PIMVII

Prévia do material em texto

UNIVERSIDADE PAULISTA - UNIP EaD
Projeto Integrado Multidisciplinar
Curso Superior de Tecnologia em
Análise e Desenvolvimento de Sistemas
MÁRIO SÉRGIO LIMA CRAVEIRO - 2283999
MEZZOFANI PEREIRA DE OLIVEIRA - 0612201
CONSTRUÇÃO DE MARKETPLACE
PICUÍ-PB
2023
RESUMO
Este trabalho busca, em seu cerne, utilizar o conteúdo aprendido nas disciplinas de
Empreendedorismo, Gerenciamento de Projeto de Software, Gestão da Qualidade e
Projeto de Sistemas Orientado a Objetos do Cursos Superior de Tecnologia em Análise e
Desenvolvimento de Sistemas. Neste sentido, cria-se um cenário hipotético onde
administra-se um projeto de uma empresa de software cujo objetivo é a construção de um
Marketplace APP/WEB. Para isso, com auxílio da ferramenta StarUML, cria-se diagramas
para apoiar o desenvolvimento do projeto, elabora-se o Termo de Abertura do Projeto
(TAP), o documento que formaliza a inicialização do projeto. Por fim, para embasar ainda
mais a startup do cenário criado, constrói-se o Plano de Negócios com seus respectivos
elementos.
Palavras-chave: Marketplace. StarUML. Diagramas. TAP. Plano de Negócios.
ABSTRACT
This work seeks, at its core, to use the content learned in the subjects of
Entrepreneurship, Software Project Management, Quality Management and
Object-Oriented Systems Design of the Higher Technology Courses in Systems Analysis
and Development. In this sense, a hypothetical scenario is created where a project of a
software company is managed whose objective is to build an APP/WEB Marketplace. To
do this, with the help of the StarUML tool, diagrams are created to support the
development of the project, the Project Opening Term (TAP) is created, the document that
formalizes the initiation of the project. Finally, to further support the startup in the created
scenario, the Business Plan is created with its respective elements.
Keywords: Marketplace. StarUML. Diagrams. TAP. Business plan.
SUMÁRIO
1. 1.0 INTRODUÇÃO…………………………………………………………………………5
2. 2.0 CONTEXTO E CASO HIPOTÉTICO…….………………………………………….6
3. 3.0 METODOLOGIA MPS.br………………….………………………………………….6
4. 4.0 DIAGRAMAÇÃO…………….…………………………………………………..…….8
5. 4.1 REQUISITOS E REGRAS………....………………………………………………...8
6. 4.2 DIAGRAMA DE CASO DE USO……...…………………………………………….9
7. 4.3 DIAGRAMA DE CLASSES……………..……………………………………….….11
8. 4.4 DIAGRAMAS DE SEQUÊNCIA E DE ATIVIDADES…………………………….12
9. 4.5 DIAGRAMA DE COMPONENTES E IMPLANTAÇÃO..………………………...14
10. 5.0 PLANO DE NEGÓCIOS…………………………………………………………...16
11. 6.0 TERMO DE ABERTURA DO PROJETO………………………………………….19
12. 9.0 CONCLUSÃO………………………………………………………………………..28
13. 10.0 REFERÊNCIAS…………………………………………………………………….29
5
1.0 INTRODUÇÃO
A evolução tecnológica alcança as mais diversas áreas da vida cotidiana, inclusive
e, talvez principalmente, as relações de consumo. Nesse contexto, como uma resposta
natural às novas demandas, o mercado obriga-se a criar novas soluções inovadoras.
Assim, seguindo esse pensamento, surge a ideia de Marketplaces, uma plataforma online
focada em compra e venda de produtos que pode ser acessada em diversos aparelhos.
A partir do exposto, neste trabalho, Projeto Integrado Multidisciplinar (PIM) VII,
onde o objeto de estudo era uma empresa fictícia de software e seu projeto de construção
de um Marketplace, concentrou-se na elaboração do Termo de Abertura do Projeto, do
Plano de Negócios, de diversos diagramas na linguagem UML e na escolha de uma
metodologia adequada frente às Normas Internacionais. Esse esforço é explicado quando
entende-se que o PIM VII marca o fim das disciplinas de Empreendedorismo,
Gerenciamento de Projeto de Software, Gestão da Qualidade e Projeto de Sistemas
Orientado a Objetos.
Assim, na busca da objetividade da exposição dos conhecimentos adquiridos nas
disciplinas, cria-se, no cenário hipotético, a empresa M&M Soluções Tecnológicas. Com
este intuito, propõe-se que a organização só realize projetos de construção de
Marketplaces, afinal, é o objeto destaque da pesquisa e também possui demanda que
justifique a exclusividade do serviço.
6
2.0 CONTEXTO E CASO HIPOTÉTICO
A fim de contextualizar o cenário em que este projeto se alicerçará, informa-se os
seguintes dados da empresa desenvolvedora do software:
Nome da Empresa M&M Soluções Tecnológicas
Missão Facilitar o comércio eletrônico, proporcionando um ambiente
virtual de alta qualidade para vendedores e compradores,
promovendo eficiência, segurança e satisfação.
Visão Tornar-se a principal referência em Marketplaces online,
reconhecida pela excelência na experiência do usuário e pela
eficácia na facilitação de transações comerciais.
3.0 METODOLOGIA MPS.br
Antes de iniciar qualquer processo ligado diretamente ao desenvolvimento do
sistema, é necessário escolher uma metodologia adequada da qualidade para o
desenvolvimento de software frente às Normas Internacionais. Contudo, é importante
considerar que a empresa desenvolvedora do software possui recursos limitados e é nova
no mercado.
Sendo assim, devido essas características, entende-se que a metodologia MPS.br
é a que melhor se adequa a realidade da desenvolvedora, pois, nas palavras de
Ribeiro(2015, p. 24), essa metodologia possui “o objetivo de incentivar as pequenas e
médias empresas brasileiras de produção de software a implantar um modelo de
qualidade de melhoria de processo com custos mais acessíveis à realidade brasileira”.
No entanto, sabe-se que esta metodologia de qualidade de software possui 7(sete)
níveis de maturidade, sendo eles:
7
Figura 01 - Níveis de Maturidade
8
Fonte: SOFTEX(2021)
Assim, tendo em vista as limitações da desenvolvedora, pretende-se atingir o nível
G de maturidade, envolvendo os processos básicos e alicerçadores para desenvolvimento
de sistemas: Gerência de Projeto e a Engenharia de Requisitos.
4.0 DIAGRAMAÇÃO
4.1 REQUISITOS E REGRAS
Independente da natureza do projeto, sempre será necessário estabelecer os
requisitos funcionais, não-funcionais e as regras de negócio. Essa afirmação de natureza
atemporal é explicada quando analisa-se artefatos como: diagramas de caso de uso,
atividades, classes e outros.
A partir deste entendimento, discrimina-se:
1. Requisitos Funcionais:
a. Cadastro - o sistema deve ser capaz de realizar diferentes formas de
cadastro, principalmente: vendedores parceiros, produtos e compradores;
9
b. Visualização e Pesquisa - o marketplace deve ser capaz de fornecer aos
compradores a possibilidade de navegar em seu catálogo de produtos e,
sobretudo, visualizar os detalhes sobre cada item;
c. Carrinho - o algoritmo deve possibilitar aos compradores a capacidade de
adicionar, excluir e alterar itens em seu carrinho;
d. Compra - o sistema deve ser capaz de processar a compra, além de: I.
definir o método de pagamento; II. definir o endereço para cobrança; III.
definir o endereço para entrega; IV. calcular frete; V. discriminar valor total
da compra; VI. emitir recibo e enviar para e-mail do cliente;
e. Controle de segurança - o sistema deve garantir a segurança de todas as
transações, seja quanto aos dados das compras e métodos de pagamento,
seja quanto aos dados pessoais de compradores e vendedores;
f. Catálogo - os vendedores devem ser capaz de visualizar as vendas de seus
produtos, além de poderem alterar, adicionar ou excluir produtos dos seus
catálogos para venda.
2. Requisitos não-funcionais:
a. Segurança - o requisito não-funcional de mais alta prioridade;
b. Usabilidade - a interface deve ser intuitiva e de fácil navegação;
c. Desempenho - mesmo diante alta demanda, o sistema deve ser capaz de
manter o desempenho e estabilidade.
3. Regras do Negócio:
a. Política de Privacidade - faz-se necessário, tanto para cumprimento dos
requisitos funcionais como também para os não-funcionais, que se
estabeleça uma política de privacidade que deve ser lida por todos os
usuários. O objetivo desta política é, além de proteger os dados, informar
aos usuários como suas informações serão tratadas;
b. Política de Pagamentoe Devolução - para o enquadramento do marketplace
dentro das exigências legais e, também, para o esclarecimento aos
usuários, é essencial que se crie uma política de pagamento e devolução,
tratando de taxas e prazos.
4.2 DIAGRAMA DE CASO DE USO
10
O Diagrama de caso de uso objetiva ser representação dos aspectos externamente
observáveis de um sistema e dos elementos externos que com ele interagem (Bezerra,
2007). Assim, para a construção desse diagrama, precisa-se definir: I. o leitor; II. aspectos
observáveis.
A definição do leitor ou do público alvo do diagrama será o parâmetro que indicará
o nível de complexidade do artefato. No caso deste projeto, o público-alvo será o cliente,
pois é a ele que mais interessa os aspectos observáveis. Neste sentido, entende-se que o
cliente não necessita entender com profundidade os detalhes técnicos.
Por fim, entender os aspectos observáveis é entender os seguintes elementos do
diagrama de caso de uso:
1. Autores: Vendedores, Compradores, Administradores do Sistema e Banco de
Dados;
2. Casos de Uso: a) Catalogar Produto; b) Cadastrar Vendedor; c) Cadastrar
Comprador; d) Gerenciar carrinho; e) Definir método de pagamento; f) Finalizar
compra; f) Pesquisar catálogo; g) Gerenciar catálogo; h) Gerenciar cadastros; i)
Fazer Login; j) Validar dados; h) Armazenar dados.
Figura 02 - Diagrama de Caso de Uso
11
Fonte: Próprio autor
4.3 DIAGRAMA DE CLASSES
Diferente do Diagrama de caso de uso que, em seu cerne, objetiva a reprodução
dos aspectos externamente observáveis, o Diagrama de classes vai além e concentra-se
nas relações entre os componentes de um sistema, em outras palavras, nas relações
entre classes. Segundo as interpretações de Larman (2007), o Diagrama de classes é o
artefato principal da modelagem orientada a objetos e serve para ilustrar classes,
interfaces e suas associações. Ainda, Felisbino (2017, p. 20), ao estudar as ideais de
Larman (2007), afirma que:
[...] principal enfoque [do Diagrama de Classes] está em permitir a visualização
das classes que irão compor o sistema com seus respectivos atributos e métodos,
bem como em demonstrar como as classes do sistema se relacionam, se
complementam e transmitem informações entre si:
Assim, ao construir o Diagrama de Classes deste trabalho, procurou-se demonstrar
as principais classes que compõem o sistema de Marketplace e como elas se relacionam.
Como o resultado, observa-se a seguinte figura:
Figura 03 - Diagrama de Classes
12
Fonte: Próprio autor
4.4 DIAGRAMAS DE SEQUÊNCIA E DE ATIVIDADES
A construção do Diagrama de sequência depende, em seu alicerce, da elucidação
dos casos de usos e da criação do Diagrama de classes, pois, nos pensamentos de
Medeiros (2022), este “tem como objetivo ilustrar a interação entre os componentes de
um sistema ao realizar uma função” e, também, “ é composto basicamente por duas
partes: os objetos, que indicam quem está executando a ação, e as mensagens, que
indicam qual ação está sendo executada.”
Entende-se, portanto, que um Diagrama de sequência pode ser feito para cada
caso de uso. Entretanto, visando a objetividade, neste trabalho construiu-se Diagrama de
sequência somente para aqueles casos de uso de maior complexidade, servindo como
apoio para a equipe de desenvolvimento e programação.
Figura 04 - Diagrama de Sequência: Fazer Login
Fonte: Próprio Autor
13
Figura 05 - Diagrama de Sequência: Finalizar Compra
Fonte: Próprio Autor
Para o Diagrama de atividades, o raciocínio permanece, ou seja, deve ser feito
para caso de uso. Contudo, desta vez, preferiu-se construir o diagrama de atividades para
o cadastro de um comprador.
14
Figura 06 - Diagrama de Atividades
Fonte: Próprio Autor
4.5 DIAGRAMA DE COMPONENTES E IMPLANTAÇÃO
Ao analisar o Diagrama de Componentes, percebe-se com certa facilidade seu
objetivo voltado para a equipe de desenvolvedores e não para observadores externos,
como o diagrama de caso de uso. Ainda, “tem por finalidade indicar os componentes do
software e seus relacionamentos” (Martins, Diniz, Silva, 2017, p. 7) e “mostra os artefatos
de que os componentes são feitos, como arquivos de código fonte, bibliotecas de
programação ou tabelas de bancos de dados”. Sendo assim, propõe-se o seguinte
Diagrama de Componentes para resumir o sistema do Marketplace:
15
Figura 07 - Diagrama de Componentes
Fonte: Próprio Autor
Muito embora, quando trata-se do Diagrama de Implementação, o enfoque muda
para os hardwares do sistema, afinal, este diagrama “consiste na organização do conjunto
de elementos de um sistema para a sua execução.” (Martins, Diniz, Silva, 2017, p. 10).
Todavia, por tratar-se de um sistema de Marketplace WEB/APP, o diagrama de
implementação deste trabalho adquire um certo grau de simplicidade, como pode ser
observado na figura:
.
16
Figura 08 - Diagrama de Implementação
Fonte: Próprio Autor
5.0 PLANO DE NEGÓCIOS
O Plano de Negócios é um documento essencial para qualquer empresa, pois,
além de estruturar as noções de missão, visão e valores, também contém informações de
extrema importância para colaboradores, futuros parceiros comerciais, como: bancos e
instituições financeiras, fornecedores e, até mesmo, clientes. Neste sentido, construiu-se
o seguinte Plano de Negócios:
Figura 09 - Plano de Negócios
17
18
19
Fonte: Próprio Autor
6.0 TERMO DE ABERTURA DO PROJETO
Antes de iniciar a execução de qualquer projeto, é importante que se elabore um
Termo de Abertura do Projeto, que pode ser entendido como:
um documento que formalmente autoriza a existência de um projeto e dá ao
gerente a autoridade necessária para aplicar recursos organizacionais às
atividades a serem executadas. O principal benefício deste processo é um início e
limites bem definidos, a criação de um registro formal em forma de documento, e
uma maneira direta da direção executiva aceitar e se comprometer formalmente
com o projeto. (BENCZIK, 2021, p.14)
Em outras palavras e, em linhas gerais, o Termo de Abertura do Projeto (TAP) deve
definir os objetivos, limitações, entregas, produtos e o próprio gerente do projeto. Além
disso, a importância do TAP torna-se ainda mais visível em empresas de pequeno porte
ou recentes no mercado, pois é a partir desse artefato que potenciais patrocinadores irão
avaliar todo o escopo do projeto. Ou seja, o TAP é o primeiro contato formal do projeto
entre patrocinador e empresa e, ao mesmo tempo, entre empresa contratada e cliente.
Figura 10 - Termo de Abertura do Projeto
PROJETO PARA CONSTRUÇÃO DE MARKETPLACE ONLINE
TERMO DE ABERTURA DO PROJETO
Preparado por:
Mário Sérgio Lima Craveiro Data da Aprovação:
Mezzofani Pereira de Oliveira 25/09/2023
Nome do Projeto:
Construção de Marketplace Online para APP e WEB.
Descrição e Justificativa do Projeto:
A fim de atender as demandas do mundo contemporâneo, com inúmeros vendedores
online, propõe-se um único site para reunir produtos diversos, onde compradores
conseguiram realizar pesquisa de preços e efetuar compras de maneira segura.
20
Objetivos do Projeto:
Construir o Marketplace em seis meses (consultar cronograma de atividades e
custos);
Destacar o Marketplace em meio a concorrência presente no mercado;
Ofertar experiência diferenciada para o usuário;
Elaborar modelo eficaz de gestão de catálogo de produtos, cadastro de cliente e de
vendedores parceiros;
Garantir a segurança nas transações;
Incorporar diferentes meios de pagamento nas transações.
Cronograma de Atividades
ATIVIDADE PERÍODO ENTREGA
Levantamento de
Requisitos
Semana 01 Requisitos iniciais
Mapear
Concorrentes
Semana 01 Relatório do
benchmarking com
as principais
estratégias
adotadas pela
concorrência
Elaboração das
Especificações
Semana 02
Construção do
código-fonte
Semana 03-05 Código-fonte
construído
Construção do
protótipo de alta
fidelidade da
interface
Semana 03 Protótipo de alta
fidelidade da
interface
Aprovação do
protótipo da
interface
Semana 04 Protótipo aprovado
Construção da
Interface e definiçãoSemana 05-06 Interface construída
21
da arquitetura
Implementação da
interface
Semana 07 Interface e código
integrados
Back-End Semana 08-09 Banco de Dados
Construído
Testes (Interface,
Código e
Usabilidade)
Semana 10-14 Relatório de Bugs
Correção e
Depuração
Semana 15-16 Relatório de erros e
correções
Aprovação do
Produto Final
Semana 17 Produto final
aprovado
Finalização e
Lançamento
Semana 18 Lançamento do
Produto
Manutenção e
Acompanhamento
Semana 19-20 Relatório de uso
Matriz RACI - Papéis de Responsabilidade
ATIVIDADE GESTOR Gr. de
PROJETOS
Eq.
PROJETOS
FINANCEIRO CLIENTE
Levantamento
de Requisitos
I A R I C
Mapear
concorrentes
I A R I C
Construção do
Código-Fonte
I A R C I
Elaboração das
especificações
I A E C C
Construção do
protótipo de
I A R C I
22
alta fidelidade
da interface
Aprovação do
protótipo da
interface
N R N C A
Construção da
Interface e
definição da
arquitetura
I A R C I
Implementação
da interface
I A R C I
Back-End I A R C I
Testes
(Interface,
Código e
Usabilidade)
N A R C I
Correção e
Depuração
I A R C I
Aprovação do
Produto Final
R C N N A
Finalização e
Lançamento
R C N N A
Manutenção e
Acompanhame
nto
N A R I C
Matriz de Análise de Riscos
N° Categoria Riscos
Probabili
dade Impacto Nível Ação Responsável
23
1
Interno Alteração de
Requisitos
4 3 12 MITIGAR -
Mitigar as
alterações
possíveis no
projeto e, ao
mesmo tempo,
implementar
novos
requisitos
Gerente de
Projetos
2
Interno Atrasos devido
a complexidade
técnica
2 4 8 MITIGAR/ACE
ITAR -
Deve-se
mitigar os
impactos
causados por
esse risco e,
ainda, alterar
imediatamente
o cronograma,
comunicando
e notificando:
Cliente,
Gestores e o
setor
Financeiro
Gerente de
Projetos
3
Interno Necessidade de
ultrapassagem
significativa de
orçamento
2 5 10 EVITAR - Esse
risco deve ser
evitado,
portanto,
deve-se
realizar
recálculos
constantes
sobre os
custos da
produção.
Entretanto, em
caso de
ocorrência,
realizar
reanálise de
Financeiro
24
orçamento.
4
Externo Surgimento de
nova tecnologia
no mercado
2 5 10 APROVEITAR
- Em caso de
surgimento de
nova
tecnologia no
mercado de
marketplaces,
deve-se
aproveitar a
oportunidade e
considerar
implementar a
nova
tecnologia no
projeto.
Gerente de
Projetos e
Gestores
5
Externo Cliente desistir
do negócio
1 5 5 ACEITAR - Em
caso de
ocorrência,
deve-se
aproveitar todo
o material
construído
para projetos
futuros
Gestores
6
Interno Dificuldade em
garantir a
segurança de
transações
2 4 8 ACEITAR -
Realizar testes
de segurança
e buscar
novos meios
para
implementar
essa
tecnologia.
Aproveitar-se
de estratégias
como
benchmarking
Equipe de
Projetos
25
7
Interno Aparição de
bugs
consideráveis
após o
desenvolviment
o e lançamento
do projeto
1 5 5 MITIGAR -
Deve-se,
imediatamente
, através de
um relatório de
bugs, corrigir
os erros
Gerente de
projetos
Equipe do Projeto
Gerente do Projeto: XXXX
Analista de Sistemas: XXXX
Desenvolvedores: XXXXX
Designer UI/UX: XXXX
Especialista em Segurança:XXXXX
Orçamento do projeto
26
Prevê-se um orçamento de R$ 70.000,00
01 de Outubro de 2023,
Com a aprovação deste termo, damos início oficial ao PROJETO PARA
CONSTRUÇÃO DE MARKETPLACE ONLINE
_______________________________
XXXXX
Gerente de Projetos
______________________________
XXXXX
Cliente
______________________________
XXXXXXX
Patrocinador
Fonte: Próprio Autor
A partir da apresentação do TAP, considera-se importante para este trabalho
conceituar a metodologia de matriz de responsabilidades RACI que, consoante Santos,
Andrade, Feitosa (2020, p. 13), é uma ferramenta que “descreve o uso de diversas
funções referentes às atividades executadas em uma empresa”. Além disso, suas siglas
descrevem:
● Responsible (Responsável por executar uma atividade [o executor]);
● Accountable (Autoridade: Quem deve responder pela atividade, o dono [apenas
uma autoridade pode ser atribuída por atividade]);
● Consulted (Consultor: Quem deve ser consultado e participar de decisão ou
atividade no momento que for executada);
27
● Informed (Informado: Quem deve receber a informação de que uma atividade foi
executada)
Outro ponto que necessita de esclarecimento é o que se refere à análise de custos.
Afinal, ao considerar a natureza do TAP, entende-se que a discriminação de gastos não é
essencial no documento. Contudo, deixa-se disposto a análise orçamentária do projeto:
1. Custos de Desenvolvimento
● Desenvolvimento de Aplicativo Web: R$ 16.000,00
● Licenças e Ferramentas de Desenvolvimento: R$ 3.000,00
● Serviços de Design Gráfico: R$ 5.000,00
● Total: R$ 24.000,00
2. Custos de Infraestrutura:
● Hospedagem Web e Serviços de Cloud: R$ 2.500,00
● Registro de Domínio: R$ 200,00
● Certificado SSL: R$ 300,00
● Total: R$ 3.000,00
3. Custos com Pessoal:
● Salários da Equipe de Desenvolvimento: R$ 32.000,00
● Total: R$ 32.000,00
4. Marketing e Publicidade:
● Campanhas de Lançamento: R$ 7.000,00
● Total: R$ 7.000,00
5. Outros Custos:
● Reservas: R$ 4.000,00
● Total: R$ 4.000,00
6. Total Geral Estimado:
● R$ 70.000,00
28
7.0 CONCLUSÃO
A construção deste trabalho possibilitou, entre outros aprendizados, o exercício das
teorias práticas assimiladas no decorrer das disciplinas de Empreendedorismo,
Gerenciamento de Projeto de Software, Gestão da Qualidade e Projeto de Sistemas
Orientado a Objetos do Cursos. Além disso, quanto ao desenvolvimento do software e as
etapas da pesquisa, torna-se necessário elencar os seguintes pontos: I. A construção de
todos os Diagramas aprendidos no curso nem sempre é necessário, isto explica-se pois
alguns possuem alto grau de especificidade e sua utilidade varia bastante de acordo com
o grau de maturidade da equipe; II. O Plano de Negócios e o Termo de Abertura de
Projeto são documentos com razoável extensão e tentar resumi-los nestas poucas
páginas foi um árduo trabalho.
29
8.0 REFERÊNCIAS
ARAUJO, Rayla. MODELIGADO: GERANDO DIAGRAMAS DE SEQUÊNCIA .Disponível
em:<<http://dspace.sti.ufcg.edu.br:8080/xmlui/bitstream/handle/riufcg/29284/RAYLA%20M
EDEIROS%20ARA%C3%9AJO%20-%20TCC%20ARTIGO%20CI%C3%8ANCIA%20DA
%20COMPUTA%C3%87%C3%83O%20CEEI%202022.pdf?sequence=1&isAllowed=y>>.
Campina Grande-PB, 2022. Acesso em: 10 de Outubro de 2023
BENCZIK, Eduardo. MODELO DE TERMO DE ABERTURA PARA PROJETOS
INDUSTRIAIS.Joinville-SC, 2021. Disponível em:
<<https://repositorio.ufsc.br/bitstream/handle/123456789/228262/TCC.pdf?sequence=1&is
Allowed=y>>. Acesso em: 07 de Outubro de 2023.
BEZERRA, Eduardo. Princípios de análise e Projeto de sistemas com UML. 2. ed., Rio
de Janeiro: Elsevier, 2007.
CAMARGO, Robson. Termo de abertura de projeto: saiba tudo sobre ele. Robson
Camargo : Projetos e Negócios. Disponível em:
<https://robsoncamargo.com.br/blog/Termo-de-abertura-de-projeto-saiba-tudo-sobre-ele>.
Acesso em: 04 de Outubro de 2023.
FELISBINO, Marcio. FERRAMENTA PARA O APOIO ENSINO-APRENDIZAGEM DO
MODELO ORIENTADO A OBJETOS DURANTE A CONSTRUÇÃO DO DIAGRAMA DE
CLASSES. Curitiba - PR, 2017 Disponível em:
<<https://repositorio.utfpr.edu.br/jspui/bitstream/1/2848/1/CT_PPGCA_M_Felisbino%2c%2
0Claudio%20Marcio_2017.pdf>>. Acesso em: 10 de Outubro de 2023
MARTINS, Bonny; DINIZ, Walisson; SILVA, Rogério. A complexibilidade da UML e seus
diagramas São Paulo-SP, 2017. Disponível em:
<<https://dspace.uniceplac.edu.br/bitstream/123456789/399/1/Jayne%20Santos_0005745
_%20Andr%c3%a9ia%20Andrade_0005845_Gustavo%20Henrique%20Feitosa_0005720.
pdf>>. Acesso em: 09 de Outubro de 2023
SANTOS, Jayne; ANDRADE, Andréia; FEITOSA, Gustavo. Uma proposta para gestão
de serviços de TI e resolução de conflitos, utilizando a Biblioteca ITIL v3 integrando
a Matriz RACI. Brasília-DF, 2020. Disponível em:
<<https://dspace.uniceplac.edu.br/bitstream/123456789/399/1/Jayne%20Santos_0005745
_%20Andr%c3%a9ia%20Andrade_0005845_Gustavo%20Henrique%20Feitosa_0005720.
pdf>>. Acesso em: 09 de Outubro de 2023
https://dspace.uniceplac.edu.br/bitstream/123456789/399/1/Jayne%20Santos_0005745_%20Andr%c3%a9ia%20Andrade_0005845_Gustavo%20Henrique%20Feitosa_0005720.pdfhttps://dspace.uniceplac.edu.br/bitstream/123456789/399/1/Jayne%20Santos_0005745_%20Andr%c3%a9ia%20Andrade_0005845_Gustavo%20Henrique%20Feitosa_0005720.pdf
https://dspace.uniceplac.edu.br/bitstream/123456789/399/1/Jayne%20Santos_0005745_%20Andr%c3%a9ia%20Andrade_0005845_Gustavo%20Henrique%20Feitosa_0005720.pdf
https://dspace.uniceplac.edu.br/bitstream/123456789/399/1/Jayne%20Santos_0005745_%20Andr%c3%a9ia%20Andrade_0005845_Gustavo%20Henrique%20Feitosa_0005720.pdf
https://dspace.uniceplac.edu.br/bitstream/123456789/399/1/Jayne%20Santos_0005745_%20Andr%c3%a9ia%20Andrade_0005845_Gustavo%20Henrique%20Feitosa_0005720.pdf
https://dspace.uniceplac.edu.br/bitstream/123456789/399/1/Jayne%20Santos_0005745_%20Andr%c3%a9ia%20Andrade_0005845_Gustavo%20Henrique%20Feitosa_0005720.pdf