PROPUESTA METODOLÓGICA PARA LA ADAPTACIÓN DE LOS SISTEMAS DE INFORMACIÓN DE UNA ORGANIZACIÓN A NUEVOS MARCOS LEGALES.CASO DE ESTUDIO C.

Transcripción

1 REPÚBLICA BOLIVARIANA DE VENEZUELA UNIVERSIDAD NACIONAL ABIERTA VICERECTORADO ACADÉMICO INGENIERÍA DE SISTEMAS (236) CENTRO LOCAL METROPOLITANO (01) PROPUESTA METODOLÓGICA PARA LA ADAPTACIÓN DE LOS SISTEMAS DE INFORMACIÓN DE UNA ORGANIZACIÓN A NUEVOS MARCOS LEGALES.CASO DE ESTUDIO C. HELLMUND S.A - LEY DE RECONVERSIÓN MONETARIA Proyecto presentado como requisito para optar al Título de Ingeniero en Sistemas Autor: Pedro Herrera Ripepi Tutora Académica: Ing. Judit Carvallo Tutor Empresarial: Lic. Luis Zapiain, MBA Caracas, Diciembre de 2010

2 REPÚBLICA BOLIVARIANA DE VENEZUELA UNIVERSIDAD NACIONAL ABIERTA VICERECTORADO ACADÉMICO INGENIERÍA DE SISTEMAS (236) CENTRO LOCAL METROPOLITANO (01) PROPUESTA METODOLÓGICA PARA LA ADAPTACIÓN DE LOS SISTEMAS DE INFORMACIÓN DE UNA ORGANIZACIÓN A NUEVOS MARCOS LEGALES. CASO DE ESTUDIO C. HELLMUND S.A - LEY DE RECONVERSIÓN MONETARIA Autor: Pedro Herrera Ripepi Tutora Académica: Ing. Judit Carvallo Tutor Empresarial: Lic. Luis Zapiain, MBA Caracas, Diciembre

3 PROPUESTA METODOLÓGICA PARA LA ADAPTACIÓN DE LOS SISTEMAS DE INFORMACIÓN DE UNA ORGANIZACIÓN A NUEVOS MARCOS LEGALES. CASO DE ESTUDIO C. HELLMUND S.A - LEY DE RECONVERSIÓN MONETARIA Resumen El desarrollo de aplicaciones ha sido parte de la sociedad moderna por los últimos 60 años. En la actualidad existe una gran diversidad de metodologías destinada para la gestión de proyectos de desarrollo sistemas de información. Algunas organizaciones, inclusive, han creado versiones adaptadas de estas metodologías para el desarrollo de sus sistemas. Sin embargo, la mayoría reconocen la presencia básica de dos tipos de metodologías: livianas y pesadas. Las metodologías pesadas, mejor conocidas como tradicionales en la manera como desarrollan soluciones, sustentan su apoyo en una planificación exhaustiva, documentación detallada y diseño expansivo. En contraste, las metodologías livianas, también conocidas como modelado ágil, en años recientes, han recaudado mayor atención por la comunidad de ingenieros involucrados con el desarrollo de sistemas. A diferencia de los métodos tradicionales, las metodologías agiles utilizan ciclos iterativos más cortos, y dependen más del conocimiento tácito de los miembros del equipo que del documentación. A través del presente trabajo de investigación, se exploraran las características de ciertas metodologías tradicionales así como de unas agiles que se aplican ampliamente en el desarrollo de sistemas de información. Se determinaran las bases comparativas para la evaluación de las debilidades y fortalezas entre las metodologías y se presentara una propuesta metodológica práctica y viable para abordar la adaptación de los sistemas de información. Para sustentar el trabajo de investigación, se consultaran e investigarán diversas fuentes para determinar cuál de las metodologías es más apropiada y flexible a ser adaptada para abordar la adaptación de sistemas de información. Finalmente, la propuesta metodológica diseñada será aplicada a un caso estudio para abordar la adaptación de los sistemas de información ante cambios en los marcos legales, específicamente el proceso de Reconversión Monetario en la Organización. Palabras Claves: metodología, adaptación, sistemas Información,PIECES. 4

4 INDICE GENERAL LISTA DE FIGURAS... 8 LISTA DE TABLAS... 9 LISTA DE ANEXOS INTRODUCCION CAPITULO I EL PROBLEMA PLANTEAMIENTO DEL PROBLEMA OBJETIVOS Objetivo General Objetivos Específicos ALCANCE CAPITULO II MARCO REFERENCIAL BASES TEORICAS Bases Legales Sistema de Gestión Empresarial La Organización C. Hellmund y Cia., S.A BASES METODOLOGICAS Metodología Método Técnica Procedimiento Herramientas Diseño Estructurado (SD) Ciclo de Vida de Desarrollo de Sistemas (SDLC) Análisis Orientado a Objeto (OOA) Proceso Racional Unificado (RUP) Programación Extrema (XP) Desarrollo Rápido de Aplicaciones (RAD)

5 PIECES CAPITULO III MARCO METODOLOGICO Y RESULTADOS ANALISIS DEL SISTEMA Investigación sobre las Metodologías Caracterización de las Metodologías Comparación de las Metodologías Elementos de Comparación Según PIECES Limitaciones de las Metodologías Tradicionales Limitaciones de las Metodologías Agiles Evaluación de las Metodologías PROPUESTA METODOLOGICA Planificación del Sistema Análisis del Sistema Diseño del Sistema Implementación del Sistema Validación y Soporte CAPITULO IV APLICACIÓN DE LA METODOLOGIA PROPUESTA Planificación del Sistema Identificación de Necesidades (IDN) Análisis de Viabilidad del Proyecto (AVP) Análisis del Sistema Inventario General del Sistema (IGS) Análisis de Impacto en las Aplicaciones (AIA) Análisis de Impacto Global e Interrelaciones (AIG) Diseño del Sistema Diseño Técnico General (DTG) Implementación del Sistema Adaptación del Sistema de Información (ASI) Pruebas Generales de Integración (PGI) Validación y Soporte

6 CAPITULO V CONCLUSIONES Y RECOMENDACIONES REFERENCIAS BIBLIOGRÁFICAS ANEXOS

7 CAPITULO I LISTA DE FIGURAS Figura II.1 Arquitectura Modular de un ERP Figura II.2 Ciclo de Vida del Diseño Estructurado Figura II.3 Ciclo de Vida del Desarrollo de Sistemas Figura II.4 Ejemplo Diagrama Caso-de-Uso Figura II.5 Ciclo de Vida de Vida del Análisis Orientado a Objetos Figura II.6 Síntesis del RUP Figura II.7 Síntesis de la Programación Extrema Figura II.8 Ciclo de Vida de RAD Figura II.9 Flujo de Trabajo en las fases de RAD Figura III.1 Conclusión de Proyectos Figura III.2 Uso de Características y Funcionalidades Figura III.3 Esquema General de la Evaluación Figura III.4 Gráfico Comparativo de Prestaciones Figura IV.1 Flujo del Proceso de Reconversión Figura IV.2 Mapa de Interrelación de Módulos con Contabilidad Figura IV.3 Flujograma General del Mecanismo de Reconversión

8 LISTA DE TABLAS Tabla II.1 Sistema de Clasificación de Requerimientos PIECES Tabla III.1 Comparación Fase Metodologías Modernas Tabla III.2 Elementos de Comparativos Tabla III.3 Modelo de Análisis PIECES Tabla III.4 Ponderación de las Etapas de Desarrollo Tabla III.5 Identificación de las Necesidades del Proyecto Tabla III.6 Planificación y Valoración del Proyecto Tabla III.7 Elaboración del Plan del Proyecto Tabla III.8 Determinación de Esfuerzos, Medios y Costos Tabla III.9 Tareas, Actividades y Responsables Tabla III.10 Resumen Información Técnica de la Instalación Tabla III.11 Resumen Información Técnica de cada Aplicación Tabla III.12 Tareas, Actividades y Responsables Tabla III.13 Preparación y Carga de Objetos Tabla III.14 Identificación y Análisis de Campos y Variables Tabla III.15 Análisis de Impacto Global e Interrelaciones Tabla III.16 Análisis de Datos Generales de la Instalación Tabla III.17 Contraste del Análisis y Conclusiones Tabla III.18 Diseño Técnico General Tabla III.19 Estudio de Alternativas y Propuestas de Solución Tabla III.20 Definición del Entorno de Pruebas Tabla III.21 Adaptación de los Sistemas de Información Tabla III.22 Modificación y Pruebas del Sistema Tabla III.23 Pruebas Unitarias del Proyecto de Adaptación Tabla III.24 Preparación y Ejecución de Pruebas Integradas Tabla III.25 Pruebas Generales de Integración Tabla III.26 Validación y Soporte

9 Tabla IV.1 Fases de Conversión Monetaria en C. Hellmund & Cia. 104 Tabla IV.2 Lista de Sistemas Críticos de Información Tabla IV.3 Equipo de Proyecto Tabla IV.4 Asignación de Recursos Financieros Tabla IV.5 Inventario de Aplicaciones y Módulos Medulares Tabla IV.6 Inventario de la Infraestructura de la Organización Tabla IV.7 Detalle de Tablas en Dynamics SL y Punto de Venta Tabla IV.8 Cronograma de Reconversión Tabla IV.9 Reportes Comparativos de Validación Tabla IV.10 Resultados Comparativos de la Validación Tabla IV.11 Lista Cotejo de Validación de la Reconversión

10 LISTA DE ANEXOS Anexo 1 Listado Parcial Tablas en Dynamics SL Anexo 2 Listado Parcial Tablas y Campos Monetarios Anexo 3 Diagrama ER Balance Comprobación ( ) Anexo 4 Diagrama ER Balance Comprobación CXP ( ) Anexo 5 Diagrama ER Transacciones CXP ( ) Anexo 6 Diagrama ER Balance Comprobación CXC ( ) Anexo 7 Diagrama ER Antigüedad CXC (08.610) Anexo 8 Diagrama ER Valoración Inventario ( ) Anexo 9 Diagrama ER Balance Comprobación IN ( ) Anexo 10 Diagrama ER Órdenes de Compra ( ) Anexo 11 Diagrama ER Ordenes de Venta ( ) Anexo 12 Muestra del código de reconversión del Módulo CxC Anexo 13 Manual de Reconversión Monetaria Dynamics SL

11 INTRODUCCION El uso adecuado de una metodología para la administración de proyectos de sistemas de información proporciona un orden a las actividades del grupo, especifica qué es lo que se debe construir, permite dirigir y planear las áreas de los desarrolladores y del equipo, proporciona criterios para hacer seguimiento y medir las actividades así como sus resultados. Adicionalmente simplifica el mantenimiento de la aplicación, el control de la calidad del producto, y la reutilización de componentes del sistema. En consideración a los requerimientos de las organizaciones en materia de tecnologías de información y a la necesidad de racionalizar y optimizar el uso de los recursos, este documento presenta y contrasta algunas metodologías, tanto tradicionales y como agiles, para definir una propuesta metodológica que sirva como guía en la adaptación de los sistemas de información ante los cambios que pueden sufrir dado la volatilidad de un entorno altamente competitivo y cambiante o el advenimiento de nuevos marcos legales. En Venezuela en el año 2007 se promulga la Ley de Reconversión Monetaria mediante la cual el Estado Venezolano establece una nueva expresión monetaria en el país, denominada Bolívar Fuerte, la cual es equivalente al Bolívar corriente dividido entre mil, con un periodo transitorio donde las transacciones que presten servicio a los clientes y que manejen efectivo, deberán estar preparadas para ofrecer la doble expresión monetaria. 12

12 Como en el caso de C. Hellmund & Cia, S.A., los sistemas de gestión empresarial Dynamics SL 6.50, requieren adaptarse para dar cumplimiento a la mencionada Ley, lo cual incentivó esta investigación que tiene como objetivo diseñar una metodología flexible para la adaptación de los sistemas de información que facilite el manejo y control de todo el proceso de conversión, la sistematización de las actividades y la adaptación de los sistema de información de diferente índole. Como resultado, se espera definir una serie de normas, actividades y productos que sean eficientes en función de costo, tiempo y valor agregado para la organización y que además puedan ser aplicadas tal como se describe en la propuesta. así: Para tal fin, la investigación se estructuró en 5 capítulos distribuidos Capítulo I, El Problema, donde se describe el planteamiento del problema, los objetivos y alcances. Capitulo II, Marco Referencial, se detallan las Bases Teóricas de los Marcos Legales, Sistemas de Gestión Empresarial, la Organización y la reseña Histórica de C. Hellmund & Cia, S.A.; así como también sobre los aspectos y conceptos claves de las metodologías en estudio. Capitulo III, Marco Metodológico, se realiza un proceso de investigación sobre las metodologías tradicionales y agiles disponibles, sus características más resaltantes y presenta la propuesta metodológica para la adaptación de los sistemas de información. 13

13 Capitulo IV, Aplicación de la Metodología Propuesta, se usa como directriz la metodología propuesta en el capítulo anterior para adaptar los sistemas de gestión empresarial de la organización en estudio acorde a los lineamientos establecidos por la Ley de Reconversión Monetaria. Capítulo V, Conclusiones, donde se enuncian las conclusiones obtenidas del trabajo de investigación. Finalmente, se presentan las Referencias y Anexos, que comprenden los textos, informes, publicaciones, investigaciones y demás que sirvieron de base para la realización de la investigación. 14

14 CAPITULO I EL PROBLEMA 1.1. PLANTEAMIENTO DEL PROBLEMA En el escenario mundial actual, el proceso de globalización y el desarrollo de nuevas tecnologías de información y comunicación han traído consigo cambios profundos y constantes en los fundamentos teóricos que soportaban la actuación empresarial y fundamentalmente en la forma como se administran y manejan los recursos de las organizaciones de cara a los nuevos requerimientos del mercado. Variables como reducción de costos, diferenciación y flexibilidad que fueron las estrategias básicas de la industrialización son sustituidas por la capacidad de respuesta en la era del conocimiento, donde la informática se impone como la herramienta que mejora la habilidad de los gerentes para tomar decisiones mucho más oportunas y efectivas, convirtiéndose así en un componente central de toda Organización. Las tecnologías de información y comunicación son herramientas básicas para el desarrollo y competencia empresarial, pues permiten la descentralización de la toma de decisiones, ya que la información puede fluir horizontal y verticalmente de forma fácil y rápida, disminuyendo los niveles jerárquicos desde los altos ejecutivos hasta el personal operativo. Además, facilitan el manejo e integración de todos los datos, procesos y documentos requeridos por las unidades funcionales. De esta manera, la informática se convierte en una ventaja competitiva, al reducir costos de operación, incrementar la flexibilidad organizacional, rapidez en la toma de decisiones, respuesta hacia los 15

15 requerimientos del cliente, información del mercado, competencia y entorno en general, además de manejar a las diferentes unidades como un todo, con la automatización e integración de procesos y cadenas productivas mediante redes y sistemas, a través del desarrollo de software, hardware y nuevas formas de hacer las cosas, a fin de que sirvan para que la gerencia pueda definir y llevar a cabo sus estrategias de acción, de forma oportuna y eficiente. Ejemplo de ello son los cambios que por cumplimiento de la norma legal tienen que realizar las empresas a sus sistemas de información como el ingreso al nuevo milenio (2000), lo cual fue un impacto mundial, el establecimiento de una moneda única (Euro), en la Comunidad Económica Europea, y en Venezuela, la Ley del Impuesto al Valor Agregado, la Ley del Impuesto Sobre la Renta y la Ley de Reconversión Monetaria. La Ley de Impuesto al Valor Agregado, crea un impuesto territorial, que grava la enajenación de bienes muebles, servicios y la importación de bienes, que deberán pagar las personas naturales o jurídicas, y demás entes jurídicos o económicos. La Ley de Impuesto Sobre la Renta establece que se graven los enriquecimientos anuales, netos y disponibles obtenidos en dinero o en especie. Y por último, la Ley de Reconversión Monetaria, promueve la eliminación de tres (3) ceros en la moneda. Estas leyes, presentan un gran reto a los legisladores que no solo deben considerar la presencia y uso de medios tecnológicos modernos para el control y fiscalización de las leyes, sino también permitir que las distintas organizaciones adquieran y adecuen sus tecnologías de información, de acuerdo a sus posibilidades, para dar fiel cumplimiento a los requisitos y especificaciones establecidos en la Ley. En este sentido, es imperativo que las organizaciones dispongan de una metodología que fácilmente puedan adaptar a sus necesidades y que les brinden alternativas de solución tecnológica eficientes en cuanto a tiempo, 16

16 costos y resultados. Como consecuencia de lo antes planteado, las organizaciones deben adecuar continuamente sus sistemas no solo en la búsqueda eficiencia y competitividad sino también para dar cumplimiento a las nuevas normativas legales. El propósito que se persigue con este trabajo investigativo es diseñar una propuesta metodológica que facilite la adaptación de los sistemas de información a los nuevos marcos legales, aplicándola como caso de estudio a la Ley de Reconversión Monetaria en C. Hellmund & Cía S.A. En base a lo planteado con anterioridad, surgen las siguientes interrogantes: 1. Cuáles son las principales metodologías disponibles para el desarrollo y la adaptación de sistemas de información empresarial? 2. Cuáles son las características más relevantes de estas metodologías? 3. Cómo sería el diseño de una propuesta metodológica adaptable y eficiente que facilite la adaptación de los sistemas de información empresarial? 4. Cuál será el resultado al validar la propuesta metodológica diseñada con el caso de estudio C. Hellmund y Cia S.A. en la adaptación de los sistemas de información a la Ley de Reconversión Monetaria? 17

17 1.2. OBJETIVOS Objetivo General Desarrollar una propuesta metodológica para adaptar los sistemas de información empresarial al advenimiento de nuevos marcos legales Objetivos Específicos 1. Investigar sobre las distintas metodologías existentes para el desarrollo y adaptación de sistemas de información. 2. Analizar las caracteristicas de las distintas metodologías investigadas. 3. Diseñar la propuesta metodológica para la adaptación de los sistemas de información de empresa. 4. Aplicar la propuesta metodológica diseñada al caso estudio en materia de la Ley de Reconversion Monetaria. 5. Evaluar los resultados obtenidos al aplicar la metodologías diseñada ALCANCE Generar la propuesta metodológica, aplicarla a un caso estudio y evaluar los resultados de su aplicación. 18

