ORIENTADOS A OBJETOS Parte 3

Prévia do material em texto

Unidade 3
Análise e Projeto de 
Software Orientado a 
Objetos
© by Editora Telesapiens
Todos os direitos reservados. Nenhuma parte desta publicação 
poderá ser reproduzida ou transmitida de qualquer modo ou por qualquer 
outro meio, eletrônico ou mecânico, incluindo fotocópia, gravação ou 
qualquer outro tipo de sistema de armazenamento e transmissão de 
informação, sem prévia autorização, por escrito, da Editora Telesapiens.
Dados Internacionais de Catalogação na Publicação (CIP)
João Danilo Nogueira
Leandro C. Cardoso
Análise e Projeto de Software Orientado a Objetos
AUTORIA
João Danilo Nogueira
Sou graduado em Ciência da Computação pela Faculdade 
Grande Fortaleza (FGF) e amo programar. Atualmente, o foco de minha 
expertise é na área de gerenciamento de projetos, teoria dos números, 
RSA e criptografia. Vai ser um prazer enorme ajudar VOCÊ a se tornar 
um excelente desenvolvedor de software ou administrador de banco 
de dados. Conte comigo para lhe ajudar nessa trajetória rumo ao seu 
desenvolvimento profissional! Muito sucesso para você. Conte comigo!
Leandro C. Cardoso 
Sou formado na Graduação em Comunicação Social com 
Habilitação em Design Digital, e mestrado em Tecnologias da Inteligência 
e Design Digital pela PUC-SP, com uma experiência em direção de arte 
e criação na área com mais de 20 anos. Passei por empresas, a exemplo 
da Laureate International Universities, FMU, FIAM-FAAM, Universidade 
Anhembi Morumbi, Universidade do Centro Paula Souza (FATEC-ETEC), 
DeVry Brasil, UNEF, FAESF, Faculdade Positivo, Uninter, Platos Soluções 
Educacionais S.A. (Krotonn - Universidade Anhaguera). Além disso, atuei 
como analista de Desenvolvimento Pedagógico Sênior, Coordenador 
de Curso Técnico de Comunicação Visual e Revisor Técnico e Validador 
para Curso EAD. Também sou autor de mais de 10 livros didáticos um dos 
organizadores da Maratona de Criação e Design do Curso de Comunicação 
Visual da ETEC Albert Einstein. Sou apaixonado pelo que faço e adoro 
transmitir minha experiência de vida àqueles que estão iniciando em suas 
profissões. Por isso fui convidado pela Editora Telesapiens a integrar seu 
elenco de autores independentes. Estou muito feliz em poder ajudar você 
nesta fase de muito estudo e trabalho. Conte comigo!
ICONOGRÁFICOS
Olá. Esses ícones irão aparecer em sua trilha de aprendizagem toda vez 
que:
OBJETIVO:
para o início do 
desenvolvimento de 
uma nova compe-
tência;
DEFINIÇÃO:
houver necessidade 
de se apresentar um 
novo conceito;
NOTA:
quando forem 
necessários obser-
vações ou comple-
mentações para o 
seu conhecimento;
IMPORTANTE:
as observações 
escritas tiveram que 
ser priorizadas para 
você;
EXPLICANDO 
MELHOR: 
algo precisa ser 
melhor explicado ou 
detalhado;
VOCÊ SABIA?
curiosidades e 
indagações lúdicas 
sobre o tema em 
estudo, se forem 
necessárias;
SAIBA MAIS: 
textos, referências 
bibliográficas e links 
para aprofundamen-
to do seu conheci-
mento;
REFLITA:
se houver a neces-
sidade de chamar a 
atenção sobre algo 
a ser refletido ou dis-
cutido sobre;
ACESSE: 
se for preciso aces-
sar um ou mais sites 
para fazer download, 
assistir vídeos, ler 
textos, ouvir podcast;
RESUMINDO:
quando for preciso 
se fazer um resumo 
acumulativo das últi-
mas abordagens;
ATIVIDADES: 
quando alguma 
atividade de au-
toaprendizagem for 
aplicada;
TESTANDO:
quando o desen-
volvimento de uma 
competência for 
concluído e questões 
forem explicadas;
SUMÁRIO
Processo Unificado - Construção e Transição ................................. 10
Fase de Construção ....................................................................................................................... 10
Fase de Transição ............................................................................................................................ 15
Desenvolvimentos Iterativo e Evolutivo ...........................................20
Processo de Desenvolvimento de Software .............................................................. 20
Processo de Desenvolvimento de Software .............................................................. 20
Métodos de Abordagem para o Processo de Desenvolvimento de 
Software .................................................................................................................................................23
Desenvolvimento Ágil de Projetos .......................................................28
O Manifesto “Ágil” ............................................................................................................................28
Princípios da Metodologia Ágil ............................................................................................. 30
Qualidade de Software ............................................................................. 41
Conceito de Qualidade ............................................................................................................... 41
Teste de Software ...........................................................................................................................45
7
UNIDADE
03
Análise e Projeto de Software Orientado a Objetos
8
INTRODUÇÃO
Você sabia que a área de desenvolvimento iterativo, evolutivo 
e ágil de software é uma das mais demandas consideradas como 
intermediárias na análise e projeto de software orientado a objetos? Isso 
mesmo. Para os profissionais da área conhecer essa demanda primeiro 
é importante possuir conhecimento prévios das notações e convenções 
dos diagramas de modelação unificada UML - Modeling Language, ou 
a Linguagem Unificada de Modelação. E o conhecimento do processo 
unificado, suas fases, as atividades de um fluxo de trabalho, procedimento 
e características. Para assim, iniciar uma nova etapa, mas para isso é 
importante estudo avançado do processo unificado de desenvolvimento 
de sistemas, focando em questões relacionadas ao gerenciamento do 
projeto e à qualidade do software. Entendeu? Ao longo desta unidade 
letiva você vai mergulhar neste universo!
Análise e Projeto de Software Orientado a Objetos
9
OBJETIVOS
Olá. Seja muito bem-vindo à Unidade 3. Nosso objetivo é auxiliar 
você no desenvolvimento das seguintes competências profissionais até o 
término desta etapa de estudos:
1. Compreender os processos relacionados às duas últimas fases do 
ciclo de vida do processo unificado.
2. Definir desenvolvimentos iterativo e evolutivo, discernindo sobre 
suas diferenças.
3. Entender o que é, para que serve e quais são os princípios do 
desenvolvimento ágil de projetos de software.
4. Identificar as principais características e princípios da qualidade 
de software.
Análise e Projeto de Software Orientado a Objetos
10
Processo Unificado - Construção e 
Transição
OBJETIVO:
Ao término deste capítulo, você será capaz de compreender 
os processos relacionados às duas últimas fases do ciclo 
de vida do processo unificado. Isto será fundamental 
para o exercício de sua profissão. E então? Motivado para 
desenvolver esta competência? Então vamos lá. Avante!.
Fase de Construção
A fase de construção se fundamenta na base de arquitetura 
desenvolvida na fase de elaboração, todas as iterações e incrementos 
desta fase têm por objetivo desenvolver o produto com as iterações 
iniciais, estando o ambiente do usuário já funcional. A transição é uma 
fase de correção de erros e de adaptações, ou seja, ao final da fase 
de construção, temos uma fase inteira que se utiliza das mesmas 
metodologias utilizadas na fase de construção, mas apenas para correção 
de problemas. A construção coloca em prática todos os planos já 
realizados até o momento, construindo todo o código e todas as relações 
definidas anteriormente.
A versão do produto gerada na fase de construção, por mais 
completa que possa ser, é chamada de versão beta, pois é a versão 
que será enviada para a fase de transição, com vistas a ser corrigida ou 
modificada de acordo com asnecessidades apresentadas. Nesta fase são 
realizadas modificações estruturais na arquitetura do sistema, para que os 
casos de uso remanescentes possam ser atendidos. É também na fase de 
construção que todos os subsistemas são agregados ao produto.
Análise e Projeto de Software Orientado a Objetos
11
Figura 1 - A versão do software gerada na fase de construção, mesmo que esteja bem 
completa recebe o nome de versão beta
Fonte: Freepik.
Diferentemente de suas fases anteriores (concepção e elaboração), 
que estavam relacionadas diretamente com a modelagem do sistema, 
tendo a parte construtiva secundária a elas, a fase de construção inverte 
os papéis, deixando a modelação como secundária, e as fases de 
construção e desenvolvimento da aplicação como sendo a parte principal 
da fase. Na fase de elaboração, todos os casos de uso e atores foram 
identificados, mas apenas uma pequena parte foi implementada, a parte 
responsável pela descrição da base arquitetural. 
Na fase de construção, o sistema como um todo deve ser detalhado 
e executado, então os casos de uso remanescentes começam a ser 
estudados e seus requisitos coletados. É nesse fluxo, durante a fase de 
construção, que os primeiros protótipos de interface com o usuário são 
projetados. É desenvolvido um estudo para se conhecer as necessidades 
e facilidades desejadas, de modo a permitir que o usuário utilize o sistema 
de forma rápida e confortável. O fluxo de requisitos, na fase de construção, 
é pequeno em comparação com o trabalho de implementação, isto se dá, 
porque toda a grande massa necessária deste fluxo já foi realizada em 
outras fases.
Análise e Projeto de Software Orientado a Objetos
12
Figura 2 - O fluxo de requisitos na fase de construção, é menor em comparação com o 
trabalho de implementação
Fonte: Freepik.
Já o fluxo de análise é o mais mutável do ciclo de vida do processo, 
a cada iteração ele sofre modificações, a cada fase ele se altera 
completamente, tornando impossível que ele esteja preservado neste 
momento do processo.
IMPORTANTE:
Muitos analistas, inclusive, renunciam ao fluxo de análise 
e se concentram unicamente no fluxo de projetos, isto 
porque o fluxo de projetos se incrementa, enquanto o fluxo 
de análise sofre depreciação.
Caso o modelo de análise for mantido até esta fase, então, ele será 
completado por meio das classes e casos de uso, baseados no fluxo de 
requisitos da fase de construção (NAKAGAWA, 2016). O resultado deste 
fluxo é um modelo de análise mais completo, dando uma visão mais 
sólida e definida do que apenas subprodutos de um modelo. 
Análise e Projeto de Software Orientado a Objetos
13
Assim, a fase de construção é a responsável pela implementação 
quase completa de todo o projeto, logo, cabe ao fluxo de projeto a 
entrega do produto quase completo, incluindo o desenvolvimento dos 
casos de uso que ainda não foram utilizados e das classes que não foram 
implementadas. É também o fluxo de projetos da fase de construção que 
analisa os subsistemas e define se algum deles irá ser implementado, ou 
um subsistema já existente deverá ser utilizado.
Já na implementação, em uma fase focada na construção 
e desenvolvimento do projeto, o fluxo de implementação é o que 
mais se destaca, já que esse é o fluxo que cuida do desenvolvimento 
propriamente dito. Todo o esforço da fase de construção é aplicado na 
fase de implementação, pois é quando o trabalho de implementação irá 
começar e terminar de fato. Todo o trabalho de implementação é feito 
com base no fluxo de projeto, sendo este revisado e atualizado nesse 
mesmo fluxo. 
Nesse sentido, o fluxo de implementação da fase de construção só 
pode ser realizado se toda a arquitetura do sistema estiver estabelecida, 
sem falhas e pronta para a execução. Apenas a partir da arquitetura 
estabelecida é possível definir quais os caminhos do projeto, como ele 
deve ser implementado e quais serão as partes núcleo e adjacentes.
Figura 3 - O fluxo de implementação da fase de construção apenas se inicia se toda a 
arquitetura do sistema estiver estabelecida
Fonte: Freepik.
Análise e Projeto de Software Orientado a Objetos
14
O resultado do fluxo de implementação é uma rotina 100% executável 
do projeto, uma versão operacional, inicial, que atende as necessidades 
do cliente e representa o versionamento beta do sistema. Já no fluxo de 
teste tem por objetivo testar cada subsistema e cada implementação do 
projeto realizado na fase de implementação. Aqui são realizados testes por 
meio de procedimentos preestabelecidos, com resultados já conhecidos, 
para que tudo possa ser comparado. 
Figura 4 - Uma rotina de testes deixa o projeto mais confiável
Fonte: Freepik.
Caso um determinado teste não encontrar o resultado desejado, é 
necessária a modificação da estrutura por meio de procedimentos. Isto se 
repete até que os resultados satisfatórios sejam encontrados. Uma rotina 
de testes deixa o projeto mais confiável, porém, se traçarmos uma reta 
de custos, veremos que o momento de execução dos testes é um dos 
momentos mais caros do processo.
Análise e Projeto de Software Orientado a Objetos
15
Fase de Transição
Após a fase de construção, esta é seguramente a mais importante 
para o sistema. Agora que isso está pronto, é possível garantir seu 
estabelecimento em um ambiente operacional. É na fase de transição 
que são lançadas as chamadas versões betas, para que usuários finais 
realizem os testes mais profundos e retornem feedbacks sobre possíveis 
erros que devem ser corrigidos. 
Inclusive, é a partir da avaliação desses feedbacks que a equipe 
começa a se preparar para corrigir falhas e avaliar se o produto realmente 
atende as necessidades do usuário final. Esses feedbacks também 
possibilitam uma avaliação sobre as facilidades e dificuldades, mostrando 
onde a equipe deve focar seus esforços de melhoramento, com foco em 
manter uma interface confortável para o cliente.
A fase de transição é crucial para a modificação do sistema, é nessa 
fase que ocorre a avaliação de modificações e adaptações. A ideia geral 
não é reformular o produto, mas apenas adaptá-lo ao que realmente é 
desejado, pois, afinal, todos os desejos do cliente foram preestabelecidos 
na modelação do projeto.
A ideia é procurar por deficiências e saná-las de forma a manter 
a lógica do projeto, essas deficiências são mínimas e sempre passam 
despercebidas pela equipe de planejamento e desenvolvimento. Essa 
fase é utilizada para a criação de treinamentos, facilitando a usabilidade 
e a profundidade do conhecimento do cliente. É também aqui que, caso 
necessário, é realizada a comunicação entre a base de dados antiga e 
a nova. Esta fase é a última do ciclo de vida do projeto, sendo finalizada 
quando o produto é entregue em sua versão 100% executável e sem erros. 
A fase de transição não mantém seu foco nos fluxos de requisitos, 
análise, projeto, implementação e teste, na verdade, ela utiliza propriedades 
de todas as demais fases, mas sem realmente penetrar a fundo em suas 
técnicas. São mínimas as atividades exercidas por esses cinco fluxos de 
trabalho, a maior parte do trabalho se encerra na fase anterior, restando 
Análise e Projeto de Software Orientado a Objetos
16
para a fase de transição apenas a revisão do que já está criado. Alguns 
processos não são ligados aos fluxos de trabalho, que acabam sendo 
executados durante esta fase. Graças a esta não-ligação, eles exigem um 
esforço um tanto maior para sua execução, entre as tarefas, estão:
 • A preparação para o lançamento da versão beta do produto, 
