Libro Completo de Ingeniería Eléctrica

SEIS SIGMA EN EL DESARROLLO DE PROYECTOS DE INFORMACIN
TECNOLGICA DE LA DIVISIN DE SERVICIOS DE INFORMACIN Y SU

APLICACIN EN UN MDULO DE LA INTERFACE WEB DEL SISTEMA DE
LA BIBLIOTECA DE LA UIS
DIANA MARCELA ZAMBRANO OLARTE

SERGIO ANDRS CONTRERAS NIGRINIS
UNIVERSIDAD INDUSTRIAL DE SANTANDER

FACULTAD DE INGENIERIAS FSICO-MECNICAS
ESCUELA DE INGENIERA DE SISTEMAS E INFORMTICA
BUCARAMANGA
2004
SEIS SIGMA EN EL DESARROLLO DE PROYECTOS DE INFORMACIN

TECNOLGICA DE LA DIVISIN DE SERVICIOS DE INFORMACIN Y SU
APLICACIN EN UN MDULO DE LA INTERFACE WEB DEL SISTEMA DE
LA BIBLIOTECA DE LA UIS
DIANA MARCELA ZAMBRANO OLARTE

SERGIO ANDRS CONTRERAS NIGRINIS
Proyecto de grado presentado como requisito parcial

para optar al ttulo de Ingeniero de Sistemas
Director
ENRIQUE TORRES LOPEZ
Jefe Divisin de Servicios de Informacin
UNIVERSIDAD INDUSTRIAL DE SANTANDER

FACULTAD DE INGENIERIAS FSICO-MECNICAS
ESCUELA DE INGENIERA DE SISTEMAS E INFORMTICA
BUCARAMANGA
2004
AGRADECIMIENTOS
Ahora que finaliza una etapa ms de nuestras vidas, queremos agradecer a
todas aquellas personas que aportaron para que culminaramos con xito una
de las metas de nuestra vida.
Queremos antes que nada agradecer a Dios, por estar siempre presente en
nuestras vidas y ser nuestra luz, nuestro camino y nuestra fortaleza.
Al Ingeniero Edwin Suarez, por la confianza depositada, por todas sus
enseanzas y por su apoyo incondicional.
Al Ingeniero Enrique Torres Lopez, por permitirnos pertenecer a la Divisin
de Servicios de Informacin y permitirnos crecer profesionalmente y
personalmente.
Al Ingeniero Gilberto Rivas Rincn, por su tiempo compartido y por sus
enseanzas en todos los aspectos de la vida, que Dios lo tenga en su gloria.
A todos los compaeros DSI, que en cualquier momento
apoyo y que fueron partcipes de este aprendizaje.
nos brindaron su
CONTENIDO
pg
INTRODUCCIN
1
PARTE I
1.
PRESENTACIN .............................................................................. 3
1.1
DESCRIPCIN DEL DOCUMENTO
1.2
ANTECEDENTES
1.2.1
Metodologa Seis Sigma.
1.2.2
Mdulo de consultas del catlogo bibliogrfico de la Bilbioteca va

web.
1.3
OBJETIVOS
1.3.1
Objetivo General.
1.3.2
Objetivos Especficos.
2.
GENERALIDADES DE SEIS SIGMA.............................................. 10
2.1
HISTORIA Y EVOLUCIN
10
2.2
DEFINICIN DE SEIS SIGMA
10
2.3
PRINCIPIOS DE SEIS SIGMA
12
2.3.1
Prevenir defectos.
12
2.3.2
Reducir la Variacin.
13
2.3.3
Orientacin en el Cliente.
14
2.3.4
Decisiones basadas en hechos.
15
2.3.5
Trabajo en Equipo.
16
2.4
HERRAMIENTAS Y ENTRENAMIENTO
16
3.
FASE DEFINIR ............................................................................... 20
3.1
ENTENDER EL MODELO DEL NEGOCIO
21
3.2
DEFINIR EL PROBLEMA
22
3.2.1
Retroalimentacin con el Cliente o VOC.
23
3.2.2
Oportunidades externas.
23
3.2.3
Experiencia.
24
3.3
DEFINIR ROLES Y RESPONSABILIDADES
26
3.3.1
Lderes Ejecutivos
26
3.3.2
Patrocinadores
27
3.3.3
Master Black Belts (MMB)
28
3.3.4
Black Belts (BB)
29
3.3.5
Green Belts (GB)
30
3.4
FORMAR EL EQUIPO DE TRABAJO
30
3.5
IDENTIFICAR LOS CLIENTES
32
3.6
IDENTIFICAR LO CRTICO PARA LA CALIDAD (CTQS)
34
3.7
DESARROLLAR EL PLAN DE PROYECTO
34
3.7.1
Definicin del alcance y objetivos
35
3.7.2
Costo/ Beneficio
37
3.7.3
Presupuesto
42
3.7.4
Riesgos
45
3.7.5
Cronograma
50
3.8
DESARROLLAR EL CUADRO RESUMEN DEL PROYECTO
52
3.9
DEFINIR UN VOCABULARIO
53
3.10
IDENTIFICAR LOS PROCESOS ACTUALES
54
4.
FASE MEDIR .................................................................................. 62
4.1
CAPTURAR LA VOZ DEL CLIENTE (VOC)
66
4.2
DETERMINAR QUE MEDIR
67
4.2.1
Tipos de variacin
68
4.2.2
Medir lo que tenga valor
70
4.2.3
Exactitud de las medidas
70
4.3
PLAN DE COLECCIN DE DATOS
71
4.3.1
Seccin 1: definir las metas y los objetivos
71
4.3.2
Seccin 2: desarrollar las definiciones operativas y los

procedimientos.
72
4.4
ELABORAR LAS GRFICAS DE LAS MEDIDAS
75
4.4.1
Diagrama de cajas
75
4.4.2
Diagrama de punto
77
4.4.3
Diagrama de torta.
78
4.4.4
Histograma con curva normal
79
4.4.5
Diagrama de Series de Tiempo
79
4.4.6
Diagrama de Corrido
80
4.4.7
Diagrama de dispersin
81
4.4.8
Diagrama de pareto
82
4.5
CALCULAR EL NIVEL SIGMA
83
4.6
BENCHMARKING
87
4.6.1
Qu es Benchmarking?
87
4.6.2
Por qu Benchmarking en Seis Sigma?
88
4.7
DESARROLLAR EL MODELO FINANCIERO
90
4.8
IDENTIFICAR Y PRIORIZAR LOS REQUERIMIENTOS DE LOS

CLIENTES
92
4.9
INICIO DE DETERMINACIN DE MEJORAS
95
4.10
PLAN DE COMUNICACIONES
96
5.
FASE ANALIZAR............................................................................ 98
5.1
DETERMINAR QUE CAUSA LA VARIACIN
5.2
LLUVIA DE IDEAS PARA LA MEJORA DE PROCESOS
5.3
DETERMINAR CUALES MEJORAS TIENEN MAYOR IMPACTO EN

LOS REQUERIMIENTOS DE LOS CLIENTES
5.4
99
105
107
ENCONTRAR LOS RIESGOS ASOCIADOS AL PROCESO

REVISADO (AMFE)
110
5.5
DESARROLLAR EL PLAN DE CAPACITACIN
111
5.5.1
Evaluar las necesidades para la capacitacin
111
5.5.2
Preparar un programa de capacitacin.
112
5.5.3
Administrar la logstica para la capacitacin.
113
5.5.4
Evaluar y dar seguimiento al programa:
115
5.6
IDENTIFICAR LOS SISTEMAS AFECTADOS DE OTRAS

DEPENDENCIAS
115
5.7
DESARROLLAR EL NUEVO MAPA DE PROCESOS
116
6.
FASE DISEAR............................................................................ 119
6.1
SELECCIONAR METODOLOGA DE DESARROLLO DE

SOFTWARE
120
6.1.1
Cascada.
120
6.1.2
Espiral.
121
6.1.3
Proceso Unificado.
123
6.1.4
Modelo de Capacidad de Maduracin (CMM).
125
6.1.5
Proceso Personal de Software (PSP).
127
6.1.6
Proceso de Software en Equipo (TSP).
128
6.1.7
Desarrollo Rpido de Aplicacin (RAD).
130
6.1.8
Extreme Programing (XP).
131
6.2
DISEAR EL FORMATO DE DOCUMENTACIN DE PROGRAMAS

134
6.3
DEFINIR LA SEGURIDAD
135
6.4
ESPECIFICACIN DEL DISEO
137
6.5
INTEGRACIN DEL SISTEMA
141
6.5.1
Tipos de integracin de sistemas
141
6.5.2
Estndares para conexin a la red
147
6.5.3
Interfaces de conexin a bases de datos.
148
6.6
REVISIN Y PERFECCIONAMIENTO DEL DISEO
148
6.7
SELECCIN DE HARDWARE Y SOFTWARE
151
6.8
CONSTRUCCIN DE PROTOTIPOS
154
6.8.1
Tcnicas de cuarta generacin.
156
6.8.2
Componentes de Software Reutilizable.
156
6.8.3
Especificaciones formales y entornos para prototipos.
156
6.9
DISEAR EL PLAN DE PRUEBAS
157
6.9.1
Prueba de Caja Blanca.
159
6.9.2
Prueba de Caja Negra.
159
6.9.3
Prueba de Entornos y Aplicaciones especializadas.
6.10
REVISAR QUE LOS PROTOTIPOS CUMPLAN CON LOS

REQUERIMIENTOS
160
161
7.
FASE DE DESARROLLAR .......................................................... 162
7.1
ORGANIZACIN DEL CDIGO FUENTE
163
7.1.1
rbol Jerrquico.
163
7.1.2
Enlaces Absolutos.
164
7.1.3
Enlaces Relativos.
165
7.2
CONSTRUCCIN
165
7.3
REVISAR QUE SE SATISFACIERON LOS REQUERIMIENTOS 166
7.4
DOCUMENTACIN DEL CDIGO
166
7.4.1
Legibilidad.
167
7.4.2
Ubicacin de comentarios.
167
7.5
DISEAR EL PLAN DE IMPLANTACIN
168
7.5.1
Corte-Rpido.
169
7.5.2
Etapas.
170
7.6
EJECUTAR EL PLAN DE IMPLANTACIN
170
8.
FASE VALIDAR ............................................................................ 171
8.1
EJECUTAR EL PLAN DE PRUEBAS.
171
8.2
CAPACITAR AL CLIENTE.
175
8.3
DETERMINAR LOS RIESGOS
177
8.4
DOCUMENTACIN DEL PROYECTO
178
8.4.1
Manuales del proyecto.
179
8.4.2
Libro del proyecto.
180
8.5
CREAR LOS MECANISMOS DE ADMINISTRACIN.
180
8.6
EVALUAR LOS BENEFICIOS ALCANZADOS
181
8.7
DOCUMENTAR LAS LECCIONES APRENDIDAS
182
8.7.1
Secciones de lecciones aprendidas.
182
8.7.2
Formato de las lecciones aprendidas.
183
8.8
COMUNICAR AL EQUIPO DE TRABAJO LOS RESULTADOS

OBTENIDOS
183
8.9
CIERRE DEL PROYECTO
184
PARTE II
9.
FASE DEFINIR ............................................................................. 185
9.1
185
9.2
DEFINIR EL PROBLEMA
187
9.3
188
9.4
189
9.5
190
9.6
DETERMINAR LO CRTICO A ASEGURAR EN LA CALIDAD (CTQ).

191
9.7
194
9.7.1
Alcance y objetivos del proyecto.
194
9.7.2
Costo/Beneficio.
194
9.7.3
Riesgos.
195
9.7.4
Cronograma.
197
9.8
CUADRO RESUMEN DEL PROYECTO
198
9.9
199
9.10
IDENTIFICACIN DEL PROCESO ACTUAL
199
9.11
PRESENTAR AL COMITE PARA APROBAR
201
10.
FASE MEDIR ................................................................................ 202
10.1
CAPTUAR LA VOZ DEL CLIENTE (VOC)
202
10.2
CTQ1
206
10.2.1 Determinar que medir.
206
10.2.2 Plan de Coleccin de Datos
207
10.2.3 Grficas.
208
10.2.4 Calcular el nivel de sigma.
212
10.2.5 Benchmarking.
213
10.3
214
CTQ 2
10.3.1 Determinar qu medir.
214
10.3.2 Plan de coleccin de datos.
215
10.3.3 Elaborar las grficas.
219
220
220
10.4
225
CTQ 3
225
226
10.4.3 ELABORAR LAS GRFICAS
227
229
230
10.5
231
10.6
IDENTIFICAR Y PRIORIZAR LOS REQUERIMIENTOS DE LOS

CLIENTES
232
10.7
INICIO DE QFD
246
10.8
PLAN DE COMUNICACIONES
247
10.9
PRESENTAR AL COMIT PARA APROBAR
248
11.
FASE ANALIZAR.......................................................................... 249
11.1
249
11.1.1 CTQ 1.
249
11.1.2 CTQ 2.
251
11.1.3 CTQ 3
251
11.2
SESIN DE LLUVIA DE IDEAS
253
11.3
DETERMINAR QUE SOLUCIONES TENDRAN MAYOR IMPACTO

EN LOS REQUERIMIENTOS DEL CLIENTE
255
11.4
ANALISIS DE MODOS DE FALLO Y EFECTOS
258
11.5
261
11.6
IDENTIFICAR LOS SISTEMAS AFECTADOS DE OTRAS

DEPENDENCIAS
263
11.7
264
11.8
266
12.
FASE DISEAR............................................................................ 267
12.1
SELECCIONAR LA METODOLOGA DE DESARROLLO DE

SOFTWARE
267
12.1.1 Principios de PSP.
269
12.1.2 Estructura del Proceso.
269
12.2
DISEO DE FORMATO DE DOCUMENTACIN DE PROGRAMAS

276
12.3
278
12.4
279
12.4.1 Diseo de datos.
279
12.4.2 Diseo arquitectnico.
282
12.4.3 Diseo de interfaz
290
12.4.4 Diseo procedimental.
291
12.5
293
12.6
295
12.6.1 Bsqueda simple
295
12.6.2 Bsqueda Avanzada
295
12.6.3 Listado de Resultados
296
12.6.4 Subconsulta
297
12.6.5 Ver Detalles
298
12.6.6 Lista previa de referencias
299
12.6.7 Enviar referencias por correo electrnico
300
12.6.8 Imprimir listado de referencias
301
12.6.9 Detalles MARC
302
12.6.10 Resumen
303
12.7
304
12.8
VERIFICAR QUE LOS PROTOTIPOS CUMPLAN CON LOS

REQUERIMIENTOS
312
12.9
312
13.
FASE DESARROLLAR ................................................................ 313
13.1
ORGANIZACIN DEL CODIGO FUENTE
313
13.2
CONSTRUCCIN
314
314
315
316
13.2.4 Subconsulta
317
13.2.5 Ver Detalles
318
319
322
323
325
13.2.10 Resumen
325
14.
CONCLUSIONES.......................................................................... 327
15.
RECOMENDACIONES ................................................................. 329
BIBLIOGRAFA
336
BIBLIOGRAFA EN INTERNET
338
ANEXOS
339
LISTADO DE FIGURAS
pg
Figura 1. Representacin de la variacin.
14
Figura 2. Ciclo de anlisis de riesgos proactivo.
48
Figura 3. Diagrama de GANTT.
52
Figura 4. Elementos utilizados en la representacin de procesos.
58
Figura 5. Diagrama de alto nivel.
59
Figura 6. Diagrama de alto nivel con pasos intermedios.
59
Figura 7. Diagrama de nivel de detalle.
60
Figura 8. Probabilidades asociadas a una distribucin normal.
65
Figura 9. Diagrama de cajas sencillo.
76
Figura 10. Diagrama de cajas avanzado.
76
Figura 11. Diagrama de punto.
78
Figura 12. Diagrama de torta.
78
Figura 13. Diagrama de histograma.
79
Figura 14. Diagrama de series de tiempo.
80
Figura 15. Diagrama de corrido.
81
Figura 16. Diagrama de dispersin.
82
Figura 17. Diagrama de pareto.
82
Figura 18. Retorno de inversin Vs tiempo.
91
Figura 19. Modelo de Kano.
94
99
Figura 21. Ciclo de anlisis del problema.
101
Figura 22. Pareto, causas de fallas del sistema.
102
Figura 23. Pareto, Causas de por que falla el cdigo.
102
Figura 24. Diagrama causa efecto.
104
Figura 25. Ciclo de capacitacin.
112
Figura 26. Ejemplo diagrama de flujo del nuevo proceso.
118
Figura 27. Modelo Cascada.
120
Figura 28. Modelo de Espiral.
122
Figura 29. Modelo proceso unificado.
124
Figura 30. Modelo de CMM.
126
Figura 31. Modelo proceso personal de software.
127
Figura 32. Modelo Proceso de software en equipo.
129
Figura 33. Modelo de desarrollo rpido de aplicacin.
130
Figura 34. Modelo Extreme Programming.
132
Figura 35. Modelo del diseo.
138
Figura 36. Integracin orientada a datos.
142
Figura 37. Integracin orientada a interfaz de aplicacin (API).
143
Figura 38. Integracin Orientada a Mtodos.
144
Figura 39. Integracin Orientado a Portal.
145
Figura 40. Integracin Orientado a Procesos.
146
Figura 41. Proceso de prototipos.
157
Figura 42. Estructura de un rbol jerrquico.
164
Figura 43. Administracin del Riesgo.
178
Figura 44. Modelo organizacional del proyecto.
190
Figura 47. Proceso Actual
200
Figura 48. Resultados de la VOC.
203
Figura 49. Porcentaje de quejas del cliente.
203
Figura 50. Arbol final soluciones
204
Figura 51. Tabla de estadsticas de tiempo.
207
Figura 52. Situacin actual, y posicin de captura de tiempo.
208
Figura 53. Consultas vs. Tiempos de respuesta.
209
Figura 54. Consultas defectuosas Vs No defectuosas.
209
Figura 55. Nmero de consultas Vs hora.
210
Figura 56. Consutas por hora vs. Consultas defectuosas por hora
210
Figura 57. Usuarios que ven detalles vs no ven.
211
Figura 58. Usuario que ven detalles Vs no ven detalles.
211
Figura 59. Consulta simple sistema informix.
215
Figura 60. Listado de resultados sistema informix.
216
Figura 61. Subconsulta sistema informix.
217
Figura 62. Detalles de un material bibliogrfico sistema informix.
218
Figura 63. Resumen sistema informix.
219
Figura 64. Comparacin de servicios.
219
Figura 65. Bsqueda simple Benchmarking.
220
Figura 66. Bsqueda avanzada Benchmarking.
221
Figura 67. Listado de resultados Benchmarking.
221
Figura 68. Detalles material bibliogrfico Benchmarking.
222
Figura 69. Detalles MARC Benchmarking.
222
Figura 70. Reserva de material bibliogrfico Benchmarking.
223
Figura 71. Guardar referencias Benchmarking.
223
Figura 72. Tablas de captura de datos estadsticos.
226
Figura 73. Diagrama de Corrido
227
Figura 74. Resultados de las Consultas.
228
Figura 75. Grficas de los tipos de errores.
228
Figura 76. Caso de uso general.
235
Figura 77. Diagrama de Casos de Uso
235
Figura 78. Diagrama de actividades CU consultar.
237
Figura 79. Diagrama de actividades CU subconsulta.
238
Figura 80. Diagrama de actividades CU bsqueda simple.
239
Figura 81. Diagrama de actividades CU bsqueda avanzada.
241
Figura 82. Diagrama de actividades CU guardar referencia.
243
Figura 83. Diagrama de actividades CU ver detalles.
245
Figura 84. Diagrama de actividades CU navegar por los resultados.
246
Figura 85. Grfico de corrido CTQ 1.
249
Figura 86. Tiempo de respuesta con cantidad de consultas por hora.
250
Figura 87. Pareto causas de la velocidad.
250
Figura 88. Pareto tipos de errores.
252
Figura 89. Pareto errores tipo 1.
253
Figura 90. Pareto requerimientos del cliente.
257
Figura 91. Nuevo mapa de procesos.
264
Figura 92. Estructura del proceso
270
270
Figura 94. Estructura por niveles de psp.
271
Figura 95. Modelo dimensional biblioteca.
281
Figura 96. Arquitectura de red distribuida.
283
Figura 97. Capa de presentacin.
285
Figura 99. Capa de datos.
289
Figura 100. Prototipo bsqueda simple.
295
Figura 101. Prototipo bsqueda avanzada.
296
Figura 102. Prototipo listado de resultados.
297
Figura 103. Prototipo subconsulta.
298
Figura 104. Prototipo ver detalles.
299
Figura 105. Prototipo lista previa de referencias.
300
Figura 106. Prototipo enviar referencia por e-mail.
301
Figura 107. Prototipo confirmacin envo de e-mail.
301
Figura 108. Prototipo imprimir referencias.
302
Figura 109. Prototipo ventana de impresin.
302
Figura 110. Prototipo detalles MARC.
303
Figura 111. Prototipo resumen.
304
Figura 112. rbol de organizacin del cdigo fuente.
313
Figura 113. rbol de organizacin de las libreras.
313
Figura 114. Construccin, Bsqueda simple.
314
Figura 115. Construccin, Bsqueda avanzada.
315
Figura 116. Construccin, Listado de resultados.
317
Figura 117. Construccin, Subconsulta.
318
Figura 118. Construccin, Ver detalles.
319
Figura 119. Construccin, Listado de referencias.
320
Figura 120. Construccin, Modificacin de lista previa de referencias.
321
Figura 121. Construccin, Lista modificada de referencias.
321
Figura 122. Construccin, Envo de referencias por e-mail.
322
Figura 123. Construccin, Confirmacin envo de referencias por e-mail. 323

Figura 124. Construccin, Imprimir referencias.
324
Figura 125. Construccin, Ventana de impresin.
324
Figura 126. Construccin, Detalles MARC.
325
Figura 127. Construccin, Resumen.
326
LISTADO DE TABLAS
Pg
Tabla 1. Comparaciones de los niveles de Seis sigma
11
Tabla 2. Seis Sigma Vs Control de Calidad
13
Tabla 3. Estructura de la definicin del problema.
25
Tabla 4. Mtodos para clasificar a los clientes.
33
Tabla 5. Tipos de riesgos.
47
Tabla 6. Criterios de seleccin de medidas.
68
Tabla 7. Mtodo de 1 P y 5 Ms.
69
Tabla 8. Categora de los riesgos en las medidas.
70
Tabla 9. Datos ejemplo.
77
Tabla 10. Conversin de DPMO a Nivel Sigma
86
Tabla 11. Categoras del diagrama causa-efecto.
104
Tabla 12. Costo/Tiempo/Impacto.
107
Tabla 13. Ranking de propuestas/requerimientos.
108
Tabla 14. Ejemplo QFD.
109
Tabla 15. Ejemplo de un plan de trabajo general.
113
Tabla 16. Ejemplo de un plan de sesin.
114
Tabla 17. Comparacin metodologias de desarrollo de software
133
Tabla 18. Tipos de Pruebas.
173
Tabla 19. Registro de Pruebas
174
Tabla 20. Formas de Capacitacin.
176
Tabla 21. Encuesta de Capacitacin.
176
Tabla 22. Roles y responsabilidades.
189
Tabla 23. Identificacin de clientes.
191
Tabla 24. Riesgos definidos en el plan.
195
Tabla 25. Principales caractersticas que debe tener el sistema.
233
Tabla 26. Listado de Requisitos Funcionales.
234
Tabla 27. CU consultar.
236
Tabla 28. CU subconsulta.
237
Tabla 29. CU bsqueda simple.
238
Tabla 30. CU bsqueda avanzada.
239
Tabla 31. CU guardar referencia.
241
Tabla 32. CU ver detalles
244
Tabla 33. CU navegar por los resultados.
245
Tabla 34. Plan de comunicaciones establecido.
247
Tabla 35. Sesin de lluvia de ideas.
253
Tabla 36. Puntaje de criterio para la seleccin de ideas.
255
Tabla 37. Anlisis de Modos de Fallo y Efectos
259
Tabla 37. Anlisis de Modos de Fallo y Efectos (Continuacin)
260
Tabla 38. Formato uno de documentacin de programas.
276
Tabla 39. Formato dos de documentacin de programas.
277
Tabla 40. Formato tres de documentacin de programas.
277
Tabla 41. Asignacin de seguridad.
278
Tabla 42. Asignacin de roles.
278
Tabla 43. Diferencias entre modelos dimensionales y E-R.
279
Tabla 44. Tabla de verdad para interseccin.
293
Tabla 45. Tabla de verdad unin.
293
Tabla 46. Pruebas de Caja Blanca.
305
Tabla 49. Cuadro resumen proyecto.
337
Tabla 50. Mtodos para capturar la VOC.
338
350
Tabla 52. Descripcin de las fases de programacin.
353
Tabla 53. Estndares de tipos de defectos.
356
LISTA DE ANEXOS
Pg
ANEXO A. Cuadro resumen de proyecto
334
ANEXO B. Tcnicas para capturar la voz del cliente.
338
ANEXO C. Captura de Requisitos con UML.
340
ANEXO D. Anlisis de modos de fallo y efecto.
347
ANEXO E. Formatos utilizados en psp.
351
1. TITULO: SEIS SIGMA EN EL DESARROLLO DE PROYECTOS DE

INFORMACIN TECNOLGICA DE LA DIVISIN DE SERVICIOS DE
INFORMACIN Y SU APLICACIN EN UN MDULO DE LA INTERFACE
*
WEB DEL SISTEMA DE LA BIBLIOTECA DE LA UIS
2. AUTORES: ZAMBRANO OLARTE DIANA MARCELA, CONTRERAS
**
NIGRINIS SERGIO ANDRES.
3. PALABRAS CLAVES: Seis Sigma, Biblioteca, Crtico para la Calidad,
Mdulo de consulta, Catlogo Bibliogrfico, Satisfaccin del cliente, defectos,
Project managament, Benchmarking.
4. DESCRIPCIN:
Durante mucho tiempo la Divisin Servicios de Informacin (DSI) de la
Universidad Industrial de Santander (UIS) ha construido una gran variedad
de proyectos de informacin tecnolgica que han sido elaborados utilizando
diferentes metodologas de desarrollo de software, las cuales han logrado
que los sistemas de informacin cumplan con las necesidades del cliente y
de cierto modo alcanzando un alto nivel de satisfaccin.
El presente proyecto se realiz con el propsito de integrar en un solo marco
metodolgico, un estndar en el que se tenga en cuenta una serie de fases y
pasos para el desarrollo formal y eficiente de procesos y especialmente de
software.
As como Seis Sigma ayuda a las compaas a eliminar defectos, reducir
costos y mejorar la satisfaccin del cliente en sus procesos de manufactura,
igualmente puede aumentar la efectividad en los tradicionales procesos de
desarrollo de software.
El estudio se centrar en un modelo definido como DMADDV utilizado para el
desarrollo de nuevos proyectos software. Adems la definicin y descripcin
de los pasos que el equipo de trabajo considere deban conforman cada una
de las fases del modelo.
**
Proyecto de Grado
Facultad de Ciencias Fsico-Mecnicas, Ingeniera de Sistemas, Dir. Ing. Enrique Torres Lpez
1. TITLE: SIX SIGMA IN TECHNOLOGICAL INFORMATION PROJECT

DEVELOPMENT OF THE INFORMATION SERVICE DIVISION AND ITS
APPLICATION IN A MODULE OF THE WEB INTERFACE OF THE
*
LIBRARY SYSTEM OF THE UIS.
2. AUTHORS: Zambrano Olarte Diana Marcela, Contreras Nigrinis Sergio
**
Andres.
3. KEY WORDS: Library, Critical for Quality, Consultation Module,
Bibliographic catalog, Customer Satisfaction, defects, project
management, Six Sigma, Benchmarking
4. DESCRIPTION:
During a long time the Information Service Division (ISD) of the Industrial
University of Santander (UIS) has built a variety of technological information
projects that have been developed using different methodologies of software
development, which have achieved that the information systems reach the
clients needs and in some way obtain a high level of satisfaction.
The present project was done with the purpose of integrating in one single
methodological frame, a standard in which is taken into account a series of
phases and steps for the efficient and formal development of processes and
specially software.
As well as Six Sigma helps companies eliminate defects, reduce costs and
improve customer satisfaction in its manufactory processes, in this same way
it can increase the effectiveness in traditional processes of software
development.
The study will be centered in a defined model as DMADDV used for the
development of new software. Also the definition and description of the steps
that the work team considers that should conform each of the phases of the
model.
**
Physical-Mechanic Science Faculty, Systems Engineering, Dir. Eng. Enrique Torres Lpez
GLOSARIO
ALCANCE: Define los lmites del proceso o del proyecto de mejora; seala
especficamente donde residen las oportunidades de mejora (puntos inicial y
final); define dnde y qu hay que medir y analizar; tiene que estar dentro de
la esfera de influencia y control del equipo que trabaja en el proyecto y,
cuanto ms amplio sea el alcance, ms complejo y ms tiempo requerir el
esfuerzo de mejora del proceso.
AMFE (Anlisis de Modos de Fallo y Efectos): Es un proceso disciplinado

que le permite anticiparse a los fallos, identificarlos y preveerlos. El modo en
que parte del proceso puede incumplir las especificaciones, creando un
defecto y el impacto en el cliente si ese modo de fallo no se prev o se
corrige.
ASEGURAMIENTO DE LA CALIDAD O QA (Quality Assurance): Disciplina

para mantenimiento de la conformidad de productos o servicios respecto a
las especificaciones del cliente; las herramientas principales son inspeccin y
control estadstico de procesos.
BB: (Black Belt): Lderes del equipo y jefes del proyecto, con habilidades de
facilitador, responsables de dirigir un proyecto hasta la conclusin del mismo.
BENCHMARKING: Es un mtodo para comparar procesos, utilizando

estndares o las mejores prcticas como referencia, para luego identificar
maneras de mejorar el proceso.
CHAMPION: Persona que representa a un equipo ante la alta direccin; da

el aprobado final a las recomendaciones del equipo, y apoya su trabajo ante
el consejo de calidad; facilita la obtencin de recursos para el equipo segn
sean necesarios; ayuda al Black Belt y al equipo a superar los obstculos; y
es el mentor para el Black Belt.
CLIENTE: Cualquier persona y organizacin, interna o externa, que recibe el

resultado (producto o servicio) del proceso; comprender el impacto del
proceso tanto en los clientes internos como externos es fundamental para la
gestin y mejora de los procesos.
CMM (Capability Maturity Model): Modelo de Madurez de Capacidad para el

Software.
Es un modelo para juzgar la madurez de los procesos de
desarrollo y mantenimiento de software en una organizacin y para identificar

las prcticas claves que se requieren para aumentar la madurez de estos
procesos.
COSTO POR BAJA CALIDAD O COPQ (Cost Of Poor Quality): Costo total
del personal, material y gastos generales atribuidos a las imperfecciones en
los procesos que entregan productos o servicios que no cumplen con las
especificaciones o expectativas.
reproceso,
trabajo
duplicado,
Estos costos incluiran la inspeccin,

rechazos
de
material,
devoluciones, quejas, prdida de clientes y el dao a la imagen.
repuestos
CRTICOS PARA LA CALIDAD O CTQ (Critical To Quality): Elementos de

un proceso que afectan significativamente la salida de ese proceso. Es vital
identificar esos elementos para entender cmo hacer mejoras que reduzcan
dramticamente los costos y mejoren la calidad.
DEFECTO: Una caracterstica medible del proceso o de su salida que no

est dentro de los lmites aceptables para el cliente, es decir, que no est
conforme a las especificaciones.
DMADV: Es una estrategia de calidad para disear productos y procesos, es

una parte integral de la iniciativa de la calidad Seis Sigma. Consiste en cinco
fases: Definir, Medir, Analizar, Disear, Verificar.
DMAIC: Acrnimo del sistema de gestin y mejora de procesos que

comprende las fases Definir, Medir, Analizar, Mejorar y Controlar.
DPMO o Defectos por milln de oportunidades: Clculo utilizado en las

iniciativas de mejora de procesos Seis Sigma que indica la cantidad de
defectos de un proceso por milln de oportunidades; el nmero de defectos
dividido por (el nmero de unidades por el nmero de oportunidades), por un
milln = DPMO.
NUMERO DE DEFECTOS * 1'000.000
DPMO =
NUMERO DE UNIDADES * NUMERO DE OPORTUNIDADES
FMEA (Failure Mode and Effect Analysis): Anlisis de Modos de Fallo y

Efectos (AMFE)
GB (Green Belt): Es un miembro de la compaa, que posee altas

habilidades en una rea especifica en que desarrolla el proceso.
Su
participacin en el proyecto puede ser parcial o de tiempo completo.

Desarrollan destrezas en las herramientas estadsticas.
GESTIN DE LA CALIDAD TOTAL O TQM (Total Quality Management): Un

enfoque de la gestin que se centra en la organizacin como un sistema, con
nfasis en los equipos, los procesos, la estadstica, la mejora continua y la
entrega de productos y servicios que satisfacen y exceden las expectativas
de los clientes.
MBB (Master Black Belt): Son los expertos en la metodologa, y los

responsables de las implantaciones estratgicas en la organizacin. Son los
encargados del entrenamiento y los mentores de los Black Belts y Green
Belt; ayudan a priorizar y a calcular el impacto de los proyectos.
REQUISITOS DE CLIENTE: Define las necesidades y expectativas del

cliente, traducidas a trminos medibles y utilizados en el proceso para
garantizar la compatibilidad con las necesidades del cliente.
SIGMA: Letra del alfabeto griego utilizada en estadstica para representar la

desviacin estndar de una poblacin, un indicador del grado de variacin en
un conjunto de medidas o en un proceso.
SEIS SIGMA: Un concepto estadstico que mide un proceso en trminos de

defectos, en un nivel Seis Sigma slo existen 3,4 defectos por milln de
oportunidades. Seis Sigma es tambin una filosofa de gestin que enfoca
su atencin en eliminar los defectos a travs de prcticas que enfatizan la

comprensin, la medida y la mejora de los procesos.
VOZ DEL CLIENTE O VOC (Voice of Customer): Datos (quejas,

cuestionarios,
comentarios,
investigaciones
de
mercado,
etc)
que
representan la perspectiva/necesidades de los clientes de la empresa; debe

traducirse a requisitos medibles para el proceso.
X: Variable empleada para indicar factores o medidas en la entrada te un

proceso o sistema empresarial.
Y: Variable empleada para indicar factores de medidasd en los resultados de

un proceso o sistema empresarial. Equivale a los resultados.
INTRODUCCIN
Cambiar la forma de hacer las cosas en direccin de encontrar la demanda
de los clientes externos o internos, e incrementar los beneficios, ha venido
siendo uno de los asuntos con mayor prioridad en las organizaciones hoy en
da. En el pasado, el cambio en las organizaciones se daba realmente lento.
Algunas compaas podran sobrevivir o simplemente prosperar en el
entorno y conservar los procesos estables. En nuestros das, sin embargo, la
competencia en el negocio es mas fuerte cada da, convirtindose en un
peligro continuar haciendo las cosas de la forma como se han realizado en el
pasado.
Como resultado, la necesidad por el cambio a largo y corto plazo se
incrementa ms, donde muchas organizaciones sienten la necesidad por
mejorar sus operaciones de cualquier forma en que se encuentren
posibilitados en hacer cada da las cosas mucho mejor.
Si el cambio ha sido bien guiado y planeado, pueden llegar a resultar nuevas
oportunidades, crecimientos, y un incremento en los beneficios para la
organizacin. Compaas como General Electric, Motorola, y Allied Signal
han hecho extraordinarias ganancias por el cambio cultural de los
trabajadores gracias a la iniciativa de Seis Sigma.
Durante mucho tiempo la Divisin Servicios de Informacin (DSI) de la
Universidad Industrial de Santander (UIS) ha construido una gran variedad
de proyectos de informacin tecnolgica que han sido elaborados utilizando
diferentes metodologas de desarrollo de software, las cuales han logrado
que los sistemas de informacin cumplan con las necesidades del cliente y
de cierto modo alcanzando un alto nivel de satisfaccin.
Este proyecto se justifica debido a la necesidad de integrar en un solo marco

metodolgico, un estndar en el que se tenga en cuenta una serie de fases y
pasos, para el desarrollo formal y eficiente de procesos, y especialmente de
software. As mismo permitir crear una nueva alternativa en el desarrollo de
proyectos de informacin tecnolgica, que sea propio de la DSI, en donde se
mejore la calidad del producto final, basado en las necesidades, satisfaccin
del cliente y en la eliminacin de defectos.
El desarrollo de este proyecto traer beneficios para toda la comunidad
universitaria, y podr ser asumido por el personal involucrado en la DSI dado
que es un modelo que busca resultados finales satisfactorios tanto para los
diferentes tipos de clientes como para los directores del proyecto.
El proyecto nace de la necesidad de buscar una solucin a los problemas
que se presentan en el desarrollo de proyectos de informacin tecnolgica,
como son: productos entregados en lapsos de tiempo mas largos de los
esperados por los directores del proyecto y los clientes, el nivel de calidad de
los servicios que presta el proyecto a los clientes finales, la no satisfaccin
total del cliente con el producto utilizado, entre otros.
Esto conlleva a un
mayor gasto de los recursos destinados al desarrollo del proyecto.

El estudio de la metodologa Seis Sigma nos ofrece una nueva alternativa
para
desarrollar
proyectos
de
informacin
tecnolgica,
basados
principalmente en la satisfaccin total del cliente final y la mejora en los

procesos y productos.
1. PRESENTACIN
1.1
DESCRIPCIN DEL DOCUMENTO
Esta seccin servir de gua al lector al momento de querer estudiar el

proyecto paso a paso y a la vez facilita el entendimiento y comprensin del
mismo.
La intensin del documento es ser comprensible a cualquier tipo de lector,
sin importar su grado de preparacin en el tema, por lo cual, se muestra el
proceso que se llev a cabo en el desarrollo del proyecto dejando ver la
fundamentacin terica utilizada como referencia.
Este libro est dividido en dos partes principalmente. La parte I contiene los
captulos del 1 al 8, donde se encuentra la metodologa Seis Sigma en
general, con todas las fases del modelo y cada uno de los pasos de cada
fase. La parte II que contiene los captulos del 9 al 15, que contiene los
resultados que se hicieron del modelo en el proyecto piloto de consulta del
material bibliogrfico de la Biblioteca de la Universidad va web, adems de
las conclusiones, recomendaciones, referencias bibliogrficas y anexos.
En el captulo 1 se presentan los antecedentes para la realizacin del
proyecto, el objetivo general y los objetivos especficos descritos en el plan
del proyecto.
El captulo 2 presenta las generalidades de Seis Sigma y los principios

escenciales.
El captulo 3 describe la primera fase del modelo, la fase Definir, con todos
los pasos, donde se presenta la descripcin del problema y las necesidades
del cliente.
El captulo 4 describe la fase Medir del modelo y los pasos, donde se
cuantifica el problema.
El captulo 5 describe la fase Analizar del modelo y los pasos, donde se
analizan y encuentran las mejores soluciones que van a resolver el
problema.
El captulo 6 describe la fase Disear y los pasos, que guiarn el diseo de
las soluciones que se han considerado como las ms ptimas.
El captulo 7 describe la fase Desarrollar y todos los pasos, que guiarn el
desarrollo de las soluciones.
El captulo 8 describe la fase Validar y todos los pasos, que ayudan a
verificar que el proyecto cumpli con los objetivos planteados.
El captulo 9 describe los resultados de los pasos de la fase Definir del
proyecto piloto de la biblioteca.
El captulo 10 describe los resultados de los pasos de la fase Medir en el
proyecto piloto.
El captulo 11 describe los resultados de los pasos de la fase Analizar en el
proyecto piloto.
4
El captulo 12 describe los resultados de los pasos de la fase Disear en el

proyecto piloto.
El captulo 13, contiene los resultados de los pasos de la fase Desarrollar del
proyecto piloto, hasta el paso de construccin, como se indic en el objetivo
especfico.
El captulo 14 y 15 contienen las conclusiones y recomendaciones para tener
en cuenta en la continuidad del proyecto.
Finalmente se encuentra las referencias bibliogrficas y los anexos que
complementan al documento.
1.2
ANTECEDENTES
1.2.1 Metodologa Seis Sigma.
Seis Sigma se desarroll en Motorola a finales de los ochenta como un modo

de proporcionar una orientacin clara a la mejora de la direccin y el
rendimiento empresarial. El concepto, las herramientas y el sistema Seis
Sigma han evolucionado y se han expandido a lo largo de los aos por
empresas como GE y AlliedSignal / Honeywell, lo que ayud a mantener un
renovado inters y a redoblar los esfuerzos en la mejora de la calidad y de
los procesos.
Seis Sigma mide y refleja estadsticamente la capacidad real de los
procesos, correlacionndolos con caractersticas como los defectos por
unidad y la probabilidad de xito o de fallo. Su valor radica en transformar
5
una visin cultural basada en la complacencia, a una basada en el logro en

toda una gama de sectores industriales.
Muchas compaas funcionan a un nivel de cuatro sigma, tolerando 6.210
defectos por un milln de oportunidades. El operar a un nivel Seis Sigma
implica un ambiente prcticamente libre de defectos, permitiendo solo 3,4
defectos por milln de oportunidades:
los productos y servicios son
prcticamente perfectos (99.99936%) eliminando los defectos se eliminan las

insatisfacciones.
Seis Sigma ha ayudado a Motorola a realizar grandes cambios en la lnea
baja de su organizacin.
De hecho, ellos argumentan que los esfuerzos
realizados de Seis Sigma en la compaa han significado un ahorro en

costos de 16 billones de dlares. Desde entonces, cientos de compaas
alrededor del mundo han adoptado Seis Sigma como la manera de hacer
negocios. Los resultados hablan por s solos
Por citar, compaas como Motorola, Allied Signal, General Electric,
Honeywell y Ford, han reducido en costos mas de 9,8 Billones de dlares en
promedio cada una en un periodo de 5 aos.
La metodologa Seis Sigma trabaja para reducir costos e incrementar la
satisfaccin del cliente, mediante la mejora de procesos de produccin. Si
observamos
al
departamento
de
informacin
tecnolgica
como
un
departamento donde se produce, entonces podemos aplicar Seis Sigma, ya

que poseemos una fbrica donde producimos sistemas de informacin,
centros de datos, servidores, redes, clientes externos e internos.
1.2.2 Mdulo de consultas del catlogo bibliogrfico de la Bilbioteca

va web.
La biblioteca de la Universidad Industrial de Santander UIS, actualmente no
tiene un sitio Web, estructurado de primer nivel, donde los usuarios puedan
acceder a todos sus servicios y a informacin general de la misma. En la
actualidad la biblioteca cuenta con un espacio dentro del Web site
institucional, pero esto ha generado ciertos inconvenientes, descritos a
continuacin:
La estructura de mens del Web site institucional, esta diseada de tal

forma que la publicacin de la informacin de la biblioteca est ubicada
en una pgina de tercer nivel, sin ningn acceso directo desde la pgina
principal. Lo anterior conduce a que la informacin no sea fcilmente
accesible por el usuario.
La informacin de la biblioteca est publicada de manera lineal,

convirtindola en un sitio de difcil navegacin, haciendo uso obligatorio
de extensas barras de desplazamiento; adems casi toda la informacin
publicada es esttica, con pocos accesos a servicios dinmicos.
Debido a que la pgina es administrada por otra seccin de la

Universidad (DSI), todos los cambios que se deseen realizar a la
informacin a publicar, deben ser autorizados por esta seccin. Dicho
procedimiento conlleva un trmite jerrquico haciendo que la informacin
pierda vigencia.
La biblioteca cuenta con una variedad de servicios que pueden

implementarse de manera dinmica en un sitio Web, hoy en da se hacen
altas inversiones en obtener informacin de calidad, pero no se han
desarrollado los medios apropiados para ofrecer todos estos bancos de
informacin al servicio de los usuarios.
Actualmente existe una versin en Web del catlogo bibliogrfico en

lnea, pero dicho desarrollo necesita una evaluacin de sus procesos y
decidir mejorar o disear una nueva aplicacin con un nuevo enfoque.
Existe alrededor de 30 Bancos Bibliogrficos (Bases de Datos), en

distintos formatos (CD-ROM en Internet), el problema que se presenta es
que estos bancos estn empaquetados independientemente, dificultando
a los usuarios el acceso a ellos, esto conlleva a que los recursos no estn
siendo suficientemente aprovechados.
Los avances tecnolgicos hacen necesaria la construccin de un Web

site propio, que le permita a la biblioteca estar a la vanguardia de la
informacin y ofrecer a sus usuarios servicios giles, de acuerdo a las
necesidades virtuales que el mundo actual exige.
1.3
OBJETIVOS
1.3.1 Objetivo General.

Analizar y definir los pasos de la metodologa "Seis Sigma" para que sea otra
alternativa de modelo de desarrollo de proyectos de informacin tecnolgica
de la Divisin de Servicios de Informacin, y aplicar esta metodologa en el
desarrollo de un mdulo de la nueva interface Web del sistema de
informacin de la Biblioteca de la UIS, LIBRUIS.
1.3.2 Objetivos Especficos.
Presentar una visin general de la metodologa Seis Sigma.

Definir y describir los pasos clave en nuestro modelo de desarrollo
DMADDV para que sirva como alternativa gua en el desarrollo de los
8
proyectos de informacin tecnolgica de la Divisin de Servicios de

Informacin de la UIS.
Aplicar la metodologa descrita en el modelo DMADDV a travs de la
elaboracin de un mdulo del proyecto: Interfase Web del sistema de
informacin de la biblioteca de la UIS, desarrollando los pasos que sean
aplicables al proyecto de las fases: Definir, Medir, Analizar, Disear y
Desarrollar hasta finalizar el paso de construccin.
Capacitar al personal de la Divisin de Servicios de Informacin, en los
mtodos, herramientas y filosofa que utiliza la metodologa Seis Sigma.
2. GENERALIDADES DE SEIS SIGMA
2.1
HISTORIA Y EVOLUCIN
La historia de Seis Sigma empieza en la dcada de los aos ochenta en

Motorola, donde primero fue desarrollado y probado. En 1983, el ingeniero
Bill Smith concluy que, si un producto era defectuoso y se correga durante
la produccin, entonces otros defectos probablemente se estaban pasando
por alto y posteriormente sera detectados por los clientes. En otras palabras,
los ndices de fallos en el proceso eran muy superiores a los indicados por
los controles finales de productos.
Cul era su argumento?
Si los
productos se montaban completamente libres de defectos, entonces

probablemente no le fallaran ms tarde a los clientes.
Este fue el punto de partida de Seis Sigma. El doctor Mikel Harry, fundador
del instituto de investigacin de Seis Sigma de Motorola, posteriormente puli
la metodologa, para no solo eliminar las prdidas en los procesos, sino
tambin convertirla en moneda de crecimiento, sin importar el tipo especfico
de servicio, producto o sector del mercado.
2.2
DEFINICIN DE SEIS SIGMA
Seis Sigma se puede definir como una filosofa de gestin que enfoca sus
esfuerzos en prevenir defectos, reducir la variacin y aumentar la satisfaccin
del cliente. Seis sigma hace referencia a un objetivo de rendimiento que
10
mide un proceso en trminos de defectos, en el cual un nivel Seis sigma

implica tener 3,4 defectos por milln de oportunidades.
Las estadsticas en la metodologa son pieza fundamental, ya que su objetivo
principal es de reducir la variacin y prevenir los defectos, adems se han
convertido en una nueva filosofa de administracin que incluye: decisiones
basadas en hechos, focalizacin en el cliente y trabajo en equipo.
Mientras otras iniciativas de produccin y de calidad, que prometen grandes
beneficios, frecuentemente fallan en las entregas del producto final, Seis
Sigma si las entrega. Priorizar los procesos, significa menos horas de trabajo
que da como resultado menos costos, mejorando as la satisfaccin del
cliente y creando un efecto positivo en los niveles ms bajos del esquema
organizacional.
1
Tabla 1. Comparaciones de los niveles de Seis sigma

Comparaciones de los niveles de Seis Sigma
Nivel
Porcentaje
Numero de defectos por un milln
Sigma
Correcto
de oportunidades
30.9
691.462
62.2
308.537
93.3193
66.807
99.3790
6.210
99.9767
233
99.99966
3.4
Estadsticamente Seis Sigma basa sus indicadores en la Tabla 1, donde un

nivel 4 de Seis Sigma corresponde a mas del 99% de exactitud. En el estudio
que
se realiza, se tiene como expectativa llegar a un nivel de 3 sigma,
Fuente: Libro Six Sigma Software Development por Tayntor Christine.

AUERBACH, Cp 1, Pg. 4.
11
Editorial
considerando un xito total con este nivel alcanzado, ya que empresas que
han iniciado con esta nueva filosofa demoran dos o tres aos en llegar a
estos niveles de Sigma.
Aplicar esta metodologa en la Universidad va mas all de medir y eliminar
defectos, implica una forma de hacer negocios, de tal forma que Seis sigma
se incorpore en nuestra cultura organizacional y llegue a ser una de las
cosas que nos haga diferentes en nuestro medio competitivo.
2.3
PRINCIPIOS DE SEIS SIGMA
Una organizacin Seis Sigma incluye los siguientes principios:

1.
Prevenir Defectos
2.
Reducir la Variacin
3.
Orientacin en el cliente
4.
Toma de decisiones basadas en hechos
5.
Trabajo en equipo
2.3.1 Prevenir defectos.
Seis Sigma difiere de las dems metodologas de calidad total gracias a la

insistencia de eliminar los defectos por medio de la prevencin ms que la
correccin de estos.
Clsicos mecanismos de control de calidad se basan en inspeccionar
productos para encontrar defectos y luego corregirlos. Seis sigma analiza los
procesos para determinar qu causa estos defectos y luego los mejora con el
fin de prevenir los errores. En la tabla 2 se muestra este efecto.
12
Tabla 2. Seis Sigma Vs Control de Calidad

Accin a
tomar
Control
de
Calidad
Seis Sigma
Accin en
Inspeccionar
Producto
Analizar
Proceso
El efecto es
Correccin
del
Error
Prevencin
defecto
Impacto
Un
Constate
producto
del
Repeticin
en
Todos
los
productos
Nunca
El objetivo de Seis Sigma es identificar los defectos antes que el producto

2
salga de fbrica y sea entregado al cliente; el costo por baja calidad (COPQ )
puede incurrir en diferentes elementos como son:
Prdida: el producto no puede ser usado.
Repeticin de trabajo: esfuerzo requerido para corregir el error
Inspeccin: costo de realizar rendimiento de control de calidad
Reportes: esfuerzo involucrado en desarrollar y monitorear reportes.
Mientras muchas compaas se enfocan en la prdida y la repeticin, el
costo por inspeccin y reportes puede superar a la prdida o la repeticin,
particularmente en el servicio. En muchos casos, los empleados invierten
gran parte de tiempo desarrollando mtodos informales para corregir los
defectos antes de que la auditora del control de calidad los reporte.
2.3.2 Reducir la Variacin.
El segundo principio de Seis Sigma es reducir la variacin, en otras palabras

aumentar la consistencia.
Esta es una forma de prevenir defectos. La
consistencia es importante por que puede ser predecible, y aquello que es

predecible puede perfeccionarse.
2
COPQ: Cost Of Poor Quality. Costos atribuidos a las imperfecciones en los procesos o
servicios que se entregan.
13
Como se muestra en la figura 1, el jugador de la izquierda aparenta ser el

mejor, porque apunto al blanco en una ocasin, una empresa Seis sigma
prefiere la consistencia del jugador de la derecha, aunque ste nunca golpe
en el centro, la puntera de este jugador es consistente.
Figura 1. Representacin de la variacin.
2.3.3 Orientacin en el Cliente.
El cliente es una pieza fundamental en el desarrollo de Seis Sigma, sean

clientes externos (aquellos que compran los productos o servicios que la
compaa vende), o clientes internos (que son los que usan los servicios que
otro departamento les provee), estos son el punto central en todas las
actividades.
Compaas Seis Sigma saben que clientes satisfechos y
aumento en las ganancias no son mutuamente excluyentes, por el contrario,

aumentar las ganancias es un resultado directo en la fuerte orientacin en el
cliente. Los clientes quieren y desean productos y servicios perfectos.
14
Proyectos Seis Sigma comienzan con escuchar la voz de los clientes, lo que
significa, entender sus necesidades y cuales son los requerimientos ms
importantes para l.
La presencia del cliente no termina cuando los
requerimientos son identificados y se da inicio al proyecto, durante todo el

ciclo de vida del proyecto existe una constante comunicacin entre las dos
partes, y es mucho ms que la entrega de reportes peridicamente, de esta
forma se asegura que el cliente sea una parte del proceso y que los
resultados garantizaran los requerimientos identificados.
2.3.4 Decisiones basadas en hechos.
Uno de los puntos que resaltan ms a Seis Sigma de las otras metodologas,
es la insistencia en que las decisiones sean basadas en hechos concretos.
Es importante entender exactamente como es que opera el proceso antes de
realizar cualquier cambio. Suena algo bsico y lo es; pero muchas veces en
la prisa de mostrar el progreso en la solucin del problema, las compaas
fallan en entender exactamente qu es lo que estn cambiando antes de
empezar a implementar esta modificacin. El resultado de esta falla pueden
ser inesperados efectos secundarios o dicho de otra forma defectos.
Las compaas que utilizan Seis Sigma, saben que entender qu es lo que
realmente el cliente quiere es fundamental. No simplemente la percepcin
del equipo de trabajo sobre las necesidades del cliente.
Un producto o
servicio defectuoso es algo que el cliente no utilizar o comprar.

La razn por la cual las decisiones deben ser basadas en hechos es simple;
teniendo todos los hechos antes de realizar cualquier cambio la compaa
puede eliminar la repeticin del trabajo y la prdida causada por soluciones a
problemas incorrectos.
15
2.3.5 Trabajo en Equipo.
El trabajo en equipo es una de las caractersticas de compaas Seis Sigma.

Para determinar la causa de la variacin y poder desarrollar mtodos para
prevenir los defectos, se requiere la gente correcta trabajando unida para
resolver el problema, compartiendo su conocimiento y experiencia.
Los miembros del equipo son seleccionados y valorados segn su
conocimiento
experiencia,
no
por
su
posicin
en
el
diagrama
organizacional.
2.4
HERRAMIENTAS Y ENTRENAMIENTO
Uno de los principales objetivos de Seis Sigma es reducir la variacin, para

esto los proyectos de Seis Sigma usan procesos y herramientas estndar,
mas all de que cada equipo de trabajo desarrolle sus propios mtodos y
tcnicas para solucionar los problemas.
Esto no solo incrementara la
consistencia si no que reducira el tiempo y los costos de los equipos en

reinventar los procesos.
Seis Sigma reconoce que el entrenamiento es necesario para que los
empleados entiendan la filosofa y la mejor forma de implementarla, para
esto existen cinco niveles de programas de entrenamiento formal:
Green Belt: Constan de ms de dos semanas, y proveen a los
participantes,
conocimiento
bsico
en
los
conceptos
herramientas.
Black Belt: Es un entrenamiento ms profundo, cerca de cuatro
semanas, con ms nfasis en herramientas de anlisis estadstico.
16
Master Black Belt: reciben un entrenamiento ms especializado en

herramientas estadsticas, y son los encargados de guiar y servir
3
de mentores para los Black Belts en sus proyectos.

Champions: son los encargados de que los recursos se encuentren
disponibles para su uso, y se encuentran involucrados en las
revisiones del proyecto.
Lderes Ejecutivos: son los encargados de comprometerse con
Seis Sigma y difundirla por toda la organizacin.
Los entrenamientos se van dando a medida que se va desarrollando el
proyecto, la razn est en que es ms efectivo estar aplicando en el mundo
real lo que se est estudiando en teora.
Seis Sigma se describe como una estrategia ms que como una iniciativa, y
aunque suenan similares, no lo son.
Iniciativa se define como el paso
introductorio mientras que estrategia es un cuidadoso plan o mtodo, una

diferencia realmente importante. Con nfasis en el anlisis y en las
decisiones basadas en hechos, se proveer un mtodo para el mejoramiento
de nuestra organizacin.
Para realizar esto, tres cosas deben estar correctas. La gente correcta debe
trabajar en el problema correcto, en la direccin correcta.
Seis
sigma,
bas
sus
fundamentos
principalmente
en
el
mbito
organizacional y de procesos, antes de ser utilizado para el desarrollo de

software.
El DMAIC
se convirti en la metodologa utilizada por las
compaas para aplicarlos tanto a la mejora como al diseo y rediseo de

procesos.
3
4
Mentor: Consejero o gua

DMAIC: Acrnimo de Define, Measure, Analyze, Improve and Control.
17
Las fases que componen este modelo son las siguientes:

Definir los proyectos, los objetivos y los entregables a los clientes.
Medir el rendimiento actual del proceso
Analizar y determinar lo que est mal, las causas races de los defectos y
las posibles soluciones
Mejorar
los
procesos
para
eliminar
los
defectos
mediante
la
implementacin de las soluciones

Controlar
el rendimiento del proceso mejorado asegurando que los
cambios se mantengan
Como lo mencionamos anteriormente, este modelo aplica nicamente al
mejoramiento de los procesos. En el rea de desarrollo, Seis Sigma utiliza
5
un modelo tambin de cinco fases, conocido como DMADV , que

especficamente se utiliza cuando un producto o un proceso no existe en la
organizacin y debe ser desarrollado.
Estas cinco fases son las que a continuacin se mencionan:
Definir los proyectos, los objetivos y los entregables a los clientes.
Medir y determinar las necesidades y especificaciones del cliente
Analizar las opciones de los procesos para determinar las necesidades
del cliente
Disear detalladamente los procesos para satisfacer las necesidades del
cliente
Verificar el rendimiento del diseo y si se cumplieron los requerimientos
del cliente.
DMADV: Acrnimo de Define, Measure, Analyze, Design and Verify
18
As como Seis Sigma ayuda a las compaas a eliminar defectos, reducir

costos y mejorar la satisfaccin del cliente en sus procesos de manufactura,
igualmente puede aumentar la efectividad en los tradicionales procesos de
6
El estudio se centrar en el modelo definido como DMADDV utilizado para el

desarrollo de nuevos proyectos software. Adems la definicin y descripcin
de los pasos que el equipo de trabajo considere deban conforman cada una
de las fases del modelo.
Las seis fases que componen el modelo son: Definir, Medir, Analizar,
Disear, Desarrollar y Verificar, son las que este proyecto tiene el propsito
de analizar y definir los pasos que las componen, como se ver en los
captulos siguientes.
DMADDV: Acrnimo de Define, Measure, Analyze, Design, Develop and Verify
19
3. FASE DEFINIR
La primera fase en el modelo DMADDV es definir. Esta fase establece el

7
escenario de un
proyecto Seis Sigma eficaz, ayudando a responder las
siguientes cuatro (4) preguntas:

Cul es el problema o la oportunidad que se va a tratar?
Cul es el objetivo? Es decir qu resultados se quieren conseguir y
cuando?
Quin es el cliente al que sirve o sobre que impacta este proceso y su
problema?
Cul es el proceso que se est investigando?
Es de vital importancia iniciar un proyecto Seis Sigma definiendo de forma
clara y especfica el problema a tratar. Este es el propsito de la fase definir.
Los pasos claves que definimos para esta fase son:
1.
Entender el modelo del negocio.
2.
Definir el problema.
3.
Definir los roles y las responsabilidades.
4.
Formar el equipo de trabajo.
5.
Identificar los clientes.
6.
Identificar lo crtico para la calidad (CTQs).
7.
Desarrollar el plan del proyecto.
DMADDV: Siglas del acrnimo Definir, Medir, Analizar, Disear, Desarrollar y Verificar.
20
8.
Establecer el cuadro resumen del proyecto.
9.
Definir el vocabulario especfico.
10. Identificar los procesos actuales.

11. Presentar al comit para aprobar.
3.1
Cada organizacin para alcanzar su misin, visin y objetivos, organiza sus

actividades por medio de un conjunto de procesos, de tal forma que se
pueda entender la funcionalidad de sta. Estas reglas tienen que permitir a
la organizacin ser competitiva en la medida que los requerimientos del
mercado lo van exigiendo.
Para que el proyecto que se vaya a construir pueda dar valor al negocio que
lo utiliza y a sus clientes, se debe tener en cuenta la comprensin del
contexto del sistema mediante un modelo del negocio.
La finalidad del
modelo del negocio es describir cada proceso del negocio, especificando sus
datos, actividades, roles y reglas.
Las siguientes preguntas servirn de ayuda para definir los proyectos segn
el modelo del negocio:
Cules son las razones del negocio que obligan a emprender este
proyecto?
El proyecto tiene una relacin directa con las metas y objetivos del
negocio?
Qu salidas dominantes de los procesos del negocio puede el proyecto
solucionar y cmo?
21
3.2
DEFINIR EL PROBLEMA
En la organizacin, la gente clave de la alta direccin debe estar convencida

de que el cambio es algo necesario. Adems, deben creer en la iniciativa de
Seis Sigma y procurar manejar los siguientes tres aspectos: la identificacin
de la nueva orientacin que debe darse para que el cambio sea realizado, el
cambio cultural que ocurrir internamente, y la respuesta de las personas
impactadas por el cambio.
La mayora de las actividades en la etapa preliminar a la implementacin de
Seis Sigma sern realizadas por el Comit de direccin de proyectos. Las
responsabilidades de ste comit son las siguientes:
1. Guiar y dirigir los pasos iniciales en el proceso de Seis Sigma.
2. Asegurar los recursos y el soporte para los proyectos de Seis Sigma.
3. Mantener enfocada a la organizacin en los esfuerzos de Seis Sigma y
encontrar formas ms eficientes y efectivas para llevar a cabo las
actividades planeadas.
4. Establecer guas para resolver problemas interdepartamentales y
anticiparse a los problemas que el cambio pueda generar en la
organizacin.
Por lo tanto deber encargarse de involucrar a todo el
personal para que se incorpore a la iniciativa de Seis Sigma.

Iniciar el cambio dentro de la organizacin implica que el comit tambin
contemple los siguientes aspectos:
Desarrollar y mantener claramente las especificaciones del comit,

que ayudarn a guiarlo en su propio trabajo y proveerlo de la direccin
para el proceso entero de Seis Sigma.
Educar a la organizacin acerca de Seis Sigma, y las razones del por

qu esta iniciativa es tomada.
22
Comunicar los beneficios de Seis Sigma.
Este punto es el ms
importante para que los empleados se comprometan con la iniciativa.
Comunicar el costo y esfuerzo de dicha implementacin, sin olvidar

resaltar el margen costo/beneficio esperado.
Determinar los indicadores a ser utilizados para medir los resultados

logrados en el proceso.
Coleccionar, analizar, y distribuir los resultados de los proyectos a

travs de la organizacin. Esta es otra funcin de comunicacin con
todas las partes involucradas.
Adaptar los resultados de los proyectos de Seis Sigma a las

estrategias y la planeacin organizacional.
El principal rol que debe realizar el Comit de Direccin de Proyecto, es

identificar los asuntos o problemas potenciales.
Numerosas fuentes de
informacin pueden ser usadas para identificar proyectos de Seis Sigma,

algunas se mencionan a continuacin:
3.2.1 Retroalimentacin con el Cliente o VOC .

8
Es una fuente de informacin acerca de la funcionalidad de los procesos,

permitiendo identificar los problemas que estos procesos poseen y
posteriormente identificar las oportunidades para mejorarlos. Aunque, VOC
es una de las fuentes de informacin ms complejas y difciles de recolectar,
documentar, y mantener, sus resultados son ms efectivos.
3.2.2 Oportunidades externas.

El Benchmarking ofrece oportunidades a la alta gerencia que no se han
9
considerado previamente. Esta informacin puede sugerir nuevos mercados

para viejos o nuevos productos, o incluso nuevas lneas de negocio.
8
VOC: Siglas en ingles para Voz del Cliente (Voice Of the Customer).
23
3.2.3 Experiencia.
El comit debe sacar el mximo provecho de la experiencia y del
conocimiento de las personas que se encuentran directamente involucrados
en el proceso con el fin de identificar una oportunidad para la mejora o el
rediseo de un proceso.
Para definir el problema, el comit deber establecer las declaraciones de
una forma EMART , que significa:
10
Especfica. El problema tiene que ser cuantificado. Por ejemplo, se

reducir a un 12% la tasa de desempleo en el pas.
Medible.
Los resultados obtenidos deben ser medibles.
Para el
ejemplo anterior, la tasa de desempleo debe haberse medido

anteriormente en el pas. De lo contrario sera imposible llegar a medir
los resultados.
Alcanzable.
El objetivo debe ser realista.
Para el ejemplo, sera
imposible reducir la tasa de desempleo al 5%.
Relevante. El mejoramiento debe poseer un impacto de satisfaccin

en el cliente. En el ejemplo, el objetivo es relevante si el pas tiene un
alto ndice de desempleo.
Tiempo Lmite. El mejoramiento propuesto debe ser logrado en un

periodo de tiempo especfico. En el ejemplo, el tiempo lmite debera
ser medido en meses en lugar de aos.
Benchmarking: Es una poderosa herramienta para ayudar a las organizaciones a

comparar los procesos con sus competidores, y entender que hace a los productos o
servicios de otras organizaciones superiores
10
EMART: En ingls SMART (specific, measure, attainable, relevant, timebound)
24
La tabla a continuacin, representa la estructura de definicin del problema.

Tabla 3. Estructura de la definicin del problema.
Qu proceso esta implicado?
Qu?
Qu no esta funcionando?
Cul
es
la
deficiencia
oportunidad?
Dnde se observa el problema o

deficiencia?
Dnde / cundo?
Departamento.
Regin.
Sector.
etc.
Cundo se observa el problema

o deficiencia?
Hora del da / mes / ao.
Antes o despus de.
Etc.
Qu envergadura tiene el
problema/ deficiencia/oportunidad.
De qu envergadura?
Cmo medirlo?
Cul es el impacto del problema/

oportunidad.
Impacto?
Cules son los beneficios de

actuar o las consecuencias de no
actuar?
25
3.3
Una poderosa funcin de Seis Sigma es la creacin de una infraestructura

que asegura el recurso humano necesario para ejecutarlas actividades del
proceso. Estos individuos actan como agentes generadores de cambio.
Una de las tareas que se deben realizar al iniciar Seis Sigma es definir los
roles adecuados en la empresa y dejar claras sus responsabilidades.
Bsicamente existen cinco (5) participantes claves en el equipo de trabajo:
1.
Lderes ejecutivos.
2.
Patrocinadores.
3.
Master Black Belts (MBBs).
4.
Black Belts (BBs).
5.
Green Belts (GBs)
3.3.1 Lderes Ejecutivos
Son los presidentes ejecutivos responsables del desempeo de la empresa

en su conjunto, encargados de alcanzar las metas estratgicas de su
compaa a travs de Seis Sigma.
El papel fundamental de los lderes ejecutivos es decidir la implementacin
de Seis Sigma en la compaa y promocionarla pblicamente por toda la
organizacin. A medida que comienza esta iniciativa de cambios dentro de
la compaa, se debe ver con claridad el liderazgo, adems de la conviccin
de que Seis Sigma y sus resultados objetivos son la mayor prioridad para la
empresa.
26
A continuacin se mencionan algunos aspectos importantes con que deben

contar los lderes ejecutivos.
Determinacin: Deben creer firmemente que Seis Sigma tendr xito.
Confianza: La confianza es un motivador poderoso, los lderes ejecutivos
deben mostrar confianza no slo en la metodologa Seis Sigma, sino
tambin en las personas encargadas de llevarlo a cabo.
Integridad: Los lderes necesitan hacer lo que dicen que van a hacer. La
integridad estimula la lealtad y el respeto, dos motivadores para los
empleados de la organizacin.
Paciencia: Los lderes ejecutivos son responsables de llevar todas las
fases Seis Sigma con serenidad y bajo control.
Las funciones especficas de los lderes ejecutivos incluyen:
Establecer los roles que desempearn los miembros del equipo e
infraestructuras de la iniciativa Seis Sigma.
Seleccionar los proyectos especficos y asignar los recursos.
Revisar peridicamente el progreso de los proyectos en curso y aportar
ideas.
Ayudar a cuantificar el impacto Seis sigma en la empresa.
Evaluar los progresos e identificar los puntos fuertes y dbiles del
esfuerzo.
Compartir las mejoras.
Actuar como eliminadores de obstculos cuando los equipos identifiquen
barreras.
3.3.2 Patrocinadores
Los patrocinadores de Seis Sigma son individuos de alto nivel jerrquico que
entienden la iniciativa y estn comprometidos con su xito.
27
Las responsabilidades del patrocinador incluyen:

Definir y mantener objetivos amplios para los proyectos a su cargo, lo que
incluye definir la misin del proyecto, y garantizar que los objetivos estn
alineados con las prioridades de la empresa.
Orientar y aprobar los cambios de direccin o alcance de un proyecto, si
se requiere.
Localizar y negociar recursos para los proyectos.
Representar al equipo ante el grupo responsable y actuar como modelo a
seguir por los miembros del equipo.
Trabajar con los propietarios de los procesos para garantizar una
transicin sin dificultades hacia la conclusin de un proyecto.
Son los encargados de costear el presupuesto de los proyectos.
3.3.3 Master Black Belts (MMB)
Los MBBs brindan liderazgo tcnico al programa de Seis Sigma.
En
consecuencia deben saber todo lo que sabe un Black Belt y adems

entender la teora matemtica que sustenta los mtodos estadsticos.
Al
mismo tiempo ayudan a los BBs a aplicar esos mtodos en situaciones

inusuales. Cuando sea posible la capacitacin en estadstica debe estar a
cargo de un MBB, de lo contrario se produce el fenmeno conocido como
propagacin del error, es decir, los BBs transmiten errores a quienes tienen
el grado de GB, quienes a su vez transmiten errores a los miembros del
equipo. Adems
estn encargados de identificar, desarrollar, implantar,
actualizar, y eliminar las herramientas Seis Sigma a ser utilizadas.
28
3.3.4 Black Belts (BB)
Los Black Belts son personas que combinan las habilidades de liderazgo,
tcnicas, comunicacin y algn conocimiento estadstico.
Los BBs con xito normalmente comparten los siguientes rasgos:
Trabajan bien tanto por su cuenta como en equipo.
Conservan la serenidad bajo extrema presin.
Se anticipan a los problemas y actan sobre ellos inmediatamente.
Respetan a sus compaeros de trabajo y son respetados por ellos.
Inspiran a los dems.
Son capaces de delegar tareas a otros miembros del equipo y de
coordinar sus esfuerzos.
Comprenden y reconocen las habilidades y limitaciones de sus
compaeros de trabajo.
Demuestran una preocupacin sincera por los dems, por lo que
necesiten o quieren.
Aceptan las crticas correctamente.
Estn preocupados por los actuales procesos y resultados y quieren
mejorar el sistema.
Sus responsabilidades son:
Servir como mentores de los GBs.
Definir las mtricas de los proyectos.
Ayudar a determinar las herramientas para poder medir estas mtricas.
29
3.3.5 Green Belts (GB)
Los Green Belts son los lderes de proyectos seis sigma capaces de formar
equipos, colaborar con ellos y manejar esos proyectos de principio a fin.
Reciben una capacitacin que incluye gestin de proyectos, herramientas de
gestin y control de calidad, resolucin de problemas y anlisis descriptivo de
datos estadsticos.
Trabajan en los proyectos a tiempo parcial, normalmente en reas
especficas y delimitadas.
Aplican las herramientas Seis Sigma para
examinar y solucionar los problemas crnicos en proyectos dentro de sus

trabajos normales.
Ayudan tambin a recoger y
analizar datos, realizar
experimentos o conducir otras tareas importantes en un proyecto.
3.4
Dado que la mayor parte del trabajo Seis Sigma se lleva a cabo mediante
equipos, es necesario tener claridad sobre algunos aspectos que se deben
tener en cuenta en la seleccin de los miembros del equipo del trabajo.
Cuando se trata de equipos, muchas organizaciones sobrecargan un equipo
con todo tipo de personas cuyas habilidades puedan ser necesarias durante
el proyecto. No es sorprendente que los grandes equipos se muevan ms
lentamente y que sus miembros tiendan tambin a comprometerse y a
entusiasmarse menos.
Existen numerosas reglas de oro muy diferentes
sobre el tamao del equipo, pero el nmero ptimo para casi cualquier
proyecto es entre cinco y ocho. Un nmero mayor hace que la comunicacin
se haga demasiado compleja, que las decisiones sean ms difciles y que la
cohesin se debilite.
30
Las siguientes preguntas ayudarn a la hora de seleccionar miembros para

el equipo :
11
Quin posee los mayores conocimientos del proceso y mejores

contactos con el cliente?
Quin tiene los mayores conocimientos del problema o el mejor acceso
a los datos?
Qu habilidades o perspectivas clave sern necesarias durante el curso
del proyecto?
Qu grupos se vern afectados ms directamente por el proyecto?
Qu grado de representacin de direccin/supervisin/primera lnea es
ms probable que se necesite?
Qu habilidades, funciones o niveles organizativos se pueden obtener
segn sean necesarios durante el proyecto?
A menudo son necesarias diferentes habilidades y talentos para que las
mejoras del proceso funcionen correctamente. Una vez la gente se halle
dentro del programa Seis Sigma, el siguiente paso es darles los
conocimientos y las habilidades en las herramientas necesarias.
Un miembro del equipo, realiza el rol de usuario final , con el objetivo
12
principal de ayudar a determinar los requerimientos del proyecto a nivel de

negocio.
Es importante conformar el equipo de trabajo con gente que no solamente
tenga los conocimientos en un rea especfica, tambin es importante contar
con gente que tenga un conjunto de caractersticas personales, como las que
se muestran a continuacin:
11
12
Tomada del libro The Six Sigma Way

Rol de usuario final: llamados en ingls Functional owners.
31
Compromiso: el individuo debe creer en el proyecto y estar dispuesto a

hacer lo que sea necesario para que tenga xito.
Inclinado a actuar: el miembro del equipo debe
sentirse obligado a
finalizar el proyecto exitosamente.

Flexibilidad: los miembros del equipo deben estar dispuestos a adaptarse
al cambio, y adems involucrarse con l.
Innovacin: ser personas iniciadoras de ese cambio, buscando nuevas
formas de lograr los objetivos.
Influencia Personal: es altamente deseable que todos los miembros sean
bien respetados dentro de sus propias comunidades.
Trabajo en equipo:
tener la habilidad de relacionarse con los dems
miembros, compartiendo conocimientos y experiencias.

Tiempo disponible: los individuos que tienen una carga de trabajo
demasiado pesada no deben ser elegidos para el equipo de trabajo. No
sern lo suficientemente eficaces sino que tambin crearn desacuerdo
en el equipo por faltar a reuniones o por no poder entregar sus
compromisos a tiempo.
3.5
El pilar de la existencia de cada organizacin son en realidad sus clientes, ya

sean externos o internos se llegan a considerar socios del proyecto. Por tal
motivo, la identificacin de los clientes se convierte en un paso fundamental
de toda iniciativa y de Seis Sigma principalmente.
Saber qu es lo que
realmente los clientes quieren y no asumirlo es el punto de partida para que

cualquier proyecto sea exitoso, por que Seis Sigma nunca trata de manejar el
problema, simplemente trata de eliminarlo.
Los clientes de una organizacin juegan diferentes roles en la compaa, los
cuales se pueden identificar en las siguientes categoras.
32
Externos: es el grupo de clientes ms fcil de identificar, ya que son los

que pagan por usar el producto o utilizan el servicio.
Internos: son los que ayudan a crear el producto o servicio. Aquellos que
se encuentran involucrados en el proceso.
La segmentacin de clientes le da una ventaja competitiva a la organizacin,

ya que puede crear sus objetivos basados hacia donde se va a enfocar el
mercado. La clave es equilibrar y diversificar los esfuerzos para aprender de
diferentes grupos.
Los mtodos ms utilizados para encontrar la clasificacin de los clientes se
encuentra en la tabla 4. Los mtodos de la nueva generacin empiezan a
adquirir ms fuerza debido a las ventajas que dan con respecto a los
tradicionales, ya que plantean ser mtodos indirectos con los clientes. La
combinacin de estos mtodos depende de los clientes, el mercado, y los
recursos.
Los datos obtenidos son un arma fundamental para la toma de decisiones en
el proyecto o la compaa, por eso es importante invertir la cantidad
necesaria de recursos para obtener la informacin que brinde la ayuda
necesaria para el proyecto.
Tabla 4. Mtodos para clasificar a los clientes.
Tradicional
Sondeos.
Grupos focales.
Entrevistas.
Sistemas de reclamaciones formales.
Investigaciones de mercado.
Programas de compradores.
33
Nueva Generacin
Entrevistas y estudios especficos y
de multinivel.
Fichas para sondeos de opinin del
cliente.
Almacenamiento de datos (Data
Warehousing) y explotacin de datos
(Data Mining).
Auditorias a clientes o proveedores.
Despliegue de la funcin de calidad.
3.6
IDENTIFICAR LO CRTICO PARA LA CALIDAD (CTQS)
Identificar las caractersticas crticas para la calidad es el aspectos ms

importante que se debe tratar para solucionar el problema que se est
analizando en el proyecto y que influye directamente en la satisfaccin del
cliente.
Las CTQs representan las caractersticas que debe tener el producto o
servicio y son definidas por los clientes, el BB, y los GB. Se convierten en los
objetivos especficos del proyecto y deben tener las mismas caractersticas
de la definicin del problema: especfico, medible, alcanzable, relevante, y
en un tiempo especfico.
Al finalizar el proyecto los resultados sern evaluados basados en las CTQs,
si se cumplieron las metas de las medidas se califica al proyecto como
exitoso, de lo contrario, como fracaso. Debido a esta razn, se debe tener
gran cuidado en el momento de hacer la declaracin y sobretodo a lo que se
espera obtener como resultado.
3.7
La creacin del Plan de Proyecto es un proceso dinmico que da lugar a un

documento que dirige todo el diseo, desarrollo y futuro de un proyecto.
Agrupa cada uno de los resultados, los procedimientos, los recursos
necesitados para producirlos, y las medidas de calidad que deben cumplir
para ser aceptado. Este documento puede crecer y cambiar durante el ciclo
de vida de los proyectos. La planeacin de proyectos aumenta las
probabilidades de xito con la deteccin a tiempo de los problemas mediante
una constante supervisin.
34
El Plan de Proyecto se puede estructurar de muchas formas, pero

principalmente debe contener los siguientes componentes:
Definicin del alcance y objetivos.
Costo/ beneficio.
Presupuesto.
Riesgos.
Cronograma.
Una de las habilidades que debe poseer el responsable de esta tarea es la
administracin de proyectos, disciplina que busca la aplicacin de tcnicas,
conocimientos, y herramientas para abarcar proyectos que cumplan con los
requerimientos planificados.
3.7.1 Definicin del alcance y objetivos
El alcance es el que define y documenta las actividades especficas y los

resultados de un proyecto particular. Declarar el alcance sirve como base
para tomar decisiones futuras sobre el proyecto, este debe ser tan claro que
debe permitir especificar lo que contiene y lo que no contiene el proyecto.
Todo los miembros del equipo del Proyecto deben trabajar juntos para
desarrollar la declaracin del alcance, usando como gua los siguientes
tems:
La visin de equipo.
Revisin del modelo de negocios, anlisis de las necesidades y anlisis
de los procesos de nivel tecnolgico existentes.
Recursos humanos y financieros disponibles.
Calidad deseada del proyecto.
35
Lo que debe quedar documentado por el comit es:

La principal funcionalidad que ser implementada.
Los tipos de resultados que estn en el alcance y los que no.
Las fuentes de datos o bases de datos que estn dentro y fuera del
alcance.
La cantidad de unidades que sern afectadas y/o se espera usen el
sistema.
Lo que realmente esta fuera del alcance.
Los objetivos del proyecto son los criterios cuantificables que se deben
satisfacer para que el proyecto sea considerado acertado y a travs de los
cuales se mide el xito del mismo. A partir de los objetivos los miembros del
equipo, jefes del proyecto, usuarios finales, etc., determinan si el producto
final cumple con los requerimientos y en que grado o nivel de satisfaccin.
La estructura de la declaracin de los objetivos se puede estandarizar
bastante con los siguientes tres elementos:
Descripcin de lo que hay que hacer. La declaracin de los objetivos
debe empezar por un verbo (reducir, aumentar, eliminar), pero es
conveniente evitar verbos que sean demasiado ambiguos.
Un objetivo medible para los resultados deseados.
El objetivo debe
cuantificar el ahorro en costes perseguido, la eliminacin de defectos o la

reduccin de tiempo, en porcentajes o cifras reales. Si es demasiado
pronto incluso para realizar suposiciones, conviene dejar un marcador
que indique donde se planea aadirlo ms adelante. El objetivo medible
es el que su equipo y los directivos de la empresa van a utilizar para
evaluar el xito del proyecto.
Un plazo o marco temporal para los resultados. Es posible que tenga que
revisar posteriormente la fecha definida en la primera parte del proyecto,
36
pero establecer un plazo ayuda a reunir recursos y compromisos y acorta

el tiempo del ciclo del proyecto.
3.7.2 Costo/ Beneficio
EL anlisis de costo/beneficio de cualquier proyecto juega un papel

importante para la aprobacin e inicio, convirtindose en uno de los
fundamentos en cuales se basan los altos directivos para tomar la decisin
de aprobarlo y dar luz verde a su comienzo.
Las oportunidades del proyecto deben ser evaluadas segn los criterios
establecidos por el equipo y la alta direccin. Los siguientes tems se tienen
en cuenta para identificar si no existe alguna oportunidad atractiva y si este
proyecto no traer beneficios.
No estar de acuerdo con la voz del cliente.
Tiempo de desarrollo no lgico.
No entender claramente el proceso.
Conflicto de intereses entre los patrocinadores del proyecto.
Bajo retorno de inversin o poco valor agregado a la compaa.
Algunos de los mtodos utilizados para el anlisis del costo/beneficio son los
siguientes:
Tiempo -
valor del dinero:
Es considerado por los mtodos mas
sofisticados para realizar el anlisis de costo/beneficio.
Tambin es
conocido como el factor de descuento, es simplemente utilizado para

convertir el valor futuro del dinero en valor presente. Se basa en que el
dlar de hoy tiene mas valor que un dlar en unos aos debido a los
inters o a la ganancia que se pueda obtener.
37
Punto de equilibrio: Es el tiempo que tomara para que el total de los

ingresos incrementados o la reduccin de gastos sea igual al costo total.
Sin embargo no toma en cuenta el Tiempo Valor del dinero.
Los pasos para determinarlo son los siguientes:
1. Costo.
2. Ingresos incrementados totales o reduccin de gastos.
3. Formula.
Punto de Equilibrio = (Costo / Ingresos incrementados y/o
reduccin de gastos) X 12 (meses)
Periodo de Devolucin: Es el tiempo requerido para recuperar el monto
inicial de una inversin de capital. Este mtodo calcula la cantidad de
tiempo que se tomara para lograr un flujo de caja positivo igual a la
inversin total. Toma en cuenta beneficios como el valor asegurado. Este
mtodo indica esencialmente la liquidez del esfuerzo por mejorar un
proceso en vez de su rentabilidad. Al igual que en el anlisis de punto de
equilibrio, el anlisis del periodo de devolucin no tiene en cuenta el valor
del dinero en el tiempo.
Los pasos para determinarlo son los siguientes:
1. Costo.
2. Valor Asegurado.
3. Total ingresos incrementados y/o reduccin de gastos.
4. Frmula.
Periodo de devolucin = [( Costo Valor Asegurado) / total de
ingresos incrementados y/o reduccin de gastos] X 12 (meses)
38
Valor presente neto (VPN): El VPN representa el Valor Presente(VP) de

13
los flujos salientes de caja menos la cantidad de la inversin inicial (I).

VPN = VP I
El valor presente del flujo de caja futuro es calculado utilizando el costo
del capital como un factor de descuento.
El propsito del factor de
descuento es convertir el valor futuro del dinero en valor presente y se

expresa como 1 + la tasa de inters (i).
Si la tasa de inters es del 25%, el factor de descuento es de (1+ i). El
factor de descuento puede expresarse como (1+ 0.25) o 1.25
Los pasos para determinar el VPN son los siguientes:
1. Ingresos.
2. Valor Asegurado.
3. Factor de Descuento.
4. Inversin.
5. Formula.
VP = (Ingresos + Valor Asegurado) / (Factor de Descuento)
VPN = VP inversin (I)
Tasa interna de retorno
14
(TIR):
Es la tasa de inters que hace la
ecuacin de la inversin inicial (I) con el valor presente (VP) de los futuros
flujos de caja entrantes. Esto es, a la tasa interna de retorno I = VP o
VPN = 0.
13
14
VPN: Valor Presente Neto

TIR: Tasa Interna Retorno.
39
En el ejemplo anterior, la tasa era del 25%.
Por lo tanto cualquier
propuesta para mejorar un proyecto o procesos deber difcilmente

exceder esta tasa si se quiere considerar.
Cuando se calcula el TIR, el VPN se fija en cero y se resuelve para un
inters (i). En este caso, el factor de descuento es (1 + i) ya que no
conocemos el inters verdadero, solamente conocemos el inters
deseado.
Pasos para determina: el TIR
1. VPN.
2. Ingresos.
3. Valor Asegurado.
4. Factor de Descuento.
5. Inversin.
6. Formula.
VP = (Ingresos + Valor Asegurado) / (Factor de Descuento)
VPN = VP Inversin (I)
Para calcular el TIR, se lleva el VPN a cero y se resuelve para un
inters (i)
Si alguno de estos tpicos no existe no se inicializa el proyecto o se debe
definir la oportunidad nuevamente. Si existe la oportunidad, se dispone a
determinar el incremento en la eficiencia, eficacia y la adaptabilidad para
recuperar los costos de los recursos que consumir el esfuerzo.
inquietudes deben ser tratadas como lo son:
40
Varias
Quines sern los ms beneficiados por el mejoramiento del proceso?
Cules personas tienen inters en el rendimiento del proceso?
stas personas reconocern el valor agregado aadido?
Los mejoramientos realizados a los procesos, convertirn a la compaa

en una organizacin ms competitiva, en trminos de mejor rendimiento
en el proceso, incremento en la porcin del mercado, calidad e ingresos?
Finalmente para determinar los beneficios del proyecto que se presentarn al

comit o alta direccin de la compaa, el equipo de trabajo debe plantear los
siguientes puntos:
Impacto sobre los clientes y requisitos externos.
Es esto una
oportunidad importante para nuestros clientes?
Impacto financiero.
Existe la reduccin de costos, mejora de la
eficiencia, aumentos en las ventas, o ganancia en la cuota del mercado?.

Qu ganancia monetaria puede existir a corto plazo? Y a largo plazo?
(es recomendable ser realista o exponer una cifra atractiva pero por
debajo de lo que se estima, ya que en el momento de entregarse el
proyecto si la cifra es superada, se obtendr mayor xito).
Tendencia.
El problema empieza a tener un comportamiento de
crecimiento o de decrecimiento en el tiempo futuro? Que pasara si no

se hace nada?
Innovacin. Qu nuevos conocimientos de la empresa, de los clientes,

de los procesos o del sistema Seis Sigma podramos obtener con este
proyecto?
Gestin. Hasta qu punto ayudar este proyecto a dirigir los grupos de

la organizacin y a crear una mejor gestin del proceso global?
Por lo general en compaas que usan Seis Sigma, existen grandes Ys es

decir, Iniciativas ms importantes que el negocio se encuentra trabajando,
por lo general para aumentar ingresos, disminuir costos, mejorar el servicio o
41
algn otro tipo de beneficio. Si el proyecto no ataca una de estas grandes

Ys, entonces no se hace.
Se hacen llamar grandes Y debido a que se utiliza la ecuacin Y = f(x) ,
15
donde X es un problema u oportunidad que se tiene.
Si se modifica X,
entonces la Y se ve afectada. Por ejemplo si para la organizacin la meta

este ao es reducir costos entonces Y es Costos. algunos ejemplos de X
son:
-
Inventario no esta siendo bien mejorado.
Los sistemas actuales no estn midiendo bien lo que se esta

gastando.
Eliminar 500,000 de gastos de arriendo al ao haciendo lo

siguiente.
El departamento de informacin tecnolgica quiere migrar de

versin el servidor de correo electrnico por que la versin utilizada
ha sido usada por mas de tres aos.
El ltimo de los cuatro proyectos es el que no se realizar y se desecha

primeramente porque no afecta directamente la Y, que para el ejemplo es la
reduccin de costos.
3.7.3 Presupuesto
Nada se lleva a cabo sin dinero, y los proyectos de desarrollo de software no

son la excepcin. Existen muchas razones por la cuales se debe calcular los
costos antes de incurrir en ellos, la principal es poder estimar una idea de
cuanto costarn en trminos de dinero los objetivos propuestos.
15
Y = f(X). mayor profundizacin en el paso Determinar que medir, fase Medir
42
El presupuesto es una estimacin que se realiza y es responsabilidad del

lder del proyecto crear estndares para que el proyecto cumpla con las
expectativas esperadas bajo los costos predecidos.
Aspectos como
cronogramas razonables, recursos y expectativas de la alta direccin deben

ser tenidos en cuenta en la estimacin que realice el equipo de trabajo. A
continuacin se describen las metodologas de estimacin existentes para
calcular el presupuesto de un proyecto.
Cada una de las metodologas existentes poseen fortalezas y debilidades por
tal razn la utilizacin de varias metodologas como complemento unas de
otras podra ser de gran herramienta para el proyecto.
Analoga.
Busca proyectos similares realizados con anterioridad para compararlos, los

datos son agregados al proyecto en curso para realizar la estimacin. La
analoga slo puede ser utilizada por completo a nivel de sistema o de
componentes.
La mayor fortaleza de este mtodo es que se basa en la experiencia de
proyectos ya ocurridos,
las diferencias entre proyectos completados y
proyectos propuestos pueden ser identificadas y se facilitara estimar el

impacto. Las debilidades de la metodologa se observan al momento de
encontrar las diferencias entre proyectos y en la limitacin que existira si no
se encuentran proyectos similares o si los datos de los proyectos anteriores
no son confiables.
Abajo Arriba.
La metodologa identifica y estima cada componente individualmente y luego

combina los resultados para producir un estimado del proyecto total.
43
Una de las dificultades que presenta es cuando la informacin no se

encuentra disponible debido al proceso de ciclo de vida
16
seleccionado.
Adems tiende a utilizar demasiado tiempo para llevarse a cabo.
Arriba Abajo.
Se basa en las caractersticas ms sobresalientes del software. El proyecto

subdivide los componentes y las fases del ciclo de vida desde un alto nivel
hasta el ms bajo nivel.
Las ventajas que presenta son las consideraciones que tiene la metodologa
con actividades a nivel del sistema como integracin, documentacin, control
del proyecto, administracin, etc. ya que la mayora de las metodologas las
ignora. Es considerada una de las ms rpidas, fciles de implementar y que
requiere de pocos detalles para trabajar. Las desventajas son la falta de
precisin y la tendencia a pasar por alto los niveles bajos de los
componentes y los problemas tcnicos, adems ofrece muy pocos detalles
en la justificacin de las estimaciones.
Juicio Experto.
Utiliza el talento humano para estimar los costos del proyecto, busca las
personas con mayor conocimiento y experiencia en proyectos similares.
La ventaja se muestra en la experiencia que se utiliza para realizar la
estimacin, adems de ofrecer un valor agregado para establecer el impacto
del proyecto.
Es la metodologa que ms se utiliza aunque siempre es
complementada con otra.
Las desventajas se presentan al momento de
16
Ciclo de Vida: Metodologa para desarrollo de software, ver paso SELECCIN DE

METODOLOGA PARA DESARROLLO DE SOFTWARE, fase DISENAR.
44
documentar y justificar los factores que ha considerado el experto para el

proyecto.
Algoritmo o Parametrizado.
Involucra el uso de ecuaciones para mejorar el rendimiento de la estimacin,

y su mayor utilizacin es en proyectos de desarrollo de software.
Las
ecuaciones son basadas en investigaciones y datos histricos que son las

entradas como el conteo de lneas de cdigo fuente (CLCF ), numero de
17
funciones, y otros tipos de costos como lenguajes, metodologas de diseo,

habilidades, riesgos, etc.
Las ventajas de la metodologa se presentan ya que la generacin de
resultados pueden repetirse, son fciles de modificar, y las f
modificables para un mejor anlisis sobre los costos.
rmulas son
Sin embargo, los
resultados son cuestionables cuando la estimacin se realiza sobre

proyectos que utilizan nuevas tecnologas; las ecuaciones finales no tienen
la capacidad de trabajar bien con condiciones especiales, como personal que
no se hubiese tenido en cuenta para realizar trabajos extras, aunque ninguna
metodologa es tan flexible para no sentir el impacto de sucesos de ese tipo.
3.7.4 Riesgos
Los riesgos son parte inherente de todos los proyectos, de hecho, son un
factor esencial en el progreso. A pesar que algunos son inevitables, su
identificacin a tiempo y administracin adecuada aumenta las posibilidades
de xito de un proyecto.
17
SLOC: Counting source lines of code.
45
Antes de analizar cmo se administran los riesgos, se define riesgo como la

posibilidad de sufrir una prdida. Para un proyecto especfico, las
consecuencias pueden ser: un producto terminado con menor calidad,
aumento en los costos, retrasos en el cronograma de actividades, o no
alcanzar el propsito y la intencin del proyecto. En otras palabras, un riesgo
es un problema en espera de ocurrir.
Para poder analizar los riesgos,
se han considerado las siguientes
categoras:
Riesgos
del
proyecto:
identifican
los
problemas
potenciales
de
presupuesto, planificacin temporal, personal, recursos, clientes y

requisitos.
Si estos riesgos se hacen realidad, es posible que la
planificacin del proyecto se retrase y que los costos aumenten.
Riesgos
tcnicos:
Identifican
problemas
potenciales
de
diseo,
implementacin, de interfaz, de verificacin y de mantenimiento. Si estos

riesgos se hacen efectivos, la implementacin puede llegar a ser difcil o
imposible.
Riesgos del negocio: Amenazan la viabilidad del software a construir.

Los principales riesgos del negocio son: construir un producto o sistema
excelente que nadie quiere, construir un producto que no encaja en la
estrategia comercial de la compaa, construir un producto que el
departamento de ventas no sabe como vender, perder el apoyo de una
gestin experta debido a cambios de enfoque o a cambios de personal, y
perder presupuesto o personal asignado.
Para identificar los riesgos, suele ser efectivo crear una lista de
comprobacin de elementos de riesgo.
46
Est lista se enfoca en un
subconjunto de riesgos conocidos y predecibles, algunos de estos son

listados a continuacin en la tabla 5.
Tabla 5. Tipos de riesgos.
TIPO DE
RIESGO
Tamao del
producto
Impacto en el
negocio
Caractersticas
del cliente
Definicin del
proceso
Entorno de
desarrollo
Tecnologa a
construir
Tamao y
experiencia del
grupo de
Trabajo
DEFINICIN
POSBILES RIESGOS
Riesgos asociados con el tamao El tamao estimado del producto

general del software a construir o Tamao de las Bases de Datos
modificar.
creadas.
La cantidad de software
reutilizado.
Riesgos
asociados
con
las Efecto del producto en los
limitaciones de la gestin o del
ingresos de la compaa.
mercado.
Nmero de clientes que usarn
este producto.
Costos asociados por un retraso
en la entrega.
Costos asociados por un producto
defectuoso.
Riesgos asociados con el cliente y la Los clientes tienen diferentes
habilidad del desarrollador para
necesidades.
comunicarse con l en los momentos Los clientes tienen diferentes
oportunos.
personalidades.
Los clientes se contradicen a
menudo.
Los clientes estn dispuestos a
colaborar en el proceso.
Riesgos asociados con el grado de Est bien definido el proceso de
definicin del proceso del software y
software.
su seguimiento por la organizacin El anlisis, diseo y pruebas se
de desarrollo.
realizan sobre la marcha.
El equipo estima importante el
concepto de calidad.
Riesgos
asociados
con
la El cdigo generado por las
disponibilidad y la calidad de las
herramientas CASE es ineficiente.
herramientas que se van a emplear No se pueden integrar algunas
en la construccin del producto.
herramientas.
Riesgos
asociados
con
la El software interacta con
complejidad del sistema a construir y
hardware nuevo o no probado.
la tecnologa de punta que contiene La base de datos usada no tiene el
el sistema.
rendimiento que se esperaba.
Son los riesgos asociados con la Se dispone de la mejor gente.
experiencia tcnica y de proyectos de El personal tiene los
los ingenieros del software que van a
conocimientos adecuados.
realizar el trabajo.
Se cuenta con suficiente personal.
47
Un equipo de proyecto que funciona eficazmente mide los riesgos

continuamente y emplea la informacin para la toma de decisiones en todas
las etapas del proyecto. Existen dos enfoques distintos para la administracin
de riesgos. Uno es reactivo y el otro es proactivo. La administracin reactiva
de riesgos significa que el equipo del proyecto reacciona a las consecuencias
de los riesgos (los problemas reales) conforme ocurren. La administracin
proactiva de riesgos significa que el equipo del proyecto cuenta con un
proceso visible para administrarlos. Este proceso se puede medir y repetir.
El proceso de administracin proactiva de riesgos es el que se muestra a
continuacin en la figura 2.
Figura 2. Ciclo de anlisis de riesgos proactivo.

La identificacin de riesgos es el primer paso en el proceso de la
administracin proactiva de riesgos. Los riesgos deben identificarse antes de
que puedan administrarse. La identificacin de riesgos proporciona al equipo
del proyecto las oportunidades, indicios e informacin que le permiten ubicar
los riesgos principales antes de que afecten adversamente al proyecto.
48
Cuando se declara un riesgo, el equipo de trabajo no debe considerar slo

un sntoma, sino tambin un resultado. Por esa razn, la declaracin del
riesgo debe incluir lo que provoca que surja la situacin (esto es, la
condicin) y el resultado esperado (la consecuencia).
Para documentar
estos defectos y administrarlos eficientemente, se recomienda utilizar el

cuadro Analisis de los modos de fallo y efectos (AMFE ).
18
El anlisis de riesgos es el segundo paso en el proceso de administracin

proactiva de riesgos. Es la conversin de los datos de un riesgo a
informacin para la toma de decisiones respectiva.
La planificacin de acciones convierte la informacin sobre un riesgo en
decisiones y acciones. La planificacin implica desarrollar acciones para
enfrentar los riesgos individuales, establecer prioridades en las acciones para
un riesgo, y crear un plan integrado de administracin de riesgos.
El seguimiento es la funcin de vigilancia del plan de acciones para riesgos,
es esencial para la implementacin de un plan de acciones eficaz. Esto
implica establecer las unidades de medicin del riesgo y los eventos de
activacin necesarios para asegurar que funcionan las acciones planificadas.
El control de riesgos es el ltimo paso en el proceso de administracin
proactiva de riesgos. Se debe combinar con los procesos de administracin
de un proyecto para controlar los planes de acciones, corregir las variaciones
de los planes, responder a los eventos de activacin, y mejorar el proceso de
administracin de riesgos.
18
FMEA: Failure mode effect & analysis, ver anexo D.
49
3.7.5 Cronograma
El cronograma se convierte en un mecanismo utilizado en el proyecto para

planear los tiempos, las tareas, recursos y costos que se involucrarn.
En el momento de planear un cronograma se debe ser realista con las fechas
a establecer, la calidad del producto final, y el costo en que esto incurrir.
Para desarrollar el cronograma se deben seguir los siguientes pasos:
1. Identificar las actividades.
2. Establecer la secuencia de las actividades.
3. Duracin estimada de cada actividad.
4. Asignar los responsables.
5. Definir los recursos de cada actividad
6. Estimar los costos.
La identificacin de actividades se lleva a cabo utilizando diferentes mtodos,
como la lluvia de ideas, entre otros.
Las personas con ms experiencia
dentro del equipo en este tipo de proyectos, son de gran aporte en la

identificacin y en la depuracin de stas.
Despus de determinar las actividades y su secuencia, se debe estar seguro
de que la definicin de entregables y logros posean una fecha estimada de
cumplimiento.
En el momento de definir los logros se debe tener cuidado en diferentes
aspectos, como lo son:
Programar fechas de entregas irreales o no alcanzables, con el fin de

impresionar al comit.
No poseer una gran calidad en los objetivos.

50
Mover las actividades que se ha programado para un alcance de un logro,

hacia otro logro dentro del proyecto; sin tener en cuenta el impacto y el
nuevo cronograma en todo el proyecto.
Para estimar la duracin de cada actividad, se hace nfasis principalmente

en la experiencia de proyectos anteriores.
Si la actividad es totalmente
nueva, se deben utilizar diferentes escenarios que puedan ocurrir, como la

no prediccin de recursos, adaptabilidad y capacidad de los miembros para
esa actividad.
En el desarrollo de proyectos que involucran el desarrollo de aplicaciones
informticas existen modelos matemticos que se utilizan para estimar la
duracin de las tareas o actividades del proyecto, modelos como Puntos de
Funcin y COCOMO hacen parte del rea de ingeniera del software
Los
cronogramas
sufren
cambios
en
el
transcurso
del
proyecto,
convirtindolo en una actividad dinmica e iterativa.

Existen diferentes tipos de grficos para representar los cronogramas, el tipo
ms utilizado y preferido por la mayora de los lderes de proyecto es el
diagrama de GANTT, ya que es ms eficiente al momento de identificar
actividades y tiempos.
Permite comparar el cronograma con el de otros
proyectos fcilmente. Las fases y actividades se distribuyen de arriba abajo,

y el tiempo es representado de izquierda a derecha.
51
Figura 3. Diagrama de GANTT.

El diagrama de GANTT aunque es el grfico que mejor se hace entender,
posee algunas limitaciones, por citar algunas tenemos:
No identifica las semanas crticas entre las fases.
No posee coordinacin entre los recursos o los requerimientos en el

cronograma.
La decisin del tipo de grfico a utilizar es responsabilidad del lder del

equipo, y debe contar con la aprobacin de los dems miembros.
3.8
DESARROLLAR EL CUADRO RESUMEN DEL PROYECTO
Este cuadro es uno de los documentos ms importantes en un proyecto Seis

Sigma, se utiliza como resumen de toda la informacin clave del proyecto.
Su funcin principal es ayudar a los miembros del equipo a entender por que
se forma el equipo, que metas se desean alcanzar, cunto tiempo tomar el
proyecto y cunto tiempo el equipo dedicar a l.
Despus de documentar esta informacin el lder del proyecto o el GB
mantiene un control sobre lo que se defini de esta forma se evitarn los
malentendidos y por el contrario existir mayor focalizacin, en otras
palabras: menor variacin.
52
Este documento se inicia desde el primer encuentro con el equipo de trabajo

y los campos que no se completen en ste, se actualizarn a lo largo del
proyecto.
Existen muchas opciones para desarrollar y dar formato a un Cuadro de
Proyecto. El modelo que se puede utilizar para el proyecto se observa en el
anexo A.
3.9
En todos los proyectos se encuentran personas con diferentes perspectivas

con respecto a definiciones o conceptos de elementos que influyen
directamente en el proyecto, creando un vocabulario. Por lo tanto, se debe
realizar una investigacin sobre los significados que tienen para los clientes
cada uno de los trminos del vocabulario utilizado y as crear un lxico
comn para todos los involucrados en el proyecto. Por ejemplo, identificar si
un libro se encuentra en mal estado, puede significar para un estudiante
(cliente 1) que el libro se encuentre subrayado en varias hojas, mientras que
para otro estudiante (cliente 2) el que se encuentre subrayado no lo clasifica
como libro en mal estado.
La metodologa Seis Sigma busca la eliminacin de los defectos y la
satisfaccin del cliente, para el ejemplo, las insatisfacciones se consideran
como defectos.
Conocer estas definiciones nos ayudarn a eliminar los
defectos que causan insatisfaccin del cliente.

Esta tarea puede ser realizada con la voz del cliente de una forma
transparente para el cliente.
53
3.10 IDENTIFICAR LOS PROCESOS ACTUALES
Determinar los procesos crticos es uno de los pasos fundamentales dentro

de la fase definir. Identificar cuales son los procesos crticos y cuales no, es
responsabilidad del BB.
Al inicio de este paso, los siguientes interrogantes deben ser resueltos:
Qu productos o servicios produce el proceso?
Quin es el cliente?
Qu tcnica esta disponible para medir la satisfaccin del cliente?
Para determinar los procesos crticos, se deben contemplar los siguientes

pasos:
a. Entradas del proceso. Se refieren a los equipos, materiales, mtodos,
y el ambiente necesario para producir los productos o servicios.
b. Salidas del proceso.
Son los resultados del proceso, productos o
servicios.
c. Objetivos del proceso.
Es la definicin de los objetivos, metas, o
logros.
d. Voz del proceso. Es un mecanismo de realimentacin en el cual la
calidad del proceso puede medirse y examinarse en funcin de
encontrar las metas propuestas, indicando los niveles en que se
encuentra. Para entender la voz del proceso surgen las siguientes
preguntas que deben ser resueltas.
1. Qu caractersticas crticas del proceso pueden ser mejoradas
para que los servicios puedan encontrar las necesidades y las
expectativas de los clientes?
54
2. Cules metas a corto plazo pueden ser establecidas para que

las caractersticas crticas de los procesos puedan encontrar las
necesidades y expectativas de los clientes?
3. Son necesarias otras fuentes para proveer informacin en
busca de encontrar las nuevas metas?
4. Qu indicadores se utilizarn para medir dentro o durante el
proceso?
5. Existe un mtodo para recolectar datos del proceso?
6. El proceso actual se encuentra alcanzando los objetivos y
metas propuestas que se establecieron desde un comienzo?
e. Cliente.
Son los que usan los productos o servicios resultado del
proceso, convirtindose en los verdaderos jueces de la calidad del

producto. El cliente se convierte en lo ms importante en el proceso,
es la razn de la existencia del proceso.
f. Necesidades del cliente y expectativas.
Ilustra los atributos que
poseen los productos y servicios que los clientes requieren.
Esta
informacin puede ser suministrada por los patrocinadores o altos

directivos.
g. Necesidades del cliente. Se pueden entender como las expectativas
especficas del cliente. Seleccionar atributos cuantificables brindan la
oportunidad de alcanzar la calidad en servicios o en productos
esperados.
h. Voz del cliente.
Son los datos que representan la perspectiva o
necesidades de los clientes de la empresa, que deben traducirse a

requisitos medibles para el proceso. Antes de utilizar alguna tcnica
de recoleccin de datos, el BB debe tener conocimiento en las
siguientes preguntas:
Qu tanto satisface el proceso a los clientes?
55
Qu se intenta al salir a hablar con clientes y encontrar sus

necesidades y expectativas?
Los indicadores por los cuales se medirn los datos son

correctos?
Diferentes tcnicas se encuentran disponibles para identificar la voz

del cliente .
19
Medir la satisfaccin del cliente es importante para cualquier tipo de proyecto

dentro de una organizacin. El mecanismo ms usado es la realimentacin;
cualquier mecanismo es valido desde que los datos sean coherentes e
ntegros, y ofrezcan la informacin que se busca. La voz del cliente es un
punto que toma un largo periodo de tiempo en este paso, para compensar
eso, la voz del proceso entra a jugar un papel importante debido a que se
considera el espejo de la voz del cliente.
Para determinar cuales son los procesos ms crticos para el proyecto, se
regresa a la ecuacin de Y = F(x), como se explicaba anteriormente las X se
definen como los problemas que afectan directamente las Y, que son las
iniciativas de la compaa. En la mayora de las oportunidades se da que un
Y es afectada por varias X, esto da como resultado lo siguiente:
Y = F(x1,x2,,xn)
Por ejemplo, si la Y es reducir costos, las X pueden ser, pago de impuestos
(X1), nmina (X2), arriendo (x3), servicios pblicos (x4), etc. Se obtiene la
siguiente ecuacin:
Y = 200 x1 + 100 x2 500 x3 + 100 x4
19
Tcnicas para identificar la voz del cliente anexo B.
56
Por tal razn se selecciona a la x3 como el proceso ms crtico y se deben

enfocar todos los esfuerzos para solucionarlo, para el ejemplo, la x3 es el
arriendo, lo cual hace que Y sea negativa, entonces la solucin sera
convertir x3 igual cero, para que la Y sea positiva, este sera el objetivo
principal del proyecto Seis Sigma.
Diagrama de Flujo de Procesos (DFP) .
20
El diseo de nuevos servicios, o el mejoramiento de los actuales, requieren

que los miembros del equipo de trabajo tengan un claro entendimiento del
proceso. La documentacin adems se convierte en pieza fundamental para
la creatividad, el liderazgo, la definicin, organizacin, control y cierre del
proyecto.
En la actualidad existen diferentes formas de documentar los
procesos, los mas utilizados en las compaas Seis Sigma son los diagramas
de flujo de procesos, ya que brindan una representacin grfica del proceso
desde su comienzo hasta el final, pasando por las diferentes localizaciones
por donde trascurre, ayudando a los miembros a identificar los puntos claves.
Los diagramas de proceso tienen como objetivos principales:
Convertir un proceso realmente complejo en algo fcil de entender,

dividindolo en componentes ms pequeos.
Documentar el flujo del proceso, mostrando la secuencia de las tareas.
Entender las relaciones entre las tareas del proceso.
Proveer argumentos para evaluar el proceso.
Ofrecer un mayor entendimiento del proceso con el fin de prevenir los

defectos antes que corregir los errores en el futuro.
20
Process flow Diagram (PFD).
57
Para tener una herramienta bien formada se debe tener una estandarizacin
en los elementos utilizados en todas las representaciones de procesos.
PROCESO
O
EVENTO
DECISION
DATOS
FIN
CONECTOR
DEMORA
Figura 4. Elementos utilizados en la representacin de procesos.
Los diagramas de flujo de procesos tienen la caracterstica de ser iterativos,

por lo tanto comienzan con un alto nivel de grficos, llegando a un nivel tan
detallado del proceso como se requiera. Los diferentes tipos de diagramas
que se pueden utilizar son:
Diagrama de alto nivel. Es el mapa inicial, que contiene el proceso en

totalidad sin entrar en detalle en la trayectoria que sigue dentro de los
estados por los que pasa; desde el principio hasta el fin. Al finalizar los
mapas a este nivel y presentarse al grupo, se toma la determinacin de ir
al siguiente nivel si se considera necesario o si en este nivel los procesos
son suficientemente comprensibles.
58
Entrada del
proceso
Cliente
entra al
sistema
Digita la
consulta
deseada
Busca la
ubicacin
Realiza el
prstamo
Regresa el
tem
Salida del
proceso
Figura 5. Diagrama de alto nivel.
Diagrama de alto nivel con pasos intermedios. Constan de los mismos

elementos del nivel alto, agregando los pasos intermedios que se llevan a
cabo en cada departamento.
Entrada del
proceso
Cliente
entra al
sistema
Digita la
consulta
deseada
Busca la
ubicacin
*Seleccin del tipo de consulta *Conocimiento de la ubicacin.

*Desplazarse hasta el lugar
*Digitacin de tem a buscar
*Seleccin del tem especfico fichado
Realiza el
prstamo
Regresa el
tem
*Desplazarse hasta el
lugar donde se autoriza
el prstamo
*llenar el formato de
prstamo
* Desplazarse hasta el
lugar de devolucin
Salida del
proceso
Figura 6. Diagrama de alto nivel con pasos intermedios.

59
Diagrama de nivel de detalle. En este nivel el mapa contiene los pasos

en una forma mucho ms especfica, incluyendo los pasos intermedios, y
bloques de decisin.
NO
Cliente entra al
sistema
Seleciona el tipo
de consulta
Digita el tem
a buscar
Exitosa?
SI
Observar
Ubicacin
SI
Escoger el tem
especfico entre
todos los
resultados
Disponible?
Se encuentra
en el sitio?
NO
SI
Dirigirse a buscar
el formato de
prstamo
Posesin del tem
FIN
Reporte de
perdida
SI
Realizar el
prstamo
Devolucin al da
establecido
Aprobado?
Exitoso?
Uso del tem
NO
Figura 7. Diagrama de nivel de detalle.
Diagrama de nivel funcional.
La principal diferencia entre el nivel
funcional y el nivel de detalle, es que el nivel funcional hace claridad en

qu pasos del proceso se llevan a cabo en que departamento, mostrando
quienes son los responsables de la entrega y resultado del producto final
60
o servicio. Ayuda a clarificar los lmites del proceso y las dependencias

entre departamentos.
USUARIO
SISTEMA
OFICINA PRESTAMO
EDIFICIO
Seleciona el tipo
de consulta
Cliente entra al
sistema
NO
Digita el tem
a buscar
NO
Exitosa?
Escoger el tem
especfico entre
todos los
resultados
Se encuentra
en el sitio?
NO
Disponible?
Observar
Ubicacin
SI
SI
FIN
Posesin del tem
Dirigirse a buscar y
diligenciar el formato de
prstamo
NO
Aprobado?
Reporte de
perdida
NO
Uso del tem
Realizar el
prstamo
Exitoso?
Devolucin al da
establecido
SI
Figura 8. Diagrama de nivel funcional.

Desarrollar los diagramas de procesos, se convierte en una tarea que puede
llegar a necesitar de mucho tiempo, anlisis y estudio. Una mayor cantidad
de procesos identificados y representados, servirn de soporte para las
decisiones en su estrategia a futuro.
61
4. FASE MEDIR
Una vez el proyecto esta claramente definido, la segunda fase del modelo
DMADDV es MEDIR. El objetivo es principalmente cuantificar el problema
que se va a solucionar, de tal forma que se pueda obtener informacin del
proceso actual y se puedan establecer parmetros vlidos y confiables para
monitorear el avance hacia las metas definidas en el paso anterior.
Gracias a los procesos internos cruciales que influyen en las medidas CTQ,
se pueden medir los defectos generados en el proceso, de tal forma que si el
cliente espera un cierto estndar, es necesario identificar los factores vitales
que afectan esa expectativa, de tal forma podr medirse el impacto de los
defectos en esas reas y que tanto afectan estos valores a la satisfaccin del
cliente, para esto es importante considerar los siguientes tems:
Slo el 4% de todos los clientes con problemas se quejan.
En promedio una persona con un problema se lo comunica habitualmente
a otras 9 personas.
Los pacientes y los clientes satisfechos le cuentan a otras 5 personas
sobre la buena atencin que han recibido.
El coste para conseguir un cliente nuevo es generalmente de 5 a 7 veces
mayor que el de mantener los clientes actuales.
El coste de contratar y formar un empleado nuevo es hasta 10 veces ms
grande que el de mantener a los actuales.
62
Estos hechos resaltan la necesidad de satisfacer a sus clientes actuales para

que permanezcan en su organizacin. Una excelente satisfaccin del cliente
es una de las pocas formas de lograr una ventaja competitiva sostenible.
Las estadsticas son pieza fundamental de Seis Sigma, ya que brindan un
anlisis, y un resultado de datos en el cual el equipo se puede fundamentar,
utilizando la variacin como los defectos ocurridos en el proceso.
Las
distribuciones existentes que arrojan los datos necesitados para identificar

los defectos en el pasado, y predecirlos en el futuro, son varias, la
distribucin ms utilizada en Seis Sigma, es la distribucin normal. Las otras
distribuciones se pueden utilizar dependiendo directamente si el proyecto lo
requiere.
DISTRIBUCIN NORMAL
La distribucin normal es una clase muy importante de las distribuciones
estadsticas, se justifica en la frecuencia o normalidad con la que ciertos
fenmenos tienden a parecerse en su comportamiento a esta distribucin.
Las distribuciones normales son simtricas y su curva es de forma campana
con solo un pico (unimodal), tal como se observa en la figura 8.
Posee dos elementos que la afectan directamente, la media y la desviacin
estndar, la media se refiere al pico de la curva, donde se concentran la
mayora de los datos, y la desviacin estndar es donde ocurre la dispersin
de la campana.
El smbolo utilizado para identificar la media es y la
dispersin .
La importancia de la distribucin normal se debe principalmente a que hay
muchas variables asociadas a fenmenos naturales que siguen el modelo de
la normal, por citar algunos tenemos.
63
Caracteres morfolgicos de individuos (personas, animales, plantas,...)

de una especie, por ejemplo: tallas, pesos, envergaduras, dimetros,
permetros.
Caracteres fisiolgicos, por ejemplo: medicamentos.
Caracteres sociolgicos, por ejemplo: consumo de cierto producto por

un mismo grupo de individuos, puntuaciones de examen.
Caracteres psicolgicos, por ejemplo: cociente intelectual, grado de

adaptacin a un medio.
Errores cometidos al medir ciertas magnitudes.
Valores estadsticos muestrales, por ejemplo: la media.
Otras distribuciones como la binomial o la de Poisson son

aproximaciones normales.
Debido a la simetra, y basndonos en el teorema de limite central, podemos

determinar que cualquier variable aleatoria puede encontrarse bajo la curva
de una distribucin normal.
El teorema del lmite central dice que si se tiene un grupo numeroso

de variables independientes y todas ellas siguen el mismo modelo de
distribucin (cualquiera que ste sea), la suma de ellas se distribuye
segn una distribucin normal.
Este teorema se aplica tanto a suma de variables discretas como de
variables continuas.
Los parmetros de la distribucin normal son:
Media : n * . (media de la variable individual multiplicada por el
nmero de variables independientes).
64
Varianza : n * .2 (varianza de la variable individual multiplicada por el

nmero de variables individuales).
En la figura 8 se puede visualizar las probabilidades asociadas a una

distribucin normal.
+ 2
+ 3
68%
95%
99.7%
Figura 8. Probabilidades asociadas a una distribucin normal.

Segn la figura 8, se pueden clasificar los datos como:
50% del rea, puede ser encontrado debajo de la mitad.
68,26% (34% a cada lado) se encuentra con mas o menos una

desviacin estndar.
95.44% puede ser encontrado con mas o menos dos desviaciones

estndar.
65
99.74% puede ser encontrado con tres desviaciones estndar.
99,9937% cuatro desviaciones.
99,999943% cinco desviaciones.
99,99999998% seis desviaciones (meta de Seis Sigma).
Debido a que ms del 0.9973 de la probabilidad de una distribucin normal

esta comprometida en el intervalo ( - 3 , + 3), a menudo se hace
referencia a la cantidad 6 como el ancho de una distribucin normal.
Los pasos necesarios para llevar con xito la fase de medir son:
1.
Capturar la voz del cliente.
2.
Determinar las mtricas.
3.
Plan de coleccin de datos.
4.
Elaborar las grficas de las medidas.
5.
Calcular el nivel de sigma.
6.
Benchmarking.
7.
Desarrollar el modelo financiero.
8.
Identificar y priorizar los requerimientos de los clientes.
9.
Inicio de QFD.
10. Plan de comunicaciones.

11. Presentar al comit para aprobar.
4.1
CAPTURAR LA VOZ DEL CLIENTE (VOC)
La voz del cliente es uno de los pasos en los que Seis Sigma se diferencia
de las otras metodologas de desarrollo de software, debido a la importancia
que se le otorga al cliente durante todo el desarrollo del proyecto.
66
Existen diferentes mecanismos para realizarla (Ver anexo B) y cualquiera

que sea utilizado debe mostrar datos lgicos y coherentes y ofrecer a los
miembros del equipo la informacin correcta para tomar decisiones efectivas.
Tomar decisiones no basadas en hechos puede llegar a tener un costo muy
alto que ninguna compaa esta dispuesta a correr, aunque algunas veces
los proyectos deben correr el riesgo de asumir diferentes aspectos, la VOC
ayuda a reducirlos.
4.2
DETERMINAR QUE MEDIR
Como Seis Sigma tiene sus fundamentos en el anlisis estadstico, es

importante hacer gran nfasis en las medidas. Uno de los principios de Seis
Sigma es que las medidas, la precisin y exactitud del anlisis estadstico y
de las formulaciones matemticas son la clave del xito.
La ecuacin y = f(x) es una explicacin matemtica de la relacin entre las
entradas, las salidas y el proceso. En la ecuacin y representa la salida
final del proceso, es una funcin de las xs, las variables o las entradas
claves del proceso y f el proceso como tal. En resumen, las entradas son
procesadas y se convierten en las salidas finales.
Aunque algunas veces no es tan simple, suelen existir varios pasos dentro
del proceso y la ecuacin se puede convertir en y = f (x1, x2, x3,.....), donde
las xs representan las diferentes entradas en el proceso.
Durante el proceso, existe la posibilidad de encontrar defectos en cada paso
que lo compone, la meta es eliminar los defectos tan pronto como sea
posible. Para poder hacer esto, es necesario conocer las causas de la
variacin en cada paso, (o de las entradas), Para conocer las causas de la
67
variacin es necesario medir el grado de variacin, pero el primer paso es

identificar las entradas y decidir que es lo que se va a medir.
La pregunta es Cmo seleccionar de verdad unas mtricas adecuadas?.
Seleccionar solamente las medidas ptimas de rendimiento significa
equilibrar dos elementos principales: 1) lo que es factible; 2) lo que es ms
til o valioso.
La tabla 6 a continuacin contiene una lista parcial de criterios a considerar,
en las categoras de viabilidad y valor, cuando elija qu medir.
Tabla 6. Criterios de seleccin de medidas.
Valor / utilidad
Enlaza
con
los
Viabilidad
requisitos
Disponibilidad de los datos.
prioritarios del cliente.
Plazo de entrega requerido.
Exactitud de los datos.
Coste de obtencin de los
rea
de
preocupacin
datos.
oportunidad potencial.
Complejidad.
Se puede comparar con la de
Posible resistencia o factor
otras organizaciones.
miedo.
Permite obtener medidas de

manera continuada.
4.2.1 Tipos de variacin
Aunque el equipo de trabajo identifica las ordenes del cliente como la entrada
principal a los procesos, tambin es necesario considerar todo lo que genere
impacto en el proceso como una posible entrada o variable. Para identificar
variables es muy til comenzar con el mtodo de las 1 P y 5 Ms: persona,
maquina, material, mtodos, medidas y madre naturaleza.
68
La tabla 7 cuadro provee una definicin del mtodo:

Tabla 7. Mtodo de 1 P y 5 Ms.
Elemento
Persona
Explicacin
Es el elemento humano, las diferencias que ocurren cuando
ms de una persona opera la misma parte del proceso.
Mquina
Son las clasificaciones de las piezas que conforman un equipo

para trabajar.
Material
Son la materia prima o ingredientes .
Mtodo
Son los procedimientos estndares para operar bien.
Las
variaciones son causadas cuando existe ms de una forma

diferente de realizar el proceso.
Medidas
El sistema de medidas puede arrojar resultados que realmente

no son variaciones.
Esto convierte a las medidas en un
elemento de variacin.
Madre naturaleza
Factores ambientales, incluyen temperatura, humedad y

energa disponible.
Adems de asignar las variables a un elemento, tambin es necesario

mencionar que las variables se clasifican en controlables e incontrolables y a
su vez las variables controlables se subdividen en crticas y no-crticas.
Variables controlables, son aquellas que las personas que miden el proceso
pueden variar para determinar los efectos en las salidas. Variables crticas
son las entradas controlables que tienen gran impacto en la salida.
Las variables incontrolables son aquellas que afectan la salida pero son
difciles de controlar.
69
4.2.2 Medir lo que tenga valor
Otro de los principios de Seis Sigma es medir lo que tenga valor. Al igual
que los requerimientos pueden ser evaluados por el mtodo EMART, existe
un acrnimo que puede ser utilizado para medir las caractersticas de unas
buenas medidas.
Las medidas pueden ser de tipo RAVF :
21
Relevantes.
Adecuadas para detectar cambios en los procesos.
Valido y consistente a travs del tiempo.
Fciles.
4.2.3 Exactitud de las medidas
Las medidas son usadas para la toma de decisiones, por tal motivo es
necesario hacer nfasis en tomar medidas que sean exactas. Es importante
conocer que existen riesgos asociados a los sistemas de medidas, por
ejemplo, la tabla 8 que se muestra a continuacin.
Tabla 8. Categora de los riesgos en las medidas.
Alpha
Riesgo
Beta
Se rechazan buenos
Se aceptan malos elementos.
elementos.
Grupo del riesgo
Efecto
proceso
en
Proveedor.
Cliente.
el Puede cambiar
No se identifican los cambios
innecesariamente.
que se necesitan.
21
RAVE: acrnimo de Relevant, Adecuate to detect process changes, Valid and consistent
from time to time, Easy.
70
Otros efectos
Aumento de costos
Se crean defectos.
innecesariamente.
4.3
PLAN DE COLECCIN DE DATOS
En proyectos de desarrollo de software, los datos son fundamentales para el

equipo de trabajo. La coleccin de datos al igual que otros pasos dentro de la
metodologa, debe hacerse bajo una buena planeacin, para asegurarse que
los procesos y las medidas sean estables, confiables, y se puedan utilizar
como soporte en la fase analizar.
Es importante destacar dos secciones principalmente. La primera donde se
definen las metas y los objetivos de la coleccin de datos, y la segunda
donde se desarrollan las definiciones operativas y los procedimientos.
4.3.1 Seccin 1: definir las metas y los objetivos
En esta seccin se debe definir claramente las metas y los objetivos de la

coleccin de datos. Un buen plan de coleccin de datos debe incluir:
Una breve descripcin del proyecto.
Los datos especficos que se necesitan (Nombre, Descripcin).
Las razones para recoger los datos.
Qu informacin brindan esos datos al proceso estudiado y cmo
ayudarn al equipo de trabajo.
Qu se puede hacer con los datos una vez sean recogidos.
71
4.3.2 Seccin
2:
desarrollar
las
definiciones
operativas
los
procedimientos.
En esta seccin se pueden desarrollar los siguientes pasos:
Desarrollar las definiciones operativas.
Avanzar en el proceso de la coleccin de datos.
Comprobar la precisin y el valor de la medida.
Trabajar con los resultados.
Desarrollar las definiciones operativas.
El equipo de trabajo debe hacer una descripcin clara, comprensible y

concreta de lo que hay que medir u observar, y como se debe hacer, para
que todos los miembros del equipo de trabajo puedan operar o medir de
forma coherente con base a la definicin.
La fiabilidad e integridad de los datos es un factor importante de este punto,
para encontrarla, los miembros del equipo deben hablar un mismo
vocabulario, el cual ya ha sido establecido en la fase definir. Pasar por alto
este paso puede terminar en resultados engaosos si los miembros del
equipo los interpretan libremente y los definen en trminos diferentes al
momento de recoger datos. Los problemas serios pueden presentarse para
la organizacin cuando se toman las decisiones econmicas basado en
estos datos potencialmente no fiables.
Existen diferentes fuentes de datos posibles en la organizacin.
Es
necesario garantizar que la fuente elegida, tenga datos precisos y que

representen el proceso que se quiere medir. Si el equipo desea examinar
datos histricos para incluirlos como parte del estudio, se debe prestar
atencin
a que tan confiables han sido los datos y su fuente, y si es

72
recomendable continuar usando esos datos. Los datos que demuestran ser
sospechados deben ser desechados.
Avanzar en el proceso de la coleccin de datos.
Implica tener claridad en los procedimientos que se van a realizar para la

recoleccin de los datos, el personal asignado a la toma de las medidas as
como la fuente o la ubicacin de los datos.
Una vez que se haya planeado y definido el proceso de coleccin de datos,
se debe hacer un seguimiento a travs del proceso, desde su comienzo
hasta el final, para asegurarse
que el plan se esta ejecutando
constantemente y exactamente. Si se asume que el Black Belt o el lder del

equipo ha comunicado a los responsables de reunir los datos y los
participantes de este proceso, cules son los datos que se deben reunir,
posiblemente necesitarn una preparacin adicional sobre las definiciones,
procedimientos, pautas, etc.
Es buena idea que el Black Belt o el lder del proyecto estn presentes en el
proceso de coleccin de datos, de esta manera los participantes sabrn
enseguida si el plan se esta ejecutando correctamente.
La falta de
supervisar el proceso desde las etapas iniciales, puede significar que ms

tarde una correccin necesite ser hecha, y muchos de los esfuerzos iniciales
se perdern.
Comprobar la precisin y el valor de la medida.
Existen varias formas de comprobar si las medidas son exactas y se

mantienen precisas. La prueba ms comn para la efectividad de un sistema
73
22
de medida es el "Estudio de R&R ", que consiste en repetir una medida en

varios escenarios para comprobar cuatro importantes criterios: Precisin,
Repetibilidad, Reproducibilidad y Estabilidad.
Los datos que son recogidos (y medidos) sern repetibles si el mismo equipo
puede alcanzar esencialmente los mismos tiempos del resultado en un
artculo particular cuando se mide ms de una vez.
Los datos sern
reproducibles si otras personas o equipos que estn midiendo los mismos

artculos estn alcanzando esencialmente los mismos resultados. El grado
en las cuales el sistema de medidas es Preciso, es cuando no se encuentran
diferencias entre una medida de media observada y el valor estndar
asociado.
El grado en el cual el sistema de la medida es estable, es
expresado generalmente por la no variacin resultado de medir el mismo

artculo, con el mismo equipo, sobre un perodo extendido.
Los equipos de trabajo necesitan reconocer todos los factores posibles que
causaran reducciones en la capacidad de repeticin, la reproductibilidad, la
precisin y la estabilidad, sobre cualquier longitud del tiempo y que
alternadamente pueda rendir datos no fiables. Es buena prctica probar,
quizs en una escala pequea, cmo procedern la coleccin y las medidas
de datos.
Trabajar con los resultados
Las medidas contienen las caractersticas de Repetibilidad, reproducibilidad,

Precisin y Estabilidad, el Black Belt o el lder del proyecto debe comprobar
que los datos sean razonables y necesarios, de no ser as, ellos son los
encargados de determinar donde ocurri la falla, y de determinar el
procedimiento a seguir con los datos errneos. Se debe tener en cuenta las
22
R&R: Repetibilidad y reproducibilidad.
74
definiciones
operacionales
para
resolver
los
malentendidos
las
interpretaciones que pudieron haber causado los errores.
4.4
ELABORAR LAS GRFICAS DE LAS MEDIDAS
La variacin que exista dentro de un proceso es vista como defecto,

identificarla es una tarea indispensable dentro de esta fase con el propsito
de eliminarla.
Los grficos ms utilizados en proyectos Seis Sigma son:
4.4.1 Diagrama de cajas
El diagrama de cajas representa varias caractersticas importantes sobre un

conjunto de datos, tales como: la dispersin, la desviacin de la simetra, la
media, el rango, entre otros.
En la figura 9, obtenido con el paquete statgraphics 5.1, para los datos
ejemplo de la tabla 9, se identifica la lnea vertical que representa la media y
la lnea horizontal que se extiende por el grfico representando el rango de
opciones existentes.
75
Figura 9. Diagrama de cajas sencillo.

Los diagramas son tiles cuando se necesitan hacer comparacin sobre los
datos obtenidos discriminados por grupos de personas o de fechas u otros
como se observa en la figura 10. La desventaja es que no se conoce la
cantidad de valores que se encuentran en cada posible valor, aunque se
tiene la seguridad que alguna(s) observacin(es) arrojaron ese valor.
Figura 10. Diagrama de cajas avanzado.
76
Tabla 9. Datos ejemplo.
Grupo
4
3
4
5
4
2
4
3
5
5
5
4
4
3
1
1
1
1
2
5
Resultado
3
3
4
2
3
1
3
4
3
3
3
4
3
3
5
6
5
6
1
3
Grupo
3
4
5
4
5
5
2
3
3
3
3
5
5
4
1
1
4
4
5
2
DATOS
Resultado
Grupo
2
3
4
3
1
2
2
4
4
5
2
5
2
2
1
5
2
4
4
4
3
2
3
4
4
3
4
3
6
4
6
5
2
3
2
3
3
5
1
4
Resultado
2
2
3
1
1
2
2
3
1
2
3
3
2
4
4
4
4
4
4
4
Grupo
3
1
1
1
3
4
4
4
2
5
2
3
3
3
4
5
5
Resultado
6
5
6
5
6
2
1
2
2
3
3
2
2
1
2
3
4
4.4.2 Diagrama de punto
Es utilizado en conjuntos pequeos de datos.
Las ventajas ms
sobresalientes son permitir ver con facilidad la ubicacin o tendencia central

de los datos, as como su dispersin o variabilidad. Elimina la dificultad de
no tener conocimiento de los valores exactos en cada opcin encontrada en
el diagrama de cajas.
La desventaja ms sobresaliente se presenta en la
dificultad de contar el numero de puntos. Por otro lado, la media no es

identificada fcilmente.
77
Figura 11. Diagrama de punto.
4.4.3 Diagrama de torta.
El diagrama de torta presenta la ventaja de mostrar claramente la cantidad

de muestras obtenidas en una opcin. Exponiendo tambin los porcentajes,
y diferenciados por diferentes colores. Una de las desventajas es que no
muestra la media de los datos.
Figura 12. Diagrama de torta.
78
4.4.4 Histograma con curva normal
El histograma proporciona una impresin visual del aspecto que tiene la

distribucin de las mediciones, as como informacin sobre la dispersin de
los datos. Es el diagrama ms utilizado por la estadstica, y agregndole la
curva normal, se obtienen mayores ventajas.
Figura 13. Diagrama de histograma.

4.4.5 Diagrama de Series de Tiempo
Es un diagrama en el que el eje vertical denota el valor observado, mientras

que el eje horizontal denota el tiempo. Una de las ventajas es que a menudo
se
observan
ciertas
caractersticas
importantes
de
los
datos
que
generalmente pasan inadvertidas. Las desventajas ms sobresalientes es la

no identificacin de la media.
79
Figura 14. Diagrama de series de tiempo.
4.4.6 Diagrama de Corrido
El diagrama tiene las mismas caractersticas del diagrama de series de

tiempo, ms la representacin de la media y algunos datos estadsticos
bsicos.
Es otra manera til de examinar la variabilidad en datos que
dependen del tiempo.
80
Diagrama de Corrido
7
Datos
0
Fecha/Tiempo
Numero de puntos en la media
18
Nmeros esperados de puntos
34.97
Corrido mas largo
17
Aprox p-valor por cluster
Aprox p-valor por mezclas
4.4.7 Diagrama de dispersin
Es un diagrama en el que cada par (x , y) esta representado con un punto en

un sistema de coordenadas bidimensionales. El anlisis de este diagrama
indica que si una curva no pasa exactamente por todos lo puntos, existe una
evidencia fuerte, de que los puntos estn dispersos de manera aleatoria
alrededor de una lnea recta.
81
Figura 16. Diagrama de dispersin.
4.4.8 Diagrama de pareto
Los diagramas de pareto son herramientas poderosas para enfocar los

proyectos en la direccin correcta. Basados en el principio de pareto, donde
solo pequeos factores trascendentales son los responsables de producir la
mayora de problemas. En otras palabras, el 80% de los problemas se
derivan del 20% de las causas, los diagramas de pareto separan los factores
y los representa en orden descendiente desde los mas, hasta los menos
problemticos.
Figura 17. Diagrama de pareto.
82
4.5
CALCULAR EL NIVEL SIGMA
Para calcular el nivel de sigma, se debe tener claridad en las siguientes

definiciones:
Unidad. Es el resultado del servicio prestado, o del producto final.
Defecto. Es el fallo al no encontrar las especificaciones establecidas

por el cliente o estndares de rendimiento.
Defectuoso. Unidad con uno o varios defectos. Son identificados al

final del proceso.
Oportunidad de defecto. Son las oportunidades que tiene una unidad

en ser defectuosa.
Defectos por unidad (DPU).
El nmero total de defectos en una
muestra, dividido en el nmero total de unidades de la misma muestra.
Rendimiento final. Es la cantidad de unidades sin defectos.
Para determinar las oportunidades por defecto se debe tener perfectamente

claro el mtodo para obtener medidas basadas en oportunidades y luego
como se expresan esas medidas. El reto del equipo esta en identificar un
nmero realista de oportunidades de defecto para cada producto o servicio.
Determinar el nmero de oportunidades debe ser una responsabilidad tica
del grupo, ya que el nmero de oportunidades es directamente proporcional
al nivel de sigma. Los pasos a seguir son los siguientes:
1. Desarrollar una lista preliminar de tipos de defectos. Cuntos tipos
de defectos puede tener un servicio o producto?
2. Determinar cuales son los defectos especficos reales, crticos para el
cliente. Aquellos que ms influyen en los requerimientos del cliente.
La determinacin debe tener caractersticas razonables, realistas,
practicas, y la ms importante, consistentes.
3. Definir estndares para calcular el numero de oportunidades.
83
Los servicios entre ms complejos sean, ms oportunidades tendrn, para

estimar las oportunidades se establecen los siguientes pautas:
Dirigirse a las reas donde se generan los problemas o que mayor

valor agregado dan al proceso.
Encontrar la semejanza que poseen algunos defectos y agruparlos

con el propsito de tener clasificaciones dentro de estos.
Ser coherente.
Estimar el nmero de oportunidades con cuidado; un nmero grande

da un mejor nivel de sigma, pero es difcil medir los resultados al final
del proyecto.
Estar seguro de que el defecto si es realmente importante para el

cliente o para el proceso.
Los pasos para calcular el nivel de sigma son los siguientes:

1. Calcular el nmero unidades. (NU)
Por ejemplo: 115
2. Calcular el nmero de unidades con defectos. (NUD)
Ej. 40
3. Calcular el nmero de oportunidades (NO)
Ej. 10
4. Calcular el defecto por unidad (DPU)
84
Numero de Defectos (NUD)
DPU =
Numero de Unidades (NU)

40
DPU =
= 0,3478
115
5. Calcular el nmero de defectos por oportunidad (DPO)

Defectos por Unidad (DPU)
DPO =
Numero de Oportunidades (NO)
DPO =
0,3478
10
= 0,03478
6. Calcular los defectos por milln de oportunidades (DPMO)
DPMO
Defectos por Oportunidad (DPO) x 1'000.000 (106)
DPMO
0,03478 x 1'000.000 (106) = 34.783
7. Convertir el DPMO en el valor de Sigma establecido en tabla 10.
34783
85
3,30 Sigma
Tabla 10. Conversin de DPMO a Nivel Sigma
23
Tabla de conversin DPMO con Sigma

DPMO
Sigma
DPMO
933,193
0.00
291,160
926,471
0.05
274,253
919,243
0.10
257,846
911,492
0.15
241,964
903,199
0.20
226,627
894,350
0.25
211,856
884,930
0.30
197,663
874,928
0.35
184,060
864,334
0.40
171,056
853,141
0.45
158,655
841,345
0.50
146,859
828,944
0.55
135,666
815,940
0.60
125,072
802,338
0.65
115,070
788,145
0.70
105,650
773,373
0.75
96,800
758,036
0.80
88,508
742,154
0.85
80,757
725,747
0.90
73,529
708,840
0.95
66,807
691,462
1.00
60,571
673,645
1.05
54,799
655,422
1.10
49,471
636,831
1.15
44,565
617,911
1.20
40,059
598,706
1.25
35,930
579,260
1.30
32,157
559,618
1.35
28,717
539,828
1.40
25,588
519,939
1.45
22,750
500,000
1.50
20,182
480,061
1.55
17,865
460,172
1.60
15,778
440,382
1.65
13,904
420,740
1.70
12,225
401,294
1.75
10,724
382,088
1.80
9,387
363,169
1.85
8,198
344,578
1.90
7,143
326,355
1.95
6,210
308,537
2.00
5,386
23
Sigma
2.05
2.10
2.15
2.20
2.25
2.30
2.35
2.40
2.45
2.50
2.55
2.60
2.65
2.70
2.75
2.80
2.85
2.90
2.95
3.00
3.05
3.10
3.15
3.20
3.25
3.30
3.35
3.40
3.45
3.50
3.55
3.60
3.65
3.70
3.75
3.80
3.85
3.90
3.95
4.00
4.05
DPMO
4,661
4,024
3,467
2,980
2,555
2,186
1,866
1,589
1,350
1,144
968
816
687
577
483
404
337
280
233
193
159
131
108
89
72
59
48
39
32
26
21
17
13
11
9
7
5
4
3
Sigma
4.10
4.15
4.20
4.25
4.30
4.35
4.40
4.45
4.50
4.55
4.60
4.65
4.70
4.75
4.80
4.85
4.90
4.95
5.00
5.05
5.10
5.15
5.20
5.25
5.30
5.35
5.40
5.45
5.50
5.55
5.60
5.65
5.70
5.75
5.80
5.85
5.90
5.95
6.00
Tomada del libro. SIX SIGMA. The Breakthrought Management Strategy Revolutionizing
the Worlds Top Corporations
86
4.6
BENCHMARKING
La prctica del Benchmarking no es nueva realmente, lo que si es nuevo es

el auge que empieza a tener. Es comn escuchar en las organizaciones
frases como:
Por qu deberamos hacer nosotros Benchmarking?,
Nosotros somos los mejores en nuestro negocio.
Estamos solos.
podemos compararnos con otros en nuestro negocio.
No
Muchas de las
compaas creen que son los mejores, debido a su larga trayectoria que les
ha generado dicha reputacin. Sin embargo, cuando se comienza con una
iniciativa como Seis Sigma, y descubren su verdadero nivel de sigma entran
en razn de que sucede realmente con la compaa.
Hoy en da la cantidad de informacin disponible para utilizar en la toma de
decisiones ha aumentado notablemente,
igual los competidores tienen
acceso a esa misma informacin; por lo tanto compaas que sean capaces
de transformar esos datos en conocimiento y logren utilizarlo para beneficio
propio, tendrn ventajas sobre los competidores.
4.6.1 Qu es Benchmarking?
Benchmarking
es
una
poderosa
herramienta
para
ayudar
las
organizaciones a comparar los procesos con sus competidores, y entender

que hace a los productos o servicios de otras organizaciones superiores.
La mayora de las veces las compaas tienen conocimiento de quienes son
sus competidores ms fuertes en algn proceso especfico, sea para un
producto o servicio, por lo tanto es necesario conocer como nuestras
fortalezas y limitantes afectan directamente la satisfaccin del cliente y
rentabilidad.
87
Los resultados obtenidos en la prctica del Benchmarking deben ser

incorporados en las operaciones del da a da, consiguiendo con esto que las
organizaciones piensen diferente acerca de cmo realizan su trabajo y en
cmo se pueden solucionar los problemas.
La primera asignacin que se debe plantear es que tipo de Benchmarking se
utilizar:
Benchmarking Interno.
Compara los procesos comunes entre diversas
funciones con un competidor.
Mide la precisin y la eficiencia de los
procesos a travs de los departamentos internos.

Benchmarking Competitivo. Observa directamente a los competidores,
midiendo el nivel de fidelidad, y satisfaccin de los clientes, y la porcin del
mercado que poseen. El Benchmarking competitivo ayuda a identificar los
cambios y las preferencias en los clientes. Por otro lado revela cual es el
valor que tienen las mercancas hacia ellos y en como piensan los clientes
hacia la compaa.
Benchmarking funcional.
Se enfoca en el proceso mismo, y en las
organizaciones con procesos similares ms all de que se encuentren en

otro negocio. Ayuda a identificar estrategias de produccin, a calcular las
horas promedio de trabajadores requeridos y a calcular el costo de retrabajo.
4.6.2 Por qu Benchmarking en Seis Sigma?
El primer paso despus de determinar que tipo de Benchmarking utilizar es

identificar cul es el campo o el porcentaje de defecto de un producto
particular, servicio o transaccin, que tenga gran valor para la organizacin.
El segundo, revela el nmero de oportunidades para un defecto existente en
algn producto, servicio o transaccin. Basandose en la frmula defectos
88
por oportunidad (DPO), la cual se utiliza para calcular el defecto por milln de
oportunidades (DPMO), se concluye que el Benchmarking es pieza
fundamental en Seis Sigma.
Debido a que el Benchmarking implica mostrar datos a los competidores,
existe un cdigo que se debe aplicar ticamente por los participantes. Este
cdigo contiene los siguientes aspectos.
Legalidad. No entrar en discusiones o actos que podran considerarse

ilegales, entre la compaa y el socio.
Intercambio.
No preguntar a los competidores asuntos que la
compaa no estara dispuesta a responder.
Confidencialidad.
Utilizar la informacin de los competidores de la
misma forma en la que la compaa deseara que la informacin fuese

tratada. Toda informacin recibida no puede ser puesta al exterior sin
previa autorizacin.
Uso de la informacin. No utilizar la informacin del socio, para un

uso diferente al que se haya acordado. En la mayora de los casos se
utiliza la informacin para el mejoramiento de procesos.
Contacto.
Iniciar el contacto a travs de alguien designado por la
compaa para el contacto. Respetar la cultura empresarial y trabajar

dentro de las conductas previamente establecidas.
Preparacin.
Demostrar eficiencia y eficacia con el contacto
aprovechando la mayor parte del tiempo con el contacto. Demostrar

profesionalismo y conocimiento del rea.
Cumplimiento.
guardar.
No realizar compromisos que no pueda realizar o
Completar el trabajo asignado para cada uno de los
participantes, como se acord mutuamente.
Entendimiento. Es la regla de oro del Benchmarking, tratar al socio y

a la informacin del socio, como le gustara a la compaa que fuera
tratado y la informacin fuese utilizada.
89
4.7
Los proyectos que se desarrollan en cualquier compaa estn acompaados

de un presupuesto para su realizacin. El retorno de inversin es uno de los
aspectos ms importantes que el comit de proyectos utiliza para dar su
aprobacin.
El retorno de inversin para proyectos nuevos o de mejora por lo general es
un porcentaje determinado por la alta direccin de la compaa, aunque
puede ser establecido para un proyecto o rea de trabajo especfica. Por
ejemplo, que cualquier proyecto en el rea de IT debe tener un retorno de
inversin mayor del 25%.
El modelo que se plantea es un pronstico de beneficios en trminos
monetarios para el proyecto. La alta direccin de la compaa establece que
tipos de proyectos deben presentar el modelo, basados en las caractersticas
que la compaa determine.
Por ejemplo, solo proyectos que tengan un
presupuesto mayor a 20 millones de pesos de inversin debe presentar el

modelo financiero.
90
50
45
40
Pesos (Millones)
35
30
ROI
Inversin
25
20
15
10
5
0
1
10
Meses
Figura 18. Retorno de inversin Vs tiempo.

El modelo debe ser coherente con la gran iniciativa de la compaa, aunque
mostrar cifras de retorno de inversin altas y tiempo en periodos especficos
es atractivo para la aprobacin del proyecto y generar confianza para el
equipo por parte de la alta direccin, es recomendable ser realista al analizar
el tiempo de retorno o presentar una cifra menor a lo que realmente se puede
alcanzar y que contine siendo atractiva, si esta cifra es superada el impacto
positivo que tendr el comit y los otros miembros de la alta direccin hacia
el equipo de trabajo ser mayor.
91
4.8
IDENTIFICAR Y PRIORIZAR
LOS REQUERIMIENTOS DE LOS
CLIENTES
La captura de requisitos es uno de los pasos fundamentales y de mayor
importancia en el proceso ya que definen las necesidades y las expectativas
del cliente final.
En la mayora de los casos la captura de requisitos suele ser compleja,
muchas veces los usuarios no saben que parte de su trabajo puede
transformarse en software, es decir, no saben cules son los requisitos ni
tampoco cmo especificarlos de forma precisa.
La voz del cliente se
convierte en el mecanismo ms recomendado para la captura.

En primer lugar es necesario establecer un estndar para que la definicin de
requisitos sea clara y concisa.
1. Enlazar con un resultado especfico: No tendra sentido si el requisito no
describe cuestiones relativas a un producto, servicio o evento especfico.
2. Describir un solo criterio o factor de rendimiento. Debe quedar muy claro
lo que el cliente busca o lo que va a evaluar ya sea rapidez, costo, etc.,
pero se debe evitar la tentacin de agrupar varios factores.
3. Expresarse mediante factores observables o medibles. Si no puede
observarse una forma de comprobar si el requisito se cumple o no, se
concluye que este requisito es demasiado ambiguo. Cuando el requisito
no es observable, se busca el mejor indicador para medir la solucin.
4. Permitir establecer un nivel de rendimiento aceptable o no aceptable.
El requisito debe ayudar a establecer la norma para el defecto.
5. Ser detallada pero concisa. Aunque uno de los mayores inconvenientes
en la definicin de requisitos es que resulte demasiado breve, al mismo
tiempo si hay demasiadas palabras, nadie lo leer. Lo correcto es lograr
un equilibrio.
92
6. Que coincida con la voz del cliente. Lo ms importante es que los

requisitos o especificaciones deben ajustarse a las necesidades o
expectativas del cliente.
Basndose en el modelo de Kano (figura 19) los requerimientos de los
clientes se pueden clasificar en tres modalidades, que son:
Los que el cliente dice y desea.
Son aquellos que el cliente dice
claramente, y que el servicio o producto debe cumplir para tener un nivel

alto de calidad. Por ejemplo, cuando se ordena un caf en una cafetera,
el requisito es que el caf este fresco y con la intensidad en que se
orden, oscuro o claro.
Los que el cliente no dice y no generan satisfaccin pero si
insatisfaccin. Son aquellos que si el servicio o producto los cumple no
genera absolutamente nada en la satisfaccin de cliente, pero que si no
los cumple generar una gran insatisfaccin y hasta la prdida del cliente,
son ocultos pero estn presentes. Para el ejemplo anterior, si el caf se
sirve caliente el cliente pasar por inadvertido ese hecho, pero si el caf
se sirve fri el cliente se sentir insatisfecho y no regresar.
Los que el cliente no dice y que generan gran satisfaccin en el
cliente. Son aquellos ms difciles de identificar, pero son los que hacen
que un cliente regrese y se vuelva fiel a la compaa. En el ejemplo, si el
caf se sirve con galletas de chips de chocolate y varios barquillos para
acompaar el caf sin incrementar el costo, el cliente sentir una
satisfaccin grande, si el caf es servido sin acompaante, el cliente
simplemente no sentir nada y opinar acerca del caf.
93
Satisfaccin del
Cliente
Requisitos no hablados,
entusiastas
Requisitos de
Calidad
Requisitos
Alcanzados
Requisitos no hablados,
deseados
Figura 19. Modelo de Kano.

Despus de ser implantados los requerimientos que no se dicen pero que
generan gran satisfaccin en el cliente (tipo 3), se convierten en
requerimientos que el cliente no dice y no generan satisfaccin pero si
insatisfaccin (tipo 2).
Diferentes formas se utilizan para identificar y dar prioridad a los requisitos,
UML, QFD, entre otras. El auge que posee UML hoy en da es bastante
grande ya que es una metodologa sencilla y aplicable a la mayora de los
proyectos de desarrollo de software y se basa en la utilizacin de casos de
uso (Ver anexo C).
El desarrollo en funcin de la calidad (QFD) , ha sido

24
24
Desarrollo en funcin de la calidad definicin en Ingles de Quality Funtion Deployment

(QFD)
94
utilizada por ms de 40 aos a lo largo de las compaas para el anlisis de

datos sobre lo que los clientes realmente quieren, su principal propsito es
mejorar la satisfaccin del cliente mejorando la calidad de los productos o
servicios, algo que los mtodos tradicionales de captura de requisitos no
realizan.
NADA INCORRECTO TODO CORRECTO
4.9
INICIO DE DETERMINACIN DE MEJORAS
Aunque la priorizacin de los requerimientos se puede realizar utilizando

diferentes mtodos, Seis Sigma utiliza la mayora de las veces Calidad en
funcin del desarrollo (QFD).
Este paso es donde se inicia la matriz de QFD, aunque es solo el comienzo
la calificacin que se le proporcionar a los requerimientos del proyecto es
un factor trascendental para hallar la solucin verdadera al problema.
La escala puede variar dependiendo de los miembros del equipo, es
recomendable utilizar la siguiente:
Tipo
Valor
Smbolo
Alto
Medio
Bajo
La calificacin de los requerimientos debe estar directamente relacionado

con los valores del rbol de soluciones que se determin despus de la voz
del cliente, los requerimientos que afecten directamente a la CTQ con mayor
porcentaje obtendrn la calificacin alta y as descendentemente.
95
Por
ejemplo. La CTQ 1 es la reduccin de 60 segundos a 20 segundos en la

bsqueda, y tiene una importancia del 70%, y la CTQ 2 es aumentar en un
30% la oferta del servicio en la biblioteca y tiene un 30% de importancia. Por
lo tanto la clasificacin es la siguiente:
Requerimiento
Importancia
Bsqueda gil, eficaz, y efectiva.
Diseo grfico amigable.
Disponibilidad de computadores para los usuarios.
4.10 PLAN DE COMUNICACIONES
El plan de comunicaciones es la estrategia usada para comunicar a todos los

que participan en el proyecto, las actividades y el estado del proyecto, as
como reportar el estado actual de sus tareas individuales y establecer los
mtodos para desarrollar registros histricos del proyecto. Un buen plan de
comunicaciones ayuda a determinar y corregir a tiempo los errores que se
pueden ir presentando en el transcurso del proyecto.
Es apropiado durante todo el proyecto mantener lneas de comunicacin
abiertas entre los miembros del equipo y los directores, pero tambin es
importante mantener la comunicacin con los usuarios finales del producto o
servicio. El primer paso en el plan de comunicaciones es determinar los
diferentes grupos que necesitarn informacin del proyecto. Los grupos que
pueden existir son:
Comit de Direccin.
Miembros del equipo.
Usuarios y gente que no est directamente involucrada en las

actividades del proyecto.
96
Agentes externos.
Patrocinadores del proyecto.
Pblico.
Segundo, para cada uno de estos grupos, se debe determinar el tipo de

informacin que necesitan, el nivel de detalle que requieren (Nivel muy
especfico, alto nivel y general) y qu tan seguido necesitan la informacin.
Existen diferentes tipos de informacin que se necesita, dependiendo del
grupo con el que se quiera comunicar, adems existen muchas formas de
comunicar la informacin. Las diferentes formas de comunicacin que se
pueden usar con cada persona que hace parte del equipo de trabajo son:
reuniones (sea en grupo o individual), llamadas telefnicas, informes escritos,
correo electrnico o la combinacin de estos.
La siguiente es una gua para desarrollar un efectivo plan de comunicacin:
Se debe involucrar los miembros clave del equipo a la hora de

desarrollar el plan de comunicaciones.
Trabajar con cada uno de los miembros del equipo para definir cuando
y como la comunicacin tendr ligar y como se trabajar en equipo
para solucionar problemas que puedan surgir en el proyecto.
Disear una estrategia en la que cada miembro del equipo ayude a

asegurar que la informacin llegue a todos.
Comenzar a desarrollar el plan de la comunicacin tan pronto como se

inicie un nuevo proyecto. Si el equipo de trabajo cambia con
frecuencia,
es
necesario
desarrollar
comunicacin.
97
nuevas
estrategias
de
5. FASE ANALIZAR
Despus de obtener la aprobacin de la fase anterior, Analizar es el siguiente

paso, para determinar el rendimiento de los procesos actuales, y comprender
cuales son las causas de los defectos.
Al momento de iniciar la fase analizar, la ecuacin Y = F(x1, x2 , , x3)
establecida por los miembros del equipo ya debe tener claramente
identificadas las Xs que afectan negativamente el resultado.
Se pasar
entonces de las conclusiones estadsticas a determinar soluciones prcticas

para crear acciones correctivas que generen una satisfaccin en el cliente y
una buena calidad en los productos o servicios.
Esta fase del proyecto tiene como principio no enfocarse en los sntomas del
problema, sino en la causa raz y en las soluciones del problema.
Para el desarrollo de esta fase se han identificado los siguientes pasos:
1.
Determinar que causa la variacin.
2.
Lluvia de ideas para la mejora de procesos.
3.
Determinar cuales mejoras tienen mayor impacto en los requerimientos

del cliente.
4.
Encontrar los riesgos asociados al proceso revisado (AMFE).
5.
Desarrollar el plan de capacitacin.
6.
Identificar los sistemas afectados de otras dependencias.
7.
Desarrollar el nuevo mapa de procesos.
8.
Presentar al comit para aprobar.

98
5.1
Despus de realizar las medidas, y observar la variacin de los procesos, el

equipo dirige sus esfuerzos a encontrar las causas de dicha variacin y crear
las soluciones apropiadas para los procesos. Las variaciones se pueden
representar de dos formas, las comunes y las especiales. Las comunes son
aquellas ms fciles de identificar por lo que el equipo se centrar solo en
eliminarlas, dejando a un lado el otro tipo que son las especiales, las cuales
son difciles de identificar, pero que tambin generan defectos al proceso. El
diagrama de corrido (Figura 20) puede ayudar a identificar las variaciones
con ms facilidad.
Diagrama de Corrido
7
66
6 6
6 6 6
5 5
44
4 4 4 4 4 44
Datos
5 5
33
3 3 333 33
33
2 22 2
22
22
33
22
11
33
2 22
22 2
0
Fecha/Tiempo

Durante todo el desarrollo del proyecto, Seis Sigma hace gran nfasis en
eliminar las suposiciones que los miembros del equipo tengan acerca del
proceso, la mayor parte de aquellas suposiciones no son la verdadera causa
de los problemas; y hacer una suposicin realidad, sin fundamentos,
basados nicamente en la experiencia de algn miembro del equipo
99
rompera el objetivo de Seis Sigma . No se trata de ignorar la experiencia de

25
algunos, ni la intuicin de otros, pero no utilizar los datos obtenidos se

convertira en una prdida de tiempo, y se corre el gran riesgo de tomar
decisiones errneamente, pasando por alto las verdades races del
problema.
El ciclo del problema se enfoca en la elaboracin y comprobacin de las
hiptesis planteadas acerca de la causa del problema como se muestra en la
figura 21. Los pasos a seguir para hallar la raz del problema son:
Plantear las hiptesis cuidadosamente evitando escribirlas vagamente o
hacindolas demasiado breves, y nunca cambiar o modificar los datos
para que las hiptesis sean ciertas.
Analizar los datos que se han recopilado en la fase anterior o en esta
fase, para discernir patrones, tendencias y otros factores que estn
directamente relacionados con el problema, buscando la aceptacin o el
rechazo de las hiptesis.
Analizar los procesos profundamente en su funcionamiento para
identificar incoherencias, o reas problemticas que puedan contribuir al
problema.
25
Hacer supociones es un paso que se debe hacer ms adelante, pero hacer realidad
supociones sin fundamentos es un error. Algunas veces las supociones pueden resultar
ciertas, pero no por esto se deben asumirlas ciertas desde el comienzo.
100
Analizar los
Datos/ procesos
Desarrollar
hiptesis causales
(una o mas)
Confirmar y
seleccionar las
causas vitales
Aceptar o
rechazar la
hiptesis
Analizar los
datos/procesos
Figura 21. Ciclo de anlisis del problema.

Los diagramas estadsticos ayudan a identificar las causas de la raz de los
problemas, el mtodo complementario de este anlisis es el planteamiento
de los 5 porques?, que consiste en preguntar hasta cinco veces por qu,
hasta llegar a una respuesta ms concreta de cual es la raz del problema.
Por ejemplo:
Por qu falla el sistema? Por errores en el cdigo de programacin.
Por qu tiene errores el cdigo de programacin? Por que cada vez

salen cosas nuevas.
Por qu cada vez salen cosas nuevas?
Por que los clientes no
explicaron claramente que se quera y los miembros del equipo no

entendieron.
Por qu los clientes no explicaron claramente lo que se quera? Por

que falt planeacin en el proyecto.
Por qu falt planeacin en el proyecto?

metodologa utilizada o fue obsoleta.
101
Por que fall la
En este ejemplo se observa, que la causa de la raz de los problemas en los

sistemas no son las lneas de programacin mal realizadas, sino el mal uso
de las metodologas.
Para esta actividad los grficos ms utilizados son los diagramas de pareto,
debido a que muestran claramente donde est la falla.
Figura 22. Pareto, causas de fallas del sistema.
Figura 23. Pareto, Causas de por que falla el cdigo.

102
La forma para elaborar los diagramas, es la metodologa de arriba a abajo:

desarrollar un nivel alto, y llegar hasta niveles bajos que son tan especficos
como se necesite. Otros diagramas como el de cajas y el de corrido, son
tiles para explicar ms a fondo las causas de la raz, pero su elaboracin se
realiza dependiendo si el proyecto lo requiere.
Otro diagrama que se utiliza frecuentemente para analizar la causa de la
variacin, es el diagrama causa-efecto (C-E) tambin conocido como el
diagrama de esqueleto de pescado, el cual comienza con una lista
estructurada de posibles causas, reuniendo un grupo de ideas y datos,
mediante el mtodo de lluvia de ideas . Una ventaja del diagrama C-E, es
26
que al establecer categoras, el grupo piensa en diferentes posibilidades sin

limitarse solo a unas pocas.
La explicacin del diagrama C-E es la siguiente: las agujas o espinas arriba
representan la variacin de las entradas o procesos, denotndose con la X.
Y las agujas abajo representan la variacin de las salidas, denotndose por
la Y.
Para construir el diagrama, se inicia indagndose el por qu de lo que se
analizar, en el momento en que el problema establecido es aceptado por los
miembros del equipo, la pregunta es ubicada en la cabecera del diagrama,
seguidamente los miembros del equipo comienzan una lluvia de respuestas
que se utilizar para encontrar la respuesta ms acertada a la pregunta
establecida.
El diagrama se utiliza tanto para servicios como para
produccin, como se muestra en la tabla 11.
26
Lluvia de ideas: Ver paso 2 de la fase analizar.
103
Tabla 11. Categoras del diagrama causa-efecto.

Servicios (Las 4 Ps)
Produccin (1 P y 5 Ms)
Polticas.
Maquinas.
Procedimientos.
Mtodos.
Personas.
Materiales.
Planta Tecnolgica.
Mediciones.
Madre naturaleza (ambiente).
Personas.
La figura 24 muestra el diagrama C-E, donde se ubican en las espinas

principales del pescado o en las agujas las categoras, y las ramificaciones
de cada categora las causas.
Politicas
Procedimientos
Causa uno
Porque?
Problema
Planta
Tecnologica
Personas
Figura 24. Diagrama causa efecto.

Las categoras son una sugerencia, y pueden cambiar segn el anlisis que
se deba llevar a cabo.
104
5.2
LLUVIA DE IDEAS PARA LA MEJORA DE PROCESOS
Una vez el equipo de trabajo tenga una lista de lo que ellos creen pueden ser
las causas de la variacin en los procesos, se comienza a considerar formas
de eliminar esta variacin. Por lo general se recurre al mtodo de lluvia de
ideas para introducir estas soluciones.
El mtodo de lluvia de ideas, es una herramienta que se utiliza para generar
la mayor cantidad de ideas o soluciones como sea posible a un problema
especfico. Antes de comenzar con una sesin efectiva de lluvia de ideas, es
necesario establecer un conjunto de reglas que permitan establecer un
cdigo de conducta para poder interactuar entre los miembros del equipo.
La mejor forma de establecer estas reglas, es hacer que el mismo equipo de
trabajo cree sus propias reglas. Una vez creadas, se debe asegurar que las
reuniones se sigan segn esas reglas.
Las siguientes son reglas que son comnmente usadas en una sesin de
lluvia de ideas:
Mantener a todos los miembros del equipo involucrados.
Que todos
conozcan que es lo que se quiere lograr.

No criticar las ideas de los otros. No es un debate, discusin o foro en el
que se intenta demostrar la superioridad sobre otras personas.
Construir sobre las ideas de otras personas.
Generalmente una idea
dada por una persona puede ser la base para otra gran idea.
No pensar en calidad sino en cantidad.
Eliminar las ideas repetidas o aquellas que no presentan relacin con el
fin de la reunin.
Las siguientes preguntas ayudan a preparar una sesin de lluvia de ideas.
105
Quin ser el lder?

Quines participarn?
Dnde se realizar?
Qu deseo como resultado?
Cmo puedo escribir rpidamente para registrar las ideas sin retrasar al
grupo?
Qu materiales necesito?
El resultado de la sesin ser una lista de ideas, algunas pueden ser buenas
otras no.
Se debe evitar intentar analizar las ideas durante la sesin,
despus se podrn analizar y clasificar mediante los diagramas de C-E, o

QFD. A menudo este es el siguiente paso despus de la lluvia de ideas.
Para crear los diagramas se debe clasificar la lluvia de ideas, creando grupos
con las ideas que se relacionen.
Cmo clasificar las ideas?:
Agrupar las ideas que deben estar juntas. No es importante definir por
qu deben ir juntas.
Clarificar cualquier idea si no es lo suficientemente clara.
Una idea puede ser ubicada en ms de un grupo si se considera
apropiado.
Los grupos pequeos de ideas pueden pertenecer a otros ms grandes.
Los grupos grandes de ideas pueden hacerse ms exactos o reducidos.
Cuando la mayora de las ideas se han agrupado, se puede comenzar a
incorporar los nombres de los grupos que se crearon.
106
5.3
DETERMINAR CUALES MEJORAS TIENEN MAYOR IMPACTO EN

LOS REQUERIMIENTOS DE LOS CLIENTES
Determinar con que se obtendr el mayor impacto en los clientes, es una

tarea de gran valor para el proyecto.
En la mayora de los casos, las
opciones elegidas a resolver son aquellas que poseen un costo menor y un

tiempo corto, sin establecer que tanto impacto generarn.
Seis Sigma
enfatiza que todas las decisiones deben ser basadas en hechos, y por lo
tanto sta es una herramienta que ayuda a la toma de decisiones.
Para la realizacin de este paso es recomendable realizar lo siguiente:
1. Listar los requerimientos de los clientes establecidos en la fase definir.
2. Cuadro de costo/tiempo/impacto.
Tabla 12. Costo/Tiempo/Impacto.
Situacin
Costo
Tiempo
Impacto
Programar nuevamente.
Alto
Alto
Medio
Redisear.
Medio
Alto
Alto
Corregir errores.
Alto
Bajo
Bajo
El orden en que se deben atacar las situaciones es: primero trabajar

sobre aquella que genere mayor impacto en el cliente, as su costo
sea alto, se reflejar en la satisfaccin del cliente despus.
Seguidamente atacar aquellas que tengan un costo bajo, y un impacto
medio, y despus atacar las restantes. Cuando el tiempo de proyecto
es largo, se deben resolver todas las situaciones, si por el contrario el
tiempo es relativamente corto, se debe atacar las de mayor impacto.
3. Crear el cuadro de ranking de las situaciones.
107
Tabla 13. Ranking de propuestas/requerimientos.

Ranking de Propuestas/Requerimientos
Grado
de
satisfaccin
(4)
Impacto
Cliente
(5)
Efecto
(4)
Impacto
Cliente
(5)
Total (6)
Efecto
(3) Propuesta
Impacto
(1)
(2)
Requerimiento
importancia
(3) Propuesta
por
implementar la mejora, o el
(7)
(7)
nuevo diseo
El clculo es el siguiente:
En
la
columna
requerimiento(1)
se
ubican
hacia
abajo
los
requerimientos de los clientes.
Calificar la importancia que posee cada requerimiento en la

columna de Ranking (2), en una escala definidad previamente.
Este punto se realizo en el paso 9 de la fase medir.
En la fila (3) Propuesta, se coloca una breve descripcin de las

propuestas planteadas para encontrar la satisfaccin de los
requerimientos de los clientes.
Se ubican tantas como se
hayan planteado.
Calificar el efecto que tiene la propuesta (3) en satisfacer el

requerimiento planteado, en la misma escala.
Calcular el Impacto-Cliente(5), multiplicando el Efecto(4) con el

Ranking de importancia (2)
Impacto Cliente (5) = Importancia (2) X Efecto (4)
108
El Impacto Total es calculado con la suma de todas las casillas

de Impacto-Cliente (5) de cada propuesta.
Los grados de satisfaccin por la propuesta (7), son calculados

con la suma de la columna (5) de cada Propuesta.
Tabla 14. Ejemplo QFD.
Ranking de Propuestas/Requerimientos
Propuestas
Adquirir
Lenguaje de
Nuevos
Programacin
Equipos.
10
10
100
10
110
Diseo Grafico Amigable.
16
20
10
70
77
Disponibilidad para la demanda de

los usuarios.
Grado de satisfaccin por implemen-
Efecto
I.C.
123
tar la mejora, o el nuevo diseo.
Total
Bsqueda gil, Eficaz, y Eficiente.
I.C.
Impacto
Efecto
Requerimientos
Importancia
Utilizar otro
84
Observando el ejemplo, se deduce que, utilizar otro lenguaje de

programacin tendra mayor impacto en todos los requerimientos, y
principalmente
se
estara
haciendo
nfasis
en
solucionar
el
requerimiento de los clientes que posee mayor puntuacin (Bsqueda

gil, Eficaz, y Eficiente).
109
5.4
ENCONTRAR LOS RIESGOS ASOCIADOS AL PROCESO

REVISADO (AMFE)
Antes de presentar las propuestas para el cambio de los procesos al lder del
proyecto, el equipo debe reconocer que esta propuesta no sera completa si
no se determinan los riesgos asociados a la mejora o el nuevo de diseo de
procesos.
Para realizar el anlisis de los riesgos, existen diferentes mtodos que se
pueden utilizar, uno de ellos es una hoja de balance conocida como: Analisis
de modos de fallo y efecto (AMFE) .
27
Los objetivos que plantea este mtodo son:

Identificar
formas
en
las
cuales
un
proceso
no
satisface
los
requerimientos del cliente.

Determinar las fallas potenciales que tienen ms efecto en el cliente.
Evaluar los controles que se disearon para prevenir la falla.
Documentar el plan de accin correctivo y sus resultados.
Este mtodo provee un importante resultado para cada modo de fallo. Este
resultado se denomina Nmero de Prioridad del Riesgo (NPR) . El mayor
28
valor encontrado de NPR es el valor del impacto ms serio en la falla. Los

tems con valores altos de NPR normalmente tienen planes de accin para
disminuir los riesgos. Ver anexo D.
27
28
Traduccin de FMEA: Failure Modes and Effect Analysis

RPN Risk Priority Number
110
5.5
La capacitacin se puede considerar como una poderosa herramienta con

que cuenta una organizacin para alcanzar sus objetivos.
Sin nuevos
conocimientos, conceptos, herramientas y metodologas, todos los miembros

(o el personal) que hacen parte de una compaa no podrn alcanzar un
nivel de competencia que la organizacin exige para ganar participacin de
los clientes, rentabilidad y competitividad.
La capacitacin implica un cambio de paradigma de las personas que operan
los procesos anteriormente realizados.
Se deben realizar prcticas
adecuadas y contar con los instructores adecuados para ensearle al

personal a pensar y actuar segn el cambio que se est implantando.
El objetivo principal de la capacitacin, es lograr que los usuarios tengan el
dominio necesario de las herramientas bsicas acerca de los procesos que
se estn implantando.
El proceso de capacitacin est formado por un ciclo constante de
actividades como lo muestra el diagrama de la figura 25.
5.5.1 Evaluar las necesidades para la capacitacin
La capacitacin es necesaria slo cuando un empleado carece del

conocimiento que se requiere para que realice su trabajo.
111
Figura 25. Ciclo de capacitacin.
5.5.2 Preparar un programa de capacitacin.
La planeacin del programa de capacitacin puede contener los siguientes

tem:
Establecer objetivos generales del curso.
Desarrollar un plan general de capacitacin.
Determinar la metodologa, tcnicas y enfoque de la capacitacin.
Desarrollar planes de sesiones de capacitacin.
Determinar los requerimientos de recursos.
Desarrollar el presupuesto para actividades de capacitacin.
112
5.5.3 Administrar la logstica para la capacitacin.
El xito de un programa de capacitacin depende, no slo de la calidad de

ste, sino tambin de la logstica.
Los participantes necesitan tener el
ambiente adecuado para evitar tener problemas para concentrarse durante la

capacitacin.
Para asegurar que las cosas se efectan correctamente, el responsable del
programa de capacitacin debe preparar un plan de trabajo que identifique:
Todas las actividades que necesitan realizarse.
Todos los materiales que se requieren para cada actividad.
Los responsables de cada actividad.
La fecha lmite para terminar cada actividad.
Ejemplo de un plan de trabajo general:

Tabla 15. Ejemplo de un plan de trabajo general.
Tema
Objetivo
Metodologa
Dirigido a:
Recursos
Presupuesto
Responsables
Fecha inicio
Ubicacin
Fecha fin
113
Cronograma
Sesin
Aprobado
Tema
Fecha
Hora
NOTAS
Ejemplo de un plan de trabajo por sesin

Tabla 16. Ejemplo de un plan de sesin.
Tema
Objetivos
Metodologa
Lugar
Hora
Fecha
Duracin
Cronograma
Responsable
114
Duracin
Una vez que se tiene el plan de trabajo, se debe asegurar que cada quien
tenga una copia. Debe utilizarse antes, durante y despus del taller para
comprobar que todo se realiza de acuerdo con el plan y el tiempo.
5.5.4 Evaluar y dar seguimiento al programa:
La evaluacin es un proceso continuo que comienza con el desarrollo de los

objetivos de capacitacin. Algunas veces, es til recolectar datos bsicos de
los participantes, tanto de su nivel de conocimientos y habilidades, como de
sus expectativas respecto a la capacitacin. Esto puede hacerse para
determinar el nivel de habilidad de cada participante y para recibir
informacin de lo que esperan aprender.
5.6
IDENTIFICAR
LOS
SISTEMAS
AFECTADOS
DE
OTRAS
DEPENDENCIAS
Tener conocimiento previo de los sistemas que afectarn directamente al
nuevo sistema y entender su funcionamiento, ayudar a que el proyecto
disminuya el riesgo de tener defectos durante su desarrollo o despus de su
implantacin.
Los casos de uso analizados con anterioridad, son utilizados para saber que
mdulos especficos de que sistemas son a los que se les debe dar mayor
prioridad.
Los aspectos ms relevantes que se deben tener en cuenta en los sistemas
son:
Plataforma en que funcionan.
Acceso a Datos (Si aplica).
115
o Motor(es) de base(s) de datos que utiliza(n).

o Modelo de datos, Esquema estrella o Entidad Relacin.
o Seguridad.
Objetos de programacin para la conexin (OLEDB, ODBC, JDBC,
TCP/IP, EDI, etc.).
Conexiones fsicas.
La integracin de los sistemas , es un paso posterior en la metodologa y en
29
el cual tener como mnimo el conocimiento de los anteriores aspectos

optimizara el trabajo.
5.7
Los mapas de proceso son unas de las herramientas esenciales de Seis

Sigma. Lo bsico de un mapa de proceso es simple: una serie de tareas y
decisiones conectados mediante flechas para mostrar el flujo de trabajo.
El equipo de trabajo debe evaluar los mapas de procesos en los cuales se
encuentra la causa raz del problema. De esta forma se pueden analizar y
observar algunas de las siguientes reas problemticas:
Desconexiones: Puntos en los que el trabajo se pasa de un grupo a otro o
donde se gestionan de forma incompleta en los que el proveedor y el
cliente no se comunican con claridad los requisitos mutuos.
Cuellos de Botella: Puntos del proceso en los que el volumen sobrepasa
la capacidad, lo que hace que todo el flujo de trabajo sea cada vez ms
lento. Los cuellos de botella son puntos clave para entregar a tiempo los
productos y servicios a los clientes y en la cantidad adecuada.
29
Ver paso integracin de sistemas, Fase Disear
116
Redundancias: Actividades repetidas en dos puntos del proceso, tambin

incluyen actividades paralelas que duplican los mismos resultados.
Bucles: Lugares donde se retorna un alto volumen de trabajo al proceso
para repararlo, corregirlo o solucionarlo.
Decisiones o inspecciones: Puntos del proceso en que intervienen la
eleccin de opciones, la evaluacin o la verificacin y crean retrasos
potenciales.
Estas actividades tienden a multiplicarse en la vida del
proceso o de la empresa.
117
USUARIO
SISTEMA
OFICINA PRESTAMO
EDIFICIO
Seleciona el tipo
de consulta
Cliente entra al
sistema
NO
Digita el tem
a buscar
NO
Exitosa?
Escoger el tem
especfico entre
todos los
resultados
Se encuentra
en el sitio?
NO
Disponible?
Observar
Ubicacin
SI
SI
FIN
Posesin del tem
Dirigirse a buscar y
diligenciar el formato de
prstamo
NO
Aprobado?
Reporte de
perdida
NO
Uso del tem
Realizar el
prstamo
Exitoso?
Devolucin al da
establecido
SI
Figura 26. Ejemplo diagrama de flujo del nuevo proceso.
118
6. FASE DISEAR
En la fase de diseo se determina la arquitectura general del sistema y su

comportamiento dinmico, adaptando la especificacin realizada segn los
resultados de las soluciones obtenidas en la etapa anterior. En esta fase, se
decide que tecnologa se utilizar en el sistema aprovechando y adaptando
sus ventajas.
Los pasos que se identificaron para esta fase son los
siguientes:
1.
Seleccionar la Metodologa de desarrollo de software.
2.
Disear el formato de documentacin de programas.
3.
Definir la seguridad.
4.
Especificacin del diseo.
5.
Integracin del Sistema.
6.
Revisin y perfeccionamiento del diseo.
7.
Seleccin de Hardware y Software.
8.
Construccin de prototipos.
9.
Disear el plan de pruebas.
10. Revisar que los prototipos cumplan con los requerimientos.
119
6.1
SELECCIONAR METODOLOGA DE DESARROLLO DE SOFTWARE
6.1.1 Cascada.
En un modelo en cascada, un proyecto progresa a travs de una secuencia

ordenada de pasos partiendo del concepto inicial del software hasta la
prueba del sistema. El proyecto realiza una revisin al final de cada etapa
para determinar si est preparado para pasar a la siguiente etapa. Cuando la
revisin determina que el proyecto no est listo para pasar a la siguiente
etapa, permanece en la etapa actual hasta que est preparado.
El modelo en cascada est dirigido por documentos; es decir, los productos
principales del trabajo que se pasan de etapa en etapa son documentos.
Figura 27. Modelo Cascada.
Ventajas
120
Ayuda a minimizar los gastos de la planificacin porque permite

realizarla sin problemas.
La secuencia de pasos y de las tareas que se realizan en cada paso

se definen claramente.
Se puede permitir que el personal se transfiera de un proyecto a otro.
Desventajas
No permite flexibilidad en los cambios.
Los requerimientos deben ser especificados completamente al

principio del proyecto y no pueden sufrir cambios.
El cliente es involucrado slo peridicamente.
Una etapa no comienza hasta no terminar por completo la anterior.
No proporciona resultados tangibles en forma de software hasta el

final del ciclo de vida.
Requiere una cantidad excesiva de documentacin.
6.1.2 Espiral.
El modelo de desarrollo en espiral, es un modelo manejador de riesgos

durante el proyecto. Es utilizado para guiar a los miembros a diferentes
niveles durante el desarrollo del sistema de informacin. Se diferencia de los
otros modelos en dos caractersticas, la primera de ellas es su parte cclica
donde muestra durante el transcurso del proyecto un incremento en la
definicin e implementacin del sistema y un decrecimiento en el riesgo. La
otra diferencia es, que se enfoca en los puntos ms importantes
comprometindose a asegurar que las soluciones sean exitosas.
121
Costo
Acumulado
Progreso
a travs
de los
pasos
Determinar
objetivos,
alternativas,
urgencias.
Evaluar alternativas
identificar, resolver el riesgo
Anlisis
Riesgo
Anlisis
Riesgo
Revisin
Parte de la
Comisin
Anlisis
Riesgo
Anlisis
Riesgo
Prototipo
1
Prototipo
2
Prototipo
3
Simulaciones, Modelos, Benchmarking
Plan de Requerimientos
Plan del Ciclo de Vida
Concepcion de
la operacin
Requeri
mientos
de
Software
Diseo de
Software
Validacin de
Requerimientos
Integracin y
Plan de
Pruebas
Planear las
siguiente
etapas
Prototipo
Operacional
Verificacin y
Validacin
del diseo
Aprobacin
Implemende la
tacin
prueba
Diseo
Detallado
CodiPrueba
ficacin
de
Unidad
Integracin
y Prueba
Desarrollar,
Verificar
Siguiente nivel de producto
Figura 28. Modelo de Espiral.

Ventajas
El riesgo es considerado desde muchos puntos de vista, lo que ayuda a
garantizar no pasar por alto detalles que puedan hacer fracasar el
proyecto.
Se crean prototipos y se hacen simulaciones en cada fase, para minimizar
el riesgo.
Se observan diferentes alternativas de solucin en cada fase.
El diseo toma mayor importancia en las reas donde existe mayor
riesgo.
122
Despus de cada fase, se evala lo realizado y se planea la siguiente

fase.
Puede combinarse con otros modelos.
El costo es inversamente proporcional al riesgo.
Desventajas
Se puede llegar a perder la continuidad del proyecto cuando se presentan
abandonos por parte de los miembros del equipo de trabajo.
Se retraza todo el proyecto cuando los resultados no son entregados
segn el cronograma.
Si el riesgo no esta bien identificado, el modelo falla.
Requiere de ms administracin.
6.1.3 Proceso Unificado.
El proceso unificado, es un proceso de desarrollo de software basado en

componentes, que adopta UML
30
como lenguaje de modelamiento para
unificar todos los esquemas de un sistema software.

Ms que un simple proceso de desarrollo, es un marco de trabajo que puede
especializarse en gran variedad de sistemas software, para diferentes reas
de aplicacin, tipos de organizaciones, niveles de aptitud y tamaos de
proyecto.
Los verdaderos aspectos definitorios del Proceso Unificado se resumen en
las siguientes tres caractersticas, dirigido por casos de uso, centrado en
la arquitectura e iterativo e incremental.
30
UML: Unified Modeling Language. Constituye una parte esencial del Proceso Unificado,
pues sus desarrollos fueron paralelos.
123
Cada ciclo se desarrolla a lo largo de cuatro fases como se muestra en la

figura 29. En la columna izquierda de la figura se muestran los flujos de
trabajo fundamentales. Las curvas muestran hasta donde se llevan a cabo
los flujos de trabajo en cada fase. Como cada fase se divide en iteraciones,
stas deben pasar por los flujos de trabajo, como se observa en la figura 29.
Figura 29. Modelo proceso unificado.
Ventajas
Desarrollo basado en componentes.
Utiliza UML como nico lenguaje de modelamiento.
Proceso Integrado.
124
Permite ganar y retener control intelectual sobre el proyecto, para

administrar su complejidad.
Provee una base efectiva para el reutilizacin de software.
Las iteraciones reducen el riesgo.
Desventajas
Es un mtodo enfocado en el proceso y no en el cliente.
No se enfoca en el verdadero problema del cliente, si no en los
requerimientos.
6.1.4 Modelo de Capacidad de Maduracin (CMM ).

31
Es un programa especializado de calidad, enfocado al desarrollo de software.

Fue creado por SEI como respuesta a los altos costos, cantidad de tiempo y
32
la falta de programacin que se presentaban en los proyectos de desarrollo

de software.
CMM es una metodologa para mejorar el desarrollo y las entregas de
software haciendo los procesos predecibles.
31
32
CMM: Capability Maturity Model.

SEI: Software Engineering Institute
125
Nivel 5
Optimizado
Nivel 4
Administrado
Nivel 3
Def inido
Nivel 2
Repetible
Nivel 1
Inicial
Figura 30. Modelo de CMM.

Ventajas
Se centra en la reduccin de la variacin.
Cuantifica el funcionamiento de mejora de procesos.
Desventajas
No tiene una intensa preocupacin por el cliente, ni hace nfasis en el
trabajo en equipo ni en las decisiones basadas en hechos.
Se aplica solamente a los procesos de software.
CMM no asegura que el problema correcto esta siendo tratado.
126
6.1.5 Proceso Personal de Software (PSP ).

33
El proceso personal de software, es considerado no solamente como un

proceso de desarrollo de software, sino tambin como una metodologa de
mejoramiento de los procesos software, ayuda a ingenieros y desarrolladores
individuales a mejorar su habilidad de escribir cdigo, a planificar de forma
ms exacta los proyectos y a administrar la calidad de su producto.
PSP puede ser aplicado a muchas partes del proceso de desarrollo de
software, desde el desarrollo de programas pequeos, la definicin de
requerimientos,
escritura
de
documento,
pruebas
de
mantenimiento.
PSP 3
DesarrolloCclico
PSP 2
Rev isindelCdigo
Rev isindelDiseo
PSP 1
EstimacindelTamao
ReportedePruebas
PSP 0
ProcesoActual
Medidas Bsicas
PSP 2.1
DiseodePlantillas
PSP 1.1
PlanearTareas
PlanearCronogramas
PSP 0.1
Estndares deCodif icacin
Propuestade lamejora delproceso
Medidas delTamao
Figura 31. Modelo proceso personal de software.

33
PSP: Personal Software Process
127
sistema
Ventajas
Mejora la calidad de los productos y la eficiencia de los procesos.
Las revisiones requeridas durante el proceso, aseguran que los
problemas de diseo y codificacin sean identificados.
Produce cero defectos sobre el calendario y los costos deseados.
Desventajas
La curva de aprendizaje es grande.
No define como implementar un producto.
6.1.6 Proceso de Software en Equipo (TSP ).

34
Es un modelo utilizado para guiar a los equipos de ingenieros a desarrollar

intensamente software. Ayuda a los equipos a cumplir con los cronogramas
planteados y los presupuestos acordados del proyecto. Maneja de 2 a 20
miembros por equipo y hasta 150 equipos.
34
TSP: Team Software Process.
128
Lanzamiento
Re-Lanzamiento
Re-Lanzamiento
Re-Lanzamiento
alsdkfjlaksjdf
Requerimientos
Diseo a
Nivel Alto
Implementacin
Integracin
y
Pruebas
Post-mortem
Figura 32. Modelo Proceso de software en equipo.

35
Ventajas
Los proyectos TSP, pueden comenzar o finalizar en cualquier fase.
Cada fase puede comenzar con un lanzamiento o relanzamiento.
Ayuda a realizar productos de alta calidad, con costos y cronogramas
agresivos.
35
Post-mortem: se dice de una evaluacin que se realiza a algn suceso o hecho que ha
sucedido recientemente.
129
Desventajas
Problemas del trabajo en equipo (liderazgo inefectivo, no compromiso,
calidad pobre, diferencias en el nivel de conocimiento por los miembros).
Diferentes objetivos establecidos, o no priorizacin.
6.1.7 Desarrollo Rpido de Aplicacin (RAD ).

36
Es un modelo de desarrollo de software lineal secuencial, enfocado en

periodos cortos de tiempo. Se considera gil y de desarrollo altamente veloz,
basando su construccin en componentes.
Equipo n.3
Equipo n. 2
Equipo n.1
M. de G
Modelado
de gestin
M. de D.
Modelado
de gestin
Modelado
de datos
M. de P.
G. de A.
Modelado
de datos
Modelado
de procesos
P. y V.
Generacin
de
aplicaciones
Modelado
de procesos
Pruebas
y
Valumen
Generacin de
aplicaciones
Pruebas
y
Valumen
De 60 a 90 das
Figura 33. Modelo de desarrollo rpido de aplicacin.
36
RAD: Rapid Aplication Development.
130
Ventajas
Es un proceso lineal, donde no se necesita tanta realimentacin.
Con el prototipado es fcil tomar riesgos tecnolgicos.
Desventajas
Las expectativas del cliente son altas con respecto al tiempo y la calidad
del producto esperado.
Tiene el riesgo de caer en programar - corregir.
Requiere de recursos humanos suficientes en proyectos de gran escala.
6.1.8 Extreme Programing (XP).
Extreme Programming es una disciplina gil de desarrollo de software,

basada en la simplicidad, comunicacin, y realimentacin con el cliente.
Trabaja enfocndose en partes simples, que individualmente no tienen
sentido, pero integrndolas forman un producto software de alta calidad, que
se entrega tan rpido como sea posible.
131
Escenarios Prueba
Nuevas
Historias
Velocidad
Proyec
Historias de
usuarios
Requerimientos
Plan de
Lanzamiento
Metfora
del sistema
Arquitectura de
Punto
Problemas
Planeacin del
Lanzamiento
Estimaciones
no certeras
Ultima
Versin
Iteracin
Siguiente
Iteracin
Aprovacin
del Cliente
Pruebas
Aceptadas
Lanzamientos
Pequeos
Estimaciones
Confidenciales
Punto
Figura 34. Modelo Extreme Programming.

Ventajas
Altamente incremental e iterativo.
Metodologa de desarrollo gil.
Se desarrolla la versin ms simple posible que resuelva el problema.
Se ejecutan todas las pruebas todos los das.
Se enfoca en la simplicidad.
Desventajas
No hay requisitos explcitos si no que el cliente participa en el desarrollo.
Se empieza por automatizar las pruebas.
Se cambia el diseo aunque sea radicalmente cada vez que se necesite
(despus de la etapa del diseo).
132
Tabla 17. Comparacin metodologias de desarrollo de software
133
6.2
DISEAR EL FORMATO DE DOCUMENTACIN DE PROGRAMAS
Debido a la rotacin de personal en las compaas, y teniendo en cuenta que

los sistemas de informacin son una herramienta fundamental para realizar
las tareas, se debe tener un formato estndar para documentar los
programas que facilite la comprensin del cdigo a todos los miembros del
equipo debido a que la forma de programar es diferente en cada uno de los
desarrolladores. La cantidad de tiempo que un integrante nuevo invierte en
entender el cdigo de los programas existentes es realmente alta y costosa.
Por eso la documentacin de programas toma ms importancia en el
Los formatos pueden llegar a tener diferentes estilos, el lder del proyecto en
conjunto con los miembros del equipo deben llegar a un consenso acerca del
formato a utilizar.
Algunas caractersticas que debe tener el formato son:
Nombre del proyecto.
Nombre del programa.
Breve descripcin.
Versin del software.(Opcional)
Nombre del autor.
Fecha de creacin.
Directorio donde se almacenar.
Variables ambiguas.
Directorio de archivos fuente.
Bases de Datos a las que accesa, tablas de la Base de Datos que
accesa, y Campos utilizados(Opcional).
134
6.3
La seguridad en los sistemas de informacin juega un papel importante. En

las fases anteriores no se mencionaba directamente el tema de seguridad,
aunque al analizar los riesgos, la seguridad fue un punto a tener en cuenta.
Es en este instante en el que el equipo de trabajo toma la decisin sobre que
aspectos de seguridad deben ser tratados con gran importancia.
Debido a la variedad de los sistemas de informacin que posee una
compaa, no todos los estndares de seguridad son aplicables para
cualquier sistema, y aunque para muchos departamentos de Administracin
de Informacin la seguridad va a nivel de sistemas operativos nicamente,
existen otros aspectos que van a nivel de diseo del sistema que pueden
resultar menos costosos y ms efectivos que otros.
Los roles y las responsabilidades de los miembros que forman parte de la
seguridad se pueden describir como sigue:
Black Belt: Lder del proyecto.
Jefe de seguridad de sistemas de informacin: Es el encargado de

desarrollar los estndares de seguridad que sern aplicados durante
el ciclo de vida del software.
Asesor legal:
Es el responsable de asesorar a los miembros del
equipo acerca de todos los asuntos legales en que pueda llegar a

incurrir un sistema de informacin, como el contrato, licencias,
incumplimientos, confidencialidad de informacin, derechos de autor,
etc.
Las consideraciones que se deben tener en cuenta en aspectos de seguridad
son las siguientes:
135
1. Seguridad general de la informacin:
la responsabilidad de la
seguridad del sistema debe ser asignada con nombres propios a los
encargados, dependiendo del contrato que se haya realizado.
2. Control de hardware y software:
se debe determinar quien puede
instalar, agregar o cambiar software, y bajo que circunstancia es

permitido. El control del software se hace con el fin de evitar virus,
modificaciones al cdigo, instalacin de software no licenciado, o
software que desproteja la entrada de intrusos.
3. Control de la informacin y de los datos. los miembros de equipo
trabajarn con informacin y datos de la compaa que no tienen
acceso libre, por lo tanto se deben establecer clusulas para prevenir
la divulgacin de la informacin o datos durante el proyecto o despus
de su finalizacin.
4. Seguridad en la documentacin:
proporciona instrucciones a los
usuarios acerca de las caractersticas de la seguridad en el sistema,

adems de convertirse en un soporte para documentar que los
requerimientos se han cumplido.
5. Asuntos legales: se debe trabajar en conjunto con el departamento
legal de la compaa, en los asuntos de tipo jurdico, para evitar
violaciones de seguridad, riesgos y responsabilidades en el contrato.
6. Personal: se debe definir el personal que tendr acceso fsico y virtual
a la informacin durante y despus del proyecto.
7. Seguridad fsica: ubicacin, medio ambiente, temperatura, riesgos de
accidentes, etc.
8. Caractersticas en los sistemas de informacin:
se refiere a las
funciones especficas que se incorporan en los sistemas de

informacin, dependiendo de variedad de factores como, sistema
operativo, procesamiento de datos, transmisin de datos, riesgos, etc.
Por ejemplo:
a. Identificacin y Autentificacin.
b. Control de Acceso.
136
c. Auditoria.
d. Criptografa.
Autentificacin de Datos.
Firma digital.
Llave de acceso.
Mdulos de seguridad para la criptografa.
Validaciones.
e. Integridad del Sistema.

f. Arquitectura del Sistema
Estas consideraciones son importantes para cualquier sistema, aunque la
realizacin de todas no es factor indispensable para que un sistema sea
seguro totalmente.
El tamao y la importancia que el proyecto pueda
representar a la compaa requerir de estas o de otras consideraciones

ms.
6.4
El diseo es el paso ms importante en el desarrollo de cualquier producto o

servicio. Podra definirse como: "el proceso de aplicar distintas tcnicas y
principios con el propsito de definir un dispositivo, un proceso o un sistema
con suficiente detalle como para permitir su realizacin fsica"
37
El diseo del software se aplica independientemente de la metodologa de

desarrollo de software utilizado. El resultado de la creacin de un modelo de
diseo, comprende el diseo de las representaciones de datos, la
arquitectura, interfaces y procedimientos.
37
TAYLOR, E.S., An Interim Report on Engineering Design, Massachusetts Institute of

Technology, Cambridge, MA, 1959.
137
Figura 35. Modelo del diseo.

En la figura 35, se representa el modelo del diseo en forma de una
pirmide. Esto significa, que se busca crear un diseo de software que sea
estable. Una base amplia en el diseo de datos, que transforma el modelo
de la informacin en las estructuras de datos necesarias para crear software.
Una regin media estable, el diseo arquitectnico, que define la relacin
entre los principales elementos estructurales del programa. El diseo de
interfaz que describe como se comunica el software consigo mismo, con los
sistemas que operan con l, y con los usuarios finales. Y una parte superior,
diseo procedimental, que transforma los elementos de la arquitectura en
una descripcin procedimental de los componentes del software.
Existe un conjunto de principios, sugeridos por Davis para el diseo de
38
software, algunos sealados en la siguiente lista:
Aumentar de tamao los sistemas incrementalmente: Una de las tcnicas

ms efectivas para reducir los riesgos en la construccin de software, es
hacerlos crecer incrementalmente. Comenzar con un sistema pequeo,
38
Se comentan un pequeo conjunto de los principios de diseo de Davis. Para

complementar esta informacin ver: Davis, A. 201 Principles of Software Development,
McGraw Hill 1995.
138
que implemente solo unas pocas funciones, y luego incrementar su

funcionalidad.
Hacerlo Simple .: Una arquitectura o un algoritmo simple conduce a

39
alcanzar mantenibilidad. Adems, si se descompone el software en

subcomponentes, se debe tener en cuenta que los humanos poseen
dificultad para comprender ms de siete cosas al tiempo.
Se debe poder seguir los pasos del diseo hasta el modelo de anlisis:
Como un solo elemento del diseo se refiere a menudo a mltiples
requisitos, es necesario tener los medios para hacer un seguimiento de
cmo el modelo de diseo ha satisfecho los requisitos.
El diseo no debe inventar nada que ya est inventado: Los sistemas se

construyen usando un conjunto de estructuras de diseo, muchas de las
cuales ya se han utilizado anteriormente. Estas estructuras, a menudo
denominadas componentes de diseo reutilizables, deben considerarse
siempre antes que reinventar algo.
El diseo debera estructurarse para admitir cambios: Durante el

desarrollo de software, generalmente se encuentran errores, nuevos
requerimientos, o el resultado de la falta de comunicacin. Todo esto
causa que el diseo cambie. Esto quiere decir que se deben seleccionar
arquitecturas, componentes y especificaciones tcnicas que permitan
afrontar mejor el cambio. Los conceptos de Abstraccin, Refinamiento,
Modularidad, entre otros, permite conseguir este principio.
El diseo no es escribir cdigo, y escribir cdigo no es disear: Incluso

cuando
se
crean
diseos
procedimentales
detallados
para
los
componentes de un programa, el nivel de abstraccin del modelo de

diseo es mayor que el del cdigo fuente. Las nicas decisiones hechas
de diseo al nivel de cdigo se refieren a los pequeos detalles de
implementacin que permiten codificar el diseo procedimental.
39
Hacerlo Simple: Mantenerlo lo mas simple posible.
139
Analizar las causas de los errores: Los errores son comunes en el

desarrollo de software. Generalmente se invierten enormes cantidades
de dinero y recursos detectando y eliminando. Como lo dice Seis Sigma,
es ms beneficioso prevenirlos antes que ocurran.
Se debe valorar la calidad del diseo mientras se crea, no despus de

terminarlo: Existen variedad de conceptos de diseo y medidas del diseo
disponibles para ayudar al diseador en la valoracin de la calidad.
El diseo debe presentar uniformidad: Un diseo es uniforme si parece

que slo una persona desarroll todo el conjunto. Se deberan definir
normas de estilo y de formato para un equipo de diseo antes de
comenzar el trabajo de diseo.
Un diseo est integrado si se tiene
cuidado en definir las interfaces entre los componentes del diseo.
Asignar a todos los productos un nombre y una versin: Aunque existan

muchas versiones intermedias de productos software, especificacin de
requerimientos, especificacin de diseo, cdigo, plan de pruebas, plan
de administracin, manuales de usuario, etc, cada producto se debe
abastecer de un nico nombre, nmero de versin y revisin y la fecha de
creacin.
Realizar el seguimiento de cada cambio: Cada cambio puede generar

problemas, tres de ellos son:
1.
El cambio realizado no solucion el problema que se pretenda

tratar.
2.
El cambio solucion el problema, pero caus otros.
3.
En un futuro, cuando el cambio se percibe, nadie puede determinar

por que fue hecho o por quien.
En cualquiera de los tres casos, es mejor hacer un seguimiento de cada

cambio, llevando un registro de cada uno de los siguientes detalles:
La peticin del cambio.
El proceso de la aprobacin del cambio (Quin, cundo, por qu).

140
6.5
Los cambios a los productos intermedios.
INTEGRACIN DEL SISTEMA
La Integracin de Sistemas consiste en integrar productos hardware y

software estndar, as como productos desarrollados especficamente para
construir un sistema que sea una solucin completa que responda a las
necesidades de los usuarios.
La integracin de aplicaciones se debe hacer utilizando protocolos y
tecnologas estndar disponibles. Existen diferentes mtodos y caminos para
integrar diferentes paquetes de aplicaciones y entornos de sistemas para
crear una solucin tecnolgica interoperativa y homognea. Tambin es
necesario tener en mente que la integracin de soluciones debe ser lo
bastante flexible como para ser fcilmente adaptable a los nuevos
requerimientos de negocio.
6.5.1 Tipos de integracin de sistemas
Actualmente existen 5 tipos de integracin de sistemas. Aunque el objetivo

de la metodologa no es entrar en detalle sobre cada tipo, se describir
brevemente cada uno de ellos.
1. Integracin orientada a datos.
Se basa en extraer datos de una base de datos para ubicarlos en otra, dentro
de la misma organizacin o con otras organizaciones. Presenta las
siguientes caractersticas:
141
Agrega bases de datos completas, tablas o campos, si el sistema de

informacin lo requiere.
Se puede dar una transformacin en los datos o en la lgica del negocio.
Es la integracin ms econmica.
Se debe entender el metadata entre las dos bases de datos.
40
Se debe definir los eventos para que las seales sean capturadas cuando
se necesita mover los datos.
Los mtodos para realizar este tipo de integracin son:
-
Software para replicar la base de datos.
Message broker.
Construir una aplicacin para sincronizarlas.
Sistema 1
Sistema 2
Logica de
Programacin
Logica de
Programacin
DATOS
Figura 36. Integracin orientada a datos.
40
Metadata: Datos acerca de los datos.
142
2. Integracin orientada a la interfaz de aplicacin (API).

Es una interfaz que sirve de apalancamiento entre un paquete de software
dentro
de
dos
sistemas
de
informacin.
Presenta
las
siguientes
caractersticas:
Utiliza los procesos del negocio y los elementos de datos ms simples.
Los messages broker son los ms utilizados para realizar la API .
41
Su utilizacin puede generar varios niveles de acceso o de servicio sobre

las otras aplicaciones.
Se implementa escribiendo una funcin de llamado dentro de un
programa el cual provee el enlace a una subrutina que necesita ser
ejecutada.
Algunos de los estndares para utilizar un API son:
-
Mtodo de invocacin remoto de Java (RMI).
CORBA.
Inter-ORB Protocol.
Microsoft Component Object Model COM+.

Sistema 1
Sistema 2
Aplicacin
API
Datos
Datos
Figura 37. Integracin orientada a interfaz de aplicacin (API).

41
API: Application program interface.
143
3. Integracin orientada a mtodos.

Busca compartir la lgica del negocio mediante una aplicacin compartida
que entienda los mtodos de los otros sistemas. Presenta las siguientes
caractersticas:
Se debe definir los mtodos y estndares a compartirse a travs de las
aplicaciones.
Existen las siguientes formas de realizarlo:
-
Utilizar un servidor Central.
Utilizar Objetos Distribuidos.
Ofrece la reutilizacin de cdigo.

Presenta una desventaja cuando los sistemas tienen que sufrir cambios
grandes para que se pueden entender con otros.
Sistema 1
Sistema 2
Aplicacin
Aplicacin
Modulo
Funcional
Figura 38. Integracin Orientada a Mtodos.
144
4. Integracin orientado a portal.

Presenta la informacin de diferentes aplicaciones a travs de una sola
interfaz, la mayora de las veces utilizando un navegador.
Presenta las
siguientes caractersticas:
Implementacin rpida.
Aprovecha la maduracin de tecnologas como:
Web Services, Web
Clients, Servidores de Bases de Datos, Servidores de Aplicacin.

Ofrece seguridad en la integridad de los datos de las aplicaciones.
La informacin no fluye en tiempo real, necesita de la interaccin humana
para realizarse.
Los sistemas no reaccionan automticamente a los eventos del negocio.
La informacin tiene que ser abstrada de una capa lgica de otra
aplicacin.
Sistema 1
Sistema 2
Sistemas
Legales
BROWSER
PDA
Middelware
ERP
Computador
WEB
SERVER
Datos
Portatil
Figura 39. Integracin Orientado a Portal.

145
5. Integracin orientada a procesos.

Define modelos de procesos comunes para que se extiendan a travs de los
diferentes
sistemas
internos
externos.
Presenta
las
siguientes
caractersticas:
Presenta una visibilidad confiable de los dems sistemas
integrados.
Los procesos son entendidos perfectamente por los otros sistemas.
Usa estndares maduros, asemejando un sistema de workflow.
Reaccionan en tiempo real a los eventos ocurridos en los otros
sistemas
Brinda la capacidad de redefinir procesos en cualquier momento.
Estandares de los Procesos Acordados
Sistema 1
Sistema 2
Aplicacin
Aplicacin
Figura 40. Integracin Orientado a Procesos.
146
6.5.2 Estndares para conexin a la red
ASCII : Representaciones numricas de caracteres de texto.
TCP/IP , PPP : Son los protocolos ms conocidos de transmisin de
42
43
44
datos, que indican cmo se efecta la transferencia de informacin en la

red. El protocolo TCP es el servicio de entrega segura y continua de
informacin, en donde se especifica el formato de los datos y los
reconocimientos que dos computadoras intercambian para lograr una
transferencia segura y que asegura que los datos lleguen a su destino
correctamente. El IP es el encargado de direccionar correctamente los
paquetes de informacin que se enviaron a travs de la capa TCP. PPP
son versiones de TCP/IP diseadas para establecer comunicacin TCP/IP
a travs del puerto serial al que el mdem est conectado cuando la
conexin se hace va telefnica.
FTP : Estas siglas designan un mtodo que permiten realizar el envo y

45
recepcin de archivos a travs de Internet, de un computador a otro.
HTML : Es un lenguaje que permite describir hipertexto, es decir, texto

46
presentado de forma estructurada y agradable, con enlaces que

conducen a otros documentos o fuentes de informacin y con inserciones
multimedia.
42
43
44
45
46
ASCII: American Standard Code for Information Interchange.

TCP/IP: Transmission Control Protocol / Internet Protocol.
PPP: Point to Point Protocol.
FTP: File Transfer Protocol.

HTML: HyperText Markup Language.
147
6.5.3 Interfaces de conexin a bases de datos.
JDBC : El driver de conexin de java con las bases de Datos.
ODBC : La conectividad abierta de las bases de datos, es un estndar o
47
48
una interfaz de programacin que se utiliza para accesar fuentes de datos

(una base de datos que conecta con otros programas) que utilizan SQL
como lenguaje de manipulacin de datos, sin importar las interfaces
propietarias de los sistemas manejadores de bases de datos.
OLEDB: es una tecnologa que tiene como objetivo resolver ciertas

restricciones de ODBC. Autoriza el acceso a todo tipo de datos,
permitiendo administrar el aspecto de tener distribuidas las fuentes de
datos, y tiene en cuenta las restricciones de la Web. En un futuro esta
tecnologa reemplazar a la tecnologa ODBC. ADO es el modelo de
objetos que permite simplificar el acceso a esta tecnologa.
6.6
REVISIN Y PERFECCIONAMIENTO DEL DISEO
Est actividad, se hace como garanta de calidad del diseo del software. En
ella intervienen analistas, lideres del proyecto y en algunos casos los
clientes. Los principales objetivos son:
1. Descubrir errores en la lgica.
2. Verificar que cumpla con los requisitos.
3. Verificar la manejabilidad y claridad en el diseo.
47
48
JDBC: Java Database Connectivity.

ODBC, Open Database Connectivity.
148
Las siguientes caractersticas sirven de directrices para la evaluacin de un

buen diseo :
49
El diseo debe implementar todos los requisitos explcitos contenidos en

el modelo de anlisis y debe acomodar todos los requisitos implcitos que
desea el cliente.
El diseo debe ser una gua que puedan leer y entender los que
construyan el cdigo, prueban y mantienen el software.
El diseo debera proporcionar una completa idea de lo que es el

software,
enfocando
los
dominios
de
datos,
funcional
de
comportamiento desde la perspectiva de la implementacin.

Existen muchas tcnicas que ayudan a evaluar y perfeccionar el diseo
inicial. A continuacin se mencionan algunas:
Ensayos y simulaciones de un proceso: Ensayar y discutir el

funcionamiento del proceso, es una buena forma de validar el rendimiento
de las cosas, conllevan a que los posibles problemas salten a la vista y
determinar si es necesario mayor nivel de detalle.
Evaluacin de momentos de la verdad: Para esto es necesario identificar

y evaluar las CTQ's del cliente en el proceso. Aunque se dispongan de
los mejores mtodos para proporcionar productos mejores y con mayor
rapidez, siempre se debe tratar al cliente y contar con l, para que esto
no repercuta en su insatisfaccin.
Secciones de Informacin: Disponer de mayor informacin del cliente o

personas familiarizadas con los procesos pueden ayudar a tener una
mejor comprensin de stos. De esta forma se podrn prever cosas que
49
McGlaughlin, R. Some Notes on Program Design, Software Engineering Notes, vol 16, n
4, octubre 1991, pgs 53 - 54.
149
nunca antes se han imaginado. La bsqueda de informacin en otras

personas tambin proporcionar apoyo. Se debe tener cuidado de no
limitarse a escuchar atentamente sugerencias, para luego no hacer nada
con la informacin sugerida.
Anlisis de Problemas Potenciales: Todos los procesos tienen un gran

nmero de problemas potenciales. El equipo de diseo de un proceso,
puede tratar todos los problemas posibles, pero tambin puede tratar de
identificar los ms grandes y preparar acciones proactivas para
eliminarlos o reducirlos.
En el anlisis de problemas potenciales, la
estrategia fundamental es centrarse en las etapas crticas del proceso y

preguntar: Qu podra fallar?. Entonces hay que concentrarse en los
problemas que tengan mayor probabilidad o mayor impacto y desarrollar
acciones preventivas o reparadoras .
50
51
Anlisis de consecuencias no deseadas: Se debe analizar el impacto que

conlleva el nuevo proceso y los diversos procedimientos, formularios,
sistemas, etc. Poner a funcionar un nuevo proceso, trae un efecto en la
gente y los dems procesos. Este cambio, puede crear problemas que
nunca se haban pensado y que son potencialmente importantes.
Comprender la interconectividad de los procesos es clave para realizar un
buen anlisis de las consecuencias. Puede hacer un seguimiento de los
efectos de los nuevos procesos para ver quin se ver afectado y como.
Lo ms importante en la revisin y el perfeccionamiento del diseo de los

procesos, es obtener informacin de estos y adaptar o mejorar el proceso de
manera que incorpore ese aprendizaje.
50
Acciones Preventivas: Son las acciones encaminadas a reducir o bloquear el efecto del
problema.
51
Acciones Reparadoras: Son las medidas diseadas para contener o vencer las
consecuencias del problema.
150
6.7
En la etapa de diseo se debe tener especial cuidado con la seleccin de las

herramientas hardware y software que se van a utilizar para el desarrollo del
proyecto.
En el proceso de seleccin se pueden mencionar dos pasos:
1. Identificar el software que mejor se ajuste a los requerimientos.
2. Identificar el hardwareque mejor funcione con ese software.
El analista de sistemas, deber evaluar el software junto con el lder del
proyecto.
La decisin ms importante que se debe tomar es el tipo de
software que se usar, existen diferentes propuestas de software libre, o con

licencia que se pueden considerar.
Para esta decisin se debe haber
realizado un previo anlisis de costo/beneficio. Se pueden evaluar desde las

siguientes perspectivas:
Modo de operacin.
Transicin.
Actualizaciones.
Fabricacin
Valor (costo).
Eleccin de un lenguaje
La decisin ms importante que se debe tomar al disear un sistema grande
de software, es la de tomar en consideracin el lenguaje de software que se
va a utilizar en la aplicacin del sistema. Un anlisis inapropiado, puede
ocasionar dificultades posteriores y aumentar el costo previamente planeado.
151
Este problema puede desaparecer si se selecciona el lenguaje de

programacin ms apropiado para la solucin y la infraestructura fsica
existente.
Una buena eleccin de un lenguaje es importante porque reduce al mnimo
las dificultades de codificar el diseo, reduce la cantidad de pruebas
necesarias haciendo el programa ms legible y ms fcil de mantener.
La aplicacin del sistema debe ser fcil de mantener, por lo tanto esto implica
que debe codificarse en un lenguaje de alto nivel que proporcione la
posibilidad de construir un sistema como varios mdulos autnomos
cooperativos.
Entre los criterios que se aplican para la evaluacin de lenguajes disponibles
estn:
1. Los requisitos del cliente del sistema. La persona que contrata el
sistema puede especificar que se utilice determinado lenguaje y se
debe respetar, el lder del proyecto es el encargado de decidir cual es
el lenguaje ms apropiado para realizar el sistema.
2. Disponibilidades de compiladores del lenguaje. Si se realiza una
aplicacin por medio de la configuracin de un sistema operativo o un
hardware en particular, se debe disponer de un traductor del lenguaje
eficiente para aplicarlo.
3. Disponibilidad de instrumentos de software para apoyar el
desarrollo
de
los
programas.
Instrumentos
de
software,
construcciones de referencia cruzada, sistemas para control de

cdigo, y analizadores de flujo de ejecucin, son importantes en el
152
apoyo del proceso de programacin, ya que facilitan la aplicacin y

confirmacin del sistema.
4. Conocimiento del personal de programacin existente. Aunque no
es una dificultad para un desarrollador aprender un nuevo lenguaje, se
necesita adquirir prctica en algn lenguaje antes de adquirir una
verdadera competencia.
5. Lenguajes de programacin utilizados en proyectos previos. Esto
se utiliza cuando los desarrolladores han trabajado con un lenguaje en
proyectos anteriores y estn familiarizados con l.
6. Necesidad de transportar el software. Si esta orientado el software
a una sola configuracin de hardware y tiene un tiempo de vida
limitado, los aspectos de su transporte no son limitados. Si el sistema
esta destinado a operar en maquinas distintas es necesario un
lenguaje de programacin capaz de crear programas porttiles.
7. La aplicacin que se est programando. Influye en gran medida
respecto al lenguaje que se utilizar.
Lenguaje de programacin e ingeniera de software
Independientemente de la metodologa de desarrollo de software, el lenguaje
de programacin tendr impacto en la planificacin, el anlisis, el diseo, la
codificacin, la prueba y el mantenimiento.
La calidad del resultado final se encuentra ms fuertemente unida a las
actividades de ingeniera de software que preceden y sigue a la codificacin.
Para la seleccin del lenguaje se debe tener en cuenta cuales son las causas
153
principales que generan el problema, por ejemplo si la causa ms grande es

la velocidad con que se muestran los datos pero el cliente quiere que el
sistema utilice demasiados grficos, se debe seleccionar el lenguaje que
garantice la velocidad antes que los grficos, un segundo proyecto es como
hacer que los grficos alcancen los niveles de velocidad exigido, tarea
realizada con la planeacin multigeneralicional de proyectos .
52
Luego de la seleccin del software, se debe realizar la evaluacin del

hardware. El analista de sistemas necesita trabajar junto con el lder del
proyecto para determinar que hardware ser necesario. En el momento de
adquirir el nuevo hardware, es importante tener conocimiento del inventario
con el que se cuenta actualmente, y si no se dispone de uno, el analista
necesita realizar uno rpidamente y apoyarse en l.
6.8
Despus de aplicar los principios del anlisis, e independientemente de la

metodologa de desarrollo de software que se aplique, se construye un
modelo de software llamado prototipo que ser valorado por el cliente y el
desarrollador.
La principal aplicacin de los prototipos de un sistema es
ayudar tanto a los clientes como a los desarrolladores a entender los

requisitos del sistema y de esta forma verificar que se esta haciendo lo que el
cliente quiere. Tambin puede ser usado para entrenar al cliente antes que
el sistema final sea entregado.
Los beneficios de desarrollar un prototipo son:
52
Planeacin multigeneralicional de proyectos, en ingls, multigeneration project

management plan.
154
1. Identificar los malentendidos entre los desarrolladores y el cliente,

mientras se demuestran las funciones del sistema.
2. Detectar a tiempo los servicios del usuario que hagan falta.
3. Identificar y mejorar los servicios que sean difciles de usar o confusos
para el cliente.
4. Identificar
completar
los
requisitos
que
estn
incompletos
inconsistentes.
5. Servir de base para escribir una especificacin de sistema de calidad.
Pueden darse dos enfoques al momento de crear un prototipo, cerrado o
abierto. El enfoque de prototipo cerrado se denomina a menudo prototipo
desechable y sirve nicamente como una demostracin de los requisitos. Un
enfoque de prototipo abierto se denomina prototipo evolutivo, y se emplea
como una primera parte de una actividad de diseo a la que le sigue la
construccin.
Antes de poder elegir un enfoque abierto o cerrado, es necesario determinar
si se puede crear un prototipo del sistema a construir.
A la hora de
determinar esto, es necesario tener en cuenta los siguientes aspectos: rea

de aplicacin, complejidad, caractersticas del cliente y del proyecto. Si una
aplicacin candidata con las caractersticas anteriormente mencionadas
requiere el desarrollo de miles de lneas de cdigo antes de poder realizar
cualquier funcin demostrable, es muy probable que sea demasiado
compleja para realizar un prototipo.
Para que la creacin del prototipo de software sea efectiva, se debe
desarrollar rpidamente, de tal forma que el cliente pueda valorar los
resultados y recomendar cambios a tiempo.
Existen tres mtodos y
herramientas para la creacin de prototipos rpidos:
155
6.8.1 Tcnicas de cuarta generacin.

Estas tcnicas de cuarta generacin (4GT ) comprenden una amplia gama
53
de lenguajes de consulta e informes de bases de datos, generadores de

programas, aplicaciones y de otros lenguajes no procedimentales de muy
alto nivel. Como las tcnicas 4GT permiten al desarrollador generar cdigo
ejecutable rpidamente, son ideales para la creacin rpida de prototipos.
6.8.2 Componentes de Software Reutilizable.

Otro enfoque para crear componentes es ensamblar, ms que construir,
mediante un conjunto de componentes software existentes. Un componente
software puede ser una estructura de datos (o una base de datos) o un
componente arquitectnico de software (un programa) o un componente
procedimental (un mdulo).
En todos los casos se debe disear el
componente software de manera que permita ser reutilizado sin un

conocimiento detallado de su funcionalidad.
6.8.3 Especificaciones formales y entornos para prototipos.
Los desarrolladores de los lenguajes de especificacin, estn desarrollando

entornos interactivos que permitan al analista crear una especificacin
basada en lenguaje de un sistema o software
y adems invoquen
herramientas automticas que traducen la especificacin
basada en el
lenguaje en cdigo ejecutable y permitan al cliente usar el cdigo ejecutable

del prototipo para refinar los requisitos formales.
53
4GT: fourth generation tecniques
156
Establecer los
objetivos del
proyecto
Definir la
funcionalidad del
prototipo
Desarrollar el
prototipo
Evaluar el prototipo
Plan del
Prototipo
Resultado de la
definicin
Prototipo
Ejecutable
Reporte de la
Evaluacin
Figura 41. Proceso de prototipos.
6.9
Las pruebas del software son elementos crticos para la garanta de la

calidad del software y se presenta como una revisin final de las
especificaciones, del diseo y de la codificacin.
Segn Glen Myers , la prueba tiene como objetivo los siguientes tres puntos:
54
La prueba es un proceso de ejecucin de un programa con la

intencin de descubrir un error.
Un buen caso de prueba es aquel que tiene una alta probabilidad de

mostrar un error no descubierto hasta entonces.
Una prueba tiene xito si descubre un error no detectado hasta

entonces.
El cambio de paradigma que se plantea en estos objetivos, busca disear

pruebas para descubrir errores y no para ignorarlos.
Por otro lado, las
pruebas son uno de los factores fundamentales para medir la calidad del
software producido. Aunque si se tiene en cuenta que La prueba no puede
54
The Art of Software Testing, Wiley, 1979
157
asegurar la ausencia de defectos, solo puede demostrar que existen defectos

en el software , el equipo de trabajo estar ms dispuesto a considerar
55
diferentes aspectos que pueden generar errores.

Se deben tener en cuenta los siguientes aspectos:
Hacer un seguimiento de las pruebas hasta los requisitos del cliente.
Plantear y disear las pruebas antes de generar el cdigo.
El 80% de todos los errores se centran en slo en el 20% de los mdulos.
Empezar las pruebas en mdulos individuales y avanzar hasta probar el

sistema entero.
Casos de prueba
El diseo de pruebas requiere de tanto conocimiento como el diseo del
sistema en general.
En muchas ocasiones es recomendado que los
diseadores de las pruebas, sean personas diferentes a los desarrolladores

del sistema; ya que al no encontrarse involucrados en el proyecto, disearan
pruebas que midan cualquier aspecto del software.
Los casos de prueba se pueden clasificar en tres partes, una parte
procedimental denominada prueba de caja blanca, otra parte funcional
operativa conocida como prueba de caja negra, y una tercera llamada prueba
de entornos y aplicaciones especializadas.
55
Ingeniera del Software, Roger S. PRESSMAN, Un Enfoque Prctico.
158
6.9.1 Prueba de Caja Blanca.
Evala que se hayan cumplido los requerimientos de los usuarios,

enfocndose en la parte procedimental. Los casos de prueba dan como
resultado los siguientes cuatro puntos:
1. Casos de prueba que garanticen la utilizacin de por lo menos una vez
todos los caminos independientes de cada mdulo.
2. Se ejerciten todas las decisiones lgicas en sus vertientes verdadera y
falsa.
3. Se ejecuten todos los bucles en sus lmites y con sus lmites
operacionales.
4. Se ejerciten las estructuras internas de datos para asegurar su validez.
Las justificaciones del porque de las pruebas de caja blanca son basadas en
los estndares de la IEEE
56
Los errores lgicos y las suposiciones incorrectas son inversamente

proporcionales a la probabilidad de que se ejecute un camino del
programa.
A menudo creemos que un camino lgico tiene pocas posibilidades de

ejecutarse cuando, de hecho, se puede ejecutar de forma normal.
Los errores tipogrficos son aleatorios.
6.9.2 Prueba de Caja Negra.
Se enfoca en toda la parte funcional del software. A Diferencia de la prueba

de la prueba de caja blanca, la prueba de caja negra busca errores en las
56
JONES, T.C. Programming Productivity: Issues for the 80s, IEEE Computer Society Press,
1981.
159
funciones, en la interfaz, las estructuras de datos o en accesos a bases de

datos externas, rendimiento, e inicializacin o terminacin.
Las pruebas de Caja Negra se disean para responder las siguientes
preguntas:
1. Cmo se prueba la validez funcional?
2. Qu clases de entrada compondrn unos buenos casos de prueba?
3. Es el sistema particularmente sensible a ciertos valores de entrada?
4. De qu forma estn aislados los lmites de una clase de datos?
5. Qu volmenes y niveles de datos tolerar el sistema?
6. Qu efectos sobre la operacin del sistema tendrn combinaciones
especificas de datos?
6.9.3 Prueba de Entornos y Aplicaciones especializadas.
Otras pruebas de importancia para la satisfaccin del cliente an ms

especializadas que las de caja blanca y caja negra son:
Prueba de interfaces grficas de usuario.
Ventanas.
Mens emergentes.
Operantes con el ratn.
Entrada de datos.
Prueba de arquitectura Cliente/Servidor.
Prueba de documentacin y de ayuda.
Prueba de sistemas de tiempo real.
160
6.10 REVISAR
QUE
LOS
PROTOTIPOS
CUMPLAN
CON
LOS
REQUERIMIENTOS
Estas revisiones, lideradas por los Black Belts, sirven de filtro en el proceso
de desarrollo, con el fin de detectar defectos para que puedan ser eliminados
a tiempo y se pueda mejorar la calidad del software. Para llevar a cabo estas
revisiones, se debe dedicar tiempo y esfuerzo por parte de todos los
miembros del equipo.
161
7. FASE DE DESARROLLAR
La fase de desarrollo es la quinta fase en el modelo DMADDV. Esta fase se

centra en el Cmo,
es decir, cmo se implementa la funcin como una
arquitectura del software, cmo han de implementarse los detalles

procedimentales, cmo han de caracterizarse las interfaces y cmo ha de
traducirse el diseo en un lenguaje de programacin.
En la fase de desarrollo se implementa el sistema, es decir, se crea el cdigo
correspondiente al resultado de la fase de diseo, siguiendo los patrones y la
arquitectura escogida. Uno de los puntos importantes a controlar en esta
etapa consiste en la coordinacin del equipo de desarrolladores del proyecto.
Los pasos que guiarn la fase de desarrollo son los siguientes:
1.
Organizacin del cdigo fuente.
2.
Construccin.
3.
Revisar que se satisficieron los requerimientos.
4.
Documentacin del cdigo.
5.
Disear el plan de implantacin.
6.
Ejecutar el plan de implantacin.
162
7.1
ORGANIZACIN DEL CDIGO FUENTE
La organizacin de los archivos que contienen el cdigo fuente son

guardados utilizando una jerarqua establecida;
aunque este paso es
ignorado por muchos equipos de trabajo, es una tarea que convertir al

proyecto en un trabajo organizado, en el presente y en el futuro.
La organizacin del cdigo fuente es independiente en cada proyecto, es
recomendado tener en cuenta lo siguientes aspectos:
Nombre de archivo: dar un nombre que al leerlo se entienda lo que
contiene.
Grupos o Subgrupos:
clasificar en grupos o clases los archivos
dependiendo de su objetivo o similitud, dividindolo las veces sea

necesario hasta alcanzar un nivel de alto entendimiento.
Grficas: las grficas utilizadas se deben almacenar en una carpeta
diferente.
7.1.1 rbol Jerrquico.
Un rbol jerrquico es la representacin lgica de datos o archivos como se

observa en la figura 42. Se grafica en forma inversa, la raz se encuentra
arriba y las hojas se despliegan hacia abajo. El smbolo / representa la
raz del directorio donde se encuentran los archivos, A, B son los dos grupos
grandes de clases que existen, C es una subclase de A, en tanto que D, E, F,
G, H, I, J representan los archivos.
163
Figura 42. Estructura de un rbol jerrquico.

Despus de definirse el rbol jerrquico de los archivos del cdigo fuente, se
debe entregar a cada uno de los miembros del equipo una copia impresa y
realizar una breve explicacin para evitar posibles confusiones.
De acuerdo con el rbol definido, se utilizan dos tipos de enlaces entre los
archivos, los enlaces relativos o absolutos, siendo los ms utilizados en
proyectos que utilizan tecnologas de hipertexto.
7.1.2 Enlaces Absolutos.
Son aquellos enlaces que contienen la direccin absoluta de un archivo

desde el directorio raz hasta el archivo. Por ejemplo, utilizando la figura 42, y
asumiendo que cada archivo son pginas jsp, se desea encontrar el archivo
J.
http://www.raiz.com/A/C/J.jsp
164
7.1.3 Enlaces Relativos.
Son aquellos enlaces que contienen la direccin del archivo desde donde se
encuentra ubicado hasta el archivo deseado. Para el ejemplo de la figura 42,
ir de H -> D
../D.jsp
7.2
CONSTRUCCIN
Esta actividad incluye la codificacin e integracin de los mdulos con

tcnicas de programacin estructurada cumpliendo con los lineamientos
especificados en la etapa del diseo.
La escritura del cdigo debe ser sencilla, casi mecnica, debido a que se han
tomado todas las decisiones durante el transcurso del proyecto.
Una vez generado el cdigo fuente, la funcin de un mdulo debe ser clara
sin necesidad de referirse a ningn diseo, el cdigo debe ser comprensible,
es decir, debe mezclarse la simplicidad con la claridad.
Entre los elementos de estilo se encuentran la documentacin interna (a nivel
cdigo fuente), los mtodos de declaracin de datos, enfoque de
construccin de sentencias y las tcnicas de entrada y salida.
165
7.3
REVISAR QUE SE SATISFACIERON LOS REQUERIMIENTOS
La revisin es conducida por el lder del proyecto y sirve de filtro en el

proceso de desarrollo, con el fin de identificar defectos en el desarrollo para
que puedan ser eliminados a tiempo y se pueda mejorar la calidad del
software.
Para llevar a cabo las revisiones, se debe dedicar tiempo y
esfuerzo por parte de todos los miembros del equipo.

Otro tipo de documentos pueden ser utilizados de apoyo en la reunin de
revisin, como por ejemplo:
Definicin del problema.
Los requerimientos de los clientes (CTQs).
Determinar que medir.
QFD.
AMFE.
7.4
DOCUMENTACIN DEL CDIGO
Este paso es propuesto para asegurar que el cdigo si ser documentado,

debido a que la documentacin permite a los desarrolladores comunicarse
con otros, adems tambin proporciona una clara gua de comprensin
durante la ltima fase del proyecto (Validar).
Aunque el formato ya ha sido establecido en el paso de diseo de formato de
documentacin de programas, en la fase diseo, se deben tener en cuenta
algunas caractersticas que se mencionan a continuacin:
166
7.4.1 Legibilidad.
Es el primer aspecto que se debe tener en cuenta, para identificar variables y

etiquetas. Aunque algunos lenguajes de programacin limitan la longitud de
los nombres de las variables o de las etiquetas a pocos caracteres, se debe
buscar la mayor comprensin posible. Por ejemplo:
D = (H_D_C * V_H_N) + (H_D_D * V_H_D)
DEU = (HORS_D_NOC * VAL_HOR_NOC) + (HORS_D_DIA *
VAL_HOR_DIA)
DEUDA = (HORAS DE DEMORA NOCHE * VALOR HORA NOCHE
DEMORA) + (HORAS DE DEMORA DIA * VALOR HORA DIA
DEMORA)
7.4.2 Ubicacin de comentarios.
La ubicacin se debe hacer de cierta forma que no ahogue el cdigo pero

tampoco lo ignore. Existen dos categoras, de prlogo y de descripcin que
poseen diferencias notables.
Los comentarios de prlogo se escriben al principio de cada mdulo,
indicando el propsito de la funcin del mdulo o una explicacin de los
datos pertinentes como variables importantes, su uso, las restricciones y
limitaciones.
Los comentarios descriptivos se incluyen en el cuerpo del cdigo fuente y se
usan para
describir las funciones del procesamiento, proporcionando
conocimiento extra que ofrezca un mayor entendimiento para los lectores

167
Adems los comentarios descriptivos deben:

Describir los bloques de cdigo en vez de describir cada lnea.
Usar lneas en blanco o tabulaciones de forma que sean fcilmente
distinguibles del cdigo.
Que sean correctos, un comentario incorrecto o que se pueda interpretar
mal es peor que no ponerlo.
En Conclusin, la documentacin de cdigo fuente es una tarea que debe
ser realizada. En su desarrollo surgen ciertas preguntas que el grupo debe
resolver para un mejor trabajo en equipo como por ejemplo:
Cuntos comentarios son suficientes?
Dnde se deben situarse los comentarios?
Son los comentarios no mantenibles, y por lo tanto, no fiables?
7.5
DISEAR EL PLAN DE IMPLANTACIN
La implantacin del sistema es uno de los ltimos pasos de la metodologa

con gran importancia, por lo tanto se necesita de una planeacin previa, ya
que en la mayora de los proyectos este paso se convierte en el ms difcil de
efectuar.
La complejidad de este paso depende directamente de la tecnologa que se
utiliz en el proyecto; si es un producto estndar ser relativamente fcil y la
familiarizacin con los usuarios pueda ser ms rpida. Sin embargo, cuando
la tecnologa es nueva y las interfaces grficas cambian notablemente, se
debe tener demasiada precaucin y una buena planeacin para que el
proyecto no falle al final.
168
La estrategia a escoger para la implantacin es responsabilidad del lder del

proyecto, los aspectos que se deben incluir son los siguientes:
Descripcin del ambiente (Servidores, Computadores, Bases de
Datos, interfaces, etc.)
Descripcin de los datos necesitados.
Programacin de las fechas en que se realizar.
o Fines de semana?
o Ultima semana del mes?
o Horas nocturnas?
o Fecha definitiva de implantacin completa.
Orden de los pasos a seguir.
Las dos estrategias ms conocidas para la implantacin de proyectos de
software son:
7.5.1 Corte-Rpido.
Busca una migracin completa del sistema viejo al sistema nuevo.
Reemplazo Inmediato.
Es el ms rpido.
Necesita un plan de reserva.
Requiere de una fuerte planeacin y pruebas.
Operacin en Paralelo.
Disminuye los riesgos.
El corte ocurre cuando el sistema nuevo esta completamente
migrado.
169
7.5.2 Etapas.
Se implanta el sistema nuevo por etapas, de una en una, hasta completar el

sistema. La etapa nueva que se implanta sustituye el funcionamiento de la
vieja.
7.6
EJECUTAR EL PLAN DE IMPLANTACIN
La ejecucin del plan de implantacin, se puede realizar antes o despus del

paso de pruebas de la fase validar, segn como el proyecto lo requiera. El
paso de revisar que se satisficieron los requerimientos puede ser utilizado
como prueba, para dar inicio a la implantacin.
La estrategia de implantacin escogida, debe ser entendible por el lder del
proyecto para su ejecucin. Los pasos a seguir marcarn el desenlace del
proyecto.
Conferir la responsabilidad de la implantacin a un comit tcnico y a
uno administrativo.
Recibir formalmente la versin definitiva del sistema.
Armar y desplegar el sistema segn se requiera.
Seguir el orden de pasos programados en el plan.
Al terminar con la totalidad de los pasos programados para la implantacin,

se debe informar al lder del proyecto para proceder con la siguiente fase del
proyecto.
170
8. FASE VALIDAR
En esta fase principalmente se validar el proyecto en su totalidad, el diseo,

los procesos tratados adems de establecer los controles que se deban tener
para esos procesos, pero sobretodo verificar que se hayan cumplido las
CTQs y que la ecuacin Y = F(X) no contenga las variables que se han
atacado durante todo el proyecto.
Los pasos que definen el desarrollo de esta fase son los siguientes:
8.1
1.
Ejecutar el plan de pruebas.
2.
Capacitar al personal.
3.
Determinar los riesgos.
4.
Entregar la documentacin final.
5.
Crear mecanismos de administracin.
6.
Evaluar los beneficios alcanzados.
7.
Documentar las lecciones aprendidas.
8.
Comunicar al equipo los resultados obtenidos.
9.
Cierre del proyecto.
EJECUTAR EL PLAN DE PRUEBAS.
Este paso se realiza para culminar el plan de pruebas diseado con

anterioridad, y presentar los resultados al lder del equipo, los cuales deben
ser manejados sistemticamente. Las construcciones que posean defectos
deben ser probadas nuevamente y posiblemente regresadas a la fase de
diseo o construccin.
171
Como ayuda para guiar las pruebas se utilizan muchos de los casos de uso
implementados para definir los requerimientos de los clientes, los cuales se
convertiran en casos de prueba. El modelo de pruebas cambia
constantemente debido a ciertos factores como:
La eliminacin de casos de uso. En la mayora de los casos sucede
esto por que el cliente no fue claro en la explicacin. Otra posibilidad
es que el proceso se haya cambiado durante el desarrollo del
proyecto.
El refinamiento de algunos casos de uso. Son adherencias que se les
hacen a los casos de uso durante el transcurso del proyecto.
Creacin de nuevos casos de uso.
Para una mejor planeacin del plan de pruebas, se recomienda asignarlas al
equipo de trabajo, dependiendo de su tipo. Los diferentes tipos de pruebas
57
que se pueden realizar se muestran en la tabla 18 .

En la tabla 19 se propone una forma de registrar los resultados de las
pruebas para presentar al lder del proyecto.
57
Tabla 19: Tipos de Prueba: Tomado del libro SIX SIGMA SOFTWARE DEVELOPMENT, Pg.
165.
172
Tabla 18. Tipos de Pruebas.
173
Tabla 19. Registro de Pruebas
174
La aceptacin de las pruebas por el lder del proyecto es la ultima parte de

este punto, en este momento el equipo debe estar completamente
convencido de que el sistema corre correctamente bajo condiciones
normales y extremas. Y que se hayan encontrado todos los requerimientos
definidos por los clientes. La ultima prueba es realizada por clientes despus
de que el proyecto se encuentre en marcha y es que la documentacin
entregada a cada cliente este acorde con lo explicado en las capacitaciones.
8.2
CAPACITAR AL CLIENTE.
Capacitar al cliente es uno de los pasos ms importante de la fase validar y

uno de los ms importantes de todo el modelo DMADDV de Seis Sigma. Es
el momento en que el cliente compara sus expectativas sobre el proyecto
con lo que esta siendo entregado, y determinan si fueron superadas o
frustradas.
La capacitacin se debe enfocar en los aspectos que son ms relevantes
para cierto grupo de clientes, con el fin de no invertir tiempo en aspectos que
nunca se utilizarn.
La forma de capacitacin que se utilice debe ser aprobada por el lder del
proyecto y se debe ajustar al presupuesto. Tambin es recomendable tener
en cuenta el nivel de conocimiento de los clientes, por citar un ejemplo, no es
recomendable utilizar una forma de capacitacin basada en Web si los
participantes han tenido un mnimo contacto con Internet. Las formas ms
comunes de realizar las capacitaciones son:
175
Tabla 20. Formas de Capacitacin.

Formas de Capacitacin
Tipo
Descripcin
Presentacin
con videobeam
Uno a uno
Realizar una presentacin con

diapositivas de power-point, flash,
etc.
El gua va puesto por puesto de
cada cliente explicando paso por
paso el sistema
Se programan clases con el grupo
seleccionado.
Se crea un Web site con un
manual mas descriptivo (grficos,
ejemplos dinmicos, etc.).
Clase.
Portal
Bajo.
Tiempo
de
preparacin
1 2 das.
Tiempo
de
ejecucin
12
horas.
Medio
1 2 das
Meses
Alto.
1 semana.
Mes.
1 Mes.
Indefinido
Costo
MedioAlto.
Es conveniente realizar una encuesta acerca del nivel de satisfaccin

despus de efectuada la capacitacin. Aunque resultado sea satisfactorio,
esto no significa que el cliente haya retenido toda la informacin o que haya
entendido todos los procedimientos del producto. En la tabla 21 se observa
un ejemplo de encuesta que puede ser utilizado, la agregacin o eliminacin
de preguntas es de acuerdo si el proyecto lo requiera.
Tabla 21. Encuesta de Capacitacin.
Encuesta de Capacitacin
Ubicacin:
Instructor:
Cliente: (opcional)
Fecha:
Las siguientes preguntas son realizadas para medir el nivel de satisfaccin del
producto entregado, y la capacitacin realizada.
La calificacin se realiza de 1 a 5, en donde 5 es el nivel mas alto de satisfaccin y 1
el nivel mas bajo
Sistema
Tiempos de respuesta.
Integridad en los resultados.
Integracin con otros sistemas.
1
1
1
2
2
2
3
3
3
4
4
4
5
5
5
Interfaz grafica
Amigable.
Entendible.
1
1
2
2
3
3
4
4
5
5
176
Requerimientos
Requerimientos encontrados.
Optimizacin de procedimientos.
Reportes tiles.
1
1
1
2
2
2
3
3
3
4
4
4
5
5
5
Capacitacin
Material utilizado
Conocimiento del Instructor
Habilidades del Instructor
1
1
1
2
2
2
3
3
3
4
4
4
5
5
5
En la mayora de los casos durante las capacitaciones los clientes identifican

nuevos requerimientos para el sistema,
o identifican ms usos que el
sistema podra tener y que pueden ofrecer un gran valor agregado al trabajo
diario. Todos los comentarios realizados por los clientes deben ser tenidos
en cuenta y ser registrados por el lder del proyecto, para una nueva versin
del sistema.
8.3
DETERMINAR LOS RIESGOS
El riesgo que se maneja en este paso, es aquel que puede llegar a existir
despus de implantar el producto para uso de los clientes. La Administracin
de los riesgos en esta fase se puede hacer de la misma forma que fueron
manejados los riesgos que puede existir durante el transcurso del proyecto,
identificados en la fase Definir.
177
Identificacin del Riesgo

Definicin del Riesgo
Administracin de
Riesgo
Anlisis del Riesgo

Prioritizacin del Riesgo
Planeacin
Control de Riesgo
Resolucin del Riesgo

Monitoreo
Figura 43. Administracin del Riesgo.

Los tipos de riesgos que se pueden presentar son de tres categoras
principalmente, riesgos del negocio, operacionales y tcnicos. Sin importar
cual sea su tipo, el trato debe ser el mismo para cada uno y debe ser
comunicado al responsable del sistema en el momento ms oportuno. Para
establecer los posibles riesgos utilizamos el mtodo de lluvia de ideas
utilizado en la fase definir tambin.
8.4
DOCUMENTACIN DEL PROYECTO
La documentacin es parte fundamental durante todo el desarrollo del

proyecto.
Ayuda principalmente a definir, planear, organizar, controlar y
cerrar el proyecto. Aunque el exceso de documentacin puede generar en

algunos casos problemas, sta se hace o no tan compleja dependiendo del
tamao y la importancia del proyecto.
Una buena documentacin es una excelente herramienta de comunicacin,
as como tambin es una herramienta para analizar y guiar las revisiones del
proyecto.
178
La documentacin incluye los documentos que se han completado durante

todo el desarrollo del proyecto, como son:
Diagramas de Flujo.
Cuadros de Proyecto.
Plan de Proyecto.
Documentos Tcnicos (documentacin del software, especificacin de

requisitos).
Tambin incluye la documentacin especfica del cierre del proyecto, tales

como:
8.4.1 Manuales del proyecto.
Es un libro esencial de referencia para tener cierta informacin disponible

fcilmente. Sin embargo, ms que proporcionar a sus lectores informacin
til, es tambin una herramienta de comunicacin que le permite a la gente
actuar eficientemente y efectivamente.
Para generar el manual de proyecto, es til realizar los siguientes pasos:
1. Determinar el contenido, para sto se pueden entrevistar a los miembros
del equipo.
2. Organizar el contenido, se puede realizar ya sea por tpicos o fases.
3. Determinar el nmero de copias, usando el nmero de los miembros del
equipo como base.
4. Asignar responsabilidades para el mantenimiento del manual.
5. Publicar y distribuir el manual.
6. Retroalimentacin por parte de los usuarios del manual.
179
8.4.2 Libro del proyecto.
El libro del Proyecto, es como un historial de archivos y se encarga

principalmente de almacenar informacin.
Adems de la informacin de
carcter administrativo, contiene informacin de la compaa y sus polticas,

procedimientos especficos del proyecto y la documentacin tcnica.
Al igual que para el manual del proyecto, es til seguir los siguientes pasos
para desarrollar el libro del proyecto:
1. Identificar el contenido.
2. Determinar la organizacin del contenido.
3. Controlar el retiro de los documentos, proporcionando una hoja de
registro.
4. Determinar la localizacin de la biblioteca, proporcionando un sitio
fcilmente accesible;
tambin se determinan los procedimientos para
tener acceso al material.
8.5
CREAR LOS MECANISMOS DE ADMINISTRACIN.
Una vez finalizado el proyecto, se deben tener en cuenta ciertos aspectos

con el fin de administrar mejor el proyecto.
Formacin: es preciso aprender como funciona este nuevo proceso y evitar
los paradigmas del cambio para as romper con los hbitos antiguos.
Documentacin: Se debe tener clara y documentada la forma en que se
deben hacer las cosas y si es posible, disponer de las respuestas a las
preguntas ms frecuentes.
180
Solucin de Problemas: Es conveniente dejar claras las responsabilidades

respecto a quien o quienes se encargarn de tratar los aspectos que surjan.
Gestin del rendimiento: Mantener los ojos abiertos hacia la necesidad y
oportunidad de revisar las descripciones de puestos de trabajo, incentivos y
criterios de revisin del rendimiento.
Medidas: Se deben documentar siempre los resultados.
8.6
EVALUAR LOS BENEFICIOS ALCANZADOS
En la fase inicial del proyecto, se describi la forma de llevar a cabo el

anlisis de costo y beneficio.
Es en este paso, donde se verificar que los
beneficios planteados se han alcanzado.

Para llevar a cabo este paso, existen diferentes mecanismos, en la mayora
de los proyectos los Black Belts deciden utilizar los mismos mecanismos
utilizados en la fase medir.
Primero volver a capturar los datos de la misma manera que en la fase dos,
realizarles las mismas medidas y grficos y observar si se alcanz la meta
propuesta.
Segundo, volver a capturar la voz del cliente, para dar fin al proyecto o
plantear mejoras para alcanzar la satisfaccin total del cliente.
El reporte de este paso es el primer reporte que el comit desea ver al
presentar esta fase.
181
8.7
DOCUMENTAR LAS LECCIONES APRENDIDAS
Las lecciones aprendidas durante todo el proceso son en definitiva la salida

final y se obtienen nicamente con el trabajo de solucionar problemas de la
vida real.
Su nico propsito es documentar los logros y las fallas del
proyecto, para evitar que se cometan los mismos errores en proyectos

siguientes. Por ejemplo, las lecciones aprendidas documentan las razones
del porque se han tomado ciertas acciones correctivas, o las causas de las
variaciones del funcionamiento, la ocurrencia de riesgos no planeados,
errores que sucedieron y que pudieron ser evitados, entre otros.
Desafortunadamente, los proyectos pueden fallar. Tambin hay cosas que
se pueden aprender de los proyectos que fallan, as como de los proyectos
exitosos, y es precisamente esta informacin la que sirve de referencia en el
futuro.
Se debe tener en cuenta que aprender de las lecciones es una
excelente oportunidad para obtener beneficios a todos los asociados en el

proyecto.
Las lecciones aprendidas se deben implementar de las siguientes formas:
8.7.1 Secciones de lecciones aprendidas.
Adems de comunicar el cierre del proyecto por escrito, es recomendable un

mecanismo para revisin en grupo. Las secciones de lecciones aprendidas
son una serie de reuniones en las que participan todo el equipo de trabajo,
los directores y los dueos del proyecto.
Para que estas secciones sean exitosas, todos los problemas encontrados
por el equipo de trabajo deben ser presentados abiertamente.
problemas que son encontrados deben priorizarse.
182
Aquellos
No es necesario
documentar todo pequeo detalle que sucede, sin embargo las cosas
importantes se deben discutir sea por solicitud de los clientes o los directores
del proyecto.
8.7.2 Formato de las lecciones aprendidas.
Existen numerosos formatos para documentar las lecciones aprendidas.

Generalmente, cada leccin aprendida debe ser documentada en una sola
pgina y debe contener principalmente: en el encabezado el nombre del
proyecto, la fecha y el punto de contacto para la leccin aprendida.
El
cuerpo debe describir la leccin aprendida de la siguiente forma:
Declaracin del problema: Se debe describir el problema que ocurri y

proporcionar informacin suficiente para establecer que fue lo que
sucedi.
Discusin: Describir en detalle la causa y el impacto del problema.
Referencias: Proporcionar las referencias usadas o cualquier fuente de

informacin que pueda ser til para entender el problema y tomar las
acciones correctivas.
Acciones correctivas:
Identificar cuales acciones correctivas fueron
tomadas y discutir los resultados.
8.8
COMUNICAR AL EQUIPO DE TRABAJO LOS RESULTADOS

OBTENIDOS
La organizacin debe creer firmemente en la importancia de reconocer el

resultado que el equipo alcanz. Esta es la oportunidad para celebrar y
reconocer oficialmente los esfuerzos y agradecer por su participacin. Una
celebracin ayuda a los miembros del equipo a reconocer formalmente que
el proyecto ha finalizado y se da por cerrado el trabajo que ellos han hecho.
183
Adems, los anima a recordar lo que aprendieron durante el desarrollo del

mismo y sobre las experiencias que pueden considerar beneficiosas tanto a
ellos como a la organizacin en los proyectos siguientes.
8.9
CIERRE DEL PROYECTO
El cierre del proyecto es la ltima fase dentro del ciclo de vida del proyecto y
es uno de los pasos ms importantes durante todo el desarrollo del mismo.
Comienza una vez el director del proyecto concluya que se alcanzaron los
objetivos planteados y el cliente y los usuarios aceptan los resultados
entregados. El cierre del proyecto es importante, pues toda la informacin
del proyecto se recoge en este paso y es la que servir de referencia en un
futuro. La documentacin recogida durante el cierre del proyecto puede ser
reutilizada por otros proyectos para prevenir problemas en el futuro.
Tambin se ejecuta el cierre del contrato y la aceptacin formal y aprobacin
por parte de los dueos del proyecto.
184
9. FASE DEFINIR
9.1
El proyecto Consulta del catlogo Bibliogrfico va Web se enmarca dentro

del contexto de la Biblioteca de la Universidad Industrial de Santander.
Para entender mejor el modelo del negocio con el que se va a interactuar, es
necesario conocer la misin, visin y objetivos de la Biblioteca.
MISIN
Ser un centro integral de informacin capaz de satisfacer y anticiparse a
las necesidades de documentacin de la comunidad universitaria,
acadmica e investigativa a nivel regional, nacional e internacional,
mediante la prestacin de servicios de adquisicin, procesamiento,
recuperacin y diseminacin de informacin con criterios de calidad.
Para ello se apoya en la utilizacin de tecnologa moderna y talento
humano idneo, constituyndose de esta forma en lder del desarrollo y
promocin de actividades intelectuales que estimulen procesos de
enseanza y de aprendizaje
185
VISION
La Biblioteca de la Universidad Industrial de Santander sera un sistema
conectado a la red mundial de informacin, mediante una infraestructura
digital que permita nuevas formas de conocimiento que contribuyan a la
formacin integral de los usuarios. As mismo, se espera lograr un
posicionamiento local, regional e internacional para ofrecer servicios
abiertos, dinmicos y oportunos, como soporte principal a la academia e
investigacin. El concurso de un equipo humano interdisciplinario,
competente y comprometido con la institucin, adems de la utilizacin
de una metodologa innovadora, sern factores vitales para lograr un
ambiente adecuado y garantizar la calidad de sus servicios
OBJETIVOS
o Ofrecer servicios de informacin con criterios de calidad para
satisfacer las necesidades de los usuarios.
o Apoyar la docencia, la investigacin y la extensin a travs del
suministro
de
informacin
oportuna,
utilizando
tecnologas
apropiadas que estimulen procesos de enseanza y aprendizaje.

o Generar las condiciones adecuadas que permiten el manejo de la
informacin acorde con los avances del siglo XXI.
o Generar en los usuarios de la biblioteca una cultura de lectura.
o Apoyar la poltica de regionalizacin de la universidad, en lo
relacionado con las unidades de informacin
Segn esto, se defini que la Biblioteca de la UIS, en funcin de esa misin,

visin y objetivos, encamina todos sus esfuerzos en la iniciativa de prestar un
mejor servicio a todos los usuarios.
Y = Mejoramiento de servicios
186
Los servicios que ofrece la biblioteca a sus usuarios en general, son los que
se mencionan a continuacin:
Acceso y consulta a las colecciones.
Catalogo de consulta en lnea.
Consulta de base de datos.
Consulta de videos, audio-cassettes y microformas.
Referencia.
Prstamo.
Prstamo nter bibliotecario.
Suministro de documentos y bibliografas.
Conmutacin bibliogrfica.
Reproduccin de documentos.
9.2
DEFINIR EL PROBLEMA
La forma en que se puede hacer ms fcilmente la definicin del problema,

es encontrando la respuesta a las preguntas que se hacen en los cuadros a
continuacin:
QUE?
Qu proceso est implicado?
Catlogo Bibliogrfico Web.
Qu no est funcionando?
Las bsquedas a travs del sistema

Web de Libruis.
Cul es la deficiencia?
El sistema slo tiene una forma de

realizar la consulta, los servicios que
presta son muy pocos, y los tiempos
de respuesta son altos.
187
DONDE / CUANDO?
Dnde se observa el problema o Campus, red externa. En el catlogo
deficiencia?
existente.
Cundo se observa el problema o Actualmente.

deficiencia?
IMPACTO
Cul
es
el
impacto
de
la Usuarios insatisfechos.
deficiencia?
Cules son los beneficios de actuar La consecuencia de no actuar, va en
o las consecuencias de no actuar?
contra del objetivo principal de la

biblioteca:
mejoramiento
de
servicios.
Segn esto, la definicin del problema se puede plantear de la siguiente
forma:
Actualmente, los usuarios de la biblioteca realizan las consultas del material
bibliogrfico por medio del catlogo bibliogrfico, situado en la pgina Web e
Intranet de la UIS.
El problema es que los usuarios se encuentran
insatisfechos por el servicio que presta y se quejan constantemente.
9.3
Las personas que estarn directamente involucradas en el proyecto con sus

distintos roles son:
188
Tabla 22. Roles y responsabilidades.
Responsabilidades
Personas Responsables
Director DSI (Patrocinador)
Ing. Enrique Torres Lpez
Director Biblioteca (Cliente)
Ing. Gladys Hernndez
Gerente del Proyecto
Responsable del Proyecto en la DSI
Responsable del Proyecto en la Biblioteca
Ing. Gilberto Rivas

Ing. Yamile Barragn
Master Black Belt
Ing. Edwin Surez
Black Belts
Sergio Contreras
Diana Zambrano
Green Belts
Ing. Gilberto Rivas

Ing. Yamile Barragn
Equipo de Trabajo
Sergio Contreras
(Analista de Sistemas, Arquitecto,
Diana Zambrano
Diseador, Desarrollador)
Yamile Barragn
Representante de los usuarios finales.
Yamile Barragn.
Las responsabilidades de los GB, BB y MBB se encuentran documentadas

en la primera parte, en la fase definir de la metodologa.
9.4
Una vez identificados los responsables de cada rol, comienzan a ser parte
del equipo de trabajo, cuya estructura organizacional est representada
Grficamente de la siguiente forma (figura 44):
189
CLIENTE
PROVEEDOR
Ing. Gladys Hernndez

Direccin Bib.
Ing Enrique Torres

Direccin DSI
Comite de direccin
de proyecto
Ing Enrique Torres

Gerente de
Proyecto
Ing Gilberto Rivas

Ing Yamile Barragn
Resp proyect Bib.
Edwin
Surez
MBB
Ing. Enrique Torres

Resp proyecto DSI
Sergio Contreras / Diana Zambrano

Black Belts
Ing Gilberto Rivas

Ing Yamile Barragn
Green Belts
Sergio Contreras
Diana Zambrano
Ing Yamile Barragn
Equipo
Figura 44. Modelo organizacional del proyecto.
9.5
La identificacin de los clientes fue realizada con el mtodo tradicional de

sondeo dentro de la universidad, y con la ayuda del participante de la
biblioteca que est representando a los clientes en el proyecto. Los mtodos
de nueva generacin no aplican debido a que la envergadura del proyecto es
pequea y no lo justifica.
190
Tabla 23. Identificacin de clientes.

Nombre
Descripcin
Frecuencia
Estudiantes UIS.
Se encuentran los estudiantes de todas las
CLIENTES EXTERNOS
carreras de la Universidad, de primer nivel
Alto.
hasta estudiantes en proyecto de grado.

Profesores.
Aquellos
que
tienen
vnculos
con
la
Universidad.
Empleados
Personal administrativo de la Universidad.
Administrativos.
Personas
Son los estudiantes, profesores y dems
naturales.
personas que no tienen vnculos directos con

la UIS, pero utilizan el sistema para consultar
Medio.
Bajo.
Bajo.
INTERNOS
CLIENTES
si existe material que les pueda interesar.
9.6
Directivas.
Personal
vinculado
administrativo
con
el
tecnolgica.
rea
de
de
la
biblioteca
informacin
Bajo.
DETERMINAR LO CRTICO A ASEGURAR EN LA CALIDAD (CTQ).
La determinacin de las CTQs se bas en diferentes aspectos, el primero de

ellos es la opinin realizada por los representantes de los clientes, el gerente
del proyecto y el equipo de trabajo. Los miembros de los dos primeros roles
se basaron en la experiencia y las constantes quejas realizadas por los
usuarios finales acerca del sistema actual, los otros miembros participantes
utilizaron la lgica y la experiencia en cosas especficas. Los otros aspectos
son analizados ms adelante en el proyecto.
191
El mecanismo utilizado fue el desarrollo del rbol de soluciones, el cual cont

con ms de tres versiones, realizados en sesiones diferentes hasta llegar a
su aprobacin o depuracin para as alcanzar la versin ms acertada. El
rbol de soluciones es el de la figura 45.
Despus de que el rbol lleg a su versin final, lo crtico para asegurar la
calidad fue:
El tiempo de respuesta.
Los servicios que presta.
Las formas de realizar la consulta.
Debido a que en el modelo DMADDV de Seis Sigma, las CTQs deben ser
definidas de una forma EMART , la definicin de cada una es la siguiente:
58
Disminuir el tiempo de respuesta actual en un 20%.

Igualar el nmero de servicios que presta el catlogo bibliogrfico Web
(2) con el servicio de bsqueda de material bibliogrfico informix (5).
Disminuir en un 25% la cantidad de intentos que realiza un usuario
para obtener un resultado en la consulta.
Los nmeros utilizados en la definicin de cada una de las CTQs son
estimados y pueden cambiar despus de completarse la fase medir y ser
presentada al comit para su aprobacin.
58
EMART: Especifica, Medible, Alcanzable, Relevante, Tiempo Limite.
192
193
Figura 45. Diagrama de Arbol de soluciones.
9.7
Los tems ms importantes que se deben definir en el desarrollo del plan son
los siguientes:
9.7.1 Alcance y objetivos del proyecto.
Objetivo General
Desarrollar un prototipo del mdulo de consulta de catlogo bibliogrfico
LIBRUIS a travs de la interfaz del sistema de informacin web de la UIS.
Objetivos Especficos
Igualar el nmero de servicios que presta el catlogo bibliogrfico Web (2)
con el servicio de bsqueda de material bibliogrfico informix (5).
Disminuir en un 25% la cantidad de intentos que realiza un usuario para
obtener un resultado en la consulta.
9.7.2 Costo/Beneficio.
El costo/beneficio del proyecto es de tipo cualitativo, debido a que se
realizar dentro una dependencia que pertenece a una institucin sin nimo
de lucro, por lo tanto los beneficios se analizan de la siguiente manera.
La gran iniciativa que tiene la Biblioteca de Universidad es el excelente
servicio que presta a los usuarios. El catlogo bibliogrfico entra a formar
parte de la lista de proyectos que se desarrollarn para cumplir la iniciativa.
La ecuacin Y = F(x) ayuda a clarificar la decisin.
194
La Y definida del proyecto es el excelente servicio, la X que abarcara el

proyecto es la optimizacin del catlogo bibliogrfico a travs de una interfaz
Web, al relacionarlas se obtiene.
Excelente Servicio = Optimizacin del catlogo bibliogrfico.
En conclusin, el proyecto de optimizacin del catlogo bibliogrfico de la
universidad, si tiene un efecto sobre la gran iniciativa que se tiene en estos
momentos por parte de la biblioteca.
9.7.3 Riesgos.
Tabla 24. Riesgos definidos en el plan.
TIPO DE
DEFINICIN
RIESGO
Tamao
producto.
POSBILES RIESGOS
del Riesgos asociados con el tamao

general del software a construir o
modificar.
Tamao estimado del producto.

Tamao de las Bases de Datos
creadas o empleadas por el
producto.
Cantidad
de
software
reutilizado.
Impacto en el Riesgos
negocio.
asociados
con
las
limitaciones de la gestin o del

mercado.
Efecto
del
producto
en
los
ingresos de la compaa.
Nmero de clientes que usarn

este producto.
Costos asociados por un retraso

en la entrega.
195
Costos
asociados
por
un
producto defectuoso.
Caractersticas
Riesgos asociados con el cliente y la
del cliente.
habilidad
del
desarrollador
para
comunicarse con l en los momentos

oportunos.
Clientes
con
diferentes
con
diferentes
necesidades.
Clientes
personalidades.
Contradiccin en los Clientes.
Colaboracin de los clientes en

el proceso.
Definicin
proceso.
del Riesgos asociados con el grado de

definicin del proceso del software y
su seguimiento por la organizacin
de desarrollo.
Est bien definido el proceso de

software.
El anlisis, diseo y pruebas se

realizan sobre la marcha.
El equipo estima importante el

concepto de calidad.
Entorno
desarrollo.
de Riesgos
asociados
con
la
El cdigo generado por las
disponibilidad y la calidad de las
herramientas
herramientas que se van a emplear
ineficiente.
en la construccin del producto.
Incapacidad
CASE
para
es
integrar
algunas herramientas.
Tecnologa
construir.
a Riesgos
asociados
con
la
complejidad del sistema a construir y

la tecnologa de punta que contiene
el sistema.
Tamao
Trabajo.
software
interacta
con
hardware nuevo o no probado.
Base de datos utilizada no tiene

el rendimiento esperado.
y Son los riesgos asociados con la
experiencia del experiencia tcnica y de proyectos de

grupo
El
de los ingenieros del software que van a
Disposicin de la mejor gente.

El
personal
los
conocimientos adecuados.
realizar el trabajo.
Se
cuenta
personal.
196
tiene
con
suficiente
Figura 46. Cronograma.
9.7.4 Cronograma.
197
9.8
CUADRO RESUMEN DEL PROYECTO
CUADRO RESUMEN DE PROYECTO

Descripcin del Proyecto
Fecha Inicio:
Enero 2 / 2004
Fecha estimada fin:
Agosto 15 / 2004
MODULO DE CONSULTA DEL CATLOGO BIBLIOGRFICO EN

LA INTERFACE WEB DEL SISTEMA DE INFORMACIN DE LA
BIBLIOTECA DE LA UIS, LIBRUIS.
Actualmente, los usuarios de la biblioteca realizan las consultas del
material bibliogrfico por medio del catlogo, situado en la pgina Web
Definicin del
e Intranet de la UIS. El problema es que los usuarios se encuentran
Problema:
insatisfechos por el servicio que presta y se quejan constantemente.
Igualar el numero de servicios que presta el catlogo bibliogrfico
Web (2) con el servicio de bsqueda de material bibliogrfico
Declaracin de los
informix (5).
objetivos
Disminuir en un 25% la cantidad de intentos que realiza un usuario
para obtener un resultado en la consulta.
Ttulo del Proyecto:
Beneficios
Medida
Actual
9 seg.
2
2,07
Unidades
Tiempo de Respuesta
Numero de Servicios
Intentos de consulta
Segundos
SI / NO
Intentos
7.2 seg.
5
1,55
Fecha
proyectada
Ago/20/2004
Ago/20/2004
Ago/20/2004
Departamento
DSI
Biblioteca
DSI
DSI
DSI
Biblioteca
Externo
% Tiempo
10%
5%
40%
100%
100%
20%
70%
Meta
Miembros del Equipo

Nombre
Enrique Torres Lpez
Gladys Hernndez
Gilberto Rivas
Sergio Contreras
Diana Zambrano
Yamile Barragn
Edwin Surez
Rol
Gerente
Gerente Cliente
Green Belt
Black Belt
Black Belt
Gerente IM
Master Black Belt
Cronograma
Entregables
Fase Definir
Fase Medir
Fase Analizar
Fase Disear
Fase Desarrollar
Fase Verificar
Fecha inicio
Abr/05/2004
Abr/18/2004
May/17/2004
Jun/01/2004
Jun/01/2004
N.A.
Fecha Fin
Jun/23/2004
Jul/17/2004
Jul/31/2004
Ago/11/2004
Ago/28/2004
N.A.
Responsables
D, S, G, Y, E.
D, S
D, S
D, S
D, S
Comentarios
Aprobaciones
Rol/Ttulo
Nombre
198
Fecha
Revisiones
Revisin nmero
9.9
Autor
Fecha
La definicin del vocabulario se realiz basada en los conceptos de los

representantes de los clientes, el gerente del proyecto y los Black Belts.
Los conceptos finales ms relevantes son los siguientes:
Tiempo de respuesta de una consulta:
es el tiempo que gasta el
resultado de una consulta en ser enviado por el servidor de

aplicaciones.
Formas de realizar una consulta: es la sintaxis que el sistema acepta
vlida para realizar la consulta.
Intuitivo:
es la compresin que el sistema tiene para entender al
usuario final.
Servicios: es lo que el sistema ofrece al usuario final para utilizar en el
sistema.
9.10 IDENTIFICACIN DEL PROCESO ACTUAL
En el proceso actual, el usuario final inicia cuando selecciona los criterios de

bsqueda, (Autor, Ttulo o Materia), el tipo de documento (Libro, Tesis,
Analtica) y digita las palabras clave a buscar.
El sistema muestra un listado de resultados basado en las palabras clave
digitadas y los criterios seleccionados, el usuario observa los detalles
199
especficos de un material haciendo click en el ttulo o en el nmero que se le

asign a la referencia en el listado.
Inicio
Seleccionar
criterios de
bsqueda
Digitar
palabras clave
Listado de
resultados
Ver Detalles
FIN
Figura 47. Proceso Actual
200
9.11 PRESENTAR AL COMITE PARA APROBAR

Los aspectos que el comit debe tener presente para aprobar el proyecto y
dar luz verde al inicio de este, son:
La declaracin del problema.
Las CTQs.
La ecuacin Y = F(x)
El costo/beneficio.
El presupuesto.
El rbol de soluciones.
201
10. FASE MEDIR
10.1 CAPTUAR LA VOZ DEL CLIENTE (VOC)
Los mecanismos utilizados para capturar la voz del cliente fueron la

entrevista y la encuesta va Web.
Fueron seleccionados ya que se
presentaban como los mecanismos que se acomodaban a las necesidades

del proyecto en trminos de presupuesto, tiempo y resultados.
La encuesta va Web presenta como desventaja la demora en la obtencin
de los datos, aunque el promedio de encuestas recibidas diariamente fueron
de 40 encuestas por da, considerado por el director del proyecto como un
nmero aceptable para la captura de datos.
Los resultados de la VOC obtenidos segn los mecanismos utilizados son los
siguientes:
202
Satisfaccin del cliente con el sistema
Satisfaccin del cliente con el sistema
80%
60%
66%
40%
34%
20%
0%
Si
No
Figura 48. Resultados de la VOC.
Causas de la insatisfaccin del cliente
Causas insatisfaccin
50%
40%
30%
20%
50%
30%
10%
20%
0%
Tiempo de
Respuesta
Servicios
Formas de
realizar
consulta
Figura 49. Porcentaje de quejas del cliente.

203
Despus de tener en cuenta los resultados obtenidos por los representantes

de los clientes y la encuesta realizada a los usuarios finales, el rbol de
soluciones definitivo es observado en la figura 50.
El anlisis de las mtricas, el plan de coleccin de datos, las graficas, el
clculo del nivel de sigma y el Benchmarking se hace de manera individual
para cada CTQ, como se muestra a continuacin.
Figura 50. Arbol final soluciones
204
205
Figura 50. rbol de soluciones.
10.2 CTQ1
206
10.2.2 Plan de Coleccin de Datos
La utilizacin de variables de tiempo que se ejecutan en el servidor, ayudan a

medir los tiempos de peticin de la consulta, y los tiempos de respuesta del
servidor. La funcin principal de la base de datos es medir las estadsticas
necesitadas para el proyecto. La tabla que se dise para el tiempo de
respuesta es la siguiente:
Figura 51. Tabla de estadsticas de tiempo.
207
4MB
Satellite
Fibra Optica
Satellite dish
Satellite dish
Enrutador
Telecom
HP
BGP
Server
Firewall
Enrutador
ISP
Cajun P880
Enrutador
UIS
Computer
Firewall
Aplicacion Wlibruis
Microondas
Cable Submarino
Enrutador
ETB
ETB
Servidor Base de Datos
4MB
Figura 52. Situacin actual, y posicin de captura de tiempo.

El tiempo de respuesta se toma donde indica la flecha con direccin hacia la
izquierda , debido a que es lo que con certeza se puede medir de una
manera confiable, se garantiza que la velocidad de conexin hasta el otro
proveedor de servicios de Internet ya sea por medio del satlite o de el cable
subterrneo es rpida, pero no se puede garantizar despus del proveedor
de servicios del cliente.
10.2.3 Grficas.
Grfica de corrido: representa el tiempo de respuesta en cada consulta

realizada. Se puede observar la gran variacin que existe respecto de la
media.
208
Consultas Vs Tiempo de Respuesta
120
Tiempo de respuesta
100
80
60
40
20
0
1
42 83 124 165 206 247 288 329 370 411 452 493 534 575 616 657 698
Consultas
Figura 53. Consultas vs. Tiempos de respuesta.
Diagrama de torta:
representa los porcentajes de las consultas
defectuosas y no defectuosas.
Consultas defectuosas Vs Consultas no

defectuosas
32%
No Defectuosas
Defectuosas
68%
Figura 54. Consultas defectuosas Vs No defectuosas.
209
Grfico de barras:
representa la cantidad de consultas que realizan
durante cada hora.
80
70
60
Consultas
50
40
30
20
10
0
0
11
13
15
17
19
21
23
Horas
Figura 55. Nmero de consultas Vs hora.

Grfica de puntos: representa las consultas realizadas en su totalidad y
las consultas defectuosas en cada hora.
90
80
70
Consultas
60
50
Consultas(todas)
40
30
20
Consutas
Defectuosas
10
0
1
11
13
15
17
19
21
23
Horas
Figura 56. Consutas por hora vs. Consultas defectuosas por hora
210
Diagrama de torta: representa la cantidad de usuarios que despus de

obtener el listado entran a ver los detalles de un documento.
Usuarios que ven detalles
28%
Ven detalles
No ven detalles
72%
Figura 57. Usuarios que ven detalles vs no ven.
Diagrama de torta: representa la cantidad de usuarios que consultan los

detalles y los que no, cuando el tiempo de respuesta est por encima de
la media.
Usuarios que ven detalles cuando la cosulta es

defectuosa
25%
Ven detalles
No ven detalles
75%
Figura 58. Usuario que ven detalles Vs no ven detalles.
211
Conceptos
Unidad: Es una consulta. Inicia cuando el usuario oprime el botn de
buscar hasta que el sistema enva el resultado de la consulta.
Tiempo de Respuesta: Tiempo que gasta el servidor desde que recibe la
peticin del usuario hasta que enva la respuesta.
Unidad defectuosa:
Es una consulta que su tiempo de respuesta es
mayor que la media de todas las unidades.

Oportunidad: Son las consultas que se realizan en las horas crticas del
servidor de la base de datos y que el tiempo de respuesta esta por
encima de la media.
Nmero de unidades (NU) = 832
Nmero de unidades defectuosas (NUD) = 245
Nmero de oportunidades (NO) = 26
Clculo
DPU
DPO
DPMO
Sigma
NUD
NU
DPU
NO
245
832
0.294471154
26
DPO * 1000000
11325.81361
11325.81361
3,77
212
0.294471
0.011326
No Aplica.
213
10.3 CTQ 2
10.3.1 Determinar qu medir.
214
Hacer una comparacin con el actual administrador del sistema, y recibir una
explicacin de cada uno de los servicios que presta la bsqueda del catlogo
bibliogrfico de informix de la UIS.
a. Consulta
Es el servicio principal del catlogo bibliogrfico, de l se derivan los
otros servicios.
La consulta se puede realizar por tipo de
documento(Libro, Tesis, Revista, Analtica) o por tipo de consulta

(Autor, Titulo, Materia).
Figura 59. Consulta simple sistema informix.

Descripcin:
Se debe seleccionar por lo menos un tipo de bsqueda (autor,
ttulo, materia), los tres pueden ser seleccionados.
Se debe seleccionar por lo menos un tipo de documento a buscar
(libro, tesis, revista o analtica) se pueden seleccionar los cuatro.
215
Se debe escribir al menos una palabra clave a buscar.

Para escribir dos palabras a buscar se debe escribir el conector
lgico (y/o).
El resultado arroja las similitudes con los criterios de bsqueda.
Figura 60. Listado de resultados sistema informix.

b. Subconsulta
Es un servicio complementario de la consulta, su objetivo principal es
el refinamiento de los criterios de bsqueda para encontrar la
informacin sobre el material bibliogrfico deseado.
216
Figura 61. Subconsulta sistema informix.

Descripcin:
Los criterios anteriormente escritos, son utilizados nuevamente y
no son modificables.
Se debe seleccionar por lo menos un tipo de bsqueda (autor,
titulo, materia), los tres pueden ser seleccionados.
Se debe seleccionar por lo menos un tipo de documento a buscar
(libro, tesis, revista o analtica) se pueden seleccionar los cuatro.
Se debe escribir al menos una palabra clave a buscar.
Para escribir dos palabras a buscar se debe escribir el conector
lgico (y/o).
El resultado arroja las similitudes con los criterios de bsqueda.
c. Detalles
Es un servicio que se agrega a la consulta, muestra los detalles del
material seleccionado
217
Figura 62. Detalles de un material bibliogrfico sistema informix.

Descripcin
Muestra la informacin general del material bibliogrfico
Tipo de documento.
Nmero de clasificacin.
Titulo.
Autores.
Edicin.
rea de publicacin.
Descripcin fsica.
Ejemplar.
Nmero de inventario.
Ubicacin.
Estado.
Fecha de devolucin.
Descripcin.
218
d. Resumen
Es un servicio que se agrega a los detalles del material bibliogrfico,
muestra el resumen de la descripcin del material seleccionado.
Figura 63. Resumen sistema informix.

Descripcin
Muestra en una pgina la descripcin del material bibliogrfico.
10.3.3 Elaborar las grficas.
Servicios
3
2
1
0
Informix
Web
Figura 64. Comparacin de servicios.

219
Conceptos
Unidad: Es un servicio que presta el sistema.
Servicio: Una funcionalidad del sistema que interacta con el usuario
final para la bsqueda de un material bibliogrfico.
Unidad defectuosa:
Es un servicio que no presta el sistema de
bsqueda de catalogo bibliogrfico Web, que si presta el sistema de

bsqueda de catalogo bibliogrfico en informix.
Oportunidad: Es un servicio que es imposible realizar por Web.
La universidad complutense de Madrid, posee uno de los sistemas de

bsqueda de catlogo bibliogrfico va Web ms sorprendentes entre tantas
universidades visitadas.
Presta diferentes servicios como
Bsqueda simple.
Figura 65. Bsqueda simple Benchmarking.
220
Bsqueda Avanzada
Figura 66. Bsqueda avanzada Benchmarking.
Listado de resultado
Figura 67. Listado de resultados Benchmarking.

221
Detalles de Bsqueda
Figura 68. Detalles material bibliogrfico Benchmarking.
Ver detalles tipo MARC
Figura 69. Detalles MARC Benchmarking.
222
Reserva de material
Figura 70. Reserva de material bibliogrfico Benchmarking.
Guardar referencias
Figura 71. Guardar referencias Benchmarking.
223
Bsqueda a:
Catlogo general: contiene todos los fondos y materiales adquiridos.
Subcatlogo de Fondo Antiguo: contiene una parte importante de los
fondos del siglo IX a 1801 de la UCM.
Subcatlogo de la Biblioteca digital Dioscrides: permite consultar ms
de 3.000 libros digitalizados.
Subcatlogo de Tesis de la UCM: permite consultar ms de 7.000 tesis
digitalizadas.
Subcatlogo de recursos electrnicos:
permite el acceso a bases de
datos, monografas, tesis y revistas en texto completo.

Subcatlogo de Biblioteca Europea: documentacin y legislacin sobre la
UE.
Catlogos especiales (nuevas adquisiciones, materiales especiales: DVD,
videos).
Bibliografas recomendadas: asignatura / profesor.
Consultas conjuntas a catlogos de otras bibliotecas.
Opciones personalizadas: ver su registro de usuario (prstamos, cmo
crear un PIN para acceder a recursos electrnicos desde casa)
Informacin: horarios, fondos, ayuda, buzn de sugerencias, libros para
adquirir.
Conclusin:
El catlogo de la universidad complutense cuenta con siete servicios. Los
siguientes servicios se pueden tener en cuenta para el proyecto.
Ver detalles MARC.
Guardar referencias.
Bsqueda avanzada.
El servicio de reserva de materiales no es tenido en cuenta por decisin de la
alta direccin.
224
10.4 CTQ 3
225
Para medir el nmero de intentos que un usuario hace al momento de

realizar una consulta hasta obtener un resultado como respuesta, se crea
una tabla en el servidor de la aplicacin y se capturan los parmetros que el
usuario introduce en el campo al momento de hacer la consulta, se guarda
en otra variable el primer resultado que se genera en la lista de resultado y si
la consulta no arroja un resultado, se guarda en otra variable el error que fue
generado.
Las tablas diseadas para medir el nmero de intentos hasta obtener un
resultado son las siguientes:
Figura 72. Tablas de captura de datos estadsticos.
226
10.4.3 ELABORAR LAS GRFICAS
a. Diagrama de corrido: Esta grfica representa la variacin que existe

del nmero de intentos al momento de realizar las consultas respecto
de la media. La media de intentos que hace un usuario hasta obtener
un resultado es 2,0791. Ver figura 73.
Diagram a de Corrido
14
12
10
8
6
4
2
691
661
631
601
571
541
511
481
451
421
391
361
331
301
271
241
211
181
151
121
91
61
31
Figura 73. Diagrama de Corrido
b. Grfica de los resultados de la consulta: Del total de las consultas que

se hicieron, se observa que el 48% de los datos arroja algn resultado
de la consulta y el 52% son errores que el usuario comete al momento
de realizar la consulta.
227
Resultados de las Consultas
52%
51%
50%
52%
49%
48%
48%
47%
46%
Resultados
Errores
Figura 74. Resultados de las Consultas.

c. Grfica de los tipos de errores:
Esta grfica muestra los tipos de
errores ms frecuentes que se presentan al momento de realizar las

consultas. Los errores estn clasificados de la siguiente forma:
i.
Error 1: Ha introducido caracteres invlidos en la consulta.
ii.
Error 2: No ha seleccionado el criterio de bsqueda.
iii.
Error 3: No ha seleccionado el tipo de documento.
iv.
Error 4: No ha introducido las palabras a buscar.
Tipos de errores en las consultas

70%
60%
50%
40%
69%
30%
20%
15%
14%
1%
10%
0%
Error 1
Error 2
Error 3
Error 4
Figura 75. Grficas de los tipos de errores.

228
Conceptos
Unidad:
es una consulta.
Inicia cuando el usuario oprime el botn
consultar hasta que el sistema arroja el resultado, si la consulta fue

exitosa o hasta que el sistema arroja el mensaje de error resultado de una
consulta mal realizada.
Nmero de intentos: es el nmero de intentos que realiza un usuario en
una consulta hasta que el sistema arroja algn resultado. El sistema
puede arrojar o no resultados dependiendo de si existe el material en la
biblioteca o si la consulta fue hecha con la sintaxis permitida.
Unidad defectuosa: Cuando el sistema arroja algn mensaje de error tipo
1, 2 3.
Oportunidad: Las consultas que se realizan y que arrojan errores tipo 4.
Nmero de unidades (NU) = 709
Nmero de unidades defectuosas (NUD) = 368
Nmero de oportunidades (NO) = 5
Clculo
DPU
DPO
DPMO
Sigma
NUD
NU
DPU
NO
368
709
0.5190
5
DPO * 1000000
103800
103800
2,78
229
0.5190
0.1038
Existen muchos ejemplos de catlogos bibliogrficos que se pueden tener en

cuenta para comparar.
Uno de los ms visitados y ms conocido es el
buscador Google . Las ventajas que presta este buscador, comparado con la
59
aplicacin actual de consulta del material bibliogrfico va Web de la UIS son:
Para realizar una consulta simple en google, se digitan las palabras

descriptivas y se presiona la tecla ENTER o se hace clic en el botn
de bsqueda en Google para ver la lista de resultados relevantes.
Google slo muestra aquellas pginas que incluyen todos los trminos
de la bsqueda. No es necesario incluir "and" entre sus trminos.
Para proporcionar resultados ms exactos, no usa "bsquedas

parciales" ni realiza bsquedas con "comodines". En otras palabras,
busca exactamente los trminos que ingresa en la casilla de
bsqueda. Buscar "sal" o "sal*" no devolver bsquedas que
contengan "salero" o "salamandra".
Las bsquedas no distinguen entre maysculas y minsculas. Todas

las letras, independientemente de como estn escritas, se consideran
minsculas.
Las bsquedas Google en espaol no distinguen los acentos

diacrticos, diresis ni la letra ee.
Si no encuentra similitud de la palabra que ha utilizado el usuario, la

aplicacin aproxima la consulta segn los registros que contenga.
Las caractersticas que se tuvieron en cuenta a la hora de realizar el

Benchmarking fueron la medida del nmero de intentos que realiza un
usuario al momento de realizar la consulta para que el sistema arroje algn
59
GOOGLE: http://www.google.com
230
resultado. Se concluye, que este buscador, sea cual tipo de consulta que el
usuario realice, arroja resultados al primer intento de bsqueda.
Al igual que en el anlisis de Benchmarking de la CTQ 2, el catlogo
bibliogrfico de la Universidad Complutense de Madrid, es un gran
acercamiento a las metas que se quieren alcanzar en este proyecto. As
como google, el catlogo de la biblioteca complutense, permite en su
bsqueda simple, realizar las consultas por ms de una palabra sin utilizar
operadores.
La bsqueda por palabras clave es el tipo de consulta con ms formas de
realizarla. Si la bsqueda se realiza en cualquier campo, el sistema busca en
todos los campos del registro, pero se puede limitar la consulta por Autores,
Ttulos, Materias, y Notas, y utilizar los operadores booleanos: AND, OR,
AND NOT, NEAR y WITHIN #
Las palabras clave, adems, pueden truncarse mediante los siguientes
caracteres:
* Trunca hasta cinco caracteres a partir de la posicin de la palabra en la que
se encuentre.
** Trunca un nmero ilimitado de caracteres a partir de la posicin de la
palabra en la que se encuentre.
? Recupera la palabra especificada con cualquier carcter en la posicin en
la que se encuentre (anders?n recupera Anderson y Andersen).
10.5 DESARROLLAR EL MODELO FINANCIERO
No aplica para el proyecto, debido a su envergadura.
231
10.6 IDENTIFICAR Y PRIORIZAR LOS REQUERIMIENTOS DE LOS

CLIENTES
Antes de iniciar la identificacin y priorizacin de los requerimientos de los

clientes, las CTQs del proyecto ya deben estar claramente definidas. Segn
la definicin del problema Actualmente, los usuarios de la biblioteca
realizan las consultas del material bibliogrfico por medio del catlogo
bibliogrfico, situado en la pgina Web e Intranet de la UIS. El problema
es que los usuarios se encuentran insatisfechos por el servicio que
presta y se quejan constantemente, stas CTQs deben atacar
directamente el problema con el fin de eliminarlo en su mayor parte.
Una vez establecidas las CTQs se comienza a establecer la captura de
Requisitos y la forma de satisfacerlos, centrado siempre en el cumplimiento
de esas metas.
Cuando se comprende el contexto que enmarca el desarrollo del sistema, los
clientes a travs de diversas fuentes de informacin, crean una primera lista
60
de las caractersticas que debera tener el sistema, y son clasificadas

basadas en el modelo de Kano.
La tabla 25 muestra esta lista a
continuacin.
60
Clientes: Biblioteca y los representantes de los usuarios. Los mecanismos que se

utilizaron para la toma de requisitos candidatos fue la Voz del Cliente.
232
Tabla 25. Principales caractersticas que debe tener el sistema.

Nmero
Descripcin
El sistema debe permitir realizar bsquedas del material
Tipo
61
bibliogrfico que se encuentra incorporado en el sistema

principal Libruis.
2
El resultado de la bsqueda debe permitir ver un listado con los
datos ms generales de cada referencia encontrada.

3
Se debe permitir seleccionar uno de estos resultados y ver los
detalles generales de ste.

4
La referencia seleccionada se podr ver en el formato MARC.
Se podr realizar una subconsulta con los resultados arrojados
en la consulta anterior.
6
Se podr seleccionar las referencias que el usuario tenga a
consideracin, ya sea para imprimir un listado o enviar a una

cuenta de correo electrnico.
7
El resultado que arroje debe ser en tiempos cortos.
La apariencia grfica debe ser agradable al usuario.
El modo de navegacin debe ser intuitivo sin importar el usuario.
10
El sistema debe ofrecer una ayuda que permita encontrar lo que
el usuario est buscando.

11
El lenguaje de desarrollo debe adaptarse a los servidores que
alojarn la aplicacin.
12
Permitir consultar revistas.
Los requisitos pueden clasificarse de dos formas: requisitos funcionales y no

funcionales. Los requisitos funcionales son aquellos que hacen todo lo que
se supone debe hacer el sistema, es decir, las funcionalidades que el
sistema pueda ofrecer a los diferentes tipos de usuarios. Los requisitos no
funcionales son aquellos que no se encuentran afectando de una manera
directa el objetivo principal del sistema.
61
Tipo: Clasificacin establecida segn el modelo de Kano.
233
El siguiente paso es identificar cules de los requisitos candidatos

mencionados anteriormente se pueden representar por medio de casos de
uso, es decir, establecer los requisitos funcionales.
Tabla 26. Listado de Requisitos Funcionales.
Nombre
Realizar
Bsqueda
Descripcin
Recuperar informacin acerca del material bibliogrfico,
utilizando una interfaz web que le permita realizar una
bsqueda simple, con solo palabras, o una bsqueda
avanzada, agregando operadores lgicos y otros criterios.
Ver Detalles
Ver las caractersticas ms representativas de un libro, ya sea
en un formato que contenga solamente la descripcin general,
o en uno ms avanzado denominado MARC.
Subconsultas
Realizar una nueva bsqueda, teniendo en cuenta el resultado
de una bsqueda antes realizada.
Guardar
Permitir seleccionar libros y guardarlos con la informacin
Referencia
general.
Imprimir Listado Preparar una pgina con la informacin detallada de cada
material de tal forma que se puede imprimir.
Enviar Listado
Generar un listado para enviarlos a una cuenta de correo
electrnico.
Navegar por los Permitir navegar por los autores o materias, mostrados en los
resultados
detalles de un material bibliogrfico.
Los otros requisitos de la tabla 26, que no fueron analizados en la tabla 25 se

consideran no funcionales.
CASOS DE USO
Los actores son los usuarios finales que interactuarn con el sistema de
Bsqueda.
Hacen parte de este grupo los estudiantes, profesores y los
profesionales que pertenezcan a la comunidad universitaria.
234
Bsqueda Catlogo
Usuario
Figura 76. Caso de uso general.

Los casos de uso que se plantearon para este actor representa los requisitos
funcionales por medio del diagrama de casos de uso presentado a
continuacin (Figura 77).
Bsqueda Simple
Bsqueda Avanzada
Navegar por resultados

<<extend>>
<<extend>>
Usuario Gen eral
Consulta
<<extend>>
V er Detal les
Guardar Referencia
Subconsulta
Figura 77. Diagrama de Casos de Uso
235
Descripcin de los casos de uso (CU):

Tabla 27. CU consultar.
CU 1: consultar
Nombre
Descripcin
Precondiciones
Flujo Bsico
Poscondiciones
Caso de uso de consultar.

Este caso de uso describe como el usuario final utiliza el
catlogo bibliogrfico a travs de la interfaz Web para consultar
el material bibliogrfico que tiene la Biblioteca de la Universidad.
La estacin de trabajo debe estar conectada a la red.
El servidor de la aplicacin este funcionando.
El servidor de la base de datos se encuentre funcionando.
El botn de buscar debe estar activo.
1. El sistema muestra las opciones de bsqueda.
{avanzada o simple}
2. El sistema muestra cuadros de texto para las palabras, las
opciones de tipos de documentos, y las opciones de tipos de
material.
{ingresa palabras; (Libro, Tesis, Revista); (Titulo, Autor,
Materia)}
3. El sistema muestra las similitudes encontradas entre los
criterios de bsqueda y los datos que posee.
El sistema muestra los datos que tienen similitud con los
criterios de bsqueda digitadas por el usuario y las opciones
de subconsulta, ver detalles o guardar la referencia.
El sistema muestra una pgina de resultados igual a cero y el
usuario cierra la sesin.
usuario realiza una bsqueda totalmente nueva.
236
Diagrama de actividades
Mostrar opciones de
busqueda
Seleccionar Opcion
Mostrar tipo de
documento
Mostrar Cuadros
de Texto
Mostrar tipo de
material
Ingreso de palabras, tipo de
material y tipo de documento
Buscar
Similitudes
Mostrar
Resultados
Figura 78. Diagrama de actividades CU consultar.

Tabla 28. CU subconsulta.
CU 2: subconsulta
Subconsulta
Nombre
Este caso de uso describe como el usuario final hace una
Descripcin
bsqueda ms filtrada para obtener resultados ms precisos.
La consulta debe haber mostrado al menos dos resultados.
Precondiciones
62
La sesin de la aplicacin contina abierta .
Los criterios de bsqueda utilizados en la consulta anterior
deben estar presentes.
1. El sistema obtiene los criterios de bsqueda utilizados en la
Flujo Bsico
consulta anterior.
2. El sistema muestra los cuadros de texto, donde el usuario
digitar los nuevos criterios que va a adicionar.
3. El sistema busca las similitudes entre los criterios de
bsqueda y los datos que posee el sistema.
62
Sesin Abierta: Que la ventana del navegador no se haya cerrado.
237
Poscondiciones
4. El sistema muestra los resultados de la bsqueda.

El sistema muestra resultados ms precisos con los criterios
de bsqueda del cliente, y la opcin de ver detalles de cada
uno de los resultados, guardar las referencias de cada uno
de los resultados.
Diagrama de actividades
[Criterios de Busqueda anteriores]

Mostrar Cuadros de
Texto
Digita criterios a agregar a los criterios anteriores
Buscar
Similitudes
Mostrar
Resultados
Figura 79. Diagrama de actividades CU subconsulta.
Tabla 29. CU bsqueda simple.

238
CU 3: bsqueda simple
Bsqueda simple
Nombre
Este caso de uso describe como un usuario utiliza el catlogo
Descripcin
bibliogrfico a travs del Web de la Universidad para consultar el
material bibliogrfico que existe en la biblioteca.
Precondiciones
El servidor de la aplicacin debe estar funcionando.
El servidor de la base de datos se encuentra funcionando.
El botn de buscar debe estar activo.
1. El sistema muestra el cuadro de texto donde el usuario
Flujo Bsico
digitar las palabras por las que desea realizar la bsqueda.
2. El sistema comprueba que el nmero de palabras digitadas
sea menor o igual a cuatro.
3. El sistema busca las similitudes de las palabras con los datos
del sistema
4. El sistema muestra los resultados obtenidos de la bsqueda.
El sistema muestra los datos que tienen similitud con los
Poscondiciones
criterios de bsqueda digitadas por el usuario y las opciones
de subconsulta, ver detalles o guardar la referencia.
Diagrama de Actividades
Mostrar Cuadros
de Texto
Ingresar Palabras a buscar
Buscar
Similitudes
Mostrar
Resultados
Figura 80. Diagrama de actividades CU bsqueda simple.

Tabla 30. CU bsqueda avanzada.
239
CU 4: bsqueda avanzada
Bsqueda avanzada
Nombre
Este caso de uso describe como un usuario final realiza una
Descripcin
bsqueda avanzada al sistema de Catlogo Bibliogrfico a travs
de la interfaz Web de la Universidad.
Precondiciones
El servidor de la aplicacin debe estar funcionando.
El servidor de la base de datos se encuentra funcionando.
La opcin de buscar debe estar activa.
Slo se pueden ingresar cuatro palabras a buscar.
Slo se puede ingresar una palabra por cada cuadro de
texto.
1. El sistema muestra cuatro cuadros de texto.
Flujo Bsico
{El usuario digita las palabras por las que desea hacer la
bsqueda.}
2. El sistema muestra los tipos de opciones que puede ser una
palabra.
{El usuario selecciona el tipo de la(s) palabra(s) de ese
cuadro de texto, autor, titulo, materia, libro, tesis, analtica,
revista.}
3. El sistema verifica la cantidad de cuadros de texto llenos
{uno solo}
4. El sistema verifica si el cuadro lleno tiene seleccionado su
tipo.
{Si}
5. El sistema busca las similitudes de la palabra y su tipo en los
datos que posee el sistema.
6. El sistema muestra los resultados de la bsqueda.
Flujo Alternativo 1. en 3, el sistema verifica la cantidad de cuadros de texto
llenos
{varias}
2. en 4, el sistema verifica si el cuadro de texto lleno tiene
seleccionado su tipo.
{No}
El sistema muestra resultados ms precisos con los criterios
Poscondiciones
de bsqueda del cliente, y la opcin de ver detalles de cada
uno de los resultados y guardar las referencias de cada uno
de los resultados.
240
Diagrama de Actividades
Mostrar Cuadros de
Texto
Ingresar Palabras
Mostrar opciones de Tipo
{Autor, Titulo, Materia, Libro, Revista, Tesis, ao, ISSN, ISBN}

Comprobar
Significados
[ Al menos una palabra sin tipo ]
[ Palabra con Tipo ]
Buscar Similitudes de
"palabra-tipo"
Mostrar
Resultados
Figura 81. Diagrama de actividades CU bsqueda avanzada.

Tabla 31. CU guardar referencia.
CU 5: guardar referencia
Guardar los registros marcados.
Nombre
Este caso de uso describe como el usuario utiliza el sistema para
Descripcin
seleccionar las referencias de preferencia para luego enviarlas a
una cuenta de correo electrnico o imprimir un listado.
Precondiciones
El usuario debe haber realizado una consulta, y el sistema le
ha arrojado los resultados organizados por pginas de hasta
n registros.
El usuario ha obtenido al menos un resultado como
respuesta del sistema.
La impresora debe estar funcionando.
La impresora debe tener papel para usar.
El servicio de envi en el servidor de correo debe estar
activo.
1. El sistema muestra al usuario los resultados que le ha
Flujo Bsico
arrojado en respuesta a la consulta y escoge aquellos en los
que l se encuentra interesado en recibir mayor informacin.
2. El usuario hace la seleccin de aquellos registros que son de
su preferencia.
3. El sistema guarda los registros marcados.
4. El usuario expide el listado para ver los registros que ha
guardado previamente.
5. El usuario solicita al sistema que la informacin adicional de
los tems que ha seleccionado sea enviada a una cuenta de
241
6.
7.
8.
Flujo Alternativo
9.
1.
2.
3.
4.
5.
Poscondiciones
correo electrnico.
El sistema basndose en la peticin enviada por el usuario
genera el cuerpo del mensaje del correo electrnico con la
informacin adicional de los tems seleccionados, y le
presenta al usuario un formato de captura de datos.
El usuario ingresa los datos que son necesarios para enviar el
correo electrnico, como la direccin a la cual se desea enviar
la informacin, el ttulo y un texto adicional que desee agregar
al cuerpo del mensaje.
El sistema se conecta con el servidor de correo y enva la
informacin al correo correspondiente y le muestra al usuario
una notificacin de que la operacin fue llevada a cabo con
xito.
El caso de uso finaliza con xito.
En 2, el usuario puede solicitar al sistema ver los detalles de
cualquier registro y desde ah puede guardarlo.
En 3, el usuario puede seguir navegando por el sitio para
agregar ms registros al listado.
En 4, el usuario puede hacer modificaciones del listado si
desea eliminar alguno de los registros guardados.
En 5, el usuario tambin puede solicitar al sistema imprimir el
listado. Entonces el sistema muestra al usuario una pgina
con la informacin adicional sobre los tems solicitados por el
usuario, la cual puede ser impresa por el usuario.
En 8, el sistema puede detectar un error en los datos en el
momento de conectarse al servidor de correo por lo cual el
sistema notifica al usuario el error y el caso de uso termina.
El sistema enva el correo el electrnico al usuario y le
notifica de este suceso,
El sistema enva el correo el electrnico al usuario y presenta
un error enviando el correo electrnico.
El sistema enva el listado en formato de impresin y la
impresora imprime satisfactoriamente.
El sistema enva el listado en formato de impresin y se
presenta un error en la impresin.
242
Inicio
Mostrar Resultados
Consulta
Ver Detall es
Mostrar
Detalles
No Ver Detal les

Sel ecciona Regi stros a Guardar
Guardar Registros
Marcados
[ Agregar otros registros ]
Navegar por los

resultados
[ No agregar ms ]
Solicita Expedir el listado
Mostrar listado
Regi stros Guardados
Modificar
listado
[Rechazar]
[Aceptar]
[ Imprim ir ]
Preparar Pgina
Impresi on
[ Enviar por Correo ]
Mostrar
Formulario
Imprimir
Llenar Datos
Verificar Datos
[Datos i nvl idos]
[Datos Vlidos]
Envi ar
Termina
Figura 82. Diagrama de actividades CU guardar referencia.

243
Tabla 32. CU ver detalles

CU 6: ver detalles
Ver detalles.
Nombre
Este caso de uso describe como el sistema permite al usuario
Descripcin
seleccionar las referencias de preferencia para luego ver los
detalles ms generales en formato Normal o en formato MARC.
Precondiciones
El usuario debe haber realizado una consulta, y el sistema le
ha arrojado al menos un resultado.
1. El sistema muestra al usuario los resultados que le ha
Flujo Bsico
arrojado en respuesta a la consulta y escoge aquellos en los
que l se encuentra interesado en recibir mayor informacin.
2. El usuario selecciona el registro para el cual quiere ver la
informacin general en formato Normal y enva la peticin al
sistema.
3. El sistema recibe la peticin del usuario y muestra toda la
informacin acerca del registro escogido en el formato
Normal.
4. El caso de uso finaliza.
En 2, el usuario selecciona mostrar la informacin en el
Flujo Alternativo 1.
formato MARC.
2.
En 3, el usuario puede ver tambin la informacin en el
formato opuesto al seleccionado en 2.
Poscondiciones El usuario puede guardar la referencia.
El usuario puede ir a ver detalles MARC si esta en detalles
normal, o ver detalles normal si esta en detalles MARC.
El usuario puede navegar por los autores o materias del
material.
El usuario puede volver al inicio del sistema.
El usuario cierra la sesin.
244
Inicio
Mostrar Resultados
Consulta
Selecciona el Registro
Ver Detalles MARC
Ver Detalles Normal

Mostrar
Detalles Normal
Mostrar
Detalles Marc
Termina
Termina
Figura 83. Diagrama de actividades CU ver detalles.

Tabla 33. CU navegar por los resultados.
CU 7: navegar por los resultados
Navegar por los resultados.
Nombre
Este caso de uso describe como el sistema permite al usuario
Descripcin
navegar por los resultados obtenidos despus de realizar
cualquier consulta.
Precondiciones
El sistema muestra al menos un autor.
El sistema muestra al menos una materia.
El sistema debe estar mostrando el detalle en formato
normal.
1. El sistema muestra la informacin acerca del material
Flujo Bsico
bibliogrfico escogido en el formato normal.
2. El usuario puede continuar navegando por una de las
materias a las cuales pertenece el material.
3. El caso de uso finaliza.
Flujo Alternativo 1. En 2, el usuario puede continuar navegando por uno de los
autores del material.
2. En 3, el usuario puede seguir navegando por los resultados
de las consultas.
Poscondiciones El sistema muestra los resultados de la nueva consulta.
245
Inicio
Mostrar Resultados
Consulta
Seleccionar Referencia
Mostrar Detalles
Normal
Navegar por el mismo Autor

Navegar por las mismas Materias
Muestra Resultados
Consulta Materias
Muestra Resultados
Navegar por Autor
Seguir consultando
Abandonar
Termina
Figura 84. Diagrama de actividades CU navegar por los resultados.
10.7 INICIO DE QFD
La escala para determinar el grado de importancia es la siguiente:

Tipo
Valor
Smbolo
Alto
Medio
Bajo
246
Los porcentajes definitivos que se obtuvieron en el rbol de soluciones para

las causas principales del problema son los siguientes:
Causa
Porcentaje
Tiempo de Respuesta.
30%
Servicios.
20%
Formas de realizar la consulta.
50%
La matriz de QFD es la siguiente:
Requerimientos
Importancia
Ofrecer ms servicios
Material completo
Interfaz grfica amigable
Intuitivo
Agilidad en la respuesta
10.8 PLAN DE COMUNICACIONES
Tabla 34. Plan de comunicaciones establecido.

GRUPO
Comit de
Direccin
Master
Black Belt
TIPO DE
NIVEL DE
INFORMACIN DETALLE
Alto nivel
Estado del
proyecto:
Realizaciones,
problemas o
asuntos
importantes que
necesiten ser
resueltos.
Nivel muy
Conceptos de
la metodologa especfico.
Seis Sigma y el
modelo
247
FRECUENCIA
Mensualmente.
METODO DE
COMUNICACIN
Informes Escritos
y reportes orales
dados en
reuniones.
Quincenalmente. Correo
Electrnico.
Equipo de
Trabajo
Usuarios
Publico
General
DMADDV.
Informacin
detallada sobre
el proyecto,
cronograma,
actividades,
fechas lmites,
planes,
publicaciones,
riesgos y
problemas.
Actualizaciones
generales del
avance del
proyecto.
Opiniones
generales sobre
el proceso
actual.
Nivel muy
especfico.
Semanalmente.
Variedad: correo
electrnico,
reportes orales
durante
reuniones,
informes escritos.
General
Mensualmente
Reuniones.
General
Diariamente
Encuestas sitio
Web.
10.9 PRESENTAR AL COMIT PARA APROBAR
Las graficas de la VOC.
Cuadros de determinar las mtricas.
Modelo financiero (si aplica).
Caso de uso principal, y segn la envergadura del proyecto los

casos de uso secundarios.
Matriz de inicio de QFD.
Plan de comunicaciones.
248
11. FASE ANALIZAR
11.1 DETERMINAR QUE CAUSA LA VARIACIN
Las medidas para cada una de las CTQs, proporcionan una mejor visin
sobre las causas del problema. La utilizacin de los grficos de corrido y de
barras para el tiempo de respuesta es de gran apoyo para encontrar la causa
de la variacin.
11.1.1 CTQ 1.
Tiempo de respuesta
120
100
80
60
40
20
0
1
51 101 151 201 251 301 351 401 451 501 551 601 651 701
Consultas
Figura 85. Grfico de corrido CTQ 1.
249
80
70
Consultas
60
50
40
30
20
10
0
0
11
13
15
17
19
21
23
Horas
Figura 86. Tiempo de respuesta con cantidad de consultas por hora.

Las barras de color blanco muestran la cantidad de consultas realizadas por
hora, y las barras de color azul muestran el promedio de tiempo de respuesta
por hora.
Para determinar las causas se utilizan los diagramas de pareto.
Causas de la velocidad
Figura 87. Pareto causas de la velocidad.

250
La causa del tiempo de respuesta alto se debe a varios factores que afectan
directamente al sistema.
Las consultas a la base de datos estn alojadas en la dll, aunque es
cdigo compilado, no es ptimo para la base de datos.
Existe mucha cantidad de volmenes de datos, tanto que el modelo de
la base de datos no es lo suficientemente rpido para satisfacer al
cliente.
La concurrencia de usuario en el servidor de aplicaciones y en el
servidor de base de datos es alta.
Los diferentes sistemas que se encuentran corriendo en el servidor de
aplicaciones (Intranet, Ctedra, otros).
Las diferentes bases de datos alojadas en el servidor de base de
datos.
11.1.2 CTQ 2.
Por ser una variable discreta no se le aplica un anlisis como el de las otras
CTQs.
11.1.3 CTQ 3
Dentro de los tipos de errores que se presentan al momento de realizar una

consulta, se observan:
Error 1: Ha introducido caracteres invlidos en la consulta.
Error 2: No ha seleccionado el criterio de bsqueda.
Error 3: No ha seleccionado el tipo de documento.
Error 4: No ha introducido las palabras a buscar.

251
Como se muestra en el diagrama de pareto, Figura 88, el error ms frecuente

fue el error tipo 1, que corresponde al 69, 02% del total.
Tipos de Errores
400
98,64
100,00
Tipo 3
Tipo 4
84,51
300
69,02
200
100
0
Tipo 1
Tipo 2
Figura 88. Pareto tipos de errores.

Para poder analizar el por que se presenta el error tipo 1, se analizaron los
datos que el usuario digita al momento de hacer las consultas. Los errores
se presentaron por tres causas principalmente: Los espacios entre palabras,
utilizacin equivocada de los operadores +, %, Y, O, y otros como tildes,
palabras con la letra ee y guiones.
La causa ms frecuente del error tipo 1, es la escritura de palabras dejando
espacios entre ellas. Ver figura 89.
Si se quiere reducir la variacin del nmero de intentos que debe hacer un
usuario al momento de realizar una consulta, se debe prestar mayor atencin
en evitar que los errores de tipo 1 se presenten, sobre todo por los espacios
entre palabras.
252
Errores Tipo 1
300
250
200
100,00
90,94
74,41
150
100
50
0
Espacios
Operadores
Otros
Figura 89. Pareto errores tipo 1.
11.2 SESIN DE LLUVIA DE IDEAS
La sesin de lluvia de ideas dio como resultado la siguiente lista de posibles

soluciones, agrupadas segn la CTQ que se intento atacar. Ver tabla 35.
Tabla 35. Sesin de lluvia de ideas.
IDEAS CTQ 1
PUNTAJE
TIPO
Hacer los queries de la forma procedimiento almacenado.
13
Crear un modelo de datos n-dimensional.
15
Grficos tipo jpg.
11
Que haya una distribucin del uso de memoria en el servidor.
Crear un campo entero que indiquela primera letra
Crear una tabla de ms buscados.
Programar la ejecucin de procesos a diferentes horas.
11
tabla de
alfabeto.
253
IDEAS CTQ 2
PUNTAJE
TIPO
Subconsultas.
11
Detalles MARC.
15
Bsqueda Avanzada.
11
Guardar Referencias.
13
Navegabilidad.
15
Ver Resumen.
11
Material Completo.
15
31
PUNTAJE
TIPO
Realizar las consultas sin utilizar operadores.
15
La bsqueda simple utilice todos los criterios de bsqueda.
15
IDEAS CTQ 3
Las ideas fueron agrupadas nuevamente en tres grupos, segn un tipo de

solucin especifico de la siguiente forma:
Tipo 1: Crear un nuevo modelo de datos.
Tipo 2: Optimizar el uso del servidor.
Tipo 3: Desarrollar un nuevo sistema.
Las ideas con un puntaje inferior a 9 puntos no son tenidas en cuenta. Los
criterios para asignar el puntaje es el siguiente.
254
Tabla 36. Puntaje de criterio para la seleccin de ideas.
Criterio
Viabilidad
Puntos
Medida
Puntos del conjunto
15 20
10 - 14
49
Costo
Milln de pesos
01
13
3 o ms
Recursos
Equipos
12
34
5 o ms
Personal
Personas
12
36
7 o ms
Tiempo
Meses
03
4 12
13 o ms
Porcentaje que ataca la
100%
60%
10%
Efectividad
CTQ
Originalidad
idea
Novedosa
Antigua con Antigua sin
en la
mejoras
mejoras
compaa
11.3 DETERMINAR QUE SOLUCIONES TENDRAN MAYOR IMPACTO EN

LOS REQUERIMIENTOS DEL CLIENTE
Las soluciones que se plantean son un paquete de pequeas soluciones que

deben realizarse.
1. Crear un nuevo modelo de datos.
1.1. Crear un modelo Data Warehousing.
2. Optimizar el uso del servidor.
2.1. Distribuir el uso de la memoria del servidor.
2.2. Programar la ejecucin de procesos a diferentes horas.
3. Desarrollar un nuevo sistema.
3.1. Servicios.
3.1.1. Subconsulta.
3.1.2. Bsqueda avanzada.
255
3.1.3. Navegar por los resultados.

3.1.4. Guardar referencias.
3.1.5. Ver detalles MARC.
3.1.6. Ver resumen.
3.1.7. Material completo.
3.2. crear los grficos tipo JPG.
3.3. Realizar consultas sin la utilizacin de operadores.
3.4. la bsqueda simple sea solo un cuadro, y los criterios de seleccin
sean todos.
3.5. Los
queries
sean
realizados
por
medio
de
procedimientos
almacenados y no por cdigo en la pagina.

La escala utilizada es:
Descripcin
Valor
Alto
Medio
Bajo
La importancia de los requerimientos es dada segn el porcentaje que se

asign a las causas del problema en el paso de definicin del problema.
Velocidad 30%, Servicios 20%, Formas de realizar la consulta 50%. Las
expectativas del cliente son agrupadas en las causas del problema.
256
Cuadro QFD.
Propuestas
Desarrollar un
nuevo sistema
Crear un nuevo
modelo de
datos
Optimizar el
uso del
servidor
TOTAL
Requerimientos
Ofrecer ms servicios
Material completo
Interfaz grfica
amigable
Intuitivo
Agilidad en la
respuesta
TOTAL
Importancia
Como
1
1
5
3
5
3
1
5
1
5
1
1
1
1
7
9
15
25
35
15
15
33
25
99
45
29
Diagrama de Pareto
Intuitivo
Agilidad en la
respuesta
Interfaz grafica
amigable
Materia completo
Ofrecer mas servicios
0%
5%
10%
15%
20%
25%
Figura 90. Pareto requerimientos del cliente.
257
30%
35%
40%
Despus del anlisis de QFD y el diagrama de pareto, lo solucin que se

debe realizar primero, debido a que satisface en un mayor porcentaje a las
expectativas del cliente, es desarrollar un nuevo sistema, la segunda
solucin es crear un nuevo modelo de datos de la base de datos, y la tercera
solucin es optimizar el servidor. Si en el ejemplo anterior la soluciones 1 y 2
tuvieran un porcentaje igual o similar, se analiza con el diagrama de pareto
que solucin tiene mayor impacto sobre las expectativas del cliente en el
orden de importancia, por ejemplo si la solucin 3 tuviera un valor de 42 y la
2 de 43, el anlisis debe decir que solucin se realiza dependiendo del
impacto que tenga en el requerimiento de mayor importancia en la matriz.
11.4 ANALISIS DE MODOS DE FALLO Y EFECTOS
258
259
Tabla 37. Anlisis de Modos de Fallo y Efectos (Continuacin)
260
11.5 DESARROLLAR EL PLAN DE CAPACITACIN
La necesidad de la capacitacin se presenta ya que la metodologa que se

est utilizando en el proyecto (Seis Sigma) es una metodologa nueva para la
Divisin de Servicios de Informacin.
Tema
Objetivo
Metodologa
Dirigido a:
Recursos
Introduccin a la metodologa Seis Sigma.

Presentar a los asistentes los conocimientos bsicos de un modelo
de la metodologa Seis Sigma para el desarrollo de Software.
Presentacin
Personal de la DSI y profesores de la Escuela de Ingeniera de
Sistemas y de Ingeniera Industrial de la UIS.
video-Beam
Saln
Computador
Manuales
Tablero
Refrigerios
60.000 $
Presupuesto
Ubicacin
Sesin
1
2
3
Aprobado
Responsables
Auditorio
INSED
Fecha inicio
Fecha fin
Cronograma
Tema
Fecha
Definir-Medir
14/07/2004
Analizar-Disear
16/07/2004
Desarrollar-Validar
21/07/2004
NOTAS
261
Sergio Contreras
Diana Zambrano
14/07/2004
21/07/2004
Hora
10:00 AM
10:00 AM
10:00 AM
Duracin
2h
2h
2h
Plan de la Sesin uno.

Introduccin y Fases Definir - Medir
Hacer una introduccin de la metodologa Seis sigma y presentar
Objetivos
los pasos de la fases definir y medir del modelo DMADDV.
Metodologa
Presentacin.
Lugar
Auditorio INSED
Hora
10 A.M.
Fecha
14/07/2004
Duracin
2 horas
Cronograma
Introduccin a la Metodologa Seis Sigma.
Fase Definir.
Fase Medir.
Preguntas
Diana Zambrano
Responsables
Sergio Contreras
Tema
Plan sesin dos

Tema
Objetivos
Metodologa
Lugar
Fecha
Fases Analizar Disear.

Presentar los pasos de la fases Analizar y Disear del modelo
DMADDV.
Presentacin
Auditorio INSED
Hora
10 A.M.
16/07/2004
Duracin
2 horas
Cronograma
Fase Analizar.
Fase Disear.
Preguntas.
Diana Zambrano
Sergio Contreras
Responsables
262
Plan sesin tres.

Fases Desarrollar Validar.
Presentar los pasos de la fases Desarrollar y Validar del modelo
DMADDV. Y evaluar el alcance de la capacitacin.
Presentacin
Auditorio INSED
Hora
10 A.M.
21/07/2004
Duracin
2 horas
Cronograma
Tema
Objetivos
Metodologa
Lugar
Fecha
Fase Desarrollar.
Fase Validar.
Preguntas.
Evaluar Alcance de la capacitacin.
Diana Zambrano
Sergio Contreras
Responsables
11.6 IDENTIFICAR
LOS
SISTEMAS
AFECTADOS
DE
OTRAS
DEPENDENCIAS
No existe un relacin directa con otros sistemas, aunque existe una relacin
directa con las bases de datos de biblioteca (una que contiene el material de
libros, tesis, y analticas, y otra que contiene las revistas) que es utilizada
tambin por el sistema Libruis.
Debido a que las bases de datos se
encuentran alojadas en otro servidor se debe realizar el anlisis como si

fuera un sistema.
Tpico
Descripcin
Plataforma..
Unix
Motor de la base de datos.
Informix 4
Driver de conexin.
OLEDB
Modelo de datos.
263
11.7 DESARROLLAR EL NUEVO MAPA DE PROCESOS
Inicio
Busqueda
Simple
NO
SI
Digitar
palabras clave
Tipo de
palabra
Palabra
Listado de
resultados
Digitar ms
criterios de
busqueda
Imprimir
referencias
Guardar
Referencia
Ver Detalles
Subconsulta
Ver Detalles
MARC
Ver Resumen
Navegar por
los resultados
Enviar
referencias por
e-mail
FIN
Figura 91. Nuevo mapa de procesos.

El sistema inicia con la opcin de realizar una bsqueda simple, que la
conforma un cuadro de texto donde el usuario final escribe las palabras clave
a buscar con la restriccin que slo sean cuatro palabras como mximo y un
botn de buscar.
Presenta adems la opcin de realizar una bsqueda

264
avanzada donde se muestran cuatro listas donde cada una tiene las
opciones de especificar ms la bsqueda autor, ttulo, materia, libro, revista,
tesis o analtica, y cuatro cajas de texto para introducir la palabra clave de la
opcin.
Si la consulta es exitosa, se observan los resultados obtenidos, y se
presentan tres: opciones guardar la referencia temporalmente, ver los
detalles de una referencia y realizar una subconsulta de los datos.
La subconsulta se realiza para obtener resultados ms precisos de la
consulta anterior, y se realiza de igual forma que la simple.
Ver detalles muestra la informacin general del material, y tiene cuatro
opciones que son:
Ver Detalles MARC: Muestra la informacin del material en el formato
MARC.
Ver Resumen: Muestra el resumen del material, en la actualidad solo
el material bibliogrfico que es tesis cuenta con este servicio.
Guardar referencia:
Es la opcin de guardar la referencia
temporalmente, presentando dos opciones:

o Enviar la lista de referencias a un e-mail.
o Imprimir la lista en papel, la restriccin es que la estacin de
trabajo donde se este realizando la consulta tenga conexin
con una impresora.
Navegar por los resultados:
Cada autor y cada materia tienen un
enlace para que se realicen nuevas consultas sobre la palabra

escogida y arroja una nueva lista de resultados.
265
Causas de la variacin.
Criterio de solucin de lluvia de ideas.
Impacto de mejoras. (QFD)
AMFE.
Plan de capacitacin general.
Nuevo mapa de procesos.
266
12. FASE DISEAR
12.1 SELECCIONAR LA METODOLOGA DE DESARROLLO DE

SOFTWARE
Est claro que Seis Sigma no es un proceso de desarrollo de software, en

lugar que eso, es ms generalizado, es una metodologa de mejoramiento de
procesos y productos. Aunque algunos de los elementos de Seis sigma en el
desarrollo de software son incluidos en el marco de psp, muchos otros estn
solamente disponibles en seis sigma y no son incorporados en psp. Es por
esto, que seis sigma puede ser usado con cualquier modelo de desarrollo de
software que sea estable, como PSP, que proporciona una excelente base
para usar las herramientas de Seis Sigma en la ingeniera del software ya
que son tecnologas complementarias.
La relacin de Seis sigma en el software con psp, se puede caracterizar en la
diferencia de sus objetivos, en donde los objetivos de psp son un
subconjunto de los objetivos asociados al proyecto seis sigma para software.
Los objetivos principales de psp son basados en el mejoramiento

continuo del rendimiento del equipo de desarrollo de software en
trminos de costos, tiempo y calidad entregada.
Los objetivos de Seis sigma incluye los objetivos de psp, pero tambin
se usa para alcanzar otros muchos objetivos del negocio, como el
mejoramiento del servicio del cliente, mejorar la satisfaccin del cliente
y muchos otros mencionados anteriormente.
267
La razn principal por la cual PSP es la metodologa de desarrollo de

software seleccionada en este proyecto, es por las dimensiones del proyecto
y la conformacin del equipo de trabajo, ya que PSP se concentra en las
prcticas de trabajo de los ingenieros en una forma individual.
PSP se ensambla muy bien al modelo DMADDV de Seis Sigma, dado que
proporciona un proceso con medidas que pueden se implementado
directamente con Seis sigma, y a su vez se complementa con la voz del
cliente y con las herramientas que se utilizan para analizar, desarrollar y
validar.
EL PROCESO PERSONAL DEL SOFTWARE
El proceso personal del software es un proceso de mejoramiento diseado
63
para ayudar a controlar, administrar y mejorar la forma en que se trabaja

individualmente. Est estructurado por formularios, guas y procedimientos
para desarrollar software.
As mismo les ensea a cmo planear y darle un seguimiento a su trabajo, a
utilizar un proceso bien definido y medido, a establecer metas medibles, y
finalmente a la utilizacin del rastreo constante para alcanzar dichas metas.
PSP les demuestra a los ingenieros a cmo manejar la calidad desde el
principio del trabajo, a cmo analizar los resultados de cada trabajo, y a
cmo utilizar los resultados para mejorar el proceso de un proyecto siguiente.
63
Traduccin al ingls de PSP: Personal Software Process
268
12.1.1 Principios de PSP.
El diseo de PSP se basa en los siguientes principios de planeacin y de

calidad:
Cada ingeniero es esencialmente diferente; para ser ms precisos, los

ingenieros deben planear su trabajo y basar sus planes en sus propios
datos personales.
Para mejorar constantemente su funcionamiento, los ingenieros deben

utilizar personalmente procesos bien definidos y medibles.
Para desarrollar productos de calidad, los ingenieros deben sentirse

personalmente comprometidos con la calidad de sus productos.
Cuesta menos encontrar y arreglar errores en la etapa inicial del

proyecto que encontrarlos en las etapas subsecuentes.
Es ms eficiente prevenir defectos que encontrarlos y arreglarlos.
La manera correcta de hacer las cosas es siempre la manera ms

rpida y ms barata de hacer un trabajo.
12.1.2 Estructura del Proceso.
Una vez planteada la declaracin de los requerimientos, el primer paso en el

proceso PSP es el de la Planeacin. Este proceso cuenta con una gua del
proceso para ayudar en el desarrollo del trabajo y un resumen del plan para
registrar los datos de la planeacin. A medida que los ingenieros siguen la
gua del proceso para realizar el trabajo, deben realizar un registro del tiempo
y defectos. Al final del trabajo, durante la fase postmortem se compara el
desempeo final con el desempeo planeado, tambien se abstraen los datos
de tiempo y defectos de los registros y se debe completar el resumen del
plan. Cuando este listo se entrega el producto junto con el formato. Figura
92 y 93.
269

PSP tiene un nmero de mtodos que generalmente los ingenieros no
practican, estos mtodos se introducen a travs de una serie de siete
versiones del proceso completo. Estas versiones se etiquetan desde PSP 0
hasta PSP 3, y cada versin tiene un sistema similar de registros, de
formatos, guas, y estndares. Las guas que intervienen en el proceso
definen los pasos para cada parte del proceso.
270
Los registros y los formatos proporcionan las plantillas para almacenar los
datos y los estndares ayudan a dirigir a los ingenieros durante todo el
proyecto que desarrollan, desde el principio hasta el final de ste.
La evolucin del modelo PSP se describe a continuacin y es la que se
muestra en la figura 94.
PSP 3
Proceso
Cclico
Administracin
personal de la
Calidad
Planeacin
personal del
proceso
Lnea Base del

Proceso
Personal
Desarrollo Cclico
PSP 2
PSP 2.1
Revisin del Cdigo

Revisin del Diseo
Plantillas para Diseo
PSP 1
Estimacin del Tamao
Informe de Pruebas
PSP 0
Proceso Actual
Registro de Tiempo
Registro de Defectos
Tipologa de Defectos
PSP 1.1
Planear Tareas
Planear Cronogramas
PSP 0.1
Estndares de Codificacin
Propuesta de mejora de proceso PIP
Medidas del Tamao
Figura 94. Estructura por niveles de psp.

LNEA BASE DEL PROCESO PERSONAL
El objetivo principal del nivel inicial es el de proveer un marco bien definido
para realizar la recoleccin de todos los datos que intervienen en el proyecto.
Esta primera fase es muy importante, ya que proporciona un panorama
general de qu mtodos utilizar para "atacar" el problema.
271
PSP 0
Proceso Actual
Identifica el proceso de desarrollo de software sobre el que se va a
trabajar, se pueden usar los siguientes pasos: Diseo, codificacin,
compilacin y se deben realizar las siguientes tareas del flujo de
trabajo:
Planeacin: Disear la forma como se har el trabajo.
Desarrollo: Desarrollo del actual proceso de software.
Postmortem: Comparacin del rendimiento actual con lo

planeado.
Requerimientos
Planeacin
Desarrollo
Postmortem
Producto Terminado
Datos del proyecto y proceso
Registro del Tiempo

Se usa para medir el tiempo que se gasta en cada parte del proceso
PSP y as poder determinar en donde se consume la mayor cantidad
de tiempo. El log de registros del tiempo se puede ver en el anexo xx.
Registro de Defectos
Se usa para mantener los datos de cada defecto encontrado y
corregido y adems poder determinar en donde ocurren la mayora de
las fallas. Para ver el log de registro de defectos vea el anexo xx.
Estndar de los tipos de defectos
Existen algunos estndares para describir los tipos de defectos. Estos
se encuentran en el anexo E.
272
PSP 0.1
Estndares de Codificacin
Se
utilizan
formatos
que
pueden
contener:
Encabezado,
identificadores, comentarios, etc.

Medidas del Tamao
Durante el proceso de planeacin se estima el tamao del trabajo en
funcin de las lneas de cdigo (LOC). Se debe desarrollar un estndar
para determinar la forma de contar, pueden contener lo siguiente:
Lneas modificadas o borradas.
Comentarios o lneas en blanco.
Lneas con varias declaraciones.
Declaraciones
Etiquetas
Smbolos como { }, begin/end, then, else, case....
Propuesta de Mejoramiento del Proceso
64
Proporciona un registro de los problemas del proceso y las ideas para

el mejoramiento.
PLANEACIN PERSONAL DEL PROCESO

Este proceso hace referencia y puntualiza los detalles finales de la
estimacin de recursos y cronograma, para continuar de lleno con la
planeacin de estos dos puntos. Una vez que se cuentan con estos planes,
el programador tiene una vista general de su proyecto y puede tener un
mejor juicio de la precisin de ste.
64
PIP: Propose Improvement Process
273
PSP 1
Estimacin del Tamao
Cualquiera de los siguientes acercamientos pueden ser usados para
estimar las Lneas de Cdigo.
Mtodo PROBE .
Modelo Cocomo
65
66
Informe de Pruebas
Es usado para mantener un registro de las pruebas hechas y los
resultados obtenidos.
PSP 1.1
Planear Tareas
Implica la estimacin del tiempo de desarrollo y los datos completos en
cada tarea del proyecto.
Planear Cronograma
El cronograma se usa para registrar las horas actuales invertidas en un
periodo calendario determinado. Tambin se utiliza para relacionar las
tareas previstas con el horario del calendario.
ADMINISTRACIN PERSONAL DE LA CALIDAD

Este proceso introduce las revisiones del diseo y el cdigo que hacen parte
del programa, as como las medidas de calidad y la evaluacin.
65
66
PROBE: PROxy-Based Estimating

COCOMO: Constructive Cost Model
274
PSP 2
Revisin del Cdigo
Estas revisiones pueden incluir:
Verificar la inicializacin de las variables y parmetros.
Formatos de llamadas a las funciones.
Verificar los nombres.
Verificar cadenas.
Verificar todos los archivos.
Verificar punteros.
Verificar los formatos de salida.
Verificar los operadores lgicos.
En general verificar en cada lnea de cdigo las sintaxis de las

instrucciones y la puntuacin adecuada y asegurarse que hagan parte
de los estndares de codificacin.
Revisin del Diseo
Asegurar que el diseo enmarque las especificaciones de los

requerimientos.
Verificar la lgica del programa.
Verificar los casos especiales.
Verificar el uso de las funciones.
PSP 2.1
Plantillas para Diseo
Introduce cuatro nuevos plantillas que proveen un marco ordenado que
sirve para el registro correcto de los diseos que el programador
realiza. Pueden incluir:
Escenario operacional.
Especificacin funcional.
Especificacin del estado.
Especificacin lgica.
275
PROCESO CCLICO
Con este nuevo nivel se llega a un nuevo concepto y se introduce una nueva
fase, la fase de realizar el proceso personal creado de una manera cclica y
uniforme.
PSP 3
Desarrollo Cclico: Este nivel ayuda al desarrollador a desarrollar
programas ms largo en poco tiempo y con menos errores, esto quiere
decir que el programador ahora tendra una forma de programar nica
y bien definida.
12.2 DISEO DE FORMATO DE DOCUMENTACIN DE PROGRAMAS
Los formatos presentados para la documentacin de programas fueron

presentados al lder del equipo, y luego el formato seleccionado fue
entregado y explicado a cada uno de los desarrolladores del equipo.
Formato 1
Tabla 38. Formato uno de documentacin de programas.
Programa
Proyecto
Autor
Fecha
Directorio de
Ubicacin
# versin
Descripcin
Base
de
Datos,
Tablas
276
Formato 2
Tabla 39. Formato dos de documentacin de programas.
Proyecto
Fecha
versin 1
Fecha
versin 2
Fecha
versin 3
Programa
Autor
Directorio de
ubicacin
Base
de
Datos, Tablas,
Campos
Descripcin
Formato 3
Tabla 40. Formato tres de documentacin de programas.
Proyecto
Programa
Descripcin
Versin
Autor
Fecha
Directorio de ubicacin
Variables
Directorio de archivos
fuente
Base de datos, tablas,
campos
El formato seleccionado es el nmero uno, debido a que es el ms corto,

sencillo y se puede repetir sin importar las veces que exista una nueva
277
versin del programa, registrando los cambios histricamente sin llegar a

ocupar demasiado espacio en el cdigo del programa.
12.3 DEFINIR LA SEGURIDAD
En la definicin de la seguridad muchos de los tipos a considerar ya se

encuentran establecidos por la Divisin de Servicios de Informacin, y se
acomodaron a las exigencias del proyecto, algunos tipos de seguridad no
aplicaban debido a la magnitud del proyecto.
Tabla 41. Asignacin de seguridad.
SEGURIDAD
Consulta de catlogo bibliogrfico de la UIS va Web.
Proyecto
Tipo
Hardware / Software
DATOS
Documentacin
Legal
Acceso de personal
Fsica
Sistema de Informacin
Responsable
Administrador de servidores de aplicaciones
Administrador de base de datos
Administrador de dominio
N/A
N/A
N/A
Auditora
Identificacin y autentificacin
Tabla 42. Asignacin de roles.

Rol
Administrador de base de datos
Administrador de dominio
Administrador de servidores de
aplicaciones
Auditora
Identificacin y autentificacin
N/A
Nombre
Ing. Benjamn Pico Merchn
Ing. Walter Caldern
Ing. Benjamn Pico Merchn
Ing. Walter Caldern
Ing. Leonilde Martnez
Sistema Informix
No Aplica
278
Fecha
Asignacin
06/2004
06/2004
06/2004
06/2004
06/2004
12.4 ESPECIFICACIN DEL DISEO
El diseo contiene cuatro etapas, segn la pirmide en la figura 35, en el

paso de especificacin del diseo.
12.4.1 Diseo de datos.
Se bas en el concepto de modelos de datos dimensionales, debido a que se

busca la rapidez en el tiempo de respuesta de la consulta y que existen
grandes volmenes de datos en la base de datos, donde el modelo ndimensional tiene sus ventajas con los modelos entidad-relacin.
Las diferencias de los modelos son las siguientes:
Tabla 43. Diferencias entre modelos dimensionales y E-R.
Entidad Relacin
1 tabla por entidad.
Minimizar la redundancia.
ptimo para actualizar datos.
Modelo de Transaccin.
Dimensional
1 Tabla Fact por organizacin de datos.
Maximizar la comprensin.
ptimo para recuperacin de datos.
Modelo Data Warehousing .
Los modelos dimensionales son modelos entidad relacin desnormalizados,

que buscan la fcil comprensin del lector, y la optimizacin para los
reportes.
Los pasos para determinar el modelo dimensional son los siguientes:
a.
Data Mart: en los trminos ms simples es la trascendencia que tendr

la fuente de datos,
en otras palabras, es la parte del modelo del
negocio en que el equipo se centrar. Por ejemplo, rdenes de compra,

envos, ventas, pagos, etc.
279
Consulta del catlogo bibliogrfico.

b.
Granularidad de la tabla Fact: es el nivel ms bajo o el detalle ms

profundo de lo que significa un registro de la tabla de Fact, ya sea una
transaccin individual en un data mart de un banco, o una transaccin
de una venta en un sistema de un almacn.
La informacin de un material bibliogrfico dependiendo de una
palabra
c.
Dimensiones: son las tablas que contienen la informacin descriptiva

de la tabla Fact, ya sea numrica o texto.
Palabras (palabrasauttitmat).
Autores (autores).
Ttulos (titulos).
Materias (materias).
Materiales (materialesbib).
Tipos de documentos (tiposdoc).
Formas (formascon).
Notas (matbib_not).
Ubicacin del ejemplar (ubicacioneseje).
Tiempo (tiempo).
Direccin del resumen de las tesis (dir_resu_tesis).
ISBN (isbn).
ISSN(issn).
Estado del ejemplar (estadoseje).
Ejemplares (ejemplares).
280
d.
Tabla Fact:
es el conjunto de la granularidad de la tabla Fact. En el
momento de leer la tabla Fact el lector debe tener claridad acerca de

que se esta hablando y que significa la tabla por s sola.
Fact_consulta.
autores titma t
ideauttitmat
INTE GE R
desauttitmat CHA R(250)
tipauttitmat
CHA R(1)
c onauttitmat DECIMA L(8)
matbib_mat
ideauttitmat INTE GE R
codmatbib
INTE GE R
etitipmat
CHA R(3)
priindmat
CHA R(1)
segindmat
CHA R(1)
orden
S MA LLINT
matbib_tit
ideauttitmat
codmatbib
etitiptit_
priindtit_
segindtit_
orden
INTE GE R
INTE GE R
CHA R(3)
CHA R(1)
CHA R(1)
S MA LLINT
matbib_aut
ideauttitmat INTE GE R
c odmatbib
INTE GE R
etitipaut
CHA R(3)
priindaut
CHA R(1)
s egindaut
CHA R(1)
orden
S MA LLINT
tiposdoc
idetipdoc
INTE GE R
c odmatbib INTE GE R
c odtipdoc
CHA R(1)
des tipdoc
CHA R(255)
formas con
ideforc on
INTE GE R
codmatbib INTE GE R
codforc on
CHA R(1)
des forc on
CHA R(255)
matbib_not
c odmatbib
INTE GE R
etinot
CHA R(3)
desmatbib_n ot CHA R(255)
ubicac iones eje

c odubieje CHA R(4)
desubieje CHA R(255)
Fac t_consul ta
c odmatbib
INTE GE R
c odpalauttitm at
INTE GE R
ideauttitmat
INTE GE R
idetipdoc
INTE GE R
ideforcon
INTE GE R
numinveje
INTE GE R
c odesteje
CHA R(1)
is sn
CHA R(20)
is bn
CHA R(25)
idedirec c ion
INTE GE R
idetiempo
INTE GE R
ideautitmat_ tit
INTE GE R
ideautitmat_ aut
INTE GE R
ideautitmat_ mat
INTE GE R
c odpalautitm at
INTE GE R
c odubieje
CHA R(4)
ideoricat
INTE GE R
idepubofi
INTE GE R
ideidi
INTE GE R
c odpaipub
CHA R(3)
idefre
INTE GE R
c odc enis ds
CHA R(2)
idetippubser
INTE GE R
ideforrep
INTE GE R
c odgrudocm atbib
CHA R(3)
fecunomatbi b
CHA R(4)
fecdosmatbi b
CHA R(4)
disindac uma tbib
CHA R(1)
c onc onmatb ib
CHA R(1)
c odc atc olma tbib
CHA R(4)
nac autc olma tbib
CHA R(1)
pubc olmatbi b
CHA R(1)
relc olmatbib
CHA R(1)
parnumc lam atbib
CHA R(25)
parnumautm atbib
CHA R(25)
menedimatb ib
CHA R(255)
arepubdisma tbib
CHA R(255)
aredesfis ma tbib
CHA R(255)
aredesnuma lfmatbib
CHA R(255)
mens ermatb ib
CHA R(255)
priindmens e rmatbib
CHA R(1)
s egindmens ermatbib CHA R(1)
palabras autt itmat

c odpalauttitm at
des palauttitm at
ejemplares
numinveje
INTE GE R
codubieje
CHA R(4)
codforadqeje CHA R(1)
idetipc ol
INTE GE R
codmon
INTE GE R
codus u
DECIMA L(10)
codorgs ol
DECIMA L(3)
codcencos
INTE GE R
codfon
DECIMA L(4)
codtem
DECIMA L(4)
codedi
DECIMA L(3)
nitpro
DECIMA L(12)
codsuc
DECIMA L(3)
numeje
INTE GE R
preeje
MONEY
des eje
CHA R(80)
fec adqeje
DAT E
fec graeje
DAT E
fec preeje
DAT E
fec venpreeje
DAT E
horvenpreeje
DAT E
fec dis s el
DAT E
voleje
CHA R(5)
numpubeje
CHA R(5)
anoeje
DAT E
mes eje
DAT E
diaeje
DAT E
es tados eje
c odes teje CHA R(1)
deses teje CHA R(255)
is sn
is s n
CHA R(20)
codmatbib INTE GE R
des is s n
CHA R(25)
tiempo
idetiempo
dia
mes
ano
INTE GE R
CHA R(50)
is bn
INTE GE R
INTE GE R
INTE GE R
INTE GE R
is bn
c odmatbib
desis bn
dir_resu_tes is
idedirec c ion
INTE GE R
c odmatbib
INTE GE R
des_direc cio n CHA R(255)
Figura 95. Modelo dimensional biblioteca.
281
CHA R(25)
INTE GE R
CHA R(255)
12.4.2 Diseo arquitectnico.
Arquitectura de Aplicaciones Distribuidas

La Arquitectura de Aplicaciones Distribuidas en Internet (Distributed interNet
Arquitecture - DNA) es un esquema que permite a los desarrolladores de
software
disear
construir
aplicaciones
distribuidas,
orientada
principalmente a las soluciones en Internet o en una Intranet. La arquitectura

Windows DNA especifica como:
Desarrollar aplicaciones distribuidas de mltiples capas, escalables y

robustas utilizando la plataforma Windows.
Extender datos existentes y aplicaciones externas para soportar el

Internet.
Soportar una amplia variedad de clientes, maximizando el alcance de

las aplicaciones.
Windows DNA est basada en el concepto que dice que una aplicacin
distribuida debe estar separada lgicamente en tres partes o capas, como se
explicaba en el modelo de tres capas de la arquitectura Cliente/Servidor.
Esta separacin incrementa la escalabilidad y hace que la aplicacin sea
ms fcil de manejar y de actualizar.
282
Figura 96. Arquitectura de red distribuida.

Los componentes de presentacin se encargan de la interaccin con el
usuario y de solicitar servicios a la aplicacin por medio de llamados a los
componentes de la capa media que corresponde a la capa de las reglas del
negocio. Los componentes en esta capa se encargan de realizar la lgica
del negocio y de hacer solicitudes a la base de datos. La aplicacin se hace
ms flexible porque los clientes pueden llamar a los componentes del
servidor y mejorar la reutilizacin de cdigo.
Las arquitecturas de mltiples capas, tambin son llamadas arquitecturas
centradas en el servidor, debido a que ellas solamente permiten que la
implementacin de las reglas del negocio de una aplicacin funcione en la
capa intermedia en el servidor, independiente tanto de la interface de
presentacin como de la implementacin de la base de datos.
Dentro de las ventajas que ofrece una arquitectura DNA se destacan las
siguientes:
Soporte de mltiples lenguajes. La implementacin de la lgica de la
aplicacin puede realizarse en diferentes lenguajes de programacin.
283
Implementacin centralizada. Los componentes o implementaciones

de la lgica de la aplicacin se encuentran localizadas en un mismo
servidor facilitando el desarrollo, el mantenimiento y la implantacin.
Balance de carga. El balance de carga corresponde a la distribucin
adecuada de los componentes que hacen parte de una aplicacin en
diferentes servidores de modo que un computador no est
sobrecargado y otro est sin carga. En la medida que la aplicacin
crece en nmero de componentes y en nmero de usuarios se debe
procurar repartir los componentes en diferentes servidores permitiendo
mayor escalabilidad .
67
Eficiencia en el acceso a los datos. Las limitaciones por problemas de

conexin a bases de datos son minimizadas debido a que solo el
componente de aplicacin accede a la conexin y no cada uno de los
clientes.
Adems el cliente no necesita utilizar controladores ni
conexiones a la base de datos.

Capa de presentacin
Incluye la interfase de usuario y la lgica necesaria que determina como se le
muestra al usuario la informacin manejada por la aplicacin.
La lgica
encerrada en esta capa interacta con la capa de negocios.
67
La escalabilidad hace referencia a la capacidad de una aplicacin de incrementar el

nmero de usuarios sin que el desempeo de la misma de disminuya.
284
Figura 97. Capa de presentacin.

Windows DNA ofrece una amplia variedad de interfaces de presentacin o de
usuario, permitiendo implementar una misma aplicacin adecuada para las
diferentes plataformas que utilizan los clientes.
Los servicios disponibles
para implementar la capa de presentacin son:

HTML: Permite que en cualquier ambiente de trabajo que soporte un
navegador de Internet se pueda acceder a la aplicacin.
Scripting y HTML Dinmico (DHTML):
Permiten aadirle a una
aplicacin basada en HTML una mayor funcionalidad en cuanto a la

presentacin. Se pueden disear pginas que respondan a eventos o
que ejecuten una serie de acciones que pueden incluso modificar el
contenido del documento HTML.
Las acciones incluyen filtros
grficos, transiciones, posicionamiento de objetos, etc.
285
Componentes: Algunas veces es necesario que algn segmento de la

aplicacin utilice el sistema operativo o la mquina sobre la cual se
est ejecutando la aplicacin mientras se mantiene una conexin
activa a Internet.
En esos casos se pueden aprovechar los
componentes y los servicios de Internet para desarrollar una

aplicacin ms robusta.
Win32 API : Las aplicaciones escritas utilizando esta librera son las
68
que mayor funcionalidad ofrecen, pero su alcance es limitado a las

plataformas que soportan esta librera.
Capa de Reglas de Negocio
Implementa la combinacin de polticas, reglas y algoritmos que
constituyen los mtodos que la empresa utiliza para realizar sus procesos
de negocios.
La capa de lgica o reglas de negocios es el corazn de una aplicacin
distribuida y es donde se mantienen los procesos especficos de la
aplicacin y las reglas del negocio. La lgica de negocios implementada
en los componentes hacen el puente entre la capa de presentacin y la
capa de datos.
Para desarrollar los componentes de la capa de la lgica de negocios de
una aplicacin se pueden utilizar los servicios Web, los servicios de
mensajera y servicios de componentes.
68
API, Application Programming Interface (Interfaz de Programacin de Aplicaciones).

Conjunto de libreras utilizadas para desarrollar y ejecutar aplicaciones sobre un sistema
operativo u otra aplicacin.
286
Figura 98. Capa lgica de negocios.

Servicios Web. El Microsoft Internet Information Server o IIS permite
el desarrollo de aplicaciones basadas en Web que pueden ser
extendidas sobre el Internet o implementadas sobre una Intranet
corporativa. El IIS hace uso de transacciones para hacer posible la
ejecucin de aplicaciones de una manera robusta y confiable. Las
transacciones garantizan que cualquier procesamiento de informacin
solicitado por un cliente en un sitio Web sea completado sin ningn
error o de lo contrario los cambios generados por dicho proceso sean
restablecidos en caso de error, permitiendo conservar la integridad de
los datos. El IIS utiliza las Pginas de Servidor Activas o Active Server
Pages (ASP) como lenguaje para generar Scripts los cuales permiten
la implementacin de pginas Web dinmicas de contenido interactivo.
Servicios de Mensajera.
Estos servicios son soportados por el
Microsoft Message Queue Server o MSMQ, encargado de proveer

mecanismos de comunicacin a travs de la red basado en un modelo
de colas de mensajera e inclusive con la interoperabilidad con otros
productos.
287
Servicios de Componentes. El Microsoft Transaction Server o MTS es

una utilidad que proporciona servicios para el desarrollo, implementacin
y administracin de aplicaciones distribuidas basadas en componentes.
El MTS administra todo lo relacionado con la reutilizacin de
componentes, manejo de transacciones y conexiones a bases de datos
realizadas desde los componentes. Todos los componentes utilizados por
el MTS son creados bajo los parmetros de COM (Component Object
Model).
Capa de Datos
Se encarga del almacenamiento y manejo de los datos. Estas funciones
son responsabilidad de uno o varios motores de bases de datos.
El
Acceso Universal a Datos o Universal Data Access (UDA) proporciona

acceso de alto desempeo a variadas fuentes de informacin incluyendo
datos relacionales y no relacionales.
Igualmente proporciona unas
interfaces de programacin de fcil uso, independientes de los lenguajes

de programacin. UDA est basado en especificaciones abiertas de modo
que la mayora de sistemas de bases de datos pueden utilizarlo.
288
Figura 99. Capa de datos.
Componentes y Cooperacin entre Componentes

Un componente es una unidad discreta de cdigo construida con la
tecnologa ActiveX que define una serie de servicios o funcionalidad
especfica. Los componentes pueden ser de diferentes tipos y segn se
ubiquen en cualquiera de las capas reciben nombres diferentes en la
arquitectura DNA. As los componentes ubicados lgicamente en la capa
de negocios se les conoce como objetos de negocios, construidos como
componentes ActiveX, mientras que los que estn ubicados lgicamente
en la capa de presentacin pueden estar implementados como
Documentos Activex o como Controles ActiveX.
La cooperacin o interoperabilidad entre componentes se basa en la
especificacin conocida como COM o Component Object Model, la cual
define una serie de estndares que permiten la comunicacin entre
289
objetos que la soportan. COM es el corazn de la arquitectura Windows

DNA ya que permite la integracin, la comunicacin entre objetos, el
acceso a una amplia variedad de clientes permitiendo hacer aplicaciones
con un mayor alcance y promoviendo la escalabilidad.
COM provee una definicin estndar de cmo ciertos objetos se pueden
comunicar y compartir informacin. COM se caracteriza principalmente
por ser Independiente del lenguaje, Independiente del sistema operativo y
Capaz de trabajar con objetos en servidores remotos a travs de una red.
COM permite que diferentes componentes en diversos lenguajes de
programacin y que corran en diferentes sistemas operativos, interacten
con un mismo propsito en el mbito de una misma aplicacin, e
igualmente permite hacer llamados a objetos remotos a travs de DCOM
o Distribuited COM.
DCOM es un protocolo que permite que los componentes software se
comuniquen directamente en una red de una manera confiable, segura y
eficiente. Est diseado para soportar diversos transportes de red lo cual
lo hace compatible con casi todos los sistemas operativos y protocolos.
12.4.3 Diseo de interfaz
El diseo est basado en las lneas y formas de construccin del logotipo,

este se forma a partir de una circunferencia en la que estn inscritas las tres
iniciales, manteniendo la curva en los bordes superior e inferior y eliminada a
los 2 lados hallando un punto medio entre el recto de las 2 primeras letras
(UI) y lo curvo de la tercera (S), estos elementos han servido como
referencia.
290
Se utilizan los conceptos como limpieza visual, facilidad de navegacin,

rpida accesibilidad, que sirven como referencia para la pgina inicial del
Web de la UIS.
12.4.4 Diseo procedimental.
El diseo procedimental de las bsquedas en el sistema se realiz basado

en la teora de conjuntos, especialmente utilizando la propiedad de la
interseccin. La utilizacin de la teora es la siguiente:
Un conjunto es la reunin en un todo de objetos bien definidos y
diferenciables entre si, que se llaman elementos del mismo. Los objetos que
forman al conjunto son nombrados elementos del conjunto o miembros del
conjunto.
Todo conjunto es una coleccin de objetos, pero no toda
coleccin de objetos es un conjunto. Esta afirmacin ser demostrada ms

adelante.
La Teora de Conjuntos es una teora matemtica, que estudia bsicamente
a un cierto tipo de objetos llamados conjuntos y algunas veces, a otros
objetos denominados no conjuntos, as como a los problemas relacionados
con estos.
Intuitiva e informalmente los objetos de estudio de la Teora de Conjuntos
quedan descritos de la siguiente manera:
1. Si x no tiene elementos, entonces x es un objeto de la Teora de
Conjuntos.
2. Si x es un conjunto, entonces x es un objeto de la Teora de
Conjuntos.
3. Los nicos objetos de la Teora de Conjuntos son los descritos en 1 y
2.
291
Relacin de Pertenencia: El ser elemento de es una relacin binaria o de

dos argumentos entre dos objetos de la Teora de Conjuntos. Esta relacin
va de un objeto a otro, donde el segundo objeto es necesariamente un
conjunto y el primero puede ser o no un conjunto.
Se dice que A est contenido en B (tambin que A es un subconjunto de B
o que A es una parte de B),
y se denota A B, si todo elemento de A lo es
tambin de B, es decir, a A a B.
Interseccin:
Se dice de dos conjuntos A y B al conjunto formado por objetos que son
elementos de A y de B, es decir: A B := {x | x A x B}.
Para explicar la interseccin se utiliza la lgica matemtica que dice lo
siguiente:
La lgica matemtica es la disciplina que trata de mtodos de razonamiento.
En un nivel elemental, la lgica proporciona reglas y tcnicas para determinar
si es o no valido un argumento dado. El razonamiento lgico se emplea en
matemticas para demostrar teoremas; ciertamente se usa en forma
constante el razonamiento lgico para realizar cualquier actividad.
Una proposicin o enunciado es una oracin que puede ser falsa o
verdadera pero no ambas a la vez. La proposicin es un elemento
fundamental de la lgica matemtica.
Para el proyecto un proposicin ser descrita como una palabra que es
buscada. Por ejemplo: calculo integral
Proposicin uno (P): calculo
Proposicin dos (Q): integral

292
La tabla de verdad de interseccin para las dos proposicin es la siguiente:

Tabla 44. Tabla de verdad para interseccin.
P
1
1
0
0
Q
1
0
1
0
P Q
1
0
0
0
Unin
Se dice unin de dos conjuntos A y B al conjunto formado por objetos que
son elementos de A o de B, es decir: A B := { x | x A x B}.
Utilizando el ejemplo anterior, la tabla de verdad seria la siguiente:
Tabla 45. Tabla de verdad unin.
P
1
1
0
0
Q
1
0
1
0
P Q
1
1
1
0
Debido a que en la unin se tienen muchas opciones verdaderas, no se

utilizo en el diseo procedimental del sistema, para garantizar que el tiempo
de respuesta en las bsquedas sea corto.
12.5 SELECCIN DE HARDWARE Y SOFTWARE
La seleccin del hardware se realiz basada en la infraestructura existente

en la Divisin de Servicios de Informacin de la Universidad Industrial de
Santander.
293
Servidor SILICON GRAPHICS modelo ORIGIN-2000, servidor de Base de

Datos y tiene la siguiente configuracin:
4 procesadores RISC de 64 bits MIPS R12000 a 300 Mhz
8,64 MB de memoria cache por procesador.
4,32 GB de memoria RAM.
52 GB en disco.
Controlador de dispositivos Ultra SCSI.
Interfase de red FastEthernet.
2 unidades de cinta DAT 4 mm 12/24 GB.
Servidor DELL Intranet DELL Poweredge 600SC.
Un procesador pentium 4 de 1,8 Ghz.
1 MB de memoria cache.
2 GB de memoria RAM.
40 GB en disco.
Controlador de dispositivos Ultra SCSI.
Interfaz de red Intel 10/100.
La seleccin del software fue realizada principalmente en la experiencia con

que contaban los desarrolladores del equipo de trabajo, el tiempo que se
necesitara para codificar todo el sitio Web, y las licencias del software que
ya han sido adquiridas por parte de la Divisin de Servicios de Informacin.
El lenguaje seleccionado fue active server pages (asp) con los scripts en
javascript para el rendimiento de cada pagina. El software para desarrollar
las paginas es Visual Interdev 6.0. El software para desarrollar las libreras
dinmicas (dll) es Visual Basic 6.0.
Los procedimientos almacenados se
realizaran en el editor de informix.

294
12.6 CONSTRUCCIN DE PROTOTIPOS
La bsqueda simple esta conformada por un cuadro de texto y un botn

llamado consultar, el usuario puede digitar solamente como mximo cuatro
palabras en el cuadro de texto. Las formas de realizar las consultas permiten
que el usuario pueda utilizar los espacios en blanco para varias palabras, las
tildes y la letra . Los resultados que arroja el sistema se dan teniendo en
cuenta todos los parmetros permitidos de consulta (Autor, Titulo, Materia,
Libro, Tesis, Revistas, Analtica, ISSN o ISBN y ao)
Figura 100. Prototipo bsqueda simple.
295
La bsqueda avanzada cuenta con cuatro cuadros de texto donde el usuario

digita las palabras clave por las que quiere buscar y cuatro listas donde cada
una tiene los siguientes criterios de bsqueda (Autor, Ttulo, Materia, Libro,
Tesis, Revista, Analtica, ISBN, ISSN, Ao). El usuario digita una palabra y al
frente en la lista debe especificar cual es el tipo de palabra segn los criterios
Figura 101. Prototipo bsqueda avanzada.
Este listado contiene los resultados de la consulta que el usuario realiza. Los
datos que se muestran como resultado de la consulta, son los datos ms
generales de los documentos y son:
El ttulo.
El tipo de documento y el autor.
El ao de publicacin.
296
La lista general contiene unas casillas de verificacin, las cuales permiten

seleccionar los registros que el usuario desee guardar. En la parte superior
se encuentran los botones de guardar (se usan para guardar las referencias
seleccionadas), ver listado (para ver la lista previa de referencias guardadas),
subconsulta y siguientes registros. Cada registro tiene un enlace para ver los
detalles del material.
Figura 102. Prototipo listado de resultados.
12.6.4 Subconsulta
La subconsulta contiene dos cuadros de texto, el primero muestra la

informacin de la consulta realizada anteriormente y no se puede modificar y
297
el segundo donde el usuario puede introducir los nuevos parmetros de

consulta.
Desde el listado general se puede realizar la subconsulta, cuya finalidad es
filtrar la informacin para obtener resultados ms precisos, por ejemplo: La
primera consulta, la puede realizar para obtener un listado con todos los
libros de un autor, y la subconsulta la realiza para obtener de ese listado slo
las publicaciones de un cierto ao. Las formas de realizar las subconsultas
utilizan las mismas limitaciones de la bsqueda simple.
Figura 103. Prototipo subconsulta.
12.6.5 Ver Detalles
Ver detalles presenta tres secciones de informacin a mostrar, la primera

seccin Informacin del Documento, muestra los detalles ms generales del
documento, como: Tipo de documento, Ttulo (principal), Autor (principal),
Edicin, rea de publicacin, y descripcin fsica. La segunda seccin
Informacin de los ejemplares, muestra los ejemplares que existen de ese
documento con la informacin de: Nmero del ejemplar, Nmero de
inventario, ubicacin, estado, fecha de devolucin (si el estado es prestado) y
298
descripcin. Y la tercera seccin Otra informacin presenta todos los ttulos,

todos los autores y todas las materias que pertenece ese material.
Desde ver detalles tambin puede ir a ver resumen, ver detalles tipo MARC y
guardar referencia.
Figura 104. Prototipo ver detalles.
La lista previa de referencias se hace para que el usuario observe la lista de

referencias que ha venido guardando durante la sesin de consulta.
299
Muestra un ndice, un cuadro para marcar y la informacin ms general del

material como lo es el ttulo, autor, ao, ubicacin, nmero de clasificacin y
el estado.
El usuario cuenta con la posibilidad de actualizar la lista cuantas veces
quiera, seleccionando el cuadro de la referencia que desea borrar y luego
oprimiendo el botn de borrar referencias seleccionadas, o puede regresar a
la pgina anterior, continuar navegando y grabando ms referencias.
Tambin tiene la posibilidad de enviar la lista a una cuenta de correo
electrnico o a un pantallazo para imprimir en una impresora.
La pgina valida que la direccin escrita sea correcta y lo enva a una nueva
ventana de confirmacin.
Estas dos actividades no se pueden realizar
simultneamente, aunque si se pueden utilizar cuantas veces el usuario lo

necesite.
Figura 105. Prototipo lista previa de referencias.

El usuario tiene la posibilidad de enviar la lista de referencias a una cuenta

de correo electrnico, seleccionado la opcin Enviar por e-mail y digitando
una direccin de vlida.
300
Figura 106. Prototipo enviar referencia por e-mail.

Despus del envo se muestra una ventana de confirmacin, y se da la
opcin enviar a otras direcciones de correo electrnico o regresar al listado.
Figura 107. Prototipo confirmacin envo de e-mail.

La otra opcin que tiene el usuario con el listado de referencias es poderlas

imprimir. El usuario debe seleccionar Imprimir en pantalla y oprimir el botn
enviar.
301
Figura 108. Prototipo imprimir referencias.

El sistema muestra el listado en la forma como se imprimir y el usuario slo
tiene que oprimir el botn imprimir.
Figura 109. Prototipo ventana de impresin.
Detalles MARC presenta una vista de la informacin de la descripcin

general del material en formato MARC. El formato MARC es un estndar
para la representacin y la comunicacin de la informacin bibliogrfica. En
la parte superior se encuentra el botn volver al registro, que lo lleva
directamente a la vista normal de los detalles generales.
302
Figura 110. Prototipo detalles MARC.
12.6.10
Resumen
Contiene el ttulo y los autores del documento de trabajo de grado con su

respectivo resumen.
303
Figura 111. Prototipo resumen.
12.7 DISEAR EL PLAN DE PRUEBAS
304
Tabla 46. Pruebas de Caja Blanca.
305
Tabla 46. Pruebas de Caja Blanca (Continuacin).
306
Tabla 46. Pruebas de Caja Blanca (Continuacin).
307
Tabla 47. Pruebas de Caja Negra.
308
Tabla 48. Pruebas de entornos y aplicaciones especializadas.
309
Tabla 48. Pruebas de entornos y aplicaciones especializadas (Continuacin)
310
Tabla 48. Pruebas de entornos y aplicaciones especializadas (Continuacin)
311
12.8 VERIFICAR QUE LOS PROTOTIPOS CUMPLAN CON LOS

REQUERIMIENTOS
Se comprob que cada caso de uso se satisface con los prototipos
presentados.
Justificacin y desarrollo de los pasos de la metodologa de desarrollo

de software seleccionada.
Formato de documentacin seleccionado.
Cuadro de seguridad.
Integracin del sistema (si aplica).
Seleccin del hardware y software.
Prototipos.
Plan de pruebas.
312
13. FASE DESARROLLAR
13.1 ORGANIZACIN DEL CODIGO FUENTE
El sitio Web slo tiene un nivel, aunque las imgenes se ubican en una
carpeta nica.
/ (Biblioteca)
Pginas ..asp
IMAGENES
Archivos .jpeg
Figura 112. rbol de organizacin del cdigo fuente.

La librera tambin tiene un slo nivel
/ Biblioteca
Archivos .dll
Figura 113. rbol de organizacin de las libreras.
313
13.2 CONSTRUCCIN
La bsqueda simple est conformada por un cuadro de texto y un botn

llamado consultar, el usuario puede digitar como mximo solo cuatro
palabras en el cuadro.
Las formas de realizar las consultas permiten que el usuario pueda utilizar los
espacios en blanco para varias palabras, las tildes y la letra .
Figura 114. Construccin, Bsqueda simple.

Tiene en la parte superior de la pgina la barra estndar que se tiene el sitio
Web de la universidad, y tiene el acceso a la Intranet de la Universidad.
Tambin tiene dos botones regresar y ayuda. Regresar lo enva a la pagina
anterior desde donde hizo el acceso si el usuario ingreso directamente al
314
catlogo bibliogrfico no regresar a ningn lado, el botn de ayuda lleva al

usuario la ayuda que tiene el sistema.
La bsqueda avanzada cuenta con cuatro cuadros de texto donde el usuario

digita las palabras clave por las que quiere buscar y cuatro listas donde cada
lista tiene los siguientes criterios de bsqueda (Autor, Ttulo, Materia, Libro,
Tesis, Revista, Analtica, ISBN, ISSN, Ao). El usuario digita una palabra y al
frente en la lista debe especificar que es la palabra segn los criterios.
Figura 115. Construccin, Bsqueda avanzada.

Tiene en la parte superior de la pgina la barra estndar que se tiene el sitio
Web de la universidad, y tiene el acceso a la Intranet de la Universidad.
Tambin tiene dos botones regresar y ayuda. Regresar lo enva a la pgina
anterior desde donde hizo el acceso si el usuario ingres directamente al
315
catlogo bibliogrfico no regresar a ningn lado, el botn de ayuda lleva a el

usuario la ayuda que tiene el sistema.
Este listado contiene los resultados de la consulta que el usuario realiza. Los
datos que se muestran como resultado de la consulta, son los datos mas
generales de los documentos y son:
El ttulo.
El tipo de documento y el autor.
El ao de publicacin.
La lista general contiene unas casillas de verificacin en cada registro, las

cuales permiten seleccionar los registros que el usuario desee guardar. En la
parte superior se encuentran los botones de guardar (se usan para guardar
las referencias seleccionadas), ver listado (para ver la lista previa de
referencias guardadas), subconsulta y siguientes registros.
tiene un enlace para ver los detalles del material.
316
Cada registro
Figura 116. Construccin, Listado de resultados.
13.2.4 Subconsulta
La subconsulta contiene dos cuadros de texto, el primero muestra la

informacin de la consulta realizada anteriormente y no se puede modificar y
el segundo donde el usuario puede introducir los siguientes parmetros de
consulta.
Desde el listado general se puede realizar la subconsulta, cuya finalidad es
filtrar la informacin para obtener resultados ms precisos, por ejemplo: La
primera consulta, la puede realizar para obtener un listado con todos los
libros de un autor, y la subconsulta la realiza para obtener de ese listado solo
las publicaciones de un cierto ao. Las formas de realizar las subconsultas
utilizan los mismos parmetros de la consulta.
317
Figura 117. Construccin, Subconsulta.
13.2.5 Ver Detalles
Ver detalles presenta tres secciones de informacin a mostrar, la primera

seccin Informacin del Documento, muestra los detalles ms generales del
documento, como: Tipo de documento, Ttulo (principal), Autor (principal),
Edicin, rea de publicacin, y descripcin fsica. La segunda seccin
Informacin de los ejemplares, muestra los ejemplares que existen de ese
documento con la informacin de: Nmero del ejemplar, Nmero de
inventario, ubicacin, estado, fecha de devolucin (si el estado es prestado) y
descripcin. Y la tercera seccin Otra informacin presenta todos los ttulos,
todos los autores y todas las materias a las que hace parte ese material.
Desde ver detalles tambin puede ir a ver resumen, ver detalles tipo MARC y
guardar referencia.
318
Figura 118. Construccin, Ver detalles.
La lista previa de referencias se hace para que el usuario observe la lista de

referencias que ha venido guardando durante la sesin de consulta.
Muestra un ndice, un cuadro para marcar y la informacin ms general del
material como lo es el ttulo, autor, ao, ubicacin, nmero de clasificacin y
el estado.
319
Figura 119. Construccin, Listado de referencias.

El usuario cuenta con la posibilidad de actualizar la lista cuantas veces
quiera, seleccionando el cuadro de la referencia que desea borrar y luego
oprimiendo el botn de borrar referencias seleccionadas, o puede regresar a
la pgina anterior, continuar navegando y grabando ms referencias.
320
Figura 120. Construccin, Modificacin de lista previa de referencias.
Figura 121. Construccin, Lista modificada de referencias.
321
Tambin tiene las posibilidades de enviar la lista a una cuenta de correo

electrnico o de visualizar en pantalla para imprimir en una impresora.
La pgina valida que la direccin escrita sea correcta y lo enva a una
ventana de confirmacin.
Estas dos actividades no se pueden realizar
simultneamente, aunque si se pueden utilizar cuantas veces el usuario lo

necesite.
El usuario tiene la posibilidad de enviar la lista de referencias a una cuenta

de correo electrnico, seleccionado la opcin Enviar por e-mail y digitando
una direccin vlida.
Figura 122. Construccin, Envo de referencias por e-mail.

Despus del envo se muestra una ventana de confirmacin, y se da la
opcin enviar a otras direcciones de correo electrnico o regresar al listado.
322
Figura 123. Construccin, Confirmacin envo de referencias por e-mail.
La otra opcin que tiene el usuario con el listado de referencias es poderlas

imprimir en papel.
El usuario debe seleccionar Imprimir en pantalla y
oprimir el botn enviar.
323
Figura 124. Construccin, Imprimir referencias.

El sistema muestra el listado en la forma como se imprimir, el usuario slo
tiene que oprimir el botn imprimir.
Figura 125. Construccin, Ventana de impresin.
324
Detalles MARC presenta una vista de la informacin de la descripcin

general del material en formato MARC. El formato MARC es un estndar
para la representacin y la comunicacin de la informacin bibliogrfica. En
la parte superior se encuentra el botn volver al registro, que lo lleva
directamente a la vista normal de los detalles generales.
Figura 126. Construccin, Detalles MARC.
13.2.10
Resumen
Contiene el ttulo y los autores del documento de trabajo de grado con su

respectivo resumen.
325
Figura 127. Construccin, Resumen.
326
14. CONCLUSIONES
El modelo DMADDV de seis sigma, planteado para la Divisin de

Servicios de Informacin indica que los mayores esfuerzos en cualquier
proyecto no consisten en encontrar la mejor solucin, si no, en encontrar
el problema indicado.
Segn lo anterior se debe romper el paradigma que actualmente los

ingenieros tienen de invertir la mayor parte de los esfuerzos en encontrar
la mejor solucin al inicio del proyecto, en lugar de invertir la mayor parte
de los esfuerzos en encontrar el problema correcto.
Cambiar la forma de plantear los objetivos especficos de una frase con

solo palabras, a una de manera medible utilizando nmeros, ofrece a la
organizacin saber con exactitud si se cumplieron los objetivos del
proyecto propuestos y si ste concluye con xito o fracasa.
La idea central de Seis Sigma es que si puede descubrir como medir los
defectos en un proceso, sistemticamente se puede encontrar como
eliminarlos y llevarlo tan cercano como se pueda a cero defectos .
Desarrollar proyectos basados en hechos y enfocados en lo que quiere el

cliente y no en lo que se cree que el cliente quiere, brinda la mayor
confianza a las directivas de la Divisin de Servicios de Informacin, de
realizar lo que realmente se debe realizar, con un fundamento en
mediciones estadsticas.
327
Reducir los costos por tiempo que se invierte en corregir programas es un

factor que genera un valor agregado para cada organizacin.
La utilizacin de la estadstica es una herramienta valiosa para identificar

la situacin actual del proceso, el calculo de las medidas, la proyeccin
de las medidas durante y despus del proyecto.
La utilizacin del modelo de Kano para la clasificacin de requerimientos

brinda a lderes del proyecto una forma ms clara de entender lo que el
sistema debe realizar, especificando claramente que requerimientos se
deben hacer, cuales son indispensables pero que el cliente pasa
desapercibido, y cuales generaran un impacto bueno en la satisfaccin
del cliente.
Dentro del modelo existen diferentes formas de hacer las cosas, lo ms

importante es que se pueda encontrar la ms adecuada segn el
problema que se vaya a solucionar y que no se deje de realizar algn
paso dentro de las fases.
El proceso personal del software, es un poderoso complemento con la

metodologa Seis Sigma, ya que sus finalidades son muy parecidas
resultados casi perfectos. Adems PSP con sus herramientas, brinda a
los desarrolladores individuales la forma de mejorar su rendimiento
personal a la hora realizar su trabajo.
328
15. RECOMENDACIONES
Continuar trabajando en el mejoramiento del modelo DMADDV planteado

para la Divisin de Servicios de Informacin, donde se acomode mucho
ms a la cultura organizacional de sta dependencia.
Utilizar el modelo DMADDV inicialmente para los proyectos de desarrollo

de software que se realicen en la Divisin de servicios de informacin y
que sean realizados por estudiantes en modalidad de prctica
empresarial. Y progresivamente a los dems tipos de proyectos.
Crear el rol de Master Black Belt dentro de la divisin de servicios de

informacin para que sirva de apoyo a todos los proyectos de desarrollo
de software con la metodologa DMADDV, que se realicen a partir del
momento en que se decida implantarse el modelo.
Generar un alto grado de compromiso de la alta direccin en la Divisin

de Servicios de Informacin para la utilizacin de la metodologa,
logrando as un mayor apoyo con cualquier miembro de esta.
Utilizar la herramienta QFD para la priorizacin de requerimientos, como

indispensable en cualquier tipo de proyecto,
sin importar que sea en
forma complementaria.
Utilizar el AMFE, para determinar los riesgos que se pueden presentar en

el proyecto antes y despus de su implantacin, y manejar la
administracin de riesgos lo mejor posible durante el proyecto.
329
Crear un espacio definido para todo el personal de la Divisin de

Servicios de Informacin donde se presenten capacitaciones de
diferentes tipos, como por ejemplo, diseo, hardware, software.
330
BIBLIOGRAFA
JACOBSON, Ivar BOOCH, Grady - RUMBAUGH, James. El Proceso

Unificado
de
Desarrollo
de
Software.
Editorial
Addison
Wesley
Iberoamericana. Madrid, 2000.

___________ El Lenguaje Unificado de Modelado. Editorial Addison Wesley
Iberoamericana Madrid, 1999.
PRESSMAN, Roger S. Ingeniera del software un enfoque prctico. Editorial
McGraw Hill. Cuarta Edicin. Espaa. 1.998.
TAYNTOR, Christine B. Six Sigma Software Development.
Auerbach
Publications. USA, 2003.

PANDE, Peter S. NEUMAN, Robert P. CAVANAGH, Roland R. Las
Claves de Seis Sigma. Editorial McGraw Hill. Edicin en espaol , traducido
de la primera versin en espaol de The Six Sigma Way.
BRUE, Greg. Seis Sigma para directivos. Editorial McGraw Hill. Edicin en
espaol, traducido de la primera edicin en ingls de Six sigma for
Managers.
LOWENTHAL, Jefrey N. Six Sigma Project Management: A Pocket Guide.
ASQ Quality Press publications, Wisconsin. 2002.
331
CHOWDHURY, Subir. The Power of Six Sigma. Editorial Dearborn Trade.

USA. 2001
HARRY, Mikel SCHROEDER, Richard. Six Sigma: The Breakthrough
Management Strategy Revolutionizing the Worlds Top Corporations. Editorial
Currency. New York. 2000.
FALKNER, Jayson GALBRAITH, Ben IRANI, Romin KOCHMER, Casey
KUNNUMPURATH, Meeraj PANDURANGA, Sathya PERRUMAL,
Krishnaraj TIMNEY, John. Beginning ASP Web Development. Wrox Press
LTD. USA. 2001.
EDWIN RAMON SUAREZ ALVAREZ.
Proyecto de Grado Sistema de
informacin Intranet-Extranet para la seccional de la Universidad Industrial de

Santander en Barrancabermeja
332
BIBLIOGRAFA EN INTERNET
http://www.ge.com/sixsigma: Este es el sitio de General Electric, una de las

principales compaas Seis Sigma del momento.
http://www.isixsigma.com. Este sitio esta dedicado a dar soporte a todos los
practicantes de la metodologa Seis Sigma.
http://www.seissigma.com. Este sitio es un complemento terico de Seis
Sigma.
http://www.sei.cmu.edu. Este es el sitio de Software Engineering Institute y
contiene informacin sobre ingeniera del Software.
http://www.pmi.org. Este es el sitio de Project Management Institute y
contiene informacin adicional sobre Project Management.
http://www.construx.com/survivalguide. Este sitio web es un complemento del
libro Software Project Survival Guide de Steve McConnell (Microsoft Press,
1998)
333
ANEXO A. Cuadro resumen de proyecto
A continuacin se describen las secciones que contiene el modelo del cuadro

resumen de proyecto y la descripcin de los campos que se deben llenar en
cada una.
Seccin descripcin del proyecto
Fecha de inicio: Es la fecha en la que se da inicio al proyecto, puede ser
la fecha en la que se convoca al equipo de trabajo o la fecha del primer
encuentro.
Fecha estimada fin: La fecha en que planea que las fases sean
completadas.
Ttulo del proyecto: debe ser claro y visualizar rpidamente el proyecto.
Definicin del Problema: Mencionar una breve descripcin del proyecto
(problemas a tratar). Tratar de mantener un problema por proyecto. As
las cosas son menos complicadas y se ejecutan ms rpido!!!
Declaracin de los objetivos: Despus de haberse mencionado el
problema, se plantean los objetivos.
Seccin beneficios
El propsito de esta seccin es cuantificar los beneficios proyectados en el
proyecto. En el modelo se mencionan algunos, como el nivel sigma, COPQ
y satisfaccin del cliente, aunque se pueden describir otros beneficios.
69
COQP: Cost of Poor Quality, Costo por Mala Calidad
334
69
Unidades: A excepcin del nivel sigma, todas las entradas en beneficios

deben tener una unidad de medida especfica, por ejemplo en COPQ las
unidades pueden ser porcentaje, mientras que satisfaccin del cliente se
puede dar en una escala del 1 al 5.
Medida Actual: Se da entrada al nivel actual en cada tem.
Meta: El nivel que se proyecta alcanzar en cada uno de los tems.
Fecha proyectada: la fecha en la que se proyecta se alcance el
beneficio.
Seccin miembros del equipo
El cuadro de Proyecto puede contener tambin la lista de personas
implicadas en el proyecto, incluyendo a los miembros del equipo, al personal
de soporte y consultora as como al patrocinador del proyecto.
Nombre: El nombre de cada uno de los miembros del equipo
Rol: El papel que juega dentro del equipo.
Departamento: La dependencia a la que pertenece.
% Tiempo: El porcentaje de tiempo que se espera cada miembro del
equipo invierta en el proyecto.
Seccin cronograma
Esta seccin sirve en gran escala como un plan de proyecto, mostrando los
datos en donde cada fase del DMADDV planea ser completada. Proyectos
largos suelen dividir las fases en fases mas pequeas y tambin documentan
las fechas planeadas de finalizacin.
Entregables: El nombre de la fase o entregable a seguir.
Fecha Inicio: La fecha en la que se da inicio a la fase.
Fecha Fin: La fecha en la que se espera se complete la fase.
335
Responsables: La persona que tiene la responsabilidad sobre la fase.

No siempre tiene que ser el lder del equipo.
Comentarios: Donde se indica si se ha completado satisfactoriamente
cada fase o si es necesario cambiar la fecha de fin.
Se establecen las fechas de presentar la fase al comit de proyecto, donde
se evalan y se da el visto bueno para seguir a la siguiente fase.
Seccin de aprobaciones
Rol/Ttulo: Es desarrollado por un grupo seleccionado o por el comit de
proyectos
Nombre: Se escribe el nombre del funcionario.
Fecha: La fecha en la que el funcionario aprob el cuadro de proyecto.
Seccin revisiones
Revisin nmero: El numero de revisin, normalmente es secuencial.
Autor: Los nombres de las personas que a la fecha han revisado el
documento.
Fecha: La fecha en la que se hace la revisin.
336
Tabla 49. Cuadro resumen proyecto.

CUADRO RESUMEN DE PROYECTO
Descripcin del Proyecto
Fecha Inicio:
Fecha estimada fin:
Ttulo del Proyecto:

Definicin
del
Problema:
Declaracin de los
objetivos
Beneficios
Unidades
Medida Actual
Meta
Fecha
proyectada
Nivel sigma
COPQ
Satisfaccin del cliente
Otro:___________________
Miembros del Equipo
Rol
Nombre
Entregables
Fase Definir
Fase Medir
Fase Analizar
Fase Disear
Fase Desarrollar
Fase Verificar
Fecha inicio
Cronograma
Fecha Fin
Departamento
Responsables
% Tiempo
Comentarios
Aprobaciones
Rol/Ttulo
Nombre
Fecha
Revisiones
Revisin nmero
Autor
337
Fecha
ANEXO B. Tcnicas para capturar la voz del cliente.

Tabla 50. Mtodos para capturar la VOC.
Tiempo de
recoleccin
de datos
Datos
Encuesta
telefnica.
2 semanas
Cuantificable
(objetiva)
Alto
Encuesta por
correo
electrnico.
Meses
Cuantificable
(objetiva)
Bajo
Mtodo
Dirigirse a
Grupos en
persona.
Dirigirse a
grupos en
lnea.
Un da
Un da
Costo
Cualitativo
(subjetivo)
Cualitativo
(subjetivo)
Ventajas
Si los datos son
correctos, se
aplican a una
poblacin grande.
Bajo costo, los
datos se puede
generalizar a
poblaciones
grandes.
Bajomedio
Puede ser
personalizado, es
una oportunidad
para profundizar
en las respuestas.
Se pueden usar
ayudas visuales.
Bajo
Puede ser
personalizado. No
requiere de viajes
en la movilidad de
participantes,
ayudas visuales
pueden ser
utilizadas.
Entrevistas
uno a uno.
Varios das
Cualitativo
(subjetivo)
Bajo
Puede ser
personalizado.
Oportunidad para
profundizar en
algunas
respuestas.
Ayudas visuales
pueden ser
utilizadas.
Intercepciones.
Varios das
Ambos
Medio
Bajo especificas
circunstancias, los
datos pueden ser
338
Desventajas
Rgido, y poca
flexibilidad.
Demoras en
obtener
respuesta.
No se puede
generalizar a
grandes poblaciones, las
respuestas
profesionales por
unos pocos se
convierten en
riesgo. Movilidad
de asistentes.
No se puede
generalizar a
grandes
poblaciones.
Dificultad en
grupos de mayor
edad.
Entrevistas
desordenadas y
falta de seriedad,
genera poca
colaboracin para
recolectar datos,
requieren mucha
movilidad de los
entrevistadores.
Se pierde el beneficio de la
discusin en
grupo.
No se puede
generalizar a
poblaciones
cuantifica-dos a
una limitada
poblacin. Ayudas
visuales pueden
ser utilizadas.
Pruebas a
usuarios.
Un mes
Ambos
Medio
Provee amistad
con los usuarios.
Quejas de los
clientes.
Varios
Meses
Cualitativos
(subjetivo)
Bajo
Provee entradas
especficas.
Benchmarking.
Un Mes
Cualitativos
Medio
Data
warehousing.
Varios
meses
Cuantitativos
Alto
Data mining.
Varios
Meses
Ambos
Medio
339
Compara nuestros
procesos con los
procesos de los
mejores
competidores.
Grandes
volmenes de
datos histricos
acerca del
negocio.
Anlisis de datos
con relaciones
ocultas.
grandes.
Apropiado para
pocos tpicos.
No es adecuado
para la
investigacin.
Apropiado para
pocos tpicos.
No se puede
generalizar.
Apropiado para
pocos tpicos.
Los procesos no
se pueden
implantar en
cualquier
organizacin.
Necesita de
tiempo para
recolectar una
cantidad
suficiente de
datos.
Necesidad de
tiempo para
recolectar una
suficiente
cantidad de datos.
ANEXO C. Captura de Requisitos con UML.

Para guiar la captura de requisitos del sistema, se establece el siguiente flujo
de trabajo:
1. Comprender el contexto del sistema.
En proyectos de desarrollo de software se encuentran implicados
diferentes
roles
de
personas
que
tienen
asignadas
diferentes
responsabilidades. Cada uno de ellos debe tener un conocimiento claro

acerca del negocio en que se encuentra y en como el sistema va a ser
parte de l.
Los mtodos que se utilizan para el entendimiento de la situacin son
explicados ms a fondo en el paso de Definicin del problema. Cuando
el modelo es entendido y se convierte manejable por los miembros del
equipo de trabajo, la comunicacin con los clientes se hace fluida y sin
obstculos.
2. Crear un borrador de la definicin de requisitos.
Durante el transcurso del proyecto los clientes, usuarios, analistas y
desarrolladores van entendiendo mejor el contexto del sistema y su
entorno;
con una comprensin de alto nivel por parte de los
desarrolladores, la cual los hace generar una gran cantidad de ideas

acerca de que debera tener el sistema. Crear una lista de estas ideas
puede mantener el proyecto bajo control, ya que muchas de estas ideas
340
se caracterizan como algo bueno por tener y otras algo indispensable

70
a tener .
71
La lista se convierte en un fundamento indispensable para la

planificacin, transformndose en requisitos, y despus en casos de uso.
Cada caracterstica debe poseer ciertos atributos con los cuales los
miembros del equipo se basaran para planificar el trabajo, tomar
decisiones y clasificarlas.
Nombre.
Descripcin o Definicin.
Breve justificacin.
Coste estimado de implementacin.
Prioridad.
3. Capturar los requisitos funcionales.

En la definicin de requisitos del sistema, cada cliente se encuentra en la
posicin de que el sistema realice lo que el quiere que haga. En esta lista
de requisitos encontramos dos tipos, los funcionales y los no funcionales;
de modo que los miembros del equipo encargados de esta tarea deben
estar preparados con fundamentos para identificar cuales son funcionales
y cuales no. En el momento que los analistas puedan representar los
requisitos mediante casos de uso y se encuentren con la capacidad de
describir cada caso de uso, entonces saben lo que debe hacer el sistema.
Por otro lado, los clientes tienen demasiadas tareas que desearan que el
sistema hiciera por ellos, por lo tanto, la voz del cliente juega un papel
72
70
71
Algo bueno por tener: Siglas en ingles NICE TO HAVE.

Algo indispensable a tener: Siglas en ingles HAVE TO HAVE.
341
muy importante, ya que ayuda a comprender que es realmente necesario

y que no.
4. Capturar los requisitos no funcionales.
Los requisitos no funcionales, son aquellos que no se encuentran
afectando de una manera directa el objetivo principal del sistema,
haciendo referencia a fenmenos del mundo real, que no son realmente
complicados
de
identificar,
como
restricciones
del
entorno,
la
implementacin, el rendimiento, las dependencias de las plataformas,

facilidad de mantenimiento, extensibilidad y fiabilidad.
5. Validar los requisitos.
La validacin incluye cualquier accin que pueda emprender para volver a
comprobar los requisitos y garantizar que reflejan exactamente las
necesidades y expectativas del cliente. Un mtodo puede ser dar a los
clientes un ejemplo basado en los requisitos y luego esperar sus
reacciones o, simplemente preguntarles. Esta validacin puede tambin
incluir una comprobacin con la gente que interviene en el proceso y que
necesitar interpretar y cumplir esos requisitos.
6. Identificar el cliente o usuarios finales.
En el modelo de casos de uso se describe lo que hace el sistema para
cada usuario. Estos usuarios se representan mediante actores . En
73
este caso, usuario, representa al cliente final o a los otros sistemas con
que interacta.
72
Voz del Cliente: Ver anexo B.
73
Actor: El conjunto de roles que los usuarios de casos de uso desempean cuando interaccionan con
estos casos de uso. Fuente libro: El proceso unificado de desarrollo de software UML.
342
Los actores y los casos de uso se identifican para delimitar el sistema de

su entorno y para esbozar quin y que (actores) va a recibir el producto o
servicio e interactuar con el sistema, y que funcionalidad (casos de uso)
se espera.
La identificacin de actores y de casos de uso es la actividad ms
decisiva para obtener adecuadamente los requisitos y es responsabilidad
del analista de sistemas.
Esta actividad incluye 4 pasos:
Encontrar los actores.
El analista de sistemas junto con el cliente identifica los usuarios e
intenta organizarlos en categoras representadas por actores. Para
elegir los candidatos a actores se tienen en cuenta los siguientes
criterios: en primer lugar debe existir al menos un usuario que se
puede representar con un actor, evitando crear actores que no son
necesarios.
El segundo criterio, no deben existir dos actores que
posean un mismo rol, de ser as los actores deben ser generalizados

en un nuevo rol que contenga las caractersticas de los actores que se
repiten.
El analista de sistemas da nombre a los actores y describe
brevemente los papeles de cada uno y para qu utiliza el sistema el
actor.
Encontrar los Casos de uso.
343
Los casos de uso deben ser planteados por los analistas del sistema.
El modelo del negocio juega un papel fundamental ya que de el
surgen muchos casos, en los cuales para cada actor se platea mnimo
un caso de uso.
Despus de el anlisis de los casos de uso, muchos de los que se han
planteado, no llegan a considerarse como un caso uso; sin embargo
se consideran parte de otros, ya que un caso puede invocar a otro y
as sucesivamente. Los casos de uso deben ser lo menos complejos
posibles, donde posean caractersticas de modificar, revisar, probar y
manejar unitariamente.
Describir brevemente cada caso de uso.
Mientras los miembros del equipo trabajan en la identificacin de los
casos de uso, su conocimiento y entendimiento acerca del proceso se
incrementa a un alto nivel, por esta razn, los miembros tienden a
clasificar diferentes asuntos importantes como obvios, y los casos
comienzan a empobrecerse en el detalle, por tal motivo, se debe
proponer una descripcin breve de los pasos y las acciones que el
sistema tiene con los actores.
Describir el modelo de caso de uso completo:
Por medio de una breve descripcin y diagramas se explica como se
relacionan los casos de uso entre s con sus actores.
7. Priorizar los casos de uso.
344
El principio de esta actividad es llevar a cabo una planeacin del

desarrollo en diferentes sentidos, econmico, duracin, recursos, o el
negocio en general.
Cada caso de uso debe tener un identificador que describa el orden en
que se debe desarrollar y el momento de realizarse. Pueden ubicarse en
diferentes
fases
del
proyecto
anlisis,
medicin,
diseo,
implementacin. La fase de verificacin utiliza los casos de uso para

comprobar el rendimiento, y el orden en que se prueba es el mismo orden
que se les ha dado en este punto.
La aprobacin de la priorizacin de los casos de uso, debe ser certificada
por el lder del equipo.
8. Detallar los casos de uso.
Se debe hacer una descripcin del flujo de sucesos de cada caso de uso,
definiendo una secuencia de acciones, incluyendo como comienza,
termina e interactan con los actores. Esta actividad se debe realizar en
conjunto con los usuarios reales de cada caso de uso, para saber que
comprensin tienen sobre este y as poder discutir propuestas con ellos.
La descripcin de un caso de uso puede incluir lo siguiente:
Definir el estado inicial.
Cmo y cuando comienza.
El orden requerido en el que las acciones se deben ejecutar.
Cmo y cuando terminan.
Definicin de los posibles estados finales.
Los caminos de ejecucin que no estn permitidos.
Las descripciones de los caminos alternativos, as como la descripcin
del camino bsico.
345
La interaccin del sistema con los actores y qu cambios producen.

La utilizacin de objetos, valores y recursos del sistema.
La descripcin completa de lo que hace el sistema.
A menudo la interaccin entre los actores y los casos de uso puede
transitar por tantos estados y tantas transiciones alternativas que es casi
imposible mantener consistente la descripcin textual de los casos de
uso. Por tal circunstancia puede ser til utilizar una tcnica de modelado
visual para describir los casos de uso, de esta forma se puede ayudar al
analista de sistemas a mejorar la comprensin de los casos de uso.
Los diagramas que pueden utilizarse son:
Diagramas de estado, para describir los estados de los casos de uso y
las transiciones entre esos estados.
Diagramas de actividad, para describir las transiciones entre estados
con ms detalle como secuencias de acciones.
Diagramas de interaccin, para describir cmo interacta una
instancias de casos de uso con la instancia de un actor.
346
ANEXO D. Anlisis de modos de fallo y efecto.

AMFE
El modelo de AMFE contiene cinco secciones principalmente:

Qu pudo pasar?
Esta seccin describe las posibles causas actuales y los efectos en los
requerimientos del cliente.
Modo de fallo: Describe las formas en que el proceso falla. Si
existen varias se deben listar en filas separadas.
Efectos de la falla: Describe el impacto que tienen las fallas sobre
los requerimientos del cliente.
Intensidad (INT): Cuantifica el impacto de la falla sobre los
requerimientos del cliente. Se recomienda utilizar una escala que
diferencie claramente la prioridad alta, media y baja.
Por qu y con qu frecuencia?
Esta seccin cuantifica las principales causas y la frecuencia con que estas
fallan ocurren.
Principales causas: Lista de las posibles causas de la falla. Si
existen muchas causas se deben listar en filas diferentes.
Frecuencia de Ocurrencia: Cuantifica la frecuencia con que ocurren
estas posibles causas.
Se debe utilizar la escala definida
anteriormente
347
Cmo se puede prevenir?

En esta seccin se describen los procedimientos o los controles que se usan
actualmente para prevenir la falla.
Controles: Describe los procesos que se usan para prevenir o
detectar los modos de fallo.
Probabilidad de fallo: Cuantifica la probabilidad de que el control
que se este utilizando falle. Tambin se usa la escala.
Nmero de Prioridad del Riesgo: Es el resultado de la
multiplicacin de la intensidad, frecuencia de ocurrencia y la
probabilidad de fallo.
NPR = INT * OCU * PROB
Plan de Accin
Describe las acciones que se siguen en la disminucin de los tems con alto
riesgo.
Accin Recomendada: Describe la accin que se toma para
disminuir la frecuencia de ocurrencia y la probabilidad de fallo.
Responsable: Contiene el nombre de la persona responsable
del plan de accin.
Resultado del Plan de Accin
En esta seccin se miden los xitos de cada accin correctiva, recalculando
los campos de intensidad, frecuencia de ocurrencia y el resultado del valor
NPR.
Resultado de la Intensidad (INT): Cuantifica el impacto de la falla
sobre los requerimientos del cliente.
Normalmente no presenta
cambios frente a la accin correctiva. Se calcula usando la escala

definida.
348
Resultado de la Frecuencia de Ocurrencia (OCU): Cuantifica la

frecuencia con la que la posible causa ocurre despus que la
accin correctiva se ha completado.
Resultado de la Probabilidad de Fallo(PROB): Cuantifica la
probabilidad de que los controles fallen despus que se completa
la accin correctiva.
Se cuantifica con la escala definida
anteriormente.
Resultado del NPR: Se calcula nuevamente multiplicando los tres
campos anteriores (INT * OCU * PROB). Si la accin correctiva es
efectiva, este resultado debe ser menos que el obtenido
anteriormente.
349
350
ANEXO E. Formatos utilizados en psp.
REGISTRO DEL TIEMPO

Proyecto / Modulo:
LOC Final:
Nombre:
LOC inicial:
Fecha
Hora
inicio
Hora
final
Tiempo
interrupciones
Delta
Tiempo
351
Actividad
Comentarios
INSTRUCCIONES PARA LLENAR EL FORMATO DE REGISTRO DEL

TIEMPO
Propsito:
El objetivo de este formulario es registrar el tiempo que

gastan los ingenieros programadores en la asignaciones que
se les hace a nivel individual.
Generalidades
El tiempo se registra en minutos, se puede redondear a los 5

minutos ms prximos. Es importante mantener el formulario
siempre a la mano, de tal forma que exista uno siempre
disponible a la hora de comenzar a trabajar y completar el
formulario de una forma limpia y ordenada. No es
recomendable mantener el formato en forma electrnica, a
menos que tenga permiso especial del director del proyecto.
Encabezado
Se digita el nombre y el nombre del proceso o mdulo

asignado para trabajar.
LOC Inicial
Si el trabajo implica un nuevo desarrollo, se digita cero. Si

por el contrario se esta reanudando, modificando o
ampliando un trabajo existente, se deben determinar las
LOC que existen y digitar este nmero ah.
LOC Final
Una vez se termina de desarrollar el mdulo asignado, se

calculan nuevamente las LOC y se digita ese nmero ah.
Fecha
Se digita la fecha en que se realiza la entrada. Si existen

muchas modificaciones en el mismo da, se puede dejar ese
campo en blanco.
Hora Inicio
Se digita el tiempo en que se comienza a trabajar en la

programacin de un mdulo.
Hora final
Se digita el tiempo en que se deja de trabajar en ese

mdulo.
Tiempo
Interrupciones
Se registra cualquier interrupcin de tiempo en la que no se

trabaj e esa tarea. Se escribe la razn de la interrupcin en
la columna de comentarios.
Si existen muchas
interrupciones se debe registrar de la siguiente forma: 5 + 2
(min.)
Delta Tiempo
Es el tiempo total que se gasto en la tarea menos el tiempo

de las interrupciones.
Por ejemplo:
Hora inicial: 7:43
Hora final: 8:24
T. Interrupciones: 7 min.
Delta tiempo = 34 min.
352
Actividad
Se digita el nombre de la fase de programacin en la que se

haya trabajado. En la tabla xx se encuentra las
descripciones de las fases de programacin.
Ejemplo:
codificar.
Comentarios
Se registran los comentarios pertinentes que sirvan para

recordar cualquier detalle especfico de esta actividad.
Ejemplo: Revisin de la teora de conjuntos.
Notas
Si por algn motivo alguna vez se olvida llegar algn registro

de tiempo, es necesario escribir la mejor estimacin posible,
o si por algn motivo este formulario no esta a la mano del
programador, se deben registrar los tiempos en un lugar
aparte y luego llenar el formulario debidamente. Si olvida
registrar un tiempo, ingrese la mejor estimacin.
Tabla 52. Descripcin de las fases de programacin.

Descripcin de las fases de programacin
Se pueden usar las siguientes categoras para completar la columna de Actividad
Es el tiempo que el programador gasta en pensar en como va a
Diseo
solucionar el problema y en disear el algoritmo. Incluye: diagramas,
pseudocdigo, y otras tareas, cualquier cosa antes de comenzar a
escribir el cdigo es considerado diseo
Codificar Es la traduccin del algoritmo en cdigo fuente.
Compilar Compilar el codigo fuente. La fase de compilar se completa cuando el
cdigo corre limpiamente sin los errores de sintaxis reportados por el
compilador.
La fase de revision implica que el cdigo sea revisado por otra
Revisin
persona.
Implica las pruebas que se hacen al programa para identificar y
Pruebas
reparar defectos. Si durante la fase de pruebas hace falta agregar
algunas lneas de cdigo, estas se agregan y la actividad que queda
registrada es la de pruebas.
353
REGISTRO DE DEFECTOS
Nombre
Programa
Fecha
Fecha
Programa #
Tiempo
requerido
Defecto
Arreglado
Nmero
Tipo
Encontrado
Removido
Nmero
Tipo
Encontrado
Removido
Tiempo
requerido
Defecto
Arreglado
Nmero
Tipo
Encontrado
Removido
Tiempo
requerido
Defecto
Arreglado
Nmero
Tipo
Encontrado
Removido
Tiempo
requerido
Defecto
Arreglado
Nmero
Tipo
Encontrado
Removido
Tiempo
requerido
Defecto
Arreglado
Descripcin:
Fecha
Descripcin:
Fecha
Descripcin:
Fecha
Descripcin:
Fecha
Descripcin:
354
INSTRUCCIONES PARA LLENAR EL FORMATO DE REGISTRO DE

DEFECTOS
Propsito
Este formulario registra los datos de cada defecto encontrado y

corregido. Estos datos son utilizados para completar el resumen
del plan de proyecto.
Generalidades
Se deben registrar todos los defectos durante el desarrollo en este

formato.
Se registra cada defecto separado y completamente.
Se digita lo siguiente:
- Nombre.
- Fecha
- Nombre del mdulo del programa.
- El nmero del programa.
Encabezado
Fecha
Es la fecha en que fue encontrado el defecto
Nmero
Es el nmero de cada defecto. Para cada programa se usa un

nmero secuencial, desde uno (1) hasta n.
Tipo
Se escribe el tipo de defecto segn la tabla de estndares de tipos

de defectos. Tabla 52. Se debe tener claridad para seleccionar cual
tipo aplica.
Introducido
Es la fase en la que el defecto fue introducido. La mayora de las

veces es la fase de codificacin.
Removido
Es la fase en la que se removi el defecto.
Tiempo
requerido
Es la estimacin de la medida del tiempo que se requiri en

encontrar y corregir el defecto.
Defecto
Arreglado
(opcional)
Esta entrada puede ser ignorada. Si este defecto fue introducido al

momento de corregir otro defecto, se registra el nmero del defecto
corregido, si es muy difcil de identificar, se puede digitar X en ese
espacio.
Descripcin
Se escribe una breve descripcin del defecto. sta debe ser clara
de tal forma que despus se pueda recordar el defecto que causo
el error y el por qu se gener.
355
ESTNDAR DE TIPOS DE DEFECTOS

Tabla 53. Estndares de tipos de defectos.
Nmero
10
Nombre Tipo
Sintaxis
20
Asignacin
30
40
Algoritmo.
Interfase.
50
Arquitectura.
60
Datos
70
Comprobacin
80
Documentacin
90
Construccin,
Empaquetamiento
100
Entorno
110
Sistema
Descripcin
Ortografa, puntuacin, errores tipogrficos,
formato de la instruccin.
Declaracin, nombres duplicados, rango de
datos, inicializacin de datos.
Errores en el diseo del algoritmo
Errores en el mdulo del diseo de la
interfase: llamadas y referencias a los
procedimientos, listas de parmetros.
Errores en el diseo de la arquitectura:
modularizacion, estructura, acoplamiento,
cohesin.
Errores en el diseo de los datos: estructura
y contenido.
Fallas al momento de validar que los valores
de los datos sean verdaderos antes de ser
usados, mensajes de error.
Comentarios del cdigo fuente, mensajes y
otra documentacin externa.
Cambios de administracin, librerias, control
de versiones, creacion de archivos de error,
etc.
Herramientas CASE, compiladores, pruebas,
u otros problemas del sistema de soporte.
Hardware y configuracin de la plataforma,
recursos, memoria compartida.
356

Libro Completo de Ingeniería Eléctrica

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Libro Completo de Ingeniería Eléctrica

Hochgeladen von

Copyright:

Verfügbare Formate

SEIS SIGMA EN EL DESARROLLO DE PROYECTOS DE INFORMACIN

TECNOLGICA DE LA DIVISIN DE SERVICIOS DE INFORMACIN Y SU

DIANA MARCELA ZAMBRANO OLARTE

UNIVERSIDAD INDUSTRIAL DE SANTANDER

SEIS SIGMA EN EL DESARROLLO DE PROYECTOS DE INFORMACIN

DIANA MARCELA ZAMBRANO OLARTE

Proyecto de grado presentado como requisito parcial

UNIVERSIDAD INDUSTRIAL DE SANTANDER

DESCRIPCIN DEL DOCUMENTO

Metodologa Seis Sigma.

Mdulo de consultas del catlogo bibliogrfico de la Bilbioteca va

GENERALIDADES DE SEIS SIGMA.............................................. 10

DEFINICIN DE SEIS SIGMA

PRINCIPIOS DE SEIS SIGMA

Decisiones basadas en hechos.

FASE DEFINIR ............................................................................... 20

ENTENDER EL MODELO DEL NEGOCIO

Retroalimentacin con el Cliente o VOC.

DEFINIR ROLES Y RESPONSABILIDADES

Master Black Belts (MMB)

Black Belts (BB)

Green Belts (GB)

FORMAR EL EQUIPO DE TRABAJO

IDENTIFICAR LOS CLIENTES

IDENTIFICAR LO CRTICO PARA LA CALIDAD (CTQS)

DESARROLLAR EL PLAN DE PROYECTO

Definicin del alcance y objetivos

DESARROLLAR EL CUADRO RESUMEN DEL PROYECTO

IDENTIFICAR LOS PROCESOS ACTUALES

FASE MEDIR .................................................................................. 62

CAPTURAR LA VOZ DEL CLIENTE (VOC)

DETERMINAR QUE MEDIR

Medir lo que tenga valor

Exactitud de las medidas

PLAN DE COLECCIN DE DATOS

Seccin 1: definir las metas y los objetivos

Seccin 2: desarrollar las definiciones operativas y los

ELABORAR LAS GRFICAS DE LAS MEDIDAS

Histograma con curva normal

Diagrama de Series de Tiempo

CALCULAR EL NIVEL SIGMA

Por qu Benchmarking en Seis Sigma?

DESARROLLAR EL MODELO FINANCIERO

IDENTIFICAR Y PRIORIZAR LOS REQUERIMIENTOS DE LOS

INICIO DE DETERMINACIN DE MEJORAS

DETERMINAR QUE CAUSA LA VARIACIN

LLUVIA DE IDEAS PARA LA MEJORA DE PROCESOS

DETERMINAR CUALES MEJORAS TIENEN MAYOR IMPACTO EN

ENCONTRAR LOS RIESGOS ASOCIADOS AL PROCESO

DESARROLLAR EL PLAN DE CAPACITACIN

Evaluar las necesidades para la capacitacin

Preparar un programa de capacitacin.

Administrar la logstica para la capacitacin.

Evaluar y dar seguimiento al programa:

IDENTIFICAR LOS SISTEMAS AFECTADOS DE OTRAS

DESARROLLAR EL NUEVO MAPA DE PROCESOS

FASE DISEAR............................................................................ 119

SELECCIONAR METODOLOGA DE DESARROLLO DE

Modelo de Capacidad de Maduracin (CMM).

Proceso Personal de Software (PSP).

Proceso de Software en Equipo (TSP).

Desarrollo Rpido de Aplicacin (RAD).

Extreme Programing (XP).