Cuestionario Capitulo 1

PROBLEMAS Y PUNTOS POR EVALUAR

1.1. Dé al menos cinco ejemplos de la forma en que se aplica la ley de las
consecuencias imprevistas al software de cómputo.

 Que el software seria la fuerza que impulsaría la revolución de las

computadoras personales.
 Que los productos de software empacados se comprarían en los
supermercados.
 Que el software evolucionaria poco a poco de un producto a un servicio cuando
compañías de software proporcionarían funcionalidad justo a tiempo a través
de un navegador web.
 Que una compañía de software sería más grande y tendría más influencia que
casi todas las empresas de la industria.
 Que una vasta red llamada internet seria operada con software y evolucionaria
y cambiaria todo.

1.2. Diga algunos ejemplos (tanto positivos como negativos) que indiquen el efecto
del software en nuestra sociedad.

Aspectos Positivos:

• Poder acceder a la información desde cualquier parte (gracias a la internet).

• El software distribuye el producto más importante de nuestros tiempos, la

información, administra la información de negocios para mejorar la competitividad.

Aspectos Negativos:

• Adicción a producto de software de entretenimiento.

• Los productos quedan obsoleto más rápidamente.

• Trafico de información.

• La red oculta (deepweb)

1.3. Desarrolle sus propias respuestas a las cinco preguntas planteadas al principio
de la sección 1.1. Analícelas con sus compañeros estudiantes.

¿Por qué se requiere de tanto tiempo para terminar un software?

Porque para desarrollar un software de calidad se deben realizar una serie de pasos
antes de entrar al desarrollo del sistema en sí, se debe tomar en cuenta todos los
requerimientos propuestos y una serie de factores que hace que proceso de desarrollo
se demore.

¿Por qué son tan altos lo costos de desarrollo?

Porque en el ciclo de desarrollo de un software interviene un equipo de varias

personas con un rol especifico a los cuales se les tiene que pagar, y que el proceso de
desarrollo de un sistema puede durar mucho tiempo.

¿Por qué no podemos detectar todos los errores antes de entregar el software a
nuestros clientes?

Mientras el programador crea el software, el tratara de corregir los errores que pueda
o que estén a su alcance, pero al final por mucho que se esfuerce el programador,
siempre después de entregar el software habrán errores o detalles que solucionar,
esta razón u otra es de ahí que existen las versiones siguientes de dicho software.

¿Porque dedicamos tanto tiempo y esfuerzo a mantener los programa existentes?

¿El software está muerto? No, no lo está. El software con el tiempo se deteriora y se
vuelve obsoleto por esta u otras razones tenemos que mantener los programas
existentes y también porque el usuario se hace cómodo al usar el sistema ya que el
sistema satisface las necesidades que el posee, aparente que esto le generaría costos y
riesgos.

¿Por qué seguimos con dificultades para medir el avance mientras se desarrolla y
mantiene el software?

El desarrollador mantiene un cierto tiempo, se prolonga a un tiempo para finalizar el

proyecto, pero la etapa de ejecución le genera errores, los cuales le impide terminar el
proyecto de software a tiempo, toda esta serie de atrasos hace que el programador
pierda la noción del tiempo.

1.4. Muchas aplicaciones modernas cambian con frecuencia, antes de que se

presenten al usuario final y después de que la primera versión ha entrado en
uso. Sugiera algunos modos de elaborar software para detener el deterioro que
produce el cambio.

• Debe diseñarse e implementarse de modo que pueda volverse a usar en muchos

programas diferentes.

• El ingeniero de software modo que pueda volverse a usar en muchos programas

diferentes.
• El ingeniero de software debe tratar de que los cambios que se hagan no vayan a ser
demasiado bruscos, para así evitar

1.5. Considere las siete categorías de software presentadas en la sección 1.1.2.

¿Piensa que puede aplicarse a cada una el mismo enfoque de ingeniería de
software? Explique su respuesta.

1) Software de sistemas. - es un conjunto de programas para dar servicio a otros

programas (editores, herramientas).

2) Software de aplicación. - se vuelve en una necesidad específica de negocios. Se

realizan de manera comercial o técnica.

3) Software de ingeniería de sistema y ciencias. - se caracteriza por algoritmos.

4) Software incrustado. - reside dentro de un sistema para implementar controles,

características y funciones para el usuario final.

5) Software de ingeniería de productos. - es diseñado para proporcionar el uso de

consumidores diferentes en algún mercado (inventario).

1.6. La figura 1.3 muestra las tres capas de la ingeniería de software arriba de otra
llamada “compromiso con la calidad”. Esto implica un programa de calidad
organizacional como el enfoque de la administración total de la calidad. Haga
un poco de investigación y desarrolle los lineamientos de los elementos clave
de un programa para la administración de la calidad.

