DISEÑO Y CONSTRUCCIÓN DE UN PUNTO DE VENTA GRATUITO, …

PONTIFICIA UNIVERSIDAD CATÓLICA DEL ECUADOR

FACULTAD DE INGENIERÍA

ESCUELA DE SISTEMAS

DISERTACIÓN PREVIA A LA OBTENCIÓN DEL TÍTULO DE

INGENIERÍA EN SISTEMAS Y COMPUTACIÓN

DISEÑO Y CONSTRUCCIÓN DE UN PUNTO DE VENTA (PoS)

GRATUITO, EN LÍNEA, PARA MICROEMPRESAS

NOMBRES

DIEGO F. PEÑAFIEL C.

CARLOS D. SÁNCHEZ M.

DIRECTOR: ING. JAVIER CÓNDOR

QUITO, 2012 - Agosto

DISEÑO Y CONSTRUCCIÓN DE UN PUNTO DE VENTA GRATUITO, EN LÍNEA,

PARA MICROEMPRESAS

Peñafiel Diego – Carlos Sánchez 1

1. CAPÍTULO I: MARCO TEÓRICO

En este capítulo se dará una introducción a los temas generales de mayor importancia y

relevancia para el Diseño y Construcción de un Punto de Venta gratuito en línea.

Se describe la Computación en la Nube, donde se verá el concepto general, sus ventajas y

desventajas, y la estructura de como se encuentra distribuida. También se verá los Tipos de

Licencia de Software, su clasificación y algunos ejemplos importantes. Del tema de

Herramientas de Desarrollo, se verán los diferentes tipos, y una breve introducción a las

herramientas CASE1 y su clasificación.

1.1. Computación en Nube

La era de la computación local está llegando a su fin, ya que la tendencia actual está

llevando a la computación en la nube es decir en el internet.

La computación en la nube es un concepto que se originó en los años 60 y su

funcionamiento es el manejo de servicios tanto en negocio y tecnología, el usuario deja de

ejecutar programas localmente en su computador, y todo se realiza desde el internet

desplegándose la información solicitada en el computador.

Los usuarios pueden gozar de actualizaciones inmediatas, gracias al concepto de

computación en nube, al tener toda la información en el internet el usuario tiene la ventaja

de utilizar diferentes servicios de una manera rápida y sencilla; los ofertantes de los

servicios pueden poner a disposición de los usuarios nuevos servicios sin realizar visitas

técnicas y perder tiempo.

1CASE: Computer-aided software engineering.


PARA MICROEMPRESAS


Figura 1-1: Esquema de Conexión entre el Internet y los dispositivos electrónicos. [A], Mayo - 2012.

Todo el concepto de computación en nube cogió auge gracias a los proveedores de internet

de gran escala, como Google, Microsoft, entre otros. Todos ellos crearon un sistema de

recursos que fueron introducidos como servicios de tecnología de la información virtuales,

todos a gran escala y configurados como recursos.

En 2006 Amazon cumplió un papel muy importante en el desarrollo de la computación en

nube actual, ya que ellos al mejorar sus centros de datos encontraron que el nuevo sistema

de recursos permitía una eficiencia mucho mejor en sus servidores internos, con esto ellos

podían agregar componentes de una manera mucho más rápida y fácil. Una vez que

Amazon se dio cuenta de los beneficios del nuevo sistema de recursos, se inicia el

desarrollo para proveer el mismo sistema a sus clientes y es a partir de este evento que se

lanza el AWS2.

2 AWS: Amazon Web Service.

Nube de Internet

Computador

portátil

Computador

escritorio Dispositivo

Móvil

Computador Tableta


PARA MICROEMPRESAS


1.1.1. Ventajas

• Integración probada de servicios Red. La computación en nube permite

una adaptación rápida y eficaz entre los componentes del cliente y la

infraestructura de las aplicaciones en la nube.

• Debido que la información no se guarda en un lugar conocido para el

usuario, esta puede ser accedida por él desde cualquier parte del mundo,

con todas sus características sin ningún cambio.

• La computación en nube es tan simple que el cliente no necesita ser parte

de la planeación del hardware necesario para el correcto funcionamiento

de las aplicaciones, la infraestructura está a cargo de la persona o

empresa que brinda el servicio en la nube.

• El cliente no tiene que invertir grandes cantidades de dinero para un

nuevo proceso, ya que la computación en nube le permite contratar un

servicio a través del internet el cual cede las responsabilidades de dicho

proceso al proveedor de este.

• Con una infraestructura de computación en nube el cliente puede

implementar diferentes servicios o procesos; el usuario no perderá

tiempo en espera de la preparación de dicho servicio o proceso. Las

aplicaciones de la computación en nube están listas en cuestión de pocos

días permitiendo al cliente acceder al servicio lo antes posible.

• La personalización de las aplicaciones y procesos para cada usuario es

algo posible en la computación en nube, ya que cada servicio o proceso

puede ser personalizado por el usuario siempre y cuando la plataforma lo

permita.

• Las actualizaciones son más rápidas y eficaces pero más importante son

transparentes para el usuario ya que éste no tiene que estar instalando

manualmente las actualizaciones ni preocupándose de tener hardware

compatible con las actualizaciones.


PARA MICROEMPRESAS


1.1.2. Desventajas

• Cuando todos los procesos o servicios y los datos están almacenados

bajo un solo proveedor se crea una dependencia a dicho proveedor

entregándole una pequeña inseguridad sobre la seguridad de la

información.

• Toda la accesibilidad a los servicios y aplicaciones están conectados

directamente a la disponibilidad del acceso a internet.

• Existe información delicada de un usuario que, en una infraestructura en

nube, no se almacena localmente y todo se encuentra en la nube, esto

crea un concepto de vulnerabilidad y dependencia mayor hacia el

proveedor del servicio.

• La creación de servicios o procesos extremadamente detallados y

especializados están fuera del límite, y la creación de estos depende de la

disponibilidad y voluntad del proveedor.

• Todos los procesos o aplicaciones están en evolución continua, cambios

creados por el proveedor, esto crea un problema en la capacitación al

personal encargado del proceso o aplicación.

• Para que las peticiones de información sean procesadas, deben recorrer

varios enlaces hasta encontrar lo solicitado, esto crea nodos de seguridad

en los cuales se perder información.

• Para combatir el problema de la seguridad, se utilizan protocolos seguros

pero al utilizar estos se pierde mucha velocidad de respuesta ya que la

carga que estos protocolos seguros reciben son muy grandes.

• Si el proveedor no tiene un índice de crecimiento correcto y soluciones

para este, se puede crear problemas de sobre carga en los servidores y

llevar a un colapso total.


PARA MICROEMPRESAS


1.1.3. Capas de la computación en nube

Figura 1-2: Esquema de Conexión entre el Internet y los dispositivos electrónicos. [A], Mayo - 2012.

A continuación se explica cada una de las capas:

• Cliente

Estos son Computadores de escritorio, Computadores portátiles, Teléfonos inteligentes,

Computadores tabletas.

Generalmente las aplicaciones no requieren tener hardware específico, pero si necesitan un

navegador de internet ya que la mayoría de aplicaciones en la computación en nube se

presentan a través del navegador de internet.

Sin embargo algunas aplicaciones si requieren de software especializado para su correcto

funcionamiento en los clientes.

• Aplicación

Las aplicaciones de la nube son servicios como software de sus siglas en ingles SaaS3.

3SaaS: Software as a service.

Cliente

Aplicación

Plataforma

Infraestructura

Servidor


PARA MICROEMPRESAS


Estas aplicaciones son software que se presenta a través del internet como un servicio hacia

el cliente. Esto permite que el usuario no instale localmente los programas, así mismo evita

que el usuario se preocupe de actualizaciones y facilita el soporte y el mantenimiento.

• Plataforma

Servicios de plataforma en la nube por sus siglas en ingles PaaS4, entrega una plataforma

como un servicio. Generalmente consume la infraestructura de la computación en nube y

así mismo las aplicaciones.

Esta facilita la ejecución de aplicaciones sin el costo y la complejidad de comprar y

controlar el hardware y las capas del software.

Estas plataformas permiten a los desarrolladores crear aplicaciones que corran en la nube o

utilicen servicios provenientes de la nube.

• Infraestructura

La infraestructura como un servicio, por sus siglas en ingles IaaS5. Nos entrega una

infraestructura como un servicio que permite usar un ambiente de virtualización de una

plataforma como un servicio.

En vez de comprar servidores, software, datacenters o equipo de redes, los clientes

compran o alquilan el servicio a un proveedor que ya tiene todo lo necesario para operar.

• Servidor

Generalmente los servidores tienen lo necesario para entregar los servicios de la

computación en nube, sea esto memoria para datos, procesadores, memoria RAM6 y

sistema operativo especialmente diseñado para computación en nube.

1.2. Licencias de software

4PaaS: Platform as a service. 5IaaS: Infrastructure as a Service. 6 RAM: Random access memory.


PARA MICROEMPRESAS


Las licencias de software son contratos que se realizan entre el licenciante, el desarrollador

del software, y el licenciatario, el comprador del software, el cual incluye clausulas y

normas que rigen el uso de un determinado programa.

1.2.1. Tipos de Licencia de Software

Figura 1-3: Tipos de Licencia de Software. [A] Basado en [1], Mayo - 2012.

Como en la gráfica se describe, las licencias se clasifican en dos grandes grupos, aquellas

que son conocidas como Licencias Propietarias o Privativas y las del tipo libre, Licencias

Libres y de Fuente Abierta, o conocidas en inglés como Open Source.

1.3. Licencias Libres y Open Source

Las Licencias Libres y Open Source son todas aquellas licencias donde la gente tiene

privilegios, como redistribuir, modificar, copiar y entre otros.

No todas las Licencias Libres y Open Source mantienen estos privilegios, puede ser que si

que no dependiendo de cual licencia sea.


PARA MICROEMPRESAS


La aprobación si una licencia es Libre, Open Source o las dos, se encuentra bajo la

responsabilidad de 2 compañías diferentes, la FSF7 encargada de las Licencias Libres, y la

OSI8 encargada de las Licencias Open Source.

Se debe tener a consideración que existen licencias que comparten ciertos atributos y se les

puede considerar tanto Libres como Open Source. Aun así existen excepciones en donde

no cumple.

Licencia Versión FSF OSI

Academic Free License (AFL) 3 Si Si

Apache License 2.0 Si Si

Apple PublicSourceLicense 2.0 Si Si

Berkeley DatabaseLicense Si Si

BSD License Si No

Common Development and Distribution License 1.0 Si Si

CommonPublicLicense 1.0 Si Si

Creative Commons licenses (BY-SA) Si

Creative Commons licenses (NC-ND) No

Eclipse PublicLicense 1.0 Si Si

EUPL 1.1

GNU General PublicLicense 3.0 Si Si

GNU Lesser General Public License 3.0 Si Si

IBM PublicLicense 1.0 Si Si

Intel Open SourceLicense Si Si

Microsoft PublicLicense Si Si Tabla 1-1: Licencias Libres/Open Source más conocidas. [A] Basado en [2], Mayo - 2012.

Licencia Versión FSF OSI

MIT license / X11 license Si SI

7FSF: Free Software Fundation. 8OSI: Open Source Initiative.


PARA MICROEMPRESAS


Mozilla PublicLicense 1.1 Si Si

PHP License 3.01 Si Si

Python Software FoundationLicense 2 Si Si

SunPublicLicense Si Si

W3C Software Notice and License Si Si Tabla 1-2: Licencias Libres/Open Source más conocidas. [A] Basado en [2], Mayo - 2012.

Como se puede apreciar en la Tabla 1−01, existen Licencias que han sido aprobadas por

ambas compañías, como también existen aquellas que no han sido aprobadas aun, o solo

han sido aprobadas por una de las dos compañías.

De entre todas las licencias descritas anteriormente, existen tres de mayor uso y frecuencia

en la comunidad del software libre, estas son:

1.3.1. GPL9

Licencia Pública General es la licencia libre más conocida y más recomendada por FSF.

Cubre la mayor parte del software de la FSF.

Originalmente fue escrita por Richard Stallman en el año 1989. En la actualidad se

encuentra en su tercera versión, la cual fue lanzada a fines del año 2005.

Esta licencia nos permite compartir, modificar, distribuir, el software, tanto el original

como trabajos derivados. Aplica el Copyleft, lo cual significa que cualquier

versionamiento o trabajo derivado debe estar bajo esta misma licencia. Otra característica

importante es que todo software desarrollado bajo este tipo de licencia será gratuito.

1.3.2. LGPL10

9GPL: General Public License. 10LGPL: Lesser General Publication License.


PARA MICROEMPRESAS


Licencia Pública General Menor es una licencia basada en la GPL. La licencia en si es más

permisiva respecto a trabajos derivados, o programas a desarrollar, ya que no es necesario

que estos tengan la misma licencia tanto GPL o LGPL.

Bajo esta licencia se desarrollan paquetes y librerías, ya que su principal diferencia con la

licencia GPL es que permite el poder estar vinculado con un software no-(L) GPL,

independiente de si se trata de software libre o software propietario. Algunos ejemplos de

software con este tipo de licencia son Mozilla y OpenOffice.org.

1.3.3. CreativeCommons

Las licencias de tipo CreativeCommons o CC11, son licencias pertenecientes a

CreativeCommons, desarrolladas en el año 2002.

Estas licencias forjan un balance dentro del termino “todos los derechos reservados”,

dando a las pequeñas, granes compañías e instituciones la facilidad de estandarizar la

forma de asignación los permiso de derechos de autor al su trabajo creativo.

