Unidad 2 Calidad de Software >

2.2 Estándares y Métricas de calidad en la ingeniería de SW

MEDICIÓN Y MÉTRICAS DEL SOFTWARE

Sería posible acelerar el proceso de revisión utilizando herramientas que procesaran el diseño del
software o el programa, e hiciesen valoraciones automáticas de la calidad del software. Estas
valoraciones permiten comprobar que el software tiene el umbral de calidad requerido, y destacar
las partes en las cuales no se ha alcanzado para revisarlas.

La medición del software se refiere a derivar un valor numérico desde algún atributo del software
o del proceso software. Comparando estos valores entre sí y con los estándares aplicados en la
organización, es posible sacar conclusiones de la calidad del software o de los procesos para
desarrollarlo.

Las mediciones del software pueden utilizarse para:

Hacer predicciones generales acerca del sistema.

Identificar componentes anómalos.

Una métrica de software es cualquier tipo de medida relacionada con un sistema, proceso o
documentación de software. Algunos ejemplos son las medidas que se utilizan para calcular el
tamaño de un producto en líneas de código; el índice de Fig., que mide la claridad de un párrafo en
un texto; el número de fallos encontrados en un producto software entregado; y el número de
personas/día requeridas para desarrollar un componente del sistema.

LAS MÉTRICAS SON DE CONTROL O DE PREDICCIÓN.

Las métricas de control suelen estar asociadas con los procesos, mientras que las métricas de
predicción lo están a los productos. Ejemplos de las métricas de control o de procesos son el
esfuerzo y el tiempo promedio requeridos para reparar los defectos encontrados. Ejemplos de
métricas de predicción son la complejidad ciclomática de un módulo, la longitud media de los
identificadores de un programa, y el número de atributos y operaciones asociadas con los objetos
de un diseño.

1
Frecuentemente, es imposible medir los atributos de calidad del software directamente. Los
atributos de calidad como la mantenibilidad, la comprensión y la usabilidad son atributos externos
que nos dicen cómo ven el software los desarrolladores y los usuarios. Éstos se ven afectados por
diversos factores y no existe un camino simple para medirlos. Más bien es necesario medir
atributos internos del software (como su tamaño) y suponer que existe una relación entre lo que
queremos medir y lo que queremos saber.

Para que la medida del atributo interno sea un indicador útil de la característica externa, se deben
cumplir tres condiciones:

El atributo interno debe medirse de forma precisa

Debe existir una relación entre lo que se puede medir y el atributo de comportamiento externo.

Esta relación se comprende, ha sido validada y se puede expresar en términos de una fórmula o
modelo.

Las métricas del producto se dividen en dos clases:

Las métricas dinámicas, que son recogidas por las mediciones hechas en un programa en
ejecución.

Las métricas estáticas, que son recogidas por las mediciones hechas en las representaciones del
sistema como el diseño, el programa o la documentación. Las métricas dinámicas ayudan a valorar
la eficiencia y la fiabilidad de un programa y por lo general están relacionadas de forma cercana
con los atributos de calidad del software. Las métricas estáticas ayudan avalorar la complejidad, la
comprensión y la mantenibilidad de un sistema de software; por lo general están relacionadas de
forma cercana con los atributos de calidad del software.

ANÁLISIS DE LAS MEDICIONES

Uno de los problemas con la recogida de datos cuantitativos en el software y en los proyectos de
software es comprender lo que significan realmente los datos. Es fácil malinterpretar los datos y
hacer inferencias incorrectas. Las mediciones se deben analizar cuidadosamente para comprender
lo que realmente significan.

Los procesos y productos para medir no están aislados de su entorno y los cambios en ese entorno
invalidan las comparaciones de los datos. Los datos cuantitativos de las actividades humanas no
siempre pueden tomar se como valores de entrada.

PUNTOS CLAVE