El proceso define una estructura que debe establecerse para la obtención eficaz de
tecnología de ingeniería de software. El proceso de software forma la base para el
control de la administración de proyectos de software, y establecer el contexto en el
que se aplican métodos técnicos, se generan producto del trabajo (modelos,
documentos, datos, reportes, formatos, etc.), se establecen puntos de referencias, sea
sea segura la calidad y se administra el cambio de manera apropiada.

1.7. ¿Es aplicable la ingeniería de software cuando se elaboran webapps? Si es así,

¿cómo puede modificarse para que asimile las características únicas de éstas?

Si, estas han evolucionado de simples conjuntos de contenido de información a

sistemas sofisticados que presentan una funcionalidad compleja y contenido en
multimedios. Y aunque la gran mayoría tienen características únicas, son consideradas
software.

Los atributos que presentan son los siguientes:

-Uso intensivo de redes

-Concurrencia

-Carga impredecible

-Rendimiento

-Disponibilidad

-Orientadas a los datos

-Contenido sensible

-Evolución continúa

-Seguridad

1.8. A medida que el software gana ubicuidad, los riesgos para el público (debidos a
programas defectuosos) se convierten en motivo de preocupación significativa.
Desarrolle un escenario catastrófico pero realista en el que la falla de un programa
de cómputo pudiera ocasionar un gran daño (económico o humano).

Los barcos poseen radares, los cuales permiten detectar objetos estáticos o móviles
dentro de un rango en específico, imaginemos que en un gran barco turístico hay un
problema, y es que el software del radar tiene un pequeño error de fórmula, parece
ser simple, pero esto podría causar que el barco choque, lo que causaría grandes
pérdidas económicas y podría causar la pérdida de muchas vidas.

1.9. Describa con sus propias palabras una estructura de proceso. Cuando se dice que
las actividades estructurales son aplicables a todos los proyectos, ¿significa que se
realizan las mismas tareas en todos los proyectos sin que importe su tamaño y
complejidad? Explique su respuesta.

Una estructura de proceso es lo que sería un mapa de cómo va a estar estructurado un

proyecto paso por paso para poder guiarnos de cómo trabajar para que todo salga
bien.

Esto no significa que se hagan las mismas tareas en todos los proyectos. La razón por la
que no se siguen los mismos pasos es simple ya que no todos los proyectos son
iguales. No es lo mismo y proyecto de un arquitecto que el proyecto de un diseñador
de moda.

Los pasos que estos deben seguir son totalmente diferentes y deben seguir una serie
de pasos exclusivos o precisos para que sus trabajos salgan con el margen de
perfección más acertado posible.
1.10. Las actividades sombrilla ocurren a través de todo el proceso del software.
¿Piensa usted que son aplicables por igual a través del proceso, o que algunas se
concentran en una o más actividades estructurales?

Son aplicables a través de todo el proceso del software. Una estructura de proceso
general para la ingeniería de software consta de cinco actividades:

• Comunicación

• Planeación

• Modelado

• Construcción

• Despliegue

Estas actividades estructurales genéricas, se usan durante el desarrollo de programas

pequeños y sencillos, en la creación de aplicaciones web grandes y en la ingeniería de
sistemas enormes y complejos basados en computadoras

1.11. Agregue dos mitos adicionales a la lista presentada en la sección 1.6. También
diga la realidad que acompaña al mito.

Mito.- “Los cambios dentro de un software son fáciles y sencillos”.

Realidad.- Es cierto que los requerimientos de un software cambian constantemente,

pero el impacto varía según el momento en el que se presenten las modificaciones.

Mito: No soy bueno en planificar. Es una tarea administrativa que la debe hacer un
administrador.

Realidad: La planificación es una competencia clave para todos los ingenieros de

software. “La planificación es un proceso natural. Es mucho más divertido hacer algo
planificado. Y lo bueno de no planificar, es que el fracaso viene como una total
sorpresa, que suele estar precedida por un período de preocupación y depresión”.
Cuestionario capítulo 2
PROBLEMAS Y PUNTOS POR EVALUAR

2.1. En la introducción de este capítulo, Baetjer afirma que: “El proceso genera
interacción entre usuarios y diseñadores, entre usuarios y herramientas cambiantes
[tecnología].” Enliste cinco preguntas que a) los diseñadores deben responder a los
usuarios, b) los usuarios deben plantear a los diseñadores, c) los usuarios deben
hacerse a sí mismos sobre el producto de software que ha de elaborarse, d) los
diseñadores deben plantearse acerca del producto de software que va a construirse y
del proceso que se usará para ello.

a) los diseñadores deben responder a los usuarios

¿Qué haría el software?

¿Cómo estaría protegido el software?

¿Cuánto costara el software?

