Arquitectura de Routers y Switches

Andrs Felipe Montoya Rosre.vu/AndresMontoya@montoya118

Edwar Andrs Ruiz Medina@EdwarRuiz324Estimacin de proyectos de software

Que es la estimacin? Estimacin Apreciar, poner precio, evaluar algo

Estimacin de proyectos de software Actividad de la planificacin del proyecto de sw que intenta determinar cunto dinero, esfuerzo, recursos y tiempo tomar construir un sistema o producto sw.

En qu consiste la estimacin de proyectos software?

Aplicacin continua de tcnicas basadas en las medidas de los procesos de desarrollo del software y sus productos, para producir una informacin de gestin significativa y a tiempo. Esta informacin se utilizar para mejorar esos procesos los productos que se obtienen de ellos (SYMONS, C., 1998).

Cul es el objetivo de la estimacin?

Predecir lasvariablesinvolucradas en el proyecto con cierto grado de certeza. Trata de aportar una prediccin de algn indicador importante para la gestin de proyectos de softwaretiempo, esfuerzo, cantidad de defectos esperados entre otros.Es razonable conocer, antes de comenzar a desarrollar el SW, cunto se va a invertir, qu tareas se deben realizar y cunto tiempo se necesitar.

Quin es y cul es el objetivo del estimador de un proyecto software?

El estimador debe ser un profesional que no tenga ningn inters, directo o indirecto, en los resultados del proceso de estimacin y que este nicamente guiado por su profesionalismo.

El principal objetivo del estimador es obtener estimaciones de calidad, las cuales no tienen siempre por qu coincidir con las expectativas de la empresa en trminos de costo y tiempo.

Requisitos que debe cumplir un buen estimador

Formacin y experiencia profesional adecuada.

Una posicin en la organizacin que le permita adoptar un juicio independiente.

Debe basarse en un mtodo que pueda ser explicado, cuestionado, discutido y auditado.

Debe poder describir su experiencia en cada estimacin.

Debe documentar su estimacin, incluyendo los resultados obtenidos y cualquier informacin necesaria para hacer el proceso de estimacin repetible y verificable.

Cundo se debe llevar a cabo?

La estimacin es un proceso continuo. A medida que el proyecto avanza, ms se conoce de l, y por lo tanto ms parmetros estn disponibles para introducir en un modelo de estimacin.La estimacin continua nos permite el uso de un nico modelo coherente que pueda capturar y utilizar la informacin sobre el proyecto a medida que ste se conozca.

El proceso de estimacin comienza usando unas pocas variables claves para proveer las macrocaractersticas de un proyecto, y evoluciona incorporando informacin de ms bajo nivel para producir las micro-caractersticas del proyecto.

Ejemplo con un MCVS en cascada

TCNICAS DE ESTIMACIN

Tcnicas de estimacin

La opinin de los expertos Esta tcnica se basa en la experiencia profesional de los Participantes en el proyecto de estimacin.La analoga Se basa en la comparacin directa de uno o ms proyectos pasados.Para poder utilizar esta tcnica es necesario disponer de una base de datos histrica de proyectos finalizados con la que poder realizar la comparacin.Los proyectos deben tener muchas similitudes en cuanto a su esquema.

Tcnicas de estimacinLa descomposicinConsiste en la descomposicin de un producto en componentes ms pequeos, o descomponer un proyecto en tareas de nivel inferior.La estimacin se hace a partir del esfuerzo requerido para producir los componentes ms pequeos o para realizar las tareas de nivel inferior.Las ecuaciones de estimacin: Son frmulas matemticas que establecen la relacin de algunas medidas de entrada (que normalmente es la medida del tamao del producto) y determinan el esfuerzo que se requerir.

MTODOS DE ESTIMACIN

Mtodo de puntos de casos de uso

mtodo de estimacin y clculo de tamao del software basado en cuentas hechas sobre los casos de uso para un sistema de software.

Cuantificacin de caractersticas funcionales del Sistema:Clasificacin de Actores, Clasificacin de los Casos de UsoObtencin del Peso oPuntos deCasos deUso

Cuantificacin de caractersticas no funcionales del Sistema:Clasificacin deFactores deComplejidadTcnica (FCT)Clasificacin deFactoresAmbientales (FA)Clculo dePuntos deCasos deUso Ajustados (PCU)

Clasificacin de Actores...

Todos los actores del sistema deben ser clasificados como Simple, Promedio y Complejo:

Actor Simple: Se trata de otro sistema interactuando a travs de una interfaz de programacin definida y conocida (API).Actor Promedio: Es otro sistema interactuando a travs de un protocolo (como TCP/IP).Actor Complejo: se trata de una persona interactuando con el sistema a travs de una interfaz grfica de usuario (GUI) o pgina Web.

Se cuentan los actores de acuerdo a su clasificacin o grado de complejidad, multiplicando cada subtotal por su factor de complejidad y sumando cada producto obtenindose el peso de los actores sin ajustar (PASA).

Clasificacin de Casos de Uso a partir de las Transacciones

Teniendo el modelo de casos de uso, cada uno de ellos debe clasificarse como Simple, Medio o Complejo, de acuerdo al nmero de transacciones descritas en el caso de uso. Se clasifican desacuerdo a lo siguiente:

Casos de Uso Simple: Tres o menos transacciones (o pasos).Casos de Uso Promedio: entre 4 o 7 Transacciones.Casos de Uso Complejos: Ms de 7 Transacciones.

Se cuentan los casos de uso de acuerdo a su clasificacin por numero de transacciones, multiplicando cada subtotal por su factor de complejidad y sumando cada producto obtenindose el peso de los actores sin ajustar (PTSA).

Obtencin de Factores de Peso oPuntos deCasos deUsoSinAjustar (PCUSA).

