República Bolivariana de Venezuela

Ministerio del Poder Popular para la Educación

Universidad Nacional Experimental Politécnica de la Fuerza Armada

Análisis Y Diseño de Sistemas II

4to Trabajo
ADS II.

Profesor: Alumno:

Ángel Cipriano Márquez César Wilson Ruda

C.I: 25.561.120

Caracas, 06 de febrero de 2023

 Introducción
Muchas veces, cuando trabajamos de manera independiente en proyectos
pequeños, no tenemos la necesidad de (o el cliente no cuenta con el
presupuesto para) escribir pruebas automatizadas.

Sin embargo, al empezar a trabajar en proyectos más grandes e integrarnos

a equipos de trabajo más amplios, notamos que muchas veces se habla de
distintos tipos de tests.

Aunque suene increíble, muchas veces como desarrolladores tendemos a

desarrollar nuevas características y no conocemos muy bien lo que hace el
equipo de QA, y no preguntamos, ya sea por falta de tiempo o porque no
queremos admitir lo poco que sabemos del tema.

Y así el tiempo avanza y no aprendemos las diferencias entre los tipos de

testing que existen. Pero esto se acaba hoy.

Aunque no vamos a escribir ni realizar pruebas en este artículo, sí que

vamos revisar qué tipos existen y qué busca lograrse con estas pruebas:
para conocer mejor sus diferencias, y no sentirnos perdidos cuando estos
conceptos sean usados en una conversación.

Las personas pueden tener definiciones que difieren un poco entre sí, pero la
idea general es la misma.

También hay que tener en cuenta que a veces los equipos se organizan para
ejecutar conjuntos de pruebas. A estos grupos de pruebas se les conoce
como "test suites" e incluyen pruebas de los distintos tipos.

Por ejemplo, es posible ejecutar un "test suite" que englobe integration

tests y regression tests.

También ten en cuenta que en algunos casos los equipos deciden "armar su
propio vocabulario" y asignan nombres a sus grupos de tests.

2
3
Fundamentos en el diseño de documentaciones de sistemas.

Preparación de manuales
Durante el desarrollo de un sistema, desde su concepción hasta su puesta
en marcha se ha generado gran cantidad de documentos, que en muchas
ocasiones se han visto modificados por documentos posteriores debido a
cambios en el sistema.

Para evitar confusiones en las revisiones de la documentación se desarrollan

diferentes tipos de documentos dirigidos a las personas que trabajarán con el
sistema y para facilitar el mantenimiento del mismo. La documentación de un
sistema debe ser marcada adecuadamente, bien organizada actualizada y
completa; todos los términos utilizados deben explicarse. La documentación
se hará disponible a todos los usuarios dc acuerdo a sus necesidades.

El estilo de redacción de los manuales de documentación debe ser:

 Concreto.
 Ser preciso y definir los términos utilizados.
 Utilizar párrafos cortos.
 Utilizar títulos y subtítulos.
 Utilizar formas activas en lugar de pasivas.
 No emplear frases largas que presenten hechos distintos.
 No hacer referencia a una información solamente con el número de
referencia

Manual del Sistema

Sirve como punto de partida al Sistema propuesto, ya que será en función de
la gerencia, de acuerdo con los usuarios de dicho Sistema, determinar si lo
expuesto en él satisface los requerimientos del propio sistema. Una vez
lograda la aprobación, se estará en condiciones de iniciar el desarrollo del
Sistema propuesto e ir integrando el resto de la documentación.

Contenido de un manual administrativo:

1. Nombre del sistema

2. Describir el nombre del sistema a implantar en la empresa.
3. Equipo Encargado Del Sistema

4
 4. Nombre del personal encargado del análisis y diseño del sistema.

Manual De Usuario
Expone los procesos que el usuario puede realizar con el sistema
implantado. Para lograr esto, es necesario que se detallen todas y cada una
de las características que tienen los programas y la forma de acceder e
introducir información. Permite a los usuarios conocer el detalle de qué
actividades ellos deberán desarrollar para la consecución de los objetivos del
sistema. Reúne la información, normas y documentación necesaria para que
el usuario conozca y utilice adecuadamente la aplicación desarrollada.

