SlideShare una empresa de Scribd logo
1 de 47
INTEGRANTES: 
- JUGO QUIPUZCO JEISON 
- DIAZ CASTILLO COSME 
- RODRIGUEZ VALLADARES JUNIOR 
EMPRESA: 
MECANICA AUTOMOTRIZ JAVIER S.A 
CARRERA: 
INDUSTRIAL Y SISTEMAS 
CURSO: 
ANALISIS Y DISEÑO DE SISTEMA II
EMPRESA EN ESTUDIO: MECANICA AUTOMOTRIZ 
«JAVIER S.A» 
 SITUACIÓN PROBLEMA 
1. ESTUDIO DEL DOMINIO DEL PROBLEMA 
- La mecánica no cuenta con un sistema de registro de clientes. 
2. ASPECTOS POSITIVOS 
- Cuenta con una página web. 
- Servicio personalizado. 
ASPECTOS NEGATIVOS 
- El cliente no es registrado. 
3. MODELADO DEL NEGOCIO 
CASO DE USO 
- Gestionar el servicio automotriz . 
- Gestionar autopartes. 
-Gestionar impuestos.
4. ENTORNO TECNOLOGICO DEL CLIENTE 
- Computadoras 
- Redes 
- Teléfono 
5. OBTENER Y DOCUMENTAR LAS NECESIDADES DEL 
CLIENTE 
- Contar con un sistema de registro de cliente 
CARACTERISTICAS 
DESARROLLAR LA VISIÓN GENERAL DEL SISTEMA 
- Ser la n° 1 en servicio automotriz en Trujillo 
- Mejorar el servicio de atención al cliente en 100% 
- Capacitar al trabajador para un buen manejo de equipos automotriz 
- Incrementar el nivel de ventas de repuestos mensuales a un 20%
 DIAGRAMAS DE CASO DE USO DEL NEGOCIO 
ESTRUCTURA DEL MCUN
OBJETIVOS DEL NEGOCIO
CASOS DE USO DEL NEGOCIO:
ACTORES DEL NEGOCIO:
OBJETIVOS VS CUN:
DIAGRAMA GENERAL:
ESTRUCTURA DEL MAN:
REALIZACIONES DE NEGOCIO:
TRABAJADORES DEL NEGOCIO:
GESTIONAR SERVICIO AUTOMOTRIZ 
•DIAGRAMA DE ACTIVIDADES:
GESTIONAR AUTOPARTES
GESTIONAR PAGO DE IMPUESTOS
Especificación de requisitos de software 
Proyecto: AUTOSOFF 
Revisión 1.0
Fecha Revisión Descripción Autor 
03/09/2014 
1.0 “Requerimientos del cliente” ING. JUNIOR RODRUIGUEZ 
VALLADARES 
10/09/2014 1.5 “Requisitos Funcionales / No 
Funcionales” 
ING. JUNIOR RODRUIGUEZ 
VALLADARES 
•Historial de Revisiones
Documento validado por las partes en fecha:03/09/2014 
Por el cliente MECANICA AUTOMOTRIZ « JAVIER 
S.A » 
Fdo. D./ Dña IGNACIO GOMEZ Fdo. D./Dña: ING RODRUIGUEZ 
VALLADARES
1. Introducción 
El presente documento sirve para especificar los requisitos del cliente en función al 
software AUTOSOFF que se desea desarrollar. 
1.1 Propósito 
El documento permite al cliente tener una visión general de lo que se pretende 
desarrollar a partir de los requisitos del negocio 
1.2 Alcance 
Se desarrollara el Software AUTOSOFF que permitirá la Gestión de Servicio 
Automotriz entre otras funciones. 
En este software se pueden implementar más funcionalidades en futuras versiones.
1.3 Personal involucrado 
Nombre JUNIOR RODRIGUEZ 
Rol Jefe de Proyecto 
Categoría profesional Tec. Profesional en Industrial y Sistemas 
Responsabilidades Gestión del Proyecto 
Información de contacto Jr_capricornio@hotmail.com / 945467571 
Aprobación JEISON JUGO 
COSME DIAZ 
Nombre JEISON JUGO 
Rol ANALISTA 
Categoría profesional Tec. Profesional en Industrial y Sistemas 
Responsabilidades Analista del sistema 
Información de contacto jeison_capricornio_95@hotmail.com / 947042135 
Aprobación JUAN RODRIGUEZ 
Nombre COSME DIAZ 
Rol Recopilador de Requerimientos 
Categoría profesional Tec. Profesional en Industrial y Sistemas 
Responsabilidades Recopilar la documentación de los requerimientos 
Información de contacto Cosme1725 @hotmail.com / 948754351 
Aprobación JUAN RODRIGUEZ
1.4 Definiciones, acrónimos y abreviaturas 
 Caso de Uso: es una descripción de los pasos o las actividades que deberán realizarse 
para llevar a cabo algún proceso. 
 Modelo: es una representación de un objeto, sistema o idea, de forma diferente al de la 
entidad misma. 
 Diagrama : es un gráfico que presenta en forma esquematizada información relativa e 
inherente a algún tipo de ámbito 
 Sistema: conjunto de partes o elementos organizados y relacionados que interactúan 
entre sí para lograr un objetivo. 
 BD: Se define una base de datos como una serie de datos organizados y relacionados 
