Ao de la Diversificacin Productiva y del Fortalecimiento de la Educacin

CURSO:

Ingeniera OPERATIVA II

ALUMNO:

Balden Rojas Jeyson

CARRERA:

Ingeniera De Sistemas

Y computacin

CICLO:

VII

UPSB 2015

Trabajo de Investigacin:

METODO DEL

TRANSPORTE

DEDICATORIA

AGRADEZCO A DIOS,

A MIS PADRES Y SERES QUERIDOS

Por el apoyo constante

Y aliento permanente,

Por el sacrificio de

Ellos por brindarme

Las facilidades de

Realizarme como

Profesional.

AGRADECIMIENTO

Quiero expresar mi mayor gratitud a los profesionales que han facilitado el camino para la realizacin de este trabajo.

A la facultad de ingeniera, carrera acadmico profesional de ingeniera de sistemas de la UPSB Huaral, en particular a los docentes por haber impartido sus conocimientos, agradecer a mis compaeros de estudios que han contribuido todos los das en nuestro aprendizaje, a todos ellos mi ms profunda gratitud.

INTRODUCCIN

El presente trabajo est diseado de forma prctica y sencilla para comenzar a conocer un poco de este tema, METODO DEL TRANSPORTE, recorriendo los conceptos, objetivos, origen, supuestos, propiedades, casos prcticos, conclusiones y recomendaciones, dando una breve descripcin de cada punto ya planteado.

Al mismo tiempo la eleccin de un tema especifico para esta monografa permite conocer ms sobre los METODO DEL TRANSPORTE no solo su concepto, sino sus aplicaciones y principalmente la importancia que tiene dentro de la Ingeniera de Sistemas.

La motivacin del presente tema es poder conocer los diferentes tipos de METODO DEL TRANSPORTE que se dan en el ambiente y la rama de la ingeniera.

METODOS DEL TRANSPORTE

CONCEPTO:

El modelo de transporte busca determinar un plan de transporte de una mercanca de varias fuentes a varios destinos. Los datos del modelo son:

1. Nivel de oferta en cada fuente y la cantidad de demanda en cada destino.

2. El costo de transporte unitario de la mercanca a cada destino.

Como solo hay una mercanca un destino puede recibir su demanda de una o ms fuentes. El objetivo del modelo es el de determinar la cantidad que se enviar de cada fuente a cada destino, tal que se minimice el costo del transporte total.

La suposicin bsica del modelo es que el costo del transporte en una ruta es directamente proporcional al nmero de unidades transportadas. La definicin de unidad de transporte variar dependiendo de la mercanca que se transporte.

El Modelo de transporte es una clase especial de problema de Programacin Lineal. Trata la situacin en la cual se enva un bien de los puntos de origen (fbricas), a los puntos de destino (almacenes, bodegas, depsitos). El objetivo es determinar las cantidades a enviar desde cada punto de origen hasta cada punto de destino,que minimicen el costo total de envo, al mismo tiempo que satisfagan tanto los lmites de la oferta como los requerimientos de la demanda. El modelo supone que el costo de envo de una ruta determinada es directamente proporcional al nmero de unidades enviadas en esa ruta.

Sin embargo, algunas de sus aplicaciones importantes (como la Programacin de la Produccin) de hecho no tienen nada que ver con el transporte.

ORIGEN:

El origen del modelo de transporte data del ao de 1941 en el que F. L. Hitchcock present un estudio titulado "La distribucin de un producto desde diversos orgenes a numerosas localidades".- Se cree que esta investigacin fue la primera contribucin para la resolucin de los problemas de transporte.- En 1947, T. C. Koopmans present un estudio, sin ninguna relacin con el de Hitchcock, al que llamo "Utilizacin ptima del sistema de transporte".- Ambas aportaciones contribuyeron al desarrollo de los mtodos de transporte que implican un nmero dado de orgenes y otros de destinos.- Aunque no todos los procesos de distribucin pueden incluirse dentro del modelo general de la Programacin Lineal, hay dos clases de problemas de caractersticas bien definidas y afines que pueden ser formulados y tratados dentro del marco de las relaciones lineales: el problema de transporte y el problema de asignacin de recursos.

Con este cuadro se calculan los LDC:

Qu valores se ponen en esta tabla?

Se coloca en la columna de "Bsf/lnea" el precio de cada lnea en cada mdulo, esto generalmente se realiza basado en los costos de proyectos anteriores.La siguiente casilla pertenece a cuantas lneas se pueden escribir en un mes.