¿Cuánto tardara en estar listo el software?

¿Cuáles son los principales beneficios que el software me brinda?

b) los usuarios deben plantear a los diseñadores

¿Cuánto tiempo durara el software?

¿Cómo se hará el mantenimiento y cada cuánto?

¿Cómo será su funcionabilidad?

¿Me podrían ir mostrando el proceso que lleva el software?

c) los usuarios deben hacerse a sí mismos sobre el producto de software que ha de

elaborarse

¿Estoy dando toda la información necesaria para la creación del software?

¿El diseñador me estará comprendiendo bien mis necesidades?

d) los diseñadores deben plantearse acerca del producto de software que va a

construirse y del proceso que se usará para ello

¿El cliente me dijo todo lo que necesito saber?

¿Qué tipo de modelo debería usar?

¿Puede que cambien los requerimientos con el pasar del tiempo?

¿Qué tipo de capacitación debería recibir el cliente?

¿El software será compatible con el sistema operativo que usan?

2.2. Trate de desarrollar un conjunto de acciones para la actividad de comunicación.

Seleccione una acción y defina un conjunto de tareas para ella.

El conjunto de acciones preparadas de antemano para lograr objetivos específicos.

Preguntas claves para un plan de comunicación:

Qué queremos conseguir,

Cuáles son nuestros objetivos y las ideas?

Cuál es el mensaje que queremos transmitir?

A quiénes vamos a dirigir nuestra comunicación?

Qué queremos que hagan con la información?

Cuáles son los medios apropiados que va a utilizar para dicha comunicación?

Cómo vamos a ejecutar el plan?

2.3. Un problema común durante la comunicación ocurre cuando se encuentra a dos

participantes que tienen ideas en conflicto sobre lo que debe ser el software, es
decir, que tienen requerimientos mutuamente conflictivos. Desarrolle un patrón del
proceso (esto sería un patrón de la etapa) con el empleo de la plantilla presentada en
la sección 2.1.3 que aborda este problema y sugiera un enfoque eficaz para él.

Patrón de etapas:

Especificación de software: Se debe definir la funcionalidad y restricciones

operacionales que debe cumplir el software.

Patrón de tarea:

Diseño e Implementación: Se diseña y construye el software de acuerdo a la

especificación.

Patrón de fase:

Validación: El software debe validarse, para asegurar que cumpla con lo que quiere el
cliente.

Evolución: El software debe evolucionar, para adaptarse a las necesidades del cliente.
Además de estas actividades fundamentales, Pressman menciona un conjunto de
“actividades protectoras”, que se aplican a lo largo de todo el proceso del software.
Ellas se señalan a continuación:

 Seguimiento y control de proyecto de software.

 Revisiones técnicas formales.
 Garantía de calidad del software.
 Gestión de configuración del software.
 Preparación y producción de documentos.
 Gestión de reutilización.
 Mediciones.

2.4. Investigue un poco sobre el PPS y haga una breve presentación que describa los
tipos de mediciones que se pide hacer a un ingeniero individual de software y la
forma en la que pueden usarse para mejorar la eficacia personal.

Los PPS permiten que el equipo planee, diseñe y construya software en forma
disciplinada, al mismo tiempo que mide cuantitativamente el proceso y el producto.

La etapa post mórtem es el escenario de las mejoras del proceso.

2.5. El uso de scripts (mecanismo requerido en el PES) no es apreciado de manera

universal en la comunidad del software. Haga una lista de pros y contras en relación
con los scripts y sugiera al menos dos situaciones en las que serían útiles, y otras dos
en las que generarían menos beneficios.

 Ventajas
 Define estándares aplicables.
 Controla la programación de actividades del proyecto.
 Utilidad

2.6. Lea a [Nog00] y escriba un ensayo de dos o tres páginas donde analice el efecto
que tiene el “caos” en la ingeniería de software.

2.7. Dé tres ejemplos de proyectos de software que podrían efectuarse con el

modelo de cascada. Sea específico.

 Proyecto de control e consultas médicas (creación de turnos y fichas del

paciente).
 Proyecto de control inventarios (registro de entradas y salidas de mercadería).
  Proyecto de control de personal (registro de entrada y salida)

2.8. Proporcione tres ejemplos de proyectos de software que podrían abordarse con
el modelo de hacer prototipos. Sea específico.

 Aplicaciones que involucren interacción humano/maquina o uso extensivo de

graficas por computadoras
 Aplicaciones de algoritmos matemáticos
 Sistemas en los que los resultados pueden ser examinados fácilmente sin
interacción en tiempo real Software de Simulación caja registradora de un
supermercado.

2.9. ¿Qué adaptaciones del proceso se requerirían si el proyecto evolucionara en un

sistema o producto que se entregase?