entre sí.
Referencia Titulo Ruta Fecha Autor 
Vinculo 
Web 
ERS 
MyMSystem 
https://docs.google.com/docu 
ment/pub?id=1VmuKwS 
vXPf8XEbwatLhP9eWdyCis2 
xPo4PWQgCwayH0 
12/09 N/A 
1.5 Referencias 
1.6 Resumen 
Este documento sirve como referencia entre el cliente y la empresa desarrolla acerca 
de las características del software AUTOSOFF a desarrollar.
2. Descripción general 
En esta sección se describen las características del producto AUTOSOFFa 
desarrollar. 
Misión: Crear un sistema de información que permita el manejo de los procesos de 
servicio automotriz entre otros de la empresa JAVIER S.A 
Visión: Desarrollar un software de calidad que permita a la empresa posicionarse en 
primer en el mercado de desarrollo de software a nivel nacional. 
2.1 Perspectiva del producto 
Este sistema funcionara en un ambiente donde exista una red LAN, el cual contendrá 
manejo de una base de datos sobre los clientes que acuden con frecuencia a la 
mecánica entre otros.
2.2 Funcionalidad del producto 
El sistema se encargara de las siguientes funciones: 
 Gestión Administrativa 
 Reportes 
 Gestión de Usuarios 
 Gestión de venta de autopartes 
 Venta de autopartes personalizados 
 Venta de autopartes en Línea 
2.4 Restricciones 
 Sistema Operativo: El SW a desarrollar funcionara en Windows 7 o versiones 
posteriores 
 Red LAN: Debe existir una Red LAN para la venta de autopartes dentro del taller, 
así como la gestión del sistema 
 Dominio Web: Debe existir un dominio web propio para los procesos online del 
software a desarrollar. 
 Seguridad: Debe implementarse políticas de seguridad para el manejo de la 
información tanta en HW y SW
2.5 Suposiciones y dependencias 
De no aprobar las restricciones anteriormente expuestas, el Sistema no podrá 
funcionar adecuadamente, con los parámetros de calidad con el que cuenta. 
2.6 Evolución previsible del sistema 
Se podrá implementar en el futuro una versión para dispositivos móviles. 
Se podrá actualizar el software con nuevas versiones de acuerdo a la evolución de 
las tecnologías de información. 
Todos estos cambios son sujetos a un nuevo contrato de desarrollo de software
3. Requisitos específicos 
Aquí se presentan los requisitos funcionales que deberán ser satisfechos por el 
sistema. 
Todos los requisitos aquí expuestos son esenciales, es decir, no sería aceptable un 
sistema que no satisfaga alguno de los requisitos aquí presentados. 
Estos requisitos se han especificado teniendo en cuenta, entre otros, el criterio de 
estabilidad: dado un requisito, debería ser fácilmente demostrable si es satisfecho 
o no por el sistema.
Número de requisito R1 
Nombre de requisito REQUISITO DE AUTENTICACIÓN 
Tipo Requisito Restricción 
Fuente del requisito Todos los usuarios deberán introducir en la pantalla de “login” 
un usuario y contraseña válidos en el sistema para poder 
entrar a éste 
Prioridad del requisito Alta/Esencial Media/Deseado Baja/ Opcional 
Número de requisito R2 
Nombre de requisito REQUISITO DE DESCRIPCIÓN 
Tipo Requisito Restricción 
Fuente del requisito El usuario administrador podrá guardar cambios en 
productos, inventario, clientes y ventas, mientras que el 
usuario empleado sólo lo podrá hacer en las ventas. 
Prioridad del requisito Alta/Esencial Media/Deseado Baja/ Opcional
3.1 Requisitos comunes de los interfaces 
 La interfaz de login necesita como entrada un usuario y contraseña válidos para 
poder dar acceso a la siguiente interfaz. 
 La interfaz del módulo de inventario necesita como entrada los datos de un producto, 
en caso de que sea necesario integrar éste al inventario
 Interfaces de usuario 
 La interfaz en uso deberá mostrar a los usuarios solamente la información necesaria 
para realizar cualquier operación. 
 Interfaces de Usuario a través de menús y ventanas para la aplicación en escritorio. 
 La interfaz en uso deberá mostrarle al usuario administrador sólo la información 
necesaria para realizar una modificación. 
 Imagen de ventana escritorio. 
 Interfaces de usuario a través de páginas web, específicamente paginas dinámicas 
las cuales son utilizadas para la aplicación del sistema.
 Interfaces de hardware 
 El monitor: éste deberá mostrar las interfaces así como la información necesaria 
para que el usuario pueda trabajar adecuadamente con el sistema. El monitor 
deberá contar con una resolución de 1024 x 768 pixeles. 
 El ratón: el sistema requerirá del ratón para que el usuario pueda realizar 
selecciones y oprimir botones. 
 El teclado: el sistema permitirá al usuario introducir datos mediante el teclado. 
 Impresora: para el manejo de reportes del sistema 
 Interfaces de software 
El sistema interactuará con la interfaz de impresión. 
 Interfaces de comunicación 
El sistema se comunica con su base de datos a través del SGBD SQLServer. 
El sistema se comunicara con las interfaces de pagos electrónicos.
3.2 Requisitos funcionales 
El sistema permitirá la entrada a los usuarios que cuenten con la 
autorización necesaria. 
El sistema recibirá los datos de clientes y productos almacenándolos en la 
base de datos para futuras consultas y diversas operaciones. 
Si se hubiera algún error al momento de ejecutar el proceso, el sistema 
deberá permitir retroceder, es decir, deshacer la operación.
 Autenticación 
El usuario deberá proporcionar un usuario y contraseña válidos para 
poder tener acceso al sistema. 
 Ventas 
El sistema calculará el monto de la venta a partir de los identificadores 
de los repuestos que se venderán, buscando con ellos el precio de 
cada producto. 
 Impresión de ticket 
