gestión de proyectos de software

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

Historia

En las décadas de 1970 y 1980, la industria del software creció muy rápidamente, ya que las empresas de informática reconocieron rápidamente el costo relativamente bajo de la producción de software en comparación con la producción de hardware y los circuitos. Para gestionar nuevos esfuerzos de desarrollo, las empresas aplicaron los métodos de gestión de proyectos establecidos, pero los cronogramas de los proyectos fallaron durante las ejecuciones de prueba, especialmente cuando se produjo 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 modelo en cascada .

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

Insuficiente participación del usuario final
Mala comunicación entre clientes, desarrolladores, usuarios y directores 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
Informes deficientes 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ítica de las partes interesadas (por ejemplo, ausencia de apoyo ejecutivo o política 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 que respalden el método. Sin un método, las herramientas no valen nada. Desde la década de 1960, los fabricantes de software han desarrollado varios métodos de gestión de proyectos de software propietario 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 todavía están 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 , a diferencia del 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 sesgados hacia la solución de inquietudes comerciales. Muchos procesos de desarrollo de software se pueden ejecutar de manera similar a los procesos generales de gestión de proyectos. 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 proyectos problemáticos. El equipo de desarrollo debe buscar la participación del usuario final y fomentar sus aportaciones 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 del cliente. Los desarrolladores de software, usuarios, directores de proyectos, clientes y patrocinadores de proyectos necesitan comunicarse de forma 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 sobre esa información para beneficiarse de las oportunidades y minimizar las amenazas. Incluso las malas noticias pueden ser buenas si se comunican relativamente pronto, porque los problemas pueden mitigarse si no se descubren demasiado tarde. Por ejemplo, una conversación informal con usuarios, miembros del equipo y otras partes interesadas a menudo puede revelar problemas potenciales antes que las reuniones formales. Todas las comunicaciones deben ser intelectualmente honestas y auténticas, 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. Son necesarias comunicaciones informales frecuentes entre desarrolladores y usuarios finales, y entre gerentes de proyecto y clientes, 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 problemas graves de comunicación o mala gestión de conflictos interpersonales. Además, los resultados asociados con dichas metodologías y estrategias de mejora de procesos mejoran con una mejor comunicación. La comunicación debe centrarse en si el equipo comprende los estatutos del proyecto y si está avanzando hacia ese objetivo. Los usuarios finales, los desarrolladores de software y los directores de proyectos deben formular con frecuencia preguntas elementales y sencillas que ayudan a identificar los problemas antes de que se agraven hasta convertirse en un desastre. 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 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 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 alternativas en caso de fracaso del proyecto, llamado 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 potencial del riesgo 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 al equipo enfocado en 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 los cambios y comunicarlos 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 analistas de negocios o desarrolladores de software identifican las necesidades o requerimientos de un cliente; Una vez identificados estos requisitos, estará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 del cambio de 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 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 riesgo-beneficio antes de su aprobación.
La gestión de la configuración del software es el proceso de identificar y documentar el alcance en sí, cuál es el producto de software en curso, incluidos todos los subproductos y cambios, y permitir la comunicación de estos a las partes interesadas relevantes. En general, los procesos empleados incluyen control de versiones , convención de nomenclatura (programación) y acuerdos de archivo de software.
La gestión de lanzamientos es el proceso de identificar, documentar, priorizar y acordar lanzamientos de software y luego controlar el cronograma de lanzamientos y comunicarlo a las partes interesadas relevantes. La mayoría de los proyectos de software tienen acceso a tres entornos de software en los que se puede lanzar 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 realizar pruebas, llamados 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 sólo pueden realizar pruebas basándose en datos que conocen, y los datos "reales" sólo se encuentran en el entorno de software llamado "producción". Por lo tanto, para probar su trabajo, los programadores a menudo también deben crear "datos ficticios" o "resguardos de datos". Tradicionalmente, antes 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 de acuerdo con un cronograma de lanzamiento de prueba, muy parecido al cronograma general de lanzamiento de software.
El mantenimiento y actualización es el proceso donde siempre intervienen los requisitos y las necesidades del cliente. Sin duda encontrarán errores, pueden solicitar nuevas funciones y solicitar funciones diferentes y más actualizaciones. Por lo tanto, todas estas solicitudes deben verificar y cumplir con los requisitos y la satisfacción del cliente.

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 a 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 actualizados sobre el avance del proyecto. Si el proyecto se desvía del plan, entonces el director del proyecto puede tomar medidas para corregir el problema. El seguimiento y control del proyecto implica reuniones de estado para recopilar el estado 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 podría 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], llaman a su sistema Issue Tracker. ^{[ necesita actualización ]}

Niveles de gravedad

Los problemas suelen clasificarse en términos de niveles de gravedad . Diferentes empresas tienen diferentes 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 reanude el funcionamiento normal.
Medio: El error o problema afecta una parte menor de un sistema, pero tiene cierto 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 severidad se asigna cuando un requerimiento no central de un sistema (y de menor importancia) se ve afectado.
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 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, se verifica la corrección del sistema y luego se asigna nuevamente a un miembro del equipo de desarrollo para resolver el problema identificado. También pueden ser identificados por los usuarios del sistema durante la fase de Prueba 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 común utilizar simplemente cualquier forma de comunicación escrita, como correos electrónicos o mensajes instantáneos, para comunicar la existencia de un problema encontrado.

Filosofía

Como una subdisciplina de la gestión de proyectos, algunos consideran la gestión del desarrollo de software 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 este punto de vista y sostiene que el desarrollo de software es enteramente un trabajo de diseño , y compara a un gerente que no sabe programar con el editor en jefe de un periódico que no sabe escribir . ^[7]

Referencias

^ ab Stellman, Andrew; Greene, Jennifer (2005). Gestión de Proyectos de Software Aplicado. Medios O'Reilly. 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 un proyecto de software libre exitoso (libro electrónico, descargable gratuitamente), por Karl Fogel
^ ab Robert Frese y Vicki Sauter , "Mejorar sus probabilidades de éxito en proyectos de software", IEEE Engineering Management Review , vol. 42, No. 4, cuarto trimestre, diciembre de 2014
^ Philip Greenspun , en Fundadores en el trabajo de Jessica Livingston (2007), ISBN 1-59059-714-1
^ Danés, 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 , Avisos SIGPLAN , Volumen 43, Número 11, noviembre de 2008, p.108: "Algunos argumentan que uno puede gestionar la producción de software sin la capacidad de programar. Esta creencia parece Surgen 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. a la producción de un periódico [sic], de modo que un administrador de software que no sabe programar es similar a un editor en 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 . Publicación J. Ross. ISBN 978-1-60427-034-1.

enlaces externos

Medios relacionados con la gestión de proyectos de software en Wikimedia Commons

fracaso del proyecto

Robert Frese (16 de diciembre de 2003). "ÉXITO Y FRACASO DEL PROYECTO: ¿QUÉ ES EL ÉXITO, QUÉ ES EL FRACASO Y CÓMO PUEDES MEJORAR TUS PROBABILIDADES DE ÉXITO?". Universidad de Missouri-St. Luis . Consultado el 13 de mayo de 2015 .