Universidad Nacional de Misiones

Licenciatura en Sistemas de Información

Analista en Sistemas de Computación
Profesorado Universitario en Computación

Introducción al Análisis de Sistemas

Ingeniería de Software I
Profesor: Ing. Selva Nieves Ivaniszyn

Guía de Estudio 4
Integrantes

Página 1|6
Foto APELLIDO y Nombre correo electrónico
Nasadyk Fernando fernasadyk12@gmail.com

Rodrigues Sebastian mailto:seb4.rdgz@gmail.com

mailto:lucas.mino1508@gmail.c
Miño Lucas
om

Keingeski Noam noamxd1@gmail.com

Año 2022

Página 2|6
22.1. EXPLIQUE por qué la intangibilidad de los sistemas de software
plantea problemas especiales para la gestión de proyectos de software.
La intangibilidad de los sistemas de software plantea problemas para la gestión de proyectos de software
porque el software al ser intangible no se puede ver ni tocar, por lo que los administradores de los
proyectos no pueden tener una idea del proceso, progreso o del avance del software; no pueden ver qué
cosas van mal, tienen que confiar en otros para la elaboración de dicho software.

22.2. 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.1.
Porque los administradores de software deben tener la capacidad y experiencia para crear y validar los
planes de desarrollo de software y para ello deberían tener experiencia de cada una de esas labores, por lo
tanto, es bien difícil que un programador se involucre en todas esas labores a menos que ya tenga un buen
tiempo de interactuar en diferentes áreas del proceso de desarrollo de software.

22.3. Con los casos de problemas de proyecto reportados en la literatura,

MENCIONE las dificultades y los errores administrativos que ocurrieron en dichos
proyectos de programación fallidos. (Se sugiere que comience con The Mythical Man
Month, de Fred Brooks).
Durante el desarrollo del sistema operativo OS/360 de IBM. Se había agregado más programadores a un
proyecto que se estaba retrasando, una decisión que más tarde concluiría que, contrariamente a la
intuición, había retrasado aún más el proyecto. También cometió el error de afirmar que un proyecto,
relacionado con la escritura de un compilador ALGOL , requeriría seis meses, independientemente de la
cantidad de trabajadores involucrados (requirió más tiempo).

22.4. 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.
Otros riesgos posibles que pueden surgir en Proyectos de Software son:

 Requerimientos incompletos: Los Requerimientos no se definieron de una manera precisa y com-

pleta.
 Modificaciones incorrectas de las especificaciones: Actualización incorrecta de los requerimientos
debido a la ausencia de un estudio detallado previo.
 Falta de Especificación de la arquitectura lógica y física: No se define adecuadamente los recursos
lógicos entre módulos del sistema, ni el hardware adecuado para la correcta funcionalidad de la ar-
quitectura lógica.
 Modificación cronograma actividades: Debido a Actividades incompletas o retrasadas por impre-
vistos. Agregación de nuevas actividades. Complejidad en el desarrollo de actividades.
 Pérdida de Backup: Perdida de la copia de seguridad del software, causado por virus o por un defi-
ciente remplazo de versión.

Página 3|6
  Enfermedad: Enfermedades eventuales a los miembros del equipo de desarrollo del
software que atrase la continuidad de una tarea.
 Demoras en la reparación de defectos: La solución de defectos encontrados en las pruebas, no son
priorizados por los desarrolladores.
 Complejidad del proyecto: A medida que el proyecto se vaya desarrollando podría ser cada vez
más complejo de lo que se tenía previsto.

22.5. Los contratos de precio fijo, donde el contratista ofrece un precio fijo para
completar un desarrollo de sistema, permiten desplazar los riesgos del proyecto del
cliente al contratista. Si algo sale mal, el contratista debe pagar. SUGIERA cómo el
uso de tales contratos puede aumentar la probabilidad de que surjan riesgos del
producto.
Puede aumentar la probabilidad de riesgos si durante el transcurso del proyecto de desarrollo si es
necesario
un gasto extra el cual no estaba estipulado, o haya cambios no planificados, esto provocaría problemas
con el cliente, ya que, el cliente no está obligado a ser responsable de la demora por los mismos y la
espera de ellos. De igual manera el cliente podría pedir diversos cambios, que exigirían más tiempo y
presión a los desarrolladores. Por lo cual, es necesario acordar una cláusula en la cual se establezca un
margen de tiempo mínimo y máximo para poder entregar el proyecto y así pueda quedar un tiempo
prudencial por posibles eventualidades fuera del control de ambas partes.

22.6. En relación a los Grupos de Trabajo:

a. EXPLIQUE por qué mantener informados a todos los miembros de un grupo
acerca del progreso y de las decisiones técnicas en un proyecto ayuda a mejorar la
cohesión del grupo.

