Arquitectura de Software - Conceptos

UNIVERSIDAD SAN PEDRO
Facultad de Ingeniera
Escuela de Ingeniera Informtica y Sistemas
Arquitectura de Software
Asignatura: Ingeniera de Software II
Docente: Jaime Omar Meca Rosales
Alumno: Gonzales Domador I Arturo
Sullana - 2017
INGENIERIA DE SOFTWARE II UNIVERSIDAD SAN PEDRO
Pgina|2
El Diseo no es solo lo que ves, sino como funciona

Steve Jobs
Pgina|3
INDICE
1. ARQUITECTURAS DE SOFTWARE
DESCOMPOSICIN MODULAR 5
ARQUITECTURA DE DOMINIO ESPECFICO 8
DISEO DE SOFTWARE DE ARQUITECTURA MULTIPROCESADOR 8
DISEO DE SOFTWARE DE ARQUITECTURA CLIENTE SERVIDOR 10
DISEO DE SOFTWARE DE ARQUITECTURA DISTRIBUIDA 12
DISEO DE SOFTWARE DE ARQUITECTURA DE TIEMPO REAL 14
2. VERIFICACIN, VALIDACIN Y PRUEBAS DEL SOFTWARE
VERIFICACIN Y VALIDACIN DEL SOFTWARE 15
DISEO DE CASOS DE PRUEBA 16
PRUEBAS DE CAJA NEGRA Y CAJA BLANCA 17
PRUEBA DE UNIDAD Y DE INTEGRACIN 18
3. MTRICAS DEL SOFTWARE
MTRICAS DEL PRODUCTO 19
MTRICAS DEL PROCESO Y PROYECTO 21
MTRICAS ORIENTADAS AL TAMAO Y A LA FUNCIN 23
4. GESTIN DE LA CALIDAD DEL SOFTWARE
CONCEPTOS GENERALES. 24
ASEGURAMIENTO DE LA CALIDAD 24
PLANEAMIENTO DE LA CALIDAD 26
ATRIBUTOS DEL SOFTWARE 26
5. GESTIN DE LA CONFIGURACIN DEL SOFTWARE
ELEMENTOS DE LA CONFIGURACIN DEL SOFTWARE 27
EL PROCESO DE GESTIN DE LA CONFIGURACIN DEL SOFTWARE 28
6. EXPOSICIN DEL PROYECTO SOFTWARE
PROTOTIPO FUNCIONAL 28
MANUALES DEL SISTEMA 29
7. REFERENCIAS 32
Pgina|4
1. ARQUITECTURAS DE SOFTWARE
1.1 DESCOMPOSICIN MODULAR
Es un mtodo de diseo que proporciona un mecanismo sistemtico para descomponer el

problema en subproblemas, reducir la complejidad de todo el problema consiguiendo de esta
manera una solucin modular efectiva. Descomposicin modular es decir la modularidad, se
refiere al software cuando se divide en componentes nombrados y abordados por separado, se
integran para satisfacer los requisitos del problema.
El diseo modular propone dividir el sistema en partes diferenciadas y definir sus interfaces.
Cuyas ventajas son: Claridad, reduccin de costos y reutilizacin. Se ha afirmado que la
modularidad es el nico atributo del software que permite gestionar un programa
intelectualmente.
CRITERIOS
Evala un mtodo de diseo en relacin con la habilidad de definir un sistema modular efectivo:
1. Capacidad de descomposicin modular. Si un mtodo de diseo proporciona un

mecanismo sistemtico para descomponer el problema en subproblemas, reducir la
complejidad de todo el problema, consiguiendo de esta manera una solucin modular
efectiva.
2. Capacidad de empleo de componentes modulares. Si un mtodo de diseo permite
ensamblar los componentes de diseo existentes en un sistema nuevo, producir una
solucin modular que no inventa nada ya inventado.
3. Capacidad de comprensin modular. Si un mdulo se puede comprender como una
unidad autnoma ser ms fcil de construir y de cambiar.
4. Continuidad modular. Si pequeos cambios en los requisitos del sistema provocan
cambios en los mdulos individuales, en vez de cambios generalizados en el sistema, se
minimizar el impacto de los efectos secundarios de los cambios.
5. Proteccin modular. Si dentro de un mdulo se produce una condicin aberrante y sus
efectos se limitan a ese mdulo, se minimizar el impacto de los efectos secundarios
inducidos por los errores.
Pgina|5
PASOS
1. Identificar los mdulos

2. Describir cada mdulo
3. Describir las relaciones entre mdulos
Despus de elegir la organizacin del sistema en su totalidad, debemos decir como

descomponer los subsistemas en mdulos. No existe una distincin rgida entre la organizacin
del sistema y la descomposicin modular. Sin embargo, los componentes de los mdulos son
normalmente ms pequeos, lo que permite usar estilos alternativos de descomposicin.
CUALIDADES
Una descomposicin modular debe poseer ciertas cualidades mnimas para que se pueda
considerar suficiente validad.
1. Independencia funcional
Al final de los documentos debe haber una matriz REQUISITOS/COMPONENTES. En

principio, cada funcin ser realizada en un mdulo distinto. Si las funciones son
independientes los mdulos tendrn independencia funcional. Cada mdulo debe
realizar una funcin concreta o un conjunto de funciones afines. Es recomendable
reducir las relaciones entre mdulos al mnimo. Para medir la independencia funcional
hay dos criterios: acoplamiento y cohesin.
2. Acoplamiento
Mide la interrelacin entre dos mdulos, segn el tipo de conexin y la complejidad de

la interface:
Fuerte por contenido, cuando desde un mdulo se pueden cambiar datos locales
de otro comn, se emplea una zona comn de datos a la que tienen acceso varios
mdulos.
Moderado de control, la zona comn es un dispositivo externo al que estn ligados
los mdulos, esto implica que un cambio en el formato de datos afecta a todos
estos mdulos.
Por etiqueta, en intercambio de datos se realiza mediante una referencia a la
estructura completa de datos (vector, pila, rbol, grafo, etc.).
Dbil de datos, viene dado por los datos que intercambian los mdulos. es el mejor
posible.
Sin acoplamiento directo, es el acoplamiento que no existe.
3. Cohesin
Es necesario lograr que el contenido de cada mdulo tenga la mxima coherencia. Para
que el n de mdulos no sea demasiado elevado y complique el diseo se tratan de
agrupar elementos afines y relacionados en un mismo mdulo.
ALTA COHESIN ABSTRACCIONAL, se logra cuando se disea el mdulo como tipo

abstracto de datos o como una clase de objetos.
COHESIN FUNCIONAL, el mdulo realiza una funcin concreta y especfica.
Pgina|6
MEDIA COHESIN SECUENCIAL, los elementos del mdulo trabajan de forma

secuencial.
COHESIN DE COMUNICACIN, elementos que operan con el mismo conjunto de
datos de entrada o de salida.
COHESIN TEMPORAL, se agrupan elementos que se ejecutan en el mismo
momento. Ej. Arrancar o parar dispositivos.
BAJA COHESIN LGICA, se agrupan elementos que realizan funciones similares. Ej.:
mdulos de E/S o de tratamiento de errores.
COHESIN COINCIDENTAL, es la peor y se produce cuando los elementos de un
mdulo no guardan relacin alguna.
La descripcin del comportamiento de un mdulo permite establecer el grado de

cohesin:
Si es una frase compuesta y contiene ms de un verbo la cohesin ser media.

Si contiene expresiones secuenciales (primero, entonces, cuando), ser temporal
o secuencial.
Si la descripcin no se refiere a algo especfico (Ej. Todos los errores), cohesin
lgica.
Si aparece inicializar, preparar, configurar, probablemente sea temporal.
4. Comprensibilidad
Para facilitar los cambios, el mantenimiento y la reutilizacin de mdulos es necesario

que cada uno sea comprensible de forma aislada. Para ello es bueno que posea
independencia funcional, pero adems es deseable:
IDENTIFICACIN, el nombre debe ser adecuado y descriptivo.

DOCUMENTACIN, debe aclarar todos los detalles de diseo e implementacin que
no queden de manifiesto en el propio cdigo.
SIMPLICIDAD, las soluciones sencillas son siempre las mejores.
5. Adaptabilidad
La adaptacin de un sistema resulta ms difcil cuando no hay independencia

