Capitulo II. Fundamentos teóricos

Transcripción

1 8 Capitulo II Fundamentos teóricos 2.1 Antecedentes En el ámbito internacional Rojas (1997) [1], en la revista de las marina de chile, publico un articulo titulado La Administración de Almacenes el cual dice que el sistema modular de control de almacenes es la nueva versión requerida para la optimización de la administración de almacenes de materias primas tanto de producción como de mantenimiento. Este involucra herramientas tecnológicas actuales (computadoras, bases de datos relacionales, sistemas integrados, ambientes cliente/servidor), y la compatibilidad con las nuevas posibilidades de procesamiento electrónico; aplicación de códigos de barra, su impresión y los scanner de lectura (fijos, recolectores móviles, y el enlace por radio frecuencia), así como el intercambio electrónico de datos e Internet para los procesos de adquisiciones. Este trabajo realiza un aporte teórico al desarrollo del proyecto pues muestra las principales características que requieren los sistemas para el control de almacenes con el fin de obtener un mejor rendimiento de los procesos que se llevan a cabo en estos. A nivel nacional se hace referencia al trabajo de Castro (2006)[3] presentado en la Universidad de los Andes y que lleva por titulo Caracterización del desempeño de las metodologías ágiles en el desarrollo de un producto de software pequeño. Se desarrollan dos productos de software, el primero es el resultado obtenido por la aplicación de la programación extrema (XP), siendo este el representante de las metodologías ágiles, el cual es contrastado frente al desarrollo de un segundo producto, con un enfoque clásico, representado por el modelo watch component. Este análisis permite descubrir en detalle los beneficios y limitaciones de

2 9 la aplicación de método ágil seleccionado, al momento de desarrollar un proyecto pequeño. Una propuesta muy equilibrada para un posible modelo híbrido de desarrollo, se encuentra la integración de las características de ambos enfoques (ágiles y tradicionales) con el principio fundamental de enfrentar o cubrir una gama más amplia de proyectos, que intente satisfacer una mayor diversidad de situaciones encontradas en un determinado proyecto de desarrollo. Las bondades de un modelo híbrido se pueden considerar como una buena oferta de equilibrio, que disminuyan la frecuente toma de decisiones que conducen a los procesos de desarrollo a situarse dentro de esquemas de alto riesgo, donde habitualmente se compromete la calidad y el tiempo de entrega del producto. El aporte realizado por este trabajo de investigación permitió determinar las ventajas y desventajas del uso de la metodología XP para el desarrollo de software con respecto a las metodologías tradicionales. El trabajo de Rojas (2005)[4] realizado el la Universidad de los Andes, Mérida, titulado Sistema de información Web para la gestión y control de contratos e inventario de la dirección de ingeniería y mantenimiento de la Universidad de Los Andes, trata lo siguiente: la Dirección de Ingeniería y mantenimiento es una dependencia adscrita al Vicerrectorado Administrativo de la Universidad de Los Andes, sus objetivos como organización se fundamentan en planificar, proyectar, remodelar, construir y dar mantenimiento a las edificaciones que constituyen la planta física de la universidad; desarrollando y llevando a cabo proyectos con calidad eficiencia y economía de los recursos asignados en el menor tiempo posible. En tal sentido, la dirección de Ingeniería y Mantenimiento de la Universidad de Los Andes (DIMULA) debe mantener un control del inventario de su almacén y de las obras contratadas, de manera que se pueda suministrar con el menor retardo posible los materiales necesarios para la ejecución de obras bajo su cargo y vigilar el desempeño de los contratistas a cargo de tales obras. Actualmente, la DIMULA lleva este control de manera manual, es por esa razón que se presenta el proyecto de desarrollo

