Sistema de informacin de una constructora |

Ingeniera de Requerimientos

Ernesto Alejandro Lima

Proyecto Constructora

Integrantes:

Jorge Adrin Meneses Barragn

Julio Lemus Lara

Zimram Carren Armenta

Sistema de informacin de una constructora |

ngel Zeferino Hernndez Page 22 | 24

Introduccin

El presente documento trata sobre el desarrollo de un sistema de informacin de obras de una constructora. El cual se puede utilizar para cualquier constructora ya que no est desarrollada para una en particular. En la actualidad la necesidad de llevar un buen control de la informacin conlleva a que las grandes, medianas y pequeas empresas adquieran una herramienta que ayude al control de gastos y evidentemente a su reduccin. Es un punto muy importante y necesario en toda obra en la actualidad para as tener un margen ms amplio y poder llegar a realizar las obras de manera exitosa con detalle de cada uno de sus procesos. En el mercado de este tipo de sistemas de gestin no se encuentra un gran nmero de herramientas, ya que no se ha invertido an en esta va de desarrollo. Adems, las herramientas actuales no engloban el conjunto de la obra sino tratan apartados concretos. En definitiva, tomando todos los datos expuestos en los prrafos anteriores se llega a la conclusin de que hacen falta herramientas que gestionen las obras en su conjunto, permitan reducir costos y adems faciliten el trabajo de los empleados. Es por ello que nace el sistema de gestin de obras de una constructora. Los principales objetivos que pretende conseguir este sistema son: llevar un correcto seguimiento de las obras, unificar la planeacin de una obra, unificar la gestin del personal que trabaja en las diferentes obras, gestionar los materiales que entran y salen, conseguir una mayor eficiencia en el trabajo a desarrollar dentro de la gestin de las diferentes obras, agilizar trmites y plazos en el desarrollo de las obras, realizar una aplicacin intuitiva y de fcil manejo, abaratar costes y centralizar la informacin.Una vez conocidos los objetivos cabe mencionar el tipo de usuario que puede darse en el sistema. Los usuarios se dividen en tres tipos diferentes: el administrador, el cual tiene acceso a todas las opciones de la aplicacin, el trabajador al pie de la obra o coordinador de obras y el directivo encargado de realizar el trmite con el H. Ayuntamiento para que la obra sea aprobada.Estos usuarios podrn realizar numerosos tareas, dependiendo del nivel de acceso asociado a su perfil. Todas las opciones disponibles se engloban en 5 mdulos: Obras, Planos, Permisos, Gastos y Personal. Con estos mdulos se intentar abarcar todos los objetivos y problemticas sugeridas en la gestin de una obra.

INTRODUCCIN.....1

CAPTULO I.- PLANEACIN DEL SISTEMA31.1.Resumen de entrevista31.2.Estudio de viabilidad41.2.1.Viabilidad tcnica41.2.2.Viabilidad econmica41.2.3.Viabilidad operativa41.3.Anlisis FODA5CAPTULO II.- ANLISIS62.1.Requerimientos funcionales62.2.Requerimientos no funcionales82.3.Casos de uso general92.4.Casos de uso detallado122.5.Diagrama de clases132.6.Diagramas de secuencia142.7.Diagrama E-R20CAPTULO III.- DISEO213.1.Base de datos fsica213.2.Diseo de interfaces213.3.Logo y colores21CAPTULO IV.- DESARROLLO224.1.Normalizacin de tablas224.2.Procedimientos almacenados y/o funciones234.3.Conexiones23CAPTULO V.- PRUEBAS23CAPTULO VI.- IMPLANTACIN Y MANTENIMIENTO23

CAPTULO I.- PLANEACIN DEL SISTEMA

1.1. Resumen de entrevista

Una empresa de construcciones desea realizar un sistema de informacin que le permita realizar un correcto seguimiento de las obras. Para ello nos dan la siguiente informacin:

El nuevo sistema debe ser capaz de guardar informacin de las obras ya terminadas, de las que actualmente estn en desarrollo y de las que se piensa comenzar en un futuro breve. Cada obra necesita para su realizacin de diversos tipos de planos: de ejecucin, del sistema elctrico y del sistema de desage (todos los planos disponen de un cdigo que permite ordenarlos dentro de cada tipo de planos, una escala y una fecha de realizacin). Es posible que haya planos que se utilicen en varias obras, pues a veces las casas a construir son idnticas. Dado que las obras se construirn bien en un solar o bien en un terreno, es necesario tener tambin el plano del solar o del terreno a construir, siendo posible en este ltimo caso, que en un terreno se realicen varias obras. Tanto si es un solar o un terreno es necesario disponer de la referencia de su ubicacin.

Toda obra, tanto para iniciar su construccin, como para que se d de paso, necesita disponer del permiso del ayuntamiento. Es, por tanto, necesario conocer si han sido concedidos y cuando. Antes de iniciar la construccin de la obra, la empresa solicitar al ayuntamiento un permiso. ste puede ser concedido o denegado total o parcialmente. Si el permiso es denegado parcialmente, el ayuntamiento dirigir a la empresa constructora un informe con las deficiencias leves encontradas que debe de modificar y los planos donde se deben llevar a cabo. La empresa constructora podr en un plazo breve de tiempo volver a solicitar el mismo permiso, adjuntando los planos modificados e indicando claramente que las deficiencias han sido subsanadas. En caso que en la nueva revisin del permiso se sigan encontrando deficiencias, el procedimiento es el mismo. Si el permiso es denegado totalmente (por deficiencias graves), la empresa constructora debe de realizar nuevos planos, por lo que se considerar una nueva obra, aunque el terreno o solar de construccin sea el mismo. Una vez concedido el permiso, las obras podrn iniciarse en un plazo no superior a seis meses, a partir de su aprobacin.

Debido a que la obra necesita de personal para su realizacin, y dado que hay que pagarles, es necesario conocer en que obras ha trabajado cada obrero y cuantos das trabaj en cada una (tanto en el mes actual como en los anteriores).

Las cuentas de gastos han de ser independientes para cada obra, es decir que, es necesario saber a qu obra se corresponden que facturas y cuales estn pagadas o hay que pagar.

1.2. Estudio de viabilidad

1.2.1. Viabilidad tcnica

El analista debe averiguar si es posible mantener actualizaciones del proyecto y mejoras aun con el objetivo de satisfacer los requerimientos bajo consideracin.

Ventajas:

Es benfico el conocimiento de los desarrolladores u analistas de sistemas, que experiencias han tenido, han trabajado en la misma situacin para tener un mejoras y tiempo estimado dado las experiencias y optimizar los resultados.

Desventajas:

En ocasiones son costosos y redituables pues no cumplen las necesidades con eficiencia.

1.2.2. Viabilidad econmica

1. Tiempo

El tiempo en que tardare en el anlisis y agregando el tiempo en que se tardaran mis colegas en el anlisis del sistema.

2. Costo de estudio

El costo de realizar un estudio de sistemas completo (incluyendo el tiempo de mis colegas con los que trabajare).

3. Costo de tiempo

Costo de tiempo que tardaremos en desarrollar el sistema.

4. Costo estimado de Hardware y Software

PC, laptops, impresoras, programas (en los cuales se va a realizar el proyecto), antivirus, SO, etc.

1.2.3. Viabilidad operativa

Determina si el sistema funcionar y se utilizar una vez que est terminado, si los usuarios estn contentos con este sistema, no tienen problemas con su manejo, por lo general no estn involucrados en la solicitud de un nuevo programa.

1.3. Anlisis FODA

