Métricas en software

1. 1. ¿Qué es una métrica y cuáles son las razones de medición?
El proceso de software y las métricas del proyecto son medidas cuantitativas que
proporcionan a los ingenieros de software una amplia visión del proceso y un
conocimiento detallado acerca del proyecto que se lleva a cabo utilizando el
proceso como marco de trabajo. La medición permite destacar las tendencias (ya
sean buenas o malas) y hacer mejores estimaciones que conducirán a un proyecto
exitoso; comienza definiendo un conjunto limitado de medidas del proceso y del
proyecto, las cuales por lo general se normalizan empleando métricas orientadas al
tamaño o la función, el resultado se analiza y compara con promedios pasados,
luego se valoran las tendencias y se generan conclusiones.
2. ¿Qué son herramientas CASE y enumere y defina algunas de ellas (5), como
su uso, ventajas y desventajas?
Las herramientas CASE (Computer Aided Software Engineering, Ingeniería de
Software Asistida por Computadora) son diversas aplicaciones informáticas
destinadas a aumentar la productividad en el desarrollo de software reduciendo el
costo de las mismas en términos de tiempo y de dinero. Estas herramientas pueden
ayudar en todos los aspectos del ciclo de vida de desarrollo del software en tareas
como el proceso de realizar un diseño del proyecto, cálculo de costos,
implementación de parte del código automáticamente con el diseño dado,
compilación automática, documentación o detección de errores entre otras. Ya en
los años 70 un proyecto llamado ISDOS diseñó un lenguaje y por lo tanto un
producto que analizaba la relación existente entre los requisitos de un problema y
las necesidades que éstos generaban, el lenguaje en cuestión se denominaba PSL
(Problem Statement Language) y la aplicación que ayudaba a buscar las necesidades
de los diseñadores PSA (Problem Statement Analyzer).
Aunque ésos son los inicios de las herramientas informáticas que ayudan a crear
nuevos proyectos informáticos, la primera herramienta CASE fue Excelerator que
salió a la luz en el año 1984 y trabajaba bajo una plataforma PC.
Las herramientas CASE alcanzaron su techo a principios de los años 90. En la época
en la que IBM había conseguido una alianza con la empresa de software AD/Cycle
para trabajar con sus mainframes, estos dos gigantes trabajaban con herramientas
CASE que abarcaban todo el ciclo de vida del software. Pero poco a poco los
mainframes han ido siendo menos utilizados y actualmente el mercado de las Big
CASE ha muerto completamente abriendo el mercado de diversas herramientas más
específicas para cada fase del ciclo de vida del software.
La siguiente clasificación es la más habitual basada en las fases del ciclo de
desarrollo que cubren:

2.  Upper CASE (U-CASE), herramientas que ayudan en las fases
de planificación, análisis de requisitos y estrategia del desarrollo, usando,
entre otros diagramas UML.
 Middle CASE (M-CASE), herramientas para automatizar tareas en
el análisis y diseño de la aplicación.
 Lower CASE (L-CASE), herramientas que semi-automatizan la generación de
código, crean programas de detección de errores, soportan la depuración de
programas y pruebas. Además automatizan la documentación completa de
la aplicación. Aquí pueden incluirse las herramientas de Desarrollo rápido de
aplicaciones.
Existen otros nombres que se le dan a este tipo de herramientas, y que no es una
clasificación excluyente entre sí, ni con la anterior:
 Integrated CASE (I-CASE), herramientas que engloban todo el proceso de
desarrollo software, desde análisis hasta implementación.
 MetaCASE, herramientas que permiten la definición de nuestra propia técnica
de modelado, los elementos permitidos del metamodelo generado se
guardan en un repositorio y pueden ser usados por otros analistas, es decir,
es como si definiéramos nuestro propio UML, con nuestros elementos,
restricciones y relaciones posibles.
 CAST (Computer-Aided Software Testing), herramientas de soporte a la
prueba de software.
 IPSE (Integrated Programming Support Environment), herramientas que
soportan todo el ciclo de vida, incluyen componentes para la gestión de
proyectos y gestión de la configuración activa.
3. ¿Cuáles son las técnicas de descomposición? Dar ejemplos
Las estimaciones se hacen sobre cada componente en que se descompone el
software o sobre tareas de bajo nivel en que se descomponen las tareas.
Las estimaciones de bajo nivel se combinan para producir una estimación del
proyecto completo. Es decir, el coste total del proyecto es el resultado de sumar las
estimaciones de todos los componentes en los que se ha dividido el proyecto.
Cuando se trata con problemas de gran tamaño que no pueden ser resueltos en los
equipos informáticos disponibles, suele recurrirse a técnicas de descomposición,
que permiten fragmentar el problema y coordinar la resolución de los
subproblemas para alcanzar la solución del problema completo. En este sentido,
las técnicas de descomposición se pueden ver como estrategias de partición del
grafo que representa el árbol de escenarios y de resolución coordinada de los
fragmentos del grafo. Este proceso de resolución es de naturaleza iterativa y amplía
el tiempo de solución total, por lo que debe ser evitado siempre que sea posible la
resolución directa. En el caso de los problemas de optimización estocástica, el
empleo de técnicas de descomposición permite la consideración de gran cantidad

