1.Definir el problema-> Describir el problema de forma precisa y exacta. 2. Realizar un análisis de Requisitos-> En este paso se describen los requisitos que el sistema debe cumplir para satisfacer las necesidades del cliente o usuario. “La captura de requisitos es el proceso de averiguar, normalmente en circunstancias difíciles, lo que se debe construir, en otras palabras, lo que hará el sistema”. 3. Crear el modelo conceptual del dominio del problema-> En este paso se van a representar los conceptos más relevantes de las entrevistas, cuestionarios, observaciones, revisión documental, otros., realizadas para desarrollar el sistema. 4. Realizar Diseño de Sistema (Crear Arquitectura) -> en este paso se tiene el conjunto de diagramas UML que permiten modelar el problema y su solución. A continuación se mencionan los siguientes: 4.1 Diseño de Interfaces (E/S) 4.2 Diseño de Procesos:  Diagramas de Clases.  Diagramas de Secuencia.  Diagramas de Colaboración.  Diagramas de Actividad.  Diagramas de Estado. 4.3 Diseño de la Base de Datos 5. Evolución (Implantación) Codificación Documentación Pruebas Migración de Datos Entretenimiento/Capacitacion Costo del Sistema 6. Mantenimiento -> adaptación a nuevos requerimientos.

1. Integrantes:
Marialis Ramírez 26.820.557
Alirio Mendoza 26.554.148
Edirmary Parra 25.149.687
Ander Rodríguez 24.400.187
Angel Gutierrez 27,736,782
Willyadris Perez 26050070
Grupo numero 2
Diseño de sistemas

2. 1.Definir el problema-> Describir el problema de forma precisa y exacta.
2. Realizar un análisis de Requisitos-> En este paso se describen los requisitos que el sistema debe cumplir para satisfacer
las necesidades del cliente o usuario. “La captura de requisitos es el proceso de averiguar, normalmente en circunstancias difíciles, lo
que se debe construir, en otras palabras, lo que hará el sistema”.
3. Crear el modelo conceptual del dominio del problema-> En este paso se van a representar los conceptos más relevantes
de las entrevistas, cuestionarios, observaciones, revisión documental, otros., realizadas para desarrollar el sistema.
4. Realizar Diseño de Sistema (Crear Arquitectura) -> en este paso se tiene el conjunto de diagramas UML que permiten
modelar el problema y su solución. A continuación se mencionan los siguientes:
4.1 Diseño de Interfaces (E/S)
4.2 Diseño de Procesos:
Diagramas de Clases.
Diagramas de Secuencia.
Diagramas de Colaboración.
Diagramas de Actividad.
Diagramas de Estado.
4.3 Diseño de la Base de Datos
5. Evolución (Implantación)
Codificación
Documentación
Pruebas
Migración de Datos
Entretenimiento/Capacitacion
Costo del Sistema
6. Mantenimiento -> adaptación a nuevos requerimientos.
Utilizando dicha metodología daremos lugar a la problemática que presentan muchas empresas de la región en cuanto a la
optimización, control y administración de sus productos, hicimos énfasis en la empresa Heladería Granizados Carora C.A que tiene
como problemática el proceso de facturación e inventario, ya que actualmente el proceso de facturación e inventario se lleva a cabo de
manera manual, en consecuencia a esto se desea la automatización y la optimización del proceso por medio de la creación de un
sistema automatizado para dicha empresa.

3. 1. Definición del problema: En este paso el cliente presenta al analista
el problema que desea se le resuelva.
Problema:
Helados Granizados Carora C.A, desea adquirir un sistema automatizado
que pueda llevar el control y administración de sus productos de manera
eficiente, así como también la facturación de la empresa para obtener mayor
provecho al momento de administrar los gastos y ganancias de la misma.
1.1) Descripción precisa y exacta del problema: El analista presenta o
describe el problema de una forma entendible y precisa, para el programador
luego de realizar el levantamiento de problema.
Desarrollar un sistema automatizado que permita a Helados Granizados
Carora C.A, llevar el control y administración de sus productos, además de
su posterior facturación