Estas licencias pueden tener o no las siguientes condiciones BY12, NC13, ND14, SA15.

Con BY se puede distribuir, copiar, exhibir, realizar trabajos derivados, solo si se reconoce

y cita al autor, mientras que con NC se puede copiar, distribuir, exhibir, y hacer trabajos

derivados, pero sin fines de lucro, pero con ND se puede copiar, distribuir, exhibir, pero no

se puede generar obras derivadas, y al final con SA se puede distribuir obras derivadas

pero que sean bajo la misma licencia.

La combinación de las condiciones generan las 6 licencias que CC ofrece. Teniendo las

siguientes combinaciones:

• CC-BY: De reconocimiento, es una licencia que permite la distribución,

la capacidad de mezclar, ajustar y de construir en base al trabajo original,

siempre y cuando el autor original sea reconocido por el nuevo trabajo.

11 CC: Creative Commons. 12BY: Atribution. 13NC: No commercial. 14ND: No derivate works. 15SA: Share alike.


PARA MICROEMPRESAS


Puede llegar a ser o no comercial, y es recomendada para la máxima

difusión del software.

• CC-BY-NC: De reconocimiento y no comercial, es una licencia que

permite la capacidad de mezclar, ajustar y construir en base al trabajo

original, aunque los trabajos derivados deben ser acreditados al autor

original y no pueden llegar a ser comerciales.

• CC-BY-ND: De reconocimiento y sin obras derivadas, es una licencia

que permite la redistribución, tanto como comercial como no comercial,

siempre y cuando se transmita el trabajo original sin ningún cambio y en

su totalidad y se acredite todo al autor original.

• CC-BY-SA: De reconocimiento y compartición bajo la misma licencia,

es una licencia que permite la capacidad de mezclar, ajustar y construir

en base al trabajo original, siempre y cuando el autor original sea

reconocido por el nuevo y el trabajo se encuentre bajo el mismo tipo de

licencia. Puede llegar a ser o no comercial.

• CC-BY-NC-SA: De reconocimiento, no Comercial y compartición bajo

la misma licencia, es una licencia que permite la capacidad de mezclar,

ajustar y construir en base al trabajo original, siempre y cuando el autor

original sea reconocido por el nuevo trabajo y el trabajo se encuentre

bajo el mismo tipo de licencia. El trabajo no puede ser comercial.

• CC-BY-NC-ND: De reconocimiento, no comercial y sin obras derivadas,

es una licencia la cual tiene como característica ser más restrictiva. Solo

permite el descargar y el compartir el trabajo original con cualquier otra

persona siempre y cuando el autor original sea reconocido, pero no

tienen derecho a modificar de ninguna forma, ni de usarla en fines

comerciales.

1.4. Licencias Propietarias

Las licencias propietarias son todas aquellas licencias que otorgan derechos al usuario, los

cuales se encuentran suscritos a condiciones impuestas por la compañía que desarrollo el

software. Entre estas condiciones se encuentra el no poder redistribuir, el no poder

modificar y el no poder copiar.


PARA MICROEMPRESAS


Para poder redistribuir o copiar el software, se debe contactar con la compañía

desarrolladora o el propietario para pagar los derechos necesarios o solicitar los permisos

necesarios para la copia o redistribución.

Existen algunas licencias propietarias tales como:

1.4.1. OEM16:

Sus siglas en inglés OEM, o en español, fabricante de equipamiento original, es una

licencia para software preinstalado en una PC17 nueva. Existen dos formas de distribución,

una para fabricantes de equipos originales multinacionales y otra para fabricantes de

equipos locales. Ambos tipos de fabricantes de equipos pueden distribuir PCs con este tipo

de licencia.

1.4.2. Retail:

Son aquellas licencias vendidas con el mismo software que las OEM, pero no se

encuentran preinstaladas. Las licencias de este tipo de software, pueden ser adquiridas a

través de cualquier distribuidor autorizado del software correspondiente.

Las licencias Retail están orientadas hacia aquellas personas o empresas que requieren un

consumo de máximo una copia del software.

1.4.3. Licencias por Volúmenes

El licenciamiento por Volúmenes es la venta de varias licencias del mismo tipo y del

mismo distribuidor para facilitar a las empresas o personas la adquisición del software de

una manera más económica y flexible. Se pueden adquirir con mínimo de dos productos.

1.4.4. EULA18

16OEM: Original Equipment Manufacturer. 17PC: Personal Computer. 18EULA: End-User license agreement.


PARA MICROEMPRESAS


Las licencias de usuario final son aquellas por la cual el uso del producto esta destinado a

solo un único usuario. Este tipo de licencia hace reconocer a los usuarios finales, tener el

conocimiento de las restricciones de uso, los derechos de autor, entre otros, y pide que se

acepte de conformidad respecto a esto.

Este tipo de acuerdo expresa los usos qué se pueden dar y cuáles no al producto, ya que

quien lo compra no es, legalmente, en ninguna forma dueño del producto, sino sólo de una

licencia para su uso, considerándose esto último por algunas personas como una limitación

a los derechos del consumidor.

El ejemplo más reconocido, a nivel mundial, del uso de estos tipos de Licencias

Propietarias lo realiza la empresa Microsoft.

1.5. Herramientas de desarrollo

Las herramientas de desarrollo son todo aquel software que se utilice para el desarrollo de

cualquier tipo de software. Surgieron a partir de la necesidad de facilitar el trabajo, como

para dar solución a los problemas inherentes a los proyectos, tales como plazos,

presupuestos incumplidos, insatisfacción del usuario, escasa productividad y baja calidad

de desarrollo.

Según el avance y las mejoras en los programas de desarrollo se han ido elaborando

herramientas que han ido evolucionando desde Compiladores, Ensambladores, a

herramientas CASE.

Estas herramientas han sido la base fundamental para el desarrollo de herramientas más

complejas y completas. Pero aun así, estas herramientas son fundamentales y aun son parte

de las nuevas herramientas, tales como los Compiladores, que son programas que toman el

código fuente del software y lo convierte al lenguaje ensamblador para que se puede llegar

a interpretar por la maquina, mientras que los Ensambladores son aquellos que se encargan

de convertir el código de lenguaje ensamblador a lenguaje binario, pero lo realizan la

conversión por partes, de una manera lineal.


PARA MICROEMPRESAS


Existen 3 grandes grupos de Herramientas de Desarrollo, estos se encuentran divididos en

IDE19, CASE, Framework.

1.5.1. IDE

Los IDEs son programas informáticos, compuestos por un conjunto de herramientas, tales

como compiladores, ensambladores, enlazadores, entre otras, juntando así todo lo

necesario para el desarrollo de un software.

Existen diferentes IDEs, pero en su mayoría se encuentran compuestos de:

• Un editor del código fuente,

• Un Compilador,

• Un intérprete,

• Un depurador y

• Un sin número de herramientas que facilitan en trabajo del programador.

También existen IDEs con herramientas para el manejo del GUI, o Interfaz Grafica de

Usuario, las cuales facilitan la construcción y el manejo de estas.

Existen IDEs desarrollados específicamente para el manejo de un solo lenguaje de

programación, pero también existen otros que no solo manejan su lenguaje con el que fue

creado, sino que se han adaptado para poder manejar otros lenguajes.

Tal es el caso de Netbeans y Eclipse, los cuales pueden trabajar, no solo con el lenguaje

Java, para lo cual fueron originalmente creados, sino que también pueden trabajar con

C++, Perl, Python, Ruby, PHP 20y entre otros.

1.5.2. Herramientas CASE

Denominadas en español como Ingeniería de Software Asistida por Computadora, son un

conjunto de programas y herramientas que dan asistencia a los analistas, ingenieros de

19IDE: Integrated development environment. 20PHP: Hypertext Preprocessor.


PARA MICROEMPRESAS


software y desarrolladores, durante todos los pasos del Ciclo de Vida de desarrollo de un

Software.

Su clasificación es compleja y puede ser variada. La clasificación más aceptada por los

programadores, está compuesta de 3 categorías:

• Tools

Soportan ciertas tareas en el desarrollo de Software. Son un tipo de software que

automatizan muchas de las actividades que se encuentran envueltas en varias fases del

ciclo de vida.

Por ejemplo los programadores pueden utilizar generadores de código automático para

genera el código en base a las interfaces planteadas, dentro de un proyecto de desarrollo.

Se clasifican en soporte del Ciclo de Vida, Integración, Construcción y basadas en el

conocimiento.

Las de soporte de Ciclo de vida, pueden ser Upper CASE y Lower CASE, mientras que las

de Integración las podemos encontrar en los CASE Framework como herramientas ICASE 21e IPSE22.

• Workbenches

Integran varias herramientas CASE para apoyar actividades especificas dentro del

desarrollo de un software. Tratan de lograr una homogénea y consistente interfaz y una

fácil invocación a las herramientas y cadena de herramientas.

Se pueden clasificar, según su funcionalidad en Planificación y Modelado de negocios,

Análisis y Diseño, Desarrollo de la GUI23, Programación, Verificación y Validación,

Mantenimiento e Ingeniería inversa, Gestión de configuración y Gestión de proyectos.

• Environments

21 ICASE: Integrated Computer-Aided Software Engineering. 22 IPSE: Integrated Project Support Environment. 23 GUI: Graphical user interface.


PARA MICROEMPRESAS


Soportan una gran parte en el desarrollo de software. Son colecciones herramientas CASE

y Workbenches, que dan apoyo completo al desarrollo de software.

Los Environments se clasifican en Toolkits, de lenguaje Centrado, Integrado, De cuarta

Generación y de proceso Centrado.

Los Toolkits son una colección de herramientas y workbenches, su soporte es limitado a la

programación, gestión de configuración y gestión de proyectos.

Los de lenguaje Centrado son ambientes escritos en los lenguajes para los cuales fueron

desarrollados, los cuales pueden ser reusados, customizados, y extendidos, según las

necesidades o gustos.

Por otra parte los integrados son ambientes que logran la integración de la interfaz,

mediante una uniforme, consistente y coherente interfaz de las herramientas y

workbenches. Los de cuarta Generación Son un conjunto de workbenches y herramientas.

Son orientadas al desarrollo de software para el proceso de información electrónica y

aplicaciones empresariales y los de proceso centrado son ambientes que se encargan de la

integración de procesos con otros procesos o puntos de inicio que se encuentran trabajando

con la interpretación de un modulo de procesos, creado por herramientas especializadas,

las cuales manejan dos funciones importantes: ejecución del proceso de modelos, y

producción del proceso de modelos.

1.5.3. Frameworks

Los Framework son un conjunto de herramientas, programas, componentes, entre otros,

que sirve para el desarrollo informático.

Estos ofrecen un diseño estándar, el cual actúa como un tipo de plantilla estándar, a partir

de la cual el programador la modifica agregando o eliminando componentes para poder

generar una interfaz o un programa en concreto.

Existen diferentes Framework, tanto algunos que son destinados para la programación web

o también conocidos como Web application Framework, o Framework dirigidos a modelos

financieros, y entre otros.


PARA MICROEMPRESAS


Cada Framework maneja posee sus propias librerías, escritas en el lenguaje de

programación al cual están orientados. Y en su gran mayoría manejan objetos.


PARA MICROEMPRESAS


2. CAPÍTULO II: TEAM SOFTWARE PROCESS

Actualmente existen un sin número de herramientas que nos permiten desarrollar

correctamente sistemas de software robustos y de alta calidad, todas las metodologías y

modelos de desarrollo tienen el objetivo de crear software diseñado específicamente para

un propósito que es solicitado por el cliente.

Actualmente el software industrial se realiza en equipos de trabajo, y para poder ser un

miembro activo de un equipo no solo se necesita saber programar o diseñar sistemas sino

que también se necesita ánimos y un buen sentido común; con estas herramientas se puede

empezar un buen equipo de trabajo. Pero así mismo un equipo de trabajo debe planear sus

proyectos, tener un seguimiento de sus avances, coordinar actividades y tener los mismos

objetivos.

El Team Software Process, o TSP, es un modelo de desarrollo en equipos que permite

realizar grandes proyectos de software en un ambiente balanceado entre: proceso, producto

y trabajo en equipo.

El Team Software Process, no solo nos permite tener un manejo organizado de la

documentación del un sistema, como veremos en el presente capítulo, pero también nos

permite establecer un proceso de ingeniería de software más maduro y disciplinado, con un

producto final seguro, confiable y en menor tiempo; esto es el por qué decidimos utilizar

este marco de trabajo para el desarrollo de esta disertación.

2.1. Visión general de TSP

2.1.1. Principios de TSPi24

Consta de cuatro principios:

1. Se permite un aprendizaje rápido ya que está dividido por ciclos cortos en los

cuales se mide y determina el avance del proyecto; es por esto que TSPi gracias a

su modalidad de desarrollo y seguimiento con formas establecidas permite un

24TSPi: Introductory Team Software Process.


PARA MICROEMPRESAS


patrón repetitivo, medible y muy claramente definido para la ingeniería de

software.

2. Todo equipo de trabajo productivo requiere una combinación de objetivos y un

buen ambiente de trabajo y en el caso de necesitarlo guía y liderazgo; TSPi brinda

las herramientas necesarias para tener un ambiente de trabajo correcto y una guía

necesaria para cumplir con el objetivo de crear un producto funcional.

3. Siempre que se tienen problemas en el desarrollo de un proyecto y para evitar todos

los retrasos que estos ocasionan se debe seguir la precisa guía del TSPi.

4. La mejor forma de construir un proyecto de software es utilizar conocimiento

previamente aprendido, ha existido gran cantidad de experiencia con equipos de