Objetivos

Que el usuario conozca cómo preparar los datos de entrada.

Que el usuario aprenda a obtener los resultados y los datos de salida.

Servir como manual de aprendizaje.

Servir como manual de referencia.

Definir las funciones que debe realizar el usuario.

Informar al usuario de la respuesta a cada mensaje de error.

Pasos a seguir para definir como desarrollar el manual de usuario.

Identificar los usuarios del sistema: personal que se relacionará con el

sistema.
Definir los diferentes tipo de usuarios: se presentan los diferentes tipos de
usuarios que usarían el sistema.

Ejemplo: usuarios directos, indirectos.

Definir los módulos en que cada usuario participará: Se describen los

módulos o procesos que se ejecutarán por cada usuario en forma narrativa
breve y clara.

Importancia Del Manual De Usuario

El Manual de Usuario facilita el conocimiento de:

 Los documentos a los que se puede dar entrada por computadora.

 Los formatos de los documentos.
 Las operaciones que utiliza de entrada y salida de los datos.
 El orden del tratamiento de la computadora con los datos introducidos.
 El momento en que se debe solicitar una operación deseada.

5
  Los resultados de las operaciones realizadas a partir de los datos
introducidos.

Al elaborar el Manual de Usuario, hay que tener en cuenta a quién va dirigido

es decir, el manual puede ser manejado desde el director de la
empresa hasta el introductor de datos. Por consiguiente, debe redactarse de
forma clara y sencilla para que lo entienda cualquier tipo de usuario.

Contenido

Diagrama general del sistema

Muestra en forma condensada el flujo general de la información y de las

actividades que se realizan en el sistema.

Proporciona una visión general del sistema.

Representar los diagramas utilizando para ello diagramas de bloques.

Diagrama particular detallado.

Presentar gráficamente todos los pasos que se efectúen dentro del

departamento usuario a quien está dirigido este manual. Deben especificarse
los archivos de entrada, salida, los resultados, revisiones y procesos
manuales.

Explicación Genérica De Las Fases Del Sistema

En este punto se explica en forma específica y detallada todas las

operaciones que aparecen representadas en forma gráfica en el diagrama
particular. Se analizan cada una de las fases señalando:

 El proceso principal que se desarrolla.

 La entrada de la información.
 La obtención de un resultado parcial.
 El envío de información a otra dependencia.

Instalación Del Sistema

La instalación del sistema proporciona detalles completos sobre la forma de

instalar el sistema en un ambiente particular.

Iniciación Al Uso Del Sistema

En este punto se explica cómo iniciarse en el sistema y cómo se pueden

utilizar sus cualidades comunes. Esta documentación debe decir al usuario
cómo salir de un problema cuando las cosas funcionan mal.

6
Cada actualización requiere un plan, y cada plan sigue el mismo proceso de
actualización básico.

Estrategias de actualización.

Debe planificar la actualización de modo que pueda saber qué esperar en

cada fase del proceso. En la fase de planificación, puede consultar la
documentación de actualización para informarse sobre el comportamiento
esperado, las nuevas características, las características descartadas, la
compatibilidad entre versiones y los requisitos para preparar el entorno de
producción. Tras dicha consulta, puede efectuar un examen del sitio para
identificar la infraestructura, las aplicaciones, los informes y los valores de
configuración personalizados de BI. Por último, puede probar la actualización
en un subconjunto de datos para poder ajustar los informes y datos antes de
llevar a cabo la actualización completa.

Al planificar la actualización, se debe realizar las tareas siguientes:

Recopilar la información necesaria, como las entradas requeridas y las

salidas previstas de cada fase.

Evaluar las aplicaciones en el entorno de creación de informes y agrupar los

informes similares.

Instalar el nuevo software en un entorno de prueba y desplegar el contenido

en el entorno de prueba.

Probar las aplicaciones actualizadas para asegurarse de que los informes se

ejecuten según lo esperado.

El proceso de despliegue y prueba suele ser iterativo. Evalúe las diferencias

que pudieran existir entre los entornos de origen y de destino. Trasládese a
su entorno de producción cuando compruebe que las aplicaciones
desplegadas cumplan sus requisitos empresariales.

