Prueba de sistemas

Cualquier pieza de software completo, desarrollado o adquirido, puede verse como un sistema que debe probarse, ya sea para decidir acerca de su aceptacin, para analizar defectos globales o para estudiar aspectos especficos de su comportamiento, tales como seguridad o rendimiento. A ste tipo de pruebas donde se estudia el producto completo se les llama Pruebas de Sistema Uno de los objetivos de la fase de pruebas del sistema es verificar que el comportamiento externo del sistema software satisface los requisitos establecidos por los clientes y futuros usuarios del mismo. A medida que aumenta la complejidad de los sistemas software y aumenta la demanda de calidad, se hacen necesarios procesos y mtodos que permitan obtener buenos conjuntos de pruebas del sistema. Este trabajo describe los modelos necesarios para generar de manera sistemtica un conjunto de pruebas que permitan verificar la implementacin de los requisitos funcionales de un sistema software.

Sistema de Pruebas
Un sistema de pruebas implica la operacin o aplicacin del mismo a travs de condiciones controladas y la consiguiente evaluacin de la informacin. Las condiciones controladas deben incluir tanto situaciones normales como anormales. El objetivo del sistema de pruebas es encontrar un error para determinar situaciones en donde algo pasa cuando no debe de pasar y viceversa. En una palabra, un sistema de pruebas est orientado a detectar. Para la planeacin de las pruebas que se van a aplicar al sistema evaluador, se integraron los distintos tipos de pruebas: - Pruebas de Caja Negra. El sistema de pruebas de caja negra no considera la codificacin dentro de sus parmetros a evaluar, es decir, que no estn basadas en el conocimiento del diseo interno del programa. Estas pruebas se enfocan en los requerimientos establecidos y en la funcionalidad del sistema. - Cajas blancas es un tipo de prueba de software que se realiza sobre las funciones internas de un mdulo. As como las pruebas de caja negra ejercitan los requisitos funcionales desde el exterior del mdulo, las de caja blanca estn dirigidas a las funciones internas. Entre las tcnicas usadas se encuentran; la cobertura de caminos (pruebas que hagan que se recorran todos los posibles caminos de ejecucin), pruebas sobre las expresiones lgico-aritmticas, pruebas de camino de datos (definicin-uso de variables), comprobacin de bucles (se verifican los bucles para 0,1 y n iteraciones, y luego para las iteraciones mximas, mximas menos uno y ms uno). Las pruebas de caja blanca se llevan a cabo en primer lugar, sobre un mdulo concreto, para luego realizar las de caja negra sobre varios subsistemas (integracin).

- Pruebas de Funcionalidad: Este tipo de pruebas examina si el sistema cubre sus necesidades de funcionamiento, acorde a las especificaciones de diseo. En ellas se debe verificar si el sistema lleva a cabo correctamente todas las funciones requeridas, se debe verificar la validacin de los datos y se deben realizar pruebas de comportamiento ante distintos escenarios. Estas pruebas deben estar enfocadas a tareas, a lmites del sistema, a condiciones planeadas de error y de exploracin. Para estas pruebas usamos los esquemas de pruebas de caja negra ya que nos interesa saber si funciona o no, independientemente de la forma en que lo haga. - Pruebas de Usabilidad: Las pruebas realizadas en este rubro tienen la finalidad de verificar que tan fcil de usar es un sistema. Las pruebas de usabilidad deben verificar aprendizaje (qu tan fcil es para los usuarios realizar tareas bsicas la primera vez que tienen contacto con el sistema), eficiencia (una vez que los usuarios han aprendido algo del sistema, que tan rpido pueden llevar a cabo las tareas), manejo de errores (cuntos errores comete el usuario, que tan graves son stos y que tan fcil es para el usuario recuperarse de ellos) y grado de satisfaccin (que tan satisfactorio es usar el sistema). Para obtener resultados realistas en este tipo de pruebas, es importante dejar que las personas que estn probando el sistema resuelvan los problemas que se les presentan por s mismos, ya que si uno los ayuda, ya est contaminando las pruebas. - Usuarios Comunes: Consideramos importante llevar a cabo pruebas con usuarios comunes ya que muchas veces los usuarios que realizan las pruebas en las empresas tienen experiencia anterior con sistemas similares. Esto significa que ya pudieran estar familiarizados con muchos aspectos del sistema y habra puntos del mismo que no se consideraran. Las pruebas realizadas por los usuarios comunes son de usabilidad y funcionalidad, ya que para hacer las evaluaciones de contenido se requiere de experiencia en el campo. - Desarrolladores: Las pruebas realizadas por los desarrolladores son pruebas de caja blanca y de integracin, con la finalidad de buscar errores a partir del conocimiento del cdigo fuente.

