UNIVERSIDAD SAN PEDRO

FACULTAD DE INGENIERA
ESCUELA ACADMICO PROFESIONAL DE
INGENIERA INFORMTICA Y DE SISTEMAS

CURSO:

INGENIERA DE SOFTWARE I
Plan General del Proyecto

Implementacin del Software para la empresa

FUNERARIA SAN LUIS
AUTORES:

CERNA PAUCAR, Jean Pierre

RUBIO MENDEZ, Diego Alexis
SOSA PAJUELO, Julio Gonzlo

CICLO:

V
BARRANCA PER
2015

Dedicatoria
Dedicamos primeramente nuestro trabajo a
Dios, por habernos permitido llegar hasta este
punto y habernos dado salud, ser el manantial
de vida y darnos lo necesario para seguir
adelante da a da para lograr nuestros
objetivos, y a nuestros padres ya que gracias a
ellos estamos en este mundo y ejerciendo lo que
nos gusta.

Agradecimient
o
Primero y antes que nada, dar gracias a Dios,
por estar con nosotros en cada paso de
nuestras vidas, por fortalecer, por haber puesto
en nuestro camino a aquellas personas que han
sido nuestro soporte y compaa durante todo
el periodo de estudio.
Agradecer hoy y siempre a nuestros padres por
el apoyo, la alegra y la fortaleza necesaria
para seguir adelante.

ndice
1.

Resumen.............................................................................................. 6

2.

Abstract............................................................................................... 7

3.

Introduccin........................................................................................ 8

4.

Generalidades..................................................................................... 9
4.1.

Nombre Del Proyecto:..................................................................9

4.2.

Descripcin Del Proyecto:...........................................................9

4.3.

Logotipo de la Organizacin:......................................................9

4.4.

Razn social de la Organizacin:.............................................10

4.5.

Descripcin de la Organizacin:...............................................10

4.6.

Organigrama:.............................................................................. 10

4.7.

Situacin Problemtica.............................................................10

4.7.1.

Descripcin de la Organizacin:........................................10

4.7.2.

Seleccin del Problema......................................................11

4.7.4.

Antecedentes del Problema...............................................11

4.8.

4.8.1.

Justificacin Tcnica..........................................................11

4.8.2.

Justificacin Operativa:......................................................12

4.8.3.

Justificacin Econmica.....................................................12

4.9.

6.

Objetivos del Proyecto..............................................................12

4.9.1.

Objetivo General..................................................................12

4.9.2.

Objetivos Especficos:.........................................................12

4.10.

5.

Justificacin del Proyecto........................................................11

Limitaciones del Proyecto........................................................12

4.10.1.

Limitacin Cronolgica:......................................................12

4.10.2.

Limitacin Tecnolgica:......................................................12

4.10.3.

Limitacin Tcnica:.............................................................13

Marco Terico................................................................................... 13
5.1.

SQL server 2014 / modelo entidad-relacin:...........................13

5.2.

Visual Studio 2013:....................................................................21

5.3.

Lenguaje de Programacin C#:................................................22

5.4.

Proceso Unificado de Rational:................................................23

Aplicacin de la Metodologa: Proceso Unificado de Rational. . .30

6.1.

Modelamiento del Negocio.......................................................30

6.1.1.

Pictograma...........................................................................30

6.1.2.

Procesos de Negocio..........................................................31

6.1.3.

Reglas de Negocio...............................................................33

6.1.4.

Visin de Negocio................................................................33

Modelado de Casos de Uso de Negocio............................................35

Especificacin de Casos de Uso de Negocio...................................35
7.

Costos Presupuestos Entregables............................................38

8.

Conclusiones.................................................................................... 39

9.

Recomendaciones............................................................................ 39

10.

Referencias Bibliogrficas y/o Enlaces Web.................................39

11.

Bibliografa........................................................................................ 40

12.

Apndices......................................................................................... 41

13.

Diccionario de Datos.....................................................................51

14.

Documentacion.............................................................................. 51

15.

Cronograma.................................................................................... 51

1. Resumen
En este proyecto se presenta el desarrollo de un sistema de informacin
que permite gestionar las ventas, alquiler, compra y el almacn de
productos en una Empresa Funeraria, de esta manera se ayuda a

organizar, controlar y administrar los productos con los que cuenta la

empresa que fue tomada como modelo, automatizando sus actividades
primarias y mejorando la interaccin con sus clientes.
En la primera seccin se presenta: la identificacin del problema, los
objetivos Generales, especficos, las metodologas de desarrollo de
software. Tambin se justifica la realizacin del presente proyecto. En las
siguientes secciones se identifican: los requerimientos del sistema, los
actores, mdulos, clases de anlisis, el diseo de la interfaz de usuario,
las principales caractersticas de la construccin. Finalmente, se
presentan las conclusiones del presente proyecto y las
recomendaciones para trabajos futuros.

2. Abstract
In this project the development of an information system for managing
sales and warehouse in an enterprise Wood thus presented helps to
organize, control and manage the products that the company has q was

taken as model, automating their primary activities and improving their

customer interactions.
The first section presents the identification of the problem, General,
specific objectives, software development methodologies. The realization
of this project is also justified. The following sections identify: System
requirements, actors, modules, types of analysis, the design of the user
interface, the main features of the building. Finally, the findings of this
project and recommendations for future work are presented.

3. Introduccin
El Proyecto a desarrollar est basado en un sistema para la gestin de
alquiler de Servicios Funerarios y venta de Atades a clientes
particulares y a clientes asegurados ya sea por el SIS, ESSALUD,
AFOCAT, SOAT, La Positiva, ETC.

Funeraria San Luis, tiene como propsito definir con claridad los
requerimientos correspondientes al proyecto Gestin de Alquiler, el
mismo beneficiar tanto a la empresa como al cliente debido a que
agilizar y facilitar el trabajo y esto conducir a la satisfaccin del
cliente.
Cuenta con el control respectivo de stock de cada atad, reposicin y
ventas. As como tambin Recepcin de los pedidos, la facturacin y
manejo de proveedores.

4. Generalidades
4.1.

Nombre Del Proyecto:

Sistema de Ventas, Compra, Alquiler y Almacn en la Funeraria San

Luis SAVFSL

4.2.

Descripcin Del Proyecto:

Este proyecto, consiste en implementar un sistema de venta de atades

y de alquiler de servicios funerarios para una empresa Funeraria. La
base de datos de este sistema o Software, se encuentra alojado en el
motor de base de datos SQL Server 2014, el cual interacta en
tiempo real con el software.

4.3.

4.4.

4.5.

Logotipo de la Organizacin:

Razn social de la Organizacin:

Razn Social: Funeraria San Luis

Nombre:
San Luis
Direccin:
AV. Nicols de Pirola N 247
Celular:
989275090

Descripcin de la Organizacin:

La empresa FUNERARIA se dedica a la venta de diversos tipos de

atades previamente trados (comprado) del proveedor, tambin se
ofrece alquiler de servicios funerarios como capillas ardientes, carro
porta flores, carroza, trmites documentarios etc.

4.6.

Organigrama:
Gerente
Mara
T. Ramrez

Asesor Funerario
Gumercindo Nolasco

Asesor Funerario
David Oyola C.

Asesor Funerario
Vladimir Delgado

Mantenimiento
Luis Cadenas

4.7.
4.7.1.

Situacin Problemtica

Descripcin de la Organizacin:

Todos los procesos son manuales: el inventario en almacn, la

