Temario

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

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.
FACTORES DE INFLUENCIA
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 sobre-
presupuesto.
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
incrementos
1
. 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.
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
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.

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