Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Métrica Orientada al Tamaño

No description
by

Rosario Lucena

on 28 October 2013

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Métrica Orientada al Tamaño

Métrica Orientada al Tamaño
INTRODUCCIÓN:
Cuando se planifica un proyecto se tiene que obtener estimaciones del costo y esfuerzo humano requerido por medio de las mediciones de software que se utilizan para recolectar los datos cualitativos acerca del software y sus procesos para aumentar su calidad.

Sin lugar a duda, el poder medir es y será siempre algo valioso, pues
en función al tamaño es posible determinar el costo de las cosas,
por ejemplo, cuando compramos manzanas, su unidad de medida es
el kilogramo, en función a ello sabemos cuánto cuesta, medio kilo,
1,2,3, etc… Los kilos que sean.

En la mayoría de los desafíos técnicos, las métricas nos ayudan a entender tanto el proceso
técnico que se utiliza para desarrollar un producto, como el propio producto. El proceso
para intentar mejorarlo, el producto se mide para intentar aumentar su calidad.

Las métricas son medidas cuantitativas que permiten obtener una visión de la eficacia de
proceso de software y los proyectos que se llevan a cabo utilizando ese proceso como
marco de trabajo.
Un método de estimación de coste de desarrollo no es otra cosa que establecer una
relación matemática entre el esfuerzo y el tiempo requerido para desarrollar un producto /
proyecto.

Todo proyecto de ingeniería de software debe partir con un buen
plan, pero lamentablemente, la planificación es una tarea nada de trivial. Uno de los aspectos que dificultan la labor de
administradores y jefes de proyecto en torno a la planificación es la difícil tarea de realizar una estimación de costos y plazos realista.
El manejador de costo principal para un proyecto de desarrollo de software es sin duda el tamaño del producto.
La medida del tamaño debe ser tal que esté en relación directa con el esfuerzo de desarrollo, por lo que las métricas de tamaño tratan de considerar todos los aspectos que influyen en el costo, como tecnología, tipos de recursos y complejidad.

MODELO COCOMO
El Modelo Constructivo de Costos (o COCOMO, por su acrónimo del ingléses COnstructive COst MOdel) es un modelo matemático de base empírica utilizado para estimación de costos de software.
Este modelo fue desarrollado por Barry W. Boehm a finales de los años 70 y comienzos de los 80, exponiéndolo detalladamente en su libro "Software Engineering Economics" (Prentice-Hall, 1981).
Características: Pertenece a la categoría de
modelos de subestimaciones basados en
estimaciones matemáticas. Está orientado a la
magnitud del producto final, midiendo el
"tamaño" del proyecto, en líneas de código
principalmente.
Ejemplos
PROBLEMAS ANTE LA FALTA
DE UNA MEDICIÓN
¿Cómo va el proyecto? - Bien, bien.
Dos semanas después… -¿Cómo va el proyecto?
- Bien, bien.
Tres semanas después… -El lunes hay que entregar el proyecto.-
- El lunes !!?. oh nooo...Todavía falta mucho!!
-¿Cómo? Me dijiste que el proyecto iba bien!! Arréglatelas como quieras, pero el proyecto tiene que estar terminado para el lunes.
Reflexión: Si no sabes el tamaño del proyecto y no sabes cuanto llevas hecho, nunca sabrás cuando vas a terminar.
Esto ocurre cuando no existe un proceso de desarrollo.
Los presupuestos se disparan.
No se entrega en plazo.
Los trabajadores trabajan noches y fines de semana (no hay control temporal)
No se conoce el estado en el que está el proyecto.
Desarrollo opaco.
CALIDAD DEL SOFTWARE
Conseguir productos software de calidad es uno de los objetivos principales de las métricas del software.

¿Cómo podemos obtener software de calidad?
¿Cómo podemos medir y evaluar la calidad de un producto software?

