Pregunta: .Robert Adam, el gerente de proyecto de Renegade, acaba de recibir una notificación de que su proyecto estuvo inactivo durante cuatro horas debido a un conflicto de especificación. El conflicto provino del desacuerdo sobre cómo llevar a cabo una de las tareas del proyecto. Peligrosamente, el desacuerdo se basó en las desviaciones de las especificaciones, por

.Robert Adam, el gerente de proyecto de Renegade, acaba de recibir una notificación de que su proyecto estuvo inactivo durante cuatro horas debido a un conflicto de especificación. El conflicto provino del desacuerdo sobre cómo llevar a cabo una de las tareas del proyecto. Peligrosamente, el desacuerdo se basó en las desviaciones de las especificaciones, por lo que la demora del proyecto probablemente era inevitable. Robert era muy consciente de que su proyecto no progresaría hasta que se resolviera este problema. En consecuencia, si el proyecto no cumplió con las especificaciones durante la revisión, no avanzaría en absoluto hasta que se haya hecho una corrección o se haya aprobado y registrado una modificación al documento de especificaciones. Esto irritó a Robert. Entonces, convocó a una reunión de emergencia con las partes involucradas. RENEGADE Renegade es un proveedor de seguros de salud en la región sureste. La empresa ha empleado la metodología “cascada” para sus proyectos de desarrollo de software. La metodología de cascada se basa en el supuesto de que los proyectos se pueden gestionar mejor cuando se segmentan en una jerarquía de fases, etapas, actividades, tareas o pasos. Por lo tanto, la metodología en cascada dirige un proyecto de desarrollo de software para que progrese en una secuencia ordenada de pasos de desarrollo. Esto también significa que los pasos de desarrollo simultáneos de un proyecto están prohibidos. Renegade ha experimentado un rápido crecimiento a lo largo de los años. En tan solo un breve lapso de cinco años, el número de suscriptores aumentó de doscientos mil a más de un millón de suscriptores. La gerencia predice aún más crecimiento. Este número es solo para suscriptores y sus dependientes no están incluidos en este número. Por lo tanto, el rápido crecimiento de los suscriptores significa una gran cantidad de datos que administrar para Renegade. La empresa ha estado utilizando Microsoft Access como su sistema de gestión de datos. Renegade se da cuenta de las limitaciones de MS Access en la gestión de grandes cantidades de datos, ahora que tienen que lidiar con demandas agresivas. Por lo tanto, es imprescindible una actualización a sistemas de administración de datos más sofisticados. Después de algunas investigaciones, los principales gerentes comerciales decidieron convertir el sistema de administración de bases de datos a Oracle, que debería haber sido capaz de proporcionar flexibilidad, capacidad para administrar grandes cantidades de datos, capacidad de expansión. , e integridad referencial. EL PROYECTO Para responder a esta necesidad, Renegade inició un proyecto cuyo propósito era implementar: Base de datos Oracle con conectividad adecuada al sistema existente, y Transferencia segura de datos desde MS Access a Oracle Presupuesto del proyecto: $ 200,000 Duración del proyecto: 10 semanas El El departamento de farmacia (PD) fue el responsable del proyecto y su coste. El PD seleccionó a Robert Adam como director del proyecto ya Leila Rakoba como analista de negocios, ambos personas con mucha experiencia. Robert era la persona principal a cargo de cualquier problema/asunto/inquietud con respecto al proyecto. Fue responsable de todos los aspectos del proyecto, incluido el cronograma del proyecto, la matriz de desarrollo, el presupuesto y la escalada de problemas. Leila fue el principal punto de contacto para el usuario. Ella era responsable de recopilar todos los requisitos de los usuarios y documentarlos en el documento de requisitos comerciales. DESARROLLO DE SOFTWARE DE WATERFALL Como se mencionó, al igual que otros proyectos, este proyecto siguió el modelo de desarrollo de software de cascada. El proyecto debe completar cada fase y pasar por un recorrido final (FWT) antes de poder avanzar. El comité de recorrido formal por lo general implicaba la verificación de la finalización de la fase y presidía todas las aprobaciones. El comité estuvo integrado por gerentes de diferentes áreas funcionales. Robert también estuvo involucrado en el FWT, pero no era parte del comité. Por lo tanto, no se requirió su firma para la aprobación de la finalización de la fase. El propósito de la reunión de FWT era garantizar que los requisitos de especificación de la fase en particular se cumplieran y documentaran claramente. Los requisitos deben validarse y los criterios de salida deben cumplirse antes de que el proyecto pueda progresar. En otras palabras, el modelo en cascada creó una gestión de proyectos disciplinada y aseguró la idoneidad de las revisiones de documentación y diseño. Establece todos los requisitos, cronogramas y expectativas antes del inicio del proyecto. La figura 3.1 muestra un esquema preliminar que representa el proceso general del ciclo de vida del desarrollo de software en Renegade. FASE DE INICIACIÓN Como director del proyecto, Robert era responsable del desarrollo del documento de requisitos de recursos y el plan del proyecto. Para preparar estos documentos, necesitaba obtener ayuda de diferentes funciones. En particular, Robert necesitaba la ayuda del ingeniero de soluciones (SE), el analista de sistemas (SA), el desarrollador, el analista de pruebas (TA), el ingeniero de versiones (RE), el arquitecto de datos (DA) y el analista de bases de datos (DBA). Robert también necesitaba escribir un documento de matriz de desarrollo que consistiera en los entregables y los miembros responsables de los entregables. Además, necesitaba producir un documento de planificación de recursos que incluyera los roles y requisitos de los recursos. Por ejemplo, Robert solicitó al analista de base de datos que tuviera un mínimo de 3,5 años de experiencia laboral en campos relacionados y que poseyera buenos conocimientos técnicos de Oracle y MS Access. PRIMERA REUNIÓN FORMAL DE INSTRUCCIÓN Fue el 13 de noviembre de 2007, 10 días antes de la reunión inicial. El PD ya asignó todos los recursos necesarios y se los asignó a Robert para el proyecto. Era su responsabilidad utilizar los recursos de manera óptima de acuerdo con el cronograma y el presupuesto. Con la ayuda de Leila para facilitar y transmitir todos los requisitos del proyecto, la reunión seguramente saldría bien. El equipo estaba más que preparado. FASE DE PLANIFICACIÓN Como se esperaba, el equipo pasó la primera reunión de FWT y pasó a la fase de planificación. Robert y su equipo continuaron y comenzaron a diseñar el plan del proyecto. Pero cuando el equipo trabajó en el plan del proyecto durante una semana, surgió un conflicto. Fue entonces cuando Robert convocó una reunión de emergencia. REUNIÓN DE EMERGENCIA En la reunión, Robert no estaba muy emocionado de escuchar problemas o quejas de Luke, quien era el analista de sistemas. Robert sabía que Luke tenía mucha experiencia pero era terco y le gustaba hacer cambios de última hora. El rol del analista de sistemas era diseñar cómo implementar el sistema Oracle, y el desarrollador (Jason) y el ingeniero de soluciones (Jasmine) debían acordar el plan antes del próximo FWT. roberto: entonces, ¿qué está pasando? ¿Alguien podría explicarme qué está pasando? Jasmine: No pudimos ponernos de acuerdo sobre cómo manejar la conversión de bits de archivos planos. No estoy seguro si está familiarizado con el archivo plano. roberto: no, por favor explícate. Jasmine: Está bien, es más fácil si dibujo. (Consulte la Figura 3.2). Jasmine: El nuevo sistema debe poder recibir los 16 bits del sistema existente para garantizar que las fuentes de entrada no estén mal configuradas. Por lo tanto, el nuevo sistema debe programarse para manejarlo. El cuadro pequeño dentro del cuadro Implementación es el proceso de conversión que se integrará en la introducción de la nueva base de datos. Este bloque de conversión es el plan de Lucas y el punto de conflicto. Jason y yo nos oponemos, ya que está más allá del alcance y no forma parte del plan del proyecto. Luke: Robert, lo que sugiero es que este proceso de conversión satisfará la necesidad de implementar el proyecto y no llevará mucho tiempo desarrollar. No veo ninguna razón para hacer el trabajo más complejo de programar la nueva base de datos con capacidad de 16 bits. ¿Por qué romper una pared cuando puedes caminar alrededor de ella? Robert: Luke, me doy cuenta de la complejidad de programar la capacidad de base de datos de 16 bits, pero su solución sugiere un cambio de alcance. Una vez más, no podemos pasar más tiempo yendo y viniendo; Una vez que se establece el plan, debemos cumplirlo. Por lo tanto, rasca el plan de conversión. Cíñete al guión original. ¿Alguna pregunta? Luke: No tiene sentido que tengamos que reinventar la rueda. He aprendido mucho sobre este sistema durante el desarrollo de la integridad referencial (miles de tablas en la base de datos que se conectan a través de una clave o número de referencia específico). La conversión llevará 18 horas menos que desarrollar una interfaz de base de datos de 16 bits. Robert: Me doy cuenta y agradezco su entusiasmo, pero la documentación de requisitos de especificación indica que la nueva base de datos será de 16 bits capaz de interactuar con la entrada del archivo plano de 16 bits. Incluso con discusiones tras discusiones, Luke no parecía estar dispuesto a estar de acuerdo. Robert buscó a alguien que pudiera ayudar a resolver este problema. Luke era un analista de sistemas sénior y había estado presente por un tiempo. Le reportaba a un gerente más senior que no era de fácil acceso. Por lo tanto, Robert decidió hablar con su propio gerente, Steven, quien era el gerente del programa. Steven le envió a Luke un correo electrónico informándole de la dirección que debería tomar el proyecto y copiado al carbón del gerente de Luke. Robert se enteró al día siguiente de que Luke había cedido y que el proyecto avanzaba. Poco después, con algo de tensión sobrante todavía en la sala, la próxima reunión de FWT transcurrió sin problemas. El proyecto avanzó con éxito a la fase de implementación. NUEVO PROBLEMA Desde entonces, el proyecto había ido según lo planeado excepto hasta que llegó a la fase de prueba. Sam, el analista de pruebas, encontró una implementación incorrecta realizada durante la fase de desarrollo. Vino a consultar a Robert. Sam: Robert, no puedo continuar con la prueba. Está fallando para llenar la tabla y ejecutar los datos apropiados en las tablas de la base de datos. Ya le expliqué esto a Jason. Lo miró aproximadamente y estimó alrededor de una semana para solucionar el problema. Pero sabes que no tenemos una semana. ¿Podrías por favor hablar con él? Robert: ¿Cuándo hablaste con él sobre esto? Sam: Esta mañana. Ya le envié un correo electrónico y hablé con él dos veces. Me dijo que tiene que completar otra tarea de alta prioridad y luego puede entrar en esto. No puedo esperar más. Tengo que completar la prueba de aceptación del usuario y desarrollar los informes de prueba en dos días. Robert: Bueno, déjame manejar esto. Hablaré directamente con su gerente para acelerar las cosas. ¿Puedo usar tu teléfono? Robert tomó el teléfono e hizo una llamada al jefe de Jason, John, que era gerente de desarrollo. Roberto: Juan, este es Rob. Me gustaría que hablaras con Jason. Se trata de completar o corregir el código de implementación de Oracle que discutieron él y Sam. Realmente no nos queda mucho tiempo y no podemos retrasarlo más. Entiendo que está ocupado, pero el proyecto está en espera. Y este proyecto es fundamental para nuestra empresa, lo sabes. John: Oh, no estaba al tanto de esto. Déjame consultar con él y te responderé. Estoy seguro de que podría posponer lo que está haciendo ahora. Debe haber entendido mal la prioridad del proyecto. Yo lo manejaré. Poco después de que Robert colgó, Jason lo llamó y le informó que estaba listo para trabajar. Sorprendentemente, Jason solo tardó cinco horas en corregir el error. Ahora el proyecto pudo seguir adelante, sin embargo, estaba retrasado. En ese momento, Robert sabía que tendría que hacer muchas llamadas telefónicas y enviar varios correos electrónicos más para completar este proyecto.

1. ¿Cuáles son los pros y los contras de la metodología en cascada?