You are on page 1of 12

CBTIS 52 Diseño de sistemas

5. VERIFICAR EL SISTEMA DE OINFORMACIÓN


Prueba de Sistemas.

Dependiendo del tamaño de la Empresa que usara el Sistema y


el riesgo asociado a su uso, puede hacerse la elección de comenzar la
operación del Sistema solo en un área de la Empresa (como una
Prueba piloto), que puede llevarse a cabo en un Departamento o con
una o dos personas. Cuando se implanta un nuevo sistema lo
aconsejable es que el viejo y el nuevo funcionen de manera
simultánea o paralela con la finalidad de comparar los resultados que
ambos ofrecen en su operación, además dar tiempo al personal para
su entrenamiento y adaptación al nuevo Sistema.

Durante el Proceso de Implantación y Prueba se deben


implementar todas las estrategias posibles para garantizar que en el
uso inicial del Sistema este se encuentre libre de problemas lo cual se
puede descubrir durante este proceso y llevar a cabo las correcciones
de lugar para su buen funcionamiento.

Desdichadamente la evaluación de Sistemas no siempre recibe


la atención que merece, sin embargo cuando se lleva a cabo de
manera adecuada proporciona muchas informaciones que pueden
ayudar a mejorar la efectividad de los esfuerzos de desarrollo de
aplicaciones futuras.

El desarrollo de sistemas de software implica una serie de actividades


de producción en las que las posibilidades de que aparezca el fallo
humano son enormes. Los errores pueden empezar a darse desde el
primer momento del proceso, en el que los objetivos....pueden estar
especificados de forma errónea o imperfecta, así como [en]
posteriores pasos de diseño y desarrollo ...Debido a la imposibilidad
humana de trabajar y comunicarse de forma perfecta, el desarrollo de
software ha de ir acompañado de una actividad que garantice la
calidad.
Las pruebas del software son un elemento crítico para la garantía de
calidad del software y representa una revisión final de las
especificaciones, del diseño y de la codificación.
La creciente percepción del software como un elemento del sistema y
la importancia de los «costes» asociados a un fallo del propio sistema,
están motivando la creación de pruebas minuciosas y bien
planificadas. No es raro que una organización de desarrollo de
software emplee entre el 30 y el 40 por ciento del esfuerzo total de
un proyecto en las pruebas. En casos extremos, las pruebas del
software para actividades críticas (por ejemplo, control de tráfico
aéreo, control de reactores nucleares) puede costar de tres a cinco
veces más que el resto de los pasos de la ingeniería del software
juntos.

Lic. Verónica Navarro B.


CBTIS 52 Diseño de sistemas

Objetivos de las pruebas


1. La prueba es el proceso de ejecución de un programa con la
intención de descubrir un error.
2. Un buen caso de prueba es aquel que tiene una alta probabilidad
de mostrar un error no es cubierto hasta entonces.
3. Una prueba tiene éxito si descubre un error no detectado hasta
entonces.

Los objetivos anteriores suponen un cambio dramático de punto de


vista. Nos quitan la idea que, Normalmente, tenemos de que una
prueba tiene éxito si no descubre errores.
Nuestro objetivo es diseñar pruebas que sistemáticamente saquen a
la luz diferentes clases de Errores, haciéndolo con la menor cantidad
de tiempo y de esfuerzo. Si la prueba se lleva a cabo con éxito (de
acuerdo con el objetivo anteriormente establecido), descubrirá
errores en el software.
Como ventaja secundaria, la prueba demuestra hasta qué punto las
funciones del software parecen funcionar de acuerdo con las
especificaciones y parecen alcanzarse los requisitos de rendimiento.
Además, los datos que se van recogiendo a medida que se lleva a
cabo la prueba proporcionan una buena indicación de la fiabilidad del
software y, de alguna manera, indican la calidad del software como
un todo. Pero, la prueba no puede asegurar la ausencia de defectos;
sólo puede demostrar que existen defectos en el software.
Atributos de las pruebas
1. Una buena prueba tiene una alta probabilidad de encontrar un
error. Para alcanzar este objetivo, responsable de la prueba debe
entender el software e intentar desarrollar una imagen mental de
cómo podría fallar el software.
2. Una buena prueba no debe ser redundante. El tiempo y los
recursos para las pruebas son limitados. No hay motivo para
realizar una prueba que tiene el mismo propósito que otra. Todas
las pruebas deberán tener un propósito diferente (incluso si es
sutilmente diferente).
3 . En un grupo de pruebas que tienen propósito similar, las
limitaciones de tiempo y recursos pueden abogar por la ejecución
de sólo un subconjunto de estas pruebas. En tales casos, se
deberán emplear la prueba que tenga la más alta probabilidad de
descubrir una clase entera de errores.
4. Una buena prueba no debería ser ni demasiado sencilla ni
demasiado compleja. Aunque es posible a veces combinar una
serie de pruebas en un caso de prueba, los posibles efectos
secundarios de este enfoque pueden enmascarar errores. En
general, cada prueba debería realizarse separadamente.