Prueba de sistemas orientado a objetos.

La metodologa de Pruebas Orientada a Objetos para el Ciclo de Vida Completo (en ingles "Full Life-Cycle Object-Oriented Testing", FLOOT) es una coleccin de tcnicas para verificar y validar software orientado a objetos. El ciclo de vida FLOOT, indica una amplia variedad de tcnicas que estan disponibles en todos los aspectos del desarrollo de software. La lista de tcnicas no pretende ser completa, por el contrario su objetivo es hacer explcito el hecho de que usted cuenta

con un amplio rango de opciones disponibles. Es importante entender que aunque el metdo FLOOT es presentado como una coleccin de fases secuenciales no necesariamente tiene que ser as: las tcnicas de FLOOT pueden ser aplicadas tambin con procesos agiles/evolutivos. La razn por la que presento FLOOT de una forma traditional es para volver explicito el hecho de que en realidad usted puede realizar pruebas en todos los aspectos del desarrollo de software no solamente durante la codificacin.

Descripcin La prueba verifica que el tem que se esta probando, cuando se Prueba de Caja-Negra dan las entradas apropiadas produce los resultados esperados. Prueba de Valores- Es la prueba de situaciones extremas o inusuales que el tem debe Frontera ser capaz de manejar. Es el acto de asegurar que una clase y todas sus instancias Prueba de Clases cumplen con el comportamiento definido. Prueba de Integracin Es el acto de asegurar que las clases, y sus instancias, conforman de Clases un software que cumple con el comportamiento definido. Una forma de revisin tcnica en la que el entregable que se Revisin de Cdigo revisa en el cdigo fuente. Prueba de Es el acto de validar que un componente funciona tal como est Componente definido. Prueba de Es el acto de asegurar que toda lnea de cdigo es ejercita al Cubrimiento menos una vez.

Tcnica FLOOT

Una revisin tcnica en la cual se inspecciona un modelo de diseo. Prueba de Regresin Es el acto de ejecutar casos de prueba de las sper clases, tanto de de Herencia forma directa como indirecta, en una subclase especifica. Consiste en realizar pruebas para verificar que un gran conjunto Prueba de Integracin de partes del software funcionan juntas. Consiste en realizar pruebas para verificar que un mtodo Prueba de Mtodo (funcin miembro) funciona tal como esta definido. Un tipo de inspeccin, que puede ser desde un revisin tcnica formal hasta un recorrido informal, realizado por personas Revisin de Modelos diferentes a las que estuvieron directamente involucradas en el desarrollo del modelo. Es el acto de asegurar que todos los caminos lgicos en el cdigo Prueba de Caminos se ejercitan al menos una vez. Es un proceso mediante el cual los usuarios trabajan a travs de Revisin de una coleccin de casos de uso, utilizando un prototipo como si Prototipos fuera el sistema real. El objetivo principal es probar si el diseo del prototipo satisface las necesidades de esos usuarios. La mejor forma de determinar si un modelo realmente refleja lo Demostrar con el que se necesita, o lo que se debe construir, es construyendo cdigo software basado en el modelo para mostrar que el modelo esta bien El acto de asegurar que los comportamientos previamente Prueba de Regresin probados todava trabajan como se espera luego que se han realizado cambios a la aplicacin. El acto de asegurar que el sistema funciona como se espera bajo Prueba de Stress grandes volmenes de transacciones, usuarios, carga y dems. Una tcnica de aseguramiento de la calidad en la cual el diseo de tu aplicacin es revisado de forma exhaustiva por un grupo de tus compaeros. Una revisin tpicamente se enfoca en la precisin, Revisin Tcnica calidad, facilidad de uso y completitud. A este proceso usualmente se le llama recorrido, inspeccin, o revisin de compaeros. Prueba de Escenarios Una tcnica de prueba en la cual una o mas personas validan un de Uso modelo siguiendo la lgica de los escenarios de uso. Consiste en probar la interfaz de usuario para garantizar que Prueba de Interfaz de cumple los estndares y requerimientos definidos. Usualmente se Usuario refiere a la prueba de interfaz de usuario grfica. Consiste en realizar pruebas para verificar que lneas especificas Prueba de Cajade cdigo funcionan tal como esta definido. Tambin se le conoce Blanca como prueba de caja-transparente. Revisin de Diseo

