Preguntas

# Pg.
39 El modelo espiral
* El modelo espiral fue
propuesto por
presente definicin pertenece

a
+ Planeacin
+ Barry Boehm
- Diseo de alto nivel
- Boehm Larry
- Desarrollo
- RiChard Matthew
Stallman
- Bill Gates
- Dennis Ritchie
- Linus Torvalds
- Post mrtem
- Equipo de desarrollo
- Modelado de sistema
- Levantamiento de
requerimientos
- James Gosling
# Pg. 49
# Pg. 39
** Cules son las
trayectorias del modelo espiral?
+ Planeacin
+ Modelado
+ Construccin
+ Despliegue
+ Comunicacin
- Implementacin
- Desarrollo
# Pg. 47
** Cules son las fases del
proceso unificado?
+ Elaboracin
+ Construccin
+ Transicin
+ Produccin
+ Concepcin
- Modelamiento
- Etapa de requerimientos
* Se determina la eficacia
del proceso por medio de
medidas y mediciones obtenidas
(esta es una cantidad sustancial
de datos que deben analizarse
con mtodos estadsticos). La
presente definicin pertenece
a
- Desarrollo
+ Post Mrtem
- Planeacin
- Requerimientos
- Modelo de desarrollo
- Estrategias de
implementacin
- Diseo del sistema
# Pg. 49
* Se desarrollan las
especificaciones externas para
cada componente que se va
construir y se crea el diseo de
componentes. Esta definicin
pertenece a
+ Diseo de alto nivel
- Planificacin
- Desarrollo
# Pg. 49
* Es la actividad aislada de
requerimientos y desarrolla las
estimaciones tanto del tamao
como de los recursos. La
- Post Mortem
- Plan de diseo de
ejecucin
- Modo de objetos
- Diseo de UML
# Pg. 65 - XP industrial.
** Cules son las prcticas
que incorpora IXP para
garantizar el xito de un
proyecto XP?
+ Evaluacin de la
factibilidad.
+ Comunidad del proyecto.
+ Calificacin del proyecto.
+ Administracin orientada
a pruebas.
+ Retrospectivas.
+ Aprendizaje continuo.
- retroalimentacin.
# Pg. 66 -El debate XP.

** Son aspectos que
destacan algunos crticos de la
XP...
+ Volatilidad de los
requerimientos.
+ Necesidades conflictivas
del cliente.
+ Los requerimientos se
expresan informalmente
+ Falta de un diseo formal.
- Los requerimientos se
expresan informalmente.
- Metodologas giles
- No volatilidad de los
requerimientos.
# Pg. 68 -Otros modelos

giles de proceso.
** Es el ms usado de todos
los modelos giles de proceso...
* La programacin extrema
(XP).
- Desarrollo adaptativo de
software (DAS).
- Scrum.
- Mtodo de desarrollo de
sistemas dinmicos (MDSD).
- Cristal.
- Desarrollo impulsado por
las caractersticas (DIC).
- Modelado gil(MA).
+ Estudio del negocio.

+ Iteracin del modelo
funcional.
+ Diseo e iteracin de la
construccin.
+ Implementacin.
- Estudio de mercado.
# Pg. 68 Desarrollo
adaptativo de software(DAS).
** Segn Highmith un
"ciclo de vida" del DAS
incorpora tres fases...
+ Especulacin.
- Depuracin.
#pg. 75 El proceso
unificado gil
** Cules son las
actividades que aborda cada
iteracin del PUA?
+ Colaboracin.
+ Modelado
+ Aprendizaje.
+ Implementacin
- Programacin.
+ Pruebas
- Investigacin.
+ Despliegue
- Diseo.
+ Configuracin
- Reingeniera.
# Pg. 69-70 Scrum.

** Son elementos del flujo
del proceso Scrum...
+ Retraso.
+ Sprints.
+ Reuniones Scrum.
+ Demostraciones
Preliminares.
- Jerarqua de
requerimientos
- Organizacin.
- Anlisis y Diseo.
+ Administracin del
ambiente
+ Administracin
#pg. 76 CONJUNTO DE
HERRAMIENTAS PARA EL
PROCESO GIL
** Herramientas para el
proceso gil. Cules son
herramientas de colaboracin y
comunicacin de baja
tecnologa e incorporacin?
+ Proximidad fsica
+ Pizarrones
+ Tableros
+ Tarjetas
+ Notas adheribles
# Pg. 71 Mtodo de
desarrollo de sistemas
dinmicos(MDSD).
** El ciclo de vida del
Mtodo de desarrollo de
sistemas dinmicos(MDSD)
define ciclos iterativos y
actividades que son...
+ Estudio de factibilidad.
- Computadoras
- Enciclopedias
#pg. 84 Principios que

guan el proceso
** Identifique los principios
fundamentales que se aplicacin
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 comunicacin y
coordinacin
+ Evaluar el riesgo
+ Administrar el cambio
#pg. 84 Principios que

guan la prctica
que guan la prctica de la Ing.
de software
+ Divide y vencers
+ Entender el uso de la
abstraccin
+ Buscar la coherencia
+ Centrarse en la
transferencia de informacin
+ Construir software que
tenga modularidad eficaz
+ Buscar patrones
+ Tener en mente que
alguien dar mantenimiento al
software
#pg. 84 Principios de
comunicacin
de comunicacin dentro de un
proyecto de software
+ Escuchar
+ Antes de comunicarse,
prepararse
+ Alguien debe facilitar la
actividad
+ Es mejor la comunicacin
cara a cara
+ Tomar notas y documentar
las decisiones
+ Perseguir la colaboracin
+ Permanecer centrado
hacer mdulos con la discusin
#pg. 83 CONOCIMIENTO
DE LA INGENIERA DE
SOFTWARE
** Muchos trabajadores del
software piensan que el
conocimiento de la IS consiste
en tecnologas especficas
Cules son?
+ Java
+ Perl
+ HTML
+ C++
+ Linux
+ Windows NT
- MYSQL
#pg 87 - Principios de
comunicacin
** Es un principio de
comunicacin...
+ Antes de comunicarse,
prepararse.
+ Alguien debe facilitar la
actividad.
+ Es mejor la comunicacin
cara a cara.
+ Tomar notas y documentar
las decisiones.
+ Perseguir la colaboracin.
+ Permanecer centrado;
hacer mdulos con la discusin.
+ Si algo no est claro,
hacer un dibujo.
#pg. 88 - Principios de
Planeacin
+ Reconocer que la
planeacin 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.
#pg. 90 - Principio de
modelado
modelado...
+ El equipo de software
tiene como objetivo
principal elaborar software,
no crear modelos.
+ Viajar ligero, no crear ms
modelos de los necesarios.
+ Tratar de producir el
modelo ms sencillo que
describa al problema o al
software.
+ Construir modelos
susceptibles al cambio.
+ Ser capaz de enunciar un
propsito explcito para cada
modelo que se cree.
+ Adaptar los modelos que
se desarrollan al sistema en
cuestin.
+ Tratar de construir
modelos tiles, pero olvidarse
de elaborar modelos perfectos.
#Pg. 94 - Principios de
construccin
** En el trabajo de
ingeniera de software moderna,
la codificacin puede ser...
planeacin...
- Demasiado sencilla
+ Entender el alcance del

proyecto.
- No es necesario codificar
+ Involucrar en la actividad
de planeacin a los participantes
del software.
- Demasiado complicada
- Solamente depende de un
lenguaje de programacin
+ La creacin directa de
lenguaje de programacin en
cdigo fuente.
+ La generacin automtica
de cdigo fuente que usa una
representacin intermedia
parecida al diseo del
componente que se va a
construir
+ La generacin automtica
de cdigo ejecutable que utiliza
un lenguaje de programacin
de cuarta generacin
# Pg. 94 - Principio de
programacin
** En los principios de
programacin, cuando se
comienza a escribir cdigo
debemos asegurarnos de...
+ Restringir sus algoritmos
por medio del uso de
programacin estructurada.
+ Tomar en consideracin el
uso de programacin por
parejas.
+ Seleccionar estructuras de
datos que satisfagan las
necesidades del diseo.
+ Entender la arquitectura
del software y crear interfaces
que son congruentes con ella.
+ Mantener la lgica
condicional tan sencilla como
sea posible.
+ Escribir cdigo que se
documente a s mismo.
+ Crear una imagen visual
que ayude a entender.
# pg. 95 - principios de
validacin
** En los principios de
validacin, una vez que se haya
terminado el primer intento de
codificacin, nos aseguramos
de:
+ Realizar el recorrido del
cdigo cuando sea apropiado.
+ Llevar a cabo pruebas

unitarias y corregir los errores
que se detecten.
+ Redisear el cdigo.
- Escribir cdigo que se
documente a s mismo.
- Crear una imagen visual
que ayude a entender.
- Restringir sus algoritmos
por medio del uso de
programacin estructurada.
- Tomar en consideracin el
uso de programacin por
parejas.
#102 Ingeniera de
requerimientos
** La Ingeniera de
requerimientos incluye las
siguientes tareas...
+ Concepcin
+ Indagacin
+ Elaboracin
+ Negociacin
+ Especificacin
+ Validacin
+ Administracin
#102 Ingeniera de
requerimientos
** La ingeniera de
requerimientos proporciona el
mecanismo apropiado para...
+ Entenderlo que desea el
cliente
+ Analizar las necesidades
+ Evaluar la factibilidad
+ Negociar una solucin
razonable
+ Especificar la solucin sin
ambigedades
+ Validar la especificacin
+ Administrar los
requerimientos
#103 Ingeniera de
requerimientos
** Christel y Kang
identificaron ciertos problemas
que se encuentran cuando ocurre
la indagacin...
- Problemas de costos
- Problemas de tiempo
- Problemas de espacio
+ Problemas de alcance
+ Problemas de
entendimiento
+ Problemas de volatilidad
- Problemas de personal
#109 Ingeniera de
requerimientos
** Cules son los
lineamientos bsicos para
conducir una reunin para
recabar los requerimientos en
forma colaborativa?
+ Tanto ingenieros de
software como otros
participantes intervienen en las
reuniones.
+ Se establecen reglas para
la preparacin y participacin.
- Se sugiere una agenda con
suficiente formalidad para
cubrir todos los puntos
importantes.
+ Proponer elementos de la
solucin
+ Negociar distintos
enfoques
+ Especificar un conjunto
preliminar de requerimientos de
la solucin
- Desarrollar listas de
restricciones.
- Eliminar las ideas
redundantes.
- Poder realizar slo una
sesin de preguntas.
#106 Comprensin de
requerimientos
** Candidatos habituales en
la identificacin de los
participantes...
+ Gerentes de operaciones
del negocio
+ Gerentes de producto
+ Personal de mercadotecnia
+ Clientes internos y
externos
+ Usuarios finales
+ Consultores
+ Ingenieros de software
+ Se sugiere una agenda con

