Este documento trata sobre el análisis de sistemas de software. Explica conceptos como la estimación de proyectos, los objetivos de la planificación, el análisis de requisitos, técnicas para facilitar la especificación de aplicaciones, y principios del análisis como el dominio de la información y el modelado. También cubre temas como la partición, la especificación y los principios de la especificación. El documento proporciona una guía sobre los procesos y técnicas empleadas en el análisis y des

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