Gestión de proyectos de software

El patrón de trabajo de una empresa de TI dedicada al desarrollo de software se puede dividir en dos partes:

Creación de software
Gestión de proyectos de software

Un proyecto es una tarea bien definida, que es una colección de varias operaciones realizadas para lograr un objetivo (por ejemplo, desarrollo y entrega de software). Un proyecto se puede caracterizar como:

Cada proyecto puede tener un objetivo único y distinto.
El proyecto no es una actividad rutinaria ni una operación diaria.
El proyecto viene con una hora de inicio y una hora de finalización.
El proyecto finaliza cuando se logra su objetivo, por lo tanto, es una fase temporal en la vida de una organización.
El proyecto necesita recursos adecuados en términos de tiempo, mano de obra, finanzas, material y banco de conocimientos.

Proyecto de software

Un proyecto de software es el procedimiento completo de desarrollo de software desde la recopilación de requisitos hasta la prueba y el mantenimiento, realizado de acuerdo con las metodologías de ejecución, en un período de tiempo específico para lograr el producto de software previsto.

Necesidad de gestión de proyectos de software

Se dice que el software es un producto intangible. El desarrollo de software es una especie de corriente completamente nueva en los negocios mundiales y hay muy poca experiencia en la creación de productos de software. La mayoría de los productos de software están hechos a medida para adaptarse a los requisitos del cliente. El más importante es que la tecnología subyacente cambia y avanza con tanta frecuencia y rapidez que la experiencia de un producto puede no aplicarse al otro. Todas estas limitaciones comerciales y ambientales conllevan riesgos en el desarrollo de software, por lo que es esencial administrar los proyectos de software de manera eficiente.

La imagen de arriba muestra restricciones triples para proyectos de software. Es una parte esencial de la organización del software entregar un producto de calidad, manteniendo el costo dentro de las restricciones presupuestarias del cliente y entregar el proyecto según lo programado. Hay varios factores, tanto internos como externos, que pueden afectar este triángulo de triple restricción. Cualquiera de los tres factores puede afectar gravemente a los otros dos.

Por lo tanto, la gestión de proyectos de software es fundamental para incorporar los requisitos del usuario junto con las limitaciones de tiempo y presupuesto.

Gerente de proyectos de software

Un gerente de proyecto de software es una persona que asume la responsabilidad de ejecutar el proyecto de software. El gerente de proyectos de software está al tanto de todas las fases de SDLC por las que pasaría el software. Es posible que el gerente de proyecto nunca participe directamente en la producción del producto final, pero controla y administra las actividades involucradas en la producción.

Un gerente de proyecto monitorea de cerca el proceso de desarrollo, prepara y ejecuta varios planes, organiza los recursos necesarios y adecuados, mantiene la comunicación entre todos los miembros del equipo para abordar cuestiones de costo, presupuesto, recursos, tiempo, calidad y satisfacción del cliente.

Veamos algunas responsabilidades que asume un director de proyecto:

La gestión de personas

Actuar como líder del proyecto
Enlace con las partes interesadas
Gestión de recursos humanos
Configurar la jerarquía de informes, etc.

Proyecto de gestión

Definición y configuración del alcance del proyecto
Gestión de actividades de gestión de proyectos
Seguimiento del progreso y el desempeño
Análisis de riesgos en cada fase
Dar los pasos necesarios para evitar o salir de problemas
Actuar como portavoz del proyecto

Actividades de gestión de software

La gestión de proyectos de software comprende una serie de actividades, que incluyen la planificación del proyecto, la determinación del alcance del producto de software, la estimación del costo en varios términos, la programación de tareas y eventos y la gestión de recursos. Las actividades de gestión de proyectos pueden incluir:

Project Planning
Scope Management
Project Estimation

Planificación de proyectos

La planificación de proyectos de software es una tarea que se realiza antes de que comience realmente la producción de software. Está ahí para la producción de software, pero no involucra ninguna actividad concreta que tenga alguna conexión directa con la producción de software; más bien es un conjunto de múltiples procesos, lo que facilita la producción de software. La planificación del proyecto puede incluir lo siguiente:

Gestión del alcance

Define el alcance del proyecto; esto incluye todas las actividades, el proceso debe realizarse para hacer un producto de software entregable. La gestión del alcance es esencial porque crea límites del proyecto al definir claramente qué se haría en el proyecto y qué no se haría. Esto hace que el proyecto contenga tareas limitadas y cuantificables, que se pueden documentar fácilmente y, a su vez, evita el sobrecoste y el tiempo.