18 CAPITULO II MARCO REFERENCIAL Está conformado por la información de primera mano donde el autor se aboca a la búsqueda investigativa de trabajos realizados con anterioridad, relacionadas directa o indirectamente con las Leyes y Reglamentos vinculados a la Ley de Reconversión Monetaria en el país, así como los fundamentos teóricos detrás de metodologías más relevantes como se detallan a continuación: 2.1. BASES TEORICAS Bases Legales Comprende las Leyes y Reglamentos que se relacionan con la Ley de Reconversión Monetaria en el país, que se detallan a continuación: Decreto con Rango, Valor y Fuerza de Ley de Reconversión Monetaria Publicada en Gaceta Oficial de la República Bolivariana de Venezuela No de fecha 6 de Marzo de 2007, expone la obligatoriedad del cumplimiento de la Ley en el Capítulo I, Disposiciones Generales: Artículo 1. A partir del 1 de enero de 2008, se reexpresa la unidad del sistema monetario de la República Bolivariana de Venezuela, en el equivalente a un mil bolívares actuales. El bolívar resultante de esta reconversión, continuará representándose con el símbolo Bs., siendo divisible en cien (100) céntimos. En consecuencia, todo importe expresado en moneda nacional antes de la citada fecha, deberá ser 19

19 convertido a la nueva unidad, dividiendo entre 1.000, y llevado al céntimo más cercano. (p.1) De igual forma, la Ley es expedita en cuanto a las sanciones establecidas por incumplimiento de la misma, como se detalla seguidamente: Artículo 9. Salvo disposición especial, los que se nieguen a efectuar la conversión contenida en el artículo 1 de este Decreto-Ley, o incumplan cualquiera de las obligaciones establecidas en el presente Decreto-Ley, serán sancionados con multa de diez unidades tributarias (10 U.T.) a diez mil unidades tributarias ( U.T.). La multa a que refiere este artículo será impuesta y liquidada por el Instituto Autónomo para la Defensa y Educación del Consumidor y del Usuario, conforme a lo establecido en la Ley de Protección al Consumidor y al Usuario. (p.3) De allí, la imperiosa necesidad de las empresas entre estas C. Hellmund & Cía S.A., de llevar a cabo la adaptación de los sistemas de información a los nuevos lineamientos que impone la Ley de Reconversión Monetaria, de cara a las satisfacción de las necesidades de la empresa y el cliente. Además de acatar los lineamientos del Banco Central de Venezuela ya que el mismo es el ente facultado para ello, tal como se detalla a continuación: Artículo 5. El Banco Central de Venezuela queda facultado para regular mediante Resoluciones, todo lo relacionado con la ejecución de la reconversión monetaria objeto del presente Decreto-Ley, así como para efectuar todas las actividades conducentes a la debida sustitución de las especies monetarias hasta la puesta en circulación de los nuevos billetes y monedas. (p.2) 20

20 Sistema de Gestión Empresarial Los sistemas de gestión empresarial (en inglés ERP, acrónimo de Enterprise Resource Planning) son sistemas de gestión de información que integran y automatizan muchas de las prácticas de negocio asociadas con los aspectos operativos o productivos de una empresa, eliminando complejas conexiones entre sistemas de distintos proveedores. Este tipo de sistemas suele presentar una arquitectura modular, donde cada módulo gestiona las funciones específicas de un área empresarial, como pueden ser: nóminas, finanzas, control de proyectos, inventarios, distribución, contabilidad, logística, pedidos, ventas, etc. Estas áreas de la empresa realizan funciones diferentes pero se interrelacionan entre sí compartiendo información. Es importante resaltar que los sistemas ERP, son integrales, es decir, una agrupación de todos los módulos que los componen, y que agrupan a su vez todos los procesos de gestión de la empresa. Gracias a la adaptabilidad de este tipo de sistemas, una empresa puede configurar su ERP para que se adapte a sus procesos de negocio. La personalización de este tipo de sistemas, junto con su modularidad y capacidad de integración de procesos, permite como veremos en un capítulo posterior una gestión completa de las operaciones. 21

21 Figura II. Arquitectura Modular de un ERP. Fuente: Elaboración propia, La Organización Popper (2002) plantea que las organizaciones son sistemas de actividad, distribuidos socialmente formados por personas, comunidades y actividades que interactúan en base a teorías de acción compartida (p.468). Las interacciones de individuos, grupos y patrones de acción se reconcilian a través de reglas, roles y herramientas que en parte son predefinidas por la organización, pero también surgen naturalmente de las prácticas sociales y técnicas del sistemas de actividad. Produciendo nuevas formas de conocer y hacer cuando se confrontan, interpretan y resuelven tensiones entre lo viejo y lo nuevo, entre el cambio y la estabilidad, modificando o creando nuevas teorías de acción, que con el tiempo se arraigan profundamente en las reglas, roles, herramientas y conceptos que actúan como mediadores entre las interacciones. 22

22 En este escenario, McGee y Prusak (2004) consideran que gran parte de la información que causa efecto en una organización, genera una posibilidad para la acción, que pasa a ser estratégica, cuando la información se activa para convertirla en comprensión y conocimiento. Esta transfiguración de la información en discernimiento, erudición y sometimiento a la acción es el objetivo del manejo de la información, para lo cual se requieren recursos, políticas y normas, así como una estructura unificadora que las aglutine. La selección y uso de fuentes para la adquisición de la información tiene que planearse, supervisarse y evaluarse continuamente, de forma tal que la misma refleje el alcance y complejidad del medio ambiente, sin abrumar a los usuarios. El uso de la información para la construcción del significado y comprensión requiere procesos y métodos que contemplen un alto grado de flexibilidad en la presentación de ésta, al tiempo que faciliten el intercambio vigoroso y evaluación de las múltiples representaciones entre los individuos. Por ende, la inteligencia de la organización es situada y mediada, es decir, se crea en la realización de tareas y en el uso de herramientas en medios ambientes físicos y sociales, se modera a través de las relaciones que vinculan a los individuos, grupos y estructuras que unen la organización con su medio ambiente externo. Por lo tanto, la organización inteligente desarrolla el conocimiento a través de tres planos fundamentales: a) Construye conocimiento como significados compartidos de lo que percibe como realidad. b) Desarrolla conocimiento como competencias ampliadas de lo que puede hacer c) Fomenta conocimiento como conductas aprendidas sobre lo que pudiese lograr. 23

23 Organización e Información La forma como las organizaciones usan la información, ha sido motivo de estudios profundos, uno de ellos fue el realizado por Choo (2002) de la Universidad de Oxford, quien plantea que la información es un componente intrínseco de todo lo que hace una organización, tanto que su función se ha vuelto transparente (p.21). En este orden de ideas, el autor expone que el pensamiento actual en teoría de dirección y organización hace énfasis en tres campos en los que la creación y uso de la información desempeñan un papel estratégico para determinar la capacidad de una organización para crecer y adaptarse. En primer lugar, la organización utiliza la información para percibir cambios y desarrollos en su medio ambiente externo, pues se desenvuelven en un mundo dinámico, incierto, donde es necesario asegurar un suministro confiable de materiales, recursos y energía. De allí, que se asuma que las fuerzas y la dinámica del mercado modulan el desempeño de la organización. Las estructuras fiscales y legales definen su identidad y ámbito de influencia. Las normas de la sociedad y la opinión pública constriñen los papeles que desempeña la empresa, así como su alcance, haciéndose necesario que se desarrolle la percepción, donde los miembros tengan una comprensión compartida de que es la organización y que está haciendo. Por otro lado, el segundo nivel del uso estratégico de la información se produce cuando las organizaciones crean, organizan, y procesan información a fin de generar un nuevo conocimiento a través del aprendizaje organizacional, el cual permite desarrollar nuevas capacidades, diseñar nuevos productos y servicios, incrementar las ofertas existentes y mejorar 24

24 los procesos. En cuanto al tercer nivel de uso estratégico de la información, se genera cuando las organizaciones evalúan y buscan información a fin de tomar decisiones importantes. Esta selección debe realizarse racionalmente, con base a una información completa sobre los objetivos organizacionales, las opciones factibles, los resultados probables de las mismas y el valor que estos tengan para la empresa. En la práctica la elección racional resulta perturbada por el forcejeo entre quienes tienen intereses, el regateo y la negociación entre grupos e individuos poderosos y la falta de información. La tesis central de Choo (2002) es que los tres campos del uso de la información, percepción, creación de conocimiento y toma de decisiones, son procesos estrechamente interrelacionados, es un ciclo continuo de aprendizaje y adaptación, al que se denomina conocimiento. Aunque la toma de decisiones por parte de la organización es un proceso complejo, no hay dudas que es una parte esencial de su vida, todas las acciones de la empresa se inician en decisiones y todas estas son compromisos para emprender una acción, de allí que Herbert (2003) afirma que dirección es toma de decisiones, por lo que el mejor modo de analizar la conducta de la organización es mediante el estudio de la estructura y los procesos de la toma de decisiones (p.56). El nuevo conocimiento es evaluado en función de la estrategia de la organización, apreciación de las capacidades modulares, estimación del potencial del mercado, la tecnología y reconocer que para hacer operacionales las innovaciones se requiere el aporte de nuevos sistemas de información en la organización. Es decir, lo que realmente constituyen el 25

25 centro de la organización es organizar y sistematizar el flujo de información, los recursos de conocimiento disponibles, las competencias y las habilidades de sus miembros. Las organizaciones están estructuradas por procedimientos y reglas que especifican roles, métodos y normas, que aligeran el procesamiento de información requerido por problemas complejos, incorporando técnicas eficientes aprendidas de la experiencia coordinando las acciones y resultados de grupos diferentes de la organización, formando hábitos sobre la adquisición y transferencia de información. Tecnologías de Información y Comunicación Actualmente las tecnologías de información y comunicación (TIC) han demostrado gran potencial estratégico y la capacidad de las empresas de reinventarse alrededor de estás. Siendo clave la visión de la alineación de las tecnologías de información con las estrategias del negocio, liderazgo y gestión de la profunda transformación que estas generan en las empresas. En este sentido, González (2002) refiere que las tecnologías de información son facilitadores del proceso de transformación de las empresas, que suelen requerir profundas innovaciones organizacionales y renovadores principios en el flujo del trabajo, con se describe seguidamente: 26

26 Figura No 1 Tipología de Iniciativas Estratégicas de las TIC Tipo de Iniciativa Impacto Estratégico Área de Impacto Procesos del Negocio Automatización de los procesos informacionales Coordinación de los procesos de información o físicos internos Coordinación de los procesos con empresas en la red de valor Mejora de la productividad al sustituir RRHH por TIC Reducción de los defectos, tiempos de ciclo y recursos. Achatamiento organizacional Integración dinámica de redes de negocio Área de Impacto Procesos Gerenciales Área de Impacto Gestión del Conocimiento Tipo de Iniciativa Apoyo a las decisiones críticas mediante modelos complejos de información gerencial Alineación de la planificación control de gestión y los incentivos Distribución de la información gerencial multidimensional entre niveles jerárquicos Tipo de Iniciativa Representación y almacenamiento del conocimiento Coordinación de los procesos de generación y divulgación del conocimiento Impacto Estratégico Mejora la calidad de decisiones y eficacia gerencial, reducción de recursos asociados a la incertidumbre Incremento de la capacidad organizacional de ejecución de las estrategias formuladas Empowerment y acatamiento organizacional Impacto Estratégico Formalización del aprendizaje y conversión del conocimiento individual en activo empresarial Distribución del conocimiento de la organización Fuente: Elaboración propia, en base a González (2002) 27

27 C. Hellmund y Cia., S.A. La firma C. Hellmund & Cía S.A., tal como lo reza documento empresarial, fue constituida el 1 de julio de Sus socios fundadores fueron los señores Gregorio Cuello, Cornelio Hellmund Spencer y Agustín Morasso. Esta firma fue la sucesora de Gregorio Cuello & Cía. La firma fue establecida en Caracas y La Guaira, y se dedicaba a dos clases de negocios, además de tener sus propias haciendas como Chuao; el primero fue la exportación de café, cacao, cueros y especies, más la importación de alimentos, licores y otros bienes de consumo inmediato; y el segundo la representación de la naviera Compagnie Générale Transatlantique, así como actuar como banca. En su trayectoria evolutiva, la citada empresa resistió las variaciones políticas venezolanas que siguieron a su constitución: el predominio del Presidente Guzmán Blanco, las actuaciones de Alcántara, Rojas Paúl y Andueza Palacios, y el largo fenómeno del Crepismo, que culmina en la Presidencia de Andrade. Entre los rubros de exportación estaban el café, el cacao, los cueros, ganado en pie, plata, oro, madera, caucho y sarrapia. La llegada de Cipriano Castro al poder coincidió con dos sucesos que afectaron los negocios de la firma: uno fue la disminución de los precios del café, que hizo mucho daño a los comerciantes venezolanos; y por otra parte, la Revolución Libertadora, que regresó, la evolución política y económica fue produciendo diversas variantes y consecuencias, como la llegada de Juan Vicente Gómez a la presidencia de la República y el cambio progresivo de la situación nacional. De igual forma, la guerra mundial de 1914 produjo una catástrofe financiera para los negociantes de café y las dificultades mercantiles producidas por la guerra imposibilitaron a esas firmas, casi todas en situación 28

28 de quiebra, el cumplir con sus obligaciones. El señor Carlos Hellmund Cuello y su hijo, Carlos Hellmund Winckelmann, se vieron en la necesidad de vender todas las propiedades de la empresa familiar para poder cumplir con sus obligaciones bancarias y financieras y de este modo, salvar su responsabilidad comercial ante sus relacionados, manteniendo así su buen nombre. La firma se sostuvo de la importación, a base de comisiones, de malta alemana y checoslovaca, utilizando para la fabricación de cervezas y de algunas otras mercancías adquiridas de exportadoras europeas, entre ellas cristal de Bohemia. Cerca de 1925 se inicia la tradición fotográfica comercial que Casa Hellmund todavía mantiene en el mercado venezolano, cuando realiza negocios con la fábrica Agfa de Berlín, y con la fábrica Leitz, de Wetzlar Alemania, comenzando así la nueva era, al entrar de lleno en el ramo de fotográfico y científico. Algunos años más tarde la empresa se mudó de nuevo a una casa bastante grande, de Torre a Veroes, donde se instaló un detal fotográfico moderno, el primero en su género en Venezuela, así como una laboratorio fotográfico donde se revelaban y copiaban películas en blanco y negro. También se distribuían al por mayor los novedosos productos fotográficos AGFA en todas las poblaciones del país. Vino luego la segunda guerra mundial y los negocios con Alemana se paralizaron totalmente, vendió el detal fotográfico de Torre a Veroes y se trasladó a un edificio propio, en la Avenida principal de Colinas de Bello Monte. Posteriormente, en 1966, Kodak de Rochester (U.S.A.), viendo la gran participación que había alcanzado su producto en el mercado venezolano, y como parte de una estrategia global de tener sus propias distribuciones, decidió instalar su empresa en Venezuela, negociando amistosamente con Casa Hellmund, y le compró la distribución que poseía. Nuevamente la 29

29 compañía se ve en la necesidad de arrancar casi desde cero al mantener algunas líneas fotográficas complementarias. Y fue cuando, en 1970, inició la representación de la firma japonesa Fuji Photo Film Co., Ltd, que hoye n día ostenta liderazgo mundial en tecnología fotográfica. Actualmente, C. Hellmund & Cía S.A. además de poseer la distribución exclusiva en Venezuela de Fujifilm, distribuye otras diversas y reconocidas marcas mundiales para aplicación en distintos campos: Leica en la División Científica; Apollo, Vivitar, Plus, Da Lite, en la División Audiovisual; Leica, Kreonite, Cromega, Metz, Mamiya, en la División Fotográfica, como también algunos productos Sony y Canon. También ofrece un excelente Servicio Técnico para los equipos que vende, lo que ha sido un aval de garantía a través de sus largos años en el mercado venezolano, cosa que no pueden igualar sus competidores, lo que complementa y asegura el éxito de su actividad comercial y, como era de esperarse, ya es pionera en la nueva tecnología de imágenes vía digital. En 1990, se crearon empresas especializadas separadas para comercializar, al detal, cadenas de tiendas de revelado rápido Laboratorios Rapidfot, que se expanden también vía franquicias, y la Distribuidora Hellmund GMS, que distribuye una gran variedad de productos para la industria gráficas, con setenta años dedicada al negocio de las imágenes, con su eslogan Siempre la mejor imagen. Misión Desde 1862 crea bienestar para los clientes, proveedores, empleados, accionistas y la comunidad, comercializando productos y servicios de alta calidad y tecnología avanzada en el mercado de imágenes e información, con un equipo humano de excelencia. Valorando la ética como principio fundamental en nuestra gestión empresarial. 30

30 Visión Es una organización con clientes, proveedores, personal y accionistas altamente satisfechos. Líder en la comercialización de productos y servicios de imagen en Venezuela, con expansión internacional, y en el mercado de imágenes. Obtener importantes alianzas con proveedores líderes de nuevas tecnologías. Lograr asociaciones con clientes claves a través de alianzas comerciales. Mantener el personal más calificado a través de incentivos, entrenamiento y planes de carrera. Un compromiso absoluto con la excelencia de servicio al cliente y el servicio técnico. Los procesos y sistemas serán cada vez más eficientes, lo cual permite ser más competitivos y flexibles. Mantener agresividad en mercadeo y ventas siendo conservadores en materia financiera. Las nuevas tecnologías (Digital, magnético) tendrán un peso importante en nuestra mezcla de productos. Lograr actividades e inversiones en otros países como parte de la realidad que vivimos en un mundo global e interconectado. Valores y Principios La organización ha implementado valores que inducen el comportamiento y las decisiones que enaltece y fortalece el ambiente humano y la sociedad, para así mantenerse unido y lograr un equipo que practica un esfuerzo en común afianzándonos en cada uno de los siguientes valores: 31

31 1. Gente: Los esfuerzos colectivos de la gente es la fortaleza, que generan inteligencia y determinan la reputación y vitalidad. Participación y trabajo en equipo son los valores principales, así como un medio ambiente de completa participación. 2. Clientes: son el centro de la organización, su satisfacción es la mayor meta, procurando mejores productos y servicios que los competidores. 3. Productos: provee productos que cumplen con las necesidades de calidad que exigen el cliente. 4. Proveedores: son tratados como socios, cultivando relaciones responsables incluso con otros negocios asociados. 5. Innovación: crecimiento y éxito requiere que la empresa sea ingeniosa e innovadora. Cada uno de sus miembros debe tomar el control para el proceso de mejoras continuas, dando ideas creativas y tomando riesgos. 6. Integridad: se actúa socialmente responsable con conciencia social. 32

