UNIVERSIDAD NACIONAL AUTNOMA DE

MXICO

FACULTAD DE CONTADURA
Y ADMINISTRACIN

PROYECTO FINAL
INFORMTICA VI

CALVO MANRIQUE EMILIO

GRUPO 2691

PROFA. MARIA DEL ROCO CARRILLO

VELZQUEZ

MXICO DF A 9 DE MAYO DE 2017

 NDICE TEMTICO

1. INTRODUCCIN A LA TEORA DEL DESARROLLO DE

SISTEMAS ORIENTADOS A OBJETOS.
2. MODELO DE IMPLEMENTACIN...
2.1. DIAGRAMAS DE IMPLEMENTACIN. ..
2.2. DIAGRAMA DE COMPONENTES. .
2.3. DIAGRAMAS DE DESPLIEGUE. .
2.4. QU ES UN MODELO DE PRUEBA. .
3. PLAN DE IMPLEMENTACIN.
3.1. LINEAMIENTOS PARA LA INSTALACIN E IMPLANTACIN. ..
3.2. MANUAL TCNICO. ..
3.3. MANUAL DE USUARIO.
4. IMPLEMENTACIN DE COMPONENTES.
5. INTEGRACIN DE SUBSISTEMAS Y SISTEMAS. ..
6. BIBLIOGRAFA.
1 INTRODUCCIN
Los sistemas grandes son demasiados complejos para que una sola
persona, por las limitaciones de la mente humana, sea capaz de retener con
precisin todos los elementos y caractersticas que lo conforman.

La complejidad expresa el grado en que un sistema o componente tiene

un diseo o implementacin difcil de entender o verificar.
En 1972 Edsger W. Dijkstra (Edsger Wybe Dijkstra) seal que se debe
reflexionar en la estructura de las abstracciones necesarias para hacer frente
conceptualmente a la complejidad de lo que se est diseando.

La complejidad del problema

Tiene que ver con la funcionalidad que el sistema debe brindar.
Cuando mayor sea el nmero de requerimientos o funcionalidad ofrecida por
una aplicacin, mayor ser el tamao del sistema, creando sistemas ms
difciles de comprender y desarrollar.

La complejidad de la solucin
Tiene que ver con el diseo del sistema, el cual debe satisfacer la
funcionalidad del problema.

Se consideran dos factores relacionados con la complejidad de un sistema:

uno esttico y otro dinmico.

1. El factor esttico corresponde a la funcionalidad que un sistema de

software debe ofrecer al ser inicialmente desarrollado

2. El factor dinmico corresponde a la funcionalidad que vara con el

tiempo, en otras palabras, con los posibles cambios en el sistema.
Estos cambios pueden ser considerables y, en muchos casos, son la
causa de los retrasos y cancelaciones de los proyectos.

Cuando nos encontramos con sistemas con una complejidad alta,

es necesario manejar modelos.

Los modelos permiten captar y enumerar los requisitos y el dominio de

conocimiento, de forma que todos los implicados puedan entenderlos y estar
de acuerdo con ellos. Un
modelo de un sistema grande permite ocuparse de la complejidad que es
difcil de tratar.
Los modelos adquieren diversas formas para diferentes propsitos y
aparecen en diferentes niveles de abstraccin. La cantidad de detalle del
modelo debe adaptarse a uno de los siguientes propsitos

Guas al proceso de pensamiento.

Especificaciones abstractas de la estructura esencial de un sistema.

Especificaciones completas de sistema final.

Ejemplos de sistemas tpicos o posibles.

Descripciones completas o parciales de sistemas.

Los modelos tienen dos aspectos importantes (Rumbaugh, Jacobson y

Booch: 15):

Informacin (semntica) y presentacin visual (notacin).

El aspecto semntico explica el significado de cada smbolo y cmo ste debe

ser interpretado, ya sea por s mismo o en el contexto con otros smbolos
(Hans-Erik,2004: 11).

Otro elemento en el que se apoya es la sintaxis, el cual se compara al

lenguaje natural, en donde es importante para saber cmo decir
correctamente las cosas y cmo usar diferentes palabras smbolos juntos
para conformar una sentencia y conocer cmo pueden ser combinadas
dentro del lenguaje de modelado.

La presentacin visual, notacin, es el material grfico que se ve en los

modelos; es la sintaxis del lenguaje de modelado (Martin Fowler, 1999:
5). No agregan significado, ms bien ayudan en la presentacin, organizacin
y distribucin de los elementos dentro del modelo de una manera ms
comprensible.

Por ejemplo, en un diagrama de clases se puede representar la clase, los

tipos de asociacin y la multiplicidad de los elementos grficos y smbolos en
su conjunto constituyen el modelo.

Es una coleccin de mtodos, prcticas y reglas usados para trabajar en

