ESPECIFICACIÓN DE REQUISITOS DEL SISTEMA

EN

SISTEMA DE GESTIÓN RTO

ENVIADO A:- ENVIADO POR:-

VIJAY MOHAN SHRIMAL RAKESHYADAV
(Profesor asociado) (CS-A/2ndaño)
(Departamento de CSE)
2

Índice

Nº PARTICULAR NÚMERO DE PÁGINA

1. Introducción al proyecto 4
1.1 Propósito 4-5
1.2 Alcance 5
1.3 Beneficios 5
1.4 Requisito funcional 6-7

2. Descripción General 7
2.1 Requisitos del sistema 7
2.2 Herramientas y tecnología utilizadas 7

3. Análisis de Sistemas 8
3.1 Recolección de información 8
3.2 Sistema Existente 8-9
3.3 Sistema Propuesto 9-10
3.4 SRS 10
3.4.1 Necesidad de SRS 10
3.4.2 Descripción general de la función del software 11
3.5 Estudio de Viabilidad 11
3.5.1 Viabilidad Técnica 11
3.5.2 Viabilidad Operativa 12
3.5.3 Viabilidad Económica 12

4. Diseño del Sistema 13

4.1 Diseño Lógico 13
4.1.1 Diagrama E R 13-14
4.1.2 Diagrama de Flujo de Datos 15-18
4.1.3 Diagrama de flujo 19
4.2 Diseño de Bases de Datos 20-22
3

Nº PARTICULAR NÚMERO DE PÁGINA

5. Pruebas del sistema e implementación 23

5.1 Pruebas 23-24
5.2 Implementación 25

6. Especificación del sistema 26

6.1 Especificación de Software
6.2 Especificación de Hardware 26

26-27

7. Mantenimiento del sistema 28-29

8. Seguridad del Sistema 30-32

9. Referencia y Apéndices 33

10. Conclusión 33
4

SISTEMA DE GESTIÓN DE RTO

1. Introducción del Proyecto

El proyecto SISTEMA DE GESTIÓN DE RTO se propone instalar un sistema que

habilitar la interfaz RTOSYSTEM propuesta con el sistema existente con máximo
exactitud. Este proyecto es muy útil para aquellos que están preocupados por lo diferente
procesos sobre RTO. Durante la fase de estudio, hemos realizado un análisis preliminar

profundidad suficiente para permitir una evaluación técnica y económica del sistema propuesto.
Como un sistema totalmente basado en mano de obra está actualmente en funcionamiento para todos los procedimientos,

diseñar un nuevo sistema que haga todo el proceso en línea requiere una profunda
conocimiento sobre el sistema existente. A lo largo del proyecto nos enfocamos en presentar
información y comandos de manera fácil e inteligible. El propósito de nuestra
El sistema de gestión de RTO es proporcionar una herramienta tecnológica líder para la facilidad de

Funciones de RTO como Registro, Licencia de Aprendiz y Aptitud, etc... Reducirá

considerablemente las dificultades enfrentadas en el sistema existente, con un mínimo de error y

dificultades.

1.1 Propósito
La administración de la Oficina del RTO es una organización de transporte gubernamental y la principal

El propósito de esta oficina es emitir licencias de conducir, registros de vehículos, etc. En este documento, nosotros

proponga el sistema computarizado de gestión de todos los trabajos de datos. Ayuda a traer el
flujo de trabajo fluido y también aumentar la eficiencia.
Este documento destaca los requisitos y también proporciona las directrices que son
necesario para el desarrollo del trabajo del proyecto que se menciona arriba. También
dê pautas breves sobre cómo diseñar el proyecto.
Este proyecto es conocido como un proyecto piloto y ayuda a estar preparado por la oficina de
RTO para mantener registros de todas las licencias de conducir que se emiten. Al mismo tiempo, también anota

los detalles para el registro de vehículos. Cuándo comenzará todo este trabajo en un
un sistema informatizado entonces ayudará a aumentar la eficiencia de los empleados. El alcance
del este proyecto es mantener los registros del DL, registro de vehículos.
Windows XP es el sistema operativo más ideal y Visual Basic 6.0 se utiliza como el
herramienta de desarrollo para este proyecto. MS Access es la base de datos que se utiliza. Ahora el

los trabajos de registros en la oficina se modifican de acuerdo al sistema manual

lo que requiere mucho tiempo y trámites. También disminuye la presión laboral y
5

la eficiencia de los empleados. Con la modernización, todo se volverá

digitalizado, aumentando así la eficiencia y el flujo de trabajo. El sistema
también ayudará a gestionar las operaciones diarias de manera rápida y fácil.

1.2 Alcance
Este es un proyecto preparado por la oficina del RTO para mantener todos los registros como la emisión de la DL.

Registro de vehículos. Una vez que todo esto se computerized para trabajar con eficiencia del
el empleado recibirá aumentos. El proyecto del sistema de gestión de RTO consta de dos
módulo de función es decir, módulo de registro de vehículos y licencia.

1.3 Beneficios
Guardar energía
Al utilizar nuestro sistema, los usuarios no necesitan desperdiciar energía para estar de pie en un