contabilidad de los atades, la compra y venta de atades o
alquiler del servicio funerario, todos esos procesos al realizarse
manualmente se vuelven lentos, adems no haber un control de
ventas y/o alquiler no se sabe con exactitud las ganancias y
prdidas, ingresos y egresos que hay en la empresa. Llegando a
tener una mala administracin y perdiendo as dinero y tiempo.

4.7.2.

Seleccin del Problema:

El problema es la carencia de un sistema automatizado en el

proceso de alquiler el cual presenta una prdida en las ganancias, y en
el tiempo.

4.7.3.

Importancia:

La importancia es brindarle un beneficio hacia la empresa y a la vez

nosotros aprender ms sobre este proyecto al llevarlo a acabo.

4.7.4.

Antecedentes del Problema:

Los registros y controles de contratos, venta y alquiler solo se llevan a

cabo en cuadernos y hojas, las cuales no son almacenadas y por
tanto no permite llevar un control de las ganancias, ni emitir
balances.

4.8.
4.8.1.

Justificacin del Proyecto

Justificacin Tcnica:

El Proyecto a desarrollar, se realiza por la necesidad que tiene la

Funeraria, ya que no cuenta con un buen control de ventas y
Alquiler, optimizando as los servicios que presta el mismo. El

sistema realiza un control de alquiler y ventas, utilizando para ello

la metodologa Orientada a Objetos y el mtodo RUP.

4.8.2.

4.8.3.

4.9.

Justificacin Operativa:

El personal registrar y controlar las ventas, alquiler y

contratos.

Permitir realizar balances, estadsticas de las ganancias y

prdidas.

Justificacin Econmica:
La Gerencia General aprobar y designar presupuesto para el
desarrollo del software.

Objetivos del Proyecto

4.9.1.

Objetivo General: Desarrollar un Sistema de

Alquiler y Venta de una Funeraria (SAVFSL).

4.9.2.

Objetivos Especficos:

Los objetivos especficos de nuestro sistema seran los

siguientes:
a) Automatizar, simplificar y controlar el registro de venta
de atades y alquiler de servicios funerarios
b) Automatizar, simplificar y controlar el registro de
Compra de Atades y/o Materia Prima para la empresa.
c) Obtener reportes de las ventas mensuales.
d) Evitar la redundancia de informacin.
4.10.

Limitaciones del Proyecto

4.10.1.

4.10.2.

4.10.3.

Limitacin Cronolgica:
Para el desarrollo del proyecto denominado SAVFSL,
Hay una limitacin en cuanto al tiempo porque solo se
cuenta con 4 meses (1 ciclo acadmico) de Desarrollo del
proyecto.
Limitacin Tecnolgica:
Se cuenta con dos laptop para 3 integrantes del equipo
de desarrollo e implementacin del software, lo ideal o
recomendable sera que cada integrante cuente con una
computadora u/o laptop para cada uno, e ir avanzando
con mayor rapidez, debido al corto tiempo que se da.
Limitacin Tcnica:
Debido a que el proyecto se va avanzando a lo largo del
semestre acadmico, la falta de conocimientos y/o
prcticas, dificulta el la eficiencia del proyecto, ya que solo
contamos con conocimientos adquiridos dentro de los
cursos enseados.
La informacin de Internet muchas veces carece de
explicaciones contundentes para el mayor entendimiento
de las explicaciones.

5. Marco Terico
5.1.
SQL server 2014 / modelo entidad-relacin:
Microsoft SQL Server es un sistema para la gestin de bases
de datos producido por Microsoft basado en el modelo
relacional. Sus lenguajes para consultas son T-SQL y ANSI
SQL. Microsoft SQL Server constituye la alternativa de
Microsoft a otros potentes sistemas gestores de bases de
datos como son Oracle, PostgreSQL o MySQL.
Caractersticas de Microsoft SQL Server
Soporte de transacciones.
Soporta procedimientos almacenados.
Incluye tambin un entorno grfico de administracin, que
permite el uso de comandos DDL y DML grficamente.
Permite trabajar en modo cliente-servidor, donde la
informacin y datos se alojan en el servidor y los terminales o
clientes de la red slo acceden a la informacin.

Adems permite administrar informacin de otros servidores

de datos.
Este sistema incluye una versin reducida, llamada MSDE con el
mismo motor de base de datos pero orientado a proyectos
ms pequeos, que en sus versiones 2012 y 2014 pasa a ser
el SQL Express Edition, que se distribuye en forma gratuita.
Es comn desarrollar completos proyectos complementando
Microsoft SQL Server y Microsoft Access a travs de los
llamados ADP (Access Data Project). De esta forma se
completa la base de datos (Microsoft SQL Server), con el
entorno de desarrollo (VBA Access), a travs de la
implementacin de aplicaciones de dos capas mediante el uso
de formularios Windows.
En el manejo de SQL mediante lneas de comando se utiliza el
SQLCMD, osql, o PowerShell.
Para el desarrollo de aplicaciones ms complejas (tres o ms
capas), Microsoft SQL Server incluye interfaces de acceso
para varias plataformas de desarrollo, entre ellas .NET, pero el
servidor slo est disponible para Sistemas Operativos.
Programacin T-SQL
T-SQL (Transact-SQL) es el principal medio de interaccin con el
Servidor. Permite realizar las operaciones claves en SQL
Server, incluyendo la creacin y modificacin de esquemas de
la base de datos, la introduccin y edicin de los datos en la
base de datos, as como la administracin del servidor como
tal. Esto se realiza mediante el envo de sentencias de T-SQL
y declaraciones que son procesadas por el servidor y los
resultados (o errores) regresan a la aplicacin cliente.
Cliente Nativo de SQL
Cliente Nativo de SQL es la biblioteca de acceso a datos para los
clientes de Microsoft SQL Server versin 2005 en adelante.
Implementa nativamente soporte para las caractersticas de
SQL Server, incluyendo la ejecucin de la secuencia de datos
tabular, soporte para bases de datos en espejo de SQL
Server, soporte completo para todos los tipos de datos
compatibles con SQL Server, conjuntos de operaciones
asncronas, las notificaciones de consulta, soporte para

cifrado, as como recibir varios conjuntos de resultados en una

sola sesin de base de datos. Cliente Nativo de SQL se utiliza
como extensin de SQL Server plug-ins para otras
tecnologas de acceso de datos, incluyendo ADO u OLE DB.
Cliente Nativo de SQL puede tambin usarse directamente,
pasando por alto las capas de acceso de datos.
Desventajas
En versiones de 32 bits, SQL Server usa Address Windowing
Extensin (AWE) para hacer el direccionamiento por encima
de 4GB. Esto le impide usar la administracin dinmica de
memoria, y slo le permite alojar un mximo de 64 GB de
memoria compartida. Esta limitacin es exclusiva de sistemas
operativos 32 bits; en sistemas operativos 64bits, la memoria
mxima que se puede direccionar en Edicin Estndar es
64Gb y en Edicin Enterprise 4Tb.
Microsoft SQL Server slo maneja compresin de datos en la
Edicin Enterprise.
Microsoft SQL Server requiere de un sistema operativo Microsoft
Windows, por lo que no puede instalarse, por ejemplo, en
servidores Linux.
Base de datos relacional
Una Base de Datos Relacional, es una base de datos que cumple
con el modelo relacional, el cual es el modelo ms utilizado en
la actualidad para implementar bases de datos ya
planificadas. Permiten establecer interconexiones (relaciones)
entre los datos (que estn guardados en tablas), y a travs de
dichas conexiones relacionar los datos de ambas tablas, de
ah proviene su nombre: "Modelo Relacional". Tras ser
postuladas sus bases en 1970 por Edgar Frank Codd, de los
laboratorios IBM en San Jos (California), no tard en
consolidarse como un nuevo paradigma en los modelos de
base de datos.
Caractersticas
Una Base de Datos Relacional se compone de varias tablas o
relaciones.