2
La gestión de la calidad del software permite señalar si éste tiene un escaso número de defectos y
si alcanza los estándares requeridos de mantenibilidad, fiabilidad, portabilidad, etcétera, las
actividades de la gestión de la calidad comprenden la garantía de la calidad que establece los
estándares para el desarrollo de software, la planificación de la calidad y el control de la calidad
que comprueba el software con respecto a los estándares definidos.

Un manual de calidad organizacional debe documentar un conjunto de procedimientos de garantía

de la calidad. Éste puede basarse en los modelos genéricos sugeridos en los estándares ISO 9000.

Los estándares de software son importantes para garantizar la calidad puesto que representan una
identificación de las «mejores prácticas». El proceso de control de calidad implica comprobar que
el proceso del software y el software a desarrollar concuerdan con estos estándares.

Las revisiones de los productos a entregar por el proceso del software incumben a un equipo de
personas los cuales comprobarán que se han seguido los estándares de calidad, las revisiones son
la técnica más utilizada para valorar la calidad.

2.2.1 PSP y TSP

PSP

Es un conjunto de prácticas disciplinadas para la gestión del tiempo y mejora de la productividad

personal de los programadores o ingenieros de software, en tareas de desarrollo y mantenimiento
de sistemas. Está alineado y diseñado para emplearse en organizaciones con modelos de procesos
CMMI o ISO 15504. Fue propuesto por Watts Humphrey en 1995 y estaba dirigido a estudiantes. A
partir de 1997 con el lanzamiento del libro "An introduction to the Personal Software Process" se
dirige ahora a ingenieros juniors.

Se puede considerar como la guía de trabajo personal para ingenieros de software en

organizaciones que emplean un modelo CMMI con nivel de madurez o de capacidad de procesos
que implica la medición cualitativa y mejora de procesos.

Uno de los mayores problemas que tiene es la gran cantidad de datos que hay que tomar. El PSP
tiene obsesión por la toma de datos y elaboración de tablas. El PSP se orienta el conjunto de áreas
clave del proceso que debe manejar un desarrollador cuando trabaja de forma individual.

3
PSP, es uno de los 3 vértices donde descansa un proceso de mejora que trabaja sobre 3 niveles de
la organización, los otros 2 son CMM y TSP.

El PSP amplia el proceso de mejora a la gente que realiza el trabajo de desarrollo de software,
concentrándose en las practicas de trabajo de los ingenieros en una forma individual, enseñando
como manejar la calidad desde el principio de un producto. PSP son nuestras propias métricas, que
permiten estructurar y ordenar nuestro trabajo del día a día (no solo de desarrollo de software,
esto lo voy a explicar mas adelante). El resultado de nuestro trabajo, además puede ser llevado a
un trabajo en equipo TSP (Team Process Software), el cual es “comandado” por un sistema de
gestión de la configuración y por supuesto, un Jefe de Proyecto quien evalúa los resultados y
avances de los miembros del equipo.

TSP

Team Software Process (TSP) es un método de establecimiento y mejora del trabajo en equipo para
procesos software.

TSP proporciona directrices para ayudar a un equipo a establecer sus objetivos, a planificar sus
procesos y a revisar su trabajo con el fin de que la organización pueda establecer prácticas de
ingeniería avanzadas y así obtener productos eficientes, fiables y de calidad. Está formado por dos
componentes primarios que abarcan distintos aspectos del trabajo en equipo:

Formación del equipo de trabajo.

Gestión del equipo de trabajo.

Existen diferentes metodologías para la mejora de procesos, la mayoría de ellas se basa en la

mejora de los procesos que dan como resultado un servicio o producto. El TSP busca integrar un
equipo que tenga como punto de partida la unificación del mismo, para poder llevar a cabo todos
aquellos procedimientos que puedan realizar mejora a los procesos que desarrollan.

El Team Software Process (TSP) es un proceso de desarrollo para equipos de ingenieros basado en
CMMI, ayuda a conformar equipos para el desarrollo de software de calidad. TSP proporciona
directrices para ayudar a un equipo a establecer sus objetivos, a planificar sus procesos y a revisar
su trabajo con el fin de que la organización pueda establecer prácticas de ingeniería avanzadas y
así obtener productos eficientes, fiables y de calidad.