32 2.2. BASES METODOLOGICAS Metodología Según Avison (2006), la metodología son los medios recomendados para desarrollar y mejorar continuamente los sistemas de información basados en un conjunto de racionales y una filosofía subyacente que apoya, justifica y unifica tales recomendaciones dentro de un contexto especifico. Tales medios generalmente incluyen la identificación de fases, procedimientos, actividades, reglas, técnicas, lineamientos, documentación y herramientas. También puede incluir recomendaciones concernientes a la administración y organización del proceso así como la identificación y entrenamiento de los participantes. Su confusión con el término método, según Checkland (1981), se presenta ya que la metodología está compuesta por un conjunto de métodos que bajo determinadas circunstancias pueden ser reducidas a un método apto exclusivo de tal circunstancia. Metodologías tradicionales Las Metodologías Tradicionales son aquellas que están guiadas fundamentalmente por una fuerte planificación durante todo el proceso de desarrollo como las metodologías estructuradas y las orientadas a objeto (Abrahamsson et al, 2002). Metodologías agiles El término Metodología Ágil se aplica a un proceso de desarrollo de software incremental (entregas pequeñas de software, con ciclos rápidos), 33

33 cooperativo (cliente y desarrolladores trabajan juntos constantemente con una cercana comunicación), sencillo (el método en sí mismo es fácil de aprender y modificar, bien documentado), y adaptable (permite realizar cambios de último momento) (Abrahamsson et al, 2002) Método Se entiende por método, el procedimiento que se emplea para alcanzar los objetivos de un proyecto (Santibáñez, 2000) Técnica El término técnica representa un conjunto de procedimientos precisamente descritos para lograr una actividad. De esta manera, la definición se centra en una "actividad", una acción específica, claramente definida y acotada, que permite alcanzar un objetivo muy específico, y que se puede alcanzar utilizando un conjunto acotado de herramientas (Santibáñez, 2000) Procedimiento El término procedimiento se refiere al modo de hacer, con orden, las cosas; es decir, como poner en práctica las herramientas. Los procedimientos corresponden a la definición que permite unir y ordenar los resultados de cada herramienta y facilitan el desarrollo racional y oportuno del software. Definen la secuencia en la que se aplican las herramientas, la entrega de los resultados de ellas, los controles que ayudan a asegurar la calidad. También coordinan y controlan los cambios y entregan las directrices que ayudan a los administradores a evaluar el progreso del proyecto (Santibáñez, 2000). 34

34 Herramientas El término herramientas se aplica a las definiciones de mecanismos manuales, semiautomáticos o automáticos que permiten analizar, diseñar o construir el software. Estas quedan estrechamente ligadas al principio rector de la metodología y es muy poco probable que una herramienta sea utilizable en otra metodología. Una herramienta debe tener un objetivo específico y un método de aplicación. Por lo general, se ha demostrado que las herramientas gráficas (que usan imágenes) son más fáciles de usar y entender que las herramientas que sólo se sustentan en textos escritos (Santibáñez, 2000) Diseño Estructurado (SD) El Diseño Estructurado, también conocido como SSADM (Structured Systems Analysis and Design Method), fue desarrollada inicialmente por Learmonth y Burchett Management Systems (LBMS) y continuada por el Central Computing and Telecommunications Agency (CCTA) mediante la adopción de un método de desarrollo de sistemas de información para el uso en los proyectos del gobierno del Reino Unido (Malcolm, 1992). El Diseño Estructurado, prosigue un esquema de avance lógico de una fase a la siguiente. Los trabajos realizados en cada fase deben ser aprobados por el promotor del proyecto (normalmente el cliente u analista de negocios en la organización) antes de continuar a la siguiente. Su rigidez e inflexibilidad conceptual hacen que la metodología sea vulnerable a las modificaciones que puedan surgir durante la etapa de desarrollo, ya que ello ocasionaría reiniciar todo el proceso de desarrollo, alterando el contrato y los acuerdos establecidos para con el cliente. 35

35 Existen dos enfoques de desarrollo con esta metodología, uno centrado en procesos y otro centrado en datos. El enfoque centrado en procesos intenta conseguir resultados desde la perspectiva de los procesos que circundan la operación del sistema, por lo que, probablemente, resultará en un sistema construido por componentes orientados al proceso. Por otro lado, el enfoque centrado en datos se concentrara en los datos utilizados por e involucrados en el sistema. La ventaja del Diseño Estructurado radica en el rigor con el cual los desarrolladores y analistas en conjunto se obligan a identificar y comprender los requerimientos del sistema mucho antes de iniciar la fase de implementación. Por el contrario, su mayor desventaja se evidencia, primero, por su incapacidad para poder retroceder a fases anteriores para efectuar cambios a la propuesta original del sistema durante el avance del proyecto y, segundo, por la carencia de mecanismos supervisión que faciliten a los usuarios observar sus avances hasta tanto el sistema no esté debidamente culminado, lo cual ocurre al final de la fase de implantación. Figura II. Ciclo de Vida del Diseño Estructurado Fuente: Elaboración propia,

36 Las fases que caracterizan las metodologías basadas en un diseño estructurado se enumeran a continuación: 1- Planificación 2- Análisis del Sistema 3- Diseño del Sistema 4- Implementación Ciclo de Vida de Desarrollo de Sistemas (SDLC) El Ciclo de Vida de Desarrollo de Sistemas de Información (SDLC Software Development Life Cycle), como su nombre lo indica, fue concebido en la década de los 1960 para construir sistemas de información de una manera muy deliberada, estructurada y metódica, reiterando cada etapa del ciclo de vida (Elliott y Strachan, 2004). SDLC es un proceso de perfeccionamiento gradual que evoluciona a través de varias fases de desarrollo donde cada fase continúa y perfecciona lo realizado con anterioridad. Comúnmente, las fases más conocidas de desarrollo en SDLC son: Planificación Es el proceso de comprensión de por qué el sistema debe ser construido y la definición de sus necesidades. También incluye el estudio de viabilidades desde perspectivas, técnicas, económicas, así como organizativos. Análisis Esta fase incluye actividades tales como la identificación y análisis del 37

37 problema así como anticipar los posibles problemas que puedan surgir a futuro en relación con el sistema. Los resultados, así como los productos de esta fase, sirven de guía en la construcción y desarrollo del sistema. Diseño El análisis del sistema conlleva decisiones de diseño, el cual determina con exactitud el funcionamiento del sistema en términos de procesos, datos, hardware, infraestructuras de red, interfaz de usuario y otros factores importantes en el entorno del sistema. Implementación Esta fase, probablemente consume más recursos, costos y tiempo de que todas las anteriores y está conformada por las etapas de construcción, pruebas e instalación. También incluye actividades de capacitación a los usuarios y de mantenimiento al sistema. Algunos expertos, prefieren segregar las fases de implementación y mantenimiento. No obstante, las cuatro fases son las más conocidas y aceptadas. El SDLC tiene como finalidad proporcionar un sistema de alta calidad que satisface o excede los requerimientos establecidos. Muchos métodos existentes fueron desarrollados con la finalidad de implementar el SDLC, incorporando mejoras sobre metodologías existentes. Aunque cada método se adhiere a ciertas técnicas y etapas, todas abordan el desarrollo de sistemas en términos de las mismas fases antes descritas. En la actualidad, existe una gran diversidad de métodos; no obstante, la mayoría de estos, fundamentalmente, son extensiones de tres metodologías: el Diseño Estructurado, el Desarrollo Rápido de Aplicaciones (RAD - Rapid Application Development), y el Análisis y Análisis Orientado a Objetos (OOA Object Oriented Analysis). 38

38 39

39 Figura II. Ciclo de Vida del Desarrollo de Sistemas. Fuente: Elaboración propia, basado en US Department of Justice (2003) 40

40 Análisis Orientado a Objeto (OOA) El Análisis Orientada a Objetos fue desarrollado por la carencia de sinergia entre los enfoques de la SDLC centrada en procesos y centrado en datos. La descomposición del sistema en términos de procesos o de datos no es fácil debido a que ambos se encuentran íntimamente interrelacionados. Como resultado, el sistema resultante tiende a inclinarse hacia una de estas opciones, y, en general, ninguno de estos puede extenderse fácilmente al ámbito del otro. El Análisis Orientado a Objetos descompone los problemas en objetos. Dichos objetos son considerados parte un sistema que contiene tanto datos como procesos, y permiten realizar actividades o procesos (método del objeto) o poseer algún tipo de estado (atributos del objeto). De esta manera, los desarrolladores pueden enfocarse en la entidad del sistema que en realidad efectúa el proceso y transporta los datos, en vez de concentrarse solamente en uno de estos. El desarrollo de sistemas Orientados a Objetos hace uso amplio de la herramienta denominada Lenguaje de Modelado Unificado (UML Unified Modeling Language), el cual es un conjunto de técnicas de diagramación y modelado inventado por Grady Booch, Ivar Jacobson, y James Rumbaugh (1999). Un enfoque de desarrollo orientado a objetos debe ser: Impulsado por Casos de Uso Esto significa que los casos-de-uso son la herramienta principal de modelado para definir el comportamiento del sistema. Los casos-de-uso describen como los usuarios interactúan con el sistema para desempeñar alguna actividad, y como ellos se enfocan en una actividad a la vez, el proceso es inherentemente más simple. 41

41 Figura II. Ejemplo Diagrama Caso-de-Uso. Fuente: Elaboración propia, Centrado en la Arquitectura El término centrado en la arquitectura significa que se provee una visión global del sistema bajo desarrollo. La arquitectura que se seleccione para sistema debe guiar las especificaciones, la construcción y la documentación del mismo. Dicha arquitectura debe ostentar las tres vistas del sistema: 42

42 Vista Funcional: Describe el comportamiento del sistema desde la perspectiva de sus usuarios generalmente con la asistencia de diagramas tipo casos-de-uso. Vista Estática: Describe la estructura del sistema en términos de clases, métodos, atributos y relaciones entre los diferentes objetos del sistema. Esta vista es tipificada mediante el uso de tarjetas CRC (Class Responsibility Collaboration), así como con diagramas de clase y objetos. Vista Dinámica: Describe el comportamiento interno del sistema en términos de la comunicación entre objetos y los cambios de estado. Herramientas como el UML, Lenguaje de Modelado Unificado, se utilizan para tipificar diagramas de secuencia, colaboración y de cambios de estado en los objetos. Iterativo e Incremental Bajo este modelo, con cada iteración del desarrollo del sistema se avanza más hacia al logro de los requerimientos pautados. Mientras que bajo la metodología SLDC el proceso de avance es gradual, la metodología de desarrollo orientado a objetos, los diagramas tipo UML, progresan de lo conceptual y abstracto durante la fase de análisis y diseño, incorporando cada vez más detalles hasta alcanzar la fase de implantación. 43

43 Figura II. Ciclo de Vida de Vida del Análisis Orientado a Objetos. Fuente: Elaboración propia, Las fases que caracterizan el Desarrollo Orientado a Objeto se enumeran a continuación: 1. Búsqueda de Clases y Objetos. 2. Identificación de Estructuras. 3. Identificación de Sujetos. 4. Definición de Atributos. 5. Definición de Servicios. 44

44 Proceso Racional Unificado (RUP) El Proceso Racional Unificado (RUP - Rational Unified Process) (Jacobson et al., 1999) es una metodología para el desarrollo de aplicaciones ideada por Rational Software y se constituyó para aplicar el UML desde sus inicios. La metodología RUP incluye fases para el desarrollo y administración de los procesos y abarca todo el ciclo de vida de desarrollo de los sistemas de información. La metodología RUP se encuentra muy bien documentada y ampliamente disponible a través de libros y guías complementarias así como sustentadas por páginas Web que proveen guías, plantillas y herramientas para todas las actividades de desarrollo. El concepto clave detrás del RUP radica en la definición de las actividades (flujo de trabajo) a lo largo del ciclo de vida de desarrollo tales como la recopilación de requerimientos, el análisis, el diseño, la implementación y las pruebas. A diferencia del proceso clásico en forma de cascada, estas actividades pueden solaparse y ejecutarse en paralelo. Dentro de cada actividad se encuentran etapas bien definidas que determinan su inicio, elaboración, construcción y transición. Si bien estas ocurren en secuencia, pueden existir múltiples iteraciones de éstas hasta que finalice el proyecto. Durante el diseño de la solución, se estimula el DBC - Desarrollo Basado en Componentes (CDB - Component Based Development). RUP promueve el desarrollo basado en componentes a través del uso de UML, el cual está fuertemente influenciado por las notaciones de UML y su enfoque de diseño. Bajo este esquema RUP concibe los componentes como una pieza poco trivial, casi independiente, y reemplazable del sistema que cumple una función clara en el contexto de una arquitectura bien definida. 45

45 Figura II. Síntesis del RUP. Fuente: Elaboración propia, Las fases que caracterizan al RUP se enumeran a continuación: 1 Modelo de Negocios 2 - Requerimientos 3 - Análisis y Diseño 4 - Implementación 5 - Pruebas 6 - Puesta en marcha 7 - Administración de configuración y cambios 8 - Administración del Proyecto 46

46 Programación Extrema (XP) La programación extrema o extreme Programming (XP) es un enfoque de la ingeniería de software formulado por Kent Beck (1999b) ante la necesidad de desarrollar sistemas de información con mayor rapidez impulsada por las necesidades cambiantes del negocio. El entorno general de los negocios se considera cada vez más competitivo, más enfocado hacia el cliente, operando en un contexto globalizado. La programación extrema (XP - Extreme Programming) ha evolucionado a partir de los problemas causados por los ciclos largos de desarrollo asociados a los modelos tradicionales (Beck, 1999a). Por contraste, el proceso XP se caracteriza por tener ciclos cortos de desarrollo, planificación incremental, retroalimentación continua, dependencia comunicacional y diseño evolutivo. Con tales cualidades, los programadores están en capacidad responder a un entorno cambiante, con mucho más valor. El término "extremo" se deriva al adoptar algunos principios y prácticas que se describen a continuación a niveles extremos (Beck, 1999b): Planificación - El programador estima el esfuerzo necesario para la ejecución de requerimientos del cliente y el cliente decide el alcance y el cronograma basado en estimaciones. Pequeñas actualizaciones - Una aplicación se desarrolla en una serie de versiones pequeñas que se actualizan regularmente. Metáfora - El sistema se define por un conjunto de metáforas entre el cliente y los programadores quienes describen cómo opera el sistema. Diseño simple El énfasis recae en el diseño de la solución más simple posible que pueda implementarse, eliminando de inmediato la complejidad innecesaria y código excedente.. Optimización Involucra la reestructuración del sistema eliminando la duplicidad, mejorando la comunicación, simplificando e 47

47 incorporando mayor flexibilidad pero alterar el funcionamiento del programa. Programación en Pares Todo el código de producción es producido por dos programadores en una computadora. Propiedad Colectiva Ninguna persona es dueño responsable de los segmento de código particular por lo que cualquiera lo puede cambiar a discreción cuando convenga. Integración Continua Tan pronto está listo, la nueva porción de código es integrada al sistema actual. Al integrar, el sistema se ensambla nuevamente y todas las pruebas deben superarse antes de aprobar los cambios realizados. Hornadas semanales de 40-horas - Nadie puede trabajar hornadas extraordinarias dos semanas seguidas. Hasta un máximo de 40 horas es permisible de lo contrario, se aborda como un problema. Cliente in situ - El cliente debe estar accesible en todo momento para el equipo de desarrollo. Estándares de Codificación Existen lineamientos para la codificación a las cuales se adhieren los programadores a fin de brindar consistencia y mejorar las comunicaciones entre los miembros del equipo de desarrollo. 48

48 Figura II. Síntesis de la Programación Extrema Fuente: Elaboración propia, El ciclo de vida de un proyecto XP se divide en seis fases: 1- Exploración 2- Planificación 3- Iteraciones a liberar 4- Producción 49

49 Desarrollo Rápido de Aplicaciones (RAD) El Desarrollo Rápido de Aplicaciones (RAD Rapid Application Development) definido por James Martin en 1991, consiste en un ciclo de desarrollo corto basado en tres fases (Requisitos, Diseño y Construcción) con un plazo de entrega ideal de 90 a 120 días como máximo y en el uso de herramientas CASE (Computer Aided Software Engineering). Tradicionalmente, el desarrollo rápido de aplicaciones tiende a englobar también la usabilidad, utilidad y la rapidez de ejecución. Según Whitten (2004), es una fusión de varias técnicas estructuradas con técnicas de modelaje para acelerar el desarrollo de software de sistemas. Bajo el enfoque, la primera fase de RAD planifica las necesidades de la aplicación en términos de los requerimientos establecidos por los usuarios de alto nivel en la organización. Durante la segunda fase, denominada fase de diseño, los usuarios con la ayuda de los analistas discuten aspectos conceptuales del diseño del sistema. Durante la fase de construcción, se llevan a cabo diversas actividades. Cualquiera que sea el producto de la fase anterior, esta se refina y mejora sistemáticamente. Tan pronto como las nuevas funciones están disponibles, se someten a los usuarios para su evaluación. Con las herramientas provistas por RAD, los analistas pueden realizar cambios continuos en el diseño de las aplicaciones. La cuarta y última fase del RAD, la fase denominada implementación se ocupa del reemplazo de aplicaciones pre-existentes. En actividades paralelas, mientras la versión anterior se encuentra ejecutándose, la nueva aplicación se somete a pruebas, se entrenan los usuarios y se modifican los 50

