1 / 6

Gestión de Proyectos De Software

Gestión de Proyectos De Software. Estudio de las técnicas de gestión necesarias par planificar, organizar, supervisar y controlar proyectos de software. - EL ESPECTRO DE LA GESTIÓN :. La gestión eficaz de un proyecto de software se centra en las 4 P’s. Personal. 2 . Producto.

marlow
Download Presentation

Gestión de Proyectos De Software

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Gestión de Proyectos De Software • Estudio de las técnicas de gestión necesarias par planificar, • organizar, supervisar y controlar proyectos de software. - EL ESPECTRO DE LA GESTIÓN : La gestión eficaz de un proyecto de software se centra en las 4 P’s • Personal 2 . Producto 3 . Proceso 4 . Proyecto

  2. PERSONAL El factor humano es tan importante que el Instituto de Ingeniería de Software ha desarrollado un modelo de madurez de la capacidad de Gestión del Personal (MMCGP) • LOS PARTICIPANTES • Gestores superiores • Gestores del proyecto • Profesionales • Clientes • Usuarios finales LOS JEFES DE EQUIPO La gestión de proyectos es una actividad intensamente humana, Y por esta razón, los profesionales competentes del software a Menudo no son buenos jefes de equipo.

  3. EL EQUIPO DE SOFTWARE La mejor estructura de equipo depende del estilo de gestión de una Organización, el número de personas que compondrá el equipo, sus Niveles de preparación y la dificultad general del problema. Estilo de Gestión • Descentralizado democrático (DD).- No tiene un jefe permanente 2.- Descentralizado controlado (DC).- Tiene un jefe de equipo definido 3.- Centralizado controlado (CC).- El jefe del equipo se encarga de la resolución de problemas a alto nivel. Paradigmas de organización • Un paradigma cerrado.- Jerarquía tradicional de autoridad 2. Paradigma aleatorio.- Libremente, depende de la iniciativa indiv. 3. El paradigma abierto.- Estructura a un equipo de manera que consiga algunos de los controles asociados con el parad. cerrado 4. El paradigma sincronizado.- Se basa en la compartimentación natural de un problema y organiza los miembros del equipo para trabajar en partes del problema.

  4. PRODUCTO El Gestor de un proyecto de software se enfrenta a un dilema al Inicio de un proyecto de ingeniería de software. Ámbito del Software: Contexto.- Como encaja el software a construir en un sistema. Objetivos de información.- Que objetos de datos visibles al cliente se obtienen del software? Función y rendimiento.- Que función realiza el software para transformar la informar de entrada en una salida? Descomposición del problema: Es una actividad que se asienta en el núcleo del análisis de requisitos del software.

  5. PROCESOS Las fases genéricas que caracterizan el proceso de software (definición, desarrollo y soporte), son aplicables a todo software. El problema es seleccionar el modelo de proceso apropiado. • El modelo secuencial lineal • El modelo de prototipo • El modelo de DRA • El modelo incremental • El modelo en espiral • El modelo en espiral WINWIN • El modelo basados en componentes • El modelo de desarrollo concurrente • El modelo de método formales • El modelo de técnicas de cuarta generación

  6. PROYECTO Para gestionar un proyecto de software con éxito, debemos Comprender qué puede ir mal (para evitar esos problemas) y como hacerlo bien. Se definen 10 señales que indican que un proyecto esta en peligro: • La gente de software no comprende las necesidades de los clientes • El ámbito del producto está definido pobremente • Los cambios están mal realizados • La tecnología cambia • Las necesidades del negocio cambian (o están mal definidas) • Las fechas de entrega no son realistas • Los usuarios se resisten • Se pierden los patrocinadores • El equipo del proyecto carecen del personal con las habilidades apropiadas • Los gestores (y los desarrolladores) evitan buenas prácticas y sabias lecciones

More Related