0 MA Elemento Textual - Engenharia de software

Prévia do material em texto

ENGENHARIA DE SOFTWARE 
Silvio Bogsan 
 
 
 
 
 
 
 
 
 
, 
 
 
2 
 
 
SUMÁRIO 
 
1 NATUREZA E ENGENHARIA DE SOFTWARE .............................................. 3 
2 PROCESSO DE DESENVOLVIMENTO DE SOFTWARE ............................... 15 
3 ENGENHARIA DE SOFTWARE E MODELAGEM ........................................ 28 
4 REQUISITOS DE SOFTWARE ................................................................... 42 
5 GESTÃO DE QUALIDADE DE SOFTWARE ................................................ 55 
6 TÓPICOS AVANÇADOS EM ENGENHARIA DE SOFTWARE ....................... 66 
 
 
, 
 
 
3 
 
 
1 NATUREZA E ENGENHARIA DE SOFTWARE 
Apresentação 
Este bloco tem como principal objetivo contextualizar a disciplina Engenharia de 
Software e pavimentar os conceitos mais importantes relacionados ao Software. 
Vamos definir o que é Software, o que é Engenharia de Software e quais suas 
principais aplicações. Também vamos entender o cenário do desenvolvimento de 
software, as diferentes classes de software, que formas de executar os softwares e 
como nós, humanos, interagimos com eles. Vamos contextualizar a Arquitetura de 
Software e estabelecer a diferença entre a Arquitetura e a Engenharia de Software. 
1.1 Natureza e Engenharia de Software 
Talvez você não saiba disso, mas “computador” já foi uma profissão, feita por uma 
pessoa, um ser humano. Talvez hoje chamaríamos essa pessoa de Contador, uma 
pessoa que faz contas. Contudo, o contador moderno faz mais do que contas. Essa 
profissão de computador se tornou extinta quando surgiu o software. Assim como a 
profissão de “acendedor de lampião” ficou extinta quando surgiu a luz elétrica nas 
ruas. 
Se seu carro lhe diz que você se esqueceu de colocar o cinto de segurança, ou que está 
na hora de trocar o óleo, é graças ao software. Seu celular lhe despertou de manhã? É 
ação do software. Seu micro-ondas preparou pipoca? Mais uma vez, há a presença do 
software. Seu fone de ouvido neutralizou ruídos externos? Software. Mandou aquela 
planilha para seu chefe por e-mail? Software e software. A vida hoje é baseada em 
software. Seja para comprar comida ou para pedir uma carona, se comunicar com as 
pessoas, ler, estudar. Você não estaria lendo este texto se não fosse por diferentes 
softwares usados na preparação desta apostila, armazenamento, transmissão e 
apresentação no seu dispositivo, seja um celular ou tela de computador. 
Software é o conjunto de instruções usado para fazer com que máquinas e dispositivos 
variados executem uma determinada rotina. Quando você liga seu celular, um 
, 
 
 
4 
 
software pré-gravado faz com que o sistema operacional seja carregado e comece a 
executar. Esse software controla tudo que seu celular faz. Inclusive executa todos os 
seus pedidos. Seja mandar uma mensagem, seja tocar uma música. Cada aplicativo 
baixado no seu celular é um software diferente. Calculadora, mensagens, fotos. 
Normalmente, o produto final que um software produz é informação. O software 
normalmente transforma uma informação recebida em outra informação desejada. 
Ao pisar no freio, o sistema ABS recebe como informação a força que foi aplicada no 
pedal, a velocidade que a roda está girando e então calcula quanto dessa força deve 
ser devolvida para o pedal, evitando assim o travamento da roda e a derrapagem 
resultante, o que diminui consideravelmente a chance de acidente. Quando você abre 
o aplicativo de câmera do seu celular, o sensor CCD é ativado e na tela aparece o que a 
lente do seu celular está captando e um botão é colocado na tela para que você 
escolha o que quer capturar e em que momento, e essa informação é salva na forma 
de um arquivo digital na memória do dispositivo. É possível fazer o mesmo num jogo 
no videogame, num website na Internet, no caixa eletrônico. 
A complexidade do desenvolvimento de software fez surgir uma disciplina para lidar 
com essa complexidade: a Engenharia de Software. Você a essa altura deve estar se 
perguntando o que engenharia tem a ver com software. Engenharia tem a ver com 
ferramentas e técnicas para lidar com coisas complexas. O desenvolvimento de 
software é bastante complexo. Daí, precisamos de ferramental e de técnicas para 
transformar essa complexidade em coisas mais simples, que podemos fazer de forma 
mais fácil, mais eficiente. 
Você nunca parou para pensar em como é complexo construir uma estação de metrô? 
Ou um prédio de 30 andares? Uma ponte sobre um rio? 
1.2 Software e Classes de Software 
Acreditamos que você agora está dentro do contexto do que seja software e qual seja 
o propósito desta disciplina. Então, vamos ver algumas definições do que é software. 
Software é o objeto de estudo que nos interessa aqui, então temos que compreender 
esse conceito. 
, 
 
 
5 
 
Segundo o dicionário do Google, a primeira definição de Software é “conjunto de 
componentes lógicos de um computador ou sistema de processamento de dados”. [1] 
Mas o que significa isso exatamente? Dentro do processador, existe um conjunto 
variado de componentes lógicos, lidando com informações binárias e que podem ser 
combinados de várias formas para executarem as operações mais complexas de que 
precisamos. Por exemplo, matematicamente, 2 x 3 é igual a 2 + 2 + 2, então, 
poderíamos combinar circuitos lógicos de soma para fazer uma multiplicação. Era 
assim que os primeiros computadores funcionavam. Hoje em dia, nos processadores 
modernos, existem milhares de conjuntos lógicos disponíveis. Quando escrevemos um 
software, usamos diferentes combinações desses componentes lógicos. 
Já segundo outro dicionário, o Michaelis, Software é “Qualquer programa ou grupo de 
programas que instrui o hardware sobre a maneira como ele deve executar uma 
tarefa, inclusive sistemas operacionais, processadores de texto e programas de 
aplicação”. [2] Essa definição nos diz exatamente o que faz o software. Quando 
apertamos o botão “Pipoca” do micro-ondas, está programado quanto tempo e quanta 
potência o aparelho vai usar para preparar sua pipoca. Se apertarmos o botão 
“Frango”, a programação será diferente. 
Uma definição pensada na Engenharia de Software vem de Pressman e Maxim [4]: 
Software consiste em: (1) instruções (programas de computador) que, 
quando executadas, fornecem características, funções e desempenho 
desejados; (2) estruturas de dados que possibilitam aos programas 
manipular informações adequadamente; e (3) informação descritiva, 
tanto na forma impressa quanto na virtual, descrevendo a operação e o 
uso dos programas. 
Perceba que aqui está incluída a estrutura de dados para dar ao software condições de 
produzir informações desejadas por nós, humanos, para manipular informações 
adequadamente através de funções e desempenho desejados. O que garante que essa 
manipulação está bem feita? Que os critérios foram seguidos? Sim, claro, a Engenharia 
de Software. Hoje em dia, o desenvolvimento de software é bem complexo. 
, 
 
 
6 
 
E uma definição mais ampla é feita por Fernandes [3], em seu artigo “Qual a prática do 
desenvolvimento de software?” e diz que: 
O termo “programa” significa o programa original e todas as cópias 
completas ou parciais do mesmo. Um programa consiste em instruções 
legíveis por máquina, seus componentes, dados, conteúdo audiovisual (tal 
como imagens, texto, gravações ou figuras) e materiais licenciados 
relacionados. [Licença de software da IBM apud Fernandes] 
Conforme esta definição, em geral adotada pela indústria de software, um 
software é mais do que as instruções interpretáveis por uma máquina. 
Digno de nota é a indicação de que conteúdo audiovisual (tal como imagens, 
texto, gravações ou figuras) também é parte do software ‒ este aspecto 
extrapola o conceito de software inicialmente apresentado como meta-
máquina, à medida que torna explícito o fato de que qualquer material 
escrito, impresso, apresentável em qualquer mídia de comunicação,de 
natureza textual, gráfica, audível etc., que tem por objetivo descrever algo 
para o usuário ou sua máquina, também é parte do software. 
As telas, os sons, a embalagem, os manuais. Tudo isso é parte integrante do software. 
É claro que nesta disciplina não vamos falar nisso, mas um projeto de software hoje 
em dia precisa considerar a parte comercial também. E hoje é muito mais comum o 
download feito direto no dispositivo a partir da “lojinha” e o manual é on-line e não 
físico, mas precisamos entender que fazem parte do software num sentido amplo. 
Agora, software é um conceito que deve ter ficado mais claro, mas ainda temos que 
ver as categorias de software para definir melhor o conceito. Segundo a TechNet[5], 
base de dados da Microsoft, a maior empresa de Software do mundo, a AIS 
(Association for Information Systems) usa 8 grandes categorias e 40 categorias 
menores para organizar inventário de software. Isso dá uma ideia da grandeza e da 
complexidade quando falamos em classificar os softwares. Pressman e Maxim [4] 
apresenta uma lista com 7 grandes categorias. Então, vamos fazer uma coletânea 
dessas diferentes classificações e apresentar aqui um resumo: 
 Software Básico: é aquele usado para funções mais operacionais e ligadas ao 
funcionamento do hardware. É o caso do sistema operacional do seu celular, 
, 
 
 
7 
 
por exemplo. Também aqui entram os utilitários como os antivírus, por 
exemplo, e os drivers, que fazem os dispositivos funcionarem adequadamente. 
 Software de Produtividade: aquele que permite a você fazer coisas do dia a dia 
como mandar um e-mail, navegar na Internet, digitar textos, fazer 
apresentações, mandar mensagens e montar uma planilha de gastos. 
 Software de Operações Comerciais: este grupo engloba os grandes softwares 
usados por empresas no mundo todo. Fazem a contabilidade, a folha de 
pagamento, o planejamento da produção, organizam a cadeia de suprimentos, 
facilitam a interação com clientes e gerenciam as informações corporativas. 
 Software de Entretenimento: feito para uso doméstico e recreativo. Diz 
respeito aos diferentes jogos de que tanto gostamos. 
 Software Educacional: é o que permite estudar e aprender usando os 
dispositivos computacionais, como o que garante que esta apostila chegue até 
você. 
 Softwares para Plataformas: são aqueles que garantem que a infraestrutura 
funcione adequadamente. Softwares que controlam as centrais telefônicas, a 
distribuição de energia elétrica, as redes de computador e as rotas de Internet, 
incluindo o software que existe no roteador wi-fi em casa e nas torres de 
telefonia celular. 
 Softwares para Desenvolvimento: são os softwares que permitem ou auxiliam 
no desenvolvimento de outros softwares. As linguagens de programação, os 
compiladores e os interpretadores de comando. Alguns autores os colocam na 
categoria de Softwares de Operações Comerciais. 
 Softwares Embarcados: são os pequenos softwares embutidos em aparelhos 
domésticos, carros e máquinas pesadas, como robôs industriais. Seu aparelho 
de TV, a máquina de lavar e o micro-ondas possuem software para funcionar. 
Esta aqui seria uma subcategoria dos Softwares Básicos, se formos ficar com 
uma classificação mais ampla. 
Essas classificações não são unanimidade. Dependendo do autor, da pessoa com quem 
se está falando, e até do momento, a classificação pode mudar. Outra coisa que se 
, 
 
 
8 
 
precisa pensar é que talvez essas divisões tenham limites pouco definidos. Usamos 
softwares de produtividade para produzir o conteúdo que você está acessando através 
de softwares de plataformas e que estão dentro do software educacional da 
Universidade. Onde exatamente termina um e começa o outro? 
1.3 Propósito ou Domínio de Uso e Domínio de Execução 
Se olharmos de forma diferente e pensarmos apenas no propósito, ou seja, em como 
vamos usar o software, poderíamos dizer que existem duas grandes categorias apenas. 
Os Softwares Básicos e os Softwares Aplicativos. 
O Básico está mais ligado a fazer os equipamentos funcionarem adequadamente, e os 
Aplicativos fariam todo o resto. É uma forma diferente de classificação que parte 
apenas do domínio de uso e tudo fica dentro dessas duas abordagens: ou o software 
faz um equipamento funcionar ou o software é para o ser humano executar suas 
tarefas. 
Há uma terceira categoria que são os Softwares Maliciosos, ou Malware, que são 
programas usados para roubar dados, os vírus de computador e outros. 
Quando olhamos onde o software é executado, a classificação pode ser feita de forma 
diferente. Os softwares precisam de ambientes diferentes para poderem executar de 
forma adequada. Vejamos: 
 Softwares Desktop: são os softwares que executam no dispositivo 
computacional (computadores, tablets, smartphones) e que permitem 
fazermos nossas atividades do dia a dia. 
 Softwares de Servidor: são os softwares que executam em grandes 
computadores e que permitem armazenar grandes quantidades de informação 
e fazem milhares de operações por segundo. 
 Softwares Embutidos: são os que executam dentro de aparelhos domésticos, 
automóveis e robôs. Normalmente, esses softwares têm apenas uma finalidade 
e uma funcionalidade. 
, 
 
 
9 
 
 Software de Microcódigo: é um tipo de software que fica gravado no próprio 
processador e que permite ao próprio processador saber como executar código 
de máquina. Normalmente, apenas o fabricante tem acesso. 
1.4 Engenharia de Software 
Vamos partir da definição de Engenharia de Software, segundo a ISO 24765:2017[6]: 
Engenharia de Software é: (1) a aplicação sistemática de conhecimento, métodos e 
experiência científicos e tecnológicos para o projeto, implementação, teste e 
documentação de software; (2) a aplicação de uma abordagem sistemática, 
disciplinada e quantificável no desenvolvimento, operação e manutenção de software; 
ou seja, a aplicação da engenharia ao software. 
Vamos entender essa definição. Aplicação sistemática de conhecimento científico e 
experiência significa que a princípio precisamos saber o que estamos fazendo. A 
definição também fala em métodos, o que significa que não podemos fazer as coisas 
de qualquer jeito. A segunda parte da definição fala especificamente do porquê usar 
engenharia. Abordagem disciplinada e quantificável no desenvolvimento, operação e 
manutenção. Software dá manutenção. Em muitos casos, muita manutenção. E 
abordagem disciplinada na operação quer dizer que não adianta operar o software de 
qualquer jeito porque ele pode deixar de funcionar ou apresentar resultados 
inesperados. É o que acontece se o usuário digitar o número de seu telefone no lugar 
do CEP, por exemplo. 
Já de acordo com Summerville [7], a engenharia de software é uma disciplina da 
engenharia que se preocupa com todos os aspectos da produção de software, desde a 
especificação até depois que entrou em uso. É uma definição mais ampla e aberta, mas 
que remete à engenharia. É uma disciplina da engenharia, ou seja, é parte da 
engenharia, o que pressupõe uso de método e controles para a produção de software. 
E o dicionário Merriam-Webster [8] traz o termo como um ramo da ciência da 
computação que lida com projeto, implantação e manutenção de programas de 
computador complexos. Aqui também é interessante notar a referência a uma ciência 
, 
 
 
10 
 
e o fato de citar programas de computador complexos. É claro que programas 
complexos precisam de mais detalhamento e muito mais cuidado no projeto, na 
implantação e vão dar muito mais manutenção do que o aplicativo “Calculadora” do 
seu celular ou o botão “Pipoca” do micro-ondas. Mas os fundamentos da Engenharia 
de Software podem e devem ser usados em qualquer tamanho ou natureza de 
software. 
A Engenharia de Software possui uma espécie de manual, de guia de referência, 
chamado SWEBOK. 
O SWEBOK – Software Engineering Base of Knowledge – ou Base de Conhecimento em 
Engenhariade Software é um guia de referência desenvolvido por um comitê técnico 
conjunto do IEEE (Institute of Eletric and Eletronic Engineering) e a ISO (International 
Organization for Standardization) que compilou num único volume muitas das normas 
e referências existentes na área da Engenharia de Software. A versão mais recente é a 
chamada SWEBOK v3, de 2013. Em 2016, foi criado um comitê chamado SWEBOK 
Evolution, para cuidar do desenvolvimento do corpo de conhecimento. 
 
Fonte: ROCHA, Felipe Lira. Modelos de Desenvolvimento de Software. Blog do Felipe Lira Rocha, 15 abr. 
2012. Disponível em: <https://felipelirarocha.wordpress.com/2012/04/15/diversos-modelos-de-
desenvolvimento-de-software-resumo/>. Acesso em: 10 jan. 2020. 
https://felipelirarocha.wordpress.com/2012/04/15/diversos-modelos-de-desenvolvimento-de-software-resumo/
https://felipelirarocha.wordpress.com/2012/04/15/diversos-modelos-de-desenvolvimento-de-software-resumo/
, 
 
 
11 
 
