La gestión de proyectos de software es un arte y una ciencia de planificar y liderar 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.
Historia
En las décadas de 1970 y 1980, la industria del software creció muy rápidamente, ya que las empresas informáticas 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 los nuevos esfuerzos de desarrollo, las empresas aplicaron los métodos de gestión de proyectos establecidos, pero los cronogramas de los proyectos se deslizaron durante las pruebas, 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]
- Participación insuficiente del usuario final
- Mala comunicación entre clientes, desarrolladores, usuarios y directores de proyectos.
- Metas del proyecto poco realistas o desarticuladas
- Estimaciones inexactas de los recursos necesarios
- Requisitos y especificaciones del sistema mal definidos o incompletos
- Informe deficiente del 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 entregar 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 usar herramientas para respaldar 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 , 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 sesgados hacia el tratamiento de las preocupaciones 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 manejo 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, usuarios, gerentes de proyectos, clientes y patrocinadores de proyectos deben comunicarse con regularidad y frecuencia. 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 casual con usuarios, miembros del equipo y otras partes interesadas a menudo puede hacer surgir 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 brinde de manera calmada, respetuosa, constructiva , no acusatoria y sin enojo. Las comunicaciones casuales frecuentes entre los desarrolladores y los usuarios finales, y entre los gerentes de proyecto y los clientes, son necesarias para mantener el proyecto relevante, útil y eficaz 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 serios en la comunicación o la mala gestión de los conflictos interpersonales. Además, los resultados asociados con tales metodologías y estrategias de mejora de procesos se mejoran con una mejor comunicación. La comunicación debe centrarse en si el equipo comprende los estatutos del proyecto y si el equipo está progresando hacia ese objetivo. 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 casi desastres. 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 gestionar el riesgo. 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 para el 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 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 al equipo enfocado 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 los requisitos y luego controlar el cambio y comunicarse con 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 comerciales 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 comunicarse con las partes interesadas relevantes. El análisis del impacto del cambio de alcance nuevo o modificado, que incluye el análisis de requisitos en el nivel de cambio, es una parte importante del proceso de ingeniería de software ; mediante el cual los analistas comerciales 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 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í, que 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 el control de versiones , la convención de nomenclatura (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 y luego controlar el calendario de versiones y comunicarse con las partes interesadas relevantes. La mayoría de los proyectos de software tienen acceso a tres entornos de software a los que se puede lanzar software; Desarrollo, prueba y producción. En proyectos muy grandes, donde los equipos distribuidos necesitan integrar su trabajo antes de entregarlo a los usuarios, a menudo habrá más entornos para las pruebas, llamadas pruebas unitarias , pruebas del sistema o pruebas de integración , antes de la entrega 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 en función de 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 "códigos auxiliares de datos". Tradicionalmente, las versiones anteriores de un sistema de producción alguna vez se utilizaron 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 programa de lanzamiento de prueba, muy parecido al programa general de lanzamiento de software.
- El mantenimiento y la actualización es el proceso en el que los requisitos y las necesidades del cliente siempre están involucrados. Indudablemente encontrarán errores, pueden 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 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. A continuación, se desarrolla el plan del proyecto para describir las tareas que llevarán a su finalización. La ejecución del proyecto es el proceso de completar las tareas definidas en el plan del proyecto.
El propósito del seguimiento y control del proyecto es mantener al equipo y a la dirección actualizados 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 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. [ cita requerida ] 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 septiembre de 2010[actualizar], llaman a su sistema Issue Tracker. [ necesita actualización ]
Niveles de gravedad
Los problemas a menudo se clasifican en términos de niveles de gravedad . Las diferentes empresas tienen diferentes definiciones de gravedad, pero algunas de las más comunes son:
- Elevado
- El error o problema afecta a una parte crucial de un sistema y debe solucionarse para que pueda reanudar el funcionamiento normal.
- 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 muchas empresas de software, [ ¿cuál? ] los analistas de garantía de calidad a menudo investigan los problemas cuando verifican la corrección de un sistema y luego se asignan a los desarrolladores que son responsables de resolverlos. También pueden ser asignados por los usuarios del sistema durante la fase de prueba de aceptación del usuario (UAT) .
Los problemas se comunican mediante sistemas de seguimiento de problemas o defectos . En algunos otros casos, se utilizan correos electrónicos o mensajería instantánea [ ejemplo necesario ] .
Filosofía
Como una 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 este punto de vista y argumenta que el desarrollo de software es completamente un trabajo de diseño y compara a un gerente que no puede programar con el editor gerente de un periódico que no puede escribir . [6]
Referencias
- ^ a b 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
- ^ a b Producción de software de código abierto: cómo ejecutar un proyecto de software libre exitoso (libro electrónico, descarga gratuita), por Karl Fogel
- ^ a b Robert Frese y Vicki Sauter , "Mejorar sus probabilidades de éxito en el proyecto de software", IEEE Engineering Management Review , vol. 42, No. 4, cuarto trimestre, diciembre de 2014
- ^ Philip Greenspun , en Fundador de Jessica Livingston en el trabajo (2007), ISBN 1-59059-714-1
- ^ John C. Reynolds, Algunas reflexiones sobre la enseñanza de programación y lenguajes de programación , SIGPLAN Notices, Volumen 43, Número 11, noviembre de 2008, p.108: "Algunos argumentan que uno puede administrar 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. Como tal, está más cerca a la producción de un nuevo periódico [sic], de modo que un administrador de software que no puede programar es similar a un editor en jefe que no puede 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 . Publicaciones J.Ross. ISBN 978-1-60427-034-1.
enlaces externos
- Recursos sobre gestión de proyectos de software de Dan Galorath
Fracaso del proyecto
- Robert Frese (16 de diciembre de 2003). "PROYECTO ÉXITO Y FRACASO: ¿QUÉ ES ÉXITO, QUÉ ES FRACASO Y CÓMO PUEDE MEJORAR SUS PROBABILIDADES DE ÉXITO?" . Universidad de Missouri-St. Louis . Consultado el 13 de mayo de 2015 .
- Joseph Gulla (febrero de 2012). "Siete razones por las que los proyectos de TI fallan" . Revista IBM Systems . Consultado el 13 de mayo de 2015 .