Engenharia de Software

Engenharia de Software
E NGENHARIA
DE
Thiago Schaedler Uhlmann
SOFTWARE
THIAGO SCHAEDLER UHLMANN
Código Logístico Fundação Biblioteca Nacional
ISBN 978-85-387-6552-3
59009 9 788538 765523

IESDE BRASIL
2020
© 2020 – IESDE BRASIL S/A.
É proibida a reprodução, mesmo parcial, por qualquer processo, sem
autorização por escrito do autor e do detentor dos direitos autorais.
Capa: IESDE BRASIL S/A.

Imagem da capa: Andrey Suslov/mydegage/Shutterstock
CIP-BRASIL. CATALOGAÇÃO NA PUBLICAÇÃO

SINDICATO NACIONAL DOS EDITORES DE LIVROS, RJ
U31e
Uhlmann, Thiago Schaedler
Engenharia de software / Thiago Schaedler Uhlmann. - 1. ed. -
Curitiba [PR] : IESDE, 2020.
188 p.
Inclui bibliografia
ISBN 978-85-387-6552-3
1. Engenharia de software. 2. Software - Desenvolvimento. I.

Título.
CDD: 005.1
19-60521
CDU: 004.41
Todos os direitos reservados.

IESDE BRASIL S/A.
Al. Dr. Carlos de Carvalho, 1.482. CEP: 80730-200
Batel – Curitiba – PR
0800 708 88 88 – www.iesde.com.br
Doutorando em Engenharia de Produção e Sistemas pela
Pontifícia Universidade Católica do Paraná (PUCPR). Mestre
em Design pela Universidade Federal do Paraná (UFPR).
Bacharel em Administração pela FAE Centro Universitário.
Atua profissionalmente como analista de processos ISO
9001:2015 e como professor do ensino superior nas áreas
de Gestão da Inovação, Governança de TI, Modelagem de
Processos de Negócio e Gestão de Negócios.
Sumário
Apresentação 7
1. Introdução à engenharia de software 9

1.1 Quem é o engenheiro de software 9
1.2 A prática da engenharia de software 13
1.3 O engenheiro de software e outros profissionais 17
2. Planejamento e processo de software 23

2.1 Estrutura básica do desenvolvimento de software 23
2.2 Modelos tradicionais de desenvolvimento 25
2.3 Modelos ágeis de desenvolvimento 33
3. Engenharia de requisitos 39
3.1 Métodos para a coleta de requisitos 40
3.2 Classificação de requisitos 48
3.3 Especificação e apresentação de requisitos 52
4. Modelagem de software com a UML 59

4.1 O que é a UML e por que utilizá-la? 60
4.2 Diagramas comportamentais 67
4.3 Diagramas estruturais 75
5. Gestão de projetos de software 83

5.1 Projeto de software: elementos básicos 83
5.2 Projeto de software: elementos acessórios 89
5.3 Projetos de arquiteturas de software 94

6. Gestão da qualidade em engenharia de software 103
6.1 Normas de qualidade 104
6.2 Qualidade em software 108
6.3 Melhorias em software 114
7. Testes e engenharia reversa em software 123

7.1 Modalidades de testes em software 124
7.2 Realização de testes 132
7.3 Manutenções e reengenharia 140
8. Práticas de engenharia de software 147

8.1 Design de interação 148
8.2 Jogos digitais 157
8.3 Projeto de WebApps e aplicativos móveis 167
Gabarito 175
Apresentação
As tecnologias da informação e comunicação estão

cada vez mais presentes em nosso cotidiano. Utilizamos
computadores, smartphones, tablets e outros dispositivos,
que têm contribuído com grandes áreas, como nos avanços da
medicina, ou com ações mais corriqueiras, como para pedir
um lanche.
Embora tenhamos familiaridade com esses dispositivos,

muitas vezes, não nos atentamos sobre o quão complexo é
elaborá-los, visto que somente funcionam se operados por
softwares, os quais, para serem desenvolvidos, exigem do
engenheiro a responsabilidade para gerenciar projetos e
modelar, desenvolver e implantar softwares.
Desse modo, a engenharia de software é uma área do

conhecimento que tem sido cada vez mais procurada dentre
as engenharias e as áreas relacionadas à TI. Isso se deve
à crescente demanda do mercado em procurar softwares
que, além de funcionarem adequadamente, sejam seguros,
confiáveis, resistentes a ataques cibernéticos e que, portanto,
não apresentem falhas, principalmente durante momentos
críticos de sua utilização.
O objetivo principal desta obra é apresentar a você,

estudante, um panorama geral da atuação profissional do
engenheiro de software. Sendo assim, no primeiro capítulo,
vamos iniciar com uma breve apresentação do que faz o
engenheiro de software e sua atuação profissional em equipes
multidisciplinares, ou seja, formadas por profissionais de
diferentes áreas do conhecimento.
Nos capítulos seguintes, trataremos de temas essenciais,

como métodos de desenvolvimento de software, engenharia de
requisitos, modelagem, gestão de projetos, testes e engenharia
reversa. Por fim, apresentaremos algumas oportunidades de
atuação do profissional de software, como no desenvolvimento
de interfaces, jogos eletrônicos e aplicativos para dispositivos
móveis. Dessa forma, por meio da leitura deste livro, você
terá a oportunidade de conhecer essa área cada vez mais
promissora.
Bons estudos!
1
Introdução à engenharia de software
Neste capítulo, você estudará o perfil do engenheiro de software

e o mercado de atuação desse profissional, que é cada vez mais
promissor.
Conhecerá a rotina de trabalho na engenharia de software,
compreendendo as principais atividades realizadas e a relação desse
engenheiro com as equipes de trabalho multidisciplinares, isto é,
formadas por profissionais de diferentes áreas do conhecimento.
Você também aprenderá que, como os demais profissionais de
engenharia, o engenheiro de software deve saber resolver problemas
e maximizar o uso de recursos. Desse modo, serão abordados os
processos básicos da engenharia de software, como engenharia de
requisitos, planejamento, desenvolvimento, testes e manutenção.
Além disso, você compreenderá as diferentes maneiras de se
organizar equipes, denominadas paradigmas.
Vídeo 1.1 Quem é o engenheiro de

software
Você sabe o que exatamente faz um engenheiro
de software?
Embora o nome guarde relações com a
engenharia, pois, dentre as várias atribuições,
também atua com projetos e com engenheiros, o engenheiro de
software é um profissional da área de Tecnologia da Informação.
10 Engenharia de Software
Resumidamente, o engenheiro de software é o

profissional responsável pelo desenvolvimento e
pela implantação de produtos, serviços e sistemas de
software, desde a ideia inicial até o produto final.
A definição de engenharia de software sofre pequenas variações

de acordo com cada autor. Schach (2010, p. 4), por exemplo,
define engenharia de software como “uma disciplina cujo objetivo
é produzir software isento de falhas, entregue dentro do prazo e
orçamento previstos, e que atenda às necessidades do cliente”.
De acordo com o IEEE (Institute of Electrical and Electronic
Engineers) – entidade internacional que definiu as diretrizes
dessa área – engenharia de software trata-se da “aplicação de
uma abordagem sistemática, disciplinada e quantificável no
desenvolvimento, na operação e na manutenção de software, isto
é, a aplicação de engenharia ao software” (IEEE apud PRESSMAN;
MAXIM, 2016).
Como você pode notar, desenvolver software requer disciplina
e visão lógica e, ao mesmo tempo, sistêmica. Logo, assim que se
gradua, um engenheiro de software deve ser capaz de coordenar
projetos, administrar equipes de trabalho e, inclusive, gerenciar
conflitos que podem surgir durante o processo de desenvolvimento.
Desse modo, o trabalho de um engenheiro de software se diferencia
do trabalho de um desenvolvedor, ao passo que, conforme afirma
Wazlawick (2013), o engenheiro de software consiste em um projetista,
sendo o desenvolvedor de software um executor do processo.
Introdução à engenharia de software 11
O engenheiro de software deve, portanto, “fornecer aos

desenvolvedores (inclusive gerentes, analistas e designers) as
ferramentas e processos que deverão ser usados e será o responsável
por verificar se esse uso está sendo feito efetivamente e de forma
otimizada” (WAZLAWICK, 2013, p. 19).
Ainda segundo Wazlawick (2013), o surgimento da engenharia
de software se deu em plena Guerra Fria, em que um grupo de
estudos da OTAN (Organização do Tratado para o Atlântico Norte),
em 1967, definiu que as atividades de software deveriam utilizar
as mesmas filosofias e disciplinas de engenharia, uma vez que a
qualidade do software desenvolvido, até então, era péssima.
Existem diferenças entre as áreas de engenharia de software,
engenharia da computação e ciência da computação. O engenheiro
de software atua em projeto, desenvolvimento e implantação de
software; o engenheiro da computação se volta ao desenvolvimento
de hardware, como computadores e equipamentos eletrônicos.
O cientista da computação, por sua vez, desenvolve os modelos
matemáticos, os algoritmos e as demais ferramentas teóricas que
serão utilizados pelo engenheiro de software, o qual é, portanto, o
elo de ligação entre os demais profissionais de TI.
Atualmente, o mercado encontra-se promissor para o engenheiro
de software. Conforme dados da ABES (Associação Brasileira de
Empresas de Software), o Brasil está em 1º lugar na América Latina
em investimentos na área de software, e em 9º lugar mundialmente.
Segundo a mesma entidade, hoje esse setor representa 1,9% do PIB
nacional, sendo um mercado de US$18,6 bilhões.
Figura 1 – O engenheiro de software é requisitado por organizações

de diferentes áreas de atuação.
Preechar Bowonkitwanchai/Shutterstock
O engenheiro de software vem sendo requisitado em empresas
de todos os portes, seja para atividades de desenvolvimento ou
para gerenciamento de projetos. Além disso, esse profissional
tem sido muito procurado para trabalhar em startups, ou seja,
empresas de base tecnológica que atuam em ambientes de mercado
de extrema incerteza, sendo necessário que o engenheiro domine
outras habilidades, como trabalhar em equipes multidisciplinares
e saber resolver problemas com o máximo de eficiência.
Um engenheiro de software deve saber que uma organização tem
restrições financeiras, procedimentos a serem respeitados e perfis
profissionais distintos. Logo, precisa considerar adequadamente
essas situações em seu trabalho, bem como em seus projetos.
Esse profissional é o responsável pela gestão consciente
de recursos humanos, de materiais financeiros e tecnológicos
necessários para o desenvolvimento do software e de processos
de desenvolvimento, desde a coleta de requisitos até a entrega do
software em sua versão final.
A atividade do engenheiro de software está sendo regulamentada

pela Resolução n. 1.100 do CONFEA (Conselho Federal de
Engenharia e Agronomia), a qual defende que esse profissional
integra o grupo dos engenheiros eletricistas, tendo direitos e deveres
de um engenheiro conforme a legislação em vigor (CONFEA, 2018).
Assim, é muito importante entendermos as competências
necessárias para se tornar um engenheiro de software e a atuação
desse profissional em equipes multidisciplinares.
Vamos estudar, na próxima seção, como é a prática profissional
de um engenheiro de software.
Vídeo 1.2 A prática da engenharia de

software
O engenheiro de software é um profissional
de inovação e um projetista. Sendo assim, seus
projetos resultam em produtos que resolvem
problemas da sociedade para os quais, até aquele
momento, ainda não havia uma solução mais eficaz ou mesmo
existente.
A inovação em engenharia de software pode acontecer de
diferentes formas: a primeira, mais frequente, é denominada
inovação incremental ou melhoria contínua, em que há
incrementação ou desenvolvimento de algo novo com base em
uma solução existente; e a segunda, denominada inovação radical,
consiste na criação de algo totalmente novo, do “zero”.
As aplicações da engenharia de software na sociedade são muito
variadas, assim como os métodos utilizados para se desenvolver
um software.
Desde a criação dos computadores, a forma de se desenvolver
programas tem evoluído de modo acelerado, cabendo ao profissional
de engenharia de software manter-se constantemente atualizado a

respeito dessas técnicas.
Dentre as aplicações, pode-se citar o desenvolvimento de
aplicativos (locais e acessados pela internet), sistemas operacionais,
sistemas para simulação, jogos eletrônicos, sistemas de banco de
dados e sistemas para automação (robôs industriais, por exemplo).
Figura 2 – O engenheiro de software é um profissional de inovação e

projetos.
PIYAWAT WONGOPASS/Shutterstock
O engenheiro de software, como todo engenheiro, é especialista

em resolver problemas e fazer as coisas acontecerem. Por meio da
aplicação de métodos, processos e controles, uma simples ideia pode
se transformar em um produto de software altamente lucrativo e que
resolverá muitos problemas da sociedade.
Desse modo, é preciso, primeiramente, considerar que o
desenvolvimento de software é um processo composto de várias
atividades consecutivas, sendo que para cada atividade existem
métodos e ferramentas específicos, conforme apresentados a seguir.
• Engenharia de requisitos
Conforme o nome sugere, consiste na definição, com a
participação do cliente ou usuário, do que o software necessita ter
em termos de funcionalidade, requisitos de segurança, aparência das
telas, botões, menus, compatibilidade com sistemas operacionais

específicos, dentre outros.
Além disso, a engenharia de requisitos trata das restrições,
ou seja, dos elementos de limitação que podem ser inseridos em
um software para evitar operações indesejadas. Um software para
automação industrial, por exemplo, deve prever a existência de um
botão que, no caso de emergências e risco de acidentes, possa ser
acionado fazendo com que todo o sistema pare.
Portanto, definir requisitos é essencial para que o software, uma
vez desenvolvido, atenda às necessidades do usuário.
• Planejamento
Esta é a fase criativa do desenvolvimento de software. Envolve
definir a sua arquitetura; criar esboços das telas; definir os
diagramas básicos (diagramas de classes e atividades, por exemplo)
e as linguagens de programação a serem utilizadas para cada
funcionalidade do software.
Além disso, nessa fase pesquisa-se por soluções já existentes em
software e que atendam, mesmo que de modo similar, os requisitos
definidos no primeiro passo. Essas soluções podem ser aproveitadas
no processo de construção do software (próxima etapa) para que a
equipe de trabalho não gaste tempo desenvolvendo funcionalidades
e arquiteturas que já existem e encontram-se disponíveis.
• Desenvolvimento ou codificação do software
Após ser planejado e esboçado, desenvolve-se o código-fonte do
software e de suas partes.
Durante o processo de desenvolvimento, podem surgir incidentes
ou problemas, forçando o projeto a ser modificado, ou erros podem
passar despercebidos e somente aparecer quando o software estiver
concluído.
Recomenda-se, nessa fase, o uso de técnicas de desenvolvimento

e a realização de testes em tempo real, pois, uma vez que o software
estiver desenvolvido, modificações podem custar caro.
• Fase de testes
Após desenvolvido e codificado, o software deve ser testado –
atividade que deve ser repetida sempre que necessária. Isso se deve
porque erros – mais conhecidos como bugs – podem custar caro,
principalmente se o software já estiver em fase de lançamento.
A realização dos testes não precisa, necessariamente, ser feita
pelo profissional responsável pelo desenvolvimento do software.
Aliás, é recomendado que não seja, pois, profissionais externos têm
uma visão diferente do software e tendem a encontrar erros não
percebidos pelos programadores. Inclusive, existem profissionais de
desenvolvimento de sistemas capacitados, especificamente, para a
realização dessa tarefa.
• Manutenção e melhorias
Após o software ser desenvolvido e lançado, é necessária a
realização de manutenção e melhorias contínuas.
As necessidades do consumidor e as tecnologias encontram-se
em constante mutação, sendo necessária a manutenção do software,
que é realizada por meio de técnicas, como a do versionamento,
em que diferentes versões são desenvolvidas com aprimoramentos,
correções de falhas e novas funcionalidades.
Em muitos casos, o processo de desenvolvimento de um software
não tem fim, pois sempre há alguma funcionalidade a incluir. Por
esse motivo, softwares de versionamento têm sido cada vez mais
utilizados por desenvolvedores para abrigar suas criações em
contínuo estágio de desenvolvimento.
Além dos cinco métodos descritos, é importante ressaltar que,
como em toda profissão, a prática de engenharia de software deve
se ater a princípios éticos, de modo que os resultados do trabalho

do profissional não prejudiquem a si e a organização ou o cliente.
Dessa forma, Sommerville (2011) cita como princípios éticos na
engenharia de software: respeitar a confidencialidade das
informações do cliente; não aceitar trabalhos fora de sua competência
profissional; respeitar direitos de propriedade intelectual e realizar
bom uso de computadores (não jogar em horário de trabalho ou
espalhar vírus e malwares, por exemplo).
Vídeo 1.3 O engenheiro de software

e outros profissionais
Em uma organização, o engenheiro de
software pode assumir várias funções, atuando
no desenvolvimento de software, na gestão de
equipes ou mesmo como consultor.
Desse modo, sendo um profissional que produz inovação,
o engenheiro de software deve estar preparado para conviver e
trabalhar com pessoas de diferentes áreas do conhecimento, como
outros engenheiros, administradores, designers, outros profissionais
da área de TI, profissionais da área jurídica, matemáticos e
profissionais de ciências humanas.
A esses grupos formados por profissionais de diferentes áreas do
conhecimento (equipes multidisciplinares), o papel do engenheiro
de software é abrangente, podendo variar desde a definição dos
requisitos do projeto e a programação (ou codificação) do software,
até a gestão do projeto como um todo.
Figura 3 – O engenheiro de software é um profissional que trabalha
com equipes de diferentes áreas do conhecimento.
Song_about_summer/Shutterstock
Durante o processo de desenvolvimento de software, é
necessária a definição de papéis e responsabilidades, de modo que
cada profissional saiba exatamente o que fará. Sommerville (2011)
cita como exemplos as funções de gerente de projeto, gerente de
configuração e programador.
Sendo tão relevante para o sucesso das organizações, o engenheiro
de software deve apresentar uma série de competências relacionadas
tanto à sua formação pessoal quanto ao seu desempenho profissional.
Essas competências, conforme afirmam Pressman e Maxim (2016),
são o senso de responsabilidade individual, a consciência aguçada
das necessidades de sua equipe de trabalho, a honestidade, a
capacidade de se mostrar resiliente sob pressão, o senso de lealdade,
a atenção aos detalhes e o pragmatismo.
Constantine (1993 apud PRESSMAN; MAXIM, 2016)
enumera paradigmas, ou padrões, para a formação de equipes de
desenvolvimento. Esses paradigmas consideram questões como a
formalidade de hierarquias, a colaboração entre os membros da
equipe e a capacidade de solucionar problemas.
No paradigma fechado, a principal característica é a existência
de uma hierarquia formal entre gestores e colaboradores, em que
se predomina a ordem. Porém, essa estrutura pode não ser ideal
quando se necessita desenvolver a criatividade e a inovação nas
equipes de trabalho, uma vez que a comunicação entre os membros,

nesse paradigma, tende a ser mais restrita.
No paradigma randômico, o que predomina é a iniciativa
individual dos membros da equipe. Opostamente ao paradigma
fechado, esse é mais adequado para o desenvolvimento de
inovações. Porém, por depender de decisões individuais, podem
surgir conflitos, caso seja preciso agir de modo mais ordenado, uma
vez que nesse paradigma a possibilidade de surgirem divergências
de opiniões é maior.
No paradigma sincronizado, o problema é segmentado de modo
que os membros da equipe organizem-se para que cada um trabalhe
em uma parte. Porém, a comunicação entre os membros, nesse caso,
é prejudicada, uma vez que cada equipe, desenvolvendo apenas uma
parte do software, terá conhecimento somente da parte que desenvolve,
tendo pouco ou nenhum conhecimento das demais partes.
No paradigma aberto, por sua vez, predominam-se a
colaboração, a comunicação e o consenso nas decisões. Para projetos
inovadores e mais complexos, equipes estruturadas nesse paradigma
tendem a se destacar. Como exemplo, têm-se as equipes estruturadas
em rede, em que os profissionais colaboram mutuamente.
Independentemente do paradigma escolhido, é importante que
o engenheiro de software saiba organizar a equipe de trabalho de
modo que as potencialidades de cada membro sejam aproveitadas
ao máximo para o desempenho das atividades do projeto. Para isso,
é necessário que o gestor de projetos conheça as necessidades e saiba
reconhecer os esforços de sua equipe de trabalho.
Sommerville (2011) enumera quatro fatores essenciais no
gerenciamento de equipes: consistência, inclusão, honestidade e respeito.
A consistência diz respeito à valorização por igual de cada
membro da equipe, considerando que as pessoas não devem sentir
que seu trabalho é desvalorizado ou subvalorizado.
A inclusão é derivada da consistência. Uma vez que o trabalho

de um profissional deve ser valorizado, as propostas apresentadas
por este devem ser levadas em consideração, independentemente do
cargo ou do tempo de trabalho na organização.
A honestidade deve permear toda a equipe. O engenheiro de
software deve estar consciente do seu nível técnico e ser honesto
com os demais membros da equipe, não supervalorizando ou
subvalorizando as suas habilidades.
O respeito é essencial em uma equipe multidisciplinar, na qual
cada profissional deve ter consciência das diferenças do outro na
maneira de pensar e de trabalhar, sem atribuir conclusões precipitadas
em relação à competência deste em realizar as atividades do projeto.
Isso é importante para que as competências de cada membro da
equipe sejam adequadamente aproveitadas, sem que preconceitos
prejudiquem o desempenho do projeto como um todo.
Desse modo, saber trabalhar em equipe é uma competência
essencial para o engenheiro de software, uma vez que, sendo um
gestor, necessita obter o melhor aproveitamento de profissionais e
demais recursos necessários para o desenvolvimento de um software.
Considerações finais
Conforme estudamos, as atribuições do engenheiro de software
são bastante diversas, assim como a forma como ele desempenha o
trabalho e organiza as equipes.
Além disso, compreendemos a importância do mercado de
software no Brasil e como este se encontra em crescimento, podendo
observar que a atuação do engenheiro de software não se resume a
atividades de programação, visto que, além de desenvolvedor, ele é
gestor de projetos.
Por fim, pudemos entender, também, que o engenheiro de

software é um profissional que sabe transformar necessidades e
requisitos em soluções lucrativas e operacionalmente eficazes.
Ampliando seus conhecimentos

• O QUE UM ENGENHEIRO de software faz? 2018.
1 vídeo (8min26s). Publicado pelo canal Código
Fonte TV. Disponível em: https://www.youtube.com/
watch?v=wdU9L3DqU2w. Acesso em: 9 out. 2019.
Este vídeo explica, com uma linguagem clara e descontraída,
as principais atividades de um engenheiro de software, além
de apresentar de modo resumido o que são atividades de
projeto, requisitos, processos, construção, testes, qualidade,
depuração, entrega e manutenção.
• CONFEA – Conselho Federal de Engenharia e Agronomia.

Resolução n. 1.100, de 24 de maio de 2018. Diário Oficial
da União, Brasília, DF, 8 jun. 2018. Disponível em: http://
www.in.gov.br/materia/-/asset_publisher/Kujrw0TZC2Mb/
content/id/21012726/do1-2018-06-08-resolucao-n-1-100-
de-24-de-maio-de-2018-21012669. Acesso em: 9 out. 2019.
Esta resolução do Conselho Federal de Engenharia e
Agronomia (CONFEA) regulamenta a atividade de engenharia
de software. Conforme mencionado nesse capítulo, por meio
dessa resolução, o profissional de engenharia de software
integra o grupo dos engenheiros eletricistas, sendo, como todo
engenheiro, um especialista em projetos.
Atividades
1. Agora que você sabe o que faz um engenheiro de software, é
hora de identificar como está o mercado de trabalho na área.
Pesquise, em sites de emprego, a disponibilidade de vagas de
trabalho para engenheiro de software. Escolha três vagas do
seu interesse e descreva por que você ser interessou por elas.
2. Cite e descreva os quatro fatores essenciais para o

gerenciamento de equipes de trabalho em engenharia de
software.
3. Um dos processos essenciais na engenharia de software

é a engenharia de requisitos. Qual é a importância desse
processo?
Referências
CONFEA – Conselho Federal de Engenharia e Agronomia. Resolução
n. 1.100, de 24 de maio de 2018. Diário Oficial da União, Brasília, DF, 8
jun. 2018. Disponível em: http://www.in.gov.br/materia/-/asset_publisher/
Kujrw0TZC2Mb/content/id/21012726/do1-2018-06-08-resolucao-n-1-
100-de-24-de-maio-de-2018-21012669. Acesso em: 9 out. 2019.
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software: uma abordagem

profissional. Porto Alegre: AMGH, 2015.
SCHACH, S. Engenharia de software: os paradigmas clássico e orientado a

objetos. Porto Alegre: AMGH, 2010.
SOMMERVILLE, I. Engenharia de software. São Paulo: Pearson Prentice

Hall, 2011.
WAZLAWICK, R. S. Engenharia de software: conceitos e práticas. Rio de

Janeiro: Elsevier, 2013.
2
Planejamento e processo de software
Agora que sabemos o que faz um engenheiro de software, os

princípios que orientam a prática desse profissional e a relação
dele com a equipe de trabalho, vamos conhecer, neste capítulo, o
processo básico do desenvolvimento de software.
Além disso, vamos aprender os principais modelos utilizados para
o desenvolvimento de sistemas, desde os tradicionais, já consagrados
pela indústria de software, até os ágeis, cada vez mais utilizados.
Com relação aos tradicionais, vamos estudar os modelos em
cascata, em espiral, em V, cíclico e RUP (Rational Unified Process).
Já com relação aos ágeis, vamos conhecer os modelos XP (Extreme
Programming), Scrum e AUP (Agile Unified Process).
Esses estudos são fundamentais, pois tratam de modelos que
acompanharão a sua carreira como engenheiro de software.
2.1 Estrutura básica do

Vídeo
desenvolvimento de software
Para começar a compreender o processo
básico de desenvolvimento de software, imagine,
por exemplo, que você vai construir uma casa.
Antes de iniciar a construção, seja contratando
um profissional de arquitetura e engenharia – que é o recomendado
– ou construindo a sua casa por conta própria, você vai precisar de
um projeto e de profissionais que o executem, os quais nortearão o
seu trabalho.
O mesmo ocorre com o desenvolvimento de um software, pois

esse necessita de modelos para norteá-lo e garantir que, ao fim de
todo o processo, ele seja funcional e confiável.
Todo modelo, seja tradicional ou ágil, segue uma metodologia
genérica composta de cinco etapas: comunicação, planejamento,
modelagem, construção e entrega (PRESSMAN; MAXIM, 2016).
Na primeira etapa, de comunicação, é realizado o contato com as
partes interessadas para tratar de procedimentos do início do projeto
(contratos, termos de abertura, dentre outros) e levantamento dos
requisitos funcionais (relacionados à funcionalidade do sistema) e não
funcionais (relacionados à segurança e às configurações do sistema).
Já na segunda etapa, de planejamento é definido o cronograma de
atividades dos profissionais envolvidos, as estimativas de utilização
de recursos (humanos, materiais, financeiros e tecnológicos) e
como será realizado o acompanhamento do projeto (a definição de
métricas de desempenho, por exemplo). A realização dessa etapa de
modo efetivo depende da prévia definição dos requisitos da etapa
anterior; ou seja, quanto mais detalhado for o levantamento dos
requisitos, melhor será o planejamento.
Na terceira etapa, de modelagem, também conhecida como
implementação e teste unitário, são realizadas as atividades de
desenvolvimento do software propriamente dito. É nessa fase que
o projeto do software começa a ganhar forma, com os primeiros
diagramas e fluxogramas (diagramas UML, por exemplo).
Na construção, a quarta etapa, os requisitos são traduzidos
em linhas de código, as quais formam os programas componentes
do conjunto de software. Cada programa desenvolvido é testado
unitariamente para a verificação de possíveis problemas ou “bugs”;
desse modo, se encontrados, devem ser prontamente corrigidos,
garantindo que, ao fim de todo o processo, o software esteja seguro
e plenamente funcional. Essas unidades de programa desenvolvidas
Planejamento e processo de software 25
são integradas no formato de um sistema completo, o qual também

deve ser testado.
Por fim, na quinta etapa, acontece a entrega do sistema
desenvolvido ao cliente, que também deverá testá-lo e verificar
se atendeu aos seus requisitos. Nessa fase há também a realização
de atividades de suporte técnico; assim, conforme necessário, ao
instalar o sistema e colocá-lo em operação, manutenções corretivas
e melhorias devem ser efetuadas.
Essas cinco etapas dizem respeito à estrutura básica de
desenvolvimento de um software; ela é aplicada, de modo direto ou
com adaptações, nos modelos tradicionais e ágeis.
Como você pode perceber, desenvolver um software não é uma
tarefa simples, uma vez que requer interação com o usuário,
planejamento e muitas etapas de testes. No entanto, os modelos
descritos a seguir possibilitam muitas formas de aplicar as cinco
etapas anteriormente descritas.
2.2 Modelos tradicionais

Vídeo
de desenvolvimento
Apesar da existência dos modelos ágeis,
conforme vamos estudar na próxima seção, os
modelos tradicionais de desenvolvimento ainda
são utilizados em projetos em que a existência de
documentação e maior estruturação do software sejam relevantes.
Os principais modelos tradicionais fazem uso da estrutura básica
de desenvolvimento, descrita na seção anterior (comunicação,
planejamento, modelagem, construção e entrega), sendo que se
diferenciam dos modelos ágeis pela forma e sequenciamento de
aplicação de cada etapa da estrutura, uma vez que, nos modelos
tradicionais, podem ser em cascata, em espiral, em V ou em formato
cíclico, além do modelo RUP (Rational Unified Process).
• Modelo em cascata
É o modelo mais antigo de desenvolvimento em engenharia de
software e, de acordo com Sommerville (2011, p. 20), é “um processo
dirigido a planos – em princípio, você deve planejar e programar
todas as atividades do processo antes de começar a trabalhar nelas”
(SOMMERVILLE, 2011, p. 20).
Nesse modelo, a estrutura básica de desenvolvimento é aplicada
de modo sequencial, ou seja, com uma atividade precedendo a
outra. Além disso, para passar de uma atividade a outra, é necessária
a aprovação do responsável pelo desenvolvimento, geralmente por
meio de um documento assinado. Dessa forma, nenhuma atividade
pode ser iniciada até que a anterior esteja concluída, e o software é
colocado em uso somente na etapa final (entrega).
A Figura 1, a seguir, representa o modelo em cascata. Observe
que nesse modelo o processo flui de modo constante, como em uma
cascata, e as cinco etapas são aplicadas sequencialmente.
Figura 1 – Modelo em cascata
Comunicação
Planejamento
Modelagem
Construção
Entrega
Fonte: Elaborada pelo autor com base em Pressman e Maxim, 2016.

O modelo em cascata é adequado para ambientes de

desenvolvimento estável, com pouca ou nenhuma alteração de
requisitos, pois se trata de um modelo inflexível.
• Modelo em espiral
Esse modelo possibilita a repetição das etapas de desenvolvimento
de modo cíclico. Nesse caso, as etapas de comunicação, planejamento,
modelagem, construção e entrega se repetem com sucessivas versões
cada vez mais sofisticadas do sistema. Desse modo, à medida que
se efetua cada entrega, uma nova fase de comunicação se inicia por
meio da revisão dos requisitos, sucedendo para uma nova sessão de
planejamento, modelagem etc.
Observe na Figura 2, a seguir, que no modelo em espiral as
fases acontecem em ciclos repetitivos. A linha em espiral simboliza
o processo de desenvolvimento passando pelas cinco etapas, de
modo repetitivo, e, ao fim de cada ciclo de cinco etapas, uma versão
aprimorada do software é entregue ao usuário.
Figura 2 – Modelo em espiral
Entrega
Construção
Comunicação
Modelagem
Planejamento
Esse modelo, em espiral, é adequado para o desenvolvimento

de software em larga escala e para ambientes com mais incerteza
em relação aos requisitos, uma vez que permite a revisão desses
sempre que uma nova entrega é efetuada. Além disso, é adequado
para software de desenvolvimento contínuo, no qual novas versões

podem ser lançadas a cada entrega.
Segundo Wazlawick (2013), o modelo em espiral é útil
tambémpara projetos com fases bem definidas e com requisitos
bem conhecidos e estáveis, além de ser recomendado para equipes
inexperientes, pois fornece um modelo a ser seguido, o que evita
esforços inúteis.
• Modelo em V
Esse modelo é uma variação dos modelos em cascata e espiral,
e “descreve a relação entre ações de garantia da qualidade e ações
associadas a comunicação, modelagem e atividades de construção
iniciais” (PRESSMAN; MAXIM, 2016, p. 42).
Em outras palavras, esse modelo divide o processo de
desenvolvimento em duas macroetapas mutuamente relacionadas:
uma de projeto e codificação, e outra de testes, visando à garantia da
qualidade do software.
Observe a seguir, na Figura 3, que na primeira macroetapa, à
esquerda, é realizada primeiramente a modelagem de requisitos do
sistema; depois efetua-se o projeto de arquitetura do sistema como
um todo e, ainda, dos seus componentes, partindo para o fim da
etapa, em que se gera o código do programa conforme a arquitetura
planejada.
Na segunda macroetapa, representada na Figura 3, à direita,
realizam-se os testes para validar as atividades realizadas na
macroetapa anterior. Dessa forma, há primeiramente os testes
dos códigos desenvolvidos; em seguida, acontecem os testes de
integração da arquitetura do sistema e de seus componentes,
partindo para o teste do sistema como um todo e, finalmente, para o
teste de aceitação por parte do cliente, tendo como base os requisitos
definidos para o programa.
Figura 3 – Modelo em V
Modelagem de Verifica Teste de aceitação