La casilla de "Coste", nos permite tener el clculo de cunto costara cada mdulo, esto se obtiene de multiplicar la columna de "Bsf. por lnea" con la de "Esperada".Los meses se calculan multiplicando las "Lneas al mes" por "Esperada"Al totalizarlas columnas calculadas tendramos en la columna de "Esperada" lacantidad de lneas que se escribiran, en la de "Coste" el costo estimado del proyecto yen la de "Meses" los meses que demorara el proyecto.

Ventajas y desventajas LDC

PUNTOS DE FUNCION

Punto funcin es un mtodo utilizado en ingeniera del software para medir el tamao del software. Fue definida por Allan Albrecht, de IBM, en 1979 y pretende medir la funcionalidad entregada al usuario independientemente de la tecnologa utilizada para la construccin y explotacin del software, y tambin ser til en cualquiera de las fases de vida del software, desde el diseo inicial hasta la implementacin y mantenimiento.

ELEMENTOS DE FUNCION

ENTRADAS (EI)

Un proceso elemental en lo que ciertos datos cruzan la frontera del sistema desde afuera hacia adentro.

Pantalla de entrada de datos

Lector de cdigo de barras

Lector de tarjetas magneticas y electrnicas

Captura de imgenes, voz, etc.

SALIDAS (EO)

Un proceso elemental con componentes de entrada y de salida mediante el cual datos simples y datos derivados (que se calculan a partir de otros datos) cruzan la frontera del sistema desde adentro hacia afuera. Adicionalmente, las Salidas Externas pueden actualizar un Archivo Lgico Interno

CONSULTAS (EQ)

Un proceso elemental con componentes de entrada y de salida donde un Actor del sistema rescata datos de uno o ms Archivos Lgicos Internos o Archivos de Interfaz Externos. Los datos de entrada no actualizan ni mantienen ningn archivo (lgico interno o de interfaz externo) y los datos de salida no contienen datos derivados (es decir, los datos de salida son bsicamente los mismos que se obtienen de los archivos). Dentro de ste tipo de transaccin entran los listados y las bsquedas de los sistemas.

FICHEROS LOGICOS O INTERNOS (ILF)

Grupo de datos relacionados lgicamente e identificables por el usuario, que residen enteramente dentro de los lmites del sistema y se mantienen a travs de las Entradas Externas.

FICHEROS DE INTERFAZ (EIF)

Grupo de datos relacionados lgicamente e identificables por el usuario, que se utilizan solamente para fines de referencia. Los datos residen enteramente fuera de los lmites del sistema y se mantienen por las Entradas Externas de otras aplicaciones.

Antecedentes

Tradicionalmente se ha medido el tamao del software mediante distintas mtricas: recuento de las lneas de cdigo, nmero de programas fuente, o tcnicas similares, que no resultan aceptables como una buena prctica profesional, porque:

Su resultado depende fuertemente del entorno tcnico y el lenguaje de programacin utilizado.

Vara en funcin de la pericia de cada programador y del uso de normas y metodologas.

No resultan significativas al usuario ni a la direccin.

Cuando se trata de establecer mtricas de productividad y calidad en la construccin de software, o realizar estimaciones de coste y duracin, es imprescindible disponer de una medida fiable y comprensible del tamao de lo que se construye.

Frontera de la Aplicacin

Define lo que es externo a la aplicacin

Interfaz entre lo interno y el mundo exterior

Se puede concebir como una membrana que atraviesan los datos procesados por las transacciones (EI, EO, EQ)

Encierra los archivos lgicos mantenidos por la aplicacin(ILF)

Asiste en la identificacin de los archivos lgicos referenciados pero no mantenidos por la aplicacin (EIF)

Depende de la visin del negocio y externa del usuario

Es independiente de consideraciones tcnicas o de implementacin

FACTORES DE COMPLEJIDAD

Comunicacin de datos: Cuntas facilidades de comunicacin hay disponibles para ayudar en el intercambio de informacin con la aplicacin o el sistema?

Procesamiento distribuido de datos: Cmo se manejan los datos y las funciones de procesamiento distribuido

Rendimiento: Existen requerimientos de velocidad o tiempo de respuesta?

Configuraciones fuertemente utilizadas: Cmo de intensivas se utilizan las plataformas hardware donde se ejecuta el sistema

Frecuencia de transacciones: Con qu frecuencia se ejecutan las transacciones? Diariamente, semanalmente.

Entrada de datos Online: Qu porcentaje de la informacin se ingresa on-line

Eficiencia del usuario final: Aplicacin diseada para maximizar la eficiencia del usuario final

Actualizaciones Online: Cuntos Archivos Lgicos Internos se actualizan por una transaccin on-line?