Durante la gestión del Alcance del Proyecto, es necesario:

Definir el alcance
Decidir su verificación y control
Divida el proyecto en varias partes más pequeñas para facilitar la gestión.
Verificar el alcance
Controle el alcance incorporando cambios al alcance

Estimación del proyecto

Para una gestión eficaz es imprescindible una estimación precisa de varias medidas. Con una estimación correcta, los gerentes pueden administrar y controlar el proyecto de manera más eficiente y efectiva.

La estimación del proyecto puede involucrar lo siguiente:

Software size estimation
El tamaño del software puede estimarse en términos de KLOC (Kilo Line of Code) o calculando el número de puntos de función en el software. Las líneas de código dependen de las prácticas de codificación y los puntos de función varían según los requisitos del usuario o del software.
Effort estimation
Los gerentes estiman los esfuerzos en términos de requisitos de personal y horas hombre requeridas para producir el software. Para la estimación del esfuerzo, se debe conocer el tamaño del software. Esto puede derivarse de la experiencia de los gerentes, los datos históricos de la organización o el tamaño del software se pueden convertir en esfuerzos mediante el uso de algunas fórmulas estándar.
Time estimation
Una vez que se estiman el tamaño y los esfuerzos, se puede estimar el tiempo requerido para producir el software. Los esfuerzos necesarios se segregan en subcategorías según las especificaciones de requisitos y la interdependencia de varios componentes del software. Las tareas de software se dividen en tareas, actividades o eventos más pequeños por Work Breakthrough Structure (WBS). Las tareas se programan en el día a día o en meses naturales.

La suma del tiempo necesario para completar todas las tareas en horas o días es el tiempo total invertido para completar el proyecto.
Cost estimation
Este podría considerarse como el más difícil de todos porque depende de más elementos que cualquiera de los anteriores. Para estimar el costo del proyecto, se requiere considerar:

Tamaño del software
Calidad del software
Hardware
Software o herramientas adicionales, licencias, etc.
Personal calificado con habilidades específicas para tareas
Viaje involucrado
Communication
Capacitación y apoyo

Técnicas de estimación de proyectos

Discutimos varios parámetros relacionados con la estimación del proyecto, como el tamaño, el esfuerzo, el tiempo y el costo.

El gerente de proyecto puede estimar los factores enumerados utilizando dos técnicas ampliamente reconocidas:

Técnica de descomposición

Esta técnica asume el software como producto de varias composiciones.

Hay dos modelos principales:

Line of Code La estimación se realiza en nombre del número de líneas de códigos en el producto de software.
Function Points La estimación se realiza en nombre del número de puntos de función en el producto de software.

Técnica de estimación empírica

Esta técnica utiliza fórmulas derivadas empíricamente para realizar estimaciones. Estas fórmulas se basan en LOC o FP.

Putnam Model
Este modelo está hecho por Lawrence H. Putnam, que se basa en la distribución de frecuencia de Norden (curva de Rayleigh). El modelo de Putnam mapea el tiempo y los esfuerzos necesarios con el tamaño del software.
COCOMO
COCOMO son las siglas de COnstructive COst MODdel, desarrollado por Barry W. Boehm. Divide el producto de software en tres categorías de software: orgánico, adosado e integrado.

Programación de proyectos

La programación del proyecto en un proyecto se refiere a la hoja de ruta de todas las actividades que se realizarán con un orden específico y dentro del intervalo de tiempo asignado a cada actividad. Los gerentes de proyecto tienden a definir varias tareas e hitos del proyecto y organizarlos teniendo en cuenta varios factores. Buscan tareas que se encuentran en una ruta crítica en el cronograma, que es necesario completar de manera específica (debido a la interdependencia de tareas) y estrictamente dentro del tiempo asignado. Es menos probable que la disposición de las tareas que se encuentran fuera de la ruta crítica afecte a todo el cronograma del proyecto.

Para programar un proyecto, es necesario:

Divida las tareas del proyecto en una forma más pequeña y manejable
Descubra varias tareas y correlacione
Estimar el marco de tiempo requerido para cada tarea
Divida el tiempo en unidades de trabajo
Asignar un número adecuado de unidades de trabajo para cada tarea.
Calcule el tiempo total requerido para el proyecto de principio a fin

Administracion de recursos

Todos los elementos utilizados para desarrollar un producto de software pueden asumirse como recursos para ese proyecto. Esto puede incluir recursos humanos, herramientas productivas y bibliotecas de software.

