Gestión de proyectos de software

La gestión de proyectos de software es el proceso de planificar y dirigir proyectos de software. ^{[ 1 ]} Es una subdisciplina de la gestión de proyectos en la que los proyectos de software se planifican, implementan, supervisan y controlan.

En las décadas de 1970 y 1980, la industria del software experimentó un rápido crecimiento, ya que las empresas informáticas pronto reconocieron el coste relativamente bajo de la producción de software en comparación con la producción de hardware y circuitos. Para gestionar los nuevos proyectos de desarrollo, las empresas aplicaron los métodos de gestión de proyectos establecidos, pero los plazos de los proyectos se retrasaban durante las pruebas, especialmente cuando surgía confusión en la zona gris entre las especificaciones del usuario y el software entregado. Para evitar estos problemas, los métodos de gestión de proyectos de software se centraron en hacer coincidir los requisitos del usuario con los productos entregados, en un método conocido actualmente como el modelo de cascada .

A medida que la industria ha madurado, el análisis de los fallos en la gestión de proyectos de software ha demostrado que las siguientes son las causas más comunes: ^{[ 2 ] [ 3 ] [ 4 ]}

1. Participación insuficiente del usuario final
2. Mala comunicación entre clientes, desarrolladores, usuarios y gerentes de proyecto.
3. Objetivos del proyecto poco realistas o no definidos.
4. Estimaciones inexactas de los recursos necesarios
5. Requisitos y especificaciones del sistema mal definidos o incompletos
6. Informes deficientes sobre el estado del proyecto
7. Riesgos mal gestionados
8. Uso de tecnología inmadura
9. Incapacidad para manejar la complejidad del proyecto.
10. Prácticas de desarrollo descuidadas
11. Política de las partes interesadas (por ejemplo, ausencia de apoyo ejecutivo o política entre el cliente y los usuarios finales).
12. presiones comerciales

Los primeros cinco puntos de la lista anterior muestran las dificultades para articular las necesidades del cliente de manera que los recursos adecuados permitan alcanzar los objetivos del proyecto. Las herramientas específicas de gestión de proyectos de software son útiles y a menudo necesarias, pero el verdadero arte de la gestión de proyectos de software reside en aplicar el método correcto y luego utilizar herramientas que lo respalden. Sin un método, las herramientas son inútiles. Desde la década de 1960, los fabricantes de software han desarrollado varios métodos de gestión de proyectos de software propios para su uso, mientras que las empresas de consultoría informática también han desarrollado métodos similares para sus clientes. Hoy en día, los métodos de gestión de proyectos de software siguen evolucionando, pero la tendencia actual se aleja del modelo en cascada hacia un modelo de entrega de proyectos más cíclico que imita un proceso de desarrollo de software.

Un proceso de desarrollo de software se centra principalmente en el aspecto de producción , a diferencia del aspecto técnico, como las herramientas de software . Estos procesos existen principalmente para apoyar la gestión del desarrollo de software y, por lo general, están orientados a abordar las necesidades del negocio. Muchos procesos de desarrollo de software pueden ejecutarse de forma similar a los procesos generales de gestión de proyectos. Algunos ejemplos son:

• Comunicación interpersonal y gestión y resolución de conflictos . Una comunicación activa, frecuente y honesta es el factor más importante para aumentar la probabilidad de éxito del proyecto y mitigar los problemas. El equipo de desarrollo debe buscar la participación del usuario final y fomentar su aporte en el proceso de desarrollo. No involucrar a los usuarios puede llevar a una mala interpretación de los requisitos, insensibilidad a las necesidades cambiantes del cliente y expectativas poco realistas por parte de este. Los desarrolladores de software, los usuarios, los gerentes de proyecto, los clientes y los patrocinadores del proyecto deben comunicarse de forma regular y frecuente. La información obtenida de estas conversaciones permite al equipo del proyecto analizar las fortalezas, debilidades, oportunidades y amenazas (FODA) y actuar en consecuencia para aprovechar las oportunidades y minimizar las amenazas. Incluso las malas noticias pueden ser buenas si se comunican relativamente pronto, ya que los problemas pueden mitigarse si no se descubren demasiado tarde. Por ejemplo, las conversaciones informales con los usuarios, los miembros del equipo y otras partes interesadas a menudo pueden revelar problemas potenciales antes que las reuniones formales. Toda comunicación debe ser intelectualmente honesta y auténtica, y es necesaria una crítica regular, frecuente y de alta calidad del trabajo de desarrollo, siempre que se proporcione de manera tranquila, respetuosa, constructiva , sin acusaciones ni enojo. La comunicación informal frecuente entre desarrolladores y usuarios finales, y entre gerentes de proyecto y clientes, es necesaria para mantener el proyecto relevante, útil y efectivo para los usuarios finales, y dentro de los límites de lo que se puede completar. La comunicación interpersonal efectiva y la gestión y resolución de conflictos son clave para la gestión de proyectos de software. Ninguna metodología o estrategia de mejora de procesos puede superar problemas graves de comunicación o la mala gestión de conflictos interpersonales. Además, los resultados asociados con dichas metodologías y estrategias de mejora de procesos se potencian con una mejor comunicación. La comunicación debe centrarse en si el equipo comprende el acta constitutiva del proyecto y si está progresando hacia ese objetivo. Los usuarios finales, los desarrolladores de software y los gerentes de proyecto deben hacer con frecuencia las preguntas elementales y sencillas que ayudan a identificar problemas antes de que se conviertan en desastres. Si bien la participación del usuario final, la comunicación efectiva y el trabajo en equipo no son suficientes, son necesarios para garantizar un buen resultado, y su ausencia casi con seguridad conducirá a un mal resultado. ^{[ 3 ] [ 4 ] [ 5 ]}
• La gestión de riesgos es el proceso de medir o evaluar el riesgo y luego desarrollar estrategias para gestionarlo. En general, las estrategias empleadas incluyen transferir el riesgo a otra parte, evitarlo, reducir su impacto negativo y aceptar algunas o todas sus consecuencias. La gestión de riesgos en la gestión de proyectos de software comienza con el análisis de viabilidad del proyecto, que incluye un análisis de costo-beneficio y una lista de alternativas en caso de fallo del proyecto, denominada plan de contingencia .
  • Una subdisciplina de la gestión de riesgos es la gestión de oportunidades , que significa lo mismo, con la diferencia de que el resultado potencial del riesgo tendrá un impacto positivo, en lugar de negativo. Si bien teóricamente se manejan de la misma manera, usar el término "oportunidad" en lugar del término algo negativo "riesgo" ayuda a que el equipo se centre en los posibles resultados positivos de cualquier riesgo registrado en sus proyectos, como proyectos derivados, ganancias inesperadas y recursos adicionales gratuitos.
• La gestión de requisitos es el proceso de identificar, obtener , documentar, analizar, rastrear , priorizar y acordar los requisitos y luego controlar el cambio y comunicarlo a las partes interesadas relevantes. Sistema informático nuevo o modificado ^{[ 1 ]} La gestión de requisitos, que incluye el análisis de requisitos , es una parte importante del proceso de ingeniería de software ; mediante el cual los analistas de negocios o los desarrolladores de software identifican las necesidades o requisitos de un cliente; habiendo identificado estos requisitos, están en condiciones de diseñar una solución.
• La gestión de cambios es el proceso de identificar, documentar, analizar, priorizar y acordar cambios en el alcance (gestión de proyectos), así como controlar dichos cambios y comunicarlos a las partes interesadas pertinentes. El análisis del impacto de los cambios en el alcance, que incluye el análisis de requisitos a nivel de cambio, es una parte importante del proceso de ingeniería de software . En este proceso, los analistas de negocio o los desarrolladores de software identifican las necesidades o requisitos modificados de un cliente; una vez identificados estos requisitos, pueden rediseñar o modificar una solución. En teoría, cada cambio puede afectar el cronograma y el presupuesto de un proyecto de software, por lo que, por definición, debe incluir un análisis de riesgo-beneficio antes de su aprobación.
• La gestión de la configuración del software consiste en identificar y documentar el alcance del producto de software en desarrollo, incluyendo todos los subproductos y cambios, y facilitar su comunicación a las partes interesadas pertinentes. En general, los procesos empleados incluyen el control de versiones , las convenciones de nomenclatura (de programación) y los acuerdos de archivo de software.
• La gestión de versiones es el proceso de identificar, documentar, priorizar y acordar las versiones de software, así como controlar el cronograma de lanzamiento y comunicarlo a las partes interesadas. La mayoría de los proyectos de software tienen acceso a tres entornos de software donde se puede lanzar el software: Desarrollo, Pruebas y Producción. En proyectos muy grandes, donde los equipos distribuidos necesitan integrar su trabajo antes del lanzamiento a los usuarios, a menudo habrá más entornos para realizar pruebas, denominadas pruebas unitarias , pruebas de sistema o pruebas de integración , antes del lanzamiento a las pruebas de aceptación del usuario (UAT).
  • Un subconjunto de la gestión de versiones que está ganando atención es la gestión de datos , ya que, obviamente, los usuarios solo pueden realizar pruebas con datos que conocen, y los datos "reales" solo se encuentran en el entorno de software denominado "producción". Para probar su trabajo, los programadores a menudo deben crear "datos ficticios" o "datos de prueba". Tradicionalmente, se utilizaban versiones anteriores de un sistema de producción para este propósito, pero a medida que las empresas dependen cada vez más de colaboradores externos para el desarrollo de software, es posible que los datos de la empresa no se entreguen a los equipos de desarrollo. En entornos complejos, se pueden crear conjuntos de datos que luego se migran entre entornos de prueba según un cronograma de lanzamiento de prueba, similar al cronograma general de lanzamiento de software.