fila.
Fácil de acceder o amigable para el usuario
Nuestro sistema es muy fácil de acceder y amigable para el usuario porque el
el usuario que no puede conocer acerca del servicio en línea también puede usar esto

proyecto porque es de acuerdo a este tipo de usuario, así que podemos decir
que nuestro proyecto sea fácil de usar.
Disponibilidad 24/7
El usuario puede acceder a nuestro proyecto desde cualquier lugar y en cualquier momento.

no es necesario usar proyectos durante el horario de oficina.

Ahorrar tiempo
Nuestro software consume mucho tiempo porque en la actualidad el
el usuario espera llenar un formulario y esperar una cita pero en nuestro
proyecto que varios usuarios se conecten en línea y se registren en un sitio web

y completar el campo requerido en un formulario y obtener una cita para el

licencia y registro del vehículo.

1.4 Requerimiento Funcional

Nuestro sistema tiene principalmente tres módulos: un módulo de administración, un usuario autorizado

módulo y otro módulo de usuario. Varios procesos involucrados en estos tres módulos
son:
Solicitud de licencia
Introducción: Cualquier usuario autorizado puede cargar un formulario para la solicitud de licencia.

Detalles proporcionados por los usuarios en el formulario de solicitud descargado.

6

Proceso: El administrador verificará los datos introducidos y los procesará si es

ok.
El usuario recibirá un correo acerca del examen de licencia.

Registro de Vehículos
Introducción: El usuario autorizado puede registrar el vehículo subiendo el formulario.
para el registro de vehículos.

Entrada Detalles proporcionados por el usuario autorizado en el descargado

formulario de solicitud.

Proceso El administrador lo procede después de verificar los detalles proporcionados

por el usuario.
Salida El usuario recibirá un correo respecto a la prueba de licencia.

Correo
Introducción El administrador puede enviar un mensaje al usuario autorizado.
sobre la renovación de la licencia y todo eso.

Entrada El mensaje enviado por el administrador.

Proceso El usuario autorizado puede leer el mensaje desde su mensaje.
caja.
El usuario puede ser actualizado.

Buscar
Introducción: El administrador y el usuario autorizado pueden seleccionar un vehículo en particular

y titular de la licencia utilizando el número de licencia, número de vehículo o color

El número de licencia del vehículo o la otra información sobre el

vehículo
Proceso: Al ingresar información particular sobre el vehículo o la licencia se puede
recuperar todo el
detalles sobre ese vehículo
Se obtendrán los detalles completos del vehículo.

[Link]ón General
7

El sistema debe diseñarse de tal manera que los usuarios autorizados y no autorizados
puede acceder a los módulos del proyecto y el Administrador da la respuesta del usuario.

2.1 Requisito del Sistema

Requisitos de hardware
Procesador : Pentium IV de 2GHz en adelante

RAM : 2GB de RAM

Monitor : Monitor a color de 15"

Teclado
Ratón

Requisitos de Software
Sistema Operativo. : Windows XP
Herramienta de desarrollo : Visual Basic 6.0
Base de datos : MS Access

2.2 Herramientas y Tecnología Utilizadas

Idioma : JAVA
Interfaz de usuario : HTML, JAVAScript
Back-end : MI SQL
8

3. Análisis del Sistema

3.1 Recopilación de Información
La recopilación de información puede utilizarse por una variedad de razones diferentes; sin embargo, el

el principal beneficio en cuanto a tus estudios académicos es que te volverás consciente

de fuentes, opiniones y enfoques más diversos que solo pueden mejorar tu
trabajo académico.

3.2 Sistema Existente

Un sistema completamente manual, que funciona sin ninguna participación de una computadora.
definitivamente tiene sus propias desventajas. Sabemos que la producción y el uso de
Los vehículos están aumentando día a día. Por lo tanto, la necesidad de la RTO es muy importante ahora.

días. Las funciones complejas como el Registro de vehículos, etc. se vuelven muy
difícil si estamos utilizando el sistema existente.
Para conocer los problemas específicamente, hemos realizado un estudio detallado sobre el
todo el procedimiento del sistema que está funcionando actualmente.
En el sistema existente de la oficina de RTO se realizan funciones como el registro,
licencia. Hay ciertos procedimientos y formalidades requeridos para llevar a cabo estos
funciones.
Es esencial que los datos de cada vehículo y su propietario deben ser
disponibles en el departamento o oficina correspondiente del Gobierno y que el
el vehículo debe ser distinguible de otros vehículos a simple vista. La matrícula
la marca debe mostrarse en lugares especificados y de manera especificada. En el
sección de registro, la solicitud de registro de un nuevo vehículo será
presentado ante la Autoridad Registrante en cuya jurisdicción se encuentra el solicitante
residiendo o teniendo su negocio y el vehículo se mantiene normalmente. La solicitud
la inscripción se llevará a cabo en el formulario, dentro de un plazo de 7 días a partir de la fecha de

entrega de dicho vehículo excluyendo el periodo de viaje.

Muchas personas tienen una obsesión con los números de matrícula de sus vehículos. Algunos de ellos