algn campo o disciplina.
Una metodologa puede englobar un conjunto de mtodos (de anlisis,
diseo, programacin, etc.) que en su conjunto abarcan el ciclo de sistemas.
Por lo tanto, una metodologa en el desarrollo de sistemas complejos nos
ayuda al definir los pasos a seguir para plasmar las ideas, implementarlas y
darle un mantenimiento de modo sistemtico para administrar un proyecto y
llevarlo a cabo con altas posibilidades de xito, cumpliendo con el objetivo
final.

Una metodologa de desarrollo de sistemas nos ayuda a manejar

la complejidad, ya que es una estrategia que lleva un proceso estandarizado
de desarrollo de sistemas que incluye un conjunto de actividades, mtodos,
modelos, prcticas y herramientas automatizadas que se usan para construir
un sistema.

El paradigma de Programacin Orientada a Objetos(POO)

se enfoca en la identificacin de entidades, su estructura, clasificacin y
comportamiento dentro del sistema por desarrollar o en el existente. Teniendo
esto presente, tras hacer un modelado de un sistema utilizando este
paradigma, el analista deber identificar objetos y clases,
de tal forma que se puedan crear relaciones, que reflejarn el trabajo entre
los objetos con el fin de generar un modelo de objetos representativos de la
realidad del problema o modelo del negocio.

Cuando se realiza el anlisis y diseo orientado a objetos se deben de seguir

los principios bsicos con la finalidad de que nuestro modelado est
correctamente definido bajo el paradigma orientado a objetos.

El paradigma orientado a objeto se basa en cuatro principios que constituyen

la base de todo desarrollo orientado a objetos.

Estos son: la abstraccin, el modularidad, la jerarqua y

el encapsulamiento.

Pero tambin hay otros elementos que son importantes no fundamentales en

POO: concurrencia y la persistencia.

Abstraccin

La abstraccin (Booch, 1996: 46-47), denota las caractersticas esenciales de

un objeto que lo distinguen de todos los dems tipos de objeto.

La abstraccin no ayuda a representar de forma concisa una entidad que la

distingue de otras; desde una perspectiva, en el anlisis y diseo orientado a
objetos, realizamos abstracciones a partir de un planteamiento de la vida real
para crear los modelos que lo representan, que posteriormente se pasar en
programa orientado a objetos para construir el sistema.

Por lo tanto, desde el punto de vista de la orientacin de objetos,

la abstraccin es la capacidad humana de identificar los objetos
y clases de objetos que conforman el sistema y que permite,
adems, manejar la complejidad.

Para construir sistemas complejos, el desarrollador debe abstraer distintas

vistas del sistema, construir modelos utilizando notaciones precisas, verificar
que los modelos plasmen los requisitos del sistema y aadir gradualmente
los detalles para trasformar los modelos en una aplicacin.

La clasificacin por categorizacin clsica (agrupar elementos con

propiedades similares), agrupamiento conceptual (agrupar entidades que
compartan significado conceptual, es decir para qu sirven) y teora de
prototipos, pueden ayudar mucho.

Tambin es adecuado recordar que no debe pretenderse realizar una sola

abstraccin, lo mejor es realizar varias, y en cada una de ellas plasmar una
parte del problema.
Mediante la abstraccin podemos identificar todos los elementos de un
objeto, tales como su identidad (propiedades), sus estados (los valores de las
propiedades), y comportamiento (los mtodos que realiza).

Modularidad

Un sistema complejo es ms fcil de resolver si se divide en un conjunto de

elementos (Pressman, 2010:85). La modularidad nos ayuda a comprender
mejor un negocio, ya que es mejor entender por partes como funciona y
despus ensamblar todo.

Cuando se realiza la modularidad, debe ser eficazmente, es decir,

se debe ser altamente cohesivo en su funcin o restrictivo en su contenido y
debe tener poco acoplamiento con respecto a fuentes de datos y otros
elementos internos o externos.

Jerarqua
La jerarqua es una clasificacin u ordenacin de abstracciones (Booch,
1996: 66).
La jerarquizacin consiste en agrupar clases que se obtuvieron de
abstracciones realizadas y se agrupan de acuerdo a las funciones que
realizan.
La relacin jerrquica se da cuando una clase hija (subclase) hereda de una
clase padre (superclase).

Bsicamente, la jerarqua define un tipo de

relacin entre las clases, que indica que puede
tomar cierto comportamiento definido en una o ms clases,
la jerarqua entre las clases se puede disear como si fuera un organigrama.

Unos conjuntos de abstracciones a menudo forman una jerarqua, y mediante

la identificacin de esta jerarqua el diseo se simplifica ayudando a la
comprensin del problema. A partir de la jerarqua de las clases se puede
realizar la herencia. El concepto de herencia se explicar ms abajo en
conceptos.

Encapsulamiento

El encapsulamiento consiste en separar los aspectos externos de un objeto,

