Você está na página 1de 21

UNIVERSIDADE PAULISTA – UNIP

LUIZ FELIPE MENDONÇA – 0580005


DANIEL SILVA MOREIRA - 0596199

PROGRAMA MEDICINA ONLINE


PROJETO INTEGRADO MULTIDISCIPLINAR VII

SÃO PAULO
2021
LUIZ FELIPE MENDONÇA - 0580005
DANIEL SILVA MOREIRA - 0596199

APLICATIVO MEDICO
PROJETO INTEGRADO MULTIDISCIPLINAR VII

Projeto Integrado Multidisciplinar – PIM VII,


apresentado como um dos pré-requisitos
para aprovação no bimestre vigente, na
graduação de Analise e Desenvolvimento
de Sistemas.

Orientador (a): Priscila Facciolli

SÃO PAULO

2021
RESUMO

O projeto teve como objetivo atender o que solicitado no projeto integrado


multidisciplinar VII (PIM VII), com o objetivo de criar um aplicativo de telemedicina
para unir pacientes necessitados de atendimento com médicos capacitados, assim,
deixando hospitais e sistemas públicos de saúde apenas para casos de emergência
e necessidade de atendimento físico. Teve como base para sua elaboração as
disciplinas estudadas no bimestre, empreendedorismo, gerenciamento de projeto
de software, gestão da qualidade e projeto de sistemas orientado a objetos, com a
integração dessas quatro matérias gerou um sistema funcional e seguro para orientar
e monitorar pacientes que necessitavam de consultas rápidas ou acompanhamento
médico continuo. O método de pesquisa usando foi o de pesquisa bibliográfica em
obras de autores entendidos no assunto em questão. Teve como principal objetivo o
desenvolvimento da parte documental do projeto em questão de modo a atender o
que solicitado pelo cliente em questão.

Palavras-chave: Sistema. Médicos. Pacientes. Desenvolvimento. Programa.


ABSTRACT

The project aimed to meet what was requested in the multidisciplinary integrated
project VII (PIM VII), with the objective of creating a a p p telemedicine system to
unitepatients in need of care with trained doctors thus leaving hospitals and public
healthsystems only for urgent cases and need for physical care. Based on the
elaboration ofthe disciplines studied in the two months, entrepreneurship, project
management software, quality management and object-oriented systems design, with
the integrationof these four materials generated a functional and safe system to guide
and monitorpatients who needed quick consultations or continuous medical
monitoring. Theresearch method used was that of bibliographic research in works by
authorsunderstood in the subject in question. Its main objective was to develop the
documentary part of the project in question in order to meet what was requested by
the client in question.

Keywords: System. Doctors. Patients. Development. Program.


Sumário
INTRODUÇÃO ..........................................................................................................................6

1 PLANO DE NEGÓCIOS ........................................................................................................7

EQUIPE ...................................................................................................................................................... 7
PRODUTOS E SERVIÇOS ......................................................................................................................... 8

2 DEFINIÇÕES DE QUALIDADE.............................................................................................9

NÍVEL DE MATURIDADE ......................................................................................................................... 10


NOSSO NÍVEL DE MATURIDADE ........................................................................................................... 10

3 OS REQUISITOS ................................................................................................................ 13

REQUISITOS FUNCIONAIS DESTE PROJETO ....................................................................................... 13


REQUISITOS NÃO FUNCIONAIS ............................................................................................................ 14
REGRAS DE NEGÓCIOS ......................................................................................................................... 14

4 TERMO DE ABERTURA .................................................................................................... 17

OBJETIVO E ESCOPO DO PROJETO PMO ......................................................................... 17


PARTES INTERESSADAS ....................................................................................................................... 17
MATRIZ DE RESPONSABILIDADES ....................................................................................................... 17
FORA DO ESCOPO.................................................................................................................................. 18
PRAZOS E ORÇAMENTOS ..................................................................................................................... 18
RISCOS INICIAIS ..................................................................................................................................... 19