suficiente formalidad para
cubrir todos los puntos,pero con
la suficiente informalidad para
la estimulacin de ideas.
# Pg. 111 - Comprensin

de los Requerimientos
- Se sugiere una agenda

totalmente informal para el flujo
de ideas.
** El despliegue de la
funcin de calidad identifica tres
tipos de requerimientos...
+ Un facilitador controla
la reunin.
+ Se utiliza un mecanismo
de definicin
+ Requerimientos Normales.
- Requerimientos
Informales.
- Requerimientos
Inesperados.
#109 Ingeniera de
requerimientos
+ Requerimientos
Esperados.
** La meta de la recabacin
de los requerimientos en forma
colaborativa es...
- Requerimientos
Impuntuales.
+ Identificar el problema
+ Requerimientos
Emocionantes.
- Requerimientos Intrigantes
+ Qu informacin del
sistema adquiere, produce o
cambia el actor?

** Para la mayora de
sistemas, los productos del
trabajo incluye lo siguiente...

+ Un enunciado de la
necesidad y su factibilidad.
** La mayora de
requerimientos tienen en comn
un conjunto de elementos
generales como...
+ Un enunciado acotado del

alcance del sistema o producto.
+ Elementos basados en el
escenario.
+ Una lista de clientes,

usuarios y otros participantes.
- Elementos basados en los

objetos.
+ Una descripcin del

ambiente tcnico del sistema.
+ Elementos basados en las

clases.
+ Una lista de
requerimientos y restricciones
de dominio.
+ Elementos del
comportamiento.
+ Un conjunto de escenarios
de uso.
+ Cualesquiera prototipos
desarrollados para definir
requerimientos.

** Segn Jacobson [Jac92],
Cules de las siguientes
preguntas sugiere para
responder un caso de uso?
+ Quin es el actor
principal y quin(es) el(los)
secundario(s)?
+ Cules 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?
+ Cules variaciones son
posibles en la interaccin del
actor?
+ Elementos orientados al
flujo.
- Elementos orientados a los
clientes.
- Identificar los defectos del

sistema.

** La revisin 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 caracterstica agregada que
tal vez no sea esencial para el
objetivo del sistema?
+ Cada requerimiento est
acotado y no es ambiguo?
- Elementos orientados al
anlisis.
+ Tiene atribucin cada

requerimiento? Es decir, hay
una fuente (por lo general una
individual y especfica) clara
para cada requerimiento?

+ Hay requerimientos en
conflicto con otros?
** Segn Boehm [Boe98],

en lugar de una sola actividad de
comunicacin con el cliente, se
definen las siguientes
actividades...
+ Una vez implementado

cada requerimiento, puede
someterse a prueba?
+ Identificacin de los
participantes clave del sistema o
subsistema.
+ Determinacin de las
"Condiciones para ganar" de los
participantes.
+ Negociacin 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.
#Pg. 136-Escritura de un
caso de uso formal.
* Qu identifica el
disparador (o trigger)?
+ Identifica el evento o
condicin 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
anlisis.
#Pg: 138-Diagramas de
canal (swimlane)
** Un diagrama de canal
(swimlane)
+ Representa el flujo de
acciones y decisiones.
+ Indica qu actores
efectan cada una de ellas.
- Atributos de datos.
- Objetos de datos.
** Coad y Yourdon sugieren

seis caractersticas en el modelo
de anlisis y son
+ Es un conjunto de tarjetas
ndice estndar que representan
clases.
+ Informacin retenida.
+ Las tarjetas se dividen en

tres secciones.
+ Servicios necesarios.
+ Atributos mltiples.
+ Atributos comunes.
+ Operaciones comunes.
+ Requerimientos
esenciales.
- Objeto de datos.
- Relaciones.
- No representa el flujo de
acciones y decisiones.
- No indica que actores
efectan cada una de ellas.
** Cules son las tres

clases de anlisis?
+ Propietario
+ Cmara
+ Interfaz
- Datos
- Canal
- Mensaje
- Grficos
#Pg.143-144-Identificacin
de las clases de anlisis
** Budd sugiere una
taxonoma de clases que
incluye
+ Productores (fuentes).
+ Consumidores
(sumideros) de datos.
+ Administradores de datos.
+ Vista.
+ Clases de observador.
+ Clases de auxiliares.
- Clases de datos.
#Pg.146-Definicin de las
operaciones
** Existen muchos tipos
distintos de operaciones, se
dividen en cuatro categoras
principales.
+ Operaciones que
manipulan datos en cierta
manera.
+ Operaciones que realizan
un clculo.
+ Operaciones que
preguntan sobre el estado de un
objeto
+ 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
cdigo fuente.
- NO son relevantes para los
requerimientos de un sistema o
producto.
#Pg. 149
** Pertenecen a la
taxonoma de tipos de clase
+ Clase de Entidad
+ Clase de Modelo
+ Clase de Negocio
+ Clase de Frontera
+ Operaciones que vigilan

un objeto de un evento de
control.
+ Clase de Controlador
- Operaciones que no
manipulan datos.
- Clase de Objetos
realizan un clculo.
pregunten sobre el estado de un
objeto.
#Pg. 148 Modelo CRC:
Colaboracin, Asociaciones y
Dependencias
- Clase de Sistema
#Pg. 150
** Recomendaciones para
asignar responsabilidades
(atributos y mtodos) a las
clases.
+ Distribuir la inteligencia
del sistema entre todas las
clases.
** Son afirmaciones
correctas acerca del Modelado
clase-responsabilidadcolaborador
+ Cada responsabilidad debe

enunciarse del modo ms
general posible.
+ Proporciona una manera

sencilla de identificacin y
organizacin de las clases.
+ La responsabilidad
asignada a una clase deber ser
de una tipologa de
encapsulamiento.
+ Generalizar las
caractersticas de los objetos del
sistema en una sola clase.
+ Los escenarios de casos de

uso (y dems diagramas) deben
organizarse en dos categoras.
+ Cuando sea apropiado, las

responsabilidades deben
compartirse entre clases
relacionadas.
+ Se da lectura a los casos

de uso, cuando se identifica un
objeto se entrega una ficha a la
persona propietaria de la tarjeta.
- Las clases debern

manejar distintos tipos de
informacin.
+ El poseedor de la tarjeta
deber describir las
responsabilidades y evaluar
(todos los presentes) el
cumplimiento de los
requerimientos.
- La concentracin de la
inteligencia del sistema se
revela a partir de la
concentracin de
responsabilidades.
#Pg. 151
** Afirmaciones acerca de
la responsabilidad Colaboracin
de una Clase.
+ Una clase cumple con su
responsabilidad cuando
manipula sus mtodos 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
relacin de colaboracin,
+ Tiene-conocimiento-de, es
un tipo relacin de
colaboracin.
+ Depende-de, es un tipo
relacin de colaboracin.
- Una clase cumple con su
responsabilidad cuando
instancia objetos.
#Pg. 152
** Pautas para la revisin de
un modelo CRC:
+ Los participantes de la
revisin manipularn las tarjetas
que no colaboren entre si.
+ Si no hay satisfaccin de
requerimientos, se modifican las
responsabilidades y
colaboraciones.
- Los escenarios de casos de
uso (y dems diagramas) deben
organizarse en varias categoras.
- Los requerimientos deben
ajustarse a las responsabilidades
y colaboraciones de las tarjetas.
#Pg. 153-154
** Si bien los modelos

especficos dependen en gran
medida de la naturaleza de la
webapp, hay cinco clases
principales y son...
+ Modelo de contenido
+ Modelo de interaccin
+ Modelo funcional
+ Modelo de navegacin
+ Modelo de configuracin
- Modelo evolutivo
- Modelo incremental
#Pg.177 - Modelo de la
interaccin de la webapps.
** La gran mayora de
webapps permiten una
conversacin entre un usuario
final y funcionalidades, y se
describe con el uso de un
modelo de interaccin que se
compone de los siguientes
elementos...
** Afirmaciones acerca del

tipo de relacin Asociacin y
Dependencia.
+ Casos de uso.
+ Dos clases de anlisis se

relacionan de forma parecida a
como indica el modelado UML.
+ Diagramas de estado.
+ Una asociacin puede

definirse si se indica
multiplicidad.
+ La multiplicidad se define
por las relaciones "uno a uno",
"uno a muchos", "cero a
muchos"
+ Las dependencias estn
definidas por un estereotipo.
+ Un estereotipo define un
elemento especial con semntica
y especializacin determinadas.
- Una asociacin puede
definirse si se indica herencia.
- Las dependencias estn
definidas por un paradigma.
#Pg.176 - Salida del
modelado de los requerimientos
+ Diagramas de secuencia.
+ Prototipos de la interfaz
de usuario.
- Diagramas sql
- Diagrama web
- Programacin
#Pg.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...
+ Tamao y complejidad del
incremento de la webapp.
+ Nmero de participantes.
+ Tamao 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 organizacin depende
directamente del xito de la
webapp.
- interfaces mal diseadas
- calidad del software

modelado de los requerimientos
* El anlisis de los
requerimientos provee...
+ un mecanismo
disciplinado para representar y
evaluar el contenido y
funcionamiento de las webapp
- Fomenta el desorden en el
grupo
- Software
#Pg.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 anlisis que
implementan comportamientos
asociados con la clase.
- funciones anidadas
- funciones abstractas
- funciones operacionales
- funciones de anlisis de
requerimientos
- operaciones en la
investigacin de requerimientos
- Dinero para la
implementacin
# Pg. 183 Tema: Conceptos
de Diseo
- una metodologa
desarrollada
* Creador de Lotus 1-2-3,

public en Dr. Doobs Journal un
"Manifiesto del diseo de
software"...
- un sistema de informacin
desarrollado

modelado de los requerimientos.
* Es posible desarrollar cada
uno de estos modelos con el
empleo de un esquema de
representacin llamado...
+ "lenguaje"
- "lengua"
- "interfaz"
- "mapa mental"
- "lenguaje de
programacin"
- Simulacin
- Disciplina
# Pg. 184 Tema: Diseo en

