Gestión de proyectos de software

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

Historia

En los años 1970 y 1980, la industria del software creció muy rápidamente, ya que las empresas de computadoras reconocieron rápidamente el costo relativamente bajo de la producción de software en comparación con la producción de hardware y circuitos. Para gestionar los nuevos esfuerzos de desarrollo, las empresas aplicaron los métodos de gestión de proyectos establecidos, pero los cronogramas de los proyectos se retrasaron durante las pruebas, especialmente cuando se producía confusión en la zona gris entre las especificaciones del usuario y el software entregado. Para poder 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 ahora como el modelo en 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]

Participación insuficiente del usuario final
Mala comunicación entre clientes, desarrolladores, usuarios y gerentes de proyectos
Objetivos del proyecto poco realistas o no articulados
Estimaciones inexactas de los recursos necesarios
Requisitos y especificaciones del sistema mal definidos o incompletos
Informe deficiente sobre el estado del proyecto
Riesgos mal gestionados
Uso de tecnología inmadura
Incapacidad para manejar la complejidad del proyecto
Prácticas de desarrollo descuidadas
Políticas de las partes interesadas (por ejemplo, ausencia de apoyo ejecutivo o políticas entre el cliente y los usuarios finales)
Presiones comerciales

Los primeros cinco elementos de la lista anterior muestran las dificultades para articular las necesidades del cliente de tal manera que los recursos adecuados puedan alcanzar los objetivos adecuados del proyecto. Las herramientas específicas de gestión de proyectos de software son útiles y a menudo necesarias, pero el verdadero arte en la gestión de proyectos de software es aplicar el método correcto y luego utilizar herramientas para respaldar el método. Sin un método, las herramientas no sirven de nada. Desde la década de 1960, los fabricantes de software han desarrollado varios métodos de gestión de proyectos de software propietarios para su propio 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.

Proceso de desarrollo de software

Un proceso de desarrollo de software se ocupa principalmente del aspecto de producción del desarrollo de software , en contraposición al aspecto técnico, como las herramientas de software . Estos procesos existen principalmente para respaldar la gestión del desarrollo de software y, por lo general, están orientados a abordar cuestiones comerciales. Muchos procesos de desarrollo de software se pueden ejecutar de manera similar a los procesos generales de gestión de proyectos. Algunos ejemplos son:

Comunicación interpersonal y gestión y resolución de conflictos . La comunicación activa, frecuente y honesta es el factor más importante para aumentar la probabilidad de éxito del proyecto y mitigar los proyectos problemáticos. El equipo de desarrollo debe buscar la participación del usuario final y alentar la participación del usuario en el proceso de desarrollo. No tener usuarios involucrados puede llevar a una mala interpretación de los requisitos, insensibilidad a las necesidades cambiantes del cliente y expectativas poco realistas por parte del cliente. Los desarrolladores de software, los usuarios, los gerentes de proyectos, los clientes y los patrocinadores del proyecto necesitan comunicarse de manera regular y frecuente. La información obtenida de estas discusiones permite al equipo del proyecto analizar las fortalezas, debilidades, oportunidades y amenazas (FODA) y actuar en función de esa información para aprovechar las oportunidades y minimizar las amenazas. Incluso las malas noticias pueden ser buenas si se comunican relativamente temprano, porque los problemas se pueden mitigar si no se descubren demasiado tarde. Por ejemplo, una conversación informal con usuarios, miembros del equipo y otras partes interesadas a menudo puede sacar a la luz problemas potenciales antes que las reuniones formales. Todas las comunicaciones deben ser intelectualmente honestas y auténticas, y es necesario que se realicen críticas regulares, frecuentes y de alta calidad sobre el trabajo de desarrollo, siempre que se proporcionen de una manera tranquila, respetuosa, constructiva , sin acusaciones ni enojo. Las comunicaciones casuales frecuentes entre desarrolladores y usuarios finales, y entre gerentes de proyectos y clientes, son necesarias 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 eficaz y la gestión y resolución de conflictos son la clave para la gestión de proyectos de software. Ninguna metodología o estrategia de mejora de procesos puede superar los problemas graves en la comunicación o la mala gestión de los conflictos interpersonales. Además, los resultados asociados con dichas metodologías y estrategias de mejora de procesos se mejoran con una mejor comunicación. La comunicación debe centrarse en si el equipo entiende el estatuto del proyecto y si el equipo está avanzando hacia esa meta. Los usuarios finales, los desarrolladores de software y los gerentes de proyectos deben hacer con frecuencia las preguntas elementales y simples que ayudan a identificar los problemas antes de que se conviertan en desastres casi catastróficos. Si bien la participación del usuario final, la comunicación eficaz y el trabajo en equipo no son suficientes, son necesarios para garantizar un buen resultado, y su ausencia casi seguramente 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, evitar el riesgo, reducir el efecto negativo del riesgo y aceptar algunas o todas las consecuencias de un riesgo en particular. La gestión de riesgos en la gestión de proyectos de software comienza con el caso de negocio para iniciar el proyecto, que incluye un análisis de costo-beneficio , así como una lista de opciones de respaldo en caso de que el proyecto falle, denominada plan de contingencia .
- Un subconjunto de la gestión de riesgos es la gestión de oportunidades , que significa lo mismo, excepto que el resultado del riesgo potencial tendrá un impacto positivo, en lugar de negativo. Aunque teóricamente se maneja de la misma manera, usar el término "oportunidad" en lugar del término algo negativo "riesgo" ayuda a mantener a un equipo concentrado en los posibles resultados positivos de cualquier registro de riesgo dado 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 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; una vez identificados 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) y luego controlar los cambios y comunicarlos a las partes interesadas relevantes. El análisis del impacto de los cambios en el alcance nuevo o modificado, que incluye el análisis de requisitos a nivel de cambio, 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 modificados de un cliente; una vez identificados estos requisitos, están en condiciones de rediseñar o modificar una solución. En teoría, cada cambio puede afectar el cronograma y el presupuesto de un proyecto de software y, por lo tanto, por definición, debe incluir un análisis de riesgos y beneficios antes de la aprobación.
La gestión de la configuración del software es el proceso de identificar y documentar el alcance en sí, es decir, el producto de software en desarrollo, incluidos todos los subproductos y cambios, y permitir la comunicación de estos a las partes interesadas pertinentes. En general, los procesos empleados incluyen el control de versiones , la convención de nombres (programación) y los acuerdos de archivo de software.
La gestión de versiones es el proceso de identificar, documentar, priorizar y acordar versiones de software y luego controlar el cronograma de versiones y comunicarse con las partes interesadas relevantes. La mayoría de los proyectos de software tienen acceso a tres entornos de software en los que se puede publicar el software: desarrollo, prueba y producción. En proyectos muy grandes, donde los equipos distribuidos necesitan integrar su trabajo antes de lanzarlo a los usuarios, a menudo habrá más entornos para pruebas, llamados pruebas unitarias , pruebas del sistema o pruebas de integración , antes de lanzarlo 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 basándose en los datos que conocen, y los datos "reales" solo se encuentran en el entorno de software llamado "producción". Por lo tanto, para probar su trabajo, los programadores también deben crear a menudo "datos ficticios" o "stubs de datos". Tradicionalmente, se utilizaban versiones anteriores de un sistema de producción para este propósito, pero como 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 publiquen para los equipos de desarrollo. En entornos complejos, se pueden crear conjuntos de datos que luego se migran a través de entornos de prueba de acuerdo con un cronograma de lanzamiento de prueba, muy 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 de los clientes. Sin duda, encontrarán errores, podrán solicitar nuevas funciones y solicitar diferentes funcionalidades y más actualizaciones. Por lo tanto, todas estas solicitudes deben verificar y cumplir con los requisitos y la satisfacción de los clientes.

Planificación, ejecución, seguimiento y control de proyectos

El propósito de la planificación del proyecto es identificar el alcance del proyecto, estimar el trabajo involucrado y crear un cronograma del proyecto . La planificación del proyecto comienza con los requisitos que definen el software que se desarrollará. Luego, se desarrolla 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 del proyecto.

El objetivo del seguimiento y control del proyecto es mantener al equipo y a la dirección informados sobre el progreso del proyecto. Si el proyecto se desvía del plan, el director del proyecto puede tomar medidas para corregir el problema. El seguimiento y control del proyecto implica reuniones de estado para recabar información del equipo. Cuando es necesario realizar cambios, se utiliza el control de cambios para mantener los productos actualizados.