Lic. Verónica Navarro B.


CBTIS 52 Diseño de sistemas

DEFINICÓN DE PRUEBAS
Las pruebas son un conjunto de actividades que se pueden
planificar por adelantado y llevar a cabo sistemáticamente.
Por esta razón, se debe definir en el proceso de la ingeniería del
software una plantilla para las pruebas del software: un conjunto de
pasos en los que podamos situar los métodos específicos de diseño
de casos de prueba.
Las pruebas comienzan a nivel de módulo’ y trabajan «hacia
fuera», hacia la integración de todo el sistema basado en
computadora. Según el momento, son apropiadas diferentes
técnicas de prueba.
La prueba la lleva a cabo el responsable del desarrollo del software
y (para grandes proyectos) un
grupo independiente de pruebas. La prueba y la depuración son
actividades diferentes, pero la depuración se debe incluir en
cualquier estrategia de prueba.
ESTRATEGIA DE PRUEBA
Una estrategia de prueba del software debe incluir pruebas de bajo
nivel que verifiquen que todos los pequeños segmentos de código
fuente se han implementado correctamente, así como pruebas de
alto nivel que validen las principales funciones del sistema frente a
los requisitos del cliente. Una estrategia debe proporcionar una
guía al profesional y proporcionar un conjunto de hitos para el jefe
de proyecto. Debido a que los pasos de la estrategia de prueba se
dan a la vez cuando aumenta la presión de los plazos fijados, se
debe poder medir el progreso y los problemas deben aparecer lo
antes posible.
Verificación y validación
La prueba del software es un elemento de un tema más amplio
que, a menudo, es conocido como verificación y validación (V&V).
La verificación se refiere al conjunto de actividades que aseguran
que el software implementa correctamente una función específica.
La validación se refiere a un conjunto diferente de actividades que
aseguran que el software construido se ajusta a los requisitos del
cliente.
La definición de V&V comprende muchas de las actividades a las
que nos hemos referido como garantía de calidad del software
La verificación y la validación abarcan una amplia lista de
actividades de calidad que incluye: revisiones técnicas formales,
auditorias de calidad y de configuración, monitorización de
rendimientos, simulación, estudios de factibilidad, revisión de la
documentación, revisión de la base de datos, análisis algorítmico,
pruebas de desarrollo, pruebas de validación y pruebas de

Lic. Verónica Navarro B.


CBTIS 52 Diseño de sistemas

Instalación. A pesar de que las actividades de prueba tienen un


papel muy importante en V&V, muchas otras actividades son
también necesarias.
La calidad se incorpora en el software durante el proceso de
ingeniería del software. La aplicación adecuada de los métodos y
de las herramientas, las revisiones técnicas formales efectivas y
una sólida gestión y medición, conducen a la calidad, que se
confirma durante las pruebas.