funcional, es decir, con alto acoplamiento y baja cohesin, y cuando el diseo es poco
comprensible. Otros factores para facilitar la adaptabilidad:
PREVISIN, es necesario prever que aspectos del sistema pueden ser susceptibles de
cambios en el futuro, y poner estos elementos en mdulos independientes, de manera
que su modificacin afecte al menor nmero de mdulos posible.
ACCESIBILIDAD, debe resultar sencillo el acceso a los documentos de especificacin,

diseo, e implementacin para obtener un conocimiento suficiente del sistema antes
de proceder a su adaptacin.
CONSISTENCIA, despus de cualquier adaptacin se debe mantener la consistencia del

sistema, incluidos los documentos afectados.
Pgina|7
1.2. ARQUITECTURA DE DOMINIO ESPECFICO
Uno de los retos principales en la arquitectura de software es disear software y hardware que
pueda funcionar en sistemas distribuidos, resolviendo los problemas que se pudieran presentar
en el manejo de estos sistemas. Es importante comprender las ventajas y desventajas que
ofrecen las diferentes arquitecturas de sistemas distribuidos para que sean consideradas al
momento de realizar el diseo.
MODELOS
1. Modelos genricos: Son abstracciones obtenidas a partir de varios sistemas reales. En

capsulan las caractersticas principales de estos sistemas. Por ejemplo, en sistemas de
tiempo real, podra haber modelos arquitectnicos genricos de diferentes tipos de
sistemas tales como sistemas de recoleccin de datos o sistemas de monitorizacin.
Se estudian varios modelos genricos.
2. Modelos de referencia: Son ms abstractos y describen una clase ms amplia de
sistemas. Constituyen un modo de informar a los diseadores sobre la estructura
general de esta clase de sistemas. Los modelos de referencia normalmente se obtienen
a partir de un estudio del dominio de la aplicacin
1.3. DISEO DE SOFTWARE DE ARQUITECTURA MULTIPROCESADOR
Un sistema multiproceso o multitarea es aquel que permite ejecutar varios procesos de forma
concurrente, un multiprocesador es aquel que cuenta con dos o ms microprocesadores. La
razn es porque actualmente la mayora de las CPUs slo pueden ejecutar un proceso cada vez.
La nica forma de que se ejecuten de forma simultnea varios procesos es tener varias CPUs,
ya sea en una mquina o en varias, en un sistema distribuido.
La ventaja de un sistema multiproceso reside en la operacin llamada cambio de contexto. Esta

operacin consiste en quitar a un proceso de la CPU, ejecutar otro proceso y volver a colocar el
primero sin que se entere de nada. Los hilos que se ejecutan comparten ciertos recursos como
el espacio del mensaje, la cual permite simplificar el diseo de una aplicacin que debe llevar a
cabo distintas funciones simultneamente. El multiproceso no es algo difcil de entender: ms
procesadores significa ms potencia computacional.
Pgina|8
Un conjunto de tareas puede ser completado ms rpidamente si hay varias unidades de

proceso ejecutndolas en paralelo. Esa es la teora, pero otra historia es la prctica, como hacer
funcionar el multiproceso, lo que requiere unos profundos conocimientos tanto del hardware
como del software. Es necesario conocer ampliamente como estn interconectados dichos
procesadores, y la forma en que el cdigo que se ejecuta en los mismos ha sido escrito para
escribir aplicaciones y software que aproveche al mximo sus prestaciones.
A pesar de las grandes mejoras acaecidas en monoprocesadores para algunas aplicaciones no es

suficiente. La solucin pueden ser los sistemas multiprocesadores debido a que es la solucin
ms sencilla, natural y con mejor coste-prestaciones. Adems, las mejoras en
microprocesadores cada vez ms son complejas; cada avance implica crecer en complejidad,
potencia y superficie; quizs se lenta pro es una clara mejora en el software, que permite
explotar el paralelismo.
Existen dos factores claves para la extensin de multiprocesadores:
Flexibilidad: El mismo sistema puede usarse para un nico usuario incrementado el

rendimiento en la ejecucin de una nica aplicacin o para varios usuarios y aplicaciones
en un entorno compartido.
Coste-rendimiento: Actualmente estos sistemas se basan en procesadores comerciales,
por lo que su coste se ha reducido drsticamente.
El multiproceso no es ms que un conjunto de tareas que pueden ser completadas rpidamente

si hay varias unidades de proceso ejecutndolas. Para el desarrollo de estos procesos se ocupan
modelos de programacin concurrente y paralela:
Los objetivos de la programacin paralela, son:
Reducir el tiempo de cmputo.

Reducir la complejidad del algoritmo,
Aprovechar al mximo la capacidad de las computadoras multiproceso.
Pgina|9
1.4. DISEO DE SOFTWARE DE ARQUITECTURA CLIENTE-SERVIDOR
Diseo de software de arquitectura cliente - servidor es un modelo de sistema en el que dicho

sistema se organiza como un conjunto de servicios y servidores asociados, ms los clientes que
acceden y usan los servicios. Desde el punto de vista funcional, se puede definir la computacin
Cliente/Servidor como una arquitectura distribuida que permite a los usuarios finales obtener
acceso a la informacin en forma transparente an en entornos multiplataforma.
En el modelo cliente servidor, el cliente enva un mensaje solicitando un determinado servicio a

un servidor (hace una peticin), y este enva uno o varios mensajes con la respuesta (provee el
servicio). En un sistema distribuido cada mquina puede cumplir el rol de servidor para algunas
tareas y el rol de cliente para otras. La idea es tratar a una computadora como un instrumento,
que por s sola pueda realizar muchas tareas, pero con la consideracin de que realice aquellas
que son ms adecuadas a sus caractersticas. Si esto se aplica tanto a clientes como servidores
se entiende que la forma ms estndar de aplicacin y uso de sistemas Cliente/Servidor es
mediante la explotacin de las PCs a travs de interfaces grficas de usuario; mientras que la
administracin de datos y su seguridad e integridad se deja a cargo de computadoras centrales
tipo mainframe.
Usualmente la mayora del trabajo pesado se hace en el proceso llamado servidor y el o los
procesos cliente slo se ocupan de la interaccin con el usuario (aunque esto puede variar). En
otras palabras la arquitectura Cliente/Servidor es una extensin de programacin modular en la
que la base fundamental es separar una gran pieza de software en mdulos con el fin de hacer
ms fcil el desarrollo y mejorar su mantenimiento.
Principales componentes del modelo son:
1. Un conjunto de servidores que ofrecen a otros subsistemas.
SERVIDOR
Es el proceso encargado de atender a mltiples clientes que hacen peticiones de algn recurso
administrado por l. Al proceso servidor se le conoce con el trmino back-end. Normalmente
maneja todas las funciones relacionadas con la mayora de las reglas del negocio y los recursos
de datos. Las funciones que lleva a cabo el proceso servidor se resumen en los siguientes puntos:
Aceptar los requerimientos de bases de datos que hacen los clientes.

Procesar requerimientos de bases de datos.
Formatear datos para trasmitirlos a los clientes
Procesar la lgica de la aplicacin y realizar validaciones a nivel de bases de datos.
P g i n a | 10
2. Un conjunto de cliente que llaman a los servicios ofrecidos por los servidores. Puede tener
varias instancias de un programa cliente ejecutndose concurrentemente.
CLIENTE
El cliente es el proceso que permite al usuario formular los requerimientos y pasarlos al servidor,
se le conoce con el trmino front-end. Normalmente maneja todas las funciones relacionadas
con la manipulacin y despliegue de datos, por lo que estn desarrollados sobre plataformas
que permiten construir interfaces grficas de usuario (GUI), adems de acceder a los servicios
distribuidos en cualquier parte de una red. Las funciones que lleva a cabo el proceso cliente se
resumen en los siguientes puntos:
Administrar la interfaz de usuario.

Interactuar con el usuario.
Procesar la lgica de la aplicacin y hacer validaciones locales.
Generar requerimientos de bases de datos.
Recibir resultados del servidor.
Formatear resultados.
3. Una red que permite a los clientes acceder a estos servicios.
CARACTERISTICAS
Las caractersticas bsicas de una arquitectura Cliente/Servidor son:
Combinacin de un cliente que interacta con el usuario, y un servidor que interacta