Adiestramiento (Training)
Ningn sistema puede ser exitoso sin el adiestramiento apropiado. El adiestramiento debe ser para los usuarios, los gerentes y los miembros del departamento de sistemas de informacin (I.S.). Todos los esfuerzos del desarrollo del sistema dependen de que las personas entiendan el sistema y puedan usarlo eficientemente. l primer paso es identificar quines debe recibir el o los adiestramientos y cul es el adiestramiento necesario para cada persona. Cada grupo (usuario, gerente y personal de I.S.) requiere una mezcla de conocimientos generales e informacin detallada para entender y usar el sistema.

Conversin de archivos
Despus de establecer el ambiente operacional del nuevo sistema y realizar los adiestramientos necesarios, se comienza el proceso de conversin, en el que se transfieren las operaciones del sistema de computadoras viejo al nuevo sistema. En la conversin de archivos los datos existentes se cargan al nuevo sistema. Esta conversin es un proceso costoso que requiere la participacin de los usuarios y del personal de I.S. Si es posible, se debe automatizar el proceso, exportando datos del viejo sistema e importndolos al nuevo. Se debe mantener estrictos controles de input durante el proceso, ya que los datos son muy vulnerables. Todas las medidas de control deben estar operando para proteger los datos de acceso no autorizado y ayudar a prevenir errores.

El Proceso De Adiestramiento
Hay que considerar a quin se va a adiestrar: Usuarios directos del sistema. Usuarios indirectos del sistema. Cada tipo de usuario tiene diferentes expectativas y habilidades. Normalmente, los trabajadores que ejercen el rol de instructor, son: Vendedores. Analistas que conocen el (los) sistema(s). Instructores externos.

 Instructores internos.

El Proceso De Soporte
Un Centro de Soporte a Usuarios (conocido tambin como Centro de Informacin), es un grupo de personas que estn en la capacidad de responder preguntas y asistir a los usuarios, dentro de una organizacin, en un amplio rango de necesidades en computacin.

En un Centro de Informacin, se ejecutan las siguientes tareas: Instalacin de nuevos HW y SW. Asistencia de consultas de los usuarios sobre 4GL. Extraccin de datos de grandes repositorios para PC. Asignacin de cuentas. Se responden preguntas bsicas. Se dan demostraciones de HW y SW. Se trabaja con los usuarios para proponer cambios en los sistemas.

Conversin De Sistemas
La conversin de sistemas es un proceso que no solo abarca la conversin del viejo al nuevo, sino tambin la interconexin de este con los dems SI de la empresa, ya que un sistema debe estar en constante comunicacin con el resto de la empresa. El proceso de conversin no solo abarca el cambio del sistema anterior al actual, sino tambin la interconexin entre el sistema que estamos instalando y los dems SI que posea la empresa, por ejemplo: si estamos implantacin un sistema de contabilidad en la empresa este debe ser plenamente compatible con el SI encargado de compras, ventas, inventario De lo contrario habra problemas en la transmisin de datos entre los departamentos, ocasionando graves prdidas para la empresa. Por eso este paso es de vital importancia, ya que puede significar la muerte del sistema porque a nadie le interesa un sistema que a pesar de ser bueno este aislado de los sistemas de la empresa. Por eso es importante tomar en cuenta los otros sistemas con que cuenta la empresa y estarn en comunicacin con el nuestro a la hora de establecer los requisitos del usuario. Otro inconveniente es que durante la instalacin del sistema se pueden descubrir nuevos errores no detectados durante la prueba del sistema generando sorpresas desagradables para los usuarios que se estn empezando a familiarizar con este nuevo sistema. Otro mtodo pero mas arriesgado es la conversin directa que implica desechar el anterior sistema e implantar de una vez el sistema nuevo. En este caso la empresa debe estar totalmente segura que el nuevo sistema esta libre de fallas, ya que en casi de existir un error es muy probable que el sistema colapse. Su ventaja es que los beneficios se vern de inmediatos, los costes de instalacin sern menores. Tambin es fundamental que los empleados estn plenamente capacitados para usar el nuevo sistema, debido a que la inexperiencia de los usuarios puede reducir el rendimiento del SI.

Y por ultimo esta la conversin piloto: esta es parecida a la conversin fases ya que se usa en sistemas grandes o sistemas que van a usarse en ms de una unidad de negocio o por varios departamentos. As este se puede ir implementando rea por rea para evaluar el comportamiento del sistema, buscar fallos y ver como es la relacin entre el sistema y los usuarios. Tambin esta estrategia reduce los riesgos pero igual a la conversin en fases se necesita mas tiempo para ver los beneficios que aportara el sistemas funcional. Despus de superada esta fase, y con el SI ya implementado solo restan la aceptacin definitiva del usuario del sistema, a partir de la cual la empresa se hace responsable de las posibles fallas del sistema en el futuro, la entrega de los manuales de usuarios y el cdigo fuente del sistema.

