ING.

DE SOFTWARE

Ing. Jorge Reyes

Software
Software

Gestin de Proyectos.

Software

Qu es la Gestin de Proyectos?
La gestin de proyectos es la disciplina del
planeamiento, la organizacin, la motivacin, y el
control de los recursos con el propsito de alcanzar
uno o varios objetivos.
Un proyecto es un emprendimiento temporario
diseado a producir un nico producto, servicio o
resultado con un principio y un final definido
(normalmente limitados en tiempo, y en costos o
entregables), que es emprendido para alcanzar
objetivos nicos, y que dar lugar a un cambio
positivo o agregar valor.
Software

 La gestin de proyectos de software es una parte

esencial de la ingeniera del software. La buena gestin
no puede garantizar el xito del proyecto. Sin embargo,
la mala gestin usualmente lleva al fracaso del
proyecto. El software es entregado tarde, los costes son
mayores que lo estimados y los requerimientos no se
cumplen.
Los gestores de software son responsables de la
planificacin y temporalizacin del desarrollo de los
proyectos. Supervisan el trabajo para asegurar que se
lleva a cabo conforme a los estndares requeridos y
supervisan el progreso para comprobar que el
desarrollo se ajusta al tiempo previsto y al presupuesto.
Software

 La administracin de proyectos de software es necesaria

debido a que la ingeniera de software profesional
siempre est sujeta a restricciones organizacionales de
tiempo y presupuesto.
El trabajo del gestor de proyectos de software es
asegurar que stos cumplan dichas restricciones y
entregar software que contribuya a las metas de la
compaa de desarrollo software.
Los gestores de software hacen el mismo tipo de trabajo
que otros gestores. Sin embargo, la ingeniera del
software es diferente en varios aspectos a otros tipos, lo
que hace a la gestin de software particularmente difcil.
Software

 La naturaleza temporal de los proyectos se contrapone con las

operaciones normales de cualquier organizacin, las cuales son
actividades
funcionales
repetitivas,
permanentes
o
semipermanentes que hacen a los productos o al servicio.
En la prctica, la gestin de estos dos sistemas suelen ser muy
distintos, y requieren el desarrollo de habilidades tcnicas y
gestin de estrategias diferentes.
El primer desafo para la gestin de proyectos es alcanzar la
meta del proyecto, y los objetivos dentro de las limitantes
conocidas. Las limitantes o restricciones primarias son el alcance,
el tiempo, la calidad y el presupuesto.
El desafo secundario, y el ms ambicioso de todos, es optimizar
la asignacin de recursos de las entradas necesarias e integrarlas
para alcanzar los objetivos predefinidos.
Software

 Algunas de estas diferencias son las siguientes:

El producto es intangible. El gestor de un proyecto de construccin de un embarca

dero o de uno de ingeniera civil puede ver el producto mientras se est
desarrollando. Si hay un desfase en calendario, el efecto en el producto es visible de
forma obvia: partes de la estructura no estn completas. El software es intangible. No
se puede ver ni tocar. Los gestores de proyectos de software no pueden ver el
progreso. Confan en otros para elaborar la documentacin necesaria para revisar el
progreso.

No existen procesos del software estndar. En las disciplinas de ingeniera con

larga historia, el proceso se prueba y verifica. Para tipos particulares de sistemas,
como puentes o edificios, el proceso de ingeniera se comprende bien. Sin embargo,
los procesos de software varan notablemente de una organizacin a otra. A pesar de
que la comprensin del proceso del software se ha desarrollado de forma significativa
en los ltimos aos, an no se puede predecir con certeza cundo un proceso
particular tiende a desarrollar problemas. Esto es especialmente cierto cuando el
proyecto software es parte un proyecto de ingeniera de un sistema grande.

A menudo los proyectos grandes son nicos. Por lo general, los proyectos
grandes de software son diferentes de proyectos previos. En consecuencia, los
gestores, aun cuando cuenten con una amplia experiencia, sta no es suficiente para
anticipar los problemas. Ms an, los rpidos cambios tecnolgicos en las
computadoras y las comunicaciones hacen parecer obsoleta la experiencia previa. Las
lecciones aprendidas en esas experiencias pueden no ser transferibles a los nuevos
proyectos.

Software

 Debido a estos problemas, no es sorprendente que

algunos
proyectos
de
software
se
retrasen,
sobrepasen el presupuesto y se entreguen fuera de
tiempo. A menudo, los sistemas de software son
nuevos y tecnolgicamente innovadores.
Frecuentemente
los
proyectos
de
ingeniera
innovadores (como los nuevos sistemas de transporte)
tambin tienen problemas de temporalizacin. Dadas
las mezclas de dificultades, es notable que muchos
proyectos de software sean entregados a tiempo y
segn lo presupuestado.

Software

Actividades de gestin.
Es imposible redactar una descripcin estndar del trabajo
de un gestor de software.
El trabajo difiere enormemente dependiendo de la
organizacin y del producto de software a desarrollar. Sin
embargo, en algn momento, muchos gestores son
responsables de algunas o de la totalidad de las siguientes
actividades:

Software

Redaccin de la propuesta.
Planificacin y calendarizacin del proyecto.
Estimacin de costes del proyecto.
Supervisin y revisin del proyecto.
Seleccin y evaluacin del personal.
Redaccin y presentacin de informes.

 La primera etapa de un proyecto de software implica

redactar una propuesta para realizar ese proyecto. La
propuesta describe los objetivos del proyecto y cmo se
llevara a cabo. Por lo general, incluye estimaciones de
coste y tiempo y justifica por qu el contrato del proyecto
se le debe dar a una organizacin o a un equipo en
particular.
La redaccin de la propuesta es una tarea crtica, ya que
la existencia de muchas organizaciones de software
depende de las propuestas aceptadas y los contratos
asignados. No existen guas para esta tarea; la redaccin
de propuestas es una habilidad que se adquiere con la
prctica y la experiencia.
Software

 La planificacin de proyectos se refiere a la identificacin de

actividades, hitos y entregas un proyecto. Por lo tanto, se debe
bosquejar un plan para guiar el desarrollo hacia las metas del proyecto.
El objetivo de la planificacin del proyecto de software es proporcionar
un marco de trabajo que permite al gestor de planificacin hacer
estimaciones razonables de recursos, costos y planificacin temporal.
Estas estimaciones se hacen dentro de un marco de tiempo limitado al
comienzo de un proyecto de software, y deberan actualizarse
regularmente
a
medida
que
progresa
el
proyecto.

Las estimaciones deberan definir los escenario del mejor caso, y peor
caso de modo que los resultados del proyecto pueden limitarse. El
objetivo de la planificacin se logra mediante un proceso de
descubrimiento de la informacin que lleve a estimaciones razonables.