Para poder imprimir un ticket de venta al cliente primero deberá 
registrarse dicha venta (sin importar su naturaleza) en la base de datos.
3.3 Requisitos no funcionales 
 Rendimiento 
 Respuesta 
El sistema ofrecerá respuesta al usuario en tiempo real. 
 Seguridad 
 Requisito de autenticación 
El sistema requerirá de un usuario y contraseña válidos para poder permitir el 
acceso. 
 Requisito de conexión. 
El sistema sólo tendrá abierta la conexión a la base de datos mientras se 
ejecuta la transacción. 
 Requisito de copia de seguridad 
El sistema realizará una copia de seguridad periódicamente siempre y cuando 
encuentre la conexión cerrada, de lo contrario lo intentará más tarde.
 Disponibilidad 
En funcionamiento normal el sistema estará disponible el 90% del tiempo. 
 Mantenibilidad 
 Requisito de mantenimiento 
El sistema recibirá mantenimiento dos veces por mes los primeros 6 meses. 
 Requisito de actualización de estadísticas. 
Se actualizarán las estadísticas manualmente para no perjudicar el 
rendimiento con una actualización automática. 
 Requisito de comprobación de integridad de datos. 
Se comprobará la integridad y asignación estructural de objetos e índices de 
la base de datos.
 Portabilidad 
 Requisito de SW 
MyMSystem será portable siempre y cuando el equipo en que se quiera 
instalar cuente con un SO igual o de versión posterior al primer equipo donde 
se instaló 
 Requisito de HW 
MyMSystem será portable siempre y cuando el equipo en el que se instale 
tenga especificaciones de HW iguales o superiores al primer equipo donde se 
instaló. 
. 
 Otros requisitos 
Si el usuario empleado quiere realizar alguna modificación deberá ser necesario 
que se presente el usuario administrador con su contraseña, salir de la 
sesión del usuario empleado y entrar a la suya.
NEEDS 
CARACTERISTICAS 
REQUERIMIENTOS 
PIRÁMIDE DE REQUISITOS 
 DESARROLLAR UN SISTEMA QUE NOS PERMITA MEJORAR LOS 
PROCESOS PRINCIPALES DE LA EMPRESA. 
 MEJORAR EL SERVICIO AUTOMOTRIZ. 
 CONTAR CON REPORTES DE ATENCION 
 MANEJAR ORDENES DE ATENCION 
 GESTIONAR SERVICIO AUTOMOTRIZ 
 GESTIONAR IMPUESTOS 
 GESTIONAR ABASTECIMIENTO DE AUTOPARTES 
 EL SISTEMA ESTARA DISPONIBLE LAS 24 HORAS DEL DIA. 
 EL SISTEMA DARA RESPUESTA A LAS PREGUNTAS EN MENOS DE 2 
MINUTOS
Casos de uso 
Requisitos 
GESTINAR 
SERVICIO 
AUTOMOTRIZ 
GESTIONAR 
ABASTECIMIENTO 
DE AUTOPARTES 
GESTIONAR 
IMPUESTOS 
ATENCION LAS 24 
HORAS DEL DIA 
MANTENER BOLETAS 
DE ATENCION 
GESTION DE PEDIDO 
MANTENER 
FORMULARIO DE 
IMPUESTOS 
MATRIZ DE TRAZABILIDAD
ORGANIZACIÓN DEL MCU
ACTORES
CASOS DE USO
PAQUETE: REUTILIZABLES
PAQUETE: GESTIONAR SERVICIO DE ATENCION
PAQUETE: GESTIONAR ABASTECIMIENTO DE AUTOPARTES
PAQUETE: SEGURIDAD
DIAGRAMA GENERAL
Proyecto de Análisis y Diseño -  Mecánica Automotriz Javier S.A
Proyecto de Análisis y Diseño -  Mecánica Automotriz Javier S.A

Más contenido relacionado

La actualidad más candente

Requerimientos funcionales y no funcionales de la aplicación
Requerimientos funcionales y no funcionales de la aplicaciónRequerimientos funcionales y no funcionales de la aplicación
Requerimientos funcionales y no funcionales de la aplicación
Yare LoZada
 
Requerimiento funcional y no funcional
Requerimiento funcional y no funcional Requerimiento funcional y no funcional
Requerimiento funcional y no funcional
CristobalFicaV
 
Configuracion de un disco maestro y un esclavo
Configuracion de un disco maestro y un esclavoConfiguracion de un disco maestro y un esclavo
Configuracion de un disco maestro y un esclavo
eli54
 
Requerimientos de un sistema operativo 1
Requerimientos de un sistema operativo  1Requerimientos de un sistema operativo  1
Requerimientos de un sistema operativo 1
tecnologia01
 
IMPORTANCIA DEL ANÁLISIS DE REQUERIMIENTOS PARA EL DESARROLLO DE SISTEMAS
IMPORTANCIA DEL ANÁLISIS DE REQUERIMIENTOS PARA EL DESARROLLO DE SISTEMASIMPORTANCIA DEL ANÁLISIS DE REQUERIMIENTOS PARA EL DESARROLLO DE SISTEMAS
IMPORTANCIA DEL ANÁLISIS DE REQUERIMIENTOS PARA EL DESARROLLO DE SISTEMAS
Alcoverify
 

La actualidad más candente (20)

Requerimientos funcionales y no funcionales de la aplicación
Requerimientos funcionales y no funcionales de la aplicaciónRequerimientos funcionales y no funcionales de la aplicación
Requerimientos funcionales y no funcionales de la aplicación
 
Que es la usabilidad
Que es la usabilidadQue es la usabilidad
Que es la usabilidad
 
Requerimiento funcional y no funcional
Requerimiento funcional y no funcional Requerimiento funcional y no funcional
Requerimiento funcional y no funcional
 
