1. Introduccin 1.1 Importancia de la administracin de proyectos de software: Crisis del software.(TB), 1.

2 certificaciones (MS ), PMB y software(projet u otros) (Todo en resumen) 1.3 El reto de la administracin de los proyectos del software: que es un proyecto, y como se dirige un proyecto, tipos de proyectos(TB y PMB) 2. Componentes Clave del Desarrollo del Software 2.0 Modelo dinmico (TB). 2.1 Planeacin(TB) 2.2 Como organizar por procesos: Direccin, Gerencias: calidad, administracin(y operacin) y procesos (MS) 2.3 Grupos de procesos de planificacin (PMB) 2.4 Modelos actuales de para administracin de proyectos(PMB) 2.5 reas de conocimiento(PMB) 2.6 Planes estratgicos, comunicacin, riesgos, econmicos, etc(MS) 3. Administracin de los Recursos Humanos 3.1 Clasificacin(TB) 3.2 Gestin de recursos humanos(PMB) 3.3 Roles (MS) 4. Produccin y Desarrollo del Software 4.0 clasificacin de produccin y desarrollo y explicacin(TB) 4.1 Ciclo vida del proyecto(TB) (PMB) 4.2 Procesos bsicos necesarios a verificar(MS) 5. Aseguramiento de la Calidad Que es calidad y tipos de calidad, ISO y Certificaciones Practicas para evaluar (MS) Planificacin aseguramiento y control (PMB) 6. Pruebas del Sistema Planes de pruebas y riesgos 7. Control y Planeacin Como seguir el modelo 8. Un Caso de Estudio

Temario

Crisis del Software

Historia Sntomas Factores

de Influencia Posibles Causas

Historia El trmino crisis del software se acu en 1968, en la primera conferencia organizada por la OTAN sobre desarrollo de software y con l se etiquetaron los problemas que surgan en el desarrollo de sistemas de software. En la misma conferencia se utiliz por primera vez el trmino "ingeniera del software" para describir el conjunto de conocimientos que existan en aquel estado inicial.

Algunas referencias tiles para comprender cules eran los conocimientos estables para el desarrollo de software en 1968 son:

En 1962 se public el primer algoritmo para bsquedas binarias. C.Bhm y G. Jacopini publicaron en 1966 el documento que creaba una fundacin para la eliminacin de "GoTo" y la creacin de la programacin estructurada. En 1968 los programadores se debatan entre el uso de la sentencia GoTo, y la nueva idea de programacin estructurada; ese era el caldo de cultivo en el que Edsger Dijkstra escribi su famosa carta "GoTo Statement Considered Harmful" en 1968.

La primera publicacin sobre programacin estructurada no vio la luz hasta 1974, publicada por Larry Constantine, Glenford Myers y Wayne Stevens. El primer libro sobre mtrica de software fue publicado en 1977 por Tom Gilb. El primer libro sobre anlisis de requisitos apareci en 1979. El trmino fue usado para referirse a los rpidos incrementos de la tecnologa en la computacin y la complejidad de los problemas a los cuales pudieran enfrentarse. En efecto, se refiere a la dificultad de escribir correcta, entendible y verificablemente los lenguajes de programacin. Las races de la crisis del software son complejas y variables.

Uno de los principales problemas en el desarrollo de software de hoy, es que muchos proyectos empiezan la programacin tan pronto se definen y concentran mucho de su esfuerzo en la escritura de cdigo. ltimamente el desarrollo de software se a ralentizado. El estudio de este fenmeno es importante porque la existencia de software cientfico libre facilita que cualquier laboratorio del mundo pueda desarrollar ciencia libre usando este software como herramienta de trabajo.

 Algunos

sntomas que indican que el software se encuentra en un periodo de crisis son: Baja Calidad del Software. Tiempo y Presupuesto Excedido. Confiabilidad Cuestionable. Altos Requerimientos de Personal para desarrollo y mantenimiento.

FACTORES DE INFLUENCIA