No pueden existir dos tablas con el mismo nombre ni registro.

Cada tabla es a su vez un conjunto de registros (filas y
columnas).
La relacin entre una tabla padre y un hijo se lleva a cabo por
medio de las claves primarias y ajenas (o forneas).
Las claves primarias son la clave principal de un registro
dentro de una tabla y stas deben cumplir con la integridad de
datos.
Las claves ajenas se colocan en la tabla hija, contienen el
mismo valor que la clave primaria del registro padre; por
medio de stas se hacen las relaciones.

Relaciones Base y Derivadas

En una base de datos relacional, todos los datos se almacenan y
se accede a ellos por medio de relaciones. Las relaciones que
almacenan datos son llamadas "relaciones base" y su
implementacin es llamada "tabla". Otras relaciones no
almacenan datos, pero son calculadas al aplicar operaciones
relacionales. Estas relaciones son llamadas "relaciones
derivadas" y su implementacin es llamada "vista" o
"consulta". Las relaciones derivadas son convenientes ya que
expresan informacin de varias relaciones actuando como si
fuera una sola.
Restricciones
Una restriccin es una limitacin que obliga el cumplimiento de
ciertas condiciones en la base de datos. Algunas no son
determinadas por los usuarios, sino que son inherentemente
definidas por el simple hecho de que la base de datos sea
relacional. Algunas otras restricciones las puede definir el
usuario, por ejemplo, usar un campo con valores enteros entre
1 y 10.
Las restricciones proveen un mtodo de implementar reglas en la
base de datos. Las restricciones limitan los datos que pueden
ser almacenados en las tablas. Usualmente se definen
usando expresiones que dan como resultado un valor
booleano, indicando si los datos satisfacen la restriccin o no.

Las restricciones no son parte formal del modelo relacional, pero

son incluidas porque juegan el rol de organizar mejor los
datos. Las restricciones son muy discutidas junto con los
conceptos relacionales.

Dominios
Un dominio describe un conjunto de posibles valores para cierto
atributo. Como un dominio restringe los valores del atributo,
puede ser considerado como una restriccin.
Matemticamente, atribuir un dominio a un atributo significa
"todos los valores de este atributo deben ser elementos del
conjunto especificado".
Distintos tipos de dominios son: enteros, cadenas de texto, fecha,
no procedurales etc.
Cada tabla puede tener uno o ms campos cuyos valores
identifican de forma nica cada registro de dicha tabla, es
decir, no pueden existir dos o ms registros diferentes cuyos
valores en dichos campos sean idnticos. Este conjunto de
campos se llama clave nica. Pueden existir varias claves
nicas en una determinada tabla, y a cada una de stas suele
llamrsele candidata a clave primaria.
Clave primaria
Una clave primaria es una clave nica elegida entre todas las
candidatas que define unvocamente a todos los dems
atributos de la tabla, para especificar los datos que sern
relacionados con las dems tablas. La forma de hacer esto es
por medio de claves forneas.
Clave fornea
Una clave fornea es una referencia a una clave en otra tabla,
determina la relacin existente en dos tablas. Las claves
forneas no necesitan ser claves nicas en la tabla donde
estn y s a donde estn referenciadas.
Por ejemplo, el cdigo de departamento puede ser una clave
fornea en la tabla de empleados. Se permite que haya varios
empleados en un mismo departamento, pero habr uno y slo

un departamento por cada clave distinta de departamento en

la tabla de empleados.
Clave ndice
Las claves ndices surgen con la necesidad de tener un acceso
ms rpido a los datos. Los ndices pueden ser creados con
cualquier combinacin de campos de una tabla. Las consultas
que filtran registros por medio de estos campos, pueden
encontrar los registros de forma no secuencial usando la clave
ndice.
Las bases de datos relacionales incluyen mltiples tcnicas de
ordenamiento, cada una de ellas es ptima para cierta
distribucin de datos y tamao de la relacin.
Los ndices generalmente no se consideran parte de la base de
datos, pues son un detalle agregado. Sin embargo, las claves
ndices son desarrolladas por el mismo grupo de
programadores que las otras partes de la base de datos.

Procedimientos almacenados
Un procedimiento almacenado es cdigo ejecutable que se
asocia y se almacena con la base de datos. Los
procedimientos almacenados usualmente recogen y
personalizan operaciones comunes, como insertar un registro
dentro de una tabla, recopilar informacin estadstica, o
encapsular clculos complejos. Son frecuentemente usados
por un API por seguridad o simplicidad.
Los procedimientos almacenados no son parte del modelo
relacional, pero todas las implementaciones comerciales los
incluyen.
Estructura
La base de datos se organiza en dos marcadas secciones; el
esquema y los datos (o instancia).
El esquema es la definicin de la estructura de la base de datos y
principalmente almacena los siguientes datos:
El nombre de cada tabla

 El nombre de cada columna

El tipo de dato de cada columna
La tabla a la que pertenece cada columna
Las bases de datos relacionales pasan por un proceso al que se
le conoce como normalizacin, el resultado de dicho proceso
es un esquema que permite que la base de datos sea usada
de manera ptima.
Los datos o instancia es el contenido de la base de datos en un
momento dado. Es en s, el contenido de todos los registros.
Manipulacin de la informacin
Para manipular la informacin utilizamos un lenguaje relacional,
actualmente se cuenta con dos lenguajes formales el lgebra
relacional y el clculo relacional. El lgebra relacional permite
describir la forma de realizar una consulta, en cambio, el
clculo relacional slo indica lo que se desea devolver.
El lenguaje ms comn para construir las consultas a bases de
datos relacionales es SQL (Structured Query Language), un
estndar implementado por los principales motores o sistemas
de gestin de bases de datos relacionales integradas.
En el modelo relacional los atributos deben estar explcitamente
relacionados a un nombre en todas las operaciones, en
cambio, el estndar SQL permite usar columnas sin nombre
en conjuntos de resultados, como el asterisco taquigrfico (*)
como notacin de consultas.
Al contrario del modelo relacional, el estndar SQL requiere que
las columnas tengan un orden definido, lo cual es fcil de
implementar en una computadora, ya que la memoria es
lineal.
Es de notar, sin embargo, que en SQL el orden de las columnas y
los registros devueltos en cierto conjunto de resultado nunca
est garantizado, a no ser que explcitamente sea
especificado por el usuario.

Manejadores de base de datos relacionales

Existe software exclusivamente dedicado a tratar con bases de

datos relacionales. Este software se conoce como SGBD
(Sistema de Gestin de Base de Datos relacional) o RDBMS
(del ingls Relational Database Management System).
Entre los gestores o manejadores actuales ms populares
encontramos:
MySQL
PostgreSQL,
Oracle,
DB2,
INFORMIX,
Interbase,
FireBird,
Sybase
Microsoft SQL Server
Ventajas y desventajas
Ventajas
Provee herramientas que garantizan evitar la duplicidad de
registros.
Garantiza la integridad referencial, as, al eliminar un registro
elimina todos los registros relacionados dependientes.
Favorece la normalizacin por ser ms comprensible y aplicable.
Desventajas
Presentan deficiencias con datos grficos, multimedia, CAD y
sistemas de informacin geogrfica.
No se manipulan de forma manejable los bloques de texto como
tipo de dato.
Las bases de datos orientadas a objetos (BDOO) se propusieron
con el objetivo de satisfacer las necesidades de las
aplicaciones anteriores y as, complementar pero no sustituir a
las bases de datos relacionales.
Diseo de las bases de datos relacionales
El primer paso para crear una base de datos, es planificar el tipo
de informacin que se quiere almacenar en la misma,
teniendo en cuenta dos aspectos: la informacin disponible y
la informacin que necesitamos.
La planificacin de la estructura de la base de datos, en particular
de las tablas, es vital para la gestin efectiva de la misma. El