desarrollo y cursos de ingeniería de software que TSPi es construido con esas

bases.

2.1.2. El diseño de TSPi

Existen varias formas de diseñar un proceso, en el caso de TSPi existen siete decisiones de

diseño principales:

1. Proveer un modelo de desarrollo simple basado en los fundamentos de PSP25.

2. Desarrollar productos de software en varios ciclos.

3. Establecer estándares para calidad y rendimiento.

4. Proveer medidas exactas para los equipos.

5. Realizar evaluaciones de rol y de equipos.

6. Requerir disciplina en los procesos.

7. Proveer guías en problemas de equipo.

2.1.3. Estructura de TSPi:

TSPi usa múltiples ciclos de desarrollo que desembocan en el producto final. El ciclo 1

comienza con la fase de lanzamiento en la cual se definen los objetivos del producto, a

continuación el equipo continúa con las siguientes fases de TSPi:

1. estrategia, 25 PSP: Personal Software Process


PARA MICROEMPRESAS


2. planeación,

3. requerimientos,

4. diseño,

5. implementación,

6. pruebas y

7. postmortem.

Después de esto en el ciclo 2 se comienza con otra fase de lanzamiento y se repiten las

mismas fases, pero esta vez con una reutilización del producto base, creado en el ciclo 1;

así mismo se puede extender el número de ciclos y siempre se reutilizará lo producido en

ciclos anteriores. A continuación en la figura veremos un esquema de los ciclos de TSPi.

Figura 2-1: Estructura y Flujo de TSPi. [A], Mayo - 2012.

2.1.4. Estrategia de desarrollo cíclica


PARA MICROEMPRESAS


Siempre que se empiece con una estrategia de desarrollo cíclica, el mejor plan es comenzar

con la versión viable más pequeña del producto, en el hecho de decidir el tamaño y

contenido de cada ciclo se debe tomar en cuenta lo siguiente:

1. En cada ciclo se debe producir una versión que se pueda probar que sea una sub

parte del producto final.

2. Cada ciclo debe ser lo suficientemente pequeño para que el desarrollo esté listo y

probado en el tiempo disponible.

3. Cuando se combinen todos los ciclos deberían producir el producto final esperado.

2.1.5. Equipos de TSPi

Para que cualquier equipo se convierta en exitoso no ocurre de la noche a la mañana, es

más bien un proceso que toma mucho tiempo, este resultado puede ocurrir por buena

suerte, o por un proceso de construcción de equipos.

En todo equipo lo más importante no es el nivel de fraternidad que tengan los integrantes

más bien es el hecho que todos los integrantes tengan los objetivos claros y trabajen con

profesionalismo, el modelo de desarrollo TSPi, ayuda a los equipos a enfocarse en sus

objetivos, en escoger los roles correspondientes, establecer de buena manera el

planeamiento del proyecto y mantener la buena comunicación entre los integrantes.

2.1.6. Objetivos de Equipo

Todo equipo cuando empieza a trabajar lo más importante que debe considerar son los

objetivos, el TSPi ayuda a que todos los integrantes entiendan los objetivos, pues hace que

cada integrante participe en el desarrollo de estos. Una vez que los objetivos para el primer

ciclo hayan sido establecidos y se llegue al segundo ciclo o a los subsiguientes ciclos,

todos los integrantes del equipo deben considerar la experiencia previa del primer ciclo y

en el caso respectivo los ciclos anteriores para modificar los objetivos para el ciclo actual

en el que se encuentren.

2.1.7. Roles de Equipo


PARA MICROEMPRESAS


Inmediatamente después que el equipo este claro en los objetivos a seguir, se deben dividir

las responsabilidades, para que haya una equidad en el trabajo de cada integrante de equipo

el TSPi distribuye a cada integrante un rol dedicado específicamente para cierta parte del

desarrollo del proyecto para una división de las actividades muy equitativa, los roles de

TSPi son líder de equipo, administrador de desarrollo, administrador de planeación,

administrador de procesos y calidad, y administrador de soporte.

Cada rol tiene diferentes responsabilidades las cuales veremos más adelante.

2.1.8. Planeación de Equipo

Una vez que el equipo haya acordado en sus objetivos y sus roles el planeamiento es muy

importante ya que este se convierte en la estrategia para poder cumplir los objetivos

planteados previamente, con TSPi la primera decisión es como dividir todo el trabajo en

los diferentes ciclos, el equipo define el contenido funcional de cada ciclo, el tamaño

esperado y la forma de integrar y probar estas partes para producir el producto final

esperado. Una vez planeado todo con respecto a tamaños de cada ciclo y tiempo que

costará realizar cada parte, se tendrá el plan de desarrollo.

2.2. Fases de TSPi

2.2.1. Fase de lanzamiento TSPi

En la fase de lanzamiento se deben tener en cuenta que los equipos deben tener en claro y

proponer objetivos tanto de equipo, como miembro de equipo y de su rol, así mismo en la

fase de lanzamiento siendo el primer paso ahorra tiempo en el futuro ya que designar las

responsabilidades de cada miembro del equipo y permitirá resolver cualquier problema en

este aspecto.

Existen tres tipos de objetivos en TSPi, los objetivos del equipo, los objetivos de cada

miembro y los objetivos del rol que desempeñaran, los cuales veremos a continuación:

• Objetivos de equipo


PARA MICROEMPRESAS


Los objetivos de equipo es lo primero que se debe plantear al empezar un proyecto ya que

es un paso esencial en el desarrollo del mismo. El principal problema en establecer

objetivos es que deben ser objetivos medibles con exactitud, y muy pocos de nosotros

tenemos el hábito de ser precisos en nuestro trabajo.

Los objetivos establecen el marco de trabajo para la estrategia y el planeamiento, y estos

son las bases y fundamentos del resto del ciclo.

Una vez que se hayan establecido los objetivos del equipo el trabajo de evaluar la

estrategia y plantear los problemas que podrían existir.

La mejor manera de establecer los objetivos sin entrar en confrontación con otros

miembros de equipo y sin usar la guía de TSPi es:

1. Definir los objetivos del proyecto.

2. Especificar la mejor manera de medirlos.

3. Describir la razón por la que se van a utilizar los objetivos creados por el equipo y

no los proporcionados por TSPi.

4. Proporcionar una copia de los objetivos a los integrantes del equipo.

5. Proporcionar una copia de los objetivos al administrador de soporte para que los

anexe en la carpeta del proyecto.

• Para establecer los objetivos con la guía de TSPi:

Antes que nada se debe tener en cuenta que el cliente espera un producto de calidad y que

llene sus expectativas, es por esto que TSPi propone los siguientes objetivos básicos:

1. Generar un producto de calidad.

2. Realizar un proyecto bien administrado y que sea productivo.

3. Terminar a tiempo.

Y la mejor manera de medir los objetivos previamente descritos es la siguiente:

1. Generar un producto de alta calidad.

a. Porcentaje de errores encontrados antes de la primera compilación: 80%.

b. Número de errores encontrados en la prueba del sistema: 0.


PARA MICROEMPRESAS


c. Requerimientos funcionales incluidos al finalizar el proyecto: 100%.

2. Realizar un proyecto bien administrado y productivo.

a. Error en el tamaño del producto estimado: menor al 20%.

b. Error en las horas de desarrollo estimadas: menor al 20%.

c. Porcentaje de datos registrados e incluidos en la carpeta del proyecto: 100%.

3. Terminar a tiempo.

a. Días anteriores o posteriores para terminar el ciclo de desarrollo: menor a 4.

2.2.2. Fase de estrategia TSPi

En esta fase del TSPi se divisa una estrategia para el trabajo con todos los miembros del

equipo además se crea un diseño conceptual del producto y fijamos un estimado del

tamaño y el tiempo que tomará el desarrollo de este ciclo.

La estrategia se realiza antes que la planeación ya que al establecer la estrategia surgirán

materiales que se necesitarán en la planeación, tanto la estrategia como la planeación están

muy bien relacionados.

• Estrategia

La estrategia consiste en aplicar un proceso de desarrollo cíclico para desarrollar el

producto. En cada ciclo se deciden cuáles funcionalidades deberán ser desarrolladas. En el

primero de ellos se diseña, implementa y evalúa una primera versión del producto; en el

segundo ciclo, se incrementan las funcionalidades del producto para generar una segunda

versión. Y de ser necesario se repite este patrón para los siguientes ciclos subsiguientes.

Siempre se debe tener en cuenta que se debe re usar todo lo que se pueda, ya que esto nos

dará un ahorro tanto de tiempo como de recursos.

• Diseño conceptual

El diseño conceptual es el punto inicial para la planeación del proyecto. Cada integrante

del equipo debe participar en la conceptualización del producto ya que cada integrante


PARA MICROEMPRESAS


debe participar en el cómo crear el producto, estos serán los componentes principales y

funcionalidades del ciclo y se debe estimar el tamaño y tiempo requerido para el desarrollo

el producto final.

• Administración de Riesgos

Un problema o issue en el idioma inglés, se define como un problema real que tendrá un

tiempo determinado por los miembros del equipo para ser manejado sin que intervenga en

el desarrollo normal del proyecto.

Un riesgo en cambio es cuando algo fuera de lo común puede o no aparecer y

entrometerse en el correcto desenvolvimiento del proyecto, por esta razón lo mejor es

detectar y tomar acciones en contra de estos riesgos al comienzo del proyecto, todos los

miembros del equipo bene proponer posibles problemas y soluciones a estos en un tiempo

determinado.

2.2.3. Fase de Planeación TSPi

El fundamento de todo buen proyecto es saber bien planear todo, y esto es bueno porque se

puede más eficientemente ya que siempre se tiene una actividad determinada que hacer y

cuando hacerla.

En el caso de que no se planee se corre el riesgo de que se olviden diferentes actividades o

que se desarrollen actividades en diferente orden, esto causa perdida de tiempo y recursos

que en un proyecto de software son extremadamente importantes.

• Planeando con lujo de detalle

TSPi solicita que cada miembro de grupo de trabajo estime como máximo 10 horas a las

tareas designadas.

Aun así, existen tareas como los requerimientos y el diseño de alto nivel que necesitarán

más de 10 horas porque serán desempeñadas por varios ingenieros, es por esto que es muy

necesario que se planee con anticipación los componentes del sistema.


PARA MICROEMPRESAS


• Tareas no planeadas

A menos que haya experiencia en proyectos previos similares al actual, se tendrán

diferentes actividades que no fueron planeadas, y es ahí que normalmente se debería volver

a planear.

En algunos casos las actividades no planeadas ocupan más tiempo que re plantear la

planeación en sí, es por esto que TSPi designa una sección cada semana para poder

desarrollar tareas no planeadas, y así no cambiar el orden de las cosas, una vez que esto

haya ocurrido en los ciclos subsiguientes se planeará las actividades que en ciclos

anteriores no fueron planeadas.

• Proceso de planeación

El proceso de planeación que propone el modelo de desarrollo TSPi podrá parecer difícil

de entender y aplicar, pero una vez que se entiende cada paso, se notará que son simples:

1. Lo primero es tomar el diseño conceptual creado anteriormente en la fase de

estrategia.

2. Se estima los tamaños de las diferentes partes del diseño conceptual, y en el diseño

conceptual se tiene que partes se desarrollaran en que ciclo.

3. En este paso se determina actividades extras que se desarrollaran solamente en este

ciclo como son las pruebas de sistema o requerimientos específicos, se ingresa en la

carpeta del proyecto todo lo referente a tamaños de este ciclo.

4. A continuación se listan las tareas nombradas en el paso 3 y se estima el tiempo de

duración de cada una de las actividades, así mismo se denotará el tiempo que cada

integrante tomará semanalmente en cada tarea.

5. En este paso se realiza el plan de calidad.

6. Cada integrante recibe las actividades que se le fueron designadas para poder

realizar sus estimaciones individuales.

7. Así mismo al igual que se realizó para todo el equipo se realiza la estimación en

tiempo y tamaño de lo que cada integrante se demorará en desarrollar sus

actividades individuales.


PARA MICROEMPRESAS


8. Es muy importante que las actividades y la cantidad de trabajo sean balanceadas, ya

que no se debe sobre cargar a ningún integrante con cargas de trabajo muy grandes

ya que no se creará un buen ambiente de trabajo ni un buen producto.

9. Con todos los planes individuales de cada integrante, se crea el plan final del ciclo,

y copias de este plan se les entrega a cada miembro de equipo.

Figura 2-2: Pasos de la Fase de Planeación. [A], Mayo - 2012.

2.2.4. Fase de requerimientos TSPi

En la fase de requerimientos se revisan las necesidades del cliente y se formulan preguntas

acerca de las funciones del producto. En esta fase se determina exactamente todos los

problemas clave de los requerimientos.

En esta fase el equipo produce el SRS26 el cual provee una clara y no ambigua descripción

que será el producto. Este deberá tener un criterio valido para evaluar el producto final y

asegurarse que hace lo que debería hacer.

26 SRS: Software Requirements Specification.

1. Producir diseño conceptual

2. Desarrollar la estrategia

3. Estimar tamaños

4. Producir plan de equipo

5. Crear plan de calidad

6. Estimar actividades individuales

7. Desarrollar planes

individuales

8. Balancear carga de trabajo

9. Plan de equipo final


PARA MICROEMPRESAS


La parte más difícil de esta fase es entender las necesidades del cliente ya que por lo

general el cliente tiene una idea vaga de lo que quiere y necesita; debido que la

automatización gracias a un producto de software cambia la forma en que realizan su

trabajo, el cliente necesita de nuestra ayuda para definir todos sus requerimientos en forma

funcional para que el producto final de verdad les sea útil.

