Romero-Romero, A. & López-Botello, F. (2020). Acompañamiento Docente en Proyectos Informáticos de Desarrollo de Software para el Usuario Final en una
Institución de Educación Superior . Revista Tecnológica-Educativa Docentes 2.0, 9(2), 212-222. https://doi.org/10.37843/rted.v9i2.166
Acompañamiento Docente en Proyectos Informáticos de
Desarrollo de Software para el Usuario Final en una
Institución de Educación Superior.
por encima del presupuesto sobre el tiempo no
necesariamente es un fracaso, sino depende del
enfoque. Humphrey (2005) considera exitoso, aquel
completado entre el 10 % más o menos de lo acordado
en costo, en tiempo, además se proporcionó bajo
funcionalidades acordadas; de lo contrario cuando no
se entregó nada es considerado un fracaso. The
Standish Group dice, es exitoso si es completado en
tiempo, presupuesto, además con todas sus
características, así como funciones specificadas (The
Standish Group, 1994).
Humphrey (2005), también otros autores como
Standish Group mencionan otra clasificación
intermedia entre un exitoso y fracasado, a los llamados
desafiantes (challenged projects) esta clasificación
establece que fueron terminados severamente tarde o
por encima del presupuesto establecido o tienen
funciones muy reducidas. Para Standish Group, este
tipo fueron completados, funcionaron, pero
sobrepasaron el presupuesto, además el tiempo
estimado; ofrecieron solo algunas características,
también pocas funciones originalmente especificadas.
Para Charette (2006) los fracasos forman parte
de la competitividad en los negocios y es esperado su
acontecimiento. Si no se falla lo suficiente ahora,
entonces probablemente no está haciendo nada por
competir. Explica respecto a fallar correctamente, lo
cual significa una organización tendiente a tomar
riesgos adecuados, consciente de esos riesgos, pero
también consciente a mitigarlos. Cuando se aprende
de los fracasos, pueden convertirse en el progreso.
Al seguir correctamente una administración de
procesos, probablemente resulte exitoso al final,
Horine (2013) menciona desde un punto de vista
académico, además utópico la definición de un
proyecto exitoso, como los entregables prometidos,
completados en tiempo dentro del presupuesto, donde
todos los entregables cumplen con especificaciones de
rendimiento, calidad, cumpliendo con propósito,
objetivos originales, expectativas de los interesados y
relaciones de ganar-ganar.
Respecto a los fracasos en procesos
informáticos según Markus (como se citó en Ruiz,
2004) el fracaso de software es bastante limitado,
considera los fracasos de manera genérica como
“fallas” (p. 43). También considera a los fracasos,
factores fuera de control del administrador del
proyecto, así como del equipo (p.46). Se identifica
como causas origen “carencia de compromiso del
personal de ventas, mal entendimiento de quienes eran
los clientes reales, conflicto entre necesidades del
cliente desconocidas por equipo de diseño, falta de
un staff calificado, alta rotación del staff y lo
referente a percepción negativa que los usuarios
tienen de su departamento de informática" (Ruiz,
2004, p. 90).
Pereira, Cerpa & Rivas (2004), los fracasos en
proceso de software son problemas con la
estimación, programación de actividades y
coherencia entre requerimientos, También fallas en:
comunicación con el cliente/usuario, estructura
organizacional, liderazgo, apoyo del nivel gerencial,
esfuerzo, choques de personalidades; uso inefectivo
respecto a métodos en desarrollo de software,
procesos de negocios, recursos inapropiados, gestión
de diseños y herramientas de seguimiento
inadecuados.
El término "fracaso", según Charette (2006)
debe reservarse a proyectos con una buena
oportunidad de éxito administrados
profesionalmente, por lo anterior, todo lo demás
debe ser etiquetado como equivocaciones. En otras
palabras, una organización, además de las partes
interesadas saben en qué están trabajando, hacen
todo para aumentar sus posibilidades de éxito dadas
las limitaciones. Las tasas de fracasos en los
procesos de IT dependen del tamaño, mientras más
grande sea, mayor probabilidad al fracaso (Hidding
& Nicholas, 2009). Humphrey (2005) menciona un
proyecto de software a gran escala es inherentemente
inmanejable, además tiene más probabilidad de
fracasar.
El problema de visibilidad de un administrador
de diseño en cierto momento no se puede decir
dónde está, debido a que la información muchas
veces no es visible, esto es, mientras los
desarrolladores pueden superar pequeños problemas
presentados, estos problemas agregan cargas de
trabajo, así como retardos, pero con el tiempo los
problemas aumentan poco a poco y tarde o temprano
el proyecto enfrenta serios problemas no observados
con anticipación. En procesos muy grandes de
software, los administradores no ven los retrasos
hasta ser muy grandes, también obvios, siendo
demasiado tarde para hacer algo al respecto
(Humphrey, 2005).
Otro termino importante es cancelados,
Boehm (2001) lo considera un diseño fracasado,
falso, también peligroso. Hay varias acepciones de
cancelado las cuales son, cuando una gran