Desarrollo de Software
I nt r oducci ónaldesar r ol l odesof t war e
Evi denci adeapr endi z a j e Ti posdepr uebasyelpr ocesode mant eni mi ent o
Instrucciones: 1. De manera individual, analiza el caso de estudio dado por tu facilitador y describe los tipos de prueba que están utilizando. Justifica cada respuesta. . !demás analiza el proceso de mantenimiento que se su"iere en el caso de estudio y describe a que tipo pertenece. Justifica tu respuesta.
#!S$ D% %S&'DI$ Formamos parte de una empresa de desarrollo de software y somos parte del equipo responsable de generar las pruebas a todos los productos que nuestra empresa genere. La semana pasada fue una de las más complicadas debido a que el trabajo de varios proyectos se nos juntó, no estaba planeado que esto ocurriera, pero las circunstancias que se explican en cada caso nos obligaron a cumplir profesionalmente nuestra labor. A continuación se explican uno de los casos de los proyectos que atendimos. l cliente de este proyecto, !a pedido que se le adelante la demostración del código, ya que estará ausente por un viaje no previsto de "# d$as. l equipo de desarrollo !a invertido más !oras para lograr codificar la iteración planeada, algunas pruebas los programadores las aplicaron y en otras se nos !a pedido que les apoyemos, para de esta manera entregar la aplicación lo más confiable posible. stas son todas las pruebas que se lograron reali%ar entre el equipo de desarrollo y el equipo de pruebas. ".
&e probaron todos los componentes de los programas' clases, m(todos, objetos, atributos. sto fue reali%ado por cada programador que además correg$a el código inmediatamente.
). &e probó que cada interfa% funcionara de acuerdo a los requerimientos del cliente, mismos que se cotejaron para poder establecer los casos de prueba válidos. &e registraron los errores que ocurrieron fueron de este tipo' Algunas interfaces no funcionaron adecuadamente. *nconsistencias en la presentación de datos con respecto a las opciones del men+. . &e probó el módulo que ser$a entregado en esta interacción para que se integrara correctamente a la estructura del sistema y se probaron los módulos, liberados anteriormente, para verificar que la inserción del nuevo no causara conflicto a los existentes. -. or +ltimo, el d$a de la presentación, un representante del equipo de pruebas y el analista entregaron el avance al cliente, quien se !i%o acompa/ar de uno de los usuarios del sistema. Ambos evaluaron el nuevo módulo en una
computadora, que se preparó previamente para tal fin por el equipo de pruebas. l resultado de esta revisión fueron +nicamente defectos de interfa%, los cuales fueron oportunamente solucionados. #. La +ltima prueba se reali%ó en la empresa del cliente, en esta ocasión fueron los principales usuarios quienes probaron el software. 0a no se encontraron más defectos, lo cual nos permitió liberar el módulo. 1. 2espu(s de !aber liberado este módulo se concluyó con el sistema. La empresa !a sido contratada, por este a/o, para dar mantenimiento al software3 pues está proyectado que en este periodo, se renovarán las licencias del sistema operativo y del manejador de base de datos y posiblemente se tengan que !acer ajustes al software liberado.
(unto n)mero 1 los programadores que intervinieron en el caso, se apoyaron en' Pruebas de unidad: para probar pro"ramas o clases. Sirven para comprobar la funcionalidad de ob*etos o m+todos. o o
(ruebas del componente: se prueban las interfaces de los componentes. (ruebas del sistema: se prueba la inte"racin de todos los componentes.
Además' Pruebas de unidad: se encar"a de probar componentes del pro"rama, como m+todos o clases de ob*etos. Se tienen que dise-ar pruebas para revisar todas las operaciones asociadas, establecer y verificar el valor de todos los atributos y poner el ob*eto en todos los estados posibles.
4ambi(n cada programador deberá tener en cuenta' $b*etivo de la (rueba: &e focali%a en ejecutar cada módulo 5o unidad m$nima a ser probada, ej. 6 una clase7 lo que provee un mejor modo de manejar la integración de las unidades en componentes mayores. 8usca asegurar que el código funciona de acuerdo con las especificaciones y que el módulo lógico es válido. Descripcin de la (rueba: • • •
•
articionar los módulos en pruebas en unidades lógicas fáciles de probar. or cada unidad !ay que definir los casos de prueba 5pruebas de caja blanca7. ara esto los casos de prueba deben dise/arse de forma tal que se recorran todos los caminos de ejecución posibles dentro del código bajo prueba3 por lo tanto el dise/ador debe construirlos con acceso al código fuente de la unidad a probar. Los aspectos a considerar son los siguientes' 9utinas de excepción, 9utinas de error, :anejo de parámetros, ;alidaciones, ;alores válidos, ;alores l$mites, 9angos, :ensajes posibles.
&+cnica: • •
#riterio de #ompletitud: • •
4odas las pruebas planeadas !an sido ejecutadas. 4odos los defectos que se identificaron !an sido tenidos en cuenta.
#onsideraciones %speciales: ara la elaboración de pruebas unitarias en java se puede utili%ar el =>?*4 y
&.
(unto n)mero los programadores que intervinieron en el caso, se apoyaron en' Pruebas de componentes: se enfoca en demostrar que la interfaz de componente se comporte se")n la especificacin. %isten diferentes tipos de interfaz entre componentes de pro"rama y, en consecuencia, distintos tipos de error de interfaz. (or e*emplo:
'so incorrecto de la interfaz. /ala interpretacin de la interfaz. %rrores de temporizacin. ara tal efecto, cada programador deberá tener en cuenta' $b*etivo de la (rueba: •
*dentificar errores introducidos por la combinación de programas probados unitariamente.
•
2etermina cómo la base de datos de prueba será cargada. 0erificar que las interfaces entre las entidades eternas usuarios2 y las aplicaciones funcionan correctamente.
•
;erificar que las especificaciones de dise/o sean alcan%adas.
•
2etermina el enfoque para avan%ar desde un nivel de integración de las componentes al siguiente.
Descripcin de la (rueba: Describe cmo verificar que las interfaces entre las componentes de software funcionan correctamente. Determina cmo la base de datos de prueba será car"ada. •
2etermina el enfoque para avan%ar desde un nivel de integración de las componentes al siguiente.
•
2ecide qu( acciones tomar cuando se descubren problemas.
or cada
•
>tili%ar la t(cnica top@down. &e empie%a con los módulos de nivel superior, y se verifica que los módulos de nivel superior llaman a los de nivel inferior de manera correcta, con los parámetros correctos. >tili%ar la t(cnica down@top. &e empie%a con los módulos de nivel inferior, y se verifica que los módulos de nivel inferior llaman a los de nivel superior de manera correcta, con los parámetros correctos.
#riterio de #ompletitud: • •
4odas las pruebas planeadas !an sido ejecutadas. 4odos los defectos que se identificaron !an sido tenidos en cuenta.
#onsideraciones %speciales: ?inguna
(unto n)mero 3 •
los programadores que intervinieron en el caso, se apoyaron en'
Pruebas de rendimiento: Se aplican cuando el sistema 4a sido inte"rado completamente, con ellas es posible probar el rendimiento y confiabilidad. 5eneralmente consisten en aumentar la car"a 4asta que el sistema se vuelve inaceptable. 'na manera de descubrir defectos es dise-ar pruebas sobre los l6mites del sistema. %n las pruebas de rendimiento, si"nifica estresar el sistema al 4acer demandas que est+n fuera de los l6mites del dise-o del software. %sto se conoce como 7prueba de esfuerzo8.
ara tal efecto, cada programador deberá tener en cuenta' $b*etivo de la (rueba: ;erificar que el sistema funciona apropiadamente y sin errores, bajo estas condiciones de stress' •
:emoria baja o no disponible en el servidor.
•
:áximo n+mero de clientes conectados o simulados 5actuales o f$sicamente posibles7
•
:+ltiples usuarios desempe/ando la misma transacción con los mismos datos.
•
l peor caso de volumen de transacciones 5ver pruebas de desempe/o7.
9$&!S: La meta de las pruebas de stress tambi(n es identificar y documentar las condiciones bajo las cuales el sistema FALLA. Descripcin de la (rueba: Las pruebas de stress se proponen encontrar errores debidos a recursos bajos o completitud de recursos. oca memoria o espacio en disco puede revelar defectos en el sistema que no son aparentes bajo condiciones normales. tros defectos pueden resultar de incluir recursos compartidos, como bloqueos de base de datos o anc!o de banda de la red. Las pruebas de stress identifican la carga máxima que el sistema puede manejar. l objetivo de esta prueba es investigar el comportamiento del sistema bajo condiciones que sobrecargan sus recursos. ?o debe confundirse con las pruebas de volumen' un esfuer%o grande es un pico de volumen de datos que se presenta en un corto per$odo de tiempo. uesto que la prueba de esfuer%o involucra un elemento de tiempo, no resulta aplicable a muc!os programas, por ejemplo a un compilador o a una rutina de pagos. s aplicable, sin embargo, a programas que trabajan bajo cargas variables, interactivos, de tiempo real y de control de proceso.
Aunque muc!as pruebas de esfuer%o representan condiciones que el programa encontrará realmente durante su utili%ación, muc!as otras serán en verdad situaciones que nunca ocurrirán en la realidad. sto no implica, sin embargo, que estas pruebas no sean +tiles. &i se detectan errores durante estas condiciones BimposiblesC, la prueba es valiosa porque es de esperar que los mismos errores puedan presentarse en situaciones reales, algo menos exigentes. &+cnica: • •
•
>sar los scripts utili%ados en las pruebas de desempe/o. ara probar recursos limitados, las pruebas se deben correr en un servidor con configuración reducida 5o limitada7. ara las pruebas de stress restantes, deben utili%arse m+ltiples clientes, ya sea corriendo los mismos scripts o scripts complementarios para producir el peor caso de volumen de transacciones.
#riterio de #ompletitud: 4odas las pruebas planeadas !an sido ejecutadas y excedidas sin que el sistema falle. 5 si las condiciones en que el sistema falle ocurren por fuera de las condiciones especificadas7. #onsideraciones %speciales: • •
•
roducir stress en la red puede requerir !erramientas de red para sobrecargarla de tráfico. l espacio en disco utili%ado para el sistema debe ser reducido temporalmente para limitar el espacio disponible para el crecimiento de la 8ase de datos. &incroni%ación de varios clientes accediendo simultáneamente los mismos registros.
(untos n)mero y ;, los programadores que intervinieron en el caso, se apoyaron en' Pruebas de usuario: %ste tipo de pruebas son necesarias por la influencia del entorno de traba*o que tiene "ran efecto sobre la fiabilidad, el rendimiento, el uso y la robustez de un sistema. %n la práctica eisten tres tipos de pruebas de usuario: •
•
•
Pruebas alfa: las reali%a el usuario en presencia de personal de desarrollo del proyecto !aciendo uso de una máquina preparada para tal fin. Pruebas beta' las reali%a el usuario despu(s de que el equipo de desarrollo les entregue una versión casi definitiva del producto. Pruebas de aceptación: son las +nicas pruebas que son reali%adas por los usuarios, deciden si está o no listo para ser aceptado.
ara tales efectos, cada programador deberá tener en cuenta' Pruebas Alfa
$b*etivo de la (rueba: rueba de aceptación para detectar errores en el sistema bajo un ambiente controlado.
Descripcin de la (rueba: La verificación involucra la ejecución de partes o todo del sistema en ambientes simulados, con el fin de encontrar errores. La retroalimentación de esta fase produce cambios en el software para resolver los errores y fallas que se descubren. &+cnica: 9eali%ar las pruebas de sistema bajo las siguientes caracter$sticas' •
&e llevan a cabo en el lugar en donde fue desarrollado el &D,
•
n un ambiente controlado, en el cual el desarrollador está presente.
&e selecciona un grupo de usuarios para el alp!a test y se les pide trabajen con el sistema como parte de las pruebas. #riterio de #ompletitud: •
4odas las pruebas planeadas !an sido ejecutadas.
•
4odos los defectos que se identificaron !an sido tenidos en cuenta.
#onsideraciones %speciales: ?inguna
Pruebas Beta
$b*etivo de la (rueba: 9eali%ar la validación del sistema por parte de l usuario. Descripcin de la (rueba: rueba de aceptación donde La validación 5o pruebas beta7 involucra el uso del software en un ambiente real. &+cnica: •
&e selecciona un grupo de usuarios que ponen a trabajar el sistema en un ambiente real. >san el sistema en sus actividades cotidianas, procesan transacciones y producen salidas normales del sistema.
•
Las transacciones y personas que usan el sistema son reales y trabajan en su área de trabajo real.
•
l desarrollador no está presente.
•
Los usuarios están advertidos de que están usando un sistema que puede fallar.
•
Los usuarios reali%an pruebas a su antojo reali%ando uso de la aplicación.
#riterio de #ompletitud:
&e establece un periodo de pruebas beta en el que los errores detectados no sean de carácter cr$tico para el sistema. #onsideraciones %speciales: &e deben considerar mecanismos de comunicación entre los desarrolladores y los usuarios de manera que los errores detectados puedan ser corregidos. Prueba de Aceptación
$b*etivo de la (rueba: 2eterminación por parte del cliente de la aceptación o rec!a%o del sistema desarrollado. Descripcin de la (rueba: La prueba de aceptación es ejecutada antes de que la aplicación sea instalada dentro de un ambiente de producción. La prueba de aceptación es generalmente desarrollada y ejecutada por el cliente o un especialista de la aplicación y es conducida a determinar como el sistema satisface sus criterios de aceptación validando los requisitos que ! an sido levantados para el desarrollo, incluyendo a documentación y procesos de negocio. 8asado en esta prueba el cliente determina si acepta o rec!a%a el sistema stas pruebas están destinadas a probar que el producto está listo para el uso operativo. &uelen ser un subconjunto de las ruebas de &istema. &irve para que el usuario pueda validar si el producto final se ajusta a los requisitos fijados, es decir, si el producto está listo para ser implantado para el uso operativo en el entorno del usuario. sta prueba es complementada por la prueba de estilo. &+cnica: 9eali%ación de los documentos de planes de prueba de aceptación y especificación de los mismos, basados en los criterios de aceptación del cliente. Los casos prueba de aceptación !an de ser planificados, organi%ados y formali%ados de manera que se determine el cumplimiento de los requisitos del sistema. ara la reali%ación de estas pruebas se necesita disponer de los siguientes documentos' •
specificación de requisitos del sistema.
•
:anual de usuario.
•
:anual de administrador.
9eali%ar ruebas de estilo
#riterio de #ompletitud: •
4odas las pruebas planeadas !an sido ejecutadas.
•
4odos los defectos que se identificaron !an sido tenidos en cuenta.
#onsideraciones %speciales: Las ruebas de Aceptación se suelen reali%ar en u n entorno de pre@producción. !demás de estas pruebas siempre se realizan por el equipo de traba*o de la empresa en desarrollo de S<, otra serie de pruebas, que a consideracin de los involucrados #liente y pro"ramador2, el tiempo de desarrollo para el S<= pueden llevarse a cabo para una &$&!> satisfaccin de los involucrados #liente y pro"ramador2, estas son: •
•
(ruebas de Sistema' Las pruebas del sistema deben enfocarse en requisitos que puedan ser tomados directamente de casos de uso y reglas y funciones de negocios. l objetivo de estas pruebas e s verificar el ingreso, procesamiento y recuperación apropiado de datos, y la implementación apropiada de las reglas de negocios. ste tipo de pruebas se basan en t(cnicas de caja negra, esto es, verificar el sistema 5y sus procesos internos7, la interacción con las aplicaciones que lo usan v$a E>* y anali%ar las salidas o resultados. (rueba de inte"racin: o
2escribe cómo verificar que las interfaces entre las componentes de software funcionan correctamente.
o
2etermina cómo la base de datos de prueba será cargada.
o
2etermina el enfoque para avan%ar desde un nivel de integración de las componentes al siguiente.
o
2ecide qu( acciones tomar cuando se descubren problemas.
or cada
(rueba de re"resin: n esta prueba se vuelve a probar el sistema a la lu% de los cambios reali%ados durante el debugging, mantenimiento o desarrollo de la nueva versión del sistema buscando efectos adversos en otras partes. •
(ruebas de ?umo Smo@e &estin" o !d ?oc2: 4oma (ste nombre debido a que su objetivo es probar el sistema constantemente buscando que saque B!umoC o falle. n algunos proyectos este tipo de prueba va junto con las pruebas funcionales. ermite detectar problemas que por lo regular no son detectados en las pruebas normales. Algunas veces, si las ruebas ocurren tarde en el ciclo de desarrollo está será una forma de garanti%ar el buen desarrollo. Las pruebas de !umo ? &? ex!austivas, pero van de extremo a extremo de la aplicación.
•
(ruebas de Desempe-o: Las pruebas de desempe/o miden tiempos de respuesta, $ndices de procesamiento de transacciones y otros requisitos sensibles al tiempo. l objetivo de las pruebas de desempe/o es verificar y validar los requisitos de desempe/o que se !an especificado 5en este caso, el desempe/o ofrecido por el proponente7. Las pruebas de desempe/o usualmente se ejecutan varias veces, utili%ando en cada una, carga diferente en el sistema. La prueba inicial debe ser ejecutada con una carga similar a la esperada en el sistema. >na segunda prueba debe !acerse utili%ando una carga máxima. Adicionalmente, las pruebas de desempe/o pueden ser utili%adas para perfilar y refinar el desempe/o del sistema como una función de condiciones tales como carga o configuraciones de !ardware.
Las principales actividades son' o
o
oner a punto el sistema para mejorar las m(tricas de desempe/o y proyectar la capacidad futura de carga del sistema.
Los objetivos de nivel de servicio definidos deben guiar la prueba de performance. Algunas caracter$sticas que afectan el desempe/o son' o
rrores lógicos
o
rocesamiento ineficiente
o
2ise/o pobre' muc!as interfaces, instrucciones y entradassalidas.
o
o canales de entradasalida
o
&alidas del sistema
o
4iempos de respuesta
o
o
4asa de entradasalida de datos
o
?+mero de transacciones que pueden ser manejadas simultáneamente.
Las pruebas de desempe/o utili%an las t(cnicas de caja blanca y caja negra. •
•
(ruebas de #ar"a: Las pruebas de carga miden la capacidad del sistema para continuar funcionando apropiadamente bajo diferentes condiciones de carga. La meta de las pruebas de carga es determinar y asegurar que el sistema funciona apropiadamente a+n más allá de la carga de trabajo máxima esperada. Adicionalmente, las pruebas de carga eval+an las caracter$sticas de desempe/o 5tiempos de respuesta, tasas de transacciones y otros aspectos sensibles al tiempo7. (ruebas de 0olumen' Las pruebas de volumen !acen referencia a grandes cantidades de datos para determinar los l$mites en que se causa que el &istema falle. 4ambi(n identifican la carga máxima o volumen que el sistema puede manejar en un per$odo dado. or ejemplo, si el sistema está procesando un conjunto de registros de 8ase de datos para generar un reporte, una prueba de volumen podr$a usar u na 8ase de datos de prueba grande y verificar que el sistema se comporta no rmalmente y produce el reporte correctamente. l objetivo de esta prueba es someter al sistema a grandes vol+menes de datos para determinar si el mismo puede manejar el volumen de datos especificado en sus requisitos. Algunos ejemplos de escenarios de prueba de vol+menes'
•
o
>n compilador puede ser alimentado por un programa para compilar que sea absurdamente grande.
o
>n editor de nexos puede recibir un programa que contenga miles de módulos.
o
>n simulador de circuito electrónico puede recibir un circuito dise/ado con miles de componentes.
uesto que obviamente, la prueba de volumen es una prueba costosa, tanto en tiempo de máquina como en personal, se debe tratar de no exceder los l$mites. &in embargo, todo programa deber$a ser expuesto, al menos, a algunas pruebas de volumen (ruebas de Aecuperacin y &olerancia a fallas: stas pruebas aseguran que una aplicación o sistema se recupere de una variedad de anomal$as de !ardware, software o red con p(rdidas de datos o fallas de integridad.
Las pruebas de tolerancia a fallas aseguran que, para aquellos sistemas que deben mantenerse corriendo, cuando una condición de falla ocurre, los sistemas alternos o de respaldo pueden tomar control del sistema sin p(rdida de datos o transacciones. Las pruebas de recuperación son contrarias a las pruebas en que la aplicación o sistema es expuesto a condiciones extremas 5o condiciones simuladas7, tales como fallas en dispositivos en entradasalida o llaves o apuntadores inválidos de base de datos. Los procesos de recuperación se invocan y la aplicación es monitoreada yo inspeccionada para verificar que (stos mecanismos se !an ejecutado en forma apropiada.
•
•
•
•
l objetivo de esta prueba es determinar la !abilidad del sistema para recuperarse de una falla de !ardware o software. sta prueba eval+a las caracter$sticas de contingencia construidas en el sistema para procesar interrupciones y para volver a puntos espec$ficos en el ciclo de procesamiento del sistema. La recuperación debe ser considerada en el proceso de dise/o. rrores de programación o de datos pueden ser incorporados ex profeso en un sistema para determinar si se puede recuperar de ellos. Las fallas de equipo 5por ejemplo errores de paridad en memoria, errores en dispositivos de entradasalida7 pueden ser simuladas (rueba de /)ltiples Sitios: l propósito de esta prueba es evaluar el correcto funcionamiento del sistema o subsistema en m+ltiples instalaciones. (rueba de #ompatibilidad y #onversin: l propósito es demostrar que los objetivos de compatibilidad no !an sido logrados y que los procedimientos de conversión no funcionan. La mayor$a de los programas que se desarrollan no son completamente nuevos3 con frecuencia son reempla%os de partes deficientes, ya sea de sistemas de procesamiento de datos, o sistemas manuales.
&eguridad del sistema, incluyendo acceso a datos o Funciones de negocios y &eguridad del sistema, incluyendo ingresos y accesos remotos al sistema.
Las pruebas de seguridad de la aplicación garanti%an que, con base en la seguridad deseada, los usuarios están restringidos a funciones espec$ficas o su acceso está limitado +nicamente a los datos que está autori%ado a acceder. or ejemplo, cada usuario puede estar autori%ado a crear nuevas cuentas, pero sólo los administradores pueden borrarlas. &i existe seguridad a nivel de datos, la prueba garanti%a que un usuario Bt$picoC " puede ver toda la información de clientes, incluyendo datos financieros3 sin embargo, el usuario ) solamente puede ver los datos institucionales del mismo cliente. Las pruebas de seguridad del sistema garanti%an que solamente aquellos usuarios autori%ados a acceder al sistema son capaces de ejecutar las funciones del sistema a trav(s de los mecanismos apropiados. 2ebido a la creciente preocupación de la sociedad por la privacidad de la información, muc!os programas tienen objetivos espec$ficos de seguridad. l objetivo de esta prueba es evaluar el funcionamiento correcto de los controles de seguridad del sistema para asegurar la integridad y confidencialidad de los datos. l foco principal es probar la vulnerabilidad del sistema frente a accesos o manipulaciones no autori%adas. >na manera de encontrar esos casos de prueba es estudiar problemas conocidos de seguridad en sistemas similares y tratar de mostrar la existencia de problemas parecidos en el sistema que se examina.
•
Algunas consideraciones de prueba son'
•
•
actividades que podr$an ocurrir durante un periodo de un a/o deber$an ejecutarse. *ncluyendo todos los ciclos y eventos diarios, semanales y mensuales que sean datos sensitivos, como las agendas. (ruebas de 5'I: La prueba de interfa% de usuario verifica la interacción del usuario con el software. l objetivo es asegurar que la interfa% tiene apropiada navegación a trav(s de las diferentes funcionalidades. Adicionalmente, las pruebas de interfa% aseguran que los objetos de la interfa% a ser probada se encuentra dentro de los estándares de la industria. (ruebas de #onfi"uracin: stas pruebas verifican la operación del sistema en diferentes configuraciones de !ardware y software. n la mayor$a de los ambientes de producción, las especificaciones para las estaciones de trabajo, equipos de red y servidores pueden variar. Las estaciones pueden tener diferentes versiones de software instaladas 5&istemas perativos, 2rivers, etc7 y en cualquier momento, pueden llegar a utili%arse diferentes combinaciones. so 5o funciones de negocio7, y las reglas del negocio. Las metas de estas pruebas son' o o
;erificar la apropiada aceptación de datos, ;erificar el procesamiento y recuperación y la implementación adecuada de las reglas del negocio.
ste tipo de pruebas están basadas en t(cnicas de caja negra, que es, verificar la aplicación 5y sus procesos internos7 mediante la interacción con la aplicación v$a E>* y anali%ar la salida 5resultados7. Lo que se identifica a continuación es un dise/o preliminar de las pruebas recomendadas para cada aplicación. •
•
(rueba de Documentacin (rocedimiento: valuar la exactitud y claridad de la documentación del usuario y para determinar si el manual de procedimientos trabajará correctamente como una parte integral del sistema. :uc!os defectos son identificados cuando un probador competente c!equea totalmente los manuales y documentación del usuario. :uc!os programas son parte de sistemas mayores, no completamente automati%ados, que contienen procedimientos reali%ados por operadores.
(unto n)mero E los programadores que intervengan en el caso, se apoyarán en' %l proceso de mantenimiento consiste en cambiar un sistema despu+s de que +ste se entre"= "eneralmente se aplica a software 4ec4o a la medida y los cambios consisten desde la simple correccin de errores, 4asta me*oras si"nificativas para corre"ir errores de especificacin o bien, a"re"ar nuevos requerimientos. %isten tres tipos de mantenimiento de software:
1. Aeparacin de fallas. %rrores de codificacin, dise-o o requerimientos, siendo estos )ltimos los más costosos de corre"ir. . !daptacin ambiental. %s necesario cuando al")n aspecto del entorno del sistema como 4ardware, plataforma operativa o al")n otro elemento 4acer cambiar al software. %l sistema debe modificarse para que se adapte a dic4os cambios. 3. !dicin de funcionalidad. %ste tipo de mantenimiento es necesario cuando los requerimientos funcionales cambian por al")n factor or"anizacional o empresarial. 5eneralmente este tipo de cambios es más "rande que los anteriores. #omo podemos darnos cuenta, la adaptación es una palabra clave en el proceso del mantenimiento al software= ya que lo que se busca es 4acer que +ste se adapte cada vez más a la solucin de las necesidades del ser 4umano, por ello desde la reparacin de fallas, los a*ustes al conteto ambiental en e l que se encuentra o simplemente a"re"arle mayor funcionalidad, son actividades que convertirán al software en una verdadera 4erramienta de traba*o para la 4umanidad. ara el mantenimiento, el programador deberá tener en cuenta' Case de mantenimiento &e centra en el cambio' • •
•
•
&e encuentran cuatro tipos de cambio' o o o
revención l software sufrirá cambios a lo largo de su vida +til. stos cambios pueden ser debidos a tres causas' o
• • •
Gue, durante la utili%ación, el cliente detecte errores en el software' los errores latentes. Gue se produ%can cambios en alguno de los componentes del sistema. Gue el cliente requiera modificaciones funcionales no contempladas en el proyecto.
C'%9&%S D% #$9S'>&!: 4ttp:FFin"Gsw.blo"spot.mFHH;FHFtiposGdeGpruebasGdeGsoftware.4tml 4ttp:FFwww.ctr.unican.esFasi"naturasFIn"enieriaSoftwareCFDocF/HK0erificacion0ali
