PROJETO INTEGRADO MULTIDISCIPLINAR IV

Prévia do material em texto

UNIVERSIDADE PAULISTA – UNIP EaD 
Projeto Integrado Multidisciplinar 
 
Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas 
 
Sara Braga Nogueira – RA 2243249 
Ian Vinicius Gonçalves de Marins – RA 2243243 
 
 
 
 
 
 
 
PROJETO INTEGRADO MULTIDISCIPLINAR IV 
 
 
 
 
 
 
UNIP EaD Polo República - Metrô República 
2023 
 
 
 
 
Sara Braga Nogueira – RA 2243249 
Ian Vinicius Gonçalves de Marins – RA 2243243 
 
 
 
 
PROJETO INTEGRADO MULTIDISCIPLINAR IV 
Projeto Integrado Multidisciplinar em 
Análise e Desenvolvimento de Projetos 
 
 
 
 
 
 
Projeto Integrado Multidisciplinar para obtenção do título de tecnólogo em 
Análise e Desenvolvimento de Sistemas, apresentado à Universidade Paulista – 
UNIP EaD. 
 
 
 
UNIP EaD Polo República - Metrô República 
2023 
 
 
 
 
RESUMO 
Neste projeto, será realizado um levantamento e análise dos requisitos 
necessários para o desenvolvimento de um software de controle e gestão de vendas 
voltado para jogos e produtos da cultura geek. Essa análise servirá como base para a 
criação de documentos essenciais na implementação do software, que será utilizado 
na loja. 
Os documentos gerados durante este projeto incluirão modelos de casos de 
uso, requisitos funcionais e não funcionais, diagramas de classes e modelos de dados 
(MER). Isso nos permitirá aplicar de forma prática todo o conhecimento adquirido ao 
longo deste semestre nas disciplinas de Análise de Sistemas Orientados ao Objeto, 
Banco de Dados e Gestão Estratégica de Recursos Humanos. 
Ao concluir este trabalho, ficou evidente que compreender os processos de 
uma empresa é fundamental para a definição de requisitos que conduzam à 
implementação de um software capaz de atender verdadeiramente às necessidades 
do cliente. 
 
Palavras-chave: Análise de Requisitos; Jogos; Loja Virtual; Modelo Entidade-
Relacionamento (MER); Software de Gerenciamento. 
 
 
 
 
 
 
 
 
ABSTRAC 
 In this project, a survey and analysis of the requirements necessary for the 
development of sales control and management software focused on games and geek 
culture products will be conducted. This analysis will serve as the foundation for 
creating essential documents in the software implementation process, which will be 
used in the store. 
The documents generated during this project will include use case models, 
functional and non-functional requirements, class diagrams, and Entity-Relationship 
(ER) data models. This will allow us to practically apply all the knowledge acquired 
throughout this semester in the Object-Oriented Systems Analysis, Database, and 
Strategic Human Resources Management courses. 
 Upon completing this work, it became evident that understanding a company's 
processes is essential for defining requirements that lead to the implementation of 
software capable of truly meeting the customer's needs. 
 
Keywords: Requirements Analysis; Games; Virtual Store; Entity-Relationship Model 
(ER); Management Software. 
 
 
 
 
 
 
 
 
Sumário 
 
1. Introdução .................................................................................................................................... 6 
2. Funções do negócio .................................................................................................................. 7 
3. Soluções disponíveis ................................................................................................................ 7 
4. Automatizações........................................................................................................................... 9 
5. Modelo de casos de uso ......................................................................................................... 10 
6. Requisitos não funcionais ..................................................................................................... 17 
7. Contexto de utilização ............................................................................................................. 19 
8. Regras de negócio ................................................................................................................... 20 
Conclusão .......................................................................................................................................... 23 
Referência .......................................................................................................................................... 25 
 
 
6 
 
 
 