• Extracción de los requerimientos

Generalmente en proyecto de desarrollo de software lo primero que se hace es reconocer

los requerimientos que el cliente solicita, para esto se interroga al cliente haciendo

preguntas claves, así mismo se interroga a los usuarios o demás involucrados para poder

determinar la verdadera necesidad que se tiene en torno a este nuevo sistema a desarrollar.

Para poder extraer requerimientos de mejor manera a continuación los pasos que TSPi

propone:

1. Evaluar la factibilidad del sistema.

2. Conocer y comprender los asuntos organizacionales.

3. Identificar a todos los involucrados en el proyecto.

4. Registrar las fuentes de requerimientos.

5. Definir el ambiente operativo del sistema.

6. Evaluar asuntos del negocio.

7. Definir las restricciones del sistema.

8. Con cada requerimiento denotar la razón.

9. Realizar un primer prototipo de los requerimientos.

10. Definir los escenarios de uso.

11. Definir los procesos operacionales.

• SRS

El documento de requerimientos SRS por sus siglas en ingles, describe tu plan de

desarrollo y como se desea que el producto funcione, los requerimientos no deben explicar

cómo construir el producto, ni siquiera implicar la construcción del mismo. Eso es parte

del diseño, y se debe dejar para la fase de diseño.


PARA MICROEMPRESAS


El TSPi se concentra en los requerimientos funcionales y operacionales del producto, es

por esto que los temas principales para el SRS son los siguientes:

1. Requerimientos funcionales: Cálculos, casos de uso, entrantes y salientes de

información.

2. Requerimientos externos de interface: Usuarios, hardware, software y

comunicaciones.

3. Limitaciones de diseño: formatos de archivos, lenguajes, estándares,

compatibilidad.

4. Atributos: disponibilidad, mantenimiento, conversión.

5. Otros requerimientos: Bases de datos, instalación, entre otros.

Con TSPi es muy importante que los integrantes de equipo estén de acuerdo con los

requerimientos establecidos y no solo los requerimientos funcionales si no que en las

interfaces externas.

2.2.5. Fase de diseño TSPi

En esta fase empieza la parte creativa del proceso de desarrollo de software, en el cual

todos los integrantes deben producir una completa y precisa especificación de cómo el

producto debe ser construido.

Un diseño completo define las partes de un producto, describe cómo esas partes interactúan

y especifica cómo unirlas para producir el resultado final.

Es muy importante que para el diseño se utilice todo el equipo de trabajo ya que no se

puede perder tiempo tratando de incorporar diferentes partes del proyecto cuando no han

estado de acuerdo desde el principio.

Cada integrante tiene una visualización diferente del proyecto y puede aportar con

diferentes ideas las cuales pueden ayudar a un mejor desenvolvimiento del equipo al

momento del diseño.

• Estándares de diseño

TSPi considera que los más importantes estándares para el diseño son los siguientes:


PARA MICROEMPRESAS


• Nombramiento: Debe existir un glosario para el desarrollo del sistema que

contenga el nombramiento de todo el sistema jerárquicamente, a su vez que

contenga las convenciones de los nombres de archivos, variables, parámetros,

procedimientos, controles y cambios de nombres.

• Formatos de interfaz: se definirán los formatos y todo el contenido de los

componentes de las interfaces, esto incluye en indicar los parámetros de las

variables, códigos de error y otras condiciones.

• Mensajes de sistema y de errores: es muy importante que los mensajes sean claros y

entendibles para que sean consistentes y se pueda tener un procedimiento claro en

el desarrollo de mensajes.

• Estándares de defectos: Se recomienda que se utilice el estándar de PSP para

errores.

• Estándares de representación de diseño: define el producto que se generará por el

diseño, seguir estos estándares permitirán una ayuda al momento de evitar

problemas en la implementación y pruebas.

El documento de diseño SDS27, será de utilidad tanto para el primer ciclo como cualquier

ciclo subsiguiente ya que este tendrá el diseño globalizado del proyecto; este documento

define las interfaces externas y las especificaciones funcionales de cada componente del

cual se conforma el proyecto.

El último paso en un diseño de alto nivel es producir varios documentos de diseño

especificando la lógica y estructura del sistema principal del programa. Una vez concluido

el SDS se debe revisar bien junto a los miembros del equipo que no haya ningún error y en

el caso de haberlo repararlo, de esta manera ahorraran tiempo y no se perderá recursos

luego al tratar de arreglar errores de esta etapa. Una vez que se haya revisado el SDS el

administrador de desarrollo se encargará de tener unido de todo el diseño el cual deberá

entregar a los demás miembros del equipo.

27 SDS: Software Design Specification.


PARA MICROEMPRESAS


2.2.6. Fase de implementación TSPi

Generalmente en un sistema grande el diseño se divide en varias etapas o mejor

denominadas como módulos o componentes, es por esto que la primera cosa antes de

empezar a implementar se debe revisar el diseño de alto nivel y completar en el caso de ser

necesario o hacer las modificaciones necesarias.

Para los sistemas grandes, se utiliza un concepto de implementación paralela la cual

consiste en desarrollar diferentes módulos paralelamente e implementarlos es sus

especificaciones externas terminadas y previamente inspeccionadas.

• Revisión de estándares

Para que un proyecto empiece con pie derecho en la fase de implementación se deba

revisar los estándares a usar por cada uno de los integrantes del equipo de trabajo, a

continuación mencionamos lo que se debería revisar como primer orden:

1. Los estándares de nombres, de interfaces y de mensajes desarrollados durante la

fase de diseño.

2. La lista de rutinas que se re utilizarán para determinar que estén terminadas, y que

cada integrante las utilice.

3. El glosario de nombres para asegurarse que cada quien está usando el mismo

nombre para el mismo producto y que todos los nombres nuevos se van agregando

al glosario.

4. Los nombres de componentes, los nombres de las variables compartidas, de los

parámetros y de los archivos para verificar su consistencia.

5. Las interfaces y los mensajes estándares para asegurarse de que ya han sido

definidos, registrados en el glosario de nombres y que son conocidos y utilizados

por los integrantes del equipo.

• Prevención de defectos

El TSPi propone cuatro diferentes consejos para la prevención de defectos, ya que si se

conoce las causas de los defectos es más fácil prevenirlos:

1. Aprender lo que más se pueda del lenguaje, el ambiente y la aplicación.


PARA MICROEMPRESAS


2. Reparar el proceso.

3. Usar mejores herramientas

4. Re definir el proceso y utilizar mejores métodos.

La idea de la prevención de defectos es buscar las diferentes maneras para modificar lo que

uno hacer y así prevenir que se cometan los defectos, una vez realizado algún cambio,

incorporar esto al proceso, y dar un seguimiento para ver la productividad del cambio

realizado.

2.2.7. Fase de pruebas TSPi

El objetivo final de la fase de pruebas consiste básicamente en evaluar el producto pero sin

modificarlo, una vez que hayamos llegado a la fase de pruebas, significa que los defectos

fueron detectados y arreglados porque la calidad de un producto de software se determina

mientras se desarrolla.

• La estrategia de pruebas de TSPi

La estrategia de pruebas de TSPi lo que trata de hacer es evaluar que todos los productos

desarrollados en el ciclo sean de alta calidad, las actividades más importantes que se

realizan son:

1. Utilizar los módulos desarrollados y construir el sistema.

2. Pruebas de integración de sistema para verificación que el sistema se encuentra

bien construido y que todos los módulos se encuentran en su lugar.

3. Pruebas del sistema para verificar que el producto cumple los requerimientos

solicitados por el cliente.

La metodología para las pruebas son las siguientes:

1. Construcción: integrar las partes del sistema en uno solo y dejarlo listo para aplicar

las pruebas.

2. Integración: Unir todas los módulos en conjunto.

3. Pruebas de integración: Estas aseguran que todo el sistema tenga todas las partes

necesarias y estén trabajando correctamente.

4. Pruebas de sistema: Es la prueba más clara del funcionamiento del producto contra

los requerimientos solicitados.


PARA MICROEMPRESAS


2.2.8. Fase PostmortemTSPi

La fase de postmortem es la última etapa de cada ciclo del TSPi, en esta fase se revisa que

el equipo haya cumplido con todas las tareas y objetivos planteados así mismo hayan

registrado todos los datos necesarios. Esta fase permite una forma de aprendizaje más

estructurado y mejorado, en esta etapa se mide tanto el desempeño individual de cada

integrante como el del equipo en total.

Lo más importante de la fase de postmortem es el hecho de mejorar para siguientes ciclos y

proyectos, lo más importante que se debe realizar es registrar las ideas de mejoras, ya que

estas incluyen las mejores prácticas personales sobre todo el trabajo de equipo que se

realizó así mismo se mejoran las herramientas a utilizar y cualquier aspecto que se

relacione con mejorar el desempeño del trabajo.

• Reportes

Una vez que se llega a la fase de post mortem se puede realizar el reporte de ciclo el cual

consiste en describir todo lo que se produjo, los procesos que se uso y los roles de cada

integrante.

En los reportes de ciclo se describe a detalle lo que se hizo, lo que no se hizo y cómo

podemos mejorar para el próximo ciclo; así mismo se debe hacer un reporte acerca del

rendimiento del equipo con respecto a tus responsabilidades, el rendimiento personal de

cada integrante como desarrollador y como el rol desempeñado.

• Evaluación de roles

Cada integrante del equipo prepara una evaluación personal indicando el desempeño del

equipo en general y como fue desempeñado cada rol en el equipo.

Estas revisiones permiten una oportunidad de reconocer lo que se realizó de mejor manera

durante el transcurso del ciclo y se realizan sugerencias en los roles o tareas que puede ser

mejoradas para ciclos futuros.


PARA MICROEMPRESAS



PARA MICROEMPRESAS


3. CAPÍTULO III: PUNTOS DE VENTA EN EL ENTORNO

ECUATORIANO

La forma en que se registran, en el Ecuador, las ventas de una empresa se la conoce como

punto de venta, el cual permite hacer un registro rápido y eficaz de las ventas que se estén

realizando.

3.1. Punto de venta

Punto de venta o en ingles (Point of Sale - PoS), se puede definir de dos maneras, desde un

enfoque macro se considera a las tiendas, locales, centros comerciales, o ciudades;

mientras en un enfoque micro se considera al cajero o la caja donde las personas pagan lo

que compran.

Un PoS de productos o de servicios es un importante foco para los mercados, ya que los

consumidores tienden a tomar decisiones acerca de que comprar o que adquirir en estos

lugares.

El PoS puede ser desde solo un cuaderno, dónde el cajero anota sus ventas diarias, o puede

ser un PoS automatizado que conlleva a ser un sistema de software y hardware con las

siguientes partes:

• Computadora General

• Software de la Computadora

• Caja registradora

• Software del hardware de la Caja

• Varios implementos de hardware

3.2. Punto de venta en línea

Un PoS en línea maneja el mismo concepto que un PoS regular, aquel que se encuentra en

las tiendas o locales de ventas, pero se este, encuentra alojado en un servidor en la web.


PARA MICROEMPRESAS


3.3. Características importantes al adquirir un PoS en línea

Algunas de las características que se considera cuando se va a adquirir un PoS en línea son:

• De fácil uso

Que posea una interfaz grafica amigable, para que no requiera de mucho trabajo el

interpretar o entender el cómo trabajan sus funciones.

• Entrada de información de ventas

El sistema debe poseer un registro de los diversos productos, ya sea por medio de código

de barras, u otros, o que se ingrese manualmente en una base de datos. De esta forma el

cajero o vendedor, podrá obviarse los cálculos y la búsqueda de los productos, o

simplemente tendrá una base de datos completa con la cual podrá encontrar algún producto

mediante sus diversos atributos.

• Precios

El sistema debería permitir manejar los precios de los productos, ingresando porcentajes,

descuentos, o formulas de ventas al por mayor, de esta forma el vendedor o cajero podría

aplicar descuentos a las ventas por mayor o poner varios precios a un mismo producto.

• Actualizar la información de los productos

El sistema debería disminuir de la base de datos de inventario la cantidad de productos que

se han vendido, de esta forma el vendedor o el encargado de administrar los productos

estará siempre con información actual y concreta.

• Seguridad en ventas

Es importante tener un control riguroso sobre los recibos para evitar el robo. Se requiere

tener una base y control sobre estos recibos o facturas.


PARA MICROEMPRESAS


• Impuestos

Debería soportar muchos tipos de impuestos, y tener la factibilidad de modificar los

impuestos ya generados, ya que existen casos donde se requiere incrementar el porcentaje

del impuesto o disminuirlo.

• Opciones de seguimiento de ventas

Cada negocio tiene su propio sistema de ventas, por lo que deben implementar un

seguimiento de ventas. En la mayoría de los casos es metodológicamente le mismo, pero

en aquellos donde su venta no es de un producto sino de un servicio, existen ciertas formas

de facturar, y donde el seguimiento de ventas se ve alterado.Tal es el caso de facturación

en partes o congelación de las facturas, entre otros.

3.4. Requerimientos básicos para un punto de venta

Los PoS están conformados de 2 partes, el hardware y el software.

3.4.1. Software

El Software para un PoS es muy especializado, comparado con cualquier otro tipo de

software. Eso se debe a la diversa gama acciones que se pueden hacer o tomar en el

momento de una venta.

El software debería llegar a manejar ventas especiales, ordenes de compra, ordenes de

reparación, servicios, programas de alquiler, así como las funcionalidades básicas de un

cajero.

El software para un PoS se puede encontrar en las siguientes formas:

• A Medida

