Anda di halaman 1dari 6

UNIVERSIDAD PRIVADA DE TACNA 2010

Proyecto SYSTRONIX

Desarrollo del Sistema de Contabilidad


Especificaciones Suplementarias (SSS)

UNIV SIDAD PRIVADA DE TACNA 2010

1. Introduccin 1.1 Propsito 1.2 Alcance 1.3 Definiciones, acrnimos y abreviaturas 1.4 Referencias 2. Suplementarias 2.1 Usabilidad 2.1.1 Estndar de interfaz de pantalla 2.1.2 Acceso a la ayuda del sistema 2.2 Confiabilidad 2.2.1 Disponibilidad 2.2.2 Tiempo de reparacin 2.2.3 Errores 2.3 Desempeo (Performance) 2.3.1 Tiempo de respuesta de la transaccin 2.4 Soporte 2.4.1 Aplicacin de estndares y metodologas 2.5 Restricciones de diseo 2.5.1 Herramienta de desarrollo 2.5.2 Arquitectura 2.6 Escalabilidad 2.7 Seguridad 2.7.1 Controles de Acceso

CONTENIDO

3 3 3 3 3 3 3 3 4 4 4 4 4 4 4 5 5 5 5 5 5 5 6

UNIVERSIDAD PRIVADA DE TACNA 2010

ESPECIFICACIONES SUPLEMENTARIAS 1. Introduccin 1.1 Propsito El presente documento tiene como propsito definir los requerimientos no funcionales del sistema SySTRONIX. 1.2 Alcance En este documento se describen cada uno de los requerimientos no funcionales del sistema SySTRONIX 1.3 Definiciones, acrnimos y abreviaturas Las definiciones, acrnimos y abreviaturas estn detalladas en el Glosario de Trminos del sistema SySTRONIX. 1.4 Referencias Los documentos que se van a utilizar como referencia son: - SRS - Glosario 2.Suplementarias 2.1 Usabilidad Se debe cubrir y garantizar los siguientes parmetros de uso para la interfaz del usuario: 2.1.1 Estndar de interfaz de pantalla

 Las pantallas de mantenimientos de informacin debern seguir un estndar segn las especificaciones de interfaz de usuario.  Si la funcionalidad lo requiere, las pantallas debern tener la opcin de deshacer cambios realizados, ver documento de especificaciones de interfaz de usuario.  Deben estar estandarizados los nombres de los botones, etiquetas, mensajes de ventanas de dilogo y mensajes de error. De modo que el usuario comprenda los eventos que se presentan en un proceso comn.  Se ofrecer una funcionalidad que permita imprimir todos los resultados que entrega cada bsqueda.  Las secciones que compondrn a cada interfaz grfica aparecern slo cuando sean requeridas. Permitirn que el usuario las minimice. Las ventanas que surjan a partir de otras podrn ser arrastradas por la pantalla.

UNIVERSIDAD PRIVADA DE TACNA 2010

2.1.2 Acceso de ayuda del sistema El sistema mantendr un formulario de ayuda, donde estar detallado el manejo del sistema paso a paso. 2.2 Confiabilidad Se deben cubrir los siguientes requerimientos de funcionalidad: 2.2.1 Disponibilidad El programa podr estar ejecutado todo el tiempo que el cliente desee, al igual en cuanto al horario, este se podr utilizar en cualquier momento. 2.2.2 Tiempo de reparacin Si ocurre una cada del sistema, se tendr un mximo de 1 hora en recuperacin del sistema. 2.2.3 Errores

 No se deben presentar errores como perdida de informacin o que la informacin se grabe de manera inadecuada.  Tasa de fallos o defectos, es el mnimo no ms del 5% de las transacciones, provocado generalmente por los usuarios al ingresar datos no correspondientes.
