Implementacion de la capa de Presentacion y Negocio del Modulo (IPC)

U U NI N IV VE E RS R SI ID DA AD D D DE E L LA AS S C C IE I E NC N CI IA AS S I I NF N FO O RM R MÁ ÁT TI IC CA AS S

F F AC A CU U LT L TA AD D 3 3

I I M M P P L L E E M M E E N N T T A A C C I I Ó Ó N N D D E E L L A A C C A A P P A A D D E E P P R R E E S S E E N N T T A A C C I I Ó Ó N N Y Y N N E E G G O O C C I I O O D D E E L L M M Ó Ó D D U U L L O O ( ( I I P P C C ) )

T T RA R AB BA AJ JO O D D E E D DI IP PL LO OM M A A P PA AR RA A O OP PT T AR A R P PO O R R E EL L T TÍ ÍT T UL U LO O D D E E

I I NG N GE EN NI IE ER RO O E EN N C C IE I EN NC CI IA AS S I I NF N FO O RM R MÁ ÁT TI IC CA AS S

A A UT U TO OR R : : I I RO R OC CH HY Y O O R RO O H H UR U RT TA AD DO O

T T U UT TO O R R : : L L IC I C . . M M ER E RL LY YN N A A V VI IL LÉ ÉS S E E S SP PI IN N OS O SA A

Ciudad de La Habana. Cuba

Junio de 2007

Declaración de autoría.

Declaración de autoría.

Declaro que soy el único autor de este trabajo y autorizo a la Facultad 3 de la Universidad de las Ciencias Informáticas a hacer uso del mismo en su beneficio.

Para que así conste firmo la presente a los ______ días del mes de _______________ del año ________.

Irochy Oro Hurtado Lic. Merlyn Avilés Espinosa

___________________________ ____________________________

Autor Tutor

Datos de contacto.

Datos de contacto.

Datos del tutor.

Nombre: Merlyn Avilés Espinosa.

Área: Universidad de las Ciencias Informáticas. Facultad 3.

Cargo: Profesor.

Apartamento: 113102 Teléfono: 8372688 Correo: [email protected]

Datos del autor.

Nombre: Irochy Oro Hurtado.

Área: Universidad de las Ciencias Informáticas. Facultad 3.

Apartamento: 11210 Teléfono: 8358707

Correo: [email protected]

Agradecimientos.

Agradecimientos.

A mi abuela, por educarme desde pequeño, por formar en mí todos los valores que hoy tengo, y aunque no se encuentre en estos momentos a mi lado, sus últimas palabras fueron que estudiara y llegará a ser alguien en la vida, y siempre pensé mucho en esto, sentía que no podía fallarle.

A mis padres, agradecerles por darme la vida, por depositar toda su confianza en mí, y darme fuerzas cada vez que lo necesité, guiándome siempre por buen camino.

A mis hermanos, por tenerme siempre presente, siendo yo el mayor de todos, sentí que debía ser un ejemplo para ellos y me esforcé mucho para lograrlo.

A mis tías, que siempre estuvieron al tanto de todo, con sus llamadas, guiándome en todo momento.

A todos mis amigos, que compartieron junto a mi, tanto buenos y malos momentos, que discutían conmigo a diario de casi todo, seguro que voy a extrañar eso.

A mi mejor amigo Yuniesky La Rosa Pérez al que quiero como un hermano, al que tuve desde pequeño a mi lado y creyó siempre en mi, gracias por estar en mi vida y espero que el destino nunca nos separe.

A mi novia Meylin Rodríguez Cabrales, por su amor y paciencia. Gracias por su apoyo y ayuda para la realización de este trabajo.

A Juan Carlos Suárez López, amigo y guía para mí en todo momento. Gracias por brindarme su experiencia e inteligencia. Gracias por compartir tu conocimiento conmigo y ayudarme a hacer de este trabajo lo que hoy es.

A todos ustedes, de todo corazón muchas gracias.

Dedicatoria.

Dedicatoria.

A mi Abuela.

A mis padres, por todo su apoyo.

A toda mi familia, por su confianza depositada.

A mi novia.

A mis amigos.

A los que me han ayudado.

A todos ustedes, porque son parte de mi vida.

Tabla de contenidos.

Tabla de contenidos.

INTRODUCCIÓN. _____________________________________________________________________ 1 CAPÍTULO 1. FUNDAMENTACIÓN TEÓRICA. _____________________________________________ 6 1.1INTRODUCCIÓN. __________________________________________________________________ 6 1.2USO DE LAS TIC.RESEÑA HISTÓRICA. __________________________________________________ 6 1.3ÍNDICES DE PRECIOS AL CONSUMIDOR IPC. ______________________________________________ 7 1.4SISTEMAS ACTUALES PARA CÁLCULOS DE IPC EN EL MUNDO. _________________________________ 7 1.5SISTEMA PARA CÁLCULOS DE IPC EN CUBA. _____________________________________________ 8 1.6¿QUE ES PROGRAMACIÓN?__________________________________________________________ 9 1.7¿QUE ES LA PROGRAMACIÓN ORIENTADA A OBJETOS POO? _________________________________ 9 1.8PARADIGMAS DE LA POO. ___________________________________________________________ 9 1.8.1 El Paradigma Concurrente. ____________________________________________________ 10 1.8.2 El Paradigma Lógico. _________________________________________________________ 11 1.8.3 El Paradigma Funcional. ______________________________________________________ 11 1.9CARACTERÍSTICAS DE LA POO. ______________________________________________________ 11 1.9.1 Abstracción. ________________________________________________________________ 11 1.9.2 Encapsulación.______________________________________________________________ 12 1.9.3 Modularidad. _______________________________________________________________ 12 1.9.4 Jerarquización.______________________________________________________________ 13 1.9.5 Tipificado.__________________________________________________________________ 14 1.9.6 Concurrencia._______________________________________________________________ 14 1.9.7 Persistencia.________________________________________________________________ 14 1.10BENEFICIOS DE LOS ESTÁNDARES DE CODIFICACIÓN. _____________________________________ 14 1.11ANÁLISIS DE LA EFICIENCIA DE ALGORITMOS. ___________________________________________ 16 1.11.1 Eficiencia de un programa. ___________________________________________________ 17 1.11.2 Factores de dependencia. ____________________________________________________ 17 1.11.3 Expresiones y sintaxis de la eficiencia. __________________________________________ 18 1.11.4 Teoría de los casos._________________________________________________________ 18 1.11.5 Métodos del cálculo de la eficiencia. ____________________________________________ 18 1.11.6 Cálculo de la complejidad temporal. ____________________________________________ 19 1.11.7 Cálculo de la complejidad espacial. _____________________________________________ 19 1.12IMPORTANCIA DEL PROCESO DE SOFTWARE PERSONAL EN EL DESARROLLO DE SISTEMAS. _________ 20 1.12.1 Paradigma del PSP._________________________________________________________ 21 1.12.2 Principios del PSP.__________________________________________________________ 21 1.12.3 Gestión del Tiempo. _________________________________________________________ 21 1.12.4 Ideas para registrar el tiempo. _________________________________________________ 22 1.12.5 La Gestión de compromisos. __________________________________________________ 22 1.12.6 Pasos para gestionar un compromiso.___________________________________________ 22 1.12.7 Tips para la gestión de compromisos. ___________________________________________ 22 1.13ANÁLISIS DE LA PLATAFORMA MICROSOFT VISUAL STUDIO 2005. ____________________________ 23 1.14CONCLUSIONES. ________________________________________________________________ 24

Tabla de contenidos.