diseo de la estructura de una tabla consiste en una

descripcin de cada uno de los campos que componen el
registro y los valores o datos que contendr cada uno de esos
campos.
Los campos son los distintos tipos de datos que componen la
tabla, por ejemplo: nombre, apellido, domicilio. La definicin
de un campo requiere: el nombre del campo, el tipo de campo,
el ancho del campo, etc.
Los registros constituyen la informacin que va contenida en los
campos de la tabla, por ejemplo: el nombre del paciente, el
apellido del paciente y la direccin de este. Generalmente los
diferentes tipos de campos que se pueden almacenar son los
siguientes: Texto (caracteres), Numrico (nmeros), Fecha /
Hora, Lgico (informaciones lgicas si/no, verdadero/falso,
etc.), imgenes.
En resumen, el principal aspecto a tener en cuenta durante el
diseo de una tabla es determinar claramente los campos
necesarios, definirlos en forma adecuada con un nombre
especificando su tipo y su longitud.
5.2.
Visual Studio 2013: Microsoft Visual Studio es un
entorno de desarrollo integrado (IDE, por sus siglas en ingls)
para sistemas operativos Windows. Soporta varios lenguajes
de programacin, tales como Visual C++, Visual C#, Visual J#,
y Visual Basic .NET, al igual que entornos de desarrollo web
como ASP.NET, aunque actualmente se han desarrollado las
extensiones necesarias para muchos otros.
Visual Studio permite a los desarrolladores crear aplicaciones,
sitios y aplicaciones web, as como servicios web en cualquier
entorno que soporte la plataforma .NET (a partir de la
versin .NET 2002). As se pueden crear aplicaciones que se
intercomuniquen entre estaciones de trabajo, pginas web y
dispositivos mviles.
Versiones
A partir de la versin 2005 Microsoft ofrece gratuitamente las
Express Editions, que son varias ediciones bsicas separadas
por lenguajes de programacin o plataforma enfocadas para

novatos y entusiastas. Estas ediciones son iguales al entorno

de desarrollo comercial pero sin caractersticas avanzadas.
Dichas ediciones son:
Visual Basic Express Edition
Visual C# Express Edition
Visual C++ Express Edition
Visual J# Express Edition (Desapareci en Visual Studio 2008)
Visual Web Developer Express Edition (para programar en
ASP.NET)
Visual F# (Apareci en Visual Studio 2010, es parecido al J#)*
Adicionalmente, Microsoft ha puesto gratuitamente a disposicin
de todo el mundo una versin reducida de MS SQL Server
llamada SQL Server Express Edition cuyas principales
limitaciones son que no soporta bases de datos superiores a 4
GB de tamao, nicamente se ejecuta en un procesador y
emplea 1 GB de RAM como mximo, y no cuenta con el
Agente de SQL Server.
En el pasado se incluyeron los siguientes productos:
Visual InterDev
Visual J++
Visual FoxPro
Visual SourceSafe

5.3.
Lenguaje de Programacin C#: C# (pronunciado
si Sharp en ingls) es un lenguaje de programacin orientado
a objetos desarrollado y estandarizado por Microsoft como
parte de su plataforma .NET, que despus fue aprobado como
un estndar por la ECMA (ECMA-334) e ISO (ISO/IEC 23270).
C# es uno de los lenguajes de programacin diseados para
la infraestructura de lenguaje comn.
Su sintaxis bsica deriva de C/C++ y utiliza el modelo de objetos
de la plataforma .NET, similar al de Java, aunque incluye
mejoras derivadas de otros lenguajes.
El nombre C Sharp fue inspirado por la notacin musical, donde
'#' (sostenido, en ingls sharp) indica que la nota (C es la nota
do en ingls) es un semitono ms alta, sugiriendo que C# es
superior a C/C++. Adems, el signo '#' se compone de cuatro
signos '+' pegados.

Aunque C# forma parte de la plataforma .NET, sta es una API,

mientras que C# es un lenguaje de programacin
independiente diseado para generar programas sobre dicha
plataforma. Ya existe un compilador implementado que provee
el marco Mono - DotGNU, el cual genera programas para
distintas plataformas como Windows, Unix, Android, iOS,
Windows Phone, Mac OS y GNU/Linux.
Historia de C#
Durante el desarrollo de la plataforma .NET, las bibliotecas de
clases fueron escritas originalmente usando un sistema de
cdigo gestionado llamado Simple Managed C (SMC). En
enero de 1999, Anders Hejlsberg form un equipo con la
misin de desarrollar un nuevo lenguaje de programacin
llamado Cool (Lenguaje C orientado a objetos). Este nombre
tuvo que ser cambiado debido a problemas de marca,
pasando a llamarse C#.2 La biblioteca de clases de la
plataforma .NET fue migrada entonces al nuevo lenguaje.
Hejlsberg lider el proyecto de desarrollo de C#. Anteriormente,
ya haba participado en el desarrollo de otros lenguajes como
Turbo Pascal, J++.
5.4.
Proceso Unificado de Rational: El Proceso
Unificado de Rational (Rational Unified Process en ingls,
habitualmente resumido como RUP) es un proceso de
desarrollo de software desarrollado por la empresa Rational
Software, actualmente propiedad de IBM. Junto con el
Lenguaje Unificado de Modelado UML, constituye la
metodologa estndar ms utilizada para el anlisis, diseo,
implementacin y documentacin de sistemas orientados a
objetos.
El RUP no es un sistema con pasos firmemente establecidos,
sino un conjunto de metodologas adaptables al contexto y
necesidades de cada organizacin.
Tambin se conoce por este nombre al software, tambin
desarrollado por Rational, que incluye informacin entrelazada
de diversos artefactos y descripciones de las diversas
actividades. Est incluido en el Rational Method Composer

(RMC), que permite la personalizacin de acuerdo con las

necesidades.
Originalmente se dise un proceso genrico y de dominio
pblico, el Proceso Unificado, y una especificacin ms
detallada, el Rational Unified Process, que se vendiera como
producto independiente.
Principios de desarrollo
El RUP est basado en 6 principios clave que son los siguientes:
Adaptar el proceso: El proceso de la adaptacin del software.
Equilibrar prioridades: Los requisitos de los diversos participantes
pueden ser diferentes, contradictorios o disputarse recursos
limitados. Debe encontrarse un equilibrio que satisfaga los
deseos de todos. Gracias a este equilibrio se podrn corregir
desacuerdos que surjan en el futuro.
Demostrar valor iterativamente: Los proyectos se entregan,
aunque sea de un modo interno, en etapas iteradas. En cada
iteracin se analiza la opinin de los inversores, la estabilidad
y calidad del producto, y se refina la direccin del proyecto as
como tambin los riesgos involucrados.
Colaboracin entre equipos: El desarrollo de software no lo hace
una nica persona sino mltiples equipos. Debe haber una
comunicacin fluida para coordinar requisitos, desarrollo,
evaluaciones, planes, resultados, etc.
Elevar el nivel de abstraccin: Este principio dominante motiva el
uso de conceptos reutilizables tales como patrn del software,
lenguajes 4GL o marcos de referencia (frameworks) por
nombrar algunos. Esto evita que los ingenieros de software
vayan directamente de los requisitos a la codificacin de
software a la medida del cliente, sin saber con certeza qu
codificar para satisfacer de la mejor manera los requisitos y
sin comenzar desde un principio pensando en la reutilizacin
del cdigo. Un alto nivel de abstraccin tambin permite
discusiones sobre diversos niveles y soluciones
arquitectnicas. stas se pueden acompaar por las
representaciones visuales de la arquitectura, por ejemplo con
el lenguaje UML.