los cuales son accesibles por otros objetos, los detalles de implementacin
interno del objeto se ocultan de otros objetos (Rumbaugh, 1991: 7). Es
importante ocultar los detalles de implementacin de un objeto y que solo
ciertas operaciones puedan ser visibles y utilizadas por el usuario. La
encapsulacin es como una caja negra que esconde los detalles para que no
puedan ser vistos ni alterados y slo permite acceder a ellos de forma
controlada y a su nivel de acceso.
Concurrencia

Para cierto tipo de problemas, un sistema puede tener varios manejos de

eventos simultneamente. Esto puede involucrar mucha capacidad de
cmputo de un solo procesador.
En estos casos se debe considerar el uso distribuido de implementaciones
que sean multitarea, por lo tanto la concurrencia es la ocurrencia de dos o
ms lugares de ejecucin durante el mismo intervalo de tiempo (Booch,
Jacobson y Rumbaugh, 2006:500). Un sistema que tiene concurrencia debe
poder manejar varios hilos en tiempo de ejecucin como si fuera mltiple en
un solo CPU.

En un sistema basado en un diseo orientado a objetos, se puede

conceptualizar el mundo como consistente en un conjunto de objetos
cooperativos, algunos de los cuales estn activos y, por lo tanto, sirven como
centros de actividad independiente. Dada esta concepcin, la concurrencia
es la propiedad que distingue un objeto activo de uno que no est activo.

Una de las realidades acerca de la concurrencia en un sistema, es considerar

cmo los objetos activos pueden sincronizar sus actividades con los otros y
con los objetos que son puramente secuenciales. Por ejemplo, si dos objetos
activos intentan enviar mensajes a un tercer objeto, hay que estar seguro de
utilizar algn medio de exclusin mutua, de manera que el estado del objeto
sobre el que acta no est daado cuando los objetos activos intenten
actualizar su estado simultneamente.

Persistencia

Un objeto, desde el punto de vista de software, toma cierta cantidad de

espacio en memoria y existe una cantidad de tiempo. Por lo que un objeto en
ocasiones debe tener la capacidad de existir sin algn cambio durante un
tiempo. De aqu la importancia de que los datos se conserven sin alteracin
alguna durante las diferentes ejecuciones del programa.

La persistencia es la propiedad de un objeto por lo que su existencia

trasciende el tiempo (es decir, el objeto contina existiendo despus de que
su creador deja de existir) y/o el espacio (es decir, la posicin del objeto vara
con respecto al espacio de direcciones en el que fue creado). (Booch et al.,
2007: 71)

La persistencia ofrece algo ms que el tiempo de vida de los datos. En bases

de datos orientadas a objetos, no slo el estado de un objeto debe persistir,
sino tambin su clase debe superar cualquier cambio en el programa, de
modo que cada programa interprete el estado guardado de la misma manera.
Esto claramente hace que sea difcil mantener la integridad de una base de
datos a medida que crece, especialmente si hay que cambiar la clase de un
objeto despus de que ya existe y se realizaron operaciones con ste.

En el anlisis y diseo orientado a objetos, existen algunos conceptos que

primero se deben entender, para comprender la forma en que se maneja a
partir de su asociacin con el mundo real.
En el mundo, generalmente, encontramos personas, animales y cosas, todas
ellas desde la prospectiva de la orientacin a objetos se consideran clases de
objetos y estos objetos tienen estado (definen cmo es, es decir, sus
caractersticas) y comportamiento (las acciones que realiza), los cuales lo
definen como un ente al que se conoce como objeto.
Los objetos para poder comunicarse (interactuar) lo deben hacer por medio
de mensajes, de esta manera saben que deben de responder con base en la
peticin recibida.

Una clase define cmo es el objeto en s y existen 2 tipos de clases, las clases
generales (superclases) y las subclases (especializadas), que van de lo
general a lo particular, de que exista una jerarqua entre ellas; a partir de sta
se puede saber de qu clase se puede realizar herencia. La herencia, como
en la vida real, adquiere sus rasgos (atributos) fsicos e incluso su forma de
ser (comportamiento), esta cualidad tambin da origen al polimorfismo, que
permite realizar operaciones de diferentes formas dependiendo del objeto
que las realiza.

Las clases generalmente se agrupan de acuerdo al tipo de operacin que

realizan, a partir de ello se requiere una organizacin y sta se realiza por
medio de paquetes. Tambin en la vida seguimos reglas de comportamiento
(operacin) y tambin de comunicacin; para definir estas reglas necesarias
en la operacin se utilizan las interfaces.

Clase

Una clase describe un grupo de objetos con propiedades similares (atributos),

comportamiento comn (operaciones), relaciones comunes con otros objetos
y semntica comn (Rumbaugh et. al., 1991: 22).

Desde la perspectiva del anlisis y diseo orientacin a objetos, en una clase

se definen los atributos cmo las caractersticas que describen a la clase y
las operaciones, como las acciones que puede realizar. Desde la perspectiva
de la programacin orientada a objetos las caractersticas estn
representadas en variables y las operaciones en los mtodos.