Software

 La estimacin del coste es una actividad relacionada con la estimacin

de los recursos requeridos para llevar a cabo el plan del proyecto.
En el principio el costo del software constitua un pequeo porcentaje del
costo total de los sistemas basados en computadoras. Hoy en da el
software es el elemento mas caro de la mayora de los sistemas
informticos. Es una pequea planeacin sobre que es lo que va a ser mi
proyecto. Una de las actividades cruciales del proceso de gestin del
proyecto del software es la planificacin.
Cuando se planifica un proyecto de software ese tiene que obtener
estimaciones de esfuerzo humano requerido, de la duracin cronolgica
del proyecto y del costo. Pero en muchos de los casos las estimaciones
se hacen valindose de la experiencia pasada como nica gua. Si un
proyecto es bastante similar en tamao y funciona un proyecto pasado
es probable que el nuevo requiera aproximadamente la misma cantidad
de esfuerzo, que dure aproximadamente lo mismo que el trabajo anterior.
Si el proyecto es distinto entonces puede que las experiencias obtenidas
no sean suficientes.
Software

 La supervisin de proyecto es una actividad continua. El

gestor debe tener conocimiento del progreso del proyecto y
comparar el progreso con los costes actuales y los
planificados.
Aunque
muchas
organizaciones
tienen
mecanismos formales para supervisar, un gestor hbil podra
formarse una imagen clara de lo que pasa llevando a cabo
una entrevista informal con el personal del proyecto.
La supervisin informal predice problemas importantes del
proyecto, y revela dificultades que pueden aparecer. Por
ejemplo, las entrevistas diarias con el personal del proyecto
pueden exteriorizar un problema en un fallo del software.
Ms que esperar un informe de atraso del proyecto, el gestor
de software podra asignar algn experto para resolver el
problema o podra decidir si se vuelve a programar.

Software

 Durante un proyecto, es normal tener varias revisiones formales de

su gestin. Se hace la revisin completa del progreso y de los
desarrollos tcnicos del proyecto, y se tiene en cuenta el estado
del proyecto junto con los propsitos de la organizacin que ha
encargado el software.
El resultado de una revisin puede dar lugar a la cancelacin del
proyecto. El tiempo de desarrollo para un proyecto grande de
software puede ser de varios aos. Durante ese tiempo los
objetivos organizacionales tienden obviamente a cambiar.
Estos cambios pueden significar que el software ya no se necesita
o que los requerimientos originales del proyecto son inapropiados.
La gestin puede decidir parar el desarrollo del software o cambiar
el proyecto para adecuarlo a los cambios de los objetivos de la
organizacin.
Software

 Por lo general, los gestores de proyectos tienen que seleccionar a

las personas para trabajar en su proyecto. De forma ideal, habr
personal disponible con habilidades y experiencia apropiada para
trabajar en el proyecto. Sin embargo, en muchos casos, los gestores
tienen que establecer un equipo ideal mnimo para el proyecto.
Las razones que explican esto son:

El presupuesto del proyecto no cubre la contratacin de personal con

sueldos altos. Se tiene que contratar personal con menos experiencia y
menor sueldo.

El personal con experiencia apropiada no est disponible dentro o fuera

de la organizacin. Es imposible reclutar nuevo personal para el proyecto.
Dentro de la organizacin, los mejores trabajadores ya se han asignado a
otros proyectos.

La organizacin desea desarrollar las habilidades de sus empleados. El

personal inexperto puede ser asignado al proyecto para aprender y
adquirir experiencia.

Software

 El gestor de software tiene que trabajar con estas restricciones

al seleccionar al personal del proyecto. Sin embargo, todos
estos problemas son probables a menos que exista un miembro
del proyecto que cuente con algo de experiencia en el tipo de
sistema a desarrollar. Sin esta experiencia, probablemente se
cometern muchos errores pequeos.
Los gestores del proyecto son responsables de informar a los
clientes y contratistas sobre el proyecto. Tienen que redactar
documentos concisos y coherentes que resuman la informacin
crtica de los informes detallados del proyecto. Les debe ser
posible presentar esta informacin durante las revisiones de
progreso. En consecuencia, comunicarse efectivamente de
forma oral y escrita es una habilidad esencial que un gestor de
proyectos debe tener.

Software

Planificacin del proyecto.

La gestin efectiva de un proyecto de software depende
de planificar completamente el progreso del proyecto.
El gestor del proyecto debe anticiparse a los problemas
que puedan surgir, as como preparar soluciones a esos
problemas. Un plan, preparado al inicio de un proyecto,
debe utilizarse como un conductor para el proyecto.
Este plan inicial debe ser el mejor posible de acuerdo
con la informacin disponible. ste evolucionar
conforme el proyecto progrese y la informacin sea
mejor.
Software

El plan del proyecto.

El plan del proyecto fija los recursos disponibles,
divide el trabajo y crea un calendario de trabajo.
En algunas organizaciones, el plan del proyecto es un
nico documento que incluye todos los diferentes
tipos de planes. En otros casos, este plan slo se
refiere al proceso de desarrollo. Otros pueden estar
referenciados, pero son proporcionados por separado.

Software

Tipos de Plan.
Plan de calidad.

Describe los procedimientos y los

estndares de calidad que se
utilizaran en un proyecto.

Plan de validacin.

Describe el enfoque, los recursos y

la programacin utilizados para la
validacin del sistema.

Plan de gestin de
configuraciones.

Describe los procedimientos para

la gestin de configuraciones y las
estructuras a utilizar.

Plan de mantenimiento.

Predice los requerimientos del

mantenimiento del sistema, los
costes del mantenimiento y el
esfuerzo requerido.

Plan de desarrollo del personal.

Describe como se desarrollan las

habilidades y experiencia de los
miembros del equipo del proyecto.

Software

Sin embargo, muchos planes incluyen las siguientes secciones:

Introduccin. Describe brevemente los objetivos del proyecto y expone las restriccio
nes (por ejemplo, presupuesto, tiempo, etctera) que afectan a la gestin del proyecto.
Organizacin del proyecto. Describe la forma en que el equipo de desarrollo est
organizado, la gente involucrada y sus roles en el equipo.
Anlisis de riesgo. Describe los posibles riesgos del proyecto, la probabilidad de que
surjan estos riesgos y las estrategias de reduccin de riesgos propuestas.
Requerimientos de recursos de hardware y software. Describe el hardware y el
software de ayuda requeridos para llevar a cabo el desarrollo. Si es necesario comprar
hardware, se deben incluir las estimaciones de los precios y las fechas de entrega.
Divisin del trabajo. Describe la divisin del proyecto en actividades e identifica los
hitos y productos a entregar asociados con cada actividad.
Programa del proyecto. Describe las dependencias entre actividades, el tiempo esti
mado requerido para alcanzar cada hito y la asignacin de la gente a las actividades.
Mecanismos de supervisin e informe. Describe la gestin de informes y cundo
deben producirse, as como los mecanismos de supervisin del proyecto a utilizar.
Software

 El plan del proyecto debe revisarse regularmente