CAPÍTULO 2. DESCRIPCIÓN Y ANÁLISIS DE LA SOLUCIÓN PROPUESTA. ___________________ 25 2.1INTRODUCCIÓN. _________________________________________________________________ 25 2.2ESTILO ARQUITECTÓNICO. _________________________________________________________ 25 2.3VALORACIÓN CRÍTICA DEL DISEÑO PROPUESTO POR EL DISEÑADOR. ___________________________ 27 2.4ESTRATEGIAS DE INTEGRACIÓN. _____________________________________________________ 29 2.5PATRONES UTILIZADOS. ___________________________________________________________ 30 2.6CAPA DE PRESENTACIÓN. __________________________________________________________ 32 2.7CAPA DE NEGOCIO._______________________________________________________________ 47 2.8ALGORITMOS Y ESTRUCTURAS DE DATOS UTILIZADOS. _____________________________________ 55 2.9DESCRIPCIÓN DE LAS NUEVAS CLASES U OPERACIONES NECESARIAS.__________________________ 56 2.10ESTRATEGIA PARA LA CAPTURA DE ERRORES. __________________________________________ 67 2.11PROCESO DE SOFTWARE PERSONAL (PSP). ___________________________________________ 70 2.12CONCLUSIONES. ________________________________________________________________ 75 CAPÍTULO 3. VALIDACIÓN DE LA SOLUCIÓN PROPUESTA. _______________________________ 76 3.1INTRODUCCIÓN. _________________________________________________________________ 76 3.2HERRAMIENTA UTILIZADA PARA LA VALIDACIÓN. __________________________________________ 76 3.3DESCRIPCIÓN DE LAS PRUEBAS REALIZADAS. ____________________________________________ 78 3.4RESULTADOS OBTENIDOS.__________________________________________________________ 88 3.5CONCLUSIONES. _________________________________________________________________ 89 CONCLUSIONES GENERALES.________________________________________________________ 90 RECOMENDACIONES. _______________________________________________________________ 91 BIBLIOGRAFÍA. _____________________________________________________________________ 92

Índice de figuras.

Índices de figuras.

Figura 1: Vista lógica de la arquitectura ___________________________________________________ 26 Figura 2: Diagrama de subsistemas del módulo IPC _________________________________________ 27 Figura 3: Método LlenarVistaPrevia ______________________________________________________ 30 Figura 4: Uso del patrón Singlenton ______________________________________________________ 32 Figura 5: Interfaz Autenticarse __________________________________________________________ 34 Figura 6: Interfaz para usuarios con rol de administrador _____________________________________ 35 Figura 7: Interfaz para usuarios con rol de operador _________________________________________ 36 Figura 8: Interfaz para insertar nuevos usuarios ____________________________________________ 37 Figura 9: Interfaz para modificar usuarios _________________________________________________ 38 Figura 10: Interfaz para eliminar usuarios _________________________________________________ 39 Figura 11: Interfaz para fusionar los datos _________________________________________________ 40 Figura 12: Interfaz para emitir fusiones ___________________________________________________ 41 Figura 13: Interfaz para emitir las tablas de precios __________________________________________ 42 Figura 14: Interfaz para emitir y calcular los índices de precios _________________________________ 43 Figura 15: Interfaz para mostrar la canasta de productos _____________________________________ 44 Figura 16: Interfaz para insertar nuevos productos __________________________________________ 45 Figura 17: Interfaz para modificar productos _______________________________________________ 46 Figura 18: Interfaz para eliminar productos ________________________________________________ 47 Figura 19: Diagrama de clase CUsuario ___________________________________________________ 49 Figura 20: Diagrama de clases ONE _____________________________________________________ 50 Figura 21: Diagrama de clases Fusión ____________________________________________________ 51 Figura 22: Diagrama de clases Canasta___________________________________________________ 53 Figura 23: Diagrama de clases Encuesta __________________________________________________ 54 Figura 24: Diagrama de clase Nomenclador _______________________________________________ 55 Figura 25: Tratamiento para la captura de excepciones del sistema _____________________________ 68 Figura 26: Tratamiento para la captura de excepciones sql ____________________________________ 69 Figura 27: Utilización del los try - catch para la captura de excepciones __________________________ 70 Figura 28: Resumen semanal de actividades (1,2) __________________________________________ 72 Figura 29: Resumen semanal de actividades (3,4) __________________________________________ 73 Figura 30: Registro del tiempo de implementación___________________________________________ 74 Figura 31: Cuaderno de registro de defectos _______________________________________________ 75 Figura 32: Caso de prueba aceptado para el caso de uso Autenticar Usuario _____________________ 77 Figura 33: Caso de prueba fallido para el caso de uso Autenticar Usuario ________________________ 78

Índice de tablas.

Índices de tablas.

Tabla 1: Descripción de la clase CUsuario _________________________________________________ 56 Tabla 2: Descripción de la clase CConversionNomencladores _________________________________ 57 Tabla 3: Descripción de la clase CProducto ________________________________________________ 57 Tabla 4: Descripción de la clase CMercado ________________________________________________ 58 Tabla 5: Descripción de la clase CProvincia________________________________________________ 59 Tabla 6: Descripción de la clase CFusión__________________________________________________ 60 Tabla 7: Descripción de la clase CProductoEncuesta ________________________________________ 61 Tabla 8: Descripción de la clase CEncuestaGeneral _________________________________________ 62 Tabla 9: Descripción de la clase CProductoCanasta _________________________________________ 63 Tabla 10: Descripción de la clase CCanastaGeneral _________________________________________ 64 Tabla 11: Descripción de la clase CFichero ________________________________________________ 65 Tabla 12: Descripción de la clase CFicheroParse ___________________________________________ 66 Tabla 13: Descripción del caso de prueba para Autenticar Usuario ______________________________ 78 Tabla 14: Descripción del caso de prueba Asignar Privilegio ___________________________________ 79 Tabla 15: Descripción del caso de prueba Gestionar Usuario __________________________________ 80 Tabla 16: Descripción del caso de prueba Modificar Usuario___________________________________ 81 Tabla 17: Descripción del caso de prueba Eliminar Usuario ___________________________________ 82 Tabla 18: Descripción del caso de prueba Insertar Producto ___________________________________ 83 Tabla 19: Descripción del caso de prueba Modificar Producto__________________________________ 84 Tabla 20: Descripción del caso de prueba Eliminar Producto __________________________________ 85 Tabla 21: Descripción del caso de prueba Emitir Fusión ______________________________________ 85 Tabla 22: Descripción del caso de prueba Emitir Tablas de Precios _____________________________ 86 Tabla 23: Descripción del caso de prueba Cálculo de Índices de Precios _________________________ 87

Resumen.

Resumen.

La existencia en Cuba de dos tipos de monedas, el peso cubano y el peso convertible (CUC), y a su vez de cuatro tipos de mercados: Formal (estatal), Informal (llamado mercado negro), Agropecuario y mercado en Divisa, han conllevado a que existan variedades en los precios para un mismo artículo, haciéndose el trabajo de cálculo de precios algo tedioso, por lo que se convierte en una necesidad realizar una operación que permita sondear los precios de los productos en los diferentes mercados, esta operación es llamada Normalización. La Oficina Nacional de Estadísticas (ONE) creó un sistema que les permite controlar todo lo referente a cálculos e índices de precios, dicho sistema posee algunas limitaciones: no permite adicionar nuevos productos o eliminarlos, haciendo empalmes con años anteriores, lo que implica que estos procesos se están realizando manualmente. Las carencias que presenta el sistema actual evidencia que es de vital importancia desarrollar un nuevo sistema más flexible que permita el control del cálculo del índice de precios al consumidor, así como gestionar la canasta de productos.