Atributos

Un atributo es un valor de un dato en poder de los objetos en una clase

(Rumbaugh,1991: 23). Los atributos definen las caractersticas que pueden
tener un clase y ste es almacenado en variables.

Operaciones

Una operacin es una funcin o transformacin que puede ser aplicada a o

realizada por objetos en una clase (Rumbaugh et al., 1991: 25). Las
operaciones representan el comportamiento que puede realizar. En la clase
se encuentran definidos en mtodos o funciones.

Objeto

Un objeto es una entidad tangible que exhibe algn comportamiento bien

definido (Booch et al., 2007: 76), se le considera un objeto como la instancia
de una clase debido a que es una copia que se hace a partir de una clase y
para identificarlo se le da un nombre. Los objetos son abstracciones que
forman parte del dominio del problema o del negocio,el cual representa un
ente de la vida real. Los objetos por ser un ente de la vida real tienen estado
y comportamiento, que se toman a partir de la definicin de la clase.

Herencia

La herencia es una tcnica de reutilizacin en el cual una clase hija hereda

todos los atributos y operaciones de una clase padre (Bruegge et al., 2002:
519). La herencia se realiza a partir de una subclase o clase hija que retoma
la lo que tiene definido la superclase o clase padre, adems puede agregar
nuevos atributos y operaciones para hacerla una clase ms especializada.
Cuando se aplica el concepto de jerarqua en las clases, aparecen otros,
como la herencia simple (cuando una subclase hereda los mtodos,
estructura y comportamiento de una superclase), herencia mltiple (cuando
una sub-clase hereda los mtodos, estructura y comportamiento de varias
superclases) y agregacin (el concepto de herencia pero visto en sentido
inverso; lo que significa que una subclase es parte de sta, es decir agregada
a una superclase), conceptos que tienen mucho que ver con los tipos de
relaciones que hay entre las clases.
Polimorfismo

La Real Academia espaola define polimorfismo como la cualidad de lo que

tiene o puede tener distintas formas. Desde la perspectiva de la orientacin
de objetos, el polimorfismo se puede aplicar en dos sentidos: uno es cuando
a partir de una clase se crean diferentes objetos y, el segundo, es cuando
una operacin puede tener diferente comportamiento (implementacin) en
cada una de las instancias.

Interfaz

Una interfaz es una coleccin de operaciones que se usan para especificar

un servicio de una clase o de un componente (Booch, Jacobson y Rumbaugh,
2006: 163). La interfaz de una clase captura slo su vista exterior, que abarca
nuestra abstraccin del comportamiento comn a todas las instancias de la
clase. En el lenguaje de programacin Java, una interface se considera un
contrato en donde la clase que la implementa est obligada a contener todos
los mtodos.

Tambin al definir en una arquitectura se le llaman interfaces a los puntos o

nodos que fungen como conexin entre dos componentes para entrar en
comunicacin. Y de forma ms general tambin una interface es aquel medio
con el que el usuario puede interactuar con el sistema o aplicacin.

En la prctica, esto significa que cada clase debe tener dos partes: una
interfaz y una implementacin. La interfaz de una clase captura slo su vista
exterior, que englobe nuestra abstraccin del comportamiento comn a todas
las instancias de la clase.

La implementacin de una clase comprende la representacin de la

abstraccin, as como los mecanismos necesarios para conseguir el
comportamiento deseado.

La interfaz de una clase es el nico lugar en el que afirman todas las acciones
que un cliente puede hacer sobre las instancias de la clase definidas, de esta
forma la aplicacin encapsula detalles que ningn cliente debe conocer.

Paquete

Los paquetes de servicios constituyen un elemento esencial para las

