METRICAS DE PUNTO FUNCION

PROBLEMA

Al hacer la compra de cualquier producto tecnolgico de la empresa el cliente no sabe si tiene el

producto que desea y la cantidad que quiere tambin existe el problema si el cliente compra el
producto y despus de un determinado tiempo quiere devolver el producto por razones X.

1.0. REQUISITOA DE FUNCION (RF)

1: El proceso de registro de un producto tecnolgico dura un tiempo menor o igual a 2 min

tambin se registran los dados del cliente.

Justificacin.- Para almacenar su informacin en la base de datos para su facturacin y futuras

compras.

2: Hacer una consulta en la base de datos para verificar el stock disponible de los productos de la
empresa y saber si se puede satisfacer la cantidad de artculos que desea el cliente.

Justificacin.- no se puede hacer un inventario diario por el simple hecho que no se realiza la
importacin a diario.

1.1. REQUISITOS NO FUNCIONALES (RNF)

- El gestor de base de datos ser SQL SERVER
- La institucin no adquiere la licencia respectiva
- Respeto al hardware se implementara en los equipo de la empresa

2.0. RECOGIDA DE INFORMACION

2.1. ACTIVIDAD 1
METODO PARA VERIFICACION DE INVENTARIO
MATERIA: INVESTIGACIN DE OPERACIONES II Q = Cantidad optima a pedir Im =
Inventario Mximo t = Periodo entre pedidos T = Periodo de Planeacin En este
modelo se representan iguales el inventario mximo y la cantidad econmica pedida.
Cabe mencionar que esto no siempre es verdadero. El costo total para un periodo en
este modelo est conformado por tres componentes de costo: Costo unitario del
producto (C1)Costo de ordenar una compra (C2)Costo de mantener un producto en
almacn (C3)El costo para un periodo estar conformado de la siguiente manera:
Costo por periodo = [Costo unitario por periodo] + [Costo de ordenar un pedido]
+[Costo de mantener el inventario en un periodo]El costo total para el periodo de
planeacin estar conformado de la manera siguiente: Costo total = Costo por periodo
x Numero de pedidos a realizar ANLISIS DE ECUACIONES. Costo unitario por periodo.
El costo unitario por periodo simplemente es el costo de la cantidad ptima a pedir.C1
Q Costo de ordenar una compra. Puesto que solo se realiza una compra en un periodo
el costo de ordenar una compra est definido por: C2
MATERIA: INVESTIGACIN DE OPERACIONES II
EJEMPLO: Una empresa vende un artculo que tiene una demanda de 18, 000 unidades
por ao, su costo de almacenamiento por unidad es de $ 1.20 por ao y el costo de
 ordenar una compra es de $ 400.00. El costo unitario del artculo es $ 1.00. No se
permite faltante de unidades y su tasa de reemplazo es instantnea. Determinar: La
cantidad optima pedida El costo total por ao El nmero de pedidos por ao El tiempo
entre pedidos DatosC1= $ 1.00 (Costo unitario del artculo)C2 = $ 400.00 (Compra)C3 =
$ 1.20 (Costo de almacenamiento por unidad por ao)La cantidad ptima a pedir se
calcula de la siguiente forma.= 3 465 Unidades El costo total estar determinado por:
Costo = [(1) (18000)] + [(400) (18000/3465)] + [(1.2) (3465/2)] = $ 22, 156 por ao El
nmero de pedidos por ao es N = D / Q = 18 000 / 3465 = 5.2 Pedidos por ao El
tiempo entre pedidos est = Q / D = 3465 / 18000 = 0.1925 aos

2.2. ACTIVIDAD 2
Mtodos de clculo para el pronstico de ventas:
Existen muchos mtodos para calcular el pronstico de ventas, nosotros utilizaremos
el mtodo estadstico y matemtico (mnimos cuadrados).
Mnimos cuadrados.- el mtodo mnimos cuadrados es el mtodo que sirve para
proyectar las ventas de futuros periodos con base a ventas de gestiones pasadas como
cualquier otro mtodo de mnimos cuadrados debe ser ajustado en caso de que
existan factores que cambien las condiciones y situaciones tanto econmicas, polticas,
de mercado, de capacidad, tanto externas como internas,
Aplicando el mtodo de mnimos cuadrados se ajusta la recta
= +
Donde