con los recursos compartidos. El proceso del cliente proporciona la interfaz entre el
usuario y el resto del sistema. El proceso del servidor acta como un motor de software
que maneja recursos compartidos tales como bases de datos, impresoras, mdems, etc.
Las tareas del cliente y del servidor tienen diferentes requerimientos en cuanto a
recursos de cmputo como velocidad del procesador, memoria, velocidad y capacidades
del disco e input-output devices.
Se establece una relacin entre procesos distintos, los cuales pueden ser ejecutados en la misma
mquina o en mquinas diferentes distribuidas a lo largo de la red.
Existe una clara distincin de funciones basada en el concepto de servicio, que se

establece entre clientes y servidores.
La relacin establecida puede ser de muchos a uno, en la que un servidor puede dar
servicio a muchos clientes, regulando su acceso a recursos compartidos.
Los clientes corresponden a procesos activos en cuanto a que son stos los que hacen
peticiones de servicios a los servidores. Estos ltimos tienen un carcter pasivo ya que
esperan las peticiones de los clientes.
P g i n a | 11
No existe otra relacin entre clientes y servidores que no sea la que se establece a travs
del intercambio de mensajes entre ambos. El mensaje es el mecanismo para la peticin
y entrega de solicitudes de servicio.
El ambiente es heterogneo. La plataforma de hardware y el sistema operativo del
cliente y del servidor no son siempre la misma. Precisamente una de las principales
ventajas de esta arquitectura es la posibilidad de conectar clientes y servidores
independientemente de sus plataformas.
El concepto de escalabilidad tanto horizontal como vertical es aplicable a cualquier
sistema Cliente/Servidor. La escalabilidad horizontal permite agregar ms estaciones de
trabajo activas sin afectar significativamente el rendimiento. La escalabilidad vertical
permite mejorar las caractersticas del servidor o agregar mltiples servidores.
1.5. DISEO DE SOFTWARE DE ARQUITECTURA DISTRIBUIDA
Los sistemas distribuidos son sistemas de informacin en los cuales las funciones se reparten
por reas de trabajo diferentes que trabajan de forma coordinada para asumir los objetivos que
la organizacin asigna a ese sistema de informacin.
Sistemas cuyos componentes hardware y software, que estn en ordenadores conectados en

red, se comunican y coordinan sus acciones mediante el pase de mensajes, para el logro de un
objetivo. Se establece la comunicacin mediante un protocolo prefijado por un esquema cliente-
servidor.
Un sistema distribuido es una coleccin de computadoras independientes que aparecen ante

los usuarios del sistema como una nica computadora (Tanenbaum, 1996).
ASPECTOS
Hardware: Las mquinas son autnomas.

Software: Los usuarios piensan que el sistema es como una nica computadora.
VENTAJAS
Comparacin de recursos: Permite compartir recursos hardware y software como discos

duros, impresoras, fichero y compiladores asociadas en una red.
Apertura: Se puede disear sobre protocolos estndar que permiten combinar
equipamiento y software de diferentes vendedores.
Concurrencia: Se puede operar procesos al mismo tiempo sobre diferentes
computadoras de la red, estos procesos pueden comunicarse con otros durante su
funcionamiento normal.
Escalabilidad: Los sistemas distribuidos son escalables en tanto que la capacidad del
sistema puede incrementarse aadiendo nuevos recursos para cubrir nuevas demandas
sobre el sistema.
Tolerancia a defecto: La disponibilidad de varias computadoras y el potencial para
reproducir informacin significa que los sistemas distribuidos pueden ser tolerantes a
algunos fallos de funcionamiento del hardware y del software.
DESVENTAJAS
Complejidad: Los sistemas distribuidos son ms complejos que los sistemas

centralizados. Hace ms difcil comprender sus propiedades emergentes y probar estos
sistemas.
P g i n a | 12
Seguridad: Puede acceder al sistema desde varias computadoras diferentes, y al trfico

en la red puede estar sujeto a escuchas indeseadas. Esto hace ms difcil el asegurar la
integridad de los datos en el sistema se mantenga y lo servicios del sistema no se
degrade por ataques de denegacin de servicio.
Manejabilidad: Las computadoras en un sistema pueden ser diferentes tipos y pueden
ejecutar versiones diferentes de sistemas operativos. Los defectos en una mquina
pueden propagarse a otras mquinas con consecuencia inesperada requiriendo ms
esfuerzo para gestionar y mantener el funcionamiento del sistema.
Impredecibilidad: La respuesta sistema distribuido depende mucho de la respuesta de
la red y la organizacin. El tiempo requerido a las respuestas de la peticin del usuario
puede variar drsticamente de una a otra.
TIPOS GENERICOS
Arquitectura cliente servidor: El sistema puede ser visto como un conjunto de

servicios que se proporcionan a los clientes que hacen uso de dichos servicios. Los
servidores y los clientes se tratan de forma diferente en estos sistemas.
Arquitectura de objetos distribuidos: No existe distincin entre servidores y clientes, el
sistema pude ser vistos como un conjunto de objetos que interaccionan cuya
localizacin es irrelevante. No hay distincin entre un proveedor de servicios y el usuario
de estos servicios.
PRINCIPIOS DE DISEO
Correspondencia del volumen de transmisin con los medios de transmisin: para un

trfico denso de datos en un sistema distribuido se deberan utilizar medios de
transmisin rpidos
Mantenimiento de los Datos ms usados en un almacenamiento Rpido: examinar los
patrones de datos en un sistema y asegurar que los datos a los que se accede
frecuentemente se guarden en algn medio de almacenamiento rpido.
Mantenimiento de los datos cerca de donde se utilizan: intenta reducir el tiempo que
pasan los datos en medios lentos de transmisin.
Utilizacin de la duplicacin de datos todo lo posible: consiste en mantener mltiples
copias de datos en un sistema al mismo tiempo. Existen muchas razones para la
duplicacin de datos las dos principales son:
o Es que hay que asegurar la redundancia que permite que un sistema distribuido
contine funcionando aun cuando una computadora con datos importantes
quede fuera de servicio normalmente por un mal funcionamiento del hardware.
o Es que proporciona una forma de implementar el principio dilucidado en la
seccin anterior, el de asegurar que los datos estn ubicados cerca de donde se
utilizan.
Eliminar cuellos de botella: manipular cuellos de botella es compartir la carga de
procesamiento entre los servidores, normalmente servidores fsicamente cerca del que
est sobrecargado.
Diseo para el fallo: analizar los fallos que podran aparecer en un sistema distribuido y
disear el sistema con suficiente redundancia como para que dicho fallo no afecte
seriamente y, en el mejor de los casos, que se pueda reducir el tiempo de respuesta de
ciertas transacciones.
P g i n a | 13
Minimizar la latencia: Cuando los datos fluyen de una computadora a otra en un

sistema distribuido a menudo tiene que atravesar otras computadoras. Algunas de estas
computadoras puede que ya tengan unos datos que expidan funcionalidad; es posible
que otras procesen los datos de alguna manera. El tiempo que tardan las computadoras
es lo que se conoce como latencia. Un buen diseo de sistema distribuido es el que
minimiza el nmero de computadoras intermediarias.
Una estrategia puede militar contra otra, minimizar la latencia y duplicar bases de datos pueden
ser dos estrategias opuestas: incrementar el nmero de bases de datos duplicadas incrementa
la latencia de un sistema; como consecuencia, el diseo de sistemas distribuidos, ms que otra
cosa, es un arte.
1.6. DISEO DE SOFTWARE DE ARQUITECTURA DE TIEMPO REAL
Los sistemas de tiempo real deben responder a eventos que tienen lugar a intervalos irregulares.
Estos eventos a menudo hacen que el sistema cambie a un estado diferente. El modelado de
mquina de estado se utiliza a menudo para modelar sistemas de tiempo real. Los modelos de
mquina de estados son una buena aproximacin independiente del lenguaje de representar el
diseo de un sistema de tiempo real, son una parte integral de los mtodos de diseo de
sistemas de tiempo real. Una forma de ver un sistema en tiempo real es como un sistema de
estimo/respuesta. Dado un estmulo de entrada, el sistema debe producir la correspondiente
salida. Se puede, por lo tanto, definir el comportamiento de un sistema de tiempo real haciendo
una lista de estmulos recibidos por el sistema, las respuestas asociadas y el tiempo real en que
dicha respuestas deben producirse.
ESTIMULOS
Estmulos peridicos. Ocurren a intervalos de tiempos predecibles .por ejemplo, el