Procesamiento complejo: Hay procesamientos lgicos o matemticos intensivos en la aplicacin

Reusabilidad: La aplicacin se desarrolla para suplir una o muchas de las necesidades de los usuarios?

Facilidad de instalacin: Qu tan difcil es la instalacin y la conversin al nuevo sistema?

Facilidad de operacin: Cmo de efectivos y/o automatizados deben ser los procedimientos de arranque, parada, backup y restore

Instalacin en distintos lugares: La aplicacin fue concebida para su instalacin en mltiples sitios y organizaciones?

Facilidad de cambio: La aplicacin fue concebida para facilitar los cambios sobre la misma?

VENTAJAS DE LOS PUNTOS DE FUNCION:

Ofrece una idea del tamao de la funcionalidad y del presupuesto necesario.

Soporta la elaboracin de una planificacin realista.

Es objetivo y fcil de usar.

Soporta la comunicacin entre la administracin, los usuarios y los proveedores.

DESVENTAJAS DE LOS PUNTOS DE FUNCION:

La crtica principal que recibe esta mtrica es la de requerir una dedicacin adicional en los proyectos de desarrollo de software, que suelen desenvolverse con presupuestos ajustados.

Su implantacin en una organizacin no acostumbrada a su uso suele resultar penosa y requerir a un fuerte compromiso de la direccin. Suele ser vista por los desarrolladores como un mecanismo de control sobre su trabajo.

Resulta arduo formar al personal en su utilizacin y mas todava mantener unos criterios homogneos de recuento.

Carece de precisin cuando se trata de proyectos pequeos.

Por debajo de 100 PF resulta poco confiable.

COCOMO

ElModelo Constructivo de Costos, es unmodelomatemtico de base emprica utilizado para estimacin de costos1desoftware. Incluye tres submodelos, cada uno ofrece un nivel de detalle y aproximacin, cada vez mayor, a medida que avanza elproceso de desarrollo del software:bsico,intermedioydetallado.

Este modelo fue desarrollado porBarry W. Boehma finales de los aos 70 y comienzos de los 80, exponindolo detalladamente en su libro "Software Engineering Economics" (Prentice-Hall, 1981).

CARACTERISTICAS GENERALES

Pertenece a la categora de modelos de subestimaciones basados en estimaciones matemticas. Est orientado a la magnitud del producto final, midiendo el "tamao" del proyecto, en lneas de cdigo principalmente.

INCONVENIENTES

Los resultados no son proporcionales a las tareas de gestin ya que no tiene en cuenta los recursos necesarios para realizarlas.

Se puede desviar de la realidad si se indica mal el porcentaje de lneas de comentarios en el cdigo fuente.

Es un tanto subjetivo, puesto que est basado en estimaciones y parmetros que pueden ser "vistos" de distinta manera por distintos analistas que usen el mtodo.

Se miden los costes del producto, de acuerdo a su tamao y otras caractersticas, pero no la productividad.

La medicin por lneas de cdigo no es vlida para orientacin a objetos.

Utilizar este modelo puede resultar un poco complicado, en comparacin con otros mtodos (que tambin slo estiman).

MODELOS

El modelo COCOMO bsico es un modelo univariable esttico que calcula el esfuerzo (y el costo) del desarrollo de software en funcin del tamao del programa expresando en lneas de cdigo (LDC) estimadas.

El modelo COCOMO intermedio calcula el esfuerzo del desarrollo de software en funcin del tamao del programa y de un conjunto de conductores de costo, que incluyen la evaluacin subjetiva del producto, del hardware, del personal y de los atributos del proyecto.

El modelo COCOMO avanzado incorpora todas las caractersticas de la versin intermedia y lleva a cabo una evaluacin de impacto de los conductores de costo en cada fase (anlisis, diseo, etc.) del proceso de ingeniera de software.

Los modelos COCOMO estn definidos para tres tipos de proyecto de software.

Modelo Orgnico. Proyectos de software relativamente pequeos y sencillos en los que trabajan pequeos equipos, con buena experiencia en la aplicacin, sobre el conjunto de requisitos poco rgidos.

Modelo Semiacoplado. Proyectos de software intermedios (en tamao y complejidad) en los que los equipos, con variados niveles de experiencia, deben satisfacer requisitos poco o medio rgido.

Modelo Empotrado. Proyectos de software que deben ser desarrollados en un conjunto de hardware, software y restricciones operativas muy restringidas.

Las ecuaciones del modelo COCOMO bsico tienen la siguiente forma:

E = ab (KLDC) exp (bb)

