RREY

CONTROL DE CAMBIOS EN REQUERIMIENTOS DE SOFTWARE DURANTE LAS FASES DE DESARROLLO

TESIS

MAESTRÍA EN ADMINISTRACIÓN DE SISTEMAS DE INFORMACIÓN

INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE MONTE

POR:

IGNACIO ALONSO MARTÍNEZ CÁRDENAS

DICIEMBRE DE 1996

CONTROL DE CAMBIOS EN REQUERIMIENTOS DE SOFTWARE DURANTE LAS FASES DE DESARROLLO

POR: IGNACIO ALONSO MARTÍNEZ CÁRDENAS

TESIS

Presentada al Programa de Graduados en Ingeniería y Tecnologías de la Universidad Virtual

Este trabajo es Requisito Parcial Para Obtener el Título de

Maestro en Ciencias o

Maestro en Administración de Sistemas de Información

INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE MONTERREY

DICIEMBRE DE 1996

Índice

1 Introducción 2

1.1 Descripción del problema 5 1.2 Preguntas 7 1.3 Descripción del Contenido 7

2 Revisión Bibliográfica 9

2.1 Requerimientos 9 2.2 Especificación de Requerimientos 11 2.3 Control de Cambios 16

3 Método y Procedimiento 26

3.1 Objetos 26 3.2 Procedimiento 39

4 Resultados 55

4.1 Proyecto P8Am 55 4.2 Proyecto P8Bm 59 4.3 Generales 60 4.4 Discusión - 62

i

5 Resumen y Conclusiones 66

A Apéndices 70

A-1 De la Empresa 70 A-2 Modelo de Madurez (CMM) 73 A-3 Bitácora de Cambios 78 A-4 Plan de Configuración 81 A-5 Experiencia 84

B Bibliografía 86

i i

LISTA DE FIGURAS

Figura 1 SEL, Distribución de Errores por Origen 4

Figura 2 Ciclo de vida típico de un producto de software 6

Figura 3 Divisiones del Manejo de Configuración 17

Figura 4 Escala de Implantación 19

Figura 5 Flujo del proceso de Control de Cambios 21

Figura 6 Modelo de Diseño de Cascada (ciclo de vida) 29

Figura 7 Modelo de Diseño (cascada) Usado por Ambos Proyectos . . 30

Figura 8 Estructura de Proyectos 31

Figura 9 Concepto de MCI en P8 Am 46

Figura 10 Niveles de Madurez de Proceso 74

i i i

Dedicado a:

Mi esposa Catalina por su paciencia, A Nachito por su admiración, A Catita por mandarme a clases, A Vivid por bebé.

iv

Las mejores prácticas programáticas (de "software") son inútiles si éstas, están enfocadas a desarrollar las funcio-nes equivocadas. -Nacho.

Puente Tacoma Narrows

El "colgante-galopante", abrió sus puertas el lo de Julio de 1940 y se colapsó 4 meses después, durante una tormenta de viento en Noviembre 7. Tenía una longitud de 1780 metros. No hacía falta esperarse hasta el final, para darse cuenta que algo andaba mal.

1

1 I N T R O D U C C I Ó N

L o s s i s t e m a s de programática, (de aquí e n ade lan te refer i -do c o m o software ind i s t in t amente ) se en focan a sa t i s facer u n a n e c e s i d a d p e r c i b i d a p o r u n c l iente . P o r lo tan to , c u a n d o h a b l a -m o s de r e q u e r i m i e n t o s de software, sob reen t endemos l a n a t u r a -l e z a f u n d a m e n t a l de estos, i .e. l a de c a p t u r a r esas n e c e s i d a d e s e x p r e s a d a s p o r e l c l i e n t e / u s u a r i o , s i n embargo , poco r econoce -m o s , de s u precisión y defec t ib i l idad r ea l y m e n o s d e l a spec to dinámico que h o y día h a n a d q u i r i d o .

L o s r e q u e r i m i e n t o s de software h a n e v o l u c i o n a d o a l a p a r de l a informática, s i n o e n l a compactación y l a v e l o c i d a d , sí e n l a c o m p l e j i d a d y e l v o l u m e n . C a s i todos r e c o r d a m o s n u e s t r o s p r i m e r o s p r o g r a m a s : prácticamente los r e q u e r i m i e n t o s se c o n -vertían e n código, y e l u s u a r i o genera lmente se c o n f o r m a b a c o n q u e e l s i s t e m a h i c i e r a algo m u y pa rec ido a lo d i c h o v e r b a l m e n t e p o r e l diseñador (nosotros) y e l u s u a r i o .

E n a q u e l en tonces , h a b l a r de p r o g r a m a s fuente e r a h a -b l a r prácticamente d e l "s is tema", y éste p o r lo gene ra l se con te -nía e n a l g u n o s c ien tos de líneas de código. H o y , l o s s i s t e m a s p o s e e n l a v e r s a t i l i d a d y grado de i n t e l i genc i a que lo s fue rza i n -h e r e n t e m e n t e a "expandi rse" geométricamente e n c o m p l e j i d a d .

Simultáneamente, e l mane jo de r e q u e r i m i e n t o s h a e v o l u -c i o n a d o . S u elaboración, recopilación, c o n t r o l , documentación y r a s t r eo se h a n vue l t o u n a d i s c i p l i n a i n g e n i e r i l .

E l mane jo de r e q u e r i m i e n t o s es f u n d a m e n t a l e n e l éxito de u n p r o d u c t o de software, pero h o y e n día, d o n d e lo único c o n s t a n t e es e l c a m b i o , e l c o n t r o l de c a m b i o s e n r e q u e r i m i e n t o s

2

se conv ie r t e e n u n a h a b i l i d a d n e c e s a r i a p a r a l a s u p e r v i v e n c i a . A q u e l l a s e m p r e s a s que no se h a n pod ido a d a p t a r a l c a m b i o , es-p e c i a l m e n t e e n l a s fases de desa r ro l lo o construcción, se están j u g a n d o u n a c a r t a pe l i g rosa p a r a s u s u b s i s t e n c i a .

A n t e s , e l c l i en te podía esperar a que e l s i s t e m a fue ra c o m -ple to , p r o b a d o y reconocía que e l s i s t e m a sería d e p u r a d o (léase corregido) a lo la rgo de l a s fases i n i c i a l e s de operación. E s o e r a p o s i b l e , p o r q u e c o n t a d a s firmas tenían el poder y c o n o c i m i e n t o p a r a d e s a r r o l l a r esos "complejos" s i s t emas . H o y , e l c l i en te c u e n -t a c o n u n a v a s t a v a r i e d a d de proveedores , que están d i s p u e s t o s a p o n e r e n s u s m a n o s , c a l i d a d m u n d i a l , p rec io y t i e m p o de e n -t r ega s i n m a y o r e s objeciones . Así, u n a e m p r e s a d e s a r r o l l a d o r a de sof tware e s t a o b l i g a d a p o r l a s c i r c u n s t a n c i a s a p roveer s o l u -c i o n e s p r e c i s a s , rápidas y l i m p i a s mejor que e l res to .

L o s p royec tos ac tua l e s de software están afectados p o r e l a m b i e n t e ex te rno . U n proyecto h o y e n día se ve i m p a c t a d o p o r lo q u e s u c e d e e n e l ex te r ior y de no acep ta r c o n t r o l a d a m e n t e esos c a m b i o s estratégicos p a r a l a v e n t a de u n p r o d u c t o , p u e d e per-d e r o p c i o n e s de v e n t a .

C a b e p r e c i s a r que estos c a m b i o s d e b e n a s i m i l a r s e y v i t a l i -z a r l o s p royec tos y n o en fe rmar o c o r r o m p e r l o s . E s decir , l o s c a m b i o s d e b e n verse c o m o p o s i b i l i d a d e s de m e j o r a y n o c o m o de t r ac to res de éxito.

A d i f e r enc i a de o t ras ac t iv idades ingen ie r i l e s d o n d e l a p re -cisión y l a métrica d o m i n a n , e l software posee c ie r t as v i r t u d e s sub j e t i va s e i n d i r e c t a s , i nhe ren te s solo a l a s ac t i v idades "c rea t i -v a s " d e l h o m b r e y es tas s o n l a s más difíciles de p e r c i b i r y c o n -t ro la r .

3

E n l a s igu ien te figura (ver F i g u r a 1. e n pág. 4) t o m a d a de l Sof tware E n g i n e e r i n g L a b o r a t o r y 1 de l a N A S A [ S E L , 1995] pode-m o s ex t r apo la r e l m i s m o p r o b l e m a , e n otros proyec tos se soft-wa re , d o n d e los r e su l t ados s o n s i m i l a r e s e n c u a n t o a l costo de u n m a l c o n t r o l de r eque r imien tos , pero sobre todo de s u s c a m -b i o s . L a figura pre tende ser u n ejemplo i l u s t r a t i vo so lamente .

O r i g e n d e E r r o r e s

Figura 1. SEL, Distribución de Errores por Origen

1. El "software Engineering Laboratory (SEL) es una organización patrocinada por el Goddard Space Flight Center de N A S A y fue creado en 1976 para investigar la efectividad de las tecnologías de software en proyec-tos de desarrollo de software.

4

1.1 Descripción del problema

E n m i c a r r e r a p ro fes iona l he s ido diseñador, i nves t i gado r de r e q u e r i m i e n t o s y p r o b a d o r de software, s i n embargo , d o n d e m a y o r sa t i s f acc iones y l ecc iones he a p r e n d i d o es, c o m o líder de p royec to .

E n b a s e a m i expe r i enc i a c o m o líder de p royec tos de soft-w a r e (ver Apéndice T a b l a 3. e n pág. 78) y lo que conozco de c o n -t r o l de c a m b i o s observo que u n o de los p r o b l e m a s que f r ecuen temen te se p a s a n p o r a l to e n los p royec tos de desa r ro l lo , y n o p o r fa l t a de r e c o n o c i m i e n t o , s i no c o m o de u n d e s l i z a m i e n t o g r a d u a l de l a i m p o r t a n c i a , es e l c o n t r o l de los c a m b i o s e n los re-q u e r i m i e n t o s d u r a n t e l a s fase de desa r ro l lo de u n p r o d u c t o de sof tware .

P o r u n l ado , e n los proyec tos donde n o exis te t a l c o n t r o l , e l logro de es tos c a m b i o s res ide ne tamente e n l a h a b i l i d a d a d m i -n i s t r a t i v a p e r s o n a l de los diseñadores o de l líder d e l p royec to . P o r o t ro , e n aque l lo s p royec tos donde exis te e l c o n t r o l de c a m -b i o s , este depende de l a ob je t iv idad y c r i t e r io d e l líder de c a m -b i o s .

E n t o n c e s decidí p a r a e l objeto de e s t a tes is , a b o r d a r e l p r o b l e m a de cómo rea l i za r este c o n t r o l de c a m b i o s e n p royec tos de d e s a r r o l l o de u n a m a n e r a pragmática y r ea l , e n c i m a de los p r o c e s o s y a p rees tab lec idos , e x c l u y e n d o aque l los c a m b i o s an te -r io re s o u l t e r io re s a l desa r ro l lo , t o d a vez que es tos c a e n e n l a de-finición y e s t ab l ec imien to de n u e v o s p royec tos o d e l m a n t e n i m i e n t o p r o p i o de l p r o d u c t o .

E n f o r m a gráfica, t r a t a r emos c o n e l c o n t r o l de c a m b i o s e n r e q u e r i m i e n t o s e n l a s fases cen t ra les de l c i c lo de v i d a de l p r o -

5

d u c t o i .e . l a d e l desa r ro l lo . V e r área s o m b r e a d a e n l a F i g u r a 2. e n pág. 6.

E s t a s r e c o m e n d a c i o n e s l a s p u s e e n práctica e n dos p r o -y e c t o s rec ien tes . E l p r i m e r proyecto fue l a p r i m e r a vez que se p u s o e n f u n c i o n a m i e n t o , y e n e l s egundo se c o r r i g i e r o n o mejo-r a r o n l a s a c c i o n e s que no p u d i e r o n a d e c u a d a m e n t e e jecutarse e n e l p r i m e r o .

Figura 2. Ciclo de vida típico de un producto de software

6

N o es que n o e x i s t a n e n e l m e r c a d o b a s t a s y comple j a s h e r r a m i e n t a s p a r a r ea l i za r este t rabajo, n o es que e l concep to s e a novedoso e n s i , t o d a vez que d i s t i n to s estándares h a c e n h i n -capié e n e l deb ido c o n t r o l . S i n embargo y pa ra f ra seando a T o m d e M a r c o [Peopleware, 1987]:

-Los mayores problemas de nuestro trabajo no son tanto tecnológicos como sociológicos en principio-

E l c o n t r o l de c a m b i o s e n r e q u e r i m i e n t o s en tonces se c o m -p l i c a , p o r l a fa l ta de u n p roceso ingen ie r i l , l a fa l ta de a d r e n a l i n a e i n g e n i o d e l líder, ó de l agobio p o r l a exces iva b u r o c r a c i a e n e l p r o c e s o m i s m o , y p o r lo tan to , c o m p r o m e t e e l éxito de los p r o -yec tos .

1.2 Preguntas

¿Cómo c o n t r o l a r los c a m b i o s de m a n e r a efect iva d u r a n t e l a e t a p a de de sa r ro l l o de los p r o d u c t o s de software, m i n i m i z a n -do c o n esto e l efecto negat ivo que estos causarían de n o c o n t r o -l a r s e ? .

¿Qué r e c o m e n d a c i o n e s prácticas puede u n líder de p r o -yec to ob tene r de l a p resen te?

1.3 Descripción del Contenido

L a tes i s se e s t r u c t u r a de l a s igu ien te m a n e r a :

7

- Capitulo 2. Revisión bibliográfica. Donde se exponen los pun-tas y temas conocidos.

- Capítulo 3. Donde se describen los casos y el procedimiento practicado

- Capitulo 4. Donde se describen con detalle los resultados de cada caso y se plantean los resultados generales de ambos.

- Capitulo 5. Donde se resumen y concluyen las observaciones, recomendaciones de esta tesis.

8

2 R E V I S I Ó N B I B L I O G R Á F I C A

L a s neces idades d e l c l iente p u e d e n ser f o r m u l a d a s a t r a -vés de requer imiento(s ) escritos(s). E s t o s r e q u e r i m i e n t o s p u e d e n s e r e l a b o r a d o s c o n j u n t a m e n t e ent re el c l ien te y l o s diseñadores de ese sof tware.

E n t o n c e s , se p r e s u m e d i rec tamente , que e l éxito de u n s i s t e m a p u e d e ser m e d i d o , p o r qué t a n b i e n los r e q u e r i m i e n t o s re f le jan l a s n e c e s i d a d e s d e l c l i en te y qué t a n b i e n l a s n e c e s i d a -des p e r c i b i d a s p o r e l c l ien te ref lejan l a s neces idades rea les y p o r qué t a n b i e n éste c u b r e ta les d e m a n d a s .

L o s objet ivos de este capítulo serán aque l lo s de de f in i r lo q u e se en t i ende p o r " requer imientos" , l a s d i ferentes c l a ses , l o q u e se en t i ende p o r u n a "especificación de r e q u e r i m i e n t o " y p o r " c o n t r o l de c a m b i o s " .

2.1 Requerimientos

E n e l m u n d o de l a programática, e l argot h a t en ido u n a c o n s t a n t e evolución y m u c h o s términos y a n o t i e n e n e l m i s m o s ign i f i cado o u n so lo s ign i f icado . E l p r o b l e m a se n o s c o m p l i c a a q u i e n e s n u e s t r a p r i m e r a l e n g u a no es e l inglés, que p o r dec i r lo así, es l a l e n g u a d e l software. Así, a l g u n o s términos i n c l u s o n o e n c u e n t r a n u n a traducción p r e c i s a o c o n s ign i f i cado que e n e l a rgo t sí p o s e e n . S i n embargo tomaré, p a r a fines de estandarización a l g u n a s de l a s def in ic iones que l a IEEE, e n es-pecífico a q u e l l a s desc r i t a s e n e l "Software E n g i n e e r i n g T e r m i n o -logy" [ I E E E , 1990] .