actividades de diseo e implementacin, las cuales ayudaran en la estructura
de los modelos de diseo e implementacin en trminos de subsistemas de
servicios (Ivar Jacobson, Los paquetes son una forma organizacional ya que
generalmente son directorios que contienen un conjunto de clases y/o
subpaquetes, agrupados por su funcionalidad o por el tipo de servicio que
prestan. Nosotros podemos tener varios paquetes en una aplicacin.

Para todos los problemas, el desarrollador debe decidir en donde declarar

cada clase y objeto, es decir, en que paquete debe estar. Para cualquier tipo
de negocio, por muy grande o pequeo que sea el software a construir, la
mejor solucin es agrupar clases relacionadas lgicamente en el mismo
mdulo.

Mensaje

Los objetos en un sistema se comunican con otros objetos y para ello utilizan
los mensajes. Un mensaje tpicamente es una llamada hacia una operacin
que un objeto invoca en otro objeto (Erikson Hans-Erick, et al., 2004: 145p).
Debido a esto los objetos pueden ser activados mediante la recepcin de
mensajes. Un mensaje realiza una peticin para que un objeto sea ejecutando
con una funcin en particular. La tcnica de enviar mensajes se conoce como
paso de mensajes. En casi todos los casos, el programador sabe qu tipo de
objetos y de dato se espera que reciba como argumento(s) de un mensaje y
tambin conoce el tipo de objeto de retorno.

2 MODELOS

Booch (1996) define la nocin a partir de que un sistema se analiza desde

diferentes puntos de vista, donde se describe cada vista por un nmero de
diagramas de modelo.

El mtodo tambin contiene un proceso por el cual se analiza el sistema, tanto

desde el aspecto macro y micro de desarrollo, y se basa en un proceso
basado en modelos altamente incremental e iterativo, para describir el
sistema.
 2.1 Diagramas de implementacin.

Los diagramas de implementacin representan la arquitectura fsica del

sistema.

Los diagramas de implementacin ofrecen una ilustracin de la arquitectura

fsica del hardware, del software y de los artefactos del sistema. Los
diagramas de implementacin pueden entenderse como lo contrario de los
casos de uso, porque ilustran la forma fsica del sistema, en lugar de
representar conceptualmente los usuarios y dispositivos que interactan con
el sistema.

Un diagrama de implementacin muestra:

Las dependencias entre las partes de cdigo del sistema (diagrama de
componentes)
Se utilizan para modelar la vista de implementacin esttica de un sistema.
La estructura del sistema en ejecucin (diagrama de despliegue): se utilizan
para modelar la vista de despliegue esttica.
2.2 Diagrama de Componentes.
Los diagramas de componentes describen los elementos fsicos del sistema y
sus relaciones.
Muestran las opciones de realizacin incluyendo cdigo fuente, binario y
ejecutable Ingeniera del Software.
Los componentes representan todos los tipos de elementos software que
entran en la fabricacin de aplicaciones informticas Pueden ser simples
archivos, paquetes, bibliotecas cargadas dinmicamente, etc. Ingeniera del
Software
La representacin grfica es la siguiente:
UML define cinco estereotipos estndar que se aplican a los componentes:
Executable: Especifica un componente que se puede ejecutar en un nodo.
Library: Especifica una biblioteca de objetos esttica o dinmica.
Table: Especifica un componente que representa una tabla de una base de
datos.
File: Especifica un componente que representa un documento que contiene
cdigo fuente o datos.
Document: Especifica un componente que representa un documento.
Ingeniera del Software

Las relaciones de dependencia se utilizan en los diagramas de componentes

para indicar que un componente se refiere a los servicios ofrecidos por otro
componente

Subsistemas
Los distintos componentes pueden agruparse en paquetes segn un criterio
lgico y con vistas a simplificar la implementacin

Son paquetes estereotipados en <<subsistemas>>

Los subsistemas organizan la vista de realizacin de un sistema

Cada subsistema puede contener componentes y otros
Subsistemas
La descomposicin en subsistemas no es necesariamente una,
descomposicin funcional.
La relacin entre paquetes y clases en el nivel lgico es el que existe entre
subsistemas y componentes en el nivel fsico.

Paquetes (Categoras) y clases en el nivel lgico. Paquetes (Subsistemas) y

componentes en el nivel fsico.

2.3 Diagramas de Despliegue / Distribucin

Los Diagramas de Distribucin muestran la disposicin fsica de los distintos

nodos que componen un sistema y el reparto de los componentes sobre
dichos nodos

Un nodo es un elemento fsico que existe en tiempo de ejecucin y

representa un recurso computacional, que generalmente tiene algo
de memoria y, a menudo, capacidad de procesamiento.
Los nodos se utilizan para modelar la topologa del hardware sobre el que
se ejecuta el sistema.
Representa tpicamente un procesador o un dispositivo sobre el que se
pueden desplegar los componentes.

Los componentes son los elementos que participan en la ejecucin de un

Sistema.

Los nodos son los elementos donde se ejecutan los componentes.

Los componentes representan el empaquetamiento fsico de los elementos

lgicos. Los nodos representan el despliegue fsico de los componentes.
La relacin entre un nodo y el componente que despliega puede mostrarse
con una relacin de dependencia, o listando los nodos desplegados en un
compartimiento adicional dentro del nodo.

Los estereotipos permiten precisar la naturaleza del equipo:

Procesadores: Nodo con capacidad de procesamiento. Puede

ejecutar un componente.

Dispositivos: Nodo sin capacidad de procesamiento. Representa

cualquier otro dispositivo hardware.

Los nodos se relacionan mediante conexiones bidireccionales (en

principio) que pueden a su vez estereotiparse.

Las conexiones se modelan como asociaciones, con todas las

caractersticas que implica.

Un artefacto es un producto del proceso de desarrollo de software, que puede

incluir los modelos del proceso.
Ejemplo: archivos fuente, ejecutables, documentos de diseo, reportes de prue
ba, prototipos, manuales de usuario y ms.
 2.4 Modelo de Prueba

Verificacin y Validacin:
Conjunto de procesos de comprobacin y anlisis que aseguran que el
software que se desarrolla est acorde a su especificacin y cumple las
necesidades de los clientes.

Verificacin:
Estamos construyendo el producto correctamente?

Se comprueba que el software cumple los requisitos funcionales y no

funcionales de su especificacin.

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.

Validacin:

Estamos construyendo el producto correcto?

Comprueba que el software cumple las expectativas que el cliente espera

Importante: Nunca se va a poder demostrar que el software est
completamente libre de defectos

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.
Prueba de unidades (prueba de mtodos y clases)
se prueba cada mtodo y clase de forma independiente

Se prueba cada componente individual de forma independiente (en OO

cada clase, con sus correspondientes mtodos). Encontrar fallos en mdulos
de forma aislada es mucho ms fcil que encontrarlos cuando ya se
encuentran ensamblados dentro de la aplicacin.

Pruebas de caja negra

En este tipo de pruebas, el elemento que se va a probar se entiende como

una caja negra de la que slo se conocen sus entradas y sus salidas. As, al
elemento bajo prueba se lo somete a una serie de datos de entrada, se
observan las salidas que produce y se determina si stas son conformes a la
entrada introducida.

Un conocido problema que se utiliza con frecuencia en el contexto de las

pruebas de software es el de la determinacin del tipo de un tringulo, que fue
originalmente propuesto por Bertrand Myers: adaptado a la orientacin a
objetos, se trata de probar una clase que dispone de una operacin que
calcula el tipo de un tringulo segn las longitud desde los lados. Esta
operacin devuelve un entero que representa si el tringulo es equiltero,
issceles, escaleno si no es un tringulo (porque tenga lados de longitud cero
o negativa, o porque la suma de dos lados sea menor o igual a la suma
del tercero).

Pruebas estructurales o de caja blanca

Las pruebas de caja blanca realizan,de alguna manera, un seguimiento del
cdigo fuente segn se van ejecutando los casos de prueba, de manera que
se determinan de manera concreta las instrucciones, bloques, etc. que han
sido ejecutados por los casos de prueba. As pues, mediante este tipo de
pruebas se puede saber cunto cdigo se ha recorrido.

As, en el mismo problema del tringulo que comentbamos antes, el ingeniero

de pruebas se fijar ahora en el cdigo que implementa su funcionalidad y
observar, para cada terna de entradas x1, x2, etc., el recorrido seguido por
los casos de prueba en la implementacin de la clase.

As, dependiendo de las ramas o caminos o nodos visitados por los casos de
prueba, el ingeniero estar ms o menos seguro de la buena, muy buena o
mediana calidad del software objeto de estudio. Existen formas muy
 variadas de medir esa cantidad de cdigo recorrido mediante lo que se
llaman criterios de cobertura.

Para Cornett, el anlisis de cobertura del cdigo es el proceso de:

Encontrar fragmentos del programa que no son ejecutados por los casos de
prueba.
Crear casos de prueba adicionales que incrementen la cobertura.
Determinar un valor cuantitativo dela cobertura (que es, de manera indirecta,
una medida de la calidad del programa).
Adicionalmente, el anlisis de cobertura tambin permite la identificacin
de casos de prueba redundantes, que no incrementan la cobertura.

Pruebas de integracin
Las pruebas de integracin se emplean para comprobar que las unidades de
prueba, que han superado sus pruebas de unidad, funcionan correctamente
cuando se integran, de manera que lo que se tiende a ir probando es la
arquitectura software. Durante la integracin, las tcnicas que ms se
utilizan son las de caja negra, aunque se pueden llevar a cabo algunas
pruebas de caja blanca para asegurar que se cubren los principales flujos
de comunicacin entre las unidades.

Pruebas de sistemas de informacin

En el contexto de la orientacin a objetos, las pruebas de integracin pre-

tenden asegurar que los mensajes que fluyen desde los objetos de una clase o
componente se envan y reciben en el orden adecuado en el objeto receptor,
as como que producen en ste los cambios de estado que se esperaban.

Localizar los fallos es un proceso complejo porque los fallos no

necesariamente se localizan cerca del punto en que se detectan. Para
localizar un fallo de un programa el programador responsable de la
depuracin tiene que disear programas de prueba adicionales que repitan el
fallo original y que ayudan a descubrir el origen del fallo.

En estos casos las herramientas de depuracin que permiten

rastrear el programa y visualizar los resultados intermedios es de una gran
ayuda.

Las herramientas de depuracin son habitualmente parte de las herramientas

de apoyo al lenguaje y que sirven de base al compilador. Proporcionan un
entorno especial de ejecucin que permiten acceder a las tablas de
 smbolos del compilador, a travs de ella a los valores de las variables del
programa.

Habitualmente, permiten controlar la ejecucin paso a paso sobre el cdigo del

programa.

Despus de que se descubre el origen del fallo en el programa, este debe

corregirse y entonces reevaluar el sistema. Esto implica repetir de nuevo las
pruebas anteriores (pruebas de regresin). Estas pruebas
se hacen para comprobar que los cambios introducidos resuelven
definitivamente el fallo y no introducen nuevos fallos. La estadstica muestra
que la reparacin de un fallo frecuentemente es incompleta y adems
introduce nuevos fallos.

3 PLAN DE IMPLEMENTACIN
Qu es un plan de implementacin de software?
3.1) Lineamientos para la instalacin e implantacin (diagrama de distribucin
y requerimientos del equipo)
https://es.slideshare.net/NAHAMA19/fase-de-implementacin-de-sistemas-
deinformacin?
next_slideshow=1