Enfocarse en la calidad: El control de calidad no debe realizarse

al final de cada iteracin, sino en todos los aspectos de la
produccin. El aseguramiento de la calidad forma parte del
proceso de desarrollo y no de un grupo independiente.
Ciclo de vida RUP
El ciclo de vida RUP es una implementacin del Desarrollo en
espiral. Fue creado ensamblando los elementos en
secuencias semis-ordenadas. El ciclo de vida organiza las
tareas en fases e iteraciones.
RUP divide el proceso en cuatro fases, dentro de las cuales se
realizan varias iteraciones en nmero variable segn el
proyecto y en las que se hace un mayor o menor hincapi en
las distintas actividades. En la Figura muestra cmo vara el
esfuerzo asociado a las disciplinas segn la fase en la que se
encuentre el proyecto RUP.
Las primeras iteraciones (en las fases de Inicio y Elaboracin) se
enfocan hacia la comprensin del problema y la tecnologa, la
delimitacin del mbito del proyecto, la eliminacin de los
riesgos crticos, y al establecimiento de una baseline (Lnea
Base) de la arquitectura.
Durante la fase de inicio las iteraciones hacen mayor nfasis en
actividades de modelado del negocio y de requisitos.
En la fase de elaboracin, las iteraciones se orientan al desarrollo
de la baseline de la arquitectura, abarcan ms los flujos de
trabajo de requisitos, modelo de negocios (refinamiento),
anlisis, diseo y una parte de implementacin orientado a la
baseline de la arquitectura.
En la fase de construccin, se lleva a cabo la construccin del
producto por medio de una serie de iteraciones.
Para cada iteracin se seleccionan algunos Casos de Uso, se
refinan su anlisis y diseo y se procede a su implementacin
y pruebas. Se realiza una pequea cascada para cada ciclo.
Se realizan iteraciones hasta que se termine la
implementacin de la nueva versin del producto.
En la fase de transicin se pretende garantizar que se tiene un
producto preparado para su entrega a la comunidad de
usuarios.

Como se puede observar en cada fase participan todas las

disciplinas, pero dependiendo de la fase el esfuerzo dedicado
a una disciplina vara.
Principales caractersticas
Forma disciplinada de asignar tareas y responsabilidades
(quin hace qu, cundo y cmo)
Pretende implementar las mejores prcticas en Ingeniera de
Software
Desarrollo iterativo
Administracin de requisitos
Uso de arquitectura basada en componentes
Control de cambios
Modelado visual del software
Verificacin de la calidad del software
El RUP es un producto de Rational (IBM). Se caracteriza por ser
iterativo e incremental, estar centrado en la arquitectura y
guiado por los casos de uso. Incluye artefactos (que son los
productos tangibles del proceso como por ejemplo, el modelo
de casos de uso, el cdigo fuente, etc.) y roles (papel que
desempea una persona en un determinado momento, una
persona puede desempear distintos roles a lo largo del
proceso).
Fases
Establece oportunidad y alcance
Identifica las entidades externas o actores con las que se trata
Identifica los casos de uso
RUP comprende 2 aspectos importantes por los cuales se
establecen las disciplinas:
'Proceso': Las etapas de esta seccin son: (Revise nuevamente
la grfica)
Modelado de negocio
Requisitos
Anlisis y Diseo
Implementacin
Pruebas
Despliegue
Soporte: En esta parte nos encontramos con las siguientes
etapas:
Gestin del cambio y configuraciones

 Gestin del proyecto

Entorno
La estructura dinmica de RUP es la que permite que ste sea un
proceso de desarrollo fundamentalmente iterativo, y en esta
parte se ven inmersas las 4 fases descritas anteriormente:
Inicio (tambin llamado Incepcin o Concepcin).
Elaboracin.
Desarrollo (tambin llamado Implementacin, Construccin).
Cierre (tambin llamado Transicin).
Fase de Inicio: Esta fase tiene como propsito definir y acordar el
alcance del proyecto con los patrocinadores, identificar los
riesgos asociados al proyecto, proponer una visin muy
general de la arquitectura de software y producir el plan de las
fases y el de iteraciones posteriores.
Fase de elaboracin: En la fase de elaboracin se seleccionan
los casos de uso que permiten definir la arquitectura base del
sistema y se desarrollaran en esta fase, se realiza la
especificacin de los casos de uso seleccionados y el primer
anlisis del dominio del problema, se disea la solucin
preliminar.
Fase de Desarrollo: El propsito de esta fase es completar la
funcionalidad del sistema, para ello se deben clarificar los
requisitos pendientes, administrar los cambios de acuerdo a
las evaluaciones realizados por los usuarios y se realizan las
mejoras para el proyecto.
Fase de Transicin: El propsito de esta fase es asegurar que el
software est disponible para los usuarios finales, ajustar los
errores y defectos encontrados en las pruebas de aceptacin,
capacitar a los usuarios y proveer el soporte tcnico
necesario. Se debe verificar que el producto cumpla con las
especificaciones entregadas por las personas involucradas en
el proyecto.
Artefactos
RUP en cada una de sus fases (pertenecientes a la estructura
dinmica) realiza una serie de artefactos que sirven para
comprender mejor tanto el anlisis como el diseo del sistema
(entre otros). Estos artefactos (entre otros) son los siguientes:
Inicio:

 Documento Visin
Diagramas de caso de uso
Especificacin de Requisitos
Diagrama de Requisitos
Elaboracin:
Documento Arquitectura que trabaja con las siguientes vistas:
Vista Lgica:
Diagrama de clases
Modelo E-R (Si el sistema as lo requiere)
Vista de Implementacin:
Diagrama de Secuencia
Diagrama de estados
Diagrama de Colaboracin
Vista Conceptual

Modelo de dominio
Vista fsica
Mapa de comportamiento a nivel de hardware.
Diseo y desarrollo de casos de uso, o flujos de casos
de uso arquitectnicos
Pruebas de los casos de uso desarrollados, que
demuestran que la arquitectura documentada responde
adecuadamente a requerimientos funcionales y no
funcionales.
Construccin:
Especificacin de requisitos faltantes
Diseo y desarrollo de casos de uso y/o flujos de acuerdo con
la planeacin iterativa
Pruebas de los casos de uso desarrollados, y pruebas de
regresin segn sea el caso
Transicin:
Pruebas finales de aceptacin
Puesta en produccin
Estabilizacin

Historia del RUP

Los orgenes de RUP se remontan al modelo espiral original de
Barry Boehm. Ken Hartman, uno de los contribuidores claves
de RUP colabor con Boehm en la investigacin. En 1995
Rational Software compr una compaa sueca llamada
Objectory AB, fundada por Ivar Jacobson, famoso por haber
incorporado los casos de uso a los mtodos de desarrollo
orientados a objetos. El Rational Unified Process fue el
resultado de una convergencia de Rational Approach y
Objectory (el proceso de la empresa Objectory AB). El primer
resultado de esta fusin fue el Rational Objectory Process, la
primera versin de RUP, fue puesta en el mercado en 1998,
siendo el arquitecto en jefe Philippe Kruchten.
El primer libro para describir el proceso fue titulado "The Unified
Software Development Process (ISBN 0-201-57169-2)" El
Proceso Unificado de Desarrollo de Software (ISBN 0-20157169-2), y publicado en 1999 por Ivar Jacobson, Grady
Booch y James Rumbaugh.