Que el software se adapte a nuevos cambios, los requisitos son inevitables, no sólo
después de entregado en producto sino también durante el proceso de desarrollo.

2.10. Diga tres ejemplos de proyectos de software que podrían realizarse con el
modelo incremental. Sea específico.

 Un sistema operativo
 Sistema de control de satélites
 Diseño de un cajero automático simple.

2.11. Conforme avanza hacia fuera por el flujo de proceso en espiral, ¿qué puede
decirse sobre el software que se está desarrollando o que está en mantenimiento?

Se puede decir que en este modelo el software debe enfocarse en la evolución real a
que puede someterse de manera constante y que se evaluaran los riesgos que podrían
llegar a tener si no hace un trabajo con existo.

2.12. ¿Es posible combinar modelos de proceso? Si es así, diga un ejemplo.

Si es posible, el modelo de espiral es un buen ejemplo porque lleva la secuencia del

modelo de cascada, al finalizar el ciclo hay un prototipo y luego empieza nuevamente
haciendo un bucle hasta obtener el software con todos los requerimientos deseados
por el cliente.

2.13. El modelo de proceso concurrente define un conjunto de “estados”. Describa

con sus propias palabras qué es lo que representan, y después indique cómo entran
en juego dentro del modelo de proceso concurrente.

Es la representación de un estado que puede cambiar de procedimiento y volver a

generar un estado si es que el cliente requiere de un cambio al software de tal manera
que puede generar un mismo estado n veces necesarias al requerimiento del cliente. El
modelado concurrente proporciona un panorama apropiado del estado actual del
proyecto. Cada actividad, acción o tarea de la red existe simultáneamente con otras
actividades, acciones o tareas.

2.14. ¿Cuáles son las ventajas y desventajas de desarrollar software en el que la calidad
no es “suficientemente buena”? Es decir, ¿qué pasa cuando se pone el énfasis en la
velocidad de desarrollo sobre la calidad del producto?

Ventajas:

 Se diseña específicamente para las necesidades que se tienen.

 Se puede cambiar y modificar con el tiempo.

Desventajas:

 Puede que el software este lleno de errores y es poco fiable.

 No tienen una presentación y dependen de los desarrolladores.

2.15. Dé tres ejemplos de proyectos de software que serían abordables con el modelo
basado en componentes. Sea específico.

2.16. ¿Es posible demostrar que un componente de software, o incluso un programa

completo, es correcto? Entonces, ¿por qué no todos lo hacen?

Porque no todos utilizan la misma metodología de hacer prototipos.

2.17. ¿Son lo mismo el proceso unificado y el UML? Explique su respuesta.

No, porque uml es un lenguaje que se utiliza para modelar un sistema. Y
RUP es una metodología tradicional pesada que me indica unos pasos a
seguir para desarrollar mi sistema.

Cuestionario capítulo 3
PROBLEMAS Y PUNTOS POR EVALUAR
3.1. Vuelva a leer el “Manifiesto para el desarrollo ágil de software” al principio de
este capítulo. ¿Puede pensar en una situación en la que uno o más de los cuatro
“valores” pudieran causar problemas al equipo de software?

Al saber que las condiciones del mercado cambian con rapidez, las necesidades de los
usuarios finales cambian, se generaría un ambiente con problemas iniciando por no
definir bien los requerimientos y para esto se debería ser ágil y responder a esto, pues
de lo contrario estaríamos con un equipo sin control.

3.2. Describa con sus propias palabras la agilidad (para proyectos de software).

Es una habilidad para adaptarse a diferentes cambios y en diferentes tiempos en el

proceso de desarrollo de software sin afectar este.

3.3. ¿Por qué un proceso iterativo hace más fácil administrar el cambio? ¿Es iterativo
todo proceso ágil analizado en este capítulo? ¿Es posible terminar un proyecto en
sólo una iteración y aun así conseguir que sea ágil? Explique sus respuestas.

Porque a comparación de otros modelos de procesos tradicionales este tipo iterativo

no nos causara demoras al tener una falla y retornar al inicio del proyecto sino que
como es iterativo se retornara a verificar una iteración antes.

¿Es iterativo todo proceso agilizado en este capítulo?

El capítulo trata de procesos ágiles por consiguiente estos tipos de procesos si son
iterativos e incrementales.

¿Es posible terminar un proyecto en solo una iteración y aun así conseguir que sea
ágil?
Dependiendo de las condicionantes y los requerimientos del proyecto si pero
teóricamente estos procesos como Scrum es de un mes natural o hasta de 2 semanas
si es necesario.

3.4. ¿Podría describirse cada uno de los procesos ágiles con el uso de las actividades
estructurales generales mencionadas en el capítulo 2? Construya una tabla que mapee
las actividades generales en las actividades definidas para cada proceso ágil.

