G2 - Atividade Prática 4

Prévia do material em texto

PONTIFÍCIA UNIVERSIDADE CATÓLICA DE GOIÁS
DEPARTAMENTO DE COMPUTAÇÃO
João Vitor Ferreira de Melo
Vinícius Biasi Nascimento
Wemerson Moura Viana
Willgnner Ferreira Santos
G2 – Atividade Prática 4
André Luiz Alves
GOIÂNIA,
2021
João Vitor Ferreira de Melo
Vinícius Biasi Nascimento
Wemerson Moura Viana
Willgnner Ferreira Santos
G2 – Atividade Prática 4
Relatório apresentado como requisito parcial para obtenção de aprovação na disciplina Validação e Testes de Sistemas no Curso de Engenharia da Computação, na Pontifícia Universidade Católica de Goiás.
André Luiz Alves
GOIÂNIA,
2021
Revisões
A primeira versão deste documento é criada após a sua aprovação e é vinculada a uma baseline do software. Esta versão, portanto, não pode ser modificada. As modificações que se fizerem necessárias após a criação da baseline farão parte de uma versão seguinte que será vinculada a uma outra baseline. Este procedimento pode se repetir sucessivamente. As modificações introduzidas em cada versão devem ser registradas seguindo o modelo do quadro abaixo. Desta forma, será possível perceber as diferenças entre as diversas versões geradas.
	Data
	Descrição
	Autor
	17/11/2021
	Criação do documento
	João, Vinícius, Wemerson e Willgnner.