4. Realizar el análisis de requisitos: En este paso se describen los requisitos
que el sistema debe cumplir para satisfacer las necesidades del cliente o
usuario. Ciclo de desarrollo de un Sistema de Control de Ventas
Fase Actividades Observaciones
Investigación de
Sistemas
• Observaciones directas.
• Entrevista con todos los
niveles del personal.
• Entrevista con usuarios finales.
• Encuestas.
• Grabaciones.
• Simulaciones.
Análisis de Sistemas
Requerimientos de Interfaz
deUsuario:
 Requerimientos de
Entrada
-Registrar datos del cliente
-Registrar datos de proveedor
-Registrar encargado.
-Registrar despachador.
-Registrar empleado.
--Registrar producto.
otros.
Requerimientos de salida
- Emitir Reporte de clientes,
proveedores, empleados y
despachadores registrados.
- Emitir Reporte de stock.
Requerimientos de
almacenamiento

5. 3. Crear el modelo conceptual del dominio del problema: Consiste en los objetos
del dominio del problema, es decir, objetos que tienen una correspondencia directa en el
área de la aplicación. Cuando se inicia el desarrollo de un sistema, lo primero que viene a
la mente, es que es lo que se va hacer. Por lo mismo, es necesario preguntar al usuario que
es lo que se requiere que haga el sistema. Entonces el usuario comienza a describir la
funcionalidad que está esperando que el sistema tenga. El Diagrama de Casos de Uso
plantea, que todo principio sea establecer las principales transacciones que contendrá el
sistema. Siendo una transacción cualquier interacción que el sistema tendrá con los
agentes externos a él.
Agentes Externos:
Encargado: Es el responsable de contactar y pedir los nuevos productos que desea
comprar para su local.
Empleado: Es el encargado de recibir los helados, llevar el control de cuantas helados
tiene en el local (en cuanto a sabores), registra clientes y también es encargado de recibir
los nuevos sabores de helados por parte del proveedor.
Despachador: encargado de entregar el pedido.
Cliente: Adquiere el producto.
Proveedor: Suministra los sabores de helados.

6. 4. Realizar Diseño del Sistema: Es la disciplina que define los
objetos y sus interacciones para resolver un problema de negocio que
fue identificado y documentado durante el análisis orientado a
objetos.
4.1 Diseño de Interfaces (E/S): Es el área del diseño que se enfoca en
la parte visual de un producto digital. Permite crear interfaces
intuitivas, usables, interactivas e impactantes. El diseño de interfaces
te permitirá conocer y encontrar qué patrones de diseño son los
mejores para cumplir las expectativas que tienen tus usuarios al usar
un producto a continuación le mostraremos 2 imágenes de lo que es
la interfaz del diseño

8. 4.2 Diseño de Procesos
Diagrama de Clases: sirve para visualizar las relaciones entre las clases que
involucran el sistema, las cuales pueden ser asociativas, de herencia, de
uso y de agregación, ya que una clase es una descripción de conjunto de
objetos que comparten los mismos atributos, operaciones, métodos,
relaciones y semántica; mostrando un conjunto de elementos que son
estáticos, como las clases y tipos junto con sus contenidos y relaciones. Un
diagrama de clases esta compuesto por los siguientes elementos: Clase:
atributos, métodos y visibilidad. Relaciones: Herencia, Composición,
Agregación, Asociación y Uso.
A continuación les mostraremos el diagrama de clase

10. Diagrama de Secuencia: es un tipo de diagrama de interacción cuyo
objetivo es describir el comportamiento dinámico del sistema de
información haciendo énfasis en la secuencia de los mensajes
intercambiados por los objetos.

11. Diagrama de Colaboración: es un tipo de diagrama de interacción
cuyo objetivo es describir el comportamiento dinámico del sistema
de información mostrando cómo interactúan los objetos entre sí, es
decir, con qué otros objetos tiene vínculos o intercambia mensajes
un determinado objeto.

12. Diagrama de Actividades: es un diagrama de flujo del proceso multi-
propósito que se usa para modelar el comportamiento del sistema. Los
diagramas de actividad se pueden usar para modelar un Caso de Uso, o
una clase, o un método complicado.

13. Diagrama de Estado: muestran el conjunto de estados por los cuales
pasa un objeto durante su vida en una aplicación en respuesta a
eventos (por ejemplo, mensajes recibidos, tiempo rebasado o errores),
junto con sus respuestas y acciones.