6. Aplicacin de la Metodologa: Proceso Unificado

de Rational
6.1.
Modelamiento del Negocio
6.1.1.
Pictograma:

Compra de Ataudes

almacen de
funeraria

Alquiler y Venta de Servicios

Atencion de los Servicios

Trabajadores

Fin del Servicio

6.1.2. Procesos de Negocio:

a) Proceso de Compra de los Atades:
Lo Primero es cuando el administrador verifica que en el
almacn de los atades no hay suficientes productos de
cada modelo y requiere de un pronto abastecimiento.
Lo Segundo es viajar a la ciudad de lima y buscar
diferentes tipos de atades y cules son sus precios
dependiendo de lo datos requeridos se trae en su mismo
carro porta flores (Peugeot), y en algunas ocasiones se
obtienen atades por pedidos de un lugar establecido
desde la ciudad de lima.
b) Proceso de Almacenaje de los Atades:
Una vez llegada la mercanca, se empieza a separar los
atades por modelo y precio y se coloca en el almacn de
la funeraria.
c) Proceso de Ventas de los Atades:
Se vende los atades mediante los siguientes modelos:
Imperial
Biblia
Americano
Metal
Fgaro Redondo
Redondo Lincoln, otros.
d) Proceso de Alquiler de Servicios Funerarios:
Se brinda alquiler de los servicios funerarios dependiendo
que es lo que desea el cliente mediante estas opciones:
Capilla Ardiente
Carroza
Carro Porta Flores
Cargadores Uniformados
Cremaciones
Movilidad
Tramites Documentativos, otros.
e) Proceso de Alquiler y Venta de Servicios Funerarios:
Entra al alquiler los servicios (previo contrato) y venta de
atades a la medida correcta y modelo que le agrade al

cliente. Cuando el producto ha sido vendido con los

servicios funerarios correctamente se le entrega al cliente
una boleta de compra.
6.1.3.

Reglas de Negocio: Las Reglas de Negocio son:

La persona quien firma el contrato debe ser familiar
cercano del fallecido (Esposo(a), Hijo(a), Hermano(a),
Pap o Mam).
El pago de todo Contrato se realiza primero pagando
un adelanto del precio cuando se hace el contrato y el
da del sepelio cancelan la diferencia y recin le
entregan la boleta o factura.
6.1.4. Visin de Negocio: FUNERARIA SAN LUIS
ser una empresa lder brindando servicios funerarios,
ya sea en la eficiencia de atencin donde la solidez
empresarial y eficiencia productiva basada en sus
recursos humanos y tecnolgicos, garanticen los ms
altos estndares de calidad y servicio para sus clientes y
aseguren un permanente crecimiento y rentabilidad.

METODOLOGIA DE DESARROLLO:
Conocer el procedimiento de venta y alquiler de la empresa hacia
los clientes, recopilar toda la informacin posible y emplearlo para
as generar un buen modelamiento de sistema requerido.

MATRIZ:

Compra De
Atad
Almacenaje
De Atad
Venta De
Atad
Alquiler De
Servicio

x
x

Verificacin De Almacn
Transporte De Atad

Administracin Por Modelos

Verificacin De Seguro
Seleccin De Modelo

x
x
x

Generar Boleta
Verificacin De Seguro
Seleccin De Servicios
Generar Contrato

Ecag.Almacen

Vendedor

Procesos

Administrador

Escenario

Cliente

Actores

x
x

Generar Factura

Modelado de Casos de Uso de Negocio

x
x

Compra De Ataud
Administrador

Cliente

Almacen De Ataud
Alquiler De Servicio
Venta De Ataud

Encargado De Almacen
Vemdedor

Especificacin de Casos de Uso de Negocio:

Verioficacion Almacen
<<include>>
Transporte Ataud
<<include>>

Administradorr

Compra Ataud
Encar. Almacen

Almacenamiento Ataud
<<include>>
Administracion Modelo

Vendedor

<<extend>>
Alquiler Servicio

<<extend>>
Verificacion Seguro
Venta Ataud

<<include>>

<<include>>
<<include>>

<<include>>

Seleccion Modelo
Generar Comprobante

FALTA MAS MODELOS COMO:

SECUENCIA
COLABORACION
ACTIVIDADES
FALTA TAMBIEN EL MODELO FISICO
FALTA EL SCRIPT QUE ESO LO DEBE DE TENER CERNA

Seleccion Servicioi

Y FALTAAA TAMBIEN LAS CAPTURAS DE PANTALLAS DEL DISEO DE LO

PROGRAMA QUE HIZO CERNA

MODELO DE BASE DE DATOS:

7.

Costos Presupuestos Entregables

Total de desarrollo del proyecto: 105 das
Costo: Aprox. S/. 2,800.
Presupuesto:
Dos computadora o Laptop con buen procesador, instalacin de
Windows, instalacin de Visual Studio 2013, instalacin SQL
server exprs, una impresora, 2 USB.
Entregable: Solicitud de aprobacin Proyecto SISVEMA y
cronograma del proyecto.
Descripcin

Inicio

Fin

Delegar funciones a los miembros del

equipo.
Coordinar y supervisar los avances de
las tareas asignadas.
Evaluar el avance.

26/03/2015

Recopilar y suministrar informacin

eficiente al Jefe de Equipo.

01/04/2015

31/03/201
5
19/05/201
5
19/05/201
5
18/04/201
5

Brindar los requerimientos que debe

cumplir la Base de Datos.
Disear la Base de Datos con la
Informacin proporcionada
Implementar el Diagrama de EntidadRelacin de las tablas.
Disear la Interfaz Grfica de Usuario
o GUI.
Implementar las lneas de cdigo de la
GUI.
Realizar iteraciones al software.

19/04/2015

Coordinar con los miembros para al

GUI.
Entregar el software al Lder de

/06/2015

01/04/2015
01/04/2015

01/05/2015
14/05/2015
28/05/2015
04/06/2015
18/06/2015

01/11/2015

22/04/201
5
13/05/201
5
27/05/201
5
03/06/201
5
17/06/201
5
24/06/201
5
30/06/201
5
10/11/2015

Equipo.
Revisar el software, comprobando que
cumpla con los requisitos.
Presentar los entregables.

8.

10/11/2015
15/12/2015

15/12/201
5
15/12/201
5

Conclusiones
Despus de algunos meses desarrollando este sistema, llegamos
a la conclusin que el proyecto resulto ser ms complejo de lo
que pensbamos pero nuestro afn disear un sistemas de
calidad nos impuls a salir adelante.
Con todo el tiempo que Maderera Gustavo lleva atendiendo a
sus clientes, se valieron de cuadernos, para llevar a cabo su
trabajo y atender satisfactoriamente a las necesidades de sus
clientes, pero por ser un sistema manual este necesita ser
sistematizar y por ende ser mejorado y despus de haber
analizado los procesos en los cuales se basan las ventas y
compras emitidos por Maderera Gustavo esperamos llegar a
cumplir las expectativas que tenamos trazadas.

9.
Recomendaciones
Con la finalizacin del presente proyecto se pueden efectuar las
siguientes recomendaciones:
Utilizar las herramientas similares para futuras construcciones
de software
Se debe tener sumo cuidado respecto a las claves de acceso
que son amigables a los usuarios por nica vez
Se debe realizar copias de seguridad de la base de datos
Prohibir el ingreso de personas ajenas a almacn
Sacar circulares internas para el buen manejo e higiene del
computador e implementos