El trabajo surge a raíz de la necesidad que tiene la ONE hoy día, de adquirir un sistema fiable, que brinde funcionalidades para gestionar nuevos productos, calcular índices de precios y realizar comparaciones de productos por provincias, etc.

Este trabajo diploma contiene la implementación de las capas de Presentación y Negocio para el módulo nacional Índices de Precios al Consumidor (IPC), el cual permitirá las funcionalidades de Seguridad, Gestión de Usuarios y Productos, Emisión de tablas e Índices de Precios, además de proporcionar un manejo fácil mediante las interfaces que estarán contempladas en la capa de Presentación.

Palabras claves.

Palabras Claves.

IPC: Índices de Precios al Consumidor.

ONE: Oficina Nacional de Estadísticas.

Fusión: Procesamiento periódico de precios, a los productos provenientes de los respectivos mercados a nivel nacional.

Interfaz: Medio que permite la interacción entre dos elementos.

Capa: Conjunto de subsistemas que comparten la misma generalidad y jerarquía.

Implementación: Término que se refiere a la forma en que se van a codificar las capas de Presentación y Negocio.

Casos de usos: Fragmentos de funcionalidad dentro de un sistema que reportan beneficios para los usuarios.

Instancia: Copia en memoria de una clase con valores en los atributos.

PSP: Proceso Personal de Software.

TSP: Proceso de Software en Equipo.

Abstract.

Abstract.

The existence in Cuba of two types of currencies Cuban peso and (CUC), and in turn four types of markets: Formal (state), Informal (called black market), Agricultural and market in Foreign currency, they have borne to that varieties exist in the prices for oneself article, being made the work of calculation of prices something tedious, for what becomes a necessity to carry out an operation that allows to sound the prices of the products in the different markets, this operation it is called Normalization. The Cuban company (ONE) National Office of Statistical created a system that allows them to control all it with respect to calculations and indexes of prices, this system possesses some limitations like to add new products or to eliminate making connections with previous years, what implies that these processes are being carried out by hand, that which tells us that it is of vital importance to develop a new more flexible system that allows in a better way the control of the calculation from the index of prices to the consumer.

The work arises soon after the necessity that has the NOE nowadays, of acquiring a reliable system that offers functionalities to negotiate new products, to calculate indexes of prices and to carry out comparisons of products for counties, etc.

This work diploma contains the implementation of the layers of Presentation and Business for the module national Indexes of Prices to the Consumer (IPC), which will allow the functionalities of Security, Administration of Users and Products, Emission of charts and Indexes of Prices, besides providing an easy handling by means of the interfaces that will be contemplated in the layer of Presentation.

Introducción.

Introducción.

Hoy en día los sistemas informáticos están presentes en todas las esferas de la sociedad, en la política, en lo social, en la cultura, en la economía, en fin en todas sin excepción. El uso de aplicaciones informáticas ha sido de carácter vital para realizar trabajos que se tornan complejos, tediosos, que requieren de mucho tiempo y detalle, los cuales si fueran realizados por el hombre estarían expuestos a cometer grandes errores y muchas veces pues simplemente con llevaría a la perdida de tiempo, Lo que parece algo muy factible.

Se ha dado cuenta la humanidad la necesidad de informatizarnos cada día más, automatizar los procesos que enmarcan un trabajo o alguna situación determinada, los cuales garantizan un aprovechamiento óptimo del tiempo de trabajo, reducción de errores en un gran margen, permitiendo muchas facilidades, logrando una interacción más amena y cómoda entre los usuarios y su puesto de trabajo. Dado esto se puede afirmar que si se crearan aplicaciones informáticas se resolverán muchos problemas que hoy en día se presentan, por ejemplo, particularmente en nuestro país tenemos dos monedas y varios mercados, problema que solo existe en nuestro territorio, por tanto para hacer cálculos de índices de precios se torna algo complejo y sabiendo además que en cada mercado existen tanto productos iguales como productos diferentes es verdaderamente imposible realizar dichos cálculos de forma manual, además de todos los procesos que deben realizar como comparaciones entre provincias, teniendo en cuenta fechas, provincias, y mercados, es una necesidad vital la creación de una aplicación para realizar todas estas operaciones. Ahora bien si es cierto que la creación de sistemas facilita todas estas operaciones, también debemos destacar que lograr un sistema completo y que satisfaga las necesidades del cliente es bastante complejo, la empresa ONE cuenta en la actualidad con un sistema debido a la necesidad que tiene de calcular índices de precios, comparar productos, entre otras cosas, y dicho sistema no cumple con todas las operaciones y funcionalidades que la empresa necesita por tanto, urge la necesidad de un sistema que resuelva esta problemática. Ya que el cálculo de índice de precios es de importancia vital pues da la medida, de cómo ondean los precios hoy en día, con respecto a varios periodos anteriores, llegando a conclusiones, siendo posible la toma de medidas si fuese necesario, para cada día poder mejorar la situación económica de cada uno de nuestros habitantes, después de analizar esto se observa varias

Introducción.

La situación problemática: esta dada porque la empresa ONE cuenta con un sistema poco flexible para realizar el proceso del cálculo del IPC, el cual presenta varias deficiencias, pues no brinda la funcionalidad de adicionar, eliminar productos, realizar empalmes con respecto a años anteriores, entre otras cosas, ya que no se realizó una arquitectura adecuada, y no se realizó de manera eficiente la implementación de la capa de Negocio.

A partir del análisis a esta problemática se puede formular el siguiente problema científico: ¿Cómo lograr un nuevo sistema que permita de manera eficiente el cálculo del Índice de Precios al Consumidor IPC?

Donde el objeto de estudio a tratar será: Implementación de las capas de Presentación y Negocio en aplicaciones para la automatización.

El objetivo general de este trabajo diploma es desarrollar las capas de Presentación y Negocio creando un nuevo sistema para el cálculo de IPC, permitiendo una aplicación más segura, eficiente, que erradique las deficiencias del sistema actual.

Para dar cumplimiento a este objetivo, se proponen los siguientes objetivos específicos:

• Definir las clases que intervendrán en el sistema así como sus relaciones.

• Definir roles con sus respectivos privilegios garantizando la seguridad del sistema.

• Dar cumplimiento a todos los requisitos funcionales de una forma eficiente.

• Realizar pruebas a las soluciones propuestas.

Del anterior objeto de estudio se deriva el siguiente campo de acción: Implementación de las capas de Presentación y Negocio en Microsoft Visual C # para la automatización de cálculos estadísticos para la ONE en Cuba.

Lo que conlleva a la hipótesis siguiente: Con la implementación, de forma correcta, de las capas de Presentación y Negocio se logrará un nuevo sistema más flexible, que permitirá de manera eficiente el proceso del cálculo de Índice de Precios al Consumidor IPC.

Introducción.

Y para lograr de manera exitosa el cumplimiento de la hipótesis expuesta anteriormente, se hizo necesario el cumplimiento de las tareas de la investigación que se presentan a continuación.

• Análisis y estudio de los requisitos funcionales y no funcionales para la implementación del módulo IPC.

• Realizar un estudio de la tecnología o lenguaje utilizado.

• Programar orientado a objetos en el lenguaje Microsoft Visual C#.

• Estudio de la herramienta NUnit Framework, para la realización de pruebas de validación.

Para la realización de forma correcta de la implementación de las capas que formarán el modulo IPC, se requiere de conocimiento, se analizará al detalle todos los requisitos funcionales, para llegar a tener una idea del tiempo de trabajo y poder desglosarlo en partes, por tanto se hace necesario la utilización de la metodología de la investigación científica, apoyado en algunos de los métodos existentes hoy en día.