3 10 evolutivo de un sistema de información para la gestión y control de contratos e inventario (SIGCCI) que apoyará los procesos descritos anteriormente. Este es un sistema construido bajo la metodología del Proceso Unificado de Racional (RUP), modelado y documentado bajo el lenguaje unificado de modelado (UML), implantado bajo la plataforma Linux, programado con el lenguaje de programación PHP y cuyos datos son almacenados en una base de datos MySQL. Este trabajo ofrece un aporte teórico, tanto desde el punto de vista del desarrollo de sistemas de gestión y control de inventarios, como del desarrollo de software usando UML como herramienta de modelado y documentación del mismo. En el ámbito local se reseña como antecedente el trabajo de Carvajal (2005) [5] que lleva por titulo Sistema de información en plataforma Web para la gerencia de inventario que se basa en proporcionar una herramienta gratuita para la gestión de inventario de los pequeños y medianos empresarios que contribuya al crecimiento de este sector y al aumento de su productividad. El resultado de esta investigación lo constituye un Software desarrollado bajo plataforma Web, donde se utilizaron herramientas como PHP para el lenguaje de programación instalado en un servidor Apache, en cuanto al diseño de la aplicación se trabajó con MACROMEDIA Studio MX 2004 y para la administración de la Base de Datos se utilizo el Sistema Gestor de Bases de Datos SQL "MySQL versión 1.4", dando esto como producto final una herramienta que permite realizar la gestión comercial de inventario, brindando información de apoyo en la toma de decisiones gerenciales. La reseña a este antecedente proporcionó una visión de lo que buscan las pequeñas y medianas empresas en cuanto a la administración de almacenes y como contribuyen los sistemas de información al mejoramiento de la productividad gerencial las organizaciones.

4 11 En el centro médico Dr. Pablo Puky no se habían desarrollado trabajos relacionados con el manejo de inventario por lo que no hubo un aporte desde este punto de vista por parte de la organización. 2.2 Marco teórico Requerimientos del sistema Según Sommerville (2005) [7], los requerimientos del sistema especifican que es lo que el sistema debe hacer (sus funciones) y sus propiedades esenciales y deseables. Como en el análisis de requerimientos del software, crear definiciones de requerimientos de sistema requiere consultar con los clientes del sistema y los usuarios finales. Esta fase de definición de requerimientos usualmente se concentra en la derivación de tres tipos de requerimientos: - Requerimientos funcionales abstractos. Las funciones básicas que el sistema debe proporcionar se definen en un nivel abstracto. Una especificación mas detallada de los requerimientos funcionales tiene lugar en el nivel de subsistemas. Por ejemplo, en un sistema de control de tráfico aéreo, un requerimiento funcional abstracto especificara que una base de datos debe usarse para almacenar los planes de vuelo de todos los aviones que entran al espacio aéreo controlado. Sin embargo, normalmente no se especificarían los detalles de la base de datos a menos que afecten a los requerimientos de otros sistemas. - Propiedades del sistema: Son propiedades emergententes no funcionales del sistema, tales como la disponibilidad, el rendimiento y la seguridad. Estas propiedades no funcionales del sistema afectan a los requerimientos de todos los subsistemas.

5 12 - Características que no debe mostrar el sistema: Algunas veces es tan importante especificar lo que el sistema debe hacer como lo que no debe hacer. Por ejemplo, si esta especificando un sistema de control de tráfico aéreo, puede especificar que el sistema no debe presentar demasiada información al controlador Análisis de requerimientos y especificación del sistema Según Bergner y otros (1997) [8], durante el análisis de requerimiento y especificación del sistema, un común entendimiento de las funcionalidades del sistema debe ser establecido, entre clientes y desarrolladores. La descripción técnica debe, por lo tanto, ser simple y entendible por personas sin experiencia en el modelado orientado a objetos. Una estrategia básica para el análisis es construir el diagrama de caso de uso y el diagrama de clases como modelos centrales a los cuales se agregan diagramas suplementarios más concretos y complejos El plan de proyecto Whitten y otros (1996) [9] dicen lo siguiente, si se recomienda una mejora o un nuevo desarrollo el analista de sistemas (o el gestor de proyectos) tendrá que desarrollar un plan de proyecto inicial (y, si es preciso, revisar la estimación original de envergadura del proyecto). La palabra inicial no debe acentuarse en exceso. En esta etapa del ciclo de vida, sabemos demasiado poco como para predecir costes o calendarios. Un plan inicial de proyecto debería constar de lo siguiente: - Un primer borrador del plan y el calendario maestros para llevar a cabo todo el proyecto. Este calendario será modificado al final de cada fase del proyecto.