durante el proyecto. Algunas partes, como el
calendario
del
proyecto,
cambiarn
frecuentemente; otras sern ms estables.
Para simplificarlas revisiones, se debe organizar el
documento en secciones separadas que permitan
su reemplazo de forma individual conforme
evoluciona el plan.

Software

Hitos y entregas.
Los gestores necesitan informacin para hacer su trabajo. Como el
software es intangible, esta informacin slo se puede proveer como
documentos que describan el estado del software que se est
desarrollando. Sin esta informacin, es imposible juzgar el progreso y no
se pueden actualizar los costes y calendarios.
Cuando se planifica un proyecto, se debe establecer una serie de hitos
puntos finales de una actividad del proceso del software. En cada
uno, debe existir una salida formal, como un informe, que se debe
presentar al gestor. Los informes de hitos no deben ser documentos
amplios. Deben ser informes cortos de los logros en una actividad del
proyecto.
Los hitos deben representar el fin de una etapa lgica en el proyecto.
Los hitos indefinidos como (80 % del cdigo completo) son imposibles
de validar y carecen de utilidad para la gestin del proyecto. No
podemos validar si se ha llegado a esta etapa debido a que la cantidad
de cdigo que se tiene que desarrollar no es precisa.
Software

 Una entrega es el resultado del proyecto que se entrega

al cliente. De forma general, se entrega al final de una
fase principal del proyecto como la especificacin, el
diseo, etc. Como regla general, las entregas son hitos,
pero stos no son necesariamente entregas. Dichos
hitos pueden ser resultados internos del proyecto que
son utilizados por el gestor del proyecto para verificar el
progreso del mismo pero que no se entregan al cliente.
Para establecer los hitos, el proceso del software debe
dividirse en actividades bsicas con sus salidas
asociadas.

Software

 Por ejemplo, la Figura muestra las actividades involucradas en la

especificacin de requerimientos cuando se utiliza la construccin
de prototipos para ayudar a validar dichos requerimientos.
Tambin se muestran las salidas principales de cada actividad (los
hitos del proyecto). Las entregas del proyecto, las cuales son
entregadas al cliente, son la definicin y especificacin de
requerimientos.

Software

Calendarizacin del
proyecto.
sta es una de las tareas ms difciles para los gestores de proyectos. Los
gestores estiman el tiempo y los recursos requeridos para completar las
actividades y organizarlas en una sucesin coherente. A menos que el proyecto
a calendarizar sea similar a otro anterior, las estimaciones previas son una
base incierta para la calendarizacin del nuevo proyecto.
La estimacin del calendario se complica ms por el hecho de que proyectos
diferentes pueden utilizar mtodos de diseo y lenguajes de implementacin
diferentes.
Si el proyecto es tcnicamente complejo, las estimaciones iniciales casi
siempre son optimistas aun cuando los gestores traten de considerar las
eventualidades. A este respecto, la calendarizacin del tiempo para la creacin
del software no es diferente a la de cualquier otro tipo de proyecto grande y
complejo. Los nuevos aeroplanos, los puentes e incluso los nuevos modelos de
automviles se retrasan debido a problemas no anticipados. Por lo tanto, los ca
lendarios se deben actualizar continuamente en la medida que se disponga de
mejor informacin acerca del progreso.
Software

 La calendarizacin del proyecto (la Figura) implica separar todo el

trabajo de un proyecto en actividades complementarias y
considerar el tiempo requerido para completar dichas actividades.
Por lo general, algunas de stas se llevan a cabo en paralelo.
Debemos coordinar estas actividades paralelas y organizar el
trabajo para que la mano de obra se utilice de forma ptima.
Deben evitarse situaciones en que el proyecto entero se retrase
debido a que no se ha terminado una actividad crtica.

Software

 Normalmente, las actividades del proyecto deben durar por lo

menos una semana. Hacer subdivisiones ms finas significa
invertir una cantidad desproporcionada de tiempo en la estima
cin y revisin de tablas. Tambin es til asignar una cantidad
de tiempo mxima de 8 a 10 semanas para realizar cualquier
actividad. Si lleva ms tiempo, se deben hacer subdivisiones.
AI estimar la calendarizacin, los gestores no deben suponer
que cada etapa del proyecto estar libre de problemas. Las
personas que trabajan en l pueden enfermarse o renunciar, el
hardware puede fallar y el software o hardware de soporte
puede llegar tarde. Si el proyecto es nuevo y tcnicamente
complejo, ciertas partes podran ser ms complicadas y
llevaran ms tiempo del que se estim originalmente.

Software

 Como en los calendarios, los gestores deben estimar los recursos necesarios
para completar cada tarea. El recurso principal es el esfuerzo humano que se
requiere. Otros recursos pueden ser el espacio en disco requerido en un
servidor, el tiempo requerido de hardware especializado, un simulador o el
presupuesto para viajes del personal del proyecto.
Una buena regla prctica es estimar como si nada fuera a salir mal, y entonces
incrementar la estimacin para abarcar los problemas previstos. Con este
mismo fin, a la estimacin se le debe agregar un factor de contingencia
adicional. Este factor extra de contingencia depende del tipo de proyecto, de
los parmetros del proceso (fecha de entrega, estndares, etc.) y de la calidad
y experiencia de los ingenieros de software que trabajen en el proyecto. Como
regla, para los problemas previstos siempre debe agregarse un 30% a la
estimacin original y otro 20% para cubrir algunas cosas no previstas.
Por lo general, el calendario del proyecto se representa como un conjunto de
grficos que muestran la divisin del trabajo, las dependencias de las
actividades y la asignacin del personal. Por lo general, las herramientas de
gestin de software, como Microsoft Project, se utilizan para automatizar la
produccin de diagramas.
Software

Gestin de riesgos.
Una tarea importante del gestor de proyectos es
anticipar los riesgos que podran afectar a la
programacin del proyecto o a la calidad del software
a desarrollar y emprender acciones para evitar esos
riesgos.
Los resultados de este anlisis de riesgos se deben
documentar a lo largo del plan del proyecto junto con
el anlisis de consecuencias cuando el riesgo ocurra.
Identificar stos y crear planes para minimizar sus
efectos en el proyecto se llama gestin de riesgos.
Software

 De forma simple, se puede concebir un riesgo como una probabilidad de

que una circunstancia adversa ocurra. Los riesgos son una amenaza
para el proyecto, para el software que se est desarrollando y para la
organizacin.
Estas categoras de riesgos se definen como se muestra a continuacin:

Riesgos del proyecto. stos afectan la calendarizacin o los recursos del

proyecto. Un ejemplo podra ser la prdida de un diseador experimentado.

Riesgos del producto. stos afectan a la calidad o al rendimiento del

software que se est desarrollando. Un ejemplo podra ser que el
rendimiento en un componente que hemos comprado sea menor que el
esperado.

Riesgos del negocio. Estos afectan a la organizacin que desarrolla o

suministra el software. Por ejemplo, que un competidor introduzca un nuevo
producto es un riesgo de negocio.

Software

 Por supuesto, estos tipos no son exclusivos entre s. Si

un programador experto abandona el proyecto, esto es
un riesgo para el proyecto (debido a que la entrega del
sistema se puede retrasar), para el producto (debido a
que un sustituto puede no ser tan experto y cometer
muchos errores) y para el negocio (debido a que esa
experiencia puede no contribuir a negocios futuros).
Los riesgos que pueden afectar a un proyecto
dependen del propio proyecto y del entorno
organizacin al donde se desarrolla. Sin embargo,
muchos riesgos son universales.

Software

 Algunos riesgos son:

Software

 La gestin de riesgos es importante particularmente para los

proyectos de software debido a las incertidumbres inherentes con
las que se enfrentan muchos proyectos.
Estas incertidumbres son el resultado de los requerimientos
ambiguamente definidos, las dificultades en la estimacin de
tiempos y los recursos para el desarrollo del software, la
dependencia en las habilidades individuales, y los cambios en los
requerimientos debidos a los cambios en las necesidades del
cliente.
Es preciso anticiparse a los riesgos: comprender el impacto de stos
en el proyecto, en el producto y en el negocio, y considerar los
pasos para evitarlos.
En el caso de que ocurran, se deben crear planes de contingencia
para que sea posible aplicar acciones de recuperacin.
Software

 El proceso de gestin de riesgos. ste comprende varias

etapas:

Identificacin de riesgos. Identificar los posibles riesgos para el proyecto, el

producto y los negocios.

Anlisis de riesgos. Valorar las probabilidades y consecuencias de estos riesgos.

Planificacin de riesgos. Crear planes para abordar los riesgos, ya sea para
evitarlos o minimizar sus efectos en el proyecto.

Supervisin de riesgos. Valorar los riesgos de forma constante y revisar los

planes para la mitigacin de riesgos tan pronto como la informacin de los
riesgos est disponible.

Software

 El proceso de gestin de riesgos, como otros de planificacin de

proyectos, es un proceso iterativo que se aplica a lo largo de todo el
proyecto.
Una vez que se genera un conjunto de planes iniciales, se supervisa la
situacin. En cuanto surja ms informacin acerca de los riesgos,
stos deben analizarse nuevamente y se deben establecer nuevas
prioridades. La prevencin de riesgos y los planes de contingencia se
deben modificar tan pronto como surja nueva informacin de los
riesgos.
Los resultados del proceso de gestin de riesgos se deben
documentar en un plan de gestin de riesgos. ste debe incluir un
estudio de los riesgos a los que se enfrenta el proyecto, un anlisis de
stos y los planes requeridos para su gestin. Si es necesario, puede
incluir algunos resultados de la gestin de riesgos; por ejemplo,
planes especficos de contingencia que se activan si aparecen dichos
riesgos.
Software

Identificacin de riesgos.
sta es la primera etapa de la gestin de riesgos.
Comprende el descubrimiento de los posibles riesgos
del proyecto. En principio, no hay que valorarlos o
darles prioridad en esta etapa aunque, en la
prctica, por lo general no se consideran los riesgos
con consecuencias menores o con baja probabilidad.
Esta identificacin se puede llevar a cabo a travs de
un proceso de grupo utilizando un enfoque de
tormenta de ideas o simplemente puede basarse en
la experiencia. Para ayudar al proceso, se utiliza una
lista de posibles tipos de riesgos.
Software

Hay al menos seis tipos de riesgos que pueden aparecer:

1. Riesgos de tecnologa. Se derivan de las tecnologas de software o de
hardware utilizadas en el sistema que se est desarrollando.
2. Riesgos de personal. Riesgos asociados con las personas del equipo
de desarrollo.
3. Riesgos organizacionales. Se derivan del entorno organizacional
donde el software se est desarrollando.
4. Riesgos de herramientas. Se derivan de herramientas CASE y de otro
software de apoyo utilizado para desarrollar el sistema.
5. Riesgos de requerimientos. Se derivan de los cambios de los
requerimientos del cliente y el proceso de gestionar dicho cambio.
6. Riesgos de estimacin. Se derivan de los estimados administrativos
de las caractersticas del sistema y los recursos requeridos para
construir dicho sistema.
Software

 La Figura proporciona algunos ejemplos de riesgos posibles en cada una de

estas categoras. El resultado de este proceso debe ser una larga lista de
riesgos que podran presentarse y afectar al producto, al proceso o al
negocio.

Software

Anlisis de riesgos.
Durante este proceso, se considera por separado cada
riesgo identificado y se decide acerca de la probabilidad y la
seriedad del mismo.
No existe una forma fcil de hacer esto recae en la
opinin y experiencia del gestor del proyecto. No se hace
una valoracin con nmeros precisos sino en intervalos:
La probabilidad del riesgo se puede valorar como muy bajo (<
10%), bajo (10-25%), moderado (25-50%), alto (50-75%) o muy
alto (>75%).
Los efectos del riesgo pueden ser valorados como catastrfico,
serio, tolerable o insignificante.
Software

 El resultado de este proceso de anlisis se debe colocar en una

tabla, la cual debe estar ordenada segn la seriedad del riesgo.
La Figura (anlisis de riesgo) ilustra esto para los riesgos
identificados en la Figura (riesgos y tipos de riesgos).
Obviamente, aqu es arbitraria la valoracin de la probabilidad y
seriedad.
En la prctica, para hacer esta valoracin se necesita
informacin detallada del proyecto, el proceso, el equipo de
desarrollo y la organizacin.
Por supuesto, tanto la probabilidad como la valoracin de los
efectos de un riesgo cambian conforme se disponga de mayor
informacin acerca del riesgo y los planes de gestin del mismo
se implementen. Por lo tanto, esta tabla se debe actualizar
durante cada iteracin del proceso de riesgos.
Software

 Figura analisis de riesgos:

Software

 Una vez que los riesgos se hayan analizado y clasificado, se debe

