Recopilacion De Informacion De Ing.Sofware

  • 632 views
Uploaded on

 

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
632
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
25
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. UNIVERSIDAD AUTONOMA DEL ESTADO DE HIDALGO ESCUELA SUPERIOR HUEJUTLA LIC. SISTEMAS COMPUTACIONALES INGENIERIA DEL SOFTWARE LIC. NOE ESPINOZA HERNANDEZ
  • 2. 3.1 ANÁLISIS DE SISTEMAS DEL SOFTWARE Es el Proceso de gestión para la creación de un Sistema o software, la cual encierra un conjunto de actividades, una de las cuales es la estimación, estimar es echar un vistazo al futuro y aceptamos resignados cierto grado de incertidumbre. Aunque la estimación, es mas un arte que una Ciencia, es una actividad importante que no debe llevarse a cabo de forma descuidada. Existen técnicas útiles para la estimación de costes de tiempo. Y dado que la estimación es la base de todas las demás actividades de planificación del proyecto y sirve como guía para una buena Ingeniería Sistemas y Software. Al estimar tomamos en cuenta no solo del procedimiento técnico a utilizar en el proyecto, sino que se toma en cuenta los recursos, costos y planificación. El Tamaño del proyecto es otro factor importante que puede afectar la precisión de las estimaciones. A medida que el tamaño aumenta, crece rápidamente la interdependencia entre varios elementos del Software. La disponibilidad de información Histórica es otro elemento que determina el riesgo de la estimación. Objetivos de la Planificación del Proyecto. El objetivo de la Planificación del proyecto de Software es proporcionar un marco de trabajo que permita al gestor hacer estimaciones razonables de recursos costos y planificación temporal. Estas estimaciones se hacen dentro de un marco de tiempo limitado al comienzo de un proyecto de software, y deberían actualizarse regularmente medida que progresa el proyecto. Además las estimaciones deberían definir los escenarios del mejor caso, y peor caso, de modo que los resultados del proyecto pueden limitarse. El Objetivo de la planificación se logra mediante un proceso de descubrimiento de la información que lleve a estimaciones razonables. 3.1.1 ANÁLISIS DE REQUERIMIENTOS
  • 3. Es un conjunto o disposición de procedimientos o programas relacionados de manera que juntos forman una sola unidad. Un conjunto de hechos, principios y reglas clasificadas y dispuestas de manera ordenada mostrando un plan lógico en la unión de las partes. Un método, plan o procedimiento de clasificación para hacer algo. También es un conjunto o arreglo de elementos para realizar un objetivo predefinido en el procesamiento de la Información. Esto se lleva a cabo teniendo en cuenta ciertos principios: Debe presentarse y entenderse el dominio de la información de un problema. Defina las funciones que debe realizar el Software. Represente el comportamiento del software a consecuencias de acontecimientos externos. Divida en forma jerárquica los modelos que representan la información, funciones y comportamiento. El proceso debe partir desde la información esencial hasta el detalle de la Implementación. 3.1.2 TECNICAS PARA FACILITAR LA ESPECIFICACION DE APLICACIÓN La función del Análisis puede ser dar soporte a las actividades de un negocio, o desarrollar un producto que pueda venderse para generar beneficios. Para conseguir este objetivo, un Sistema basado en computadoras hace uso de seis (6) elementos fundamentales: Software, que son Programas de computadora, con estructuras de datos y su documentación que hacen efectiva la logística metodología o controles de requerimientos del Programa. Hardware, dispositivos electrónicos y electromecánicos, que proporcionan capacidad de cálculos y funciones rápidas, exactas y efectivas (Computadoras, Censores, maquinarias, bombas, lectores, etc.), que proporcionan una función externa dentro de los Sistemas. Personal, son los operadores o usuarios directos de las herramientas del Sistema. Base de Datos, una gran colección de informaciones organizadas y enlazadas al Sistema a las que se accede por medio del Software. Documentación, Manuales, formularios, y otra información descriptiva que detalla o da instrucciones sobre el empleo y operación del Programa. Procedimientos, o pasos que definen el uso especifico de cada uno de los elementos o componentes del Sistema y las reglas de su manejo y mantenimiento. 3.1.3 DESPLIEGUE DE LA FUNCIÓN DE CALIDAD
  • 4. El despliegue de funciones de calidad como enfoque de diseño es un concepto que se introdujo en Japón en 1966. El uso del despliegue de funciones de calidad ha eliminado la mitad de los problemas que anteriormente se presentaban en las fases iniciales de desarrollo de un producto y ha reducido el periodo de desarrollo de una mitad a un tercio, mientras se ha asegurado también la satisfacción del usuario y el incremento de las ventas. Sin embargo, si se aplica incorrectamente, el despliegue de funciones de calidad a puede aumentar el trabajo sin producir esos beneficios. ¿QUE ES EL DESPLIEGUE DE FUNCIONES DE CALIDAD? Ofrece métodos específicos para asegurar la calidad a través de cada fase del proceso de desarrollo del producto, comenzando por el diseño. En otras palabras, este es un método para desarrollar una calidad de diseño enfocada a satisfacer al consumidor y entonces trasladar las demandas del consumidor en metas de diseño y puntos principales de aseguramiento de la calidad a través de la fase de producción. Se utiliza para definir en términos operacionales la “Voz del Consumidor” , el cual tiene necesidades y expectativas, que frecuentemente difieren de las del fabricante y por lo tanto no son atendidas correctamente. Es un mecanismo formal para asegurar que la voz del consumidor sea escuchada durante el desarrollo del producto. También identifica medios específicos para asegurar que los requerimientos del consumidor sean cumplidos por todas las actividades funcionales de la compañía. El despliegue de Calidad es un proceso para convertir los requerimientos de Calidad de los usuarios a características de la contraparte, y así determinar la Calidad del diseño para el producto terminado. Así mismo se despliega esta calidad de diseño a calidad de cada parte funcional, al mismo tiempo que se clarifican las relaciones entre estas partes y los elementos. Dicho de otra manera, es el despliegue paso a paso con el mayor detalle de las funciones u operaciones que conforman sistemáticamente la calidad, con procedimientos objetivos en vez de subjetivos. Es un método empleado para convertir lo que el consumidor quiere en direcciones y acciones que puedan ser desplegadas horizontalmente a través de la planeación, ingeniería y producción. Es tan sólo una dentro de las muchas técnicas que se encuentran bajo el concepto de CWQC (Control de Calidad a lo largo de toda la Compañía). Esta técnica identifica QUE'S, define COMO'S y, por medio de evaluación y análisis, sugiere métodos a ser utilizados para la solución de un problema. Es una técnica que identifica los requerimientos del consumidor y establece una disciplina para asegurar que esos requerimientos tengan una influencia positiva en el diseño del producto o el desarrollo del proceso. La Función de Despliegue de Calidad, puede pensarse que consiste de dos partes principales; despliegue de la calidad del producto y despliegue de las funciones de calidad:
  • 5. 1.-El despliegue de la calidad del producto es la actividad necesaria para convertir los requerimientos del consumidor en características de calidad del producto 2.-El despliegue de la función de calidad es la actividad necesaria para asegurar que la calidad requerida por el consumidor sea cumplida 3.2 PRINCIPIOS DEL ANALISIS se desarrollaron varios métodos de análisis y especificación del software. Los investigadores han identificado los problemas y sus causas y desarrollando reglas y procedimientos para resolverlos. Cada método de análisis tiene una única notación y punto de vista. Sin embargo, todos los métodos de análisis están relacionados por un conjunto de principios fundamentales: 3.2.1 DOMINIO DE LA INFORMACIÓN El dominio de la información, así como el dominio funcional de un problema debe ser representado y comprendido. El problema debe subdividirse de forma que se descubran los detalles de una manera progresiva (o jerárquica) Deben desarrollarse las representaciones lógicas y físicas del sistema. Aplicando estos principios, el analista enfoca el problema sistemáticamente. Se examina el dominio de la información de forma que pueda comprenderse su función mas completamente. La partición se aplica para reducir la complejidad. La visión lógica y física del software, es necesaria para acomodar las ligaduras lógicas impuestas por los requerimientos de procesamiento, y las ligaduras físicas impuestas Un dominio puede referirse a dos cosas: es un conjunto de ordenadores conectados en una red que confían a uno de los equipos de dicha red la administración de los usuarios y los privilegios que cada uno de los usuarios tiene en dicha red. es la parte principal de una dirección en el web que usualmente indica la organización o compañía que administra dicha página. Controlador de dominio El controlador de dominio es un solo equipo si la red es pequeña. Cuando la red es grande (más de 30 equipos con sus respectivos periféricos y más de 30 usuarios) suele ser necesario un segundo equipo dependiente del primero al que llamaremos subcontrolador de dominio. Usaremos este equipo para descargar en él parte de las tareas del controlador de dominio (a esto se le llama balance de carga). Cuando las redes son muy grandes es mejor dividirlas en subdominios, con controladores diferentes.
  • 6. 3.2.2 MODELADO El modelado es una técnica cognitiva que consiste en crear una representación ideal de un objeto real mediante un conjunto de simplificaciones y abstracciones, cuya validez se pretende constatar. La validación del modelo se lleva a cabo comparando las implicaciones predichas por el mismo con observaciones. En otras palabras, se trata de crear un modelo irreal o ideal que refleja ciertos aspectos de un objeto real, como al crear una escultura o una pintura. Un modelo es por tanto una simplificación de la realidad que recoge aquellos aspectos de relevancia para las intenciones del modelador. Se modela para comprender mejor o explicar mejor un proceso o unas observaciones. 3.2.3 PARTICION El segmento del espacio de almacenamiento de una unidad de disco que puede accederse como si fuese un disco entero Consiste en dividir un disco duro en varias partes, cada una de las cuales se comportará como si fuera un disco duro independiente de los demás. Es la opción más razonable (a veces imprescindible) para instalar varios sistemas operativos en un mismo ordenador Modalidad de indización que consiste en la subdivisión previa de las distintas partes de una obra, para indizar cada parte por separado cada una de las zonas en las que se divide la memoria principal para alojar los procesos del sistema. 3.3 ESPECIFICACIÓN No hay duda de que la forma de especificar tiene mucho que ver con la calidad de la solución. Los ingenieros de software que se han esforzado en trabajar con especificaciones incompletas, inconsistentes o mal establecidas han experimentado la frustración y confusión que invariablemente se produce. Las consecuencias se padecen en la calidad, oportunidad y completitud del software resultante. Hemos visto que los requerimientos de software pueden ser analizados de varias formas diferentes. Las técnicas de análisis pueden conducir a una especificación en papel que contenga las descripciones graficas y el lenguaje natural de los requerimientos del software. La construcción de prototipos conduce a una especificación ejecutable, esto es, el prototipo
  • 7. sirve como una representación de los requerimientos. Los lenguajes de especificación formal conducen a representaciones formales de los requerimientos que pueden ser 3.3.1 PRINCIPIOS DE LA ESPECIFICACIÓN La especificación, independientemente del modo en que se realice, puede ser vista como un proceso de representación. Los requerimientos se representan de forma que conduzcan finalmente a una correcta implementación del software. Baltzer y Goldman proponen ocho principios para una buena especificación: PRINCIPIO #1. Separar funcionalidad de implementación. Primero, por definición, una especificación es una descripción de lo que se desea, en vez de cómo se realiza (implementa). Las especificaciones pueden adoptar dos formas muy diferentes. La primera forma es la de funciones matemáticas: dado algún conjunto de entrada, producir un conjunto particular de salida. La forma general de tales especificaciones es encontrar [un/el/todos] resultado tal que P (entrada), donde P representa un predicado arbitrario. En tales especificaciones, el resultado a ser obtenido ha sido expresado enteramente en una forma sobre el que (en vez de cómo). En parte, esto es debido a que el resultado es una función matemática de la entrada (la operación tiene puntos de comienzo y parada bien definidos) y no esta afectado por el entorno que le rodea. PRINCIPIO #2. Se necesita un lenguaje de especificación de sistemas orientado al proceso. Considerar una situación en la que el entorno sea dinámico y sus cambios afecten al comportamiento de alguna entidad que interactúe con dicho entorno. Su comportamiento no puede ser expresado como una función matemática de su entrada. En vez de ello, debe emplearse una descripción orientada al proceso, en la cual la especificación del que se consigue mediante la especificación de un modelo del comportamiento deseado en términos de respuestas funcionales, a distintos estímulos del entorno. PRINCIPIO #3. Una especificación debe abarcar el sistema del cual el software es una componente. Un sistema esta compuesto de componentes que interactúan. Solo dentro del contexto del sistema completo y de la interacción entre sus partes puede ser definido el comportamiento de una componente especifica. En general, un sistema puede ser modelado como una colección de objetos pasivos y activos. Estos objetos están interrelacionados y dichas relaciones entre los objetos cambian con el tiempo. Estas relaciones dinámicas suministran los estímulos a los cuales los objetos activos, llamados agentes, responden. Las respuestas pueden causar posteriormente cambios y, por tanto, estímulos adicionales a los cuales los agentes deben responder. PRINCIPIO #4. Una especificación debe abarcar el entorno en el que el sistema opera. Similarmente, el entorno en el que opera el sistema y con el que interactúa debe ser especificado. Afortunadamente, esto tan solo necesita reconocer que el propio entorno es un sistema compuesto de objetos que interactúan, pasivos y activos, de los cuales el sistema especificado es una agente, Los otros agentes, los cuales son por definición inalterables debido a que son parte del entorno, limitan el ámbito del diseño subsecuente y de la implementación. De hecho, la única diferencia entre el sistema y su entorno es que el esfuerzo de diseño e implementación subsecuente opera exclusivamente sobre la
  • 8. especificación del sistema. La especificación del entorno facilita que se especifique la interfaz del sistema de la misma forma que el propio sistema, en vez de introducir otro formalismo. PRINCIPIO #5. Una especificación de sistema debe ser un modelo cognitivo. La especificación de un sistema debe ser un modelo cognitivo, en vez de un modelo de diseño o implementación. Debe describir un sistema tal como es percibido por su comunidad de usuario. Los objetivos que manipula deben corresponderse con objetos reales de dicho dominio; los agentes deben modelar los individuos, organizaciones y equipo de ese dominio; y las acciones que ejecutan deben modelar lo que realmente ocurre en el dominio. Además, debe ser posible incorporar en la especificación las reglas o leyes que gobiernan los objetos del dominio. Algunas de estas leyes proscriben ciertos estados del sistema (tal como “dos objetos no pueden estar en el mismo lugar al mismo tiempo”), y por tanto limitan el comportamiento de los agentes o indican la necesidad de una posterior elaboración para prevenir que surjan estos estados. PRINCIPIO #6. Una especificación debe ser operacional. La especificación debe ser completa y lo bastante formal para que pueda usarse para determinar si una implementación propuesta satisface la especificación de pruebas elegidas arbitrariamente. Esto es, dado el resultado de una implementación sobre algún conjunto arbitrario de datos elegibles, debe ser posible usar la especificación para validar estos resultados. Esto implica que la especificación, aunque no sea una especificación completa del como, pueda actuar como un generador de posibles comportamientos, entre los que debe estar la implementación propuesta. Por tanto, en un sentido extenso, la especificación debe ser operacional. PRINCIPIO #7. La especificación del sistema debe ser tolerante con la incompletitud y aumentable. Ninguna especificación puede ser siempre totalmente completa. El entorno en el que existe es demasiado complejo para ello. Una especificación es siempre un modelo, una abstracción, de alguna situación real (o imaginada). Por tanto, será incompleta. Además, al ser formulad existirán muchos niveles de detalle. La operacionalidad requerida anteriormente no necesita ser completa. Las herramientas de análisis empleadas para ayudar a los especificadores y para probar las especificaciones, deben ser capaces de tratar con la incompletitud. Naturalmente esto debilita el análisis, el cual puede ser ejecutado ampliando el rango de comportamiento aceptables, los cuales satisfacen la especificación, pero tal degradación debe reflejar los restantes niveles de incertidumbre. PRINCIPIO #8. Una especificación debe ser localizada y débilmente acoplada. Los principios anteriores tratan con la especificación como una entidad estática. Esta surge de la dinámica de la especificación. Debe ser reconocido que aunque el principal propósito de una especificación sea servir como base para el diseño e implementación de algún sistema, no es un objeto estático precompuesto, sino un objeto dinámico que sufre considerables modificaciones. Tales modificaciones se presentan en tres actividades principales: formulación, cuando se está creando una especificación inicial; desarrollo, cuando la especificación se esta elaborando durante el proceso iterativo de diseño e implementación; y mantenimiento, cuando la especificación se cambia para reflejar un entorno modificado y/o requerimientos funcionales adicionales.
  • 9. 3.3.2 REPRESENTACIÓN El esquema de representación consiste en tres partes principales: El servicio de representación, define las operaciones de representación. Este servicio es utilizado para representar una instancia o instancias de fenómeno. El paquete de catálogo de representación, define las reglas de representación para las clases de fenómenos definidas en un esquema de aplicación. 3.3.3 ESPECIFICACION DE LOS REQUISITOS DEL SOFTWARE El paquete de especificación de representación, define los parámetros subyacentes que son necesarios para el servicio de representación. En resumen se puede decir que para poder representar un tipo de fenómeno es necesario mediante una regla seleccionar una representación gráfica. En el primer paso, las reglas disponibles son testeadas según el tipo de entidad dada y sus parámetros adjuntos. Y el segundo paso, es cuando la especificación de representación es utilizada para encontrar la regla válida que hay que aplicar. A continuación se aplica la regla sobre el fenómeno. Las reglas están almacenadas en el catálogo de representación, es decir contiene la representación cartográfica para cada tipo de fenómeno. 3.3.4 REVISIÓN DE LAS ESPECIFICACIONES Las especificaciones serán revisadas a intervalos, de acuerdo a las prioridades indicadas en la Sección 3.5 del Manual. FAO y OMS prepararán un programa de revisión de las especificaciones publicadas, las cuales serán consideradas por la JMPS. Como una de las responsabilidades de la administración de productos y como condición para mantener las especificaciones de la FAO y la OMS, los proponentes deben informar a FAO/OMS de los cambios en los procesos de fabricación que tienen implicaciones para las especificaciones existentes y de los cambios en el nombre o dirección de la compañía. Las especificaciones son publicadas en base a que la información sobre el proceso de producción (confidencial), perfil de impurezas, datos sobre riesgos disponibles por FAO/OMS y el nombre y la dirección del fabricante permanecen válidos. Los proponentes tienen la responsabilidad de informar a FAO/OMS los cambios en esta información. Cuando la validez de esta información está en duda, la(s) especificación(es) puede ser programada para revisión por la JMPS. El fabricante de un producto evaluado por el WHOPES y fundadas en tal evaluación se han desarrollado las recomendaciones de OMS para uso y especificaciones, debe notificar a OMS cualquier cambio de proceso de fabricación, característica de formulación y/o formulantes que pueda requerir la reevaluación del producto y/o revisar la especificación. Los proponentes también pueden requerir la revisión de las especificaciones.
  • 10. Las especificaciones bajo revisión deben ser respaldadas por la información indicada en las Secciones 3.1 ó 3.2 (según corresponda). La JMPS: (i) confirmará que la especificación existente es apropiada, o (ii) recomendará una corrección en la especificación, o (iii) recomendará que la especificación sea eliminada. Cuando las autoridades nacionales consideren necesario adaptar una Especificación FAO/OMS, el propietario o la autoridad le debe informar a éstas de tales cambios y las razones de ello. Estas especificaciones modificadas no pueden ser consideradas como Especificaciones FAO/OMS, pero la información que sustenta los cambios permitirá revisiones de la especificación por la JMPS. La FAO y la OMS agradecerán comentarios y mayor información en relación a las especificaciones. Las proposiciones para modificar las especificaciones, deben estar respaldadas por evidencia que demuestre que el cambio es pertinente ya sea para mantener o mejorar la calidad, o para reducir los riesgos tanto de los ingredientes activos técnicos como de las formulaciones. 3.4 ESTUDIO DE VIABILIDAD Los Estudios de Viabilidad (EV) proporcionan una evaluación de las alternativas de restauración, incluyendo el análisis de las debilidades y ventajas de cada una de las tecnologías, así como los criterios utilizados para seleccionar una alternativa sobre las demás. La integración de la lista de tecnologías posibles de utilizarse en la restauración del sitio se hace en forma concurrente con la investigación de restauración. El desarrollo y análisis de alternativas así como, el establecimiento de las metas de restauración se afinan y modifican a medida que se progresa en la investigación de restauración, y la información generada va estando disponible. En el EV se determina la factibilidad técnica y económica de alcanzar el objetivo de la restauración ambiental, o sea eliminar, reducir o controlar la presencia de los tóxicos en el sitio de estudio, para que no presenten riesgos mayores para la salud pública que los socialmente aceptables. El Estudio de Viabilidad consta de las siguientes partes: *Establecimiento de los objetivos de la restauración *Desarrollo de alternativas de restauración *Selección preliminar de las alternativas tecnológicas
  • 11. *Análisis detallado de las alternativas seleccionadas. ¿VIABILIDAD 0 FACTIBILIDAD? Es frecuente encontrar en estudios de proyectos la denominación genérica de “factibilidad técnica económica», para titular el informe final de cualquier evaluación de un proyecto de inversión. Si bien en el lenguaje diario se usan indistintamente los términos viabilidad y factibilidad, es conveniente aclarar la necesidad de su diferenciación, especialmente si se considera que el segundo corresponde a una etapa del ciclo del proyecto que tiene repercusiones importantes en los procedimientos y alcances que se exigirán al trabajo del evaluador. 3.4.1 ANÁLISIS ECONÓMICO Y 3.4.2 ANALISIS TÉCNICO El Análisis Económico incluye lo que llamamos, el análisis de costos – beneficios, significa una valoración de la inversióneconómica comparado con los beneficios que se obtendrán en la comercialización y utilidad del producto o sistema. Muchas veces en el desarrollo de Sistemas de Computación estos son intangibles y resulta un poco dificultoso evaluarlo, esto varia de acuerdo a la características del Sistema. El análisis de costos – beneficios es una fase muy importante de ella depende la posibilidad de desarrollo del Proyecto. En el Análisis Técnico, el Analista evalúa los principios técnicos del Sistema y al mismo tiempo recoge información adicional sobre el rendimiento, fiabilidad, características de mantenimiento y productividad. Los resultados obtenidos del análisis técnico son la base para determinar sobre si continuar o abandonar el proyecto, si hay riesgos de que no funcione, no tenga el rendimiento deseado, o si las piezas no encajan perfectamente unas con otras. Modelado de la arquitectura del Sistema Cuando queremos dar a entender mejor lo que vamos a construir en el caso de edificios, Herramientas, Aviones, Maquinas, se crea un modelo idéntico, pero en menor escala (mas pequeño). Sin embargo cuando aquello que construiremos es un Software, nuestro modelo debe tomar una forma diferente, deben representar todas las funciones y subfunciones de un Sistema. Los modelos se concentran en lo que debe hacer el sistema no en como lo hace, estos modelos pueden incluir notación gráfica, información y comportamiento del Sistema. Todos los Sistemas basados en computadoras pueden modelarse como transformación de la información empleando una arquitectura del tipo entrada y salida.
  • 12. Especificaciones del Sistema Es un Documento que sirve como fundamento para la Ingeniería Hardware, software, Base de datos, e ingeniería Humana. Describe la función y rendimiento de un Sistema basado en computadoras y las dificultades que estarán presente durante su desarrollo. Las Especificaciones de los requisitos del software se produce en la terminación de la tarea del análisis. 3.4.3 LA VIABILIDAD LEGAL La viabilidad técnica, que siempre debe establecerse con la ayuda de los técnicos especializados en la materia, busca determinar si es posible física o materialmente «hacer” un proyecto. Tal tarea corresponde a dichos especialistas y no puede ser asumida con responsabilidad por el evaluador económico del proyecto. Por ejemplo, sólo los expertos pueden, en sus respectivas áreas de especialidad, determinar si materialmente es posible construir un puerto en determinado lugar, obtener pectina de limón, producir papel de diario usando el bagazo de la caña de azúcar o reconvertir el plástico de desecho para utilizarlo como materia prima de otros productos plásticos. Considérese al respecto lo absurdo que sería el hecho de que el evaluador económico tuviera que medir, con traje de buzo, si la profundidad de mar permite recalar a las naves que habrían de usar el futuro puerto; o que en un laboratorio haga pruebas para precisar el contenido de pectina de cierto tipo de limón; o que mida la temperatura de las aguas para determinar la posibilidad- de instalar un proyecto de piscicultura. 3.5 DISEÑO DE SISTEMAS El Diseño de Sistemas se ocupa de desarrollar las directrices propuestas durante el análisis en función de aquella configuración que tenga más posibilidades de satisfacer los objetivos planteados tanto desde el punto de vista funcional como del no funcional (lo que antes hemos denominado constricciones). El proceso de diseño de un sistema complejo se suele realizar de forma descendente: Diseño de alto nivel (o descomposición del sistema a diseñar en subsistemas menos complejos) Diseño e implementación de cada uno de los subsistemas: Especificación consistente y completa del subsistema de acuerdo con los objetivos establecidos en el análisis Desarrollo según la especificación
  • 13. Prueba Integración de todos los subsistemas Validación del diseño Dentro del proceso de diseño de sistemas hay que tener en cuenta los efectos que pueda producir la introducción del nuevo sistema sobre el entorno en el que deba funcionar, adecuando los criterios de diseño a las características del mismo. En este contexto está adquiriendo una importancia creciente la adaptación de todo sistema-producto a las capacidades de las personas que van a utilizarlo, de forma que su operación sea sencilla, cómoda, efectiva y eficiente. De estas cuestiones se ocupa una disciplina, la Ergonomía, que tiene por objeto la optimización de los entornos hombre-máquina. Si bien en un principio estaba centrada en los aspectos antropométricos de la relación hombre-máquina, en la actualidad ha pasado a intervenir con fuerza en todos los procesos cognitivos (análisis, interpretación, decisión, comunicación y representación del conocimiento). Así, con respecto al diseño de herramientas software, la ergonomía tiene mucho que decir en cuestiones relacionadas con la disposición de informaciones en pantalla, profundidad de menús, formato de iconos, nombres de comandos, control de cursores, tiempos de respuesta, manejo de errores, estructuras de datos, utilización de lenguaje natural, etc. 3.5.1 CONCEPTOS DEL DISEÑO Es el proceso de aplicar distintas técnicas y principios con el propósito de definir un sistema con suficiente detalle como para permitir su implementación. Modelos de diseño Diseño de datos. Especifica las estructuras de datos necesarias para implementar el sistema. Utiliza el DER (diagrama de entidad-relación) y el DD (diccionario de datos). Diseño arquitectónico. Define las relaciones entre los elementos estructurales (módulos) del programa. Utiliza el DFD (diagrama de flujo de datos). Diseño de interface. Describe como se comunica el software consigo mismo, con los sistemas que operan con él y con los operadores que lo emplean. Utiliza el DFD. Diseño procedimental. Transforma los elementos estructurales de la arquitectura del programa en una descripción procedimental. Utiliza el DTE y la minispec o EP (especificación de procesos). 3.5.2 ABSTRACCIÓN. *Capacidad de extraer las características principales de un objeto para modelarlo.
  • 14. *Permite concentrarse en un problema sin ocuparse de los detalles. *Puede definirse abstracción procedimental, de datos y de control. 3.5.3 MODULARIDAD Estrategia de dividir un programa en componentes identificables y tratables por separado llamados módulos. Divide y vencerás. 3.5.3.1 INDEPENDENCIA FUNCIONAL Mide el grado en que los módulos dependen unos de otros. Es deseable que cada módulo sea independiente con una función única y poca interacción. La independencia funcional se mide con la cohesión y el acoplamiento. 3.5.3.2 COHESIÓN Mide el número de funciones que hace un módulo. Baja cohesión. Cohesión coincidente. El módulo hace muchas cosas sin relación. Cohesión lógica. El módulo hace muchas cosas relacionadas lógicamente. Cohesión temporal. El módulo hace muchas cosas relacionadas por el hecho que deben hacerse al mismo tiempo. Cohesión moderada. Cohesión procedimental. El módulo hace varias cosas relacionadas que deben ejecutarse en cierto orden. Cohesión de comunicación. El módulo hace varias cosas que trabajan sobre una sola estructura de datos. Alta cohesión. Cohesión funcional. El módulo hace una sola cosa. Se busca una moderada o alta cohesión.
  • 15. 3.5.3.3 ACOPLAMIENTO Mide la interconexión entre los módulos. Bajo acoplamiento. Sin acoplamiento. El módulo es independiente. Acoplamiento de datos. El módulo recibe una lista de argumentos de quien lo llama. Acoplamiento moderado. Acoplamiento de control. El módulo recibe una bandera de quien lo llama y se comporta de una manera u otra dependiendo del valor de la bandera. Alto acoplamiento. Acoplamiento externo. El módulo esta acoplado a un dispositivo de I/O externo. Este tipo de acoplamiento debe limitarse a unos pocos módulos. Acoplamiento común. El módulo utiliza variables globales o comunes. Acoplamiento de contenido. El módulo usa datos contenidos dentro de los límites de otro módulo. Se busca un bajo o moderado acoplamiento y limitar el uso de variables globales 3.5.4 ARQUITECTURA DEL SOFTWARE Es la estructura jerárquica de los módulos del programa, la manera en que interactúan y las estructuras de datos usadas por ellos. La Arquitectura de Software es la organización fundamental de un sistema encarnada en sus componentes, las relaciones entre ellos y el ambiente y los principios que orientan su diseño y evolución. 3.5.5 ESTRUCTURAS DE DATOS Muestra las alternativas de organización, métodos de acceso, capacidad de asociación y procesamiento de la información. En programación, una estructura de datos es una forma de organizar un conjunto de datos elementales con el objetivo de facilitar su manipulación. Un dato elemental es la mínima información que se tiene en un sistema.
  • 16. Una estructura de datos define la organización e interrelación de éstos y un conjunto de operaciones que se pueden realizar sobre ellos. Las operaciones básicas son: Alta, adicionar un nuevo valor a la estructura. Baja, borrar un valor de la estructura. Búsqueda, encontrar un determinado valor en la estructura para realizar una operación con este valor, en forma secuencial o binario (siempre y cuando los datos estén ordenados). Otras operaciones que se pueden realizar son: Ordenamiento, de los elementos pertenecientes a la estructura. Apareo, dadas dos estructuras originar una nueva ordenada y que contenga a las apareadas. Cada estructura ofrece ventajas y desventajas en relación a la simplicidad y eficiencia para la realización de cada operación. De esta forma, la elección de la estructura de datos apropiada para cada problema depende de factores como la frecuencia y el orden en que se realiza cada operación sobre los datos. Estructuras de datos Vectores (matriz o arreglo) Registro Tipo de datos algebraico Listas Enlazadas Listas Simples Listas Doblemente Enlazadas Listas Circulares Listas por saltos (Skip lists) Pilas (stack) Colas (queue) Cola de prioridades Árboles Árboles Binarios Árbol binario de búsqueda
  • 17. Árbol binario de búsqueda equilibrado Árboles Rojo-Negro Árboles AVL Árboles Biselados (Árboles Splay) Árboles Multicamino (Multirrama) Árboles B Árboles B+ Árboles B* Conjuntos (set) Grafos Tablas Hash Mapeos Diccionarios Montículos (o heaps) Montículo binario Montículo binómico Montículo de Fibonacci Montículo suave Montículo 2-3 3.5.6 OCULTAMIENTO DE LA INFORMACIÓN Los detalles de implementación de los módulos deben ser privados. En informática, se trata de la ocultación de la implementación de un programa o unidad de software, proveyendo a la vez una interfaz estable para acceder a éstos. La interfaz de una unidad de software es la única forma que tienen otras unidades de comunicarse e interactuar sobre ésta. En los lenguajes de programación modernos existen múltiples formas de llevar a cabo la ocultación de información, por ejemplo, el encapsulamiento. Algunos autores toman como
  • 18. sinónimos la ocultación de la información y el encapsulamiento, mientras que otros consideran la primera como el principio y la segunda como un método para implementar el principio. Veamos un ejemplo: supongamos que tenemos un módulo (una unidad de software) que recibe una función matemática, calcula sus raíces (valores de X donde se hace cero la función) y devuelve esos valores. No importa el método que utilice para calcular las raíces (implementación), lo que importa es que recibe una función y devuelve sus raíces (interfaz). Por lo tanto la implementación está oculta. Si en un futuro se decide cambiar la implementación del módulo usando un algoritmo más eficiente, se puede cambiar perfectamente sin alterar la interfaz (interfaz estable). 3.6 NOTACIONES PARA EL DISEÑO El diseño lógico es el proceso de construir un esquema de la información que utiliza la empresa, basándose en un modelo de base de datos específico, independiente del SGBD concreto que se vaya a utilizar y de cualquier otra consideración física. El diseño físico es el proceso de producir la descripción de la implementación de la base de datos en memoria secundaria: estructuras de almacenamiento y métodos de acceso que garanticen un acceso eficiente a los datos. Antes de implementar los formularios y los informes, hay que diseñar su aspecto. Es conveniente tener en cuenta las siguientes recomendaciones. Utilizar títulos que sean significativos, que identifiquen sin ambigüedad el propósito del informe o formulario. 3.6.1 DIAGRAMA ENTIDAD-RELACION El modelo entidad-relación (E/R) es uno de los modelos más utilizado para el diseño conceptual de bases de datos por ejemplo SQL. Una de las ventajas del diseño E/R es que se expresa de forma grafica lo cual permite una fácil lectura, pero esto depende de la notación que se este usando para diagramarlos, pudiendo ser simbología de cardinalidad, diagrama Entidad/Relación. Entidad: Cualquier objeto, real o abstracto, que existe en un contexto determinado o puede llegar a existir y del cual deseamos guardar información.
  • 19. Relación (interrelación): Se entiende por relación a la asociación, vinculación o correspondencia entre entidades EJEMPLO DE DAIGRAMA ENTIDAD-RELACION. 3.6.2 DIAGRAMA DE FLUJO DE DATOS El diagrama de flujo de datos (DFD), es una herramienta que permite visualizar un sistema como una red de procesos funcionales, conectados entre sí por "conductos" y "tanques de almacenamiento" de datos. Proceso El primer componente del DFD se conoce como proceso. Los sinónimos comunes son burbuja, función, transformación. Flujo Un flujo se representa gráficamente por medio de una flecha que entra o sale de un proceso. El flujo se usa para describir el movimiento de bloques o paquetes de información de una parte del sistema a otra. el flujo de la figura tiene nombre. El nombre representa el significado del paquete que se mueve a lo largo del flujo. Los flujos muestran también la dirección: una cabeza de flecha en cualquier extremo (o posiblemente ambos) del flujo indica si los datos (o el material) se está moviendo hacia adentro o hacia fuera de un proceso (o ambas cosas). 3.6.3 DICCIONARIO DE DATOS Un diccionario de datos es un catálogo, un depósito, de los elementos de un sistema. Estos elementos se centran alrededor de los datos y la forma en que están estructurados para satisfacer los requerimientos y las necesidades de la organización. En él se encuentran la lista de todos los elementos que forman parte del flujo de datos en todo el sistema. Los analistas usan los diccionarios de datos por cinco razones principales:
  • 20. Manejar los detalles en sistemas grandes Comunicar un significado común para todos los elementos del sistema Documentar las características del sistema Facilitar el análisis de los detalles con la finalidad de evaluar las características y determinar donde efectuar cambios en el sistema Localizar errores y omisiones en el sistema Contenido de un registro del diccionario: Campos: es el nivel más importante de datos; ninguna unidad más pequeña tiene significado para los analistas. La descripción de los datos debe ir acompañada por los siguientes elementos: Estructuras de datos: son un grupo de datos elementales que están relacionados con otros y que en conjunto describen un componente del sistema. Los flujos de datos, o los almacenes de datos son ejemplo de estructuras de datos. Dicho de otra forma si las estructuras están en movimiento reciben el nombre de flujos y si son estéticas son almacenes de datos. La simbología empleada se describe a continuación: Símbolo Significado Explicación Uso = Es equivalente a Alias Denota sinónimos Concatenación, componentes Denota una relación de + Y que siempre están incluidos en secuencia una estructura Define opciones entre los Denota una relación de [] Uno u otro componentes de una selección estructura Define la repetición de un Denota una relación de {} Iteraciones de componente de la estructura iteración Define componentes de la Denota una relación () Opcional estructura que puede o no opcional. estar presente una sola vez 3.7 DISEÑO DE INTERFACES GRAFICAS
  • 21. El diseño del software se encuentra en el núcleo técnico de la ingeniería del software y se aplica independientemente del modelo de diseño de software que se utilice. Una vez que se analizan y especifican los requisitos del software, el diseño del software es la primera de las tres actividades técnicas -diseño, generación de código y pruebas- que se requieren para construir y verificar el software. Cada actividad transforma la información de manera que dé lugar por último a un software de computadora validado. Las «puertas, ventanas y conexiones de servicios» del software informático es lo que constituye el diseño de la interfaz de usuario. El diseño de la interfaz se centra en tres áreas de interés: (1) el diseño de la interfaz entre los componentes del software; (2) el diseño de las interfaces entre el software y los otros productores y consumidores de información no humanos (esto es, otras entidades externas) (3) el diseño de la interfaz entre el hombre (esto es, el usuario) y la computadora. REGLAS DE ORO 1. Dar el control al usuario 2. Reducir la carga de memoria del usuario 3. Construir una interfaz consecuente Estas reglas de oro forman en realidad la base para los principios del diseño de la interfaz de usuario que servirán de guía para esta actividad de diseño de software tan importante. El proceso global para el diseño de la interfaz de usuario comienza con la creación de diferentes modelos de funcionamiento del sistema (la percepción desde fuera). Es entonces cuando se determinan las tareas orientadas al hombre y a la máquina que se requieren para lograr el funcionamiento del sistema; se tienen en consideración los temas de diseño que se aplican a todos los diseños de interfaces; se utilizan herramientas para generar prototipos y por último para implementar el modelo de diseño, y evaluar la calidad del resultado. 3.7.1 MODELO DE DISEÑO DE INTERFAZ Un modelo de diseño de un sistema completo incorpora las representaciones del software en función de los datos, arquitectura, interfaz y procedimiento. La especificación de los requisitos puede que establezca ciertas limitaciones que ayudarán a definir al usuario del
  • 22. sistema, pero el diseño de la interfaz suele ser un único tema secundario de modelo de interfaz'. El papel del diseñador de interfaz es reconciliar estas diferencias y derivar una representación consecuente de la interfaz: Principiantes: en general no tienen conocimientos sintáctico ni conocimientos semánticos de la utilización de la aplicación o del sistema. Usuarios esporádicos y con conocimientos: poseen un conocimiento semántico razonable, pero una retención baja de la información necesaria para utilizar la interfaz; Usuarios frecuentes y con conocimientos: poseen el conocimiento sintáctico y semántico suficiente como para llegar al «síndrome del usuario avanzado)), esto es, individuos que buscan interrupciones breves y modos abreviados de interacción. La percepción del sistema (el modelo de usuario) es la imagen del sistema que el usuario final tiene en su mente. La imagen del sistema es una combinación de fachada externa del sistema basado en computadora (la apariencia del sistema) y la información de soporte (libros, manuales, cintas de vídeo, archivos de ayuda) todo lo cual ayuda a describir la sintaxis y la semántica del sistema. Cuando la imagen y la percepción del sistema coinciden, los usuarios generalmente se sienten a gusto con el software y con su funcionamiento. Para llevar a cabo esta «mezcla» de modelos, el modelo de diseño deberá desarrollarse con el fin de acoplar la información del modelo de usuario, y la imagen del sistema deberá reflejar de forma precisa la información sintáctica y semántica de la interfaz. Los modelos descritos anteriormente en esta sección son «abstracciones de lo que el usuario está haciendo o piensa que está haciendo o de lo que cualquier otra persona piensa que debería estar haciendo cuando utiliza un sistema interactivo» [MON84]. Esencialmente, estos modelos permiten que el diseñador de la interfaz satisfaga un elemento clave del principio más importante del diseño de la interfaz de usuario: «quien conoce al usuario, conoce las tareas» 3.7.2 ANALISIS Y MODELADO DE TAREAS El análisis de tareas se puede aplicar de dos maneras. Un sistema interactivo basado en computadora se suele utilizar para reemplazar una actividad manual o semi-manual. Para comprender las tareas que se han de llevar a cabo para lograr el objetivo de la actividad, un ingeniero deberá entender las tareas que realizan los hombres actualmente (cuando se utiliza un enfoque manual) y hacer corresponder esta tareas con un conjunto de tareas similar (aunque no necesariamente idénticas) que se implementan en el contexto de la interfaz de usuario.
  • 23. De forma alternativa, el ingeniero puede estudiar la especificación existente para la solución basada en computadora y extraer un conjunto de tareas que se ajusten al modelo de usuario, al modelo de diseño y a la percepción del sistema. Independientemente del enfoque global utilizado para el análisis de tareas, el ingeniero deberá en primer lugar definirlas y clasificarlas. El modelo de diseño de la interfaz deberá adaptarse a cada una de estas tareas de forma consecuente con el modelo del usuario (el perfil de un diseñador «típico» de interiores) y con la percepción del sistema (lo que el diseñador de interiores espera de un sistema automatizado). Establecer los objetivo e intenciones para cada tarea. Hacer corresponder cada objetivo/intención con una secuencia de acciones específicas Especificar la secuencia de acciones de tareas y subtareas, también llamado escenario del usuario, de la manera en que se ejecutarán a nivel de la interfaz. Indicar el estado del sistema, esto es, el aspecto que tiene la interfaz cuando se está llevando a cabo el escenario del usuario. Definir los mecanismo de control, esto es, los objetos y acciones disponibles para que el usuario altere el estado del sistema. Mostrar la forma en que los mecanismos de control afectan al estado del sistema. Indicar la forma en que el usuario interpreta el estado del sistema a partir de la información proporcionada gracias a la interfaz. 3.7.3 ASPECTOS DEL DISEÑO Un paso importante en el diseño de la interfaz es la definición de los objetos y acciones que se van a aplicar. Para llevar a cabo esta definición, el escenario del usuario se analiza sintácticamente de manera muy similar a como se analizaban las narrativas de procesamiento del Capítulo 12. Esto es, se escribe la descripción del escenario de un usuario. Los sustantivos (objetos) y los verbos (acciones) se aíslan para crear una lista de objetos y de acciones. Los objetos se identifican como objetos origen, destino y de aplicación. Un objeto origen (por ejemplo, un icono de informes) se arrastra y se coloca sobre otro objeto destino (por ejemplo, un icono de impresora). La implicación de esta acción es crear una copia impresa de un informe. Un objeto de aplicación representa los datos específicos de la aplicación que no se manipulan directamente como parte de la interacción de la pantalla.
  • 24. Una vez creado el modelo de diseño, se implementa como un prototipo’, que los usuarios han examinado (aquellos que adaptan el modelo del usuario descrito anteriormente), y que se ha basado en los comentarios de los usuarios. Para acoplar este enfoque de diseño iterativo se ha desarrollado una clase extensa de herramientas diseño de interfaz y de generación de prototipos. Estas herramientas así llamadas, juego de herramientas de la interfaz de usuario o sistemas de desarrollo de la interfaz de usuario (SDIU), proporcionan componentes u objetos que facilitan la creación de ventanas, menús, interacción de dispositivos, mensajes de error, Órdenes y muchos otros elementos de un entorno interactivo. Mediante los componentes de software preestablecidos que se pueden utilizar para crear una interfaz de usuario, un SDIU proporcionará los mecanismos [MYE89] para: gestionar los dispositivos de salida (tales como el ratón o el teclado); validar la entrada del usuario; manipular los errores y visualizar mensajes de error; proporcionar una respuesta (por ejemplo, un eco automático de la entrada) proporcionar ayuda e indicaciones de solicitud de entrada de órdenes; manipular ventanas y campos, desplazarse por las ventanas; establecer conexiones entre el software de la aplicación y la interfaz; aislar la aplicación de las funciones de gestión de la interfaz; permitir que el usuario personalice la interfaz. Estas funciones se pueden implementar mediante un enfoque gráfico o basado en lenguajes. 3.7.4 EVALUACION DEL DISEÑO Una vez que se ha creado un prototipo de interfaz de usuario, deberá sufrir una evaluación para determinar si cumple las necesidades del usuario. La evaluación podrá abarcar un espectro de formalidad: desde «pruebas» informales en donde el usuario proporciona respuestas espontáneas hasta un estudio formalmente diseñado que utilizará métodos estadísticos para la evaluación de cuestionarios cumplimentados por un grupo de usuarios finales. Una vez finalizado el modelo de diseño, se crea un prototipo de primer nivel. Este prototipo es evaluado por el usuario, que es quien proporcionará al diseñador los comentarios directos sobre la eficacia de la interfaz. Durante las primeras revisiones del diseño se podrán aplicar una serie de criterios [MOR811 de evaluación: 1. La duración y la complejidad de la especificación que se haya escrito del sistema y de su interfaz proporcionan una indicación de la cantidad de aprendizaje que requieren los usuarios del sistema. 2. La cantidad de tareas especificadas y la cantidad media de acciones por tarea proporcionan una indicación del tiempo y de la eficacia global del sistema.
  • 25. 3. La cantidad de acciones, tareas y estados de sistemas indicados con el modelo de diseño indican la carga de memoria que tienen los usuarios del sistema. 4. El estilo de la interfaz, las funciones de ayuda y el protocolo de solución de errores proporcionan una indicación general de la complejidad de la interfaz y el grado de aceptación por parte del usuario. La interfaz de usuario es la ventana del software. En muchos casos, la interfaz modela la percepción que tiene un usuario de la calidad del sistema. Si la ventana se difumina, se ondula o se quiebra, el usuario puede rechazar un sistema potente basado en computadora. 3.7.5 DIRECTRICES PARA EL DISEÑO 3.7.5.1 DIRECTRICES INTERACCIÓN GENERAL Consistencia de formato Respuestas significativas Verificación de acciones destructivas Deshacer acciones Eficiencia diálogo: distancia que debe moverse el ratón,... Autoprotección del sistema ante errores Cohesión órdenes y acciones: organización de órdenes por tipo Ayudas sensibles al contexto Verbos y frases sencillos para las órdenes 3.7.5. 2 DIRECTRICES VISUALIZACIÓN DE INFORMACION Información relevante en el contexto actual No abrumar con datos: usar gráficos y esquemas Mantener contexto visual Etiquetas consistentes, abreviaciones estándar y colores predecibles Mensajes de error significativos
  • 26. Uso de ventanas Presentaciones analógicas Geografía de la pantalla 3.7.5.3 DIRECTRICES ENTRADA DE DATOS Minimizar número acciones entrada: reducir la cantidad de escritura necesaria, usando el ratón, macros,... Consistencia visualización-introducción Personalizar entrada: órdenes personalizadas, eliminar mensajes de advertencia y verificación,... Interacción personalizada: por ejemplo, escoger teclado o ratón. Desactivar órdenes inapropiadas Eliminar entradas innecesarias: .00 en cantidades enteras, información disponible automáticamente o que se puede calcular,... 3.8 PSICOLOGIA DEL COLOR La psicología del color es un campo de estudio que está dirigido a analizar el efecto del color en la percepción y la conducta humana. Desde el punto de vista estrictamente médico, todavía es una ciencia inmadura en la corriente principal de la psicología contemporánea, teniendo en cuenta que muchas técnicas adscritas a este campo pueden categorizarse dentro del ámbito de la medicina alternativa. Sin embargo, en un sentido más amplio, el estudio de la percepción de los colores constituye una consideración habitual en el diseño arquitectónico, la moda, la señalética y el arte publicitario. Si bien la psicología del color es un área relativamente nueva de la investigación científica, las civilizaciones antiguas creían en la influencia del color sobre los seres humanos. Tanto en China como en el antiguo Egipto y en la India se usaba la cromoterapia para curar diversas dolencias. == Teoría del color de Goethe =='== Teoría del color de Goethe == Goethe intentó deducir leyes de armonía del color, incluyendo los aspectos fisiológicos del tema, vale decir, de qué
  • 27. forma nos afectan los colores, y -en general- el fenómeno subjetivo de la visión. En este campo, analizó por ejemplo los efectos de las post-visión, y su consecuencia en el concepto de colores complementarios, deduciendo que la complementariedad es una sensación que como tal, no se origina en cuestiones físicas relativas a la incidencia lumínica sobre un objeto, sino por el funcionamiento de nuestro sistema visual. Johann Eckermann refiere una cita de los últimos años de Goethe mostrando la importancia que éste le asignaba a la cuestión: "De todo lo que he hecho como poeta, no obtengo vanidad alguna. He tenido como contemporáneos buenos poetas, han vivido aún mejores antes que yo y vivirán otros después. Pero haber sido en mi siglo el único que ha visto claro en esta ciencia difícil de los colores, de ello me vanaglorio, y soy consciente de ser superior a muchos sabios". Una mención de la Enciclopedia Británica, permite posiblemente redondear el contexto del problema: "Artistas y diseñadores han estudiado los efectos del color por siglos, y han desarrollado una multitud de teorías sobre el uso del color. El número y variedad de tales teorías demuestra que no pueden aplicarse reglas universales: la percepción del color depende de la experiencia individual” Newton uso por primera vez la palabra espectro (del latín, "apariencia" o "aparición") en 1671 al describir sus experimentos en óptica. Newton observó que cuando un estrecho haz de luz solar incide sobre un prisma de vidrio triangular con un ángulo, una parte se refleja y otra pasa a través del vidrio y se desintegra en diferentes bandas de colores. También Newton hizo converger esos mismos rayos de color en una segunda lente para formar nuevamente luz blanca. Demostró que la luz solar tiene todos los colores del arco iris. Cuando llueve y luce el sol, cada gota de lluvia se comporta igual que el prisma de Newton y de la unión de millones de gotas de agua se forma el fenómeno del arco iris. A pesar que el espectro es continuo y por lo tanto no hay cantidades vacías entre uno y otro color, se puede establecer la siguiente aproximación: Color Longitud de onda violeta ~ 380-450 nm azul ~ 450-495 nm verde ~ 495-570 nm amarillo ~ 570–590 nm
  • 28. naranja ~ 590–620 nm rojo ~ 620–750 nm 3.8.1 CLASIFICACION DE LOS COLORES Los colores primarios no son una propiedad fundamental de la luz, sino un concepto biológico, basado en la respuesta fisiológica del ojo humano a la luz. Un ojo humano normal sólo contiene tres tipos de receptores, llamados conos. Estos responden a longitudes de onda específicas de luz roja, verde y azul. Las personas y los miembros de otras especies que tienen estos tres tipos de receptores se llaman tricrómatas. Aunque la sensibilidad máxima de los conos no se produce exactamente en las frecuencias roja, verde y azul, son los colores que se eligen como primarios, porque con ellos es posible estimular los tres receptores de color de manera casi independiente, proporcionando un amplio gamut. Para generar rangos de color óptimos para otras especies aparte de los seres humanos se tendrían que usar otros colores primarios aditivos. Por ejemplo, para las especies conocidas como tetracrómatas, con cuatro receptores de color distintos, se utilizarían cuatro colores primarios (como los humanos sólo pueden ver hasta 400 nanómetros (violeta), pero los tetracrómatas pueden ver parte del ultravioleta, hasta los 300 nanómetros aproximadamente, este cuarto color primario estaría situado en este rango y probablemente sería un magenta espectral puro, en lugar del magenta que vemos). Muchas aves y marsupiales son tetracrómatas, y se ha sugerido que algunas mujeres nacen también tetracrómatas,[5] [6] con un receptor extra para el amarillo. Por otro lado, la mayoría de los mamíferos tienen sólo dos tipos de receptor de color y por lo tanto son dicrómatas; para ellos, sólo hay dos colores primarios. Las televisiones y los monitores de ordenador son las aplicaciones prácticas más comunes de la síntesis aditiva. Rojo + Verde = Amarillo Verde + Azul = Cian Azul + Rojo = Magenta Azul + Rojo + Verde = Blanco
  • 29. Síntesis sustractiva: colores primarios Todo lo que no es color aditivo es color sustractivo. En otras palabras, todo lo que no es luz directa es luz reflejada en un objeto, la primera se basa en la síntesis aditiva de color, la segunda en la síntesis sustractiva de color. La síntesis sustractiva explica la teoría de la mezcla de pigmentos y tintes para crear color. El color que parece que tiene un determinado objeto depende de qué partes del espectro electromagnético son reflejadas por él, o dicho a la inversa, qué partes del espectro son absorbidas. Se llama síntesis sustractiva porque a la energía de radiación se le sustrae algo por absorción. En la síntesis sustractiva el color de partida siempre suele ser el color acromático blanco, el que aporta la luz (en el caso de una fotografía el papel blanco, si hablamos de un cuadro es el lienzo blanco), es un elemento imprescindible para que las capas de color puedan poner en juego sus capacidades de absorción. En la síntesis sustractiva los colores primarios son el amarillo, el magenta y el cian, cada uno de estos colores tiene la misión de absorber el campo de radiación de cada tipo de conos. Actúan como filtros, el amarillo, no deja pasar las ondas que forman el azul, el magenta no deja pasar el verde y el cian no permite pasar al rojo. En los sistemas de reproducción de color según la síntesis sustractiva, la cantidad de color de cada filtro puede variar del 0% al 100%. Cuanto mayor es la cantidad de color mayor es la absorción y menos la parte reflejada, si de un color no existe nada, de ese campo de radiaciones pasara todo. Por ello, a cada capa de color le corresponde modular un color sensación del órgano de la vista: al amarillo le corresponde modular el azul, al magenta el verde y al cian el rojo. Así mezclando sobre un papel blanco cian al 100% y magenta al 100%, no dejaran pasar el color rojo y el verde con lo que el resultado es el color azul. De igual manera el magenta y el amarillo formaran el rojo, mientras el cian y el amarillo forman el verde. El azul, verde y rojo son colores secundarios en la síntesis sustractiva y son más oscuros que los primarios. En las mezclas sustractivas se parte de tres primarios claros y según se mezcla los nuevos colores se van oscureciendo, al mezclar estamos restando luz. Los tres primarios mezclados dan el negro. La aplicación práctica de la síntesis sustractiva es la impresión a color y los cuadros de pintura. Cian + Magenta = Azul Magenta + Amarillo = Rojo Cian + Amarillo = Verde
  • 30. Cian + Amarillo + Magenta = Negro Colores elementales Los ocho colores elementales corresponden a las ocho posibilidades extremas de percepción del órgano de la vista. Las posibilidades últimas de sensibilidad de color que es capaz de captar el ojo humano. Estos resultan de las combinaciones que pueden realizar los tres tipos de conos del ojo, o lo que es lo mismo las posibilidades que ofrecen de combinarse los tres primarios. Estas ocho posibilidades son los tres colores primarios, los tres secundarios que resultan de la combinación de dos primarios, más los dos colores acromáticos, el blanco que es percibido como la combinación de los tres primarios (síntesis aditiva: colores luz) y el negro es la ausencia de los tres.[10] Rojo Verde Azul Amarillo Cian Magenta Blanco Negro Por tanto colores tradicionales como el violeta, el naranja o el marrón no son colores elementales. El blanco y el negro no pueden considerarse colores y por lo tanto no aparecen en un círculo cromático, el blanco es la presencia de todos los colores y el negro es su ausencia total. Sin embargo el negro y el blanco al combinarse forman el gris el cual también se marca en escalas. Esto forma un círculo propio llamado "círculo cromático en escala de grises" o "círculo de grises". En la teoría del color se dice que dos colores se denominan complementarios si, al ser mezclados en una proporción dada el resultado de la mezcla es un color neutral (gris, blanco, o negro). Colores más frecuentes Cada color determinado está originado por una mezcla o combinación de diversas longitudes de onda. En las siguientes tablas se agrupan los colores similares. A cada color se le han asociado sus matices. El matiz es la cualidad que permite diferenciar un color de otro: permite clasificarlo en términos de rojizo, verdoso, azulado, etc. Se refiere a la ligera variación de tono que un color hace en el círculo cromático en su zona contigua (o dicho de otra forma la ligera variación en el espectro visible). Así un verde azulado o a un verde
  • 31. amarillo son matices del verde cuando la longitud de onda dominante en la mezcla de longitudes de onda es la que corresponde al verde, y hablaremos de un matiz del azul cuando tenemos un azul verdoso o un azul magenta donde la longitud de onda dominante de la mezcla corresponda al azul. Rojo y sus matices: Nombre Muestra HTML RGB HSV 10 Rojo #FF0000 255 0 0 0° 100% 0% 86 Carmesí #DC143C 220 20 60 348° 91% % 89 Bermellón #E34234 227 66 51 5° 77% % 10 Escarlata #FF2400 255 36 0 8° 100% 0% 50 Granate #800000 128 0 0 0° 100% % 59 Carmín #960018 150 0 24 350° 100% % 64 Amaranto #E52B50 229 43 80 345° 78% % Verde y sus matices: Nombre Muestra HTML RGB HSV Verde #00FF00 0 255 0 120° 100% 100% Chartreuse #7FFF00 127 255 0 90° 100% 100%
  • 32. Verde Kelly #4CBB17 76 187 23 120° 48% 48% Esmeralda #50C878 80 200 120 140° 60% 78% Jade #00A86B 0 168 107 158° 100% 66% Verde #40826D 64 130 109 113° 87% 97% Veronés Arlequín #44944A 68 148 74 105° 97% 50% Espárrago #7BA05B 123 160 91 92° 43% 63% Verde Oliva #6B8E23 107 142 35 80° 75% 56% Verde #355E3B 53 94 59 120° 45% 45% Cazador Azul y sus matices: Nombre Muestra HTML RGB HSV Azul #0000FF 0 0 255 240° 100% 100% Azul cobalto #0047AB 0 71 171 215° 100% 67% Azul marino #120A8F 18 10 143 244° 93% 56% Azur #0000CD 0 0 250 ?° 93% ?% Zafiro #0131B4 1 49 180 224° 99% 35% Añil o Indigo #4B0082 75 0 130 275° 100% 51% Turquí #000080 0 0 128 240° 100% 50% Azul de #003153 0 49 83 250° 100% 33% Prusia
  • 33. Azul #6050DC 96 80 220 247° 67% 59% Majorelle Magenta y sus matices: Nombre Muestra HTML RGB HSV 10 Magenta #FF00FF 255 0 255 300° 100% 0 % 62 Fucsia #F400A1 253 63 146 334° 98% % 70 Morado #C54B8C 197 75 140 285° 67% % 10 Malva #E0B0FF 224 176 255 276° 31% 0 % 78 Lila #C8A2C8 200 162 200 300° 19% % 84 Salmón #FEC3AC 254 195 172 17° 98% % 96 Lavanda #E6E6fA 230 230 250 245° 40% % 10 Rosa #FFCBDB 255 192 203 350° 25% 0 % Cian y sus matices: Nombre Muestra HTML RGB HSV 10 Cian #00FFFF 0 255 255 180° 100% 0%
  • 34. 84 Turquesa #30D5C8 48 213 200 175° 77% % 10 Celeste #87CEFF 135 206 255 204° 47% 0% 89 Cerúleo #9BC4E2 155 196 226 205° 31% % 10 Aguamarina #7FFFD4 127 255 212 160° 50% 0% Amarillo y sus matices: Nombre Muestra HTML RGB HSV Amarillo #FFFF00 255 255 0 60° 100% 100% Limón #FDE910 253 233 16 55° 94% 99% Oro #FFD700 255 215 0 51° 100% 100% Ámbar #FFBF00 255 191 0 45° 100% 100% Amarillo indio #E3A857 227 168 87 35° 62% 89% Amarillo #FFBA00 255 186 0 44° 100% 100% selectivo Marrón y sus matices: Nombre Muestra HTML RGB HSV Marrón o #964B00 150 75 0 30° 100% 59% Pardo Caqui #94812B 148 129 43 49° 55% 37%
  • 35. Ocre #CC7722 204 119 34 30° 83% 80% Siena #B87333 184 115 51 29° 29% 72% Siena Pálido #DA8A67 218 138 95 18° 56% 85% Borgoña #800020 128 0 32 345° 50% 50% Violeta y sus matices: Nombre Muestra HTML RGB HSV Violeta #8B00FF 139 0 255 273° 100% 100% Lavanda #B57EDC 181 126 220 270° 76% 76% floral Amatista #9966CC 153 102 204 270° 50% 80% Púrpura #660099 102 0 153 280° 100% 60% Púrpura de #66023C 102 2 60 277° 67% 44% Tiro Naranja y sus matices: Nombre Muestra HTML RGB HSV 10 Naranja #FF7028 255 112 40 60° 100% 0% 10 Coral #FF7F50 255 127 80 16° 69% 0% Sesamo #FF8C69 255 140 105 14° 59% 10
  • 36. 0% 87 Albaricoque #FBCEB1 251 206 177 30° 25% % 96 Beige #F5DEB3 245 222 179 39° 26% % 10 Piel #FFCC99 255 200 160 30° 40% 0% Blancos, grises y negros: Nombre Muestra HTML RGB HSV 10 Blanco #FFFFFF 255 255 255 0° 0% 0 % ? Nieve #FFFAFA 255 250 250 ?° ?% % ? Lino #FAF0E6 250 240 230 ?° ?% % 96 Hueso #F5F5DC 245 245 220 60° 10% % 10 Marfil #FFFDD0 255 253 208 57° 18% 0 % 75 Plateado #C0C0C0 192 192 192 0° 0% % 50 Gris #808080 128 128 128 0° 0% % 0 Negro #000000 0 0 0 0° 0% %
  • 37. Efecto de los colores en los estados de ánimo de las personas El uso de ciertos colores impacta gradualmente en el estado de ánimo de las personas, muchos de ellos son utilizados con esa intención en lugares específicos, por ejemplo en los restaurantes es muy común que se utilice decoración de color naranja ya que abre el apetito, en los hospitales se usa colores neutros para dar tranquilidad a los pacientes, y para las entrevistas de trabajo es recomendable llevar ropa de colores oscuros, ya que da la impresión de ser una persona responsable y dedicada; estos son algunos ejemplos de la relación entre los colores y las emociones. Colores análogos: Se utilizan de manera adjunta y producen una sensación de armonía. Colores complementarios: Cuando son usados producen un efecto de agresividad, provocado por el máximo contraste al utilizarlos juntos. Colores monocromáticos: Al utilizarlos producen una sensación de unidad y estabilidad se pueden usar con diferente intensidad (más claro o más oscuro) esto va a depender de la luz 3.8.2 RECOMENDACIONES DE USO DEL COLOR Se trata de unos esquemas de color relacionados con la clasificación de los datos en representaciones visuales, que pueden ser muy útiles a la hora de escoger una paleta de colores para un gráfico o un mapa. Brewer considera 4 tipos diferentes de esquemas de color que se pueden aplicar a diferentes tipos de clasificación de datos: Cualitativo: para representar un esquema con datos de distintas categorías (por ejemplo un mapa con la representación de diversos sectores industriales) se suelen representar de forma efectiva mediante diferencias en la tonalidad de color. Binario: para representar un esquema con datos de dos categorías (por ejemplo un mapa con países que pertenecen o no a una organización) se puede utilizar una gama cromática con diferencias en luminosidad o en la tonalidad del color. Divergente: para representar un esquema con dos conjuntos de datos alrededor de un punto de equilibrio (por ejemplo un mapa térmico), es útil servirse de un espectro de colores con dos valores claramente diferenciados en los extremos. Secuencial: para representar datos ordenados en forma secuencial (por ejemplo un incremento de valores en una misma categoría) la recomendación más habitual es utilizar variaciones en la luminosidad o saturación de un color determinado.
  • 38. 4.1 CONSTRUCCION La construcción de la solución desarrollada en forma de un programa real (o código). Considerando que la solución ha sido bien definida, este proceso es casi directo, pues es un proceso mental inmediato de las fases anteriores. Mediante rutinas, funciones, script, procedimientos y reglas del lenguaje de programación, se va ensamblando la aplicación de acuerdo con los estándares de estilo y de estructura. 4.1.1 EL PROCESO DE TRADUCCIÓN El proceso de traducción se compone internamente de varias etapas o fases, que realizan distintas operaciones lógicas. Es útil pensar en estas fases como en piezas separadas dentro del traductor, y pueden en realidad escribirse como operaciones codificadas separadamente aunque en la práctica a menudo se integren juntas. 4.1.2 PLANTEAMIENTO PSICOLOGICO Lo “psicológico” como un segmento situacional. Es decir, la relación interactiva entre un organismo y un objeto actúan como factores segmentadotes de una determinada situación. 4.1.3 MODELO SINTACTICO / SEMANTICO El análisis semántico realizado por un compilador es averiguar, por ejemplo, si una expresión dentro de un programa significa algo válido. • Una frase analizada a fondo, al terminar su validez lexicográfica, sintáctica y semántica, llega el momento de ser traducida. – En algunos compiladores suelen incluirse las funciones de generación de código (lenguaje máquina o al menos lenguaje ensamblador). El análisis sintáctico utilizado por un compilador (llamado parsers) se dividen en dos familias ascendentes y descendentes.
  • 39. UNIDAD IV 4.2 PRUEBAS Las pruebas del software son un elemento crítico para la garantía de calidad del software y representa una revisión final de las especificaciones, del diseño y de la codificación. La creciente percepción del software como un elemento del sistema y la importancia de los «costes» asociados a un fallo del propio sistema, están motivando la creación de pruebas minuciosas y bien planificadas. No es raro que una organización de desarrollo de software emplee entre el 30 y el 40 por ciento del esfuerzo total de un proyecto en las pruebas. En casos extremos, las pruebas del software para actividades críticas (por ejemplo, control de tráfico aéreo, control de reactores nucleares) puede costar ¡de tres a cinco veces más que el resto de los pasos de la ingeniería del software juntos! 4.2.1 FUNDAMENTOS DE LAPRUEBA Las pruebas presentan una interesante anomalía para el ingeniero del software. Durante las fases anteriores de definición y de desarrollo, el ingeniero intenta construir el software partiendo de un concepto abstracto y llegando a una implementación tangible. A continuación, llegan las pruebas. El ingeniero crea una serie de casos de prueba que intentan «demoler» el software construido. De hecho, las pruebas son uno de los pasos de la ingeniería del software que se puede ver (por lo menos, psicológicamente) como destructivo en lugar de constructivo. Los ingenieros del software son, por naturaleza, personas constructivas. Las pruebas requieren que se descarten ideas preconcebidas sobre la «corrección» del software que se acaba de desarrollar y se supere cualquier conflicto de intereses que aparezcan cuando se descubran errores. ¿Deben infundir culpabilidad las pruebas? ¿Son realmente destructivas? La respuesta a estas preguntas es: ¡No! Sin embargo, los objetivos de las pruebas son algo diferentes de lo que podríamos esperar. 4.2.2 OBJETIVOS DE LA PRUEBA
  • 40. La prueba es el proceso de ejecución de un programa con la intención de descubrir un error. Un buen caso de prueba es aquel que tiene una alta probabilidad de mostrar un error no descubierto hasta entonces. Una prueba tiene éxito si descubre un error no detectado hasta entonces. Los objetivos anteriores suponen un cambio dramático de punto de vista. Nos quitan la idea que, normalmente, tenemos de que una prueba tiene éxito si no descubre errores. Nuestro objetivo es diseñar pruebas que sistemáticamente saquen a la luz diferentes clases de errores, haciéndolo con la menor cantidad de tiempo y de esfuerzo. Si la prueba se lleva a cabo con éxito (de acuerdo con el objetivo anteriormente establecido), descubrirá errores en el software. Como ventaja secundaria, la prueba demuestra hasta qué punto las funciones del software parecen funcionar de acuerdo con las especificaciones y parecen alcanzarse los requisitos de rendimiento. Además, los datos que se van recogiendo a medida que se lleva a cabo la prueba proporcionan una buena indicación de la fiabilidad del software y, de alguna manera, indican la calidad del software como un todo. Pero, la prueba no puede asegurar la ausencia de defectos; sólo puede demostrar que existen defectos en el software. 4.2.2.1 PRINCIPIOS DE LA PRUEBA Antes de la aplicación de métodos para el diseño de casos de prueba efectivos, un ingeniero del software deberá entender los principios básicos que guían las pruebas del software. Davis [DAV95] sugiere un conjunto de principios de prueba A todas las pruebas se les debería poder hacer un seguimiento hasta los requisitos del cliente. Como hemos visto, el objetivo de las pruebas del software es descubrir errores. Se entiende que los defectos más graves (desde el punto de vista del cliente) son aquellos que impiden al programa cumplir sus requisitos. Las pruebas deberían planificarse mucho antes de que empiecen. La planificación de las pruebas pueden empezar tan pronto como esté completo el modelo de requisitos. La definición detallada de los casos de prueba puede empezar tan pronto como el modelo de diseño se ha consolidado. Por tanto, se pueden planificar y diseñar todas las pruebas antes de generar ningún código. El principio de Pareto es aplicable a la prueba del software. Dicho de manera sencilla, el principio de Pareto implica que al 80 por 100 de todos los errores descubiertos durante las pruebas se les puede hacer un seguimiento hasta un 20
  • 41. por 100 de todos los módulos del programa. El problema, por supuesto, es aislar estos módulos sospechosos y probarlos concienzudamente. Las pruebas deberían empezar por «lo pequeño» y progresar hacia «lo grande». Las primeras pruebas planeadas y ejecutadas se centran generalmente en módulos individuales del programa. A medida que avanzan las pruebas, desplazan su punto de mira en un intento de encontrar errores en grupos integrados de módulos y finalmente en el sistema entero No son posibles las pruebas exhaustivas. El número de permutaciones de caminos para incluso un programa de tamaño moderado es excepcionalmente grande. Por este motivo, es imposible ejecutar todas las combinaciones de caminos durante las pruebas. Es posible, sin embargo, cubrir adecuadamente la lógica del programa y asegurarse de que se han aplicado todas las condiciones en el diseño a nivel de componente Para ser más eficaces, las pruebas deberían ser realizadas por un equipo independiente. Por «más eficaces » queremos referirnos a pruebas con la más alta probabilidad de encontrar errores (el objetivo principal de las pruebas). Por las razones que se expusieron anteriormente el ingeniero del software que creó el sistema no es el más adecuado para llevar a cabo las pruebas para el software. 4.2.2.2 FACILIDAD DE LA PRUEBA En circunstancias ideales, un ingeniero del software diseña un programa de computadora, un sistema o un producto con la «facilidad de prueba» en mente. Esto permite a los encargados de las pruebas diseñar casos de prueba más fácilmente. Pero, ¿qué es la «facilidad de prueba» James Bach describe la facilidad de prueba de la siguiente manera: La facilidad de prueba del software es simplemente la facilidad con la que se puede probar un programa de computadora. Como la prueba es tan profundamente difícil, merece la pena saber qué se puede hacer para hacerlo más sencillo. A veces los programadores están dispuestos a hacer cosas que faciliten el proceso de prueba y una lista de comprobación de posibles puntos de diseño, características, etc., puede ser útil a la hora de negociar con ellos. Existen, de hecho, métricas que podrían usarse para medir la facilidad de prueba en la mayoría de sus aspectos. A veces, la facilidad de prueba se usa para indicar lo adecuadamente que un conjunto particular de pruebas va a cubrir un producto. También es empleada por los militares para indicar lo fácil que se puede comprobar y reparar una herramienta en plenas maniobras. Esos dos significados no son lo mismo que «facilidad de prueba del software». La siguiente lista de
  • 42. comprobación proporciona un conjunto de características que llevan a un software fácil de probar. Operatividad. «Cuanto mejor funcione, más eficientemente se puede probar.» El sistema tiene pocos errores (los errores añaden sobrecarga de análisis y de generación de informes al proceso de prueba). Ningún error bloquea la ejecución de las pruebas El producto evoluciona en fases funcionales (permite simultanear el desarrollo y las pruebas). Observabilidad. «Lo que ves es lo que pruebas.» Se genera una salida distinta para cada entrada. Los estados y variables del sistema están visibles o se pueden consultar durante la ejecución. Los estados y variables anteriores del sistema están visibles o se pueden consultar (por ejemplo, registros de transacción). Todos los factores que afectan a los resultados están visibles. Un resultado incorrecto se identifica fácilmente. Los errores internos se detectan automáticamente a través de mecanismos de auto-comprobación. Se informa automáticamente de los errores internos. El código fuente es accesible. Controlabilidad. «Cuanto mejor podamos controlar el software, más se puede automatizar y optimizar.» Todos los resultados posibles se pueden generar a través de alguna combinación de entrada. Todo el código es ejecutable a través de alguna combinación de entrada. El ingeniero de pruebas puede controlar directamente los estados y las variables del hardware y del software. Los formatos de las entradas y los resultados son consistentes y estructurados. Las pruebas pueden especificarse, automatizarse y reproducirse convenientemente. Capacidad de descomposición. «Controlando el ámbito de las pruebas, podemos aislar más rápidamente los problemas y llevar a cabo mejores pruebas de regresión.» El sistema software está construido con módulos independientes. Los módulos del software se pueden probar independientemente
  • 43. Simplicidad. «Cuanto menos haya que probar, más rápidamente podremos probarlo.» Simplicidad funcional (por ejemplo, el conjunto de características es el mínimo necesario para cumplir los requisitos). Simplicidad estructural (por ejemplo, la arquitectura es modularizada para limitar la propagación de fallos). Simplicidad del código (por ejemplo, se adopta un estándar de código para facilitar la inspección y el mantenimiento). Estabilidad. «Cuanto menos cambios, menos interrupciones a las pruebas.» Los cambios del software son infrecuentes. Los cambios del software están controlados. Los cambios del software no invalidan las pruebas existentes. El software se recupera bien de los fallos. Facilidad de comprensión. «Cuanta más información tengamos, más inteligentes serán las pruebas.» El diseño se ha entendido perfectamente. Las dependencias entre los componentes internos, externos y compartidos se han entendido perfectamente. Se han comunicado los cambias del diseño. La documentación técnica es instantáneamente accesible. La documentación técnica está bien organizada. La documentación técnica es específica y detallada. La documentación técnica es exacta. 4.2.2.3 PLAN DE PRUEBAS Las pruebas son un conjunto de actividades que se pueden planificar por adelantado y llevar a cabo sistemáticamente. Por esta razón, se debe definir en el proceso de la ingeniería del software una plantilla para las pruebas del software: un conjunto de pasos en los que podamos situar los métodos específicos de diseño de casos de prueba.
  • 44. características generales: Las pruebas comienzan a nivel de módulo’ y trabajan«hacia fuera», hacia la integración de todo el sistema basado en computadora. Según el momento, son apropiadas diferentes técnicas de prueba. La prueba la lleva a cabo el responsable del desarrollo del software y (para grandes proyectos) un grupo independiente de pruebas. La prueba y la depuración son actividades diferentes, pero la depuración se debe incluir en cualquier estrategia de prueba. Una estrategia de prueba del software debe incluir pruebas de bajo nivel que verifiquen que todos los pequeños segmentos de código fuente se han implementadocorrectamente, así como pruebas de alto nivel que validen las principales funciones del sistema frente a los requisitos del cliente. 4.2.2.3.1 ESTRATEGIA DE PRUEBA DEL SOFTWARE Se puede ver la estrategia para la prueba del software en el contexto de la espiral La prueba de unidad comienza en el vértice de la espiral y se centra en cada unidad del software, tal como está implementada en código fuente. La prueba avanza, al movernos hacia fuera de la espiral, hasta llegar a la prueba de integración, donde el foco de atención es el diseño y la vuelta por la espiral hacia fuera, encontramos la prueba de validación, donde se validan los requisitos establecidos como parte del análisis de requisitos del software, comparándolos con el sistema que ha sido construido. Finalmente, llegamos a la prueba del sistema, en la que se prueban como un todo el software y otros elementos del sistema. Para probar software de computadora nos movemos hacia fuera por una espiral que, a cada vuelta, aumenta el alcance de la prueba.
  • 45. 4.2.2.3.2 ASPECTOS ESTRATEGICOS Especificar los requisitos del producto de manera cuantificable mucho antes de que comiencen las pruebas. Aunque el objetivo principal de la prueba es encontrar errores, una buena estrategia de prueba también evalúa otras características de la calidad, tales como la portabilidad, facilidad de mantenimiento y facilidad de uso. Establecer los objetivos de la prueba de manera explícita. Se deberían establecer en términos medibles los objetivos específicos de la prueba. Por ejemplo, la efectividad de la prueba, la cobertura de la prueba, tiempo medio de fallo, el coste para encontrar y arreglar errores, densidad de fallos remanente o frecuencia de ocurrencia, y horas de trabajo por prueba de regresión deberían establecerse dentro de la planificación de la prueba. Comprender qué usuarios van a manejar el sofwarey desarrollar un perfil para cadacategoría de usuario. Usar casos que describan el escenario de interacción para cada clase de usuario pudiendo reducir el esfuerzo general de prueba concentrando la prueba en el empleo real del producto. Desarrollar un plan de prueba que haga hincapié en la «prueba de ciclo rápido». Gilb [GIL951 recomienda que un equipo de ingeniería del software «aprenda a probar en ciclos rápidos (2 por 100 del esfuerzo del proyecto) de incrementos de funcionalidad y/o mejora de la calidad Útiles para el cliente, y que se puedan probar sobre el terrenon. Construir un software «robusto» diseñado para probarse a sí mismo. El software debería diseñarse de manera que use técnicas de depuración antierrores. Usar revisiones técnicas formales efectivas como filtro antes de la prueba. Las revisiones técnicas formales pueden ser tan efectivas como las pruebas en el descubrimiento de errores. Por este motivo, las revisiones pueden reducir la cantidad de esfuerzo de prueba necesaria para producir software de alta calidad. Llevar a cabo revisiones técnicas formales para evaluar la estrategia de prueba y los propios casos de prueba. Las revisiones técnicas formales pueden descubrir inconsistencias, omisiones y errores claros en el enfoque de la prueba. Esto ahorra tiempo y también mejora la calidad del producto. Desarrollar un enfoque de mejora continua al proceso de prueba. Debería medirse la estrategia de prueba. Las métricas agrupadas durante la prueba deberían usarse como parte de un enfoque estadístico de control del proceso para la prueba del software.
  • 46. 4.2.3 PRUEBA DE UNIDAD La prueba de unidad centra el proceso de verificación en la menor unidad del diseño del software: el componente software o módulo. 4.2.3.1 CONSIDERACIONES Las pruebas que se dan como parte de la prueba de unidad están esquemáticamente ilustradas en la Figura 18.4. Se prueba la interfaz del módulo para asegurar que la información fluye de forma adecuada hacia y desde la unidad de programa que está siendo probada. Se examinan las estructuras de datos locales para asegurar que los datos que se mantienen temporalmente conservan su integridad durante todos los pasos de ejecución del algoritmo. Se prueban las condiciones límite para asegurar que el módulo funciona correctamente en los límites establecidos como restricciones de procesamiento. Se ejercitan todos los caminos independientes (caminos básicos) de la estructura de control con el fin de asegurar que todas las sentencias del módulo se ejecutan por lo menos una vez.
  • 47. Y, finalmente, se prueban todos los caminos de manejo de errores. Antes de iniciar cualquier otra prueba es preciso probar el flujo de datos de la interfaz del módulo. Si los datos no entran correctamente, todas las demás pruebas no tienen sentido. 4.2.3.2 PROCEDIMIENTOS En la Figura 18.5 se ilustra el entorno para la prueba de unidad. En la mayoría de las aplicaciones, un controlador no es más que un «programa principal» que acepta los datos del caso de prueba, pasa estos datos al módulo (a ser probado) e imprime los resultados importantes. Los resguardos sirven para reemplazar módulos que están subordinados (llamados por) el componente que hay que probar. Un resguardo o un «subprograma simulado» usa la interfaz del módulo subordinado, lleva a cabo una mínima manipulación de datos, imprime una verificación de entrada y devuelve control al módulo de prueba que lo invocó. Los controladores y los resguardos son una sobrecarga de trabajo. Es decir, ambos son software que debe desarrollarse (normalmente no se aplica un diseño formal) pero que no se entrega con el producto de software final. Si los controladores y resguardos son sencillos, el trabajo adicional es relativamente pequeño.Desgraciadamente, muchos componentes no pueden tener una adecuada prueba unitaria con un «sencillo» software adicional. En tales casos, la prueba completa se pospone hasta que se llegue al paso de prueba de integración. 4.2.5 PRUEBA DE INTEGRACION La prueba de integración es una técnica sistemática para construir la estructura del programa mientras que, al mismo tiempo, se llevan a cabo pruebas para detectar errores asociados con la interacción. El objetivo es coger los módulos probados mediante la prueba de unidad y construir una estructura de programa que esté de acuerdo con lo que dicta el diseño. Efectuar una integración big bag es una estrategia vaga que está condenada al fracaso. la prueba de integración deberá ser conducida incrementalmente.
  • 48. 4.2.4 INTEGRACION ASCENDENTE La prueba de la integración ascendente, como su nombre indica, empieza la construcción y la prueba con los módulos atómicos (es decir, módulos de los niveles más bajos de la estructura del programa). Dado que los módulos se integran de abajo hacia arriba, el proceso requerido de los módulos subordinados siempre está disponible y se elimina la necesidad de resguardos. ¿Cuáles son los pasos para una integración ascendente? Se puede implementar una estrategia de integración ascendente mediante los siguientes pasos: 1. Se combinan los módulos de bajo nivel en grupos (a veces denominados construcciones) que realicen unasubfunción específica del software. 2. Se escribe un controlador (un programa de control de la prueba) para coordinar la entrada y la salida de los casos de prueba. 3. Se prueba el grupo. 4. Se eliminan los controladores y se combinan los grupos moviéndose hacia arriba por la estructura del programa. A medida que la integración progresa hacia arriba, disminuye la necesidad de controladores de prueba diferentes. De hecho, si los dos niveles superiores de la estructura del programa se integran de forma descendente, se puede reducir sustancialmente el número de controladores y se simplifica enormemente la integración de grupos. 4.2.4.2 INTEGRACION DESCENDENTE
  • 49. La prueba de integración descendente es un planteamiento incremental a la construcción de la estructura de programas. Se integran los módulos moviéndose hacia abajo por la jerarquía de control, comenzando por el módulo de control principal (programa principal). Los módulos subordinados (subordinados de cualquier modo) al módulo de control principal se van incorporando en la estructura, bien de forma primero-en-profundidad, o bien de forma primero-en- anchura. Cuando.desarrallas una planificación detallada del proyecto debes considerar la manera en que la integración se va a realizar, de forma que los componentes estén disponibles cuando se necesiten. El proceso de integración se realiza en una serie de cinco pasos: 1. Se usa el módulo de control principal como controlador de la prueba, disponiendo de resguardos para todos los módulos directamente subordinados al módulo de control principal. 2. Dependiendo del enfoque de integración elegido (es decir, primero-en- profundidad o primero-en-anchura) se van sustituyendo uno a uno los resguardos subordinados por los módulos reales. 3. Se llevan a cabo pruebas cada vez que se integra un nuevo módulo. 4. Tras terminar cada conjunto de pruebas, se reemplaza otro resguardo con el módulo real. 5. Se hace la prueba de regresión (Sección 18.4.3) para asegurarse de que no se han introducido errores nuevos.
  • 50. El proceso continúa desde el paso 2 hasta que se haya construido la estructura del programa entero. ¿Qué problemas puedes encontrar cuando elijas una estrategia de integración descendente? El primer enfoque (retrasar pruebas hasta reemplazar los resguardos por los módulos reales) hace que perdamos cierto control sobre la correspondencia de ciertas pruebas específicas con la incorporación de determina- ,dos módulos. Esto puede dificultar la determinación de las causas del error y tiende a violar la naturaleza altamente restrictiva del enfoque descendente. El segundo enfoque es factible pero puede llevar a un significativo incremento del esfuerzo a medida que los resguardos se hagan más complejos. El tercer enfoque, denominado prueba ascendente, se estudia en la siguiente sección. 4.2.5 PRUEBA DE REGRESION La prueba de regresión es volver a ejecutar un subconjunto de pruebas que se han llevado a cabo anteriormente para asegurarse de que los cambios no han propagado efectos colaterales no deseados. La prueba de regresión es una estrategia importante para reducir (efectos colateralesx Se deben ejecutor pruebas de regresión cada vez que se realice un cambio importante en el sohore (incluyendo la integración de nuevos módulos). El conjunto de pruebas de regresión (el subconjunto de pruebas a realizar) contiene tres clases diferentes de casos de prueba: una muestra representativa de pruebas que ejercite todas las funciones del software; pruebas adicionales que se centran en las funciones del software que se van a ver probablemente afectadas por el cambio; pruebas que se centran en los componentes del software que han cambiado. 4.2.6 PRUEBA DE VALIDACION La validación puede definirse de muchas formas, pero una simple (aunque vulgar) definición es que la validación se consigue cuando el software funciona de acuerdo con las expectativas razonables del cliente. En este punto, un desarrollador de software estricto podría protestar: «¿Qué o quién es el árbitro de las expectativas razonables?»
  • 51. Las expectativas razonables están definidas en la Especificación de Requisitos del Software –un documento que describe todos los atributos del software visibles para el usuario. La especificación contiene una sección denominada-. «Criterios de validación». La información contenida en esa sección forma la base del enfoque a la prueba de validación. La validación del software se consigue mediante una serie de pruebas de caja negra que demuestran la conformidad con los requisitos. Un plan de prueba traza la clase de pruebas que se han de llevar a cabo, y un procedimiento de prueba define los casos de prueba específicos en un intento por descubrir errores de acuerdo con los requisitos. Tanto el plan como el procedimiento estarándiseñados para asegurar que se satisfacen todos los requisitos funcionales, que se alcanzan todos los requisitos de rendimiento, que la documentación es correcta e inteligible y que se alcanzan otros requisitos (por ejemplo, portabilidad, compatibilidad, recuperación de errores, facilidad de mantenimiento). Una vez que se procede con cada caso de prueba de validación, puede darse una de las dos condiciones siguientes: (1) las características de funcionamiento o de rendimiento están de acuerdo con las especificaciones y son aceptables; o (2)’se descubre una desviación de las especificaciones y se crea una lista de deficiencias. Las desviaciones o errores descubiertos en esta fase del proyecto raramente se pueden corregir antes de la terminación planificada. A menudo es necesario negociar con el cliente un método para resolver las deficiencias. 4.2.6.1 CRITERIOS Se han realizado pocos estudios para determinar qué factores son los más importantes en el momento de seleccionar una metodología de desarrollo de software. Uno es el de Sachidanandam Sakthivec, donde la conclusión obtenida, es que no todos los requisitos son iguales de importantes para los profesionales de desarrollo de software. Esta investigación se basó en requisitos de la metodología. Seguidamente se muestra un cuestionario para clasificar la importancia de los números relevantes Posteriormente mediante un programa que utiliza algoritmos computacionales AHP (Analityc Hierarchy Process), identificó la importancia relativa de los requisitos de la metodología para cada participante en la encuesta. Las conclusiones de la investigación dieron el siguiente resultado: La capacidad de una metodología para desarrollar sistemas con la calidad requerida es el requisito más importante para los profesionales del desarrollo. Coincidencia con los investigadores en la importancia que tiene el criterio de satisfacción del usuario en la calidad del nuevo sistema
  • 52. La capacidad para desarrollar gran variedad de sistemas tiene mayor importancia que los aspectos relacionados con la productividad. 4.2.6.2 REVISION DE LA CONFIGURACION Deshabilite el servicio de configuración inalámbrica rápida utilizando la API de configuración inalámbrica rápida en Microsoft Windows CE 5.0. Sin embargo, el servicio Configuración inalámbrica rápida puede mantener estableciendo los identificadores de conjunto de servicio (SSID) que no son válidos en el controlador de red inalámbrica. Este problema se produce si una aplicación envía un SSID al controlador de red inalámbrica después de deshabilitar el servicio de configuración inalámbrica rápida. Nota: El SSID que no es válidos se compone de 32 bytes de caracteres aleatorios. Información de actualización de softwareUna actualización de software compatible... Información de actualización de software Una actualización de software compatible ahora está disponible de Microsoft como actualización mensual de Windows CE 5.0 Platform Builder (noviembre de 2007). Puede confirmar desplazándose a la sección "Información de archivos" de este artículo. El nombre de archivo de paquete contiene la versión del producto, fecha, número de artículo de Knowledge Base y tipo de procesador. El formato de nombre de archivo de paquete es: tipo de versión-aammdd-kbnnnnnn-procesador de producto Por ejemplo: Wincepb50-060503-kb917590-armv4i.msi es la corrección de ARMV4i Windows CE 5.0 Platform Builder documentada en el artículo 917590 de KB y contenida en la actualización mensual de mayo de 2006. Para resolver este problema inmediatamente, haga clic en el número de artículo siguiente para información acerca de cómo obtener Windows CE Platform Builder y principales de las actualizaciones de software del sistema operativo: 837392 (http://support.microsoft.com/kb/837392/ ) Corrige cómo localizar el sistema del núcleo operativo para productos de Microsoft Windows CE Platform Builder Requisitos previos Esta actualización es compatible sólo si también están instaladas todas las actualizaciones publicadas previamente para este producto.
  • 53. Requisito de reinicio Después de aplicar esta actualización, debe realizar una compilación limpia de la plataforma toda. Para limpiar la plataforma, haga clic en Limpiar en el menú Generar . Para generar la plataforma, haga clic en Build Platform en el menú Generar . No es necesario reiniciar el equipo después de aplicar esta actualizació 4.2.6.3 PRUEBAS DE ALFA Y BETA Es virtualmente imposible que un desarrollador de software pueda prever cómo utilizará el usuario realmente el programa. Se pueden malinterpretar las instrucciones de uso, se pueden utilizar habitualmente extrañas combinaciones de datos, y una salida que puede parecer clara para el responsable de las pruebas y puede ser ininteligible para el usuario. Cuando se construye software a medida para un cliente, se llevan a cabo una serie de pruebas de aceptación para permitir que el cliente valide todos los requisitos. Las realiza el usuario final en lugar del responsable del desarrollo del sistema, una prueba de aceptación puede ir desde un informal «paso de prueba» hasta la ejecución sistemática de una serie de pruebas bien planificadas. De hecho, la prueba de aceptación puede tener lugar a lo largo de semanas o meses, descubriendo así errores acumulados que pueden ir degradando el sistema. Si el software se desarrolla como un producto que va a ser usado por muchos clientes, no es práctico realizar pruebas de aceptación formales para cada uno de ellos. La mayoría de los desarrolladores de productos de software llevan a cabo un proceso denominado prueba alfa y beta para descubrir errores que parezca que sólo el usuario final puede descubrir. La prueba ulju se lleva a cabo, por un cliente, en el lugar de desarrollo. Se usa el software de forma natural con el desarrollador como observador del usuario y registrando los errores y los problemas de uso. Las pruebas alfa se llevan a cabo en un entorno controlado. Laprueba beru se lleva a cabo por los usuarios finales del software en los lugares de trabajo de los clientes. A diferencia de la prueba alfa, el desarrollador no está presente normalmente. Así, la prueba beta es una aplicación «en vivo» del software en un entorno que no puede ser controlado por el desarrollador. El cliente registra todos los problemas (reales o imaginarios) que encuentra durante la prueba beta e informa a intervalos regulares al desarrollador. Como resultado de los problemas informados durante la prueba beta, el desarrollador del software lleva a cabo modificaciones y así prepara una versión del producto de software para toda la clase de clientes.
  • 54. 4.2.7 PRUEBAS DEL SISTEMA De que el software es sólo un elemento de un sistema mayor basado en computadora. Finalmente, el software es incorporado a otros elementos del sistema (por ejemplo, nuevo hardware, información) y realizan una serie de pruebas de integración del sistema y de validación. Estas pruebas caen fuera del ámbito del proceso de ingeniería del software y no las realiza únicamente el desarrollador del software. Sin embargo, los pasos dados durante el diseño del software y durante la prueba pueden mejorar enormemente la probabilidad de éxito en la integración del software en el sistema. Un problema típico de la prueba del sistema es la ((delegación de culpabilidad». Esto ocurre cuando se descubre un error y cada uno de los creadores de cada elemento del sistema echa la culpa del problema a los otros. En vez de verse envuelto en esta absurda situación,el ingeniero del software debe anticiparse a los posibles problemas de interacción y: ( 1 ) diseñar caminos de manejo de errores que prueben toda la información procedente de otros elementos del sistema; (2) llevar a cabo una serie de pruebas que simulen la presencia de datos en mal estado o de otros posibles errores en la interfaz del software; (3) registrar los resultados de las pruebas como «evidencia» en el caso de que se le señale con el dedo; (4) participar en la planificación y el diseño de pruebas del sistema para asegurarse de que el software se prueba de forma adecuada . La prueba del sistema, realmente, está constituida por una serie de pruebas diferentes cuyo propósito primordial es ejercitar profundamente el sistema basado en computadora. Aunque cada prueba tiene un propósito diferente, todas trabajan para verificar que se han integrado adecuadamente todos los elementos del sistema y que realizan las funciones apropiadas. En las siguientes secciones examinamos los tipos de pruebas del sistema [BE1841 valiosos para sistemas basados en software. 4.2.7.1 RECUPERACION Muchos sistemas basados en computadora deben recuperarse de los fallos y continuar el proceso en un tiempo previamente especificado. En algunos casos, un sistema debe ser tolerante con los fallos; es decir, los fallos del proceso no deben hacer que cese el funcionamiento de todo el sistema. En otros casos, se debe corregir un fallo del sistema en un determinado periodo de tiempo para que no se produzca un serio daño económico. La prueba de
  • 55. recuperación es una prueba del sistema que fuerza el fallo del software de muchas formas y verifica que la recuperación se lleva a cabo apropiadamente. Si la recuperación es automática (llevada a cabo por el propio sistema) hay'que evaluar la corrección de la inicialización, de los mecanismos de recuperación del estado del sistema, de la recuperación de datos y del proceso de rearranque. Si la recuperación requiere la intervención humana, hay que evaluar los tiempos medios de reparación (TMR) para determinar si están dentro de unos límites aceptables. 4.2.7.2 SEGURIDAD Cualquier sistema basado en computadora que maneje información sensible o lleve a cabo acciones que puedan perjudicar (o beneficiar) impropiamente a las personas es un posible objetivo para entradas impropias o ilegales al sistema. Este acceso al sistema incluye un amplio rango de actividades: «piratas informáticom que intentan entrar en los sistemas por deporte, empleados disgustados que intentan penetrar por venganza e individuos deshonestos que intentan penetrar para obtener ganancias personales ilícitas. La prueba de seguridad intenta verificar que los mecanismos de protección incorporados en el sistema lo protegerán, de hecho, de accesos impropios. Para citar a Beizer [BEI84]: «Por supuesto, la seguridad del sistema debe ser probada en su invulnerabilidad frente a un ataque frontal, pero también debe probarse en su invulnerabilidad a ataques por los flancos o por la retaguardia. Durante la prueba de seguridad, el responsable de la prueba desempeña el papel de un individuo que desea entrar en el sistema. ¡Todo vale! Debe intentar conseguir las claves de acceso por cualquier medio, puede atacar al sistema con software a medida, diseñado para romper cualquier defensa que se haya construido, debe bloquear el sistema, negando así el servicio a otras personas, debe producir a propósito errores del sistema, intentando acceder durante la recuperación o debe curiosear en los datos sin protección, intentando encontrar la clave de acceso al sistema, etc. Con tiempo y recursos suficientes, una buena prueba de seguridad terminará por acceder al sistema. 4.2.7.3 RESISTENCIA
  • 56. Durante los pasos de prueba anteriores, las técnicas de caja blanca y de caja negra daban como resultado la evaluación del funcionamiento y del rendimiento normales del programa. Las pruebas de resistencia están diseñadas para enfrentar a los programas con situaciones anormales. En esencia, el sujeto que realiza la prueba de resistencia se pregunta: «LA qué potencia puedo ponerlo a funcionar antes de que falle?» La prueba de resistencia ejecuta un sistema de forma que demande recursos en cantidad, frecuencia o volúmenes anormales. Por ejemplo: (1) diseñar pruebas especiales que generen diez interrupciones por segundo, cuando las normales son una o dos; (2) incrementar las frecuencias de datos de entrada en un orden de magnitud con el fin de comprobar cómo responden las funciones de entrada; ( 3 ) ejecutar casos de prueba que requieran el máximo de memoria o de otros recursos; (4) diseñar casos de prueba que puedan dar problemas en un sistema operativo virtual o (5) diseñar casos de prueba que produzcan excesivas búsquedas de datos residentes en disco. Esencialmente, el responsable de la prueba intenta romper el programa. Una variante de la prueba de resistencia es una técnica denominada prueba de sensibilidad. 4.2.7.4 RENDIMIENTO Para sistemas de tiempo real y sistemas empotrados, es inaceptable el software que proporciona las funciones requeridas pero no se ajusta a los requisitos de rendimiento. La prueba de rendimiento está diseñada para probar el rendimiento del software en tiempo de ejecución dentro del contexto de un sistema integrado. La prueba de rendimiento se da durante todos los pasos del proceso de la prueba. Incluso al nivel de unidad, se debe asegurar el rendimiento de los módulos individuales a medida que se llevan a cabo las pruebas de caja blanca. Sin embargo, hasta que no están completamente integrados todos los elementos del sistema no se puede asegurar realmente el rendimiento del sistema. Las pruebas de rendimiento, a menudo, van emparejadas con las pruebas de resistencia y, frecuentemente, requieren instrumentación tanto de software como de hardware. Es decir, muchas veces es necesario medir la utilización de recursos (por ejemplo, ciclos de procesador),de un modo exacto. La instrumentación externa puede monitorizar los intervalos de ejecución, los sucesos ocurridos (por ejemplo, interrupciones) y muestras de los estados de la máquina en un funcionamiento normal. Instrumentando un sistema, el encargado de la prueba puede descubrir situaciones que lleven a degradaciones y posibles fallos del sistema.
  • 57. 4.3 MANTENIMIENTO El mantenimiento constituye la última fase del ciclo de vida del software Una vez finalizado el desarrollo, el producto entra en la fase de operación y mantenimiento.El mantenimiento debe asegurar que el producto sigue satisfaciendo las expectativas del cliente Para facilitar el mantenimiento del producto es necesario un desarrollo de calidad Necesidad del mantenimiento El cambio es inevitable en la vida del software. Por ello, debemos desarrollar mecanismos de evaluación, control e implementación de modificaciones. 4.3.1 DEFINICION El mantenimiento del software es la totalidad de las actividades necesarias para proporcionar soporte económico (cost-effective) al sistema software. Estas actividades se desarrollan tanto antes como después de la entrega. Las actividades previas a la entrega incluyen la planificación de las operaciones posteriores a la entrega, planificación del soporte y determinación de la logística. Las actividades posteriores a la entrega incluyen la modificación del software, la formación de usuarios, y la operación de un help desk. Como se ve, hay una diferenciación en las diferentes definiciones entre actividades pre- y post- entrega del software. Para clarificar los conceptos, en esta obra diferenciaremos entre: actividades de mantenimiento propiamente dichas (posteriores a la entrega) y actividades de preparación para el mantenimiento. El criterio para diferenciarlo de otras actividades es el hecho de la entrega del producto software. Se debe tener en cuenta que en ocasiones esa entrega es un acto formal dentro de un contrato, pero en muchas otras es una simple decisión de disponibilidad pública de un grupo de desarrollo. Por ejemplo, en los proyectos de fuente abierto, desarrollados de manera voluntaria, el qué es una entrega lo determinan los propios desarrolladores cuando piensan que la funcionalidad implementada ha llegado a un determinado nivel.
  • 58. La guía SWEBOK2 considera que el mantenimiento ocurre durante todo el ciclo de vida, y coincide en su definición con la de Pigoski antes mencionada. Es importante resaltar que el concepto de mantenimiento del software difiere de la concepción de mantenimiento en otras disciplinas de ingeniería. Esto es debido a que el software no se “deteriora” con el uso. En la ingeniería mecánica, el mantenimiento consiste en las acciones de reparación necesarias para que la máquina o sistema mecánico siga funcionando. En la Ingeniería del Software, el mantenimiento tiene un significado más amplio, cubriendo su adaptación a necesidades. 4.3.2 TIPOS DE MANTENIMIENTO Mantenimiento preventivo: Cambiar el software para facilitar el futuro mantenimiento. Mantenimiento correctivo: Diagnosticar y corregir errores no localizados durante la prueba Mantenimiento perfectivo: Añadir nuevas funciones y modificar funciones existentes Mantenimiento adaptativo: Modificar el software para que interaccione con el entorno cambiante 4.3.2.1 PREVENTIVO Es una actividad programada de inspecciones, tanto de funcionamiento como de seguridad, ajustes, reparaciones, análisis, limpieza, lubricación, calibración, que deben llevarse a cabo en forma periódica en base a un plan establecido. El propósito es prever averías o desperfectos en su estado inicial y corregirlas para mantener la instalación en completa operación a los niveles y eficiencia óptimos. El mantenimiento preventivo permite detectar fallos repetitivos, disminuir los puntos muertos por paradas, aumentar la vida útil de equipos, disminuir costes de reparaciones, detectar puntos débiles en la instalación entre una larga lista de ventajas. Relativo a la informática, el mantenimiento preventivo consiste en la revisión periódica de ciertos aspectos, tanto de hardware como de software en un pc. Estos influyen en el desempeño fiable del sistema, en la integridad de los datos
  • 59. almacenados y en un intercambio de información correctos, a la máxima velocidad posible dentro de la configuración optima del sistema. Dentro del mantenimieto preventivo existe software que permite al usuario vigilar constantemente el estado de su equipo, asi como también realizar pequeños ajustes de una manera fácil. Además debemos agregar que el mantenimiento preventivo en general se ocupa en la determinación de condiciones operativas, de durabilidad y de confiabilidad de un equipo en mención este tipo de mantenimiento nos ayuda en reducir los tiempos que pueden generarse por mantenimiento correctivo. En lo referente al mantenimiento preventivo de un producto software, se diferencia del resto de tipos de mantenimiento (especialmente del mantenimiento perfectivo) en que, mientras que el resto (correctivo, evolutivo, perfectivo, adaptativo...) se produce generalmente tras una petición de cambio por parte del cliente o del usuario final, el preventivo se produce tras un estudio de posibilidades de mejora en los diferentes módulos del sistema. Aunque el mantenimiento preventivo es considerado valioso para las organizaciones, existen una serie de riesgos como fallos de la maquinaria o errores humanos a la hora de realizar estos procesos de mantenimiento. El mantenimiento preventivo planificado y la sustitución planificada son dos de las tres políticas disponibles para los ingenieros de mantenimiento. Algunos de los métodos más habituales para determinar que procesos de mantenimiento preventivo deben llevarse a cabo son las recomendaciones de los fabricantes, la legislación vigente, las recomendaciones de expertos y las acciones llevadas a cabo sobre activos similares. El primer objetivo del mantenimiento es evitar o mitigar las consecuencias de los fallos del equipo, logrando prevenir las incidencias antes de que estas ocurran. Las tareas de mantenimiento preventivo incluyen acciones como cambio de piezas desgastadas, cambios de aceites y lubricantes, etc. El mantenimiento preventivo debe evitar los fallos en el equipo antes de que estos ocurran. 4.3.2.2 CORRECTIVO Este mantenimiento también es denominado “mantenimiento reactivo”, tiene lugar luego que ocurre una falla o avería, es decir, solo actuará cuando se presenta un error en el sistema. En este caso si no se produce ninguna falla, el mantenimiento será nulo, por lo que se tendrá que esperar hasta que se presente el desperfecto
  • 60. para recién tomar medidas de corrección de errores. Este mantenimiento trae consigo las siguientes consecuencias: Paradas no previstas en el proceso productivo, disminuyendo las horas operativas. Afecta las cadenas productivas, es decir, que los ciclos productivos posteriores se verán parados a la espera de la corrección de la etapa anterior. Presenta costos por reparación y repuestos no presupuestados, por lo que se dará el caso que por falta de recursos económicos no se podrán comprar los repuestos en el momento deseado La planificación del tiempo que estará el sistema fuera de operación no es predecible. 4.3.2.3 PERFECTIVO Es la modificación de un producto software, después de su puesta en producción y para mejorar el rendimiento o la mantenibilidad, que es la facilidad de mantenimiento que tiene un software, es decir, la facilidad de un software para ser modificado, lo que influye directamente en los costes del mantenimiento. Estos cambios en las aplicaciones GesConFac y Web, serán debidos a cambios en la especificación del producto, bien sea porque el analista no captó la idea del producto de una forma concisa, bien porque el cliente no definió claramente los requerimientos deseables de las aplicaciones. En cuanto a cambios para mejorar el rendimiento de las aplicaciones, uno podría ser el que se ha especificado ya en el mantenimiento adaptativo y que también podría verse como perfectivo, y es el paso de la aplicación a un sistema en red. Otro cambio podría ser el referente a la inclusión de un monitor transaccional y su gestión, para mejorar los accesos a la base de datos, puesto que va a ser accedida concurrentemente por la aplicación comercial y por la Web, o la utilización de caches en el cliente para liberar la carga de la red de comunicaciones, etc. Otra mejora, respecto a la página Web que podría considerarse como parte de este tipo de mantenimiento, es la posibilidad de que un usuario pueda confeccionarse una cocina, o un baño a su gusto, es decir, la aplicación proporcionará una plantilla estándar de cocina o baño, y el usuario irá añadiendo a ella los complementos que considere oportunos, conociendo en todo momento su modelo creado y pudiendo modificarlo en caso de que no quede totalmente satisfecho con su elección.
  • 61. Si se habla de cambios por modificación de los requisitos de usuario o de las especificaciones funcionales, se puede citar el aumento del número de usuarios de las aplicaciones, lo que podría repercutir en el rendimiento del sistema, o el aumento de las funcionalidades, etc. 4.3.2.4 ADAPTATIVO Es aquel que se realiza sobre el sistema para adaptarlo a nuevas versiones de módulos externos, compatibilidad con nuevo hardware. Pese a que por norma general, la actualización de un componente externo traiga mejoras de rendimiento, estabilidad o funcionales, su actualización puede ser un gran problema que puede estar presente en forma de incompatibilidad parcial o total con el sistema de información. Cuando el software ya está en explotación, puede ocurrir que se produzca algún cambio en el software o el hardware del entorno en el que se ejecuta, este tipo de mantenimiento responde a esta situación.¡ Estos cambios pueden deberse a: Cambio en el sistema operativo. Cambio del tipo de arquitectura en la que se ejecuta (red local a Internet/Intranet). Entorno de desarrollo del software (nuevos elementos y herramientas como ODBC). Los cambios pueden ir desde un pequeño retoque a nivel de módulo hasta la casi reescritura de todo el código. Podemos realizar cambios en el entorno software a nivel de datos (migración de un sistema de ficheros a un sistema basado en bases de datos relacionales) o de procesos (pasar de una tecnología a otra, como una plataforma de desarrollo con componentes distribuidos). El mantenimiento adaptativo es cada vez más frecuente debido a la gran velocidad a la que está evolucionando el hardware, nuevos sistemas operativos (Linux), continuas actualizaciones de los existentes (actualizaciones de seguridad, Service Packs,…). Por termino general, la vida de un sistema software suele ser superior a la frecuencia de estos cambios, por lo que debe adaptarse.Cuando el software ya está en explotación, puede ocurrir que se produzca algún cambio en el software o el hardware del entorno en el que se ejecuta, este tipo de mantenimiento responde a esta situación.¡ Estos cambios pueden deberse a: Cambio en el sistema operativo. Cambio del tipo de arquitectura en la que se ejecuta (red local a Internet/Intranet).
  • 62. Entorno de desarrollo del software (nuevos elementos y herramientas como ODBC). Los cambios pueden ir desde un pequeño retoque a nivel de módulo hasta la casi reescritura de todo el código. Podemos realizar cambios en el entorno software a nivel de datos (migración de un sistema de ficheros a un sistema basado en bases de datos relacionales) o de procesos (pasar de una tecnología a otra, como una plataforma de desarrollo con componentes distribuidos). El mantenimiento adaptativo es cada vez más frecuente debido a la gran velocidad a la que está evolucionando el hardware, nuevos sistemas operativos (Linux), continuas actualizaciones de los existentes (actualizaciones de seguridad, Service Packs,…). Por termino general, la vida de un sistema software suele ser superior a la frecuencia de estos cambios, por lo que debe adaptarse. 4.3.3 COSTOS DEL MANTENIMIENTO Los costos de mantenimiento son muy difíciles de estimar con anticipación. La evidencia de los sistemas existentes muestra que los costos de mantenimiento son lo más cuantioso del desarrollo y uso del sistema. El precio del mantenimiento varía mucho de una aplicación a otra, pero en promedio, representan alrededor de cuatro veces los costos de desarrollo en grandes sistemas de software. Para obtener los costos de mantenimiento se utiliza el TCA (Tráfico de Cambio Anual), el cual es un porcentaje de instrucciones que sufre un cambio por adición o modificación. Además, se toma en cuenta el esfuerzo de desarrollo estimado o real por personas-mes para hallar el esfuerzo anual requerido para el mantenimiento de software. Se calcula de la siguiente manera: EMA = 1.0 * TCA * TDS EMA y TDS son el esfuerzo de mantenimiento anual y tiempo de desarrollo del software, y las unidades de cada uno son personas-mes (p.m.). Por lo tanto, nuestro proyecto necesita 17 personas-mes de esfuerzo de desarrollo y se estima que un 15% del código podría ser modificado en un año, el esfuerzo de mantenimiento básico sería: EMA = 1.0 * 0.15 * 17 = 2.55 p.m.
  • 63. Este resultado nos sirve para calcular una cifra más precisa. La estimación de costos de mantenimiento se puede refinar si se juzga la importancia de cada factor que afecta al costo, multiplicando el costo de mantenimiento básico por un multiplicador que se le asigna a cada factor. Se tomarán en cuenta los siguientes factores: Confiabilidad alta (1.1) Disponibilidad del personal de apoyo con experiencia en el lenguaje (.85) y aplicaciones alta (.90). Uso de prácticas modernas de programación alta (.85). Al aplicar estos factores como multiplicadores se obtiene lo siguiente: EMA = 2.55 * 1.10 * 0.85 * 0.90 * 0.80 = 1.71 p.m. Una vez que se obtiene el número de personas-mes para el mantenimiento, se busca el CMA (costo de mantenimiento), tomando en cuenta que se le pagan $5000 al mes a la persona encargada de mantenimiento: CMA = 1.71 * 5000 = 8550 4.3.4 EFECTOS SECUNDARIOS DEL MANTENIMIENTO Errores u otros comportamientos indeseables aparecidos como resultado de una modificación Se pueden limitar mediante una profunda documentación de diseño, una revisión de la configuración completa del software antes de lanzar la nueva versión y una cuidadosa prueba de regresión Categorías de efectos secundarios (Freedman y Weinberg, 1990) • Efectos secundarios sobre el código • Efectos secundarios sobre los datos • Efectos secundarios sobre la documentación La documentación del diseño y una cuidadosa prueba de regresión ayudan a eliminar errores, pero seguirán apareciendo efectos secundarios del mantenimiento.
  • 64. 4.3.4.1 SOBRE EL CODIGO un subprograma eliminado ó cambiado, eliminación ó modificación de una sentencia de etiqueta, eliminación ó modificación de un identificador, cambios para mejorar el rendimiento en ejecución, modificación de operadores lógicos, cambios sobre las pruebas de límites. 4.3.4.2 SOBRE LOS DATOS Es redefinición de constantes locales ó globales, redefinición de formatos de registros ó de archivos, aumento ó disminución del tamaño de arreglos ó de otras estructuras de datos de mayor orden, modificación de datos globales, reinicialización de indicadores de control ó de apuntadores, reorganización de argumentos de E/S ó de subprogramas. 4.3.4.3 SOBRE LA DOCUMENTACION siempre que se haga un cambio en el flujo de datos, arquitectura, procedimientos ó sistema, debe actualizarse la documentación técnica de soporte. UNIDAD V 5.1 PREPARACION DE LA PUESTA EN MARCHA
  • 65. Puesta en marcha Es en este punto cuando se pone en funcionamiento el nuevo sistema de la compañía. El usuario final ha completado su formación, los datos se han migrado del viejo al nuevo sistema y los usuarios comienzan a trabajar conforme a los procedimientos definidos. La solución adaptada al cliente es validada en su totalidad por el usuario final que prueba el sistema utilizando grandes volúmenes de información, para poder confirmar que se cumplen los objetivos definidos al comenzar el proyecto. Se corrobora junto al cliente que las expectativas se han alcanzado por completo. En el caso de que el cliente necesite instalaciones en distintas ubicaciones se lleva a cabo la puesta en marcha en una oficina piloto y, tras la evaluación, se traslada la experiencia al resto de oficinas, de acuerdo al plan de desarrollo. 5.1.1 PRUEBA DEL SISTEMA Antes de que pueda se usado el sistema de informacion debe ser probado. Durante este proceso se debe poner en practica todas las estrategias posibles para garantizar que el usuario inicial del sistema se encuentre libre de problemas. La implementacion es la ùltima fase del desarrollo de sistemas. Es el proceso de instalar equipos o software nuevo, como resultado de un anàlisis y diseño previo como resultado de la situaciòn o mejoramiento de la forma de llevar acabo un proceso automatizado. Al implementar un sistema lo primero que debemos hacer es asegurarnos què el sistema sea operacional o que funcione de acuerdo a los requerimientos del analisis y permitir que los usuarios puedan operarlos. Durante el proceso de implementación y prueba se deben poner en practica todas las estrategias posibles para garantizar que el usuario inicial del sistema se encuentre libre de problemas lo cual se puede describir durante este proceso t llevar acabo la correcciones. 1. Prueba de carga máxima 2. Prueba de procedimientos: Evaluar la claridad, validez, seguridad asi como su facilidad y sencillez de los manuales de procedimientos. 3. Prueba de recursos humanos: Se determinan como utilizar los usuarios el sistema al procesar datos o procesar informes. Implementación:
  • 66. Es la última fase del desarrollo de sistemas. Es el proceso de instalar equipos o software nuevo, como resultado de un análisis y diseño previo como resultado de la situación o mejoramiento de la forma de llevar acabo un proceso automatizado. Al implementar un sistema lo primero que debemos hacer es asegurarnos que el sistema sea operacional o que funcione de acuerdo a los requerimientos del análisis y permitir que los usuarios puedan operarlos. Existen varios enfoques de implementación: • Es darle responsabilidad a los grupos • Uso de diferentes estrategias para el enfrentamiento de usuarios. • El analista necesita formular medidas de desempeño con los cuales evalúa a los usuarios. La finalidad de las pruebas de implantación es doble: - Comprobar el funcionamiento correcto del mismo en el entorno de operación. - Permitir que el usuario determine, desde el punto de vista de operación, la aceptación del sistema instalado en su entorno real, según el cumplimiento de los requisitos especificados. Para ello, el responsable de implantación revisa el plan de pruebas de implantación y los criterios de aceptación del sistema, previamente elaborados. Las pruebas las realizan los técnicos de sistemas y de operación, que forman parte del grupo de usuarios técnicos que ha recibido la formación necesaria para llevarlas a cabo. Una vez ejecutadas estas pruebas, el equipo de usuarios técnicos informa de las incidencias detectadas al responsable de implantación, el cual analiza la información y toma la s medidas correctoras que considere necesarias para que el sistema dé respuesta a las especificaciones previstas, momento en el que el equipo de operación lo da por probado. 5.1.2 CAPACITACION DEL USUARIO Se define la formación necesaria para el equipo de trabajo responsable de la implantación y aceptación del sistema, estableciendo el esquema de formación para cada tipo de perfil dentro del equipo y la duración estimada de los cursos. Asimismo, se aseguran los recursos humanos, técnicos y materiales necesarios para realizar la formación al equipo de implantación.
  • 67. Por último, se convoca a las personas que deben asistir a los cursos de formación y se espera laconfirmación. Productos De entrada · Plan de Implantación (IAS 1.1) · Equipo de Implantación (IAS 1.2) De salida · Plan de Formación del Equipo de Implantación: Esquema de Formación Materiales de Formación Recursos de Formación Planificación de la Formación Participantes · Jefe de Proyecto · Responsable de Implantación · Directores de los Usuarios · Equipo de Formación 5.2 ESTRATEGIA PARA LA CONVERSION La estrategia de implantación del sistema se habrá determinado en la tarea Evaluación de las
  • 68. Alternativas y Selección (EVS 6.2) del proceso Estudio de Viabilidad del Sistema (EVS), en función de la envergadura del sistema, es decir el número de sistemas de información implicados en la implantación y la cobertura geográfica, cuyo alcance depende de las características y complejidad de los sistemas de información que conforman el sistema objeto de la implantación. Se revisan los requisitos de implantación (instalación, infraestructura, formación) establecidos en la tarea Especificación de Requisitos de Implantación (DSI 11.2) y los procedimientos implicados en la implantación, establecidos para cada uno de los sistemas de información en la tarea Especificación de Requisitos de Operación y Seguridad (DSI 1.7), con el fin de asegurar su adecuación a la estrategia global de implantación. Una vez analizada la información anterior, se define un plan de implantación que permita calcular adecuadamente el esfuerzo y los recursos necesarios para llevar a cabo con éxito la implantación. Dicho plan debe contemplar todas las tareas relacionadas con: - La formación necesaria para la implantación, tanto a usuarios finales como al equipo que se encarga de realizar las pruebas de implantación y aceptación del sistema. - La preparación de la infraestructura necesaria para la incorporación del sistema al entorno de operación. - La instalación de todos los componentes y procedimientos manuales y automáticos asociados a cada sistema de información implicado en la implantación. - La ejecución de los procedimientos de carga inicial y migración de datos, si se determinó su necesidad. - La realización de las pruebas de implantación y aceptación del sistema. - La formalización del plan de mantenimiento. 5.2.1 ETAPAS En esta actividad se revisa la estrategia de implantación para el sistema, establecida inicialmente en el proceso Estudio de Viabilidad del Sistema (EVS). Se identifican los distintos sistemas de información que forman parte del sistema
  • 69. objeto de la implantación. Para cada sistema se analizan las posibles dependencias con otros proyectos, que puedan condicionar el plan de implantación. Una vez estudiado el alcance y los condicionantes de la implantación, se decide si ésta se puede llevar a cabo. Será preciso establecer, en su caso, la estrategia que se concretará de forma definitiva en el plan de implantación. Se constituye el equipo de implantación, determinando los recursos humanos necesarios para la propia instalación del sistema, para las pruebas de implantación y aceptación, y para la preparación del mantenimiento. Se identifican, para cada uno de ellos, sus perfiles y niveles de responsabilidad. 5.2.2 MEDIOS En esta tarea se recopilan los productos de cada uno de los sistemas de información implicados en la implantación que van a ser objeto de mantenimiento. Se entregan a su responsable con el fin de implicarle más activamente en el dominio del sistema, para que una vez aceptado e implantado responda de forma satisfactoria a las peticiones de mantenimiento. El conjunto de productos a entregar dependerá del alcance y nivel de soporte que se haya establecido previamente para el mantenimiento del sistema. Una vez que el responsable de mantenimiento ha analizado en detalle la funcionalidad del sistema a implantar, valorará si la información disponible es suficiente para poder abordar en condiciones óptimas el futuro mantenimiento, asegurando que cuando el sistema se incorpore al entorno de producción todos los productos relacionados estén completos, actualizados y sean consistentes y precisos. La revisión de la configuración asegura que todos los elementos de la configuración del software son completos y comprensibles, garantizando el control de modificaciones futuras. Asimismo, aunque el entorno en que va a funcionar el sistema ya está predefinido, es necesario preparar el entorno en el que se va a realizar el mantenimiento identificando las necesidades de hardware y software adicional para acometer los cambios de una forma más ágil y segura. Por tanto, es necesario evaluar las herramientas disponibles en la organización para la gestión del mantenimiento y determinar su nivel de adecuación a las necesidades del nuevo sistema. Si las herramientas son insuficientes, o no están del todo integradas, se debe analizar y valorar qué herramientas de las existentes en el mercado son las más apropiadas, y seleccionar aquéllas que garanticen la integración entre los distintos productos objeto del mantenimiento.
  • 70. Es conveniente definir mecanismos para registrar y evaluar cada petición de mantenimiento, controlar y realizar los cambios y asegurar que se implementan adecuadamente. Finalmente, se recoge en el plan de mantenimiento toda la infraestructura necesaria para la gestión del futuro mantenimiento. Productos De entrada · Catálogo de Requisitos (DSI 11.2) De salida · Plan de Mantenimiento Prácticas · Diagrama de Representación · Sesiones de trabajo Participantes · Jefe de Proyecto 5.3 REVISION POSTERIOR A LA IMPLANTACION 5.3.1 IMPACTO DE LA APLICACIÓN Se evalúan los resultados de las pruebas, analizando las incidencias recibidas y comprobando que se han llevado a cabo todos los casos de pruebas establecidos en el plan de pruebas. Dicha evaluación consiste en: - Comparar los resultados obtenidos con los esperados.
  • 71. - Identificar el origen de cada problema para poder remitirlo a quién proceda y determinar qué acciones o medidas correctoras es preciso llevar a cabo para resolverlo de forma satisfactoria. - Indicar qué pruebas se debe volver a realizar, o si será necesario contemplar nuevos casos de prueba. Una vez realizadas las medidas correctoras necesarias, y comprobado que su comportamiento es adecuado, se documenta el resultado global de la evaluación de las pruebas de aceptación que incluye la aprobación del sistema por parte del usuario final. Productos De entrada · Plan de Pruebas (IAS 6.1) · Resultado de las Pruebas de Aceptación (IAS 6.2) De salida · Evaluación del Resultado de las Pruebas de Aceptación Participantes · Jefe de Proyecto · Directores de los Usuarios 5.3.2 METODOS PARA VALORAR EL IMPACTO DE LA APLICACION Se establece formalmente el plan de mantenimiento para el sistema, una vez que haya sido aceptado y se incorpore al entorno de producción. Se fija el tipo de mantenimiento que se va a asumir para cada sistema de información, determinando los criterios de regulación necesarios para cada tipo de mantenimiento contemplado y reflejando los requisitos de formación esenciales, de manera que se pueda responder satisfactoriamente a las peticiones de mantenimiento.
  • 72. Se estiman los recursos humanos necesarios para el servicio de mantenimiento establecido, definiendo claramente sus perfiles, asignando responsabilidades y determinando las funciones que van a llevar a cabo, con el fin de garantizar la coordinación en la gestión del mantenimiento. Productos De entrada · Plan de Mantenimiento (IAS 7.1) De salida · Plan de Mantenimiento Prácticas · Sesiones de trabajo Participantes · Responsable de Mantenimiento · Directores de los Usuarios