.

APORTES

Al realizar las cotizaciones, se vio que presentan muchas dificultades como: Perdida de

datos, demora a la hora de realizar las cotizaciones de las ventas, mal cálculo financiero de los

accesorios y con el desarrollo del presente sistema permite solucionar y/o cubrir las necesidades

planteadas en esta empresa:

 El sistema realizará el registro de compra y venta de manera sistematizada.

 La implementación del sistema reduce el tiempo para efectuar el proceso de

ventas.

 El sistema será confiable y seguro.

 El sistema solucionara los problemas cotidianos dentro de la empresa.

8. ENFOQUE METODOLÓGICO

El proyecto de grado tiene un enfoque cuantitativo, porque se puede cuantificar todas las

ventas en un determinado periodo de tiempo, también se puede conocer de las ventas realizadas

cuantos productos se tienen en el almacén.

8.1. Enfoque Metodológico (cualitativo, cuantitativo y mixto)

Los métodos de investigación mixta son la integración sistemática de los métodos

cuantitativo y cualitativo en un solo estudio con el fin de obtener una “fotografía” más completa

del fenómeno. Éstos pueden ser conjuntados de tal manera que las aproximaciones cuantitativa y

cualitativa conserven sus estructuras y procedimientos originales (“forma pura de los métodos

mixtos”). Alternativamente, estos métodos pueden ser adaptados, alterados o sintetizados para
efectuar la investigación y lidiar con los costos del estudio (“forma modificada de los métodos

mixtos”) (Chen, 2006; Johnson et al., 2006)

8.2. Tipo de investigación

El tipo de investigación del presente proyecto será mixto ya que la investigación aborda

tanto lo cualitativo como lo cuantitativo por medio de información primaria y secundaria. A

través del enfoque cualitativo se sabrá el comportamiento y sus exigencias del servicio a recibir,

lo cual se considera muy importante para determinar sus características de cada uno de los

accesorios, dando así mayor facilidad en la obtención de datos.

8.3 Métodos, técnicas e instrumentos

Para el desarrollo del software se utilizará el modelo RUP (Proceso Unificado Racional).

Como técnicas de recolección de información se utilizará: observación directa y

entrevistas.

Se utilizará para el análisis y diseño del sistema de software UML para los diagramas.

El modelo COCOMO II en su modelo Diseño anticipado para la estimación de costos de

software.

Las pruebas de software se realizarán mediante las pruebas unitarias, pruebas de Caja

Negra y de Caja Blanca.

En la implementación del software se utilizará el lenguaje de programación Visual Basic,

el Sistema gestor de bases de datos MySQL.

8.3.1. Proceso Unificado Racional (RUP)

la metodología de desarrollo de software RUP (Rational Unified Process), la cual es una

metodología iterativa e incremental que se caracteriza por su enfoque en casos de uso y la

arquitectura de la solución a desarrollar (Kruchten, 2004). Estas características permiten tener

siempre en cuenta los requerimientos, la creación de modelos y vistas para comprender cada

parte del software y fomentar la reutilización de componentes (Martínez & Martínez, 2014).

8.3.2. COCOMO II

Este modelo permite realizar estimaciones en función del tamaño del software, y de un

conjunto de factores de costo y de escala. Los factores de costo describen aspectos relacionados

con la naturaleza del producto, hardware utilizado, personal involucrado, y características

propias del proyecto. El conjunto de factores de escala explica las economías y des economías de

escala producidas a medida que un proyecto de software incrementa su tamaño. COCOMO II

posee tres modelos denominados Composición de Aplicación, Diseño Temprano y Post-

Arquitectura. Cada uno de ellos orientados a sectores específicos del mercado de desarrollo de

software y a las distintas etapas del desarrollo de software. (Adriana Gómez, María del C.López,

Silvina Migani, Alejandra Otazú).

8.3.2.1. COCOMO II DISEÑO TEMPRANO

Este modelo se usa en las etapas tempranas de un proyecto de software, cuando se conoce

muy poco del tamaño del producto a ser desarrollado, de la naturaleza de la plataforma, de la

persona a ser incorporado al proyecto o detalles específicos del proceso a utilizar. Este modelo
podría emplearse tanto en productos desarrollados en sectores de Generadores de Aplicación,

Sistema Integrados o Infraestructura.

8.3.3. Lenguaje Unificado de Modelado (U.M.L.)

