GUÍA DE EXAMEN
Exámen de validación de
competencias profesionales
de paradigmas de desarrollo
de software.

 
 
 
 
 
 
 
 
  
 
 
 
 

 
 
 
 
Instrucciones
Deberás leer correctamente todo el contenido de ésta guía, ya que tiene como
propósito ofrecer información útil a quienes han de presentar el examen de validación
de competencias para el curso de Paradigmas de Desarrollo de Software.

La guía, te servirá únicamente como una asesoría en tu preparación para presentar el

examen de validación de competencias. Su lectura ayudará a familiarizarte con la estructura, y
el formato del mismo.

Recuerda que contarás con un lapso máximo de dos horas para realizer tu examen, por lo cual
te sugerimos que lleves un reloj, para así saber el la hora en la que empezaste y en la que
debes terminar.

Competencias a validar:

§ Emplear herramientas de ingeniería de software asistida por computadora.

§ Utilizar técnicas para la gestión y desarrollo de software.
§ Identificar las diferencias entre los diversos paradigmas de desarrollo de
software.
§ Aplicar el razonamiento lógico para la solución de problemas manejo de
información.
§ Solución de problemas de información empleando paradigmas de programación.

Objetivo del examen

Este examen tiene como objetivo ser un instrumento de validación de competencias para los
contenidos tratados en el curso de Paradigmas de Desarrollo de Software.

    2  
 
 
 
 
  
 
 
 
 

Metodología de la evaluación
El examen consta de una serie de reactivos de opción múltiple los cuales evalúan los
conocimientos sobre el curso.

Para acreditar el examen, el sustentante deberá responder correctamente como mínimo al

60% del total de las preguntas.
 

Temario

1. Generalidades.
1.1 Conceptos generales
1.2 Requisitos fundamentales que debe cumplir una metodología.
1.3 Evolución de los paradigmas de desarrollo de software.

2. Paradigma de desarrollo Estructurado.

2.1 Bloques elementales del sistema de información.
2.2 Ciclo de vida del desarrollo de sistemas.
2.3 Técnicas, metodologías y ciclos de vida.
2.4 Metodologías de desarrollo de software.

3. Paradigma de desarrollo orientado a objetos.

3.1 Conceptos básicos del paradigma orientado a objetos.
3.2 UML.
3.3 Descripción de las metodologías orientadas a objetos.
3.4 Metodologías orientadas a objetos más importantes.

4. El Proceso Unificado de Desarrollo de Software.

4.1 Antecedentes del Proceso Unificado de Desarrollo de Software.
4.2 Características del Proceso Unificado de Desarrollo de Software.
4.3 Las cuatro "P" en el Desarrollo de Software.

    3  
 
 
 
 
  
 
 
 
 

4.4 Fases del Proceso Unificado de Desarrollo de Software.

4.5 Flujos de Trabajo Fundamentales.

Bibliografía sugerida
• García, F. y Bravo, C. (2004). Metodologías de Desarrollo de Software. Consultado en junio 4,
2007 en: http://alarcos.inf-cr.uclm.es/per/fgarcia/isoftware/doc/tema3_1xh.pdf.

• Altamirano, L. (2003). Metodologías para generación de Sistemas Orientados a Objetos.

Consultado en junio 4, 2007 en: http://ccc.inaoep.mx/~labvision/doo/proy/T32.pdf. Whitten, J.,
Bentley, L., Barlow, V., (1996). Análisis y diseño de sistemas de información. Madrid: Mc-Graw
Hill.

• Ministerio de Administraciones Públicas (2007). Métrica Versión 3. Consultado en julio 2,

2007 en: http://www.csi.map.es/csi/metrica3/.

• Popkin, S. (2007). Diagramas de actividad. Consultado en julio 14, 2007 en:

http://es.tldp.org/Tutoriales/doc-modelado-sistemas-UML/multiple-html/x291.html.

• Programación orientada a objetos. Consultado en julio 15, 2007

