1. UNIVERSIDAD AUTONOMA DEL ESTADO DE HIDALGO
ESCUELA SUPERIOR HUEJUTLA
LIC. SISTEMAS COMPUTACIONALES
INGENIERIA DEL SOFTWARE
SISTEMAS 3 - 2
LIC.NOE ESPINOSA HERNÁNDEZ
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. 3.1.1 ANÁLISIS DE REQUERIMIENTOS
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.
4. 3.1.3 DESPLIEGUE DE LA FUNCIÓN DE CALIDAD
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.
5. 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:
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
sirve como una representación de los requerimientos. Los lenguajes de especificación formal
conducen a representaciones formales de los requerimientos que pueden ser
7. 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
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
8. 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.
(ii) recomendará una corrección en la especificación.
(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
*Análisis detallado de las alternativas seleccionadas.
11. ¿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.
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.
12. 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
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
13. 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.
*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.
14. 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.
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.
15. 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.
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.
16. 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
Á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)
17. 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
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).
18. 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.
Relación (interrelación): Se entiende por
relación a la asociación, vinculación o correspondencia entre entidades
EJEMPLO DE DAIGRAMA ENTIDAD-RELACION.
19. 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:
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:
20. 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
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.
21. 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
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
22. 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.
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.
23. 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.
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.
24. 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.
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.
DIRECTRICES PARA EL DISEÑO
3.7.5.1 DIRECTRICES INTERACCIÓN GENERAL
Consistencia de formato
Respuestas significativas
Verificación de acciones destructivas
25. 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
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,...
26. 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é
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.
27. 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
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
28. 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
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.
29. 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
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
30. 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
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%
36. ?
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%
%
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
37. 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.
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.
38. 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.
40. 4.2.2 OBJETIVOS DE LA PRUEBA
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.
41. 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
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
42. 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
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.
43. Los módulos del software se pueden probar independientemente
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.
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.
44. 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.
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.
47. 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.
49. 4.2.4.2 INTEGRACION DESCENDENTE
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.