discernir cules son los ms importantes que se deben considerar
durante el proyecto. Este discernimiento debe depender de una
combinacin de la probabilidad de aparicin del riesgo y de los
efectos del mismo. En general, siempre se deben tener en cuenta
todos los riesgos catastrficos, as como todos los riesgos serios que
tienen ms que una moderada probabilidad de ocurrir.
Boehm (Boehm, 1988) recomienda identificar y supervisar los (10
riesgos ms altos), pero este nmero parece demasiado arbitrario.
El nmero exacto de riesgos a supervisar debe depender del
proyecto. Pueden ser cinco o 15. No obstante, el nmero apropiado
debe ser manejable.
Un nmero muy grande de riesgos requiere obtener mucha
informacin. De los riesgos identificados en la Figura (analisis de
riesgos), conviene considerar los ocho que tienen consecuencias
serias o catastrficas.
Software

Planificacin de riesgos.
El proceso de planificacin de riesgos considera cada uno de los riesgos clave
que han sido identificados, as como las estrategias para gestionarlos. Otra vez,
no existe un proceso sencillo que nos permita establecer los planes de gestin de
riesgos. Depende del juicio y de la experiencia del gestor del proyecto. La Figura
(estrategia de gestin de riesgos) muestra posibles estrategias para los ries
gos que han sido identificados en la Figura (anlisis de riesgos).
Estas estrategias seguidas pueden dividirse en tres categoras.
1. Estrategias de prevencin. Siguiendo estas estrategias, la probabilidad de que el ries
go aparezca se reduce. Un ejemplo de este tipo de estrategias es la estrategia de evita
cin de defectos en componentes de la Figura (estrategia de gestin de riesgos).
2. Estrategias de minimizacin. Siguiendo estas estrategias se reducir el impacto del
riesgo. Un ejemplo de esto es la estrategia frente a enfermedad del personal de la Figura
(estrategia de gestin de riesgos).
3. Planes de contingencia. Seguir estas estrategias es estar preparado para lo peor y te
ner una estrategia para cada caso. Un ejemplo de este tipo de estrategia es el mostrado
en la Figura (estrategia de gestin de riesgos) con la estrategia para problemas
financieros.
Software

 Puede verse aqu una analoga con las estrategias utilizadas en sistemas crticos
para asegurar fiabilidad, proteccin y seguridad. Bsicamente, es mejor usar
una estrategia para evitar el riesgo. Si esto no es posible, utilizar una para
reducir los efectos serios de los riesgos. Finalmente, tener estrategias para
reducir el impacto del riesgo en el proyecto y en el producto.
Software

Supervisin de riesgos.
La supervisin de riesgos normalmente valora cada uno de los riesgos
identificados para decidir si ste es ms o menos probable y si han cambiado sus
efectos. Por supuesto, esto no se puede observar de forma directa, por lo que se
tienen que buscar otros factores para dar indicios de la probabilidad del riesgo y
sus efectos. Obviamente, estos factores dependen de los tipos de riesgo.
La Figura (factores de riesgo) da algunos ejemplos de los factores que ayudan en
la valoracin de estos tipos de riesgos.

Software

 La supervisin de riesgos debe ser un

proceso continuo y, en cada revisin del
progreso de gestin, cada uno de los riesgos
clave debe ser considerado y analizado por
separado.

Software

Puntos clave.
Es esencial una buena gestin de proyectos de software para
que los proyectos de ingeniera de software se desarrollen a
tiempo y segn presupuesto.
La gestin de proyectos de software es diferente a la gestin de
otro tipo de ingenieras. El software es intangible. Los proyectos
pueden ser nuevos o innovadores, por lo que no existe un
conjunto de experiencias para guiar su gestin. El proceso del
software no se comprende del todo.
Los gestores de software tienen diversos papeles. Sus
actividades ms significativas son la planificacin, estimacin y
calendarizacin de los proyectos. La planificacin y la estimacin
son procesos iterativos. Tienen continuidad a lo largo del
proyecto. En cuanto se tenga ms informacin, se deben revisar
los planes y calendarios.
Software

 Un hito de un proyecto es el resultado predecible de una actividad

en el que se debe presentar un informe del progreso a la gestin.
Los hitos ocurren de forma frecuente en un proyecto de software.
Una entrega es un hito que se entrega al cliente del proyecto.
La calendarizacin de proyectos implica la creacin de varias
representaciones grficas de partes del plan del proyecto. stas
incluyen redes de actividades que muestran las interrelaciones de
las actividades del proyecto y grficos de barras que muestran la
duracin de dichas actividades.
Se deben identificar y valorar los riesgos mayores del proyecto
para establecer su probabilidad y consecuencias para ste. En
cuanto a los riesgos ms probables y potencialmente serios, se
deben hacer planes para anularlos, gestionarlos o tratarlos. Estos
riesgos se deben analizar de manera explcita en cada reunin del
progreso del proyecto.
Software

Espectro de Gestin.

Software

Espectro de Gestin.
La gestin eficaz de un proyecto de software
se centra en las cuatro Ps: personal,
producto, proceso y proyecto.
El orden no es arbitrario. El gestor que se
olvida de que el trabajo de ingeniera del
software es un esfuerzo humano intenso
nunca tendr xito en la gestin de
proyectos.
Software

 Un gestor que no fomenta una minuciosa

comunicacin con el cliente al principio de la
evolucin del proyecto se arriesga a construir una
elegante solucin para un problema equivocado.
El administrador que presta poca atencin al
proceso corre el riesgo de arrojar mtodos
tcnicos y herramientas eficaces al vaco. El
gestor que emprende un proyecto sin un plan
slido arriesga el xito del producto.

Software

 Personal.

La necesidad de contar con personal para el desarrollo del software