Fortalezas: aspectos tecnolgicos, humanos o situaciones que favorecen el cumplimiento de sus objetivosDebilidades: aspectos tecnolgicos, materiales, humanos o situaciones que dificultan actualmente el logro de sus objetivos, o que impiden lograr un ptimo desarrollo del potencial.Oportunidades: reas en las que su unidad puede explorar posibilidades de optimizacin de su trabajo, nuevos objetivos que la orienten de manera efectiva al cumplimiento de las metas finales.Amenazas: factores del entorno inmediato o mediato, de cualquier naturaleza, que pueden dificultar o impedir el logro de los objetivos.

FORTALEZAS

La empresa cuenta con personal destinado a cada funcin. Sus proyectos de construccin tienen que ser aprobados por el H. Ayuntamiento por lo que los resultados sern de calidad. La empresa cuenta con un sistema, el cual le permite llevar un control total de manera responsable. La empresa cumple con todas sus obligaciones y pagos. El sistema cuenta con seguridad de la informacin. El sistema cumple con todas la metas definidas. El sistema tiene bien definido los roles de los usuarios que lo trabajan.

OPORTUNIDADES

Participa en proyectos de organizaciones municipales. Realiza proyectos no solo en terrenos sino tambin en solares. El sistema puede ser mejorado.

DEBILIDADES

Los trabajadores no cuentan con seguro Respuestas negativas por parte del H. Ayuntamiento. Es una empresa centralizada por lo que no cuentan con sucursal en cada lugar donde labora. El Proceso de capacitacin para el uso del sistema. La curva de aprendizaje desde el punto de vista humano.

AMENAZAS

Puede haber sanciones que repercuten directamente con la empresa si las propuestas de construccin al H. Ayuntamiento son rechazadas demasiadas veces. Que se valla la luz, ya que el sistema tiene que estar funcionando 24/7. Que el sistema sea reemplazado en su totalidad. Que exista alguna contingencia ambiental que ponga el peligro los datos. Competencia de un software mejor.

Tabla 1.3.1.- F.O.D.ACAPTULO II.- ANLISIS

2. 2.1. Requerimientos funcionales

Expresan la naturaleza del funcionamiento del sistema (cmo interacciona el sistema con su entorno y cules van a ser su estado y funcionamiento).

IDPrioridadDescripcin

RF011Agregar una obra nueva

RF021Modificar una obra cuando cambie de estado (futuro, desarrollo finalizada)

RF031Modificar el nombre de una obra, agregar un ayuntamiento

RF041Eliminar una obra cuando sea rechazada

RF051Agregar planos a una obra

RF061Agregar empleados a una obra

RF071Crear un plano (ejecucin, hidrulico, desage o terreno).

RF081Modificar un plano

RF091Eliminar plano

RF101Crear un registro de factura dependiendo de la obra donde haya sido expedido

RF111Dar de alta un empleado

RF121Modificar datos del empleado

RF131Dar de baja un empleado

RF141Agregar ayuntamiento

RF151Modificar datos del ayuntamiento

RF161Eliminar ayuntamiento

RF172Almacenar los resultados que responde el ayuntamiento despus de pedir permiso de construccin

RF182Actualizar las obras y planos dependiendo de la respuesta del ayuntamiento

RF193Consultar las obras futuro

RF203Consultar las obras en desarrollo

RF213Consultar las obras finalizadas

RF223Consultar el total de gastos por obra

RF233Consultar los planos de una obra seleccionada

RF243Consultar por nombre a cada empleado que haya generado un gasto para la empresa

RF254Consultar las obras por municipios

RF264Consultar nmina de los empleados por obra

RF274Consultar la suma total de gastos

RF284Consultar el nmero de empleados que trabajan en la obra

RF294Consultar el nmero de horas que trabaja un empleado

RF304Consultar el nmero de horas que trabajan los empleados en una obra

RF315Consultar de menor a mayor las nminas de los empleados

RF325Consultar si el plano lo utiliza una obra y saber si debe ser modificado

RF335Consultar los planos por tipo

RF345Consultar empleados por puesto en la empresa