Este modelo es una coleccin de componentes y los subsistemas que los

contienen. Estos componentes incluyen: ficheros ejecutables, ficheros de
cdigo fuente, y todo otro tipo de ficheros necesarios para la implantacin y
despliegue del sistema.
Definir la organizacin del cdigo en trminos de subsistemas estructurados
en capas.
Implementar (codificar y estructurar) clases y objetivos en trminos de
componentes (cdigo fuente, ejecutables, bases de datos, etcteras.
Ejecutar pruebas de componentes como unidades.
Integrar los resultados producidos por desarrolladores individuales y
equipos en un sistema ejecutable.
5 Fases que se utilizan en la implementacin de software de aplicacin:

Preparar ambiente operacional y uno de prueba por separado.

Se entiende por ambiente o plataforma la combinacin especfica de
hardware y software que nos permite correr un sistema, por ambiente
operacional, la plataforma donde corre el sistema actual y por
ambiente de test o de prueba, la plataforma utilizada para desarrollar y
dar mantenimiento a los sistemas.
El tener el ambiente operacional y el de prueba separados permite
proteger el sistema y evitar problemas que pudieran daar los datos o
interrumpir las operaciones durante las tareas de prueba.
La plataforma operacional del sistema de informacin incluye las
configuraciones de hardware y software apropiadas, utilidades del
sistema, recursos de telecomunicaciones y otros componentes. A esta
plataforma operacional slo tienen acceso los usuarios bajo un control
estricto. Los analistas de sistemas y programadores no tienen acceso.
El ambiente de test reduciendo probablemente a una estacin de
trabajo o a un servidor, contiene copias de todos los programas y
procedimientos, as como de los archivos de datos de prueba.

Capacitar a los usuarios, administradores y tcnicos

A los usuarios debe ofrecrseles una visin general del sistema y los
trminos o palabras clave; los procedimientos de inicio y apagado del
sistema; el men principal y los submens; las funciones principales
del sistema; una gua para sacar adelante los problemas que se
presenten y una lista de preguntas frecuentes.
A los administradores, entre otros debe capacitrseles en la obtencin
de los objetivos del negocio, los principales reportes que ofrece el
sistema y como requerir mejoras al mismo.
Al equipo de TI se le debe entrenar en la arquitectura del sistema y su
documentacin, la resolucin de problemas y en el entrenamiento de
los usuarios y del personal administrativo.
Realizar conversin de datos y el cambio de sistema
Es una parte importante de la implantacin o instalacin del sistema y que
consiste en cargar en el nuevo sistema los datos existentes. Dependiendo
del sistema puede hacerse antes, durante o despus de completar el
ambiente operacional.
El proceso de cambio del sistema consiste en poner en lnea el nuevo sistema
y en retirar el anterior. Puede realizarse de forma directa en paralelo,
mediante un piloteo o por etapas intercaladas dependiendo del riesgo
implcito y del tiempo disponible para realizar la tarea
Efectuar una evaluacin luego de la instalacin
Una vez instalado el sistema, debe permitir observar la calidad del nuevo
sistema de informacin de forma integral. Se pone nfasis en determinar si
el sistema efectivamente cumple ciertos requisitos, permite lograr los
objetivos de los usuarios y produce los beneficios para los cuales fue
aprobado.

Presentar un reporte final a la administracin

Se realiza un reporte final que debe incluir las versiones definitivas de toda
la documentacin del sistema, las modificaciones o mejoras a realizar a
futuro que fueron detectadas, la recapitulacin de los presupuestos y
cronogramas utilizados durante la instalacin y los resultados de los test
correspondientes a la evaluacin final.

3.2) Manual Tcnico