Los recursos están disponibles en cantidades limitadas y permanecen en la organización como un conjunto de activos. La escasez de recursos dificulta el desarrollo del proyecto y puede retrasarse en el cronograma. La asignación de recursos adicionales aumenta el costo de desarrollo al final. Por tanto, es necesario estimar y asignar recursos adecuados para el proyecto.

La gestión de recursos incluye:

Definir el proyecto de organización adecuado mediante la creación de un equipo de proyecto y la asignación de responsabilidades a cada miembro del equipo.
Determinar los recursos necesarios en una etapa particular y su disponibilidad.
Administre los recursos generando solicitudes de recursos cuando sean necesarios y desasignándolos cuando ya no sean necesarios.

Gestión de riesgos del proyecto

La gestión de riesgos incluye todas las actividades relacionadas con la identificación, el análisis y la provisión de riesgos predecibles y no predecibles en el proyecto. El riesgo puede incluir lo siguiente:

Personal experimentado que abandona el proyecto y nuevo personal que ingresa.
Cambio en la gestión organizacional.
Requisito cambio o malinterpretación del requisito.
Subestimación del tiempo y los recursos necesarios.
Cambios tecnológicos, cambios ambientales, competencia empresarial.

Proceso de gestión de riesgos

Hay las siguientes actividades involucradas en el proceso de gestión de riesgos:

Identification - Tome nota de todos los posibles riesgos que puedan ocurrir en el proyecto.
Categorize - Clasifique los riesgos conocidos en intensidad de riesgo alta, media y baja según su posible impacto en el proyecto.
Manage - Analizar la probabilidad de ocurrencia de riesgos en varias fases. Haga un plan para evitar o enfrentar riesgos. Intente minimizar sus efectos secundarios.
Monitor - Controle de cerca los riesgos potenciales y sus primeros síntomas. También supervise los efectos de las medidas adoptadas para mitigarlos o evitarlos.

Ejecución y seguimiento de proyectos

En esta fase, las tareas descritas en los planes del proyecto se ejecutan de acuerdo con sus cronogramas.

La ejecución necesita un seguimiento para comprobar si todo va de acuerdo con el plan. Monitorear es observar para verificar la probabilidad de riesgo y tomar medidas para abordar el riesgo o informar el estado de varias tareas.

Estas medidas incluyen:

Activity Monitoring - Todas las actividades programadas dentro de alguna tarea se pueden monitorear en el día a día. Cuando se completan todas las actividades de una tarea, se considera completa.
Status Reports - Los informes contienen el estado de las actividades y tareas completadas dentro de un período de tiempo determinado, generalmente una semana. El estado se puede marcar como terminado, pendiente o en progreso, etc.
Milestones Checklist - Cada proyecto se divide en múltiples fases donde se realizan las principales tareas (hitos) en función de las fases de SDLC. Esta lista de verificación de hitos se prepara una vez cada pocas semanas e informa el estado de los hitos.

Gestión de comunicación de proyectos

La comunicación eficaz juega un papel vital en el éxito de un proyecto. Sirve de puente entre el cliente y la organización, entre los miembros del equipo y otras partes interesadas en el proyecto, como los proveedores de hardware.

La comunicación puede ser oral o escrita. El proceso de gestión de la comunicación puede tener los siguientes pasos:

Planning - Este paso incluye la identificación de todos los interesados en el proyecto y el modo de comunicación entre ellos. También considera si se requieren instalaciones de comunicación adicionales.
Sharing - Después de determinar varios aspectos de la planificación, el gerente se enfoca en compartir la información correcta con la persona correcta en el momento correcto. Esto mantiene a todos los involucrados en el proyecto al día con el progreso del proyecto y su estado.
Feedback - Los gerentes de proyecto utilizan diversas medidas y mecanismos de retroalimentación y crean informes de estado y desempeño. Este mecanismo asegura que los aportes de las diversas partes interesadas lleguen al director del proyecto como retroalimentación.
Closure - Al final de cada gran evento, final de una fase de SDLC o finalización del propio proyecto, se anuncia formalmente el cierre administrativo para actualizar a todos los interesados mediante el envío de correo electrónico, la distribución de una copia impresa del documento o por otro medio de comunicación eficaz.

Después del cierre, el equipo pasa a la siguiente fase o proyecto.

Gestión de la configuración

La gestión de la configuración es un proceso de seguimiento y control de los cambios en el software en términos de requisitos, diseño, funciones y desarrollo del producto.