requisitos
Projeto de Verifica
Teste de sistema
arquitetura
Projeto de Verifica
Teste de integração
componente
Verifica
Geração de código Teste de unidade
Implantação
O modelo em V é indicado quando a realização de múltiplos

testes seja necessária, pois possibilita melhor detecção de erros em
cada etapa de realização.
• Modelo cíclico
Esse modelo tem formato cíclico, como o de espiral, porém
enfatiza a rápida execução das etapas de planejamento e modelagem,
adicionando uma etapa de construção de protótipos.
Observe na Figura 4, a seguir, que, assim como os demais
modelos, o de prototipação inicia-se com a etapa de comunicação,
a qual é uma das mais importantes. Nessa fase, uma reunião é feita
com as partes interessadas no projeto (clientes, desenvolvedores,
dentre outras) para definir os objetivos e os requisitos necessários
para o desenvolvimento do software. Em seguida, as etapas de
planejamento e modelagem são executadas no formato de um
projeto rápido, em que se constrói um protótipo do software. Depois
de entregue o software e recebido o feedback, o protótipo é discutido
em uma nova etapa de comunicação, na qual os requisitos do projeto

são refinados, e assim sucessivamente.
Figura 4 – Modelo cíclico
Planejamento rápido
Comunicação
Modelagem rápida
Entrega
(feedback)
Construção de
protótipos
De acordo com Sommerville (2011, p. 30), o desenvolvimento

de protótipos proporciona vantagens tanto aos clientes quanto aos
desenvolvedores. Na definição de requisitos, um protótipo “pode
ajudar na elicitação e validação de requisitos de sistema”, ao passo
que, no projeto de sistema, um protótipo “pode ser usado para
estudar soluções específicas do software e para apoiar o projeto de
interface do usuário”.
• Modelo RUP
O modelo RUP (Rational Unified Process), também conhecido
como Processo Unificado (PU), “reúne elementos de todos os
modelos de processo genéricos, ilustra boas práticas de especificação
e no projeto e apoia a prototipação e a entrega incremental”
(SOMMERVILLE, 2011, p. 34).
O RUP foi desenvolvido como “uma tentativa de aproveitar
os melhores recursos e características dos modelos tradicionais
de processo de software, mas caracterizando-os de modo a

implementar muitos dos melhores princípios do desenvolvimento
ágil de software” (PRESSMAN; MAXIM, 2016, p. 56).
A organização do RUP acontece em quatro fases, as quais –
opostamente aos modelos anteriormente descritos, orientados a
aspectos técnicos – são relacionadas a aspectos de negócio do cliente.
Na fase de concepção, realizam-se a comunicação e o
planejamento com o cliente, tendo como objetivo estabelecer um
estudo de caso para o negócio a ser desenvolvido. Nessa etapa,
identificam-se as pessoas e os sistemas que irão interagir com o
software que será desenvolvido e avalia-se a contribuição do sistema
para o negócio. Portanto, caso o sistema não contribua, o projeto já
é cancelado nessa fase.
Na segunda fase, a de elaboração, realiza-se a modelagem de
uma arquitetura do sistema. Nessa etapa, busca-se a compreensão
dos problemas do negócio, desenvolve-se o plano do projeto e
identificam-se os riscos e as oportunidades. Dentre os modelos
que podem ser desenvolvidos nessa fase encontram-se: o de caso
de uso, o de análise, o de projeto, o de implementação e o de
disponibilização (PRESSMAN; MAXIM, 2016).
Na fase de construção, efetuam-se a construção ou codificação
do sistema e os testes de unidades para cada componente desse
sistema. Implementam-se, nessa etapa, todos os recursos e
funcionalidades, e integram-se todos os componentes e partes
do sistema codificado. Ao fim dessa fase, um sistema deverá estar
concluído e ser funcional.
Por último, na fase de transição, efetua-se a entrega do sistema ao
cliente e coloca-se esse sistema para funcionar em um ambiente real.
Nessa etapa é essencial realizar o monitoramento contínuo do sistema,
tendo em vista que pode haver a necessidade de aperfeiçoamento
contínuo, realizando-se o suporte técnico necessário.
Na Figura 5, observe que, no processo unificado, as quatro fases

são sequenciais, mas as fases de elaboração e construção podem ser
realizadas de maneira concomitante, ou seja, ao mesmo tempo em
que se elabora o sistema, também se faz a construção desse.
Figura 5 – Modelo RUP
Elaboração
Concepção Planejamento
Modelagem
Comunicação
Construção
Entrega
Construção
Transição
Fonte: Elaborado pelo autor com base em Pressman e Maxim, 2016.
Esse modelo é recomendado para projetos em que a estabilidade

dos processos de desenvolvimento seja importante, já que o modelo
sendo estruturado, ao ser aplicado, tende a reduzir os riscos de
desenvolvimento de software.
Embora esses modelos tradicionais de desenvolvimento sejam
amplamente utilizados, vale ressaltar que, na sociedade atual, os
problemas acontecem de modo rápido, o que demanda soluções de
desenvolvimento ainda mais velozes. Dessa forma, os modelos ágeis
de desenvolvimento, alguns apresentados a seguir, têm ganhado
cada vez mais espaço entre os desenvolvedores.
Vídeo 2.3 Modelos ágeis de

desenvolvimento
Vamos estudar agora os modelos ágeis de
desenvolvimento de software, bastante necessários
em um mundo de intensas mudanças.
Quando os prazos para o desenvolvimento de sistemas são
cada vez menores, os requisitos mudam a todo tempo e os riscos,
consequentemente, aumentam. Diante disso, faz-se necessário o uso
de metodologias mais ágeis e informais, abordadas a seguir.
Os modelos ágeis têm origem em princípios estabelecidos pelo
Manifesto para o Desenvolvimento Ágil de Software, desenvolvido
por Kent Beck – criador do modelo XP (Extreme Programming) – e
mais 16 desenvolvedores.
De acordo com esse manifesto, no processo de desenvolvimento
de software é importante valorizar os seguintes aspectos: as
interações entre os indivíduos acima de processos e sistemas;
o software operacional acima da documentação completa; a
colaboração com os clientes acima de negociação contratual; e as
respostas às mudanças acima de seguir um plano.
Conforme afirma Sommerville (2011, p. 39), os modelos
ágeis “são modelos de desenvolvimento incremental em que os
incrementos são pequenos e, normalmente, as novas versões do
sistema são criadas e disponibilizadas aos clientes a cada duas ou três
semanas”. Dessa forma, são modelos de desenvolvimento de caráter
cíclico, no qual as etapas de comunicação, planejamento, entre
outras, se repetem em ciclos curtos e com a intensa participação dos
clientes no processo de desenvolvimento.
Assim, justamente por se tratar de ciclos curtos de
desenvolvimento, não é prioritário haver uma documentação
completa ou mesmo um plano complexo para se seguir. Além
disso, os contratos normalmente são por tempo de desenvolvimento,
e não pela entrega de um software completo ou pelo cumprimento

de requisitos.
Os principais modelos ágeis abordados neste Capítulo são o XP
(Extreme Programming), o scrum e o AUP (Agile Unified Process).
• Modelo XP
É um modelo ágil que considera o desenvolvimento de software
sob uma perspectiva diferente dos demais modelos. Para essa
metodologia, a definição de requisitos é feita considerando cenários
ou histórias de clientes; os programadores trabalham sempre em pares
e o código é escrito em definitivo apenas após a realização de testes.
O projeto na XP segue o princípio KISS (Keep It Simple
Stupid); sendo assim, é melhor um projeto simples com múltiplos
incrementos posteriores do que projetos mais complexos logo de
início. Desse modo, quando concluído, cada projeto é integrado ao
sistema e todos os testes, após essa integração, devem apresentar
sucesso.
• Modelo scrum
Esse modelo tem caráter cíclico, cujo nome diz respeito a uma
jogada no esporte rugby, na qual os atletas se encontram corpo a
corpo. Nesse modelo, as atividades de desenvolvimento ocorrem em
um ciclo denominado sprint.
O ciclo de trabalho no scrum consiste na realização de tarefas
de desenvolvimento, definidas em uma lista de prioridades de
requisitos, chamada de backlog. Dessa forma, é realizada uma reunião
inicial, denominada sprint planning meeting, em que são feitas as
definições de planejamento das atividades que serão desenvolvidas.
Em seguida, iniciam-se os ciclos de desenvolvimento, denominados
sprints, nos quais cada desenvolvedor desempenha a tarefa que lhe
foi designada.
No modelo scrum, a cada ciclo de 24 horas, são realizadas

reuniões de 15 minutos, nas quais a equipe de desenvolvimento,
sob a liderança do scrum master, responde às seguintes questões
(PRESSMAN; MAXIM, 2016): o que você realizou desde a última
sprint? Você está tendo alguma dificuldade? O que você vai fazer
antes da próxima reunião?
Após a realização das sprints, a equipe apresenta as
funcionalidades do software implantadas e, então, um novo ciclo de
desenvolvimento se inicia.
• Modelo AUP
Trata-se de uma variante do Processo Unificado voltada para
o desenvolvimento ágil. Esse processo adota as atividades clássicas
do RUP – concepção, elaboração, construção e transição –, porém
com ciclos repetitivos para tornar o modelo mais ágil. Cada iteração
adota as seguintes atividades:
1. Modelagem: elaboração de modelos, preferencialmente com
o uso da UML (Unified Modeling Language).
2. Implementação: transformação dos modelos em código.
3. Testes: realização de testes para a descoberta de erros e
oportunidades de melhoria no código.
4. Entrega: entrega de um incremento do código e feedback dos
usuários.
5. Configuração e gerenciamento do projeto: gerenciamento de
configurações, alterações, riscos e controle.
6. Gerenciamento do ambiente: gerenciamento de processos,
padrões, ferramentas e tecnologias de suporte.
Embora sejam diferentes, todos os métodos ágeis apresentados
são importantes. Cabe à equipe de desenvolvimento, conforme as
necessidades de cada projeto e as preferências pessoais, escolher o
mais adequado para utilizar em cada caso.
Neste capítulo, estudamos os principais modelos utilizados para
o desenvolvimento de um software.
Primeiramente, conhecemos a estrutura básica do
desenvolvimento de software, abordando as etapas de comunicação,
planejamento, modelagem, construção e entrega.
Em seguida, identificamos os principais modelos tradicionais
– em cascata, em espiral, em V, cíclico e RUP – e, com relação
aos modelos ágeis, estudamos os princípios do Manifesto Ágil de
Desenvolvimento de Software, além dos modelos XP, scrum e AUP.
Estudar os modelos de desenvolvimento de software é muito
importante para que possamos escolher o mais adequado para
determinado projeto e fazer o máximo aproveitamento dos recursos
disponíveis.
Vale ressaltar que não há modelo mais correto ou melhor. A
escolha do modelo mais adequado dependerá do tipo de sistema
que deveremos construir, do perfil da nossa equipe de projeto e dos
requisitos do nosso cliente.

• BECK, K. Programação extrema explicada: acolha as
mudanças. Porto Alegre: Bookman, 2004.
Neste livro, o criador do Extreme Programming apresenta
esse modelo com uma linguagem simples e clara. A obra é
recomendada para quem deseja um estudo mais aprofundado
do modelo XP, estudado neste capítulo.
• SCOTT, K. O processo unificado explicado. Porto Alegre:

Editora Bookman, 2002.
Neste livro, explica-se o RUP (Rational Unified Process), o

qual, conforme estudamos neste capítulo, é um dos modelos
tradicionais mais usados para o desenvolvimento de sistemas.
• RUBIN, K. S. Scrum essencial: um guia prático para o mais

popular processo ágil. Rio de Janeiro: Alta Books, 2017.
Nesse livro, explica-se de maneira didática o modelo ágil
scrum, abordado neste capítulo, com ilustrações e descrições
de fácil compreensão.
Atividades
1. No modelo ágil scrum são desempenhadas as funções de
scrum master, product owner e development team. Pesquise
e disserte sobre a importância de cada uma delas.
2. Uma variante do modelo XP é o Industrial XP, que

adota práticas diferenciadas para projetos em grandes
organizações. Pesquise e descreva as características desse
modelo alternativo
3. Neste capítulo, tratamos brevemente do Manifesto de

Desenvolvimento Ágil de Software. Uma variante desse
manifesto são os 12 princípios do software ágil. Pesquise e
descreva esses princípios.
Referências
profissional. 8. ed. Porto Alegre: AMGH, 2016.
SOMMERVILLE, I. Engenharia de software. 9. ed. São Paulo: Pearson

Prentice Hall, 2011.
WAZLAWICK, R. S. Engenharia de software: conceitos e práticas. Rio de

Janeiro: Elsevier, 2013.
3
Engenharia de requisitos
Neste capítulo, vamos tratar da definição de requisitos, uma

das mais importantes atividades da engenharia de software.
Dessa forma, é importante, primeiramente, compreendermos que
dependendo da situação, o mesmo software pode ser tanto um
serviço quanto um produto.
Sendo um serviço, é importante definirmos os requisitos
considerando que todo software é criado de pessoas para pessoas
e que cada usuário tem necessidades específicas. Um software é
intangível, ou seja, não pode ser tocado, o que significa que o valor
desse serviço é baseado na percepção de quem vai utilizá-lo. Diante
disso, é essencial que o engenheiro ouça o que o cliente tem a dizer
para que o software seja desenvolvido de modo que atenda às suas
necessidades.
Já como produto a ser comercializado, devemos considerar que
um software requer o uso de recursos para o seu desenvolvimento,
os quais muitas vezes são escassos ou caros, como pessoas, materiais
e tecnologias. Sendo assim, definir previamente requisitos de
desenvolvimento é mais do que uma atividade obrigatória de um
engenheiro de software, é uma responsabilidade.
Assim, neste capítulo, vamos tratar dos requisitos sob os pontos
de vista do usuário e do sistema. Primeiramente, vamos apresentar
métodos úteis para a coleta de requisitos, depois estudaremos quais
requisitos podem ser coletados por meio desses métodos e, por fim,
observaremos as formas de organizar e apresentar os requisitos para
o cliente e para a equipe de desenvolvimento.
Vídeo
3.1 Métodos para a coleta de
requisitos
Imagine que você vai comprar um presente
para uma pessoa que não é muito próxima de
você – no amigo secreto da empresa onde você
trabalha, por exemplo. Para não errar na escolha e evitar que a pessoa
fique chateada, você, provavelmente, realizará uma entrevista com
os amigos próximos dela, observará os seus hábitos, o modo como
se veste, objetos que costuma usar, e, inclusive, poderá perguntar a
ela mesma do que gosta, quais são seus hobbies etc. Com isso, você
levantará os requisitos necessários para a escolha do presente. Esse
processo é bastante semelhante ao da engenharia de requisitos.
Todo software é desenvolvido tendo em vista um usuário ou

grupo de usuários. Assim, para que o engenheiro obtenha
sucesso no desenvolvimento de um serviço ou produto,
inicialmente, é necessário definir quais requisitos o software
deverá apresentar.
Segundo Pfleeger (2004, p. 111), requisito é “uma característica do

sistema ou a descrição de algo que o sistema é capaz de realizar, para
atingir os seus objetivos”, ou seja, trata do que um sistema necessita
possuir ou como deverá se comportar para que esteja conforme às
necessidades do usuário. Desse modo, a engenharia de requisitos
é “o conjunto de técnicas empregadas para levantar, detalhar,
documentar e validar os requisitos de um produto” (PAULA FILHO,
2009, p. 165), ou seja, consiste em efetuar a gestão dos requisitos
de um software durante todo o ciclo de desenvolvimento, desde a
concepção até a entrega.
Engenharia de requisitos 41
Ainda segundo Paula Filho (2009), os requisitos de um software

devem atender a determinadas características, conforme apresenta
a Figura 1.
Figura 1 – Características para o levantamento de requisitos de um

produto ou software
Correção
Rastreabilidade Precisão
Características
Modificabilidade
para o
Completeza
levantamento
de requisitos
Verificabilidade Consistência
Priorização
Fonte: Elaborada pelo autor com base em Paula Filho, 2009.
A característica correção, apresentada na figura, prevê que o

requisito do software seja corretamente descrito e que ele seja realmente
o do software a ser construído, já a precisão trata da descrição do
requisito, não permitindo interpretações ambíguas em relação ao que
deve ser feito. A completeza diz respeito ao requisito abranger, de
modo completo, aspectos relativos a funcionalidade, desempenho,
interfaces, restrições e aspectos de qualidade, sem cláusulas de
pendências; já a consistência possibilita que o requisito não apresente
conflitos com outros requisitos, de modo lógico ou temporal. A
priorização caracteriza-se pelo requisito poder ser classificado, em
conjunto com outros requisitos, conforme sua importância (essencial,

desejável ou opcional, por exemplo); a verificabilidade trata do
requisito ser verificável quanto à sua conformidade com o produto
final desenvolvido. A modificabilidade permite que o requisito
seja modificável quando necessário. Por fim, a rastreabilidade diz
respeito ao requisito poder ser rastreável quanto aos seus antecedentes
e consequências, podendo ser relacionada à origem do requisito (para
trás) ou aos resultados obtidos (para frente).
Para garantir que esses aspectos sejam obtidos no levantamento
dos requisitos, é necessário considerar nesse processo as
características do usuário e as especificações de sistema. Assim, o
processo de engenharia de requisitos, segundo Pressman (2011), é
composto de algumas fases, conforme podemos observar na figura
a seguir.
Figura 2 – Fases da engenharia de requisitos
Concepção
Especificação
Levantamento
Validação
Elaboração
Gestão
Negociação
Fonte: Elaborada pelo autor com base em Pressman, 2011.

O processo inicial da definição dos requisitos, conforme

podemos observar na Figura 2, é a concepção, na qual são
previstos os problemas que serão solucionados pelo software
e são identificadas as partes interessadas1. Em seguida, há o
levantamento das informações necessárias para a elaboração dos
requisitos, que acontece por meio de técnicas, como entrevistas e
etnografia, aplicadas junto às partes interessadas. Já na elaboração,
as informações obtidas são analisadas, o que permite descrever
como os usuários interagirão com o sistema e, assim, construir
um modelo de requisitos para ser apresentado. Posteriormente,
há a fase de negociação, na qual são discutidos possíveis conflitos
relacionados ao que as partes interessadas desejam e ao que pode ser
desenvolvido até se chegar a um consenso. Na sequência, elabora‑se
o modelo de especificação de requisitos de software – ou SRS
(Software Requirements Specification) –, documento contendo a
descrição detalhada dos requisitos do sistema a ser desenvolvido.
Depois, ocorre a validação do que foi descrito na especificação de
requisitos de software junto ao usuário, detectando e corrigindo
prováveis inconsistências, omissões e erros. Por fim, na etapa de
gestão, uma vez validada, a especificação de requisitos de software é
acompanhada durante o processo de desenvolvimento de modo que,
caso necessário, correções e mudanças possam ser feitas.
Além disso, o levantamento dos requisitos deve considerar,
além do usuário, todas as partes interessadas nesse sistema
(stakeholders), visto que, segundo Sommerville (2011), no
processo de definição dos requisitos podem surgir dificuldades,
como o fato de as partes interessadas nem sempre sabem o
1 Uma parte interessada, denominada stakeholder, é “quem tem alguma influência

direta ou indireta sobre os requisitos do sistema” (SOMMERVILLE, 2011, p. 70), ou seja,
todo indivíduo envolvido no processo de desenvolvimento de um sistema.
que desejam de um sistema; elas podem utilizar linguagem

própria ou jargões técnicos para explicar os requisitos, termos
nem sempre compreensíveis para os engenheiros de software.
Podem haver diferenças em termos de prioridades ou de opiniões
com relação a requisitos necessários ou não para determinado
sistema. A definição de requisitos pode ser influenciada por
fatores políticos (por exemplo, influência na organização) e os
requisitos definidos pelas partes interessadas podem mudar com
o tempo, assim como as prioridades para cada requisito, o que
pode dificultar o processo de desenvolvimento do sistema.
Desse modo, durante o levantamento de requisitos, para verificar
quais são as necessidades dos usuários em relação ao software que
será desenvolvido, realizam-se técnicas como entrevistas, análise de
cenários, etnografia e coleta colaborativa, descritas a seguir. Nessa
etapa, também é necessário realizar um levantamento sobre pessoas,
processos e recursos envolvidos no desenvolvimento e na utilização
do software. Pode-se também realizar pesquisa em base de dados,
artigos, documentos técnicos de hardware e software, dentre outras
fontes, a fim de se obter informações adicionais que possam ser
utilizadas como base para a definição dos requisitos.
• Entrevistas
A entrevista é uma das técnicas primárias para a descoberta
de requisitos. Em um ambiente formal, ou informal, realizam‑se
perguntas para saber a opinião das partes interessadas sobre quais
seriam os requisitos do sistema para o usuário. Recomenda‑se a
realização das entrevistas em equipe, isto é, com vários profissionais
de engenharia de software trabalhando juntos e anotando as
respostas das perguntas. As entrevistas podem ser de dois tipos,
conforme figura a seguir.
Figura 3 – Tipos de entrevista durante a definição de requisitos
Entrevistas (em equipe)
abertas fechadas
as perguntas são previamente

não há um roteiro definido de
definidas e os stakeholders se
perguntas – inicia-se com uma
atêm apenas a responder às
pergunta inicial e a entrevista
perguntas realizadas.
evolui conforme as respostas dos
stakeholders.
Fonte: elaborada pelo autor com base em Sommerville, 2011.
As entrevistas são adequadas para uma compreensão

abrangente a respeito dos hábitos das partes interessadas, das
dificuldades enfrentadas nos sistemas que atualmente usam e das
expectativas relacionadas ao novo sistema que será desenvolvido
(SOMMERVILLE, 2011). Outra vantagem das entrevistas é
o esclarecimento de jargões técnicos, processos, atividades e
conhecimentos nem sempre claros para os engenheiros de software.
Além disso, elas podem servir para esses profissionais obterem
conhecimento, mesmo que pouco, da cultura da organização e de
suas relações de poder – elementos que também podem influenciar
no desenvolvimento do software.
• Análise de cenários
Outro método para a coleta de requisitos consiste na análise de
cenários. Segundo Sommerville (2011, p. 73), “as pessoas geralmente
acham mais fácil se relacionar com exemplos da vida real do que com
descrições abstratas. Elas podem compreender e criticar um cenário
de como elas podem interagir com um sistema de software”. Assim,

essa técnica, conforme o nome sugere, está relacionada à montagem
e simulação de cenários hipotéticos para a utilização do software,
como a criação de histórias no método Extreme Programming.
Dentre as situações que podem ser simuladas com a análise
de cenários, encontram-se casos de uso do sistema por parte do
usuário, possíveis usos inadequados, possíveis erros ou exceções
apresentadas pelo sistema, bem como atividades simultâneas que
podem acontecer durante a execução do sistema.
Sommerville (2011) sugere que a análise de cenários seja
realizada por escrito, contendo cinco elementos básicos:
Figura 4 – Elementos básicos para a análise de cenários
Suposição Situação
O que pode
inicial normal de
dar errado
utilização
01 02 03
04 05
Outras Estado do
atividades sistema na
conclusão
Fonte: elaborada pelo autor com base em Sommerville, 2011.
Na suposição inicial, expõe-se a situação na qual o software

será utilizado – o cenário-base; na situação normal de utilização,
descreve-se o processo de utilização do software, passo a passo,
considerando o papel de cada usuário nesse processo. Na etapa que
considera o que pode dar errado, descreve-se, a partir da situação
normal de utilização, os possíveis erros que podem acontecer durante
a utilização do software. Em outras atividades, verificam‑se outras
atividades ou restrições com relação ao uso do software, as quais
não se encontram na situação normal de utilização. Por fim, em
estado do sistema na conclusão, abordam-se os processos relativos

à finalização do uso do sistema e como a sua utilização é concluída.
• Etnografia
Essa possível técnica para o levantamento de requisitos
considera que o uso do software é realizado em um contexto social
e organizacional, ou seja, é considerado parte de uma cultura. A
etnografia “é uma técnica de observação que pode ser usada para
compreender os processos operacionais e ajudar a extrair os requisitos
de apoio para estes processos” (SOMMERVILLE, 2011, p. 75).
A etnografia consiste na observação do uso de um artefato em
seu ambiente pelos usuários. Um observador se introduz nesse
ambiente e realiza anotações a respeito do uso desse software –
da forma como o sistema é utilizado, o porquê de determinadas
funcionalidades serem usadas ou não e as interações dos usuários
com a interface do sistema.
Assim, essa técnica permite a identificação de requisitos com
base na realidade da utilização do sistema no ambiente de trabalho, e
não apenas com base em suposições ou estudos. Além disso, permite
a identificação de requisitos com base na observação da cooperação
entre as pessoas e na troca de conhecimentos, experiências e
opiniões entre elas.
• Coleta colaborativa
A coleta colaborativa de requisitos é uma técnica em que se
realizam reuniões com a participação das partes interessadas e dos
engenheiros de software. Essas reuniões são realizadas segundo
regras estabelecidas para a participação, e “é sugerida uma agenda
suficientemente formal para cobrir todos os pontos importantes,
porém, suficientemente informal para encorajar o fluxo livre de
ideias” (PRESSMAN, 2011, p. 133).
Nessas reuniões, identificam-se os problemas, propõem-se
as soluções e definem-se diferentes abordagens para definir um
conjunto preliminar de requisitos. Um facilitador é escolhido

para conduzir a reunião e garantir que as regras definidas sejam
cumpridas.
Por fim, independentemente da técnica utilizada (entrevistas,
análise de cenários, etnografia e coleta colaborativa), o importante é
que, por meio dessa aplicação, seja possível a coleta dos requisitos
funcionais e não funcionais necessários para o desenvolvimento do
software. A seguir, definimos alguns desses requisitos.
Vídeo
3.2 Classificação de requisitos
Agora que você já sabe o que são requisitos,
é importante realizar a distinção dos tipos de
requisitos. Pfleeger (2004) sugere a priorização
de requisitos em três categorias básicas, conforme
figura a seguir. Essa priorização é importante para
que a equipe de desenvolvimento seja melhor direcionada em relação
aos seus esforços e recursos para as tarefas de desenvolvimento.
Figura 5 – Classificação de requisitos de acordo com Pfleeger (2004)
Requisitos
possíveis, mas
totalmente altamente
que podem ser
satisfeitos desejáveis eliminados
Fonte: Elaborada pelo autor com base em Pfleeger, 2004.
Dentre os requisitos que devem ser totalmente satisfeitos,

pode‑se citar as funcionalidades básicas de um sistema. Por
exemplo, um sistema comercial deve possibilitar a emissão de
notas fiscais, ao passo que um sistema de departamento de pessoal
(DP) deve possibilitar a exibição da ficha cadastral de determinado
colaborador.
Já os requisitos que são desejáveis, mas não necessários, dizem

respeito a funcionalidades acessórias que seriam muito úteis para o
usuário desempenhar suas tarefas, mas que podem ser dispensadas
em uma versão básica do sistema. Por exemplo, o sistema comercial
poderia emitir um relatório de clientes inadimplentes, e o sistema
de gerenciamento de pessoal armazenar, além da ficha cadastral, o
currículo do colaborador.
Por fim, os requisitos que são possíveis, mas poderiam ser
eliminados, dizem respeito a adições ao sistema que podem
ser consideradas em determinado momento, porém podem
ser dispensadas se necessário. Um exemplo desse requisito é a
formatação dos sistemas empresariais anteriormente mencionados,
originalmente desenvolvidos para computadores pessoais, para o
formato de aplicativos de celular.
Já Pressman (2011) estabelece outra classificação para requisitos,
sob o viés da gestão da qualidade. Para o autor, os requisitos podem
ser classificados em três modalidades, conforme apresenta a figura
a seguir.
Figura 6 – Classificação de requisitos de acordo com Pressman

(2011)
Requisitos
normais esperados fascinantes
Os requisitos normais são estabelecidos com base em objetivos

e metas definidos junto às partes interessadas, utilizando técnicas
de levantamento de requisitos. Já os requisitos esperados, que nem
sempre são declarados pelas partes interessadas, podem ser tão
fundamentais quanto os requisitos normais, e sua ausência causará

insatisfações. Por último, se os requisitos fascinantes estiverem
presentes, ocasionarão, além das expectativas das partes interessadas,
extrema satisfação, constituindo-se em uma surpresa. Portanto, a
definição do autor supracitado considera os tipos de requisitos sob a
perspectiva das partes interessadas no projeto.
Outra classificação possível para requisitos, segundo
Sommerville (2011), diz respeito à sua funcionalidade. Dessa forma,
é possível a classificação dos requisitos segundo duas modalidades,
conforme figura a seguir.
Figura 7 – Requisitos com base na funcionalidade
Requisitos
funcionais não funcionais
funcionalidades básicas de
determinado sistema, descrevendo restrições do sistema, ou seja, não
o que este deverá executar em cada descrevem o que o sistema deverá
situação. O cumprimento desses executar, mas sim como ele se
requisitos garante que o sistema comportará durante a execução.
funcione conforme o esperado.
Fonte: Elaborada pelo autor com base em Sommerville, 2011.
Como exemplos de requisitos funcionais, pode-se citar, em um

jogo, as possíveis ações que o jogador poderá desempenhar, já em
uma página de internet, é possível mencionar o conteúdo que deverá
ser apresentado, o layout da página, a disposição dos botões e links,
dentre outros. No caso de exemplos de requisitos não funcionais,
pode-se citar, tanto no jogo, como na página de internet, os requisitos
mínimos de hardware para o funcionamento do sistema.
Tanto os requisitos funcionais quanto os não funcionais podem
ser, também, classificados conforme os componentes do sistema e
seus processos de desenvolvimento. Pfleeger (2004) realiza, dessa
forma, a seguinte classificação:
• Requisitos de ambiente físico: dizem respeito ao local físico

de instalação e funcionamento do sistema ou hardware,
bem como possíveis restrições de funcionamento, como
temperatura, ruídos, vibrações, interferência magnética,
dentre outras.
• Requisitos de interface: tratam da interação de um sistema
com outros sistemas, abrangendo aspectos como a formatação
de dados, entradas e saídas, dentre outros.
• Requisitos de usuários e fatores humanos: abrangem a
forma com a qual o usuário interage com o sistema e sua
interface, e consideram diferentes níveis de competências
– conhecimentos, habilidades e atitudes, bem como a
necessidade de treinamento para o seu melhoramento. Ainda,
consideram a intuitividade, as facilidades e as dificuldades de
compreensão do usuário, e analisam o perfil do usuário do
sistema e quantos o utilizarão.
• Requisitos de funcionalidade: dizem respeito às funções
do sistema, seus modos de operação, necessidades de
aprimoramento e limitações.
• Requisitos de documentação: tratam da necessidade de
documentação para o sistema, bem como do formato – se é
on-line, em papel (físico) ou ambos. Também dizem respeito
aos públicos aos quais se destina cada documentação e quais
usuários devem ter acesso à documentação.
• Requisitos de dados: tratam da formatação dos dados, da
frequência de envio e recebimento, da precisão, do fluxo e da
forma de armazenagem e manutenção desses dados no sistema.
• Requisitos de recursos: dizem respeito a materiais, pessoas,
tecnologias, dentre outros, necessários para o adequado
funcionamento do sistema. Também tratam de questões
relacionadas às tecnologias da informação necessárias, como
hardware, telecomunicações, infraestrutura (edificações,

estrutura física, dentre outros) e custos de desenvolvimento.
• Requisitos de segurança: dizem respeito às políticas de
acesso ao sistema, bem como à gestão de dados e informações,
principalmente, dos usuários e demais stakeholders. Também,
dizem respeito às políticas de backup (sendo que se sugere
que as cópias sejam armazenadas em local distinto ao do
sistema) e prevenções contra desastres naturais ou acidentes.
• Requisitos de garantia da qualidade: abrangem, por sua vez,
questões básicas de qualidade do sistema, como confiabilidade,
disponibilidade, manutenibilidade, capacidade, prevenção a
falhas e defeitos, correção de erros, indicadores de desempenho,
dentre outros.
Desse modo, é possível compreender que se pode classificar
requisitos pela funcionalidade, conforme os componentes do
sistema ou pela ótica da gestão da qualidade. O importante é que o
software, ao cumprir esses requisitos, esteja adequado às necessidades
do usuário e das demais partes interessadas pelo sistema.
Vídeo 3.3 Especificação e

apresentação de requisitos
Agora que estudamos os requisitos e suas
características, chegou a vez de definirmos como
apresentá-los às partes interessadas, bem como a
melhor forma de documentá-los.
Conforme afirma Sommerville (2011), especificar requisitos
para o desenvolvimento de um sistema consiste em documentá-los.
Uma forma de se documentar os requisitos, tanto do usuário quanto
do sistema, é por meio da especificação de requisitos de software
(SRS). Esse documento detalha todos os aspectos do software que
deverão ser considerados no processo de construção. Pressman
(2011) sugere o seguinte conteúdo para esse documento:
Figura 8 – Conteúdos sugeridos para se documentar os requisitos
Introdução Descrição geral Características Requisitos de

