ClubEnsayos.com - Ensayos de Calidad, Tareas y Monografias
Buscar

Proyecto Final de Mantención de Software

Francisco ArmijoApuntes1 de Abril de 2016

5.413 Palabras (22 Páginas)418 Visitas

Página 1 de 22

Proyecto Final de Mantención de Software


Introducción:

El siguiente informe detallara  un sistema de información para compras y abastecimiento. Cuyo estudio previo entrego una lista de requerimientos funcionales y no funcionales.

Nuestro equipo desarrollara en base a los distintos estándares  satisfaciendo los requerimientos del cliente logrando así cumplir con sus expectativas.

También se presentara un contrato de Outsourcing, para dejar estipulado los servicios y condiciones  que significara la  mantención futura por parte de nuestro equipo al sistema ya mencionado. Conjuntamente  se establecerá un Acuerdo de Nivel de Servicio (SLA) para proporcionar un ambiente claro de lo que nuestra empresa ofrecerá.


Análisis de Impacto

“Sistema de información para compras y abastecimiento”

 1.1Definición de alcance:

Se deseas desarrollar un sistema de información que tiene como principal objetivo controlar el proceso de solicitud de compra y abastecimiento de la empresa.

La aplicación deberá contemplar un nivel de privilegios jerárquicos, así un usuario de nivel, superior siempre podrá acceder a la información de los niveles inferiores.

También deberá mantener cuentas de usuario para los privilegios de las distintas opciones del sistema.

1.2Requisitos funcionales:

*Controlar las etapas de solicitud  de compra y abastecimiento.

*Solicitud de insumos

*Se envía al departamento de compra, se decide si se efectúa o no la compra.

*Se abastece con lo que hay en la bodega, sino se busca mejor precio con los distintos proveedores.

* Se genera una solicitud de compra al proveedor.

*Se genera la orden de compra.

*Trascurre el tiempo de espera por el o los productos.

*Llega el o los productos solicitados.

1.2El sistema llevara un registro de:

*Stock disponible

*Número de inventario.

*Unidad de medida.

*Costo.

*Fecha última compra.

*Ultimo proveedor.

*Stock  crítico.

*Proveedores posibles.

*Volumen mínimo a comprar.

*Familia.

*Grupo.

*Fecha de vencimiento del producto.

*Marca del producto.

2 El Sistema proveerá elementos que permitirán:

a-Registrar las solicitudes de los o el producto.

b-Registrar las solicitudes canceladas.

c-Registrar los productos despachados.

d-Registrar los despachos cancelados.

e-Emitir informes agrupados por familia.

f-Emitir informes agrupados por compra.

g-Emitir informes agrupados por grupo.

h-Emitir informes agrupados por despacho.

i-Emitir informes agrupados por artículos con stock crítico.

j-Emitir informes agrupados por precio.

k-Emitir informes agrupados por proveedores.

l-Emitir informes agrupados por marca.

m-Emitir una orden de compra automática para aquellos productos con stock mínimo o por vencer (en ciertos tipos de productos).

n-Emitir Informe que compare niveles de compra y consumo de artículos, el periodo queda definido por el usuario.

ñ-Emitir informe de diferencias mensuales acumuladas entre comprado, solicitado y entregado a despacho.

2.1Lista los artículos ordenados por inventario.

I-Informe de compra realizada por proveedor.

II-Informe vencimiento de artículos.

III-Informe de cambio por proveedor.

IV-Informe de despachos atrasados por proveedor.

V-Informe de solicitudes rechazadas.

VI-Informe de despacho cancelado.

VII-Informe de despacho realizado.

VIII-Informe de solicitudes.

3 Sistema registrara hoja de vida por proveedor:

a. Artículos comprados.

b. Descuentos.

c. Monto compra.

d. Tiempo de despacho.

e. Cantidad producto.

f. Solvencia (en cuanto a los pagos).

g. Cambios por proveedor.

h. Registro de despachos atrasados.

4. Privilegio jerárquico a lo que respecta a:

- Vistas y manejo de información según el nivel de usuario (administrador, usuario básico).

-Creación de perfiles de usuario.

-modificación de datos y archivos, eliminación  y otorgación de privilegios a usuarios de niveles más bajos.

5. Requisitos no funcionales:

  1. El proyecto no debe durar más de 3 meses.
  2. El sistema debe ser capaz de atender al menos 7 peticiones al mismo tiempo.
  3. El sistema debe estar operativo las 24 horas del día los 7 días de la semana.
  4. Requerimientos técnicos:

  1. El sistema deberá estar construido en ASP, con elementos JavaScript y HTML.
  2. La base de datos será MS SQL Server 6.5 o 7.0.
  3. Sistema Operativo soportado será Windows NT 4.x o Windows 2000.

6. Estimación de Esfuerzo  horas Hombres.

Actividad

Duración(Días)

Roles

Análisis

20

1JP (30%)+ 1AS (100%)

Diseño

15

1JP (20%)+ 1DI (100%)

Construir

25

1JP (10%)+ 1AS (25%)+

3PG (100%)

Pruebas

5

1JP (35%) +1AT (100%) +

1IS (50%) +1AT (15%) +

1AS (10%)

Implementation

5

1JP (25%) +1IS (100%)

*Jefe de proyecto =JP. *Analista de Sistema =AS. *Diseñador=Di. *Programador=PG.

*Analista de Testing= AT. *Ingeniero de Sistema=IS.

Cargo

Análisis

Diseño

Construcción

Prueba

Implementación

Total

Jefe de Proyecto(JP)

48

24

20

14

10

116

Analista de Sistema (AS)

160

---------

25

4

---------

189

Diseñador(DI)

-------

120

------

---------

----------

120

Programador(PG)

------

-----

600

6

-----

606

Analista de Testing(AT)

-------

--------

---------

40

--------

40

Ingenieros de Sistema(IS)

------

---------

---------

10

40

50

Total

208

144

645

74

50

1121

Rol

Horas Hombre

Jefe De Proyecto

116

Analista de Sistema

189

Diseñador

120

Programador

606

Analista de Testing

40

Ingeniero de Sistema

50

Total

1121 H.H

7. Análisis Costo Beneficio

    Costos Basados en esfuerzo estimado.

Cargos

H.H

Pesos cada H.H

Costo Persona

Jefe de Proyecto

116

17.940

2.081.040

Analista de Sistema

189

12.814

2.421.846

Diseñador

120

10.251

1.230.120

Programador

606

7.689

4.659.534

Analista de Testig

40

12.814

512.560

Ingeniero en Sistema

50

15.378

768.900

Total

1121

……………………….

11.647.000

8. Plan de Pruebas

Definición de Pruebas:

En la aplicación desarrollada un error generado dentro del sistema podría ser nefasto, por lo cual se debe poner aprueba el sistema a todas las posibles fallas.

Para ello se ha realizado casos de prueba de caja negra, en donde, se prueban las funcionalidad-des sin atender su contenido (código fuente).

Estas pruebas permiten obtener un conjunto de condiciones de entrada que ejerciten todos los requisitos funcionales del programa.  Para preparar los casos de prueba hacen falta un numero de datos que ayuden a la ejecución de los casos y que permitan que el sistema se ejecute en todas sus variantes, pudiendo ser datos validos e inválidos, para el programa según si lo que se desea es hallar un error o probar una funcionalidad.

...

Descargar como (para miembros actualizados) txt (38 Kb) pdf (388 Kb) docx (45 Kb)
Leer 21 páginas más »
Disponible sólo en Clubensayos.com