Desenvolvimento do escopo de um projeto de um produto de software

Prévia do material em texto

2
Trabalho de APS
Sistemas de Informação
Campus
2021
Nome: RA:
Nome: RA:
Nome: RA:
Desenvolvimento do escopo de um projeto de um produto de software
Trabalho de Atividade Prática 
Supervisionada apresentado
ao Professor xxxxxxxxxxxxxx
xxxxxxxxxxx, do curso de 
Sistemas de Informação da 
 Universidade Paulista – UNIP,
 campus de xxxxxxxxxxxxxxxx. 
Campus
2021
Sumário
1.Objetivo	5
2.Introdução	6
3.Conceitos gerais	7
3.1. Requisitos de software	7
3.1.1. Requisitos funcionais	7
3.1.2. Requisitos não funcionais	8
3.1.3. Mensagem do sistema	9
3.2. Engenharia de Requisitos	9
3.3. Modelagem gráfica	9
3.3.1. Diagramas estruturais	9
3.3.2. Diagramas comportamentais	10
3.3.3. Lista de caso de uso	10
3.3.4. Tabela de relação de atores/processos	11
3.4. Prototipação	12
4. Documento de Requisitos	19
4.1. Modelagem	19
4.2. Protótipos	19
5. Conclusão	19
6. Bibliografia	20
7. Ficha de Atividades Práticas Supervisionadas	21
1.Objetivo
Esse trabalho tem como objetivo o desenvolvimento do escopo de um projeto de um produto de software baseando-se nas necessidades do cliente (ONG – ONG Jovens Ambientalistas), que recolhe, educa e oferece formação profissionalizante para jovens sem lar que depois de receberem cursos gratuitos por professores que são ex-alunos, prestam serviços remunerados, fabricando brinquedos “ambientalmente corretos” que são vendidos para o Brasil e o exterior. A referida ONG deseja instalar uma solução computacional para melhorar o controle das informações referentes aos serviços, produtos e financeiro da Instituição. A proposta desse desafio é planejar o desenvolvimento do sistema proposto pelo cliente, assegurando a melhor qualidade possível durante o desenvolvimento e o resultado final.
2.Introdução
O trabalho passa uma visão geral em questão de desenvolvimento de software mostrando a relação entre o software e seu ambiente, sendo o software apresentado para todos causando efeito e sempre tentando atingir todos os seus propósitos definidos em projeto após reuniões com o cliente.
Essa atividade busca a solução de facilitar registros a cerca dos módulos do sistema que é pedido pelo cliente, após o pedido é encontrada a solução computacional em busca de facilitar e melhorar o controle de todas as informações que passam pelo sistema do cliente, sendo assim, facilitando soluções.
O desenvolvimento do software abrange diversas etapas tendo a versatilidade de evoluir rapidamente, mas que pode haver sempre problemas que devem ser resolvidos antes de ser implantado em todo o sistema, apesar disso as soluções de software após termino são de grande ajuda e importância para trabalhar com esses dados e informações.
3.Conceitos gerais
3.1. Requisitos de software
Requisitos de software são as ações que o software deve executar possuindo características e condições próprias, de forma a automatizar uma tarefa de um processo de negócio. A que definimos os requisitos funcionais e não funcionais, e, conforme o método IRON, Requisitos de Dados e Regras de Execução (REDEREQUISITOS, 2017).
3.1.1. Requisitos funcionais
	RF001
	O usuário deve se identificar
	RF002
	O aluno pode consultar suas notas
	RF003
	O aluno pode consultar suas faltas
	RF004
	O professor pode executar as mesmas ações do aluno
	RF005
	O professor pode cadastrar notas dos alunos
	RF006
	O professor pode atualizar notas dos alunos
	RF007
	O professor pode cadastrar faltas dos alunos
	RF008
	O professor pode atualizar faltas dos alunos
	RF009
	O professor pode atualizar suas informações
	RF010
	O professor pode examinar alunos
	RF011
	O administrador pode executar as mesmas ações do professor
	RF012
	O administrador pode cadastrar professores
	RF013
	O administrador pode excluir professores
	RF014
	O administrador pode examinar professores
	RF015
	O administrador pode cadastrar alunos
	RF016
	O administrador pode atualizar alunos
	RF017
	O administrador pode excluir alunos
	RF018
	O administrador pode cadastrar empresas
	RF019
	O administrador pode atualizar empresas
	RF020
	O administrador pode excluir empresas
	RF021
	O administrador pode consultar empresas