6 13 - Un plan y un calendario detallados para la terminación de la siguiente fase del proyecto. En la mayoría de los casos este calendario será mas exacto pero aun sufrirá las consecuencias de la falta de conocimiento detallado sobre el sistema actual y las necesidades de usuario. El plan de proyecto se basa en a experiencia y en las estimaciones de tamaño y modelos de sistemas propuestos y las soluciones posibles UML El lenguaje unificado de modelado (UML), es un lenguaje visual de modelado de propósito general que permite especificar, visualizar, construir y documentar sistemas de software. Esta destinado a ser usado con todos los métodos de desarrollo y fases del ciclo de vida. Las especificaciones del UML no tienen un proceso estándar definido pero esta destinado a ser útil con un proceso de desarrollo iterativo y a soportar la mayoría de los procesos de desarrollo orientados a objetos. El UML captura información acerca de la estructura estática y dinámica del comportamiento del sistema. Un sistema es modelado como una colección discreta de elementos que trabajan para conseguir en última instancia beneficios para los usuarios finales. La estructura estática define los tipos de objetos importantes y su implementación, así como la relación entre los objetos. El comportamiento dinámico define la historia de los objetos en tiempo y la comunicación que hay entre ellos para completar las metas. El UML también permite organizar los modelos en paquetes lo que permite a los equipos de software dividir sistemas grandes en piezas más simples de trabajar, para comprender y controlar dependencias entre los paquetes, y la administración de versiones de los modelos en un entorno de desarrollo complejo. Rumbaugh y otros (1999) [10].

7 Vista de Caso de Uso La vista de Caso de Uso captura el comportamiento de un sistema, subsistema o clase desde el punto de vista del usuario. Dividir el sistema en partes significativas para los actores que idealizan los usuarios del sistema. Las piezas de funcionalidad interactiva son llamadas casos de uso. Un caso de uso describe una interacción con los actores como una secuencia de mensajes entre el sistema y uno o más actores. El termino actores incluye humanos, así como otros sistemas de computadoras y procesos. Texto citado [10] Actores Un actor es una representación de una persona externa, proceso o cualquier cosa que interactué con un sistema, subsistema o clase. Un actor caracteriza la interacción que el usuario tiene con el sistema. Un usuario físico puede ser representado por múltiples actores en el sistema. Diferentes usuarios pueden ser vinculados con un solo actor y por tanto representados por múltiples instancias del mismo actor. Texto citado [10]. Un actor se representa como un hombre palo (stickman) con un nombre representativo debajo Caso de Uso Un caso de uso es una unidad coherente de una funcionalidad visible desde el exterior proveída por un sistema y expresada por una secuencia de mensajes intercambiados entre el sistema y uno o más actores del sistema. El propósito del caso de uso es definir una parte de comportamiento coherente sin revelar la estructura interna del sistema. La definición del caso de uso incluye todos los posibles