Sumário
1.	Introdução	5
1.1.	Objetivos	5
1.2.	Público-Alvo	5
1.3.	Organização do documento	5
2.	Casos de Uso	5
2.1.	Atores	5
2.2.	Lista de casos de uso	5
3.	Requisitos e restrições funcionais (RFUN)	6
4.	Requisitos e restrições não funcionais	8
4.1.	Requisitos e Restrições de Informação (RINF)	8
4.2.	Requisitos e Restrições de Interface Homem Computador (RIHC)	8
4.3.	Requisitos de Interface Externa (RIEX)	9
4.4.	Requisitos e Restrições de Projeto (RPRO)	9
4.5.	Requisitos e Restrições de Arquitetura de Software (RARQ)	9
4.6.	Requisitos e Restrições de Plataforma de Hardware (RPHW)	9
4.7.	Requisitos e Restrições de Plataforma de Software (RPSW)	9
4.8.	Requisitos e Restrições de Desempenho (RDES)	10
4.9.	Requisitos e Restrições de Disponibilidade (RDIS)	10
4.10.	Requisitos e Restrições de Segurança (RSEG)	11
4.11.	Requisitos e Restrições de Manutenibilidade (RMAN)	11
4.12.	Requisitos e Restrições de Portabilidade (RPOR)	11
4.13.	Requisitos de Documentação (RDOC)	12
5.	Matriz de Rastreabilidade	12
5.1.	Requisitos e Restrições Funcionais (RFUN)	13
5.2.	Requisitos e Restrições de Informação (RINF)	14
5.3.	Requisitos e Restrições de Interface Homem Computador (RIHC)	14
5.4.	Requisitos de Interface Externa (RIEX)	14
5.5.	Requisitos e Restrições de Projeto (RPRO)	14
5.6.	Requisitos e Restrições de Arquitetura de Software (RARQ)	14
5.7.	Requisitos e Restrições de Plataforma de Hardware (RPHW)	14
5.8.	Requisitos e Restrições de Plataforma de Software (RPSW)	14
5.9.	Requisitos e Restrições de Desempenho (RDES)	15
5.10.	Requisitos e Restrições de Disponibilidade (RDIS)	15
5.11.	Requisitos e Restrições de Segurança (RSEG)	15
5.12.	Requisitos e Restrições de Manutenibilidade (RMAN)	15
5.13.	Requisitos e Restrições de Portabilidade (RPOR)	15
5.14.	Requisitos de Documentação (RDOC)	15
6.	System Overview	15
6.1.	UML	16
6.2.	Diagrama de Classes	22
6.2.1	Diagrama de classes sem atributos e métodos	22
6.2.2	Exemplo de um diagrama de classe com atributos e métodos já especificados.	23
7.	Construção de Software	24
7.1.	Fundamentos	24
7.2.	Gerenciando a Construção	24
7.3.	Considerações práticas	24
8.	Aprovação Formal	24
9.	Bibliografia	24
10.	Abreviações	25
Introdução
Com o alto índice de pedidos em empresas de fast-food e necessidades de serviços remotos surgindo a necessidade de um controle e automação no setor de entregas, possibilitando um melhor atendimento ao cliente e agregando uma entrega mais ágil e confiável, por esse motivo o Delivery WJV vem trazer um gerenciamento de pedidos, o padrão de desenvolvimento utilizado foi a versão mobile pois o mesmo pode ser acessado de qualquer lugar, basta ter acesso a internet e um celular com sistemas de Android ou iOS, possibilitando assim uma melhor administração e controle do processo, a presente documentação especifica os requisitos do Aplicativo Delivery WJV, de modo geral, um melhor atendimento do cliente possibilitando a melhor interação e maior fidelização, cliente/empresa.
Objetivos
Este documento tem o objetivo de descrever o software e especificar os requisitos do sistema Delivery WJV.
Público-Alvo
Clientes, usuários e administradores do sistema.
Organização do documento
O documento está dividido em tópicos como especificado no conteúdo do sumário, mostrado no início do documento.
Casos de Uso
Atores
1. Cliente
1. Gerente
1. Recepcionista
1. Chef / Cozinheiro
1. Entregador
Lista de casos de uso
	Ref.
	Descrição
	Atores
	Categoria
	CSU1
	Receber ligação pelo aplicativo.
	Recepcionista
	Primário
	CSU2
	Realizar pedido.
	Cliente
	Primário
	CSU3
	Solicitar 	cancelamento 	de pedidos dentro do prazo de 5 min.
	Cliente
	Primário
	CSU4
	Cancelar pedidos após o prazo de confirmação.
	Gerente
	Primário
	CSU5
	Aceitar o pedido para preparação.
	Chef /Cozinheiro
	Primário
	CSU6
	Solicitar troca ou exclusão de condimentos.
	Cliente
	Primário
	CSU9
	Cadastrar pratos.
	Chef /Cozinheiro
	Secundário
	CSU10
	Concluir prato.
	Chef/Cozinheiro
	Primário
	CSU11
	Receber pratos.
	Chef /Cozinheiro
	Primário
	CSU12
	Escolher forma de pagamento.
	Cliente
	Primário
	CSU13
	Receber pedido para entrega.
	Entregador do Aplicativo
	Primário
	CSU14
	Permitir chat direto entre cliente/entregador.
	Cliente/Entregador
	Primário
	CSU15
	Permitir chat direto entre cliente/restaurante.
	Cliente/ Gerente
	Primário
	CSU16
	Sinalizar entrega/recebimento do pedido.
	Cliente/Entregador
	Primário
	CSU17
	Avaliar entrega.
	Cliente
	Primário
	CSU18
	Permitir observação de compra.
	Cliente
	Primário
	CSU19
	Realizar Pagamento
	Cliente
	Primário
	CSU20
	Visualizar cardápio
	Cliente
	Primário
	CSU21
	Cadastrar Cliente
	Cliente
	Primário
	CSU22
	Realizar login
	Todos os Atores
	Primário
	CSU23
	Acompanhar entrega do pedido
	Cliente
	Primário
