TABLA DE CONTENIDOS

INTRODUCCIN
CAJA NEGRA
o Qu son las pruebas de caja negra?
o Descripcin de las pruebas de caja negra
o Limitaciones de las pruebas de caja negra
TIPOS DE MANTENIMIENTO
TECNICAS DE MANTENIMIENTO
o Definicin formal de reingeniera
o Redocumentacin:
o Ingeniera inversa y reingeniera:
o Ingeniera inversa. Beneficios
CONCLUSIN
ANEXOS




















INTRODUCCIN

El mantenimiento del software es una importante tarea que
habitualmente requiere entre el 70% y 80% del coste del ciclo de vida del
producto. Esto es debido a mltiples factores, entre los que podemos
encontrar:

Inexistencia de mtodos, tcnicas y herramientas que puedan
proporcionar una solucin global al mantenimiento. La complejidad de los
sistemas se incrementa paulatinamente por la realizacin de continuas
modificaciones. La documentacin del sistema es defectuosa e inexistente. Se
considera el mantenimiento como una actividad poco creativa, a diferencia del
desarrollo. Las actividades de mantenimiento se suelen realizar bajo presin de
tiempo. Poca participacin del usuario durante el desarrollo del sistema.

El mantenimiento de software es tambin una de las fases en el ciclo de
vida de desarrollo de sistemas (SDLC, sigla en ingls de system development
life cycle), que se aplica al desarrollo de software. La fase de mantenimiento es
la fase que viene despus del despliegue (implementacin) del software en el
campo.

La fase de mantenimiento de software involucra cambios al software
para corregir defectos encontrados durante su uso o la adicin de nueva
funcionalidad mejorando la usabilidad y aplicabilidad del software.













CAJA NEGRA

Qu son las pruebas de caja negra?

Existen muchas dudas con las pruebas funcionales de caja negra. Es
un concepto algo abstracto en relacin a este campo. Vamos a despejar las
dudas

Las pruebas de caja negra son, ni ms ni menos que, pruebas
funcionales dedicadas a mirar en el exterior de lo que se prueba. Estas
pruebas se denominan de varias formas, pruebas de caja opaca, pruebas de
entrada/salida, pruebas inducidas por datoslos sinnimos son muchos y muy
variados.

En Globe contamos con un grupo experto en la realizacin de pruebas
de caja negra que solventar tus problemas a nivel de datos externos.

Descripcin de las pruebas de caja negra

Las pruebas de caja negra se centran principalmente en lo que se
quiere de un mdulo, charter o seccin especfica de un software, es decir, es
una manera de encontrar casos especficos en ese modulo que atiendan a su
especificacin.

Las pruebas de caja negra se limitan a que el tester pruebe
con datos de entrada y estudie como salen, sin preocuparse de lo que ocurre
en el interior.



stas, principalmente, se centran en mdulos o charters de interfaz de
usuario (pantalla, ficheros, canales de comunicacin) pero suelen ser tiles
en cualquier mdulo ya que todos o la mayora tienen datos de entrada y salida
que se pueden comprobar y verificar.

Como cualquier otra prueba, las de caja negra se apoyan y basan en la
especificacin de requisitos y documentacin funcional, estos requisitos suelen
ser ms complejos que los internos, para ello realizaremos una cobertura de
especificacin que ser muy recomendable para conseguir probar el mayor
campo posible.

Limitaciones de las pruebas de caja negra

Lo ms deseable a la hora de realizar pruebas de caja negra es realizar
una cobertura completa, pero, en la mayora de los casos no es suficiente,
siempre hay quecombinarlas con pruebas de integracin, ya que por mucho
que funcionen los datos de entrada/salida, por dentro o en terceros sistemas,
pueden existir defectos que no se estn teniendo en cuenta. Estos defectos
pueden no acarrear problemas a corto plazo, pero a lo largo del tiempo
aparecern y como dicenes mejor el remedio que la enfermedad.