1. Introdução 
Entender o que o cliente quer ou acredita que precisa, bem como as regras 
ou processos de negócios, é o cerne que impulsiona essa função vital que faz parte 
da engenharia de requisitos para o grupo. Esta é uma das partes mais significativas 
do processo que resultará no desenvolvimento de um sistema para o grupo. Além 
disso, há o mapeamento de processos, fundamental para a melhoria dos resultados 
do grupo. Muitos sistemas falham ao longo de sua jornada porque a fase de coleta de 
requisitos é ignorada ou executada de forma ineficiente pelo grupo. 
Uma investigação baseada em 5.400 sistemas desenvolvidos em 1999 
revelou que os custos incorridos como consequência da primeira implementação da 
fase de levantamento de requisitos podem fazer com que os sistemas custem até dez 
vezes o necessário para o grupo. E quão bons são esses sistemas? Preços altos não 
implicam alta qualidade para o grupo. Para desenvolver sistemas profissionais e de 
alta qualidade, é necessário atender aos requisitos de forma eficiente e metódica pelo 
grupo. É necessário contar com profissionais qualificados de acordo com as 
necessidades específicas de cada projeto do grupo. 
O grupo acredita firmemente na importância da avaliação de processos, 
mapeamento e melhoria dos processos de negócios. Neste estudo, o grupo concluirá 
a importância desses processos, bem como sua eficiência na gestão do 
desenvolvimento de software pelo grupo. 
 
7 
 
 
 
2. Funções do negócio 
As Funções de Negócios são estruturas conceituais que fornecem uma 
descrição da missão de uma organização e têm a capacidade de manter sua 
estabilidade ao longo do tempo, mesmo quando a empresa passa por 
reorganizações. 
Pode-se definir uma função como uma sequência de atividades inter-
relacionadas que envolvem uma ou mais entidades de dados e são executadas com 
o propósito de alcançar um ou mais objetivos empresariais. Estes objetivos podem 
variar desde a geração de resultados financeiros específicos até a satisfação das 
necessidades dos clientes da empresa, passando pela criação de produtos e serviços 
destinados à comercialização ou pela geração de receita. 
 
3. Soluções disponíveis 
Os sistemas modernos apresentam uma abordagem mais generalista, onde 
um único sistema de gestão de loja pode ser adaptado para atender a uma ampla 
variedade de tipos de negócios. Isso permite que os desenvolvedores concentrem 
seus esforços tecnológicos em um único aplicativo, o que resulta em entregas de 
soluções mais rápidas e na capacidade de desenvolver novas funcionalidades com 
agilidade. 
Diversas empresas oferecem soluções prontas para atender às necessidades 
da UNIGEEP. Essas soluções variam em termos de linguagem de programação 
utilizada, disponibilidade do aplicativo (local ou na nuvem) e capacidade de integração 
com outras aplicações. Todas as soluções pesquisadas oferecem planos mensais 
que variam de básicos a avançados, com os preços sendo influenciados pela 
quantidade de funcionalidades desejadas. Além disso, os valores podem variar com 
base na duração do contrato, com opções de planos anuais. 
Para enfrentar uma situação como a apresentada pela UNIGEEP, é essencial 
não apenas atender aos requisitos funcionais e não funcionais do software, mas 
também realizar uma análise competitiva. Essa análise não apenas permite que os 
gestores compreendam melhor o panorama demercado e adotem práticas saudáveis 
e éticas para competir nos negócios, mas também oferece oportunidades de 
aprendizado com os concorrentes. Esta pesquisa nos auxiliará a determinar se é 
8 
 
 
 
economicamente viável desenvolver um novo software para um aplicativo que já é 
popular e tem diversos fornecedores no mercado. 
 
Figura 1 - TagPlus - Fonte: tagplus.com.br 
 
Figura 2 – Eleve - Fonte: elevesuasvendas.com.br 
9 
 
 
 
 
Figura 3 – GestãoClick - Fonte: gestaoclick.com.br 
 
Figura 4 – Nex - Fonte: programanex.com.br 
 
4. Automatizações 
Como se determina quais procedimentos podem ser automatizados? 
Gestores que enxergam adiante, antecipando o momento em que os procedimentos 
serão automatizados e todas as dificuldades serão abordadas. A automação de 
processos é, de fato, a chave para o sucesso? 
10 
 
 
 
A automação de processos faz uso de tecnologia especializada e integração 
de dados e sistemas para executar os processos conforme foram originalmente 
concebidos. Isso resulta na redução do risco de erros, na otimização da execução 
dos processos e na capacidade de monitorar o desempenho em tempo real, 
permitindo decisões mais eficazes. Além disso, garante a conformidade com as 
regras e o cumprimento de prazos, oferecendo uma série de outros benefícios. A 
automação vai além do âmbito virtual, possibilitando a integração de diversos 
participantes, como colaboradores, clientes e parceiros de negócios, que podem 
interagir via Internet ou Extranet, utilizando e-mails, sistemas ou portais e uma 
variedade de dispositivos, incluindo computadores tradicionais, smartphones e 
tablets, viabilizando a interação remota e à distância. 
As primeiras operações a serem automatizadas incluem o envio de e-mails 
sobre mercadorias em falta no estoque, notificações aos clientes sobre a 
disponibilidade de produtos reservados e campanhas de e-mail marketing com 
produtos relacionados às compras anteriores dos clientes. 
 
