fffgdfdfsvsd

1. Entrada 1
-Conceptos básicos
-Ciclo de vida del software
-Modelos de proceso
-Tipos y clasificación

2. Definir la Ingeniería de Software y explicar su
importancia.
Discutir los conceptos de producto de software y
Proceso de software.
Introducir la noción de responsabilidad profesional.
La economía de todos los países desarrollados es
Dependiente del software.
Actualmente cada vez mas sistemas son controlados por
Software.

3. El término ciclo de vida del software describe el desarrollo de
software, desde la fase inicial hasta la fase final. El propósito de
este programa es definir las distintas fases intermedias que se
requieren para validar el desarrollo de la aplicación, es decir,
para garantizar que el software cumpla los requisitos para la
aplicación y verificación de los procedimientos de desarrollo:
se asegura de que los métodos utilizados son apropiados.
Estos programas se originan en el hecho de que es muy costoso
rectificar los errores que se detectan tarde dentro de la fase de
implementación. El ciclo de vida permite que los errores se
detecten lo antes posible y por lo tanto, permite a los
desarrolladores concentrarse en la calidad del software,
en los plazos de implementación y en los costos asociados.

4. Marco de referencia que contiene los Marco de referencia
que contiene los procesos, las actividades y las tareas involucradas
en el desarrollo, la explotación y el mantenimiento de un producto
de software, ab d l id d l i t d d l d fi i ió d l i it barcando la vida del
sistema desde la definición de los requisitos hasta la finalización
de su uso (norma ISO 12207-1) [ISO/IEC, 1995].

5. Podemos encontrar distintos tipos de software,
hay desde una clasificación básica hasta una
avanzada, por el momento veremos la básica
para no entrar demasiado en el tema e ir a lo que
queremos.

6. Entrada 2
-Descripción del modelo nivel a nivel.

7. El DELE A2 es el segundo de los niveles del MCER.
Este diploma acredita que el candidato es capaz de comprender frases y
expresiones cotidianas de uso frecuente relacionadas con áreas de experiencia
que le son especialmente relevantes (información básica sobre sí mismo y su familia,
compras, lugares de interés, ocupaciones, etc.).
El examen DELE A2 consta de diferentes pruebas, organizadas en dos grupos:
Grupo 1 (Destrezas de lecto-escritura): Comprensión de lectura (60 minutos) y
expresión e interacción escritas (50 minutos).
Grupo 2 (Destrezas orales): Comprensión auditiva (35 minutos) y expresión
e interacción orales (15 minutos).Se requiere la calificación de «apto» en cada
uno de los grupos de pruebas en la misma convocatoria de examen.
La puntuación máxima que se puede conseguir en el examen es de 100 puntos
y es necesario obtener 30 puntos en cada grupo para alcanzar la calificación
global de «apto».

8. Entrada 3
- Que son pruebas de software
- Pruebas de caja negra
- Pruebas de integración
- Pruebas del sistema
- Pruebas de contenido
- Prueba de funcionalidad
- Pruebas de usabilidad

9. Las pruebas de software (en inglés software testing) son las investigaciones e
mpíricas y técnicas cuyo objetivo es proporcionar información objetiva e
independiente sobre la calidad del producto a la parte interesada o stakeholder.
Es una actividad más en el proceso decontrol de calidad.
Las pruebas son básicamente un conjunto de actividades dentro del desarrollo
de software. Dependiendo del tipo de pruebas, estas actividades podrán ser
implementadas en cualquier momento de dicho proceso de desarrollo.
Existen distintos modelos de desarrollo de software, así como modelos de
pruebas. A cada uno corresponde un nivel distinto de involucramiento en las
actividades de desarrollo.
Que son pruebas de software

10. En teoría de sistemas y física, se denomina Caja Negra
a aquel elemento que es estudiado desde el punto de vista de las
entradas que recibe y las salidas o respuestas que produce,
sin tener en cuenta su funcionamiento interno. En otras palabras,
de una caja negra nos interesará su forma de interactuar con el
medio que le rodea (en ocasiones, otros elementos que también
podrían ser cajas negras) entendiendo qué es lo que hace, pero
sin dar importancia a cómo lo hace. Por tanto, de una caja negra
deben estar muy bien definidas sus entradas y salidas, es decir,
su interfaz; en cambio, no se precisa definir ni conocer los detalles
internos de su funcionamiento.