Mantener informados a todos los miembros de un grupo acerca de las decisiones que se toman en un
proyecto ayuda a mejorar la cohesión del grupo porque se crea un entorno en el cual no hay confusión,
genera más comunicación, confianza y ayuda a que todos lleguen a un acuerdo.

b. ¿QUÉ estrategias pueden utilizarse para fomentar la cohesión en el grupo de

trabajo?
Las estrategias que pueden utilizarse para fomentar la cohesión en el grupo de trabajo pueden ser:
Primeramente, para que un grupo tenga buena comunicación no debe ser de muchos integrantes, si el
grupo de trabajo es informal, podríamos limitar el número de integrantes a 5 o 6, al ser pocas personas, es
más fácil acordar juntas y por lo tanto aumenta la comunicación en persona, esto evita confusiones y
aumenta la confianza con el grupo.
Al momento de tomar decisiones, lo recomendable es tomar decisiones o consenso y no por ocurrencia de
la minoría.
La inclusión de una persona del sexo opuesto también es recomendable ya que ayuda a la interacción del
grupo.
Un ambiente laboral agradable hace que cada miembro del grupo se sienta cómodo en donde se
encuentra, esto genera un buen humor, el cual es muy importante para las relaciones en un grupo de
trabajo.
Página 4|6
Organizar eventos sociales explícitos al grupo de trabajo, incluyendo tanto a los
integrantes del grupo como a sus familias, también alientan a la cohesión del grupo.

22.7. ¿QUÉ problemas considera que surgirían en los equipos de programación

extrema, donde muchas decisiones administrativas se delegan en los miembros del
equipo?
Los problemas que considero que surgirían en los equipos de programación extremas son: confusiones,
desacuerdos, discusiones, falta de coordinación de los miembros del grupo y una posible falla del
proyecto. Ya que al delegar decisiones administrativas a los miembros del grupo quita la posibilidad de
definir una autoridad para dirigir el trabajo; supongamos que los miembros del equipo no tienen la
capacidad de decidir para el equipo, esto puede llevar al equipo a tomar malas decisiones y por lo tanto
gestionar y concluir el proyecto con errores.

22.8. ESCRIBA un estudio de caso, con el estilo usado aquí, para ilustrar la
importancia de las comunicaciones en un equipo de proyecto. SUPONGA que
algunos miembros del equipo trabajan a distancia y no es posible reunir a todo el
equipo en el corto plazo.
Hoy en día cada vez son más comunes estas situaciones, ya que, al haber internet y redes sociales, se hace
posible la tarea de comunicarse entre miembros de un equipo que están a distancia, sin ser tan necesaria la
comunicación en persona, ya que estas aplicaciones nos facilitan esta labor. Por lo tanto, no creo que la
distancia sea un problema muy grande.
Pero el hecho de no poder comunicarse personalmente los miembros de un equipo puede afectar bastante
a la hora de tomar decisiones, ponerse de acuerdo en algo y por consiguiente el proyecto, debido a que la
única forma de comunicarse sería mediante celulares y computadoras. Puede pasar que algún miembro
del equipo no esté presente a la hora de debatir sobre algo en algún grupo o reunión, entonces esa persona
posteriormente tendrá que ponerse al día con lo que se ha hablado en esa reunión, entonces tardará más en
hacer su parte del trabajo y posiblemente retrasará al resto del equipo, esto puede llegar a comprometer el
proyecto.
En conclusión, si cada miembro del equipo es responsable y se propone a cumplir con su parte del
proyecto, no debería haber muchos inconvenientes para terminar el trabajo, aunque sea poco el tiempo
disponible.

22.9. Su administrador le pide entregar software en un plazo que sólo podrá cumplir
si pide a su equipo de proyecto trabajar tiempo extra sin remuneración. Todos los
miembros del equipo tienen hijos pequeños. DISCUTA si debe aceptar esta demanda
de su administrador o SI DEBE persuadir a su equipo a ceder su tiempo a la
organización en lugar de dedicarlo a sus familias. ¿QUÉ factores pueden ser
significativos en su decisión?
En nuestra opinión no aceptaríamos la demanda que exige el administrador, a menos que el equipo de
proyecto esté de acuerdo o el software a realizar sea de muchísima importancia, debido a que nos parece
una falta de respeto pedir trabajar horas extra al equipo sabiendo que no le serán remuneradas, además de
saber que todos poseen hijos.
Los factores significativos en la decisión serían la opinión del equipo de proyecto junto a la importancia
del requerimiento del software.

Página 5|6
22.10. Como programador, se le ofrece una promoción a un puesto de
gestión de proyectos, pero siente que puede hacer una aportación más
efectiva en un papel técnico más que administrativo. DISCUTA si debe aceptar la
promoción.
Si mi interés es el crecimiento personal estaría en lo correcto a la hora de aceptar la promoción, siempre y
cuando tenga presente que dicho puesto no vaya a ser un elemento que me cause algún tipo de
desmotivación y ésta encadene un bajo rendimiento en mí trabajo.

Página 6|6