NOTA:

EXAMEN PARCIAL I
Apellidos Ojeda Morocho Semestre 2020 - 2
Nombres Jefersson Raul Ciclo académico V
Escuela INGENIERÍA DE SISTEMAS Aula AV - C1
Experiencia
INGENIERÍA DE SOFTWARE Turno M T N
curricular
Docente Mg. LAIN CÁRDENAS ESCALANTE Fecha 22 09 2020

I. COMPETENCIA:
Aplica las técnicas y métodos de Ingeniería de Software para la construcción e implementación
de software, expresando sus ideas con coherencia, lógica, orden, claridad, fundamento y buen
lenguaje; innovando en la búsqueda de soluciones.

II. INSTRUCCIONES:
 Lee atentamente cada actividad antes de desarrollarla.
 Se recomienda mantener la correcta redacción, orden.
 Sus cámaras deben estar encendidas.
 Las preguntas deberán ser formuladas sólo al docente a cargo.

III.CONDICIONES DE EVALUACIÓN:
 La prueba tiene una duración de 60 minutos.
 Utiliza la Plataforma Blackboard y la Herramienta Zoom.

IV. ACTIVIDADES DE EVALUACIÓN:

Preguntas de opción múltiple, marque con una X dentro de los corchetes la respuesta correcta.

1. La Ingeniería de Software es la aplicación de un enfoque sistemático por las siguientes razones

(1pto):
a) El proceso de desarrollo del software es sometido a medición [ ]
b) Las actividades deben estar sujetas a control con respecto a ciertos estándares [ ]
c) Se realizan actividades de acuerdo a un proceso o plan de desarrollo de software [ x ]
d) Se elaboran diagramas de procesos con SPEM [ ]

2. La Ingeniería de Software como disciplina permite (1pto):

a) Aplicar el método científico para estudiar actividades de ingeniería [ ]
b) Realizar diseño y construcción de software [ x ]
c) Aplicar el método científico para generar teorías de ingeniería de software [ ]
d) Generar modelos explicativos de la ingeniería de software [ ]

3. Es una unidad mínima de trabajo, tiene una duración definida, consume recursos y tiene un
coste (1pto):
a) Actividad [ x ]
b) Proceso de software [ ]
c) Artefacto [ ]
d) Rol [ ]

4. Como parte del proceso de la Ingeniería de Software se realiza el proceso de requisitos que
permite realizar (1pto):
a) Captura de requisitos y diseño arquitectónico [ ]
b) Análisis de requisitos, diseño detallado y codificación [ ]
c) Análisis de requisitos, especificación de requisitos y diseño arquitectónico [ ]
d) Captura, análisis y validación de requisitos [ x ]
Preguntas de correspondencia, marque con una X dentro de las celdas la respuesta correcta.

5. Clasificar las características en función al proceso de desarrollo que aplique (4ptos):

CARACTERÍSTICA CascadRUP Scrum

a
Los equipos suelen ser pequeños e incluyen a un
x
representante de usuario como dueño del producto.
Está guiado por los casos de uso como artefacto de
x
requisitos.
Se debe terminar toda la fase de requisitos para poder pasar
x
a la fase de diseño e implementación.
Divide el proyecto en cuatro fases y las fases en iteraciones. x

DESCRIPCIÓN DE UN PROCESO DE DESARROLLO DE SOFTWARE