sistema debe de tener un sensor cada 50 mili segundos y realizar una accin respuesta)
dependiendo del valor de ese sensor (estimulo).
Estmulos aperidicos. Ocurren de forma irregular. Normalmente son provocados
utilizando el mecanismo de interrupciones de la computadora. Un ejemplo de dicho
estimo podra ser una interrupcin para indicar que una trasferencia de E/S sea
completado y que los datos estn disponibles en un buffer.
Por consiguiente los sistemas de tiempo real se disean como un conjunto de procesos
concurrentes que cooperan entre s con el objeto de soportar la gestin de estos procesos, la
plataforma de ejecucin para la mayora de los sistemas de tiempo real incluye un sistema
operativo en tiempo real.
La generalizacin de este estimulo-repuesta de un sistema de tiempo real conduce a un modelo

arquitectnico genrico abstracto en el que hay tres tipos de procesos:
Procesos de computacionales: calculan la respuesta requerida para el estmulo recibido

del sistema
Procesos de control de actuadores: controlan el funcionamiento del actuador. Este
modelo permite recoger rpidamente los datos desde el sensor (antes de la siguiente
entrada est disponible) y permiten que su procesamiento y la respuesta asociada al
actuador se realicen ms tarde.
P g i n a | 14
2. VERIFICACION Y VALIDACION Y PRUEBAS DEL SOFTWARE

2.1 VERIFICACION Y VALIDACION DEL SOFTWARE
Durante y despus del proceso de implementacin, el programa que se est desarrollando debe
ser comprobado para asegurar que satisface su especificacin y entrega la funcionalidad
esperada por las personas que pagan por el software. A estos procesos de anlisis y prueba se
les conoce como Verificacin y Validacin del software.
La verificacin y la validacin no son la misma cosa, aunque es muy fcil confundirlas.
VERIFICACION:
El papel de la verificacin comprende comprobar que el software est de acuerdo con

su especificacin. Se comprueba que el sistema cumple los requerimientos funcionales
y no funcionales que se le han especificado.
Estamos construyendo el producto correctamente?
VALIDACION:
La validacin es un proceso ms general. Se debe asegurar que el software cumple las

expectativas del cliente. Va ms all de comprobar si el sistema est acorde con su
especificacin, para probar que el software hace lo que el usuario espera a diferencia de
lo que se ha especificado
Estamos construyendo el producto concreto?
Dentro del proceso de Verificacin y validacin se utilizan dos tcnicas de comprobacin y

anlisis de sistemas:
Inspecciones del software:
Se analizan las diferentes representaciones del sistema (diagramas de requerimientos,

diagramas de diseo y cdigo fuente) en bsqueda de defectos.
Son tcnicas de validacin estticas => No requieren que el cdigo se ejecute.
Debe realizarse durante todo el ciclo de desarrollo.
P g i n a | 15
Las pruebas del software:
Se contrasta dinmicamente la respuesta de prototipos ejecutables del sistema con el

comportamiento operacional esperado.
Tcnicas de validacin dinmicas => El sistema se ejecuta.
Requiere disponer de prototipo ejecutables, por lo que slo pueden utilizarse en ciertas
fases del proceso.
En el esquema se muestra el lugar que ocupan las inspecciones y las pruebas dentro del
proceso de desarrollo de software. Las flechas indican las fases del proceso en las que
se utilizan las tcnicas. Las inspecciones de software se pueden utilizar en todas las
etapas del proceso, mientras que las tcnicas de prueba slo se pueden cuando est
disponible un prototipo o cdigo ejecutable
2.2 DISEO DE CASO DE PRUEBA:
Un caso de prueba es un conjunto de entradas, condiciones de ejecucin y resultados esperados,

desarrollando para conseguir un objetivo particular o condicin de prueba.
En la ingeniera de software, mediante el caso de prueba o test case el analista determina, si una
aplicacin o una caracterstica de esta es parcial completamente satisfactoria.
Para llevar a cabo un caso de prueba es necesario definir los siguientes pasos:
Definir escenarios.
Identificar condiciones de entrada.
Definir clases de equivalencia.
Realizar casos de prueba.
P g i n a | 16
2.3 PRUEBAS DE CAJA NEGRA Y BLANCA
2.3.1 PRUEBAS DE CAJA NEGRA:
Se centran en los requisitos funcionales del software. Permite al ingeniero del software
obtener conjuntos de condiciones de entrada, es decir consideran la funcin para la cual
fue creado el producto. Se llevan a cabo sobre la interfaz del sistema reduciendo el
nmero de casos de prueba mediante la eleccin de entradas y salidas vlidas y no
vlidas que ejercitan toda la funcionalidad del sistema.
La prueba de caja negra intenta encontrar errores de las siguientes categoras:
Funciones incorrectas o ausentes.

Errores de interfaz.
Errores en estructuras de datos o en accesos a bases de datos externas.
Errores de rendimiento.
Errores de inicializacin y de terminacin.
2.3.2 PRUEBAS DE CAJA BLANCA:
La prueba de caja blanca denominada a veces prueba de caja de cristal es un mtodo de

diseo de casos de prueba que usa la estructura de control del diseo procedimental
para obtener los casos de prueba. Mediante los mtodos de prueba de caja blanca, el
ingeniero del software puede obtener casos de prueba que:
1. Garanticen que se ejercita por lo menos una vez todos los caminos
independientes de cada mdulo.
2. Ejerciten todas las decisiones lgicas en sus vertientes verdadera y falsa.
3. Ejecuten todos los bucles en sus lmites y con sus lmites operacionales.
4. Ejerciten las estructuras internas de datos para asegurar su validez.
P g i n a | 17
2.4 PRUEBA DE UNIDAD Y DE INTEGRACION
2.4.1 PRUEBA DE UNIDAD:
La prueba de unidad centra el proceso de verificacin en la menor unidad del diseo del
software: el mdulo. Usando la descripcin del diseo procedimental como gua, se
prueban los caminos de control importantes, con el fin de descubrir errores dentro del
lmite del mdulo. La prueba de unidad est orientada a caja blanca y este paso se puede
llevar a cabo en paralelo para mltiples mdulos.
2.4.2 PRUEBAS DE INTEGRACION:
Se prueban la respuesta de grupos de mdulos interconectados a fin de detectar fallos

resultantes de la interaccin entre los componentes. Las pruebas de integracin se
realizan con referencia a las especificaciones del programa. La principal dificultad de las
pruebas de integracin es la localizacin de los fallos. Para facilitar la deteccin de los
errores se utilizan tcnicas incrementales. Existen principalmente dos tipos de
integracin:
P g i n a | 18
2.4.2.1 La integracin incremental consiste en combinar el conjunto de

mdulos ya probados (al principio ser un conjunto vaco) con los siguientes
mdulos a probar. Luego se va incrementando progresivamente el nmero de
mdulos unidos hasta que se forma el sistema completo.
2.4.2.2 En la integracin no incremental o Big Bang se combinan todos los

mdulos de una vez. Son pruebas con un enfoque incremental de pruebas de
integracin donde el componente en el nivel ms alto en la jerarqua es probado
en primer lugar, con los componentes del nivel inferior siendo simulados
mediante stubs. A continuacin, los componentes probados son utilizados para
probar los componentes del nivel inferior. El proceso se repite hasta que el nivel
ms bajo haya sido probado.
3. METRICAS DEL SOFTWARE

En el campo de la ingeniera del software una mtrica es cualquier medida o conjunto de
medidas destinadas a conocer o estimar el tamao u otra caracterstica de un software o un
sistema de informacin, generalmente para realizar comparativas o para la planificacin de
proyectos de desarrollo.
3.1 METRICAS DEL PRODUCTO
Las mtricas del software permiten medir de forma cuantitativa la calidad de sus atributos
internos del producto, esto permite al ingeniero evaluar la calidad antes de su construccin. Es
importante establecer qu es la calidad del software?, quin lo hace?, Por qu es
importante?, Cules son los pasos? Para determinar la calidad, Cul es el producto obtenido?,
Cmo estar seguro de hacerlo correctamente? Todas estas interrogantes se determinarn a lo
largo del desarrollo del presente informe. Aspectos a considerar tales como hacer una distincin
entre medida, mtrica e indicador, qu factores de calidad se toman en cuenta.
P g i n a | 19
CALIDAD GENERAL
Calidad del Software es el cumplimiento de los requisitos de funcionalidad y desempeo

