Gestión de proyectos de software - Software project management

Ciclo de vida del software IEEE

La gestión de proyectos de software es un arte y una ciencia de la planificación y el liderazgo de proyectos de software. Es una subdisciplina de la gestión de proyectos en la que los proyectos de software se planifican, implementan, monitorean 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:

  1. Participación insuficiente del usuario final
  2. Mala comunicación entre clientes, desarrolladores, usuarios y directores de proyectos.
  3. Metas del proyecto poco realistas o desarticuladas
  4. Estimaciones inexactas de los recursos necesarios
  5. Requisitos y especificaciones del sistema mal definidos o incompletos
  6. Informe deficiente del 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 elementos de la lista anterior muestran las dificultades para articular las necesidades del cliente de tal manera que los recursos adecuados puedan brindar 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 preocupaciones comerciales. Muchos procesos de desarrollo de software se pueden ejecutar de forma 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.
  • 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 alterado 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 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. Teóricamente, 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 "stubs de datos". Tradicionalmente, las versiones anteriores de un sistema de producción se usaban 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 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, al igual que el 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. 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 Issue Tracker.

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, los analistas de control 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 .

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 .

Referencias

General

enlaces externos

Fracaso del proyecto