3.5. Proponga un “principio de agilidad” más que ayudaría al equipo de ingeniería de

software a ser aún más maniobrable.

Generar la importancia del cliente para su software presentando iteraciones las cuales
pueda evaluar y examinar a su gusto.

3.6. Seleccione un principio de agilidad mencionado en la sección 3.3.1 y trate de

determinar si está incluido en cada uno de los modelos de proceso presentados en
este capítulo. [Nota: sólo se presentó el panorama general de estos modelos de
proceso, por lo que tal vez no fuera posible determinar si un principio está incluido
en uno o más de ellos, a menos que el lector hiciera una investigación (lo que no se
requiere para este problema)].

La prioridad más alta es satisfacer al cliente atreves de la entrega pronta y continua de

software valioso.

Este principio si está presente en estos modelos de procesos pues necesariamente

tenemos que entregar avances de software que funcione y de igual manera su pronta
entrega.

3.7. ¿Por qué cambian tanto los requerimientos? Después de todo, ¿la gente no sabe
lo que quiere?

El software se caracteriza por su adaptabilidad en el tiempo sin embargo podría no

satisfacer al propietario es así que se generan nuevos requerimientos por el cambio y
crecimiento de la empresa, como también si se estaría desarrollando por primera vez
en una empresa los requerimientos cambiarían por la mala comunicación con los
clientes o también por la mala coordinación y dinámica del grupo de trabajo del
proyecto llegando a no entender lo que se quiere.
3.8. La mayoría de modelos de proceso ágil recomiendan la comunicación cara a
cara. No obstante, los miembros del equipo de software y sus clientes tal vez estén
alejados geográficamente. ¿Piensa usted que esto implica que debe evitarse la
separación geográfica? ¿Se le ocurren formas de resolver este problema?

Pienso que como personas vinculadas a la tecnología esto no debería ser un

impedimento sin embargo quisiera poner el ejemplo del sistema integrado de la
universidad andina del cusco el cual tuvo problemas justo en este aspecto, llegando a
una conclusión que si es necesario recopilar información para obtener los
requerimientos exactos utilizar las nuevas formas de comunicación que existen como
Facebook, twittter, skype, Email, Video llamadas, mensajes de texto, etc.

3.9. Escriba una historia de usuario XP que describa la característica de “lugares

favoritos” o “marcadores” disponible en la mayoría de navegadores web.

Historia de Usuario

Numero: 1 Nombre: característica de “lugares favoritos” o

“marcadores” disponibles en la mayoría de

Navegadores web.

Usuario: Administrador

Modificación de historia numero: Iteración Asignada:

Prioridad de negocio: Baja Puntos Estimados:

Riesgo de Desarrollo: Medio Puntos Reales:

Descripción: Los navegadores que tenemos en la actualidad nos ofrecen varias

funciones como la de almacenar las direcciones o unos de los sitios, así de esta forma
nos brinda la posibilidad de marcar favoritos e ingresar de esta manera
inmediatamente a tus sitios favoritos.

Observaciones

3.10. ¿Qué es una solución en punta en XP?

Es una creación inmediata de un prototipo operativo de la porción encontrada en el

proceso de diseño al inicio de la implementación.
3.11. Describa con sus propias palabras los conceptos de rediseño y programación en
parejas de XP.

Es una manera de cambiar el software pero que no altere la parte externa sino nada
más el interior del software, en otras palabras que tenga la misma interfaz y que se
modifique y mejore el código del software.

Es lógico que dos personas piensen más que uno, este proceso es conocido por ello
trabajar código y a la vez revisarlo o centrarse en el problema y el otro en el diseño
luego así integrarlo al trabajo de los demás grupos.

3.12. Haga otras lecturas y describa lo que es una caja de tiempo. ¿Cómo ayuda a un
equipo DAS para que entregue incrementos de software en un corto periodo?

Una caja de tiempo nos ayudara a guardar información del presente en la parte de
recolección de información y aprendizaje respetando así el tiempo que se asignó a
dichas tareas.

Ayudando así en problemas futuros a no volver a recolectar y aprender información

sino continuar con estos antecedentes.

3.13. ¿Se logra el mismo resultado con la regla de 80% del MDSD y con el enfoque de
la caja de tiempo del DAS?

La regla del 80% es eficaz en cuanto a tiempo y la caja de tiempo del DAS también es
por ello que concluyo que si se logra el mismo resultado pues estos son adaptables.

3.14. Con el formato de patrón de proceso presentado en el capítulo 2, desarrolle

uno para cualquiera de los patrones Scrum presentados en la sección 3.5.2.

Nombre del patrón: sprint

Fuerzas: lugar donde aremos las tareas del trabajo

Tipo:

· Patrón de Etapa:

Adaptación y modificación del problema

· Patrón de Tarea:

Definir los requerimientos.

· Patrón de Fase:

Modelos del trabajo.

Contexto Inicial: Planeación y comunicación de la tarea.

Problema: ocurrencias estructurales de las tareas

Solución: adaptar los problemas y modificarlos.

Contexto Resultante: será eficaz en proyectos de plazos de entrega muy apretados

Patrones Relacionados:

3.15. ¿Por qué se le llama a Cristal familia de métodos ágiles?

Es una forma de compartir recursos limitados y comunicación con un objetivo único el

cual es estregar software que funcione, siendo esta familia efectiva para diferentes
tipos de proyectos.

3.16. Con el formato de característica DIC descrito en la sección 3.5.5, defina un

conjunto de características para un navegador web. Luego desarrolle un conjunto de
características para el primer conjunto.

<Acción> el <resultado> <a|por|de|para> un <objeto>

Navegador Web:

· Mejora la velocidad de otros navegadores.

· Actualiza su versión para ser más óptimo.

· Tiene vistas interactivas a diferencia de otros.

3.17. Visite el sitio oficial de modelación ágil y elabore la lista completa de todos los
principios fundamentales y secundarios del MA.

Principios fundamentales:

· Suponer simplicidad

· Aceptar el cambio

· Cambio Incremental
· Modelo con un propósito

· Modelos Múltiples

· Trabajo de Calidad

· Retroalimentación rápida

· Trabajo Software es su objetivo principal

Principios secundarios:

· Comunicación abierta y honesta

· El Contenido es más importante que la representación

3.18. El conjunto de herramientas propuestas en la sección 3.6 da apoyo a muchos

de los aspectos “suaves” de los métodos ágiles. Debido a que la comunicación es tan
importante, recomiende un conjunto de herramientas reales que podría utilizarse
para que los participantes de un equipo ágil se comuniquen mejor.

· Usar herramientas adecuadas para la comunicación.

· Usar la interactividad al momento de explicar y/o exponer los problemas o

soluciones planteadas por los equipos de trabajo.

Conocer o tener un glosario específico para el trabajo desarrollado

Cuestionario capítulo 4
PROBLEMAS Y PUNTOS POR EVALUAR

4.1. Toda vez que la búsqueda de la calidad reclama recursos y tiempo, ¿es posible
ser ágil y centrarse en ella?

Si desde luego porque nos proponemos realizar un énfasis en el mismo de tal forma
que gobernamos este enfoque.
4.2. De los ocho principios fundamentales que guían el proceso (lo que se estudió en
la sección 4.2.1), ¿cuál cree que sea el más importante?

Formar un equipo eficaz

4.3. Describa con sus propias palabras el concepto de separación de entidades.

Es la resolución de un problema mediante un proceso para llegar a la solución.

4.4. Un principio de comunicación importante establece que hay que “prepararse

antes de comunicarse”. ¿Cómo debe manifestarse esta preparación en los primeros
trabajos que se hacen? ¿Qué productos del trabajo son resultado de la preparación
temprana?

Se debe de comprender el trabajo el cual estamos realizando y para esto es necesario

la investigación y documentación.

4.5. Haga algunas investigaciones acerca de cómo “facilitar” la actividad de

comunicación (use las referencias que se dan u otras distintas) y prepare algunos
lineamientos que se centren en la facilitación.

Definir los objetivos de forma clara y concisa, con el fin de llegar a cumplir los
propósitos del software.

4.6. ¿En qué difiere la comunicación ágil de la comunicación tradicional de la

ingeniería de software? ¿En qué se parecen?

La comunicación tradicional se diferencia de la comunicación ágil en que esta da un

mayor grado de valor al cliente.

4.7. ¿Por qué es necesario “avanzar”?

Para poder adaptarse a la competencia, y así poder brindar un mejor servicio.

4.8. Investigue sobre la “negociación” para la actividad de comunicación y prepare

algunos lineamientos que se centren sólo en ella.
El proceso negociador es ante todo un proceso comunicativo. Si cada parte no puede
manifestar sus deseos y necesidades de un modo adecuado y eficaz, le será poco
menos que imposible alcanzar algún objetivo. Una comunicación eficaz resulta esencial
para cuidar y mantener el proceso de negociación.

4.9. Describa lo que significa granularidad en el contexto de la programación de

actividades de un proyecto.

Es en cuanto al progreso que se necesita en el detalle del sistema.

4.10. ¿Por qué son importantes los modelos en el trabajo de ingeniería de software?
¿Siempre son necesarios? ¿Hay calificadores para la respuesta que se dio sobre esta
necesidad?

Estos vienen a ser de sebera importancia porque en cada uno de los niveles se necesita
un modelo diferente para su desarrollo.