Quando olhamos o SWEBOK, encontramos os capítulos para Requisitos de Software, 
Projeto de Software, Construção de Software, Testes de Software, Manutenção de 
Software, Gerenciamento de Configuração, Gerenciamento da Engenharia de 
Software, Modelos e Métodos de Engenharia de Software, Qualidade do Software, 
Prática Profissional, Modelo Econômico da Engenharia de Software, Fundamentos 
Computacionais, Matemáticos e de Engenharia. São 15 capítulos em 335 páginas e é 
uma leitura que faz referência a diversas fontes. Então, esse guia, ou corpo de 
conhecimento precisa ser complementado com muita leitura extra e muito estudo. No 
entanto, os princípios estão compilados num único volume. 
1.5 Arquitetura de Software 
A Arquitetura de Software se refere às estruturas fundamentais de um sistema de 
software e a criação dessas estruturas fundamentais. É uma analogia com a 
arquitetura de um prédio, em que o arquiteto projeta um edifício e diz que material 
vai revestir as escadas, onde vai ficar o elevador e as garagens, e qual será o tipo de 
janela. Na Arquitetura do Software, dizemos o que o software vai fazer, como serão as 
telas, em que plataforma tecnológica ele vai funcionar. 
Contudo, é a Engenharia de Software que vai cuidar de todo o detalhamento. Assim 
como é o Engenheiro Civil que vai dizer quanto concreto será usado nas escadas que 
depois serão revestidas tal qual projetou o arquiteto. A Engenharia de Software vai 
cuidar dos requisitos, do projeto, do desenvolvimento, testes e manutenção. Essas 
duas áreas trabalham de forma integrada. Entretanto, o objetivo delas é diferente. A 
Arquitetura de Software cuida mais da concepção do produto desejado, enquanto a 
Engenharia de Software cuida da construção do produto desejado. 
A Arquitetura de Software nos faz adotar certas estruturas que são muito difíceis e 
muito caras para mudar depois. Por exemplo, se o arquiteto de software decidiu usar 
um banco de dados de um determinado fabricante, será muito difícil mudar para um 
banco de dados de outro fabricante, pois embora os sistemas de banco de dados 
sejam parecidos e sigam uma padronização (pelo menos os relacionais, mais comuns 
, 
 
 
12 
 
hoje), existem especificidades que podem gerar comportamentos indesejados e 
inesperados (chamados “bugs”, ou erros). 
A ISO 42010 [9] é quem define a Arquitetura de Software como o processo de 
conceber, definir, expressar, documentar, comunicar, certificar a implementação 
apropriada, manter e melhorar uma arquitetura através do ciclo de vida de um 
sistema. E ainda diz que os conceitos fundamentais ou propriedades de um sistema 
levam em consideração seu ambiente, seus elementos, relacionamentos e a evolução 
do seu projeto. 
Podemos perceber uma interação clara com a Engenharia quando a definição diz que a 
arquitetura tem o processo de certificar a implementação. Ou seja, depois que a 
Engenharia construiu o produto de software, a Arquitetura valida o que foi feito para 
ver se atende o conceito, se o software faz aquilo que foi proposto e concebido pela 
Arquitetura de Software. 
E ainda a mesma norma ISO 42010 [9] traz o conceito de “Framework” da Arquitetura 
de Software, que seriam as convenções, os princípios e as práticas para a descrição das 
arquiteturas estabelecidas dentro de um domínio específico de aplicação. 
“Framework” tem a ver com forma de fazer, um modelo de como as coisas devem ser 
feitas. Isso para que os conceitos e a concepção fundamental do software possam ser 
bem definidas e documentadas para o processo de construção do software, que será 
feito por outro conjunto de pessoas. Documentação é fundamental dentro de todos 
esses processos, tanto de Arquitetura de Software, quanto de Engenharia. Grupos de 
pessoas diferentes fazem coisas diferentes para a produção de um resultado esperado. 
Pense num jogo de videogame. Alguém vai desenhar o jogo, os personagens. Outro 
grupo de pessoas vai programar o jogo. Há ainda música e animação de tudo isso. 
Também haverá pessoas pensando no produto final, venda e distribuição. Sem se 
esquecer da equipe de testes. Se esses diferentes grupos não documentarem o que 
estão fazendo, a integração dessas áreas será muito difícil, podendo resultar num 
produto de software de qualidade inferior, cheio de erros e comportamentos 
inesperados, caracterizando uma falha de projeto que custará caro para recuperar. 
, 
 
 
13 
 
 
Conclusão 
Neste bloco, você viu a definição de software e suas diferentes classificações. Software 
é um produto intangível. Não podemos tocá-lo, segurá-lo na mão. Você teve a 
oportunidade de entender como diferentes tipos de software vão precisar de 
diferentes ferramentas e técnicas para serem construídos. O processo de construção é 
complexo, demanda várias fases, e cada fase vai ter métodos próprios e características 
próprias, fazendo com que a disciplina da Engenharia de Software se torne muito 
importante nos dias de hoje, em que empregamos software em aparelhos domésticos, 
automóveis, educação, entretenimento; e muitas coisas que fazemos atualmente 
dependem muito dos softwares que utilizamos e da integração entre softwares 
diferentes. 
Vamos pensar um pouco no processo de compra pela Internet. Existe software que 
permite que a Internet exista. Existe software sendo executado no servidor da 
empresa de quem você está comprando. Existe o processamento do pagamento, que é 
via software. Depois a emissão dos documentos legais é feita por software. 
Finalmente, a entrega é controlada por software, estabelecendo até a melhor rota de 
entrega para o entregador. Se não existisse software, como seria esse processo? 
Antigamente, era muito difícil e demorado comprar qualquer coisa que não fosse 
numa loja física. 
O software permeia tudo o que fazemos. Está em todos os lugares e controla as 
operações mais fundamentais da vida cotidiana. Isso faz com que o desenvolvimento 
de software tenha se tornado uma tarefa complexa, com diversas implicações. Por 
isso, precisamos aplicar os conceitos da Engenharia na produção de software. 
A Engenharia de Software está definida através de organismos internacionais. A ISO, o 
IEEE e outros órgãos governamentais e associações profissionais produziram normas e 
conjuntos de conhecimento que definem o que é e como se faz para seguir os 
conceitos da Engenharia de Software. A Engenharia de Software cuida dos Requisitos, 
da Qualidade, da Construção, dos Testes e vários outros princípios importantes para 
, 
 
 
14 
 
garantir que o software atenda aos seus propósitos, definidos antes pela Arquitetura 
de Software, sem apresentar falhas e comportamentos indesejados, e que funcione 
por muito tempo, passando por procedimentos adequados de manutenção, de acordo 
com toda a documentação que foi produzida. 
 
 
REFERÊNCIAS 
[1] SOFTWARE . Dicionário online do Google. Disponível em: 
<https://bit.ly/39MDRhz>. Acesso em: 8 jan. 2020. 
[2] SOFTWARE. Michaelis DicionárioBrasileiro da Língua Portuguesa. Disponível em: 
<michaelis.uol.com.br>. Acesso em: 8 jan. 2020. 
[3] FERNANDES, Jorge Henrique Cabral. Qual a prática do desenvolvimento do 
software. Ciência e Cultura, 2003. Disponível em: 
<http://cienciaecultura.bvs.br/pdf/cic/v55n2/15526.pdf>. Acesso em: 8 jan. 2020. 
[4] PRESSMAN, Roger S; MAXIM, Bruce R. Engenharia de Software: uma abordagem 
profissional. 8. ed. Porto Alegre: AMGH, 2016. 
[5] MICROSOFT CORPORATION, SOFTWARE CATEGORIES. Microsoft TechNet (2010). 
Disponível em: 
<https://web.archive.org/web/20080921072543/http://technet.microsoft.com/en-
us/library/bb852143.aspx>. Acesso em: 25 nov. 2019. 
[6] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 24765 Systems and 
Software Engineering – Vocabulary. 2. ed. Genebra, 2017. 
[7] SOMMERVILLE, Ian. Software Engineering. 8. ed. Harlow, England: Pearson 
Education, 2007. 
[8] SOFTWARE ENGINEERING. Dicionário Merriam-Webster. Disponível em: 
<www.merriam-webster.com>. Acesso em: 25 nov. 2019. 
[9] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 42010 Systems and 
Software Engineering – Architecture Description. 1. ed. Genebra, 2007. 
 
http://cienciaecultura.bvs.br/pdf/cic/v55n2/15526.pdf
https://web.archive.org/web/20080921072543/http:/technet.microsoft.com/en-us/library/bb852143.aspx
https://web.archive.org/web/20080921072543/http:/technet.microsoft.com/en-us/library/bb852143.aspx
, 
 
 
15 
 
 
2 PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 
Neste bloco, falaremos sobre o projeto de software e seu ciclo de vida, a construção 
do software, o processo de desenvolvimento de software, os testes de software e a 
manutenção de software. Vamos lá? 
 
2.1 Projeto de Software e Ciclo de Vida 
Bom, você já deve ter entendido como o cenário do desenvolvimento de software é 
complexo, e já tem uma ideia do que seja software e Engenharia de Software. Para 
uma iniciativa dar certo e se chegar ao produto de software desejado, com qualidade, 
e principalmente, que atenda as necessidades e expectativas dos usuários, é 
necessário estabelecer as bases do projeto e controlar as atividades necessárias, para 
que tudo seja de acordo com o especificado. 
Precisamos pensar o projeto como o termo em inglês “design”. Esse termo tem a ver 
com concepção, com definição de características básicas e importantes, que vão servir 
como definição e determinação de como o software deve se comportar e quais são as 
principais funcionalidades que o software precisa atender, servindo plenamente às 
necessidades dos usuários, com eficiência e com qualidade. Depois de documentarmos 
esse processo de concepção, precisamos definir os requisitos do software, as 
especificações do projeto e iremos ver a parte de requisitos em um bloco separado, 
devido à importância desse tópico para o desenvolvimento do software. 
Imagine a frustração de todos os envolvidos (stakeholders) num projeto de software 
quando ao final de meses de trabalho, o produto não atende o que foi especificado. É 
como se você comprasse uma bicicleta na caixa, e ao abrir, não tivesse os pedais. O 
que fazer? Retrabalho do software? Começar todo o processo de novo? E se houvesse 
requerimentos legais a serem cumpridos, como por exemplo, uma reforma tributária e 
o novo software estivesse calculando tudo errado? Quais as implicações? A empresa 
que não entrega seus impostos corretamente é considerada como atividade suspeita 
de sonegação. Haverá processos, multas e punições para seus dirigentes. Por isso, é 
importante entender o projeto como um todo, e a necessidade de organizar o trabalho 
, 
 
 
16 
 
a ser feito, dividindo as atividades em tarefas menores, distribuindo essas tarefas para 
cada pessoa envolvida, alocar os custos e definir os critérios de qualidade. 
Para gerenciar o projeto do software em si, podem ser usados os conhecimentos 
contidos no PMBOK, o Guia de Gerenciamento de Projetos do PMI (Project 
Management Institute). Esse corpo de conhecimentos contém uma compilação de 
várias melhoras práticas em gestão de projetos, que podem ser usados em conjunto 
com as práticas de Engenharia de Software. 
Gestão de projetos é uma das áreas de preocupação da Engenharia de Software. 
Afinal, os produtos precisam chegar a quem vai usar, o mais rápido possível, 
atendendo todos os requisitos e com um preço razoável. A área de Engenharia tem 
suas práticas de gestão de projetos. Aliás, o PMI nasceu com um grupo de engenheiros 
em 1969. Nesses mais de 50 anos, essa experiência foi sendo compilada. Quando a 
área de Tecnologia começou a adotar essas práticas, já compiladas, o PMBOK ficou 
popular rapidamente e o PMI se tornou a referência mundial em projetos. Assim 
sendo, para que inventar a roda quando ela já foi inventada? Vamos gerenciar projetos 
usando o PMBOK. 
O PMI recentemente fez acordo com a Agile Alliance e adotou a metodologia Scrum 
para gerenciar projetos de forma ágil. A partir da 6ª edição do PMBOK, o manual de 
práticas de Scrum passa a ser uma parte integrante dos conhecimentos em gestão de 
projetos, como uma alternativa que segue os padrões definidos no Manifesto Agile. 
Uma abordagem Agile não significa fazer as coisas sem controle e de forma 
descuidada. Pelo contrário, é uma forma de trabalhar mais ágil, voltada a entregar 
resultados rapidamente aos clientes e usuários, estabelecendo critérios de aceitação 
dos requisitos e de performance da equipe de programadores. Uma espécie de “jeito 
para colocar ordem na bagunça”. E tem se tornado a forma de trabalho mais comum 
nas equipes de criação de software. Scrum é uma forma de gerenciar projetos, 
excelente para projetos de software, na qual muitas vezes não sabemos exatamente o 
que precisa ser feito e novas necessidades vão aparecendo conforme o 
desenvolvimento acontece. 
, 
 
 
17 
 
O tripé da gestão de projetos é Prazo, Custo e Qualidade. Sempre que vamos pensar 
num projeto de software, não podemos nos esquecer dessas três coisas que interagem 
entre si sempre de forma mutuamente exclusiva. Isso significa que não é possível 
melhorar a qualidade sem aumentar o custo e/ou o prazo. Porque, para melhorar a 
qualidade, custará mais caro, se precisará de mais tempo. De forma semelhante, não 
se pode fazer mais barato sem perder qualidade e/ou prazo. Para que o software fique 
mais barato, contratam-se menos programadores ou programadores inexperientes. 
Isso significa que o software vai perder qualidade e/ou levar mais tempo para ficar 
pronto. Com o prazo é a mesma coisa. Para fazer mais rápido, são necessários mais 
programadores (custo) e pode haver perda de qualidade no produto de software que 
será entregue ao final. Compreender esse tripé é muito importante para entender 
como será um projeto de software. 
Outro conceito importante para ser compreendido é o ciclo de vida do software. 
Segundo a norma ISO 12207:2017 [1], ciclo de vida é a evolução de um sistema, 
produto, serviço, projeto ou outra entidade feita por humanos, desde a concepção até 
ser aposentada. Quando falamos do ciclo de vida do software, ainda a mesma norma 
diz que esse ciclo inclui várias fases. Uma fase de requisitos, uma fase de projeto ou 
design, a fase de implementação, a fase de testes e algumas vezes uma fase de 
instalação é necessária. Depois disso, o software entra na fase de operação, que é 
quando ele precisa de manutenção. 
Esse ciclo de vida pode ser mais longo ou mais curto em função de vários fatores. 
Imagine um videogame. É um mercado ávido por novidades. Assim, a tendência é o 
jogo ser aposentado mais cedo, substituído por um novo e normalmente melhorado. 
Por outro lado, um sistema que controle todas as reservas de uma companhia aérea 
tende a ser deixado em operação por muitos anos, sofrendo manutenção constante 
para que sempre funcione adequadamente e seguindo as novas tendências do 
mercado, como reservas online, confirmação por celular e outras funcionalidades. 
Novas funcionalidadespodem ser acrescentadas ao software, mas na essência é o 
mesmo software de anos atrás que passou por manutenção e renovação. 
, 
 
 
18 
 
Na Engenharia de Software, é importante notar que o desenvolvimento de um projeto 
inclui vários processos, seguindo o ciclo de vida: 
 Elicitação de Requisitos; 
 Análise dos Requisitos do Sistema; 
 Projeto Arquitetural do Sistema; 
 Análise dos Requisitos de Software; 
 Projeto de Software; 
 Construção do Software; 
 Teste do Software; 
 Integração do Sistema; 
 Teste do Sistema; 
 Instalação do Software; 
 Manutenção do Software e do Sistema. 
2.2 Construção do Software 
O termo construção do software se refere ao trabalho de criação do produto de 
software em si, através da combinação de codificação, verificação, teste unitário, teste 
integrado e correção do software [2]. Existem 5 princípios fundamentais relacionados 
à construção do software, sendo que os 4 primeiros são aplicados desde o projeto do 
Software. 
O primeiro princípio está ligado à incapacidade do ser humano em lidar com estruturas 
e informações complexas, especialmente por longos períodos de tempo. Esse fato 
influencia demais a construção de software e leva ao primeiro princípio, que é 
minimizar a complexidade [2]. 
Para conseguir minimizar a complexidade, é preferível implementar código simples e 
fácil de entender em vez de um código enxuto e mais “fácil” de escrever. Uma das 
grandes dificuldades da indústria de software tem sido a manutenção depois que o 
produto está em operação e é usado pelas pessoas. Qualquer alteração posterior, 
vamos dizer que poucos meses após a entrada em operação, exige que se consiga 
entender o que foi codificado antes. Isso já é difícil quando o próprio programador vai 
, 
 
 
19 
 
entender seu código. Imagine se outra equipe estiver responsável pela manutenção? É 
por isso que existem tantos paradigmas de programação e padronizações de técnicas 
de programação. Quanto mais fácil de entender o código, melhor. Mesmo se o código 
não ficar tão “elegante”, ou “técnico”, e às vezes, prefere-se perder eficiência. 
O segundo princípio é o de se antecipar à mudança. E está ligado com o primeiro. O 
software vai passar por mudanças ao longo do tempo, principalmente se estivermos 
falando de um software que tem vida longa, como um sistema integrado ou um 
software de CRM. A ideia por trás de antecipar a mudança é estender a vida útil do 
software, permitindo que se implementem melhorias sem afetar a estrutura principal 
[2]. 
Construir para verificação significa construir o software de forma que qualquer erro 
seja encontrado prontamente pelos engenheiros de software e pelos testadores e 
usuários, tanto durante a fase de testes, quanto na operação [2]. Para atingir esse 
terceiro princípio, são empregadas técnicas que permitam a automação de testes, a 
organização do código de forma a facilitar os testes e as auditorias, além do uso de 
padrões conhecidos e evitar as estruturas mais complexas das linguagens de 
programação, como foi mencionado anteriormente. 
O quarto princípio é o reúso. Reúso de código significa usar rotinas pré-programadas 
para fazer as tarefas básicas ao invés de se recriar as rotinas de código [2]. Por 
exemplo, a verificação de CPF. Sempre que se digita um CPF é feita uma validação para 
evitar que um código inválido tenha sido digitado. É um número de documento 
importante no Brasil, é um número longo e pode estar sujeito a erro pelos usuários. 
Então, existe uma rotina para verificar o CPF através dos dígitos finais. A ideia do reúso 
é usar sempre a mesma rotina para isso, chamando essa rotina sempre que necessário, 
em vez de reescrever esse código de programação todas as vezes. Se for necessário 
mudar alguma coisa, basta mudar uma rotina. Todo o software usa a mesma rotina, 
então está corrigido em todo o produto de software. Esse princípio pode ser usado 
para cadastros, endereços, números de telefone, senhas e uma série de rotinas 
comuns ao software como um todo. 
, 
 
 
20 
 
E finalmente, o quinto princípio é o de padronização da construção. Usar a mesma 
linguagem de programação em todo o projeto (ou um pequeno conjunto de 
linguagens), linguagens conhecidas no mercado, com facilidade de obtenção de 
especialistas no mercado, criar convenções de uso de nomes de arquivo e de variáveis, 
métodos e formas de comunicação e mensageria, ferramentas de programação e de 
modelagem (UML, por exemplo) e sempre se basear em padrões internacionalmente 
aceitos pelo mercado. Padrões de desenvolvimento na construção do software ajudam 
a atingir os objetivos de qualidade, eficiência e custo do projeto [2]. 
 
