Temario 1. Introducción 1.1 Importancia de la administración de proyectos de software: Crisis del software.(TB),

1. Temario 1. Introducción 1.1 Importancia de la administración 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 administración 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 dinámico (TB). 2.1 Planeación(TB) 2.2 Como organizar por procesos: Dirección, Gerencias: calidad, administración(y operación) y procesos (MS) 2.3 Grupos de procesos de planificación (PMB) 2.4 Modelos actuales de para administración de proyectos(PMB) 2.5 Áreas de conocimiento(PMB) 2.6 Planes estratégicos, comunicación, riesgos, económicos, etc(MS) 3. Administración de los Recursos Humanos 3.1 Clasificación(TB) 3.2 Gestión de recursos humanos(PMB) 3.3 Roles (MS) 4. Producción y Desarrollo del Software 4.0 clasificación de producción y desarrollo y explicación(TB) 4.1 Ciclo vida del proyecto(TB) (PMB) 4.2 Procesos básicos necesarios a verificar(MS) 5. Aseguramiento de la Calidad Que es calidad y tipos de calidad, ISO y Certificaciones Practicas para evaluar (MS) Planificación aseguramiento y control (PMB) 6. Pruebas del Sistema Planes de pruebas y riesgos 7. Control y Planeación Como seguir el modelo 8. Un Caso de Estudio

2. Crisis del Software Historia Síntomas Factores de Influencia Posibles Causas

3. Historia El término “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 surgían en el desarrollo de sistemas de software. En la misma conferencia se utilizó por primera vez el término "ingeniería del software" para describir el conjunto de conocimientos que existían en aquel estado inicial.

4. Algunas referencias útiles para comprender cuáles eran los conocimientos estables para el desarrollo de software en 1968 son: • En 1962 se publicó el primer algoritmo para búsquedas binarias. • C.Böhm y G. Jacopini publicaron en 1966 el documento que creaba una fundación para la eliminación de "GoTo" y la creación de la programación estructurada. • En 1968 los programadores se debatían entre el uso de la sentencia GoTo, y la nueva idea de programación estructurada; ese era el caldo de cultivo en el que Edsger Dijkstra escribió su famosa carta "GoTo Statement Considered Harmful" en 1968.

5. La primera publicación sobre programación estructurada no vio la luz hasta 1974, publicada por Larry Constantine, Glenford Myers y Wayne Stevens. • El primer libro sobre métrica de software fue publicado en 1977 por Tom Gilb. • El primer libro sobre análisis de requisitos apareció en 1979. • El término fue usado para referirse a los rápidos incrementos de la tecnología en la computación 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 programación. Las raíces de la crisis del software son complejas y variables.

6. SINTOMAS • Uno de los principales problemas en el desarrollo de software de hoy, es que muchos proyectos empiezan la programación tan pronto se definen y concentran mucho de su esfuerzo en la escritura de código. • Últimamente el desarrollo de software se a ralentizado. El estudio de este fenómeno es importante porque la existencia de software científico libre facilita que cualquier laboratorio del mundo pueda desarrollar ciencia libre usando este software como herramienta de trabajo.

7. Algunos “síntomas” 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.

8. FACTORES DE INFLUENCIA • Para poder llevar el estado del proceso de software como un estado de crisis, los críticos han destacado ciertas características que han permitido esta postura del software respecto a otras etapas de su corta historia. Algunos de esos factores son: • Aumento del poder computacional. • Reducción del costo del hardware. • Rápida obsolescencia de hardware y software.

9. Aceptación de la computarización en las empresas. • Incremento en el número de usuarios de los sistemas de software. • Tipo de usuario no homogéneo aun en sistemas hechos a la medida. • Personal desarrollado y mantenimiento diferente. • La magnitud del proyecto impacta en: • Tiempo costo y número de desarrolladores

10. Control administrativo y detalles técnicos • Aumento en el conocimiento del problema. • Cambios en el entorno: • Tecnológicos (Internet, redes, ERP, CRM, SCM). • Económicos (crisis económicas, globalización, etcétera). • Sociales (nuevas necesidades, costumbres nuevas, etcétera).

11. 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 común que son causadas por el método de valorar los avances científicos y el mecanismo actual de financiación de la actividad científica. 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 ingeniería de software como una profesión. La crisis se manifestó a sí misma en varias maneras:

12. Proyectos gestionados con un sobre-presupuesto. • Proyectos gestionados con sobre tiempo. • Software de baja calidad. • El software a menudo no satisfacía los requerimientos deseados. • Los proyectos fueron inmanejables, con un código difícil de mantener. • La crisis del software fue dirigida por la implementación de varios procesos y metodologías.

13. 1.2 Reto Admi..MOPROSOFT1 El propósito de este documento es presentar un Modelo de Procesos para la Industria de Software (MoProSoft) en México que fomente la estandarización de su operación a través de la incorporación de las mejores prácticas en gestión e ingeniería de software.

14. MOPROSOFT2 La adopción del modelo permitirá elevar la capacidad de las organizaciones para ofrecer servicios con calidad y alcanzar niveles internacionales de competitividad

15. PMBOOK1 Los Fundamentos de la Dirección de Proyectos constituyen la suma de conocimientos en la profesión de dirección de proyectos. Al igual que en otras profesiones, como la abogacía, la medicina o las ciencias económicas, los conocimientos residen en los practicantes y académicos que los aplican y los

16. PMBOOK2 desarrollan. Los Fundamentos de la Dirección de Proyectos completos incluyen prácticas tradicionales comprobadas y ampliamente utilizadas, así como prácticas innovadoras que están emergiendo en la profesión, incluyendo material publicado y no publicado.

17. PMBOOK3 Como consecuencia, los Fundamentos de la Dirección de Proyectos están en constante evolución.

18. 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 serán o no podrán ser alcanzados, o cuando la necesidad del proyecto ya no exista y el proyecto sea cancelado.

19. Proy2 Temporal no necesariamente significa de corta duración; muchos proyectos duran varios años. En cada caso, sin embargo, la duración de un proyecto es limitada. Los proyectos no son esfuerzos continuos. La mayoría 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 también pueden tener impactos sociales, económicos y ambientales, intencionales o no, que perduran mucho más que los propios proyectos.

20. Producto del proyecto resultados. Los proyectos pueden crear: • Un producto o artículo 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 producción o la distribución • Un resultado como, por ejemplo, salidas o documentos. Por ejemplo, de un proyecto de investigación se obtienen conocimientos que pueden usarse para determinar si existe o no una tendencia o si un nuevo proceso beneficiará a la sociedad.

21. Producto… La singularidad es una característica 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 diseño, diferente ubicación, diferente contratista, etc. La presencia de elementos repetitivos no cambia la condición fundamental de único del trabajo de un proyecto.

22. Elaboración Gradual La elaboración gradual es una característica de los proyectos que acompaña a los conceptos de temporal y único. “Elaboración 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 más explícito y detallado a medida que el equipo del proyecto desarrolla un mejor y más completo entendimiento de los objetivos y de los productos entregables.

23. La elaboración gradual de las especificaciones de un proyecto debe ser coordinada cuidadosamente con la definición 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 relación entre el alcance del producto y el alcance del proyecto se trata más adelante, en la introducción del Capítulo 5.

24. Los siguientes ejemplos ilustran la elaboración gradual en dos áreas de aplicación diferentes. • El desarrollo de una planta de procesamiento químico comienza con la ingeniería de proceso que define las características del proceso. Estas características se utilizan para diseñar las unidades de procesamiento principales. Esta información se convierte en la base para el diseño de ingeniería, que define tanto el plano detallado de la planta como las características mecánicas de las unidades de proceso y las instalaciones auxiliares. Todo ello resulta en dibujos de diseño que se elaboran para crear dibujos de fabricación y construcción. Durante la construcción, se realizan las interpretaciones y

25. adaptaciones que sean necesarias, que están sujetas a la aprobación correspondiente. Esta elaboración 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 rotación. • El producto de un proyecto de desarrollo económico puede definirse inicialmente como: “Mejorar la calidad de vida de los residentes con ingresos más bajos de la comunidad X”. A medida que el proyecto avanza, los productos

26. pueden describirse más específicamente como, por ejemplo: “Proporcionar acceso a agua y comida a 500 residentes de bajos ingresos de la comunidad X”. La siguiente etapa de elaboración gradual podría centrarse exclusivamente en mejorar la producción y comercialización agrícola, considerando la provisión de agua como una segunda prioridad, a ser iniciada una vez que el componente agrícola esté en una etapa avanzada. Forma de resolución: Divide y vencerás; De un problema grande obtén varios problemas chicos.

27. Proceso MS Conjunto de prácticas relacionadas entre si, llevadas a cabo a través de roles y por elementos automatizados, que utilizando recursos y a partir de insumos producen un satisfactor de negocio para el cliente.