Para poder llevar el estado del proceso de software como un estado de crisis, los crticos han destacado ciertas caractersticas que han permitido esta postura del software respecto a otras etapas de su corta historia. Algunos de esos factores son: Aumento del poder computacional. Reduccin del costo del hardware. Rpida obsolescencia de hardware y software.

Aceptacin de la computarizacin en las empresas. Incremento en el nmero de usuarios de los sistemas de software. Tipo de usuario no homogneo aun en sistemas hechos a la medida. Personal desarrollado y mantenimiento diferente.

La magnitud del proyecto impacta en: Tiempo costo y nmero de desarrolladores

Control administrativo y detalles tcnicos Aumento en el conocimiento del problema. Cambios en el entorno:

Tecnolgicos (Internet, redes, ERP, CRM, SCM). Econmicos (crisis econmicas, globalizacin, etctera). Sociales (nuevas necesidades, costumbres nuevas, etctera).

POSIBLES CAUSAS DE LA CRISIS DEL SOFTWARE

Hay varias razones que pueden ser propuestas como causa de la crisis. No son mutuamente excluyentes; de hecho, es posible que la verdadera causa sea una mezcla de todas ellas. Sin embargo, todas tienen en comn que son causadas por el mtodo de valorar los avances cientficos y el mecanismo actual de financiacin de la actividad cientfica. Las causas de la crisis del software fueron vinculadas a la complejidad en general del proceso de software y a la relativa inmadurez de la ingeniera de software como una profesin. La crisis se manifest a s misma en varias maneras:

Proyectos gestionados con un sobrepresupuesto. Proyectos gestionados con sobre tiempo. Software de baja calidad. El software a menudo no satisfaca los requerimientos deseados. Los proyectos fueron inmanejables, con un cdigo difcil de mantener.

La crisis del software fue dirigida por la implementacin de varios procesos y metodologas.

1.2 Reto Admi..MOPROSOFT1

El

propsito de este documento es presentar un Modelo de Procesos para la Industria de Software (MoProSoft) en Mxico que fomente la estandarizacin de su operacin a travs de la incorporacin de las mejores prcticas en gestin e ingeniera de software.

MOPROSOFT2
La

adopcin del modelo permitir elevar la capacidad de las organizaciones para ofrecer servicios con calidad y alcanzar niveles internacionales de competitividad

PMBOOK1
Los

Fundamentos de la Direccin de Proyectos constituyen la suma de conocimientos en la profesin de direccin de proyectos. Al igual que en otras profesiones, como la abogaca, la medicina o las ciencias econmicas, los conocimientos residen en los practicantes y acadmicos que los aplican y los

PMBOOK2
desarrollan.

Los Fundamentos de la Direccin de Proyectos completos incluyen prcticas tradicionales comprobadas y ampliamente utilizadas, as como prcticas innovadoras que estn emergiendo en la profesin, incluyendo material publicado y no publicado.

PMBOOK3
Como

consecuencia, los Fundamentos de la Direccin de Proyectos estn en constante evolucin.

Proyecto PM
Un

proyecto es un esfuerzo temporal que se lleva a cabo para crear un producto, servicio o resultado nico
Temporal significa que cada proyecto tiene un comienzo definido y un final definido. El final se alcanza cuando se han logrado los objetivos del proyecto o cuando queda claro que los objetivos del proyecto no sern o no podrn ser alcanzados, o cuando la necesidad del proyecto ya no exista y el proyecto sea cancelado.

Proy2

Temporal no necesariamente significa de corta duracin; muchos proyectos duran varios aos. En cada caso, sin embargo, la duracin de un proyecto es limitada. Los proyectos no son esfuerzos continuos. La mayora de los proyectos se emprenden para obtener un resultado duradero. Por ejemplo, un proyecto para erigir un monumento nacional crear un resultado que se espera que perdure durante siglos. Con frecuencia, los proyectos tambin pueden tener impactos sociales, econmicos y ambientales, intencionales o no, que perduran mucho ms que los propios proyectos.

Producto del proyecto