Este documento contiene toda la informacin sobre los recursos utilizados por
el proyecto, llevan una descripcin muy bien detallada sobre las
caractersticas fsicas y tcnicas de cada elemento. Por ejemplo:
caractersticas de procesadores, velocidad, dimensiones del equipo,
garantas, soporte, proveedores y equipo adicional.
Su extensin depende de la cantidad de recursos y equipo utilizado y
generalmente se presenta en forma de fichas tcnicas en donde se describe
en cada una las caractersticas de cada recurso.
 Elaboracin del Manual Tcnico.
Un manual tcnico es aquel que va dirigido a un pblico con conocimientos
tcnicos sobre algn rea, mientras que, por ejemplo, un manual de usuario
va dirigido a un pblico ms general, el cual no necesariamente debe tener
conocimientos especficos en el rea de inters.
En este caso el manual tcnico, debe incluir:

1. Paradigma de programacin seleccionado y sus beneficios.

2. Lenguaje de programacin seleccionado y sus beneficios frente a otros
lenguajes.
3. Estandarizacin de cdigo utilizada.
4. Diseo del sistema.

3.3) Manual de Usuario

Un manual de usuario se trata de una gua que ayuda a entender el

funcionamiento de algo. Es un documento de comunicacin tcnica que
busca brindar asistencia a los sujetos que usan un sistema o servicio.
Elaboracin del Manual De Usuario.
Pasos del manual del usuario:
1. Portada: De que se trata el documento y quin lo elaboro?
2. Introduccin: Describe el uso del documento (para qu sirve?) y de qu
habla?
3. Anlisis y requerimientos del sistema (que se ocupa para poder instalarlo y
usarlo?)
3. Explicacin del funcionamiento: Debes de poner paso a paso y con pantallas
bien explicadas cmo funciona el programa
4. Glosario
Debe ser escrito de tal manera, que cualquier persona pueda entenderlo con la
menor dificultad posible.
Es recomendable, detallar todos aquellos pasos que se llevan a cabo para usar
el programa.
Especificar los alcances y las limitaciones que tiene el programa.
Un buen punto de partida para un manual de usuario, es hacer de cuenta que
las personas que lo van a leer no tienen el ms mnimo conocimiento sobre
computadores.
Resumen de:
https://americalatina.pmi.org/latam/KnowledgeCenter/Articles/~/media/3E9828
A63F904D00A32
4DAB09F41E1FC.ashx
4) Implementacin de Componentes
5) Integracin de subsistemas y sistemas