5 CONCLUSÃO ..................................................................................................................... 20

REFERENCIAS ..................................................................................................................... 21
6

INTRODUÇÃO

O presente projeto terá como objetivo a documentação da parte teórica de um


aplicativo de telemedicina para auxiliar pacientes a terem o devido tratamento sem a
necessidade de consultas presenciais, assim deixando sistemas de saúde pública e
hospitais apenas para reais necessidades.

Terá como base as disciplinas de empreendedorismo, gerenciamento de


projeto de software, gestão da qualidade e projeto de sistemas orientado a objetos,
das quais empreendedorismo será responsável por documentar a parte de
desenvolvimento da startup encarregada por gerar o programa de software.
Gerenciamento de projeto de software cuidará dos cronogramas, e pela definição dos
papeis de cada integrante da equipe de desenvolvimento. Gestão da qualidade
definira a metodologia de qualidade de software adotada pela startup e a detalhará. E
por fim projeto de sistemas orientado a objetos demonstrará os requisitos e regras e
negocio adotados no projeto.

Servira como exercício da teoria estudada no bimestre nas matérias citadas


anteriormente, demonstrando de maneira pratica como surgirão os problemas durante
a programação e suas respectivas soluções no decorrer do projeto.

A metodologia adotada será a de pesquisa bibliográfica fundamentada nos


principais autores disponíveis sobre o tema em questão, para um melhor
embasamento teórico das práticas adotadas.

O resultado esperado será a entrega da documentação do projeto atendendo


as solicitações feiras pelo cliente, nesse caso a empresa farmacêutica BioFarma, com
a geração de um documento detalhado que auxiliará o entendimento do cliente e da
equipe de programação, assim, criando um programa coeso que atenda às
necessidades elicitadas.
7

1 PLANO DE NEGÓCIOS

Antes de iniciarmos nossas atividades precisamos definir nosso plano de


negócio para podermos ser uma empresa bem sucedida e atingir o crescimento
desejado.

O primeiro passo para o empreendedor é que ele precisa planejar o seu


negócio. Saltar no escuro não e exatamente uma boa pedida.
Empreendedores tendem a negligenciar o estágio de planejamento, seja pela
ansiedade em iniciar o novo negócio, seja pela descrença no instrumento ou
mesmo pela desinformação sobre como elaborar um planejamento.

Precisaremos ter definidos nossos objetivos desde o princípio, pois uma


startup (um negócio no geral) não evoluirá se não tiver objetivos a alcançar e
ultrapassar.

A startup DW.tec (Digital World.tec) terá o diferencial de oferecer ao cliente


além de um produto de software de qualidade e um suporte a altura deste produto,
uma experiencia de atendimento mais humana e com qualidade excepcional. Prezara
pelo atendimento da melhor maneira possível colocando o cliente em primeiro lugar.

O principal objetivo será o respeito a prazos e orçamentos, ou seja, o


planejamento eficiente, assim fidelizando o contratante para no futuro retornar a busca
a nossos serviços de atendimento e de desenvolvimento. O plano de negócios, é a
parte mais importante do planejamento e como citado por Biagio (2005), é o mais
completo e indispensável instrumento de planejamento para as micro e pequenas
empresas, tanto nos primeiros momentos de atividade quanto no balizamento dos
resultados depois de alguns anos de atuação no mercado.

Equipe

A equipe terá o objetivo de inovar e transmitir o conhecimento e respeito ao


cliente, sendo formada por profissionais capacitados nas áreas de tecnologia em
geral, mas também tendo como foco áreas de gestão de pessoas para gerar esta
unificação entre a tecnologia e o ser humano.

Este será o proposito desta equipe/empresa aproximar os problemas dos


clientes aos programadores assim tornando o atendimento mais direto e pessoal para
8

cada cliente. Como citado por Luiza Helena Trajano em matéria para o site e
ecommercebrasil (2018):