5. Modelo de casos de uso 
Com base na identificação dos casos de uso, foram desenvolvidos os modelos 
correspondentes para cada um, como descrito a seguir: 
Identificação: Consulta de Produtos 
Escopo: Seleção de Produto 
Descrição: 
Este caso de uso permite ao cliente, com a assistência 
de um atendente, acessar a página do produto 
desejado. 
Ator: Cliente, Atendente 
11 
 
 
 
Interessados: Cliente, Atendente e Loja 
Pré-requisitos: O atendente deve estar autenticado no sistema. 
Pós-condição: 
Tanto o atendente quanto o cliente selecionam o 
produto desejado. 
Fluxo normal: 
1. O sistema realiza uma consulta aos produtos no 
sistema de controle de vendas da loja. 
2. O sistema exibe na tela os produtos encontrados. 
Requisitos relacionados: RQNF02 – Disponibilidade do Sistema 
 
Identificação: Filtragem de Consulta de Produtos 
Escopo: Seleção de Produto 
Descrição: 
Este caso de uso permite ao cliente, com a 
assistência de um atendente, realizar uma pesquisa 
específica de produtos com base em características 
como categoria, gênero, fabricante, entre outros. 
Ator: Cliente, Atendente 
Interessados: Cliente, Atendente e Loja 
Pré-requisitos: 
Tanto o atendente quanto o cliente devem ter o 
resultado da consulta disponível. 
12 
 
 
 
Pós-condição: 
1. O Atendente/Cliente fornece dados em pelo 
menos um dos campos de consulta e aciona o 
botão de pesquisa. 
2. O sistema utiliza os dados fornecidos para buscar 
correspondências na base de dados do sistema. 
3. O sistema exibe na tela os resultados da consulta. 
Fluxo normal: 
1. Se o botão de pesquisa for acionado sem que 
nenhum dado de busca seja informado, o sistema 
exibirá mensagens solicitando que pelo menos 
um dado de busca seja inserido. 
2. Se o sistema não encontrar nenhum produto com 
base nos dados fornecidos, serão exibidas 
mensagens informando que não há produtos com 
essas características no sistema. 
Requisitos relacionados: RQNF02 - Disponibilidade do Sistema 
 
Identificação: Adição ao Carrinho de Compras 
Escopo: Escolha de Produto 
Descrição: 
Este caso de uso permite que o Cliente ou Atendente 
inclua produtos no carrinho de compras, com a 
finalidade de posteriormente concluir a compra. 
Ator: Cliente, Atendente 
Interessados: Cliente, Atendente e Loja 
13 
 
 
 
Pré-requisitos: 
O Atendente deve estar autenticado no sistema, e o 
carrinho de compras deve estar vazio. 
Pós-condição: 
O carrinho de compras contém os produtos 
selecionados. 
Fluxo normal: 
1. O Cliente ou Atendente clica no botão "Detalhes 
do Produto". 
2. O sistema redireciona para a página com os 
detalhes do produto. 
3. O Cliente ou Atendente clica no botão "Adicionar 
ao Carrinho". 
4. O sistema armazena as informações na tabela de 
transição do carrinho de compras. 
Requisitos relacionados: RQNF02 - Disponibilidade do Sistema 
 
Identificação: Remoção do Carrinho de Compras 
Escopo: Escolha de Produto 
Descrição: 
Este caso de uso permite ao Cliente ou Atendente 
remover produtos do carrinho de compras, 
possibilitando a finalização da compra apenas com os 
produtos desejados. 
Ator: Cliente, Atendente 
Interessados: Cliente, Atendente e Loja 
14 
 
 
 
Pré-requisitos: O Atendente deve estar autenticado no sistema. 
Pós-condição: 
O carrinho de compras será atualizado com os 
produtos selecionados. 
Fluxo normal: 
1. O Cliente ou Atendente acessa o carrinho de 
compras. 
2. O Cliente ou Atendente clica no botão "Remover" 
ao lado da descrição do produto que deseja 
remover do carrinho. 
3. O sistema recalcula o valor total da compra e 
exibe o resultado na tela. 
Requisitos relacionados: RQNF02 - Disponibilidade do Sistema 
 