Asunto

En informática, el término "problema" es una unidad de trabajo para lograr una mejora en un sistema. ^[6] Un problema puede ser un error , una característica 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 ^[update], llamaron a su sistema Issue Tracker. ^{[ Necesita actualización ]}

Niveles de gravedad

Los problemas suelen clasificarse en términos de niveles de gravedad . Distintas empresas tienen distintas definiciones de gravedad, pero algunas de las más comunes son:

Alto: El error o problema afecta una parte crucial de un sistema y debe solucionarse para que vuelva a funcionar normalmente.
Medio: El error o problema afecta a una parte menor de un sistema, pero tiene algún impacto en su funcionamiento. Este nivel de gravedad se asigna cuando se ve afectado un requisito no central de un sistema.
Bajo/Fijo: El error o problema afecta a una parte menor de un sistema y tiene muy poco impacto en su funcionamiento. Este nivel de gravedad se asigna cuando se ve afectado un requisito no central de un sistema (y de menor importancia).
Trivial (cosmético, estético): El sistema funciona correctamente, pero la apariencia no coincide con la esperada. Por ejemplo: colores incorrectos, demasiado o muy poco espacio entre los contenidos, tamaños de fuente incorrectos, errores tipográficos, etc. Este es el problema de menor gravedad.

Gestión de problemas

En algunas implementaciones de procesos de desarrollo de software, los analistas de control de calidad investigan los problemas , verifican la corrección del sistema y luego asignan la tarea a un miembro del equipo de desarrollo para que resuelva el problema identificado. Los usuarios del sistema también pueden identificarlos durante la fase de pruebas de aceptación del usuario (UAT) .

Los problemas se pueden registrar y comunicar mediante sistemas de seguimiento de problemas o defectos . En ausencia de un sistema formal de seguimiento de problemas o defectos, es habitual utilizar cualquier forma de comunicación escrita, como correos electrónicos o mensajes instantáneos, para comunicar la existencia de un problema detectado.

Filosofía

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 fabricación , que puede ser realizada por alguien con habilidades de gestión, pero sin habilidades de programación. John C. Reynolds refuta esta opinión y sostiene que el desarrollo de software es completamente 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 . ^[7]

Referencias

^ ab Stellman, Andrew; Greene, Jennifer (2005). Gestión de proyectos de software aplicado. O'Reilly Media. ISBN 978-0-596-00948-9. Archivado desde el original el 9 de febrero de 2015.
^ "Por qué falla el software", en IEEE Spectrum
^ ab Producción de software de código abierto: cómo ejecutar con éxito un proyecto de software libre (libro electrónico, descargable gratuita), por Karl Fogel
^ ab Robert Frese y Vicki Sauter , "Cómo mejorar las probabilidades de éxito de un proyecto de software", IEEE Engineering Management Review , vol. 42, n.º 4, cuarto trimestre, diciembre de 2014
^ Philip Greenspun , en Fundadores en acción (2007), de Jessica Livingston , ISBN 1-59059-714-1
^ Dane, Bertram (2009). "La naturaleza social del seguimiento de problemas en la ingeniería de software" (PDF) . Archivado desde el original (PDF) el 8 de noviembre de 2016. Consultado el 7 de octubre de 2023 .
^ John C. Reynolds, Algunas reflexiones sobre la enseñanza de la programación y los lenguajes de programación , SIGPLAN Notices, Volumen 43, Número 11, noviembre de 2008, pág. 108: "Algunos sostienen que se puede gestionar la producción de software sin la capacidad de programar. Esta creencia parece surgir de la visión errónea de que la producción de software es una forma de fabricación. Pero la fabricación es la construcción repetida de objetos idénticos, mientras que la producción de software es la construcción de objetos únicos, es decir, todo el proceso es una forma de diseño. Como tal, se acerca más a la producción de un periódico [sic], de modo que un gerente de software que no sabe programar es similar a un editor jefe que no sabe escribir".

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 - Estándar 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.

Enlaces externos

Medios relacionados con 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 POSIBILIDADES DE ÉXITO?". Universidad de Missouri-St. Louis . Consultado el 13 de mayo de 2015 .