Diagramas de Casos de Uso del Negocio y del Sistema
 Diagramas de Casos de Uso del Negocio y del Sistema Diagramas de Casos de Uso del Negocio y del Sistema
Diagramas de Casos de Uso del Negocio y del Sistema
 
Formato ieee830(srs lleno)
Formato ieee830(srs lleno)Formato ieee830(srs lleno)
Formato ieee830(srs lleno)
 
Requisitos funcionales y no funcionales
Requisitos funcionales y no funcionales Requisitos funcionales y no funcionales
Requisitos funcionales y no funcionales
 
Sqap ejemplos
Sqap ejemplosSqap ejemplos
Sqap ejemplos
 
Dfd
DfdDfd
Dfd
 
Requerimientos norma ieee830
Requerimientos norma ieee830Requerimientos norma ieee830
Requerimientos norma ieee830
 
Evaluación a interfaces - Test de usuarios,evaluación heurística y eye-tracking
Evaluación a interfaces - Test de usuarios,evaluación heurística y eye-trackingEvaluación a interfaces - Test de usuarios,evaluación heurística y eye-tracking
Evaluación a interfaces - Test de usuarios,evaluación heurística y eye-tracking
 
Usabilidad
UsabilidadUsabilidad
Usabilidad
 
Lectura 3 Modelo De Analisis
Lectura 3   Modelo De AnalisisLectura 3   Modelo De Analisis
Lectura 3 Modelo De Analisis
 
Modelado del análisis
Modelado del análisisModelado del análisis
Modelado del análisis
 
Configuracion de un disco maestro y un esclavo
Configuracion de un disco maestro y un esclavoConfiguracion de un disco maestro y un esclavo
Configuracion de un disco maestro y un esclavo
 
Requerimientos de un sistema operativo 1
Requerimientos de un sistema operativo  1Requerimientos de un sistema operativo  1
Requerimientos de un sistema operativo 1
 
IMPORTANCIA DEL ANÁLISIS DE REQUERIMIENTOS PARA EL DESARROLLO DE SISTEMAS
IMPORTANCIA DEL ANÁLISIS DE REQUERIMIENTOS PARA EL DESARROLLO DE SISTEMASIMPORTANCIA DEL ANÁLISIS DE REQUERIMIENTOS PARA EL DESARROLLO DE SISTEMAS
IMPORTANCIA DEL ANÁLISIS DE REQUERIMIENTOS PARA EL DESARROLLO DE SISTEMAS
 
Requerimientos de usuario y del sistema
Requerimientos de usuario y del sistemaRequerimientos de usuario y del sistema
Requerimientos de usuario y del sistema
 
NORMA ISO 90003
NORMA ISO 90003NORMA ISO 90003
NORMA ISO 90003
 
Ejercicio seguridad en redes
Ejercicio seguridad en redesEjercicio seguridad en redes
Ejercicio seguridad en redes
 
Requisitos funcionales y no funcionales
Requisitos funcionales y no funcionalesRequisitos funcionales y no funcionales
Requisitos funcionales y no funcionales
 

Similar a Proyecto de Análisis y Diseño - Mecánica Automotriz Javier S.A

Proyecto De Analisis Y Sistema De Reclamos
Proyecto De Analisis Y Sistema De ReclamosProyecto De Analisis Y Sistema De Reclamos
Proyecto De Analisis Y Sistema De Reclamos
investigacionformativaut
 
Proyecto De Analisis Y Sistema De Reclamos
Proyecto De Analisis Y Sistema De ReclamosProyecto De Analisis Y Sistema De Reclamos
Proyecto De Analisis Y Sistema De Reclamos
investigacionformativaut
 
Arquitectura 2
Arquitectura 2Arquitectura 2
Arquitectura 2
bistasa
 
tarea de administracion sistema de informacion.docx
tarea de administracion sistema de informacion.docxtarea de administracion sistema de informacion.docx
tarea de administracion sistema de informacion.docx
LuisAbreu85
 
10 Clase Captura De Los Requisitos Cap.6
10 Clase Captura De Los Requisitos  Cap.610 Clase Captura De Los Requisitos  Cap.6
10 Clase Captura De Los Requisitos Cap.6
Julio Pari
 
10 Clase Captura De Los Requisitos Cap[1].6
10 Clase Captura De Los Requisitos Cap[1].610 Clase Captura De Los Requisitos Cap[1].6
10 Clase Captura De Los Requisitos Cap[1].6
Julio Pari
 
0001-Informe de Factibilidad de Proyecto (1).docx
0001-Informe de Factibilidad de Proyecto (1).docx0001-Informe de Factibilidad de Proyecto (1).docx
0001-Informe de Factibilidad de Proyecto (1).docx
BrayanPUMAVILLA
 

Similar a Proyecto de Análisis y Diseño - Mecánica Automotriz Javier S.A (20)

Ers panaderia final analisis2
Ers panaderia final analisis2Ers panaderia final analisis2
Ers panaderia final analisis2
 
Proyecto De Analisis Y Sistema De Reclamos
Proyecto De Analisis Y Sistema De ReclamosProyecto De Analisis Y Sistema De Reclamos
Proyecto De Analisis Y Sistema De Reclamos
 
Proyecto De Analisis Y Sistema De Reclamos
Proyecto De Analisis Y Sistema De ReclamosProyecto De Analisis Y Sistema De Reclamos
Proyecto De Analisis Y Sistema De Reclamos
 
sistema de empresas
sistema de empresassistema de empresas
sistema de empresas
 
DIseño de Sistema
DIseño de Sistema DIseño de Sistema
DIseño de Sistema
 
