Proyecto Analisis De Sistemas

INSTITUTO TECNOLÓGICO SUPERIOR “JOSÈ OCHOA LEÒN” CARRERA DE TECNOLOGÍA EN ANALISIS DE SISTEMAS TEMA: “ANÁLISIS Y DEFINICION DE LOS REQUERIMIENTOS PREVIO AL DESARROLLO INFORMATICO QUE SOLUCIONARA LOS INCOVENIENTES DE LA FALTA DE AUTOMATIZACION EN EL DEPARTAMENTO DE ADMINISTRACION Y FACTURACION DE LA MECANICA AUTOMOTRIZ ESPINOZA DE LA CIUDAD DE PASAJE, PROVINCIA DE EL ORO AÑO 2015”. PROYECTO QUE SE PRESENTA COMO TRABAJO FINAL DE LA ASIGNATURA DE ANÁLISIS DE SISTEMAS DEL TERCER CICLO SECCIÓN NOCTURNA. AUTORES: 

CABRERA TORRES EDINSON XAVIER  ESPINOZA ARMIJOS RICHARD ANDRES  MOSQUERA TORRES LUIS FERNANDO  MOSQUERA TORRES LUIS MIGUEL DOCENTE: TLG. JONATHAN CHACHA Pasaje, 04 de Febrero del 2015

I

DEDICATORIA

Dedico este trabajo a los pilares fundamentales de mi vida que son mi mayor inspiración, quien me bendice y cuida mi sendero como es Dios, a mis padres, en especial mi madre Mercedes que son es apoyo incondicional para alcanzar la meta anhelada, a mis sobrinos, que nunca han dejado que se trunque mis sueños y deseos de superación, quien ha sido mi conciencia para la culminación de mis estudios. ESPINOZA ARMIJOS RICHARD ANDRES A mi madre con mucho amor y

cariño le dedico todo mi esfuerzo y trabajo

puesto para la realización de esta tesis. CABRERA TORRES EDINSON XAVIER La concepción de este proyecto está dedicada a mis padres, pilares fundamentales en mi vida. Sin ellos, jamás hubiese podido conseguir lo que hasta ahora. Su tenacidad y lucha insaciable han hecho de ellos el gran ejemplo a seguir y destacar, no solo para mí, sino para mis hermanos y familia en general. También dedico este proyecto a mi novia, Mi Naranjita, compañera inseparable de cada jornada. Ella representó gran esfuerzo y tesón en momentos de decline y cansancio. A ellos este proyecto, que, sin ellos, no hubiese podido ser. LUIS MIGUEL MOSQUERA TORRES

V

Esta monografía está dedicada a mis padres ya que gracias a ellos puedo estar en esta linda institución y poder aportar con mis conocimientos. También dedico a mis abuelos ya que con ellos sigo siendo una persona de bien pese a cualquier tipo de enfermedad. Y quiero dedicar también a un amigo muy especial que es mi Dios con el ago. Todo y esta Conmigo en las buenas y en las malas, en las noches más frías y por eso se lo debo todo al ya que a pesar de mis errores en esta vida él supo perdonarme y comenzar nuevamente. LUIS FERNANDO MOSQUERA TORRES

V

AGRADECIMIENTO

Agradezco a Dios por proteger cada paso que doy, a mi familia que ha sido mi apoyo fundamental para continuar mis estudios superiores, quien en todo momento han estado junto a mi dándome fuerzas en cada obstáculo presentado, mi tutor Tlg. Jonathan Chacha, quien gracias sus conocimientos impartidas en el aula de clases ha logrado ilustrarnos, a todos mis compañeros que de una y otra forma me han apoyado de las enseñanzas recibidas ESPINOZA ARMIJOS RICHARD ANDRES En primer lugar, a Dios por haberme guiado por el camino de la felicidad hasta ahora; en segundo lugar, a cada uno de los que son parte de mi familia a mi MADRE; a mis hermanos y a todos mis tíos; por siempre haberme dado su fuerza y apoyo incondicional que me han ayudado y llevado hasta donde estoy ahora. Por último, a mis compañeros de tesis porque en esta armonía grupal lo hemos logrado y a mi director de tesis quién nos ayudó en todo momento, Tlgo. Johnnatan Chacha. EDINSON XAVIER CABRERA TORRES Los resultados de este proyecto, están dedicados a todas aquellas personas que, de alguna forma, son parte de su culminación.

Nuestros sinceros

agradecimientos están dirigidos hacia nuestros amigos, quien, con su ayuda desinteresada, nos brindó información relevante, próxima, pero muy cercana a la realidad de nuestras necesidades. A los muchachos de 3º Análisis de Sistemas, los cuáles plasmaron nuestros resultados investigativos en diseños originales, atractivos y de gran realce para el éxito del proyecto. A nuestras familias por siempre brindarnos su apoyo, tanto sentimental, como V

económico. Pero, principalmente nuestros agradecimientos están dirigidos hacia la excelentísima autoridad de nuestro director y amigo, Johnnatan, sin el cual no hubiésemos podido salir adelante y al Tlgo. Johnnatan Chacha. LUIS MIGUEL MOSQUERA TORRES Primero, antes que nada, dar gracias a Dios, por estar conmigo en cada paso que doy, por fortalecer mi corazón e iluminar mi mente y por haber puesto en mi camino a aquellas personas que han sido mi soporte y compañía durante todo el periodo de estudio. Agradecer hoy y siempre a mi familia por el esfuerzo realizado por ellos. El apoyo en mis estudios, de ser así no hubiese sido posible. A mis padres y demás familiares ya que me brindan el apoyo, la alegría y me dan la fortaleza necesaria para seguir adelante. LUIS FERNANDO MOSQUERA TORRES

V

1 INDICE GENERAL PORTADA……………………………………………………………………........I DEDICATORIA……………...……………………………………………………… IIAGRADECIMIENTO…………………………………………………………...…III INDICE GENERAL……………………………………………………………………........IV 2

ÍNDICE DE CUADROS................................................................x

3

CAPITULO I..........................................................................11 1.1

TÍTULO DEL PROYECTO.....................................................11

1.2

OBJETIVOS.....................................................................11

3.1

1.2.1 OBJETIVO GENERAL..................................................11

1.2.2 3.2

OBJETIVOS ESPECÍFICOS................................................11 1.3 DESCRIPCIÓN GENERAL DE LA SITUACIÓN........................11

3.3 1.4 CONTEXTUALIZACIÓN DE LA ZONA DE INFLUENCIA DEL PROYECTO.............................................................................12 3.4........................................................................................13 3.5

1.5 JUSTIFICACIÓN DE LA NECESIDAD DE LA INTERVENCIÓN......13

3.6

1.5.1. FUNDAMENTACIÓN DE LA PROPUESTA..........................13

3.7

1.6 DESCRIPCIÓN DEL PROYECTO........................................14

Este proyecto se idealizo en las diferentes necesidades e inconvenientes que tienen los clientes, como también los usuarios, en la atención recibida y brindad de la Mecánica Automotriz, y debido a la desactualización se los servicios.................................................................................14 Los diferentes servicios que brinda el taller mecánico son de beneficiosos para la ciudadanía, por ser los pilares fundamentales del bienestar en servicio al cliente dirigido a los clientes como base de turismo. Como parte del estudio se identificó, que existen diferentes déficits para lograr la misión a la que se refiere el Gremio y de mecánicos y Anexos del Cantón Pasaje, su principal problema es la falta de automatización de cada cliente que recibe el taller, ya que no permite controlar su control de atención y poder realizar

V

el respectivo seguimiento médico, de acuerdo a las atenciones recibidas anteriormente y los diagnósticos emitidos por los diferentes................14 Ficha del documento...............................................................19 Contenido.................................................................................1 1

Introducción........................................................................3 1.1

Propósito.......................................................................3

1.2

Alcance..........................................................................3

Personal involucrado..............................................................4 1.3

2

3

Definiciones, acrónimos y abreviaturas............................5

1.3.1

Del Negocio.............................................................................5

1.3.2

Del Sistema.............................................................................5

1.3.3

De Tecnología.........................................................................6

1.4

Referencias....................................................................7

1.5

Resumen........................................................................7

Descripción general.............................................................7 2.1

Perspectiva del producto................................................7

2.2

Funcionalidad del producto.............................................7

2.3

Características de los usuarios........................................8

2.4

Restricciones..................................................................8

2.4.1

Políticas Reguladoras............................................................8

2.4.2

Limitaciones de Hardware.....................................................9

2.4.3

Interfaces con Otras Aplicaciones.......................................9

2.4.4

Funciones de Control............................................................9

2.4.5

Requisitos del Lenguaje........................................................9

2.4.6

Requisitos de Fiabilidad........................................................9