4
TSP es una solución basada en procesos para resolver problemas de negocio, tales como:

Predictibilidad de costo y tiempo

Mejora de productividad

Ciclos de desarrollo y mejora de calidad de productos.

Características de los grupos eficaces:

Miembros expertos en papeles de liderazgo y pertenencia.

Relaciones tranquilas y establecidas entre los miembros.

Los miembros se sienten atraídos por el grupo y son fieles.

Los valores y metas del grupo son los de sus integrantes

Los miembros están motivados por hacer lo que puedan por el grupo.

La interacción y toma de decisiones tiene lugar en el ambiente adecuado.

El grupo desea ayudar a cada miembro a adquirir su pleno El grupo desea ayudar a cada miembro
a adquirir su pleno potencial.

Cada miembro acepta con gusto y sin resentimiento las metas y normas establecidas.

Los miembros se prestan ayuda mutua cuando es necesaria o recomendable.

Existe una atmósfera de creatividad.

El grupo conoce el “conformismo constructivo” y se sirve de él.

Existe gran motivación para iniciar y recibir las comunicaciones.

Los miembros son flexibles y adaptables en sus metas y actitudes.

Los miembros se sienten seguros al tomar decisiones que les Los miembros se sienten seguros al
tomar decisiones que les parecen apropiadas al entender la filosofía de la operación.

Sus orígenes se deben a las limitaciones que el PSP (Personal Software Process, su antecesor) tenía
en el ámbito industrial. PSP resultó muy efectivo para que los ingenieros pudiesen tener el control
de su proceso personal mediante la mejora de sus habilidades de estimación y la reducción de los
defectos introducidos en los productos sin afectar a su productividad, pero PSP sólo se enfocaba en
las fases de desarrollo de software (diseño y pruebas unitarias); la aplicación que lo ingenieros
hicieron del PSP dentro de las empresas resulto en prácticas no satisfactorias.

5
Por tal motivo, Watts Humphrey desarrolló el TSP, el cual consideraba como parte importante,
además de lo previsto por el PSP, los requisitos, las pruebas de integración, la documentación y
otras actividades típicas en todo proyecto de desarrollo, de igual manera incluía actividades como
los roles de equipo, interrelaciones dentro de la organización y la definición de un proceso de
equipo para ser utilizado dentro de los procesos existentes en la organización.

Los Roles (responsabilidades) en los equipos en STP son:

Líder del Equipo: Dirige al equipo, se asegura que todos reporten sus datos de los procesos y
completen su trabajo tal y como se planeó. Realiza los reportes semanales del avance del equipo.

Gestor de desarrollo: Guía al equipo en el diseño y desarrollo del producto.

Gestor de Planificación: Apoya y guía al equipo en la planificación y seguimiento del trabajo.

Gestor de Calidad/Proceso: Apoya al equipo en definir sus necesidades acerca del proceso y a
establecer y administrar el plan de calidad. Genera estándares para obtener un trabajo uniforme.
Modera las inspecciones y revisa cada artefacto generado.

Administrador de Requerimientos/Soporte: Dirige al equipo en el desarrollo de requerimientos de

software y ayuda a dar a conocer la tecnología y en las necesidades de apoyo administrativo.
Administra el plan de configuración

Es necesario que los ingenieros que usan TSP estén formados en PSP. Con TSP, los equipos
encuentran y reparan defectos en etapas tempranas del proceso de desarrollo, esto reduce de
manera importante el tiempo de pruebas. Esto reduce de manera importante el tiempo de
pruebas. Con un testing más corto, el ciclo completo se reduce.

A diferencia de otros métodos, TSP mejora el desempeño tanto de equipos como individuos, es
disciplinado y ágil, provee beneficios inmediatos y medibles y acelera las iniciativas de mejora de
procesos organizacionales.

