Preguntas

# Pág. 39 El modelo espiral

* El modelo espiral fue propuesto por…

+ Barry Boehm

- Boehm Larry

- RiChard Matthew Stallman

- Bill Gates

- Dennis Ritchie

- Linus Torvalds

- James Gosling

# Pág. 39

** ¿Cuáles son las trayectorias del modelo espiral?

+ Planeación

+ Modelado

+ Construcción

+ Despliegue

+ Comunicación

- Implementación

- Desarrollo

# Pág. 47

** ¿Cuáles son las fases del proceso unificado?

+ Elaboración

+ Construcción

+ Transición

+ Producción

+ Concepción

- Modelamiento

- Etapa de requerimientos

# Pág. 49

* Es la actividad aislada de requerimientos y desarrolla las estimaciones tanto del tamaño como de los recursos. La

presente definición pertenece a…

+ Planeación

- Diseño de alto nivel

- Desarrollo

- Post mórtem

- Equipo de desarrollo

- Modelado de sistema

- Levantamiento de requerimientos

# Pág. 49

* Se determina la eficacia del proceso por medio de medidas y mediciones obtenidas (esta es una cantidad sustancial de datos que deben analizarse con métodos estadísticos). La presente definición pertenece a…

- Desarrollo

+ Post Mórtem

- Planeación

- Requerimientos

- Modelo de desarrollo

- Estrategias de implementación

- Diseño del sistema

# Pág. 49

* Se desarrollan las especificaciones externas para cada componente que se va construir y se crea el diseño de componentes. Esta definición pertenece a…

+ Diseño de alto nivel

- Planificación

- Desarrollo

- Post Mortem

- Plan de diseño de ejecución

- Modo de objetos

- Diseño de UML

# Pág. 65 - XP industrial.

** ¿Cuáles son las prácticas que incorpora IXP para garantizar el éxito de un proyecto XP?

+ Evaluación de la factibilidad.

+ Comunidad del proyecto.

+ Calificación del proyecto.

+ Administración orientada a pruebas.

+ Retrospectivas.

+ Aprendizaje continuo.

- retroalimentación.

# Pág. 66 -El debate XP.

** Son aspectos que destacan algunos críticos de la XP...

+ Volatilidad de los requerimientos.

+ Necesidades conflictivas del cliente.

+ Los requerimientos se expresan informalmente

+ Falta de un diseño formal.

- Los requerimientos se expresan informalmente.

- Metodologías ágiles

- No volatilidad de los requerimientos.

# Pág. 68 -Otros modelos ágiles de proceso.

** Es el más usado de todos los modelos ágiles de proceso...

* La programación extrema (XP).

- Desarrollo adaptativo de software (DAS).

- Scrum.

- Método de desarrollo de sistemas dinámicos (MDSD).

- Cristal.

- Desarrollo impulsado por las características (DIC).

- Modelado ágil(MA).

# Pág. 68 Desarrollo adaptativo de software(DAS).

** Según Highmith un "ciclo de vida" del DAS incorpora tres fases...

+ Especulación.

+ Colaboración.

+ Aprendizaje.

- Programación.

- Investigación.

- Diseño.

- Reingeniería.

# Pág. 69-70 Scrum.

** Son elementos del flujo del proceso Scrum...

+ Retraso.

+ Sprints.

+ Reuniones Scrum.

+ Demostraciones Preliminares.

- Jerarquía de requerimientos

- Organización.

- Análisis y Diseño.

# Pág. 71 Método de desarrollo de sistemas dinámicos(MDSD).

** El ciclo de vida del Método de desarrollo de sistemas dinámicos(MDSD) define ciclos iterativos y actividades que son...

+ Estudio de factibilidad.

+ Estudio del negocio.

+ Iteración del modelo funcional.

+ Diseño e iteración de la construcción.

+ Implementación.

- Estudio de mercado.

- Depuración.

#pág. 75 El proceso unificado ágil

** ¿Cuáles son las actividades que aborda cada iteración del PUA?

+ Modelado

+ Implementación

+ Pruebas

+ Despliegue

+ Configuración

+ Administración del ambiente

+ Administración

#pág. 76 CONJUNTO DE HERRAMIENTAS PARA EL PROCESO ÁGIL

** Herramientas para el proceso ágil. ¿Cuáles son herramientas de colaboración y comunicación de baja tecnología e incorporación?

+ Proximidad física

+ Pizarrones

+ Tableros

+ Tarjetas

+ Notas adheribles

- Computadoras

- Enciclopedias

#pág. 84 Principios que guían el proceso

** Identifique los principios fundamentales que se aplicación al proceso de software

+ Ser ágil

+ En cada etapa, centrarse en la calidad

+ Estar listo para adaptar

+ Formar un equipo eficaz

+ Establecer mecanismos para la comunicación y coordinación

+ Evaluar el riesgo

+ Administrar el cambio

#pág. 84 Principios que guían la práctica

** Identifique los principios que guían la práctica de la Ing. de software

+ Divide y vencerás

+ Entender el uso de la abstracción

+ Buscar la coherencia

+ Centrarse en la transferencia de información

+ Construir software que tenga modularidad eficaz

+ Buscar patrones

+ Tener en mente que alguien dará mantenimiento al software

#pág. 84 Principios de comunicación

** Identifique los principios de comunicación dentro de un proyecto de software

+ Escuchar

+ Antes de comunicarse, prepararse

+ Alguien debe facilitar la actividad

+ Es mejor la comunicación cara a cara

+ Tomar notas y documentar las decisiones

+ Perseguir la colaboración

+ Permanecer centrado hacer módulos con la discusión

#pág. 83 CONOCIMIENTO DE LA INGENIERÍA DE SOFTWARE

** Muchos trabajadores del software piensan que el conocimiento de la IS consiste en tecnologías específicas ¿Cuáles son?

+ Java

+ Perl

+ HTML

+ C++

+ Linux

+ Windows NT

- MYSQL

#pág 87 - Principios de comunicación

** Es un principio de comunicación...

+ Antes de comunicarse, prepararse.

+ Alguien debe facilitar la actividad.

+ Es mejor la comunicación cara a cara.

+ Tomar notas y documentar las decisiones.

+ Perseguir la colaboración.

+ Permanecer centrado; hacer módulos con la discusión.

+ Si algo no está claro, hacer un dibujo.

#pág. 88 - Principios de Planeación

** Es un principio de planeación...

+ Entender el alcance del proyecto.

+ Involucrar en la actividad de planeación a los participantes del software.

+ Reconocer que la planeación es iterativa.

+ Estimar con base en lo que se sabe.

+ Al definir el plan, tomar en cuenta los riesgos.

+ Ser realista.

+ Ajustar la granularidad cuando se defina el plan.

#pág. 90 - Principio de modelado

** Es un principio de modelado...

+ El equipo de software tiene como objetivo principal elaborar software, no crear modelos.

+ Viajar ligero, no crear más modelos de los necesarios.

+ Tratar de producir el modelo más sencillo que describa al problema o al software.

+ Construir modelos susceptibles al cambio.

+ Ser capaz de enunciar un propósito explícito para cada modelo que se cree.

+ Adaptar los modelos que se desarrollan al sistema en cuestión.

+ Tratar de construir modelos útiles, pero olvidarse de elaborar modelos perfectos.

#Pág. 94 - Principios de construcción

** En el trabajo de ingeniería de software moderna, la codificación puede ser...

- Demasiado sencilla

- Demasiado complicada

- No es necesario codificar

- Solamente depende de un lenguaje de programación

+ La creación directa de lenguaje de programación en código fuente.

+ La generación automática de código fuente que usa una representación intermedia parecida al diseño del componente que se va a construir

+ La generación automática de código ejecutable que utiliza un “lenguaje de programación de cuarta generación”

# Pág. 94 - Principio de programación

** En los principios de programación, cuando se comienza a escribir código debemos asegurarnos de...

+ Restringir sus algoritmos por medio del uso de programación estructurada.

+ Tomar en consideración el uso de programación por parejas.

+ Seleccionar estructuras de datos que satisfagan las necesidades del diseño.

+ Entender la arquitectura del software y crear interfaces que son congruentes con ella.

+ Mantener la lógica condicional tan sencilla como sea posible.

+ Escribir código que se documente a sí mismo.

+ Crear una imagen visual que ayude a entender.

# pág. 95 - principios de validación

** En los principios de validación, una vez que se haya terminado el primer intento de codificación, nos aseguramos de:

+ Realizar el recorrido del código cuando sea apropiado.

+ Llevar a cabo pruebas unitarias y corregir los errores que se detecten.

+ Rediseñar el código.

- Escribir código que se documente a sí mismo.

- Crear una imagen visual que ayude a entender.

- Restringir sus algoritmos por medio del uso de programación estructurada.

- Tomar en consideración el uso de programación por parejas.

#102 Ingeniería de requerimientos

** La Ingeniería de requerimientos incluye las siguientes tareas...

+ Concepción

+ Indagación

+ Elaboración

+ Negociación

+ Especificación

+ Validación

+ Administración


** La ingeniería de requerimientos proporciona el mecanismo apropiado para...

+ Entenderlo que desea el cliente

+ Analizar las necesidades

+ Evaluar la factibilidad

+ Negociar una solución razonable

+ Especificar la solución sin ambigüedades

+ Validar la especificación

+ Administrar los requerimientos


** Christel y Kang identificaron ciertos problemas que se encuentran cuando ocurre la indagación...

- Problemas de costos

- Problemas de tiempo

- Problemas de espacio

+ Problemas de alcance

+ Problemas de entendimiento

+ Problemas de volatilidad

- Problemas de personal


** ¿Cuáles son los lineamientos básicos para conducir una reunión para recabar los requerimientos en forma colaborativa?

+ Tanto ingenieros de software como otros participantes intervienen en las reuniones.

+ Se establecen reglas para la preparación y participación.

- Se sugiere una agenda con suficiente formalidad para cubrir todos los puntos importantes.

+ Se sugiere una agenda con suficiente formalidad para cubrir todos los puntos,pero con la suficiente informalidad para la estimulación de ideas.

- Se sugiere una agenda totalmente informal para el flujo de ideas.

+ Un “facilitador” controla la reunión.

+ Se utiliza un “mecanismo de definición”


** La meta de la recabación de los requerimientos en forma colaborativa es...

+ Identificar el problema

+ Proponer elementos de la solución

+ Negociar distintos enfoques

+ Especificar un conjunto preliminar de requerimientos de la solución

- Desarrollar listas de restricciones.

- Eliminar las ideas redundantes.

- Poder realizar sólo una sesión de preguntas.

#106 Comprensión de requerimientos

** Candidatos habituales en la identificación de los participantes...

+ Gerentes de operaciones del negocio

+ Gerentes de producto

+ Personal de mercadotecnia

+ Clientes internos y externos

+ Usuarios finales

+ Consultores

+ Ingenieros de software