quieren números elegantes mientras que los demás quieren números de acuerdo a su fe en el
astrología numérica. Sea lo que sea, será interesante conocer sobre el
teoría de la formación de números de registro de vehículos en el estado, manteniéndolo como un

identificador único para cada vehículo.

9

En la sección de licencias en el RTO, después de la verificación del formulario, su

conocimiento sobre las reglas y regulaciones de tráfico así como la interpretación de símbolos
se les evaluará. Sin embargo, si surge la necesidad, también pueden realizar una prueba escrita.

Después de todo esto, se emitirá una licencia de aprendiz. Esta licencia es válida por un periodo de
6 meses y se puede renovar por otros 6 meses solo una vez. El siguiente
Con el tiempo, se tendrá que emitir una nueva licencia de aprendiz siguiendo todo el proceso anterior.

procedimiento.

3.3 Sistema Propuesto

El sistema propuesto tiene como objetivo automatizar los principales procesos en la Regional

Oficina de Transporte.

Descomposición del Sistema Propuesto

Los módulos básicos en el procedimiento total son:
El administrador: El administrador es un usuario con privilegios. Tiene el poder de verificar el

datos ingresados por el usuario, procesamiento de datos y proporcionar apropiado

soluciones.
Usuario autorizado: Cualquier persona que haya sido autorizada por el
administrador. Un usuario autorizado debe tener un nombre de usuario y una contraseña

para acceder a información detallada del sitio excluyendo el acceso

información general en páginas compartidas y públicas.
Él es la persona que obtiene todos los beneficios de esta aplicación.
Características del Sistema Propuesto
El sistema propuesto es un sistema en línea: por lo que cualquier persona puede navegar por el sitio.

y descargar y subir el formulario de solicitud.

Menos que consume tiempo.
Altamente seguro en el almacenamiento de datos.
Es más amigable para los usuarios: las secciones como, registro, licencia, etc. son
combinados juntos en una sola ventana.
10

Los usuarios pueden tener conocimiento sobre las nuevas reglas y regulaciones de
información y
sección de conciencia.
En el sistema en línea, la repetición de trabajo y la duplicación de datos pueden ser

evitado.

3.4 SRS
La especificación de requisitos de software es un documento en el que se completa

describe lo que hace el sistema propuesto. El objetivo básico del requisito

la fase es producir el SRS. Que describe el comportamiento completo del
software propuesto. SRS también es útil para el usuario que utiliza nuestro software para
entender así su propia necesidad.

3.4.1 Necesidad de SRS

Los usuarios no siempre conocen así sus necesidades.
Debes analizar y comprender el potencial.
El proceso de requisitos ayuda a clarificar necesidades.
Comprensión clara de lo que se espera.
Los errores de requisitos se manifiestan en el software final.
Para satisfacer el objetivo de calidad, se debe comenzar con alta calidad.

SRS.
Los errores de SRS son costosos de corregir más tarde.

3.4.2 Resumen de la función del software

Esta es la configuración del software en la que se dio forma al proyecto. El
el lenguaje de programación utilizado, las herramientas utilizadas, etc. se describen aquí.

HTML y Java Script se utilizan como front end

Microsoft SQL Server se utiliza como backend
La tecnología web utilizada es [Link]

3.5 Estudio de Viabilidad

El estudio de viabilidad es el estudio detallado que se expande a partir del resultado inicial.

investigación. Esto se hace investigando el sistema existente en el área bajo

investigación o ideas generales sobre un nuevo sistema. Es la prueba de un sistema
propuesta según su capacidad de trabajo, impacto en la organización, capacidad para satisfacer usuario
11

necesidades y uso efectivo de recursos. El objetivo del estudio de viabilidad es adquirir un

sentido del alcance del problema. Se lleva a cabo para seleccionar el mejor sistema que
cumple con los requisitos de rendimiento.

3.5.1 Viabilidad Técnica

La viabilidad técnica se centra en el sistema existente y en qué medida puede soportar.
modificaciones propuestas. Involucra una mejora financiera.
Esta evaluación determina si la tecnología necesaria para el propuesto
el sistema está disponible o no. Esto tiene que ver con especificar satisfacer al usuario

requisitos. Las necesidades técnicas del sistema pueden incluir front-end y back-
fin de la selección.
Un problema importante para el desarrollo de un proyecto es la selección de adecuado
front-end y back-end.
Basado en algunos aspectos, seleccionamos la plataforma más adecuada que se ajuste a las necesidades.

de la organización.

3.5.2 Viabilidad Operacional

El sistema actual es fácilmente comprensible. A los usuarios se les presenta de manera amigable

interfaz de usuario que les ayuda a comprender el flujo del sistema más fácilmente.
Se ha proporcionado máxima transparencia. El nuevo sistema es muy fácil de usar.
amigable y los costos operativos son soportables. El mantenimiento y funcionamiento del nuevo
el sistema necesita menos esfuerzo humano. El proyecto propuesto es beneficioso para el

organizado y es fácil de usar.

El sistema es utilizado directamente por los usuarios y no necesita otros operadores para

coordina el sistema. Así que el sistema puede ser juzgado como operativamente viable.

3.5.3 Viabilidad Económica