A empresa que não tiver propósito, equidade de gênero nem preocupação


com o social será excluída do mercado – não pelos outros varejistas, mas
pelos próprios clientes, cada vez mais preocupados com a responsabilidade
das companhias.

E como citado acima não será por sermos uma empresa nova no mercado
que está não será uma empresa modelo as demais, este tipo de planejamento já no
início do funcionamento ajudará no crescimento exponencial da empresa no futuro.

Produtos e serviços

A empresa terá em seu catalogo especialistas de software para desenvolver


aplicativos e programas únicos para cada cliente, atuando de início em áreas diversas
áreas para angariar clientes. O enfoque inicial será em aplicativos multiplataforma,
para atuar em diversos canais e sistemas de forma simultânea.
9

2 DEFINIÇÕES DE QUALIDADE

Antes mesmo de iniciar a parte de programação da empresa é necessário


definir os métodos de qualidade os quais serão seguidos para evitar o que citado por
Schach (2010) como as crises de software, onde a qualidade desses era inaceitável
e os prazos e orçamentos não eram respeitados.

Apesar de ainda uma empresa pequena de software os objetivos de


crescimento são ambiciosos, portanto, desde o início de nossas atividades já existe a
necessidade de uma metodologia de qualidade que visa esse crescimento. Faremos
o uso do método conhecido como MPS.br (Melhoria de Processo do Software
Brasileiro).

Como explicado por Silveira (2012)

O MPS. Br serve como um selo que indica o nível de maturidade da empresa


em relação às práticas relacionadas ao desenvolvimento de software. Esse
selo possui níveis. Cada nível tem diversas práticas associadas. Uma
empresa que possui o "selo" MPS. Br utiliza essas boas práticas e,
teoricamente, tem bastantes condições de desenvolver softwares com
qualidade e com custos e prazos dentro do estimado.

Como citado existem diversos níveis de maturidade de software no modelo


MPS.br como podemos ver na figura 1.

Figura 1- Níveis de maturidade do modelo MPS.br

Fonte: Livro texto (2020)


10

Os níveis no caso do MPS.br são sete e representam o nível de maturidade


da empresa que adota esse sistema de classificação, os níveis são sequencias e
dependentes entre si.

Nível de maturidade

Para um entendimento de nosso nível de maturidade atual é necessário


entender o que cada nível significa e também o porquê da existência de sete quando
os outros modelos de qualidade apresentam menos níveis para crescimento. Para
isso vamos verificar o que foi escrito no guia geral de MPS de software disponibilizado
pela SOFTEX (2012)

A divisão em 7 estágios tem o objetivo de possibilitar uma implementação e


avaliação adequada aos micros, pequenas e médias empresas. A
possibilidade de se realizar avaliações considerando mais níveis também
permite uma visibilidade dos resultados de melhoria de processos em prazos
mais curtos.

Os sete níveis de maturidade são: A (em otimização), B (gerenciado


quantitativamente), C (definido), D (largamente definido), E (parcialmente definido), F
(gerenciado) e G (parcialmente gerenciado). A escala de maturidade começa no nível
G e avança até o nível A. Cada nível possui um foco de onde a empresa deve colocar
seus esforços de melhoria.

Nosso nível de maturidade

Para evitar uma explicação muito técnica o foco será em explicar nosso nível
de maturidade atual, o nível G (parcialmente gerenciado), para tal nível é necessário
atingir alguns atributos, assim como para que no futuro haja possibilidade de evolução.

Os atributos do nível G são segundo a SOFTEX (2012);

• Atributo 1.1 – O processo é executado: esse atributo evidencia quanto o processo é


seguido.

• Atributo 2.1 – O processo é gerenciado: esse atributo evidencia quanto a execução


do processo é gerenciada com perguntas como:
11

• Existe uma política organizacional estabelecida e mantida para o processo.


• A execução do processo é planejada.
• A execução do processo é monitorada e ajustes são realizados;