9

Requirement:

(1) A c o n d i t i o n or c a p a b i l i t y needed b y a u s e r to solve a p r o b l e m or ach ieve a n objective.

(2) A c o n d i t i o n o r c a p a b i l i t y tha t m u s t be me t o r p o s s e s s e d b y a s y s t e m or s y s t e m c o m p o n e n t s to sat isfy a con t r ac t , s t a n d a r d , spec i f i ca t ion , or o ther f o r m a l l y i m p o s e d d o c u -m e n t s .

(3) A d o c u m e n t e d r ep re sen ta t i on o f a c o n d i t i o n o r c a p a b i l i -t y a s i n (1) o r (2).

E s t a s 3 def in ic iones c o n t i e n e n (resumen) algo, de l a c u l p a i n d i r e c t a de l a s fal las c o n el mane jo de r e q u e r i m i e n t o s . P o r e jemplo , e n l a p r i m e r a (1), so lo se h a b l a de l "usua r io" , m i e n t r a s q u e e l "cl iente" h a s ido exc lu ido , y éste debe a l a p a r o c o n m a -y o r p r i o r i d a d ser cons ide rado , t o d a vez que e n l a r e a l i d a d e l d i -señador de software quizá, n i l legue a conoce r a l u s u a r i o . D o n d e e l c l i en te es q u i e n negoc i a o p a g a y e l u s u a r i o es s o l a m e n t e q u i e n físicamente interactúa c o n e l s i s t e m a , s e a o n o e l p r o p i e -t a r io . Así que n o necesa r i amen te es tas dos p e r s o n a s c o n c u e r -d a n ent re lo que se requiere , se fac i l i t a o a p o r t a u n s i s t e m a .

L a s e g u n d a (2), d i g a m o s que se q u e d a c o r t a e n e l s en t i do m o d e r n o (último l u s t r o de l siglo), e n el sen t ido de que habrá o c a s i o n e s e n que e l diseñador e n r i q u e z c a o supe re l o s r e q u e r i -m i e n t o s d e l c l ien te y c o n ello logre u n a ven ta ja c o m p e t i t i v a ; sí, e n p r i n c i p i o los r e q u e r i m i e n t o s d e b e n ser es t r ic tos , pero lo úni-co es t r i c to es lo conoc ido ; lo nuevo , lo novedoso , lo es p r e c i s a -m e n t e p o r q u e b r i n c a l a s l i m i t a c i o n e s es t r ic tas . C u a n d o e l c l i en te , e l u s u a r i o o e l diseñador, se d a n c u e n t a que se p u e d e b r i n c a r u n a f rontera , rápidamente se desea es tab lecer u n n u e v o r e q u e r i m i e n t o , s u r g i e n d o c o n esto l a d i f i c u l t a d de c o n t r o l a r es-tos " c a m b i o s " e n los proyec tos de desa r ro l lo v igentes .

10

2.2 Especificación de Requerimientos

T o m a n d o l a definición de l "Software E n g i n e e r i n g T e r m i -no logy" [ I E E E , 1990] .

Requirement Specification:

A d o c u m e n t t ha t specif ies the r e q u i r e m e n t s for a s y s t e m o r c o m p o n e n t . T y p i c a l l y i n c l u d e d are f u n c t i o n a l r e q u i r e -m e n t s , p e r f o r m a n c e r equ i r emen t s , d e s i g n r e q u i r e m e n t s , in te r face r e q u i r e m e n t s a n d deve lopment s t a n d a r d s .

E n s u sen t ido más a m p l i o , l a especificación de u n a e n t i -d a d es: l a descripción de e sa en t idad .

E n l a mayoría de los casos u n a especificación será u n a descripción de los a t r i b u t o s que s o n "relevantes" a l u s o i n t e n c i o -n a d o de l a especificación. Se d i s t i n g u e n dos t i pos de espec i f i ca -c i o n e s p o r e l u s o que se les p r e t e n d a dar :

- D e s c r i p t i v a s : A q u e l l a s que s i r v e n p a r a en tender e s a e n t i d a d .

- P r e s c r i p t i v a s : A q u e l l a s que s i r v e n p a r a c r ea r u n a e n t i d a d .

E s n a t u r a l u s a r los dos t ipos de especificación e n l a m i s -m a especificación de r eque r imien tos , s i n embargo es ta tes i s se en foca e n e l mane jo y c o n t r o l de los r e q u e r i m i e n t o s p r e s c r i p -t ivos , p r e c i s a m e n t e p o r l a d i f i c u l t a d de r ep re sen t a r y c r e a r a lgo q u e aún n o exis te .

P o r h a c e r u n a analogía, es más fácil e s c r i b i r u n a h i s t o r i a y a s u c e d i d a e n s u s h e c h o s y s u s fechas, que p reve r l a .

11

E s t a m i s m a analogía n o s desp ie r t a l a imaginación y n o s de ja rápidamente p re sen t i r l a d i f i cu l t ades que u n d e s a r r o l l o de sof tware n u e v o i m p l i c a , e n oposición a l de u n a m a q u i l a de soft-w a r e . Entendiéndose p o r m a q u i l a , a q u e l l a producción e n ser ie de u n sof tware y a exis tente , p robado y ren tab le .

F o c a l i z a n d o e n los r eque r imien to s de sof tware [ I E E E , 1990] :

Software Requirement Specification (SRS):

D o c u m e n t a t i o n of the e s sen t i a l r e q u i r e m e n t s ( funct ions , p e r f o r m a n c e , d e s i g n cons t r a in t s , a n d a t t r ibutes) of the sof tware a n d i t s e x t e r n a l in ter faces .

Así , l o s p r i n c i p a l e s tópicos que los esc r i to res de r e q u e r i -m i e n t o s (SRS) d e b e n c o n s i d e r a n s o n :

- F u n c i o n a l i d a d : ¿Qué se s u p o n e que h a c e ?

- I n t e r conex iones ex te rnas : ¿Qué in t e r acc iones t iene c o n h u m a -n o s , e q u i p o s periféricos, y o t ros s i s t e m a s de sof tware?

- Desempeño: V e l o c i d a d y t i empos .

- A t r i b u t o s : i n t e r n o s y ex ternos , e.g. s e g u r i d a d , p o r t a b i l i d a d .

- L i m i t a c i o n e s : i n t e r n a s y ex te rnas , e.g. m e m o r i a , lenguaje .

2.2.1 Características

L o s r e q u e r i m i e n t o s d e s c r i b e n cosas , en t idades ; c o m o t a l , t i e n e n u n a ser ie de características necesa r i a s y / o deseab les q u e p e r m i t a n s u v a l i d e z y u t i l i d a d . E s t a s características s o n e n m u -c h o s c a s o s análogas a aque l l a s que con t i ene l a información ve -raz .

12

L a s espec i f icac iones de r e q u e r i m i e n t o s de software (SRS) p a r a se r útiles d e b e n tener l a s s igu ien tes características [ I E E E 8 3 0 - 1 9 9 3 ; D e Boer , 1993]:

Correcta

U n a S R S es co r rec t a sí y solo sí c a d a r e q u e r i m i e n t o a s e n -tado , es t a l que e l software d e b a c u m p l i r l o .

Clara

U n a especificación debe ser c o m u n i c a d a . P o r lo t an to e l c l i en te , e l diseñador, e l equ ipo de inspección y p r u e b a , e l equ ipo de a s e g u r a m i e n t o de c a l i d a d , d e b e n tener l a m i s m a in t e rp re t a -ción. U n a especificación es c l a r a c u a n d o t iene sólo u n a in t e rp re -tación.

Completa

U n a especificación debe d e s c r i b i r todos los a t r i b u t o s re le-v a n t e s de l a e n t i d a d que se especi f ica . C o m o esto es m u y difícil de c u m p l i r y a que t endemos a sobre-especi f icar , r e q u e r i m o s l a s igu i en t e característica.

Precisa

U n a especificación n o debe espec i f icar más de lo n e c e s a -r i o , p a r a l l ega r a en tender l a e n t i d a d espec i f i cada .

13

Consistente

D e b e t ener c o n s i s t e n c i a i n t e r n a , i .e. n o debe t ener c o n t r a -d i c c i o n e s den t ro de l a m i s m a , n i c o n t r a espec i f i cac iones s u p e -r io re s , c o m o p o r e jemplo u n a especificación de s i s t e m a (universo) .

C u a n d o u n a especificación p ie rde l a c o n s i s t e n c i a se re-q u i e r e n g r a n d e s i nve r s iones e n t i empo p a r a c l a r i f i ca r y a c o r d a r c o n t o d a s l a s pa r tes (usuar io , c l iente y diseñador) c u a l espec i f i -cación precede a c u a l y a que de p r i n c i p i o u n a contradicción i n -válida a t odas l as espec i f icac iones que están e n conf l ic to .

Verificable

C o m o l a especificación de r e q u e r i m i e n t o s (SRS) será u t i l i -z a d a p a r a ve r i f i ca r que e l p r o d u c t o final sa t isface lo s r e q u e r i -m i e n t o s , debe ex i s t i r u n proceso c o n e l c u a l se c o m p r u e b e que e l p r o d u c t o c u m p l e c o n l a especificación. U n a especificación es ve r i f i cab le sí y so lo sí c a d a r eque r imien to a sen tado es ve r i f i ca -b l e .

E j e m p l o de r e q u e r i m i e n t o s n o ver i f i cab les s o n a q u e l l o s sub je t ivos c o m o : - m u y rápido-, -amigable - , -bon i to - .

Utilidad

U n a especificación debe ser útil. D e b e s e rv i r t an to c o m o c o n t r a t o c o n e l c l iente , c o m o u n a base p a r a e l diseño. C o n s e -c u e n t e m e n t e , l a especificación debe ser e s c r i t a de m a n e r a t a l que :

14

- e l c l i en te e n t i e n d a l a s i m p l i c a c i o n e s de l a especificación

- e l e q u i p o de diseño, e n t i e n d a l a s i m p l i c a c i o n e s de l a espec i f i -cación y

- q u e h a y a u n a suave transición de l a especificación h a c i a e l d i -seño.

L a u t i l i d a d de u n a especificación n o se m i d e n e c e s a r i a -m e n t e e n e l h e c h o de que ésta resu l te e n u n diseño r e a l i n m e -d ia to . E n m u c h a s ocas iones u n a especificación o s u s m o d i f i c a c i o n e s s o n p romoto re s de o t ras espec i f icac iones que sí se m a t e r i a l i z a n e n diseños reales o e n pa tentes .

Modificable

U n a especificación debe ser e s c r i t a de t a l m a n e r a q u e per-m i t a c o n s i d e r a r n u e v a s en t idades o l a modificación de l a s ex i s -tentes .

T o d o s lo s que v i v i m o s diseñando software, quisiéramos q u e e s t a característica no l a t u v i e r a n , es más, n o creo que u n diseñador h a y a s ido e l p r o m o t o r de es t a característica...

E s t a característica es l a que más dolores de c a b e z a repre -s e n t a p a r a lo s líderes de proyecto , diseñadores, i n s p e c t o r e s y p r o b a d o r e s , y a que e n u n a b r i r y ce r ra r de ojos u n a línea, u n e n u n c i a d o e n l a especificación de r e q u e r i m i e n t o s de sof tware (SRS) p u e d e d e s e n c a d e n a r u n a serie c o s t o s a de c a m b i o s y a jus-tes a l o s p royec tos . U n a especificación puede c a m b i a r todo lo q u e se p u e d a , s i e m p r e y c u a n d o n o lo h a g a e n e l m o m e n t o p re -c i s o e n q u e u n proyec to v ivo e s t a t r aba jando c o n e l l a .

15

C u a n d o u n a modificación a u n a especificación es acep ta -d a , f o r zada o i n t r o d u c i d a a u n proyec to e n p roceso de ejecución, l a s c o n s e c u e n c i a s p u e d e n ser devas tadoras a m e n o s que se l leve u n c o n t r o l p r e c i s o e i n g e n i e r i l de estos c a m b i o s .

2.3 Control de Cambios

No basta saber, sino también aplicar el saber: no basta querer, es preciso obrar. -Goethe.

I m a g i n e m o s p o r u n m o m e n t o que se desea c o n s t r u i r u n a c a s a . E s t a o b r a , le es a s i g n a d a a u n a rqu i tec to , q u i e n p l a s m a l a s i d e a s d e l c l i en te e n u n a serie de p l a n o s ( requer imientos) . E s -tos p l a n o s p r e t e n d e n reflejar l a s ideas expues t a s p o r e l c l i en te . S i todo fue ra i d e a l l a c a s a deb ie ra c o n s t r u i r s e con fo rme a lo que l o s p l a n o s i n d i c a n , centímetro a centímetro.

Qué p a s a c u a n d o a l a m i t a d de l a o b r a l l ega l a dueña de l a c a s a y se d a c u e n t a que l a iluminación de l a c o c i n a n o es l a a d e c u a d a g r ac i a s a que u n m u r o comple to e s to rba e l pa so de l a l u z so la r ; qué p a s a c u a n d o e l baño requ ie re m o v e r lo s gr ifos a u n a a l t u r a que lo s niños a l c a n c e n , c u a n d o y a todo e l m o s a i c o e s t a i n s t a l a d o .

Igua l e n e l software. L o s r e q u e r i m i e n t o s h a c e n l a s veces d e l m a p a , y m i e n t r a s m a s c l a ros será más fácil r e a l i z a r e l p r o -yec to , s i n embargo , u n a ser ie de even tua l idades , me jo ras y n u e -v a s n e c e s i d a d e s (e.g. de ajuste preciso) p u e d e n forzar u n a modificación a los r e q u e r i m i e n t o s o a l a s espec i f i cac iones de función. E s t o s c a m b i o s de no ser con t ro l ados e n e l s en t ido téc-n i c o y de implantación, p u e d e n l l eva r a u n a insatisfacción d e l c l i en te a l p e r c i b i r que s u s neces idades no s o n c o n s i d e r a d a s ; o a

16

u n a tensión entre los diseñadores c u a n d o estos c a m b i o s se r ea -l i z a n c o n s t a n t e y c a p r i c h o s a m e n t e 2 .

E l c o n t r o l de c a m b i o s es u n a par te de l mane jo de c o n f i g u -ración (del inglés - con f igu ra t i on m a n a g e m e n t , p o r s ig las : C M ) y es p a r a propósitos de es ta tes is l a par te crítica de m a n e j o de p royec to s d u r a n t e l a fase de ejecución (F igu ra 3 . e n pág. 17).

E l propósito de l C M (manejo de configuración) es el m a n -t ene r l a i n t e g r i d a d de lo s p r o d u c t o s (por p r o d u c t o s se en t i ende e l sof tware , h a r d w a r e y firmware, y s u documentación asoc iada) c o n f o r m e e v o l u c i o n a n desde l a s espec i f icac iones , a través d e l d i -seño, de sa r ro l l o y producción. N o es u n a a c t i v i d a d a i s l a d a , ex i s -te p a r a a p o y a r e n e l desa r ro l lo y m a n t e n i m i e n t o d e l p r o d u c t o . U n p o b r e mane jo de configuración y los p r o d u c t o s se perderán; u n C M exces ivo y l a s o rgan izac iones jamás entregarán p r o d u c -tos p o r e l exceso de b u r o c r a c i a .

Figura 3. Divisiones del Manejo de Configuración

2. Caprichosamente usado aquí, para acentuar vaguedad, no una voluntad inmadura.

17

Pero , qué es mane jo de configuración. T o m a n d o l a des-cripción de F l e t c h e r B u c W e y [ I E E E , 1995] de mane jo de c o n f i g u -ración más c e r c a n a a los fines de e s t a tes is , q u i e n a s u vez compendió los estándares I E E E - 6 1 0 ( IEEE) y de M I L - S T D - 9 7 3 (depar tamento de l a defensa de los E U A ) :

Configuration management:

E s u n a d i s c i p l i n a que a p l i c a dirección y supervisión técni-c a y a d m i n i s t r a t i v a p a r a :

(a) Identificar y documentar características físicas y funcionales de los objetos de configuración (CIs, del inglés -configuration item).

(b) Controlar cambios a los objetos y su documentación.