Métodos Teóricos:

• Histórico - Lógico: permitiéndonos hacer un estudio del comportamiento actual del desarrollo de sistemas de gestión, dándole solución al problema dado.

• Sistémico: es uno de los métodos más importantes, permite desglosar los elementos que contendrá el sistema así como asignar las relaciones y jerarquías que existen entre ellos.

Métodos Empíricos:

• Observación: mediante este método percibimos y planificamos como quedaría concebido el sistema.

• Medición: para medir la eficiencia de los algoritmos, así como el tiempo de desarrollo del sistema.

Introducción.

La culminación exitosa de este trabajo diploma permitirá lograr resultados satisfactorios, dando lugar a importantes aportes prácticos: El desarrollo de las capas de Presentación y Negocio para el módulo nacional IPC propuesto en el trabajo diploma contiene un gran valor práctico que se manifiesta en su aplicación:

• El desarrollo de estrategias de integración que permitieron una solución eficiente a las exigencias trazadas y una mejor viabilidad y organización en la programación.

• El proceso de la captura de errores de las distintas excepciones lanzadas por el sistema y la base de datos, asegurando un correcto funcionamiento y especificándole al usuario el tipo de error cometido.

• El sistema de seguridad con el que cuenta la aplicación, pretende brindar la integridad de los datos, así como la reusabilidad de la misma, puesto que puede ser perfectamente utilizado este sistema en la creación de otras aplicaciones.

El trabajo diploma esta estructurado en tres capítulos:

Capítulo 1: Fundamentación Teórica.

Se hace un estudio del arte de los sistemas estadísticos para la automatización de índices de precios al consumidor, así como las principales tendencias de la programación hoy en día, y sus características, especialmente de la Programación Orientada a Objetos (POO), se analiza también las ventajas que da la utilización de estándares de programación, la importancia que tiene para el desarrollo de aplicaciones el uso del Proceso Personal de Software (PSP), y el análisis de la eficiencia de los algoritmos, así como una breve descripción de la plataforma utilizada, que actualmente brinda un entorno cómodo y fácil de trabajo.

Capítulo 2: Descripción y análisis de la solución propuesta.

En este capítulo se realiza una descripción de la propuesta de solución al problema planteado en el diseño teórico de la investigación, para ello se expresa una solución concreta del problema, plasmando de esta manera los artefactos generados para dar cumplimiento al módulo nacional IPC, empezando por la

Introducción.

arquitectura definida por el arquitecto, seguido una valoración crítica del modelo de diseño propuesto por el diseñador, estrategias de integración, patrones utilizados, clases u operaciones que permiten dar respuesta de forma rápida y segura a los requisitos planteados por el cliente, la captura de errores, así como la utilización de las distintas actividades y normas planteadas dentro del PSP para el control y planificación de los desarrolladores durante el ciclo de implementación del software.

Capítulo 3: Validación de la solución propuesta.

Este capítulo muestra la validación realizada a la solución propuesta en el capítulo anterior, para ello se analiza la solución concreta del problema, presentando y describiendo las clases de prueba que verifican la validez de los casos de usos (CU) que conforman el módulo nacional IPC, además de una breve descripción de la herramienta utilizada, NUnit Framework.

Capitulo 1. Fundamentación Teórica.

Capítulo 1: Fundamentación Teórica.

1.1 Introducción.

En este capítulo se hará un estudio del estado del arte, el uso de las Tecnología de la Informáticas y las Comunicaciones (TIC), una breve reseña histórica, se hablará del IPC y como se ve esto en el mundo actual, así como maneja la empresa ONE en Cuba esta importante estadística, se darán características especiales de la Programación Orientada a Objetos y sus ventajas, cálculos de eficiencia de algoritmos, y una concepción de la importancia del PSP, también se detallará la herramienta de desarrollo a utilizar, las facilidades que esta proporciona. Entre otras cosas.

1.2 Uso de las TIC. Reseña Histórica.

Se sabe de antemano que en tiempos anteriores para realizar ciertos tipos de trabajos se necesitaba de mucho esfuerzo y tiempo, el nivel de cometer errores era grande y por tanto la calidad y aprovechamiento era malo, hoy en día se ha podido resolver esta problemática, con la aparición de la computadora y los software que en ella se ejecutan, con el uso de las TIC, las condiciones de trabajo han mejorado en un gran nivel. En los primeros días de la computación, las computadoras se usaban principalmente en aplicaciones militares, pues su costo era muy alto. Hoy en día están presentes prácticamente en todas las actividades del hombre. Sin duda alguna, su mayor aplicación se da en ambientes de negocios, en el procesamiento de datos relevantes para actividades administrativas. Esto no hubiese sido posible sin la dedicación y entrega de un grupo de Personas que años tras años lo han entregado todo por mejorar cada día más esta rama. Personas que están integradas a lo que podemos llamar grupos de desarrollo de software las cuales juegan determinados roles dentro del grupo como Analistas, Diseñadores, Arquitectos, Programadores entre otros, dando lugar a la obtención de productos de calidad mediante la programación por mencionar alguna, tarea que desempeña el Programador. [MARE, 1999]

Capitulo 1. Fundamentación Teórica.

1.3 Índices de precios al consumidor IPC.

IPC es la abreviatura de Índice de Precios al Consumidor, Índice de Precios de Consumo o Índice de Precios al Consumo (CPI en inglés).

Es un índice de precios el valor numérico que representa una medida relativa de diferencia de precios de bienes y servicios en diferentes situaciones temporales. Esto es, medir las variaciones de precios de una muestra de productos, (conocida como "canasta" o "cesta") con respecto a un período base determinado.

De esta forma se pretende medir, mensualmente, la evolución del nivel de precios de bienes y servicios de consumo en un país. El objetivo es medir las diferencias de nivel de precios de una canasta con respecto a una región determinada. [ONE, 2000]

1.4 Sistemas actuales para cálculos de IPC en el mundo.

La creación de software para cálculos estadísticos ha sufrido un gran aumento en los últimos años. Este crecimiento se debe al incremento proporcional de las empresas en el mundo. El perfeccionamiento empresarial a nivel mundial constituye una constante evolución, y de ese modo, las organizaciones necesitan de una automática evaluación de todos los aspectos implicados en sus procesos. Precisamente los sistemas estadísticos permiten acceder a un mejor conocimiento de la información contenida en los datos mediante metodologías y procesos de recogida, análisis e interpretación. La evolución del software estadístico en los últimos años ha significado un importante ahorro en tiempo, en precisión y en calidad de los resultados en los procesos de las empresas. [ALFARO, 2001]

En la actualidad, la mayoría de los sistemas estadísticos presentan funcionalidades que permiten el trabajo con indicadores visuales capaces de mostrar al usuario resultados en gráficas, de una forma más amigable. Esta característica la presentan con mayor frecuencia los sistemas que abarcan la estadística descriptiva, o sea, los que trabajan con modelos matemáticos, los que calculan estimaciones, etc.

[ALFARO, 2001]

Capitulo 1. Fundamentación Teórica.

Sin embargo, muchos de los sistemas que se usan para calcular IPC han evolucionado poco dentro del campo estadístico. Esto se debe a que la metodología del IPC no ha variado ni ha sufrido cambios en los últimos 15 años, pero eso si, cada país tiene una forma independiente de recolectar los datos, de procesar las encuestas, entre otros procesos. A continuación se analiza uno de los sistemas utilizados para calcular IPC. [ALFARO, 2001]

