Temario

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 ISO90002000 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

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).

38
Desarrollar plan PB