El diagrama siguiente muestra un flujo de actualización general y las fases

del proceso de actualización. El proceso incluye las siguientes etapas:

7
Métodos de prueba de software

Tipos de métodos
Los diferentes tipos de pruebas

1. Pruebas unitarias

Las pruebas unitarias son de muy bajo nivel y se realizan cerca de la fuente
de la aplicación. Consisten en probar métodos y funciones individuales de las
clases, componentes o módulos que usa tu software. En general, las pruebas
unitarias son bastante baratas de automatizar y se pueden ejecutar
rápidamente mediante un servidor de integración continua.

2. Pruebas de integración

Las pruebas de integración verifican que los distintos módulos o servicios

utilizados por tu aplicación funcionan bien en conjunto. Por ejemplo, se

8
puede probar la interacción con la base de datos o asegurarse de que los
microservicios funcionan bien en conjunto y según lo esperado. Estos tipos
de pruebas son más costosos de ejecutar, ya que requieren que varias
partes de la aplicación estén en marcha.

3. Pruebas funcionales

Las pruebas funcionales se centran en los requisitos empresariales de una

aplicación. Solo verifican el resultado de una acción y no comprueban los
estados intermedios del sistema al realizar dicha acción.

A veces, se confunden las pruebas de integración con las funcionales, ya

que ambas requieren que varios componentes interactúen entre sí. La
diferencia es que una prueba de integración puede simplemente verificar que
puedes hacer consultas en la base de datos, mientras que una prueba
funcional esperaría obtener un valor específico desde la base de datos,
según dicten los requisitos del producto.

4. Pruebas de extremo a extremo

Las pruebas integrales replican el comportamiento de un usuario con el

software en un entorno de aplicación completo. Además, verifican que
diversos flujos de usuario funcionen según lo previsto, y pueden ser tan
sencillos como cargar una página web o iniciar sesión, o mucho más
complejos, como la verificación de notificaciones de correo electrónico,
pagos en línea, etc

Las pruebas integrales son muy útiles, pero son costosas de llevar a cabo y
pueden resultar difíciles de mantener cuando están automatizadas. Se
recomienda tener algunas pruebas integrales clave y depender más de
pruebas de menor nivel (unitarias y de integración) para poder detectar
rápidamente nuevos cambios.

5. Pruebas de aceptación

Las pruebas de aceptación son pruebas formales que verifican si un sistema

satisface los requisitos empresariales. Requieren que se esté ejecutando
toda la aplicación durante las pruebas y se centran en replicar las conductas
de los usuarios. Sin embargo, también pueden ir más allá y medir el
rendimiento del sistema y rechazar cambios si no se han cumplido
determinados objetivos.

9
6. Pruebas de rendimiento

Las pruebas de rendimiento evalúan el rendimiento de un sistema con una

carga de trabajo determinada. Ayudan a medir la fiabilidad, la velocidad, la
escalabilidad y la capacidad de respuesta de una aplicación. Por ejemplo,
una prueba de rendimiento puede analizar los tiempos de respuesta al
ejecutar un gran número de solicitudes, o cómo se comporta el sistema con
una cantidad significativa de datos. Puede determinar si una aplicación
cumple con los requisitos de rendimiento, localizar cuellos de botella, medir
la estabilidad durante los picos de tráfico y mucho más.

7. Pruebas de humo

Las pruebas de humo son pruebas básicas que sirven para comprobar el
funcionamiento básico de la aplicación. Están concebidas para ejecutarse
rápidamente, y su objetivo es ofrecerte la seguridad de que las principales
funciones de tu sistema funcionan según lo previsto.

Las pruebas de humo pueden resultar útiles justo después de realizar una
compilación nueva para decidir si se pueden ejecutar o no pruebas más
caras, o inmediatamente después de una implementación para asegurarse
de que la aplicación funciona correctamente en el entorno que se acaba de
implementar.

Características
Las pruebas de software siguen un proceso en común. Las tareas o pasos
incluyen definir el entorno de prueba, desarrollar casos de prueba, desarrollar
scripts, analizar los resultados de las pruebas y enviar los informes de los
defectos.