28. Modelo de Procesos MS Criterios: 1. Generar una estructura de los procesos que esté acorde con la estructura de las organizaciones de la industria de software (Alta Dirección, Gestión y Operación). 2. Destacar el papel de la Alta Dirección en la planificación estratégica, su revisión y mejora continua como el promotor del buen funcionamiento de la organización. 3. Considerar a la Gestión como proveedor de recursos, procesos y proyectos, así como responsable de vigilar el cumplimiento de los objetivos estratégicos de la organización.

29. 4. Considerar a la Operación como ejecutor de los proyectos de desarrollo y mantenimiento de software. 5. Integrar de manera clara y consistente los elementos indispensables para la definición de procesos y relaciones entre ellos. 6. Integrar los elementos para la administración de proyectos en un solo proceso. 7. Integrar los elementos para la ingeniería de productos de software en un solo marco que incluya los procesos de soporte (verificación, validación, documentación y control de configuración).

30. 8. Destacar la importancia de la gestión de recursos, en particular los que componen la base de conocimiento de la organización tales como: productos generados por proyectos, datos de los proyectos, incluyendo las mediciones, documentación 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 prácticas de otros modelos de referencia tales como PMBOK [4], SWEBOK [9] y otros más especializados.

31. Otras formas de trabajo Método japonés: Pirámide. Arriba : directivos Objetivos claros y precisos, visión y misión claras. Conseguir compromiso con empleados (accionistas) Trabajan de por vida en una empresa.

32. Cap. 2 Componentes claves

33. Componentes clave.. En subsistemas

34. Componentes clave MS El modelo que se propone está enfocado en procesos y considera los tres niveles básicos de la estructura de una organización que son: la Alta Dirección, Gestión y Operación. El modelo pretende apoyar a las organizaciones en la estandarización de sus prácticas, en la evaluación de su efectividad y en la integración de la mejora continua

35. Componente Clave: Planeación2 Requerimos varios planes: 1.Plan estratégico (inicial) 2. Plan de recursos 3. Plan de riesgos 4. Plan de comunicación…

36. PMBOOK El plan de gestión del proyecto documenta el conjunto de salidas de los procesos de planificación del Grupo de Procesos de Planificación e incluye: • Los procesos de dirección de proyectos seleccionados por el equipo de dirección del proyecto • El nivel de implementación de cada proceso seleccionado • Las descripciones de las herramientas y técnicas que se utilizarán para llevar a cabo esos procesos. • Cómo se utilizarán los procesos seleccionados para dirigir el proyecto específico, incluidas las dependencias y las interacciones entre esos procesos, y las entradas y salidas esenciales. • Cómo se ejecutará el trabajo para alcanzar los objetivos del proyecto • Cómo se supervisarán y controlarán los cambios • Cómo se realizará la gestión de la configuración • Cómo se actualizará y usará la integridad de las líneas base para la medición del rendimiento • La necesidad y las técnicas para la comunicación entre los interesados • El ciclo de vida del proyecto seleccionado y, para los proyectos de múltiples fases, las fases del proyecto relacionadas • Las revisiones clave de dirección acerca del contenido, la extensión y la oportunidad para facilitar la gestión de polémicas sin resolver y decisiones pendientes

37. 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 específico. Estos planes subsidiarios pueden incluir, entre otros: • Plan de gestión del alcance del proyecto (Sección 5.1.3.1) • Plan de gestión del cronograma (introducción del Capítulo 6) • Plan de gestión de costes (introducción del Capítulo 7) • Plan de gestión de calidad (Sección 8.1.3.1). • Plan de mejoras del proceso (Sección 8.1.3.4) • Plan de gestión de personal (Sección 9.1.3.3). • Plan de gestión de las comunicaciones (Sección 10.1.3.1) • Plan de gestión de riesgos (Sección 11.1.3.1) • Plan de gestión de las adquisiciones (Sección 12.1.3.1). Estos otros componentes incluyen, entre otros: • Lista de hitos (Sección 6.1.3.3). • Calendario de recursos (Sección 6.3.3.4). • Línea base del cronograma (Sección 6.5.3.3). • Línea base de coste (Sección 7.2.3.1). • Línea base de calidad (Sección 8.1.3.5). • Registro de Riesgos (Sección 11.2.3.1). Pag. 106 de PMBOOK

38. Desarrollar plan PB