explcitamente establecidos, de los estndares de desarrollo explcitamente documentados y de
las caractersticas implcitas que se esperan de todo software desarrollado profesionalmente.
Con esta definicin se destacan tres puntos importantes:
1. Los requisitos del software son la base de las medidas de calidad. La falta de
concordancia con estos requisitos es una falta de calidad.
2. Los estndares especificados definen un conjunto de criterios de desarrollo que guan la
ingeniera del software. Si no se siguen los criterios, el resultado ser, casi seguramente,
la falta de calidad.
3. A menudo se soslaya un conjunto de requisitos implcitos. Si el software cumple con sus
requisitos explcitos pero no con los implcitos, la calidad del software estar en duda.
FACTORES
CALIDAD DE MCCALL: Estos factores se dividen en dos grupos muy importantes:
1. Los que se miden directamente.

2. Los que solo se miden indirectamente. McCall, Richards y Walters propusieron unos
factores los cuales se concentran en tres aspectos importantes de un producto de
software: sus caractersticas operativas, su capacidad para experimentar cambios y su
capacidad para adaptarse a nuevos entornos.
Correccin: Grado en que cumple el programa con su especificacin y satisface los

objetivos que propuso el cliente.
Contabilidad: Grado en que se esperara que un programa desempee su funcin
con la precisin requerida.
Eficiencia: Cantidad de cdigo y de RR. De cmputo necesarios para que un
programa realice su funcin.
Integridad: Grado de control sobre el acceso al S/W o los datos por parte de
personas no autorizadas.
Facilidad de uso: Esfuerzo necesario para prender, operar y preparar los datos de
entrada de un programa e interpretar la salida.
Facilidad de mantenimiento: Esfuerzo necesario para localizar y corregir un error
en un programa.
Flexibilidad: Esfuerzo necesario para modificar un programa en operacin.
Facilidad de prueba: Esfuerzo que demanda probar un programa con el fin de
asegurar que realiza su funcin.
Portabilidad: Esfuerzo necesario para transferir el programa de un entorno de
hardware o software a otro.
Facilidad de reutilizacin: grado en que un programa puede reutilizarse en otras
aplicaciones.
Interoperabilidad: Esfuerzo necesario para acoplar un sistema con otro.
Muchas de estas mtricas solo se miden subjetivamente.
P g i n a | 20
Factores de calidad del estndar ISO 9126
Se desarroll como un intento por identificar los atributos de calidad para el software de
computadora. El estndar identifica 6 puntos:
1. -Funcionalidad.
2. -Confiabilidad.
3. -Facilidad de uso.
4. -Eficiencia.
5. -Facilidad de mantenimiento.
6. -Portabilidad.
Un marco conceptual para las mtricas del producto
Medidas, mtricas e indicadores
Aunque estos tres trminos suelen utilizarse de manera intercambiable, es necesario especificar
las diferencias entre stos.
Medida: proporciona indicacin cuantitativa de la extensin, la cantidad, la dimensin,

la capacidad o el tamao de algn atributo de un producto o proceso.
Medicin: acto de determinar una medida.
Mtrica: Medida cuantitativa del grado en que un sistema, componente o proceso
posee un atributo determinado.
Un ingeniero de software recopila medidas y desarrolla mtricas para obtener los indicadores.
Indicador: mtrica o combinacin de mtricas que proporcionan conocimientos. Estos

conocimientos le permiten al jefe de proyecto o a los ingenieros de software ajustar el proceso,
el proyecto o el producto para que las cosas mejores.
El reto de las mtricas del producto
El peligro de tratar de encontrar medidas que caractericen tantos atributos diferentes es que
inevitablemente las medidas tienen que satisfacer objetivos que entran en conflicto entre s.
Esto se opone a la teora de que cada medicin debe ser representativa. Aunque la afirmacin
de Fenton es correcta, muchas personas argumentan que la medicin del producto realizada
durante las primeras etapas del proceso de software proporciona a los ingenieros un mecanismo
consistente y objetivo para evaluar la calidad.
3.2 METRICAS DE PROCESO Y DE PROYECTO
Las mtricas del proceso permiten obtener un conjunto de indicadores de proceso que
conduzcan a la mejora de los procesos de software a largo plazo, las cuales se usan con fines
estratgicos. Las mtricas del proyecto permiten valorar el estado de un proyecto en curso, as
como tambin rastrearlos riesgos potenciales y descubrir las areas problema antes que se
vuelvan criticas, tambin permite ajustar el flujo de trabajo o las tareas y evaluar la habilidad
del equipo del proyecto. Las mtricas del proyecto se usan con fines tcticos.
P g i n a | 21
3.2.1 MEJORA DEL PROCESO
Est influenciada por tres factores:
1. -La destreza y motivacin del personal

2. -Complejidad del producto y la
3. -Tecnologa
Est reflejada en condiciones ambientales:
1. -Entorno de Desarrollo
2. -Condiciones de Riesgo
3. -Caractersticas del cliente
Las mtricas del proceso mejoran la calidad de una operacin o un proceso mediante la
medicin de sus atributos y descubrir errores antes de liberar el software desarrollado.
En el proceso de mejoramiento de procesos se detectan y reportan defectos emitidos
por los usuarios finales. Al desarrollar un conjunto de mtricas para mejorar los procesos
se desarrollan un conjunto de mtricas clasificadas como privadas y pblicas.
Mtricas privadas: denominadas como defectos por individuos por

componente durante el desarrollo del proyecto.
Mtricas pblicas: denominadas como ndices a nivel de proyecto,
esfuerzo, planificacin, etc. Las mtricas hacia la mejora de los procesos
ofrecen indicadores que conducen a estrategias an ms especficas.
Para que las mtricas no creen problemas se debe aplicar sentido comn y sensibilidad
para interpretarlas y as ofrecer retroalimentacin a quienes lo recopilan teniendo en
cuenta que no se deben utilizar para realizar evaluaciones o amenazar a los individuos
que tambin forman parte del proyecto. As tambin establecer metas claras y mtricas
que se utilizaran para conseguirlas y no considerar negativos los datos que identifiquen
areas problemas y no obsesionarse solo con una mtrica. Las mtricas del proyecto
tienen doble finalidad:
Minimizar el tiempo de desarrollo: se las aplica por primera vez durante la

estimacin.
Valorar la calidad del producto
3.2.2 MEDICIN DEL SOFTWARE
Se debe medir el software para indicar la calidad del producto, evaluar la productividad
de la gente que desarrolla el proyecto, evaluar los beneficios (en trminos de
productividad y de calidad) derivados del uso de nuevos mtodos y herramientas de
ingeniera del software, establecer una lnea base para la estimacin, ayudar a justificar
el uso de nuevas herramientas o de formacin adicional. En la medicin del software se
han definidos dos tipos de medidas:
Medidas Directas: como el coste y el esfuerzo aplicado.

Medidas Indirectas: definidas como la funcionalidad, calidad, complejidad,
eficiencia, fiabilidad, facilidad de mantenimiento. Dentro de las mtricas ms
importantes del desarrollo de un proyecto de software se han considerado de
alta importancia las siguientes, tales como
P g i n a | 22
Mtricas de productividad: se centran en el rendimiento del proceso de la

ingeniera de software.
Mtricas de calidad: proporcionan una indicacin de cmo se ajusta el
software a los requisitos implcitos y explcitos del cliente.
Mtricas orientadas a la persona: proporcionan informacin sobre la forma en
que la gente desarrolla software de computadora y sobre el punto de vista
humano de la efectividad de las herramientas y mtodos.
Mtricas tcnicas: se centran en las caractersticas del software, complejidad
lgica grado de modularidad.
3.3 METRICAS ORIENTADAS AL TAMAO Y LA FUNCION
3.3.1 METRICAS ORIENTADAS AL TAMAO
Las mtricas del software orientadas al tamao provienen de la normalizacin de las