2.4.7

Credibilidad de la Aplicación................................................9

2.4.8

Consideraciones de Seguridad..........................................10

2.5

Suposiciones y dependencias........................................10

2.6

Evolución previsible del sistema....................................10

Requisitos específicos........................................................10 3.1

Requisitos comunes de los interfaces.............................11

3.1.1

Interfaces de usuario...........................................................11

V

3.1.2

Interfaces de hardware........................................................12

3.1.3

Interfaces de software.........................................................13

3.1.4

Interfaces de comunicación................................................13

3.2

Requisitos funcionales..................................................13

3.2.1

Requisito funcional 1...........................................................13

3.2.2

Requisito funcional 2...........................................................14

3.2.3

Requisito funcional 3...........................................................15

3.2.4

Requisito funcional n...........................................................17

3.3

Requisitos no funcionales..............................................18

3.3.1

Requisitos de rendimiento..................................................18

3.3.2

Seguridad..............................................................................18

3.3.3

Fiabilidad...............................................................................19

3.3.4

Disponibilidad.......................................................................19

3.3.5

Mantenibilidad......................................................................19

3.3.6

Portabilidad...........................................................................19

3.4

Otros requisitos............................................................19

4

Apéndices..........................................................................19

4

CAPÍTULO II.........................................................................21 4.1

2.1. MARCO TEÓRICO CONCEPTUAL.....................................21

4.2 2.1.1. DEFINICIÓN DE REQUERIMIENTOS Y DE ANÁLISIS DE REQUERIMIENTOS....................................................................21 4.3 2.2. SELECCIÓN DEL CICLO DE VIDA DE DESARROLLO DE PROYECTOS...........................................................................23 4.4........................................................................................24 4.5

2.3 ELECCIÓN DEL ENFOQUE DE DESARROLLO DEL SISTEMA.....24

4.6

2.4 FASES DEL PROYECTO.................................................25

4.6.1

2.4.1 FASE I: INVESTIGACIÓN PRELIMINAR...................25

4.6.2

2.4.2. FASE II: DETERMINACIÓN DE REQUERIMIENTOS 26

4.6.3

2.4.3. FASE III: ANÁLISIS....................................................27

4.6.4

2.4.4 FASE IV: DISEÑO.........................................................27

4.6.5

2.4.5 FASE V: CONSTRUCCIÓN..........................................28

4.7

MARCO TEÓRICO CONTEXUAL............................................28 V

4.7.1

RESEÑA HISTÓRICA............................................................28

4.7.2

MISIÓN...................................................................................31

4.7.3

VISIÓN...................................................................................31

5.1.1

OBJETIVOS...........................................................................32

1.2.4.1. 5.2

OBJETIVOS ESPECÌFICOS.............................................32

1.2. 5 FODA.....................................................................32

5.2.1

1.2.51.1. Fortalezas..............................................................32

5.2.2

1.2.51.2. Debilidades:...........................................................32

1.2.51.3. Oportunidades:...................................................................33 6

CAPITULO III.........................................................................34 1.1.

DURACIÓN DEL PROYECTO................................................34

1.2.

DESCRIPCIÓN DETALLADA DE LAS ACTIVIDADES....................35

1.3.

CRONOGRAMA DE EJECUCIÓN DE ACTIVIDADES.....................37

1.4.

RESULTADOS ALCANZADOS...............................................40

1.4.1. 7

FUNCIONAMIENTO DEL SISTEMA.......................................40

3.5. CONCLUSIONES Y RECOMENDACIONES................................42 7.1 1.5.2.

3.5.1. CONCLUSIONES.......................................................42 RECOMENDACIONES......................................................42

7.2

3.6. BIBLIOGRAFÍA............................................................43

7.3

ANEXOS.........................................................................45

7.4

ANEXO 1. ÁRBOL DE PROBLEMAS........................................45

7.5

ANEXO 2. ÁRBOL DE OBJETIVOS.........................................46

V

1 ÍNDICE DE CUADROS

2

CAPITULO I

V

1.1 TÍTULO DEL PROYECTO ANÁLISIS Y DEFINICION DE LOS REQUERIMIENTOS PREVIO AL DESARROLLO

INFORMATICO

QUE

INCOVENIENTES

DE

DE

LA

FALTA

SOLUCIONARA AUTOMATIZACION

LOS EN

EL

DEPARTAMENTO DE ADMINISTRACION DE LA MECANICA AUTOMOTRIZ ESPINOZA DE LA CIUDAD DE PASAJE, PROVINCIA DE EL ORO AÑO 2015 1.2 OBJETIVOS 2.1

1.2.1 OBJETIVO GENERAL

Permite identificar los problemas que presenta el departamento de administración y la necesidad de automatizar las historias de atención al cliente, de los clientes que son atendidos en la Mecánica Automotriz Espinoza, con el propósito de brindar un servicio rápido y oportuno, y que no exista 1.2.2 OBJETIVOS ESPECÍFICOS  Garantizar al cliente el acceso por vía sistemática a los datos, propios o de sus representados, que se encuentren disponibles en formato digital en alguno de los Servicios que se integra, siempre que cumplan los mínimos requisitos de seguridad establecidos para proteger sus propios datos contra la intrusión ilegítima de quienes no hayan sido facultados para acceder.  Garantizar a los clientes, un servicio de primea calidad, demostrando eficacia y de manera rápida el servicio de facturación; y que al momento de ingresar los datos, estos queden registrados en el sistema para una próxima atención.  El sistema a desarrollar deberá dotarse de agilidad y sencillez en el acceso, al servicio de los clientes.

V

2.2

1.3 DESCRIPCIÓN GENERAL DE LA SITUACIÓN.

Actualmente la Mecánica Automotriz de la Ciudad de Pasaje, está considerado como un Taller Básico según el Gremio de mecánicos y Anexos de la misma Ciudad, cuenta con los servicios completos de servicio de mantenimiento automotriz a los autos de los habitantes de la ciudad, mediante la construcción de un taller mecánico. Además de servicio de cambio de Aceite, cambio de Filtro, cambio de bujías, cambio de tensores, correas de tiempo y verificación de alternadores de motores de arranques a todo tipo de vehículo a diésel. La Mecánica Automotriz Espinoza de la Ciudad de Pasaje, recibe aproximadamente 10 clientes diarios para los diferentes servicios que se brinda, cabe indicar que, en cuanto a la descentralización, los clientes tienen que recibir atención primaria ya sea en servicios Mecánica General como en Mecánica preventiva, para que sean referidos a la atención básica automotriz, y reciban el tratamiento según el diagnóstico. En el día de la atención el cliente va directo a la preparación del vehículo ya que el oficial asistente realiza su

preparación, el historial del cliente se

mantienen en carpetas de la cuales no son totalmente seguras, totalmente desactualizado ya que solo permite ingresar los datos como nombre, apellido, fecha de nacimiento y numero de cedula, no permite opciones, no permite tener una atención rápida y oportuna, por lo que esta empresa necesita urgentemente de un Software sofisticado que permita la atención eficaz al actual y a los futuros clientes. Para finalizar, esta empresa no cuenta con un cartel, ni publicidad puesta, solo cuenta con los carteles de seguridad y está totalmente equipado.

V

2.3

1.4 CONTEXTUALIZACIÓN DE LA ZONA DE INFLUENCIA DEL PROYECTO

El proyecto se desarrolló con la finalidad de lograr la automatización y los requerimientos de un sistema de facturación que permitirá registrar, el historial de los clientes que son atendidos en la Mecánica Automotriz Espinoza de la ciudad de Pasaje, con mira a brindar servicios con calidad y calidez, sean oportunos, concisos y veraces, y ser los pioneros en atención remota con las diferentes áreas que reciben por parte de la Mecánica. Este proyecto se desarrolló en la Mecaniza Automotriz Espinoza, ubicada en el área Urbana de la ciudad de Pasaje, en la tercera entrada de la Gasolinera “Carmona”, ubicada en las coordenadas geográficas 25700 NORTE y 18175 ESTE en la Ciudad de Pasaje de la Provincia de El Oro.

V

Fuente:https://www.google.com.ec/maps/@-3.3353023,79.8149218,229m/data=!3m1!1e3 2.4 2.5

1.5 JUSTIFICACIÓN DE LA NECESIDAD DE LA INTERVENCIÓN

2.6

1.5.1. FUNDAMENTACIÓN DE LA PROPUESTA

Este proyecto centra su atención en las tecnologías de la información al servicio de los clientes, a quienes van dirigidas las acciones de mejora de acceso a la información sobre sus datos en el sistema, condición necesaria para que la empresa, como agentes de los ciudadanos, puedan ofertar atención de calidad.

V