IEEE lo define como “el proceso de identificar y definir los elementos en el sistema, controlar el cambio de estos elementos a lo largo de su ciclo de vida, registrar y reportar el estado de los elementos y las solicitudes de cambio, y verificar la integridad y corrección de los elementos”.

En general, una vez finalizado el SRS, hay menos posibilidades de que el usuario requiera cambios. Si ocurren, los cambios se abordan solo con la aprobación previa de la gerencia superior, ya que existe la posibilidad de que se excedan los costos y el tiempo.

Base

Una fase de SDLC se asume como finalizada si es de línea base, es decir, la línea base es una medida que define la completitud de una fase. Una fase se basa en la línea de base cuando todas las actividades relacionadas con ella están terminadas y bien documentadas. Si no fuera la fase final, su salida se utilizaría en la siguiente fase inmediata.

La gestión de la configuración es una disciplina de la administración de la organización, que se encarga de la ocurrencia de cualquier cambio (proceso, requisito, tecnológico, estratégico, etc.) después de que una fase es la línea base. CM controla los cambios realizados en el software.

Cambio de control

El control de cambios es una función de la gestión de la configuración, lo que garantiza que todos los cambios realizados en el sistema de software sean coherentes y se realicen según las normas y reglamentos de la organización.

Un cambio en la configuración del producto pasa por los siguientes pasos:

Identification- Llega una solicitud de cambio de una fuente interna o externa. Cuando la solicitud de cambio se identifica formalmente, está debidamente documentada.
Validation - Se comprueba la validez de la solicitud de cambio y se confirma su procedimiento de tramitación.
Analysis- El impacto de la solicitud de cambio se analiza en términos de cronograma, costo y esfuerzos requeridos. Se analiza el impacto general del cambio prospectivo en el sistema.
Control- Si el cambio prospectivo impacta a demasiadas entidades en el sistema o es inevitable, es obligatorio contar con la aprobación de las altas autoridades antes de que el cambio se incorpore al sistema. Se decide si vale la pena incorporar el cambio o no. Si no es así, la solicitud de cambio se rechaza formalmente.
Execution - Si la fase anterior determina ejecutar la solicitud de cambio, esta fase toma las acciones apropiadas para ejecutar el cambio, hace una revisión completa si es necesario.
Close request- Se verifica el cambio para su correcta implementación y fusión con el resto del sistema. Este cambio recién incorporado en el software está debidamente documentado y la solicitud se cierra formalmente.

Herramientas de gestión de proyectos

El riesgo y la incertidumbre se multiplican con respecto al tamaño del proyecto, incluso cuando el proyecto se desarrolla de acuerdo con metodologías establecidas.

Hay herramientas disponibles que ayudan a una gestión eficaz del proyecto. Se describen algunos:

Gráfico de gantt

Los diagramas de Gantt fueron ideados por Henry Gantt (1917). Representa el cronograma del proyecto con respecto a los períodos de tiempo. Es un gráfico de barras horizontales con barras que representan las actividades y el tiempo programado para las actividades del proyecto.

Gráfico PERT

El gráfico PERT (técnica de evaluación y revisión de programas) es una herramienta que describe el proyecto como un diagrama de red. Es capaz de representar gráficamente los principales eventos del proyecto tanto de forma paralela como consecutiva. Los eventos, que ocurren uno tras otro, muestran la dependencia del evento posterior sobre el anterior.

Los eventos se muestran como nodos numerados. Están conectados por flechas etiquetadas que representan la secuencia de tareas del proyecto.

Histograma de recursos

Esta es una herramienta gráfica que contiene una barra o un gráfico que representa la cantidad de recursos (generalmente personal capacitado) necesarios a lo largo del tiempo para un evento (o fase) del proyecto. El histograma de recursos es una herramienta eficaz para la planificación y coordinación del personal.

Análisis de ruta crítica

Esta herramienta es útil para reconocer tareas interdependientes en el proyecto. También ayuda a encontrar la ruta más corta o la ruta crítica para completar el proyecto con éxito. Como el diagrama PERT, a cada evento se le asigna un marco de tiempo específico. Esta herramienta muestra la dependencia del evento asumiendo que un evento puede pasar al siguiente solo si se completa el anterior.

Los eventos se organizan de acuerdo con su hora de inicio más temprana posible. La ruta entre el nodo inicial y final es una ruta crítica que no se puede reducir más y todos los eventos deben ejecutarse en el mismo orden.