do sistema interfaces externas
Requisitos não
Validação Gestão Outros requisitos
funcionais
Na introdução, apresentam-se o documento, suas convenções,

seu público-alvo, sugestões de leitura, o escopo do projeto de
software e as referências utilizadas. Já na descrição geral, detalha-
se o software a ser desenvolvido, contemplando características,
restrições de projeto, ambiente operacional, dentre outros. Em
características do sistema, detalham-se os requisitos funcionais do
sistema e suas características essenciais. Em seguida, em requisitos
de interfaces externas, detalham-se os requisitos referentes às
interfaces de usuário, software, hardware e comunicação. Depois, em
requisitos não funcionais, apresentam-se requisitos considerados
não funcionais, como de desempenho, segurança, proteção e
qualidade. Por fim, em outros requisitos, descrevem-se requisitos
não mencionados nos itens anteriores, porém, importantes para o
projeto.
Essa especificação de requisitos pode ser feita de diferentes
formas. Sommerville (2011) descreve algumas:
• Sentenças em linguagem natural: os requisitos são escritos na
linguagem natural – sugere-se uma frase para expressar cada
requisito.
• Linguagem natural estruturada: descrevem-se os requisitos
em linguagem natural, porém em um formulário estruturado
(template).
• Linguagem de descrição de projeto: os requisitos são escritos

com o uso de uma linguagem similar à de programação, mas
com características mais abstratas.
• Notações gráficas: utilizam-se notações gráficas para a
descrição dos requisitos, como a linguagem UML.
• Especificações matemáticas: utilizam-se notações matemáticas
para a expressão dos requisitos (conjuntos, por exemplo) – deve-
se observar que a maioria das pessoas pode não compreender
os requisitos escritos dessa maneira.
Sommerville (2011) ainda sugere aspectos a serem considerados
no momento de escrever requisitos. Primeiramente, ele propõe a
padronização do formato de escrita, por exemplo, com a escrita dos
requisitos em uma única frase e uma justificativa para cada requisito.
Além disso, é necessária uma linguagem consistente para a
distinção dos requisitos obrigatórios e desejáveis ou possíveis – por
exemplo, utilizando o termo deve para os requisitos obrigatórios
e pode para os requisitos desejáveis e possíveis. O autor sugere,
também, o uso de alguma forma para destacar os elementos
fundamentais do requisito – itálico, negrito ou o uso de cores.
Adicionalmente, é preciso considerar que nem todas as pessoas
conhecem os termos técnicos utilizados na engenharia de software.
Assim, deve-se evitar, na descrição dos requisitos, o uso de jargões,
siglas e acrônimos que possam causar interpretações equivocadas ou
não entendimentos.
Para melhor compreensão por parte do usuário e do
desenvolvedor, a escrita pode ser associada ao desenvolvimento
de protótipos para se analisar e visualizar melhor cada requisito.
Paula Filho (2009, p. 170) sugere a utilização de um protótipo
evolucionário, “que é uma versão parcial do produto que satisfaz a
um subconjunto de requisitos do produto final”, ou de um protótipo
descartável, “construído com a única finalidade de demonstrar o que
foi entendido ou resolvido em relação a algum aspecto da análise ou

desenho do produto”. O autor cita os seguintes tipos de protótipos:
• Protótipo visual: adequado para expressar funções e interfaces
de usuário, bem como relatórios gráficos, permitindo a
visualização das interfaces e a navegação entre estas – ele pode
ser construído com ferramentas de desenho ou em ambiente
de programação rápida.
• Processador de textos: pode ser utilizado para prototipar
relatórios textuais – neste caso, a amostra do relatório que o
software deverá produzir.
• Planilhas eletrônicas: adequadas para a simulação de cálculos
ou algoritmos complexos.
• Programas de teste: para simular a execução de partes de um
sistema ou novas tecnologias.
Uma vez apresentados às partes interessadas, os requisitos
podem sofrer alterações ao longo do desenvolvimento do software.
Recomenda-se que as mudanças sejam gerenciadas e justificadas com
base em aspectos operacionais e financeiros (custos). Sommerville
(2011) recomenda alguns estágios para se promover mudanças em
requisitos:
Figura 9 – Estágios para as mudanças em requisitos
1
Análise de problema
e especificação de
mudanças
2
Análise de
Estágios
mudanças e custos
3
Implementação
de mudanças
Fonte: Elaborada pelo autor com base em Sommerville, 2011.
Em 1, analisa-se o problema ou proposta de mudança com o

intuito de verificar a sua validade e viabilidade. Em 2, analisam‑se
os efeitos e impactos da mudança, bem como a necessidade de
mudanças no documento de requisitos, em que se deve aprovar a
mudança antes de realizá-la. Por último, em 3, implementa-se a
mudança e efetuam-se as alterações no documento de requisitos.
Por fim, vale ressaltar que, durante o desenvolvimento do
software e no processo de apresentação dos requisitos, estes podem
ser negociados entre as partes. Sugere-se, com base em Pressman
(2011), que a negociação dos requisitos seja feita no sistema
“ganha‑ganha”. Ainda recomenda-se identificar os principais
interessados na negociação, definir as condições de ganho de
cada parte e negociar as condições, buscando-se garantir esses
ganhos tanto para as partes interessadas quanto para a equipe de
desenvolvimento de software.
A engenharia de requisitos é uma atividade que não deve
acontecer apenas na fase inicial de desenvolvimento de software,
mas deve permear todo o processo de desenvolvimento de modo
que, conforme o software é desenvolvido, os desenvolvedores
estejam constantemente atentos às necessidades do usuário.
Os requisitos das partes interessadas, dos usuários e do
sistema encontram-se em constante mudança, principalmente se
considerarmos o fato de que as organizações estão inseridas em
mercados cada vez mais dinâmicos.
Desse modo, cabe ao engenheiro de software perceber
essas mudanças e aplicar, sempre que possível, os métodos de
levantamento de requisitos estudados neste capítulo, com o intuito
de manter sempre atualizados os requisitos do sistema, facilitando,
assim, o trabalho da equipe de desenvolvimento.

• VAZQUEZ, C. E.; SIMÕES, G. S. Engenharia de requisitos:
software orientado ao negócio. Rio de Janeiro: Brasport, 2016.
Esse livro descreve de modo didático, os processos
de definição, coleta, análise e gestão de requisitos,
relacionando‑os a processos de negócio.
• FERNANDES, J. M.; MACHADO, R. J. Requisitos em projetos de

software e de sistemas de informação. São Paulo: Novatec, 2017.
Esse livro descreve os principais processos da engenharia de
requisitos, dando ênfase à modelagem de requisitos.
Atividades
1. Escolha um software que você utilize – pode ser um aplicativo
de celular, um jogo, o sistema da empresa onde você trabalha
ou outro de sua preferência. Defina, no mínimo, três
requisitos funcionais e três requisitos não funcionais para
esse sistema.
2. Baixe um aplicativo de celular qualquer pela internet e

peça a uma pessoa (amigo, familiar etc.) que o utilize. Faça
anotações e, se possível, uma gravação de vídeo de cada
atividade ou interação dessa pessoa com o aplicativo. Defina,
com base nessa utilização, três requisitos funcionais e três
requisitos não funcionais para esse aplicativo.
3. Escolha um jogo digital de sua preferência. Imagine que você

desenvolverá a continuação desse jogo e elabore um modelo
de especificação de requisitos de software para ele.
Referências
PAULA FILHO, W. P. Engenharia de software: fundamentos, métodos e
padrões. Rio de Janeiro: LTC, 2009.
PFLEEGER, S. L. Engenharia de software: teoria e prática. São Paulo:

Pearson, 2004.
PRESSMAN, R. S. Engenharia de software: uma abordagem profissional.

Porto Alegre: AMGH, 2011.
SOMMERVILLE, I. Engenharia de software. São Paulo: Pearson, 2011.

4
Modelagem de software com a UML
Neste capítulo, vamos estudar a UML (Unified Modeling

Language ou Linguagem de Modelagem Unificada), uma das mais
intuitivas linguagens gráficas utilizadas na modelagem de software.
Devido à sua fácil compreensão e adaptabilidade em retratar
elementos característicos de linguagens orientadas a objetos, como
classes, objetos e interfaces, a UML pode ser aplicada de modo que o
todo e as partes componentes de um sistema possam ser discutidos,
antes mesmo de qualquer esforço de programação, poupando,
assim, tempo de desenvolvimento e, consequentemente, recursos
humanos, materiais e financeiros.
Além disso, essa linguagem possui vários diagramas, que
possibilitam retratar diferentes perspectivas de um mesmo
sistema e cujos elementos e seus significados são definidos
internacionalmente.
Por meio do diagrama de casos de uso, por exemplo, é possível
esquematizar graficamente as diferentes maneiras possíveis de se
utilizar um software. Já por meio do diagrama de classes, de caráter
mais técnico, é possível modelar as classes e os objetos que farão
parte da estrutura do sistema, facilitando, posteriormente, o trabalho
de codificação dos desenvolvedores.
Desse modo, compreender a linguagem UML significa
colocar ideias no papel de modo facilitado, bem como fazer com
que o projeto seja compreendido mais facilmente por outros
engenheiros de software.
Vídeo 4.1 O que é a UML e por que

utilizá-la?
Antes de entendermos o que é a UML,
precisamos compreender a diferença entre
linguagem de modelagem e linguagem de
programação. A primeira, como o nome sugere, consiste em
notações:
representações
notações para a concepção de sistemas e objetiva obter um projeto
gráficas de software. Já a outra consiste em notações para a codificação e tem
por meio de
símbolos ou
como objetivo obter um software em funcionamento.
caracteres.
A UML é, portanto, uma linguagem de modelagem que tem
como objetivo auxiliar os engenheiros de software na definição
de características, requisitos, comportamentos, estruturas lógicas,
dinâmicas de processos e necessidades físicas do equipamento
para o qual o sistema será implantado (GUEDES, 2011, p. 19).
Desse modo, podemos entender que, além de tratar da estrutura
do desenvolvimento de software, a UML aborda aspectos relativos
à sequência de execução de um sistema, aspectos de hardware e,
inclusive, definição de requisitos.
Imagine que você é o engenheiro responsável pela construção de
uma casa. Você poderia simplesmente aterrar o terreno e construir
a fundação, as paredes, o telhado e as janelas, sem utilizar um
projeto específico. Porém, além de infringir normas que deveriam
ser respeitadas para a construção em determinados locais, esse
método seria muito difícil de ser aplicado em projetos de maior
complexidade, como na construção de um edifício comercial de 30
andares na região central de uma cidade.
Para o desenvolvimento de um software, esse processo é
bastante semelhante, principalmente se envolver a disposição de
recursos humanos, bem como materiais e financeiros de outras
pessoas. Desse modo, assim como recursos na construção do
edifício comercial, ao desenvolver um software, você necessitará
Modelagem de software com a UML 61
de um projeto detalhando todos os elementos necessários,

como dimensionamento, componentes e o modo de utilizá-los,
cronograma, escopo, dentre outros.
Assim como o projeto de um edifício deve ser esquematizado
em plantas, ou seja, em projeções dimensionais do que deverá
ser construído, o projeto de um software deve ser esquematizado
em formato de modelos. Um modelo “é a abstração de algo
com a finalidade de entendê-lo antes de construí-lo” (BLAHA;
RUMBAUGH, 2006, p. 17). Desse modo, na engenharia de software,
um modelo é a representação do sistema a ser construído, de modo
que ao programá-lo o desenvolvedor tenha referências que poderão
ser consultadas para verificar se o sistema atende aos requisitos
necessários para o pleno funcionamento e, consequentemente, à
satisfação do cliente.
Segundo Blaha e Rumbaugh (2006), os modelos de software
apresentam algumas finalidades, como:
• testar uma entidade física antes de construí-la: os modelos
possibilitam simular o funcionamento de um software,
verificando como irá se comportar em determinadas
situações e corrigindo erros antes de gastar tempo e recursos
em programação.
• comunicar as partes interessadas: os modelos permitem
estabelecer um canal de comunicação efetivo com os
clientes durante a definição de requisitos e o processo de
desenvolvimento do software.
• visualizar: os modelos, sendo representações do software,
facilitam um entendimento comum entre clientes e
desenvolvedores.
• reduzir a complexidade: os modelos promovem a
representação e a visualização holística (como um todo)
de sistemas que são complexos para um formato de fácil
compreensão.
Sendo um processo característico da Engenharia de software, a

modelagem tem uma série de atividades que devem ser executadas,
de modo que, ao final, se obtenha um software modelado e,
principalmente, viável de ser construído. Dessa forma, segundo
Guedes (2011), as atividades que compõem a modelagem são:
levantamento e análise de requisitos; prototipação; definição de
prazos e custos; projeto; e manutenção e documentação histórica.
Assim, primeiramente, em levantamento e análise de
requisitos, definem-se o que o software deverá realizar (requisitos
funcionais) e as diferentes formas como será executado (requisitos
não funcionais). Na fase de prototipação, elabora-se uma versão
primária do sistema que será desenvolvido, abrangendo como
será o fluxo de informações desse sistema, seus componentes
principais, dentre outros. Depois, em definição de prazos e custos,
determinam-se os recursos humanos e materiais que serão utilizados
no projeto, bem como o cronograma e a duração das atividades. Já
na etapa projeto, desenvolve-se a arquitetura do sistema (o projeto
detalhado) e o protótipo é transformado em um modelo que
descreve o modo que cada componente será aplicado no sistema e
quais resultados deverão ser obtidos. Uma vez o software projetado,
definem-se aspectos relativos à manutenção, ou seja, como será a
política de manutenção e como se pode reduzir a necessidade de
manutenções nele. Por fim, realiza-se a documentação histórica
de todo o projeto de software de modo que, caso haja mudança das
equipes de desenvolvimento, o projeto tenha continuidade.
A UML originou-se para “ser um padrão que resolva as
necessidades práticas da comunidade de desenvolvimento de
software” (PENDER, 2004, p. 7), ou seja, para ser uma linguagem
que, por meio da utilização de modelos, permita a engenheiros de
software, independentemente de origens, formações e preferências
por linguagens de programação, um meio comum de comunicação.
Segundo Pender (2004, p. 7-8), o OMG (Object Management Group)

desenvolveu a UML com os seguintes objetivos:
• Oferecer aos modeladores uma linguagem de modelagem
pronta para usar, expressiva e visual, para o desenvolvimento
e a troca de modelos significativos.
• Fornecer mecanismos de extensibilidade e especialização
para estender os principais conceitos.
• Admitir especificações independentes das linguagens de
programação e dos processos de desenvolvimento específicos.
• Oferecer uma base formal para entender a linguagem de
modelagem.
• Encorajar o crescimento do mercado de ferramentas de
objetos.
• Admitir conceitos de desenvolvimento de nível mais alto,
como componentes, colaborações, frameworks e padrões.
Dessa forma, a UML propõe-se ser uma linguagem
universalmente utilizada para o desenvolvimento de software, sendo
adequada para projetos com diferentes finalidades e em diferentes
dimensões. Segundo Booch, Rumbaugh e Jacobson (2005), a
UML apresenta estes blocos de construção, que se constituem em
elementos fundamentais: itens (elementos de composição básicos
da UML); relacionamentos (elementos de ligação entre os itens);
e diagramas (representações gráficas de itens e relacionamentos).
Para compreendermos esses elementos, precisamos entender o
conceito de orientação a objetos – paradigma de programação no
qual a UML se baseia. Essa propõe-se ser de fácil compreensão, uma
vez que os códigos de programação estruturados nesse paradigma
utilizam o conceito de objetos para sua representação. Tendo isso
em vista, imagine um objeto qualquer, um automóvel, por exemplo.
Depois, suponha que esse automóvel é composto de vários outros
objetos subordinados a ele, como pneus, portas, volante, bancos e

motor. Agora, pense que esse automóvel, um objeto, faz parte de
uma classe de objetos mais generalizada, como a de veículos de
determinada marca.
Na orientação a objetos, as definições ocorrem de modo
similar. Assim, classes são formas de se classificar elementos de
um sistema em uma mesma categoria, sendo os objetos exemplos
de determinada categoria. No caso do automóvel mencionado, os
objetos têm atributos, propriedades e comportamentos.
Os itens, relacionamentos e diagramas da UML são
apresentados com base no conceito de orientação a objetos. Alguns
itens, segundo Booch, Rumbaugh e Jacobson (2005), encontram-
se a seguir:
• Classes: itens que descrevem um conjunto de objetos com as
mesmas características.
• Interface: item que retrata o comportamento externo de uma
classe ou componente.
• Caso de uso: diagrama que descreve as ações realizadas pelo
usuário e pelo sistema, de modo a visualizar as interações
feitas por esse sistema.
• Ator: elemento que interage com o sistema, como um usuário;
• Componentes: elementos que modulam o sistema.
• Nós: elementos físicos que contêm memória e capacidade de
processamento.
• Máquinas de estado: comportamentos que representam
sequências de estados de um sistema.
Para melhor entendimento, observe a Figura 1, que ilustra esses
itens.
Figura 1 – Formas de representação de alguns itens utilizados pela

UML
CLASSE
CASO DE USO Atributo
Método INTERFACE
ATOR
COMPONENTE NÓ ESTADO
Fonte: Elaborada pelo autor com base em Booch, Rumbaugh, Jacobson, 2005.
Essa figura ilustra alguns dos principais elementos utilizados

nos diagramas UML. A utilização desses elementos, de modo
padronizado nos diagramas, possibilita a compreensão do projeto de
software por parte de outros engenheiros de software, assim como
dos desenvolvedores que, no ato da programação, transformam
esses elementos em linhas de código.
Os relacionamentos, por sua vez, constituem-se nas diferentes
formas com as quais os itens da UML se relacionam e trocam
mensagens entre si, sendo os seguintes:
• Associação: relacionamento simples entre dois elementos,
conectando-os entre si e demonstrando qual parte de um
elemento se relaciona com o elemento de outra parte.
• Dependência: relacionamento de dependência entre dois
elementos, com um independente e outro dependente – a
alteração do elemento independente resulta, necessariamente,
na alteração do dependente.
• Generalização: relacionamento de especialização e
generalização, no qual os elementos especializados herdam
características dos elementos generalizados.
• Realização: relacionamento no qual um elemento especifica

as regras que o outro elemento deve executar.
A Figura 2 ilustra os possíveis relacionamentos entre os
elementos da UML, bem como um exemplo de como utilizá-los.
Figura 2 – Possíveis relacionamentos entre os elementos da UML

0..1 0..*
ASSOCIAÇÃO
vendedor cliente
DEPENDÊNCIA
GENERALIZAÇÃO
REALIZAÇÃO
Fonte: Elaborada pelo autor com base em Booch, Rumbaugh; Jacobson, 2005.
A Figura 2 apresenta as principais formas de relacionamento

entre os elementos da UML. A associação geralmente é representada
por uma linha cheia simples; a dependência é simbolizada por uma
flecha tracejada com as extremidades abertas; a generalização é
retratada por uma flecha em linha cheia com a ponta em triângulo;
por sua vez, a realização é ilustrada por uma linha tracejada com a
ponta também em triângulo. Essa padronização da representação
gráfica de cada tipo de relacionamento é relevante, principalmente,
no caso de diagramas estruturais, em que é possível estabelecer,
para classes e objetos em programação, relações como herança,
polimorfismo, dentre outros.
Ainda na Figura 2, os números constantes na linha de
associação – que poderiam estar representados nas outras formas
de relacionamento – dizem respeito a outro importante conceito:

o de multiplicidade (GUEDES, 2011). Em um diagrama de classes,
esse conceito diz respeito à quantidade de objetos de uma classe que
estarão relacionados com o da outra classe. No exemplo em questão,
no mínimo 0 objeto e no máximo 1 objeto da classe vendedor será
relacionado a objetos da classe cliente, ao passo que no mínimo
0 objeto e no máximo muitos objetos da classe cliente estarão
relacionados à classe vendedor. Sendo assim, um vendedor pode ter
nenhum ou vários clientes, já cada cliente terá 0 ou 1 vendedor.
Além de itens e relacionamentos, a UML faz o uso de diagramas,
isto é, representações gráficas de elementos que possibilitam a
visualização do sistema como um todo. Os principais diagramas
utilizados pela UML – comportamentais e estruturais – são
abordados nas próximas seções deste capítulo.
Vídeo
4.2 Diagramas
comportamentais
Os diagramas comportamentais têm o intuito
de especificar, descrever e documentar os possíveis
comportamentos do sistema e do usuário. Desse
modo, enfatizam questões como usabilidade, aspectos temporais,
troca de mensagens entre sistemas e entre sistemas e usuários, além
de mudanças de estado.
De acordo com Booch, Rumbaugh e Jacobson (2005), os
principais diagramas comportamentais da UML são diagrama de
caso de uso, diagrama de sequência, diagrama de comunicação,
diagrama de gráfico de estados e diagrama de atividades, descritos
a seguir.
• Diagrama de caso de uso

Esse foi um dos primeiros diagramas elaborados no processo de
modelagem de software e é amplamente utilizado para a definição
de requisitos funcionais e não funcionais.
O diagrama de caso de uso apresenta as possíveis situações de
uso do sistema por parte do usuário. Desse modo, os usuários são
representados como atores e interagem com o sistema por meio de
suas funcionalidades (caso de uso), representadas por frases escritas
dentro de uma figura no formato de elipse.
Assim, cada caso de uso tem um relacionamento com o ator
que o realiza, seja usuário ou sistema. Segundo Lima (2009), esses
relacionamentos ocorrem nas modalidades extensão, inclusão e
generalização.
O relacionamento de extensão consiste na adição das
características de um caso de uso em um segundo caso de uso e é
representado por uma flecha tracejada com a palavra “<<extend>>”
na parte superior, apontada para o caso de uso estendido. O primeiro
caso de uso, que é estendido, é denominado caso de uso básico, e o
segundo é denominado caso de uso de extensão.
Já o relacionamento de inclusão significa que o primeiro caso de
uso também conterá características do segundo, denominado caso
de uso de inclusão, e é representado por uma flecha tracejada com
a palavra “<<include>>” na parte superior, apontada para o caso de
uso incluído.
O relacionamento de generalização, por sua vez, indica que o
primeiro caso de uso consiste em uma especialização do caso de uso
ou ator e é representado por uma seta em linha sólida apontando
para o caso de uso ou ator mais geral.
Para melhor compreensão, observe a Figura 3, que ilustra

um exemplo de diagrama com as possíveis interações de um ator
(cliente) com um sistema de vendas, bem como os relacionamentos
de inclusão entre as partes desse sistema.
Figura 3 – Exemplo de diagrama de caso de uso
Selecionar peça
Autorizar acesso
Acrescentar
<<include>> cliente
Fazer pedido Atualizar cliente

Cliente
<<include>>
Selecionar <<include>>
Restituir pedido Localizar pedido
assentos
Fonte: Pender, 2004, p. 48.
No diagrama representado na Figura 3, um usuário pode realizar

diferentes ações em um sistema de vendas. Cada elemento inserido
nas elipses representa um caso de uso ou uma possível ação a ser
realizada. Desse modo, o usuário, sendo um cliente nesse sistema de
vendas, pode realizar uma compra on-line por meio de ações como
fazer um pedido (que inclui selecionar peças e selecionar assentos),
acrescentar e atualizar seus dados e, inclusive, restituir o pedido (que
incluirá, nesse caso, a localização do pedido para ser restituído).
• Diagrama de sequência
Esse diagrama descreve a sequência de execução do sistema,
dando ênfase à troca de mensagens entre atores, interfaces e sistema.
Nesse diagrama, o usuário (ou ator) e os demais elementos da

UML são representados na parte superior do diagrama. Porém,
há uma linha tracejada vertical (linha de vida) abaixo deles, que
representa a existência e a atuação desses objetos de acordo com o
tempo (quanto mais para baixo, mais tempo passou). Há retângulos
sobre cada linha vertical, que representam o momento em que o
ator, interface ou componente do sistema é chamado e executa uma
atividade.
As flechas horizontais representam as trocas de mensagens
ocorridas entre os objetos, as quais partem da origem até o
destinatário. Quando essa flecha é de espessura fina, a mensagem é
assíncrona, ou seja, não necessariamente possuirá uma mensagem
de retorno correspondente, já quando a flecha é de espessura maior
com linha triangular cheia, a mensagem é síncrona, ou seja, possuirá
uma mensagem correspondente de retorno (por exemplo, uma
chamada).
Observe a Figura 4, que ilustra um exemplo de diagrama de
sequência.
Figura 4 – Exemplo de diagrama de sequência
sd Atualização de produtos
cat1 :Categoria :Produto
Funcionário Interface_Sistema Controlador_Sistema

Selecionar categoria
Categoria selecionada conCat()
Informar verdadeiro :int

percentual de
aumento Percentual de aumento loop
[Para cada produto]
Atualizar()
verdadeiro :int
Fonte: Guedes, 2011, p. 211.

A figura 4 ilustra um exemplo de uso de um sistema de

atualização de produtos (por exemplo, de uma loja virtual).
Utilizando uma interface (como uma página de internet on-line),
o usuário seleciona uma categoria de produtos. A interface envia
a informação da categoria selecionada ao controlador do sistema,
o qual retornará uma mensagem de que a categoria existe e é
verdadeira. A seguir, o usuário informa um percentual de aumento
no preço dos produtos da categoria selecionada na interface, que
repassa, novamente, essa informação ao controlador, que comanda
a atualização das informações de cada produto na base de dados.
• Diagrama de comunicação
Um diagrama de comunicação enfatiza a participação e
a interação entre os elementos de um sistema, bem como as
comunicações existentes e as mensagens trocadas entre esses objetos.
Primeiramente, inserem-se nesse diagrama os elementos
participantes dessa interação. Depois, conectam-se os elementos por
meio de linhas cheias e flechas representando as mensagens trocadas
entre esses elementos. Cada mensagem é sequenciada por meio de
um número (por exemplo, 1, 2, 3...). Observe a Figura 5, que ilustra
um exemplo desse tipo de diagrama.
Figura 5 – Exemplo de diagrama de comunicação
sd Emitir Saldo
2. Informar a senha 2.1: Senha

1. Inserir cartão da conta 1.1: Número da conta
1.4: Solicitar senha
:Interface_Banco 2.6: Saldo :Controlador_Banco
:Cliente
1.2: consultar_Conta(long) 1.3: verdadeiro: int
2.2: validar_Senha(int) 2.3: verdadeiro: int
2.4: saldo_Conta( ) 2.5: saldo :double
:Conta_Comum

Na situação representada na Figura 5, há uma troca de

informações entre um cliente e um sistema bancário. O cliente
informa dados como o número do cartão da conta bancária e a sua
senha. A interface do banco (por exemplo, o sistema de um caixa
eletrônico) repassa essa informação a um sistema controlador do
banco, que, validando a senha informada pelo cliente, consulta a
conta e solicita o saldo à base de dados da conta. A base de dados
retorna o valor do saldo da conta, o qual novamente é repassado
pelo sistema controlador do banco, por meio da interface, ao cliente.
• Diagrama de gráfico de estados
Esse diagrama exibe uma máquina de estados, ou seja, apresenta
os estados de atividades de um sistema, assim como os fluxos entre
um estado e outro. Esses estados são representados por retângulos
com bordas arredondadas, podendo estar inseridos dentro de um
estado aninhado (representado da mesma forma, só que no formato
de um retângulo maior que inclui os demais). O estado inicial é
representado por um círculo e as setas representam a evolução entre
um estado e outro, bem como as mensagens e condições para a
transição entre os estados acontecer. A Figura 6 ilustra um exemplo
desse tipo de diagrama.
Figura 6 – Diagrama de gráfico de estado

stm Emitir Saldo
Número da conta informado Senha informada Validando Senha

Consultando conta
+ do / validar_Senha()
+ do / consultar_Conta()
Emitir saldo
Estado Inicial
Consultando Saldo
+ do / saldo_Conta()
Saldo
Estado Final

A situação apresentada na Figura 6 ilustra os possíveis estados em

um sistema de emissão de saldos bancários. Caso o usuário informe
o número de sua conta, o sistema passa de um estado inicial (de
escuta de informações) para o estado “Consultando Conta”. Após o
usuário digitar a sua senha, o sistema passa para o estado “Validando
Senha”, e se a senha é correta e o usuário solicita a emissão do saldo,
o sistema passa para o estado “Consultando Saldo”, e finaliza em um
estado final.
• Diagrama de atividades
Esse diagrama mostra a sequência de atividades realizadas pelo
sistema, abrangendo condições para a realização de uma atividade
ou outra (representadas no diagrama por losangos), atividades
realizadas em paralelo (representadas por barras horizontais de cor
escura), dentre outras.
Similarmente ao diagrama de gráfico de estados, as atividades
também são representadas por retângulos com bordas arredondadas,
o início das atividades por um círculo e a sequência das atividades por
flechas. Porém, há a possibilidade de inclusão de condições para que
determinada atividade, ou outra, seja realizada por meio de losangos
contendo cada condição. Ao mesmo tempo, há a possibilidade da
representação de atividades sendo realizadas em paralelo, por meio
de uma barra horizontal inserida no local onde o paralelismo inicia.
A Figura 7 ilustra um tipo desse diagrama.
Figura 7 – Exemplo de diagrama de atividades
Exibir peças
Exibir eventos padrão
[Usuário selecionou cancelar]
[Usuário selecionou
uma peça]
[Usuário selecionou
um evento] Exibir confirmação
[Usuário informou
intervalo de datas]
[Não]
Exibir peças para evento
selecionado [Sim]
Salvar informações
Exibir peças para o intervalo

informado
Fonte: Pender, 2004, p. 48.
O diagrama apresentado na figura 7 ilustra uma sequência de

atividades para a seleção de um evento artístico em um sistema de
vendas on-line. Os eventos e as peças padrão (mais selecionadas)
são exibidos simultaneamente ao usuário. A seguir, o usuário toma
uma decisão (selecionar um evento ou cancelar). Caso cancele o
processo, o sistema exibirá as peças para o evento selecionado. Caso
o usuário selecione um intervalo de datas, o sistema exibirá peças
para o intervalo informado pelo usuário. Caso o usuário selecione
uma peça, o sistema solicitará uma confirmação por parte deste, que,
caso seja feita, as informações serão salvas e o processo é finalizado.
Antes de se modelar o sistema estruturalmente, é importante que
os aspectos comportamentais do usuário sejam descobertos e
modelados. Os diagramas comportamentais atendem a essa
necessidade, ao permitir a modelagem das múltiplas maneiras pelas
quais um sistema poderá ser utilizado.
Vídeo
4.3 Diagramas estruturais
Os diagramas estruturais “existem para
visualizar, especificar, construir e documentar
os aspectos estáticos de um sistema” (BOOCH,
RUMBAUGH; JACOBSON, 2005, p. 96), ou seja,
enfatizam os aspectos estruturais e técnicos de um sistema, como
classes, interfaces, componentes, dentre outros.
Segundo Booch, Rumbaugh e Jacobson (2005), os principais
diagramas estruturais da UML são diagrama de classes, diagrama
de componentes, diagrama de artefatos e diagrama de implantação,
descritos a seguir.
• Diagramas de classes
Esses diagramas são “encontrados com maior frequência
na modelagem de sistemas orientados a objetos” (BOOCH,
RUMBAUGH; JACOBSON, 2005, p. 107). Essa frequência se deve ao
fato de a orientação a objetos se basear, dentre outros fatores, no uso
de classes e objetos para a representação de elementos em um sistema.
Já os diagramas de objetos, construídos de modo similar ao diagrama
de classes, representam objetos construídos a partir de determinadas
classes de origem.
A Figura 8 ilustra o diagrama de classes. O diagrama de objetos

tem formato similar, com a diferença de que os nomes, atributos e
métodos dizem respeito a objetos em vez de classes.
Figura 8 – Diagrama de classes
class Modelo Conceitual – Sistema de Controle Bancário

Movimento
- tipo_mov: int
- /dt_mov: Date
- /hor_mov: Time
- val_mov: Double
1..*
registra
Pessoa Conta_Comum
# nom_pessoa: String # nro_conta: long
# end_pessoa: String possui # /dt_abertura: Date
# cep_pessoa: long # /dt_encerramento: Date [0..1]
# tel_pessoa: String 1..* 1..*
# situação: int = 1
# renda_pessoa: double # senha: int
# sit_pessoa: int # /saldo: double = 0
Pessoa_Fisica Pessoa_Juridica Conta_Especial Conta_Poupança
- cpf_pessoa: long - cnpj_pessoa: long - limite_conta: double - dt_aniversario: Date

- rg_pessoa: long
As associações entre classes, ou entre objetos, são feitas por