Por ello, este sistema ha de orientarse también a las necesidades de los profesionales dotando al sistema de mecanismos ágiles y funcionales que faciliten su tarea y que al propio tiempo ofrezcan seguridad a los clientes y a los ciudadanos de que las actuaciones se realizan en un marco ético y jurídico compartido por todos los agentes. El reto que la movilidad de los clientes impone a estos sistemas hace necesaria la implantación de un sistema que facilite la extensión territorial de dichas funcionalidades al conjunto y permita a los profesionales la posibilidad de disponer de la información precisa cuando las necesidades de atención al cliente se producen fuera de la entidades desconcentradas en la que se ha generado esta información, y que facilite a los clientes el acceso a la misma información objetiva sobre su salud y al registro de los accesos realizados a sus datos, disponible en virtud de la obligada trazabilidad de la que este sistema de información debe ser dotado. Los servicios de la Mecánica Automotriz tienen que ser claros y oportunos, dirigidos a la población de la Ciudad de Pasaje. 2.7

1.6 DESCRIPCIÓN DEL PROYECTO

Este proyecto se idealizo en las diferentes necesidades e inconvenientes que tienen los clientes, como también los usuarios, en la atención recibida y brindad de la Mecánica Automotriz, y debido a la desactualización se los servicios.

Los diferentes servicios que brinda el taller mecánico son de beneficiosos para la ciudadanía, por ser los pilares fundamentales del bienestar en servicio al cliente dirigido a los clientes como base de turismo. Como parte

V

del estudio se identificó, que existen diferentes déficits para lograr la misión a la que se refiere el Gremio y de mecánicos y Anexos del Cantón Pasaje, su principal problema es la falta de automatización de cada cliente que recibe el taller, ya que no permite controlar su control de atención y poder realizar el respectivo seguimiento médico, de acuerdo a las atenciones recibidas anteriormente y los diagnósticos emitidos por los diferentes Por tal motivo se mantiene como propuesta principal la implementación y desarrollo de un software, que permita controlar y manejar el historial de cada cliente, con su respectiva base de datos, y conlleve a una mejor atención de calidad y calidez, con datos reales y concisos, para que los reciban los servicios de salud de una manera eficaz y mejore su calidad de atención, se estableció como propuesta de solución a esta problemática en los servicios de salud dentro de la Institución: “Análisis y definición de los requerimientos previo

al

desarrollo

informático

que

solucionara

los

inconvenientes de la falta de automatización en el departamento de administración”. Que beneficiara a la población en general tanto en las áreas urbanas como de las áreas rurales, dirigida a la salud como base del Turismo.

V

Especificación

de

requisitos

de

software Proyecto: Especificación de requerimientos de un sistema de software de facturación para la mecánica automotriz “Espinoza”. Revisión 001 Cabrera Torres Edinson Xavier

V

Espinoza Armijos Richard Andrés Mosquera Torres Luis Fernando

2015

Ficha del documento

Fecha

Revisi

Autor

Verificado dep. calidad.

ón 10-012016

0.1

Espinoza Richard Cabrera Edinson Mosquera Fernando

V

Mosquera Miguel

Documento validado por las partes en fecha: 29-01-2016 Por el cliente

Por la empresa suministradora

Fdo. D./ Dña Victor Espinoza

Fdo. D./Dña GLOBAL

V

V

Contenido Ficha del documento Contenido 1

Introducción 1.1

Propósito

1.2

Alcance

1.3

Personal involucrado

1.4

Definiciones, acrónimos y abreviaturas

1.5

Referencias

1.6

Resumen

2

Descripción general 2.1

Perspectiva del producto

2.2

Funcionalidad del producto

2.3

Características de los usuarios

2.4

Restricciones

2.5

Suposiciones y dependencias

2.6

Evolución previsible del sistema

3

Requisitos específicos 3.1

Requisitos comunes de los interfaces

3.1.1

Interfaces de usuario..........................................................................................................................8

3.1.2

Interfaces de hardware.......................................................................................................................8

3.1.3

Interfaces de software........................................................................................................................8

3.1.4

Interfaces de comunicación................................................................................................................8

3.2

Requisitos funcionales

3.2.1

Requisito funcional 1..........................................................................................................................9

3.2.2

Requisito funcional 2..........................................................................................................................9

3.2.3

Requisito funcional 3..........................................................................................................................9

3.2.4

Requisito funcional n..........................................................................................................................9

3.3

Requisitos no funcionales

1

3.3.1

Requisitos de rendimiento..................................................................................................................9

3.3.2

Seguridad...........................................................................................................................................9

3.3.3

Fiabilidad............................................................................................................................................9

3.3.4

Disponibilidad...................................................................................................................................10

3.3.5

Mantenibilidad..................................................................................................................................10

3.3.6

Portabilidad.......................................................................................................................................10

3.4 4

Otros requisitos Apéndices

2

2 Introducción La especificación de requerimientos de nuestro software “Sistema de Requerimientos está enfocado

de facturación de una mecánica automotriz”

a dar un sistema rápido

y eficaz además está

enfocado a utilizar la tecnología, este sistema funcionara con un propósito de que el usuario se sienta cómodo a la hora de facturar un servicio o producto dirigido a personas que tienen algún tipo de vehículo Este software podrá ser controlado

por el personal de taller

mecánico como el gerente, administrador o empleado. Sera solamente facturado los productos que sean utilizados en esta empresa, por medio de un inventario, y tendrá sus definiciones similares ya que los servicios a utilizar se requieren de productos únicamente que cuente el taller mecánico.

2.1 Propósito El propósito de nuestro sistema es que el usuario se sienta más cómodo a la hora de facturar los productos, así como también dar un mejor servicio a los clientes para que estos se sientan satisfechos por el servicio que se le brinda. Este sistema va dirigido para las personas que tengan algún tipo de vehículo o a las personas que sientan necesitar de este servicio.

2.2 Alcance Diseño desarrollo e implementación del sistema “Sistema de Requerimientos de Facturación de una Mecánica Automotriz” El sistema de facturación que funcionara en un entorno web que permitirá administrar y consultar la información de los clientes y el servicio de la mecánica automotriz .Este sistema dará apoyo a los siguientes procesos  Administrar facturas  Administrar clientes  Gestión de programación de actividades 3

 

Administrar usuario del sistema Generación de estadísticas El sistema – web permitirá una flexibilidad de acceso a la información en la programación de la Facturación, igualmente una actualización de la

misma.

Personal involucrado

Nombre Rol Categoría profesional Responsabilidades Información de contacto Aprobación

Edison Cabrera Programador Estudio Superior Codificar la Aplicación Ninguno

Nombre Rol Categoría profesional Responsabilidades Información de contacto Aprobación

Richard Espinoza Diseñador Grafico Estudio Superior Realizar las interfaces de prueba del Sistema Ninguno

Nombre Rol Categoría profesional Responsabilidades Información de contacto Aprobación

Luis Fernando Mosquera Seguimiento Estudio Superior Coordinar el proyecto y contacto con el cliente Ninguno

Nombre Rol Categoría profesional Responsabilidades Información de contacto Aprobación

Luis Miguel Mosquera Entregador Estudio Superior Coordinar el proyecto y contacto con el cliente Ninguno

NOMBRE: ROL: CATEGORIA PROFESIONAL:

4

2.3 Definiciones, acrónimos y abreviaturas 2.3.1 Del Negocio a.RESERVA: Por el cual el supervisor solicita un servicio para un proceso. b.FACTURA: Proceso por el cual una persona recibe por un servicio. c. PUBLICAR FACTURAS: Modifica información del sistema. d.CONSULTA

FACTURAS:

Proceso

en

el

que

brinda

información en el sistema. e.CANCELAR FACTURA: Proceso en el que se cancela una factura. f. PRECIO DEL SERVICIO: El cliente debe pagar por recibir un servicio. g.SUPERVISOR: Persona encargada de administrar un servicio. h.ADMINISTRADOR: Persona encargada del sistema. i. CLIENTE: Persona

que llega por necesidad de un

servicio. j. EMPLEADO: Persona responsable de brindar el servicio

2.3.2 Del Sistema a. Administrar: Acción de agregar, modificar, eliminar y consultar la información de un determinado objeto o persona. b. Visitante: Persona que navega o utiliza el SIS-WEB. c. Usuario: Persona que puede ingresar a la zona privada del SIS-WEB, a través de un proceso de autenticación utilizando nombre de usuario y contraseña. d. Rendimiento:

Referencia

al

resultado

deseado

efectivamente obtenido por cada unidad que realiza la 5

actividad, donde el término unidad puede referirse a un individuo, un equipo, un departamento o una sección de una organización. e. Permiso: Parámetro que especifica si su poseedor dispone de acceso a una determinada función del sistema o a una parte de la interfaz de usuario del sistema. f.