En Perú hay implementado un sistema el cual se llama Procesamiento y Difusión del IPC este sistema trae consigo cuatro subsistemas

• Sub-sistema de entrada de datos inteligente.

• Sub-sistema de consistencia analítica.

• Sub-sistema de entrada de cálculo.

• Sub-sistema de entrada de resultados.

Para la realización del mismo se utilizan los cuatros subsistemas, pero se aclara que el proceso automático solo es en el sub-sistema de cálculo. [ALFARO, 2001]

1.5 Sistema para cálculos de IPC en Cuba.

Si se sabe que en el mundo entero existen aplicaciones que realizan cálculos de IPC, entonces porque la empresa ONE no puede adquirir una y resolver su problema, pues, porque como se dijo anteriormente cada país lo hace de manera particular y en Cuba esto se torna un poco más complejo, dado por la existencia de varios mercados y dos tipos de monedas, por lo que la empresa se vio necesitada de ayuda y acudió a la Universidad de las Ciencias Informáticas (UCI), en busca de soluciones, ya que el sistema utilizado para realizar dichos cálculos no es eficiente, siendo así posible la realización de este trabajo diploma.

Capitulo 1. Fundamentación Teórica.

1.6 ¿Que es Programación?

Se llama programación a un conjunto finito de instrucciones que pueden ejecutarse dando lugar a resultados.

En la actualidad la programación ha evolucionado mucho se ha ido perfeccionando en aras de mejores y más óptimos productos con una mayor calidad. Durante años, los programadores se han dedicado a construir aplicaciones muy parecidas que resolvían una y otra vez los mismos problemas. Para conseguir que los esfuerzos de los programadores puedan ser utilizados por otras personas se creó la Programación Orientada a Objetos. Que es una serie de normas de realizar las cosas de manera que otras personas puedan utilizarlas y adelantar su trabajo, de manera que consigamos que el código se pueda reutilizar. La Programación Orientada a Objetos POO surge en Noruega en 1967 con un lenguaje llamado Simula 67, desarrollado por Krinsten Nygaard y Ole-Johan Dahl, en el centro de cálculo noruego. [Programación Orientada a Objeto (POO), 2007]

1.7 ¿Que es la Programación Orientada a Objetos POO?

La POO es una forma especial de programar, más cercana a como expresaríamos las cosas en la vida real. Es una manera de pensar, otra manera de resolver un problema. [ALVAREZ, 2007]

1.8 Paradigmas de la POO.

La POO no es difícil, pero es una manera especial de pensar, a veces subjetiva de quien la programa, de manera que la forma de hacer las cosas puede ser diferente según el programador. Aunque podamos hacer los programas de formas distintas, no todas ellas son correctas, lo difícil no es programar orientado a objetos sino programar bien. Programar bien es importante porque así nos podemos aprovechar de todas las ventajas de la POO. [FERNÁNDEZ, 2007]

Capitulo 1. Fundamentación Teórica.

La POO es un paradigma de la programación de computadores; esto hace referencia al conjunto de teorías, estándares, modelos y métodos que permiten organizar el conocimiento, proporcionando un medio bien definido para visualizar el dominio del problema e implementar en un lenguaje de programación la solución a ese problema. [FERNÁNDEZ, 2007]

La POO se basa en el modelo objeto donde el elemento principal es el objeto, el cual es una unidad que contiene todas sus características y comportamientos en sí misma, lo cual lo hace como un todo independiente pero que se interrelaciona con objetos de su misma clase o de otras clase, como sucede en el mundo real. [FERNÁNDEZ, 2007]

Anterior al paradigma de objetos, está el paradigma algorítmico o de procesos, el cual se fundamenta en los procesos o funciones que se llevan a cabo en el mundo real dentro del dominio del problema analizado. Se refiere a lo que entra, como lo maneja el proceso, y lo que sale del proceso. La programación tradicional la sustentan los procesos, algoritmos, bloques de construcción modulares cuya abstracción va de lo general a lo particular, mientras que en la POO tiene como marco de referencia conceptual el objeto, el cual pertenece a una clase que agrupa a todos compañeros con las mismas características y un comportamiento similar. [FERNÁNDEZ, 2007]

Una ventaja de la POO frente al paradigma algorítmico es la facilidad que brinda a través de sus herramientas, de concebir, analizar, modelar, diseñar e implementar el mundo real de manera fiel a como se presenta en la realidad; el paso que hay desde la concepción y asimilación del problema hasta la implementación del mismo es un proceso que se hace de manera casi natural. Esto porque el mundo está lleno de objetos reales, los cuales se puede representar como tales en una solución computarizada.

[FERNÁNDEZ, 2007]

1.8.1 El Paradigma Concurrente.

Se dice que dos o mas procesos son concurrentes si están construidos de manera tal que pueden ejecutarse al mismo tiempo y compartiendo recursos. Considerando un entorno multi-thread, cada hilo representa un proceso individual ejecutándose en un sistema. Generalmente, cada hilo controla un único aspecto dentro de un programa. Todos los hilos comparten los mismos recursos. [TESO, 2007]

Capitulo 1. Fundamentación Teórica.

1.8.2 El Paradigma Lógico.

Una forma de razonar para resolver problemas en matemáticas se fundamenta en la lógica de primer orden. El conocimiento básico de las matemáticas se puede representar en la lógica en forma de axiomas, a los cuales se la agregan reglas formales para deducir cosas verdaderas (teoremas). Los lenguajes que utilizan esta lógica se llaman lenguajes declarativos, porque todo lo que tiene que hacer el programador para solucionar un problema es describirlo vía axiomas y reglas de deducción. [TESO, 2007]

1.8.3 El Paradigma Funcional.

La programación funcional tiene como objeto imitar las funciones matemáticas lo mas posible. Un lenguaje funcional posee la propiedad matemática de transparencia referencial, lo que significa que una expresión representa siempre el mismo valor. Esto permite razonar sobre la ejecución de un programa y demostrar matemáticamente que es correcto. [TESO, 2007]

Las variables de un lenguaje funcional son como las variables en algebra. Inicialmente representan un valor desconocido que, una vez calculado, ya no cambia. En un programa funcional, el orden de evaluación de las subexpresiones no afecta al resultado final, por lo tanto las subexpresiones pueden ejecutarse en forma paralela para hacer más eficiente el programa. [TESO, 2007]

1.9 Características de la POO.

Se enfatizara de forma breve las características de este tipo de programación, y las ventajas que proporciona la abstracción, encapsulación, modularidad, jerarquización, tipificado, concurrencia, y persistencia. [POL, 1996-1997]

1.9.1 Abstracción.

Denota las características esenciales que distinguen a un objeto de otros tipos de objetos, definiendo precisas fronteras conceptuales, relativas al observador.

Capitulo 1. Fundamentación Teórica.

• Surge del reconocimiento de similaridades entre ciertos objetos, situaciones o procesos en el mundo real.

• Decide concentrarse en estas similaridades e ignorar las diferencias.

• Enfatiza detalles con significado para el usuario, suprimiendo aquellos detalles que, por el momento, son irrelevantes o distraen de lo esencial.

• Deben seguir el "principio de mínimo compromiso", que significa que la interface de un objeto provee su comportamiento esencial, y nada más que eso. Pero también el "principio de mínimo asombro": capturar el comportamiento sin ofrecer sorpresas o efectos laterales. [POL, 1996-1997]

1.9.2 Encapsulación.

Es el proceso de compartimentalización de los elementos de una abstracción que constituyen su estructura y comportamiento. La encapsulación sirve para separar la interface de una abstracción y su implementación.

• Es un concepto complementario al de abstracción.

