Teoria de Administracion de Proyectos

Visión General de la Administración de Proyectos 1

Administración de Proyectos InformáticosTema 5

VISIÓN GENERAL DE LA VISIÓN GENERAL DE LA ADMINISTRACIÓN DE PROYECTOSADMINISTRACIÓN DE PROYECTOS

1. Introducción2. Áreas de gestión de proyectos3. Bases del desarrollo de software

3.1 Bases de gestión3.2 Bases técnicas3.3 Bases de control de calidad

4. Procesos del proyecto5. Madurez del proceso6. Organización de un proyecto

6.1 Decisión estratégica6.2 El equipo de trabajo

7. Herramientas de ayuda7.1. Tipos de herramientas7.2. Criterios de selección

8. Teoría W


Administración de Proyectos Informáticos

1. Introducción1. Introducción

Conceptos básicos [PMI, 2003] :– Proyecto: Conjunto de actividades dirigidas a crear un único

producto, servicio o resultado– Programa: grupo de proyectos relacionados que se

gestionan de forma coordinada para obtener unos beneficios y un control que no es posible obtener gestionándolos individualmente

– Porfolio (“portfolio”): colección de proyectos y/o programas que se agrupan para facilitar la gestión efectiva del trabajo y conseguir los objetivos estratégicos de negocio

La gestión de proyectos es la aplicación de conocimientos, habilidades, herramientas y técnicas a las actividades de un proyecto para conseguir los requisitos del proyecto La gestión de programas es la gestión coordinada y centralizada de un programa para obtener las beneficios y objetivos estratégicos del programaLa gestión de porfolios la gestión centralizada de uno o más porfolios, incluyendo identificación, priorización, autorización, gestión y control de proyectos, programas y otros trabajos relacionados para conseguir objetivos estratégicos de negocio específicos



1. Introducción1. Introducción

La gestión de proyectos opera en un entorno en el que hay que considerar:– El ciclo de vida y las fases del proyecto: determinan las

actividades de gestión que hay que realizar y la forma y el momento de realización de las mismas

– Personas y organizaciones involucradas en el proyecto (stakeholders):

» el equipo de gestión del proyecto debe identificar a los stakeholders y determinar y gestionar sus requisitos para asegurar el éxito del proyecto

» Los stakeholders clave son el gestor responsable del proyecto, el cliente, la organización encargada del desarrollo del proyecto, los miembros del equipo del proyecto y el patrocinador del proyecto

– Influencias de la organización: cultura, normas, política, estructura organizativa que tienen influencia en el proyecto

– Prácticas clave de gestión: prácticas que afectan a la mayoría de los proyectos

– Influencias del entorno socioeconómico: estándares, reglamentos, culturas, internacionalización, impacto social, etc.



2. Áreas de la gestión de proyectos2. Áreas de la gestión de proyectos

Las actividades de gestión de proyectos se agrupan en nueve áreas:– Gestión de la integración del proyecto: procesos necesarios

para asegurar la adecuada coordinación de los elementos del proyecto

– Gestión del alcance del proyecto: procesos para asegurar que el proyecto incluye el trabajo requerido

– Gestión del tiempo: procesos que aseguran la terminación del proyecto a tiempo

– Gestión del coste: procesos que aseguran la realización del proyecto con el presupuesto aprobado

– Gestión de la calidad: procesos para asegurar la satisfacción de las necesidades establecidas

– Gestión de recursos humanos: procesos necesarios para hacer más efectivo el trabajo de las personas implicadas en el proyecto

– Gestión de las comunicaciones: procesos que aseguran que la generación, recolección diseminación y almacenamiento de la información del proyecto se realice de la forma apropiada y a tiempo

– Gestión de riesgos: procesos relacionados con la identificación, análisis y respuesta a los riesgos del proyecto

– Gestión de las adquisiciones: procesos para la adquisición de bienes y servicios fuera de la organización



Áreas de la gestión de proyectosÁreas de la gestión de proyectos

