UNIVERSIDAD PUBLICA DE EL ALTO
INGENIERIA DE SISTEMAS
ANALISIS Y DISEÑO II
SISTEMA DE VENTAS DE CELULARES
MAYHOSVEL
UNIVERSITARIA:
- Huaqui Quispe Karen Yhoselin
DOCENTE:
- Ing, WENDY SARMIENTO
Gestión: 2020
INDICE
Resumen ...................................................................................................................................4
CAPÍTULO II MARCO TEÓRICO ...........................................................................................5
2.1. Conceptos generales ......................................................................................................5
2.3. Ingeniería de software ....................................................................................................5
2.4. Método (ciclo de vida) ....................................................................................................6
2.5. Metodología ......................................................................................................................6
2.6. Características de la metodología ...............................................................................7
2.7.1. Análisis de Requisitos ............................................................................................7
2.7.2. Análisis y Diseño Preliminar .................................................................................8
2.7.3. Diseño .........................................................................................................................8
2.7.4. Implementación ........................................................................................................8
2.8. UML .....................................................................................................................................8
2.8.1. Tipos de diagramas UML ........................................................................................8
2.8.2. Diagramas estructurales.....................................................................................9
2.8.3. Diagramas de comportamiento .......................................................................10
2.8.4. Diagramas de interacción.: ..................................................................................10
2.9. Herramientas ..................................................................................................................11
2.9.1. HTML5: .....................................................................................................................11
2.9.2. CSS3: .........................................................................................................................11
2.9.3. POSTGRESQL: ........................................................................................................11
2.9.4 Lenguaje de Programación PHP:.........................................................................12
2.10. Pruebas ..........................................................................................................................12
2.10.1. Pruebas de Caja Negra .......................................................................................12
2.10.2. Pruebas de Caja Blanca.....................................................................................12
2.11. Métricas de calidad .....................................................................................................13
2.11. ISO 9126 .....................................................................................................................13
2.11.2 Confiabilidad ..........................................................................................................13
2.11.3. Usabilidad ..............................................................................................................14
2.11.4. Mantenimiento ......................................................................................................14
CAPÍTULO III MARCO APLICATIVO ..................................................................................14
3.1 Introducción .....................................................................................................................14
3.2 Arquitectura del Negocio ..............................................................................................14
3.3. Aplicar la metodología de acuerdo a cada fase .....................................................15
3.3.1 Revisión de los requisitos/ Análisis de Requisitos .........................................15
[Link]. modelo de dominio .........................................................................................15
2|P ági na
[Link]. Modelo de casos de uso ................................................................................16
[Link]. Prototipacion rápida .......................................................................................19
3.3.2. Análisis y Diseño Preliminar ...............................................................................19
[Link]. Diagrama de Robustez: .................................................................................19
3.3.3. Diseño .......................................................................................................................21
[Link]. Requerimientos ...............................................................................................21
[Link]. Implementación ...................................................................................................23
3|P ági na
Resumen
El presente proyecto se orienta al análisis y diseño de un sistema de venta de
celulares para el manejo de inventario de un negocio dedicado de la venta de
celulares el sistema MAYHOSVEL, fue desarrollado bajo el modelo iterativo, el
modelo permite crear en cada etapa un prototipo de mejorar con expectativas de
cumplir con lo requerido
La primera empresa en proveer servicio de telefonía en Bolivia fue TIGO, llamado
TELECEL en ese entonces, en el año [Link] ingreso al mercado en 1996 y
VIVA, NUEVATEL, en el año 2000, los servicios de telefonía y de valor agregado
son los más representativos del sector de las telecomunicaciones y generan el
mayor volumen de ingresos a las compañías.
Las características con las cuales surgen en los 80, con los denominados
ladrillos siendo estas de tecnología analógica. La segunda generación surge en
la década de 90 con celulares con tecnología digital, estos ya podían envía y
recibir mensajes de texto. Los de tercera generación estas se unen las
tecnologías anteriores con las nuevas ya presentan un chip e internet.
Por esa razón que la variedad de los celulares requiere un sistema de inventarios
para tener organizados la venta y los registros de stock de los celulares.
4|P ági na
CAPÍTULO II MARCO TEÓRICO
2.1. Conceptos generales
Celulares:
Definimos teléfono móvil o celular como un dispositivo electrónico de
comunicación, normalmente de diseño reducido y sugerente y basado en la
tecnología de ondas de radio (es decir, transmite por radiofrecuencia), que tiene
la misma funcionalidad que cualquier teléfono de línea fija. Su rasgo
característico principal es que se trata de un dispositivo portable e inalámbrico,
esto es, que la realización de llamadas no es dependiente de ningún terminal fijo
y que no requiere de ningún tipo de cableado para llevar a cabo la conexión a la
red telefónica.
Sistemas de ventas:
El sistema de ventas, se trata de una completa aplicación, para la gestión de
clientes, proveedores y productos, incluyendo la posibilidad de realizar el registro
de ventas de dichos productos y generar informes.
Sistemas de inventarios:
El sistema de inventario es uno de los aspectos de la administración que la micro
y pequeña empresa es muy pocas veces atendido, sin tenerse registros
fehacientes, un responsable, políticas o sistemas que le ayuden a esta fácil pero
tediosa tarea
La base de toda empresa comercial es la compra y venta de bienes o servicios;
de aquí la importancia del manejo del inventario por parte de la misma. Este
manejo contable permitirá a la empresa mantener el control oportunamente, así
como también conocer al final del período contable un estado confiable de la
situación económica de la empresa.
2.3. Ingeniería de software
La ingeniería de software es una disciplina que comprende todos los aspectos
de la producción del sistema desde las etapas iniciales de la especificación,
hasta el mantenimiento de éste después de que se utiliza. En esta definición,
existen dos frases clave [SOMMEERVILLE, 2005].
5|P ági na
Disciplina de la Ingeniería. Los ingenieros hacen que las cosas
funcionen. Aplican teorías, métodos y herramientas donde sean
convenientes, pero las utilizan de forma selectiva y siempre tratando de
descubrir soluciones a los problemas.
Todos los Aspectos de Producción de Software. La ingeniería del
software no sólo comprende los procesos técnicos del desarrollo, sino
también con actividades tales como la gestión de proyectos y el desarrollo
de herramientas, métodos y teorías para el apoyo a la producción.
El objetivo de la ingeniería de software es lograr productos de calidad (tanto en
su forma final como durante su elaboración), mediante un proceso apoyado por
métodos y herramientas.
En general los ingenieros de software adoptan un enfoque sistemático y
organizado en su trabajo, ya que es la forma más efectiva de producir software
de alta calidad. Sin embargo, aunque la ingeniería consiste en seleccionar el
método más apropiado para un conjunto de circunstancias, un enfoque más
informal y creativo de desarrollo podría ser efectivo en algunos casos. El
desarrollo informal es apropiado para el desarrollo de sistemas basados en Web,
los cuales requieren una mezcla de técnicas de software y de diseño gráfico.
2.4. Método (ciclo de vida)
Ciclos de vida de desarrollo de software utilizado
Iterativo e Incremental:
El ciclo de vida incremental consiste en desarrollar por partes el
producto de manera que puedas integrarlas funcionalmente.
Ciclo de vida Iterativo, en cada ciclo de iteración se revisa y mejora el
producto.
El desarrollo se organiza en series de mini-proyectos cortos, llamados
iteraciones.
2.5. Metodología
METODOLOGIA ICONIX: Es una metodología pesada-ligera de Desarrollo del
Software que se halla a medio camino entre RUP (Rational Unified Process) y
XP (eXtreme Programming), es una metodología simplificada en comparación a
6|P ági na
otras más tradicionales, la cual unifica un conjunto de métodos de orientación a
objetos con el objetivo de tener un control estricto sobre todo el ciclo de vida del
producto a realizar, cuenta con una secuencia de pasos que se deben seguir y
determina claramente las actividades a desarrollar en cada etapa del ciclo de
vida del proyecto que la utilice.
2.6. Características de la metodología
Características de la metodología ICONIX son:
Iterativo e Incremental: Ocurren varias iteraciones entre el desarrollo del
modelo del dominio y los casos de uso. El modelo estático es incremental
Trazabilidad: Es la capacidad de seguir una relación entre los diferentes
artefactos producidos, por lo que cada paso esta referenciado por algún
requisito.
Dinámica del UML: Ofrece un uso dinámico del UML, como los
diagramas de caso de uso, diagramas de secuencia y de colaboración.
2.7. Fases de la metodología ICONIX
2.7.1. Análisis de Requisitos: Se deben analizar todos los requisitos
formaran parte del sistema y con estos construir el diagrama de clases, que
representa las agrupaciones funcionales que estructuraran el sistema en
desarrollo.
Para esta fase se utilizan 3 herramientas
Modelo de Dominio: Esto se refiere a identificar objetos que intervienen
con nuestro sistema. (Estático)
Modelo de Casos de Uso: Describe las acciones o el comportamiento
que un usuario realiza dentro del sistema. Comprende de actores, casos
de uso y el sistema.
Prototipo de Interfaz de Usuario: Implica la creación de un modelo o
modelos operativos del trabajo de un sistema, en el que analistas y
clientes deben estar de acuerdo. (Dinámico/ los usuarios se hacen
participantes activos en el desarrollo).
7|P ági na
2.7.2. Análisis y Diseño Preliminar
En esta fase a partir de cada caso de uso se obtendrán una ficha de caso de
uso, (la cual no pertenece a UML), está formada por un nombre, una descripción,
una precondición que debe cumplir antes de iniciarse, una postcondicion que
debe cumplir al terminar si termina correctamente.
Diagrama de Robustez: Un diagrama de robustez es un híbrido entre
un Diagrama de Clases y Diagrama de Actividades. Es una herramienta
que nos permite capturar el Que hacer y a partir de eso él Como hacerlo.
2.7.3. Diseño
En esta fase se reconocen todos los elementos que forman parte de nuestro
sistema.
Se utilizará la herramienta de actividades.
2.7.4. Implementación
En esta fase a partir del buen diseño logrado se creará el software; que
posteriormente se entregará.
2.8. UML
El Lenguaje Unificado de Modelado o UML (“Unified Modeling Language”) es un
lenguaje estandarizado de modelado. Está especialmente desarrollado para
ayudar a todos los intervinientes en el desarrollo y modelado de un sistema o un
producto software a describir, diseñar, especificar, visualizar, construir y
documentar todos los artefactos que lo componen, sirviéndose de varios tipos de
diagramas
La finalidad de los diagramas es presentar diversas perspectivas de un sistema,
a las cuales se les conoce como modelo. Recordemos que un modelo es una
representación simplificada de la realidad; el modelo UML describe lo que
supuestamente hará un sistema, pero no dice cómo implementar dicho sistema.
2.8.1. Tipos de diagramas UML
En UML, existen dos clasificaciones de diagramas:
Diagramas estructurales
8|P ági na
Diagramas de comportamiento.
Clasificación de los diagramas UML
2.8.2. Diagramas estructurales
Los diagramas estructurales muestran la estructura estática del sistema y sus
partes en diferentes niveles de abstracción. Existen un total de siete tipos de
diagramas de estructura:
Diagrama de clases: Muestra la estructura del sistema, subsistema o
componente utilizando clases con sus características, restricciones y
relaciones: asociaciones, generalizaciones, dependencias, etc.
Diagrama de componentes: Muestra componentes y dependencias
entre ellos. Este tipo de diagramas se utiliza para el desarrollo basado en
componentes (CDB), para describir sistemas con arquitectura orientada a
servicios (SOA).
Diagrama de despliegue: Muestra la arquitectura del sistema como
despliegue (distribución) de artefactos de software.
Diagrama de objetos: Un gráfico de instancias, incluyendo objetos y
valores de datos. Un diagrama de objeto estático es una instancia de un
diagrama de clase; muestra una instantánea del estado detallado de un
sistema en un punto en el tiempo.
Diagrama de paquetes: Muestra los paquetes y las relaciones entre los
paquetes.
Diagrama de perfiles: Diagrama UML auxiliar que permite definir
estereotipos personalizados, valores etiquetados y restricciones como un
mecanismo de extensión ligero al estándar UML. Los perfiles permiten
adaptar el meta modelo UML para diferentes plataformas o dominios.
9|P ági na
Diagrama de estructura compuesta: Muestra la estructura interna
(incluidas las partes y los conectores) de un clasificador estructurado.
2.8.3. Diagramas de comportamiento
A diferencia de los diagramas estructurales, muestran cómo se comporta un
sistema de información de forma dinámica. Es decir, describe los cambios que
sufre un sistema a través del tiempo cuando está en ejecución. Hay un total de
siete diagramas de comportamiento, clasificados de la siguiente forma:
Diagrama de actividades: Muestra la secuencia y las condiciones para
coordinar los comportamientos de nivel inferior, en lugar de los
clasificadores que poseen esos comportamientos. Estos son comúnmente
llamados modelos de flujo de control y flujo de objetos.
Diagrama de casos de uso: Describe un conjunto de acciones (casos de
uso) que algunos sistemas o sistemas (sujetos) deben o pueden realizar
en colaboración con uno o más usuarios externos del sistema (actores)
para proporcionar algunos resultados observables y valiosos a los actores
u otros interesados del sistema(s).
Diagrama de máquina de estados: Se utiliza para modelar el
comportamiento discreto a través de transiciones de estados finitos.
Además de expresar el comportamiento de una parte del sistema, las
máquinas de estado también se pueden usar para expresar el protocolo
de uso de parte de un sistema.
2.8.4. Diagramas de interacción.: Es un subconjunto de los diagramas de
comportamiento. Comprende los siguientes diagramas:
Diagrama de secuencia: Es el tipo más común de diagramas de
interacción y se centra en el intercambio de mensajes entre líneas de vida
(objetos).
10 | P á g i n a
Diagrama de comunicación: Se enfoca en la interacción entre líneas de
vida donde la arquitectura de la estructura interna y cómo esto se
corresponde con el paso del mensaje es fundamental. La secuencia de
mensajes se da a través de una numeración.
Diagrama de tiempos: Se centran en las condiciones que cambian
dentro y entre las líneas de vida a lo largo de un eje de tiempo lineal.
Diagrama global de interacciones: Los diagramas global de
interacciones brindan una descripción general del flujo de control donde
los nodos del flujo son interacciones o usos de interacción.
2.9. Herramientas
Herramientas Tecnológicas
2.9.1. HTML5:
Lenguaje de marcado de hipertexto, versión 5 (por sus siglas en español), es la
revisión número 5 de lenguaje básico de la WWW. Es el lenguaje de
programación madre y básico de todos los sitios web.
Esta nueva versión ofrece mejoras que permiten el desarrollo de sitios web
funcionales con contenido multimedia, animaciones, efectos y nueva versión de
hojas de estilo sin plug-ins, [Gauchat, 2012].
2.9.2. CSS3:
Hojas de estilo en cascada por las siglas en ingles que permiten definir reglas y
estilos de representación en diferentes dispositivos ordenadores de Escritorio,
móviles y otros capaces de mostrar contenidos web, [Gauchat, 2012].
2.9.3. POSTGRESQL:
Gestor de base de datos libre de tipo objeto-relacional, soporta gran parte del
estándar SQL permite consultas complejas, triggers, vistas, entre otros. Puede
ser usado, modificado y distribuido libremente sin cargo para cualquier
propósito.
11 | P á g i n a
2.9.4 Lenguaje de Programación PHP:
Lenguaje de programación del lado del servidor diseñado para el desarrollo
web de contenido dinámico.
2.10. Pruebas
Pruebas (Diseño de Casos de Prueba)
Para la realización de estas es necesario la creación de casos de prueba
especificando la forma de probar el sistema como un todo, [Sommerville, 2005].
esto incluye:
Pruebas de configuración.
Pruebas negativas, encontrar debilidades del sistema.
Pruebas de tensión o de estrés al no existir recursos suficientes.
Prueba de integración del Sistema.
2.10.1. Pruebas de Caja Negra
También denominadas pruebas de comportamientos, se centran en los
requisitos funcionales del sistema. Esta prueba permite al ingeniero obtener
conjunto de condiciones de entrada que ejerciten los requisitos funcionales del
sistema, [Sommerville, 2005].
Este tipo de pruebas intentan encontrar errores de tipo:
Funciones incorrectas o ausentes
Errores de interfaz
Errores de estructuras de datos
Errores de rendimiento
Errores de inicio y fin
2.10.2. Pruebas de Caja Blanca
Denominada también prueba de caja de cristal, es un método de diseño de casos
de prueba que usa la estructura de control de diseño para obtenerlos,
[Sommerville,2005].
Con estas pruebas se pretenden:
Garantizar que se ejecuta al menos una vez todos los caminos
independientes de cada módulo.
12 | P á g i n a
Ejerciten todas las decisiones lógicas en sus vertientes verdadero y falsa.
Ejecuten todos los bucles en sus limite.
2.11. Métricas de calidad
2.11. ISO 9126
ISO 9126 era un estándar internacional para la evaluación de la calidad del software.
Fue reemplazado en 2005 por el conjunto de normas SQuaRE, ISO 25000:2014, la cual
desarrolla los mismos conceptos.
2.11.1. Funcionalidad
Conjunto de atributos que se relacionan con un conjunto de funciones y sus
propiedades, [Pressman, 2005]. Estas funciones satisfacen lo indicado o implica
necesidades. El grado en que el sistema satisface las necesidades se
determinan por:
Adecuación: Capacidad del sistema para proporcionar un conjunto de
funciones para tareas y objetivos especificados.
Exactitud: Capacidad del sistema para ofrecer los resultados acordados,
con el grado necesario de precisión.
Interoperabilidad: Capacidad del sistema para interactuar con uno o más
sistemas.
Seguridad de acceso: Capacidad del sistema para proteger la
información y datos de manera que personas o sistemas no puedan
leerlos o modificarlos.
Cumplimiento Funcional: Capacidad del sistema para adherirse a
normas, convenciones o regulaciones en leyes y prescripciones similares
relacionadas con funcionalidad.
2.11.2 Confiabilidad
Cantidad de tiempo que el sistema está dispuesto para su uso, [Pressman,2005],
referido por:
Madurez: Capacidad del sistema para evitar faltar como resultado de
fallos en el software.
Tolerancia a fallos: Mantener un nivel especificado de presentaciones
en cao de fallos de software.
13 | P á g i n a
Capacidad de recuperación: Capacidad del producto para restablecer
un nivel de prestaciones especificado y recuperar los datos afectados en
caso de fallos.
Cumplimiento de fiabilidad: Capacidad del producto para ajustarse a
normas, convenciones o regulaciones relacionadas con la fiabilidad.
2.11.3. Usabilidad
Se define la usabilidad como ―La capacidad de un producto de software de
facilitar a usuarios específicos alcanzar metas con eficacia, productividad,
seguridad y satisfacción en un contexto específico de uso‖. Añade que ―Calidad
en uso, es la visión de calidad de los usuarios de un ambiente conteniendo
software, y es medida sobre los resultados de usar el software en el ambiente,
antes que sobre las propiedades del software mismo‖, [Pressman, 2005].
2.11.4. Mantenimiento
Facilidad con que una modificación puede ser realizada, [Pressman, 2005]. Está
indicada por:
Capacidad para ser analizado: Capacidad del producto para
diagnosticar las deficiencias o causas de los fallos.
Capacidad para ser cambiado: Permite que una modificación sea
implementada.
Estabilidad: Para evitar efectos inesperados debido a modificaciones del
software.
Capacidad para ser probado: Permite que el producto modificado sea
validado.
Cumplimiento de mantenibilidad: Capacidad del producto para
ajustarse a normas o convenios relacionados con mantenibilidad.
CAPÍTULO III MARCO APLICATIVO
3.1 Introducción
En este capítulo se presentan todas las fases de la metodología y su aplicación
el en trabajo de ella.
3.2 Arquitectura del Negocio
14 | P á g i n a
3.3. Aplicar la metodología de acuerdo a cada fase
3.3.1 Revisión de los requisitos/ Análisis de Requisitos
[Link]. modelo de dominio
15 | P á g i n a
[Link]. Modelo de casos de uso
Casos de uso(paquetes)
16 | P á g i n a
CASO DE USO EMPLEADO
CASO DE USO PRODUCTO
17 | P á g i n a
CASO DE USO COMPRA
CASO DE USO SALIDA
18 | P á g i n a
[Link]. Prototipacion rápida
3.3.2. Análisis y Diseño Preliminar
[Link]. Diagrama de Robustez:
19 | P á g i n a
20 | P á g i n a
3.3.3. Diseño
[Link]. Requerimientos
REQUISITOS DEL SISTEMA
ID DESCRIPCION PRIORIDAD
R1 Base de datos independiente para el registro de ALTA
las ventas diarias y seguimiento de las tareas.
R2 Diseño de la interfaz para los registros o ALTA
formularios de compra, cotización, ordenes de
productos
R3 Automatizar el proceso de ventas ALTA
R4 Búsqueda de usuarios, clientes y productos ALTA
R5 Desarrollo de una interfaz para registrar clientes, MEDIA
usuarios y productos.
R6 Desarrollo de una interfaz para obtener
información de cada pedido cotización y venta.
R7 Seguimiento de información de ventas ALTA
realizadas por cada uno de los empleados.
R8 Reporte de deudas pendientes de cada cliente. MEDIA
R9 Reportes generados por las ventas diarias. ALTA
R10 Reportes generados de los productos. MEDIA
R11 Reportes de la ventas desde una fecha dada ALTA
para adelante.
R12 Control de acceso seguro para los usuarios. ALTA
R13 Interfaz amigable. MEDIA
R14 Seguridad en el acceso directo a la interfaz. MEDIA
REQUISITOS DE LAS VENTAS Y PRODUCTOS
Después de establecer los requerimientos (ítems) del usuario o cliente,
ordenados por prioridad, se genera la pila de producción en el cual estarán todas
las tareas funciones o requerimientos a realizar en el cual aporta mucho.
N° TAREA ESTIMACION DESCRIPCION
EN DIAS
21 | P á g i n a
PRIORIDAD
1 Realizar la base de datos 3 Se necesita una base de datos
del sistema independiente para el registro de las
ventas diarias y seguimiento de
compras y stock.
2 Diseñar una interfaz para 3 Para poder almacenar una venta se
ingresar informacion. necesita de una interfaz en la cual
llenamos los datos de cada venta
3 Automatizar el proceso de 2 Para que ya no se tenga que escribir
ventas cada venta en libros se automatizara el
proceso de todas las ventas
4 Desarrollo de una interfaz 3 Para el registro de cada compra se
para las compras necesitara una interfaz amigable que
permite el almacenamiento de
información.
5 Desarrollo de una interfaz 2 Permite obtener información de cada
para obtener información. producto venta cliente.
6 Control de pago 1 Realiza un control de pagos deudas de
los clientes que solicitaron un pedido
7 Reporte de pedidos 3 Realizar reportes de los productos a
vender ordenados por fecha
8 Control de acceso al 4 Para poder realizar un mejor control de
sistema acceso seguro de cada uno de los
usuarios
PRIORIDAD DEL NIVEL MEDIO
9 Realizar la búsqueda de las 3 Mediante filtros de búsqueda se
ventas optimizara las búsquedas
10 Seguimiento de las ventas 2 Realizar un seguimiento de cada una
realizadas de las ventas por cada empleado
11 Reporte de dados 2 Realizar los reportes con los datos de
los productos
22 | P á g i n a
12 Interfaz amigable 3 Facilitará el manejo del sistema,
mediante una interfaz sencilla y
amigable
13 Registro de datos de los 2 Para poder realizar una adecuada
clientes administración de los usuarios clientes
se registraran sus datos
[Link]. Implementación
23 | P á g i n a
24 | P á g i n a