el contexto de la Ingeniera de
Software
** El empleo de la notacin
y de los mtodos de diseo
estudiados en los ltimos
captulos produce diseos de...
+ Los datos o clases
+ La arquitectura
+ La interfaz
+ Los componentes
- La estructura
- Los fundamentos
- Los diagramas
- los diagramas
implementados
- un diseo completo de las

interfaces
- Aplicacin
+ Mitch Kapor
# Pg. 185 Tema: Diseo en

el contexto de la Ingeniera de
Software
* La importancia del diseo
del software se resumen en una
palabra...
- Robbie Parker
+ Calidad
- Peter Williams
- Esfuerzo
- Robert Lautner
- Dedicacin
- Taylor Pattinson
- Esmero
- Jackson Rathbone
- Eficacia
- Ashley Greene
- Prioridad
- Cantidad
# Pg. 184 Tema: Conceptos

de Diseo
** La diversificacin y la
convergencia combinan .......
y ....... con base en la
experiencia en la construccin
de entidades similares
- "implementacin"
+ Intuicin
- "conceptual"
+ Criterio
- Hardware
# Pg. 187-188 Tema:

Atributos de calidad de "El
proceso de diseo"
** Los atributos de calidad
FURPS representan el objetivo
de todo diseo de software...
+ Funcionalidad
+ Usabilidad
+ Confiabilidad
+ Rendimiento
+ Mantenibilidad
- Abstraccin
- Ajustabilidad
# Pg. 194 Tema: Aspectos

de "Conceptos de diseo"
** Conforme tiene lugar el
anlisis de los requerimientos,
surge un conjunto de
"preocupaciones" que
incluyen...
+ Requerimientos
+ La evolucin del modelo

de diseo conforme se ejecutan
las tareas de este
- La evolucin del modelo
de diseo del dominio
de la implementacin
de diseo de la interfaz
de diseo de anlisis
de procesos
de arquitectura
+ Casos de uso
+ Caractersticas
+ Estructuras de datos
+ Calidad del servicio
+ Variantes
+ Fronteras
#Marco Carrillo Colque
#196 CLASES DE DISEO

** Son clases de diseo
+ Clases de usuario de la
interfaz
+ Clases del dominio de
negocios
+ Clases de proceso
+ Clases persistentes
+ Clases de sistemas
- Clases de implementacin
- Clases de dominio
#197 MODELO DE
DISEO
* La dimensin del proceso
indica...
#197 MODELO DE
DISEO
* La dimensin de la
abstraccin representa...
+ El nivel de detalle
conforme cada elemento del
modelo de anlisis se transforma
en un equivalente de diseo
- El nivel de detalle
diseo se transforma en un
equivalente de diseo
conforme cada usuario del
- El nivel de anlisis
equivalente de abstraccin
- El nivel de abstraccin
conforme cada grafico del
#197 MODELO DE
DISEO
* La lnea punteada indica...
+ La frontera entre los
modelos de anlisis y diseo
- La frontera entre los
modelos de abstraccin y diseo
modelos de anlisis y
abstraccin
modelos de arquitectura y
diseo
modelos de anlisis y
arquitectura
modelos de interfaz y diseo
modelos de anlisis y interfaz
#199 ELEMENTOS DE
DISEO DE LA INTERFAZ
* El diseo de software
comienza cuando...
+ Termina la primera
iteracin de la ingeniera de
requerimientos
- Termina la primera
iteracin del diseo de la
interfaz
iteracin del diseo de base de
datos
iteracin del anlisis
- Comienza la primera
iteracin del diseo de interfaz
iteracin del diseo de base de
datos
iteracin del anlisis
#203 ELEMENTOS DEL

DISEO DE DESPLIEGUE
* El objetivo del diseo de
software es...
+ Aplicar un conjunto de
principios, conceptos y prcticas
que llevan al desarrollo de un
producto de calidad
- Aplicar un conjunto de
principios que llevan al
desarrollo de una arquitectura de
calidad
desarrollo de una interfaz de
calidad
desarrollo de una base de datos
de calidad
desarrollo de un anlisis de
calidad
desarrollo de una abstraccin de
calidad
desarrollo de una gestin de
calidad
#Pg. 207 Arquitectura de

software
* Segn 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.
#Pg. 207 Arquitectura del

software
**La arquitectura no es el
software operativo. Es una
representacin que permite...
+ Analizar la efectividad del
diseo para cumplir los
requerimientos establecidos.
+ Considerar alternativas
arquitectnicas en una etapa en
la que hacer cambios al diseo
todava es relativamente fcil.
+ Reducir los riesgos
asociados con la construccin
del software.
- Aumentar los riesgos
asociados con la construccin
del software.
- Considerar alternativas
arquitectnicas en una etapa en
la que hacer cambios al diseo
es sumamente compleja.
- Despedir al personal que
no tenga la misma visin que el
resto.
trabajo de ingeniera de software

siguiente.
+ La arquitectura constituye
un modelo relativamente
pequeo y asequible por la va
intelectual sobre cmo est
estructurado el sistema.
- Porque las
representaciones de la
arquitectura evitan la
comunicacin 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 va intelectual sobre cmo
est estructurado el sistema.
- Porque el modelo del
diseo de la arquitectura y los
patrones arquitectnicos
contenidos dentro de estos son
intransferibles.
#Pg. 209 Descripciones

Arquitectnicas
** IEEE Computer Society
hizo la propuesta IEEE-Std1471-2000, Recommended
Practice for Architectural
Description of SoftwareIntensive Systems, con los
siguientes objetivos...
- Aumentar el plazo de
entrega del trabajo, con lo cual
se logra ganar ms dinero.
+ Establecer un marco
conceptual con un vocabulario
que se use durante el diseo de
la arquitectura del software.
#Pg. 208 Arquitectura de

software
+ Proporcionar lineamiento
detallados para representar una
descripcin arquitectnica.
** Razones clave por las

cuales es importante la
arquitectura del software...
+ Estimular las mejores

prcticas del diseo
arquitectnico.
+ Las representaciones de la
arquitectura del software
permiten la comunicacin entre
todas las partes interesadas
(participantes).
- Incentivar a los jvenes a

elegir una carrera relacionada
con el desarrollo de software.
+ La arquitectura resalta las

primeras decisiones que tendrn
un efecto profundo en todo el
- Estimular las prcticas

libres, sin reglas del diseo
arquitectnico.
- Generar ingresos
adicionales, con la venta de su
propuesta a los desarrolladores.
- Proporcionar lineamientos
confusos para representar una
descripcin arquitectnica.
#Pg. 210 Gneros

Arquitectnicos
** En su texto evolutivo
Handbook of Software
Architecture [Boo08], Grady
Booch sugiere los siguientes
gneros arquitectnicos para
sistemas basados en software...
las propiedades conocidas de

sus partes constituyentes.
datos de salida a traves de

varios componentes
- Un conjunto de conectores
que no permiten la
comunicacin normal entre los
componentes.
- Tiene un Conjuntos de
componentes llamados filtros
- Restricciones que definen

cuanto se debe cobrar por el
software.
- Un conjunto de
componentes que optimizan el
consumo de energa elctrica.
#Kevin Flores Chambilla
+ Inteligencia Artificial
+ Comerciales y no
lucrativos
+ Comunicaciones
+ Dispositivos
+ Financieros
+ Juegos
+ Mdicos
#Pg. 212 Estilos

Arquitectnicos
** El software construido
para sistemas basados en
computadora tiene uno de
muchos estilos arquitectnicos.
Cada estilo describe una
categora de sistemas que
incluye...
+ Un conjuto de
componentes que realizan una
funcin requerida por el
sistema.
+ Un conjunto de conectores
que permiten la comunicacin,
coordinacin y cooperacin
entre los componentes.
+ Restricciones que definen
cmo se integran los
componentes para formar el
sistema.
+ Modelos semnticos que
permiten que un diseador
entienda las propiedades
generales del sistema al analizar
#Pg. 213 - Breve

taxonoma 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.
- Los filtros transmiten datos

de un componente a otro
- Cada filtro trabaja de
forma independiente de
componentes que estn arriba
y abajo del flujo
- Se denomina lote
secuencial, al flujo de datos
degenerado en una sola lnea
de transformaciones
+ El filtro requiere
conocimientos de los trabajos
realizados de otros filtros.
- Acepta estructura con lote
de datos
#Pg. 214 - Breve

arquitectura
** 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
#Pg. 215 - Patrones

Arquitectnicos
#Pg. 213 - Breve
arquitectura
* No es verdad sobre las
Arquitecturas de flujo de datos
- Se aplica cuando los datos
de entrada se transforman en
** Patrones Arquitectnicos
+ Se aboca dentro de a un
problema de aplicacin
especifica
+ El patrn propone una
solucin arquitectnica que
sirve como base en el diseo
de arquitectura.
- No enfrenta problemas
amplios que abarca toda la
aplicacin.
- La informacin usada o
producida por el software de
seguridad.
- Hay pocas limitantes y

restricciones que no afectan la
manera de resolver el
problema.
- Se utilizan por el software

de seguridad y se muestran
como subordinados a ste.
+ Este estilo encontrara

problemas comunes que se
abordan con patrones
arquitectnicos especficos.
- El aboca a un problema de
aplicacin que no se puede
hallar.
- Un conjunto de
herramientas y notacin
estandarizadas que permiten que
el diseo se represente sin
ambigedades.
- Es el riesgo se preocupa
por los acontecimientos futuros.
+ Procesamiento de alarmas
- Estimar costo y esfuerzo
- Desarrollar un calendario
del proyecto
- Estructuras
#Pg. 222 Mtodo de la

negociacin para analizar la
arquitectura
** Cules son las
actividades de anlisis de diseo
que se mencionan en el mtodo
de la negociacin para analizar
la arquitectura?
- No presenta apoyo en la
resolucin de problemas de
aplicaciones especficas.
# Luis eduardo gamero

sandoval
#Pg. 217 - Diseo

Arquitectnico
#Pg. 219 tema

Refinamiento de la arquitectura
hacia los componentes
+ Obtencin de los
requerimientos y restricciones, y
descripcin del ambiente
** Cules son los