Rol: Es un conjunto de permisos que puede asignarse a un usuario.

g. Administrador del Sistema: Persona encargada de ofrecer el soporte técnico y operativo al SIS-WEB. h. Pruebas: Proceso mediante el cual se realizan actividades para verificar la óptima función del sistema.

2.3.3 De Tecnología a. Dominio: Nombre base que agrupa a un conjunto de equipos o dispositivos y que permite proporcionar nombres de equipo más fácilmente recordables en lugar de una dirección IP numérica, Ej: sis-web.com. b. Enlaces: una referencia en un documento de hipertexto a otro documento o recurso. c. Sistema de gestión de Base de Datos: Son un tipo de software muy específico, dedicado a servir de interfaz entre la base de datos, el usuario y las aplicaciones que la utilizan. d. Base de Datos: Es un conjunto de datos que pertenecen al mismo contexto almacenados sistemáticamente para su posterior uso. e. Aplicación: Es un programa informático diseñado para facilitar al usuario la realización de un determinado tipo de trabajo.

6

f.

Internet: Es un método de interconexión descentralizada de

redes

de

computadoras

implementado

en

un

conjunto de protocolos denominado TCP/IP. g. Encriptar: Ocultar el contenido de un mensaje mediante un proceso de codificación de manera tal que el acceso al contenido del mensaje sea restringido.

2.4 Referencias Referenc

Fech

ia

Titulo

Ruta

a

IEEE

Standard

Hppt://cic.puj.ed.co/wiki/lib/exel 17-12- Tania Mora 2015

IEEE 830 -

Autor

Luis Romo

1998

2.5 Resumen Este contenido muestra que podemos brindar un servicio eficaz y rápido, además de oportuno. El Sistema de Requerimientos tiene un solo propósito que es que el Usuario y Cliente se sientan más cómodos a la hora de Facturar los productos o servicios, implementaremos un excelente diseño desarrollo e implementación; para esto el personal involucrado estamos trabajando en cada detalle para que sea un trabajo excelente. Este documento estará organizado de manera puntual ya que tendrá categorías de ingreso diferentes al Sistema, tendrá un inventario general de los productos y servicios que pueden ofrecer, en si un software sofisticado y actualizad.

7

3 Descripción general 3.1 Perspectiva del producto El sistema será un producto diseñado para trabajar en entornos agradables, lo que permitirá su utilización de forma descentralizada, además trabajará de manera independiente por lo tanto no interactuará con otros sistemas.

3.2 Funcionalidad del producto El sistema SIS-WEB permitirá realizar las siguientes funciones:

a. Administración de Usuarios: El administrador del sistema podrá gestionar los usuarios (agregar, modificar, eliminar, buscar, listar).

b. Administración de Seminarios: El administrador del sistema podrá gestionar seminarios, y asignarles un coordinador de seminario para que lo administre.

c. Administración de Roles: El administrador del sistema gestionará los roles de usuarios del sistema, de igual forma asignará los roles a los usuarios.

d. Publicación de Información: El administrador del sistema actualizará la información general del Sistema.

e. Navegación: Proceso por el cual una persona podrá utilizar el Sistema.

3.3 Características de los usuarios Tipo de usuario Formación Habilidades Actividades

Administrador del Sistema

Tipo de usuario Formación Habilidades Actividades

Cajero

Codificador del Sistema. Actualizar y publicar la Actualización del software.

Administrar y contabilizar registros de dinero. Llevar un control correcto y administrativo de la Empresa.

8

Tipo de usuario Formación Habilidades Actividades

Gerente Administrar y contabilizar ingresos y salidas de dinero. Llevar el correcto control de la Administración de la Empresa.

3.4 Restricciones 3.4.1 Políticas Reguladoras La aplicación se desarrollará mediante software de licencia abierta por lo tanto no se deberá pagar por el uso de: servidor, Sistema de Gestión de base de datos y el lenguaje de programación, por lo tanto, la utilización de estos programas se hará mediante las políticas establecidas por este tipo de licenciamiento.

3.4.2 Limitaciones de Hardware Para esta aplicación será necesario un computador servidor en el cual se instalará el servidor y la aplicación.

3.4.3 Interfaces con Otras Aplicaciones. Debido a que el sistema no interactúa con otros sistemas y es autónomo no se desarrollaran interfaces con otras aplicaciones.

3.4.4 Funciones de Control. El sistema debe controlar los permisos que tiene cada usuario para su accesibilidad de una manera correcta, de tal forma que pueda acceder la información que le corresponde de acuerdo a su rol. Debe tener controles adecuados para la validación de datos, de igual manera la programación de las actividades específicas para cada seminario.

3.4.5 Requisitos del Lenguaje Todo el material que se realice para el usuario y la aplicación debe de estar en lenguaje español.

9

3.4.6 Requisitos de Fiabilidad La información correspondiente a la programación de los seminarios como la fecha, la hora, el sitio, cantidad de inscritos, ponente y los recursos deben estar ajustados a la realidad para evitar desorganización.

3.4.7 Credibilidad de la Aplicación Para garantizar una buena credibilidad el sistema deberá ser sometido a una serie de pruebas para establecer que se encuentra acorde a los requerimientos que se plasman en el documento en tanto a la consistencia de datos como al rendimiento de la aplicación, tales como tiempos de respuesta.

3.4.8 Consideraciones de Seguridad Cada usuario deberá autenticarse y su acceso verificado por una sola Terminal para su respectiva labor de acuerdo a lo que su rol especifique. Todas las claves de seguridad deberán estar seguras y en su defecto encriptadas en la base de datos para dar una buena seguridad al sistema y su información.

3.5 Suposiciones y dependencias Los requisitos descritos en este documento pueden cambiar, pues los procesos son dinámicos y por lo tanto cambia los requisitos del software, para lo cual es necesario que las fases de análisis y diseño estén bien documentadas y además definir una fase y metodología de mantenimiento del sistema. El sistema de información funciona independientemente, sin necesidades de comunicarse con otros sistemas externos, por lo que no hay dependencias respecto de otros sistemas.

3.6 Evolución previsible del sistema Ninguno

10

4 Requisitos específicos !!br0ken!!RF1 Número de requisito Permitir la autenticación de los usuarios Nombre de requisito ■ Requisito

Restricción

Tipo Actualizar la autenticación de los usuarios Fuente del requisito ■ Alta/Esencial

Media/Deseado

Baja/ Opcional

Prioridad del requisito

RF2 Número de requisito Permitir la gestión de Usuarios, clientes y socios Nombre de requisito ■ Requisito

Restricción

Tipo Crear, modificar y eliminar Fuente del requisito ■ Alta/Esencial Prioridad del requisito

RF3 Número de requisito Aperturas de créditos Nombre de requisito

11

Media/Deseado

Baja/ Opcional

Requisito

■ Restricción

Tipo Aprobar créditos a los Clientes Fuente del requisito Alta/Esencial

■ Media/Deseado

Baja/ Opcional

Prioridad del requisito

RFn Número de requisito Realizar Operaciones de Credito Nombre de requisito Requisito

■ Restricción

Tipo Aprobar créditos a los Clientes Fuente del requisito Alta/Esencial

■ Media/Deseado

Baja/ Opcional

Prioridad del requisito

4.1 Requisitos comunes de los interfaces 4.1.1 Interfaces de usuario Las interfaces de usuario están relacionadas con las pantallas, ventanas (formularios) que debe manipular el usuario para realizar una operación determinada. Dicha manipulación el usuario la realizará por medio del teclado y el Mouse (ratón). Es importante mencionar que las interfaces de usuario también abarcan las ayudas correspondientes en cada uno de los procesos que realice el sistema.

12

Las interfaces de usuario ayudarán al usuario final trabajando en un ambiente Form, por lo que se dichas interfaces incluirán: • Botones • Menús despegables • Mensajes informativos • Mensajes de error • Cuadros de diálogo • Formularios para el ingreso, modificación, actualización y eliminación de datos. Así como para las operaciones y las ayudas que se mencionó anteriormente. • Otros

A continuación se muestra una previa de lo que será las interfaces de usuario. El usuario previamente debe tener su cuenta de usuario en el sistema para poder acceder.

En caso de que no ingrese correctamente el USUARIO o el PASSWORD se desplegara un mensaje de datos incorrectos. Como a continuación se muestra.

13

4.1.2 Interfaces de hardware La pantalla del monitor. - el software deberá mostrar información al usuario a través de la pantalla del monitor. Ratón. - el software debe interactuar con el movimiento del ratón y los botones del ratón. El ratón se activan las zonas de entrada de datos, botones de comando y seleccione las opciones de los menús. Teclado. - el software deberán interactuar con las pulsaciones del teclado. El teclado de entrada de datos en el área activa de la base de datos. Impresora. - el software imprimirá los reportes en la impresora instalada.