El Proceso De Instalacin
Es el proceso de sustituir el viejo Sistema de Informacin por el nuevo. Existen cuatro (4) tipos de procesos de instalacin:

A. Instalacin Directa:

B. Instalacin En Paralelo:

C. Instalacin De Localidades Individuales: (Con Instalacin Directa En Cada Localidad). Localidad n.

Localidad n + 1.

D. Instalacin Por Fases:

E. Conversin. Transformacin de estructuras de datos y modos de almacenamiento actuales en las estructuras propuestas Traduccin de archivos actuales al formato requerido por el nuevo sistema Ej.: De Libros a Disco o de Cobol a SQL Enfoques Paralela Directa Piloto Por fases Se debe elaborar plan de contingencia Se debe evaluar la conversin Cuenta de Registros Totales Financieros Establecidos Cifras de Control (no financieras)

F. Instalacin de Hardware y Software Determinar los requerimientos del sitio y controlar su preparacin Instalaciones fsicas

Instalaciones elctricas Piso Falso, Cielo Raso y Aire Acondicionado Seguridad

Instalar y Probar el Hardware Instalar y Probar el Software Determinar Requerimientos especiales

G. Adiestramiento de Usuarios (Tcnicos y Operativos) Consiste en capacitar al personal que va a operar y mantener los sistemas propuestos Personal a ser adiestrado: Mtodos Seminarios Simulacin Personal Directo Procedimental Usuarios Operadores de Sistemas

H. Elaboracin de la Documentacin Incluye una descripcin completa del sistema para la operacin y mantenimiento. Principales Manuales Informacin General dirigido a Gerentes y Directivos

de Usuario dirigido a Usuarios Directos, para el correcto uso del sistema

de Operaciones Dirigido a personal tcnico de Sistemas, a fin de facilitar el posterior mantenimiento Debe contener al menos DFDs, DD, DER, DED, y en general, la documentacin tcnica generada durante el desarrollo de la aplicacin

del Administrador del Sistema Dirigido a personal de administracin de sistemas Debe contener al menos esquema de Base de Datos y cronogramas para respaldos y recuperacin, indexamiento de base de datos, pasos para creacin de usuarios, entre otros.

I. Entrega al Usuario.

Tcnicas de Implantacin del sistema

Al iniciar un proceso de instalacin de un servidor hay que tener en cuenta dos elementos esenciales, el software que se va a instalar y el (los) usuario(s) que tendr(n) acceso.

Software
Los sistemas UNIX (entindase sistemas operativos UNIX, Linux, Solaris, BSD, etc.) traen todos sus propios instaladores. Algunos de ellos tienen varios tipos de instalacin dentro de las cuales las ms comunes son: Estacin de trabajo (Workstation) Servidor

 Avanzado Teniendo en cuenta estos tres tipos de instalacin posibles, debemos decidir a la hora de realizar la instalacin por cul de ellos nos vamos a ir. Al ser este un sitio enfocado hacia la seguridad, descartaremos la instalacin tipo estacin de trabajo y tipo servidor y elegiremos la avanzada. Antes de instalar un equipo es necesario saber para qu se va a utilizar (servidor web, servidor SQL, servidor de archivos, varios servicios en un mismo servidor, etc.). Partiendo del servicio que va a prestar la mquina, se deben tener en cuenta las siguientes recomendaciones: Instalar exclusivamente los servicios que se vayan a utilizar. Al configurar los servicios, se deben dejar corriendo como un usuario sin privilegios, nunca con privilegios de administrador. No instalar software extra como juegos, editores de texto herramientas que no sirvan para prestar el servicio para el cual la mquina fue designada. No activar los servicios instalados para que se inicien por defecto al encender la mquina (para esto utilizar trabajos programados). Para los servicios que manejen contraseas siempre se debe escoger la gestin de contraseas cifradas. Evitar la instalacin de cualquier tipo de cliente a menos que su uso sea esencial. Adicional a los servicios instalados para que el servidor pueda cumplir su labor es aconsejable instalar servicios de firewall, logging, IDS (Sistemas de Deteccin de Intrusos) e IPS (Sistemas de Proteccin contra Intrusos). Si el servidor va a ser gestionado de manera remota, se deben instalar solamente los servicios necesarios para realizar la gestin y siempre se deben escoger aquellos que utilicen comunicacin segura (cifrada) sobre los que no lo hacen (por ejemplo SSH sobre Telnet). Si el servidor no va a ser gestionado de manera remota, no se debe instalar ningn servicio de este tipo (SSH, Telnet, VNC, etc.). Toda instalacin de servidores debe ser cuidadosamente diseada desde el inicio y las tareas deben ser repartidas de acuerdo a las caractersticas de las mquinas y las necesidades de los usuarios. No es necesario que todos tengan sistemas de IDS