flechas de relacionamentos, a representação de uma classe é feita
por um retângulo segmentado em três partes por meio de uma linha
horizontal – a parte superior contém o nome, ou identificação, da
classe, e a parte inferior, por sua vez, contém os métodos ou funções
executadas pela classe.
• Diagrama de componentes
Esses diagramas visam a representação de componentes ou
partes segmentáveis de um sistema. Um componente “é uma parte
substituível de um sistema ao qual se adapta e fornece a realização de
um conjunto de interfaces” (BOOCH; RUMBAUGH; JACOBSON,

2005, p. 196). Assim, um componente é um segmento de um sistema
que possibilita interações e trocas de serviços e mensagens com
outra parte do sistema.
Os componentes interagem entre si e com as classes por meio
de relacionamentos ou por interfaces. Interface “é uma coleção de
operações utilizadas para especificar um serviço de uma classe ou
de um componente” (BOOCH et al., 2005, p. 197). Desse modo,
interfaces podem ser fornecidas por componentes e requeridas por
outros, que ao receberem-nas podem entrar em funcionamento. A
Figura 9 ilustra um diagrama de componentes.
Figura 9 – Diagrama de componentes
cmp Sistema de Controle Bancário
Interface Caixa
Eletrônico
Firewall Gerenciador de
Autoatendimento
Gerenciador de
SGBD
Contas
A Figura 9 ilustra o diagrama de componentes de um sistema

de controle bancário. Nesse diagrama, encontram-se ilustrados
os principais componentes do sistema, como gerenciadores de
autoatendimento e de contas, uma interface com o usuário e um
SGBD (Sistema de Gerenciamento de Banco de Dados). Nesse

caso, a interface do caixa eletrônico (componente que se relaciona
diretamente com o usuário) é separada dos sistemas gerenciadores
por meio de um sistema firewall, que filtra as informações do usuário
de modo a evitar fraudes, por exemplo.
• Diagrama de artefatos
Esse diagrama permite a representação de aspectos físicos de um
sistema, como arquivos, páginas de internet e bancos de dados. A
Figura 10 ilustra exemplos de diagrama de artefatos.
Figura 10 – Diagrama de artefatos
dlog.dll
<<artifact>>
animator.exe
wrfrme.dll
render.dll
raytrce.dll
Fonte: Booch; Rumbaugh, Jacobson., 2005, p. 358.
Nessa figura, podemos observar os diferentes arquivos que

compõem um sistema de animação gráfica. Percebe-se, nesse caso,
que para a execução do arquivo “animator.exe” há dependência de
vários outros arquivos no formato .dll (bibliotecas).
Esses diagramas são úteis para a visualização das relações entre
o sistema e os componentes físicos – por exemplo, quais arquivos ou
bibliotecas se relacionam entre si e em qual linguagem (ou extensão),

ou a relação entre as diferentes tabelas de um banco de dados entre si
e com outras partes do sistema.
• Diagrama de implantação
Esse diagrama representa os aspectos de implantação de um
sistema após ser desenvolvido, contemplando comunicação de rede,
estrutura de hardware e nós de processamento.
Assim como em outros diagramas, é possível inserir
relacionamentos, como dependência e associação, entre os
elementos desse diagrama. A Figura 11 ilustra um exemplo de
diagrama de implantação.
Figura 11 – Diagrama de implantação
<<device>>
Servidor de Aplicação Departamento de Contabilidade
Sistema de Contabilidade
Sistema de Folha de Pagamento
<<TCP-IP>>
<<device>>
Servidor de Aplicação Departamento de Vendas
Sistema de Controle de Estoque

Na situação apresentada na Figura 11, encontram-se

representados dois computadores atuando como servidores: um
servidor para um departamento de contabilidade e outro para um
departamento de vendas. Ambos se encontram associados por
meio de uma conexão TCP/IP (internet). O sistema de controle
de estoque, armazenado no servidor do departamento de vendas,
encontra-se em uma relação de dependência de dados do sistema
de contabilidade, localizado no servidor do departamento de
contabilidade. Da mesma forma, o sistema de folha de pagamento
também é dependente, em termos de dados, do sistema de
contabilidade. Assim, por meio desse diagrama, é possível perceber
que a implantação do sistema de contabilidade será primordial
para o funcionamento dos demais sistemas.
Os diagramas estruturais da UML, desse modo, são relevantes
para que engenheiros de software e desenvolvedores compreendam
o funcionamento do sistema e de seus componente antes de se iniciar
o processo de desenvolvimento. A partir dos diagramas estruturais,
é possível definir a estrutura de um sistema e estimar prazos para o
desenvolvimento de cada funcionalidade.
A UML consiste em um padrão universal de modelagem de
sistemas. Para isso, vale-se de notações visuais de fácil compreensão
e utilização, como símbolos, formas geométricas, flechas e outras
formas de representação.
Os diagramas UML são muito úteis para a modelagem de
sistemas, por possibilitarem a visualização de um sistema por
diferentes pontos de vista, seja do usuário ou do sistema.
Assim, um dos principais benefícios da UML é facilitar o
processo de desenvolvimento de software, pois as notações visuais
facilitam o trabalho do engenheiro de software em compreender o
sistema, antes mesmo que a primeira linha de código seja elaborada.
Portanto, vale a pena, antes de começar a programar qualquer

sistema, você dispor de um esforço inicial para modelá-lo usando a
UML. Você vai economizar tempo e dinheiro.

• GLIFFY. Gliffy, 2019. Diagramming software that works
at the speed of your ideas. Disponível em: www.gliffy.com.
Acesso em: 12 nov. 2019.
Este software é gratuito e possibilita a modelagem com o uso
de UML, conforme apresentado neste capítulo, sendo ideal
para praticar o uso dessa notação.
• GUEDES, G. T. A. UML 2: uma abordagem prática. São Paulo:

Novatec, 2011.
Este livro explica, de modo didático, a UML e seus principais
diagramas, com vários exemplos de representação gráfica
dos diagramas.
Atividades
1. Escolha um aplicativo qualquer. Liste as possíveis formas de
uso desse aplicativo, bem como suas funcionalidades. Com
base nessa listagem, elabore um diagrama de caso de uso
para esse aplicativo.
2. Escolha um aplicativo qualquer. Abra-o e o utilize por alguns

instantes. Anote todas as ações que você realiza em sequência
e a resposta dada pelo aplicativo (por exemplo: “agora digito
o login e a senha”, “o aplicativo responde que minha senha
está correta”, “o aplicativo abre a tela”, “eu aperto determinado
botão”, “acontece tal coisa”). Com base nas suas anotações,

elabore um diagrama de atividades para esse aplicativo.
3. Imagine que você foi contratado como engenheiro de

software para a modelagem de um aplicativo para reservas
de viagens (hotel e passagens aéreas). Elabore um diagrama
de caso de uso, descrevendo os possíveis casos de uso para
esse aplicativo, e um diagrama de atividades, descrevendo a
sequência de uso deste aplicativo.
Referências
BLAHA, M.; RUMBAUGH, J. Modelagem e projetos baseados em objetos
com UML 2. Rio de Janeiro: Elsevier, 2006.
BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML: guia do usuário. Rio

de Janeiro: Elsevier, 2005.
GUEDES, G. T. A. UML 2: uma abordagem prática. São Paulo: Novatec,

2011.
LIMA, A. S. UML 2.2: do requisito à solução. São Paulo: Saraiva, 2009.
PENDER, T. UML: a bíblia. Rio de Janeiro: Elsevier, 2004.

5
Gestão de projetos de software
Toda atividade de desenvolvimento de software apresenta

início, meio e fim, utiliza recursos humanos, materiais e financeiros
finitos e tem como objetivo criar um produto totalmente novo
ou melhorar significativamente um produto existente. Desse
modo, desenvolver um software significa elaborar um projeto,
de preferencia, inovador, que faça o melhor aproveitamento
possível dos recursos investidos, sejam da própria equipe de
desenvolvimento sejam captados de terceiros.
Neste capítulo, vamos tratar de uma competência de extrema
relevância para o engenheiro de software: a habilidade de planejar,
implantar, conduzir e analisar projetos. Portanto, vamos estudar o
desenvolvimento de arquiteturas de software em diferentes escalas
– conhecimento fundamental para a condução bem-sucedida de um
projeto de software.
Vídeo
5.1 Projeto de software:
elementos básicos
Toda vez que alguém sonha em realizar algo,
a tendência é de, primeiramente, transformar esse
sonho em projeto. Uma viagem, por exemplo,
nasce da vontade de alguém viajar. Esse sonho se transforma em um
roteiro, com definições de para onde ir, o que visitar, onde comer
etc. Considerando que nenhuma viagem tende a durar para sempre,
é necessário definir as datas de ida e de retorno. Além disso, visto
que ninguém possui recursos financeiros infinitos, é fundamental
planejar para onde ir e quanto gastar. Outros aspectos a serem
considerados são os riscos, isto é, acontecimentos que podem
impactar negativamente a viagem e os viajantes, como evitar locais

perigosos ou contratar um seguro viagem. Enfim, planejar uma
viagem é o exemplo ideal de um projeto.
Esse processo é semelhante ao de desenvolvimento de um
software, para o qual é indispensável definir as funcionalidades
que serão ou não desenvolvidas (escopo do projeto); um
cronograma para o desenvolvimento de cada componente; o
modo como os recursos humanos, financeiros e materiais serão
alocados em cada parte do projeto; os custos e o tempo necessário
para o desenvolvimento. Logo, desenvolver um software significa
administrar e realizar projetos.
De acordo com o PMBOK (Project Management Body of
Knowledge) – uma das principais referências em gestão de projetos
–, um projeto é “um esforço temporário empreendido para criar
um produto, serviço ou resultado único. A natureza temporária
dos projetos indica que eles têm um início e um término definidos”
(PMI, 2014, p. 26). Ainda de acordo com o PMBOK (PMI, 2014),
um projeto possui alguns componentes básicos, como escopo,
tempo, custo, qualidade, riscos, recursos humanos, aquisições,
comunicação e integração, os quais vamos estudar a seguir.
5.1.1. Escopo
O escopo consiste na definição de como será realizado um
projeto. No caso de um software, o escopo define, portanto, as
funcionalidades que serão ou não implantadas e os requisitos
funcionais e não funcionais desse projeto.
De acordo com o PMBOK (PMI, 2014), o escopo de um projeto
também deve considerar o gerenciamento das partes interessadas,
ou seja, se o escopo de um projeto e seus requisitos atendem às
necessidades de clientes, fornecedores, patrocinadores e outros que, de
alguma forma, possam ser impactados pelos resultados desse projeto.
Para a definição do escopo de um projeto, pode-se utilizar várias
técnicas, como a realização de entrevistas com as partes interessadas,
Gestão de projetos de software 85
de modo a identificar as necessidades de desenvolvimento e os

requisitos. Além das entrevistas, outros métodos possíveis podem
ser, por exemplo, criar grupos de discussão entre desenvolvedores
e clientes; produzir protótipos do software para verificar se as
funcionalidades estão de acordo com as necessidades do cliente;
elaborar técnicas criativas em grupo, como o brainstorming, que
consiste em gerar ideias coletivas de modo rápido e em grande
quantidade; ou, ainda, obter informações utilizando o benchmarking,
que é a comparação, realizada por meio de pesquisa, do escopo do
projeto com projetos similares desenvolvidos por outras empresas
ou equipes de projeto.
Após essas etapas, o escopo de um projeto e seus requisitos
funcionais e não funcionais devem estar documentados. Uma das
formas de se realizar essa documentação é por meio da Estrutura
Analítica do Projeto (EAP), que consiste em dividir as entregas do
projeto em subentregas, de modo que possam ser gerenciadas em
partes, o que facilita o desenvolvimento do projeto como um todo. A
seguir, a Figura 1 ilustra um exemplo de Estrutura Analítica de Projeto.
Figura 1 – Exemplo de EAP
1. JOGO
1.1. Interface 1.2. Controles 1.3. Modelo
1.1.1. Telas 1.2.1. Controle 1.3.1. Banco de

via joystick dados
1.1.2. 1.2.2. Controles 1.3.2. Lógica e

Personagens por toque na tela mecânica do
jogo
1.1.3. Menus 1.2.3 Controles

via teclado
Fonte: Elaborada pelo autor.

Conforme demonstra a Figura 1, a estrutura analítica em um

jogo é composta de três grupos de entregas: interface, controles
e modelo. O primeiro grupo de entregas, interface, abrange as
entregas de telas, os personagens e os menus. O grupo de controles
envolve as entregas de controle via joystick, controles por toque na
tela e controles via teclado. E o terceiro grupo, de modelo, considera
as entregas de banco de dados e das lógicas e mecânicas do jogo.
Desse modo, entende-se que ao se realizar as entregas de cada grupo,
considera-se que a entrega maior (o grupo) foi realizada e, ao se
realizar a entrega dos três grandes grupos, considera-se que o jogo
por inteiro foi entregue.
Ao definir o escopo de um projeto de software, é imprescindível
considerar, também, os requisitos funcionais e não funcionais do
sistema a ser desenvolvido, visto que com base neles é possível
definir o tamanho de um sistema.
Para estabelecer o tamanho do sistema, pode-se utilizar a
técnica denominada contagem de pontos de função, mediante a qual
o tamanho do projeto é calculado com base na “complexidade de
fluxo de dados através das interfaces e funções de um produto,
por meio de regras padronizadas” (PAULA FILHO, 2009, p. 515).
Assim, o cálculo do tamanho de um projeto depende diretamente
das funcionalidades e dos fluxos de dados entre seus componentes.
Os pontos de função, segundo Paula Filho (2009), podem ser
classificados nos tipos a seguir.
• Entradas externas: processo pelo qual os dados se integram
no sistema de fora para dentro.
• Consultas externas: recuperações de dados de um ou mais
arquivos lógicos.
• Saídas externas: processo pelo qual os dados derivados se
apresentam ao usuário, ou seja, cruzam o sistema de dentro
para fora.
• Arquivos lógicos internos: dados logicamente correlatos,

possíveis de identificação pelo usuário, que se encontram
dentro de um aplicativo e mantido por meio de entradas
externas.
• Arquivos de interface externa: dados logicamente correlatos,
possíveis de identificação pelo usuário, mas consultados
apenas pelo sistema, sendo mantidos por outros aplicativos.
O método contagem de pontos de função é um dos mais utilizados
na indústria para a definição do tamanho de um software, assim como
para a precificação do desenvolvimento desse produto com o cliente.
5.1.2. Tempo
Desenvolver um software é uma atividade com início, meio e
fim. Sendo assim, é preciso considerar os impactos relacionados ao
tempo necessário para realizar esse desenvolvimento.
Um dos meios mais eficazes de realizar a gestão do tempo de um
projeto de software é a elaboração de um cronograma, que, segundo
o PMI (2014), pode ser de diferentes formas: consulta a opiniões de
especialistas para verificar o tempo de duração estimado para cada
atividade; uso de técnicas analíticas, como estudos, para verificar o
tempo de desempenho de cada tarefa; realização de reuniões com a
equipe de desenvolvimento para discutir esse cronograma.
Sugere-se que a elaboração do cronograma seja feita com base
nas entregas e subentregas propostas na EAP. Cada subentrega deve
ser realizada conforme determinado prazo, com marcos sinalizando
a data final de cada entrega.
5.1.3. Custos
Outro elemento essencial a ser considerado em um projeto de
software é o gerenciamento dos custos, que é possível a contar do
momento em que se sabe o que precisa ser desenvolvido (o escopo)
e a quantidade de tempo disponível a ser alocada.
Os analistas de desenvolvimento de software, por exemplo,

geralmente são profissionais que têm seus custos mensurados
por tempo, ou seja, por horas, meses e anos. O mesmo vale para
serviços como hospedagem na nuvem, licenças de software e
aluguel de equipamentos. Logo, deve-se considerar o escopo – o
que será entregue por esses profissionais e serviços – e o tempo
necessário para as entregas, mensurando-se, assim, o custo por
hora desses profissionais e serviços em relação ao escopo das tarefas
desempenhadas.
Dessa forma, preferencialmente antes de se executar um
projeto, ou uma fase dele, torna-se necessária a realização de
uma estimativa de custos tanto fixos (que não dependam de
tempo de desenvolvimento) quanto variáveis (que dependem da
quantidade de tempo), que possam impactar o desenvolvimento
do projeto. Assim, recomenda-se a realização de um orçamento
para cada fase do projeto, contemplando recursos humanos,
materiais, financeiros e tecnológicos fundamentais e tendo em
vista que a alocação adequada de recursos para a realização do
projeto impacta diretamente na qualidade dos resultados obtidos,
conforme descrito a seguir.
5.1.4. Qualidade
A qualidade de um projeto de software diz respeito à sua
adequabilidade aos requisitos e aos interesses das partes envolvidas,
a qual pode ser mensurada por métricas ou indicadores de
qualidade. Por meio das métricas, é possível verificar se a realização
do projeto está de acordo com as políticas e normas necessárias e
com os requisitos definidos conforme o escopo. Já os indicadores
podem ser utilizados para a mensuração de todos os aspectos de um
projeto, como tempo, custos, qualidade, aquisições e riscos. Alguns
exemplos de métricas em projetos de software são:
• tempo dispendido por funcionalidade desenvolvida;
• quantidade de linhas de código desenvolvidas por hora;
• custo total do projeto por mês;

• aquisições efetuadas por mês;
• probabilidade de determinado risco ocorrer no projeto.
Outra forma de avaliar a qualidade de um projeto é por meio
da realização de auditorias da qualidade. Essas auditorias podem
ser realizadas pelo pessoal interno do projeto (primeira parte), por
fornecedores (segunda parte) ou por um organismo de certificação
(terceira parte). Os resultados das auditorias são geralmente
descritos em um relatório, em que se evidencia as conformidades e
não conformidades do processo auditado.
Com base nas conformidades ou não conformidades detectadas
pelos indicadores ou pelos relatórios de auditoria interna, podem ser
realizadas ações corretivas e melhorias no projeto de modo que as
conformidades sejam reforçadas e as não conformidades sejam
solucionadas e não voltem a ocorrer no projeto.
Vídeo
5.2 Projeto de software:
elementos acessórios
A atividade de desenvolvimento de software
envolve, ainda, riscos a serem considerados,
como mudanças na equipe de desenvolvimento,
incompatibilidade do sistema desenvolvido com os demais
softwares e hardware do cliente, que, se não forem consideradas
logo no início do projeto, podem acarretar custos e tempo
adicionais, prejudicando o desempenho do projeto como um todo.
Vale destacar que um projeto é planejado e implementado por
pessoas, portanto é relevante efetuar a gestão dos recursos humanos,
bem como dos diferentes canais de comunicação entre os membros
e as partes interessadas de um projeto. Além dos recursos humanos,
são indispensáveis políticas e ações para a aquisição de recursos
materiais, de modo que o projeto conte com a matéria-prima
necessária para sua efetiva execução.
Os itens a seguir tratam da gestão de riscos, comunicação,

recursos humanos e aquisições, que embora sejam acessórios são
tão relevantes quanto os itens básicos em um projeto.
5.2.1. Riscos
Além de escopo, custo, tempo e qualidade, existem outros
componentes que devem ser considerados na elaboração, realização
e análise de um projeto de software. Esses componentes, embora
secundários em relação aos mencionados anteriormente, também
merecem consideração para que o projeto seja executado com
a máxima eficiência (melhor utilização de recursos) e eficácia
(obtenção de resultados satisfatórios).
Um dos componentes também importantes em um projeto
de software é a gestão de riscos. Sendo uma atividade de
desenvolvimento tecnológico e que utiliza uma variedade e
complexidade de componentes físicos e virtuais, um software ou
sistema apresenta riscos no processo de desenvolvimento, os quais
geralmente são mensurados por meio de duas variáveis básicas:
probabilidade e impacto.
A probabilidade diz respeito às possibilidades quantitativas
de o risco se transformar no acontecimento de fato e geralmente
é mensurada em termos de porcentagem: quanto maior for a
porcentagem, maiores serão as chances de o risco se concretizar.
No entanto, caso o risco se concretize, o impacto diz respeito aos
possíveis acontecimentos que impactarão positiva ou negativamente
o projeto como um todo. São exemplos de impactos: perdas materiais
ou financeiras, atrasos no cronograma do projeto, problemas na
equipe de trabalho, entre outros.
5.2.2. Comunicação
Para a execução de todo projeto, é necessária a comunicação
entre os próprios membros da equipe desenvolvedora e entre essa
equipe e as partes interessadas. Essa comunicação pode ser feita
por meio de reuniões, dispositivos de comunicação (chats, por

exemplo), redes sociais, newsletters (informativos), murais, veículos
de comunicação de massa etc.
Dentre o que necessita ser comunicado em um projeto,
encontram-se a sua situação atual, informações essenciais para o
desenvolvimento, necessidades de recursos, potenciais riscos que
possam surgir durante o desenvolvimento, dentre outros.
A comunicação é essencial em um projeto de software,
principalmente quando há múltiplas equipes de desenvolvimento.
Como cada equipe geralmente é estruturada para desenvolver
componentes específicos de um software, algumas ferramentas,
como murais Kanban, se tornam essenciais para que todas as
equipes saibam, mutuamente, em que estágio cada uma está no
desenvolvimento de seu componente. No mural Kanban, ilustrado
na Figura 2, colocam-se apontamentos, geralmente por meio de
post-its, para sinalizar, em cada estágio de desenvolvimento, em
que lugar o componente do software está localizado – por exemplo,
determinado componente pode estar por fazer, outro com o
desenvolvimento em progresso e um em fase de implantação.
Figura 2 – Exemplo de mural Kanban
Fonte: Adaptada de Quarta/Shutterstock

Outro exemplo do uso da comunicação é no método de

desenvolvimento scrum. Antes da realização de cada atividade de
desenvolvimento, reuniões são realizadas entre os membros de cada
equipe para discutir as entregas a serem efetuadas no projeto.
5.2.3. Recursos humanos

A gestão de pessoas também é relevante para o sucesso de um
projeto de software, principalmente devido à possibilidade de haver
equipes multidisciplinares – equipes com profissionais de diferentes
áreas do conhecimento e origens culturais.
Dessa forma, cabe aos gestores de projeto a manutenção de
equipes de trabalho saudáveis, com um bom relacionamento entre
seus membros. Além disso, recomenda-se que as lideranças sejam
definidas e formalizadas, que as competências dos profissionais
sejam aproveitadas efetivamente nas atividades do projeto e que as
negociações entre os membros da equipe proporcionem, sempre que
possível, vantagens para ambos os lados.
Para que os recursos humanos do projeto sejam aproveitados,
algumas atividades são necessárias. A primeira é a mobilização da
equipe do projeto, que consiste na contratação dos membros do
projeto. Outra atividade é o desenvolvimento, que se relaciona com
as iniciativas de treinamento e a capacitação das equipes do projeto.
Ainda, é fundamental o gerenciamento da equipe do projeto por
meio das ferramentas de comunicação.
5.2.4. Aquisições
Além dos recursos humanos, é importante considerar
em um projeto de software a aquisição e o uso adequado dos
recursos materiais. Em relação a essas aquisições, vale destacar a
necessidade de compras de ativos, como servidores, computadores,
dispositivos de comunicação móvel, serviços de telecomunicações,
hospedagem de conteúdo na nuvem, entre outros.
O gerenciamento das aquisições em um projeto é realizado por

meio de três etapas essenciais: planejamento, condução e controle.
Na primeira etapa, planeja-se o que se pretende adquirir, com a
análise e avaliação de propostas e a realização de negociações com os
fornecedores conforme necessário. Já na segunda etapa, realizam‑se
a aquisição e o pagamento dos recursos adquiridos, além do
acompanhamento da aquisição para verificar se o recurso adquirido
chegará com sucesso ao local da entrega. Por fim, na terceira etapa,
controlam-se as aquisições e realizam-se inspeções e auditorias para
verificar se o conteúdo recebido corresponde ao que foi solicitado e,
caso necessário, são feitas reivindicações com o fornecedor.
5.2.5. Integração
A integração envolve as atividades de abertura, planejamento,
mudanças e encerramento do projeto, abrangendo os demais
componentes do projeto, como escopo, custos, tempo, qualidade,
riscos, comunicação, recursos humanos e aquisições, desde o início
até o final.
O termo de abertura é um dos documentos mais relevantes,
pois autoriza o início do projeto e descreve seus itens como
responsabilidades, requisitos, entregas, premissas e restrições. Outro
documento relevante é o plano de gerenciamento do projeto, que
descreve as diretrizes necessárias para gerenciar o projeto como
um todo, servindo de base para o planejamento das demais partes
componentes.
Desse modo, é possível observar que, assim como em outros
tipos de projetos, ao se desenvolver um software, é importante
elaborar um projeto considerando elementos como escopo,
tempo, custo, qualidade, riscos, comunicação, recursos humanos,
aquisições e integração, mesmo que o software utilize um método
ágil de desenvolvimento.
Além disso, mesmo que seja simplificado, como no caso de

projetos de menor porte, em um projeto de desenvolvimento de
software são necessários: um escopo, abrangendo as funcionalidades
que um software possuirá ou não; um cronograma, para que prazos
de entrega sejam cumpridos; e a definição dos custos relacionados
aos recursos humanos, materiais e financeiros, além de ações para
reduzir ou controlar possíveis riscos.
Vídeo 5.3 Projetos de arquiteturas de

software
Conforme Pressman e Maxim (2016), a
arquitetura permite analisar as funcionalidades
de um software, verificando o cumprimento dos
requisitos, a detecção e redução dos riscos e o estudo de alternativas
para sua melhoria, ou seja, consiste em um protótipo de alto nível
de um sistema.
Assim, o projeto de arquitetura do software norteia os
desenvolvedores em relação ao que necessita ser feito para que os
requisitos das partes interessadas sejam adequadamente atendidos
e o sistema seja implantado com sucesso e de modo funcional. De
acordo com Sommerville (2011), as arquiteturas de software podem
ser de pequena ou grande escala.
• Arquitetura de pequena escala: projeto de arquiteturas
de software individuais, ou seja, de como cada programa é
dividido em seus componentes menores;
• Arquitetura de grande escala: sistemas de maior
complexidade, geralmente distribuídos em mais de um
computador.
Ainda de acordo com o autor, o projeto de arquiteturas de

software apresenta uma série de vantagens, tanto para a equipe de
desenvolvimento quanto para as partes interessadas no projeto.
Dentre essas vantagens, um projeto de arquitetura adequadamente
realizado possibilita uma melhor comunicação entre os
desenvolvedores e as partes interessadas (principalmente clientes),
uma vez que a arquitetura consiste na apresentação de um sistema
em seu nível mais elevado.
Outra vantagem em projetar a arquitetura de um software consiste
na facilidade de análise e visualização do sistema como um todo e da
inter-relação de seus componentes, visto que “as decisões de projeto
de arquitetura têm um efeito profundo sobre a possibilidade de o
sistema atender ou não aos requisitos críticos, como desempenho,
confiabilidade e manutenibilidade” (SOMMERVILLE, 2011, p. 104).
Dessa forma, compreende-se que, com base no projeto de arquitetura,
é possível visualizar um sistema de modo que uma equipe de
desenvolvedores possa discutir sobre aspectos relacionados à eficácia
do sistema em atender aos requisitos desejados pelo cliente, o que
inclui aspectos como desempenho, confiabilidade e manutenibilidade.
Ainda, por descrever o modo de funcionamento de um sistema,
a arquitetura pode ser reaproveitada para o projeto de sistemas
com finalidades semelhantes, sem que se tenha que gastar tempo e
recursos com o desenvolvimento de funcionalidades. A reutilização
de arquiteturas é útil, principalmente, no desenvolvimento de
sistemas em grande escala, em que módulos ou partes componentes
desses sistemas podem ter funcionalidades semelhantes.
As arquiteturas a serem utilizadas no projeto de software podem
ser, segundo Pressman e Maxim (2016), centralizadas em dados,
de fluxo de dados, de programa principal e subprograma ou em
camadas, descritas a seguir.
• Arquitetura centralizada em dados

Conforme o nome sugere, insere-se um repositório de
armazenamento de dados em seu centro, sendo acessado por
softwares ou componentes clientes1 que transitam ao seu redor e
“que atualizam, acrescentam, eliminam ou modificam de alguma
maneira os dados contidos no repositório” (PRESSMAN; MAXIM,
2016, p. 259). Uma vantagem desse tipo de arquitetura reside nos
softwares clientes, que podem ser alterados de modo independente,
tendo em vista que dependem apenas do repositório de dados. A
seguir, a Figura 3 ilustra essa arquitetura.
Figura 3 – Arquitetura centralizada em dados
Software Software
cliente cliente
Software
cliente Software
cliente
Armazenamento de dados
(repositório ou “quadro-negro”) Software
Software cliente
cliente
Software Software
cliente cliente
Fonte: Pressman e Maxim, 2016, p. 259.
Uma aplicação dessa modalidade de arquitetura é a arquitetura

cliente-servidor, que consiste em um conjunto de servidores
associados a clientes, sendo que esses clientes acessam e utilizam os
serviços oferecidos pelo servidor. Podem ser implantadas em grupos
de servidores ou mesmo em um único servidor. A vantagem desse
1 Software ou componente cliente é quem solicita acesso ao servidor para interagir

e trocar dados com ele.
modelo de arquitetura, segundo Sommerville (2011), consiste no

fato de que os servidores podem se encontrar distribuídos em vários
locais em várias redes.
• Arquitetura de fluxo de dados
É utilizada quando é necessária a visualização das entradas e
saídas de dados de um sistema ou entre seus componentes. Nesse
caso, utiliza-se um padrão denominado tubos-e-filtro, no qual os
componentes do sistema representam filtros de dados, e o fluxo de
dados entre um componente e outro é denominado tubo. A Figura 4
ilustra essa modalidade de arquitetura.
Figura 4 – Arquitetura de fluxo de dados
Tubos
Filtro Filtro
Filtro Filtro Filtro Filtro
Filtro Filtro
Filtro
Filtro
Tubos e filtros
Fonte: Pressman; Maxim, 2016, p. 260.
Conforme é possível observar na Figura 4, os dados são inseridos

no sistema, passando por um fluxo de transformação formado por
filtros, nos quais os dados são tratados e transformados até que, ao
final, gerem saídas de interesse para quem os inseriu.
• Arquitetura de programa principal e subprograma
Estabelece uma hierarquia em que um programa principal
administra componentes controladores, que por sua vez administram
aplicações. De acordo com Pressman e Maxim (2016), esse tipo

de arquitetura permite uma fácil atualização do sistema como um
todo e dos seus componentes, bem como uma fácil ampliação desse
sistema. A Figura 5 ilustra essa modalidade de arquitetura.
Figura 5 – Arquitetura de programa principal e subprograma
Programa principal
Subprograma Subprograma Subprograma

controlador controlador controlador
Subprograma Subprograma Subprograma Subprograma Subprograma

de aplicação de aplicação de aplicação de aplicação de aplicação
Subprograma Subprograma
de aplicação de aplicação
Fonte: Pressman; Maxim, 2016, p. 260.
A Figura 5 ilustra um sistema composto de um programa

principal, o qual forma um sistema composto de três subprogramas
controladores que executam funções por meio de subprogramas de
aplicação subordinados. Cada subprograma de aplicação executa
uma funcionalidade do sistema como um todo, sendo controlados
pelos subprogramas controladores.
• Arquitetura em camadas
Consiste na segmentação dos componentes de software em
diferentes camadas de operações, sendo que, quanto mais próximo
à camada central, mais próximas as informações se tornam de
um conjunto de instruções de máquina. Além disso, quanto mais
externa for a camada, mais próxima ela se aproxima da interface do
usuário, que é a parte do sistema que interage com a pessoa que o
utiliza. A Figura 6 ilustra um exemplo de camada.
Figura 6 – Arquitetura em camadas
Componentes
Camada da interface
do usuário
Camada de aplicação
Camada de utilitários
Camada
central
Um exemplo de aplicação desse tipo de arquitetura é o padrão

MVC (Model-View-Controller), utilizado na arquitetura de sistemas
para dispositivos móveis. Esse padrão, conforme Sommerville
(2011), segmenta os elementos de um sistema de modo que sejam
independentes entre si. O componente view (visão) define como os
dados serão apresentados por meio de uma interface ao usuário; o
componente controller (controle) gerencia a interação do usuário
com a interface, esta realizada por meio de botões, cliques de mouse,
teclas, toques na tela, entre outras formas. Por fim, o componente
model (modelo) gerencia o sistema e suas operações, sendo a
camada mais central do modelo.
As arquiteturas de software descritas representam formas de
organizar e efetuar a gestão de projetos de software. Por meio das
arquiteturas de software, é possível inserir e relacionar as diferentes
partes que compõem um sistema, bem como visualizar o sistema
como um todo. Assim, é possível definir, de modo claro, o escopo de
um sistema e o esforço necessário para desenvolvê-lo, em termos de
tempo e custo. Em suma, definir a arquitetura de um sistema é parte
essencial da gestão de um projeto de software.
Neste capítulo, identificamos os principais elementos a serem
considerados no projeto de um software. Observamos, também,
que desenvolver um software requer conhecer as necessidades das
partes interessadas do projeto, como podem contribuir para o seu
desenvolvimento e os requisitos que elas estabelecem para o sistema
que será desenvolvido. Dentre as partes interessadas mais relevantes
para o projeto, encontram-se os clientes e fornecedores.
Além disso, requer conhecer aspectos técnicos, como o
desenvolvimento de arquiteturas. Esse conhecimento é importante
para que o projeto, além de gerido de maneira adequada, proporcione
resultados técnicos viáveis.
Como você pode observar, o projeto de um software deve
considerar aspectos técnicos, humanos e de gestão. Nenhum
desses aspectos deverá ser ignorado no desenvolvimento do
software, sob o risco de problemas durante a execução do projeto e,
consequentemente, aumento de custos ou atrasos no cronograma.
O projeto de um software é uma atividade de inovação, pois
recursos humanos, materiais, financeiros e tecnológicos são
transformados, dia após dia, em novas maneiras de se resolver
problemas e automatizar processos de negócio, isto é, software.