(c) Registro y reporte de la información necesaria para manejar los obje-tos (CIs) efectivamente, sus estados y su documentación asociada.

(d) Auditar los objetos para verificar su adherencia a las especificaciones y requerimientos.

E l c o n t r o l de c a m b i o s (del inglés - c o n f i g u r a t i o n cont ro l ) es e l t e rce r m a y o r p roceso iden t i f i cado p a r a e l mane jo de c o n f i g u -ración ( F i g u r a 3 . e n pág. 17) y s i lo viéramos e n e l a spec to histó-r i c o , ocuparía e l tercero y penúltimo n i v e l e n l a p l a t a f o r m a ( F i g u r a 4 . e n pág. 19).

Así, c u a l q u i e r a e m p r e s a de desa r ro l lo de software, debe t ene r p r i m e r o per fec tamente iden t i f i cados a s u s p r o d u c t o s ; des -pués, debe ser c a p a z de m o n i t o r e a r los c a m b i o s e n estos; s i l a e m p r e s a se p r e c i a de tener u n a b u e n a ingeniería de sof tware, deberá p o d e r c o n t r o l a r los c a m b i o s y finalmente, s i l a e m p r e s a c u e n t a c o n l a i n f r a e s t r u c t u r a de c a l i d a d necesa r i a , podrá a s p i -r a r a t ener auditorías a todo lo largo de l c i c lo de v i d a de u n p r o -d u c t o .

18

Figura 4. Escala de Implantación

C o m o proceso , e l c o n t r o l de c a m b i o s es l a p r o p u e s t a s i s -temática, justificación, evaluación, coordinación, aprobación/ desaprobación de todos los c a m b i o s después de l e s t a b l e c i m i e n -to f o r m a l de l a configuración.

U n p r o d u c t o puede ser c a m b i a d o , p o r t res r azones p r i n c i -pa l e s :

(a) El producto está en desacuerdo con las especificaciones

(b) Mejoras

(c) Ajuste fino

19

E l p r i m e r p a s o e n l a resolución de u n p r o b l e m a es l a i d e n -tificación (registro) de éste, y a sea a través de u n repor te de fa-l l a , u n a petición f o r m a l de c a m b i o o m e j o r a ( F i g u r a 5. e n pág. 21) .

E s t a s pe t i c iones d e b e n ser a n a l i z a d a s desde e l p u n t o de v i s t a de i m p a c t o s y d o c u m e n t a r los p r o s y c o n t r a s e n u n d o c u -m e n t o q u e p e r m i t a a l a dirección de l proyec to t o m a r d e c i s i o n e s sob re e l fu tu ro de esos c a m b i o s . E s t a s pe t i c iones debe es ta r f u n d a m e n t a d a s c o n los deta l les , d i a g r a m a s e i n d i c a c i o n e s técni-c a s lo m a s p r e c i s a s pos ib le , además de los cos tos a p royec to ( t iempo básicamente) y de ser pos ib le s u g e r i r a l t e rna t i va s v i a -b l e s , e n o r d e n de p r i o r i d a d , según q u i e n l a s a r g u m e n t a .

V e a m o s e l p roceso básico e n e l d i a g r a m a de flujo s igu ien te [ B u c k l e y , 1995] .

2 0

Figura 5. Flujo del proceso de Control de Cambios

21

2.3.1 Eras del Control de Cambios

E n m i opinión S u s a n D a r t [SEI, 1992] n o s desc r ibe per -fec tamente l a s t res eras de l mane jo de con f igu rac iones (CM) que simultánea e implícitamente descr ibe aque l l a s d e l c o n t r o l de c a m b i o s (CC) :

P a s a d o :

U n p a s a d o donde e l C M e ra u n p r o b l e m a o r g a n i z a c i o n a l p r i v a d o , d o n d e l a s s o l u c i o n e s incluían p r o c e d i m i e n t o s y políti-c a s m a n u a l e s , i .e. l a gente contenía l a información de C M e n s u s cabezas o e n u n a r ch ive ro físico.

Presen te :

E l p resen te está ca rac te r i zado p r i n c i p a l m e n t e p o r aspec-tos tecnológicos. E s decir , que l a tecnología exis ten te p a r a so-p o r t a r e l C M es l i m i t a d a p a r a g r a n d e s a p l i c a c i o n e s y p l a t a f o r m a s m u y específicas, así que l a mayoría de l a s g r a n d e s o r g a n i z a c i o n e s c o n s t r u y e n s u s p r o p i o s s i s t e m a s de C M .

F u t u r o :

E l f u tu ro se caracterizará p o r 5 t e m a s p r i n c i p a l e s :

1. Tecnología

Nuevos y más perfectos requerimientos.

2. Orientación a procesos

Se requiere una definición precisa de estos.

3. Gerencia

2 2

La gerencia necesita asistencia para tomar decisiones sobre si adquirir ó ha-cer los sistemas de C M .

4. Política

Todo parece indicar que el gobierno Norteamericano eventualmente reque-rirá que sus contratistas tengan un cierto nivel (nivel 3 al menos) de C M M (ver Apéndice A-2 en pág. 73). De suceder esto, las grandes firmas crearán una barrera para los nuevos entrantes (competidores) que orillaran al resto de las firmas a lograr niveles iguales o mejores.

5. Estandarización

Cada vez se reconoce a C M como un factor importante de estandarización, quizá pronto sea contemplado por organismos internacionales de estandarización.

2.3.2 Herramientas Existentes de Manejo de Configuración (CM)

Evi tando hablar de los diversos productos existentes en el mercado de soporte a u t o m á t i c o de C M , a c o n t i n u a c i ó n se hace u n a e x t r a c c i ó n o resumen de las c u a l i d a d e s / t ó p i c o s inherentes que poseen el universo de los productos existentes (SEI, Dar t Susan):

E s decir, cas i todos los productos contienen l a m a y o r í a de las siguientes c a r a c t e r í s t i c a s .

- Depós i t o :

Capturan información de C M y almacenan versiones de archivos como in-mutables.

2 3

- Distribución

Permiten a múltiples usuarios tener acceso al depósito.

- M a n e j o de contex to

Capturan el dominio (conjunto de cualidades del artículo de configuración) para el usuario, eliminando con esto que el usuario recuerde como el objeto obtuvo cierto estado y cuales son todos los artículos, relaciones y herra-mientas en ese contexto.

- C o n t r a t o

Representan un plan y registro formal de trabajo de cada artículo de confi-guración.

- Petición de C a m b i o

Llevan el proceso de cambio en configuraciones y lleva un memoria de es-tos cambios.

- Modelación

Extraen la noción de una configuración a partir de una instancia de ésta, al describir totalmente la configuración.

- Depósito de par tes

Optimizan la necesidad de regenerar estas partes y maximiza la compartición de estas partes (reutilización).

- Atribución

Permiten la descripción del sistema a un alto nivel, mediante la extracción de sus características.

2 4

- Mantenimiento de consistencia

Permiten al sistema identificar inconsistencias.

- A r e a de trabajo

Permiten aislamiento del trabajo entre diseñadores y distingue entre partes inmutables (globales) de aquellas áreas de trabajo privadas y provisionales.

- Transparenc ia

Permiten un mecanismo de visión de una configuración, desde el depósito principal hacia un área de trabajo con protección contra accesos no autoriza-dos.

- T r a n s a c c i ó n

Sincronizan y coordinan equipos de diseñadores que cambian o trabajan la misma configuración.

25

3 M É T O D O Y P R O C E D I M I E N T O

3.1 Objetos

L o s objetos u t i l i z a d o s p a r a r ea l i za r l a investigación s o n : d o s p royec tos de software de t e l e c o m u n i c a c i o n e s rea les y c o n -temporáneos, den t ro de u n a e m p r e s a i n t e r n a c i o n a l , q u e t a n sólo e n México t iene más de 9 0 años de h a c e r negoc ios e n telefo-nía: Ericsson. A m b o s proyec tos se desar ro l lan( ron) e n S a l t i l l o , C o a h u i l a , d u r a n t e los años de 1995 y 1996 . E l apéndice A - l e n pág. 7 0 con t i ene los da tos ad i c iona l e s de E m p r e s a Tecnológica E r i c s s o n S . A . de C . V . u b i c a d a e n S a l t i l l o , C o a h u i l a , México.

E l enfoque será cua l i t a t ivo , c o n dos objet ivos p r i n c i p a l e s :

A . - Dar a conocer métodos y practicas existentes.

B. - Sugerir alternativas de mejora, mismas que habrán de practicarse en sendos proyectos.

L o s r e s u l t a d o s cuan t i t a t i vos , r e su l t an t e s de l a m e d i c i o n e s y estadísticas p r o p i a s de l a ingeniería de software de l a e m p r e s a serán u t i l i z a d a s p a r a enfat izar l a i m p o r t a n c i a y c o n s e c u e n c i a s de u n b u e n o m a l c o n t r o l de c a m b i o s e n lo p a r t i c u l a r .

S e e scog ie ron dos proyec tos c o n l a s s igu ien te s caracterís-t i ca s :

• P8A. E l cual ya finalizó la etapa de desarrollo en Abril de 1996, y entra en la etapa de producción y distribución (ver Figura 2. en pág. 6).

• P8B. El cual se encuentra a la mitad del desarrollo, en algo llamado "codifi-cación y prueba básica" (ver Figura 7. en pág. 30) y es una versión mejorada de P8A.

2 6

3.1.1 Modelo de Diseño (Ciclo de Vida del Software)

L o s p royec tos P 8 A y P 8 B u t i l i z a n u n M o d e l o de Diseño de C a s c a d a 3 (ver F i g u r a 6. e n pág. 29).

E l concep to f u n d a m e n t a l de l m o d e l o de c a s c a d a es e l de t e r m i n a r u n a e t apa c o n ver i f icac iones an tes de e m p e z a r l a s i -gu ien te , ev i t ando c o n esto l a propagación de fa l las , e n e l s u -p u e s t o de que u n a fa l la e n c o n t r a d a e n l as e tapas i n i c i a l e s es m a s b a r a t a e n cos to y daño que e n e tapas pos te r io res .

E r i c s s o n e n p a r t i c u l a r h a d e t e r m i n a d o que e l cos to de u n a fa l l a se e s c a l a p o r 10 entre c a d a fase; así p o r e jemplo , u n a f a l l a q u e a l p r i n c i p i o c u e s t a 1 peso e n c o n t r a r l a y co r r eg i r l a , e n l a e t a p a de m a n t e n i m i e n t o l l ega a cos t a r h a s t a 1 0 , 0 0 0 pesos e n -c o n t r a r l a y co r r eg i r l a .

C a b e h a c e r n o t a r que e l mode lo de c a s c a d a h a su f r ido u n c o n s t a n t e pe r f ecc ionamien to desde 1970 p o r c a u s a d e l u s o que h a t en ido den t ro de l a s g randes empre sa s d e s a r r o l l a d o r a s de sof tware , t an to m i l i t a r e s c o m o c iv i les . I nc lu so h a y q u i e n e s a u -g u r a n s u d e c a d e n c i a to ta l , a l ser s u s t i t u i d o p o r m o d e l o s más d i -námicos y aco rdes a l f i n de m i l e n i o (e.g. M o d e l o s E v o l u t i v o s e Increméntales); s i n embargo , aún e l m o d e l o es v igente y los m o -de los evo lu t ivos aún seme jan réplicas de ca scadas , e n oposición a l a aseveración categórica de F . B r o o k s , [1995] -the waterfáll model is wrong!-. C i e r t o es que e l a p l i c a r e l m o d e l o c o m o t a l , t ie -ne s u s efectos s e c u n d a r i o s negat ivos , sobre todo c u a n d o se u s a e n p royec tos de a l t a v o l a t i l i d a d o e n p r o d u c t o s de v i d a co r t a , pe ro eso n o lo a n u l a .

3. E l modelo de cascada fue inicialmente publicado por Winton Royce, 1970, pero iniciado por la Fuerza Aé -rea de los E U A , 1966; también por Rosove, 1967

2 7

E l m o d e l o u t i l i z a d o p o r E r i c s s o n (ver F i g u r a 7. e n pág. 30) , v i ene h a se r u n a adaptación m o d e r n a de l de c a s c a d a , d o n -de l a s d i fe renc ias más no to r i a s c o n el m o d e l o clásico ( F i g u r a 6. e n pág. 29) s o n :

1. Se tienen mojoneras de dos tipos:

•"Milestones", donde se verifica la entrada y salida entre fases.

•"Tollgates", donde el proyecto es evaluado desde el aspecto financiero y de mercado. En las aduanas ("tollgates") se determina el futuro del proyecto como tal.

2. La verificación y prueba se lleva de mayor a menor ("bottom- up") en senti-do inverso al diseño, que va de mayor a menor ("top-down").

2 8

Figura 6. Modelo de Diseño de Cascada (ciclo de vida)

2 9

Figura 7. Modelo de Diseño (cascada) Usado por Ambos Proyectos

3 0

3.1.2 Estructura de los Proyectos

L o s dos proyec tos (objetos de es ta tesis) están a ca rgo de d o s o r g a n i z a c i o n e s de diseño, u n a l o c a l i z a d a e n México, de a h o -r a e n ade lan te re fe r ida c o n e l sufijo " m " (e.g. P 8 A m ) , y l a o t r a l o -c a l i z a d a e n los E s t a d o s U n i d o s de América, de a h o r a e n ade l an t e re fe r ida c o n e l sufijo "u" (e.g. P 8 A u ) . E s t a tes i s se enfo-c a e n los p royec tos r ea l i zados e n México, s i n embargo d o n d e lo s efectos s e a n e x t r a f ronteras habrán de referirse a m b o s (m y u) .

L o s dos p royec tos están r e l a c i o n a d o s e n p r i n c i p i o , u n o c o m o m e j o r a d e l otro, es decir , P 8 A s e r i a e l i n i c i a l y P 8 B será l a s igu i en t e versión de P 8 A .

L a e s t r u c t u r a de los dos proyec tos P 8 A m y P 8 B m se l l e v a a l c a b o de l a s igu ien te fo rma :

Figura 8. Estructura de Proyectos

Proyecto Global

P8

Proyecto Local

P8u

Proyecto Local

P8m

Así, c a d a proyec to t iene s u p r o p i a organización i n t e r n a de p royec to , es to es, c o n s u s líderes de proyec to , de c a l i d a d , de p r u e b a , y s o n r e s p o n s a b l e s de los p r o d u c t o s i nhe ren t e s . L a for-m a e n que se s i n c r o n i z a n es a través de l a s mo jone ra s ("milesto-nes" y "tollgates") que s o n l as m i s m a s p a r a a m b o s p royec tos l oca l e s .

P a r a n o a h o n d a r e n detal les , ésta es l a f o r m a e n que E r i c -s s o n h a t raba jado los últimos ve in te años (ver F i g u r a 7. e n pág. 30) , d o n d e e n ocas iones e l número de p royec tos loca les p u e d e l l ega r a i n v o l u c r a r h a s t a c i n c o o seis o rgan izac iones diferentes , e n m u c h o s de los casos de d iversos países.

L a f o r m a e n que E r i c s s o n l og ra l a i n t e g r i d a d de s u s p r o -d u c t o s es g rac i a s (entre o t ras cosas) a u n es t r ic to c o n t r o l de Identificación de Configuración y C o n t r o l de E s t a d o s . P o d e m o s d e c i r q u e es tos dos tópicos (ver F i g u r a 3 . e n pág. 17) de M a n e j o de Configuración, s o n l a c o l u m n a ve r t eb ra l de l a i n t e g r i d a d de l o s p r o d u c t o s E r i c s s o n y s o n lo su f i c i en temente sólidos c o m o p a r a o p a c a r a los o t ros 2 (Con t ro l de C a m b i o s y Auditorías).