13. Realiza sobre las funciones internas de un módulo. Así como las pruebas
de caja negra ejercitan los requisitos funcionales desde el exterior del
módulo, las de caja blanca están dirigidas a las funciones internas. Entre las
técnicas usadas se encuentran; la cobertura de caminos (pruebas que hagan
que se recorran todos los posibles caminos de ejecución), pruebas sobre las
expresiones lógico-aritméticas, pruebas de camino de datos (definición-uso
de variables), comprobación de bucles (se verifican los bucles para 0,1 e
interacciones, y luego para las interacciones máximas, máximas menos uno y
más uno).
Las pruebas de caja blanca se llevan a cabo en primer lugar, sobre un
módulo concreto, para luego realizar las de caja negra sobre varios
subsistemas (integración).

16. En este caso probamos cómo es la interacción entre dos o mas
unidades del software. Este tipo de pruebas verifican que los
componentes de la aplicación funcionan correctamente actuando
en conjunto. Siguiendo con el caso anterior, las pruebas de
integración son las que comprobarían que se ha mandado un
email, la conexión real con la base de datos etc.
Este tipo de pruebas son dependientes del entorno en el que
se ejecutan. Si fallan, puede ser porque el código esté bien,
pero haya un cambio en el entorno.
Por ejemplo, también podríamos usar JUnit para realizar
pruebas de integración, si no hacemos mocks o stubs, y nos
centramos en probar el comportamiento de los componentes en
su conjunto.

18. Son similares a las pruebas de caja negra,
Solo que estas buscan probar al sistema como
un todo. Están basadas en los requerimientos
generales y abarca todas las partes combinadas
Del sistema.

20. Este entorno lo utilizan los probadores y puede ser tan simple como
un servidor individual donde las actualizaciones de sitios y de contenido
se pueden probar antes de que se sindiquen en el entorno de entrega, o
tan complejo como las réplicas completas del entorno de entrega donde
las pruebas se pueden producir en el sitio de revisión y en las
actualizaciones de contenido, y para probar el rendimiento del entorno de
entrega. También permite acumular cambios del entorno de creación desde
su entorno de creación antes de sindicar los cambios para el entorno de entrega
como un único lote.

22. Se ejecuta cada caso de uso, flujo de caso de uso,
o función, usando datos válidos e inválidos, para
verificar lo siguiente: Pruebas Funcionales –
Software II – Mayo 2005  Que se aplique
apropiadamente cada regla de negocio.  Que los
resultados esperados ocurran cuando se usen
datos válidos.  Que sean desplegados los mensajes
apropiados de error y precaución cuando se usan
datos inválidos.

24. Las pruebas de usabilidad es una técnica usada en el diseño de
interacciones centrado en el usuario para evaluar un producto mediante pruebas con
los usuarios mismos. Esto puede ser visto como una práctica
de usabilidad irreemplazable, dado que entrega información directa de como los
usuarios reales utilizan el sistema.1 Este es en contraste con los métodos
de inspección de usabilidad donde expertos usan diferentes métodos para evaluar
una interfaz de usuario sin involucrar a usuarios reales.
Las pruebas de usabilidad se enfocan en medir la capacidad de un producto de
fabricación humana en cumplir el propósito para el cual fue diseñado. Ejemplos de
productos que normalmente se benefician de pruebas de usabilidad son comidas,
productos de consumo, sitios web o aplicaciones web, interfaces de usuario,
documentos y dispositivos. Las pruebas de usabilidad miden la usabilidad, o facilidad
de uso, de un objeto específico o un conjunto de objetos, mientras que los estudios
de interacción persona-computador intentan formular los principios generales.

26. Entrada 4
Pruebas de mantenimiento
- Que son?
- Tipos

27. 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.
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.

28. Tipos:
- Verificación
- Prueba
- Mantenimiento

29. 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 ensuring that appropriate quality assurance measures are in place

30. 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.
•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.

31. 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.