Por eso en Globe siempre recomendamos que se realicen todos los
tipos de pruebas, tanto de caja negra, como de integracin as como unas
buenas pruebas de regresin y de compatibilidad. Siempre las pruebas
funcionales tienen que estar completas y cubrir todas las funcionalidades
posibles, solo as, se conseguir una verdadera calidad del software y tus
clientes podrn respirar tranquilos.

Tipos de mantenimiento

A continuacin se sealan los tipos de mantenimientos existentes,
definidos tal y como se especifican para la metodologa de MTRICA:

Perfectivo: son las acciones llevadas a cabo para mejorar la calidad
interna de los sistemas en cualquiera de sus aspectos: reestructuracin
del cdigo, definicin ms clara del sistema y optimizacin del
rendimiento y eficiencia.
Evolutivo: son las incorporaciones, modificaciones y eliminaciones
necesarias en un producto software para cubrir la expansin o cambio
en las necesidades del usuario.
Adaptativo: son las modificaciones que afectan a los entornos en los
que el sistema opera, por ejemplo, cambios de configuracin del
hardware, software de base, gestores de base de datos,
comunicaciones, etc.
Correctivo: son aquellos cambios precisos para corregir errores del
producto software.

Cabe sealar que, de estos 4 tipos de mantenimiento, solamente el
correctivo y el evolutivo entran en el mbito de MTRICA versin 3, ya que los
otros dos requieren actividades y perfiles distintos a los del proceso de
desarrollo.

TECNICAS DE MANTENIMIENTO

Dentro de la ingeniera del software se proporcionan soluciones tcnicas
que permiten abordar el mantenimiento de manera que su impacto en coste
dentro del ciclo de vida sea menor. Las soluciones tcnicas pueden ser de tres
tipos:

Ingeniera inversa: Anlisis de un sistema para identificar sus
componentes y las relaciones entre ellos, as como para crear
representaciones del sistema en otra forma o en un nivel de abstraccin
ms elevado.
Reingeniera: Modificacin de un producto software, o de ciertos
componentes, usando para el anlisis del sistema existente tcnicas de
ingeniera inversa y, para la etapa de reconstruccin, herramientas de
ingeniera directa, de tal manera que se oriente este cambio hacia
mayores niveles de facilidad en cuanto a mantenimiento, reutilizacin,
comprensin o evolucin.
Reestructuracin del software: Cambio de representacin de un
producto software, pero dentro del mismo nivel de abstraccin.

El objetivos de estas tcnicas es proporcionar mtodos para reconstruir
el software, ya sea reprogramndolo, redocumentndolo, redisendolo, o
rehaciendo alguna/s caracterstica/s del producto. La diferencia entre las
soluciones descritas radica en cul es el origen y cul es el destino de las
mismas (producto inicial y/o producto final).

Grficamente, estas tres soluciones tcnicas se enmarcan en el ciclo de
vida de la siguiente manera:

FIGURA 4.5 RELACIONES ENTRE LOS TERMINOS ASOCIADOS CON LA
REINGENIERIA

La Ingeniera directa corresponde al desarrollo del software tradicional.
La Ingeniera Inversa es el proceso de anlisis de un sistema para identificar
sus componentes e interrelaciones y crear representaciones del sistema en
otra forma o a un nivel ms alto de abstraccin. La Reingeniera es el examen y
la alteracin de un sistema para reconstruirlo de una nueva forma y la
subsiguiente implementacin de esta nueva forma. La Reestructuracin es la
modificacin del software para hacerlo ms fcil de entender y cambiar.

La reingeniera hace referencia a un ciclo, esto es, se aplican tcnicas
de ingeniera inversa para conseguir representaciones de mayor abstraccin
del producto y sobre ellas se aplican tcnicas de ingeniera directa para
redisear o re implementar el producto.