4.11. ¿Cuáles son los tres “dominios” considerados durante el modelado de

requerimientos?

Las excepciones en un caso de uso serian condiciones en las cuales los actores tanto
principales como secundarios pueden encontrarse a lo largo de la ejecución del
sistema. Las excepciones son una descripción de lo que está sucediendo, como actuar,
que esperar, etc.

4.12. Trate de agregar un principio adicional a los que se mencionan en la sección

4.3.4 para la codificación.

El desarrollo de software es algo que lleva ya varias décadas durante ese tiempo
personas se han fijado que, aunque cada proyecto de software es único estos tienen
cierta semejanza en ciertos aspectos, entonces crearon como si fuera una plantilla
para poder solucionar proyectos de software que tengan ciertas similitudes entre sí,
estas plantillas son llamados patrones de análisis
4.13. ¿Qué es una prueba exitosa?

Es el muestreo de la información de calidad del sistema.

4.14. Diga si está de acuerdo o en desacuerdo con el enunciado siguiente: “Como

entregamos incrementos múltiples al cliente, no debiéramos preocuparnos por la
calidad en los primeros incrementos; en las iteraciones posteriores podemos corregir
los problemas. Explique su respuesta.

4.15. ¿Por qué es importante la retroalimentación para el equipo de software?

Esto es algo más social como la interacción entre los equipos del proyecto.

Cuestionario capítulo 5
PROBLEMAS Y PUNTOS POR EVALUAR
5.1. ¿Por qué muchos desarrolladores de software no ponen atención suficiente a la
ingeniería de requerimientos? ¿Existen algunas circunstancias que puedan ignorarse?

Existen muchas razones para que los desarrolladores tomen esta decisión que casi
siempre se debe a que los requisitos son dinámicos, entonces al menos que se utilice
un enfoque eficiente y ágil que haga al equipo versátil en esta tarea.

Otra, puede ser que es una actividad que requiere de un alto grado de análisis, lo que
demanda tiempo, es preferible solo tomar los requisitos que afectaran directamente al
negocio y avanzar en las próximas iteraciones.

También se piensa que retrasa la etapa más divertida que es el modelado y la

codificación del proceso de software, pero se sabe que es fundamental.

5.2. El lector tiene la responsabilidad de indagar los requerimientos de un cliente que

dice estar demasiado ocupado para tener una reunión. ¿Qué debe hacer?

 Debe prepararse con la información pertinente del negocio

 Tratar de solicitar una persona auxiliar que conozca el negocio, su
funcionamiento, y tenga una idea más técnica de las necesidades del cliente,
como un Product Owner
 Procurar de tener una visión del proyecto que satisfaga dichos requisitos
5.3. Analice algunos de los problemas que ocurren cuando los requerimientos deben
indagarse para tres o cuatro clientes distintos.

Muchos de los problemas que nos enfrentaremos como Ingenieros de software es la

indagación de requisitos conflictivos.

Estos problemas se dan en primera por la oposición o “conflicto” de algunos

participantes del negocio. Si bien esto puede parecer un problema en primera,
también brinda sutilmente una riqueza “visual” al proyecto, por la accesibilidad de
varios puntos de vistas. Ahora, lo ideal para tal situación es hacer una
retroalimentación con el grupo conflictivo e implementar la negociación de requisitos,
y obtener la mejor estrategia para el proyecto.

5.4. ¿Por qué se dice que el modelo de requerimientos representa una fotografía
instantánea del sistema en el tiempo?

Considero, que constituye una visión de lo que será el proyecto ya que se identifican
las ideas, y se concibe el software de manera rápida, para suponer lo que yacerá a
largo plazo el proyecto.

5.5. Suponga que ha convencido al cliente (es usted muy buen vendedor) para que
esté de acuerdo con todas las demandas que usted hace como desarrollador. ¿Eso lo
convierte en un gran negociador? ¿Por qué?

La verdad, es relativo. Si en esa situación el cliente también se dispone convencido y

acepta con entusiasmo, además de que siente que gana, durante dicha tarea; entonces
se puede decir que soy un gran negociador.

Mas sin embargo, si el cliente quedo en dudas o se siente desplazado de la

negociación, entonces estaré siendo egoísta, y no cumpliría con uno de los principios
del manifiesto ágil, por tanto sería un pésimo negociador.

5.6. Desarrolle al menos tres “preguntas libres de contexto” adicionales que podría
plantear a un participante durante la concepción.

 ¿Por qué nace la idea de hacer e implementar un proyecto de software en la

empresa?
 ¿Qué espera(n) usted(s) del proyecto a desarrollar?
 ¿Cómo cree que afectará el software al negocio?