10. Referencias Bibliogrficas y/o Enlaces Web

http://es.wikipedia.org/wiki/Proceso_Unificado_de_Rational
http://es.wikipedia.org/wiki/Microsoft_Visual_Studio
http://es.wikipedia.org/wiki/SQL
http://es.wikipedia.org/wiki/Programaci%C3%B3n_por_capas
http://es.wikipedia.org/wiki/C_Sharp

11.

Bibliografa
Programacin avanzada con Visual C++, de David J.
Kriglinski, George Shepherd y Scot Wingo. Mc GrawHill
A fondo C#, de Tom Archer. Mc Graw-Hill
El lenguaje de programacin C#, de Jos Antonio
Gonzlez Seco. Publicado en Internet:
http://www.josanguapo.com
As es Microsoft Visual Studio .NET, de Microsoft
Corporation. Mc Graw-Hill
Microsoft .NET Framework, de Microsoft Corporation.
Mc Graw-Hill
La Biblia de C# - Anaya
Gua de Arquitectura N-Capas DDD .NET 4.0 - Cesar
de la Torre Llorente, Urial Zorrilla Castro.

12.

Apndices

Formato de encuesta
13. Diccionario de Datos:
TABLA
CLIENTE

DESCRIPCION

TABLAS
RELACIONAD
AS
CLAVE

TRANSACCION

PK

CAMPO

DESCRIPCION

CLI_ID
CLI_NOMBRE
CLI_DOCUMENTO

SE ALMACENA EL ID DEL
CLIENTE
SE ALMACENA EL NOMBRE
CLIENTE

TIPO DE
DATO
INT

SE ALMACENA EL DOCUMENTO
DEL CLIENTE

CLI_DIRECCION
CLI_TELEFONO
CLI_EMAIL

SE ALMACENA LA DIRECCION
DEL CLIENTE
SE ALMACENA EL TELEFONO
DEL CLIENTE
SE ALMACENA EL EMAIL DEL
CLIENTE

TAMA
O

VALOR
DEFEC.

NULO

VARCHA
R

50

NO

CHAR

NO

VARCHA
R

50

NO

CHAR

10

NO

VARCHA
R

50

NO

UNICO

TABLA
DESCRIPCION
TRANSACCION
TABLAS
RELACIONADAS
CLAVE
PK

DOCUMENTO, SEGURO, TRABAJADOR, CLIENTE, DETALLE_TRANSACCION

CAMPO

DESCRIPCION

TRAN_ID

SE ALMACENA EL
ID DE LA
TRANSACCION
SE ALMACENA LA
FECHA DE LA
TRANSACCION

TRAN_FECHA

CLI_ID
TRA_LOGIN
SEG_ID

SE ALMACENA EL
ID DEL CLIENTE
SE ALMACENA EL
LOGIN DE LA
TRANSACCIONS
SE ALMACENA EL
ID DEL SEGURO

DOC_ID
SE ALMACENA EL
ID DEL

TIPO DE
DATO
INT

LONG
ITUD

VALOR
DEFEC.
0

DATATIME

NUL
O

No

INT

No

fecha del
sistema

No

INT

No

INT

No

VARCHAR

50

UNI

DOCUMENTO

TRAN_SERIE

TRAN_NRO
FK

TRAN_TOTAL

TABLA
DOCUMENTO

DESCRIPCION

TABLAS
RELACIONAD
AS
CLAVE

TRANSACCION

PK

CAMPO
DOC_ID
DOC_NOMBRE

TABLA
SEGURO

DESCRIPCION

TABLAS
RELACIONAD
AS
CLAVE

TRANSACCION

PK

CAMPO

SE ALMACENA LA
SERIE DE LA
TRANSACCION
SE ALMACENA EL
NUMERO DE
TRANSACCION
SE ALMACENA EL
TOTAL DE LA
TRANSACCION

TINYINT

No

TINYINT

No

DECIMAL

DESCRIPCION

SEG_NOMBRE
SEG_MONTO

SE ALMACENA EL MONTO DEL

SEGURO

No

LONGI
TUD

VALOR
DEFEC.

INT

SE ALMACENA EL NOMBRE DEL

DOCUMENTO

DESCRIPCION

(18,2)

TIPO DE
DATO

SE ALMACENA EL ID DEL
DOCUMENTO

SE ALMACENA EL ID DEL
SEGURO
SE ALMACENA EL NOMBRE
DEL SEGURO

SEG_ID

VARCHAR

TIPO DE
DATO

NU

50

LONGI
TUD

INT

VALOR
DEFEC.

NULO

VARCHAR

50

DECIMAL

(18,2)

No
B

No

TABLA
TRABAJADOR

DESCRIPCION

TABLAS
RELACIONAD
AS
CLAVE

TRANSACCION, COMPRA
CAMPO

PK

TRA_LOGIN
TRA_CLAVE
TRA_NOMBRE
TRA_DOCUMENTO
TRA_DIRECCION
TRA_TELEFONO
TRA_SEXO
TRA_FCHNAC

FK

DESCRIPCION
SE ALMACENA EL LOGIN DE
LA TRANSACCION
SE ALMACENA LA CLAVE DE
LA TRANSACCION
SE ALMACENA EL NOMBRE DE
LA TRANSACCION
SE ALMACENA EL DOCUMENTO
DE LA TRANSACCION
SE ALMACENA LA
DIRRECCION DE LA
TRANSACCION
SE ALAMACENA EL NUMERO
TELEFONICO DE LA
TRANSACCION
SE ALMACENA EL DOCUMENTO
DEL SEXO EN LA
TRANSACCION
SE ALMACENA LA FECHA DE
NACIMIENTO

TRA_FCHCONT

TABLA
DETALLE_TRANSCC
ION

DESCRIPCION

EL ALMACENA LA FECHA DE
CONTRATO EN LA
TRASACCION

TIPO DE
DATO

LONGITU
D

VALOR
DEFEC.

NUL

VARCHAR

50

VARCHAR

50

VARCHAR

50

No

CHAR

fecha del
sistema

No

VARCHAR

50

No

CHAR

10

No

CHAR

No

No

DATATIME

No

DATATIME

No

TABLAS
RELACIONADAS
CLAVE
PK

TRANSACCION, PRODUCTO
CAMPO
TRAN_ID
PRO_ID
DET_PRECIO
DET_CANTIDAD

TABLA
MODELO

DESCRIPCION

TABLAS
RELACIONADAS
CLAVE

PRODUCTO

PK

CAMPO
MOD_ID
MOD_NOMBRE

TABLA

DESCRIPCION
SE ALMACENA EL ID
DE LA TRASACCION
SE ALMACENA EL ID
DEL PRODUCTO
SE ALMACENA EL
PRECIO DEL DETALLE
SE ALMACENA LA
CANTIDAD DEL
DETALLE

DESCRIPCION
EL ALMACENA EL
MODELO DEL ID
SE ALMACENA EL
NOMBRE DEL MODELO

TIPO DE
DATO

LONGI
TUD

INT

VALOR
DEFEC.

No

MONEY
INT

LONGI
TUD

INT
VARCHAR

INT

TIPO DE
DATO

NULO

No

fecha del
sistema

No

VALOR
DEFEC.

NULO

0
50

No

DESCRIPCION

TIPO
TABLAS
RELACIONADAS
CLAVE
PK

PRODUCTO
CAMPO

DESCRIPCION

TIPO_ID

SE ALMACENA EL
TIPO DEL PRODUCTO

TIPO_NOMBRE

SE ALMACENA EL
TIPO DEL NOMBRE