4.1.3 Interfaces de software Ninguno

4.1.4 Interfaces de comunicación La pantalla del monitor. - el software deberá mostrar información al usuario a través de la pantalla del monitor. Ratón. - el software debe interactuar con el movimiento del ratón y los botones del ratón. El ratón se activa las zonas de entrada de datos, botones de comando y seleccione las opciones de los menús.

14

Teclado. - el software deberá interactuar con las pulsaciones del teclado. El teclado de entrada de datos en el área activa de la base de datos. Impresora. - el software imprimirá los reportes en la impresora instalada. La interfaz de comunicación entre el servidor de base de datos será en Access y la aplicación desarrollada en VISUAL BASIC.

4.2 Requisitos funcionales 4.2.1 Requisito funcional 1 Número

de RF1

requisito Nombre

de Permitir la autenticación de los usuarios.

requisito Tipo

Requisito

Fuente

Restricción

del BD Tabla: Usuario Campos: user y password

requisito Prioridad

del

Alta/Esencial

requisito

Media/Desead o

Baja/ Opcional

INTRODUCCION El sistema debe permitir el ingreso del nombre y password del usuario para realizar las diferentes funciones que tendrá cada uno. ENTRADAS Cedula, Nombres, Apellidos, Contraseña, Tipo de Usuario (Técnico, Cajero, Gerente). PROCESOS El sistema pedirá la correspondiente identificación como administrador. Nos ubicamos en la parte de Administrar del menú principal y escogemos Usuario El sistema pedirá los correspondientes datos del nuevo usuario luego verificara que no haya espacios en blanco, en el caso de ningún error guardara los datos del nuevo usuario.

15

SALIDAS Las salidas van dirigidas a: Administrador (Gerente). Mensaje de error en el caso de no haber llenado algún campo. Mensaje de error en el caso de ingresar un numero de cedula ya existente en la base de datos. Mensaje de error en casos de ingresar incorrectamente los datos es decir que el formato de los datos sea incorrecto.

4.2.2 Requisito funcional 2 Número

de RF2

requisito Nombre

de Permitir la gestión (crear, modificar, eliminar) de

requisito

usuarios, clientes y socios.

Tipo

Requisito

Fuente

Restricción

del BD Tabla: Usuario, Clientes, Socios

requisito Prioridad

del

Alta/Esencial

requisito

Media/Desead o

Baja/ Opcional

INTRODUCCION El sistema debe permitir gestionar es decir crear, modificar y eliminar las cuentas de usuarios, clientes y socios. ENTRADAS Cedula, Nombres, Apellidos, Tipo de Usuario (Técnico, Cajero, Gerente), Dirección, Teléfono. PROCESOS Para cumplir con este requerimiento se le presentara una sola pantalla donde el sistema pedirá la correspondiente identificación como administrador. Nos ubicamos en la parte de Administrar del menú principal y escogemos Usuario El sistema pedirá los correspondientes datos del nuevo usuario, cliente o socio luego verificara que no haya espacios en blanco, en el caso de ningún error

16

guardara los datos del nuevo usuario. En este mismo formulario podrá crear, modificar y guardar. SALIDAS Las salidas van dirigidas a: Administrador (Gerente). Mensaje de error en el caso de no haber llenado algún campo. Mensaje de error en el caso de ingresar un numero de cedula ya existente o mal ingresada en la base de datos. Mensaje de error en casos de ingresar incorrectamente los datos es decir que el formato de los datos sea incorrecto. Mensaje de error al eliminar una cuenta, ya que no se permite eliminaciones en cascada.

4.2.3 Requisito funcional 3 Número

de RF3

requisito Nombre

de Apertura cuentas de Crédito

requisito Tipo

Requisito

Fuente

Restricción

del BD Tabla: Aprobar Créditos a los Clientes

requisito Prioridad

del

Alta/Esencial

requisito

Media/Desead o

Baja/ Opcional

INTRODUCCION El sistema debe permitir gestionar las libretas de ahorro es decir crear, modificar y eliminar las cuentas de ahorro. ENTRADAS Número de cuenta, Cedula, Nombres, Apellidos, Dirección, Teléfono. PROCESOS Para cumplir con este requerimiento se le presentará una sola pantalla donde el sistema pedirá la correspondiente identificación como administrador para efectuar la tarea. Nos ubicamos en la parte de Administrar cuentas de ahorro.

17

El sistema pedirá los correspondientes datos al cliente o socio para la apertura de la libreta, el mismo que verificará los datos ingresados a la base de datos. En el caso de modificar los datos tiene que hacerlo mediante el número de cuenta. No se podrá eliminar las cuentas de ahorro, simplemente en caso de que así lo desee a la cuenta de ahorro se le pasara a un estado inactivo. SALIDAS Las salidas van dirigidas a: Administrador (Gerente), Cajero. Mensaje de error en el caso de no haber llenado algún campo. Mensaje de error en el caso de ingresar un número de cuenta ya existente o mal ingresada en la base de datos. Mensaje de error en casos de ingresar incorrectamente los datos es decir que el formato de los datos sea incorrecto. Mensaje de error al eliminar una cuenta de ahorro (libreta), ya que no se permite eliminaciones en cascada.

4.2.4 Requisito funcional n Número

de RFn

requisito Nombre

de Realizar operaciones de créditos.

requisito Tipo

Requisito

Fuente

Restricción

del BD Tabla: Cuenta, Ahorro, CertificadoAportacion,

requisito Prioridad

Creditos del

Alta/Esencial

requisito

Media/Desead o

Baja/ Opcional

INTRODUCCION El sistema debe permitir realizar las operaciones de créditos a los Clientes.

18

ENTRADAS Número de cuenta, Cedula, Valor dinero. PROCESOS Para cumplir con este requerimiento se le presentará una sola pantalla donde el sistema pedirá la correspondiente identificación como administrador para efectuar la tarea. Nos ubicamos en la parte de Administrar “Créditos” Para realizar esta operación debe ingresar el número de cuenta y la cantidad a retirar, y dicha operación será registrada en la base de datos. SALIDAS Las salidas van dirigidas a: Administrador (Gerente), Cajero. Mensaje de aviso: operaciones efectuadas satisfactoriamente. Mensaje de error: en el caso de no haber llenado algún campo. Mensaje de error: en casos de ingresar incorrectamente los datos es decir que el formato de los datos sea incorrecto. Mensaje de error: en el caso de que no tenga suficiente saldo para efectuar dicho retiro.

4.3 Requisitos no funcionales 4.3.1 Requisitos de rendimiento La infraestructura de red, así como sus terminales deben cumplir con normas según la IEEE en la forma de conexión a los equipos, para tener tiempos de respuesta mínimos. 

Numero de terminales a manejar:

Se contará con un servidor de base de datos en la matriz de la cooperativa. 

Número de usuarios simultáneos:

El número de usuarios que interactuaran simultáneamente con nuestro sistema es de 3 usuarios.

19



Número de transacciones a manejar dentro de ciertos periodos de tiempo:

Se estima que se manejará alrededor 10 transacciones durante el día, tomando en cuenta que la cajera realiza aproximadamente 20 operaciones diarias, como ahorros y retiros y el resto lo hace el gerente y la secretaria tareas propias. El servidor de base de datos, deberá tener un respaldo apropiado, así como personal técnico listo para cualquier eventualidad.

4.3.2 Seguridad La seguridad del sistema es por: Uso de contraseñas para cada usuario (administrador, cajera, oficial de crédito). Esto permitirá que tengan acceso al sistema solo las personas que tienen autorización. Registros de ingreso al sistema. Creación de roles y asignarlos a cada usuario dependiendo su funcionalidad.

4.3.3 Fiabilidad Es uno de los factores que dará confianza al cliente, para lo cual el sistema está controlando todo tipo de transacción y está apto a responder todo tipo de incidente.

4.3.4 Disponibilidad El sistema ha sido desarrollado tomando en cuenta las necesidades, requerimientos, reglas, política, misión, objetivos etc. De la cooperativa, por lo que se encuentra disponible el 80% del tiempo del día tomando en cuenta que el día tiene 24 horas; mientras que el 20% del tiempo es para tareas administrativas sobre el sistema.

4.3.5 Mantenibilidad El sistema cuenta con características parametrizables lo que permitirá futuros mantenimientos. Es decir, cada tres meses se va a realizar un mantenimiento preventivo, encargado de hacerlo están los desarrolladores.

20

Se realizará el mantenimiento dos veces sin ningún recargo económico, pasados estas dos revisiones tendrán costos adicionales.