resultados. Los proyectos pueden crear: Un producto o artculo producido, que es cuantificable, y que puede ser un elemento terminado o un componente La capacidad de prestar un servicio como, por ejemplo, las funciones del negocio que respaldan la produccin o la distribucin Un resultado como, por ejemplo, salidas o documentos. Por ejemplo, de un proyecto de investigacin se obtienen conocimientos que pueden usarse para determinar si existe o no una tendencia o si un nuevo proceso beneficiar a la sociedad.

Producto

La singularidad es una caracterstica importante de los productos entregables de un proyecto. Por ejemplo, se han construido muchos miles de edificios de oficinas, pero cada edificio individual es nico: diferente propietario, diferente diseo, diferente ubicacin, diferente contratista, etc. La presencia de elementos repetitivos no cambia la condicin fundamental de nico del trabajo de un proyecto.

Elaboracin Gradual

La elaboracin gradual es una caracterstica de los proyectos que acompaa a los conceptos de temporal y nico. Elaboracin gradual significa desarrollar en pasos e ir aumentando mediante incrementos1. Por ejemplo, el alcance de un proyecto se define de forma general al comienzo del proyecto, y se hace ms explcito y detallado a medida que el equipo del proyecto desarrolla un mejor y ms completo entendimiento de los objetivos y de los productos entregables.

La elaboracin gradual de las especificaciones de un proyecto debe ser coordinada cuidadosamente con la definicin adecuada del alcance del proyecto, particularmente si el proyecto se ejecuta en virtud de un contrato. Una vez definido correctamente, el alcance del proyecto el trabajo a realizar deber controlarse a medida que se elaboran gradualmente las especificaciones del proyecto y del producto. La relacin entre el alcance del producto y el alcance del proyecto se trata ms adelante, en la introduccin del Captulo 5.

Los siguientes ejemplos ilustran la elaboracin gradual en dos reas de aplicacin diferentes.

El desarrollo de una planta de procesamiento qumico comienza con la ingeniera de proceso que define las caractersticas del proceso. Estas caractersticas se utilizan para disear las unidades de procesamiento principales. Esta informacin se convierte en la base para el diseo de ingeniera, que define tanto el plano detallado de la planta como las caractersticas mecnicas de las unidades de proceso y las instalaciones auxiliares. Todo ello resulta en dibujos de diseo que se elaboran para crear dibujos de fabricacin y construccin. Durante la construccin, se realizan las interpretaciones y

adaptaciones que sean necesarias, que estn sujetas a la aprobacin correspondiente. Esta elaboracin adicional de los productos entregables se refleja en dibujos que se realizan sobre la marcha, y los ajustes operativos finales se realizan durante la etapa de pruebas y rotacin. El producto de un proyecto de desarrollo econmico puede definirse inicialmente como: Mejorar la calidad de vida de los residentes con ingresos ms bajos de la comunidad X. A medida que el proyecto avanza, los productos

pueden describirse ms especficamente como, por ejemplo: Proporcionar acceso a agua y comida a 500 residentes de bajos ingresos de la comunidad X. La siguiente etapa de elaboracin gradual podra centrarse exclusivamente en mejorar la produccin y comercializacin agrcola, considerando la provisin de agua como una segunda prioridad, a ser iniciada una vez que el componente agrcola est en una etapa avanzada. Forma de resolucin: Divide y vencers; De un problema grande obtn varios problemas chicos.

Proceso MS
Conjunto

de prcticas relacionadas entre si, llevadas a cabo a travs de roles y por elementos automatizados, que utilizando recursos y a partir de insumos producen un satisfactor de negocio para el cliente.

Criterios: 1. Generar una estructura de los procesos que est acorde con la estructura de las organizaciones de la industria de software (Alta Direccin, Gestin y Operacin). 2. Destacar el papel de la Alta Direccin en la planificacin estratgica, su revisin y mejora continua como el promotor del buen funcionamiento de la organizacin. 3. Considerar a la Gestin como proveedor de recursos, procesos y proyectos, as como responsable de vigilar el cumplimiento de los objetivos estratgicos de la organizacin.

Modelo de Procesos MS