Gestión de ProyectosGestión de Proyectos

Gestión de laintegración

Desarrollo del plan del proyectoEjecución del plan del proyectoControl de cambios integrado

Gestión del alcance

IniciaciónPlanificación del alcanceDefinición del alcanceVerificación del alcanceControl de cambios del alcance

Gestión del tiempo

Definición de actividadesSecuenciación de actividadesEstimación de la duraciónDesarrollo de la programaciónControl de la programación

Gestión delcoste

Planificación de recursosEstimación del costePresupuestación del costeControl del coste

Gestión de lacalidad

Planificación de la calidadAseguramiento de la calidadControl de la calidad

Gestión de recursos humanos

Planificación organizativaAdquisición de personalDesarrollo del equipo

Gestión decomunicaciones

Planificación de comunicacionesDistribución de la informaciónInforme de la ejecuciónCierre administrativo

Gestión del riesgo

Planificación de la gest. riesgoIdentificación del riesgoAnálisis cualitativo del riesgoAnálisis cuantitativo del riesgoPlanificación respuesta al riesgoControl y monitoriz. del riesgo

Gestión de las adquisiciones

Planificación de la adquisiciónPlanificación de la solicitudSolicitudSelección de fuentesAdministración del contratoCierre del contrato

Figura 1. Actividades de gestión de proyectos



3. Bases del desarrollo de software3. Bases del desarrollo de software

Bases de gestión– Consiste en determinar el tamaño del producto, asignar los

recursos apropiados a un producto de ese tamaño, crear un plan para aplicar esos recursos y controlar y dirigir los recursos para evitar que el proyecto se desvíe

– La gestión controla las tres magnitudes del triángulo planificación-coste-producto

– Bases: estimación, planificación, seguimiento y mediciónBases técnicas– Se refiere a la utilización de métodos de desarrollo.– Incluye:

» Gestión de requisitos» Diseño» Construcción» Gestión de la configuración del Software

Bases de control de calidad– Control dirigido a asegurar la calidad :

» del proceso» del producto

– Actividades del control de calidad:» Seguimiento» Revisiones» Pruebas



Bases del desarrollo de softwareBases del desarrollo de software3.1. Bases de gestión3.1. Bases de gestión

Estimación y planificación

– Las etapas básicas iniciales de cualquier proyecto de software son, en primer lugar, estimar el tamaño del producto, luego estimar el esfuerzo necesario para construir un producto con ese tamaño y por último realizar la planificación basándose en la estimación del esfuerzo.

– La planificación de un proyecto software incluye las siguientes actividades:

» Estimación y planificación» Determinar el número de participantes» Organizar el equipo de trabajo» Elegir el modelo de ciclo de vida a seguir» Gestión de riesgos» Tomar decisiones estratégicas

Tiempos

Recursos

Secuencia

de tareas

Fecha de

comienzo

Estimación Planificación Calendario

Figura 2. Estimación y planificación de un proyecto



Bases del desarrollo de softwareBases del desarrollo de softwareBases de gestiónBases de gestión

Seguimiento– Después de la planificación del proyecto hay que realizar un

seguimiento del proceso de desarrollo para asegurar que se está cumpliendo el plan previsto: objetivos de planificación, coste y calidad.

– Las actividades de seguimiento:» nivel de gestión: listas de tareas, informes sobre el

estado, informes de presupuesto, revisiones de hitos ...» nivel técnico: intervenciones y revisiones técnicas y

entradas de calidad que controlan la finalización de los hitos.

– Uno de los problemas típicos de los proyectos reales es la visibilidad de la gestión del proyecto. En un proyecto ideal, en todo momento se tiene el 100% de visibilidad.

Medidas – Recogida de datos métricos para analizar la calidad y la

productividad del software.– La obtención de datos históricos proporciona las bases para

la planificación de proyectos futuros.– Las métricas mejoran la visibilidad del estado del proyecto.



Bases del desarrollo de softwareBases del desarrollo de software3.2. Bases técnicas3.2. Bases técnicas