D = cb (E) exp (db)

donde E es el esfuerzo aplicado en personas-mes, D es el tiempo de desarrollo en meses cronolgicos y KLDC es el nmero estimado de Lneas de Cdigo distribudas (en miles) para el proyecto. Las ecuaciones del modelo COCOMO intermedio toma la forma:

E = ai (KLDC) exp (bi) x FAE

donde E es el esfuerzo aplicado en personas-mes, KLDC es el nmero estimado de Lneas de Cdigo distribudas para el proyecto.

MODELOS DE ESTIMACION

La idea de los modelos de estimacin es la de proporcionar sistemas y mtodos generales para proceder a realizar la estimacin de costos en la construccin de software de aplicacin.

Los diferentes modelos de estimacin de costes y/o esfuerzos en la construccin de software se pueden dividir en cuatro grupos principales:

1. Modelos con base histrica.

2. Modelos con base estadstica.

3. Tericos.

4. Compuestos.

MODELOS CON BASE HISTORICA

Los modelos de base histrica son los ms antiguos y, en cierta manera, primitivos.

A menudo se basan en la analoga con otros proyectos parecidos y se fundamentan casi exclusivamente en la experiencia profesional (la historia) de los que efectan la estimacin.

MODELOS CON BASE ESTADSTICA

A partir del estudio estadstico de los datos reales disponibles tomados de un conjunto ms o menos numeroso de proyectos ya acabados, obtienen frmulas que relacionan las diferentes unidades de medida del software, a menudo las lneas de cdigo (LDC) y el esfuerzo (generalmente medido en hombre-mes).

MODELOS CON BASE TEORICAS

Estos modelos, ms que basarse en datos estadsticos disponibles, lo que hacen es partir de una serie de ideas generales sobre el proceso de construccin de software y, sobre esta teora, elaboran frmulas que relacionan diferentes mtricas de software.

MODELOS CON BASE COMPUESTOS

Estos modelos intentan obtener las ventajas de los dos sistemas anteriores: estadsticos y tericos. Es decir, se parte de una serie de planteamientos tericos y se complementan o corrigen con datos estadsticos obtenidos de proyectos reales ya acabados.

CONCLUSIONES

Se han desarrollado varias tcnicas de estimacin para el desarrollo de software como establecer de antemano el mbito del proyecto, usar las mtricas del software (mediciones del pasado) como base para la realizacin de estimaciones y desglosar el proyecto en partes ms pequeas que se estiman individualmente.

Esto ayuda al programador, ya que le permite dedicar ms tiempo a otras partes del proyecto.

Las medidas LDC y PF se utilizan a menudo para extraer mtricas de productividad.

En resumidas cuentas, estimar la carga de trabajo que es necesario llevar a cabo para la construccin de software de aplicacin es una tarea que normalmente fracasa.

Tambin, debe de tenerse en cuenta que mientras que LDC se estima directamente, PF se determina indirectamente mediante la estimacin del nmero de entradas, salidas, archivos de datos, peticiones e interfaces externas, entre otras.

BIBLIOGRAFIAS

http://catarina.udlap.mx/u_dl_a/tales/documentos/lis/gonzalez_d_h/capitulo5.pdf

http://arfduoc.blogspot.com/p/estimaciones-ldc-y-pf.html

http://html.rincondelvago.com/tecnicas-de-estimacion-de-costo-y-esfuerzo.html

http://www.inegi.org.mx/inegi/contenidos/espanol/prensa/Contenidos/Articulos/tecnologia/puntosxfuncion.pdf

https://prezi.com/hso9uz97ufwx/puntos-de-funcion-y-cocomo/

https://prezi.com/khx6q_cxwey1/tecnicas-de-estimacion-de-software/

http://es.wikipedia.org/wiki/COCOMO

INDICE

CARATULA1

PRESENTACION.2

DEDICATORIA.3

AGRADECIMIENTO..4

INTRODUCCION.5

CONCEPTO PRINCIPAL..6

LINEAS DE CODIGO..6

TECNICA..6

EN QUE CONSISTE6

FIGURA 1.6

VALORES.7

VENTAJAS Y DESVENTAJAS.7

PUNTOS DE FUNCION.8

ELEMENTOS DE FUNCION9

ANTECEDENTES.10

FACTORES DE COMPLEJIDAD..11

VENTAJAS Y DESVENTAJAS12

COCOMO13

CARACTERISTICAS13

INCONVENIENTES13

MODELOS.14

MODELOS DE ESTIMACION15

CONCLUSIONES..16

BIBLIOGRAGIAS..17