RF355Consultar de menor a mayor el total de empleados en cada obra

Tabla 2.1.1 Requerimientos Funcionales

2.2. Requerimientos no funcionales

IDPrioridadDescripcin

RNF011Para la base de datos se har uso de la herramienta SQL Server, no importa la versin

RNF021El sistema deber soportar las versiones de Windows XP en adelante

RNF031Se podr generar usuarios con accesos al sistema

RNF041Se crear un login de acceso

RNF051Se debe contemplar que el nmero de empleados debe soportar cinco mil empleados ya que se pretende abarcar todo el pas

RNF061Deber mostrar un buen desempeo en cada consulta

RNF071Las contraseas debern ser encriptados con el algoritmo MD5 para el acceso al sistema

RNF082Debe haber respaldos peridicos cada mes o lo que se considere necesario por el equipo de desarrollo

RNF093La disponibilidad del sistema debe ser continua

RNF103La aplicacin tendr interfaces y deber ser intuitiva

RNF113La aplicacin se lanzar en paralelo con el actual sistema de la empresa para evitar fallas

Tabla 2.2.1 Requerimientos No Funcionales

2.3. Casos de uso general

Figura 2.3.1 - Diagrama de casos de uso - Empleado

Figura 1.3.2 - Diagrama de casos de uso - Gasto

Figura 2.3.3. - Diagrama de casos de uso - Obra

Figura 2.3.2. - Diagrama de casos de uso - Plano

Figura 2.3.3.- Diagrama de casos de uso - Usuario

Figura 2.3.4.- Diagrama de casos de uso - Permiso2.4. Casos de uso detallado Nombre del proceso: Solicitud de permiso al H. Ayuntamiento. Nombre del subproceso: Iniciar obra. 1) Precondiciones: Que la obra se pretenda construir dentro del H. Ayuntamiento al que se dirige el permiso.

2) Poscondiciones: Actualizar el registro de cuando fue concedido el permiso para la construccin, una vez que fue aprobado por el H. Ayuntamiento.

3) Quin comienza la accin? La constructora.

4) Quin termina la accin? El H. Ayuntamiento

5) Descripcin del caso: Toda obra, tanto para iniciar su construccin, como para que se d de paso, necesita disponer del permiso del ayuntamiento. Es, por tanto, necesario conocer si han sido concedidos y cuando. Antes de iniciar la construccin de la obra, la empresa solicitar al ayuntamiento un permiso. ste puede ser concedido o denegado total o parcialmente. Si el permiso es denegado parcialmente, el ayuntamiento dirigir a la empresa constructora un informe con las deficiencias leves encontradas que debe de modificar y los planos donde se deben llevar a cabo. La empresa constructora podr en un plazo breve de tiempo volver a solicitar el mismo permiso, adjuntando los planos modificados e indicando claramente que las deficiencias han sido subsanadas. En caso que en la nueva revisin del permiso se sigan encontrando deficiencias, el procedimiento es el mismo. Si el permiso es denegado totalmente (por deficiencias graves), la empresa constructora debe de realizar nuevos planos, por lo que se considerar una nueva obra, aunque el terreno o solar de construccin sea el mismo. Una vez concedido el permiso, las obras podrn iniciarse en un plazo no superior a seis meses, a partir de su aprobacin.

6) Excepciones: Si la obra fue denegada totalmente la empresa debe crear una nueva obra. 7)

2.5. Diagrama de clases

Figura 2.5.1. - Diagrama de clases

2.6. Diagramas de secuencia

Figura 2.6.1.- Empleados

Figura 2.6.2.- Gastos

Figura 2.6.3.- Obras

Figura 2.6.4.- Planos

Figura 2.6.5.- Usuarios

Figura 2.6.6.- Permisos

2.7. Diagrama E-R

Figura 2.7.1. - Diagrama Entidad-Relacin

CAPTULO III.- DISEO

3. 3.1. Base de datos fsica