8 15 escenarios, la línea principal de secuencias, diferentes variaciones o comportamiento normal, y todas las condiciones excepcionales que puedan ocurrir con dicho comportamiento, junto con la respuesta deseada. Desde el punto de vista del usuario estas son situaciones anómalas. Desde el punto de vista del sistema estas son variaciones que deben ser descritas y controladas. Texto citado [10] Modelo de Caso de uso Muestra los usuarios y usos de todo el sistema. Los casos de uso con un comportamiento dinámico no trivial son especificados en el futuro con los diagramas de actividades, diagramas de secuencia y prototipos de interfaz de usuario. Los modelos de casos de uso son usualmente fáciles de entender por los clientes ya que no tienen una sintaxis compleja y concierne a tareas y procedimientos con los cuales están familiarizados ya que es su trabajo diario Diagrama de Clases El diagrama de clases es el mas común encontrado en los sistemas orientados a objetos. El diagrama de clases muestra un conjunto de clases, interfaces, y colaboraciones y sus relaciones. Un diagrama de clases describe los objetos en el sistema y los diferentes tipos de relaciones estáticas que existen entre ellos. Los dos principales tipos de relaciones estáticas son: asociaciones (por ejemplo, un cliente alquila un numero de videos) y subtipos (una enfermera es un tipo de persona). Los diagramas de clase también muestran los atributos y operaciones de una clase y las restricciones que aplican a la forma en que los objetos se conectan. Fowler y Scott (1999) [11].

9 Modelos del Proceso del software Según Sommerville (2005) [7], Un Proceso del software es un conjunto de actividades que conducen a la creación de un producto de software. Según el mismo autor No existe un proceso ideal, y muchas organizaciones han desarrollado su propio enfoque para el desarrollo del software. Para algunos sistemas, como los sistemas críticos, se requiere un proceso de desarrollo muy estructurado. Para sistemas de negocio, con requerimientos rápidamente cambiantes, un proceso flexible y ágil probablemente sea más efectivo. Aunque existen muchos procesos diferentes de software, algunas actividades fundamentales son comunes para todos ellos: - Especificación del software: Se debe definir la funcionalidad del software y las restricciones en su operación. - Diseño e implementación del software: Se debe producir software que cumpla su especificación. - Validación del software: Se debe validar el software para asegurar que hace lo que el cliente desea. - Evolución del software: El software debe evolucionar para cubrir las necesidades cambiantes del cliente Desarrollo Evolutivo El desarrollo evolutivo se basa en la idea de desarrollar una implementación inicial, exponiéndola a los comentarios de los usuarios y refinándolas a través de las diferentes versiones hasta que se desarrolla un sistema adecuado. Las actividades de especificación, desarrollo y validación se entrelazan en vez de separarse, con una rápida retroalimentación entre estas.

10 17 Existen dos tipos de desarrollo evolutivo: - Desarrollo exploratorio, donde el objetivo del proceso es trabajar con el cliente para explorar sus requerimientos y entregar un sistema final. El desarrollo empieza con las partes del sistema que se comprenden mejor. El sistema evoluciona agregando nuevos atributos propuestos por el cliente. - Prototipos desechables, donde el objetivo del proceso de desarrollo evolutivo es comprender los requerimientos del cliente y entonces desarrollar una definición mejorada de los requerimientos del sistema. El prototipo se centra en experimentar con los requerimientos del cliente que no se comprenden del todo. La ventaja de un proceso del software que se basa en un enfoque evolutivo es que la especificación se puede desarrollar de forma creciente. Tan pronto como los usuarios desarrollen un mejor entendimiento de su problema, este se puede reflejar en el sistema de software sin embargo desde una perspectiva de ingeniería y de gestión, el enfoque evolutivo tiene dos problemas: - El proceso no es visible. Los administradores tienen que hacer entregas regulares para medir el progreso. Si los sistemas se desarrollan rápidamente, no es rentable producir documentos que reflejen cada versión del sistema. - A menudo los sistemas tienen una infraestructura deficiente. Los cambios continuos tienden a corromper la estructura del software. Incorporar cambios en él, se convierte cada vez mas en una tarea difícil y costosa. Para sistemas pequeños y de tamaño medio (hasta líneas de código), el enfoque evolutivo de desarrollo es el mejor. Los problemas del desarrollo evolutivo se hacen particularmente agudos para sistemas grandes y complejos con un periodo