5.7. Desarrolle un “kit” para recabar requerimientos. Debe incluir un conjunto de
lineamientos a fin de llevar a cabo la reunión para recabar requerimientos y los
materiales que pueden emplearse para facilitar la creación de listas y otros objetos
que ayuden a definir los requerimientos.

Especificación de JRC2 Kit:

Lineamientos:

 Simpleza y puntualidad: Antes que todo, se debe representar una buena

imagen laboral ante el cliente, es fundamental la puntualidad a la hora de llegar
a citas de intercambio de información.

Indagación del Negocio a través de la preparación:

 Es preferible saber de forma razonable, conceptos y términos del negocio, ya

que facilita mucho la comunicación.
 Apoyarse en el uso de las TIC: La obtención tradicional de los requisitos, se
podía plasmar en lápiz y papel, pero eso ha cambiado; como actualizados que
somos, debemos hacer uso de herramientas que mejoren y optimicen dicha
actividad a través de las TICS.
 Disponibilidad de facilitadores: Un facilitador evita la tensión entre los
participantes, y sirve de interfaz para el flujo de información entre el cliente y el
equipo.

Herramientas:

 Si se prefiere el uso del lápiz y papel, se puede, aunque se debe pensar en TIC
en un futuro.
 Tablero y video vean para presentar lógicas del negocio por parte del cliente.
 Cámara de video y fotográfica.

5.8. Su profesor formará grupos de cuatro a seis estudiantes. La mitad de ellos

desempeñará el papel del departamento de mercadotecnia y la otra mitad adoptará
el del equipo para la ingeniería de software. Su trabajo es definir los requerimientos
para la función de seguridad de Casa Segura descrita en este capítulo. Efectúe una
reunión para recabar los requerimientos con el uso de los lineamientos presentados
en este capítulo.

a) Hacer un retiro de efectivo en un cajero automático

5.9. Desarrolle un caso de uso completo para una de las actividades siguientes: a)
Hacer un retiro de efectivo en un cajero automático. b) Usar su tarjeta de crédito
para pagar una comida en un restaurante. c) Comprar acciones en la cuenta en línea
de una casa de bolsa. d) Buscar libros (sobre un tema específico) en una librería en
línea. e) La actividad que especifique su profesor.

5.10. ¿Qué representan las “excepciones” en un caso de uso?

Son situaciones que inducen comportamientos ajenos al flujo normal o “feliz” de uso,
en el sistema. Aunque no correspondan al flujo normal, se deben evaluar, analizar,
validad e implementar (controlar y satisfacer).

5.11. Describa con sus propias palabras lo que es un patrón de análisis.

Como su nombre lo indica, surgieren la solución parcial o completa de una situación,

problemática, dominio o modelos y análisis de requisitos que se comportan como
patrones o se han vivido y solucionada parcial o totalmente anteriormente.

5.12. Con el formato presentado en la sección 5.5.2, sugiera uno o varios patrones de
análisis para los siguientes dominios de aplicación: a) Software de contabilidad. b)
Software de correo electrónico. c) Navegadores de internet. d) Software de
procesamiento de texto. e) Software para crear un sitio web. f) El dominio de
aplicación que diga su profesor.

Escojo en primera a los navegadores web, que tienen que modelar siempre un
protocolo de comunicación, por el que se comunican con los servidores y permiten al
usuario navegar en internet por peticiones y respuestas.

 Nombre del patrón: Protocolito

 Intención: El patrón trata de modelar la interacción, y flujo que se da en el
protocolo de comunicación HTTP que debe satisfacer el navegador web.
 La motivación: Servir de interfaz en una solicitud de cliente (petición) y
respuesta de servidor.
 Solución: Definir un conjunto de pasos que modelen el protocolo. Dicho
modelo debe poseer por lo menos dos identificadores (cliente y servidor)
implementados en clases. Los objetos deben proveer métodos de
comunicación e interfaces para la transmisión y transporte de Hipertexto y
Archivos.
  Consecuencias: El patrón facilita la tarea de modelar el protocolo, apoyándose
en las clases de cliente y servidor.
 Diseño: Uso del patrón de diseño Comando y Visitante
 Los usos conocidos: Todos los navegadores, lo deben implementar como
requisito.

5.13. ¿Qué significa ganar-ganar en el contexto de una negociación durante la

actividad de ingeniería de los requerimientos?

Que tanto el cliente y el equipo, se ven beneficiados por un conjunto de negociaciones,

que permiten la satisfacción del cliente y condiciones buenas de trabajo para el
equipo.

5.14. ¿Qué piensa que pasa cuando la validación de los requerimientos detecta un
error? ¿Quién está involucrado en su corrección?

Por obviedad se debe corregir. Se puede hacer por medio de la retroalimentación

conjunta que se hace con el cliente que es quien que realiza la aclaración y corrección
indirecta del requerimiento.