14. 4.3 Diseño de la base de datos: en esta parte se crea la base de datos a
partir de un servidor o un gestor de base de datos ya puede ser
phpmyadmin, xampp u otro gestor. De acuerdo a las necesidades del
sistemas crearas las base de dato con las trabas necesarias para
guardar los datos importantes del sistemas ya sean lo datos del
cliente, datos del proveedor entre otras cosas para eso se utiliza la
base de datos

15. 5.1 Codificación: En esta parte atreves de un lenguaje de programación
ya sea en java, php o cualquier otro lenguaje se procede a construir el
código para la creación del sistema, Para poder programar se descarga
cualquier editor de texto que te permita programar en el lenguaje que
deseas hacerlo
A continuación te mostraremos una parte de las líneas de código del
sistema seleccionado de nostros

17. 5.2 documentación: en esta parte se realiza un manual de usuario, sistema, instalación) de manera
que el usuario entienda lo que se hizo con el sistema y puede familiarizarse con el sistema, también
esto seria de gran ayuda para otro próximo programador en dado caso ya no estés en la empresa. La
documentación es el conjunto de información que nos dice qué hacen los sistemas, cómo lo hacen y
para quién lo hace.
La documentación consiste en material que explica las características técnicas y la operación de
un sistema. Es esencial para proporcionar entendimiento de un sistema a quien lo vaya a usar para
mantenerlo, para permitir auditoria del sistema y para enseñar a los usuarios como interactuar con el
sistema y a los operando como hacerlo funcionar.
Existen varios tipos de documentación. La de programas, que explica la lógica de un programa e
incluye descripciones, diagramas de flujo, listados de programas y otros documentos; la del usuarios
en forma general la naturaleza y capacidades del sistema y cómo usarlo.
Otra definición sería la de registro físico, generalmente por escrito que contiene los siguientes
elementos:
Políticas y normas referentes al desarrollo del sistema, su implantación, operación y mantenimiento.
El diseño del sistema de información administrativo.
Procedimientos para instalar el sistema de información administrativo.
Procedimientos para operar el sistema de información administrativo.
Procedimientos para mantener el sistema de información administrativo.
Importancia De La Documentación De Sistemas
La importancia de la documentación bien podría ser comparada con la importancia de la existencia
de una Póliza de Seguro; mientras todo va bien no existe la precaución de confirmar si nuestra Póliza
de Seguros está o no vigente.
La documentación adecuada y completa, de una aplicación que se desea implantar, mantener y
actualizar en forma satisfactoria, es esencial en cualquier Sistema de Información, sin embargo,
frecuentemente es la parte a la cual se dedica l menor tiempo y se le presta menos atención.
Siempre se debe documentar un sistema como si estuviera a punto de irse a Siberia el siguiente mes,
para nunca volver. Si la documentación del sistema es incompleta el diseñador continuamente estará
involucrado y no podrá moverse a otra asignación.