11 18 de vida largo, donde diferentes equipos desarrollan distintas partes del sistema. Texto citado [7] Ingeniería del software basada en componentes En la mayoría de los proyectos de software existe algo de reutilización de software. Por lo general esto sucede informalmente cuando las personas que trabajan en el proyecto conocen diseños o códigos similares al requerido y los incorporan al sistema. Este enfoque basado en la reutilización se compone de una gran base de componentes software reutilizable y de algunos marcos de trabajo de integración para estos. Algunas veces estos componentes son sistemas por si mismo que se pueden utilizar para proporcionar una funcionalidad especifica, como dar formato al texto o efectuar cálculos numéricos. La ingeniería del software basada en componentes tiene la ventaja obvia de reducir la cantidad de software a desarrollarse y así reduce los costos y los riesgos. Por lo general también permite una entrega más rápida del software. Sin embargo, los compromisos en los requerimientos son inevitables, y esto puede dar lugar a un sistema que no cumpla las necesidades reales de los usuarios. Más aun, si las nuevas versiones de los componentes reutilizables no están bajo el control de la organización que los utiliza, se pierde parte de control sobre la evolución del sistema. Texto citado [7].

12 Programación Extrema La programación extrema (XP) es actualmente una deliberada y disciplinada propuesta para el desarrollo de software. Hace 5 años esta siendo probada por compañías como Bayerische Landesbank, Credit Suizo Life, DaimlerChrysler, First Union National Bank y Ford Motor Company. XP es exitosa porque hace énfasis en la satisfacción del cliente. La metodología esta diseñada para entregar al cliente el software que necesite cuando lo necesite. XP Autoriza a los desarrolladores a responder con seguridad a los cambios en los requerimientos del cliente, incluso tarde en el ciclo de vida. Esta metodología también hace énfasis en el equipo de trabajo. Directiva, clientes y desarrolladores son todos partes de un equipo dedicado a otorgar calidad al software. XP implementa una simple, aun efectiva forma de permitir el desarrollo en grupo. XP orienta un proyecto de software en cuatro caminos esenciales; comunicación, simplicidad, retroalimentación y coraje. Los programadores en XP se comunican con sus clientes y otros programadores. Ellos mantienen sus diseños simples y limpios. Obtienen retroalimentación realizando pruebas al software desde el primer día. Entregan el sistema a sus clientes tan temprano como sea posible e implementan los cambios que sean sugeridos. Con este fundamento los programadores XP son capaces de valientemente responder a los cambios de requerimientos y tecnologías. XP es diferente es como un rompecabezas. Hay muchas piezas pequeñas. Individualmente las piezas no tienen sentido, pero cuando se combinan juntas

13 20 completan una imagen. Esto es una significante salida de los métodos de desarrollo tradicionales e introduce un cambio en la forma de programar. [12] Fases de la Metodología XP Planificación: XP plantea la planificación como un permanente dialogo entre la parte empresarial (lo deseable) y la técnica (lo posible). La fase de planificación comprende principalmente las siguientes actividades: - Escribir historias de usuario: Tienen el mismo propósito que los casos de uso pero no son lo mismo. Son usadas para crear estimaciones de tiempo para realizar el plan inicial. Ellos también son usados para elaborar la documentación de los requerimientos. Las historias de usuario son escritas por los clientes como cosas que necesitan que el sistema haga por ellos. Son similares a los escenarios solo que no se limitan a describir la interfaz de usuario. [12]. - Crear un plan inicial: La esencia de realizar el plan inicial es para el equipo de desarrollo estimar cada historia de usuario en términos de semanas de programación ideales. Una semana ideal tomara tanto tiempo como imagine que tomara la implementación de la historia si no tiene absolutamente nada más que hacer. Ninguna dependencia, ningún trabajo extra pero incluyendo las pruebas. Los clientes deciden que historia es la más importante o tiene la mayor prioridad para ser completada. [12]. - Realizar reuniones: Reuniones cada mañana usadas para comunicar problemas soluciones y promover el foco del equipo. Las reuniones ser realizan en un circulo donde se tiene una larga discusión. Esto es más eficiente que tener una reunión corta con cada uno de los desarrolladores. [12].

