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 unite patients
in need of care with trained doctors thus leaving hospitals and public health systems only for
urgent cases and need for physical care. Based on the elaboration of the disciplines studied in
the two months, entrepreneurship, project management software, quality management and
object-oriented systems design, with the integration of these four materials generated a
functional and safe system to guide and monitor patients who needed quick consultations or
continuous medical monitoring. The research method used was that of bibliographic research
in works by authors understood 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.
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
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.
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)

 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:
  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).

 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.
‘
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).
 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.
  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)

 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)

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.
 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.
 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.
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.
 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.