incluindo a criação das metodologias de retorno de opinião, para 
a análise de feedback. 
 • A preparação do público para recebê-la, dependendo do tipo do 
produto envolvendo um marketing de lançamento.
 • A instalação da versão beta nos ambientes operacionais do 
usuário, o grande teste final, que retorna a resposta de que o 
produto realmente funcionou.• A forma de gerenciamento dos resultados dos testes, levando em 
consideração as opiniões, facilidades e dificuldades, com ênfase 
em analisar quais as mudanças são realmente necessárias.
 • A nova adaptação do produto, com suas falhas melhoradas por 
meio das circunstâncias definidas pelos usuários (neste ponto, 
entramos na discussão “o que é bom para um pode ser ruim para 
outro”, levando o analista e o arquiteto de softwares a tomarem as 
decisões mais adequadas para a maioria).
 • A necessidade de completar os artefatos do projeto, que podem 
ter sido lançados de forma incompleta, e isso inclui a anexação 
da documentação das modificações realizadas nas atividades 
anteriores. 
 • A determinação da conclusão do projeto, as perguntas que 
sempre cercam essa atividade é “Quando iremos encerrar?”, “Já 
fizemos tudo o que podíamos?”, “Podemos melhorar?”. É sempre 
frustrante pensar que algo acabou, afinal, em linha de código tudo 
pode ser aprimorado (CAVALCANTI, 2018).
Análise e Projeto de Software Orientado a Objetos
17
Claro, não são todos os tipos de projeto que irão ter todas as seis 
atividades listadas acima, alguns não necessitarão de todas, porém, 
outros, sim. Vale analisar se o produto está sendo desenvolvido para o 
mercado ou para um cliente específico. Quando tratamos do mercado, 
todas as atividades necessitam de execução, tratamos de muitos usuários 
em potencial. Os erros assumem uma escala catastrófica se não forem 
tratados imediatamente.
Para um usuário específico já existe um ambiente adequado para 
a instalação do sistema, uma rotina sempre será seguida. O cliente pode 
estar acompanhando o processo, então, algumas atividades se tornam 
obsoletas. Por fim, é preciso avaliar a satisfação do cliente, dependendo 
da satisfação do cliente, um processo unificado poderá ser considerado 
finalizado ou não (CAVALCANTI, 2018). 
Assim, quando lançado no mercado, será considerado finalizado 
o projeto que corrigir todos os erros encontrados na versão beta, bem 
como esteja funcionando e executando suas funções de maneira efetiva. 
Já quando tratamos de um cliente específico, o gerente pode considerar 
como completo o projeto que apresentar os resultados de todos os testes 
corretamente, não demonstrando falhas de execução.
No momento da realimentação e adaptação, a chave de sucesso do 
processo unificado (PU) está na fase de transição e na modularização do 
sistema, desde a sua modelação inicial. A construção deve se adequar ao 
inevitável avanço e às muitas futuras atualizações dos planos. Para cada 
iteração gerada, subconjuntos de requisitos são projetados rapidamente. 
Esses subconjuntos obedecem às características modulares de um 
sistema e, em algum momento, podem ser reutilizados para agilizar 
os processos. Esse tratamento de subconjuntos facilita as futuras 
modificações ou adaptações que o tempo exigirá do projeto. 
Afinal, se o mesmo código é utilizado por todo o sistema, quando 
um for atualizado, os demais seguirão a linha, mantendo sempre o 
desenvolvimento de forma dinâmica. O PU utiliza ciclos avaliativos que 
ajudam na detecção de falhas, iluminando um caminho de progressão e 
descoberta de valores reais do sistema, além de melhorar o entendimento 
dos requisitos e de facilitar o processo de implementação.
Análise e Projeto de Software Orientado a Objetos
18
O Processo Unificado gera dois tipos de versões executáveis antes 
do produto, são elas a Versão Beta e o MVP, a fase de transição utiliza 
essas versões para corrigir erros e adaptar os desejos do cliente. Um 
versionamento Beta gera uma versão de um determinado produto que 
ainda se encontra em fase de teste. Por mais que seja um lançamento, 
a versão beta é disponibilizada apenas para a realização de testes de 
usuários, para que eles encontrem e reportem erros, e estes sejam 
devidamente corrigidos.
MVP significa “Produto Mínimo Viável”, e é utilizado para apresentar 
ao possível cliente a forma e funcionalidade que determinado produto 
irá adquirir na fase final de produção. É uma versão que possui apenas as 
funcionalidades extremamente necessárias, com uma interface simples 
e que permita ao cliente a visualização daquilo que ele quer. É a partir 
do MVP que testamos a eficiência de um produto, se ele realmente é 
utilizável, se pode ser aceito no mercado ou, dependendo do caso, se ele 
pode concorrer com os demais produtos similares no mercado.
Análise e Projeto de Software Orientado a Objetos
19
RESUMINDO:
E então? Gostou do que lhe mostramos? Aprendeu mesmo 
tudinho? Agora, só para termos certeza de que você 
realmente entendeu o tema de estudo deste capítulo, vamos 
resumir tudo o que vimos. Você deve ter aprendido que o 
processo unificado (PU) foi criado para ser uma metodologia 
que se comunica de maneira eficiente com a linguagem 
UML, além de ser um método de desenvolvimento ágil. Se 
comparado ao modelo de cascata, no qual cada etapa do 
ciclo do processo é executada integralmente e apenas uma 
vez, o PU subdivide o projeto inteiro em fases e fluxos, cada 
um com suas características, capacidades e peculiaridades. 
Tenha em mente que não existe um plano detalhado para 
um projeto, cada projeto é único, suas exigências são 
únicas e seus resultados exclusivos. Não imagine que vai 
haver uma fórmula mágica para solucionar qualquer projeto 
como uma receita de bolo. O PU é um modelo que pode 
basear a modelagem de um projeto, assim como a UML. 
Cabe ao arquiteto de softwares decidir qual sistema de 
modelagem melhor se encaixa nas necessidades técnicas 
de um projeto e quais podem ser realmente aplicados.
Análise e Projeto de Software Orientado a Objetos
20
Desenvolvimentos Iterativo e Evolutivo 
OBJETIVO:
Ao término deste capítulo, você será capaz de entender o 
que são desenvolvimentos iterativo e evolutivo, discernindo 
sobre suas diferenças. Isto será fundamental para o exercício 
de sua profissão. E então? Motivado para desenvolver esta 
competência? Então vamos lá. Avante!.
Processo de Desenvolvimento de Software
Um processo de desenvolvimento de software é um conjunto de variáveis 
parcialmente ordenadas, com o objetivo de gerar um sistema de software como 
produto. É um dos ramos da Engenharia de Software, considerado um dos 
principais processos responsáveis pela qualidade de software. 
Processo de Desenvolvimento de Software
Antes de falarmos sobre os processos de desenvolvimento de 
software, vale lembrar alguns conceitos como que a orientação objetos 
foi um processo criado para combater a crise do software. Mas o que 
foi realmente esta crise? Para entender melhor, o ano era 1970, em não 
havia nenhum tipo de organização, ou engenharia que controlasse o 
desenvolvimento de software à época, que eram desenvolvidos à critério 
de cada programador, que criavam seus próprios modos e padrões. 
Continuando a explicação, vamos supor que a empresa fictícia 
BollySoftware contratava desenvolvedores para criar seus pequenos softwares 
e então comprava deles os direitos sobre o que havia sido desenvolvido. 
Com passar do tempo, a computação avançou e a BollySoftware precisou 
chamar novamente os desenvolvedores para atualizar os softwares criados 
anteriormente. Mas havia ali um problema, anos haviam se passado e, com a 
maturidade adquirida na profissão, os antigos desenvolvedores não seguiam 
mais aqueles padrões até então adotados. 
Análise e Projeto de Software Orientado a Objetos
21
Alguns nem mesmo lembravam mais como seus padrões 
funcionavam e, quando pegavam os antigos projetos, não conseguiam 
evoluir fazê-los evoluir. Assim sendo, todos precisavam reconstruir seus 
softwares do zero, readaptando-os aos novos padrões que usavam. 
Agora, imagine que isso estava acontecendo em todo o mundo, não 
apenas isso havia uma demanda gigante surgindo pelos softwares e 
poucos desenvolvedores no mercado.
Figura 5 - A grande demanda pelos softwares e poucos desenvolvedores no mercado,vou 
uma das causas da crise do software
Fonte: Freepik.
Os softwares não estavam mais se adaptando aos hardwares, os 
hardwares não estavam mais suportando os softwares, os desenvolvedores 
estavam tentando corrigir os problemas, mas a grande complexidade dos 
problemas fazia com que desafios ainda maiores surgissem. O mercado de 
desenvolvimento começou a entrar em crise e começou a ruir. As principais 
causas estavam relacionadas aos projetos que estouravam os orçamentos 
e prazos, a qualidade dos produtos também era insuficiente. 
Os requisitos não estavam sendo cumpridos e as manutenções 
eram quase impossíveis de serem feiras, dada a tamanha “bagunça” que 
os códigos acabavam armazenando. Foi nesta época que o termo “bug” 
começou a ser amplamente difundido, significando “erro” de programação 
em software. Em 1970, no auge da crise do software, foi estabelecido o 
primeiro grande paradigma de programação: a Programação Estruturada. A 
PE, como era conhecida, consistia em uma forma de programação baseada 
em sub-rotinas, laços de repetição, estruturas condicionais e de bloco.
Análise e Projeto de Software Orientado a Objetos
22
VOCÊ SABIA?
Antes da programação estruturada, os códigos eram 
baseados em blocos de instruções aleatórios ligados por 
comandos de desvio de fluxo conhecidos como “Ligadores”. 
O mais conhecido desses comandos era o “GOTO”, que 
desviava o fluxo de execução para uma linha do programa, 
sem previsão de retorno ao mesmo ponto.
A programação estruturada foi o paradigma vigente até o surgimento 
da programação orientada a objetos (POO) na década de 1990. Enquanto 
a programação estruturada se baseava em estruturas de controle alto 
nível, conceitos de execução top-down e refinamento passo a passo, 
a POO vinha com sua tecnologia de objetos, que continham atributos 
e métodos. Com a programação estruturada, surgiu a Metodologia de 
Desenvolvimento de Sistemas, na década de 1980, que começou a criar 
padrões de construção de sistemas baseados em programas estruturados. 
Era o início da profissionalização do que se conhece atualmente por 
Análise de Sistemas.
IMPORTANTE:
A figura do analista de sistemas ganhou força no início 
da década de 80 com o surgimento da metodologia de 
desenvolvimento de sistemas, introduzindo conceitos 
como modelagem conceitual de dados, diagrama de 
contexto e análise de processos.
Análise e Projeto de Software Orientado a Objetos
23
Ainda na década de 1990, surge a POO e, com ela, a UML e o 
Processo Unificado de Desenvolvimento de Software, e, por fim, na virada 
do milênio, surge o Processo Ágil. Existem alguns métodos de abordagem 
para o Processo de Desenvolvimento de Software, os mais conhecidos 
são o (a):
 • Modelo em Cascata. 
 • Prototipação. 
 • Desenvolvimento Incremental.
 • Desenvolvimento Iterativo e Evolutivo. 
 • Modelo em Espiral. 
 • Desenvolvimento Rápido de Aplicação. 
 • Desenvolvimento Ágil de Software.
 • Processo de programar e arrumar e as metodologias Leves.