• La encapsulación esconde la implementación del objeto que no contribuye a sus características esenciales.

• La encapsulación da lugar a que las clases se dividan en dos partes:

1. Interface: captura la visión externa de una clase, abarcando la abstracción del comportamiento común a los ejemplos de esa clase.

2. Implementación: comprende la representación de la abstracción, así como los mecanismos que conducen al comportamiento deseado.

Se conoce también como ocultamiento o privacidad de la información. [POL, 1996-1997]

1.9.3 Modularidad.

Es la propiedad que tiene un sistema que ha sido descompuesto en un conjunto de módulos cohesivos y vagamente conexos.

• Cada módulo se puede compilar separadamente, aunque tengan conexiones con otros módulos.

Capitulo 1. Fundamentación Teórica.

• En un diseño estructural, modularización comprende el agrupamiento significativo de subprogramas. En diseño orientado a objetos, la modularización debe ceñirse a la estructura lógica elegida en el proceso de diseño.

• Dividir un programa en componentes individualizados reduce en alguna manera su complejidad.

• También se separan los módulos interface de los módulos con implementación. [POL, 1996-1997]

1.9.4 Jerarquización.

Es una clasificación u ordenación de las abstracciones.

• Por jerarquía denotamos el orden de relación que se produce entre abstracciones diferentes.

• Los tipos de jerarquía más útiles:

1. Herencia (generalización/especialización, padre/hijo, jerarquía del tipo "es un"...). Una clase (subclase) comparte la estructura o comportamiento definido en otra clase, llamada superclase.

2. Herencia múltiple Una clase comparte la estructura o comportamiento de varias superclases.

3. Agregación Comprende relaciones del tipo "es parte de" al realizar una descomposición.

Relaciones entre los conceptos asociados al modelo de objetos.

• Los conceptos de abstracción y encapsulación son conceptos complementarios: abstracción hace referencia al comportamiento observable de un objeto, mientras encapsulación hace referencia a la implementación que la hace alcanzar este comportamiento.

• Existe una tensión entre los conceptos de encapsulación de la información y el concepto de jerarquía de herencia, que requiere una apertura en el acceso a la información.

• Ofrece mucha flexibilidad, pudiendo disponer de tres compartimentos en cada clase:

1. Privado: declaraciones accesibles sólo a la clase (completamente encapsulado) 2. Protegido: declaraciones accesibles a la clase y a sus subclases.

3. Público: declaraciones accesibles a todos los clientes.

Capitulo 1. Fundamentación Teórica.

Además de estos tres tipos, soporta la definición de clases cooperativas a las que se les permite acceder a la parte privada de la implementación.

[POL, 1996-1997]

1.9.5 Tipificado.

Tipificar es la imposición de una clase a un objeto, de tal modo que objetos de diferentes tipos no se puedan intercambiar, o se puedan intercambiar solo de forma restringida.

• Tipo es una caracterización precisa de las propiedades estructurales y de comportamiento que comparten una colección de entidades.

• Grosso modo, tipo y clase pueden considerarse sinónimos.

• Existen lenguajes fuertemente tipificados (Ada) y débilmente tipificados. Estos últimos soportan polimorfismo, mientras que los fuertemente tipificados no. [POL, 1996-1997]

1.9.6 Concurrencia.

Es la propiedad que distingue un objeto activo de uno no activo. Concurrencia permite que diferentes objetos actúen al mismo tiempo, usando distintos threads de control. [POL, 1996-1997]

1.9.7 Persistencia.

Es la propiedad por la cual la existencia de un objeto trasciende en el tiempo (esto es, el objeto sigue existiendo después de que su creador deja de existir) o en el espacio (esto es, la localización del objeto cambia respecto a la dirección en la que fue creado). [POL, 1996-1997]

1.10 Beneficios de los estándares de codificación.

Esto es uno de los factores claves para obtener calidad en un producto, y se ha venido perfeccionando con el transcurso de los tiempos, en la actualidad se habla mucho acerca del peso que tiene esto para las aplicaciones. [TORRES, 2006]

Facilitando en gran medida el entendimiento de las aplicaciones así como su fácil mantenimiento, pudiendo reutilizar su código en nuevos sistemas. Usando estándares estamos siguiendo un patrón que

Capitulo 1. Fundamentación Teórica.

nos asegura que un futuro nuestra aplicación seguirá viéndose exactamente igual y funcionando exactamente igual. [TORRES, 2006]

Un estándar de codificación completo comprende todos los aspectos de la generación de código. Si bien los programadores deben implementar un estándar de forma prudente, éste debe tender siempre a lo práctico. Un código fuente completo debe reflejar un estilo armonioso, como si un único programador hubiera escrito todo el código de una sola vez. Importante para cuando en un sistema trabaje más de un programador, parezca que solo uno lo ha hecho todo. [TORRES, 2006]

Al comenzar un proyecto de software, establezca un estándar de codificación para asegurarse de que todos los programadores del proyecto trabajen de forma coordinada. [TORRES, 2006]

Cuando el proyecto de software incorpore código fuente previo, o bien cuando realice el mantenimiento de un sistema de software creado anteriormente, el estándar de codificación debería establecer cómo operar con la base de código existente. [TORRES, 2006]

La legibilidad del código fuente repercute directamente en lo bien que un programador comprende un sistema de software. La mantenibilidad del código es la facilidad con que el sistema de software puede modificarse para añadirle nuevas características, modificar las ya existentes, depurar errores, o mejorar el rendimiento. [TORRES, 2006]

Aunque la legibilidad y la mantenibilidad son el resultado de muchos factores, una faceta del desarrollo de software en la que todos los programadores influyen especialmente es en la técnica de codificación. El mejor método para asegurarse de que un equipo de programadores mantenga un código de calidad es establecer un estándar de codificación sobre el que se efectuarán luego revisiones del código de rutinas.

[TORRES, 2006]

Usar técnicas de codificación sólidas y realizar buenas prácticas de programación con vistas a generar un código de alta calidad es de gran importancia para la calidad del software y para obtener un buen rendimiento. Además, si se aplica de forma continuada un estándar de codificación bien definido, se utilizan técnicas de programación apropiadas, y, posteriormente, se efectúan revisiones del código de

Capitulo 1. Fundamentación Teórica.

rutinas, caben muchas posibilidades de que un proyecto de software se convierta en un sistema de software fácil de comprender y de mantener. [TORRES, 2006]

Aunque el propósito principal para llevar a cabo revisiones del código a lo largo de todo el desarrollo es localizar defectos en el mismo, las revisiones también pueden afianzar los estándares de codificación de manera uniforme. La adopción de un estándar de codificación sólo es viable si se sigue desde el principio hasta el final del proyecto de software. No es práctico, ni prudente, imponer un estándar de codificación una vez iniciado el trabajo. [TORRES, 2006]

1.11 Análisis de la eficiencia de algoritmos.

Todos los problemas de la matemática y la lógica podrán ser resueltos mediante algoritmos. Sin embargo no todas las soluciones son igualmente eficientes.

Normalmente los algoritmos de interés reciben una serie de datos de volumen o tamaño N dado. De hecho es posible tener infinidad de algoritmos que resuelvan el mismo problema.

Cada método se tomará más o menos unidades de tiempo en hacerlo. Si el algoritmo tiene que evaluar una muestra de entrada extensa, obviamente, su tiempo de ejecución dependerá de la cantidad de elementos en la muestra de entrada (N). En muchos casos existe una dependencia clara de la cantidad de elementos en la muestra de entrada, en otros la dependencia es del valor de ese dato de entrada. En general, tenemos que el tiempo de ejecución de un programa dependerá del ‘tamaño’ de los datos de entrada. A esta dependencia se la llama complejidad temporal y se la suele expresar como tiempo de ejecución en alguna unidad de tiempo = T(N). Se la distingue de la complejidad espacial que nos da la dependencia del espacio necesitado por el algoritmo según el tamaño de la muestra de entrada.