2.3 Processo de Desenvolvimento de Software 
Muito se fala de Usabilidade, UX (User eXperience) ou experiência do usuário. Tem 
estado “na moda” desde 2007. Contudo, muito antes já se falava em Ergonomia. São 
conceitos diferentes, mas todos fortemente interligados e tem a ver em como a pessoa 
que está usando um produto pode obter a melhor performance, com qualidade e 
eficiência. 
A altura da mesa, a posição do teclado, a distância da cadeira, a iluminação. Todas 
essas características fazem parte da Ergonomia. Quando falamos de software, ele 
também tem uma ergonomia. Para idiomas baseados no alfabeto latino, onde se lê da 
esquerda para a direita, os menus na tela deveriam ficar à esquerda. Observe os sites 
da Internet que você costuma navegar. A maioria tem o logo e o nome no canto 
superior esquerdo, porque é onde começamos a ler o website, o menu no topo, a 
barra de tarefas do lado esquerdo. Nesse ponto, estamos falando de Ergonomia. 
Usabilidade tem a ver com facilidade de aprendizagem, eficiência de uso, capacidade 
de memorização dos componentes, quantidade de erros cometidos e satisfação de 
utilização. A capacidade de um usuário específico em obter um resultado específico 
dentro de um contexto predeterminado [3]. Isso tudo está definido na norma ISO 
16982. 
Já a UX tem mais a ver com sentimento e percepção. A pessoa que está usando 
determinado software gostou da experiência? E está definido em outra norma da ISO, 
, 
 
 
21 
 
a ISSO 9241-210, que define UX como a percepção e a resposta que resultam do uso 
de um produto, sistema ou serviço [4]. 
Essas decisões são muito importantes na hora de construir o software porque afetam a 
maneira como as pessoas vão perceber o produto. Imagine alguém que tenha que ficar 
a maior parte do seu dia digitando numa tela com tons de vermelho. Com certeza em 
poucas horas sua vista estaria cansada, e consequentemente sua produtividade 
diminuiria, fazendo com que o software não fosse o mais eficiente que ele poderia ser; 
da mesma forma, um cadastro com muitos itens feito numa única tela com letras 
pequenas. O melhor é dividir o cadastro em duas ou mais telas, para facilitar a vida da 
pessoa que vai passar horas com essa tela aberta. 
Imagine outras situações, como falta de conexão para consultar o estoque, um jogo no 
qual todos os itens na tela sejam tons de cinza, menus não responsivos em telas de 
tamanho diferente. Já reparou que todos os teclados seguem um padrão? Isso não é 
por acaso. São definições pensadas durante a fase de design (projeto) do software e 
cuidadosamente implementadas e testadas na construção do software, seguindo as 
normas e boas práticas da Usabilidade, Interação Humano-Computador e UX. 
 
2.4 Testes de Software 
Teste de software consiste em uma verificação dinâmica em que um programa provê 
os comportamentos esperados num conjunto finito de casos de teste, devidamente 
selecionados de um domínio de execução usualmente infinito [2]. 
Difícil? Vamos ver os conceitos básicos dessa definição para entendermos exatamente 
do que estamos falando. Dinâmica significa que o teste vai depender sempre do 
estado em que o software está. Num determinado momento, os dados têm um 
determinado valor, mas no momento seguinteos valores podem mudar, definindo um 
estado diferente do software. 
Na definição, comportamento esperado significa que sabemos qual é a resposta 
desejada que queremos que o software forneça. Imagine a calculadora do seu celular. 
É um software cujo comportamento esperado nós sabemos. Digitamos números e as 
, 
 
 
22 
 
operações, e esperamos um resultado dessa operação matemática que desejamos. É o 
comportamento esperado de um software de calculadora. 
Agora, conjunto finito de testes significa que testamos o software dentro de 
determinados parâmetros. Imagine se fôssemos testar todos os parâmetros de uma 
calculadora. Poderíamos levar anos testando, mesmo os softwares mais simples. 
Somamos dois números simples, fáceis de conferir o resultado e esperamos que 
operações de soma mais complexas também estejam certas. Fazemos um número 
finito de testes de soma, subtração, multiplicação, divisão. Conferimos os resultados e 
avaliamos se o software acertou as operações e consideramos como testado. 
Finalmente, devidamente selecionado significa que escolhemos determinados 
conjuntos de valores para tentar simular um bom número de casos. Num cadastro de 
clientes, é muito comum os programadores cadastrarem a si próprios no sistema, para 
avaliar se os dados de endereço, telefone e números de documentos sejam 
corretamente armazenados. Mas é comum que os programadores se esqueçam de 
testar o cadastro de uma empresa, baseado em CNPJ e não no CPF, potencialmente 
deixando de avaliar a funcionalidade de cadastro num bom número de situações. 
Então, nos testes precisamos pensar quais são as situações desejadas, as mais 
esperadas e escolher um domínio de execução apropriado para a maior parte das 
situações. 
O teste de software tem diferentes objetivos e dependendo da complexidade do 
produto de software que estamos construindo, diversos testes podem ser necessários, 
o que toma bastante tempo da equipe de desenvolvimento. Vejamos alguns exemplos. 
Teste unitário é aquele que testa uma determinada funcionalidade ou componente do 
software. Em oposição ao teste integrado, em que se testam como o software se 
comporta interagindo com seus diferentes componentes. Um jogo não fica bom sem a 
música, ou com um pedaço da tela em branco. Há vários diferentes testes que 
devemos levar em consideração na construção do software. Teste de instalação, teste 
de segurança, teste de estresse, que tenta estabelecer se o software se comporta bem 
quando está sobrecarregado. Temos ainda teste de recuperação, que procura 
, 
 
 
23 
 
determinar se o software volta a funcionar adequadamente após um problema, como 
falta de energia no computador, por exemplo. Teste de performance, e teste da 
interface, quando pedimos ao usuário para que diga como foi a experiência da 
interação com o software. 
Também existem diferentes técnicas para teste de software. O teste exploratório tem 
ficado popular e consiste em se acompanhar o usuário enquanto ele navega pelo 
software, faz entrar dados, clica e usa o software. As dificuldades são registradas e 
passadas ao time de desenvolvimento. É uma boa técnica para teste de interface e 
usabilidade. 
A maioria dos testes é feita de forma “ad hoc”, ou seja, é o próprio desenvolvedor que 
testa o básico, seguindo sua experiência e intuição. É um teste relativamente 
ineficiente porque fica dependendo do entendimento do desenvolvedor. 
E finalmente vale a pena saber que há diferentes ferramentas de testes, que auxiliam 
em encontrar erros e comportamentos inesperados, com base nos parâmetros 
especificados. Nem sempre as ferramentas são eficientes, porque dependem se o 
código está preparado para testes automatizados e dependem da parametrização feita 
na ferramenta de teste. Entretanto, testes de performance e de estresse são bastante 
comuns com emprego de ferramentas para colocar o sistema sobrecarregado e medir 
tanto a performance quanto à capacidade de recuperação. 
2.5 Manutenção de Software 
Há uma quantidade grande de razões que levam o software a passar por manutenção. 
Corrigir falhas, melhorias de processo, baixa performance, atualização de plataforma 
tecnológica, fazer integração com outros softwares e até a segurança do software [2]. 
Existem três diferentes categorias de manutenção que precisamos considerar: a 
manutenção adaptativa, que ajusta o software a novas condições de operação e que 
normalmente advêm de fatores externos; as manutenções de aperfeiçoamento, que 
visam corrigir algum erro ou melhorar a eficiência do software ou da operação, que 
normalmente advém de fatores internos do próprio software; e as manutenções 
preventivas, que visam evitar que algum problema aconteça num futuro próximo. 
, 
 
 
24 
 
Ao contrário do que se acredita, manutenção não pode ser feita de forma rápida, sem 
controle ou planejamento. Alguns cuidados são necessários para que tudo ocorra de 
forma eficiente. O principal motivo é a possibilidade de uma manutenção numa 
determinada rotina do software, causar comportamentos inesperados em outra rotina 
do software. 
Sendo assim, é necessário implementar ferramentas e técnicas de controle na 
operação do dia a dia do software, para saber como o software está operando, se está 
tendo comportamentos fora do esperado, se está atendendo as especificações e um 
registro de problemas deve ser analisado. Também encontrar soluções para os 
problemas de forma que nada mais pare de funcionar é extremamente importante. 
Muitas vezes, é melhor gastar um tempo maior analisando uma falha do que sair 
mudando o software sem um planejamento adequado. 
Outra preocupação necessária é a documentação atualizada do software. Se for feita 
uma manutenção, mudando alguma rotina, é necessário documentar a mudança, 
como ela foi feita, qual o motivo, qual foi o erro ou comportamento inesperado que 
gerou a necessidade de mudança e muito importante, o código original, antes da 
mudança, precisa ser preservado. É importante documentar as diferentes versões de 
código. 
O software também precisa evoluir naturalmente. Algumas vezes, o usuário faz 
sugestões de melhoria, após o uso continuado do software. Outras vezes, o 
desenvolvedor percebe uma forma melhor de uma rotina ser executada, ou uma 
forma mais rápida de executar uma certa operação. Essas evoluções são muito comuns 
e necessárias e fazem parte do processo de manutenção. 
Ameaças externas ao software também podem exigir manutenção. Uma nova forma 
de ataque na segurança pode ser descoberta ou desenvolvida e para não 
comprometer a segurança das informações, uma manutenção pode ser obrigatória. 
Outra razão comum para desejarmos fazer manutenção é a performance. Logo que o 
software entra em operação, existem poucos dados, poucos usuários e a performance 
é bastante agradável para os usuários. Mas com o passar do tempo, pode ser 
, 
 
 
25 
 
necessário mudar algumas técnicas de programação que foram empregadas, por 
outras mais eficientes. Existem diferentes razões para isso, desde o volume de dados 
maior, até inovações ou mudanças na plataforma onde o software está instalado que 
passe a prejudicar a performance, obrigando uma manutenção para ajustar o software 
às novas condições da plataforma. 
Existem vários fatores que podem acontecer e que prejudicam a manutenção do 
software. Talvez a principal delas seja a falta de entendimento. Muitas vezes, o 
desenvolvedor do software pode não estar disponível na hora da manutenção e outro 
engenheiro de software precise assumir a tarefa. É necessário ter certeza que esse 
novo especialista compreenda o que o software faz, qual o comportamento desejado e 
qual o problema pelo qual o software está passando que impede que se chegue ao 
resultado desejado ANTES que a manutenção comece. Senão corre-se o risco de que o 
software deixe de atender as necessidades do usuário. 
É necessária muitas vezes uma análise de impacto, para determinaro que a rotina que 
entrará em manutenção faz, com quais rotinas ela se relaciona e quais os potenciais 
problemas podem acontecer. Situações podem acontecer de modo que a 
complexidade da manutenção, ou ainda a necessidade de testar de novo todas as 
funcionalidades, forcem o custo dessa manutenção para cima, precisando de uma 
análise maior, para determinar se não seria melhor retirar esse software e substituir 
por um novo. 
 
Conclusão 
Neste bloco, você pôde ver todo o processo de desenvolvimento do software, bem 
como seu ciclo de vida, desde a fase de projeto até a manutenção, que acontece 
depois que o software está em operação. Não necessariamente o software entra em 
operação completo. Apesar disso, ele tem um ciclo de vida próprio e bem definido, 
mesmo que em módulos. 
Foram apresentadas as principais considerações a respeito de um projeto de software, 
quais são as necessidades na hora de gerenciar o projeto, definir o que precisa ser 
, 
 
 
26 
 
feito e definir quais são os requisitos. Vimos também que requisitos são uma parte 
fundamental para a Engenharia de Software. 
Falamos sobre a construção do software em si, e dos 5 princípios que a construção do 
software deveria seguir. O princípio de reduzir a complexidade, o de antecipar a 
mudança, o princípio de construir para facilitar a verificação, o reúso de partes do 
código e a importância de se seguir os padrões da indústria e da empresa. 
Falamos da interface do usuário e de interação entre o homem e o computador. Como 
as questões de usabilidade e experiência do usuário são importantes e podem, 
inclusive, determinar o sucesso de um software, tanto em termos comerciais quanto 
em termos de qualidade. 
Em seguida, abordamos o teste de software. Outra fase bastante importante, que 
consome tempo e recursos da equipe de desenvolvimento e que não pode ser 
negligenciada como uma atividade sem importância. Falamos sobre os diferentes tipos 
de testes e as ferramentas e técnicas para obtermos maior taxa de sucesso. 
Finalmente, falamos também da manutenção de software, fase que acontece depois 
que o software entra em operação, suas características, os diferentes tipos de 
manutenção e abordamos os principais problemas e preocupações que devemos ter 
quando falamos em manutenção de software. 
O processo de desenvolvimento de software é importante para compreender a 
Engenharia de Software como um todo, a abrangência dos conhecimentos e das 
habilidades de um profissional dessa área e como cada parte do ciclo de vida afeta as 
demais e pode comprometer o produto de software que se pretende construir. 
 
REFERÊNCIAS 
 [1] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 12207:2017 
Systems and software engineering – Software life cycle processes. 3. ed. Genebra, 
2018. 
[2] BOURQUE, Pierre; FAIRLEY, Richard E. (ed.). SWEBOK – Software Engineering Base 
Of Knowledge. 3. ed. IEEE Computer Society, Piscataway, NJ, 2014. 
, 
 
 
27 
 
[3] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 16982 Ergonomics of 
human-system interaction — Usability methods supporting human-centred design. 
Genebra, 2002. 
[4] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 9241-100 
Ergonomics of human-system interaction. 2. ed. Genebra, 2006. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
, 
 
 
28 
 
 
3 ENGENHARIA DE SOFTWARE E MODELAGEM 
Apresentação 
Este bloco falará sobre modelagem. Modelagem de um software consiste em criar um 
modelo da situação real com o objetivo de ajudar a entender o problema, quando e 
como ele ocorre e propor uma solução. Modelos conceituais são configurados para 
refletir a situação real, com seus relacionamentos e dependências. A partir desse 
modelo é que se pode especificar o que será necessário fazer, estabelecendo os 
objetivos de cada requisito, para criar um software com qualidade. 
Entender as principais ferramentas e técnicas de modelagem permite ao Engenheiro 
de Software ter uma visão geral de como o software precisa funcionar, quando e como 
acontece a comunicação do software com outras entidades, sejam pessoas ou outros 
softwares. Também se consegue uma ideia clara das dificuldades e do tamanho do 
esforço necessário para a construção do software, melhorando a qualidade do produto 
final e a qualidade do projeto. 
3.1 Modelagem de Software 
A modelagem de software está cada vez mais disseminada na cultura da criação de 
software e é uma técnica para ajudar engenheiros de software entender, engenheirar 
(aplicar os conceitos de engenharia) e comunicar aspectos do software para os 
stakeholders. Stakeholders são todas as entidades (pessoas, empresas, departamentos 
etc.) que possuem algum interesse no software, como por exemplo, os usuários, os 
desenvolvedores, o presidente da empresa, a área de Tecnologia da empresa e outros. 
[1] 
A modelagem provê uma abordagem sistemática e organizada que permite 
representar aspectos significantes do software em estudo, facilitando as decisões 
sobre o software, ou elementos dele, e comunicar essas decisões e sua importância 
para todas as partes envolvidas [1]. 
Existem muitas técnicas e formas de fazer, tanto no ambiente acadêmico quanto na 
prática. Isso tem sido uma dificuldade para a área de Engenharia de Software por 
, 
 
 
29 
 
décadas, mas alguns princípios são comuns a essas várias ferramentas e técnicas. 
Também se está padronizando e alguns modelos têm se tornado mais comuns e 
conquistado vários seguidores. Vamos começar com os três princípios básicos: 
1. Modele o essencial sobre o software. Aqueles aspectos que precisam de uma 
resposta específica, abstraindo os aspectos que não sejam essenciais. Bons modelos, 
os mais úteis e significativos, são aqueles que não consideram todos os detalhes do 
que o software vai fazer. 
2. Forneça perspectiva ao software em estudo. Diferentes visões sobre o software sob 
diferentes pontos de vista fornecem dimensionalidade ao modelo. Por exemplo, criar 
uma visão estrutural, uma visão comportamental, uma visão organizacional, uma visão 
temporal e outras visões que forem necessárias, pode criar um foco relevante para a 
construção do entendimento do problema e facilitar a tomada de decisão sobre a 
solução desse problema. 
3. Estabeleça uma comunicação efetiva pensando nas pessoas. A modelagem usa um 
vocabulário do software, uma linguagem de modelagem e expressões semânticas que 
são próprias do projeto. As palavras e seu significado dentro de um contexto, quando 
usadas regularmente e sistematicamente no projeto do software, criam uma facilidade 
de entendimento para todos os envolvidos. Essa facilidade de entendimento aumenta 
a efetividade da comunicação, evitando mal-entendimentos e confusão a respeito do 
software objeto de estudo. 
Um modelo é uma abstração, ou seja, uma simplificação de um componente de 
software. Uma consequência do uso de abstrações é que nenhuma sozinha representa 
muito bem aquele componente. O modelo do software passa a ser, então, um 
conjunto de diferentes abstrações que quando olhadas em conjunto traduzem um 
aspecto, perspectivas e visões selecionados, necessários para tomar uma decisão bem 
informada sobre a melhor solução para o problema sendo analisado [1]. 
As propriedades de um bom modelo incluem: Completude, ou seja, abordam todos os 
aspectos que se deseja contemplar no software; Consistência, que é a ausência de 
conflito entre os requisitos e demais componentes do modelo; e também Correção, 
, 
 
 
30 
 
definida como estando o modelo livre de defeitos e satisfazendo os requisitos 
definidos no modelo. 
Os principais elementos encontrados em modelos são as Entidades, usadas para 
representar os artefatos concretos, sejam processadores, robôs, outros softwares ou 
protocolos de comunicação. As entidades precisam se conectar, trocar informação e se 
comunicar. Para isso, representamos através do elemento Relacionamento. Essesdois 
elementos não são os únicos, mas são comuns na maioria dos modelos usados no 
mercado, eventualmente com alguma variação. 
3.2 Tipos e Análise de Modelos 
Como vimos, um bom modelo é uma agregação de submodelos. Cada um desses 
submodelos é uma descrição parcial e foi criado para um propósito específico, para dar 
uma dimensão sobre o software. A UML (Unified Modeling Language) reconhece uma 
rica coleção desses modelos e diferentes abstrações, e apresenta na forma de 
diagramas. Existem vários na UML que são agrupados de acordo com 3 grandes tipos: 
modelagem de Informação, modelagem de comportamento e modelagem de 
estrutura. 
3.2.1 Modelagem de Informação 
Modelos de informação têm foco principal nos dados e na informação. Apresentam 
uma representação que identifica e define um conjunto de conceitos, propriedades, 
relações e restrições para as entidades de dados [1]. A abstração de dados serve para 
conceituar uma visão dos dados no mundo real e como serão empregados. Esses 
modelos vão dar origem aos modelos de dados conceituais e físicos que serão 
implementados no software e para construção do Banco de Dados. 
3.2.2 Modelagem de Comportamento 
Modelagem Comportamental identifica e define as funções do software sendo 
modelado [1]. Funções do software ou funcionalidade refere-se àquilo que esperamos 
que o software faça. Tem a ver com atender as necessidades dos usuários e demais 
stakeholders. Imagine o aplicativo de calculadora do seu celular. Qual é o 
comportamento esperado? Que abram na tela os botões para você clicar e fazer 
, 
 
 
31 
 
