Capitulo 16 del libro de analisis y diseño de sistemas de Kendall y kendall

Capitulo 16 del libro de analisis y diseño de sistemas de Kendall y kendall

ESTUDIANDO PARA SU PRUEBA DE SISTEMAS

"Tenemos el tiempo encima. Tan sólo mira esta proyección", dice Lou

Scuntroll, el miembro más nuevo de su equipo de análisis de sistemas,

mientras le muestra el diagrama PERT que el equipo ha estado usando

para proyectar la fecha en que el nuevo sistema quedaría listo. "Quizá no

podamos cumplir la fecha prevista de julio para realizar las pruebas con

datos reales. Estamos atrasados tres semanas debido a que el equipo se

embarcó tarde."

Como uno de los analistas de sistemas que han vivido la presión de

fijar y reprogramar fechas límite en otros proyectos, usted intenta permanecer

tranquilo y evaluar cuidadosamente la situación antes de hablar.

Lentamente, usted plantea a Lou la posibilidad de postergar las

pruebas.

Lou contesta: "Si tratamos de retrasar las pruebas hasta las primeras

semanas de agosto, en esas fechas dos personas importantes de

contabilidad estarán de vacaciones". Lou está visiblemente molesto con

la posibilidad de retrasar la fecha límite.

Stan Dards, otro miembro reciente de su equipo de análisis de sistemas,

entra en la oficina de Lou. "Ambos tienen un aspecto pésimo. Todo

está bien, ¿no es cierto? No me reasignaron a programar una aplicación

de nómina, ¿o sí?"

A Lou no le hace gracia el sentido del humor de Stan ni su aparente

preocupación por sí mismo. "Todo estaba bien hasta antes de que llegaras.

Estábamos a punto de tomar algunas decisiones importantes sobre

el calendario." Lou le pasa a Stan el diagrama PERT para que lo revise.

"Observa la fecha de pruebas de julio. Como podrás darte cuenta, no hay

manera de cumplirla. ¿Alguna brillante idea?"

Stan contempla unos instantes el diagrama, luego señala: "Algo ha

pasado. Veamos aquí... quizá si movemos el módulo de contabilidad a..."

Lou lo interrumpe bruscamente: "¡No!, ya pensamos en eso, pero

Stanford y Binet, de contabilidad, están de vacaciones en agosto. Quizá

podríamos omitir esa parte de las pruebas. Ellos han sido muy cooperativos.

No creo que pongan ninguna objeción si sacamos los sistemas y

hacemos las pruebas ya que estemos en la fase de producción".

"Creo que ésa es una buena idea, Lou", coincide Stan, tratando de congraciarse

con Lou después de sus bromas anteriores. "No hemos tenido

ningún problema real con eso, y los programadores son confiables. Así podríamos

mantener el calendario con todo lo demás. Yo voto por no probar la

parte de contabilidad, y sólo darle un vistazo cuando se ponga en marcha."

Como el miembro con más experiencia del equipo, ¿qué puede usted

argumentar para convencer a Lou y Stan de la importancia de probar el

módulo de contabilidad con datos reales? ¿Qué pueden hacer los analistas

de sistemas para planificar sus actividades de tal manera que le dediquen

un tiempo razonable a realizar las pruebas con datos reales?

¿Cuáles son algunos de los posibles problemas que los miembros del

equipo podrían encontrar si no prueban el sistema completamente con

datos reales antes de poner el sistema en producción? ¿Hay en el proceso

de análisis y diseño de sistemas pasos que puedan omitirse con el

propósito de poner al día un proyecto retrasado?

...