En las fases del Ciclo TSP se planea el número de ciclos. Dentro de cada ciclo se realiza:

6
Lanzamiento

Estrategia

Plan

Requisitos

Diseño

Implementación

Pruebas

Postmortem

Los objetivos que tiene el TSP son:

Maximizar calidad software, minimizar costos.

Integrar equipos independientes de alto rendimiento que planeen su trabajo, establezcan metas y
san sueños de sus procesos y planes.

Mostrar a los gerentes como monitorear y motivar a sus equipos de trabajo y como ayudarlos a
alcanzar su máxima productividad.

Acelerar la mejora continua de monitoreo.

Proveer de una guía para e mejoramiento en organizaciones maduras

Sus entornos son:

CMM- Administración.

TSP- Equipo Ingenieros.

PSP-Ingeniero.

2.2.2 CMM

Modelo de Capacidad y Madurez o CMM (Capability Maturity Model), es un modelo de evaluación

de los procesos de una organización.

7
Fue desarrollado inicialmente para los procesos relativos al software por la Universidad Carnegie-
Mellon para el SEI (Software Engineering Institute).

El SEI es un centro de investigación y desarrollo patrocinado por el Departamento de Defensa de

los Estados Unidos de América y gestionado por la Universidad Carnegie-Mellon. "CMM" es una
marca registrada del SEI.

EL MODELO CMM

A partir de noviembre de 1986 el SEI, a requerimiento del Gobierno Federal de los Estados Unidos
de América, desarrolló una primera definición de un modelo de madurez de procesos en el
desarrollo de software, que se publicó en septiembre de 1987. Este trabajo evolucionó al modelo
CMM o SW-CMM (CMM for Software), cuya última versión (v1.1) se publicó en febrero de 1993.

Este modelo establece un conjunto de prácticas o procesos clave agrupados en Áreas Clave de
Proceso (KPA - Key Process Area). Para cada área de proceso define un conjunto de buenas
prácticas que habrán de ser:

Definidas en un procedimiento documentado

Provistas (la organización) de los medios y formación necesarios

Ejecutadas de un modo sistemático, universal y uniforme (institucionalizadas)

Medidas

Verificadas

A su vez estas Áreas de Proceso se agrupan en cinco "niveles de madurez", de modo que una
organización que tenga institucionalizadas todas las prácticas incluidas en un nivel y sus inferiores,
se considera que ha alcanzado ese nivel de madurez.

Los niveles son:

Inicial. Las organizaciones en este nivel no disponen de un ambiente estable para el desarrollo y
mantenimiento de software. Aunque se utilicen técnicas correctas de ingeniería, los esfuerzos se
ven minados por falta de planificación. El éxito de los proyectos se basa la mayoría de las veces en
el esfuerzo personal, aunque a menudo se producen fracasos y casi siempre retrasos y
sobrecostes. El resultado de los proyectos es impredecible.

Repetible. En este nivel las organizaciones disponen de unas prácticas institucionalizadas de

gestión de proyectos, existen unas métricas básicas y un razonable seguimiento de la calidad. La
relación con subcontratistas y clientes está gestionada sistemáticamente.

Definido. Además de una buena gestión de proyectos, a este nivel las organizaciones disponen de
correctos procedimientos de coordinación entre grupos, formación del personal, técnicas de
ingeniería más detallada y un nivel más avanzado de métricas en los procesos. Se implementan
técnicas de revisión por pares (peer reviews).

8
Gestionado. Se caracteriza porque las organizaciones disponen de un conjunto de métricas
significativas de calidad y productividad, que se usan de modo sistemático para la toma de
decisiones y la gestión de riesgos. El software resultante es de alta calidad.

Optimizado. La organización completa está volcada en la mejora continua de los procesos. Se hace
uso intensivo de las métricas y se gestiona el proceso de innovación.