PRUEBAS DE VALIDACIÓN
Tras la culminación de la prueba de integración, el software está
completamente ensamblado como un paquete, se han encontrado y
corregido los errores de interfaz y puede comenzar una serie final de
pruebas del software: la prueba de validación. La validación puede
definirse de muchas formas, pero una simple definición es que la
validación se consigue cuando el software funciona de acuerdo con
las expectativas razonables del cliente. En este punto, un
desarrollador de software estricto podría protestar: «¿Qué o quién es
el árbitro de las expectativas razonables?» Las expectativas
razonables están definidas en la Especificación de Requisitos del
Software: documento que Describe todos los atributos del software
visibles para el usuario. La especificación contiene una sección
denominada-. «Criterios de validación». La información contenida en
esa sección forma
la base del enfoque a la prueba de validación.
Criterios de la prueba de validación
La validación del software se consigue mediante una serie de pruebas
de caja negra que muestran la conformidad con los requisitos. Un
plan de prueba traza la clase de pruebas que se han de llevar a cabo,
y un procedimiento de prueba define los casos de prueba específicos
en un intento por descubrir errores de acuerdo con los requisitos.
Tanto el plan como el procedimiento estarán diseñados para asegurar
que se satisfacen todos los requisitos funcionales, que se alcanzan
todos los requisitos de rendimiento, que la documentación es correcta
e inteligible y que se alcanzan otros requisitos (por ejemplo,
portabilidad, compatibilidad, recuperación de errores, facilidad de
Mantenimiento).
Una vez que se procede con cada caso de prueba de validación,
puede darse una de las dos condiciones siguientes: (1) las
características de funcionamiento o de rendimiento están de acuerdo
con las especificaciones y son aceptables; o (2)’se descubre una
desviación de las especificaciones y se crea una lista de deficiencias.
Las desviaciones o errores descubiertos en esta
fase del proyecto raramente se pueden corregir antes de la
terminación planificada. A menudo es necesario negociar con el
cliente un método para resolver las deficiencias

Lic. Verónica Navarro B.


CBTIS 52 Diseño de sistemas

Revisión de la configuración
Un elemento importante del proceso de validación es la revisión de la
configuración. La intención de la revisión es asegurarse de que todos
los elementos de la configuración del software se han desarrollado
apropiadamente, se han catalogado y están suficientemente
detallados para soportar la fase de mantenimiento duran te el ciclo de
vida del software.

PRUEBA DE SEGURIDAD
La prueba de seguridad intenta verificar que los mecanismos de
protección incorporados en el sistema lo protegerán, de hecho, de
accesos impropios.
«Por supuesto, la seguridad del sistema debe ser probada en su
invulnerabilidad frente a un ataque frontal, pero también debe
probarse en su invulnerabilidad a ataques por los flancos o por la
retaguardia.»
Durante la prueba de seguridad, el responsable de la prueba
desempeña el papel de un individuo que desea entrar en el sistema.
¡Todo vale! Debe intentar conseguir las claves de acceso por
cualquier medio, puede atacar al sistema con software a medida,
diseñado para romper cualquier defensa que se haya construido,
debe bloquear el sistema, negando así el servicio a otras personas,
debe producir a propósito errores del sistema, intentando acceder
durante la recuperación o debe curiosear en los datos sin protección,
intentando encontrar la clave de acceso al sistema, etc.
PRUEBA DE RESISTENCIA
La prueba de resistencia ejecuta un sistema de forma que demande
recursos en cantidad, frecuencia o volúmenes anormales. Por
ejemplo:
(1) diseñar pruebas especiales que generen diez interrupciones por
segundo, cuando las normales son una o dos; (2) incrementar las
frecuencias de datos de entrada en un orden de magnitud con el fin
de comprobar cómo responden las funciones de entrada; ( 3 )
ejecutar casos de prueba que requieran el máximo de memoria o
de otros recursos; (4)diseñar casos de prueba que puedan dar
problemas en un sistema operativo virtual o ( 5 ) diseñar casos de
prueba que produzcan excesivas búsquedas de datos residentes en
disco. Esencialmente, el responsable de la prueba intenta romper el
programa.

PRUEBA DE RENDIMIENTO
Para sistemas de tiempo real y sistemas empotrados, es inaceptable
el software que proporciona las funciones requeridas pero no se
ajusta a los requisitos de

Lic. Verónica Navarro B.


CBTIS 52 Diseño de sistemas

rendimiento. La prueba de rendimiento está diseñada para probar el