La viabilidad económica se utiliza para determinar los beneficios y ahorros esperados de
el sistema de candidato y compararlos con los costos incurridos. Si los beneficios
si los beneficios superan los costos, entonces la decisión será diseñar e implementar el sistema. De lo contrario,
12

se deberán realizar modificaciones al sistema propuesto. El sistema propuesto es

económicamente viable.

[Link]ño del Sistema

El diseño del sistema típicamente se centra en las interfaces externas de los módulos y
no se puede extender para especificar los internos. El diseño detallado es una forma en la que

el diseño se puede comunicar de manera precisa y completa en cualquier grado de

detalle deseado por el diseñador. El propósito del Documento de Diseño de Software es
proporcionar una descripción del diseño de un sistema lo suficientemente completa como para permitir el software

el desarrollo debe continuar con una comprensión de lo que se va a construir y cómo se va a hacer
se espera que se construya. El Documento de Diseño de Software proporciona la información necesaria

para proporcionar una descripción de los detalles del software y el sistema que se va a construir. Esto

El Documento de Diseño de Software es para un sistema de nivel base que funcionará como una prueba.

de concepto para el uso de construir un sistema de control de calidad que proporciona una base
nivel de funcionalidad para mostrar la viabilidad para el uso en producción a gran escala.

4.1 Diseño Lógico

Diagrama ER 4.1.1E
El Diagrama de Entidad-Relación (también conocido como ERD o diagrama ER) es un
modelo de red que describe la disposición de los datos almacenados de un sistema a un alto nivel de
 13

abstracción. El ERD debe representar las relaciones entre todas las entidades.
Cualquier par de entidades debe estar conectado entre sí por algún conjunto de relaciones y

El tipo de relación también debe ser especificado.

Componentes de un ERD
Hay dos componentes principales de un ERD:
Entidad
Se define como cualquier objeto sobre el cual se recopila información. Tiene diferentes
atributos que lo describen. Debe estar representado por una caja regular como se muestra
debajo:
Relaciones:
Las entidades están conectadas entre sí por relaciones. una relación representa un
conjunto de conexiones entre entidades y representar por un diamante.
Una relación es una asociación significativa bidireccional.
Existen tres tipos de relaciones
Relaciones uno a uno
Relaciones uno a muchos
Relación de muchos a muchos

USUARIO

Dos LMV
Rueda Cuatro
r Wheeler
HMV

Ap
Registro contraplacado Licencia
n para

ES ES
A Una
Dos Ruedas Cuatrimoto
L_Licencia P_Licencia

E_no
.
14

C_no Color C_no Color

. . U_i
U_i
d U_ad
M_n
d d
E_no
o.
M_n .
o. sexo sexo
4.1.2 Diagrama de Flujo de Datos
Como su nombre indica, el DFD es una representación del flujo de datos dentro del sistema.
U_ad
d
Incluye procesos, almacenes de datos e interfaces externas al sistema. Externo
las interfaces pueden ser tratadas como entidades externas. El DFD puede descomponerse en sub-

los procesos. Cualquier par de entidades/almacenes de datos deben estar conectados entre sí por algún

proceso. Los procesos no pueden estar conectados directamente entre sí. Lo siguiente
¿Cuáles son los cuatro componentes principales del DFD?
Proceso
Entidad Externa
Almacén de datos
Conector
El DFD también se conoce como el diagrama de burbujas. Es un formalismo gráfico simple.
que se puede usar para representar un
sistema en términos de los datos de entrada al sistema, varios procesos realizados en
estos datos y la salida
datos generados por el sistema. La razón principal por la que esta técnica DFD es tan

popular es probablemente debido a

los hechos de que DFD es un formalismo muy simple. Es sencillo de entender y usar.
El modelo DFD utiliza un muy
número limitado de símbolos primitivos para representar las funciones realizadas por un
sistema y el flujo de datos
entre estos sistemas. Comenzando con un conjunto de alto nivel
funciones que un sistema de rendimiento del modelo DFD en
Jerárquicamente representa varias subfunciones. El Diagrama de Flujo de Datos
la técnica también sigue un
un conjunto simple de conceptos y reglas intuitivas.

DFD de Nivel 0
 15

Solicitud

USUARIO Proceso
Licencia
CUOTA Y
RECHAZAR
Respuesta

ADMIN Registro

DFD de Nivel 0
Registro
gestión

Vehículo Cliente
gestión gestión
RTO
Vehículo
Regístrate
ión
Licencia de conducir sistema Usuario del sistema

gestión gestión

Iniciar sesión
gestión
 16

DFD de Nivel 1

Vehículo GenerarVehículo
gestión Informe

Cliente Generar
gestión Informe del Cliente

Licencia de conducir Vehículo RTO Generar conducción

gestión Registro Informe de Licencia
sistema
Registro Generar
gestión Registro
Informe Informe
Iniciar sesión Verificar inicio de sesión del usuario
gestión Detalles
Usuario del sistema
Generar Sistema
gestión Informe del usuario
 17

Yo
RTO NAM
OFICIAL Yo ID E
NO

CATEGOR
Y

OFERTA VERI Crear