Así es como el modelo CMM establece una medida del progreso, conforme al avance en niveles de
madurez. Cada nivel a su vez cuenta con un número de áreas de proceso que deben lograrse. El
alcanzar estas áreas o estadios se detecta mediante la satisfacción o insatisfacción de varias metas
claras y cuantificables. Con la excepción del primer nivel, cada uno de los restantes Niveles de
Madurez está compuesto por un cierto número de Áreas Claves de Proceso, conocidas a través de
la documentación del CMM por su sigla inglesa: KPA.

Cada KPA identifica un conjunto de actividades y prácticas interrelacionadas, las cuales cuando son
realizadas en forma colectiva permiten alcanzar las metas fundamentales del proceso. Las KPAs
pueden clasificarse en 3 tipos de proceso:

Gestión

Organizacional

Ingeniería.

Las prácticas que deben ser realizadas por cada Area Clave de Proceso están organizadas en 5
Características Comunes, las cuales constituyen propiedades que indican si la implementación y la
institucionalización de un proceso clave es efectivo, repetible y duradero.

Estas 5 características son:

Compromiso de la realización

La capacidad de realización

Las actividades realizadas

Las mediciones y el análisis

La verificación de la implementación.

Las organizaciones que utilizan CMM para mejorar sus procesos disponen de una guía útil para
orientar sus esfuerzos. Además, el SEI proporciona formación a evaluadores certificados (Lead
Assesors) capacitados para evaluar y certificar el nivel CMM en el que se encuentra una
organización. Esta certificación es requerida por el Departamento de Defensa de los Estados
Unidos, pero también es utilizada por multitud de organizaciones de todo el mundo para valorar a
sus subcontratistas de software.

Se considera típico que una organización dedique unos 18 meses para progresar un nivel, aunque
algunas consiguen mejorarlo. En cualquier caso requiere un amplio esfuerzo y un compromiso
intenso de la dirección.

9
Como consecuencia, muchas organizaciones que realizan funciones de factoría de software o, en
general, outsourcing de procesos de software, adoptan el modelo CMM y se certifican en alguno
de sus niveles. Esto explica que uno de los países en el que más organizaciones certificadas exista
sea India, donde han florecido las factorías de software que trabajan para clientes estadounidenses
y europeos.

A partir de 2001, en que se presentó el modelo CMMI, el SEI ha dejado de desarrollar el SW-CMM,
cesando la formación de los evaluadores en diciembre de 2003, quienes dispondrán hasta fin de
2005 para reciclarse al CMMI. Las organizaciones que sigan el modelo SW-CMM podrán continuar
haciéndolo, pero ya no podrán ser certificadas a partir de fin de 2005.

2.2.3 MOPROSOFT

Modelo de Procesos para la Industria del Software. Modelo para la mejora y evaluación de los
procesos de desarrollo y mantenimiento de sistemas y productos de software. Desarrollado por la
Asociación Mexicana para la Calidad en Ingeniería de Software a través de la Facultad de Ciencias
de la Universidad Nacional Autónoma de México (UNAM) y a solicitud de la Secretaría de
Economía para obtener una norma mexicana que resulte apropiada a las características de tamaño
de la gran mayoría de empresas mexicanas de desarrollo y mantenimiento de software. Moprosoft
es el nombre del modelo en la comunidad universitaria y profesional, y la norma técnica a la que
da contenido es la NMX-059/01-NYCE-2005 que fue declarada Norma Mexicana el 15 de agosto de
2005 con la publicación de su declaratoria en el Diario oficial de la Federació.

Moprosoft considera que los modelos de evaluación y mejora CMMI e ISO/IEC 15504 no resultan
apropiados para empresas pequeñas y medianas de desarrollo y mantenimiento de software.
Sobre las áreas de procesos de los niveles 2 y 3 del modelo SW-CMM e inspirándose en el marco
de ISO/IEC 15504 se ha desarrollado este modelo.

Criterios empleados

Se han aplicado los siguientes criterios para la elaboración de este modelo de procesos:

La estructura de procesos resultante debe ser acorde a la estructura generalmente empleada por
las organizaciones de la industria del software (alta dirección, gestión y operación)