Ers calzado ferrel
Ers calzado ferrelErs calzado ferrel
Ers calzado ferrel
 
Especificación de requisitos de software
Especificación de requisitos de softwareEspecificación de requisitos de software
Especificación de requisitos de software
 
Arquitectura 2
Arquitectura 2Arquitectura 2
Arquitectura 2
 
Arquitectura
ArquitecturaArquitectura
Arquitectura
 
Proyecto final programación avanzada
Proyecto final programación avanzadaProyecto final programación avanzada
Proyecto final programación avanzada
 
tarea de administracion sistema de informacion.docx
tarea de administracion sistema de informacion.docxtarea de administracion sistema de informacion.docx
tarea de administracion sistema de informacion.docx
 
10 Clase Captura De Los Requisitos Cap.6
10 Clase Captura De Los Requisitos  Cap.610 Clase Captura De Los Requisitos  Cap.6
10 Clase Captura De Los Requisitos Cap.6
 
10 Clase Captura De Los Requisitos Cap[1].6
10 Clase Captura De Los Requisitos Cap[1].610 Clase Captura De Los Requisitos Cap[1].6
10 Clase Captura De Los Requisitos Cap[1].6
 
PROYECTO DE TESIS SISTEMA INTEGRAL DE COMPRA Y VENTA
PROYECTO DE TESIS SISTEMA INTEGRAL DE COMPRA Y VENTAPROYECTO DE TESIS SISTEMA INTEGRAL DE COMPRA Y VENTA
PROYECTO DE TESIS SISTEMA INTEGRAL DE COMPRA Y VENTA
 
Tema 3
Tema 3Tema 3
Tema 3
 
Aladdin cargo - Steven Alejandro Suárez Castro
Aladdin cargo - Steven Alejandro Suárez CastroAladdin cargo - Steven Alejandro Suárez Castro
Aladdin cargo - Steven Alejandro Suárez Castro
 
0001-Informe de Factibilidad de Proyecto (1).docx
0001-Informe de Factibilidad de Proyecto (1).docx0001-Informe de Factibilidad de Proyecto (1).docx
0001-Informe de Factibilidad de Proyecto (1).docx
 
SCADAS COMERCIALES
SCADAS COMERCIALESSCADAS COMERCIALES
SCADAS COMERCIALES
 
Anteproyecto salazar bolivar
Anteproyecto salazar bolivarAnteproyecto salazar bolivar
Anteproyecto salazar bolivar
 
Analisis De Software
Analisis De SoftwareAnalisis De Software
Analisis De Software
 

Último

COMPENDIO ECE 5 GRADO MATEMÁTICAS DE PRIMARIA
COMPENDIO ECE 5 GRADO MATEMÁTICAS DE PRIMARIACOMPENDIO ECE 5 GRADO MATEMÁTICAS DE PRIMARIA
COMPENDIO ECE 5 GRADO MATEMÁTICAS DE PRIMARIA
Wilian24
 
2° SEM32 WORD PLANEACIÓN PROYECTOS DARUKEL 23-24.docx
2° SEM32 WORD PLANEACIÓN PROYECTOS DARUKEL 23-24.docx2° SEM32 WORD PLANEACIÓN PROYECTOS DARUKEL 23-24.docx
2° SEM32 WORD PLANEACIÓN PROYECTOS DARUKEL 23-24.docx
candy torres
 
Concepto y definición de tipos de Datos Abstractos en c++.pptx
Concepto y definición de tipos de Datos Abstractos en c++.pptxConcepto y definición de tipos de Datos Abstractos en c++.pptx
Concepto y definición de tipos de Datos Abstractos en c++.pptx
Fernando Solis
 

Último (20)

UNIDAD DIDACTICA nivel inicial EL SUPERMERCADO.docx
UNIDAD DIDACTICA nivel inicial EL SUPERMERCADO.docxUNIDAD DIDACTICA nivel inicial EL SUPERMERCADO.docx
UNIDAD DIDACTICA nivel inicial EL SUPERMERCADO.docx
 
Educacion Basada en Evidencias SM5 Ccesa007.pdf
Educacion Basada en Evidencias  SM5  Ccesa007.pdfEducacion Basada en Evidencias  SM5  Ccesa007.pdf
Educacion Basada en Evidencias SM5 Ccesa007.pdf
 
10-08 Avances tecnológicos del siglo XXI.pdf
10-08 Avances tecnológicos del siglo XXI.pdf10-08 Avances tecnológicos del siglo XXI.pdf
10-08 Avances tecnológicos del siglo XXI.pdf
 
Lecciones 06 Esc. Sabática. Los dos testigos
Lecciones 06 Esc. Sabática. Los dos testigosLecciones 06 Esc. Sabática. Los dos testigos
Lecciones 06 Esc. Sabática. Los dos testigos
 
Sesión de clase APC: Los dos testigos.pdf
Sesión de clase APC: Los dos testigos.pdfSesión de clase APC: Los dos testigos.pdf
Sesión de clase APC: Los dos testigos.pdf
 
Los dos testigos. Testifican de la Verdad
Los dos testigos. Testifican de la VerdadLos dos testigos. Testifican de la Verdad
Los dos testigos. Testifican de la Verdad
 
Presentación de la propuesta de clase.pdf
Presentación de la propuesta de clase.pdfPresentación de la propuesta de clase.pdf
Presentación de la propuesta de clase.pdf
 
Prueba de evaluación Geografía e Historia Comunidad de Madrid 4ºESO
Prueba de evaluación Geografía e Historia Comunidad de Madrid 4ºESOPrueba de evaluación Geografía e Historia Comunidad de Madrid 4ºESO
Prueba de evaluación Geografía e Historia Comunidad de Madrid 4ºESO
 