medidas de calidad y/o productividad considerando el tamao del software que se
haya producido. Si una organizacin de software mantiene registros sencillos, se puede
crear una tabla de datos orientados al tamao, como la que muestra la Figura 4.4. La
tabla lista cada proyecto de desarrollo de software de los ltimos aos y las medidas
correspondientes de cada proyecto. Debe tenerse en cuenta que el esfuerzo y el coste
registrados en la tabla incluyen todas las actividades de ingeniera del software (anlisis,
diseo, codificacin y prueba) y no slo la codificacin.
3.3.2 METRICAS ORIENTADAS A LA FUNCION
Las mtricas del software orientadas a la funcin utilizan una medida de la funcionalidad
entregada por la aplicacin como un valor de normalizacin. Ya que la
funcionalidad>>no se puede medir directamente, se debe derivar indirectamente
mediante otras medidas directas.
Las mtricas orientadas a la funcin fueron propuestas por primera vez por Albretch,
quien sugiri una medida llamada punto defuncin. Los puntos de funcin se derivan
con una relacin emprica segn las medidas contables (directas) del dominio de
informacin del software y las evaluaciones de la complejidad del software.
P g i n a | 23
Nmero de entradas de usuario. Se cuenta cada entrada de usuario que

proporciona diferentes datos orientados a la aplicacin. Las entradas se
deberan diferenciar de las peticiones, las cuales se cuentan de forma separada.
Nmero de salidas de usuario. Se cuenta cada salida que proporciona al usuario
informacin orientada a la aplicacin. En este contexto la salida se refiere a
informes, pantallas, mensajes de error, etc.
Nmero de peticiones de usuario. Una peticin se define como una entrada
interactiva que produce la generacin de alguna respuesta del software
inmediata en forma de salida interactiva.
Nmero de archivos. Se cuenta cada archivo maestro lgico (esto es, un grupo
lgico de datos que puede ser una parte de una gran base de datos o un archivo
independiente).
Nmero de interfaces externas. Se cuentan todas las interfaces legibles por la
mquina (por ejemplo: archivos de datos de cinta o disco) que se utilizan para
transmitir informacin a otro sistema.
4. GESTION DE LA CALIDAD DEL SOFTWARE
4.1 CONCEPTOS GENERALES.
Durante los ltimos aos se ha mejorado sustancialmente la calidad de software, esto se debe
en gran medida a que desarrollar un software no es lo mismo que la manufactura de un
producto. Elaborar un producto de calidad implica que el producto desarrollado debe guardar
similitud con su especificacin. Sin embargo durante el proceso de desarrollo de software se
presentan problemas entre la especificacin de un software y su implementacin, y en muchos
casos no se sabe especificar caractersticas de calidad. Por otro lado, la ingeniera de
requerimientos presenta limitaciones en la redaccin de especificaciones concreta de software.
Se presentan las mtricas para medir el comportamiento del software: la competencia, calidad,
desempeo y la complejidad del software.
El principal objetivo de los ingenieros del software es producir un sistema, aplicacin o producto
de alta calidad, para lo cual emplean mtodos y herramientas efectivas dentro del contexto de
un proceso maduro de desarrollo del software y adems deben desarrollar mediciones que den
como resultado sistemas de alta calidad. Para obtener esta evaluacin, el ingeniero debe utilizar
medidas tcnicas.
4.2 ASEGURAMIENTO DE LA CALIDAD
SQA (Software Quality Assurance o Aseguramiento de la Calidad del Software)
La calidad es el conjunto de propiedades inherentes a una entidad, que permiten juzgar su valor.
Est cuantificada por el valor que se le da al conjunto de propiedades seleccionadas. De esta
manera la calidad es subjetiva y, como dice James Bach, es circunstancial. Es subjetiva porque
depende de los atributos elegidos para medirla y es circunstancial porque el conjunto de
atributos elegidos puede variar en situaciones diferentes. Cuando aplicamos el concepto de
calidad al software, ste deja de ser subjetivo porque se determinan cules son los atributos de
P g i n a | 24
calidad del software. Pero no deja de ser accidental ya que en ciertas situaciones, un
determinado conjunto de caractersticas de calidad puede ser ms importante que en ciertas
otras. Resumiendo, la calidad del software es medible y vara de un sistema a otro o de un
programa a otro.
PROPSITO
Proporcionar visibilidad sobre los procesos utilizados por el proyecto de software y sobre los
productos que genera.
OBJETIVOS
1. Planificar las actividades de aseguramiento de la calidad.

2. Revisar y auditar objetivamente los productos y las actividades para verificar que
estn conformes con los procedimientos y estndares aplicables.
3. Proporcionar los resultados de estas revisiones o auditoras informando a la
direccin cuando sea necesaria su mediacin.
METAS
Planificar las actividades de SQA

Verificar la adherencia de los productos y actividades de software a los estndares, a los
procedimientos y a los requisitos aplicables.
Los grupos y los individuos afectados son informados de las actividades y de los
resultados de la SQA.
Las tareas que no cumplen con los estndares o procedimientos y que no se pueden
resolver dentro del proyecto del software son tratadas por la gerencia general.
ACTIVIDADES PRINCIPALES
Un plan de SQA es preparado para el proyecto de software de acuerdo a procedimientos

documentados.
Las actividades del grupo de SQA son realizadas de acuerdo a los planes de SQA
El grupo de SQA participa en la preparacin y revisin de los planes de desarrollo,
estndares y procedimientos del proyecto.
El grupo de SQA revisa las actividades de Ingeniera de Software para verificar el
cumplimiento de lo anterior.
El grupo de SQA audita los productos del trabajo designado para verificar el
cumplimiento de lo anterior.
P g i n a | 25
El grupo de SQA peridicamente reporta los resultados de sus actividades al grupo de

ingeniera de software.
Las desviaciones detectadas en las actividades del software y en los productos del
trabajo de software son documentadas y manejadas de acuerdo a procedimientos
previamente documentados.
El grupo de SQA conduce peridicamente revisiones de sus actividades y reuniones con
el personal de SQA del cliente, segn sea necesario.
ROL DE SQA
El rol para SQA es brindar a Metodologa de Desarrollo de Software la administracin la

seguranza de que procesos oficialmente establecidos estn siendo implementados. Y asegura
que:
Una apropiada este establecida

Que los proyectos utilicen estndares y procedimientos en su trabajo
Que la documentacin sea creada para mantenimiento y mejoramiento
La administracin de configuracin de software este adecuada para controlar cambios
Se realicen pruebas y que se aprueben
Cualquier deficiencia y desviaciones sean identificadas y llevadas con atencin a la
administracin.
4.3 PLANEAMIENTO DE LA CALIDAD
La planificacin de la calidad es el proceso en el cual se desarrolla un plan de calidad para un

proyecto. Define la calidad del software deseado y describe cmo debe valorarse.
Humphrey propone una estructura para un plan de calidad basado en los siguientes pasos:
Introduccin del producto: debe incluir la descripcin del producto, el mercado al que
se dirige y las expectativas de calidad
Planes de producto: contiene las fechas y plazos de terminacin de producto y las
responsabilidades asignadas.
Descripciones del proceso: contiene los procesos de desarrollo y de servicio.
Metas de calidad: contiene metas y planes de calidad para el producto, que debern
incluir la identificacin de los atributos seleccionados como ms relevantes.
Riesgos y gestin de riesgos: contiene los riesgos clave que podran afectar la calidad
del producto.
4.4 ATRIBUTOS DEL SOFTWARE
Durante el proceso de planificacin de la calidad debe considerarse los siguientes atributos
P g i n a | 26
5. GESTIN DE LA CONFIGURACIN DEL SOFTWARE
Gestin de Configuracin de Software (Software Configuration Management, SCM) es una

especializacin de la gestin de configuracin a todas las actividades en el sector del desarrollo
de software.
SCM trata y controla:
La elaboracin de cdigo fuente por varios desarrolladores simultneamente.

El seguimiento del estado de las fases del desarrollo de software (versiones) y sus
cambios (control de versiones).
La conduccin de la integracin de las partes del software en un solo producto de
software.
Para la realizacin de la SCM hay diferentes herramientas. Pero herramientas que
pretenden ofrecer una solucin total al problema, a menudo no cumplen con los
requisitos tcnicos como:
Apoyo a diferentes plataformas.
Iniciar el proceso de build.
Conexin a los bancos de datos existentes.
Integracin a la organizacin existente.
Por esa razn ofrece una mayor flexibilidad una solucin que integre herramientas parciales que
sean ms fciles de integrar en el proceso existente. Ejemplo:
Uso de un software de administracin de versiones como IBM Rational Team Concert,