• PMI – PROJECT MANAGEMENT INSTITUTE. Um guia
do conhecimento em gerenciamento de projetos: guia PMBOK.
São Paulo: Saraiva, 2014.
Esse guia é uma das principais referências em gestão de
projetos na atualidade, sendo uma das mais aplicadas,
atualmente, para o gerenciamento de projetos de software,
principalmente em grande escala.
• ARTIA, 2019. Gerencie projetos, tarefas e equipes com o

Artia. Página inicial. Disponível em: www.artia.com. Acesso
em: 4 nov. 2019.
Esse software on-line apresenta funcionalidades como
definição de escopo, cronograma, gestão de riscos etc., que
possibilitam o gerenciamento de projetos.
Atividades
1. Imagine que você fará um jantar para os seus amigos. Para
isso, elabore uma EAP (Estrutura Analítica do Projeto)
contemplando as entregas a serem realizadas por você nesse
jantar (como saladas, pratos quentes, mesa arrumada), e as
subentregas (ingredientes, por exemplo).
2. Uma das arquiteturas mais utilizadas na indústria de software

atualmente é a MVC (Model-View-Controller). Pesquise e
registre as principais aplicações da MVC.
3. Desenvolver software é uma atividade que apresenta riscos,

tanto para o cliente quanto para o desenvolvedor. Pesquise e
descreva quais são esses riscos.
Referências
PMI – PROJECT MANAGEMENT INSTITUTE. Um guia do conhecimento

em gerenciamento de projetos: guia PMBOK. São Paulo: Saraiva, 2014.

SOMMERVILLE, I. Engenharia de software. 9. ed. São Paulo: Pearson

Prentice Hall, 2011.
6
Gestão da qualidade em engenharia
de software
Antes de comprar um produto ou serviço, você provavelmente

analisa muitas características. Em uma feira, no momento em que está
escolhendo frutas e verduras, por exemplo, você normalmente verifica
o tamanho delas e se estão maduras e frescas para serem consumidas.
Já ao adquirir um bem mais caro, como um automóvel, a exigência
é ainda maior. Você compara marcas, modelos, características e
potência do motor, verifica se o motor está em bom estado, se os
pneus não estão “carecas”, se o interior do veículo lhe agrada, enfim,
busca elementos de qualidade que justifiquem a compra desse
veículo em relação a outros.
Esse processo é bastante semelhante ao de aquisição de um
software ou sistema. Ele precisa cumprir os requisitos definidos,
estando adequado às necessidades de quem vai utilizá-lo, em
conformidade com o propósito para o qual foi planejado e compatível
com o hardware onde será instalado.
Desse modo, sendo responsável pelo projeto e implementação
de determinado software, o desenvolvedor também tem como
responsabilidade adotar ações que garantam a qualidade desse
produto.
Para compreendermos essas ações, vamos estudar, neste capítulo,
a gestão de qualidade em engenharia de software, abordando as
principais normas de qualidade e as ações e técnicas necessárias
para a garantia e o controle de qualidade em softwares.
Vídeo 6.1 Normas de qualidade

As atividades de desenvolvimento de
software, geralmente,envolvem projetos de
elevada complexidade e riscos e demandam
profissionais de diferentes áreas do conhecimento
para desenvolver um produto que, mesmo após
a implantação, estará sujeito a falhas. Logo, desenvolver softwares
consiste em verificações e controles constantes por parte do
engenheiro, de modo que os requisitos definidos pelo cliente e pelas
demais partes interessadas no projeto sejam atendidos e o produto
final seja viável operacional e financeiramente.
As normas de qualidade têm como propósito fornecer os
subsídios necessários para a gestão e o controle adequados das
atividades de desenvolvimento de software, para que toda entrega
atenda aos requisitos esperados. Por meio dessas normatizações, o
trabalho do engenheiro de software e demais profissionais é norteado
e padronizado; e os recursos humanos, materiais e financeiros do
projeto podem ser aproveitados da melhor forma possível.
A norma mais básica de gestão da qualidade para softwares ou
demais produtos e serviços é a NBR ISO 9000:2015, a qual estabelece
que a qualidade consiste em um conjunto de características que
satisfaçam os requisitos (ABNT, 2015a). Dessa forma, a qualidade
está relacionada à adequação de algo (produto ou serviço, por
exemplo) a um propósito. Assim, um software, por exemplo, deve
ser adequado ao usuário, ou seja, atender aos requisitos funcionais e
não funcionais para o qual foi desenvolvido.
Já a norma NBR ISO 9001:2015 (ABNT, 2015b) é a versão mais
atual da série ISO 9000 e contempla, ao todo, 10 capítulos. Nos
Gestão da qualidade em engenharia de software 105
capítulos de 4 a 10, abordados a seguir, descrevem-se princípios para

a aplicação da norma nas organizações, inclusive as que atuam com
o desenvolvimento de softwares.
• Contexto da organização (Capítulo 4)
Este capítulo trata das necessidades e expectativas das partes
interessadas e do escopo do sistema de gestão, ou seja, define o que
a organização entrega de produtos e serviços às partes interessadas.
Sendo assim, uma organização que atua com o desenvolvimento
de software, por exemplo, deve entender as expectativas e
necessidades dos usuários – traduzidas em requisitos funcionais
e não funcionais – além de monitorar e avaliar criticamente toda
informação das partes interessadas relacionada a esses requisitos, de
modo a atendê-los da maneira adequada.
• Liderança (Capítulo 5)
Este capítulo trata do papel da alta direção e das lideranças
na promoção do sistema de gestão da qualidade, sobre o
desenvolvimento de uma política de qualidade e de papéis,
responsabilidades e autoridades organizacionais. Assim, cabe às
lideranças de uma organização ou projeto (incluindo engenheiros
de software) a promoção de políticas e práticas de gestão efetiva
da qualidade, de modo que as equipes de trabalho tenham suas
necessidades atendidas e se comprometam aos trabalhos com o foco
em atender às necessidades do cliente.
É, também, responsabilidade da alta direção comunicar as
funções e autoridades aos colaboradores, visto que, em uma equipe
de desenvolvimento de software, por exemplo, cada pessoa deve
saber o papel a desempenhar em cada etapa ou atividade, bem como
ter a consciência do impacto dos resultados do seu trabalho nos
resultados dos demais colegas de equipe.
• Planejamento (Capítulo 6)
Este capítulo aborda a necessidade de planejamento
organizacional para administrar os riscos e as oportunidades
inerentes à atividade que a organização desempenha, bem como
os objetivos da qualidade e as mudanças a serem realizadas na
organização.
Assim, uma equipe de desenvolvimento de software, por exemplo,
deve adotar ações para minimizar riscos, como o de mudanças de
requisitos, incompatibilidade do software desenvolvido com os
demais sistemas da organização-cliente, dentre outros.
Além disso, a organização deve definir objetivos de gestão a
serem alcançados, que devem ser coerentes e mensuráveis para a
conformidade de produtos e serviços, como o desenvolvimento de
software. Esses objetivos devem ser monitorados, para identificação
de seu cumprimento, comunicados aos clientes e atualizados sempre
que necessário.
• Apoio (Capítulo 7)
Este capítulo aborda a gestão de recursos materiais e humanos,
bem como a infraestrutura necessária para a execução das atividades.
Além disso, trata do ambiente operacional, que deve ser adequado
social, psicologica e fisicamente.
Desse modo, uma empresa de desenvolvimento de software, por
exemplo, deve proporcionar aos profissionais um ambiente calmo,
que evite o estresse e tenha a temperatura climática adequada, uma
vez que a atividade desenvolvida demanda concentração.
Esse capítulo ainda aborda a gestão do conhecimento
organizacional, sendo que a organização precisa determinar o
conjunto de conhecimentos necessários para que a operação dos
seus processos esteja em conformidade, além de adotar medidas
para as comunicações interna e externa.
Por fim, é evidente a necessidade da documentação e do

controle das informações organizacionais e relativas ao estágio
de desenvolvimento do software, ao cumprimento de requisitos
funcionais e não funcionais, dentre outros, como distribuição,
acesso, recuperação, uso, armazenamento, preservação, alterações,
retenção e disposição.
• Operação (Capítulo 8)
Este capítulo aborda as ações que viabilizam a atividade
operacional nas organizações, bem como o planejamento e controle
operacional e os controles de processos. Quanto aos produtos
e serviços, trata da definição de seus requisitos, do projeto e do
desenvolvimento deles, daqueles fornecidos por uma entidade
externa, da atividade produtiva e da liberação deles ao cliente.
Uma organização de desenvolvimento de software, por
exemplo, deve estabelecer critérios para a realização da sua
atividade produtiva e para a aceitação do produto desenvolvido.
Dessa forma, essa companhia deve especificar para cada atividade
de desenvolvimento, os requisitos declarados (especificados pelo
cliente), não declarados (não especificados, mas necessários para as
atividades de desenvolvimento), regulamentares (requisitos legais,
por exemplo) e contratuais.
Ainda, é necessário definir as entradas e saídas para os projetos
de software – as entradas consistem nos requisitos definidos, e
as saídas se referem aos produtos desenvolvidos. Esses produtos
deverão ser devidamente controlados por meio de atividades de
análise crítica, verificação, validação ou de quaisquer mudanças que
ocorram durante o desenvolvimento do projeto.
• Avaliação de desempenho (Capítulo 9)
Este capítulo trata dos instrumentos de avaliação do desempenho
dos serviços de uma organização, que pode ser por meio da satisfação
do cliente, da auditoria interna e da análise crítica pela direção.
Uma organização de desenvolvimento de software deve

adotar formas de medir a satisfação do cliente, como a realização
de pesquisas de satisfação em diferentes etapas do projeto,
questionários, entrevistas, dentre outros. Outra ferramenta de
avaliação de desempenho é a auditoria interna, por meio da qual,
periodicamente, colaboradores da organização avaliam uns aos
outros para verificar se as atividades estão de acordo com os padrões
da organização e com a NBR ISO 9001:2015 (ABNT, 2015b).
Além disso, a alta direção deve avaliar, periodicamente e de
modo crítico, o desempenho do sistema de gestão por meio da
análise crítica, verificando o alinhamento, a adequação, a suficiência
e a eficácia do sistema de qualidade aos princípios estratégicos
da organização. Nesse caso, as lideranças devem se reunir, em
intervalos planejados, para verificar se os processos se encontram
em conformidade com os requisitos definidos.
• Melhoria (Capítulo 10)
Este capítulo enfatiza que a organização deve adotar ações
para a promoção da melhoria contínua dos seus processos,
corrigindo, prevenindo ou reduzindo quaisquer efeitos indesejados.
Assim, devem ser detectadas as não conformidades e suas causas
estabelecidas para que ações corretivas sejam adotadas com a
máxima presteza e rapidez, impedindo, também, que essas situações
ocorram novamente.
Ao compreender a aplicação dos princípios da NBR ISO 9001:2015
(ABNT, 2015b), podemos observar que essa norma é essencial para
que uma organização que atue com o desenvolvimento de software
garanta a qualidade dos seus produtos e serviços. Desse modo ao
considerar aspectos como liderança, planejamento e melhoria, uma
organização desenvolve um ambiente saudável e propício para a
inovação e o desenvolvimento tecnológico.
Vídeo 6.2 Qualidade em software

Um sistema é composto de uma série de
produtos e serviços de software e hardware, que
necessitam ser executados ou ligados em perfeita
sincronia para que seu funcionamento esteja de
acordo com os requisitos esperados.
Devido à complexidade de muitos sistemas, existe a possibilidade
de ocorrerem falhas ou operações indesejadas, prejudicando o
desempenho do sistema como um todo e impactando negativamente
na organização-cliente do sistema. Assim, é necessário que a
qualidade seja adequadamente planejada, gerenciada e controlada,
de modo que, no projeto do software, os requisitos sejam plenamente
atendidos e o produto ou serviço final entregues estejam adequados
às necessidades da organização-cliente.
Os principais aspectos de qualidade a serem considerados no
desenvolvimento de um software estão descritos a seguir.
6.2.1. Fatores de qualidade em um produto de

software
Pensar na qualidade em desenvolvimento de software, ou na
qualidade do software como um produto, é pensar em gestão ou
em como efetuar o melhor aproveitamento dos recursos humanos,
materiais e financeiros para que o software entregue ao cliente
(produto final) atenda aos requisitos previamente definidos. Dessa
forma, a gestão da qualidade envolve o planejamento e o controle

de pessoas e processos, de modo que o software final seja definido
como um produto de qualidade.
McCall, Richards e Walters (1977 apud PRESSMAN; MAXIM,
2016) definem uma série de fatores que devem ser considerados
para a avaliação da qualidade em um produto de software. A Figura
1 ilustra este processo, que se divide em três grupos: revisão do
produto; transição do produto; e operação do produto.
Figura 1 – Fatores de qualidade de software

• Facilidade de manutenção • Portabilidade
• Flexibilidade • Reusabilidade
• Testabilidade • Interoperabilidade
REVISÃO DO TRANSIÇÃO
PRODUTO DO PRODUTO
OPERAÇÃO
DO PRODUTO
Correção Usabilidade Eficiência

Confiabilidade Integridade
Conforme se observa na Figura 1, o grupo revisão do produto,

como o nome sugere, abrange a revisão contínua do software, seja
na etapa de desenvolvimento ou após o software ser entregue. Nesse
grupo destacam-se três fatores:
• Facilidade de manutenção: quantidade de recursos e esforços
necessários para encontrar e corrigir erros.
• Flexibilidade: recursos e esforços necessários para modificar
um software em desenvolvimento ou acabado.
• Testabilidade: esforços necessários para a realização de testes,
verificando se o software atende às necessidades e aos requisitos.
Já o grupo transição do produto diz respeito a aspectos
transitórios do software, ou seja, de instalação ou transferência de
uma máquina a outra e de integração entre o software e outros.

Nesse grupo destacam-se três fatores:
• Portabilidade: recursos necessários para a transferência de
um software de um hardware a outro.
• Reusabilidade: o quanto um software (ou partes do código) pode
ser reaproveitado para o desenvolvimento de outros sistemas.
• Interoperabilidade: capacidade de integração do software com
outros softwares e hardwares, formando um sistema integrado.
Por fim, o grupo operação de produto trata de aspectos de
funcionalidade e desempenho do software em um ambiente
operacional. Nesse grupo destacam-se cinco fatores:
• Correção: o quanto um software é correto, ou seja, o quanto
atende às especificações e requisitos definidos.
• Confiabilidade: o quão preciso é o software para o
cumprimento de suas funções, sem a ocorrência de erros ou
falhas.
• Eficiência: quantidade de recursos computacionais (memória
RAM, uso de processador e espaço em HD, por exemplo)
necessários para a execução.
• Integridade: segurança do software, ou seja, a prevenção ao
acesso por parte de pessoas não autorizadas.
• Usabilidade: esforços necessários para aprender a utilizar o
software corretamente.
A qualidade, porém, não pode se restringir ao software
enquanto produto. O processo de desenvolvimento também deve
ser considerado, uma vez que impacta significativamente nos custos
do software e nos resultados obtidos (produto final).
Sendo assim, os fatores de qualidade mencionados nesta seção
permeiam todo o processo de desenvolvimento de um software,
desde a concepção, passando pela construção até a implantação. Os
elementos relativos à revisão, transição e operação são importantes
no sentido de que um usuário, ao receber um software para execução,

deverá percebê-los durante a utilização.
6.2.2. Garantia de qualidade em software

Para a garantia da qualidade, faz-se necessária, na engenharia
de software, a implementação de processos, desde o início do
desenvolvimento do código até a entrega do software ou sistema
finalizado, para que, uma vez entregue ao cliente, funcione
corretamente. Pressman e Maxim (2016) enumeram alguns destes
processos, conforme a seguir.
Primeiramente, a garantia da qualidade é obtida por meio da
padronização dos processos de desenvolvimento, que segue algumas
normas, como as definidas pelos organismos internacionais IEEE e
ISO. O ideal é que todo projeto de software seja desenvolvido com
base em processos padronizados, possibilitando melhor controle em
todas as etapas de desenvolvimento.
Recomenda-se que a padronização dos processos de
desenvolvimento seja implementada em conjunto com ações
de educação dos gestores e colaboradores da equipe de
desenvolvimento, de modo que estejam devidamente preparados
para seguir os padrões e realizar as ações necessárias para a garantia
da qualidade.
Juntamente à padronização e educação dos processos, são
necessárias ações de gerenciamento de fornecedores para que os
produtos e serviços prontos fornecidos tenham, assim como os
desenvolvidos pela equipe de projeto, a qualidade verificada e
validada para o cumprimento dos requisitos necessários do software
que está sendo desenvolvido.
Além disso, no processo de desenvolvimento de software, é
importante a realização periódica de revisões de código em busca
de erros. Essas revisões devem ser realizadas em todos os estágios
de desenvolvimento do software, visto que, quanto mais cedo são
detectados os erros, maiores são as chances de serem corrigidos e

menores são os custos para essa correção.
Outra ferramenta relevante para a garantia de qualidade
consiste na realização de auditorias periódicas no projeto,
que podem ser feitas por membros da própria equipe de
desenvolvimento ou por pessoas externas. As auditorias têm
o intuito de verificar se os princípios e as normas de qualidade
estão sendo adequadamente adotados no projeto, bem como se a
execução do projeto está conforme os requisitos do cliente.
Em conjunto à execução de revisões e auditorias, a realização
de testes permite a detecção de não conformidades nos processos
de desenvolvimento, bem como a detecção de erros no projeto.
Esses testes devem ser antecipadamente planejados e conduzidos
para abranger as funcionalidades necessárias do software em
desenvolvimento, de maneira que os resultados possam ser
aproveitados para a condução de melhorias.
A execução de revisões, auditorias e testes possibilita a
evidenciação de erros ou defeitos, que devem ser coletados,
analisados, catalogados, agrupados e expostos em forma de
indicadores, para se verificar suas principais causas e realizar
ações corretivas para sua redução ou eliminação. A necessidade
de mudanças de requisitos durante o desenvolvimento, a
codificação ou outra atividade também aumenta as possibilidades
de surgirem erros, defeitos ou não conformidades no projeto de
software. Assim, tornam-se necessárias ações de gerenciamento de
mudanças, para que a equipe de desenvolvimento não se confunda
ou não consiga administrar as mudanças e suas consequências no
decorrer do projeto.
Além de erros e defeitos no projeto, outra questão a se considerar
é a segurança dos dados que estão sendo processados ou que o
software, uma vez acabado, irá processar. Torna-se necessária a
realização de ações de administração da segurança para impedir
alterações não autorizadas no software, bem como garantir a

privacidade e o não vazamento de dados, principalmente, de
usuários do software.
Ainda, é necessário analisar a integridade física e mental das
pessoas que utilizarão o software. Considerando o fato de que
softwares podem ser implantados em dispositivos críticos, como
aeronaves, braços robóticos, automóveis, dentre outros. A garantia
da qualidade também contempla ações de verificação de potenciais
erros ou defeitos que possam causar danos, principalmente no caso
de softwares direcionados às indústrias altamente sensíveis, como a
automobilística e a aeronáutica. Isso pode ser feito, por exemplo, por
meio da verificação regular do código em busca de erros, ou seja,
pela realização de testes periódicos nesse código.
Por fim, mais importante do que detectar erros, torna-se
necessário preveni-los. Dessa forma, ações de gestão de riscos
devem ser adotadas para que o próprio desenvolvimento minimize
a quantidade de erros e defeitos, bem como as consequências deles
para o usuário do software.
A garantia deve acontecer durante todo o processo de
desenvolvimento de um software. A realização de revisões e
conferências periódicas aumenta a segurança do código e contribui
para a sua segurança e adequação aos requisitos funcionais e não
funcionais. A qualidade, assim, não deve ser somente planejada, mas
executada a todo instante.
Vídeo
6.3 Melhorias em software
Um dos principais motivos para a adoção de
práticas de gestão da qualidade nas organizações,
incluindo as de desenvolvimento de software,
é a realização de melhorias contínuas nos processos dessas
organizações.
Em um mercado altamente concorrido, cada vez mais exigente

em termos de qualidade e requisitos e com custos progressivamente
elevados para a aquisição de recursos, as organizações devem
adotar políticas de aprimoramento contínuo de processos, recursos
humanos e infraestrutura. Essas melhorias não necessitam ser
radicais, mas devem ser, sempre que possível, gradativas.
Sommerville (2011, p. 493), considerando que “a melhoria de
processos implica a compreensão dos processos existentes e sua
mudança para aumentar a qualidade de produtos e/ou reduzir
custos e o tempo de desenvolvimento”, sugere duas abordagens para
ela: a abordagem de maturidade de processo e a abordagem ágil.
A abordagem de maturidade de processo “se centra em
melhorar o gerenciamento de processos e projetos e em introduzir
boas práticas de engenharia de software em uma organização”
(SOMMERVILLE, 2011, p. 493). Desse modo, como o próprio nome
sugere, nessa abordagem, o foco consiste no desenvolvimento de
processos maduros, estruturados e previsíveis, de modo a garantir
maior segurança no desenvolvimento de software, bem como na
realização de mudanças e melhorias.
Já a abordagem ágil “se centra no desenvolvimento iterativo
e na redução de overheads gerais no processo de software”
(SOMMERVILLE, 2011, p. 493, grifo do original). Dessa forma,
diferentemente da abordagem anterior, o foco consiste na realização
de entregas rápidas de funcionalidades, ou seja, as mudanças
e melhorias nos processos de desenvolvimento são efetuadas
rapidamente de acordo com as mudanças de requisitos fornecidas
pelo cliente.
Ambas as abordagens são válidas para o processo de melhoria de
software e devem ser adotadas conforme a natureza do projeto, do
método de desenvolvimento adotado (tradicional ou ágil), dentre
outros fatores.
6.3.1. Roteiro para a melhoria dos processos de

desenvolvimento de software
Para que a qualidade do produto ou serviço final seja assegurada
e esteja sempre de acordo com as necessidades do cliente, as
organizações devem constantemente repensar seus processos de
desenvolvimento de software. Assim, a melhoria desses processos
tem caráter de continuidade, ou, segundo Sommerville (2011),
segue um modelo cíclico, conforme a Figura 2 a seguir.
Figura 2 – Ciclo de melhorias de processos
MEDIR
MUDAR ANALISAR
Fonte: Sommerville, 2011, p. 497.
Com base na Figura 2, a organização deve, primeiramente,

medir o seu processo atual e a qualidade dos produtos e serviços
desenvolvidos. Em seguida, deve analisar o processo atual e verificar a
existência de pontos fracos. Uma vez detectados os gargalos ou pontos
fracos, deve implantar mudanças para a solução desses problemas e,
então, o ciclo se reinicia.
Para a realização de melhorias nos processos de desenvolvimento
de software, de modo concordante ao exposto por Sommerville (2011),
Pressman e Maxim (2016) sugerem um roteiro (sequência de atividades)
composto de cinco atividades, ou etapas, destacadas a seguir.
A primeira atividade consiste na avaliação e análise de lacunas,

nas quais levantam-se os pontos fortes e fracos do processo atual de
desenvolvimento de software utilizado. Verificam-se se os processos
de desenvolvimento têm objetivos claramente definidos, se os
critérios de entrada e saída foram adequadamente definidos, se há
métricas estabelecidas para a atividade e se o processo é executado
de maneira uniforme para todos os projetos de software. Além disso,
avalia-se se o processo de software é aceito pela alta direção e pela
equipe técnica e se a alta direção fornece os subsídios e o apoio
necessários para que o processo seja executado adequadamente.
Por sua vez, a segunda atividade diz respeito à realização de
ações de educação e treinamento. Antes de se realizar mudanças
no processo de desenvolvimento de software, recomenda-se
que os colaboradores envolvidos sejam conscientizados sobre a
necessidade de um processo eficaz e organizado. Assim, Pressman
e Maxim (2016, p. 825) recomendam três tipos de educação e
treinamento: “conceitos e métodos genéricos de engenharia de
software, tecnologia e ferramentas específicas e comunicação e
tópicos relacionados à qualidade”. Os treinamentos propostos pelos
autores tratam de conceitos teóricos necessários para a realização
de melhorias no desenvolvimento de software, além de abordar
assuntos que sejam de interesse da equipe e que possam auxiliá-los a
passar pela mudança de processo de desenvolvimento.
Em seguida, a terceira atividade aborda a seleção e justificação.
Com base na avaliação e análise de lacunas, deve-se optar por
manter o processo atual de desenvolvimento de software ou adotar
um que se torne mais adequado para a equipe de desenvolvimento.
Por exemplo, pode-se migrar do método de desenvolvimento
tradicional em cascata para um modelo ágil de desenvolvimento.
Já a quarta atividade se refere à instalação e migração, etapa
na qual a organização desenvolve um processo inteiramente novo
ou implanta a mudança de processo selecionada na etapa anterior.

Sugere-se, em ambos os casos, a consideração de três modelos:
o processo existente (‘da forma como está’), o processo
de transição (‘daqui para lá’) e o processo-alvo (‘o novo’).
Se o processo-alvo for significativamente diferente do
existente, a única abordagem racional para a instalação é
uma estratégia incremental na qual o processo de transição
é implementado em etapas. (PRESSMAN; MAXIM, 2016,
p. 826)
Por fim, a quinta atividade trata da mensuração, que deve ser

realizada durante todas as etapas de desenvolvimento, por meio de
fatores qualitativos e indicadores quantitativos, para verificar se o
processo de mudança atende às necessidades da organização. Nessa
etapa, compara-se o processo recém-implantado com o que era
utilizado pela organização, analisando se as melhorias aconteceram
durante a implantação do novo processo.
6.3.2. Atributos de processo de software para a

melhoria contínua
A melhoria de um processo de desenvolvimento de software
pode demandar tempo e custos significativos para a organização,
uma vez que envolve o trabalho de vários profissionais e a aquisição
de novos recursos. Dessa forma, recomenda-se que a avaliação
do processo atual e do processo a ser implantado seja realizada
conforme critérios ou atributos racionais.
Sobre a melhoria em processos de desenvolvimento,
Sommerville (2011) enumera alguns atributos de processo que
devem ser considerados, conforme descrito a seguir.
• Compreensibilidade: verifica-se o quanto o processo é
definido de modo explícito, bem como sua compreensão por
parte da equipe de desenvolvimento.
• Padronização: observa-se o quanto o processo se assemelha
a um processo genérico padrão e se esse mesmo processo é
utilizado em todas as equipes de desenvolvimento.
• Visibilidade: avalia-se se as atividades do processo resultam

em produtos e serviços claramente definidos e se, quando o
processo é aplicado, seu progresso é claramente percebido.
• Capacidade de medição: analisa-se se existe a coleta de dados
necessária para a estruturação de indicadores quantitativos
para a avaliação eficaz do desempenho do processo.
• Capacidade de apoio: confere-se se as ferramentas de
software, atualmente usadas, são capazes de apoiar as
atividades desempenhadas pelo processo.
• Aceitabilidade: comprova-se se o processo é aceito pelas
equipes de desenvolvimento, sendo plenamente utilizado
pelos engenheiros de software.
• Confiabilidade: constata-se se o processo é projetado de
modo que erros sejam evitados, visto que, se ignorados,
podem ser transmitidos para o produto final, prejudicando
a sua qualidade.
• Robustez: examina-se se o processo resiste a incidentes ou
problemas, mantendo a sua continuidade.
• Manutenibilidade: confirma-se a capacidade de evolução
do processo para reagir a mudanças nas necessidades da
organização ou dos clientes.
• Rapidez: investiga-se a rapidez do processo na realização de
entregas de software, ou seja, a sua conclusão após a entrega
de uma determinada especificação de software.
Desse modo, recomenda-se a reflexão sobre esses atributos sempre
que um processo é executado, tendo-se em vista que as necessidades
da organização e do mercado estão em constante mutação.
Como você pôde perceber, desenvolver um software de qualidade
não é uma tarefa fácil, visto que, além da preocupação com o próprio
software e seu código, o desenvolvedor deve considerar as pessoas,

os fornecedores, os processos e os recursos utilizados.
A garantia da qualidade depende, principalmente, de mecanismos de
verificação, para assegurar que o software atenda aos requisitos definidos
pelo cliente. Dessa forma, pode-se afirmar que a qualidade de um
software depende, primeiramente, da precisão e coerência na definição
de requisitos, visto que requisitos desnecessariamente definidos, ou
definidos de modo vago e impreciso, podem impactar negativamente o
processo de desenvolvimento do software como um todo.
Além disso, sendo um processo, a gestão da qualidade dele deve
ser planejada com igual precisão, pois definir padrões, normas,
mecanismos de verificação, dentre outros, é essencial para que
todos, em uma mesma equipe de desenvolvimento, tenham o
mesmo entendimento sobre o que é necessário garantir, em termos
de entregas de software ao cliente e ao usuário.

• KOSCIANSKI, A.; SOARES, M. S. Qualidade de software. São
Paulo: Novatec, 2006.
Esse livro aborda várias questões relacionadas à garantia e
à melhoria de processos de qualidade, como as normas ISO
(9000, 12207 e 25000), os fatores humanos, os requisitos de
qualidade, a qualidade de código, dentre outras.
• SANTOS, L. D. V.; OLIVEIRA, C. V. S. Introdução à garantia

de qualidade de software. Timburi: Cia do e-book, 2017.
Esse e-book trata das principais questões relacionadas à
garantia da qualidade em software, como projetos de melhoria
da qualidade, revisões de software e ferramentas de qualidade
em software.
Atividades
1. Uma das normas que norteiam o trabalho do engenheiro de
software é a ISO/IEC 12207. Pesquise e descreva os principais
processos dessa norma.
2. Imagine que você desenvolverá um software para automação

de braços robóticos para uma fábrica. Descreva quais fatores
de qualidade você considera essenciais para esse software.
3. Quais aspectos de garantia de qualidade você julga

importantes para o desenvolvimento do software da questão
anterior? Descreva-os.
Referências
ABNT – Associação Brasileira de Normas Técnicas. NBR ISO 9000: Sistema
de Gestão da Qualidade – fundamentos e vocabulário. Rio de Janeiro:
ABNT, 2015a.
ABNT – Associação Brasileira de Normas Técnicas. NBR ISO 9001: Sistema

de Gestão da Qualidade – Requisitos. Rio de Janeiro, 2015b.

SOMMERVILLE, I. Engenharia de software. 9. ed. São Paulo: Pearson, 2011.

7
Testes e engenharia reversa em
software
A conclusão do desenvolvimento de um software não é a última

etapa desse processo. Um software, ou um de seus componentes,
necessita passar por avaliação quando terminado, na qual é
observado se os requisitos funcionais e não funcionais são atendidos,
se as funcionalidades implantadas desempenham adequadamente
suas tarefas, se as configurações do software em determinado
computador ou servidor estão corretas, dentre outras verificações.
Desse modo, um software, como qualquer produto, necessita
passar por testes em todo o processo de desenvolvimento, e não
apenas quando está “finalizado”, ou seja, deve ser testado desde o
projeto, passando pela modelagem, até a construção e entrega ao
cliente. Esses testes são importantes para que possíveis falhas sejam
detectadas e corrigidas imediatamente, economizando-se, assim,
esforços da equipe de desenvolvimento e recursos financeiros do
patrocinador do software.
Outro tema a ser considerado é a engenharia reversa, ou
reengenharia, a qual consiste na elaboração de um projeto de
software a partir de um código existente e que é especialmente útil
quando é necessário desenvolver um sistema novo a partir de um
código legado (antigo), desatualizado e sem suporte técnico, como
ocorre em muitos sistemas empresariais.
Dessa forma, este capítulo busca abordar os principais testes,
métodos e metodologias utilizados para a engenharia reversa de
software. De modo que, primeiramente, serão abordados os
principais defeitos que podem ocorrer no desenvolvimento de um
produto dessa natureza. Depois, serão destacados os principais testes

a serem adotados na correção desses defeitos, impedindo que eles
impactem significativamente no processo de desenvolvimento do
software. Também, serão descritas metodologias para a execução de
testes, de modo a otimizar o uso de recursos e esforços por parte da
equipe de desenvolvimento. Por fim, serão apresentados os conceitos
de engenharia reversa e reengenharia de software, bem como um
modelo para a realização dessas técnicas.
Vídeo 7.1 Modalidades de testes em

software
A realização de testes em software, seja para
demonstrar que o produto está funcionando de
acordo com os requisitos ou seja para a descoberta
de falhas que impedem seu funcionamento, é um
processo que não pode ser ignorado pela equipe de desenvolvimento.
Quanto mais testes forem realizados, maior será a certeza de que um
software e seus componentes estão funcionando adequadamente e,
consequentemente, maior será a qualidade assegurada ao produto.
Quando efetuado de modo adequado, um teste pode expor
vários tipos de defeitos que, ao serem prontamente corrigidos,
provavelmente, resultarão em economia de esforços e recursos
financeiros. Pfleeger (2004) enumera algumas ocorrências de
defeitos possíveis em um sistema: algoritmo, computação e precisão,
documentação, capacidade e defeitos de recuperação.
Os defeitos mais comuns no desenvolvimento de um software
são os de algoritmo, que ocorrem quando a lógica de um código
criado resulta em uma saída indesejada ao testá-lo. Esse defeito
ocorre, por exemplo, quando a sintaxe de um código está incorreta
Testes e engenharia reversa em software 125
ou quando há comparação de variáveis de tipos não compatíveis,