L a m e t i c u l o s a identificación de configuración c o m p r e n d e prácticamente todo t ipo de artículos, objetos, d o c u m e n t o s , e q u i -pos , s i s t e m a s , s u b s i s t e m a s , func iones y c o m p o n e n t e s que se p u e d a n e n c o n t r a r bajo l a firma. T o d o p r o d u c t o , a i s l a d o o in t e -g r ado de n -p i ezas , se e n c u e n t r a reg is t rado e n u n a ba se de da tos l l a m a d a P R I M 4 , acces ib le desde c u a l q u i e r o f i c ina E r i c s s o n e n e l m u n d o . Allí se e n c u e n t r a n referencias c r u z a d a s de m a n u f a c t u r a y documentación, t a l que c u a l q u i e r empleado (diseñador, vende -d o r o arqui tec to) puede u b i c a r u n p r o d u c t o p a r t i c u l a r .

4. P R I M es la base de datos en que se inscriben todos y cada uno de los productos, más su documentación asociada, dentro de Ericsson. L a base de datos contaba en 1994 con: 920,000 productos, información sobre 3 millones de documentos, 13 GigaBytes y maneja 100,000 transacciones diarias.

3 2

Además, a lo la rgo de l a v i d a de u n proyec to (más de dos años) l a documentación v i v a se e n c u e n t r a e n o t r a base de da tos m u n d i a l l l a m a d a De l ta 5 . E s t a les pe rmi t e l l eva r u n es t r ic to c o n -t r o l de E s t a d o de l a documentación a s o c i a d a . P o r c i t a r u n e jem-p l o , allí se p u e d e ve r el es tado de u n d o c u m e n t o p a r t i c u l a r , s u e s t ado de revisión (pre l iminar , listo-para-revisión, i n s p e c c i o n a -do, ap robado) y l a s m i n u t a s (registros de inspección) que a v a l a n d i c h a s i n s p e c c i o n e s . P o r c ier to es tas m i n u t a s (registros de i n s -pección) f a c i l i t a n e l C o n t r o l de C a m b i o s y a que i n d i c a n e l núme-ro y t ipo de fa l las e n c o n t r a d a s y c a l i f i c a n o d e s c a l i f i c a n lo s objetos i n s p e c c i o n a d o s .

Aquí, es e l m o m e n t o p rec i so p a r a r e m a r c a r que es tos p r o -y e c t o s c a r e c e n de u n sistemático (ingenieril) C o n t r o l de C a m -b i o s . E r i c s s o n adolece a lo largo de s u s filas, de u n M a n e j o de Configuración a p r o p i a d o .

C a d a p royec to l o c a l posee algún t ipo de C o n t r o l de C a m -b i o s , pe ro es tos n o se e n c u e n t r a n in tegrados e n el p royec to g lo-b a l . C i e r t o es que d iversos p royec tos sí lo p r a c t i c a n , pero n o ex is te u n c o n t r o l científico o a l m e n o s i n g e n i e r i l de éste. D i g a -m o s q u e e l C o n t r o l de C a m b i o s e n E r i c s s o n rec ibe u n a c e r c a -m i e n t o pragmático, que e n ocas iones f u n c i o n a y e n o c a s i o n e s n o .

C a b e h a c e r n o t a r que es ta d e b i l i d a d , h a s ido r e s a l t a d a e n d o s frentes, p o r u n l ado ISO9001:1994 (en s u cláusula 4 .4 .9 ) :

- L a mayoría de lo s cen t ros de diseño de E r i c s s o n t i e n e n l a cer-tificación ISO9001 c o n m e r e c i d o s a t r i bu tos , s i n e m b a r g o l a sustentación sólida de l C o n t r o l de C a m b i o s a n i v e l g l o b a l de

5. D E L T A es una base de datos en que la documentación vigente de todos los proyectos activos se localiza. U n a vez liberado el producto, todas las ultimas revisiones aprobadas son inscritas permanentemente en P R I M .

3 3

proyec tos está a u n débil. L o s cen t ros de diseño loca les c u m -p l e n este r u b r o , pero no lo h a c e n m u y b i e n a n i v e l intercompañías.

y p o r otro , e l mode lo de m a d u r e z , C M M Versión 1.1 [ H u m -p h r e y , 1989] que es e l estándar de c a l i d a d de software más re-c o n o c i d o e n l a s e g u n d a m i t a d de los noven tas :

- D i v e r s o s cen t ros de diseño de E r i c s s o n h a n h e c h o esfuerzos s u s t a n c i a l e s p a r a obtener n ive les (específicamente N i v e l 3) d e n t r o d e l M o d e l o de M a d u r e z de C a p a c i d a d (CMM), p o r se r éste e l estándar requer ido p o r e l G o b i e r n o N o r t e a m e r i c a n o a través de s u depa r t amen to de l a defensa (ver Apéndice A - 2 e n pág. 73). E l M a n e j o de R e q u e r i m i e n t o s y e l M a n e j o de C o n f i g u -ración de Sof tware s o n Procesos C l a v e s de l N i v e l 2 . E r i c s s o n n o h a p u b l i c a d o e l r e su l t ado de s u s auditorías e n CMM, pe ro se p r e s u m e q u e s i está c o m o el res to de l a s e m p r e s a s de d i se -ño de software, aún se e n c u e n t r a e n los n ive les i n i c i a l e s .

3.1.3 Contenido Técnico de P8Am

E l propósito de l p royec to P 8 A m es d e s a r r o l l a r y l i b e r a r n u e v a f u n c i o n a l i d a d y pe r fecc ionamien tos e n u n a ser ie de s u b -s i s t e m a s p a r a sa t i s facer los r equ i s i to s p a r a C e n t r a l e s telefóni-c a s públicas, de tránsito (Tándem) e In t e rnac iona l e s (IXC). L o s p r i n c i p a l e s c l ien tes a sa t i s facer s o n e m p r e s a s telefónicas e n l o s E s t a d o s U n i d o s de Norteamérica.

E l p royec to a b a r c a todas l a s fases de l de sa r ro l l o de soft-w a r e , desde s u fase de e s t ab lec imien to h a s t a l a liberación y e l m a n t e n i m i e n t o (ver F i g u r a 7. e n pág. 30).

L a ser ie de mejoras c o m p r e n d e n lo s igu ien te :

3 4

1. Adherencia al Estándar de Redes Inteligentes (AIN 0.1)

2. Mejoras a la versión 0.1 de SSP (Tándem de datos)

3. Mejorar Filtrado de la Información del Abonado-A

(ANI)

C o n t a n d o c o n l as s igu ien tes fechas i m p o r t a n t e s , c o m u n e s t a n t o p a r a P 8 A m y P 8 A u :

• La fecha de liberación fue el 8 de Abril de 1996.

• La fecha para disposición al cliente, es el 25 de Julio de 1996.

L a c a r g a de t rabajo se dividió c o m o s igue ( tomar referen-c i a e n l a F i g u r a 7. e n pág. 30):

- Administración de Proyecto

5,000 horas-hombre (mhr)

- Especificación y Diseño de Funciones

12,150 mhr

- Diseño de bloques, de software y prueba básica

19,505 mhr

- Prueba Funcional

12,200 mhr

- Prueba de Sistema Fuente

400 mhr

- Seguimiento durante Pruebas

1,860 mhr

3 5

- Total P8Am

51,115 mhr (la mayoría durante 1995)

3.1.4 Contenido Técnico de P8Bm

E l propósito de l p royec to P 8 B m e n T X M es d e s a r r o l l a r y l i -b e r a r n u e v a f u n c i o n a l i d a d y pe r fecc ionamien to e n u n a ser ie de s u b s i s t e m a s de l a c e n t r a l telefónica E r i c s s o n AXE10, e n e l s i s te -m a fuente 2/APT 210 10 p a r a sa t i s facer los r equ i s i t o s p a r a C e n -t r a l e s telefónicas públicas loca les , de Tránsito (Tándem) e I n t e r n a c i o n a l e s (IXC). L o s p r i n c i p a l e s c l i en tes a sa t i s facer s o n e m p r e s a s telefónicas e n los E s t a d o s U n i d o s de Norteamérica.

L o s objet ivos de m e r c a d o p a r a el p royec to P 8 B i n c l u y e n l a satisfacción de r equ i s i t o s nuevos p a r a u n a e m p r e s a a d m i n i s t r a -d o r a de se rv ic ios telefónicos y de conmutación de voz y da tos , e n s u rápida expansión de negocios domésticos e i n t e r n a c i o n a l e s . P r o v e y e n d o n u e v a y me jo rada f u n c i o n a l i d a d p a r a c l i en tes i m -p o r t a n t e s de l m e r c a d o N o r t e a m e r i c a n o (las compañías ope rado-r a s B e l l , R B O C s p o r s u s s ig las e n inglés), c u m p l i e n d o c o m p r o m i s o s c o n t r a c t u a l e s exis tentes c o n estos c l i en tes y ase-g u r a n d o p r o g r a m a s de c o m p r a s de Software n u e v o p a r a l a b a s e y a i n s t a l a d a .

L a ser ie de mejoras c o m p r e n d e n lo s igu ien te :

1. Probador Digital Remoto de Líneas (ROTL)

2. Administración de Opciones (para el abonado).

3. Desarrollo de la facilidad Rechazo de Llamadas Desco-nocidas (Anonymous Cali Rejection).

4. Limpieza de Productos No-Conformes

3 6

C o n t a n d o c o n l a s s igu ien tes fechas i m p o r t a n t e s , c o m u n e s t a n t o p a r a P 8 B m y P 8 B u :

• La fecha de liberación para P8B será el 15 de Septiembre de 1996.

• La fecha para disposición al cliente para P8B será el 30 de Diciembre de 1996.

L a composición de l a ca rga de t rabajo se a p r e c i a c o m o s i -gue :

- Administración de Proyecto

5,000 mhr

- Especificación y Diseño de Funciones

12,600 mhr

- Diseño de bloques, de software y prueba básica

15,160 mhr

- Prueba Funcional

10,620 mhr

- Seguimiento durante Pruebas

1,000 mhr

- Total P8Bm

44,380 mhr (la mayoría durante 1996)

3 7

Instantánea de Ambos Proyectos L a s igu ien te t a b l a r e s u m e algo de los números de a m b o s

p royec tos tan to e n duración, comple j idad , v o l u m e n e n líneas de código, d e n s i d a d de f a l l a s 6 , v o l u m e n de código ( K L O C s 7 ) y c o n -tribución de a m b o s proyectos . E s t o s números sólo c o m p r e n d e n l a e t apa de d e s a r r o l l o 8 .

Parámetro Proyecto P8Am Proyecto P8Bm

Duración 11 m e s e s 9 m e s e s

F e c h a de Liberación 8 / A p r / 9 6 1 5 / S e p / 9 6

P r e s u p u e s t o de H o r a s - 5 1 , 0 0 0 - 4 4 , 0 0 0

P l a n t i l l a (diseñadores) 5 0 5 2

Número de P r o d u c t o s ( u n i d a d e s de software) 31 3 5

V o l u m e n t o t a l ( K L O C )

9 2 . 0 3 7 9 5 a

D e n s i d a d de F a l l a s ( f a l l a s / K L O C )

0 . 1 7 0 . 0 8

Número de E s p e c i f i c a c i o n e s de R e q u e r i m i e n t o s

(SRSs) 5 19

Po rcen t a j e de Contribución a l P r o y e c t o G l o b a l 5 0 8 0

a.Es un valor aproximado ya que los productos aún no han sido codificados.

Tabla 1. Instantánea de Ambos Proyectos

6. La densidad de fallas se mide constantemente a partir de la pmeba básica (ver Figura 7. en pág. 30). sin em-bargo aquella que a la empresa más le interesa es la densidad de fallas durante los primeros 6 meses en opera-ción del producto (6MOP). La densidad es el número de fallas sobre el volumen de líneas. 7. K L O C es una medida generalizada en la ingeniería de software y es igual a mil líneas de código (indistinto del lenguaje). 8. La etapa de desarrollo es aquella comprendida entre las aduanas (ver Figura 7. en pág. 30) de aceptación (porque el proyecto es factible) y la de liberación (porque el producto esta a disposición general).

38

3.2 Procedimiento

L a metodología de diseño e n E r i c s s o n se respetó a lo la rgo de a m b o s proyec tos ; s i n embargo se i n t r o d u j e r o n c ie r t as a c c i o -n e s (buenas prácticas) que s i n c o n t r a v e n i r l a metodología y p r o -cesos e s t ab lec idos cre ímos 9 n o s darían m a y o r atención a l c o n t r o l de c a m b i o s , de es ta m a n e r a se evitó conf l ic to c o n e l s i s -t e m a de c a l i d a d , y e l c o o r d i n a d o r de c a l i d a d aprobó e l u s o de d i -c h a s prácticas.

U n o de es tos p r o c e d i m i e n t o s es tab lec idos es e l de " C o n -t r o l de C a m b i o s " que es y a u n a b u e n a práctica den t ro de E r i c s -s o n S a l t i l l o , pe ro no de lo s p r o c e d i m i e n t o s m u n d i a l e s , es deci r , q u e e n es tos p royec tos i n t e n t a m o s u n a m e j o r a de este p r o c e d i -m i e n t o b a s a d o s e n lo s r e su l t ados ob ten idos c o n antelación. Aún y c u a n d o e l p roceso es d i rec to , carece de u n a visión a d m i n i s t r a -d o r a de es tos (cambios) y lo que e x p e r i m e n t a m o s e n p royec tos an t e r i o r e s e r a que múltiples c a m b i o s e r a n o m i t i d o s bajo l a ex-c u s a (real) de fa l ta de t i empo; desviación de l a atención, i .e. e l diseñador prefiere i nve r t i r t i empo e n cod i f i ca r que e n d o c u m e n -tar ; o p o r d i f e renc ia de c r i te r ios : p a r a u n o s , u n c a m b i o m a y o r es u n a c o s a s i n i m p o r t a n c i a y p a r a otros , u n c a m b i o s e n c i l l o p u e -de ser s u peo r p e s a d i l l a . P o r c i t a r u n ejemplo: e l p royec to ante-r i o r P7+ (del c u a l fu i líder) tuvo u n revés costosísimo e n h o r a s y d e n s i d a d de fa l las , p o r q u e u n c a m b i o e n u n párrafo de los re-q u e r i m i e n t o s fue c o n s i d e r a d o "s imple" p o r e l exper to , s i n e m -ba rgo p a r a los p r o g r a m a d o r e s fue u n a v e r d a d e r a c a r g a de t raba jo (1500 hrs .) y anímica, y a que a l es ta r c e r c a l a f echa de p r u e b a s func iona l e s , se c r e a r o n fal las e n po rc iones de código y a ve r i f i cado e n p r u e b a s básicas y po r lo t an to c o n e s t a b i l i d a d .

9. Plural porque tanto el líder de proyecto y el gerente (yo) acordamos las acciones.

3 9

E l p roceso u t i l i z a d o e n E r i c s s o n S a l t i l l o se a p r e c i a e n l a s i gu i en t e i m a g e n (la par te s u p e r i o r es ta t r u n c a d a p o r con f iden -c ia l idad) :

Imagen 1. Proceso de Control de Cambio. Ericsson Saltillo

4 0

S e o b s e r v a l a fal ta de u n cue rpo i n t e g r a d o r / a d m i n i s t r a -d o r gene ra l de todos los c a m b i o s . C ie r to que el comité de c a m -b i o s ( C R T d e l Inglés "Change R e v i e w Team") t iene acceso a todos e l los , pe ro n o los in tegra , m e n o s los a d m i n i s t r a e n e l s en t ido a m p l i o de l a p a l a b r a , de m a n e r a s i m i l a r a l a F i g u r a 5. e n pág. 2 1 .

E l p a s o 2 es e l o r igen de l a fa l ta de integración y a que e l e q u i p o (CRT) se reúne b i e n a l p r i n c i p i o de s u s ac t iv idades , pe ro s u s m i e m b r o s c a d a vez más o c u p a d o s e m p i e z a n a fa l tar a s u c o m p r o m i s o c o n e l equ ipo . E l p roceso se vue lve e l t rabajo de u n a s o l a p e r s o n a , l a c u a l a l l l egar a l paso 11, e s t a t a n a g o b i a d a p o r e l t rabajo , que s i m p l e m e n t e no d a e l " segu imien to" n e c e s a -r io p a r a ve r i f i ca r que e l c a m b i o sea i m p l a n t a d o . L o s o r i g i n a d o r e s d e l c a m b i o p r o n t o se d e s i l u s i o n a n p o r l a l e n t i t u d d e l p roceso y lo a b a n d o n a n , p a r a h a c e r los c a m b i o s a s u m a n e r a .