Esses métodos de abordagem para o Processo de Desenvolvimento 
de Software serão aprofundados a seguir.
Métodos de Abordagem para o Processo de 
Desenvolvimento de Software
Sobre o modelo em cascata, a primeira impressão, o termo “modelo 
em cascata” nos remete a belas paisagens naturais formadas por quedas 
d’água. O modelo em cascata é baseado exatamente nessa estrutura, 
uma forma natural de criar uma representação lógica que siga a ideia de 
cascata. Consiste em um modelo sequencial que flui constantemente por 
meio das fases básicas de um projeto, incluindo requerimentos, projeto, 
implementação, testes, integração e manutenção. A figura a seguir ilustra 
bem a sequência de fases de desenvolvimento de sistemas que constitui 
o modelo em cascata.
Análise e Projeto de Software Orientado a Objetos
24
Figura 6 - Modelo em Cascata
Implementação
Verificação
Manutenção
Projeto
Requerimento
Fonte: Nogueira (2018a, p. 16).
Já prototipação é o processo de desenvolvimento que trabalha 
com o conceito de criação de protótipos, para entender melhor para cada 
pequena modificação é criado um protótipo de teste, como demonstrado na 
figura a seguir. Trata-se do ciclo da prototipação, que inicia na obtenção dos 
requisitos, passa pela rápida elaboração do projeto, construção, avaliação e 
refinamento de um protótipo. Voltando à etapa de obtenção de requisitos, e 
assim por diante, até que haja um modelo aprovado pelo cliente.
Figura 7 - Ciclo da prototipação
Refinar 
protótipo
Obter 
requisitos
Elaborar 
projeto 
rápido
Construir 
protótipo
Avaliar 
protótipo
Fonte: Nogueira (2018a, p. 16).
Análise e Projeto de Software Orientado a Objetos
25
Sobre o modelo em espiral, é um provedor de metamodelos 
que acomoda diversos processos específicos de desenvolvimento. A 
vantagem do modelo em espiral é que ele pode agregar facilmente todos 
os outros modelos, ou partes deles, desde que os conceitos facilitem o 
alcance dos objetivos.
Figura 8 - Fases do Modelo em Espiral
Fonte: Nogueira (2018a, p. 17).
Este modelo é utilizado geralmente para grandes projetos, seus 
usos estão diretamente ligados às facilidades de redução de riscos, à 
aplicação de engenharias atuais, às abordagens sistemáticas. Como 
também ao tratamento de estimativas, à versatilidade do modelo para 
mudanças e à capacidade de os profissionais poderem começar seus 
processos mais cedo que o normal.
Já no processo iterativo e evolutivo de maneira geral, o processo 
evolutivo é uma estratégia de planejamento focado no desenvolvimento 
paralelo de diversas partes do sistema e, quando completas, unificadas. O 
processo iterativo é um plano de retrabalho e melhoramento do sistema 
em partes pré-definidas. Observe que ambos os conceitos são similares, 
mas um não engloba o outro. Enquanto um desenvolve o sistema como 
um todo, o outro quebra-o em pedaços e vai gerando retrabalho nessas 
partes até o objetivo ser alcançado.
Análise e Projeto de Software Orientado a Objetos
26
A ideia de um Processo Iterativo-Evolutivo (PIE) se dá exatamente da 
união das duas características. Você, como programador, de certa forma, 
irá quebrar o sistema em pequenos módulos. E esses pequenos módulos 
irão passar por evoluções iterativas, fazendo com que, a cada nova rodada 
do ciclo de vida do processo, tenhamos um produto funcional com mais 
funcionalidades. 
Ele se assemelha muito ao modelo de Processo Unificado, pois o PU 
utiliza o desenvolvimento iterativo-evolutivo para basear suas iterações, 
então, no PIE - Processo Iterativo-Evolutivo temos a seguinte formatação. 
Que durante a inicialização do projeto é definida uma versão chamada de 
base, e é a partir desta versão que todo o projeto começa a evoluir. 
Nesse sentido, a ideia inicial é criar um MVP - Minimum Viable 
Product (Mínimo Produto Viável) do produto, para que o usuário possa 
realizar uma avaliação. Este MVP deve demonstrar a funcionalidade para 
os aspectos-chaves do projeto, bem como os problemas propostos e 
as possíveis soluções. Deve ser funcional o bastante para que o produto 
possa ser compreendido e suas melhorias sejam facilmente localizáveis. É 
preciso utilizar técnicas de Gerenciamento de Projetos para criar uma lista 
de tarefas a serem realizadas, cronogramadas, cronometradas e aplicadas. 
A parte iterativa é o momento de reprojetização e implementação das 
checklists geradas pela gerência do projeto, a ideia é que toda iteração 
seja simples, direta e modular, ou seja, que possa ser reaproveitada.
Análise e Projeto de Software Orientado a Objetos
27
RESUMINDO:
E então? Gostou do que lhe mostramos? Aprendeu mesmo 
tudinho? Agora, só para termos certeza de que você 
realmente entendeu o tema de estudo deste capítulo, 
vamos resumir tudo o que vimos. Você deve ter aprendido 
que os processos de desenvolvimento foram criados para 
suprir as necessidades de uma crise, porém, esta crise 
se alastra até os presentes dias.Ainda há uma falta de 
desenvolvedores no mercado e uma procura muito alta 
por bons profissionais. Alguns casos de softwares que não 
atendem seus requisitos e alguns ditos desenvolvedores 
que não seguem os padrões indicados. De maneira geral, 
os processos de desenvolvimento foram criados para 
suprir as necessidades de uma crise, porém, esta crise 
se alastra até os presentes dias. Para isso é importante os 
estudos sobre Processo Unificado de Desenvolvimento 
de Software, os conceitos e diagramas da Linguagem 
Unificada de Modelação (UML) e, consequentemente, 
os processos de desenvolvimento. Assim é importante 
o conhecimento sobre duas características do Processo 
Unificado: a capacidade de crescimento iterativo e a 
capacidade de evolução do software.
Análise e Projeto de Software Orientado a Objetos
28
Desenvolvimento Ágil de Projetos
OBJETIVO:
Ao término deste capítulo, você será capaz de entender 
o que é, para que serve, e quais são os princípios do 
desenvolvimento ágil de projetos de software. Isto será 
fundamental para o exercício de sua profissão. E então? 
Motivado para desenvolver esta competência? Então 
vamos lá. Avante!.
O Manifesto “Ágil”
A comunidade de TI sempre se debateu sobre o que seria o termo 
“ágil” quando se referia ao processo de desenvolvimento de software. 
Para os mais regrados, agilidade significa renunciar a muitos protocolos 
preestabelecidos de produção, o que acarretaria queda de qualidade do 
produto final. A metodologia ágil oferece suas próprias práticas e princípios, 
muitas delas compartilhadas com o que foi definido no “Manifesto Ágil” 
(CONCEIÇÃO; SILVEIRA, 2015). Então, a grande discussão que gira em torno 
das metodologias de desenvolvimento ágil está nas suas prioridades e 
valorização delas. Todo o conteúdo maçante das diversas metodologias 
documentais que haviam sido estabelecidas nas décadas anteriores estava 
sendo desvalorizadas em relação a outros tópicos.
Com a metodologia ágil, valorizamos mais as interações e os 
indivíduos do que os processos e ferramentas. Em outras palavras, 
essa metodologia olha mais para o funcionamento do software do 
que para a documentação envolvida no gerenciamento de seu projeto 
de desenvolvimento. Ou seja, em um desenvolvimento ágil, todos 
os olhares se voltam para o cliente em si, muito mais do que para os 
contratos negociados, dando sempre preferência ao estudo e resposta às 
mudanças do escopo (requisitos) e do ambiente em torno do produto que 
está sendo desenvolvido, tudo isto acima das questões relacionadas ao 
cumprimento do plano estabelecido no início do projeto.
Análise e Projeto de Software Orientado a Objetos
29
Figura 9 - Na metodologia ágil, valorizamos mais as interações e os indivíduos do que os 
processos e ferramentas
Fonte: Freepik.
Os indivíduos e as interações desses com o sistema devem ser mais 
valorizados do que os processos e ferramentas envolvidos com o projeto. 
Quando nos focamos demais em processos e ferramentas, esquecemos 
de que as pessoas são mais importantes do que o software em si, pois 
são elas quem irão utilizá-lo no dia a dia. Em uma metodologia ágil de 
desenvolvimento de software, os velhos papéis e formulários contendo 
folhas de requisitos são substituídos pela velha e boa conversa cara a cara 
(face to face) entre desenvolvedores e usuários finais.
IMPORTANTE:
No desenvolvimento ágil de projetos, os requisitos 
analisados continuam sendo importantes, com toda a 
certeza, mas não mais do que a discussão face to face.
O software em funcionamento deve vir antes das documentações 
mais abrangentes, logo, para uma metodologia ágil, a prototipação de 
Análise e Projeto de Software Orientado a Objetos
30
sistemas é uma ferramenta indispensável a sua aplicação direta. Ela 
permite que haja um processo de colaboração dinâmica entre a equipe de 
desenvolvimento e o cliente. Por mais que todo o sistema esteja detalhado 
e definido nas linhas de um contrato, o processo de desenvolvimento flui 
bem mais naturalmente quando o cliente explica sua ideia, frente a frente 
com o desenvolvedor. 
Figura 10 - O processo de desenvolvimento pode fluir bem mais natural quando o cliente 
explica sua ideia, frente a frente com o desenvolvedor
 
