MANUAL

TÉCNICO
1. INTRODUCCION

En ésta documentación, a través de varias reuniones y

gestiones que se realizaron en el entorno del problema, se
describe los requerimientos para satisfacer las necesidades de
cada uno de los procedimientos que se realizan en el Control
de Materiales un taller de Mecánica Automotriz de repuestos
usados de carro.
2. ESPECIFICACIÓN DE LOS REQUERIMIENTOS

En ésta documentación, a través de varias reuniones y

gestiones que se realizaron en el entorno del problema, se
describe los requerimientos para satisfacer las necesidades de
cada uno de los procedimientos que se realizan en el Control
de Materiales un taller de Mecánica Automotriz de repuestos
usados de carro.

2.1. ANÁLISIS DE LOS PROCESOS DE CONTROL DE

MATERIAL.

CONTROL DE DATOS:

De acuerdo a la gestión de requisitos realizadas en el entorno

del problema, en ésta actividad se desempeña por lo general
por el Maestro del local y está a cargo de registrar los datos
que intervienen en todas las actividades que se realiza en esta
área de venta de repuestos usados.

Registro de los clientes.

Registro de los Proveedores de Materiales.
Registro de los Materiales señalando la Marca.
Registro de los Materiales señalando la Categoría.
Registro de las diferentes Actividades:
Venta de materiales.
Compra de materiales.
RECEPCIÓN Y ENTREGA DE MATERIALES:

En esta actividad se desempeña por lo general el

administrador(a) de almacén quien se encarga de recibir y
llevar un control de productos que se ingresa a bodega, así
mismo debe realizar las gestiones de entrega de productos al
personal que labora en la imprenta:

Control de Ingreso de repuestos a Bodega

Control de Egresos de repuestos de Bodega.

REPORTES DE LOS PROCESOS DE CONTROL DE

MATERIAL:

Dentro de esta actividad mayormente está a cargo el Maestro y

debe realizar reportes:

Reporte de Ventas.
Reportes de Compras.
Existencias.
Lista de Clientes.
2.2. FASE DE ESPECIFICACIÓN.

Como hemos visto en el transcurso de la realización del

proyecto los requerimientos de Sistema pueden ser analizados
de diferentes formas, las técnicas de análisis pueden conducir a
una especificación en un papel que contenga las descripciones
gráficas y el lenguaje natural de los requerimientos de Sistema.

La especificación, independientemente del modo en que se

realice, puede ser vista como un proceso de representación, los
requerimientos se representan de forma que conduzcan a una
correcta implementación del Sistema.

2.2.1. ESTRATEGIA DE SOLUCIÓN.

El equipo de desarrollo como estrategia de solución debe

utilizar la programación Microsoft Visual Basic 6.0 por
cuestiones de coste – beneficio.

Analizados los puntos del proyecto se prosiguió a realizar el

prototipo del producto al cual lo llamaremos Sistema de
Factura de Repuestos Automotriz.
2.2.2. ANÁLISIS COSTE – BENEFICIO.

El análisis coste-beneficio señala los costes del desarrollo del

proyecto y los constata con los beneficios tangibles (medibles
directamente en dólares), e intangibles del sistema. Este
análisis es complicado porque los criterios varían según las
características del sistema a desarrollar, el tamaño relativo del
proyecto y la recuperación esperada de la inversión como
parte del plan estratégico de la Empresa. Además muchos
beneficios obtenidos de los sistemas basados en computadora
son tangibles. Puede ser difícil lograr comparaciones directas
cuantitativas. Como hemos dicho anteriormente en nuestro
Sistema vamos a tomar en cuenta la clasificación antes
mencionada.

FACTIBILIDAD:

Técnica.
Realización de un sistema informático en calidad de prototipo
conectado a una base de datos MYSQL en un servidor Linux
(Centos 4), con encriptación de clave y conexión inalámbrica,
para usarse bajo plataforma Windows XP; estas
especificaciones deben permitir que el sistema, sea confiable y
garantice la seguridad de los datos así como en su
manipulación, además sea de fácil manejo y mantenimiento, y
por supuesto utilizar tecnología de punta; el propósito de éste
prototipo es para definir y proyectar funcionalmente el
producto final.
Económica.
Beneficios Tangibles:
Integridad total de los datos, lo que garantiza una
confiabilidad absoluta en todos los procesos de control de
repuestos de carros en un taller, esto disminuye
considerablemente todos los gastos extra de revisión, y
reedición de todos los documentos que intervienen en los
procesos, como también en caso de errores en los documentos
y / o proceso o extravío de los documentos.
Se obtiene información de manera rápida, ya que la
automatización de los procesos que intervienen en el entorno
de las actividades de la empresa beneficiada, permite generar
la información existente de manera eficaz y rápida en función a
lo que se requiera.
Se optimiza las actividades, ya que el control eficaz y
rápido que brinda esta tecnología, por tanto se ganará mucho
tiempo y por ende se obtiene más ganancias.
Se debe adquirir una mejor imagen en la empresa
beneficiada, puesto que al trabajar con tecnología de punta, se
gana prestigio, competitividad y confiabilidad; lo que asegura
una mayor fluidez de trabajo y por consiguiente se satisface las
necesidades en mayor proporción a los clientes, por lo tanto
más ingresos económicos.
En todos los procedimientos se debe consumir mucho
menor tiempo, que con los métodos manuales actual,
realizando así mayor número de transacciones/ operaciones
por procesos.
Beneficios Intangibles:
Con la automatización de los procesos internos se
obtendrá un alto grado de satisfacción del cliente, ganando
así una imagen de confianza y seguridad.
La satisfacción del personal interno de la empresa
beneficiada, logrando un ambiente de trabajo más agradable,
por ende un mejor rendimiento.

Costo del Proyecto: $ 1.500

DETALLE COSTO $

EQUIPO (SW, HW, otros) 1.000,00

SFRA 500,00

TOTAL 1.500.00

Factibilidad Operacional.
Este cambio en la Empresa beneficiada debe tener buena
aceptación, ya que al optimizar sus procedimientos internos
la organización se desempeñará de manera eficaz, de forma
que cliente se siente seguro al obtener servicio de una
empresa que se mantenga actualizada, en conocimientos y
tecnología de punta, que brinde rapidez, y que demuestre
seguridad y eficiencia.
La capacitación del personal no deben ser un obstáculo,
ya que el sistema, al presentar un Interfaz gráfica deben ser
muy sencillo de utilizar y de adaptarse, por lo que no debe
requerir, mucho esfuerzo.
2.2.3. ANÁLISIS DE RIESGO:

Se estudian los riesgos, ya que estos implican una elección, y la

falta de certeza de que la elección sea la correcta, elecciones
como cuanta gente debe estar involucrada, que métodos debe
usar, el tiempo del proyecto, que herramientas usar, etc.
Al modificar nuestras acciones actuales creamos una
oportunidad para una situación diferente y mejor en el futuro.

IDENTIFICACIÓN DEL RIESGO.

RIESGOS DEL PROYECTO:

Falta de colaboración del usuario.
Indisponibilidad de HW.
Indisponibilidad de SW.
Indisponibilidad del Asesor.
Feriados, huelgas, etc.
RIESGOS TÉCNICOS:
Excesivo número de líneas de código.
No cumple con todos los requisitos del cliente.
La verificación arroja demasiados errores.
Manuales que dificultan el mantenimiento.
RIESGOS DEL NEGOCIO:
Sistema muy bien hecho pero que no satisfaga las
necesidades del cliente.
Proyecto demasiado costoso.
Pérdida de personal.
2.2.3. 1. ESTIMACIÓN DEL RIESGO:
Se trata al riesgo con un análisis probabilística así como sus
consecuencias y gestión.
Se evalúa con valores cualitativos como: Bastante improbable,
Improbable, Moderado, Poco Probable, Probable, Bastante
probable.

2.2.3.2. ESCALA DEL RIESGO.

ESCALA DE PROBABILIDAD DEL RIESGO.
2.2.3.3. LAS CONSECUENCIAS, Y GESTIÓN DE LOS
PROBLEMAS ASOCIADOS CON EL RIESGO.

CONSECUENCIAS DEL RIESGO.

2.2.4. MODELO ENTIDAD – RELACION.
2.3. DISEÑO APLICACIÓN SFRA.
2.3.1. DISEÑO ORIENTADOS A DATOS.

Ésta técnica se utilizó dentro de la fase de diseño para

desarrollar el SW, tomando en cuenta el flujo de datos que se
define de acuerdo al dominio de información encontrada en el
entorno del problema, ya que el enfoque de desarrollo se
orienta en una aplicación conectada a una Base de Datos.

2.3.2DISEÑO ARQUITECTÓNICO.

Basándonos en el documento de especificación y su diagrama

de entidad relación determinaremos las tablas para obtener un
listado de todos los registros y determinamos las relaciones de
control entre las tablas, para definir las interfaces que faciliten
el flujo de los datos.

2.3.2.1. DEFINICIÓN Y DISEÑO DE LOS