3. de escenarios o de problemas con un mayor nivel de detalle en el modelado.
La estimación del proyecto completo se calcula mediante la suma de las cantidades
parciales (enfoque abajo-arriba/bottom-up).
- En la estimación intervienen los responsables de cada componente y/o fase del
proyecto.
- Lo más adecuado es utilizar las técnicas de descomposición estructurada
(EDT/WBS, DFT/WFD).
Técnicas de descomposición:
Del proyecto (o por fases)
Del producto (o por módulos)
Del proyecto y del producto (por fases y por módulos). Es una combinación de las
anteriores.
Entre las ventajas se encuentran:
La posibilidad de que el responsable del componente a estimar participe en dicha
estimación.
Ayuda a analizar con detalle cada componente.
Entre los inconvenientes se encuentran:
La dificultad para contemplar los costes de actividades relacionadas con el proyecto
como lectura de código, revisión, reuniones, y actividades no relacionadas con el
proyecto relacionado con los hábitos de trabajo.
Estimación basada en el problema.
Puede usarse LOC o PF para hacer estimaciones.
Si se utiliza LOC, la descomposición es esencial y a menudo debe ser a detalle.
Si se utiliza PF, en vez de centrar la descomposición en la función, se calcula el PF
como se estudió en el capítulo anterior, estimando de alguna forma, cada uno de
los valores.
En ambos casos, mediante datos históricos o la intuición, se estiman valores
optimista (O), medio (M) y pesimista (P) para cada función o contador, y se calcula
el valor esperado (E) con la siguiente fórmula:
E = (O + 4 * M + P) / 6
Estimación basada en el proceso
Delimitar las funciones del software.
Identificar las tareas de ingeniería del software para cada una de las funciones y
representarlas en una tabla.

4. Estimar el esfuerzo (número de personas/unidad de tiempo) de realización de cada
tarea para cada una de las funciones del software.
Aplicar las tarifas laborales (coste/unidad de esfuerzo) correspondientes a cada una
de las tareas.
Calcular los costes y el esfuerzo para cada función y cada tarea.
Existen dos técnicas principales de descomposición que pueden considerarse como
duales entre sí, ya que realizan la descomposición en dos dimensiones
transversales. Estas dos técnicas son la descomposición de Benders y la relajación
lagrangiana, que se explican en los dos siguientes apartados.
Descomposición de Benders
La descomposición de Benders [Benders,1962], [VanSlyke,1969] propone separar
en subproblemas las decisiones tomadas en diferentes etapas. Para ello se necesita
que las decisiones de una etapa sólo dependan de las consecuencias de las
decisiones tomadas en la etapa anterior. Con esta descomposición se plantea un
problema por cada etapa, y en ese problema se incluye tanto la parte
correspondiente a la propia etapa como la parte que liga esa etapa a las decisiones
tomadas en la etapa anterior.
Relajación lagrangiana
El otro método de descomposición más relevante es la relajación lagrangiana
[Geoffrion, 1970], En esta ocasión se intentan separar dentro de cada etapa las
decisiones para grupos de variables que están relacionadas entre sí. Es decir, se
pueden localizar conjuntos de variables que están muy conectadas con otras
etapas, pero poco relacionadas con otras variables de la misma etapa.
4. ¿En la identificación de los riesgos, cuáles son los más relevantes?
Identificación y clasificación del Riesgo
La identificación del riesgo es un intento sistemático para especificar las amenazas
al plan de proyecto (estimaciones, planificación temporal, cargo de recursos, etc.).
Identificando los riesgos conocidos y predecibles, el gestor del proyecto da un paso
adelante para evitarlos cuando sea posible y controlarlos cuando sea necesario.
Existen dos tipos diferenciados de riesgos para cada categoría:
1. Riesgos Genéricos: Son una amenaza potencial para todos los proyectos de
software.

5. 2. Riesgos específicos: Los riesgos específicos de producto sólo los pueden
identificar los que tienen una clara visión de la tecnología, el personal y el
entorno específico del proyecto en cuestión, entre los que están:
o Tamaño del producto: Riesgos asociados con el tamaño general del
software a construir o a modificar.
o Impacto en el negocio: Riesgos asociados con las limitaciones
impuestas por la gestión o por el mercado.
o Características del cliente: Riesgos asociados con la sofisticación del
cliente y la habilidad del desarrollador para comunicarse con el cliente
en los momentos oportunos.
o Definición del proceso: Riesgos asociados con el grado de definición
del proceso del software y su seguimiento para la organización de
desarrollo.
o Entorno de desarrollo: riesgos asociados con la disponibilidad y
calidad de las herramientas que se van a emplear en la construcción
del producto.
o Tecnología a construir: Riesgos asociados con la complejidad del
sistema a construir y la tecnología de punta que contiene el sistema.
o Tamaño y experiencia de la plantilla: Riesgos asociados con la
experiencia técnica y de proyectos de los ingenieros de sw que van a
realizar el trabajo.
5. ¿Cuáles son los riesgos relacionados con el cliente?
Riesgos asociados con la sofisticación del cliente y la habilidad del desarrollador
para comunicarse con el cliente en los momentos oportunos.
 Los clientes tienen diferentes necesidades: algunos saben lo que quieren,
otros no.
 Los clientes tienen diferentes necesidades.
 Los clientes también tienen varios tipos de asociaciones con sus
suministradores.
 Los clientes se contradicen a menudo.
Ejemplo: si trabajó con el cliente, si el cliente tienen la idea formal de lo que quiere,
aceptará gastar tiempo en reuniones, está dispuesto a mantener una comunicación
fluida, está dispuesto a participar en revisiones, es sofisticado técnicamente el
áreas del producto, si está dispuesto dejar a su personal hacer el trabajo, si
entiende el proceso de software.
Si alguna de las respuestas es no, se deberá realizar una investigación más
profunda para valorar el potencial del riesgo.