Realmente en la práctica no se trabaja con T(N) sino con funciones que clasifiquen estas funciones acotando su valor asintóticamente. Se dirá que un algoritmo es eficiente si al aumentar el tamaño de la muestra de la entrada, el tiempo de ejecución crece de forma tan sólo polinomial en función de aquel tamaño. En otro caso, si el crecimiento es de tipo exponencial (más exactamente O(n elevado a k b elevado n)), se dice que es ineficiente o intratable. Esto es así porque en estos últimos algoritmos, tamaños no muy grandes de la entrada dan tiempos de ejecución de días. . . aún en las máquinas más rápidas. El tiempo de ejecución se puede mejorar (quizás con paralelismo, etc.) de forma lineal o

Capitulo 1. Fundamentación Teórica.

polinomial pero nunca se puede conseguir una mejora en hardware que reduzca la tendencia exponencial.

[PÉREZ et al., 2007]

Como hemos visto, en principio puede suponerse que para cualquier problema resoluble (atención, hemos dicho resoluble), existe un algoritmo y una máquina que lo resuelve. La teoría que estudia la posible algoritmización de la solución a un problema se le denomina computabilidad. Otro problema, aparte de la computabilidad, es la complejidad (en términos de espacio y tiempo) de los algoritmos para resolver los problemas, y de los propios problemas (con modelos independientes de la máquina que los ejecute).

Hemos visto que existen problemas cuya solución se retrasa en función de “b elevado a n” o incluso “n elevado a n” términos a tener en cuenta, son algoritmos exponenciales. La solución es ineficiente o inadecuada computacionalmente. Otros algoritmos, sin embargo tienen un comportamiento “más sensato”, tardando del orden de “n elevado a c”, se les llama polinómicos y se consideran adecuados y más o menos eficientes. [PÉREZ et al., 2007]

1.11.1

Eficiencia de un programa.

Decimos que un programa es eficiente cuando consume pocos recursos durante su ejecución. Durante su ejecución, un programa consume básicamente dos recursos:

• Tiempo del procesador - coste temporal

• Espacio en memoria - coste espacial [PÉREZ et al., 2007]

1.11.2 Factores de dependencia.

• El algoritmo utilizado.

• El tamaño de la entrada o complejidad del problema a resolver. El tamaño de la entrada es una medida de la cantidad de datos que deberán procesarse.

• Características de la máquina donde se ejecuta

• Calidad del software de desarrollo usado en la implementación [PÉREZ et al., 2007]

Capitulo 1. Fundamentación Teórica.

1.11.3 Expresiones y sintaxis de la eficiencia.

El tiempo de ejecución y el espacio de memoria requeridos por un programa se expresan en función del tamaño de los datos de entrada n. Esto es así porque el tamaño de los datos es lo que afecta en mayor medida al consumo de recursos de un programa. Si cambiamos de máquina o compilador, el consumo de recursos varía, a lo sumo, en un factor constante.

El hecho anterior se enuncia como el Teorema de la Invarianza:

El teorema de la Invarianza: establece que al cambiar de lenguaje, compilador o máquina, el consumo de recursos se multiplica o divide a lo sumo por una constante. Por lo tanto, factores ligados a la máquina donde se ejecuta el programa o al software de desarrollo utilizado, tienen una repercusión moderada en el consumo de recursos. [PÉREZ et al., 2007]

En cambio, la dependencia del tamaño de los datos presenta con frecuencia otro comportamiento. Para muchos algoritmos, al incrementar un poco el tamaño de los datos, el tiempo y la memoria consumidos crecen de forma exagerada: se duplican, se triplican, crecen de forma exponencial, etc. El hecho de expresar la eficiencia de un algoritmo en función del tamaño de los datos de entrada es algo bastante lógico, porque el tamaño de los datos determina, por un lado, la cantidad de instrucciones que tiene que ejecutar el programa, y por otro, la cantidad de elementos que tiene que almacenar. [PÉREZ et al., 2007]

1.11.4

Teoría de los casos.

A la hora de expresar la eficiencia de un programa, aún hay otra decisión a tomar. El consumo de recursos no sólo depende del tamaño de los datos, sino también de las características de los datos.

[PÉREZ et al., 2007]

1.11.5 Métodos del cálculo de la eficiencia.

Básicamente hay dos métodos:

Capitulo 1. Fundamentación Teórica.

• Implementar el programa y probarlo (prueba empírica)

• Analizar el algoritmo en el que se basa el programa (análisis del algoritmo)

La prueba empírica consiste en implementar y ejecutar el programa y medir el tiempo y el espacio en una máquina concreta y con unos datos concretos.

El análisis de la complejidad del algoritmo consiste en estimar el tiempo y el espacio a partir del análisis de las instrucciones que componen el algoritmo en el que se basa el programa. [PÉREZ et al., 2007]

1.11.6 Cálculo de la complejidad temporal.

Básicamente existen dos formas de analizar la complejidad temporal de un algoritmo:

• Contar el número de instrucciones que se ejecutan (en función del tamaño de entrada n)

• Analizar el comportamiento asintótico del algoritmo (qué pasa cuando n tiene a infinito) [PÉREZ et al., 2007]

1.11.7 Cálculo de la complejidad espacial.

Dado un algoritmo, nos interesa conocer su complejidad espacial, es decir, clasificar su coste espacial E(n) en una de las formas de crecimiento. Como ya se ha señalado, calcularemos siempre el coste para el caso peor, y trataremos de establecer una cota superior a E(n) usando una notación asintótica. [PÉREZ et al., 2007]

Un programa puede requerir memoria para muchos conceptos distintos:

• Variables estáticas y locales (heap)

• Variables dinámicas (pila)

• Parámetros de funciones (pila)

Un programa durante su ejecución no consume una cantidad de memoria fija, sino que depende de las

Capitulo 1. Fundamentación Teórica.

complicar considerablemente el análisis. Sin embargo, hay un caso sencillo: los algoritmos no recursivos que no utilizan memoria dinámica. En estos casos, para calcular la complejidad espacial de un algoritmo deben seguirse las siguientes reglas obvias:

• Una variable de tipo elemental ocupa una cantidad constante.

• Una variable de tipo tabla de n elementos ocupa n veces el espacio de cada elemento. [PÉREZ et al., 2007]

1.12 Importancia del Proceso de Software Personal en el desarrollo de sistemas.

“Mayor calidad y reducir el costo”

La calidad del software es el grado con el que un sistema, componente o proceso cumple los requerimientos especificados y las necesidades o expectativas del cliente.

En la actualidad Ing. de experiencia introducen entre 7 y 10 defectos por línea de código, la mayoría de estos defectos son detectados en las pruebas.

Muchas organizaciones concentran sus esfuerzos en arreglar los errores en vez de prevenirlos.

Por lo tanto surge la necesidad de hacer planes ajustados, realizar detalles en el diseño, eliminación temprana de los defectos, inspecciones efectivas, y muy importante centrarse en la calidad todo el tiempo.

[HUMPHREY, 2001]

Por tanto se necesita:

• Una infraestructura y ambiente que los soporte.

• Procesos (reglas y pasos) para ponerlos en práctica.

• Un sistema de métricas para gestionar y controlar los resultados.

Para esto tenemos el Proceso de Software Personal (PSP)