L o s p royec tos an te r iores a P 8 c o n t e m p l a b a n e l c o n t r o l de c a m b i o s c o m o u n a a c t i v i d a d útil, pero que sólo t e n i a éxito c u a n -do lo s diseñadores c o o p e r a b a n p a r a r ea l i z a r l a . N a d a más le jano de l a ingeniería de software, que no es c a p r i c h o s i n o p roceso .

3.2.1 Proyecto P8Am

E n e l p royec to P 8 A m se i n t e n t a r o n l a s s igu ien tes a c c i o n e s c o n e l fin de h a c e r efectivo e l c o n t r o l de c a m b i o s , y dejar de se r c o n e l lo u n p roceso a n h e l a d o pero inef icaz:

1. Introducir el Plan de Manejo de Configuración.

2. Asignación de la posición de Administrador de Cambios.

3. Elaboración del Indice de Configuración Maestro.

41

E l p l a n de configuración es u n d o c u m e n t o que p re tende p o r p r i m e r a vez e n l a h i s t o r i a de E r i c s s o n S a l t i l l o , c u b r i r e l c o n -t r o l de c a m b i o s de lo s p r o d u c t o s que s o n r e s p o n s a b i l i d a d de P 8 A m (ni P 8 A n i P 8 A u t u v i e r o n t a l plan) que f u e r a n i m p a c t a d o s a p a r t i r d e l fin de Diseño de Función y h a s t a e l fin de l a P r u e b a F u n c i o n a l (ver F i g u r a 7. e n pág. 30).

P a r a t ener éxito e n e l con t ro l , fue de v i t a l i m p o r t a n c i a q u e hiciéramos u n "congelamiento" de l a base de diseño, así que a p r o v e c h a m o s l a m o j o n e r a de F i n de l Diseño de Función y c o n -s i d e r a r l a c o m o l a base p a r a a m a r r a r e l es tado de lo s d o c u m e n -tos . L e l l a m a m o s conge lamien to , po rque a p a r t i r de e s a fecha , ningún c a m b i o es p e r m i t i d o s i n p a s a r an tes p o r el c o n t r o l d e l a d m i n i s t r a d o r de c a m b i o s , s ea que el d o c u m e n t o y a esté a p r o -b a d o o n o p o r los comités respec t ivos . E n p royec tos an te r io res a l g u n o s c a m b i o s se filtraban bajo l a e x c u s a de que los d o c u -m e n t o s n o e s t a b a n a p r o b a d o s y que p o r ende e l "proceso" les permitía aún hace r los ; es ta práctica promovía de a l g u n a m a n e -r a q u e lo s d o c u m e n t o s más volátiles se m a n t u v i e r a n ab ie r tos ( s in aprobarse) h a s t a los últimas fases pos ib le s , e l u d i e n d o de e s t a m a n e r a los con t ro les de c a m b i o s . A l g o q u e n o s o t r o s e n d i -seño l l a m a m o s , tomar atajos...

L a s m e t a s es tab lec idas po r e l p l a n fueron:

1. Identificar la base funcional. Aprovechando el final de la etapa (mojonera) ya mencionada.

2. Definir la organización de Manejo de Configuración.

3. Analizar y aprobar los cambios a la base.

4. Prevenir cambios no autorizados.

5. Asegurar la observancia del procedimiento de control de cambio.

6. Mantener el Indice Maestro al día.

4 2

L a s func iones de l a d m i n i s t r a d o r de c a m b i o s fue ron l a s de r e c i b i r l a s p r o p u e s t a s de c a m b i o s y ver i f i ca r que f u e r a n ca l i f i c a -d a s y de ser acep tadas , que fue ran i m p l a n t a d a s además de l l e -v a r e l índice de configuración maes t ro . E s t e r o l sería e l r e s p o n s a b l e de m a n t e n e r e l p l a n y ver i f i ca r que se l l e v a r a a l c a -b o .

E l a d m i n i s t r a d o r de c a m b i o s t iene u n a posición e n l a p l a n t i l l a d e l p royec to c o m o se a p r e c i a e n l a s igu ien te i m a g e n lo q u e le p e r m i t e a l líder tener u n c o n t r o l p u n t u a l de c u a l q u i e r c a m b i o .

4 3

Imagen 2. Organigrama de P8Am

E l índice m a e s t r o (ver Imagen 3. e n pág. 48) fue l a apor ta -ción de l m i s m o a d m i n i s t r a d o r de c a m b i o , y tenía e l propósito ló-gico de d a r atención p r i m o r d i a l m e n t e a todos aque l los objetos de configuración que p o r s u i m p o r t a n c i a , c o m p l e j i d a d o a l cance , e r a n más su scep t i b l e s de c a u s a r daños e n el proyecto s i suce -

4 4

dían c a m b i o s n o con t ro l ados . C a b e r e sa l t a r e l h e c h o de que e l índice e r a u n ext rac to de l Indice de Configuración (global) de todo e l p royec to .

E n e l argot de mane jo de configuración, el Ind ice de C o n f i -guración M a e s t r o ( M C I de l inglés M a s t e r C o n f i g u r a t i o n Index) e n l a mayoría de lo s casos es el único índice. S i n embargo e n P 8 A m e l M C I sería u n ext rac to de l g loba l , c o n t e n i e n d o en tonces sólo a q u e l l o s objetos (documentos) que e r a n de v i t a l i m p o r t a n c i a p a r a e l p royec to . Así, e l M C I contenía d o c u m e n t o s aún y c u a n d o es tos e s t u v i e r a n fuera de l desa r ro l lo de P 8 A m , es decir , incluía también d o c u m e n t o s h e c h o s p o r o rgan izac iones ex t e rnas c o m o P 8 A u . E s t e concep to se a p r e c i a e n l a F i g u r a 9. e n pág. 4 6 .

4 5

Indice de Configuración Maestro (MCI)

Figura 9. Concepto de MCI en P8Am

4 6

E n l a Imagen 3. e n pág. 4 8 , se m u e s t r a e l M C I d e l p royec -to y allí se a p r e c i a cómo se especi f ica e l t ipo de d o c u m e n t o s (e.g. F F , d e l inglés, F u n c t i o n F r a m e w o r k ) , e l to ta l de éste t ipo de do-c u m e n t o s ; e l es tado, l a fecha e n que adquirió d i c h o es tado y e l foro q u e a v a l a d i c h o estado; l a revisión (e.g. P A 5 , que s i g n i f i c a l a q u i n t a revisión p r e l i m i n a r de u n d o c u m e n t o que u n a vez l i b e r a -do será revisión final A) y u n a m a r c a que i n d i c a s i h a t en ido c a m b i o s rec ien tes .

D e l a m i s m a i m a g e n podemos ap rec i a r l a f o r m a l i d a d d e l índice, a l poseer u n autor , e l a d m i n i s t r a d o r de c a m b i o s ; u n a aprobación, l a de l líder de proyecto; u n a inspección, l a d e l coor -d i n a d o r de c a l i d a d ; u n a fecha de emisión y revisión de ésta, así c o m o u n a l i s t a de los receptores ob l igados de este d o c u m e n t o .

E l índice m a e s t r o se emitía s e m a n a l m e n t e y contenía u n a l i s t a de lo s d o c u m e n t o s , r ev i s iones y c a m b i o s e n estos , así que rápidamente se podía iden t i f i ca r c a m b i o s (ver última c o l u m n a e n l a I m a g e n 3 . e n pág. 48), pero no i n d i c a b a cuáles habían s i d o es tos c a m b i o s e n lo específico, i .e. sólo a l e r t a b a a l a d m i n i s t r a -d o r sob re c a m b i o s e n s u terreno, c o n lo c u a l él podría en t rev i s -t a r a l a u t o r de l objeto (documentos) p o r a q u e l l a s r a zones q u e s u s t e n t a b a n los c a m b i o s r e d u c i e n d o c o n esto e l número de c a m b i o s a r e q u e r i m i e n t o s no con t ro l ados , po l i zones .

4 7

Imagen 3. P8Am, Indice Maestro

4 8

3.2.2 Proyecto P8Bm

E n b a s e a l a s exper i enc ias de l proyec to P 8 A m , se m o d i f i -c a r o n y p e r f e c c i o n a r o n a l g u n a s de l a s prácticas e n el p royec to P 8 B .

L a s a c c i o n e s específicas p a r a r ea l i za r e l c o n t r o l de c a m -b i o s e n e l p royec to P 8 B m fue ron l a s s igu ien tes :

1. Asignación de un administrador de cambios con mejores condiciones de tiempo para realizar su trabajo.

2. Se introdujo una Bitácora de Cambios.

3. E l índice maestro fue sustituido por el índice de configu-ración.

4. Se omitió el plan de configuración.

5. Se destinó un tiempo específico en las juntas de segui-miento, para que el administrador de cambios diera su avance

E l h e c h o de que e l líder de proyecto de P 8 B m fuera e l a d -m i n i s t r a d o r de c a m b i o de P 8 A m permitió l a rápida i n c o r p o r a -ción y atención de l n u e v o líder de c a m b i o s e n s u p royec to pe ro también t u v o efectos s e c u n d a r i o s , c o m o los s igu ien tes :

P R O S

• rápido entendimiento del problema

• continuidad

• perfeccionamiento del proceso hecho a la medida del líder presente

4 9

• reconocimiento por parte del líder, del tiempo requerido para realizar esta labor, ya que él mismo vivió la sobrecarga de tareas por mal considerar que el manejo de cambios sería sencillo en el proyecto anterior (del cual él fue el administrador de configuración)

C O N T R A S

• como los proyectos corrieron simultáneamente (durante 5 meses aproxima-damente), el administrador de cambios de P8Am no tuvo el tiempo deseable para realizar la tarea adecuadamente, ya que gran parte de su tiempo lo tuvo que invertir en preparar su proyecto (P8Bm).

E l a d m i n i s t r a d o r de c a m b i o s tuvo más t i e m p o p a r a r e a l i -z a r s u t rabajo y a que no tenía ac t iv idades a s i g n a d a s de diseño, pe ro tenía ac t iv idades que le permitirían con juga r s u t rabajo . E l a d m i n i s t r a d o r en tonces solo tenía a s ignac iones c o m o i n s p e c t o r y / o m o d e r a d o r que le permitían enterarse de p r i m e r a m a n o de l o s c a m b i o s , con jugando mejor s u t a r ea de a d m i n i s t r a d o r de c a m b i o s .

A l i g u a l que e n P 8 A m , e l a d m i n i s t r a d o r de c a m b i o s f o r m a pa r te de l a p l a n t i l l a de l proyecto c o m o se a p r e c i a de l a I m a g e n 4 . e n pág. 5 1 .

E n P 8 B m e l a d m i n i s t r a d o r de c a m b i o s tomó e l n o m b r e de " c o o r d i n a d o r técnico loca l " , m i s m o que le confería u n r o l de ne-g o c i a d o r / c o n t r o l a d o r de t o d a c lase de aspec tos técnicos, es de-c i r , e l recibía d u d a s , c u e s t i o n a m i e n t o s y c a m b i o s c o n l a intención de encont ra r , p roveer y / o fac i l i t a r s u solución.

5 0

Imagen 4. Organigrama de P8Bm

L a bitácora de c a m b i o s 1 0 d a u n a visión c l a r a de los c a m -b ios , r e s p o n s a b l e s de resolver los , fecha p r o m e t i d a , c ier re y e l l u -gar, d o c u m e n t o , j u n t a , foro o situación que d a o r igen a c a d a u n o (ver Imagen 5. e n pág. 52). Y pre tende d a r l a atención y se-

51

g u i m i e n t o q u e fácilmente se d i l u y e c u a n d o sólo se confía e n l a m e m o r i a (cerebro) ó, se vue lve t ed io sa c u a n d o se deja e n m a n o s de l a máquina.

E s t e t rabajo debe rea l izarse p e r s o n a l m e n t e p o r e l a d m i -n i s t r a d o r de c a m b i o s .

T X M . P 8 E 0 CLASS,page2(6)

T E C H N I C A L L O G

Imagen 5. Bitácora de Cambios de P8Bm

10. Esta herramienta la utilice por primera vez en un proyecto muy anterior (1992) y se recomendó como un "integrador" natural de los cambios.

52

E l índice m a e s t r o se sustituyó po rque e n P 8 B m l a d e p e n -d e n c i a c o n P 8 B u e r a mínima, así que e l índice de configuración g e n e r a l fue suf ic ien te . E s t e porcentaje de contribución e implíci-t a m e n t e de d e p e n d e n c i a se a p r e c i a e n T a b l a 1. e n pág. 3 8 .

E l P l a n de Configuración se suprimió c o m o u n a c e r c a -m i e n t o pragmático de l líder de proyecto P 8 B m . E l líder pensó q u e c o n esto eliminaría b u r o c r a c i a , sobre algo que él tendría u n c o n t r o l d i rec to de todas fo rmas , es dec i r n o q u i s o ob l iga r se él m i s m o p o r esc r i to .

E l p l a n de configuración no debe e l i m i n a r s e bajo e l riesgo de p e r d e r f o r m a l i d a d y atención, y s i funcionó p a r a P 8 B m fue p o r q u e e l líder de proyec to es u n campeón e n c o n t r o l de c a m -b i o s , pe ro esto es p r o d u c t o de u n a c o i n c i d e n c i a y p o r lo t an to es difícil de repe t i r y / o es tab lecer c o m o proceso i n g e n i e r i l .

D a r u n t i e m p o e n l as j u n t a s de s e g u i m i e n t o r e s a l t a l a i m -p o r t a n c i a de l a a c t i v i d a d y pone e n a le r t a a t o d a l a p l a n t i l l a d e l p royec to d e l avance de lo s c a m b i o s (can t idad y f recuencia) así c o m o de l a atención que se les está d a n d o p a r a i m p l a n t a r l o s o d e s c a r t a r l o s . E n l a s j u n t a s s e m a n a l e s de s e g u i m i e n t o se r e v i s a -r o n cuántos y cuáles s o n los más an t iguos s i n reso lverse y p o r lo t an to se p u e d e n t o r n a r e n po tenc ia les a g u a f i e s t a s 1 1 .

E l efecto H a w t h o r n e 1 2 t uvo aquí u n efecto pos i t i vo h a -c i e n d o evidente e l interés de l equ ipo a d m i n i s t r a d o r de p royec tos

11. U n tópico no entendido en el desarrollo de software es: que una molestia no atendida desde el inicio, con el paso del tiempo adquiere dimensiones de problema progresivamente mayores.

12. {Elton M a y o , 1933} Nos reporta del experimento Hawthorne que: -el nivel de producción no esta deter-minado por la capacidad física o fisiológica del empleado, sino por las normas sociales y expectativas que in-volucra.

5 3

sob re l o s c a m b i o s r ea l i zados p o r los diseñadores, y c o n ello l a a c t i v i d a d t o m a u n m a t i z m o t i v a d o r a l hace r l e s pa ten te éste in te -rés. E s deci r , que a l m o s t r a r e l equ ipo de administración s u i n -terés r e a l e n los c a m b i o s y eventos que estos a r r o s t r a n , e l c u e r p o de diseñadores perc ibe l a i m p o r t a n c i a de éstos y p o r c o n s i g u i e n t e d a n a l a a c t i v i d a d u n carácter mo t ivan t e , a l se r és-tos c o n s i d e r a d o s c o m o de v i t a l i m p o r t a n c i a p a r a e l p royec to . Quién qu ie re se r e l m a l o de l a película.

54

4 R E S U L T A D O S

L o s s igu ien te s r e su l t ados se o b t u v i e r o n los dos p royec tos , y se r e s u m e n e n l a sección (4.3 e n pág. 60) de genera les aque -l l o s q u e i n d i s t i n t a m e n t e a p l i c a n a a m b o s .

4.1 Proyecto P8Am

L o s r e s u l t a d o s los ex t raemos de los repor tes finales, e l de p royec to y e l de mane jo de configuración, esc r i tos p o r e l líder d e l p royec to y p o r e l a d m i n i s t r a d o r de c a m b i o s r e spec t ivamen te .