Identificação: Concluir Compra 
Escopo: Efetivação da Compra 
Descrição: 
Este caso de uso permite ao Cliente ou Atendente 
finalizar a aquisição dos produtos e, se necessário, 
fazer reservas de itens indisponíveis. 
Ator: Cliente, Atendente 
Interessados: Cliente, Atendente e Loja 
15 
 
 
 
Pré-requisitos: 
O carrinho de compras deve conter pelo menos um 
item. 
Pós-condição: 
O Cliente ou Atendente completa com sucesso o 
processo de compra ou, se aplicável, reserva 
produtos indisponíveis. 
Fluxo normal: 
1. O Cliente ou Atendente especifica a quantidade 
desejada de cada produto a ser adquirido. 
2. O Cliente ou Atendente clica no botão "Concluir 
Compra". 
Requisitos relacionados: 
RQNF02 - Disponibilidade do Sistema; RQNF03 - 
Disponibilidade da Operadora de Cartões. 
 
Identificação: Efetuar Reserva de Produto 
Escopo: Efetivação da Compra 
Descrição: 
Este caso de uso permite ao Cliente ou Atendente 
reservar produtos quando eles não estão disponíveis. 
Ator: Cliente, Atendente 
Interessados: Cliente, Atendente, Loja e Operadora 
Pré-requisitos: Deve haver produtos no carrinho de compras. 
16 
 
 
 
Pós-condição: A reserva do produto é concluída com sucesso. 
Fluxo normal: 
1. O Cliente ou Atendente clica no botão "Efetuar 
Reserva de Produto". 
2. O sistema realiza a reserva do produto, 
registrando a quantidade e associando-a aos 
dados cadastrais do Cliente. 
Requisitos relacionados: 
RQNF02 - Disponibilidade do Sistema; RQNF03 - 
Disponibilidade da Operadora de Cartões. 
 
Identificação: Submissão de Dados do Cartão 
Escopo: Efetivação da Compra 
Descrição: 
Este caso de uso permite que os dados do cartão do 
Cliente sejam submetidos à operadora para 
validação. 
Ator: Cliente, Atendente 
Interessados: Cliente, Atendente, Loja e Operadora 
Pré-requisitos: Deve haver produtos no carrinho de compras. 
Pós-condição: 
A compra é efetivada após a autorização da 
operadora. 
17 
 
 
 
Fluxo normal: 
1. O Atendente solicita os dados do cartão ao 
Cliente. 
2. O Cliente fornece os dados do cartão. 
3. Após preenchimento, o Atendente clica no botão 
"Autorizar Compra". 
4. O sistema envia os dados à Operadora. 
5. O sistema exibe uma mensagem confirmandoa 
conclusão da compra. 
Fluxo alternativo: 
1. Se o Atendente pressionar o botão "Autorizar 
Compra" sem os dados do cartão, o sistema 
exibirá uma mensagem solicitando que os dados 
sejam preenchidos. 
Requisitos relacionados: 
RQNF02 - Disponibilidade do Sistema; RQNF03 - 
Disponibilidade da Operadora de Cartões. 
 
6. Requisitos não funcionais 
Geralmente, o cliente não precisa explicitar esses critérios, pois eles representam 
a base essencial de um programa ou serviço. Requisitos não funcionais abrangem 
aspectos relacionados à utilização do aplicativo em relação à confiabilidade, 
desempenho, disponibilidade, manutenção, tecnologias envolvidas e usabilidade. 
No contexto proposto, os requisitos não funcionais incluem: 
Identificação Nome Descrição 
RQNF01 
Segurança de 
acesso 
Para fortalecer a segurança do sistema, é 
imprescindível a adoção de boas práticas de 
segurança de acesso, incluindo a implementação 
18 
 
 
 
de tokens de autenticação e a escolha criteriosa 
de um sistema de firewall robusto para proteção 
contra ameaças externas. 
RQNF02 
Disponibilidade 
do sistema 
Assim como na escolha do firewall, a 
disponibilidade do sistema é fundamental. A 
preservação do funcionamento ininterrupto do 
sistema durante o horário comercial requer 
sistemas de backup de energia e hardware 
confiáveis. 
RQNF03 
Disponibilidade 
da Operadora de 
Cartões 
A operadora financeira desempenha um papel 
crucial no processo de finalização da compra, 
uma vez que é um dos métodos de pagamento 
aceitos. Portanto, é essencial garantir a 
disponibilidade contínua dessa operadora. 
RQNF04 
Desempenho de 
Internet 
Aprimorado 
O sistema utilizado para efetuar as vendas opera 
online, tornando essencial uma alta qualidade no 
desempenho da conexão de rede. Isso é vital 
para evitar atrasos e desistências por parte dos 
clientes durante o processo de compra. 
 