Como uma empresa ainda relativamente nova, nosso nível de maturidade


ainda está se desenvolvendo, porem todas as empresas de software precisaram se
adaptar aos modelos de qualidade algum dia, assim sendo, começar essa adaptação
desde o início torna no futuro uma transição muito mais fácil até mesmo para um
modelo internacional de qualidade, visto que atualmente o modelo MPS.br apesar de
ser um modelo que abre muitas portas, como a possibilidade de desenvolver
programas para o governo brasileiro, ele ainda só é aceito em território nacional,
tornando nossa transição no futuro muito suave, se comparada com empresas já de
grande porte que para sair para o setor internacional precisam abruptamente mudar
seu modelo de qualidade para um que não tinham nenhum conhecimento prévio.

O MPS.br foi selecionado no nosso caso devido ao sua referência a diversos


modelos de qualidade internacional (figura 2), assim sendo sua base é solida e já
reconhecida aqui no brasil, além de ter sido desenvolvida justamente de maneira a
facilitar sua implantação em micro e pequenas empresas como citado anteriormente
nesse trabalho pela SOFTEX.

Figura 2- Componentes do modelo MPS.br

Fonte: MPS.BR: Guia geral MPS de software, página 14 (2012).


12

Sendo assim como nosso objetivo é um crescimento calmo e com decisões


bem pensadas, se torna a melhor escolha, além do fato de nossa empresa pelo menos
de momento não ter a intenção de sair do território nacional e sim de no futuro
desenvolver sistemas para o governo de nosso país, o qual já solicita que empresas
que trabalhem para ele tenham o selo de qualidade MPS.br.

Outro fator importante é o custo de implementação do modelo, o qual é muito


mais viável a uma empresa que está iniciando agora do que outros modelos como
CMMI ou ISSO que possuem seus custos de implementação mais elevados, o que os
torna de certa forma inviáveis ao nosso modelo de negócios atuais. Esse ponto é
reforçado por Koscianski (2007).

O MPS.BR - Melhoria de processo do Software Brasileiro [...], tem como


objetivo promover a melhoria da qualidade e da produtividade de soluções e
serviços de software de acordo com os padrões de qualidade internacional,
com custos acessíveis às empresas nacionais, principalmente as de pequeno
e médio porte. Ele está em conformidade com as normas internacionais
ISO/IEC 12207 e 15504 e é compatível com o CMMI (Capability Maturity
Model Integration), além de ser adequado à realidade das empresas
brasileiras.

13

3 OS REQUISITOS

Nesta fase, após algumas reuniões com os interessados no projeto


(funcionários, gerencia, analistas e clientes envolvidos no projeto) são gerados os
requisitos que o sistema necessitará ter para ser considerado um sucesso.

Os requisitos de um sistema segundo Sommerville (2007), tem como objetivo


definir o que o sistema deve fazer, quais as necessidades reais e identificar
quais restrições existem para que o software seja desenvolvido. É nesse
passo da engenharia de software que ocorre a comunicação entre o cliente e
a equipe de desenvolvimento.

Requisitos funcionais deste projeto

A seguir se verá uma lista das necessidades solicitadas para o programa de


consultas médicas e seus devidos acompanhamentos clínicos a pacientes, estas
necessidades serão utilizadas para os casos de uso do programa e para verificar se
os pedidos do cliente foram atendidos no decorrer do desenvolvimento do mesmo.

Requisitos funcionais (RF) descrevem o comportamento esperado de um


sistema de software, explicita o que o sistema deve fazer e idealmente o que o sistema
não deve fazer (SOMMERVILLE, 2010).

• RF01 consulta a clientes: Ao inserir e-mail e senha no site o sistema


