Embed Size (px)
Citation preview
UNIVERSIDAD MAYOR DE SAN ANDRESFACULTAD DE CIENCIAS PURAS Y NATURALES
CARRERA DE INFORMATICA
MATERIA INF -162 ANÁLISIS Y DISEÑO PARA EL CONTROL DE COMPRA Y VENTA DE
LLANTAINTEGRANTES:1. Arpazi Vito Grover Christian CI. 8310947 LP. [email protected]. Colmena Queso Edwin Luis CI. 6051475 LP. [email protected]. Guaycho Quispe Edgar Cesar CI. 4848199 LP. [email protected]. Lopez Blanco Bryan N. CI. 8399155 LP. [email protected]. Tucupa Miranda Gonzalo CI. 3460989 LP. [email protected]
MATERIA: INF-162 (Análisis y Diseño de Sistemas)FACILITADOR: Mg. Sc. Miguel Cotaña Mier
1
1. CAPITULO I
2
1.1. INTRODUCCION
El aumento de la tecnología requiere nuevas formas de realizar
procedimientos en cualquier tipo de organización, las técnicas de
automatización son muy conocidas para el agrupamiento de datos en un solo
lugar; trayendo ventajas como la reducción de tiempo,costos, eliminación de
tiempos muertos, mayor accesibilidad a la información y otros.
Algunas características del presente proyecto son:
Inclusión de nuevas técnicas de agrupamiento de datos
Accesibilidad de información mínima pero importante para personas
externas al sistema.
Reducción de tiempoen entrega de información; cualquiera sea el
nivel de acceso al sistema.
Acceso a la información
Además podemos citar que lamentablemente hoy en día todavía existen
muchas instituciones sean privadas o públicas que no terminan de utilizar la
TIC’S disponibles a favor de ellas y de esta forma mejorar sus procesos de
gestión empresarial. Es así que existen procesos de control que se pueden
automatizar dentro de cualquier tipo de empresa.
Así es necesario implementar un sistema de ventas e inventarios para llantas
que puedan atender las demandas de la institución, para el mejor manejo y
control de información.
3
1.2.ANTECEDENTES
Actualmente la llantería San Carlos Importaciones no cuenta con ningún
software automatizado.
Además es importante resaltar que existen programas similares que
fueron desarrollados para diferentes empresas que proveen llantas, el
siguiente cuadro muestra algunos delsoftware que fueron desarrollados
con el fin de automatizar el control de varios procesos en una empresa de
distribución de llantas.
WIFCODOR
GOOD YEAR
SOCOSER
4
1.3.PLANTEAMIENTO DEL PROBLEMA
1.3.1. PROBLEMA PRINCIPAL
El sistema de compra y venta de llantas existente es manual y no es el
adecuado. Para su mejor comprensión vea el siguiente árbol de
problemas.
5
El sistema de compra y venta de llantas existente
es manual y no es el adecuado
Demora en la atención a los clientes
La información de existencias no es oportuna
ni confiable.
El registró y control de llantas en stock es
inadecuado
Deficiencias en la adquisición de productos
Perdida en ganancias La emisión de nota de venta y/o facture es
manual
Falta de asesoramiento para la adquisición de un
software
1.3.2. PROBLEMAS SECUNDARIOS
a. Demora en la atención a los clientes
b. Existe perdida en ganancias
c. La información de existencias no es oportuna ni confiable.
d. La emisión de nota de venta y/o facture es manual
e. El registro y control de llantas en stock es inadecuado
f. Deficiencias en la adquisición de productos
g. Falta de asesoramiento para la adquisición de un software
6
1.4.OBJETIVOS
1.4.1. OBJETIVO PRINCIPAL
Desarrollar el análisis y diseño para el control de compras y ventas llantas,
de tal modo que la información sea accesible en cualquier momento del día,
cuando se haga la solicitud por parte del dueño y los encargados de venta.
Para su mejor comprensión ver, tabla siguiente:
7
Desarrollar el análisis y diseño para el control de compras y ventas llantas, de tal modo que la información sea accesible en
cualquier momento del día, cuando se haga la solicitud por parte del dueño y los
encargados de venta.
Desarrollar módulos de consulta de llantas los cual permita que un
cliente al solicitar información sobre una llanta espere un tiempo
reducido para conocer la respuesta a su interrogante.
Desarrollar módulos de consulta de precios, costos de las llantas.
Crear una base de datos para compras y ventas,
que permitan generar de forma automática los kardex de cada llanta.
Diseñar una base de datos de proveedores
Desarrollar módulos para el cálculo de venta
y compra del día.
Desarrollar módulos que permitan el registro de
compra y venta, y que a través de los cuales se pueda generar de forma computarizada las notas
de entrada y salida.
Proveer de asesoramiento tecnológico y capacitación
constante al gerente propietario de la llantería.
1.4.2. OBJETIVOS SECUNDARIOS
a. Desarrollar módulos de consulta de llantas los cual permita que un cliente
al solicitar información sobre una llanta espere un tiempo reducido para
conocer la respuesta a su interrogante.
b. Desarrollar módulos para el cálculo de venta y compra del día.
c. Desarrollar módulos de consulta de precios, costos de las llantas
d. Desarrollar módulos que permitan el registro de compra y venta, y que a
través de los cuales se pueda generar de forma computarizada las notas
de entrada y salida.
e. Crear una base de datos para compras y ventas, que permitan generar
de forma automática los kardex de cada llanta.
f. Diseñar una base de datos de proveedores.
g. Proveer de asesoramiento tecnológico y capacitación constante al
gerente propietario de la llantería
8
1.5.METODOLOGIA, METODOS Y TECNICAS
1.5.1. METODOLOGIA
Para el desarrollo del presente proyecto se emplearan las siguientes
metodologías:
Metodología de investigación mixta
Lenguaje Unificado de Modelado(UML, UnifiedModelingLanguaje)
1.5.2. METODOLOGIA DE INVESTIGACION MIXTA
El enfoque mixto de la investigación implica un proceso de recolección,
análisis y vinculación de datos cualitativos y cuantitativos de un mismo
estudio; para responder a un planteamiento de problema.
Cabe destacar que el enfoque mixto va másallá de la simple recolección de
datos de diferentes medios sobre el mismo fenómeno, este implica desde el
planteamiento del problema mezclar la lógica inductiva y deductiva.
1.5.3. LENGUAJE UNIFICADO DE MODELADO(UML)
El lenguaje UML(lenguaje unificado de modelado) proporciona las
herramientas necesarias para poder obtener los planos de software, además
este lenguaje se puede utilizar para visualizar, especificar, construir y
documentar todos los artefactos que compone un sistema de información,
hasta aplicaciones distribuidas basadas en Web, pasando por sistemas
empotrados de tiempo real.
UML es un lenguaje por que proporciona un vocabulario y las reglas para
utilizarlo, además es un lenguaje de modelado; lo que significa que el
9
vocabulario y las reglas se utilizan para la representación que abarca todas
las fases del ciclo de vida de un proyecto, soporta además diferentes
maneras de visualización dependiendo de quien tenga que interpretar los
planos y en qué fase del proyecto se encuentre.
1.6.METODOS
1.6.1. METODOS ANALITICOS
El método analítico es aquel método de investigación que consiste en la
desmembración de un todo descomponiéndolo en sus partes o elementos
para observar las causas, la naturaleza y los efectos. El análisis es la
observación y examen de un hecho en particular. Es necesario conocer la
naturaleza del fenómeno y objeto que se estudia para comprender su
esencia. Este método nos permite conocer más del objeto de estudio, con lo
cual se puede explicar, hacer analogías, comprender mejor su
comportamiento y establecer nuevas teorías.
Este método se usara en la realización de la descripción y en el transcurso
del proyecto.
1.6.2. METODO DEDUCTIVO
Este método permite pasar de afirmaciones de carácter general a hechos
particulares. Deductivo significa descender, es decir parte de lo general a lo
particular.
Este método será usado como parte de las metodologías de la investigación
para el proceso de ingeniería del proyecto.
10
1.6.3. METODO INDUCTIVO
Involucran aquellos procedimientos que van de lo simple a lo compuesto, es
decir va de los hechos particulares a afirmaciones de carácter general. Se
caracterizan por que tienen una síntesis.
Este método será usado en los procesos y actividades que se plantean en el
ciclo de vida a utilizar.
1.7.TECNICAS
1.7.1. TECNICAS CONCEPTUALES
Son procedimientos particularmente mentales y comprenden las reglas
lógicas que acompañan todo ciclo de investigación, se emplean en la
caracterización e identificación del objeto de estudio y de sus conexiones
externas en el planteamiento y fundamentación de problema; lo cual hace
posible la abstracción, la generalización, el análisis, la síntesis, la
sistematización y las operaciones de las reglas lógicas.
Se usaran en la comprensión de definiciones básicas que ayudaran para
elaborar el marco teórico en el documento final.
1.7.2. TECNICAS DESCRIPTIVAS
Estas son empleadas para recoger, registrar y elaborar cuadros de
descripción que nos servirán para construir elementos metodológicos
aplicables a propósitos del estudio que se está realizando.
Las técnicas descriptivas se usaran en el recojo, registro y elaboración de
cuadros para la ingeniería del proyecto.
11
1.8.ALCANCE Y APORTES
1.8.1. Alcances
El sistema propuesto tiene como alcance aprovechar los beneficios que nos
ofrece la metodología UML para el desarrollo de software.
El estudio abarcara el área de compra y venta, principalmente:
artículos(altas, bajas, modificaciones, consultas)
compra(registro de compra, consulta de compra, reportes)
venta(registro de venta, consulta de ventas, reportes)
Cliente(altas, bajas, modificaciones, consultas)
1.8.2. Aporte técnico
Mediante la aplicación del software propuesto se minimizara tiempos en la
obtención de datos y se brindara una mejor atención a las entidades externas
que interactuaran con el sistema; así los aportes del sistema son:
Sistema de ventas e Inventarios para llantas:
Modulo automatizado de consulta artículos (altas, bajas,
modificaciones)
Modulo automatizado para el control de ventas
Modulo automatizado para el control de compras
Modulo automatizado para el control de cliente(altas, bajas y reportes)
Modulo automatizado para el control inventarios(generación de
kardex)
12
1.9.PLANIFICACION DE ACTIVIDADES
ACTIVIDADES
Mes: Mayo - JunioSEMANAS DE TRABAJOS: 5
DIAS HABILES1 2 3 4 5
FASE I: "Planificación del tema" 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5
Planteamiento del problema Elaboración árbol de problemas Formulación de problemas Propósitos del trabajo Medios e instrumentos de investigación
FASE II: "Marco Teórico" Instrumentos de investigación Investigación Datos teóricos
FASE III: "Desarrollo" Modelo de negocios Gestión de RequerimientosCasos de Uso del Sistema Diagrama de Clases Diagramas de Secuencia Diagrama de Objetos Diagrama de Comunicación Diagrama de Actividades Diagrama de Paquetes
FASE IV: "Conclusiones y resolución" Finalización y resultados Revisión y reflexiones(análisis)
13
2. CAPITULO II
MARCO TEORICO
2.1.PARADIGMA ORIENTADA A OBJETOS
14
Análisis Diseño Codificación Pruebas Implementación
2.2.METODOLOGIAS E INGENIERIA DE SOFTWARE
La Ingeniería de software se define como:
El estudio de los principios y metodologías para el desarrollo y
mantenimiento de sistemas de software.
La aplicación práctica del conocimiento científico en el diseño y construcción
de programas de computadora y la documentación asociada requerida para
desarrollar, operar (funcionar) y mantenerlos. Se conoce también como
desarrollo de software o producción de software.
La aplicación de un enfoque sistemático, disciplinado y cuantificable al
desarrollo, operación (funcionamiento) y mantenimiento del software; es
decir, la aplicación de ingeniería al software.
2.2.1. MODELO DE CICLO DE VIDA SECUENCIAL
Llamado algunas veces ciclo de vida básico o modelo en cascada», el
modelo lineal secuencial sugiere un enfoque5 sistemático, secuencial, para
el desarrollo del software que comienza en un nivel de sistemas y progresa
con el análisis, diseño, codificación, pruebas y mantenimiento. La Figura 2.1
muestra el modelo lineal secuencial para la ingeniería del software.
2.2.2. MODELO DE CICLO DE VIDA RUP
15
Una de las metodologías pesadas más conocidas y utilizadas es laM
etodología RUP (Rational Unified Process) que divide el desarrollo en 4 f
ases que definen su ciclo de vida:
FASE DE INICIO:
El objetivo general de esta fase es establecer un acuerdo entre
todos los interesados acerca de los objetivos del proyecto.
Es significativamente importante para el desarrollo de nuevo
software, ya que se asegura de identificar los riesgos
relacionados con el negocio y requerimientos.
Para proyectos de mejora de software existente, esta fase es
más breve y se centra en asegurar la viabilidad de desarrollar
el proyecto.
FASE DE ELABORACION:
El objetivo en esta fase es establecer la arquitectura base del
sistema para proveer bases estables para el esfuerzo de
diseño e implementación en la siguiente fase.
La arquitectura debe abarcar todas las consideraciones de
mayor importancia de los requerimientos y una evaluación del
riesgo.
16
FASE DE CONSTRUCCIÓN:
El objetivo de la fase de construcción es clarificar los
requerimientos faltantes y completar el desarrollo del sistema
basados en la arquitectura base.
Vista de cierta forma esta fase es un proceso de manufactura,
en el cual el énfasis se torna hacia la administración de
recursos y control de la operaciones para optimizar costos,
tiempo y calidad.
FASE DE TRANSICIÓN:
Esta fase se enfoca en asegurar que el software esté
disponible para sus usuarios.
Se puede subdividir en varias iteraciones, además incluye
pruebas del producto para poder hacer el entregable del
mismo, así como realizar ajuste menores de acuerdo a ajuste
menores propuestos por el usuario.
En este punto, la retroalimentación de los usuarios se centra
en depurar el producto, configuraciones, instalación y aspectos
sobre utilización.
2.3.LENGUAJE UNIFICADO DE MODELADO
2.3.1. INTRODUCCION
UML es un lenguaje estándar que sirve para escribir los planos del software,
puede utilizarse para visualizar, especificar, construir y documentar todos los
artefactos que componen un sistema con gran cantidad de software. UML
puede usarse para modelar desde sistemas de información hasta
aplicaciones distribuidas basadas en Web, pasando por sistemas
17
empotrados de tiempo real. UML es solamente un lenguaje por lo que es sólo
una parte de un método de desarrollo software, es independiente del proceso
aunque para que sea optimo debe usarse en un proceso dirigido por casos
de uso, centrado en la arquitectura, iterativo e incremental.
UML es un lenguaje por que proporciona un vocabulario y las reglas para
utilizarlo, además es un lenguaje de modelado lo que significa que el
vocabulario y las reglas se utilizan para la representación conceptual y física
del sistema.
UML es un lenguaje que nos ayuda a interpretar grandes sistemas mediante
gráficos o mediante texto obteniendo modelos explícitos que ayudan a la
comunicación durante el desarrollo ya que al ser estándar, los modelos
podrán ser interpretados por personas que no participaron en su diseño (e
incluso por herramientas) sin ninguna ambigüedad. En este contexto, UML
sirve para especificar, modelos concretos, no ambiguos y completos.
Debido a su estandarización y su definición completa no ambigua, y aunque
no sea un lenguaje de programación, UML se puede conectar de manera
directa a lenguajes de programación como Java, C++ o Visual Basic, esta
correspondencia permite lo que se denomina como ingeniería directa
(obtener el código fuente partiendo de los modelos) pero además es posible
reconstruir un modelo en UML partiendo de la implementación, o sea, la
ingeniería inversa.
UML proporciona la capacidad de modelar actividades de planificación de
proyectos y de sus versiones, expresar requisitos y las pruebas sobre el
sistema, representar todos sus detalles así como la propia arquitectura.
Mediante estas capacidades se obtiene una documentación que es válida
durante todo el ciclo de vida de un proyecto.
18
2.3.2. DIAGRAMAS DE UML
Los diagramas se utilizan para representar diferentes perspectivas de un
sistema de forma que un diagrama es una proyección del mismo. UML
proporciona un amplio conjunto de diagramas que normalmente se usan en
pequeños subconjuntos para poder representar las cinco vistas principales
de la arquitectura de un sistema.
Diagramas de Clases, Muestran un conjunto de clases, interfaces y
colaboraciones, así como sus relaciones. Estos diagramas son los más
comunes en el modelado de sistemas orientados a objetos y cubren la vista
de diseño estática o la vista de procesos estática (sí incluyen clases activas).
Diagramas de Objetos, Muestran un conjunto de objetos y sus relaciones,
son como fotos instantáneas de los diagramas de clases y cubren la vista de
diseño estática o la vista de procesos estática desde la perspectiva de casos
reales o prototípicos.
Diagramas de Casos de Usos, Muestran un conjunto de casos de uso y
actores (tipo especial de clases) y sus relaciones. Cubren la vista estática de
los casos de uso y son especialmente importantes para el modelado y
organización del comportamiento.
Diagramas de Secuencia y de Colaboración, Tanto los diagramas de
secuencia como los diagramas de colaboración son un tipo de diagramas de
interacción. Constan de un conjunto de objetos y sus relaciones, incluyendo
los mensajes que se pueden enviar unos objetos a otros. Cubren la vista
dinámica del sistema. Los diagramas de secuencia enfatizan el ordenamiento
temporal de los mensajes mientras que los diagramas de colaboración
muestran la organización estructural de los objetos que envían y reciben
19
mensajes. Los diagramas de secuencia se pueden convertir en diagramas de
colaboración sin pérdida de información, lo mismo ocurren en sentido
opuesto.
Diagramas de Estados, Muestran una máquina de estados compuesta por
estados, transiciones, eventos y actividades. Estos diagramas cubren la vista
dinámica de un sistema y son muy importantes a la hora de modelar el
comportamiento de una interfaz, clase o colaboración.
Diagramas de Actividades, Son un tipo especial de diagramas de estados
que se centra en mostrar el flujo de actividades dentro de un sistema. Los
diagramas de actividades cubren la parte dinámica de un sistema y se
utilizan para modelar el funcionamiento de un sistema resaltando el flujo de
control entre objetos.
Diagramas de Componentes, Muestra la organización y las dependencias
entre un conjunto de componentes. Cubren la vista de la implementación
estática y se relacionan con los diagramas de clases ya que en un
componente suele tener una o más clases, interfaces o colaboraciones
Diagramas de Despliegue, Representan la configuración de los nodos de
procesamiento en tiempo de ejecución y los componentes que residen en
ellos. Muestran la vista de despliegue estática de una arquitectura y se
relacionan con los componentes ya que, por lo común, los nodos contienen
uno o más componentes.
2.3.2.1. DIAGRAMAS DE CLASE
20
Un diagrama de clases es un diagrama que muestra un conjunto de clases,
interfaces, colaboraciones y sus relaciones. Al igual que otros diagramas los
diagramas de clases pueden contener notas y restricciones. También pueden
contener paquetes o subsistemas, los cuales su usan para agrupar los
elementos de un modelo en partes más grandes. A veces se colocarán
instancias en los diagramas de clases, especialmente cuando se quiera
mostrar el tipo (posiblemente dinámico) de una instancia.
Los diagramas de componentes y de despliegue son muy parecidos a los de
clases, simplemente que muestran componentes y nodos respectivamente
en vez de clases.
Usos comunes
Los diagramas de clases se utilizan para modelar la vista de diseño estática
de un sistema. Esta vista soporta principalmente los requisitos funcionales de
un sistema, los servicios que el sistema debe proporcionar a los usuarios
finales.
2.3.2.2. DIAGRAMA DE OBJETO
21
En UML los diagramas de clases se utilizan para visualizar los aspectos
estáticos de los bloques de construcción del sistema. Los diagramas de
interacción se utilizan para ver los aspectos dinámicos del sistema y constan
de instancias de estos bloques y mensajes enviados entre ellos. Un
diagrama de objetos contiene un conjunto de instancias de los elementos
encontrados en un diagrama de clases. Por lo tanto, un diagrama de objetos
expresa la parte estática de una interacción, consistiendo en los objetos que
colaboran pero sin ninguno de los mensajes enviados entre ellos.
2.3.2.3. DIAGRAMA DE CASOS DE USO
Los diagramas de casos de uso se emplean para visualizar el
comportamiento de un sistema, un subsistema o una clase, de forma que los
usuarios puedan comprender cómo utilizar ese elemento y de forma que los
desarrolladores puedan implementarlo.
Los diagramas de casos de uso muestran un conjunto de casos de uso,
actores y sus relaciones, estas pueden ser relaciones de dependencia,
generalización y asociación. También pueden contener paquetes, que se
emplean para agrupar elementos del modelo en partes mayores.
Elementos:
Los elementos que pueden aparecer en un diagrama de casos de uso son:
actores, casos de uso y relaciones entre casos de uso:
Actores:
Un actor es algo con comportamiento, como una persona (identificada por
un rol), en un sistema informático u organización, y que realiza algún tipo
de interacción con el sistema. Se representa mediante una figura humana
22
dibujada con palotes. Esta representación sirve tanto para actores que
son personas como para otro tipo de actores.
Casos de uso
Un caso de uso es una descripción de la secuencia de interacciones que
se producen entre un actor y el sistema, cuando el actor us el sistema
para llevar a cabo una tarea específica. Expresa una unidad coherente de
funcionalidad y se representa en el diagrama de casos de uso mediante
una elipse con el nombre del caso de uso en su interior. El nombre del
caso de uso debe reflejar la tarea específica que el actor desea llevar a
cabo usando el sistema.
Relaciones entre casos de uso
Un caso de uso, en principio debería describir una tarea que tiene un
sentido completo para el usuario. Sin embargo, hay ocasiones en las que
es útil describir una interacción con un alcance menor como caso de uso.
La razón para utilizar estos casos de uso no completos en algunos casos,
es mejorar la comunicación en el equipo de desarrollo, el manejo de la
documentación de casos de uso. Para el caso que se quiera utilizar estos
casos de uso más pequeños.
En la figura se muestra como el caso de uso realizar reintegro puede
incluir una relación de colaboración del caso de uso autorización.
2.4.LENGUAJE DE PROGRAMACION
23
Un lenguaje de programación es un idioma artificial diseñado para expresar
procesos que pueden ser llevados a cabo por máquinas como las
computadoras.
Pueden usarse para crear programas que controlen el comportamiento físico
y lógico de una máquina, para expresar algoritmos con precisión, o como
modo de comunicación humana.
Está formado por un conjunto de símbolos y reglas sintácticas y semánticas
que definen su estructura y el significado de sus elementos y expresiones. Al
proceso por el cual se escribe, se prueba, se depura, se compila y se
mantiene el código fuente de un programa informático se le llama
programación.
También la palabra programación se define como el proceso de creación de
un programa de computadora, mediante la aplicación de procedimientos
lógicos, a través de los siguientes pasos:
El desarrollo lógico del programa para resolver un problema en
particular.
Escritura de la lógica del programa empleando un lenguaje de
programación específico (codificación del programa).
Ensamblaje o compilación del programa hasta convertirlo en lenguaje
de máquina.
Prueba y depuración del programa.
Desarrollo de la documentación.
Existe un error común que trata por sinónimos los términos 'lenguaje de
programación' y 'lenguaje informático'. Los lenguajes informáticos engloban a
los lenguajes de programación y a otros más, como por ejemplo HTML
(lenguaje para el marcado de páginas web que no es propiamente un
lenguaje de programación, sino un conjunto de instrucciones que permiten
diseñar el contenido de los documentos).
24
Permite especificar de manera precisa sobre qué datos debe operar una
computadora, cómo deben ser almacenados o transmitidos y qué acciones
debe tomar bajo una variada gama de circunstancias. Todo esto, a través de
un lenguaje que intenta estar relativamente próximo al lenguaje humano o
natural. Una característica relevante de los lenguajes de programación es
precisamente que más de un programador pueda usar un conjunto común de
instrucciones que sean comprendidas entre ellos para realizar la
construcción de un programa de forma colaborativa.
2.4.1. VISUAL STUDIO 2012
Microsoft Visual Studio es un entorno de desarrollo integrado (IDE, por sus
siglas en inglés) para sistemas operativos Windows. Soporta varios
lenguajes de programación 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 versión .NET 2002). Así se pueden crear
aplicaciones que se intercomuniquen entre estaciones de trabajo, páginas
web y dispositivos móviles.
Características:
La actualización más importante que recibieron los lenguajes de
programación fue la inclusión de tipos genéricos, similares en muchos
aspectos a las plantillas de C++. Con esto se consigue encontrar muchos
más errores en la compilación en vez de en tiempo de ejecución, incitando a
usar comprobaciones estrictas en áreas donde antes no era posible. C++
25
tiene una actualización similar con la adición de C++/CLI como sustituto de
C# manejado. Se incluye un diseñador de implantación, que permite que el
diseño de la aplicación sea validado antes de su implantación. También se
incluye un entorno para publicación web y pruebas de carga para comprobar
el rendimiento de los programas bajo varias condiciones de carga.
Visual Studio 2005 también añade soporte para arquitecturas de 64 bits.
Aunque el entorno de desarrollo sigue siendo una aplicación de 32 bits,
Visual C++ 2005 soporta compilación para x86-64 (AMD64, Intel 64) e IA-64
(Itanium). El SDK incluye compiladores de 64 bits así como versiones de 64
bits de las librerías. Se lanzó el Service Pack 1 para Visual Studio 2005 el 14
de diciembre de 2006.
La versión interna de Visual Studio 2005 es la 8.0, mientras que el formato
del archivo que emplea es la 9.0.
2.5.SISTEMA GESTOR DE BASE DE DATOS
2.5.1. SQL SERVER 2005
Microsoft SQL Server es un sistema para la gestión 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. Las características de SQL
Server Compact Edition incluyen lo siguiente:
Un motor de base de datos compacto y un sólido optimizador de
consultas.
Compatibilidad con la réplica de mezcla y el acceso a datos remotos
(RDA).
26
Integración con Microsoft SQL Server 2005.
Las herramientas de administración son Microsoft SQL Server
Management Studio y SQL Server Management Studio Express.
Integración con Microsoft Visual Studio 2005.
Acceso a datos remotos y réplica de mezcla para sincronizar datos.
Microsoft Proveedor de datos .NET Framework y .NET Compact
Framework para SQL Server Compact Edition
(System.Data.SqlServerCe).
Compatibilidad con Microsoft ADO.NET y el proveedor de OLE DB para
SQL Server Compact Edition.
Un subconjunto de sintaxis SQL.
Se implementa como una base de datos incrustada en equipos de
escritorio, dispositivos móviles y Tablet PC.
Compatibilidad con la tecnología de implementación ClickOnce.
2.6.DIAGRAMA DE GANTT
El diagrama de Gantt es una popular herramienta gráfica cuyo objetivo es
mostrar el tiempo de dedicación previsto para diferentes tareas o actividades
a lo largo de un tiempo total determinado. A pesar de esto, el diagrama de
Gantt no indica las relaciones existentes entre actividades
La posición de cada tarea a lo largo del tiempo hace que se puedan
identificar dichas relaciones e interdependencias. Fue Henry Laurence Gantt
quien, entre 1910 y 1915, desarrolló y popularizó este tipo de diagrama en
Occidente.
Por esta razón, para la planificación del desarrollo de proyectos complejos
(superiores a 25 actividades) se requiere además el uso de técnicas basadas
en redes de precedencia como CPM o los grafos PERT. Estas redes
27
relacionan las actividades de manera que se puede visualizar el camino
crítico del proyecto y permiten reflejar una escala de tiempos para facilitar la
asignación de recursos y la determinación del presupuesto. El diagrama de
Gantt, sin embargo, resulta útil para la relación entre tiempo y carga de
trabajo.
En gestión de proyectos, el diagrama de Gantt muestra el origen y el final de
las diferentes unidades mínimas de trabajo y los grupos de tareas (llamados
summaryelements en la imagen) o las dependencias entre unidades mínimas
de trabajo (no mostradas en la imagen).
Desde su introducción los diagramas de Gantt se han convertido en una
herramienta básica en la gestión de proyectos de todo tipo, con la finalidad
de representar las diferentes fases, tareas y actividades programadas como
parte de un proyecto o para mostrar una línea de tiempo en las diferentes
actividades haciendo el método más eficiente.
28
Básicamente el diagrama está compuesto por un eje vertical donde se
establecen las actividades que constituyen el trabajo que se va a ejecutar, y
un eje horizontal que muestra en un calendario la duración de cada una de
ellas.
29
3. CAPITULO III
DESARROLLO
30
3.1. INTRODUCCION
El presente proyecto se basara en la metodología RUP, en la cual se
siguen las siguientes fases:
Fase de inicio
Fase de elaboración
Fase construcción
Fase de transición
3.2.FASE DE INICIO
3.2.1. MODELO DE NEGOCIO
3.2.1.1. DIAGRAMA DE CASO DE USO DE NEGOCIO
31
3.2.2. GESTION DE REQUERIMIENTOS
Para la obtención de los requisitos se utilizo los métodos de:
Entrevista con el administrador
Método de observación
3.2.3. LISTA DE REQUERIMIENTOS
No se cuenta con un sistema de registros de la materia prima.
La empresa en cuestión cuenta con una desorganización a gran
escala en el control de su materia prima (llantas). No cuenta con un
registro de sus clientes, si como aquellos que más frecuentemente
compran en la empresa.
Se desea tener un registro sofisticado que guarde los datos de todos
los clientes y registre sus datos para tener un acercamiento más
entrañable y que él se siente más cómodo e identificado con la
empresa.
Se desea tener un registro de todas las ventas que realiza la
empresa, registra las ventas más grandes así como los datos del
cliente, para mandarle ofertas o simplemente estar ofreciendo
innovaciones o invitándolo a comprar nuevamente la empresa.
Se desea tener un sistema de seguridad en la empresa que impida
que cualquier trabajador o simplemente cualquier persona accedan a
información confidencial que será útil para el Administrador.
32
Se desea que el sistema controle el inventario y obtenga la cantidad
de stock de los diferentes productos, pero esta información deberá ser
confidencial, así que solamente se podrá acceder a esta parte del
sistema mediante una contraseña.
Se desea tener información dentro del sistema (etiquetas, opciones de
ayuda, etc.) para evitar el menor número posible de problemas y de
tiempo, y por ende en ganancias, al tratar de familiarizarse con el
programa.
Se desea que el sistema guarde los atributos principales del producto
(Llantas), como cantidad y marca.
Se desea que el sistema sea amigable y de fácil y rápido aprendizaje,
ya tanto nuestros trabajadores como nosotros mismos (clientes del
sistema), contamos con los mínimos conocimientos informáticos. Así
como una interfaz que genere el menor número posible de problemas,
Y también el sistema deberá elaborar las principales funciones de
altas, bajas, cambios y consultas.
33
3.3.FASE DE ELABORACION
3.3.1. CASOS DE USO DE SISTEMA
El modelo de casos de uso permite que los desarrolladores del software y los clientes lleguen a un acuerdo sobre los requisitos, es decir, sobre las condiciones y posibilidades que debe cumplir el sistema. El modelo de casos de uso sirve como acuerdo entre clientes y desarrolladores, y proporciona la entrada fundamental para el análisis, el diseño y las pruebasUn modelo de casos de uso es un modelo del sistema que contiene actores, casos de uso y sus relaciones
3.3.1.1. DIAGRAMAS DE CASOS DE USO – Venta de Llanta
34
3.3.1.2. DIAGRAMAS DE CASOS DE USO – Actualiza
Existencias
35
3.3.1.3. DIAGRAMAS DE CASOS DE USO – Compra de Llanta
36
3.3.1.4. DIAGRAMAS DE CASOS DE USO DE TIPO TEXTO
CASO DE USO: Realizar venta de llantas
ACTORES: encargado de ventas, cliente
PROPOSITO: Registrar una venta
RESUMEN: el encargado de ventas realiza una venta, entrega factura y
registra la venta realizada
TIPO: Primario y esencial
Curso normal de eventos
Acción del actor Respuesta del sistema
1.- El encargado de venta registra al
cliente
3.-Acepta el registro del cliente
4.- Realiza la venta de llantas
Si existe más productos a vender,
el vendedor digita la cantidad
6.- El encargado de ventas confirma
y registra la venta
8.- entrega la factura al cliente y
devuelve cambio en caso de
existencia
9.- Finaliza venta
2. muestra los datos del cliente
5.- Muestra datos de venta
7.- Genera factura
Cursos alternos:
Línea 1. El cliente ya está registrado: salta a la línea 4
Línea 6. El encargado de ventas no confirma la venta: cancelar operación
CASO DE USO: Realizar compra de inventarios (stock)
ACTORES: encargado de almacén, administrador, proveedor
PROPOSITO: Registrar la compra a proveedor (stock)
RESUMEN: el encargado de almacén realiza una solicitud al
administrador para la compra de inventarios y registrar la compra
37
TIPO: Primario y esencial
Curso normal de eventos
Acción del actor Respuesta del sistema
1.- El encargado de almacén revisa
los inventarios(cantidad de llantas
existentes)
3.-El encargado de almacén solicita
la compra de inventarios al
administrador
4.- El administrador acepta la
solicitud
5.- El encargado de almacén compra
el producto del proveedor
6.- El encargado de almacén registra
los datos de la compra
9.-Finaliza
2. muestra los datos del almacén
7.- Actualiza el inventarios del
almacén
8.-Muestra datos del almacén
Cursos alternos:
Línea 1. El almacén está lleno: cancelar operación
Línea 4. El administrador no acepta la solicitud: cancelar operación
Línea 5. El proveedor no cuenta con los productos: cancela operacion
38
3.3.2. DIAGRAMA DE CLASE
39
3.3.3. DIAGRAMA DE SECUENCIA
DIAGRAMA DE COMUNICACIÓN PARA VENTA DE LLANTAS
DIAGRAMA DE COMUNICACIÓN PARA COMPRA DE INVENTARIOS
40
DIAGRAMA DE COMUNICACIÓN PARA ACTUALIACION DE INVENTARIO(STOCK)
41
42
4. CAPITULO IV
CONCLUSIONES Y
RECOMENDACIONES
43
Conclusiones.- En un mundo globalizado donde las empresas se esfuerzan por tener una mayor participación en el mercado, lo que origina el desarrollo de estrategias de distribución y técnicas de venta que refuercen los objetivos económicos de los negocios. Por esta razón, las medianas empresas en Bolivia buscan aplicar métodos que fortalezcan su relación con el cliente por medio de sistemas de ventas eficacesPara el caso de estudio de esta investigación, la Empresa San Carlos, se tiene la necesidad de profesionalizar el sistema de venta directa; reforzando el equipo de ventas. Sistema que se espera cumpla con las expectativas de los consumidores y por ende aumente las ventas para la Empresa
Después de estudiar la información recolectada y desarrollar la estrategia, se plantean las siguientes recomendaciones:
La venta directa debe ser personalizada. El vendedor debe brindar una atención constante al cliente, porque al cliente le agrada que estén al pendiente de sus necesidades y además le informen de nuevos producto.
Es muy importante que el vendedor procure que el cliente no se sienta incómodo con la visita de ventas y con el producto. Por lo que debe hacerlo sentir en confianza, creando una atmósfera donde él pueda expresar lo que piensa y siente. Esto ayudará a lograr una relación estrecha cliente-vendedor originando fructíferas y continuas ventas.
La capacitación del vendedor es lo más importante en la estrategia de venta, ya que de él depende totalmente se realice la compra. Él debe tratar de que su cliente quede satisfecho con el trato recibido, para que así el cliente recomiende positivamente tanto a los productos como a la empresa.
Teniendo así la empresa un sistema para la organización y venta de llantas para la demanda del público al nivel de otras empresas reconocidas en Bolivia.
44
5. CAPITULO V
BIBLIOGRAFIA
45
Apuntes de clase
Monografías.com
http://fabianbermeop.blogspot.com/2010/12/metodologia-rup-desarrollo-
de-software.html
http://www.wikipedoa.org/
46
![Proyecto Final Sige Ver 2.0[1]](https://img.dokumen.tips/doc/110x75/563db9d3550346aa9aa04c26/proyecto-final-sige-ver-201.jpg)