# Pág. 111 - Comprensión de los Requerimientos

** El despliegue de la función de calidad identifica tres tipos de requerimientos...

+ Requerimientos Normales.

- Requerimientos Informales.

- Requerimientos Inesperados.

+ Requerimientos Esperados.

- Requerimientos Impuntuales.

+ Requerimientos Emocionantes.

- Requerimientos Intrigantes


** Para la mayoría de sistemas, los productos del trabajo incluye lo siguiente...

+ Un enunciado de la necesidad y su factibilidad.

+ Un enunciado acotado del alcance del sistema o producto.

+ Una lista de clientes, usuarios y otros participantes.

+ Una descripción del ambiente técnico del sistema.

+ Una lista de requerimientos y restricciones de dominio.

+ Un conjunto de escenarios de uso.

+ Cualesquiera prototipos desarrollados para definir requerimientos.


** Según Jacobson [Jac92], ¿Cuáles de las siguientes preguntas sugiere para responder un caso de uso?

+ ¿Quién es el actor principal y quién(es) el(los) secundario(s)?

+ ¿Cuáles son los objetivos de los actores?

+ ¿Qué precondiciones deben existir antes de comenzar la historia?

+ ¿Qué tareas o funciones principales son realizadas por el actor?

+ ¿Qué excepciones deben considerarse al describir la historia?

+ ¿Cuáles variaciones son posibles en la interacción del actor?

+ ¿Qué información del sistema adquiere, produce o cambia el actor?


** La mayoría de requerimientos tienen en común un conjunto de elementos generales como...

+ Elementos basados en el escenario.

- Elementos basados en los objetos.

+ Elementos basados en las clases.

+ Elementos del comportamiento.

+ Elementos orientados al flujo.

- Elementos orientados a los clientes.

- Elementos orientados al análisis.


** Según Boehm [Boe98], en lugar de una sola actividad de comunicación con el cliente, se definen las siguientes actividades...

+ Identificación de los participantes clave del sistema o subsistema.

+ Determinación de las "Condiciones para ganar" de los participantes.

+ Negociación de las condiciones para ganar de los participantes.

+ Reconciliar el conjunto de condiciones ganar-ganar para todos los que intervienen.

- Identificar las fortalezas del sistema.

- Identificar las debilidades del sistema.

- Identificar los defectos del sistema.


** La revisión del modelo de requerimientos aborda las siguientes preguntas...

+ ¿Es coherente cada requerimiento con los objetivos generales del sistema o producto?

- ¿Es coherente la ganancia con el beneficio que la empresa percibirá producto del sistema?

+ El requerimiento, ¿es realmente necesario o representa una característica agregada que tal vez no sea esencial para el objetivo del sistema?

+ ¿Cada requerimiento está acotado y no es ambiguo?

+ ¿Tiene atribución cada requerimiento? Es decir, ¿hay una fuente (por lo general una individual y específica) clara para cada requerimiento?

+ ¿Hay requerimientos en conflicto con otros?

+ Una vez implementado cada requerimiento, ¿puede someterse a prueba?

#Pág. 136-Escritura de un caso de uso formal.

* ¿Qué identifica el disparador (o trigger)?

+ Identifica el evento o condición que “hace que comience el caso de uso”.

- Un objeto de datos.

- Un modelo de datos como parte del modelado.

- Atributos de los datos

- Relaciones

- Modelado basado en clases

- Identifica las clases de análisis.

#Pág: 138-Diagramas de canal (swimlane)

** Un diagrama de canal (swimlane)…

+ Representa el flujo de acciones y decisiones.

+ Indica qué actores efectúan cada una de ellas.

- Atributos de datos.

- Objetos de datos.

- Relaciones.

- No representa el flujo de acciones y decisiones.

- No indica que actores efectúan cada una de ellas.

** ¿Cuáles son las tres clases de análisis?

+ Propietario

+ Cámara

+ Interfaz

- Datos

- Canal

- Mensaje

- Gráficos

#Pág.143-144-Identificación de las clases de análisis

** Budd sugiere una taxonomía de clases que incluye…

+ Productores (fuentes).

+ Consumidores (sumideros) de datos.

+ Administradores de datos.

+ Vista.

+ Clases de observador.

+ Clases de auxiliares.

- Clases de datos.

** Coad y Yourdon sugieren seis características en el modelo de análisis y son…

+ Información retenida.

+ Servicios necesarios.

+ Atributos múltiples.

+ Atributos comunes.

+ Operaciones comunes.

+ Requerimientos esenciales.

- Objeto de datos.

#Pág.146-Definición de las operaciones

** Existen muchos tipos distintos de operaciones, se dividen en cuatro categorías principales….

+ Operaciones que manipulan datos en cierta manera.

+ Operaciones que realizan un cálculo.

+ Operaciones que preguntan sobre el estado de un objeto

+ Operaciones que vigilan un objeto de un evento de control.

- Operaciones que no manipulan datos.

- Operaciones que no realizan un cálculo.

- Operaciones que no pregunten sobre el estado de un objeto.

#Pág. 148 Modelo CRC: Colaboración, Asociaciones y Dependencias

** Son afirmaciones correctas acerca del Modelado clase-responsabilidad-colaborador

+ Proporciona una manera sencilla de identificación y organización de las clases.

+ Es un conjunto de tarjetas índice estándar que representan clases.

+ Las tarjetas se dividen en tres secciones.

+ Estas tarjetas indican el nombre de la clase, las responsabilidades de la misma y los colaboradores.

+ Las responsabilidades son los atributos y operaciones relevantes para la clase.

+ Las tarjetas CRC fallaran con frecuencia y en forma barata evitan desechar gran cantidad de código fuente.

- NO son relevantes para los requerimientos de un sistema o producto.

#Pág. 149

** Pertenecen a la taxonomía de tipos de clase

+ Clase de Entidad

+ Clase de Modelo

+ Clase de Negocio

+ Clase de Frontera

+ Clase de Controlador

- Clase de Sistema

- Clase de Objetos

#Pág. 150

** Recomendaciones para asignar responsabilidades (atributos y métodos) a las clases.

+ Distribuir la inteligencia del sistema entre todas las clases.

+ Cada responsabilidad debe enunciarse del modo más general posible.

+ La responsabilidad asignada a una clase deberá ser de una tipología de encapsulamiento.

+ Generalizar las características de los objetos del sistema en una sola clase.

+ Cuando sea apropiado, las responsabilidades deben compartirse entre clases relacionadas.

- Las clases deberán manejar distintos tipos de información.

- La concentración de la inteligencia del sistema se revela a partir de la concentración de responsabilidades.

#Pág. 151

** Afirmaciones acerca de la responsabilidad Colaboración de una Clase.

+ Una clase cumple con su responsabilidad cuando manipula sus métodos y atributos.

+ Una clase cumple con su responsabilidad cuando colabora con otras clases.

+ Si una clase no puede cumplir una responsabilidad, entonces esta necesita interactuar con otra clase.

+ Es-parte-de, es un tipo relación de colaboración,

+ Tiene-conocimiento-de, es un tipo relación de colaboración.

+ Depende-de, es un tipo relación de colaboración.

- Una clase cumple con su responsabilidad cuando instancia objetos.

#Pág. 152

** Pautas para la revisión de un modelo CRC:

+ Los participantes de la revisión manipularán las tarjetas que no colaboren entre si.

+ Los escenarios de casos de uso (y demás diagramas) deben organizarse en dos categorías.

+ Se da lectura a los casos de uso, cuando se identifica un objeto se entrega una ficha a la persona propietaria de la tarjeta.

+ El poseedor de la tarjeta deberá describir las responsabilidades y evaluar (todos los presentes) el cumplimiento de los requerimientos.

+ Si no hay satisfacción de requerimientos, se modifican las responsabilidades y colaboraciones.

- Los escenarios de casos de uso (y demás diagramas) deben organizarse en varias categorías.

- Los requerimientos deben ajustarse a las responsabilidades y colaboraciones de las tarjetas.

#Pág. 153-154

** Afirmaciones acerca del tipo de relación Asociación y Dependencia.

+ Dos clases de análisis se relacionan de forma parecida a como indica el modelado UML.

+ Una asociación puede definirse si se indica multiplicidad.

+ La multiplicidad se define por las relaciones "uno a uno", "uno a muchos", "cero a muchos"

+ Las dependencias están definidas por un estereotipo.

+ Un estereotipo define un elemento especial con semántica y especialización determinadas.

- Una asociación puede definirse si se indica herencia.

- Las dependencias están definidas por un paradigma.

#Pág.176 - Salida del modelado de los requerimientos

** Si bien los modelos específicos dependen en gran medida de la naturaleza de la webapp, hay cinco clases principales y son...

+ Modelo de contenido

+ Modelo de interacción

+ Modelo funcional

+ Modelo de navegación

+ Modelo de configuración

- Modelo evolutivo

- Modelo incremental

#Pág.177 - Modelo de la interacción de la webapps.

** La gran mayoría de webapps permiten una “conversación” entre un usuario final y funcionalidades, y se describe con el uso de un modelo de interacción que se compone de los siguientes elementos...

+ Casos de uso.

+ Diagramas de secuencia.

+ Diagramas de estado.

+ Prototipos de la interfaz de usuario.

- Diagramas sql

- Diagrama web

- Programación

#Pág.174 - Modelado de requerimientos para Webapps

** El grado en el que se profundice en el modelado de los requerimientos para las webapps depende de los factores siguientes...

+ Tamaño y complejidad del incremento de la webapp.

+ Número de participantes.

+ Tamaño del equipo de la webapp.

+ Grado en el que los miembros del equipo han trabajado juntos antes.

+ Medida en la que el éxito de la organización depende directamente del éxito de la webapp.

- interfaces mal diseñadas

- calidad del software

#Pág.175 - Salida del modelado de los requerimientos

* El análisis de los requerimientos provee...

+ un mecanismo disciplinado para representar y evaluar el contenido y funcionamiento de las webapp

- Fomenta el desorden en el grupo

- Dinero para la implementación

- los diagramas implementados

- una metodología desarrollada

- un diseño completo de las interfaces

- un sistema de información desarrollado

#Pág.176 - Salida del modelado de los requerimientos.

* Es posible desarrollar cada uno de estos modelos con el empleo de un esquema de representación llamado...

+ "lenguaje"

- "lengua"

- "interfaz"

- "mapa mental"

- "lenguaje de programación"

- "implementación"

- "conceptual"

#Pág.178 - Modelo funcional para las Webapps

** El modelo funcional enfrenta dos elementos de procesamiento en la webapp...

+ funciones observables por los usuarios que entrega la webapp

+ las operaciones contenidas en las clases de análisis que implementan comportamientos asociados con la clase.

- funciones anidadas

- funciones abstractas

- funciones operacionales

- funciones de análisis de requerimientos

- operaciones en la investigación de requerimientos

# Pág. 183 Tema: Conceptos de Diseño