14 Diseño: Durante la fase de diseño se debe tener en cuenta las siguientes recomendaciones: - Simplicidad: Un diseño simple toma menos tiempo para ser terminado que uno complejo. Casi siempre hacer cosas simples puede costar trabajo. Si se encuentra algo que sea complejo debe remplazarse con algo simple. Siempre es más rápido y barato remplazar código complejo ahora antes de que transcurra más tiempo. [12]. - Escoger una metáfora del sistema: Una metáfora es una historia que todo el mundo puede contar a cerca de cómo funciona el sistema. Algunas veces podremos encontrar metáforas sencillas Programa de gestión de compras, ventas, con gestión de cartera y almacén. Las metáforas ayudan a cualquier persona a entender el objeto del programa. [12] Desarrollo: En cuanto al desarrollo es importante tener en cuenta: - El cliente esta siempre disponible: Uno de los pocos requerimientos de la programación extrema (XP) es tener al cliente disponible. No solo para ayudar al equipo de desarrollo sino para ser parte del mismo. Todas las fases de un proyecto XP requieren comunicación con el cliente, preferiblemente cara a cara, en el sitio. [12]. - Integración secuencial: El código se debe integrar como mínimo una vez al día, y realizar las pruebas sobre la totalidad del sistema. Una pareja de programadores se encargara de integrar todo el código en una maquina y realizar todas las pruebas hasta que estas funcionen al 100%. [12].

15 22 - Nada de Sobretiempo: Si queremos estar frescos y motivados cada mañana y cansado y satisfecho cada noche. El viernes quiero estar cansado y satisfecho para sentir que tengo dos días para pensar en algo distinto y volver el lunes lleno de pasión e ideas. Esto requiere que trabajemos 40 horas a la semana, mucha gente no puede estar más de 35 horas concentrada a la semana, otros pueden llegar hasta 45 pero ninguno puede llegar a 60 horas durante varias semanas y aun seguir fresco, creativo y confiado. Las horas extras son síntoma de serios problemas en el proyecto, la regla de XP dice nunca 2 semanas seguidas realizando horas extras. [12] Pruebas: No debe existir ninguna característica en el programa que no haya sido probada, los programadores escriben pruebas para chequear el correcto funcionamiento del programa, los clientes realizan pruebas funcionales. El resultado un programa mas seguro que conforme pasa el tiempo es capaz de aceptar nuevos cambios. [12] Panorámica del sistema de gestión de base de datos MySQL MySQL, el sistema de gestión de bases de datos SQL Open Source más popular, lo desarrolla, distribuye y soporta MySQL AB. MySQL AB es una compañía comercial, fundada por los desarrolladores de MySQL. Es una compañía Open Source de segunda generación que une los valores y metodología Open Source con un exitoso modelo de negocio. [13]. MySQL es un sistema de gestión de bases de datos Una base de datos es una colección estructurada de datos. Puede ser cualquier cosa, desde una simple lista de compra a una galería de pintura o las más vastas cantidades de información en una red corporativa. Para añadir, acceder, y procesar los