contas corretamente como as antigas calculadoras físicas? Existem modelos para 
descrever esses comportamentos esperados. O exemplo a seguir é bem simples, você 
provavelmente deve conhecer ou talvez seja fácil de experimentar, mas imagine um 
software que precise emitir a NFe (Nota Fiscal Eletrônica). Nota Fiscal depende de 
várias coisas. Acesso ao estoque, cálculos de impostos, acesso ao sistema do governo 
que valida a NFe, acesso a meio de pagamento (banco ou cartão de crédito) e mais. 
3.2.3 Modelagem de Estrutura 
Modelagem Estrutural ilustra a composição física ou lógica do software sendo 
modelado a partir de seus vários componentes. Essa modelagem serve para identificar 
os vários componentes do software e sua interação com o ambiente no qual o 
software vai operar [1]. Esses diagramas dizem onde ficarão quais componentes. No 
exemplo da NFe, uma parte do software vai precisar de acesso à Internet para trocar 
dados com o banco. Outra parte vai verificar se há os produtos no estoque. Outra 
acessará o cadastro do cliente. Serão necessários diagramas e modelos para entender 
como esses diferentes componentes interagem entre eles e com as entidades externas 
ao software. A UML provê vários diagramas que auxiliam nesse tipo de modelagem 
também: Diagramas como Diagrama de Classe, Diagrama de Objeto, Diagrama de 
Componente etc. 
O desenvolvimento de modelos permite ao Engenheiro de Software uma oportunidade 
para estudar, raciocinar a respeito e entender a estrutura, função, uso operacional e 
considerar aspectos da montagem do software. A análise desses modelos tem que 
garantir que eles estejam completos, consistentes e corretos [1]. 
Existem ferramentas para analisar o grau de completude do software, a partir das 
conexões dos modelos e verificar que estejam vindo e indo para onde devem, além de 
verificar que todos os componentes estejam ligados uns aos outros. E também podem 
ser verificados manualmente, através de uma técnica de revisão e inspeção. 
Também é feita uma análise manual ou automática buscando inconsistências, como 
descrições conflitantes, nomes duplicados ou que estejam faltando. Como na análise 
, 
 
 
32 
 
de completude, a Análise de Consistência pode gerar ações corretivas e algum 
retrabalho. 
A terceira análise, a de Correção, pode ser feita por alguma ferramenta eletrônica ou 
manualmente, e busca erros na modelagem. Existe uma gramática e uma simbologia 
que precisam ser seguidas em cada padrão de modelagem. Na UML, por exemplo, 
existe um símbolo para Repositório de Dados diferente do símbolo para Função de 
Programação. Usar o símbolo errado pode gerar um entendimento completamente 
diferente do que se espera do software, perdendo qualidade, tempo e provocando 
retrabalho nas fases adiantadas do desenvolvimento, o que aumenta o custo de se 
refazer aquela funcionalidade. 
É necessário manter também a Rastreabilidade das diferentes versões e documentos 
da modelagem. Imagine que se uma alteração é feita num determinado modelo, essa 
mudança precisa estar refletida nos demais modelos. Como falamos antes, os modelos 
oferecem diferentes visões do mesmo software. Quando mudamos uma visão, 
podemos precisar mudar outras visões relacionadas àquele componente ou 
funcionalidade. 
Nenhuma análise estaria completa sem analisarmos também as interações entre as 
diferentes entidades e o software, buscando saber como o software vai se comportar 
com o sistema operacional do computador ou computadores, com os softwares de 
gerenciamento de banco de dados, com outros softwares e módulos de software e 
ainda em alguns casos, com elementos da segurança de informação, como antivírus e 
firewalls. 
3.3 UML e DFD 
UML é a sigla para Unified Modeling Language. Diferente de uma linguagem de 
computador, a UML é uma linguagem visual para visualizar, projetar e construir 
software, além de ser capaz de modelar processos de negócio. UML é um padrão de 
como construir diagramas, que modelam diferentes aspectos do software e o 
comportamento que o software precisa apresentar em determinadas situações. 
, 
 
 
33 
 
A primeira versão da UML já tem 20 anos e podemos dizer que é um padrão aceito 
internacionalmente, mantido e controlado pela OMG (Object Management Group), um 
consórcio que reúne empresas, acadêmicos, universidades, profissionais e entidades 
com o objetivo de criar e manter padrões para a indústria de tecnologia como um todo 
e acabou ficando encarregado de vários padrões. Além da UML, também mantém o 
padrão BPM para processos de negócio, CISQ para qualidade do software e até mais 
recentemente, o IoT Consortium que fala de Internet das Coisas [2]. 
Assim, a UML consiste numa série de diagramas que podem modelar o software de 
diferentes visões, como Modelagem Comportamental, Modelagem Estrutural e 
Modelagem de Informação. 
 
Fonte: OBJECT MANAGEMENT GROUP – OMG® Unified Modeling Language – Versão 2.5 [3] 
Figura 3.1−Diagramas e divisões (Structure Diagram = diagrama de estrutura, Behavior 
Diagram – diagrama de comportamento). 
Como podemos ver na Figura 3.1, são 14 diagramas em 3 divisões. A lista de diagramas 
(traduções) é: Diagrama de Atividades, Diagrama de Classes, Diagrama de 
Comunicação, Diagrama de Componentes, Diagrama de Composição de Estrutura, 
Diagrama de Entregas, Diagrama Geral de Interações, Diagrama de Objetos, Diagrama 
, 
 
 
34 
 
de Pacotes, Diagrama de Perfis, Diagramas de Estado de Máquina, Diagrama de 
Sequência, Diagrama de Tempo e Diagrama de Caso de Uso. 
Não é nosso objetivo aqui estudar a UML toda, mas alguns diagramas são 
interessantes para entender a prática da modelagem, parte importante da Engenharia 
de Software. 
Um diagrama de Caso de Uso vai dizer quem são os atores e que relacionamentos eles 
têm com quais atividades do sistema. Não é o caso de entrar em detalhes sobre como 
funciona cada uma das atividades que o sistema irá executar. Esse detalhamento será 
feito através do Diagrama de Atividades. O caso de uso serve para avaliarmos apenas 
quem são as pessoas que usariam o sistema e o que elas gostariam que o sistema 
fizesse. É uma espécie de entendimento de alto nível, uma visão de como o sistema 
precisará se comportar para cada tipo de usuário. Usamos uma simbologia própria 
para identificar os Atores (bonecos), as Atividades (ovais) e osRelacionamentos 
(linhas). O que seriam atividades agrupadas dentro do software fica dentro de um 
retângulo. O interessante aqui é que qualquer Engenheiro de Software sabe 
reconhecer o Diagrama e sabe interpretar seu significado [3]. 
 
Fonte: adaptado de https://sg.com.mx/revista/27/papel-analista-programador 
Figura 3.2 – Representações de atores, atividades e relacionamentos. 
https://sg.com.mx/revista/27/papel-analista-programador
, 
 
 
35 
 
Vamos imaginar um aplicativo simples para que um profissional possa criar um perfil, 
concorrer a uma vaga e que o recrutador possa procurar candidatos a emprego no 
mesmo aplicativo. Representaríamos os atores Profissional e Recrutador como 
bonecos, interagindo com diferentes atividades, que estão encapsuladas dentro de um 
objeto de software, o aplicativo sendo modelado. 
Com base nesse diagrama de Caso de Uso, seriam construídos 3 diagramas de 
atividade: Administrar Perfil, onde o candidato Profissional preencheria suas 
informações; Buscar candidatos, que é usado pelo Recrutador, seria outra atividade e 
teria seu próprio diagrama; e finalmente haveria outro diagrama de atividades para 
Aplicar para vaga, que também seria usado pelo Profissional. 
Já DFD (Data Flow Diagram ou Diagrama de Fluxo de Dados) é outra forma de 
representação de alto nível que foca nos dados e não na interação das pessoas. Não 
faz parte da UML, sendo outra técnica de modelagem, mais antiga (vem sendo usada 
desde a década de 1970), que pode modelar bem uma funcionalidade qualquer do 
software. Um modelo gráfico pode explicar algumas coisas melhor do que palavras. 
Como são fáceis de compreender pelo público técnico e não técnico, ainda são usados 
mesmo depois de tanto tempo. 
Um DFD representa Entidades, Fluxo dos Dados, Processos e Repositórios de dados. 
Um DFD pode ter vários níveis, cada nível detalhando mais cada processo. Mesmo 
assim, não é suficiente para mapear toda a complexidade do software, mas é um 
excelente ponto de partida para a criação de outros modelos, inclusive os diagramas 
propostos na UML [5]. 
Fonte: o autor 
Figura 3.3 – Exemplo de DFD nível 0. 
, 
 
 
36 
 
 
Na Figura 3.3, temos um DFD nível 0 sobre o mesmo exemplo dado antes: um 
Profissional que quer se cadastrar num aplicativo e o Recrutador procurando 
candidatos. Podemos ver que tipo de dados o Profissional precisa informar. Quando 
“descermos” um nível, é detalhado quais dados pessoais devem ser informados e 
como seria o processo para conferir esses dados (verificação do dígito do CPF, apenas 
números no CEP etc.) e que dados sobre as vagas ele receberia. Outro DFD de nível 1 
poderia ser feito para descrever o processo do Recrutador e os dados de candidato 
que ele receberia, só para ficar mais claro. 
 
3.4 Metodologias Ágeis 
Os métodos ágeis nasceram a partir do final dos anos 1990, quando metodologias mais 
leves começaram a ser propostas, tanto para a modelagem quanto para o 
gerenciamento dos processos de software, porque os desenvolvedores estavam 
usando muitas metodologias pesadas e com intensivo trabalho de documentação, 
sobrando menos tempo para a atividade de programação em si [1]. Na nossa opinião, 
surgiram porque fazer documentação é uma tarefa que dá trabalho mesmo, exige 
atenção e cuidado. O desenvolvedor prefere as atividades de programação e 
codificação, que oferecem um nível de desafio bem maior, sendo por isso mais 
“divertidas” do que ficar escrevendo documentos. Desenhar os modelos é desafiador, 
até mais do que a programação em si, já que a solução do problema tem que ser 
pensada e analisada antes de ser codificada para a máquina. 
RAD (Rapid-Application Development) é uma técnica que foca mais numa abordagem 
de processo adaptativo e menos em planejamento. Frequentemente, são empregados 
protótipos ao invés de especificações e modelagem [1]. Dependem de se ter uma boa 
ferramenta de software para a construção dos protótipos e adaptação e controle dos 
erros e ajustes necessários. Imagine o risco de você construir uma casa e depois que a 
casa estiver pronta e com gente morando, ter que aumentar o tamanho dos quartos? 
Por isso, metodologia ágil não pode ser sinônimo de falta de planejamento. No lugar 
da especificação e da modelagem, o protótipo tem que ser feito com cuidado e 
, 
 
 
37 
 
discutido com os stakeholders. Assim, se consegue mais detalhes sobre o que o 
software precisa fazer e quais são as necessidades fundamentais, que diminuem muito 
as chances de erros grosseiros comprometerem o produto de software sendo 
desenvolvido. 
XP (eXtreme Programming) utiliza de outro artefato para substituir a modelagem. Usa 
histórias ou cenários no lugar da modelagem e da especificação. Os usuários passam a 
fazer parte da equipe de desenvolvedores criando os cenários de teste e as situações 
em que o software vai ser usado desde os estágios iniciais do desenvolvimento, sendo 
uma metodologia bastante interativa. 
Scrum é um procedimento mais amigável para gerenciar o projeto como um todo. É a 
reunião dos jogadores de Rúgbi ou Futebol Americano antes de fazerem uma jogada. A 
metodologia tem esse nome porque a equipe se reúne todos os dias, por 15 minutos, 
antes de começarem suas atividades diárias. É criado um Backlog (registro completo) 
de todas as tarefas que precisam ser feitas e ciclos de 2 a 4 semanas são feitos para 
produzirem alguns itens do backlog. Esses ciclos, que são chamados Sprints (corridas 
ou campanhas, como as jogadas do rúgbi), produzem uma parte das funcionalidades, 
que são então testadas pelos usuários e liberadas. Um novo Sprint é então priorizado 
com mais itens do backlog, até que todas as tarefas estejam completas e o software 
aprovado e testado pelos usuários. 
Outra metodologia ágil comum no mercado é a FDD (Feature-Driven Development), 
que significa uma abordagem direcionada para as funcionalidades. São trabalhadas 5 
fases: 
1) Desenvolver um modelo do produto; 
2) Criar a lista de funcionalidades e tarefas; 
3) Construir o plano de implementação; 
4) Desenvolver as funcionalidades de integração e interface com as pessoas; 
5) Codificar e testar de forma integrada o software. 
É uma abordagem que se parece com XP ao criar cenários, mas ao contrário das 
metodologias incrementais que vão detectando falhas e refazendo ao longo do 
, 
 
 
38 
 
processo de desenvolvimento, essa metodologia foca em criar um modelo correto da 
primeira vez e evitar retrabalho e várias interações [1]. 
3.5 Aspectos Humanos e Profissionais 
Além da importância de se pensar no usuário e que tipo de interface o usuário vai ter, 
o dispositivo computacional que ele vai usar e coisas assim, temos que pensar em 
alguns outros aspectos humanos. Fazemos software para pessoas usarem. A tecnologia 
existe para facilitar a vida das pessoas. 
O Engenheiro de Software ou o Desenvolvedor precisa se relacionar com os demais 
stakeholders e obter deles as informações necessárias para a criação de bons modelos, 
aperfeiçoar os requisitos e testar os softwares para que funcionem corretamente. 
Precisamos pensar que o Desenvolvedor e principalmente o Engenheiro de Software 
não deveriam ser focados só em aspectos técnicos e de programação de 
computadores. É necessário desenvolver habilidades ligadas com Pensamento 
Analítico e Solução de Problemas. É necessário assimilar vários tipos de informações 
rapidamente (diagramas, preocupações de stakeholders, feedback de usuários, 
esquemas e planilhas), identificar quais são mais relevantes, apresentar soluções e 
escolhas aos stakeholders as quais ofereçam valor, que sejam apropriadas ao problema 
em questão, resolvam de forma rápida e apresentem ideias complexas de forma 
simplificada. Essa habilidade de Pensamento Analítico e Solução de Problemas é 
composta por pensamento criativo, aprendizagem, tomada de decisão, pensamento 
conceitual e sistêmico [6]. 
Todas são habilidades quepodem ser aprendidas e que melhoram com a experiência e 
a prática. Acho que se você compreende como você aprende melhor, se de forma 
visual, escutando ou lendo, vai desenvolver as suas habilidades rapidamente. 
Também são esperadas características comportamentais do Engenheiro de Software. 
Ética, adaptabilidade, organização, gerenciamento do tempo e ser sempre aquela 
pessoa com quem se pode contar [6]. Essas também são características que melhoram 
com a experiência. 
, 
 
 
39 
 
Seja parceiro dos stakeholders. Aprenda com eles como funcionam o negócio e a 
empresa. Então, quando for criar um software, você já sabe como o negócio opera e 
terá ideias e conceitos do que o software poderá fazer, de forma eficiente. O mesmo 
se aplica para qualquer software. Um jogo de tiro em primeira pessoa tem objetivos e 
jogadores bem diferentes de um RPG, por exemplo. 
Saiba ouvir. Habilidades de comunicação são fundamentais para entender os 
problemas dos stakeholders, mas mais do que comunicar suas soluções de forma clara, 
saber ouvir e entender as preocupações e desejos dos seus usuários é o que fará você 
desenvolver aquela funcionalidade “matadora”, que atende o necessário de forma 
eficiente. Essa é uma habilidade que não é ensinada em lugar nenhum, mas que você 
consegue melhorar e desenvolver sozinho. Lembre-se de que comunicação pode ser 
verbal e não verbal. 
Uma forma efetiva de comunicação consiste em adaptar os estilos e as técnicas para a 
sua audiência, para quem pretende enviar a mensagem. O tom de voz, a linguagem 
corporal, as palavras usadas. E na comunicação escrita ou gráfica, como nos modelos 
também [6]. Pense em quem será sua audiência e como ela gostaria de receber sua 
mensagem. 
 
Conclusão 
Neste bloco, foram abordados os principais tópicos da análise que a Engenharia de 
Software faz para a construção do software. E não chegamos a falar em especificações 
e requisitos ainda. A codificação é uma etapa posterior. Sem entendermos exatamente 
qual a tarefa e o tamanho do esforço antes mesmo de começarmos, não é possível 
estarmos preparados para resolver a situação e entregar um software funcional. 
Falamos da modelagem de software, das técnicas de modelagem, dos diferentes tipos 
de modelo existentes, apresentamos ferramentas de modelagem e técnicas ágeis, 
voltadas a facilitar o desenvolvimento do software e acelerar o processo. Também 
consideramos os aspectos humanos que o profissional de Engenharia de Software 
precisa desenvolver. 
, 
 
 
40 
 