• El mantenimiento y la actualización son procesos en los que siempre intervienen los requisitos y las necesidades del cliente. Sin duda, encontrarán errores, solicitarán nuevas funciones y pedirán diferentes funcionalidades y más actualizaciones. Por lo tanto, es necesario revisar todas estas solicitudes y satisfacer los requisitos y la satisfacción del cliente.

El objetivo de la planificación de proyectos es identificar el alcance del proyecto, estimar el trabajo necesario y crear un cronograma . La planificación comienza con los requisitos que definen el software a desarrollar. A continuación, se elabora el plan del proyecto para describir las tareas que conducirán a su finalización. La ejecución del proyecto es el proceso de completar las tareas definidas en el plan.

El objetivo del seguimiento y control de proyectos es mantener al equipo y a la gerencia al tanto del progreso del proyecto. Si el proyecto se desvía del plan, el gerente de proyecto puede tomar medidas para corregir el problema. El seguimiento y control de proyectos incluye reuniones de estado para obtener información del equipo. Cuando se requieren cambios, se utiliza el control de cambios para mantener los productos actualizados.

En informática, el término "problema" es una unidad de trabajo para lograr una mejora en un sistema. ^{[ 6 ]} Un problema podría ser un error , una función solicitada , una tarea, documentación faltante , etc.

Por ejemplo, OpenOffice.org solía llamar a su versión modificada de Bugzilla IssueZilla. A partir de septiembre de 2010, llaman a su sistema Rastreador de Incidencias. ^{[ 7 ]}

Como subdisciplina de la gestión de proyectos, algunos consideran que la gestión del desarrollo de software es similar a la gestión de la producción , que puede ser realizada por alguien con habilidades de gestión, pero sin habilidades de programación. John C. Reynolds refuta esta visión y argumenta que el desarrollo de software es enteramente un trabajo de diseño , y compara a un gerente que no sabe programar con el editor jefe de un periódico que no sabe escribir . ^{[ 12 ]}

General

• 16326:2019(E) - Norma internacional ISO/IEC/IEEE - Ingeniería de sistemas y software - Procesos del ciclo de vida - Gestión de proyectos . 2019. doi : 10.1109/IEEESTD.2019.8932690 . ISBN 978-1-5044-6299-0.
• 1058-1998 - Norma IEEE para planes de gestión de proyectos de software . 1998. doi : 10.1109/IEEESTD.1998.88822 . ISBN 978-0-7381-1448-4.
• Jalote, Pankaj (2002). Gestión de proyectos de software en la práctica . Addison-Wesley. ISBN 0-201-73721-3.
• Murali Chemuturi, Thomas M. Cagley Jr. y (2010). Gestión de proyectos de software: mejores prácticas, herramientas y técnicas . J. Ross Publishing. ISBN 978-1-60427-034-1.

• Contenido multimedia relacionado con la gestión de proyectos de software en Wikimedia Commons.

• Robert Frese (16 de diciembre de 2003). "ÉXITO Y FRACASO DE PROYECTOS: ¿QUÉ ES EL ÉXITO, QUÉ ES EL FRACASO Y CÓMO PUEDE MEJORAR SUS PROBABILIDADES DE ÉXITO?" . Universidad de Missouri-St. Louis . Recuperado el 13 de mayo de 2015 .