=
2 ( )2

=

2.3. ACTIVIDAD 3
2.4. ACTIVIDAD 4
Metodologa XP (Programacin Extrema)
2.4.1. Planificacin

La metodologa XP plantea la planificacin como un dialogo continuo entre las

partes involucradas en el proyecto, incluyendo al cliente, a los programadores y a
los coordinadores o gerentes. El proyecto comienza recopilando Historias de
usuarios, las que sustituyen a los tradicionales casos de uso. Una vez obtenidas
las historias de usuarios, los programadores evalan rpidamente el tiempo de
desarrollo de cada una. Si alguna de ellas tiene riesgos que no permiten
establecer con certeza la complejidad del desarrollo, se realizan pequeos
programas de prueba (spikes), para reducir estos riesgos. Una vez realizadas
estas estimaciones, se organiza una reunin de planificacin, con los diversos
actores del proyecto (cliente, desarrolladores, gerentes), a los efectos de
establecer un plan o cronograma de entregas (Release Plan) en los que todos
estn de acuerdo. Una vez acordado este cronograma, comienza una fase de
 iteraciones, en dnde en cada una de ellas se desarrolla, prueba e instala unas
pocas historias de usuarios.

IMPLEMENTACION DE HISTORIAS DE USUARIO

21-abr-15
AGENDA VIRTUAL DE LA UNIDAD EDUCATIVA NUESTRA SEORA DE LA PAZ
Historia de Usuario
Numero: Usuario:
1 Estudiante
nombre de historia:

registro de estudiante (usuarios de la aplicacin web)

prioridad de negocio: riesgo en desarrollo

Alta Baja
puntos estimados: iteracin asignada:
1
programador disponible:
Milton Ismael Vsquez jaliri

Descripcin:

Para registrar los datos de los estudiantes, en la aplicacin web se ingresara

Datos de estudiante
Notas del estudiante
Datos de la materia

Una vez obtenidas estos datos, utilizamos los mtodo POST para enviar datos al servidor web
por medio de nuestro WebService creado en PHP

Se observa que el WebService Fue creado como un inmediato entre el cliente y el servidor,
por cuestiones de seguridad de informacin

El servidor cuando recibe los datos de los estudiante es insertado a la base de datos del
estudiante

Observaciones
 IMPLEMENTACION DE HISTORIAS DE USUARIO

21-abr-15
AGENDA VIRTUAL DE LA UNIDAD EDUCATIVA NUESTRA SEORA DE LA PAZ
Historia de Usuario
Numero: Usuario:
1 Presidente de junta de padres de familia
nombre de historia:

registro de padres de familia (junta de padres de familia) (usuarios de la aplicacin web)

prioridad de negocio: riesgo en desarrollo

Alta Baja
puntos estimados: iteracin asignada:
1
programador disponible:
Erland Faustino Herrera Prieto

Descripcin:

Para registrar los datos de la junta de padres de familia, en la aplicacin web se ingresara

Las actividades curriculares (bailes, paseos, salidas, etc.)

EL envi de actividades curriculares y extra curriculares (ferias, tcnica
. vocacional, etc.)
Registro de padres de familia (directiva de padres de familia)

Una vez obtenidas estos datos, utilizamos los mtodo POST para enviar datos al servidor web
por medio de nuestro WebService creado en PHP

Se observa que el WebService Fue creado como un inmediato entre el cliente y el servidor,
por cuestiones de seguridad de informacin

El servidor cuando recibe los datos de los estudiante es insertado a la base de datos del
estudiante

Observaciones
 IMPLEMENTACION DE HISTORIAS DE USUARIO

21-abr-15
AGENDA VIRTUAL DE LA UNIDAD EDUCATIVA NUESTRA SEORA DE LA PAZ
Historia de Usuario
Numero: Usuario:
1 Docente
nombre de historia:

registro de Docentes (usuarios de la aplicacin web)

prioridad de negocio: riesgo en desarrollo

Alta Baja
puntos estimados: iteracin asignada:
1
programador disponible:
Miguel Arturo Colque flores

Descripcin:

Para registrar los datos de los estudiantes, en la aplicacin web se ingresara