rendimiento del software en tiempo de ejecución dentro del contexto
de un sistema integrado.
La prueba de rendimiento se da durante todos los pasos del proceso
de la prueba. Incluso al nivel de unidad, se debe asegurar el
rendimiento de los módulos
individuales a medida que se llevan a cabo las pruebas de caja
blanca. Sin embargo, hasta que no están completamente integrados
todos los elementos del sistema no se puede asegurar realmente el
rendimiento del sistema.
Las pruebas de rendimiento, a menudo, van emparejadas con las
pruebas de resistencia y, frecuentemente, requieren instrumentación
tanto de software como
de hardware. Es decir, muchas veces es necesario medir la utilización
de recursos (por ejemplo, ciclos de procesador), de un modo exacto.
La instrumentación externa puede monitorizar los intervalos de
ejecución, los sucesos ocurridos (por ejemplo, interrupciones) y
muestras de los estados de la máquina en un funcionamiento normal.
Instrumentando un sistema, el encargado de la prueba puede
descubrir situaciones que lleven a degradaciones y posibles fallos del
sistema.
El Proceso de depuración
La depuración no es una prueba, pero siempre ocurre como
consecuencia de la prueba. el proceso Se evalúan los resultados y
aparece una falta de correspondencia entre los esperados y los
encontrados realmente. En muchos casos, los datos que no
concuerdan son un síntoma de una causa subyacente que todavía
permanece oculta. El proceso de depuración intenta hacer
corresponder el sistema con una causa, llevando así a la corrección
del error.
El proceso de depuración siempre tiene uno de los dos resultados
siguientes:
(1) se encuentra la causa, se corrige y se elimina; o (2) no se
encuentra la causa.
En este último caso, la persona que realiza la depuración debe
sospechar la causa, diseñar un caso de prueba que ayude a confirmar
sus sospechas y el trabajo vuelve hacia atrás a la corrección del error
de una forma iterativa
PRUEBA DE RECUPERACIÓN
La prueba de recuperación es una prueba del sistema que fuerza el
fallo del software de muchas formas y verifica que la recuperación se
lleva a cabo apropiadamente. Si la recuperación es automática
(llevada a cabo por el propio sistema) hay que evaluar la corrección
de la inicialización, de los mecanismos de recuperación del estado del
sistema, de la recuperación de datos y del proceso de rearranque. Si

Lic. Verónica Navarro B.


CBTIS 52 Diseño de sistemas

la recuperación requiere la intervención humana, hay que evaluar los


tiempos medios de reparación para determinar si están dentro de
unos límites aceptables.
PRUEBA DE UNIDAD
Las pruebas que se dan como parte de la prueba de unidad se prueba
la interfaz del módulo para asegurar que la información fluye de
forma adecuada hacia y desde la unidad de programa que está
siendo probada. Se examinan las estructuras de datos locales para
asegurar que los datos que se mantienen temporalmente conservan
su integridad durante todos los pasos de ejecución del
algoritmo. Se prueban las condiciones límite para asegurar que el
módulo funciona correctamente en los límites establecidos como
restricciones de procesamiento.
Se ejercitan todos los caminos independientes (caminos básicos) de la
estructura de control con el fin de asegurar que todas las sentencias
del módulo se ejecutan
por lo menos una vez. Y, finalmente, se prueban todos los caminos de
manejo de errores.
Antes de iniciar cualquier otra prueba es preciso probar el flujo de
datos de la interfaz del módulo. Si los datos no entran correctamente,
todas las demás pruebas no tienen sentido. Además de las
estructuras de datos
locales, durante la prueba de unidad se debe comprobar (en la
medida de lo posible) el impacto de los datos globales sobre el
módulo.
PRUEBA DE INTEGRACION
La prueba de integración es una técnica sistemática para construir la
estructura del programa mientras que, al mismo tiempo, se llevan a
cabo pruebas para detectar errores asociados con la interacción. El
objetivo es coger los módulos probados mediante la prueba de unidad
y construir una estructura de programa que esté de acuerdo con lo
que dicta el diseño.
La integración incremental es cuando el programa se construye y se
prueba en pequeños segmentos en los que los errores son más fáciles
de aislar y de corregir, es más probable que se puedan probar
completamente las interfaces y se puede aplicar un enfoque de
prueba sistemática. En las siguientes secciones se tratan varias
estrategias de integración incremental diferentes.

IMPLANTACION Y MANTENIMIENTO
Implantación de sistemas
Es la ultima fase del desarrollo de Sistemas. Es el proceso instalar
equipos o Software nuevo, como resultado de un análisis y diseño

Lic. Verónica Navarro B.


CBTIS 52 Diseño de sistemas

previo como resultado de la sustitución o mejoramiento de la forma


de llevar a cavo un proceso automatizado.
Al Implantar un Sistema de Información lo primero que debemos
hacer es asegurarnos que el Sistema sea operacional o sea que
funcione de acuerdo a los requerimientos del análisis y permitir que
los usuarios puedan operarlo.
Existen varios enfoques de Implementación:

• Es darle responsabilidad a los grupos.


• Uso de diferentes estrategias para el entrenamiento de los
usuarios.
• El Analista de Sistemas necesita ponderar la situación y proponer
un plan de conversión que sea adecuado para la organización.