deve ser capaz, caso possua cadastro, liberar o login do cliente e caso
contrário solicitar o cadastro do mesmo, mediante solicitação de e-mail,
senha, CPF, endereço e telefone validos.
• RF02 consulta doutores: o sistema de login será o mesmo que para
pacientes porem ao identificar e-mail e senha cadastrados na lista de
doutores do sistema o mesmo tem que ser capaz de direcionara o
médico ao sistema de atendimento ao paciente.
• RF03 consulta cortesia: o sistema ao identificar um novo CPF na base
de dados disponibilizará uma consulta gratuita de uma hora a este novo
cliente.
• RF04 pagamento: o sistema após a utilização da consulta gratuita
deve solicitar os dados de pagamento do cliente para consultas futuras
(apenas cartões de credito serão aceitos inicialmente).
14

Mediante definição dos requisitos funcionais do sistema também é necessário


a definição dos requisitos não funcionais para o correto entendimento das
necessidades antes do início da diagramação e posterior programação. Como citado
por Sommerville (2010) Requisitos não funcionais (RNF) descrevem restrições sobre
os serviços oferecidos pelo sistema de software

Requisitos não funcionais

Como citado anteriormente a seguir uma listagem dos requisitos não


funcionais apresentados nesse projeto;

• RNF01 validação: o sistema somente liberara acesso a tela de


atendimento tanto para médicos quanto para pacientes mediante login
e senhas validos.
• RNF02 jornada de trabalho: toda vez que um médico efetuar login ou
logout este será salvo em seu arquivo com data e horário para posterior
pagamento de horas de trabalho.
• RNF03 acesso: o sistema deve ser capaz de conceder privilégios
diferentes aos logins (médicos/pacientes) assim direcionando cada um
para sua respectiva área de atendimento.
• RNF04 pagamento: após a consulta gratuita o sistema só finalizará o
próximo agendamento mediante verificação do cartão de credito
apresentado, assim efetuando a cobrança da consulta no ato da
confirmação do agendamento.

Regras de negócios

As regras de negócios são um conjunto de restrições que definem como um


processo de negócio de uma organização deve ser executado, além de
representar determinados conhecimentos a respeito de um processo,
também representam importantes restrições na execução deste processo
(BUSINESS RULES GROUP, 2000).

As restrições devem estar bem definidas para assim o projeto não fugir do
escopo correto que o cliente quer que ele execute, se mantendo dentro das
expectativas e limitações impostas pelo cliente e localidade onde o sistema será
instalado para uso.
15

• Os médicos cadastrados somente serão liberados para atendimento


mediante apresentação de CRM valido e conferido no site do conselho
de medicina http://portal.cfm.org.br/
• Os médicos após cada consulta devem preencher um breve resumo da
mesma e o prontuário online que ao enceramento do vídeo chamado
será apresentado ao médico.

A seguir podemos ver de forma representativa como o documento de casos


de uso é representado e como servirá para a documentação do sistema. O arquivo
mais detalhado pode ser consultado no Link:
https://docs.google.com/document/d/1sa3JHU6uJRWdzVh_Sznlr7KrNsty8QqQEYOq
bzOMMzM/edit?usp=sharing, tal link online permite atualizações por parte de toda a
equipe e um histórico de atualizações muito importante para a documentação do
projeto.

Figura 3- Caso de uso efetuar login

Fonte: Autoria própria, ferramenta google documentos (2020)


16

A seguir a diagramação do caso de uso documentado anteriormente (o


mesmo arquivo pode ser encontrado na pasta de entrega deste projeto para uma
melhor visualização)

Figura 4 - Diagrama caso de uso login

Fonte: Autoria própria, Site app.lucidchart.com (2020)


17

4 TERMO DE ABERTURA

Objetivo e escopo do projeto PMO

Este projeto terá como objetivo desenvolver um sistema de controle que una
médicos e pacientes que necessitam de atendimento nesta época de pandemia
(COVID-19).

O sistema deverá possibilitar acesso e comunicação de pacientes e médicos


