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 MONTERREY
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
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
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
iii
Dedicado a:
Mi esposa Catalina por su paciencia, A Nachito por su admiración,
A Catita por mandarme a clases,
A Vivid por bebé.
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 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 adelante referi- do c o m o software indistintamente) se enfocan a satisfacer 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 cliente. P o r lo tanto, 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, sobreentendemos l a n a t u r a - leza 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 necesidades e x p r e s a d a s p o r el c l i e n t e / u s u a r i o , s i n embargo, poco reconoce- m o s , de s u precisión y defectibilidad real y m e n o s d e l aspecto dinámico q u e 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 el 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 el u s u a r i o generalmente 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 parecido 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 el u s u a r i o .
E n a q u e l entonces, 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 "sistema", y éste p o r lo general se conte- nía e n a l g u n o s cientos 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 inteligencia q u e l o s fuerza i n - h e r e n t e m e n t e a "expandirse" geométricamente e n c o m p l e j i d a d .
Simultáneamente, el manejo de r e q u e r i m i e n t o s h a evolu- c i o n a d o . S u elaboración, recopilación, control, documentación y rastreo se h a n vuelto u n a d i s c i p l i n a ingenieril.
E l manejo de requerimientos es f u n d a m e n t a l e n el éxito de u n p r o d u c t o de software, pero h o y e n día, donde 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
se convierte e n u n a h a b i l i d a d necesaria 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 podido 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 las fases de desarrollo o construcción, se están j u g a n d o u n a c a r t a peligrosa p a r a s u s u b s i s t e n c i a .
A n t e s , el cliente podía esperar a que el s i s t e m a fuera c o m - pleto, p r o b a d o y reconocía que el s i s t e m a sería d e p u r a d o (léase corregido) a lo largo de las fases iniciales de operación. E s o era posible, 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" sistemas. H o y , el cliente 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 , precio y tiempo de e n - trega 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 software esta o b l i g a d a p o r las c i r c u n s t a n c i a s a proveer s o l u - ciones precisas, rápidas y l i m p i a s mejor que el resto.
L o s proyectos actuales de software están afectados p o r el a m b i e n t e externo. 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 que s u c e d e e n el exterior y de no aceptar 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 , puede per- der 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 vitali- z a r los proyectos y n o enfermar o corromperlos. E s decir, los c a m b i o s d e b e n verse c o m o posibilidades de mejora y n o c o m o detractores de éxito.
A diferencia de otras actividades ingenieriles d o n d e l a pre- cisión y l a métrica d o m i n a n , el software posee ciertas v i r t u d e s subjetivas e indirectas, inherentes solo a las actividades "creati- vas" d e l h o m b r e y estas s o n las más difíciles de p e r c i b i r y c o n - trolar.
E n l a siguiente figura (ver F i g u r a 1. e n pág. 4) t o m a d a del Software E n g i n e e r i n g L a b o r a t o r y1 de l a N A S A [SEL, 1995] pode- m o s extrapolar el m i s m o p r o b l e m a , e n otros proyectos se soft- ware, donde los resultados s o n similares 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 requerimientos, pero sobre todo de s u s c a m - bios. L a figura pretende ser u n ejemplo ilustrativo solamente.
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 NASA y fue creado en 1976 para investigar la efectividad de las tecnologías de software en proyec- tos de desarrollo de software.
1.1 Descripción del problema
E n m i c a r r e r a profesional he sido diseñador, investigador 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 satisfacciones y lecciones he a p r e n d i d o es, c o m o líder de proyecto.
E n b a s e a m i experiencia como líder de proyectos 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 frecuentemente se p a s a n p o r alto e n los proyectos de desarrollo, y n o p o r falta de reconocimiento, sino 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 el 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 las fase de desarrollo de u n p r o d u c t o de software.
P o r u n lado, e n los proyectos donde no existe t a l c o n t r o l , el logro de estos c a m b i o s reside netamente 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 del líder del proyecto.
P o r otro, e n aquellos proyectos donde existe el c o n t r o l de c a m - b i o s , este depende de l a objetividad y criterio del líder de c a m - bios.
E n t o n c e s decidí p a r a el objeto de esta tesis, a b o r d a r el p r o b l e m a de cómo realizar este c o n t r o l de c a m b i o s e n proyectos de desarrollo de u n a m a n e r a pragmática y real, e n c i m a de los procesos y a preestablecidos, excluyendo aquellos c a m b i o s ante- riores o ulteriores a l desarrollo, t o d a vez que estos c a e n e n l a de- finición y establecimiento de nuevos proyectos o d e l m a n t e n i m i e n t o propio del producto.
E n f o r m a gráfica, trataremos c o n el 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 las fases centrales del ciclo de v i d a del p r o -
d u c t o i.e. l a d e l desarrollo. 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 recomendaciones l a s p u s e e n práctica e n d o s pro- yectos recientes. E l p r i m e r proyecto fue l a p r i m e r a vez q u e se p u s o e n f u n c i o n a m i e n t o , y e n el segundo se corrigieron o mejo- r a r o n l a s acciones q u e n o p u d i e r o n a d e c u a d a m e n t e ejecutarse e n e l p r i m e r o .
Figura 2. Ciclo de vida típico de un producto de software
N o es que no e x i s t a n e n el m e r c a d o b a s t a s y complejas h e r r a m i e n t a s p a r a realizar este trabajo, no es que el concepto s e a novedoso e n s i , t o d a vez que distintos estándares h a c e n h i n - capié e n el debido control. S i n embargo y parafraseando 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 requerimientos entonces se c o m - p l i c a , p o r l a falta de u n proceso ingenieril, l a falta de a d r e n a l i n a e ingenio d e l líder, ó del agobio por l a excesiva b u r o c r a c i a e n el proceso m i s m o , y p o r lo tanto, compromete el éxito de los pro- yectos.
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 efectiva d u r a n t e l a e t a p a de desarrollo 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 el efecto negativo que estos causarían de no contro- larse?.
¿Qué r e c o m e n d a c i o n e s prácticas puede u n líder de pro- yecto obtener de l a presente?
1.3 Descripción del Contenido
L a tesis se e s t r u c t u r a de l a siguiente m a n e r a :
- 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.
2 REVISIÓN B I B L I O G R Á F I C A
L a s necesidades d e l cliente p u e d e n ser f o r m u l a d a s a t r a - vés de requerimiento(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 entre el cliente y l o s diseñadores de ese software.
E n t o n c e s , se p r e s u m e directamente, que el éxito de u n s i s t e m a p u e d e ser m e d i d o , por qué t a n b i e n los r e q u e r i m i e n t o s reflejan l a s necesidades d e l cliente 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 el cliente reflejan las necesidades reales y p o r qué t a n b i e n éste c u b r e tales d e m a n d a s .
L o s objetivos de este capítulo serán aquellos de definir lo q u e se entiende p o r "requerimientos", las diferentes clases, lo q u e se entiende p o r u n a "especificación de requerimiento" y p o r
"control de c a m b i o s " .
2.1 Requerimientos
E n el m u n d o de l a programática, el argot h a tenido 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 el m i s m o significado o u n solo significado. 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 el inglés, que p o r decirlo 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 significado que e n el argot 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 definiciones que l a IEEE, e n es- pecífico a q u e l l a s descritas e n el "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].
Requirement:
(1) A c o n d i t i o n or capability needed b y a u s e r to solve a p r o b l e m or achieve a n objective.
(2) A c o n d i t i o n or capability that m u s t be m e t or 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 satisfy a contract, s t a n d a r d , specification, or other formally 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 representation o f a c o n d i t i o n or c a p a b i l i - ty a s i n (1) or (2).
E s t a s 3 definiciones contienen (resumen) algo, de l a c u l p a i n d i r e c t a de l a s fallas c o n el manejo de requerimientos. P o r ejemplo, e n l a p r i m e r a (1), solo se h a b l a d e l "usuario", m i e n t r a s que el "cliente" h a sido excluido, 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 considerado, toda 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 llegue a conocer a l u s u a r i o . D o n d e el cliente es q u i e n negocia o paga y e l u s u a r i o es solamente q u i e n físicamente interactúa c o n el sistema, s e a o n o e l propie- tario. Así q u e n o necesariamente estas dos personas c o n c u e r - d a n entre lo q u e se requiere, se facilita o aporta u n s i s t e m a .
L a s e g u n d a (2), digamos que se q u e d a corta e n el sentido m o d e r n o (último l u s t r o d e l siglo), e n el sentido de q u e habrá o c a s i o n e s e n que el diseñador e n r i q u e z c a o supere l o s requeri- m i e n t o s d e l cliente y c o n ello logre u n a ventaja competitiva; sí, e n p r i n c i p i o los requerimientos deben ser estrictos, pero lo úni- co estricto es lo conocido; 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 las limitaciones estrictas. C u a n d o e l cliente, e l u s u a r i o o el diseñador, se d a n c u e n t a q u e se p u e d e b r i n c a r u n a frontera, rápidamente se desea establecer u n n u e v o requerimiento, surgiendo c o n esto l a dificultad de c o n t r o l a r es- tos "cambios" e n los proyectos de desarrollo vigentes.
2.2 Especificación de Requerimientos
T o m a n d o l a definición del "Software E n g i n e e r i n g T e r m i - nology" [ I E E E , 1990].
Requirement Specification:
A d o c u m e n t tha t specifies the requirement s for a s y s t e m or c o m p o n e n t . Typically i n c l u d e d are f u n c t i o n a l require- m e n t s , performance requirements, d e s i g n r e q u i r e m e n t s , interface r e q u i r e m e n t s a n d development s t a n d a r d s .
E n s u sentido más amplio, l a especificación de u n a enti- d a d es: l a descripción de esa entidad.
E n l a mayoría de los casos u n a especificación será u n a descripción de los atributos 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 tipos de especifica- ciones p o r el u s o que se les pretenda 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 entender 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 crear 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 tipos de especificación e n l a m i s - m a especificación de requerimientos, s i n embargo esta tesis se enfoca e n el manejo y c o n t r o l de los requerimientos p r e s c r i p - tivos, precisamente por l a dificultad de representar y crear algo que aún n o existe.
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 hechos y s u s fechas, que preverla.
E s t a m i s m a analogía n o s despierta l a imaginación y n o s deja rápidamente presentir l a dificultades que u n desarrollo de software 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 serie de u n software y a existente, probado y rentable.
F o c a l i z a n d o e n los requerimientos de software [ I E E E , 1990]:
Software Requirement Specification (SRS):
D o c u m e n t a t i o n of the essential r e q u i r e m e n t s (functions, performance, design constraints, a n d attributes) of the software a n d its external interfaces.
Así, los p r i n c i p a l e s tópicos que los escritores 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 son:
- F u n c i o n a l i d a d : ¿Qué se supone que hace?
- Interconexiones externas: ¿Qué interacciones tiene c o n h u m a - nos, equipos periféricos, y otros sistemas de software?
- Desempeño: Velocidad y tiempos.
- A t r i b u t o s : i n t e r n o s y externos, e.g. seguridad, 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 externas, e.g. m e m o r i a , lenguaje.
2.2.1 Características
L o s requerimientos describen cosas, entidades; c o m o tal, t i e n e n u n a serie de características necesarias y / o deseables que p e r m i t a n s u validez 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 casos análogas a aquellas que contiene l a información ve- raz.
L a s especificaciones de requerimientos de software (SRS) p a r a s e r útiles d e b e n tener l a s siguientes 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 correcta 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 q u e el 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 tanto el cliente, e l diseñador, el equipo de inspección y p r u e b a , el equipo de a s e g u r a m i e n t o de c a l i d a d , deben tener l a m i s m a interpreta- ción. U n a especificación es c l a r a c u a n d o tiene sólo u n a interpre- tación.
Completa
U n a especificación debe d e s c r i b i r todos l o s a t r i b u t o s rele- v a n t e s de l a e n t i d a d q u e se especifica. C o m o esto es m u y difícil de c u m p l i r y a q u e tendemos a sobre-especificar, r e q u e r i m o s l a siguiente característica.
Precisa
U n a especificación n o debe especificar más de lo n e c e s a - rio, p a r a llegar a entender l a e n t i d a d especificada.
Consistente
D e b e tener c o n s i s t e n c i a i n t e r n a , i.e. no debe tener c o n t r a - d i c c i o n e s dentro de l a m i s m a , n i c o n t r a especificaciones supe- riores, c o m o p o r ejemplo 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 pierde 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 inversiones e n tiempo p a r a clarificar y a c o r d a r c o n t o d a s las partes (usuario, cliente y diseñador) c u a l especifi- 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 todas las especificaciones que están e n conflicto.
Verificable
C o m o l a especificación de requerimientos (SRS) será u t i l i - z a d a p a r a verificar que el producto final satisface los requeri- m i e n t o s , debe existir u n proceso c o n el c u a l se c o m p r u e b e que el 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 verificable sí y solo sí c a d a requerimiento asentado es verifica- ble.
E j e m p l o de requerimientos no verificables s o n aquellos subjetivos como: - m u y rápido-, -amigable-, -bonito-.
Utilidad
U n a especificación debe ser útil. Debe servir tanto c o m o contrato c o n el cliente, como u n a base p a r a el diseño. C o n s e - c u e n t e m e n t e , l a especificación debe ser escrita de m a n e r a t a l que:
- el cliente 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
- el e q u i p o de diseño, e n t i e n d a las i m p l i c a c i o n e s de l a especifi- cación y
- que h a y a u n a suave transición de l a especificación h a c i a el 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 el h e c h o de que ésta resulte e n u n diseño r e a l i n m e - diato. E n m u c h a s ocasiones 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 promotores de otras especificaciones que sí se m a t e r i a l i z a n e n diseños reales o e n patentes.
Modificable
U n a especificación debe ser escrita de t a l m a n e r a que per- m i t a c o n s i d e r a r n u e v a s entidades o l a modificación de l a s exis- tentes.
T o d o s los que vivimos diseñando software, quisiéramos que esta 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 sido el p r o m o t o r de esta 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 los líderes de proyecto, diseñadores, inspectores y p r o b a d o r e s , y a que e n u n a b r i r y cerrar 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 requerimientos de software (SRS) p u e d e d e s e n c a d e n a r u n a serie costosa de c a m b i o s y ajus- tes a los proyectos. U n a especificación puede c a m b i a r todo lo que 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 el m o m e n t o pre- ciso e n que u n proyecto vivo esta trabajando c o n ella.
C u a n d o u n a modificación a u n a especificación es acepta- d a , forzada o i n t r o d u c i d a a u n proyecto e n proceso 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 devastadoras a m e n o s que se lleve u n c o n t r o l preciso e ingenieril 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 por 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 arquitecto, q u i e n p l a s m a l a s ideas d e l cliente e n u n a serie de p l a n o s (requerimientos). E s - tos p l a n o s p r e t e n d e n reflejar las ideas expuestas p o r el cliente.
S i todo fuera ideal l a c a s a debiera c o n s t r u i r s e conforme a lo que los 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 llega 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 gracias a que u n m u r o completo estorba el paso de l a l u z solar; qué p a s a c u a n d o el baño requiere m o v e r los grifos a u n a a l t u r a que los niños a l c a n c e n , c u a n d o y a todo el m o s a i c o esta i n s t a l a d o .
Igual e n el 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 claros será más fácil r e a l i z a r el p r o - yecto, s i n embargo, u n a serie de eventualidades, mejoras 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 requerimientos o a l a s especificaciones de función. E s t o s c a m b i o s de no ser controlados e n el sentido téc- n i c o y de implantación, p u e d e n llevar a u n a insatisfacción d e l cliente a l p e r c i b i r que s u s necesidades no s o n c o n s i d e r a d a s ; o a
u n a tensión entre los diseñadores c u a n d o estos c a m b i o s se rea- 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 e2.
E l c o n t r o l de c a m b i o s es u n a parte del manejo de configu- ración (del inglés -configuration m a n a g e m e n t , p o r siglas: C M ) y es p a r a propósitos de esta tesis l a parte crítica de manejo de proyectos d u r a n t e l a fase de ejecución (Figura 3. e n pág. 17).
E l propósito del C M (manejo de configuración) es el m a n - tener l a i n t e g r i d a d de los p r o d u c t o s (por p r o d u c t o s se entiende el software, h a r d w a r e y firmware, y s u documentación asociada) c o n f o r m e e v o l u c i o n a n desde las especificaciones, a través d e l d i - seño, desarrollo y producción. N o es u n a actividad a i s l a d a , exis- te p a r a a p o y a r e n el desarrollo 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 manejo de configuración y los p r o d u c t o s se perderán;
u n C M excesivo y l a s organizaciones jamás entregarán p r o d u c - tos p o r el 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.
Pero, qué es manejo 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 [IEEE, 1995] de manejo de configu- ración más c e r c a n a a los fines de esta tesis, 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 (departamento 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 para:
(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 -configuration control) es el tercer m a y o r proceso identificado p a r a el manejo de configu- ración (Figura 3. e n pág. 17) y s i lo viéramos e n el aspecto histó- rico, ocuparía el tercero y penúltimo nivel e n l a p l a t a f o r m a (Figura 4. e n pág. 19).
Así, c u a l q u i e r a empresa de desarrollo de software, debe tener p r i m e r o perfectamente identificados a s u s productos; 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 software, deberá poder controlar 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 infraestructura de c a l i d a d necesaria, podrá a s p i - r a r a tener auditorías a todo lo largo del ciclo de v i d a de u n pro- d u c t o .
Figura 4. Escala de Implantación
C o m o proceso, el control de c a m b i o s es l a p r o p u e s t a sis- temática, justificación, evaluación, coordinación, aprobación/
desaprobación de todos los c a m b i o s después d e l establecimien- to f o r m a l de l a configuración.
U n p r o d u c t o p u e d e ser cambiado, p o r tres razones p r i n c i - pales:
(a) El producto está en desacuerdo con las especificaciones (b) Mejoras
(c) Ajuste fino
E l p r i m e r paso 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 s e a a través de u n reporte de fa- l l a , u n a petición f o r m a l de c a m b i o o mejora (Figura 5. e n pág.
21).
E s t a s peticiones 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 contras 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 d e l proyecto t o m a r decisiones sobre e l futuro de esos c a m b i o s . E s t a s peticiones debe estar f u n d a m e n t a d a s c o n los detalles, 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 precisas posible, además de los costos a proyecto
(tiempo básicamente) y de ser posible sugerir alternativas v i a - bles, 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 proceso básico e n el d i a g r a m a de flujo siguiente [Buckley, 1995].
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 describe per- fectamente las tres eras del manejo de configuraciones (CM) que simultánea e implícitamente describe aquellas del c o n t r o l de c a m b i o s (CC):
Pasado:
U n p a s a d o donde el C M era u n p r o b l e m a o r g a n i z a c i o n a l privado, donde las soluciones incluían procedimientos y políti- cas 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 archivero físico.
Presente:
E l presente está caracterizado p r i n c i p a l m e n t e por aspec- tos tecnológicos. E s decir, que l a tecnología existente p a r a so- p o r t a r el C M es l i m i t a d a p a r a g r a n d e s aplicaciones y p l a t a f o r m a s m u y específicas, así que l a mayoría de las g r a n d e s organizaciones c o n s t r u y e n s u s propios sistemas de C M .
F u t u r o :
E l futuro se caracterizará por 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
La gerencia necesita asistencia para tomar decisiones sobre si adquirir ó ha- cer los sistemas de CM.
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)
Evitando 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 extracció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, Dart Susan):
E s decir, casi todos los productos contienen la m a y o r í a de las siguientes características.
- Depósito:
Capturan información de C M y almacenan versiones de archivos como in- mutables.
- Distribución
Permiten a múltiples usuarios tener acceso al depósito.
- M a n e j o de contexto
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 partes
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.
- Mantenimiento de consistencia
Permiten al sistema identificar inconsistencias.
- Area de trabajo
Permiten aislamiento del trabajo entre diseñadores y distingue entre partes inmutables (globales) de aquellas áreas de trabajo privadas y provisionales.
- Transparencia
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.
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 utilizados p a r a realizar l a investigación s o n : dos proyectos de software de telecomunicaciones reales y c o n - temporáneos, dentro de u n a e m p r e s a i n t e r n a c i o n a l , que t a n sólo e n México tiene más de 9 0 años de h a c e r negocios e n telefo- nía: Ericsson. A m b o s proyectos se desarrollan(ron) e n Saltillo, 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 contiene los datos adicionales 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 Saltillo, C o a h u i l a , México.
E l enfoque será cualitativo, c o n dos objetivos 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 resultados cuantitativos, resultantes 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 enfatizar 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 control de c a m b i o s e n lo particular.
Se escogieron dos proyectos c o n las siguientes caracterís- ticas:
• P8A. El 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.
3.1.1 Modelo de Diseño (Ciclo de Vida del Software)
L o s proyectos P 8 A y P 8 B u t i l i z a n u n Modelo de Diseño de C a s c a d a3 (ver F i g u r a 6. e n pág. 29).
E l concepto f u n d a m e n t a l del modelo de c a s c a d a es el de t e r m i n a r u n a etapa c o n verificaciones antes de e m p e z a r l a s i - guiente, evitando c o n esto l a propagación de fallas, e n el s u - p u e s t o de que u n a falla e n c o n t r a d a e n las etapas iniciales es m a s b a r a t a e n costo y daño que e n etapas posteriores.
E r i c s s o n e n p a r t i c u l a r h a determinado que el costo de u n a falla se e s c a l a p o r 10 entre c a d a fase; así p o r ejemplo, u n a falla que 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 corregirla, e n l a e t a p a de m a n t e n i m i e n t o llega a costar h a s t a 10,000 pesos e n - c o n t r a r l a y corregirla.
C a b e h a c e r notar que el modelo de c a s c a d a h a sufrido u n c o n s t a n t e perfeccionamiento desde 1970 p o r c a u s a del u s o que h a tenido dentro de las grandes empresas desarrolladoras de software, tanto militares como civiles. Incluso h a y quienes a u - g u r a n s u d e c a d e n c i a total, a l ser s u s t i t u i d o por m o d e l o s más d i - námicos y acordes a l fin de milenio (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 el modelo es vigente y los m o - delos evolutivos aún semejan réplicas de cascadas, 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!-. Cierto es que el a p l i c a r el model o c o m o tal, tie- ne s u s efectos s e c u n d a r i o s negativos, sobre todo c u a n d o se u s a e n proyectos de a l t a volatilidad o e n p r o d u c t o s de v i d a corta, pero 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
E l modelo utilizado p o r E r i c s s o n (ver F i g u r a 7. e n pág.
30), viene h a ser u n a adaptación m o d e r n a d e l de c a s c a d a , d o n - de l a s diferencias más notorias c o n el modelo clásico (Figura 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").
Figura 6. Modelo de Diseño de Cascada (ciclo de vida)
Figura 7. Modelo de Diseño (cascada) Usado por Ambos Proyectos
3.1.2 Estructura de los Proyectos
L o s d o s proyectos (objetos de esta tesis) están a cargo 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 adelante referida 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 l o s E s t a d o s U n i d o s de América, de a h o r a e n a d e l a n t e referida c o n e l sufijo "u" (e.g. P 8 A u ) . E s t a tesis se enfo- c a e n l o s proyectos realizados e n México, s i n embargo d o n d e l o s efectos s e a n extra fronteras habrán de referirse a m b o s (m y u).
L o s d o s proyectos están relacionados 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 siguiente versión de P 8 A .
L a e s t r u c t u r a de l o s d o s proyectos P 8 A m y P 8 B m se lleva a l c a b o de l a siguiente forma:
Figura 8. Estructura de Proyectos
Proyecto Global P8
Proyecto Local P8u
Proyecto Local P8m
Así, c a d a proyecto tiene s u p r o p i a organización i n t e r n a de proyecto, esto es, c o n s u s líderes de proyecto, 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 inherentes. 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 las mojoneras ("milesto- nes" y "tollgates") que s o n las m i s m a s p a r a a m b o s proyectos locales.
P a r a n o a h o n d a r e n detalles, ésta es l a f o r m a e n que E r i c - s s o n h a trabajado los últimos veinte años (ver F i g u r a 7. e n pág.
30), d o n d e e n ocasiones el número de proyectos locales p u e d e llegar a i n v o l u c r a r h a s t a c i n c o o seis organizaciones diferentes, e n m u c h o s de los casos de diversos países.
L a f o r m a e n que E r i c s s o n l o g r a 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 gracias (entre otras cosas) a u n estricto 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 estos 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 vertebral de l a i n t e g r i d a d de los p r o d u c t o s E r i c s s o n y s o n lo suficientemente sólidos c o m o p a r a o p a c a r a los otros 2 (Control 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 tipo 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 , funciones 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 inte- grado de n-piezas, se e n c u e n t r a registrado e n u n a b a s e de datos l l a m a d a P R I M4, accesible desde c u a l q u i e r oficina E r i c s s o n e n el 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 arquitecto) 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.
Además, a lo largo de l a v i d a de u n proyecto (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 b a s e de datos m u n d i a l l l a m a d a Delta5. E s t a les permite llevar u n estricto 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 citar u n ejem- plo, allí se p u e d e ver el estado de u n d o c u m e n t o p a r t i c u l a r , s u estado de revisión (preliminar, listo-para-revisión, i n s p e c c i o n a - do, aprobado) 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 cierto estas m i n u t a s (registros de i n s - pección) facilitan el 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 el núme- ro y tipo de fallas e n c o n t r a d a s y califican o d e s c a l i f i c a n los objetos i n s p e c c i o n a d o s .
Aquí, es el m o m e n t o preciso p a r a r e m a r c a r que estos p r o - yectos 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 apropiado.
C a d a proyecto local posee algún tipo de C o n t r o l de C a m - b i o s , pero estos n o se e n c u e n t r a n integrados e n el proyecto glo- bal. C i e r t o es que diversos proyectos sí lo p r a c t i c a n , pero n o existe u n c o n t r o l científico o a l m e n o s ingenieril de éste. D i g a - m o s que el 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 recibe u n acerca- m i e n t o pragmático, que e n ocasiones f u n c i o n a y e n o c a s i o n e s no.
C a b e h a c e r n o t a r que esta d e b i l i d a d , h a sido r e s a l t a d a e n d o s frentes, p o r u n lado ISO9001:1994 (en s u cláusula 4.4.9):
- L a mayoría de los centros 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 merecidos atributos, s i n embargo l a sustentación sólida del 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.
Una vez liberado el producto, todas las ultimas revisiones aprobadas son inscritas permanentemente en P R I M .
proyectos está a u n débil. L o s centros de diseño locales 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, el modelo 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 el 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 noventas:
- D i v e r s o s centros 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 niveles (específicamente Nivel 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 ser éste el estándar requerido por el 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 departamento 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 el M a n e j o de C o n f i g u - ración de Software s o n Procesos C l a v e s del Nivel 2. E r i c s s o n n o h a p u b l i c a d o el resultado de s u s auditorías e n C M M , pero se p r e s u m e que s i está c o m o el resto de las e m p r e s a s de dise- ño de software, aún se e n c u e n t r a e n los niveles iniciales.
3.1.3 Contenido Técnico de P8Am
E l propósito del proyecto 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 perfeccionamientos e n u n a serie de s u b - s i s t e m a s p a r a satisfacer los requisitos 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 Internacionales (IXC). L o s p r i n c i p a l e s clientes a satisfacer 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 proyecto a b a r c a todas las fases del desarrollo de soft- w a r e , desde s u fase de establecimiento h a s t a l a liberación y el 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 serie de mejoras c o m p r e n d e n lo siguiente:
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 las siguientes fechas importantes, 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 trabajo se dividió c o m o sigue (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
- Total P8Am
51,115 mhr (la mayoría durante 1995) 3.1.4 Contenido Técnico de P8Bm
E l propósito del proyecto P 8 B m e n T X M es desarrollar 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 perfeccionamiento e n u n a serie de s u b s i s t e m a s de l a central telefónica E r i c s s o n AXE10, e n el siste- m a fuente 2/APT 210 10 p a r a satisfacer los requisitos p a r a C e n - trales telefónicas públicas locales, de Tránsito (Tándem) e Internacionales (IXC). L o s p r i n c i p a l e s clientes a satisfacer 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 objetivos de m e r c a d o p a r a el proyecto P 8 B i n c l u y e n l a satisfacción de requisitos 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 servicios telefónicos y de conmutación de voz y datos, 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 . Proveyendo n u e v a y mejorada f u n c i o n a l i d a d p a r a clientes i m - portantes del m e r c a d o Norteamericano (las compañías operado- ras B e l l , R B O C s p o r s u s siglas 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 contractuales existentes c o n estos clientes 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 serie de mejoras c o m p r e n d e n lo siguiente:
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
C o n t a n d o c o n las siguientes fechas importantes, 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 carga de trabajo 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)
Instantánea de Ambos Proyectos
L a siguiente t a b l a r e s u m e algo de los números de a m b o s proyectos tanto e n duración, complejidad, v o l u m e n e n líneas de código, d e n s i d a d de fallas6, v o l u m e n de código ( K L O C s7) y con- 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 etapa de d e s a r r o l l o8.
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 total
( K L O C ) 9 2 . 0 3 7 9 5a
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
Porcentaje de Contribución
a l Proyecto 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).
3.2 Procedimiento
L a metodología de diseño e n E r i c s s o n se respetó a lo largo de a m b o s proyectos; s i n embargo se i n t r o d u j e r o n ciertas accio- n e s (buenas prácticas) que s i n contravenir l a metodología y p r o - cesos establecidos creímos9 nos 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 esta m a n e r a se evitó conflicto c o n el s i s - t e m a de c a l i d a d , y el c o o r d i n a d o r de c a l i d a d aprobó el u s o de d i - c h a s prácticas.
U n o de estos procedimientos establecidos es el 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 dentro de E r i c s - s o n Saltillo, pero no de los procedimientos m u n d i a l e s , es decir, q u e e n estos proyectos i n t e n t a m o s u n a mejora de este p r o c e d i - m i e n t o b a s a d o s e n los resultados obtenidos c o n antelación. Aún y c u a n d o el proceso es directo, carece de u n a visión a d m i n i s t r a - d o r a de estos (cambios) y lo que e x p e r i m e n t a m o s e n proyectos anteriores 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 falta de tiempo; desviación de l a atención, i.e. el diseñador prefiere invertir tiempo e n codificar que e n d o c u m e n - tar; o p o r diferencia de criterios: 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 sencillo p u e - de ser s u peor p e s a d i l l a . P o r citar u n ejemplo: el proyecto ante- r i o r P7+ (del c u a l fui 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 fallas, porque 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 considerado "simple" por el experto, s i n e m - bargo p a r a los programadores fue u n a v e r d a d e r a c a r g a de trabajo (1500 hrs.) y anímica, y a que a l estar c e r c a l a fecha de p r u e b a s funcionales, se c r e a r o n fallas e n porciones de código y a verificado e n p r u e b a s básicas y por lo tanto 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.
E l proceso utilizado e n E r i c s s o n Saltillo se a p r e c i a e n l a siguiente i m a g e n (la parte superior esta t r u n c a d a p o r confiden- cialidad) :
Imagen 1. Proceso de Control de Cambio. Ericsson Saltillo
Se observa l a falta de u n cuerpo i n t e g r a d o r / a d m i n i s t r a - d o r general de todos los c a m b i o s . Cierto que el comité de c a m - b i o s ( C R T del Inglés "Change Review Team") tiene acceso a todos ellos, pero no los integra, m e n o s los a d m i n i s t r a e n el sentido 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 paso 2 es el origen de l a falta de integración y a que el e q u i p o (CRT) se reúne b i e n a l principio de s u s actividades, pero 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 faltar a s u c o m p r o m i s o c o n el equipo. E l proceso se vuelve el trabajo de u n a s o l a p e r s o n a , l a c u a l a l llegar a l paso 11, esta t a n a g o b i a d a p o r el trabajo, que simplemente no d a el "seguimiento" necesa- rio p a r a verificar que el c a m b i o sea i m p l a n t a d o . L o s originadores del c a m b i o pronto se d e s i l u s i o n a n por l a l e n t i t u d del proceso y lo a b a n d o n a n , p a r a hacer los c a m b i o s a s u m a n e r a .
L o s proyectos anteriores a P 8 c o n t e m p l a b a n el 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 los diseñadores cooperaban p a r a realizarla. N a d a más lejano de l a ingeniería de software, que no es c a p r i c h o s i n o proceso.
3.2.1 Proyecto P8Am
E n el proyecto P 8 A m se i n t e n t a r o n las siguientes acciones c o n el fin de h a c e r efectivo el control de c a m b i o s , y dejar de ser c o n ello u n proceso anhelado pero ineficaz:
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.
E l p l a n de configuración es u n d o c u m e n t o que pretende 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 Saltillo, c u b r i r el c o n - t r o l de c a m b i o s de los productos 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 fueran i m p a c t a d o s a p a r t i r del fin de Diseño de Función y h a s t a el 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 tener éxito e n el control, fue de v i t a l i m p o r t a n c i a que 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 mojonera de F i n del 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 el estado de los d o c u m e n - tos. L e l l a m a m o s congelamiento, porque 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 antes por 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 , sea que el d o c u m e n t o y a esté apro- b a d o o n o p o r los comités respectivos. E n proyectos anteriores 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 no e s t a b a n aprobados y que por ende el "proceso" les permitía aún hacerlos; esta práctica promovía de a l g u n a m a n e - r a que los 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 abiertos (sin aprobarse) h a s t a los últimas fases posibles, e l u d i e n d o de e s t a m a n e r a los controles de cambios. Algo que nosotros e n d i - seño l l a m a m o s , tomar atajos...
L a s m e t a s establecidas por el 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.
L a s funciones d e l a d m i n i s t r a d o r de c a m b i o s fueron 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 verificar q u e fueran califica- d a s y de ser aceptadas, q u e fueran i m p l a n t a d a s además de lle- v a r e l índice de configuración maestro. 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 el p l a n y verificar q u e se l l e v a r a a l c a - bo.
E l a d m i n i s t r a d o r de c a m b i o s tiene u n a posición e n l a p l a n t i l l a d e l proyecto c o m o se aprecia e n l a siguiente i m a g e n lo que 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 .
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 aporta- ción del 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 el 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 aquellos objetos de configuración que por s u i m p o r t a n c i a , complejidad o alcance, e r a n más susceptibles de c a u s a r daños e n el proyecto s i suce-
dían c a m b i o s n o controlados. C a b e resaltar el h e c h o de que el índice e r a u n extracto del Indice de Configuración (global) de todo el proyecto.
E n el argot de manejo de configuración, el Indice de C o n f i - guración M a e s t r o (MCI del 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 los casos es el único índice. S i n embargo e n P 8 A m el M C I sería u n extracto del global, conteniendo entonces sólo a q u e l l o s objetos (documentos) que e r a n de vital i m p o r t a n c i a p a r a el proyecto. Así, el M C I contenía d o c u m e n t o s aún y c u a n d o estos e s t u v i e r a n fuera del desarrollo de P 8 A m , es decir, incluía también d o c u m e n t o s hechos por organizaciones externas c o m o P 8 A u . E s t e concepto 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 .
Indice de Configuración Maestro (MCI)
Figura 9. Concepto de MCI en P8Am
E n l a Imagen 3. e n pág. 48, se m u e s t r a el M C I del proyec- to y allí se a p r e c i a cómo se especifica el tipo de d o c u m e n t o s (e.g.
F F , del inglés, F u n c t i o n F r a m e w o r k ) , el total de éste tipo de do- c u m e n t o s ; el estado, l a fecha e n que adquirió d i c h o estado y el foro que a v a l a d i c h o estado; l a revisión (e.g. P A 5 , que significa 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 tenido c a m b i o s recientes.
D e l a m i s m a i m a g e n podemos apreciar l a f o r m a l i d a d d e l índice, a l poseer u n autor, el 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 del líder de proyecto; u n a inspección, l a del 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 obligados 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 los d o c u m e n t o s , revisiones y c a m b i o s e n estos, así que rápidamente se podía identificar 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 sido estos c a m b i o s e n lo específico, i.e. sólo alertaba a l a d m i n i s t r a - d o r sobre c a m b i o s e n s u terreno, c o n lo c u a l él podría entrevis- tar a l a u t o r del objeto (documentos) p o r aquellas razones que s u s t e n t a b a n los c a m b i o s reduciendo c o n esto el número de c a m b i o s a requerimientos no controlados, polizones.
Imagen 3. P8Am, Indice Maestro
3.2.2 Proyecto P8Bm
E n b a s e a l a s experiencias d e l proyecto P 8 A m , se modifi- c a r o n y perfeccionaron algunas de las prácticas e n el proyecto P 8 B .
L a s acciones específicas p a r a realizar el c o n t r o l de c a m - b i o s e n el proyecto P 8 B m fueron las siguientes:
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. El í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 el líder de proyecto de P 8 B m fuera el 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 d e l nuevo líder de c a m b i o s e n s u proyecto pero también tuvo efectos secundarios, como los siguientes:
P R O S
• rápido entendimiento del problema
• continuidad
• perfeccionamiento del proceso hecho a la medida del líder presente