REGISTROS.

En vista de que se trata de una aplicación donde tendremos

que manejar gran cantidad de datos y además evitar la
redundancia de los mismos, y la integridad de los datos;
implica pensar rápidamente en la utilización de Bases de Datos
las mismas que deben tener un conjunto de tablas las que
contienen la información necesaria, garantizando el correcto y
rápido acceso a los datos de forma confiable.
2.3.2.2. DEFINICIÓN DE LOS REGISTROS.

Son definidos todos los registros tal y como se mostró

anteriormente en el diagrama entidad –relación.

2.3.2.3. DISEÑO DE LOS REGISTROS O BASE DE

DATOS.

La realización del diseño de las tablas para la Base de Datos

(BD), utilizaremos una herramienta Power Disenger Trial,
donde se establece y define las relaciones entre tablas,
recursividad y restricciones para la integridad de los datos,
implantado en un SGBD de MYSQL.

DISEÑO DETALLADO.

Del diseño arquitectónico obtenemos los módulos detallados

para lograr así tener una mejor visión de los módulos, para
lograr generar algoritmos que permiten ser interpretados con
facilidad.
2.3.2.4. ESTIMACIÓN DE LA BASE DE DATOS PARA
SFRA.

La estimación de la Base de datos es una tarea muy

importante, ya que debe permitir tener una estimación del
crecimiento de la base de datos, para de esa manera saber que
tipo de tablas serían convenientes utilizar para alguna
característica especial de la tabla, como puede ser la definición
de alguna, o incluso el espacio libre para cada tabla según sea
el crecimiento de cada una de ellas.

2.3.2.5. DISEÑO DE LA INTERFAZ DE LA

APLICACIÓN SFRA.

En el diseño de la interfaz consideraremos situaciones

importantes, en el sentido de que la Interfaz debe ser de uso
fácil para el usuario, dando facilidad en el desempeño del
usuario, etc. Razón por la cual utilizaremos las bondades que
da el Sistema operativo Windows, con toda la posibilidad de
utilizar y manejarse en un ambiente gráfico y aprovechando
además las bondades de la multimedia, para de esa manera
atraer al usuario hacia el sistema.
2.3.2.6. DISEÑO DEL FLUJO DE LOS
PROCEDIMIENTOS.

Identificación y descripción de transacciones que se realizan

en el control de material.
En el siguiente documento identificaremos un conjunto de
procedimientos que se realizan en la distribución de los
productos de una imprenta hacia los diferentes trabajos
realizados allí inclusive emperchar, así como también su
descripción, los procesos que implica, y un algoritmo que
describa la secuencia de pasos que se realiza por cada
transacción.
El orden de las transacciones debe determinar también la
frecuencia con la que se ejecutan:

2.3.3. FASE DE IMPLEMENTACIÓN E

INTEGRACIÓN IMPLEMENTACIÓN.

La implementación es la fase Terminal de la realización del

proyecto, razón por la cual no tendremos problemas en visto
de que tanto el análisis como el diseño a cumplido todas las
pasos necesarios para de esa forma garantizar que la
implementación del sistema SFRA, esta fase se la realiza
transformando el diseño detallado en código.
Primeramente ¿Cómo escogimos el código Correcto?
Se tuvo en cuenta:
La naturaleza de la aplicación.
Soporte técnico.
Experiencia.

A nivel de dirección de sistemas la elección de una

herramienta se ha decidido por COSTO – BENEFICIO
Tiempo invertido.
Recurso Consumido.

2.3.4. CONSIDERACIONES DE PROGRAMACIÓN.

Se ha utilizado nombres de variables CONSISTENTES Y

SIGNIFICATIVAS .

Consistentes = Orden correcto y completo

Significativos = Objetos y eventos reales en lenguaje natural.
Idioma: las variables están escritas en lenguaje ESPAÑOL, fácil
de identificar para cualquier mantenimiento en un futuro.

Para la Programación del sistema utilizaremos el Visual Basic

6.0, ya que es un lenguaje de programación de IV Generación
que nos brinda las facilidades necesarias para programar la
aplicación, la base de datos está utilizaremos MYSQL para
garantizar la integridad de cada una de las tablas, así como
también evitar la redundancia de información.
2.4. FASE DE MANTENIMIENTO.

En esta fase se determinara mediante un cronograma el

tiempo que se debe otorgar al mantenimiento, mismo que
después de cada cual las partes concuerdan en que se
entregara un informe de lo que se realiza en el mantenimiento
ya sea este de cambios al producto a de adaptación del mismo.