Reto 3.
Prácticas y estánd
21-7-2025
Gestión de proyectos de tecnologías de informaci
Marco Antonio Torres Sixtos
Asesor:
22007230
Francisco Javier Hernández
Palero
Caso 1
La empresa SmarIT Solutions está a cargo de varios proyectos que brindan soluciones de
tecnologías de información a diversos clientes. Uno de ellos ha solicitado sus servicios para un
proyecto en el que se necesita la adquisición de al menos una computadora que cumpla con los
siguientes requerimientos:
• Capacidad de almacenamiento: 1 TB.
• Tamaño de la pantalla: 27 pulgadas.
• Memoria RAM: 16 GB.
• Procesador: Intel Core i7 11ª generación.
Quien administra el proyecto debe tomar la decisión entre invertir en una computadora de
escritorio nueva (de marca) o armarla. Para eso, necesita calcular el TCO de ambas opciones y
elegir en cuál invertir.
Conclusión:
La opción con menor TCO es la computadora armada ($3,800), por lo tanto, es la mejor opción
para invertir, aunque dentro de lo que cabe es mejor asegurar que las piezas con las que se va a
armar el equipo sean nuevas (luego se les ocurre meter algo de 2da mano XD).
Caso 2
La empresa SmarIT Solutions debe decidir si le conviene invertir en un nuevo proyecto de software
que un cliente le está solicitando, por el cual planea pagarle $200,000. Estos son algunos de los
datos de costos que se han recopilado:
• Costos materiales: $20,000
• Pagos a personal de trabajo: $150,000
• Compra de software: $10,000
• Compra de hardware: $30,000
• Renta de oficinas: $15,000
• Costos de luz y agua: $13,000
Conclusión:
La inversión no es rentable, ya que el ROI es negativo (–15.97%), por lo tanto, la decisión correcta
sería NO INVERTIR.
Reflexiones
Sobre TCO y ROI
Cuando se trata de tomar decisiones en un proyecto de software, es muy importante no
quedarnos solo con el precio inicial de un producto o servicio (creo que en cualquier campo
siempre tenemos que buscar precio – beneficio). Por eso, herramientas como el TCO y el ROI son
tan útiles. El TCO nos ayuda a ver cuánto nos va a costar realmente algo a lo largo del tiempo, no
solo lo que pagamos al principio. Incluye cosas como mantenimiento, operación y otros gastos que
a veces no se ven de inmediato. Por otro lado, el ROI nos dice si vale la pena invertir o no,
comparando lo que vamos a ganar con lo que vamos a gastar (más para cuando te esforzaste por
ahorrar ese capital lo que menos se quiere es arriesgar demasiado). Usar estos cálculos nos
permite tomar decisiones más inteligentes, evitar pérdidas y aprovechar mejor los recursos en
cualquier proyecto de software.
Sobre el estándar de calidad más indispensable para mi
En mi experiencia estudiando y participando en proyectos de desarrollo de software, he aprendido
que hay muchos aspectos que se deben cuidar para lograr un producto de calidad. Si tuviera que
elegir un estándar que considero indispensable, sería sin duda el ISO/IEC 25010. Este estándar me
parece fundamental porque no se enfoca únicamente en que el software funcione, sino en que sea
seguro, confiable, fácil de usar, sustentable y eficiente.
Hoy en día, los usuarios no solo esperan que una aplicación o sistema “haga lo que debe hacer”,
sino que además sea rápido, intuitivo y no falle fácilmente (los usuarios desconocen todas las
dificultades por las que se pasa para desarrollar desde una infraestructura o un software). Y en ese
sentido, este estándar nos da una guía muy clara sobre qué aspectos tomar en cuenta desde el
inicio del proyecto, esto para no tener que corregir errores costosos más adelante. También ayuda
a mantener una buena imagen ante los clientes, ya que demuestra un compromiso total con la
calidad y el cliente.
Por ejemplo, si estás desarrollando un sistema para una institución financiera, no basta con que
permita hacer transferencias o pagos. Debe garantizar la seguridad de los datos, evitar caídas del
sistema y ofrecer una buena experiencia al usuario. Todo eso está cubierto por ISO/IEC 25010. Por
eso, creo que este estándar no puede faltar en ningún proyecto de software serio. Aplicarlo desde
el inicio ayuda a prevenir muchos problemas y garantiza que el producto final cumpla con las
expectativas tanto del equipo como de los usuarios.
Sobre metodologías tradicional y ágil
Algo que he aprendido en estos años es que no existe una única forma de desarrollar software,
planear infraestructura TI y OT, adquirir software, entre otras actividades de TI es que cada
proyecto tiene sus propias necesidades. Por eso, me parece muy valioso poder combinar lo mejor
de una metodología tradicional con lo mejor de una metodología ágil, dependiendo del tipo de
proyecto que se esté llevando a cabo.
Por la parte de lo tradicional, me gusta mucho el enfoque del modelo en espiral, porque permite
avanzar por etapas, pero haciendo una revisión constante de riesgos y mejoras. Este modelo es
ideal cuando el proyecto es complejo o involucra muchas áreas críticas. Por ejemplo, si tuviera que
trabajar en el desarrollo de un sistema para la gestión de emergencias en hospitales, no me
arriesgaría con una metodología muy ágil, porque aquí es clave que todo esté bien documentado y
probado antes de implementarlo. La espiral me permitiría trabajar por ciclos, detectar fallos o
ajustes en cada vuelta, y reducir el riesgo de errores graves.
Ahora bien, si hablamos de un proyecto más cambiante o con usuarios que quieren ver avances
rápidos, entonces sin duda usaría una metodología ágil como Scrum. Me gusta porque está
pensada para ir entregando partes funcionales del software en poco tiempo, lo que permite recibir
retroalimentación constante del cliente y hacer mejoras sobre la marcha. Por ejemplo, si estoy
desarrollando una app para organizar tareas personales, usar Scrum me ayudaría a lanzar primero
una versión básica, y después ir agregando funciones nuevas como recordatorios o sincronización
con el calendario, según lo que los usuarios vayan pidiendo.
En resumen, el modelo en espiral lo usaría cuando se necesita seguridad y análisis detallado, y
Scrum cuando el proyecto requiere flexibilidad y entregas rápidas. Lo importante es saber
adaptarse y elegir bien según las características del proyecto. No se trata de usar una sola
metodología para todo, sino de entender al cliente desde las necesidades reales y aplicar la mejor
estrategia posible.
Referencias
Corona Treviño, L. M., & Mendoza Morales, R. A. (2017).
Administración de proyectos de tecnologías de información. McGraw-Hill Interamericana.
González, J. J., & Mora, M. (2015).
Calidad del software: Fundamentos y estándares internacionales. Universidad Autónoma
de Aguascalientes.
Soto Gómez, M. A., & Martínez García, A. (2018).
Metodologías ágiles y tradicionales en proyectos de software: Un enfoque práctico.
Instituto Politécnico Nacional.