50 procedimientos de la organización antes de que ocurra el cambio definitivo. El objetivo principal del RAD es acortar el SDLC para responder de manera expedita los requerimientos dinámicos de la organización. El SDLC toma un enfoque mucho más metódico y sistemático a fin de garantizar la integridad y exactitud y tiene como propósito la creación de sistemas integrados a los procedimientos y cultura de la organización. La fase de diseño del RAD difiere de las fases existentes en SDLC, debido a que las herramientas empleadas por RAD se utilizan para generar pantallas y exhibir el flujo global de funcionamiento de la aplicación. De esta manera, cuando los usuarios aprueban el diseño de la aplicación, están conviviendo con una representación visual del modelo, mas no con un diseño conceptual representado en papel, como tradicionalmente se hace. La fase de implementación del RAD es, en muchas formas, menos exigentes que las otras debido a la intensa participación de los usuarios en el diseño de los aspectos de negocios del sistema. Debido a ello, existen pocas sorpresas ya que conocen perfectamente los cambios requeridos. En contraste, bajo el SDLC, los analistas se distancian de los usuarios y trascurre mucho tiempo entre la fase de diseño y desarrollo. En ese tiempo, los requerimientos pueden cambiar y el producto final puede sorprender a los usuarios si discrepa de lo anticipado meses atrás. 51

51 Figura II. Ciclo de Vida de RAD Fuente: Elaboración propia, El ciclo de vida de un proyecto RAD se divide en cinco fases: 1. Análisis 2. Diseño 3. Construcción 4. Pruebas 5. Implementación 52

52 Figura II. Flujo de Trabajo en las fases de RAD. Fuente: Elaboración propia,

53 PIECES James Wetherbe y Nicholas Vitalari (1994) desarrollaron un modelo de mucha utilidad para analizar aplicaciones y sistemas con el fin de resolver problemas, explotar las oportunidades, y satisfacer las directivas establecidas. Dicho marco referencial adopta el nombre de PIECES por sus siglas ingles que se emplean para categorizar los problemas según presentamos en la Tabla II., a continuación. Tabla II. Sistema de Clasificación de Requerimientos PIECES. Fuente: Elaboración propia,

54 El objetivo que persigue el modelo propuesto por Wetherbe es asegurar que tanto el analista de sistemas como los usuarios se involucren en el análisis de cada una de las categorías esenciales en relación con el dominio del problema y que las respuestas contribuyan significativamente a la definición de los requerimientos del sistema. En este sentido, las categorías de clasificación PIECES se describen a continuación: Prestaciones: o rendimiento abordan temas relacionados con el desempeño del sistema ante los usuarios. Aquí se consideran asuntos de rendimiento en términos de la cantidad de trabajo realizado sobre un cierto período de tiempo y el tiempo promedio de respuesta obtenido ante la solicitud o transacción iniciada por el usuario. Información: aborda aspectos íntimamente vinculados con el proceso de captura, procesamiento, presentación y almacenamiento de los datos en el sistema. Economía: se ocupa de la evolución del proyecto en términos de costos operacionales así como de cualquier otro elemento que pueda vincularse o impactar económicamente el sistema. Control: está estrechamente relacionado con cuestiones de seguridad del sistema, así como en la redacción requerida en los datos entrantes. Eficiencia: se ocupa de evaluar el grado de certeza con la que se realizan las cosas. El impacto de la eficiencia por lo general se mide en uno de tres niveles: Corporativo, departamental o individual. Servicio: aborda aspectos funcionales del sistema así como otros requerimientos relacionados con su implementación, mantenimiento, adiestramiento y documentación. 55

55 CAPITULO III MARCO METODOLOGICO Y RESULTADOS El presente trabajo se elabora bajo el tipo de investigación denominado proyecto factible apoyado en una investigación documental, el cual, según definición de la Universidad Pedagógica Experimental Libertador UPEL (2005) incluye la elaboración y desarrollo de una propuesta de un modelo operativo viable para solucionar problemas, requerimientos o necesidades de organizaciones o grupos sociales (p.16) El proyecto factible comprende un diagnóstico, planteamiento y fundamentación teórica de la propuesta, procedimiento metodológico, actividades y recursos necesarios para su ejecución, el análisis y conclusiones acerca de su viabilidad y realización. El mencionado diseño se adapta a la realización del presente trabajo pues facilita la recolección de datos primarios permitiendo ahondar sobre la problemática objeto del estudio, esenciales para el logro de los objetivos y la solución del problema planteado ANALISIS DEL SISTEMA La dificultad inherente al desarrollo y adaptación de sistemas así como su impacto en el negocio, han puesto de manifiesto las ventajas, y en muchos casos la necesidad, de aplicar una metodología formal para abordar proyectos de este tipo. El objetivo es convertir el desarrollo de software en un proceso formal, con resultados predecibles, que permitan obtener un producto final de alta calidad, que satisfaga las necesidades y expectativas del cliente. 56

56 En la actualidad existen numerosos estándares y modelos que podemos emplear como directriz. Independientemente del marco, modelo o estándar elegido como referencia, la implantación de una metodología de desarrollo de software en una organización plantea diversos retos cuya resolución está más cerca de lo humano que de lo técnico. En síntesis, podríamos decir que el éxito en la implantación de una metodología de desarrollo en una organización consiste en aplicar un enfoque de gestión del cambio (apoyo de la dirección, comunicación, formación, plazos razonables, etc.) acompañado de pragmatismo, sencillez y flexibilidad en el fondo y la forma de los procesos. Debido a la innumerable cantidad de metodologías y variantes existente, por fines prácticos, limitaremos la evaluación y análisis de las métodos a algunas de las más reconocidos como Diseño Estructurado (SD), Ciclo de Vida de Desarrollo de Sistemas (SDLC), Análisis Orientado a Objetos (OOA), Proceso Racional Unificado (RUP), Programación Extrema (XP) y Desarrollo Rápido de Aplicaciones (RAD) Investigación sobre las Metodologías Debido a la naturaleza del estudio y en función de los datos requeridos, desde el punto de vista teórico, metodológico y de la presentación del trabajo escrito, se aplicaron las técnicas de investigación documental para el análisis de las fuentes documentales, tales como, la presentación documental, presentación resumida, resumen analítico y análisis crítico. De igual manera, se aplicaron técnicas operacionales para manejar las fuentes documentales, desde una dimensión estrictamente técnica, como el subrayado, fichaje, bibliográficas, de cita y notas de referencias 57

57 bibliográficas, ampliación de texto, así como el análisis e interpretación de cuadros y gráficos Caracterización de las Metodologías En el contexto de presente análisis, las metodologías serán examinadas en términos las etapas del ciclo de vida que éstas abordan. En el ciclo de vida se identifican nueve etapas: estrategia (planificación), factibilidad, análisis, diseño lógico, diseño físico, programación, pruebas, implementación y mantenimiento. Cabe recalcar que las dimensiones empleadas para este análisis comparativo, pudiera malinterpretar aquellas metodologías que no fueron diseñadas para adecuarse a esta estructura, como en el caso de metodologías orientadas a desarrollar prototipos, en cuyo caso su comparación al modelo espiral de desarrollo sería el más conveniente. A continuación, la Tabla III. resume los resultados del análisis comparativo. Las áreas resaltadas en azul indican que la metodología aborda con cierto detalle la fase señalada, la cual puede incluir de técnicas y herramientas específicas de apoyo. Las áreas grises señalan que la metodología aborda con poco detalle y profundidad la fase. En estos casos hay menos dirección por parte de la metodología y mayor responsabilidad por parte de los desarrolladores en la interpretación y realización de las actividades. Las áreas rayadas indican que las fases son mencionadas brevemente por la metodología sin proporcionar procedimientos, técnicas o lineamientos aun cuando reconoce que dicha fase debería ser abordada. El señalamiento que una metodología abarca o aborda una fase no significa necesariamente que exista una fase denominada así, sino más bien la presencia de elementos que pueden agruparse en fases equivalentes. 58

58 Tabla III. Comparación Fase Metodologías Modernas. METODOLOGIA FASE SD SDLC OOA XP RUP RAD Estrategia Factibilidad Análisis Diseño Lógico Diseño Físico Programación Pruebas Implementación Evaluación Mantenimiento Fuente: Elaboración propia, Abreviaturas: SD - Diseño Estructurado, SDLC - Ciclo de Vida, OOA - Análisis Orientado a Objetos, RUP - Proceso Relacional Unificado, XP - Programación Extrema, RAD Desarrollo Rápido de Aplicaciones En el análisis comparativo, la estrategia es utilizada para indicar si la metodología trata aspectos relacionados al contexto empresarial, y aborda la estrategia, propósito y planificación de los sistemas de información como un todo y no solo como un área de interés o sistema aislado. RAD se señala que aborda el tema con algún detalle, SD y SDLC menor detalle y RUP menor aun. 59

59 La siguiente fase, la factibilidad se define como la evaluación económica, social, y técnica del sistema bajo consideración. SD y SDLC incluyen aspectos detallados para la evaluación mientras que RUD y RAD también lo abordan pero de manera no tan exhaustiva. La fase de análisis, la cual incluye los análisis de requerimientos de los usuarios, se aborda con detalle, aunque en una amplia variedad de maneras, por todas las metodologías. Las fases de diseño lógico se abordan en detalle por todas las metodologías. El diseño físico se aborda en detalle por todas las metodologías excepto por el OOA y XP, la cual lo hacen de manera menos explícita. A próxima fase que identificamos es la del desarrollo físico del sistema caracterizado por la programación o codificación. Solo las metodologías SDLC, XP, RAD y RUP cubren la programación. Otras metodologías asumen o sugieren que existen otras formas para el desarrollo físico del sistema, por lo cual no se incluyen. Las pruebas, las cuales abarcan la planificación así como las pruebas de los sistemas, programas y procedimientos, son realizadas en las metodologías XP, RAD y RUP, pero en mayor grado de detalle en las últimas. La implementación, donde incluimos la planificación e incorporación de aspectos técnicos, sociales y organizacionales, lo abordan SD, SDLC y RAD. Por otro lado, RUP trata en detalle los aspectos técnicos, pero no así los aspectos sociales y organizacionales. La evaluación y revisión post implementación que mide y evalúa el sistema implementado contra los objetivos establecidos originalmente lo aborda RAD y RUP pero en menor detalle SD y SDLC. 60

60 La fase final del análisis es el mantenimiento, en ella asumiremos que es abordada por la metodología solo si está contemplada explícitamente como una actividad. El hecho que el mantenimiento en general pueda mejorarse por el uso de la metodología en fases anteriores no se considerará como formalmente abordada por ésta. En este sentido, solo SDLC y RAD lo contemplan Comparación de las Metodologías La existencia de un gran número de metodologías y las necesidades imperativas que tienen las empresas por abordar y concluir exitosamente los proyectos de desarrollo u adaptación de los sistemas de información, hacen que el mero proceso de selección de aquella que más se adecué a sus realidades sea un trabajo titánico. Las particularidades de cada metodología dificultan la creación de patrones comparativos que aborden objetivamente esta tarea sin favorecer más a unas que a otras. Generalmente, los procesos comparativos en las metodologías se ven influenciados por razones académicas mientras que otros por razones prácticos. En la primera, su motivación es comprender mejor la naturaleza de las mismas (sus características, objetivos, filosofía y demás) para así clasificarlas y mejorar el desarrollo de sistemas de información; Entre tanto, la segunda, su objetivo es seleccionar una metodología, parte de ella, o un número de metodologías para abordar una aplicación específica, un grupo de aplicaciones, o toda una organización. A los fines de facilitar el proceso comparativo, consideraremos los elementos propuestos por David Avison y Guy Fitzgerald (2006) que 61

61 presentamos en la Tabla III. y que exponemos posteriormente. 62

62 Tabla III. Elementos de Comparativos Fuente: Elaboración propia,

63 1 - Filosofía La filosofía es un aspecto importante de la metodología ya que ésta abarca todos los demás elementos, y la distingue, más que otros criterios, de otras metodologías. La elección de las áreas cubiertas por la metodología, los sistemas, los datos u orientación de las personas, el sesgo o inclinación hacia una solución meramente tecnológica, así como otros aspectos se materializa en bases a la filosofía bajo la cual se ampara la metodología. La filosofía puede ser explicita, no obstante en la mayoría de los caso es implícita. En este contexto, consideramos la filosofía como un principio o conjunto de estos, que sustenta la metodología. Como guía se exploraran cuatro factores relevantes de la filosofía: paradigma, objetivos, dominios, y la aplicabilidad Paradigma La idea de paradigma está asociada con la formulación presentada por el científico Thomas Kuhn en su libro "La Estructura de las Revoluciones Científicas" (1962). Aquí, la define como aquello que se debe observar y escrutar; el tipo de interrogantes que es necesario formular para hallar respuestas en torno de un objetivo; la estructuración de dichos interrogantes; y la interpretación de los resultados científicos. De esto se desprende que, el paradigma constituye básicamente un modelo de cómo deben realizarse investigaciones y experimentos científicos, con la concepción de que dicho modelo pueda replicarse. Sin embargo, en la práctica científica un paradigma trasciende el modelo experimental para responder a la manera en que los agentes del campo científico entienden, piensan y hacen ciencia. 64

64 1.2 - Objetivos Por lo general, el objetivo u objetivos establecidos por la metodología pueden ser representativos de la filosofía. Los objetivos por alcanzar pueden ser diversos, no obstante el propósito primordial es determinar si la meta radica es construir un sistema de información, o mejorar y rediseñar los procesos de negocio en la organización. Esto representa una diferencia importante ya que delimita el radio de acción Dominio El tercer factor relacionado con la filosofía es el dominio de las situaciones abordadas por la metodología. A diferencia con interpretaciones pasadas, la más reciente nos señala que para solventar problemas individuales, es necesario analizar toda la organización con la finalidad de diseñar una estrategia generalizada de los sistemas de información, segregando los datos y los recursos, e identificando las áreas que se solapan y las aquellas que requieren integración. En esencia, se requiere realizar un análisis vertical de la organización, para determinar los requerimientos estratégicos del negocio y de esta manera garantizar que los sistemas de información estén diseñados para apoyar los requerimientos fundamentales Aplicabilidad El último factor de la filosofía es su aplicabilidad. Cuando algunas metodologías están orientadas específicamente para abordar determinados problemas, entornos, u organizaciones de diferentes tipos o tamaños, otras son más generalizadas. 65

65 2 - Modelo El segundo elemento del marco comparativo involucra un análisis del modelo al cual la metodología se adhiere. El modelo representa la percepción que tiene la metodología del mundo y constituye tanto una abstracción como una representación de los factores más relevantes del sistema de información o de la organización. El modelo trabaja en tres niveles: primero, representa un medio de comunicación; segundo, es un medio para capturar la esencia del problema o del diseño, de tal manera que pueda traducirse a otra forma sin pérdida de detalle; y tercero, el modelo es una representación que provee detalles del problema o área de preocupación. El modelo puede clasificarse en cuatro tipos distintivos: a) Verbal b) Analítico o matemático c) Icónico, pictórico o esquemático d) Simulación Los modelos asociados a las metodologías de los sistemas de información son en su mayoría del tercer tipo. La razón primordial del dominio actual de los modelos icónico, pictórico o esquemático es la importancia del uso de los modelos para la comunicación, particularmente entre usuarios y analistas. Otros aspectos de importancia en el desarrollo de sistemas de información es asegurar que toda la información necesaria sea capturada, en la etapa apropiada, y que esta información sea la indispensable para desarrollar el sistema requerido. 66

66 3 - Técnicas y Herramientas Un elemento clave del marco comparativo es la identificación de las técnicas y herramientas empleadas en las metodologías. Siendo esto tan relevante en el proceso, en el Marco Referencial se presenta una definición precisa de lo que constituyen desde la perspectiva de los sistemas los procedimientos, las técnicas y las herramientas 4 - Alcance El cuarto elemento del marco comparativo es el alcance de la metodología. El alcance reseña las etapas del ciclo de vida de los sistemas de información empleadas por la metodología, así como un su nivel de detalle. Cabe destacar que no todas las metodologías adoptan la estructura propuesta por SDLC, pudiendo adoptar un modelo más interactivo, evolutivo o espiral. 5 - Entregables El próximo elemento en el marco comparativo son los entregables de la metodología. Es importante conocer cuál es el producto de la metodología en cada etapa y, particularmente, la naturaleza del producto final. Esto pudiera variar desde un análisis de especificaciones hasta la implantación de un sistema con todos sus procedimientos. 6 - Práctica El penúltimo elemento en el marco comparativo se denomina la práctica y se mide acorde a: (a) los antecedentes del metodología (en términos comerciales o académicos); (b) base de usuarios (número y tipos de usuarios); (c) participantes en la metodología y su calificación. 67

67 7 - Producto El último elemento describe lo que se obtiene al adquirir una metodología. La mayoría de las metodologías poseen una amplia gama de productos y servicios disponibles, que pueden seleccionarse de acuerdo a las necesidades del proyecto u organización. Así mismo, el producto puede cambiar rápidamente en el tiempo, principalmente debido a la gran variedad de las herramientas disponibles. El producto puede proporcionar desde una colección de manuales hasta a un conjunto de pruebas y libros académicos. Otros productos, como RUP, cuentan con un repertorio de documentos, libros y especificaciones que se complementan con la disponibilidad de páginas web multimedia. Algunas metodologías requieren consultores, facilitadores, y adiestramiento, mientras que otras, ofrecen certificados de competencia Elementos de Comparación Según PIECES Bajo estos preceptos, adaptaremos los elementos del modelo de análisis PIECES para facilitar la comparación de las metodologías en términos de sus particularidades y capacidades para el desarrollo u adaptación de los sistemas de información. La Tabla III., presentada a continuación, resume el modelo de análisis PIECES propuestos por Wetherbe y Vitalari combinados con los elementos de evaluación propuestos por Avison y Fitzgerald. 68

68 Tabla III. Modelo de Análisis PIECES Elementos P I E C E S 1. Filosofía X 2. Modelo X 3. Técnicas y Herramientas X 4. Alcance X 5. Entregables X 6. Práctica X 7. Producto X X Fuente: Elaboración propia, De acuerdo con estos, a continuación estableceremos los criterios que se aplicaran para evaluar las metodologías seleccionadas. 69