Es completamente especifico, suelen ser muy caros comparados a los otros tipos, y sus

actualizaciones o modificaciones se encuentran ligadas a la empresa que lo desarrollo.


PARA MICROEMPRESAS


• Comerciales

Son de carácter general, para cualquier tipo de PoS, por ejemplo: ropa, hotelería, ferretería,

farmacias, etc. Suelen estar diseñados y enfocados para un tipo de negocio, suelen ser más

económicos.

• Específicos

Son los que se encuentran embebidos en las terminales de los PoS. Suele serel caso que la

empresa que lo desarrolla, lo adjunta en el hardware y lo vende de forma conjunta. Son

diseñados para un sector en concreto y no se pueden reutilizar para otros.

3.4.2. Hardware

Usualmente se requiere de equipo especial para la instalación de un PoS, ya que este se

encuentra expuesto a la vista de todas las personas, en la mayoría de los casos será el

último punto donde el cliente estará antes de salir del local comercial.

Se emplean dispositivos inalámbricos, dispositivos a base de baterías, computadoras

especiales con acceso a internet, para tener un fácil acceso a internet.

El hardware de un PoS se puede encontrar en las siguientes formas:

• Compacto

Son equipos específicamente diseñados para ser un PoS. Incluyen e integran los periféricos

necesarios, tales como impresora de recibos, pantallas para clientes, teclado, una caja

registradora.

Son hechos a la medida, poseen piezas especializadas, tales como pantallas y teclados

resistentes a los líquidos, discos de estado sólidos, entre otras.

Son de bajo costo de mantenimiento, son fiables, y se encuentran diseñados solo para

trabajar en PoS, por lo que vienen con su propio sistema operativo, el cual elimina las

características innecesarias que existen en un computador personal, incrementando su

estabilidad.


PARA MICROEMPRESAS


• Modular

Son equipos basados en computadores personales, los cuales han sido adaptados para ser y

actuar como un PoS.

Si bien pueden ejecutar las aplicaciones de un PoS, resultan ser más voluminosos, menos

fiables, y de mayor mantenimiento. Suelen ser una solución más económica que los

equipos Compactos.

Las partes que se utilizan suelen ser:

1. Monitor de una PC o un monitor de sistema táctil.

2. Teclado de una PC o uno de reducidas dimensiones.

3. Impresora de tickets.

4. Cajón portamonedas.

Existe otro hardware en los PoS, en la mayoría de tiendas o locales se utilizan, pero no son

tan indispensables, estos son:

− Lector de código de barras.

− Pantalla o visor electrónico, para mostrar la información al cliente de cuanto

ha sido su consumo final.

− Lector de banda magnética.

3.5. Razones para usar un PoS en Línea

Existe la duda del porque sería mejor un PoS en línea vs un PoS tradicional, y claramente

existen razones para fundamentar el uso del PoS en línea, tales como:

• Es accesible desde cualquier lugar

Siempre y cuando se posea conexión a internet se puede acceder al sistema, y a todas sus

funcionalidades, de forma fácil, rápida y segura.

• No se requiere actualizar el software


PARA MICROEMPRESAS


Ya que el software es una solución en línea, se encontrará alojada en un servidor en la web,

y todas las actualizaciones serán automáticas.

• Respaldos automáticos

Ya que la información se encuentra alojada en un servidor, la información de la base de

datos y de los respaldos se encontrara de forma segura alojados en este mismo en un

computador personal, preferiblemente del gerente o la persona a cargo.

• Seguro

Si se manejara un PoS convencional podría pasar algún percance al hardware de este

mismo.Con la solución del PoS en línea no importaría si su computador sufre algún

percance, ya que toda su información, datos y el software en si, estarán en la nube o

remotamente en un servidor.

• Fácil de usar

No se requiere de ninguna explicación o entrenamiento técnico, solo se requiere que sepas

usar un navegador, y una breve explicación de las funciones básicas del software.

3.6. Entorno Ecuatoriano

Toda persona natural que tenga a su disposición la capacidad legal, podrá desarrollar

cualquier actividad económica por medio de una empresa unipersonal de responsabilidad

limitada28.

Toda la responsabilidad de esta empresa estará sujeta al monto del capital que haya sido

destinado para esta.

28 Ley de Empresas Unipersonales de Responsabilidad Limitada. Publicada Registro Oficial 196. Enero 2006


PARA MICROEMPRESAS


3.6.1. Microempresa

En el artículo 2 del “Reglamento de aprobación de microempresas asociativas”, de la

norma: Acuerdo Ministerial 14, publicación en el registro oficial 524, con fecha: 15 de

febrero de 2005; dice textualmente: “Microempresa es una unidad económica operada por

personas naturales, jurídicas o de hecho, formales o informales que se dedican a la

producción, servicios y/o comercio.

Se encuentran en los subsectores de alimentos, cerámico, confecciones-textil, cuero y

calzado, electrónico - radio - TV, gráfico, hotelería - restaurantes - turismo, químico -

plástico, materiales de construcción, maderero, metalmecánica, servicios profesionales,

transporte, de servicios públicos y cuidado de carreteras, y otros”.

Podemos denotar que en el Ecuador existen un gran número de microempresas ya que “las

tiendas de barrio” o “los kioskos” si están debidamente registrados son considerados como

microempresas.

Una microempresa asociativa se construye con un número limitado de socios, con la

condición que trabajen en el mismo ámbito. Así mismo se pueden contratar hasta un

número máximo de diez personas independientes.

Para que una empresa sea considerada como tal debe tener un capital máximo de veinte mil

dólares estadounidenses; a este valor no se le incluye inmuebles ni vehículos que la

microempresa pudiese tener.

El nombre que se presenta con una nueva microempresa a ser registrada no podrá ser el

mismo de otra microempresa previamente registrada en el Ministerio del Trabajo y

Empleo.

Una microempresa está calificada para poder participar en los concursos de compras

estatales ya que las empresas estatales están en la obligación de considerar como

proveedores a los microempresarios y microempresas.


PARA MICROEMPRESAS


3.6.2. Relación laboral

El estado ecuatoriano define la relación laboral de dependencia como trabajador es aquel

empleado que presta un servicio o ejecuta una obra bajo las órdenes de su empleador.29

Es empleador de un negocio toda persona que emplea a otros para que ejecuten algo o

presten un servicio, por cuenta suya o bajo su orden. Es dueño de una microempresa, toda

persona que establece una empresa o negocio, para prestar servicios o arriesgar capitales.

3.6.3. Impuesto al valor agregado

“Se establece el Impuesto al Valor Agregado (IVA), que grava al valor de la transferencia

de dominio o a la importación de bienes muebles de naturaleza corporal.

En todas sus etapas de comercialización, así como a los derechos de autor, de propiedad

industrial y derechos conexos; y al valor de los servicios prestados, en la forma y en las

condiciones que prevé esta Ley.”30

El IVA es un impuesto que se paga al gobierno ecuatoriano calculado del valor total del

bien que se está obteniendo, sea este servicio o bien. El valor que se calcula es el doce por

ciento, 12%, al monto del bien o servicio.

Así mismo hay transferencias que no son objeto del pago de IVA como por ejemplo:

• Pagos en especie.

• Herencia y liquidación de sociedades.

• Ventas de negocios.

• Fusiones o transformaciones de sociedades.

• Donaciones.

• Cesión de acciones.

• Las cuotas de condominio para mantenimiento de condominios.

29Norma: Resolución del IESS 301, Publicación: Registro oficial 128, 11 – 02 – 2010, Reforma: 22 – 11 - 2011 30 Ley de régimen tributario interno. Codificación 16, reforma: 28 – 12 – 2011, Articulo: 52.


PARA MICROEMPRESAS


Así mismo hay productos considerados que tienen tarifa de cero con respecto al pago estos

son tanto de transferencia como de importaciones, a continuación veremos cuáles son:

• Productos de origen agrícola, avícola, pecuario, apícola, cunícola, forestales, bio-

acuáticos.

• Leches tanto nacionales como importadas.

• Pan, azúcar, panela, sal, manteca, margarina, avena, maicena, fideos, harinas de

consumo humano, enlatados nacionales de atún, macarela, sardina y trucha, aceites

comestibles, excepto el de oliva.

• Semillas y plantas de uso doméstico.

• Harinas de pescado y alimentos balanceados.

• Medicamentos y drogas de consumo humano, estos dependerán de la lista que

emita el Presidente de la República mediante un decreto al inicio de cada año.

• Papel bond, libros y material complementario que se comercializa con libros.

• Energía eléctrica.

• Lámparas fluorescentes.

• Aviones, avionetas y helicópteros destinados al transporte de pasajeros.

• Vehículos híbridos o eléctricos, cuya base imponible sea hasta USD 35000.31

En el caso de los servicios que son prestados por parte del Estado o personas naturales para

beneficio de un tercer implicado, requieren el pago del IVA a excepción de los siguientes:

• Transporte nacional terrestre y acuático de pasajeros y carga

• Salud

• Arrendamiento de inmuebles destinados para vivienda

• Servicios públicos de energía eléctrica, agua potable, alcantarillado y los de

recolección de basura

• Educación

• Guarderías infantiles y hogares de cuidado de ancianos

• Religiosos

• Impresión de libros

31 Ley de régimen tributario interno. Codificación 16, reforma: 28 – 12 – 2011, Articulo: 55.


PARA MICROEMPRESAS


• Funerarios

• Administrativos prestados por el Estado

• Espectáculos públicos.

Las microempresas tienen la obligación de emitir una factura la cual es entregada al

adquiriente del bien, o receptor del servicio con la descripción de todo lo que se está

realizando.

Esta deber ser realizada por las microempresas a pesar que los bienes o servicios tengan

tarifa cero. En las facturas se debe tenerpor separado el valor de cada ítem y los impuestos

que rijan a estos, sean de tarifa cero o no.

En el caso de no emitirse facturas se considera un caso de fraude hacia el Estado y la

sanción será conforme al Código Tributario.

Todas las microempresas deberán declarar sus actividades mensualmente, y deberán

realizarlo hasta el siguiente mes de realizadas las actividades económicas.

3.6.4. Impuesto a los consumos especiales

El impuesto a los consumos especiales ICE, es un impuesto que se aplica sobre una cierta

gama de bienes y/o servicios nacionales o importados los cuales detallaremos a

continuación:

• Productos de uso diario

Descripción Valor

Productos del tabaco 150%

Bebidas Gaseosas 10%

Perfumes 20%

Videojuegos 35%

Armas de fuego o deportivas 300%

Focos incandescentes 100% Tabla 3-1: Productos de Uso Diario. [A], Mayo – 2012.


PARA MICROEMPRESAS


• Vehículos de transporte terrestre hasta 3.5 toneladas de carga:

Descripción Valor

Venta al público hasta USD 20000 5%

Camionetas, Furgonetas, Camiones y vehículos de rescate que el PVP32 sea hasta USD 30000 5%

Vehículos motorizados (excepto los nombrados anteriormente) que el PVP desde USD 20000 hasta USD 30000 10%

Vehículos motorizados que el PVP entre USD 30000 y USD 40000 15%




Vehículos motorizados que el PVP sea desde USD 70000 en adelante 35% Tabla 3-2: Vehículos de transporte terrestre hasta 3.5 toneladas de carga. [A], Mayo – 2012.

• Vehículos motorizados híbridos o eléctricos de hasta 3.5 toneladas de

carga

Descripción Valor

Vehículos híbridos o eléctricos que el PVP sea hasta USD 35000 0%

Vehículos híbridos o eléctricos que el PVP sea entre USD 35000 y USD 40000 8%




Vehículos híbridos o eléctricos que el PVP sea superior a USD 70000 32% Tabla 3-3: Vehículos híbridos o eléctricos hasta 3.5 toneladas de carga. [A], Mayo - 2012.

Aviones, avionetas y helicópteros excepto aquellas destinadas al transporte comercial de

pasajeros, carga y servicios; motos acuáticas, tricares, cuadrones, yates y barcos de recreo:

15%

32 PVP: Precio de venta al público


PARA MICROEMPRESAS


• Servicios

Descripción Valor

Televisión Pagada 15%

Casinos y salas de juego 35%

Cuotas de membrecías y afine de clubes de recreación que su PVP supere los USD 1500 anuales 35%

Tabla 3-4: Servicios. [A], Mayo – 2012.

• Para los siguientes productos se ha establecido una tarifa específica

Descripción Valor

Cigarrillos USD 0,08 por unidad

Bebidas alcohólicas incluida la cerveza USD 6,20 por litro

Alcohol puro 75% Tabla 3-5: Tarifa Específica. [A], Mayo - 2012.

Toda microempresa que venda cualquiera de los productos presentados en los cuadros

deberá presentar una declaración mensual con el detalle de los productos y el impuesto

realizados el mes anterior a la declaración.


PARA MICROEMPRESAS


4. CAPÍTULO IV: DESARROLLO

Para el desarrollo del sistema PoS, se utilizará el modelo de desarrollo TSPi, el cual está

descrito en el capítulo dos de la presente disertación.

4.1. Ciclo 1

A continuación empezaremos el desarrollo del proyecto en el orden que TSPi lo indica, a

través de fases.

4.1.1. Fase de Lanzamiento

La fase de Lanzamiento es la primera en el proceso de TSP, en esta fase se definen muchos

puntos, entre los más importantes se encuentran las metas del equipo, las metas por

miembro del equipo, la distribución de los roles dentro de las personas en el equipo, las

metas por cada rol.

En esta fase también se puede verificar que responsabilidad es la más apta para cada

integrante del equipo.

Lo más importante en esta fase es poder llegar a entender y uno de los objetivos que se