2.3 Desempeo (Performance) 2.3.1 Tiempo de respuesta de la transaccin Tenemos fijado que el performance de nuestro sistema, ser de muy buenas expectativas.

 En cuanto al Tiempo de Respuesta tenemos programados que las consultas, reportes e ingresos sean en cuestin de segundo.  Veremos que la productividad de la empresa se incrementara debido a la implementacin de nuestro sistema, ya que el tiempo que tarda en dar una respuesta es de menor tiempo que el actual y eso genera ahorro de tiempo.  La Capacidad del sistema ser mejor que el actual debido que al optimizarse y automatizarse nuestro sistema cumplir funciones y capacidades especficas.

UNIVERSIDAD PRIVADA DE TACNA 2010

2.4 Soporte 2.4.1 Aplicacin de estndares y metodologas El desarrollo del sistema SySTRONIX se realizar cumpliendo ciertas metodologas como RUP (proceso unificado del rational). 2.5 Restricciones de diseo 2.5.1 Herramienta de desarrollo

 Herramienta de desarrollo : Visual Studio .NET 2008 Express  Motor de Base de datos : Microsoft SQL Server 2008 Express
2.5.2 Arquitectura La arquitectura del sistema mantendr a los tres usuarios interconectados, permitiendo el libre manejo del sistema y el almacenamiento de los datos en un servidor nico y exclusivo para los datos del sistema. 2.6 Escalabilidad El sistema SySTRONIXse manejara a travs de tres usuarios con diferentes privilegios:

 Administrador: Tiene todos los privilegios sobre el sistema.  Contador: Podr gestionar tareas contables, cuentas contables, tipo de operacin, plantilla contable, asientos contables.  Auxiliar de Contabilidad: solo podr un acceso de lectura a los datos.
2.7 Seguridad Seguridad Nivel Lgico: Los objetivos que se plantearan sern: 1. Permitir el acceso al sistema de aplicacin y archivos Importantes solo a Usuarios que estn debidamente Registrados 2. Permitir la modificacin segn el tipo de usuario (Administrador o contador) y Limitando el acceso de diferentes funciones del Programa a Usuarios no autorizados (auxiliar). 3. Asegurar que se estn utilizados los datos correctos y por el procedimiento correcto 4. Se dispone de un Backup de emergencia para guardar todo el historial realizado en la Base de Datos.

2.7.1 Controles de Acceso Estos controles sern implementados sobre el sistema de aplicacin y la base de datos, en un paquete especfico de seguridad. Para proteger el sistema de

UNIVERSIDAD PRIVADA DE TACNA 2010

aplicacin planteado o restringir modificaciones no autorizadas manteniendo la integridad de la informacin (Restringiendo a Usuarios no autorizados) y para resguardar la informacin confidencial de accesos no autorizados. y Identificacin y Autentificacin Se identificara por seguridad al tipo de usuario al ingresar al sistema de aplicacin, si el usuario no existe, despus de 2 intentos fallidos se cerrara el programa y no podr usarlo dentro de 1 hora la cual enviara un mensaje de Alerta al administrador para tomar en cuenta que un usuario no autorizado quiso ingresar al sistema de aplicacin. Roles El acceso a la informacin tambin puede controlarse por el rol del usuario que requiere dicho acceso. En Nuestro Proyecto Los roles de Usuarios son los siguientes: y Director del proyecto

 Elmer Cruz Arocutipa.


y Analista y programador

 Joao Loayza Bahamondes.  AngelOxacopaGarcia.


Seguridad Nivel Fsico Los objetivos que se plantearan sern:

 Ataque/Riesgo:  Copia y Manipulacin del Software


Amenaza:

 Base de Datos Saturada  Velocidad de transmisin  Falla en el Servidor.


Estrategia Proactiva: y y Predecir posibles daos: Prdida de equipos o Soporte de informacin. Evaluar planes de contingencia: backup de la informacin.

Estrategia Reactiva:

 Evaluar daos: Perdida de hardware e informacin.  Implementar plan de contingencia: recuperar backup.