Este documento presenta diferentes modos de comunicación utilizados en proyectos de ingeniería de software, incluyendo revisiones del cliente, revisiones del proyecto, inspecciones y pruebas de recorrido, revisiones de estado, lluvia de ideas, lanzamientos, revisiones post mortem, peticiones de aclaraciones, peticiones de cambio y resolución de problemas. También describe mecanismos de comunicación como conversaciones informales, reuniones, correo electrónico y grupos de noticias.

1. COMUNICACIÓN DE
PROYECTOS.
INGENIERA DE SISTEMAS
TOPICOS AVANZADOS DE INGENIERA DEL SOFTWARE
HERNAN CAMILO CELY CACERES
5 de Mayo de 2016

2. PANORAMICA DE LA COMUNICACION
 Un modo de comunicación se refiere a un tipo de intercambio de información que
tiene objetivos y alcances definidos
 El reporte de problemas es un ejemplo del modo de comunicación durante el cual
un usuario reporta un error a los desarrolladores.

3. Los modos calendarizados incluyen:
Revisiones del cliente, reportes de estado y versiones del sistema.
Los modos manejados por eventos incluyen:
Peticiones de cambios, aclaraciones y resolución de problemas.

4. Modos de Comunicación.
MODO MODO
Definición del problema. Lanzamientos.
Revisiones del cliente. Revisión post mortem
Revisiones del proyecto. Peticiones de aclaraciones
Inspecciones y pruebas de recorrido. Peticiones de cambios
Revisiones de estado. Resolución de problemas.
Lluvia de ideas.

5. DEFINICION DEL PROBLEMA.
 El objetivo de esta es que el gerente de proyecto y el cliente se pongan
de acuerdo sobre el alcance del sistema que se va a construir.
Esto produce un documento de definición
del problema que tiene las
funcionalidades y los requerimientos no
funcionales.

6. REVISIONES DEL CLIENTE
 El objetivo de las revisiones del clientes son:
 El cliente valore el avance del desarrollo.
 Los desarrolladores confirmen o cambien los requerimientos del
sistema.
 Incrementar comprensión compartida entre participantes.
 La revisión se hace sobre que hace el sistema y cuales restricciones
son relevantes para el cliente.

7. La revisión está precedida por la entrega de un producto de trabajo, como un
documento de especificaciones, una maqueta de interfaz o un prototipo para
evaluación.
Ejemplo de una agenda para una revisión del cliente.

8. REVISION DEL PROYECTO
 El gerente del proyecto valore el estado y los equipos revisen las interfaces de los
subsistemas, esto puede favorecer el intercambio de conocimiento operacional
entre los equipos.
 El enfoque de las revisiones del proyecto no deben ser sobre una funcionalidad,
a menos que tenga un impacto de factibilidad en el sistema.

9. INSPECCIONES Y PRUEBAS DE
RECORRIDO
 Incrementar la calidad de un
subsistema mediante la revisión de
iguales.
 En el caso de una prueba de recorrido,
un desarrollador presenta ante los
demás miembros del equipo el
código, línea por línea, que ha escrito.
Los del cuestionan cualquier código
sospechoso tratan de descubrir la
mayor cantidad de errores en el.
 Efectivas para detección temprana de
defectos

10. REVISIONES DE ESTADO
 El objetivo de esta es detectar desviaciones con respecto al plan de tareas y
corregirlos.
 Se puede realizar en: un equipo(cada semana), un proyecto(cada mes).
 Motiva la discusión de asuntos pendientes, problemas no anticipados y la
comunicación informal.

11. LLUVIA DE IDEAS
 La idea fundamental de la lluvia de ideas es que las propuestas hechas por un
participantes así no sean validas, pueden generar otras ideas o propuestas de los
otros participantes.

12. LANZAMIENTOS
 Poner un documento o un subsistema a disposición de otros participantes del
proyecto, reemplazando con frecuencia una versión anterior del artefacto. Un
lanzamiento puede ser tan simple como un mensaje electrónico de dos
renglones
REVISION POST MORTEM
 Se enfocan en la extracción de lecciones del desarrollo una vez que se ha