La alta dirección tiene un papel importante a través de la planificación estratégica. Debe actuar
como promotor del buen funcionamiento de la organización a través de su implicación en la
revisión y mejora continua del modelo.

El modelo considera a la gestión como proveedora de recursos, procesos y proyectos; así como
responsable de la vigilancia del cumplimiento de los objetivos estratégicos de la organización.

10
El modelo considera a la operación como ejecutora de los proyectos de desarrollo y
mantenimiento de software.

El modelo integra con claridad y consistencia los elementos indispensables para la definición de los
procesos y las relaciones entre ellos.

El modelo integra los elementos para realizar la administración de proyectos desde un sólo
proceso.

El modelo integra los elementos para realizar la ingeniería de productos de software en un único
marco que incluya los procesos precisos de soporte (verificación, validación, documentación y
control de la documentación).

El modelo destaca la importancia de la gestión de recursos, con especial relevancia en aquellos que
componen el conocimiento de la organización: productos generados por proyectos, datos de los
proyectos, mediciones, documentación de procesos y datos cosechados a partir del uso y de las
lecciones aprendidas.

Moprosoft se basa en los modelos de procesos ISO 9001:2000, en las áreas de procesos de los
niveles 2 y 3 de CMM-SW: CMM-SW v.1.1., en el marco general ISO/IEC15504 y en prácticas y
conceptos de PMBOK Y SWEBOK.

PROSOFT representa un campo diferente de apoyo a los empresarios de las tecnologías de la

información, es un sector diverso para hacer negocios y generar fuentes de empleo dignas”

El Plan Nacional de Desarrollo 2001-2006 plantea el fomento a la industria y el mercado De

Tecnologías de la Información (TI) como estrategia para aumentar la competitividad del País. Dado
el gran potencial con que cuenta México para desarrollar esta industria, la Secretaría de Economía,
en coordinación con organismos empresariales y empresas del Sector, diseñó el PROSOFT.

El Moprosoft se estructura en 3 categorías:

Categoría de Alta Dirección (DIR): Se establecen los lineamientos para los procesos de la Categoría
de Gerencia y se retroalimenta con la información generada por ellos en apoyo a la estrategia de la
organización.

Categoría de Gerencia (GER): Se definen los elementos para el funcionamiento de los procesos de
la Categoría de Operación en función de la estrategia de Dirección, recibe y evalúa la información
generada por éstos y comunica los resultados a la Categoría de Alta Dirección.

Categoría de Operación (OPE): Se realizan las actividades de acuerdo a los elementos

proporcionados por la Categoría de Gerencia y entrega a ésta la información y productos
generados

11
2.3 Impacto de la calidad en tiempo, costo y alcance del proyecto

La gestión deja de ser una tarea aislada para constituirse en una herramienta que sirve para
ejecutar las acciones necesarias que permitan ordenar, disponer y organizar los recursos de un
proyecto, utilizando procedimientos específicos y optimizando la relación entre recursos y
resultados.

Objetivos de la gestión: Conocer y hacer el mejor uso posible de los recursos disponibles para
satisfacer de manera óptima los objetivos perseguidos, teniendo en cuenta las limitaciones que se
puedan presentar.

Niveles de gestión

Las labores de gestión abarcan todos los ámbitos de un proyecto, incluyendo los administrativos e
incluso financieros, el alcance y la trascendencia de las acciones que se ejecuten. En este ámbito se
destacan los siguientes niveles:

Gestión del alcance: Comprende las actividades orientadas a garantizar el cumplimiento de las
tareas necesarias para lograr los objetivos del proyecto.

Gestión técnica o de proceso: Incluye las actividades necesarias para garantizar que los resultados
del proyecto satisfagan las necesidades y requerimientos de los gestores o inversionistas.

Gestión del Tiempo: Comprende las actividades necesarias para asegurar que el proyecto se
ejecute en el plazo estimado y que los resultados (producción de bienes o servicios) estén a
disposición de los clientes o consumidores.