IPS, sin embargo esta labor la debe asumir al menos una de las mquinas que se encuentren en la red de servidores. Usuarios.

Los sistemas multiusuario tienen en general varias clases de usuarios, pero definiremos ac solamente dos:

Superusuarios: son aquellos que tienen poderes administrativos sobre la mquina (root por ejemplo) y por lo tanto pueden realizar cambios en la configuracin del equipo. Usuarios: son aquellos que no tienen acceso administrativo y solamente pueden hacer uso limitado de los recursos sin hacer grandes modificaciones a las configuraciones de las mquinas.

Durante el proceso de instalacin es obligatorio crear una contrasea para el superusuario que el sistema operativo ha creado. La creacin de otros usuarios debe estar estrictamente ligada a las personas que tendrn acceso al sistema y el uso que le darn. Bajo ninguna circunstancia deben crearse usuarios genricos para uso compartido ni tampoco deben crearse ms de los estrictamente necesarios. Algunas distribuciones crean usuarios y claves por defecto las cuales deben ser desactivadas apenas finaliza la instalacin.

Instalacin de un sistema software

La instalacin de programas computacionales (software) es el proceso por el cual nuevos programas son transferidos a un computador y, eventualmente, configurados, para ser usados con el fin para el cual fueron desarrollados. Un programa recorre diferentes fases de desarrollo durante su vida til: 1. Desarrollo: cada programador necesita el programa instalado, pero con las herramientas, cdigos fuente, bancos de datos y etc., para modificar el programa. 2. Prueba: antes de la entrega al usuario, el software debe ser sometido a pruebas. Esto se hace, en caso de software complejos, en una instalacin ad hoc. 3. Produccin: Para ser utilizado por el usuario final.

En cada una de esas fases la instalacin cumple diferentes objetivos. Se debe comprender que en castellano programa sirve para sealar tanto un guion o archivo ejecutable, ejemplo tal, como un conjunto de archivos que sirven un fin comn, ejemplo OpenOffice.org. Por eso usaremos el neologismo software para programas computacionales. Una instalacin exitosa es una condicin necesaria para el funcionamiento de cualquier software. Mientras ms complejo sea el software, es decir, entre otras caractersticas, mientras ms archivos contenga, mientras mayor la dispersin de los archivos y mientras mayor sea la interdependencia con otros software, mayor es el riesgo de alguna falla durante la instalacin. Si la instalacin falla aunque sea solo parcialmente, el fin que persigue la instalacin posiblemente no podr ser alcanzado. Por esa razn, sobre todo en casos de software complejo, el desarrollo de un proceso de instalacin confiable y seguro es una parte fundamental del desarrollo del software. La Desinstalacin de software es el proceso que elimina el software del computador. Para la instalacin de software se pueden aplicar las siguientes tcnicas bsicas:

Los archivos son simplemente copiados en algn lugar del directorio.

Este sistema es fcil e intuitivo, y el preferido en MacOS X. Un riesgo es que versiones ms antiguas hayan quedado abandonadas en algn otro lugar sin que nos demos cuenta. Se instala primero un instalador, el que posteriormente instala el software deseado.
El sistema operativo o algn software permanente se ocupan de

instalar un paquete de software con todos los archivos requeridos. Esto es un Sistema de gestin de paquetes.

Pasos para la instalacin de un sistema software.

 Verificacin de la compatibilidad: Se debe comprobar si se cumplen los requisitos para la instalacin en cuanto a hardware y software. A veces es necesario desinstalar versiones antiguas del mismo software. Verificacin de la integridad: Se verifica que el paquete de software es el original, esto se hace para evitar la instalacin de programas maliciosos. Creacin de los directorios requeridos: Para mantener el orden en el directorio cada sistema operativo puede tener un estndar para la instalacin de ciertos archivos en ciertos directorios. Ver por ejemplo Linux Standard Base. Creacin de los usuarios requeridos: Para deslindar responsabilidades y tareas se pueden o deben usar diferentes usuarios para diferentes paquetes de software. Concesin de los derechos requeridos: Para ordenar el sistema y limitar daos en caso necesario, se le conceden a los usuarios solo el mnimo necesario de derechos. Copia, desempaque y descompresin de los archivos desde el paquete de software: Para ahorrar Ancho de banda y tiempo en la transmisin por internet o espacio de Disco duro, los paquetes vienen empacados y comprimidos. Compilacin y enlace con las bibliotecas requeridas: En algunos casos no se puede evitar el complicado paso de la compilacin y enlace que a su vez tiene severos requerimientos de software al sistema. El enlace con bibliotecas requeridas puede ser un problema si en su instalacin no se acataron los standards establecidos. Configuracin: Por medio de archivos de configuracin se le da a conocer al software con que parmetros debe trabajar. Por ejemplo, los nombres de las personas que pueden usar el software, como verificar su clave de ingreso, la ruta donde se encuentran los archivos con datos o la direccin de nuestro proveedor de correo electrnico. Para sistemas complejos se debe desarrollar el Software Configuration Management. Definir las variables de entorno requeridas: Algunos comportamientos del software solo pueden ser determinados por medio de estas variables. Esto es parte de la configuracin, aunque es ms dinmica.

 Registro ante el dueo de la marca: Para el Software comercial a