69 Limitaciones de las Metodologías Tradicionales La diferencia primordial entre las metodologías agiles y tradicionales es la aceptación del cambio, lo cual a menudo determina el éxito o el fracaso de un proyecto (L. Williams y A. Cockburn, 2003). Las metodologías tradicionales detienen la funcionalidad del producto y rechazan los cambios. Sin embargo, una de los pilares filosóficos que motivan la adopción de metodologías agiles es su respuesta a los cambios durante cualquier etapa del proyecto. Por ello, se hace difícil implementar un proceso predecible o proveer requerimientos en un entorno volátil e inestable. Michael Dell complementa los anterior diciendo, "... la única constante es el cambio" (citado en First eworkshop on Agile Methods, 2003). Martin Fowler y Jim Highsmith fundadores del manifiesto ágil mencionan que, "facilitar el cambio es más eficaz que intentar evitarlo. Por otra parte, Boehm (1988) y Jones (1997) concluyen, por su larga experiencia, que más del 25% de los requerimientos de un proyecto cambian. Durante el año 2005, el Grupo Standish condujo un estudio de investigación donde se realizaron 365 encuestas sobre proyectos en empresas importantes en el segmento de grandes industrias. Sus resultados indicaron que el 16,2% de los proyectos culminaron en tiempo y acorde a presupuesto, satisfaciendo todas las características y funcionalidades especificadas. No obstante, el 52,7% de los proyectos culminados excedieron el presupuesto y tiempo estimado, ofreciendo menos características y funcionalidades. El 31,1% de los proyectos restantes fueron cancelados en algún momento durante el ciclo de desarrollo (véase Figura III.). El estudio también revela que las tres razones fundamentales para el éxito de un proyecto son la participación de los usuarios, el apoyo ejecutivo, y una declaración clara de los requerimientos. 70

70 Figura III. Conclusión de Proyectos Fuente: Elaboración propia, Otra limitación de las metodologías tradicionales está asociada al manejo de la complejidad. Según el ex director general de Visa International (citado en el estudio realizado por Standish Group, 2005), "La complejidad de las reglas y regulaciones promueven un comportamiento simplemente estúpido. Intentar planificar todo y luego acogerse al plan funciona bien en ambientes estables y menos complejos, pero en entornos más grandes y complejos, se el plan desmorona. La solución al problema radica en la simplicidad, por lo cual Dee Hock dice que la Simplicidad, propósito y principios claros promueven la inteligencia y los comportamientos complejos (citado en Agil Manifesto, 2001). Algunas empresas aplican reglas simples para sobrevivir mercados complejos y turbulentos. Según Kathleen Eisenhardt (2001), profesor en Stanford University, el éxito radica en 2 reglas simples (citado en Strategy as Simple Rule, 2001). Primera, desarrollar un método simple para analizar las 71

71 debilidades y fortalezas de la organización. Segunda, administrar la reducción de actividades innecesarias e involucrar a los usuarios en reuniones para abordar los problemas y oportunidades. Entonces si alguna idea valiosa aparece, se aplica sin importar su fuente. Otro hallazgo realizado por el Grupo Standish revela que 45% de las bondades y funcionalidades presentes en las aplicaciones jamás se utilizan (véase Figura III.). Esto constituye otra de las razones por la cual el diseño y la codificación debe ser lo más simple posible ya que casi la mitad de las aplicaciones y complementos agregados nunca fueron requeridos. Figura III. Uso de Características y Funcionalidades Fuente: Elaboración propia, Kathleen Eisenhardt (2001) también sugiere que en lugar de seguir procesos complejos, es más efectivo aplicar reglas simples para comunicar la estrategia y así empoderar a los individuos para aprovechar las oportunidades fugaces en mercados cambiantes. Con reglas simples, los equipos de trabajo son capaces de mejorar, continuamente, los procesos y 72

72 productos sin la supervisión detallada o el uso de procesos complejos. Los procesos de Manufactura Eficiente así como Gestión de Calidad Total tienen un conjunto de reglas efectivas que han sido comprobados durante las últimas dos décadas en el desarrollo de sistemas de información. Mary Poppendieck (2001) demuestra cómo las metodologías ágiles siguen las mismas reglas a diferencia de las metodologías tradicionales. A continuación presentamos una sinopsis de las analogías entre los procesos de Manufactura Eficiente, la Gestión de Calidad Total y las Metodologías agiles. 1. Eliminar desperdicio: Eliminar todo aquello que no agregue valor al cliente. 2. Proporcionar Calidad: Validar continuamente todos los supuestos a lo largo del proceso. Si una métrica o práctica no tiene valor, desecharla. 3. Crear Conocimiento: Aplicar ciclos iterativos cortos para proveer retroalimentación rápida y constante para garantizar que el enfoque se encuentra sobre los aspectos correctos. 4. Diferir Compromisos: Dilatar las decisiones hasta que se disponga de suficientes criterios para tomar la decisión. 5. Entregas Rápidas: Minimizar el tiempo que demora identificar el problema y entregar el sistema (o funcionalidad) que lo corrige. 6. Respetar las Personas: Potenciar el equipo para ser exitoso. 7. Optimizar el Todo: Constituir equipos multidisciplinarios para evitar omitir aspectos importantes posiblemente críticos del problema y del sistema diseñado para resolverlo. Estudios independientes realizados por el Grupo Standish demuestran contundentemente que los procesos fundamentales de las metodologías agiles como: desarrollos iterativos cortos, retroalimentación y pruebas 73

73 rápidas continuas así como el desarrollo incremental, mejoran drásticamente la calidad de los sistemas de información. El Grupo Standish concluye en su informe que los tres factores más importantes para el éxito de un proyecto radican en el apoyo ejecutivo, la participación del usuario y la experiencia en la gestión de proyectos. Las metodologías agiles se sustentan por el talento y las habilidades de los individuos y ajustan los procesos hacia individuos y equipos específicos, a diferencia de las metodologías tradicionales donde las tareas y los roles se asignan a los individuos (indiscriminadamente) esperando que lo desempeñen debidamente. Una de las grandes creencias entre los promotores de los procesos agiles es que los individuos responden y trasmiten ideas más rápido cuando se comunican cara a cara que con la escritura y lectura de la documentación, en las metodologías tradicionales. Según lo anterior el factor más importante es la "comunicación". Otro argumento entre las metodologías ágiles y tradicionales es el grado del éxito del proyecto. Un proyecto tradicional considera exitoso una entrega a tiempo y acorde a lo presupuesto. Sin embargo, los seguidores de metodologías agiles determinan su éxito cuando el valor obtenido por el sistema es mayor a lo invertido en él. Según Martin Fowler (2000), "Un proyecto predecible procederá según lo planificado pero un proyecto ágil construirá algo diferente y mejor a lo que se previó originalmente en el plan Limitaciones de las Metodologías Agiles La limitante fundamental de las metodologías agiles es el manejo de grandes equipos de trabajo. Cockburn y Highsmith (2001) en su artículo 74

74 Desarrollo de Sistemas Agiles: Factor Humano concluyen que "el desarrollo ágil es más difícil para equipos de mayores dimensiones... cuanto más crecen más crítico es el factor comunicación. Constantine (2001) y Fowler (2000), también opinan que bajo proyectos agiles la comunicación se desmorona, dificulta y complica en equipos con más de 20 desarrolladores. En contraste, las metodologías tradicionales, con sus mecanismos de planificación, se acoplan mejor en proyectos de gran escala. Barry Boehm (2002) expresa cierto grado de desacuerdo con el primer principio del manifiesto ágil, el cual establece que: "La prioridad más alta es satisfacer al cliente mediante la entrega la oportuna y continua de sistemas que agregan valor. El señala que El énfasis sobre las entregas preliminares de sistemas de gran tamaño puede ocasionar mayor trabajo si la arquitectura no es la apropiada. También argumenta que los procesos orientados a la planificación son más necesarios cuando se desean garantías sobre las soluciones. Igualmente, Scott Ambler (2002), fundador de la metodología ágil, menciona que Dudaría al aplicar modelado ágil para el desarrollo de sistemas críticos. Los objetivos de los procesos tradicionales como la previsibilidad, la repetitividad y la optimización son característicos del desarrollo de sistemas críticos confiables y seguros. La mayoría de los procesos agiles no soportan la evolución sistemática ni las inspecciones de código tradicional a lo largo del ciclo de vida, ya que su énfasis recae en la programación en pares y la evaluación informal como mecanismo para el control de calidad. No obstante, Martin Fowler (2000) menciona que los procesos agiles proveen una solución factible solo para sistemas de negocio. Alistair Cockburn y Jim Highsmith (2001) enfatizan que los aspectos claves para el éxito de un proyecto dependen de factores humanos como la amabilidad, el talento, la habilidad y la comunicación. Boehm (2002) comenta que estadísticamente el 49,9999 por ciento de los desarrolladores del mundo 75

75 están por debajo de las calificación promedio requeridas. Larry Constantine (2001) continua afirmando que, "... Todos los métodos ágiles ponen énfasis sobre la disponibilidad de personal altamente calificado". Aun cuando las metodologías agiles no requieren, en general, de personas calificadas, dependen más del conocimiento de los miembros del equipo que del conocimiento escrito en forma de documentación. Boehm (2002) explica que esto puede conducir a errores arquitectónicos que no pueden detectarse con facilidad debido a la carencia de documentación. Por contrario, las metodologías tradicionales mitigan este riesgo invirtiendo en arquitecturas y planes sustentados por el ciclo de vida que facilitan su evaluación aun cuando puedan ser obsoletos o costosos de implementar si se produce algún cambio. El debate sobre si las metodologías agiles requieren o no personas creativas y hábiles para ser eficientes, desemboca sobre otro argumento. El uso de personas calificadas puede hacer que casi cualquier cosa suceda y el tipo de metodología específica no es importante cuando se trabaja con personas calificadas. Esto sugiere que el éxito de los procesos ágiles se atribuye a la conformación de un equipo calificado, en lugar de buenas prácticas y principios. Alistair Cockburn (2001) concuerda con este argumento, pero explica: "Si las personas involucradas con el proyecto son lo suficientemente buenos, cualquier proceso se puede aplicar para alcanzar su misión. Por contrario, si las personas son las inadecuadas, ningún proceso reparara sus deficiencias ". Los defensores de los procesos agiles creen fehacientemente en el enfoque de las metodologías orientadas-a-personas en contraste con las orientadas-a-procesos. Las metodologías ágiles enfatizan la participación del cliente y lo consideran parte fundamental del equipo de desarrollo a lo largo de todo el proceso. La investigación realizada por el Grupo Standish determina, que en la opinión de los Gerentes de Tecnología, el segundo factor de relevancia en 76

76 el éxito del proyecto es la participación del usuario. De acuerdo con Boehm (2002), "Los procesos ágiles son más efectivos cuando los clientes participan de manera dedicada con el equipo de desarrollo, y cuando su conocimiento es lo suficientemente amplio para abordar en sistema". Nuevamente, el riesgo recae en la falta de conocimiento sobre las metodologías tradicionales, éste riesgo se reduce con la incorporación de la documentación, planificación, y evaluación de expertos independientes que compensan la negligencia del cliente in-situ. El producto y la documentación es otro aspecto que atrae mucha polémica sobre las metodologías ágiles. Se requiere alguna documentación? Y de ser así, Cuánta es suficiente? Scott Ambler (2002) señala, "Las organizaciones demandan más documentación que la requerida, y ella representa una forma de comunicación inapropiada. También comenta que la documentación caduca y se actualiza sólo "cuando tiene un doliente. No obstante, la documentación es mecanismo necesario para mantener información vital en el tiempo. Barry Boehm (2002) menciona: "Un proyecto bien documentado facilita a los auditores el diagnóstico de los problemas". Omitir la documentación incrementa el riesgo del proyecto cuando se consideran aspectos de mantenimiento y uso, especialmente si se asume que los miembros del equipo de desarrollo permanecerán juntos hasta el final del proyecto. Según los voceros de la comunidad de procesos ágiles, las metodologías agiles son el camino para el diseño y funcionalidad de la interfaz del usuario en el sistema. Cuando se trata sobre el diseño de interfaz de usuario, los procesos ágiles prefieren formas simplistas o prototipos iterativos en papel en lugar de diseño basado en modelos. Como uno de ellos, Constantino Larry señala que el proceso orientado a usuarios califica como una metodología ágil, ya que proporciona un esquema efectivo y eficiente de diseño de interfaces de gran utilidad para el usuario. 77

77 Evaluación de las Metodologías Para los efectos del presente trabajo, se limitará la evaluación de las metodologías a su alcance dentro del ciclo de vida según lo expuesto por David Avison y Guy Fitzgerald (2006) ( Tabla III. ). Bajo este esquema de evaluación, cada uno de los elementos PIECES se le asignará un rango de puntuación que puede variar de 0 a 10. Los valores más bajos corresponderán con aquellos aspectos que denoten una mejor apreciación de los elementos evaluados en términos de velocidad, calidad de las especificaciones y documentación producida y flexibilidad para adaptar las metodologías a los requerimientos del ámbito organizacional. En este contexto, los elementos de PIECES se interpretan como de define a continuación: Prestaciones: rendimiento en términos de la cantidad de trabajo realizado sobre cierto periodo de tiempo y el tiempo promedio de respuesta obtenido ante la solicitud o actividad realizada por el usuario según la metodología. Información: cantidad de información requerida por los procesos de análisis, diseño, y documentación de la metodología. Economía: evolución de la metodología en términos de costos operacionales así como de cualquier otro elemento que pueda vincularse o impactar económicamente. Control: Control sobre la información y requerimientos necesarios en sobre los datos entrantes. Eficiencia: certeza con la que se realizan las cosas y su impacto sobre la eficiencia. Servicio: Flexibilidad en la adaptación de la metodología en aspectos relacionados su implementación, mantenimiento, adiestramiento y documentación. 78

78 Figura III. Esquema General de la Evaluación Fuente: Elaboración propia, En este orden de ideas, acorde a las características específicas del proyecto, se ponderaran las diferentes fases del ciclo de vida como se presenta a continuación: 79

79 Tabla III. Ponderación de las Etapas de Desarrollo METODOLOGIA RAD FASE SD SDLC OOA XP RUP Estrategia Factibilidad Análisis Diseño Lógico Diseño Físico Programación Pruebas Implementación Evaluación 4 Mantenimiento 6 TOTAL Fuente: Elaboración propia, Una vez totalizadas las ponderaciones por metodología acorde al elemento PIECES evaluado, se invierte cada uno de los totales mediante la función f(x) = 1/x y se grafican en conjunto de manera radial para apreciar visualmente las diferencias para el elemento evaluado. Con ellos podremos observar el desempeño de las metodologías en términos de sus fortalezas y debilidades. 80

80 Figura III. Gráfico Comparativo de Prestaciones Fuente: Elaboración propia, De manera similar, cada uno de los elementos restantes PIECES (Información, Economía, Control, Eficiencia y Servicio) pueden evaluarse acorde a las ponderaciones asignadas por el ente evaluador para cada metodología en cada fase del ciclo de vida de desarrollo. Finalmente, la comparación de los diferentes gráficos podría dar un indicio claro de las metodologías más favorables para abordar el proyecto. 81

81 3.2. PROPUESTA METODOLOGICA El presente trabajo tiene como finalidad estructurar una metodología flexible para adaptar los sistemas de información en una organización a nuevos marcos legales. Bajo este enfoque, la propuesta asume también los Lineamientos Tecnológicos para el Adaptación de los Sistemas y Tecnologías de Información basados en la Reconversión Monetaria expuestos en la Gaceta Oficial No de Junio Por otro lado, para que la propuesta represente una solución específica a la problemática de estudio, la misma se sustenta sobre la base de los requerimientos detectados en el diagnóstico de la situación actual. En consecuencia con los resultados obtenidos en la sección anterior, y del estudio de las bondades irrefutables que goza cada una de las metodologías evaluadas, a continuación presenta su estructura general con características predominantes del Ciclo de Vida de Desarrollo: 1. Planificación del Sistema: que cuenta con la Identificación de Necesidades (IDN) y el Análisis de Viabilidad del Proyecto (AVP). 2. Análisis del Sistema: que cuenta con el Inventario General de Componentes del Sistema de Información (IGS), el Análisis de Impacto en las Aplicaciones (AIA) y Análisis de Impacto Global e Interrelaciones (AIG). 3. Diseño del Sistema: que cuenta con el Diseño Técnico General (DTG). 4. Implementación del Sistema: que incluye la Adaptación del Sistema de Información (ASI), Pruebas Unitarias del Sistema (PUS) y Pruebas Generales de Integración (PGI). 82

82 5. Validación y Soporte: donde se dará soporte al mantenimiento e incidencias que puedan producirse. Pudiendo realizar pruebas complementarias, las cuales debido a sus condicionantes técnicos debieron posponerse, como es el caso de las aplicaciones que reciben valores monetarios de otros sistemas que no habían finalizado su conversión. Además de probar la comunicación de los sistemas de la empresa con otros externos, que inicialmente tenían puentes temporales. Así también se realizará el mantenimiento de las aplicaciones en el período inicial de funcionamiento. Se vigilará que los nuevos desarrollos cumplan con los criterios establecidos y de ser necesario se ejecutarán las acciones de contingencias previstas Planificación del Sistema Las actividades y tareas de la metodología serán descritas en cada una de las fases descritas con anterioridad, comenzando con la Identificación de las Necesidades (IDN), cuyo objetivo fundamental es determinar las necesidades, objetivos, alcances y viabilidad del proyecto. Seguidamente se detallan, una serie de formatos que facilitan y sistematizan los esfuerzos requeridos dentro del proceso de adaptación y que sirven de gran apoyo al equipo de proyecto, toda vez que en los mismos además de resumir las actividades y tareas a cumplir identifican los responsables de cada una de ellas, facilitando el control sobre la gestión del proyecto de forma consolidada y los reportes de avances a la Dirección de la organización. 83

83 Identificación de Necesidades (IDN) Como parte fundamental del proceso de planificación, esta fase determina necesidades, problemas, oportunidades y directivas que propician el proyecto, ponderándolos en función de los beneficios, prioridad, urgencia y visibilidad de los mismos. Así mismo, también es de interés establecer las limitaciones del proyecto, tales como los plazos, inversión máxima y tecnología a emplear. Tabla III. Identificación de las Necesidades del Proyecto Tarea Actividades Identificación de Necesidades Determinar necesidades, problemas, oportunidades y directivas. Evaluación de beneficios, prioridad, urgencia y visibilidad. Determinar limitaciones. Fuente: Elaboración propia,

84 Análisis de Viabilidad del Proyecto (AVP) En este mismo orden de ideas, está la Análisis de Viabilidad del Proyecto (AVP) con el propósito de conducir los estudios económicos, operacionales, técnicos, legales, contractuales o políticos que proporciona información crítica para realizar la planificación del proyecto y establecer los mecanismos de priorización y control del proyecto, como se describe a continuación: Tabla III. Planificación y Valoración del Proyecto Tarea Actividades Elaboración del Plan de Proyecto Determinación de Esfuerzos, Medios y Costos Plan general del proceso de desarrollo Valoración del proceso de desarrollo Fuente: Elaboración propia,