como uma do tipo string e uma do tipo inteira1.
Outro tipo de defeito é o de computação e precisão, que
pode acontecer, por exemplo, quando o computador não calcula
determinada fórmula com o grau de precisão requerido pelo software,
resultando em saídas imprecisas. Em sistemas de instrumentação ou
automação de processos, esse tipo de defeito requer muita atenção, uma
vez que a precisão dos cálculos matemáticos é essencial para que, por
exemplo, um braço robótico se mova para certa direção e desempenhe
uma tarefa delicada, como a montagem de um componente.
Ainda, pode haver defeitos quando a documentação
elaborada para o software não corresponde ao que o produto
de fato desempenha. Isso pode ocorrer, por exemplo, quando
as atualizações sucessivas do software não são repassadas ao
documento. Essa incompatibilidade na documentação pode trazer
desconfiança em relação ao funcionamento de componentes
que precisam ser atualizados, prejudicando esse processo e o de
desenvolvimento do software. Quando um documento de software
está desatualizado, há risco de os desenvolvedores se confundirem
em relação a quais componentes ou funcionalidades devem ser
alterados, desenvolvidos ou retirados. Além disso, considerando
que a atualização de componentes ou funcionalidades impacta no
desempenho do software como um todo (afinal, o componente
faz parte de um sistema integrado), é importante que qualquer
alteração seja documentada e uma versão atual do documento do
software seja elaborada.
Já quando o software não atende à capacidade de processamento
à qual deveria, ocorrem os defeitos por capacidade, como quando
um sistema projetado para gerenciar uma quantidade específica
de dispositivos de hardware não consegue processar dados para a
1 A variável do tipo string armazena combinações sequenciais de caracteres. Já a

variável do tipo inteira, como o nome sugere, armazena números inteiros.
demanda em questão, resultando em sobrecargas, ou nos casos em

que há incapacidade de um sistema de comércio eletrônico gerenciar
determinada quantidade de acessos e compras simultâneos, sem que
haja travamentos.
Há, também, possibilidade de ocorrem falhas em um software,
denominadas defeitos de recuperação. Quando ocorre falha
no funcionamento de um software, como quando um sistema
operacional “trava”, a tendência é que seu pleno funcionamento
seja recuperado ao ser reativado, o que não acontece com sistemas
que apresentam defeitos de recuperação. Desse modo, quando
ocorrem falhas, devem ser adotados processos para recuperação e
plena utilização do software, que devem contar com a restauração
de arquivos e processos de um estágio imediatamente anterior à
ocorrência da falha. Além disso, sempre que possível, o software
deve registrar as ocorrências de falhas para nortear a equipe de
desenvolvimento com relação a atualizações do sistema. Já em um
sistema com defeitos, esses processos de recuperação não funcionam
adequadamente no momento de uma falha, o que pode prejudicar o
funcionamento do sistema temporária ou permanentemente.
Todos esses defeitos podem ocorrer durante o desenvolvimento,
a entrega ou até a operacionalização do software pelo usuário. Dessa
forma, Paula Filho (2009), Pfleeger (2004) e Sommerville (2011)
sugerem, cada qual com seu ponto de vista, vários testes que podem
ser adotados para a detecção de falhas, cada um com o seu método.
Esses testes, descritos a seguir, devem ser aplicados conforme houver
necessidade, em diferentes estágios de desenvolvimento do sistema.
a) Teste de unidade
Este é um dos testes com maior nível de detalhamento durante
o desenvolvimento do software, que, segundo Sommerville (2011,
p. 148), é o “processo de testar os componentes de programa, como
métodos ou classes de objeto”, ou seja, possibilita testar cada parte
de um componente.
Desse modo, o teste de unidade “focaliza o esforço de verificação

na menor unidade de projeto do software: o componente ou
módulo de software” (PRESSMAN; MAXIM, 2016, p. 473), sendo,
portanto, recomendado sempre que um componente de software
for desenvolvido, com o objetivo de assegurar que, ao ser concluído,
todo o software esteja plenamente funcional.
b) Teste de desenvolvimento
Este teste também atua com o componente de software, mas é
aplicado durante o seu desenvolvimento ou sua codificação pela
equipe de trabalho. Desse modo, consiste em um “teste formal ou
informal realizado durante o desenvolvimento de um sistema ou
componente, geralmente pelo desenvolvedor” (PAULA FILHO,
2009, p. 352).
Similarmente ao de unidade, o teste de desenvolvimento é
recomendado durante todas as etapas de desenvolvimento de
um software ou componente, assegurando que determinado
componente, quando concluído, consequentemente passe no teste
de unidade e funcione adequadamente na conclusão do software
como um todo.
c) Teste de qualificação
Este teste, normalmente, é realizado quando o software, ou o
seu componente, acaba de ser desenvolvido, para verificar se está
de acordo com o projeto. Dessa forma, é “realizado para determinar
se um sistema ou componente é adequado para uso operacional”
(PAULA FILHO, 2009, p. 352).
Assim, esse tipo de teste possibilita verificar a funcionalidade
de um componente antes do teste operacional, o qual o coloca em
funcionamento no próprio ambiente onde será implantado. Ainda,
no teste de qualificação, verifica-se a ocorrência de problemas que
podem prejudicar a futura operacionalização desse componente.
d) Teste funcional
Este teste permite verificar as funcionalidades de um sistema
ou componente antes de ser colocado em ambiente de operação
e é realizado “para avaliar a conformidade de um sistema ou
componente com os requisitos funcionais especificados” (PAULA
FILHO, 2009, p. 352).
Assim, o foco desse tipo de teste não está na estrutura, mas no
desempenho do componente ou software, para que ele atenda aos
requisitos funcionais. Dessa forma, recomenda-se a participação
do cliente ou usuário fazendo uso das funcionalidades do sistema
enquanto os desenvolvedores observam e registram os possíveis
erros ou necessidades de melhoria. Também, se possível, recomenda-
se, na realização dos testes, a verificação da interação do sistema
testado com outros sistemas da organização ou empresa do cliente,
para que, quando o sistema for implementado, possa interagir na
troca de informações.
e) Teste operacional
Após concluído, o software deve ser testado sob condições
realistas, por meio de simulações, de modo que seus componentes
sejam colocados à prova e, assim, seja possível verificar precisamente
se esse produto é capaz de atender aos requisitos funcionais e não
funcionais definidos ou se será necessária a realização de ajustes.
Dessa forma, o teste operacional é “realizado para avaliar um
sistema ou componente em seu ambiente operacional” (PAULA
FILHO, 2009, p. 352), ou seja, avalia-se o funcionamento do software
no ambiente em que ele será implementado. Assim, recomenda-se
a participação do usuário na manipulação das funcionalidades do
software e na simulação de diferentes casos de uso, principalmente
dos que podem resultar em falhas, possibilitando a adoção de
ações corretivas no software a tempo de finalizá-lo e colocá-lo em
ambiente de uso.
f) Teste de regressão
Esse tipo de teste consiste na análise comparativa de duas versões
do software: antes e depois da realização de alterações e melhorias.
Desse modo, é possível verificar se essas mudanças realmente
resultaram em melhoria de desempenho ou em defeitos no software.
O teste de regressão é “seletivamente repetido de um sistema ou
componente para verificar se alterações não causaram efeitos
indesejáveis e se o sistema ou componente mantém a conformidade
com seus requisitos especificados” (PAULA FILHO, 2009, p. 352).
Além disso, esses testes agem sobre os efeitos colaterais de
funcionamento de um sistema, que podem acontecer quando se
modificam seus componentes. A alteração desses componentes pode
resultar em modificações no comportamento de outros componentes,
que muitas vezes já foram testados. Assim, os testes de regressão nos
componentes de um sistema “verificam novamente as unidades já
testadas, para checar se eles continuam funcionando de maneira
apropriada após as alterações” (PAULA FILHO, 2009, p. 369). Dessa
forma, após as alterações realizadas em decorrência dos testes,
recomenda-se a realização dos testes de regressão para verificar se as
melhorias efetuadas atenderam aos requisitos esperados.
A importância do teste de regressão está em reconhecer que
falhas podem aparecer conforme são desenvolvidas as diferentes
versões do software. Se a equipe desenvolvedora não efetua o
adequado acompanhamento das alterações e melhorias do software
ao longo do tempo, a tendência é de que as falhas no funcionamento
do sistema sejam mais difíceis de serem detectadas.
g) Teste de integração
Neste teste, segundo Paula Filho (2009, p. 352), “componentes
são combinados e avaliados para testar a interação entre eles”,
possibilitando verificar se essa relação resulta em sucesso ou defeitos.
O teste de integração é importante para verificar, além do

funcionamento dos componentes do sistema isoladamente,
a interação dos algoritmos ou códigos entre eles, bem como
compatibilidade, intercâmbio de dados e saídas geradas entre esses
componentes para o software como um todo. Assim, recomenda-se
esse tipo de teste sempre que forem desenvolvidos componentes
inter-relacionados, antes de entrarem em funcionamento.
h) Teste de sistema
De modo similar ao de integração, o teste de sistema envolve a
interação e a troca de informações entre componentes. No entanto,
o foco é a verificação do funcionamento do sistema como um todo,
em uma versão funcional. Assim, o teste de sistema “envolve a
integração de componentes para criação de uma versão do sistema
e, em seguida, o teste do sistema integrado” (SOMMERVILLE,
2011, p. 153). Esse teste pode ser realizado nas etapas finais de
desenvolvimento do software, uma vez que os componentes já estão
elaborados e, provavelmente, funcionais.
i) Testes de usuário
O teste de usuário é, possivelmente, um dos mais relevantes,
podendo permear os demais testes realizados para o software.
Esse teste “é um estágio no processo de teste em que os usuários
ou clientes fornecem entradas e conselhos sobre o teste de sistema”
(SOMMERVILLE, 2011, p. 159). Ou seja, coletam-se informações
de feedback do cliente com relação ao sistema, aos componentes,
ao código, às funcionalidades, às compatibilidades, dentre outros
fatores.
Os testes de usuário devem ser realizados sempre que
informações destes forem relevantes para o desenvolvimento do
software. Porém, deve-se dar atenção ao fato de que o usuário,
conforme seus conhecimentos técnicos a respeito do software

que será elaborado, nem sempre poderá auxiliar a equipe de
desenvolvimento adequadamente no processo de construção do
software. Assim, recomenda-se cautela com relação ao esse tipo de
envolvimento na realização de testes.
j) Teste de aceitação
O teste de aceitação é, possivelmente, um dos mais relevantes no
desenvolvimento de software, visto que a conclusão deste processo
depende de sua aprovação. Esse é, portanto, um “teste formal
realizado para determinar se um sistema satisfaz a seus critérios
de aceitação e capacitar um usuário, cliente, ou outra entidade
autorizada a determinar se aceita ou não o sistema” (PAULA FILHO,
2009, p. 352).
Assim, esse teste permite ao usuário verificar se o software
atende às suas necessidades, avaliando todos os aspectos de
desenvolvimento e se existe algum defeito (de algoritmo, de
computação e precisão ou de documentação). Desse modo, a
participação do usuário ou cliente é necessária para a verificação do
cumprimento dos requisitos funcionais e não funcionais, bem como
se existe alguma funcionalidade não programada que deverá ser
desenvolvida ou adicionada para futuros projetos.
Desse modo, conforme exposto nos itens anteriores, existem

diferentes modalidades de testes a serem adotadas durante o
processo de desenvolvimento de um software. Recomenda-se,
sempre que possível, que testes sejam efetuados durante todo o
processo de desenvolvimento do software, visto que, quanto mais
cedo os defeitos são detectados, maiores são as chances de sucesso

ao corrigi-los e menores são os gastos e esforços dispendidos. Ainda,
na realização desses testes sugere-se a participação do usuário ou
cliente, visto que ele é o responsável ou participará da aprovação da
versão final do software.
Vídeo
7.2 Realização de testes
Assim como o desenvolvimento de um
software, a execução de testes como ferramenta
de melhoria requer um planejamento cuidadoso.
Ao se realizar testes de maneira sistematizada e
planejada, verificam-se, além de possíveis defeitos
no software e em seus componentes, a conformidade, a usabilidade e
o atendimento a requisitos funcionais e não funcionais.
Dessa forma, a realização de testes depende da definição de um
plano, no qual se estabeleça o planejamento, o desenho, a realização
e a forma de avaliação dos resultados. Pode-se organizar os testes de
modo a abranger todas as modalidades possíveis de teste, bem como
todos os componentes do software e suas interações.
7.2.1 Transparência dos testes

A realização de testes depende, primeiramente, de um escopo
(definição de etapas), que é importante considerando a necessidade
ou não de se verificar as saídas geradas por um componente apenas
ou por todo o sistema.
A transparência consiste na abrangência e no detalhamento de
dados a determinado teste. Assim, conforme o nível de transparência
de um teste, é dado maior ou menor detalhamento em relação a
componentes e códigos. Há três modalidades de testes de acordo
com o nível de transparência: caixa branca, caixa cinza e caixa preta.
O teste de caixa branca é a modalidade mais detalhada, que
abrange o sistema e o funcionamento de todos os seus componentes
e, portanto, “leva em conta os mecanismos internos de um sistema

ou componente” (PAULA FILHO, 2009, p. 353). Nesse processo,
avaliam-se as entradas e saídas do sistema e dos componentes, além
da inter-relação entre elas.
Já o teste de caixa cinza “ignora os mecanismos internos de
um componente e focaliza apenas as saídas geradas em resposta a
entradas e condições de execução selecionadas” (PAULA FILHO,
2009, p. 353). Nesse caso, são considerados apenas a interação
dos componentes em um sistema e o funcionamento do software
como um todo, desprezando o funcionamento detalhado de um
componente. Utiliza-se essa modalidade quando há confiança de
que os componentes foram elaborados adequadamente, focando na
maneira como um software funciona.
Por fim, o teste de caixa preta “ignora os mecanismos internos
de um sistema e focaliza apenas as saídas geradas em resposta a
entradas e condições de execução selecionadas” (PAULA FILHO,
2009, p. 353). Essa é a modalidade mais superficial e é utilizada para
avaliar o cumprimento dos requisitos funcionais e não funcionais e
verificar a compatibilidade do software com outros sistemas, uma
vez que se ignora, nesse processo, a interação dos componentes
internos do sistema.
Todavia, independentemente da transparência utilizada,
é necessário definir uma estratégia adequada, conforme se
aborda a seguir, para que o teste seja realizado de maneira
adequada e proporcione os resultados esperados para a equipe de
desenvolvimento.
7.2.2 Definição de uma estratégia de testes

Essa definição considera que a realização de testes assume um
caráter cíclico, ou seja, consiste em um processo repetitivo e escalável
em que, quanto mais testes se realiza, maiores são os conhecimentos

adquiridos a respeito de um software e maior se torna o escopo desses
testes. Dessa forma, Pressman e Maxim (2016) definem a estratégia de
testes de software no formato espiral, apresentado na Figura 1, na qual
se observa que determinado teste é adotado a cada ciclo.
Figura 1 – Estratégia de testes de software
de sistema
Teste
e de validação
Test
e integra
ste d çã
Te
o
de
ste de
Te nida
u
o
dig
Có
Projeto
Requisitos
Eng as
enharia de sistem
Fonte: Pressman e Maxim 2016, p. 470.
De acordo com a Figura 1, conforme a evolução do

desenvolvimento de um software, uma modalidade de testes se torna
mais necessária em relação a outras. Desse modo, o teste de unidade
é utilizado na etapa mais básica de desenvolvimento – a codificação.
Uma vez desenvolvidos os códigos e formatados em componentes,
o teste de integração assume maior importância, visto que é possível
analisar os componentes funcionando de maneira inter-relacionada.
Depois, adota-se o teste de validação dos requisitos do software
junto ao cliente, e o teste de sistema, por sua vez, é utilizado para a
verificação do funcionamento do software e do seu relacionamento
com outros sistemas e com o hardware onde está instalado.
Pfleeger (2004) adota uma abordagem similar à de Pressman e

Maxim (2016) sobre a modalidade de teste a ser utilizada conforme
a etapa de desenvolvimento do software. A seguir, a Figura 2 ilustra
um método para a testagem por meio de etapas. Nesse roteiro, os
testes são primeiramente realizados com os componentes de um
sistema e, após, com o sistema integrado.
Figura 2 – Roteiro com etapas para a realização de testes

componente componente
Código do Código do
Teste de Especificações
unidade Requisitos Outros Especificação Ambiente
de projeto funcionais do requisitos de de requisitos do usuário
Compo
sistema software do cliente

nente te
Teste de
unidade
stado
Teste de Teste Teste de Teste de Teste de

integração funcional desempenho aceitação instalação
Software
testado
Módulos Sistema verificado e Sistema

integrados funcionando validado aceito
onente
componente
Código do
Comp
Teste de SISTEMA EM USO

unidade
Fonte: Pfleeger, 2004, p. 246.
Segundo o autor, para verificar a conformidade do código

desenvolvido para o software, deve-se, primeiramente, utilizar
testes de unidade. Na sequência, quando os componentes são
integrados, deve-se realizar um teste de integração para analisar sua
conformidade com as especificações do projeto. Ainda, quando os
módulos estão todos integrados, é necessária a realização de um
teste funcional para verificar se o software está de acordo com
os requisitos funcionais. Uma vez o sistema em funcionamento,
torna‑se necessária a realização de testes de desempenho (ou de
sistema) para observar a conformidade do sistema com outros
requisitos de software. Por último, são necessários os testes de
aceitação, em que se verifica a adequabilidade com os requisitos do
cliente; e os testes de instalação (ou operacionais), para analisar se o

sistema está adequado ao ambiente operacional do usuário.
Conforme essas abordagens descritas, recomenda-se a escolha
do teste mais apropriado à etapa em que se encontra o projeto. Além
disso, os testes devem ser planejados de maneira sistematizada, em
etapas, conforme a seguir.
7.2.3 Planejamento e realização de testes

O planejamento é um processo sistematizado no qual se definem
as principais diretrizes a serem adotadas para a realização dos testes
e por meio do qual a equipe de desenvolvimento pode se comunicar,
dividir tarefas e padronizar a execução dos testes.
Pfleeger (2004) sugere seis etapas para a elaboração de um plano
de testes. Nessas etapas, definem-se e constroem-se o que o estudioso
denomina casos de teste, ou seja, as instâncias ou ocasiões de teste.
Esse plano inclui, além da construção de testes, métodos para sua
execução e avaliação, de modo que, ao final, as conformidades e
não conformidades (defeitos) sejam evidenciadas. Assim, segundo
o autor, um plano de testes contempla algumas etapas, conforme a
figura a seguir.
Figura 3 – Planejamento das etapas de testes
1 2 3
Estabelecimento Projeto dos casos Escrita dos casos
dos objetivos
4 5 6
Execução dos Avaliação dos
Teste dos casos testes resultados
Fonte: Elaborada pelo autor com base em Pfleeger, 2004.
Na primeira etapa, estabelecem-se os objetivos e definem-se

quais são os resultados esperados com a realização do teste, bem
como as metas a serem alcançadas. É importante estabelecer os

objetivos para que seja possível detectar determinados tipos de falhas
ou defeitos, que necessitam de uma modalidade de teste específica.
Depois, com base nos objetivos, definem-se os testes, a ordem em
que serão aplicados e os recursos a serem utilizados. Segundo Paula
Filho (2009), o projeto ou desenho dos casos de teste contempla a
especificação, os procedimentos e os tipos específicos de testes que
deverão ser adotados no processo de testagem.
Na sequência, os testes projetados na etapa anterior devem ser
escritos em linguagem técnica – recomenda-se o uso de notações
como a UML, em especial diagramas comportamentais, como o de
casos de uso e o de atividades. Nessa etapa de escrita, deve-se dar
atenção a quais componentes ou sistemas serão testados, a ordem
da testagem, a quais testes serão adotados para cada componente,
dentre outros detalhes.
Em seguida, realiza-se o teste dos casos de teste, etapa
recomendada antes da execução dos casos, uma vez que as testagens
demandam tempo e dinheiro. Essa etapa de casos de teste se faz por
meio da simulação fora do ambiente operacional do software.
Posteriormente, os testes são realizados no software, em ambiente
próprio. Segundo Paula Filho (2009), primeiramente é necessário
preparar, configurar e povoar materialmente o ambiente, para que
o teste seja executado conforme planejado. Recomenda-se, durante
cada testagem, anotar os resultados de modo a facilitar a etapa de
avaliação seguinte e possibilitar a correção de defeitos posteriores.
Por fim, avaliam-se os resultados do teste, verificando se são
positivos e quais são as correções necessárias. Recomenda-se a
análise comparativa desses resultados com o que foi projetado nas
etapas anteriores, assim como com os requisitos funcionais e não
funcionais definidos.
A elaboração e o cumprimento de um plano de testes são

essenciais para a adequada alocação de esforços e recursos para as
testagens. Ao se estabelecer objetivos, metas e casos de teste a serem
executados, disciplina-se o trabalho dos testadores e aumenta-se,
assim, as chances de que erros e falhas sejam detectados a tempo de
serem corrigidos antes da entrega final do software.
7.2.4 Roteiros para a realização dos testes

O planejamento também contempla a definição de um
roteiro para a realização de testes de software, que consiste no
sequenciamento dos componentes e dos testes a serem realizados.
Pfleeger (2004) recomenda abordagens distintas para o
sequenciamento de testes de componentes e software: a bottom-up
e a top-down. A primeira, conforme apresenta a Figura 4, aborda a
realização de testes em cada componente isoladamente e, depois,
nos componentes integrados entre si, até finalizar com um último
teste no sistema integrado.
Figura 4 – Teste bottom-up
Teste
Teste E
B, E, F
Teste A,
Teste F Teste C B, C, D,
E, F, G
Teste
Teste G
D, G
No exemplo apresentado, foram realizados primeiramente

testes nos componentes C, E, F e G. Na sequência, os componentes
foram integrados nos grupos B, E, F e D, G. Essa integração entre os
componentes foi testada novamente, de modo que, ao final, todos os

componentes passassem por testes de maneira integrada.
Já a abordagem top-down consiste na realização de testes
primeiramente com o sistema como um todo, em seu nível
de abstração mais elevado e, depois, com seus componentes
isoladamente. Pfleeger (2004) ainda sugere, com relação a essa
abordagem, uma forma mesclada com a bottom-up, denominada
teste top-down modificado. Nesse caso, testam-se os componentes
e, em seguida, o sistema como um todo. Após isso, o sistema passa
novamente por testagem de seus componentes e, então, uma nova
configuração de componentes integrados é testada. A Figura 4
ilustra o teste top-down modificado contemplando duas instâncias
de integração e desintegração.
Figura 5 – Teste top-down modificado
Teste B Teste E
Teste Teste A,
Teste A Teste C A, B, C, D Teste F B, C, D, E,
F, G
Teste D Teste G
Nesse exemplo, o componente A foi testado isoladamente, assim

quanto os componentes B, C e D. Depois, foram realizados os testes
para os componentes A, B, C, D em conjunto. Em seguida, foram
testados isoladamente os componentes E, F e G e, por último, todos
os componentes foram testados – A, B, C, D, E, F e G.
É importante destacar que a testagem de software requer
disciplina para planejá-la e sequenciá-la. Além disso, testes
adequadamente planejados e executados evitam retrabalhos e gastos

desnecessários de recursos. Dessa forma, tanto as conformidades
como as não conformidades, no desenvolvimento de software, são
detectadas, analisadas e tratadas de maneira precisa, assegurando
posterior adequabilidade do software com os requisitos funcionais e
não funcionais.
Vídeo 7.3 Manutenções e reengenharia

O processo de desenvolvimento de software
inclui a realização de manutenções e engenharia
reversa, também dependentes da realização
de testagens. O sucesso nos testes da etapa de
implantação não significa que o software está
livre de quaisquer falhas; e, durante sua execução no dia a dia,
defeitos ainda não detectados podem aparecer, principalmente
considerando que, com o avanço tecnológico, há possibilidade
de ocorrem atualizações de hardware, de sistemas operacionais e
de outros softwares, o que pode prejudicar o funcionamento do
software construído.
Dessa forma, além do desenvolvimento do software, é preciso
implantar políticas de manutenção e revisão contínua para que
adaptações, mudanças e melhorias sejam adequadamente tratadas
e aplicadas com sucesso em novas versões do software. Além disso,
sistema legado:
pode surgir a necessidade de realizar adaptações do sistema legado
sistema antigo
que permanece do cliente ao novo software desenvolvido, denominadas engenharia
em execução.
reversa, em que se desenvolve o sistema legado novamente, mas
em uma outra linguagem ou adapta-se seus componentes para
proporcionar a compatibilidade necessária ao novo sistema.
Os itens a seguir tratam de políticas e práticas relacionadas a
revisões e reengenharia, as quais, junto à realização de testes, são
relevantes para a garantia da qualidade e a durabilidade do software.
7.3.1 Modalidades de reengenharia de software

Desenvolver e testar softwares pode demandar uma considerável
quantidade de tempo e recursos. Desde a concepção até a entrega, o
desenvolvimento de um software pode acarretar riscos que podem
ser evitados com antecedência pela equipe de desenvolvimento.
Dessa forma, uma alternativa para esse trabalho é a engenharia
reversa, ou reengenharia, de software, que, conforme o nome
sugere, consiste na reconstrução de um software a partir de uma
solução já existente.
Uma das vantagens desse processo é a redução de custos e
esforços, à medida que o código existente já está desenvolvido.
Outra vantagem consiste na diminuição de riscos, visto que os
componentes do código desenvolvido já demonstraram, em
algum momento, a funcionalidade desejada. Sommerville (2011)
destaca algumas modalidades de reengenharia de software a serem
adotadas, as quais abordam, de alguma forma, a transformação da
versão antiga de um software em uma versão atualizada e funcional.
Essas modalidades estão descritas a seguir.
• Engenharia reversa de informações: nesse caso, o software
é analisado como um todo e as suas informações – como
código-fonte, interações entre componentes, bancos de dados,
funcionalidades etc. – são extraídas para futura codificação.
• Tradução de código-fonte: nessa modalidade, o código-fonte
do software é convertido de uma versão mais antiga para
uma atual. Para a realização dessa atualização, é necessário
o conhecimento, por parte da equipe de desenvolvimento,
das linguagens de programação, tanto das antigas quanto das
atuais para as quais o software será convertido.
• Melhoria de estrutura de programa: nessa modalidade,
modifica-se a estrutura do software e seus controles de modo
a melhorar sua legibilidade. Tal prática, também denominada
refatoração, visa auxiliar na realização de manutenções no
software por parte da equipe de trabalho, além de facilitar a

leitura e interpretação do código para novas equipes em caso
de mudanças.
• Modularização de programa ou eliminação de redundâncias:
nessa modalidade, agrupam-se partes do software que
possuam alguma relação entre si, e as redundâncias são
removidas. Isso diminui o espaço ocupado pelo software em
memória, aumenta a velocidade de processamento e auxilia
na legibilidade do código.
• Adaptação dos dados processados pelo software à nova
estrutura: nesse caso, redefinem-se esquemas de bancos
de dados e convertem-se bancos de dados existentes. Essa
medida é necessária para garantir a compatibilidade dos
bancos de dados e dos dados armazenados nestes, com o novo
software desenvolvido.
Independentemente da modalidade de reengenharia escolhida, é
necessário, assim como com os testes, adotar um plano de ações para a
realização dos processos de reengenharia. Uma das maneiras possíveis
de se executar a reengenharia de software será descrita a seguir.
7.3.2 Processo de reengenharia de software

A atividade de reengenharia de software, assim como a realização
de testes, acarreta riscos. Logo, é necessária a sistematização desse
processo por meio de um plano de ações.
Pressman e Maxim (2016) descrevem uma sequência de ações
que devem ser executadas para um processo de reengenharia de
software, conforme ilustra a Figura 6. Essas ações, dispostas de
maneira cíclica, abordam desde questões relacionadas a código até a
dados e documentação.
Figura 6 – Modelo de processo de reengenharia de software
Análise do
Engenharia inventário
direta
Reestruturação
do código
Reestruturação
dos dados
Engenharia
reversa
Reestruturação
dos documentos
Com base na Figura 6, o plano de ações para reengenharia de software

é composto de cinco passos: análise do inventário,reestruturação
do código, engenharia reversa, reestruturação dos documentos,
reestruturação dos dados e engenharia direta.
Na análise do inventário, há o levantamento das principais
informações sobre os sistemas operacionais atualmente utilizados
pela empresa, como idade, tamanho, funcionalidades, relações com
outros softwares, dentre outras relevantes para se detectar possíveis
softwares candidatos à reengenharia. Já no segundo passo do plano
de ações ocorre a reestruturação do código-fonte do programa,
utilizando interfaces de desenvolvimento (IDEs) de modo a atualizar
o código e torná-lo mais “limpo”. Essa reestruturação pode ser feita
manualmente ou por meio de software automatizado de codificação.
Por sua vez, a engenharia reversa consiste em analisar o
software para desenvolver sua representação de modo mais abstrato
do que seu código‑fonte. Nesse caso, extraem-se dados relativos à
arquitetura do sistema e ao seu funcionamento, visando possibilitar
uma nova codificação.
O quarto passo consiste, ainda, na reestruturação da

documentação do software ou, se necessário, no desenvolvimento
de uma documentação inteiramente nova. Essa documentação
deve abranger os componentes e funcionalidades necessários para a
realização da reengenharia, no entanto, nem todos os componentes
necessitam ser documentados.
Na sequência, a reestruturação dos dados abrange a recuperação
da base de dados armazenada no software para que possa ser
reaproveitada na nova versão desse software. Dependendo da
complexidade dos dados, pode ser necessário um processo de
reengenharia específico para o banco que os armazena.
Por fim, a engenharia direta “não apenas recupera as informações
do projeto do software existente, como também as utiliza para
alterar ou reconstituir o sistema, em um esforço para melhorar sua
qualidade geral” (PRESSMAN; MAXIM, 2016, p. 805), isto é, o
próprio projeto do software é utilizado como base para sua melhoria,
recriando-se funcionalidades do sistema existente e acrescentando-
se novas funções.
Dessa forma, a reengenharia e a manutenção de software não
podem ser ignoradas por desenvolvedores, mesmo quando o
software foi entregue ao cliente ou usuário. Problemas e necessidades
de melhoria podem acontecer, assim como necessidades de
adaptações de sistemas legados para receber o novo software, e
tanto a manutenção quanto a reengenharia devem ser processos
sistematizados, de modo a racionalizar o uso de recursos.
Tanto a realização de testes quanto práticas de reengenharia,
engenharia reversa, dentre outras, são essenciais para a racionalização
dos custos e esforços no processo de desenvolvimento de um software.
Existem várias ocasiões nas quais testes podem ser realizados em

um software; essas requerem planejamento e disciplina. A realização
de testes em software deve ser um processo cuidadoso, pois defeitos
detectados tardiamente, ou ignorados, podem acarretar custos
elevados para a correção, principalmente se o software já estiver em
um estágio de desenvolvimento próximo à entrega final ao cliente.
Da mesma forma, a reengenharia, ou engenharia reversa, deve
ser feita com cautela, tomando cuidado com detalhes do código
antigo (legado) que podem ser essenciais para o funcionamento
do software. A decisão de se fazer essas práticas ou adquirir um
software novo deve ser cuidadosamente ponderada de modo que a
decisão tomada seja economicamente viável.
Assim, os processos de testes e engenharia reversa em software
não podem ser realizados de maneira empírica ou sem critérios
racionais, haja vista sua importância para o bom desempenho do
sistema em sua versão finalizada.

• RIOS, E.; FILHO, T. M. Teste de software. Rio de Janeiro: Alta
Books, 2013.
Esse livro aborda de maneira didática diferentes questões
relacionadas a testes de software, como processos, estimativas
e questões relacionadas à infraestrutura, além de apresentar
diversos exemplos de realização de testes.
• 3 DICAS sobre entrevistas de teste de software. 2019. 1 vídeo

(6min57s). Publicado pelo canal Julio de Lima. Disponível
em: https://www.youtube.com/watch?v=6oFkfhq1E5k.
Acesso em: 3 dez. 2019.
Nesse vídeo, o autor descreve um roteiro contendo três dicas
para participação em entrevistas de emprego para testador
de software, abordando questões como perfil da empresa e o

modo que a pessoa desempenhará o seu cargo.
Atividades
1. Uma das áreas de atuação do engenheiro de software é no
projeto de sistemas de serviços on-line, como sistemas
bancários e sistemas de vendas de passagens aéreas. Quais
são os tipos de defeitos que podem ocorrer no projeto desses
sistemas?
2. Desenvolva um código ou escolha um aplicativo de celular.

Depois, escreva um possível caso de teste, com o tipo de teste
de sua preferência.
3. Uma das aplicações da reengenharia é o desenvolvimento