veces el desarrollador de software exige el registro de la instalacin si se desea su servicio.

Soporte de sistemas:
Es un grupo de servicios que proveen asistencia para hardware, software u otros bienes electrnicos o mecnicos. En general, el servicio de soporte sirve para ayudar a resolver los problemas que puedan presentrseles a los usuarios, mientras hacen uso de servicios, programas o dispositivos. La mayora de las compaas que venden hardware o software, ofrecen servicio tcnico por telfono u otras formas online como e-mails o sitios web. El personal que se ocupa del soporte debe poseer habilidades tcnicas reales (tanto en hardware como en software) y la capacidad de saber escuchar a los usuarios y actuar como mediador. El soporte debe ser metdico y analtico y debe saber juzgar qu preguntas hacer al usuario. Asimismo, debe saber percibir el nivel de conocimiento informtico del usuario para saber usar mucho o poco vocabulario tcnico.

Mantenimiento de sistemas:
Cualquier esfuerzo de Ingeniera del Software (si termina con xito) acaba por producir un determinado producto software, orientado a satisfacer ciertos requisitos previamente establecidos. El mantenimiento en este contexto se entiende de manera general como las actividades de cambio de ese producto. Ahora bien, el cambio se puede entender de diferentes maneras. Comenzando por lo bsico, la definicin de Mantenimiento del Software del estndar IEEE 1219 es: El mantenimiento del

software es la modificacin de un producto software despus de la entrega para corregir fallos, para mejorar el rendimiento u otros atributos, o para adaptar el producto a un entorno modificado. Esta definicin implica que las actividades de mantenimiento de un producto comienzan en el tiempo slo despus de que el producto se ha entregado, es decir, despus de que el producto est en operacin. No obstante, en ocasiones se considera que algunas actividades de mantenimiento puede comenzar antes de la entrega del producto. Se puede considerar que ciertas actividades de mantenimiento comienzan antes de la entrega. Algunas de estas actividades son la planificacin de las actividades posteriores a la entrega, as como toda actividad orientada a facilitar el mantenimiento, como la revisin de la documentacin. No obstante, estas pueden considerarse actividades de preparacin para el mantenimiento, ms que de mantenimiento en s. Por ejemplo, Pigoski (1997) resalta que hay una necesidad de comenzar a considerar el mantenimiento desde el mismo momento en que comienza el desarrollo. El mantenimiento del software es la totalidad de las actividades necesarias para proporcionar soporte econmico (cost-effective) al sistema software. Estas actividades se desarrollan tanto antes como despus de la entrega. Las actividades previas a la entrega incluyen la planificacin de las operaciones posteriores a la entrega, planificacin del soporte y determinacin de la logstica. Las actividades posteriores a la entrega incluyen la modificacin del software, la formacin de usuarios, y la operacin de un help desk. Como se ve, hay una diferenciacin en las diferentes definiciones entre actividades pre- y post- entrega del software. Para clarificar los conceptos, en esta obra diferenciaremos entre actividades de mantenimiento propiamente dichas (posteriores a la entrega) y actividades de preparacin para el mantenimiento. El criterio para diferenciarlo de otras actividades es el hecho de la entrega del producto software. Se debe tener en cuenta que en ocasiones esa entrega es un acto formal dentro de un contrato, pero en muchas otras es una simple decisin de disponibilidad pblica de un grupo de desarrollo. Por ejemplo, en los proyectos de fuente abierto, desarrollados de manera voluntaria, el qu es una entrega lo determinan los propios desarrolladores cuando piensan que la funcionalidad implementada ha llegado a un determinado nivel. La gua SWEBOK2 considera que el mantenimiento ocurre durante todo el ciclo de vida, coincidiendo en su definicin con la de Pigoski antes mencionada.