Que no es más que las habilidades individuales y la disciplina que debe tener un desarrollador de software, es exigirse uno mismo. Ser más crítico con su trabajo conocerse uno mismo. [HUMPHREY, 2001]

Capitulo 1. Fundamentación Teórica.

1.12.1 Paradigma del PSP.

• Se definen metas de procesos individuales

• Cada cual define los métodos que usa

• Miden su trabajo individualmente

• Analizan sus resultados

•

1.12.2 Principios del PSP.

• La calidad de un sistema de software está regida por la calidad del proceso utilizado para desarrollarlo.

• La calidad de un sistema de software está regida por la calidad de sus peores componentes.

• La calidad de un componente de software está regida por el individuo que lo desarrolló.

• Esto está regido por el conocimiento, disciplina y compromiso del individuo. [HUMPHREY, 2001]

• Cómo un profesional del software, debe conocer su propia productividad.

• Se debe medir, registrar y analizar el trabajo.

• Se debe aprender de las variaciones de la productividad.

• Se debe incorporar estas lecciones en las prácticas personales. [HUMPHREY, 2001]

1.12.3 Gestión del Tiempo.

• Para hacer un plan realista, tienes que controlar la forma en que usas tu tiempo

• Debes estimar la exactitud de tus estimaciones.

• Determinar equivocaciones en los planes anteriores.

• Clasifica tus principales actividades.

• Registra el tiempo dedicado a cada una de las actividades principales.

• Registra el tiempo de forma normalizada.

Capitulo 1. Fundamentación Teórica.

•

1.12.4 Ideas para registrar el tiempo.

• Lleva siempre contigo el cuaderno de notas.

• Si olvidas registrar, haz una estimación en cuanto lo recuerdes.

• Utiliza un cronómetro para las interrupciones.

•

1.12.5 La Gestión de compromisos.

• ¿Qué se hará?

• Criterios para determinar lo que está hecho.

• ¿Quien lo hará?

•

1.12.6 Pasos para gestionar un compromiso.

• Hacer una lista de los compromisos actuales.

• Incluir Qué y para Cuando es el nuevo compromiso.

• Incluir estimación de cuanto trabajo te supondrá cada compromiso. [HUMPHREY, 2001]

1.12.7 Tips para la gestión de compromisos.

• Detectar si te estas retrasando

• Intentarlo más duramente no ayudará

• Define en que lugar del proyecto estas y que tiempo te queda

• No confíes en la suerte

• Estimaciones erróneas = estimaciones bajas

• Cambio, implica trabajo [HUMPHREY, 2001]

Capitulo 1. Fundamentación Teórica.

El PSP no es más que un motor pequeño que guía a cada uno con vista a realizar un trabajo más rápido, óptimo y con posibilidad de pocos errores, pero de manera personal, para lo que después viniese siendo el motor mayor el Proceso de Software en Equipo (TSP) con una mayor claridad y compenetración, lo que arrojara en un futuro mejores resultados.

1.13 Análisis de la plataforma Microsoft Visual Studio 2005.

Una vez expuestas algunas de las características que debe de tener un sistema para su calidad y eficiencia, y de esta manera proponer ya una posible solucionar a nuestro problema, creo que debemos mencionar el uso de las plataformas para desarrollar sistemas, ya que sin ellas tampoco seria posible la implementación de aplicaciones.

En la actualidad existen varias plataformas para el desarrollo de software las cuales poseen diferentes características y con diferentes potencialidades después de hacer un estudio de las mismas llegamos a la conclusión y es a la que me quiero referir, la plataforma utilizada en la solución de nuestro problema será Microsoft Visual Studio 2005 dentro de ella utilizaremos el lenguaje de programación Microsoft Visual C #.

Con Visual Studio 2005, Microsoft incorpora nuevas características y tecnologías que admiten el desarrollo de aplicaciones en todas las fases del ciclo de vida del software, desde su desarrollo hasta la fase de implantación, permitiendo una completa plataforma de desarrollo que satisfaga a los desarrolladores en todos los niveles. [IZQUIERDO, 2007]

También proporciona nuevas y avanzadas características para los desarrolladores de software. Con herramientas de calidad, desarrollo y diseño de aplicación altamente integradas, así como metodología de proceso de software personalizable. Ofrece a los equipos de desarrollo las herramientas y los procesos que les ayudarán a predecir que un proyecto será exitoso, a ganar en eficiencia organizacional y a reducir los costes totales de desarrollo. [IZQUIERDO, 2007]

Visual Studio es una plataforma multilenguaje, proporciona la (POO), es compatible con otras aplicaciones, proporciona una gran cantidad de librerías y funciones que no ahorra trabajo y por tanto

Capitulo 1. Fundamentación Teórica.

integración de lo mejor de otros lenguajes. Aunque debemos de reconocer que se necesita una máquina potente para que pueda correr sin problemas y el trabajo no se haga lento y tedioso. Por tanto trabajaremos sobre esta plataforma utilizando el Microsoft Visual C# como lenguaje de programación debido a las potencialidades que este nos brinda.

1.14 Conclusiones.

Se hace referencia de esta manera a las características principales de la programación hoy en día, la importancia que esta jugando para el desarrollo de aplicaciones la programación orientada a objetos POO por sus grandes ventajas, el papel que juega la buena selección de la plataforma de trabajo, el uso del PSP y sus tablas, la utilización de patrones correctamente, etc.

Si se tiene en cuenta todos estos detalles mencionados anteriormente, se creará una base más sólida y factible para lograr el éxito. Ahora bien para ello se debe contar con algo muy importante que hasta ahora no se ha visto y es la propuesta de solución al problema dado, se debe tener convicciones clara de lo que se quiere y como se quiere para llegar a realizar una buena propuesta que satisfaga y erradique el problema planteado.

Capitulo 2. Descripción y análisis de la solución propuesta.

Capítulo 2: Descripción y análisis de la solución propuesta.

2.1 Introducción.

En este capítulo se dará una panorámica de cómo se dio respuesta al problema, la solución propuesta, para ello se abordará temas, sin los cuales no hubiese sido posible la realización del sistema, se hablará de la arquitectura, sus estilos, se hará una valoración critica del diseño propuesto por al analista paso fundamental para el cumplimiento de los requisitos de forma correcta.

También tratará sobre las estrategias de integración que conforman nuestro sistema y la importancia de las mismas para mayor organización y rapidez de la aplicación. Se Menciona además los patrones que tuvimos en cuenta a la hora de programar el sistema.

Como detalle importante se debe hablar de las Capas que fueron definidas por el arquitecto dentro de estas, capa de Presentación la cual brinda interfaces que le permiten al usuario intercambiar con el sistema, y la capa de Negocio que contiene clases controladoras encargadas de manejar toda la lógica del negocio de la aplicación. Se dará a conocer también algunos de los algoritmos y estructuras de datos que fueron utilizados en nuestro sistema, así como una descripción de las clases u operaciones que nos fueron útiles para dar cumplimiento a nuestros objetivos, y como aspecto fundamental abordará sobre el Proceso de Software Personal PSP y sus tablas.

2.2 Estilo Arquitectónico.

Existen varios lugares donde la arquitectura esta presente, aquí se verá en el desarrollo de aplicaciones informáticas, sin lugar a duda lo que la convierte en una herramienta de puntería para la organización del trabajo, partiendo de esto podemos decir que hay diferentes caminos por lo cual guiar un trabajo o un proyecto etc. Para el desarrollo de aplicaciones hay creados diferentes estilos arquitectónicos los cuales solucionan un problema, en dependencia de las características del mismo, ejemplo de esto tenemos el