16 23 datos almacenados en una base de datos, necesita un sistema de gestión de base de datos como MySQL Server. Al ser los computadores muy buenos en tratar grandes cantidades de datos, los sistemas de gestión de bases de datos juegan un papel central en computación, como aplicaciones autónomas o como parte de otras aplicaciones. [13]. MySQL es un sistema de gestión de bases de datos relacionales Una base de datos relacional almacena datos en tablas separadas en lugar de poner todos los datos en un gran almacén. Esto añade velocidad y flexibilidad. La parte SQL de "MySQL" se refiere a "Structured Query Language". SQL es el lenguaje estandarizado más común para acceder a bases de datos y está definido por el estándar ANSI/ISO SQL. El estándar SQL ha evolucionado desde 1986 y existen varias versiones. [13]. MySQL software es Open Source. Open Source significa que es posible para cualquiera usar y modificar el software. Cualquiera puede bajar el software MySQL desde Internet y usarlo sin pagar nada. Si lo desea, puede estudiar el código fuente y cambiarlo para adaptarlo a sus necesidades. El software MySQL usa la licencia GPL (GNU General Public License), para definir lo que puede y no puede hacer con el software en diferentes situaciones. [13]. El servidor de base de datos MySQL es muy rápido, fiable y fácil de usar. El servidor MySQL también tiene una serie de características prácticas desarrolladas en cooperación con los usuarios. MySQL Server se desarrolló originalmente para tratar grandes bases de datos mucho más rápido que soluciones existentes y ha sido usado con éxito en entornos de producción de alto rendimiento durante varios años. MySQL Server ofrece hoy en día una gran cantidad de

17 24 funciones. Su conectividad, velocidad, y seguridad hacen de MySQL Server altamente apropiado para acceder bases de datos en Internet. [13] Visual C# Microsoft Visual C# 2005 es un lenguaje de programación diseñado para crear una amplia gama de aplicaciones que se ejecutan en.net Framework. C# es simple, eficaz, con seguridad de tipos y orientado a objetos. Con sus diversas innovaciones, C# permite desarrollar aplicaciones rápidamente y mantiene la expresividad y elegancia de los lenguajes de tipo C. Visual Studio admite Visual C# con un editor de código completo, plantillas de proyecto, diseñadores, asistentes para código, un depurador eficaz y fácil de usar, además de otras herramientas. La biblioteca de clases.net Framework ofrece acceso a una amplia gama de servicios de sistema operativo y a otras clases útiles y adecuadamente diseñadas que aceleran el ciclo de desarrollo de manera significativa. [14] NET Framework.NET Framework es el modelo de programación de código administrado de Microsoft para la creación de aplicaciones en clientes de Windows, servidores y dispositivos móviles o incrustados. Los desarrolladores pueden usar.net para crear muchos tipos de aplicaciones: aplicaciones web, de servidor, de cliente inteligente, de consola, de bases de datos, etc. Para admitir esta diversidad,.net Framework incluye un amplio conjunto de bibliotecas de clases de soporte, como: Windows Presentation Foundation (WPF), para conseguir experiencias de usuario visualmente impresionantes; Windows

18 25 Communication Foundation (WCF), para permitir comunicaciones rápidas y flexibles entre las aplicaciones de la empresa; Windows Workflow Foundation (WF), para permitir a los desarrolladores la creación de flujos de trabajo en cualquier aplicación; ASP.NET, para obtener aplicaciones interactivas de alto rendimiento basadas en la Web; bibliotecas para trabajar con XML, datos, optimización de infraestructuras, criptografía, conversión de texto a voz, etc. [15] Pruebas de software El objetivo de la etapa de pruebas de componentes es descubrir defectos probando componentes de programas individuales. Estos componentes pueden ser funciones, objetivos o componentes reutilizables. Durante las pruebas del sistema, estos componentes se integran para formar subsistemas o el sistema completo. En esta etapa, la prueba del sistema debería centrarse en establecer que el sistema satisface sus requerimientos funcionales y no funcionales, y no se comporta de manera inesperada. Inevitablemente, los defectos en los componentes que no se han detectado durante las primeras etapas de la pruebas se descubren durante las pruebas del sistema. Texto Citado [7]. Según Sommerville (2005) [7], El proceso de pruebas del software tiene dos objetivos distintos: - Para demostrar al desarrollador y al cliente que el software satisface sus requerimientos. Para el software a medida, esto significa que debería haber al menos una prueba para cada requerimiento de los documentos de requerimientos del sistema y del usuario. - Para descubrir defectos en el software en el que el comportamiento de este es incorrecto, no deseable o no cumple su especificación. La prueba de defectos esta