Las pruebas pueden llevar mucho tiempo. Las pruebas manuales o las
pruebas ad-hoc pueden ser suficientes para compilaciones pequeñas. Sin
embargo, para sistemas más grandes, se utilizan con frecuencia
herramientas para automatizar las tareas. Las pruebas automatizadas
ayudan a los equipos a implementar diferentes escenarios, probar
diferenciadores (como mover componentes a un entorno de nube) y obtener
rápidamente comentarios sobre lo que funciona y lo que no.

Un buen enfoque de prueba abarca la interfaz de programación de

aplicaciones (API), la interfaz de usuario y los niveles del sistema. Además,
cuantas más pruebas se automaticen y se ejecuten antes, mejor. Algunos
equipos crean herramientas de automatización de pruebas internas. Sin

10
embargo, las soluciones de los proveedores ofrecen características que
pueden agilizar las tareas clave de administración de pruebas, tales como:

Prueba continua: Los equipos de proyecto prueban cada compilación a

medida que está disponible. Este tipo de prueba de software se basa en la
automatización de pruebas que se integra con el proceso de implementación.
Permite que el software se valide en entornos de prueba realistas al principio
del proceso, lo que mejora el diseño y reduce los riesgos.
Gestión de la configuración: Las organizaciones mantienen de forma
centralizada los activos de prueba y realizan un seguimiento de las
compilaciones de software para probarse. Los equipos obtienen acceso a
activos como código, requisitos, documentos de diseño, modelos, scripts de
prueba y resultados. Los buenos sistemas incluyen autenticación de usuarios
y rastros de auditoría para ayudar a los equipos a cumplir con los requisitos
de cumplimiento con un esfuerzo administrativo mínimo.
Virtualización de servicios: Es posible que los entornos de prueba no estén
disponibles, especialmente en las primeras etapas del desarrollo del código.
La virtualización de servicios simula los servicios y sistemas que faltan o aún
no se completaron, lo que permite a los equipos reducir las dependencias y
realizar pruebas antes. Pueden reutilizar, implementar y cambiar una
configuración para probar diferentes escenarios sin tener que modificar el
entorno original.
Defecto oseguimiento de errores: El seguimiento de los defectos es
importante tanto para los equipos de pruebas como para los de desarrollo,
con el fin de medir y mejorar la calidad. Las herramientas automatizadas
permiten a los equipos rastrear defectos, medir su alcance e impacto y
descubrir otros problemas relacionados.
Métricas e informes: Los informes y los análisis permiten a los miembros del
equipo compartir el estado, los objetivos y los resultados de las pruebas. Las
herramientas avanzadas integran las métricas del proyecto y presentan los
resultados en un tablero. Los equipos ven rápidamente el estado general de
un proyecto y pueden monitorear las relaciones entre la prueba, el desarrollo
y otros elementos del proyecto.

Métodos de evaluación y verificación

Tres medios instrumentales de minimizar los riesgos de la tecnología son la
verificación, prueba y mantenimiento de los sistemas. Cada componente de
un sistema de cómputo -equipo, comunicaciones y programas- debe ser
verificado y probado rigurosamente antes de utilizarlo para un evento
electoral. Después de una prueba exitosa, los sistemas requieren
mantenimiento regular para asegurarse que funcionarán de manera efectiva
cuando se requieran.

11
Es probable que el nivel de importancia tecnológica determine el grado de
rigor aplicado a la verificación, prueba y mantenimiento de la tecnología.
Para un sistema que va a ser utilizado en una función electoral clave, como
una votación electrónica, el nivel de rigor requerido será mayor.

Verificación

Para un sistema muy importante, como uno de votación electrónica, es

conveniente que una autoridad independiente aplique las pruebas de
verificación. Para sistemas de menor importancia, la verificación puede
realizarse internamente.

Las pruebas de verificación (también conocidas como pruebas de calidad)

pueden incluir:

Probar los equipos bajo condiciones que simulen las de operación real.
Probar los programas para asegurar que se siguen los estándares
apropiados y que desempeñan las funciones esperadas.
Asegurar que la documentación sea la adecuada y esté completa.
Asegurar que los sistemas de comunicación se ciñan a los estándares
establecidos y funcionen de manera efectiva.
Verificar que los sistemas sean capaces de operar bajo condiciones
normales, pero también bajo potenciales condiciones inesperadas.
Asegurar que se cuente con las debidas medidas de seguridad y que estas
se ciñan a las normas establecidas.
Asegurar que la calidad