18. 5.3 Pruebas del sistema: se realizan pruebas al sistema ya creado para verificar su funcionamiento y así poder
comprobar que no existan error, que todo funcione en perfecta normalidad
Se pueden realizar:
Pruebas de componentes de código
pruebas funcionales
pruebas de validación
pruebas de aceptación
5.3.1 pruebas de componentes de código: El Equipo de Proyecto comprobará cada componente que va generando para
detectar posibles errores y evitar que éstos se reproduzcan en componentes o módulos posteriores. Además, cada vez
que se implemente la comunicación entre dos o más módulos que estén integrados, el equipo de proyecto comprobará
dicha integración. De este modo es más sencillo detectar y corregir los errores que si el sistema se encuentra
totalmente desarrollado y todos sus módulos integrados. Para ello, deberá realizar las siguientes pruebas:
Pruebas unitarias. Conjunto de pruebas que comprueban el correcto funcionamiento de cada componente de código
por separado. Esto sirve para asegurar que cada uno de los módulos funcione correctamente por separado.
Posteriormente, con las pruebas de integración, se podrá asegurar el correcto funcionamiento del sistema o subsistema
en cuestión. Para la ejecución de las pruebas unitarias se deberá utilizar una herramienta que automatice el proceso,
por ejemplo, JUnit. Se propone la siguiente plantilla como ayuda a la definición de las pruebas unitarias.
Pruebas de integración. Conjunto de pruebas que verifican la correcta integración entre todos los
componentes/módulos del sistema. La necesidad de realizar las pruebas de integración viene dada por el hecho de que
los módulos que forman un programa suelen fallar cuando trabajan de forma conjunta, aunque previamente se haya
demostrado que funcionan correctamente de manera individual. Por ello se deberán realizar este tipo de pruebas, las
cuáles asegurarán que los módulos que están relacionados se ejecutan correctamente. Con el uso de estas pruebas, se
conseguirá formar el producto global a medida que se comprueba como los distintos componentes interaccionan y se
comunican libres de errores. Para automatizar las pruebas de integración se pueden emplear las mismas herramientas
que para las pruebas unitarias (por ejemplo, JUnit), pero los casos de pruebas por regla general serán más largos y la
verificación de resultados puede requerir más de una comprobación. Se propone la siguiente plantilla como ayuda a la
definición de las pruebas de integración.
Pruebas de código estático. Son verificaciones de código estático que todo programador debe realizar en su código para
evitar errores de compilación, ejecución durante las fases posteriores. Un alto porcentaje de las pruebas se podrán
automatizar en herramientas, tales como Checkstyle, PMD, Findbugs.

19. 5.3.2 pruebas funcionales: Se puede definir un caso de prueba como “el conjunto de entradas,
condiciones de ejecución y resultados esperados" para satisfacer un objetivo concreto. La definición de
los casos de pruebas se debe basar en la explotación de los distintos escenarios de ejecución de los
casos de uso; en un diagrama de actividad, se puede asumir que existen distintos tipos de escenarios
marcados por cada que camino que se puede trazar partiendo de su estado inicial.
No obstante el número de caminos posibles en un diagrama de actividad suele ser muy elevado,
incluso en los casos más sencillos. Pero además, hay que añadir las múltiples posibilidades de
escenarios de pruebas si se consideran todos los posibles valores de entrada posibles. Puesto que no
resulta viable comprobar el comportamiento del software en todas las situaciones de funcionamiento,
debemos seleccionar los casos de pruebas eligiendo aquellos que resulten más representativos,
asegurando siempre una cobertura mínima. Se entenderá que un caso de uso, a través de su diagrama
de actividad, estará los suficientemente probado, si los caminos utilizados permiten pasar por todas
las flechas y transiciones del diagrama, al menos una vez.
Además, se deberá realizar un análisis del dominio de valores de entrada, para detectar grupos de
datos que cuentan con un comportamiento homogéneo en el sistema, de forma que si el sistema falla
con un dato concreto, podamos suponer que fallará también con otro dato del mismo grupo.
Por tanto, a partir de los caminos mínimos identificados y de los grupos de datos se establecerán los
casos de pruebas necesarios para probar la funcionalidad completa del sistema. Se recomienda utilizar
la plantilla propuesta por MADEJA.
Una vez finalizada la construcción del sistema, el Equipo de Proyecto deberá ejecutar los casos de
pruebas definidos, con el fin de probar la funcionalidad completa del sistema software desarrollado.

20. 5.4 Costo del sistema: en esta parte se estima las horas trabajas y
si hubo algún gasto del sistema, si la hora trabajada es efectiva o
frente a la computadora, si cobro como programador sénior o
junior, los gastos de operación, entre otros. En cuanto a las horas
productivas, ya sabiendo todo eso se procede a calcular el costo
del sistema

21. Se realiza después de la entrega del producto al cliente. Se realiza para
corregir errores, mejorar el rendimiento, u otros atributos, eliminación
de funciones obsoletas y optimización. Debido a que el cambio es
inevitable, se debe desarrollar mecanismos para la evaluación, controlar
y hacer modificaciones.
Así que cualquier trabajo realizado para cambiar el software después de
que esté en operación es considerado trabajo de mantenimiento. El
propósito es preservar el valor del software sobre el tiempo. El valor
puede ser mejorado ampliando la base de clientes, cumpliendo
requisitos adicionales, siendo cada vez más fácil de usar, más eficiente y
empleando más nuevas tecnología