TRABAJO COLABORATIVO 2
INGENIERIA DEL SOFTWARE
LUZ YANETH ECHAVARRIA
RODOLFO GUTI
MONICA MONTAÑEZ MEDINA
BLANCA YOLANDA PINZON
ALVARO JAVIER URBINA
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD
ESCUELA DE CIENCIAS BÁSICAS, TECNOLOGÍAS E INGENIERÍA
INGENIERÍA DE SISTEMAS
2009
INGENIERIA DE SOFTWARE: TRABAJO COLABORATIVO # 2.
Caso # 1:
Se le ha nombrado gestor de proyecto dentro de una organización de sistemas de información. Su trabajo es construir una aplicación que es bastante similar a otras que ha construido su equipo, aunque esta es mayor y más compleja.
Los requisitos han sido detalladamente documentados por el cliente. ¿Qué estructura de equipo elegiría y porqué? ¿Qué modelo(s) de proceso de software elegiría y porqué?
Hechos:
Soy el Gestor de proyectos.
Construir una aplicación similar a otras que ha construido mi equipo, pero más grande y más compleja.
Requisitos detalladamente documentados por el cliente. Situaciones problemáticas:
Elegir estructura de equipo y ¿Por qué?
Elegir modelo de proceso software y ¿Por qué? Alternativas de solución:
1. Selección del equipo de software:
Para poder elegir una estructura de equipo, debemos tener en cuenta que es una aplicación similar a otras que el equipo ha desarrollado, por tales razones sería muy práctico y eficiente optar por un modelo centralizado controlado, porque además de conocerse proyecto similares, el proyecto actual es de mucho mas tamaño, el cual con una buena modularidad se desarrollaría fácil y rápidamente.
2. Selección del modelo:
Como la documentación está ampliamente detallada y la aplicación es de gran tamaño, se recomendaría por esos motivos el modelo de proceso de software lineal secuencial. Como segunda opción tenemos:
a) Construir una aplicación que es bastante similar a otras, como situación problemática Por lo general, los desarrolladores de software están acostumbrados a desarrollar software a medida, sin suministrar las fuentes a sus clientes, debido al incremento de coste que supondría el no poder rentabilizar sus desarrollos con otros clientes. Estos bloques de código reutilizables en
otras aplicaciones también permiten agilizar en tiempo y medida el desarrollo de programas, además una organización que tenga sus procesos mejor estructurados y estandarizados podrá obtener mejor provecho de las herramientas que tiene disponible y no al contrario. Esto es observable en muchas organizaciones, por lo general adquieren software que puede ofrecerles infinidad de posibilidades, razón por la cual otras empresas lo emplean, sin embargo al no tener la base definida es poco el provecho que se obtiene pues no se busca optimizar el proceso a través del empleo de herramientas.
Como alternativa de solución:
La definición de alcance del proyecto es muy importante para su buena y eficaz conclusión. En este sentido, las metodologías de desarrollo son herramientas que nos permiten soportar y estructurar el proyecto de una manera concisa. Aquí, es importante aplicarlas y usarlas de forma adecuada. Los objetivos del proyecto se deben definir desde el inicio, esto no implica, necesariamente, que no sea extensible. Sino que delimita un rango de cosas que abarca.
b) La aplicación es mayor y más compleja, como situación problemática:
Un gestor de proyectos de software debe concentrarse en entender el problema que hay que resolver, gestionando el flujo de ideas y, al mismo tiempo, haciendo saber a todos los miembros del equipo (mediante palabras y, mucho más importante, con hechos) que la calidad es importante y que no debe verse comprometida.
Esto debido a que la escala es de gran tamaño y complejidad y que se presta para confusiones y dificultades en el desarrollo del software.
Como alternativa de solución:
La filosofía de "voy desarrollando y va quedando como quiere el cliente ya que somos recontra flexibles", no es la mejor ya que, de acuerdo a experiencias, genera mas problemas que soluciones (refactoring, retrasos, perdida de percepción del alcance, etc.)
Sobre la estimación de tiempos de un proyecto, podría comentar que el grado alto de flexibilidad dificulta terriblemente una estimación confiable, ya que el cliente puede cambiar tantas cosas que tu proyecto puede crecer y crecer. En todo caso lo que se hace es controlar componentes más pequeños del proyecto, planificar el trabajo sobre estos, el tiempo y los recursos que intervendrán y posteriormente a este componente, los que sigan. También es muy importante métodos de coordinación y comunicación con el equipo.
c) Los requisitos han sido detalladamente documentados por el cliente, como situación problemática:
Cuando los integrantes del equipo o proyecto trabajan en aspectos que son de su interés, de esta manera, el proyecto en global se beneficia teniendo mejores resultados, personas comprometidas y apasionadas con su trabajo. Sin embargo, esto presenta el problema de que, generalmente, se pierde un poco el sentido de visualización integral del proyecto, cosa que se suele mejorar con la incorporación de roles de coordinación.
Como alternativa de solución:
Respecto al tema de definición de requisitos y ámbito del proyecto, tenemos, como aspecto relevante la constante interacción con el usuario operador a través de sus procesos de retroalimentación de versiones en etapa temprana. Esto permite que el desarrollo se realice a medida que se encuentre una necesidad del usuario. Sea un informe de fallo, solicitud de características nuevas, modificación de funcionalidad, etc. estas incidencias son las que usualmente activan los esfuerzos de desarrollo y mantienen una línea de vida constante en el proyecto de software. Si se pierde el interés en el software o no se obtiene esta retroalimentación, usualmente el desarrollo se estanca y suele quedar abandonado.
En cuanto a: ¿Qué estructura de equipo elegiría y porqué?:
Creo que es importante una estructura de equipo CENTRALIZADO CONTROLADO, que me permita como Jefe de equipo la resolución de problemas a alto nivel, obviamente no dependerá solo de mi situación como Jefe, sino del aporte y coordinación interna del equipo, pero se hace necesario una comunicación vertical que permita tener enfocado al grupo en una misma dirección. Lo elegiría porque da pie a la coordinación racional tanto del personal como del conjunto de actividades a desarrollar, razón por la cual es posible que todos hablen el mismo idioma y que todos se interesen en analizar las situaciones con un margen de control interno que no permite desviaciones en el proceso.
¿Qué modelo(s) de proceso de software elegiríamos y por qué?:
El modelo de proceso de software que implementaríamos sería el COCOMO DETALLADO, ya que permite incluir características del modelo intermedio y además los factores correspondientes a los atributos son sensibles a la fase sobre la que se realizan las estimaciones, puesto que aspectos tales como la experiencia en la aplicación, utilización de herramientas de software entre otras, tiene mayor influencia en unas fases que en otras y además porque van variando de una etapa a otra y permiten una evaluación del impacto de los conductores de costo en cada fase del proceso. También establece una jerarquía de tres niveles de productos de forma que los aspectos que representan gran variabilidad a bajo nivel, se consideran a nivel de modulo; los que representan pocas variaciones, a nivel de subsistema; y los restantes son considerados a nivel del sistema.
Caso # 2:
Se le ha nombrado gestor de proyecto de una pequeña compañía de productos software. Su trabajo consiste en construir un producto innovador que combine hardware de realidad virtual con software innovador. Puesto que la competencia por el mercado de entrenamiento casero es intensa, hay cierta presión para terminar el trabajo rápidamente. ¿Qué estructura de equipo elegiría y porqué? ¿Qué modelo(s) de proceso de software elegiría y porqué?
Soy gestor de proyectos.
Pequeña compañía de productos software.
Desarrollar producto innovador que combine hardware y software innovador. Presión para terminar trabajo.
Situaciones problemáticas:
Elegir estructura de equipo de trabajo y ¿Por qué? Elegir proceso de software y ¿Por qué?
Alternativas de solución:
1. Selección de equipo de trabajo:
Para tomar esta decisión debemos considerar seriamente las circunstancias que se presentan: Empresa pequeña.
Hacer cambios de software existente (innovar). Necesidad de terminar pronto.
Por tales razones y por la necesidad de innovar y por los tiempos de entrega cortos, me inclinaría inevitablemente por la estructura de equipo descentralizado controlado. El cual permite cumplir con tiempos de entrega y posibilita una máxima innovación.
2. Selección del modelo:
Debido a la presión por tiempo de entrega corto y a la posible reutilización de aplicaciones debemos indicarnos por el modelo de desarrollo rápido para software también llamado DRA. Caso # 3:
Usted es el jefe de proyectos de una compañía de software. Se le ha pedido que dirija a un equipo que está desarrollando un software de un procesador de textos.
Construya una tabla de riesgo para el proyecto. Hechos:
Soy el jefe de proyectos de una compañía de software. Se debe desarrollar un procesador de textos.
Situaciones problemáticas:
Alternativas de solución:
RIESGOS
CATEGORIA
PROBALIDAD
IMPACTO
Efectos del producto en
los ingresos de la
compañía.
IO
90%
4
Es nuevo para la
compañía el software a
desarrollar.
T
90%
4
Suficiente personal.
ET
90%
4
El software interactuará
con hardware nuevo o no
aprobado.
T
80%
1
Hay disponible
herramienta de gestión de
proyectos de software.
ED
70%
2
Hay disponible
herramienta de gestión de
proyectos de software.
ED
70%
2
El cliente tiene claro el
producto que requiere.
TC
70%
3
Existen en nuestra
compañía herramientas
de análisis y diseño.
ED
50%
2
Personal con
conocimientos adecuados.
ET
50%
2
Mayor número de
usuarios del producto.
TP
45%
3
Número de cambios antes
de la entrega del
producto.
TP
30%
3
Número de cambios
después de la entrega
del producto.
TP
3%
3
Caso #4:Asuma que ha sido contratado por una Universidad para desarrollar un sistema de inscripción a cursos para un determinado programa. Defina un listado de tareas. Utilice las diferentes técnicas para establecer una planificación temporal del proyecto.
Desarrollar de un sistema de inscripción a cursos para un determinado programa. Situación problemática:
Definir listado de tareas.
Usar diferentes técnicas para establecer una planificación temporal del proyecto: Alternativas de solución: Listado de tareas.
1. Definición de cursos (1 día) A.
2. Definición de mecanismos de inscripción (1 día) B. 3. Definición de personal necesario (1 día) C.
4. Definición de formato de inscripción (1 día) D. 5. Capacitación de personal (8 días) E.
6. Simulacro de inscripción (3 días) F. 7. Correcciones y/o mejoras (3días) G.
8. Definición de fecha de la inscripción (1 día) H. 9. Evento (5 días) I. Diagrama PERT: A (1) C (1) D (1) E (8) B (1) F (3) G (3) H (1) I (5) 1 0 2 1 1 4 2 3 5 3 3 6 11 11 3 2 2 7 14 14 8 17 17 9 18 18 10 23 23