El proceso inicia cuando el cliente debe definir un listado de necesidades que serán entregadas al
gerente de proyecto. Posteriormente, el gerente de proyecto debe elaborar el plan general en donde
se describirá el alcance, los objetivos, los roles, el tiempo estimado de cada iteración y los riesgos.
El plan general debe ser revisado y aprobado por el cliente para que el gerente de proyecto pueda
planificar la próxima iteración. En caso el cliente no apruebe el plan general, el cliente debe cancelar
el proyecto y el proceso termina. Posterior a la planificación de la iteración, el analista es el
responsable de analizar los modelos de procesos de negocio para comprender la situación actual
del SuperMarket. El analista, luego de comprender el negocio, debe capturar los requisitos del
sistema elaborando el documento visión. El documento visión describirá las necesidades y
características del sistema a desarrollar. Posteriormente, el analista debe analizar los requisitos del
sistema que tendrá como resultado el diagrama y priorización de casos de uso. Conociendo los
casos de uso priorizados para la iteración, el analista debe especificar los requisitos lo cual dará
como resultado la especificación de casos de uso y las especificaciones suplementarias. Por último,
el analista debe validar los requisitos para encontrar alguna inconformidad. Si en la validación se
encuentran inconformidades o no se tienen claro los requisitos, entonces el cliente debe definir las
mejoras o cambios en los requisitos y luego el analista nuevamente debe capturar los requisitos del
sistema actualizando el documento visión y seguir sus demás actividades. Si la validación de los
requisitos diera conformidad, entonces se parten dos actividades en paralelo, una en donde el
arquitecto de software en base a la especificación de los casos de uso y las especificaciones
suplementarias debe diseñar la arquitectura, y la otra en donde el tester en base a la especificación
de los casos de uso debe diseñar los casos de prueba. Luego que el arquitecto de software diseñe
la arquitectura y se obtenga un diagrama de arquitectura, debe elaborar el modelo de diseño que da
como resultado diagramas de clases y el modelo de datos. Con los artefactos del diseño, se inician
las actividades del programador que debe implementar la funcionalidad requerida y realizar las
pruebas unitarias. Si las pruebas unitarias dieran error, entonces el programador debe depurar la
funcionalidad implementada y luego volver a realizar las pruebas unitarias. En caso no se tengan
error en las pruebas unitarias, entonces el programa pasa al tester quien ya debe tener elaborado
los casos de prueba para ejecutar las pruebas funcionales y registrar los resultados de las pruebas.
Si los resultados de las pruebas funcionales dieran error, entonces el programador debe volver a
depurar la funcionalidad implementada y seguir el flujo de actividades. En caso no se tengan error
en las pruebas funcionales, el cliente debe realizar las pruebas de aceptación de las funcionalidades
implementadas en la iteración. Si las pruebas de aceptación dieran error, entonces el programador
debe volver a depurar la funcionalidad implementada y seguir el flujo de actividades. En caso no se
tengan error en las pruebas de aceptación, se da por finalizada la iteración y el gerente verifica si
existe una siguiente iteración. Si no existiera una siguiente iteración, entonces se cierra el proyecto
y el proceso termina. Pero, si existiera una siguiente iteración, entonces el gerente de proyecto debe
volver a planificar la siguiente iteración y seguir el flujo de actividades.

En base a la descripción del proceso anterior responda las siguientes preguntas:

6.
6. Marque en la última columna el código de la actividad que corresponde con el rol que lo realiza
(4ptos):

Códig Actividad Rol Código

o
A1 Elaborar modelos de diseño Analista A3(Arquitecto)
A4(Programador
A2 Realizar las pruebas unitarias Tester
)
A3 Elaborar el documento Visión Arquitecto A1(Analista)

A4 Registrar los resultados de las pruebas Programador A2(Tester)

7. Marque en la última columna el código del artefacto de entrada que corresponde con la
actividad que lo usa o necesita (4ptos):

Códig Artefacto de entrada Actividad Código

o
Especificación de los casos
A1 Depurar errores de programación A4
de uso
A3(Elaborar
Modelos de procesos de
A2 Implementar la funcionalidad el documento
negocio
visión)
A3 Funcionalidad implementada Elaborar el documento Visión A2

A4 Modelos de diseño Diseñar casos de pruebas A1

Pregunta para completar.

8. Escriba las actividades en orden de ejecución (4ptos):

Actividad anterior Actividad posterior

Definir un listado de Necesidades Elaborar el plan general
Analizar los modelos de procesos de
Elaboración del documento visión
negocio
Describir las necesidades y características
Analizar los requisitos del sistema y priorización
del sistema a desarrollar
Especificar casos de uso y especificaciones
Especificar los requisitos
suplementarias