Es importante resaltar que el concepto de mantenimiento del software difiere de la concepcin de mantenimiento en otras disciplinas de ingeniera. Esto es debido a que el software no se deteriora con el uso. En la ingeniera mecnica, el mantenimiento consiste en las acciones de reparacin necesarias para que la mquina o sistema mecnico siga funcionando. En la Ingeniera del Software, el mantenimiento tiene un significado ms amplio, cubriendo su adaptacin a necesidades

Tipos de mantenimiento: Mantenimiento correctivo:

A pesar de las pruebas y verificaciones que aparecen en etapas anteriores del ciclo de vida del software, los programas pueden tener defectos. El mantenimiento correctivo tiene por objetivo localizar y eliminar los posibles defectos de los programas. Un defecto en un sistema es una caracterstica del sistema con el potencial de causar un fallo. Un fallo ocurre cuando el comportamiento de un sistema es diferente del establecido en la especificacin. Entre otros, los fallos en el software pueden ser de: Procesamiento, por ejemplo, salidas incorrectas de un programa. Rendimiento, por ejemplo, tiempo de respuesta demasiado alto en una bsqueda de informacin. Programacin, por ejemplo, inconsistencias en el diseo de un programa. Documentacin, por ejemplo, inconsistencias entre la funcionalidad de un programa y el manual de usuario.

Mantenimiento adaptativo:
Este tipo de mantenimiento consiste en la modificacin de un programa debido a cambios en el entorno (hardware o software) en el cual se ejecuta. Estos cambios pueden afectar al sistema operativo (cambio a uno ms moderno), a la arquitectura fsica del sistema informtico (paso de una arquitectura de red de rea local a Internet/Intranet) o al entorno de desarrollo del software (incorporacin de nuevos elementos o herramientas como ODBC). La envergadura del cambio necesario puede ser muy diferente: desde un pequeo retoque en la estructura de un mdulo hasta tener que reescribir prcticamente todo el programa para su ejecucin en un ambiente distribuido en una red. Los cambios en el entorno software pueden ser de dos clases:

 En el entorno de los datos, por ejemplo, al dejar de trabajar con un sistema de ficheros clsico y sustituirlo por un sistema de gestin de bases de datos relacionales. En el entorno de los procesos, por ejemplo, migrando a una nueva plataforma de desarrollo con componentes distribuidos, Java, ActiveX, etc. El mantenimiento adaptativo es cada vez ms usual debido principalmente al cambio, cada vez ms rpido, en los diversos aspectos de la informtica: nuevas generaciones de hardware cada dos aos, nuevos sistemas operativos - versiones de los antiguos- que se anuncian regularmente, y mejoras en los perifricos o en otros elementos del sistema. Frente a esto, la vida til de un sistema software puede superar fcilmente los diez aos [Pressman, 1993].

Mantenimiento perfectivo:
Cambios en la especificacin, normalmente debidos a cambios en los requisitos de un producto software, implican un nuevo tipo de mantenimiento llamado perfectivo. La casustica es muy variada. Desde algo tan simple como cambiar el formato de impresin de un informe, hasta la incorporacin de un nuevo mdulo aplicativo. Podemos definir el mantenimiento perfectivo como el conjunto de actividades para mejorar o aadir nuevas funcionalidades requeridas por el usuario. Algunos autores dividen este tipo de mantenimiento en dos: Mantenimiento de Ampliacin: orientado a la incorporacin de nuevas funcionalidades. Mantenimiento de Eficiencia: que busca la mejora de la eficiencia de ejecucin. Este tipo de mantenimiento aumenta cuando un producto software tiene xito comercial y es utilizado por muchos usuarios, ya que cuanto ms se utiliza un software, ms peticiones de los usuarios se reciben demandando nuevas funcionalidades o mejoras en las existentes.

Mantenimiento preventivo:
Este ltimo tipo de mantenimiento consiste en la modificacin del software para mejorar sus propiedades (por ejemplo, aumentando su calidad y/o su mantenibilidad) sin alterar sus especificaciones funcionales. Por ejemplo, se pueden incluir sentencias que comprueben la validez de los datos de entrada, reestructurar los

programas para mejorar su legibilidad, o incluir nuevos comentarios que faciliten la posterior comprensin del programa. Este tipo de mantenimiento es el que ms partido saca de las tcnicas de ingeniera inversa y reingeniera. En algunos casos se ha planteado el Mantenimiento para la Reutilizacin, consistente en modificar el software (buscando y modificando componentes para incluirlos en bibliotecas) para que sea mas fcilmente reutilizable. En realidad este tipo de mantenimiento es preventivo, especializado en mejorar la propiedad de reusabilidad del software.