plantean, así cada integrante del equipo, debe trabajar y llegar a cumplir tanto los objetivos

del equipo, como los del producto, y entre los demás planteados.

A continuación en esta fase se detallan:

• Objetivos de equipo

• Objetivos como miembros del equipo

• Objetivos del producto

• Manejo de estándares

Para conocer los objetivos, véase el anexo TSP ciclo 1 fase de lanzamiento.

Todas las formas relacionadas con esta fase se las puede ver en el anexo TSP.


PARA MICROEMPRESAS


4.1.2. Fase de Estrategia

En la Fase de Estrategia planeamos todos los detalles y hacemos estimaciones sobre las

líneas de código y el tiempo que nos tomará realizar cada módulo del ciclo. Aquí es donde

definimos el diseño conceptual, el tiempo de desarrollo de este mismo, entre otras cosas.

Gracias a esta fase el equipo de trabajo obtiene una apreciación mejor acerca del producto

que se va a realizar, así de esta forma se evitan riesgos que afectarán al correcto desarrollo

del sistema.

Además podremos definir o administrar los riesgos que se podrían o no concebir durante

los demás procesos o en forma general del proyecto.

Criterios de Estrategia

1º. Ciclo

• Se desarrollará el Ingreso al Sistema, el cual manejará la validación de usuario y

contraseña y la salida del sistema.

• Se desarrollará la administración de Perfiles en la cual se podrárealizar las acciones

de crear y actualizar.

• Se desarrollará la administración de Usuarios en la cual se podrá realizar las

acciones de crear y actualizar.

• Se desarrollará la administración de Clientes en la cual se podrá realizar las


• Se desarrollará la administración de Productos en la cual se podrá realizar las

acciones de ingresar y actualizar.

• Se desarrollará la administración de Proveedores en la cual se podrá realizar las


• Se desarrollará la administración de Empresas en la cual se podrá realizar las


• Se desarrollará la administración de Unidades de Medida en la cual se podrá

realizar las acciones de crear y actualizar.

• Se desarrollará la administración de Tipos de Pago en la cual se podrá realizar las



PARA MICROEMPRESAS


2º. Ciclo

• Se automatizará los procesos de Insertar Inventario.

• Se automatizará los procesos de Insertar Datos de Autorización.

• Se automatizará los procesos de Facturación.

• Se generarán reportes para: Clientes, Productos, Proveedores, Facturas y Ventas

por Cliente.

Para conocer los documentos de configuración y el proceso de control de configuración,

véase el anexo TSP ciclo 1 fase de estrategia.


4.1.3. Fase de Planeación

En esta base estableceremos toda la planificación para el desarrollo del proyecto, ya que

así podremos determinar el tiempo estimado que tomará realizar las diferentes actividades.

Balancear las actividades a realizarse de manera equitativa permite evitar sobrecargas a los

miembros de equipo, de esta manera podemos hacer que cada integrante cumpla con sus

tareas a tiempo.

Distribución de Módulos.

• Diego Peñafiel: Ingreso al Sistema.

• Diego Peñafiel: Administración de Perfiles.

• Diego Peñafiel: Administración de Usuarios.

• Diego Peñafiel: Administración de Empresas.

• Carlos Sánchez: Administración de Unidades de Medida.

• Carlos Sánchez: Administración de Tipos de Pago.

• Carlos Sánchez: Administración de Clientes

• Carlos Sánchez: Administración de Productos

• Carlos Sánchez: Administración de Proveedores.



PARA MICROEMPRESAS


4.1.4. Fase de Requerimientos

En esta fase se define los requerimientos, su importancia y sus características los cuales se

define formalmente en la Especificación de Requerimientos de Software (ERS). El

documento que tiene una descripción clara del producto, sus funcionalidades y la forma de

evaluar al tener terminado el producto.

Antes de generar el documento se debe revisar las necesidades del cliente. Adicionalmente

se realizará preguntas acerca de las funcionalidades del producto, las mismas que sirven

para conocer si se necesita más información acerca de las funcionalidades del producto. En

este proceso se llega a un acuerdo acerca de lo que se va a construir por lo cual es

importante que se todos los integrantes del equipo participen en esta etapa.

A menudo se presentan cambios en los requerimientos ya que los clientes no tienen muy

claras sus necesidades hasta tener el producto por lo cual en el desarrollo del producto los

usuarios presentan nuevas funcionalidades y características.

Definición General del sistema

El punto de venta en línea es el servicio que permite agilitar y facilitar el manejo de

administraciones y procesos.

Este sistema de punto de venta permitirá la administración de:

• Clientes

• Productos

• Proveedores

• Perfiles

• Usuarios

• Tipos de Pago

• Unidades de Medida

• Empresas


PARA MICROEMPRESAS


Y el proceso de:

• Facturación

• Insertar Inventario

• Insertar Datos de Autorización

• Reportes

Daremos por concluido el proyecto cuando el sistema de punto de venta esté en su total

funcionamiento, liberado y listo para ser aplicado en cualquier micro empresa del Ecuador.

Información del Equipo

Rol Integrante Funcionalidad

Líder:

Diego Peñafiel

Diego

Peñafiel • Ingreso al Sistema

• Administración Perfiles

Administrador de Desarrollo:

Diego Peñafiel

Diego

Peñafiel • Administración Usuarios

• Administración de Empresas.

Administrador de Planeación:

Carlos Sánchez

Carlos

Sánchez • Administración Clientes

• Administración Productos

Administrador de Calidad y

Configuración:

Carlos Sánchez

Carlos

Sánchez

• Administración Proveedores

• Administración de Unidades de

Medida

• Administración de Tipos de Pago Tabla 4-1: Información del Equipo. [A], Mayo - 2012

Requerimientos funcionales

Los requerimientos funcionales nos permiten tener una vista de que es lo que se quiere

realizar y quienes intervienen en el sistema.


PARA MICROEMPRESAS


Diagrama General (Nivel 0)

Figura 4-1: Diagrama general. [A], Mayo - 2012

Diagramas de casos de uso detallados

A continuación veremos el detalle de los casos de uso del diagrama general


PARA MICROEMPRESAS


F0: Ingresar al sistema

Figura 4-2: F0: Ingreso al sistema. [A], Mayo – 2012.

F0.1: Validar Usuario y Contraseña

Figura 4-3: F0.1: Validar Usuario y Contraseña. [A], Mayo - 2012

Actores: SuperAdmin, Administrador, Usuario.

Descripción: En esta opción se realiza una validación de usuario y contraseña en el

sistema.

Flujo Principal:

1. El actor ingresa usuario y contraseña.

2. El actor selecciona ingresar.


PARA MICROEMPRESAS


3. El sistema valida usuario y contraseña (E1, E2).

4. El sistema muestra la página principal.

Excepciones:

E1. Error a conexión de BDD.

E2. Error al validar usuario y contraseña.

El resto de casos de uso y sus respectivas formas las podemos encontrar en el anexo TSP.

Diagramas de clases

Figura 4-4: Diagramas de Clases. [A], Mayo – 2012.

Otros Requerimientos

Estación PoS

• Dispositivo con Conexión a impresora.

• Navegador Web que soporte Javascript.

• Conexión a internet.

• Programa que permita leer PDFs.

Servidor


PARA MICROEMPRESAS


• Soporte de PHP

• Soporte de MYSQL

Restricciones de diseño e implementación

Lenguaje de Programación

• PHP 5.2 o superior

Base de Datos

• MYSQL

Requerimientos Especiales (Requerimientos No Funcionales)

RNF1. Respaldos de BDD

RNF2. Disponibilidad 24/7

RNF3. Seguridad

RNF4. Mantenimiento

RNF5. Soporte

Prototipo de la interface

Figura 4-5: Prototipo de la interface Login. [A], Mayo - 2012

Para visualizar el resto de los prototipos de interface véase anexo TSP Fase

Requerimientos.


PARA MICROEMPRESAS


Sistema de pruebas del sistema

Caso de Prueba: F0. Ingresar al sistema

Casos de Uso Entradas Resultados Esperados

F0 Ingresar a la página Se muestra la página de inicio de sesión.

F0.1

Ingreso de Datos

Correctos

Incorrectos

Despliega página principal.

Mensaje de error usuario o contraseña incorrecta.

F0.2 Salir (Cerrar Sesión) Sale de la sesión.

Tabla 4-2: Sistema de pruebas – Ingresar al sistema. [A], Mayo - 2012

Para visualizar el resto del sistema de pruebas del sistema véase anexo TSP Fase

Requerimientos

4.1.5. Fase de Diseño

Esta fase es la más importante ya que mediante esta vamos a ver cómo va a estar

funcionando nuestro sistema.

Aquí se desarrolla el SDS, documento con el cual podemos ver y comprender al sistema de

una mejor manera, desde un punto de vista de alto nivel.

En esta fase también vamos a tratar el diseño en equipos, el cual suele ser complejo ya que

no se sabe quién diseñará que parte o como se unirán las partes, entre otras.

También se desarrollarán los estándares de diseño del producto, así todos podremos tener

claro cómo será el producto, como serán las clases y métodos de cada parte de este.

Estructura del producto

¿Qué es Documento de Especificación de Diseño de Software (DSD)?

Es el artefacto generado más importante en la fase de diseño de TSP. En él se documenta el

diseño detallado que será de gran utilidad en la fase de implementación el mismo que se

enfoca en producir modelos para guiar el diseño del producto en donde varios ingenieros


PARA MICROEMPRESAS


la puedan utilizar de manera individual, mediante la utilización de diagramas que permitan

tener una visión clara de lo que se pretende realizar. También se definen escenarios en los

cuales se realizarán las funcionalidades del producto y se especifica la lógica y la

estructura del programa principal.

Diseño Arquitectónico

Es un estilo o forma de programación, su objetivo primordial es separar la programación

en tres capas:

Capa de presentación.

Capa de negocio.

Capa de datos.

Una de las ventajas de trabajar con esta arquitectura es que se puede distribuir l el trabajo y

cada capa está abstraída (oculta o independiente) del resto de niveles, de modo que basta

con conocer el API (métodos que pueden ser usados por otras capas) que existe entre cada

nivel.

Diagrama de paquetes

Figura 4-6: Diagrama de Paquetes TPL. [A], Mayo – 2012.


PARA MICROEMPRESAS


Para visualizar el resto de los diagramas de paquetes véase anexo TSP Fase Diseño.

Diagramas de clases

Figura 4-7: Diagrama de clase usuario. [A], Mayo – 2012.

Para visualizar el resto de los diagramas de clases véase anexo TSP Fase Diseño.


PARA MICROEMPRESAS


Diagramas de secuencia

F0 Ingresar Sistema

F0.1 Ingresar

Figura 4-8: Diagrama de secuencia Ingresar Sistema. [A], Mayo - 2012

Para visualizar el resto de los diagramas de secuencia véase anexo TSP Fase Diseño.

Plan de pruebas de integración

Las pruebas de integración se llevan a cabo durante la construcción del sistema, involucran

a un número creciente de módulos y terminan probando el sistema como conjunto.

Estas pruebas se pueden plantear desde un punto de vista estructural o funcional.

Las pruebas estructurales de integración son similares a las pruebas de caja blanca; pero

trabajan a un nivel conceptual superior. En lugar de referirnos a sentencias del lenguaje,

nos referiremos a llamadas entre módulos. Se trata pues de identificar todos los posibles

esquemas de llamadas y ejercitarlos para lograr una buena cobertura de segmentos o de

ramas.

Las pruebas funcionales de integración son similares a las pruebas de caja negra. Aquí

trataremos de encontrar fallos en la respuesta de un módulo cuando su operación depende

de los servicios prestados por otro(s) módulo(s). Según nos vamos acercando al sistema

total, estas pruebas se van basando más y más en la especificación de requisitos del

usuario.


PARA MICROEMPRESAS


Las pruebas finales de integración cubren todo el sistema y pretenden cubrir plenamente la

especificación de requisitos del usuario.

En todas estas pruebas funcionales se siguen utilizando las técnicas de partición en clases

de equivalencia y análisis de casos límite.

Integración por Dependencia de Clase

Aquí se comienza el ensamblaje del sistema probando aquellas clases, llamadas

independientes, que usan muy poca o ninguna otra clase del sistema; después de que las

clases independientes han sido probadas se continúa con la próxima etapa de clases, las

cuales usan a las independientes. Esta secuencia de pruebas por capas de clases

dependientes continúa hasta que el sistema entero se construye.

PLAN DE PRUEBAS DE INTEGRACION APLICADA AL PROYECTO

Las diferentes administraciones del proyecto se realizarán por cada miembro del equipo

por lo que la integración por dependencia es la que se va a utilizar, con este plan de

pruebas podemos identificar que clases son las que dependen de otras, para corregir los

errores y defectos con el plan de pruebas de integración.

El plan de pruebas de integración se va a realizar de la siguiente manera:

1. Plan de Pruebas de Integración de todas las clases TPL.

2. Plan de Pruebas de Integración de todas las clases F.

3. Plan de Pruebas de Integración de todas las clases P

4. Plan de Pruebas del Sistema.

ESTÁNDARES DE DISEÑO

Mensajes de error

Establecer formatos de estándares y procedimientos para mensajes de error. Los mensajes

deben ser entendibles y reutilizables, todo error producido por fallas de la base de datos

debe ser visualizado por pantalla a través de mensajes de error y los errores de ingreso de

datos generados por el usuario del mismo modo serán notificados a través de ventanas de

advertencia, informando detalladamente el error producido.


PARA MICROEMPRESAS


Formatos de Interface

Definir el formato y contenido de las interfaces de los componentes, las búsquedas por