Cualquiera de estas tcnicas se puede aplicar a lo largo de todas las
fases del ciclo de vida o bien entre algunas de sus fases.

Tambin existen otras tecnologas, como por ejemplo:

La remodularizacin: consiste en cambiar la estructura modular de un
sistema de forma que se obtenga una nueva estructura siguiendo los principios
del diseo estructurado.

Anlisis de la facilidad de mantenimiento: normalmente la mayor parte
del mantenimiento se centra relativamente en unos pocos mdulos del sistema.

Visualizacin: el proceso ms antiguo para la comprensin del
software.
Anlisis y mediciones: son importantes tecnologas que estudian
ciertas propiedades de los programas.

El mantenimiento de software o mantencin de software es una de las
actividades ms comunes en la ingeniera de software y es el proceso de
mejora y optimizacin del software despus de su entrega al usuario final (es
decir; revisin del programa), as como tambin correccin y prevencin de los
defectos.

El mantenimiento de software es tambin una de las fases en el ciclo de
vida de desarrollo de sistemas (SDLC, sigla en ingls de system development
life cycle), que se aplica al desarrollo de software. La fase de mantenimiento es
la fase que viene despus del despliegue (implementacin) del software en el
campo.

Definicin formal de reingeniera

Estamos entrando en el nuevo siglo, con compaas que funcionaron en
el XX con diseos administrativos del siglo XIX. Necesitamos algo enteramente
distinto.

Ante un nuevo contexto, surgen nuevas modalidades de administracin,
entre ellas est la reingeniera, fundamentada en la premisa de que no son los
productos, sino los procesos que los crean los que llevan a las empresas al
xito a la larga. Los buenos productos no hacen ganadores; los ganadores
hacen buenos productos. Lo que tienen que hacer las compaas es
organizarse en torno al proceso.

Las operaciones fragmentadas situadas en departamentos
especializados, hacen que nadie est en situacin de darse cuenta de un
cambio significativo, o si se da cuenta, no puede hacer nada al respecto, por
que sale de su radio de accin, de su jurisdiccin o de su responsabilidad. Esto
es consecuencia de un concepto equivocado de administracin organizacional.
Un proceso de negocios es un conjunto de actividades que reciben uno
o ms insumos para crear un producto de valor para el cliente.

Reingeniera significa volver a empezar arrancando de nuevo;
reingeniera no es hacer ms con menos, es con menos dar ms al cliente. El
objetivo es hacer lo que ya estamos haciendo, pero hacerlo mejor, trabajar ms
inteligentemente. Es redisear los procesos de manera que estos no estn
fragmentados. Entonces la compaa se las podr arreglar sin burocracias e
ineficiencias.

Propiamente hablando: reingeniera es la revisin fundamental y el
rediseo radical de procesos para alcanzar mejoras espectaculares en medidas
crticas y actuales de rendimiento, tales como costos, calidad, servicio y
rapidez.

Detrs de la palabra reingeniera, existe un nuevo modelo de negocios y
un conjunto correspondiente de tcnicas que los ejecutivos y los gerentes
tendrn que emplear para reinventar sus compaas.

Bajo el pensamiento tradicional de la administracin muchas de las
tareas que realizaban los empleados nada tena que ver con satisfacer las
necesidades de los clientes. Muchas de esas tareas se ejecutaban para
satisfacer exigencias internas de la propia organizacin de la empresa.

En el ambiente de hoy nada es constante ni previsible, ni crecimiento del
mercado, ni demanda de los clientes, ni ciclo de vida de los productos.

Tres fuerzas, por separado y en combinacin, estn impulsando a las
compaas a penetrar cada vez ms profundamente en un territorio que para la
mayora de los ejecutivos y administradores es desconocido. Estas fuerzas
son: clientes, competencia y cambio.

La reestructuracin del software modifica el cdigo fuente y/o los datos
en un intento de adecuarlo a futuros cambios. Tiende a centrarse en los
detalles de diseo de mdulos individuales y en estructuras de datos locales
definidas dentro de los mdulos.