Vimos que um bom modelo precisa ser completo, consistente e correto. Exploramos 
algumas técnicas para obter a completude do modelo, como a revisão e a inspeção, 
que também podem ser aplicadas à consistência do modelo, em que algumas 
ferramentas de software ajudam a encontrar os erros, e vimos que é necessário seguir 
um padrão para que o modelo seja corretamente compreendido por toda a equipe de 
desenvolvimento. 
Falamos das análises dos modelos, de como a rastreabilidade é importante para 
sabermos o que foi alterado, quem pediu a alteração e quando. E também vimos que 
analisar o ambiente do software, que interações ele terá com outros softwares, em 
que momentos e como se darão as interações é fundamental para determinarmos o 
bom comportamento do software e ajudarmos a manter a segurança das informações. 
Conhecemos a importância das diferentes visões que a modelagem propicia, como a 
Modelagem Comportamental, a Modelagem Estrutural e a Modelagem da Informação. 
Modelos diferentes que se integram e criam visões diferentes sobre o mesmo projeto, 
o mesmo produto de software. 
Quando olhamos para duas técnicas de modelagem, o DFD e a UML, vimos pequenos 
exemplos de como a modelagem é criada e como manter o padrão tão necessário para 
que a equipe saiba o que está sendo feito. DFD é uma técnica antiga, mas ainda usada 
pela simplicidade e efetividade ao comunicar conceitos complexos para os 
stakeholders não técnicos. Vimos um exemplo da UML e como as diferentes visões 
propostas são atendidas por essa técnica. 
Conhecemos 4 abordagens chamadas ágeis porque procuram usar menos tempo nos 
processos documentais e mais tempo nos processos mais ligados ao desenvolvimento 
em si, codificação e testes. RAD, XP, Scrum e FDD são metodologias diferentes, mas 
com o mesmo foco, que é colocar o software mais cedo em funcionamento, seguindo 
uma abordagem incremental, em que partes do software ficam prontas e começam a 
ser usadas mesmo antes de o todo estar completo. 
Elencamos os aspectos humanos do profissional de Engenharia de Software e algumas 
habilidades necessárias, que podem muito bem ser desenvolvidas e aprendidas e que 
, 
 
 
41 
 
melhoram com a experiência e a prática. Entre as habilidades, são importantes o 
pensamento analítico, a solução de problemas e a comunicação, fundamental para o 
trabalho com software, já que se está em contato com diferentes stakeholders durante 
todo o processo. 
 
REFERÊNCIAS 
[1] BOURQUE, Pierre; FAIRLEY, Richard E. (ed.). SWEBOK – Software Engineering Base 
of Knowledge. 3. ed. IEEE Computer Society, Piscataway, NJ, 2014. 
[2] OBJECT MANAGEMENT GROUP. About us. Disponível em: <http://www.omg.org>. 
Acesso em: 15 jan. 2020. 
[3] OBJECT MANAGEMENT GROUP – OMG®. Unified Modeling Language – Versão 2.5. 
Dez. 2017. Disponível em: <http://www.omg.org>. Acesso em: 15 jan. 2020. 
[4] RANGEL, Ricardo. Entre lo estático y lo dinámico: el papel del analista y del 
programador. Disponível em: <https://sg.com.mx/revista/27/papel-analista-
programador>. Acesso em: 14 jan. 2020. 
[5] LUCIDCHART. What is a Data Flow Diagram. Disponível em: 
<https://www.lucidchart.com/pages/data-flow-diagram>. Acesso em: 15 jan. 2020. 
[6] INTERNATIONAL INSTITUTE OF BUSINESS ANALYSIS. BABOK Guide to Business 
Analysis Base of Knowledge. 3. ed. Ontario, Canada: IIBA, 2015. 
 
 
 
 
 
 
 
 
http://www.omg.org/
http://www.omg.org/
https://sg.com.mx/revista/27/papel-analista-programador%3e.%20Acesso%20em:%2014%20jan.%202020
https://sg.com.mx/revista/27/papel-analista-programador%3e.%20Acesso%20em:%2014%20jan.%202020
, 
 
 
42 
 
 
4 REQUISITOS DE SOFTWARE 
 
Apresentação 
Neste bloco, vamos ver a importância de uma boa especificação de requisitos para o 
desenvolvimento do software. Junto da modelagem, onde entendemos o problema e 
visualizamos a solução, precisamos especificar o que deverá ser entregue para os 
programadores para que possam então codificar, ou seja, transformar nossas soluções 
em código de máquina, o software propriamente dito. Para que isso aconteça de 
acordo com o planejado, precisamos seguir os passos da modelagem, analisar, 
especificar e validar os requisitos para termos certeza de que o modelo realmente 
representa a realidade. A principal diferença é o nível de detalhamento que a 
especificação tem que trazer. Normalmente, os programadores são especializados em 
código e linguagens de programação e não conhecem as regras de negócio. É um 
conjunto diferente de habilidades. A situação fica ainda mais delicada quando 
precisamos dar manutenção a um software existente. Incluir novos requisitos, alterar 
partes do software existentes que precisam ser mudadas, seja porque há novos 
requerimentos legais, ou seja, porque há novas regras de negócio, é uma tarefa que 
precisa de bem mais detalhamento para que as mudanças que queremos implementar 
não afetem outras partes do código que não queremos mexer. 
 
4.1 Fundamentos de Requisitos 
O termo “engenharia de requisitos” é amplamente usado no mercado para mostrar o 
tratamento e a importância dessa área da Engenharia de Software. Algumas vezes, um 
Engenheiro de Software se torna especialista em requisitos e, outras vezes, é 
necessário um Engenheiro de Software experiente para que a construção dos 
requisitos seja feita de forma adequada. Imagine que um software pode levar vários 
meses para ficar pronto e se os requisitosnão forem bem especificados no início, após 
todo esse tempo e todos esses gastos, o resultado pode ser insatisfatório ou até 
desastroso. 
, 
 
 
43 
 
Requisitos de software expressam as necessidades e restrições colocadas em um 
produto de software que contribuem para a solução de algum problema da vida real 
[1]. Pode ser desde a automação de uma tarefa feita num processo de negócios, 
integração entre processos de negócio, como pagamento por cartão, até a operação 
de um dispositivo ou máquina, só para exemplificar os tipos de coisas da vida real onde 
pode ser empregado um software. Se um software for empregado, é necessário que se 
diga quais são os requisitos para que a operação do software seja considerada bem-
sucedida. 
O modo como as pessoas trabalham, como os processos de negócio acontecem e 
como os dispositivos funcionam podem ser bastante complexos, e por extensão, os 
requisitos também podem ser bem complexos. Por isso, pode ser necessário o 
envolvimento de várias pessoas, em diferentes áreas da empresa, com conjuntos de 
habilidades diferentes e vários níveis diferentes de especialização. Imagine um 
software que vai fazer triangulação fiscal, no qual um produto é comprado pela 
Internet em um estado, para ser pago por outra pessoa em outro estado e deverá ser 
entregue ainda em outro estado. A emissão da NFe, a apuração dos impostos e os 
registros bancários para cobrança e a contabilização de toda a operação podem gerar 
muitos requisitos para o software. Um robô soldador que precisa montar o chassi de 
um veículo na linha de montagem pode ter requisitos mais complexos se ele for 
responsável por verificar se o material está adequado, na posição certa, virar a peça ou 
peças para a montagem, e ainda a verificação de qualidade para procurar rachaduras 
depois de montado o chassi. 
Também temos que entender que existem vários tipos de requisitos. Requisitos de 
processo, de produto, de performance, de qualidade. Eles podem ser agrupados em 
duas categorias principais: os requisitos funcionais e os requisitos não funcionais. 
Requisitos funcionais descrevem as funções que o software precisa executar e são 
chamados também de funcionalidades ou capacidades [1]. Requisitos não funcionais 
são aqueles que agem para restringir ou limitar a solução, e podem ser chamados de 
restrições, ou às vezes, de requisitos de qualidade [1], como por exemplo, quando 
, 
 
 
44 
 
especificamos que uma transação de pagamento por cartão tem que executar em até 
30 segundos. Esse tipo de requisito impõe um limite para o software cumprir. 
O processo para trabalhar com requisitos envolve o planejamento de como vamos 
lidar com eles naquele projeto em particular. Cada projeto de software tem 
características únicas e as atividades de elicitação, análise, especificação, validação e 
testes devem ser projetadas de acordo com as especificidades de cada projeto. Além 
disso, precisamos entender o papel que as diferentes pessoas irão exercer no projeto. 
Temos que lidar com os usuários, que irão dizer quais são os problemas que eles têm e 
que necessitam de uma solução. Às vezes, os usuários são máquinas e precisamos 
entender como elas precisam interagir com o software que estamos criando. Há ainda 
os clientes, que são os que encomendaram o produto e não necessariamente vão 
operar o software, como os usuários. Também no projeto, teremos os Engenheiros de 
Software, Gerentes de Projeto, Programadores e outras pessoas exercendo as funções 
técnicas. Muitas vezes, as funções técnicas entram em conflito com as funções de 
negócio. O programador ou o engenheiro podem querer aproveitar uma 
funcionalidade criada antes em outro produto (reúso de componentes) e o cliente ou 
usuário querem um novo cadastro. É papel do Engenheiro de Software pesar o que é 
mais vantajoso para o projeto como um todo. 
4.2 Elicitação de Requisitos 
Elicitação de requisitos tem a ver com as origens dos requisitos de software e como o 
engenheiro de software pode capturar esses requisitos [1]. Elicitar significa “fazer 
aparecer”. Esse é o primeiro estágio no entendimento do problema, e é 
essencialmente uma atividade humana, porque envolve muita comunicação. Significa 
estabelecer o relacionamento entre a equipe de desenvolvimento de software e a 
equipe do cliente, junto aos usuários. Se esse relacionamento não funcionar, não se 
consegue resolver o problema através de um software. Como exemplo, um problema 
vivido em equipe de desenvolvimento, relacionado aos impostos no Brasil, que são 
complicados. Após reunião com uma usuária, a equipe acreditava que não seria tão 
complicado. Com o tempo, ao se fazer o levantamento de requisitos, foi descoberto 
que só 30% dos impostos estavam sendo contemplados. Ao se verificar com a usuária, 
, 
 
 
45 
 
ela disse que não quis passar todos os detalhes de uma vez porque eram muito 
complicados. Só após uma segunda reunião, mais detalhes foram descobertos e a 
equipe de desenvolvimento pôde finalmente perceber toda a complexidade e o 
tamanho do esforço necessário para que o software pudesse calcular os impostos 
corretamente. Imagine se só fosse descoberto isso ao final do projeto, com o software 
todo praticamente pronto. A quantidade de retrabalho que precisaria ser feito poderia 
encarecer demais o software, além de provocar um atraso significativo, sem falar em 
desdobramentos que poderiam afetar a qualidade final do produto de software. 
A comunicação entre os técnicos e os usuários é fundamental para que os requisitos 
possam ser elicitados corretamente desde o princípio. É com base nesses 
levantamentos que a modelagem será feita, que os requisitos serão especificados e 
que o código de máquina será criado. Provavelmente, essa é a atividade mais 
importante em toda a Engenharia de Software. 
Alguns termos são fundamentais na compreensão do software como um todo e para 
os requisitos em particular, e o engenheiro de software deveria estar familiarizado 
com esses termos: 
 Metas: também chamadas de fatores críticos de sucesso, se referem aos 
objetivos gerais que o software precisa atender. A partir daí, um estudo de 
viabilidade pode determinar se vale a pena atender esse objetivo geral ou não. 
 Conhecimento da área: o engenheiro de software ou alguém na equipe deveria 
ter um conhecimento prévio do assunto tratado pelo software. Um software 
para controle de estoque fica mais bem projetado por alguém que entenda de 
logística. 
 Stakeholders: são as pessoas envolvidas. Não podemos deixar de ouvir todas as 
pessoas envolvidas com o software e sua futura operação. Às vezes, um grupo 
de pessoas não representa todo o conjunto de possibilidades, todos os pontos 
de vista. 
 Regras de Negócio: essas são afirmações que definem ou restringem algum 
aspecto da estrutura ou do comportamento do negócio em si [1]. “O cliente 
, 
 
 
46 
 
pode pagar com cartão de crédito à vista ou parcelado ou com boleto à vista e 
5% de desconto”. Essa é uma regra de negócio clara sobre o tipo de 
pagamentos com que o software terá que lidar. A partir dela, serão criados os 
requisitos para atender a regra de negócio. 
 Ambiente Operacional: vai determinar em que condições o software irá 
operar. Um software hospedado na nuvem terá requisitos não funcionais que 
irão especificar como se dará a conectividade e como proceder na falta de 
conexão. Bem diferente de um ambiente operacional de um aplicativo 
instalado num tablet. 
 Ambiente Organizacional: é o ambiente da empresa ou da organização que irá 
usar o software. Entre empresas ou organizações e até de uma pessoa para 
outra, há diferenças de valores, conhecimento, procedimentos, estrutura, 
política interna e cultura, principalmente a cultura organizacional. Pense numa 
empresa pequena com 3 funcionários e uma multinacional com 3.000. O 
ambiente organizacional de cada uma é bem diferente. 
Depois de identificada afonte dos requisitos, eles podem começar a ser levantados. 
Alguns são facilmente determinados, como por exemplo, um requisito legal. Está na 
lei, existe uma portaria a respeito e basta seguir o que está escrito. Mas para lidar com 
humanos é melhor empregar técnicas de facilitação para garantir que se obtenham os 
requisitos da melhor forma possível. 
Entrevistas são boas para obter requisitos de uma ou bem poucas pessoas. É uma 
técnica direta, mas algumas perguntas importantes precisam ser feitas e é bom terem 
sido pensadas antes de a entrevista começar. 
Para situações mais complexas ou que envolvam mais pessoas, é interessante pensar 
na construção de cenários. Cenários são ótimos para o Engenheiro de Software 
construir um entendimento da situação e fazer perguntas tipo “como isso é feito” ou 
“o que acontece se”. Uma ferramenta bastante usada para a construção de cenários é 
o diagrama de caso de uso, proposta pela UML. 
, 
 
 
47 
 
Uma técnica usada para esclarecer requisitos é a técnica de prototipagem, na qual um 
protótipo é construído e pode prover aos usuários um contexto para que digam 
exatamente o que precisa ser feito e como. Os tipos de protótipo vão desde o 
rascunho de uma tela no papel, até a construção de uma tela com funcionalidade 
limitada, mas dentro do contexto que se busca compreender e esclarecer. 
As reuniões facilitadas podem trazer os “insights” do grupo para os requisitos do 
software em construção. Uma discussão em grupo pode trazer melhores resultados do 
que as pessoas trabalhando individualmente. Quando bem executada, essa técnica 
pode trazer resultados mais ricos e mais consistentes, e os requisitos conflitantes 
aparecem mais cedo no projeto e podem ser discutidos pelo grupo para ser 
encontrada uma solução. 
A equipe de desenvolvimento também pode conseguir entender melhor o problema 
através da observação. Nessa técnica, o Engenheiro de Software faz uma imersão no 
ambiente do usuário e acompanha como suas tarefas são executadas e como ele 
interage com outras pessoas e de quais ferramentas ele faz uso para completar seu 
trabalho. É uma verificação “in loco” do que acontece e quais resultados são os 
desejados. 
Já User Stories (Estórias de Usuário) é uma técnica muito usada com metodologias 
ágeis, que são mais adaptativas e vão sendo construídas com a participação do 
usuário. São descrições curtas e sem muito detalhamento daquilo que o usuário 
precisa que o software faça para ele. Nessa técnica, deve-se ter informação suficiente 
para que seja estimado o esforço necessário para que o software atenda a expectativa. 
Essas são as mais comuns, mas para elicitação de requisitos existem muitas outras 
técnicas, que vão desde analisar produtos concorrentes até mineração de dados para 
compreender o mercado que o cliente opera e tentar saber com que dados o software 
vai operar. É uma fase de muita importância, então quanto mais se souber logo no 
início do desenvolvimento, melhor a qualidade do produto final, com menos custos 
envolvidos e sem muitas “surpresas” durante o desenvolvimento, que geram 
retrabalho e por isso mais custos. 
, 
 
 
48 
 
4.3 Análise de Requisitos 
A visão tradicional da análise de requisitos tem sido a abordagem da modelagem 
conceitual, feita por uma técnica como análise estruturada ou UML. No entanto, a 
análise de requisitos se preocupa muito com muitos outros aspectos do que só 
modelar o problema. 
Entender como os requisitos são classificados, quais são requisitos funcionais e quais 
são não funcionais é essencial, bem como saber quais requisitos são derivados de uma 
ou mais solicitações, quais são os requisitos que vêm de requerimentos legais, para 
atender plenamente a legislação, quais requisitos são propriedades emergentes, ou 
seja, surgem a partir da integração entre os vários componentes do software e/ou 
integração entre as pessoas e os dispositivos com os componentes do software. 
Também é importante diferenciar requisitos de produto e requisitos de processo, que 
podem restringir a escolha da empresa contratada, da equipe de desenvolvimento, do 
processo de engenharia de software adotado ou o padrão a que se adere. 
A análise também envolve determinar a prioridade dos requisitos. Alguns requisitos 
precisam ficar prontos antes de outros para que o software apresente a funcionalidade 
desejada. Outras vezes, o cliente pede por certas funcionalidades antes de outras, e 
ainda o processo de trabalho pode fazer com que alguns requisitos sejam atendidos 
com prioridade. Isso pode levar a escopo de requisito maior ou menor. O escopo 
determina a extensão na qual um determinado requisito afeta o software como um 
todo ou seu componente de software. 
Alguns requisitos podem ser voláteis, ou seja, podem mudar durante o ciclo de vida de 
desenvolvimento do software. Enquanto outros requisitos podem ser mais estáveis e 
permanecerem do mesmo jeito do começo ao fim. Um requisito que peça que o 
software aumente o desconto na semana depois do Natal pode mudar se o cliente não 
desejar mais conceder descontos, enquanto o requisito para processar o meio de 
pagamento “cartão de crédito” pode ser mais estável porque o negócio não vê motivo 
para deixar de aceitar cartão de crédito. 
, 
 
 
49 
 