Gestión de costos: Asegura que las tareas se lleven a cabo dentro de los rangos económicos
impuestos (presupuesto del proyecto o recursos asignados para la actividad correspondiente).

Gestión de calidad: Tiene que ver con las actividades que aseguran que el proyecto satisface los
requisitos bajo los cuales deben generarse los resultados.

Gestión de los recursos: Para que una empresa cumpla su misión, logre sus objetivos y le entregue
resultados favorables a los propietarios, es necesario que cuente con recursos suficientes para que
contribuyan a una gestión adecuada incrementando la productividad de la empresa.

Gestión de la comunicación: Permite garantizar que la información formal e informal, se genere,

recopile, almacene y utilice de forma adecuada.

Gestión de compras y adquisiciones: Cuando el proyecto es de cierta complejidad, se hace

necesario definir algunos procedimientos que estén orientados a la correcta selección y obtención
de bienes y servicios que deben ser llevados de fuera de la empresa o del proyecto.

12
ALCANCES

El alcance de un proyecto llamado también alcance del trabajo es el trabajo que debe hacerse para
que el cliente se convenza de que las entregas (las cosas por hacer), es decir el producto u objetos
tangibles que han de suministrarse) cumplan con los requisitos o criterios de aceptación acordados
al comenzar el proyecto. Por ejemplo, el alcance podría ser el trabajo de limpiar el suelo, de
construir una casa, poner la jardinería ornamental según las especificaciones hechas por el cliente
y aceptadas por el contratista.

GESTIÓN DEL ALCANCE

Comprende las actividades orientadas a garantizar el cumplimiento de las tareas necesarias para
lograr los objetivos del proyecto.

La gestión del alcance del proyecto se relaciona principalmente con la definición y el control de lo
que está y no está incluido en el proyecto.

En el contexto del proyecto, la palabra alcance puede referirse a lo siguiente:

Alcance del producto. Las características y funciones que caracterizan a un producto, servicio o
resultado.

Alcance del proyecto. El trabajo que debe realizarse para entregar un producto, servicio o
resultado con las funciones y características especificadas.

PLANIFICACIÓN DEL ALCANCE

El plan de gestión del alcance del proyecto es una herramienta de planificación que describe cómo
el equipo definirá el alcance del proyecto, desarrollará el enunciado del alcance del proyecto
detallado, definirá y desarrollará la estructura de desglose del trabajo, verificará y controlará el
alcance del proyecto.

HERRAMIENTAS Y TÉCNICAS

Análisis del Producto Técnicas como desglose del producto, análisis de sistemas, ingeniería de
sistemas, ingeniería del valor, análisis del valor y análisis funcional.

Identificación de Alternativas Las más comunes son la tormenta de ideas y el pensamiento lateral.

13
Juicio de Expertos

Análisis de los Interesados Identifica la influencia y los intereses de los diversos interesados y
documenta sus necesidades, deseos y expectativas.

VERIFICACIÓN DEL ALCANCE

La verificación del alcance es el proceso de obtener la aceptación formal por parte de los
interesados del alcance del proyecto completado y los productos entregables relacionados.

Verificar el alcance del proyecto incluye revisar los productos entregables para asegurarse de que
cada uno se complete satisfactoriamente.

CONTROL DEL ALCANCE

El control del alcance del proyecto se encarga de influir sobre los factores que crean cambios en el
alcance del proyecto y de controlar el impacto de dichos cambios.

El control del alcance del proyecto también se usa para gestionar los cambios reales cuando se
producen, y está integrado con los demás procesos de control. Los cambios no controlados a
menudo se denominan corrupción del alcance del proyecto. Los cambios son inevitables, con lo
cual se impone algún tipo de proceso de control de cambios.

ESTRUCTURA

Por estructuración se entiende la facilidad con que las funciones pueden ser compartidas y la
naturaleza jerárquica de la información a tratar. A medida que el grado de estructuración aumenta,
la posibilidad de estimar con precisión mejora y, por consiguiente, el riesgo disminuye.