Requisitos e restrições funcionais (RFUN)
Todos os requisitos funcionais do sistema Delivery WJV estão listados na tabela abaixo.
	Ref.
	Função
	Categoria
	Prioridade
	Casos de Uso
	RFUN1
	O sistema deverá registrar a venda de um produto.
	Evidente
	Alta
	CSU5
	RFUN2
	O sistema deverá permitir alteração dos condimentos.
	Evidente
	Média
	CSU6
	RFUN3
	O sistema deverá permitir cancelar pedidos dentro do prazo.
	Oculta
	Alta
	CSU3
	RFUN4
	O sistema deverá enviar confirmação de compra ao Cliente.
	Oculta
	Alta
	CSU2/CSU5
	RFUN5
	O sistema deverá permitir cadastro dos funcionários.
	Oculta
	Média
	CSU7
	RFUN7
	O sistema deverá permitir o Cliente visualizar o cardápio.
	Evidente
	Alta
	CSU2
	RFUN8
	O sistema deverá permitir ao Chef atualizar cardápio.
	Oculta
	Alta
	CSU9
	RFUN9
	O sistema deverá enviar o pedido ao Chef.
	Oculta
	Alta
	CSU5
	RFUN11
	O sistema deverá atualizar os pedidos após o prazo.
	Oculta
	Média
	CSU4
	RFUN12
	O sistema deverá apresentar uma opção para sinalizar a conclusão do prato.
	Oculta
	Média
	CSU10
	RFUN13
	O sistema deverá aceitar formas de pagamento online.
	Evidente
	Alta
	CSU12/CSU19
	RFUN14
	O sistema deverá aceitar pagamento durante a entrega.
	Evidente
	Alta
	CSU12/CSU19
	RFUN15
	O sistema deverá avisar no cardápio online quando um prato estiver em falta.
	Evidente
	Alta
	CSU20
	RFUN16
	O sistema deverá permitir chat online entre cliente/entregador.
	Evidente
	Alta
	CSU14
	RFUN17
	O sistema deverá permitir chat online entre cliente/restaurante.
	Evidente
	Alta
	CSU15
	RFUN18
	O sistema deverá oferecer ao Cliente escolher a forma de como receber o pedido.
	Evidente
	Alta
	CSU16
	RFUN19
	O sistema deverá oferecer a opção ao Cliente de dar gorjeta.
	Evidente
	Média
	CSU19
	RFUN20
	O sistema deverá permitir o Cliente fazer observação ao realizar pedido.
	Evidente
	Alta
	CSU18
	RFUN21
	O sistema deverá permitir cadastrar Clientes.
	Evidente
	Alta
	CSU21 / CSU22
Requisitos e restrições não funcionais
Os Requisitos não funcionaisabaixo estão divididos em tipos de requisitos e possuem um identificador único para que possam ser referenciados sem ambiguidades no futuro.
Requisitos e Restrições de Informação (RINF)
	Ref.
	Tipo
	Descrição
	Casos de Uso
	RINF1
	Cadastral
	Login deve ser autenticado
	CSU22
	RINF2
	Cadastral
	Não pode ter dois produtos com o mesmo nome
	CSU9
	RINF3
	Cadastral
	Usuário deve ter CPF válido 
	CSU22
	RINF2
	Cadastral
	O sistema deverá solicitar informações do funcionário.
	CSU7
	RINF3
	Cadastral
	O sistema deverá solicitar informações sobre o produto.
	CSU2/CSU9/CSU20
	RINF4
	Cadastral
	O sistema deverá solicitar informações para o cadastro de clientes.
	CSU21
	RINF5
	Cadastro 
	O sistema deverá receber o cadastro dos pratos disponíveis no restaurante
	CSU9/CSU20
Requisitos e Restrições de Interface Homem Computador (RIHC)
	Ref.
	Descrição
	Casos de Uso
	RIHC1
	Para facilitar a usabilidade na transação de venda, pede-se que a tela de vendas tenha uma fonte que permita uma fácil visualização.
	Todos
	RIHC2
	O software deverá apresentar uma interface intuitiva de fácil usabilidade.
	Todos
	RIHC3
	O software deverá ter uma seção onde o cardápio do dia estará em evidencia, a fim de facilitar o acesso. 
	CSU20
	RIHC4
	O tempo de resposta do programa, deverá ser de no máximo 3 segundos.
	Todos
Requisitos de Interface Externa (RIEX)
	Ref.
	Descrição
	Casos de Uso
	RIEX1
	O software deverá gerar recibo pelo email cliente.
	CSU19
 Requisitos e Restrições de Projeto (RPRO)
	Ref.
	Descrição
	Casos de Uso
	RPRO1
	O software deverá ser desenvolvido pela equipe de desenvolvimento do sistema Delivery WJV.
	Todos
	RPRO2
	O software deverá ser desenvolvido utilizando a ferramenta CASE, na linguagem Java, gerando um código padrão da empresa.
	Todos
	RPRO3
	A equipe responsável deverá dar um feedback mensal sobre o andamento do projeto.
	Todos
	RPRO4
	O projeto só será iniciado pela equipe responsável somente quando o protótipo for aceito pelo cliente.
	Todos
