UNIVERSIDAD NACIONAL PEDRO RUIZ GALLO

INGENIERIA DE SOFTWARE
CICLO 2018-II
Preguntas sobre los libros de los autores: Sommerville, Roger Pressman.

INTEGRANTES:
 BAUTISTA CASTAÑEDA, AARÓN
 BECERRA HUAMAN, BRYAN
 SANDOVAL CHAPOÑAN, ANDERSON

1 DE OCTUBRE DE 2018
LAMBAYEQUE, PERÚ
 PARTE I:
Resolver las siguientes preguntas extraídas del libro de Ingeniería de software de
Sommerville, capítulo 22
1.- Explique por qué los mejores programadores no siempre son los mejores
administradores de software. Tal vez le resulte útil basar su respuesta en la lista
de actividades administrativas de la sección 22.
Motivo porque los mejores programadores no pueden ser los mejores administradores
es que los programadores están capacitados y programados exclusivamente ara esta
tarea en el desarrollo del software y por otra parte los gestores se abocan a la
planificación del proyecto ya que este debe tener el conocimiento del progreso del
proyecto y así comparar el progreso, acción que quizá el programador no lo ve
claramente por ello se debe tener a ambos en el proyecto Programador y Gestor. Y por
último motivo seria que los programadores no tienen mucha capacidad de comunicación
como para liderar un quipo

2. Además de los riesgos que se muestran en la figura 22.1, identifique al menos

otros seis riesgos posibles que pudieran surgir en los proyectos de software.

Riesgo Repercute en Descripción

Peleas en el personal
Se subestimo el presupuesto
Mal interpretación de requisitos
Falta de compromiso del cliente
para el proyecto
Baja motivación
Trabajos no programados
Proyecto Riñas o celos dentro del personal crean
un ambiente poco productivo
Proyecto y producto Los recursos obtenidos no son
suficientes
Proyecto y Producto Los requisitos son mal interpretados
ocasionando desfase en las
expectativas, demandas y el producto.
Proyecto y producto Poca actividad en reuniones para la
validación del plan que seguirá el
proyecto.
Proyecto El personal se encuentra cansado por
un proyecto que es largo en el tiempo,
decayendo la productividad.
Proyecto Situaciones nuevas las cuales no hay
respuestas comprobadas que puedan
ser utilizadas como guía.

3. Explique por qué mantener informados a todos los miembros de un grupo

acerca del progreso y las decisiones técnicas en un proyecto ayuda a mejorar la
cohesión del grupo.
Porque las personas que trabajan en una organización de software son los activos más
importantes, por lo tanto son ellos los primeros en tener conocimiento del progreso,
eventos y decisiones técnicas que ocurren en un proyecto a diferentes niveles del
personal con esto alentar al personal a ser productivo ya que una de las metas más
importantes para la mayoría de los proyectos es mantener un equipo de desarrollo
óptimo y con buen funcionamiento.
PARTE II:
Resolver las siguientes preguntas extraídas del libro de Ingeniería de software de
Sommerville, capítulo 24
1. Las decisiones tomadas por los administradores ejecutivos pueden tener un
impacto significativo sobre la efectividad de un equipo de ingeniería del software.
Proporcione cinco ejemplos para ilustrar que esto es cierto.
1. LA PLANIFICACION DE TIEMPOS:
Una mala planificación puede ocasionar que el proyecto se retrase y el costo estima do
sea mayor.
2. EL PERSONAL:
Si el administrador agrega un personal más, afectara la coordinación del equipo.
3. CAPACITACION:
No existe capacitación regular para la actualización de las nuevas tecnologías.
4. LIDERAZGO:
Si el administrador no es líder, es decir decide que el personal tiene la suficiente
preparación sin llevar un control de sus conocimientos.
5. ADQUISICIÓN DE TECNOLOGIA:
Si el administrador decide llevar una tecnología sin consultar a su equipo.
2. Al lector se le asigna una gerencia de proyecto dentro de una organización de
sistemas de información. Su labor será construir una aplicación que sea muy
similar a otras que su equipo construyó, aunque ésta será más grande y más
compleja. Los requerimientos se documentaron ampliamente por parte del cliente
¿Qué modelo de proceso de software elegiría y por qué?
- Elegiría el modelo espiral, porque al trabajar con grandes cantidades de información
es necesario un gestor de riesgos para el control de posibles riesgos y daños que
puedan ocurrir ya que este modelo a diferencia de otros hace un reconocimiento
explícito del riesgo. Conforme a su construcción del aplicación este modelo es un
proceso que pasa por cuatro interacciones que son determinar objetivos y restricciones,
valoración y reducción de riesgos, desarrollo y validación y por últimos el proyecto se
revisa y se toma una decisión sobre si hay que continuar con otro ciclo de la espiral,
todo esto conlleva a la realización de un conjunto de actividades para su definición y
desarrollo óptimo del software.
3. Al lector se le asigna una gerencia de proyecto para una gran compañía de
productos de software. Su labor será administrar el desarrollo de la versión de
siguiente generación de su software de procesamiento de palabras ampliamente
usado. Puesto que la competencia es intensa, se establecieron y anunciaron
apretadas fechas límite. ¿Qué modelo de proceso de software elegiría y por qué?
- Elegiría de modelo Incremental, porque es orientado al cliente en un proceso en que
los clientes identifican, en un bosquejo, los servicios que proporciona el sistema, de ahí
las especificaciones o requerimientos se van desarrollando con las diferentes versiones
del código. Este modelo brinda procesos iterativos que pueden ayudar a develar metas
del diseño en caso que el cliente no supiera como definir lo que quiere y este desarrollo
iterativo recomienda la construcción de secciones reducidas de software que irán
ganando tamaño para facilitar así la detección de problemas de importancia antes de la
fecha límite.
4. Al lector se le ha pedido desarrollar una pequeña aplicación que analice cada
curso ofrecido en la universidad y reporte las calificaciones promedio obtenidas
en el curso (por un determinado periodo). Exponga el alcance y las limitaciones
de este trabajo.
- Está dirigido a almacenar y ordenar, por ciclos y cursos, un millar de diferentes tipos
de datos ligado a millares de estudiantes en distintos ciclos académicos, lo que requiere
una base de datos amplia, debe tener una rapidez de proceso en las consultas de notas
de los estudiantes, mostrando específicamente lo que se requiere al colocar los datos
de entrada.
El software se aprovecha para la universidad en general a llevar control de todos los
cursos ofrecidos y en que ciclo académico se ofrecen.
Por otro lado se deriva la información de cuales cursos son los más difíciles para los
estudiantes gracias a las calificaciones almacenadas, probablemente si las
calificaciones del curso son demasiados bajas esto quiere decir que el curso es
complicado para el nivel de los estudiantes o también podría decir que el docente que
tiene asignado este curso tiene problemas de enseñanza.
PARTE III
Resolver las siguientes preguntas extraídas del libro de Ingeniería de software de
Roger Pressman, capítulo 27(preguntas de la 1 a la 2) y de Sommerville, capítulo
23(preguntas de la 3 a la 3):
1. Las fechas límite “irracionales” son un hecho de la vida en el negocio del
software. ¿Cómo debe proceder si se enfrenta con una?
Usando las técnicas de las fechas límites que se implementan bajo las restricciones de
una fecha limite definida. Así las mejores estimaciones que la fecha límite es irreal, el
gerente del proyecto deberá proteger a su equipo contra la presión excesiva (del
calendario) y devolver la presión a quienes la originaron.
A continuación, se va a explicar los 4 pasos de las técnicas de las fechas límites:
 Realice una estimación detallada, usando datos históricos de proyectos
