Aseguramiento de
la Calidad del Software. Disponible en http://datateca.unad.edu.co/contenidos/201014/2015-1/Aseguramiento_de_la_calidad_del_software.pdf
ASEGURAMIENTO DE
LA CALIDAD DE SOFTWARE
1.
Calidad de software
Hablamos todo el
tiempo de problemas relacionados con la calidad del software, pero no tenemos una
definición precisa de lo que ésta significa. Sin una definición clara, concisa
y medible de lo que es la calidad del software, no podemos tomar buenas
decisiones de negocio respecto del uso de los recursos, ni en qué áreas mejorar
la calidad, ni que herramientas y técnicas utilizar para mejorar la calidad.
Hay diferentes
puntos de vista para definir calidad de software. Desde el punto de vista del
cumplimiento de los requerimientos Roger Pressman define la calidad de software
como:
“El cumplimiento de los requerimientos funcionales y
de performance explícitamente definidos, de los estándares de desarrollo
explícitamente documentados y de las características implícitas esperadas del
desarrollo de software profesional.”
Desde el punto
de vista del cliente o usuario Watts Humphrey dice:
“El foco principal de cualquier definición de calidad
de software debería ser las necesidades del cliente. Crosby [6] al igual que
Pressman [1] define la calidad como conformidad con los requerimientos.
Mientras uno puede discutir la diferencia entre requerimientos, necesidades y
deseos, la definición de calidad debe considerar la perspectiva de los
usuarios. Entonces las preguntas claves son ¿Quiénes son los usuarios?, ¿Qué es
importante para ellos? Y ¿Cómo sus prioridades se relacionan con la manera en
que se construye, empaqueta y se da soporte al producto?”
Al Davis define
calidad del software como:
“La calidad no se trata de tener cero defectos o una
mejora medible de la proporción de defectos, no se trata de tener los
requerimientos documentados. No es más ni menos que satisfacer las necesidades
del cliente (por más que las necesidades estén o no correctamente
documentadas)”
Finalmente,
desde estas dos perspectivas el glosario de la IEEE para la ingeniería de
software define la calidad del software como:
“El grado con el cual un sistema, componente o proceso
cumple con los requerimientos y con las necesidades y expectativas del
usuario.”
Más allá de cómo
definamos la calidad del software, para que la definición tenga sentido esta
debe ser medible. Para poder controlar la calidad del software es necesario,
ante todo, definir los parámetros, indicadores o criterios de medición, ya que,
como bien plantea Tom De Marco, "no se puede controlar lo que no se puede
medir".
Para poder
identificar los costos y beneficios del software se definieron los atributos de
calidad. La intención es separar el software en atributos que puedan ser
medidos o cuantificados (en términos de costo beneficio). Ejemplos de estos
atributos son confiabilidad, adaptabilidad, usabilidad y funcionalidad.
Para clasificar
los atributos de calidad del software se definieron varios modelos, uno ellos
fue el modelo FURPS+. Este modelo fue desarrollado por Robert Grady y Deborah
Caswell de Hewlett Packard - 24 - Bajo el acrónimo FURPS+, por sus siglas en
inglés, se definen las siguientes características:
El más (+) en el
acrónimo FURPS+ nos permite especificar restricciones, incluyendo restricciones
de diseño, implementación e interfaces.
La obtención de
un software con calidad implica la utilización de metodologías o procedimientos
estándares para el análisis, diseño, programación y prueba del software que
permitan uniformar la filosofía de trabajo, en aras de lograr una mayor
confiabilidad, mantenibilidad y facilidad de prueba, a la vez que eleven la
productividad, tanto para la labor de desarrollo como para el control de la
calidad del software.
Cuando no se
cumplen los estándares o procesos de la organización o del proyecto se dice que
estamos frente a una no conformidad. Lo esperable es la ausencia de no
conformidades (conformidad) El costo de conformidad (calidad) no es
despreciable, pero es menor que el costo de su alternativa (Costo de no
conformidad). Crosby describe el costo de la no-conformidad como aquel costo en
el que se incurre porque el producto o servicio no se desarrolló de forma
apropiada la primera vez.
La calidad del
software puede medirse después de elaborado el producto. Pero esto puede
resultar muy costoso si se detectan problemas derivados de imperfecciones en el
diseño o requerimientos, por lo que es imprescindible tener en cuenta tanto la
obtención de la calidad como su control durante todas las etapas del ciclo de
vida del software.
En el siguiente
cuadro Pressman muestra el costo relativo de corregir un error en las distintas
etapas del ciclo de vida.
Como se puede
observar en la tabla 5, el costo relativo de corregir un error en producción es
cientos de veces más que en la etapa de requisitos. El 50% del costo de
corrección de defectos en las últimas fases se debe a defectos introducidos en
las primeras.
Entonces uno de
los propósitos que guían el aseguramiento de la calidad es que es mucho menos
costoso corregir los problemas en sus fases iniciales que esperar hasta que un
problema se manifieste a través de las quejas del usuario.
Los principios
básicos del concepto de calidad del software son:
·
No alcanza en pensar en calidad
a la hora hacer las revisiones y pruebas, sino que debe ser una preocupación
durante todo el ciclo de vida del software.
·
Sólo se alcanza con la
contribución de todas las personas involucradas.
·
La calidad debe ser planificada
y gestionada con eficacia.
·
Dirigir esfuerzos a prevención
de defectos.
·
Reforzar los sistemas de
detección y eliminación de defectos durante las primeras fases.
·
La calidad es un parámetro
importante del proyecto al mismo nivel que los plazos de entrega, costo y
productividad.
Es esencial la
participación de la dirección, que ha de propiciar la calidad.
Hasta aquí, lo
que define el modelo FURPS+ son los atributos de calidad de los productos de
software, pero también los procesos que se siguen en su desarrollo cuentan con
atributos de calidad como por ejemplo que estén bien definidos, que estén
documentados, que sean practicados y medidos. La calidad depende de los
procesos, debe estar orientada al cliente y es de mejora continua.
2.
Aseguramiento de la calidad de
software
Sofware Quality Assurance
Al igual que
ocurrió con la definición de calidad hay varios puntos de vista desde donde se
puede definir el aseguramiento de la calidad del software.
Desde el punto
de vista de la evidencia, la IEEE define el aseguramiento de la calidad como:
“Una guía planificada y sistemática de todas las
acciones necesarias para proveer la evidencia adecuada de que un producto
cumple los requerimientos técnicos establecidos. Un conjunto de actividades
diseñadas para evaluar el proceso por el cual un producto es desarrollado o
construido.”
Daniel Galin
define SQA como:
“Un conjunto, sistemático y planificado, de acciones
necesarias para proveer la evidencia adecuada de que el proceso de desarrollo o
mantenimiento de un sistema de software cumple los requerimientos técnicos
funcionales tan bien como los requerimientos gerenciales para cumplir la
planificación y operar dentro del presupuesto confinado”
Para certificar
madurez de procesos, hay que evidenciar que uno aplica un cierto proceso y para
esto se deben registrar las distintas actividades de tal proceso de desarrollo,
como éste es el objetivo que persigue el software a desarrollar como parte de
esta tesis, elegiremos la definición que da la IEEE desde el punto de vista de
la generación de evidencia adecuada que muestre que se cumple con el proceso
que se dice seguir y con los requerimientos establecidos.
Software Quality Control
3.
Funciones del SQA
Describir los
diferentes roles que puede jugar el equipo de SQA en una organización nos dará
una visión clara de las funciones que puede llevar a cabo.
“Como policía
del proceso”: el trabajo del equipo de SQA es asegurar que el desarrollo sigue
el proceso establecido. Entre sus funciones en este rol se encuentran:
·
Auditar los productos del
trabajo para identificar deficiencias.
·
Determinar el cumplimiento del
plan de desarrollo del proyecto y del proceso de desarrollo de software.
·
Juzgar el proceso y no el
producto.
“Como abogado
del cliente”: el trabajo del equipo de SQA es representar al cliente. Entre sus
funciones en este rol se encuentran:
·
Identificar la funcionalidad
que al cliente le gustaría encontrar.
·
Ayudar a la organización a
sensibilizarse con las necesidades del cliente.
·
Actuar como un cliente de
prueba para obtener una alta satisfacción del cliente.
“Como analista”
el trabajo del equipo de SQA es recabar información. Entre sus funciones en
este rol se encuentran:
·
Juntar muchos datos sobre todos
los aspectos del producto y del proceso.
·
Con esta información ayudar a
mejorar los procesos y los productos.
“Como proveedor
de información” el trabajo del equipo de SQA es revisar qué es lo que esté
hecho y decir cuáles objetivos técnicos realmente están cumplidos para que la
gerencia pueda tomar mejores decisiones de negocios. Entre sus funciones en
este rol se encuentran:
·
Proveer información técnica
objetiva para que la gerencia pueda usarla para tomar mejores decisiones.
·
Proveer información apropiada
de las clases de productos y de los riesgos asociados con estos.
·
Concentrarse más en la
reducción de los riesgos que en el cumplimiento del proceso.
“Como
responsable de la elaboración del proceso” el trabajo del equipo de SQA es
participar en la definición de los planes, procesos, estándares y
procedimientos para asegurar que se ajustan a las necesidades del proyecto y
que pueden ser usados para realizar las evaluaciones de QA y cumplir los
requerimientos del proyecto y las políticas de la organización. Para cumplir
este rol el aseguramiento de la calidad debería comenzar en las fases tempranas
del proyecto.
Aquí conviene
aclarar que no necesariamente las personas que definen la metodología a seguir
pertenecen al equipo de QA. Definir la metodología puede llegar a ser o no una
actividad del equipo de QA. Una estructura posible en el proceso de mejora del
software puede ser contar con un SEPG (Software Engineering Process Group)
totalmente independiente del equipo de QA, encargado de definir la metodología
mientras que el equipo de QA se limita a verificar que se cumpla dicha
metodología.
EOI AMERICA,
GERENCIA DE PROYECTOS MASTER EUROPEO EN GERENCIA Y ADMINISTRACIÓN. Disponible
en: http://api.eoi.es/api_v1_dev.php/fedora/asset/eoi:48238/componente48236.pdf
GERENCIA DE
PROYECTOS
1.
Definición de proyecto
De acuerdo con
la Norma Internacional ISO 10006, un proyecto se puede definir como aquel
proceso único, que consiste en un conjunto de actividades coordinadas y
controladas con fechas de inicio y fin, llevadas a cabo para lograr un objetivo
conforme con requisitos específicos los cuales incluyen los compromisos de
plazos, costes, y recursos.
Según el PMI
(Project Management Institute) un proyecto es un esfuerzo de carácter temporal
llevado a cabo con objeto de crear un producto o servicio único (PMBoK 2000),
mientras que un programa es un conjunto de proyectos interrelacionados.
De las
definiciones anteriores puede concluirse que los proyectos tienen las
siguientes características:
·
Es un proceso único constituido
por subprocesos y actividades coordinadas con objeto de realizar uno o más
productos.
·
Son de naturaleza temporal
caracterizándose por tener fechas de comienzo y terminación determinadas.
·
Precisan de una cantidad de
recursos determinada y de una estructura organizacional con roles y
responsabilidades predefinidos para realizar los productos antes mencionados de
acuerdo a ciertos requisitos (calidad, plazos, costes).
·
Al tratarse de un proceso
único, mayor relevancia de los riesgos. Dado que el producto o servicio no
existe en el momento de iniciarse el proyecto ya que se desarrolla a medida que
éste se ejecuta, lo único verdaderamente fijo es el cliente y sus necesidades,
debiendo estar el producto del proyecto subordinado a estas necesidades.
El resultado
global del proyecto, en adelante producto de proyecto, es un producto o un
servicio y puede ser de cualquier naturaleza: una automóvil, un garaje, un
programa de software, el rediseño de un proceso de negocio, el desarrollo de un
nuevo fármaco, el diseño de una cadena de negocio, la creación de una empresa,
etc.
Por último, la
dirección de proyectos es la aplicación de conocimientos, habilidades,
herramientas, y técnicas a las actividades del proyecto para satisfacer los
requisitos del mismo. El término de dirección de proyectos es muchas veces
utilizado por organizaciones orientadas a proyectos que gestionan sus
actividades u operaciones continuas o que intentan alcanzar sus objetivos
utilizando técnicas de gestión de proyectos.
2.
Contexto de los proyectos
Todo proyecto es
parte de un determinado contexto social, tecnológico y organizacional que
afecta e impone restricciones a su desarrollo. Las restricciones impuestas
pueden ser de diversos tipos: organizacionales, tecnológicas, legales, medioambientales,
estratégicas, tipo de proyecto, etc. Así, puede tratarse de un proyecto de
demanda (como sucede por ejemplo cuando se desarrolla algo para un cliente
externo en un proyecto bajo contrato), o de un proyecto de oferta (como en el
caso de lanzamiento de un nuevo producto resultado de una iniciativa estrategia
determinada, o de un proyecto interno de implantación de un sistema informático
de gestión). Es preciso que el portafolio de proyectos de la empresa esté
equilibrado, es decir, debe existir una proporción adecuada entre proyectos de
oferta y de demanda.
Los proyectos se
desarrollan normalmente en el seno de una organización más amplia –
organización ejecutante- afectando la organización y madurez en gestión de
proyectos de ésta a la organización del proyecto y a su desarrollo. A su vez,
los proyectos pueden afectar a una parte de la organización, a toda la
organización o a varias organizaciones (socios, subcontratistas, proveedores,
etc.). Es decir, siempre existirán interrelaciones entre la “organización del
proyecto” y la “organización ejecutante”.
El contexto
organizacional ejerce también una poderosa influencia sobre el proyecto a
través de la estructura de la organización ejecutante. La estructura
organizativa condiciona la manera en que se ponen a disposición del director de
proyecto los recursos necesarios, determinando su autoridad.
3.
STAKEHOLDERS (Interesados en el
proyecto)
Las partes
interesadas, también llamadas Stakeholders, son individuos y organizaciones
involucrados en el desarrollo del proyecto o cuyos intereses pueden verse
afectados positiva o negativamente como resultado de la ejecución del proyecto
o por el producto del proyecto durante sus fases de operación y retirada.
Entre las partes
interesadas se pueden incluir diferentes roles, que pueden recibir diferentes
nombres según el sector y organización de que se trate. A modo de ejemplo:
·
El director o jefe de proyecto,
que es la persona encargada de la gestión del proyecto.
·
El cliente, que es la persona u
organización destinataria del producto del proyecto.
·
Organización ejecutante, que es
aquella en cuyo seno se desarrolla el proyecto.
·
Miembros del equipo que
constituye la organización del proyecto.
·
Consumidor o usuario final del
producto del proyecto.
·
Patrocinador o sponsor.
·
Subcontratistas, que son
organizaciones encargadas de la realización de parte del alcance del proyecto.
·
Comité de proyecto, encargado
de la toma de decisiones de alto nivel del proyecto.
·
La sociedad, como por ejemplo
el público en general, agencias e instituciones públicas, entidades con
capacidad normativa, medios de comunicación, etc.
·
Otros: socios (en el caso de
proyectos tipo joint venture), proveedores, subcontratistas, organismos subvencionadores,
auditores de proyecto, etc.
4.
Gestión de Alcance
El concepto de
alcance es un término relativamente ambiguo que origina interpretaciones
dispares y a veces encontradas entre cliente y suministrador, pero que resulta
esencial en proyectos. Nosotros lo definiremos como:
“El alcance es
la combinación de los objetivos del proyecto más el trabajo necesario para
alcanzar los objetivos”
Vemos por tanto
que el alcance tiene dos dimensiones de las que a su vez se deducen las
definiciones siguientes:
·
Alcance del producto (product
scope): características y funciones que caracterizan a un producto o servicio.
Éstas incluyen tanto características de tipo técnico como características del
producto relacionadas con el plazo de terminación (time-to-market) y coste de
producto final. El alcance de proyecto se mide contra el plan de proyecto.
·
Alcance del proyecto (project
scope): trabajo que debe ser realizado para entregar el producto (del proyecto)
con las características y funciones especificadas. El alcance de producto se
mide contra los requisitos de cliente.
5.
Gestión del tiempo
La gestión del
tiempo incluye todas las actividades necesarias para conseguir cumplir con el
objetivo de fecha de entrega del producto del proyecto. Incluye las siguientes
actividades: identificación de actividades, secuenciación lógica de
actividades, estimación de duración de las actividades, y elaboración del
cronograma de proyecto.
En la
identificación de actividades e hitos pueden emplearse listas de actividades o
plantillas de proyectos similares realizados en la organización ejecutante.
Estas listas habrán de ser revisadas de acuerdo al proyecto de que se trate,
añadiendo o suprimiendo actividades. En el caso de carecer de registros
históricos es posible recurrir a la opinión de expertos - que son normalmente
los responsables de la realización de las actividades se trate- utilizando
técnicas como la tormenta de ideas.
Una vez
identificadas los hitos y las actividades de diferente nivel que componen el
alcance del proyecto, es preciso identificar y documentar las relaciones
lógicas que existen entre ellas. Para ello pueden utilizarse redes o plantillas
de proyectos anteriores similares o porciones de estas redes, también llamadas
subredes.
La estimación de
la duración de las actividades exige determinar previamente las cantidades y
los tipos de recursos necesarios. Para ello podemos recurrir a diversas
alternativas como: la opinión de expertos, análisis de alternativas de
ejecución (con diferentes combinaciones de recursos y cantidades), información
publicada (tasas de producción, etc), estimación de detalle, etc. La estimación
de recursos por actividad servirá también para determinar su coste, por lo que
ambos procesos de estimación de coste y duración se realizan en paralelo.
Al determinar la
duración es imprescindible distinguir entre esfuerzo y duración. Si, por
ejemplo, el responsable de una actividad que precisa de una persona declara una
duración de 5 días, ¿Qué quiere esto decir? Podría tratarse tanto de una
persona trabajando durante 8 horas al día (40 horas de esfuerzo) como de una
persona que dedica a la actividad 1 hora diaria durante 5 días (5 horas de
esfuerzo). Las estimaciones de esfuerzo y los incurridos correspondientes serán
registrados como parte de la información histórica de proyecto.
El cronograma
del proyecto (project schedule) puede definirse como el conjunto de fechas
planificadas para realizar las actividades e hitos del proyecto, y constituye
el Plan de Referencia de Tiempo o Línea de Base de Tiempos contra la que se
medirá el progreso alcanzado durante la ejecución. La determinación del
cronograma se realiza a partir de la lista de actividades, la relación lógica
entre ellas expresada en forma de diagrama de red, la duración de las
actividades, la disponibilidad de recursos (ver nivelado de recursos), y el
análisis de riesgos realizado en el que se identifican los riesgos principales
del proyecto (registro de riesgos). Respecto a este último punto, se prestará
especial atención a los puntos de convergencia de la red, que suelen ser hitos
de proyecto donde el riesgo puede ser elevado.
6.
Gestión de coste
La gestión del
coste del proyecto incluye todas aquellas actividades necesarias para la
planificación, estimación, obtención del plan de referencia de costes o
baseline, y control de costes, con objeto de completar el proyecto dentro del
presupuesto asignado.
·
Coste de ciclo de vida (LCC:
Life Cycle Cost). Comprende todos los costes incurridos durante la vida
estimada del producto, correspondiente al sistema completo, subsistemas y
componentes. Incluye los costes de investigación y desarrollo, ensayos,
producción, adquisición, sistema de apoyo, mantenimiento, operación y costes de
eliminación. Es importante destacar que en muchos proyectos el coste de
adquisición del producto desarrollado constituye un porcentaje reducido del
coste de ciclo de vida, por lo que será este coste de ciclo de vida el
utilizado por el cliente en sus decisiones de inversión. El coste de ciclo de
vida es el coste visto desde la perspectiva del cliente, ya que será él quien
normalmente financie todos los costes, desde los de desarrollo, hasta los de
eliminación del sistema una vez concluye su vida útil.
·
Costes fijos (Fixed costs).
Costes que no varían prácticamente con el volumen de producción o carga de
trabajo, y en los que se debería seguir incurriendo aun en el supuesto de que
la carga de trabajo fuese nula. Entre ellos podemos citar los costes de
seguros, alquiler, impuestos, y gestión de la empresa. Estos costes constituyen
la parte más importante de los costes indirectos de una empresa.
·
Costes variables (Variable
costs). Costes que son incurridos en función de la carga de trabajo, sea ésta
un volumen de producción o un nivel de prestación de servicio. Normalmente son
costes directos, aunque pueden tener un componente indirecto.
·
Costes directos (Direct costs).
Costes o agregados de costes que pueden ser identificados con algún objetivo
final cuyo coste se quiere estimar, ya sea éste un producto, un servicio o un
proyecto. Estos costes pueden ser repercutidos directamente a un proyecto al
representar un consumo de recursos exclusivo para ese proyecto.
·
Costes indirectos (Overhead
costs or indirect costs). Son aquellos costes que no pueden ser identificados
con algún fin específico. Normalmente son cargados a cuentas o fondos de costes
indirectos para ser después repercutidos a los productos o servicios según
algún método preestablecido por la empresa. Caso de que en la empresa hubiera
un único proyecto, no cabría hablar de costes indirectos, ya que, al estar
todos los recursos orientados al desarrollo de ese proyecto único, todos los
costes serían directos.
·
Gastos generales (General and
administrative costs). Se trata de una categoría de costes indirectos
relacionados con los departamentos de staff de la empresa, tales como
Dirección, contabilidad, relaciones públicas, y cualesquiera otros que
desarrollen actividades para el conjunto de la empresa. Pueden variar entre un
5% y un 25% de los costes totales directos e indirectos de la empresa.
·
Carga horaria (Labor burden).
Corresponde a los gastos de seguridad social a cargo de la empresa, vacaciones,
primas, bajas por enfermedad, costes de subactividad o tiempo no productivo,
planes de pensiones, etc. Se trata de un coste indirecto que normalmente se
expresa como un porcentaje del coste horario marginal correspondiente a sueldos
y salarios, siendo ese porcentaje función de la relación entre el tiempo no
productivo correspondiente a la carga horaria y el tiempo productivo.
·
Carga de materiales (Material
burden). Corresponde a los costes administrativos de compra, manipulación,
control de inventario y almacenamiento de los materiales y equipos del
proyecto. Normalmente se recuperan como un porcentaje de su valor de compra,
siendo el porcentaje función del valor relativo del producto respecto al coste
de carga de materiales. En ocasiones, cuando se trata de equipos que requieran
un proceso individualizado de compra y manipulación, son tratados como costes
directos. Fondos de contingencia (Contingency budget). Como se verá en el
capítulo dedicado al riesgo, ante una situación o evento de riesgo, pueden
tomarse distintas medidas. Una de ellas es dotar un fondo o contingencia -que
puede ser de coste o de tiempo- que será utilizada en caso de que el riesgo
llegue a materializarse. Estos fondos son parte del presupuesto del proyecto y
actúan protegiendo al margen o al plazo de finalización del proyecto frente a
los riesgos. Si éstos no llegaran a materializarse, estos fondos pasarían a
engrosar el margen del proyecto. Existen 2 tipos de contingencias: las
derivadas del análisis de riesgos del proyecto (Contingency Reserve), y las
contingencias de reserva de gestión (Management Reserve).
·
Costes no recurrentes
(Non-recurring costs). Son aquellos costes en los que se incurre para
desarrollar la primera unidad de un producto. En un proyecto son todos los
asociados a las fases de desarrollo y de inversión en instalaciones de
producción: ingeniería, ensayos, fabricación de prototipos, elaboración de
documentación de usuario, desarrollo del sistema de apoyo, aprovisionamiento y
desarrollo de instalaciones de producción, etc.
·
Costes recurrentes (Recurring
costs). Costes en los que se incurre repetidamente al aumentar el número de
unidades producidas. Por ejemplo, son costes recurrentes las compras de
materiales y mano de obra directa empleados en la fabricación de las unidades,
los ensayos de aceptación y los gastos de transporte de las unidades.
·
Escalación de costes (Cost
escalation). Son los costes originados por el incremento de precio de los
recursos utilizados en el proyecto.
·
Curva de experiencia (Learning
Curve). La curva de experiencia o de aprendizaje es la representación
matemática de la reducción en recursos coste, tiempo, experimentada al realizar
una tarea dada de forma repetitiva. Se utiliza en proyectos en los que el
número de unidades a producir es grande (fase de producción de proyectos con
series largas) para determinar cómo disminuyen los recursos (materiales y mano
de obra) necesarios para producir una unidad de producto con el nivel acumulado
de producción. Ha de ser considerada como un coste más del proyecto cuando
exista el factor aprendizaje (por ejemplo, cuando exista personal nuevo que es
preciso formar).
La estimación de
costes es un subproceso de gestión de costes del proyecto consistente en la
determinación del coste de los diferentes elementos del EDP/WBS a partir de uno
o varios de los siguientes: características de producto, definición de tareas y
actividades del trabajo a realizar, recursos necesarios, costes horarios, y
estimación de duración.
A continuación,
se presenta una lista de métodos de estimación de costes con una breve
descripción de cada uno de ellos:
·
Estimación de detalle. La
estimación de detalle consiste en la determinación de los recursos necesarios
al nivel más bajo posible del EDP/WBS. La estimación de detalle sólo se podrá
realizar cuando exista un diseño detallado del producto o proyecto y un programa
de fabricación, ensayo, montaje y entrega del mismo. La determinación del coste
consistirá en un desglose del tipo de recursos y habilidades necesarios y de su
cuantía, junto con el coste unitario de los mismos. Así mismo, será necesario
disponer de un criterio de asignación de costes indirectos y gastos generales
en la determinación del coste total.
·
Estimación directa. Se trata de
una estimación realizada por un experto que está familiarizado con tareas
similares a las que se trata de estimar. Por ejemplo, cuando se trata de
estimar el coste de fabricación de un conjunto de piezas y sólo se dispone de
un plano de conjunto del mismo, un experto podría dar un presupuesto aproximado
del coste basado en el número de horas y cantidades aproximadas de materiales a
utilizar.
·
Estimación por analogía. Este
método se basa en analizar los recursos utilizados en actividades similares o
análogas a las actividades del proyecto cuyo coste se quiere estimar, y en la
comparación de ambas. Por ejemplo, un estimador podría determinar el coste de
un ensayo mediante la comparación con un ensayo similar de otro proyecto, cuya
duración fue la mitad, aplicando un factor de 2 y las correcciones que
considerara pertinentes. Un problema asociado a este método es el riesgo que supone
no identificar pequeñas variaciones en el contenido de trabajo de las tareas
que puedan tener un impacto apreciable en el coste.
·
Cotizaciones de subcontratistas
y proveedores. Este eficaz método de estimación se basa en determinar el coste
de un producto o servicio a partir de las cotizaciones de subcontratistas. Para
que este método de estimación no pierda su eficacia es necesario que se
soliciten varias cotizaciones del trabajo a realizar (al menos tres) y que el
suministrador elabore una solicitud de oferta (RFP, RFQ, ITB, etc) completa y
precisa.
·
Estimación paramétrica de
costes. Este método se usa normalmente en las fases iniciales de un proyecto,
cuando no existe información detallada del mismo. Los modelos paramétricos de
estimación de costes se basan en la correlación existente entre las
características físicas de un producto (peso, volumen, materiales empleados,
precisión de mecanizado requerida, complejidad, etc.) con los recursos o coste
necesario para desarrollarlo o producirlo. Es, por tanto, un método de
estimación de arriba-abajo, ya que el coste del producto se obtiene a partir de
las características del mismo, en contraposición al método de estimación de
detalle abajo-arriba, en el que el coste del producto se obtiene a partir del coste
de sus componentes. Los métodos de estimación paramétrica tienen como ventajas
principales su capacidad de realización de análisis de sensibilidad
coste-configuración y la posibilidad de obtener el coste del producto o
proyecto, sin necesidad de tener un conocimiento detallado del mismo ni del
trabajo a realizar. Son más precisos que los métodos de estimación de detalle
en las fases iniciales del proyecto.
·
Utilización de la curva de
aprendizaje. Ya definida anteriormente en el apartado de clasificación de
costes.
·
Otros. Utilización de
bibliografía, catálogos, revistas y manuales que contengan información de coste
y de los recursos necesarios (materiales, productos semi-terminados, equipos,
solares, alquileres, servicios, etc.) para desarrollar un proyecto.
7.
Gestión de riesgos
La gestión de
los riesgos es una parte integral de la dirección del proyecto, siendo un
elemento clave en el proceso de toma de decisiones. Cualquier empresa que vaya
a comenzar un nuevo proyecto se enfrenta al reto de invertir dinero en
personal, equipamiento e instalaciones, formación, suministros y gastos
financieros. El mejor modo de evitar el fracaso del proyecto, que en ocasiones
puede llegar a originar la ruina de la organización, es la utilización de
ciertas herramientas que permiten gestionar los riesgos.
Como parte de la
gestión del riesgo, es preciso definir una política de riesgos del proyecto con
objeto de mantener los riesgos inherentes dentro de límites definidos y
aceptados. Esta política debe estar de acuerdo con la política de riesgos de la
organización, de manera que la identificación y el tratamiento de los riesgos
sea consistente y homogéneo en todos los proyectos.
Se entiende por
riesgo en un proyecto, un evento o condición que, si ocurre, tiene un efecto
sobre los objetivos del proyecto. Los riesgos pueden ser positivos o negativos.
Los riesgos negativos influyen negativamente sobre alguno o varios objetivos
del proyecto, como, por ejemplo:
Aumento de los
costes del proyecto
·
Retrasos de proyecto.
·
Disminución de calidad.
·
Impacto en el medio ambiente.
·
Pérdida o daños a personas o
propiedades.
·
Otros. Es necesario gestionar
estos riesgos de manera que su efecto sobre el proyecto sea nulo o mínimo.
También existe
una concepción de riesgo como oportunidad, en cuyo caso se habla de riesgos
positivos. En este caso lo que se pretende mediante la gestión de riesgos es
incidir sobre los factores que puedan provocar la aparición de estos riesgos.
La gestión de
los riesgos consta de cuatro procesos (identificación, análisis, planificación
de la respuesta y supervisión y control de riesgos) que a continuación pasamos
a describir.
Los riesgos
pueden dividirse en distintos tipos:
·
Aceptables y no aceptables.
Aceptables son aquellos que si ocurren no degradan o paralizan críticamente al
proyecto.
·
A corto y largo plazo. A corto
plazo son los riesgos cuya ocurrencia tiene efecto inmediato en el proyecto.
·
Positivos y negativos.
Positivos son aquellos cuya ocurrencia ayuda al proyecto.
·
Controlables y no controlables.
Controlables son aquellos en los que el jefe de proyecto tiene autoridad para
gestionar el riesgo. Los riesgos no controlables deben ser comunicados al
sponsor de manera que pueda nombrarse un propietario de cada riesgo encargado
de su gestión.
·
Internos y externos. Son
riesgos internos aquellos que son causados por elementos que están dentro de
los límites del proyecto.
Existen
múltiples técnicas de identificación de riesgos. Éstas son:
·
Revisión estructurada de la
documentación del proyecto y de archivos de proyectos anteriores.
·
Tormenta de ideas. Mediante
esta técnica se generan ideas acerca de los riesgos del proyecto con la ayuda
de un facilitador. Es el método más utilizado.
·
Técnica Delphi. Es una técnica
para alcanzar el consenso sobre un tema determinado de manera anónima, sin que
se produzca influencia personal entre los miembros del grupo. Se envía un
cuestionario para solicitar ideas acerca de los riesgos más importantes, siendo
luego enviadas a otras personas para generar comentarios adicionales.
·
Listas de verificación. Son
listas que sirven de guía para la identificación y categorización de riesgos
según las fuentes de riesgos más usuales. Tienen como inconveniente el que
pueden inducir a limitar la búsqueda a aquellos riesgos contenidos en la lista.
Las listas nunca son exhaustivas, son solo una guía que se enriquece con la
experiencia acumulada en proyectos sucesivos. Debe ser revisada por su hubiera
riesgos adicionales. En la tabla siguiente se presenta un ejemplo de distintos
riesgos agrupados según 4 categorías o fuentes de riesgo diferentes. Es
frecuente considerar de manera aislada los riesgos asociados al personal. Otras
fuentes posibles de riesgo serían: comerciales, jurídicos, políticos, etc.
El análisis de
riesgos puede ser cualitativo o cuantitativo. El análisis de riesgos
cualitativo precede en ocasiones al cuantitativo, cuando se quiere profundizar
en algún riesgo concreto. En otras ocasiones precede directamente a la
planificación de respuesta al riesgo, obviándose el análisis cuantitativo.
El análisis de
riesgos tiene como objetivo establecer una priorización de los riesgos del
proyecto para su tratamiento posterior. También permite establecer una
clasificación general de riesgo del proyecto, en relación a otros proyectos de
la organización. Esta información puede ser utilizada para apoyar decisiones de
inicio o cancelación de un proyecto, para realizar asignaciones de recursos
entre proyectos, o para la realización de análisis costo-beneficio. La repetición
de estos análisis proporciona información sobre tendencias que indiquen
acciones a tomar para gestionar el riesgo.