CVS, Subversion, SourceSafe, ClearCase, Darcs, Plastic SCM.
Introduccin de una herramienta para la documentacin comunitaria con una
administracin de cambios, acceso interactivo y foro o alguna plataforma para la
comunicacin.
Determinar un entorno para el build automtico.
5.1 ELEMENTOS DE LA CONFIGURACIN DEL SOFTWARE
Segn la interfaz gestin de la configuracin definida en MTRICA v3, los elementos de

configuracin del software incluyen:
Ejecutables
Cdigo Fuente
Modelos de datos
Modelos de procesos
Especificaciones de requisitos
Pruebas
Y para cada uno de estos elementos se almacenar al menos:
Nombre
Versin
Estado
Localizacin
P g i n a | 27
5.2 EL PROCESO DE GESTIN DE LA CONFIGURACIN DEL SOFTWARE
Se denomina Gestin de la Configuracin al conjunto de procesos destinados a asegurar la

calidad de todo producto obtenido durante cualquiera de las etapas del desarrollo de un Sistema
de Informacin (S.I.), a travs del estricto control de los cambios realizados sobre los mismos y
de la disponibilidad constante de una versin estable de cada elemento para toda persona
involucrada en el citado desarrollo. Estos dos elementos (control de cambios y control de
versiones de todos los elementos del S.I.) facilitan tambin el mantenimiento de los sistemas al
proporcionar una imagen detallada del sistema en cada etapa del desarrollo. La gestin de la
configuracin se realiza durante todas las fases del desarrollo de un sistema de informacin,
incluyendo el mantenimiento y control de cambios, una vez realizada la puesta en produccin.
Identificacin de la configuracin GCS: se pueden identificar dos tipos de los objetos bsicos y
los objetos compuestos.
Un objeto bsico es una unidad de texto creada durante el anlisis, diseo, codificacin o
prueba.
Un objeto compuesto es una coleccin de objetos bsicos u objetos compuestos. Cada objeto
tiene un conjunto de caractersticas que los identifican como nicos. El nombre del objeto es
una cadena de caracteres que identifica al objeto sin ambigedad. La descripcin del objeto es
una lista de elementos de datos que identifican:
El tipo de ECS (documento, programa, datos) que est representado por el objeto.
Un identificador del proyecto; y la informacin de la versin y/o el cambio.
El esquema de identificacin de los objetos de software debe tener en cuenta que los objetos
evolucionan a lo largo del proceso de ingeniera, por lo que se puede crear un grafo de evolucin.
6. EXPOSICIN DEL PROYECTO SOFTWARE
6.1 PROTOTIPO FUNCIONAL
Permite que todo el sistema, o algunos de sus partes, se construyan rpidamente para
comprender con facilidad y aclarar ciertos aspectos en los que se aseguren que el desarrollador,
el usuario, el cliente estn de acuerdo en lo que se necesita as como tambin la solucin que se
propone para dicha necesidad y de esta forma minimizar el riesgo y la incertidumbre en el
desarrollo, este modelo se encarga del desarrollo de diseos para que estos sean analizados y
prescindir de ellos a medida que se adhieran nuevas especificaciones, es ideal para medir el
alcance del producto, pero no se asegura su uso real.
Este modelo principalmente se lo aplica cuando un cliente define un conjunto de objetivos

generales para el software a desarrollarse sin delimitar detalladamente los requisitos de entrada
procesamiento y salida, es decir cuando el responsable no est seguro de la eficacia de un
algoritmo, de la adaptabilidad del sistema o de la forma en que interacta el hombre y la
mquina. Este modelo se encarga principalmente de ayudar al ingeniero de sistemas y al cliente
a entender de mejor manera cul ser el resultado de la construccin cuando los requisitos estn
satisfechos.
P g i n a | 28
El paradigma de construccin de prototipos tiene tres pasos:
1. Escuchar al cliente. Recoleccin de requisitos. Se encuentran y definen los

objetivos globales, se identifican los requisitos conocidos y las reas donde es
obligatorio ms definicin.
2. Construir y revisar la maqueta (prototipo).
3. El cliente prueba la maqueta (prototipo) y lo utiliza para refinar los requisitos del
software.
Este modelo es til cuando:
El cliente no identifica los requisitos detallados.

El responsable del desarrollo no est seguro de la eficiencia de un algoritmo, sistema
operativo o de la interface hombre-mquina.
VENTAJAS
Este modelo es til cuando el cliente conoce los objetivos generales para el software, pero no
identifica los requisitos detallados de entrada, procesamiento o salida. Tambin ofrece un mejor
enfoque cuando el responsable del desarrollo del software est inseguro de la eficacia de un
algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debera tomar la
interaccin humano-mquina.
DESVENTAJAS
Su principal desventaja es que una vez que el cliente ha dado su aprobacin final al prototipo y
cree que est a punto de recibir el proyecto final, se encuentra con que es necesario reescribir
buena parte del prototipo para hacerlo funcional, porque lo ms seguro es que el desarrollador
haya hecho compromisos de implementacin para hacer que el prototipo funcione
rpidamente. Es posible que el prototipo sea muy lento, muy grande, no muy amigable en su
uso, o incluso, que est escrito en un lenguaje de programacin inadecuado.
El cliente ve funcionando lo que para l es la primera versin del prototipo que ha sido
construido con "plastilina y alambres", y puede desilusionarse al decirle que el sistema an no
ha sido construido. El desarrollador puede ampliar el prototipo para construir el sistema final
sin tener en cuenta los compromisos de calidad y de mantenimiento que tiene con el cliente.
6.2 MANUALES DEL SISTEMA
Conjunto de informacin que nos dice qu hacen los sistemas, cmo lo hacen y para quin lo
hacen. La documentacin consiste en material que explica las caractersticas tcnicas y la
operacin de un sistema. Es esencial para proporcionar entendimiento de un sistema a quien lo
vaya a usar para mantenerlo, para permitir auditoria del sistema y para ensear a los usuarios
como interactuar con el sistema y a los operando como hacerlo funcionar.
MANUAL ADMINISTRATIVO
Sirve como punto de partida al Sistema propuesto, ya que ser funcin de la gerencia,
de acuerdo con los usuarios de dicho Sistema, determinar si no expuesto en l satisface
los requerimientos del propio sistema. Una vez lograda la aprobacin, se estar en
condiciones de iniciar el desarrollo del Sistema propuesto e ir integrando el resto de la
documentacin.
P g i n a | 29
El manual tiene como finalidad el permitir a la alta gerencia tener la informacin

necesaria y suficiente sobre un sistema en particular y servir como fuente de consulta
una vez que el Sistema ha sido implantado:
Contenido
Nombre del sistema
Equipo Encargado Del Sistema
Resumen Administrativo
Comprendido de los puntos que se describen en el manual, el cual tiene como propsito
permitir a los altos ejecutivos enterarse en forma somera de la propuesta del sistema.
En este punto aparece por primera vez el nombre del sistema, el cual debe ser nico,
este deber conservarse invariable en todos los documentos referentes a ese sistema.
Planteamiento
Este punto tiene como finalidad registrar los antecedentes que servirn de partida al
desarrollo del anlisis del sistema. Se debe mencionar:
Dependencia que requiri el trabajo: Personas y / o puestos ocupados por estas al

momento de requerirse el trabajo (acuerdos, disposiciones legales, memorandos, y
otros) Condiciones y criterios que normaron el desarrollo del trabajo. Fechas
correspondientes. Objetivos Del Sistema Aqu se dejarn establecidos los objetivos que
debe cubrir el sistema, en forma clara y precisa para evitar errores de interpretacin.
Entradas Del Sistema (Informacin A Captar) Debe quedar especificado en este punto,
los documentos fuentes que inician las operaciones del sistema as como la informacin
detallada de aquellos conceptos que sern los datos a captar por el sistema. Se debern
mencionar todos los datos que en forma secundaria originan una entrada importante al
sistema.
Ejemplo:
MANUAL DE USUARIO
Expone los procesos que el usuario puede realizar con el sistema implantado. Para lograr
esto, es necesario que se detallen todas y cada una de las caractersticas que tienen los
programas y la forma de acceder e introducir informacin. Permite a los usuarios
conocer el detalle de qu actividades ellos debern desarrollar para la consecucin de
los objetivos del sistema. Rene la informacin, normas y documentacin necesaria para
que el usuario conozca y utilice adecuadamente la aplicacin desarrollada.
P g i n a | 30
OBJETIVOS
o Que el usuario conozca cmo preparar los datos de entrada.