* Creador de Lotus 1-2-3, publicó en Dr. Doobs Journal un "Manifiesto del diseño de software"...

+ Mitch Kapor

- Robbie Parker

- Peter Williams

- Robert Lautner

- Taylor Pattinson

- Jackson Rathbone

- Ashley Greene

# Pág. 184 Tema: Conceptos de Diseño

** La diversificación y la convergencia combinan ....... y ....... con base en la experiencia en la construcción de entidades similares

+ Intuición

+ Criterio

- Hardware

- Software

- Aplicación

- Simulación

- Disciplina

# Pág. 184 Tema: Diseño en el contexto de la Ingeniería de Software

** El empleo de la notación y de los métodos de diseño estudiados en los últimos capítulos produce diseños de...

+ Los datos o clases

+ La arquitectura

+ La interfaz

+ Los componentes

- La estructura

- Los fundamentos

- Los diagramas

# Pág. 185 Tema: Diseño en el contexto de la Ingeniería de Software

* La importancia del diseño del software se resumen en una palabra...

+ Calidad

- Esfuerzo

- Dedicación

- Esmero

- Eficacia

- Prioridad

- Cantidad

# Pág. 187-188 Tema: Atributos de calidad de "El proceso de diseño"

** Los atributos de calidad FURPS representan el objetivo de todo diseño de software...

+ Funcionalidad

+ Usabilidad

+ Confiabilidad

+ Rendimiento

+ Mantenibilidad

- Abstracción

- Ajustabilidad

# Pág. 194 Tema: Aspectos de "Conceptos de diseño"

** Conforme tiene lugar el análisis de los requerimientos, surge un conjunto de "preocupaciones" que incluyen...

+ Requerimientos

+ Casos de uso

+ Características

+ Estructuras de datos

+ Calidad del servicio

+ Variantes

+ Fronteras

#Marco Carrillo Colque

#196 CLASES DE DISEÑO

** Son clases de diseño

+ Clases de usuario de la interfaz

+ Clases del dominio de negocios

+ Clases de proceso

+ Clases persistentes

+ Clases de sistemas

- Clases de implementación

- Clases de dominio

#197 MODELO DE DISEÑO

* La dimensión del proceso indica...

+ La evolución del modelo de diseño conforme se ejecutan las tareas de este

- La evolución del modelo de diseño del dominio

- La evolución del modelo de la implementación

- La evolución del modelo de diseño de la interfaz

- La evolución del modelo de diseño de análisis

- La evolución del modelo de procesos

- La evolución del modelo de arquitectura


* La dimensión de la abstracción representa...

+ El nivel de detalle conforme cada elemento del modelo de análisis se transforma en un equivalente de diseño

- El nivel de detalle conforme cada elemento del diseño se transforma en un equivalente de diseño

- El nivel de detalle conforme cada usuario del diseño se transforma en un equivalente de diseño

- El nivel de análisis conforme cada elemento del diseño se transforma en un equivalente de diseño

- El nivel de detalle conforme cada elemento del diseño se transforma en un equivalente de abstracción

- El nivel de abstracción conforme cada elemento del diseño se transforma en un equivalente de diseño

- El nivel de detalle conforme cada grafico del diseño se transforma en un equivalente de diseño


* La línea punteada indica...

+ La frontera entre los modelos de análisis y diseño

- La frontera entre los modelos de abstracción y diseño

- La frontera entre los modelos de análisis y abstracción

- La frontera entre los modelos de arquitectura y diseño

- La frontera entre los modelos de análisis y arquitectura

- La frontera entre los modelos de interfaz y diseño

- La frontera entre los modelos de análisis y interfaz

#199 ELEMENTOS DE DISEÑO DE LA INTERFAZ

* El diseño de software comienza cuando...

+ Termina la primera iteración de la ingeniería de requerimientos

- Termina la primera iteración del diseño de la interfaz

- Termina la primera iteración del diseño de base de datos

- Termina la primera iteración del análisis

- Comienza la primera iteración del diseño de interfaz

- Comienza la primera iteración del diseño de base de datos

- Comienza la primera iteración del análisis

#203 ELEMENTOS DEL DISEÑO DE DESPLIEGUE

* El objetivo del diseño de software es...

+ Aplicar un conjunto de principios, conceptos y prácticas que llevan al desarrollo de un producto de calidad

- Aplicar un conjunto de principios que llevan al desarrollo de una arquitectura de calidad

- Aplicar un conjunto de principios que llevan al desarrollo de una interfaz de calidad

- Aplicar un conjunto de principios que llevan al desarrollo de una base de datos de calidad

- Aplicar un conjunto de principios que llevan al desarrollo de un análisis de calidad

- Aplicar un conjunto de principios que llevan al desarrollo de una abstracción de calidad

- Aplicar un conjunto de principios que llevan al desarrollo de una gestión de calidad

#Pág. 207 Arquitectura de software

* Según Bass, Clements y Kazaman, ¿Qué es la arquitectura del software?

+ Es la estructura o estructuras del sistema, lo que comprende componentes del software, sus propiedades externas visibles y las relaciones entre ellos.

- Es la estructura o estructuras del sistema, lo que comprende componentes del hardware, sus propiedades externas visibles y las relaciones entre ellos.

- Es la parte del hardware, el computador y sus componentes como el procesador, memoria ram, etc.

- Es el software Operativo

- Son las licencias que nos permiten trabajar sin romper las leyes.

- Se refiere a la BD, sus tablas, campos y registros.

- Es la parte no visible del software.

#Pág. 207 Arquitectura del software

**La arquitectura no es el software operativo. Es una representación que permite...

+ Analizar la efectividad del diseño para cumplir los requerimientos establecidos.

+ Considerar alternativas arquitectónicas en una etapa en la que hacer cambios al diseño todavía es relativamente fácil.

+ Reducir los riesgos asociados con la construcción del software.

- Aumentar los riesgos asociados con la construcción del software.

- Considerar alternativas arquitectónicas en una etapa en la que hacer cambios al diseño es sumamente compleja.

- Despedir al personal que no tenga la misma visión que el resto.

- Aumentar el plazo de entrega del trabajo, con lo cual se logra ganar más dinero.

#Pág. 208 Arquitectura de software

** Razones clave por las cuales es importante la arquitectura del software...

+ Las representaciones de la arquitectura del software permiten la comunicación entre todas las partes interesadas (participantes).

+ La arquitectura resalta las primeras decisiones que tendrán un efecto profundo en todo el trabajo de ingeniería de software siguiente.

+ La arquitectura constituye un modelo relativamente pequeño y asequible por la vía intelectual sobre cómo está estructurado el sistema.

- Porque las representaciones de la arquitectura evitan la comunicación entre las partes interesadas (participantes).

- La arquitectura resalta las conclusiones finales las cuales sirven para evaluar el producto final.

- La arquitectura constituye un modelo grande y asequible por la vía intelectual sobre cómo está estructurado el sistema.

- Porque el modelo del diseño de la arquitectura y los patrones arquitectónicos contenidos dentro de estos son intransferibles.

#Pág. 209 Descripciones Arquitectónicas

** IEEE Computer Society hizo la propuesta IEEE-Std-1471-2000, Recommended Practice for Architectural Description of Software-Intensive Systems, con los siguientes objetivos...

+ Establecer un marco conceptual con un vocabulario que se use durante el diseño de la arquitectura del software.

+ Proporcionar lineamiento detallados para representar una descripción arquitectónica.

+ Estimular las mejores prácticas del diseño arquitectónico.

- Incentivar a los jóvenes a elegir una carrera relacionada con el desarrollo de software.

- Estimular las prácticas libres, sin reglas del diseño arquitectónico.

- Generar ingresos adicionales, con la venta de su propuesta a los desarrolladores.

- Proporcionar lineamientos confusos para representar una descripción arquitectónica.

#Pág. 210 Géneros Arquitectónicos

** En su texto evolutivo Handbook of Software Architecture [Boo08], Grady Booch sugiere los siguientes géneros arquitectónicos para sistemas basados en software...

+ Inteligencia Artificial

+ Comerciales y no lucrativos

+ Comunicaciones

+ Dispositivos

+ Financieros

+ Juegos

+ Médicos

#Pág. 212 Estilos Arquitectónicos

** El software construido para sistemas basados en computadora tiene uno de muchos estilos arquitectónicos. Cada estilo describe una categoría de sistemas que incluye...

+ Un conjuto de componentes que realizan una función requerida por el sistema.

+ Un conjunto de conectores que permiten la comunicación, coordinación y cooperación entre los componentes.

+ Restricciones que definen cómo se integran los componentes para formar el sistema.

+ Modelos semánticos que permiten que un diseñador entienda las propiedades generales del sistema al analizar las propiedades conocidas de sus partes constituyentes.

- Un conjunto de conectores que no permiten la comunicación normal entre los componentes.

- Restricciones que definen cuanto se debe cobrar por el software.

- Un conjunto de componentes que optimizan el consumo de energía eléctrica.

#Kevin Flores Chambilla

#Pág. 213 - Breve taxonomía de estilos de arquitectura

** Es verdad que las arquitecturas centradas en los datos

+ Promueven la integrabilidad

+ En el centro de esta arquitectura se halla un almacenamiento de datos.

+ Los componentes del software pueden ser cambiados y agregarse otros nuevos.

- Promueven la inestabilidad

- Afuera de esta arquitectura se halla un almacenamiento de datos.

- Los componentes del software no pueden ser cambiados.

+ Accede frecuentemente a componentes que actualizan, agregan, eliminan o modifican los datos.


* No es verdad sobre las Arquitecturas de flujo de datos

- Se aplica cuando los datos de entrada se transforman en datos de salida a traves de varios componentes

- Tiene un Conjuntos de componentes llamados filtros

- Los filtros transmiten datos de un componente a otro

- Cada filtro trabaja de forma independiente de componentes que están arriba y abajo del flujo

- Se denomina lote secuencial, al flujo de datos degenerado en una sola línea de transformaciones

+ El filtro requiere conocimientos de los trabajos realizados de otros filtros.

- Acepta estructura con lote de datos


** Son algunos estilos de arquitecturas

+ Arquitecturas centradas en los datos.

+ Arquitecturas de flujo de datos.

+ Arquitecturas de llamar y regresar.

+ Arquitecturas orientadas a objetos

+ Arquitecturas en capas.

+ Arquitecturas de programa principal/subprograma.

- Arquitecturas Secuenciales

#Pág. 215 - Patrones Arquitectónicos

** Patrones Arquitectónicos

+ Se aboca dentro de a un problema de aplicación especifica

+ El patrón propone una solución arquitectónica que sirve como base en el diseño de arquitectura.

- No enfrenta problemas amplios que abarca toda la aplicación.

- Hay pocas limitantes y restricciones que no afectan la manera de resolver el problema.

+ Este estilo encontrara problemas comunes que se abordan con patrones arquitectónicos específicos.

- El aboca a un problema de aplicación que no se puede hallar.