85 Tabla III. Elaboración del Plan del Proyecto Tarea Actividades Producto Elaboración del Plan Definir con detalle el desarrollo preliminar del proyecto Planificación del Proyecto contemplando, fechas de inicio y finalización, puntos de control y responsables Fuente: Elaboración propia, 2010 Tabla III. Determinación de Esfuerzos, Medios y Costos Tarea Actividades Producto Determinación de Esfuerzos, Medios y Costos Valoración económica del proyecto los sistemas de información así como la distribución en el tiempo de la misma. Estimación y organización de los recursos, detallando los equipos de trabajo, medios técnicos necesarios para cada fase del proyecto teniendo en cuenta los entornos de desarrollo y pruebas. Valoración del proyecto Fuente: Elaboración propia,

86 Análisis del Sistema Inventario General del Sistema (IGS) El propósito del Inventario General de Componentes del Sistema de Información (IGS), es recabar un inventario exhaustivo de los componentes de los sistemas existentes en la instalación. Con este fin, se realizaran reuniones de trabajo entre los integrantes calificados de la Gerencia de Tecnología y Sistemas con la finalidad de obtener toda información necesaria para realizar la carga de las aplicaciones con todos sus componentes en un entorno de prueba en el que estén contenidos todos los elementos de los sistemas de información antes mencionados. Tabla III. Tareas, Actividades y Responsables Tarea Actividades Responsable Recabar Información de la Instalación y las aplicaciones Información Técnica de la instalación Información técnica de cada una de las aplicaciones Gerente de Tecnología y Sistemas Analistas de Soporte Sénior y Junior Fuente: Elaboración propia,

87 Tabla III. Resumen Información Técnica de la Instalación Tarea Actividades Características técnicas generales de la instalación Información Técnica de la Instalación Número de aplicaciones Relación de aplicaciones de la instalación Fuente: Elaboración propia, 2010 Estándares de nomenclatura de la instalación Tabla III. Resumen Información Técnica de cada Aplicación Tarea Actividades Recopilación detallada de cada aplicación Nomenclatura para nombrar cada programa, rutinas y resto de elementos de la aplicación Información Técnica de las Aplicaciones Número de programas, rutinas, archivos, copias, mapas Librerías donde se encuentre los fuentes, objetos, mapas Interrelación con otras aplicaciones, internas o externas Fuente: Elaboración propia, 2010 Antigüedad y particularidades de la aplicación Frecuencia y porcentaje habitual de mantenimiento de la aplicación Documentación y posible existencia de fuente 88

88 Análisis de Impacto en las Aplicaciones (AIA) Por otro lado, se hace necesario especificar el Análisis de Impacto en las Aplicaciones (AIA), el cual tienen como propósito conocer con exactitud y precisión la situación en que se encuentran tanto las aplicaciones como los objetos que la integran con respecto a la adaptación de los sistemas de información, basándose en los datos obtenidos en la actividad anterior. Para tal fin, se realizaran una serie de tareas a nivel de campos y codificación para determinar el grado impacto, tal como se detalla seguidamente: Tabla III. Tareas, Actividades y Responsables Tarea Actividades Responsable Preparación y Carga de Objetos Inventario de componentes del sistema Gerente de Tecnología y Sistemas Identificación y Análisis de Campos y Variables Monetarias Datos generales de cada aplicación Detalle de cada Objeto Propuestas técnicas de alternativas para la adaptación de las aplicaciones Analistas de Soporte Sénior y Junior Fuente: Elaboración propia,

89 Tabla III. Preparación y Carga de Objetos Tarea Actividades Producto Preparación y Cargas de Objetos Instalación de la herramienta elegida Configuración inicial de los analizadores de código y filtros lógicos Inventario de componentes del sistema mediante: Incorporación de herramientas de evaluación de los objetos en la instalación sujetos al análisis, así como la preparación de los analizadores o exploradores de la misma Fuente: Elaboración propia,

90 Tabla III. Identificación y Análisis de Campos y Variables Tarea Actividades Producto Identificación y Análisis de Campos y Variables Monetarias Exploración de campos requeridos e identificados progresivamente a lo largo de la actividad mediante los siguientes pasos: Detección Automática: Uso de analizadores sintácticos de código y exploradores o filtros lógicos Detección Manual: Uso rutinas de validación de campos monetarios en la base de datos Detección del resto de Componentes Afectados Exploración interna de las aplicaciones según los elementos previamente identificados Información detallada por aplicación por tipo de objeto, número de objetos de cada tipo afectados y porcentaje de afectación de cada tipo de objeto. Información detallada de los elementos de cada objeto y grado de afectación. Alternativas para la adaptación de cada aplicación y su prioridad técnica. Fuente: Elaboración propia, 2010 Así también, se utiliza la técnica de análisis sintáctico, pues tiene como ventaja, que proporciona identificaciones y datos estadísticos más fiables y propagar los resultados, pero su uso es específico para cada lenguaje de programación, además de la exploración como complemento. 91

91 Análisis de Impacto Global e Interrelaciones (AIG) En este mismo escenario, se tiene el Análisis de Impacto Global e Interrelaciones (AIG), cuyo objetivo es proveer una visión general del conjunto de aplicaciones de la instalación y de la magnitud del problema. Para ello, se analizan los datos obtenidos en las actividades anteriores y simultáneamente se constatan los resultados obtenidos con los responsables asignados, como se detalla a continuación: Tabla III. Análisis de Impacto Global e Interrelaciones Tarea Actividades Análisis General de Datos en las Aplicaciones Datos generales de la instalación Mapa de la relación entre Aplicaciones Elementos coincidentes entre las Aplicaciones Relación General de Aplicaciones y Componentes Contraste del Análisis y Conclusiones Propuesta técnica de alternativas para la adaptación de la instalación Análisis de impacto en Componentes y Datos Análisis de Riesgo Fuente: Elaboración propia,

92 Tabla III. Análisis de Datos Generales de la Instalación Tarea Actividades Producto Identificación y Análisis de Campos y Variables Monetarias Entrevistas con los responsables de las aplicaciones para realizar el inventario para dimensionar debidamente el problema Elaboración del modelo de relaciones entre las diferentes aplicaciones para cuantificar los cambios requeridos Análisis de los datos directos y complementarios para cuantificar las tareas e identificar posibles inconsistencias Resumen de las características principales de la instalación. Mapa de relación entre aplicaciones, distinguiendo elementos afectados y no afectados Elementos coincidentes entre aplicaciones, elementos y componentes compartidos por las distintas aplicaciones. Relación general de aplicaciones y componentes, donde se obtenga el inventario final de la instalación Fuente: Elaboración propia,

93 Tabla III. Contraste del Análisis y Conclusiones Tarea Actividades Producto Contraste del Análisis y Conclusiones Contraste con los responsables de las aplicaciones de aspectos cuyas definiciones sean insuficiente; tales como: Características y volúmenes de código, fuente y objeto, compiladores, librerías, sistemas operativos, aplicaciones de terceros y herramientas de desarrollo. Interrelación de las aplicaciones Interfaces del sistema y aplicaciones externas Propuesta técnica de las alternativas de adaptación. Análisis de impacto en componentes y datos, con resumen cuantitativo del grado de afectación que permita una visión del conjunto del impacto del cambio en la instalación Análisis de Riesgos, con resumen de las conclusiones alcanzadas en el análisis de riesgo en el diagnóstico, que se ha complementado o modificado como consecuencia de una nueva información aportada durante esta tarea. Fuente: Elaboración propia,

94 Diseño del Sistema Diseño Técnico General (DTG) Siguiendo el mismo enfoque, se expone el Diseño Técnico General (DTG), cuyo objeto es definir detalladamente el proceso de desarrollo de las aplicaciones, estableciendo la normativa, el desarrollo y control de cambios, y la definición de entorno de desarrollo y pruebas. Se concretan las reglas de funcionamiento y el entorno operativo necesario para ser eficiente en el desarrollo de los procedimientos y de las herramientas que facilitan el proceso de adaptación de los sistemas de información, como se desglosa a continuación: Tabla III. Diseño Técnico General Tarea Actividades Estudio de Alternativas y Propuestas de Solución Definición del Entorno de Pruebas Diseño técnico para la adaptación Referencia general de pruebas Fuente: Elaboración propia,

95 Tabla III. Estudio de Alternativas y Propuestas de Solución Tarea Actividades Producto Estudio de Alternativas y Propuestas de Solución Establece el control técnico del proceso de adaptación, sistema de gestión de configuración de los componentes lógicos (software) coordinando y controlando los cambios en el desarrollo. Definir la normativa. Estudiar las alternativas establecidas Determinar el entorno en el cual se desarrolla el proyecto. Reglas y mecanismos de desarrollo de base de datos y archivos. Configuración de herramientas para el control y seguimiento de las fuentes modificadas. Herramientas y métodos para el desarrollo. Sistemas básicos precisos conforme a la configuración de equipos, herramientas y utilidades adoptadas. Diseño técnico para el desarrollo, con la recopilación de las decisiones y criterios de carácter general para el desarrollo como; control, normativa, entorno Estrategias y técnicas de desarrollo de sistemas Fuente: Elaboración propia,

96 Tabla III. Definición del Entorno de Pruebas Tarea Actividades Producto Definición del Entorno de Pruebas Diseño de los requerimientos generales delas pruebas. Tipo de errores o problemas a controlar. Definición del entorno de las pruebas. Reglas y mecanismos de desarrollo de la base de datos y archivos para la prueba. Configuración de las librerías de soporte a las fuentes modificadas. Herramientas y métodos para las pruebas. Sistemas básicos conforme a la configuración de equipos y utilidades. Especificación de la planificación de las pruebas en paralelo de las aplicaciones, como requisito a considerar ante la eventual división en módulos de las aplicaciones Formatos para registrar los resultados de las pruebas Referencia general de pruebas Descripción de los criterios para la realización de las pruebas y de su entorno de ejecución Fuente: Elaboración propia,

97 Implementación del Sistema Esta fase tiene como objetivo adaptar los sistemas de información acorde a las pautas y prioridades definidas en la planificación. Para garantizar la coexistencia entre los entornos de mantenimiento y adaptación de la aplicación, se establecerá un sistema de comunicación bidireccional para con los responsables que garantice que las modificaciones efectuadas en los sistemas sean notificadas y aplicadas en los nuevos diseños. De igual forma, esta fase está compuesta por la Adaptación de los Sistemas de Información (ASI), Pruebas Unitarias del Sistema (PUS) y Pruebas Generales de Integración (PGI), las cuales se exponen seguidamente: Adaptación del Sistema de Información (ASI) Tabla III. Adaptación de los Sistemas de Información Tarea Actividades Desarrollo y Pruebas del Sistema Componentes probados unitariamente Cuadernos de carga de componentes e interfaces Fuente: Elaboración propia, 2010 Pruebas, resultados y sus expedientes 98

98 Tabla III. Modificación y Pruebas del Sistema Tarea Actividades Producto Adaptación de cada uno de los componentes Adaptación y Pruebas del Sistema Modificaciones de copias o componentes similares Modificaciones de mapas Modificaciones de programas Elaboración de los juegos de pruebas Pruebas unitarias de los programas Desarrollo de programas de conversión de archivos y base de datos Diseño y elaboración de puentes o interfaces con otros elementos Diseño de la estructura del código, tanto de las modificaciones de los componentes, puentes e interfaces de nueva creación. Código fuente de componentes y probados individualmente. Recopilación de los juegos de pruebas y de los resultados de las mismas e incorporación al expediente. Fuente: Elaboración propia,

99 Pruebas Unitarias del Sistema (PUS) En este escenario, surgen también las Pruebas Unitarias del Sistema (PUS) cuyo objeto es realizar las pruebas integradas del sub-proyecto, como se detalla a continuación: Tabla III. Pruebas Unitarias del Proyecto de Adaptación Tarea Actividades Preparación y Ejecución de las Pruebas Unitarias Equipo lógico probado Pruebas, resultados y sus expedientes Fuente: Elaboración propia, 2010 Tabla III. Preparación y Ejecución de Pruebas Integradas Tarea Actividades Producto Preparación y Ejecución de las Pruebas Integradas Pruebas unitarias de las aplicaciones para comprobar su funcionalidad acorde a las especificaciones técnicas. Pruebas de las contrapartes en producción, para garantizar el correcto funcionamiento de las adaptaciones Código fuente de aplicaciones adaptadas y probados. Recopilación de las pruebas, sus resultados y su incorporación al expediente de pruebas Fuente: Elaboración propia,

100 Pruebas Generales de Integración (PGI) Por último, se conducen las Pruebas Generales de Integración (PGI), mediante la cual se asegura la correcta integración y funcionamiento de las adaptaciones introducidas en las aplicaciones, datos y sistemas, de acuerdo a las especificaciones técnicas establecidas, de la siguiente forma: Tabla III. Pruebas Generales de Integración Tarea Actividades Producto Preparación y ejecución de las pruebas de integración Prueba de aceptación Puesta en producción progresiva Compilación de aplicaciones Pruebas y resultados Puesta en operación del Sistema Procedimientos de producción Código de objetos probados integradamente para cada aplicación Sistema aceptado Sistema operando Integración de todos los componentes, incluidos los archivos o bases de datos comprendidos en proyecto y en el entorno de producción. Procedimientos de producción. Puesta en marcha definitiva de los procedimientos de producción y aplicaciones, o módulos de éstas, incluidas en el proyecto Fuente: Elaboración propia,

101 Validación y Soporte En esta fase proporciona soporte al mantenimiento e incidencias que pueden producirse y para garantizar el máximo nivel de confianza se debe realizar una simulación lo más cercana posible a la realidad. Para este propósito se acometen las siguientes acciones: Tabla III. Validación y Soporte Acciones Actividades Pruebas Complementarias Comunicación con Sistemas Externos Mantenimiento de Aplicaciones Nuevos Desarrollos Acciones del Plan de Contingencias Aquellas que por sus condicionantes técnicos específicos, fueron pospuestos Vigilar que la solución momentánea sea sustituida por la definitiva y verificar la adaptación de la conexión Facilita la corrección y calidad de la documentación generada para cada aplicación a lo largo de todo el proceso, las cuales se integran al plan de mantenimiento perfectivo de aplicaciones existente Control del cumplimiento de los criterios en todos los nuevos desarrollos de aplicaciones que se realicen. Si se detectan problemas se aplican las acciones previstas en el plan de contingencias Fuente: Elaboración propia,

102 CAPITULO IV APLICACIÓN DE LA METODOLOGIA PROPUESTA C. Hellmund & Cía S.A. es una empresa con más de ciento cuarenta y cinco años de historia en Venezuela, distribuidora de los productos afamados el campo audiovisual, científico, fotográfico y gráfico, que debe adaptar los sistemas de información a la Ley de Reconversión Monetaria (2007) implantada por el Estado venezolano a propósito del establecimiento del Bolívar Fuerte, que básicamente elimina tres ceros a la unidad monetaria anterior el Bolívar, para facilitar la comprensión, uso y manejo del dinero. Ante el impacto de tal Ley sobre su operatividad y los sistemas de información es imperativo que la empresa cuente con una metodología diseñada a su medida que le facilite alternativas para su adaptación que sean eficientes en cuanto a tiempo, costos y resultados. Seguidamente, presentamos las etapas de la propuesta metodológica aplicada para la adaptación de los sistemas de información de C. Hellmund & Cía S.A., las cuales se desarrollaran con más detalles en las secciones subsiguientes, acode a sus necesidades: 103

103 Tabla IV. Fases de Conversión Monetaria en C. Hellmund & Cia. Fases Concepto Acciones I Planificación Aplicación, validación y análisis de la Lista de Cotejo para identificar la situación a modificar Situación actual de los sistemas de información. Valoración de los sistemas de información. Planificación del Proyecto de Adaptación. II Análisis del Impacto Aplicación, validación y análisis de la Lista de Cotejo para identificar el impacto de la adaptación Inventario de los componentes de los sistemas de información. Impacto en las aplicaciones Valoración de la conversión III Conversión y Prueba Aplicación de la Metodología Propuesta Desarrollo de los cambios Pruebas de integración IV Validación y Soporte Aplicación de la Metodología Propuesta Mantenimiento de las modificaciones en el período inicial de funcionamiento Mantenimiento de las aplicaciones para validar la calidad de la documentación generada, para cada aplicación a lo largo de todo el proceso de adaptación Fuente: Elaboración propia,

104 4.1. Planificación del Sistema Identificación de Necesidades (IDN) Ante la directiva establecida por la Ley de Reconversión Monetaria (2007), la empresa C. Hellmund & Cia, S.A. se encuentra en la obligación de adaptar los sistemas críticos de información acorde a los lineamiento fijados por el Banco Central de Venezuela. Según esta, para el momento de su publicación, se establece un lapso de 10 meses, es decir el 1 de enero del 2008, para que todas las actividades y transacciones económicas se expresen en la nueva moneda, el Bolívar Fuerte. Con la finalidad de determinar el alcance y las limitaciones de las adaptaciones requeridas en las aplicaciones, se realiza un diagnóstico preliminar mediante la aplicación, validación y análisis de los sistemas críticos de información que se muestran a continuación: 105

105 Tabla IV. Lista de Sistemas Críticos de Información Aplicación SI NO 1 - ERP Dynamics SL 6.50 X - Módulo Contabilidad X - Módulo Cuentas por Cobrar X - Módulo Cuentas por Pagar X - Módulo Inventario X - Módulo de Ventas X - Módulo Compras X - Módulo Activo Fijo X - Módulo Conciliación Bancaria X 2 - Punto de Venta X 3 - Sistema de Nómina X 4.- Sistema de Ajuste Fiscal X Fuente: Elaboración propia, 2010 La lista confirma que el sistema ERP Dynamics SL 6.50 y Punto de Venta requieren ser adaptados, ya que los mismos constituyen el esquema medular de los movimientos relacionados con la facturación y venta de los productos y servicios ofrecidos por la empresa en el mercado nacional. También se comprobó que dichos sistemas manejan campos monetarios sensibles a la aplicación de la regla de redondeo establecida por el Banco Central de Venezuela por lo que es necesario tomar en cuenta el efecto de neutralidad y el principio de Homogeneidad, a fin de que el total coincida con la suma de los detalles de la factura. 106