Fonte: Freepik.
A capacidade de responder às mudanças dever estar sempre mais 
afiada do que a de seguir um plano, afinal, desenvolver um software 
é aprendizado. Mudanças são ótimas oportunidades para ganhar 
novos conhecimentos e adaptar o sistema de maneira mais efetiva às 
necessidades do cliente.
Princípios da Metodologia Ágil
Antes de entendermos os princípios da metodologia ágil de 
desenvolvimento de projetos de software, é importante que se 
compreenda o que vem a ser um princípio.
Análise e Projeto de Software Orientado a Objetos
31
DEFINIÇÃO:
Segundo o dicionário da língua portuguesa, um princípio 
é toda a estrutura sobre a qual se constrói alguma coisa, 
os ensinamentos básicos e gerais que delimitam de onde 
devemos partir em busca de algo. Verdades práticas 
que visam treinar nossa mente para melhor discernirmos 
sobre os caminhos corretos a serem tomados. É por meio 
dos princípios que podemos extrair regras e normas para 
construirmos procedimentos, programas e paradigmas 
(CONCEIÇÃO; SILVEIRA, 2015).
O manifesto ágil se baseia em 12 princípios que são considerados 
os pilares de sustentação da metodologia ágil, são princípios de simples 
enunciação, mas que têm profundo significado e abrangência, são eles:
1. A maior prioridade deve ser a satisfação do cliente, com entregas 
contínuas e adiantadas de software, e com valor agregado;
2. Escopo variável – mudanças nos requisitos são bem-vindas, 
mesmo tardiamente, os processos ágeis tiram vantagem das 
mudanças, visando à vantagem competitiva para o cliente;
3. Entregar versões do software funcionando com frequência de 
semanal a mensal, ou na menor escala de tempo possível;
4. Pessoas de negócio e desenvolvedores devem trabalhar 
diariamente em conjunto por todo o projeto;
5. Os projetos devem ser construídos em torno de indivíduos 
motivados, com ambiente, suporte e confiança neles depositados 
para que possam realizar o trabalho da forma mais eficiente possível;
6. O método mais eficiente e eficaz de transmitir informação para 
a equipe, e entre membros da equipe de desenvolvimento, é a 
conversa frente a frente;
7. Software funcional é a medida primária do progresso;
Análise e Projeto de Software Orientado a Objetos
32
8. Os processos ágeis promovem desenvolvimento sustentável, os 
patrocinadores, desenvolvedores e usuários devem ser capazes 
de manter um ritmo constante sempre;
9. Contínua atenção à excelência técnica e bom design aumentam a 
agilidade das entregas;
10. Simplicidade é a arte de maximizar a quantidade de trabalho;
11. As melhores arquiteturas, requisitos e design emergem de times 
auto-organizáveis;
12. Em intervalos regulares, o time reflete sobre como se tornar mais 
eficaz e, então, refina e ajusta seu comportamento ao longo do 
projeto (CONCEIÇÃO; SILVEIRA, 2015).
Sobre a prioridade é satisfazer o cliente, você sabe qual a única certeza 
que envolve um projeto de software, ou de quaisquer naturezas? Incrivelmente, 
a resposta sincera de uma grande parcela dos gerentes de projeto é a seguinte. 
“A única certeza que temos sobre um projeto é que irá atrasar”. 
Isto se dá porque, com o desenvolvimento de algumas soluções, 
processos documentais e burocráticos parecem ter se tornado mais 
importantes do que a entrega do próprio software. Pela análise dos 
“profissionais da área”, se não é possível realizar toda a documentação 
de um software antes de iniciar a implementação dele, corre-se diversos 
riscos de diminuir a qualidade do produto entregue. 
De fato, esta preocupação procede e tais riscos existem, no 
entanto, a metodologia ágil não pede que a documentação não seja 
feita, ela apenas propõe que a documentação e a implementação sejam 
realizadasem paralelo, uma sem influenciar no avanço da outra. Deste 
modo, para garantir a satisfação do cliente, deve-se internalizar a ideia de 
que a documentação é secundária em relação à entrega a este cliente, 
pois mais vale uma a entrega de uma versão do software imperfeita do 
que a não-entrega.
Sobre o escopo variável, como vimos anteriormente, a metodologia 
ágil prega a preparação da vinda de mudanças, e mudanças nos requisitos 
também são esperadas, e muito bem-vindas. As técnicas e metodologias 
utilizadas até então desencorajavam e desestimulavam as possibilidades 
Análise e Projeto de Software Orientado a Objetos
33
de mudança, gerando grandes ameaças sobre o custo do produto, o 
prazo de entrega e a qualidade de sua manutenção. Em outras palavras, a 
metodologia ágil procura trabalhar com contratos de escopo aberto, nos 
quais os requisitos podem mudar de acordo com as entregas parciais do 
projeto.
IMPORTANTE:
O fato de a metodologia ágil se basear no conceito do 
escopo aberto, não significa que ela deva tolerar toda e 
qualquer mudança nos requisitos do escopo inicial, mas, 
as mudanças que afetem positivamente o projeto, devem 
ser bem-vindas. Para isto, o modelo de negócio de quem 
desenvolve deve prever esse tipo de mudança em seus 
acordos de trabalho com sua equipe de desenvolvimento.
Em relação à entrega frequente de versões do software funcionando, 
note que a todo o momento, os princípios fazem menção à velocidade 
de entrega e felicidade do cliente com isso. O objetivo da metodologia 
ágil é garantir que determinado software agregue o valor necessário 
e seja entregue no menor tempo possível. Para atingir este objetivo, a 
metodologia preconiza as entregas parciais do software em ciclos curtos 
de desenvolvimento, já pensando em maneiras efetivas de se realizar 
mudanças, adaptações, modificações e lançamentos de novos requisitos 
no escopo. Desse modo, quanto menor for o intervalo de tempo entre 
uma entrega e outra, melhor será a qualidade do resultado para o cliente.
Em relação ao princípio do cliente como parte da equipe, vivemos 
em um mundo no qual o cliente chega a uma empresa e contrata seus 
serviços. Fala exatamente o que quer e volta um mês depois para verificar 
se foi realizado, muitas vezes, escutamos frases de insatisfação.
Análise e Projeto de Software Orientado a Objetos
34
Figura 11 - A metodologia ágil tem como base a ligação direta entre o desenvolvedor e o 
cliente
 