- No presenta apoyo en la resolución de problemas de aplicaciones específicas.

#Pág. 217 - Diseño Arquitectónico

** Sistemas que interactúan con el sistema objetivo representados por

+ Sistemas Superiores

+ Sistemas Subordinados

+ Sistemas entre iguales

+ Actores

- Sistemas Vecinos

- Sistemas Enlazados

- Sistemas Trenzados

#Pág. 218 - Definición de Arquetipo

* Un Arquetipo es ...

+ Una clase o un patrón que representa una abstracción fundamental de importancia crítica para el diseño de una arquitectura para el sistema objetivo.

- Son usados por el sistema objetivo y proveen datos o procesamiento.

- Se comunica con el sistema objetivo a través de una interfaz

- La información usada o producida por el software de seguridad.

- Se utilizan por el software de seguridad y se muestran como subordinados a éste.

- Un conjunto de herramientas y notación estandarizadas que permiten que el diseño se represente sin ambigüedades.

- Es el riesgo se preocupa por los acontecimientos futuros.

# Luis eduardo gamero sandoval

#Pág. 219 tema Refinamiento de la arquitectura hacia los componentes

** ¿Cuáles son los componentes de la infraestructura que hacen posible los componentes de la aplicación, pero no tienen conexión con el dominio de ésta?

+ Administración de memoria

- Entidades

+ Comunicación

- Dominio

+ Base de datos

- Aplicación

+ Administración de tareas

#Pág. 220 Refinamiento de la arquitectura hacia los componentes

** El conjunto de componentes de alto nivel sigue las siguientes funciones...

+ Administración de la comunicación externa

+ Procesamiento del panel de control

+ Administración de detectores

+ Procesamiento de alarmas

- Estimar costo y esfuerzo

- Desarrollar un calendario del proyecto

- Estructuras

#Pág. 222 Método de la negociación para analizar la arquitectura

** ¿Cuáles son las actividades de análisis de diseño que se mencionan en el método de la negociación para analizar la arquitectura?

+ Escenarios de investigación

+ Obtención de los requerimientos y restricciones, y descripción del ambiente

+ Descripción de los estilos o patrones de arquitectura elegidos para abordar los escenarios y requerimientos

+ Evaluación de los atributos de calidad, considerando cada atributo por separado

+ Identificación de la sensibilidad de los atributos de calidad de varios atributos arquitectónicos para un estilo de arquitectura específico

+ Crítica de las arquitecturas candidatas con el uso del análisis de sensibilidad

- Escenarios de ayuda

#Pág. 222 Método de la negociación para analizar la arquitectura

** En la descripción de los estilos o patrones de arquitectura elegidos para

abordar los escenarios y requerimientos, marque las perspectivas que tiene

+ Perspectiva modular

+ Perspectiva del proceso

+ Perspectiva del flujo de datos

- Perspectiva de datos

- Perspectiva de flujo

- Perspectiva de funciones

- Perspectiva de atributos

#Pág. 224 Complejidad arquitectónica

** La complejidad arquitectónica considera las dependencias entre los componentes de la arquitectura, marque cuales son…

+ Las dependencias compartidas

+ Las dependencias de flujo

+ Las dependencias de restricción

- Las dependencias de recursos

- Las dependencias de red

- Las dependencias de Componentes COTS

- Las dependencias de Componentes nuevos

#Pág. 224 Complejidad arquitectónica

** En la técnica de mapeo llamado diseño estructurado, tiene los siguientes pasos...

+ Se establece el tipo de flujo de información

+ Se indican las fronteras del flujo

+ Se mapea el DFD en la estructura del programa

+ Se define la jerarquía del control

+ Se refina la estructura resultante con el empleo de criterios de medición para el diseño y heurísticos

+ Se mejora y elabora la descripción arquitectónica

- Se mejora los Componentes

#Silvana Beatriz Cabana Yupanqui

#Pág. 231 Diseño de la arquitectura

* El refinamiento de la arquitectura del software de estimularse en...

+ Las primeras etapas del diseño

- Las últimas etapas del diseño

- Refinando y evaluando en busca del "mejor" enfoque

- En la optimización del diseño

- En todas las etapas del proyecto

- En ninguna etapa del diseño

- Luego de haber realizado el front-end.

#Pág. 239 Diseño de nivel de componentes

** En medida que avanza el trabajo de diseño se dispone de...

+ un catálogo de diseño probado.

+ un catálogo de componentes o patrones de diseño.

- un catálogo de métodos de programación.

- una base de datos concurrentes.

- un catálogo de personas involucradas en el proyecto.

- un registro donde almacenamos todos los cambios.

+ la visión relacionada con el proceso.


** Es el encargado de ilustrar la estructura y organización de los componentes del software

- El diseño front-end

+ La arquitectura del software

+ El que también está encargado de proporcionar una visión holística del sistema.

- El análisis del sistema

- La encargada también de la visión paralela en el software.

- Los requerimientos del sistema

- Los requisitos del sistema.


* El diseñador identifica un conjunto de abstracciones de alto nivel que también son llamados...

- architipos

+ arquetipos

- diseños metodológicos

- Infraestructura TI

- tipos de datos

- tipos recurrentes

- tipos metodológicos

- tipos arquitectónicos del diseño


** El diagrama de flujo de datos se mapea...

+ Con el uso del enfoque del mapeo de la transformación

+ En una estructura que asigna el control a la entrada

+ En una estructura que asigna el control al procesamiento

+ En una estructura que asigna el control a la salida

- En una estructura matemática

- En una estructura física

- En una estructura no listada en el proceso de ingeniería

#Pág. 234 Diseño de nivel de componentes

** Un enfoque alternativo consiste en representar el diseño en el nivel de los componentes en alguna representación intermedia como...

- En booleano

+ Grafica

- En pulsaciones

+ Basada en texto

- Oral

+ Tabulada

- En pulsaciones de luz

#Jose Luis Lanchipa Jilaja

#243 DISEÑO EN EL NIVEL DE COMPONENTES

* ¿Qué es cohesión, según el concepto de diseño?

+ Unidad de objetivo de un componente

- Unión de los componentes

- Adherir partes

- Trabajar en conjunto

- Participar en grupo

- Hacer un buen uso del hardware

- Que el software este compacto

#243 DISEÑO EN EL NIVEL DE COMPONENTES

** Los Tipos de cohesión...

+ Funcional

+ De capa

+ De comunicación

- De enlace

- De componente

- De clase

- Relacional

#244-245 DISEÑO EN EL NIVEL DE COMPONENTES

** Las categorías del nivel de componentes son...

+ Acoplamiento de contenido

+ Acoplamiento común

+ Acoplamiento del control

+ Acoplamiento de molde

+ Acoplamiento de datos

+ Acoplamiento de rutina de llamada

+ Acoplamiento de tipo de uso

#246-251 REALIZACIÓN DEL DISEÑO EN EL NIVEL DE COMPONENTES

** Pasos para el diseño en el nivel de componentes

+ Identificar todas las clases de diseño que correspondan al dominio del propietario

+ Identificar todas las clases de diseño que correspondan al dominio de la infraestructura

+ Elaborar todas las clases de diseño que no sean componentes reutilizables

+ Describir las fuentes persistentes de datos e identificar las clases requeridas para administrarlos

+ Desarrollar y elaborar representaciones del comportamiento para una clase o componente

+ Elaborar diagramas de despliegue para dar más detalles de la implantación

+ Rediseñar cada representación del diseño en el nivel de componentes y considerar alternativas

#251 DISEÑO EN EL NIVEL DE COMPONENTES PARA WEBAPPS

* ¿Qué es un componente de webapps?

+ Una función cohesiva bien definida que manipula contenido

- Es un parte fundamental de una aplicación

- Encargado del enlace de la aplicación

- Capa encargada del diseño

- Capa encargada del protocolo

- Caso de uso que se encarga del enlace

- Es aquel que se hace después de un despliegue webapps

#254 NOTACIÓN DEL DISEÑO TABULAR

** Para desarrolar una tabla de decisión

+ Enlistar todas las acciones asociadas con un procedimiento

+ Enlistar todas las condiciones

+ Asociar conjuntos específicos de condiciones con acciones específicas

+ Definir reglas indicando que acciones suceden para un conjunto dado de condiciones

- Enmarcar todas las acciones de la webapps

- Agrupar los componentes ya definidos en el diseño

- Asociar los componentes ya definidos en la interfaz

#Alfredo Néstor Juanillo Mamani

#255

** El lenguaje de diseño de programa (LDP), es también llamado…

+ Castellano estructurado.

+ Seudocódigo.

- Bloque estructurado.

- Bloque no estructurado.

- Idioma estructurado.

- Semi-Seudocódigo.

- Cableado estructurado.

#257

** En el enfoque general del análisis del dominio los pasos de este proceso se definen como sigue…

+ Definir el dominio que se va a investigar.

+ Clasificar los aspectos extraídos del dominio.

+ Reunir una muestra representativa de aplicaciones en el dominio.

+ Analizar cada aplicación en la muestra y definir clases de análisis.

+ Desarrollar un modelo de los requerimientos para las clases.

- Definir el dominio de la función.

- Definir el dominio de la estructura.

#257

** La ingeniería del dominio incluye tres actividades especiales…

+ Análisis.

+ Construcción.

+ Diseminación.

- Contemplación.

- Destrucción.

- Inseminación.

- Capacitación.

#260

** Binder sugiere varios aspectos clave que constituyen la base del diseño para la reutilización…

+ Datos estándar.

+ Protocolos de interfaz estándar.

+ Plantillas del programa.

- Adaptabilidad.

- Portabilidad.

- Protocolos de datos.

- Capacidad de memoria.

#259

** El sistema de componentes JavaBeans incluye un conjunto de herramientas llamado KDB que permite que los desarrolladores…

+ Analicen la forma en la que funcionan los Beans existentes.

+ Personalicen su comportamiento y apariencia.

+ Establezcan mecanismos para la coordinación y comunicación.

+ Desarrollen Beans especiales para el uso en una aplicación específica.

+ Prueben y evalúen el comportamiento Bean.

- Analizar el IDE para desarrollar el Bean.

- Verificar la compatibilidad del Bean.

#266

** En su libro sobre el diseño de la interfaz, Theo Mandel acuñó tres reglas doradas…

+ Dejar el control al usuario.

+ Reducir la carga de memoria del usuario.

+ Hacer que la interfaz sea consistente.

- Dejar el control a los desarrolladores

- Usar memoria caché.

- Realizar múltiples interfaces gráficas.

- Finalizar los controles.

# Yeny Laquita Mamani 2011-119053

# Paginas 267-278

# Pág. 267

** Dejar al control del usuario...

+ Definir modos de interacción de manera que no se obligue al usuario a realizar acciones innecesarias o no deseadas.

+ Dar una interacción flexible.

+ Permitir que la interacción del usuario sea interrumpible y también reversible.