• El Analista necesita formular medidas de desempeño con las


cuales evaluar a los Usuarios.

• Debe Convertir físicamente el sistema de información antiguo, al


nuevo modificado.
 Diferentes métodos de implantación(sistemas en paralelo,
enfoque piloto,conversón directa, método por etapas)
Conversión: Este es el proceso de cambiar el sistema anterior al
nuevo, existen nos métodos para el logro efectivo de esta conversión.
Existen 4 métodos para llevar a cabo esta conversión, estos métodos
deben ser estudiados con cuidado para que así se implante el método
que mejor se le encaje a la conversión.
Métodos de conversión:
• Sistemas paralelos: es el método mas seguro, el cual
consiste en poner a trabajar los dos sistemas en paralelo,
de esta manera los usuario siguen utilizando el sistema
anterior de manera acostumbrada aunque van teniendo
mas contacto con el otro. La data va a ser poco a poco
migrada de un sistema a otro y sin que el usuario se de
cuenta vamos obligándolo a usar poco a poco mas el
nuevo sistema. Una de las desventajas es que al estar
operando los dos sistemas los costos se duplicaran debido
a que pudiera ser que se tenga que contratar personal
para que opere los dos sistemas, puede que también el
nuevo sistema sea rechazado por los usuarios y se vuelva
al sistema anterior.
• Conversión directa: este tipo de conversión se hace de
manera radical debido que se hace de un día a otro
obligando tanto físico como psicológicamente al usuario
que no existe otro sistema y debe usar ese. Esto tiene

Lic. Verónica Navarro B.


CBTIS 52 Diseño de sistemas

una desventaja ya que al eliminar por completo el


sistema antiguo se quedan sin respaldo, y si el sistema
nuevo llegase a tener problemas este quedara parando a
la empresa hasta que se solucione, también la empresa
se retrasa varias semanas debido que toda la captura de
datos debe empezarse de nuevo y los departamentos
deben ponerse a trabajar con eso. una vez que empiece
este proceso debe seguirse a pesar de las frustraciones
que pueden haber por cuestión de tiempo perdido. Este
método necesita una buena planificación, para que así no
exista perdida de ningún tipo.
• Enfoque piloto: este método funciona de la siguiente
manera, tenemos el sistema pero solo se lo aplicamos a
un departamento a manera de prueba para así también ir
probándolo y mejorándolo una vez capaces de trabajar
con el, y saber que el sistema esta trabajando en su
plenitud y no tiene errores y ah minimizado tareas en ese
departamento tanto como costos, tiempo etc. se va a
implementar en toda la empresa.
• Modelo por etapas: este método se da debido a la
tardanza de la llegada del nuevo sistema que pasara de
días a meses y es por eso que solo algunos tendrán
acceso a el. Ejemplo: soy un empresario, tengo 15 tiendas
de ropa, automatizar a las 15 tiendas a lo mejor me sale
muy costoso y es por eso que la implanto primero en 5
tiendas y luego en el resto.

Plan de capacitación

En la preparación de la Implantación, aunque el Sistema este bien


diseñado y desarrollado correctamente su éxito dependerá de su
implantación y ejecución por lo que es importante capacitar al usuario
con respecto a su uso y mantenimiento.
Capacitación de Usuarios del Sistema:
Es enseñar a los usuarios que se relacionan u operan en un proceso
de implantación.
La Responsabilidad de esta capacitación de los Usuarios primarios y
secundarios es del Analista, desde el personal de captura de datos
hasta aquellos que toman las decisiones sin usar una Computadora.
No se debe incluir a personas de diferentes niveles de habilidad e
intereses de trabajo; debido a que si en una Empresa existen
trabajadores inexpertos no se pueden incluir en la misma sección de
los expertos ya que ambos grupos quedaran perdidos.

Lic. Verónica Navarro B.


CBTIS 52 Diseño de sistemas

“Es como querer conducir dos Barcos con diferentes destinos con un
mismo Mapa de rutas o con el mismo timón”.

Aun y cuando la Empresa puede contratar los Servicios de


Instructores externos, el analista es la persona que puede ofrecer la
mejor capacitación debido a que conoce el personal y al Sistema
mejor que cualquier otro. A la falta o imposibilidad del analista la
organización puede contratar otros servicios de capacitación como
son:

• Vendedores: Son aquellos que proporcionan capacitación gratuita


fuera de la Empresa de uno o dos días.
• Instructor pagado externamente: Son aquellos que pueden
enseñar todo acerca de las computadoras pero para algunos
usuarios esta no es una capacitación necesaria.
• Instructores en casa: Están familiarizados con el personal y pueden
adecuar los materiales a sus necesidades, pero le faltaría
experiencia en Sistemas de Información que es realmente la
necesidad del usuario.

En nuestro país existe una ley institucional (Ley 116 del 16 de Enero
de 1980) llamada INFOTEP, representante de los trabajadores y
empresarios en el ámbito de Capacitación y entrenamiento, la cual
Asesora y brinda Sus servicios a las Empresas y Sus trabajadores.

Objetivos de la Capacitación:
Es lograr que los usuarios tengan el Dominio necesario de las cosas
básicas acerca de las maquinarias y procesos que se emplean para su
operación de manera eficiente y segura.

La Evaluación del Sistema:


Evaluación: Incluye la factibilidad de uso, tiempo de respuesta,
formatos de información, detectando las áreas donde el sistema falle.
Se lleva a cabo para identificar puntos débiles y fuertes del Sistema
implantado. La evaluación ocurre a lo largo de cualquiera de las
siguientes cuatro dimensiones:

Evaluación operacional:
Es el Momento en que sé evalúa la manera en que funciona el
Sistema, esto incluye su facilidad de uso, Tiempo de respuesta ante
una necesidad o proceso, como se adecuan los formatos en que se
presenta la Información, contabilidad global y su nivel de Utilidad.

Lic. Verónica Navarro B.


CBTIS 52 Diseño de sistemas

Impacto Organizacional:
Identifica y mide los beneficios operacionales para la Empresa en
áreas tales como, Finanzas (Costos, Ingresos y Ganancias), eficiencia
en el desempeño laboral e impacto competitivo, Impacto, rapidez y
organización en el flujo de Información interna y externa.
Desempeño del Desarrollo.
Es la evaluación del Proceso de desarrollo adecuado tomando en
cuentas ciertos criterios como, Tiempo y esfuerzo en el desarrollo
concuerden con presupuesto y estándares y otros criterios de
Administración de Proyectos. Además se incluyen la valoración de los
métodos y herramientas utilizados durante el desarrollo del Sistema.

Durante el Proceso de Implantación y Prueba se deben implementar


todas las estrategias posibles para garantizar que en el uso inicial del
Sistema este se encuentre libre de problemas lo cual se puede
descubrir durante este proceso y levar a cabo las correcciones de
lugar para su buen funcionamiento.
Desdichadamente la evaluación de Sistemas no siempre recibe la
atención que merece, sin embargo cuando se lleva a cabo de manera
adecuada proporciona muchas informaciones que pueden ayudar a
mejorar la efectividad de los esfuerzos de desarrollo de aplicaciones
futuras.

Mantenimiento de sistemas
Mantenimiento: consiste en la actualización del diseño de los
archivos, corrección de errores, depuración de bases de datos, en
lagunas ocasiones cambio en la forma de realizar los procesos.

Después de que los sistemas han sido verificados, probados e


implantados, se les debe seguir dando mantenimiento para asegurar
que continúen operando en el nivel mostrado durante la etapa de
prueba. Las rutinas de mantenimiento variarán de acuerdo con el tipo
y complejidad de la tecnología. Los fabricantes o proveedores suelen
indicar en muchos productos el programa o calendario de
mantenimiento requerido. El mantenimiento también puede ser
realizado por el fabricante o el proveedor como parte del acuerdo de
compra.

El monitoreo permanente de los sistemas necesita ser sistematizado


para asegurar que las necesidades de mantenimiento sean
identificadas y satisfechas cuando resulte necesario. Cuando los
sistemas son de uso prolongado, se puede establecer un mecanismo
para recibir retroalimentación de los usuarios como otra forma de
determinar las necesidades de mantenimiento y modificación.

Lic. Verónica Navarro B.


CBTIS 52 Diseño de sistemas

Cuando se realicen modificaciones al equipo, programa o


comunicaciones como resultado de programas de mantenimiento o
actualización, puede ser necesario promover rondas adicionales de
verificación y prueba del sistema para asegurarse que sigue
cumpliendo las normas exigidas.

Lic. Verónica Navarro B.

You might also like