RS FY s

R NO. R
TIPO BELO
R R EXP NGS
FECHA A
LICENCIA/RENOVACIÓN BIEN

F
TIPO
4.1.3 Diagrama de flujo FNO
BIEN
E
TRANSECTI T
DURACIÓN ONN PROHIBIR
TRÁFICO
K
EDUCACIÓN
N T NO T AMT
ETAPAS

L NO. INSCRIBIR
L PA
LED
EXPIRAR YS
L
TIPO

LICENCIA DEBERÍA CONTROLADOR

D GE
E TENER TS
U ID
DIRECCIÓN_U

U
VEHÍCULO NOMBRE U_TELEFONO
U
CONTACTO
U_
V NO. V REG NOMBRE DE USUARIO

V V
TIPO CHASIS
V
COL
18

4.2 Diseño de Base de Datos

Una base de datos es una colección de datos relacionados. Por datos, nos referimos a hechos conocidos que pueden

ser grabados y que tienen un significado implícito. Definir una base de datos implica

especificando los tipos de datos, estructuras y restricciones de los datos que se almacenarán en el
base de datos. El objetivo general es hacer que el acceso a la base de datos sea fácil, rápido, en

caro y flexible para los usuarios. La normalización se realiza para obtener interno
consistencia de datos y tener una redundancia mínima y una estabilidad máxima.
Esto asegura minimizar el almacenamiento de datos requerido y optimizar las actualizaciones.
Los datos en el sistema deben ser almacenados y recuperados de la base de datos. Diseñando el
la base de datos es una parte del diseño detallado. Los elementos de datos y las estructuras de datos deben ser

se han identificado en la etapa de análisis. Están estructurados y puestos

juntos para diseñar el sistema de almacenamiento y recuperación de datos.
MS SQL es la base de datos del sistema. Proporciona datos seguros, precisos y
gestión.
La base de datos de nuestro proyecto está diseñada utilizando SQL y consta de 5 tablas.
Inicio de sesión de administrador
Registro
Inicio de sesión del usuario
Registro de Vehículos
Licencia
1. Inicio de Sesión de Admin
NOMBRE Descripción Tipo de Datos Tamaño Restricciones
A_ID Nombre del Administrador varchar 30 Clave primaria
A_Pass Contraseña Varchar 30

[Link]
NOMBRE Descripción Tipo de dato Tamaño Restricciones
ID ID de UsuarioInt 32 Clave primaria
Nombre Nombre del Varchar 25
19

usuario
Sexo Sexo Varchar 7
Fecha de nacimiento Fecha de nacimiento Varchar 12
Multitud Número de móvil Varchar 15
Nombre del padre Nombre del padre Varchar 30
Agregar Dirección Varchar 30
Correo electrónico ID de correo electrónico Varchar 30
Ruta de la foto Varchar 30
Varchar
Ruta de la fecha de nacimiento Camino de nacimiento 30
Ruta de añadir Camino de añadir Varchar 30

[Link] de Sesión de Usuario

NOMBRE Descripción Tipo de Datos Tamaño Restricciones
U_ID Nombre del usuario varchar 30
U_Pass Contraseña Varchar 30

[Link] de Vehículos
NOMBRE Descripción Tipo de Dato Tamaño Restricciones
ID ID de el varchar 32 Clave primaria
vehículo
Concesionario Nombre del concesionario Varchar 25
Clase 4 y 2 ruedas Varchar 32
Fabricado Nombre del Varchar Max
fabricar
D_fabricado Fecha del Varchar 32
fabricar
H_P Caballo de fuerza Varchar 25
Número de chasis Chasis Varchar 50
número
Eng_no. Número de motor Varchar 50
Capacidad Capacidad Varchar 30
Combustible Tipo de combustible Varchar 40
Color Color ofVarchar 30
vehículo
Reg_no Registro Varchar 30
número
20

[Link]
NOMBRE Descripción Tipo de Dato Tamaño Restricciones
U_ID Nombre de U_id Ent 30 Clave primaria
D_aplicar Fecha de solicitud Varchar 20
D_prueba Fecha de la prueba Varchar 20
T_prueba Tiempo de prueba Varchar 10
I_autoridad Problema deVarchar 30
autoridad
Resultado Resultado ofVarchar 10
aprobar/reprobar
Tipo Escriba ofVarchar 10
LMV/HMV

[Link] del Sistema e Implementación

5.1 Pruebas
Las pruebas del sistema son en realidad una serie de diferentes cuya finalidad principal es completar

ejercita el sistema basado en computadora. La prueba de software es un elemento crítico de

aseguramiento de la calidad del software y representa la revisión final de la especificación,

diseño y codificación. Las pruebas del sistema hacen una suposición lógica de que todas las partes de

el sistema es correcto; el objetivo se logrará con éxito. La prueba es la final

actividad de verificación y validación dentro de la propia organización. Durante las pruebas
las principales actividades se concentran en los exámenes y modificaciones de los
código fuente.
21

Las pruebas son un proceso de ejecutar un programa con la intención de encontrar un error. Un
Una buena prueba es aquella que descubre un error aún no descubierto. Los objetivos de las pruebas son:

Pruebas unitarias
Las pruebas unitarias permiten a un programador detectar errores en el código. Una prueba unitaria

se centra en la verificación de la unidad más pequeña del diseño de software. Esta prueba

se llevó a cabo durante la codificación misma. En este paso de prueba, cada módulo
va a funcionar satisfactoriamente como la salida esperada del módulo.
Aspecto del proyecto:
El diseño del front end consiste en varios formularios. Fueron probados para datos.
aceptación. De manera similar, el backend también probó para la aceptación exitosa

y recuperación de datos.

Pruebas de integración
A través de cada programa trabajan individualmente, deberían funcionar después de enlazarlos.

juntos. Esto se conoce como interfaz. Los datos pueden perderse a través de
interfaz; un módulo puede tener un efecto adverso sobre el otro
las subrutinas después de enlazar pueden no realizar la función deseada que se esperaba por el

rutina principal. La prueba de integración es la técnica sistemática para

construyendo la estructura del programa mientras se realizan pruebas
para descubrir errores asociados con la interfaz. Usando un plan de pruebas integrado
preparado en la fase de diseño del desarrollo del sistema como una guía, el
se llevó a cabo una prueba de integración. Todos los errores encontrados en el sistema fueron

corregido para el siguiente paso de prueba.

Aspecto del Proyecto

Después de conectar el backend y el frontend como un módulo completo, los datos

ingresó en el front-end. Una vez enviado, se ingresaron correctamente en el
Base de datos. A solicitud, los datos fueron recuperados con éxito en dos formas.

Pruebas del sistema

Después de realizar las pruebas de integración, el siguiente paso es la prueba de salida de

el sistema propuesto. No
el sistema podría ser útil si no produce la salida requerida en un
formato especificado. Las salidas generadas son mostradas por el usuario. Aquí el
22

el formato de salida se considera de dos maneras. Una en pantalla y la otra en

formato impreso.
Aspecto del proyecto:
Todo el proyecto fue probado y se encontró exitoso.

Pruebas de validación
El usuario tiene que trabajar con el sistema y verificar si el proyecto cumple con
sus necesidades. En la validación
verificando que el usuario funcione con la versión beta del software.
Aspecto del proyecto:
El usuario introduce los datos apropiados y los resultados fueron verificados y validados.
Pruebas de aceptación del usuario
La aceptación del usuario de un sistema es un factor clave para el éxito de cualquier sistema.

El sistema en consideración fue probado para la aceptación del usuario ejecutando

un prototipo del software.
Aspecto del proyecto:
Se demuestra una versión Alfa a los usuarios. Sus sugerencias son
grabado.

5.2 Implementación
Una vez que el sistema fue probado, comenzó la fase de implementación. Fase crucial en
el ciclo de vida del desarrollo del sistema es la implementación exitosa de un nuevo sistema

El diseño. La implementación simplemente significa convertir el nuevo diseño del sistema en

operación. Este es el momento de la verdad, la primera pregunta que surge en la mente de todos
ten en cuenta si el sistema podrá proporcionar todos los resultados deseados como se aceptó
del sistema. Antes de iniciar el proceso de implementación del proyecto, el proyecto debe

han completado con éxito el proceso de evaluación del proyecto y el proyecto ha

ha sido aprobado para su implementación.
El proceso de evaluación del proyecto incluye realizar un análisis de necesidades y

revisión de arquitectura. El
la fase de implementación del diseño de software consiste en diferentes tareas que deben realizarse

secuencialmente para obtener el resultado deseado. Varias implementaciones distintas

proyectos en lugar de una gran implementación podrían limitar el riesgo y el alcance y
gestión de recursos. Así que el proyecto se implementó por módulos.
23

6. Especificación del sistema

6.1 ESPECIFICACIÓN DE SOFTWARE
Un elemento principal en la construcción de un sistema es la selección de software compatible ya que

el software en el mercado está experimentando una progresión geométrica Seleccionado

el software en el mercado está experimentando una progresión geométrica Software seleccionado

debe ser aceptable por la empresa y los usuarios, así como también debe ser viable para
el sistema.
Herramienta de Front End [Link] con C#.NET
Herramientas [Link], informes Crystal
Backend Microsoft SQL Server 2005
Sistema Operativo Windows NT/2000 Servidor/ XP/ 2003/ Longhorn (con
IIS)
Lado del Cliente HTML, Java Script, Photoshop

El propósito de tener un documento de especificación de requisitos de software es tener

una documentación de especificaciones comprensible, sin ambigüedades y completa
requisito para el proyecto.

6.2 ESPECIFICACIONES DE HARDWARE

La sección de configuración de hardware es una tarea importante relacionada con el software
El desarrollo de la memoria de acceso aleatorio insuficiente puede afectar negativamente en el

la velocidad y eficiencia de todo el sistema. El proceso debe ser potente para

manejar todas las operaciones El disco duro debe tener suficiente capacidad para almacenar
el archivo y las aplicaciones.
Procesador Pentium IV y superior
Velocidad del procesador 1.4 GHz en adelante
Memoria del sistema 128 Mb Mínimo 256 Mb Recomendado
Mostrar Tarjeta Gráfica Capaz de Producir Resolución 1024,768
Tamaño de caché 512 KB
RAM 512 MB (Mínimo)
24