4.3.6 Portabilidad Una de las ventajas de utilizar herramientas y lenguajes libres estamos garantizando la portabilidad. De esta manera: 99.9% es portable la aplicación por el simple hecho de utilizar el lenguaje y plataforma VISUAL BASIC. 99% es portable la base de datos, ACCESS es decir puedo tenerlo en Windows o Linux.

4.4 Otros requisitos PROPIEDAD INTELECTUAL El costo de licencia de producto será valorado por el número de usuarios que se conecten.

5 Apéndices 

Este Sistema no puede ser Plagiado.



Este Software no podrá ser removido a otra Máquina, más que no sea en la que se instaló.

21

3

CAPÍTULO II

3.1

2.1. MARCO TEÓRICO CONCEPTUAL

3.2

2.1.1. DEFINICIÓN DE REQUERIMIENTOS Y DE ANÁLISIS DE REQUERIMIENTOS.

Requerimientos: Los requerimientos especifican qué es lo que el sistema debe hacer (sus funciones) y sus propiedades esenciales y deseables. La captura de los requerimientos tiene como objetivo principal la comprensión de lo que los clientes y los usuarios esperan que haga el sistema. Un requerimiento expresa el propósito del sistema sin considerar como se va a implantar. En otras palabras, los requerimientos identifican el qué del sistema, mientras que el diseño establece el cómo del sistema. La captura y el análisis de los requerimientos del sistema es una de las fases más importantes para que el proyecto tenga éxito. Como regla de modo empírico, el costo de reparar un error se incrementa en un factor de diez de una fase de desarrollo a la siguiente, por lo tanto, la preparación de una especificación adecuada de requerimientos reduce los costos y el riesgo general asociado con el desarrollo. Análisis de requerimientos: Es el conjunto de técnicas y procedimientos que nos permiten conocer los elementos necesarios para definir un proyecto de software. Es una tarea de ingeniería del software que permite especificar las características operacionales del software, indicar la interfaz del software con otros elementos del sistema y establecer las restricciones que debe cumplir el software.

22

La especificación de requerimientos suministra al técnico y al cliente, los medios para valorar el cumplimiento de resultados, procedimientos y datos, una vez que se haya construido. La tarea de análisis de los requerimientos es un proceso de descubrimiento y refinamiento, el cliente y el desarrollador tienen un papel activo en la ingeniería de requerimientos de software. El cliente intenta plantear un sistema que en muchas ocasiones es confuso para él, sin embargo, es necesario que describa los datos, que especifique las funciones y el comportamiento del sistema que desea. El objetivo es que el desarrollador actúe como un negociador, un interrogador, un consultor, o sea, como persona que consulta y propone para resolver las necesidades del cliente. El análisis de requerimientos proporciona una vía para que los clientes y lo desarrolladores lleguen a un acuerdo sobre lo que debe hacer el sistema. La especificación, producto de este análisis proporciona las pautas a seguir a los diseñadores del sistema. “La carencia de buenos requisitos ha sido la causa del fracaso de proyectos con presupuestos de millones de dólares, ha impedido el desarrollo productivo, y ha sido el mayor contribuyente de los costes elevados del mantenimiento del software”

23

En esta parte se realiza un análisis de los diferentes modelos de ciclos de vida de desarrollo de sistemas para determinar, en base a las características propias del sistema a desarrollar y a las características específicas de cada modelo, el camino más adecuado a seguir, ya que lo que se busca al guiarse con una metodología es corrección y control en cada etapa del desarrollo de un sistema. Lo que permite una forma sistemática para poder obtener un producto correcto y libre de errores. Además, se efectúa un análisis entre los enfoques estructurado y orientado a objetos para estipular el enfoque más adecuado para el proyecto.

3.3

2.2.

SELECCIÓN DEL CICLO DE VIDA DE DESARROLLO DE

PROYECTOS El proyecto se desarrollará en base al MODELO DE CICLO DE VIDA EN CASCADA PURA, ya que es el que mejor se adapta al sistema a desarrollar. Esto se ha determinado en base a una evaluación técnica, la cual puede verse con más detalle en el capítulo 5, apartado 5.1, del documento de

24

Anteproyecto ubicado en la carpeta Documentos del directorio raíz del DVD adjunto.

Las etapas del modelo de ciclo de vida en cascada pura son: Análisis, Diseño, Implementación, Pruebas, Instalación y Aceptación.

3.4 3.5

2.3 ELECCIÓN DEL ENFOQUE DE DESARROLLO DEL SISTEMA

Una vez seleccionado un ciclo de vida para el desarrollo de sistemas, es necesario adoptar en enfoque de desarrollo de sistemas a través de un patrón o modelo de desarrollo. Para poder seleccionar un enfoque de desarrollo se presenta, primeramente, una evaluación técnica entre el enfoque estructurado y el enfoque orientado a objetos.

25

El enfoque a utilizar por el grupo de trabajo para el desarrollo del proyecto será el enfoque Orientado a Objetos, considerando las ventajas que este enfoque ofrece con respecto al Estructurado. Dos de las más importantes son:  Permite la flexibilidad en cuanto a cambios de los requerimientos por parte de los usuarios.  Permite un diálogo común entre desarrolladores (equipo de trabajo) y usuarios. Para modelar sistemas orientados a objetos se utiliza el estándar de la industria, es decir UML (Lenguaje de Modelado Unificado), el cual proporciona diagramas que permiten visualizar el desarrollo de un sistema orientado a objetos, además permite especificar las características de un sistema, construir a partir de los modelos especificados y documentar a través de sus propios elementos gráficos 3.6

2.4 FASES DEL PROYECTO

En cada una de las fases del modelo de ciclo de vida, se establecen una serie de objetivos, tareas, actividades, recursos y herramientas que las caracterizan. 3.6.1 2.4.1 FASE I: INVESTIGACIÓN PRELIMINAR En esta etapa del ciclo de vida de desarrollo de proyectos, se realiza un acercamiento entre los miembros del equipo de trabajo y los usuarios, con el objetivo de obtener toda la información necesaria para determinar si el proyecto es factible desde 3 puntos de vista: técnico, operativo y económico. Este acercamiento sirve también para conocer la situación actual, los problemas y oportunidades de mejora en el área de Hospitalización. A continuación, se describe la forma en la cual se procederá a realizar esta fase:

26

 En primer lugar, se realizarán visitas al área de la mecánica y se llevarán a cabo reuniones con el gerente la empresa y del Departamento de Administración, donde se realizarán entrevistas, encuestas y recolección de documentos bibliográficos referentes al área del taller mecánico.  Se realizará un análisis de la situación actual utilizando la técnica del enfoque de sistemas.  Se realizará un estudio técnico para evaluar si la solución es factible desde el punto de vista técnico, operativo y económico. Producto final: el resultado más importante en la fase de investigación preliminar es el estudio de factibilidad el cual incluye la factibilidad técnica, económica y operativa. 3.6.2 2.4.2. FASE II: DETERMINACIÓN DE REQUERIMIENTOS El fin que se persigue en esta fase es estudiar el negocio, así como todos aquellos elementos que formarán parte en el desarrollo del proyecto, desde el punto de vista de los usuarios y del negocio determinando de esta forma los requerimientos informáticos, operativos, técnicos, de desarrollo e implementación. A continuación, se detalla la forma en que se abordará esta fase:  Se definirá con los usuarios finales los requerimientos informáticos, operativos, técnicos, de desarrollo e implementación. Para ello se recolectará

la

información

necesaria

sobre

necesidades

de

información, las condiciones medioambientales en las que debe operar el sistema, los recursos técnicos y tecnológicos necesarios para desarrollar y echar a andar el sistema.  Se validarán todos los requerimientos con los usuarios, esto para evitar conflictos con sus intereses.  laborar el documento de especificación de requerimientos.

27

Producto final: al terminar la fase de determinación de requerimientos se obtendrá

un

documento

técnico

con

las

especificaciones

de

los

