Segunda revicion de formato

3.1    Requisitos comunes de los interfaces
En este documento especificamos los requisitos técnicos y  metas para el desarrollo del           sistema así como servicios que ofrecerá.

3.1.1    Interfaces de usuario
En este punto indicaremos detalles de la interfaz del modulo, en la cual constara de colores representativos de la institución para que este mas acorde con la institución pero también cuidando que la vista se agradable y un  diseño sencillo ya que la vista realmente no es lo mas importante si no el funcionamiento del modulo igualmente se tratara  de que la interfaz sea sencilla y simple de entender lo que usualmente se maneja como una interfaz amigable.
Los requisitos de interface de usuario fueron adquiridos por el equipo desarrollador por medio de una entrevista la cual fe desarrollada con anterioridad en la cual el cliente nos da a conocer  todos los requisitos necesarios para el manejo y configuración de las interfaces necesarias para que el usuario pueda usarlo sin confundirse lo cual esto reduciría el índice de errores  en las interfaces. El cliente también  especifico cada una de las secciones que tendrá que tener el modulo  para que cada usuario pueda sentiré familiarizado con el sistema y no tenga dudas según su consulta ya que sabemos que el sistema está relacionado  con el pago de cada persona que consulte el sistema.

3.1.2    Interfaces de hardware
Componente    Minimo     recomendado
Cpu     Intel® Core 2 Duo, 2,6 GHz o
Dual Core Xeon 2,6 GHz    Quad Core Intel® Xeon® 3,1 GHz
Disco duro    250 SATA 7,2K rpm    3 x 160 Gb SCSI, Ultra 320 SCSI o SATA,
15 000 rpm, con una configuración RAID 5
Dvd-rom    16 con cable SATA     48 DVD+/- RW
Memoria    1GB    12GB
NIC    Tarjeta de red soportada por la red instalada
100 Mb/s para un rendimiento óptimo   
COMPUTADORA    Si el servidor es una computadora autónoma, debería elegirse un modelo
“torre”; de lo contrario, debería poder almacenarse en un rack. Debería tener
una arquitectura servidor, con la posibilidad de instalar discos y memoria adicionales.
La posibilidad de bloquear el teclado y el enchufe eléctrico sería
una ventaja.   
       

Las especificaciones de hardware para servidores que utilizan otro sistema operativo de red deberían tener igual capacidad y rendimiento.

Componente    Minimo     recomendado
Cpu     Intel® Core 2 Duo, 2,6 GHz o
Dual Core Xeon 2,6 GHz    Quad Core Intel® Xeon® 3,1 GHz
Disco duro    250 SATA 7,2K rpm    3 x 160 Gb SCSI, Ultra 320 SCSI o SATA,
15 000 rpm, con una configuración RAID 5
Dvd-rom    16 con cable SATA     48 DVD+/- RW
Memoria    1GB    12GB
NIC    Tarjeta de red soportada por la red instalada
100 Mb/s para un rendimiento óptimo   
COMPUTADORA    Si el servidor es una computadora autónoma, debería elegirse un modelo
“torre”; de lo contrario, debería poder almacenarse en un rack. Debería tener
una arquitectura servidor, con la posibilidad de instalar discos y memoria adicionales.
La posibilidad de bloquear el teclado y el enchufe eléctrico sería
una ventaja.   
       

Componente    Minimo     recomendado
Cpu     Intel® Core 2 Duo, 2,6 GHz o
Dual Core Xeon 2,6 GHz    Quad Core Intel® Xeon® 3,1 GHz
Disco duro    250 SATA 7,2K rpm    3 x 160 Gb SCSI, Ultra 320 SCSI o SATA,
15 000 rpm, con una configuración RAID 5
Dvd-rom    16 con cable SATA     48 DVD+/- RW
Memoria    1GB    12GB
NIC    Tarjeta de red soportada por la red instalada
100 Mb/s para un rendimiento óptimo   
COMPUTADORA    Si el servidor es una computadora autónoma, debería elegirse un modelo