Tarjeta de Red Cualquier tarjeta puede proporcionar una velocidad de 100 Mbps

Conexión de red Conexión de cable UTP o coaxial

Impresora Impresora a color por inyección de tinta/ láser que proporciona al menos 1000 dpi

Disco duro 80 GB
Monitor SVGA Color 15”
Ratón Teclado US de 104 teclas, Serial, USB o PS/2
Teclado 104 Teclas
Módem 56.6 Kbps

7. Mantenimiento del sistema

La gestión es "el proceso de diseñar y mantener un entorno en
qué individuos, trabajando juntos en grupos, logran eficientemente seleccionar
el objetivo clave es proporcionar un soporte rentable
a un sistema de software durante toda su vida útil. La gestión está preocupada por
calidad y productividad, que implican efectividad y eficiencia. gestión
consiste en cinco funciones separadas. Las funciones son: planificación, organización,
dotación de personal, liderazgo (a veces también llamado dirección) y control. Planificación

consiste en seleccionar misiones y objetivos y predeterminar un curso de

25

acciones para lograrlos. Compromiso de recursos humanos y materiales

y la programación de acciones están entre las actividades más críticas en esta función.
La organización es la función de gestión que establece una estructura intencionada de
roles para que las personas los ocupen en una organización. Esto implica organizar las relaciones
entre roles y otorgando las responsabilidades y la autoridad necesaria. Dotación de personal

involucra el llenado de las posiciones en la organización seleccionando y capacitando a personas.

Dos actividades clave de esta función son evaluar y valorar al personal del proyecto.
y proporcionando un desarrollo general, es decir, la mejora del conocimiento, actitudes,
y habilidades. Liderar es crear un ambiente de trabajo y una atmósfera que
asistir y motivar a las personas para que contribuyan al logro de
organización y objetivos del grupo. Medidas de control del rendimiento real contra
metas planificadas y, en caso de desviaciones, elabora acciones correctivas. Esto implica
recompensar y disciplinar al personal del proyecto. organizaciones de mantenimiento de software

puede ser diseñado y configurado con tres estructuras: funcional, por proyecto o matricial
Las organizaciones funcionales son jerárquicas por naturaleza. La organización de mantenimiento

se descompone en diferentes unidades funcionales, como la modificación de software,

pruebas, documentación, aseguramiento de calidad, etc. Organizaciones funcionales presentes

la ventaja de una organización centralizada de recursos especializados similares. El

la principal debilidad es que los problemas de interfaz pueden ser difíciles de resolver: siempre que un

el departamento funcional está involucrado en más de un proyecto, pueden surgir conflictos sobre

las prioridades relativas de estos proyectos en la competencia por recursos. En

además, la falta de un punto central de responsabilidad y autoridad completa para
el proyecto puede implicar que un departamento funcional ponga más énfasis en su
especialidad propia que en el objetivo del proyecto. Las organizaciones de proyectos son el

opuesto de las organizaciones funcionales (ver figura 14). En este caso, un gerente es
dada la plena responsabilidad y autoridad para llevar a cabo el proyecto; todo el
los recursos necesarios para lograr los objetivos del proyecto están separados de la
estructura funcional regular y organizada en un autónomo, autosuficiente
equipo. El gerente de proyecto podría posiblemente adquirir recursos adicionales de
fuera de la organización en general. Las ventajas de este tipo de organización son una plena
control sobre el proyecto, toma de decisiones rápida y una alta motivación del proyecto
26

personal. Las debilidades incluyen el hecho de que hay un tiempo de inicio para formar el
equipo, y puede haber un uso ineficiente de los recursos. Las organizaciones matriciales son un

composición de organizaciones funcionales y por proyectos con el objetivo de

maximizando las fortalezas y minimizando las debilidades de ambos tipos de
Las organizaciones. El mantenimiento todavía es percibido por muchas organizaciones como un no

cuestión estratégica, y esto explica por qué está atendido por estudiantes y nuevos contratados

personas. Para agravar el problema, está el hecho de que la mayoría de las universidades no
enseñar el mantenimiento de software, y el mantenimiento raramente se enseña en el ámbito corporativo

programas de capacitación y educación, también. La falta de evaluación del mantenimiento

el personal genera otros problemas de gestión, principalmente alta rotación y baja

moral

8. Seguridad del Sistema

La seguridad puede tener diferentes niveles de dificultad para su implementación. Un factor en

determinar la dificultad es el número y la distribución de los sistemas. Cuando

solo los sistemas individuales deben ser protegidos, como una computadora con todos los archivos

residiendo localmente y sin necesidad de conectarse a ningún recurso externo, la seguridad es