Datos del docente

datos de los planes bimestrales acadmicos
datos de los estudios realizados

Una vez obtenidas estos datos, utilizamos los mtodo POST para enviar datos al servidor web
por medio de nuestro WebService creado en PHP

Se observa que el WebService Fue creado como un inmediato entre el cliente y el servidor,
por cuestiones de seguridad de informacin

El servidor cuando recibe los datos de los estudiante es insertado a la base de datos del
docente

Observaciones

2.4.2. ANALISIS

Es la fase en la que se define el alcance general del proyecto. En esta fase, el

cliente define lo que necesita mediante la redaccin de sencillas historias de
usuarios. Los programadores estiman los tiempos de desarrollo en base a esta
informacin. Debe quedar claro que las estimaciones realizadas en esta fase son
primarias (ya que estarn basadas en datos de muy alto nivel), y podran variar
cuando se analicen ms en detalle en cada iteracin. Esta fase dura tpicamente un
par de semanas, y el resultado es una visin general del sistema, y un plazo total
estimado.

2.4.3. DISEO

La metodologa XP hace especial nfasis en los diseos simples y claros. Los

conceptos ms importantes de diseo en esta metodologa son los siguientes:
Simplicidad

Un diseo simple se implementa ms rpidamente que uno complejo. Por ello XP

propone implementar el diseo ms simple posible que funcione. Se sugiere nunca
adelantar la implementacin de funcionalidades que no correspondan a la
iteracin en la que se est trabajando.

Soluciones spike

Cuando aparecen problemas tcnicos, o cuando es difcil de estimar el tiempo para

implementar una historia de usuario, pueden utilizarse pequeos programas de 1
prueba (llamados spike), para explorar diferentes soluciones. Estos programas
son nicamente para probar o evaluar una solucin, y suelen ser desechados luego
de su evaluacin.

Recodificacin

La recodificacin (refactoring) consiste en escribir nuevamente parte del cdigo

de un programa, sin cambiar su funcionalidad, a los efectos de hacerlo ms simple,
conciso y/o entendible. Muchas veces, al terminar de escribir un cdigo de
programa, pensamos que, si lo comenzramos de nuevo, lo hubiramos hecho en
forma diferente, mas clara y eficientemente. Sin embargo, como ya est pronto y
funciona, rara vez es reescrito. Las metodologas de XP sugieren recodificar cada
vez que sea necesario. Si bien, puede parecer una prdida de tiempo innecesaria
en el plazo inmediato, los resultados de sta prctica tienen sus frutos en las
siguientes iteraciones, cuando sea necesario ampliar o cambiar la funcionalidad. La
filosofa que se persigue es, como ya se mencion, tratar de mantener el cdigo
ms simple posible que implemente la funcionalidad deseada.

Metforas

Una metfora es algo que todos entienden, sin necesidad de mayores

explicaciones. La metodologa XP sugiere utilizar este concepto como una manera
sencilla de explicar el propsito del proyecto, y guiar la estructura y arquitectura
del mismo. Por ejemplo, puede ser una gua para la nomenclatura de los mtodos
y las clases utilizadas en el diseo del cdigo. Tener nombres claros, que no
requieran de mayores explicaciones, redunda en un ahorro de tiempo. Es muy
importante que el cliente y el grupo de desarrolladores estn de acuerdo y
compartan esta metfora, para que puedan dialogar en un mismo idioma. Una
buena metfora debe ser fcil de comprender para el cliente y a su vez debe tener
suficiente contenido como para que sirva de gua a la arquitectura del proyecto.
Sin embargo, sta prctica resulta, muchas veces, difcil de realizar. En un trabajo
realizado en el School of Computer Science del Carnegie Mellon, se cuestiona la
utilidad de su uso.

2.4.4. IMPLEMENTACION

Implementacin del software.-

Primero se realizara un proceso de prueba a la empresa para la bsqueda de

errores del sistema que puedan existir, con base en los errores se proceder a su
correccin y la adecuada implementacin del sistema.

Lenguaje.-

Se utilizar el lenguaje SQL Server para el desarrollo del sistema

Capacitacin.-
 Se brindar capacitacin a todo el personal que la empresa decida lo necesite para