parámetro, errores de código u otras condiciones.

En caso de eliminar o actualizar el sistema visualizará por pantalla una ventana de

confirmación por motivos de seguridad.

Estándares generales

• Las clases deben ser privadas.

• Los nombres de las clases deben empezar con letra mayúscula indicando claramente

que clase es.

• Los nombres de los atributos y métodos deben describir claramente al mismo para que

sea identificable fácilmente por cualquier integrante del equipo.

• No debe existir más de una sentencia por cada línea de código.

• Se debe comentar al inicio de cada clase sobre la funcionalidad de la misma y

observaciones pertinentes para facilitar el entendimiento de la misma a cualquier

integrante del equipo.

• Las sentencias de manipulación propias de la base de datos deben estar escritas en

mayúsculas.

4.1.6. Fase de Implementación

Antes de proceder con esta etapa es necesario tener un diseño a de alto nivel completo

y detallado en donde es necesario subdividir al sistema en varios subsistemas que

permitan reducir la complejidad del mismo, se realiza este procedimiento hasta tener el

mínimo nivel posible.

Estándares de implementación

Todos los miembros del equipo deben definir y estar de acuerdo con los estándares y el

administrador de configuración debe guiar al equipo en esta tarea. Los temas a revisar

son: nombres de interfaces, rutinas de re uso.

• Codificación: Facilita la inspección y el compartimiento de código.


PARA MICROEMPRESAS


publicstaticfunctioncargarTodosClientes($db, $id_emp, $desde, $hasta) {

$sql = "SELECT `nombre_cln`, àpellido_cln`, `cedula_cln`, `direccion_cln`,

`telefono_cln`, `fecha_ingreso_cln`, èstado_cln`

FROM `pos_cliente`

WHERE ìd_emp`='" .$id_emp . "'

AND `fecha_ingreso_cln` BETWEEN '" .$desde . "' AND '" . $hasta . "';";

$result = $db->getAll($sql);

if ($result)

return $result;

else

return false;

}

}

• Tamaño: Es necesario detallar líneas de código y el compartimiento de código.

• Defectos: Se debe clasificar defectos para encontrar errores en el diseño y

codificación.

Revisión de defectos: Para prevenir defectos es necesario aprender el lenguaje, utilizar las

mejores herramientas, los mejores métodos y detectar los efectos recurrentes.

Ejemplo de código Cliente.class.php:

Figura 4-9: Ejemplo de Código. [A], Mayo - 2012

4.1.7. Fase de Pruebas

En esta fase, se determina la funcionalidad del producto de software utilizando los casos de

pruebas vistos en la fase de requerimientos. El objetivo final de esta fase consiste

básicamente en evaluar el producto, una vez que hayamos llegado a esta fase todos los

defectos debieron haber sido reparados. En el caso de existir errores en las pruebas, el

producto no puede ser cambiado en esta fase y se deberá reparar en los ciclos siguientes en

las respectivas fases de implementación.

Las formas se encuentran en el anexo TSP.


PARA MICROEMPRESAS


4.1.8. Fase de Postmortem

En esta fase se revisa el trabajo de todo el ciclo, se ve los puntos buenos, malos y todo lo que sucedió durante el transcurso del ciclo. Aquí se evalúa el trabajo de todo el ciclo, tanto como personal y como de equipo.

Esta fase es muy importante ya que para un proyecto de varios ciclos esta fase es la puerta para el siguiente ciclo, el cuál debería empezar a continuación.

El Post Mortem también nos sirve para mejorar la calidad de nuestro trabajo ya que en esta fase se determina las falencias y problemas que pudieron ocurrir pero así mismo se destaca los beneficios que aparecieron.

1. Nivel de Equipo

Diego Peñafiel

Criterio de qué es TSP

Lo Bueno:

TSPi es un modelo de desarrollo de software en equipo que debería ser usada en todo el mundo. Si se sigue fielmente el proceso que define TSPi se pude generar un producto de software superior, con la menor cantidad de defectos y generando patrones que permiten que los procesos comunes sean más fáciles de replicar.

Lo Malo:

El avance del trabajo en equipo depende directamente del trabajo conjunto de todos los miembros del equipo, si existen factores negativos que afecten el desempeño de un miembro del equipo eso puede acarrear algunos problemas dentro del desarrollo de software.

Lo Feo:

TSPi es un modelo de desarrollo que se ajusta a los componentes es decir, se impone una forma rígida de realizar las cosas sin analizar el comportamiento o la forma de pensar de los integrantes que conforman el equipo, y todos los integrantes tienen que acceder y limitarse a lo que TSPi dispone.

Criterio sobre el rol

Los roles que se desempeñó permitieron tener una visión más global de lo que es el TSPi ya que no solamente se tiene una mirada netamente de un solo rol, y más bien se puede tener una perspectiva con diferentes puntos de vista. Cada rol es importante y las cargas de trabajo están divididas de una manera equitativa.


PARA MICROEMPRESAS


Criterio sobre el equipo

Como en todo equipo de trabajo existen sus altas y bajas, pero lo más importante es denotar y utilizar siempre las cualidades de cada integrante a su máxima expresión, dejando problemas personales fuera y trabajando profesionalmente para que el proyecto sea termine a tiempo y con buena calidad.

Carlos Sánchez

Criterio de qué es TSP

Lo bueno

TSPi es una herramienta diferente ya que al momento de realizar proyectos en grupo se crean problemas de compatibilidad entre los intergantes y TSPi tiene formas de ayudar al equipo a sobrepasar este tipo de problemas.Para que un proyecto tenga éxito es necesario evaluar muchos factores y planearlos con anticipación y TSPi permite esta planeación.

Lo malo

TSPi es una herramienta poco flexible por lo cual se debe realizar cada fase con la menor cantidad de defectos posibles. Esto se realiza para evitar que una falla en una fase se replique en otras y en el proyecto final.

Lo feo

Al trabajar con TSPi se tiene la presión de realizar todas las fases evitando errores, y de ser necesario se repetirá una fase o documento las veces que sean necesarias.

Criterio sobre el rol

Los roles desempeñados me permitieron entender de mejor manera el funcionamiento del modelo TSPi, ya que no trabajé de una manera enfocada a un rol, y trabajé de una manera más amplia.

Criterio sobre el equipo

El equipo estuvo muy bien conformado ya que durante el primer ciclo no hemos tenido problemas graves solamente algunos leves. Todos desarrollamos nuestro trabajo de acuerdo a lo esperado por lo cual existió una ambiente de trabajo muy ameno y sobre todo de aprendizaje.


PARA MICROEMPRESAS


Fin del ciclo 1, para ver la documentación del ciclo 2 véase anexo TSP.


PARA MICROEMPRESAS


5. CAPITULO V: CONCLUSIONES Y RECOMENDACIONES

5.1. Conclusiones

1. Algunas microempresas del Ecuador, tienen un manejo desorganizado, de los

procesos de facturación y reportes; así mismo de las administraciones de: clientes,

inventario, usuarios y productos; que conllevan a problemas tales como: cruce de

productos, información errónea de gastos, inventarios fuera de orden, mal conteo

del dinero de caja chica, entre otros.

2. Para aquellas microempresas Ecuatorianas que no tienen la capacidad económica

de adquirir un sistema propietario que realice las administraciones de clientes,

inventario, usuarios y productos; y los procesos de procesos de facturación,

reportes, está a disposición el sistema PoS – Ecuador.

3. Al tener en cuenta que el internet es más accesible cada día en el Ecuador, hemos

decidido ofrecer y difundir esta herramienta a través del internet para aquellas

microempresas que estén en capacidad de utilizarlo.

4. La computación en la nube es un concepto que está en auge actualmente, el cual

nos permite despreocuparnos del alojamiento local de aplicaciones y tener la

facilidad de compartir dicha información a través del internet.

5. La automatización de los procesos crea un aumento en la productividad, y facilita el

trabajo de todos los implicados. El ahorro de tiempo y la reducción del factor

humano en procesos repetitivos, permite que la microempresa reduzca errores y

optimice sus labores.


PARA MICROEMPRESAS


6. La computación en la nube, permite tanto acceder al sistema PoS Ecuador como

hacer uso de todos los beneficios del sistema siempre y cuando se tenga acceso a

internet.

5.2. Recomendaciones

1. Se sugiere a las microempresas que no dispongan de ningún tipo de sistema punto

de venta y que se acoplen a este servicio de puntos de venta, utilizar el sistema PoS

- Ecuador.

2. Se recomienda valorar las aplicaciones en la nube que puedan solventar las

necesidades de la microempresas.

3. Establecer un ambiente adecuado para la ejecución del sistema en la nube,

servidores confiables, robustos, con factibilidad de crecimiento y soporte de tráfico

de datos.

4. Se recomienda tener una conexión a internet dedicada y con óptima calidad de

servicios, pues de otra manera la microempresa no contará con un buen tiempo de

respuesta.

5. Es recomendable acceder al sistema desde equipos portátiles, sean teléfonos

inteligentes, computadores tableta o computadores portátiles, siempre y cuando

tengan acceso a Internet, para utilizar el servicio proporcionado por PoS - Ecuador.


PARA MICROEMPRESAS


6. Es imperativo que la escuela de sistemas proporcione infraestructura necesaria para

poner en operación el PoS Ecuador, y futuros proyectos relacionados con este

estudio, y así apoyar el desarrollo profesional de los estudiantes.

7. La escuela de sistemas, a través de los estudiantes autores del presente estudio,

debe brindar charlas de capacitación a otros estudiantes de diversas facultades

sobre conocimiento básico del PoS – Ecuador.

8. La Pontificia Universidad Católica del Ecuador debe implementar planes de

difusión de reciclaje de tecnología, haciendo público el servicio PoS – Ecuador y

así reciclar equipos de punto de venta.


PARA MICROEMPRESAS


Glosario de Términos.-

• A

AWS: Amazon Web Service comenzó en el año 2006 a proporcionar servicios de

infraestructura TI para empresas en formas de servicios web.

• B

BY: Atribution.

• C

CASE: Computer-aided software engineering.

CC: Creative Commons.

• E

EULA: End-User license agreement.

• F

FSF: Free Software Fundation es una compañía sin fines de lucro con la misión de

promover las libertades de usuario y defender los derechos de todos los usuarios de

software libre.

• G

GPL: General Public License.

GUI: Graphical user interface

• I

IaaS: Infrastructure as a Service.

IDE: Integrated development environment.

ICASE: Integrated Computer-Aided Software Engineering.

IPSE: Integrated Project Support Environment

• L

LGPL: Lesser General Publication License.

• N


PARA MICROEMPRESAS


NC: No comercial.

ND: No derivate Works.

• O

OSI: Open Source Initiative.

OEM: Original Equipment Manufacturer.

• P

PoS: Point of Sale o Punto de venta.

PaaS: Platform as a service.

PC: Personal Computer.

PHP: Hypertext Preprocessor.

PSP: Personal Software Process.

PVP: Precio de venta al público.

• R

RAM: Random access memory.

• S

SaaS: Software as a service.

SA: Share alike.

SRS: Software Requirements Specification.

SDS: Software Design Specification.

Smartphones: Teléfonos celulares inteligentes con gran capacidad de procesamiento y memoria

• T

TSPi: Introductory Team Software Process


PARA MICROEMPRESAS


Bibliografía.-

[A]. Disertación, Diseño y Construcción de un Punto de Venta Gratuito, en Línea,

para Microempresas, Peñafiel Diego – Sánchez Carlos, PUCE, 2012.

[B]. HUMPHREY Watts, "TSP: Leading a Development Team", Addison-Wesley,

septiembre 2005.

[C]. HUMPHREY Watts, "TSP, Coaching Development Teams", Addison-Wesley,

abril 2006

[D]. HUMPHREY Watts, "Team Software Process: Body of Knowledge", julio 2010,

Technical Report.

[1]. http://www.gnu.org/philosophy/categories.es.html#OpenSource, febrero 2012

[2]. http://en.wikipedia.org/wiki/Comparison_of_free_software_licenses, febrero 2012

[3]. http://www.maestrosdelweb.com/editorial/cloud-computing-nueva-era-de-

desarrollo/, febrero 2012

[4]. http://en.wikipedia.org/wiki/Cloud_computing, febrero 2012

[5]. http://es.wikipedia.org/wiki/Computaci%C3%B3n_en_nube, febrero 2012

[6]. http://www.wikinvest.com/concept/Cloud_Computing, febrero 2012

[7]. http://es.wikipedia.org/wiki/Licencia_de_software, febrero 2012

[8]. http://www.monografias.com/trabajos55/licencias-de-software/licencias-de-

software.shtml, febrero 2012

[9]. http://creativecommons.org/licenses/?lang=es_ES, febrero 2012

[10]. http://en.wikipedia.org/wiki/Creative_Commons_licenses, febrero 2012

[11]. http://www.opensource.org/licenses/alphabetical, febrero 2012

[12]. http://hispalinux.es/LicenciasLibres, febrero 2012

[13]. http://www.monografias.com/trabajos55/licencias-de-software/licencias-de-

software2.shtml, febrero 2012

[14]. http://opensource.org/licenses/, febrero 2012

[15]. http://www.gnu.org/licenses/license-list.html, febrero 2012

[16]. http://www.informatica.us.es/~ramon/articulos/LicenciasSoftware.pdf, febrero

2012

[17]. http://www.informatica-hoy.com.ar/software-libre-gnu/Tipos-de-licencia-de-

Software.php#opinar, febrero 2012

[18]. http://en.wikipedia.org/wiki/Retail_software, febrero 2012

http://www.maestrosdelweb.com/editorial/cloud-computing-nueva-era-de-desarrollo/