Prueba

La prueba de los sistemas es usualmente más detallada y rigurosa que la

verificación. Se requiere para asegurar que cada componente del sistema
esté en operación como debe y que el sistema en su conjunto se desempeñe
exactamente de acuerdo con los requerimientos locales específicos.

Para un sistema importante, como el de votación electrónica, un programa

estructurado de prueba constituye un medio para asegurar que todos sus
componentes sean evaluados. Las medidas de prueba que se pueden seguir
incluyen:

Desarrollar un conjunto de criterios para la prueba.

Examinar todos los códigos no estandarizados para garantizar su lógica y
que se hayan seguido los estándares debidos de diseño y construcción.
Aplicar pruebas "no operativas" para asegurar que el equipo puede tolerar los
niveles de manejo físico esperado.

12
Aplicar pruebas funcionales para determinar si se han satisfecho los criterios
de prueba.
Aplicar evaluaciones de calidad para determinar si se han satisfecho los
criterios de prueba.
Conducir pruebas en condiciones de "laboratorio" y en una variedad de
condiciones "reales".
Conducir pruebas durante un periodo prolongado, para cerciorarse que los
sistemas pueden funcionar de manera consistente.
Conducir "pruebas de carga", simulando tanto como sea posible una
variedad de condiciones reales utilizando o excediendo los volúmenes de
información que se pueden esperar en una situación concreta.
Verificar que lo que entra es lo que sale, introduciendo información conocida
y verificando que el resultado sea consecuente con ella.

Mantenimiento

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.

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.

Consumo de Recursos
Esta sub-característica principal se refiere a la capacidad del producto de
software para utilizar una apropiada cantidad y tipos de recursos cuando el
software desempeña su función bajo condiciones establecidas. Los recursos
humanos están incluidos como parte de la productividad.

13
Consumo de Recursos

Esta sub-característica principal se refiere a la capacidad del producto de

software para utilizar una apropiada cantidad y tipos de recursos cuando el
software desempeña su función bajo condiciones establecidas. Los recursos
humanos están incluidos como parte de la productividad.

Documentación.
En general se habla mucho de la documentación, pero no se la hace, no se
le asigna presupuesto, no se la mantiene y casi nunca está al día en los
proyectos de desarrollo de software.

Lo importante es la disponibilidad de la documentación que se necesita en el

momento en que se la necesita.

Muchas veces se hace porque hay que hacerla y se escribe, con pocas
ganas, largos textos, a la vez que se está convencido de estar haciendo un
trabajo inútil.

A veces se peca por exceso y otras por defecto. Ocurre mucho en la Web y
con productos RAD. En ocasiones se olvida que el mantenimiento también
debe llegar a la documentación.

La documentación se suele clasificar en función de las personas o grupos a

los cuales está dirigida:

 Documentación para los desarrolladores

 Documentación para los usuarios
 Documentación para los administradores o soporte técnico

La documentación para desarrolladores es aquélla que se utiliza para el

propio desarrollo del producto y, sobre todo, para su mantenimiento futuro.
Se documenta para comunicar estructura y comportamiento del sistema o de
sus partes, para visualizar y controlar la arquitectura del sistema, para
comprender mejor el mismo y para controlar el riesgo, entre otras cosas.
Obviamente, cuanto más complejo es el sistema, más importante es la
documentación.

En este sentido, todas las fases de un desarrollo deben documentarse:

requerimientos, análisis, diseño, programación, pruebas, etc. Una
herramienta muy útil en este sentido es una notación estándar de modelado,
de modo que mediante ciertos diagramas se puedan comunicar ideas entre
grupos de trabajo.

14
Hay decenas de notaciones, tanto estructuradas como orientadas a objetos.
Un caso particular es el de UML, que analizamos en otra obra. De todas
maneras, los diagramas son muy útiles, pero siempre y cuando se
mantengan actualizados, por lo que más vale calidad que cantidad.

La documentación para desarrolladores a menudo es llamada modelo, pues