Los beneficios de de la reestructuracin son:

Programas de mayor calidad con mejor documentacin y menos
complejidad, y ajustados a las prcticas y estndares de la ingeniera del
software moderno.
Reduce la frustracin entre ingenieros del software que deban trabajar
con el programa, mejorando por tanto la productividad y haciendo ms
sencillo el aprendizaje.
Reduce el esfuerzo requerido para llevar a cabo las actividades de
mantenimiento.
Hace que el software se mas sencillo de comprobar y depurar.

La reestructuracin se produce cuando la arquitectura bsica de la
aplicacin es slida, an cuando sus interioridades tcnicas necesiten un
retoque.

Los tipos de reestructuracin, bsicamente son 2: del cdigo y de datos.

INGENIERIA DIRECTA,INVERSA,REINGENIERIA Y REDOCUMENTACION.
Definici
n
Dise
o
Implemen
tacin


Ingeniera
directa (1)
Ingeniera
directa (2)


Reing.(6
)
Reing.(8)



Redocumen
tacin (5)
Redoc
ument
acin
Redoc
ument
acin
Redocumentacin:

Si el sistema funciona y la redocumentacin consume muchos recursos,
tal vez mejor no redocumentar. Si es preciso actualizar la documentacin, pero
recursos limitados, puede ser til documentar cuando se modifica. Con el
tiempo, se formar una coleccin de informacin interesante.

Si el sistema es fundamental para la organizacin, redocumentar por
completo. Se puede reducir la documentacin al mnimo.

Ingeniera inversa y reingeniera:

Objetivo: mtodos para reconstruir el sw:

Reprogramarlo.
redocumentarlo.
redisearlo.
rehacer alguna/s caracterstica/s del producto.

Ingeniera inversa: el proceso de construir especificaciones abstractas del
cdigo fuente de un sistema heredado, de manera que estas especificaciones
puedan ser utilizadas para construir una nueva implementacin del sistema
hacia delante.

Ingeniera inversa. Beneficios (Piattini et al. 96):

Reducir la complejidad del sistema.
Generar vistas alternativas.
Recuperar la informacin perdida (cambios que no se documentaron en
su momento).
Detectar efectos laterales.
Facilitar la reutilizacin.

Reingeniera: la modificacin de un producto sw., o de ciertos componentes,
usando para el anlisis del sistema existente tcnicas de ingeniera inversa y,
para la etapa de reconstruccin, herramientas de ingeniera directa.

CONCLUSIN

En un ambiente formal de desarrollo de software, la organizacin o
equipo de desarrollo tendrn algn mecanismo para documentar y rastrear
defectos y deficiencias. El Software tan igual como la mayora de otros
productos, es tpicamente lanzado con un conjunto conocido de defectos y
deficiencias. El software es lanzado con esos defectos conocidos porque la
organizacin de desarrollo en las utilidades y el valor del software en un
determinado nivel de calidad compensa el impacto de los defectos y
deficiencias conocidas.

Las deficiencias conocidas son normalmente documentadas en una
carta de consideraciones operacionales o notas de lanzamiento (release notes)
es as que los usuarios del software sern capaces de trabajar evitando las
deficiencias conocidas y conocern cundo el uso del software sera
inadecuado para tareas especficas.

Con el lanzamiento del software (software release), otros defectos y
deficiencias no documentados sern descubiertas por los usuarios del
software. Tan pronto como estos defectos sean reportados a la organizacin de
desarrollo, sern ingresados en el sistema de rastreo de defectos.

Las personas involucradas en la fase de mantenimiento de software
esperan trabajar en estos defectos conocidos, ubicarlos y preparar un nuevo
lanzamiento del software, conocido como un lanzamiento de mantenimiento, el
cual resolver los temas pendientes.











ANEXOS