http://www.maestrosdelweb.com/editorial/cloud-computing-nueva-era-de-desarrollo/

http://en.wikipedia.org/wiki/Cloud_computing

http://es.wikipedia.org/wiki/Computaci%C3%B3n_en_nube

http://www.wikinvest.com/concept/Cloud_Computing

http://es.wikipedia.org/wiki/Licencia_de_software

http://www.monografias.com/trabajos55/licencias-de-software/licencias-de-software.shtml

http://www.monografias.com/trabajos55/licencias-de-software/licencias-de-software.shtml

http://www.monografias.com/trabajos55/licencias-de-software/licencias-de-software2.shtml

http://www.monografias.com/trabajos55/licencias-de-software/licencias-de-software2.shtml

http://opensource.org/licenses/

http://www.gnu.org/licenses/license-list.html

http://en.wikipedia.org/wiki/Retail_software


PARA MICROEMPRESAS


[19]. http://es.scribd.com/JocTK/d/58952855/57-Licencias-propietarias#, febrero 2012

[20]. http://es.wikibooks.org/wiki/Fundamentos_de_programaci%C3%B3n/Herramient

as_de_desarrollo, febrero 2012

[21]. http://es.wikipedia.org/wiki/Depurador, febrero 2012

[22]. http://es.wikipedia.org/wiki/Interfaz_gr%C3%A1fica_de_usuario, febrero 2012

[23]. http://es.scribd.com/doc/3062020/Capitulo-I-HERRAMIENTAS-CASE, febrero

2012

[24]. http://www.alipso.com/monografias/desarrollo_de_sistemas_de_informacion/,

febrero 2012

[25]. http://en.wikipedia.org/wiki/Computer-aided_software_engineering#cite_note-5,

febrero 2012

[26]. http://www.ongei.gob.pe/publica/metodologias/Lib5083/cap2011.HTM, febrero

2012

[27]. http://en.wikipedia.org/wiki/Software_framework, febrero 2012

[28]. http://americati.com/blog/?p=105, febrero 2012

[29]. http://www.investopedia.com/terms/p/point-of-sale.asp#axzz1lGyW7gg4

[30]. http://www.pcmag.com/encyclopedia_term/0,2542,t=point+of+sale&i=4944

4,00.asp

[31]. http://es.wikipedia.org/wiki/Establecimiento_comercial

[32]. http://whatis.techtarget.com/definition/0,,sid9_gci774854,00.html

[33]. http://www.entrepreneur.com/encyclopedia/term/82360.html

[34]. http://es.wikipedia.org/wiki/Terminal_punto_de_venta

[35]. http://en.wikipedia.org/wiki/Point_of_sale#Hardware_Stores.2C_Building_

Supply.2C_Lumber_Yards

[36]. http://www.phppointofsale.com/

[37]. http://www.infinitycloudpos.com/cloud-retail-pos-software/#7

http://es.scribd.com/JocTK/d/58952855/57-Licencias-propietarias

http://es.wikibooks.org/wiki/Fundamentos_de_programaci%C3%B3n/Herramientas_de_desarrollo

http://es.wikibooks.org/wiki/Fundamentos_de_programaci%C3%B3n/Herramientas_de_desarrollo

http://es.wikipedia.org/wiki/Depurador

http://es.wikipedia.org/wiki/Interfaz_gr%C3%A1fica_de_usuario

http://es.scribd.com/doc/3062020/Capitulo-I-HERRAMIENTAS-CASE

http://www.alipso.com/monografias/desarrollo_de_sistemas_de_informacion/

http://en.wikipedia.org/wiki/Computer-aided_software_engineering#cite_note-5

http://www.ongei.gob.pe/publica/metodologias/Lib5083/cap2011.HTM


PARA MICROEMPRESAS

Peñafiel Diego – Carlos Sánchez

Contenido 1. CAPÍTULO I: MARCO TEÓRICO .............................................................................. 1

1.1. Computación en Nube ............................................................................................ 1

1.1.1. Ventajas ........................................................................................................... 3

1.1.2. Desventajas ...................................................................................................... 4

1.1.3. Capas de la computación en nube ................................................................... 5

1.2. Licencias de software .............................................................................................. 6

1.2.1. Tipos de Licencia de Software ........................................................................ 7

1.3. Licencias Libres y Open Source ............................................................................. 7

1.3.1. GPL .................................................................................................................. 9

1.3.2. LGPL ............................................................................................................... 9

1.3.3. CreativeCommons ......................................................................................... 10

1.4. Licencias Propietarias ........................................................................................... 11

1.4.1. OEM: ............................................................................................................. 12

1.4.2. Retail: ............................................................................................................ 12

1.4.3. Licencias por Volúmenes .............................................................................. 12

1.4.4. EULA ............................................................................................................ 12

1.5. Herramientas de desarrollo ................................................................................... 13

1.5.1. IDE ................................................................................................................ 14

1.5.2. Herramientas CASE ...................................................................................... 14

1.5.3. Frameworks ................................................................................................... 16

2. CAPÍTULO II: TEAM SOFTWARE PROCESS ....................................................... 18

2.1. Visión general de TSP .......................................................................................... 18

2.1.1. Principios de TSPi ......................................................................................... 18

2.1.2. El diseño de TSPi .......................................................................................... 19

2.1.3. Estructura de TSPi: ........................................................................................ 19


PARA MICROEMPRESAS


2.1.4. Estrategia de desarrollo cíclica ...................................................................... 20

2.1.5. Equipos de TSPi ............................................................................................ 21

2.1.6. Objetivos de Equipo ...................................................................................... 21

2.1.7. Roles de Equipo ............................................................................................. 21

2.1.8. Planeación de Equipo .................................................................................... 22

2.2. Fases de TSPi ........................................................................................................ 22

2.2.1. Fase de lanzamiento TSPi ............................................................................. 22

2.2.2. Fase de estrategia TSPi .................................................................................. 24

2.2.3. Fase de Planeación TSPi ............................................................................... 25

2.2.4. Fase de requerimientos TSPi ......................................................................... 27

2.2.5. Fase de diseño TSPi ....................................................................................... 29

2.2.6. Fase de implementación TSPi ....................................................................... 31

2.2.7. Fase de pruebas TSPi ..................................................................................... 32

2.2.8. Fase PostmortemTSPi ................................................................................... 33

3. CAPÍTULO III: PUNTOS DE VENTA EN EL ENTORNO ECUATORIANO ........ 35

3.1. Punto de venta ....................................................................................................... 35

3.2. Punto de venta en línea ......................................................................................... 35

3.3. Características importantes al adquirir un PoS en línea........................................ 36

3.4. Requerimientos básicos para un punto de venta ................................................... 37

3.4.1. Software ......................................................................................................... 37

3.4.2. Hardware ....................................................................................................... 38

3.5. Razones para usar un PoS en Línea ...................................................................... 39

3.6. Entorno Ecuatoriano ............................................................................................. 40

3.6.1. Microempresa ................................................................................................ 41

3.6.2. Relación laboral ............................................................................................. 42

3.6.3. Impuesto al valor agregado............................................................................ 42


PARA MICROEMPRESAS


3.6.4. Impuesto a los consumos especiales .............................................................. 44

4. CAPÍTULO IV: DESARROLLO ................................................................................ 47

4.1. Ciclo 1 ................................................................................................................... 47

4.1.1. Fase de Lanzamiento ..................................................................................... 47

4.1.2. Fase de Estrategia .......................................................................................... 48

4.1.3. Fase de Planeación......................................................................................... 49

4.1.4. Fase de Requerimientos ................................................................................. 50

4.1.5. Fase de Diseño ............................................................................................... 56

4.1.6. Fase de Implementación ................................................................................ 61

4.1.7. Fase de Pruebas ............................................................................................. 62

4.1.8. Fase de Postmortem ....................................................................................... 63

5. CAPITULO V: CONCLUSIONES Y RECOMENDACIONES ................................ 66

5.1. Conclusiones ......................................................................................................... 66

5.2. Recomendaciones ................................................................................................. 67

Tablas

Tabla 1-1: Licencias Libres/Open Source más conocidas. [A] Basado en [2], Mayo - 2012.

............................................................................................................................................... 8

Tabla 1-2: Licencias Libres/Open Source más conocidas. [A] Basado en [2], Mayo - 2012.

............................................................................................................................................... 9

Tabla 3-1: Productos de Uso Diario. [A], Mayo – 2012. .................................................... 44

Tabla 3-2: Vehículos de transporte terrestre hasta 3.5 toneladas de carga. [A], Mayo –

2012. .................................................................................................................................... 45

Tabla 3-3: Vehículos híbridos o eléctricos hasta 3.5 toneladas de carga. [A], Mayo - 2012.

............................................................................................................................................. 45

Tabla 3-4: Servicios. [A], Mayo – 2012. ............................................................................. 46


PARA MICROEMPRESAS


Tabla 3-5: Tarifa Específica. [A], Mayo - 2012. ................................................................. 46

Tabla 4-1: Información del Equipo. [A], Mayo - 2012 ....................................................... 51

Tabla 4-2: Sistema de pruebas – Ingresar al sistema. [A], Mayo - 2012............................. 56

Figuras

Figura 1-1: Esquema de Conexión entre el Internet y los dispositivos electrónicos. [A],

Mayo - 2012. ......................................................................................................................... 2

Figura 1-2: Esquema de Conexión entre el Internet y los dispositivos electrónicos. [A],

Mayo - 2012. ......................................................................................................................... 5

Figura 1-3: Tipos de Licencia de Software. [A] Basado en [1], Mayo - 2012. ..................... 7

Figura 2-1: Estructura y Flujo de TSPi. [A], Mayo - 2012. ................................................ 20

Figura 2-2: Pasos de la Fase de Planeación. [A], Mayo - 2012. .......................................... 27

Figura 4-1: Diagrama general. [A], Mayo - 2012................................................................ 52

Figura 4-2: F0: Ingreso al sistema. [A], Mayo – 2012. ....................................................... 53

Figura 4-3: F0.1: Validar Usuario y Contraseña. [A], Mayo - 2012 ................................... 53

Figura 4-4: Diagramas de Clases. [A], Mayo – 2012. ......................................................... 54

Figura 4-5: Prototipo de la interface Login. [A], Mayo - 2012 ........................................... 55

Figura 4-6: Diagrama de Paquetes TPL. [A], Mayo – 2012................................................ 57

Figura 4-7: Diagrama de clase usuario. [A], Mayo – 2012. ................................................ 58

Figura 4-8: Diagrama de secuencia Ingresar Sistema. [A], Mayo - 2012 ........................... 59

Figura 4-9: Ejemplo de Código. [A], Mayo - 2012 ............................................................. 62

Leyenda

[A]: Figura o tabla realizado por el o los autores especificados en el literal correspondiente

en la bibliografía.

[A] Basado en [1]: Figura o tabla realizada por el o los autores especificados en el literal

correspondiente en la bibliografía basados en una tabla o figura pre existente especificados

en el literal correspondiente en la bibliografía. Ver Bibliografía.


PARA MICROEMPRESAS


AGRADECIMIENTO

Carlos D. Sánchez M.

Agradezco sobre todo a Dios, por haberme permitido culminar mis estudios, el

desarrollo de mi tesis; y durante todo el transcurso de mis estudios, este trabajo y mi

carrera de manera exitosa. También agradezco a mis padres por haberme inculcado los

valores y el coraje necesario para poder continuar con mis estudios y poder lograr llegar al

final de estos. Gracias a ellos y a sus esfuerzos, he logrado llegar acá, y gracias a eso podre

continuar y conseguir un futuro mejor.

Agradezco a cada uno de los Ingenieros de la Facultad de Ingeniería, aquellos que

estuvieron durante mis estudios, y pudieron inculcarme y educarme de la mejor manera

posible para la adquisición de conocimientos durante el transcurso de la carrera.

Agradezco al Ingeniero Javier Cóndor, director de tesis, quien ha logrado y facilitado el

desarrollo de esta misma, y siempre ha estado dispuesto a resolver nuestras dudas e

inquietudes. Agradezco a mi compañero y amigo Diego Peñafiel, por haberme colaborado

durante toda mi carrera, y por poder culminar este proyecto de la mejor manera.

Diego F. Peñafiel C.

En primera instancia quiero agradecer a mis padres, que con su apoyo y amor

incondicional me han ayudado para seguir adelante y no detenerme ante los problemas que

se generasen durante todos mis estudios y durante el desarrollo de esta disertación. A mis

hermanos por ser fuente de conocimiento tanto, técnico como jurídico, que me ha

permitido crecer como profesional, a la Pontificia Universidad Católica del Ecuador por

impartirme los conocimientos necesarios para poder desarrollar este proyecto de

disertación, al Ingeniero Javier Cóndor, director de tesis, quien diariamente imparte

conocimiento a los futuros profesionales del Ecuador, y por último pero no menos

importante, a mi compañero y amigo Carlos Sánchez con quien hemos podido completar

este proyecto sin importar los momentos difíciles.


PARA MICROEMPRESAS


DEDICATORIA

Carlos D. Sánchez M.

Dedico este trabajo, a mi familia, la cual fue paciente y siempre estuvo ahí para mostrarme e indicarme el camino correcto a seguir. Y que sé que siempre estarán ahí para mí.

Diego F. Peñafiel C.

Dedico este proyecto a mis padres, que no solo han sido mis primeros maestros,

pero más importante son mis amigos que nunca me han fallado y siempre me han apoyado.

Documents

DISEÑO Y CONSTRUCCIÓN DE UN PUNTO DE VENTA GRATUITO, …