requerimientos para el desarrollo del Sistema de Información para el área de Hospitalización en el Hospital Nacional Rosales. 3.6.3 2.4.3. FASE III: ANÁLISIS En esta fase se determinan los elementos que intervienen en el sistema a desarrollar, su estructura, relaciones, evolución temporal y funcionalidades. Se tendrá una descripción clara de qué producto se va construir, qué funcionalidades aportará y qué comportamiento tendrá. A continuación, se detallan las actividades a llevarse a cabo en esta fase:  Analizar las necesidades propias del sistema utilizando diagramas UML. Dentro de esta actividad también se crea el Modelo de Dominio que se presenta como uno o más diagramas de clases, éste será tomado como el punto de partida para el diseño del sistema. Además, se crea el diccionario de datos, en el cual se describen los atributos de cada clase.  Elaboración del documento análisis. Producto final: Documento que contiene el análisis de las necesidades del sistema representado a través de los diagramas UML. 3.6.4 2.4.4 FASE IV: DISEÑO En esta fase se diseña el sistema de información que cumpla con todos los requerimientos encontrados en las fases anteriores. Se definen los estándares para crear los diseños de base de datos, interfaces de usuario de entrada, salida, alertas y mensajes. A continuación, se detallan las actividades a llevarse a cabo en esta fase:  Definición de los estándares de diseño. 28

 Diseño de la base de datos.  Diseño de las interfaces de usuario.  Elaboración del documento. Producto final: Documento que contiene el diseño de sistema que satisface las necesidades del usuario. 3.6.5 2.4.5 FASE V: CONSTRUCCIÓN En esta fase se desarrolla el software necesario llevando el diseño de la etapa anterior a un lenguaje de programación de alto nivel. A continuación, se detallan las actividades a llevarse a cabo en esta fase:  Definición de estándares de programación.  Codificación y documentación del código fuente.  Programación de la base de datos: procedimientos almacenados y funciones.ca / Producto final: En esta fase se obtiene el sistema informático funcionando de forma correcta.

3.7

MARCO TEÓRICO CONTEXUAL

3.7.1 RESEÑA HISTÓRICA Pasaje, 1970 Aproximadamente en el año 1970, el gerente de la Mecánica Automotriz Espinoza, comenzaría sus primeros pasos en su carrera profesional y que en esos años comienza su aprendizaje en la rama Automotriz de vehículos a diésel. Pasaje, 1980

29

Años después de aprendizaje, en el año de 1980 se independizaría crearía su propio taller Mecánico y dejaba de ser oficial asistente, sus primeros meses fueron fundamentales para ir creciendo en su trayectoria, teniendo ubicado primeramente en las Calles Eloy Alfaro entre Machala y 9 de octubre. Aproximadamente en el año 1980, el gerente general Sr. Víctor Espinoza Bustamante contrajo Matrimonio con la Sra. María Armijos y comenzaría ahí el trabajo en grupo ya que la esposa durante toda su vida desde que se unió ha servido como apoyo fundamental a su entrañable esposo, en 1981 nacería su primogénito, y esto requeriría de más esfuerzo en su trabajo para darle un buen hogar a su familia, luego de esto cambiarían de lugar de trabajo a un lugar más amplio ubicado en la Av. Quito diagonal al Hospital Civil “San Vicente de Paul”. Pasaje, 1989 Al pasar los años, con sus ahorros guardados deciden construir su propio hogar en el año 1989 ubicada en la Ciudadela. La Francisca, en 1990 nacería su segundo hijo y su hogar propio entraría en funcionamiento. En el mismo domicilio había instalado lo necesario para que funcione su taller mecánico, con espacio más amplio y con servicios de primera necesidad, en este lugar se encuentra hasta la actualidad y con los años, la empresa sigue de pie con el mismo entusiasmo del principio

Un dato interesante digno de anotarse, fue la creación de su hogar propio con su empresa y esta seria así: 1. El negocio será de concreto de 1 piso, sobre una plataforma de una y media vara de alto, el lecho del terreno de cemento, lo que podrá servir para su taller mecánico. 2. La altura total del taller será de 4.5 m. desde el nivel del suelo. 3. Las necesidades son las siguientes:

30

- Taller para vehículos, con capacidad para 5; - Zaguán, portería; - Departamento para Archivo; - Departamento para Herramientas; - Una sala de espera para 4 personas; - Los baños: un excusado; 4. Que el taller lleve las respectivas galerías en los 3 frentes. 5. Que tanga la suficiente profusión de ventilación. De esta manera de lograría Cristalizar su deseo de tener su propia familia con 2 hijos, su hogar propio y su Mecanica Automotriz en el mismo domicilio.

31

3.7.2 MISIÓN

Conservar los autos de nuestros clientes en un estado de operación eficiente y seguro, superando las expectativas de nuestros consumidores en el menor tiempo posible Para nosotros usted y su vehículo son lo más importante. 3.7.3 VISIÓN Establecer un modelo de liderazgo en el mantenimiento preventivo y correctivo de vehículos automotores. - Mantener un crecimiento continuo basado en la satisfacción del cliente. - Mejorar la calidad de vida de nuestros clientes reduciendo el tiempo invertido en mantenimiento de su vehículo. Conservar los activos de nuestros clientes.

4

32

4.1.1 OBJETIVOS

4.1.1.1 OBJETIVO GENERAL



Incrementar la eficiencia, eficacia y calidad de las actividades operativas de la Mecánica Automotriz “Espinoza”.

1.2.4.1.

OBJETIVOS ESPECÌFICOS  Establecer un modelo de liderazgo en el mantenimiento preventivo y correctivo de vehículos automotores.  Mantener un crecimiento continuo basado en la satisfacción del cliente. – Mejorar la calidad de vida de nuestros clientes reduciendo el tiempo invertido en mantenimiento de su vehículo.  Conservar los activos de nuestros clientes.

4.2

1.2. 5 FODA

4.2.1 1.2.51.1. Fortalezas   

El personal está capacitado. El personal está comprometido con ofrecer un buen servicio. El sueldo del personal es bueno y por ello está motivado.

4.2.2 1.2.51.2. Debilidades:

 

No hay suficiente personal para atender a todos los clientes. El personal no tiene la capacitación suficiente para dar un buen servicio.

 

El personal no tiene buena actitud de servicio. El sueldo es bajo y el personal no está dispuesto a dar más tiempo de su horario.

33

1.2.51.3. Oportunidades:



Cada vez hay más automóviles y por lo tanto más oportunidad de tener clientes.

  

El costo de reparación en las agencias es caro. Hay pocos talleres mecánicos por la zona. El lugar en el que se encuentra, pasan muchos autos.

34

5

1.1.

CAPITULO III

DURACIÓN DEL PROYECTO

El tiempo de ejecución del proyecto, fue estimado desde el momento de su aprobación por parte del tutor de la asignatura de análisis en sistemas del Instituto Superior Tecnológico “José Ochoa León”, lo cual corresponde al mes de septiembre, hasta el mes de febrero 4, 2016 donde se entregaremos los resultados del mismo, por lo cual todo el proceso de ejecución del proyecto fue de cinco meses.

El proceso de levantamiento de información bibliográfica y análisis de la implementación del software de control de las actividades de los estudiantes durante las horas de clases, fue elaborado durante en los meses de diciembre y enero; posteriormente se realizaron los estudios para lograr justificar la implementación del mismo.

35

1.2.

DESCRIPCIÓN DETALLADA DE LAS ACTIVIDADES

ACTIVIDAD

PERIODO

DE RESPONSABLES

EJECUCIÓN 1.Diseño

y

planificación

RESULTADO ALACANZADO

del 15/09/2015 - 30/11/2015

Richard Espinoza

proyecto

Documento

físico

del

proyecto.

1.1.Aprobación del proyecto

15/09/2015

– Tutor de asignatura

Proyecto aprobado

– Edinson Cabrera

Fundamentación

30/09/2015 1.2. Levantamiento de información bibliográfica acerca del software a implementarse

30/11/2015 04/01/2016

teórica

estructurada.

2. Levantamiento de información para

el

requerimiento

de

la

implementación de un software de control de

actividades de los

30/11/2015

– Fernando Mosquera

Estudio realizado

– Miguel Mosquera

Estudio realizado

04/01/2016

estudiantes. 2.1. Estudio de aceptación del requerimiento

de

la

implementación del sistema de control de

actividades de los 30/11/2015

estudiantes dentro del laboratorio 04/01/2016 de computación. 2.1.1.

Socialización

de

los

resultados obtenidos, a través del estudio de campo.

3.Elaboracion del informe final

Justificación del proyecto 30/11/2015

– Richard Espinoza

aceptada.

04/01/2016

30/11/2015 02/02/2016

– Richard Espinoza

Documento final de grado terminado

Elaborado por: Richard Espinoza, Edinson Cabrera, Fernando Mosquera y Miguel Mosquera.

1.3.

CRONOGRAMA DE EJECUCIÓN DE ACTIVIDADES CRONOGRAMA POR OBJETIVOS Y ACTIVIDADES COMPONENTES,

TIEMPO

ACTIVIDADES Y

ESTIMADO

SUBACTIVIDADES

RESPONS

RECURSOS

ABLES

NECESARIOS

DES

HA

COMPONENTE 1: Elaboración

DE 21/09

STA 02/0

Richard

Equipos de

del proyecto

/2015

2/20

Espinoza

oficina

ACTIVIDAD 1.1: Socializar el

24/09

16 24/0

Richard