de softwares de abordagem similar ao original, porém com
algumas funcionalidades modificadas. Pesquise exemplos de
aplicativos ou serviços de internet em que isso ocorre.
Referências
PFLEEGER, S. L. Engenharia de software: teoria e prática. São Paulo:

Pearson, 2004.

SOMMERVILLE, I. Engenharia de software. São Paulo: Pearson Prentice

Hall, 2011.
8
Práticas de engenharia de software
Neste capítulo, você vai conhecer tópicos especiais da prática

profissional em desenvolvimento de software, que vão além de
simples modelagem, codificação e testes de sistemas. Você aprenderá
a respeito do entretenimento, ou mais especificamente, da indústria de
jogos, executados em dispositivos móveis como smartphones e tablets.
Além de entretenimento, os dispositivos móveis têm sido cada
vez mais utilizados para as diversas tarefas do dia a dia, como pagar
uma conta (aposentando-se o cartão de plástico), conversar, tirar
fotografias, navegar pela internet e, inclusive, estudar. Atualmente,
fica difícil imaginar a nossa vida sem a existência da tecnologia
móvel. Assim, este capítulo apresenta alguns conceitos necessários
para o engenheiro de software atuar com essas novas tendências.
Primeiramente, vamos estudar o design de interação, o qual
consiste em princípios e práticas para a promoção da interação
entre o ser humano e a tecnologia. Depois, vamos tratar de alguns
princípios e técnicas de design de jogos, abordando questões como
narrativa, mecânica, interface, documentação e playtest.
Também, conheceremos as diretrizes básicas para o
desenvolvimento de WebApps e aplicativos móveis, contemplando
aspectos básicos a serem considerados em relação à estruturação e
viabilização desses produtos, além de questões como usabilidade,
funcionalidade, confiabilidade, eficiência e facilidade de
manutenção. Por último, observaremos tópicos para o projeto de
aplicativos voltados para dispositivos móveis, que possibilitam
elaborar e analisar um projeto de aplicativo móvel de modo a
viabilizar um produto fácil de usar e funcional.
Vídeo 8.1 Design de interação

O usuário é fundamental para o
desenvolvimento de softwares e sistemas, pois é
quem se beneficia e faz uso dos produtos. Tudo
começa com o usuário, pois sem ele não haveria
necessidade de as organizações disponibilizarem
produtos e serviços, bem como não faria sentido haver designers,
desenvolvedores ou mesmo testadores. Assim, torna-se necessário
compreender como o usuário pensa e, principalmente, como
interage com os softwares e sistemas.
O design de interação diz respeito ao “design de produtos
interativos que fornecem suporte às atividades cotidianas das pessoas,
seja no lar ou no trabalho” (PREECE; ROGERS; SHARP, 2005, p. 28),
sendo assim, consiste em projetar produtos e serviços que sejam, ao
mesmo tempo, úteis e fáceis de serem manuseados ou manipulados
pelas pessoas.
Um exemplo do design de interação é o smartphone, que, a
princípio, é um produto com apenas uma superfície de contato
(a tela). Quando essa superfície é ligada, possibilita observar que
aspectos como a disposição e os símbolos de cada ícone e a forma
como se movimenta de um lado para o outro conforme o deslizar
de um dedo denotam que esse produto foi projetado para ser usado
intuitivamente, ou seja, é como se o usuário utilizasse o produto por
instinto ou intuição, não necessitando, por exemplo, de um manual
de instruções.
Nos itens a seguir, serão abordadas questões de interação
e usabilidade, que devem ser consideradas por engenheiros de
software em projetos que envolvam interação com o usuário, como
aplicativos de smartphone, interfaces, painéis, dentre outros.
8.1.1. Aspectos cognitivos do usuário

No projeto de um aplicativo ou qualquer outro software,
é importante considerar que o usuário é, antes de tudo, um
Práticas de engenharia de software 149
ser pensante. Assim, a utilização desse software será de modo

intencional, com um propósito, para entretenimento, conversação,
solução de problemas, dentre outras finalidades.
Dessa forma, o projeto de um software deve considerar, tanto
visual quanto funcionalmente, os processos cognitivos por meio
dos quais o usuário utilizará esse software. Segundo Preece; Rogers;
Sharp (2005, p. 94), “a cognição é o que acontece em nossas mentes
quando realizamos atividades diárias; envolve processos cognitivos,
tais como pensar, lembrar, aprender, fantasiar, tomar decisões, ver,
ler, escrever e falar”. Assim, quando um software é acessado, uma
informação é inserida ou recebida ou um botão é clicado, alguma
decisão foi tomada na mente do usuário, e a resposta fornecida pelo
software estimulará, de alguma forma, seus pensamentos.
O autor ainda destaca uma série de processos cognitivos que são
relevantes no momento de se projetar a interação de um usuário em
um produto, inclusive software, conforme estão descritos a seguir.
a) Atenção
Este processo cognitivo consiste em “selecionar coisas em que se
concentrar, num certo momento, dentre a variedade de possibilidades
disponível” (PREECE; ROGERS; SHARP, 2005, p. 95). A atenção é
relevante, por exemplo, no projeto de uma interface, quando se deseja
que o usuário se atente para algo que está acontecendo, por meio de
um alerta, um destaque, uma mensagem importante, dentre outros.
b) Percepção e reconhecimento
Esse processo cognitivo “refere-se a como a informação é adquirida
do ambiente pelos diferentes órgãos sensitivos (por exemplo, olhos,
ouvidos, dedos) e transformada em experiências com objetos, eventos,
consoles:
sons e gostos” (PREECE; ROGERS; SHARP, 2005, p. 97). A percepção
dispositivos
de sentidos, na indústria de software, é cada vez mais explorada, por para a
execução de
exemplo, no desenvolvimento de jogos digitais, com a adoção de
jogos, também
estímulos além do visual e do auditivo. Atualmente, os jogos digitais conhecidos
como
e os consoles possibilitam, cada vez mais, a exploração de sensações
videogames.
táteis, como os consoles de videogame com controles vibratórios.

Além disso, já há estudos para o estímulo de sensações olfativas.
c) Memória
Outro processo que “implica recordar vários tipos de
conhecimentos que nos permitem agir adequadamente” (PREECE;
ROGERS; SHARP, 2005, p. 98). Esse processo cognitivo pode
ser associado ao aprendizado, cada vez mais explorado no
desenvolvimento de software. O aprendizado “pode ser considerado
no que concerne a (i) como utilizar uma aplicação baseada em
computador ou (ii) utilizar uma aplicação baseada em computador
para entender um dado tópico” (PREECE; ROGERS; SHARP, 2005,
p. 105). Atualmente, abordam-se a memória e o aprendizado no
desenvolvimento de software sob o ponto de vista da intuitividade.
Softwares, principalmente aplicativos de smartphone, têm sido
desenvolvidos de modo que o usuário memorize rapidamente as
funcionalidades e a forma de utilizar seja a mais próxima do que ele
está acostumado em outros softwares da mesma categoria.
d) Leitura, fala e audição
Esses processos também devem ser considerados em um projeto,
pois são utilizados pelo usuário para a percepção das informações
contidas em um software e apresentam “propriedades semelhantes
e diferentes. Uma similaridade diz respeito ao significado das
sentenças ou frases ser o mesmo, sem levar em consideração o
modo em que estão expressas” (PREECE; ROGERS; SHARP, 2005,
p. 106). Dessa forma, antes de se pensar em como a informação
será transmitida, deve-se pensar na construção da informação
em si. Porém, “a facilidade com que as pessoas podem ler, ouvir
ou falar varia conforme a pessoa, a tarefa e o contexto” (PREECE;
ROGERS; SHARP, 2005, p. 107), sendo necessário pensar em como
a pessoa interpretará melhor a informação que será transmitida,
questionando-se, por exemplo, se será por meio visual ou auditivo.
Esse tipo de questionamento deve ser considerado, especialmente,

para pessoas portadoras de deficiência.
e) Resolução de problemas, planejamento, raciocínio e
tomada de decisão
Esses são processos que “envolvem cognição reflexiva. Implicam
pensar sobre o que fazer, quais são as opções e quais podem ser as
consequências de se realizar uma dada ação” (PREECE; ROGERS;
SHARP, 2005, p. 108). Sempre que utiliza um software, o usuário
está tomando decisões, escolhendo qual botão apertar, qual menu
acessar, qual é a funcionalidade ou informação desejada, dentre
outras. Dessa forma, é importante que o software o auxilie na
tomada de decisões, seja por meio de um menu de ajuda, destaque
de uma informação ou seja qualquer outra solução. Um dos intuitos
principais de um software deve ser facilitar a vida de um usuário, e
não o deixar em apuros.
Conforme observamos, os aspectos cognitivos do usuário devem

ser considerados no projeto de um software tendo-se em vista que
esse produto é desenvolvido, essencialmente, para a interação com
o ser humano. A tecnologia tem o propósito de facilitar a vida das
pessoas, razão pela qual a interação humano-computador deve ser,
acima de tudo, a mais natural possível. O item a seguir apresenta as
interfaces gráficas – uma das formas de a interação acontecer.
8.1.2. Projeto de interfaces

As interfaces consistem nos meios pelos quais o usuário interage
com o sistema, como telas, botões, dispositivos (mouse e teclado),
dentre outros. O projeto de um software deve contemplar a forma
pela qual as interfaces serão utilizadas, uma vez que é por meio
destas que o usuário fornecerá as entradas necessárias para o
sistema, conforme podemos observar na Figura 1.
Figura 1 – Interface gráfica com o usuário
ProductionPerig/Shutterstock
Um exemplo de interface gráfica com o usuário é a tela de um smartphone, por meio da qual ele pode
acessar as funcionalidades de um aparelho, como aplicativos, representados pelos botões coloridos.
Na engenharia de software, o projeto de interfaces abrange,

essencialmente, a aplicação dos aspectos cognitivos no
desenvolvimento de maneiras de se inserir entradas e gerar saídas
em um sistema. Desse modo, a consideração das características e
necessidades do usuário em um projeto é de suma importância,
tendo-se em vista que a operação adequada do software depende
dele. Mandel (1997, apud Pressman; Maxim, 2016) determina,
assim, o que se denomina Regras de Ouro no projeto de interfaces.
• Regra 1: Usuário no comando
O usuário deve ter o controle total de suas ações em um software.
O software não pode, por exemplo, fazer com que o usuário realize
ações indesejadas ou desnecessárias para ele conseguir o que quer
e deve permitir interrupções de ações por parte deste. A interação
deve ser simplificada de acordo com o grau de aprendizagem do
usuário, e detalhes técnicos de funcionamento devem ser ocultados
do usuário iniciante, permitindo a personalização desses detalhes
no caso de usuários avançados. Ainda, o projeto de um software
deve ser feito de modo que o usuário interaja diretamente com os

objetos de uma tela.
• Regra 2: Redução da carga de memória para o usuário
A memória é um processo cognitivo que trata da recordação de
conhecimentos, sendo associada à aprendizagem. Dessa forma, é
importante que o usuário, ao utilizar um software, consiga detectar
padrões, como formas e funcionalidades, tenha acesso a atalhos
intuitivos, que as informações sejam reveladas progressivamente, e
não todas de uma vez, para não confundir o usuário, e que o layout
da interface, na medida do possível, aproxime-se das características do
mundo real (MANDEL, 1997 apud PRESSMAN; MAXIM, 2016). Por
exemplo, um sistema de pagamento de boletos bancários ter o layout e
a disposição de informações similares aos de um boleto bancário físico.
• Regra 3: Consistência da interface
O software deve “fornecer indicadores (por exemplo, títulos para as
janelas, ícones gráficos, sistema de cores padronizado) que possibilitem
ao usuário saber o contexto do trabalho em mãos” (MANDEL, 1997,
apud PRESSMAN; MAXIM, 2016, p. 320-321). Assim, a interface
deve estar consistente com a tarefa a qual será realizada pelo
usuário e tal consistência deve ser mantida no caso de uma linha
de produtos (ou seja, softwares de uma mesma família), de modo
que o usuário já tenha familiaridade com sua utilização. Alterações
na interface, assim, somente devem ser feitas se forem estritamente
necessárias, pois a tendência é o usuário já ter se acostumado a
utilizar determinado comando, como digitar CTRL+B para salvar
um arquivo no Microsoft Word.
Desse modo, entendemos que o projeto de interfaces é essencial

para que um software seja compreendido e adequadamente utilizado
pelo usuário, tornando-se necessário não somente projetá-lo, mas
simular a sua utilização. Isso é possível por meio de uma técnica
denominada prototipação, descrita a seguir.
8.1.3. Prototipação
A prototipação é uma técnica na qual, por meio de um
dispositivo, processo ou objeto similar ao que seria o resultado final
de um projeto, simula-se a utilização de um produto ou serviço. “Os
protótipos são muito úteis quando se estão discutindo ideias com
stakeholders; são dispositivos que facilitam a comunicação entre
os membros das equipes e que consistem em uma maneira eficaz
de testar as ideias para você mesmo” (PREECE; ROGERS; SHARP,
2005, p. 261, grifo do original).
Assim, na engenharia de software, o uso de protótipos, interfaces
ou componentes é útil para a discussão de ideias e possibilidades
de abordagem em um projeto entre desenvolvedores e clientes. Os
autores supracitados defendem algumas finalidades para a elaboração
de protótipos, que também se aplicam à engenharia de software:
• Teste da viabilidade técnica de uma ideia: a partir de um
protótipo de um software ou interface, é possível verificar
questões como funcionalidades, interação com o usuário, se
há a possibilidade de requisitos funcionais ou não funcionais
serem atendidos, dentre outros.
• Esclarecimento de requisitos vagos: por meio do protótipo,
por exemplo, é possível aos desenvolvedores exporem seus
pontos de vista com relação aos requisitos de um software
no formato de um protótipo que simula esse requisito
sendo atendido. Dessa forma, o cliente pode analisar esse
protótipo para verificar se a interpretação dada pela equipe
de desenvolvimento condiz com o seu ponto de vista. Os
protótipos são ferramentas úteis na etapa de definição de
requisitos.
• Testes e avaliações com usuários: por meio de um protótipo,
é possível visualizar o usuário operando o que poderia ser
o software em sua versão acabada, avaliando-se possíveis
melhorias a serem feitas e aspectos positivos e negativos na

solução apresentada pela equipe de desenvolvimento.
• Verificação da compatibilidade: por meio de um protótipo,
é possível verificar se determinado conceito adotado em uma
parte do projeto é compatível com o utilizado no restante do
sistema desenvolvido. A partir da análise comparativa entre
diferentes protótipos, ou entre um protótipo e um sistema
finalizado, é possível verificar o que precisa ser adaptado em
um sistema para que seja compatível com os demais.
A elaboração de protótipos pode ser feita de duas formas
possíveis de prototipação: baixa fidelidade e alta fidelidade.
A prototipação de baixa fidelidade, como o nome sugere,
consiste na construção de protótipos com pouca similaridade ao
produto acabado. “Os protótipos de baixa fidelidade são úteis porque
tendem a ser simples, baratos e de rápida produção” (PREECE;
ROGERS; SHARP, 2005, p. 263). Esses protótipos possuem custo
mais baixo de desenvolvimento, mas contam com limitações de
uso e de verificação de erros tendo em vista a menor relação com o
produto final.
Na engenharia de software, um exemplo de protótipo de baixa
fidelidade seria um conjunto de telas de software esboçadas em um
software gráfico e impressas em papel, para que o usuário simule
a utilização deste software de modo a verificar se a disposição das
informações e funcionalidades está adequada. Outro exemplo de
prototipação de baixa fidelidade é o uso de storyboard, que consiste
em uma “série de desenhos mostrando como um usuário pode
progredir em uma tarefa utilizando o produto que está sendo
desenvolvido” (PREECE; ROGERS; SHARP, 2005, p. 263). Como o
nome sugere, em um storyboard, uma história de uso de um produto
ou serviço, é contada com ilustrações dispostas lado a lado, como
nas histórias em quadrinhos.
O exemplo a seguir ilustra a história de utilização de um software

de digitalização de imagens por um usuário.
Figura 2 – Exemplo de storyboard
O usuário pega um documento e se dirige ao O escâner digitaliza o documento e o salva no

escâner. computador.
O documento aparece na tela do computador. Os caracteres do documento são reconhecidos

por OCR (Optical Character Recognition).
Já o protótipo de alta fidelidade “utiliza materiais que você

espera que estejam no produto final e realiza um protótipo que se
parece muito mais com algo acabado” (PREECE; ROGERS; SHARP,
2005, p. 265). Um protótipo de alta fidelidade em software, seria, por
exemplo, uma simulação do software em formato digital contendo
telas leiautadas como seria na realidade, podendo este protótipo ser
acessado por smartphone ou por PC, e o usuário podendo interagir
com esse protótipo como se fosse o software real.
Assim, observamos que o design de interação é uma disciplina
essencial na engenharia de software, uma vez que softwares são
desenvolvidos tendo-se em vista atender às expectativas e
necessidades de um usuário, o que somente é possível se, no processo
de desenvolvimento, as características cognitivas do usuário forem
compreendidas e puderem ser traduzidas em interfaces, protótipos e

produto final.
Vídeo 8.2 Jogos digitais

Uma das áreas mais promissoras em
engenharia de software é o desenvolvimento de
jogos digitais. A indústria de jogos é uma das mais
lucrativas, pois movimenta mais de 1,5 bilhão de
dólares somente no Brasil e mais de 1,9 trilhão
de dólares mundialmente (AGÊNCIA BRASIL, 2019). Esse setor
de entretenimento encontra‑se em crescimento em todo o mundo,
e parte significativa disso se deve à utilização cada vez maior de
dispositivos móveis, como smartphones e tablets, bem como redes
sociais, que estimulam a prática de jogos em grupos.
Além da programação, desenvolver um jogo digital significa
aprimorar atributos como lógica, criatividade e senso artístico, que
necessitam também da sabedoria do engenheiro de software em
trabalhar de maneira harmoniosa com equipes multidisciplinares
– compostas de artistas, designers, produtores de som, escritores,
dentre outros – agindo como uma interface entre esses profissionais
e a equipe de desenvolvimento, a qual deverá poder transformar o
trabalho desses artistas em código.
Assim, torna-se relevante que o engenheiro de software conheça
as partes componentes do desenvolvimento de um jogo digital,
para participar ativamente no trabalho dos demais profissionais
e orientar, de maneira apropriada, a equipe de desenvolvimento,
conforme abordam os itens a seguir.
8.2.1. Ideia
Toda criação inicia-se com uma ideia, seja uma obra de arte, um
software ou mesmo um jogo. Uma ideia de jogo digital, para se tornar
viável, deve considerar, além de aspectos técnicos de desenvolvimento,
aspectos relativos ao principal componente de um jogo: o jogador.
Um jogo somente tem sentido se proporcionar ao jogador algo

pelo qual ele se identifique e valorize. Para Schell (2011), é necessário,
na idealização e no desenvolvimento de jogo, pensar no que é
valioso para os jogadores, em como tornar o jogo mais valioso e
nas relações entre o valor do jogo e as motivações do jogador. Dessa
forma, uma ideia deve considerar a possibilidade de, quando o jogo
for desenvolvido, o jogador se identificar com ele em termos de
princípios e valores. Assim, o jogador terá facilidade em se concentrar
de maneira imersiva, ou seja, “fugir da realidade” enquanto joga.
Outra questão de relevância na idealização de um jogo é a
solução de problemas. Um jogo consiste, por natureza, em uma série
de desafios a serem cumpridos pelo jogador, seja por meio de um
quebra-cabeças – como nos jogos de estratégia – ou de ações com
o uso de coordenação motora – como nos jogos de ação. De acordo
com Schell (2011), no processo de idealização, é necessário pensar
em quais desafios (inclusive ocultos) o jogo solicita para o jogador
solucionar e como pode gerar novos desafios para que ele sempre
volte a jogá-lo.
8.2.2. Narrativa
Assim como na vida real, um jogo tem desafios a serem cumpridos.
E, a cada desafio cumprido, uma história ou narrativa pode ser
contada. A narrativa também é um componente essencial na criação
de jogos. É por meio das narrativas, ou histórias, que o jogador se situa
no universo do jogo e se identifica com cenário, personagens, dentre
outros elementos.
Em um jogo digital, planejar uma narrativa é pensar no
sequenciamento das fases e da história de um jogo, o que significa,
também, pensar em horas trabalhadas por uma equipe de
desenvolvimento. Conforme Schell (2011), recomenda-se que o jogo
possibilite a personalização da história a ser contada por parte do
jogador, personalizando cenários e personagens. A personalização
da história, apesar de interessante, significa também desenvolver
algoritmos que possibilitem essa personalização por parte do jogador,

o que também pode demandar tempo de desenvolvimento. Dessa
forma, no projeto da narrativa, é preciso que designers de jogos e
desenvolvedores entrem em acordo a respeito das funcionalidades a
serem apresentadas no jogo, de modo a viabilizá-lo adequadamente.
Ainda de acordo com Schell (2011, p. 310), pensar em narrativa
é proporcionar diferentes escolhas aos jogadores a respeito de
como atingir seus objetivos, além de proporcionar conflitos a serem
resolvidos pelo jogador. As escolhas, bem como os conflitos, facilitam
o envolvimento por parte do jogador com a narrativa que está sendo
contada, o que facilita a identificação, por parte do jogador, com a
história que está sendo contada. Para o autor, “a história só é boa
se você puder afirmar isso. A quem seus jogadores podem contar a
história que realmente importa?” (SCHELL, 2011, p. 266), ou seja,
quem determina se uma história encontra-se bem contada é o jogador
– o desenvolvedor apenas habilita os mecanismos para contá-la
adequadamente.
Uma boa história somente pode ser contada com a ajuda de
personagens, os quais também devem ser desenvolvidos tanto em
termos de aparência quanto de movimentação, ações que podem
desempenhar, dentre outros atributos. Em uma história, cada
personagem desempenha um determinado papel e se adequa a ele.
Conforme Schell (2011), “se criarmos jogos com histórias
excelentes, essas narrativas deverão conter personagens memoráveis”
(SCHELL, 2011, p. 310). Ainda conforme o autor, atenção especial
deve ser dada aos personagens controlados pelo jogador, denominados
avatares. Um avatar deve ser projetado de modo que o jogador,
quando interagir com ele, identifique-se de alguma forma com esse
personagem. “Há momentos em que o jogador é claramente distinto
do avatar, mas há outros em que o estado mental do jogador se projeta
totalmente no avatar, a ponto de o jogador gemer ou ofegar quando o
avatar é ferido ou ameaçado” (SCHELL, 2011, p. 312).
Assim, avatares podem ser projetados e desenvolvidos de duas

formas possíveis: avatares neutros, sem envolvimento do jogador com
o personagem, ou avatares que proporcionam esse envolvimento de
modo que o jogador se sinta imerso na narrativa, como se participasse
ativamente desse mundo, “desligando-se” do mundo exterior.
Sendo assim, desenvolver narrativas e personagens em um
jogo digital também significa pensar em engenharia de software.
A partir do momento em que se definem a história a ser contada
e os personagens que participarão dela, cada personagem ou parte
da história representa linhas de código a serem desenvolvidas. Cabe
à equipe de desenvolvimento pensar no balanceamento entre uma
história bem contada e um jogo bem projetado.
8.2.3. Mecânica
Um jogo digital não se constrói somente por meio de histórias
e personagens bem elaborados. É necessário pensar em quais ações
são possíveis de serem realizadas, como serão realizadas e quais serão
as consequências. Além disso, devem ser consideradas as regras, ou
seja, como o jogo funcionará, quais objetos serão manipulados, qual
será o espaço disponível, quais habilidades o jogador desenvolverá ao
jogar e quais serão os aspectos probabilísticos e não probabilísticos
presentes no jogo, ou seja, o que tem base na sorte, e o que o jogador
pode controlar. Enfim, é necessário pensar nas mecânicas que
compõem o jogo.
Conforme Schell (2011), existem seis mecânicas possíveis que
devem ser consideradas no desenvolvimento de jogos, inclusive
digitais: espaço, objetos, ações, regras, habilidades e probabilidade.
• Espaço
A primeira mecânica exposta por Schell é o espaço, que, segundo
o autor, “define os vários lugares que podem existir em um jogo, e
como esses lugares estão relacionados entre si” (SCHELL, 2011, p. 130).
O espaço em um jogo digital é como um tabuleiro em um jogo
analógico: define os limites físicos do jogo e da movimentação dos

personagens. Um espaço de jogo é matematicamente dimensionado
e, quanto maior for, maior será a variedade de cenários possíveis
de serem inseridos, o que demandará mais quantidade de horas de
desenvolvimento por parte de designers e programadores.
• Objetos
O segundo elemento de mecânica a ser considerado são os
objetos presentes no jogo, bem como seus atributos (características)
e estados (isto é, com qual característica o objeto se encontra no
atual momento). “Se os objetos são substantivos da mecânica do
jogo, podemos dizer que os atributos e seus estados são os adjetivos”
(SCHELL, 2011, p. 136), ou seja, um objeto (por exemplo, um
personagem) tem atributos (altura, peso, aparência, dentre outras) e
estados (dormindo, acordado, inconsciente, invisível, visível, dentre
outros). Cada objeto, seus atributos e estados devem ser programados
de modo a refletir sobre as ações que deverão desempenhar em
determinado momento do jogo.
A Figura 3 ilustra as variações de estado no jogo Pac-Man, um
exemplo de aplicação de objetos e estados.
Figura 3 – Objetos e estados no jogo Pac-Man
Devorado
Pac-Man come pelo Pac-
Hora de pastilhas de Azul: Man
sair da jaula Perseguindo energia Fugindo do
Na jaula o Pac-Man Pac-Man
Medidor
Medidor das das pastilhas
Olhos pastilhas de quase cheio
chegaram à energia cheio
jaula
Olhos Piscando:
Rolando: até Fugindo do
Devorado Pac-Man
a jaula pelo Pac-Man
Fonte: Schell, 2011, p. 137.

No jogo digital Pac-Man, o jogador deve movimentar um

personagem no formato de um círculo amarelo (o Pac-Man) em um
tabuleiro com forma de um labirinto, comendo pastilhas de comida
enquanto foge de fantasmas cujo principal atributo é perseguir o
esse personagem, além de serem de diferentes cores. Cada fantasma
(objeto) tem dois estados: perseguindo ou fugindo do Pac‑Man.
Quando o perseguem, os fantasmas são coloridos; quando o
Pac‑Man come uma pastilha de energia, os fantasmas mudam de
estado e passam a fugir dele, que também pode comê-los.
• Ações
O terceiro tipo de mecânica em um jogo digital são as ações,
ou seja, o que o jogador, amigos e oponentes poderão realizar.
“Ações são os ‘verbos’ da mecânica dos jogos. Há duas perspectivas
em relação às ações ou, dito de outro modo, duas maneiras de
responder à pergunta ‘o que os jogadores podem fazer?’” (SCHELL,
2011, p. 140). Em outras palavras, as ações significam os verbos
desempenhados em um jogo, como correr, pular, lançar, esconder,
dentre outras. Para o autor, existem dois tipos de ações possíveis: as
operacionais e as resultantes.
As operacionais consistem nas ações mais básicas de um jogador,
como os movimentos básicos das peças em um jogo de xadrez. Já as
resultantes são as ações especiais que podem ser tomadas por um
jogador, como o sacrifício de uma peça em determinada casa para
enganar o adversário – ao comer a peça, o adversário é surpreendido
por outra ação que come também sua peça de maior valor.
• Habilidades
A quarta mecânica – habilidades de um jogador – deve ser
considerada tendo-se em vista que um jogo e suas mecânicas
dependerão dessas habilidades para serem realizados. Schell (2011)
recomenda que desenvolvedores, quando estão projetando um jogo,
façam uma lista das habilidades que deverão, necessariamente, ser
desempenhadas pelo jogador. As habilidades a serem desenvolvidas
podem ser físicas (como força, destreza e coordenação motora),

mentais (como memória, observação e solução de problemas)
ou sociais (como interpretação do que pensa um adversário e
coordenação de equipes de jogadores).
• Probabilidade
A quinta mecânica – a probabilidade – “é parte essencial de um jogo
interessante porque significa incerteza, e incerteza significa surpresas
[...] uma importante fonte de prazer humano e o ingrediente secreto
do divertimento” (SCHELL, 2011, p. 153), isto é, a probabilidade,
quando usada adequadamente em um jogo, significa proporcionar, a
cada partida, uma sequência de acontecimentos diferentes para cada
jogador. Desenvolvedores de jogos devem, entretanto, considerar
a probabilidade com cautela, pois quanto maior a sua presença em
jogos, menor o controle por parte do jogador, o que significa menor
envolvimento por parte deste no jogo.
Finalmente, as regras, segundo Schell (2011, p. 144), consistem
na mecânica mais fundamental de um jogo, pois “definem o espaço,
os objetos, as ações, as consequências das ações, as restrições sobre
as ações e os objetivos. Em outras palavras, tornam possível toda
a mecânica que vimos até agora e adicionam a coisa fundamental
que define um jogo – objetivos”. Resumidamente, as regras são os
elementos que estruturam um jogo, o fazem ser compreensível e
definem ao jogador as ações que devem ser realizadas para ganhar
o jogo, sendo, portanto, o principal elemento norteador. Assim, as
regras de um jogo jamais deverão ser dispensadas, tendo de ser
elaboradas para viabilizar um processo de desenvolvimento de jogos
consistente.
As mecânicas de jogo são os elementos essenciais para a
viabilidade dele. Desenvolvedores de jogos digitais devem pensar
detalhadamente em cada tipo de mecânica, pois todas representam
linhas de código que deverão ser desenvolvidas de modo a viabilizar
cada uma das mecânicas pensadas.
8.2.4. Interfaces em jogos

O projeto de interfaces para jogos segue os mesmos princípios
já abordados anteriormente neste capítulo. Porém, no caso de jogos
digitais, o projeto da interface deve considerar, especificamente,
aspectos relativos ao relacionamento do jogador com o jogo, de
modo que este se envolva com a narrativa contada; e as ações e
demais mecânicas do jogo possam ser adequadamente realizadas.
Segundo Schell (2011, p. 222), “o objetivo de uma interface é
fazer os jogadores sentirem que têm o controle de suas experiências”.
Assim, ela deve ser projetada de modo que o jogador perceba o jogo
como um todo e, ao mesmo tempo, perceba as suas opções de ação
para cada situação apresentada. Ainda de acordo com o autor, um
jogo digital possui dois tipos de interfaces que devem ser projetadas: a
interface física e a interface virtual, descritas a seguir.
Figura 4 – Interface física e interface virtual
Interfaces
Física Virtual
consiste nos elementos físicos consiste em controles e
que podem ser manipulados informações dispostas na
pelo jogador, como um mouse, tela do usuário, como escores
um joystick, um console, dentre (pontuação), botões acionados
outros. pelo mouse, dentre outros.
Schell (2011) sugere, no caso de interfaces físicas, a possibilidade

da utilização de formas de dispositivos que possam transformar
a experiência de jogo em um formato similar ao mundo real,
como dispositivos de toque para realidade virtual. Para o autor, as
informações referentes à interface virtual não podem atrapalhar o
desempenho do jogador no jogo (por exemplo, obstruindo o seu

campo de visão) e, quando possível, a interface pode interagir com
os demais elementos no mundo do jogo (por exemplo, a partir de
uma janela pop-up).
Projetar interfaces, assim, significa considerar que a interação do
jogador com o jogo se dá tanto no ambiente real quanto no virtual.
Desenvolvedores de jogos, ao projetar interfaces, devem considerar
que botões, por exemplo, podem ser apertados tanto em um controle
quanto na tela do jogo, e cada ação proporcionará uma experiência de
jogo diferenciada. Isso vale para movimentação (que pode ser física
ou virtual) ou mesmo para visualização (na tela ou por meio de óculos
de realidade virtual, por exemplo). Enfim, projetar interfaces significa
projetar experiências de jogo.
8.2.5. Documentação
Finalmente, o projeto de um jogo, para viabilizar a comunicação
entre clientes, designers e desenvolvedores, deve contemplar a
elaboração de uma documentação precisa e detalhada. Como
qualquer software, um jogo necessita da documentação de
seus requisitos, componentes e estrutura, de modo que possa
ser desenvolvido e, posteriormente, testado com relação ao
cumprimento de requisitos.
Conforme menciona Schell (2011), existem duas finalidades
importantes para a documentação em jogos: memória e
comunicação. Primeiramente, um documento de design tem a
finalidade de guardar informações a respeito de aspectos relativos
ao jogo, bem como requisitos, de modo que essa informação possa
ser facilmente recuperada pela equipe de desenvolvimento quando
necessário. Depois, um documento adequadamente elaborado
facilita a comunicação entre desenvolvedores, designers e clientes.
O autor também enumera cinco tipos de documentos essenciais
a serem desenvolvidos no caso de jogos: design, programação,
gerenciamento, escrita e jogadores. O primeiro diz respeito aos