Requisitos e Restrições de Arquitetura de Software (RARQ)
	Ref.
	Descrição
	Casos de Uso
	RARQ1
	O software deverá ser desenvolvido com uma arquitetura de camadas que permita isolar as funcionalidades ligadas ao negócio das mesmas relacionadas com a interface homem-computador.
	Todos
Requisitos e Restrições de Plataforma de Hardware (RPHW)
	Ref.
	Descrição
	Casos de Uso
	RPHW1
	Aparelhos celulares e computadores deverão operar o software.
	Todos
Requisitos e Restrições de Plataforma de Software (RPSW)
	Ref.
	Descrição
	Casos de Uso
	RPSW1
	O software deverá ser desenvolvido para operar em sistemas mobile como IOS e ANDROID.
	Todos
	RPSW2
	O software deverá ser desenvolvido para operar em sistemas operacionais como WINDOWS, MAC e LINUX.
	Todos
	RPSW3
	O software deverá ter suporte de portabilidade as versões mais recentes dos sistemas operacionais.
	Todos
	RPSW4
	O software deverá ter suporte de portabilidade a versão mais recente dos sistemas mobile.
	Todos
Requisitos e Restrições de Desempenho (RDES)
	Ref.
	Descrição
	Casos de Uso
	RDES1
	O ambiente onde o software rodará deverá permitir picos de acesso sem queda de velocidade.
	Todos
	RDES2
	O 	tempo 	de 	resposta 	máximo 	permitido 	para transações on-line é de até 3 segundos.
	Todos
	RDES3
	O software deverá ser capaz de suprir altas transações simultâneas da função “Realizar Pedido”.
	CSU3
	RDES4
	O 	sistema d	everá 	apresentar 	funcionalidades necessárias para uma alta eficiência de desempenho.
	Todos
	RDES5
	O sistema deverá permitir acessos simultâneos sendo operados por diferentes perfis de usuários do sistema.
	Todos
Requisitos e Restrições de Disponibilidade (RDIS)
	Ref.
	Descrição
	Casos de Uso
	RDIS1
	O software deverá permanecer operante de forma contínua durante todos os dias da semana.
	Todos
	RDIS2
	O sistema deve reiniciar por completo em até, no máximo, 10 segundos.
	Todos
	RDIS3
	A opção de realizar pedido não pode ficar mais do que 30 minutos indisponível.
	Todos
	RDIS4
	O software deverá restringir pedidos fora do horário de funcionamento do estabelecimento.
	 CSU2
	RDIS5
	As manutenções e atualizações do sistema deverão ser feitas fora do horário de funcionamento do estabelecimento.
	Todos
	RDIS6
	O software deverá permitir exceções no sistema para horários de funcionamento.
	Todos
 Requisitos e Restrições de Segurança (RSEG)
	Ref.
	Descrição
	Casos de Uso
	RSEG1
	O software deverá solicitar autorização do gerente para excluir uma venda já registrada.
	CSU4
	RSEG2
	Somente usuários previamente cadastrados possuem acesso a versão mobile para realizar pedidos no restaurante.
	Todos
	RSEG3
	Somente 	usuários 	previamente 	cadastrados 	podem realizar compras no software.
	Todos
	RSEG4
	Para qualquer atualização efetuada deverá ser registrado o usuário que realizou a operação assim como a data e hora.
	Todos
	RSEG5
	Todo usuário do software deverá ser associado a um perfil que define as funcionalidades que poderão ser utilizadas por ele.
	Todos
Requisitos e Restrições de Manutenibilidade (RMAN)
	Ref.
	Descrição
	Casos de Uso
	RMAN1
	O projeto das responsabilidades de cada classe de objetos deverá seguir os padrões GRASP sugeridas no livro Utilizando UML e Padrões de Craig Larman.
	Todos
	RMAN2
	Todo programa deve estar documentado de acordo com as orientações contidas na Norma de Documentação de Programas da empresa.
	Todos