4. Considerar a la Operacin como ejecutor de los proyectos de desarrollo y mantenimiento de software. 5. Integrar de manera clara y consistente los elementos indispensables para la definicin de procesos y relaciones entre ellos. 6. Integrar los elementos para la administracin de proyectos en un solo proceso. 7. Integrar los elementos para la ingeniera de productos de software en un solo marco que incluya los procesos de soporte (verificacin, validacin, documentacin y control de configuracin).

8. Destacar la importancia de la gestin de recursos, en particular los que componen la base de conocimiento de la organizacin tales como: productos generados por proyectos, datos de los proyectos, incluyendo las mediciones, documentacin de procesos y los datos recaudados a partir de su uso y lecciones aprendidas. 9. Basar el modelo de procesos en ISO9000:2000 y nivel 2 y 3 de CMM V.1.1. Usar como marco general ISO/IEC 15504 - Software Process Assesment [3] e incorporar las mejores prcticas de otros modelos de referencia tales como PMBOK [4], SWEBOK [9] y otros ms especializados.

Otras formas de trabajo

Mtodo

japons: Pirmide. Arriba : directivos Objetivos claros y precisos, visin y misin claras. Conseguir compromiso con empleados (accionistas) Trabajan de por vida en una empresa.

Cap. 2 Componentes claves

Componentes clave.. En subsistemas

Componentes clave MS

El modelo que se propone est enfocado en procesos y considera los tres niveles bsicos de la estructura de una organizacin que son: la Alta Direccin, Gestin y Operacin. El modelo pretende apoyar a las organizaciones en la estandarizacin de sus prcticas, en la evaluacin de su efectividad y en la integracin de la mejora continua

Componente Clave: Planeacin2

Requerimos

varios planes: 1.Plan estratgico (inicial) 2. Plan de recursos 3. Plan de riesgos 4. Plan de comunicacin

PMBOOK

El plan de gestin del proyecto documenta el conjunto de salidas de los procesos de planificacin del Grupo de Procesos de Planificacin e incluye: Los procesos de direccin de proyectos seleccionados por el equipo de direccin del proyecto El nivel de implementacin de cada proceso seleccionado Las descripciones de las herramientas y tcnicas que se utilizarn para llevar a cabo esos procesos. Cmo se utilizarn los procesos seleccionados para dirigir el proyecto especfico, incluidas las dependencias y las interacciones entre esos procesos, y las entradas y salidas esenciales. Cmo se ejecutar el trabajo para alcanzar los objetivos del proyecto Cmo se supervisarn y controlarn los cambios Cmo se realizar la gestin de la configuracin Cmo se actualizar y usar la integridad de las lneas base para la medicin del rendimiento La necesidad y las tcnicas para la comunicacin entre los interesados El ciclo de vida del proyecto seleccionado y, para los proyectos de mltiples fases, las fases del proyecto relacionadas Las revisiones clave de direccin acerca del contenido, la extensin y la oportunidad para facilitar la gestin de polmicas sin resolver y decisiones pendientes

PMBOOK

planes subsidiarios y otros componentes. Cada uno de los planes subsidiarios y componentes se detallan en la medida en que lo exija el proyecto especfico. Estos planes subsidiarios pueden incluir, entre otros: Plan de gestin del alcance del proyecto (Seccin 5.1.3.1) Plan de gestin del cronograma (introduccin del Captulo 6) Plan de gestin de costes (introduccin del Captulo 7) Plan de gestin de calidad (Seccin 8.1.3.1). Plan de mejoras del proceso (Seccin 8.1.3.4) Plan de gestin de personal (Seccin 9.1.3.3). Plan de gestin de las comunicaciones (Seccin 10.1.3.1) Plan de gestin de riesgos (Seccin 11.1.3.1) Plan de gestin de las adquisiciones (Seccin 12.1.3.1). Estos otros componentes incluyen, entre otros: Lista de hitos (Seccin 6.1.3.3). Calendario de recursos (Seccin 6.3.3.4). Lnea base del cronograma (Seccin 6.5.3.3). Lnea base de coste (Seccin 7.2.3.1). Lnea base de calidad (Seccin 8.1.3.5). Registro de Riesgos (Seccin 11.2.3.1).

Pag. 106 de PMBOOK

Desarrollar plan PB