(com CRM valida e ativa) tendo a capacidade de agendar consultas com especialistas,
assim deixando hospitais menos lotados e evitando tumultos. Médicos terão acesso a
um prontuário exclusivo para cada paciente que poderá ser preenchido durante a
consulta e acessado por outros profissionais caso o cliente desejar uma segunda
opinião.

O sistema terá uma consulta gratuita de uma hora por usuário cadastrado,
após esta consulta o sistema deve solicitar um cartão de credito para cobrar o valor
simbólico de R$10,00 por hora (a consulta será de uma hora no máximo) este valor
será apenas para manutenção e pagamento dos profissionais.

Partes interessadas

O principal interessado em nosso projeto, será nosso contratante a empresa


farmacêutica BioFarma que está em ascensão na atual situação do país e quer entrar
no mercado de telemedicina. Por parte da empresa teremos a participação do CEO
(Fabrino Garcia), seu médico chefe (Doutor Charles Silva), os quais serão
responsáveis por supervisionar e aprovar ideias e projetos da nossa equipe de
desenvolvimento e programação.

Matriz de responsabilidades

A seguir uma divisão das responsabilidades por parte da equipe no


desenvolvimento deste projeto. Esta divisão será apresentada na primeira reunião de
equipe deixando claro o papel desempenhado por todos os envolvidos.
18

Figura 5 - Matriz de responsabilidade

Fonte: Autoria própria (baseado no livro texto 2020)

Fora do escopo

O sistema não precisará fornecer a feramente de vídeo conferencia apenas o


sistema de login, agendamento e organização de prontuários online. Tal ferramenta
em decisão mutua será terceirizada, utilizando a feramente gratuita da gigante da
comunicação Google, o hangouts, pela segurança oferecida e por todo usuário o qual
se cadastrarem em nosso sistema necessitam ter um e-mail valido o acesso a
ferramenta em questão é quase certo.

Mesmo assim o sistema terá tutoriais e abas de ajuda para usuários mais
inexperientes ou com dúvidas de como proceder para realizar a consulta online.

Prazos e orçamentos

Devido a urgência da situação atual do país o prazo deste projeto será muito
reduzido. Tal tem um limite máximo de entrega de 2 meses com orçamento de
R$10000,00 iniciais. Com um pagamento inicial de 50% e nas cinco últimas semanas
do projeto durante reuniões de avanço pagamentos parciais de 10% por
semana/reunião.

Após a publicação do sistema como forma de incentivo e para manter um


suporte impecável, em contrato foi estabelecido uma participação de nossa empresa
de 1% da receita gerada pelo programa. Assim quanto mais usuários utilizarem o
sistema mais suporte será necessário consequentemente nossa empresa recebera
um valor exponencial assim ficando justo para ambas as partes.
19

Riscos iniciais

Segundo Fontoura e Priceeng (2004)

O controle de risco abrange as atividades que tratam da solução do risco.


Controle de risco é o processo de elaborar planos de resolução de riscos,
monitorar o status do risco, implementar planos de resolução de riscos, e
corrigir desvios do plano

Devido a urgência, o prazo é algo a se levar em consideração neste projeto,


apesar de ser um programa que provavelmente permanecerá pós pandemia seu
lançamento nesta faze crucial não só alavancará sua disseminação como ajudará na
contenção do avanço da pandemia.

Além disso a inexperiência da equipe com um projeto desta magnitude


também não pode ser deixada de lado, mas para evitar uma mancha na reputação de
nossa empresa consultorias externas serão realizadas caso necessário. Tais
consultorias ficaram como custo de nossa empresa de software já que o conhecimento
trazido por consultores será usado em diversos projetos não somente nesse em
questão.
20

5 CONCLUSÃO

O presente projeto teve como objetivo a documentação da parte teórica de


um sistema de telemedicina para auxiliar pacientes a terem o devido tratamento sem
a necessidade de consultas presenciais, assim deixando sistemas de saúde pública e
hospitais apenas para reais necessidades.