El software al no ser físico es difícil medir su función, ventajas y costes. Por lo tanto, los procesos y los métodos para manejar, para supervisar, y para medir su calidad pueden ser muy complejos.



Hay varias razones para medir un producto
1.Para indicar la calidad del producto.
2.Para evaluar la productividad de la gente que desarrolla el producto.
3.Par evaluar los beneficios en términos de productividad y de calidad
derivados del uso de nuevos métodos y herramientas de la ingeniería de
software.
4.Para establecer una línea de base para la estimación.
5.Para ayudar a justificar el uso de nuevas herramientas o de formación
adicional.
Las mediciones del mundo físico pueden englobarse en dos
categorías:
Medidas Directas: En el proceso de ingeniería se encuentran el
costo, y el esfuerzo aplicado, las líneas de código producidas,
velocidad de ejecución, el tamaño 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.
A TENER EN CUENTA
Satisfacción del usuario = Producto manejable + Buena Calidad + Entrega dentro de
presupuesto y tiempo.

La calidad del software puede medirse después de que el producto haya sido implementado:
Si se hace así, nos puede salir muy caro si detectamos problemas en la arquitectura, en los requisitos funcionales.

La calidad del software se puede evaluar y controlar durante el proceso de desarrollo del
software para asegurar que vamos a obtener un producto de calidad y no llevarnos
sorpresas:
Aseguramiento de la Calidad Software (SQA, Software Quality Assurance)
El aseguramiento de la calidad se planifica
antes de empezar a desarrollar un producto
software.
Las actividades comprendidas dentro del
aseguramiento de la calidad software se aplican
durante todo el proceso de desarrollo.
El aseguramiento de la calidad software
aumenta la calidad del proceso de desarrollo y
disminuye los riesgos.

Algunas de las actividades que están involucradas con el Aseguramiento de la Calidad Software:
Revisiones Técnicas Formales (RTF) en todos los pasos de desarrollo de software.
Control de la documentación
Control de los cambios.
Asegurar que se sigue la metodología
adoptada.
Definir mecanismos y técnicas de medida de la calidad.
Realizar auditorías y registrar la
información mediante informes.
¿Qué debemos hacer para elaborar y seguir un
eficaz Aseguramiento de la Calidad Software?
Primero la planificación del plan de
aseguramiento de la calidad.
Descripción del sistema.
Estimación de los objetivos y requisitos del
sistema
Gestión de los riesgos elaboración plan
contingencia.
Diagrama de Gantt.
Definir qué características de calidad se van a
tener en cuenta a la hora de evaluar la calidad
del producto.
Elegir las herramientas necesarias.
Cuando el plan está hecho se lleva a cabo
durante el desarrollo del sistema.
Tamaño del Software
La métrica orientada al tamaño, es para saber en que tiempo voy a
terminar el software y cuantas personas voy a necesitar. Son medidas directas al software y el proceso por el cual se desarrolla.
se obtiene considerando las medidas de productividad y normalizándolas por l tamaño de código s decir las LINEAS DE CODIGOS (LDC)
se basan en la utilización de registros sencillos para las medidas mas relevantes para nuestro proyecto.
Hay autores que sugieren cuatro enfoques diferentes del problema del tamaño:
Existen autores que sugieren cuatro enfoques diferentes del problema del tamaño:
Tamaño en Lógica Difusa
Este enfoque utiliza las técnicas
aproximadas de razonamiento que son la
piedra angular de la lógica difusa.
Para aplicar este enfoque,el planificado debe identificar el tipo de aplicación, establece su magnitud en una escala cuantitativa y
refinar la magnitud dentro del rango
original.
Tamaño en Punto de Función
El planificador desarrolla
estimaciones de
características del dominio
de información.
Tamaño de Componentes Estándar
El software se compone de un número de
«componentes estándar » que son genéricos para un área en particular de la aplicación.
Por ejemplo,subsistemas, módulos, pantallas,
informes, programas interactivos. El planificador de
proyectos estima el número de incidencias de cada
uno de los componentes estándar, y utiliza datos de proyectos históricos para determinar el tamaño de
entrega por componente estándar.
Tamaño del cambio
Este enfoque se utiliza cuando un proyecto
comprende la utilización de software
existente que se debe modificar de alguna manera como parte de un proyecto.
El planificador estima el número y tipo
(por ejemplo: reutilización, añadir código
cambiar código, suprimir código)