Fonte: Nogueira (2018b, p. 18).
A metodologia ágil tem como um de seus pilares fundamentais 
a ligação direta entre o desenvolvedor e o cliente, mantendo uma 
comunicação fácil, clara e direta, permitindo que as alterações de escopo 
sejam realizadas em tempo real.
Já em relação ao princípio equipe motivada e com suporte, a 
ideia da metodologia ágil é que a equipe seja autogerenciada. Não há 
necessidade de ninguém dar ordens ou cobrar resultados se cada um 
souber exatamente o que deve ser feito e estiver motivado para isto. O 
fato de a metodologia ágil pressupor a comunicação constante com o 
cliente e, consequentemente, com toda a equipe, reduz os riscos de 
desentendimentos e potencializa o comprometimento sadio de todos. 
Vale salientar que a chave da metodologia ágil são os profissionais 
proativos, já que em um ambiente dessa natureza é necessário tomar 
decisões rápidas e acertadas o tempo todo, e somente uma equipe 
motivada e bem-informada é capaz de propiciar essa realidade.
Análise e Projeto de Software Orientado a Objetos
35
Em relação a comunicação face to face no time, os maiores problemas 
enfrentados pela maioria das empresas é a falha da comunicação entre 
seus diversos setores, e entre pessoas dentro desses mesmos setores. 
Nas empresas de tecnologia não é diferente, e o problema ainda se 
potencializa em virtude de a tecnologia tornar as relações interpessoais 
mais frias e distantes. 
Figura 12 - Uns dos problemas enfrentados é a falha da comunicação entre as pessoas 
dentro dos mesmos setores
Fonte: Nogueira (2018b, p. 19).
As relações mediadas por mídias digitais, como telefone, e-mail, 
SMS, chat, WhatsApp etc. são mais fluentes em um ambiente empresarial, 
sendo que tais relações foram potencializadas com o grande número de 
profissionais em home office, devido à pandemia do Covid-19. Porém, não 
possuem o calor do contato frente a frente. A conversa flui de maneira 
diferente, com objetivos diferentes, quando temos o companheiro de 
trabalho face a face. 
Análise e Projeto de Software Orientado a Objetos
36
Figura 13 - As relações mediadas por mídias digitais podem ser consideradas fluentes em 
um ambiente empresarial, mas não possuem o calor do contato frente a frente
Fonte: Freepik.
As comunicações digitais ganham no âmbito quantitativo, mas 
pecam no qualitativo, os gestos, entonação de voz e expressões faciais se 
perdem em meio as letras, números, emoticons e dados. O Manifesto Ágil 
estabelece que a forma mais eficaz de troca de informações entre equipes 
é a “frente a frente”, por meio de daily meetings (reuniões diárias), ou mais 
frequentes. Esses encontros podem ganhar um tom de formalidade se 
acontecerem com uma regularidade previamente estabelecida pelo 
gerente de projetos. Contudo, o mais importante mesmo, é que eles 
aconteçam com a maior frequência possível.
Em relação ao software funcional, a engenharia de software, em 
seu nascedouro, baseou-se nos modelos industriais da época em que foi 
criada. Todos os modelos eram processos teoricamente determinísticos 
e controláveis. Pensava-se, à época, que por cada processo era possível 
descobrir o andamento de qualquer projeto, avaliando seus riscos e 
estimando seus prazos e custos. Ela se fundamentava no modelo de 
gerência de projetos em que as atividades eram determinadas, estimadas 
e distribuídas em um cronograma, sendo acompanhadas paulatinamente 
até gerarem o produto. Embora este modelo ainda funcione nas 
indústrias, ele é ineficaz quando aplicado à engenharia de software. 
Análise e Projeto de Software Orientado a Objetos
37
Esta incompatibilidade fez com que fosse desenvolvido um novo ramo 
do gerenciamento de projetos, denominado de Gerência de Projetos de 
Tecnologia da Informação, destinado ao desenvolvimento de software.
Figura 14 - A Gerência de Projetos de Tecnologia da Informação é destinada a ao 
desenvolvimento de software
Fonte: Freepik.
O Manifesto Ágil diz que o bom andamento do projeto só é medido 
pela quantidade de software entregue, em pleno funcionando, afinal, é 
isso que importa ao cliente. Já em relação ao princípio de desenvolvimento 
sustentável, diferentemente da metodologia aplicada à maioria das 
indústrias, considera que o profissional irá render mais proporcionalmente 
ao tempo em que fica em sua estação de trabalho. 
Porém, em uma metodologia ágil de desenvolvimento de software, 
o entendimento é outro. Para esta metodologia, o desenvolvimento é um 
processo essencialmente criativo e, por isto, o profissional deve manter um 
ritmo constante, sem ultrapassar seus limites.
Inclusive, empresas, como Google, Microsoft e outros gigantes da TI, 
ensinaram ao mundo que o local de trabalho não precisa ser “chato”, vigiado 
e formal. Ele pode ser uma extensão da casa do colaborador, com toda 
uma ambiência que favoreça à criatividade, ao prazer e aos momentos de 
descompressão e troca intensa de informações e inspirações entre os pares. 
Para essas empresas, jornada de trabalho, assiduidade e 
pontualidade são paradigmas quebrados pela produtividade e 
comprometimento com os resultados. Os profissionais dessas empresas 
Análise e Projeto de Software Orientado a Objetos
38
trabalham por ideais, prazer e recompensas diretamente proporcionais 
aos resultados que consigam gerar para suas organizações.
Em relação à excelência técnica e bom design, a pergunta que 
todos fazem quando ouvem falar em metodologia ágil é: como manter 
a qualidade e ainda serágil? A resposta para isso é a mesma para uma 
metodologia não-ágil, “Desenvolver um bom código é a chave do sucesso 
de um projeto”.
DEFINIÇÃO:
Por um bom código entende-se um código limpo, enxuto, 
objetivo, organizado e compreensível, um código bem-
feito elimina a necessidade da documentação exaustiva, 
reduz os processos de retrabalho e facilita as tomadas de 
decisão (NAKAGAWA, 2016).
Quando tudo isso está garantido, é fácil manter o ritmo de entrega 
constante de versões e uma teia de confiança é estabelecida entre todos 
os envolvidos, fortalecendo os laços da equipe, tornando o ambiente 
de trabalho sustentável. Já o contrário traz exatamente os resultados 
indesejáveis, ou seja, um código malfeito exige muita documentação, 
gera retrabalho, toma tempo, aumenta os custos do projeto e os prazos 
de entrega.
Em relação ao princípio da simplicidade, aqui não estamos falando 
em procrastinar trabalho, mas em focar naquilo que realmente é importante 
para valorizar o código. Sempre nos perguntamos o que realmente 
é essencial ou quais as formas de tornar algo mais simples. Quando 
tratamos do método ágil, essas perguntas ficam ainda mais frequentes 
em nossas mentes. Os métodos ágeis não implicam necessariamente no 
desenvolvimento rápido de um software. 
Além disso, valer ressaltar que o desenvolvimento rápido é uma 
metodologia para a entrega de projetos em curtos espaços de tempo, 
enquanto a metodologia ágil fala mais sobre a eficiência, eficácia e 
Análise e Projeto de Software Orientado a Objetos
39
efetividade do desenvolvimento. Assim sendo, o princípio da simplicidade 
da metodologia ágil remete sobretudo à objetividade do software – fazer 
exatamente o que o cliente quer ou precisa, sem rodeios (direto ao ponto).
Em relação ao princípio times auto-organizáveis, os gerentes 
insistem em detalhar exaustivamente todos os passos do processo de 
desenvolvimento de software, tentando criar formas de controle para 
garantir que os produtos sejam entregues nos prazos estabelecidos. 
Porém, nem todos os detalhamentos conseguem prever pequenas 
falhas ou mudanças na estrutura, e apenas uma equipe bem-organizada e 
autogerenciável consegue realizar as mudanças necessárias na arquitetura 
do sistema em desenvolvimento ou já implantado. Para a metodologia 
ágil, cada membro da equipe tem que ser seu próprio gerente de projeto, 
daí o termo autogerenciável ou auto-organizável. Assim, as melhores 
arquiteturas, requisitos e design emergem de times auto-organizáveis. E 
sobre o princípio de refinamento e ajuste de comportamento, uma equipe 
autogerenciável precisa discutir técnicas e formas de se tornar cada vez 
melhor. Não existe uma receita de bolo, todos devem se autoavaliar 
e avaliar seus companheiros de modo a identificar necessidades de 
melhorias e pontos positivos que devem ser mantidos ou potencializados 
ainda mais.
Análise e Projeto de Software Orientado a Objetos
40
RESUMINDO:
E então? Gostou do que lhe mostramos? Aprendeu mesmo 
tudinho? Agora, só para termos certeza de que você 
realmente entendeu o tema de estudo deste capítulo, 
vamos resumir tudo o que vimos. Você deve ter aprendido 
que trabalhar com os métodos ágeis requer esforço e 
foco. Não é algo simples para quem está acostumado ao 
modelo orientado à documentação. A metodologia ágil 
não exclui processos como UML ou Processo Unificado, 
ela, na verdade, utiliza esses modelos para se basear e só 
então inicia suas aplicações. De modo geral a engenharia 
de software, cumpri seu dever de trazer metodologias para 
melhorar as práticas do desenvolvimento de sistemas, 
acabou por trazer também um novo problema. Para alguns 
desenvolvedores e arquitetos de software, as metodologias 
utilizadas até o momento eram lentas e repetitivas, tornando 
muitas vezes o trabalho esticado e desnecessário. Para 
resolver tal problema, novas metodologias começaram a 
surgir. Uma delas teve origem por meio de um manifesto, 
conhecido como “Manifesto Ágil”. 
Análise e Projeto de Software Orientado a Objetos
41
Qualidade de Software
OBJETIVO:
Ao término deste capítulo, você será capaz de compreender 
as principais características e princípios da qualidade 
de software. Isto será fundamental para o exercício de 
sua profissão. E então? Motivado para desenvolver esta 
competência? Então vamos lá. Avante!.
Conceito de Qualidade
Um determinado produto tem mais qualidade que outro apenas por 
alguns detalhes determinantes, como pela coloração específica que é 
utilizada em toda aquela linha de produção, ou em virtude de uma técnica 
de fechamento que impede que coisas vazem, enfim, detalhes fazem a 
diferença.
Para a International Standardization Organization (ISO), qualidade é 
o grau em que um conjunto de características inerentes a um produto, 
processo ou sistema cumpre os requisitos inicialmente estipulados para 
estes.
Qualidade tem a ver primordialmente com o processo 
pelo qual os produtos ou serviços são materializados. 
Se o processo for bem realizado, um bom produto virá 
naturalmente. A qualidade reside no que se faz e não 
apenas no que se tem como consequência disto. (ISO9001, 
2008, p. 37)
Para a norma ISO, qualidade é, antes de tudo, a capacidade que 
um serviço, produto, ou informação tem de cumprir sua promessa, e não 
necessariamente apresentar características reconhecidamente boas ou 
excelentes, pois, afinal, o que é bom ou excelente para um pode não ser 
para outro. 
E o que é Qualidade de Software? Será que podemos aplicar a 
mesma definição de qualidade que vimos anteriormente ao software? 
Análise e Projeto de Software Orientado a Objetos
42
Claro que sim, mas podemos recorrer a definições mais específicas para o 
segmento de software, como a estabelecida pela IEEE em seu SWEBOK, 
que é um manual de práticas e regulamentação da entidade. Para o IEEE, 
a qualidade de software está descrita nos quatro seguintes tópicos:
1. Fundamentos de Qualidade de Software – Abrange a cultura e 
ética da qualidade de software, bem como os valores e custos da 
qualidade. Também são os fundamentos que cuidam dos modelos 
e características da qualidade, suas melhorias e segurança;
2. Processos de Gerência de Qualidade de Software – Envolvem a 
garantia de qualidade, as validações e revisões;
3. Considerações Práticas – São a parte mais gerencial. Englobam os 
requisitos, as caracterizações de defeitos, as técnicas de gerência 
e as medidas de qualidade;
4. Ferramentas de Qualidade de Software – Envolve os softwares 
auxiliares de medição e técnicas próprias de garantia de qualidade.
A qualidade de software é uma área de conhecimento extremamente 
importante, tanto que não importa em qual fase do projeto você se 
encontre, sempre haverá de ser considerada a qualidade daquilo em que 
se estiver trabalhando.
Figura 15 - A qualidade de software é uma área de conhecimento muito importante
Fonte: Freepik.
Análise e Projeto de Software Orientado a Objetos
43
Para avaliar a qualidade de um software, muito se discute sobre 
como medir a qualidade de um software em funcionamento, já que 
a referência SWEBOK apenas se refere às características estáticas do 
software, ou seja, àquelas que não irão se alterar. Já para as características 
dinâmicas teremos que nos prender a outras técnicas, muitos gerentes 
de projeto se atêm aos testes de software como a maneira mais eficaz 
de garantir a sua qualidade. Para que a qualidade de um software seja 
atestada, existem algumas características que devem ser avaliadas e 
confirmadas.
 • Funcionalidade – É a capacidade de um software executar as 