no tan complejo como con sistemas distribuidos. Con la arquitectura de sistemas distribuidos,
hay diferentes nodos y recursos. Un problema importante con los sistemas distribuidos
es la seguridad de aplicaciones. Hay la pregunta de cómo se maneja la seguridad en
aplicaciones distribuidas, y cómo el cliente maneja las aplicaciones que provienen de un
fuente desconocida.
Estableciendo la política de seguridad
La política de seguridad consiste en aquellos procedimientos y regulaciones destinados a
mantener el nivel deseado de seguridad del sistema. La política de seguridad para el Teradata
Los RDBMS deben incluir dos elementos esenciales de implementación:
27

Funciones de seguridad impuestas por el sistema

Características de seguridad impuestas por el personal (a través del administrador, operador y
usuarios finales)
La seguridad impuesta por el sistema es relativamente fácil de implementar. Define cómo usar
las características de seguridad de Teradata y las reglas. Implementar esas reglas es

responsable por el administrador de seguridad. La consideración principal para

establecer una política de seguridad incluye:
Identificación de las necesidades de seguridad.
Identificación de políticas y procedimientos para satisfacer esas necesidades.

Identificación de necesidades de seguridad y niveles de seguridad

El primer paso para establecer una política de seguridad es identificar las necesidades de seguridad, que

involucrar lo siguiente:
Identificando la importancia empresarial de los datos y su asociación
sistema de procesamiento.
Asignar una prioridad de seguridad a los datos, basada en el caso de negocio
evaluación.
Identificando las clases de usuarios que requieren acceso al RDBMS de Teradata
y los datos bajo su control.
Identificando los recursos del sistema que requieren protección para garantizar la continuidad
disponibilidad para todos los usuarios válidos de Teradata.

Los requisitos de seguridad deben basarse en el valor comercial de los datos

procesado en el sistema. Un sistema que almacena y procesa datos altamente sensibles
probablemente tiene una mayor necesidad de seguridad que uno que no la tiene.
Existen tres niveles de seguridad de datos, que incluyen mínimo, moderado y alto.
Cada nivel tendrá sus ventajas y desventajas:
Seguridad mínima Cualquiera que haya iniciado sesión con éxito en el sistema
tiene acceso sin restricciones a todos los datos y recursos de Teradata RDBMS. No
Se realiza auditoría relacionada con la seguridad y no hay una política de seguridad formal.

La única restricción de acceso relacionada con la seguridad es que un usuario debe obtener primero

acceso a un sistema cliente que es capaz de comunicarse con el

Teradata RDBMS. Todo esto hace que compartir información sea extremadamente

simple, y el rendimiento del sistema se ve mejorado por la falta de seguridad

actividades de aplicación. Por otro lado, obviamente, los datos están sujetos a
destruir o corromper debido a la falta de control de seguridad del sistema.
28

Seguridad moderada En esta clase, los usuarios se agrupan según su

necesidades y confiabilidad. Bajo seguridad moderada, el acceso ilimitado es
reservado para un pequeño grupo privilegiado. Solo auditorías ocasionales de
se realizan eventos relacionados con la seguridad, y no existe una política de seguridad formal

para los usuarios. En esta clase, los eventos relacionados con la seguridad que tienen poco o ningún

efecto en el rendimiento del sistema, y los usuarios están sujetos a poca o ninguna demanda

por el esfuerzo adicional para realizar su trabajo, pero la desventaja es que es

posible que un intento de violación grave pueda pasar desapercibido durante un período prolongado

períodos.
Alta seguridad. A este nivel, se identifica a un administrador de seguridad y
encargado de establecer y mantener la seguridad de Teradata RDBMS.
El acceso físico a los procesadores, unidades de almacenamiento en disco y consolas de sistema es

controlado cuidadosamente. Los eventos relacionados con la seguridad se auditan regularmente. Aleatorio

Se realizan auditorías de seguridad de usuarios individuales. En esta clase, los datos y

los recursos de procesamiento se les otorga un alto nivel de protección. Si un

se intenta acceder sin autorización, la política de auditoría está diseñada para ambos

detectar el intento y permitir que se implementen medidas correctivas. El

la desventaja es que los datos compartidos requieren un esfuerzo adicional por parte de
propietario, ya que deben definir quién está autorizado a acceder a lo que se posee

información. También, basado en la frecuencia y el alcance de la auditoría, sistema

el rendimiento puede verse afectado negativamente por las demandas de la auditoría
eventos relacionados con la seguridad.
Formulación de la Política de Seguridad
Una vez que se han definido las necesidades de seguridad del sistema, se puede establecer una política de seguridad.

formulados. Los documentos de seguridad deben cubrir:

Extensión de la necesidad de seguridad
Beneficios que se derivan de un sistema seguro
Una política de gestión definida cuando se descubre a un usuario intentando
violar la seguridad
Protección con contraseña
Otorgar acceso a los datos
Personal de la sala de computadoras
Contactando al administrador de seguridad
29

9. Referencias y Apéndices

[Link]

Conclusión
El SISTEMA DE GESTIÓN DE OFICINA RTO es una aplicación web, que es muy útil para
La finalización del trabajo de RTO en línea. Aquí estamos desarrollando este tipo de módulo que

ayuda a reducir el trabajo de RTO manualmente y ayuda a ahorrar tiempo al usuario.

Reducir considerablemente la corrupción en el departamento de transporte. Mantener la licencia
documentos de forma segura.
30