O desenvolvimento de modelos que simulem o mundo real é chave para entender os 
requisitos e analisar possíveis soluções. Diversos modelos diferentes podem ser 
usados, bem como diferentes ferramentas, como diagrama de caso de uso ou 
diagrama de fluxo de dados. Muitas dessas ferramentas são parte da UML e bem 
definidas na literatura. Outras formas podem envolver a construção de protótipos ou 
histórias de usuário. A escolha da modelagem vai depender de vários fatores, como a 
natureza do problema, que pode ser mais complexo ou menos complexo. Um 
problema mais complexo pode exigir uma modelagem mais rigorosa, com mais 
detalhes. Para outro menos complexo, pode ser suficiente um protótipo da tela em 
papel ou uma história de usuário. A experiência e o conhecimento da equipe de 
Engenharia de Software podem influenciar a escolha da modelagem, em virtude de 
estarem familiarizados mais com um método que outro. Também o cliente pode exigir 
que se use uma determinada ferramenta ou técnica. 
Muitas vezes, acontece que alguns requisitos são incompatíveis com outros. Alguma 
negociação precisa ser feita entre os stakeholders para resolver os conflitos. Sejam 
problemas entre funcionalidades conflitantes, funcionalidades que exijam muitos 
recursos (de pessoal ou de dinheiro), sejam soluções tecnicamente inviáveis, diversos 
conflitos aparecem durante os projetos de desenvolvimento de software. Melhor que 
sejam resolvidos na fase de análise, na qual as soluções estão sendo propostas e a 
validação, codificação e testes ainda não aconteceram. Isso vai gerar menos retrabalho 
depois. Entenda que depois de codificado, recodificar um software pode ser muito 
difícil, exigindo que partes inteiras tenham que ser refeitas devido às várias 
integrações entre os componentes e entre o software e o ambiente externo. Algumas 
cláusulas contratuais podem impor restrições no produto de software, no tipo de 
solução que se quer empregar, na priorização dos requisitos, e pode levar a conflitos 
entre os stakeholders. 
Na sua análise, procure usar métodos formais, bem definidos, com uma semântica 
conhecida e de domínio pela equipe de desenvolvimento. Especialmente em projetos 
grandes, complexos, com muitas integrações. Seguir um padrão bem definido facilita a 
análise de duas maneiras: oferecer uma linguagem padronizada permite que os 
, 
 
 
50 
 
requisitos sejam expressados de forma clara, sem ambiguidades e mal interpretação, e 
em segundo lugar, permite que as soluções sejam discutidas, entendidas e esclarecidas 
de forma inequívoca, justamente porque os requisitos estão expressados 
formalmente. Só não esqueça que a formalizaçãototal deve ser feita ao final do 
processo, dando mais liberdade no início para a criação de ideias e soluções novas nos 
estágios iniciais da análise. 
4.4 Especificação de Requisitos 
Na Engenharia de Software, o termo “Especificação de Requisitos” se refere à 
produção de um documento que pode ser sistematicamente revisado, avaliado e 
aprovado [1]. Em sistemas muito complexos, especialmente os que têm vários 
componentes que não são software, como aplicações logísticas, com leitores de código 
de barra, headsets, tablets e outros dispositivos, podem ser necessários 3 documentos 
diferentes. 
Um documento é o documento de Definição de Sistema, onde é capturado o conceito 
das operações a serem desenvolvidas, incluindo fluxogramas das atividades e linhas 
gerais sobre o contexto em que o sistema foi idealizado, bem como casos de uso. É um 
documento que não se preocupa em detalhar cada requisito, mas provê um contexto e 
um cenário geral do sistema como um todo. 
Outro documento é chamado de Especificação de Requisitos de Sistema, e possui uma 
descrição dos componentes que não são software. No exemplo de um sistema 
logístico, aqui seria descrito o funcionamento dos leitores de código de barra, sua 
especificação técnica, capacidade e configuração de hardware e qual o tipo de 
integração com o software ele teria. Nesse exemplo, ainda, entrariam os diversos 
componentes de infraestrutura, como roteadores, impressoras, tipo de etiqueta usado 
e diversos detalhes que seria melhor outro tipo de engenheiro para criar essa 
especificação. 
E o terceiro documento é a Especificação de Requisitos de Software, onde sim seriam 
detalhados todos os requisitos para os vários componentes do software, com detalhes 
de modelagem e das soluções imaginadas durante a análise. É o documento que será a 
, 
 
 
51 
 
base para a contratação de serviços, para estipular o esforço necessário para codificar 
o software, sendo a base para determinar o prazo, o custo, os riscos e todos os 
detalhes do projeto de software. 
Os requisitos de software são construídos em linguagem natural, mas por vezes é 
necessário usar descrições formais da modelagem, como diagramas de caso de uso e 
outras ferramentas. Como regra geral, um requisito precisa estar descrito de forma o 
mais precisa possível. 
As organizações usam esse documento como base para estabelecer os critérios de 
qualidade e de aceitação do software. Imagine todos os detalhes da legislação fiscal 
brasileira sendo detalhados na forma de requisitos de software para que um 
desenvolvedor possa então codificar isso num componente de software que emita a 
NFe, faça a apuração dos impostos, os lançamentos contábeis e a baixa de estoque dos 
produtos vendidos, bem como o conhecimento de transporte para que a mercadoria 
possa trafegar pelas estradas sem ser considerada carga roubada. 
Nesses casos, mais de um requisito pode ser necessário para descrever todos os 
detalhes. O nível de detalhamento precisa ser o mais preciso possível porque estamos 
lidando com legalidades. Não cumprir a lei, ou apurar os impostos de forma 
equivocada pode ser considerado sonegação de impostos, e pode levar pessoas à 
prisão. Ou ainda, no caso de um software hospitalar, podemos estar falando de vidas 
humanas perdidas por ter especificações de software pobres, como não levar em 
conta doenças preexistentes no receituário dos pacientes. 
É importante que os requisitos de software possam ser usados para determinar riscos, 
custos, prazos e outros detalhes do projeto de software. Estes, inclusive, são 
considerados indicadores de qualidade para determinar se os requisitos estão bem 
definidos e explicados, para estabelecer a capacidade ou não que a descrição de um 
requisito tem de facilitar a determinação dos detalhes do projeto. 
Os requisitos de software também devem ser uma base bem informada para transferir 
o software para um novo usuário, em outras palavras, têm que fornecer uma 
plataforma para estudo e aprendizagem sobre o próprio software. Isso faz com que os 
, 
 
 
52 
 
requisitos de software sejam usados para outras tarefas, além da construção do 
software, como treinamento, melhorias no software (manutenção) e adoção do 
software para outras plataformas de operação (portabilidade). 
4.5 Validação de Requisitos 
Os documentos de requisitos estão sujeitos a procedimentos de validação e 
verificação. Os requisitos devem ser validados para assegurar que o Engenheiro de 
Software entendeu os requisitos [1]. É importante verificar que o documento esteja 
em conformidade com os padrões da organização, com as práticas do mercado e com 
a legislação ou outro marco regulatório da indústria. Bancos têm padrões elevados de 
segurança. Farmacêuticas devem seguir várias regras da vigilância sanitária, bem como 
a indústria de alimentos. 
Além das obrigações legais, a validação se preocupa em verificar o entendimento dos 
requisitos. Uma das formas de se validar o documento de requisitos de software é 
formar um comitê com vários stakeholders e repassar o documento, discutindo como 
foi o entendimento da equipe de desenvolvedores. Também na fase de validação 
podem ser feitos vários constructos e protótipos para que os usuários validem o 
entendimento através de uma funcionalidade ainda não implementada, e muitas 
vezes, ainda sem logomarcas e outros detalhes do produto final, mas que execute o 
requisito como foi especificado. 
Quanto antes for detectado que o entendimento do software não está de acordo com 
o especificado ou o entendimento não está de acordo com a necessidade do usuário, 
mais rápido e mais barato para fazer os ajustes necessários para que o software 
atenda plenamente às necessidades dos usuários. 
Algumas vezes, é necessário fazer uma prova de conceito. A prova de conceito é uma 
espécie de teste que se faz simulando as condições reais. De volta ao exemplo do 
sistema logístico, um teste com os leitores de códigos de barra, uma análise dos dados 
gerados por esses dispositivos e como capturar esses dados no sistema, impressão dos 
códigos em diferentes impressoras e tipos de papel, testes com a configuração do 
ambiente para evitar surpresas desagradáveis em fases mais avançadas do projeto. 
, 
 
 
53 
 
Será um desastre se o software for desenvolvido, implantado e testado, e na hora de 
utilizar, a etiqueta não fica legível para os leitores, ou o dado capturado pelo leitor não 
está em um formato compatível para ser usado pelo software. Por isso, provas de 
conceito devem ser feitas o mais cedo possível e seus resultados validados o mais cedo 
possível pelos usuários e clientes. Nem sempre aquilo que pensa o desenvolvedor é o 
mesmo que pensam os demais stakeholders. E frequentemente não é. Para o 
desenvolvedor, uma mensagem que fique poucos segundos na tela é suficiente para 
alertar de um problema, mas para o usuário no dia a dia, que nem sempre está todo o 
tempo olhando para a tela, pode não ser suficiente, e uma confirmação de leitura será 
necessária. 
Esse é o tipo de validação que se procura fazer nessa fase. Encontrar o máximo de 
divergências de entendimento entre a equipe de desenvolvimento e os demais 
stakeholders. Já foi falado sobre a importância da comunicação entre esses dois 
públicos diferentes. São tipos de pessoas distintos, com necessidades e visões de 
mundo bem diferentes, então uma validação é importante para assegurar a qualidade 
do produto final. 
 
Conclusão 
Neste bloco, você viu a importância da especificação de requisitos num projeto de 
software, os conceitos fundamentais sobre o que é um requisito, como funciona o 
processo de requisitos e suas fases principais: elicitação, análise, especificação e 
validação. 
Foram analisadas as principais técnicas para elicitação dos requisitos, técnicas e 
ferramentas como entrevistas, reuniões e observações. Com certeza, é uma fase muito 
importante, e acreditamos que sejaa mais importante da Engenharia de Software. 
Na análise de requisitos, vemos a aproximação com a modelagem. Nessa fase, é 
importante ter liberdade criativa para trazer soluções inovadoras e eficientes ao 
problema que o software propõe resolver. 
, 
 
 
54 
 
Especificação de requisitos é onde os requisitos são formalmente registrados e um 
documento de requisitos é produzido. Veja o exemplo: 
 
[RF001] Criar componente 
Descrição do caso de uso: Este caso de uso permite que o usuário crie e armazene um novo registro de 
produto no sistema de controle de estoque, de acordo com o protótipo RF001-P. 
Prioridade:  Essencial  Importante  Desejável 
Entradas e pré-condições: não tem. 
Saídas e pós-condição: um produto é cadastrado no sistema 
 
Aqui vemos um requisito funcional para que seja cadastrado um produto novo no 
estoque. Os dados a serem cadastrados estão no protótipo mencionado no exemplo. 
Tem alta prioridade, não tem nenhum pré-requisito e seu critério de validação é que 
haja um novo registro no sistema. Funcionalidade básica, um exemplo bem simples, 
mas ilustrativo do que seja um documento de requisitos. 
Por fim, a validação de requisitos cuida de revisar e garantir que o entendimento da 
equipe de desenvolvimento tenha sido correto e que não haja interpretações 
duvidosas. Também vimos algumas ferramentas e técnicas empregadas para essa 
finalidade, como a prova de conceito. 
É importante notar que a saída dessa fase é o documento de requisitos funcionais e 
requisitos não funcionais, que pode ser separado, dependendo do projeto e sua 
complexidade, e esse documento de requisitos é o que será a base para determinar 
toda a base do projeto de software, determinar o esforço necessário, quantos e quais 
especialistas serão necessários, custos, prazos e os critérios de aceite e de qualidade 
do produto de software final. 
REFERÊNCIAS 
[1] BOURQUE, Pierre; FAIRLEY, Richard E. (ed.). SWEBOK – Software Engineering Base 
of Knowledge. 3. ed. IEEE Computer Society, Piscataway, NJ, 2014. 
, 
 
 
55 
 
 
5 GESTÃO DE QUALIDADE DE SOFTWARE 
Apresentação 
Outro assunto importante na Engenharia de Software é a garantia da qualidade do 
produto de software criado. Imagine que algumas obras de engenharia civil foram 
feitas para durar muito tempo. Estações de metrô, pontes e viadutos (podemos incluir 
as pirâmides do Egito e a muralha da China). Para garantir a qualidade, alguns 
procedimentos foram criados ao longo do tempo na história humana. Creio que a ISO 
9000 é o termo que todos associam à qualidade. Os princípios fundamentais da norma 
podem ser aplicados ao software, pois, no fim das contas, software também pode ser 
um produto, e a norma atual absorveu suas variantes que tratam de procedimentos e 
projetos, e ficou ISO 9001:2015. Contudo, software também pode ser um serviço. E 
também pode ser parte de um produto e estar “embarcado” como numa Smart TV, 
por exemplo. Então, algumas normas específicas foram desenvolvidas, além de outros 
padrões mundiais. 
O objetivo deste bloco é apresentar os diferentes padrões e normas de qualidade, bem 
como as melhores práticas do mercado de software. Você já ouviu a expressão “está 
bugado”? Normalmente, essa expressão se refere a um “bug” num software. A 
associação de “bug” (inseto) com software remete aos primórdios da computação, 
quando uma mariposa (“bug”) entrou no computador, que na época era bem grande, e 
provocou um curto-circuito, que fez com que os programas não funcionassem mais. Ao 
dar explicações para o chefe, o responsável pela programação colou o pobre inseto 
com fita adesiva no relatório. Bem, é desses erros que estamos falando aqui. E claro, 
como prevenir erros no software. 
Vamos começar definindo qualidade como a conformidade com os requisitos [1]. 
Embora simples, é uma definição que casa bem com a Engenharia de Software, que 
estuda e propõe que se usem os requisitos para a construção do software. Perceba 
que essa definição não fala em atributos. Diz apenas “atenda os requisitos”. 
, 
 
 
56 
 
Outra coisa importante é saber que muitas vezes consertar um erro crítico é tão 
demorado e tão caro, que é preferível começar tudo de novo. Na obtenção dos 
requisitos, as expectativas e as necessidades devem ficar muito claras a todos 
stakeholders (envolvidos no projeto do software). 
 
5.1 Qualidade Funcional e Qualidade Estrutural 
Enquanto Crosby tem uma definição para a qualidade de forma geral, a definição de 
Qualidade de Software é a capacidade do produto de software de satisfazer as 
necessidades implícitas e declaradas dentro de determinadas condições [2]. Essa 
definição abrange a definição de Crosby de que a qualidade é obtida quando se 
atendem os requisitos [1], independentemente do tipo de requisito. 
Existe uma certa ambiguidade na Engenharia de Software quanto à Qualidade do 
Software e a Qualidade dos Requisitos de Software, mas fica claro que quando falamos 
de Qualidade dos Requisitos estamos falando das características funcionais do 
software, ou seja, aquilo que o software se propõe a fazer [3], a resolução dos 
problemas dos usuários. Mas não são apenas esses os requisitos de qualidade. Existem 
outros muito importantes, como seguir um determinado protocolo ou apresentar uma 
determinada performance ou executar num tipo de ambiente. Todas essas outras 
características são questões de Qualidade Estrutural. 
Sendo assim, a Qualidade Funcional pode ser definida como a qualidade aplicada aos 
requisitos funcionais, que são características e restrições diretamente ligadas às 
funcionalidades do software. Qualidade Estrutural seria todo o resto, ou seja, 
performance, ambiente onde o software será executado e outras características não 
funcionais [3]. 
A Qualidade do Software é a soma dessas duas. Sempre que se aborda o assunto 
Qualidade de Software, pense sempre no todo, ou seja, na qualidade dos requisitos 
funcionais e não funcionais, Qualidade Estrutural e Qualidade Funcional. 
É necessário ter em mente que qualidade é valor agregado para os stakeholders. Um 
produto de software que atende todas as expectativas de quem vai se beneficiar pelo 
, 
 
 
57 
 
uso do produto é um produto de qualidade. Como prefere a IBM, a qualidade é 
direcionada pelo cliente, que é o árbitro final que determina se o software tem 
qualidade ou não [4]. 
No processo de definirmos os requisitos, é importante determinarmos quais são as 
expectativas dos stakeholders, que desejos eles têm e talvez o mais importante, que 
necessidades eles têm. Especialmente quando falamos da Qualidade Funcional do 
software, muito frequentemente os stakeholders não têm uma ideia clara do que o 
software pode fazer por eles. É o entendimento do Engenheiro de Software que traduz 
os conceitos vagos dos usuários em requisitos funcionais bem definidos. Nessa hora, é 
importante estabelecer o critério de qualidade daquele requisito. E é baseado nesse 
critério de qualidade que o desenvolvimento do software deve ser feito e o esforço 
estimado. Essa estimativa leva à definição de custo e de prazo de entrega da 
funcionalidade. 
Quando falamos da Qualidade Estrutural, normalmente os requisitos não funcionais 
ficam na mão dos profissionais do desenvolvimento, da infraestrutura de TIC 
necessária para o funcionamento do software e todo um corpo mais técnico, que sabe 
exatamente quais são os requisitos não funcionais e as definições dos critérios de 
qualidade desses requisitos não funcionais ficam mais simples de serem obtidas. Não 
que seja sempre fácil, mas normalmente um conjunto de profissionais que sabe o que 
um recurso computacional pode fazer e como um software deve se comportar está 
envolvido com a obtenção dos requisitos não funcionais. 
 
5.2 Análise de Ponto de Função 
No começo do desenvolvimento de software, as maiores preocupações eram com 
tempo de máquina. Quanto menos tempo um software levava para serexecutado, 
melhor. O computador era um recurso caríssimo, difícil de operar, que exigia muitos 
recursos das organizações. Assim, a primeira métrica para saber se o software era 
bom, ou não, foi a contagem de linhas de código. Entretanto, linha de código trata-se 
de um termo subjetivo, que depende do programador, da linguagem de programação 
usada, da experiência do desenvolvedor e uma série de fatores não muito objetivos. 
, 
 
 
58 
 