anteriores. Determine el esfuerzo y la duración estimados para el proyecto.

 Con el modelo de proceso incremental (capítulo 2), desarrolle una estrategia de

ingeniería de software que entregue funcionalidad crucial hacia la fecha límite
impuesto, pero desarrolle otra estrategia para otra entrega de software con
funcionalidad hasta más tarde. Documente el plan.

 Reúnase con el cliente y (con la estimación detallada) explique por qué la fecha
límite es irreal. Asegúrese de señalar que todas las estimaciones se basan en el
rendimiento de proyectos anteriores. También asegúrese de indicar el porcentaje
de mejora que se requeriría para lograr cumplir en la fecha límite, como se
plantea originalmente. El siguiente comentario puede ser apropiado como
respuesta:
 Creo que podemos tener problemas con la fecha de entrega para el software
controlador XYZ. A cada uno de ustedes le entrego una distribución abreviada
de las tasas de desarrollo para proyectos de software anteriores y una
estimación que se hizo de maneras distintas. Observarán que supuse una
mejora de 20 por ciento en tasas de desarrollo anteriores, pero todavía tenemos
una fecha de entrega que es de 14 meses en lugar de nueve.

 Ofrezca la estrategia de desarrollo incremental como una alternativa: Tenemos

algunas opciones, y me gustaría que tomaran una decisión con base en ellas.
Primero, podemos aumentar el presupuesto y conseguir recursos adicionales,
de modo que podremos tener listo este trabajo en nueve meses. Pero entiendo
que esto aumentará el riesgo de empobrecer la calidad debido a las fechas tan
apretadas.3 Segundo, podemos remover algunas funciones y capacidades del
software que se solicitan. Esto hará que la versión preliminar del producto sea
un poco menos funcional, pero puede anunciarse toda la funcionalidad y
entregarla durante el periodo de 14 meses. Tercero, podemos prescindir de la
realidad y querer que el proyecto esté completo en nueve meses. Acabaremos
sin tener algo que pueda entregarse al cliente. La tercera opción, y creo que
estarán de acuerdo, es inaceptable. La historia pasada y nuestras mejores
estimaciones dicen que es irreal y que representa una receta para el desastre.
Como conclusión: Habrá algunos gruñidos, pero si se presenta una estimación sólida
con base en buenos datos históricos, es probable que se elijan las versiones negociadas
de las opciones 1 o 2. La fecha límite irreal se evapora.
2. ¿Puede existir un caso donde un hito de proyecto de software no se ligue a una
revisión? Si es así, ofrezca uno o más ejemplos.
Si es cierto esto se da al Atender especialmente los puntos críticos del proyecto. - Estos
puntos normalmente son los hitos de un programa de trabajo y coinciden con la
obtención de los productos entregables más representativos del proyecto, como: la
especificación, el documento de diseño, el código, los ejecutables, las interfaces de
usuario y las pruebas.
3. La figura 23.14 establece algunas tareas, duraciones y dependencias. Dibuje
una gráfica de barras que muestre el calendario del proyecto.
4. La figura 23.14 muestra las duraciones de las tareas para actividades de un
proyecto de software. Suponga que ocurre un grave inconveniente no anticipado
y que la tarea T5, en vez de tardar 10 días, tarda 40 días. Dibuje nuevas gráficas
de barras que muestren cómo puede reorganizarse el proyecto.
 SEMANA
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 20 21 22 23 24 25 26 27 28 29 30
T1

(T1) T2
(T1, T2) T3

T4

T5

(T3, T4) T6

(T3) T7

(T7) T8

(T6) T9

(T5, T9) T10

(T9) T11

(T10) T12
(T3, T4) T13

(T8, T9) T14

(T2, T14) T15

(T15) T16