Sie sind auf Seite 1von 4

Ingeniería en Desarrollo de Software

Introducción a la Ingeniería de Software


3er Semestre
Alumno: Daniel Pineda de la Riva
Matricula: es162006588
Docente: Susana Salgado Segovia
Unidad 3
Autorreflexiones.
Unidad 3: Diseño, codificación, pruebas y Mantenimiento

Instrucciones. Analiza y contesta las siguientes preguntas con relación a la unidad 3.

1. ¿Qué es un lenguaje arquitectónico?

Ya que se definieron las interacciones entre el sistema y su entorno, se utiliza esta información como
base para diseñar la arquitectura del sistema. Se deben identificar los componentes del sistema y
sus interacciones, después se organizan en un patrón arquitectónico como un modelo.

2. Indica si la siguiente afirmación es cierta o falsa y razona tu respuesta: en el modelado de


un sistema se ha de optar por una de las diferentes vistas disponibles en el lenguaje de
representación utilizado (por ejemplo, la vista de casos de uso de UML).

Es cierta porque para continuar con el desarrollo de software, es necesario retomar los diagramas
elaborados en la etapa de análisis y modelado de requerimientos para el diseño de la interfaz del
sistema, de las bases de datos, procedimientos y de los posibles reportes del sistema.

3. ¿Qué es un generador automatizado de documentación?

Un generador de documentación es una herramienta de programación que genera documentación


destinada a los programadores (documentación de API) o a usuarios finales, o a ambos, a partir de
un conjunto de código fuente especialmente documentado, y en algunos casos, archivos binarios.

4. Enumera algunos tipos de prueba y su importancia en el desarrollo de un sistema.

Pruebas de desarrollo: son un proceso de prueba obligado, cuyo objetivo consiste en descubrir
errores en el software, generalmente están entrelazadas con la depuración: localizar problemas con
el código y cambiar programas para corregirlos.

Pruebas de unidad: para probar programas o clases. Sirven para comprobar la funcionalidad de
objetos o métodos.

Pruebas del componente: se prueban las interfaces de los componentes.

Pruebas del sistema: se prueba la integración de todos los componentes.

Pruebas de componentes: se enfoca en demostrar que la interfaz de componente se comporte según


la especificación.

Pruebas del sistema: incluyen la integración de los componentes y luego probar el sistema
completamente integrado. La prueba del sistema es un proceso colectivo más que individual.

Pruebas de versión: sirven para poner a prueba una versión particular de un sistema que se
pretende usar fuera del equipo de desarrollo. Generalmente esta versión es para clientes y usuarios,
sin embargo, en proyectos muy grandes, una versión podría ser para otros equipos que desarrollan
sistemas relacionados.
Pruebas basadas en requerimientos: Estas pruebas son de validación más que defectos, se
intenta demostrar que el sistema implementó adecuadamente sus requerimientos.

Pruebas de escenario: son similares a las de versión, donde se crean escenarios que generalmente
suceden y se les utiliza en el desarrollo de casos de prueba para el sistema.

Pruebas de rendimiento: Se aplican cuando el sistema ha sido integrado completamente, con ellas
es posible probar el rendimiento y confiabilidad.

Pruebas de usuario: Este tipo de pruebas son necesarias por la influencia del entorno de trabajo
que tiene gran efecto sobre la fiabilidad, el rendimiento, el uso y la robustez de un sistema.

5. ¿Qué opinión te merece el siguiente comentario? ¿Qué argumentos utilizarías para


rebatirlo? “el tiempo que se pierde en pensar mejores nombres para los identificadores puede
emplearse en cosas mejores. Si solo es un pedazo de código en el que queda claro por el
contexto cual es el significado de cada nombre ¿Por qué perder el tiempo buscando los
mejores nombres? Sinceramente creo que no es hacer buen uso del tiempo disponible el
dedicarse a esto”

En mi opinión es que los nombres que se le van a poner a los identificadores deben de estar
relacionados con lo que se esta trabajando no es necesario pensar mucho o perder el tiempo en
poner nombres a los identificadores ya que la aplicación que se esté trabajando siempre tendrá un
tema es decir si se va a realizar una aplicación para una ferretería sabemos que todos los productos
tienen un nombre con el cual podemos nombrar a los identificadores en base al nombre del producto.
Referencias

Jesús Barranco de Areba. (2001). Metodología del Análisis Estructurado de Sistemas. España:
Comillas.

Ian Sommerville. (2005). Ingeniería del Software. Madrid: Pearson.

Daniel Ramos. (2017). Curso de Ingeniería de Software. Estados Unidos: IT Campus Academy.

Fernando Alonso. (2005). Introducción a la Ingeniería del Software modelos de desarrollo de


software. España: Delta Publicaciones.

Cristina Gómez. (2003). Diseño de Sistemas Software UML. Barcelona: Edicions UPC.

Jesús Lores Vidal. (2005). Diseños de Sistemas Interactivos centrados en el usuario. Barcelona:
UOC.

Kendall. (2005). Análisis y diseños de Sistemas. México: Pearson Educación.

Das könnte Ihnen auch gefallen