106 Por otro lado, debido a la imposibilidad de alterar las estructuras de datos para albergar simultáneamente ambas expresiones monetarias, Bolívares y Bolívares Fuertes, se replicaran las estructuras para segregarlas. En cuanto al Sistema de Nomina y el Sistema de Ajuste Fiscal se refiere, estas no necesitan del desarrollo de alguna herramienta de conversión puesto que las casas de distribución dispondrán de una Análisis de Viabilidad del Proyecto (AVP) La aplicación de la metodología propuesta para la adaptación de los sistemas de información en la empresa aplicada a la Ley de Reconversión Monetaria en Venezuela, se debe a que la misma surge como una necesidad sentida de la organización, ante esta imposición legal, pues hace eficiente dicho proceso en función de tiempo, costo y valor agregado para la empresa y el cliente. Esta propuesta es cónsona con los planes estratégicos de la organización ya que ésta le permite mejorar la capacidad interna y oportunidad de respuesta ante esta exigencia legal, dado que su prioridad es adaptar los sistemas de información a la Ley de Reconversión Monetaria de forma inmediata a fin de evitar conflictos y retrasos en las actividades operativas de rutina, como Nómina, Punto de Ventas y aquellas que maneja el ERP Dynamics SL 6.50, sino por el contrario que esta adaptación se convierta en una ventaja competitiva. Por otro lado, este proyecto se considera factible, dado que cumple los requisitos desde el punto de vista financiero, operativo y técnico. Operativamente, la empresa cuenta con el recurso humano especializado necesario para diseñar y poner en práctica la metodología propuesta a fin de adaptar los sistemas de información de C. Hellmund & Cía S.A. a la Ley de 107

107 Reconversión Monetaria como se describe seguidamente: Tabla IV. Equipo de Proyecto Cnt Cargo Funciones 1 Gerente de Tecnología y Sistemas Administrar y coordinar los proyectos, recursos y actividades del área, así como de alinear las soluciones tecnológicas a las necesidades de la empresa 1 Administrador de Redes e Infraestructura Instalar, mantener, y resguardar los activos de información (equipos, sistemas operativos, aplicaciones y enlaces de comunicación) 1 Analista de Soporte Sénior Brindar soporte técnico y operativo a los distintos usuarios que interactúan con los distintos módulos instalados del ERP Dynamics SL Analista de Soporte Junior Brindar soporte técnico y operativo, en campo, a las diversas tiendas operando con el Sistema de Punto de Venta Fuente: Elaboración propia con Datos de C. Hellmund & Cía S.A.,

108 Acorde a la información recabada y los análisis preliminares realizados sobre las aplicaciones e infraestructura por la Gerencia de Tecnología y Sistemas y Consultores externos, se le presentó a la junta Directiva una propuesta de inversión para abordar el proceso de reconversión monetaria, como se resume a continuación: Monto Concepto Asignados $ Consultoría y Adaptación de sistemas de Información $ $ Adquisición de servidores para ampliar la infraestructura para albergar la información expresada en Bolívares y aquellas convertidas con información expresada en Bolívares Fuertes $ $ Recursos asignados en Acta de Junta Directiva de fecha Octubre (2007) para la adaptación de los sistemas de información a la Ley de Reconversión Monetaria $ Tabla IV. Asignación de Recursos Financieros Fuente: Elaboración propia con Datos de C. Hellmund & Cía S.A., 2010 Después del estudio de la propuesta económica presentada, se registra en Acta de Junta Directiva de fecha Octubre 2007 la asignación de catorce mil (14.000$) Dólares Americanos para el ejecútese del proyecto de 109

109 adaptación de los sistemas de información Análisis del Sistema Inventario General del Sistema (IGS) De acuerdo al levantamiento detallado de los sistemas de información de la empresa, a continuación se presenta en la Tabla IV. una relación de las aplicaciones y módulos críticos para la organización. El resto de las aplicaciones serán desechadas debido a su obsolescencia o por no agregar mayor valor a la operación. Tabla IV. Inventario de Aplicaciones y Módulos Medulares Serie Financiera Contabilidad General Reporteador FRx Cuentas por Pagar Cuentas por Cobrar Administrador de Efectivo Conciliación Bancaria Multi-Compañia Administrador de Monedas Traducción de Estados Financieros Activo Fijo Serie Configuración y Desarrollo Customization Manager Dynamics SL IV Tools for VB Microsoft SQL Server 2000 Microsoft SQL Server 2000 Serie Distribución Otros Compras Requisiciones Landed Cost Administración de Pedidos Inventario Punto de Venta Nómina Sistema de Ajuste Fiscal Fuente: Elaboración propia con Datos de C. Hellmund & Cía S.A.,

110 Desde el punto de vista de la infraestructura, la empresa cuenta con equipos y una plataforma de vanguardia que respaldan de forma eficiente la las actividades y los procesos de la organización, así como también la adaptación de los sistemas de información requerida por la Ley de Reconversión Monetaria, como se detallan a continuación: Tabla IV. Inventario de la Infraestructura de la Organización. No Concepto Descripción Detalles 5 Servidores HP Manejador de Base de Datos: SQL Server 2000; Directorio Activo; Active Directory; Mensajería: Exchange Server 2005;Firewall: ISA Server 2004; Sistema de Respaldo; BackupExec Sistema operativo Windows 2003 Server Estándar 90 Estaciones de Trabajo Marca Dell Modelo Optiplex Serie 7XX Sistema Operativo Windows XP 1 Infraestructura de Red Cableado Estructurado Nivel 5E interconectado por 4 Swicthes marca 3COM modelo 4250T de 48 Puertos y 1GB de transmisión. 1 Plataforma Sistema de Alimentación Ininterrumpida Marca (UPS) APC Modelo RT 6000 Autonomía energética a la infraestructura de 45 minutos ante fallas eléctricas 1 Enlace a Internet Proveedor de servicio: Intercable Provee la navegación, mensajería, y la comunicación con las tiendas remotas. Fuente: Elaboración propia con Datos de C. Hellmund & Cía S.A.,

111 Análisis de Impacto en las Aplicaciones (AIA) Una vez identificada las aplicaciones que no disponen de alguna herramienta provista por la casa matriz o distribuidor, como son el caso de Dynamics SL 6.50 y el Punto de Ventas, se realiza un inventario detallado de las tablas con campos monetarios para cuantificar y luego analizar la magnitud de los cambios requeridos mediante la construcción y ejecución de las siguientes consultas a través del manejador de base de datos. El Anexo 1 muestra un listado parcial de las 280 tablas contenidas en Dynamics SL 6.50 y el Punto de Ventas resultantes de las sentencias que se muestran a continuación: Tabla IV. Detalle de Tablas en Dynamics SL y Punto de Venta Objetivo Sentencia SQL Determinar Tablas en la base de datos con registros SELECT DISTINCT "TABLE NAME" = o.name, i.rows Records FROM sysobjects o, sysindexes i WHERE o.type = 'U' and o.id = i.id and i.indid in (0,1)and i.rows > 0 ORDER BY o.name Determinar Tablas en la base de datos con registros y campos monetarios SELECT "TABLE NAME" = o.name, "FIELD NAME" = f.name, f.xtype FROM sysobjects o, syscolumns f, sysindexes i WHERE o.type = 'U' and o.id = f.id and o.id = i.id and i.indid in (0,1) and i.rows > 0 and f.xtype = 62 and f.name not like '%QTY%' and f.name not like '%User%' ORDER BY o.name, f.name, f.xtype -- tipos: = Small Integer, 56 = Integer, 62 = Float Fuente: Elaboración propia con Datos de C. Hellmund & Cía S.A.,

112 De igual manera, el Anexo 2 muestra un listado parcial de las tablas con sus respectivos campos monetarios objeto de análisis. Dado que el ERP Dynamics SL 6.50 y el Punto de Ventas no disponen de alguna herramienta que facilite el proceso de Reconversión Monetario establecido por ley, y que además, se hace inviable adicionar campos complementarios a tales sistemas para satisfacer los requerimientos técnicos de la misma, se propone como única alternativa disponible lo siguiente: 1. Construir una base de datos con una estructura idéntica a la existente para registrar datos en la nueva expresión montería. 2. Coordinar con las diferentes Unidades de Negocio de la empresa, el análisis de la evolución periódica de los saldos y transacciones y, en especial, de las partidas pendientes. 3. Transferir y convertir únicamente los saldos y las partidas pendientes existentes al 31/12/ Facilitar todos los reportes de cotejo para validar la exactitud de la reconversión de los saldos y transacciones pendientes. 5. Garantizar el acceso a los usuarios de los datos contenidos en ambas monedas. 113

113 Figura IV. Flujo del Proceso de Reconversión Fuente: Microsoft Dynamics SL

114 Análisis de Impacto Global e Interrelaciones (AIG) Analizando los datos recabados en las actividades anteriores, se rectifican con los responsables asignados y se comparten con los distintos miembros del equipo de proyecto. Para disponer de una imagen clara del impacto de los cambio y de su interrelación con los diferentes componentes del sistema, se traza el mapa de la relación entre los módulos así como los diagramas de Entidad-Relación (ER) de las tablas criticas identificadas previamente, como se muestra a continuación la Figura IV. y los Anexo al Anexo. Debido a lo limitado de las alternativas disponibles, se decide abordar el proyecto de reconversión monetaria según se bosqueja en la sección anterior. Así mismo, se concluye que el riego asociado al proceso de reconversión recae básicamente en tres elementos que señalamos a continuación: 1. Consolidar y procesar de manera oportuna todos los datos al 31/12/2007 en la oficina principal, incluyendo aquella procedente de los puntos de venta que operan este día a nivel nacional. 2. Aplicar la Reconversión Monetaria en todas las tienda a nivel nacional y oficina principal antes del 3/1/2008 darle continuidad a la operación. 3. Cualquier demora o variación importante en la proceso de reconversión retrasaría la apertura de operaciones en cada una de las dependencias ocasionando pérdidas económicas para la empresa. 115

115 Figura IV. Mapa de Interrelación de Módulos con Contabilidad Fuente: Microsoft Dynamics SL

116 4.3. Diseño del Sistema Diseño Técnico General (DTG) Como se mencionó anteriormente, para el diseño, desarrollo y pruebas de la solución, se recreara en ambiente operativo de Dynamics SL y Punto de Venta en un computador de escritorio básicamente con un procesador de 2 núcleos, 4 GB de memoria RAM y un disco duro con aproximadamente 60Gb libres. La herramienta de análisis y desarrollo que se utilizara para son SQL Enterprise Manager para administrar las bases de datos, el SQL Query Analyzer para evaluar los datos y desarrollar sentencias, vistas y procedimientos de transformación propias de SQL server, y el generador de reportes Crystal Reports. El detalle del diseño de la reconversión se esboza en la Figura IV. y describe a continuación: Sobre la base de datos de sistemas, HellmundSys: 1. Asignar en la Tabla Company, campo BaseCuryId el valor VEF Sobre la base de datos de aplicaciones, HellmundApp: 1. Vaciar por módulos todas las tablas empleadas en el registro de transacciones. 2. Actualizar las tablas de configuración, maestras, y saldos. 3. Transferir de la base de datos expresada en VEB los datos históricos y el detalle de las partidas pendientes (transacciones) actualizando los campos monetarios correspondientes. 117

117 4. Cuando los datos de alguna transacción indiquen que el campo CuryId (Moneda) corresponda a la moneda base, todos los campos monetarios serán actualizados. De lo contrario, solo los campos monetarios correspondientes a campos cuya denominación no comience con las siglas Cury. 5. Se incorporara a la tablas de control de comprobantes cada una de las transacciones transferidas asignándole el número de control consecutivo y estado correspondientes. 6. Liberar transacciones de Inventario y de Manejo de Efectivo siguiendo las instrucciones establecidas en el Manual de Reconversión. 118

118 Figura IV. Flujograma General del Mecanismo de Reconversión Fuente: Elaboración propia con Datos de C. Hellmund & Cía S.A.,

119 Así mismo, se establece un cronograma para la implementación de la reconversión monetaria, como presenta a continuación:. Tabla IV. Cronograma de Reconversión Oficina Ppal Diciembre 2007 Enero 2008 L M M J V S D L M M J V S D L M M J V S D Azueto Navideno X X X X X X X X X X X X X X X X X X X X X Partidas Pendientes X X X X X Validación X X X X Recepcion Datos Tiendas X X X X X X X X X X X X X X Cierre Contable Reconversión Contingencia X X X Tiendas Mant. Grp 1 X X X Mant. Grp 2 X X X Mant. Grp 3 X X X Mant. Grp 4 X X Trf Datos VEB X X X X X X X X X X X X X X R. Monetaria G1 X R. Monetaria G2 X R. Monetaria G3 X R. Monetaria G4 X Contingencia X X X X Fuente: Elaboración propia con Datos de C. Hellmund & Cía S.A., 2010 X X X 120

120 4.4. Implementación del Sistema Adaptación del Sistema de Información (ASI) Acorde a las pautas establecidas en la fase de diseño, se construye y prueban los distintos elementos que conforman la rutina de reconversión, se elabora la documentación requerida para ejecutar dicho proceso y se establecen los mecanismos de validación necesarios para constatar la exactitud de proceso y la detección de errores en los datos. Mediante el uso de técnicas de análisis y refinamiento de información, se examinan, por módulos, las diferentes tablas a fin de caracterizar las transacciones registradas e identificar los campos asociados a la reconversión para así construir un conjunto de sentencias en SQL que identifique, transfiera y convierta los registros asociados a la nueva expresión monetaria, como se presenta en el Anexo. Simultáneamente, conforme avanza el desarrollo de la herramienta también, se elabora el Manual correspondiente como se muestra en el 121

121 Anexo y que funge de guía para replicar el proceso de reconversión durante las fases de prueba y de conversión definitiva, tanto en la oficina principal como en tiendas a nivel nacional. Finalmente, se identifican los reportes del sistema que sirven de validación de los resultados de la reconversión como se presentan en la Tabla IV., a continuación: 122

122 Tabla IV. Reportes Comparativos de Validación Reportes Comparativos Módulo SL Reporte Notas Contab. General Balance Comprobación ( ) Balance Comprobación ( ) Imprimir formato Totales Combinados para el periodo actual Imprimir formato Totales Combinados para el Final Ejercicio Anterior Cuentas por Pagar Cuentas por Cobrar Inventario Ordenes de Compra Órdenes de Venta Activo Fijo Punto de Venta Balance Comprobación Proveedores ( ) Antigüedad ( ) CXP Antigüedad CXP Sensible Periodo ( ) Balance Comprobación Clientes ( ) Antigüedad Cuentas por Cobrar (08.610) Valoración Inventario ( ) Balance Comprobación Inventario ( ) Balance Comprobación Inventario ( ) Registro Órdenes de Compra ( ) Órdenes de Venta por Número ( ) Valorización de Activos (FA ) Lista de Precios (XP ) Pedidos Pendientes (XP ) Imprimir formato Documentos Abiertos Únicamente Imprimir formato Vencido Resumido para 31/12/2007 Imprimir formato Resumido para el periodo actual Imprimir formato Documentos Abiertos Únicamente Imprimir formato Resumen Saldos Clientes Imprimir formato Excluir Saldo Cero Imprimir formato Estándar para el periodo actual Imprimir formato Todos los Artículos (Incluir No-Almacenados) para el periodo actual Imprimir formato Resumido para el periodo actual para ordenes pendientes Imprimir formato Detalle por Número de Orden para ordenes pendientes Imprimir formato al 31/12/2007 Imprimir formato para listas vigentes. Imprimir formato al 31/12/2007 para pedidos pendientes. Fuente: Elaboración propia con Datos de C. Hellmund & Cía S.A.,

123 Pruebas Generales de Integración (PGI) Una vez desarrollada la herramienta de reconversión monetaria y hasta tanto no se efectué la de conversión definitiva, el 2 de enero del 2008, se coordinan simulacros mensuales de reconversión para validar el funcionamiento e integración las adaptaciones sobre los datos más recientes, de acuerdo a las especificaciones técnicas establecidas. Para sustentar las pruebas, se emiten todos los reportes claves identificados en la fase de Adaptación del Sistema de Información (ASI) y se analizan conjuntamente con los gerentes de las Unidades de Negocio a fin de detectar errores, irregularidades u omisiones. De igual manera, se ingresaran transacciones típicas en los diferentes módulos para corroborar el procesamiento individual de los mismos y su integración con otros, incluyendo el módulo de contabilidad. Acorde a lo anterior, la Tabla IV. presentan las cifras comparativas satisfactorias resultantes tras la primera prueba integrada de reconversión. 124

124 Tabla IV. Resultados Comparativos de la Validación Comparación de Reportes después de las Pruebas Módulo SL Reporte Resultado Contabilidad General Cuentas por Pagar Cuentas por Cobrar Inventario Ordenes de Compra Órdenes de Venta Activo Fijo Punto de Venta OK OK OK OK REV OK OK OK OK OK OK Balance Comprobación ( ) O Balance Comprobación Proveedores ( ) Antigüedad CXP ( ) Balance Comprobación Clientes ( ) Antigüedad Cuentas por Cobrar (08.610) Valoración Inventario ( ) Registro Órdenes de Compra ( ) Órdenes de Venta por Número ( ) Valorización de Activos (FA ) Lista de Precios (XP ) Pedidos Pendientes (XP ) Fuente: Elaboración propia con Datos de C. Hellmund & Cía S.A., 2010 Saldo VEB: 75,192,665, Saldo VEF: 75,192, Diferencia: Saldo VEB: 10,438,092, Saldo VEF: 10,438, Diferencia: 0.01 Saldo VEB: 10,438,092, Saldo VEF: 10,438, Diferencia: 0 Saldo VEB: 5,266,232, Saldo VEF: 5,266, Diferencia: 0 Saldo VEB: 5,266,232, Saldo VEF: 5,266, Diferencia: Saldo VEB: 2,507,391, Saldo VEF: 2,507, Diferencia: 0.07 Cantidad: 118,312 unidades Ninguna Pendiente Ninguna Pendiente Saldo VEB:1,781,891, Saldo VEF:1,781, Diferencia: 0.00 Sin Variación Sin Variación 125