3.1.2. Requisitos não funcionais
	RFN001
	Desempenho
O sistema deve garantir que as transações por cartão devem ser aprovadas em menos de 5 minutos.
Prioridade: ( ) Essencial ( ) Importante ( ) Desejável 
	RFN002
	Arquitetura de Software
O design deve seguir o design pattern MVC (Modelo, Visão e Controle).
Prioridade: ( ) Essencial ( ) Importante ( ) Desejável
	RFN003
	Apresentação da interface gráfica
O sistema deve fazer uso prioritário da língua Portuguesa.
Prioridade: ( ) Essencial ( ) Importante ( ) Desejável
	RFN004
	Usabilidade
O sistema deve dispor ao usuário uma interface simples e intuitiva, de fácil navegação para facilitar o uso do mesmo por parte dos usuários.
Prioridade: ( ) Essencial ( ) Importante ( ) Desejável
	RFN005
	Linguagem de programação exercida
A implementação do sistema deve ser feito em PHP.
Prioridade: ( ) Essencial ( ) Importante ( ) Desejável
	RFN006
	Banco de dados
A implementação do sistema deve utilizar MySQL como servidor de banco de dados.
Prioridade: ( ) Essencial ( ) Importante ( ) Desejável
3.1.3. Mensagem do sistema
	MS001
	Professor cadastrado com êxito!
	MS002
	Professor editado com êxito!
	MS003
	Professor excluído com êxito!
	MS004
	Empresa cadastrada com êxito!
	MS005
	Empresa editada com êxito!
	MS006
	Empresa excluída com êxito!
	MS007
	Aluno cadastrado com êxito!
	MS008
	Aluno editado com êxito!
	MS009
	Aluno excluído com êxito!
	MS010
	Nota cadastrada com êxito!
	MS011
	Nota editada com êxito!
	MS012
	Falta cadastrada com êxito!
	MS013
	Nota editada com êxito!
	MS014
	Nenhum registro foi encontrado!
3.2. Engenharia de Requisitos
Utilizamos de metodologias em que pudéssemos obter o máximo de informação possível do cliente, tivemos uma reunião com o cliente para que tivéssemos uma ideia abrangente de suas principais necessidades, logo após a reunião, pudemos nos reunir com a equipe e assim fizemos algumas observações. Após isso iniciamos outra reunião com o cliente para tirarmos nossas dúvidas a cerca de suas necessidades, concluindo esta etapa demos inicio no processo de criação de todo o sistema.
3.3. Modelagem gráfica
3.3.1. Diagramas estruturais
· De Classe: Este diagrama é fundamental e o mais utilizado na UML e serve de apoio aos outros diagramas. O Diagrama de Classe mostra o conjunto de classes com seus atributos e métodos e os relacionamentos entre classes.
· De Objeto: O diagrama de objeto está relacionado com o diagrama de classes e, é praticamente um complemento dele. Fornece uma visão dos valores armazenados pelos objetos de um Diagrama de Classe em um determinado momento da execução do processo do software.
· De Componentes: Está associado à linguagem de programação e tem por finalidade indicar os componentes do software e seus relacionamentos.
· De implantação: Determina as necessidades de hardware e características físicas do Sistema.
· De Pacotes: Representa os subsistemas englobados de forma a determinar partes que o compõem.
· De Estrutura: Descreve a estrutura interna de um classificador.
3.3.2. Diagramas comportamentais
· De caso de uso: Geral e informal para fases de levantamento e análise de Requisitos do sistema.
· De máquina de Estados: Procura acompanhar as mudanças sofridas por um objeto dentro de um processo.
· De Atividades: Descreve os passos a serem percorridos para a conclusão de uma atividade.
· De Interação: Dividem-se em:
1. De Sequência: Descreve a ordem temporal em que as mensagens são trocadas entre os objetos.
2. Geral interação: Variação dos diagramas de atividades que fornece visãogeral dentro do sistema ou processo do negócio.
3. De comunicação: Associado ao diagrama de Sequência, complementando-o e concentrando-se em como os objetos estão vinculados.
4. De tempo: Descreve a mudança de estado ou condição de uma instância de uma classe ou seu papel durante o tempo.
(INFOESCOLA).
3.3.3. Lista de caso de uso
	USC001
	Identificação
	USC002
	Examinar Aluno
	USC003
	Examinar Empresa
	USC004
	Examinar Professor
	USC005
	Consultar Nota
	USC006
	Cadastrar Professor
	USC007
	Atualizar Professor
	USC008
	Excluir Professor
	USC009
	Cadastrar Empresa
	USC010
	Excluir Empresa
	USC011
	Atualizar Empresa
	USC012
	Cadastrar Notas
	USC013
	Atualizar Notas
	USC014
	Consultar Faltas
	USC015
	Atualizar Faltas
	USC016
	Cadastrar Faltas
	USC017
	Examinar Aluno
	USC018
	Cadastrar Aluno
	USC019
	Atualizar Aluno
	USC020
	Excluir Aluno
	USC021
	Cadastrar nota
