Tipos de Riesgos en Proyectos de Software
Durante la implementación de un proyecto de software, pueden surgir diversos riesgos que afecten su desarrollo y éxito. A continuación, se describen algunos de los más comunes:
- Riesgo de Personal: Existe la posibilidad de que parte del equipo de implementación se retire del proyecto a mitad de su desarrollo, por ejemplo, debido a una mejor oferta de salario en otra empresa.
- Riesgo de Requerimientos: Puede ocurrir que el cliente solicite modificaciones de los requerimientos o la implementación de nuevos requerimientos durante el desarrollo del proyecto.
- Riesgo de Hardware: Pueden ocurrir fallas en los servidores de implementación o en los servidores de base de datos.
- Riesgos Técnicos: Se pueden encontrar problemas técnicos como tiempos de respuesta muy altos de determinados componentes de software, velocidades muy bajas de transmisión de datos por determinados canales inalámbricos, redes de transmisión de datos especiales, etc.
- Riesgos Operativos: Durante la implementación o puesta en operación del proyecto, se pueden encontrar problemas de operación, tales como tiempos muy altos de procesos o una cantidad muy alta de personal requerido para operar determinados módulos de la aplicación.
Características y Herramientas para la Gestión de Proyectos
Un proyecto se define como cualquier empresa humana con un inicio y un final claros. Los proyectos de software comparten algunas características comunes:
- Combinación de actividades
- Relación secuencial entre actividades
- Preocupación por el tiempo
- Preocupación por los recursos
Para la planificación, programación y control de proyectos, se utilizan diversas herramientas, entre ellas:
- Gráficas de Gantt
- Modelos de redes:
- Redes deterministas (CPM = Método de la Ruta Crítica)
- Redes probabilistas (PERT = Técnica de Evaluación y Revisión de Programas)
- Otras técnicas
Roles y Responsabilidades en el Desarrollo de Software
Diferentes roles dentro del equipo de desarrollo utilizan distintas herramientas y metodologías para llevar a cabo sus tareas:
- Cliente y Jefe de Proyecto: Utilizan los diagramas de Casos de Uso para visualizar la globalidad del sistema y delimitar el alcance del proyecto.
- Jefe de Proyecto: Emplea los diagramas de Casos de Uso y la documentación asociada para descomponer el proyecto en un Plan Director de Iteraciones.
- Analista y Cliente: Se apoyan en la documentación asociada a los Casos de Uso para comprender mejor y delimitar la funcionalidad del sistema.
- Documentalista: Usa la documentación asociada a los Casos de Uso para redactar los manuales de usuario y definir el plan de formación.
- Analista y Desarrollador: Usan los diagramas de secuencia y colaboración para visualizar la lógica del sistema y el flujo de mensajes entre los objetos.
- Desarrollador: Utiliza los diagramas de Clases y los diagramas de Estado Transición para visualizar la estructura de todas las piezas claves del sistema y la dinámica de su comportamiento.
- Implementador: Se sirve de los diagramas de Componentes y los diagramas de Despliegue para visualizar los ejecutables, ficheros DLL y otros componentes, así como la distribución de su despliegue en la red.
- Controller: Usará la documentación asociada a los Casos de Uso y los diagramas de secuencia y colaboración para diseñar las pruebas de certificación.
- Todos los Agentes: Usan el modelo de referencia para garantizar la trazabilidad entre los requerimientos y el código, y para asegurar la trazabilidad entre el código y la funcionalidad.
Cálculo de la Ruta Crítica
La Ruta Crítica es la ruta más larga a través de la red y determina la longitud del proyecto. Toda red tiene al menos una ruta crítica, y es posible que haya proyectos con más de una. Para encontrar la ruta crítica, es necesario agregar a la red los tiempos de cada actividad, los cuales se agregarán en cada nodo. Las flechas solo representan la secuencia de las actividades.
UML (Lenguaje de Modelado Unificado)
UML tiene como propósito que los analistas y arquitectos de sistemas que trabajan en el diseño y análisis de objetos puedan especificar, visualizar, construir y documentar componentes de software.
Orientación a Objetos
La orientación a objetos ofrece una manera diferente de ver una aplicación, organizando la complejidad en microestructuras con componentes reutilizables y adaptabilidad a un entorno cambiante.
Diferencias entre Mentalidad Procedural y Orientación a Objetos
- Mentalidad Procedural:
- Se enfoca en qué hace el sistema y qué objetivos tiene.
- Diseño y codificación orientados a conseguir los objetivos.
- Enfoque dirigido a los algoritmos y centrado en los datos.
- Mentalidad Orientada a Objetos:
- Se enfoca en qué objetos configuran el sistema.
- Estructura y función de cada objeto.
- Dinámica del sistema a través del comportamiento o la interacción de sus objetos.
- Se posponen las funciones algorítmicas y el modelo de datos.
Conceptos Clave en la Orientación a Objetos
- Encapsulación: Empaquetar dentro de un objeto una pieza de información con un comportamiento específico que actúa sobre esta información. Ventaja: Limita los efectos de cambios sobre el sistema.
- Herencia: Mecanismo que permite crear nuevos objetos basados en una progenie. Ventaja: Facilidad de mantenimiento.
- Polimorfismo: Capacidad de aplicar distintas implementaciones a una determinada funcionalidad. Ventaja: Simplicidad y orden.
Diagramas en UML
- Diagrama de Casos de Uso: Muestra la granularidad del sistema en piezas de funcionalidad reutilizables, la interacción de los actores con la funcionalidad del sistema y organiza visualmente los requerimientos del usuario. Ventajas: Lenguaje de comunicación entre usuarios y desarrolladores, comprensión detallada de la funcionalidad del sistema, planificación de iteraciones para su implementación y estimación precisa del esfuerzo para su implementación.
- Diagrama de Actividad: Muestra la secuencia de actividades que se desarrollan en el flujo de trabajo de un caso de uso, como pieza de funcionalidad concreta. También muestra el flujo de trabajo que se desarrolla en un proceso configurado como un paquete de casos de uso.
- Diagrama de Secuencia: Describe la interacción de objetos que requiere la funcionalidad de los distintos escenarios de un caso de uso. Los objetos son representados con su ciclo de vida dentro de una serie temporal.
- Diagrama de Colaboración: Muestra cómo interaccionan los objetos dentro de un caso de uso. A diferencia de un diagrama de secuencia, no hay referencia a una serie temporal.
- Diagrama de Estado-Transición: Muestra los distintos estados en que un objeto puede existir, presenta la visión dinámica del sistema y describe el comportamiento de un objeto, desde que nace hasta que muere.
- Diagrama de Clases: Un objeto representa a una entidad del mundo real o inventada. Es un concepto que dispone de una definición (intensión) y de una aplicabilidad (extensión). Es la instancia de una clase.
- Diagrama de Componentes: Son utilizados por el responsable de compilar el sistema. Describen en qué orden han de ser compilados los componentes y muestran qué componentes run-time serán creados como resultado de la compilación.
- Diagrama de Despliegue: Muestra la distribución física de los componentes en nodos locales y remotos de la red. Un nodo puede representar una pieza de hardware, desde un periférico a un servidor.
DFD (Diagramas de Flujo de Datos)
Los DFD son una representación gráfica del flujo de datos a través de un sistema de información. También se pueden utilizar para la visualización de procesamiento de datos, muestran la interacción entre el sistema y las entidades externas, y los distintos escenarios de comportamiento de los sistemas de información.