Actividades de mantenimiento:
El establecimiento de analogas entre el mantenimiento del software y el mantenimiento del hardware puede conducir a confusin, ya que el software, a diferencia del hardware, no se desgasta y, por tanto, la principal actividad asociada con el mantenimiento del hardware - reemplazar o reparar las piezas estropeadas o defectuosas - no es aplicable al software [Bardou, 1997]. Algunos autores ([McClure, 1992], [Bennet et al., 1991], [Harjani y Queille, 1992], [Briand et al., 1998]) han identificado diferentes tipos de actividades que se realizan en cada modificacin del software. [Basili et al, 1996] identifican las siguientes once actividades, que se realizan con cada modificacin del software: Anlisis de impacto y de costes/beneficios: se dedica esta actividad a analizar diferentes alternativas de implementacin y/o a comprobar su impacto en la planificacin, coste y facilidad de operacin. Comprensin del cambio: puede consistir en localizar el error y determinar su causa, o en comprender los requisitos de una mejora solicitada. Diseo del cambio: se refiere al diseo propuesto para el cambio, pudindose incluir un rediseo del sistema. Codificacin y pruebas unitarias: se codifica y prueba el funcionamiento de cada componente modificado. Inspeccin, certificacin y consultora: esta actividad se dedica a inspeccionar el cambio, comprobar otros diseos, reuniones de inspeccin, etc. Pruebas de integracin: se refiere a comprobar la integracin de los componentes modificados con el resto del sistema. Pruebas de aceptacin: en esta actividad, el usuario comprueba, junto al personal encargado del mantenimiento, la adecuacin del cambio a sus necesidades.

 Pruebas de regresin: en esta actividad se somete el software modificado a casos de pruebas previamente almacenados y por los que ya pas. Documentacin del sistema: se revisa y reescribe, en caso necesario, la documentacin del sistema para que se ajuste al producto software ya modificado. Otra documentacin (del usuario, por ejemplo): se revisa y reescribe, en caso necesario, los diferentes manuales de usuario y otra documentacin, excepto la documentacin del sistema. Otras actividades, como las dedicadas a la gestin del proyecto de mantenimiento.

Costes del mantenimiento:

Mltiples estudios sealan que el mantenimiento es la parte ms costosa del ciclo de vida del software. Est comprobado que el coste de mantenimiento de un producto software a lo largo de toda su vida til supone ms del doble que los costes de su desarrollo [Schach, 1992]. La tendencia es creciente con el paso del tiempo, tal como puede visualizar en la siguiente tabla, en la cual se indica el porcentaje que supone el mantenimiento respecto del coste total. Referencia Fechas % Mantenimiento

[Pressman, 1993]

aos 70 1976

35%-40%

[Lientz y Swanson, 1980]

60% 55%

[Pigoski, 1997] [Pressman, 1993] [Rock-Evans y Hales, 1990] [Schach, 1990]

1980-1984 Aos 80 1987

60% 67% 67%

1987

[Pigoski, 1997] [Frazer, 1992] [Pressman, 1993]

1985-1989 1990 Aos 90

75% 80% 90%

Evolucin de los costes de mantenimiento. Una causa directa de los grandes costes del mantenimiento es que el coste relativo aproximado de reparar un defecto aumenta considerablemente en las ltimas etapas del ciclo de vida del software [Boehm, 1981] de forma que la relacin entre el coste de detectar y reparar un defecto en la fase de anlisis de requisitos y en la fase de mantenimiento es de 1 a 100 respectivamente, como se observa en la figura siguiente.

Coste relativo aproximado de detectar y corregir defectos.

Bibliografas
http://geopelia.wordpress.com/2008/02/14/importancia-de-la-conversin-desistemas-en-la-implantacin-de-un-sistema-de-informacin/ http://es.wikipedia.org/wiki/Instalaci%C3%B3n_de_software http://www.monografias.com/trabajos12/insis/insis.shtml#in http://seguridad.wordpress.com/2006/05/17/instalacion-de-un-sistema/

Repblica Bolivariana de Venezuela. Ministerio del Poder Popular para la Defensa. Universidad Nacional Experimental Politcnica de la Fuerza Amada UNEFA Ncleo Portuguesa - Sede Guanare.

Integrantes: Andriluis Romero. C.I: 22.109.025 Daniel lvarez C.I: 20.600.051 Eduardo Urdaneta. C.I: 20.601.441 Jess Araujo C.I: 21.022.214 Helys Duran C.I: 24.025.929 Diana Prez C.I: 21.160.613 Seccin: A VIII Semestre Ing. de Sistemas.

Noviembre de 2011.