el uso adecuado del sistema.

Mantenimiento.-

Se brindar el mantenimiento semestral con base al contrato establecido.

3.0. CALULO DEL FACTOR DE AJUSTE (VAF)

CARACTERISTICA DESCRIPCIN PESO
1. Comunicacin de Se realizar un sistema de consulta simple para las 5
datos llamadas al sistema, basndose en el nmero de tablas
relacionadas
2. Procesamiento Se llevar los datos a variables lgicas para el manejo de los 5
distribuido de datos en cualquier proceso de .NET
datos
3. Rendimiento Se utilizar un software que dar variables aleatorias a la 4
base de datos y as se conocer la velocidad del sistema, se
espera que la respuesta sea menor a 1 segundo
4. Configuraciones El servidor y su respaldo, estarn activos a todo momento, 5
fuertemente realizando backup cada final de da laboral.
utilizadas
5. Frecuencias de Diariamente. 3
transacciones
6. Entrada de datos Se ingresar la informacin de los costos e informacin de 3
OnLine los producto, basndose en 30% de entrada de datos a
travs del medio OnLine
7. Eficiencia de Se har aplicaciones mviles para la consulta de los clientes 2
usuario final y tambin contar con servicios web.
8. Actualizaciones No se realizan transacciones OnLine, ya que todo el servicio 0
OnLine es para visualizacin de productos de la empresa y sus
caractersticas.
9. Procesamiento Si, se utilizarn mtodos operativos para inventarios, 3
complejo adems de clculos estadsticos de muestreo para la
distribucin y adquisicin de los productos
10. Reusabilidad La aplicacin cubrir las dudas bsicas de los usuarios sobre 2
los productos
11. Facilidad de Utilizar una instalacin tpica y simple con la opcin de 1
instalacin personalizar si as se desea, usando pocas ventanas para
minimizar el tiempo y la dificultad al momento de la
instalacin.
12. Facilidad de Se utilizar la funcin de autoguardado para evitar perdidas 5
operacin de informacin, en caso de que el cliente lo requiera estar
disponible el servicio de restore ubicado en la memoria
cache, el proceso de inicio est estimado en durar 5
segundos aproximadamente y el proceso de detencin est
estimado en 10 segundos
13. Instalacin en El sistema tendr una distribucin estndar para funcionar 3
distintos lugares con cualquier tipo de navegador adems de contar con una
 versin mvil para ajustarse a los tamaos de pantalla.
El sistema solo estar basados para sistemas Windows y
LINUX.
14. Facilidad de La aplicacin tendr la disponibilidad para efectuar 4
cambio cambios y modificaciones sobre s misma.

CGS = 45

4.0. INVENTARIADO DE TRANSACCIONES LOGICAS Y FICHEROS LOGICOS

IMPORTACION Y VENTA DE
MATERIAL TECNOLOGICO

IDENTIFICACION VENTA INVENTARIO PRODUCTO PROVEEDOR IMPORTACIN

CLIENTE

ENTRADAS EXTERNAS: Identificacin cliente, Importacin, Proveedor.

SALIDAS EXTERNAS: Productos, Venta, Inventario.
CONSULTAS EXTERNAS: Datos del cliente, Productos.
FICHEROS LOGICOS INTERNOS: Las tablas relacionas con el cliente.
FICHEROS EXTERNOS DE INTERSFAZ: Las tablas relacionadas de facturacin y proveedor.

3+3+2+1+2 = 11

5.0. CLASIFICACIN DE COMPONENTES

ENTRADAS EXTERNAS:
Identificacin de cliente, 5 ficheros, complejidad alta.
Importacin, 4 ficheros, complejidad media.
Proveedor, 5 ficheros, complejidad alta.
SALIDAS EXTERNAS:
Productos, 4 ficheros, complejidad media.
Venta, 6 ficheros, complejidad alta.
Inventario, 5 ficheros, complejidad alta.
CONSULTAS EXTERNAS:
Datos del cliente, 5 ficheros.
Productos, 4 ficheros.
FICHEROS LOGICOS INTERNOS Y FICHEROS LOGICOS DE INTERFAZ.
Considerados de prioridad alta >50

FACTOR DE PONDERACIN