Gestión de requisitos– Proceso consistente en reunir requisitos, plasmarlos en un

documento, hacer un seguimiento del diseño y del código y gestionar los cambios para el resto del proyecto.

– Bases de la gestión de requisitos:» Metodologías de análisis de requisitos» Métodos para crear el modelo del sistema» Métodos de comunicación» Relaciones entre la gestión de requisitos y los diferentes

modelos de ciclo de vida

Diseño– Bases de la arquitectura y el diseño:

» Principales estilos de diseño» Conceptos fundamentales del diseño (ocultamiento de

la información, modularidad, abstracción ...)» Enfoques de diseño estándar en áreas conflictivas

(manejo de excepciones, rendimiento, E/S...)» Consideraciones del diseño propias del dominio de la

aplicación» Esquema de arquitectura» Uso de herramientas de diseño



Bases del desarrollo de softwareBases del desarrollo de softwareBases técnicasBases técnicas

Construcción– Bases de la construcción:

» Metodos de codificación» Directrices de uso de datos específicos» Conceptos relativos al control» Aserciones y otros métodos de detección de errores

basados en el código» Reglas para compactar código» Métodos de depuración y comprobación de unidades» Estrategias de integración (incremental, big-bang...)» Detalles del lenguaje de programación» Uso de herramientas de construcción

Gestión de las configuraciones– Método de gestión de los componentes del proyecto, de

forma que el proyecto permanezca en estado consistente.– Incluye métodos para evaluar los cambios, seguirlos,

manejar las versiones y guardar copias de la evolución.– La gestión de configuraciones (SCM) se considera un

método de garantía o control de calidad.– El componente del proyecto más controlado suele ser

código fuente, pero se puede aplicar SCM a los requisitos, planes, diseño, casos de prueba, etc.



Bases del desarrollo de softwareBases del desarrollo de software3.3. Bases de control de calidad3.3. Bases de control de calidad

Seguimiento:– Es la comprobación periódica del cumplimiento de las

previsiones. – Tiene dos aspectos diferenciados:

» Comprobación de la funcionalidad: control de calidad del producto.

» Comprobación de la planificación: control de calidad del proceso (eficiencia y productividad).

SEGUIMIENTO DE LA FUNCIONALIDAD

FUNCIÓN

CALIDAD

PLAN DE PRUEBAS

CONTROL CALIDAD

SEGUIMIENTO DE LA PLANIFICACIÓN

RENDIMIENTO

CAMBIO DE OBJETIVOS

( o causas externas)

MEJORA DEPRODUCTIVIDAD,

AUMENTO DETIEMPO O RECURSOS

REVISARPLANIFICACIÓN

Figura 3. Aspectos del seguimiento de un proyecto



Bases del desarrollo de softwareBases del desarrollo de softwareBases de control de calidadBases de control de calidad

RevisionesSon técnicas estáticas que se aplican en varios momentos del desarrollo del software y sirven para detectar defectos que puedan así ser eliminados.

Tipos de revisiones (IEEE Std. 1028):

– Revisiones de gestión: sirven para controlar el progreso y detectar inconsistencias de los planes con la programación y los requisitos.

– Revisiones técnicas: revisan la documentación producida a lo largo del proyecto.

– Inspecciones: revisiones que involucran al autor de un producto.

– Walkthrough: inspecciones conducidas únicamente por miembros del grupo de desarrollo que examinan una parte específica del producto.

– Auditorías: evaluaciones independientes sobre el cumplimiento de estándares, planes, procedimientos ...



Bases del desarrollo de softwareBases del desarrollo de softwareBases de control de calidadBases de control de calidad

Pruebas– Es el método más común de control de calidad. Su objetivo

es la detección de errores mediante la ejecución de los programas.

– La prueba puede afectar de manera indirecta a la planificación del proyecto si pone de manifiesto que la calidad del producto es demasiado baja para lanzarlo.

– Para atenuar el efecto negativo sobre la planificación es necesario preparar un plan que permita corregir los errores tan pronto como sea posible.

