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
Crisis del Software
Historia
Síntomas
Factores
de Influencia
Posibles Causas
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.
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.




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.


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.
 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.
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.
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

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).

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:
Proyectos gestionados con un sobrepresupuesto.
 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.
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.
MOPROSOFT2
 La
adopción 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 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
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.
PMBOOK3
 Como
consecuencia, los
Fundamentos de la Dirección de
Proyectos están en constante
evolución.
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.
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.
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.
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.
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.

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.
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


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


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.
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.
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.





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).




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.
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.
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 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
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…
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
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
















Desarrollar plan PB
Descargar

Crisis del Software