Identificador RQNF05 Categoria Usabilidade 
Nome Utilização de Design Responsivo nas Interfaces Gráficas 
Data de criação 15/04/2020 Autor Silvio Agnoleto 
19 
 
 
 
Data última 
alteração 
Não Aplicável Autor Não Aplicável 
Versão 1.0 Prioridade Importante 
Descrição O sistema de Controle e Vendas está sendo desenvolvido para 
operar em ambiente desktop. No entanto, é crucial que a 
interface do sistema seja capaz de se adaptar adequadamente, 
independentemente do dispositivo utilizado para acessá-lo, seja 
um desktop ou um tablet. Devido ao crescente uso de 
dispositivos móveis, em particular tablets, em estabelecimentos 
comerciais, é essencial que o layout do sistema seja compatível 
com esses dispositivos. Importante ressaltar que durante o 
processo de homologação do sistema, serão conduzidos testes 
de usabilidade para verificar a conformidade com este requisito. 
A não conformidade resultará na não realização de pagamento 
referente à funcionalidade que não seja homologada de acordo 
com os critérios estabelecidos neste documento. 
 
7. Contexto de utilização 
A relevância do contexto na experiência do usuário está em constante 
crescimento. Com os avanços tecnológicos e a ampla adoção de dispositivos móveis, 
o contexto de utilização, ou seja, o ambiente onde ocorre a interação entre o usuário 
e o produto, tornou-se um elemento fundamental no desenvolvimento de sistemas. 
Algumas considerações importantes a serem feitas em relação ao contexto 
incluem: 
 Que tipo de experiência deseja-se proporcionar em cada situação de uso? 
 Quais são os cenários nos quais o seu produto ou serviço pode ser 
empregado? 
20 
 
 
 
 Quais são as expectativas que os usuários têm em cada um desses 
contextos? 
O entendimento do contexto de uso permite que você prepare seus produtos 
e serviços para proporcionar experiências adequadas em cada situação de acesso. 
Público-alvo: O sistema está disponível para todos aqueles que tenham 
acesso mediante autenticação com login e senha, abrangendo tanto os funcionários 
quanto o proprietário. 
Objetivo: O sistema foi projetado para a realização de vendas de produtos 
disponíveis na loja física. 
Plataforma: O acesso ao sistema ocorre por meio de uma aplicação desktop, 
embora seja possível utilizá-lo em dispositivos móveis. Esse acesso é restrito à 
localidade física da loja. 
8. Regras de negócio 
As regras de negócio desempenham um papel fundamental na modelagem de 
processos, uma vez que delimitam e especificam a maneira como um determinado 
processo deve ser conduzido. Além disso, elas refletem o entendimento profundo do 
processo em questão. 
Dentro dos cenários apresentados, a seguir estão as regras a serem 
aplicadas. 
Fonte Manual do PIM VI – página 25 
Identificação RGN05 - Registro de Vendas de Produtos 
Descrição Toda venda deve incluir os dados do cliente e a lista de produtos 
adquiridos. É obrigatória a geração de um código exclusivo para a 
venda, contendo a data da transação, o valor total, opções de 
21 
 
 
 
pagamento (dinheiro ou cartão), o status do pagamento e o status da 
venda. 
Identificação RGN06 - Exclusão de Itens da Venda 
Descrição O atendente tem permissão para remover itens da venda caso o 
cliente opte por não adquiri-los. Entretanto, somente o supervisor da 
loja tem a autorização para efetuar essa exclusão, mediante 
autenticação com nome de usuário e senha válidos. 
Identificação RGN07 - Consulta de Preços 
Descrição O atendente está autorizado a consultar os preços dos produtos 
quando solicitado pelo cliente. 
Identificação RGN08 - Cancelamento de Vendas 
Descrição O cancelamento de uma venda pode ser realizado exclusivamente 
pelo supervisor da loja, que deve fornecer credenciais válidas de 
usuário e senha durante o procedimento. No momento do 
cancelamento, o código da venda deve ser transmitido ao sistema 
financeiro. 
Identificação RGN01 - Acesso ao Sistema 
Descrição O acesso ao sistema é restrito à loja e requer autenticação por meio 
de login e senha. 
Identificação RGN02 - Cadastro de Produtos 
22 
 
 
 