A evolução natural dessa métrica é a Análise de Pontos de Função. Em vez de contar 
quantas linhas de código tem o software, são medidos quantos Pontos de Função tem 
o software. A Análise de Pontos de Função é uma técnica que mede quantas 
funcionalidades tem o software do ponto de vista do usuário, independentemente da 
tecnologia empregada para o desenvolvimento ou execução do software. É uma 
métrica associada aos requisitos de negócio (requisitos funcionais). E que pode ser 
executada desde o projeto, analisando para isso o documento de requisitos. Assim, se 
você souber logo nas fases iniciais quantos requisitos tem o software, conseguirá 
controlar melhor o projeto, fornecendo estimativas confiáveis de prazo e custo, além 
de assegurar que todos os pontos de função foram implementados, de acordo com os 
requisitos. 
Inicialmente proposto por Allan Albrecht em 1979, os requisitos funcionais definidos 
pelos usuários são identificados e classificados em 4 categorias: saídas, entradas, 
consultas e arquivos mestres. Cada uma dessas categorias tem um peso que é 
multiplicado pela quantidade. E esses pesos podem ainda ser ajustados. Se o tipo de 
consulta é complicado, pode ser acrescentado 5%, por exemplo. O resultado dessa 
soma é a quantidade de pontos de função do software. 
Essa abordagem tem sido desenvolvida e melhorada, e hoje em dia existem vários 
padrões e formas diferentes de cálculo, todas partindo desse mesmo princípio de 
medir as funcionalidades e comparar com os requisitos. O IFPUG (International 
Function Point User Group) assumiu a tarefa de evoluir o padrão criado por Albrecht 
desde 1986 e a norma ISO 20926 é baseada exatamente nesse método de cálculo. 
Existem ainda a ISO 29881, com a métrica criada chamada FiSMA Functional Size 
Measurement, ou Medida de Tamanho Funcional (em tradução livre), que propõe uma 
fórmula diferente para o cálculo. De forma similar, há a ISO 20968 Software 
Engineering – Ml II Function Point Analysis, a ISO 24570 Software Engineering – Nesma 
Functional Size Measurement Method e a ISO 19761 Software Engineering – A 
Functional Size Measurement Method. Também existem padrões desenvolvidos por 
associações profissionais como a OMG (Object Management Group) e outros métodos 
específicos criados por empresas e ainda não padronizados. Todos têm o objetivo de 
, 
 
 
59 
 
medir quantas funções tem o software e assim facilitar o projeto do software nos 
quesitos de qualidade e determinação do esforço necessário para o desenvolvimento. 
5.3 Normas de Qualidade 
Existem diversos padrões de qualidade definidos na ISO. A ISO 90003 oferece um guia 
de como usar a ISO 9001 para a aquisição, desenvolvimento e operação de software. 
Até a nova ISO 41062:2019 que foi recém-publicada e trata de aquisição de software, 
traz uma série de considerações sobre a qualidade de software. Contudo, a principal 
norma de qualidade de Software é a série ISO 25000. 
ISO 25000 é conhecida também como SQuaRE (System and Software Quality 
Requirements and Evaluation) (em tradução livre, Avaliação e Requisitos para a 
Qualidade de Software e Sistemas). Ela é, na verdade, uma série de normas. Vamos ver 
a lista: 
 ISO 25000 – Guia para o SQuaRE, que estabelece a terminologia, explica a série 
de padrões e dá outras definições básicas. 
 ISO 25001 – Planejamento e Gerenciamento, que oferece ajuda para o 
processo de gerenciamento da qualidade de software. 
 ISO 25010 – Modelos e Sistemas de Qualidade de Software, que descreve o 
modelo para a qualidade de software e o uso de software. 
 ISO 25012 – Modelo de qualidade de dados, que fornece um modelo para a 
qualidade dos dados armazenados em um sistema de computador. 
 ISO 25020 – Guia e modelo de referência de métricas, que apresenta uma 
explicação introdutória e um modelo de referência para métricas de qualidade 
de software. 
 ISO 25021 – Elementos de métricas de qualidade, que define um conjunto 
básico de métricas de qualidade para aplicação em todo o ciclo de vida do 
software. 
 ISO 25022 – Métricas para qualidade do software em uso. 
 ISO 25023 – Métricas para a qualidade do projeto de software. 
 ISO 25024 – Métricas para qualidade dos dados. 
, 
 
 
60 
 
 ISO 25030 – Métricas para qualidade dos requisitos, com várias recomendações 
para obtenção de requisitos com qualidade desde o início do desenvolvimento. 
 ISO 25040 – Guia e modelo de referência para auditoria de qualidade do 
software. 
 ISO 25041 – Guia de avaliação para desenvolvedores, compradores e auditores 
independentes. 
 ISO 25042 – Módulo de auditoria, define como serão os documentos 
produzidos no processo de auditoria. 
 ISO 25045 – Avaliação da capacidade de recuperação. Se há uma interrupção 
na execução do software, como o sistema como um todo se recupera. 
E ainda existe uma extensão, a ISO 25099 que compatibiliza a metodologia SQuaRE 
com outras normas e padrões internacionais. 
O SQuaRE prevê 8 características e várias subcaracterísticas. Em resumo, a qualidade 
de um sistema é avaliada pelo grau de satisfação com o produto que os stakeholders 
percebem. Essas necessidades dos stakeholders são representadas no modelo pelas 
várias características e subcaracterísticas. 
Adequação Funcional tem como subitens a completude funcional, a correção funcional 
e a adequação funcional, e representa o grau que as necessidades dos usuários são 
atendidas pelo software, quando este é usado da forma como foi projetado. 
Eficiência de desempenho representa como é o desempenho do software no consumo 
de recursos computacionais necessários para fazê-lo funcionar. Os subitens avaliam o 
quanto o software consome de tempo, de recursos e de capacidade. 
A característica Compatibilidade tem a ver com a capacidade do software de coexistir 
com outros softwares e funcionar adequadamente no hardware que ele estiver 
instalado. Os subitens são coexistência e interoperabilidade. 
A Usabilidade é a característica que atesta a satisfação de uso do software e possui os 
subitens adequabilidade, aprendizagem, operacionalidade, proteção contra erros do 
, 
 
 
61 
 
usuário, estética e acessibilidade, que é a capacidade para ser operado por pessoas 
com os mais variados graus de dificuldade motora, visual ou auditiva. 
Confiabilidade é a avaliação de quanto tempo o sistema opera nas suas condições 
ótimas e seus subitens são: maturidade, disponibilidade, tolerância a falhas e 
recuperabilidade, definida como a capacidade de se recuperar depois de uma falha. 
Já Segurança é a característica para proteção dos dados, tanto para acesso por pessoas 
não autorizadas quanto à permanência dos dados no sistema, e suas subcaracterísticas 
são: confidencialidade, integridade, autenticidade, não repúdio e prestação de contas. 
A característica Manutenibilidade tem a ver com a eficácia com que se pode realizar 
manutenção no sistema, seja para ajustar uma regra de negócio e até mesmo 
implementar novas funcionalidades. Seus subitens são: modularidade, reusabilidade, 
analisabilidade, modificabilidade e testabilidade. 
E, finalmente, Portabilidade é a condição de o sistema ser levado para outra 
plataforma e manter suas especificações funcionando. Seus subitens são: 
adaptabilidade, instalabilidade e substituição. 
 
5.4 Melhores Práticas de Qualidade 
Além dos diferentes padrões e normas, existem conjuntos de melhores práticas 
adotados pelo mercado. Desses conjuntos de melhores práticas, o mais conhecido e 
usadoé o chamado CMMI, mantido pelo CMMI Institute, uma subsidiária da ISACA, a 
associação de auditores de sistemas de informação, que atualmente estabelece vários 
padrões de melhores práticas para auditoria, gestão de risco e governança da área de 
Tecnologia da Informação. 
CMMI é um modelo integrado de capacitação para a maturidade. É um modelo 
evolutivo da sua capacidade de fazer software cada vez melhor. Atualmente, o CMMI 
se concentra em 3 áreas diferentes: CMMI-DEV, para desenvolvimento de aplicações; 
CMMI-SVC, para serviço e suporte técnico; e CMMI-ACQ, para as aquisições de 
software. 
, 
 
 
62 
 
Basicamente, temos 5 níveis de maturidade dos processos. No nível 1, chamado de 
Inicial, os processos são imprevisíveis e pouco controlados. O nível 2 é chamado de 
Gerenciado e aqui os processos são agregados a um projeto e basicamente são 
reativos. O nível 3 é chamado de Definido e os processos são organizados, proativos e 
conhecidos por todos. Já no nível 4, chamado de Quantitativamente Gerenciado, os 
processos são medidos e controlados. Finalmente, o nível 5 é chamado de Otimizado e 
o foco está na melhoria contínua dos processos. 
5 Foco contínuo na 
melhoria dos 
processos. 
 
 
4 Processos são 
medidos e 
controlados. 
 
 
3 Processos são 
caracterizados para 
Organização e são 
proativos. 
 
 
2 Processos são 
caracterizados por 
Projeto e as ações 
frequentemente 
reativas. 
 
 
1 Processos são 
imprevisíveis, 
pouco controlados 
e reativos. 
 
 
Fonte: adaptado de: <http://www.isdbrasil.com.br/o-que-e-cmmi.php>. Acesso em: 21 jan. 2020. 
Figura 5.1 – Níveis de maturidade do CMMI. 
Otimização 
Quantitativamente 
Gerenciado 
Definido 
Gerenciado 
Inicial 
http://www.isdbrasil.com.br/o-que-e-cmmi.php
, 
 
 
63 
 
Há também o padrão ISO 15504, que é também chamado de SPICE, Software Process 
Improvement and Capability Determination, que pode ser traduzido livremente para 
Processo de Determinação da Melhoria e Capacitação de Software, que é basicamente 
a mesma coisa que o CMMI. A diferença entre um conjunto de melhores práticas e 
uma norma ISO é a questão da obrigatoriedade. Quando assumimos uma norma, 
temos que cumprir toda a especificação da norma e a empresa é quem é certificada. 
No caso de melhores práticas, o profissional é certificado e ele é quem aplica o 
conhecimento na área em questão. 
5.5 Modelo CISQ 
Finalmente, o modelo CISQ de qualidade é definido pelo CISQ – Consortium for IT 
Software Quality, uma organização formada por executivos de grandes empresas de 
software, e se baseia em 5 fatores desejáveis para agregar valor para o cliente. 
 Confiabilidade, um atributo de resiliência e solidez. Esse atributo mede a 
probabilidade de uma falha, ou seja, o risco de falha do software em questão. 
 Eficiência é o atributo que garante uma alta performance na execução do 
software, definido como rapidez no processamento do código de máquina com 
o mínimo de consumo de recursos computacionais. 
 Segurança é o atributo que assegura a preservação e a continuidade dos dados 
armazenados pelo software, através de práticas seguras de codificação. 
 Manutenibilidade é o atributo para medir a facilidade em aplicar mudanças no 
software sem afetar o processamento e os dados armazenados e inclui os 
conceitos de portabilidade e adaptabilidade. 
 O Tamanho do Software não é um atributo de qualidade propriamente dito, 
mas estabelece padrões e ajuda a controlar os projetos de desenvolvimento, 
pois ajuda a dimensionar o esforço necessário tanto para o desenvolvimento 
quanto para a manutenção do software. 
O conceito principal do modelo CISQ é a automação do processo. As definições e as 
técnicas utilizadas devem obrigatoriamente facilitar a adoção de software para 
, 
 
 
64 
 
garantia da qualidade, medir a qualidade de um software usando outro software que 
processa e calcula as métricas de cada fator e aponta indicadores para melhoria. 
 
Conclusão 
Você viu neste bloco que o assunto da Qualidade de Software é importante e extenso. 
Viu ainda a diversidade de maneiras e estilos para o controle de qualidade. Uma 
variedade de normas e padrões foi desenvolvida ao longo do tempo e estão todas 
ativas e tentando estabelecer as bases para que se garanta a qualidade do software. 
Porém, como explicado no Bloco 1, devido à natureza do próprio software, é quase 
impossível dizer que um software está completamente livre de erros. Há muitas 
variáveis. O comportamento do software é um sob circunstâncias ideais e outro 
diferente quando alguma coisa não está como se planejou. Senão coisas como 
vazamento de informação, perda de dados, websites lentos e congestionados 
simplesmente não aconteceriam. Você já deve ter visto notícias sobre a entrega do 
imposto de renda, sobre divulgação de notas do ENEM e outros erros mais grosseiros, 
como quando uma atualização do Windows da Microsoft travou máquinas em todo o 
Brasil. 
Essa diversidade sugere que ainda é muito difícil garantir a qualidade do software. 
Portanto, cabe ao Engenheiro de Software se apegar aos princípios básicos da 
qualidade de software: fazer um bom levantamento dos requisitos, desenvolver código 
segundo o que foi especificado e não se esquecer de que um software vai precisar de 
manutenções, seja por fatores externos ou internos ao próprio software. Esteja 
preparado e deixe o código preparado para facilitar a manutenção. 
 
REFERÊNCIAS 
[1] CROSBY, Phillip B. Quality is free: the art of making quality certain. McGraw Hill, 
1979. 
, 
 
 
65 
 
[2] INTERNATIONAL ORGANIZATION OF STANDARDS. ISO/IEC 25010:2011 Systems and 
Software Engineering. Systems and Software Quality Requirements and Evaluation 
(SQuaRE). Systems and Software Quality Models, ISO/IEC, 2011. 
[3] BOURQUE, Pierre; FAIRLEY, Richard E. (ed.). SWEBOK – Software Engineering Base 
of Knowledge. 3 ed. IEEE Computer Society, Piscataway, NJ, 2014. 
[4] KAN, Stephen H. Metrics and Models in Software Quality Engineering. 2. ed. 
Addison-Wesley, 2002. 
[5] ALBRECHT, Allan J. Measuring Application Development Productivity. IBM 
Development Symposium, Monterrey, California, 1979. 
[6] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 25000 System and 
Software Quality Requirements and Evaluation (SQuaRE) series of standards. 2. ed. 
Genebra, 2011. 
 
 
 
 
 
 
 
 
 
 
 
 
, 
 
 
66 
 
 
6 TÓPICOS AVANÇADOS EM ENGENHARIA DE SOFTWARE 
Apresentação 
Neste bloco, vamos discutir algumas tendências do século XXI que têm potencial de 
durar por muitos anos ainda. Na tecnologia, os cenários mudam rapidamente, novas 
tendências e novas tecnologias colocam tudo em xeque todo o tempo, e como 
Engenheiros de Software, temos que estar preparados para essas mudanças rápidas, 
adaptar nossos softwares e oferecer sempre a melhor solução disponível aos 
stakeholders. 
Por isso, vamos ver alguns conceitos que já estão consolidados e alguns ainda se 
consolidando rapidamente. Inteligência Artificial e Blockchain são tendências em 
consolidação no momento e afetam nosso modelo de trabalho com Software. SaaS e 
SOA já são tendências consolidadas e devem ficar assim por um tempo ainda, 
enquanto Big Data ainda é uma incógnita se vai se consolidar mesmo como uma 
tendência e quanto tempo vai durar isso, apesar de todos falarem no assunto. Vamos 
ver cada um desses conceitos e tendências. 
6.1 SaaS – Software as a Service 
Vamos contar um pouco de história para contextualizar SaaS (Software como um 
Serviço). Até o final da década de 1950, os computadores eram calculadoras grandes e 
rápidas. Na década seguinte, os mainframes dominavam e sua arquitetura era 
centralizada (óbvio). O software processava no mainframe e o usuário tinha um 
terminal na sua mesa com monitor e teclado apenas. Com a revolução do PC na 
década de 1980 e a arquitetura cliente-servidor da década de 1990, o usuário passou a 
ter um computadorcompleto na sua mesa. E passou a produzir informação, que às 
vezes gerava confusão, porque cada usuário produzia uma informação diferente da 
outra. Nos anos 2000, a Internet virou a plataforma dominante. 
Com o aumento do uso e da confiabilidade da “grande rede”, migrar os softwares para 
a Web passou a ser o paradigma dominante e surgiram várias arquiteturas distribuídas 
e várias implementações distribuídas de software. Só que a grande “sacada” dos 
, 
 
 
67 
 
fabricantes de software foi oferecer a plataforma necessária para processar os grandes 
softwares. Imagine que a empresa não precisa mais ter um (ou dezenas de) 
servidor(es). Com isso, o custo de manter toda essa tecnologia passou a não existir 
mais. E o custo do software? SaaS foi a resposta para isso. Alugar em vez de comprar. 
Temos ainda uma mentalidade de ter as coisas. Achamos melhor ter um carro. Mas 
para que ter um carro se posso alugar um sempre que preciso, e que ainda vem com 
motorista junto? Já ouviu falar em Uber? Em vez de comprar uma licença de software, 
posso pagar uma mensalidade para usar o software de uma empresa. E muitas vezes o 
pagamento não envolve dinheiro. Usamos o Android nos nossos celulares “de graça”. 
Pagamos com informação. Quem somos, onde vamos, o que vemos, o que ouvimos. 
Toda essa informação vai para a Android, divisão do Google. É capaz de o Google saber 
mais sobre você do que você mesmo! 
Existe ainda um modelo de comercialização chamado freemium, onde se usa a 
funcionalidade básica de graça, mas se você quiser mais recursos, tem de pagar pelo 
uso. É mais comum quando há um serviço além do uso do software, como música, por 
exemplo. Spotify é um exemplo. É um software para ouvir música que vem com um 
catálogo de músicas associado. 
No mundo corporativo, os grandes softwares estão indo para a nuvem e se tornando 
SaaS. Ao invés de comprar as licenças, manter um datacenter com vários servidores, 
backups e vários funcionários especializados, a empresa prefere pagar pelo serviço 
prestado. As grandes vantagens são essas. Economia e simplicidade no gerenciamento 
da infraestrutura necessária para o software funcionar. Entretanto, a grande 
desvantagem é que os dados ficam armazenados no prestador do serviço, então 
cancelar e mudar para outro pode ser um transtorno enorme e custar muito caro para 
a migração. Acesso indevido também pode ser um problema, mas com a popularização 
desse modelo de serviço, os provedores de SaaS estão cada vez melhores em manter 
seus dados protegidos. É importante ter um bom contrato com o provedor de serviço, 
com cláusulas de proteção e de propriedade dos dados. 
, 
 
 
68 
 