Requisitos e Restrições de Portabilidade (RPOR)
	Ref.
	Descrição
	Casos de Uso
	RPOR1
	O software deverá ser capaz de rodar em celulares com sistemas Android ou em IOS.
	Todos
	RPOR2
	O software deverá permitir a utilização dos seguintes Bancos de dados: SQL Server, MySql, MongoDB, POstgre SQL ou Oracle
	Todos
Requisitos de Documentação (RDOC)
	Ref.
	Descrição
	Casos de Uso
	RDOC1
	O software deve prover ajuda on-line em todas as suas telas.
	Todos
	RDOC2
	O software deverá conter um Chatbot para eventuais dúvidas sobre funcionamento.
	Todos
	RDOC3
	A 	empresa 	responsável 	pelo 	desenvolvimento deverá prestar suporte ao sistema.
	Todos
Matriz de Rastreabilidade
Requisitos e Restrições Funcionais (RFUN)
Requisitos e Restrições de Informação (RINF)
Requisitos e Restrições de Interface Homem Computador (RIHC)
Requisitos de Interface Externa (RIEX)
Requisitos e Restrições de Projeto (RPRO)
Requisitos e Restrições de Arquitetura de Software (RARQ)
Requisitos e Restrições de Plataforma de Hardware (RPHW)
Requisitos e Restrições de Plataforma de Software (RPSW)
Requisitos e Restrições de Desempenho (RDES)
Requisitos e Restrições de Disponibilidade (RDIS)
Requisitos e Restrições de Segurança (RSEG)
Requisitos e Restrições de Manutenibilidade (RMAN)
Requisitos e Restrições de Portabilidade (RPOR)
Requisitos de Documentação (RDOC)
System Overview
O Sistema tem o objetivo de facilitar a interação do cliente com diversos estabelecimentos por meio do Delivery WJV trazendo um modelo simples e prático de solicitações de pedidos cadastros de clientes dentre outas muitas funcionalidades o que automatiza grande parte do processo de interação entre o cliente e o a empresa além de rodar na maioria dos sistemas operacionais atuais inclusive em plataforma mobile.
A seguir mostraremos um Diagrama de Contexto que resume todas as atividades de processamento e também ajuda os usuários a visualizar o nível mais alto do sistema com os limites do sistema.
UML
Na Linguagem de modelagem unificada (UML), o diagrama de caso de uso resume os detalhes dos usuários do seu sistema (também conhecidos como atores) e as interações deles com o sistema. Para criar um, use um conjunto de símbolos e conectores especializados. Um bom diagrama de caso de uso ajuda sua equipe a representar e discutir:
· Cenários em que o sistema ou aplicativo interage com pessoas, organizações ou sistemas externos;
· Metas que o sistema ou aplicativo ajuda essas entidades (conhecidas como atores) a atingir;
· O escopo do sistema.
Diagrama de Casos de Uso
Figura 1 - Realizar acesso ao Aplicativo Delivery WJV
Figura2 - Realização de pedido no aplicativo Delivery WJV
Figura 3 - Aplicativo Delivery WJV com acesso ao Estoque do estabelecimento
Para montar um diagrama de caso são necessários os seguintes componentes:
· Caso de uso: formato oval na horizontal e que representam os diferentes usos que um usuário pode ter.
· Atores: bonecos palito, representando as pessoas que realmente implementam os casos de uso.
· Associações: uma linha entre atores e casos de uso. Nos diagramas complexos, é importante saber quais atores estão associados a quais casos de uso.
· Caixa de limite do sistema: caixa que define um escopo do sistema para os casos de uso. Todos os casos de uso fora da caixa são considerados fora do escopo do sistema.
· Pacote: uma forma UML na qual colocar diferentes elementos em grupos. Assim como no diagrama de componentes, esses agrupamentos são representados como pastas de arquivos.
Modelo de caso de uso detalhado.
· Identificação: O caso de uso a ser detalhado e sua identificação.
· Escopo: Por onde acessá-lo
· Descrição: Qual a função designada ao caso de uso dentre o sistema
· Ator: Um ator representa um conjunto coerente de papéis que os usuários de casos de uso desempenham
· Fluxo normal: A sequência de passos a ser seguida para que o caso de uso tenha seu papel efetuado dentre o sistema
· Tratamento de erro: Será a mensagem a qual o sistema mostrara caso haja uma exceção ou erro em alguma etapa dos passos descritos no fluxo normal. 
· Requisitos relacionados: São os requisitos que tem alguma ligação com o caso de uso que foi detalhado.
Casos de uso detalhados:
Diagrama de Classes
Diagrama de classes sem atributos e métodos
Na criação do diagrama de classes são utilizados diversos elementos sendo que os mais aparecem em projetos são:
· Classe
· Associação
· Herança
· Composição
· Agregação
 Diagrama de classe com atributos e métodos já especificados.
	