19 26 relacionada con la eliminación de todos los tipos de comportamientos del sistema no deseables, tales como caídas del sistema, interacciones no permitidas con otros sistemas, cálculos incorrectos e interacción de datos. El primer objetivo conduce a las pruebas de validación en las que se espera que el sistema funcione correctamente usando un conjunto determinado de casos de prueba que reflejan el uso esperado de aquél. El segundo objetivo conduce a la prueba de defectos, en los que los casos de prueba se diseñan para exponer los defectos. Los casos de prueba pueden ser deliberadamente oscuros y no necesitan reflejar como se utiliza normalmente el sistema. Para las pruebas de validación una prueba exitosa es aquella en la que el sistema funciona correctamente. Para las pruebas de defectos una prueba con éxito es aquella que muestra un defecto que hace que el sistema funcione incorrectamente. Texto Citado [7]. Las pruebas exhaustivas en la que cada posible secuencia de ejecución del programa es probada, son imposibles. Las pruebas por lo tanto tienen que basarse en un subconjunto de posibles casos de prueba. Idealmente, algunas compañías deberían tener políticas para elegir este subconjunto en lugar de dejar esto al equipo de desarrollo. Estas políticas podrían basarse en la experiencia de uso del sistema y pueden centrarse en probar las características de sistema operacional. Por ejemplo: - Deberían probarse todas las funciones del sistema a las que se accede a través de menús. - Deben probarse todas las combinaciones de funciones (por ejemplo, formateado de textos) a las que se accede a través del mismo menú. - En los puntos del programa donde el usuario introduce datos, todas las funciones deben probarse con datos correctos e incorrectos.

20 27 Las pruebas de navegabilidad o evaluación de la interfaz es el proceso de evaluar una interfaz y verificar que cumple los requerimientos del usuario. Texto citado [7]. La evaluación sistemática del diseño de la interfaz de usuario puede ser un proceso caro que implica a científicos cognoscitivos y diseñadores gráficos. Es posible que se tenga que diseñar y realizar un número estadísticamente importante de experimentos con los usuarios típicos. Existen varias técnicas menos costosas y sencillas en la evaluación de interfaces que pueden identificar deficiencias específicas en el diseño de interfaces. Texto citado [7]. - Cuestionarios que recopilan información de lo que opinan los usuarios de la interfaz. - La observación de los usuarios cuando trabajan con el sistema y piensan en voz alta de cómo tratan de utilizar el sistema para llevar a cabo alguna tarea. - Instantáneas de videos del uso típico del sistema. - La inclusión de código en el software que recopila información de los recursos mas utilizados y de los errores más comunes. Según Pérez (2007) [16], las pruebas de funcionalidad tienen como objetivo validar si el comportamiento observado del software cumple o no con sus especificaciones. La prueba exhaustiva del producto requiere ejercitar todos los caminos posibles del mismo, el tiempo requerido para esto, incluso para un programa pequeño es prohibitivo. Esto impacta directamente en la economía de las pruebas, ya que se deberán realizar suposiciones sobre el comportamiento del programa, y la forma en que se diseñan los casos de prueba para el mismo. El objetivo es maximizar

21 28 la producción de las pruebas, esto es, maximizar el número de los errores encontrados por un número finito de los casos de prueba. Las funciones son probadas ingresando las entradas y examinando las salidas. La estructura interna del programa raramente es considerada. Se deben considerar condiciones inválidas e inesperadas de la entrada y tener en cuenta que la definición del resultado esperado es una parte vital de un caso de la prueba. El propósito de la prueba funcional es mostrar discrepancias con la especificación y no demostrar que el programa cumple su especificación. [16]