De los resultados de cada uno de los
métodos de tamaño señalados
anteriormente se combinan
estadísticamente para crear una
estimación de tres puntos o del
valor esperado. Esto se lleva a cabo desarrollando valores de tamaño
optimistas (bajos), y más probables, y pesimistas (altos).

VENTAJAS
Son fáciles de calcular
Muchos modelos de estimación de software usan LOC (lines of code) O KLOC (miles de lineas de códigos se usan en programas grandes) como datos de entrada.
Existe un amplio conjunto de materiales basados en LOC.
DESVENTAJAS
Son dependientes del lenguaje de programación.
Perjudica a los programas cortos pero bien diseñados.
Su uso de estimación es difícil, porque hay que estimar las LOC a producirse ucho antes de que se complete l analis y el diseño.
TIPOS DE METRICAS
DEL PRODUCTO
Tamaño
Estructura de datos
Logicas
Del Proceso
Tiempo de desarrollo
Reusabilidad
Productividad
Metricas del software
Métricas de Tamaño
Métricas de estructuras de control
Métricas compuestas
Métricas de esfuerzos
Métricas de calidad y fiabilidad
Métricas de diseños
Otras métricas orientadas del software.
Incluye tres sub modelos, cada uno ofrece un nivel de detalle y aproximación, cada vez mayor, a medida que avanza el proceso de desarrollo del software:
Básico: se usa para obtener una aproximación rápida del esfuerzo.
Intermedio: añade al modelo básico 15 factores de ajuste de coste, la formula es la misma, pero con el añadido del factor multiplicando. Así logramos mayor precisión.
Detallado:Presenta principalmente dos mejoras respecto al anterior.
Los factores correspondientes a los atributos son sensibles o dependientes de la fase sobre la que se realizan las estimaciones.
Establece una jerarquía de tres niveles de productos.

Inconvenientes
Los resultados no son proporcionales a las tareas de gestión ya que no tiene en cuenta los recursos necesarios para realizarlas.
Se puede desviar de la realidad si se indica mal el porcentaje de líneas de comentarios en el código fuente.
Es un tanto subjetivo, puesto que está basado en estimaciones y parámetros que pueden ser "vistos" de distinta manera por distintos analistas que usen el método.
Se miden los costes del producto, de acuerdo a su tamaño y otras características, pero no la productividad.
La medición por líneas de código no es válida para orientación a objetos.
Utilizar este modelo puede resultar un poco complicado, en comparación con otros métodos (que también sólo estiman).
Modos:
Representan el tipo de
proyecto, que puede ser
Modo orgánico: un pequeño grupo de
programadores experimentados desarrollan
software en un entorno familiar. El tamaño de software varía desde unos pocos miles de línea (tamaño pequeño) a unas decenas de miles
(medio).
Modo semi libre o semi encajado:corresponde a un esquema intermedio entre el orgánico y el rígido; el grupo de desarrollo puede incluir una mezcla de personas experimentadas y no experimentadas.
Modo rígido o empotrado: el proyecto tiene
fuertes restricciones, que pueden estar
relacionadas con la funcionalidad y/o pueden ser técnicas. El problema a resolver es único y es difícil basarse en la experiencia, puesto que puede no haberla.
Desarrollar un software de no muy elevada dificultad con las siguientes restricciones:
3 meses para el desarrollo del proyecto.
Debe estar implementado en el lenguaje Visual Basic.
Full transcript