altamente preparado y motivado se viene discutiendo desde los aos 60 (por
ejemplo, [COUSO, WT94, DEM981). De hecho, el (factor humano) es tan
importante que el Instituto de Ingeniera del Software ha desarrollado un
Modelo de Madurez de la Capacidad de Gestin de Personal (MMCGP) (para
aumentar la preparacin de organizaciones del software para llevar a cabo
las cada vez ms complicadas aplicaciones ayudando a atraer, aumentar,
motivar, desplegar y retener el talento necesario para mejorar su capacidad
de
desarrollo
de
software).

El modelo de madurez de gestin de personal define las siguientes reas

clave prcticas para el personal que desarrolla software: reclutamiento,
seleccin, gestin de rendimiento, entrenamiento, retribucin, desarrollo de
la carrera, diseo de la organizacin y del trabajo y desarrollo cultural y de
espritu de equipo.

El MMCGP es compaero del modelo de madurez de la capacidad software,

que gua a las organizaciones en la creacin de un proceso de software
maduro.

Software

 LOS PARTICIPANTES.

El proceso de software lo integran participantes que pueden clasificarse

dentro de una de cinco categoras:
1.
Gestores ejecutivos: definen los aspectos del negocio que
usualmente tienen una influencia significativa en el proyecto.
2.

Gestores del proyecto : quienes planifican, motivan, organizan y

controlan a los profesionales que realizan el trabajo del software.

3.

Profesionales: quienes proporcionan las habilidades tcnicas

necesarias para realizar la ingeniera de un producto o aplicacin.

4.

Clientes: quienes especifican los requisitos para la ingeniera del

software y otros elementos que tienen un inters mnimo en el
resultado.

5.

Usuarios finales: quienes interactan con el software una vez que se

libera para su uso productivo.

Software

 LIDERES DE EQUIPO.
La gestin del proyecto es una actividad intensamente
humana, por lo tanto, los profesionales competentes
con frecuencia no son buenos lderes de equipo.
Simplemente no tienen la mezcla correcta de
habilidades con el personal.
Weinberg sugiere un modelo MOI de liderazgo, basado
en la Motivacin Organizacin e Innovacin.
Otra visin de las caractersticas que definen un
gestor de proyecto eficiente resalta 4 rasgos clave:
Resolucin de problemas, Dotes de gestin, Incentivos
e Influencia y fomento de la cultura de equipo.
Software

 EL EQUIPO DE SOFTWARE.

Existen casi tantas estructuras organizacionales de profesionales para el

desarrollo de software como organizaciones que tiene el mismo fin. La
estructura organizacional no puede ser fcilmente modificada.

Las preocupaciones acerca de las consecuencias prcticas y polticas de

cambio organizacional no estn dentro del mbito de responsabilidad del
gestor del proyecto de software. Sin embargo, la organizacin de la gente
directamente involucrada en un proyecto de software est dentro del
mbito del gestor del proyecto.

Los factores de proyecto que deberan considerarse cuando se planifica la

estructura de los equipos de ingeniera del software son:

Software

La dificultad del problema que se resolver.

El tamao del programa resultante en lneas de cdigo o puntos de funcin.
La vida del equipo.
El grado en el que el problema puede separarse en mdulos.
La calidad y confiabilidad requeridas del sistema que se construir.
La rigidez de la fecha de entrega.
El grado de sociabilidad que requiere el proyecto.

 Constantine, sugiere 4 paradigmas organizacionales

para los equipos de ingeniera de software:
Paradigma cerrado, estructura un equipo a lo largo de
una jerarqua tradicional de autoridad. Estos equipos
pueden trabajar mejor cuando producen software muy
similar a los proyectos anteriores, pero ser menos
probable que sean innovadores.
Paradigma aleatorio, estructura un equipo libremente
y depende de la iniciativa individual de los miembros
del equipo. Cuando se requieren innovacin o adelantos
tecnolgicos, los equipos que siguen el paradigma
aleatorio sern excelentes, pero no son recomendables
cuando se requiere desempeo ordenado.

Software

 Paradigma abierto, el trabajo se desarrolla en

colaboracin. La slida comunicacin y la toma de
decisiones basada en el consenso son las marcas
caractersticas de los equipos de paradigma abierto. Las
estructuras de equipo de paradigma abierto se adecuan
bien a la solucin de problemas complejos, pero no
pueden desempearse de manera tan eficiente como
otros equipos.
Paradigma sincrnico, organiza a los miembros del
equipo para trabajar en partes del problema con poca
comunicacin activa entre ellos.

Software

 EQUIPOS AGILES.
La filosofa gil alienta la satisfaccin del cliente y la temprana
entrega incremental de software; pequeos equipos de trabajo
enormemente motivados; mtodos informales; mnimos productos
de trabajo de ingeniera del software y simplicidad global de
desarrollo.
El enfoque gil subraya la competencia individual en conjuncin
con la colaboracin del grupo como factores de xito cruciales para
el equipo.
Para aprovechar en forma eficiente las competencias de cada
miembro del equipo y fomentar la colaboracin eficaz a lo largo de
un proyecto de software, los equipos giles son auto organizados.
Un equipo auto organizado no necesariamente mantiene una sola
estructura de equipo, sino que ms bien aprovecha elementos de
los paradigmas aleatorio, abierto y sincrnico.
Software

 CONFLICTOS
DE
COMUNICACIN.

COORDINACION

Existen muchas razones por las cuales los

proyectos
de
software
se
vuelven
problemticos.
La escala de muchos esfuerzos de desarrollo
es grande, lo que conduce a complejidad,
confusin y dificultades significativas en la
coordinacin de los miembros del equipo.
Software

Producto.
Antes de poder planificar un proyecto, se deberan establecer los objetivos y el mbito
del producto, se deberan considerar soluciones alternativas e identificar las
dificultades tcnicas y de gestin. Sin esta informacin, es imposible definir unas
estimaciones razonables (y exactas) del coste; una valoracin efectiva del riesgo, una
subdivisin realista de las tareas del proyecto o una planificacin del proyecto
asequible
que
proporcione
una
indicacin
fiable
del
progreso.
El desarrollador de software y el cliente deben reunirse para definir los objetivos del
producto y su mbito. En muchos casos, esta actividad empieza como parte del
proceso de ingeniera del sistema o del negocio y contina como el primer paso en el
anlisis de los requisitos del software. Los objetivos identifican las metas generales del
proyecto sin considerar cmo se conseguirn (desde el punto de vista del cliente).
El mbito identifica los datos primarios, funciones y comportamientos que caracterizan
al producto, y, ms importante, intenta abordar estas caractersticas de una manera
cuantitativa.
Una vez que se han entendido los objetivos y el mbito del producto, se consideran
soluciones alternativas.

Software

 mbito del software.

La primera actividad de gestin de un proyecto de software es la

determinacin del mbito de software. El mbito se define al responder
las siguientes preguntas:

CONTEXTO Cmo encaja el software que se desarrollar en un sistema ms

grande, producto o contexto de negocios, y qu restricciones se imponen
como resultado del contexto?

OBJETIVOS DE INFORMACION Qu objetos de datos visibles al usuario

producen como resultado del software? Qu objetos de datos se requieren de
entrada?

FUNCION Y DESEMPEO Qu funciones realiza el software para transformar

los datos de entrada en salida? Existen algunas caractersticas de
desempeo especiales que deban abordarse?

Software

El mbito del proyecto de software no debe ser ambiguo ni

incomprensible a niveles de gestin y tcnico. Se debe acotar un
enunciado del mbito del software, es decir, se establecen de manera
explcita los datos cuantitativos, se anotan las restricciones o limitaciones
y se describen los factores que reducen riesgos.

 Descomposicin del problema.

La descomposicin del problema, a veces llamada particin o
elaboracin del problema, es una actividad que se asienta en el
ncleo del anlisis de requisitos de software. La descomposicin se
aplica en dos grandes reas:

La funcionalidad que debe entregarse.

El proceso que se emplear para entregarlo.

Un problema complejo se divide en problemas menores que

resultan ms manejables. sta es la estrategia que se aplica
cuando comienza la planificacin del proyecto.
Las funciones de software se evalan y refinan para proporcionar
ms detalles antes del comienzo de la estimacin. Puesto que las
estimaciones
de
costo
y
planificacin
temporal
estn
funcionalmente orientadas, con frecuencia es til cierto grado de
descomposicin.
Software

Proceso.
Un proceso de software proporciona la estructura desde la que se puede
establecer un detallado plan para el desarrollo del software.
Un pequeo nmero de actividades estructurales se puede aplicar a todos los
proyectos de software, sin tener en cuenta su tamao o complejidad.
Diferentes conjuntos de tareas -tareas, hitos, productos del trabajo y puntos
de garanta de calidad- permiten a las actividades estructurales adaptarse a
las caractersticas del proyecto de software y a los requisitos del equipo del
proyecto.
Finalmente, las actividades protectoras -tales como garanta de calidad del
software, gestin de la configuracin del software y medicin- cubren el
modelo de proceso.
Las actividades protectoras son independientes de las estructurales y tienen
lugar a lo largo del proceso.
Software

 El problema que se presenta es seleccionar el modelo de proceso

apropiado para que un equipo de proyecto someta al software a
ingeniera.
El gestor de proyectos debe decidir cul modelo de proceso es
ms apropiado para:
Los clientes que han solicitado el producto y el personal que har el
trabajo.
Las caractersticas del producto mismo.
El ambiente del proyecto en el que trabaja el equipo de software.

Cuando se ha seleccionado un modelo de procesos entonces el

equipo define un plan de proyecto preliminar con base en el
conjunto de actividades del marco del trabajo del proceso.
Una vez que se establece el plan preliminar, comienza le
descomposicin del proceso.
Software

 Combinacin del producto y el proceso.

La planeacin del proyecto comienza con la
combinacin del producto y del proceso. Cada funcin
que el equipo de software someter a ingeniera debe
pasar a travs del conjunto de actividades del marco
de trabajo definidas para una organizacin de software.

Descomposicin del proceso.

Un equipo de software debe tener un grado
significativo de flexibilidad al elegir el modelo de
procesos de software que sea mejor para el proyecto y
las tareas de ingeniera de software que integren el
modelo de procesos una vez elegido.
Software

 Enfoque secuencial lineal: para realizar un proyecto relativamente

pequeo similar a otros que se hayan realizado.
Modelo de desarrollo rpido de aplicaciones: utilizado cuando
existen restricciones de tiempo muy ceidas.
Estrategia Incremental: utilizado cuando la fecha lmite es tan ceida
que la funcionalidad completa no puede alcanzarse. Proyectos con otras
caractersticas conducirn a la bsqueda de otros modelos.
Una vez elegido el modelo de proceso, el marco de trabajo respectivo se
adapta a l. Podr aplicarse el marco de trabajo genrico: comunicacin,
planificacin, modelado, construccin y despliegue. Funcionar para
modelos lineales, iterativos e incrementales, as como evolutivos e
incluso para modelos concurrentes o de ensamble de componentes.
La descomposicin del proceso comienza cuando el gerente de proyecto
pregunta Cmo lograremos esta actividad del marco de trabajo?
Software

Proyecto.
Dirigimos los proyectos de software planificados y controlados por una
razn principal -es la nica manera conocida de gestionar la
complejidad-. Y todava seguimos esforzndonos. En 1998, los datos de
la industria del software indicaron que el 26% de proyectos de software
fallaron
completamente
y
que
el
46%
experimentaron
un
desbordamiento en la planificacin y en el coste. Aunque la proporcin
de xito para los proyectos de software ha mejorado un poco, nuestra
proporcin de fracaso de proyecto permanece ms alto del que debera
ser.
Para evitar el fracaso del proyecto, un gestor de proyectos de software y
los ingenieros de software que construyeron el producto deben eludir un
conjunto de seales de peligro comunes; comprender los factores del
xito crticos que conducen a la gestin correcta del proyecto y
desarrollar un enfoque de sentido comn para planificar, supervisar y
controlar el proyecto.
Software

La gestin de un proyecto de software exitoso requiere entender que puede salir mal.
John Reel define10 seales que indican que un proyecto de sistemas de informacin
est en peligro:
1. El personal de software no entiende las necesidades de sus clientes.
2. El mbito del producto est mal definido.
3. Los cambios se gestionan mal.
4. La tecnologa elegida cambia.
5. Las necesidades comerciales cambian, o estn mal definidas.
6. Los plazos de entrega no son realistas.
7. Los usuarios se resisten.
8. Se pierde el patrocino.
9. El equipo de proyecto carece de personal.
10.Los gestores evitan las mejores prcticas y las lecciones aprendidas.
Software

Cmo acta un gestor para evitar los problemas

mencionados?

Sugiere un enfoque de sentido comn de 5 partes para

proyectos de software:

1.

Comience con el pie derecho: Entender bien el problema para establecer bien
los objetivos y expectativas. Construir el equipo correcto y darle a ste
autonoma, autoridad y tecnologa.

2.

Mantenga el mpetu: El gestor de proyecto debe proporcionar incentivos, el

equipo debe resaltar la calidad en cada tarea que realiza y los gestores ejecutivos
deben hacer lo posible por mantenerse fuera del camino del equipo.

3.

Rastree el progreso: En un proyecto de software el progreso se rastrea

conforme se elaboran los productos de trabajo(cdigo fuente-modelos) y se
aprueban como parte de una actividad de aseguramiento de calidad

4.

Tomar decisiones inteligentes: Las decisiones del gestor de proyecto y del

equipo de software deben encaminarse para mantenerlo simple.

5.

Realice un anlisis de resultados: Establezca un mecanismo consistente para

extraer lecciones aprendidas por cada proyecto.

Software

Medidas, Mtricas e
Indicadores.

Software

Software

 Las Medidas, mtricas e indicadores son muy importantes, porque ayudan al

desarrollador en la toma de decisiones ya sea para caracterizar, evaluar,
predecir, e incluso mejorar el producto.
Medidas: proporciona una indicacin cuantitativa de la extensin, cantidad,
dimensiones, capacidad o tamao de algunos atributos de un proceso o
producto.
Ejemplo: Un programa tiene 10.000 LDC (lneas de cdigo).
Muchas veces las personas confundimos los trminos Medida y Medicin
pues consideramos que es lo mismo, esto es un error ya que La medicin es
el acto de determinar una medida.
Ejemplo: Lenin ser el encargado de medir las lneas de cdigo de cada
mdulo del sistema.
La Utilidad de la medida del software radica en poder asegurar la calidad,
cuantificar los atributos que constituyen la calidad para el usuario final, de
ah surgen los resultados cuantitativos.
Software

 Mtrica: es una indicacin medible de algn aspecto

cuantificable de un sistema: alcance, riesgo, costo,
tiempo.
Caractersticas de una mtrica til:

Medible
Independiente
Controlable
Precisa

Ejemplo: la productividad de este proyecto fue de 500

(LDC/persona-mes).
Software

 DESVENTAJAS DE LAS METRICAS

Uno de los problemas que tienen las mtricas es que no
existe un esquema de criterios generalmente aceptado
(un estndar). Como no hay acuerdo en los criterios
involucrados, abundan las propuestas de mtricas que
abordan la calidad con criterios propios.
Otro problema de las mtricas es que no proporcionan
informacin por s solas y a veces en vez de claridad
aportan confusin a la contraparte del modelador dentro
del proceso. Esto se debe a que muchas mtricas no
guardan relacin con los intereses de las partes, y el
indicador de la calidad de un esquema se construye
generalmente con todas ellas.

Software

 Indicador: es una mtrica o combinacin de

mtricas que proporcionan una visin profunda del
proceso del software, del proyecto de software o
del producto en s.
Ejemplo: la productividad media de nuestra
empresa es de 500(LDC/pm) y en el ltimo
proyecto ha sido de 250(LDC/pm).
Los indicadores del proyecto permiten al gestor:
Evaluar el estado del proyecto en curso.
Seguir la pista de riesgos potenciales.
Software

Mediciones del software.

Las mediciones del mundo fsico se pueden
categorizar de dos maneras: medidas
directas (por ejemplo: la longitud de un
tornillo) y medidas indirectas (por
ejemplo: la calidad de los tornillos
producidos, medidos contando los artculos
defectuosos).
Las mtricas del software
categorizar de forma similar.
Software

se

pueden

 Medidas Directas: En el proceso de ingeniera se encuentran

el costo, y el esfuerzo aplicado, las lneas de cdigo
producidas, velocidad de ejecucin, el tamao de memoria y
los defectos observados en un determinado periodo de tiempo.
Medidas Indirectas: Se encuentra la funcionalidad, calidad,
complejidad, eficiencia, fiabilidad, facilidad de mantenimiento,
etc.
El coste y el esfuerzo requerido para construir el software, el
nmero de lneas de cdigo producidas, y otras medidas
directas son relativamente fciles de reunir. Sin embargo, la
calidad y funcionalidad del software, o su eficiencia o
mantenimiento son ms difciles de evaluar y slo pueden ser
medidas indirectamente.

Software

 Mtricas Orientadas al Tamao: provienen de la normalizacin

de las medidas de calidad y/o productividad considerando el
tamao del software que se haya producido.
Mtricas Orientadas a la Funcin: las mtricas del software
orientadas a la funcin utilizan una medida de la funcionalidad
entregada por la aplicacin como un valor de normalizacin. Ya que
la funcionalidad no se puede medir directamente, se debe derivar
indirectamente mediante otras medidas directas.
Las mtricas orientadas a la funcin fueron propuestas por primera
vez por Albretch, quien sugiri una medida llamada punto de
funcin.
Los puntos de funcin se derivan con una relacin emprica segn
las medidas contables (directas) del dominio de informacin del
software y las evaluaciones de la complejidad del software.
Software

 Los puntos de funcin se calculan completando la

tabla siguiente:

Software

 Mtricas ampliadas de punto de funcin: la

medida de punto de funcin se dise
originalmente para aplicarse a aplicaciones de
sistemas de informacin de gestin. Por esta
razn, la medida del punto de funcin era
inadecuada para muchos sistemas de ingeniera y
sistemas empotrados (que enfatizan funcin y
control).
Para remediar esta situacin se ha propuesto un
nmero de extensiones a la mtrica del punto de
funcin bsica.

Software

 Mtricas para la calidad del software.

Un buen ingeniero de software utiliza mediciones la
calidad del anlisis y los modelos del diseo, el
cdigo fuente y los casos de prueba que se han
creado al aplicar la ingeniera del software.
Para lograr esta evaluacin de calidad en tiempo
real, el ingeniero debe utilizar medidas tcnicas, que
evalan la calidad con objetividad no con
subjetividad.
El gestor de proyectos tambin debe evaluar la
calidad objetivamente y no subjetivamente.
Software

 Medida de la calidad.
Aunque hay muchas medidas de la calidad de software, la correccin, facilidad de
mantenimiento, integridad y facilidad de uso proporcionan indicadores tiles para el
equipo del proyecto.

Correccin: Es el grado en el que el software lleva a cabo su funcin requerida. La

medida mas comn de correccin es defectos por KLDC.

Facilidad de mantenimiento: Es la facilidad con la que se puede corregir un

programa si se encuentra un error. No hay forma de medir directamente la facilidad
de mantenimiento, por consiguiente se deben utilizar medidas indirectas. Una simple
mtrica orientada el tiempo es el tiempo medio de cambio (TMC), es decir el tiempo
que se tarda en analizar la peticin del cambio. Hitachi ha utilizado una mtrica
orientada al coste para la capacidad de mantenimiento llamada desperdicios, que es
el coste en corregir defectos encontrados despus de haber distribuido el software a
sus usuarios finales.

Integridad: Mide la capacidad de un sistema para resistir ataques (tanto

intencionales como accidentales) contra su seguridad. Para medir la integridad se
tienen que definir dos atributos adicionales amenaza (probabilidad de que un ataque
de un tipo determinado ocurra en un tiempo determinado). La seguridad es la
probabilidad de que se pueda repeler el ataque de un tipo determinado.
Software

Caractersticas.
Objetivos y metas (el proyecto debe ser o hacerse viable, sustentable y medible, con
talentos y recursos asignados, sin estrs y con buen clima laboral y contractual)
Calendario de actividades (debe tener un programa detallado de actividades en
funcin del tiempo -o plan de trabajo- con alcance, metas, talentos y recursos...)
Complejidad manejable (hace sencillo lo complejo, inter relacionando con visin de
totalidad los mltiples elementos componentes y las inter relaciones entre ellos)
Administra recursos (especifica y logra disponibilidad de talentos (conocimientos y
competencias), capital y esfuerzo humano de diversas reas de la organizacin,
comunidad, etc.)
Organizacin matricial (define estructura, sistemas, valores, smbolos, personas y
talentos, asigna responsabilidades y recursos: talentos y logros vs. compensaciones
fijas y variables; x ej. consultor, coach, facilitador, ejecutor, diseador, gerente,
patrocinador, cliente interno, etc.)
Sistema de comunicacin y control (sistema manual o automatizado de registro y
difusin de documentacin e informacin sobre marcha del proyecto, precisando
desviaciones y correctivos)

Software