Descrição A tarefa de cadastrar produtos é atribuída ao estoquista, que deverá 
categorizá-los como jogos, acessórios ou produtos geek. 
Identificação RGN03 - Cadastro de Clientes 
Descrição Os registros de clientes devem conter informações como número de 
RG ou CPF, nome, data de cadastro, endereço, número de telefone e 
endereço de e-mail. 
Identificação RGN04 - Especificações dos Produtos 
Descrição Cada produto deve ser acompanhado por detalhes como código de 
barras, nome, categoria, fabricante, quantidade em estoque e preço. 
No caso de jogos e acessórios, também é necessário especificar a 
plataforma de uso e o prazo de garantia do produto. 
 
23 
 
 
 
Conclusão 
Os requisitos constituem o conjunto de necessidades estipuladas pelo cliente 
ou usuário, delineando a estrutura e o comportamento do software em 
desenvolvimento, assim como os processos, os dados a serem gerados, as restrições 
operacionais e as pessoas que irão utilizar o software, bem como suas interações 
complexas. 
A compreensão dos desafios enfrentados por uma organização na utilização 
de software é uma tarefa desafiadora. Portanto, a definição precisa do que um sistema 
deve realizar é uma tarefa complexa por natureza. 
O PIM IV ilustra que, por meio das técnicas aprendidas neste semestre, somos 
capazes de interpretar de maneira mais precisa as expectativas do cliente e 
transformá-las em realidade de forma organizada, eficiente e econômica. Isso leva em 
consideração não apenas as expectativas, mas também os prazos estabelecidos 
pelas partes envolvidas no processo. 
Assim, podemos afirmar que os benefícios da análise de requisitos incluem: 
o Estabelecimento de um entendimento comum entre desenvolvedores, 
clientes e usuários em relação ao trabalho a ser realizado. 
o Criação de uma fonte confiável para estimativas de custo, pessoal, prazos, 
entre outros. 
o Aprimoramento da qualidade dosoftware a ser desenvolvido. 
o Definição de objetivos que resultam em menor necessidade de 
manutenção e personalização do software no futuro. 
No entanto, para que essas estratégias alcancem o impacto desejado, é 
essencial que a definição de requisitos seja: 
o Clara e inequívoca. 
o Abrangente, abordando todos os aspectos relevantes. 
o Precisa e consistente, evitando ambiguidades. 
o Concisa, evitando informações desnecessárias. 
o Confiável, assegurando que os requisitos sejam sólidos e confiáveis em 
cada proposta a ser implementada. 
24 
 
 
 
Em conclusão, as abordagens de análise e coleta de requisitos 
desempenharam um papel fundamental para o sucesso deste projeto e para os futuros 
projetos que virão. 
 
25 
 
 
 
Referência 
Manual do PIM IV Curso Superior de Tecnologia em Análise e Desenvolvimento 
de Sistemas – Universidade Paulista – Unip .CST Análise e Desenvolvimento de 
Sistemas. 
[DENNIS, 2005] DENNIS, Alan. Análise e Projeto de Sistemas. Rio de Janeiro, LTC, 
2005. 
[Lima,2005] LIMA, Adilson da Silva. UML 2.0: do requisito à solução. 1 ed. São 
Paulo: Érica, 2005. 
[Ahern, 2001] DENNIS M. AHERN, AARON CLOUSE, e RICHARD TURNER, CMMI 
Distiled: A Practical Introduction to Integrated Process Improvement, SEI Series 
in Software Engineering, Addison-Wesley, 306 pages, 2001. 
[Pressman, 2002] PRESSMAN, R. Engenharia de Software. Rio de Janeiro: 
McGraw-Hill, 2002. 
[Campos, 1992] CAMPOS, VICENTE TQC — Controle da Qualidade Total. Belo 
Horizonte: Bloch Ed, 1992. 
[ISO. 2000] ISO 9001:2000. Quality Management Systems. Requirements, 2000. 
[Maldonado, 2001] — Qualidade de Software, Teoria e prática. São Paulo: Pearson, 
2001. 
[MCT,1996] MCT. Qualidade no setor de software brasileiro: 1995. Brasília, DF. 
http:/Awww.mct.gov.br 
[Weber, 2001] WEBER, K.C,; ROCHA, A.R.C e NASCIMENTO, C.J. Qualidade e 
produtividade em software, 4ª edição renovada. São Paulo, Makron Books, 2001