Equipos de

proyecto

/2015

9/20

Espinoza

cómputo

15 Subactividad 1.1.1: Reuniones sobre planteamiento de estrategias para la ejecución del

Richard 24/09

04/0

/2015

1/20

información referente al proyecto. ACTIVIDAD 1.2: Determinar el análisis del requerimiento del sistema a implementar.

Aula de clases del ITSJOL

16

proyecto. Levantamiento de

presupuesto requerido para el

Espinoza

Edinson 15/04

20/0

/2015

4/20

materiales de

15

oficina

Cabrera

Equipos y

COMPONENTE 2: Análisis del requerimiento para la implementación del software

Edinson 21/09

15/1

/2015

2/20

oficina y equipos

15

de computo

Actividad 1: Aplicación de cuestionario, con el personal que labora en la Mecanica

18/0

/2016

1/20

Mosquera

Equipos de cómputo

16 Miguel

Equipos de

Mosquera

cómputo

16 03/0

Richard

Equipos de

2/20

Espinoza

cómputo y

18/01

18/0

/2016

1/20

Elaboración del informe final del

01/02

proyecto

/2016

Mecanica Automotriz “Espinoza”

Materiales de

Fernando 18/01

Automotriz “Espinoza” Actividad 2: Aplicación del cuestionario a los clientes de la

Cabrera

16

materiales de

Presentación del informe final del

04/02

04/0

Edinson

oficina Documento en

proyecto

/2016

2/20

Cabrera

físico

16

1.4.

RESULTADOS ALCANZADOS

1.4.1. FUNCIONAMIENTO DEL SISTEMA Permitirá comprender de una mejor manera, como el sistema propuesto ayudará a satisfacer las necesidades que presentes.  Prestaciones: La información de los clientes podrá ser accesada en cualquier momento, lo que facilitará el acceso a la información del cliente y a la relacionada con la productividad del área.  Información: El sistema contará con la disponibilidad y acceso oportuno de la información de los clientes y de productividad del área del taller mecánico, permitiendo realizar los procesos y procedimientos de forma rápida, al contar con la información oportuna y precisa. Además, se garantizará que la información obtenida será proporcionada de acuerdo a las necesidades y a los niveles de acceso de cada uno de los usuarios del sistema.  Economía: La mecanización de los procesos y procedimientos del área proporcionará grandes ahorros en los tiempos que se invierten tanto para el registro como para la consolidación de la información, facilitando de esta manera, las tareas que realiza el personal de la Mecánica. Este ahorro de tiempo se traduce en dinero, ya que incrementa la productividad de cada persona en el área.  Control: El control del acceso de los usuarios (Gerente y Administrador) y la validación de los datos ingresados al sistema, ayudará a garantizar que la información que se obtenga sea veraz y presentada de acuerdo a las necesidades y niveles de usuario, para que esta información no sea manipulada o utilizada para fines distintos a las normas y ética establecida para la información de los cientes, ya que la información debe ser protegida

y libre de cualquier divulgación. Además de esto se presentará información que apoye a la toma de decisiones basada en datos fidedignos del área.  Eficacia: Con la obtención de información veraz y oportuna se agilizarán los procesos y se tendrá un mejor punto de vista para la toma de decisiones, el cual encaminará a la distribución y uso más adecuados de los recursos con que cuenta la Mecánica Automotriz “Espinoza”, obteniendo un mayor rendimiento en los procesos y procedimientos que se realizan.  Servicios: El sistema proporcionará información para los diversos niveles jerárquicos, con el objetivo de satisfacer las necesidades de información de los usuarios. Esta información será precisa, oportuna, clara, flexible y veraz  Ingreso de clientes en el Sistema de la Mecánica: Con el uso del sistema se agilizará el ingreso de los clientes, ya que la información personal del cliente no tendrá que ser escrita en los diferentes formularios para poder realizar el ingreso, ya que esto se ejecutará de forma automática y el personal solo tendrá que verificar que todos los documentos estén completos.  Altas: El sistema llevará el control de las altas, permitiendo tener el control de los días que están disponibles, para que esto pueda ser notificado inmediatamente al personal competente.  Consolidación de datos: El sistema

proporcionará

la

información

consolidada del área de la Mecánica, pudiendo obtener la información de forma rápida y en el momento que se requiera, ahorrándoles al personal el tiempo y esfuerzo en la elaboración de los consolidados del área.

6 6.1

3.5. CONCLUSIONES Y RECOMENDACIONES 3.5.1. CONCLUSIONES

Como en un principio del proyecto se estableció realizar el software con una base de datos, al momento de implementar el modulo FACTURACION PARA LA MECANICA AUTOMOTRIZ “ESPINOZA” se tropezó con la falta de informacion, para solucionar este problema acudimos a visitas e inspecciones. El prototipo desarrollado aún necesita re-finamiento que ejecutara en las siguientes iteraciones del proyecto, actualmente cumple con un 80% de respuesta a los requisitos obtenidos con la ingeniería de requerimientos, en lo que respecta a venta de boletos, el modelo de componentes todavía está sujeto a cambios y mejoras, así como toda la arquitectura del proyecto, pero se logró generar un aplicativo que era lo que se esperaba.

1.5.2. RECOMENDACIONES

La factura electrónica en nuestro país se encuentra en un periodo de adaptación, aplicándose su obligatoriedad en forma segmentada para que en 2018 absolutamente todas las empresas, de todos los tamaños y de cualquier lugar del país, deban migrar a este sistema. Pero, aunque sea opcional no son pocas las empresas que han decidido utilizar este sistema por decisión propia. En este caso nuestro software fue elaborado por un grupo de jóvenes estudiantes para brindar mejor servicio a los fieles clientes de la Mecanica Automotriz “Espinoza”. Aún trabajan con la factura de papel, y desea cambiar a este nuevo sistema, a continuación, le entregamos algunas recomendaciones que debe tener en cuenta para que este cambio sea lo más tranquilo y eficaz.

6.2

3.6. BIBLIOGRAFÍA



América Latina: Aspectos conceptuales de los censos del 2000 (LC/L.1204P), N° de venta: S.99.II.G.9 (US$ 10.00), 1999.



Manual de identificación, formulación y evaluación de proyectos de desarrollo rural (LC/L.1267-P; LC/IP/L.163), N° de venta: S.99.II.G.56 (US$ 10.00), 1999.



Control de gestión y evaluación de resultados en la gerencia pública (LC/L.1242-P; LC/IP/L.164), N° de venta: S.99.II.G.25 (US$ 10.00), 1999.



Metodología de evaluación de proyectos de viviendas sociales (LC/L.1266P; LC/IP/L.166), N° de venta: S.99.II.G.42 (US$ 10.00), 1999.



Política fiscal y entorno macroeconómico (LC/L.1269-P; LC/IP/L.168), en prensa. N° de venta: S.99.II.G.25 (US$ 10.00), 2000.



Manual para la preparación del cuestionario sobre medidas que afectan al comercio de servicios en el hemisferio (LC/L.1296-P), N° de venta: S.99.II.G.57 (US$ 10.00), 1999.



Material docente sobre gestión y control de proyectos (LC/L.1321-P; LC/IP/L.174), N° de venta: S.99.II.G.87 (US$ 10.00), 2000.



Curso a distancia sobre formulación de proyectos de información (LC/L.1310-P), N° de venta: S.99.II.G.44 (US$ 10.00), 2000.



Manual de cuentas trimestrales, Oficina de Estadísticas de la Unión Europea (EUROSESTAT) (LC/L.1379-P, N° de venta: S.99.II.G.52 (US$ 10.00), 2000.

6.3

ANEXOS

6.4

ANEXO 1. ÁRBOL DE PROBLEMAS

PERIODO(AÑOS)

SALDO INVERSIÓN

FLUJO DE CAJA

RENTABILIDAD EXIGIDA

RECUPERACIÓN INVERSIÓN

1 2 3 4 5 6 7 8 9 10

$36.718,34 $22.097,93 $2.852,37 -$22.167,22 -$54.395,26 -$108.007,15 -$172.859,59 -$255.165,97 -$359.303,31 -$490.743,30

$23.802,46 $24.771,53 $25.732,86 $26.684,76 $40.009,43 $37.843,41 $39.079,89 $40.328,74 $41.590,08 $67.571,94

$9.182,05 $5.525,96 $713,28 -$5.543,29 -$13.602,46 -$27.009,03 -$43.226,48 -$63.808,60 -$89.849,91 -$122.718,72

$14.620,41 $19.245,56 $25.019,58 $32.228,04 $53.611,89 $64.852,44 $82.306,38 $104.137,34 $131.439,99 $190.290,66

6.5

ANEXO 2. ÁRBOL DE OBJETIVOS