É preciso considerar também que a manutenção não é feita pela empresa, mas sim 
pelo provedor de serviço, e algumas vezes pode demorar para que alguma 
funcionalidade que você deseja fique disponível. Essa agilidade na manutenção pode 
ser contornada através da contratação de mais serviços do provedor ou criando uma 
API (interface) com o software do prestador que permita que a empresa acesse os 
dados ela mesma, e construa funcionalidades adicionais. Esse tipo de software externo 
ao principal é chamado de Middleware. 
6.2 SOA – Service Oriented Architecture 
Aqui também vamos recorrer à história para entendermos o conceito de SOA 
(Arquitetura Orientada a Serviços). Certamente, já ouviu falar em Orientação a 
Objetos. Programar usando orientação a objetos tornou as tarefas mais simples e 
possibilitou o reúso dos objetos, diminuindo o tempo de programação e a quantidade 
de linhas de código necessárias para criar o software. Imagine que você possa usar 
objetos de forma distribuída! Esse é o conceito de SOA. Pense em digitar o endereço 
no cadastro de cliente! Você pode acessar um serviço dos correios que busca o 
endereço a partir do CEP e só colocar o número da casa e do apartamento, se tiver. Do 
ponto de vista do usuário ficou mais fácil. Do ponto de vista do software também. 
Rotinas de consistência e checagem e verificação dos dados são dispensáveis, já que os 
dados chegam formatados no padrão dos correios, prontos para serem usados. 
Imagine todo o sistema formado por um conjunto de serviços. Cada serviço pode estar 
hospedado em um lugar diferente ou ser fornecido por um provedor diferente. Porém, 
tudo funciona integrado, como um único software. SOA exige novas formas de se 
pensar a criação de software. Ao criar um serviço de verificação do CPF, por exemplo, 
basta colocar o serviço disponível no catálogo e pronto. Está disponível para qualquer 
parte do software que precise desse serviço e até para outros softwares poderem usar 
também. 
É claro que para essa maravilha tecnológica funcionar é necessário que existam 
algumas coisas bem definidas como padronização dos serviços e da troca de dados. 
Isso é conseguido com o uso da tecnologia de Web Services. Foram esses provedores e 
empresas de software que praticamente criaram a SOA, então é natural que a 
, 
 
 
69 
 
implementação de SOA seja mais fácil através dos Web Services. Outro fator que 
impulsiona a adoção de SOA é a própria UML, que, com seus diagramas de 
modelagem, facilita a visualização dos Serviços e da integração entre os serviços. Uma 
outra necessidade dessa arquitetura é a criação e manutenção de um bom catálogo de 
serviços, para evitar duplicidade e saber quais serviços estão disponíveis, quais estão 
em desenvolvimento e quais estão em manutenção ou atualização. 
Aliás, manutenção é muito facilitada porque o software já foi construído em partes. Se 
precisar de manutenção corretiva numa parte, a correção fica imediatamente 
disponível para todos os serviços integrados ao serviço modificado. Isso oferece 
também agilidade ao negócio, porque sempre que surgir uma nova regra de negócio, 
ela vai estar disponível em todo o software, bastando ser implementada num serviço 
novo ou modificar um já existente. 
Os requisitos funcionais podem ser agrupados dentro de um serviço. Assim, um serviço 
oferece um conjunto de capacidades que fazem referência a uma parte do modelo de 
negócio. O conceito de granularidade é interessante nessa nova forma de projetar 
software. Cada problema ou funcionalidade fica dentro de um serviço, que pode ser 
inclusive constituído por serviços menores. Um cadastro de produtos pode ser feito 
buscando as características do produto no servidor do fornecedor, o preço unitário na 
NFe da compra do produto e a quantidade em estoque por leitura de código de barras. 
O cadastro fica decomposto em 3 serviços menores, mas disponível cada vez que se 
precise da funcionalidade cadastrar/atualizar produtos no software [1]. 
Essa implementação é facilitada pelos Web Services porque eles já possuem padrões 
largamente usados na indústria de software, como XML e AJAX e são feitos na forma 
de APIs, ou seja, já são formatados para passar informação e receber informação. Na 
SOA, existem 3 conceitos fundamentais: o provedor do serviço, que vai processar as 
requisições de serviço recebidas, o repositório de serviços, que mantém o catálogo dos 
serviços disponíveis atualizado e o cliente do serviço, que manda uma solicitação e 
recebe a informação que o serviço processou. Usando a tecnologia Web Services, que 
já existe, pode-se implementar SOA mais facilmente porque ela usa desses 3 princípios 
e possui os protocolos padrão para envio e recebimento de dados. 
, 
 
 
70 
 
6.3 Blockchain 
Bom, como o nome já diz, Blockchain é uma cadeia de blocos, onde bloco é um 
registro e a cadeia é a criptografia que liga um bloco no bloco anterior. Como é uma 
tecnologia distribuída, esses blocos estão disponíveis para todos que estão na cadeia, 
ou seja, falsificações são muito improváveis, já que existem várias cópias dos blocos, 
com vários usuários diferentes, com chaves de criptografia independentes. 
O Blockchain é, então, um conjunto de registros contábeis públicos e distribuídos, 
transparentes,imutáveis e sincronizados [2]. A implementação de Blockchain mais 
conhecida é o Bitcoin. Bitcoin é uma criptomoeda, isto é, moeda criptografada e 
descentralizada. Não existe um país e nem mesmo um banco por trás do Bitcoin. Ele é 
composto de 4 elementos: 
 Uma rede peer-to-peer descentralizada (o protocolo bitcoin); 
 Um registro público de transações (o blockchain); 
 Uma emissão de moeda descentralizada, baseada em matemática; 
 Um sistema de validação das transações (o script de transação) [3]. 
A grande novidade é o Blockchain. Vamos ilustrar com um problema da teoria da 
computação chamado de Generais Bizantinos. Imagine que vários generais estejam no 
topo de montanhas e precisam atacar seu inimigo que está no vale. Para o ataque ser 
bem-sucedido, precisa ser feito simultaneamente. O problema está justamente em 
sincronizar o ataque. Seria necessário enviar um mensageiro para cada outro general. 
Os mensageiros precisam ou trazer a informação de volta ou um novo mensageiro 
precisaria ser enviado para saber se o mensageiro anterior chegou. Existe ainda a 
possibilidade de um general (ou mais) trair os demais e passar informações diferentes 
para mensageiros diferentes. O Blockchain resolve esse problema. É um registro 
público, descentralizado, e por isso, disponível para todos ao mesmo tempo. É seguro, 
porque é criptografado e existem várias cópias com usuários diferentes. Quando você 
tenta mudar um registro, ele é invalidado porque a outra cópia não foi alterada e a 
cópia original substitui sua alteração. Sendo assim, o Blockchain pode ser usado para 
uma série de aplicações e não apenas aplicações financeiras. [2] 
, 
 
 
71 
 
Imagine que a empresa tenha uma entrega que precisa ser feita. Um registro através 
de Blockchain pode ser criado. Qualquer caminhoneiro pode baixar esse registro e 
aceitar a tarefa. Após a entrega realizada, o cliente e a empresa recebem um registro 
(blockchain) da hora em que a entrega foi feita, e o caminhoneiro é pago, gerando 
outro registro (blockchain de novo) que finaliza o contrato (temporário) entre a 
empresa e o entregador. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Fonte: adaptado de LYRA [2]. 
Figura 6.1 – Esquematização do funcionamento do Blockchain 
1. Um nodo desbloqueia os fundos de seu 
endereço com a senha única. Cria uma hash de 
transação com dados do endereço receptor e a 
quantidade de tokens a ser enviada. 
5. Sendo consolidada e reconhecida 
pela rede, a transação chega ao 
endereço receptor. 
4. O bloco, ao ser fechado, envia à 
rede as transações validadas e os 
ledgers são atualizados. 
3. A hash de transação válida 
chega ao bloco em formação 
e que consolida a transação. 
2. Os nodos da rede verificam nos 
seus ledgers se há transação 
anterior que valide o envio da 
quantidade de tokens da 
transação atual. 
, 
 
 
72 
 
A emissão de um registro precisa ser verificada por outros usuários e só se for validada 
é que os registros, chamados ledgers (livro contábil), são atualizados para refletir a 
nova transação. 
6.4 Big Data 
Em síntese, Big Data é uma abordagem que analisa e procura extrair informação de um 
conjunto de dados complexo e bem grande, que um software tradicional não é capaz 
de fazer. Quando falamos aqui de um conjunto de dados bem grande, imagine a 
quantidade de posts gerados no Facebook, no ano de 2019, em todo o mundo. É desse 
conjunto de dados que o Big Data se propõe a extrair informação útil para o negócio. 
Esses dados não estão lá organizados, e nem no mesmo idioma. Estão espalhados em 
vários perfis diferentes, possuem formatos diferentes (texto, foto, vídeo, áudio) e não 
existe uma classificação para eles. Até usamos o “#” (hashtag). Contudo, isso não 
significa classificação, pelo menos, não para uma aplicação de software tradicional. 
Para encarar o desafio chamado Big Data, precisamos de uma nova forma de 
engenheirar a aplicação. Big Data não tem só a ver com tamanho. É também 
velocidade. A cada minuto temos 87,5 mil “tweets” gerados. A cada minuto! Some a 
isso 188 milhões de e-mails e 18 milhões de textos no Whatsapp. A cada minuto US$ 1 
milhão é gasto pelas pessoas no comércio eletrônico. Além de muito grande, a base de 
dados atualiza muito rápido. 
E há ainda outra vertente do Big Data que diz respeito à veracidade da informação. Se 
você postar no Twitter dizendo que gosta de amarelo, realmente gosta de amarelo? E 
tudo isso não tem importância se não agregar valor para a empresa, se não alavancar 
novos negócios ou analisar tendências. Senão não há justificativa para os 
investimentos feitos para processar o Big Data. É necessário agregar valor. 
Entretanto, os dados do Big Data não precisam vir necessariamente da Internet. No 
Brasil, um supermercado começou a disponibilizar wi-fi nas suas lojas, através de seu 
aplicativo. Dessa forma, espera não só saber quantos clientes estão na loja, mas quais 
clientes, o que estão comprando, e principalmente, o que não encontraram na loja. 
Com base na análise dessas informações, é possível planejar o estoque e manter 
, 
 
 
73 
 
apenas produtos que vendem. Também é possível mover o estoque de uma loja para a 
outra, aumentando a disponibilidade dos produtos mais vendidos. Imagine que o 
supermercado saiba que fará calor na terça-feira. Produtos gelados, como sorvete, vão 
estar com alta demanda. E se você souber que amarelo é a cor da moda, pode 
aumentar a oferta de produtos nessa cor. 
Uma ferramenta de BI (Business Intelligence) analisa dados históricos dos sistemas 
tradicionais da empresa. Big Data analisa qualquer dado que faça sentido ser analisado 
e possa gerar valor. Porém, como fazer o Big Data acontecer? 
Não bastam ferramentas de captura da informação e grande capacidade de 
processamento. A empresa precisa mudar sua percepção do negócio. Novas regras de 
negócio precisam ser criadas e estar disponíveis. É aí onde entra a Engenharia de 
Software. Mudanças nas aplicações atuais precisam ser feitas de forma ágil. Processos 
de negócio precisam responder a essas novas informações de forma muito rápida, de 
preferência automatizada. Os algoritmos nos softwares precisam tomar decisões em 
conjunto com as pessoas. 
6.5 Inteligência Artificial 
E falando em tomada de decisão, nosso último subtema é Inteligência Artificial. Para 
começar a falar nesse assunto, primeiro queremos que você tire a imagem do robô 
malvado destruindo a humanidade. A realidade é bem diferente dos filmes. A 
Inteligência Artificial (IA) é bem decepcionante nesse ponto. São algoritmos que 
tomam decisões baseadas em estatísticas armazenadas após milhões de tentativas e 
erros em ambiente simulado. 
Inteligência artificial é a capacidade de uma máquina simular a inteligência humana. 
Isso significa aprender com a experiência e se ajustar conforme novas informações. 
Isso vai de sistemas que preveem o comportamento das ações na bolsa de valores até 
carros que dirigem sozinhos. Atualmente, estamos na onda dos sistemas que 
conversam com você. Essa é uma área da IA chamada de processamento de linguagem 
natural, ou seja, a capacidade de entender o que dizemos e reagir de acordo. 
, 
 
 
74 
 
Sistemas especialistas nem são tão novos assim. O conceito da IA também não é 
exatamente uma novidade. A diferença é que o hardware agora ficou bastante 
poderoso. Um smartphone é capaz de processar o que você diz, mas antes essa 
capacidade de processamento só estava disponível em computadores bem grandes. 
Para software de IA, é preciso uma nova abordagem da Engenharia de Software. É 
necessário pensar nos requisitos como se fossem regras para a IA aprender. Quando 
você projeta um software que não tem mais interface gráfica, mas sim uma interface 
de voz, o Software precisa se comportar de maneira diferente. É necessário descrever 
o que está acontecendo e pedir comandos claros para o humano. Talvez a Engenharia 
de Software ainda não tenhapensado em normas para isso. Os monitores estão aí a 50 
anos. Contudo, a interface de voz está chegando agora. 
Aplicações para carros autônomos e aspiradores de pó necessitam de velocidade nas 
decisões, assim como as aplicações de reconhecimento facial e interpretação de 
imagens. Existem hoje sistemas de IA que detectam tumores em estágios iniciais de 
formação antes que os médicos possam perceber a presença deles nas imagens. Isso 
só é possível com muito treino. Uma IA precisa de treinamento. A diferença é que o 
que um humano leva 20 anos para aprender, a IA aprende em 20 dias. 
Para um sistema computacional aprender e entender o mundo como o ser humano faz 
é um desafio muito grande. Imagine uma criança que está aprendendo a andar. Ela 
precisa aprender a controlar sua musculatura e movimentar esses músculos de forma 
sincronizada, para não cair. Aprendemos isso porque temos dentro da cabeça uma 
rede neural, um conjunto enorme de microprocessadores que se comunicam e trocam 
informação entre eles. Nosso cérebro é mais que um computador. O computador é 
milhões de vezes mais rápido, mas nós temos os neurônios. Os desafios para projetar 
software inteligente começam em como representar o conhecimento. Como você 
aprendeu a usar talheres para comer? Como ensinar um robô a fazer isso? 
Imagine ensinar uma máquina a falar. Ela precisa aprender os sotaques, as gírias, as 
ironias e outras figuras de linguagem para se comunicar conosco como uma pessoa 
faria. Isso precisa de treino. Não basta carregar o dicionário na memória. Outro desafio 
, 
 
 
75 
 
é fazer a máquina perceber o ambiente. Nós não colocamos a mão no fogo porque 
percebemos seu calor, sabemos a dor que é uma queimadura. A máquina não sabe 
nem uma coisa e nem outra. Uma série de sensores precisa dar informação para que 
seu aspirador não caia da escada e quebre. O processo de aprendizado envolve lógica, 
modelos estatísticos, classificação de informação, estabelecimento de padrões e 
validação. Um humano precisa dizer para a máquina o que ela acertou e o que ela 
errou. Pelo menos nos estágios iniciais do treino. 
Considere um carro autônomo. Há um conjunto de regras predefinidas e claras. Como 
acelera o carro, como freia e o que fazer se o sinal está vermelho. Para saber se o 
semáforo está fechado ou não, é necessário algum tipo de sensoriamento. Uma 
câmera, por exemplo. Imagine a velocidade que o computador do carro precisa ter 
para, em tempo real, processar as imagens recebidas da câmera. Reconhecer que há 
um semáforo na imagem, reconhecer que o semáforo está fechado. Nós processamos 
imagens muito rapidamente, afinal é um traço evolutivo. Reconhecer ameaças nos faz 
sobreviver. Nós também temos percepção de quando o carro está derrapando, se há 
pedestres atravessando fora da faixa. Um carro que freia de repente nos faz reagir. O 
recurso computacional embarcado precisa ser poderoso o suficiente. O software do 
carro precisa ser bem escrito não para prever cada coisa que pode acontecer, mas para 
evoluir em função das diferentes situações que o carro enfrenta. Se você não dirigiu na 
neve ainda, é uma experiência que você não passou e não aprendeu. O carro a mesma 
coisa. 
Sistemas de IA são ótimos para identificar padrões. Juntando processamento de 
linguagem natural com Big Data e reconhecimento de imagens, temos uma ferramenta 
que pode ser muito interessante para os negócios. Especificamos qual o padrão que 
queremos encontrar e deixamos a IA processar esse volume todo de informação com 
velocidade, e aprender como detectar os padrões de forma mais eficiente. Isso já está 
acontecendo. Vamos começar a criar IAs que farão previsões de venda e com base 
nisso, ajustar o estoque e fazer as compras. 
 
, 
 
 
76 
 
Conclusão 
Como vimos neste bloco, novas tecnologias estão mudando os paradigmas da 
Engenharia de Software, apresentando novos desafios e novas oportunidades. Temos 
que levar em conta toda essa variedade de novas tecnologias e outras mais que não 
abordamos aqui, como IoT, a Internet das Coisas. Desde software distribuído até criar 
softwares que ainda não têm modelagem definida, precisamos pensar na Engenharia 
de Software de forma diferente, mais ampla, mais adaptativa. 
Com certeza, novos padrões e novos modos de trabalhar a Engenharia de Software 
irão aparecer e impulsionar o desenvolvimento da área com mais rapidez. Vamos 
pensar de forma integrada. O que acontece quando a IA passa a ser um serviço, que 
pode ser integrado ao software tradicional da empresa? Temos a oportunidade para 
quebrar os modelos atuais e criar novos. Coisas que ainda não estão sendo feitas. Usar 
Blockchain para validar os padrões encontrados pela IA para aprender o que fazer com 
o Big Data e oferecer a informação resultante como um serviço, através de um modelo 
de assinatura. 
Essas ideias precisam ser pensadas, estruturadas e novos modelos na Engenharia de 
Software precisam surgir para ajudar a se criar softwares mais confiáveis, de 
qualidade, que possam lidar com as novas possibilidades que a tecnologia tem 
apresentado. A Engenharia de Software ainda vai evoluir bastante. 
 
REFERÊNCIAS 
[1] THOMAS, Erl. SOA: princípios de design de serviços. Pearson, 2013. Disponível na 
Biblioteca Virtual. 
[2] LYRA, João G. Blockchain e Organizações Descentralizadas. Brasport, 2019. 
Disponível na biblioteca virtual. 
[3] ANTONOPOULOS, Andreas M. Mastering Bitcoin: unlocking digital 
cryptocurrencies. Sebastopol. CA: O'Reilly Media, 2014. 
[4] TAURION, Cesar. Big Data. Brasport, 2019. Disponível na biblioteca virtual. 
, 
 
 
77 
 
[5] SALESFORCE. O que é SaaS? Disponível em: 
<https://www.salesforce.com/br/saas/>. Acesso em: 22 jan. 2020. 
 
https://www.salesforce.com/br/saas/