entregado el software.
 En todos los casos, las áreas cubiertas deben incluir las herramientas, los métodos,
la organización y los procedimientos usados en ci proyecto.

13. EJEMPLO DE PREGUNTAS PARA UNA
REVISIÓN POST MORTEM.

14. PETICIONES DE ACLARACIONES
 Las peticiones de aclaraciones son
manejadas por eventos. Un
participante puede solicitar aclaración
acerca de cualquier aspecto del
sistema que puede ser ambiguo. Las
peticiones de aclaraciones pueden
ocurrir durante reuniones informales, o
por medio de llamadas telefónicas,
correo electrónico, formularios o en la
mayoría de los demás mecanismos de
comunicación disponibles para ci
proyecto.

15. PETICION DE CAMBIO
 Un participantes reporta un problema y en algunos casos, propone una solución.
 Las peticiones de cambio contienen una clasificación, una descripción del
problema, una descripción del contexto donde sucede y cualquier cantidad de
material de apoyo

16. RESOLUCION DE PROBLEMAS
 Una organización plana puede seleccionar una solución como parte de un
proceso de lluvia de ideas. Una organización jerárquica, o una situación de crisis,
puede requerir que un solo individuo seleccione o imponga una solución. En
todos los casos, la solución necesita documentarse y comunicarse a los
participantes relevantes.

17. MECANISMOS DE COMUNICACION
SINCRONOS ASINCRONOS
Conversaciones en los pasillos Correo electrónico
Cuestionarios y entrevistas estructurados Grupos de noticias
Reuniones(frente a frente, telefónica, en
video)
World wide web
Group ware(diferente lugar y al mismo
tiempo)
Lotus notes

18. CONVERSACIONES EN LOS PASILLOS
 Intercambios de información informal manejados por eventos basados en la
oportunidad. Dos participantes se reúnen por accidente y comparten
información.

19. CUESTIONARIOS Y ENTREVISTAS
ESTRUCTURADAS
 El objetivo de un cuestionario es
obtener información de una o más
personas en forma estructurada.
 Los cuestionarios tienen la ventaja de
obtener información confiable con un
costo mínimo por parte del usuario.
 La desventaja de los cuestionarios es
que son difíciles de diseñar.

20. REUNIONES
 Permiten que varios participantes negocien asuntos y soluciones.
 Son costosas y difíciles de administrar.
 En una reunión se asignan varios roles para que sea mas fácil de manejar la
información:
 Moderador principal. Responsable de organizar la reunión y guiarla.
 Secretario de actas. Registra la reunión y toma notas.
 Tomador de tiempo. Notifica el tiempo.
 La reunión da como resultado un conjunto de minutas que tienen lo que se debe
hacer frente a un asunto.

22. GROUPWARE EN DIFERENTES LUGARES Y
AL MISMO TIEMPO
 Esta definido en diferentes lugares y al mismo tiempo.
 Permite la comunicación de usuarios que están en diferentes lados.
 Todos los usuarios ven el mismo documento, uno solo puede modificarlo,
cualquiera puede tener la voz.
 Es demasiado útil cuando se utiliza en videoconferencias y se combina con canal
de audio.
 Su debilidad es la dificultad para coordinar los usuarios.

23. CORREO ELECTRONICO
 Es un mensaje de texto enviado a uno
o mas usuarios, que puede ser
enviado en tan solo segundos, hasta
unas horas o días. El mensaje llega a
un buzón y hay permanece hasta que
el receptor lo recibe.
 Es de naturaleza asíncrona por lo que
seria muy bien utilizado en la
comunicación manejada por eventos,
lluvia de ideas o peticiones de
aclaraciones.
 Debido a su misma naturaleza el
correo tiene el mayor potencial de
perdida de información.

24. GRUPOS DE NOTICIAS
 Similar al correo electrónico. Sin embargo, en vez de enviar un mensaje a
varios receptores, el emisor envía un mensaje a un grupo de noticias (al que
también se le conoce como foro).
 Los grupos de noticias son
adecuados para notificar y discutir
entre personas que comparten un
interés común.

25. BIBLIOGRAFIA
 Ingeniería de software orientada a objetos-Bernd Bruegge