suas funções de modo a satisfazer os desejos e necessidades 
do cliente, dentro do contexto declarado no escopo do software. 
Por exemplo, se o software é um antivírus, ele terá qualidade à 
medida em que conseguir fornecer todas as opções de o usuário 
eliminar e se precaver contra todos os tipos de vírus, em todos os 
seus dispositivos;
 • Confiabilidade– É a capacidade do software se manter no nível de 
desempenho, independentemente de seu contexto operacional, 
sendo cumpridos os requisitos mínimos para a sua execução;
 • Usabilidade – É a capacidade do software ser facilmente 
compreendido, com todas as suas funcionalidades devidamente 
compreensíveis e facilmente aprendidas, além de sua operação 
ser simples e eficaz, cumprindo os requisitos estético, dialógico 
e intuitivo;
 • Eficiência – É a capacidade do software manter seu tempo de 
execução compatível com o nível de desempenho esperado de 
acordo com a proposta inicial do sistema;
 • Manutenibilidade – É a garantia de facilidade de manutenção, 
adaptação e atualização do software, isso inclui as capacidades 
de recebimento de paths corretivos, melhoramentos, entre outros.
 • Portabilidade – É a capacidade de transferência do software, 
incluindo variações de idiomas, compatibilidade com diferentes 
sistemas operacionais, hardwares, entre outros.
Análise e Projeto de Software Orientado a Objetos
44
IMPORTANTE:
Quanto à usabilidade de um software, ela tem que cumprir 
um dos pilares fundamentais: “don’t make me think”, ou 
seja, traduzindo do inglês, “não me faça pensar”. Em outras 
palavras, o software tem que ser tão intuitivo que o usuário 
deve ser levado a clicar ou responder aos eventos propostos 
pela sua interface sem ter que parar para raciocinar ou 
procurar pelos elementos de chamada para a ação (call to 
action).
Para a qualidade de software, existem três maneiras de ocorrem 
problemas em um sistema, a primeira está relacionada ao defeito, quando 
há uma instrução ou comando incorreto, dizemos que o software possui 
um defeito. Um defeito muito comum em softwares é a existência de 
botões inoperantes, pois em algum momento do desenvolvimento, o 
código de ligação do botão foi perdido.
VOCÊ SABIA?
Apresentar falhas em seu funcionamento não é uma 
característica dos softwares produzidos por pequenas 
empresas ou desenvolvedores inexperientes. Durante a 
Comdex 98 (evento de tecnologia realizado nos Estados 
Unidos), Bill Gates, então diretor-executivo da Microsoft, 
resolveu dar uma prévia da versão 98 do Windows, quando, 
em plena demonstração, o recém-lançado novo sistema 
operacional da Microsoft apresentou a emblemática “tela 
azul”, bastante conhecida dos usuários das versões 98 e 
XP. Foi um vexame para o experiente empresário Bill Gates, 
principalmente porque o evento estava sendo transmitido 
pela rede CNN para todo o planeta (SOUZA; GASPAROTTO, 
2018).
O segundo problema está relacionado à falha, é considerado como 
um comportamento inesperado, o software continua executando, mas 
sem as condições adequadas. E o terceiro é o erro, quando algo que não 
deveria ocorrer, ocorre.
Análise e Projeto de Software Orientado a Objetos
45
Teste de Software
Muito já se falou sobre teste de software, segundo Roger Pressman, 
engenheiro de software:
Teste é um conjunto de atividades que podem 
ser planejadas antecipadamente e conduzidas 
sistematicamente. Um gabarito de testes de software, que 
é um conjunto de passos no qual pode incluir técnicas de 
projetos de casos de teste e métodos de teste específicos. 
Deve ser definido para o processo de software utilizado no 
projeto. (PRESSMAN; MAXIN, 2009, p. 43)
O teste de software tem por objetivo identificar erros, falhas e defeitos 
em um software, emitindo relatório técnico para fins de correção. Em uma 
rotina simples, uma bateria de testes deve ser preparada para um determinado 
software, os dados pertencentes à massa de teste devem ser inseridos e os 
programas devem ser executados com esses dados selecionados. 
Figura 16 - O teste de software tem objetivo identificar erros, falhas e defeitos, emitindo 
relatório técnico para fins de correção do mesmo
Fonte: Freepik.
Caso o programa execute normalmente, pode-se dizer que o 
software passou no teste, e um novo caso de teste passa a ser preparado, 
até que todas as possibilidades sejam esgotadas. Caso contrário, o 
software deve retornar à análise de código e os erros, falhas e defeitos 
Análise e Projeto de Software Orientado a Objetos
46
identificados devem ser corrigidos. Para uma bateria de testes em um 
software comercial, podemos elencar os seguintes passos:
1. Todos os menus e botões do software devem ser testados, 
validando cada link e destino realizados em relação aos previstos;
2. Todos os formulários devem ser verificados, juntamente ao banco 
de dados, para saber se os dados estão sendo inseridos, gravados, 
alterados, excluídos e consultados de maneira correta;
3. Todas as funções de saída devem ser verificadas, cálculos devem 
ser realizados, e os piores cenários analisados, detalhes não 
podem ser deixados de lado, pois eles podem esconder erros, 
falhas e defeitos ocultos.
VOCÊ SABIA?
Existe uma profissão na área de TI intitulada de “Analista de 
Teste de Software”. Os profissionais com esta especialização 
são cada vez mais requisitados pelas empresas de software. 
A disciplina de teste de software já integra a maioria dos 
programas curriculares dos cursos técnicos e de graduação 
das escolas e faculdades em todo o país. Existem inúmeras 
instituições oferecendo pós-graduação nesta área 
para quem já é graduado em ciências da computação, 
engenharia de computação, análise de sistemas e cursos 
afins. Os segmentos empresariais que mais demandam 
atividades para esses profissionais são as produtoras de 
games e de aplicativos para celulares.
Os especialistas em testes, engenheiros de software e gerentes do 
projeto devem desenvolver estratégias para formatarem seus planos de 
testes (SOUZA, 2013). Este plano é um documento formal que todo projeto 
de software deve possuir para aplicar ao produto antes de colocá-lo em 
produção. A atividade de teste de software requer grande esforço no ciclo 
de desenvolvimento e, se for implementado ao acaso, pode implicar em 
um prejuízo múltiplo de esforço, tempo e valor, além de abrir espaços para 
Análise e Projeto de Software Orientado a Objetos
47
erros, defeitos e falhas, causando uma queda considerável na qualidade 
do software, afetando diretamente sua funcionalidade e confiabilidade.
O teste de software funciona da seguinte maneira, para cada parte 
do sistema um teste deve ser executado, então, quando os requisitos 
forem especificados, deve haver um teste de aceitação. Quando um 
projeto de alto nível surgir, um teste de sistema deve ser executado, 
quando o projeto for detalhado, um teste de integração deve ser planejado 
e executado. Quando começar a codificação, cada unidade deve receber 
seu teste em separado.
Um dos de testes é chamado de unidade, é o teste unitário que 
avalia a menor unidade do código, o objetivo do teste de unidade é 
identificar possíveis falhas no funcionamento das partes independentes 
do software. Este tipo de teste é utilizado para verificar as funções 
independentes, descobrindo facilmente os erros de cada modulo do 
software. O foco desse teste é a identificação de comparações incorretas 
ou fluxos de controle impróprios. Como exemplos de teste de unidade, 
podemos citar as ações de salvar os dados de um cliente, por meio de um 
formulário, no banco de dados, ou mesmo tentar excluir um cliente deste 
mesmo banco de dados.
Figura 17 - O teste de unidade avalia a menor unidade do código com o objetivo de 
identificar possíveis falhas no funcionamento das partes independentes do software
Fonte: Freepik.
Análise e Projeto de Software Orientado a Objetos
48
O teste de integração envolve os componentes que trabalham em 
conjunto, com o intuito de encontrar erros em resultados apresentados 
em função desses componentes articulados entre si. Quando realizamos 
testes de telas de cadastro inteiras, ou quando decidimos testar todo 
um módulo administrativo, como por exemplo, o módulo de biblioteca 
de uma escola, estamos realizando testes de integração. No teste de 
validação, é oque avalia todo um ambiente específico, por meio dos 
requisitos definidos para uma determinada situação, seu objetivo é provar 
que o software está atendendo às solicitações. 
Assim, quando realizamos o teste em determinado sistema 
operacional ou verificamos a conexão com uma base de dados remota, 
ou mesmo quando disparamos diversos acessos ao banco de dados para 
verificar comportamentos, estamos realizando testes de validação.
Já o teste de sistema, é o tipo mais complexo de teste, é realizada 
uma emulação de um ambiente ideal e aplica-se quatro tipos de teste 
para verificar se o sistema pode ser realmente posto à prova, esse teste 
somente poderá ser realizado quando o sistema estiver completo.
Figura 18 - O teste de sistema é o mais complexo no qual é realizado uma emulação de um 
ambiente ideal
Fonte: Freepik.
Análise e Projeto de Software Orientado a Objetos
49
É um tipo de teste que devido à complexidade é importante o 
aprofundamento, são esses os quatro testes aos quais o teste de sistema 
deve ser submetido:
1. Teste de Recuperação – Verifica o processo de recuperação 
de falhas, geralmente são forçadas falhas para avaliar o 
comportamento do sistema, como por exemplo: 
 • Desativar o banco de dados para que ele esteja indisponível;
 • Fechar o sistema sem salvar os dados;
 • Interromper repentinamente o fornecimento de energia etc.