detalhamentos relativos ao design de um jogo, contemplando
ideias, mecânicas, personagens, narrativa e interfaces do jogo. O
documento de programação diz respeito aos aspectos técnicos de
desenvolvimento do jogo, como aspectos relativos à programação
e integração da programação com os aspectos artísticos do jogo. O
documento de gerenciamento trata de questões como cronograma,
orçamentação e demais aspectos relativos à gestão do projeto do
jogo. O documento de escrita trata de aspectos como narrativa,
roteiro, tutorial e manual do jogo, ou seja, a parte escrita de um jogo.
Por fim, o documento aos jogadores trata do passo a passo de um
jogo, sendo inclusive um documento interativo – jogadores podem
complementá-lo com dicas, opiniões, dentre outros.
Desenvolver um jogo é, talvez, uma das tarefas mais difíceis,
porém, mais prazerosas na engenharia de software. Além de envolver
a interação com profissionais de diferentes áreas do conhecimento,
contempla o desenvolvimento de um software que não somente
deve funcionar adequadamente, mas deve proporcionar lazer e
diversão a quem o executa. Desenvolver um jogo digital, assim, é
como elaborar uma obra de arte: técnica e estética se combinam para
proporcionar um objeto que fornece uma experiência agradável a
quem interage com ele.
Vídeo
8.3 Projeto de WebApps
e aplicativos móveis
O mercado de desenvolvimento de aplicativos
para dispositivos móveis, bem como de aplicativos
executados via web (WebApps), apresenta-se cada
vez mais promissor para a engenharia de software. A cada dia, cresce o
número de usuários de internet e, consequentemente, de smartphones
e tablets, e as empresas têm investido cada vez mais em serviços

digitais confiáveis para esses públicos.
A seguir, serão detalhadas questões relativas ao projeto de
interfaces para tais aplicativos. Finalmente, serão abordadas questões
relacionadas à estruturação e viabilização desses aplicativos.
8.3.1. Requisitos para o projeto de aplicativos

baseados na web
O projeto de aplicativos baseados na web, incluindo para
dispositivos móveis, deve considerar que a internet é uma
plataforma de comunicação, onde a quantidade de informações e a
velocidade pelas quais essas trafegam de um ponto a outro na rede
constituem elementos essenciais para o adequado desempenho de
um aplicativo. Dessa forma, Pressman e Maxim (2016) elaboraram o
que se denomina Árvore de requisitos de qualidade, a qual detalha os
principais elementos de qualidade que devem estar presentes em um
aplicativo baseado na web. A Figura 5 ilustra esse esquema.
Figura 5 – Árvore de Requisitos de Qualidade

Facilidade de compreensão geral do site
Feedback on-line e recursos de ajuda
Usabilidade Características estéticas e de interface
Características especiais
Capacidade de busca e recuperação
Características de navegação e leitura de documentos
Funcionalidade Características relacionadas ao domínio da aplicação
Qualidade Processamento correto dos links

da aplicação Confiabilidade Recuperação de erros
para Web Validação e recuperação dos dados de entrada dos usuários
Desempenho do tempo da resposta
Eficiência Velocidade de geração de páginas
Velocidade de geração de imagens
Facilidade de correção
Facilidade de Adaptabilidade
manutenção Extensibilidade

Conforme a figura acima, a Árvore de Requisitos de Qualidade

é composta de cinco elementos críticos para o funcionamento de
qualquer sistema baseado na web, sendo que há a necessidade desses
elementos, portanto, estarem presentes em qualquer projeto desse
tipo de sistema.
O primeiro elemento crítico consiste na usabilidade. Visto que o
espaço de navegação de um aplicativo baseado na web geralmente tem
limitações (a tela de um smartphone ou o navegador de internet), é
necessário considerar a presença de elementos estéticos e de interface
balanceados de modo que a navegação, por parte do usuário, seja feita
de maneira funcional e rápida (ou seja, intuitiva – sem a necessidade
de receber instruções adicionais). Além disso, o usuário, ao se deparar
com a tela do aplicativo, deve poder compreender as informações
desta de modo inteligível e saber para onde deve navegar para buscar
outras informações que, porventura, não estejam nela. Finalmente,
o usuário deve poder receber o feedback constante da sua navegação
– por exemplo, ao clicar em um botão ou acionar um comando, o
usuário receber de volta o informe de que acionou esse comando e,
assim, a informação desejada por ele.
O segundo elemento essencial no projeto de um aplicativo
baseado na web é a funcionalidade, a qual consiste em o aplicativo
desempenhar com qualidade as tarefas para as quais foi projetado.
Isso significa, primeiramente, o aplicativo ter a capacidade de busca
e recuperação de informações de maneira segura e íntegra, ou seja,
as informações serem buscadas sem a ocorrência de ruídos ou falhas.
Além disso, deve-se considerar como funcionalidades as formas por
meio das quais o aplicativo disponibiliza as informações ao usuário
e como ele pode interagir com o aplicativo para a satisfação de suas
necessidades.
O terceiro elemento essencial é a confiabilidade. Por estar na
internet, e, portanto, sujeito a ameaças, o aplicativo deve, na medida
do possível, reduzir ou eliminar vulnerabilidades. Além disso, deve
proporcionar a recuperação de links para o usuário de maneira

eficaz e se recuperar adequadamente no caso de incidência de erros.
O quarto elemento essencial em um aplicativo baseado na web é a
eficiência, que significa a velocidade com a qual as informações são
buscadas e disponibilizadas para o usuário. Significa proporcionar,
ao usuário, uma resposta rápida para seus comandos, de modo que
ele possa atingir os seus objetivos com a utilização do software mais
rapidamente.
Finalmente, o quinto elemento essencial é a facilidade de
manutenção. A internet é uma plataforma de dados em constante
mutação, com novas tecnologias, protocolos, e linguagens de
programação surgindo a todo instante. O aplicativo deve poder ser
modificado, corrigido e atualizado rapidamente, sem que haja a
ocorrência de defeitos futuros.
Assim, desenvolver um aplicativo para internet requer pensar,
basicamente, em proporcionar ao usuário uma comunicação rápida,
acessível e intuitiva. O usuário tem um objetivo definido ao acessar
um aplicativo, o qual deve proporcionar uma resposta rápida às suas
necessidades, exigindo do usuário de um aprendizado mínimo.
8.3.2. Projeto de interfaces para aplicativos móveis

O projeto de interfaces para aplicativos móveis segue os mesmos
princípios expostos neste capítulo para o desenvolvimento de
interfaces. Porém, visto que aplicativos móveis demandam rápido
acesso por parte do usuário e rápida disponibilização de informações,
segundo Pressman e Maxim (2016), alguns elementos adicionais
devem ser considerados para o desenvolvimento de interfaces:
1. Princípio da antecipação: “uma aplicação deve ser projetada
para prever o próximo passo do usuário” (PRESSMAN; MAXIM,
2016, p. 338, grifos do original), ou seja, aplicações de internet
devem ser desenvolvidas tendo em vista enfatizar, na interface, as
funcionalidades mais básicas ou de uso mais frequentes.
2. Princípio da comunicação: “a interface deve comunicar o

estado de qualquer atividade iniciada pelo usuário” (PRESSMAN;
MAXIM, 2016, p. 338, grifos do original), ou seja, o usuário deve
ser comunicado e entender em qual parte da interface se encontra.
3. Princípio da consistência: “o uso de controles de navegação,
menus, ícones e estética deve ser consistente” (PRESSMAN; MAXIM,
2016, p. 338, grifos do original). Assim, a quantidade desses itens
deve ser suficiente para a compreensão por parte do usuário da
interface, não sendo essa quantidade excessiva.
4. Princípio da autonomia controlada: “a interface deve facilitar
a movimentação do usuário pela aplicação, mas deve fazê-lo de
modo que faça valer as convenções de navegação estabelecidas para a
aplicação” (PRESSMAN; MAXIM, 2016, p. 338, grifos do original).
Dessa forma, a navegação do usuário deve ser precisa e fácil, porém
seguindo as regras de design convencionadas para o aplicativo.
5. Princípio da eficiência: “o projeto de uma aplicação e sua
interface deve otimizar a eficiência de trabalho do usuário, não a
eficiência do desenvolvedor que a projeta e constrói ou o ambiente
cliente/servidor que a executa” (PRESSMAN; MAXIM, 2016, p. 338,
grifos do original). Nesse caso, o foco no desenvolvimento de uma
interface é o usuário, e o desenvolvedor deve, no momento de projetá-
la, pensar nas necessidades e características desse usuário.
6. Princípio da flexibilidade: “a interface deve ser flexível
o bastante para permitir que alguns usuários cumpram tarefas
diretamente, ao passo que outros devem explorar a aplicação de
maneira um tanto aleatória” (PRESSMAN; MAXIM, 2016, p. 338,
grifos do original), ou seja, a interface deve proporcionar ao usuário
uma navegação, ao mesmo tempo, precisa e exploratória. Quem
deseja realizar tarefas deve encontrar precisão e facilidade. Quem
deseja explorar as funcionalidades do aplicativo, deve encontrar
opções para tal.
7. Princípio do foco: “a interface (e o conteúdo apresentado) deve

permanecer focado na tarefa do usuário em questão” (PRESSMAN;
MAXIM, 2016, p. 338, grifos do original), ou seja, a tarefa de um
aplicativo deverá ser prontamente atendida.
8. Princípio da redução da latência: “em vez de fazer com que o
usuário espere por alguma operação interna completar (por exemplo,
baixar uma imagem complexa), a aplicação deve usar multitarefas de
uma forma que deixe o usuário prosseguir com seu trabalho como se
a operação tivesse sido completada” (PRESSMAN; MAXIM, 2016,
p. 339, grifos do original). Na internet, é comum a realização de
multitarefas, e um aplicativo deve possibilitar que o usuário as
realize enquanto este aplicativo se encontrar ocupado realizando
outra tarefa.
9. Princípio da facilidade de aprendizagem: “a interface deve
enfatizar um projeto simples e intuitivo que organiza conteúdo e
funcionalidades em categorias óbvias para o usuário” (PRESSMAN;
MAXIM, 2016, p. 339, grifos do original). Assim, simplicidade é
característica essencial em interfaces para internet, principalmente
em aplicativos para dispositivos móveis, em que o tamanho das telas
tende a ser menor.
10. Princípio da legibilidade: “o projetista de interfaces deve
dar prioridade aos estilos de tipos e tamanhos de fontes controláveis
pelo usuário e fundos coloridos que aumentam o contraste”
(PRESSMAN; MAXIM, 2016, p. 339). Uma interface, antes de
operada, deve ser percebida pelo usuário, essa percepção também
deve ser rápida e objetiva, razão pela qual o uso de fontes e cores
deve ser planejado com cautela.
11. Princípio de acompanhar o estado da interação: “quando
apropriado, o estado de interação de usuário deve ser acompanhado e
armazenado de modo que um usuário possa sair do sistema e retornar
mais tarde, prosseguindo do ponto onde parou” (PRESSMAN;
MAXIM, 2016, p. 339, grifos do original). Isso demonstra eficiência
por parte do software, pois este facilita ao usuário o cumprimento de

suas tarefas e seus objetivos.
12. Princípio da navegação visível: uma interface deve
proporcionar ao usuário praticidade na navegação, não forçando-o
a ler grandes quantidades de texto, não dependendo de funções
do navegador de internet para auxiliar na navegação da página (as
funções devem estar na própria interface ou página de internet),
dentre outras.
Assim, projetar interfaces para aplicativos web significa, antes
de tudo, pensar no usuário que fará o seu uso. A disposição das
informações, layout, botões, links, dentre outros elementos em uma
interface deve considerar, além dos princípios básicos descritos
acima, as características cognitivas do usuário que realizará o uso
dessa interface.
Conforme estudamos nesse capítulo, as possibilidades de atuação
de um engenheiro de software são diversas, indo além do simples
desenvolvimento de software. O fato de cada vez mais pessoas
utilizarem dispositivos móveis, acessarem a internet e jogarem
proporciona ao engenheiro de software oportunidades de atuação
promissoras, fazendo com que esse profissional seja cada vez mais
requisitado pelas empresas para o desenvolvimento de soluções de
comunicação e interação com pessoas.
Soma-se a isso o fato de o engenheiro de software cada vez
mais precisar interagir com profissionais de diferentes áreas do
conhecimento. Seja para o desenvolvimento de interfaces, jogos ou
aplicativos móveis, a capacidade de se comunicar efetivamente com
designers, artistas, produtores e outros profissionais torna-se, assim,
uma competência essencial para esse profissional.
Dessa forma, ser um engenheiro de software, atualmente, está

além de lidar com algoritmos, estruturas de dados ou UML, é saber
como as pessoas agem e se comportam quando utilizam um software,
bem como quais emoções e reações são despertadas por meio dessa
utilização, ou seja, é conhecer e saber lidar com o ser humano.

• MATTHES, E. Curso intensivo de Python: uma introdução
prática e baseada em objetos à programação. São Paulo:
Novatec, 2016.
Esse livro trata da linguagem Python, uma das mais utilizadas
para a programação de jogos e aplicativos web, com exemplos
e passo a passo de como construir um jogo ou aplicativo.
• SCHUYTEMA, P. Design de games: uma abordagem prática.

São Paulo: Cengage Learning, 2011.
Esse livro ensina, didaticamente, os principais elementos que
compõem um jogo eletrônico, além de abordar a programação
de um jogo com o uso da linguagem de programação Lua.
Atividades
1. Projete um jogo com base em um conto literário, um filme
ou uma outra obra de sua escolha. Para isso, lembre-se de
considerar todos os elementos estudados neste capítulo, como
narrativa, personagens, mecânicas, cenários, dentre outros.
2. Escolha uma atividade qualquer do seu dia a dia, que você

realize no trabalho ou em casa, por exemplo. Depois, esboce
um storyboard para essa tarefa, detalhando o passo a passo
da sua execução.
3. Escolha e utilize um aplicativo móvel ou um webapp de sua
preferência. Depois, escreva seus elementos com base na
Árvore de Requisitos de Qualidade.
Referências
AGÊNCIA BRASIL. Mercado de games no Brasil deve crescer 5,3% até
2022, diz estudo. Exame, São Paulo, 3 ago. 2019. Disponível em: https://
exame.abril.com.br/negocios/mercado-de-games-no-brasil-deve-crescer-
53-ate-2022-diz-estudo/. Acesso em: 12 dez. 2019.
PREECE, J.; ROGERS, Y.; SHARP, H. Design de interação: além da interação

homem-computador. Porto Alegre: Bookman, 2005.

SCHELL, J. A arte de game design: o livro original. Rio de Janeiro: Elsevier,

2011.
Gabarito
1 Introdução à engenharia de software

1. Esta é resposta uma pessoal. A pesquisa pode ser realizada em
websites de emprego, procurando pelo cargo de engenheiro
de software.
2. Os quatro fatores essenciais para o gerenciamento de equipes

de trabalho em engenharia de software são: consistência,
inclusão, honestidade e respeito.
A consistência refere-se à valorização consistente ou
igualitária de cada membro da equipe de desenvolvimento.
A inclusão diz respeito à aceitação do membro da equipe
como igual, principalmente no tocante à proposição e
aceitação de propostas. A honestidade está atrelada ao
engenheiro ser honesto com relação às suas competências,
não subvalorizando ou supervalorizando-as. O respeito, por
sua vez, consiste em considerar as diferenças do outro sem
conclusões precipitadas ou preconceituosas.
3. A engenharia de requisitos permite a verificação dos

requisitos funcionais e não funcionais que devem ser
respeitados durante o desenvolvimento de software, de modo
que o produto final atenda às necessidades do usuário.
2 Planejamento e processo de software

1. O scrum master é o responsável pela gestão do projeto e pela
garantia dos valores do scrum durante o trabalho da equipe
de desenvolvimento. O product owner é o representante das
partes interessadas do projeto (por exemplo, clientes); e o

development team, como o próprio nome sugere, consiste em
pessoas responsáveis pelo desenvolvimento e pela construção
do sistema usando o modelo scrum.
2. O Industrial XP é um modelo variante do Extreme

Programming e integra novas práticas voltadas a organizações
de grande porte, como: avaliação imediata, comunidade de
projeto, mapeamento do projeto, gerenciamento orientado a
testes, retrospectivas e aprendizagem contínua.
3. Os 12 princípios do software ágil são:
a) A maior prioridade é satisfazer o cliente por meio da

entrega adiantada e contínua de software de valor.
b) Aceitar mudanças de requisitos, mesmo no fim do
desenvolvimento, visto que processos ágeis se adequam
às mudanças, para que o cliente possa tirar vantagens
competitivas.
c) Entregar software funcionando com frequência, na escala
de semanas até meses, com preferência aos períodos mais
curtos.
d) Pessoas relacionadas a negócios e desenvolvedores devem
trabalhar em conjunto e diariamente, durante todo o
curso do projeto.
e) Construir projetos ao redor de indivíduos motivados,
proporcionando a eles o ambiente e suporte necessário, e
confiar que farão seu trabalho.
f) O método mais eficiente e eficaz de transmitir
informações, por dentro de um time de desenvolvimento,
é por meio de uma conversa cara a cara.
g) Software funcional é a medida primária de progresso.
h) Processos ágeis promovem um ambiente sustentável.
Gabarito 177
Os patrocinadores, desenvolvedores e usuários

devem ser capazes de manter indefinidamente passos
constantes.
i) Contínua atenção à excelência técnica e bom design
aumentam a agilidade.
j) Simplicidade: a arte de maximizar a quantidade de
trabalho que não precisou ser feito.
k) As melhores arquiteturas, requisitos e designs emergem
de times auto-organizáveis.
l) Em intervalos regulares, o time reflete em como ficar mais
efetivo; então, se ajusta e otimiza seu comportamento.
3 Engenharia de requisitos
1. Para o software escolhido, você deverá definir, no mínimo,
três requisitos funcionais e três não funcionais.
Os requisitos funcionais dizem respeito à funcionalidade do

software, como em um sistema financeiro:
• O sistema da minha empresa deve emitir notas fiscais
com as informações necessárias e calcular os impostos
conforme a legislação;
• O sistema deve possibilitar a inserção de códigos de barras
(QR-Codes) nos documentos;
• O sistema deve possibilitar o envio da Nota Fiscal
Eletrônica (NF-e), por via on-line, aos órgãos competentes.
Já os requisitos não funcionais dizem respeito aos aspectos
como qualidade, capacidade, segurança e desempenho, como
nesse mesmo sistema financeiro:
• O sistema da minha empresa deve ser compatível com um
computador da marca “X”.
• O sistema deve processar “X” transações por segundo e
permitir acesso simultâneo a “Y” usuários.
• O sistema deve permitir acesso somente a quem tenha

uma chave de segurança específica.
2. Você deve seguir os passos do exercício, aplicando, assim,
a técnica de etnografia. Com isso, deverá descrever três
requisitos funcionais e três não funcionais para o aplicativo
que você baixou e solicitou a outra pessoa que o utilizasse.
Exemplos de requisitos funcionais de um aplicativo de troca
de mensagens, vídeo e imagens:
• Permitir a digitação de mensagens para um destinatário.

• Permitir a formação de grupos de conversa.
• Permitir a transmissão e a visualização de vídeo e som.
Exemplos de requisitos não funcionais para esse mesmo
aplicativo:
• Não permitir a instalação em mais de um dispositivo
móvel.
• Realizar verificação via SMS quando há a instalação em
outro dispositivo.
• Possibilitar uma taxa mínima de transferência de “X”
KB/s.
3. Você deverá elaborar um modelo de especificação de
requisitos de software para o jogo escolhido, com base na
estrutura descrita no item 3.3. Por exemplo, imagine que
você escolheu desenvolver uma evolução do jogo Pac-Man.
Alguns requisitos para esse jogo poderiam ser os seguintes:
• possibilitar a seleção de diferentes cores para o labirinto,

os fantasmas e o personagem principal (Pac-Man) –
requisito funcional;
• possibilitar responsividade para telas de tablet, smartphone
e computadores – requisito não funcional;
• possibilitar jogos com múltiplos jogadores em um mesmo
labirinto – requisito funcional;
Gabarito 179
• Possibilitar a escolha do formato das pastilhas que o

Pac‑Man come, por exemplo: balas, frutas, dentre outros
– requisito funcional.
4 Modelagem de software com a UML

1. Você deverá elaborar um diagrama de caso de uso para o
aplicativo que você escolheu. Lembre-se de representar os
atores e os casos de uso no formato de frases curtas (por
exemplo: “Emitir Saldo Bancário”, “Finalizar Reserva”,
“Escolher Produto”, “Esvaziar Carrinho”). O exemplo a
seguir é de um diagrama de casos de uso para um sistema de
empréstimo de livros em uma biblioteca.
Apresenta o livro Consulta a situação

para empréstimo do livro (emprestado
ou não)
Digita a senha Consulta se o livro

já tem empréstimo
agendado
USUÁRIO ATENDENTE DA
BIBLIOTECA
Digita o número
da carteirinha da Consulta se o livro
biblioteca já tem empréstimo
agendado
2. Você deverá desenhar um diagrama de atividades

contemplando o passo a passo da utilização do aplicativo
escolhido. Não se esqueça de representar cada passo da
utilização do aplicativo, bem como atividades que possam
ocorrer em paralelo ou sob condições. O exemplo a seguir
é de um diagrama de atividades simplificado para um
aplicativo de solicitação de delivery de comida:
INÍCIO
Apresentar opções de
cardápio Apresentar promoções
Selecionar pedido
Selecionar forma de
pagamento
Cartão de crédito ou
Dinheiro débito
Coletar a senha do
cliente
Informar número
do pedido
FIM
Gabarito 181
3. Você deverá elaborar um diagrama de caso de uso, e um

diagrama de atividades, para esse aplicativo de reservas.
Lembre-se de usar frases como “Escolher Origem”, “Escolher
Destino”, “Visualizar Destino”, “Finalizar Reserva”, “Realizar
Pagamento”. Os exemplos de diagramas encontram-se
dispostos a seguir.
Escolher origem
Mostrar destinos
Escolher destino Mostrar preço de

hotel
SISTEMA
Selecionar datas
USUÁRIO de início e fim da Mostrar preço de
viagem passagem aérea
Selecionar
destino Finalizar reserva
Confirmar
reserva
Cliente seleciona
origem e destino
Cliente seleciona datas de

início e fim da viagem
Sistema mostra Sistema mostra

opções de hotel opções de voos
Cliente escolhe
Cliente escolhe opções de voos de ida
opção de hotel e volta
Cliente escolhe opção

de pagamento
Sistema coleta registros

de pagamento
Sistema confirma a
reserva para o cliente
FIM
5 Modelagem de software com a UML

1. Você deverá montar a EAP desse jantar contemplando
as principais entregas e subentregas a serem realizadas,
conforme exemplo a seguir.
Gabarito 183
1. JANTAR
1.1. Aperitivos 1.2. Prato Principal 1.3. Sobremesa
1.1.1. Amendoim 1.2.1. Prato principal 1.3.1. Compotas

elaborado com nata
1.1.2. Torradas e patê 1.2.2. Prato principal 1.3.2. Licor

pronto
1.1.3. Bebidas 1.2.3. Prato principal

servido
De acordo com o exemplo, as entregas dizem respeito aos

aperitivos, ao prato principal e à sobremesa, que representam
os três grupos principais de elementos presentes em um
jantar. Cada entrega possui suas subentregas, isto é, partes
da entrega principal. Ao se cumprir as subentregas de cada
grupo, cumpre-se necessariamente cada entrega principal
e, ao se cumprir as entregas, cumpre-se o projeto como um
todo, ou seja, o jantar.
2. Algumas das aplicações atuais do método MVC que podem

ser citadas são: aplicações web, desenvolvimento de jogos,
aplicativos móveis e software corporativo.
3. O desenvolvimento de software pode acarretar vários riscos,

como o não cumprimento dos requisitos, as mudanças nos
requisitos, o surgimento de custos imprevistos, a necessidade
de substituição de recursos humanos (e com essa substituição
a fuga de conhecimentos) e alterações no escopo do projeto
durante a sua execução.
6 Gestão da qualidade em engenharia de

software
1. Os principais processos da norma ISO/IEC 12207 são os
seguintes:
• Fundamentais: processos principais que devem ser

considerados no desenvolvimento de software, consistindo
em: aquisição, fornecimento, desenvolvimento, operação e
manutenção.
• De apoio: processos gerais para a garantia da qualidade, como
verificação, validação, usabilidade e auditoria.
• Organizacionais: processos de gestão do desenvolvimento de
software, como gerência, recursos humanos, infraestrutura e
melhoria.
• De adaptação: processos para adaptação do software à
organização, cultura organizacional, dentre outros.
2. Alguns dos principais fatores de qualidade a serem

considerados no desenvolvimento desse software são:
• Eficiência: o software de automação do braço robótico

deve apresentar recursos computacionais suficientes
para a operação do equipamento. O excesso de recursos
computacionais pode prejudicar o desempenho do braço
mecânico, tendo em vista que, em uma fábrica, os processos
ocorrem de modo muito dinâmico.
• Portabilidade: o software deve poder ser instalado e replicado
em vários braços robóticos conforme necessário.
• Interoperabilidade: o software deve possibilitar a integração
do braço robótico com os demais sistemas da organização
(por exemplo, sistemas de controle produtivo, sistemas ERP,
dentre outros).
Gabarito 185
3. Alguns dos aspectos de garantia a serem considerados são:
• Educação da equipe de desenvolvimento: por envolver

elevada complexidade (automação, eletrônica, mecânica etc.),
a capacitação da equipe de desenvolvimento do software, com
relação à forma de funcionamento de um braço robótico, é
fundamental para que ele atenda aos requisitos de operação
dessa ferramenta.
• Gerenciamento de fornecedores: por se tratar de um projeto
de elevada complexidade, é possível que haja a necessidade
de serviços terceirizados de desenvolvimento de software – a
qualidade desses serviços deverá ser auditada de modo que
os produtos de software fornecidos estejam de acordo com os
requisitos do sistema como um todo.
• Revisões constantes nos códigos: por se tratar de um
produto de elevada complexidade, o software de automação
do braço robótico deve ser constantemente revisado em busca
de solucionar possíveis erros.
7 Testes e engenharia reversa em software

1. Em um website, pode haver defeitos de algoritmo, capacidade
e recuperação (ele pode apresentar, por exemplo, defeitos de
processamento de informações). Já um serviço de internet
que armazene dados de clientes pode apresentar defeitos de
capacidade (ou seja, estar localizado em um servidor de tamanho
inadequado, que não suporta uma grande quantidade de acessos
simultâneos). Ainda, pode apresentar defeitos de recuperação
(como no caso de um ataque hacker, não retornando ao ar de
maneira apropriada).
2. Você pode desenvolver um código na linguagem de sua

preferência (como em Python, Java ou outro) e realizar
um Teste de Unidade. Você pode escolher um aplicativo
ou página de internet e elaborar um roteiro de testes. Por

exemplo, um jogo on-line, o qual você pode testar em
diferentes plataformas (smartphone, tablet, computador de
mesa etc.), além de tentar diferentes formas de jogar, testar
cliques na tela em diferentes locais, dentre outros.
3. Um exemplo de reengenharia de aplicativos é o Telegram, um

aplicativo de conversação com funcionalidades similares ao
Whatsapp, como a troca de mensagens com emoticons. Outro
exemplo são os buscadores de internet, como Google, Yahoo
e Baidu, os quais, embora cada um com suas particularidades,
atendem a um propósito de maneira similar.
8 Práticas de engenharia de software

1. Uma sugestão de jogo pode ser com base no conto Chapeuzinho
Vermelho. Como elementos pode-se considerar que a trilha
sonora seja, por exemplo, uma música clássica; os cenários
podem ser a casa da vovó da Chapeuzinho Vermelho e a floresta
por onde ela caminha; e o jogador pode escolher jogar com a
Chapeuzinho Vermelho ou com o Lobo Mau. Na primeira
opção (jogando como Chapeuzinho Vermelho), a missão
pode ser chegar, com segurança, à casa da vovó, passando
por obstáculos como bichos, borboletas e coelhos (correndo,
pulando, agachando-se) e, chegando lá, enfrentar o lobo mau.
Na segunda opção (jogando como Lobo Mau), o jogador deve
montar armadilhas na floresta para a Chapeuzinho Vermelho e,
no caso de falha, tentar enganá-la passando-se pela vovó.
2. Você deverá escolher uma atividade qualquer do seu dia a dia e

elaborar um storyboard, descrevendo, graficamente e em formato
de texto, como essa atividade é desempenhada. Um exemplo de
storyboard se encontra na figura a seguir, que representa uma ida
à academia por parte de um usuário desse serviço.
Gabarito 187
O usuário passa pela catraca de entrada da O usuário realiza 1h de corrida na esteira.

academia e guarda seus pertences.
O usuário realiza exercícios de musculação. Após os exercícios, o usuário toma banho e vai
para casa.
3. Árvore de Requisitos de Qualidade do Whatsapp.
Usabilidade Fácil acesso aos

contatos
Funcionalidade Conversas via chat e

Qualidade de imagens
aplicação do
Whatsapp
Garantia de entrega e
Confiabilidade confirmação de leitura
da mensagem
Eficiência Troca de mensagens de

modo rápido e eficaz
Para o Whatsapp, por exemplo, um elemento de usabilidade

é a capacidade de o aplicativo proporcionar fácil acesso aos
contatos – bastando apertar apenas um botão – e, após a
escolha de um contato, abrir uma tela para iniciarmos uma
conversa. Com relação à funcionalidade, o aplicativo tem

como propósito possibilitar a conversa via chat ou por meio de
troca de imagens com um contato ou com grupos de pessoas.
Em termos de confiabilidade, o esse aplicativo garante que a
mensagem seja entregue para o usuário, que, caso deseje, saiba
se foi lida e está sendo respondida. No que trata da eficiência,
ele permite a troca de mensagens por várias pessoas e grupos
de modo rápido e eficaz, inclusive devido ao fato de que as
mensagens, geralmente textos, ocupam pouco espaço na
memória. Finalmente, a respeito da facilidade de manutenção,
por sua simplicidade de funções, o Whatsapp permite a
elaboração de atualizações em um prazo curto de tempo.
E NGENHARIA
DE
SOFTWARE
THIAGO SCHAEDLER UHLMANN
Código Logístico Fundação Biblioteca Nacional
ISBN 978-85-387-6552-3
59009 9 788538 765523

Engenharia de Software

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Engenharia de Software

Enviado por

Direitos autorais:

Formatos disponíveis

Engenharia de Software

59009 9 788538 765523

Thiago Schaedler Uhlmann

Capa: IESDE BRASIL S/A.

CIP-BRASIL. CATALOGAÇÃO NA PUBLICAÇÃO

1. Engenharia de software. 2. Software - Desenvolvimento. I.

Todos os direitos reservados.

1. Introdução à engenharia de software 9

1.2 A prática da engenharia de software 13

1.3 O engenheiro de software e outros profissionais 17

2. Planejamento e processo de software 23

2.2 Modelos tradicionais de desenvolvimento 25

2.3 Modelos ágeis de desenvolvimento 33

3.2 Classificação de requisitos 48

3.3 Especificação e apresentação de requisitos 52

4. Modelagem de software com a UML 59

4.2 Diagramas comportamentais 67

4.3 Diagramas estruturais 75

5. Gestão de projetos de software 83

5.2 Projeto de software: elementos acessórios 89

5.3 Projetos de arquiteturas de software 94

6.2 Qualidade em software 108

6.3 Melhorias em software 114

7. Testes e engenharia reversa em software 123

7.2 Realização de testes 132

7.3 Manutenções e reengenharia 140

8. Práticas de engenharia de software 147

8.2 Jogos digitais 157

8.3 Projeto de WebApps e aplicativos móveis 167

As tecnologias da informação e comunicação estão

Embora tenhamos familiaridade com esses dispositivos,

Desse modo, a engenharia de software é uma área do

O objetivo principal desta obra é apresentar a você,

Nos capítulos seguintes, trataremos de temas essenciais,

Neste capítulo, você estudará o perfil do engenheiro de software

Vídeo 1.1 Quem é o engenheiro de

Resumidamente, o engenheiro de software é o

A definição de engenharia de software sofre pequenas variações

O engenheiro de software deve, portanto, “fornecer aos

Figura 1 – O engenheiro de software é requisitado por organizações

A atividade do engenheiro de software está sendo regulamentada

Vídeo 1.2 A prática da engenharia de

de engenharia de software manter-se constantemente atualizado a

Figura 2 – O engenheiro de software é um profissional de inovação e

O engenheiro de software, como todo engenheiro, é especialista

telas, botões, menus, compatibilidade com sistemas operacionais

Recomenda-se, nessa fase, o uso de técnicas de desenvolvimento

se ater a princípios éticos, de modo que os resultados do trabalho

Vídeo 1.3 O engenheiro de software

equipes de trabalho, uma vez que a comunicação entre os membros,

A inclusão é derivada da consistência. Uma vez que o trabalho

Por fim, pudemos entender, também, que o engenheiro de

Ampliando seus conhecimentos

• CONFEA – Conselho Federal de Engenharia e Agronomia.

2. Cite e descreva os quatro fatores essenciais para o

3. Um dos processos essenciais na engenharia de software

PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software: uma abordagem

SCHACH, S. Engenharia de software: os paradigmas clássico e orientado a

SOMMERVILLE, I. Engenharia de software. São Paulo: Pearson Prentice

WAZLAWICK, R. S. Engenharia de software: conceitos e práticas. Rio de

Agora que sabemos o que faz um engenheiro de software, os

2.1 Estrutura básica do

O mesmo ocorre com o desenvolvimento de um software, pois

são integradas no formato de um sistema completo, o qual também