Construção de Software
Fundamentos
O termo Construção de Software se refere à construção detalhada de um software funcional, através de uma combinação de codificação, verificação e teste. Seus fundamentos são:
· Minimizar complexidade;
· Antecipar mudanças;
· Construir para verificação;
· Reuso;
· Padrões de construção;
Gerenciando a Construção
Já quando se trata do processo deve-se atentar aos seguintes tópicos:
· Construção em modelos de ciclo de vida;
· Planejamento da construção;
· Mensuração da construção;
Considerações práticas
Devido à influência de variáveis do mundo real, construção está mais relacionado as considerações práticas do que alguma outra área de conhecimento (KA). Por isso é importante destacar:
· Design de construção;
· Linguagem de construção;
· Codificação;
· Teste na construção;
· Reuso na construção;
· Qualidade de construção;
· Integração;
Aprovação Formal
Data: 16/11/2021
Local: Goiânia, Goiás, Brasil
Versão: 1.0
Bibliografia
Fontes de informação usadas para desenvolver o Documento de Requisitos do sistema Delivery WJV.
[1] EOR – Modelo de Documento de Especificação de Objetivos e Requisitos de Software, Versão 1.0, setembro de 2017.
Meta-Modelo usado como guia para definição do formato e conteúdo deste documento.
Abreviações
	CASE = Computer-Aided Software Engineering (Engenharia de Software Auxiliada por Computador)
	CSU = Caso de Uso
	EOR = Especificação de Objetivos e Requisitos
	GRASP = General Responsibility Assignment Software Patterns (Padrões de Software de Atribuição de Responsabilidade Geral)
	RARQ = Requisitos e Restrições de Arquitetura de Software
	RDES = Requisitos e Restrições de Desempenho
	RDIS = Requisitos e Restrições de Disponibilidade
	RDOC = Requisitos de Documentação
	Ref = Referência
	RFUN = Requisitos e Restrições Funcionais
	RIEX = Requisitos de Interface Externa
	RIHC = Requisitos e Restrições de Interface Homem-Computador
	RINF = Requisitos e Restrições de Informação
	RMAN = Requisitos e Restrições de Manutenibilidade
	RPHW = Requisitos e Restrições de Plataforma de Hardware
	RPOR = Requisitos e Restrições de Portabilidade
	RPRO = Requisitos e Restrições de Projeto
	RPSW = Requisitos e Restrições de Plataforma de Software
	RSEG = Requisitos e Restrições de Segurança
	SQL = Structured Query Language (Linguagem de Consulta Estruturada)
	UML = Unified Modeling Language (Linguagem de modelagem unificada)
Participantes na criação deste Documento de Requisitos: João, Vinícius, Wemerson e Willgnner.
CSU19
RIEX1X
RIEX2X
Todos
RPRO1X
RPRO2X
RPRO3X
RPRO4X
Todos
RARQ1X
Todos
RPHW1X
Todos
RPSW1X
RPSW2X
RPSW3X
RPSW4X
CSU3Todos
RDES1X
RDES2X
RDES3X
RDES4X
RDES5X
CSU2Todos
RDIS1X
RDIS2X
RDIS3X
RDIS4X
RDIS5X
RDIS6X
CSU4Todos
RSEG1X
RSEG2X
RSEG3X
RSEG4X
RSEG5X
Todos
RMAN1X
RMAN2X
Todos
RPOR1X
RPOR2X
Todos
RDOC1x
RDOC2x
RDOC3x
CSU2CSU7CSU9CSU20CSU21
RINF1X
RINF2XXX
RINF3X
RINF4XX
CSU20Todos
RIHC1X
RIHC2X
RIHC3X
RIHC4X