TIPO DE
DATO

LONG
ITUD

INT
VARCHAR

VALOR
DEFEC.

NULO

0
50

No

TABLA
MOVIMIENTO
TABLAS
RELACIONADAS
CLAVE
PK

DESCRIPCION
PRODUCTO, ALMACEN
CAMPO

DESCRIPCION
SE ALMACENA EL ID
DEL MOVIMIENTO

MOV_ID
MOV_TIPO

MOV_CANTIDAD
PRO_ID
ALM_ID

TABLA
ALMACEN
TABLAS
RELACIONADAS
CLAVE
PK

LONGIT
UD

VALOR
DEFEC.

INT

CAMPO

VARCHAR

50

No

INT

No

INT

No

INT

No

DESCRIPCION

ALM_ID

ALM_STOCK

SE ALMACENA EL ID
DEL ALMACEN
SE ALMANCENA EL
NOMBRE DEL ALMACEN
SE ALMACENA EL STOCK

TIPO DE
DATO

LONGI
TUD

VALOR
DEFEC.

INT
VARCHAR

50

No

INT

No

DESCRIPCION

PK

TRABAJADOR, PROVEEDOR
CAMPO

DESCRIPCION

TIPO
DE
DATO

MOV_ID

SE ALMACENA EL
ID DEL MOVIENTO

INT

MOV_TIPO

SE ALMACENA EL
TIPO DEL
MOVIMIENTO

VARCHAR

MOV_CANT
IDAD

SE ALMACENA LA
CANTIDAD DEL
MOVIENTO

INT

LON
GIT
UD

VALOR
DEFEC.

NUL
O

50

NULO

COMPRA
TABLAS
RELACIONADAS
CLAVE

NULO

DESCRIPCION

ALM_NOMBRE

TABLA

SE ALMACENA EL
TIPO DEL
MOVIMIENTO
SE ALMACENA LA
CANTIDAD DEL
MOVIMIENTO
SE ALAMCENA EL ID
DEL PRODCUTO
SE ALMACENA EL ID
DEL ALMACENAMIENTO

TIPO DE
DATO

No

No

UNI
CO

PRO_ID

SE ALMACENA EL
ID DEL PRODUCTO

INT

No

ALM_ID

SE ALMACENA DEL
ID DEL ALMACEN

INT

No

TABLA
PROVEEDOR

DESCRIPCION

TABLAS
RELACIONADAS
CLAVE

COMPRA

PK

CAMPO
COM_ID
TRA_ID
COM_FECH
PROV_ID
COM_TOTAL

DESCRIPCION
SE ALMACENA EL ID
DE LA COMPRA
SE ALMACENA DEL ID
DE LA TRANSACCION
SE ALMACENA LA
FECHA DE LA COMPRA
SE ALMACENA EL ID
DEL PRVEEDOR
SE ALMACENA EL
TOTAL DE LA COMPRA

TIPO DE
DATO
INT
VARCHAR

COMPRA, PROVEEDOR, TRABAJADOR, PRODUCTO

PRO_ID
COM_ID
DET_CANT
DET_CANT

SE ALMACENA ID DEL
PROVEEDOR
SE ALMACENA ID DE
LA COMPRA
SE ALMACENA LA
CANTIDAD DEL
DETALLE
SE ALMACENA LA
CANTIDAD DEL
DETALLE

50

No

No

DECIMAL

TIPO DE
DATO

(18,2)

LONGI
TUD

INT

No

VALOR
DEFEC.

NULO

INT

No

INT

No

DECIMAL

UN

INT

TABLAS
RELACIONADAS
CLAVE
PK

NULO

No

DESCRIPCION

DESCRIPCION

VALOR
DEFEC.

DATE

TABLA
DETALLE_COMPRA

CAMPO

LONG
ITUD

(18,2)

No

14.

DOCUMENTACIN DE CASOS DE USO:

PREFIJO
CUS.01
CUS.02
CUS.03
CUS.04

Realizacion
Realizacion
Realizacion
Realizacion

CASO DE USO

Realizacion De Venta De Ataud

Actores:

Cliente, Vendedor.

Tipo:

Principal

Descripcin
Precondiciones

De
De
De
De

CASO DE USO
Venta De Ataud
Almacenaje De Ataud
Compra De Ataud
Alquiler De Servicios

Este Caso de uso el cliente selecciona el atad para luego

proceder a su compra ante el personal de atencin al cliente que
est a cargo en ese momento.
1 El Cliente debe de seleccionar el modelo de atad.
2 En El Almacen Tiene que Haber el atad que el cliente desea.

Flujo bsico
1

Usuario
Ingresa Al establecimiento el
cliente.

Sistema

El Cliente Selecciona el modelo

de atad que desea comprar.

Caso de Uso
Actores
Tipo

El Vendedor hace el documento de venta

al cliente.

El vendedor le hace entrega del atad al

cliente.

Realizacion De Almacenaje De Ataud

Encargado De Almacen
Principal

Descripcin

En este caso de uso el encargado de almacen adminstra los atuedes

comprados por modelo.

Precondiciones
1. Tiene que haber atudes en la empresa.

Flujo bsico
Usuario

Sistema
1. Llega los atades al establecimiento.

2. El encargado del alamacen administra los

atades por modelo.

Caso de Uso
Actores
Tipo
Descripcin
Precondiciones

Realizacion De Compra De Ataud

Administrador, Encargado de almacen

Principal
En este caso de uso el adiminuistrador hace la compra del ataud

1. El Encargado del almacen debe informar la falta de atades en el almacen.

2. Se debe de tner un presupuesto para la compra.

Flujo bsico
Usuario

Sistema
1. El encargado del almacen revisa en el alamcen
que falte algn modelo de ataud.

2. El administrador se dirige a la ciudad de lima a

hacer la compra de atad en el proveedor.
3. Se transporta el atuad hasta el establecimiento.

Caso de Uso
Actores
Tipo
Descripcin

Realizacion De Alquiler De Servicios

Vendedor, Cliente.
Principal
En este caso de uso el cliente hace el alquiler de servicio.

Precondiciones
1. Se debe de contar con los servicios disponibles.

Flujo bsico
Usuario
1. El
Cliente
establecimiento.

Sistema
Ingresa

al

2. El Cliente debe seleccionar el

servicios que desea alquilar.

3. Al Empleado Genera el documento de

alquiler.

4. El empleado le hace entrega de los servicios

al cliente que le proporciona la direccin
donde se hara uso de los servicios
funerarios.

15.

Cronograma de Actividades:

FASES
ACTIVIDADES

DURACIN DEL PROYECTO

F1

MODELAMIENTO DE NEGOCIO

1.
2.
3.
4.
5.
6.

Identificacin del problema.

Estudio de factibilidad
Elaboracin del Plan Preliminar del Proyecto.
Definicin de objetivos y metas.
Definicin de estrategias y polticas.
Modelamiento del negocio

REQUERIMIENTOS

7. Estudio de factibilidad
8. Recopilacin y Validacin de informacin.
9. Identificacin y priorizacin de requerimientos
ANALISIS Y DISEO

10.Modelamiento de requerimientos.
11.Modelamiento conceptual de entidades.
12.Diseo del Modelo Relacional.
13.Modelado de los diagrama de clases.
CONSTRUCCION

14.Diseo de las interfaces.

15.Implementacin de la base de datos.
16.Elaboracin y entrega de documentacin
17.Evaluacin de objetivos alcanzados.
PRUEBAS

FASES: F1. Inicio

F2. Elaboracin

DURACIN DEL PROYECTO:

1-9 Semanas

F2