2. Teste de Segurança – Este teste verifica a integridade do sistema, 
provocando-o de formas ilegais, por meio de condições extremas 
de violação. Tentativas de forçar usuário e senha ou tentativas 
de salvamento de informações de forma incorreta são alguns 
exemplos dessas violações;
3. Teste de Estresse – É um teste que verifica o quanto de estresse 
o software aguenta, um cenário extremo é criado apenas para 
esse teste, nos quais todas as condições absurdas são testadas. 
Simulação de milhares de acessos a mesma funcionalidade, 
cliques simultâneos em botões de salvamento etc.;
4. Teste de Desempenho – Verifica como o sistema se comporta 
como um sistema integrado, certifica se o sistema fica lento se 
adicionado novos dados ou telas.
Existem ainda os chamados testes de caixa branca e testes de caixa 
preta.
 • Teste de Caixa Branca – Possui todos os critérios para a realização 
dos testes de fluxo de controle e fluxo de dados, geralmente é 
focado em avaliar a parte estrutural do software. É quase sempre 
um teste executado em linha de código, para testar lógicas, 
englobas as técnicas usadas nos testes de unidade e de integração.
 • Teste de Caixa Preta – Para esse teste a parte interna do software 
é desconsiderada, focando-se apenas na parte externa. Ou seja, o 
teste de caixa preta verifica como o software está se comportando 
Análise e Projeto de Software Orientado a Objetos
50
no sistema de uma maneira geral. Este é o teste aplicado nas 
unidades MVP - Minimum Viable Product, (Produto Mínimo Viável) 
lançadas, engloba as técnicas usadas nos Testes de Aceitação e 
Sistema.
É importante salientar que esses testes têm como objetivo a 
busca pela qualidade de um bom sistema, ou seja, um software, no qual 
é importante ser bem testado antes de apresentá-lo para o cliente ou 
disponibilizar para o usuário final.
RESUMINDO:
E então? Gostou do que lhe mostramos? Aprendeu mesmo 
tudinho? Agora, só para termos certeza de que você 
realmente entendeu o tema de estudo deste capítulo, 
vamos resumir tudo o que vimos. Você deve ter aprendido 
que a qualidade de software é um item extremamente 
importante para os processos de criação de projetos de 
software. O fato de se trabalhar com orientação a objetos 
facilita sobremaneira o processo de teste de software, pois, 
com o código limpo fica bem mais fácil identificar erros de 
programação. Vimos também que existem três tipos de 
inconsistências em um software: erros, falhas e defeitos, 
vimos ainda os vários tipos de teste de software que são 
implementados pelo analista de testes. E a busca por teste 
é para propor a qualidade do produto, segundo estudos, 
a qualidade está ligada às necessidades internas de cada 
um. Dependendo de quem seja o alvo, a qualidade será 
mensurada pela aparência, pelo material, pelo preço, ou 
seja, existem diversas dimensões de qualidade, para isso a 
importância da realização dos testes.
Análise e Projeto de Software Orientado a Objetos
51
REFERÊNCIAS
CAVALCANTI, A. Introdução ao Processo Unificado: PU. DCA 
UFRN, 2018. Disponível em: https://www.dca.ufrn.br/~anderson/FTP/
dca0120/P2_Aula2.pdf. Acesso em: 07 dez 2021.
CONCEIÇÃO, J. D.; SILVEIRA, S. R. Aplicação de Metodologias 
Ágeis para Desenvolvimento de Software: um Estudo de Caso na 
Empresa Alliance Software. Santa Maria: UFSM – Universidade Federal de 
Santa Maria, 2015. Disponível em https://goo.gl/EnJLSZ. Acesso em: 07 
dez 2021.
ISO9001. Quality management systems: Requirements. ISO, 2008. 
Disponível em: https://www.iso.org/standard/46486.html. Acesso em: 07 
dez 2021.
NAKAGAWA, E. Y. Modelos de Processos de Software. USP, 
2016. Disponível em https://edisciplinas.usp.br/mod/resource/view.
php?id=477720. Acesso em: 07 dez 2021. 
NOGUEIRA, João. Análise e Projeto de Software Orientado a 
Objetos. Desenvolvimentos Iterativo e Evolutivo. São Paulo: Uninassau, 
2018a.
NOGUEIRA, João. Análise e Projeto de Software Orientado a 
Objetos. Desenvolvimento Ágil de Projetos. São Paulo: Uninassau, 2018b.
SOUZA, K. P.; GASPAROTTO, A. M. A importância da atividade de 
Teste no Desenvolvimento de Software. In: XXXIII ENCONTRO NACIONAL 
DE ENGENHARIA DE PRODUCAO, São Paulo, 2013. Disponível em: www.
abepro.org.br/biblioteca/enegep2013_TN_STO_177_007_23030.pdf. 
Acesso em: 07 dez 2021.
SOUZA, L. M. “Tela da morte” do Windows faz empresas (e até Bill 
Gates) passarem vergonha; veja gafes. TecMundo, 2013. Disponível em: 
https://www.tecmundo.com.br/software/125218-tela-morte-windows-
ela-diz-resolver-erros.htm. Acesso em: 07 dez 2021.
Pressman, R.; MAXIM, B. Software Engineering: A Practitioner’s 
Approach. New York: McGraw-Hill Higher Education, 2009.
Análise e Projeto de Software Orientado a Objetos
about:blank
about:blank
about:blank
about:blank
about:blank
about:blank
about:blank
about:blank
	Processo Unificado - Construção e Transição
	Fase de Construção
	Fase de Transição
	Desenvolvimentos Iterativo e Evolutivo 
	Processo de Desenvolvimento de Software
	Processo de Desenvolvimento de Software
	Métodos de Abordagem para o Processo de Desenvolvimento de Software
	Desenvolvimento Ágil de Projetos
	O Manifesto “Ágil”
	Princípios da Metodologia Ágil
	Qualidade de Software
	Conceito de Qualidade
	Teste de Software