E n ba se a los objet ivos de l a L i s t a e n pág. 4 2 , los s i g u i e n -tes f u e r o n l a s s a l i d a s e n opinión d i r ec t a de a d m i n i s t r a d o r de configuración:

1. Identificar la base funcional. Aprovechando el final de la etapa (mojonera) ya mencionada.

Fue posible identificar los documentos de requerimientos requeridos para el diseño desde el principio, se incorporaron al MCI, sin embargo algunos de estos permanecieron en revisiones preliminares (no aprobadas) por tiempo excesivo.

2. Definir la organización de Manejo de Configuración.

La organización se estableció, pero los participantes tenían otras tareas, in-cluyendo al administrador de cambios.

55

3. Analizar y aprobar los cambios a la base.

La base no pudo congelarse debido a la volatilidad de los documentos no aprobados. En ocasiones la velocidad del cambio-implantación evitó el aná-lisis concienzudo de estos y escribir los avisos de cambio pertinentes.

4. Prevenir cambios no autorizados.

Algunos cambios no autorizados fueron detectados, algunos se pudieron de-tener hasta su aprobación; algunos otros se detectaron después de que ya ha-bían sido implantados.

5. Asegurar la observancia del procedimiento de control de cambio.

E l procedimiento no se aplicó completamente por las prisas de cumplir las fechas de entrega.

6. Mantener el Indice Maestro al día.

El MCI fue actualizado semanalmente, aún y cuando la base no se pudo congelar fue útil detectar cambios y anticipar a los diseñadores de nuevas versiones de requerimientos.

Q u i s i e r a h a c e r hincapié e n dos factores que el a d m i n i s -t r a d o r de configuración refirió c o m o aque l los que más c o n t r i b u -y e n o a fec tan u n mane jo efectivo de c a m b i o s y , q u e s o n común d e n o m i n a d o r i r r e s t r i c to de proyec tos (guardando l a s p r o p o r c i o -nes) .

56

T I E M P O :

E l líder de configuración tuvo o t ras ac t iv idades que c o m -p r o m e t i e r o n l a e fec t iv idad a l en t r a r éstas e n conf l ic to de in te re -ses , c o m o se a p r e c i a e n l a Imagen 6. e n pág. 5 8

E l a d m i n i s t r a d o r de configuración tomó además l a res-p o n s a b i l i d a d de u n equ ipo de diseñadores (14 ingenieros) lo c u a l lo t u v o e n u n a cons tan te d u a l i d a d de papeles ; t o d a vez q u e a m b a s a c t i v i d a d e s s o n equ iva len tes a n i v e l p l a n t i l l a de p royec to .

E s de esperarse que s u t i empo lo d e d i c a r a h a es ta r a p a -g a n d o fuegos e n a m b o s frentes. P o r u n l ado los diseñadores de s u e q u i p o r e q u i r i e r o n atención d i r e c t a y po r otro l a a d m i n i s t r a -ción de c a m b i o requirió con tac tos c o n los demás líderes de lo s e q u i p o s i .e. c o n t o d a l a p l a n t i l l a .

5 7

Imagen 6. Organigrama de P8Am

58

C A M B I O S Y A H E C H O S :

E s m u y difícil ev i tar c a m b i o s c l a n d e s t i n o s sobre todo c u a n d o e n e l p royec to ex i s t en n u m e r o s o s diseñadores, c o m o e n e l c a s o de P 8 A y P 8 B e n que r e b a s a n l a c a n t i d a d de 3 0 .

L o s diseñadores e n s u afán de me jo ra r y en t regar u n p r o -d u c t o c o n e l más al to n i v e l de pe r fecc ionamien to , t i e n d e n a i n -t r o d u c i r a d a p t a c i o n e s que p u d i e n d o o no c o n s i d e r a r a l t e r e n e l p r o d u c t o final, lo h a c e n p a r a b r i n d a r u n v a l o r agregado, es de-cir , t o m a n l a i n i c i a t i v a n a t u r a l de los c readores . T o d o diseñador qu i e r e d e s t a c a r c o n u n software que sea b r i l l a n t e y s u p e r i o r a l estándar.

C o n l a expe r i enc i a , a p r e n d e n que c ier tos c a m b i o s p o r mí-n i m o s q u e p a r e z c a n , a fec tan o t ras características i n d i r e c t a s d e l s i s t e m a y que a l se r e n c o n t r a d a s afectarán s u i m a g e n p u l c r a y g e n i a l , q u e i n i c i a l m e n t e q u i s i e r o n promover .

L o s diseñadores m a d u r o s , v e n e n e l mane jo de c o n f i g u r a -ción u n a opción que les pe rmi t e p r o m o v e r s u s "mejoras" y obte-n e r m a y o r r e c o n o c i m i e n t o c u a n d o s o n acep tados l o s c a m b i o s , c o n l a garantía e x t r a de q u e d a r bajo e l a m p a r o de l a aprobación de u n comité.

4.2 Proyecto P8Bm

E l t i e m p o otorgado a l a a d m i n i s t r a d o r a de configuración fue s i n d u d a l a m a y o r contribución, q u i e n a y u d a d a p o r s u bitá-c o r a de c a m b i o s , m a n t u v o de m a n e r a pragmática y efect iva l a atención de t o d a l a p l a n t i l l a de l proyec to .

5 9

Aún y c u a n d o e l proyecto se e n c u e n t r a todavía e n e t apa de P r u e b a s F u n c i o n a l e s ex i s t en los s igu ien tes i n d i c a d o r e s p o s i -t ivos de u n a c o r r e c t a aplicación de l mane jo de configuración:

• 38 cambios registrados en la bitácora. De los cuales 36 ya están cerrados, i.e. resueltos hasta sus últimas consecuencias.

Estos puntos de acción se consideran mayores, lo que significa que al cliente le representarían una falla, así, 38 fallas al cliente fueron evitadas de un esti-mado de 63 para poder cumplir los 0.08 fallas/KLOC durante los primeros 6 meses en servicio que el proyecto tiene como meta. Este objetivo será medi-do hasta la segunda mitad de 1997 que es cuando todos los productos resul-tantes del proyecto cumplirán sus 6 meses en servicio con el cliente.

4.3 Generales

-Al ojo del amo engorda el caballo-

reza, e l viejo refrán.

U n p royec to que carece de l a supervisión d e l líder, c o m o p r o p u l s o r ; d e l c l ien te , c o m o pa t roc inador ; de l a ge renc ia , c o m o f a c i l i t a d o r a y d e l a d m i n i s t r a d o r de configuración c o m o c o n t r o l a -d o r de t a l l i s t a ; es c o m o u n caba l lo s i n s i l l a , n i r i e n d a , n i r a n c h o , i .e . u n s i m p l e c a p r i c h o de l a n a t u r a l e z a .

E n a m b o s p royec tos se practicó l a administración de c o n -figuración de m a n e r a i n g e n i e r i l c o m o u n a n e c e s i d a d r e s u l t a n t e de e x p e r i e n c i a s adve r sa s an te r iores . D e h e c h o e l c o n t r o l de re-q u e r i m i e n t o s e n E r i c s s o n Sa l t i l l o h a s ido u b i c a d o c o m o u n a "ac-ción v i t a l " o "factor c r i t i co de l éxito" d u r a n t e dos años s e g u i d o s

6 0

(1995 y 1996), c o n t a n d o así c o n u n f ranco apoyo de l a dirección e n lo e jecut ivo y lo económico.

E l r o l de l a d m i n i s t r a d o r de c a m b i o t iene y a u n l u g a r e n l a c o n c i e n c i a de los líderes de proyecto c o m o u n a p i e z a que d a co-hesión y s e g u r i d a d a s u s proyectos , e n l a m e d i d a que p rev iene eventos s o r p r e s a de u n al to costo , t an to e n v a l o r m o n e t a r i o , c o m o de s u i m a g e n c o m o líderes exi tosos . L o s líderes a c t u a l e s s o l i c i t a n a l a ge r enc i a que es ta posición sea c u b i e r t a e n lo espe-cífico y lo s diseñadores c o n expe r i enc i a v e n e n e l p u e s t o u n a m a n e r a de r e c o n o c i m i e n t o . E l r o l e n sí, t iene y a u n l u g a r e n e l a rgot de E r i c s s o n Sa l t i l l o c o m o u n a posición que d a l u c i m i e n t o a q u i e n l a d e s a r r o l l a ex i tosamente , c o m o u n a p e r s o n a de h a b i l i -d a d e s técnicas, negoc iadoras y a d m i n i s t r a t i v a s s u s c e p t i b l e s de s e r r e c o n o c i d a s p o r e l escalafón.

U n e jemplo pos i t ivo de esto, es e l interés m o s t r a d o p o r o t ros c e n t r o s de diseño e n i m p l a n t a r acc iones s i m i l a r e s ; e n pa r -t i c u l a r e l p l a n de configuración, así c o m o l a designación f o r m a l de l o s líderes/administradores de c a m b i o , e n l a s p l a n t i l l a s de p royec to .

D e h e c h o , e l p royec to P 9 , que recién i n i c i a h a d a d o u n peso r a d i c a l a l a a c t i v i d a d de l mane jo de configuración y h a to-m a d o a S a l t i l l o y s u s r e c o m e n d a c i o n e s c o m o válidas. E s t e p r o -yec to quizá h a exced ido l a no ta , a l d e d i c a r más de 3 i ngen i e ro s p a r a t ene r éxito e n s u e m p r e s a de con t ro l a r los c a m b i o s . P 9 será u n p royec to de a p r o x i m a d a m e n t e 1 2 0 , 0 0 0 h o r a s - h o m b r e y h a p l a n e a d o a p r o x i m a d a m e n t e 5 ,000 h o r a s a es ta t a rea .

61

4.4 Discusión

¿Por qué si y por qué no CM?

E l mane jo de configuración, es l a a c t i v i d a d que c o n t r o l a l a dinámica de u n proyec to , no c o n t r o l a l a v e l o c i d a d , n i l a p r e c i -sión, n i e l v o l u m e n , n i e l cos to . S i n o l a s fuerzas que a fec tan a l p royec to i n t e r n a y ex te rnamente , pero que se c o m p o r t a n dife-r en te e n relación d i r e c t a a l t i empo .

D e e s t a i d e a p o d e m o s e m i t i r los s igu ien tes j u i c i o s :

Si existe un proyecto con una duración extensa, (mayor a 6 meses) tal que los efectos del tiempo son tangibles y rápidamente notables, entonces se requiere CM. No es lo mismo desarrollar software para un misil balístico en tiempos de paz que en tiempos de guerra, por razones obvias; en las que el tiempo impone una volatilidad constante y una precisión impostergable.

Si existe un proyecto cuya volatilidad o exposición al cam-bio es alta, entonces se requiere CM, en proporción directa al volu-men y al costo. Similar al "manejo por contingencia" que se recomienda en la administración de sistemas de información: mientras más grande el riesgo y el costo de perder un equipo, más grande el costo/inversión por protegerlo.

Si los cambios previsibles en un proyecto son menores o dé-biles en costo, entonces se puede prescindir de CM.

Si el volumen y dependencia entre las partes de un proyec-to es de un tamaño considerable, es decir mayor a 50 KLOCs de código, entonces se requiere CM.

6 2

Si el proyecto de desarrollo es realizado por un número con-siderable de diseñadores, digamos mayor a quince, entonces se requiere CM, en proporción directa a la cantidad de diseñadores y de su educación de procesos. Una banda de diseñadores requeri-rá mayor CM, que un equipo bien entrenado.

Si el proyecto de desarrollo es realizado por más de dos or-ganizaciones entonces se requiere CM, en proporción directa a la cantidad de organizaciones, su separación geográfica y su simili-tud de procedimientos. Es decir, un proyecto desarrollado en co-operación por dos firmas distintas, requerirá mayor control que dos bajo la misma firma. Un proyecto realizado en distintas insta-laciones requerirá mayor CM que uno bajo el mismo techo.

Si la empresa aspira a producir software de calidad mun-dial, entonces debe tener CM, por sistema, por política.

¿Cuándo si y cuándo no CM?

T o d o se r educe a l a l cance que l a e m p r e s a o c u p e e n l a es-c a l a de implantación o a l que p r e t e n d a lograr . C o m o se i n t e rp re -t a de l a F i g u r a 4 . e n pág. 19.

L a s p r i m e r a e t apa de implantación será l a de i den t i f i c a -ción, e n d o n d e se con t ro l en , d o c u m e n t e n , i d e n t i f i q u e n todos y c a d a u n a de l a s par tes , c o m p o n e n t e s y artículos de t an to s p r o -d u c t o s c o m o se t e n g a n bajo l a firma. Identificación, que debe se r p r e c i s a y común a lo largo de l a e m p r e s a y d o c u m e n t a d a e n catálogos esc r i tos o electrónicos.

P o s t e r i o r m e n t e , se podrá p e n s a r e n m a n e j a r e l es tado de l o s artículos p r i m a r i o s .

63

U n a vez que estos 2 p rocesos base están a r ra igados , es pos ib l e i n i c i a r e l c o n t r o l de c a m b i o s . E l c o n t r o l de c a m b i o s po-drá rea l i za r se an tes o después de los p rocesos base y a c i t ados , pero es sólo e n este n i v e l e n que se puede g a r a n t i z a r que exis te u n p roceso repet ib le y p ronos t i cab l e e n oposición a u n a ac t iv i -d a d única y for tu i ta , que es lo que se pre tende evitar.

Costos de no llevar un CM

Citaré e l e jemplo de l a v i d a rea l , que n o s i l u s t r a l a m a g n i -t u d de u n error, de u n a omisión, e n los p r o c e d i m i e n t o s de c o n -t r o l de c a m b i o s o mane jo de configuración:

E l Ariane 501 despegó e n l a mañana d e l 4 de J u n i o de 1996, y se autodestruyó m i n u t o s después deb ido a u n a fa l la de software.

Ariane 501

Aún c u a n d o l a comisión inves t igadora no emite s u repor te final, se sabe que el software de l a c o m p u t a d o r a de navegación

6 4

funcionó m a l a l en t regar u n a a l t i t u d e q u i v o c a d a a l res to de l a s c o m p u t a d o r a s de vue lo , u n a s e g u n d a u n i d a d r e d u n d a n t e p rove-yó o t r a a l t i t u d (se s o s p e c h a que también equivocada) y a l n o te-n e r más re ferenc ias u t i l i z a r o n l a a l t i t u d equ ivocada , p a r a t r a t a r de c o m p e n s a r s u a l t u r a r ea l y deb ido a l a s fuerzas aerodinámicas e l cohete se partió e n dos , p r o p i c i a n d o c o n esto q u e l a s c o m p u t a d o r a s i n i c i a r a n u n a explosión a u t o d e s t r u c t i v a automática.

S e sabe que e l software de altimetría provenía práctica-m e n t e i n t a c t o de s u an tecesor el Ariane4, y que e s t a c o m p a t i b i l i -d a d s u p u e s t a , n o fue t a l . Se sabe también que este software n o fue p r o b a d o e n e l n u e v o Ar¡ane5, lo c u a l d e n o t a u n mane jo de configuración o m i t i d o .

N o todos los er rores de configuración terminarán c o n t a n catastróficos r e su l t ados , pero s i e n proporción a l cos to de desa -r r o l l o y f a l l a de los s i s t e m a s que p r e t e n d e n proteger.

65

5 R E S U M E N Y C O N C L U S I O N E S

P e r s o n a l m e n t e he v iv ido l a s fo r tunas y d e s a v e n e n c i a s de s e r u n líder de p royec to e n más de c u a t r o ocas iones . E n todas e l l a s he t en ido e l pr iv i leg io de c o n v i v i r e i n t e r c a m b i a r e x p e r i e n -c i a s c o n o t ros líderes, ve te ranos y nova tos , o t ros b r i l l a n t e s , o t ros i n c a u t o s o va l i en tes . D e el los y e l las aprendí, que m u c h o d e l sof tware de a l t a tecnología es m e r a v o l u n t a d h u m a n a . C o m o d ice T o m D e M a r c o [1987] -the mqjor problems of our work are not so much technological as sociological in nature-.