componentes de la
infraestructura que hacen
posible los componentes de la
aplicacin, pero no tienen
conexin con el dominio de
sta?
+ Descripcin de los estilos

o patrones de arquitectura
elegidos para abordar los
escenarios y requerimientos
** Sistemas que interactan

con el sistema objetivo
representados por
+ Sistemas Superiores
+ Sistemas Subordinados
+ Sistemas entre iguales
+ Actores
- Sistemas Vecinos
- Sistemas Enlazados
- Sistemas Trenzados
+ Administracin de
memoria
- Entidades
+ Comunicacin
- Dominio
+ Base de datos
#Pg. 218 - Definicin de

Arquetipo
* Un Arquetipo es ...
+ Una clase o un patrn que
representa una abstraccin
fundamental de importancia
crtica para el diseo 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 travs de una
interfaz
- Aplicacin
+ Administracin de tareas
#Pg. 220 Refinamiento de

la arquitectura hacia los
componentes
** El conjunto de
componentes de alto nivel sigue
las siguientes funciones...
+ Administracin de la
comunicacin externa
+ Procesamiento del panel
de control
+ Administracin de
detectores
+ Escenarios de
investigacin
+ Evaluacin de los
atributos de calidad,
considerando cada atributo por
separado
+ Identificacin de la
sensibilidad de los atributos de
calidad de varios atributos
arquitectnicos para un estilo de
arquitectura especfico
+ Crtica de las arquitecturas
candidatas con el uso del
anlisis de sensibilidad
- Escenarios de ayuda
#Pg. 222 Mtodo de la

negociacin para analizar la
arquitectura
** En la descripcin 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
- Se mejora los
Componentes
- Perspectiva de datos
- Perspectiva de flujo
- Perspectiva de funciones
#Silvana Beatriz Cabana

Yupanqui
- Perspectiva de atributos
#Pg. 231 Diseo de la
arquitectura
#Pg. 224 Complejidad
arquitectnica
** La complejidad
arquitectnica considera las
dependencias entre los
componentes de la arquitectura,
marque cuales son
+ Las dependencias
compartidas
+ Las dependencias de flujo
+ Las dependencias de
restriccin
- Las dependencias de
recursos
- Las dependencias de red
Componentes COTS
* El refinamiento de la
arquitectura del software de
estimularse en...
+ Las primeras etapas del
diseo
- Las ltimas etapas del
diseo
- Refinando y evaluando en
busca del "mejor" enfoque
- En la optimizacin del
diseo
- En todas las etapas del
proyecto
- En ninguna etapa del
diseo
- Luego de haber realizado
el front-end.
Componentes nuevos
#Pg. 239 Diseo de nivel
de componentes
#Pg. 224 Complejidad
arquitectnica
** En la tcnica de mapeo
llamado diseo estructurado,
tiene los siguientes pasos...
+ Se establece el tipo de
flujo de informacin
+ Se indican las fronteras
del flujo
+ Se mapea el DFD en la
estructura del programa
+ Se define la jerarqua del
control
+ Se refina la estructura
resultante con el empleo de
criterios de medicin para el
diseo y heursticos
+ Se mejora y elabora la
descripcin arquitectnica

arquitectura
** Es el encargado de
ilustrar la estructura y
organizacin de los
componentes del software
- El diseo front-end
+ La arquitectura del
software
+ El que tambin est
encargado de proporcionar una
visin holstica del sistema.
- El anlisis del sistema
- La encargada tambin de
la visin paralela en el software.
- Los requerimientos del
sistema
- Los requisitos del sistema.

arquitectura
* El diseador identifica un
conjunto de abstracciones de
alto nivel que tambin son
llamados...
- architipos
+ arquetipos
** En medida que avanza el

trabajo de diseo se dispone
de...
- diseos metodolgicos
+ un catlogo de diseo
probado.
- tipos de datos
+ un catlogo de
componentes o patrones de
diseo.
- un catlogo de mtodos de
programacin.
- Infraestructura TI
- tipos recurrentes
- tipos metodolgicos
- tipos arquitectnicos del
diseo
- una base de datos

concurrentes.

arquitectura
- un catlogo de personas
involucradas en el proyecto.
** El diagrama de flujo de
datos se mapea...
- un registro donde
almacenamos todos los cambios.
+ Con el uso del enfoque del

mapeo de la transformacin
+ la visin relacionada con

el proceso.
+ En una estructura que

asigna el control a la entrada

asigna el control al
procesamiento
#243 DISEO EN EL
NIVEL DE COMPONENTES

asigna el control a la salida
** Los Tipos de cohesin...

+ Funcional
- En una estructura
matemtica
+ De capa
- En una estructura fsica
+ De comunicacin
- En una estructura no
listada en el proceso de
ingeniera
- De enlace
- De componente
- De clase
#Pg. 234 Diseo de nivel

de componentes
** Un enfoque alternativo
consiste en representar el diseo
en el nivel de los componentes
en alguna representacin
intermedia como...
- En booleano
+ Grafica
#244-245 DISEO EN EL
** Las categoras del nivel
de componentes son...
+ Acoplamiento de
contenido
+ Acoplamiento comn
+ Basada en texto
+ Acoplamiento del control
- Oral
+ Acoplamiento de molde
+ Tabulada
+ Acoplamiento de datos
- En pulsaciones de luz
+ Acoplamiento de rutina de
llamada
#Jose Luis Lanchipa Jilaja
uso
* Qu es cohesin, segn
el concepto de diseo?
+ Unidad de objetivo de un
componente
- Unin de los componentes
- Adherir partes
- Trabajar en conjunto
- Participar en grupo
+ Desarrollar y elaborar
representaciones del
comportamiento para una clase
o componente
+ Elaborar diagramas de
despliegue para dar ms detalles
de la implantacin
+ Redisear cada
representacin del diseo en el
nivel de componentes y
considerar alternativas
- Relacional
- En pulsaciones
#243 DISEO EN EL
identificar las clases requeridas

para administrarlos
+ Acoplamiento de tipo de
#246-251 REALIZACIN
DEL DISEO EN EL NIVEL
DE COMPONENTES
#251 DISEO EN EL
PARA WEBAPPS
* Qu es un componente de
webapps?
+ Una funcin cohesiva bien
definida que manipula
contenido
- Es un parte fundamental de
una aplicacin
- Encargado del enlace de la
aplicacin
- Capa encargada del diseo
- Capa encargada del
protocolo
- Caso de uso que se encarga
del enlace
- Es aquel que se hace
despus de un despliegue
webapps
** Pasos para el diseo en el

nivel de componentes
#254 NOTACIN DEL

DISEO TABULAR
+ Identificar todas las clases

de diseo que correspondan al
dominio del propietario
** Para desarrolar una tabla

de decisin
+ Identificar todas las clases

de diseo que correspondan al
dominio de la infraestructura
- Hacer un buen uso del

hardware
+ Elaborar todas las clases

de diseo que no sean
componentes reutilizables
- Que el software este

compacto
+ Describir las fuentes

persistentes de datos e
+ Enlistar todas las acciones

asociadas con un procedimiento
+ Enlistar todas las
condiciones
+ Asociar conjuntos
especficos de condiciones con
acciones especficas
+ 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 diseo
- Asociar los componentes
ya definidos en la interfaz
- Definir el dominio de la
estructura.
#257
** La ingeniera del
dominio incluye tres actividades
especiales
+ Anlisis.
+ Desarrollen Beans
especiales para el uso en una
aplicacin especfica.
+ Prueben y evalen el
comportamiento Bean.
- Analizar el IDE para
desarrollar el Bean.
- Verificar la compatibilidad
del Bean.
+ Construccin.
#Alfredo Nstor Juanillo
Mamani
+ Diseminacin.
- Contemplacin.
- Destruccin.
#255
** El lenguaje de diseo de
programa (LDP), es tambin
llamado
+ Castellano estructurado.
+ Seudocdigo.
- Bloque estructurado.
- Bloque no estructurado.
- Idioma estructurado.
- Semi-Seudocdigo.
- Cableado estructurado.
- Inseminacin.
- Capacitacin.
#260
** Binder sugiere varios
aspectos clave que constituyen
la base del diseo para la
reutilizacin
+ Datos estndar.
+ Protocolos de interfaz
estndar.
+ Plantillas del programa.
#266
** En su libro sobre el
diseo 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 mltiples
interfaces grficas.
- Finalizar los controles.
- Adaptabilidad.
#257
** En el enfoque general del
anlisis del dominio los pasos
de este proceso se definen como
sigue
+ Definir el dominio que se
va a investigar.
+ Clasificar los aspectos
extrados del dominio.
+ Reunir una muestra
representativa de aplicaciones
en el dominio.
+ Analizar cada aplicacin
en la muestra y definir clases de
anlisis.
+ Desarrollar un modelo de
los requerimientos para las
clases.
- Definir el dominio de la
funcin.
- 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
# Yeny Laquita Mamani

2011-119053
# Paginas 267-278
# Pg. 267
** Dejar al control del
usuario...
+ Analicen la forma en la
que funcionan los Beans
existentes.
+ Definir modos de
interaccin de manera que no se
obligue al usuario a realizar
acciones innecesarias o no
deseadas.
+ Personalicen su
comportamiento y apariencia.
+ Dar una interaccin

flexible.
+ Establezcan mecanismos
para la coordinacin y
comunicacin.
+ Permitir que la interaccin

del usuario sea interrumpible y
tambin reversible.
+ Facilitar la interaccin a
medida que aumenta la
habilidad y permitir que aqulla
se personalice.
+ Ocultar los tecnicismos
internos al usuario ocasional.
+ Disear la interaccin
directa con objetos que
aparezcan en la pantalla.
- Dar una interaccin
inflexible.
- No permitir que el usuario

coloque la tarea en curso en un
contexto significativo.
** Para el anlisis de tarea

se debe responder preguntas
como...
- No mantener la
consistencia en toda la familia
de aplicaciones.
+ Qu trabajo realizar el
usuario en circunstancias
especficas?
- NO mantener modelos
interactivos anteriores han
creado expectativas en el
usuario.
+ Qu tareas y subtareas se
efectuarn cuando el usuario
haga su trabajo?
- Nunca dar la razn al

usuario.
# Pg. 267
** Reducir las necesidades
del usuario...
+ La demanda de memoria
de corto plazo.
+ Hacer que lo
preestablecido sea significativo.
+ Definir atajos que sean
intuitivos.
# Pg. 271 -272