o Que el usuario aprenda a obtener los resultados y los datos de salida.
o Servir como manual de aprendizaje.
o Servir como manual de referencia.
o Definir las funciones que debe realizar el usuario.
o Informar al usuario de la respuesta a cada mensaje de error.
Pasos a seguir para definir como desarrollar el manual de usuario.
Identificar los usuarios del sistema: personal que se relacionar con el sistema.
Definir el diferente tipo de usuarios: se presentan los diferentes tipos de usuarios que
usaran el sistema. Ejemplo: Usuarios directos, indirectos.
Definir los mdulos en que cada usuario participar: Se describen los mdulos o
procesos que se ejecutarn por cada usuario en forma narrativa breve y clara.
Importancia Del Manual De Usuario

El Manual de Usuario facilita el conocimiento de:
Los documentos a los que se pueden dar entrada por computadora.

Los formatos de los documentos.
Las operaciones que utiliza de entrada y salida de los datos.
El orden del tratamiento de la computadora con los datos introducidos.
El momento en que se debe solicitar una operacin deseada.
Los resultados de las operaciones realizadas a partir de los datos introducidos.
Al elaborar el Manual de Usuario, hay que tener en cuenta a quin va dirigido es decir,
el manual puede ser manejado desde el director de la empresa hasta el introductor de
datos. Por consiguiente, debe redactarse de forma clara y sencilla para que lo entienda
cualquier tipo de usuario.
P g i n a | 31
7. REFERENCIAS
Ingeniera de Software
http://www.marcoteorico.com/curso/45/ingenieria-de-software
Descomposicin modular
https://ittgweb.wordpress.com/2016/05/29/descomposicion-modular/
Arquitectura de dominio Especfico
https://ittgweb.wordpress.com/2016/05/29/3-3-arquitectura-de-dominio-especifico/
Diseo de Software de Arquitectura Multiprocesador
https://ittgweb.wordpress.com/2016/05/29/3-4-diseno-software-arquitectura-
multiprocesador/
Diseo de Arquitectura de Software Cliente Servidor
https://ittgweb.wordpress.com/2016/05/28/3-5-diseno-de-software-de-arquitectura-
arquitectura-cliente-servidor/
Diseo de Arquitectura de Software Arquitectura Distribuida
https://ittgweb.wordpress.com/2016/05/29/3-6-diseno-de-software-de-arquitectura-
distribuida/
Diseo de Arquitectura de Software Arquitectura de Tiempo real
https://ittgweb.wordpress.com/2016/05/29/3-7-diseno-de-software-de-arquitectura-de-
tiempo-real/
Ostin dicson-wikipedia.com
Exposicin del Proyecto Software
http://sabus.usal.es/pdf/manual_ref.pdf
http://ec.europa.eu/internal_market/imi-net/docs/user_handbook_es.pdf
http://www.ccee.edu.uy/ensenian/catoym/material/2009-05-
Los%20Manuales%20Administrativos%20Hoy.pdf
P g i n a | 32

Arquitectura de Software - Conceptos

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Arquitectura de Software - Conceptos

Uploaded by

Copyright:

Available Formats

UNIVERSIDAD SAN PEDRO

Escuela de Ingeniera Informtica y Sistemas

Asignatura: Ingeniera de Software II

Docente: Jaime Omar Meca Rosales

Alumno: Gonzales Domador I Arturo

El Diseo no es solo lo que ves, sino como funciona

ARQUITECTURA DE DOMINIO ESPECFICO 8

DISEO DE SOFTWARE DE ARQUITECTURA MULTIPROCESADOR 8

DISEO DE SOFTWARE DE ARQUITECTURA CLIENTE SERVIDOR 10

DISEO DE SOFTWARE DE ARQUITECTURA DISTRIBUIDA 12

DISEO DE SOFTWARE DE ARQUITECTURA DE TIEMPO REAL 14

2. VERIFICACIN, VALIDACIN Y PRUEBAS DEL SOFTWARE

VERIFICACIN Y VALIDACIN DEL SOFTWARE 15

DISEO DE CASOS DE PRUEBA 16

PRUEBAS DE CAJA NEGRA Y CAJA BLANCA 17

PRUEBA DE UNIDAD Y DE INTEGRACIN 18

3. MTRICAS DEL SOFTWARE

MTRICAS DEL PRODUCTO 19

MTRICAS DEL PROCESO Y PROYECTO 21

MTRICAS ORIENTADAS AL TAMAO Y A LA FUNCIN 23

4. GESTIN DE LA CALIDAD DEL SOFTWARE

ATRIBUTOS DEL SOFTWARE 26

5. GESTIN DE LA CONFIGURACIN DEL SOFTWARE

ELEMENTOS DE LA CONFIGURACIN DEL SOFTWARE 27

EL PROCESO DE GESTIN DE LA CONFIGURACIN DEL SOFTWARE 28

6. EXPOSICIN DEL PROYECTO SOFTWARE

MANUALES DEL SISTEMA 29

Es un mtodo de diseo que proporciona un mecanismo sistemtico para descomponer el

1. Capacidad de descomposicin modular. Si un mtodo de diseo proporciona un

1. Identificar los mdulos

Despus de elegir la organizacin del sistema en su totalidad, debemos decir como

Al final de los documentos debe haber una matriz REQUISITOS/COMPONENTES. En

Mide la interrelacin entre dos mdulos, segn el tipo de conexin y la complejidad de

ALTA COHESIN ABSTRACCIONAL, se logra cuando se disea el mdulo como tipo

MEDIA COHESIN SECUENCIAL, los elementos del mdulo trabajan de forma

La descripcin del comportamiento de un mdulo permite establecer el grado de

Si es una frase compuesta y contiene ms de un verbo la cohesin ser media.

Para facilitar los cambios, el mantenimiento y la reutilizacin de mdulos es necesario

IDENTIFICACIN, el nombre debe ser adecuado y descriptivo.

La adaptacin de un sistema resulta ms difcil cuando no hay independencia

ACCESIBILIDAD, debe resultar sencillo el acceso a los documentos de especificacin,

CONSISTENCIA, despus de cualquier adaptacin se debe mantener la consistencia del

1.2. ARQUITECTURA DE DOMINIO ESPECFICO

1. Modelos genricos: Son abstracciones obtenidas a partir de varios sistemas reales. En

1.3. DISEO DE SOFTWARE DE ARQUITECTURA MULTIPROCESADOR

La ventaja de un sistema multiproceso reside en la operacin llamada cambio de contexto. Esta

Un conjunto de tareas puede ser completado ms rpidamente si hay varias unidades de

A pesar de las grandes mejoras acaecidas en monoprocesadores para algunas aplicaciones no es

Existen dos factores claves para la extensin de multiprocesadores:

Flexibilidad: El mismo sistema puede usarse para un nico usuario incrementado el

El multiproceso no es ms que un conjunto de tareas que pueden ser completadas rpidamente

Los objetivos de la programacin paralela, son:

Reducir el tiempo de cmputo.

1.4. DISEO DE SOFTWARE DE ARQUITECTURA CLIENTE-SERVIDOR

Diseo de software de arquitectura cliente - servidor es un modelo de sistema en el que dicho

En el modelo cliente servidor, el cliente enva un mensaje solicitando un determinado servicio a

Principales componentes del modelo son:

1. Un conjunto de servidores que ofrecen a otros subsistemas.

Aceptar los requerimientos de bases de datos que hacen los clientes.

Administrar la interfaz de usuario.

3. Una red que permite a los clientes acceder a estos servicios.

Las caractersticas bsicas de una arquitectura Cliente/Servidor son:

Combinacin de un cliente que interacta con el usuario, y un servidor que interacta

Existe una clara distincin de funciones basada en el concepto de servicio, que se