Es la suma del Peso de los Actores Sin ajustar ms el Peso de las Transacciones Sin Ajustar, es decir:

PCUSA = PASA + PTSA

Clasificacin de Factores de Complejidad Tcnica (FCT)

Son los factores de peso que incorporan la complejidad tcnica del sistema y algunas caractersticas no funcionales, el peso se representa de la siguiente manera: 0: Sin influencia3: Promedio5: Fuerte influencia

Para obtener el factor final se debe multiplicar cada item (T1 a T13) por el grado de influencia sobre el sistema y se obtiene la suma llamada FactorT, de acuerdo a la siguiente Frmula:FCT = 0.6 + (0.01*FactorT)

Clasificacin de Factores Ambientales (FA)

Corresponden en trminos generales, las caractersticas del equipo de desarrollo en cuanto a perfiles, experiencia y capacidad tcnica. Se clasifican de la siguiente manera

0: Sin influencia3: Promedio5: Fuerte influencia

Para obtener el factor final se debe multiplicar cada item (F1 a F8) por el grado de influencia sobre el sistema y se obtiene la suma llamada FactorA, de acuerdo a la siguiente Frmula:

FA = 1.4 + (-0.03*FactorA)

Clculo de Puntos de Casos de Uso Ajustados (PCU)

Finalmente, se obtiene la siguiente frmula que representa los puntos de casos de uso ajustados:

PCU = PCUSA*FCT*FA

MTODO DE ESTIMACIN COCOMO

Cuando un ingeniero est ante un proyecto a estimar, lo primero que debe hacer para aplicar el COCOMO es situar su proyecto en el espacio de dos dimensiones (modo, modelo).

Segn COCOMO existen tres modos de desarrollo, a cada uno de estos modos se le pueden aplicar tres mtodos de estimacin diferentes

Modo orgnico

El proyecto se desarrolla en equipos relativamente pequeosMuchas personas relacionadas con el proyecto tienen amplia experiencia trabajando en sistemas similares y tienen un buen conocimiento de cmo el sistema que se est desarrollando contribuir a los objetivos de la organizacin.Se desarrolla en un entorno generalmente estable, con muy pequea probabilidad de coincidencia en el desarrollo de un nuevo hardware u operaciones desconocidas.Proyectos de tamao relativamente pequeo. Como mximo 50 KDSI (miles de instrucciones).

Modo semilibre

El equipo del proyecto tiene un nivel medio de experiencia en proyectos similares.

El equipo es una combinacin de personal experto e inexperto.

El tamao del producto llega a las 300 KDSI.

Modo rgido

Proyectos que deben desarrollarse dentro de unas limitaciones muy estrictas.

El producto debe explotarse dentro de un entorno muy acoplado de hardware, software, normativa y procedimientos operativos

Estos proyectos se desarrollan en reas generalmente desconocidas, lo cual lleva inicialmente a equipos pequeos de analistas y, a una sobrecarga de comunicacin importante durante el desarrollo.

Se aplica a proyectos de cualquier tamao.

Modelo bsicoSe suele aplicar en los desarrollos de productos pequeos/medios Las ecuaciones de estimacin de esfuerzo y tiempo de desarrollo para cada modo de desarrollo:

Orgnico: MM = 2,4 (KDSI)1,05 TDEV = 2,5 (MM)0,38Semilibre: MM = 3,0 (KDSI)1,12 TDEV = 2,5 (MM)0,35Rgido: MM = 3,6 (KDSI)1,20 TDEV = 2,5 (MM)0,32

KDSI = nmero de instrucciones de cdigo en miles. MM = esfuerzo medido en meses/hombre. TDEV = duracin en meses

Modelo intermedioAtributos del producto software: RELY: Fiabilidad requerida del software DATA: Tamao de la base de datos.CPLX: Complejidad del producto.TIME: Limitaciones en el tiempo de ejecucinSTOR: Limitaciones de memoria principal.VIRT: Volatilidad de la mquina virtualTURN: Frecuencia de cambio en el modelo de explotacin del ordenador.

Atributos de personalACAP: Capacitacin de los analistasAEXP: Experiencia en aplicaciones.PCAP: Capacitacin de los programadoresVEXP: Experiencia en la mquina virtual.LEXP: Experiencia en el lenguaje de programacin.Atributos del proyectoMODP: Prcticas Modernas de programacin.TOOL: Uso de herramientas para el desarrollo de software.SCED: Limitaciones en la planificacin.

La estimacin de esfuerzo aplicando este modelo es:

Modo orgnico: MM = 3,2 (KDSI) 1,05

Modo semilibre: MM = 3,0 (KDSI) 1,12

Modo rgido: MM = 2,8 (KDSI) 1,20

Modelo detallado

Multiplicadores de esfuerzo por fases En el modelo COCOMO intermedio, la distribucin de esfuerzo por fase se determina nicamente por el tamao del producto. En la prctica, factores como la fiabilidad requerida, la experiencia en aplicaciones y desarrollos interactivos afectan a unas fases ms que a otras. El modelo detallado proporciona un conjunto de multiplicadores de esfuerzo para cada atributo en cada fase. Descomposicin Jerrquica del producto a tres niveles:Nivel mdulo.Nivel subsistema.Nivel sistema.

Modelo SLIM

Est basado en lacurva de Rayleigh, que describe la necesidad de personal al desarrollar proyectos complejos.Fue desarrollada para estimar los costes de los grandes proyectos de software. En proyectos pequeos hara falta ajustar la ecuacin.

T= Tamao en LDCC= factor dependiente del entorno ((vale 2.000 para entornos poco productivos, 8.000 para entornos buenos, 11.000 para entornos excelentes)K= Esfuerzos de personas ao Td= tiempo para completar el proyecto en aos.

Conclusiones!!!