en: http://es.wikipedia.org/wiki/Programaci%C3%B3n_orientada_a_objetos

• Jacobson, I., Booch, G., Rumbaugh, J., (2000). El Proceso Unificado de Desarrollo de Software.
Madrid: Addison Wesley.

Examen muestra

1. Es el conjunto de elementos que interactúan entre sí con el fin de apoyar las actividades
de una empresa o de un negocio.
a. Procesamiento de información
b. Almacenamiento de información
c. Sistema de información

    4  
 
 
 
 
  
 
 
 
 

d. Salida de información

2. Este requisito nos dice que la metodología debe estar soportada por herramientas
automatizadas que mejoren la productividad, tanto del ingeniero de software en particular,
como la del desarrollo en general.
a. Debe definir a los responsables de resultados
b. Debe ser pedagógica
c. Debe ser soportada por herramientas CASE
d. Debe ser la base de una comunicación efectiva

3. En la planificación de sistemas, esta etapa es un plan de selección de la tecnología de

información y el desarrollo de los sistemas de información necesarios para apoyar el
cometido de la empresa.
a. Etapa 1. Estudiar el cometido de la empresa
b. Etapa 2. Definir una arquitectura de información
c. Etapa 3. Análisis de áreas de empresa
d. Etapa 4. Codificación

4. En el diseño de sistemas esta vialidad es la encargada de analizar si los beneficios del

sistema compensarán los costos.
a. Viabilidad técnica
b. Viabilidad económica
c. Viabilidad operativa
d. Viabilidad de fechas

5. En el diseño de sistemas esta vialidad es la encargada de analizar si

los beneficios del sistema compensarán los costos.
a. Viabilidad técnica
b. Viabilidad económica
c. Viabilidad operativa
d. Viabilidad de fechas

    5  
 
 
 
 
  
 
 
 
 

6. En la metodología Merise, dentro del ciclo de abstracción este nivel indica cómo se hace,
concretándose en definir la estructura final del gestor a utilizar.
a. Conceptual
b. Organizacional
c. Operacional
d. Lógico

7. Esta etapa del ciclo de vida de un SI en Merise se realiza para cada dominio a estudiar. Se
parte de la situación existente, de la que se obtiene el Modelo Organizacional de
tratamientos (MOT) y el Modelo Lógico de Datos (MLD) actuales. Se elimina la organización
existente y se deduce el Modelo Conceptual de Tratamientos (MCT) y el Modelo Conceptual de
Datos (MCD) actuales.
a. Etapa1: Esquema director
b. Etapa 2: Estudio previo
c. Etapa 3: Estudio detallado
d. Etapa 4: Estudio técnico

8. En esta fase se somete el producto a prueba de un grupo mínimo de usuarios, se realizan

modificaciones en respuesta a las observaciones hechas por los usuarios.
a. Inicio
b. Elaboración
c. Construcción
d. Transición

9. Se inicia a partir del resultado del diseño y se construye el sistema en términos de

componentes (ficheros de código fuente, scripts, ficheros de código binario, ejecutables).
a. Requisitos
b. Análisis
c. Diseño
d. Implementación

10. Describe los requisitos del sistema en forma gráfica.

a. Diagrama de clases.
b. Diagrama de casos de uso.
c. Diagrama de secuencia.
d. Diagrama de colaboración.

    6  
 
 
 
 
  
 
 
 
 

Duración

Tienes un tiempo máximo de dos horas para la responder el examen, por lo que te
remendamos administrar bien tu tiempo al momento de presentarlo.

Especificaciones

Para presentar el examen, es necesario mostrar una identificación oficial con fotografía
(credencial de elector, cartilla militar, permiso de conducir, etc.).

La identificación debe de ser cotejada por el responsable del lugar donde se aplicará el
examen.

Para presentar el examen no necesitas llevar libreta, lápiz, calculadora o goma ya que el
examen es completamente en línea.

    7