** El proceso de diseo de
la interfaz de usuario consta de
actividades estructurales...
+ Anlisis.
+ Modelado de la interfaz.
+ Diseo de la interfaz.
+ Construccin.
+ La distribucin visual de
la interfaz debe basarse en una
metfora del mundo real.
+ Validacin.
+ Revelar informacin de
manera progresiva.
- Interpretacin.
- Definir atajos que no sean

intuitivos.
- La distribucin visual de la
interfaz debe basarse en el
criterio.
- No Revelar informacin de
manera progresiva.
** Es el principio de diseo
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.
+ Cul es la secuencia de
las tareas?
+ Cul es la jerarqua de
las tareas?
- Qu dominio no es
importante en el problema?
- Cul es la secuencia de la
jerarqua?
- Cul es jerarqua de las
secuencias?
- Diseo del caso de uso.

# Zuleydi Mendoza Callao
- Consistencia.
# Pg. 279-280 Etapas del
diseo de la interfaz
# Pg. 272-273
** La informacin puede
proceder de diversas fuentes...
+ Entrevistas.
+ Informacin de ventas.
# Pg. 267
+ Qu dominio de
problema especfico manipular
el usuario al realizar su labor?
+ Informacin de
mercadotecnia.
+ Informacin de apoyo.
- Informacin de
construccin.
- Informacin del diseo.
- Informacin de casos de
uso.
* El diseo de la interfaz es
un proceso...
- Secuencial.
+ Iterativo.
- Paralelo.
- Detallado.
- Intuitivo.
# Pg. 281 Aspectos del

diseo
** Son 4 aspectos comunes
del diseo...
- Leyendas de los bosquejos.
# Pg. 273
- Tiempo de respuesta del

cliente.
- Manejo de informacin
referencial.
+ Tiempo de respuesta del

sistema.
+ Herramientas de ayuda
para el usuario.
+ Manejo de informacin
errnea.
+ Leyendas de los
comandos.
- Para qu lo har?
# Pg. 285-286 Principios y

lineamientos del diseo de la
interfaz
** Son algunos principios
generales de diseo...
+ Previsin.
+ Comunicacin.
# Pg. 282 Manejo de

errores
+ Consistencia.
#Dante Huillca Duran 2011119059
#Pg. 291 evaluacin de

diseo
** Pertenecen al ciclo de
evaluacin de diseo de la
interfaz...
+ Diseo preliminar
+ Construccin del prototipo
numero 1
** Todo mensaje de error o

advertencia producido por un
sistema interactivo debe tener
las siguientes caractersticas...
+ Autonoma controlada.
+ Evaluacin del usuario
+ Eficiencia.
+ Estudio de la interfaz
+ Flexibilidad.
+ Modificaciones de diseo
+ El mensaje debe describir

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

consejos constructivos para
corregir el error.
# Pg. 289-290 Flujo de

trabajos para el diseo de la
interfaz de webapp
+ El mensaje debe indicar

cualesquiera consecuencias
negativas del error.
** Son alguna de las tareas

que representan un flujo de
trabajo rudimentario para
disear una interfaz para
webapp...
- No debe ser muy corto.

- Debe dar instrucciones de
correccin.
+ El mensaje debe estar
acompaado de una clave
audible o visual.
+ El mensaje no debe
juzgar.
# Pg. 284 Diseo de una

interfaz para webapps
** Debe disearse una
interfaz de webapp de modo que
responda 3 preguntas
principales del usuario final...
+ Dnde estoy?
+ Qu puedo hacer ahora?
+ Dnde he estado, hacia
dnde voy?
- A dnde puedo ir?
- Cundo lo har?
- Cmo lo har?
+ Revisar la informacin
contenida en el modelo de
requerimientos y refinarla segn
se requiera.
+ Desarrollar un esquema
aproximado de la distribucin
de la interfaz para la webapp.
+ Mapear los objetivos del
usuario en acciones especficas
de la interfaz.
+ Definir un conjunto de
tareas de usuario asociadas con
cada accin.
+ Elaborar un guion de las
imgenes en la pantalla para
cada accin de la interfaz.
+ Refinar la distribucin de
la interfaz y los guiones con
entradas del diseo de la
esttica.
+ Identificar los objetos de
la interfaz de usuario requeridos
para implementar la interfaz.
+ Construccin del prototipo

numero n
- construccin del prototipo
numero 2
#Pg. 291 Criterios de

evaluacin de interfaz
** Criterios de evaluacin
durante la revisin de la
interfaz...
+ Cantidad de aprendizaje
requerido por los usuarios del
sistema
+ Tiempo de interaccin de
la eficiencia general del sistema
+ La Carga de memoria para
los usuarios del sistema
+ Complejidad de la interfaz
+ Grado de aceptacin por
parte del usuario
+ Longitud y Complejidad
del modelo de requerimientos
+ El nmero de acciones,
tareas y estados del sistema
#Pg. 296 patrones de

diseo
** Caractersticas de un
patrn de diseo eficaz
+ Resuelve un problema
+ Es un concepto probado
+ La solucin no es obvia
+ Describe una relacin
+ Tiene un componente
humano significativo
- La solucin es obvia
- Es un concepto no probado
#Pg. 300 descripcin de un

patrn
** Informacin que contiene
el formato de diseo del patrn
+ Nombre del patrn
+ Problema
#Pg. 297 Clases de

patrones
+ Motivacin
+ Contexto
** Son clases de patrones...
+ Solucin
+ Generativos
+ Objetivo
+ Arquitectnicos
+ Implementacin
+ Patrones de datos
+ Componentes
+ Patrones de diseo
+ Patrones de webapp
#JESUS MANUEL
QQUEHUE CUCHILLO
#303-314
** Diferencias entre los

patrones de diseo y las
estructuras
+ Los patrones de diseo
son ms abstractos que las
estructuras
son elementos arquitectnicos
ms pequeos que las
estructuras
estn menos especializados que
las estructuras
- Los patrones de diseo son
elementos arquitectnicos ms
grandes que las estructuras
- Los patrones de diseo
estn ms especializados que las
estructuras
- Los patrones de diseo son
menos abstractos que las
estructuras
+ Una estructura normal
contiene varios patrones de
diseo, lo contrario sucede con
los patrones.
+ Mejorar el diseo,
adaptando cada patrn a las
especificidades del software que
se trata
de elaborar.
- Una vez terminado todos
los pasos anteriores se empieza
a reconfigurar el software.
#pgina 303-304: Tareas de

Diseo
* Cuntas tareas de diseo
se necesitan para tener xito y
sea ptimo?
+8
-4
-6
+ Creacionales
#Pg. 299 Estructuras
+ Repetir los pasos 1 a 4

hasta que el diseo est
completo.
#pgina 303: Diseo basado

en Patrones
-6
** Shalloway y Trott
sugieren el siguiente enfoque,
que permite que un diseador
-9
-5
- 12
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 comprensin.
+ Estudiar el panorama,
identificar los patrones
presentes en ese nivel de
abstraccin.
+ Comenzar el diseo con
patrones del panorama que
establezcan un contexto o
esqueleto
para el trabajo de diseo
adicional.
+ Trabajar dentro del
contexto Shalloway en busca
de patrones en niveles ms bajos
de
abstraccin que contribuyan
a la solucin del diseo.
#pgina 305: Construccin

de una tabla para organizar el
patrn
** 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
- Direccin
- Telfono
#pgina 306: Patrones

Arquitectnicos
** Los patrones
Arquitectnicos para el software
definen ciertos numeros de
dominios, cuntos y cules
son?
+ son 4
- son 3
+ Patrones de interaccin.
+ Simplicidad
+ Patrones de presentacin.
+ Consistencia
+ Patrones funcionales.
+ Identidad
- Patrones de Interfaz.
+ Robustez
- Patrones no funcionales.
+ Navegabilidad
+ Atractivo visual
+ Control de Acceso.
+ Concurrencia.
#Carlos Cesar Zelada

Melchor
+ Compatibilidad
+ Distribucin.
+ Persistencia.
- Concurrencia
#pgina 308: Patrones de

Diseo en el nivel de
Componentes
* Los patrones de diseo en
el nivel de componentes
brindan...
+ Soluciones comprobadas
que se abocan a uno o ms
subproblemas extrados del
modelo de requerimientos.
- Soluciones no
comprobadas que se abocan a
uno o ms subproblemas
extrados del modelo de
requerimientos.
- Interfaces acabadas y muy
atractivas.
- Ayuda a los dems niveles.
#Pgina 321
#Pgina 319 Webapps
** Cules son los
principales atributos de las
Webapps?
+ Usabilidad
+ Fracasar
+ Funcionalidad
- Mejorar
+ Confiabilidad
- Crecer
+ Eficiencia
- Continuar
+ Facilidad para recibir

mantenimiento
- Libre
* Segn Jean Kaiser: "Que

algo pueda hacerse,...
+ no significa que deba
hacerse"
- Interfaces incompletas y
poco atractivas.
- no significa que tenga que

hacerse"
- significa que deba hacerse"
- significa que pueda
hacerse"
#pgina 310: Patrones de

Diseo de la Interfaz de Usuario
- significa que tenga que

hacerse"
** Los patrones de webapps

se clasifican con el empleo de
los siguientes niveles de
atencin en el diseo...
- significa que es necesario

hacerse"
+ Patrones de navegacin.
- Se eliminar
- Podr ser optimizada
#Pgina 322
#Pgina 320
- no significa que pueda

hacerse"
+ Patrones de arquitectura
de la informacin.
- Perdurar
- Creativo
- Mantenimiento al
Hardware.
- Independencia en los
niveles.
* Segn Curt Cloninger: "Si

un sitio es perfectamente
utilizable, pero carece de un
estilo elegante y apropiado, ...
#Pgina 320
** Cules son las metas del
diseo de una Webapp?
** Cul de los siguientes

diseos pertenece a la pirmide
de diseo de las Webapps?
+ Diseo de la interfaz
+ Diseo esttico
+ Diseo del contenido
+ Diseo de la navegacin
+ Diseo de la arquitectura
+ Diseo de los
componentes
- Diseo de la programacin
#Pgina 323
* "Descubrimos que las
personas evalan rpidamente
un sitio tan slo por su diseo...
+ Visual"
- Estructurado"
- Ordenado"
- Esttico"
- De colores"
- De funciones"
- De los componentes"
#Pg. 341 Dimensiones de