3.3.4. Tabela de relação de atores/processos
	Caso de uso
	Descrição
	Aluno
	Examinar nota
	
	Examinar falta
	Professor
	Examinar nota
	
	Examinar falta
	
	Cadastrar nota
	
	Cadastrar falta
	
	Examinar aluno
	
	Atualizar professor
	Administrador
	Examinar nota
	
	Examinar falta
	
	Cadastrar falta
	
	Cadastrar nota
	
	Examinar aluno
	
	Atualizar professor
	
	Cadastrar professor
	
	Excluir professor
	
	Examinar Professor
	
	Cadastrar aluno
	
	Excluir aluno
	
	Atualizar aluno
	
	Cadastrar empresa
	
	Atualizar empresa
	
	Excluir empresa
	
	Examinar empresa
3.4. Prototipação
Figura 1: tela de cadastro do aluno
Figura 2: tela de cadastro do professor
Figura 3: lista de alunos
Figura 4: lista de professores
Figura 5: tela de cadastro de empresa
Figura 6: lista de empresas
Figura 7: tela de login aluno/professor
Figura 8: tela de login empresas
4. Documento de Requisitos
4.1. Modelagem
4.2. Protótipos 
Para o desenvolvimento do diagrama de classe e o diagrama de uso foi utilizado o ArgoUML (ArgoUML é uma ferramenta UML open source para modelar o desenho de software de computador), para a criação do MER (Modelo Entidade Relacionamento) foi utilizado o workbench e na criação de protótipos de tela foi utilizado programas de edição de imagens (PaintTool SAI e Photoshop).
5. Conclusão
De acordo com tudo feito foi concluído que a utilização de modelos padrões para criação e implementação do projeto facilita o desenvolvimento do mesmo. Sendo assim atendendo as especificações do cliente de acordo com o planejado no início, sendo assim, se o cliente utilizar dessa ferramenta ficará mais fácil de se organizar todos os jovens, professores e empresas.
6. Bibliografia
http://rederequisitos.com.br/o-que-sao-requisitos-e-requisitos-de-software/#:~:text=1-Requisitos%20do%20Negócio%3A%20descrevem,com%20os%20objetivos%20estratégicos%2C%20etc.
https://www.infoescola.com/engenharia-de-software/uml/.
MACORATTI, J. C. UML - Unified Modeling Language e Visual Modeler. Disponível em: http://www.macoratti.net/uml_vb.htm. Acesso em: 12 maio. 2021. 
MIKE. Unified Modeling Language TM (UML®) Resource Page. Disponível em: 
http://www.uml.org/. Acesso em: 13 maio. 2021. 
VARGAS, T. C. DE S. A história de UML e seus diagramas.
Disponível em: https://niltonfelipe.files.wordpress.com/2013/08/tx-ms-02-uml-historia.pdf. Acesso em: 13 maio. 2021.
7. Ficha de Atividades Práticas Supervisionadas
NOME:_______________________________________________________________________________________TURMA: ________________________RA:__________________________
CURSO:___________________________________________________CAMPUS:_________________________________SEMESTRE:____________TURNO:___________________________
CÓDIGO DA ATIVIDADE:________________________________________SEMESTRE:_____________________________ANO GRADE:____________________________________________
DATA DA 
ATIVIDADE
DESCRIÇÃO DA ATIVIDADE
(1) Horas atribuídas de acordo com o regulamento das Atividades Práticas Supervisionadas do curso.
TOTAL DE HORAS ATRIBUÍDAS:___________________________
AVALIAÇÃO:__________________________________________
NOTA:______________________
DATA:_____/______/__________
CARIMBO E ASSINATURA DO COORDENADOR DO CURSO
FICHA DAS ATIVIDADES PRÁTICAS SUPERVISIONADAS - APS
ASSINATURA DO ALUNO
HORAS 
ATRIBUÍDAS (1)
ASSINATURA DO PROFESSOR
_______________________________________________________________
TOTAL DE 
HORAS
Aprovado ou Reprovado