125 4.5. Validación y Soporte Habiendo culminado la fase de Pruebas Generales de Integración y a escasas cuatro semanas de realiza el proceso de conversión definitivo, se realiza un simulacro de reconversión masivo para determinar posibles incidentes, inconsistencias, garantizar la confianza requerida y ultimar detalles de un proceso tan delicado. De igual manera, para oficializar la validación se elabora una lista de cotejo donde los diferentes responsables de las áreas de negocio de la organización, constatan y aprueban los resultados de la reconversión como se muestra en la Tabla IV.. Hasta el momento de la reconversión, se evalúan aquellas actividades que por su naturaleza fueron pospuestas y recopila y corrige la documentación generada. Finalmente, luego de la reconversión, todos los esfuerzos se avocan a corregir cualquier falla detectada y ampliar las capacidades de reportes para incluir la doble expresión monetaria. 126

126 Tabla IV. Lista Cotejo de Validación de la Reconversión Modulo Descripción Responsable Aprobado Firma MULTIMONEDA CM Validar creación de VEB y VEF CM Validar Ingreso de tasas cambiarias Historicas INVENTARIOS IN Validar Fecha de Transacción IN Validar Fecha Ultima Compra/Recepción IN Validar Cantidas,Costosy Totales IN Unificar Localidades de Almacen IN Liberar Comprobante de Recepción IN Deshabilitar/Eliminar Almacenes/Localidades en desuso IN Deshabilitar/Eliminar Productos/Servicios en desuso CUENTAS POR COBRAR CXC Validar Partidas Pendientes CXC Validar Saldos y Antigüedad Clientes CXC Deshabilitar/Eliminar Clientes sin Actividad CUENTAS POR PAGAR CXP Validar Partidas Pendientes CXP Validar Saldos y Antigüedad Proveedores CXP Deshabilitar/Eliminar Proveedores sin Actividad VENTAS OM Validar Pedidos Pendientes OM Validar Embarques Pendientes OM Validar Impuestos por ventas COMPRAS PO Validar Pedidos Pendientes PO Validar Recepciones Parciales Punto de Venta POS Validar Pedidos Pendientes POS Validar Precios y Combos POS Validar Truncado de Tablas ACTIVO FIJO AF Validar Valores LOCALIZACION VENEZUELA LV Validar Conversión de los datos LV Impresión Libro de Ventas LV Impresión Libro de Compra LV Calculos de Retenciones Fuente: Elaboración propia con Datos de C. Hellmund & Cía S.A.,

127 CAPITULO V CONCLUSIONES Y RECOMENDACIONES Durante el proceso de investigación del presente trabajo, se encontraron innumerables fuentes relacionadas con la aplicación de diversos métodos y metodologías, donde se enfatiza la importancia de las metodologías sobre los métodos. En estos términos, los autores plantean la metodología como el resultado de y el proceso de una investigación adaptable, donde ni la teoría ni la práctica tienen precedencia (Checkland, 1985) y la resultante de un hilado consciente de la teoría y la práctica en un contexto determinado. En contraste, el método lo conciben como un elemento estático de pasos a seguir. De lo anterior concluyen, que si el método no se considera como una fórmula sino más bien como una directriz, y el individuo o colectivo asume la responsabilidad de aprender de tal proceso, entonces éste puede transformarse en una metodología. La presencia de una cantidad importante de métodos y metodologías llevan a pensar que, en general, no están satisfaciendo los requerimientos de la organización por cuanto estas se ven obligadas a desarrollar sus propias metodologías o adaptar las existentes toda vez que las versiones formales, tradicionales o agiles, no son aplicables a todos los procesos de desarrollo. Aun así, los beneficios adquiridos por su implementación se justifican en términos de la productividad, calidad y comunicación que proporcionan a la organización. 128

128 En cuanto al esquema diseñado para abordar la comparación de métodos y metodologías se refiere, el valor del mismo no recae precisamente en el resultado obtenido sino más bien en la comprensión de las dimensiones que deben analizarse para determinar cuál metodología es más favorable para abordar un proyecto de manera eficaz de acuerdo a las capacidades y necesidades de la organización. En definitiva, la elección de una metodología sobre otra depende más bien de la naturaleza del proyecto, la experiencia y el conocimiento que se dispongan para aplicarla efectivamente. Como resultado de la investigación, también se elabora una propuesta metodológica que hereda la estructura fundamental de las metodologías predominantes con el objetivo fundamental de ofrecer un esquema comprensible, flexible y simple, capaz de servir como directriz en la adaptación de los sistemas de información ante el advenimiento de nuevos marcos legales. Como asistencia al proceso de conversión monetaria, Microsoft a través de sus canales de negocio en Venezuela facilitó una "Herramienta de Reconversión Monetaria" desarrollada para Dynamics sustentada en los principios y lineamientos establecidos por el Banco Central de Venezuela. No obstante, dada la integración medular existente en C. Hellmund & Cia, S.A. entre la solución MS Dynamics SL y el módulo del Punto de Ventas, desarrollado por un aliado comercial de Microsoft, la empresa se vio obligada a revaluar la herramienta as fin de modificarla para así cubrir los diversos elemento provistos por el Punto de Ventas. La aplicación de la metodología propuesta para la adaptación de los 129

129 sistemas de información de C. Hellmund & Cía S.A. a la Ley de Reconversión Monetaria, no solo facilitó el manejo de un proceso complejo y exigente sino también permitió alcanzar con éxito los objetivos planteados en función del tiempo, recursos asignados y resultados obtenidos. Finalmente, como resultado del presente trabajo de investigación, es necesario recomendar, por un lado, que la metodología propuesta sea modificada para abarcar aspectos relacionados con el desarrollo de nuevos sistemas de información y, por otro, que la Universidad Nacional Abierta incluya en su programa, el estudio de las distintas metodologías, muy en especial, la Metodología Métrica Versión 3, que aun cuando no formó parte del presente trabajo, proporciona un instrumento útil para la sistematización de las actividades que dan soporte al ciclo de vida del software. 130

130 REFERENCIAS BIBLIOGRÁFICAS Abrahamsson, P., Salo, O., Ronkainen, J., Warsta, J. (2002) Agile Software Development Methods. Review and Analysis, VTT. Ambler, S. W. (2002, Julio) Ducking it out, Software Development. Aparasi, J., Ripoll, V. (2000) Relevancia de la Tecnología de la Información y de los Sistemas de Información Estratégicos para la Elaboración del Cuadro de Mando Integral. Universidad de Valencia (España). Asociación de Psicología de Estados Unidos de América (APA) (2005) Publicación del Manual APA. Washington, DC, USA. Avison, D. y Fitzgerald, G. (2006) Information Systems Development, 4th ed., McGraw Hill, New York, NY, USA. Beck, K. (1999a). Embracing Change With Extreme Programming. IEEE Computer 32(10):70-77 Beck, K. (1999b). Extreme programming explained: Embrace change. Reading, Mass., Addison-Wesley Boehm, B. y Philip, P. (1988, Octubre) Understanding and Controlling Software Costs, IEEE Transactions on Software Engineering, Vol. 14 No 10 Boehm, B. (2002, Enero) Get Ready for Agile Methods with Care, IEEE Software Development, pp Booch, G., Rumbbaugh, J. y Jacobson, I. (1999). El Lenguaje Unificado de Modelado. Madrid: Addison Wesley Iberoamericana (Original en Ingles publicadio en 1998). Britos, P. Fernández, E. Ochoa, M. Merlino, H. y García, M (2004) Metodología de Selección de Herramientas de Explotación de Datos. Buenos Aires, Argentina. Instituto Tecnológico de Buenos Aires. Checkland, P.B. (1981) System Thinking, System Practice, John Wiley & Son, Chichester, UK. 131

131 Checkland, P.B. (1985) From optimizing to learning: a development of systems thinking for the 1990s, Journal of the Operational Research Society, vol. 36, pp Chiesa, F. (2000) Metodología para la Selección de Sistemas ERP. Buenos Aires, Argentina. Centro de Ingeniería de Software e Ingeniería del Conocimiento. Choo, Chun Wei. (2002) Information Management for the Intelligent Organization, edition Medford, NJ: Information Today Inc. Cockburn A. y Highsmith J. (2001, Noviembre) Agile Software Development: The People Factor, IEEE Computer, IEEEArticle2Final.pdf. Constantine, L. (2001, Junio) Methodological Agility, IEEE Software Development, pp Dell, Michael (2002, Abril 8) First eworkshop on Agile Methods, Centre for Experimental Software Engineering Maryland. Eisenhardt, K. y Sull, D. (2001, Enero) Strategy as Simple Rules, Harvard Business Review, Vol. 79, pp Elliott, G. y Strachan J. (2004), Global Business Information Technology. p.87. González, D. Morales, J. y Roda, L (2007) Metodología Métrica V.3. Tenerife, España. Universidad de la Laguna. González, G (2002) Tecnología de Información: Inversión Improductiva o recurso Estratégico. Caracas. Debates IESA. Año Volumen VII. No 4 Herbert, S (2003) Importancia de la Toma de Decisiones en la Empresa. New York, Prentice Hall. Jones, C. (1997), Applied Software Measurements. McGraw Hill Kuhn, T. S. (1962) The Structure of Scientific Revolutions, 1st. ed., Chicago: Univ. of Chicago Pr. Malcolm, Eva (1992). SSADM Version 4: A User's Guide McGraw-Hill, Inglaterra. 132

132 Poppendieck, M. (2001, Mayo-Junio) Lean Programming, Software Development Magazine, Vol. 9, No. 5 y 6. Santibáñez, J. M. (2000). SISTEMAS DE INFORMACION Capítulo A Metodología. Suarez, R (2007) Metodología de Gestión de Proyectos en las Administraciones Públicas según ISO Universidad de Oviedo. Universidad Pedagógica Experimental Libertador, UPEL (2005) Manual de Trabajos de Grado, de Especialización y Maestrías y Tesis Doctorales. Caracas. FEDEUPEL. US Department of Justice (2003). INFORMATION RESOURCES MANAGEMENT Chapter 1. Introduction Wetherbe, J. y Vitalari, N. (1994), Systems Analysis and Design: Traditional, Best Practices, 4 th Ed. Minnesota. Whitten, J., Bentley L. y Ditmann K. (2004), System Analysis and Design Methods. McGraw-Hill. 6th Ed. New York, USA. Williams, L. y Cockburn, A. (2003, Junio), Agile Software Development: It s about Feedback and Change, IEEE Computer, pp Fuentes de Tipo Legal Ley de Reconversión Monetaria (2007). Gaceta Oficial de la República Bolivariana de Venezuela No de fecha 6 de Marzo de 2007.Caracas. Lineamientos Tecnológicos para la Adaptación de los Sistemas y Tecnologías de Información basados en la Reconversión Monetaria. Gaceta Oficial de la República Bolivariana de Venezuela No de fecha 22 de Junio de 2007.Caracas. BCV. 133

133 Otras Fuentes MÉTRICA. VERSIÓN 3 Metodología de Planificación, Desarrollo y Mantenimiento de sistemas de información

134 ANEXOS 135

135 Anexo Listado Parcial Tablas en Dynamics SL Account CustContact LocTable SlsTaxHist XBRecHdr xpdoc AcctClass CustGLClass LostSaleCode smsvccalendar XBStateDet xpdoc_hist AcctHist CustNameXRef LotSerMst Snote XBStateHdr XPDpstCash Address Customer LotSerT SoAddress XBStrStateFld xperiod AKAPDoc CustomerEDI LV_Setup SOAddrSlsper XBStrStateHdr XPFisRpt AKARDoc CustSlsper LVFactorCompra SOColRmks XBTranClass XPGLTran AKRetIVADoc DocTerms LVVersion SOEvent XBTranCode xphistorystore AKRetIVAStp Document MSCustomer SOHeader XCCategorias XPInventory AKRetIVAWrk EDConvMeth MSVendor SOLine XCComisiones xploteserial AKSOShipHeader EDPurchOrd PCSetup SOLot XCComisiones_tmp xppackage AP_Balances EntryTyp PIABC SONoShip xcheckbook xppayment AP03625_Wrk Field PIDetail SONoUpdate XCPenaltys xppayment_hist APAdjust FlexDef PIMoveCl SOPlan XCVendeCategoria XPPaymentProc APCheck FOBPoint POAddress SOPrintControl xfaassets xppaytype APCheckDet FrtTermDet POReceipt SOSched xfaassetsclass XPPostProcessTmp APDoc FrtTerms POReqDet SOShipHeader xfaassetsclassset XPPrLsDet APHist FSDefHdr POReqHdr SOShipLine xfaassetsset XPPrLsHdr APRefNbr FSSetup POReqHist SOShipLineSplit xfaassetssub XPPrLsLv APSetup GLSetup POSetup SOShipLot xfadoc xprefnbr APTran GLTran POTran SOShipSched xfadoclines xpregister AR_Balances HistDocSlsTax PriceClass SOShipSplit xfaevent xprights ARAdjust IN10990_ItemSite ProcessLog SOShipTax xfahist xprosubclass ARDoc IN10990_Location ProcessQueue SOSplitDefaults xfalocdet xpschedule ARHist INArchTran ProductClass SOSplitLine xfasetsstatus xpsending ARSetup INDfltSites ProductLine SOStep xfasubdist xpsendingtarget ARShipTrack INProdClDfltSites PStatus SOTax xfasubdisthdr xpstore ARStmt INSetup PurchOrd SOType xfatran xpsystemlog ARTran INTran PurchOrdTrack State xfwrkcuberpt xptran AssyDoc INUnit PurOrdDet SubAcct xheaderfac xptran_hist AttribDef Inventory ReasonCode Terms xhotfix xptransferdet Batch InventoryADG Record Territory xmasterdef xptransferhdr Budget_Dist_Type InvtDescrXRef RefNbr TrnsfrDoc xmastertable XPVersion CASetup Item2Hist Results typetransl xordinal xsubtree CashAcct ItemAttribs safperiodos VendClass xpbank xtrans

136 Anexo Listado Parcial Tablas y Campos Monetarios Tabla Campo Tabla Campo Tabla Campo AcctHist AnnBdgt APDoc DiscBal AR_Balances NbrInvcPaid AcctHist AnnMemo1 APDoc DiscTkn AR_Balances PaidInvcDays AcctHist BegBal APDoc DocBal AR_Balances PromoBal AcctHist PtdAlloc APDoc OrigDocAmt AR_Balances S4Future AcctHist PtdBal APDoc PmtAmt AR_Balances TotOpenOrd AcctHist PtdCon APDoc RGOLAmt AR_Balances TotPrePay AcctHist YtdBal APDoc S4Future AR_Balances TotShipped AcctHist YTDEstimated APDoc TaxTot ARAdjust AdjAmt AP_Balances CurrBal APDoc TxblTot ARAdjust AdjDiscAmt AP_Balances CYBox APHist BegBal ARAdjust CuryAdjdAmt AP_Balances CYInterest APHist PtdCrAdjs ARAdjust CuryAdjdDiscAmt AP_Balances FutureBal APHist PtdDiscTkn ARAdjust CuryAdjdRate AP_Balances NYBox APHist PtdDrAdjs ARAdjust CuryAdjgAmt AP_Balances NYInterest APHist PtdPaymt ARAdjust CuryAdjgDiscAmt AP_Balances S4Future APHist PtdPurch ARAdjust CuryRGOLAmt AP_PPApplicBat S4Future APHist S4Future ARAdjust S4Future AP_PPApplicDet AppliedDocAmt APHist YtdCrAdjs ARDoc ApplAmt AP_PPApplicDet AppliedDocBalance APHist YtdDiscTkn ARDoc CmmnAmt AP_PPApplicDet ApplyingDocAmt APHist YtdDrAdjs ARDoc CmmnPct AP_PPApplicDet ApplyingDocBalance APHist YtdPaymt ARDoc CuryApplAmt AP_PPApplicDet CuryApplyAmt APHist YtdPurch ARDoc CuryClearAmt AP_PPApplicDet S4Future APRefNbr S4Future ARDoc CuryCmmnAmt APAdjust AdjAmt APTran CuryPOExtPrice ARDoc CuryDiscApplAmt APAdjust AdjDiscAmt APTran CuryPOUnitPrice ARDoc CuryDiscBal APAdjust CuryAdjdAmt APTran CuryPPV ARDoc CuryDocBal APAdjust CuryAdjdDiscAmt APTran CuryRate ARDoc CuryOrigDocAmt APAdjust CuryAdjdRate APTran CuryTaxAmt ARDoc CuryRate APAdjust CuryAdjgAmt APTran CuryTranAmt ARDoc CuryStmtBal APAdjust CuryAdjgDiscAmt APTran CuryTxblAmt ARDoc CuryTaxTot APAdjust CuryRGOLAmt APTran CuryUnitPrice ARDoc CuryTxblTot APAdjust S4Future APTran JobRate ARDoc DiscApplAmt APCheckDet CuryDiscAmt APTran POExtPrice ARDoc DiscBal APCheckDet CuryGrossAmt APTran POUnitPrice ARDoc DocBal APCheckDet CuryPmtAmt APTran PPV ARDoc OrigDocAmt APCheckDet CuryRate APTran S4Future ARDoc RGOLAmt APCheckDet DiscAmt APTran TaxAmt ARDoc S4Future APCheckDet GrossAmt APTran TranAmt ARDoc StmtBal APCheckDet PmtAmt APTran TxblAmt ARDoc TaxTot APCheckDet S4Future APTran UnitPrice ARDoc TxblTot APDoc ApplyAmt AR_Balances AccruedRevAgeBal00.04 ARHist AccruedRevBegBal APDoc ClearAmt AR_Balances AccruedRevBal ARHist BegBal APDoc CuryDiscBal AR_Balances AgeBal ARHist NbrInvcPaid APDoc CuryDiscTkn AR_Balances AvgDayToPay ARHist PaidInvcDays APDoc CuryDocBal AR_Balances CrLmt ARHist PTDAccruedRev APDoc CuryOrigDocAmt AR_Balances CurrBal ARHist PTDCOGS

137 Anexo Diagrama ER Balance Comprobación ( ) 138

138 Anexo Diagrama ER Balance Comprobación CXP ( ) 139

139 Anexo Diagrama ER Transacciones CXP ( ) 140

140 Anexo Diagrama ER Balance Comprobación CXC ( ) 141

141 Anexo Diagrama ER Antigüedad CXC (08.610) 142

142 Anexo Diagrama ER Valoración Inventario ( ) 143

143 Anexo Diagrama ER Balance Comprobación IN ( ) 144

144 Anexo Diagrama ER Órdenes de Compra ( ) 145

145 Anexo Diagrama ER Ordenes de Venta ( ) 146