la calidad de Garvin
** Son dimensiones de
calidad propuestas por David
Garvin
+ Calidad del desempeo
+ Calidad de las
caractersticas
# Kevin Mike Herrera Vega

#Pg. 334-354
+ Confiabilidad y
Conformidad
+ Durabilidad
#Pg 334 Calidad de una

webapp
** Son caractersticas para
un buen diseo de una
webapp
+ Sencillez
+ Consistencia
+ Identidad
+ Robustez
+ Navegabilidad
+ Atractivo visual
+ Servicio
+ Esttica
+ Percepcin
#Pg. 342 Factores de la

calidad de McCall
** La clasificacin 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
+ Usabilidad
+ Eficiencia
+ Facilidad de recibir
mantenimiento
+ Portabilidad
- Costo
#Pg. 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
- Complejidad de uso
+ Sus caractersticas
operativas
- Proceso procura que el

producto final se libre de fallas
#Pg. 339 Qu es calidad?
+ Su capacidad de ser
modificado
- Proceso no eficaz de
desarrollo
+ Su adaptabilidad a nuevos
ambientes
- Proceso que no se fija en

buenas practicas, solo en tiempo
** David Garvin, de
Harvard Bussiness School,
sugiere que la calidad es un
concepto complejo de mltiples
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
- Su costo en el mercado
- Su costo de operacin
- Proceso que nunca podr

definirse
- Su tiempo de ejecucin
- Sus niveles de seguridad
#Pg. 343 Factores de la

calidad ISO 9126
** El estndar ISO 9126 se
desarroll con el fin de
identificar atributos claves del
software. Este estndar
identifica 6 atributos clave de
calidad
+ Funcionalidad
+ Confiabilidad
# Perfecto Henrry
Cachicatari Mamani 201236148
# Pgs. 555-566
#Pg. 555 el espectro

administrativo.
** La administracin
efectiva de un proyecto de
software se enfoca en las cuatro
P
+ Personal.
+ Producto.
+ Proceso.
+ Proyecto.
- Produccin
- Perspectiva
- Prospecto
eficaz enfatizan cuatro rasgos

clave
+ Resolucin de problemas.
+ Identidad administrativa.
+ Logro.
+ Influencia y construccin
del equipo.
#Pg. 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
(tcnicos), quienes deben
planificar, motivar, organizar y
controlar a los profesionales que
hacen el trabajo de software.
+ Profesionales que aportan
las habilidades tcnicas que se
necesitan para someter a
ingeniera un producto o
aplicacin.
+ Clientes que especifican
los requerimientos para el
software que se va a fabricar, as
como otros participantes que
tienen un inters perifrico en el
resultado.
- Lder, quien dirige no
dirige a los participantes del
proyecto
+ Usuarios finales, quienes
interactan con el software una
vez que se libera para su uso
productivo.
- Personal, quien atiende a
los participantes del proyecto
para que se sientan cmodos y
desarrollen con xito
#Pg. 558 Los lideres

** Las caractersticas que
definen a un gerente de proyecto
- Motivacin
- Organizacin
+ Cmo encaja en un
sistema, producto o contexto
empresarial ms 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?
- Ideas o innovacin
+ Qu funcin realiza el
software para transformar los
datos de entrada en salida?
#Pg. 558 El equipo de

software
+ Existe alguna
caracterstica de desempeo
especial que deba abordarse?
** Mantei [Man81] describe

los factores de proyecto que
deben considerarse cuando se
planee la estructura de los
equipos de ingeniera de
software
+ Dificultad del problema
que se va a resolver.
+ Tamao del programa
resultante en lneas de cdigo o
puntos de funcin.
+ Tiempo que el equipo
permanecer unido (vida del
equipo).
+ Grado en el que puede
dividirse en mdulos el
problema.
- Qu funcin realiza el
software para el cliente?
- Qu funcin cumple el
cliente en la etapa de la
programacin?
#Pg. 565 El proceso,

descomposicin del proyecto
** Un proyecto simple y
relativamente pequeo puede
requerir las siguientes tareas
para la actividad de
comunicacin
+ Desarrollar lista de
clarificacin de conflictos.
+ Calidad y confiabilidad
requeridas por el sistema que se
va a construir.
+ Reunirse con los

participantes para abordar la
clarificacin de conflictos.
+ Rigidez de la fecha de
entrega.
+ Desarrollar en conjunto un
enunciado del mbito.
+ Grado de sociabilidad
(comunicacin) requerido para
el proyecto.
+ Revisar el enunciado del

mbito con todos los
interesados.
#Pg. 562 El producto,

mbito del software
** La primera actividad en
la administracin del proyecto
de software es determinar el
mbito del software, que se
define al responder las
siguientes preguntas
+ Modificar el enunciado
del mbito segn se requiera.
- Modificar el enunciado del
mbito segn se requiera
- Revisar el conjunto de
enunciados con los interesados
#Edward Axel Cruz

Catacora
#567-578
#Pg. 567 El principio

W5HH
** En el principio W5HH,
Cules son las preguntas que
conducen a una definicin de las
caractersticas clave del
proyecto?
+ Por qu (Why) se
desarrollar el sistema?
#Pg. 572 Las mtricas 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 desempeo del equipo
- El precio del producto
+ Qu (what) se har?
- Los clientes
+ Cundo (when) se har?
- La documentacin
- Quin (who) es el cliente?
- Los pagos
+ Dnde (where) se
ubicarn en la organizacin?
+ Cmo (how) se har el
trabajo, tcnica y
organizativamente?
+ Cunto (how much) se
necesita de cada recurso?
- Las pruebas
#Pg. 577 Mtricas

orientadas a funcin
* Usan una medida de la
funcionalidad entregada por la
aplicacin como un valor de
normalizacin, este concepto
pertenece a ...
- Reconciliacin de mtricas
LOC y PF
- Mtricas orientadas a
tamao
- Medidas directas del
proceso de software
- Mtricas de proceso
#Pg. 572 Las mtricas del

proceso y la mejora del proceso
de software
* La eficacia de un proceso
de software slo puede medirse
de manera...
- Mtricas orientadas al
desarrollo
- Mtricas de normalizacin
+ Mtricas orientadas a
funcin
- Directa
#Pg. 572 MTRICAS EN
LOS DOMINIOS DE
PROCESO Y PROYECTO
** Las mtricas 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
crticas
+ 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 visin del
proyecto
- Sustancial
- Superficial
#ALONSO GODINEZ
2012-36156
- Perspectiva
- General
- Global
- Local
+ Indirecta
#Pg. 574 Mtricas de

proyecto
* La primera aplicacin de
las mtricas de proyecto sobre la
mayora de los proyectos de
software ocurre durante...
+ La estimacin
- La recopilacin de
requerimientos
#579 Mtricas orientadas a

objetos
** Cules son las mtricas
orientadas a objetos?
+ Nmero de guiones de
escenario.
+ Nmero de clases clave.
+ Nmero de clases de
apoyo.
+ Nmero promedio de
clases de apoyo.
+ Nmero de subsistemas.
- Nmero de punteros.
- Nmero de listas
enlazadas.
- El desarrollo
- El anlisis
- El diseo
- La programacin
#580 Mtricas orientadas a

caso de uso
orientadas a casos de uso?
+ Nmero de casos de uso.

+ Nmero de casos de
prueba.
+ Esfuerzo.
+ Tamao de aplicacin.
- Lenguaje de
programacin.
- SGBD.
- Metodologa de desarrollo.
#580 Mtricas de proyecto

webapp
de un proyecto webapp?
+ Nmero de pginas web
estticas.
+ Nmero de pginas web
dinmicas.
+ Nmero de vnculos de
pgina interno.
#584 Mtricas para calidad

de software
#Pg. 593 Estimacin para

proyectos de software
* Por qu es importante
medir el proceso de ingeniera
de software?
** Antes de que un proyecto

pueda comenzar, el equipo de
software debe...
+ Porque si no se mide, no
hay forma real de saber si se
est mejorando.
+ Estimar el trabajo que se

va a realizar
- Porque si no se mide,
demora ms.
- No hay forma de medir el
proceso de software.
- Porque es necesario para la
documentacin.
- Porque sirve para definir el
costo.
- Porque sirve para definir el
tiempo.
- Porque sirve para definir
los requerimientos.
+ Nmero de objetos de
contenido dinmico.
+ Nmero de objetos de
contenido esttico.
+ Nmero de funciones
ejecutables.
+ Nmero objetos de datos
persistentes.
#586 Integracin de
mtricas dentro del proceso de
software
* Qu es una lnea de
referencia de mtrica?
+ Es un conjunto de datos
recopilados a partir de proyectos
de software
#582 Mtricas para calidad

de software
- Es una lnea de cdigo

comentada

de calidad?
- Es una suposicin
+ Exactitud.
+ Mantenibilidad.
+ Integridad.
+ Usabilidad.
- Lneas de cdigo.
- Es un estndar de calidad
de software
- Es una metodologa de
software
- Es un patrn de diseo
- Es un diagrama complejo
de requerimientos
- Metodologa de desarrollo.
- Nmero de
desarrolladores.
- Ver los contratiempos

+ Estimar los recursos que
sern 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
#Pg.594 Observaciones
acerca de las estimaciones
** Las siguientes
observaciones tienen efectos
sobre las estimaciones para el
proyecto de software
+ Complejidad del proyecto
+ El tamao del proyecto
- El nmero de usuarios del
sistema
+ El grado de incertidumbre
+ Disponibilidad de
informacin histrica
- La planificacin del
proyecto
- La calendarizacin para el
desarrollo
#Pg. 596 - 598 Recursos

para el desarrollo de software
** Las tres principales
categoras de recursos para el
desarrollo de software son...
+ Recursos humanos
#Gladys Huanacune
Chambilla
2012-36157
- Recursos monetarios
+ Recursos de software
reutilizables
- Dimensionamiento del
cdigo
- Recursos de hardware
camino
+ Recursos Ambientales
- Recursos de planificacin
de tareas
- Recursos para la impresin
digital
#Pg. 598 Estimacin de

proyectos de software
* La estimacin 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
exacta
- Solo esfuerzo del software
es una ciencia exacta
- Tiempo y costo del
exacta
- Beneficios del software
nunca ser una ciencia exacta
#Pg. 600 Tcnicas de

descomposicin
** Putnam y Myer sugieren
cuatro enfoques para el
problema de
dimensionamiento...
#Pg. 600 - 602 Estimacin