L o s líderes de proyec to que s o n h u m a n o s e n p r i n c i p i o , c a -r e c e n e n ocas iones de l soporte y sabiduría de l a técnica; n o po r -q u e n o ex i s t a , s i n o po rque no a p l i c a de l a m a n e r a e s t r i c t a c o m o d i c e n l a s fórmulas, e n p r i m e r lugar , po rque l a técnica se t r a n s -f o r m a a l e n t r a r e n con tac to c o n el h o m b r e . E l h o m b r e d i s t a u n a e t e r n i d a d de ser u n a máquina y e n los p rocesos c rea t ivos o de c o n j u n t o a f lo ra e s t a i m p o s i b i l i d a d . E n e spec ia l e n e l de sa r ro l l o de sof tware, y a que u n m i s m o b loque f u n c i o n a l (código) c o n lo s m i s m o s r e q u e r i m i e n t o s es t r ic tos es diseñado diferente c u a n d o lo r e a l i z a n d i s t i n t a s pe r sonas , no solo e n lo que p l a s m a n s i n o e n l a s p r o p i e d a d e s que les h e r e d a n a estos p r o d u c t o s , es deci r , u n p r o d u c t o será más conf iable que otro, otro será más l i m p i o y o t ro más res i s ten te a efectos s e c u n d a r i o s .

L o s c a m b i o s h o y e n día, s o n necesa r ios p a r a que u n p r o -d u c t o de software p u e d a ser diseñado, v e n d i d o y p o r lo t an to fi-n a n c i a d o , y a que e l ritmo de evolución e n los s i s t e m a s de información es lo su f ic ien temente ver t ig inoso p a r a que u n p r o -yec to se m a n t e n g a a i s l ado to ta lmente de l a m b i e n t e exter ior . U n p r o d u c t o de software puede conver t i r se e n poco r en t ab l e aún an t e s de s a l i r a l m e r c a d o , s i no i n c o r p o r a sobre l a m a r c h a c ie r -t a s novedades que los compe t ido res y a h a n ofertado, c ie r t as m e -j o r a s que e l c l ien te recién h a v i s u a l i z a d o .

6 6

E s t a tes is , p r o p o n e métodos s i m p l e s y en t end ib l e s p a r a c o n t r o l a r l o s c a m b i o s a r eque r imien tos , c o m o u n c o m p o n e n t e c o n s t a n t e e n los p royec tos de software; ev i t ando c o n el lo que c a u s e n r u i d o y m o l e s t i a s que a c a b e n reflejándose e n e l c u r s o y cos to de lo s p royec tos . P o r tanto , está o r i e n t a d a e n p r i n c i p i o a l o s líderes de p royec tos y coo rd inado re s de c a m b i o s e n p royec -tos m e d i a n o s y g randes (donde p a r t i c i p e n más de ve in te diseñadores).

L a tes i s se puede r e s u m i r e n l a s s igu ien tes t res a c c i o n e s :

U n o . P o r p r i n c i p i o de c u e n t a s se r e c o m i e n d a t ener u n a p e r s o n a c o n e l c o n o c i m i e n t o técnico necesa r io que h a g a l a s ve-ces de c o o r d i n a d o r de c a m b i o s . E s t e r o l c i e r t amente t iene u n cos to , pero se justificó e n a m b o s casos e i g u a l se j u s t i f i c a e n p royec to s de s endo tamaño. E s t a fue u n a inversión s u p e r i o r a l a s 1 0 0 0 h o r a s - h o m b r e e n a m b o s casos y , que a l n o se r h o r a s p r o d u c t i v a s d i rec tas , c o m o l a s de u n diseñador, r e c i b e n p r o n t o l a n e g a t i v a de l a administración.

L a administración rechazará l a p r o p u e s t a de i n c r e m e n t a r e l p e r s o n a l de l a p l a n t i l l a (overhead) pero es c o n v e n c i d a c u a n d o se les i n d i c a e l a h o r r o que es ta posición les significará. P a r a e jempl i f icar , e n e l p royec to P 8 B m se dejó de c o b r a r a p r o x i m a d a -m e n t e 2 5 , 0 0 0 dólares p o r concep to de l a s h o r a s i n d i r e c t a s (no c o b r a b l e s p o r l a p lan t i l l a ) , pero l a s 3 8 fa l las ev i tadas e n e l c a m -po le r e p r e s e n t a r o n u n a h o r r o de 3 8 0 , 0 0 0 dólares p o r concep to de m a n t e n i m i e n t o que e n e l c a m p o es tas fa l las h u b i e r a n cos t a -do .

D o s . E l d o c u m e n t a r es ta a c t i v i d a d m e d i a n t e e l p l a n de configuración, e l índice maes t ro y l a bitácora, es u n p u n t o i n -e l u d i b l e c u a n d o se p r a c t i c a l a ingeniería de software, d o n d e lo

6 7

q u e n o se m i d e n o puede ser mejorado , y donde lo que n o se lee, p r o n t o se o l v i d a o p ie rde interés.

T r e s . S e n t i d o común. A q u e l l a s cosas de l s en t ido común q u e p a s a m o s p o r a l to c u a n d o l a tecnología es a b r u m a d o r a p u e -d e n se r n u e s t r o s a lvav idas . D o c u m e n t a r los avances , l o s c a m -b i o s , e l e s tado de estos y p r e g u n t a r p o r s u finalización, s o n c o m o e l l i b r o de m a y o r p a r a los con tadores , es decir , u n l u g a r t a n g i b l e d o n d e se e n c u e n t r a n los m o v i m i e n t o s que r e p r e s e n t a n u n va lo r , e n este caso p a r a e l proyecto , y de los que se puede h a -ce r r e v i s t a p o r p r o p i o s y ajenos p a r a conoce r l a anatomía de u n p royec to . E n c o n t r a n d o allí b u e n a s i nve r s iones o m a l o s gas tos , a l e r t a n d o c o n ello a l líder de proyecto sobre e l b u e n desempeño de s u p royec to o a n t i c i p a n d o c u a l q u i e r evento desag radab le .

E m p e z a r c o n r e q u e r i m i e n t o s firmes n o es u n a garantía de éxito, pe ro sí u n pa so fuerte, que se debe so l id i f i ca r c o n u n es-t r i c to c o n t r o l de lo s c a m b i o s e n éstos, t o d a vez que l a v e l o c i d a d de c a m b i o y el t i e m p o de en t rega (TTM - t ime to marke t ) e n los n o v e n t a s , n o s h a b l a n de l a i m p o s i b i l i d a d de tener r e q u e r i m i e n -tos rígidos e i n a m o v i b l e s m a s allá de u n año. U n b u e n c o n t r o l de c a m b i o s puede n o mejora r e l t i empo de en t rega (TTM), pe ro de f in i t i vamen te sí a s e g u r a que éste, se c u m p l a .

R e c o r d e m o s l a ley de p e r v e r s i d a d [ H u m p h r e y 1989] que n o s d ice : -mientras mas firmes sean los requerimientos, más sus-ceptibles son de estar equivocados-, y que c o n el lo , n o s i n v i t a a e s t a r a le r tas , a l e r t as a no conf iarse de u n r e q u e r i m i e n t o perfec-to, a le r t as a lo que e l c l iente p u e d a in t e rp re t a r de es tos y a l a pos t r e i m p a c t a r n u e s t r a navegación de proyec to .

E l líder de proyec to novato debe v i v i r c o n l a noción de c a m b i o y m a n e j a r l a . Aquél líder que p r e t e n d a v i v i r s i n e l los (los c a m b i o s ) está des t i nado a v i v i r u n proyec to de c o n f u s i o n e s y

68

s o r p r e s a s n o s i e m p r e gra tas y e n a l g u n o s casos h a s t a p u d i e r a n cos t a r l e s u c a r r e r a .

O t r o s ab io consejo que s i r v a de co ro la r io lo ex t r aemos d e l p r i n c i p i o de i n c e r t i d u m b r e (de los r equer imien tos ) : -mientras mas grande el cambio funcional, menos precisos son los requeri-mientos- [ H u m p h r e y 1989]. Y eso es e n s i u n a invitación a l m a -nejo de configuración, e n es t a tes is p r o m o v i d o y c o m p l e m e n t a d o c o n i d e a s prácticas y reales que u n líder de p royec to r e c o m i e n -d a .