+ Facilitar la interacción a medida que aumenta la habilidad y permitir que aquélla se personalice.

+ Ocultar los tecnicismos internos al usuario ocasional.

+ Diseñar la interacción directa con objetos que aparezcan en la pantalla.

- Dar una interacción inflexible.

# Pág. 267

** Reducir las necesidades del usuario...

+ La demanda de memoria de corto plazo.

+ Hacer que lo preestablecido sea significativo.

+ Definir atajos que sean intuitivos.

+ La distribución visual de la interfaz debe basarse en una metáfora del mundo real.

+ Revelar información de manera progresiva.

- Definir atajos que no sean intuitivos.

- La distribución visual de la interfaz debe basarse en el criterio.

- No Revelar información de manera progresiva.

# Pág. 267

** Es el principio de diseño para la interfaz...

+ Permitir que el usuario coloque la tarea en curso en un contexto significativo.

+ Mantener la consistencia en toda la familia de aplicaciones.

+ Mantener modelos interactivos anteriores han creado expectativas en el usuario.

- No permitir que el usuario coloque la tarea en curso en un contexto significativo.

- No mantener la consistencia en toda la familia de aplicaciones.

- NO mantener modelos interactivos anteriores han creado expectativas en el usuario.

- Nunca dar la razón al usuario.

# Pág. 271 -272

** El proceso de diseño de la interfaz de usuario consta de actividades estructurales...

+ Análisis.

+ Modelado de la interfaz.

+ Diseño de la interfaz.

+ Construcción.

+ Validación.

- Diseño del caso de uso.

- Interpretación.

- Consistencia.

# Pág. 272-273

** La información puede proceder de diversas fuentes...

+ Entrevistas.

+ Información de ventas.

+ Información de mercadotecnia.

+ Información de apoyo.

- Información de construcción.

- Información del diseño.

- Información de casos de uso.

# Pág. 273

** Para el análisis de tarea se debe responder preguntas como...

+ ¿Qué trabajo realizará el usuario en circunstancias específicas?

+ ¿Qué tareas y subtareas se efectuarán cuando el usuario haga su trabajo?

+ ¿Qué dominio de problema específico manipulará el usuario al realizar su labor?

+ ¿Cuál es la secuencia de las tareas?

+ ¿Cuál es la jerarquía de las tareas?

- ¿Qué dominio no es importante en el problema?

- ¿Cuál es la secuencia de la jerarquía?

- ¿Cuál es jerarquía de las secuencias?

# Zuleydi Mendoza Callao

# Pág. 279-280 Etapas del diseño de la interfaz

* El diseño de la interfaz es un proceso...

- Secuencial.

+ Iterativo.

- Paralelo.

- Detallado.

- Intuitivo.

# Pág. 281 Aspectos del diseño

** Son 4 aspectos comunes del diseño...

- Leyendas de los bosquejos.

- Tiempo de respuesta del cliente.

- Manejo de información referencial.

+ Tiempo de respuesta del sistema.

+ Herramientas de ayuda para el usuario.

+ Manejo de información errónea.

+ Leyendas de los comandos.

# Pág. 282 Manejo de errores

** Todo mensaje de error o advertencia producido por un sistema interactivo debe tener las siguientes características...

+ El mensaje debe describir el problema en un lenguaje que entienda el usuario.

+ El mensaje debe dar consejos constructivos para corregir el error.

+ El mensaje debe indicar cualesquiera consecuencias negativas del error.

- No debe ser muy corto.

- Debe dar instrucciones de corrección.

+ El mensaje debe estar acompañado de una clave audible o visual.

+ El mensaje “no debe juzgar”.

# Pág. 284 Diseño de una interfaz para webapps

** Debe diseñarse una interfaz de webapp de modo que responda 3 preguntas principales del usuario final...

+ ¿Dónde estoy?

+ ¿Qué puedo hacer ahora?

+ ¿Dónde he estado, hacia dónde voy?

- ¿A dónde puedo ir?

- ¿Cuándo lo haré?

- ¿Cómo lo haré?

- ¿Para qué lo haré?

# Pág. 285-286 Principios y lineamientos del diseño de la interfaz

** Son algunos principios generales de diseño...

+ Previsión.

+ Comunicación.

+ Consistencia.

+ Autonomía controlada.

+ Eficiencia.

+ Flexibilidad.

+ Centrarse.

# Pág. 289-290 Flujo de trabajos para el diseño de la interfaz de webapp

** Son alguna de las tareas que representan un flujo de trabajo rudimentario para diseñar una interfaz para webapp...

+ Revisar la información contenida en el modelo de requerimientos y refinarla según se requiera.

+ Desarrollar un esquema aproximado de la distribución de la interfaz para la webapp.

+ Mapear los objetivos del usuario en acciones específicas de la interfaz.

+ Definir un conjunto de tareas de usuario asociadas con cada acción.

+ Elaborar un guion de las imágenes en la pantalla para cada acción de la interfaz.

+ Refinar la distribución de la interfaz y los guiones con

entradas del diseño de la estética.

+ Identificar los objetos de la interfaz de usuario requeridos para implementar la interfaz.

#Dante Huillca Duran 2011-119059

#Pág. 291 evaluación de diseño

** Pertenecen al ciclo de evaluación de diseño de la interfaz...

+ Diseño preliminar

+ Construcción del prototipo numero 1

+ Evaluación del usuario

+ Estudio de la interfaz

+ Modificaciones de diseño

+ Construcción del prototipo numero n

- construcción del prototipo numero 2

#Pág. 291 Criterios de evaluación de interfaz

** Criterios de evaluación durante la revisión de la interfaz...

+ Cantidad de aprendizaje requerido por los usuarios del sistema

+ Tiempo de interacción de la eficiencia general del sistema

+ La Carga de memoria para los usuarios del sistema

+ Complejidad de la interfaz

+ Grado de aceptación por parte del usuario

+ Longitud y Complejidad del modelo de requerimientos

+ El número de acciones, tareas y estados del sistema

#Pág. 296 patrones de diseño

** Características de un patrón de diseño eficaz

+ Resuelve un problema

+ Es un concepto probado

+ La solución no es obvia

+ Describe una relación

+ Tiene un componente humano significativo

- La solución es obvia

- Es un concepto no probado

#Pág. 297 Clases de patrones

** Son clases de patrones...

+ Generativos

+ Arquitectónicos

+ Patrones de datos

+ Componentes

+ Patrones de diseño

+ Patrones de webapp

+ Creacionales

#Pág. 299 Estructuras

** Diferencias entre los patrones de diseño y las estructuras

+ Los patrones de diseño son más abstractos que las estructuras

+ Los patrones de diseño son elementos arquitectónicos más pequeños que las estructuras

+ Los patrones de diseño están menos especializados que las estructuras

- Los patrones de diseño son elementos arquitectónicos más grandes que las estructuras

- Los patrones de diseño están más especializados que las estructuras

- Los patrones de diseño son menos abstractos que las estructuras

+ Una estructura normal contiene varios patrones de diseño, lo contrario sucede con los patrones.

#Pág. 300 descripción de un patrón

** Información que contiene el formato de diseño del patrón

+ Nombre del patrón

+ Problema

+ Motivación

+ Contexto

+ Solución

+ Objetivo

+ Implementación

#JESUS MANUEL QQUEHUE CUCHILLO

#303-314

#página 303: Diseño basado en Patrones

** Shalloway y Trott sugieren el siguiente enfoque, que permite que un diseñador

piense en los siguientes patrones...

+ Asegurarse de entender el panorama: el contexto en el que se encuentra el software

que se va a elaborar. El modelo de requerimientos debe transmitir esa comprensión.

+ Estudiar el panorama, identificar los patrones presentes en ese nivel de abstracción.

+ Comenzar el diseño con patrones del “panorama” que establezcan un contexto o esqueleto

para el trabajo de diseño adicional.

+ “Trabajar dentro del contexto” Shalloway en busca de patrones en niveles más bajos de

abstracción que contribuyan a la solución del diseño.

+ Repetir los pasos 1 a 4 hasta que el diseño esté completo.

+ Mejorar el diseño, adaptando cada patrón a las especificidades del software que se trata

de elaborar.

- Una vez terminado todos los pasos anteriores se empieza a reconfigurar el software.

#página 303-304: Tareas de Diseño

* ¿Cuántas tareas de diseño se necesitan para tener éxito y sea óptimo?

+ 8

- 4

- 6

- 6

- 5

- 9

- 12

#página 305: Construcción de una tabla para organizar el patrón

** Una tabla organizadora de patrones puede implementarse con la columna organizada por...

+ Datos/contenido.

+ Arquitectura.

+ Nivel de componentes.

+ Aspecto de la Interfaz del Usuario.

- Nombre

- Dirección

- Teléfono

#página 306: Patrones Arquitectónicos

** Los patrones Arquitectónicos para el software definen ciertos numeros de dominios, ¿cuántos y cuáles son?

+ son 4

- son 3

+ Control de Acceso.

+ Concurrencia.

+ Distribución.

+ Persistencia.

- Concurrencia

#página 308: Patrones de Diseño en el nivel de Componentes

* Los patrones de diseño en el nivel de componentes brindan...

+ Soluciones comprobadas que se abocan a uno o más subproblemas extraídos del modelo de requerimientos.

- Soluciones no comprobadas que se abocan a uno o más subproblemas extraídos del modelo de requerimientos.

- Interfaces acabadas y muy atractivas.

- Ayuda a los demás niveles.

- Mantenimiento al Hardware.

- Interfaces incompletas y poco atractivas.

- Independencia en los niveles.

#página 310: Patrones de Diseño de la Interfaz de Usuario

** Los patrones de webapps se clasifican con el empleo de los siguientes niveles de atención en el diseño...

+ Patrones de arquitectura de la información.

+ Patrones de navegación.

+ Patrones de interacción.

+ Patrones de presentación.

+ Patrones funcionales.

- Patrones de Interfaz.

- Patrones no funcionales.

#Carlos Cesar Zelada Melchor

#Página 319 Webapps

** ¿Cuáles son los principales atributos de las Webapps?

+ Usabilidad

+ Funcionalidad

+ Confiabilidad

+ Eficiencia

+ Facilidad para recibir mantenimiento

- Libre

- Creativo

#Página 320

* Según Jean Kaiser: "Que algo pueda hacerse,...

+ no significa que deba hacerse"

- no significa que pueda hacerse"

- no significa que tenga que hacerse"

- significa que deba hacerse"

- significa que pueda hacerse"

- significa que tenga que hacerse"

- significa que es necesario hacerse"

#Página 320

** ¿Cuáles son las metas del diseño de una Webapp?

+ Simplicidad

+ Consistencia

+ Identidad

+ Robustez

+ Navegabilidad

+ Atractivo visual

+ Compatibilidad

#Página 321

* Según Curt Cloninger: "Si un sitio es perfectamente utilizable, pero carece de un estilo elegante y apropiado, ...