Bajo el concepto de la administración de proyectos, se asignan representantes de cada uno de los

departamentos funcionales de las divisiones al equipo asignado al proyecto. Cada miembro del
equipo deriva una guía funcional experta y control administrativo del gerente de departamento. El
equipo incluye al siguiente personal clave:

Gerente de Proyectos

Ingeniero de Proyectos

Gerente de Construcción del proyecto

14
Coordinador de construcción del proyecto

Ingeniero de puesta en marcha del proyecto

Ingeniero de aseguramiento de la calidad del proyecto

Supervisor de costo y programas del proyecto

Administrador del proyecto

Gerente de aprovisionamiento del proyecto

Asistente del controlador del proyecto

ESPECIFICACIONES

El concepto en la preparación de planos y especificaciones es que los planos del proyecto definen
la geometría incluyendo dimensiones, forma y detalles mientras que las especificaciones
complementen esto definiendo aspectos generales, materiales y la ejecución necesaria.

Muchos profesionales de la construcción confían en que los planos contienen lo necesario para
ejecutar su proyecto de infraestructura.

En el momento en que se requiere más información o cuando surgen discrepancias, entonces

buscan más detalles en las especificaciones. Es entonces donde muchas veces aparecen problemas
porque las especificaciones no son adecuadas y, en vez de aclarar la intención del diseñador, crean
complicaciones adicionales.

TIEMPO, COSTOS Y RECURSOS

La estimación del tiempo forma parte del proceso de Gestión del Tiempo de la Administración de
Proyectos.

La Gestión del Tiempo del Proyecto incluye los procesos necesarios para lograr la conclusión del
proyecto a tiempo. Los procesos de Gestión del Tiempo del Proyecto incluyen lo siguiente:

Definición de las Actividades: identifica las actividades específicas del cronograma que deben ser
realizadas para producir los diferentes productos entregables del proyecto.

Establecimiento de la Secuencia de las Actividades: identifica y documenta las dependencias entre

las actividades del cronograma.

Estimación de Recursos de las Actividades: estima el tipo y las cantidades de recursos necesarios
para realizar cada actividad del cronograma.

15
Estimación de la Duración de las Actividades: estima la cantidad de períodos laborables que serán
necesarios para completar cada actividad del cronograma.

Desarrollo del Cronograma: analiza las secuencias de las actividades, la duración de las actividades,
los requisitos de recursos y las restricciones del cronograma para crear el cronograma del proyecto.

Control del Cronograma: controla los cambios del cronograma del proyecto.

COSTOS

La estimación de costos de una actividad es una evaluación cuantitativa de los costes probables de
los recursos necesarios para completar las actividades del cronograma del proyecto. Este tipo de
estimación puede presentarse en forma de resumen o en detalle.

Los costos se estiman para todos los recursos que se aplican a la estimación de costos de la
actividad. Esto incluye, entre otros, la mano de obra, los materiales, los equipos, los servicios, las
instalaciones, la tecnología de la información, y categorías especiales como una asignación por
inflación o una reserva para contingencias de costo.

RECURSOS

La estimación de recursos y costes es una actividad importante que debe llevarse a cabo con el
mayor detalle posible, porque permite al comprador establecer una aproximación al coste total y
plazos del desarrollo del sistema.

Para ello se requiere experiencia, acceso a una buena información histórica y determinación para
confiar en medidas cuantitativas cuando todo lo que existe son datos cualitativos.

Factores que afectan a esta estimación:

La complejidad del proyecto, cuantificando la misma en función de:

Número de módulos y nivel de interrelación entre los mismos.

Número y tipo de las interfaces externas con otros sistemas, programas o datos.

Grado de distribución y heterogeneidad del entorno de implantación.

Grado de sofisticación de las herramientas de desarrollo.

Naturaleza de los algoritmos que se deben diseñar y programar.

16