es una simplificación de la realidad para comprender mejor el sistema como
un todo.

Otro aspecto a tener en cuenta cuando se documenta o modela, es el del

nivel de detalle.

Así como cuando construimos planos de un edificio podemos hacer planos

generales, de arquitectura, de instalaciones y demás, también al documentar
el software debemos cuidar el nivel
de detalle y hacer diagramas diferentes en función del usuario de la
documentación, concentrándonos en un aspecto a la vez.

De toda la documentación para los desarrolladores, nos interesa

especialmente en esta obra aquella que se utiliza para documentar la
programación, y en particular hemos analizado la que se usa para
documentar desarrollos orientados a objetos en el capítulo respectivo.

La documentación para usuarios es todo aquello que necesita el usuario para

la instalación, aprendizaje y uso del producto. Puede consistir en guías de
instalación, guías del Incluye los requisitos del sistema, el procedimiento de
instalación en pasos bien definidos y las posibilidades de personalización.
Usuario, manuales de referencia y guías de mensajes.

En el caso de los usuarios que son programadores, verbigracia los clientes

de nuestras clases, esta documentación se debe acompañar con ejemplos
de uso recomendados o de muestra y una reseña de efectos no evidentes de
las bibliotecas.

Más allá de todo esto, debemos tener en cuenta que la estadística

demuestra que los usuarios no leen los manuales a menos que nos les
quede otra opción. Las razones pueden ser varias, pero un análisis de la
realidad muestra que se recurre a los manuales solamente cuando se
produce un error o se desconoce cómo lograr algo muy puntual, y recién
cuando la ayuda en línea no satisface las necesidades del usuario.

Por lo tanto, si bien es cierto que debemos realizar manuales, la existencia

de un buen manual nunca nos libera de hacer un producto amigable para el
usuario, que incluso contenga ayuda en línea.

15
Es incluso deseable proveer un software tutorial que guíe al usuario en el uso
del sistema, con apoyo multimedia, y que puede llegar a ser un curso online.
Buena parte de la documentación para los usuarios puede empezar a
generarse desde que comienza el estudio de requisitos del sistema. Esto
está bastante en consonancia con las ideas de extreme programming y con
metodologías basadas en casos de uso.

La documentación para administradores o soporte técnico, a veces llamada

manual de operaciones, contiene toda la información sobre el sistema
terminado que no hace al uso por un usuario final.

Es necesario que tenga una descripción de los errores posibles del sistema,
así como los procedimientos de recuperación. Como esto no es algo estático,
pues la aparición de nuevos errores, problemas de compatibilidad y demás
nunca se puede descartar, en general el manual de operaciones es un
documento que va engrosándose con el tiempo.

16
 Conclusión
Así como es importante verificar que nuestros usuarios pueden usar nuestra
aplicación (pueden iniciar sesión, enviar mensajes, y/o actualizar datos), es
igual de importante verificar que nuestro sistema siga funcionando
adecuadamente cuando se ingresen datos incorrectos o se realicen acciones
inesperadas.

Necesitamos anticipar qué ocurrirá cuando un usuario cometa un error

ingresando datos incoherentes, intente guardar un formulario sin completar
todos los campos, o vaya de un paso a otro sin seguir una secuencia, con o
sin malas intenciones.

Así mismo, necesitamos verificar si es posible para un usuario comprometer

datos (es decir, tener acceso a recursos que no deben).

Entonces:

Un buen conjunto de pruebas debería "romper nuestra aplicación" y

ayudarnos a entender sus límites. Y, por último, las pruebas son código
también, por lo que no debemos olvidarlas durante los "code review", ya que
son un paso importante para el pase a producción.

17
 Bibliografía
- https://aceproject.org/main/espanol/et/ete05.htm

18
INDICE
Introducción 2
Fundamentos en el diseño de documentaciones de sistemas. 4
Preparación de manuales 4
Manual del Sistema 4
Manual De Usuario 5
Estrategias de actualización. 7
Métodos de prueba de software 8
Tipos de métodos 8
Características 10
Métodos de evaluación y verificación 11
Consumo de Recursos 13
Documentación. 14
Conclusión 17
Bibliografía 18

19