+ Fracasará

- Mejorará

- Crecerá

- Continuará

- Perdurará

- Se eliminará

- Podrá ser optimizada

#Página 322

** ¿Cuál de los siguientes diseños pertenece a la pirámide de diseño de las Webapps?

+ Diseño de la interfaz

+ Diseño estético

+ Diseño del contenido

+ Diseño de la navegación

+ Diseño de la arquitectura

+ Diseño de los componentes

- Diseño de la programación

#Página 323

* "Descubrimos que las personas evalúan rápidamente un sitio tan sólo por su diseño...

+ Visual"

- Estructurado"

- Ordenado"

- Estético"

- De colores"

- De funciones"

- De los componentes"

# Kevin Mike Herrera Vega

#Pág. 334-354

#Pág 334 Calidad de una webapp

** Son características para un buen diseño de una webapp…

+ Sencillez

+ Consistencia

+ Identidad

+ Robustez

+ Navegabilidad

+ Atractivo visual

- Complejidad de uso

#Pág. 339 ¿Qué es calidad?

** David Garvin, de Harvard Bussiness School, sugiere que la calidad es un concepto complejo de múltiples facetas, que se describe en 5 puntos diferentes de vista…

+ Punto de vista trascendental

+ Punto de vista del usuario

+ Punto de vista del fabricante

+ Punto de vista del producto

+ Punto de vista basado en el valor

- Punto de vista del docente

- Punto de vista del mercado

#Pág. 341 Dimensiones de la calidad de Garvin

** Son dimensiones de calidad propuestas por David Garvin…

+ Calidad del desempeño

+ Calidad de las características

+ Confiabilidad y Conformidad

+ Durabilidad

+ Servicio

+ Estética

+ Percepción

#Pág. 342 Factores de la calidad de McCall

** La clasificación de los factores que afectan la calidad del Software propuesta por McCall, Richards y Walters, se centran en 3 aspectos importantes del producto de software…

+ Sus características operativas

+ Su capacidad de ser modificado

+ Su adaptabilidad a nuevos ambientes

- Su costo en el mercado

- Su costo de operación

- Su tiempo de ejecución

- Sus niveles de seguridad

#Pág. 343 Factores de la calidad ISO 9126

** El estándar ISO 9126 se desarrolló con el fin de identificar atributos claves del software. Este estándar identifica 6 atributos clave de calidad…

+ Funcionalidad

+ Confiabilidad

+ Usabilidad

+ Eficiencia

+ Facilidad de recibir mantenimiento

+ Portabilidad

- Costo

#Pág. 340 Calidad de Software

* Calidad es un concepto complejo de definir, desarrolladores de software experimentados concuerdan en que la calidad del software se puede definir como…

+ Proceso eficaz de software que se aplica de manera que crea un producto útil que proporciona valor medible a quienes lo producen y a quienes lo utilizan.

- Proceso que produce software a menor costo

- Proceso que no malgasta tiempo

- Proceso procura que el producto final se libre de fallas

- Proceso no eficaz de desarrollo

- Proceso que no se fija en buenas practicas, solo en tiempo

- Proceso que nunca podrá definirse

# Perfecto Henrry Cachicatari Mamani 2012-36148

# Págs. 555-566

#Pág. 555 el espectro administrativo.

** La administración efectiva de un proyecto de software se enfoca en las cuatro P…

+ Personal.

+ Producto.

+ Proceso.

+ Proyecto.

- Producción

- Perspectiva

- Prospecto

#Pág. 557 El Personal, los participantes

** El proceso de software (y todo proyecto de software) está poblado de participantes, quienes pueden organizarse en alguna de las siguientes áreas…

+ Gerentes ejecutivos, quienes definen los temas empresariales que con frecuencia tienen una influencia significativa sobre el proyecto.

+ Gerentes de proyecto (técnicos), quienes deben planificar, motivar, organizar y controlar a los profesionales que hacen el trabajo de software.

+ Profesionales que aportan las habilidades técnicas que se necesitan para someter a ingeniería un producto o aplicación.

+ Clientes que especifican los requerimientos para el software que se va a fabricar, así como otros participantes que tienen un interés periférico en el resultado.

- Líder, quien dirige no dirige a los participantes del proyecto

+ Usuarios finales, quienes interactúan con el software una

vez que se libera para su uso productivo.

- Personal, quien atiende a los participantes del proyecto para que se sientan cómodos y desarrollen con éxito

#Pág. 558 Los lideres

** Las características que definen a un gerente de proyecto eficaz enfatizan cuatro rasgos clave…

+ Resolución de problemas.

+ Identidad administrativa.

+ Logro.

+ Influencia y construcción del equipo.

- Motivación

- Organización

- Ideas o innovación

#Pág. 558 El equipo de software

** Mantei [Man81] describe los factores de proyecto que deben considerarse cuando se planee la estructura de los equipos de ingeniería de software…

+ Dificultad del problema que se va a resolver.

+ “Tamaño” del programa resultante en líneas de código o puntos de función.

+ Tiempo que el equipo permanecerá unido (vida del equipo).

+ Grado en el que puede dividirse en módulos el problema.

+ Calidad y confiabilidad requeridas por el sistema que se va a construir.

+ Rigidez de la fecha de entrega.

+ Grado de sociabilidad (comunicación) requerido para el proyecto.

#Pág. 562 El producto, ámbito del software

** La primera actividad en la administración del proyecto de software es determinar el ámbito del software, que se define al responder las siguientes preguntas…

+ ¿Cómo encaja en un sistema, producto o contexto empresarial más grande el software que se va a construir y qué restricciones se imponen como resultado del contexto?

+ ¿Qué objetos de datos visibles para el cliente se producen como salida del software?

+ ¿Qué objetos de datos se requieren como entrada?

+ ¿Qué función realiza el software para transformar los datos de entrada en salida?

+ ¿Existe alguna característica de desempeño especial que deba abordarse?

- ¿Qué función realiza el software para el cliente?

- ¿Qué función cumple el cliente en la etapa de la programación?

#Pág. 565 El proceso, descomposición del proyecto

** Un proyecto simple y relativamente pequeño puede requerir las siguientes tareas para la actividad de comunicación…

+ Desarrollar lista de clarificación de conflictos.

+ Reunirse con los participantes para abordar la clarificación de conflictos.

+ Desarrollar en conjunto un enunciado del ámbito.

+ Revisar el enunciado del ámbito con todos los interesados.

+ Modificar el enunciado del ámbito según se requiera.

- Modificar el enunciado del ámbito según se requiera

- Revisar el conjunto de enunciados con los interesados

#Edward Axel Cruz Catacora

#567-578

#Pág. 567 El principio W5HH

** En el principio W5HH, ¿Cuáles son las preguntas que conducen a una definición de las características clave del proyecto?

+ ¿Por qué (Why) se desarrollará el sistema?

+ ¿Qué (what) se hará?

+ ¿Cuándo (when) se hará?

- ¿Quién (who) es el cliente?

+ ¿Dónde (where) se ubicarán en la organización?

+ ¿Cómo (how) se hará el trabajo, técnica y organizativamente?

+ ¿Cuánto (how much) se necesita de cada recurso?

#Pág. 572 MÉTRICAS EN LOS DOMINIOS DE PROCESO Y PROYECTO

** Las métricas de proyecto permiten al gerente de un proyecto de software...

+ Valorar el estado de un proyecto en marcha

+ Rastrear riesgos potenciales

+ Descubrir áreas problema antes de que se vuelvan “críticas”

+ Ajustar el flujo de trabajo o las tareas

+ Evaluar la habilidad del equipo del proyecto

- Controlar la cantidad de los productos operativos del software.

- Ampliar la visión del proyecto

#Pág. 572 Las métricas del proceso y la mejora del proceso de software

** La complejidad del producto puede tener un impacto sustancial sobre...

+ La calidad del equipo

- La calidad del producto

+ El desempeño del equipo

- El precio del producto

- Los clientes

- La documentación

- Los pagos

#Pág. 572 Las métricas del proceso y la mejora del proceso de software

* La eficacia de un proceso de software sólo puede medirse de manera...

- Directa

- Sustancial

- Superficial

- Perspectiva

- General

- Global

- Local

+ Indirecta

#Pág. 574 Métricas de proyecto

* La primera aplicación de las métricas de proyecto sobre la

mayoría de los proyectos de software ocurre durante...

+ La estimación

- La recopilación de requerimientos

- El desarrollo

- El análisis

- El diseño

- La programación

- Las pruebas

#Pág. 577 Métricas orientadas a función

* Usan una medida de la funcionalidad entregada por la aplicación como un valor de normalización, este concepto pertenece a ...

- Reconciliación de métricas LOC y PF

- Métricas orientadas a tamaño

- Medidas directas del proceso de software

- Métricas de proceso

- Métricas orientadas al desarrollo

- Métricas de normalización

+ Métricas orientadas a función

#ALONSO GODINEZ 2012-36156

#579 Métricas orientadas a objetos

** ¿Cuáles son las métricas orientadas a objetos?

+ Número de guiones de escenario.

+ Número de clases clave.

+ Número de clases de apoyo.

+ Número promedio de clases de apoyo.

+ Número de subsistemas.

- Número de punteros.

- Número de listas enlazadas.

#580 Métricas orientadas a caso de uso

** ¿Cuáles son las métricas orientadas a casos de uso?

+ Número de casos de uso.

+ Número de casos de prueba.

+ Esfuerzo.

+ Tamaño de aplicación.

- Lenguaje de programación.

- SGBD.

- Metodología de desarrollo.

#580 Métricas de proyecto webapp

** ¿Cuáles son las métricas de un proyecto webapp?

+ Número de páginas web estáticas.

+ Número de páginas web dinámicas.

+ Número de vínculos de página interno.

+ Número de objetos de contenido dinámico.

+ Número de objetos de contenido estático.

+ Número de funciones ejecutables.

+ Número objetos de datos persistentes.

#582 Métricas para calidad de software

** ¿Cuáles son las métricas de calidad?

+ Exactitud.

+ Mantenibilidad.

+ Integridad.

+ Usabilidad.

- Líneas de código.

- Metodología de desarrollo.

- Número de desarrolladores.

#584 Métricas para calidad de software

* ¿Por qué es importante medir el proceso de ingeniería de software?

+ Porque si no se mide, no hay forma real de saber si se está mejorando.

- Porque si no se mide, demora más.

- No hay forma de medir el proceso de software.

- Porque es necesario para la documentación.

- Porque sirve para definir el costo.

- Porque sirve para definir el tiempo.

- Porque sirve para definir los requerimientos.

#586 Integración de métricas dentro del proceso de software

* ¿Qué es una línea de referencia de métrica?

+ Es un conjunto de datos recopilados a partir de proyectos de software

- Es una línea de código comentada

- Es una suposición

- Es un estándar de calidad de software

- Es una metodología de software

- Es un patrón de diseño

