UNIVERSIDAD DE ORIENTE NCLEO DE MONAGAS INGENIERA DE SISTEMAS COMISIN DE TRABAJOS DE GRADO MATURN / MONAGAS / VENEZUELA

GENIERA DE REQUISITOS PARA PROCESOS DE EJECUCIN DE INGENIERA ESTRATEGIAS DE MERCADEO MERCADEO (IMPULSOS Y FACHADAS), COORDINACIN DE DE DESARROLLO SARROLLO EN EL PUNTO DE VENTA CERVECERA POLAR C.A TERRITORIO COMERCIAL ORIENTE SUR Informe de Pasantas de Grado presentado ante la Comisin de Trabajos de Grado, como requisito para optar al ttulo de Ingeniero de Sistemas

Br: Karinthia Lilianit Sarabia Dorlemont. CI: 19.078.215 Asesor Acadmico: Ing. Jess Chaparro. CI: 4.526.369 Asesor Laboral: Ing. Anantonieta Morales. CI: 8.281.117

Maturn, Junio de 2011

ACTA DE APROBACIN

ii

DEDICATORIA Dedico este trabajo de grado a Dios Todopoderoso, por haberme acompaado y guiado en cada uno de los pasos que he dado en mi vida, as como tambin como regalarme una hermosa familia quienes me han llenado de amor desde antes de nacer. A mi Virgen del Valle, quien con su amor de madre me ha iluminado desde los inicios de mi carrera transmitindome fortaleza para alcanzar una de mis metas ms preciadas. A mis padres, Ellis Dorlemnt y Hernn Sarabia, por tener la bendicin de ser su hija, por haber credo y confiado en m siempre, por haberme inculcado que la mejor herencia es la educacin. Gracias a ustedes hoy todo esto es posible. A mi hermana, Ambar Sarabia, por haberle pedido a nuestros padres te regalarn un hermanita, s que desde antes de nacer ya me queras. Espero haber cumplido tu sueo de tener una hermana en todo el sentido de la palabra. Hoy estoy junto a ustedes tambin gracias a ti Sis! A mi amor, Giovanni Villahermosa, por ser mi amigo, mi compaero de estudios, mi bastn, y uno de mis ms grandes apoyo en todo momento, por ayudarme a levantarme cuando lo he necesitado. Y muy especialmente a mi to Alex Antonio Dorlemnt ( ), nunca olvidar

aquella ltima vez que te escuche decir fundamento hija, aunque ya no te encuentres entre nosotros, espero ests orgulloso de m! Con todo mi amor, este triunfo tambin es de ustedes!!! Karinthia L. Sarabia D.

iii

AGRADECIMIENTOS A Dios y a la Virgen del Valle por darme mucha salud, paciencia y fortaleza para culminar con xito esta meta. A mis queridos padres Ellis Dorlemnt y Hernn Sarabia, por su esfuerzo, confianza, dedicacin, amor, apoyo y compaa durante toda mi vida. Los Amo con toda mi alma! A Ambar Sarabia mi sis, por ser la mejor hermana con que cualquier persona puede soar tener y ser mi ejemplo, ensendome apreciar las mejores cosas de la vida, por estar a mi lado apoyndome en todo momento. Te amo hermana! A mi amor, Giovanni Villahermosa, infinitas gracias por tu apoyo, confianza y comprensin, gracias por ensearme de todo tanto en mbito profesional como en el personal, por ser parte de mi vida. Te amo con todo mi corazn!!! A mis amigos, Riusmary Daniela Rivas, Jess David Garca, Carmen Sofa Rendn, Ana Mara Figuera, Andreina Brito, Solymar Carrera y Luis Jos Montaner, siempre recuerdo los bellos momentos vividos en bachillerato, mil gracias por esa bella amistad que a pesar de la distancia la hemos podido conservar, los quiero muchsimo!!! A la Universidad de Oriente, por ser mi segunda casa y brindarme la oportunidad de estudiar en tan reconocida institucin universitaria y as lograr convertirme hoy en da en una profesional. A los profesores: Ing. Jess Chaparro de manera muy especial quien fue mi asesor acadmico me brindo un voto de confianza y siempre confi en m, mi admiracin y respeto para usted, infinitamente agradecida, a la Ing. Beatriz Prez, Ing. Roger Daz y Lcda. Marlene Zerpa, quienes con apoyo y dedicacin ayudaron a culminar mi trabajo de grado. Mil Gracias!!!

iv

A mi amigos, compaeros de estudios, colegas y cuasi colegas: Zelandia Carvajal, Miriangel Fajardo, Luisa Daz, Roxana Romero, Luis Jos Montaner, Jos Alejandro Hernndez, Juan Carlos Carvajal, Vladimir Mata, Zairen Torres, Diana Garca, Sandra Azocar, Julio Campos, Kharym Zapata, Elizabeth Ortiz, Gabriela Lozada, Mnica Gamboa, Mara Biondy, Orlando Coronado, Alejandra Angel, Maricel Caraballo, ngel Campos, Yanires Velsquez, Renn Guzmn, Juan Daz, Giomar Marcano, Flix Rodrguez, Annelys Figuera y a todas aquellas personas que se me escapan en este momento, pero de igual manera estuvieron conmigo, gracias por estar siempre a mi lado, brindndome compaa y apoyo incondicional. Lo estamos logrando amigos!!! los voy a extraar muchsimo, siempre los llevar en mi corazn. A la organizacin Empresas Polar en su negocio Cervecera Polar C.A., por brindarme la oportunidad de adquirir mi primera experiencia laboral en tan reconocida empresa. A la Ing. Anantonieta Morales, mi asesora laboral por toda la colaboracin prestada para la realizacin de mi trabajo de grado, inmensamente agradecida por todo! Y a todo el equipo que conforman Cervecera Polar C.A Territorio Comercial Oriente Sur. Infinitas gracias a todos! Karinthia L. Sarabia D.

UNIVERSIDAD DE ORIENTE NCLEO DE MONAGAS ESCUELA DE INGENIERA DE SISTEMAS COMISIN DE TRABAJOS DE GRADO MATURN / MONAGAS / VENEZUELA INGENIERA NGENIERA DE REQUISITOS PARA PROCESOS DE EJECUCIN DE ESTRATEGIAS DE MERCADEO MERCADEO (IMPULSOS Y FACHADAS), COORDINACIN DE DE DESARROLLO SARROLLO EN EL PUNTO DE VENTA CERVECERA POLAR C.A TERRITORIO COMERCIAL ORIENTE SUR Lnea de investigacin: Sistemas de Informacin Autor: Karinthia Sarabia. C.I: 19.078.215 Tutor: Ing. Jess Chaparro Chaparro. C.I: 4.526.369 Fecha: Febrero de 2011 RESUMEN La presente investigacin tuvo como objetivo desarrollar la ingeniera de requisitos de aplicacin empresarial para la gestin, control y seguimiento de los procesos de ejecucin de estrategias de mercadeo (Impulsos y Fachadas) en la Coordinacin de Desarrollo en el Punto de Venta en Cervecera Polar C.A Territorio Comercial Oriente Sur. El tipo de investigacin es de carcter proyectivo y nivel comprensivo. . Las tcnicas e instrumentos de recoleccin de datos fueron la observacin directa, irecta, la revisin documental, las entrevistas no estructuradas y el cuestionario con el propsito de obtener informacin confiable, basndose en el anlisis de contenido como tcnica de procesamiento de la informacin. Para el cumplimiento de los objetivos planteados se utiliz la metodologa de desarrollo de software Gray Watch conjuntamente con el Lenguaje Unificado de Modelado (UML). El estudio comprende un anlisis profundo de procesos tcnicos: Modelo de Negocio e Ingeniera de Requisitos propuestos por la metodologa. La ingeniera de requisitos formulada propone una solucin para disear y construir una aplicacin empresarial que atienda las necesidades planteadas en la coordinacin con la finalidad de automatizar los procesos Impulsos y Fachadas. Se plantea un sistema desarrollado bajo ambiente web que permita mejorar mejorar el procesamiento de manera eficaz de las estrategias requeridas. Palabras claves: Modelo de negocio, Ingeniera de requisitos, Metodologa Gray Watch, , Aplicacin Empresarial. Empresarial

vi

NDICE ACTA DE APROBACIN........................................................................................... ii DEDICATORIA .......................................................................................................... iii AGRADECIMIENTOS ............................................................................................... iv RESUMEN................................................................................................................... vi NDICE ....................................................................................................................... vii LISTA DE FIGURAS ................................................................................................... x LISTA DE CUADROS ............................................................................................... xii LISTA DE DIAGRAMAS ....................................................................................... xviii LISTA DE GRFICOS ............................................................................................. xxi INTRODUCCIN ........................................................................................................ 1 CAPTULO I................................................................................................................. 3 CONTEXTO ORGANIZACIONAL ............................................................................ 3 Empresas Polar .......................................................................................................... 3 Resea Histrica.................................................................................................... 4 Cervecera Polar C.A. ............................................................................................... 8 Objetivo General ................................................................................................... 8 Objetivos Especficos ............................................................................................ 9 Visin .................................................................................................................... 9 Misin ................................................................................................................... 9 Valores ................................................................................................................ 10 Estructura Organizativa de Empresas Polar ............................................................ 11 CAPTULO II ............................................................................................................. 12 EL PROBLEMA Y SUS GENERALIDADES........................................................... 12 Planteamiento del Problema .................................................................................... 12 Objetivos de la Investigacin .................................................................................. 16 Objetivo General ................................................................................................. 16 Objetivos Especficos .......................................................................................... 16 Justificacin de la Investigacin ............................................................................. 17 Alcance de la Investigacin .................................................................................... 18

vii

CAPTULO III ............................................................................................................ 19 MARCO REFERENCIAL .......................................................................................... 19 Antecedentes de la Investigacin ............................................................................ 19 Bases Tericas ......................................................................................................... 21 Sistema de Informacin....................................................................................... 21 Mtodo Gray Watch ............................................................................................ 24 Modelo de Negocio con la metodologa Gray Watch ......................................... 36 Ingeniera de Requisitos ...................................................................................... 44 Cadena de Valor .................................................................................................. 50 Lenguaje Unificado de Modelado (UML) .......................................................... 52 Enterprise Architect ............................................................................................ 64 Macromedia Dreamweaver ................................................................................. 65 Macromedia Fireworks 8 .................................................................................... 67 Definicin de Trminos........................................................................................... 67 CAPTULO IV ............................................................................................................ 70 MARCO METODOLGICO ..................................................................................... 70 Tipo de investigacin .............................................................................................. 70 Nivel de la investigacin ......................................................................................... 70 Diseo de la investigacin ...................................................................................... 71 Poblacin ................................................................................................................. 72 Muestra.................................................................................................................... 72 Tcnicas e Instrumentos de Recoleccin de Datos ................................................. 72 Tcnicas de Anlisis de Datos................................................................................. 74 Diseo Operativo .................................................................................................... 75 Etapa I: Estudio de la Situacin Actual: ............................................................. 75 Etapa II: Modelo de Negocio: ............................................................................. 75 Etapa III: Ingeniera de Requisitos:..................................................................... 76 Cuadro Operativo .................................................................................................... 76 CAPTULO V ............................................................................................................. 79 RESULTADOS ........................................................................................................... 79 Etapa I: Estudio de la situacin actual .................................................................... 79

viii

Etapa II: Modelo de Negocio ................................................................................ 129 Etapa III: Ingeniera de Requisitos........................................................................ 185 Anlisis Costo Beneficio .................................................................................... 271 Costos ................................................................................................................ 271 Beneficios .......................................................................................................... 274 CONCLUSIONES .................................................................................................... 276 RECOMENDACIONES ........................................................................................... 278 BIBLIOGRAFA ...................................................................................................... 279 ANEXOS .................................................................................................................. 282 HOJAS METADATOS ............................................................................................. 287

ix

LISTA DE FIGURAS FIGURA pp

Figura 1. Organigrama de Empresas Polar. ................................................................ 11 Figura 2. Componentes de Mtodo Gray Watch. ....................................................... 29 Figura 3. Principales tipos de productos del Mtodo Gray Watch. ............................ 29 Figura 4. Clasificacin de los Actores. ....................................................................... 31 Figura 5. Procesos del Mtodo Watch. ....................................................................... 32 Figura 6. Procesos del Mtodo Gray Watch. .............................................................. 32 Figura 7. Estructura de los Modelos de Procesos. ...................................................... 35 Figura 8. Modelo de Productos asociados al Modelo de Negocios............................ 37 Figura 9. Subprocesos del Proceso de Modelo de Negocio. ...................................... 39 Figura 10. Modelo de Producto del Proceso de Ingeniera de Requisitos. ................. 45 Figura 11. Subprocesos del Proceso de Ingeniera de Requisitos. ............................. 46 Figura 12. Representacin de una Cadena de Valor................................................... 52 Figura 13. El smbolo UML de una clase. .................................................................. 55 Figura 14. Actor. ........................................................................................................ 58 Figura 15. Caso de Uso. ............................................................................................. 59 Figura 16. Transaccin de una Actividad a otra. ........................................................ 60 Figura 17. Simbologa de los Diagramas de Estados. ................................................ 62 Figura 18. Clasificacin de los Procesos del Mtodo Watch durante el desarrollo del proyecto. ............................................................................................................ 107 Figura 19. Principales Tipos de Productos del Mtodo Watch. ............................... 110 Figura 20. Modelo de Jerarqua de Sistemas de la Coordinacin de Desarrollo en el Punto de Venta. ................................................................................................. 133 Figura 21. Cadena de Valor de la Gerencia de Ventas del Territorio Comercial Oriente Sur. ....................................................................................................... 142 Figura 22. Cadena de Valor de la Coordinacin de Desarrollo en el Punto de Venta. ........................................................................................................................... 144 Figura 23. Modelo de Reglas del Negocio. .............................................................. 171 Figura 24. Integracin de los Modelos ..................................................................... 184 Figura 25. Interfaz de Acceso al Sistema. ................................................................ 260

Figura 26. Interfaz de Inicio Rol SuperUsuario. ...................................................... 260 Figura 27. Interfaz de Inicio Rol Administrador del Sistema. ................................. 261 Figura 28. Interfaz Cambiar Clave Rol SuperUsuario. ............................................ 261 Figura 29. Interfaz Cambiar Clave Rol Administrador. ........................................... 262 Figura 30. Solicitud de Impulsos Rol Usuario y SuperUsuario. .............................. 262 Figura 31. Estatus de Solicitud Rol Usuario. ........................................................... 263 Figura 32. Estatus de Solicitud Rol Superusuario. ................................................... 264 Figura 33. Asignacin de proveedor estrategia impulsos......................................... 265 Figura 34. Asignacin de proveedor a solicitud de impulsos ................................... 265 Figura 35. Solicitud de Fachadas.............................................................................. 266 Figura 36. Estatus de Solicitud Fachadas Rol Usuario............................................. 266 Figura 37. Estatus de Solicitud Fachadas Rol SuperUsuario ................................... 267 Figura 38. Asignacin de proveedor a solicitud de fachada ..................................... 267 Figura 39. Asignacin de proveedor a solicitud de fachada ..................................... 268 Figura 40. Ingresar Proveedores. .............................................................................. 269 Figura 41. Consulta de proveedores. ........................................................................ 269 Figura 42. Administrar Usuarios. ............................................................................. 270

xi

LISTA DE CUADROS CUADRO pp

Cuadro 1. Resumen de los Subprocesos del Proceso Modelo de Objetivos ............... 40 Cuadro 2. Resumen de los Subprocesos del Proceso Modelado de Procesos del Negocio ............................................................................................................... 41 Cuadro 3. Resumen de los Subprocesos del Proceso Modelado de Objetos del Negocio ............................................................................................................... 41 Cuadro 4. Resumen de los Subprocesos del Proceso Modelado de Reglas del Negocio ............................................................................................................................. 42 Cuadro 5. Resumen de los Subprocesos del Proceso Modelado de Actores del Negocio. .............................................................................................................. 43 Cuadro 6. Resumen de los Subprocesos del Proceso Modelado de Eventos del Negocio. .............................................................................................................. 43 Cuadro 7. Descripcin del Flujo de Trabajo: Descubrimiento de Requisitos ............ 47 Cuadro 8. Descripcin del Flujo de Trabajo: Anlisis de Requisitos ......................... 47 Cuadro 9. Descripcin del Flujo de Trabajo: Especificacin de Requisitos .............. 48 Cuadro 10. Descripcin del Flujo de Trabajo: Validacin de Requisitos .................. 49 Cuadro 11. Descripcin del Flujo de Trabajo: Gestin de Requisitos ....................... 50 Cuadro 12. Relaciones entre las Clases ...................................................................... 56 Cuadro 13. Elementos de los Diagramas de Objetos .................................................. 56 Cuadro 14. Elementos del Diagrama de Despliegue .................................................. 58 Cuadro 15. Tipos de Relaciones en Diagramas de Casos de Uso .............................. 59 Cuadro 16. Elementos del Diagrama de Actividad .................................................... 61 Cuadro 17. Elementos del Diagrama de Secuencia .................................................... 62 Cuadro 18. Clasificacin de las acciones de un Diagrama de Procesos ..................... 64 Cuadro 19. Cuadro Operativo ..................................................................................... 77 Cuadro 20. Distribucin Absoluta y Porcentual acerca que la Coordinacin de Desarrollo en el Punto de Venta se define como unidad encargada de la aplicacin de las estrategias de mercadeo como son Impulsos y Fachadas. ....... 80 Cuadro 21. Distribucin Absoluta y Porcentual acerca de la existencia de misin, visin, valores y objetivos formalmente definidos para la Coordinacin de Desarrollo en el Punto de Venta.......................................................................... 81

xii

Cuadro 22. Distribucin Absoluta y Porcentual las principales funciones que realiza la coordinacin. ................................................................................................... 82 Cuadro 23. Distribucin Absoluta y Porcentual acerca del objetivo general de la Coordinacin de Desarrollo en el Punto de Venta. ............................................. 83 Cuadro 24. Distribucin Absoluta y Porcentual acerca de la existencia de normas y procedimientos bien definidos para las solicitudes de Impulsos y Fachadas...... 84 Cuadro 25. Distribucin Absoluta y Porcentual acerca del grado de eficiencia en el control de documentos que se lleva en la coordinacin. ..................................... 85 Cuadro 26. Distribucin Absoluta y Porcentual acerca de la disposicin de tecnologa de punta en la Coordinacin de Desarrollo en el Punto de Venta....................... 86 Cuadro 27. Distribucin Absoluta y Porcentual acerca de la consideracin del recurso humano como el activo ms valioso para empresa. ............................................ 87 Cuadro 28. Distribucin Absoluta y Porcentual acerca del inters por el bienestar de sus trabajadores por parte de Cervecera Polar C.A. ........................................... 88 Cuadro 29. Distribucin Absoluta y Porcentual acerca del empeo diario en mantener y crecer como departamento para as a su vez contribuir afianzar el liderazgo de la empresa en el mercado. ................................................................................... 89 Cuadro 30. Distribucin Absoluta y Porcentual acerca que la Coordinacin de Desarrollo en el Punto de Venta contribuye positivamente afianzar el liderazgo de los productos y marcas de Cervecera Polar C.A ........................................... 90 Cuadro 31. Distribucin Absoluta y Porcentual acerca de la imagen que desea reflejar la Coordinacin de Desarrollo en el Punto de Venta antes sus clientes y consumidores ...................................................................................................... 91 Cuadro 32. Distribucin Absoluta y Porcentual acerca del trabajo que har la Coordinacin de Desarrollo en el Punto de Venta en el futuro........................... 92 Cuadro 33. Distribucin Absoluta y Porcentual acerca de la posicin que se encontrar en un mediano plazo la Coordinacin de Desarrollo en el Punto de Venta. .................................................................................................................. 93 Cuadro 34. Distribucin Absoluta y Porcentual acerca que la Coordinacin de Desarrollo en el Punto de Venta se enfoca en satisfacer las necesidades y gustos de sus consumidores ............................................................................................ 94 Cuadro 35. Interesados (stakeholders) del proyecto. ................................................ 103 Cuadro 36. Identificacin de interesados del proyecto. ............................................ 105 Cuadro 37. Productos que genera la metodologa Gray Watch. ............................... 109 Cuadro 38. Caractersticas de ISO-9126 y aspecto que atiende cada uno. ............... 114 Cuadro 39. Cronograma Primera Iteracin............................................................... 117 Cuadro 40. Cronograma Segunda Iteracin ............................................................. 117 xiii

Cuadro 41. Cronograma Tercera Iteracin ............................................................... 118 Cuadro 42. Cronograma Cuarta Iteracin ................................................................. 118 Cuadro 43. Cronograma Quinta Iteracin ................................................................ 119 Cuadro 44. Matriz de Evaluacin de Riesgos ........................................................... 120 Cuadro 45. Primer Riesgo ........................................................................................ 121 Cuadro 46. Segundo Riesgo ..................................................................................... 121 Cuadro 47. Tercer Riesgo ......................................................................................... 122 Cuadro 48. Cuarto Riesgo ........................................................................................ 122 Cuadro 49. Quinto Riesgo ........................................................................................ 123 Cuadro 50. Sexto Riesgo .......................................................................................... 123 Cuadro 51. Sptimo Riesgo ...................................................................................... 124 Cuadro 52. Octavo Riesgo ........................................................................................ 124 Cuadro 53. Noveno Riesgo ....................................................................................... 125 Cuadro 54. Dcimo Riesgo ....................................................................................... 125 Cuadro 55. Dcimo Primer Riesgo ........................................................................... 126 Cuadro 56. Dcimo Segundo Riesgo ........................................................................ 126 Cuadro 57. Dcimo Tercer Riesgo ........................................................................... 127 Cuadro 58. Preguntas claves con que debe cumplir la Misin ................................. 135 Cuadro 59. Preguntas claves con que debe cumplir la Visin.................................. 135 Cuadro 60. Evaluacin de la Misin......................................................................... 136 Cuadro 61. Premisas bsicas para la Evaluacin de la Misin ................................. 137 Cuadro 62. Evaluacin de la Visin ......................................................................... 138 Cuadro 63. Matriz Procesos vs Objetos.................................................................... 169 Cuadro 64. Matriz Proceso/ Responsabilidad/ Actor. .............................................. 178 Cuadro 65. Matriz Procesos vs Eventos. .................................................................. 182 Cuadro 66. Reglas del Negocio ................................................................................ 189 Cuadro 67. Primer Actor .......................................................................................... 190 Cuadro 68. Segundo Actor ....................................................................................... 190 Cuadro 69. Tercer Actor ........................................................................................... 190 Cuadro 70. Recoleccin de Requerimientos Iniciales .............................................. 192 Cuadro 71. Planilla Volere ....................................................................................... 193

xiv

Cuadro 72. Primer Requisito Funcional ................................................................... 193 Cuadro 73. Segundo Requisito Funcional ................................................................ 194 Cuadro 74. Tercer Requisito Funcional .................................................................... 194 Cuadro 75. Cuarto Requisito Funcional ................................................................... 194 Cuadro 76. Quinto Requisito Funcional ................................................................... 195 Cuadro 77. Sexto Requisito Funcional ..................................................................... 195 Cuadro 78. Sptimo Requisito Funcional ................................................................. 195 Cuadro 79. Octavo Requisito Funcional ................................................................... 196 Cuadro 80. Noveno Requisito Funcional.................................................................. 196 Cuadro 81. Dcimo Requisito Funcional.................................................................. 197 Cuadro 82. Dcimo Primer Requisito Funcional ...................................................... 197 Cuadro 83. Dcimo Segundo Requisito Funcional................................................... 197 Cuadro 84. Dcimo Tercer Requisito Funcional ...................................................... 198 Cuadro 85. Dcimo Cuarto Requisito Funcional ...................................................... 198 Cuadro 86. Dcimo Quinto Requisito Funcional ..................................................... 198 Cuadro 87. Dcimo Sexto Requisito Funcional ....................................................... 199 Cuadro 88. Dcimo Sptimo Requisito Funcional ................................................... 199 Cuadro 89. Dcimo Octavo Requisito Funcional ..................................................... 199 Cuadro 90. Dcimo Noveno Requisito Funcional .................................................... 200 Cuadro 91. Vigsimo Requisito Funcional ............................................................... 200 Cuadro 92. Vigsimo Primer Requisito Funcional ................................................... 200 Cuadro 93. Vigsimo Segundo Requisito Funcional................................................ 201 Cuadro 94. Vigsimo Tercer Requisito Funcional ................................................... 201 Cuadro 95. Vigsimo Cuarto Requisito Funcional ................................................... 201 Cuadro 96. Vigsimo Quinto Requisito Funcional .................................................. 202 Cuadro 97. Vigsimo Sexto Requisito Funcional .................................................... 202 Cuadro 98. Vigsimo Sptimo Requisito Funcional ................................................ 202 Cuadro 99. Vigsimo Octavo Requisito Funcional .................................................. 203 Cuadro 100. Vigsimo Noveno Requisito Funcional ............................................... 203 Cuadro 101. Trigsimo Requisito Funcional ............................................................ 204 Cuadro 102.Trigsimo Primer Requisito Funcional ................................................. 204

xv

Cuadro 103. Trigsimo Segundo Requisito Funcional ............................................. 204 Cuadro 104. Trigsimo Tercer Requisito Funcional ................................................ 205 Cuadro 105. Trigsimo Cuarto Requisito Funcional ................................................ 205 Cuadro 106. Trigsimo Quinto Requisito Funcional................................................ 205 Cuadro 107. Trigsimo Sexto Requisito Funcional .................................................. 206 Cuadro 108. Trigsimo Sptimo Requisito Funcional ............................................. 206 Cuadro 109. Trigsimo Octavo Requisito Funcional ............................................... 206 Cuadro 110. Trigsimo Noveno Requisito Funcional .............................................. 207 Cuadro 111. Cuadragsimo Requisito Funcional ..................................................... 207 Cuadro 112. Cuadragsimo Primer Requisito Funcional ......................................... 207 Cuadro 113. Cuadragsimo Segundo Requisito Funcional ...................................... 208 Cuadro 114. Cuadragsimo Tercer Requisito Funcional.......................................... 208 Cuadro 115. Primer Requisito No Funcional ........................................................... 209 Cuadro 116. Segundo Requisito No Funcional ........................................................ 209 Cuadro 117. Tercer Requisito No Funcional ............................................................ 209 Cuadro 118. Cuarto Requisito No Funcional ........................................................... 210 Cuadro 119. Quinto Requisito No Funcional ........................................................... 210 Cuadro 120. Sexto Requisito No Funcional ............................................................. 210 Cuadro 121. Sptimo Requisito No Funcional ......................................................... 211 Cuadro 122. Octavo Requisito No Funcional ........................................................... 211 Cuadro 123. Noveno Requisito No Funcional .......................................................... 211 Cuadro 124. Dcimo Requisito No Funcional .......................................................... 212 Cuadro 125. Dcimo Primer Requisito No Funcional .............................................. 212 Cuadro 126. Dcimo Segundo Requisito No Funcional ........................................... 212 Cuadro 127. Dcimo Tercer Requisito No Funcional .............................................. 213 Cuadro 128. Dcimo Cuarto Requisito No Funcional .............................................. 213 Cuadro 129. Dcimo Quinto Requisito No Funcional.............................................. 213 Cuadro 130. Dcimo Sexto Requisito No Funcional................................................ 214 Cuadro 131. Dcimo Sptimo Requisito No Funcional ........................................... 214 Cuadro 132. Dcimo Octavo Requisito No Funcional ............................................. 214 Cuadro 133. Dcimo Noveno Requisito No Funcional ............................................ 215

xvi

Cuadro 134. Vigsimo Requisito No Funcional ....................................................... 215 Cuadro 135. Vigsimo Primer Requisito No Funcional ........................................... 215 Cuadro 136. Vigsimo Segundo Requisito No Funcional ........................................ 216 Cuadro 137. Vigsimo Tercer Requisito No Funcional ........................................... 216 Cuadro 138. Vigsimo Cuarto Requisito No Funcional ........................................... 216 Cuadro 139. Vigsimo Quinto Requisito No Funcional........................................... 217 Cuadro 140. Vigsimo Sexto Requisito No Funcional............................................. 217 Cuadro 141. Vigsimo Sptimo Requisito No Funcional ........................................ 217 Cuadro 142. Vigsimo Octavo Requisito No Funcional .......................................... 218 Cuadro 143. Vigsimo Noveno Requisito No Funcional ......................................... 218 Cuadro 144. Requisitos Funcionales del Sistema ..................................................... 223 Cuadro 145. Requisitos No Funcionales del Sistema ............................................... 227 Cuadro 146. Adecuidad ............................................................................................ 232 Cuadro 147. Seguridad ............................................................................................. 232 Cuadro 148. Madurez ............................................................................................... 233 Cuadro 149. Tolerancia a fallos ................................................................................ 233 Cuadro 150. Recuperacin........................................................................................ 234 Cuadro 151. Entendibilidad ...................................................................................... 235 Cuadro 152. Operabilidad......................................................................................... 235 Cuadro 153. Comportamiento en el tiempo .............................................................. 236 Cuadro 154. Analizibilidad....................................................................................... 237 Cuadro 155. Cambiabilidad ...................................................................................... 237 Cuadro 156. Estabilidad ........................................................................................... 237 Cuadro 157. Conformidad de la transportabilidad ................................................... 238 Cuadro 158. Involucrados en el Proyecto ................................................................. 272 Cuadro 159. Costos por Personal del Proyecto ........................................................ 272 Cuadro 160. Costos de adiestramiento ..................................................................... 272 Cuadro 161. Costos de material de oficina ............................................................... 273 Cuadro 162. Costos totales del proyecto .................................................................. 274

xvii

LISTA DE DIAGRAMAS DIAGRAMA pp

Diagrama 1. Diagrama de Objetivos. ....................................................................... 140 Diagrama 2. Diagrama de Jerarqua de la Gerencia de Ventas. ............................... 143 Diagrama 3. Diagrama de Jerarqua de la Coordinacin de Desarrollo en el Punto de Venta. ................................................................................................................ 146 Diagrama 4. Diagrama de Proceso - Identificacin del Punto. ................................ 147 Diagrama 5. Diagrama de Proceso - Recepcin de Requerimientos. ....................... 148 Diagrama 6. Diagrama de Proceso - Seleccin de Proveedores. .............................. 149 Diagrama 7. Diagrama de Procesos - Desarrollo de Impulsos y/o Fachadas. .......... 150 Diagrama 8. Diagrama de Proceso - Seguimiento de Impulsos y/o Fachadas. ........ 151 Diagrama 9. Diagrama de Proceso - Procesamiento de Factura. ............................. 152 Diagrama 10. Diagrama de Actividades - Identificacin del Punto - Flujo de Control. ........................................................................................................................... 153 Diagrama 11. Diagrama de Actividades - Identificacin del Punto - Flujo de Objetos. ........................................................................................................................... 154 Diagrama 12 Diagrama de Actividades - Recepcin de Requerimientos - Flujo de Control. ............................................................................................................. 155 Diagrama 13. Diagrama de Actividades - Recepcin de Requerimientos - Flujo de Objetos. ............................................................................................................. 155 Diagrama 14. Diagrama de Actividades - Seleccin de Proveedor - Flujo de Control. ........................................................................................................................... 156 Diagrama 15. Diagrama de Actividades - Seleccin de Proveedor - Flujo de Objetos ........................................................................................................................... 157 Diagrama 16. Diagrama de Actividades - Desarrollo de Impulsos y/o Fachadas Flujo de Control. ............................................................................................... 158 Diagrama 17. Diagrama de Actividades - Desarrollo de Impulsos y/o Fachadas Flujo de Control. ............................................................................................... 159 Diagrama 18. Diagrama de Actividades - Seguimiento de Impulsos y/o FachadasFlujo de Control. ............................................................................................... 160 Diagrama 19. Diagrama de Actividades - Seguimiento de Impulsos y/o Fachadas Flujo de Objetos. ............................................................................................... 161 Diagrama 20. Diagrama de Actividades - Procesamiento de Facturas - Flujo de Control. ............................................................................................................. 162

xviii

Diagrama 21. Diagrama de Actividades - Procesamiento de Facturas - Flujo de Objetos. ............................................................................................................. 162 Diagrama 22. Diagrama de Objetos para el Proceso Identificacin del Punto. ....... 164 Diagrama 23. Diagrama de Objetos para el Proceso Recepcin de Requerimientos. ........................................................................................................................... 165 Diagrama 24. Diagrama de Objetos para el Proceso Seleccin de Proveedor. ........ 165 Diagrama 25. Diagrama de Objetos para el Proceso Desarrollo de Impulsos y/o Fachadas. ........................................................................................................... 166 Diagrama 26. Diagrama de Objetos para el Proceso Seguimiento de Impulsos y/o Fachadas. ........................................................................................................... 166 Diagrama 27. Diagrama de Objetos para el Proceso Procesamiento de Factura...... 167 Diagrama 28. Diagrama de Clases para la Coordinacin de Desarrollo en el Punto de Venta. ................................................................................................................ 168 Diagrama 29. Diagrama Actividad/Actor/Responsabilidad Proceso Identificacin del Punto. ................................................................................................................ 173 Diagrama 30. Diagrama Actividad/Actor/Responsabilidad Proceso Recepcin de Requerimientos. ................................................................................................ 173 Diagrama 31. Diagrama de Actividad/Actor/Responsabilidad Proceso Seleccin de Proveedores. ...................................................................................................... 174 Diagrama 32. Diagrama de Actividad/Actor/Responsabilidad Proceso Desarrollo de Impulsos y/o Fachadas. ..................................................................................... 175 Diagrama 33. Diagrama de Actividad/Actor/Responsabilidad Proceso Seguimiento de Impulsos y/o Fachadas. ................................................................................ 176 Diagrama 34. Diagrama de Actividad/Actor/Responsabilidad Proceso Procesamiento de Factura. ......................................................................................................... 177 Diagrama 35. Diagrama de Eventos para la Coordinacin de Desarrollo en el Punto de Venta. ........................................................................................................... 181 Diagrama 36. Diagrama de Procesos del "Descubrimiento de Requisitos. ............ 187 Diagrama 37. Diagrama de Jerarqua de Procesos "Descubrimiento de Requisitos". ........................................................................................................................... 188 Diagrama 38. Diagrama de Procesos del "Anlisis de Requisitos".......................... 219 Diagrama 39. Diagrama de Jerarqua de Procesos "Anlisis de Requisitos". .......... 220 Diagrama 40. Diagrama de Casos de Uso General del Sistema. .............................. 241 Diagrama 41. Caso de Uso Validar Usuario. ........................................................... 242 Diagrama 42. Diagrama de clases Validar Usuario.................................................. 243

xix

Diagrama 43. Diagrama de secuencia Validar Usuario............................................ 244 Diagrama 44. Caso de Uso Cambiar Clave. ............................................................. 245 Diagrama 45. Diagrama de clases Cambiar Clave. .................................................. 246 Diagrama 46. Diagrama de Secuencia Cambiar Clave. ........................................... 247 Diagrama 47. Caso de Uso Gestionar Impulsos. ...................................................... 248 Diagrama 48. Diagrama de clases Gestionar Impulsos. ........................................... 250 Diagrama 49. Diagrama de secuencia Gestionar Impulsos. ..................................... 250 Diagrama 50. Caso de Uso Gestionar Fachadas....................................................... 251 Diagrama 51. Diagrama de clases Gestionar Fachadas. ........................................... 253 Diagrama 52. Diagrama de secuencia Gestionar Fachadas ...................................... 253 Diagrama 53. Caso de Uso Ingresar Proveedor. ...................................................... 254 Diagrama 54. Diagrama de clases Proveedor. .......................................................... 255 Diagrama 55. Diagrama de secuencia Proveedores. ................................................ 255 Diagrama 56. Caso de Uso Administrar Usuario. .................................................... 256 Diagrama 57. Diagramas de clases Administrar Usuarios. ...................................... 258 Diagrama 58. Diagrama de secuencia Administrar Usuarios. .................................. 259

xx

LISTA DE GRFICOS GRFICO pp

Grfico 1. Representacin grfica tem 1 ................................................................... 80 Grfico 2. Representacin grfica tem 2 ................................................................... 81 Grfico 3. Representacin grfica tem 3 ................................................................... 82 Grfico 4. Representacin grfica tem 4 ................................................................... 83 Grfico 5. Representacin grfica tem 5 ................................................................... 84 Grfico 6. Representacin grfica tem 6 ................................................................... 85 Grfico 7. Representacin grfica tem 7 ................................................................... 86 Grfico 8. Representacin grfica tem 8 ................................................................... 87 Grfico 9. Representacin grfica tem 9 ................................................................... 88 Grfico 10. Representacin grfica tem 10 ............................................................... 89 Grfico 11. Representacin grfica tem 11 ............................................................... 90 Grfico 12. Representacin grfica tem 12 ............................................................... 91 Grfico 13. Representacin grfica tem 13 ............................................................... 92 Grfico 14. Representacin grfica tem 14 ............................................................... 93 Grfico 15. Representacin grfica tem 15 ............................................................... 94

xxi

INTRODUCCIN Hoy en da las organizaciones requieren del desarrollo e implementacin de los sistemas de informacin porque le permite lograr mejoras que favorecen el desenvolvimiento del trabajo diario de estas entidades que solicitan el uso de dichas tecnologas. Estas herramientas ofimticas automatizan los procesos administrativos o tcnicos de las empresas, proporcionando una plataforma de informacin necesaria para la toma de decisiones. Adems, la implementacin de sistemas de informacin brinda la posibilidad de obtener grandes ventajas, incrementar la capacidad de organizacin de la empresa, y tornar de esta manera los procesos a una verdadera competitividad. El desarrollo de los sistemas de informacin implica de la aplicacin de los conocimientos propios de la ingeniera de software, donde se comprenden las etapas para la realizacin de los sistemas, entre las etapas se encuentra la fase de anlisis, fase de diseo y la fase de implementacin. La etapa de anlisis se realiza con respecto al sistema de negocio, esto permite elaborar un modelo de negocio en donde se describen funcionamientos reales de la entidad organizacional en donde se realiza el estudio, adems de indicar cules son los requisitos indispensables para satisfacer las necesidades de la misma. La etapa de diseo se realiza en funcin de la etapa de anlisis, es decir, se construye un modelo de diseo que comprende la arquitectura del sistema del software y su diseo ms detallado. Por ltimo, se encuentra la fase de implementacin, en esta etapa se procede a programar e implementar los diseos especficos que se obtienen del modelo de diseo. Cervecera Polar C.A forma parte de estas organizaciones que buscan la manera de implementar sistemas de informacin que ayuden a mejorar el desarrollo de las actividades que llevan a cabo. Por consiguiente, en este estudio se propone el desarrollo de la ingeniera de requisitos de aplicacin empresarial para la gestin, control y seguimiento de los procesos de ejecucin de las estrategias de mercadeo

(Impulsos y Fachadas), en la Coordinacin de Desarrollo en el Punto de Venta de Cervecera Polar C.A Territorio Comercial Oriente Sur. El presente proyecto se encuentra organizado en cinco (5) captulos los cuales se explican a continuacin: Captulo I: Contexto Organizacional, comprende los aspectos contextuales de la organizacin en la que se llevo a cabo la investigacin tales como: resea histrica, visin, misin, objetivos, entre otros. Captulo II: El Problema y sus Generalidades, se expresa toda la informacin pertinente a la problemtica bajo estudio, as como tambin el objetivo general y los objetivos especficos, adems de la justificacin de la investigacin. Captulo III: Marco Referencial, en el cual se presentan los fundamentos y basamentos del proyecto, mediante los antecedentes de la investigacin, las bases tericas referentes al estudio y la definicin de trminos relacionados con el tema. Captulo IV: Marco Metodolgico, describe el tipo de investigacin, el nivel y las tcnicas utilizadas, logrando aplicar una metodologa para la recoleccin de datos y herramientas ms adecuadas para el anlisis y diseo de la propuesta. Captulo V: Resultados, est relacionado con los resultados alcanzados al aplicar la metodologa diseada para el logro de los objetivos propuestos y seguidamente se detalla el Anlisis Costo - Beneficio. Finalmente se presentan las conclusiones, recomendaciones, la bibliografa y los anexos que complementan el contenido del trabajo.

CAPTULO I CONTEXTO ORGANIZACIONAL Empresas Polar Empresas Polar es una corporacin lder en los mercados de bebidas y alimentos, cuya orientacin fundamental es brindar bienestar a consumidores, clientes, distribuidores, suplidores, trabajadores, accionistas y a la sociedad en general. Desde hace 70 aos su historia empresarial ha avanzado de la mano con su arraigado compromiso social, lo que la ha convertido en paradigma de la organizacin socialmente responsable en Venezuela. Esta labor la ha cumplido mediante las diversas acciones emprendidas por las compaas asentadas en cada regin del pas y el valioso aporte de su Fundacin Empresas Polar. Bajo un moderno enfoque de concentracin en negocios donde posee habilidades bsicas, Empresas Polar agrupa a ms de 40 compaas hermanas. La significacin de esta corporacin en la economa nacional se sustenta en indicadores contundentes: genera 30 mil empleos directos y ms de 180 mil indirectos. La infraestructura de produccin, comercializacin y servicios, altamente tecnificada y apta para desarrollar funciones de fabricacin ptimas, avanza de acuerdo con las dimensiones de las operaciones: ms de 30 plantas de produccin ubicadas en sitios estratgicos de la geografa nacional y la red de comercializacin ms importante de Venezuela, garantizando la presencia de sus productos en ms de 150 mil puntos de venta. Empresas Polar realiza operaciones comerciales en los negocios de cerveza y malta (Cervecera Polar); alimentos (Alimentos Polar); y refrescos y bebidas no carbonatadas (Pepsi-Cola Venezuela).

Cervecera Polar se encarga de las marcas de cerveza tambin concentra la lnea de Vinos de las Bodegas Pomar, maltas y otras bebidas alcohlicas como la Sangra Carorea. sta es la divisin principal de Empresas Polar por ser la de mayor facturacin para la compaa. En el mbito internacional est ubicada entre las empresas cerveceras ms importantes del mundo Alimentos Polar la industria de alimentos ms grande del pas, ofrece un abanico de productos que alcanzan una participacin de liderazgo en el mercado venezolano en los rubros de aceite y harina precocida de maz, arroz, pasta, margarinas, mayonesas y helados. Adems, el nutrido y amplio portafolio de productos incluye marcas lderes en segmentos como salsas y untables, productos del mar enlatados, alimentos congelados, modificadores lcteos, entre otros. Algunas de las marcas de Alimentos Polar son harina de maz precocida Harina P.A.N., aceite de maz Mazeite, arroz y pasta Primor, productos Quaker, salsas y untables Mavesa, salsa de tomate Pampero, salsas y untables La Torre del Oro, untables Rikesa, productos del mar Margarita, alimentos congelados Galera, helados Efe y otros. Pepsi-Cola Venezuela, la empresa establecida en sociedad estratgica con PepsiCo. International, que posee el 30% del capital. Con la actividad comercial desarrollada en esta rea, Empresas Polar reafirma las habilidades bsicas que posee en la produccin y envasado de bebidas. Pepsi-Cola Venezuela satisface las necesidades de los consumidores venezolanos, con un amplio y competitivo portafolio de productos que incluye marcas lderes como: Pepsi, Pepsi Light, 7up, 7up Light, Sabores Golden, agua mineral Minalba, Gatorade, jugos Yukery y otros. Resea Histrica Negocio de Cerveza y Malta De acuerdo a informacin compilada en el Portal de Empresas polar, disponible en lnea: (http://portal.netpolar.com/irj/portal), a principios de 1939, empezaron a forjarse los cimientos de una industria, que para aquel entonces era un proyecto de

gran envergadura. Estos se concretaron para 1941, con el nacimiento de Cervecera Polar, C.A., que empieza a funcionar generando trabajo para muchas personas. Para el ao 1946 la organizacin todava era un pequeo ncleo de produccin, pero ya se comenzaba a hablar de la excelente calidad de sus productos. Sin embargo, a principios de 1950 se crea en el Oriente del pas una importante fuente de trabajo: Cervecera de Oriente, unidad productora de la Planta de Barcelona, la cual hace su primer despacho a la ciudad de Porlamar en ese mismo ao. Con el crecimiento de la regin central del pas empieza a crecer tambin en forma vertiginosa la demanda de sus productos, por lo que se hace necesario para abastecer la zona instalar una planta que pudiera abarcarla, incluyendo el rea metropolitana. De esa forma nace el proyecto de una nueva planta. El nacimiento de Empresas Polar es el resultado de la constancia y el trabajo de una familia heredera de arrojo y la voluntad de servicio de sus primeros integrantes. Los cambios que experimentaba el pas tras 27 aos de dictadura y las posibilidades de apertura y apoyo a los inversionistas ofrecidas por el gobierno de Lpez Contreras, hizo que Jos Manuel Sez diseara un proyecto para el establecimiento de una industria cervecera. Su idea fue respaldada por Rafael Enrique Lujan, Andrs Ypez Santamara, Carlos Garca Toledo y apoyada por Lorenzo Mendoza Fleury, quienes no se sintieron amilanados por la presencia de otros grupos cerveceros, muy por el contrario, esto constituy para ellos un motivo ms, un estmulo para emprender la meta que se haban propuesto, seguros de cumplirlas. El 14 de Marzo de 1941, se concreta dicho proyecto con la constitucin de Cervecera Polar, C.A., en Antmano, la pionera. Luego de su puesta en funcionamiento, la empresa comienza a posicionarse en el mercado y a incrementar su mbito de accin, de tal manera que su producto fue aceptado en las distintas regiones del territorio nacional, a pesar de la presencia de otros grupos cerveceros muy competitivos. Motivado a esto, la empresa Polar estuvo obligada a establecer nuevas plantas y distribuidoras para cubrir las exigencias del cliente, las cuales eran

altamente considerables. Actualmente el grupo de Empresas Polar del negocio Cervecero est conformado por cuatro plantas y ocho territorios comerciales para abastecer a todo el Territorio Nacional. Cabe destacar que la antigua Distribuidora Polar del Sur, C.A., (Diposurca) al igual que las otras distribuidoras y plantas sufrieron una modificacin en su figura jurdica y denominacin; pasando, mediante el proceso de fusin, a ser Cervecera Polar C.A a partir del 01 de octubre del ao 2003, subdividindolas en cuatro (4) plantas y en ocho (8) Territorios Comerciales; siendo el caso de la Agencia Maturn que pertenece al Territorio Comercial Sur; Sin embargo Empresas Polar, an cuando se cre con el negocio de Cerveza y Malta a lo largo del camino, contando con una gran visin de futuro ha incursionado en otros negocios, como el de Alimentos, refrescos y vinos; a continuacin se presenta un resumen de la historia de estos negocios: Negocio de Alimentos Las actividades del rea de Alimentos se inician con la creacin de la Empresa Refinadora de Alimentos Venezolana (Remavenca) en el ao 1954, luego en el ao 1960 sale al mercado nacional un nuevo rengln de consumo masivo como lo es la Harina P.A.N. En 1967 inicia operaciones la Empresa Procra, en el mercado de alimento balanceados para animales. En 1986 la Organizacin entra en el negocio del arroz con la Compaa Corina, logrando posicionarse en el corto tiempo como lder en el mercado. En 1987 es adquirida Productos EFE, con lo cual comienza a participar en el negocio de los Helados. Tambin en ese mismo ao Empresas Polar se incorpora a la Agroindustria del trigo, a travs de la Empresa Mosaca, para procesar este cereal y elaborar pastas alimenticias. En 1988 se adquiere lo que sera Savoy Brands Internacional, con industrias de Snaks en Colombia, Guatemala, Honduras, Panam, Ecuador, Chile, Per, Argentina y Venezuela. El negocio de Alimentos se extiende al adquirir Promasa Colombia y su sistema comercial en ese pas en el ao 1996. En 1998 se establece una asociacin con

Fritolay en varios pases de la regin, dando origen a Snaks Amrica Latina. Luego en el ao 2001 se adquiere Mavesa, la cual incorpora una amplia gama de productos de valor agregado y marcas lderes. En el ao 2003 se crea Alimentos Polar. Bajo esta nueva denominacin se integraron las operaciones de Primor Alimentos, Mavesa, Productos EFE y Quaker, tanto en Venezuela como en Colombia. Nutripet Andina, compaa dedicada a elaborar y comercializar marcas globales de alimentos para mascotas, en el ao 2004 se incorpora a Alimentos Procra para conformar un completo portafolio. Negocio de Refrescos La Organizacin incursiona en el negocio de refrescos en el ao 1993 al adquirir Golden. Posteriormente en el ao 1997 se establece un acuerdo con PepsiCo para producir y comercializar Pepsi en Venezuela. En el ao 2002, luego de la adquisicin de Quaker por PepsiCO a nivel mundial, ste le licencia a Empresas Polar la marca Gatorade en Venezuela. Paralelamente Empresas Polar adquiere las lneas de avenas tanto en Venezuela como en Colombia. En el ao 2005, PepsiCo selecciona a Pepsi-Cola Venezuela como el Embotellador del ao 2004, entre todas sus operaciones alrededor del mundo. Negocios de Vinos En 1990 sale al mercado nacional la primera produccin de vinos jvenes de Bodegas Pomar. En enero de 2005, el negocio de los vinos se integr a Cervecera Polar, logrando importantes sinergias. Fundacin Empresas Polar En 1977 nace Fundacin Empresas Polar para contribuir con el desarrollo social del pas, iniciativa que era canalizada hasta entonces a travs de la Asociacin Civil El Puntal.

Cervecera Polar C.A. El negocio de cerveza y malta de Empresas Polar es operado por Cervecera Polar, lder en los rubros de cerveza y malta, manteniendo el 75 por ciento del mercado local de cervezas y el 90 por ciento del consumo de maltas. En el mbito internacional est ubicada entre las empresas cerveceras ms importantes del mundo. Con una capacidad instalada de 200 millones de litros mensuales, Cervecera Polar satisface la demanda de sus productos en los mbitos nacional e internacional. Cuenta con 4 plantas de produccin situadas en puntos estratgicos de la geografa venezolana. Todas las instalaciones estn dotadas con la ms avanzada tecnologa cervecera, lo cual ha permitido establecer estrictos controles en las diversas etapas del proceso. Estas instalaciones industriales ejecutan importantes inversiones de capital en ampliacin, remodelacin, mantenimiento y adquisicin de nuevas tecnologas con miras a apuntalar altos niveles de competitividad y prepararse para los retos del nuevo milenio. En los mercados externos, Cervecera Polar compite exitosamente con sus productos de cerveza y malta en pases como Colombia, Antillas Holandesas, Estados Unidos (Florida y New Jersey), Surimane, Hait y Dominica. Objetivo General Cervecera Polar, C.A. Territorio Comercial Sur, tiene como objetivo principal, la venta y distribucin de los productos de Cerveza y Malta en la zona Oriente-Sur del pas, contando con un alto nivel competitivo y un buen rendimiento econmico que permite satisfacer las expectativas de los diversos puntos de expendios y as al mismo tiempo de sus consumidores. La distribucin creada por Empresas Polar crecer lgicamente para llevar el producto hacia su destino, permitiendo que fuese ms conocido y as garantizar al mismo tiempo su total comercializacin.

Objetivos Especficos 1. Abastecer de manera eficiente y en el momento preciso los productos

Cerveceros y Malta en todo el mercado. 2. 3. 4. 5. 6. Mantener un control interno de la calidad del producto para su mejoramiento. Elaborar campaas publicitarias para promocionar el producto. Administrar de la mejor forma los bienes de la empresa. Contar con depsitos aptos para mantener en condiciones ptimas el producto. Vender el producto a las distintas reas de ventas a travs de las Compaas

Vendedoras (CV.), actualmente conocidos Franquiciados. 7. Organizar y participar en diferentes programas de promocin y apoyo a la

comunidad. Visin Llegar a ser el lder claro del negocio de Cerveza y Malta en Venezuela y un jugador clave en Amrica Latina, ofreciendo productos y marcas de calidad de los distintos segmentos del mercado. Fortalecer su posicin a lo largo de la cadena de valor, la orientacin hacia el mercado, la excelencia en la atencin y servicio al cliente y que las marcas lderes tengan presencia predominante en el punto de venta en Venezuela. Lograr estas metas es manteniendo niveles de costos que la ubiquen entre las cinco primeras Cervecera del mundo. Seleccionar y capacitar al personal con el fin de alcanzar los perfiles requeridos, logrando su pleno compromiso con los valores de Empresas Polar y ofrecer las mejores oportunidades de desarrollo. Disponible en lnea: (http://portal.netpolar.com/irj/portal). Misin Satisfacer las necesidades de consumidores, clientes, compaas vendedoras, concesionarios, distribuidores, accionistas, trabajadores y suplidores, a travs de nuestros productos y de la gestin de nuestros negocios, garantizando los ms altos

estndares de calidad, eficiencia y competitividad, con la mejor relacin precio/valor, alta rentabilidad y crecimiento sostenido, contribuyendo con el mejoramiento de la calidad de vida de la comunidad y el desarrollo del pas. Disponible en lnea: (http://portal.netpolar.com/irj/portal). Valores Orientacin al Mercado Satisfacer las necesidades de los consumidores y clientes de manera consistente. Orientacin a Resultados y Eficiencia Ser consistentes en el cumplimiento de los objetivos, al menor costo posible. Agilidad y Flexibilidad Actuar oportunamente ante los cambios del entorno, siempre guiados por su visin, misin y valores. Innovacin Tener una actitud proactiva ante la generacin de nuevas tecnologas y nuevos productos. Poseer la disposicin a aprender, gerencial y difundir el conocimiento. Trabajo en Equipo Fomentar la integracin de equipos con el propsito de alcanzar metas comunes. Reconocimiento Contino al Logro y la Excelencia Fomentar y reconocer constantemente entre los trabajadores la excelencia y la orientacin al logro. Oportunidades de Empleo sin Distincin Proveer oportunidades de empleo en igualdad de condiciones.

10

Integridad y Civismo Exhibir una actitud consistentemente tica, honesta, responsable, equitativa y proactiva hacia el trabajo y hacia la sociedad en la cual nos desenvolvemos. Relaciones de Mutuo Beneficio con las Partes Interesadas Busca el beneficio comn en las relaciones de comercializacin, con las partes interesadas del negocio. Estructura Organizativa de Empresas Polar

Figura 1. Organigrama de Empresas Polar. Fuente: Portal de Empresas Polar, C.A. (2009). http://portal.netpolar.com/irj/portal 11

CAPTULO II EL PROBLEMA Y SUS GENERALIDADES Planteamiento del Problema A mediados de los aos 20s, el fsico britnico John Loige Baird invent un sistema que mediante ondas permita la integracin y transmisin de sonido con las imgenes visuales a grandes distancias, este invento se conoce como Televisin. sta comenz a originar un gran revuelo en el mundo entero, cambiando desde ese momento las formas de comunicacin existentes para ese entonces, convirtindose en el sistema de telecomunicaciones ms potente inventado en cuanto a su alcance e impacto en la sociedad, la televisin es un icono del proceso de Globalizacin que est viviendo la humanidad. En este sentido es indudable el poder de penetracin de la televisin y Cervecera Polar C.A desde sus inicios ha sabido hacer buen uso de ella caracterizndose por cuas televisivas impregnadas de grandes energas, y singular atractivo por su conexin con el consumidor, nostalgia y curiosidad. No obstante en la Gaceta Oficial de la Repblica Bolivariana de Venezuela N 38.031 de fecha 07 de diciembre del ao 2004, se sanciona la Ley de Responsabilidad Social en Radio y Televisin, en la cual se establecen restricciones en cuanto a la publicidad y propaganda, es as que reza: Artculo 9: Por motivos de salud pblica, orden pblico y respeto a la persona humana, no se permite en los servicios de radio y televisin, durante ningn horario la difusin de publicidad sobre: 2. Bebidas Alcohlicas y dems especies previstas en la legislacin sobre la materia. (Omissis)

Ante las restricciones que prov la Ley de Responsabilidad Social en Radio y Televisin, se avecinaban tiempos de grandes cambios y retos, como consecuencia de esto se deban construir y disear nuevas estrategias con el objeto de difundir y hacer de conocimiento del pblico en general las marcas de productos que ofrece Cervecera Polar C.A. El mayor reto al que se enfrentaban las corporaciones afectadas consista en crear alternativas eficientes y eficaces con la finalidad de reducir el impacto generado por las restricciones aplicadas, que rigen hasta la actualidad. Entre las estrategias que se disean se encuentran la implementacin de Impulsos y Fachadas, estos procesos se definen de la siguiente manera: 1. Impulsos: Es toda aquella actividad que se desarrollar en el punto de venta por

ejemplo promotoras, degustaciones, sonido, djs, agrupaciones musicales que incentiven el consumo de un producto especfico. 2. Fachadas: Se refiere a toda aquella imagen publicitaria externa que se

encuentran en el negocio, tales como pinturas y avisos de la marca lder del Punto de Venta. Debido a esto, la unidad encargada de llevar a cabo los procesos de ejecucin de las estrategias de mercadeo especficamente impulsos y fachadas es la Coordinacin de Desarrollo en el Punto de Venta (CDPV). Actualmente, estos procesos requieren de herramientas que les permitan efectuar un control y respaldo de la informacin (presupuestos, facturas, reportes fotogrficos, entre otros) generados. En la actualidad Cervecera Polar C.A, se encuentra disgregada en la geografa venezolana en cuatro (4) plantas de produccin (Caracas, San Joaqun, Maracaibo y Barcelona) y en ocho (8) Territorios Comerciales: Occidente, Centro Occidente, Los Andes, Centro Llanos, Valles Centrales, Metropolitano, Oriente Norte y Oriente Sur; todas las instalaciones estn dotadas con la ms avanzada tecnologa cervecera, lo

13

cual ha permitido establecer estrictos controles en las diversas etapas del proceso. Los productos Polar: Cerveza y Maltn, se distribuyen en el territorio nacional por medio de las Distribuidoras y sus respectivas Agencias, stas a su vez venden los productos a travs de la Red de Franquicias que proporcionan los mismos a numerosos puntos de ventas, y por medio de los cuales se encargan de hacerlos llegar al consumidor. El Territorio Comercial Oriente Sur se encuentra conformado por 12 Agencias: Maturn, Punta de Mata, Tucupita, Temblador, Puerto Ordaz, San Flix, Ciudad Bolvar, Upata, Tumeremo, Santa Elena de Uairn, Caicara del Orinoco y Puerto Ayacucho, a cada una de estas se delega la distribucin de los productos en sus respectivas localizaciones y zonas aledaas. La Coordinacin Desarrollo en el Punto de Venta debe realizar la aplicacin de sus estrategias a todas las Agencias pertenecientes al Territorio, lo que constituye un gran volumen de informacin generada en la ejecucin de las estrategias impulsos y fachadas empleadas en los puntos de ventas que debe ser tratada con especial cuidado. Inicialmente la Coordinacin Desarrollo en el Punto de Venta se encargaba de realizar la ejecucin de las estrategias de mercadeo: Impulsos y Fachadas, una vez ejecutados los mencionados procesos toda la informacin referente a estos, se almacenaba en un registro conjuntamente con el resto de facturas de proveedores de pagos efectuados localizados por registros contables que lleva a cabo la Gerencia de Administracin de la Empresa, los cuales luego de cierto tiempo (mximo un ao) pasaban a un registro muerto. Actualmente la CDPV coordina los esfuerzos de los proveedores de servicio quienes ejecutan los procesos Impulsos y Fachadas, para luego recibir las respectivas facturas y continuar con el procesamiento de cancelacin de las mismas. Una vez aprobadas se procede a realizar un respaldo, el cual consiste en fotocopiar dichas facturas conjuntamente con sus reportes de impulsos y reportes fotogrficos que hacen constar la ejecucin de los procesos aplicados a distintos puntos de venta y finalmente son almacenados en carpetas resguardadas en la coordinacin.

14

Por razones como las expuestas, el procedimiento descrito implica el empleo de tiempos prolongados convirtindose en un trabajo engorroso y difcil de llevar un seguimiento tanto fsico como sistematizado, an as no satisface los requerimientos de la unidad, es decir, que en el momento de solicitar o verificar datos especficos, se debe buscar en cada una de las carpetas donde se almacenan archivos fsicos provocando un atraso y lentitud en las actividades laborales cotidianas. Aunado a esto, es evidente que una base de datos facilitar el acceso a dicha informacin, y de igual manera servir de soporte sustentable para la toma de decisiones. Por otro lado, cabe destacar que la coordinacin no posee misin ni visin definidas formalmente. Cervecera Polar C.A presume la necesidad de mtodos e instrumentos enfocados a la generacin de datos estadsticos resultantes de los procesos Impulsos y Fachadas, que hagan posible el acceso, clasificacin y totalizacin de la data haciendo referencia a distintos campos o tems como son: ciudades, unidades de tiempo, marcas, entre otros. Es por esto, que se dificulta para la empresa la aplicacin de sistemas de indicadores que permitan conocer estadsticamente datos reveladores del estado de la misma, especficamente de los procesos mencionados, o bien saber si stos se llevan a cabo de acuerdo a los objetivos previstos o de manera correcta. En este sentido, es importante mencionar un factor problema de la situacin de la CDPV, relacionado con el descontrol y poco seguimiento a cada acuerdo de los puntos de venta que maneja esta rea, ya que suele incidir en prdidas monetarias al reinvertir en la aplicacin de las estrategias de impulsos y fachadas recientemente efectuadas a diversos puntos de venta. Entonces, como se ha mencionado anteriormente, el uso de una herramienta que proporcione informacin actualizada y puntual a requerimientos emergentes contribuye a manejar la data generada en estos procesos y sirviendo a la vez de registro para cualquier trmite o transaccin solicitada. Se deduce que los procesos llevados a cabo en la CDPV son efectuados mediante la utilizacin de herramientas ofimticas que no se adaptan con los

15

requerimientos funcionales. Por las razones antes expuestas, se propone el desarrollo de la ingeniera de requisitos de aplicacin empresarial que facilitar el control y la visualizacin de los procesos de ejecucin de estrategias de mercadeo como son la aplicacin de impulsos y fachadas en los puntos de expendios que mantienen acuerdos con la empresa. Estos estudios servirn de base para poder llevar a cabo el diseo y la construccin de la aplicacin empresarial que permitira visualizar las diferentes inversiones que se realizaron en los puntos de venta y as determinar la rentabilidad de futuras ejecuciones, optimizando los tiempos empleados en la bsqueda de datos, proporcionando informacin confiable y oportuna en la toma de decisiones, contando con un soporte para el seguimiento de estos procesos en el tiempo. De esta manera minimizar los ndices de inconsistencias y duplicidad del contenido de la informacin de dichos procesos que se resguardaran. Objetivos de la Investigacin Objetivo General Desarrollar la ingeniera de requisitos de aplicacin empresarial para la gestin, control y seguimiento de los procesos de ejecucin de estrategias de mercadeo (Impulsos y Fachadas), en la Coordinacin de Desarrollo en el Punto de Venta en Cervecera Polar C.A Territorio Comercial Oriente Sur. Objetivos Especficos 1. Estudiar la situacin actual de los procesos de ejecucin de estrategias de

mercadeo (Impulsos y Fachadas). 2. Disear el modelo de negocio de la Coordinacin de Desarrollo en el Punto de

Venta de Cervecera Polar C.A. 3. Definir los requisitos funcionales y no funcionales con el propsito de la

automatizacin de los procesos Impulsos y Fachadas.

16

4.

Formular la ingeniera de requisitos de aplicacin empresarial para los procesos

de ejecucin de estrategias de mercadeo (Impulsos y Fachadas) en la Coordinacin de Desarrollo en el Punto de Venta de Cervecera Polar C.A. Justificacin de la Investigacin Desde comienzos del funcionamiento de la Coordinacin de Desarrollo en el Punto de Venta se ha evidenciado notablemente el crecimiento de la misma, sin embargo esta coordinacin ha sufrido algunos cambios en cuanto a sus objetivos y funciones planteados inicialmente, aunado a esto presenta dificultades en el desarrollo de los procesos, el alto volumen de solicitudes que debe asistir y la escasez de herramientas eficientes que permitan llevar un respaldo de la informacin generada son algunos de los sntomas. Por esta razn, la investigacin radica en la necesidad de conocer y definir los procesos de Impulsos y Fachadas, los cuales representan los procesos fundamentales de dicha coordinacin, con el propsito de identificar y mejorar el desarrollo de estos procesos que actualmente presentan carencias de una clara definicin para el desarrollo y control de los mismos, generando problemas en el entorno organizacional. La importancia de realizar la fase de anlisis compuesta por el modelo de negocio y la ingeniera de requisitos se sita en el entendimiento del sistema de negocio para poder continuar con un proyecto de desarrollo de software. En general, esta investigacin le proporcionar a la Coordinacin de Desarrollo en el Punto de Venta, una mayor comprensin del funcionamiento administrativo de la misma, y as tener conocimiento de los procesos que actualmente no se desenvuelven de la mejor manera. Tambin le proporcionar las herramientas para realizar el diseo de una aplicacin empresarial que permita la gestin, control y visualizacin de sus procesos fundamentales Impulsos y Fachadas.

17

La ingeniera de requisitos propondra la solucin para la construccin de una aplicacin empresarial que permita automatizar los procesos Impulsos y/o Fachadas, el requerimiento de las solicitudes para estos procesos provenientes de las doce (12) Agencias que debe atender la coordinacin. Se plantea un sistema desarrollado bajo un ambiente web, que permita mejorar y lograr que los procedimientos se procesen de manera eficaz y eficiente, alcanzando un control y manejo adecuado de la ejecucin de los procesos Impulsos y Fachadas, de esta manera este sistema puede contribuir al desarrollo productivo de la organizacin en general, permitiendo que las Agencias envan sus solicitudes de manera fcil, rpida, y segura enviarlos va web y conocer el estatus de sus solicitudes desde su puesto de trabajo. Alcance de la Investigacin El alcance de esta investigacin comprende el desarrollo de ingeniera de requisitos para los procesos de ejecucin de las estrategias de mercadeo (Impulsos y Fachadas) en la Coordinacin de Desarrollo en el Punto de Venta en Cervecera Polar C.A Territorio Oriente Sur, con la finalidad de automatizar estos procesos fundamentales. Aunado a esto, permitir entender y modelar el sistema bajo estudio para continuar con la definicin, anlisis y especificacin de los requisitos funcionales y no funcionales de una aplicacin empresarial que permita la gestin, control y seguimiento de los procesos Impulsos y Fachadas. Por lo tanto, el estudio comprende el desarrollo de la etapa de anlisis de los procesos tcnicos propuestos por la Metodologa Gray Watch. En este sentido el estudio de la situacin actual permitir describir detalladamente el funcionamiento de los procesos organizacionales que se ejecutan en la CDPV. La participacin de personal que labora en la coordinacin contribuir a la definicin de los requisitos funcionales y no funcionales, ya que a partir de los mismos se obtendrn las especificaciones de los requisitos que debe satisfacer la aplicacin.

18

CAPTULO III MARCO REFERENCIAL Antecedentes de la Investigacin Cuando se realiza una investigacin es necesario complementarla tericamente, analizando y exponiendo los enfoques, es decir, las bases y antecedentes generales que se consideran vlidos para la correcta evaluacin del problema. Durante la revisin efectuada se encontraron varias investigaciones relacionadas con el tema que permitieron llevar a cabo la elaboracin del presente Proyecto Especial de Grado. Abreu, M. (2007). Modelo de Negocios del Departamento Tcnico de la Direccin de Servicios Generales de la Universidad de los Andes, Tesis de Grado presentado ante la Universidad de los Andes como requisito final para optar al ttulo de Ingeniero de Sistemas. Dicho estudio tena como objetivo desarrollar el Modelo de Negocios del Departamento Tcnico de la Direccin de Servicios Generales de la Universidad de los Andes con la finalidad de documentar la situacin actual, entender los elementos claves y planificar la infraestructura informtica. El desarrollo del modelo estuvo guiado por la Metodologa BMM (Business Modeling Method) de Montilva y Barrios (2003), y representado a travs del lenguaje grfico UML Business. La investigacin referida permiti conocer la utilizacin de la metodologa Watch durante el proceso de modelado del negocio, as como tambin el uso de los diferentes diagramas de UML Business para la adaptacin del modelado del negocio del sistema bajo estudio.

Mata, V (2010). Modelado de Negocios y procesos operacionales de la gerencia de plantas de gas y agua del distrito norte de Pdvsa Exploracin y Produccin Oriente. Trabajo Especial de Grado realizado para obtener el ttulo de Ingeniero de Sistemas en la Universidad de Oriente, Ncleo Monagas Este proyecto fue desarrollado con el fin de construir el Modelo de Negocios de la Gerencia de Plantas de Gas y Agua, el mismo fue elaborado empleando la Metodologa Business Modeling Method (BMM), a partir de la cual el autor estructur tres (03) fases: Descripcin de los procesos actuales de la Gerencia de Plantas, Desarrollo de los Modelos y Integracin, Documentacin y Validacin del Modelado de Negocios y Procesos Operacionales de la Gerencia de Plantas. Esta investigacin se tomo como orientacin y gua, su aporte ms significativo est relacionado con la formulacin del Modelo de Negocios para la Coordinacin Desarrollo en el Punto de Venta; facilit la representacin de los elementos (procesos, actores, reglas, estructura organizativa, entidades o recursos) constituyentes. Salazar, C (2006). Especificacin y Evaluacin de alternativas de software para el departamento de repuestos de ALMARCA. Tesis de grado de la especialidad de Ingeniera de Sistemas de la Universidad de los Andes Mrida. La finalidad de este trabajo es definir mediante el levantamiento de requisitos, las caractersticas de una herramienta de software que satisfaga las necesidades del departamento de repuestos de ALMARCA, para luego evaluar alternativas de software existentes en el mercado y recomendar la que mejor se adapte a las necesidades de dicho departamento. Este trabajo de investigacin ser de utilidad para comprender el desarrollo de la fase de ingeniera de requisitos de la metodologa GRAY WATCH, as como tambin de los productos finales que se obtienen en esta fase.

20

Bases Tericas Sistema de Informacin Segn Kenneth Laudon y Janes Laudon (1995), en su libro de Administracin de los Sistemas de Informacin definen un Sistema de Informacin de la siguiente manera: Un Sistema de Informacin puede definirse tcnicamente como un conjunto de componentes interrelacionados que permiten capturar, procesar, almacenar y distribuir la informacin para apoyar toma de decisiones y el control en una institucin. Adems, para apoyar la toma de decisiones, la coordinacin y el control, los Sistemas de Informacin pueden tambin ayudar a los administradores y al personal a analizar problemas, visualizar cuestiones complejas y crear nuevos productos. (p.08). Los componentes que interactan entre s son: el equipo computacional, el recurso humano, los datos o informacin fuente, programas ejecutados por las computadoras, las telecomunicaciones y los procedimientos de polticas y reglas de operacin. Un Sistema de Informacin realiza cuatro actividades bsicas: a) Entrada de informacin: Proceso en el cual el sistema toma los datos que

requiere para procesar la informacin, por medio de estaciones de trabajo, teclado, lectoras de CD, DVD, diskettes, cintas magnticas, cdigo de barras, puertos USB, scanner, etc. b) Almacenamiento de informacin: Es una de las actividades ms importantes

que tiene una computadora, ya que a travs de esta propiedad el sistema puede recordar la informacin guardada en la sesin o proceso anterior. c) Procesamiento de la informacin: Esta caracterstica de los sistemas permite la

transformacin de los datos fuente en informacin que puede ser utilizada para la toma de decisiones, lo que hace posible, entre otras cosas, que un tomador de decisiones genere una proyeccin financiera a partir de los datos que contiene un estado de resultados o un balance general en un ao base.

21

d)

Salida de informacin: Es la capacidad de un SI para sacar la informacin

procesada o bien datos de entrada al exterior. Las unidades tpicas de salida son las impresoras, graficadores, cintas magnticas, diskettes, la voz, etc. (Vega, E., 2005, p.05). De esta forma, los sistemas de informacin cumplen con los objetivos de automatizar los procesos operativos, proporcionar informacin de apoyo a la toma de decisiones y lograr ventajas competitivas a travs de su implantacin y uso. Importancia de los Sistemas de Informacin La toma de decisiones es una actividad crtica dentro de las organizaciones, y es por esto que de ello depende en gran medida el xito que en un momento dado, la organizacin pueda alcanzar. Actualmente las empresas y organizaciones enfocan gran parte de sus esfuerzos en detectar reas de mejora que les permitan optimizar su desempeo, con la finalidad de mantenerse en el nivel competitivo deseado. Uno de los aspectos que mayor importancia refleja hace referencia al uso de la informacin dentro de la empresa, de tal manera que a travs de su eficiente administracin sea posible la toma de decisiones certera y oportuna, que la conduzcan a alcanzar las metas y objetivos planteados. Uno de los factores que influyen para que el proceso de la administracin de la informacin se lleve a cabo de manera adecuada, es el uso de herramientas tecnolgicas que proporcionen el soporte necesario para agilizar estos procesos, y como consecuencia de ello, un incremento en el desempeo dentro de la empresa, as como tambin una reduccin de costos en la misma. Dentro de dichos instrumentos tecnolgicos, se, encuentran los programas o software. Un software se refiere a las instrucciones electrnicas que van a indicar al ordenador que es lo que tiene que hacer. De esta manera, la toma de decisiones se convierte en una variable crtica de xito dentro de las empresas, y es aqu donde radica la importancia de un sistema de

22

informacin. En la actualidad los sistemas de informacin juegan un papel fundamental para el xito de las empresas. Es un gran reto el que una organizacin pueda tener controladas las variables de planeacin, organizacin, control y direccin de la empresa. Sistemas de Informacin Transaccionales En la actividad cotidiana, toda organizacin interacciona con otras organizaciones de su entorno de actuacin. Esta interaccin consiste, bsicamente, en el intercambio de transacciones de bienes y/o servicios que provocan transacciones de informacin. Los sistemas de informacin transaccionales segn Pastor, J (2002): Son aquellos sistemas que se encargan de manera especfica de procesar tanto las transacciones de informacin provocadas por las interacciones formales entre el entorno y la organizacin como las transacciones generadas en el seno de la organizacin. (p.11). Sus principales caractersticas son: a) Suelen lograr ahorros significativos de mano de obra, debido a que automatizan

tareas operativas de la organizacin. b) Con frecuencia son el primer tipo de Sistemas de Informacin que se implanta

en las organizaciones. Se empieza apoyando las tareas a nivel operativo de la organizacin. c) Son intensivos en entrada y salida de informacin; sus clculos y procesos

suelen ser simples y poco sofisticados. d) Tienen la propiedad de ser recolectores de informacin, es decir, a travs de

estos sistemas se cargan las grandes bases de informacin para su explotacin posterior. e) Son fciles de justificar ante la direccin general, ya que sus beneficios son

visibles y palpables.

23

Mtodo Gray Watch El mtodo Watch es una metodologa que basa su desarrollo en los procesos gerenciales, tcnicos y de soporte que son necesarios para realizacin de una aplicacin empresarial. Segn Jons Montilva C, Judith Barrios A, Milagro Rivero A, creadores de Watch: El mtodo WATCH es un marco metodolgico que describe los procesos tcnicos, gerenciales y de soporte que deben emplear los equipos de trabajo que tendrn a su cargo el desarrollo de aplicaciones de software empresarial. Objetivos del Mtodo Gray Watch Gray Watch es un mtodo que ha sido elaborado expresamente para ser utilizado durante el desarrollo de aplicaciones empresariales, con la finalidad de: 1. Orientar a los equipos de desarrollo acerca de qu deben hacer y cmo deben

desarrollar una aplicacin empresarial. 2. Garantizar la uniformidad, consistencia, facilidad de integracin y calidad de

los distintos componentes arquitectnicos que integrarn una aplicacin empresarial. 3. Gestionar el desarrollo de aplicaciones empresariales como proyectos de

ingeniera, siguiendo los estndares de gestin de proyectos ms utilizados en la Industria del Software, a fin de garantizar que la aplicacin se entregue a tiempo y dentro del presupuesto acordado con el cliente. 4. Asegurar que en el desarrollo de cada aplicacin empresarial se empleen las

mejores, prcticas, tcnicas, herramientas, estndares y lenguajes aceptados internacionalmente para producir software de alta calidad. Caractersticas del Mtodo Gray Watch Las caractersticas ms relevantes del mtodo Gray Watch son las siguientes: Est slidamente fundamentado. Posee una base conceptual y metodolgica muy bien sustentada. El mtodo descansa en conceptos bien establecidos que se

24

derivan de la Ingeniera de Software y los Sistemas de Informacin Empresarial. En concreto, el mtodo emplea una arquitectura de dominio de tres capas que define los elementos principales de las aplicaciones empresariales modernas.

Metodolgicamente, el modelo ha sido elaborado tomando como referencia modelos de procesos bien conocidos o bien fundamentados, tales como el modelo RUPRational Unified Process (Krutchen, 2000) y versiones anteriores del mtodo WATCH (Montilva y Barrios, 2004b). Es estructurado y modular. Posee una clara estructura que facilita su comprensin y utilizacin. Esta estructura separa los tres elementos primordiales de un mtodo: el producto que se quiere elaborar, los actores que lo elaboran y el proceso que siguen los actores para elaborar el producto. Estos tres elementos definen los tres componentes del mtodo WATCH: modelo de productos, modelo de actores y modelo de procesos. Cada uno de ellos posee, a su vez, una estructura claramente visible y acorde al elemento que representa. Es de propsito especfico. El mtodo est dirigido al desarrollo de aplicaciones de software en entornos empresariales; es decir, al desarrollo de aplicaciones que apoyan uno o ms sistemas de negocios de una empresa. Esta orientacin concreta y especfica resuelve los problemas que tienen la mayora de los mtodos comerciales y acadmicos existentes, cuya generalidad va en detrimento de su aplicabilidad en software especializado. El mtodo no es apropiado para desarrollar software del sistema (sistemas operativos, utilitarios, middleware, etc.), ni software de programacin (compiladores, editores, entornos de programacin, etc.) Tampoco es til en el desarrollo de software de entretenimiento (videojuegos, herramientas multimedia, etc.). En aplicaciones especializadas, tales como sistemas de informacin geogrfica (GIS), sistemas de control, software educativo y software embebido, el usuario del mtodo debe hacer las adaptaciones pertinentes para ajustar el mtodo al dominio particular de este tipo de aplicaciones.

25

Es flexible y adaptable. Si bien el mtodo est dirigido al desarrollo de aplicaciones especializadas (aplicaciones de software empresarial), sus tres componentes pueden ser adaptados, con relativa facilidad, a otros tipos de productos de software. Esta labor, sin embargo, debe ser hecha por expertos en Ingeniera de Procesos de Software, para asegurar la correcta y efectiva adaptacin a otros tipos de aplicaciones. Emplea las Mejores Prcticas del Desarrollo de Software. Al igual que otros mtodos bien establecidos, tales como RUP (Krutchen, 2000), XP y OOSE (Jacobson, 1994), el mtodo WATCH emplea prcticas metodolgicas

internacionalmente aceptadas y utilizadas en la industria del software, las cuales, al ser aplicadas apropiadamente, contribuyen a resolver muchos de los problemas que, comnmente, se le atribuyen a los proyectos de software. Entre estas prcticas, se destacan las siguientes: Desarrollo de software iterativo, incremental y versionado. WATCH considera el proceso de desarrollo de aplicaciones como un proceso iterativo. Cada iteracin produce un componente o una nueva versin operativa de la aplicacin. Manejo eficiente de los requisitos. Una mala gestin de los requisitos de una aplicacin es una de las principales causas de problemas en proyectos de desarrollo de software. Para evitar estos problemas, WATCH emplea las mejores prcticas, tcnicas y procesos de la Ingeniera de Requisitos, las cuales facilitan las actividades de identificacin, anlisis, especificacin, validacin y gestin de requisitos. Reutilizacin de activos de software. El mtodo promueve la reutilizacin de activos de software. Ello reduce costos y aumenta la calidad de los productos de software elaborados usando el mtodo. Entre estos activos estn los siguientes: arquitecturas de dominio, patrones de diseo, componentes de software reutilizables y plantillas de documentos.

26

Modelado visual de la aplicacin. Para desarrollar una aplicacin informtica es indispensable modelar distintos aspectos de ella, en cada una de las etapas o fases de su desarrollo. WATCH emplea lenguajes de modelado grfico o visual ampliamente conocidos, tales como UML 2 (Eriksson et al, 2004) y UML Business (Eriksson and Penker, 2000). Estos lenguajes facilitan la representacin de la aplicacin desde diferentes perspectivas y reducen los problemas de comunicacin que normalmente surgen entre los expertos en Informtica y los usuarios. Desarrollo basado en modelos. Bajo este paradigma, el desarrollo de software es un proceso de transformacin gradual e iterativa de modelos elaborados usando lenguajes de modelado, tales como UML. Cada proceso tcnico del mtodo genera uno o ms modelos en UML 2 y/o UML Business. Estos modelos son transformados, gradualmente, en los procesos siguientes, hasta elaborar el producto final. La ventaja de esta prctica radica en que la transformacin de modelos se puede automatizar usando herramientas de desarrollo de software apropiadas, lo cual reduce significativamente el tiempo de desarrollo. Verificacin contina de la calidad de los productos. WATCH asegura la calidad de la aplicacin, a travs del uso de procesos bien definidos de Aseguramiento de la Calidad y Verificacin & Validacin de software (V&V). Los procesos V&V son aplicados a todos los productos intermedios y finales que se elaboran a lo largo del desarrollo de cada aplicacin. Programacin guiada por las pruebas. Para codificar los componentes de software, el mtodo emplea el enfoque de programacin guiada por las pruebas, la cual consiste en disear y preparar las pruebas de cada componente antes de iniciar su codificacin. De esta manera, la codificacin se hace con la intencin de pasar la prueba, lo cual garantiza una mayor calidad del cdigo producido. La codificacin y la prueba unitaria del componente se hacen paralela y coordinadamente usando herramientas de pruebas automatizadas.

27

Apropiada gestin de cambios. Los cambios en los requisitos y productos elaborados es una constante en el desarrollo de aplicaciones empresariales. Estos cambios pueden surgir en cualquier fase del desarrollo de una aplicacin, por lo que es necesario controlarlos apropiadamente, a fin de evitar que el proyecto se postergue continua o indefinidamente. WATCH emplea procesos bien definidos de Gestin de Requisitos y Gestin de la Configuracin de Software (SCM) que se encargan de controlar estos cambios. Emplea las Mejores Prcticas y Procesos de Gestin de Proyectos. El mtodo WATCH emplea procesos y prcticas establecidas en el cuerpo de conocimientos de gestin de proyectos PMBOK propuesto por el PMI (2004). Este cuerpo de conocimientos fue usado durante el diseo del mtodo para definir y elaborar los procesos de gestin y parte de los procesos de soporte. Integra los procesos de gestin con los procesos tcnicos y de soporte. WATCH define tres grupos de procesos: tcnicos, de gestin y de soporte. Los procesos tcnicos se relacionan con las actividades de anlisis, diseo, implementacin y pruebas de las aplicaciones. Los procesos de gestin se encargan de gerenciar el desarrollo de cada aplicacin como un proyecto de ingeniera; involucran, por lo tanto, actividades de planificacin, organizacin, administracin, direccin y control del proyecto. Por su parte, los procesos de soporte complementan los procesos tcnicos y gerenciales con actividades, tales como: el aseguramiento de la calidad, la gestin de la configuracin y la gestin de riesgos del proyecto. Estructura del Mtodo Gray Watch El mtodo WATCH est compuesto por tres modelos que describen los tres elementos claves de todo mtodo: el producto que se quiere elaborar, los actores que lo elaboran y el proceso que los actores deben seguir para elaborar el producto (ver Figura 2).

28

Mtodo Watch

Modelo de Productos

Modelo de Actores

Modelo de Procesos

Figura 2. Componentes de Mtodo Gray Watch. Modelos de productos. Este modelo identifica y describe los tipos de productos que se deben generar durante el desarrollo de una aplicacin empresarial. Estos tipos de productos se elaboran durante la ejecucin de los procesos tcnicos, de gestin o de soporte, que estn descritos en el Modelo de Procesos del mtodo.

Producto Watch

Producto Intermedio

Producto Entregable

Producto Tcnico

Producto de Gestin

Producto de Soporte

Aplicacin Entregable

Figura 3. Principales tipos de productos del Mtodo Gray Watch. Fuente: Montilva, J. (2008).

29

La Figura 3 recoge los principales tipos de productos que se deben producir a lo largo del desarrollo de una aplicacin empresarial y los clasifica de acuerdo a los grupos de procesos donde ellos se generan. Los productos intermedios son todos aquellos documentos, modelos, listas, libreras de software, matrices, etc., que se elaboran durante la ejecucin de los procesos tcnicos, de soporte y de gestin y que son necesarios para desarrollar la aplicacin. No son considerados productos finales o entregables, por cuanto no constituyen parte integrante de la aplicacin. Los productos entregables o finales del proyecto son todos aquellos que conforman la aplicacin empresarial propiamente dicha y que son entregados al cliente al final de un ciclo de desarrollo o de todo el proyecto. En este grupo se incluyen todas las versiones de la aplicacin que se elaboran durante la vida del proyecto. Cada versin entregable est compuesta de programas, bases de datos y manuales. Modelos de actores. El Modelo de Actores tiene como objetivos: a) Identificar los actores o interesados (stakeholders) que estn involucrados en el

desarrollo de aplicaciones empresarial. b) Describir las modalidades de organizacin del equipo de trabajo que

desarrollar los diferentes componentes arquitectnicos de una aplicacin empresarial. c) Definir los roles y responsabilidades de aquellos actores que integrarn el

equipo de trabajo.

30

Actor (Stakeholder)

Cliente

Promotor

Desarrollador

Usuarios

Figura 4. Clasificacin de los Actores. Fuente: Montilva, J. (2008). La Figura 4 clasifica, al ms alto nivel de abstraccin, a los actores que participan el desarrollo de aplicaciones aplicacin empresarial en cuatro grupos diferentes. Los clientes son aquellas personas o unidades organizacionales que contratan el desarrollo de la aplicacin y aportan los recursos financieros necesarios para su desarrollo. Los promotores son aquellas personas o unidades organizacionales que tienen inters en que la aplicacin se desarrolle y, por consiguiente, promueven y apoyan su desarrollo. Los desarrolladores son personas o grupos que participan en la ejecucin de los procesos tcnicos, de gestin y/o soporte del desarrollo de la aplicacin. Los usuarios son todas aquellas personas, unidades organizacionales u organizaciones externas que hacen uso de los servicios que ofrece la aplicacin. Modelos de procesos. El objetivo de este modelo es describir los procesos tcnicos, de gestin y de soporte que los equipos de trabajo deben emplear para desarrollar una aplicacin empresarial. Estos procesos se organizan en la forma de una cadena de valor, tal como se ilustra en la Figura 5.

31

Modelo de Negocio

Ingeniera de Requisitos

Diseo Arquitectnico

Diseo de Programacin Componentes & Integracin

Pruebas de la Aplicacin

Entrega de la Aplicacin

Gestin de Proyectos, Alcance, Tiempo, Recursos, y Contratos

Gestin de Riesgos

Gestin de la Configuracin

Gestin de la Calidad

Figura 5. Procesos del Mtodo Watch. Fuente: Montilva, J. (2008). Estos procesos se clasifican, segn su naturaleza con respecto al proceso de desarrollo de software, en tres grupos: procesos tcnicos, procesos de gestin y procesos de soporte (ver Figura 6).

Producto de Procesos

Producto Tcnico

Producto de Gestin

Producto de Soporte

Figura 6. Procesos del Mtodo Gray Watch.

32

El grupo de procesos tcnicos se encarga de organizar las actividades tecnolgicas que caracterizan el desarrollo de una aplicacin empresarial cualquiera e incluye los siguientes procesos: Modelado del negocio. Agrupa a las actividades encargas de caracterizar y entender el dominio de la aplicacin, es decir, el sistema de negocios para el cual se desarrolla la aplicacin. Ingeniera de requisitos. Incluye todas las actividades necesarias para identificar, analizar, especificar, validar y gestionar los requisitos que se le imponen a la aplicacin. Diseo arquitectnico. Congrega las actividades necesarias para especificar, disear y documentar la arquitectura de software que debe tener la aplicacin. Diseo de componentes. Organiza todas actividades de diseo detallado de los componentes arquitectnicos relacionados con la interfaz grfica de la aplicacin, sus componentes de software, su base de datos y su interaccin con otras aplicaciones. Programacin & integracin. Agrupa las actividades de diseo detallado, codificacin y prueba unitaria de cada uno de los componentes de software que integran la arquitectura de la aplicacin, as como las actividades de integracin y prueba de la integracin de estos componentes. Pruebas de la aplicacin. Ordena las actividades de pruebas de la aplicacin como un todo, incluyendo las pruebas funcionales, no-funcionales y de aceptacin de la aplicacin. Entrega de la aplicacin. Estructura el conjunto de actividades que preceden a la puesta en produccin de la aplicacin. Incluye la capacitacin de usuarios, la instalacin de la aplicacin en su plataforma de produccin u operacin, las pruebas de instalacin y la entrega final del producto. El grupo de procesos de gestin apoya la ejecucin de todos los procesos tcnicos y est relacionado con la gestin del proyecto. Se encarga de administrar el alcance, los tiempos, los costos, los recursos humanos y dems recursos que se requieran para desarrollar la aplicacin. Este grupo incluye los siguientes procesos: 33

Constitucin del proyecto. Establece las actividades necesarias para promover, justificar, aprobar e iniciar el proyecto. Planificacin del proyecto. Incluye las actividades encargadas de la planificacin del alcance, tiempos, recursos humanos, otros recursos y servicios que requiera el desarrollo de la aplicacin. Direccin del proyecto. Agrupa las actividades de conformacin del equipo de trabajo, capacitacin del personal que integra estos equipos, administracin de contratos con terceros, coordinacin de la ejecucin de las actividades del proyecto y administracin de los recursos asignados al proyecto, entre otros. Control del proyecto. Contiene las actividades necesarias para supervisar y controlar el alcance, tiempos, costos, recursos humanos y dems recursos que han sido asignados al proyecto. Cierre del proyecto. Organiza las actividades que se requieren para cerrar administrativa y tcnicamente el proyecto, una vez que concluya el desarrollo completo de la aplicacin. El grupo de procesos de soporte complementan los procesos de gestin y, al igual que estos ltimos, apoyan la ejecucin de todos los procesos tcnicos. Este grupo se relaciona con la calidad, los riegos y la configuracin de la aplicacin. Incluye los siguientes procesos: Gestin de riesgos. Agrupa las actividades necesarias para identificar, analizar, planificar respuestas, monitorear y controlar todos aquellos riesgos o eventos que puedan afectar negativamente el proyecto. Gestin de la configuracin. Organiza las actividades encargadas del control de los cambios que puedan surgir en la configuracin de la aplicacin, es decir, en los diferentes tems o productos que la integran y que se desarrollan a lo largo del proyecto. Gestin de la calidad. Contempla las actividades necesarias para garantizar la calidad de la aplicacin y todos los productos que la integran, as como la calidad del

34

proceso usado para producir estos productos. Este proceso est relacionado con las actividades de Aseguramiento de la Calidad del Software y la Verificacin & Validacin del Software. El orden en que los procesos del mtodo se ejecutan est inspirado en la metfora del reloj; metfora en la cual el proceso de desarrollo de software es visto como un reloj, cuyo motor son los procesos de gestin y soporte y cuyos diales constituyen los procesos tcnicos. Esta metfora determina la estructura estruct del modelo de procesos (ver Figura 7).

Figura 7. Estructura de los Modelos de Procesos. Procesos Fuente: Montilva, J. (2008). Como puede observarse, en la Figura 7 el orden de ejecucin es cclico, es decir, la aplicacin se desarrolla mediante la entrega de una o ms versiones de la aplicacin. Cada ciclo de desarrollo produce una nueva versin operativa de la aplicacin. Una versin es un producto operativo, esto e es, s, ejecutable y que provee ciertos servicios a sus usuarios. Cada nueva versin la agrega, a la anterior, nuevos servicios o funciones. Los ciclos de desarrollo se repiten hasta completar al conjunto total de servicios o funciones que demandan sus usuarios y que estn indicados en la

35

arquitectura de la aplicacin. El proyecto culmina cuando se entrega la ltima versin prevista de la aplicacin. Las versiones definen el carcter versionado o cclico del mtodo. Modelo de Negocio con la metodologa Gray Watch El proceso de Modelado de Negocios permite representar el ambiente o Sistema de Negocios (dominio de la aplicacin) dentro del cual se desarrollar la aplicacin; de manera que se puedan definir sus elementos claves, sus interrelaciones y el grado de influencia que stos pudieran tener sobre los requisitos tcnicos que la aplicacin empresarial debe satisfacer; especialmente, aquellos que se corresponden con la integracin de la aplicacin al Sistema de Negocios. Objetivos Fundamentales del Modelo de Negocio El Modelado de Negocios (MN) es el primer proceso tcnico del mtodo y tiene como objetivos fundamentales los siguientes: 1. 2. Entender el dominio de la aplicacin empresarial que se va a desarrollar. Comprender los problemas que motivan el desarrollo de la aplicacin

empresarial. 3. Facilitar la identificacin de las necesidades de informacin que tienen los

usuarios futuros de esta aplicacin. 4. Identificar los sistemas de negocios pares con lo que interacta (recibe y/o

entrega recursos, informacin, datos, coordina la ejecucin de actividades y tareas) el sistema objeto del modelado. 5. Facilitar la integracin de la aplicacin empresarial, una vez desarrollada, en el

Sistema de Negocios o dominio organizacional donde operar. Modelo de Productos del proceso Modelado de Negocio (MN) El proceso MN genera un producto final, denominado Modelo del Negocio de la Aplicacin o Modelo Empresarial. Este modelo representa al Sistema de Negocios

36

para el cual se desarrollar la aplicacin empresarial. Es un modelo compuesto por un conjunto de submodelos, cada uno de los cuales representa un elemento organizacional del Sistema de Negocios. La Figura 8 captura la estructura de un Modelo de Negocios mostrando cada uno de sus componentes, los cuales se elaboran durante la realizacin del proceso de Modelado MN.

modelo Modelo de Negocio

Documento Descripcin Sistema de Negocios

Documento Modelo de Objetiv os

modelo Modelo de Procesos de Negocio

modelo Modelo de Obj etos del Negocio

modelo Modelo de Reglas de Negocio

modelo Modelo de Actores

modelo Modelo de Ev entos

Documento Glosario de Trminos

diagrama UM... Descripcin Obj etiv os

diagrama UML Diagrama de Clases del Negocio

diagrama UML Cadena de Valor

diagrama UML Descripcin de Procesos

diagrama UML Diagrama de Activ idades

Documento Matriz de Roles y Responsabilidades

diagrama UML Estructura Organizativ a

Figura 8. Modelo de Productos asociados al Modelo de Negocios. Fuente: Manual del Mtodo Gray Watch. Descripcin de los Componentes del Modelo de Negocio de la Aplicacin Cada uno de los elementos organizacionales del Sistema de Negocios es representado mediante un sub-modelo que ser brevemente descrito en los prrafos siguientes. Cada uno de ellos es un producto intermedio que es ensamblado al final del proceso de modelado del negocio de la aplicacin para integrar y elaborar el documento que describe el Modelo de Negocios de la Aplicacin.

37

Definicin del sistema de negocios. El documento de Descripcin del Sistema de Negocios contiene la informacin relacionada con la identificacin de objetivos, alcance, componentes o subsistemas y las interacciones con otros sistemas, del sistema o contexto dentro del cual operar la aplicacin. Modelo de objetivos. Este modelo contiene el conjunto de objetivos de la organizacin representados como una jerarqua de objetivos. La raz de esta jerarqua representa la misin y la visin de la organizacin, pasando luego a especificar el objetivo general de la misma, que se descompone en un conjunto de sub-objetivos ms precisos; a su vez, stos se van descomponiendo de manera recursiva, hasta lograr establecer los objetivos de bajo nivel dentro de la organizacin, los cuales son asignados directamente a los procesos del negocio. Modelo de procesos del negocio. Este modelo representa el conjunto de procesos que se realizan en el Sistema de Negocios y que conllevan al logro de los objetivos de alto nivel del mismo. Como punto de partida se define la cadena de valor del Sistema de Negocios, la cual agrupa los procesos del negocio en dos grandes categoras: los procesos primarios y los procesos de apoyo. Los primeros representan la razn de ser del Sistema de Negocios, los segundos prestan el apoyo tcnico y administrativo necesario para que los primeros se lleven a cabo. Modelo de reglas del negocio. Este modelo representa el conjunto de reglas, normas y estndares de la organizacin que rigen y regulan la ejecucin de las actividades y procesos por parte de los actores. En algunos casos se deben incluir tambin aquellas leyes y/o regulaciones externas (provenientes del dominio ampliado del sistema de negocios) que afectan la ejecucin de los procesos y actividades del sistema de negocios. Modelo de eventos. Este modelo captura el conjunto de eventos tanto internos como externos al Sistema de Negocios que causan, disparan y condicionan la ejecucin de las diferentes actividades y procesos del negocio.

38

Modelo de actores y roles. Este modelo representa el conjunto de actores que participan en la ejecucin de las actividades y procesos del negocio. Los actores pueden ser miembros o no de la organizacin, mquinas, equipos o sistemas automatizados. Los actores son responsables, bajo la definicin de un rol, de la consecucin de un objetivo operacional (de muy bajo nivel) especfico. Un actor mediante la ejecucin, coordinacin y/o supervisin de un conjunto de actividades y/o tareas participa activamente en los procesos de negocios. Modelo de objetos del negocio. Es una representacin, del conjunto de objetos de negocios, que se crean, modifican, participan y/o fungen como recursos fundamentales en la ejecucin de las actividades asociadas a cada uno de los procesos del negocio. Estos recursos son utilizados tanto a nivel de operaciones bsicas como a nivel de los procesos de toma de decisiones en los diferentes niveles gerenciales de una organizacin o sistema. Subprocesos del proceso Modelo de Negocio El proceso Modelo de Negocio se descompone en siete subprocesos complementarios: modelado de objetivos, modelado de procesos del negocio, modelado de objetos del negocio, modelado de actores, modelado de reglas, modelado de eventos e integracin de modelos (ver Figura 9).

Modelado del Negocio

Modelado de Objetivos

Modelado de Procesos del Negocio

Modelado de Objetos del Negocio

Modelado de Actores

Modelado de Reglas del Negocio

Modelado de Eventos

Integracin de Modelos

Figura 9. Subprocesos del Proceso de Modelo de Negocio. Fuente: Manual del Mtodo Gray Watch.

39

Cada uno de los sub-modelos producidos en cada subproceso, es validado por un conjunto selecto de usuarios o interesados de la aplicacin empresarial. Estos usuarios e interesados tienen un conocimiento slido del Sistema de Negocios que se modela. Una vez validados todos los sub-modelos, se procede a integrarlos validando y documentando los sub-modelos y las relaciones entre ellos, de manera que se presentan como un todo que describe el Modelo del Negocio donde operar la Aplicacin.

Cuadro 1. Resumen de los Subprocesos del Proceso Modelo de Objetivos

Procesos Subprocesos Actividades 1. Definir objetivos generales del sistema de negocios. 2. Establecer alcance del sistema. 3. Definir subsistemas que componen el Sistema de Negocios si complejo. 4. Definir interacciones con otros sistemas de negocios. 1. Definir la visin del sistema de Negocios. 2. Definir su misin. 3. Definir sus objetivos de alto nivel. 4. Descomponer objetivos de alto nivel en sub-objetivos. 5. Construir jerarqua de objetivos. 6. Revisar la coherencia entre objetivos. 1. Analizar la jerarqua de objetivos. 2. Enmendar inconsistencias en la representacin de objetivos. 3. Documentar Modelo de Objetivos. Productos

Definicin del Sistema de negocios.

1. Descripcin del Sistema de Negocios.

Modelado de Objetivos

Construccin de la jerarqua de objetivos

1. Modelo de Objetivos: a) Jerarqua de Objetivos.

Validacin de jerarqua de objetivos

1. Modelo de Objetivos.

40

Cuadro 2. Resumen de los Subprocesos del Proceso Modelado de Procesos del Negocio
Procesos Subprocesos Actividades Productos 1. Cadena de Valor. 2. Modelo de Procesos del Negocio (Diagramas de procesos y subprocesos). 3. Diagramas de Actividad por subproceso de bajo nivel.

Modelado de Procesos del Negocio

Construccin de la Cadena de Valor.

1. Identificar los procesos fundamentales. 2. Identificar los procesos de apoyo. 3. Describir cada proceso usando diagramas de procesos (fundamental y de apoyo).

Descomposicin de procesos en subprocesos Modelado de Procesos del Negocio Validacin del Modelo de Procesos

1. Construir jerarqua de Procesos fundamentales y de apoyo. 2. Describir cada proceso del negocio de bajo nivel (subprocesos). 3. Elaborar diagramas de actividades para procesos bajo nivel. 1. Verificar coherencia en descomposicin de procesos. 2. Validar descripciones de procesos y diagramas de actividad. 3. Validar con el usuario/cliente. 4. Actualizar diagramas y modelos.

1. Cadena de Valor. 2. Modelo de Procesos del Negocio (Diagramas de procesos y subprocesos). 3. Diagramas de Actividad por subproceso de bajo nivel

Cuadro 3. Resumen de los Subprocesos del Proceso Modelado de Objetos del Negocio
Procesos Subprocesos Actividades 1. Identificar las clases de objetos del negocio. 2. Establecer tipos de relaciones entre clases de negocio. 3. Validar relaciones y clasificacin de clases de objetos. 1. Definir propiedades de las clases de objetos. 2. Definir comportamiento de clases de objetos. 3. Representar las relaciones entre clases de objetos. Productos

Identificacin de Objetos del Negocio. Modelado de Objetos del Negocio Organizacin de los Objetos del Negocio.

1. Lista y categoras de Objetos del Negocio.

1. Diagramas de Clases de Objetos.

41

Cuadro 3. (Cont.)
Procesos Subprocesos Actividades 1. Integracin del modelo de objetos. 2. Revisar diagramas de clases. 3. Corroborar objetos representados por procesos del negocio. 4. Documentar modelo de objetos. 1. Analizar los diagramas de procesos del negocio. 2. Analizar diagramas de actividades. 3. Analizar diagramas de clases 4. Identificar fuentes de reglas del negocio. Productos 1. Modelo de Objetos del Negocio. 2. Matriz procesos/objetos.

Elaboracin de Diagramas de Clases de Objetos de Negocio.

Validacin del Modelo de Objetos del Negocio

1. Listas de Reglas del Negocio.

Cuadro 4. Resumen de los Subprocesos del Proceso Modelado de Reglas del Negocio
Procesos Subprocesos Actividades 1. Analizar los diagramas de procesos del negocio. 2. Analizar diagramas de actividades. 3. Analizar diagramas de clases 4. Identificar fuentes de reglas del negocio. 1. Clasificar las reglas. 2. Seleccionar notacin de representacin. 3. Representar reglas en lenguaje natural y/o seudocdigo. 4. Incluir en glosario de trminos. 5. Incluir reglas en diagramas de clases. 1. Revisar reglas de representacin segn notacin. 2. Validar consistencia con los modelos de procesos y objetos del negocio. 3. Actualizar modelo de reglas y glosario. Productos

Identificacin de las Reglas del Negocio.

1. Listas de Reglas del Negocio.

Modelado de Reglas del Negocio

Representacin de las Reglas del Negocio.

Validacin del Modelo de Reglas del Negocio.

1. Descripcin de reglas en seudocdigo y/o lenguaje natural. 2. Modelo de Reglas del Negocio. 3. Glosario de Trminos.

42

Cuadro 5. Resumen de los Subprocesos del Proceso Modelado de Actores del Negocio.
Procesos Subprocesos Actividades 1. Retomar los diagramas de actividades de cada proceso. 2. Identificar los actores y su tipo de participacin (roles). 3. Modificar los diagramas de actividades. 1. Representar la distribucin de responsabilidades de los diferentes actores. 2. Modelar los actores, sus roles y sus responsabilidades. 3. Validar modelo de actores. 4. Construir matriz proceso/actividad/actor. 1. Determinar la estructura actual de la organizacin o del sistema de negocios. 2. Validar estructura con los objetivos modelados del sistema de negocios. a) Proponer modificaciones a la estructura actual. b) Disear nueva estructura organizativa. 3. Representar estructura en notacin UML. Productos

Identificacin de Actores. Modelado de Actores del Negocio. Especificacin de Actores y sus Roles.

1. Diagramas de Actividades.

1. Matriz proceso/actor/ actividad. 2. Modelo de Actores.

Modelado de Actores del Negocio

Caracterizacin de la Estructura Organizativa.

1. Estructura Organizativa.

Cuadro 6. Resumen de los Subprocesos del Proceso Modelado de Eventos del Negocio.
Procesos Subprocesos Identificacin de Eventos. Actividades 1. Detectar eventos. 2. Identificar tipo de evento y sus efectos. 1. Describir efectos en objetos del negocio. 2. Describir efectos en flujo de acciones. 3. Validar representacin de los eventos. 4. Construir matriz Procesos/Eventos. Productos 1. Descripcin de Eventos. 1. Modelo de Procesos del Negocio. 2. Modelo de Clases de Objetos del Negocio. 3. Matriz Procesos/ Eventos

Modelado de Eventos del Negocio

Representacin de Efectos Causados

43

Ingeniera de Requisitos El proceso de Ingeniera de Requisitos permite descubrir, analizar, especificar y validar el conjunto de requisitos funcionales y no-funcionales que la aplicacin empresarial debe satisfacer. Este proceso utiliza tcnicas, notaciones y herramientas orientadas por objetos para producir una documentacin completa y precisa de los requisitos que se le impondrn a la aplicacin empresarial. La entrada al proceso es el Modelo de Negocios producido por el proceso que lo antecede en la cadena de valor: el Modelado de Negocios. Los requisitos definen: 1. Lo que la aplicacin debe hacer: Las funciones que debe ejecutar, los datos

que debe capturar y almacenar y la informacin que debe producir. 2. La interaccin entre los usuarios y la aplicacin: La interfaz grfica usuario-

sistema (GUI). 3. Las restricciones bajo las cuales la aplicacin debe operar: La plataforma de

operacin de la aplicacin (Hardware/Software), la tecnologa de informacin que debe usar, las reglas y normas bajo las cuales debe operar y las interfaces con otros sistemas o aplicaciones. 4. Los atributos de calidad que la aplicacin debe satisfacer: Seguridad,

facilidad de uso, documentacin, utilidad, confiabilidad, etc. 5. Los requisitos se clasifican en dos tipos: funcionales y no funcionales. Los

requisitos funcionales establecen los servicios que debe proporcionar la aplicacin, determinan la funcionalidad de la aplicacin. Describen lo que la aplicacin empresarial deber hacer, esto es: su comportamiento; su interaccin con los usuarios y con su dominio de aplicacin (o sistema de negocios); y sus respuestas a eventos internos (mismo sistema) y externos (interaccin con otros sistemas). Los requisitos no-funcionales definen las limitaciones que se le impondrn al diseo de la aplicacin. Describen: las restricciones que se le aplican al desarrollo y operacin de la aplicacin, tales como el ambiente de desarrollo, los recursos disponibles para

44

desarrollo y el ambiente de operacin de la aplicacin (la plataforma H/S bajo la cual la aplicacin deber operar). 6. Las cualidades o atributos que el sistema debe satisfacer, tales como su

confiabilidad, utilidad, documentacin, rendimiento, interfaces con otros sistemas o aplicaciones. 7. Reglas y normas internas o externas al Sistema de Negocios que restringen o

condicionan la operacin. Modelo de Productos del Proceso de Ingeniera de Requisitos (IR) El conjunto de productos que se elaboran durante la ejecucin del proceso IR se presenta en la Figura 10. El producto principal del proceso IR es el Documento de Requisitos de la Aplicacin, el cual describe el conjunto de requisitos que establecen los usuarios de la aplicacin.

Documento Requisitos de la Aplicacin

Documento Documento Definicin de Requisitos

Documento Documento de Especificacin de Requisitos de la Aplicacin

Documento Plan de gestin de Requisitos

Documento Matriz de rastreo de requisitos Documento Lista de Requisitos de la Aplicacin modelo Modelo de Casos de Uso

modelo Modelo preliminar de clases

Documento Casos de Prueba de Aceptacin

producto tcnico Prototipo de la Aplicacin

Documento Matriz resuisitos v s requisitos

Documento Requisitos clasificados diagrama UML Diagramas preliminares de clases de obj etos

Documento Descripciones textuales

diagrama UML Diagramas de casos de uso

Figura 10. Modelo de Producto del Proceso de Ingeniera de Requisitos. Fuente: Manual del Mtodo Gray Watch.

45

Tal como lo ilustra la Figura 10, este documento est dividido en tres partes. La primera de ellas es la Definicin de Requisitos, la cual describe los requisitos desde la perspectiva de los usuarios de la aplicacin empresarial; est dirigida a los usuarios y dems interesados en la aplicacin. No tiene, por lo tanto, un carcter tcnico. La segunda es denominada Especificacin de Requisitos de la Aplicacin y consta de un conjunto de modelos elaborados usando la notacin UML; est dirigida al Grupo de Diseo que tiene a su cargo elaborar el diseo de la aplicacin, por consiguiente, tiene un carcter tcnico. La tercera parte corresponde al Plan de Gestin de Requisitos de la aplicacin, est dirigido al Grupo de Anlisis (Gestor de Requisitos) y establece el conjunto de actividades que se deben realizar para llevar a cabo este proceso, durante todo el proceso de desarrollo de la aplicacin. Subprocesos del Proceso IR La Ingeniera de Requisitos requiere de la ejecucin de cinco (5) subprocesos complementarios para especificar los requisitos de una aplicacin empresarial, como lo muestra la Figura 11.
Ingeniera de Requisitos

Descubrimiento de Requisitos

Anlisis de Requisitos

Especificacin de Requisitos

Validacin de Requisitos

Gestin de Requisitos

Figura 11. Subprocesos del Proceso de Ingeniera de Requisitos. A continuacin se presentan los flujos de trabajo de cada uno de los subprocesos que componen el proceso Ingeniera de Requisitos. Descubrimientos de requisitos. A continuacin se muestra en el Cuadro 7 la descripcin del flujo de trabajo de este subproceso.

46

Cuadro 7. Descripcin del Flujo de Trabajo: Descubrimiento de Requisitos

Actividad 1. 2. 3. 4. Tareas Identificar objetivos de la aplicacin. Definir alcance de la aplicacin. Determinar el problema a resolver. Establecer restricciones. Producto 1. Objetivos y Alcance de la aplicacin claramente definidos.

Determinar Objetivos de la Aplicacin.

Establecer dominio a partir del Modelo del Negocio.

Recolectar requisitos de la Aplicacin.

Consolidacin de Requisitos.

1. Analizar el modelo de negocios y determinar el dominio de la aplicacin. 2. Revisar documentacin relacionada con aplicaciones dentro del dominio identificado - reuso de requisitos. 3. Estudiar documentacin sobre aplicaciones en dominio. 4. Identificar los actores o interesados de la aplicacin y que participarn directamente en la definicin de requisitos. 1. Contactar interesados o actores miembros del sistema de negocios. 2. Recabar los requisitos (funcionales, no funcionales y de interfaz) de la aplicacin desde el punto de vista de cada actor o interesado. 3. Definir requisitos (funcionales, no funcionales y de interfaz) a partir del modelo de negocios. 4. Definir requisitos (funcionales, no funcionales y de interfaz) a partir de aplicaciones del dominio. 5. Definir requisitos de interaccin de la aplicacin con otros sistemas dentro o fuera del mismo sistema de negocios. 1. Verificar consistencia entre los requisitos recolectados. 2. Unificar requisitos recolectados.

1. Lista de actores clasificados.

1. Planillas (Volre) de recoleccin de requisitos. 2. Modelos de casos de uso con sus respectivos escenarios

1. Lista de requisitos de la aplicacin

Anlisis de Requisitos. A continuacin en el Cuadro 8 se muestra la descripcin del flujo de trabajo de este subproceso. Cuadro 8. Descripcin del Flujo de Trabajo: Anlisis de Requisitos
Actividad Proceso 1. Revisar los requisitos recolectados. 2. Determinar criterios de agrupamiento, generalmente va asociado al tipo de requisitos: funcionales y no-funcionales. 3. Agrupar requisitos en las categoras establecidas. Producto

Clasificar Requisitos Recolectados.

1. Requisitos clasificados.

47

Cuadro 8 (Cont.)
Actividad Proceso 1. Establecer contradicciones entre requisitos. 2. Determinar grado de completitud de requisitos. 3. Determinar solapamientos y dependencia entre requisitos. 4. Elaborar matriz de requisitos .vs. requisitos. 1. Eliminar incompatibilidades y contradicciones entre requisitos. 2. Redefinir requisitos. 3. Determinar viabilidad de los requisitos. 4. Establecer prioridades de los requisitos junto con el usuario. 1. Describir en mayor nivel de detalle los requisitos recolectados: a) Elaborar diagramas de caso de uso para explorar funcionalidad. b) Definir escenarios de utilizacin y describiros textualmente. c) Elaborar diagramas de clases de objetos para representar objetos persistentes y requeridos para la funcionalidad. d) Describir atributos y restricciones de la aplicacin. 1. Revisar requisitos con los actores o interesados. 2. Ajustar y corregir los diagramas de casos de uso, clases y la definicin de restricciones y atributos. Producto 1. Matriz de requisitos .vs. Requisitos. 1. Lista de requisitos factibles con prioridades acordadas con usuario o interesado. 1. Diagramas de casos de uso. a) Descripciones textuales. 2. Diagramas preliminar de clases. 3. Diagramas de estados. 1. Documento de definicin de requisitos

Definir interacciones entre requisitos.

Depurar lista de Requisitos.

Refinar Requisitos Clasificados.

Validar Requisitos.

Especificacin de Requisitos. A continuacin se muestra en el Cuadro 9 la descripcin del flujo de trabajo de este subproceso. Cuadro 9. Descripcin del Flujo de Trabajo: Especificacin de Requisitos
Actividad Definicin del documento de especificacin. Tareas 1. Establecer la estructura y contenido de la especificacin de requisitos. a) Especificar requisitos desde el punto de vista del actor o interesado: funcionales y no funcionales. b) Especificar requisitos desde el punto de vista del desarrollador: Modelos del sistema funcional, esttico o estructural y dinmico. Productos 1. Estructura y contenido de documento.

48

Cuadro 9 (Cont.)
Actividad Especificar requisitos desde el punto de vista del interesado (stakeholder) Proceso 1. Documentar tcnicamente los requisitos de la aplicacin (punto de vista del grupo de desarrollo): a) Refinar los diagramas y modelos preliminares de casos de uso, clases de objetos, estados y transiciones, objetos y secuencia. 2. Documentar atributos, restricciones y otras especificaciones segn la estructura y contenido definidos para el documento. Producto 1. Documento de especificacin de requisitos de la aplicacin.

Validacin de Requisitos. A continuacin se muestra en el Cuadro 10 la descripcin del flujo de trabajo de este subproceso. Cuadro 10. Descripcin del Flujo de Trabajo: Validacin de Requisitos
Actividad Revisar documento de especificacin de requisitos. Construir un prototipo para validar los requisitos. Ajustar los modelos y descripciones de la especificacin de requisitos. Definir pruebas y parmetros de aceptacin de la aplicacin. Tareas 1. Validar la estructura y el contenido del documento. 2. Validar especificacin tcnica de los requisitos. 1. Desarrollar un prototipo que emule la funcionalidad (segn los casos de uso) y la interfaz que tendra la aplicacin. 2. Validar funcionalidad e interfaz de la aplicacin. 1. Modificar los modelos y descripciones de especificacin tcnica atendiendo a los resultados de validacin del prototipo. 2. Verificar consistencia e integridad de la especificacin tcnica. 1. Determinar parmetros de aceptacin de la aplicacin. 2. Definir casos de prueba de aceptacin. 3. Verificar, con los interesados, los parmetros de aceptacin y los casos de prueba de aceptacin de la aplicacin. Producto 1. Documento validado.

1. Prototipo de la aplicacin.

1. Modelos actualizados y validados.

1. Conjunto de casos de prueba de aceptacin de la aplicacin.

Gestin de Requisitos. A continuacin se muestra en la Cuadro 11 la descripcin del flujo de trabajo de este subproceso.

49

Cuadro 11. Descripcin del Flujo de Trabajo: Gestin de Requisitos

Actividad Tareas 1. Definicin de los medios y modos de almacenamiento de los requisitos de la aplicacin Base de Datos de apoyo a la gestin. 2. Establecer procedimientos y mecanismos de actualizacin, mantenimiento y control de requisitos. 1. Seguir los procedimientos y mecanismos establecidos para la gestin de cambios en los requisitos. 2. Realizar los cambios en los requisitos. 3. Modificar documento de especificacin de requisitos. 4. Asegurar consistencia e integridad de la base de datos una vez realizados los cambios 1. Definir mbito de influencia del cambio sobre los requisitos de la aplicacin. 2. Elaborar matriz de rastreo de requisitos. 3. Asegurar actualizacin de documentos y modelos de la aplicacin. Productos

Planificar el proceso de gestin de modificaciones en los requisitos.

1. Plan de gestin de Requisitos.

Realizar cambios en los requisitos.

1. Documento de especificacin actualizado. 2. Base de datos de Requisitos actualizada.

Rastreo de cambios en los requisitos.

1. Matriz de rastreo de requisitos.

Cadena de Valor La cadena valor es una herramienta de gestin diseada por Michael Porter que permite realizar un anlisis interno de una empresa, a travs de su desagregacin en sus principales actividades generadoras de valor. Se denomina cadena de valor, pues considera a las principales actividades de una empresa como los eslabones de una cadena de actividades (las cuales forman un proceso bsicamente compuesto por el diseo, produccin, promocin, venta y distribucin del producto), las cuales van aadiendo valor al producto a medida que ste pasa por cada una de stas. La cadena de valor categoriza las actividades que producen valores aadido en una organizacin en dos tipos: las actividades primarias y las actividades de apoyo o auxiliares de micro.

50

Actividades Primarias Las actividades primarias se refieren a la creacin fsica del producto, su venta y el servicio postventa, y pueden tambin a su vez, diferenciarse en sub-actividades. El modelo de la cadena de valor distingue cinco actividades primarias: Logstica interna. Comprende operaciones de recepcin, almacenamiento y distribucin de las materias primas. Operaciones (produccin). Procesamiento de las materias primas para transformarlas en el producto final. Logstica externa. Almacenamiento de los productos terminados y distribucin del producto al consumidor. Marketing y ventas. Actividades con las cuales se da a conocer el producto. Servicio. De post-venta o mantenimiento, agrupa las actividades destinadas a mantener, realzar el valor del producto, mediante la aplicacin de garantas. Actividades de Apoyo Las actividades primarias estn apoyadas o auxiliadas por las tambin denominadas actividades secundarias: Infraestructura de la organizacin. Actividades que prestan apoyo a toda la empresa, como la planificacin, contabilidad y las finanzas. Direccin de recursos humanos. Bsqueda, contratacin y motivacin del personal. Desarrollo de tecnologa, investigacin y desarrollo. Obtencin, mejora y gestin de la tecnologa. Abastecimiento (compras). Proceso de compra de los materiales. A continuacin se observa en la Figura 12 la representacin grfica de una Cadena de Valor.

51

Figura 12. Representacin de una Cadena de Valor. Lenguaje Unificado de Modelado (UML) El Unified Modeling Language (UML), es un lenguaje que permite modelar (analizar y disear), construir y fundamentar los elementos que conforman un sistema orientado a objetos. Segn los autores Grady Booch, Ivar Jacobson y Jim Rumbaugh (2000): El UML es un lenguaje estndar para el modelado de software - lenguaje para visualizar, especificar, construir y documentar los artefactos de un sistema con gran cantidad de software. Lenguaje utilizado por el Proceso Unificado. Lenguaje que permite a los desarrolladores visualizar el producto de su trabajo (artefactos) en esquemas o diagramas estandarizados. (p. 430) Historia de UML Durante los aos ochenta y principios de los noventa Grady Booch, James Rumbaugh, e Ivar Jacobson trabajaban por separado en desarrollo de notaciones para el anlisis y diseo de sistemas orientados a objetos. Los tres llegaron por separado a obtener bastante reconocimiento. Luego esto cambi en octubre de 1994 cuando Rumbaugh se uni a Booch en Rational. Los dos expertos comenzaron de inmediato a trabajar juntos en el desarrollo de una metodologa que combinara sus respectivos avances y permitiera representar un sistema de informacin orientado a objetos.

52

Posteriormente, el nombre metodologa unificada cambi rpido a lenguaje unificado de modelado. En Rational, en 1995 se les uni Ivar Jacobson. Los tres trabajaron juntos y en 1997 fue publicada la versin 1.0 de UML. El Object Management Group (OMG), una asociacin de las compaas lderes en tecnologas de objetos en el mundo, asumi la responsabilidad de organizar un estndar internacional para el UML. Desde ese momento en adelante, tal como afirma Schach (2005): El UML es actualmente la notacin estndar internacional indiscutible para representar los sistemas de informacin (p. 46). Objetivos de UML Algunos de sus objetivos principales son los siguientes, planteados por sus autores al momento de su creacin: 1. Ser un lenguaje de modelado de propsito general que puedan usar todos los

modeladores. No tiene propietario y est basado en el comn acuerdo de gran parte de la comunidad informtica. 2. No pretende ser un mtodo de desarrollo completo. No incluye un proceso de

desarrollo paso a paso. 3. Ser tan simple como fuera posible pero manteniendo la capacidad de modelar

toda la gama de sistemas que se necesite construir. (Jacobson y otros, 2000) Diagramas UML Un diagrama es la representacin grfica de un conjunto de elementos, visualizado la mayora de las veces como un grafo conexo de nodos (elementos) y arcos (relaciones). Los diagramas se dibujan para visualizar el sistema desde diferentes perspectivas, de forma que un diagrama es una proyeccin de un sistema. Los diagramas UML pueden clasificarse de dos maneras: estructurales o de comportamiento. Los estructurales permiten visualizar, especificar, construir y

53

documentar los aspectos estticos de un sistema, dentro de stos se encuentran los siguientes: diagrama de clases, diagrama de objetos, diagrama de componentes y diagrama de despliegue. Por su parte, los de comportamiento permiten visualizar, especificar, construir y documentar los aspectos dinmicos de un sistema, bajo estas caractersticas se pueden incluir los diagramas de casos de uso, diagramas de interaccin, que a su vez estn compuestos por los diagramas de secuencia y diagramas de colaboracin; diagramas de estado y por ltimo, diagramas de actividades. A continuacin se describen algunos de los diagramas ms usados, dando atencin especial a los empleados en el desarrollo del presente proyecto: 1. Diagramas Estructurales a. Diagramas de Clases

Tal como lo define Schmuller (2001): Una clase es una categora o grupo de cosas que tienen atributos y acciones similares (p. 27). Por lo tanto, los diagramas de clases son diagramas de estructura esttica que muestran las clases del sistema y sus interrelaciones. Sirven para facilitar la comunicacin con los futuros usuarios del sistema y resultan especialmente tiles para determinar las caractersticas necesarias que tendr el sistema, lo cual hace posible que los clientes indiquen importantes detalles de los problemas que requieren ser resueltos. En otras palabras, los diagramas de casos de uso describen qu es lo que debe hacer el sistema, pero no cmo hacerlo. Schmuller (2001), explica cul es la notacin de este tipo de diagramas, tal como se puede observar en la Figura 13: Un rectngulo es el smbolo que representa a la clase y se divide en tres reas. El rea superior contiene el nombre, el rea central contiene los atributos y el rea inferior las acciones (p. 28). Luego, varios rectngulos de este tipo conectados entre s por lneas muestran la manera en que las clases se relacionan entre s y producen el diagrama.

54

Figura 13. El smbolo UML de una clase. Los atributos o caractersticas de las clases pueden ser de tres tipos, segn el grado de comunicacin y visibilidad de ellos con el entorno, estos son: 1. Pblicos (+): indican que el atributo ser visible tanto afuera como dentro de la

clase, es decir, es accesible desde todos t lados. 2. Privados (-): indican que el atributo solo ser accesible desde dentro de la clase

(solo sus mtodos lo pueden acceder) 3. Protegidos (#) indica que el atributo no ser accesible desde afuera de la clase,

pero si podr ser accesado por mtodos de la clase. Los mtodos u operaciones de una clase son la forma en cmo esta interacta con su entorno, estos pueden tener las caractersticas: 1. Publico (+): indican que el mtodo ser visible tanto afuera como dentro de la

clase, es decir, es accesible desde todos lados. 2. Privados (-): indican que el mtodo solo ser accesible desde dentro de la clase

(solo otros mtodos de la clase lo pueden acceder) 3. Protegidos (#) indica que el mtodo no ser accesible desde afuera de la clase,

pero si podr ser accesado por mtodos de la clase. En un diagrama de clases, los vnculos entre clases se representan por lneas, a las que se les da diferentes caractersticas, dependiendo del tipo de relacin. En los extremos de esas lneas se representan las relaciones y puede colocarse colo el rol que asume cada clase en esa relacin. En el Cuadro 12 se observan las relacion relaciones que puede haber entre clases.

55

Cuadro 12. Relaciones entre las Clases

Nombre Asociacin Agregacin Composicin Dependencia Generalizacin Dependencia Descripcin Asociacin bidireccional entre clases con roles y multiplicidad. Relacin de subordinacin Relacin es parte de Relacin de dependencia Relacin es un (a)

b.

Diagramas de Objetos

Los diagramas de objetos se pueden considerar un caso especial de un diagrama de clases en el que se muestran instancias especficas de clases (objetos) en un momento particular del sistema. Los diagramas de objetos utilizan un subconjunto de los elementos de un diagrama de clase. Los diagramas de Objetos no presentan arquitecturas que varen de sus orrespondientes diagramas de Clases, pero reflejan la multiplicidad y los roles a los que las clases instanciadas podran servir. Ellos son muy tiles en la comprensin de diagramas de Clases complejos, al crear diferentes casos en los que se aplican las relaciones y las clases. Los diagramas de objetos representan intantaneas de intancias de los elementos que aparecen en los diagramas de clases. A continuacin se muestra el Cuadro 13 que representan los elementos de los diagramas de objetos. Cuadro 13. Elementos de los Diagramas de Objetos
Control

Actor Objeto Colaboracin tem de informacin Limite

Entidad Flujo de informacin Asociar Dependencia

56

c.

Diagrama de Componentes

Un diagrama de componentes es un diagrama tipo del Lenguaje Unificado de Modelado. Un diagrama de componentes representa cmo un sistema de software es dividido en componentes y muestra las dependencias entre estos componentes. Los componentes fsicos incluyen archivos, cabeceras, bibliotecas compartidas, mdulos, ejecutables o paquetes. Los diagramas de Componentes prevalecen en el campo de la arquitectura de software pero pueden ser usados para modelar y documentar cualquier arquitectura de sistema. Debido a que estos son ms parecidos a los diagramas de casos de usos estos son utilizados para modelar la vista esttica y dinmica de un sistema. Muestra la organizacin y las dependencias entre un conjunto de componentes. No es necesario que un diagrama incluya todos los componentes del sistema, normalmente se realizan por partes. Cada diagrama describe un apartado del sistema. d. Diagramas de Despliegue

Los Diagramas de Despliegue muestran la disposicin fsica de los distintos nodos que componen un sistema y el reparto de los componentes sobre dichos nodos. Estos diagramas muestran la configuracin en funcionamiento del sistema, incluyendo su hardware y su software. Un Diagrama de Despliegue modela la arquitectura en tiempo de ejecucin de un sistema mostrando la configuracin de los elementos de hardware y mostrando cmo los elementos y artefactos del software se trazan en esos nodos. En el Cuadro 14 se observan los elementos que componen un diagrama de despliegue.

57

Cuadro 14. Elementos del Diagrama de Despliegue

Elementos Nodo Objeto fsico en tiempo de ejecucin que representa un recurso computacional. Se utiliza para identificar cualquier servidor o terminal de trabajo. Componente Representa todos los tipos de elementos de software que entran en la fabricacin de aplicaciones informticas.

2.

Diagramas de Comportamientos a. Diagrama de Casos de Usos

Un Diagrama de Casos de Uso muestra la relacin entre los actores y los casos de uso del sistema. Representa la funcionalidad que ofrece el sistema en lo que se refiere a su interaccin externa. En el diagrama de casos de uso se representa tambin el sistema como una caja rectangular con el nombre en su interior. Los casos de uso estn en el interior de la caja del sistema, y los actores fuera, y cada actor est unido a los casos de uso en los que participa mediante una lnea. Los elementos que pueden aparecer en un Diagrama de Casos de Uso son: actores, casos de uso y relaciones entre casos de uso. 1. Actores

Un actor es algo con comportamiento, como una persona (identificada por un rol), un sistema informatizado u organizacin, y que realiza algn tipo de interaccin con el sistema. Se representa mediante una figura humana dibujada con palotes. Esta representacin sirve tanto para actores que son personas como para otro tipo de actores.

Actor

Figura 14. Actor. 58

2.

Casos de Uso

Un caso de uso es una descripcin de la secuencia de interacciones que se producen entre un actor y el sistema, cuando el actor usa el sistema para llevar a cabo una tarea especfica. Expresa una unidad coherente de funcionalidad, y se representa en el Diagrama de Casos de Uso mediante una elipse con el nombre del caso de uso en su interior. El nombre del caso de uso debe reflejar la tarea especfica que el actor desea llevar levar a cabo usando el sistema.

Caso de Uso

Figura 15. Caso de Uso. 3. Relaciones entre Casos de Uso

Un caso de uso, en principio, debera describir una tarea que tiene un sentido completo para el usuario. Sin embargo, hay ocasiones en las que es til describir una interaccin con un alcance menor como caso de uso. La razn para utilizar estos casos de uso no completos en algunos casos, es mejorar la comunicacin en el equipo de desarrollo, el manejo nejo de la documentacin de casos de uso. Para el caso de que queramos utilizar estos casos de uso ms pequeos, las relaciones entre estos y los casos de uso ordinarios pueden ser de los siguientes tres tipos. Cuadro 15. Tipos de Relaciones en Diagramas de Casos de Uso
Tipos de Relaciones Asociacin Comunicar un actor con un caso de uso, o con otro actor. Un caso de uso incluido es bsicamente un paso de caso de uso o base, que decidimos extraer aparte a para mejorar la comprensin, por la importancia que tiene el paso por si mismo, o para factorizar comportamiento comn que se repite en varios casos de usos. Cuando un caso de uso base tiene ciertos puntos (puntos de extensin) en los cuales, dependiendo de ciertos criterios, se van a realizar una interaccin adicional. El caso de uso que se extiende describe un comportamiento opcional del sistema.

Include

Extends

59

b.

Diagramas de Actividad

Los diagramas de actividad ilustran el flujo de funcionalidad en un sistema. En otras palabras, muestran una visin simplificada de lo que ocurre durante un proceso y son muy tiles para representar los procesos de negocios. Puede decirse que es una extensin del diagrama de estados. Es importante recalcar que aunque un diagrama de actividad es muy similar en definicin a un diagrama de flujo (tpicamente asociado en el diseo de Software), estos no son lo mismo. Se pudiera considerar que un diagrama de actividad describe el problema, mientras un diagrama de flujo describe la solucin. En estos diagramas a cada actividad se le representa por un rectngulo con las puntas redondeadas. El procesamiento de una actividad se lleva a cabo y, al realizarse, se contina con la siguiente actividad. Una flecha representa la transicin de una a otra actividad. Adems cuenta con un punto inicial, representado por un crculo relleno, y uno final, representado por una diana. La Figura 16 sirve de ilustracin.

Actividad 1

Actividad 2

Figura 16. Transaccin de una Actividad a otra. En el Cuadro 16 se observan los elementos que componen un diagrama de actividad.

60

Cuadro 16. Elementos del Diagrama de Actividad

Nombre Accin Smbolo Descripcin Nodo de actividad, primitiva ejecutable de asignacin o computacin Nodo de inicio Nodo de control que indica el inicio de un flujo de control cuando una actividad es invocada Nodo de fin de actividad Nodo de control que indica el fin de todos lo flujos dentro de una actividad. Muestra el fin de la actividad. Flujo de control Eje de actividad para flujo de control. Conecta dos acciones. Usado para indicar secuencias. Nodo de sincronizacin Nodo de control que divide un flujo en dos o ms flujos concurrentes conc (paralelos). Nodo de concurrencia (Join) Nodo de decisin Nodo de control que sincroniza mltiples flujos. Nodo de control que selecciona entre dos o ms flujos de salida.

c. Diagramas de Estados Un diagrama de estados es un diagrama utilizado para identificar cada una de las rutas o caminos que puede tomar un flujo de informacin luego de ejecutarse cada proceso. Permite identificar bajo qu argumentos se ejecuta cada uno de los procesos y en qu momento podran tener una variacin. E El l diagrama de estados permite visualizar de una forma secuencial la ejecucin de cada uno de los procesos.

61

Figura 17. Simbologa de los Diagramas de Estados. d. Diagrama de Secuencia Un diagrama de secuencia muestra la interaccin de un conjunto de objetos de una aplicacin a travs del tiempo, es decir muestra los objetos participantes y los mensajes que se intercambian entre ellos a lo largo del tiempo. El diagrama de secuencia permite observar la perspectiva cronolgica de las interacciones, muestra la secuencia explcita de mensajes y son mejores para especificaciones de tiempo real y para escenarios complejos. En el Cuadro 17 se observan los elementos que componen un diagrama de secuencia. Cuadro 17. Elementos del Diagrama de Secuencia
Smbolo Descripcin La lnea vertical representa la existencia de un objeto a lo largo de un tiempo determinado.
Actor

Lnea de v ida del obj eto

62

Cuadro 17 (Cont).
Objeto

Un objeto se representa como una lnea vertical punteada, lnea de vida, con un rectngulo de encabezado.

Activacin, periodo de tiempo en el cual el objeto se encuentra desarrollando alguna

operacin.

Objeto

Objeto2

El envi de mensajes entre objetos se denota mediante una lnea solida dirigida, desde el objeto que emite el mensaje hacia el objeto que

Mensaje()

lo ejecuta.

e. Diagramas de Procesos Es una representacin grfica de los pasos que se siguen en toda una secuencia de actividades, dentro de un proceso o un procedimiento, identificndolos mediante smbolos de acuerdo con su naturaleza; incluye, adems, toda la informacin que se considera necesaria para el anlisis, tal como distancias recorridas, cantidad considerada y tiempo requerido. Con fines analticos y como ayuda para descubrir y eliminar ineficiencias, es conveniente clasificar las acciones que tienen lugar durante un proceso dado en cinco clasificaciones. Estas se conocen bajo los trminos de operaciones, transportes, inspecciones, retrasos o demoras y almacenajes. Las siguientes definiciones cubren el significado de estas clasificaciones en la mayora de las condiciones encontradas en los trabajos de diagramado de procesos, se puede observar en Cuadro 18.

63

Cuadro 18. Clasificacin de las acciones de un Diagrama de Procesos

Smbolo Actividad Definicin Ocurre cuando un objeto est siendo modificado en sus caractersticas, se esta creando o agregando algo Operacin o se esta preparando para otra operacin, transporte, inspeccin o almacenaje. Una operacin tambin ocurre cuando se est dando o recibiendo

informacin o cuando se est planeando algo. Ocurre cuando un objeto o grupo de ellos son Transporte movidos de un lugar a otro, excepto cuando tales movimientos forman parte de una operacin o inspeccin. Ocurre cuando un objeto o grupo de ellos son Inspeccin examinados para su identificacin o para comprobar y verificar la calidad o cantidad de cualesquiera de sus caractersticas. Ocurre cuando se interfiere en el flujo de un objeto o Demora grupo de ellos. Con esto se retarda el siguiente paso planeado. Ocurre cuando un objeto o grupo de ellos son Almacenaje retenidos y protegidos contra movimientos o usos no autorizados. Cuando se desea indicar actividades conjuntas por el Actividad combinada mismo operario en el mismo punto de trabajo, los smbolos empleados para dichas actividades

(operacin e inspeccin) se combinan crculo inscrito en el cuadro.

Enterprise Architect Enterprise Architect es una herramienta CASE (Computer Aided Software Engineering - Ingeniera de Software Asistida por Ordenador) para el diseo y construccin ccin de sistemas de software. sta soporta la especificacin de UML 2.0, que describe un lenguaje visual por el cual se pueden definir mapas o modelos de un proyecto. Es s una herramienta progresiva que cubre todos los aspectos del ciclo de

64

desarrollo, proporcionando una trazabilidad completa desde la fase inicial del diseo a travs del despliegue y mantenimiento. Tambin provee soporte para pruebas, mantenimiento y control de cambio. Usando las notaciones y semnticas del UML, se puede disear y modelar sistemas de software complejos desde su comienzo. Es posible usar Enterprise Architect para generar y realizar ingeniera directa de cdigo fuente en varios lenguajes, importar diseos de base de datos desde la fuente de datos ODBC, e importar y exportar modelos usando el XMI estndar de la industria. Enterprise Architect y el Lenguaje UML La plataforma de modelado de Enterprise Architect est basada en el Lenguaje Unificado de Modelado (UML). Este lenguaje se dise para ser flexible, extensible y amplio, pero lo suficientemente genrico para servir como fundamento para todas las necesidades de modelado de sistemas. Con esta especificacin, existe un amplio rango de elementos caracterizados por los diagramas a los que sirven, y los atributos que proveen. Todo se puede especificar ms an utilizando estereotipos, etiquetas y perfiles. Enterprise Architect tambin provee diagramas y elementos personalizados adicionales, para otros intereses de modelado. Macromedia Dreamweaver Adobe Dreamweaver es una aplicacin en forma de estudio (basada en la forma de estudio de Adobe Flash) enfocada a la construccin y edicin de sitios y aplicaciones Web basadas en estndares. Creado inicialmente por Macromedia (actualmente producido por Adobe Systems). Es el programa de este tipo ms utilizado en el sector del diseo y la programacin Web, por sus funcionalidades, su integracin con otras herramientas como Adobe Flash y, recientemente, por su soporte de los estndares del World Wide Web Consortium.

65

Macromedia Dreamweaver es un editor de HTML visual, diseado para desarrolladores profesionales. Dreamweaver hace muy fcil el crear complejas pginas Web dinmicas, con la conocida tcnica de "arrastrar y soltar", permitiendo que los diseadores puedan crear entornos Web y animaciones sofisticadas sin tener que escribir una sola lnea de cdigo. Dreamweaver genera HTML dinmico, que usa JavaScript y "cascade style sheets". El cdigo resultante es compatible con las ltimas versiones de los navegadores actuales, adems podrs generar pginas que funcionen bien en versiones anteriores. Caractersticas Dreamweaver permite un fcil desarrollo en aplicaciones web optimizando las pginas para las diferentes versiones de los navegadores, mantiene el cdigo fuente editable, de esta forma se puede manejar el cdigo en distintos editores. Incluye un editor de imagen integrado, diferentes colores para la sintaxis HTML, soporte para posicionamiento absoluto, poder hacer cambios por todas las pginas usando elementos comunes, cliente de FTP integrado (con soporte Firewall), soporte XML, plantillas, e interfaz personalizado. Ventajas 1. Puede ampliar y personalizar el editor, ya que en este programa, sus rutinas

(como la de insertar un hipervnculo, una imagen o aadir un comportamiento) estn hechas en Javascript-C, lo que le ofrece una gran flexibilidad en estas materias. 2. Las versiones originales de la aplicacin se utilizaban como simples editores

WYSIWYG. Sin embargo, versiones ms recientes soportan otras tecnologas Web como CSS, JavaScript y algunos frameworks del lado servidor. 3. Est disponible tanto para la plataforma Windows como para MAC, se puede

ejecutar en plataformas establecidas en UNIX utilizando programas que implementan las API's de Windows, tipo Wine. 4. Dreamweaver permite que alguien no especializado pueda crear aplicaciones de

forma rpida y fcil, debido a que oculta cdigo HTML de cara al usuario.

66

Macromedia Fireworks 8 Fireworks 8 es una suite de diseo vectorial que agrupa texto, diseo, ilustracin, edicin de imgenes, URL, JavaScript, y herramientas de animacin. Diseado desde un primer momento para satisfacer las necesidades de los diseadores Web profesionales, Fireworks 8 incluye opciones tan avanzadas como: exportacin de pre-visualizacin visual, control total sobre las paletas de color y la compresin de las mismas, generacin automtica de botones de estado y mensajes en JavaScript, control total sobre textos y efectos que se pueden editar en cualquier momento. Definicin de Trminos Accin: es la unidad fundamental de especificacin de comportamiento en un diagrama de actividades. (Montilva, J. y Barrios, J., 2006). Actor del negocio: es un miembro (sistema, maquina, persona o grupo de personas), que tiene bajo su responsabilidad la ejecucin de uno o ms roles. (Montilva y Barrios, 2006). Clase: es un conjunto de objetos de negocio que tienen los mismos atributos (Montilva, J. y Barrios, J., 2006). Diagrama: es la representacin grfica de un conjunto de elementos y sus relaciones. Los diagramas se utilizan para visualizar un sistema desde diferentes perspectivas. (Montilva y Barrios, 2006). Evento: es una accin de muy corta duracin que activa la ejecucin de un proceso de negocio, una actividad o una accin y/o cambia el estado de un objeto de negocio. (Montilva y Barrios, 2006). Flujo de Control: indica el orden de ejecucin de las acciones. (Montilva, J. y Barrios, J., 2006).

67

Flujo de Objetos: muestra los objetos que entran y/o salen de las acciones. Objetos que son transformados por las acciones. (Montilva, J. y Barrios, J., 2006). Metas: se define la palabra metas (un ao o ms) como punto de referencia o aspiraciones que las organizaciones deben lograr, con el objeto de alcanzar objetivos a un plazo ms largo. (Iiguez, 1998). Misin: es el propsito de la organizacin que la distingue de otras organizaciones y que establece el cubrimiento de operaciones, productos, servicios y personal para lograr dicho propsito. (Montilva y Barrios, 2006). Modelado: es un proceso de abstraccin y simbolizacin usado para entender y manejar la complejidad de un sistema. (Montilva y Barrios, 2006). Modelo del Negocio: es una representacin de los elementos que constituyen una organizacin o parte de ella y de sus interrelaciones. (Montilva y Barrios, 2006). Modelo: esquema o representacin de un sistema u objeto que se elabora para simplificar su comprensin y estudio. (Montilva y Barrios, 2006). Negocio: es una empresa u organizacin o una parte de ella. (Montilva y Barrios, 2006). Objetivo: es un resultado establecido de antemano y que, por lo general, refleja el modo de pensar de la organizacin, orienta el desempeo empresarial y permite evaluar la continuidad del negocio (Chiavenato, 2000). Objetos de negocios: son aquellas cosas o entidades que intervienen en los procesos de negocio. Son creados, usados, requeridos, consumidos, producidos por los procesos. (Montilva y Barrios, 2006). Objetos fsicos: son aquellas cosas que estn presentes en el mundo real.(Montilva, J. y Barrios, J., 2006).

68

Objetos abstractos: son cosas intangibles; pero tienen existencia propia. No son temporales ni espaciales, slo existen en la mente humana. (Montilva, J. y Barrios, J., 2006). Organizacin: es un sistema de actividades humanas (realizadas con o sin instrumentos) diseadas y formalmente realizadas con el propsito de cumplir un fin prefijado y explcitamente predefinido. (Montilva, J. y Barrios, J., 2006). Proceso: es un conjunto de actividades interrelacionadas que permiten alcanzar un objetivo del negocio. (Montilva y Barrios, 2006). Procesos de apoyo: son los procesos administrativos y tcnicos bsicos de cualquier organizacin, requeridos por los procesos primarios. (Montilva y Barrios, 2006). Procesos fundamentales: son la razn de ser de la organizacin. (Montilva y Barrios, 2006). Regla de negocio: conjunto de condiciones que gobiernan un proceso de negocio de tal manera que ste pueda ocurrir de una manera aceptable para la empresa. (Montilva y Barrios, 2006). Rol: es un conjunto de actividades que tienen un objetivo bien definido dentro de la organizacin. (Montilva y Barrios, 2006). Sistema: conjunto de entes independientes entre s mismos que se encuentran en interrelacin con ellos mismos y con el ambiente que los rodea. (Montilva y Barrios, 2006).

69

CAPTULO IV MARCO METODOLGICO Tipo de investigacin El proceso de investigacin es un elemento fundamental para el desarrollo individual, profesional y social, investigar es un proceso humano, intencionado y sistmico. Hurtado (2008) seala que la investigacin es: Un proceso continuo y organizado mediante el cual se pretende conocer algn evento (caracterstica, proceso, hecho o situacin), ya sea con el fin de encontrar leyes generales, o simplemente con el propsito de obtener respuestas particulares a una necesidad o inquietud determinada (p.22). El tipo de investigacin fue seleccionado haciendo uso del enfoque holstico, la misma autora seala que los mtodos, tcnicas, tcticas y estrategias no son genricos para cualquier investigacin; los mtodos son diferentes en funcin del tipo de investigacin y del objetivo que pretende lograr (p.98). De acuerdo a lo expresado, el tipo de investigacin del presente proyecto es de tipo proyectiva, la cual define Hurtado, J. (2008) como: Este tipo de investigacin propone soluciones a una situacin determinada a partir de un proceso de indagacin. Implica explorar, describir, explicar y proponer alternativas de cambio, mas no necesariamente ejecutar la propuesta. Todas la investigaciones que implican el diseo o creacin de algo con base en un proceso investigativo tambin entran en esta categora. (p.114) Nivel de la investigacin La investigacin holstica ha organizado y clasificado los objetivos, as como sus correspondientes tipos de investigacin, de acuerdo con su complejidad, los

objetivos pueden ser de diferentes niveles. Habiendo definido que el tipo de investigacin clasificndola de tipo proyectiva, se puede afirmar que se ubica en un nivel comprensivo, el cual Hurtado, J. (2008) define como: El nivel comprensivo alude a las explicaciones que generan el evento. (p.92). Diseo de la investigacin Otra de las actividades importantes de una investigacin es precisar de dnde provendrn los datos indispensables para desarrollar los diversos estudios necesarios, los cuales permitirn a su vez elaborar conclusiones acertadas sobre el fenmeno en cuestin. Esto es conocido como el diseo de la investigacin, Hurtado (2008) dice que: El diseo alude a las decisiones que se toman en cuanto al proceso de recoleccin de datos, que permitan al investigador lograr la validez interna de la investigacin, es decir tener un alto grado de confianza de que sus conclusiones no son erradas. (p 147) La informacin necesaria para realizar el Modelado de Negocios y la Ingeniera de Requisitos proviene de fuentes vivas y no vivas, por ende el diseo es mixto, es decir, de campo y documental. Arias (2006), define el diseo de campo como: Es aquella que consiste en la recoleccin de datos directamente de los sujetos investigados, o de la realidad donde ocurren los hechos (datos primarios), sin manipular o controlar variable alguna, es decir, el investigador obtiene la informacin pero no altera las condiciones existentes. (p.31) El mismo autor, refirindose al diseo documental expresa que: Es un proceso basado en la bsqueda, recuperacin, anlisis, crtica e interpretacin de datos secundarios, es decir, los obtenidos y registrados por otros investigadores en fuentes documentales: impresas, audiovisuales o electrnicas. Como en toda investigacin, el propsito de este diseo es el aporte de nuevos conocimientos. (p.27).

71

Poblacin La poblacin es el conjunto de unidades o elementos que se encuentran definidos y que son objetos de estudio en una investigacin, con la finalidad de entender sus caractersticas y cualidades, por lo tanto, Fidias Arias (2006), afirma lo siguiente: la poblacin es un conjunto finito o infinito de elementos con caractersticas comunes para los cuales sern extensivas las conclusiones de la investigacin (p.81). Para la presente investigacin las entidades que son objeto de estudio son de tipo finita, debido a que la Coordinacin de Desarrollo en el Punto de Venta en la actualidad se encuentra representada por tres empleados que laboran en dicha institucin. Muestra La muestra es una parte caracterstica de la poblacin bajo estudio. Segn Fidias Arias (2006), la muestra es subconjunto representativo y finito que se extrae de la poblacin accesible (p.83). Considerando las caractersticas esenciales de una poblacin finita y manejable, se establece como la muestra, por lo cual no se aplicaran ciertas criterios mustrales de una investigacin. Por consiguiente, la muestra est conformada por la misma cantidad de elementos que constituyen a la poblacin. Acerca de lo explicado antes, el autor Fidias Arias (2006), indica lo siguiente: Si la poblacin, por el nmero de unidades que la integran, resulta accesible, no ser necesario extraer una muestra. En consecuencia, se podr investigar u obtener datos de toda la poblacin objetivo... (p.82). Tcnicas e Instrumentos de Recoleccin de Datos Para el logro de los objetivos planteados del presente estudio, se proceder a la implementacin de una serie de tcnicas e instrumentos para la obtencin de los datos

72

y la informacin necesaria, dirigidos a alcanzar los fines propuestos. Hurtado (2008), expresa que: Las tcnicas tienen que ver con los procedimientos utilizados para la recoleccin de datos, es decir, el cmo. Estas pueden ser de revisin documental, observacin, encuesta y tcnicas sociomtricas, entre otras. Los instrumentos representan la herramienta con la cual se va a recoger, filtrar y codificar la informacin, es decir, el con qu. Los instrumentos pueden estar elaborados e incluso normalizados, como es el caso de los tests y algunas escalas. (p.153). En tal sentido, se emplearn las tcnicas de observacin directa, la entrevista no estructurada, la revisin documental y el cuestionario, con la finalidad de obtener informacin relevante y fundamental para la investigacin. La tcnica de observacin directa se fundamenta en la definicin establecida por Arias (2006): consiste en visualizar o captar mediante la vista, en forma sistemtica, cualquier hecho, fenmeno o situacin que se produzca en la naturaleza o en la sociedad, en funcin de unos objetivos de investigacin preestablecidos (p.69). Se establece que el nivel de participacin de esta tcnica es de tipo no participativo, en relacin a eso el autor seala que: la observacin directa de tipo no participativa es la que se realiza cuando el investigador observa de manera neutral sin involucrarse en el medio o realidad donde se realiza el estudio (p.69). Esta herramienta permitir la recopilacin de datos fundamentales relacionados con el desarrollo de las actividades administrativas y tcnicas de la Coordinacin de Desarrollo en el Punto de Venta. Otra tcnica que ser de gran utilidad es la entrevista no estructurada, dado que permite la formulacin de preguntas de forma libre al personal que labora en la CDPV. Segn el autor Arias (2006) establece la siguiente definicin: En esta modalidad no se dispone de una gua de preguntas elaboradas previamente. Sin embargo, se orienta por unos objetivos preestablecidos, lo que permite definir el tema de la entrevista. (p. 73).

73

Por otro lado, la revisin bibliogrfica o documental es definida por Hurtado (2000) como: proceso mediante el cual un investigador recopila, revisa, analiza, selecciona y extrae informacin de diversas fuentes, acerca de un tema particular (p.119). Fueron consultados libros, tesis de grado, y temas relacionados con el objeto bajo estudio. Igualmente se revis informacin particular de la Coordinacin de Desarrollo en el Punto de Venta que permitieron conocer aspectos propios de la misma. El cuestionario segn el autor Arias (2006) es la modalidad de encuesta que se realiza de forma escrita mediante un instrumento o formato de papel contentivo de una serie de preguntas. Se le denomina cuestionario autoadministrado porque debe ser llenado por el encuestado, sin intervencin del encuestador. (p.74). Para la elaboracin de cuestionarios se tomaron como base los lineamientos de la tcnica Escalamiento tipo Likert segn Hernndez (2000) como: Consiste en un conjunto de tems presentados en forma de afirmaciones o juicios, ante los cuales se pide la reaccin de los sujetos. Es decir, se presenta cada afirmacin y se pide al sujeto se externe su reaccin eligiendo uno de los cinco puntos de la escala, a cada punto se le asigna un valor numrico. (p.368) Tcnicas de Anlisis de Datos Una vez recopilados todos los datos provenientes de las diversas fuentes, es conveniente hacer uso de alguna tcnica lgica o estadstica que permita la categorizacin y anlisis de los mismos, a fin de extraer de ellos informacin relevante para el proyecto, que de otra manera no se pudiese consolidar. Una de esas herramientas es la que Hurtado (2000) denomina anlisis de contenido, este autor expresa que la misma puede ser utilizada en investigaciones descriptivas para hacer un diagnstico y agrupar contenidos significativos de una serie de entrevistas, conversaciones u observaciones (p.487).

74

Tomando en cuenta lo anteriormente citado, el presente trabajo hace uso de tcnicas cualitativas de anlisis como la organizacin de los datos y la presentacin de informacin siguiendo los pasos y actividades planteadas por la metodologa Gray Watch, que incluyen la generacin de diagramas y la elaboracin de matrices que relacionan todos los modelos entre s y al igual que los diagramas UML correspondientes a la ingeniera de requisitos desarrollada. Diseo Operativo Etapa I: Estudio de la Situacin Actual: Esta etapa consisti en la bsqueda de toda la informacin que describiera al sistema de negocios, para as entrar en contacto con la organizacin y entender su importancia, fines y metas dentro de la corporacin, divisar su estructura organizativa, comprender cada uno de los procesos que ejecuta, tener un primer acercamiento a la Coordinacin de Desarrollo en el Punto de Venta y as conocer su ubicacin y su funcionamiento, descubrir cules son los departamentos con las que se relaciona, cmo est constituida, quines la conforman, cules son sus procesos principales y de apoyo para la realizacin de sus actividades cotidianas. Etapa II: Modelo de Negocio: Esta etapa comprendi la elaboracin de cada uno de los modelos definidos por la metodologa Gray Watch. Inicialmente se construy el Modelo de Objetivos, posteriormente se desarrollaron los Modelos de Procesos, Objetos, Actores, Reglas y Eventos, por ltimo la integracin de los submodelos, los cuales en conjunto exponen de manera integral las actividades realizadas por los especialistas de la Coordinacin en estudio.

75

Etapa III: Ingeniera de Requisitos: Una vez desarrollado el Modelado de Negocio para la Coordinacin de Desarrollo en el Punto de Venta se procede a realizar la Ingeniera de Requisitos, el primer paso comprendi la obtencin y captura de los requisitos para conocer cuales son las necesidades de los usuarios, continuando con el anlisis de los requisitos a fin de transformar los mismos en condiciones apropiadas para ser tratadas en el diseo, luego se procedi a definir los requisitos a un nivel apropiado de detalle, una vez definidos se realiz la verificacin de estos para concluir con la validacin comprobando que se correspondan con los planteados inicialmente, est validacin tiene como misin demostrar que la definicin de los requisitos especifica realmente el sistema que el usuario necesita o el cliente desea. Tambin se propone un prototipo de la aplicacin empresarial. Cuadro Operativo En el Cuadro 19 se resumen todas las etapas, pasos y cada una de las actividades realizadas durante el desarrollo de la ingeniera de requisitos, la misma vincula cada objetivo especfico de la investigacin con las diferentes etapas del proceso.

76

Cuadro 19. Cuadro Operativo

Etapas Metodologa Pasos Actividades -Recopilar informacin sobre la situacin actual. -Revisar estructura organizativa. -Entrevistar al personal de CDPV. -Estudiar los procesos que se lleven a cabo en la coordinacin. -Definicin del sistema de negocio -Construccin de la jerarqua de objetivos -Validacin de jerarqua de objetivos -Construccin de la cadena de valor -Descomposicin de procesos en subprocesos -Validacin del modelo de procesos -Identificacin de objetos del negocio. -Organizacin de los objetos del negocio -Elaboracin de diagrama de clases de objetos de negocio. -Validacin del modelo de objetos del negocio -Identificacin de las reglas del negocio. -Representacin de las reglas del negocio. -Validacin del modelo de reglas del negocio. -Identificacin de actores. -Especificacin de actores y sus roles. -Identificacin de eventos. -Representacin de efectos causados. Objetivos Especficos Estudiar la situacin actual situacin actual de los procesos de ejecucin de las estrategias de mercadeo (Impulsos y Fachadas).

I: Estudio de la situacin actual

Investigacin y Reconocimiento

Modelo de objetivos

GRAY WATCH

Modelo de procesos del negocio

II: Modelo de negocio

Modelo de objetos del negocio

Disear el modelo de negocio de la Coordinacin de Desarrollo en el Punto de Venta de Cervecera Polar C.A

77

Modelo de reglas de negocio Modelo de actores del negocio Modelo de eventos del negocio

Cuadro 19 (Cont.)
Etapas Metodologa Pasos Actividades -Determinar objetivos de la aplicacin. -Establecer dominio a partir del modelo de negocio. -Recopilar requisitos -Consolidar requisitos -Clasificar requisitos recopilados -Definir interacciones entre requisitos -Refinar requisitos -Validar -Definicin documento de especificacin -Especificar requisitos desde el punto de vista del interesado -Revisar documento de especificaciones -Construir un prototipo para validar -Ajustar los modelos descripcin de la especificacin de requisitos -Definir pruebas y parmetros de aceptacin de la aplicacin -Planificar el proceso de gestin de modificaciones -Realizar cambios -Rastreo de cambios en los requisitos Objetivos Especficos

Descubrimiento

III: Ingeniera de Requisitos

GRAY WATCH

Anlisis

Definir los requisitos funcionales y no funcionales con el propsito de la automatizacin de los procesos Impulsos y Fachadas

Especificacin

78

Validacin

Gestin

Formular la ingeniera de requisitos de aplicacin empresarial para los procesos de ejecucin de las estrategias de mercadeo (Impulsos y Fachadas) en la Coordinacin de Desarrollo en el Punto de Venta de Cervecera Polar C.A

CAPTULO V RESULTADOS A continuacin se muestran los resultados de las actividades que se llevaron acabo durante el transcurso del proyecto para el cumplimiento de los objetivos planteados. Para cumplir la planificacin del desarrollo de la ingeniera de requisitos para la Coordinacin de Desarrollo en el Punto de Venta de Cervecera Polar C.A, se aplic la metodologa de desarrollo de software Gray Watch, la cual estuvo dividida en tres etapas que abarcan desde el estudio de la situacin actual hasta formulacin la ingeniera de requisitos. Etapa I: Estudio de la situacin actual La tcnica de recoleccin de datos como el cuestionario siguiendo los lineamientos del escalamiento tipo Likert se tomo como base para ser aplicada con la finalidad de medir la percepcin y/o apreciacin de diferentes tems al personal perteneciente a la Coordinacin de Desarrollo en el Punto de Venta, la cual resulto muy eficiente ya que a partir de los resultados obtenidos se pudo conocer la definicin que tiene el personal acerca de la coordinacin, adems se identificar los focos problemticos mientras otros tems permitieron definir las premisas bsicas para la formulacin de una misin y visin para la Coordinacin de Desarrollo en el Punto de Venta. A continuacin se presentan todos los tems estudiados:

Cuadro 20. Distribucin Absoluta y Porcentual acerca que la Coordinacin de Desarrollo en el Punto de Venta se define como unidad encargada de la aplicacin de las estrategias de mercadeo como son Impulsos y Fachadas. Frecuencia Absoluta 3 0 0 0 0 3

Opciones Muy de acuerdo De acuerdo Ni de acuerdo, ni en desacuerdo En desacuerdo Muy en desacuerdo Totales

% 100 0 0 0 0 100

Muy de acuerdo 0% De acuerdo Ni de acuerdo, ni en desacuerdo En desacuerdo Muy en desacuerdo

100%

Grfico 1. Representacin grfica tem 1 Al analizar la situacin actual de la Coordinacin de Desarrollo en el Punto de Venta, referente a la definicin de la misma como unidad encargada de la aplicacin de las estrategias de mercadeo como son Impulsos y Fachadas, , se pudo observar que el 100% del personal de dicha coordinacin se encuentran totalmente de acuerdo, esto representa que conocen la razn de ser de est, lo cual es una ventaja significativa para la organizacin.

80

Cuadro 21. Distribucin Absoluta y Porcentual acerca de la existencia de misin, visin, valores y objetivos formalmente definidos para la a Coordinacin de Desarrollo en el Punto de Venta Venta. Frecuencia Absoluta 0 0 0 1 2 3

Opciones Muy de acuerdo De acuerdo Ni de acuerdo, ni en desacuerdo En desacuerdo Muy en desacuerdo Totales

% 0 0 0 33 67 100

Muy de acuerdo 0% 33% 67% De acuerdo Ni de acuerdo, ni en desacuerdo En desacuerdo Muy en desacuerdo

Grfico 2. Representacin grfica tem 2 Al analizar la situacin actual de la Coordinacin de Desarrollo en el Punto de Venta, referente a la existencia de misin, visin, valores y objetivos formalmente definidos, , se pudo observar que el 33% se encuentran en desacuerdo y el restante 67% del personal de dicha coordinacin se encuentran totalmente en desacuerdo, por lo tanto manifiestan que no poseen misin, visin, valores y objetivos, lo cual es inadecuado para cualquier organizacin o departamento debido a que su personal se encuentra desorientado. entado.

81

Cuadro 22. Distribucin Absoluta y Porcentual las principales funciones que realiza la coordinacin coordinacin. Frecuencia Absoluta 2 1 0 0 0 3

Opciones Muy de acuerdo De acuerdo Ni de acuerdo, ni en desacuerdo En desacuerdo Muy en desacuerdo Totales

% 67 33 0 0 0 100

Muy de acuerdo 0% 33% 67% De acuerdo Ni de acuerdo, ni en desacuerdo En desacuerdo Muy en desacuerdo

Grfico 3. Representacin grfica tem 3

Al analizar la situacin actual de la Coordinacin de Desarrollo en el Punto de Venta, referente a las principales funciones de est, el 33% expresan que se encuentran de acuerdo mientras que el 67% del personal de dicha coordinacin se encuentran totalmente de acuerdo, esto confirma que los procesos Impulsos y Fachadas son las principales funciones de la unidad en estudio. est

82

Cuadro 23. Distribucin Absoluta y Porcentual acerca del objetivo general de la Coordinacin de Desarrollo en el Punto de Venta. Venta Frecuencia Absoluta 1 1 1 0 0 3

Opciones Muy de acuerdo De acuerdo Ni de acuerdo, ni en desacuerdo En desacuerdo Muy en desacuerdo Totales

% 34 33 33 0 0 100

0% 33% 34%

Muy de acuerdo De acuerdo Ni de acuerdo, ni en desacuerdo En desacuerdo Muy en desacuerdo

33%

Grfico 4. Representacin grfica tem 4 Al analizar la situacin actual de la Coordinacin de Desarrollo en el Punto de Venta, referente al objetivo general de est, se pudo observar que el 33% opina ni de acuerdo, ni en desacuerdo, otro 33% se encuentran de acuerdo y el restante 34% del personal de dicha coordinacin se encuentran totalmente de acuerdo, por otra parte, esto refleja ja que el personal no posee la misma percepcin acerca del objetivo general de la coordinacin, lo cual es inadecuado para la misma, se recomienda realizar acciones correctivas.

83

Cuadro 24. Distribucin Absoluta y Porcentual acerca de la existencia de normas y procedimientos bien definidos para las solicitudes de Impulsos y Fachadas. Frecuencia Absoluta 2 1 0 0 0 3

Opciones Muy de acuerdo De acuerdo Ni de acuerdo, ni en desacuerdo En desacuerdo Muy en desacuerdo Totales

% 67 33 0 0 0 100

0% 33%

Muy de acuerdo De acuerdo

67%

Ni de acuerdo, ni en desacuerdo En desacuerdo Muy en desacuerdo

Grfico 5. Representacin grfica tem 5 Al analizar la situacin actual de la Coordinacin de Desarrollo en el Punto de Venta, referente a la existencia de normas y procedimientos bien definidos, se pudo observar que el 33% se encuentran en desacuerdo y el 67% del personal de dicha coordinacin se encuentran totalmente en desacuerdo, por lo tanto manifiestan que no cuentan con normas y procedimientos bien definidos, , lo cual es inadecuado inadecuad para

84

cualquier organizacin o departamento debido a que su personal se encuentra desorientado. Cuadro 25. Distribucin Absoluta y Porcentual acerca del grado de eficiencia en el l control de documentos que se lleva en la coordinacin. Frecuencia Absoluta 3 0 0 0 0 3

Opciones Muy de acuerdo De acuerdo Ni de acuerdo, ni en desacuerdo En desacuerdo Muy en desacuerdo Totales

% 100 0 0 0 0 100

Muy de acuerdo 0% De acuerdo Ni de acuerdo, ni en desacuerdo En desacuerdo Muy en desacuerdo

100%

Grfico 6. Representacin grfica tem 6 Al analizar la situacin actual de la Coordinacin de Desarrollo en el Punto de Venta, referente al grado de eficiencia en el control de documentos, se pudo observar que el 100% del personal de dicha coordinacin se encuentran totalmente tota de acuerdo, esto representa la poca eficiencia en control de documentos mediante herramientas ofimticas como (Word, Excel) que para el momento se realizaba no cubre con requerimientos del personal.

85

Cuadro 26. Distribucin Absoluta y Porcentual acerca de la disposicin de tecnologa de punta en la Coordinacin de Desarrollo en el Punto de Venta Opciones Muy de acuerdo De acuerdo Ni de acuerdo, ni en desacuerdo En desacuerdo Muy en desacuerdo Totales Frecuencia Absoluta 1 2 0 0 0 3 % 33 67 0 0 0 100

0% 33%

Muy de acuerdo De acuerdo Ni de acuerdo, ni en desacuerdo En desacuerdo Muy en desacuerdo

67%

Grfico 7. Representacin grfica tem 7 Al analizar la situacin actual de la Coordinacin de Desarrollo en el Punto de Venta, referente ferente a la disponibilidad de tecnologa de punta a su alcance, alcance se pudo observar r que el 33% opino totalmente de acuerdo y el 67% restante reflejo estar de acuerdo, representando en general que tiene a su disposicin tecnologa de punta lo cual es vital para un buen desempeo de las labores que se llevan a cabo.

86

Cuadro 27. Distribucin Absoluta A y Porcentual acerca de la consideracin del recurso humano como el activo ms valioso para empresa. Opciones Muy de acuerdo De acuerdo Ni de acuerdo, ni en desacuerdo En desacuerdo Muy en desacuerdo Totales Frecuencia Absoluta 3 0 0 0 0 3 % 100 0 0 0 0 100

Muy de acuerdo 0% De acuerdo Ni de acuerdo, ni en desacuerdo En desacuerdo Muy en desacuerdo

100%

Grfico 8. Representacin grfica tem 8 Al analizar la situacin actual de la Coordinacin de Desarrollo en el Punto de Venta, referente a la percepcin que muestra la empresa calificando el recurso humano como el activo ms valioso que posee, se pudo observar que el 100% del personal de dicha coordinacin se encuentran totalmente de acuerdo, esto representa una gran ventaja ya que el recurso humano se siente motivado a seguir trabajando, t el trabajador siente a la empresa como suya por lo cual da a da se empea en alcanzar las metas y objetivos de la empresa.

87

Cuadro 28. Distribucin Absoluta y Porcentual acerca del inters por el bienestar de sus trabajadores por parte de Cervecera Polar C.A. Opciones Muy de acuerdo De acuerdo Ni de acuerdo, ni en desacuerdo En desacuerdo Muy en desacuerdo Totales Frecuencia Absoluta 3 0 0 0 0 3 % 100 0 0 0 0 100

Muy de acuerdo 0% De acuerdo Ni de acuerdo, ni en desacuerdo En desacuerdo Muy en desacuerdo

100%

Grfico 9. Representacin grfica tem 9 Al analizar la situacin actual de la Coordinacin de Desarrollo en el Punto de Venta, referente a la percepcin que muestra la empresa inters por el bienestar de sus trabajadores, se pudo observar que el 100% del personal de dicha coordinacin se encuentran totalmente de acuerdo, esto representa un beneficio significativo ya que los trabajadores se sienten seguros y respaldados por Cervecera Polar C.A de esta manera ra afianzando los vnculos entre la empresa y los trabajadores, por ende el empleado se enfoca mucho ms en la organizacin y no desea quedar mal ante ella en ningn momento.

88

Cuadro 29. Distribucin Absoluta y Porcentual acerca del empeo diario en mantener y crecer como departamento para as a a su vez contribuir afianzar el liderazgo de la empresa en el mercado. Opciones Muy de acuerdo De acuerdo Ni de acuerdo, ni en desacuerdo En desacuerdo Muy en desacuerdo Totales Frecuencia Absoluta 1 2 0 0 0 3 % 33 67 0 0 0 100

0% 33%

Muy de acuerdo De acuerdo

67%

Ni de acuerdo, ni en desacuerdo En desacuerdo Muy en desacuerdo

Grfico 10. Representacin grfica tem 10 Al analizar la situacin actual de la Coordinacin de Desarrollo e en el Punto de Venta, referente al empeo diario en mantener y crecer como departamento para as a su vez contribuir con el liderazgo de la empresa en el mercado, mercado, se pudo observar que el 33% % del personal de dicha coordinacin se en encuentran cuentran totalmente de acuerdo, adems el restante 67% opinan que estn de ac acuerdo, uerdo, lo que refleja que la unidad en estudio est enfocada a contribuir con la misin y la visin de la empresa.

89

Cuadro 30. Distribucin Absoluta y Porcentual acerca que la Coordinacin de Desarrollo en el Punto de Venta contribuye positivamente afianzar el liderazgo de los productos y marcas de Cervecera Polar C.A Opciones Muy de acuerdo De acuerdo Ni de acuerdo, ni en desacuerdo En desacuerdo Muy en desacuerdo Totales Frecuencia Absoluta 2 1 0 0 0 3 % 67 33 0 0 0 100

0% 33%

Muy de acuerdo De acuerdo 67% Ni de acuerdo, ni en desacuerdo En desacuerdo Muy en desacuerdo

Grfico 11. Representacin grfica tem 11 Al analizar la situacin actual de la Coordinacin de Desarrollo en el Punto de Venta, referente a la incidencia positiva que mantiene el departamento con la finalidad de afianzar el liderazgo de los productos y marcas de Cervecera Polar C.A, C.A se pudo observar que el 33% del personal de dicha coordinacin se encuentran de acuerdo, adems el restante 67% opinan que estn totalmente de acuerdo, lo que refleja que la unidad en estudio est enfocada a contribuir con la misin y la visin de la empresa.

90

Cuadro 31. Distribucin Absoluta y Porcentual acerca acer de la imagen que desea reflejar la Coordinacin de Desarrollo en el Punto de Venta antes sus clientes y consumidores Opciones Muy de acuerdo De acuerdo Ni de acuerdo, ni en desacuerdo En desacuerdo Muy en desacuerdo Totales Frecuencia Absoluta 3 0 0 0 0 3 % 100 0 0 0 0 100

0%

Muy de acuerdo De acuerdo Ni de acuerdo, ni en desacuerdo

100%

En desacuerdo Muy en desacuerdo

Grfico 12. Representacin grfica tem 12 Al analizar la situacin actual de la Coordinacin de Desarrollo en el Punto de Venta, referente a la percepcin que muestra sobre la imagen que desea reflejar el departamento, se pudo observar que el 100% del personal de dicha coordinacin se encuentran de acuerdo, lo que refleja que la unidad en estudio est enfocada a contribuir con la misin y la visin de la empresa.

91

Cuadro 32. Distribucin Absoluta y Porcentual acerca del trabajo que har la Coordinacin de Desarrollo en el Punto de Venta en el futuro. Opciones Muy de acuerdo De acuerdo Ni de acuerdo, ni en desacuerdo En desacuerdo Muy en desacuerdo
Totales

Frecuencia Absoluta 3 0 0 0 0
3

% 100 0 0 0 0
100

0%

Muy de acuerdo De acuerdo Ni de acuerdo, ni en desacuerdo En desacuerdo Muy en desacuerdo

100%

Grfico 13. Representacin grfica tem 13 Al analizar la situacin actual de la Coordinacin de Desarrollo en el Punto de Venta, referente a la percepcin que muestra acerca del trabajo que realizara la coordinacin en el futuro, se pudo observar que el 100% del personal de dicha coordinacin se encuentran de acuerdo, lo que refleja que la unidad en estudio est enfocada a contribuir con la misin mi y la visin de la empresa.

92

Cuadro 33. Distribucin Absoluta y Porcentual acerca de la posicin que se encontrar en un mediano plazo la Coordinacin de Desarrollo en el Punto de Venta. Opciones Muy de acuerdo De acuerdo Ni de acuerdo, ni en desacuerdo En desacuerdo Muy en desacuerdo Totales Frecuencia Absoluta 2 1 0 0 0 3 % 67 33 0 0 0 100

0% 33%

Muy de acuerdo De acuerdo 67% Ni de acuerdo, ni en desacuerdo En desacuerdo Muy en desacuerdo

Grfico 14. Representacin grfica tem 14 Al analizar la situacin actual de la Coordinacin de Desarrollo en el Punto de Venta, referente a la percepcin que muestra posicin que se encontrar en un mediano plazo, , se pudo observar que el 67% del personal de dicha coordinacin se encuentran totalmente ente de acuerdo, adems el restante 33% opinan que estn de acuerdo, lo que refleja que la unidad en estudio consolidara su posicin en un mediano plazo.

93

Cuadro 34. Distribucin Absoluta y Porcentual acerca que la Coordinacin de Desarrollo en el Punto de Venta se enfoca en satisfacer las necesidades y gustos de sus consumidores Opciones Muy de acuerdo De acuerdo Ni de acuerdo, ni en desacuerdo En desacuerdo Muy en desacuerdo Totales Frecuencia Absoluta 3 0 0 0 0 3 % 100 0 0 0 0 100

0%

Muy de acuerdo De acuerdo Ni de acuerdo, ni en desacuerdo En desacuerdo Muy en desacuerdo

100%

Grfico 15. Representacin grfica tem 15 Al analizar la situacin actual de la Coordinacin de Desarrollo en el Punto de Venta, referente a la percepcin que m muestra uestra acerca del inters en satisfacer las necesidades de sus clientes y consumidores, consumidores, se pudo observar que el 100% del personal de dicha coordinacin se encuentran de acuerdo, lo que refleja que la unidad en estudio est enfocada a satisfacer las necesidades, gustos y preferencias de sus consumidores.

94

Procesos de Gestin y de Soporte Posteriormente se realizaron las actividades de los procesos de gestin y soporte de la metodologa los cuales complementan a los procesos tcnicos del desarrollo del software. Para el caso de los procesos de gestin se realiz el documento inicial del proyecto el cual describe la justificacin, los objetivos, el alcance, entre otros aspectos. Tambin se elabor el documento de instanciacin que representa el proceso de desarrollo de la aplicacin. Finalmente para terminar con este grupo de procesos se elabor el plan integral utilizado para gestionar la ejecucin del desarrollo del proyecto. Por medio de este conjunto de actividades se asegura que el desarrollo de la aplicacin sea sistemtico, organizado, eficaz y eficiente. Adicionalmente se realizaron los procesos de soporte que contribuyen a hacer ms efectivos los procesos de gestin. Este conjunto de procesos tiene asociados una serie de actividades que se llevaron a cabo para gestionar tres aspectos fundamentales del desarrollo del sistema: el tiempo de ejecucin de las actividades, los riesgos que pueden afectar el proyecto y la configuracin de la aplicacin, obtenindose como resultado: el plan de gestin de tiempos, plan de gestin de riesgos y el plan de gestin de configuracin. Estos planes conforman el plan integral del proyecto mencionado anteriormente. La utilizacin de herramientas de diagramado UML como Enterprise Architec permiti plasmar el modelo del negocio y la ingeniera de requisitos que conforman la etapa de estudio de la situacin actual. A continuacin se describen cada uno de los resultados obtenidos en esta etapa: a) b) c) d) Documento Enunciado del Trabajo. Documento de Inicio del Proyecto. Documento de Instanciacin del Mtodo. Plan Integral del Proyecto.

95

Cervecera Polar C.A Territorio Oriente Sur Ingeniera de requisitos para procesos de ejecucin de estrategias de mercadeo (Impulsos y Fachadas), Coordinacin de Desarrollo en el Punto de Venta Cervecera Polar C.A Territorio Comercial Oriente Sur. ENUNCIADO DEL TRABAJO DE PROYECTO Versin 1.0 Autor Karinthia Sarabia Karinthia Sarabia Karinthia Sarabia Fecha 05/12/2009 17/01/2010 18/02/2010 Versin 0.90 0.91 1.0 Versin proyecto. Correccin de la versin preliminar Versin final Descripcin preliminar de gestin del

1.

Introduccin Es un documento preliminar de gestin del proyecto. Se elabora antes de iniciar

formalmente el proyecto y estima a grosso modo el trabajo que se realizar en el proyecto de desarrollo. Es elaborado por el cliente o promotor del proyecto con el objetivo de describir, de una manera muy general, la aplicacin que el proyecto deber desarrollar, si ste es aprobado. Indica porque la aplicacin es necesaria, cules son sus requisitos generales, cual es el alcance de la aplicacin que se quiere desarrollar. Es usado para elaborar el Documento de Inicio del Proyecto. 2. Aplicacin que el Proyecto deber desarrollar El producto a desarrollar es la documentacin de la Ingeniera de requisitos que servir para la construccin del software que permite a los integrantes de la Coordinacin de Desarrollo Punto de Venta (CDPV) la gestin, el control y visualizacin de los procesos de ejecucin de las estrategias de mercadeo (impulsos y fachadas) que se ejecutan en la unidad. La integracin de los procesos favorecer a los Subsistemas que se encuentran relacionados con los Sub-procesos Impulsos y Sub-procesos Fachadas debido a que proporcionara una herramienta para la gestin, control y visualizacin de dichos procesos que pueden ser aplicados a un mismo 96

Cervecera Polar C.A Territorio Oriente Sur punto de venta. El producto de la Ingeniera de requisitos permitir evidenciar la seccin administrativa que debe contemplar la aplicacin para facilitar la configuracin de los usuarios. El software debe contar con una base de datos que permita el almacenamiento de la informacin generada por la unidad. 3. Necesidad de Implementar el Sistema La Coordinacin de Desarrollo en el Punto de Venta en Cervecera Polar C.A Territorio Comercial Oriente Sur, realiza los procesos de ejecucin de estrategias de mercadeo especficamente impulsos y fachadas sin contar con una herramienta que le permita realizar un control y respaldo de la informacin (presupuestos, facturas, reportes fotogrficos, entre otros) generada en estos procesos. Actualmente la coordinacin comenz a implementar un mecanismo para llevar a cabo el respaldo de la informacin, este implica el empleo de tiempos prolongados convirtindose en un trabajo engorroso y difcil de llevar un seguimiento tanto fsico como sistematizado, an as no satisface los requerimientos de la unidad, es decir que, en el momento de solicitar o verificar datos especficos, se debe buscar en cada una de las carpetas donde se almacenan archivos fsicos provocando un atraso y lentitud en las actividades laborales cotidianas. Al mismo momento se evidencia la inexistencia de una base de datos consolidada que sirva de soporte sustentable para la toma de decisiones. Por las razones antes expuestas se propone el desarrollo de la ingeniera de requisitos de una aplicacin empresarial que facilitar el control y la visualizacin de los procesos de ejecucin de estrategias de mercadeo como son la aplicacin de impulsos y fachadas en los puntos de expendios que mantienen acuerdos con Cervecera Polar C.A. La implementacin de la aplicacin proporciona las siguientes oportunidades y ventajas a la Coordinacin de Desarrollo en el Punto de Venta:

97

Cervecera Polar C.A Territorio Oriente Sur 1. Se reducirn considerablemente los tiempos asociados a los procesos que se

llevan a cabo en la coordinacin. 2. 3. 4. 5. Minimizar la redundancia y duplicidad de informacin. Incrementar los niveles de productividad laboral. Facilita el manejo de la informacin generada en los procesos. Disponer con una base de datos, la cual almacene dicha informacin contando

as con un respaldo perdurable en el tiempo. 4. Requisitos Generales El software a desarrollar va a demandar en su implementacin equipos de hardware, una plataforma de red local y conectividad a internet, que le permitan garantizar el funcionamiento, rendimiento adecuado y eficaz de sus procesos. 5. Alcance de la Aplicacin El resultado del desarrollo de la ingeniera de requisitos de dicha aplicacin abarcar funciones a nivel de la Coordinacin de Desarrollo en el Punto de Venta (CDPV) relacionada con los Sub-procesos Impulsos y Sub-proceso Fachadas, con el objetivo de totalizar la informacin resultante de la ejecucin de estos procesos, de esta manera minimizar la inconsistencia y la duplicidad de dicha informacin, as como tambin verificar y validar las inversiones realizadas, la fechas en que fueron ejecutados en cada uno de los punto de venta, entre otros.

98

Cervecera Polar C.A Territorio Oriente Sur Ingeniera de requisitos para procesos de ejecucin de estrategias de mercadeo (Impulsos y Fachadas), Coordinacin de Desarrollo en el Punto de Venta Cervecera Polar C.A Territorio Comercial Oriente Sur. DOCUMENTO DE INICIO DEL PROYECTO Versin 1.0 Autor Fecha Versin 0.90 0.91 0.92 1.0 Descripcin Versin preliminar como propuesta de desarrollo. Correccin de la versin preliminar Correccin de la versin anterior Versin Final

Karinthia Sarabia 01/12/2009 Karinthia Sarabia 04/01/2010 Karinthia Sarabia 25/01/2010 Karinthia Sarabia 22/02/2010

1.

Introduccin Este es el primer documento formal del proyecto. El objetivo es justificar

econmica y tcnicamente la necesidad de desarrollar una nueva aplicacin empresarial. Su objetivo es explicar la necesidad de desarrollar la aplicacin, para dar respuesta a un conjunto de necesidades de informacin, que tiene una o ms unidades organizacionales de la empresa. Este documento se elabora para decidir si la aplicacin debe desarrollarse, diferirse o es improcedente. Esta decisin determina el inicio, diferimiento o cancelacin del proyecto, por lo tanto orientado a facilitar la toma de decisiones sobre el futuro del proyecto. 2. 2.1 Objetivo y Alcance del Proyecto Objetivos El objetivo del proyecto es desarrollar la ingeniera de requisitos para los procesos de ejecucin de las estrategias de mercadeo (Impulsos y Fachadas), en la Coordinacin de Desarrollo en el Punto de Venta en Cervecera Polar C.A Territorio Comercial Oriente Sur, y tiene como objetivos especficos.

99

Cervecera Polar C.A Territorio Oriente Sur 1. Efectuar el modelo de negocio de la Coordinacin de Desarrollo en el Punto de

Venta, para tener un mejor conocimiento del funcionamiento de la misma. 2. Realizar la instanciacin del mtodo GRAY WATCH para ajustarlo a las

caractersticas particulares del sistema empresarial a desarrollar y a las condiciones existentes de la CDPV. 3. Realizar el levantamiento de los requisitos funcionales y no funcionales para el

sistema. 4. Disear el prototipo de la aplicacin empresarial considerando los

requerimientos funcionales y no funcionales de la aplicacin. 2.2 Alcance del Proyecto Se obtendr del desarrollo del proyecto la ingeniera de requisitos la cual proporcionara la informacin necesaria para el posterior diseo y construccin del software empresarial, permitiendo la integracin de todos los procesos que en la Coordinacin de Desarrollo en el Punto de Venta se llevan a cabo. 3. Caractersticas Generales de la Aplicacin Es un sistema para el registro, gestin, seguimiento y control de los procesos Impulsos y Fachadas, donde intervienen las Agencias del Territorio Oriente Sur, que son las unidades donde se ejecutarn dichos procesos y la Coordinacin Desarrollo en el Punto de Venta. La automatizacin de estos procesos Impulsos y Fachadas incluye: a) Control de Puntos de Venta: permite llevar un control de aquellos puntos de

venta que mantienen acuerdos con Cervecera Polar que incluye la ejecucin de las estrategias de mercadeo para los procesos Impulsos y Fachadas. b) Elaboracin de Solicitudes de Impulsos y Fachadas: el sistema permitir a las

Agencias realizar las solitudes de los procesos Impulsos y Fachadas, a travs del llenado automatizado de los formatos establecidos para la elaboracin de las

100

Cervecera Polar C.A Territorio Oriente Sur solicitudes referente a dichos procesos, los cuales sern enviados a la Coordinacin Desarrollo en el Punto de Venta para su posterior revisin. c) Asignacin y Control de proveedores: permitir llevar un registro de todos los

proveedores disponibles para realizar la ejecucin de los procesos de Impulsos y Fachadas del Territorio, adems una vez aprobada una solicitud de Impulsos y/o Fachadas llevar un registro asociando el punto de venta con el proveedor asignado. d) Consulta de la informacin: para los usuarios es muy importante poder

operaciones de consulta, para tal fin el sistema contar con mdulos de consulta que les permiten ver las solicitudes de las estrategias de mercadeo realizadas, el status actual de estos procesos, consultar datos histricos, entre otros. e) Administracin: Esta rea permite la administracin de la aplicacin

empresarial y realizar las modificaciones necesarias pertinentes. f) Validacin de usuario: permite a los usuarios finales el ingreso al sistema. El sistema evita la duplicidad de trabajo e informacin, ya que efecta validaciones y se asegura que la base de datos sea actualizada constantemente. La automatizacin de los procesos facilitar determinar la rentabilidad de futuras ejecuciones de dichos procesos, optimizando los tiempos empleados en la bsqueda de datos, proporcionando informacin confiable y oportuna en la toma de decisiones. 4. Requisitos Iniciales Para garantizar el rendimiento adecuado del proyecto a desarrollar y por ende del sistema propuesto es necesario contar con una serie de requisitos, en esta oportunidad se mencionarn los requisitos mnimos para comenzar con el proyecto, destacando que en la medida que se avance en el desarrollo del mismo estos requisitos se incrementarn. En cuanto a los requisitos de hardware se debe contar con un computador para el manejo y almacenamiento de la informacin. En lo que respecta a software se requieren programas como: Enterprise Architect, Macromedia Dreamweaver, Macromedia Fireworks, Microsotf Project.

101

Cervecera Polar C.A Territorio Oriente Sur Entre otros requisitos se encuentran proporcionar cursos en el manejo de herramientas como: Dreamweaver, PHP, Javascript, HTML, metodologa GRAY WATCH y UML con la finalidad de capacitar al desarrollador involucrado en el proyecto. Estos adiestramientos son indispensables para preparar al desarrollador y lograr la culminacin del proyecto en el tiempo establecido. 5. Visin del Negocio La Coordinacin de Desarrollo en el Punto de Venta en Cervecera Polar C.A Territorio Comercial Oriente Sur se encarga de coordinar, organizar, implementar, velar y hacer seguimiento a las actividades promocionales de las marcas a fin de contribuir a alcanzar los objetivos planteados de acuerdo a los lineamientos de la Gerencia Nacional de Mercadeo de Canales controlando el presupuesto asignado, aplicando el principio GANAR GANAR. La Coordinacin de Desarrollo en el Punto de Venta CDPV esta constituida por tres (3) funcionarios y a su vez realiza operaciones donde intervienen las doce (12) Agencias (Maturn, Punta de Mata, Tucupita, Temblador, Puerto Ordaz, San Flix, Ciudad Bolvar, Upata, Tumeremo, Santa Elena de Uairn, Caicara del Orinoco y Puerto Ayacucho) que conforman el Territorio Oriente Sur, estas Agencias son las unidades donde se ejecutarn dichos procesos, CDPV coordina estos procesos a las anteriormente mencionadas doce (12) Agencias, de all la relacin con las actividades administrativas que se realizan en la unidad y las Agencias, estas personas manejan los procedimientos administrativos diariamente, por lo tanto, son las personas idneas para transmitir los requerimientos necesarios para elaborar un nuevo sistema. Los actores que rigen el curso de las actividades y que modelan el comportamiento del negocio dentro de la CDPV precisando el nmero de personas que ocupa cada cargo: (1) Coordinador de Desarrollo en el Punto de Venta, (1) Analista Desarrollo en el Punto de Venta, (1) Almacenista y (12) Gerentes de Agencia

102

Cervecera Polar C.A Territorio Oriente Sur 6. Necesidad de Implementar el Sistema Actualmente la Coordinacin de Desarrollo en el Punto de Venta comenz a implementar un mecanismo para contar con un respaldo de la informacin. Este procedimiento se realiza con la utilizacin de herramientas ofimticas no acordes con los requerimientos funcionales lo cual se convierte en un trabajo engorroso y dificulta llevar un seguimiento tanto fsico como sistematizado de la misma, implica el empleo de horas/hombre dedicadas para culminarlo, y aun as no satisface las necesidades o requerimientos de la unidad, es decir que, en el momento de requerir o verificar datos especficos, se debe buscar en cada una de las carpetas donde se almacenan archivos fsicos retrasando as las actividades a realizar en la coordinacin. El producto de este proyecto servir de base para poder llevar a cabo el diseo y la construccin de la aplicacin empresarial que permitira visualizar las diferentes inversiones que se realizaron en los puntos de venta y as determinar la rentabilidad de futuras ejecuciones, optimizando los tiempos empleados en la bsqueda de la informacin, proporcionando informacin confiable y oportuna en la toma de decisiones, contando con un soporte para el seguimiento de estos procesos en el tiempo. Minimizar los ndices de inconsistencias y duplicidad del contenido de la informacin de dichos procesos que se resguardarn. 7. Resumen de los Interesados del Proyecto Se describe todos los interesados (stakeholders) del proyecto: Cuadro 35. Interesados (stakeholders) del proyecto.
Roles Responsabilidades

Elaborar el Plan Integral del Proyecto de desarrollo de Prestar asistencia tcnica a los miembros del equipo de
Lder del Proyecto. desarrollo. Gestionar los riesgos del proyecto. Dirigir y controlar la ejecucin del Plan Integral del Proyecto. Cerrar administrativa y tcnicamente el proyecto. la aplicacin empresarial que le sea asignada.

103

Cervecera Polar C.A Territorio Oriente Sur

Cuadro 35. (Cont.)

Roles Analista del Negocio.

Analista del Sistema.

Arquitecto de Software. Diseador de Software.

Programador.

Especialista V&V.

Gestor de Configuracin de Software.

Gestor de Calidad.

Responsabilidades Modelar el dominio de la aplicacin empresarial. Asegurar que los productos del desarrollo de la aplicacin estn alineados al sistema de negocios que acta como dominio de la aplicacin. Descubrir, analizar, especificar y documentar los requisitos de la aplicacin. Validar, en conjunto con los usuarios, los requisitos establecidos. Gestionar los requisitos. Especificar requisitos arquitectnicos. Disear y evaluar la arquitectura de la aplicacin. Especificar cada una de las vistas arquitectnicas. Disear los detalles de la Interfaz U/S, las Bases de Datos y los Componentes de Software de la aplicacin. Codificar, documentar y probar los componentes de software de la aplicacin. Depurar los componentes que tengan errores. Integrar los componentes de la aplicacin y desplegarlos en la plataforma de ejecucin del proyecto. Elaborar los manuales de instalacin, uso y mantenimiento. Verificar y validar los productos de cada proceso del desarrollo. Disear y ejecutar pruebas de unidad, de integracin, del sistema y de aceptacin de la aplicacin. Gestionar los tems producidos durante el desarrollo y controlar los cambios que puedan surgir en cada una de ellos. Gestionar las versiones de la aplicacin. Definir los estndares y procedimientos de aseguramiento de la calidad del software. Asegurar la calidad del software.

Luego se procede a definir que papel desempea cada interesado (stakeholders) del proyecto:

104

Cervecera Polar C.A Territorio Oriente Sur

Cuadro 36. Identificacin de interesados del proyecto. Roles Responsables Lder del Proyecto. Responsable General del proyecto. Analista del Negocio. Analista del Sistema Gestor de Configuracin de Software. Gestor de Calidad. Ing. Anantonieta Morales. Ing. Jess Chaparro. Br. Karinthia Sarabia

Ing. Yhuanailys Nez

8.

Restricciones Las personas involucradas en el desarrollo del proyecto estn conformados por

el personal de la Coordinacin de Desarrollo en el Punto de Venta y otros aquellos participantes que se estimen convenientes para proporcionar los requisitos y validar el sistema: Responsable General de Proyecto, Lder de Proyecto y Usuarios. El proyecto esta siendo desarrollado haciendo uso de las siguientes tecnologas y herramientas Enterprise Architect para la elaboracin del Modelado de Negocios y levantamiento de los requisitos, as como tambin Microsoft Project, Macromedia Dreamweaver, Macromedia Fireworks. Las restricciones de infraestructura estn relacionadas con las normas, aplicaciones de estndares, los requisitos de calidad del producto, tales como: confiabilidad, desempeo, entre otros y requisitos de ambiente, tales como: sistema operativo, requisitos de compatibilidad.

105

Cervecera Polar C.A Territorio Oriente Sur Ingeniera de requisitos para procesos de ejecucin de estrategias de mercadeo (Impulsos y Fachadas), Coordinacin de Desarrollo en el Punto de Venta Cervecera Polar C.A Territorio Comercial Oriente Sur. DOCUMENTO PROCESO DE INSTANCIACIN DEL MTODO Versin 1.0 Autor Fecha Versin 0.90 0.91 1.0 Descripcin Versin preliminar como propuesta de desarrollo Correccin de la versin preliminar Versin Final

Karinthia Sarabia 02/12/2009 Karinthia Sarabia 05/01/2010 Karinthia Sarabia 23/02/2010

1.

Introduccin Este documento presenta la instanciacin del mtodo, el cual consiste en

adaptar el conjunto de procesos y actividades prescritas por el mtodo, a las caractersticas particulares del sistema que se va a implementar. Para realizar la adaptacin se toma en cuenta tanto las condiciones existentes en el ambiente de trabajo como la complejidad de la aplicacin; es decir, el proceso de ajuste del mtodo considera las caractersticas del producto que se desea desarrollar y del ambiente organizacional de implantacin para establecer los procesos que deben seguirse y los productos que se van a elaborar. 2. Procesos que se generarn en el Proyecto Con el objeto de facilitar su descripcin, estos procesos se han organizado en tres grupos (ver Figura 18). El grupo de Procesos Tcnicos enmarcan todas las actividades de ingeniera que estn relacionadas directamente con el ciclo de desarrollo de las aplicaciones. El grupo de Procesos de Gestin cubre todas las actividades de gestin de proyectos de software. El grupo de Procesos de Soporte concentra todas aquellas actividades que son necesarias para apoyar la ejecucin de

106

Cervecera Polar C.A Territorio Oriente Sur los procesos tcnicos y gerenciales. Para el desarrollo del proyecto se van realizar todos los procesos del mtodo WATCH que se muestran a continuacin:

MODELO DE PROCESOS

Procesos Tcnicos

Procesos de Gestin

Procesos de Soporte

Modelado de negocio

Constitucin del Proyecto Planificacin del Proyecto

Gestin de la Configuracin Gestin de la Calidad

Ingeniera de requisitos

Direccin del Proyecto

Gestin de Riesgos

Control del Proyecto

Cierre del Proyecto

Figura 18. Clasificacin de los Procesos del Mtodo Watch durante el desarrollo del proyecto. Una vez que los modelos de productos, procesos y actores han sido instanciados se debe asegurar que el mtodo resultante de la integracin de estos tres modelos, permitir verdaderamente desarrollar el proyecto. Para ello se debe revisar la correspondencia entre los conceptos predefinidos en el mtodo y el subconjunto de conceptos utilizados durante la adaptacin; verificar la consistencia y la coherencia de las interacciones establecidas entre los diferentes modelos de la adaptacin del mtodo, asegurar la consistencia entre modelo de producto y de proceso, garantizar la correspondencia entre actores y actividades del proceso.

107

Cervecera Polar C.A Territorio Oriente Sur Para comenzar se verifica la coherencia entre el modelo de productos y el modelo de procesos; en el proceso de gestin se van a ejecutar los cinco procesos que a su vez generan los productos que ya hemos instanciado. En la constitucin del proyecto se generan los productos: Enunciado del trabajo del proyecto y Documento de inicio del proyecto. Posteriormente para la planificacin es necesario generar el plan integral del proyecto, plan del alcance del proyecto y el plan de tiempos. Los productos entregables son el resultado del proceso de Direccin del proyecto. El proceso de control genera el plan integral del proyecto actualizado el cual permite llevar un control de la ejecucin del proyecto y corregir las desviaciones de lo ejecutado con respecto a lo establecido en el plan integral del proyecto. El ltimo proceso de gestin es el cierre del proyecto que se encarga de dar por finalizado formalmente el proyecto con la entrega de los documentos Modelado de Negocios y Documento de Requisitos. Para la elaboracin del proyecto Ingeniera de requisitos para los procesos de ejecucin de las estrategias de mercadeo (Impulsos y Fachadas), en la Coordinacin de Desarrollo en el Punto de Venta en Cervecera Polar C.A Territorio Comercial Oriente Sur. Los procesos tcnicos van abarcar el proceso de anlisis de modo que el estudio en cuestin se basa en el levantamiento de requisitos. El resultado de los procesos de anlisis son el Modelado de Negocio y la Ingeniera de requisitos. Los productos que se generan del proceso de soporte estn conformados el Plan Integral Proyectos, los cuales son: Gestin de la Configuracin, Gestin de la Calidad y Gestin de riesgos. 3. Procesos que se generan en el Proyecto El modelo de producto identifica y describe los tipos de productos que se pueden generar durante el desarrollo del proyecto: Ingeniera de requisitos para los procesos de ejecucin de las estrategias de mercadeo (Impulsos y Fachadas), en la Coordinacin de Desarrollo en el Punto de Venta en Cervecera Polar C.A Territorio

108

Cervecera Polar C.A Territorio Oriente Sur Comercial Oriente Sur. Estos tipos de productos son el resultado parcial o final de la ejecucin de los procesos tcnicos, de gestin o de soporte. Para hacer la instanciacin del modelo de productos se elabora una lista de los productos concretos que se producirn durante el desarrollo del proyecto y describe las caractersticas particulares del proyecto para la gestin, el control y visualizacin de los procesos de ejecucin de estrategias de mercadeo (impulsos y fachadas) en la CDPV en Cervecera Polar, C.A. El modelo de productos est compuesto por tres tipos de productos: tcnicos, de soporte y de gestin, a continuacin se muestra la lista de los productos que se producirn durante todo el proceso de desarrollo del proyecto para Ingeniera de requisitos para los procesos de ejecucin de las estrategias de mercadeo (Impulsos y Fachadas), en la Coordinacin de Desarrollo en el Punto de Venta en Cervecera Polar C.A Territorio Comercial Oriente Sur. Cuadro 37. Productos que genera la metodologa Gray Watch. Grupo de procesos Producto 1. Documento de Inicio del proyecto. Procesos de Gestin 2. Proceso de Desarrollo. 3. Plan Integral del Proyecto 4. Instanciacin del mtodo. Procesos Tcnicos 1. Modelo del anlisis del negocio. 2. Documento de Requisitos. Forman parte del Plan Integral del Proyecto: 1. Plan de Gestin de Riesgos. Procesos de Soporte 2. Plan de Gestin de la Configuracin. 3. Plan de Aseguramiento de la Calidad del Software. Como se muestra en la Figura 19 el mtodo produce dos grandes categoras de productos, los productos intermedios y los productos finales. Al mismo tiempo el mtodo permite distinguir los productos segn el grupo de procesos que los 109

Cervecera Polar C.A Territorio Oriente Sur producen; es decir, hay productos resultantes de los procesos tcnicos o de ingeniera, otros son resultantes de los procesos de gestin del proyecto y otros de los procesos de apoyo al proceso de desarrollo:

Producto Watch

Producto Intermedio

Producto Entregable

Producto Tcnico

Producto de Gestin

Producto de Soporte

Aplicacin Empresarial

Figura 19. Principales Tipos de Productos del Mtodo Watch. La instanciacin del modelo de producto da como resultado los productos concretos que se van a producir durante el proceso de desarrollo del sistema de la Coordinacin de Desarrollo en el Punto de Venta de Cervecera Polar C.A.

110

Cervecera Polar C.A Territorio Oriente Sur Ingeniera de requisitos para procesos de ejecucin de estrategias de mercadeo (Impulsos y Fachadas), Coordinacin de Desarrollo en el Punto de Venta Cervecera Polar C.A Territorio Comercial Oriente Sur. PLAN INTEGRAL DEL PROYECTO Versin 1.0 Autor Karinthia Sarabia Karinthia Sarabia Karinthia Sarabia Karinthia Sarabia Fecha 03/12/2009 06/01/2010 27/01/2010 01/03/2010 Versin 0.90 0.91 0.92 1.0 Versin proyecto Correccin de la versin preliminar Correccin de la versin anterior Versin final Descripcin preliminar de gestin del

1.

Introduccin Es el documento ms importante de la gestin del proyecto, por cuanto

determina, rige y gua la ejecucin de todos los procesos del desarrollo de la aplicacin. El Plan de Integral del Proyecto (denominado, tambin, Plan del Proyecto) define cmo el proyecto se debe iniciar, planificar, ejecutar, controlar y cerrar. Este documento determinara la ejecucin de todos los procesos del desarrollo del proyecto: Ingeniera de requisitos para los procesos de ejecucin de las estrategias de mercadeo (Impulsos y Fachadas), en la Coordinacin de Desarrollo en el Punto de Venta en Cervecera Polar C.A Territorio Comercial Oriente Sur. Se podr establecer los objetivos y alcance de la aplicacin, el proceso tcnico necesario para desarrollar dicha aplicacin, las actividades que componen cada uno de los procesos, el cronograma de ejecucin de estas actividades, y los recursos humanos, tecnolgicos, fsicos y materiales necesarios para desarrollar las actividades. Bajo estas premisas, el estudio en referencia se circunscribir al desarrollo de la Ingeniera de requisitos para los procesos de ejecucin de las

111

Cervecera Polar C.A Territorio Oriente Sur estrategias de mercadeo (Impulsos y Fachadas), en la Coordinacin de Desarrollo en el Punto de Venta en Cervecera Polar C.A Territorio Comercial Oriente Sur. 2. Objetivos Con lo diferentes planes, los cuales se detallarn mas adelante se pretende obtener la informacin que se necesita para llevar a cabo el proyecto planificado y controlado en lo que respecta a tiempos, riesgos y cambios. Todo proyecto de software es susceptible a riesgos los cuales de llegar a concretarse afectan los tiempos de ejecucin de las actividades y producen cambios en el proyecto, por esto los objetivos que se persiguen con los diferentes planes que se realizan son los siguientes: 1. Asegurar que el desarrollo de la aplicacin sea sistemtico, organizado, eficaz y

eficiente, mediante el empleo de los procesos de planificacin, direccin y control. 2. Garantizar que la aplicacin se desarrolle en el tiempo estipulado y siguiendo

los estndares y procedimientos establecidos para asegurar la calidad de la aplicacin. 3. Manejar apropiadamente los riesgos que puedan surgir durante el desarrollo de

la aplicacin y que puedan afectar los objetivos del proyecto. 4. 3. 3.1 Controlar la configuracin de la aplicacin. Recursos Necesarios Recursos Humanos El equipo de trabajo est representado de la siguiente manera: Se requiere primeramente de la Ing. Anantonieta Morales cuya responsabilidad es ser lder del proyecto: es la persona que elabora el Plan Integral del Proyecto de desarrollo de la aplicacin, presta asistencia tcnica a los miembros del equipo de desarrollo, dirigir y controlar la ejecucin del Plan Integral del Proyecto y es el responsable general del proyecto, esta persona valida cada uno de los documentos.

112

Cervecera Polar C.A Territorio Oriente Sur Se requiere de asesoramiento e instrucciones del Ing. Yhuanailys Nez, pues desempea el papel de gestor de la calidad y gestor de configuracin de software en el proyecto. Es la persona que define los lineamientos a seguir para el desarrollo de las versiones. Finalmente la elaboracin del proyecto estar a cargo del Br. Karinthia Sarabia quien es la persona encargada de la elaboracin de proyecto, desempea los papeles Analista de Negocios y Analista de Sistemas. 3.2 Recursos Tecnolgicos Para garantizar un rendimiento adecuado del sistema propuesto es necesario que los equipos hardware donde se van a instalar y operar el sistema cumplan con los siguientes requerimientos unidad central de procesamiento (CPU) Pentium IV, se recomienda 1024 megabyte (MB)/1 GB de memoria RAM, Disco Duro de 160 GB y Sistema operativo Windows XP, Macromedia Dreamweaver, Enterprise Architect, Editor de Texto y un Navegador Web. 3.3 Recursos Materiales Los miembros de trabajo del proyecto deben contar con resmas de papel tipo carta, cartuchos de impresin, carpetas, lpices, bolgrafos, marcadores, libreta de anotaciones, CD-ROM, guas didcticas con informacin sobre el mtodo de desarrollo, material de apoyo y textos varios sobre los procesos y actividades a desarrollar. 3.4 Otros Recursos El desarrollador debe tener la capacitacin y formacin necesaria para ejecutar eficaz y eficientemente las actividades de los procesos tcnicos, de gestin y de soporte. A continuacin se nombran aquellos cursos que son requeridos por el desarrollador del sistema: curso de UML, curso de programacin en PHP, curso de programacin en JavaScript, curso de Macromedia Dreamweaver.

113

Cervecera Polar C.A Territorio Oriente Sur 4. 4.1 Estndares y Procedimientos Normas de Calidad: Norma de Calidad ISO-9126: La ISO, bajo la norma ISO-9126, ha establecido un estndar internacional para la evaluacin de la calidad de productos de software el cual fue publicado en 1992 con el nombre de Tecnologa de la informacin de evaluacin de productos de software: caractersticas de calidad y directrices para su uso, en el cual se establecen las caractersticas de calidad para productos de software. El estndar ISO9126 establece que cualquier componente de la calidad del software puede ser descrito en trminos de una o ms de seis caractersticas bsicas, las cuales son: funcionalidad, confiabilidad, usabilidad, eficiencia, mantenibilidad y portabilidad; cada una de las cuales se detalla a travs de un conjunto de subcaractersticas que permiten profundizar en la evaluacin de la calidad de productos de software. El Cuadro 38 denominada Caractersticas ISO-9126 demuestra la pregunta central que atiende cada una de estas caractersticas. Cuadro 38. Caractersticas de ISO-9126 y aspecto que atiende cada uno. Caractersticas Pregunta central Las funciones y propiedades satisfacen las necesidades explicitas e implcitas; esto es, el qu? Puede mantener en nivel de rendimiento bajo Confiabilidad ciertas condiciones y por cierto tiempo? Usabilidad El software es fcil de usar y de aprender? Es rpido y minimalista en cuanto al uso de Eficiencia recursos? Mantenibilidad Es fcil de modificar y verificar? Portabilidad Es fcil de transferir de un ambiente a otro? Fuente: Modelo de calidad establecido por el estndar ISO 9126. Funcionalidad

114

Cervecera Polar C.A Territorio Oriente Sur 4.2 Leyes: Las bases legales que dan soporte al proyecto en referencia, se encuentras plasmadas en la: 1. Constitucin de la Repblica Bolivariana de Venezuela Artculo 110: El Estado reconocer el inters pblico de la ciencia, la tecnologa, el conocimiento, la innovacin y sus aplicaciones y los servicios de informacin necesarios por ser instrumentos fundamentales para el desarrollo econmico social y poltico del pas, as como para la seguridad y soberana nacional 2. Decreto Rango y Fuerza de Ley Orgnica de Ciencia, Tecnologa e Innovacin

en Consejo de Ministros Artculo 2.- Las actividades cientficas, tecnolgicas y de innovacin son de inters pblico y de inters general. Ello indica que ataen a todos los individuos y entes nacionales. 4.3 1. Manuales GRAY WATCH Mtodo de Desarrollo de Software de Aplicaciones

Empresariales, 2008 Jons Montilva, Judith Barrios y Milagro Rivero: Este documento tiene por objetivos describir, en detalle, el mtodo WATCH de tal manera que los equipos de desarrollo puedan utilizarlo como un patrn metodolgico que les ayude a definir el proceso especfico de desarrollo de cada una de las aplicaciones de una empresa. 2. Modelado de sistemas usando UML 2.0, Jons Montilva e Isabel Besembel: Es una gua que describe el modelado de sistemas con las notaciones en UML 2.0 y el modelado de sistemas de negocios con UML Bussines. Esta dirigido a ensear al desarrollador de sistemas como usar este lenguaje en el proceso desarrollo

115

Cervecera Polar C.A Territorio Oriente Sur de software y como modelar los diferentes aspectos que caracterizan a un sistema de informacin o aplicacin de software. 3. Ingeniera de requisitos, Jons Montilva, CeiSoft: Es una gua que detalla las generalidades involucradas en el proceso de ingeniera de requisitos como la especificacin, documentacin y representacin usando notaciones en UML 2.0. 4.4 IEEE Std 1233, Edicin 1998 Este estndar muestra una gua para el desarrollo de especificaciones de requerimientos de sistemas, donde se da la pauta para el desarrollo de un conjunto de requerimientos que debern satisfacer una necesidad especfica, los cuales incluyen la identificacin, organizacin, presentacin y modificacin de los requerimientos. La gua trata las condiciones necesarias para incorporar conceptos operacionales, restricciones de diseo y de la configuracin del diseo en la especificacin. Adems, trata las caractersticas y cualidades necesarias de los requerimientos individuales y del conjunto de todos los requerimientos. 5. 5.1 Planes Plan de Gestin de Tiempo Este plan establece las actividades necesarias para elaborar el cronograma del proyecto. Describe, tambin, el formato para elaborar el cronograma, los criterios y supuestos que se deben considerar para programar las actividades del proyecto. Una vez que el o los cronogramas del proyecto se elaboren, ellos pasan a formar parte del Plan de Gestin de Tiempos. A continuacin se presenta el plan de tiempo del proyecto:

116

Cervecera Polar C.A Territorio Oriente Sur

Cuadro 39. Cronograma Primera Iteracin

Cuadro 40. Cronograma Segunda Iteracin

117

Cervecera Polar C.A Territorio Oriente Sur Cuadro 41. Cronograma Tercera Iteracin

Cuadro 42. Cronograma Cuarta Iteracin

118

Cervecera Polar C.A Territorio Oriente Sur Cuadro 43. Cronograma Quinta Iteracin

5.2

Plan de Gestin de Riesgo La Planificacin de la Gestin de Riesgos tiene como objetivo definir las

actividades, recursos, responsabilidades, costos, tiempos que son necesarios para evaluar y responder a los riesgos del proyecto de la Coordinacin de Desarrollo en el Punto de Venta de manera organizada. El proceso comienza considerando las caractersticas del ambiente de desarrollo, del proyecto, la experiencia en el dominio y categora de la aplicacin a desarrollar, las herramientas y recursos requeridos y disponibles, para luego determinar cules actividades de gestin de riesgos se llevaran a cabo, cuando, en qu orden y quines sern los responsables. En este documento se reconoce y listan todos aquellos riesgos que puedan influir negativamente en el proyecto. El proceso comienza con la definicin de las caractersticas del proyecto en relacin a la complejidad, requisitos, recursos, experiencia del recurso humano, de manera que se pueda determinar el conjunto de riesgos potenciales a los que el desarrollo de la aplicacin estar expuesto. 119

Cervecera Polar C.A Territorio Oriente Sur La matriz de evaluacin de riesgo es una herramienta que permite el anlisis de los riegos, es decir, los clasifica, los evala y les estableces prioridades a cada uno de los riesgos identificados. A continuacin se muestra la matriz diseada para la evaluacin de los riesgos, incluyendo cada uno de los sus aspectos involucrados. Cuadro 44. Matriz de Evaluacin de Riesgos Descripcin del Riesgo: (Identificador del (Lista de cada riesgo al cual se enfrenta el proyecto.) Riesgo) Tipo de Riesgo: Efectos del Riesgo: (tecnolgico/ personal/ (catastrfico, serio, tolerable, e herramientas/ requerimientos/ insignificante) organizacionales) Responsable(s): (Asignacin de cada accin Consecuencia: (Consecuencia asociada al riesgo) de mitigacin de riesgos a un individuo para su resolucin.) Probabilidad: (Cul es la probabilidad de que el riesgo se Bajo Medio Alto convierta en un problema? Selecciona! Entre las siguientes: ) Periodo en el cual puede Entre Entre suceder: (Determinar un periodo del 0% y 25% y >70% proyecto mediante el cual se 25 % 70% produzca el riesgo). Estrategia de Mitigacin: (Ponderacin de uno o ms enfoques para controlar, evitar, minimizar, o en ltima instancia mitigar el riesgo).

Se enumera lo que se consideraron los riesgos ms importantes con su respectiva jerarquizacin. Los criterios para la escogencia de los riesgos se centran en los siguientes aspectos: tecnolgicos, personal, de herramientas, de requerimientos, de estimacin y organizacionales. En la elaboracin de la lista de riesgos se utilizar una tabla que visualice cada uno de los riesgos con sus aspectos involucrados.

120

Cervecera Polar C.A Territorio Oriente Sur Riesgo a administrar:

Cuadro 45. Primer Riesgo Descripcin del Riesgo: R-01 Incumplimiento de entrega de documentos al Ing. Jess Chaparro y Departamento de Sistemas de Cervecera Polar C.A., debido a responsabilidades con carga de trabajo fuerte, no relativos al proyecto. Tipo de Riesgo: Efectos del Riesgo: Personal Serio Consecuencia: Responsable(s): Retraso en la elaboracin del Analista del Sistema. proyecto. Bajo Medio Alto Probabilidad: Periodo en el cual puede suceder: Durante la elaboracin del proyecto. Estrategia de Mitigacin: Para evitar el incumplimiento de las asignaciones, el participante debe dar a conocer con anticipacin la no participacin en alguna iteracin y por consiguiente exponer con aval dicha solicitud.

Cuadro 46. Segundo Riesgo Descripcin del Riesgo: R-02 Comunicacin no fluida entre el cliente e involucrados en el desarrollo del producto. Tipo de Riesgo: Efectos del Riesgo: Personal Tolerable Consecuencia: Responsable(s): No contar con informacin para poder Analista del Negocio y de desarrollar el proyecto, y desviacin en el Requisitos. cumplimiento de los requerimientos. Bajo Medio Alto Probabilidad: Periodo en el cual puede suceder: Durante la elaboracin del proyecto. Estrategia de Mitigacin: Para evitar la disminucin en el flujo de la comunicacin se requiere hacer reuniones peridicas (diarias y semanales para la Coordinacin de Desarrollo en Punto de Venta) referentes al proyecto, con el fin de incrementar al mximo la retroalimentacin.

121

Cervecera Polar C.A Territorio Oriente Sur

Cuadro 47. Tercer Riesgo R-03 Descripcin del Riesgo: Desconocimiento del rea de trabajo. Tipo de Riesgo: Efectos del Riesgo: Personal Serio Consecuencia: No contar con informacin mnima acerca del Responsable(s): rea de trabajo, impidiendo el desarrollo y Analista de Sistemas. culminacin del mismo. Bajo Medio Alto Probabilidad: Periodo en el cual puede suceder: Durante la elaboracin del proyecto. Estrategia de Mitigacin: Para evitar el desconocimiento del rea de trabajo se debe recopilar la mayor cantidad de informacin acerca de la CDPV, para proceder a estudiar su funcionamiento y prestar suma atencin a los procesos que se ejecutan en la misma.

Cuadro 48. Cuarto Riesgo Descripcin del Riesgo: R-04 Falta de conocimientos de las herramientas de desarrollo como: Enterprise Architect, Microsoft Project, Macromedia Dreamweaver, Macromedia Fireworks, Php y del lenguaje UML por parte del equipo de desarrollo. Tipo de Riesgo: Efectos del Riesgo: Herramientas Tolerable Consecuencia: Responsable(s): Retardo en la entrega de documentos. Analista de Sistemas. Bajo Medio Alto Probabilidad: Periodo en el cual puede suceder: Durante la elaboracin del proyecto. Estrategia de Mitigacin: Capacitacin al equipo de desarrollo de las herramientas a utilizar, con la finalidad de obtener los conocimientos necesarios y de esta manera cumplir con sus asignaciones.

122

Cervecera Polar C.A Territorio Oriente Sur

Cuadro 49. Quinto Riesgo Descripcin del Riesgo: R-05 Incumplimiento de entrega de documentos aprobados y/o corregidos por parte de los supervisores del proyecto como son el asesor acadmico del proyecto: Ing. Jess Chaparro y el Departamento de Sistemas de Cervecera Polar C.A. Tipo de Riesgo: Efectos del Riesgo: Organizacional Serio Consecuencia: Responsable(s): Prolongacin de la culminacin del proyecto. Gestor de configuracin de software y gestor de calidad. Bajo Medio Alto Probabilidad: Periodo en el cual puede suceder: Durante la elaboracin del proyecto. Estrategia de Mitigacin: El gestor de configuracin de software y gestor de calidad debe apegarse al cumplimiento del cronograma de actividades.

Cuadro 50. Sexto Riesgo Descripcin del Riesgo: R-06 Reduccin de la retroalimentacin y desviacin en el cumplimiento de los requerimientos. Tipo de Riesgo: Efectos del Riesgo: Organizacional Serio Consecuencia: Responsable(s): Retardo en la entrega de documentos por no Responsable general del contar con la informacin necesaria. proyecto. Bajo Medio Alto Probabilidad: Periodo en el cual puede suceder: Durante la elaboracin del proyecto. Estrategia de Mitigacin: Se requiere hacer reuniones peridicas (diarias y semanales para la Coordinacin de Desarrollo en Punto de Venta) referentes al proyecto, con el fin de incrementar al mximo la retroalimentacin.

123

Cervecera Polar C.A Territorio Oriente Sur

Cuadro 51. Sptimo Riesgo Descripcin del Riesgo: R-07 Perder el apoyo de los integrantes de la Coordinacin de Desarrollo en el Punto de Venta, debido a la prdida de inters hacia el proyecto. Tipo de Riesgo: Efectos del Riesgo: Organizacional Catastrfico Consecuencia: Responsable(s): Cancelacin del proyecto. Responsable general del proyecto. Bajo Medio Alto Probabilidad: Periodo en el cual puede suceder: Durante la elaboracin del proyecto. Estrategia de Mitigacin: Exponer y presentar cada iteracin del proyecto, con la finalidad de mantener al tanto a los integrantes de la CDPV del desarrollo del mismo.

Cuadro 52. Octavo Riesgo Descripcin del Riesgo: R-08 Suspensin de actividades en la Coordinacin de Desarrollo en el Punto de Venta por causas externas a la misma, por ejemplo cambios organizacionales generados ante una medida de expropiacin a la empresa. Tipo de Riesgo: Efectos del Riesgo: Organizacional Catastrfico Consecuencia: Responsable(s): Cancelacin del proyecto Responsable general del proyecto. Bajo Medio Alto Probabilidad: Periodo en el cual puede suceder: Durante la elaboracin del proyecto. Estrategia de Mitigacin: Tratar de llevar la planificacin del proyecto para poder mitigar el efecto de retraso que pudiera ser causado por la situacin descrita.

124

Cervecera Polar C.A Territorio Oriente Sur

Cuadro 53. Noveno Riesgo Descripcin del Riesgo: R-09 Escasa atencin por parte de los usuarios de la Coordinacin de Desarrollo en el Punto de Venta. Tipo de Riesgo: Efectos del Riesgo: Organizacional Serio Consecuencia: Responsable(s): Prolongacin de la culminacin del proyecto. Responsable general del proyecto. Bajo Medio Alto Probabilidad: Periodo en el cual puede suceder: Durante la elaboracin del proyecto. Estrategia de Mitigacin: Exponer y presentar cada iteracin del proyecto, con la finalidad de mantener al tanto a los integrantes de la CDPV del desarrollo del mismo.

Cuadro 54. Dcimo Riesgo R-10 Descripcin del Riesgo: Crecimiento no controlado del alcance. Tipo de Riesgo: Efectos del Riesgo: Requerimientos Serio Consecuencia: Responsable(s): Proyecto fuera de calendario y Analista de Sistemas. requerimientos. Bajo Medio Alto Probabilidad: Periodo en el cual puede suceder: Durante la elaboracin del proyecto. Estrategia de Mitigacin: El alcance del proyecto debe ser definido previo a la etapa de operacin.

125

Cervecera Polar C.A Territorio Oriente Sur

Cuadro 55. Dcimo Primer Riesgo R-11 Descripcin del Riesgo: Proyecto fuera de calendario. Tipo de Riesgo: Efectos del Riesgo: Requerimientos Serio Consecuencia: Responsable(s): Proyecto fuera de calendario. Responsable general del proyecto. Bajo Medio Alto Probabilidad: Periodo en el cual puede suceder: Durante la elaboracin del proyecto. Estrategia de Mitigacin: El alcance del proyecto debe ser definido previo a la etapa de operacin.

Cuadro 56. Dcimo Segundo Riesgo Descripcin del Riesgo: R-12 Determinacin errnea de funcionalidades y proceso con alto nmero de incrementos por correccin, lo que genera una prolongacin no deseada del cronograma de actividades. Tipo de Riesgo: Efectos del Riesgo: Requerimientos Catastrfico Consecuencia: Responsable(s): Prolongacin de la culminacin del proyecto. Analista del Negocio, Requisitos y Sistemas. Bajo Medio Alto Probabilidad: Periodo en el cual puede suceder: Durante la elaboracin del proyecto. Estrategia de Mitigacin: Establecer mecanismos de supervisin de requerimientos por parte de los Analistas y expertos del negocio, cuyas funciones se centraran en ejecutar pruebas de desempeo funcional y aceptacin. Mientras ms grande sea el contacto cliente equipo de desarrollo mayor ser la garanta de capturar requerimientos reales y realizar la menor cantidad de incrementos por correccin.

126

Cervecera Polar C.A Territorio Oriente Sur Cuadro 57. Dcimo Tercer Riesgo R-13 Descripcin del Riesgo: Datos actuales no migrados eficientemente. Tipo de Riesgo: Efectos del Riesgo: Tecnolgico Catastrfico Consecuencia: Responsable(s): Proyecto realizado con datos no reales. Analista de Sistemas. Bajo Medio Alto Probabilidad: Periodo en el cual puede suceder: Durante la elaboracin del proyecto. Estrategia de Mitigacin: Para evitar que esto ocurra, el gestor de configuracin de software debe prever la incorporacin paulatina (a travs de las versiones) de data bsica real en la base de datos. Un modulo funcional debe ejecutarse correctamente, sino debe crearse tantas versiones sean necesarias. 5.3 Plan de Gestin de Configuracin Se realiz una gestin de configuracin para llevar un registro de los documentos generados y sus versiones. Para este proyecto los elementos de configuracin representan los entregables definidos en el Modelo de Procesos. Todos los productos del desarrollo del sistema (programas, documentos, datos, etc.) forman la configuracin del software, a medida que el desarrollo de la aplicacin avanz la configuracin creci rpidamente y surgieron cambios de diferente tipo, que obviamente afectaron a los productos ya elaborados. Para controlar los cambios del proyecto los documentos estn identificados por versiones, las cuales se incrementaron a medida que se avanz en el proyecto. Cada uno de estos documentos fueron revisados, una vez realizados los cambios propuestos en los documentos se cambi a una nueva versin y as sucesivamente hasta obtener la versin definitiva del documento. Tambin se incluye la gestin de las solicitudes de cambio (si se da el caso) y de las modificaciones que stas produzcan, informando y publicando dichos cambios para que sean accesibles a todo los participantes en el proyecto. Al final de cada

127

Cervecera Polar C.A Territorio Oriente Sur iteracin se estableci una baseline (un registro del estado de cada documento, estableciendo una versin), la cual pudo ser modificada slo por una solicitud de cambio aprobadas

128

Etapa II: Modelo de Negocio

129

Cervecera Polar C.A Territorio Oriente Sur Ingeniera de requisitos para procesos de ejecucin de estrategias de mercadeo (Impulsos y Fachadas), Coordinacin de Desarrollo en el Punto de Venta Cervecera Polar C.A Territorio Comercial Oriente Sur. MODELADO DEL NEGOCIO 1.0 Autor Karinthia Sarabia Karinthia Sarabia Karinthia Sarabia Fecha 13/07/2010 19/08/2010 28/10/2010 Versin 0.90 0.91 1.0 Descripcin Versin preliminar como propuesta de desarrollo. Correccin de la versin preliminar Versin final

1.

Introduccin El modelo de anlisis del negocio es un documento que permite revisar y

verificar el dominio organizacional donde operar el sistema. Este documento tiene como propsito realizar un anlisis del modelado de negocio del sistema a desarrollar; el objetivo es verificar y validar con los usuarios que el modelo de negocio est representado correctamente y cumple con los procesos de negocio actuales. Este documento representa el modelo de negocio siendo el primer proceso tcnico del mtodo Watch realizando un anlisis a profundidad para la Coordinacin de Desarrollo en el Punto de Venta, ya que para realizar la ingeniera de requisitos es necesario contar con el modelado de negocio del sistema de negocio .Por medio de entrevistas con el personal se logr determinar los procesos de negocio que se llevan a cabo en la Coordinacin de Desarrollo en el Punto de Venta.

130

Cervecera Polar C.A Territorio Oriente Sur 2. 2.1 Modelo de Objetivos Representacin del Modelado de Negocio El proyecto se desarrolla bajo el enfoque de la metodologa WATCH, donde el modelado del negocio se estableci mediante UML BUSINESS una extensin del lenguaje UML, que est orientado a procesos de negocio que incorpora nuevos smbolos para modelar procesos de negocios, emplea estereotipos para agregar mayor semntica a los smbolos utilizados, usa cadena de valor de MICHAEL PORTER para modelar procesos al ms alto nivel y descomponer cada proceso de la cadena de valor en sub-procesos de ms bajo nivel, los cuales sern desglosados de manera ms especfica y completa. El proceso inicial es la identificacin del punto de venta, el cual es realizado por el Supervisor Comercial y bajo la supervisin del Gerente de la Agencia. Para continuar con la recepcin de los requerimientos de los procesos Impulsos y/o Fachadas por parte de los Gerentes de las Agencias, a continuacin se procede con la seleccin de proveedores que ejecutaran las estrategias de mercadeo en las localidades necesarias, se encarga de esta seleccin el Coordinador de Desarrollo en el Punto de Venta; seguidamente se deriva el desarrollo de Impulsos y/o Fachadas una vez puesta en marcha estos procesos continua hacia el Seguimiento de Impulsos y Fachadas bajo el control de los Supervisores Comerciales y respectivo Gerente de la Agencia donde se ejecutan los Impulsos y Fachadas, para finalizar se procede al Procesamiento de Factura De acuerdo la Coordinacin de Desarrollo en el Punto de Venta, el mismo est conformado por quince (15) funcionarios, los cuales se detallan a continuacin precisando el nmero de personas que ocupan cada cargo: 1 Coordinador de Desarrollo en el Punto de Venta, 12 Gerentes de Agencias, 1 Analista de DPV, 1 Almacenista.

131

Cervecera Polar C.A Territorio Oriente Sur 2.2 Modelo de Jerarqua de Sistemas de la Coordinacin Desarrollo en el Punto

de Venta En esta seccin se genera como producto un diagrama de jerarqua del sistema de negocio, este diagrama permite representar la jerarqua de los sistemas de la Cervecera Polar C.A con respecto al rea en estudio. El suprasistema corresponde a Cervecera Polar C.A Territorio Comercial C.A como la cabecera principal del sistema el cual da origen a cada rea que administra como un todo. El sistema en estudio corresponde a la Coordinacin de Desarrollo en el Punto de Venta una de las reas adscrita a la Gerencia de ventas, sus sub-procesos son identificados como las estrategias de mercadeo (Impulsos y/o Fachadas) aplicados a los puntos de venta. La Figura 20 muestra el diagrama de jerarqua del negocio basado en el primer modelo de Derek Hitchins (2000).

132

Figura 20. Modelo de Jerarqua de Sistemas de la Coordinacin de Desarrollo en el Punto de Venta.

133

Cervecera Polar C.A Territorio Oriente Sur

2.3

Modelo de Objetivos del Negocio Un objetivo representa la intencin o camino a seguir, es un resultado establecido de antemano por los miembros de la empresa o del Sistema de Negocios. Los Objetivos representan y justifican la existencia del sistema, orientan su desempeo y permiten evaluar su presencia y continuidad en el ambiente competitivo en el cual se encuentra inmerso. (Chiavenato, 2000).

Formulacin de la Visin y Misin de la Coordinacin de Desarrollo en el Punto de Venta La Coordinacin de Desarrollo en el Punto de Venta de Cervecera Polar C.A no contaba con una visin ni misin formalmente definidas. Por lo tanto se procedi a realizar la formulacin de la misin y visin para la coordinacin. Para su elaboracin fue fundamental una entrevista con el coordinador de la unidad en estudio, lo que permiti obtener informacin sobre aspectos claves que sirvieron de base para la enunciacin de la filosofa organizativa. Se tom como referencia los criterios de evaluacin de Fred David (1998) de su libro Conceptos de Administracin Estratgica y Humberto Serna (1999) como hace mencin en su libro Gerencia Estratgica, (ver Cuadro 58 y Cuadro 59), que permitieron verificar si la visin y misin estaban bien formuladas y cumplan con los requisitos preestablecidos, igualmente fueron evaluadas con base a dichos criterios. Segn Fred David (1998). La misin es definida de la siguiente manera: es un propsito duradero, es lo que distingue a una empresa de otras parecidas. Identifica el alcance de las operaciones de una empresa en los aspectos del producto y del mercado.

134

Cervecera Polar C.A Territorio Oriente Sur Cuadro 58. Preguntas claves con que debe cumplir la Misin
Misin: Preguntas Claves Quines somos? Identidad y reconocimiento legal que otorga legitimidad a nuestra accin. Qu buscamos? Las funciones principales de la organizacin. Cambios fundamentales que deseamos lograr en el medio en el cual trabajamos. Razn de ser de la organizacin. Por qu lo hacemos? Valores como principios y motivaciones de orden moral, religioso, poltico, social y cultural. Para quienes trabajamos? Sectores sociales hacia los cuales se orientan principalmente nuestros esfuerzos.

Fuente: David, F. (2005) p.97 Segn Serna (1999) La visin corporativa es un conjunto de ideas generales, algunas de ellas abstractas, las cuales proveen el marco de referencia de lo que una empresa es y quiere ser en el futuro. Cuadro 59. Preguntas claves con que debe cumplir la Visin
Visin: Preguntas Claves Cul deseada? es la imagen Cmo vemos a la poblacin con la cual trabajamos?, es decir, cul es la situacin futura deseada para nuestros usuarios o beneficiarios. Cmo futuro? seremos en el Cmo nos vemos en el futuro? es decir, cual ser la posicin futura de nuestra organizacin en relacin a otras organizaciones. Qu haremos en el futuro? Qu queremos hacer en el futuro? Cules son las contribuciones distintas que queremos hacer en el futuro y/o cules son los principales proyectos o actividades que queremos desarrollar?

Fuente: Serna, H. (1999) p.78

135

Cervecera Polar C.A Territorio Oriente Sur Formulacin de la Misin A continuacin se presenta la formulacin de la misin para la Coordinacin de Desarrollo en el Punto de Venta, la cual ser sometida a una respectiva evaluacin para determinar si cumple o no con los lineamientos establecidos por Fred David (ver Cuadro 60). Seguidamente se valorar si sta corresponde con las premisas bsicas para la evaluacin de la misin, (ver Cuadro 61). Declaracin de la Misin Somos una coordinacin dedicada atender las necesidades, gustos y preferencias del consumidor del Territorio Oriente Sur, apoyados en tecnologa de punta y un equipo profesional altamente capacitado, experimentado y comprometido. Encargado de la aplicacin de estrategias de mercadeo de alto impacto con la finalidad de promover un consumo sano y responsable en la familia Venezolana, contribuyendo afianzar el liderazgo de nuestros productos y marcas, por ende la consolidacin de la empresa. Cuadro 60. Evaluacin de la Misin
Misin: Preguntas Claves Quines somos? Somos una coordinacin dedicada atender las necesidades, gustos y preferencias del consumidor del Territorio Oriente Sur Qu buscamos? Encargado de la aplicacin de estrategias de mercadeo de alto impacto. Por qu lo hacemos? Porque estamos contribuyendo afianzar el liderazgo de nuestros productos y marcas, por ende la consolidacin de la empresa. Para quienes trabajamos? Con la finalidad de promover un consumo sano y responsable en la familia Venezolana.

136

Cervecera Polar C.A Territorio Oriente Sur Como se puede observar, la misin formulada para la CDPV responde a todas las preguntas claves que debe contener la misin, todo ello con el propsito de contar con una misin completa y representativa de la coordinacin. Para concluir con la evaluacin de la misin, se elabor el (Cuadro 61), con el propsito de certificar si sta cumpla con los nueve elementos esenciales para su declaracin. Cuadro 61. Premisas bsicas para la Evaluacin de la Misin
Departamento Inters por si misma SI Inters Supr. Tecnologa Empleado SI Mercado Filosofa Servicio Imagen SI Cliente SI

Coordinacin de Desarrollo en el Punto de Venta

SI

SI

SI

SI

SI

La matriz arroj como resultados 9 Si, 9/9 = 1*100% = 100%. Una vez evaluada completamente la misin para la Coordinacin de Desarrollo en el Punto de Venta, se puede concluir que cumple con todos los lineamientos y premisas bsicas establecidas por Fred David. Formulacin de la Visin Declaracin de la Visin Posicionarse como una coordinacin slida tanto tecnolgica como humanamente. Con procedimientos y funciones bien definidas. Llegar a ser reconocido por lograr lo ms altos niveles de presencia en todo el Territorio Oriente Sur a travs de la representacin de nuestros productos y marcas en los puntos de venta.

137

Cervecera Polar C.A Territorio Oriente Sur Compuesto por profesionales integrales capacitados en mercadeo y publicidad que constantemente trabajan en la creacin, diseo e implementacin de nuevas estrategias, enmarcadas en la innovacin y vanguardia contribuyendo a colocarnos en la primera posicin del mercado entre los gustos, preferencias de nuestros clientes y pblico. A continuacin se muestra la evaluacin correspondiente a la visin formulada, (ver Cuadro 62). Cuadro 62. Evaluacin de la Visin
Visin: Preguntas Claves Cul deseada? es la imagen Llegar a ser reconocido por lograr lo ms altos niveles de presencia en todo el Territorio Oriente Sur a travs de la representacin de nuestros productos y marcas en los puntos de venta. Cmo futuro? seremos en el Posicionarse como una coordinacin slida tanto

tecnolgica como humanamente. Con procedimientos y funciones bien definidas.

Qu haremos en el futuro?

Trabajar en la creacin, diseo e implementacin de nuevas estrategias, enmarcadas en la innovacin y vanguardia contribuyendo a colocarnos en la primera posicin del mercado entre los gustos, preferencias de nuestros clientes y pblico.

La visin formulada responde a las preguntas propuestas por el referido autor, por lo tanto ser sometida a una evaluacin final de alineacin con el propsito de definir si es considerada como visin formal de la Coordinacin de Desarrollo en el Punto de Venta.

138

Cervecera Polar C.A Territorio Oriente Sur Objetivos Objetivos de Alto Nivel Garantizar el cumplimiento de los planes y actividades promocionales de las marcas enfocados a la satisfaccin de las necesidades de los clientes mediante la aplicacin de estrategias de mercadeo. Objetivos de Bajo Nivel 1. Identificar posibles puntos de venta para la ejecucin de las estrategias de

mercadeo Impulsos y Fachadas. 2. Examinar las solicitudes de los Supervisores Comerciales priorizndolos

tomando como base el presupuesto de la Agencia. 3. Asignar de los puntos de venta a los proveedores que ejecutaran las estrategias

de mercadeo Impulsos y/o Fachadas. 4. Ejecutar las estrategias de mercadeo Impulsos y/o Fachadas en los puntos de

venta seleccionados. 5. Validar la ejecucin estrategias de mercadeo Impulsos y/o Fachadas en los

puntos de venta realizados por los proveedores. 6. Verificar el cumplimiento de las estrategias de mercadeo aplicadas a los puntos

de venta. Diagrama de Objetivos La misin, visin, y los objetivos de la Coordinacin de Desarrollo en el Punto de Venta puede percibirse en el Diagrama de Objetivos mostrado en el Diagrama 1.

139

Objetivo ::COORDINACIN DE DESARROLLO EN EL PUNTO DE VENTA

Objetivo Objetivo

Visin

Diagrama 1. Diagrama de Objetivos.

Misin
Objetivo

Somos una coordinacin dedicada atender las necesidades, gustos y preferencias del consumidor del Territorio Oriente Sur, apoyados en tecnologa de punta y un equipo profesional altamente capacitado, experimentado y comprometido. Encargado de la aplicacin de estrategias de mercadeo de alto impacto con la finalidad de promover en consumo sano y responsable en la familia Venezolana, contribuyendo afianzar el liderazgo de nuestros productos y marcas, por ende la consolidacin de la empresa. Objetivo General Garantizar el cumplimiento de los planes y actividades promocionales de las marcas enfocados a la satisfaccin de las necesidades de los clientes mediante la aplicacin de estrategias de mercadeo.

Posicionarse como una coordinacin slida tanto tecnolgica como humanamente. Con procedimientos y funciones bien definidas. Llegar a ser reconocido por lograr lo ms altos niveles de presencia en todo el Territorio Oriente Sur a travs de la representacin de nuestros productos y marcas en los puntos de venta. Compuesto por profesionales integrales capacitados en mercadeo y publicidad que constantemente trabajan en la creacin, diseo e implementacin de nuevas estrategias, enmarcadas en la innovacin y vanguardia contribuyendo a colocarnos en la primera posicin del mercado entre los gustos, preferencias de nuestros clientes y pblico.

140
Objetivo Objetivo
Asignar de los puntos de venta a los proveedores que ejecutaran los Impulsos y o Fachadas. Examinar las Solicitudes de los Supervisores Comerciales priorizandolos tomando como base el presupuesto disponible para la agencia.

Objetivo

Objetivo
Ejecutar las estrategias de mercadeo Impulsos y/o Fachadas en los puntos de venta previamente seleccionados

Objetivo
Validar la ejecucin de Impulsos y/o Fachadas en los puntos de venta realizados por los proveedores

Objetivo
Verificar del cumplimiento de las estrategias de mercadeo Impulsos y/o Fachadas aplicadas en los puntos de venta.

Cervecera Polar C.A Territorio Oriente Sur

Identificar los posibles puntos de venta para la ejecucin de las estrategias de mercadeo Impulsos y/o Fachadas.

Cervecera Polar C.A Territorio Oriente Sur 3. Modelo de Procesos del Negocio Los modelos de procesos de negocio estn enfocados principalmente a la descripcin de estos, es decir, consisten en representar los elementos que intervienen en la realizacin de algn proceso, que factores influyen y que pasos son llevados a cabo para el cumplimiento del mismo. Describe los procesos que son realizados en la organizacin a travs de un conjunto estructurado de actividades, diseado para producir una salida determinada o lograr un objetivo, esto es alcanzado por personas, maquinarias o su interrelacin (actores). Los procesos describen cmo es realizado el trabajo en la empresa y se caracterizan por ser observables, medibles, mejorables y repetitivos. Estructuralmente, un proceso de negocio est constituido por un conjunto de actividades. As, la actividad, como elemento bsico, mediante relaciones o dependencias con otras actividades conforma la estructura de un proceso de negocio. El proceso de negocio implica un fuerte nfasis en cmo se hace el trabajo en una organizacin. As, un proceso es un ordenamiento especfico de actividades de trabajo a travs del tiempo y del espacio, con un comienzo, unas reglas, actividades impulsadas por eventos, unos actores que las llevan a cabo, un fin, entradas y salidas claramente identificados, una estructura para la accin. 3.1 Cadena de Valor del Negocio Se empleo la cadena de valor de Michael Porter como modelo para analizar las Actividades Primarias (procesos fundamentales o primarios) y las Actividades de Soporte (procesos de apoyo o soporte) del sistema de negocio, la Coordinacin de Desarrollo en el Punto de Venta, la Coordinacin de Mercadeo de Canales conjuntamente con la unidad Supervisin de Vinos y Derivados integran la Gerencia de Ventas de Cervecera Polar Territorio Comercial Oriente Sur es por ello que primeramente se model la Cadena de Valor de la Gerencia de Ventas, con la finalidad de comprender mejor el sistema de negocio y su entorno. A continuacin se

141

Cervecera Polar C.A Territorio Oriente Sur presenta en la Figura 21 la Cadena de Valor para la Gerencia de Ventas. Posteriormente se mostrara la Cadena de valor para la Coordinacin de Desarrollo en el Punto de Venta.

Procesos Primarios

Ventas

Distribucin

Franquicia Gestin de Gente Administracin Procesos de Apoyo Servicio al Cliente Sistemas Flota Auditora

Figura 21. Cadena de Valor de la Gerencia de Ventas del Territorio Comercial Oriente Sur. 3.2 Diagrama Jerrquico de Procesos de Negocio Este modelo est conformado en principio por los Diagramas Jerrquicos de Procesos de Negocio, los cuales permiten descomponer de forma recursiva cada unidad de negocio hasta que los mismos slo puedan ser explicados mediante un conjunto de actividades. El diagrama de jerarqua de procesos muestra la descomposicin de los procesos fundamentales de la cadena de valor en subprocesos ms simples que 142

Cervecera Polar C.A Territorio Oriente Sur apoyan a la realizacin del mismo, cada proceso de negocio localizado en los niveles ms bajos contribuye a la realizacin de los procesos de ms alto nivel manteniendo la integridad y coherencia entre los mismos. El proceso es descompuesto hasta que pueda ser explicado a travs de diagramas de actividades, una actividad describe el flujo de trabajo de un proceso de negocio de un sistema que es ejecutado por un actor (maquinarias, personas, entre otros). A continuacin se detalla el Diagrama 2, ste muestra el diagrama jerarqua para la Gerencia de Venta

Ventas

Nivel 0

Mercadeo de Canales

Desarrollo en el Punto de Venta

Supervisin de Vinos y Derivados

Nivel 1

Diagrama 2. Diagrama de Jerarqua de la Gerencia de Ventas. Una vez realizados tanto la cadena de valor como el diagrama jerarqua para la Gerencia de Ventas que constituye los procesos de alto nivel desde donde se desprende el sistema de negocio objeto de estudio la Coordinacin de Desarrollo en el Punto de Venta se procedi a realizar la cadena de valor para esta unidad. La Cadena de Valor para la Coordinacin de Desarrollo en el Punto de Venta se defini de la siguiente manera: las actividades principales son los dos (2) procesos que se manejan en esa coordinacin, las cuales permiten que la ejecucin de las estrategias de mercadeo Impulsos y Fachadas desde su planificacin, para continuar con el desarrollo hasta llegar a la validacin de las mismas. Las actividades de soporte son aquellas que sirven de apoyo para la realizacin de las actividades dentro del rea.

143

Cervecera Polar C.A Territorio Oriente Sur

Coordinacin Desarrollo en Punto de Venta

Procesos Primarios

Impulsos

Fachadas

Coordinacin Mercadeo de Canales Proveedores de Servicio Procesos de Apoyo Administracin Abastecimiento Sistemas

Figura 22. Cadena de Valor de la Coordinacin de Desarrollo en el Punto de Venta. Las actividades de soporte son todas aquellas que aportan procesos, materiales o espacio fsico para que se puedan dar todos los procesos de la Coordinacin de Desarrollo en el Punto de Venta entre estas se encuentran: Coordinacin Mercadeo de Canales: es la unidad encargada de proporcionar la tramitacin de los acuerdos comerciales que involucran a los puntos de venta que sern objeto para ejecucin de las estrategias de mercadeo Impulsos y/o Fachadas. Proveedores de Servicio: son indispensables para el cumplimiento de las estrategias de mercadeo Impulsos y Fachadas, debido a que son los encargados de la ejecucin de dichas estrategias, por lo tanto contribuyen notablemente en el proceso.

144

Cervecera Polar C.A Territorio Oriente Sur Administracin: es el departamento designado para gestionar la cancelacin del pago de facturas emitidas por los proveedores de servicio, posterior a la ejecucin de Impulsos y Fachadas. Abastecimiento: se refiere a las compras realizadas especficamente aquellas que tienen relacin con los procesos Impulsos y Fachadas, entre este tipo se tienen: material POP y uniformes que son utilizados en la ejecucin del proceso Impulsos. Sistemas: es el departamento que brinda el soporte tecnolgico necesario para la comunicacin de los diferentes actores que participan en el proceso de la aplicacin de las estrategias de mercadeo Impulsos y Fachadas. Los procesos Impulsos y Fachadas deben de cumplir con una serie de pasos a seguir antes de que sean ejecutados en los puntos de venta. Sin embargo aunque la ejecucin de cada uno de estos producen distintos resultados, ambos estrategias de mercadeo deben cumplir con pasos, los cuales no presentan diferencias. Es por ello que para ambas estrategias de mercadeo se defini en: identificacin del punto, anlisis de oportunidades, ejecucin de la estrategia y procesamiento de factura. De esta descomposicin la seccin anlisis de oportunidades se subdivide en: recepcin de requerimientos y a su vez la seccin ejecucin de la estrategia se subdivide en Desarrollo Impulsos y/o Fachadas y Seguimiento de Impulsos y/o Fachadas. A continuacin se detalla el Diagrama 3, ste muestra el diagrama jerarqua para la Coordinacin de Desarrollo en el Punto de Venta.

145

Desarrollo en el Punto de Venta

Nivel 1

Diagrama 3. Diagrama de Jerarqua de la Coordinacin de Desarrollo en el Punto de Venta.

146
Anlisis de Oportunidades PF-2 PF-3 PF-4 Ejecucin de la Estratgia Seleccin de Proveedores PF-2.2 Desarrollo de Impulsos y/o Fachadas PF-3.1

Identificacin del Punto

Procesamiento de Factura

Nivel 2

PF-1

Recepcin de Requerimientos

Nivel 3

Cervecera Polar C.A Territorio Oriente Sur

PF-2.1

Seguimiento de Impulsos y/o Fachadas PF-3.2

Cervecera Polar C.A Territorio Oriente Sur 3.3 Diagramas de Proceso para los Procesos Fundamentales Impulsos y

Fachadas Proceso PF-1 Identificacin del Punto El proceso 1 es la Identificacin del Punto que tiene como propsito identificar los posibles puntos de venta para la ejecucin de las estrategias de mercadeo Impulsos y/o Fachadas.

Regla Procedimiento para ejecucin de Impulsos Actor Gerente de la Agencia Procedimiento para ejecucin de Fachadas

Objetivo Identificar posibles puntos de venta para la ejecucion de las estrategias de mercadeo Impulsos y Fachadas

controla

regula

Datos de los puntos de venta: Propietario Cdula Razn Social RIF Contacto Direccion Fiscal y Fsica Tipo de cliente

cumple

Identificacin del Punto PF-1

Solicitudes de los Supervisores Comerciales Acuerdo Comercial

ejecuta

apoya

Actor Supervisor Comercial

Informacin Formato de Testigo del Territorio Mapa de zonas de la Agencia

Diagrama 4. Diagrama de Proceso - Identificacin del Punto.

147

Cervecera Polar C.A Territorio Oriente Sur Proceso PF-2 Anlisis de Oportunidades PF-2.1 Recepcin de Requerimientos El proceso 2.1 Recepcin de Requerimientos persigue examinar las Solicitudes de los Supervisores Comerciales, para ser priorizadas de acuerdo al presupuesto disponible para la agencia.

Regla Procedimiento para ejecucin de Impulsos Actor Coordinador Desarrollo Punto de Venta del Territorio Procedimiento para ejecucin de Fachadas

Objetivo Examinar las Solicitudes de los Supervisores Comerciales priorizandolos tomando como base el presuesto de la Agencia

controla

regula

cumple

Solicitudes de los Supervisores Comerciales

Recepcin de Requerimientos
Presupuesto para la Agencia

Formato de Solicitud de Impulsos

PF-2.1

Formato de Solicitud de Fachadas

ejecuta

Actor Gerente de la Agencia

Diagrama 5. Diagrama de Proceso - Recepcin de Requerimientos.

148

Cervecera Polar C.A Territorio Oriente Sur Proceso PF-.2 Anlisis de Oportunidades PF-2.2 Seleccin de Proveedores El proceso 2.2 Seleccin de Proveedores tiene como finalidad la asignacin de los puntos de venta a los proveedores que ejecutaran los Impulsos y o Fachadas.

Regla Procedimiento para ejecucin de Impulsos Actor Coordinador Desarrollo Punto de Venta del Territorio Procedimiento para ejecucin de Fachadas

Objetivo Asignar los puntos de venta a los proveedores que ejecutaran los Impulsos y/o Fachadas

Formato de Solicitud de Impulsos Formato de Solicitud de Fachadas Presupuestos de los Proveedores

controla

regula

cumple

Puntos de Venta a ejecutar (Impulsos y Fachadas)

Seleccin de Proveedores PF-2.2

Proveedores asignados a los puntos de venta

Cotizaciones aprobadas
ejecuta

Actor Gerente de la Agencia

Diagrama 6. Diagrama de Proceso - Seleccin de Proveedores.

149

Cervecera Polar C.A Territorio Oriente Sur Proceso PF-3 Ejecucin de la Estrategia PF-3.1 Desarrollo de Impulsos y/o Fachadas El proceso 3.1 Desarrollo de Impulsos y/o Fachadas persiguen como objetivo ejecutar las estrategias de mercadeo Impulsos y/o Fachadas en los puntos de venta previamente seleccionados.

Actor Coordinador Desarrollo Punto de Venta del Territorio Gerente de Agencia Puntos de Venta a ejecutar (Impulsos y Fachadas) Proveedores asignados a los puntos de venta Material POP (Point of Purchase) y Uniformes

Regla Procedimiento para ejecucin de Impulsos Procedimiento para ejecucin de Fachadas

Objetivo Ejecutar las estrategias de mercadeo Impulsos y Fachadas en los puntos de venta seleccionados

controla

regula

cumple

Puntos de venta ejecutados

De sarrollo de Impulsos y/o Fachadas PF-3.1

Reportes fotograficos

Reportes de inventario
ejecuta apoya

Productos para degustaciones

Actor Proveedor

Informacin Arte del trabajo (logos, standares de colores, dimensiones)

Diagrama 7. Diagrama de Procesos - Desarrollo de Impulsos y/o Fachadas.

150

Cervecera Polar C.A Territorio Oriente Sur Proceso PF-3 Ejecucin de la Estrategia PF-3.2 Seguimiento de Impulsos y/o Fachadas El proceso 3.2 Seguimiento de Impulsos y/o Fachadas tienen como propsito validar la ejecucin de Impulsos y/o Fachadas en los puntos de venta realizados por los proveedores de servicio.

Actor Coordinador Desarrollo Punto de Venta del Territorio Gerente de Agencia

Regla Procedimiento para ejecucin de Impulsos Procedimiento para ejecucin de Fachadas

Objetivo Validar la ejecucin de Impulsos y Fachadas en los puntos de venta realizados por los proveedores

controla

regula cumple

Puntos de venta ejecutados

Reportes fotograficos

Seguimiento de Impulsos y/o Fachadas PF-3.2

Puntos de venta validados

Reporte de inventario
ejecuta apoya

Actor Supervisor Comercial

Informacin Arte del trabajo (logos, standares de colores, dimensiones)

Diagrama 8. Diagrama de Proceso - Seguimiento de Impulsos y/o Fachadas.

151

Cervecera Polar C.A Territorio Oriente Sur Proceso PF-4 Procesamiento de Factura El proceso 4 Procesamiento de Factura persigue la verificacin del cumplimiento de las estrategias de mercadeo Impulsos y/o Fachadas aplicadas en los puntos de venta.

Actor Coordinador Desarrollo Punto de Venta del Territorio

Regla Procedimiento para ejecucin de Impulsos Procedimiento para ejecucin de Fachadas

Objetivo Verificar el cumplimiento de las estrategias de mercadeo Impulsos y Fachadas aplicadas en los puntos de venta

Factura Orden de compra Reportes fotograficos Reportes de inventario

controla

regula

cumple

Procesamiento de Factura PF-4

Facturas aprobadas

ejecuta

Actor Gerente de la Agencia

Diagrama 9. Diagrama de Proceso - Procesamiento de Factura. 3.4 Diagramas de Actividades Un diagrama de actividades representa los flujos de trabajo, paso a paso, de los componentes de un sistema. Los diagramas de actividades muestran el flujo desde el punto de inicio hasta el punto final detallando muchas de las rutas de decisiones que existen en el progreso de eventos contenidos en la actividad. Estos tambin pueden usarse para detallar situaciones donde el proceso paralelo puede ocurrir en la ejecucin de algunas actividades. Estos diagramas modelan el flujo de trabajo del negocio, y se dividen en:

152

Cervecera Polar C.A Territorio Oriente Sur A. El Flujo de Control: donde se muestra el orden de las acciones que son

realizadas con el propsito de producir las salidas preestablecidas y cumplir con los objetivos de la organizacin. B. El Flujo de Objetos: el cual muestra todos objetos (informes, reporte,

documentos, etc.) que entran y salen de cada una de las actividades ejecutadas por los actores. Los diagramas del 10 al 21 muestran los Diagramas de Actividades de los Procesos de Negocio de ms bajo nivel de la Coordinacin de Desarrollo en el Punto de Venta, son presentados tanto los Flujos de Control como los Flujos de Objetos.

Identificacin del Punto

Inicio

Flujo de control

Detectar oportunidades en el mercado

Identificar las necesidades de la zona tanto para la solicitud de im pulsos de venta como para la solicitud de fachadas externa e interna de los negocios

El Punto de Venta m antiene acuerdos con la empresa?

NO

Realizar la negociacin y respectivo acuerdo comercial

SI Realizar la notificacin con el cliente

Analizar y estudiar la zona donde se encuentra el negocio

Consolidar, verificar y analizar las necesidades de la Agencia

Asignar un respectivo orden de prioridades Fin

Diagrama 10. Diagrama de Actividades - Identificacin del Punto - Flujo de Control.

153

Cervecera Polar C.A Territorio Oriente Sur

Identificacin del Punto

Inicio

Flujo de objetos

Detectar oportunidades en el mercado

Identificar las necesidades de la zona tanto para la solicitud de impulsos de venta como para la ejecucin externa e interna de los negocios

Datos de los puntos de venta

El Punto de Venta mantiene acuerdos con la empresa?

NO

Realizar la negociacin y respectivo acuerdo comercial

Acuerdo comercial

SI Realizar la notificacin con el cliente

Analizar y estudiar la zona donde se encuentra el negocio

Consolidar, verificar y analizar las necesidades de la Agencia

Solicitudes de los Supervisores Comerciales

Asignar un respectivo orden de prioridades

Fin

Diagrama 11. Diagrama de Actividades - Identificacin del Punto - Flujo de Objetos.

154

Cervecera Polar C.A Territorio Oriente Sur

Recepcin de requerimientos
Inicio

Flujo de control

Enviar a las agencias el presupuesto disponible por mes

Totalizar las necesidades de la agencia

Recibir en la Coordinacion Desarrollo en el Punto de Venta

Elaborar formatos de las solicitudes de Impulsos y Fachadas a enviar

Fin

Diagrama 12 Diagrama de Actividades - Recepcin de Requerimientos - Flujo de Control.

Recepcin de requerimientos
Presupuesto Inicio Solicitudes de los supervisores comerciales Enviar a las agencias el presupuesto disponible por mes

Flujo de objetos

Totalizar las necesidades de la agencia

Recibir en la Coordinacion Desarrollo en el Punto de Venta

Formato de solicitudes de Impulsos

Elaborar formatos de las solicitudes de Impulsos y Fachadas a enviar

Formato de solicitudes de Fachadas Fin

Diagrama 13. Diagrama de Actividades - Recepcin de Requerimientos - Flujo de Objetos.

155

Cervecera Polar C.A Territorio Oriente Sur

Seleccin de proveedor
Inicio

Flujo de control

Revisar los formatos de solicitudes de Impulsos y/o Fachadas

Tiene requerimientos de Impulsos y/o Fachadas?

NO

SI

Aprobar en conjunto la marca que se va a utilizar en la ejecucin del trabajo

Estn de acuerdo?

NO

SI Contactar a proveedores que ofrezca servicios de publicidad y promociones Recibir cotizaciones por parte de los proveedores

Realizar la solicitud de presupuestos a los proveedores

Analizar las cotizaciones de los proveedores

Recibir la solicitud de presupuestos

Seleccionar los puntos de venta a ejecutar de acuerdo al presupuesto disponible

Elaborar presupuesto del trabajo para enviar a la CDPV

Asignar a un proveedor la ejecucin del trabajo

Fin

Diagrama 14. Diagrama de Actividades - Seleccin de Proveedor - Flujo de Control.

156

Cervecera Polar C.A Territorio Oriente Sur

Seleccin de proveedor

Flujo de objetos

Revisar los formatos de solicitudes de Impulsos y/o Fachadas

Formatos de solicitud de Impulsos Inicio Formatos de solicitud de Fachadas

Tiene requerimientos de Impulsos y/o Fachadas? SI

NO

Aprobar en conjunto la marca que se va a utilizar en la ejecucin del trabajo

Estn de acuerdo?

NO

SI Lista de proveedores

Presupuestos de los proveedores

Asignar a un proveedor la ejecucin del trabajo

Contactar a proveedores que ofrezca servicios de publicidad y promociones

Recibir cotizaciones por parte de los proveedores Puntos de venta asignados a proveedores Orden de compra

Realizar la solicitud de presupuestos a los proveedores

Analizar las cotizaciones de los proveedores

Lista de requerimientos de puntos de venta

Cotizaciones aprobadas

Recibir la solicitud de presupuestos

Seleccionar los puntos de venta a ejecutar de acuerdo al presupuesto disponible

Fin

Elaborar presupuesto del trabajo para enviar a la CDPV

Puntos de Venta a ejecutar (Impulsos y/o Fachadas)

Diagrama 15. Diagrama de Actividades - Seleccin de Proveedor - Flujo de Objetos

157

Cervecera Polar C.A Territorio Oriente Sur

Desarrollo de Impulsos y/o Fachadas

Inicio

Flujo de control

Solicitar la ejecucion de Impulsos y/o Fachadas a los proveedores previamente seleccionados

Recibir las especificaciones del trabajo a realizar

Requiere de Material POP, Producto y/o Uniformes?

SI

La Agencia cuenta con el material requerido?

NO

Enviar una solicitud a la Oficina Principal del Territorio

Recibir la solicitud en la Oficina Principal del Territorio

SI

Recibir el material en la Agencia

Enviar a la Agencia solicitante

NO Suministrar al proveedor previo a la ejecucin de la actividad

Proceder a la ejecucin

Generar reportes sobre la ejecucin de la actividad Fin

Diagrama 16. Diagrama de Actividades - Desarrollo de Impulsos y/o Fachadas Flujo de Control.

158

Cervecera Polar C.A Territorio Oriente Sur

Desarrollo de Impulso y/o Fachada

Orden de Compra Solicitar la ejecucion de Impulsos y/o Fachadas a los proveedores previamente seleccionados

Flujo de objetos

Proveedores asignados a los puntos de venta Puntos de venta a ejecutar (Impulsos y/o Fachadas)

Inicio

El proveedor requiere de Material POP, Producto y/o Uniformes?

SI

La Agencia cuenta con el material requerido?

NO Enviar una solicitud a la Oficina Principal del Territorio

Solictud de material

NO

SI

Recibir la solicitud en la Oficina Principal del Territorio

Recibir el material en la Agencia

Enviar a la Agencia solicitante

Suministrar al proveedor previo a la ejecucin de la actividad

Nota envio de material

Material

Material entregado a los proveedores

Nota de entrega material entregado a los proveedores

Reportes fotograficos

Proceder a la ejecucin

Generar reportes sobre la ejecucin de la actividad

Reportes de Inventario Fin Puntos de venta ejecutados

Diagrama 17. Diagrama de Actividades - Desarrollo de Impulsos y/o Fachadas Flujo de Control.

159

Cervecera Polar C.A Territorio Oriente Sur

Seguimiento de Impulsos y/o Fachadas

Inicio

Flujo de control

Supervisar la actividad realizada por el proveedor en el sitio

Revisar los reportes de inventario y reportes fotograficos

Validar el cumplimiento apegado a los standares establecidos por la CDPV

El Proveedor realizo trabajo cumpliendo requerimientos?

NO

Tomar acciones para ajustar el trabajo a los requerimientos

SI Aprobar la ejecucin del trabajo realizado

Fin

Diagrama 18. Diagrama de Actividades - Seguimiento de Impulsos y/o FachadasFlujo de Control.

160

Cervecera Polar C.A Territorio Oriente Sur

Seguimiento de Impulsos y/o Fachadas

Inicio

Flujo de objetos

Supervisar la actividad realizada por el proveedor en el sitio

Reportes fotogrficos

Reportes de inventario

Validar el cumplimiento apegado a los standares establecidos por la CDPV

Revisar los reportes de promotoras y reportes fotograficos

El Proveedor realizo trabajo cumpliendo requerimientos?

NO

Tomar acciones para ajustar el trabajo a los requerimientos

SI

Puntos de venta rechazados

Aprobar la ejecucin del trabajo realizado Fin

Diagrama 19. Diagrama de Actividades - Seguimiento de Impulsos y/o Fachadas - Flujo de Objetos.

161

Cervecera Polar C.A Territorio Oriente Sur

Procesamiento de factura
Inicio

Flujo de control

Enviar factura a la Agencia

Enviar factura de ejecucin de Impulsos y/o Fachadas a la Oficina Principal del Territorio

Recibir factura en la Agencia

Recibir factura de ejecucin de Impulsos y/o Fachadas

Revisar factura de ejecucin de Impulsos y/o Fachadas

Aprobar factura de ejecucin de Impulsos y/o Fachadas

Aprobar factura de ejecucin de Impulsos y/o Fachadas

Enviar factura aprobadas de ejecucion de Impulsos y/o Fachadas al Departamento de Administracin para cancerlar

Fin

Diagrama 20. Diagrama de Actividades - Procesamiento de Facturas - Flujo de Control.

Procesamiento de factura
Inicio

Flujo de objetos

Factura

Enviar factura de ejecucin de Impulsos y/o Fachadas a la Oficina Principal del Territorio

Enviar factura a la Agencia

Recibir factura de ejecucin de Impulsos y/o Fachadas

Recibir factura en la Agencia

Aprobar factura de ejecucin de Impulsos y/o Fachadas

Revisar factura de ejecucin de Impulsos y/o Fachadas Factura aprobada por Coordinacin Desarrollo en el Punto de Venta

Aprobar factura de ejecucin de Impuls os y/o Fachadas

Factura aprobada por Gerente de Agencia

Enviar factura aprobadas de ejecucion de Impulsos y/o Fachadas al Departamento de Administracin para cancerlar

Factura aprobadas Fin

Diagrama 21. Diagrama de Actividades - Procesamiento de Facturas - Flujo de Objetos.

162

Cervecera Polar C.A Territorio Oriente Sur 4. Modelo de Objetos del Negocio Los Objetos del Negocio se denominan a todos aquellos elementos organizacionales que son creados, usados, consumidos y/o transformados por las actividades asociados a los procesos de negocio. Estas entidades pueden ser fsicas o abstractas. Un objeto fsico representa un objeto en el mundo real que ocupa un espacio y se localiza en un tiempo; por ejemplo un empleado, un dispositivo, un libro de registro de cuentas mientras que los objetos abstractos representan elementos convencionales productos de la mente humana, no se pueden ubicar en el tiempo ni en el espacio porque no tienen existencia fsica determinada., pero son el resultado de un acuerdo social; por ejemplo una cuenta o una transaccin bancaria. Los objetos de negocio son caracterizados por los atributos, cuyos valores los diferencian unos de otros, y por su comportamiento, que describe su actuacin y funcionalidad. Estos son parte esencial de la ejecucin de los procesos del negocio. 4.1 Diagramas de Objetos Los objetos empleados en las diferentes unidades funcionales guardan cierta relacin entre s, un ejemplo de ello puede ser la relacin que existe entre los Formatos de Solicitudes de Impulsos y el Gerente de la Agencia que los realiza, en ese caso se dice que el Gerente de la Agencia elabora un formato. El objetivo principal de los Diagramas de Objetos es presentar de forma grfica tales relaciones. A continuacin se muestran los diagramas comprendidos entre el Diagrama 22 hasta Diagrama 27 se encontrarn en las pginas 164-167, los cuales presentan los Diagramas de Objetos para la Coordinacin de Desarrollo en el Punto de Venta.

163

Cervecera Polar C.A Territorio Oriente Sur

Formato de Testigo del Territorio

consulta propone

Acuerdo comercial
contiene establece

Supervisor Comercial

captura

Punto de Venta

suministra

Datos de los puntos de venta

elabora

revisa

contiene

Solicitudes de los Supervisores Comerciales

Mapas de zonas de la Agencia

aprueba

Gerente de la Agencia

Diagrama 22. Diagrama de Objetos para el Proceso Identificacin del Punto.

164

Cervecera Polar C.A Territorio Oriente Sur

Coordinador DPV

asigna

recibe

Presupuesto

dispone

Agencia

recibe

utliza

administra

Formatos de Solicitud de Impulsos

elabora

Gerente de la Agencia
estudia

elabora

Formatos de Solicitud de Fachadas

Solicitudes de los Supervisores Comerciales

Diagrama 23. Diagrama Requerimientos.

de

Objetos para

el

Proceso

Recepcin

de

Orden de compra

Formatos de Solicitud de Fachadas Formatos de Solicitud de Impulsos

realiza

estudia estudia

Punto de venta

asigna

Coordinador DPV

consulta

Lista de proveedores

aprueba ejecuta recibe contacta

realiza

Cotizaciones

elabora

Proveedor

recibe

Lista de requerimientos de puntos de venta

contiene

Diagrama 24. Diagrama de Objetos para el Proceso Seleccin de Proveedor.

165

Cervecera Polar C.A Territorio Oriente Sur

Reporte fotogrfico

Punto de venta

Reportes de Inventario

genera

ejecuta

genera

Nota de entrega material entregado a los proveedores

recibe

Proveedor

recibe

realiza envia

Material

envia

Solictud de material
realiza

recibe

Oficina Principal del Territorio

envia

Gerente de la Agencia
recibe

Nota envo de material

recibe

Diagrama 25. Diagrama de Objetos para el Proceso Desarrollo de Impulsos y/o Fachadas.

revisa

Reporte fotogrfico

Supervisor comercial

revisa

supervisa

Reportes de inventario

resea

Punto de venta

resea

Diagrama 26. Diagrama de Objetos para el Proceso Seguimiento de Impulsos y/o Fachadas.

166

Cervecera Polar C.A Territorio Oriente Sur

Proveedor

emite contiene

Reporte fotogrfico

Administracin

cancela

Factura

contiene

Orden de compra

contiene aprueba aprueba

Reporte de Inventario

Gerente de la Agencia

Coordinador DPV

Diagrama 27. Diagrama de Objetos para el Proceso Procesamiento de Factura. 4.2 Diagrama de Clases Una clase de negocio representa a una coleccin de objetos de negocio que tienen un conjunto de atributos en comn. El diagrama de clases consta de una o ms clases de objetos de negocio y una o ms relaciones entre clases. A continuacin se presenta el diagrama de clases de la Coordinacin de Desarrollo en el Punto de Venta en el Diagrama 28

167

Empleado ::Documento Nombre: char Cdigo: char Responsable: char Fecha: char Ubicacin: char Medio: char Apellido: char Cedula: long Nombre: char Telfono: long Direccin: char Correo: char

::Cotizacin ::Factura Zona: char ::Superv isor Comercial

Gerente de la Agencia

Coordinador DPV

1..* 1 emite gestiona 1..*

elabora 1 1 ::Estrategia 1 supervisa PDV asignada asignado 1 1 1 Razn Social: char Rif: char CEP: char Propietario: char Cedula: long Contacto: char Telfono: long Direccin : char Tipo de cliente: char Tipo: char Fecha: char Supervisor encargado: char Proveedor encargado: char Punto de venta: char Agencia: char ::Prov eedor 1 1..* Razn Social: char ejecuta Rif: char Ubicacin: char 1..* 1 Tipo de Servicio: char Telfono: char Correo: char

Diagrama 28. Diagrama de Clases para la Coordinacin de Desarrollo en el Punto de Venta.

::Agencia Nombre: char Ubicacin: char Gerente: char ::Territorio

168

Cervecera Polar C.A Territorio Oriente Sur

Cervecera Polar C.A Territorio Oriente Sur 4.3 Matriz Procesos vs Objetos

Cuadro 63. Matriz Procesos vs Objetos.

Procesos de Negocio Recepcin de requerimientos Seguimiento de Impulsos y/o Fachadas Desarrollo de Impulsos y/o Fachadas

Objetos Acuerdo comercial Cotizaciones Datos de los puntos de venta Factura Formato de Solicitud de Impulsos Formato de Solicitud de Fachadas Formato de Testigo del Territorio Lista de Proveedores Lista de requerimientos de puntos de venta Mapas de zona de la Agencia Material Nota de entrega de material suministrado a proveedor Nota de envo de material Orden de compra Presupuesto Reporte fotogrfico Reporte de inventario Solicitudes de los Supervisores Comerciales Solicitudes de material

169

Procesamiento de Factura

Seleccin de proveedores

Identificacin del Punto

Cervecera Polar C.A Territorio Oriente Sur 5. Modelo de Reglas del Negocio Toda organizacin est compuesta por procesos de negocios, los cuales a su vez se encuentran regulados o controlados por un conjunto de normas, procedimientos, manuales, leyes, entre otros. A este conjunto de regulaciones se les denomina reglas del negocio. Los procesos de negocios no se encuentran delimitados solo por las tecnologas que utilizan, sino tambin por las reglas del negocio que deben cumplir. Un sistema de negocios debe atenerse a las regulaciones y leyes del gobierno de su entorno operativo, como tambin, debe satisfacer los planes y estndares establecidos internamente por los directores o representantes del negocio. Dado que los procesos se encuentran normalizados o controlados por una serie de reglas, modelar un negocio involucra la previa identificacin de los procesos y el conocimiento de las regulaciones que controlan su ejecucin. 5.1 Diagrama de Reglas Es la representacin del conjunto de reglas que controlan el proceso que se est modelando, las cuales se clasifican segn su naturaleza. A continuacin en la Figura 23 ubicada en la pgina 171 se muestra el diagrama de reglas para los procesos objeto de estudio de la Coordinacin de Desarrollo en el Punto de Venta.

170

Cervecera Polar C.A Territorio Oriente Sur

Reglas

Reglas Reglas del Negocio

Reglas LEYES

Reglas CDIGOS

Reglas PROCEDIMIENTOS

- Constitucin de la Repblica Bolivariana de Venezuela - Ley de Responsabilidad en Radio y Televisin

- Cdigo Caveface - Cdigo de Responsabilidad - Cdigo de Responsabilidad en Comunicaciones

- Procedimientos para la ejecucin de Impulsos - Procedimientos para la ejecucin de Fachadas

Figura 23. Modelo de Reglas del Negocio. 6. Modelo de Actores del Negocio Todos los procesos de negocio son llevados a cabo por actores. Un actor puede ser tanto una persona o una mquina capaz de desarrollar acciones definidas o tareas. Los actores pueden ser externos o internos dependiendo del alcance o mbito del sistema de negocios. Los actores externos son parte del entorno del sistema de negocios, ellos interactan con el sistema de negocios para suplir sus necesidades o proveer recursos. Clientes, proveedores y actores pertenecientes a otros sistemas de negocios son ejemplos de actores externos. Los actores internos, por otro lado, son parte del sistema de negocios. En vez de modelar actores como personas, un modelo de negocios se especializa mas en representar los roles que se desempean en un sistema de negocios. Cada rol es responsable de desarrollar una serie de tareas las cuales son parte de uno o ms procesos de negocios.

171

Cervecera Polar C.A Territorio Oriente Sur Los actores son asignados, de acuerdo a sus roles, a unidades de negocios. Las unidades de negocios son organizadas en estructuras de jerarqua de procesos, las cuales son comnmente representadas en el esquema de la organizacin. Este esquema define la estructura de la empresa en lneas de autoridad que gobiernan las relaciones entre las unidades de negocios. 6.1 Diagramas Actividad ActorResponsabilidad Estos diagramas representan las actividades mostradas en el Diagrama de Actividades pero indicando quin o qu realiza en cada paso de las mismas. Los diagramas Actividad Actor de la Coordinacin de Desarrollo en el Punto de Venta son mostrados en los diagramas comprendidos desde el Diagrama 29 hasta el Diagrama 34 los cuales se presentan en las pginas 173-177.

172

Cervecera Polar C.A Territorio Oriente Sur Identificacin del Punto

Supe rvisor comercial
Inicio

Ge rente de la Age ncia

Detectar oportunidades en el mercado

Identificar las necesidades de la zona tanto para la solicitud de impulsos de venta como para la solicitud de fachadas externa e interna de los negocios

El Punto de Venta mantiene acuerdos con la empresa?

NO

Realizar la negociacin y respectivo acuerdo comercial

SI Realizar la notificacin con el cliente Analizar y estudiar la zona donde se encuentra el negocio

Consolidar, verificar y analizar las necesidades de la Agencia

Asignar un respectivo orden de prioridades Fin

Diagrama 29. Diagrama Actividad/Actor/Responsabilidad Proceso Identificacin del Punto. Recepcin de Requerimientos
Coordinador DPV Ge re nte de la Agencia

Inicio

Enviar a las agencias el pres upuesto disponible por mes

Totalizar las necesidades de la agencia

Recibir en la Coordinacion Desarrollo en el Punto de Venta

Elaborar formatos de las solicitudes de Impulsos y Fachadas a enviar

Fin

Diagrama 30. Diagrama Actividad/Actor/Responsabilidad Proceso Recepcin de Requerimientos.

173

Cervecera Polar C.A Territorio Oriente Sur Seleccin de Proveedores

Gerente de la Agencia

Coordinador DPV
Inicio

Proveedores

Revisar los formatos de solicitudes de Impulsos y/o Fachadas

Aprobar en conjunto la marca que se va a utilizar en la ejecucin del trabajo

SI

Tiene requerimientos de Impulsos y/o Fachadas?

NO

Estn de acuerdo?

NO

SI

Contactar a proveedores que ofrezca servicios de publicidad y promociones

Realizar la solicitud de presupuestos a los proveedores

Recibir la solicitud de presupuestos

Recibir cotizaciones por parte de los proveedores

Elaborar presupuesto del trabajo para enviar a la CDPV

Analizar las cotizaciones de los proveedores

Seleccionar los puntos de venta a ejecutar de acuerdo al presupuesto disponible

Asignar a un proveedor la ejecucin del trabajo

Fin

Diagrama 31. Diagrama de Actividad/Actor/Responsabilidad Proceso Seleccin de Proveedores. 174

Cervecera Polar C.A Territorio Oriente Sur Desarrollo de Impulsos y/o Fachadas

Proveedor
Inicio

Gerente de la Agencia

Coordinador DPV

Solicitar la ejecucion de Impulsos y/o Fachadas a los proveedores previamente seleccionados

Recibir las especificaciones del trabajo a realizar

Requiere de Material POP, Producto y/o Uniformes?

SI

La Agencia cuenta con el material requerido?

NO Enviar una solicitud a la Oficina Principal del Territorio

Recibir la solicitud en la Oficina Principal del Territorio

SI

Recibir el material en la Agencia

Enviar a la Agencia solicitante

NO Suministrar al proveedor previo a la ejecucin de la actividad

Proceder a la ejecucin

Generar reportes sobre la ejecucin de la actividad

Fin

Diagrama 32. Diagrama de Actividad/Actor/Responsabilidad Proceso Desarrollo de Impulsos y/o Fachadas.

175

Cervecera Polar C.A Territorio Oriente Sur Seguimiento de Impulsos y/o Fachadas

Supervisor comercial

Inicio

Supervisar la actividad realizada por el proveedor en el sitio

Revisar los reportes de inventario y reportes fotograficos

Validar el cumplimiento apegado a los standares establecidos por la CDPV

El Proveedor realizo trabajo cumpliendo requerimientos?

NO

Tomar acciones para ajustar el trabajo a los requerimientos

SI Aprobar la ejecucin del trabajo realizado

Fin

Diagrama 33. Diagrama de Actividad/Actor/Responsabilidad Seguimiento de Impulsos y/o Fachadas.

Proceso

176

Cervecera Polar C.A Territorio Oriente Sur

Procesamiento de Factura

Proveedor
Inicio

Gerente de la Agencia

Coordinador DPV

Enviar factura a la Agencia

Recibir factura en la Agencia

Recibir factura de ejecucin de Impulsos y/o Fachadas

Revisar factura de ejecucin de Impulsos y/o Fachadas

Aprobar factura de ejecucin de Impulsos y/o Fachadas

Aprobar factura de ejecucin de Impulsos y/o Fachadas

Enviar factura aprobadas de ejecucion de Impulsos y/o Fachadas al Departamento de Administracin para cancerlar

Enviar factura de ejecucin de Impulsos y/o Fachadas a la Oficina Principal del Territorio Fin

Diagrama 34. Diagrama Procesamiento de Factura.

de

Actividad/Actor/Responsabilidad

Proceso

6.2

Matriz Proceso/ Responsabilidad/ Actor En esta matriz son relacionadas las actividades de cada uno de los Procesos de

Negocio con los actores que las llevan a cabo, y se identifica la funcin de ejecucin en cada una de ellas; E: ejecutar. A continuacin se muestra la Matriz Proceso de Negocio/Actividad/Actor para la Coordinacin de Desarrollo en el Punto de Venta.

177

Cervecera Polar C.A Territorio Oriente Sur Cuadro 64. Matriz Proceso/ Responsabilidad/ Actor.
Actor Coordinador DPV E E E E E E E E E E E E E Proveedores

Proceso

Actividad

Identificacin del Punto

Recepcin de Requerimientos

Seleccin de Proveedores

Detectar oportunidades en el mercado Identificar las necesidades de la zona tanto para la solicitud de impulsos como para la ejecucin interna Realizar la notificacin con el cliente Realizar la negociacin con el cliente Analizar y estudiar la zona donde se encuentra el negocio Consolidar, verificar y analizar las necesidades de la Agencia Asignar un respectivo orden de prioridades Enviar a las agencias el presupuesto disponible por mes Totalizar las necesidades de la Agencia Elaborar formatos de las solicitudes de Impulsos y/o Fachadas a enviar Recibir en la Coordinacin Desarrollo en el Punto de Venta Recibir formatos de las solicitudes de Impulsos y/o Fachadas Aprobar en conjunto la marca que se va a utilizar en la ejecucin de la estrategia Contactar a los proveedores que ofrezcan servicios de publicidad y promociones Realizar la solicitud de presupuestos a los proveedores Recibir la solicitud de presupuestos Elaborar presupuestos del trabajo para enviar a la CDPV Recibir cotizaciones por parte de los proveedores Analizar cotizaciones de los proveedores

E E

E E E E E

178

Gerente de Agencia

Supervisor Comercial

Cervecera Polar C.A Territorio Oriente Sur Cuadro 64 (Cont.)

Seleccin de Proveedores Seleccionar los puntos de venta a ejecutar de acuerdo al presupuesto disponible Asignar a un proveedor la ejecucin del trabajo Solicitar la ejecucin de Impulsos y Fachadas a los proveedores previamente seleccionados Recibir las especificaciones del trabajo a realizar Enviar una solicitud de material a la Oficina Principal del Territorio Recibir una solicitud de material en la Oficina Principal del Territorio Enviar a la agencia solicitante Recibir en la Agencia solicitante Suministrar al proveedor previo a la ejecucin Proceder a la ejecucin Generar reportes sobre la actividad realizada Supervisar la actividad realizada por el proveedor en el sitio Revisar los reportes de inventario y los reportes fotogrficos Validar el cumplimiento apegado a los estndares de la CDPV Aprobar la ejecucin del trabajo realizado Tomar acciones para ajustar el trabajo a los requerimientos Enviar facturas a la Agencia Recibir facturas a la Agencia Revisar facturas de ejecucin de Impulsos y/o Fachadas Aprobar facturas de ejecucin de Impulsos y/o Fachadas Enviar facturas de ejecucin de Impulsos y/o Fachadas a la Oficina Principal del Territorio Revisar facturas de ejecucin de Impulsos y/o Fachadas Aprobar facturas de ejecucin de Impulsos y/o Fachadas Enviar facturas aprobadas de ejecucin de Impulsos y/o Fachadas al Departamento de Administracin para cancelar. E

E E

E E E E E E E E E E E E E E E E E E

Desarrollo de Impulsos y/o Fachadas

Seguimiento de Impulsos y/o Fachadas

Procesamiento de Factura

E E E

179

Cervecera Polar C.A Territorio Oriente Sur 7. Modelo de Eventos del Negocio Los Eventos del Negocio son hechos cuya ocurrencia dispara la ejecucin inmediata de un conjunto de acciones asociadas a los procesos del negocio. Esta ocurrencia puede causar alteraciones sobre los estados de los Objetos de Negocios como resultado de las acciones realizadas en ese instante; un evento puede provocar la ejecucin en secuencia o no de un conjunto de acciones en distintos procesos del negocio. Los Eventos del Negocio necesitan ser identificados y especificados de manera que pueda modelarse tanto sus causas o fuentes de origen como sus efectos o impactos en objetos y procesos del negocio. Los eventos pueden ser: planificados o no, internos originados dentro del mismo sistema o externos cuando provienen del contexto del sistema de negocios. 7.1 Enumeracin de Eventos A continuacin se citan los eventos que activan los diferentes Procesos de Negocio ejecutados por la Coordinacin de Desarrollo en el Punto de Venta. a) b) c) d) e) f) 7.2 Aplicacin de la estrategia en el punto de venta Asignar puntos de venta a proveedores Nueva campaa de mercadeo Procesar cancelacin de servicio Seleccin de punto de venta Supervisar la ejecucin de la estrategia Diagrama de Eventos Estos diagramas son realizados finalidad de mostrar de forma grfica, jerrquica y secuencial la relacin existente entre cada uno de los eventos enumerados en la seccin anterior y los Procesos de Negocio ejecutados por la

180

Cervecera Polar C.A Territorio Oriente Sur CDPV. Seguidamente se presentan los Diagramas de Eventos asociados a los procesos de la Coordinacin de Desarrollo en el Punto de Venta (ver Diagrama 35).

Nueva campaa de mercadeo

Identificacin del Punto PF-1

Solicitudes de los Supervisores Comerciales

Seleccin de Punto de Venta

Recepcin de Requerimientos PF-2.1

Solicitud de Impulsos y/o Fachadas

Asignar puntos de venta a proveedores

Seleccin de Proveedores PF-2.2

Puntos de venta asignados

Aplicacin de la estrategia en el punto de venta

Desarrollo de Impulsos y/o Fachadas PF-3.1

Punto de venta ejecutados

Supervisar la ejecucin de la estrategia

Seguimiento de Impulsos y/o Fachadas PF-3.2

Puntos de venta validados

Factura firmada Procesar cancelacin de servicio

Procesamiento de Factura PF-4

Cancelar factura

Diagrama 35. Diagrama de Eventos para la Coordinacin de Desarrollo en el Punto de Venta.

181

Cervecera Polar C.A Territorio Oriente Sur

7.3

Matriz Procesos vs Eventos Establece la relacin entre los eventos y los procesos representada en el punto

anterior, diagramas de eventos. A continuacin en el Cuadro 65 se muestra la matriz que relaciona los procesos con los eventos a travs de la letra A cuyo significado corresponde a Activa. Cuadro 65. Matriz Procesos vs Eventos.
Procesos de Negocio Seguimiento de Impulsos y/o Fachadas Desarrollo de Impulsos y/o Fachadas

Recepcin de requerimientos

Eventos Aplicacin de la estrategia en el punto de venta Asignar Puntos de Venta a proveedores Nueva campaa de mercadeo Procesar cancelacin de servicio Seleccin de Punto de Venta Supervisar la ejecucin de la estrategia

A A A A A A

8.

Integracin de los Submodelos Cada uno de los modelos elaborados para el Modelado de Procesos guardan

estrecha relacin entre s, los mismos en conjunto explican de manera clara y sintetizada las actividades de Identificacin del Punto, Recepcin de Requerimientos,

182

Procesamiento de Factura

Seleccin de proveedores

Identificacin del Punto

Cervecera Polar C.A Territorio Oriente Sur Seleccin de Proveedores, Desarrollo de Impulsos y Fachadas, Seguimiento de Impulsos y/o Fachadas y por ltimo Procesamiento de Factura. Por otro lado, los modelos desarrollados para el Modelado de Negocios estn vinculados unos con otros, haciendo posible la descripcin del funcionamiento de la Coordinacin de Desarrollo en el Punto de Venta. Los mismos detallan diversos aspectos o elementos del sistema de negocio como lo son sus: Objetivos, Procesos de Negocio Organizacionales, Objetos, Reglas, Actores y Eventos.

183

Descripcin del Modelado

Cadena de Valor

Diagrama de Jerarqua de Procesos

Diagrama de Actividades

Diagrama de Procesos

Figura 24. Integracin de los Modelos

Modelo de Objetos Modelo de Reglas Modelo de Actores

184
Diagrama de Objetos Diagrama de Clases Diagrama de Reglas Matriz Procesos/ Actividad / Actor Matriz Objetos vs Procesos

Modelo de Objetivos

Modelo de Eventos

Diagrama de Objetivos

Matriz Actor vs Responsabilidad

Diagrama de Eventos

Matriz Procesos vs Eventos

Cervecera Polar C.A Territorio Oriente Sur

Diagrama Actividad / Actor

Etapa III: Ingeniera de Requisitos

185

Cervecera Polar C.A Territorio Oriente Sur Ingeniera de requisitos para procesos de ejecucin de estrategias de mercadeo (Impulsos y Fachadas), Coordinacin de Desarrollo en el Punto de Venta Cervecera Polar C.A Territorio Comercial Oriente Sur. DOCUMENTO DE DEFINICIN DE REQUISITOS Versin 1.0 Autor Karinthia Sarabia Karinthia Sarabia Karinthia Sarabia 1. Introduccin Una vez elaborado el modelo del negocio, ya se tiene una comprensin suficiente del problema y del dominio donde operar el sistema. El siguiente proceso, denominado ingeniera de requisitos, consiste en analizar y documentar las necesidades funcionales que debern ser soportadas por el sistema; el presente documento contiene la definicin de los requisitos que deber satisfacer la aplicacin. Adems de identificar los requisitos de funcionalidad que se ajustan a las necesidades de los usuarios, se documentarn los requisitos no funcionales que definen las limitaciones que se le impondrn al diseo del sistema. El objetivo es presentar las necesidades de la Coordinacin de Desarrollo en el Punto de Venta y lo obtenido por medio de las entrevistas, teniendo adems como insumo de entrada el modelo del negocio. El alcance del documento es desarrollar el proceso de Descubrimiento y Anlisis de Requisitos correspondiente al anlisis general, chequeo y depuracin de la lista preliminar de los requisitos funcionales. Fecha 01/09/2010 07/11/2010 10/12/2010 Versin 0.90 0.91 1.0 Descripcin Versin preliminar como propuesta de desarrollo Correccin de la versin preliminar Versin final

186

Cervecera Polar C.A Territorio Oriente Sur 2. Descubrimiento de Requisitos Es el proceso mediante el cual los desarrolladores en conjunto con los usuarios identifican, revisan, articulan y entienden los requisitos del sistema y su objetivo es capturar las necesidades de los interesados que tienen relacin con la aplicacin. Este proceso implica entender: el sistema de negocios que ser servido por el sistema, los problemas de informacin que se quieren resolver y las necesidades de los usuarios finales. 2.1 Diagrama de Procesos de Requisitos

Insumos

Productos
Dominio Objetivos Procesos Reglas Actores Problemas Lista preliminar de los requisitos funcionales

Modelo de negocio de la Coordinacion Desarrollo en el Punto de Venta

Descubrimiento de requisitos

Diagrama 36. Diagrama de Procesos del "Descubrimiento de Requisitos. Como se muestra en la figura anterior el Descubrimiento de los Requisitos tiene como insumo de entrada el Modelo de Negocio de la Coordinacin de Desarrollo en el Punto de Venta y como productos de salida: dominio de jerarqua del sistema, los objetivos del negocio, procesos de negocios (cadena de valor general), las reglas de negocio, actores, problemas y las lista preliminar de los requisitos funcionales. 2.2 Jerarqua de Procesos Descubrimiento de Requisitos A continuacin se muestra el diagrama de jerarqua de procesos, donde se observan los subprocesos que se llevan a cabo en el proceso de descubrimiento de requisitos.

187

Cervecera Polar C.A Territorio Oriente Sur

<<Proceso>>

Ingeniera de requisitos

P-1 Descubrimiento de requisitos

P-2 Anlisis de requisitos

P-3 Especificacin de requisitos

<<Proceso>>

Ingeniera de requisitos

P-1.1 Establecimientos de objetivos

P-1.2 Entendimiento del dominio

P-1.3 Organizacin del conocimiento

P-1.4 Recoleccin de requisitos

Diagrama 37. Diagrama de Jerarqua de Procesos "Descubrimiento de Requisitos".

2.3

Objetivos de Requerimientos Los objetivos de la aplicacin vienen dados por los requerimientos de la

Coordinacin de Desarrollo en el Punto de Venta para operar de forma ptima y eficiente. A continuacin se presentan los objetivos que la aplicacin deber satisfacer: a) b) Automatizar la gestin de las estrategias de mercadeo Impulsos y Fachadas. Minimizar los tiempos de bsqueda referente a las inversiones realizadas

asociados a los procesos Impulsos y Fachadas. c) Proporcionar una herramienta que genere informacin eficaz, eficiente y

oportuna que facilite la toma de decisiones en la Coordinacin. d) Poseer una base de datos que sirva para el almacenamiento y respaldo de la

informacin generada en la ejecucin de los procesos Impulsos y Fachadas.

188

Cervecera Polar C.A Territorio Oriente Sur 2.4 Reglas del Negocio

Cuadro 66. Reglas del Negocio

Reglas del Cdigo Nombre Descripcin Fuente Variacin negocio relacionadas Slo se podrn

registrar en el sistema facturas emitidas por los RN-01 Proveedores de servicio proveedores que de se -

servicio

encuentren registrados en la cartera de de proveedores servicios organizacin. El sistema estar a de la

disponible sujeto al horario de trabajo de la empresa, tanto para Horario de trabajo la oficina principal del territorio como para las Agencias, -

RN-02

pudindose definir en el comprendido: horario Lun-

Sab (7 am 7 pm)

2.5

Descripcin de Actores En esta seccin se describen a todos aquellos actores que de alguna manera

interactan con el sistema. Ellos son los principales conductores proporcionando sus objetivos, necesidades o problemas para el proceso de generacin de requisitos. A su vez estn clasificados en actores directos e indirectos. Los actores directos son

189

Cervecera Polar C.A Territorio Oriente Sur aquellos que forman parte del sistema de negocio y desempean un rol en las actividades del negocio, ellos pueden representar una persona o una mquina. Los actores indirectos son aquellos que no forman parte del sistema de negocio, es decir, interactan con el sistema para satisfacer ciertas necesidades o proveer recursos. Los usuarios actores se identifican de la siguiente manera:

Cuadro 67. Primer Actor Actor-01

Coordinador Desarrollo en el Punto de Venta

Este actor es responsable de coordinar y supervisar los procesos ejecutados en la unidad.

Coordinador

Actor directo

Cuadro 68. Segundo Actor Actor-02

Gerente de Agencia

Este actor representa a la persona encargada de realizar las solicitudes de Impulsos y Fachadas con respecto a la
Gerente de Agencia

Agencia que gerencia, para luego ser enviados a la CDPV para ser procesados dichos requerimientos. Actor directo

Cuadro 69. Tercer Actor Actor-03

Analista Desarrollo en el Punto de Venta

Este actor representa a la persona encargada de llevar el control de las estrategias de Impulsos y Fachadas.
Analista DPV

Actor directo

190

Cervecera Polar C.A Territorio Oriente Sur

2.6

Actores del Sistema Existen un conjunto de usuarios que interactan con el sistema, estos usuarios

denominados segn UML (actores) pueden clasificarse segn sus funciones o responsabilidades que desempean dentro del mismo. Los actores que van a tener acceso al sistema sern los siguientes: Administrador: El departamento encargado de la administracin del sistema es el departamento de Sistemas. El administrador del sistema tiene el control total de la aplicacin y posee todos los privilegios existentes sobre el sistema en cuanto a datos de la misma como a la administracin de la base de datos y recursos manejados por sta. Sper-Usuario: (Coordinador de Desarrollo en el Punto de Venta). Este usuario tiene privilegios para asignar estatus a las solicitudes realizadas tanto para impulsos como para fachadas, adems de asignar proveedores a las solicitudes aprobadas asociando un punto de venta con proveedor que se encargara de ejecutar la estrategia de mercadeo y por ltimo realizar el registro de los puntos de venta ejecutados para as contar con un histrico de los puntos de venta a los cuales se les ha aplicado alguna de las estrategias: impulsos y/o fachadas. Usuario: (Gerentes de Agencia, Supervisor de Vinos y Derivados, Analista de Desarrollo en el Punto de Venta). Son usuarios con privilegios para realizar las solicitudes de Impulsos y/o Fachadas, visualizar el estatus de ests solicitudes desde su puesto de trabajo y en caso de requerir editar alguna de las solicitudes tambin podrn realizarlas.

191

Cervecera Polar C.A Territorio Oriente Sur 2.7 Recoleccin de Requerimientos Iniciales

Cuadro 70. Recoleccin de Requerimientos Iniciales

Cdigo Descripcin de requerimientos Realizar las solicitudes de Impulsos y Fachadas de manera automatizada. Conocer el estatus de las solicitudes de Impulsos y Fachadas Conocer la identificacin del usuario Registrar un punto de venta Modificar, consultar y eliminar un punto de venta Asignar un proveedor a una solicitud de Impulsos y/o Fachadas Generar reportes de todos los procesos. Existir un registro de todos los proveedores que prestan sus servicios. Actor Gerente de Agencia Maturn Gerente de Agencia Maturn Analista DPV Coordinador DPV Coordinador DPV Coordinador DPV Coordinador DPV Analista DPV Proceso de negocio PF-2.1 Regla del Negocio Medio

RI-01

En lnea

RI-02

PF-2.2

En lnea

RI-03 RI-04 RI-05

PF-1 PF-1

En lnea En lnea En lnea

RI-06 RI-07

PF-3.1 -

En lnea En lnea /. Impreso En lnea

RI-08

PF-2.2

192

Cervecera Polar C.A Territorio Oriente Sur 2.8 Planillas Volere

Cuadro 71. Planilla Volere

Identificador del requisito: Descripcin: Justificacin del requisito: Fuente (que interesado lo propone): Criterios de validacin: Grado de satisfaccin del interesado Dependencias (que requisitos dependen de este): Documentos de soporte: Proyecto: Grado de insatisfaccin del interesado Conflictos(que requisitos son incompatibles o inconsistente con este): Histrico de cambios: Analista: Unidad en la que se origina: Tipo de requisito: Caso de uso/Evento:

2.8.1

Requisitos Funcionales

Los requisitos funcionales determinan la funcionalidad del sistema es decir lo que

el sistema deber hacer involucrando todo lo referente a su comportamiento, su iteracin con los usuarios, su dominio de aplicacin (negocio), y respuesta a eventos.

Cuadro 72. Primer Requisito Funcional

Identificador del requisito: Tipo de requisito: Caso de uso/Evento: RF-01 Funcional Descripcin: El sistema debe validar el acceso de todos los usuarios del sistema. Justificacin del requisito: es necesario para restringir el acceso al sistema slo a personas autorizadas y a su vez muestra opciones del sistema de acuerdo al rol del usuario. Fuente: Unidad en la que se origina: Jaime Albornett Departamento de Sistemas Criterios de validacin: El sistema implementado se estar revisando peridicamente para evaluar si la aplicacin permite el acceso a la misma a personas que no se encuentren registradas o autorizadas. Grado de satisfaccin del interesado: 5 Grado de insatisfaccin del interesado: 1 Dependencias: 2, 5, 6, 7, 32, 34, 35, 36, 38, 40 Conflictos: No presenta Documentos de soporte: No definido Histrico de cambios:06/09/2010 Proyecto: Sistema para la gestin y control de Analista: Karinthia Sarabia las estrategias de mercadeo

193

Cervecera Polar C.A Territorio Oriente Sur Cuadro 73. Segundo Requisito Funcional
Identificador del requisito: Tipo de requisito: Caso de uso/Evento: RF-02 Funcional Descripcin: El administrador del sistema puede registrar nuevos usuarios al sistema. Justificacin del requisito: Restringe el registro de un nuevo usuario slo al administrador del sistema. Fuente: Unidad en la que se origina: Jaime Albornett Departamento de Sistemas Criterios de validacin: El sistema implementado se estar revisando peridicamente para evaluar si la aplicacin permite registrar nuevos usuarios. Grado de satisfaccin del interesado: 5 Grado de insatisfaccin del interesado: 1 Dependencias:1, 3, 4, 5, 33, 34, 38, 40, 41, Conflictos: No presenta Documentos de soporte: No definido Histrico de cambios: 06/09/2010 Proyecto: Sistema para la gestin y control de Analista: Karinthia Sarabia las estrategias de mercadeo

Cuadro 74. Tercer Requisito Funcional

Caso de uso/Evento: Identificador del requisito: Tipo de requisito: RF-03 Funcional Descripcin: El administrador del sistema puede modificar datos de cualquier usuario. Justificacin del requisito: Restringe la modificacin de datos de cualquier usuario slo al administrador del sistema. Fuente: Unidad en la que se origina: Jaime Albornett Departamento de Sistemas Criterios de validacin: El sistema implementado se estar revisando peridicamente para evaluar si la aplicacin permite la modificacin de datos del usuario. Grado de satisfaccin del interesado: 5 Grado de insatisfaccin del interesado: 1 Dependencias: 2,5, 33, 34, 38 Conflictos: No presenta Documentos de soporte: No definido Histrico de cambios: 06/09/2010 Proyecto: Sistema para la gestin y control de Analista: Karinthia Sarabia las estrategias de mercadeo

Cuadro 75. Cuarto Requisito Funcional

Caso de uso/Evento: Identificador del requisito: Tipo de requisito: RF-04 Funcional Descripcin: El administrador del sistema puede eliminar cualquier usuario registrado. Justificacin del requisito: Restringe la eliminacin de cualquier usuario slo al administrador del sistema. Fuente: Unidad en la que se origina: Jaime Albornett Departamento de Sistemas Criterios de validacin: El sistema implementado se estar revisando peridicamente para evaluar si la aplicacin permite eliminar usuarios registrados. Grado de satisfaccin del interesado: 5 Grado de insatisfaccin del interesado: 1 Dependencias: 2, 5, 38 Conflictos: No presenta Documentos de soporte: No definido Histrico de cambios: 06/09/2010 Proyecto: Sistema para la gestin y control de Analista: Karinthia Sarabia las estrategias de mercadeo

194

Cervecera Polar C.A Territorio Oriente Sur Cuadro 76. Quinto Requisito Funcional
Identificador del requisito: Tipo de requisito: Caso de uso/Evento: RF-05 Funcional Descripcin: El sistema permitir el control de acceso a contenidos. Justificacin del requisito: Es sumamente importante debido a que permite otorgarle permisos de acceso de acuerdo a los roles que tengan los usuarios. Fuente: Unidad en la que se origina: Jaime Albornett Departamento de Sistemas Criterios de validacin: El sistema implementado se estar revisando peridicamente para evaluar si la aplicacin permite el acceso de acuerdo al rol asignado a la persona que ingresa al sistema. Grado de satisfaccin del interesado: 5 Grado de insatisfaccin del interesado: 1 Dependencias: 1, 2, 3, 4, 6, 7, 12, 34, 36 Conflictos: No presenta Documentos de soporte: No definido Histrico de cambios: 06/09/2010 Proyecto: Sistema para la gestin y control de Analista: Karinthia Sarabia las estrategias de mercadeo

Cuadro 77. Sexto Requisito Funcional

Caso de uso/Evento: Identificador del requisito: Tipo de requisito: RF-06 Funcional Descripcin: Los usuarios deben poder abandonar el sistema en cualquier momento. Justificacin del requisito: El sistema debe permitir el abandono del mismo en cualquier momento para resguardar la seguridad del software. Fuente: Unidad en la que se origina: Jaime Albornett Departamento de Sistemas Criterios de validacin: El sistema implementado se estar revisando peridicamente para evaluar si la aplicacin permite salir del sistema en cualquier momento. Grado de satisfaccin del interesado: 5 Grado de insatisfaccin del interesado: 1 Dependencias: No presenta Conflictos: No presenta Documentos de soporte: No definido Histrico de cambios: 06/09/2010 Proyecto: Sistema para la gestin y control de Analista: Karinthia Sarabia las estrategias de mercadeo

Cuadro 78. Sptimo Requisito Funcional

Tipo de requisito: Caso de uso/Evento: Identificador del requisito: RF-07 Funcional Descripcin: El sistema despus de haber transcurrido cierto tiempo se cierra automticamente. Justificacin del requisito: resguarda la seguridad del sistema, luego de haber transcurrido cierto tiempo se cierra automticamente, es necesario ingresar su usuario y clave nuevamente para tener acceso al mismo. Fuente: Unidad en la que se origina: Jaime Albornett Departamento de Sistemas Criterios de validacin: El sistema implementado se estar revisando peridicamente para evaluar si la aplicacin se cierra automticamente despus de haber transcurrido cierto tiempo. Grado de satisfaccin del interesado: 5 Grado de insatisfaccin del interesado: 1 Dependencias: No presenta Conflicto: No presenta Documentos de soporte: No definido Histrico de cambios: 06/09/2010 Proyecto: Sistema para la gestin y control de Analista: Karinthia Sarabia las estrategias de mercadeo

195

Cervecera Polar C.A Territorio Oriente Sur

Cuadro 79. Octavo Requisito Funcional

Identificador del requisito: Tipo de requisito: Caso de uso/Evento: RF-08 Funcional Descripcin: El sistema debe permitir elaborar las solicitudes de Impulsos y/o Fachadas nuevas y/o recurrentes llenando la informacin requerida en los formularios. Justificacin del requisito: permitira a los Gerentes de las Agencias realizar las solicitudes de Impulsos y Fachadas de manera automatizada desde su puesto de trabajo. Fuente: Unidad en la que se origina: Anantonieta Morales (Coordinadora DPV) CDPV Criterios de validacin: El sistema implementado se estar revisando peridicamente para evaluar si la aplicacin permite realizar las solicitudes de Impulsos y Fachadas. Grado de satisfaccin del interesado: 5 Grado de insatisfaccin del interesado: 1 Dependencias: 09,10,11,29,39 Conflictos: No presenta Documentos de soporte: Procedimiento para la Histrico de cambios: 07/09/2010 ejecucin de Impulsos y Fachadas Proyecto: Sistema para la gestin y control de Analista: Karinthia Sarabia las estrategias de mercadeo

Cuadro 80. Noveno Requisito Funcional

Identificador del requisito: Tipo de requisito: Caso de uso/Evento: RF-09 Funcional Descripcin: El formato para realizar las solicitudes de Impulsos debe reflejar los siguientes campos: Agencia, Supervisor Comercial, Cliente, CEP, Cantidad de promotoras, motivo, marca, horario, material POP, uniformes, comentarios. Permitiendo adems guardar, enviar e imprimir los documentos. Justificacin del requisito: permitira a los Gerentes de las Agencias realizar las solicitudes de Impulsos y Fachadas de manera automatizada desde su puesto de trabajo. Fuente: Unidad en la que se origina: Anantonieta Morales (Coordinadora DPV) CDPV Criterios de validacin: El sistema implementado se estar revisando peridicamente para evaluar si la aplicacin cuenta con todos los campos necesarios para realizar las solicitudes de Impulsos. Grado de satisfaccin del interesado: 5 Grado de insatisfaccin del interesado: 2 Dependencias: 08 Conflictos: No presenta Documentos de soporte: Procedimiento para la Histrico de cambios: 07/09/2010 ejecucin de Impulsos y Fachadas Proyecto: Sistema para la gestin y control de Analista: Karinthia Sarabia las estrategias de mercadeo

196

Cervecera Polar C.A Territorio Oriente Sur Cuadro 81. Dcimo Requisito Funcional
Identificador del requisito: Tipo de requisito: Caso de uso/Evento: RF-10 Funcional Descripcin: El formato para realizar las solicitudes de Fachadas debe reflejar los siguientes campos: Agencia, Supervisor Comercial, Cliente, CEP, Direccin, Descripcin, marca, prioridad, especificaciones. Permitiendo adems guardar, enviar e imprimir los documentos Justificacin del requisito: permitira a los Gerentes de las Agencias realizar las solicitudes de Impulsos y Fachadas de manera automatizada desde su puesto de trabajo. Fuente: Unidad en la que se origina: Anantonieta Morales (Coordinadora DPV) CDPV Criterios de validacin: El sistema implementado se estar revisando peridicamente para evaluar si la aplicacin cuenta con todos los campos necesarios para realizar las solicitudes de Fachadas. Grado de satisfaccin del interesado: 5 Grado de insatisfaccin del interesado: 2 Dependencias: 08 Conflictos: No presenta Documentos de soporte: Procedimiento para la Histrico de cambios: 07/09/2010 ejecucin de Impulsos y Fachadas Proyecto: Sistema para la gestin y control de Analista: Karinthia Sarabia las estrategias de mercadeo

Cuadro 82. Dcimo Primer Requisito Funcional

Identificador del requisito: Tipo de requisito: Caso de uso/Evento: RF-11 Funcional Descripcin: El sistema debe permitir enviar las solicitudes de Impulsos y Fachadas a la CDPV. Justificacin del requisito: permite el acceso al Coordinador DPV a las solicitudes de Impulsos y Fachadas para continuar con el proceso de anlisis de dicha solicitud. Fuente: Unidad en la que se origina: Anantonieta Morales (Coordinadora DPV) CDPV Criterios de validacin: El sistema implementado se estar revisando peridicamente para evaluar si la aplicacin permitir enviar las solicitudes de Impulsos y Fachadas. Grado de satisfaccin del interesado: 4 Grado de insatisfaccin del interesado: 1 Dependencias: 08 Conflictos: No presenta Documentos de soporte: Procedimiento para la Histrico de cambios: 07/09/2010 ejecucin de Impulsos y Fachadas Proyecto: Sistema para la gestin y control de Analista: Karinthia Sarabia las estrategias de mercadeo

Cuadro 83. Dcimo Segundo Requisito Funcional

Identificador del requisito: Tipo de requisito: Caso de uso/Evento: RF-12 Funcional Descripcin: El sistema debe poseer un men principal con mdulos en los cuales se pueda realizar los procesos de la CDPV Justificacin del requisito: . Fuente: Unidad en la que se origina: Nimia Martnez (Analista DPV) CDPV Criterios de validacin: El sistema implementado se estar revisando peridicamente para evaluar si la aplicacin cuenta con los mdulos necesarios para realizar las funciones principales de la CDPV. Grado de satisfaccin del interesado: 4 Grado de insatisfaccin del interesado: 1 Dependencias: No presenta Conflictos: No presenta Documentos de soporte: No definido Histrico de cambios: 07/09/2010 Proyecto: Sistema para la gestin y control de Analista: Karinthia Sarabia las estrategias de mercadeo

197

Cervecera Polar C.A Territorio Oriente Sur Cuadro 84. Dcimo Tercer Requisito Funcional
Identificador del requisito: Tipo de requisito: Caso de uso/Evento: RF-13 Funcional Descripcin: El sistema debe permitir revisar la informacin recibida de las solicitudes de Impulsos y Fachadas para hacer observaciones en el caso de errores. Justificacin del requisito: permitira revisar las solicitudes de Impulsos y Fachadas para as determinar si cumple con los parmetros establecidos por la CDPV. Fuente: Unidad en la que se origina: Anantonieta Morales (Coordinadora DPV) CDPV Criterios de validacin: El sistema implementado se estar revisando peridicamente para evaluar si la aplicacin permite revisar la informacin recibida de las solicitudes de Impulsos y Fachadas. Grado de satisfaccin del interesado: 4 Grado de insatisfaccin del interesado: 1 Dependencias: 11 Conflictos: No presenta Documentos de soporte: Procedimiento para la Histrico de cambios: 07/09/2010 ejecucin de Impulsos y Fachadas Proyecto: Sistema para la gestin y control de Analista: Karinthia Sarabia las estrategias de mercadeo

Cuadro 85. Dcimo Cuarto Requisito Funcional

Tipo de requisito: Caso de uso/Evento: Identificador del requisito: RF-14 Funcional Descripcin: El sistema debe permitir devolver las solicitudes a la Agencia de procedencia en el caso que no cumpla con las especificaciones o lineamientos establecidos por la CDPV. Justificacin del requisito: permitira remitir las solicitudes para los procesos Impulsos y Fachadas. Fuente: Unidad en la que se origina: Anantonieta Morales (Coordinadora DPV) CDPV Criterios de validacin: El sistema implementado se estar revisando peridicamente para evaluar si la aplicacin permite devolver las solicitudes que no cumplan con las especificaciones. Grado de satisfaccin del interesado: 5 Grado de insatisfaccin del interesado: 1 Dependencias: 13 Conflictos: No presenta Documentos de soporte: No definido Histrico de cambios: 07/09/2010 Proyecto: Sistema para la gestin y control de Analista: Karinthia Sarabia las estrategias de mercadeo

Cuadro 86. Dcimo Quinto Requisito Funcional

Identificador del requisito: Tipo de requisito: Caso de uso/Evento: RF-15 Funcional Descripcin: El sistema debe permitir modificar la informacin llenada en los formularios sobre los requerimientos de las solicitudes cuando le sean devueltos. Justificacin del requisito: permitira a los usuarios editar los campos pertinentes para la completacin del formulario que presenta los procesos Impulsos y Fachadas Fuente: Unidad en la que se origina: Pablo Mora ( Gerente de Agencia Maturn) Agencia Maturn Cervecera Polar C.A Criterios de validacin: El sistema implementado se estar revisando peridicamente para evaluar si la aplicacin permite modificar campos de la informacin llenada en los formularios de las solicitudes de Impulsos y Fachadas. Grado de satisfaccin del interesado: 5 Grado de insatisfaccin del interesado: 1 Dependencias: 09,10 Conflictos: No presenta Documentos de soporte: No definido Histrico de cambios: 07/09/2010 Proyecto: Sistema para la gestin y control de Analista: Karinthia Sarabia las estrategias de mercadeo

198

Cervecera Polar C.A Territorio Oriente Sur

Cuadro 87. Dcimo Sexto Requisito Funcional

Identificador del requisito: Tipo de requisito: Caso de uso/Evento: RF-16 Funcional Descripcin: El sistema debe permitir consultar el estatus de las solicitudes de Impulsos y Fachadas. Justificacin del requisito: los usuarios podran conocer el estatus de las solicitudes tanto para los procesos Impulsos y Fachadas a travs del sistema. Fuente: Unidad en la que se origina: Pablo Mora ( Gerente de Agencia Maturn) Agencia Maturn Cervecera Polar C.A Criterios de validacin: El sistema implementado se estar revisando peridicamente para evaluar si la aplicacin permite consultar el estatus de una solicitud de Impulsos y Fachadas. Grado de satisfaccin del interesado: 5 Grado de insatisfaccin del interesado: 4 Dependencias: 08, 11, 29 Conflictos: No presenta Documentos de soporte: No definido Histrico de cambios: 08/09/2010 Proyecto: Sistema para la gestin y control de Analista: Karinthia Sarabia las estrategias de mercadeo

Cuadro 88. Dcimo Sptimo Requisito Funcional

Identificador del requisito: Tipo de requisito: Caso de uso/Evento: RF-17 Funcional Descripcin: El sistema debe mostrar un listado de las solicitudes de Impulsos y/o Fachadas Justificacin del requisito: Proporciona un listado general de las solicitudes de los procesos Impulsos y Fachadas Fuente: Unidad en la que se origina: Nimia Martnez (Analista DPV) CDPV Criterios de validacin: El sistema implementado se estar revisando peridicamente para evaluar si la aplicacin muestra un listado de las solicitudes. Grado de satisfaccin del interesado: 5 Grado de insatisfaccin del interesado: 1 Dependencias: 08,11 Conflictos: No presenta Documentos de soporte: No definido Histrico de cambios: 08/09/2010 Proyecto: Sistema para la gestin y control de Analista: Karinthia Sarabia las estrategias de mercadeo

Cuadro 89. Dcimo Octavo Requisito Funcional

Identificador del requisito: Tipo de requisito: Caso de uso/Evento: RF-18 Funcional Descripcin: El sistema debe permitir la impresin del listado general de las solicitudes tanto para el proceso de Impulsos como para el proceso de Fachadas Justificacin del requisito: Generar reportes fsicos con listado general de las solicitudes de los procesos Impulsos y Fachadas Fuente: Unidad en la que se origina: Nimia Martnez (Analista DPV) CDPV Criterios de validacin: El sistema implementado se estar revisando peridicamente para evaluar si la aplicacin permite imprimir generar reportes de las solicitudes de Impulsos y Fachadas. Grado de satisfaccin del interesado: 5 Grado de insatisfaccin del interesado: 1 Dependencias: 08,11 Conflictos: No presenta Documentos de soporte: No definido Histrico de cambios: 08/09/2010 Proyecto: Sistema para la gestin y control de Analista: Karinthia Sarabia las estrategias de mercadeo

199

Cervecera Polar C.A Territorio Oriente Sur Cuadro 90. Dcimo Noveno Requisito Funcional
Identificador del requisito: Tipo de requisito: Caso de uso/Evento: RF-19 Funcional Descripcin: El sistema debe permitir que el usuario pueda consultar en cualquier momento la informacin llenada de sus solicitudes antes de ser enviada a la Coordinacin modificarlo y consultar otro da para completar la informacin Justificacin del requisito: permitira a los Gerentes de las Agencias realizar cambios a las solicitudes de Impulsos y Fachadas de manera automatizada desde su puesto de trabajo. Fuente: Unidad en la que se origina: Pablo Mora ( Gerente de Agencia Maturn) Agencia Maturn Cervecera Polar C.A Criterios de validacin: El sistema implementado se estar revisando peridicamente para evaluar si la aplicacin permite consultar la informacin llenada en los formularios. Grado de satisfaccin del interesado: 4 Grado de insatisfaccin del interesado: 2 Dependencias: 08 Conflictos: No presenta Documentos de soporte: No definido Histrico de cambios: 08/09/2010 Proyecto: Sistema para la gestin y control de Analista: Karinthia Sarabia las estrategias de mercadeo

Cuadro 91. Vigsimo Requisito Funcional

Tipo de requisito: Caso de uso/Evento: Identificador del requisito: RF-20 Funcional Descripcin: El sistema debe permitir realizar un registro de puntos de venta. Justificacin del requisito: Contar un registro consolidado de todos los puntos de venta que maneja la CDPV Territorio Oriente Sur Fuente: Unidad en la que se origina: Anantonieta Morales (Coordinadora DPV) CDPV Criterios de validacin: El sistema implementado se estar revisando peridicamente para evaluar si la aplicacin permite registrar un punto de venta Grado de satisfaccin del interesado: 5 Grado de insatisfaccin del interesado: 1 Dependencias: No presenta Conflictos: No presenta Documentos de soporte: No definido Histrico de cambios: 08/09/2010 Proyecto: Sistema para la gestin y control de Analista: Karinthia Sarabia las estrategias de mercadeo

Cuadro 92. Vigsimo Primer Requisito Funcional

Identificador del requisito: Tipo de requisito: Caso de uso/Evento: RF-21 Funcional Descripcin: El sistema debe permitir modificar datos sobre puntos de venta previamente ingresados en el sistema. Justificacin del requisito: A travs de este requisito se permite la modificacin de los datos de algn punto de venta previamente ingresado al sistema. Fuente: Unidad en la que se origina: Anantonieta Morales (Coordinadora DPV) CDPV Criterios de validacin: El sistema implementado se estar revisando peridicamente para evaluar si la aplicacin permite modificar informacin de algn punto de venta. Grado de satisfaccin del interesado: 5 Grado de insatisfaccin del interesado: 1 Dependencias: 20 Conflictos: No presenta Documentos de soporte: No definido Histrico de cambios: 08/09/2010 Proyecto: Sistema para la gestin y control de Analista: Karinthia Sarabia las estrategias de mercadeo

200

Cervecera Polar C.A Territorio Oriente Sur

Cuadro 93. Vigsimo Segundo Requisito Funcional

Identificador del requisito: Tipo de requisito: Caso de uso/Evento: RF-22 Funcional Descripcin: El sistema debe permitir eliminar puntos de venta. Justificacin del requisito: Permite la eliminacin de un punto de venta del sistema. Fuente: Unidad en la que se origina: Anantonieta Morales (Coordinadora DPV) CDPV Criterios de validacin: El sistema implementado se estar revisando peridicamente para evaluar si la aplicacin permite eliminar un punto de venta del sistema. Grado de satisfaccin del interesado: 5 Grado de insatisfaccin del interesado: 1 Dependencias: 20 Conflictos: No presenta Documentos de soporte: No definido Histrico de cambios: 08/09/2010 Proyecto: Sistema para la gestin y control de Analista: Karinthia Sarabia las estrategias de mercadeo

Cuadro 94. Vigsimo Tercer Requisito Funcional

Identificador del requisito: Tipo de requisito: Caso de uso/Evento: RF-23 Funcional Descripcin: El sistema debe permitir listar todos los puntos de venta. Justificacin del requisito: Generar un listado de todos los puntos de venta Fuente: Unidad en la que se origina: Anantonieta Morales (Coordinadora DPV) CDPV Criterios de validacin: El sistema implementado se estar revisando peridicamente para evaluar si la aplicacin permite listar todos los puntos de venta. Grado de satisfaccin del interesado: 5 Grado de insatisfaccin del interesado: 1 Dependencias: 20 Conflictos: No presenta Documentos de soporte: No definido Histrico de cambios: 08/09/2010 Proyecto: Sistema para la gestin y control de Analista: Karinthia Sarabia las estrategias de mercadeo

Cuadro 95. Vigsimo Cuarto Requisito Funcional

Identificador del requisito: Tipo de requisito: Caso de uso/Evento: RF-24 Funcional Descripcin: El sistema debe permitir realizar el registro de proveedores. Justificacin del requisito: Contar con informacin detallada acerca de cada uno de los proveedores que prestan servicios tanto para los procesos de Impulsos como de Fachadas. Fuente: Unidad en la que se origina: Anantonieta Morales (Coordinadora DPV) CDPV Criterios de validacin: El sistema implementado se estar revisando peridicamente para evaluar si la aplicacin permite realizar registros de proveedores. Grado de satisfaccin del interesado: 5 Grado de insatisfaccin del interesado: 1 Dependencias: No presenta Conflictos: No presenta Documentos de soporte: No definido Histrico de cambios: 08/09/2010 Proyecto: Sistema para la gestin y control de Analista: Karinthia Sarabia las estrategias de mercadeo

201

Cervecera Polar C.A Territorio Oriente Sur Cuadro 96. Vigsimo Quinto Requisito Funcional
Identificador del requisito: Tipo de requisito: Caso de uso/Evento: RF-25 Funcional Descripcin: El sistema debe permitir modificar datos de un proveedor previamente ingresado en el sistema. Justificacin del requisito: Permite la modificacin de datos de algn proveedor. Fuente: Unidad en la que se origina: Anantonieta Morales (Coordinadora DPV) CDPV Criterios de validacin: El sistema implementado se estar revisando peridicamente para evaluar si la aplicacin permite modificar datos de algn proveedor previamente registrado. Grado de satisfaccin del interesado: 5 Grado de insatisfaccin del interesado: 1 Dependencias: 24 Conflictos: No presenta Documentos de soporte: No definido Histrico de cambios: 09/09/2010 Proyecto: Sistema para la gestin y control de Analista: Karinthia Sarabia las estrategias de mercadeo

Cuadro 97. Vigsimo Sexto Requisito Funcional

Tipo de requisito: Caso de uso/Evento: Identificador del requisito: RF-26 Funcional Descripcin: El sistema debe permitir eliminar un(os) proveedor (es). Justificacin del requisito: Permite eliminar un proveedor cuando este por alguna razn no vaya a continuar como proveedor de los procesos Impulsos y Fachadas Fuente: Unidad en la que se origina: Anantonieta Morales (Coordinadora DPV) CDPV Criterios de validacin: El sistema implementado se estar revisando peridicamente para evaluar si la aplicacin permite eliminar un proveedor. Grado de satisfaccin del interesado: 5 Grado de insatisfaccin del interesado: 1 Dependencias: 24 Conflictos: No presenta Documentos de soporte: No definido Histrico de cambios: 09/09/2010 Proyecto: Sistema para la gestin y control de Analista: Karinthia Sarabia las estrategias de mercadeo

Cuadro 98. Vigsimo Sptimo Requisito Funcional

Tipo de requisito: Caso de uso/Evento: Identificador del requisito: RF-27 Funcional Descripcin: El sistema debe permitir listar todos los proveedores. Justificacin del requisito: Permite visualizar todos los proveedores que prestan servicio a los procesos Impulsos y Fachadas. Fuente: Unidad en la que se origina: Anantonieta Morales (Coordinadora DPV) CDPV Criterios de validacin: El sistema implementado se estar revisando peridicamente para evaluar si la aplicacin permite listar todos los proveedores. Grado de satisfaccin del interesado: 5 Grado de insatisfaccin del interesado: 1 Dependencias: 24 Conflictos: No presenta Documentos de soporte: No definido Histrico de cambios: 09/09/2010 Proyecto: Sistema para la gestin y control de Analista: Karinthia Sarabia las estrategias de mercadeo

202

Cervecera Polar C.A Territorio Oriente Sur

Cuadro 99. Vigsimo Octavo Requisito Funcional

Identificador del requisito: Tipo de requisito: Caso de uso/Evento: RF-28 Funcional Descripcin: Los estatus de las solicitudes de Impulsos y Fachadas estarn definidos de la siguiente manera:Abierta, En Proceso, Aprobada, Rechazada. El Coordinador DPV es el encargado de asignar los estatus a dichas solicitudes. Justificacin del requisito: Los usuarios podran conocer el estatus de su solicitud a travs del sistema. Fuente: Unidad en la que se origina: Anantonieta Morales (Coordinadora DPV) CDPV Criterios de validacin: El sistema implementado se estar revisando peridicamente para evaluar si la aplicacin permite visualizar los estatus correspondientes a las solicitudes de Impulsos y Fachadas. Grado de satisfaccin del interesado: 5 Grado de insatisfaccin del interesado: 2 Dependencias: 08 Conflictos: No presenta Documentos de soporte: No definido Histrico de cambios: 09/09/2010 Proyecto: Sistema para la gestin y control de Analista: Karinthia Sarabia las estrategias de mercadeo

Cuadro 100. Vigsimo Noveno Requisito Funcional

Identificador del requisito: Tipo de requisito: Caso de uso/Evento: RF-29 Funcional Descripcin: Una vez enviadas las solicitudes de Impulsos y Fachadas a la CDPV, para la consulta de estatus de dichas solicitudes se mostraran en forma predeterminadas con estatus ABIERTA. Justificacin del requisito: Los procesos Impulsos y Fachadas requieren cumplir con una serie de pasos descritos con anterioridad en el Documento Modelo de Negocio, por lo cual mientras se lleva a cabo las diferentes etapas para estos procesos, se estableci definir automticamente por el sistema con estatus ABIERTA Fuente: Unidad en la que se origina: Anantonieta Morales (Coordinadora DPV) CDPV Criterios de validacin: El sistema implementado se estar revisando peridicamente para evaluar si la aplicacin muestra las solicitudes de manera predeterminada con el estatus ABIERTA. Grado de satisfaccin del interesado: 5 Grado de insatisfaccin del interesado: 1 Dependencias: 08 Conflictos: No presenta Documentos de soporte: No definido Histrico de cambios: 09/09/2010 Proyecto: Sistema para la gestin y control de Analista: Karinthia Sarabia las estrategias de mercadeo

203

Cervecera Polar C.A Territorio Oriente Sur Cuadro 101. Trigsimo Requisito Funcional
Identificador del requisito: Tipo de requisito: Caso de uso/Evento: RF-30 Funcional Descripcin: El Coordinador DPV pueda asociar una solicitud de Impulsos y/o Fachadas APROBADA a un proveedor encargado de llevar a cabo la ejecucin del proceso. Justificacin del requisito: Una vez que una solicitud de Impulsos y/o Fachadas ha sido APROBADA permitira asociar dicha solicitud con el proveedor a cargo. Fuente: Unidad en la que se origina: Anantonieta Morales (Coordinadora DPV) CDPV Criterios de validacin: El sistema implementado se estar revisando peridicamente para evaluar si la aplicacin permite el acceso a la misma a personas no se encuentren registradas o autorizadas. Grado de satisfaccin del interesado: 5 Grado de insatisfaccin del interesado: 1 Dependencias: 08, 24 ,27 Conflictos: No presenta Documentos de soporte: No definido Histrico de cambios: 09/09/2010 Proyecto: Sistema para la gestin y control de Analista: Karinthia Sarabia las estrategias de mercadeo

Cuadro 102.Trigsimo Primer Requisito Funcional

Tipo de requisito: Caso de uso/Evento: Identificador del requisito: RF-31 Funcional Descripcin: Mostrar un listado de las solicitudes de Impulsos y Fachadas APROBADAS. Justificacin del requisito: Visualizar las solicitudes de Impulsos y Fachadas que se encuentran APROBADAS conjuntamente con el proveedor asignado. Fuente: Unidad en la que se origina: Anantonieta Morales (Coordinadora DPV) CDPV Criterios de validacin: El sistema implementado se estar revisando peridicamente para evaluar si la aplicacin muestra un listado de las solicitudes de Impulsos y Fachadas. Grado de satisfaccin del interesado: 5 Grado de insatisfaccin del interesado: 1 Dependencias: 30 Conflictos: No presenta Documentos de soporte: No definido Histrico de cambios: 09/09/2010 Proyecto: Sistema para la gestin y control de Analista: Karinthia Sarabia las estrategias de mercadeo

Cuadro 103. Trigsimo Segundo Requisito Funcional

Identificador del requisito: Tipo de requisito: Caso de uso/Evento: RF-32 Funcional Descripcin: El sistema debe mostrar un mensaje de autenticacin fallida cada vez que el usuario y clave sean invlidos. Justificacin del requisito: Muestra al usuario un mensaje de error. Fuente: Unidad en la que se origina: Jaime Albornett Departamento de Sistemas Criterios de validacin: El sistema implementado se estar revisando peridicamente para evaluar si la aplicacin muestra un mensaje de autenticacin fallida cuando son errneos los datos introducidos. Grado de satisfaccin del interesado: 5 Grado de insatisfaccin del interesado: 1 Dependencias: 01 Conflictos: No presenta Documentos de soporte: No definido Histrico de cambios: 09/09/2010 Proyecto: Sistema para la gestin y control de Analista: Karinthia Sarabia las estrategias de mercadeo

204

Cervecera Polar C.A Territorio Oriente Sur Cuadro 104. Trigsimo Tercer Requisito Funcional
Identificador del requisito: Tipo de requisito: Caso de uso/Evento: RF-33 Funcional Descripcin: El sistema debe validar que no se puede ingresar un nuevo registro de usuario con el nombre de usuario o cdula ya registrado en el mismo. Justificacin del requisito: Los campos nombre de usuario y cdula son valores nicos. Fuente: Unidad en la que se origina: Jaime Albornett Departamento de Sistemas Criterios de validacin: El sistema implementado se estar revisando peridicamente para evaluar si la aplicacin verifica que los campos nombre de usuario o cdula sean campos nicos. Grado de satisfaccin del interesado: 5 Grado de insatisfaccin del interesado: 1 Dependencias: 41 Conflictos: No presenta Documentos de soporte: No definido Histrico de cambios: 09/09/2010 Proyecto: Sistema para la gestin y control de Analista: Karinthia Sarabia las estrategias de mercadeo

Cuadro 105. Trigsimo Cuarto Requisito Funcional

Tipo de requisito: Caso de uso/Evento: Identificador del requisito: RF-34 Funcional Descripcin: El sistema deber mostrar un men principal de acuerdo al nivel de acceso que tendr asignado el usuario. Justificacin del requisito: Muestra solamente las opciones permitidas de acuerdo al perfil del usuario que ha ingresado al sistema. Fuente: Unidad en la que se origina: Jaime Albornett Departamento de Sistemas Criterios de validacin: El sistema implementado se estar revisando peridicamente para evaluar si la aplicacin permite el acceso a la misma a personas no se encuentren registradas o autorizadas. Grado de satisfaccin del interesado: 5 Grado de insatisfaccin del interesado: 1 Dependencias: 01 Conflictos: No presenta Histrico de cambios: 09/09/2010 Documentos de soporte: Proyecto: Sistema para la gestin y control de Analista: Karinthia Sarabia las estrategias de mercadeo

Cuadro 106. Trigsimo Quinto Requisito Funcional

Identificador del requisito: Tipo de requisito: Caso de uso/Evento: RF-35 Funcional Descripcin: El sistema se bloquea despus de 3 intentos fallidos de acceso. Justificacin del requisito: Resguarda la seguridad del sistema. Fuente: Unidad en la que se origina: Jaime Albornett Departamento de Sistemas Criterios de validacin: El sistema implementado se estar revisando peridicamente para evaluar si la aplicacin se bloquea despus de 3 intentos fallidos de acceso. Grado de satisfaccin del interesado: 5 Grado de insatisfaccin del interesado: 1 Dependencias: 01, 32 Conflictos: No presenta Documentos de soporte: No definido Histrico de cambios: 09/09/2010 Proyecto: Sistema para la gestin y control de Analista: Karinthia Sarabia las estrategias de mercadeo

205

Cervecera Polar C.A Territorio Oriente Sur Cuadro 107. Trigsimo Sexto Requisito Funcional
Identificador del requisito: Tipo de requisito: Caso de uso/Evento: RF-36 Funcional Descripcin: El sistema debe poseer la opcin de cambiar clave. Justificacin del requisito: Proporciona a los usuarios finales mayor confiabilidad del sistema, ya que podrn cambiar su clave las veces que as lo desee. Fuente: Unidad en la que se origina: Jaime Albornett Departamento de Sistemas Criterios de validacin: El sistema implementado se estar revisando peridicamente para evaluar si la aplicacin permite cambiar la clave de cualquier usuario en todo momento. Grado de satisfaccin del interesado: 5 Grado de insatisfaccin del interesado: 1 Dependencias: 01 Conflictos: No presenta Histrico de cambios: 10/09/2010 Documentos de soporte: Proyecto: Sistema para la gestin y control de Analista: Karinthia Sarabia las estrategias de mercadeo

Cuadro 108. Trigsimo Sptimo Requisito Funcional

Tipo de requisito: Caso de uso/Evento: Identificador del requisito: RF-37 Funcional Descripcin: El sistema debe tener la opcin de imprimir y generar PDF para cada uno de los mens del mismo. Justificacin del requisito: Genera de forma fsica y en lnea los reportes de la informacin requerida. Fuente: Unidad en la que se origina: Anantonieta Morales (Coordinadora DPV) CDPV Criterios de validacin: El sistema implementado se estar revisando peridicamente para evaluar si la aplicacin genera documentos en formato PDF y permite su impresin. Grado de satisfaccin del interesado: 4 Grado de insatisfaccin del interesado: 2 Conflictos: No presenta Dependencias: Documentos de soporte: No definido Histrico de cambios: 10/09/2010 Proyecto: Sistema para la gestin y control de Analista: Karinthia Sarabia las estrategias de mercadeo

Cuadro 109. Trigsimo Octavo Requisito Funcional

Identificador del requisito: Tipo de requisito: Caso de uso/Evento: RF-38 Funcional Descripcin: El Sistema arrojara un mensaje cuando uno de los campos no sea completado o llenado correctamente Justificacin del requisito: Informa al usuario que debe completar las opciones faltantes. Fuente: Unidad en la que se origina: Jaime Albornett Departamento de Sistemas Criterios de validacin: El sistema implementado se estar revisando peridicamente para evaluar si la aplicacin informa al usuario cuando existan campos vacios que son obligatorios. Grado de satisfaccin del interesado: 5 Grado de insatisfaccin del interesado: 1 Dependencias: 01, 09,10,41 Conflictos: No presenta Documentos de soporte: No definido Histrico de cambios: 10/09/2010 Proyecto: Sistema para la gestin y control de Analista: Karinthia Sarabia las estrategias de mercadeo

206

Cervecera Polar C.A Territorio Oriente Sur Cuadro 110. Trigsimo Noveno Requisito Funcional
Identificador del requisito: Tipo de requisito: Caso de uso/Evento: RF-39 Funcional Descripcin: El sistema debe generar Cdigo de Dgitos Aleatorios nicos por cada Solicitud de Impulsos y/o Fachadas. Justificacin del requisito: Identifica cada solicitud realizada con un cdigo nico. Fuente: Unidad en la que se origina: Anantonieta Morales (Coordinadora DPV) CDPV Criterios de validacin: El sistema implementado se estar revisando peridicamente para evaluar si la aplicacin asigna un cdigo nico a cada solicitud realizada. Grado de satisfaccin del interesado: 4 Grado de insatisfaccin del interesado: 2 Dependencias: 08 Conflictos: No presenta Documentos de soporte: No definido Histrico de cambios: 10/09/2010 Proyecto: Sistema para la gestin y control de Analista: Karinthia Sarabia las estrategias de mercadeo

Cuadro 111. Cuadragsimo Requisito Funcional

Tipo de requisito: Caso de uso/Evento: Identificador del requisito: RF-40 Funcional Descripcin: El sistema debe tener un mdulo de Administrar Usuario, en el cual se puede registrar toda la informacin de los usuarios del sistema. Justificacin del requisito: Permite realizar el registro de los usuarios que harn uso del sistema. Fuente: Unidad en la que se origina: Jaime Albornett Departamento de Sistemas Criterios de validacin: El sistema implementado se estar revisando peridicamente para evaluar si la aplicacin cuenta con un mdulo Administrar Usuario. Grado de satisfaccin del interesado: 5 Grado de insatisfaccin del interesado: 1 Dependencias: No presenta Conflictos: No presenta Documentos de soporte: No definido Histrico de cambios: 10/09/2010 Proyecto: Sistema para la gestin y control de Analista: Karinthia Sarabia las estrategias de mercadeo

Cuadro 112. Cuadragsimo Primer Requisito Funcional

Tipo de requisito: Caso de uso/Evento: Identificador del requisito: RF-41 Funcional Descripcin: El mdulo Administrar Usuario debe contemplar los siguientes campos: Nombre, Apellido, Cedula, Cargo, Telfono, Correo, Rol, Usuario, Clave. Justificacin del requisito: Comprende los campos que deben completar para realizar el registro de un nuevo usuario. Fuente: Unidad en la que se origina: Jaime Albornett Departamento de Sistemas Criterios de validacin: El sistema implementado se estar revisando peridicamente para evaluar si la aplicacin cuenta con los campos anteriormente mencionados. Grado de satisfaccin del interesado: 5 Grado de insatisfaccin del interesado: 1 Dependencias: 40 Conflictos: No presenta Documentos de soporte: No definido Histrico de cambios: 10/09/2010 Proyecto: Sistema para la gestin y control de Analista: Karinthia Sarabia las estrategias de mercadeo

207

Cervecera Polar C.A Territorio Oriente Sur Cuadro 113. Cuadragsimo Segundo Requisito Funcional
Identificador del requisito: Tipo de requisito: Caso de uso/Evento: RF-42 Funcional Descripcin: Se requiere que el sistema pueda registrar ms de una solicitud a un mismo punto de venta. Justificacin del requisito: Los procesos Impulsos y Fachadas pueden ser requeridos en un mismo punto de venta, por lo tanto se permite realizar las solicitudes pertinentes. Fuente: Unidad en la que se origina: Anantonieta Morales (Coordinadora DPV) CDPV Criterios de validacin: El sistema implementado se estar revisando peridicamente para evaluar si la aplicacin permite realizar ms de una solicitud asociada a un mismo punto de venta. Grado de satisfaccin del interesado: 4 Grado de insatisfaccin del interesado: 1 Dependencias: 08 Conflictos: No presenta Documentos de soporte: No definido Histrico de cambios: 10/09/2010 Proyecto: Sistema para la gestin y control de Analista: Karinthia Sarabia las estrategias de mercadeo

Cuadro 114. Cuadragsimo Tercer Requisito Funcional

Tipo de requisito: Caso de uso/Evento: Identificador del requisito: RF-42 Funcional Descripcin: Se requiere que el sistema pueda asignar un mismo proveedor a distintos solicitudes a ser ejecutadas. Justificacin del requisito: Los proveedores estn encargados de llevar a cabo la ejecucin de los procesos Impulsos y Fachadas por lo tanto un proveedor puede asignarse para atender varias solicitudes aprobadas. Fuente: Unidad en la que se origina: Anantonieta Morales (Coordinadora DPV) CDPV Criterios de validacin: El sistema implementado se estar revisando peridicamente para evaluar si la aplicacin permite asignar a un proveedor varias solicitudes. Grado de satisfaccin del interesado: 5 Grado de insatisfaccin del interesado: 1 Dependencias: 30 Conflictos: No presenta Documentos de soporte: No definido Histrico de cambios: 10/09/2010 Proyecto: Sistema para la gestin y control de Analista: Karinthia Sarabia las estrategias de mercadeo

2.8.2

Requisitos No Funcionales

Los requisitos no funcionales hacen relacin a las caractersticas del sistema que aplican de manera general como un todo, ms que a rasgos particulares del mismo. Son adicionales a los requisitos funcionales que debe cumplir el sistema, y corresponden a aspectos tales como la arquitectura, la seguridad, el diseo, la implementacin y la plataforma hardware/software del sistema propuesto.

208

Cervecera Polar C.A Territorio Oriente Sur Cuadro 115. Primer Requisito No Funcional
Identificador del requisito: Tipo de requisito: Caso de uso/Evento: RNF-01 No Funcional Descripcin: El sistema debe ser diseado segn la arquitectura cliente/servidor. Justificacin del requisito: Presenta ventajas como escalabilidad, fcil mantenimiento, centralizacin del control adems que existen tecnologas que aseguran la seguridad en las transacciones, la amigabilidad de la interfaz y la facilidad de empleo. Fuente: Unidad en la que se origina: Karinthia Sarabia CDPV Criterios de validacin: No presenta Grado de satisfaccin del interesado: 5 Grado de insatisfaccin del interesado: 1 Dependencias: No presenta Conflictos: No presenta Documentos de soporte: No definido Histrico de cambios: 13/09/2010 Proyecto: Sistema para la gestin y control de Analista: Karinthia Sarabia las estrategias de mercadeo

Cuadro 116. Segundo Requisito No Funcional

Identificador del requisito: Tipo de requisito: Caso de uso/Evento: RNF-02 No Funcional Descripcin: La aplicacin deber ser independiente de la plataforma donde se despliegue. Justificacin del requisito: permite que el sistema se pueda implementar en distintos sistemas operativos. Fuente: Unidad en la que se origina: Karinthia Sarabia CDPV Criterios de validacin: No presenta Grado de satisfaccin del interesado: 5 Grado de insatisfaccin del interesado: 1 Dependencias: No presenta Conflictos: No presenta Documentos de soporte: No definido Histrico de cambios: 13/09/2010 Proyecto: Sistema para la gestin y control de Analista: Karinthia Sarabia las estrategias de mercadeo

Cuadro 117. Tercer Requisito No Funcional

Identificador del requisito: Tipo de requisito: Caso de uso/Evento: RNF-03 No Funcional Descripcin: El sistema deber tener interfaces grficas de administracin y de operacin en idioma espaol. Justificacin del requisito: Otorga todos los permisos del sistema al administrador del sistema y garantiza que ste sea desarrollado en idioma espaol. Fuente: Unidad en la que se origina: Karinthia Sarabia CDPV Criterios de validacin: No presenta Grado de satisfaccin del interesado: 5 Grado de insatisfaccin del interesado: 1 Dependencias: No presenta Conflictos: No presenta Documentos de soporte: No definido Histrico de cambios: 13/09/2010 Proyecto: Sistema para la gestin y control de Analista: Karinthia Sarabia las estrategias de mercadeo

209

Cervecera Polar C.A Territorio Oriente Sur Cuadro 118. Cuarto Requisito No Funcional
Identificador del requisito: Tipo de requisito: Caso de uso/Evento: RNF-04 No Funcional Descripcin: El sistema deber tener interfaz grfica sencilla y amigable, basada en mens, ventanas, listas despegables y botones de accin. Justificacin del requisito: con la finalidad que los usuarios se adapten rpidamente al sistema y as evitar la resistencia al cambio. Fuente: Unidad en la que se origina: Karinthia Sarabia CDPV Criterios de validacin: No presenta Grado de satisfaccin del interesado: 5 Grado de insatisfaccin del interesado: 1 Dependencias: No presenta Conflictos: No presenta Documentos de soporte: No definido Histrico de cambios: 13/09/2010 Proyecto: Sistema para la gestin y control de Analista: Karinthia Sarabia las estrategias de mercadeo

Cuadro 119. Quinto Requisito No Funcional

Tipo de requisito: Caso de uso/Evento: Identificador del requisito: RNF-05 No Funcional Descripcin: El sistema debe identificar en ventana activa el usuario que est haciendo uso de est. Justificacin del requisito: permite al usuario que esta haciendo uso del sistema verificar que ste lo identifico correctamente. Fuente: Unidad en la que se origina: Karinthia Sarabia CDPV Criterios de validacin: No presenta Grado de satisfaccin del interesado: 5 Grado de insatisfaccin del interesado: 1 Dependencias: No presenta Conflictos: No presenta Documentos de soporte: No definido Histrico de cambios: 13/09/2010 Proyecto: Sistema para la gestin y control de Analista: Karinthia Sarabia las estrategias de mercadeo

Cuadro 120. Sexto Requisito No Funcional

Tipo de requisito: Caso de uso/Evento: Identificador del requisito: RNF-06 No Funcional Descripcin: La conexin del sistema debe ser a travs del protocolo http://. Justificacin del requisito: El uso de campos de encabezados enviados en las transacciones HTTP le dan gran flexibilidad al protocolo. Estos campos permiten que se enve informacin descriptiva en la transaccin, permitiendo as la autenticacin, cifrado e identificacin de usuario. Fuente: Unidad en la que se origina: Karinthia Sarabia CDPV Criterios de validacin: No presenta Grado de satisfaccin del interesado: 5 Grado de insatisfaccin del interesado: 1 Dependencias: No presenta Conflictos: No presenta Documentos de soporte: No definido Histrico de cambios: 13/09/2010 Proyecto: Sistema para la gestin y control de Analista: Karinthia Sarabia las estrategias de mercadeo

210

Cervecera Polar C.A Territorio Oriente Sur Cuadro 121. Sptimo Requisito No Funcional
Identificador del requisito: Tipo de requisito: Caso de uso/Evento: RNF-07 No Funcional Descripcin: El acceso del sistema deber estar restringido por el uso de claves asignadas a cada uno de los usuarios. Slo podrn ingresar al Sistema las personas que estn registradas. Justificacin del requisito: Resguarda y restringe el acceso de usuarios al sistema, debido a que slo aquellos usuarios previamente registrados se le asignara un usuario y clave, la cual puede ser modificado por dicho usuario. Fuente: Unidad en la que se origina: Karinthia Sarabia CDPV Criterios de validacin: No presenta Grado de satisfaccin del interesado: 5 Grado de insatisfaccin del interesado: 1 Dependencias: No presenta Conflictos: No presenta Documentos de soporte: No definido Histrico de cambios: 13/09/2010 Proyecto: Sistema para la gestin y control de Analista: Karinthia Sarabia las estrategias de mercadeo

Cuadro 122. Octavo Requisito No Funcional

Tipo de requisito: Caso de uso/Evento: Identificador del requisito: RNF-08 No Funcional Descripcin: El sistema debe ser definido a travs de clases reutilizables (programacin orientada a objetos). Justificacin del requisito: Fuente: Unidad en la que se origina: Karinthia Sarabia CDPV Criterios de validacin: No presenta Grado de satisfaccin del interesado: 5 Grado de insatisfaccin del interesado: 1 Dependencias: No presenta Conflictos: No presenta Documentos de soporte: No definido Histrico de cambios: 13/09/2010 Proyecto: Sistema para la gestin y control de Analista: Karinthia Sarabia las estrategias de mercadeo

Cuadro 123. Noveno Requisito No Funcional

Tipo de requisito: Caso de uso/Evento: Identificador del requisito: RNF-09 No Funcional Descripcin: Cada usuario del sistema tendr asignado un determinado perfil, usado para activar servicios u opciones que ste perfil pueda realizar dentro del sistema. Justificacin del requisito: Asocia cada usuario con un rol o perfil para hacer uso el sistema. Fuente: Unidad en la que se origina: Karinthia Sarabia CDPV Criterios de validacin: No presenta Grado de satisfaccin del interesado: 5 Grado de insatisfaccin del interesado: 1 Dependencias: No presenta Conflictos: No presenta Documentos de soporte: No definido Histrico de cambios: 13/09/2010 Proyecto: Sistema para la gestin y control de Analista: Karinthia Sarabia las estrategias de mercadeo

211

Cervecera Polar C.A Territorio Oriente Sur Cuadro 124. Dcimo Requisito No Funcional
Identificador del requisito: Tipo de requisito: Caso de uso/Evento: RNF-10 No Funcional Descripcin: El sistema debe presentar mensajes de error que sean de fcil comprensin. Justificacin del requisito: Permite que cualquier usuario final comprenda dicho mensaje. Fuente: Unidad en la que se origina: Karinthia Sarabia CDPV Criterios de validacin: No presenta Grado de satisfaccin del interesado: 5 Grado de insatisfaccin del interesado: 1 Dependencias: No presenta Conflictos: No presenta Documentos de soporte: No definido Histrico de cambios: 13/09/2010 Proyecto: Sistema para la gestin y control de Analista: Karinthia Sarabia las estrategias de mercadeo

Cuadro 125. Dcimo Primer Requisito No Funcional

Tipo de requisito: Caso de uso/Evento: Identificador del requisito: RNF-11 No Funcional Descripcin: El sistema deber ser desarrollado bajo software libre, utilizando el lenguaje de programacin PHP y utilizar el estndar HTML, para el diseo de las pginas web del sistema. De esta forma se garantizara que el cdigo HTML generado pueda ser interpretado por cualquiera de los navegadores comerciales existentes en el mercado. Justificacin del requisito: Fuente: Unidad en la que se origina: Karinthia Sarabia CDPV Criterios de validacin: No presenta Grado de satisfaccin del interesado: 5 Grado de insatisfaccin del interesado: 1 Dependencias: No presenta Conflictos: No presenta Documentos de soporte: No definido Histrico de cambios: 14/09/2010 Proyecto: Sistema para la gestin y control de Analista: Karinthia Sarabia las estrategias de mercadeo

Cuadro 126. Dcimo Segundo Requisito No Funcional

Tipo de requisito: Caso de uso/Evento: Identificador del requisito: RFN-12 No Funcional Descripcin: El sistema debe tener rapidez y rendimiento de respuesta Justificacin del requisito: Fuente: Unidad en la que se origina: Karinthia Sarabia CDPV Criterios de validacin: No presenta Grado de satisfaccin del interesado: 5 Grado de insatisfaccin del interesado: 1 Dependencias: No presenta Conflictos: No presenta Documentos de soporte: No definido Histrico de cambios: 14/09/2010 Proyecto: Sistema para la gestin y control de Analista: Karinthia Sarabia las estrategias de mercadeo

212

Cervecera Polar C.A Territorio Oriente Sur Cuadro 127. Dcimo Tercer Requisito No Funcional
Identificador del requisito: Tipo de requisito: Caso de uso/Evento: RNF-13 No Funcional Descripcin: El sistema deber funcionar en un computador con un procesador Pentium IV, 1024 MG/ 1 GB de memoria RAM, 120/160 GB de disco duro Justificacin del requisito: son las especificaciones tcnicas para garantizar un ptimo funcionamiento del servidor donde se encontrara alojado el sistema. Fuente: Unidad en la que se origina: Karinthia Sarabia CDPV Criterios de validacin: No presenta Grado de satisfaccin del interesado: 5 Grado de insatisfaccin del interesado: 1 Dependencias: No presenta Conflictos: No presenta Documentos de soporte: No definido Histrico de cambios: 14/09/2010 Proyecto: Sistema para la gestin y control de Analista: Karinthia Sarabia las estrategias de mercadeo

Cuadro 128. Dcimo Cuarto Requisito No Funcional

Tipo de requisito: Caso de uso/Evento: Identificador del requisito: RNF-14 No Funcional Descripcin: El sistema podr visualizarse en un monitor de 14 pulgadas, con una resolucin ptima de 1024x768 Justificacin del requisito: son especificaciones tcnicas del monitor donde se visualizar el sistema. Fuente: Unidad en la que se origina: Karinthia Sarabia CDPV Criterios de validacin: No presenta Grado de satisfaccin del interesado: 5 Grado de insatisfaccin del interesado: 1 Dependencias: No presenta Conflictos: No presenta Documentos de soporte: No definido Histrico de cambios: 14/09/2010 Proyecto: Sistema para la gestin y control de Analista: Karinthia Sarabia las estrategias de mercadeo

Cuadro 129. Dcimo Quinto Requisito No Funcional

Tipo de requisito: Caso de uso/Evento: Identificador del requisito: RNF-15 No Funcional Descripcin: El sistema debe estar en capacidad de permitir en el futuro el desarrollo de nuevas funcionalidades posteriores a su construccin y puesta en marcha inicial. Justificacin del requisito: en caso que se realicen cambios en el sistema de negocio o surjan nuevos requisitos se podran realizar los cambios pertinentes o incorporar nuevas funcionalidades al sistema. Fuente: Unidad en la que se origina: Karinthia Sarabia CDPV Criterios de validacin: No presenta Grado de satisfaccin del interesado: 5 Grado de insatisfaccin del interesado: 1 Dependencias: No presenta Conflictos: No presenta Documentos de soporte: No definido Histrico de cambios: 14/09/2010 Proyecto: Sistema para la gestin y control de Analista: Karinthia Sarabia las estrategias de mercadeo

213

Cervecera Polar C.A Territorio Oriente Sur Cuadro 130. Dcimo Sexto Requisito No Funcional
Identificador del requisito: Tipo de requisito: Caso de uso/Evento: RNF-16 No Funcional Descripcin: El sistema debe captar la informacin a ser ingresada al sistema desde los dispositivos de entrada como por ejemplo: un teclado, mouse. Justificacin del requisito: permite que los usuarios interacten con el sistema mediante dispositivos de entrada como teclados. Fuente: Unidad en la que se origina: Karinthia Sarabia CDPV Criterios de validacin: No presenta Grado de satisfaccin del interesado: 5 Grado de insatisfaccin del interesado: 1 Dependencias: No presenta Conflictos: No presenta Documentos de soporte: No definido Histrico de cambios: 14/09/2010 Proyecto: Sistema para la gestin y control de Analista: Karinthia Sarabia las estrategias de mercadeo

Cuadro 131. Dcimo Sptimo Requisito No Funcional

Tipo de requisito: Caso de uso/Evento: Identificador del requisito: RNF-17 No Funcional Descripcin: El sistema debe hacer uso de dispositivos de salida como monitor, impresoras entre otros. Justificacin del requisito: permite la visualizacin tanto en lnea por medio del monitor y fsica a travs de la impresin de la informacin. Fuente: Unidad en la que se origina: Karinthia Sarabia CDPV Criterios de validacin: No presenta Grado de satisfaccin del interesado: 5 Grado de insatisfaccin del interesado: 1 Dependencias: No presenta Conflictos: No presenta Documentos de soporte: No definido Histrico de cambios: 14/09/2010 Proyecto: Sistema para la gestin y control de Analista: Karinthia Sarabia las estrategias de mercadeo

Cuadro 132. Dcimo Octavo Requisito No Funcional

Tipo de requisito: Caso de uso/Evento: Identificador del requisito: RNF-18 No Funcional Descripcin: Los resultados generados por el sistema se desplegarn a travs de la pantalla del computador. Justificacin del requisito: siendo as de fcil comprensin y visualizacin para los usuarios finales. Fuente: Unidad en la que se origina: Karinthia Sarabia CDPV Criterios de validacin: No presenta Grado de satisfaccin del interesado: 5 Grado de insatisfaccin del interesado: 1 Dependencias: No presenta Conflictos: No presenta Documentos de soporte: No definido Histrico de cambios: 14/09/2010 Proyecto: Sistema para la gestin y control de Analista: Karinthia Sarabia las estrategias de mercadeo

214

Cervecera Polar C.A Territorio Oriente Sur Cuadro 133. Dcimo Noveno Requisito No Funcional
Identificador del requisito: Tipo de requisito: Caso de uso/Evento: RNF-19 No Funcional Descripcin: Existencia de un Manual de Usuario para describir el funcionamiento y el uso del sistema al usuario final Justificacin del requisito: su importancia radica en que permite guiar a los usuarios finales para la utilizacin del sistema. Fuente: Unidad en la que se origina: Karinthia Sarabia CDPV Criterios de validacin: No presenta Grado de satisfaccin del interesado: 5 Grado de insatisfaccin del interesado: 1 Dependencias: No presenta Conflictos: No presenta Documentos de soporte: No definido Histrico de cambios: 14/09/2010 Proyecto: Sistema para la gestin y control de Analista: Karinthia Sarabia las estrategias de mercadeo

Cuadro 134. Vigsimo Requisito No Funcional

Identificador del requisito: Tipo de requisito: Caso de uso/Evento: RNF-20 No Funcional Descripcin: El sistema debe ser de fcil uso y entrenamiento por parte de los usuarios de la coordinacin y de las agencias, as como de fcil adaptacin de la entidad con el mismo. Justificacin del requisito: para contribuir a la adaptacin con el sistema por parte de los usuarios finales y minimizar la resistencia al cambio. Fuente: Unidad en la que se origina: Karinthia Sarabia CDPV Criterios de validacin: No presenta Grado de satisfaccin del interesado: 5 Grado de insatisfaccin del interesado: 1 Dependencias: No presenta Conflictos: No presenta Documentos de soporte: No definido Histrico de cambios: 14/09/2010 Proyecto: Sistema para la gestin y control de Analista: Karinthia Sarabia las estrategias de mercadeo

Cuadro 135. Vigsimo Primer Requisito No Funcional

Identificador del requisito: Tipo de requisito: Caso de uso/Evento: RNF-21 No Funcional Descripcin: Estar disponible 100%o muy cercano a sta disponibilidad durante el horario laboral de Cervecera Polar C.A (Ejemplo: Lunes a Sbado de 7:00 am a 7:00 pm). Justificacin del requisito: El sistema se encontrar en estado de espera a ser usado en cualquier momento por cualquier de los usuarios que se encuentran registrados en el mismo. Fuente: Unidad en la que se origina: Karinthia Sarabia CDPV Criterios de validacin: No presenta Grado de satisfaccin del interesado: 5 Grado de insatisfaccin del interesado: 1 Dependencias: No presenta Conflictos: No presenta Documentos de soporte: No definido Histrico de cambios: 15/09/2010 Proyecto: Sistema para la gestin y control de Analista: Karinthia Sarabia las estrategias de mercadeo

215

Cervecera Polar C.A Territorio Oriente Sur Cuadro 136. Vigsimo Segundo Requisito No Funcional
Identificador del requisito: Tipo de requisito: Caso de uso/Evento: RNF-22 No Funcional Descripcin: El sistema debe validar automticamente informacin como: obligatoriedad de campos, longitud de caracteres permitida por campo, manejo de tipos de datos, entre otros. Justificacin del requisito: contribuye notoriamente a minimizar los errores que comenten los usuarios finales. Fuente: Unidad en la que se origina: Karinthia Sarabia CDPV Criterios de validacin: No presenta Grado de satisfaccin del interesado: 5 Grado de insatisfaccin del interesado: 1 Dependencias: No presenta Conflictos: No presenta Documentos de soporte: No definido Histrico de cambios: 15/09/2010 Proyecto: Sistema para la gestin y control de Analista: Karinthia Sarabia las estrategias de mercadeo

Cuadro 137. Vigsimo Tercer Requisito No Funcional

Tipo de requisito: Caso de uso/Evento: Identificador del requisito: RNF-23 No Funcional Descripcin: Se debe emplear la plataforma XAMPP que contiene el servidor Apache el cual funcionar como el servidor donde se probar la funcionalidad del sistema. Justificacin del requisito: XAMPP es una aplicacin multiplataforma que permite montar un servidor web, por lo tanto se utilizar para montar el servidor que alojara el sistema. Fuente: Unidad en la que se origina: Karinthia Sarabia CDPV Criterios de validacin: No presenta Grado de satisfaccin del interesado: 5 Grado de insatisfaccin del interesado: 1 Dependencias: No presenta Conflictos: No presenta Documentos de soporte: No definido Histrico de cambios: 15/09/2010 Proyecto: Sistema para la gestin y control de Analista: Karinthia Sarabia las estrategias de mercadeo

Cuadro 138. Vigsimo Cuarto Requisito No Funcional

Tipo de requisito: Caso de uso/Evento: Identificador del requisito: RNF-24 No Funcional Descripcin: La organizacin, manipulacin, consulta y almacenamiento de los datos estarn bajo la responsabilidad del sistema manejador de base de datos relacional Sybase MySQL. Justificacin del requisito: se designa al sistema manejador de base de datos estas responsabilidades. Fuente: Unidad en la que se origina: Karinthia Sarabia CDPV Criterios de validacin: No presenta Grado de satisfaccin del interesado: 5 Grado de insatisfaccin del interesado: 1 Dependencias: No presenta Conflictos: No presenta Documentos de soporte: No definido Histrico de cambios: 15/09/2010 Proyecto: Sistema para la gestin y control de Analista: Karinthia Sarabia las estrategias de mercadeo

216

Cervecera Polar C.A Territorio Oriente Sur Cuadro 139. Vigsimo Quinto Requisito No Funcional
Identificador del requisito: Tipo de requisito: Caso de uso/Evento: RNF-25 No Funcional Descripcin: El sistema debe utilizar los servicios de la red interna de Cervecera Polar C.A para establecer comunicacin entre los clientes, el servidor web y manejador de base de datos. Justificacin del requisito: Fuente: Unidad en la que se origina: Karinthia Sarabia CDPV Criterios de validacin: No presenta Grado de satisfaccin del interesado: 5 Grado de insatisfaccin del interesado: 1 Dependencias: No presenta Conflictos: No presenta Documentos de soporte: No definido Histrico de cambios: 15/09/2010 Proyecto: Sistema para la gestin y control de Analista: Karinthia Sarabia las estrategias de mercadeo

Cuadro 140. Vigsimo Sexto Requisito No Funcional

Tipo de requisito: Caso de uso/Evento: Identificador del requisito: RNF-26 No Funcional Descripcin: El sistema debe ser capaz de almacenar consistentemente todos los datos. Esto incluye los usuarios registrados y la informacin relacionada con un registro de un usuario en el sistema. Justificacin del requisito: Fuente: Unidad en la que se origina: Karinthia Sarabia CDPV Criterios de validacin: No presenta Grado de satisfaccin del interesado: 5 Grado de insatisfaccin del interesado: 1 Dependencias: No presenta Conflictos: No presenta Documentos de soporte: No definido Histrico de cambios: 15/09/2010 Proyecto: Sistema para la gestin y control de Analista: Karinthia Sarabia las estrategias de mercadeo

Cuadro 141. Vigsimo Sptimo Requisito No Funcional

Identificador del requisito: Tipo de requisito: Caso de uso/Evento: RNF-27 No Funcional Descripcin: El sistema debe ser conservar la integridad de los datos almacenados en la base de datos. Justificacin del requisito: Fuente: Unidad en la que se origina: Karinthia Sarabia CDPV Criterios de validacin: No presenta Grado de satisfaccin del interesado: 5 Grado de insatisfaccin del interesado: 1 Dependencias: No presenta Conflictos: No presenta Documentos de soporte: No definido Histrico de cambios: 15/09/2010 Proyecto: Sistema para la gestin y control de Analista: Karinthia Sarabia las estrategias de mercadeo

217

Cervecera Polar C.A Territorio Oriente Sur Cuadro 142. Vigsimo Octavo Requisito No Funcional
Identificador del requisito: Tipo de requisito: Caso de uso/Evento: RNF-28 No Funcional Descripcin: El sistema debe tener los botones estndares de navegacin (imprimir, retornar, guardar, modificar, nuevo, buscar). Justificacin del requisito: son de fcil comprensin para los usuarios finales, asocian rpidamente las acciones que se pueden realizar con las figuras que muestran estos botones. Unidad en la que se origina: Fuente: Karinthia Sarabia CDPV Criterios de validacin: No presenta Grado de satisfaccin del interesado: 5 Grado de insatisfaccin del interesado: 1 Dependencias: No presenta Conflictos: No presenta Documentos de soporte: No definido Histrico de cambios: 15/09/2010 Proyecto: Sistema para la gestin y control de Analista: Karinthia Sarabia las estrategias de mercadeo

Cuadro 143. Vigsimo Noveno Requisito No Funcional

Tipo de requisito: Caso de uso/Evento: Identificador del requisito: RNF-29 No Funcional Descripcin: El sistema debe almacenar en forma perdurable toda la informacin ingresada. Justificacin del requisito: Fuente: Unidad en la que se origina: Karinthia Sarabia CDPV Criterios de validacin: No presenta Grado de satisfaccin del interesado: 5 Grado de insatisfaccin del interesado: 1 Dependencias: No presenta Conflictos: No presenta Documentos de soporte: No definido Histrico de cambios: 15/09/2010 Proyecto: Sistema para la gestin y control de Analista: Karinthia Sarabia las estrategias de mercadeo

218

Cervecera Polar C.A Territorio Oriente Sur 3. Anlisis de Requisitos El propsito principal de esta etapa es conseguir una comprensin ms precisa de los requisitos recolectados y una descripcin de los mismos que sea fcil de mantener y que ayude a estructurar el sistema completo, incluyendo la arquitectura. Para ello es necesario revisar los requisitos recolectados y determinar criterios de agrupamiento. 3.1 Diagrama de Procesos Una vez recolectados los requisitos funcionales preliminares, la siguiente fase del proceso de la Ingeniera de Requisitos consiste en analizar estos requisitos, por lo tanto el Anlisis de Requisitos es el proceso mediante el cual se razonan y analizan las necesidades identificadas de los clientes y usuarios para llegar a una definicin de los requisitos de software.

Insumos Productos Dominio Objetivos Procesos Reglas Actores Problemas Lista preliminar de los requisitos funcionales

Anlisis de requisitos

Documento de Definicin de Requisitos

Diagrama 38. Diagrama de Procesos del "Anlisis de Requisitos". Una vez que se tiene la lista preliminar de los requisitos funcionales se realizaron ciertas actividades para obtener los requisitos funcionales definitivos. Estas actividades fueron: a) b) Analizar los requisitos funcionales recolectados. Agrupar los requisitos funcionales recolectados y clasificarlos.

219

Cervecera Polar C.A Territorio Oriente Sur c) Determinar la clasificacin de aquellos requisitos funcionales que: no son

necesarios, son incompatibles entre si, no son completos, no son factibles o estn repetidos. 3.2 Jerarqua de Procesos Anlisis de Requisitos

<<Proceso>>

Ingeniera de requisitos

P-1 Descubrimiento de requisitos

P-2 Anlisis de requisitos

P-3 Especificacin de requisitos

<<Proceso>>

Ingeniera de requisitos

P-2.1 Clasificacin de requisitos

P-2.2 Negociacin de requisitos

P-2.3 Modelado del problema

P-2.4 Diseo inicial de la arquitectura

Diagrama 39. Diagrama de Jerarqua de Procesos "Anlisis de Requisitos". 3.3 Criterios de Agrupacin de los Requisitos Funcionales y Requisitos No

Funcionales Los requisitos funcionales determinan la funcionalidad del sistema es decir lo que el sistema deber hacer involucrando todo lo referente a su comportamiento su interaccin con los usuarios, su dominio de aplicacin (negocio), y respuesta a eventos. Los tipos de requisitos funcionales a utilizar para el sistema se especifican a continuacin:

220

Cervecera Polar C.A Territorio Oriente Sur

Se expresan desde la
Requisito dado por: Coordinacin de Desarrollo en el Punto de Venta.

Requisitos del Negocio

perspectiva de la empresa: describen por que la empresa o cliente sistema. desea desarrollar el

Contiene

tambin

objetivos, metas o necesidades que la empresa desea alcanzar con el uso del sistema. Se expresan del desde la
Requisito dado por: Personal de la CDPV

Requisitos del Usuario

perspectiva

Usuario:

describen las necesidades que los usuarios tienen y las tareas que los usuarios realizan con la aplicacin. Expresan lo que el usuario ser capaz de hacer con el sistema. Se expresan desde la

Requisitos del Sistema

perspectiva del sistema que contiene la aplicacin: son requisitos de alto nivel para productos que tienen

Requisito dado por: Coordinacin de Desarrollo en el Punto de Venta.

componentes de hardware y software. Se expresan desde la

Requisito dado por: Pasante Karinthia Sarabia.

Requisitos de Comportamiento

perspectiva del desarrollador: describen los servicios que el sistema presta a todos sus

usuarios directos. Expresa lo que hace el sistema bajo ciertos estmulos o eventos.

Los requisitos no funcionales especifican criterios que pueden usarse para juzgar la operacin de un sistema en lugar de sus comportamientos especficos, ya que stos corresponden a los requisitos funcionales. Por tanto, se refieren a todos los

221

Cervecera Polar C.A Territorio Oriente Sur requisitos que ni describen informacin a guardar, ni funciones a realizar. Los tipos de requisitos no funcionales a utilizar para el sistema, se especifican a continuacin:
Especifican el comportamiento

Requisitos del Producto

del producto. Ejemplos: rapidez de la ejecucin, capacidad de memoria, fiabilidad, etc. Derivan de polticas y

Requisito dado por: Desarrollador

Requisitos Organizacionales

procedimientos existentes en la organizacin del cliente y del desarrollador. Ejemplos:

Requisito dado por: Cervecera Polar C.A

Estndares de procesos, mtodos de diseo, lenguajes mtodos de de

programacin, entrega, etc.

Se derivan de factores externos

Requisitos Externos

al sistema y a sus procesos de desarrollo. Ejemplos: Requisitos de interoperatividad, legislativos, ticos, etc.

Requisito dado por: Personas que manipularan el sistema

222

3.4

Requisitos Funcionales El siguiente cuadro muestra la lista de los requisitos funcionales definitivos del sistema, despus del estudio, anlisis y

verificacin realizada. Cuadro 144. Requisitos Funcionales del Sistema

Cdigo RF-01 RF-02 RF-03 RF-04 RF-05 RF-06 RF-07 RF-08 Descripcin del Requisito El sistema debe validar el acceso de todos los usuarios del sistema. El administrador del sistema puede registrar nuevos usuarios al sistema. El administrador del sistema puede modificar datos de cualquier usuario. El administrador del sistema puede eliminar cualquier usuario registrado. El sistema permitir el control de acceso a contenidos. Los usuarios deben poder abandonar el sistema en cualquier momento. El sistema despus de haber transcurrido cierto tiempo se cierra automticamente. El sistema debe permitir elaborar las solicitudes de Impulsos y/o Fachadas nuevas y/o recurrentes llenando la informacin requerida en los formularios. El formato para realizar las solicitudes de Impulsos debe reflejar los siguientes campos: Agencia, Supervisor Comercial, Cliente, CEP, Cantidad de promotoras, motivo, marca, horario, material POP, uniformes, comentarios. Permitiendo adems guardar, enviar e imprimir los documentos. Usuario Todos los Usuarios Administrador Administrador Administrador Todos los Usuarios Todos los Usuarios Todos los Usuarios Todos los Usuarios Proceso del Negocio PF-2.1 Regla del Negocio Tipo de Requisito De Comportamiento De Comportamiento De Comportamiento De Comportamiento De Sistema De Comportamiento De Comportamiento De Comportamiento Medio En lnea En lnea En lnea En lnea En lnea En lnea En lnea En lnea

223

RF-09

Todos los Usuarios

PF-2.1

De Comportamiento

En lnea

Cuadro 144. (Cont.)

Cdigo Descripcin del Requisito El formato para realizar las solicitudes de Fachadas debe reflejar los siguientes campos: Agencia, Supervisor Comercial, Cliente, CEP, Direccin, Descripcin, marca, prioridad, especificaciones. Permitiendo adems guardar, enviar e imprimir los documentos El sistema debe permitir enviar las solicitudes de Impulsos y Fachadas a la CDPV. El sistema debe poseer un men principal con mdulos en los cuales se pueda realizar los procesos de la CDPV El sistema debe permitir revisar la informacin recibida de las solicitudes de Impulsos y Fachadas para hacer observaciones en el caso de errores. El sistema debe permitir devolver las solicitudes a la Agencia de procedencia en el caso que no cumpla con las especificaciones o lineamientos establecidos por la CDPV. El sistema debe permitir modificar la informacin llenada en los formularios sobre los requerimientos de las solicitudes cuando le sean devueltos. El sistema debe permitir consultar el estatus de las solicitudes de Impulsos y Fachadas. El sistema debe mostrar un listado de las solicitudes de Impulsos y/o Fachadas El sistema debe permitir la impresin del listado general de las solicitudes tanto para el proceso de Impulsos como para el proceso de Fachadas El sistema debe permitir que el usuario pueda consultar en cualquier momento la informacin llenada de sus solicitudes antes de ser enviada a la Coordinacin modificarlo y consultar otro da para completar la informacin Usuario Proceso del Negocio Regla del Negocio Tipo de Requisito Medio

RF-10

Todos los Usuarios Todos los Usuarios Todos los Usuarios Coordinador DPV Coordinador DPV Todos los Usuarios Todos los Usuarios Todos los Usuarios Coordinador DPV

PF-2.1

De Comportamiento De Comportamiento De Comportamiento De Comportamiento De Comportamiento De Comportamiento De Comportamiento De Comportamiento De Comportamiento

En lnea

RF-11 RF-12 RF-13

PF-2.1 PF-2.2

En lnea En lnea En lnea

RF-14

PF-2.2

En lnea

224
RF-15 RF-16 RF-17 RF-18 RF-19

PF-2.2 PF-2.2

En lnea En lnea En lnea En lnea

Todos los Usuarios

PF-2.1

De Comportamiento

En lnea

Cuadro 144. (Cont.)

Cdigo RF-20 RF-21 RF-22 RF-23 RF-24 RF-25 RF-26 RF-27 Descripcin del Requisito El sistema debe permitir realizar un registro de puntos de venta. El sistema debe permitir modificar datos sobre puntos de venta previamente ingresados en el sistema. El sistema debe permitir eliminar puntos de venta. El sistema debe permitir listar todos los puntos de venta. El sistema debe permitir realizar el registro de proveedores. El sistema debe permitir modificar datos de un proveedor previamente ingresado en el sistema. El sistema debe permitir eliminar un(os) proveedor (es). El sistema debe permitir listar todos los proveedores. Los estatus de las solicitudes de Impulsos y Fachadas estarn definidos de la siguiente manera:Abierta, En Proceso, Aprobada, Rechazada. El Coordinador DPV es el encargado de asignar los estatus a dichas solicitudes. Una vez enviadas las solicitudes de Impulsos y Fachadas a la CDPV, para la consulta de estatus de dichas solicitudes se mostraran en forma predeterminadas con estatus ABIERTA. El Coordinador DPV pueda asociar una solicitud de Impulsos y/o Fachadas APROBADA a un proveedor encargado de llevar a cabo la ejecucin del proceso. Mostrar un listado de las solicitudes de Impulsos y Fachadas APROBADAS. Usuario Todos los Usuarios Todos los Usuarios Coordinador DPV Todos los Usuarios Coordinador DPV Coordinador DPV Coordinador DPV Coordinador DPV Coordinador DPV Proceso del Negocio PF-1 PF-1 PF-1 PF-1 PF-2.2 PF-2.2 PF-2.2 PF-2.2 Regla del Negocio Tipo de Requisito De Comportamiento De Comportamiento De Comportamiento De Comportamiento De Comportamiento De Comportamiento De Comportamiento De Comportamiento De Comportamiento Medio En lnea En lnea En lnea En lnea En lnea En lnea En lnea En lnea

225

RF-28

PF-2.2

En lnea

RF-29

Todos los Usuarios Coordinador DPV Todos los Usuarios

PF-2.2

De Comportamiento De Comportamiento De Comportamiento

En lnea

RF-30 RF-31

PF-2.2 PF-2.2

En lnea En lnea

Cuadro 144. (Cont.)

Cdigo RF-32 RF-33 RF-34 RF-35 RF-36 RF-37 RF-38 Descripcin del Requisito El sistema debe mostrar un mensaje de autenticacin fallida cada vez que el usuario y clave sean invlidos. El sistema debe validar que no se puede ingresar un nuevo registro de usuario con el nombre de usuario o cdula ya registrado en el mismo. El sistema deber mostrar un men principal de acuerdo al nivel de acceso que tendr asignado el usuario. El sistema se bloquea despus de 3 intentos fallidos de acceso. El sistema debe poseer la opcin de cambiar clave. El sistema debe tener la opcin de imprimir y generar PDF para cada uno de los mens del mismo. El Sistema arrojara un mensaje cuando uno de los campos no sea completado o llenado correctamente El sistema debe generar Cdigo de Dgitos Aleatorios nicos por cada Solicitud de Impulsos y/o Fachadas. El sistema debe tener un mdulo de Administrar Usuario, en el cual se puede registrar toda la informacin de los usuarios del sistema. El mdulo Administrar Usuario debe contemplar los siguientes campos: Nombre, Apellido, Cedula, Cargo, Telfono, Correo, Rol, Usuario, Clave. Se requiere que el sistema pueda registrar ms de una solicitud a un mismo punto de venta. Usuario Todos los Usuarios Administrador Todos los Usuarios Todos los Usuarios Todos los Usuarios Todos los Usuarios Todos los Usuarios Todos los Usuarios Administrador Proceso del Negocio PF-2.1 Regla del Negocio Tipo de Requisito De Comportamiento De Comportamiento De Comportamiento De Sistema De Comportamiento De Comportamiento De Comportamiento De Comportamiento De Comportamiento De Comportamiento De Comportamiento Medio En lnea En lnea En lnea En lnea En lnea En lnea En lnea En lnea En lnea

226

RF-39 RF-40

RF-41 RF-42

Administrador Todos los Usuarios

PF-2.1

En lnea En lnea

3.5

Requisitos No Funcionales El siguiente cuadro muestra la lista de los requisitos funcionales definitivos del sistema, despus del estudio, anlisis y

verificacin realizada. Cuadro 145. Requisitos No Funcionales del Sistema

Cdigo RNF-01 RNF-02 RNF-03 Descripcin del Requisito El sistema debe ser diseado segn la arquitectura cliente/servidor. La aplicacin deber ser independiente de la plataforma donde se despliegue. El sistema deber tener interfaces grficas de administracin y de operacin en idioma espaol. El sistema deber tener interfaz grfica sencilla y amigable, basada en mens, ventanas, listas despegables y botones de accin El sistema debe identificar en ventana activa el usuario que est haciendo uso de est. La conexin del sistema debe ser a travs del protocolo http://. El acceso del sistema deber estar restringido por el uso de claves asignadas a cada uno de los usuarios. Slo podrn ingresar al Sistema las personas que estn registradas. El sistema debe ser definido a travs de clases reutilizables (programacin orientada a objetos). Cada usuario del sistema tendr asignado un determinado perfil, usado para activar servicios u opciones que ste perfil pueda realizar dentro del sistema. Usuario Desarrollador Desarrollador Todos los usuarios Desarrollador Desarrollador Desarrollador Todos los Usuarios Desarrollador Proceso del Negocio Regla del Negocio Tipo de Requisito De Producto De Producto Organizacional Organizacional Externo De Producto Medio En lnea En lnea En lnea En lnea En lnea

227

RNF-04 RNF-05 RNF-06

RNF-07

Externo

En lnea

RNF-08

Organizacional

En lnea

RNF-09

Desarrollador

Externo

En lnea

Cuadro 145. (Cont.)

Cdigo RNF-10 Descripcin del Requisito El sistema debe presentar mensajes de error que sean de fcil comprensin. El sistema deber ser desarrollado bajo software libre, utilizando el lenguaje de programacin PHP y utilizar el estndar HTML, para el diseo de las pginas web del sistema. De esta forma se garantizara que el cdigo HTML generado pueda ser interpretado por cualquiera de los navegadores comerciales existentes en el mercado. El sistema debe tener rapidez y rendimiento de respuesta El sistema deber funcionar en un computador con un procesador Pentium IV, 1024 MG/ 1 GB de memoria RAM, 120/160 GB de disco duro El sistema podr visualizarse en un monitor de 14 pulgadas, con una resolucin ptima de 1024x768 El sistema debe estar en capacidad de permitir en el futuro el desarrollo de nuevas funcionalidades posteriores a su construccin y puesta en marcha inicial. El sistema debe captar la informacin a ser ingresada al sistema desde los dispositivos de entrada como por ejemplo: un teclado, mouse. El sistema debe hacer uso de dispositivos de salida como monitor, impresoras entre otros. Los resultados generados por el sistema se desplegarn a travs de la pantalla del computador. Existencia de un Manual de Usuario para describir el funcionamiento y el uso del sistema al usuario final El sistema debe ser de fcil uso y entrenamiento por parte de los usuarios de la coordinacin y de las agencias, as como de fcil adaptacin de la entidad con el mismo. Usuario Desarrollador Proceso del Negocio Regla del Negocio Tipo de Requisito Organizacional Medio En lnea

RNF-11

Desarrollador

Organizacional

RNF-12 RNF-13 RNF-14

Desarrollador Desarrollador Desarrollador Desarrollador

De Producto De Producto De Producto Organizacional

En lnea En lnea

228

RNF-15

RNF-16 RNF-17 RNF-18 RNF-19

Desarrollador Desarrollador Desarrollador Desarrollador

Organizacional Organizacional Externo Externo

En lnea En lnea En lnea En lnea

RNF-20

Desarrollador

De Producto

En lnea

Cuadro 145. (Cont.)

Cdigo Descripcin del Requisito Estar disponible 100% o muy cercano a sta disponibilidad durante el horario laboral de Cervecera Polar C.A (Ejemplo: Lunes a Sbado de 7:00 am a 7:00 pm). El sistema debe validar automticamente informacin como: obligatoriedad de campos, longitud de caracteres permitida por campo, manejo de tipos de datos, entre otros. Se debe emplear la plataforma XAMPP que contiene el servidor Apache el cual funcionar como el servidor donde se probar la funcionalidad del sistema. La organizacin, manipulacin, consulta y almacenamiento de los datos estarn bajo la responsabilidad del sistema manejador de base de datos relacional Sybase MySQL El sistema debe utilizar los servicios de la red interna de Cervecera Polar C.A para establecer comunicacin entre los clientes, el servidor web y manejador de base de datos. El sistema debe ser capaz de almacenar consistentemente todos los datos. Esto incluye los usuarios registrados y la informacin relacionada con un registro de un usuario en el sistema. El sistema debe ser conservar la integridad de los datos almacenados en la base de datos. El sistema debe tener los botones estndares de navegacin (imprimir, retornar, guardar, modificar, nuevo, buscar). El sistema debe almacenar en forma perdurable toda la informacin ingresada Usuario Proceso del Negocio Regla del Negocio Tipo de Requisito Organizacional Medio

RNF-21

Desarrollador

En lnea

RNF-22

Desarrollador

De producto

En lnea

RNF-23

Desarrollador

Organizacional

En lnea

RNF-24

Desarrollador

Organizacional

229
RNF-25 RNF-26 RNF-27 RNF-28 RNF-29

Desarrollador

Organizacional

Desarrollador

Organizacional

En lnea

Desarrollador Desarrollador Desarrollador

Organizacional Externo Organizacional

En lnea En lnea En lnea

Cervecera Polar C.A Territorio Oriente Sur 3.6 Atributos de Calidad La calidad del software es el grado con el que un sistema, componente o proceso cumple los requerimientos especificados y las necesidades o expectativas del cliente o usuario. (IEEE, Std. 610-1990). La calidad del software debe evaluarse usando un modelo de calidad que tiene en cuenta criterios para satisfacer las necesidades de los desarrolladores, mantenedores, adquisidores y usuarios finales. Para efectos de este estudio se tom como marco de referencia el modelo de calidad ISO/IEC 9126 (Internacional Standard Information technology Software Product Quality), es un estndar internacional, el cual est pensado para los desarrolladores, quienes son los responsables de especificar y evaluar la calidad del software. Por tanto, puede servir para validar la completitud de una definicin de requisitos, identificar requisitos de calidad de software, objetivos de diseo y prueba, criterios de aseguramiento de la calidad, etc. Se han desarrollado varios modelos de calidad para diferentes productos y procesos software. Despus de haber analizado varios de ellos (los factores de calidad de McCall y aquellos propuestos por Hewlett- Packard FURPS: Funcionality, Usability, Reliability; Performance, Supportability), se puede afirmar que la mayor parte estn basados en la norma ISO 9126-1. Este modelo estructura los atributos de calidad de software en seis caractersticas (funcionalidad, fiabilidad, usabilidad, eficiencia, mantenibilidad y transportabilidad), que se subdividida en

subcaractersticas. Las subcaractersticas pueden ser medidas por mtricas internas. El objetivo no es necesariamente alcanzar una calidad perfecta, sino la necesaria y suficiente para cada contexto de uso a la hora de la entrega y del uso por parte de los usuarios.

230

Cervecera Polar C.A Territorio Oriente Sur Mtricas Internas de la Calidad del Producto de Software Segn la Norma ISO-9126-3. La calidad de los requisitos debe expresarse de manera cuantitativa con el uso de mtricas que faciliten la verificacin. Es por esto que todos los atributos definidos por la norma 9126-1 sern medidos con el uso de las mtricas internas ISO-9126-3, se tom como referencia estas mtricas por las siguientes razones: a) b) c) d) Se aplican a un producto de software no ejecutable. Se aplican durante las etapas de su desarrollo. Permiten medir la calidad de los entregables intermedios. Permiten predecir la calidad del producto final. La norma ISO-9126-3 contiene 6 mtricas para calcular la calidad del software, estas mtricas se presentan a continuacin con sus atributos: Mtricas de Funcionalidad: Permiten calificar si el software maneja en forma adecuada el conjunto de funciones que satisfagan las necesidades para las cuales fue diseado. Caractersticas: 1. Adecuidad: Capacidad del producto software para proporcionar un conjunto de

funciones apropiadas para efectuar las tareas y objetivos de usuario especificados. 2. Exactitud: Permite evaluar si el software presenta resultados o efectos acordes

a las necesidades. 3. Interoperabilidad: Permite evaluar la habilidad del software de interactuar con

otros sistemas previamente especificados. 4. Seguridad: Capacidad del producto software para proteger informacin y datos

de manera que las personas o sistemas no autorizados no puedan leerlos o

231

Cervecera Polar C.A Territorio Oriente Sur modificarlos, al tiempo que no se deniega el acceso a las personas o sistemas autorizados. 5. Conformidad: Evala si el software se adhiere a estndares, convenciones o

regulaciones en leyes y prescripciones similares. En el presente proyecto es necesario medir las caractersticas de Adecuidad y Seguridad, a continuacin se muestran las frmulas apropiadas para tal fin: Cuadro 146. Adecuidad ADECUIDAD Propsito Frmula Se mide esta caracterstica para garantizar al usuario que el sistema cumple con la totalidad de tareas necesarias. X = 1 - A/B A = nmero de funciones faltantes B = nmero de funciones descritas en la especificacin de requisitos. 0 <= X <= 1 Entre ms cercano a uno, ms completa. SEGURIDAD Propsito Frmula Detalles de la frmula Se mide esta caracterstica para garantizar al usuario que el sistema protege de forma slida los datos. [1-AMENAZA X (1-SEGURIDAD)] AMENAZA=probabilidad de que un cierto tipo de amenaza ocurra en un tiempo. SEGURIDAD=probabilidad de que se pueda contrarrestar un cierto tipo de ataque.

Detalles de la frmula

Cuadro 147. Seguridad

Mtricas de Confiabilidad: Conjunto de atributos que se refieren a la capacidad del software de mantener su nivel de ejecucin bajo condiciones normales en un periodo de tiempo establecido. Caractersticas: 1. Madurez: Capacidad del producto software para medir la frecuencia de falla

por errores en el software.

232

Cervecera Polar C.A Territorio Oriente Sur

2.

Tolerancia a fallos: Se refiere a la habilidad de mantener un nivel especfico de

funcionamiento en caso de fallas del software o de cometer infracciones de su interfaz especfica. 3. Recuperacin: Se refiere a la capacidad de restablecer el nivel de operacin y

recobrar los datos que hayan sido afectados directamente por una falla, as como al tiempo y el esfuerzo necesarios para lograrlo. En el presente proyecto es necesario medir las caractersticas de Madurez, Tolerancia a fallos y Recuperacin a continuacin se muestran las frmulas apropiadas para tal fin: Cuadro 148. Madurez MADUREZ Propsito Frmula Detalles de la frmula Se mide esta caracterstica para garantizar al usuario que el sistema esta creado para obtener un nivel de respuesta alto ante fallas durante el uso del mismo. X = A/B A = nmero de casos de pruebas en el plan B = nmero de casos de pruebas requeridos. 0 <= X Entre X sea mayor, mejor la suficiencia.

Cuadro 149. Tolerancia a fallos TOLERANCIA A FALLOS Propsito Frmula Se mide esta caracterstica para garantizar al usuario que el sistema brinda un nivel alto de servicio, en caso de fallas. ANULACION DE FALLAS SERIAS X=A/B 0 <= X <= 1 el ms cercano a 1.0 es el mejor A=numero de fallas serias anuladas contra los casos de prueba del modelo de errores que casi causa la falla B=numero de casos de pruebas ejecutadas del modelo de errores que casi causa la falla durante la prueba

Detalles de la frmula

233

Cervecera Polar C.A Territorio Oriente Sur Cuadro 150. Recuperacin RECUPERACIN Propsito Se mide esta caracterstica para garantizar al usuario que el sistema es capaz de continuar realizando lo que est en proceso en caso de algn inconveniente externo. TIEMPO DE RECUPERACION(1) Tiempo medio= X = suma=(T)/B TIEMPO ESTIMADO DE REINICIO(2) Promedio =X=A/B (1) 0 <X el menor es el mejor T=tiempo para recuperar bajas del sistema software en cada oportunidad B=numero de veces que el software observado entro en proceso de recuperacin (2) 0 <= X el mayor y mas cercano a 1.0 es el mejor A=Un ero de oportunidades de reinicio que se dieron en el tiempo estimado. B=Nmero total de oportunidades de reinicio durante las pruebas o el apoyo al funcionamiento al usuario

Frmula

Detalles de la frmula

Mtricas de Usabilidad: Consiste de un conjunto de atributos que permiten evaluar el esfuerzo necesario que deber invertir el usuario para utilizar el sistema. Caractersticas: 1. Entendibilidad: Capacidad del producto software que permite al usuario

entender si el software es adecuado y cmo puede ser usado para unas tareas o condiciones de uso particulares. 2. Facilidad de Aprender: Establece atributos del software relativos al esfuerzo

que los usuarios deben hacer para aprender a usar la aplicacin. 3. Operabilidad: Agrupa los conceptos que evalan la operacin y el control del

sistema. 4. 5. Atractivo: Capacidad del producto software para ser atractivo al usuario. Conformidad de la usabilidad: Capacidad del producto software para

adherirse a normas, convenciones, guas de estilo o regulaciones relacionadas con la usabilidad.

234

Cervecera Polar C.A Territorio Oriente Sur En el presente proyecto es necesario medir las caractersticas de Entendibilidad y Operabilidad, a continuacin se muestran las frmulas apropiadas para tal fin: Cuadro 151. Entendibilidad ENTENDIBILIDAD Propsito Frmula Se mide esta caracterstica para garantizar al usuario que el sistema cumple un determinado nmero de tareas adecuadas. X = A/B X = A/B A = nmero de funciones (o tipos de funciones) evidentes al usuario B = total de funciones (o tipos de funciones) 0 <= X <= 1 Entre ms cercano a 1, mejor OPERABILIDAD Propsito Frmula Detalles de la frmula Se mide esta caracterstica para garantizar al usuario que el sistema le permite realizar completamente sus tareas. xito=(n de tareas terminadas+(n medias 0.5))100/n total de tareas Tarea terminada tiene peso 1,tarea a medio terminar 0.5 y tarea no terminada 0

Detalles de la frmula

Cuadro 152. Operabilidad

Mtricas de Eficiencia: Capacidad del producto permite evaluar la relacin entre el nivel de funcionamiento del software y la cantidad de recursos usados. Caractersticas: 1. Comportamiento en el tiempo: Capacidad del producto software para

proporcionar tiempos de respuesta, tiempos de proceso y potencia apropiados, bajo condiciones determinadas. 2. Utilizacin de recursos: Capacidad del producto software para usar las

cantidades y tipos de recursos adecuados cuando el software lleva a cabo su funcin bajo condiciones determinadas.

235

Cervecera Polar C.A Territorio Oriente Sur 3. Conformidad de la eficiencia: Capacidad del producto software para adherirse

a normas o convenciones relacionadas con la eficiencia. En el presente proyecto es necesario medir la caracterstica de Comportamiento en el tiempo, a continuacin se muestran la frmula apropiada para tal fin: Cuadro 153. Comportamiento en el tiempo COMPORTAMIENTO EN EL TIEMPO Propsito Frmula Detalles de la frmula Se mide esta caracterstica para determinar cul es el tiempo estimado para completar una tarea X = tiempo (calculado o simulado) Entre ms corto, mejor

Mtricas de Mantenibilidad: Capacidad del producto software para ser modificado. Caractersticas: 1. Analizabilidad: Relativo al esfuerzo necesario para diagnosticar las

deficiencias o causas de fallas, o para identificar las partes que debern ser modificadas. 2. Cambiabilidad: Mide el esfuerzo necesario para modificar aspectos del

software, remover fallas o adaptar el software para que funcione en un ambiente diferente. 3. Estabilidad: Permite evaluar los riesgos de efectos inesperados debidos a las

modificaciones realizadas al software. 4. Examinabilidad: Se refiere al esfuerzo necesario para validar el software una

vez que fue modificado. En el presente proyecto es necesario medir las caractersticas de Analizabilidad, Cambiabilidad y Estabilidad, a continuacin se muestran las frmulas apropiadas para tal fin:

236

Cervecera Polar C.A Territorio Oriente Sur Cuadro 154. Analizibilidad ANALIZIBILIDAD Propsito Frmula Se mide esta caracterstica para garantizar al usuario que el sistema puede o no ser modificado en algn proceso. Tiempo medio en analizar un fallo: X = sum(Tout-Tin) / N siendo Tout = momento en el que se encuentran las causas del fallo (o son reportadas por el usuario) Tin = momento en el que se recibe el informe del fallo y N = nmero total de fallos registrados CAMBIABILIDAD Propsito Frmula Se mide esta caracterstica para garantizar al usuario que el sistema puede ser modificado. X = A/B A = nmero de cambios a funciones o mdulos que tienen comentarios confirmados B = total de funciones o mdulos modificados 0 <= X <= 1 Entre ms cercano a 1, ms registrable. 0 indica un control de cambios deficiente o pocos cambios y alta estabilidad ESTABILIDAD Propsito Se mide esta caracterstica para garantizar al usuario que el sistema no tendr efectos secundarios en caso de algn cambio Frecuencia de fallos debidos a efectos laterales producidos despus de una modificacin: X=1-A/B siendo A= nmero de fallos debidos a efectos laterales detectados y corregidos y B= nmero total de fallos corregidos el usuario) Tin = momento en el que se recibe el informe del fallo y N = nmero total de fallos registrados

Detalles de la frmula

Cuadro 155. Cambiabilidad

Detalles de la frmula

Cuadro 156. Estabilidad

Frmula

Detalles de la frmula

237

Cervecera Polar C.A Territorio Oriente Sur Mtricas de Transportabilidad: Facilidad con que el software puede ser llevado de un entorno a otro. Caractersticas: 1. Adaptabilidad: Capacidad del producto software para ser adaptado a diferentes

entornos especificados, sin aplicar acciones o mecanismos distintos de aquellos proporcionados para este propsito por el propio software considerado. 2. Facilidad de instalacin: Es el esfuerzo necesario para instalar el software en

un ambiente determinado. 3. Remplazabilidad: Capacidad del producto software para ser usado en lugar

de otro producto software, para el mismo propsito, en el mismo entorno. 4. Conformidad de la transportabilidad: Capacidad del producto software para

adherirse a normas o convenciones relacionadas con la portabilidad. En el presente proyecto es necesario medir la caracterstica de Conformidad de la transportabilidad, a continuacin se muestran la frmula apropiada para tal fin: Cuadro 157. Conformidad de la transportabilidad CONFORMIDAD DE LA TRANSPORTABILIDAD Propsito Frmula Detalles de la frmula Se mide esta caracterstica para garantizar al usuario que el sistema se ajustar al entorno y normas preestablecidas. X = A/B A = nmero de artculos implementados de conformidad B = total de artculos que requieren conformidad 0 <= X <= 1 Entre ms cercano a 1, ms completa.

238

Cervecera Polar C.A Territorio Oriente Sur Ingeniera de requisitos para procesos de ejecucin de estrategias de mercadeo (Impulsos y Fachadas), Coordinacin de Desarrollo en el Punto de Venta Cervecera Polar C.A Territorio Comercial Oriente Sur DOCUMENTO DE ESPECIFICACIN DE REQUISITOS Versin 1.0 Autor Fecha Versin 0.90 0.91 1.0 Descripcin Versin preliminar como propuesta de desarrollo Correccin de la versin preliminar Versin final

Karinthia Sarabia 01/09/2010 Karinthia Sarabia 07/11//2010 Karinthia Sarabia 10/12//2010

1. Introduccin Este documento describe con mayor detalle cada uno de los requisitos funcionales identificados en el documento de definicin de requisitos, los cuales sern especificados usando un modelo de casos. Dicho modelo contendr una serie de casos de usos, donde se muestra la interaccin usuario-sistema y se representaran las funciones u operaciones que cada actor puede realizar dentro del sistema. El alcance es realizar el proceso de especificacin de requisitos de software que esta orientado a guiar y dirigir posteriormente el proceso de diseo del sistema propuesto. 2. Requisitos Especficos Para el anlisis detallado de los requisitos del sistema se realiz desde el punto de vista del modelo funcional representado por los casos de usos, el modelo estructural representado por los diagramas de clases y el modelo dinmico haciendo referencia a los diagramas de secuencia, as como la descripcin concisa en lenguaje natural de los mismos y los prototipos de interfaces, estos diagramas ayudarn al desarrollador a entender el funcionamiento completo del sistema y como utilizarlo.

239

Cervecera Polar C.A Territorio Oriente Sur 2.1 Diagrama de Caso de Uso Los casos de uso vienen siendo casos de utilizacin del sistema, descripciones de su comportamiento desde el punto de vista del usuario que permiten mejorar la comprensin de los requisitos. Los diagramas de caso de uso son una representacin grfica de parte o el total de los actores y caso de uso del sistema, incluyendo sus interacciones; todo sistema tiene como mnimo un diagrama de caso de uso los cuales son una representacin grfica del entorno del sistema (actores) y su funcionalidad principal (casos de uso). Un diagrama de caso de uso muestra por lo tanto los distintos requisitos funcionales que se esperan de una aplicacin o sistema y cmo se relaciona con su entorno (usuarios u otras aplicaciones). Diagrama de Caso de Uso General del Sistema En ste caso de uso se describe el proceso general para la validacin de usuario (usuario, superusuario y administrador), que le permite el acceso al SISTEMA PARA LA GESTIN Y CONTROL DE LAS ESTRATEGIAS DE MERCADEO, donde al usuario le ser mostrado el men de opciones correspondiente a su nivel de acceso, se muestra el diagrama de caso de uso general del sistema (ver Diagrama 40). A continuacin se presenta la especificacin detallada de cada uno de los casos de usos del sistema.

240

Cervecera Polar C.A Territorio Oriente Sur

CU-2 Cambiar clav e

CU-3 include Gestionar Impulsos include Usuario CU-4 include Gestionar Fachadas Validar Usuario CU-1

include CU-5 Registrar Puntos de Venta

Superusuario

include

CU-6 Administrar Prov eedores

include

CU-7 Administrador Administrar Usuarios

Diagrama 40. Diagrama de Casos de Uso General del Sistema.

241

Cervecera Polar C.A Territorio Oriente Sur Escenario 1: Validar Usuario Caso de Uso del Negocio Actores Referencias Precondicin Autor Validar Usuario << CU-1 >>

Usuario SuperUsuario Administrador del sistema Todos los casos de usos Contar con usuarios registrados en el sistema. Fecha Karinthia Sarabia 06/09//2010

Versin 1.0

Propsito Representar el proceso de validacin de usuarios. Resumen En este caso de uso se validan los usuarios y se permite su ingreso a los mdulos que conforman el sistema en cuestin. Diagrama de Caso de Uso
CU-01 Validar Usuario

Usuarios del sistema

Usuarios

Super Usuario

Administrador

Diagrama 41. Caso de Uso Validar Usuario.

242

Cervecera Polar C.A Territorio Oriente Sur Curso Normal (Bsico) Nro. Accin del Actor

Nro. Respuesta del sistema 1 El sistema muestra la interfaz de autenticacin requerida, con los campos usuario y clave. Introduce usuario, clave y pulsa 3 Autentica usuario y clave. Ingresar. 4 Verifica el estado de cuenta del usuario. 5 Autoriza al usuario de acuerdo a las pginas y mdulos que tiene asignados. 6 Presenta al usuario el men principal.

Cursos Alternos 3 Si el usuario o clave son invlidas, el sistema muestra un mensaje de autenticacin fallida y permite ingresar el nombre de usuario y clave nuevamente 4 Si el usuario esta desactivado el sistema mostrara un mensaje de notificacin. Las interfaces usuario/sistema asociados a este caso de uso se encuentran en la seccin posterior prototipo de la aplicacin, son las Figura 25, Figura 26 y Figura 27. Diagrama de Clases
t_usuarios + + + + + + + + + + + id_usuario: int nombre: char apellido: char clave: int cedula: int estatus: char fec_registro: int validarcedula() validarclave() validarestatus() verificarTipoUsuario() cambiarEstatus() cargarTipoUsuario() buscarUsuario() cargarUsuario() cargarEstatus() cambiarclave() regresar()

t_tipo_usuario 1..* 1..* + + + id_tipo_usuario: int desc_tipo_usuario: char buscarTipoUsuario() agregarTipoUsuario() modificarTipoUsuario()

Diagrama 42. Diagrama de clases Validar Usuario.

243

Cervecera Polar C.A Territorio Oriente Sur

Diagrama 43. Diagrama de secuencia Validar Usuario.

244

Cervecera Polar C.A Territorio Oriente Sur Escenario 2: Cambiar Clave Caso de Uso del Negocio Actores Referencias Precondicin Autor Cambiar Clave << CU-2 >>

Usuario SuperUsuario Administrador del sistema Todos los casos de usos Contar con usuarios registrados en el sistema. El usuario debe iniciar sesin. Fecha Karinthia Sarabia 06/09/2010

Versin 1.0

Propsito Representar el proceso de cambio de clave del usuario. Resumen Este caso de uso presenta la funcionalidad que tienen todos los usuarios para hacer modificaciones en su clave que permite el acceso al sistema Diagrama de Caso de Uso
CU-02 Cambiar Clave

Usuarios del sistema

include

CU-01 Validar Usuario

Usuarios

Super Usuario

Administrador

Diagrama 44. Caso de Uso Cambiar Clave.

245

Cervecera Polar C.A Territorio Oriente Sur Curso Normal (Bsico) Nro. Accin del Actor Nro. Respuesta del sistema 1 Acceder a la opcin Cambiar clave ubicado en el men principal 2 El sistema mostrar la interfaz correspondiente a Cambiar Clave 3 El usuario debe ingresar su clave actual 4 El usuario debe ingresar su nueva clave y repetir para confirmarla 5 El usuario debe hacer click en el botn Guardar 6 El sistema gestionar el cambio de clave 7 El sistema mostrar un mensaje de cambio de clave exitoso Cursos Alternos 3 Si la clave es incorrecta el sistema mostrar un mensaje informndole al usuario que la contrasea es invlida. Las interfaces usuario/sistema asociados a este caso de uso se encuentran en la seccin posterior prototipo de la aplicacin, son las Figura 28 y Figura 29. Diagrama de Clases
t_usuarios + + + + + + + + + + + id_usuario: int nombre: char apellido: char clave: int cedula: int estatus: char fec_registro: int validarcedula() validarclave() validarestatus() verificarTipoUsuario() cambiarEstatus() cargarTipoUsuario() buscarUsuario() cargarUsuario() cargarEstatus() cambiarclave() regresar()

Diagrama 45. Diagrama de clases Cambiar Clave. 246

Cervecera Polar C.A Territorio Oriente Sur

Diagrama 46. Diagrama de Secuencia Cambiar Clave.

247

Cervecera Polar C.A Territorio Oriente Sur Escenario 3: Gestionar Impulsos Caso de Uso del Negocio Actores Referencias Precondicin Autor Gestionar Impulsos << CU-3>>

Usuario SuperUsuario Administrador del sistema. El usuario debe haber seleccionado el mdulo Impulsos Fecha Karinthia Sarabia 12/09/2010

Versin 1.0

Propsito Representar el proceso gestin de la estrategia de mercadeo Impulsos. Resumen En este caso de uso se representa el proceso de gestin de la estrategia de mercadeo Impulsos, el cual permite a las Agencias realizar las solicitudes mediante la completacin de un formulario, para luego ser enviado y posteriormente estudiar dicha solicitud, para continuar con el proceso de gestin se determinara el estatus de la mencionada solicitud y permite al Coordinador la asignacin del proveedor correspondiente. Diagrama de Caso de Uso
CU-3.1 Registrar Solicitud Impulsos include

CU-3.2 Usuario Consultar Estatus Impulsos include

CU-1 Validar usuario

CU-3.3 Asignar Proveedor

include

Superusuario

Diagrama 47. Caso de Uso Gestionar Impulsos.

248

Cervecera Polar C.A Territorio Oriente Sur Curso Normal (Bsico) Nro. Accin del Actor Nro. Respuesta del sistema 1 El usuario selecciona del men 2 El sistema abre una nueva ventana y principal Impulsos muestra desplegados 3 submdulos: Solicitudes, Estatus de la solicitud, Asignar proveedor. En el submdulo Solicitudes se muestra la opcin ingresar una Nueva Solicitud de Impulsos. En el submdulo Estatus de la Solicitud se podr consultar las solicitudes y verificar el estado de estas. En el Submdulo Asignar proveedor permitir al Coordinador asociar una solicitud de Impulsos aprobada con un proveedor a ejecutar dicho trabajo. 3 Solicitudes 3.1 Se muestra una ventana para ingresar El usuario selecciona del men una nueva solicitud de Impulsos principal Impulsos, luego la opcin Solicitudes 3.2 Se muestra el formulario para ser completado con los datos de la nueva solicitud a realizar 3.3 El usuario ingresa los datos de la 3.4 El sistema guarda los datos y genera solicitud y presiona Guardar un alerta donde la operacin fue exitosa. 4 Estatus de Solicitud 4.1 Se muestra una ventana con un El usuario selecciona del men buscador y un listado de solicitudes. principal Impulsos, luego la opcin El buscador permite filtrar la Estatus de Solicitud informacin seleccionando alguna de las opciones bien sea Agencia o Cliente. 4.2 El usuario introduce en el campo 4.3 El sistema realiza el proceso de de texto la informacin bsqueda y muestra segn lo correspondiente a la Agencia o el seleccionado por el usuario, si este Cliente requerido, y selecciona de seleccion Agencia, se mostrar un acuerdo a los datos ingresados si listado con las solicitudes de esa desea que sea filtrado por Agencia agencia por el contrario si el usuario o por Cliente presiona cliente slo se mostrar la(s) solicitud(es) realizadas para ese cliente en especfico.

249

Cervecera Polar C.A Territorio Oriente Sur 5 Asignar Proveedor El sistema mostrar un listado con los solicitudes aprobadas Muestra la solicitud en detalle adems de la opcin para seleccionar un proveedor mediante una lista desplegable. El sistema mostrara un mensaje de asignacin de proveedor exitosa.

5.1 Hace doble click en la solicitud a la cual desea asignar un proveedor

5.2

5.3 Selecciona el proveedor a ser asignado y presiona Guardar

5.4

Las interfaces usuario/sistema asociados a este caso de uso se encuentran en la seccin posterior prototipo de la aplicacin, son las Figura 30, Figura 31, Figura 32, Figura 33 y Figura 34. Diagrama de Clases
t_tipo_cliente t_puntos_v enta + + + + + + + + id_punto: int razon_social: char rif: int direccion: char contacto: char tlf_contacto: int tipo_de_cliente: char estatus: char agencia: char validarestatus() verificartipodecliente() cambiarestatus() buscarpunto() cargarpunto() cargarestatus() registrarsolicitud() regresar() asigna + + + id_tipo_cliente: int desc_tipo: int agregartipocliente() buscartipocliente() modificartipocliente()

t_prov eedores 1..* + + + + + id_proveedores: int razon_social: char rif: int area_servicio: char direccion: char correo: char telefono1: int telefono2: int fax: int registrar_proveedor() editar_proveedor() eliminar_proveedor() buscar_proveedor() asignar_proveedor()

1..*

Diagrama 48. Diagrama de clases Gestionar Impulsos. Diagrama 49. Diagrama de secuencia Gestionar Impulsos.

250

Cervecera Polar C.A Territorio Oriente Sur Escenario 4: Gestionar Fachadas Caso de Uso del Negocio Actores Referencias Precondicin Autor Gestionar Fachadas << CU-4>>

Usuarios SuperUsuario Administrador del sistema. El usuario debe haber seleccionado el mdulo Fachadas Fecha Versin Karinthia Sarabia 12/09/2010 1.0

Propsito Representar el proceso gestin de la estrategia de mercadeo Impulsos. Resumen En este caso de uso se representa el proceso de gestin de la estrategia de mercadeo Fachadas, el cual permite a las Agencias realizar las solicitudes mediante la completacin de un formulario, para luego ser enviado y posteriormente estudiar dicha solicitud, para continuar con el proceso de gestin se determinara el estatus de la mencionada solicitud y permite al Coordinador la asignacin del proveedor correspondiente. Diagrama de Caso de Uso
CU-4.1 Registrar Solicitud Fachadas include

CU-4.2 Usuario Consultar Estatus Fachadas include

CU-1 Validar usuario

CU-4.3 Asignar Proveedor

include

Superusuario

Diagrama 50. Caso de Uso Gestionar Fachadas.

251

Cervecera Polar C.A Territorio Oriente Sur Curso Normal (Bsico) Nro. Accin del Actor Nro. Respuesta del sistema 1 El usuario selecciona del men 2 El sistema abre una nueva ventana y principal Fachadas muestra desplegados 3 submdulos: Solicitudes, Estatus de la solicitud, Asignar proveedor. En el submdulo Solicitudes se muestra la opcin ingresar una Nueva Solicitud de Fachadas. En el submdulo Estatus de la Solicitud se podr consultar las solicitudes y verificar el estado de estas. En el Submdulo Asignar proveedor permitir al Coordinador asociar una solicitud de Fachadas aprobada con un proveedor a ejecutar dicho trabajo. 3 Solicitudes 3.1 Se muestra una ventana para ingresar El usuario selecciona del men una nueva solicitud de Fachadas principal Fachadas, luego la opcin Solicitudes 3.2 Se muestra el formulario para ser completado con los datos de la nueva solicitud a realizar 3.3 El usuario ingresa los datos de la 3.4 El sistema guarda los datos y genera solicitud y presiona Guardar un alerta donde la operacin fue exitosa. 4 Estatus de Solicitud 4.1 Se muestra una ventana con un El usuario selecciona del men buscador y un listado de solicitudes. principal Fachadas, luego la El buscador permite filtrar la opcin Estatus de Solicitud informacin seleccionando alguna de las opciones bien sea Agencia o Cliente. 4.2 El usuario introduce en el campo 4.3 El sistema realiza el proceso de de texto la informacin bsqueda y muestra segn lo correspondiente a la Agencia o el seleccionado por el usuario, si este Cliente requerido, y selecciona de seleccion Agencia, se mostrar un acuerdo a solicitud si desea que sea listado con las solicitudes de esa filtrado por Agencia o por Cliente agencia por el contrario si el usuario presiona cliente slo se mostrar la(s) solicitud(es) realizadas para ese cliente en especfico.

252

Cervecera Polar C.A Territorio Oriente Sur 5 Asignar Proveedor El sistema mostrar un listado con los solicitudes aprobadas Muestra la solicitud en detalle adems de la opcin para seleccionar un proveedor mediante una lista desplegable. El sistema mostrara un mensaje de asignacin de proveedor exitosa.

5.1 Hace doble click en la solicitud a la cual desea asignar un proveedor

5.2

5.3 Selecciona el proveedor a ser asignado y presiona Guardar

5.4

Las interfaces usuario/sistema asociados a este caso de uso se encuentran en la seccin posterior prototipo de la aplicacin, son las Figura 35, Figura 36, Figura 37, Figura 38 y Figura 39. Diagrama de Clases
t_tipo_cliente t_puntos_v enta + + + + + + + + id_punto: int razon_social: char rif: int direccion: char contacto: char tlf_contacto: int tipo_de_cliente: char estatus: char agencia: char validarestatus() verificartipodecliente() cambiarestatus() buscarpunto() cargarpunto() cargarestatus() registrarsolicitud() regresar() asigna + + + id_tipo_cliente: int desc_tipo: int agregartipocliente() buscartipocliente() modificartipocliente()

t_prov eedores 1..* + + + + + id_proveedores: int razon_social: char rif: int area_servicio: char direccion: char correo: char telefono1: int telefono2: int fax: int registrar_proveedor() editar_proveedor() eliminar_proveedor() buscar_proveedor() asignar_proveedor()

1..*

Diagrama 51. Diagrama de clases Gestionar Fachadas. Diagrama 52. Diagrama de secuencia Gestionar Fachadas

253

Cervecera Polar C.A Territorio Oriente Sur Escenario 6: Administrar Proveedores Caso de Uso del Negocio Actores Referencias Precondicin Autor Administrar Proveedor << CU-6>>

Administrador El usuario debe haber seleccionado el mdulo Proveedores Fecha Versin Karinthia Sarabia 15/09/2010 1.0

Propsito Permitir el ingreso al sistema de un nuevo proveedor, actualizar los datos de cualquier proveedor existente, eliminar proveedor y consultar algn proveedor. Resumen Este caso de uso representa el ingreso de un nuevo proveedor al sistema, la actualizacin de los datos del mismo, su eliminacin y consulta. Diagrama de Caso de Uso
CU-6 Administrar Proveedores Usuarios del sistema include CU-1 Validar usuario

Superusuario

Administrador

Diagrama 53. Caso de Uso Ingresar Proveedor.

Las interfaces usuario/sistema asociados a este caso de uso se encuentran en la seccin posterior prototipo de la aplicacin, son las Figura 40 y Figura 41.

254

Cervecera Polar C.A Territorio Oriente Sur

Curso Normal (Bsico) Nro. Accin del Actor Nro. Respuesta del sistema El usuario selecciona del men 1 principal Proveedores 2 Ingresar Proveedor 2.1 Se muestra la ventana de Ingresar para El usuario hace clic en el submdulo un nuevo proveedor. Ingresar 2.2 Se muestra el formulario para ser completado con los datos del nuevo proveedor 2.3 El usuario ingresa los datos del proveedor y presiona Guardar 2.4 El sistema guarda los datos y genera un alerta donde la operacin fue exitosa. 3 Consultar Proveedor 3.1 Se muestra la ventana de Consulta de El usuario hace clic en el submdulo proveedores y las opciones de bsqueda Consulta 3.2 El usuario ingresa la razn social o 3.3 Se muestra los datos generales del Rif del proveedor proveedor 3.4 El usuario presiona el Rif del proveedor 3.5 El sistema muestra los datos especficos del proveedor 3.6 El usuario modifica los datos que sean necesarios modificar y presiona Guardar. 3.7 El sistema genera una notificacin indicando que la operacin fue exitosa.

Diagrama de Clases
t_prov eedores + + + + + id_proveedores: int razon_social: char rif: int area_servicio: char direccion: char correo: char telefono1: int telefono2: int fax: int registrar_proveedor() editar_proveedor() eliminar_proveedor() buscar_proveedor() asignar_proveedor()

Diagrama 54. Diagrama de clases Proveedor. Diagrama 55. Diagrama de secuencia Proveedores.

255

Cervecera Polar C.A Territorio Oriente Sur Escenario 7: Administrar Usuarios Caso de Uso del Negocio Actores Referencias Precondicin Administrar Usuarios << CU-7 >>

Postcondicin

Autor

Administrador del sistema. Documento Definicin de Requisitos El usuario ha sido validado por el sistema y su men ha sido cargado como administrador. El administrador realiz cambios en los usuarios del sistema segn la seleccin (ingresar, editar o eliminar un usuario). El administrador les asign los mdulos y pginas a los distintos usuarios del sistema. Fecha Versin Karinthia Sarabia 15/09/2010 1.0

Propsito Establecer perfiles a cada usuario del sistema. Resumen Este caso de uso es iniciado por el administrador del sistema, le permite realizar cambios en las cuentas de los usuarios registrados

Diagrama de Caso de Uso

CU-7 Administrar Usuarios include Administrador CU-1 Validar Usuario

Diagrama 56. Caso de Uso Administrar Usuario.

256

Cervecera Polar C.A Territorio Oriente Sur Curso Normal (Bsico) Nro. Accin del Actor Nro. Respuesta del sistema 1 Se inicia cuando el Administrador 2 El sistema abre una nueva ventana y del Sistema selecciona del men muestra las opciones (Ingresar, principal Administrar Usuarios. Editar, Eliminar) y tambin permite listar los usuarios que han sido creados y los muestra en pantalla. 3 Ingresar Nuevo Usuario 3.1 El sistema abre una ventana, busca El administrador del sistema los tipos de usuarios y muestra en presiona el botn Ingresar para pantalla el formulario para editar los datos del nuevo usuario. crear un nuevo usuario 3.2 El administrador introduce los 3.3 El sistema valida los datos introducidos datos del nuevo usuario y presiona Agregar 3.4 El sistema registra un nuevo usuario 3.5 El sistema muestra un mensaje en pantalla notificando que el usuario ha sido creado correctamente. 4 Buscar Usuario 4.1 El sistema busca usuario de acuerdo a El usuario llena el campo de los caracteres ingresados y los bsqueda y presiona Filtrar muestra en pantalla 5 Editar Usuario 5.1 El sistema abre una ventana busca el El usuario administrador usuario seleccionado, busca los tipos selecciona un usuario de la lista y de usuarios y muestra en pantalla el presiona el botn Modificar formulario con la informacin del usuario seleccionado 5.2 El administrador edita los datos del 5.3 El sistema actualiza los datos del usuario y presiona el botn usuario. Modificar 5.4 El sistema en pantalla un mensaje indicando que los datos han sido actualizados exitosamente. 6 Eliminar Usuario 6.1 El sistema muestra un mensaje de El administrador selecciona un confirmacin para eliminar el usuario usuario de la lista y presiona el botn Eliminar 6.2 El usuario confirma la eliminacin. 6.3 El sistema elimina el usuario seleccionado 6.4 El sistema enva un mensaje indicando que el usuario ha sido eliminado exitosamente. 7 El usuario administrador presiona 7.1 Para terminar con el proceso, el sistema abre y muestra el men principal. el botn Salir.

257

Cervecera Polar C.A Territorio Oriente Sur Cursos Alternos 1a En caso que el administrador dese volver a la pantalla anterior sin guardar los datos del nuevo usuario, entonces presiona el botn Retornar. 1b En caso de que los datos introducidos del usuario sean invlidos o que el nombre de usuario ingresado ya exista, el sistema enva un mensaje para que el usuario verifique la informacin. Las interfaces usuario/sistema asociados a este caso de uso se encuentran en la seccin posterior prototipo de la aplicacin, es la Figura 42. Diagrama de Clases
t_usuarios + + + + + + + + + + + id_usuario: int nombre: char apellido: char clave: int cedula: int estatus: char fec_registro: int validarcedula() validarclave() validarestatus() verificarTipoUsuario() cambiarEstatus() cargarTipoUsuario() buscarUsuario() cargarUsuario() cargarEstatus() cambiarclave() regresar() pertenece 1..* 1..*

t_tipo_usuario + + + id_tipo_usuario: int desc_tipo_usuario: char buscarTipoUsuario() agregarTipoUsuario() modificarTipoUsuario()

Diagrama 57. Diagramas de clases Administrar Usuarios.

258

Cervecera Polar C.A Territorio Oriente Sur

W:AdministrarUsuario

:Usuario

:TipoUsuario

USUARIO

Ingresa Cdula,Nombre

Presiona botn Guardar Enva Datos (cedula, nom_usuario) GuardaDatos (cedula, nom_usuario)

Registrar Usuario

GuardaDatos (desc_tipo_usuario)

Muestra mensaje de carga correcta

Ingresa Cdula Presiona botn Buscar Enva Datos (cedula, nom_usuario) BuscaDatos (cedula, nom_usuario, estatus) Enva Datos (desc_tipo_usuario) BuscaDatos (desc_tipo_usuario) Enva Datos (desc_tipo_usuario)

BuscaDatos (desc_tipo_usuario)

Muestra datos del usuario

Actualizar Usuario

Realiza Cambios Presiona botn Actualizar Enva Datos (estatus) ModificaDatos (estatus)

Enva Datos (desc_tipo_usuario)

ModificaDatos (desc_tipo_usuario)

Muestra mensaje de actualizacin correcta

Diagrama 58. Diagrama de secuencia Administrar Usuarios. 2.2 Prototipo de la Aplicacin Es un producto de software que emula la interaccin usuario/sistema que tendr la aplicacin empresarial. Se construye con la finalidad de descubrir nuevos requisitos, facilitar la validacin de los requisitos funcionales de la aplicacin. Bajo

259

Cervecera Polar C.A Territorio Oriente Sur un enfoque de desarrollo evolutivo e iterativo. El prototipo sirve como entrada al proceso de diseo de la aplicacin, especialmente en el diseo de interfaz. Interfaces Usuario/Sistema

Figura 25. Interfaz de Acceso al Sistema.

Figura 26. Interfaz de Inicio Rol SuperUsuario.

260

Cervecera Polar C.A Territorio Oriente Sur

Figura 27. Interfaz de Inicio Rol Administrador del Sistema.

Figura 28. Interfaz Cambiar Clave Rol SuperUsuario.

261

Cervecera Polar C.A Territorio Oriente Sur

Figura 29. Interfaz Cambiar Clave Rol Administrador.

Figura 30. Solicitud de Impulsos Rol Usuario y SuperUsuario.

262

Cervecera Polar C.A Territorio Oriente Sur

Figura 31. Estatus de Solicitud Rol Usuario.

263

Cervecera Polar C.A Territorio Oriente Sur

Figura 32. Estatus de Solicitud Rol Superusuario.

264

Cervecera Polar C.A Territorio Oriente Sur

Figura 33. Asignacin de proveedor estrategia impulsos

Figura 34. Asignacin de proveedor a solicitud de impulsos

265

Cervecera Polar C.A Territorio Oriente Sur

Figura 35. Solicitud de Fachadas.

Figura 36. Estatus de Solicitud Fachadas Rol Usuario.

266

Cervecera Polar C.A Territorio Oriente Sur

Figura 37. Estatus de Solicitud Fachadas Rol SuperUsuario

Figura 38. Asignacin de proveedor a solicitud de fachada

267

Cervecera Polar C.A Territorio Oriente Sur

Figura 39. Asignacin de proveedor a solicitud de fachada

268

Cervecera Polar C.A Territorio Oriente Sur

Figura 40. Ingresar Proveedores.

Figura 41. Consulta de proveedores.

269

Cervecera Polar C.A Territorio Oriente Sur

Figura 42. Administrar Usuarios.

270

Anlisis Costo Beneficio El anlisis costo beneficio es una tcnica importante que permite definir la factibilidad de un proyecto. Tiene como objetivo fundamental proporcionar una medida de los costos en que se incurren en la realizacin de un proyecto a fin de comparar dichos costos con los beneficios esperados. La finalidad de este anlisis es justificar la elaboracin de este proyecto y de especificar los beneficios tangibles e intangibles que se obtendrn. A continuacin describen los costos que fueron necesarios para desarrollar el proyecto. Costos Costos de Personal En este rubro se incluyen todos los gastos concernientes al pago del recurso humano necesario para el desarrollo de la investigacin, ya sea por concepto de contrato de nuevo personal o por el tiempo brindado por los trabajadores de la empresa, que pudo ser utilizado en la ejecucin de sus actividades diarias. La elaboracin del modelado estuvo a cargo del tesista autor del presente Trabajo de Grado, el cual tuvo la responsabilidad de buscar toda la informacin necesaria para la construccin de los diversos diagramas y matrices que explican el funcionamiento de la coordinacin. El mismo estuvo contratado durante un perodo de nueve (06) meses, durante los cuales percibi un salario de mil (1000) bolvares. Estos costos nos permiten representar la remuneracin que reciben cada uno de los involucrados con el desarrollo del proyecto. Los costos mostrados a continuacin fueron determinados de acuerdo a los salarios establecidos por el Colegio de Ingenieros de Venezuela y al tiempo de experiencia de los involucrados. En este proyecto los participantes fueron:

271

Cuadro 158. Involucrados en el Proyecto Rol Salario Responsable General del Proyecto Lder del Proyecto Analista de Procesos de Negocio Analista de Sistemas 4.740,74 8.385.25 1000

Salario por Jornada Diaria (8 h) 237,04 419.263 50

Los costos incurridos este proyecto en base al tiempo empleado por cada uno de los participantes se muestra a continuacin: Cuadro 159. Costos por Personal del Proyecto Rol Tiempo Empleado Costo por por Mes Mes Responsable General 8 Horas 237,04 del Proyecto Lder del Proyecto 16.Horas 838.53 Analista de Procesos de Negocio Analista de Sistemas 64 Horas 64 Horas Total Costo Personal Costos de Adiestramiento Estos costos se encuentran representados por los adiestramientos, talleres o cursos realizados con la finalidad de obtener los conocimientos necesarios para lograr el desarrollo del proyecto, estos son mostrados a continuacin: Cuadro 160. Costos de adiestramiento Necesidad Costos Curso de PHP 800 14.604.53 Bs 1000Bs.F

Total Costo*6 Meses 1896.32 6708.21 6000

272

Costos de Materiales de Oficina Este grupo abarca todas la erogaciones realizadas en cuanto a la adquisicin de los distintos recursos de uso comn, empleados en cualquier proyecto, tales como lapiceros, hojas, carpetas, entre otros, los cuales facilitan y agilizan la ejecucin de las actividades cotidianas como la redaccin de informes, reproduccin de material, investigacin, organizacin de documentos, etc. Los gastos por materiales de oficina efectuados durante el desarrollo del presente proyecto se presentan en el Cuadro 161. Cuadro 161. Costos de material de oficina Material de oficina Precio Unitario Papel tamao carta Fotocopias Lapiceros Pega de barra grande Marcadores Libreta Corrector Recarga Cartuchos Impresin Bs 40,00 Bs 0,25 Bs 2,00 Bs 7,00 Bs 5,00 Bs 6,00 Bs 9,00 de Total Costos de Hardware y Software Se refiere a los desembolsos realizados por la adquisicin de computadoras y aplicaciones informticas empleadas para la elaboracin del modelado. La empresa contaba con los equipos de computacin y posea las licencias de software requeridas, como Microsoft Office, para la elaboracin del desarrollo de la ingeniera de requisitos, Enterprise Architect, herramienta CASE utilizada para dibujar cada uno de los diagramas. Por tal razn, no fue necesaria la compra de estos recursos, es decir, la inversin de hardware y software para este trabajo fue de cero (00) bolvares. Bs. 15,00

Cantidad 5 500 6 1 4 2 1 8

Costo Bs 200,00 Bs125,00 Bs 12,00 Bs 7,00 Bs 20,00 Bs 12,00 Bs 9,00 Bs.120,00 Bs. 505,00

273

En conclusin, el proyecto tuvo un costo total de Bs, el Cuadro 162 resume los gastos de personal, logstica, materiales de oficina, hardware y software. Cuadro 162. Costos totales del proyecto Concepto Personal Adiestramiento Materiales de Oficina Hardware Software Total Costo Bs. 14.604.53 Bs. 800 Bs 505,00 Bs. 0,00 Bs. 0,00 Bs 15.909,53

Beneficios Anlisis de los Beneficios Los beneficios asociados al desarrollo y puesta en operacin del proyecto se clasifican en beneficios tangibles e intangibles. Beneficios Tangibles: Se refiere a las ventajas cualititativas que genera el desarrollo del proyecto. La ingeniera de requisitos obtenida permitir un diseo consisten y construccin adecuada, trayendo como resultado una aplicacin empresarial con los siguientes beneficios directos: 1. Aumento en la competitividad de la empresa en cuanto al uso de tecnologas

que permiten un manejo eficiente de las estrategias de mercado implementadas sobre de los productos ofertados. 2. 3. Mayor confiabilidad de la informacin manejada. Optimizacin de los procesos de estrategias de mercadeo de Impulsos y

Fachadas.

274

4.

Manejo adecuado y uso eficientemente de los recursos para control de los

procesos de mercado de Impulsos y Fachadas. 5. 6. Obtencin de informacin oportuna en forma ms rpida y segura. Optimizacin de los tiempos empleados en la bsqueda de datos,

proporcionando informacin confiable y oportuna en la toma de decisiones, 7. 8. Contar con un soporte para el seguimiento de estos procesos en el tiempo real Reduccin de los ndices de inconsistencias y duplicidad del contenido de la

informacin de dichos procesos que se resguardarn. 9. Generacin de datos estadsticos resultantes de los procesos Impulsos y

Fachadas, que hagan posible el acceso, clasificacin y totalizacin de la data haciendo referencia a distintos campos Beneficios Intangibles: Se refiere a aquellos beneficios que no se pueden cuantificar pero poseen gran relevancia al momento de decidir si se procede o no con el desarrollo de algn proyecto, entre los beneficios intangibles que trae el presente proyecto se encuentran: 1. Mayor entendimiento de los procesos que realiza la Coordinacin de Desarrollo

en el Punto de Venta tanto por el personal interno como externo. 2. 3. 4. 5. 6. Visualizacin de los aspectos crticos que presenta la Coordinacin. Mejora en el proceso de toma de decisiones. Aumento en la competitividad de los servicios a los usuarios del negocio. Mayor integracin del personal con el negocio. Captacin de los requerimientos de los usuarios del negocio de la

Coordinacin. 7. Facilidad para el desarrollo de software.

275

CONCLUSIONES 1. El diagnstico realizado en la unidad en estudio result apropiado para determinar las fortalezas entre estas el empeo diario de sus trabajadores en crecer como departamento, debilidades como la carencia de misin y visin formalmente definidas, los focos problemticos resaltando la inexistencia de normas y procedimientos bien definidos para las solicitudes de Impulsos y Fachadas, adems sus respectivas causas que para el momento se detectaron en la Coordinacin de Desarrollo en el Punto de Venta, derivando la necesidad de construir una aplicacin empresarial con la finalidad de automatizar los procesos de la misma. 2. El Modelo de negocio permiti representar el sistema de negocio en estudio constituido por la Coordinacin de Desarrollo en el Punto de Venta dentro del cual se desarrollar la aplicacin empresarial, el modelador logr descubrir, comprender y plasmar diferentes aspectos de la organizacin como los procesos (medulares y de apoyo) que se ejecutan, su funcin dentro Territorio Comercial Oriente Sur, la descripcin de cada uno de los procesos Impulsos y Fachadas, la distribucin jerrquica de los mismos y la relacin con otras unidades. 3. En cuanto a las plantillas volere permitieron capturar, analizar y depurar eficientemente los requisitos funcionales y no funcionales que deber satisfacer la aplicacin empresarial propuesta para la gestin y control de las estrategias de mercadeo (Impulsos y Fachadas). 4. El diseo y construccin de la aplicacin empresarial se facilitara significativamente debido a que requisitos finales definidos se sustentaron mediante la utilizacin del Lenguaje de Modelado Unificado (UML) permitiendo tener una visin detallada y explicativa desde el punto de vista: funcional, estructural y de comportamiento de los mismos. 5. La ingeniera de requisitos permiti validar los requisitos funcionales y no funcionales generando el prototipo de interfaces usuario/sistema para la

276

aplicacin de empresarial diseada para la gestin y control de las estrategias de mercadeo Impulsos y Fachadas que constituyen los procesos primarios para la Coordinacin de Desarrollo en el Punto de Venta.

277

RECOMENDACIONES 1. Basndose en el Modelo de Negocio para la Coordinacin de Desarrollo en el Punto de Venta Territorio Comercial realizar una propuesta ante los directivos de la empresa para adaptar dicho Modelo de Negocio a sus unidades homologas. 2. Construir la aplicacin empresarial para la gestin, control y seguimiento de las estrategias de mercadeo Impulsos y Fachadas en la Coordinacin de Desarrollo en el Punto de Venta Cervecera Polar C.A Territorio Comercial Oriente Sur en base a la ingeniera de requisitos propuesta.

278

BIBLIOGRAFA Abreu, M. (2007). Modelo de Negocios del Departamento Tcnico de la Direccin de Servicios Generales de la Universidad de los Andes. Tesis de grado, Ingeniera de Sistemas, Universidad de los Andes, Mrida - Venezuela. ARIAS, F. (2006). El proyecto de investigacin: Introduccin a la metodologa cientfica. (5 ed.) Caracas - Venezuela: Episteme. BALESTRINI ACUA, M. (2002). Cmo se Elabora el Proyecto de Investigacin. (6a. ed.). Caracas: BL Consultores Asociados. C.J Date. (2001). Introduccin a los sistemas de bases de datos. Editorial Pearson. Edicin 7. CASTRO, M. (2003). El proyecto de investigacin y su esquema de elaboracin. (2.ed.). Caracas: Uyapal. CEISoft Ingeniera de Requisitos Curso IS-12. Programa de Actualizacin Profesional en Ingeniera de Requisitos. Mrida, 2009 Jons Montilva. Versin 5.0-2009- BIOSFT C.A. Centro de Excelencia en Ing. de Requisitos Mrida, Venezuela. COBO, A., GMEZ, P., PREZ, D. y ROCHA, R. PHP y MySQL Tecnologas para el desarrollo de aplicaciones web. Ediciones Daz de Santos. Espaa 2005. Diccionario Informtico. Aplicacin Web. [Documento en lnea]. Disponible: http://www.alegsa.com.ar/Dic/aplicacion%20web.php Enero 11] HURTADO, J. (2007). El Proyecto de Investigacin. Metodologa de la Investigacin Holstica. Caracas: Quirn. [Consulta: 2010,

279

LAUDON, Kenneth (1995). Administracin de los Sistemas de Informacin. 3ra Edicin. Editorial Nueva Visin. Venezuela. Lenguaje Unificado de Modelado (UML). [Documento en lnea]. Disponible: http://es.wikipedia.org/wiki/Lenguaje_Unificado_de_Modelado 2010, Enero 04] MARTIN, F. y KENDALL S. (1999). "UML Gota a Gota. 1era Edicin. Mata, V (2010). Modelado de Negocios y procesos operacionales de la gerencia de plantas de gas y agua del distrito norte de Pdvsa Exploracin y Produccin Oriente. Trabajo Especial de Grado realizado para obtener el ttulo de Ingeniero de Sistemas en la Universidad de Oriente, Ncleo Monagas MONTILVA C., J. GRAY WATCH mtodo de desarrollo de software para aplicaciones empresariales. Venezuela 2008. MONTILVA C., J. (2007). Modelado de Negocios. Del espacio del problema al espacio de la solucin. Universidad de los Andes. [Documento en lnea]. Disponible:http://kuainasi.ciens.ucv.ve/ideas07/documentos/conferencias/Con ferenciaJonasMontilva.pdf. [Consultado: 2009, Noviembre]. MONTILVA, J. y BARRIOS, J. BMM: A Business Modeling Method for Information Systems Development. CLEI Electronic Journal, Vol. 7, No. 2, Diciembre 2004. Disponible: http://www.clei.cl/cleiej/papers/v7i2p3.pdf. [Consultado: 2009,Noviembre]. MONTILVA, J. y BARRIOS, J. Un Mtodo para el Desarrollo de Aplicaciones Empresariales. Venezuela 2005. PASTOR, J. (s.f). Usos de los sistemas de informacin en la organizacin. Editorial UOC, p.10. [Consulta:

280

PREZ, A. (2002). Gua Metodolgica para anteproyectos de Investigacin. Editorial FEDUPEL. Caracas Venezuela. RAMREZ, T. (1999). Como hacer un proyecto de investigacin. (1. Ed.). Caracas: Panapo. RODRIGUEZ A., Miguel A. (1992). Bases de Datos. Editorial Mc Graw-Hill. Venezuela. RODRGUEZ, N. y MARTNEZ, W. Planificacin y evaluacin de proyectos informticos. Editorial Universidad Estatal a Distancia. San Jos, Costa Rica, 1998. Primera Edicin. (pp. 163). Salazar, C (2006). Especificacin y Evaluacin de alternativas de software para el departamento de repuestos de ALMARCA. Tesis de grado de la especialidad de Ingeniera de Sistemas de la Universidad de los Andes Mrida. TAMAYO Y TAMAYO (2001). El proceso de la investigacin cientfica. (4. ed.) Mxico: Lamusa. Universidad Pedaggica Experimental Libertador. Vicerrectorado de Investigacin y Postgrado (2006). Manual de Trabajos de Grado de Especializacin y Maestra y Tesis doctorales. Caracas: FEDUPEL. VEGA, E. (2005). Los sistemas de informacin y su importancia para las organizaciones y empresas. [Documento en lnea]. Disponible:

http://www.monografias.com/trabajos24/tics-empresas/tics-empresas.shtml [Consulta: 2009, Diciembre 01]

281

ANEXOS

UNIVERSIDAD DE ORIENTE NCLEO DE MONAGAS INGENIERA DE SISTEMAS MATURN / MONAGAS / VENEZUELA

CUESTIONARIO

NOMBRE Y APELLIDO_______________________________________ CARGO QUE OCUPA_________________________________________ TIEMPO DE SERVICIO EN LA EMPRESA_______________________

Lea cuidadosamente y conteste cada una de las afirmaciones de acuerdo a lo que considere, seleccione solo una de las opciones de respuesta.

1.

Considera usted que la Coordinacin de Desarrollo en el Punto de Venta es la

unidad encargada de la aplicacin de las estrategias de mercadeo como son Impulsos y Fachadas. a. Muy de acuerdo b. De acuerdo c. Ni de acuerdo ni en desacuerdo d. En desacuerdo e. Muy en desacuerdo

2.

La Coordinacin de Desarrollo en el Punto de Venta posee misin, visin,

valores y objetivos formalmente definidos. a. Muy de acuerdo b. De acuerdo c. Ni de acuerdo ni en desacuerdo d. En desacuerdo e. Muy en desacuerdo 3. Las principales funciones que realiza la coordinacin son los procesos Impulsos

y Fachadas. a. Muy de acuerdo b. De acuerdo c. Ni de acuerdo ni en desacuerdo d. En desacuerdo e. Muy en desacuerdo 4. El objetivo general de la Coordinacin de Desarrollo en el Punto de Venta es

garantizar el cumplimento de los planes y actividades promocionales mediante ejecucin de las estrategias de mercadeo. a. Muy de acuerdo b. De acuerdo c. Ni de acuerdo ni en desacuerdo d. En desacuerdo e. Muy en desacuerdo 5. La Coordinacin de Desarrollo en el Punto de Venta tiene normas y

procedimientos bien definidos para las solicitudes de Impulsos y Fachadas a. Muy de acuerdo b. De acuerdo c. Ni de acuerdo ni en desacuerdo d. En desacuerdo e. Muy en desacuerdo

6.

El control de documentos que se lleva en la coordinacin es poco eficiente. a. Muy de acuerdo b. De acuerdo c. Ni de acuerdo ni en desacuerdo d. En desacuerdo e. Muy en desacuerdo

7.

Considera que el personal de la Coordinacin de Desarrollo en el Punto de

Venta cuenta con tecnologa de punta a su disposicin a. Muy de acuerdo b. De acuerdo c. Ni de acuerdo ni en desacuerdo d. En desacuerdo e. Muy en desacuerdo 8. Considera usted que el recurso humano es el activo ms valioso de la empresa. a. Muy de acuerdo b. De acuerdo c. Ni de acuerdo ni en desacuerdo d. En desacuerdo e. Muy en desacuerdo 9. Cervecera Polar C.A, se interesa por el bienestar de sus trabajadores. a. Muy de acuerdo b. De acuerdo c. Ni de acuerdo ni en desacuerdo d. En desacuerdo e. Muy en desacuerdo

10.

La Coordinacin de Desarrollo en el Punto de Venta se empea da a da en

mantener y crecer como departamento y as a su vez contribuir afianzar el liderazgo de la empresa en el mercado. a. Muy de acuerdo b. De acuerdo c. Ni de acuerdo ni en desacuerdo d. En desacuerdo e. Muy en desacuerdo 11. Considera usted que la Coordinacin de Desarrollo en el Punto de Venta

contribuye positivamente afianzar el liderazgo de los productos y marcas de Cervecera Polar C.A a. Muy de acuerdo b. De acuerdo c. Ni de acuerdo ni en desacuerdo d. En desacuerdo e. Muy en desacuerdo 12. La Coordinacin de Desarrollo en el Punto de Venta desea reflejar una imagen

positiva antes sus clientes y consumidores a. Muy de acuerdo b. De acuerdo c. Ni de acuerdo ni en desacuerdo d. En desacuerdo e. Muy en desacuerdo 13. Considera que la Coordinacin de Desarrollo en el Punto de Venta trabajar en

el futuro en la creacin y diseo de estrategias de mercadeo de alto impacto a. Muy de acuerdo b. De acuerdo c. Ni de acuerdo ni en desacuerdo d. En desacuerdo e. Muy en desacuerdo

14.

Considera usted que la coordinacin del Territorio Oriente Sur se posicionar

a mediano plazo como una unidad slida con procedimientos y funciones bien definidas. a. Muy de acuerdo b. De acuerdo c. Ni de acuerdo ni en desacuerdo d. En desacuerdo e. Muy en desacuerdo 15. La Coordinacin de Desarrollo en el Punto de Venta se enfoca en satisfacer

las necesidades y gustos de sus consumidores. a. Muy de acuerdo b. De acuerdo c. Ni de acuerdo ni en desacuerdo d. En desacuerdo e. Muy en desacuerdo

HOJAS METADATOS Hoja de Metadatos para Tesis y Trabajos de Ascenso - 1/6

INGENIERA DE REQUISITOS PARA PROCESOS DE EJECUCIN DE ESTRATEGIAS DE MERCADEO (IMPULSOS Y FACHADAS), COORDINACIN DE DESARROLLO EN EL PUNTO DE VENTA CERVECERA POLAR C.A TERRITORIO COMERCIAL ORIENTE SUR.

Ttulo

Subtitulo El Ttulo es requerido. El subttulo o ttulo alternativo es opcional. Autor(es) Apellidos y Nombres Sarabia D., Karinthia L.

Cdigo CVLAC / e-mail CVLAC e-mail e-mail CVLAC e-mail e-mail CVLAC e-mail e-mail 19.078.215 skarinthia@gmail.com

Se requiere por lo menos los apellidos y nombres de un autor. El formato para escribir los apellidos y nombres es: Apellido1 InicialApellido2., Nombre1 InicialNombre2. Si el autor est registrado en el sistema CVLAC, se anota el cdigo respectivo (para ciudadanos venezolanos dicho cdigo coincide con el nmero de la Cedula de Identidad). El campo e-mail es completamente opcional y depende de la voluntad de los autores.

Palabras o frases claves: Modelo de Negocio, Ingeniera de Requisitos, Metodologa Gray Watch, Aplicacin Empresarial.
El representante de la subcomisin de tesis solicitar a los miembros del jurado la lista de las palabras claves. Deben indicarse por lo menos cuatro (4) palabras clave.

Hoja de Metadatos para Tesis y Trabajos de Ascenso - 2/6 Lneas y sub lneas de investigacin: rea Sub-rea Tecnologa (Ciencias Aplicadas) Ingeniera de Sistemas

Debe indicarse por lo menos una lnea o rea de investigacin y por cada rea por lo menos un subrea. El representante de la subcomisin solicitar esta informacin a los miembros del jurado.

RESUMEN La presente investigacin tuvo como objetivo desarrollar la ingeniera de requisitos de aplicacin empresarial para la gestin, control y seguimiento de los procesos de ejecucin de estrategias de mercadeo (Impulsos y Fachadas) en la Coordinacin de Desarrollo en el Punto de Venta en Cervecera Polar C.A Territorio Comercial Oriente Sur. El tipo de investigacin es de carcter proyectivo y nivel comprensivo. Las tcnicas e instrumentos de recoleccin de datos fueron la observacin directa, la revisin documental, las entrevistas no estructuradas y el cuestionario con el propsito de obtener informacin confiable, basndose en el anlisis de contenido como tcnica de procesamiento de la informacin. Para el cumplimiento de los objetivos planteados se utiliz la metodologa de desarrollo de software Gray Watch conjuntamente con el Lenguaje Unificado de Modelado (UML). El estudio comprende un anlisis profundo de procesos tcnicos: Modelo de Negocio e Ingeniera de Requisitos propuestos por la metodologa. La ingeniera de requisitos formulada propone una solucin para disear y construir una aplicacin empresarial que atienda las necesidades planteadas en la coordinacin con la finalidad de automatizar los procesos Impulsos y Fachadas. Se plantea un sistema desarrollado bajo ambiente web que permita mejorar el procesamiento de manera eficaz de las estrategias requeridas. Palabras claves: Modelo de negocio, Ingeniera de requisitos, Metodologa Gray Watch, Aplicacin Empresarial.

Hoja de Metadatos para Tesis y Trabajos de Ascenso - 3/6 Contribuidores: Apellidos y Nombres Cdigo CVLAC / e-mail CA AS TU ROL Chaparro Jess CVLAC e-mail e-mail ROL Morales Anantonieta CVLAC e-mail e-mail ROL Daz Roger CVLAC e-mail e-mail ROL Zerpa Marlene CVLAC e-mail e-mail CA 15.511.946 mazerpa@udo.edu.ve AS TU JU CA 9.901.823 rogercab321@gmail.com AS TU CA 8.281.117 anantonietam@gmail.com AS TU 4.526.369 jchaparro@udo.edu.ve

JU

JU

JU

Se requiere por lo menos los apellidos y nombres del tutor y los otros dos (2) jurados. El formato para escribir los apellidos y nombres es: Apellido1 InicialApellido2., Nombre1 InicialNombre2. Si el autor est registrado en el sistema CVLAC, se anota el cdigo respectivo (para ciudadanos venezolanos dicho cdigo coincide con el nmero de la Cedula de Identidad). El campo e-mail es completamente opcional y depende de la voluntad de los autores. La codificacin del Rol es: CA = Coautor, AS = Asesor, TU = Tutor, JU = Jurado.

Fecha de discusin y aprobacin: Ao Mes Da 2011

Lenguaje: spa

06

10
Requerido. Lenguaje del texto discutido y aprobado, codificado usando ISO 6392. El cdigo para espaol o castellano es spa. El cdigo para ingles en. Si el lenguaje se especifica, se asume que es el ingls (en).

Fecha en formato ISO (AAAA-MM-DD). Ej: 2005-03-18. El dato fecha es requerido.

Hoja de Metadatos para Tesis y Trabajos de Ascenso - 4/6 Archivo(s): Nombre de archivo Tipo MIME Tesis Karinthia Sarabia Microsoft Office Word 2007

Caracteres permitidos en los nombres de los archivos: A B C D E F G H I J KLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwx yz0123456789_-. Alcance: Espacial: __________________ (opcional) Temporal: __________________ (opcional) Ttulo o Grado asociado con el trabajo: Ingeniero de Sistemas Dato requerido. Ejemplo: Licenciado en Matemticas, Magister Scientiarium en Biologa Pesquera, Profesor Asociado, Administrativo III, etc Nivel Asociado con el trabajo: Pre-Grado

Dato requerido. Ejs: Licenciatura, Magister, Doctorado, Postdoctorado, etc. rea de Estudio: Tecnologa (Ciencias Aplicadas) Usualmente es el nombre del programa o departamento. Institucin(es) que garantiza(n) el Ttulo o grado: Universidad de Oriente Ncleo Monagas Si como producto de convenciones, otras instituciones adems de la Universidad de Oriente, avalan el ttulo o grado obtenido, el nombre de estas instituciones debe incluirse aqu.

Hoja de metadatos para tesis y trabajos de Ascenso- 5/6

Hoja de Metadatos para Tesis y Trabajos de Ascenso - 6/6 Derechos: Artculo 41 del REGLAMENTO DE TRABAJO DE PREGRADO (vigente a partir del II Semestre 2009, segn comunicado CU-034-2009): Los Trabajos de Grado son de exclusiva propiedad de la Universidad, y solo podrn ser utilizados a otros fines, con el consentimiento del Consejo de Ncleo Respectivo, quien deber participarlo previamente al Consejo Universitario, para su autorizacin.

___________________ AUTOR

_________________ TUTOR