AEC2. Egipto Antiguo. Adivina, Adivinanza.pptx
AEC2. Egipto Antiguo. Adivina, Adivinanza.pptxAEC2. Egipto Antiguo. Adivina, Adivinanza.pptx
AEC2. Egipto Antiguo. Adivina, Adivinanza.pptx
 
COMPENDIO ECE 5 GRADO MATEMÁTICAS DE PRIMARIA
COMPENDIO ECE 5 GRADO MATEMÁTICAS DE PRIMARIACOMPENDIO ECE 5 GRADO MATEMÁTICAS DE PRIMARIA
COMPENDIO ECE 5 GRADO MATEMÁTICAS DE PRIMARIA
 
Novena de Pentecostés con textos de san Juan Eudes
Novena de Pentecostés con textos de san Juan EudesNovena de Pentecostés con textos de san Juan Eudes
Novena de Pentecostés con textos de san Juan Eudes
 
2° SEM32 WORD PLANEACIÓN PROYECTOS DARUKEL 23-24.docx
2° SEM32 WORD PLANEACIÓN PROYECTOS DARUKEL 23-24.docx2° SEM32 WORD PLANEACIÓN PROYECTOS DARUKEL 23-24.docx
2° SEM32 WORD PLANEACIÓN PROYECTOS DARUKEL 23-24.docx
 
La Sostenibilidad Corporativa. Administración Ambiental
La Sostenibilidad Corporativa. Administración AmbientalLa Sostenibilidad Corporativa. Administración Ambiental
La Sostenibilidad Corporativa. Administración Ambiental
 
GRUPO 2 - LA GRAN TRIBULACIÓN 25-03-2024 vf.pdf
GRUPO 2 - LA GRAN TRIBULACIÓN 25-03-2024 vf.pdfGRUPO 2 - LA GRAN TRIBULACIÓN 25-03-2024 vf.pdf
GRUPO 2 - LA GRAN TRIBULACIÓN 25-03-2024 vf.pdf
 
EFEMERIDES DEL MES DE MAYO PERIODICO MURAL.pdf
EFEMERIDES DEL MES DE MAYO PERIODICO MURAL.pdfEFEMERIDES DEL MES DE MAYO PERIODICO MURAL.pdf
EFEMERIDES DEL MES DE MAYO PERIODICO MURAL.pdf
 
TÉCNICAS OBSERVACIONALES Y TEXTUALES.pdf
TÉCNICAS OBSERVACIONALES Y TEXTUALES.pdfTÉCNICAS OBSERVACIONALES Y TEXTUALES.pdf
TÉCNICAS OBSERVACIONALES Y TEXTUALES.pdf
 
Programa dia de las madres para la convi
Programa dia de las madres para la conviPrograma dia de las madres para la convi
Programa dia de las madres para la convi
 
activ4-bloque4 transversal doctorado.pdf
activ4-bloque4 transversal doctorado.pdfactiv4-bloque4 transversal doctorado.pdf
activ4-bloque4 transversal doctorado.pdf
 
Concepto y definición de tipos de Datos Abstractos en c++.pptx
Concepto y definición de tipos de Datos Abstractos en c++.pptxConcepto y definición de tipos de Datos Abstractos en c++.pptx
Concepto y definición de tipos de Datos Abstractos en c++.pptx
 
animalesdelaproincia de beunos aires.pdf
animalesdelaproincia de beunos aires.pdfanimalesdelaproincia de beunos aires.pdf
animalesdelaproincia de beunos aires.pdf
 