- Es un diagrama complejo de requerimientos

#Gladys Huanacune Chambilla 2012-36157

#Pág. 593 Estimación para proyectos de software

** Antes de que un proyecto pueda comenzar, el equipo de software debe...

+ Estimar el trabajo que se va a realizar

- Ver los contratiempos

+ Estimar los recursos que serán requeridos

+ Estimar el tiempo que transcurrirá de principio a fin

- Estimar los estados de ánimo de los integrantes

- Estimar los beneficios para la empresa

- Delegar funciones

#Pág.594 Observaciones acerca de las estimaciones

** Las siguientes observaciones tienen efectos sobre las estimaciones para el proyecto de software

+ Complejidad del proyecto

+ El tamaño del proyecto

- El número de usuarios del sistema

+ El grado de incertidumbre

+ Disponibilidad de información histórica

- La planificación del proyecto

- La calendarización para el desarrollo

#Pág. 596 - 598 Recursos para el desarrollo de software

** Las tres principales categorías de recursos para el desarrollo de software son...

+ Recursos humanos

- Recursos monetarios

+ Recursos de software reutilizables

- Recursos de hardware

+ Recursos Ambientales

- Recursos de planificación de tareas

- Recursos para la impresión digital

#Pág. 598 Estimación de proyectos de software

* La estimación de...

- Costo del software nunca será una ciencia exacta

- Costo y refuerzo del software nunca será una ciencia exacta

- Costo y esfuerzo del software siempre será una ciencia exacta

+ Costo y esfuerzo del software nunca será una ciencia exacta

- Solo esfuerzo del software es una ciencia exacta

- Tiempo y costo del software nunca será una ciencia exacta

- Beneficios del software nunca será una ciencia exacta

#Pág. 600 Técnicas de descomposición

** Putnam y Myer sugieren cuatro enfoques para el problema de dimensionamiento...

+ Dimensionamiento de "lógica difusa"

+ Dimensionamiento de punto de función

- Dimensionamiento del componente circular

+ Dimensionamiento de componente estándar

+ Dimensionamiento del cambio

- Dimensionamiento del código

- Dimensionamiento del camino

#Pág. 600 - 602 Estimación basada en problema

** Con respecto a la técnica de estimación PF, se puede decir...

+ Se enfoca en cada una de las características del dominio de información

+ Sus datos se usan como variables para dimensionar cada elemento del software

+ Sus datos se usan cono métricas de referencia recopiladas de proyectos pasados

- Se enfoca solo en entradas y salidas

- Lleva a considerables niveles de detalle

- Se enfoca en la función

- Es totalmente seguro

#Angel Rodriguez Romero

#2012-36165

#Página 604 - Estimación basada en proceso

* La técnica más común para estimar un proyecto es basar...

+ La estimación sobre el proceso que se usará

- La estimación errada

- La cantidad de líneas de código

- Las horas de trabajo

- La estimación de tiempo

- La bajas de personal

- La cantidad de procedimientos

#Página 605 - Estimación con casos de uso

** Desarrollar un enfoque de estimación con casos de usos es problemático por las siguientes razones...

+ Los casos de uso se describen usando muchos formatos

+ Los casos de uso representan una visión externa del software

+ Los casos de uso no abordan la complejidad de las funciones

+ Los casos de uso pueden describir comportamiento complejo

- Los casos de uso son muy fáciles de realizar

- Los casos de uso son muy complejos de entender

- Los casos no están diseñados correctamente


* Smith argumenta que cualquier nivel de esta jerarquía estructural puede describirse mediante

+ No más de 10 casos de uso

- No más de 1 caso de uso

- No más de 5 casos de uso






* Según Smith cada caso de uso no abarca más de ..

+ 30 escenarios distintos

- 20 escenarios distintos



- 1 escenario distinto



#Página 607 - Reconciliación de estimaciones

** Las estimaciones ampliamente divergentes con frecuencia pueden tener una de dos causas...

+ El ámbito del proyecto no se entiende adecuadamente

+ El planificador lo malinterpreto

+ Los datos de productividad usados por las técnicas de estimación basadas en problema son inadecuadas

- No se entendió el propósito del proyecto

- Los datos son inadecuados

- Existe poca consistencia en la finalidad del proyecto

- Es inadecuado para un grupo de trabajo

#Página 609 - El modelo COCOMO II

** Cocomo II en realidad es una jerarquía de modelos de estimación que aborda la áreas siguientes..

+ Modelo de composición de aplicación

+ Modelo de etapa temprana de diseño

+ Modelo de etapa postarquitectónica

- Modelo de capa temprana

- Modelo de etapa prearquitectónica

- Modelo de capa escasa

- Modelo de composición de interfaz

# Página 615 Creación de un árbol de decisión

* Si el sistema se va a construir desde cero. ¿De cuánto será la posibilidad de que el trabajo sea difícil?

- 50 por ciento

- 55 por ciento

- 60 por ciento

+ 70 por ciento

- 71 por ciento

- 75 por ciento

- 80 por ciento

#Página 615 Creación de un árbol de decisión

** La organización de ingeniería de software puede...

+ Construir el sistema x desde cero

+ Reusar componentes de experiencia parcial existentes para construir el sistema

- Gestionar la disponibilidad del desarrollador.

+ Comprar un producto de software disponible y

modificarlo para satisfacer las necesidades locales.

- Estructuras los costos esperados y las probabilidades.

+ Contratar el desarrollo del software a un proveedor externo.

- Estimar el desarrollo y planificación del proyecto.

#Página 616 Outsourcing

** La decisión del Outsourcing puede ser...

+ Estratégica

- Analítica

- Secuencial

- Programable

+ Táctica

- Trabajable

- Continua

#Página 620 Calendarización del proyecto

** La calendarización adecuada requiere que...

+ Todas las tareas aparezcan en la red.

+ El esfuerzo y la calendarización se asignen de manera inteligente a cada tarea.

+ Las interdependencias entre tareas se indiquen de manera adecuada.

- Los modelos de proceso del software se refinan en función a la funcionalidad

- Mostrar un proyecto de software regular o grande.

+ Se asignen los recursos para el trabajo que se va a realizar

+ Se proporcionen hitos cercanamente espaciados de modo que pueda darse seguimiento al progreso.

#Página 621 Conceptos básicos

** Aunque existen muchas razones por las que el software se entrega tardíamente, la mayoría pueden rastrearse en una o más de las siguientes causas fundamentales...

+ Una fecha límite irreal establecida por alguien externo al equipo de software.

+ Requerimientos del cliente variables que no se reflejan en cambios del calendario.

+ Una honesta subestimación de la cantidad de esfuerzo y/o número de recursos que se requerirán para hacer el trabajo.

- Excesiva comunicación entre el personal del proyecto.

+ Falta de comunicación entre el personal del proyecto.

+ Riesgos predecibles y/o impredecibles que no se consideraron cuando comenzó el proyecto.

+ Dificultades humanas que no podían prever por anticipado.

#Página 622 Conceptos básicos

** ¿Qué recomiendan los autores frente a las presiones del mercado externo, las cuales dictan la fecha en el que el producto debe liberarse?

+ Realizar una estimación detallada, usando datos históricos de proyectos anteriores.

+ Con el modelo de proceso incremental, desarrollar una estrategia de ingeniería de software que entregue funcionalidad crucial hacia la fecha límite impuesta.

- Marchar a la oficina del cliente y demandar que se cambie la fecha de entrega.

+ Reunirse con el cliente y explicar por qué la fecha límite es irreal.

- No presentar una estimación sólida con base en buenos datos históricos.

+ Ofrecer la estrategia de desarrollo incremental como una alternativa.

- Faltar por parte de la administración del proyecto para reconocer que el proyecto tiene retrasos y falta acciones para corregir errores.

#Pág. 627 Conjunto de tareas

** Los proyectos de desarrollo de concepto se abordan al aplicar las siguientes acciones...

+ El ámbito del concepto

+ La planificación preliminar del concepto

+ La valoración del riesgo tecnológico

+ La prueba del concepto

+ La implementación del concepto

+ La reacción del cliente

- La verificación del proyecto

#Pág.627 Refinamiento de acciones de ingeniería de software

** Es cierto sobre el refinamiento de acciones de ingeniería del software

+ Debe refinarse para crear un calendario de proyecto detallado.

+ Comienza tomando cada acción

+ Se descompone cada acción en un conjunto de tareas

+ El refinamiento de las tareas puede lograrse con un formato de bosquejo.

- Se usa un bosquejo orientado a objetos

- Debe refinarse para crear un cronograma.

+ Comienza con el ámbito del concepto

#Pág. 629 Calendarización

** El seguimiento puede lograrse en varias formas diferentes

+ Realizar reuniones periódicas del estado del proyecto.

+ Evaluar los resultados de todas las revisiones realizadas.

+ Determinar si los hitos se lograron en la fecha provista.

+ Comparar la fecha de inicio real con la fecha de inicio planeada.

+ Reunirse informalmente con los profesionales

+ Usar análisis de valor ganado

- Control de las tareas programadas.

#Pág.632 Calendarización

* Son hitos técnicos del diseño orientado a objetos completo...

+ Definición y revisión del conjunto de subsistemas.

+ Asignación de clases a subsistemas y su revisión.

+ Establecimiento y revisión de la asignación de tareas.

+ Identificación de responsabilidades y colaboraciones.

+ Diseño y revisión de atributos y operaciones.

+ Creación y revisión del modelo de comunicación.

- Revisión de todas las clases

#Pág. 633 Calendarización para proyectos webapp

** Los incrementos para el componente del proyecto basado en web...

+ Información básica de compañía y producto.

+ Información detallada de producto y descargas.

+ Citas de producto y procesamiento de pedidos de producto.

+ Plantilla espacial y diseño de sistemas de seguridad.

+ Servicios de información y solicitud de monitoreo.

+ Control en línea del equipo de monitoreo.

+ Acceso a información de cuenta.

#Pág. 636 Valor ganado

** Para determinar el valor ganado se realizan los siguientes pasos...

+ Determinar el costo presupuestado del trabajo calendarizado.

+ Determinar el presupuesto al concluir.

+ Calcular el costo presupuestado del trabajo realizado.

- Hallar el índice de rendimiento.

- Calcular la variación del calendario.

- Calcular el indicio de la eficiencia del proyecto.

- Hallar el porcentaje calendarizado.

#Luis Miguel Castillo Mamani

#Pág. 641 - Estrategia reactivas de riesgo frente a estrategias proactivas de riesgo.

* ¿Cuál es la frase que citó Tom Gilb?

+ Si no atacas de manera activa los riesgos, ellos te atacarán de manera activa.

- El hardware se hizo para patearse.

- El software libre es una filosofía de vida.

- El riesgo se preocupa por los acontecimientos futuros.

- Ayer y hoy están más allá de la preocupación activa.

- Al que madruga dios lo ayuda.

- Ojo por ojo, diente por diente.