8.3.3.1. Tipos De Diagramas En UML

El lenguaje unificado de modelado o UML (Unified Modelillg úlIIguage) es el sucesor de

la oleada de métodos de análisis y diseño orientados a objetos (OOA&D) que surgió a finales de

la d écada de 1980 y principios de la siguiente. El UML unifica, sobre todo, los métodos de

800ch, Rumbaugh (OMT) y Jacobson, pero su alcance llegará a ser mucho más amplio. En estos

momentos el UML está en pleno proceso de estandarización con el OMG (Object Mallagemell'

Group o Grupo de administración de objetos) y estoy seguro de que se convertirá en el lenguaje

de modelado estándar del futuro. Decimos, pues, que el UML es un lenguaje de modelado, y no

un método. La mayor parte de los métodos consisten, al menos en principio, en un lenguaje y en

un proceso para modelar. El lenguaje de modelado es la notación (principalmente gráfica) de que

se valen los métodos para expresar los diseños. El proceso es la orientación que nos dan sobre los

pasos a seguir para hacer el diseño. (Martin Fowler).

Diagramas estructurales

Los diagramas estructurales muestran la estructura estática del sistema y sus partes en

diferentes niveles de abstracción. Existen un total de siete tipos de diagramas de estructura:

Diagrama de clases
 Muestra la estructura del sistema, subsistema o componente utilizando clases con sus

características, restricciones y relaciones: asociaciones, generalizaciones, dependencias, etc.

Diagrama de componentes

Muestra componentes y dependencias entre ellos. Este tipo de diagramas se utiliza para el

desarrollo basado en componentes (CDB), para describir sistemas con arquitectura orientada a

servicios (SOA).

Diagrama de despliegue

Muestra la arquitectura del sistema como despliegue (distribución) de artefactos de

software.

Diagrama de objetos

Un gráfico de instancias, incluyendo objetos y valores de datos. Un diagrama de objeto

estático es una instancia de un diagrama de clase; muestra una instantánea del estado detallado

de un sistema en un punto en el tiempo.

Diagrama de paquetes. Muestra los paquetes y las relaciones entre los paquetes.

Diagrama de perfiles. Diagrama UML auxiliar que permite definir estereotipos

personalizados, valores etiquetados y restricciones como un mecanismo de extensión ligero al

estándar UML. Los perfiles permiten adaptar el metamodelo UML para diferentes plataformas o

dominios.

Diagrama de estructura compuesta. Muestra la estructura interna (incluidas las partes y

los conectores) de un clasificador estructurado.[ CITATION UML \l 16394 ].

8.3.4. Pruebas de Software

Caja Blanca

Tipo de pruebas de software que se realiza sobre las funciones internas de un módulo. Así

como las pruebas de caja ejercitan los requisitos funcionales desde el exterior del módulo, las de

caja blanca están dirigidas a las funciones internas. Entre las técnicas usadas se encuentran; la

cobertura de caminos (pruebas que hagan que se recorran todos los posibles caminos de

ejecución), pruebas sobre las expresiones lógico-aritméticas, pruebas de camino de datos

(definición-uso de variables), comprobación de bucles(se verifican los bucles para 0,1 e

interacciones, y luego para las interacciones máximas, máximas menos uno y más uno).Las

pruebas de caja blanca se llevan a cabo en primer lugar, sobre un módulo concreto, para luego

realizar las de caja negra sobre varios subsistemas (integración).En los sistemas orientados a

objetos, las pruebas de caja blanca pueden aplicarse a los métodos de la clase, pero según varias

opiniones, ese esfuerzo debería dedicarse a otro tipo de pruebas más especializadas (un

argumento podría ser que los métodos de una clase suelen ser menos complejos que los de una

función de programación estructurada). Dentro de las Pruebas de Caja Blanca encontramos las

llamadas coberturas (sentencia, decisión, condición y múltiple además de los mencionados

caminos ciclo máticos propuestos porMcCabe).

Caja Negra

 Es aquel elemento que es estudiado desde el punto de vista de las entradas que recibe y las
salidas o respuestas que produce, sin tener en cuenta su funcionamiento interno. En otras
palabras, de una nos interesara nos interesará su forma de interactuar con el medio que le rodea
(en ocasiones, otros elementos que también podrían ser cajas negras) entendiendo qué es lo que
hace, pero sin dar importancia a cómo lo hace. Por tanto, de una caja negra deben