Teve como base as disciplinas de empreendedorismo, gerenciamento de


projeto de software, gestão da qualidade e projeto de sistemas orientado a objetos,
das quais empreendedorismo foi responsável por documentar a parte de
desenvolvimento da startup encarregada por gerar o programa de software.
Gerenciamento de projeto de software cuidou dos cronogramas, e das definições dos
papeis de cada integrante da equipe de desenvolvimento. Gestão da qualidade definiu
a metodologia de qualidade de software adotada pela startup e a detalhou. E por fim
projeto de sistemas orientado a objetos demonstrou os requisitos e regras de negócio
adotados no projeto.

Serviu como exercício da teoria estudada no bimestre nas matérias citadas


anteriormente, demonstrando de maneira pratica como surgirão os problemas durante
a programação e suas respectivas soluções no decorrer do projeto.

A metodologia adotada foi a de pesquisa bibliográfica fundamentada nos


principais autores disponíveis sobre o tema em questão, para um melhor
embasamento teórico das práticas adotadas.

O resultado foi a entrega da documentação do projeto atendendo as


solicitações feitas pelo cliente, nesse caso a empresa farmacêutica BioFarma, com a
geração de um documento detalhado que auxiliou o entendimento do cliente e da
equipe de programação, assim, possibilitando o início das fazes de desenvolvimento
e entrega das necessidades elicitadas.

Conforme detalhado nesse trabalho o projeto em questão foi realizado e


concluído com êxito, assim concluindo seu objetivo de detalhar de maneira
documental como os requisitos e regras foram desenvolvidas teoricamente, sendo
assim a parte documental que era parte única e fundamental desse trabalho encontra-
se concluída apresentando o que solicitado no projeto integrado multidisciplinar VII.
21

REFERENCIAS

BIAGIO, L. Plano de negócios: estratégia para micro e pequenas empresas.


Barueri: Manole, 2005.

BUSINESS RULES GROUP. Defining business rules: what are they really? 2000.
Disponível em: http://www.businessrulesgroup.org/first_paper/BRG-
whatisBR_3ed.pdf Acesso em: 30 de set. de 2020.

CHIAVENATO, I. Empreendedorismo: dando asas ao espirito empreendedor. São


Paulo: Saraiva: 2008.

ECOMMERCEBRASIL. Para Luiza Trajano, do magazine Luiza, ‘o cliente é um só’.


Disponível em: https://www.ecommercebrasil.com.br/noticias/magazine-luiza-cliente-
um-so/. Acessado em: 21 e setembro, 2020.

FONTOURA, Lisandra M.; PRICEENG, Roberto. Usando GQM para Gerenciar


Riscos em Projetos de Software. Universidade Federal do Rio Grande do Sul.
2004.

KOSCIANSKI, André; SOARES, Michel dos Santos. Qualidade de Software.1. Ed.


Novatec. 2007.

SCHACH, Stephen R. Engenharia de software: os paradigmas clássicos e


orientados a objeto. 7. Ed. Porto Alegre. AMGH. 2010.

SILVEIRA, Arthur Rafael da. O que é o MPS.br? Oficina da net. 2012. Disponível
em: https://www.oficinadanet.com.br/artigo/desenvolvimento/melhoria-de-processos-
do-software-brasileiro--mpsbr. Acessado em 30 de set. de 2020.

SOFTEX. MPS.BR: Guia geral MPS de software. 2012. Disponível em;


https://www.softex.br/wp-
content/uploads/2013/07/MPS.BR_Guia_Geral_Software_2012-c-ISBN-1.pdf
Acessado em 30 de set. de 2020.

SOMMERVILLE, Ian. Engenharia de software, 9ª ed São Paulo: Pearson Addison-


Wesley. 2010.

SOMMERVILLE, Ian. Engenharia de Software. 8ª ed. São Paulo: Pearson Addison-


Wesley, 2007.

Você também pode gostar