basada en problema
** Desarrollar un enfoque
de estimacin con casos de usos
es problemtico por las
siguientes razones...
** Con respecto a la tcnica

de estimacin PF, se puede
decir...
+ Los casos de uso se

describen usando muchos
formatos
+ Se enfoca en cada una de

las caractersticas del dominio
de informacin
+ Los casos de uso

representan una visin externa
del software
+ Sus datos se usan como

variables para dimensionar cada
elemento del software
+ Los casos de uso no

abordan la complejidad de las
funciones
+ Sus datos se usan cono

mtricas de referencia
recopiladas de proyectos
pasados
+ Los casos de uso pueden

describir comportamiento
complejo
- Se enfoca solo en entradas

y salidas
- Lleva a considerables
niveles de detalle
- Se enfoca en la funcin
#Angel Rodriguez Romero

#2012-36165
#Pgina 604 - Estimacin

basada en proceso
* La tcnica ms comn
para estimar un proyecto es
basar...
+ La estimacin sobre el
proceso que se usar
- La estimacin errada
+ Dimensionamiento de
punto de funcin
- La cantidad de lneas de
cdigo
componente circular
- Las horas de trabajo
+ Dimensionamiento del
cambio
- Los casos de uso son muy

fciles de realizar
- Los casos de uso son muy
complejos de entender
- Los casos no estn
diseados correctamente
- Es totalmente seguro
"lgica difusa"
componente estndar

con casos de uso
- La estimacin de tiempo
- La bajas de personal
- La cantidad de
procedimientos

con casos de uso
* Smith argumenta que
cualquier nivel de esta jerarqua
estructural puede describirse
mediante
+ No ms de 10 casos de
uso
- No ms de 1 caso de uso
- No ms de 5 casos de uso

con casos de uso
* Segn Smith cada caso de
uso no abarca ms de ..
+ 30 escenarios distintos
- Modelo de capa escasa
- 20 escenarios distintos
- Modelo de composicin de
interfaz
- 1 escenario distinto
#Pgina 607 Reconciliacin 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
tcnicas de estimacin basadas
en problema son inadecuadas
- No se entendi el
propsito del proyecto
- Los datos son inadecuados
* Si el sistema se va a
construir desde cero. De cunto
ser la posibilidad de que el
trabajo sea difcil?
- 50 por ciento
- 55 por ciento
- 60 por ciento
+ 70 por ciento
- 71 por ciento
- 75 por ciento
- 80 por ciento
#Pgina 615 Creacin de un

rbol de decisin
** La organizacin de
ingeniera de software puede...
+ Construir el sistema x
desde cero
+ Reusar componentes de
experiencia parcial existentes
para construir el sistema
- Es inadecuado para un
grupo de trabajo
- Gestionar la disponibilidad
del desarrollador.
#Pgina 609 - El modelo

COCOMO II
+ Comprar un producto de
software disponible y
modificarlo para satisfacer las
necesidades locales.
+ Modelo de composicin
de aplicacin
+ Modelo de etapa temprana
de diseo
+ Modelo de etapa
postarquitectnica
- Modelo de capa temprana
- Modelo de etapa
prearquitectnica
- Secuencial
- Programable
+ Tctica
# Pgina 615 Creacin de un

rbol de decisin
- Existe poca consistencia

en la finalidad del proyecto
** Cocomo II en realidad es
una jerarqua de modelos de
estimacin que aborda la reas
siguientes..
- Analtica
- Estructuras los costos

esperados y las probabilidades.
+ Contratar el desarrollo del
software a un proveedor
externo.
- Estimar el desarrollo y
planificacin del proyecto.
#Pgina 616 Outsourcing

** La decisin del
Outsourcing puede ser...
+ Estratgica
- Trabajable
- Continua
#Pgina 620
Calendarizacin del proyecto
** La calendarizacin
adecuada requiere que...
+ Todas las tareas aparezcan
en la red.
+ El esfuerzo y la
calendarizacin 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
funcin 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.
#Pgina 621 Conceptos

bsicos
** Aunque existen muchas
razones por las que el software
se entrega tardamente, la
mayora pueden rastrearse en
una o ms de las siguientes
causas fundamentales...
+ Una fecha lmite irreal
establecida por alguien externo
al equipo de software.
+ Requerimientos del cliente
variables que no se reflejan en
cambios del calendario.
+ Una honesta
subestimacin de la cantidad de
esfuerzo y/o nmero de recursos

que se requerirn para hacer el
trabajo.
- Excesiva comunicacin
entre el personal del proyecto.
** Los proyectos de
desarrollo de concepto se
abordan al aplicar las siguientes
acciones...
+ El mbito del concepto
+ Evaluar los resultados de

todas las revisiones realizadas.
+ Determinar si los hitos se
lograron en la fecha provista.
+ Falta de comunicacin
entre el personal del proyecto.
+ La planificacin
preliminar del concepto
+ Comparar la fecha de
inicio real con la fecha de inicio
planeada.
+ Riesgos predecibles y/o

impredecibles que no se
consideraron cuando comenz
el proyecto.
+ La valoracin del riesgo

tecnolgico
+ Reunirse informalmente
con los profesionales
+ Dificultades humanas que

no podan prever por anticipado.
+ La implementacin del
concepto
+ La prueba del concepto
+ La reaccin del cliente

#Pgina 622 Conceptos
bsicos
** 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 estimacin
detallada, usando datos
histricos de proyectos
anteriores.
+ Con el modelo de proceso
incremental, desarrollar una
estrategia de ingeniera de
software que entregue
funcionalidad crucial hacia la
fecha lmite 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 lmite
es irreal.
- No presentar una
estimacin slida con base en
buenos datos histricos.
+ Ofrecer la estrategia de
desarrollo incremental como
una alternativa.
- Faltar por parte de la
administracin del proyecto
para reconocer que el proyecto
tiene retrasos y falta acciones
para corregir errores.
#Pg. 627 Conjunto de

tareas
- La verificacin del
proyecto
#Pg.627 Refinamiento de
acciones de ingeniera de
software
** Es cierto sobre el
refinamiento de acciones de
ingeniera del software
+ Debe refinarse para crear
un calendario de proyecto
detallado.
+ Usar anlisis de valor

ganado
- Control de las tareas
programadas.
#Pg.632 Calendarizacin
* Son hitos tcnicos del
diseo orientado a objetos
completo...
+ Definicin y revisin del
conjunto de subsistemas.
+ Asignacin de clases a
subsistemas y su revisin.
+ Establecimiento y revisin
de la asignacin de tareas.
+ Comienza tomando cada

accin
+ Identificacin de
responsabilidades y
colaboraciones.
+ Se descompone cada
accin en un conjunto de tareas
+ Diseo y revisin de
atributos y operaciones.
+ El refinamiento de las
tareas puede lograrse con un
formato de bosquejo.
+ Creacin y revisin del

modelo de comunicacin.
- Se usa un bosquejo
orientado a objetos
- Debe refinarse para crear
un cronograma.
+ Comienza con el mbito
del concepto
#Pg. 629 Calendarizacin

** El seguimiento puede
lograrse en varias formas
diferentes
+ Realizar reuniones
peridicas del estado del
proyecto.
- Revisin de todas las

clases
#Pg. 633 Calendarizacin

para proyectos webapp
** Los incrementos para el
componente del proyecto basado
en web...
+ Informacin bsica de
compaa y producto.
+ Informacin detallada de
producto y descargas.
+ Citas de producto y
procesamiento de pedidos de
producto.
+ Plantilla espacial y diseo

de sistemas de seguridad.
- Ayer y hoy estn ms all

de la preocupacin activa.
empresarial global de la
compaa.
+ Servicios de informacin
y solicitud de monitoreo.
- Al que madruga dios lo

ayuda.
+ Control en lnea del

equipo de monitoreo.
- Ojo por ojo, diente por

diente.
+ Construir un producto que

el equipo de ventas no sabe
cmo vender.
+ Acceso a informacin de
cuenta.
#Pg. 636 Valor ganado

** Para determinar el valor
ganado se realizan los siguientes
pasos...
#Pg. 641 - Riesgos de

Software.
** Cules son las dos
caractersticas del riesgo de
software?
+ Incertidumbre.
+ Determinar el costo
presupuestado del trabajo
calendarizado.
+ Riesgo.
+ Determinar el presupuesto
al concluir.
- Efectividad
+ Calcular el costo
presupuestado del trabajo
realizado.
- Hallar el ndice de
rendimiento.
- Calcular la variacin del
calendario.
- Calcular el indicio de la
eficiencia del proyecto.
- Hallar el porcentaje
calendarizado.
#Luis Miguel Castillo

Mamani
* Cul es la frase que cit

Tom Gilb?
+ Si no atacas de manera
activa los riesgos, ellos te
atacarn de manera activa.
- El hardware se hizo para
patearse.
+ Perder apoyo presupuestal

o de personal.
- Que los programadores
mueran en un accidente.
- Que un corte de luz borre
todo el avance.
- Grandeza.
- Pereza.
- Perseverancia.
- Codicia.

Software.
** Cules son los 5
problemas que identifican los
riesgos tcnicos?
+ Diseo.
+ Implementacin.
+ Interfaz.
+ Verificacin.
+ Mantenimiento.
#Pg. 641 - Estrategia

reactivas de riesgo frente a
estrategias proactivas de riesgo.
+ Perder el apoyo de los

administradores debido a un
cambio en el enfoque o en el
personal.
- Avaricia.
- Retroalimentacin.

Software.
** Los candidatos para los
cinco principales riesgos
empresariales son...
- El software libre es una

filosofa de vida.
+ Construir un producto o
sistema excelente que realmente
no se requiere.
- El riesgo se preocupa por

los acontecimientos futuros.
+ Construir un producto que

ya no encaje en la estrategia

Software.
* Cul es la frase que cit
Tom DeMarco y Tim Lister?
+ Los proyectos sin riesgos
reales son perdedores. Casi
siempre estn desprovistos de
beneficios; es por esto por lo
que no se hicieron aos atrs.
- Camarn 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 jams te dejar
ciego.
- La tecnologa es el reflejo
del fanatismo del hombre por
sobrevivir.
- Hoy en da por suerte, la
sociedad tiene una percepcin
esquizofrnica de la cienciatecnologa.
- Cada experiencia de la
vida es tapada por una cosa de la
tecnologa.
#Pg. 643 - Identificacin