9{acfio Martínez

Septiembre de 1996

6 9

A A P É N D I C E S

A - l De la Empresa

Empresa Tecnológica Ericsson es u n cen t ro de de sa r ro l l o de sof tware p a r a e l sec tor t e l e c o m u n i c a c i o n e s l oca l i zado e n S a l t i l l o , C o a h u i l a . S u p l a n t i l l a es c e r c a n a a los 2 5 0 p e r s o n a s de lo s c u a -les e l 9 0 % s o n ingen ie ros e n electrónica, s i s t e m a s o c o m u n i c a -c i o n e s .

F u e f u n d a d a e n l a c i u d a d de México a fines de 1 9 8 5 p o r l a m a t r i z s u e c a L M Ericsson c o n visión a fu turo , p a r a u n México ab ie r to y compe t i t i vo . F u e d e s c e n t r a l i z a d a a S a l t i l l o e n 1 9 9 1 .

T e n i e n d o c o m o guía el P ro fe s iona l i smo , Respe to y Pe r se -v e r a n c i a , va lo r e s que f u n d a m e n t a n a l a firma E r i c s s o n ; E m p r e -s a Tecnológica E r i c s s o n t iene c o m o m e t a conver t i r se e n u n o de l o s mejores 5 cen t ros de desa r ro l lo de software e n e l m u n d o E r i c s s o n .

E l c a b a l l o de b a t a l l a de L M E r i c s s o n es s u c e n t r a l d i g i t a l electrónica A X E 1 0 , l a c u a l es u n a c o m p u t a d o r a m o d u l a r c o n t r o -l a d a p o r u n p a r de p rocesadores r e d u n d a n t e s que h a c e n l a s ve-ces d e l ce rebro (CPU), los cua l e s c o n t r o l a n u n a ser ie de p r o c e s a d o r e s reg iona les r e d u n d a n t e s (has ta 1024 p r o c e s a -dores) , m i s m o s que f o r m a n l a s p i e r n a s y b r a z o s d e l A X E 1 0 . L a s a n g r e que d a v i d a a todos s u s p rocesos de conmutación e in t e -l i g e n c i a , es e l software. Sof tware que se d e s a r r o l l a e n 19 cen t ro s de diseño a lo la rgo de l m u n d o , exper tos e n c ie r t as áreas d e l A X E .

7 0

De su producto

E r i c s s o n S a l t i l l o , c o m o se le d e n o m i n a a lo la rgo de e s t a t es i s , p r o d u c e es tos paque tes de software d e s a r r o l l a d o s e n u n lengua je de a l to n i v e l 1 3 p rop io de s u s cen t ra les telefónicas. E s -tos p a q u e t e s c o m p r e n d e n :

(a) Documentación asociada.

(b) El código como tal.

(c) Las pruebas individuales y del sistema.

(d) Los registros de calidad de dicho software.

E l sof tware allí p r o d u c i d o c u b r e d iversos a spec tos de l a telefonía, es dec i r :

(a) Operación y Mantenimiento (interno de las centrales y la red)

(b) Señalización (CCS, CAS, MIS41, ISUP)

(c) Facilidades para abonados (e.g. 911, desvío de llamadas)

(d) Facilidades para abonados de negocios (e.g. conexión y ampliación de los P B X a la red pública)

(e) Administración de la red de telefonía celular

(f) Servicio a Tráfico (e.g. recepción/transmisión de dígitos, voz, datos)

(g) Control de Tráfico (e.g. análisis de dígitos y enrutamiento)

(h) Operación y Mantenimiento (interno de las centrales y la red)

(i) Tasación (e.g. cobro de llamadas y servicios)

13. Desarrollado por y para Ericsson

71

Aquí se d e s a r r o l l a desde l a investigación, el desa r ro l lo , l a s p r u e b a s y liberación de d i c h o s p r o d u c t o s . E n E m p r e s a Tecnoló-g i c a E r i c s s o n , se desarrolló el p r i m e r se rv ic io 8 0 0 de E r i c s s o n , e l p r i m e r 9 1 1 y se continúa pe r fecc ionando e l " roaming" , r as t reo y "handover" de ce lu la r , que tan to éxito financiero h a n d a d o a E r i c s s o n a n i v e l m u n d i a l .

C o m o dato in te resan te , más de l 3 0 % de l a s l l a m a d a s c e l u -l a r e s d e l p l a n e t a se h a c e n a través de equ ipo E r i c s s o n .

P o r se r u n p r o d u c t o e n s u mayoría de exportación ( E U A , Canadá, E u r o p a , México), t an to l a p r o d u c t i v i d a d y c a l i d a d e n -t r e g a d a s o n de c lase m u n d i a l .

E r i c s s o n S a l t i l l o , fue ce r t i f i cada e n 1994 e n ISO9000 y Tic-k l T 1 4 p o r Bureau Veritas Quality International de México (BVQI), y es-p e r a e n u n fu tu ro ce rcano (1997) l og ra r e l Premio Nacional de Cal idad.

E r i c s s o n S a l t i l l o p r o d u c e a n u a l m e n t e :

• Alrededor de medio millón de líneas de código (500,000 KLOC) .

• Con un costo de más de trescientas mil horas hombre (400,000 mh).

• Con una densidad de fallas de 1 error por cada 10,000 líneas de código.

• Logra ventas superiores a los 20 millones de dólares, por el concepto exclu-sivo de desarrollo de software.

14. T ick IT es certificado que amplia la norma ISO9001 para empresas de Tecnología de Información.

72

A-2 Modelo de Madurez (CMM)

E l m o d e l o de m a d u r e z (del Inglés C a p a b i l i t y M a t u r i t y M o -de l , p o r s ig l a s CMM) es e l r e su l t ado de u n proyec to de l a F u e r z a A r e a N o r t e a m e r i c a n a rea l i zado p o r el Software Engineering Institu-te (SEI) de l a U n i v e r s i d a d Carnegie Mellon.

S u objet ivo p r i n c i p a l e r a proveer guías a l ejercito p a r a po-d e r s e l e c c i o n a r proveedores de software competen tes . E l método r e s u l t a n t e p a r a e v a l u a r fuerzas y deb i l i dades h a p r o b a d o se r v a -l i o so p a r a e v a l u a r c u a l q u i e r a organización de software.

E l CMM en tonces es u n a aplicación c o n sentido-común de l o s c o n c e p t o s mane jo-de-procesos y me jo ra s -de -ca l i dad , enfoca-d o s a l d e s a r r o l l o y m a n t e n i m i e n t o de software. E s u n m o d e l o evo lu t ivo p a r a t r a n s f o r m a r o rgan izac iones , e n p roveedores p re -fer idos de p r o d u c t o s de software.

Posee además u n a e s t r u c t u r a firme p a r a e v a l u a r e l CMM de m a n e r a conf iab le y cons i s t en temen te . E s t a e s t r u c t u r a c o n s t a de c i n c o (5) n ive les de m a d u r e z de p rocesos (ver F i g u r a 10. e n pág. 74) .

E s t a s e c u e n c i a debe ser r espe tada , de t a l m a n e r a que u n a organización n o puede esca la r a l s igu ien te n i v e l s i n an tes h a b e r c o n s e g u i d o sólidamente, los n ive les p rev ios .

73

O p t i m i z a n t e

C o n t r o l de P roceso

A d m i n i s t r a d o

Medición de P roceso

Def in ido

Definición de P roceso

Repe t ib le

C o n t r o l A d m i n i s t r a t i v o Básico

Figura 10. Niveles de Madurez de Proceso

L o s n ive les se p u e d e n r e s u m i r c o n c e p t u a l m e n t e e n lo s s i -gu ien te :

1. INICIAL. Mientras los procesos no estén bajo control estadístico, una mejo-ra de estos no es posible.

74

I n i c i a l

2. REPETIBLE. La organización ha alcanzado un proceso estable con niveles repetibles de control estadístico a través de un riguroso manejo de proyec-tos, compromisos, costos, tiempos y cambios.

3. DEFINIDO. La organización ha definido el proceso como base para una consistente implantación y entendimiento. En esta etapa, tecnología de pun-ta puede ser útilmente introducida.

4. ADMINISTRADO. La organización ha iniciado un amplio análisis y medi-ción del proceso. Aquí, es cuando las mejoras de calidad mas significativas pueden empezar.

5. OPTIMIZANTE. La organización una base para mejorar continua y optimización del proceso.

L a s igu ien te t a b l a (ver T a b l a 2 . e n pág. 76) r e s u m e e l e n -foque q u e se o b s e r v a e n l as o rgan izac iones a l se r a u d i t a d a s , es d e c i r a q u e l l a s características que rápidamente se o b s e r v a n e n l a s e m p r e s a s así, c o m o l a s áreas de p roceso c laves que d e b e n sos t ene r se c o n p r u e b a s i r refutables de que se está e n c ie r to n i -v e l p a r t i c u l a r , es decir , aque l l a s ac t iv idades que d e b e n d o m i n a r -se p a r a p o d e r ob tener n ive les de m a d u r e z supe r io re s .

E l gob ie rno de los E s t a d o s U n i d o s p ide c o n t r a t a r sólo a q u e l l a s e m p r e s a s desa r ro l l ado ra s de software que p o s e a n c o m o mínimo e l n i v e l t res . P o r lo c u a l , h o y e n día e l m o d e l o de m a d u r e z ( C M M ) rápidamente se es ta c o n v i r t i e n d o e n l a n o r m a de l a i n d u s t r i a (de software).

Se inf iere c o n cer teza que los P r o c e s o - C l a v e s o n en tonces c o n s i d e r a d o s guías p a r a a scende r e n el mode lo .

7 5

Nivel Enfoque Areas de Procesos Clave

I n i c i a l Héroes

R e p e t i b l e M a n e j o de P r o y e c t o s P r o c e s o de C o m p r o -m i s o

M a n e j o de R e q u e r i m i e n t o s Planeación de P r o y e c t o s de Sof tware S e g u i m i e n t o de P r o y e c t o s de Soft-w a r e M a n e j o de S u b c o n t r a t i s t a s de Soft -w a r e A s e g u r a m i e n t o de C a l i d a d de Soft-w a r e M a n e i o de Configuración de Sof tware

D e f i n i d o P r o c e s o I n g e n i e r i l D e f i n i d o

E n f o q u e e n p r o c e s o s e n l a O r g a n i z a -ción Definición de P r o c e s o s e n l a O r g a n i -zación M a n e j o In tegra l de sof tware Ingeniería de P r o d u c t o de So f tware Coordinación I n t e r g r u p a l P r o g r a m a de E n t r e n a m i e n t o R e v i s i o n e s en t re C o l e g a s

A d m i n i s t r a d o C a l i d a d de P r o d u c t o y P r o c e s o

M a n e j o C u a n t i t a t i v o de P r o c e s o s M a n e j o de C a l i d a d de Sof tware

O p t i m i z a n t e M e j o r a C o n t i n u a de P r o c e s o s

Prevención de Defec tos M a n e j o de C a m b i o de Tecnología M a n e j o de C a m b i o de P r o c e s o s

Tabla 2. Procesos Clave Requeridos por Nivel C M M

D e l a t a b l a p o d e m o s obse rva r lo s igu ien te (subrayados) :

7 6

(a) El Manejo de Requerimientos y el Manejo de Configuración (CM) son indispensable para aspirar y sostener el nivel 2.

(b) Estos mismos rubros deben estar muy sólidos para aspirar al nivel tres, es decir, el manejo de requerimientos y configuración debe ser sistemático y establecido en procedimientos, de manera que los re-sultados sean predecibles y repetibles una y otra vez. Nada de sor-presas.

77

A-3 Bitácora de Cambios

L a bitácora de c a m b i o s es u n a b u e n a práctica que hace e l t rabajo de l a d m i n i s t r a d o r de c a m b i o s , más senc i l lo de l levar. C l a r o que e x i s t e n h e r r a m i e n t a s de s i s t emas que hace este t r a -bajo, pero e n este caso n a d a m a s práctico que lápiz y pape l . C u -r i o s a m e n t e e n e l m u n d o de l software, e l viejo refrán a p l i c a m u y b i e n {-en casa del herrero cuchara de palo-) e n e l sen t ido de que es t a n c o t i d i a n o y exube ran te e l t rabajo c o n p r o g r a m a s y s is te-m a s de información, que las pe r sonas t i e n d e n a o lv ida r a l g u n a s b u e n a s prácticas de l a v i d a rea l , c o m o e l lápiz y e l pape l .

E l s igu ien te es u n macho t e de u n a bitácora:

Proyecto A, Bitácora de Cambios

Número Dónde

se Encontró Acción Responsable Estado

1

2

•

n

Autor Fecha

Revisión

Tabla 3. Machote de Bitácora

U n a bitácora c o m o ésta puede hacerse más o m e n o s c o m -ple ja , s i n embargo se r e c o m i e n d a tener u n mínimo de c o l u m n a s

78

c o m o e n l a T a b l a 3 . e n pág. 78 , y a que l a práctica n o s i n d i c a c con t i ene los e l emen tos cen t ra les de aque l lo que r ea lmen te qu ie re c o o r d i n a r .

E l c o n t e n i d o de c a d a c a m p o es c o m o s igue :

1. Número. Es un consecutivo al cual es fácil referirse cuan-do se le da seguimiento.

2. Dónde se Encontró. Es el día, el nombre de la junta, la persona, el documento o comité donde una inconsisten-cia fue encontrada.

3. Acción. Es la acción inicial propuesta y se va actualizan-do conforme se tenga mas información

4. Responsable. Aquel que tiene la autoridad o capacidad para darle solución al problema. Se recomienda que solo sea una persona.

5. Estado. El estado en que la inconsistencia se encuentra. Se recomiendan los siguientes 3 estados:

-Abierto. Aún sin definirse.

-Cerrado. Solución determinada e im-plantada. Se recomienda sellar este es-tado con la fecha.

-Cancelado. Se decidió no hacer mas, sea porque fue solo una confusión o el proyecto decidió no implantar. Se reco-mienda sellar este estado con la fecha.

6. Autor. Debe ser el administrador de cambio. Esta activi-dad no debe delegarse.

7. Fecha. Siendo un documento vivo, es decir, que cambia periódicamente (cada semana por ejemplo) es importan-te tener una referencia de tiempo.

79

8. Revisión. Como la bitácora se publica periódicamente, es importante saber qué revisiones son preliminares y cuá-les finales (publicadas).

E n e l caso d e l proyecto P 8 B m (ver Imagen 5. e n pág. 52), a p r e c i a m o s u n a ser ie de reng lones s o m b r e a d o s , es tos i n d i c a n cuándo u n a acción y a h a s ido ce r rada . E s t a m o d a l i d a d u o t r a p a r e c i d a se r e c o m i e n d a c u a n d o , e l número de acc iones es t a l q u e a l g u n a s p u d i e r a n perderse v i s u a l m e n t e sobre todo s i n o se h a n ce r r ado desde hace algún t i empo . E n e sa m i s m a i m a g e n se a p r e c i a rápidamente, l a acción que no h a s ido c e r r a d a y que p o r lo t an to es u n r iesgo a p u n t o de conver t i r se e n p r o b l e m a .

L a bitácora de P 8 B m prefirió u s a r e l número de d o c u m e n -to e n l u g a r de u n número consecu t ivo , pero eso es l i b e r t a d d e l p r o p i o a d m i n i s t r a d o r de c a m b i o s .

8 0

A-4 Plan de Configuración

E l s i gu i en t e es u n esqueleto suger ido , p a r a h a c e r u n p l a n de configuración s i m i l a r a l u t i l i z a d o p o r P 8 A m .

Se r e c o m i e n d a que e l d o c u m e n t o l leve l a s firmas d e l a u -tor, e l líder de p royec to y o p c i o n a l m e n t e l a firma de verificación d e l gerente de línea o de r e sponsab le de c a l i d a d .

1. Información de revisión

donde se describen los cambios más re-cientes a este documento como tal.

2. Introducción

donde se habla en pocas líneas, del pro-pósito del proyecto de diseño, así como de los posibles clientes y la base de di-seño.

2.1. Propósito

donde se habla de la intención de éste plan.

e.g. Este plan tiene la intención de lle-var el control del estado de los produc-tos y controlar cuidadosamente los requerimientos fuente al identificar la base funcional y prevenir cambios no autorizados

81

3. Alcance

donde se indican los productos que cu-bre, durante qué periodo y lista las prin-cipales tareas a realizar.

e.g.

-identificar la base.

-congelar la base cuando los requeri-mientos sean estables.

-analizar y aprobar los cambios a la base.

-mantener la bitácora actualizada.

4. Organización y roles

donde se listan los roles, sus responsa-bilidades y preferiblemente se indica el nombre y/o siglas de la persona o comi-té con dicha responsabilidad.

4.1. Responsabilidades del Coordinador

donde se indican las responsabilidades del coordinador.

4.2. Productos a ser controlados

donde se listan los productos que serán controlados.

Se recomienda listar aquellos productos en forma genérica. p o

-diagramas de flujo

-código

8 2

-discos

-descripciones

5. Actividades

donde se describen brevemente las acti-vidades a realizarse.

5.1. Control de Cambios

se indica el proceso a seguir para llevar el control de cambios.

5.2. Bitácora

se indica qué objetos deben allí estar in-cluidos y la frecuencia con que éste re-porte debe ser emitido y por quién.

5.3. Documentación

donde se indican las librerías (bases de datos) donde se deberán almacenar los productos.

6. Referencias

donde se listan las referencias a los pro-cesos y políticas oficiales o temporales, consideradas válidas para la ejecución del plan.

83

A-5 Experiencia

E n m i c a r r e r a p ro fes iona l he s ido diseñador, i nves t i gado r de r e q u e r i m i e n t o s y p r o b a d o r de software p o r más de 3 años, s i n e m b a r g o d o n d e m a y o r sa t i s facc iones y l ecc iones he a p r e n d i -do es c o m o líder de proyec to .

L o s 6 años que ded ique a este t rabajo de a d r e n a l i n a y es-t r a t eg i a p u r a , h a n s ido u n bas to c a m p o de experimentación, allí aprendí cómo e l software es t a d o m i n a d o e n g r a n m e d i d a p o r e l fac tor h u m a n o , cómo u n a minoría de p r o d u c t o s o a c c i o n e s e q u i -v o c a d a s p u e d e n a r r u i n a r p royec tos enteros , y cómo e l l ide razgo r e a l m e n t e t iene u n efecto d i rec to sobre el éxito o f racaso de u n p royec to .

M i s p r i m e r o s proyec tos (menores de 5 ,000 horas) caí e n l a t r a m p a de h a c e r l a s veces de líder, diseñador, inspec to r , p r o b a -d o r y l i m p i a d o r , e n fin, u n m u l t i c h a m b a s nova to .

M i s p royec tos m e d i o s (menores de 2 0 , 0 0 0 horas) fue ron de e x p e r i e n c i a s c o m o líder. Aprendí a l l evar u n a presión e x t e r n a e n n a d a r e l a c i o n a d a c o n e l p r o d u c t o e n s i , p o r e jemplo l a p re -sión de u n c l ien te desconf iado; también viví l a g r a t a pero a n g u s -t i o s a sue r t e de t raba ja r c o n novatos , i .e. diseñadores recién s a l i d o s de l a u n i v e r s i d a d , pero c o n u n a n s i a de m o s t r a r s u s c a -p a c i d a d e s (v i r tud exce l sa entre los c a m p e o n e s de software).

M i s p royec tos g randes (mayores de 2 5 , 0 0 0 horas) y a c o n l a m a d u r e z , m e p e r m i t i e r o n d i s f ru ta r de l a navegación, a h o r a l o s p l a n e s c u a d r a b a n y los p r o b l e m a s y a no e r a n s o r p r e s a s s i n o r i e sgos p r ev i s i b l e s . N o es que no h u b i e r a n esco l los , pe ro y a n o o c a s i o n a b a n confusión n i caos .

84

M i s últimos proyec tos c o m o líder, c o n t r i b u y e r o n a l l eva r a E r i c s s o n S a l t i l l o a l tercero y p r i m e r l u g a r e n c a l i d a d de software e n lo s años d e l 9 4 y 9 5 respec t ivamente . E s t o es, los número 1 (1995) de 19 cen t ros de desa r ro l lo de software de l m u n d o E r i c s -s o n , c o n u n a d e n s i d a d de fal las once fal las p o r c a d a 1 0 0 , 0 0 0 lí-n e a s de código.

A p a r t i r de 1995 , los s u b s e c u e n t e s p royec to m e h a n t o c a -do desde u n frente diferente, y a no c o m o líder de proyec to , s i n o c o m o gerente de diseño. E l reto a h o r a , es m a n t e n e r todos lo s p royec to s de l a ge renc ia den t ro de los mejores de l m u n d o E r i c s -s o n . C o n u n a m e t a agres iva p a r a 1998 de, 4 fa l las p o r c a d a 1 0 0 , 0 0 0 líneas.

8 5

B B I B L I O G R A F Í A

[Bentley, 88] Bentley, Jon. More Programming Pearls. confessions of a Coder. Ed. Addison-Wesley. lst edition. New Jersey. 1988

[Boehm, 81] Boehm, Barry. Software Engineering Economics. Ed. Prentice Hall, lst edition. USA. 1981

[Brooks, 95] Brooks, Frederick. The mvthical Man-month. Ed. Addison-Wesley. Anniversary edition. USA. 1995

[Buckley, 95] Buckley, Fletcher. Implementing Configuration Management. Hardware. Software and Firmware. IEEE Press. 2nd. edition. USA. 1995

[Chiavenato, 89] Chiavenato, Idalberto. Introducción a la Teoría General de la Administración. McGraw Hill . 3a. edición. México. 1989

[Dart, 92] Dart, Susan A. The Past. Present and Future of Configuration Management. Software Engineering Institute/Carnegie Mellon Uni-versity. CMU/SEI-92-TR-8. Pittsburg. 1992

[De Boer, 93] De Boer, Reino. "Computer Aided Requirements". Tesis de maestría. Erasmus Universiteit. Rotterdam. 1993

[Demarco, 87] Demarco, Tom. Peopleware: Productive Projects and teams. Ed. Dorset-House, lst edition. New York. 1987

[Deutsch, 93] Deutsch, Michael. "Managing SW Projects: Controlling Risks and Adversities". Seminar, University of California, Berkeley. 1993

[Humphrey, 89] Humphrey, Watts. Managing the Software Process. Ed. Ad-dison-Wesley. lst edition. New Jersey. 1989

86

[Humphrey, 95] Humphrey, Watts. A Discipline for Software Engineering. Ed. Addison-Wesley. lst edition. New Jersey. 1995

[IEEE, 94], IEEE Computer Society. "IEEE Standard Glossary of Software Engineering Terminology". IEEE Inc. 1994 edition. New York. 1994

[IEEE-1042, 93] IEEE/ANSI, Standard 1042-1987. "IEEE Guide To Soft-ware Configuration Management". IEEE Inc. New York. 1993

[IEEE-830, 94] IEEE, Standard 830-1993. "IEEE Recommended Practice for Software Requirements Specifications". IEEE Inc. New York. 1994

[ISO9001, 94] ISO9001:1994(E). International Organization for Standariza-tion. Quality Systems-Model for quality assurance in design. devel-opment, production, installation and servicing. ISO. 2nd edition. Switzerland. 1994.

[Glass, 92] Glass, Robert. Building Quality Software. Ed. Prentice Hall, lst edition. New Jersey. 1992

[Karolak, 95] Karolak, Dale. Software Engineering Risk Management. Ed. IEEE, lst edition. USA. 1995

[SEL, 94] SEL. Software Measurement Guidebook. NASA/Goddard Space Flight Center. SEL-94-002. Maryland. 1994

[SEL, 95] SEL. Software Process Improvement Guidebook. NASA/God-dard Space Flight Center. SEL-95-002. Maryland. 1995

87

Puente Tacoma Narrovvs

E l nuevo puente, abrió sus puertas el 14 de Octubre de 1950 después de 29 me-ses de construcción. Tiene una longitud de 1790 metros.

88