#Pág. 641 - Riesgos de Software.

** ¿Cuáles son las dos características del riesgo de software?

+ Incertidumbre.

+ Riesgo.

- Grandeza.

- Efectividad

- Pereza.

- Perseverancia.

- Codicia.


** ¿Cuáles son los 5 problemas que identifican los riesgos técnicos?

+ Diseño.

+ Implementación.

+ Interfaz.

+ Verificación.

+ Mantenimiento.

- Avaricia.

- Retroalimentación.


** Los candidatos para los cinco principales riesgos empresariales son...

+ Construir un producto o sistema excelente que realmente no se requiere.

+ Construir un producto que ya no encaje en la estrategia empresarial global de la compañía.

+ Construir un producto que el equipo de ventas no sabe cómo vender.

+ Perder el apoyo de los administradores debido a un cambio en el enfoque o en el personal.

+ Perder apoyo presupuestal o de personal.

- Que los programadores mueran en un accidente.

- Que un corte de luz borre todo el avance.


* ¿Cuál es la frase que citó Tom DeMarco y Tim Lister?

+ Los proyectos sin riesgos reales son perdedores. Casi siempre están desprovistos de beneficios; es por esto por lo que no se hicieron años atrás.

- Camarón que se duerme se lo lleva la corriente.

- La laptop se hizo para que el empresario trabaje hasta en vacaciones.

- Mirar la pantalla de tu computadora jamás te dejará ciego.

- La tecnología es el reflejo del fanatismo del hombre por sobrevivir.

- Hoy en día por suerte, la sociedad tiene una percepción esquizofrénica de la ciencia-tecnología.

- Cada experiencia de la vida es tapada por una cosa de la tecnología.

#Pág. 643 - Identificación de riesgo

** ¿Cuáles son algunas de subcategorías genéricas respecto a la identificación de riesgos?

+ Tamaño del producto.

+ Impacto empresarial.

+ Características de los participantes.

+ Definición del proceso.

+ Entorno de desarrollo.

+ Tecnología para construir.

+ Tamaño y experiencia personal.

#4 Arquitectura de Procesos MoProSoft

** Formar parte de la Arquitectura de Procesos MoProSoft...

+ Alta dirección: Gestión de negocios

- Alta dirección: Gestión de ventas

+ Gerencia: Gestión de procesos, gestión de proyectos y gestión e recursos

- Gerencia: Gestión de procesos

+ Operación: Admin. de proyectos específicos, Desarrollo y mantenimiento de software.

- Operación: Admin. de proyectos y mantenimiento de software.

- Alta dirección: Gestión de Marketing

#5 Procesos MoProSoft

** Son procesos MoProSoft

+ Dirección

- Secretaría

+ Coordinación instrumentación

- Desarrollo Urbano

+ Ejecución

- Devolución

- Asesoría

#7 Método de Evaluación

** El propósito del método de evaluación de Procesos EvalProSoft es otorgar a la organización...

+ Un nivel de capacidad de procesos implantados en la organización

- Un nivel de cantidad de procesos implantados en la organización

+ Un nivel de madurez de capacidades

- Un nivel de capacidad de proyectos implantados en la organización

- Un nivel de inmadurez de capacidades

- Un nivel de madurez de cantidades

- Un nivel de capacidad de procesos

#8 Niveles de capacidad

* Es el orden de los niveles de capacidad por proceso

- Incompleto, realizado, predecible, optimizado.

- Incompleto, realizado, gestionado,

- Establecido, predecible, optimizado.

+ Incompleto, realizado, gestionado, establecido, predecible, optimizado.

- Optimizado, Predecible, Incompleto, realizado, gestionado, establecido.

- Optimizado, Predecible, Incompleto.

- Realizado, gestionado, establecido.

#10 Nivel de madurez

* El nivel de madurez de capacidades de una organización corresponde...

- Al mínimo nivel de capacidad alcanzado por todos los procesos evaluados

+ Al máximo nivel de capacidad alcanzado por todos los procesos evaluados

- Al mínimo nivel de capacidad alcanzado por todos los procesos pre-evaluados

- Al máximo nivel de capacidad no alcanzado por todos los procesos evaluados

- Al máximo nivel de cantidad alcanzado por todos los procesos evaluados

- Al nivel promedio de capacidad alcanzado por todos los procesos evaluados

- Al máximo nivel de capacidad alcanzado por uno de los procesos evaluados

#13 La norma mexicana

** Sobre la norma mexicana NMX-I-059

+ Norma para la Tecnología de la Información-Software-Modelo de procesos y métodos.

+ Es útil para el desarrollo y mantenimiento de software

+ Define conceptos y productos

+ Contiene Requisitos de procesos

+ Contiene Guía de implantación de procesos

+ Contiene el Método de evaluación

+ Fue publicada en el diario oficial en Agosto del 2005

# diap 16 - Gestión de negocios

* ¿Cuál es el propósito de una gestión de negocios?

+ Establecer la razón de ser de la organización.

- No establecer una organización

- Establecer los objetivos de la organización

- Establecer las condiciones de la organización

- Establecer los resultados de una organización

- Establecer los procesos de la organización

- Identificar un plan estratégico

# diap 19 - Gestión de proceso

* ¿Cuál es el propósito de una gestión de procesos?

+ Establecer los procesos de la organización.

- Establecer la razón de ser de la organización

- Agilizar un proceso

- Conseguir y dotar a la organización de los recursos humanos

- Proporcionar proveedores de bienes, servicio e infraestructura

- No existe un propósito definido

- Hacer saber el tiempo de vida de una empresa

# diap 20 - Gestión de proyectos

* ¿Cuál es el propósito de una gestión de proyectos?

+ Asegurar que los proyectos contribuyan al cumplimiento de los objetivos y estrategias de la organización.

- Establecer los procesos de la organización

- proporcionar proveedores de bienes, servicios e infraestructura

- Establecer la razón de ser de la organización

- Ganar dinero

- No tiene propósito definido

- Hacer que la empresa sea reconocida

# diap 22 - Gestión de recursos

** Son subprocesos del proceso de gestión de recursos...

+ Recursos humanos y ambiente de trabajo.

+ Bienes, servicios e infraestructura.

+ Conocimientos de la organización.

- No hay subprocesos

- Es un proceso compacto

- Desarrollo de un software

- Mantenimiento de un software

# diap 28 - Proceso de administración de proyectos específicos

** Es parte del flujo de trabajo del proceso de administración de proyectos específicos...

+ Inicio.

+ Planeación.

+ Realización.

+ Evaluación y control.

+ Cierre.

- Mantenimiento

- Soporte

# diap 30 - Proceso de desarrollo y mantenimiento de software

** Es parte del flujo de trabajo del proceso de desarrollo y mantenimiento de software...

+ Ciclos de desarrollo.

+ Fases de un ciclo.

+ Actividades de una fase.

- Construcción

- Requerimientos

- Inicio

- Análisis

#MOPROSOFT

#30 - Proceso de Desarrollo y Mantenimiento de Software

** Flujos de trabajo en el desarrollo de Software

+ Ciclos de Desarrollo.

+ Fases de un Ciclo.

+ Actividades de una Fase.

- Realimentación.

- Método ágil.

- Requerimientos.

- Testeo.

#31 - ciclos de Desarrollo

** Mencionar los elementos del ciclo de Desarrollo

+ Necesidades cliente.

+ Fases del Primer Ciclo.

+ Fases del siguiente ciclo.

+ Nuevas necesidades.

- Desarrollador.

- Cliente.

- Metodologia ágil.

#32 - Fases de un ciclo

** Mencionar las fases de un ciclo.

+ Inicio.

+ Requerimientos.

+ Análisis y Diseño.

+ Construcción.

+ Integración.

+ Pruebas.

+ Cierre.

#33 - Actividades de una Fase

** Elementos de una Actividad de Fase

+ Producción

+ Corrección.

+ Verificación.

+ Validación.

+ Aceptación.

+ Registro de Mediciones.

+ Incorporación Bajo Control.

#34 - Modelo de Procesos para la Industria de Software (Moprofost)

** Elementos de Patrón de procesos.

+ Definición General de Proceso.

+ Prácticas.

+ Guías de Ajuste.

- Libro de Diseño.

- Inicio.

- Metodología.

- Evento.

#35 - Definición general de proceso.

** Estructura del patrón de Procesos.

+ Proceso.

+ Categoría.

+ Propósito.

+ Descripción.

+ Objetivos.

+ Indicadores.

+ Metas Cuantitativas.

#47 CMM

** Usos más comunes del modelo.

+ Autoevaluación de capacidad de procesos de software.

+ Evaluación de capacidad de procesos de software.

- Desarrollo de nuevas tecnologías.

- Corrección de errores de hardware.

- Corrección de errores de código.

- Establecer mejoras de procesos de codificación.

- Selección de hardware para proyectos.

#48 Organizaciones de software maduras e inmaduras

** Las organizaciones inmaduras generalmente...

+ Improvisan procesos durante un proyecto.

+ Son reactivas, resolviendo crisis inmediatas.

+ Exceden presupuestos.

+ Exceden calendarios.

+ No cuentan con bases objetivas.

+ Comprometen calidad y funcionalidad.

+ No saben evaluar la calidad del producto generado.

#49 Organizaciones de software maduras e inmaduras

** Las organizaciones maduras generalmente...

+ Poseen habilidad organizacional.

+ Trabajan con base en un plan.

+ Monitorean la calidad de los productos.

+ Basan su calendario y presupuesto en datos históricos y realistas.

+ Administran procesos de desarrollo y mantenimiento de sistemas.

+ Analizan los posibles problemas de productos y procesos.

+ Se comunican de forma constante con el personal existente.

#50 Niveles de CMM

** Los 5 niveles de CMM(SEI, CMU) son ...

+ Inicial

+ Repetible

+ Definido

+ Administrado

+ Optimizado

- Planeado

- Dominado

#52 Procesos clave por nivel de madurez

** Mencione los procesos clave del nivel 3 de CMM

+ Revisiones internas.

+ Coordinación intergrupal.

+ Ingeniería de productos de sistemas.

+ Administración integrada de sistemas.

+ Programa integral de desarrollo profesional.

+ Definición de procesos de la organización.

+ Enfoques a procesos de la organización.

#53 Características de procesos por nivel

** ¿Cuáles son las relaciones correctas entre el nivel de CMM y su característica principal?

+ 1 inicial (Los procesos son informales y AD-HOC).

+ 2 repetible (Las prácticas administrativas de proyectos se institucionalizan).

+ 3 definido (Las prácticas técnicas se integran con las prácticas administrativas).

+ 4 administrado (Los procesos y productos se controlan cuantitativamente).

+ 5 optimizado (Se institucionaliza la mejora de procesos).

- 1 inicial (Se ve el alcance de posibilidades).

- 3 definido (Se revisan las prácticas para evitar errores).

Preguntas

Documents

Transcript of Preguntas