Proyecto de Análisis y Diseño - Mecánica Automotriz Javier S.A

  • 1. INTEGRANTES: - JUGO QUIPUZCO JEISON - DIAZ CASTILLO COSME - RODRIGUEZ VALLADARES JUNIOR EMPRESA: MECANICA AUTOMOTRIZ JAVIER S.A CARRERA: INDUSTRIAL Y SISTEMAS CURSO: ANALISIS Y DISEÑO DE SISTEMA II
  • 2. EMPRESA EN ESTUDIO: MECANICA AUTOMOTRIZ «JAVIER S.A»  SITUACIÓN PROBLEMA 1. ESTUDIO DEL DOMINIO DEL PROBLEMA - La mecánica no cuenta con un sistema de registro de clientes. 2. ASPECTOS POSITIVOS - Cuenta con una página web. - Servicio personalizado. ASPECTOS NEGATIVOS - El cliente no es registrado. 3. MODELADO DEL NEGOCIO CASO DE USO - Gestionar el servicio automotriz . - Gestionar autopartes. -Gestionar impuestos.
  • 3. 4. ENTORNO TECNOLOGICO DEL CLIENTE - Computadoras - Redes - Teléfono 5. OBTENER Y DOCUMENTAR LAS NECESIDADES DEL CLIENTE - Contar con un sistema de registro de cliente CARACTERISTICAS DESARROLLAR LA VISIÓN GENERAL DEL SISTEMA - Ser la n° 1 en servicio automotriz en Trujillo - Mejorar el servicio de atención al cliente en 100% - Capacitar al trabajador para un buen manejo de equipos automotriz - Incrementar el nivel de ventas de repuestos mensuales a un 20%
  • 4.  DIAGRAMAS DE CASO DE USO DEL NEGOCIO ESTRUCTURA DEL MCUN
  • 6. CASOS DE USO DEL NEGOCIO:
  • 13. GESTIONAR SERVICIO AUTOMOTRIZ •DIAGRAMA DE ACTIVIDADES:
  • 15. GESTIONAR PAGO DE IMPUESTOS
  • 16. Especificación de requisitos de software Proyecto: AUTOSOFF Revisión 1.0
  • 17. Fecha Revisión Descripción Autor 03/09/2014 1.0 “Requerimientos del cliente” ING. JUNIOR RODRUIGUEZ VALLADARES 10/09/2014 1.5 “Requisitos Funcionales / No Funcionales” ING. JUNIOR RODRUIGUEZ VALLADARES •Historial de Revisiones
  • 18. Documento validado por las partes en fecha:03/09/2014 Por el cliente MECANICA AUTOMOTRIZ « JAVIER S.A » Fdo. D./ Dña IGNACIO GOMEZ Fdo. D./Dña: ING RODRUIGUEZ VALLADARES
  • 19. 1. Introducción El presente documento sirve para especificar los requisitos del cliente en función al software AUTOSOFF que se desea desarrollar. 1.1 Propósito El documento permite al cliente tener una visión general de lo que se pretende desarrollar a partir de los requisitos del negocio 1.2 Alcance Se desarrollara el Software AUTOSOFF que permitirá la Gestión de Servicio Automotriz entre otras funciones. En este software se pueden implementar más funcionalidades en futuras versiones.
  • 20. 1.3 Personal involucrado Nombre JUNIOR RODRIGUEZ Rol Jefe de Proyecto Categoría profesional Tec. Profesional en Industrial y Sistemas Responsabilidades Gestión del Proyecto Información de contacto Jr_capricornio@hotmail.com / 945467571 Aprobación JEISON JUGO COSME DIAZ Nombre JEISON JUGO Rol ANALISTA Categoría profesional Tec. Profesional en Industrial y Sistemas Responsabilidades Analista del sistema Información de contacto jeison_capricornio_95@hotmail.com / 947042135 Aprobación JUAN RODRIGUEZ Nombre COSME DIAZ Rol Recopilador de Requerimientos Categoría profesional Tec. Profesional en Industrial y Sistemas Responsabilidades Recopilar la documentación de los requerimientos Información de contacto Cosme1725 @hotmail.com / 948754351 Aprobación JUAN RODRIGUEZ
  • 21. 1.4 Definiciones, acrónimos y abreviaturas  Caso de Uso: es una descripción de los pasos o las actividades que deberán realizarse para llevar a cabo algún proceso.  Modelo: es una representación de un objeto, sistema o idea, de forma diferente al de la entidad misma.  Diagrama : es un gráfico que presenta en forma esquematizada información relativa e inherente a algún tipo de ámbito  Sistema: conjunto de partes o elementos organizados y relacionados que interactúan entre sí para lograr un objetivo.  BD: Se define una base de datos como una serie de datos organizados y relacionados entre sí.
  • 22. Referencia Titulo Ruta Fecha Autor Vinculo Web ERS MyMSystem https://docs.google.com/docu ment/pub?id=1VmuKwS vXPf8XEbwatLhP9eWdyCis2 xPo4PWQgCwayH0 12/09 N/A 1.5 Referencias 1.6 Resumen Este documento sirve como referencia entre el cliente y la empresa desarrolla acerca de las características del software AUTOSOFF a desarrollar.
  • 23. 2. Descripción general En esta sección se describen las características del producto AUTOSOFFa desarrollar. Misión: Crear un sistema de información que permita el manejo de los procesos de servicio automotriz entre otros de la empresa JAVIER S.A Visión: Desarrollar un software de calidad que permita a la empresa posicionarse en primer en el mercado de desarrollo de software a nivel nacional. 2.1 Perspectiva del producto Este sistema funcionara en un ambiente donde exista una red LAN, el cual contendrá manejo de una base de datos sobre los clientes que acuden con frecuencia a la mecánica entre otros.
  • 24. 2.2 Funcionalidad del producto El sistema se encargara de las siguientes funciones:  Gestión Administrativa  Reportes  Gestión de Usuarios  Gestión de venta de autopartes  Venta de autopartes personalizados  Venta de autopartes en Línea 2.4 Restricciones  Sistema Operativo: El SW a desarrollar funcionara en Windows 7 o versiones posteriores  Red LAN: Debe existir una Red LAN para la venta de autopartes dentro del taller, así como la gestión del sistema  Dominio Web: Debe existir un dominio web propio para los procesos online del software a desarrollar.  Seguridad: Debe implementarse políticas de seguridad para el manejo de la información tanta en HW y SW
  • 25. 2.5 Suposiciones y dependencias De no aprobar las restricciones anteriormente expuestas, el Sistema no podrá funcionar adecuadamente, con los parámetros de calidad con el que cuenta. 2.6 Evolución previsible del sistema Se podrá implementar en el futuro una versión para dispositivos móviles. Se podrá actualizar el software con nuevas versiones de acuerdo a la evolución de las tecnologías de información. Todos estos cambios son sujetos a un nuevo contrato de desarrollo de software
  • 26. 3. Requisitos específicos Aquí se presentan los requisitos funcionales que deberán ser satisfechos por el sistema. Todos los requisitos aquí expuestos son esenciales, es decir, no sería aceptable un sistema que no satisfaga alguno de los requisitos aquí presentados. Estos requisitos se han especificado teniendo en cuenta, entre otros, el criterio de estabilidad: dado un requisito, debería ser fácilmente demostrable si es satisfecho o no por el sistema.
  • 27. Número de requisito R1 Nombre de requisito REQUISITO DE AUTENTICACIÓN Tipo Requisito Restricción Fuente del requisito Todos los usuarios deberán introducir en la pantalla de “login” un usuario y contraseña válidos en el sistema para poder entrar a éste Prioridad del requisito Alta/Esencial Media/Deseado Baja/ Opcional Número de requisito R2 Nombre de requisito REQUISITO DE DESCRIPCIÓN Tipo Requisito Restricción Fuente del requisito El usuario administrador podrá guardar cambios en productos, inventario, clientes y ventas, mientras que el usuario empleado sólo lo podrá hacer en las ventas. Prioridad del requisito Alta/Esencial Media/Deseado Baja/ Opcional
  • 28. 3.1 Requisitos comunes de los interfaces  La interfaz de login necesita como entrada un usuario y contraseña válidos para poder dar acceso a la siguiente interfaz.  La interfaz del módulo de inventario necesita como entrada los datos de un producto, en caso de que sea necesario integrar éste al inventario
  • 29.  Interfaces de usuario  La interfaz en uso deberá mostrar a los usuarios solamente la información necesaria para realizar cualquier operación.  Interfaces de Usuario a través de menús y ventanas para la aplicación en escritorio.  La interfaz en uso deberá mostrarle al usuario administrador sólo la información necesaria para realizar una modificación.  Imagen de ventana escritorio.  Interfaces de usuario a través de páginas web, específicamente paginas dinámicas las cuales son utilizadas para la aplicación del sistema.
  • 30.  Interfaces de hardware  El monitor: éste deberá mostrar las interfaces así como la información necesaria para que el usuario pueda trabajar adecuadamente con el sistema. El monitor deberá contar con una resolución de 1024 x 768 pixeles.  El ratón: el sistema requerirá del ratón para que el usuario pueda realizar selecciones y oprimir botones.  El teclado: el sistema permitirá al usuario introducir datos mediante el teclado.  Impresora: para el manejo de reportes del sistema  Interfaces de software El sistema interactuará con la interfaz de impresión.  Interfaces de comunicación El sistema se comunica con su base de datos a través del SGBD SQLServer. El sistema se comunicara con las interfaces de pagos electrónicos.
  • 31. 3.2 Requisitos funcionales El sistema permitirá la entrada a los usuarios que cuenten con la autorización necesaria. El sistema recibirá los datos de clientes y productos almacenándolos en la base de datos para futuras consultas y diversas operaciones. Si se hubiera algún error al momento de ejecutar el proceso, el sistema deberá permitir retroceder, es decir, deshacer la operación.
  • 32.  Autenticación El usuario deberá proporcionar un usuario y contraseña válidos para poder tener acceso al sistema.  Ventas El sistema calculará el monto de la venta a partir de los identificadores de los repuestos que se venderán, buscando con ellos el precio de cada producto.  Impresión de ticket Para poder imprimir un ticket de venta al cliente primero deberá registrarse dicha venta (sin importar su naturaleza) en la base de datos.
  • 33. 3.3 Requisitos no funcionales  Rendimiento  Respuesta El sistema ofrecerá respuesta al usuario en tiempo real.  Seguridad  Requisito de autenticación El sistema requerirá de un usuario y contraseña válidos para poder permitir el acceso.  Requisito de conexión. El sistema sólo tendrá abierta la conexión a la base de datos mientras se ejecuta la transacción.  Requisito de copia de seguridad El sistema realizará una copia de seguridad periódicamente siempre y cuando encuentre la conexión cerrada, de lo contrario lo intentará más tarde.
  • 34.  Disponibilidad En funcionamiento normal el sistema estará disponible el 90% del tiempo.  Mantenibilidad  Requisito de mantenimiento El sistema recibirá mantenimiento dos veces por mes los primeros 6 meses.  Requisito de actualización de estadísticas. Se actualizarán las estadísticas manualmente para no perjudicar el rendimiento con una actualización automática.  Requisito de comprobación de integridad de datos. Se comprobará la integridad y asignación estructural de objetos e índices de la base de datos.
  • 35.  Portabilidad  Requisito de SW MyMSystem será portable siempre y cuando el equipo en que se quiera instalar cuente con un SO igual o de versión posterior al primer equipo donde se instaló  Requisito de HW MyMSystem será portable siempre y cuando el equipo en el que se instale tenga especificaciones de HW iguales o superiores al primer equipo donde se instaló. .  Otros requisitos Si el usuario empleado quiere realizar alguna modificación deberá ser necesario que se presente el usuario administrador con su contraseña, salir de la sesión del usuario empleado y entrar a la suya.
  • 36. NEEDS CARACTERISTICAS REQUERIMIENTOS PIRÁMIDE DE REQUISITOS  DESARROLLAR UN SISTEMA QUE NOS PERMITA MEJORAR LOS PROCESOS PRINCIPALES DE LA EMPRESA.  MEJORAR EL SERVICIO AUTOMOTRIZ.  CONTAR CON REPORTES DE ATENCION  MANEJAR ORDENES DE ATENCION  GESTIONAR SERVICIO AUTOMOTRIZ  GESTIONAR IMPUESTOS  GESTIONAR ABASTECIMIENTO DE AUTOPARTES  EL SISTEMA ESTARA DISPONIBLE LAS 24 HORAS DEL DIA.  EL SISTEMA DARA RESPUESTA A LAS PREGUNTAS EN MENOS DE 2 MINUTOS
  • 37. Casos de uso Requisitos GESTINAR SERVICIO AUTOMOTRIZ GESTIONAR ABASTECIMIENTO DE AUTOPARTES GESTIONAR IMPUESTOS ATENCION LAS 24 HORAS DEL DIA MANTENER BOLETAS DE ATENCION GESTION DE PEDIDO MANTENER FORMULARIO DE IMPUESTOS MATRIZ DE TRAZABILIDAD