Please enable JavaScript.

Coggle requires JavaScript to display documents.

Gestión de Proyectos Laboratorio de Diseño de Software (Gestión de riesgos…

- - - - El producto es intangible: Un administrador de un astillero o un proyecto de ingeniería civil pueden ver el producto conforme se desarrolla. Si hay retraso en el calendario, es visible el efecto sobre el producto: es evidente que algunas partes de la estructura no están terminadas. El software es intangible. No se puede ver ni tocar. Los administradores de proyectos de software no pueden constatar el progreso con sólo observar el artefacto que se construye. Más bien, ellos se apoyan en otros para crear la prueba que pueden utilizar al revisar el progreso del trabajo.
    - - Los grandes proyectos de software con frecuencia son proyectos excepcionales: Los grandes proyectos de software se consideran en general diferentes en ciertas formas de otros proyectos. Por eso, incluso los administradores que cuentan con vasta experiencia pueden encontrar difícil anticiparse a los problemas.
      - Los vertiginosos cambios tecnológicos en computadoras y comunicaciones pueden volver obsoleta la experiencia de un administrador. Las lecciones aprendidas de proyectos anteriores pueden no ser aplicables a nuevos proyectos.
    - - Los procesos de software son variables y específicos de la organización: El proceso de ingeniería para algunos tipos de sistema, como puentes y edificios, es bastante comprendido. Sin embargo, los procesos de software varían considerablemente de una organización a otra.
      - Aunque se ha producido un notorio avance en la estandarización y el mejoramiento de los procesos, no es posible predecir de manera confiable cuándo un proceso de software particular conducirá a problemas de desarrollo. Esto es especialmente cierto si el proyecto de software es parte de un proyecto de ingeniería de sistemas más amplio.
  - - - Los administradores de proyecto son responsables de la planeación, estimación y calendarización del desarrollo del proyecto, así como de la asignación de tareas a las personas. Supervisan el trabajo para verificar que se realice de acuerdo con los estándares requeridos y monitorizan el avance para comprobar que el desarrollo esté a tiempo y dentro del presupuesto.
    - - Los administradores de proyectos por lo común son responsables de informar del avance de un proyecto a los clientes y administradores de la compañía que desarrolla el software. Deben ser capaces de comunicarse en varios niveles, desde codificar información técnica detallada hasta elaborar resúmenes administrativos.Deben redactar documentos concisos y coherentes que sinteticen información crítica de reportes detallados del proyecto. Es necesario que esta información se presente durante las revisiones de avance.
    - - Los administradores de proyecto tienen que valorar los riesgos que pueden afectar un proyecto, monitorizar dichos riesgos y emprender acciones cuando surjan problemas.
    - - Los administradores de proyecto son responsables de administrar un equipo de personas. Deben elegir a los integrantes de sus equipos y establecer formas de trabajar que conduzcan a desempeño efectivo del equipo.
    - - La primera etapa en un proyecto de software puede implicar escribir una propuesta para obtener un contrato de trabajo. La propuesta describe los objetivos del proyecto y cómo se realizará. Por lo general, incluye estimaciones de costo y calendarización, además de justificar por qué el contrato del proyecto debería concederse a una organización o un equipo particular. La escritura de propuestas es una tarea esencial, pues la supervivencia de muchas compañías de software depende de contar con suficientes propuestas aceptadas y concesiones de contratos.
- - - - En lo que respecta a los recursos humanos, debemos de ser la organización cuenta con personal con los conocimientos técnicos necesarios para operar el sistema que se desarrollara, en este punto es claro que lo primero que se les pedirá son conocimientos básicos de computo, claro esta que acceder a las redes sociales y publicar en ellas no califica como conocimientos básicos de computo.
    - - La segunda parte del estudio, corresponde a estudiar la estructura orgánica de la empresa, dado que la implementación de un nuevo sistema, puede requerir en un momento determinado la creación de nuevos puestos o incluso áreas que antes no existían.
  - - - Derivado de la factibilidad técnica: Equipos de computo y periféricos que se necesita adquirir, adecuación de las instalaciones, instalación de los equipos, instalación de los programas bajo licencia, licencias de programas o bibliotecas especiales.
    - - Derivado de la factibilidad operativa: Cursos de capacitación, modificación de la estructura (costos de modificación de manuales de organización, selección de personal).
    - - Derivados de las etapas de desarrollo. Mano de obra (ya sea en horas-hombre o líneas de código), papelería, electricidad, consumibles, capacitación, diseño de pruebas, tiempo de pruebas.
    - - Derivados de la instalación del sistema. Mano de obra para la instalación, traducción y preparación de datos, soporte inicial, gastos varios.
- - - - Desarrollo/Adquisición
        
        ¿Software comprado o desarrollado? y quien desarrollara el sistema en dado caso (internamente o contratado), hardware (compra, leasing), infraestructura (comunicaciones, infraestructura edilicia)
      - Instalación/Conversión
        
        Instalación, entrenamiento de personal, migración de datos/archivos.
    - - Mantenimiento, Personal, Por departamento (vehtas, producción, etc.)
  - - - Pueden calcularse en montos ($)
    - - Pueden cuantificarse los beneficios pero no calcularse los montos ($)
    - - No se cuantifican ni se calculan en montos ($)
    - - Por nivel de organización: Operacional (baja, media, alta gerencia)
      - Por departamento: Producción, ventas, etcétera.
- - - - Se derivan de las tecnologías de software o hardware usadas para desarrollar el sistema.
      - Riesgos posibles: (1) La base de datos que se usa en el sistema no puede procesar tantas transacciones por segundo, como se esperaba. (2) Los componentes se software de reutilización contienen defectos que hacen que no puedan reutilizarse como se planeo.
    - - Se asocian con el personal en el equipo de trabajo
      - Riesgos posibles: (1) Es imposible reclutar personal con las habilidades requeridas. (2) El personal esta enfermo e indispuesto en momentos críticos. (3) No está disponible la capacitación requerida para el personal.
    - - Se derivan del entorno organizacional donde se desarrolla el software.
      - Riesgos posibles: (1) La organización se reestructura de modo que diferentes administraciones son responsables del proyecto. (2) Problemas financieros de la organización que fuerzan reducciones en el presupuesto del proyecto.
    - - Resultan de las herramientas de software y otro software de soporte que se usa para desarrollar el sistema.
      - Riesgos posibles: (1) El código elaborado por las herramientas de generación de código de software sea ineficiente. (2) Las herramientas de software no pueden trabajar en una forma integrada.
    - - Proceden de cambios a los requerimientos del cliente y del proceso de gestionarlos.
      - Riesgos posibles: (1) Se proponen cambios a los requerimientos que demandan mayor trabajo de rediseño. (2) Los clientes no entienden las repercusiones de los cambios a los requerimientos.
    - - Surgen de las estimaciones administrativas de los recursos requeridos para construir el sistema.
      - Riesgos posibles: ** (1) Se subestima el tiempo requerido para desarrollar el sistema. (2) Se subestima la tasa de reparación de defectos. (3) Se subestima el tamaño del software.
  - - - La probabilidad de ocurrencia del riesgo puede valorarse como muy baja (< 10%), baja (del 10% al 25%), moderada (del 25% al 50%) o muy alta ( > 70%).
    - - Los efectos del riesgo pueden estimarse como, catastróficos (amenazan la supervivencia del proyecto), graves (que causarían grandes demoras), tolerables (demoras dentro de la contingencia permitida) o insignificantes.
  - - - Seguir estas estrategias significa que se reducirá la probabilidad de que surja el riesgo. Un ejemplo de estrategia de de evitación del riesgo, es la estrategia de enfrentar los componentes defectuosos.
    - - Seguir estas estrategias significa que se reducirá el efecto del riesgo. Un ejemplo de estrategia de minimización de un riesgo es la estrategia para las enfermedades del personal.
    - - Seguir estas estrategias significa que se está preparado para lo peor, y se tiene una estrategia para hacer frente a ello. Un ejemplo de estrategia de contingencia es la estrategia para los problemas financieros de la organización.
  - - - Tecnológicos
        
        Indicador potencial: Entrega tardía de hardware o software de soporte.
      - Personales
        
        Indicador potencial: Baja moral del personal, malas relaciones entre miembros del equipo, alta rotación de personal.
      - Organizacionales
        
        Indicador potencial: Chismes dentro de la organización, falta de acción de los altos ejecutivos.
      - De herramientas
        
        Indicador potencial: Renuencia de los miembros del equipo para usar ciertas herramientas, quejas de las herramientas CASE, demandas por estaciones de trabajo mejor equipadas.
      - De estimación
        
        Indicador potencial: Falta para cumplir con el calendario acordado, falla para corregir los defectos reportados.
      - De requerimientos
        
        Indicador potencial: Muchas peticiones de cambios de requerimientos, quejas de los clientes.
  - - - Los riesgos que afectan la calidad o el rendimiento del software a desarrollar. Un ejemplo de riesgo de producto es la falla que presenta un componente que se adquirió al no desempeñarse como se esperaba. Esto puede afectar el rendimiento global del sistema, de modo que es más lento de lo previsto.
    - - Riesgos que afectan a la organización que desarrolla o adquiere el software. Por ejemplo, un competidor que introduce un nuevo producto es un riesgo empresarial. La introducción de un producto competitivo puede significar que las suposiciones hechas sobre las ventas de los productos de software existentes sean excesivamente optimistas.
    - - Los riesgos que alteran el calendario o los recursos del proyecto. Un ejemplo de riesgo de proyecto es la renuncia de un diseñador experimentado. Encontrar un diseñador de reemplazo con habilidades y experiencia adecuadas puede demorar mucho tiempo y, en consecuencia, el diseño del software tardará más tiempo en completarse.
- - - - En la etapa de propuestas, es cuando se presenta una licitación con vistas a obtener un contrato para desarrollar un sistema de software. En esta etapa es necesario un plan para ayudarle a decidir si cuenta con los recursos para completar el trabajo y a calcular el precio que debe cotizar al cliente.
    - - Durante la fase de inicio, es cuando se debe determinar quien trabajará en el proyecto, como se dividirá el proyecto en incrementos, como se asignarán los recursos a través de la compañía, etc. Aquí se cuenta con más información que en la etapa de la propuesta y por lo tanto se pueden afinar las estimaciones iniciales.
    - - Periódicamente a lo largo del proyecto, es cuando el plan se modifica a las luz de la experiencia obtenida y de la información del monitoreo del avance del trabajo. Se aprende más acerca del sistema a implementar y de las capacidades del equipo de desarrollo. Esta información permite hacer estimaciones más precisas sobre cuanto tardará el trabajo. Más aún, es probable que los requisitos del software cambien y esto por lo general significa que debe modificarse la división del trabajo y extenderse el plazo.
      - Para proyectos de desarrollo tradicional, quiere decir que el plan creado al inicio debe modificarse. No obstante cuando se usa un enfoque ágil los planes son a plazos más cortos y varían continuamente a medida que evoluciona el software.
  - - - La introducción describe brevemente los objetivos del proyecto y establece las restricciones (por ejemplo, presupuesto, tiempo, etc.) que afectan la administración del proyecto.
    - - La organización del proyecto refiere la forma en que esta organizado el equipo de desarrollo, las personas implicadas y sus roles en el equipo.
    - - El análisis de riesgo detalla los posibles riesgos del proyecto, la probabilidad de que surjan dichos riesgos y las estrategias propuestas para reducir el riesgo.
    - - Los requerimientos de recursos de hardware y software detallan el hardware y software de soporte, requeridos para realizar el desarrollo. Si hay que comprar hardware pueden incluirse estimaciones de los precios y el calendario de entregas.
    - - La división del trabajo establece la división del proyecto en actividades e identifica los plazos y entregas asociados con cada actividad. Los plazos son la etapa clave del proyecto donde puede valorarse el avance; las entregas son productos de trabajo que se proporciona al cliente.
    - - El calendario del proyecto indica las dependencias entre las actividades, el tiempo estimado requerido para alcanzar cada plazo y la asignación de personal a las actividades.
    - - Los mecanismos de monitorización y reportes definen los informes administrativos que deben producirse cuando tienen que elaborarse y los mecanismos de monitorización del proyecto que se usarán.
  - - - Describe los procedimientos de calidad y estándares que se usarán en un proyecto.
    - - Describe el enfoque, los recursos y el calendario utilizados para la validación del sistema.
    - - La configuración del plan de gestión describe la configuración de los procedimientos y las estructuras para la gestión.
    - - Predice los requerimientos, los costos y el esfuerzo de mantenimiento.
    - - Describe como se desarrollarán las habilidades y la experiencia de los miembros del equipo de proyecto.
- - - - Basadas en el calendario, las cuales señalan al responsable de cada actividad, el tiempo transcurrido previsto y la fecha en que se programa el inicio y el fin de la actividad. Estas gráficas de barras se conocen como gráficas de Gantt en honor de su inventor, Herny Gantt.
    - - Simplemente son diagramas de red que muestran las dependencias entre las diferentes actividades que constituyen un proyecto.
    - - Una duración en días o meses-
      - Un plazo dentro del cual debe completarse la actividad.
      - Un punto final definido. Este representa el resultado tangible de completar la actividad. También podría ser un documento, la realización de una junta de revisión, una ejecución exitosa de pruebas, etcétera.
  - - - Release: Se prevé con muchos meses de antelación y decide sobre las características que deben incluirse en una entrega de un sistema.
    - - Tiene un panorama a corto plazo y se enfoca en la planificación del siguiente incremento de un sistema. Esto para el equipo representa de dos a cuatro semanas de trabajo.