– Niveles de prueba:» Pruebas de unidad: se dirigen a módulos o clases

individuales. » Pruebas de subsistemas: determinan si un subsistema

trabaja como se esperaba.» Pruebas del sistema: sirven para confirmar que el

sistema se comporta como el usuario desea.



4. Procesos del proyecto4. Procesos del proyecto

Proceso: sucesión de acciones que dan lugar a un resultado

Categorías de procesos [PMI, 2000]: – Procesos orientados al producto: especifican y crean el

producto del proyecto– Procesos de gestión del proyecto: describen, organizan y

completan el trabajo proyectoSe organizan en cinco grupos:

» Procesos de iniciación: autorizan el proyecto o una fase» Procesos de planificación: definición y refinamiento de

objetivos y selección de la mejor alternativa» Procesos de ejecución: coordinación de recursos para

ejecutar el plan» Procesos de control: monitorización y medición del

progreso» Procesos de cierre: formalización de aceptación

Iniciación Planificación

Control Ejecución

CierreFlujo de información

Figura 4. Enlaces entre grupos de procesos en una fase



Procesos del proyectoProcesos del proyecto

Procesos de iniciación– Estudio de la viabilidad– Estudio preliminar de los requisitos– Concepto de operaciones– Plan preliminar

Procesos de planificación– Procesos principales (“core”): Definición y planificación

del alcance, definición, secuenciación y estimación de la duración de las actividades, desarrollo de la programación (“schedule”), planificación de la gestión de riesgos, planificación de los recursos, estimación y presupuestacióndel coste, desarrollo del plan del proyecto

– Procesos de facilitación: Planificación de la calidad, planificación organizativa, adquisición de personal, planificación de las comunicaciones, identificación del riesgo, análisis cualitativo y cuantitativo del riesgo, planificación de la respuesta al riesgo

Procesos de ejecución– Ejecución del plan del proyecto– Aseguramiento de la calidad– Desarrollo del equipo– Distribución de la información– Solicitud– Selección de fuentes– Administración del contrato



Procesos del proyectoProcesos del proyecto

Procesos de control– Control de cambios integrado– Verificación del alcance– Control de cambios del alcance– Control de la programación– Control del coste– Control de la calidad– Informe de la ejecución– Control y monitorización de riesgos

Procesos de cierre– Cierre del contrato– Cierre administrativo

Comienzo de la fase

Fin de la fase

Tiempo

Procesos de

iniciación

Procesos de planificación

Procesos de ejecución

Procesos de controlProcesos de

cierre

Nivelde

actividad

Figura 5. Solapamiento de procesos en una fase



5. Madurez del proceso5. Madurez del proceso

El SEI (Software Engineering Institute) ha desarrollado un modelo de capacidad de madurez (CMM) con cinco niveles:

– Nivel 1 (Inicial): se definen pocos procesos– Nivel 2 (Repetible): se establecen los procesos de gestión

del proyecto para hacer un seguimiento del coste, de la planificación y de la funcionalidad.

– Nivel 3 (Definido): El proceso del software de las actividades de gestión y de ingeniería se documenta, se estandariza y se integra dentro de un proceso de software de toda una organización.

– Nivel 4 (Gestionado): Se recopilan medidas detalladas del proceso de software y de la calidad del producto.

– Nivel 5 (Optimización): Mediante un resultado cuantitativo del proceso y de las ideas y tecnologías innovadoras se posibilita una mejora del proceso.

El SEI ha asociado áreas clave del proceso (ACP) a cada nivel. Cada una de ellas describe las funciones de la ingeniería del software que se deben presentar para satisfacer una buena práctica en un nivel particular.Cada ACP se describe identificando las siguientes características: Objetivos, compromisos, capacidades, actividades, métodos para supervisar la implementación y métodos para verificar la implementación.



Madurez del procesoMadurez del procesoNiveles de madurezNiveles de madurez

En cada nivel se deberían lograr las siguientes ACP:

Niveles de madurez Áreas claves

Nivel 2 Gestión de configuracionesGarantía de calidadGestión de subcontratación del softwareSeguimiento y supervisión del proyectoPlanificación del proyectoGestión de requisitos

Nivel 3 Revisiones periódicasCoordinación entre gruposIngeniería de productos de softwareGestión de integración del softwarePrograma de formaciónDefinición del proceso de la organizaciónEnfoque del proceso de la organización

Nivel 4 Gestión de calidad del softwareGestión cuantitativa del proceso

Nivel 5 Gestión de cambios del procesoGestión de cambios de tecnologíaPrevención de defectos

Cada ACP define un conjunto de prácticas clave (normas procedimientos y actividades que deben ocurrir antes de que se haya instituido completamente un área de proceso clave.Cada nivel contiene todas las ACP’s del nivel anterior.



6. Organización de un proyecto6. Organización de un proyecto6.1. Decisión estratégica6.1. Decisión estratégica

La decisión de llevar a cabo un proyecto debe considerarse una decisión estratégica , por cuanto es capaz de influir en el funcionamiento y, por tanto, en la rentabilidad de la empresa.En un entorno informatizado y estable la decisión de iniciar un proyecto viene dada por:

– Una nueva necesidad– Una evolución o cambio importante– Una mejora por una informatización deficiente

Cuando se crea o se cambia el entorno informático, debe considerarse el proyecto encuadrado en un plan de sistemas dentro de la estrategia empresarial.El plan de sistemas decide las necesidades de información.El plan estratégico está orientado a conseguir la información necesaria. Hay que considerar:– La situación actual– La situación deseada– Las distintas alternativas

Además hay que tener en cuenta:– La viabilidad: Siempre debe considerarse la necesidad de

abordar un proyecto teniendo en cuenta los recursos de los que se dispone o se puede disponer.

– La rentabilidad: relación entre los costes y el beneficio esperado.



Organización de un proyectoOrganización de un proyecto6.2. El equipo de trabajo 6.2. El equipo de trabajo

Reglas básicas:– Cada equipo debe ser lo suficientemente pequeño para ser

controlable y manejable.– Cada equipo deberá realizar las tareas que conduzcan a un

nivel de interacción con otros equipos.– Cada equipo deberá realizar las tareas que constituyan una

gran cohesión.

Tipos de equipos (Larson y LaFasto, 1989):– Para la resolución de problemas: se centra en resolver un

problema complejo, poco definido.– Para creatividad: su objetivo es explorar posibilidades y

alternativas.– Para ejecución táctica: su misión es la ejecución de un plan

bien definido.

Características adicionales:– Papeles y responsabilidades claros.– Monitorización del rendimiento individual y realimentación.– Comunicación efectiva.– Toma de decisiones basada en hechos.



Organización de un proyectoOrganización de un proyectoEl equipo de trabajoEl equipo de trabajo

Estructura y funciones del equipo

Jefe de proyecto

Soporte métodos e instrumentos

AdministraciónDocumentación

Seguro y control de calidad

Figura 6. Organización de un equipo de proyecto

– Jefe de proyecto: sus funciones son planificar, coordinar y controlar.

– Administración y documentación: labor de asistir al jefe de proyecto en la administración (planificación, reuniones, etc.) así como en la documentación durante todo el proyecto.

– Soporte de métodos e instrumentos: función de asistencia a los miembros del equipo en el uso de métodos y herramientas.

– Seguro y control de calidad: revisión del proyecto para asegurar la calidad de los documentos, principalmente empleando técnicas de lectura cruzada.




Modelos de equipo– Equipo de negocios: grupo de personas con el mismo estatus

y diferente ámbito de experiencia, encabezados por un jefe técnico.

– Equipo con programador jefe: fue concebido por IBM y popularizado por Brooks (Brooks, 1975, 1995). En este equipo, los programadores jefe son los más productivos, ellos realizan la especificación completa, el diseño, y la mayoría del código de producción. El resto de los miembros se especializan en tareas concretas.

– Equipo en la sombra: aglutina un grupo de desarrolladores de productos creativos. Éstos son liberados de las restricciones burocráticas habituales y tienen libertad para desarrollar e innovar.

– Equipo de prestaciones: el desarrollo, el control de calidad, la documentación, la gestión del programa y el marketing están organizados con las estructuras tradicionales jerárquicas de responsabilidad. Cada equipo toma uno o más miembros de estos grupos y les asigna la responsabilidad de una parte de la funcionalidad del producto (McCarthy, 1995).

– Equipo SWAT: grupo de personas con una sólida formación en una herramienta o método determinado que se dedican a resolver un problema que se adapta perfectamente a esa herramienta o método.

– Otros modelos: equipo de búsqueda y rescate, equipo profesional de atletismo, equipo de teatro...




Grandes equipos– Los equipos grandes plantean problemas especiales de

comunicación y coordinación. – Todos los métodos para simplificar las comunicaciones se

basan en la creación de grupos pequeños y la asignación de responsables dentro de cada grupo. La creación de los grupos se puede hacer de varias formas:

» Jerárquica o descentralizada controlada (DC): Existe un jefe del proyecto y jefes secundarios responsables de diferentes partes del proyecto.

» En red o descentralizada democrática (DD): Existe uno o varios coordinadores no permanentes.

» En estrella o centralizada coordinada (CC): Hay un jefe de equipo que se encarga de realizar tareas de alto nivel y coordinar al resto de los miembros.

DC DD CC

Figura 7. Formas de organización de equipos



7. Herramientas de ayuda7. Herramientas de ayuda7.1. Tipos de herramientas 7.1. Tipos de herramientas

Clasificación de las herramientas CASE :

Análisis Diseño Implementación Prueba Mantenimiento

Herramientasde Gestión

PLANIFICACIÓN DIMENSIONAMIENTO

SEGUIMIENTO

HerramientasTécnicas

CASESUPERIORES

CASEINFERIORES

GENERADORESDE CÓDIGO

HERRAMIENTASDE PRUEBA

HERRAMIENTASDE MANTENIMIENTO

CASE INTEGRADO LENGUAJES DE 4ª GENERACIÓN

Herramientasde Soporte

SISTEMA DE REPOSITORIO/DICCIONARIO

CONTROL DE CONFIGURACIÓN SERVICIOS DE SEGURIDAD

Figura 8. Categorías de herramientas CASE

Herramientas CASE de gestión:– De planificación de proyectos: Ayudan a definir las tareas y

a representar las interdependencias entre ellas.– De análisis de riesgos: permiten construir tablas de riesgos

que facilitan la identificación y el análisis de dichos riesgos.– Administración de proyectos: son herramientas de

seguimiento del proyecto y proporcionan una indicación de la calidad del producto.

– De métricas y gestión: capturan métricas específicas del proyecto que proporcionan una indicación global de la calidad o de la productividad.

– De documentación: herramientas de producción de documentos y de autoedición.

– De control de calidad: la mayoría realizan una auditoría del código fuente para ver si se ajusta a ciertos estándares del lenguaje.



Herramientas de ayudaHerramientas de ayuda7.2. Criterios de selección7.2. Criterios de selección

Beneficios estimados: es necesario estimar la eficiencia que se espera ganar con su uso.Estabilidad del vendedor: – Tiempo que lleva en el negocio– ¿La herramienta entra en la línea principal de trabajo?– ¿Podría ser soportada por otra empresa? ...

Calidad: la calidad de la herramienta va a influir en la calidad de la aplicación que se va a realizar con ella.Madurez: generalmente las primeras versiones de las herramientas no tienen mucha calidad.Tiempo de formación: hay que considerar si alguna persona del equipo tiene experiencia directa con la herramienta y la productividad que se perderá en la curva de aprendizaje.Aplicabilidad: asegurarse de que la herramienta es aplicable al proyecto y no hay que forzar su adaptación.Compatibilidad con otras herramientas en uso.Ámbito de crecimiento: deberá soportar el probable crecimiento del producto (sistema de software).Personalización de los criterios: asegurarse de comprar la herramienta según criterios propios.Compromiso: una vez seleccionada la herramienta debe usarse y no cambiarla a mitad del proyecto.



8. Teoría W8. Teoría W

La teoría W (Boehm y Ross, 1989) proporciona un entorno de trabajo para la gestión de proyectos orientado a la reconciliación de intereses opuestos.Está diseñada para su uso combinado con el modelo de ciclo de vida en espiral.La mayoría de los proyectos comienzan con un grupo de implicados que tienen intereses contrapuestos, como puede observarse en la tabla siguiente:

Clientes Jefes DesarrolladoresUsuariosFinales Mantenimiento

Planificaciónrápida

Sinretrasos

Diseñointeresante

Muchasprestaciones

Sin defectos

Presupuestobajo

Sinsorpresas

Exploración denuevas técnicas

Softwareamigable

Buenadocumentación

Éxito en elproyecto

Trabajoagradable

Softwarerápido

Fácilmentemodificable

OBJETIVOS

Softwarerobusto

Aspectos de la teoría W:– Objetivos más claros del proyecto: el proyecto comienza

identificando las condiciones de éxito de los implicados.– Mejores relaciones con el cliente: mejora de la eficiencia

por la mejor comunicación, planificación más realista ...– Reducción del riesgo relacionado con el cliente.



Teoría WTeoría W

Pasos de la teoría W:

1. Establecer un conjunto de precondiciones donde todos ganen antes de iniciar el proyecto:

– Comprender la forma en que las personas quieren ganar.– Establecer expectativas razonables por parte de todos los

implicados.– Adecuar las tareas de las personas con sus condiciones de

éxito.– Proporcionar un entorno que soporte los objetivos del

proyecto.2. Estructurar un proceso de software en donde todos ganen:

– Establecer un plan realista.– Utilizar el plan para controlar el proyecto.– Identificar y gestionar los riesgos donde todos pierden o

donde unos pierden y otros ganan.– Mantener implicadas a las personas.

3. Estructurar un producto software con el que todos ganen:– Adecuar el producto a las condiciones de éxito de los

usuarios finales y de las personas de mantenimiento.



BIBLIOGRAFÍABIBLIOGRAFÍA

Boehm, B. y Ross, R., Theory-W Software Project Management: Principles andExamples, IEEE Transaction on Software Engineering, 1989.

Brooks, F., The Mythical Man-Month, Anniversary Edition, Addison-Wesley, 1995.

Juan, A. y Pérez, P., La Auditoría en el Desarrollo de Proyectos Informáticos, Ed. Diazde Santos, 1988.

IEEE Standard for Software Project Management Plans, New York, IEEE, 1987. (IEEE/ANSI Standard 1058.1-1987).

Larson, C. y LaFasto, F., Teamwork: What Must Go Right; What Can Go Wrong. Sage, 1989.

McCarthy, J., Dynamics of Software Development, Microsoft Press, 1995.

McConnell, S., Desarrollo y gestión de proyectos informáticos, Mc Graw Hill 1997.

Paulk, M. et al., Capability Maturity Model for Software, Software EngineeringInstitute, Carnie Mellon University, Pittsburgh, P.A., 1993.

PMI (Project Management Institute), A Guide to the Project Management Body ofKnowledge (PMBOK Guide), 2000.

PMI (Project Management Institute), PM Standards Program, 2003.

Pressman, R.S., Ingeniería del Software, un enfoque práctico, Mc Graw Hill, 1998.

Puig, J., Proyectos Informáticos. Planificación, Desarrollo y Control, Paraninfo, 1994.

Quang, P. Y Gonin J., Dirección de proyectos informáticos, Eyrolles, 1994.

Teoria de Administracion de Proyectos

Documents

Transcript of Teoria de Administracion de Proyectos