3.1.3    Interfaces de software
C♯ o C# (pronunciado si sharp en inglés) es un lenguaje de programación orientado a objetos desarrollado y estandarizado por Microsoft como parte de su plataforma .NET, que después fue aprobado como un estándar por la ECMA e ISO.
C♯, como parte de la plataforma.NET, está normalizado por ECMA desde diciembre de 2001 (C# Language Specification «Especificación del lenguaje C♯»). El 7 de noviembre de 2005 salió la versión 2.0 del lenguaje, que incluía mejoras tales como tipos genéricos, métodos anónimos, iteradores, tipos parciales y tipos anulables.
Aunque C♯ forma parte de la plataforma.NET, ésta es una interfaz de programación de aplicaciones (API), mientras que C♯ es un lenguaje de programación independiente diseñado para generar programas sobre dicha plataforma. Ya existe un compilador implementado que provee el marco de DotGNU – Mono que genera programas para distintas plataformas como Win32, UNIX y Linux.

SERVIDOR DE BASE DE DATOS:
Nuestro sistema sera implementado en una base de datos mysql la cual consistira en:
MySQL es un sistema de gestión de base de datos relacional, multihilo y multiusuario con más de seis millones de instalaciones. MySQL AB —desde enero de 2008 una subsidiaria de Sun Microsystems y ésta a su vez de Oracle Corporation desde abril de 2009— desarrolla MySQL como software libre en un esquema de licenciamiento dual.
Por un lado se ofrece bajo la GNU GPL para cualquier uso compatible con esta licencia, pero para aquellas empresas que quieran incorporarlo en productos privativos deben comprar a la empresa una licencia específica que les permita este uso. Está desarrollado en su mayor parte en ANSI C.
el cual funciona como servidor de impresora y servidor de copias de seguridad (back-up). Es posible que se necesite memoria adicional y espacio adicional en el disco duro si se instalan otros programas. Las especificaciones de hardware para servidores que utilizan otro sistema operativo de red deberían tener igual capacidad y rendimiento.
3.1.4    Interfaces de comunicación
Este sistema va a trabajar de forma unitaria con procesos de información internos  del sistema.  Por lo tanto este sistema no es necesario que cuente con algún tipo de protocolo de comunicación.

3.2    Requisitos funcionales
                    

3.2.1 El sistema debe desarrollarse para SO Microsoft Windows.
3.2.2 El sistema debe tener una interfaz amigable.
3.2.3    El sistema debe tener conexión a  bases de datos.
3.2.4 El sistema debe ser capaz de realizar operaciones matemáticas de 3.2.5 forma automática para la elaboración de la nómina.
3.2.6    Es necesario que realice operaciones para automatizar y agilizar la elaboración de la nómina.
3.2.7    El sistema debe ser mostrar a un informe a detalle de las operaciones matemáticas mencionadas en el punto anterior, para  el administrador.
3.2.8    El sistema debe mostrar la información de cada trabajador.
       
3.2.9    El sistema debe mostrar si el empleado tuvo faltas o retardos.
3.2.10 Esto para que en sistema se refleje en la nómina si el empleado tuvo alguna de estas situaciones y lo pueda corroborar en su recibo y un mejor control del administrador.
3.2.11 El sistema debe mostrar si el empleado tuvo algún incentivo o gratificación económica.
3.2.12    El sistema debe mostrar las prestaciones que percibe el empleado.
3.2.13    El sistema debe mostrar si el empleado presenta alguna deducción.
3.2.14    El sistema debe mostrar el periodo de tiempo por el cual se le está pagando al trabajador.
3.2.15    El sistema debe poder  guardar registros de  pagos anteriores.
3.2.16    El sistema  debe poder  mostrar registros de  pagos anteriores.
3.2.17    El sistema debe permitir  modificación de registros de pago en caso de que sea necesario.
3.2.18    El sistema debe permitir  modificación de la información de los empleados.
3.2.19    El sistema debe permitir  realizar altas de nuevos empleados que se agreguen a la nómina.
3.2.20 El sistema debe permitir  realizar bajas de  empleados que salgan de la  nómina.
3.2.21    El sistema debe tener una cuenta para el administrador la cual le de todos los privilegios.
3.2.22    El sistema debe tener una cuenta general para el demás personal que lo opere
3.2.23    La cuenta general debe tener restricciones, no podrá hacer altas, bajas ni modificaciones de usuarios, ni modificaciones de nómina.
3.2.24    La cuenta de administrador debe solicitar un usuario y contraseña para el acceso.

3.2.25 El sistema debe mostrar el tiempo laborado.
3.3    Requisitos no funcionales
3.3.1    Requisitos de rendimiento
En nuestro sistema no se podran conectar varios usuarios simultaneamente ya que es un sistema de cliente/servidor. 
La mayoria de las transacciones que este sistema debe realizar de seben ejecutar en un lapso menor de 1 segundo para que el operador no tenga que esperar terminar una trasaccion para iniciar otra.
3.3.2    Seguridad
Para que un usuario pueda ingresar al sistema y hacer modificaciones, este le pide al usuario una contraseña y ademas que debe tener una cuenta como administrador, por lo cual solo usuarios autorizados podran ingresar a el sistema y asi poder evitar modificaciones maliciosas, destruccion de la base de datos o que afecte a la integridad del sistema.

3.3.3    Fiabilidad
El sistema es fiable debido a que el usuario para poder ingresar a el necesita de una contraseña y ser administrador.

3.3.4    Disponibilidad
El sistema debe estar disponible el 95 % del turno laboral del operador, para que este pueda ingresar a la hora que nesesite realizar una consulta de algun trabajador o hacer una observacion del empleado, asi como para elaborar la nomina del mismo.
3.3.5    Mantenibilidad

En caso de que el sistema efectue algun fallo o que no arroje los resultados esperados o que no funcione como funcionaba inicialmente, solo el desarrollador del software podra darle mantenimiento necesario para que el sistema funcione correctamente de nuevo.
3.3.6    Portabilidad
El sistema debe de ser lo mas portable posible para que el usuario pueda trasladarlo en diferentes equipos de su empresa y que sea facil de instalar en diferentes sistemas operativos asi en caso de algun fallo o cambio de equipo de cómputo no se presenten problemas de  instalacion y poder seguir utilizando el software.  
3.4    Otros requisitos
             No se han planteado otros requisitos.
4    Apéndices

Lo relevante de este proyecto puede ser lo siguiente:
–    El equipo dividió el proyecto en partes, esto, para que el proyecto se generara en menos tiempo y con más control.
–    En este equipo realizaremos varias reuniones para poder saber el avance del proyecto y más que nada para revisar el trabajo de cada uno de los integrantes.
–    En este proyecto se han generado diferentes conflictos, porque en algunos momentos la información entregada por cada uno de los integrantes no era coherente algo que se necesitaba y por lógica nos veíamos en la necesidad de volver a revisar el documento y asesorar a la persona a la cual se le entrego dicha investigación.

NOTA: Formato completo en google docs. 

https://docs.google.com/document/edit?id=1uXKNuOdo0EXfz71UaxefYO-Bq4NtD0mVgRnltZRCvTs&hl=es&pli=1#