I) Obra ( idObra, Nombre, Ubicacion, idAyuntamiento, idStatusObra)

II) Ayuntamiento ( idAyuntamiento, Nombre, Estado, RFC, Tel, Cel, email)

III) Permiso ( idPermiso, Informe, FechaRecibido, idObra, idTipoPermiso)

IV) TipoPermiso ( idTipoPermiso, Nombre)

V) StatusObra ( idSatusObra, Nombre)

VI) Empleado ( idEmpleado, Nombre, FechaIngreso, SueldoMensual, idPuesto)

VII) Puesto ( IdPuesto, Nombre)

VIII) Plano ( idPlano, Nombre, Escala, Fecha, Adjunto, idTipoPlano)

IX) TipoPlano ( idTipoPlano, Nombre, Ubicacion)

X) Gasto ( idGasto, NoFactura, Monto, Descripcion, idObra)

XI) o_e ( idObra, idEmpleado, FechaHoraEntrada, FechaHoraSalida)

XII) g_e ( idGasto, idEmpleado)

XIII) o_p ( idObra, idPlano)

3.2. Diseo de interfaces

3.3. Logo y colores

Propuesta de logo

4.

CAPTULO IV.- DESARROLLO

4.1. Normalizacin de tablas

use master

create database Constructora

use Constructora

create table Obra (idObra int not null identity(1,1) primary key,Nombre varchar (50) not null,Ubicacion varchar (50) not null,idAyuntamiento int foreign key references Ayuntamiento (idAyuntamiento) not null,idStatusObra int foreign key references StatusObra (idStatusObra) not null);

create table Ayuntamiento (idAyuntamiento int not null identity(1,1) primary key,Nombre varchar (50) not null,Estado varchar (50) not null,RFC varchar (30), Tel int not null,Cel int,email varchar (30));

create table Permiso(idPermiso int not null identity(1,1) primary key,Informe varchar (100) not null,FechaRecibido date not null,idObra int foreign key references Obra (idObra) not null,idTipoPermiso int foreign key references TipoPermiso (idTipoPermiso) not null);

create table TipoPermiso(idTipoPermiso int not null identity(1,1) primary key,Nombre varchar (30) not null);

create table StatusObra(idStatusObra int not null identity(1,1) primary key,Nombre varchar (30) not null);

create table Empleado(idEmpleado int not null identity(1,1) primary key,Nombre varchar (50) not null,FehaIngreso date not null,SueldoMensual decimal (6,2) not null,idPuesto int foreign key references Puesto (idPuesto) not null);

create table Puesto(idPuesto int not null identity(1,1) primary key,Nombre varchar (30) not null);

create table Plano(idPlano int not null identity(1,1) primary key,Nombre varchar (30) not null,Escala varchar (30) not null,Fecha date not null,Adjunto image not null,idTipoPlano int foreign key references TipoPlano (idTipoPlano));

create table TipoPlano(idTipoPlano int not null identity(1,1) primary key,Nombre varchar (30) not null,Ubicacion varchar (30) not null);

create table Gasto(idGasto int not null identity(1,1) primary key,NoFactura int not null,Monto decimal (6,2) not null,Descripcion varchar (100) not null,idObra int foreign key references Obra (idObra) not null);

create table o_e(idObra int foreign key references Obra (idObra) not null,idEmpleado int foreign key references Empleado (idEmpleado) not null,FechaHoraEntrada datetime not null,FechaHoraSalida datetime not null);

create table g_e(idGasto int foreign key references Gasto (idGasto) not null,idEmpleado int foreign key references Empleado (idEmpleado) not null);

create table o_p(idObra int foreign key references Obra (idObra) not null,idPlano int foreign key references Plano (idPlano) not null);

4.2. Procedimientos almacenados y/o funciones

4.3. Conexiones

CAPTULO V.- PRUEBAS

CAPTULO VI.- IMPLANTACIN Y MANTENIMIENTO