de riesgo
** Cules son algunas de
subcategoras genricas respecto
a la identificacin de riesgos?
+ Tamao del producto.

+ Impacto empresarial.
+ Caractersticas de los
participantes.
+ Definicin del proceso.
+ Entorno de desarrollo.
+ Tecnologa para construir.
+ Tamao y experiencia
personal.
#7 Mtodo de Evaluacin
** El propsito del mtodo
de evaluacin de Procesos
EvalProSoft es otorgar a la
organizacin...
+ Un nivel de capacidad de
procesos implantados en la
organizacin
- Un nivel de cantidad de
procesos implantados en la
organizacin
* El nivel de madurez de
capacidades de una organizacin
corresponde...
- Al mnimo nivel de
capacidad alcanzado por todos
los procesos evaluados
+ Al mximo nivel de
- Al mnimo nivel de
los procesos pre-evaluados
#4 Arquitectura de Procesos
MoProSoft
+ Un nivel de madurez de
capacidades
- Al mximo nivel de
capacidad no alcanzado por
todos los procesos evaluados
** Formar parte de la
Arquitectura de Procesos
MoProSoft...
- Un nivel de capacidad de
proyectos implantados en la
organizacin
- Al mximo nivel de
cantidad alcanzado por todos los
procesos evaluados
+ Alta direccin: Gestin de

negocios
- Un nivel de inmadurez de
capacidades
- Alta direccin: Gestin de

ventas
- Un nivel de madurez de
cantidades
- Al nivel promedio de
+ Gerencia: Gestin de
procesos, gestin de proyectos y
gestin e recursos
- Un nivel de capacidad de
procesos
- Gerencia: Gestin de
procesos
+ Operacin: Admin. de
proyectos especficos,
Desarrollo y mantenimiento de
software.
- Operacin: Admin. de
proyectos y mantenimiento de
software.
- Alta direccin: Gestin de
Marketing
#5 Procesos MoProSoft
** Son procesos MoProSoft
+ Direccin
- Secretara
+ Coordinacin
instrumentacin
- Desarrollo Urbano
+ Ejecucin
- Devolucin
- Asesora
#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
- Al mximo nivel de
capacidad alcanzado por uno de
#13 La norma mexicana

** Sobre la norma mexicana
NMX-I-059
+ Norma para la Tecnologa
de la Informacin-SoftwareModelo de procesos y mtodos.
+ Es til para el desarrollo y
mantenimiento de software
+ Define conceptos y
productos
+ Contiene Requisitos de
procesos
+ Contiene Gua de
implantacin de procesos
+ Contiene el Mtodo de
evaluacin
+ Fue publicada en el diario
oficial en Agosto del 2005
# diap 16 - Gestin de
negocios
* Cul es el propsito de
una gestin de negocios?
+ Establecer la razn de ser

de la organizacin.
- No establecer una
organizacin
- Establecer los objetivos de
la organizacin
- proporcionar proveedores
de bienes, servicios e
infraestructura
# diap 30 - Proceso de
desarrollo y mantenimiento de
software
- Establecer la razn de ser

de la organizacin
** Es parte del flujo de

trabajo del proceso de desarrollo
y mantenimiento de software...
- Ganar dinero
- Establecer las condiciones

de la organizacin
- No tiene propsito
definido
- Establecer los resultados

de una organizacin
- Hacer que la empresa sea

reconocida
- Establecer los procesos de

la organizacin
- Identificar un plan
estratgico
** Son subprocesos del

proceso de gestin de recursos...
+ Recursos humanos y
ambiente de trabajo.
una gestin de procesos?
+ Bienes, servicios e
infraestructura.
+ Establecer los procesos de

la organizacin.
+ Conocimientos de la
organizacin.
- Agilizar un proceso
- Conseguir y dotar a la
organizacin de los recursos
humanos
- Proporcionar proveedores
de bienes, servicio e
infraestructura
- No existe un propsito
definido
- Hacer saber el tiempo de
vida de una empresa
proyectos
una gestin de proyectos?
+ Asegurar que los
proyectos contribuyan al
cumplimiento de los objetivos y
estrategias de la organizacin.
- Establecer los procesos de
la organizacin
+ Fases de un ciclo.
+ Actividades de una fase.
- Construccin
- Requerimientos
recursos
proceso
- Establecer la razn de ser

de la organizacin
+ Ciclos de desarrollo.
- No hay subprocesos
- Es un proceso compacto
- Desarrollo de un software
- Mantenimiento de un
software
- Inicio
- Anlisis
#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.
- Realimentacin.
- Mtodo gil.
- Requerimientos.
# diap 28 - Proceso de
administracin de proyectos
especficos
- Testeo.
** Es parte del flujo de

trabajo del proceso de
administracin de proyectos
especficos...
#31 - ciclos de Desarrollo

** Mencionar los elementos
del ciclo de Desarrollo
+ Inicio.
+ Necesidades cliente.
+ Planeacin.
+ Fases del Primer Ciclo.
+ Realizacin.
+ Fases del siguiente ciclo.
+ Evaluacin y control.
+ Nuevas necesidades.
+ Cierre.
- Desarrollador.
- Mantenimiento
- Cliente.
- Soporte
- Metodologia gil.
#32 - Fases de un ciclo
** Mencionar las fases de

un ciclo.
+ Inicio.
+ Requerimientos.
+ Anlisis y Diseo.
+ Construccin.
+ Integracin.
+ Proceso.
+ Categora.
+ Propsito.
+ Descripcin.
+ Objetivos.
+ Indicadores.
+ Metas Cuantitativas.
+ Pruebas.
+ Cierre.
#33 - Actividades de una

Fase
** Elementos de una
Actividad de Fase
+ Produccin
+ Correccin.
+ Verificacin.
+ Validacin.
+ Aceptacin.
+ Registro de Mediciones.
+ Incorporacin Bajo
Control.
#34 - Modelo de Procesos

para la Industria de Software
(Moprofost)
** Elementos de Patrn de
procesos.
+ Definicin General de
Proceso.
+ Prcticas.
+ Guas de Ajuste.
- Libro de Diseo.
#47 CMM
** Usos ms comunes del
modelo.
+ Autoevaluacin de
capacidad de procesos de
software.
+ Evaluacin de capacidad
de procesos de software.
- Desarrollo de nuevas
tecnologas.
- Correccin de errores de
hardware.
- Correccin de errores de
cdigo.
- Establecer mejoras de
procesos de codificacin.
- Seleccin de hardware
para proyectos.
#48 Organizaciones de
software maduras e inmaduras
** Las organizaciones
inmaduras generalmente...
+ Improvisan procesos
durante un proyecto.
- Metodologa.
+ Exceden calendarios.
** Estructura del patrn de

Procesos.
+ Poseen habilidad
organizacional.
+ Trabajan con base en un
plan.
+ Monitorean la calidad de
los productos.
+ Basan su calendario y
presupuesto en datos histricos
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
+ Definido
+ Administrado
+ Optimizado
- Planeado
- Dominado
+ Son reactivas, resolviendo

crisis inmediatas.
+ Exceden presupuestos.
#35 - Definicin general de

proceso.
** Las organizaciones
maduras generalmente...
+ Repetible
- Inicio.
- Evento.
#49 Organizaciones de
software maduras e inmaduras
+ No cuentan con bases

objetivas.
+ Comprometen calidad y
funcionalidad.
+ No saben evaluar la
calidad del producto generado.
#52 Procesos clave por nivel

de madurez
** Mencione los procesos
clave del nivel 3 de CMM
+ Revisiones internas.
+ Coordinacin intergrupal.
+ Ingeniera de productos de
sistemas.
+ Administracin integrada
de sistemas.
+ Programa integral de
desarrollo profesional.
+ Definicin de procesos de
la organizacin.
+ Enfoques a procesos de la
organizacin.
#53 Caractersticas de
procesos por nivel
** Cules son las

relaciones correctas entre el
nivel de CMM y su
caracterstica principal?
+ 1 inicial (Los procesos son
informales y AD-HOC).
+ 2 repetible (Las prcticas
administrativas de proyectos se
institucionalizan).
+ 3 definido (Las prcticas
tcnicas se integran con las
prcticas 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
prcticas para evitar errores).

Preguntas

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Preguntas

Uploaded by

Copyright:

Available Formats

# Pg.

presente definicin pertenece

- Diseo de alto nivel

# Pg. 66 -El debate XP.

# Pg. 68 -Otros modelos

+ Estudio del negocio.

# Pg. 69-70 Scrum.

#pg. 84 Principios que

#pg. 84 Principios que

+ Entender el alcance del

+ Llevar a cabo pruebas

+ Se sugiere una agenda con

# Pg. 111 - Comprensin

- Se sugiere una agenda

# Pg. 113 - Comprensin

# Pg. 118 - Comprensin

+ Un enunciado acotado del

+ Una lista de clientes,

- Elementos basados en los

+ Una descripcin del

+ Elementos basados en las

# Pg. 114 - Comprensin

- Identificar los defectos del

# Pg. 122 - Comprensin

+ Tiene atribucin cada

# Pg. 121 - Comprensin

** Segn Boehm [Boe98],

+ Una vez implementado

** Coad y Yourdon sugieren

+ Las tarjetas se dividen en

** Cules son las tres

+ Estas tarjetas indican el

+ Operaciones que vigilan

+ Cada responsabilidad debe

+ Proporciona una manera

+ Los escenarios de casos de

+ Cuando sea apropiado, las

+ Se da lectura a los casos

- Las clases debern

** Si bien los modelos

** Afirmaciones acerca del

+ Dos clases de anlisis se

+ Una asociacin puede

+ Grado en el que los

#Pg.175 - Salida del

* Creador de Lotus 1-2-3,

#Pg.176 - Salida del

# Pg. 184 Tema: Diseo en

- un diseo completo de las

# Pg. 185 Tema: Diseo en

# Pg. 184 Tema: Conceptos

# Pg. 187-188 Tema:

# Pg. 194 Tema: Aspectos

+ La evolucin del modelo

#Marco Carrillo Colque

#196 CLASES DE DISEO

#203 ELEMENTOS DEL

#Pg. 207 Arquitectura de

- Son las licencias que nos

#Pg. 207 Arquitectura del

trabajo de ingeniera de software

#Pg. 209 Descripciones

#Pg. 208 Arquitectura de

** Razones clave por las