La integracin del sistema sigue el siguiente plan:

1.- Se deber definir la organizacin del cdigo, en trminos de
subsistemas de implementacin.
2.- Los subsistemas de implementacin son colecciones de
componentes y otros modelos de implementacin usados para
estructurar el modelo de implementacin.
3.- Se implementarn las clases y objetos definidos en el modelo de
diseo en la forma de componentes de software tales como archivos
fuente, binarios o ejecutables
4.- Se probarn los componentes desarrollados como unidades
En el flujo de trabajo de integracin de sistemas se realizan la
siguientes actividades:
Artefacto principal = Modelo de Implementacin.
1.- Planificar la integracin.- Es el proceso de examen y actualizacin
del plan de Integracin para asegurar que no quede obsoleto debido a
los cambios en la arquitectura o en el diseo del nuevo sistema
2.- Implementacin de los componentes.- Es el proceso que establece
que el artefacto principal producido es el componente.
3.- Integrar cada Subsistema.- Es el proceso que establece que los
principales artefactos producidos son la Construccin y el
Susbsistema de Implementacin.
 4.- Integrar el Sistema.- Es el proceso que establece que el artefacto
principal producido es la construccin donde la integracin envuelve
un alto grado de automatizacin.
5.- Artefactos para la implementacin (prototipo).- Son los artefactos
que se crean para la implementacin que capturan y presentan la
realizacin de la solucin del flujo de trabajo del Anlisis y Diseo.

Nota.
EN los temas en donde se mencionen diagramas, plante

https://www.altova.com/es/umodel/uml-deployment-diagrams.html

https://es.slideshare.net/zonickx/diagramas-de-implementacion

https://es.slideshare.net/techmi/curso-uml-25-diagramas-de-implementacin

https://es.slideshare.net/joshell/diagramas-uml-componentes-y-despliegue

https://es.slideshare.net/arcangelsombra/diagramas-de-despligue-uml-1475353?qid=16a5a9f8-
5194-4a1e-bdb0-77eb781b328f&v=&b=&from_search=2

http://www.ctr.unican.es/asignaturas/Ingenieria_Software_4_F/Doc/M7_09_VerificacionValidacio
n-2011.pdf

http://www.inf-cr.uclm.es/www/mpolo/asig/0708/phd/apuntesDoctorado.pdf
https://es.slideshare.net/Dolphinus/manuales-de-usuario-y-tecnico

https://americalatina.pmi.org/latam/KnowledgeCenter/Articles/~/media/3E9828A63F904D00A32
4DAB09F41E1FC.ashx

https://es.slideshare.net/joshell/diagramas-uml-componentes-y-despliegue

https://es.slideshare.net/TomRodriguez/implementacion-de-software

http://flanagan.ugr.es/docencia/2005-2006/2/apuntes/ciclovida.pdf

http://blogparaentregartareas.blogspot.mx/2011/04/ingenieria-de-software-manual-de.html

https://es.slideshare.net/zonickx/diagramas-de-implementacion

docencia.fca.unam.mx/~rcastro/T5-INFOVI.ppt