Apostila - Engenharia de Software e Engenharia de Requisitos

Prévia do material em texto

Engenharia de Softwares e Engenharia de Requisitos 
1
Engenharia de 
Software e Engenharia 
de Requisitos
Profª Elisamara de Oliveira
Profº Marcelo de Freitas Pintaud
Engenharia de Softwares e Engenharia de Requisitos 
2
Apresentação 3
Software e Engenharia de Software 4
Antecedentes Históricos da Engenharia de Software 4
Definições e Conceitos de Software e Engenharia de Software 6
O Produto Software 9
Aplicações do Software 10
Mitos do Software 12
Exercícios do Capítulo 1 15
Processo de Software 16
Conceitos Básicos de Processo de Software 16
Padrões, Avaliação e Tecnologias de Processo 18
Exercícios do Capítulo 2 20
Modelos de Processo 21
Ciclo de Vida e Modelos de Processo 21
Modelos Prescritivos de Processo 24
Modelo em Cascata 24
Modelos Evolucionários de Processo 25
Prototipação 25
Modelo Espiral 26
Modelo de Desenvolvimento Concorrente 28
Modelos Incrementais de Processo 29
Modelo Incremental 29
Desenvolvimento Baseado em Componentes 32
Modelo de Métodos Formais 33
Processo Unificado 34
Desenvolvimento Ágil 37
Exercícios do Capítulo 3 41
Engenharia de Requisitos 44
Requisitos e Engenharia de Requisitos 44
Objetivos e Classificação dos Requisitos 45
Requisitos de Produto 45
Requisitos Organizacionais 45
Requisitos Externos 46
Tarefas da Engenharia de Requisitos 49
Exercícios do Capítulo 4 - Parte 1 49
Elicitação de Requisitos 53
Técnicas de Coleta de Requisitos 55
Considerações sobre as Técnicas de Coleta de Requisitos 59
Exercícios do Capítulo 4 - Parte 2 60
Considerações Finais 62
Respostas Comentadas dos Exercícios 63
Capítulo 1 63
Capítulo 2 65
Capítulo 3 66
Sumário
Engenharia de Softwares e Engenharia de Requisitos 
3
Capítulo 4 – Parte 1 68
Capítulo 4 – Parte 2 68
Glossário de Siglas 71
Referências Bibliográficas 72
Engenharia de Softwares e Engenharia de Requisitos 
4
Apresentação
Atualmente o software está presente, explicitamente ou mesmo sem se fazer notar, em diversos aspectos 
da vida, inclusive nos sistemas críticos que afetam nossa saúde e nosso bem estar. Diferentemente de outras 
áreas da Engenharia, novas aplicações de software aparecem a cada dia e isso torna a área de desenvolvi-
mento de software um desafio constante, necessitando de pessoas treinadas, capacitadas e em constante 
evolução para desempenhar adequadamente as funções necessárias para a produção de software de quali-
dade.
As dificuldades em se obter software de qualidade, obedecendo a prazos, custos e escopo estabelecidos, 
se mostram presentes desde os primórdios da área de computação. Devido a isso, uma base sólida sobre 
a teoria e a prática da Engenharia de Software é essencial para sabermos como construir bons softwares e 
avaliarmos os riscos e as oportunidades que ele pode trazer para o bom desempenho dos negócios. 
A Engenharia de Software trilhou um longo caminho desde quando o termo foi usado pela primeira vez. 
Convidamos você, caro aluno, a percorrer esse caminho. Ao longo dessa disciplina, iremos destacar aspectos-
-chaves da Engenharia de Software, abordando, dentre outras, as seguintes questões:
• Qual a necessidade de uma disciplina de Engenharia para o desenvolvimento de software?
• O que se entende por Engenharia de Software?
• O que se entende por software de computador?
• Por que lutamos para construir sistemas de alta qualidade?
• Como podemos categorizar os domínios de aplicação para o software? 
• Que mitos ainda existem sobre software?
• O que é um processo de software?
• Que modelos de processo podem ser aplicados ao desenvolvimento de software?
• Quais os pontos fortes e fracos de cada modelo de processo?
• Por que é tão complicado estabelecer os requisitos de um sistema?
• Quais técnicas podem nos auxiliar no estabelecimento dos requisitos?
Quando essas questões forem respondidas, você, caro aluno, estará melhor preparado para entender os 
conceitos de gestão e os aspectos técnicos da atividade de Engenharia de Software que serão abordados nas 
disciplinas subsequentes do nosso curso.
Marcelo Pintaud
Elisamara de Oliveira 
Engenharia de Softwares e Engenharia de Requisitos 
5
Software e Engenharia de Software
Caro aluno, neste capítulo abordaremos os antecedentes históricos da engenharia de software, 
falaremos sobre os principais conceitos de software e da engenharia de software, sobre a crise 
do software, mostraremos as diferenças entre os produtos “software” x ‘hardware”, exemplifi-
caremos algumas das principais aplicações do software e o alertaremos sobre o que é mito e 
realidade na área de desenvolvimento.
Antecedentes Históricos da 
Engenharia de Software
Caros alunos, para entendermos melhor os concei-
tos fundamentais que envolvem a área de Engenha-
ria de Software, vamos fazer um breve histórico dos 
principais fatos que ocorreram no mundo da tecnolo-
gia que justificaram a criação deste ramo da compu-
tação. É interessante vocês notarem que há algumas 
décadas atrás, não se tinha ideia da importância que 
os computadores e, em especial, o software (progra-
mas de computadores), iriam ter e como iriam afetar 
profundamente a vida de todos nós.
A denominação da “Engenharia de Software” sur-
giu em 1968, em uma conferência organizada para 
discutir a chamada “crise do software”. Mas, para 
sermos mais precisos, o termo foi criado no início da 
década de 1960, tendo sido utilizado oficialmente em 
1968 nesta conferência, a NATO Conference on Sof-
tware Engineering (Conferência da OTAN sobre En-
genharia de Software), que aconteceu na cidade de 
Garmisch, Alemanha. Nesta ocasião, todos estavam 
preocupados em contornar os efeitos da crise do 
software e buscar maneiras de dar um tratamento de 
engenharia, ou seja, mais sistemático e controlado, 
ao desenvolvimento de sistemas de software comple-
xos. 
Um sistema de software complexo é caracterizado 
por um conjunto de componentes de software (es-
truturas de dados, métodos, técnicas) encapsulados 
na forma de procedimentos, funções, módulos, obje-
tos ou agentes, interconectados entre si, compondo 
a arquitetura do software, que deverão ser executa-
dos em sistemas computacionais. 
Fonte: http://profcarolinadgs.webnode.com.br/unip/engenharia-
de-software/
Engenharia de Softwares e Engenharia de Requisitos 
6
A Crise do Software
A “crise do software” foi um termo criado para descrever as dificuldades enfrentadas no desenvolvimento de 
software no final da década de 1960. A complexidade dos problemas, a ausência de técnicas bem estabelecidas 
e a crescente demanda por novas aplicações começavam a se tornar um problema sério. Essa crise teve como 
origem a introdução de computadores “mais poderosos”. O advento deste hardware com mais recursos tornava 
viáveis softwares bem maiores e mais complexos que os sistemas existentes. A experiência inicial de construção 
desses sistemas mostrou que uma abordagem informal de desenvolvimento de software não era suficiente. 
Projetos importantes sofriam atrasos (às vezes, de alguns anos). Os custos eram muito maiores do que os ini-
cialmente projetados. As soluções de software não eram confiáveis. Os programas eram de difícil manutenção. 
Novas técnicas e novos métodos eram necessários para controlar a complexidade inerente aos grandes sistemas 
de software.
Desta forma, como o principal objetivo dessa conferência foi estabelecer práticas mais maduras para o 
processo de desenvolvimento de software, é considerado como o evento que deu origem à disciplina de En-
genharia de Software.
Duas décadas depois, em 1986, Alfred Spector, presidente da Transarc Corporation, foi co-autor de um 
artigo comparando a construção de pontes ao desenvolvimento de software. Sua premissa era de que “As 
pontes normalmente eram construídas no tempo planejado, no orçamento e nunca caíam. Por outro lado,os 
softwares nunca ficavam prontos dentro do prazo e do orçamento, e, além disso, quase sempre apresenta-
vam problemas.”
Uma década mais tarde, em 1995, a organização The Standish Group (1995) publicou um estudo anali-
sando as estatísticas sobre sucesso e fracasso dos projetos de desenvolvimento de software: o Chaos Report. 
Neste estudo foi revelado que:
• quase 84% dos projetos de software eram mal-sucedidos, sejam por serem cancelados ou apresenta-
rem falhas críticas (dentre elas conclusão fora do tempo previsto, fora do orçamento previsto ou com 
menos funcionalidades do que o planejado)
• 31.1% dos projetos eram cancelados antes de serem concluídos
• 52.7% dos projetos apresentavam custo real 189% maior que o estimado e o tempo de conclusão 
222% maior que o previsto
• 16.2% dos projetos eram concluídos dentro de prazo, custo e escopo estimados
• estimou-se que, naquele ano, as agências governamentais e companhias privadas americanas teriam 
gasto US$ 81 bilhões apenas em projetos cancelados, e mais US$ 59 bilhões em projetos concluídos 
fora do tempo previsto.
Engenharia de Softwares e Engenharia de Requisitos 
7
O Standish Group continuou publicando regularmente seu relatório nos anos seguintes e, apesar de 35% 
dos projetos de software iniciados em 2006 terem obtido sucesso, ainda é assustador saber que dois terços 
de todos eles fracassam. Vejam as estatísticas de 2004:
Observando estes números, fica claro que de 1960 
até hoje, mais de 50 anos de experiência no desen-
volvimento de software não bastaram para melhorar 
efetivamente a qualidade do software, a despeito da 
evolução ocorrida na área de Engenharia de Software 
e do ferramental disponível. 
Grady Booch, um dos criadores da UML – Unified 
Modeling Language, resumiu assim a história: “uma 
doença que dure tanto tempo quanto esta, franca-
mente, deveria ser chamada de normalidade”. [BOO-
CH et al, 2006].
Definições e Conceitos de 
Software e Engenharia de Software
Engenharia de Software é uma disciplina da enge-
nharia que se ocupa de todos os aspectos da produ-
ção de software, desde os estágios iniciais de especi-
ficação do sistema até a manutenção desse sistema, 
depois que ele entrou em operação. Seu principal ob-
jetivo é fornecer uma estrutura metodológica para a 
construção de software com alta qualidade. Para que 
isso seja conseguido é necessário:
• aplicar teorias, métodos e ferramentas nas si-
tuações apropriadas nas diversas etapas do de-
senvolvimento
• trabalhar de acordo com as restrições organiza-
cionais e financeiras procurando soluções que 
estejam dentro dessas restrições
• gerenciar os projetos de software para que o 
resultado final esteja dentro do escopo, custo e 
prazos planejados
• adotar uma abordagem sistemática e organiza-
da (maneira mais eficaz de produzir software 
de alta qualidade)
Apesar da sua indiscutível importância, caro, alu-
no, as técnicas e métodos da Engenharia de Softwa-
re são, atualmente, amplamente, mas não universal-
mente, utilizadas.
Engenharia de Softwares e Engenharia de Requisitos 
8
Mas não podemos falar da Engenharia de Sof-
tware, sem antes, entendermos o software e seus 
fundamentos. Assim, os conceitos de software são 
apresentados aqui como uma referência inicial para 
o estudo do software, propriamente dito, e de seus 
processos de desenvolvimento.
Comecemos pelo significado léxico da palavra sof-
tware e seu significado nos dicionários: 
Software (palavra inglesa, de soft, mole + ware, 
mercadoria); [Informática]. Conjunto de programas, 
processos e regras, e, eventualmente, de documen-
tação, relativos ao funcionamento de um conjunto de 
tratamento da informação (por oposição a hardware). 
(Dicionário Priberam da Língua Portuguesa, http://
www.priberam.pt/dlpo/dlpo.aspx?pal=software, 2011) 
Software é uma sequência de instruções a serem 
seguidas e/ou executadas, na manipulação, redirecio-
namento ou modificação de um dado/informação ou 
acontecimento. Software também é o nome dado ao 
comportamento exibido por essa seqüência de instru-
ções quando executada em um computador ou máqui-
na semelhante além de um produto desenvolvido pela 
Engenharia de software, e inclui não só o programa de 
computador propriamente dito, mas também manuais 
e especificações. Para fins contábeis e financeiros, o 
Software é considerado um bem de capital. (Wikipe-
dia, http://pt.wikipedia.org/wiki/Software, 2011)
Pressman (2010) conceitua o software como:
“(1) Instruções (programas de computador) 
que, quando executadas, produzem a função e o 
desempenho desejados; (2) Estruturas de dados 
que possibilitam que os programas manipulem 
adequadamente a informação; (3) Documentos 
que descrevem a operação e o uso dos progra-
mas”.
As normas de gestão de qualidade e garantia da 
qualidade apresentam definições de software e seus 
componentes e processos. De acordo com a norma 
NBR ISO 9000-3, que é uma interpretação da norma 
de garantia de qualidade ISO 9001 para aplicação aos 
produtos de software, temos as seguintes definições:
Software: Criação intelectual compreendendo 
os programas, procedimentos, regras e qual-
quer documentação correlata à operação de 
um sistema de processamento de dados.
Produto de software: Conjunto completo 
de programas de computador, procedimentos 
e documentação correlata, assim como dados 
designados para entrega a um usuário.
Item de software: Qualquer parte identificá-
vel de um produto de software em etapa inter-
mediária ou na etapa final de desenvolvimento.
Desenvolvimento: Todas as atividades a se-
rem realizadas para a criação de um produto 
de software.
Fase: Segmento definido do trabalho.
Como podemos observar, o conjunto de conceitos 
apresentados deixa claro que o software é um pro-
duto que exige uma visão ampla, contemplando toda 
sua complexidade, não podendo o controle da qua-
lidade ser uma atividade secundária, devendo estar 
presente desde o início de seu desenvolvimento até a 
análise final de entrega.
Engenharia de Softwares e Engenharia de Requisitos 
9
Comparar o software com produtos de hardware 
auxilia na compreensão das diferenças existentes en-
tre eles e enfatiza as características inerentes a um 
software. O processo de desenvolvimento do softwa-
re apresenta diferenças fundamentais em relação ao 
hardware [PRESSMAN, 2010]:
• O processo criativo do hardware gera algo físi-
co (por exemplo, placas de circuitos). O desen-
volvimento de software resulta em um elemen-
to pertencente a um sistema lógico, intangível;
• O software geralmente é desenvolvido sob me-
dida, ao contrário do hardware, no qual o pro-
jetista tem acesso a componentes existentes 
que executam tarefas definidas. O projetista do 
software nem sempre terá acesso a módulos 
prontos para utilização e quando o faz, pode 
elevar o risco do produto devido a questões de 
segurança;
• Os custos do software estão concentrados no 
desenvolvimento e não no processo de manu-
fatura. Isto significa que não pode ser gerido 
como projeto de manufatura;
• Ao longo do tempo, o produto de software não 
se desgasta, mas se deteriora em função da 
introdução de erros oriundos de atividades de 
manutenção ou evoluções implícitas no proces-
so que devem ser reconsideradas no modelo 
original.
Desta forma, o software sofre deterioração oca-
sionada por diversos fatores sendo uma caracterís-
tica peculiar do produto. Segundo Pressman (2010), 
no caso do hardware, temos um alto índice de fa-
lhas no início do seu ciclo de vida ocasionadas por 
defeitos de fabricação e projeto. Posteriormente os 
defeitos são corrigidos dando estabilidade nas falhas 
ou mantendo-a em um nível muito baixo e supor-
tável para a estrutura. Já no final do ciclo de vida 
do produto podem surgir problemas relacionados ao 
envelhecimento,acúmulo de poeira, vibração, abuso, 
temperaturas extremas, entre outros. Este processo 
pode ser visto no gráfico apresentado na figura 1.
 Diferentemente da curva teórica de falhas do har-
dware, a de software leva em conta que o software 
não sofre processos de envelhecimento como o har-
dware, pois o software não é algo físico.No início do 
ciclo de vida do software, teremos problemas (bugs) 
que serão ajustados no decorrer do desenvolvimento 
e se estabilizarão gerando uma tendência de acha-
tamento da curva. Notemos que esta é apenas uma 
teoria, já que a curva real do índice de falhas de um 
software considera o processo de manutenção e mu-
danças. Durante o processo de refinamento do pro-
duto ou mudanças aumenta-se, consideravelmente, 
a probabilidade de inserção de novos erros, gerando 
picos na curva de falhas. As sucessivas alterações do 
software tendem a introduzir mais erros antes da es-
tabilização dos erros de alterações anteriores, oca-
sionando a tendência crescente do índice de falhas, 
conforme pode ser visto na figura 2.
Figura 1 - Curva de falhas do hardware
Fonte: [PRESSMAN, 2010]
Figura 2 - Curva de falhas do software
Fonte: [PRESSMAN, 2010]
Engenharia de Softwares e Engenharia de Requisitos 
10
Isso nos remete a uma realidade bastante complicada 
em relação ao software: ele é um produto que quanto 
mais se conserta, pior fica. Um software em constante 
manutenção pode ser tornar uma espécie de “colcha 
de retalhos”, gerando pontos de falhas diversos, difíceis 
de se identificar e de se ajustar. O melhor modelo é o 
desenvolvimento de um novo produto após o tempo 
de vida útil do mesmo, considerando-se as novas 
necessidades e tecnologias disponíveis.
Quando o hardware é projetado e construído, faz-
-se uso de catálogos de componentes digitais. Cada 
circuito integrado tem um código de componente, 
uma função definida e validada, uma interface bem 
delineada e um conjunto padrão de integração. De-
pois que cada componente é selecionado, ele pode 
ser requisitado do estoque e utilizado em diferentes 
projetos de hardware com alta confiabilidade.
 No mundo do software, isso é algo que está ape-
nas começando a ser utilizado numa escala mais 
ampla, apesar de existirem alguns casos antigos de 
“reuso”, como as bibliotecas de subrotinas científi-
cas. Atualmente, a visão de reuso foi ampliada para 
abranger não apenas algoritmos consagrados, mas 
também estruturas de dados, interfaces gráficas e 
diferentes classes e componentes orientados a ob-
jetos.
O Produto Software
Na realidade atual, o software assume um duplo 
papel: ele é o produto e, ao mesmo tempo, o veículo 
para entrega do produto. Esta afirmação é do conhe-
cido autor Roger Pressman (Pressman, 2010), que 
explica que o software, como produto, permite que 
o potencial de processamento do hardware do com-
putador ou da rede de computadores seja utilizado, 
pois transforma informações em um amplo espectro 
de aplicações, das mais simples às mais complexas. 
Como veículo usado para entrega do produto, o sof-
tware trabalha como elemento essencial para o con-
trole do computador e seus recursos (como o sistema 
operacional), para a comunicação e transmissão da 
informação (redes) e para a criação e controle de 
outros programas (ferramentas e ambientes de de-
senvolvimento).
A importância do software na nossa sociedade 
continua a crescer. Ele entrega o produto mais 
importante da nossa época: a informação.
O programador solitário de antigamente foi subs-
tituído por uma equipe de especialistas de software, 
com cada um se concentrando numa parte da tecno-
logia necessária para produzir uma aplicação comple-
xa. Mas, os mesmos questionamentos feitos ao “pro-
gramador solitário” continuam sendo feitos quando 
modernos sistemas baseados em computador estão 
sendo construídos:
• Por que se leva tanto tempo para concluir um 
software?
• Por que os custos de desenvolvimento são tão 
altos?
• Por que não podemos achar todos os erros an-
tes de entregar o software aos clientes?
• Por que continuamos a ter dificuldade em ava-
liar o seu progresso enquanto o software é de-
senvolvido?
Essas perguntas são manifestações da preocupa-
ção sobre o software e a maneira pela qual ele é 
Engenharia de Softwares e Engenharia de Requisitos 
11
desenvolvido. E, como vimos, questões como estas 
levaram à criação e adoção da Engenharia de Sof-
tware.
Assim, caro aluno, o desenvolvimento de software 
deve ser feito cercando todo o processo de bastante 
cuidado. Numa abordagem mais madura do proces-
so de desenvolvimento, podemos considerar diversos 
fatores, dentre os quais podemos citar: 
• Há similaridades e diferenças entre os projetos 
de software, assim os modelos definidos não 
são aplicáveis a todos os projetos;
• Existe uma estreita relação entre o processo 
de desenvolvimento e manutenção, e o produ-
to de software, sendo a escolha do processo 
fundamental para o alcance das características 
desejadas do produto;
• Para uma boa visibilidade do processo é essen-
cial o estabelecimento de critérios de medição 
apoiados em objetivos e modelos apropriados;
• O software é um processo experimental, no 
qual o aprendizado com realimentação para o 
processo de desenvolvimento e manutenção 
dos produtos é atividade natural;
• Avaliação e realimentação repetitiva são neces-
sárias para o aprendizado e inclusão de melho-
rias, além do controle individual de projetos;
• Gerir, registrar e distribuir corretamente as ex-
periências (ou cases) permitirá a construção de 
uma competência de software na organização;
• Uma variedade de experiências em relação ao 
processo, produto, recursos, defeitos e mode-
los de qualidade podem formar uma base de 
experiências atualizável;
• O processo de desenvolvimento e manutenção 
de software deve considerar a reutilização de 
experiências com definições de quando, como 
e onde reutilizar;
• As experiências podem ser armazenadas e dis-
ponibilizadas de formas variadas e integradas 
em repositórios de informações relacionando a 
similaridade de projetos, produtos, característi-
cas, fenômenos e outros.
Aplicações do Software
O software pode ser aplicado em qualquer situa-
ção para a qual um conjunto previamente especia-
lizado de procedimentos (um algoritmo) tenha sido 
definido.
 Exemplos de áreas de aplicações de software são:
• Software de sistema: coleção de programas 
para servir outros programas (compiladores, 
editores, utilitários para gestão de arquivos, 
componentes de sistemas operacionais, etc). 
Estes tipos de programas se caracterizam por 
manterem uma interação intensa com o har-
dware.
• Software de tempo real: monitora, analisa 
e controla eventos do mundo real à medida 
em que eles ocorrem. É o software que geren-
cia os recursos de um sistema computacional, 
com o objetivo de garantir que todos os even-
tos sejam atendidos dentro de suas restrições 
de tempo e sejam gerenciados da forma mais 
eficiente possível. Exemplos: sistema de radar 
aeroespacial, teclado que gera inputs de teclas 
pressionadas para um sistema microprocessa-
do, sensor de temperatura que gera um input 
para um microcontrolador, sistema de controle 
de voos, dentre outros.
• Software comercial: maior área de aplicação 
de software. Estão na categoria de software de 
aplicação que resolvem necessidades específi-
cas do negócio, como controle de reservas de 
Engenharia de Softwares e Engenharia de Requisitos 
12
voos, sistemas de pagamento, de controle de 
estoque, etc. 
• Software científico e de engenharia: ca-
racterizado por algoritmos que “processam nú-
meros” e realizam operações matemáticas e 
cálculos mais complexos (astronomia, análise 
automotiva de tensões, manufatura automati-
zada, previsão de tempo, simuladores, etc). 
• Softwareembutido: produtos “inteligentes”. 
São programas armazenados em ROMs – Read 
Only Memories, como controle de teclado para 
um forno de microondas, funções digitais em 
um automóvel – controle de combustível, mos-
tradores do painel, sistemas de frenagem, etc. 
Estes programas são chamados de firmware, 
que são programas gravados no hardware que 
controlam as funções dos dispositivos eletrôni-
cos.
• Software para web: as páginas da web recu-
peradas por um browser constituem software 
que incorpora instruções executáveis na forma 
de scripts, permitindo a inclusão de elemen-
tos dinâmicos, animações, acesso a banco de 
dados e diversas características que fazem as 
páginas HTML estáticas de antigamente pare-
cerem apenas folhas de um livro em papel.
• Software para computadores pessoais: 
esse mercado “explodiu” nos últimos anos, en-
globando uma enorme lista de aplicativos para 
os desktops e notebooks, como processadores 
de texto, planilhas, aplicações gráficas, aplica-
ções multimídia, etc. 
• Software para inteligência artificial: faz 
uso de algoritmos não numéricos para resolver 
problemas complexos, como sistemas de reco-
nhecimento de padrões (de imagem e de voz), 
redes neurais artificiais, sistemas de controle 
de robôs, etc.
Engenharia de Softwares e Engenharia de Requisitos 
13
Mitos do Software
Muitas crenças ou mitos foram criados acerca de 
acontecimentos ligados ao processo de desenvolvi-
mento de software, desde os primeiros programas. 
Mas são informações, muitas vezes, traiçoeiras. Os 
mitos podem parecer verdadeiros, trazer informa-
ções sobre fatos razoáveis e muitas vezes serem di-
vulgados por pessoas que “entendem do assunto”. 
Hoje os profissionais que conhecem a Engenharia de 
Software reconhecem os mitos pelo o que eles são 
na realidade: afirmações enganosas que já causaram 
prejuízo a diversos profissionais. 
Para que você, caro aluno, não seja enganado pe-
los mitos, pois eles ainda estão presentes em nosso 
meio, vamos apresentá-los a você nesta seção, com 
base na abordagem de Pressman (2010).
Mitos Administrativos ou Gerenciais
Gerentes estão frequentemente sob pressão para 
manter o orçamento, cumprir prazos e aumentar a 
qualidade. Devido a isso, é comum agarrarem-se a 
mitos que diminuem (temporariamente) essa pres-
são. 
• Mito:
Já temos o manual repleto de padrões e proce-
dimentos para a construção do software. Isso 
não oferecerá ao meu pessoal tudo o que eles 
precisam saber? 
• Realidade: 
- O manual existe. Mas é usado? 
- Os profissionais sabem da sua existência? 
- Ele reflete as práticas mais modernas de enge-
nharia de software? 
- É completo? 
- Está voltado p/ melhorar o prazo de entrega fo-
cado na qualidade?
Na maioria dos casos a resposta é “não”. 
• Mito: 
Meu pessoal tem ferramentas de software de 
última geração; afinal de contas lhes compra-
mos os mais novos computadores. 
• Realidade: 
É necessário mais do que computadores de 
última geração para fazer um desenvolvimen-
to de software de alta qualidade. Ferramentas 
Case são mais importantes. Contudo, a maioria 
dos desenvolvedores não as usam ainda, ou 
subutilizam-nas.
• Mito:
Se nós estamos atrasados nos prazos, podemos 
adicionar mais programadores e tirar o atraso. 
• Realidade:
Desenvolvimento de software não é um pro-
cesso mecânico. Quando novas pessoas são 
adicionadas, pessoas que estavam trabalhan-
do devem gastar tempo educando os novatos. 
Pessoas podem ser adicionadas, mas de um 
modo planejado e bem coordenado. 
• Mito:
Se decidirmos terceirizar um projeto vamos po-
der relaxar e deixar que a empresa o elabore. 
• Realidade:
Se uma organização não sabe como gerir e 
controlar seus projetos de software, terceirizá-
-los certamente trará outros problemas, talvez 
maiores. 
Engenharia de Softwares e Engenharia de Requisitos 
14
Mitos do Cliente 
Um cliente que encomenda um software pode ser 
uma pessoa na mesa vizinha, um grupo técnico em 
outra sala, o departamento de promoção/vendas ou 
uma empresa que encomendou software sob contra-
to. 
O cliente acredita em mitos de software, geral-
mente porque os gerentes e profissionais de software 
fazem pouco para corrigir essa desinformação. Mitos 
levam a falsas expectativas (pelo cliente) e à insatis-
fação com o desenvolvedor.
• Mito:
Uma declaração geral dos objetivos é suficiente 
para se começar a escrever programas – pode-
mos preencher os detalhes mais tarde. 
• Realidade:
Uma definição inicial ruim é a principal causa 
de falhas nos esforços de software. É essen-
cial uma descrição formal do domínio da infor-
mação, função, comportamento, performance, 
interface, restrições de projeto e critérios de 
validação. Necessária intensa comunicação en-
tre cliente e desenvolvedor. 
• Mito:
Os requisitos de projeto modificam-se continu-
amente, mas as mudanças podem ser facilmen-
te acomodadas, porque o software é flexível. 
• Realidade:
É verdade que os requisitos de software mu-
dam, mas o impacto das mudanças varia de 
acordo com o momento na qual ela ocorre. Em 
termos de custos, na fase de definição (x1), na 
fase de desenvolvimento (1,5 a 6x) e na fase 
de manutenção (60 a 100x). Deve ser dada 
muita atenção às definições iniciais. 
Mitos do Profissional 
Os mitos que ainda têm crédito entre os profissio-
nais de software sobreviveram a mais de 50 anos de 
cultura de programação. No início a programação era 
vista como uma forma de arte. 
• Mito:
Assim que escrevermos o programa e o colo-
carmos em funcionamento nosso trabalho es-
tará completo.
• Realidade:
Estudos mostram que, entre 60% a 80%, de 
todo o esforço gasto em um programa serão 
despendidos depois dele ter sido entregue, 
pela primeira vez, para o usuário.
• Mito:
Enquanto não tiver o programa “funcionando”, 
eu não terei realmente nenhuma maneira de 
avaliar sua qualidade. 
• Realidade:
Um dos mecanismos mais efetivos para garan-
tia de qualidade do software pode ser aplicado 
desde o seu início – a Revisão Técnica Formal 
(um filtro de qualidade). 
• Mito:
A única coisa a ser entregue em um projeto 
bem-sucedido é o programa funcionando. 
• Realidade:
O programa executável é uma das partes da 
configuração do software. A documentação é 
um fator importante também (alicerce para o 
desenvolvimento e guia para a manutenção). 
• Mito:
A engenharia de software vai nos fazer criar 
documentação volumosa e desnecessária que 
certamente nos atrasará. 
• Realidade:
A engenharia de software não se relaciona à 
criação de documentos. Refere-se à criação de 
qualidade. Melhor qualidade leva à redução de 
Engenharia de Softwares e Engenharia de Requisitos 
15
retrabalho. E menor retrabalho resulta em tem-
pos de entrega mais rápidos. 
Conclusão sobre os Mitos:
Profissionais de software devem reconhecer a fa-
lácia dos mitos. O reconhecimento das realidades do 
software é o primeiro passo em direção à formulação 
de soluções práticas e eficientes para a Engenharia de 
Software.
Engenharia de Softwares e Engenharia de Requisitos 
16
Exercícios do Capítulo 1 
1) Qual das questões abaixo não é mais uma das grandes preocupações de um engenheiro 
de software?
a) Por que normalmente se gasta tanto tempo para desenvolver software?
b) Por que, via de regra, software custa tão caro?
c) Por que quase sempre não se consegue remover todos os erros do software antes da sua entrega?
d) Por que hardware é tão caro?
2) Software é um produto que pode ser manufaturado usando as mesmas tecnologias 
usadas para outros artefatos de engenharia.
a) Verdadeiro
b) Falso
3) Software deteriora-se ao invés de se desgastar porque:
a) Software “sofre” quando exposto a ambientes “hostis”
b) Defeitos são mais prováveis de surgir quando o software é usado várias vezes
c) Mudançasfrequentes aumentam a probabilidade de se introduzir erros no software
d) Componentes de reposição de sofware são difíceis de se encontrar no mercado
4) Atividades “guarda-chuva” de engenharia de software são aplicadas somente durante 
as fases iniciais do desenvolvimento de software:
a) Verdadeiro
b) Falso
5) O que caracterizou a chamada “crise do software”?
6) Conforme vimos, Engenharia de Software é uma disciplina da Engenharia que se ocupa 
de todos os aspectos da produção de software. Seu principal objetivo é fornecer uma 
estrutura metodológica para a construção de software com alta qualidade. O que é ne-
cessário para que isso aconteça?
7) Normalmente, para o leigo, software se constitui no “código fonte + código executá-
vel”. Vimos que para a Engenharia de Software, o conceito de software é algo mais 
abrangente. Como Pressman conceitua software?
8) O processo de desenvolvimento do software apresenta diferenças fundamentais em 
relação ao hardware. Cite algumas dessas diferenças.
9) Faça um esboço das curvas de taxa de falhas do hardware e do software. Explique as 
diferenças entre as curvas.
Engenharia de Softwares e Engenharia de Requisitos 
17
Processo de Software
Caro aluno, neste capítulo descreveremos o que é um processo de software, mostraremos as 
camadas em que a Engenharia de Software se divide, descreveremos os padrões de processo, a 
avaliação e as ferramentas que apoiam o processo.
Conceitos Básicos de Processo de 
Software
Caro aluno, todo projeto de software inicia-se a 
partir de alguma necessidade do negócio. Assim que 
esta necessidade é identificada, esta costuma ser ex-
pressa de forma informal, através de uma conversa. 
Mas esta informalidade deve parar por aí. Até mesmo 
a especificação da necessidade do cliente é abrangida 
pelos métodos e técnicas da Engenharia de Software. 
E este é um processo bastante complexo. Então va-
mos começar a entendê-lo, conhecendo exatamente 
do que se trata um “processo de software”.
Para que as necessidades da empresa ou de um 
cliente possa se transformar numa solução de sof-
tware, todo o diálogo e a interação entre usuários, 
projetistas, ferramentas de desenvolvimento e tecno-
logias devem ser transformados num processo.
Assim, processo de software é um arcabouço 
(framework) das tarefas requeridas para se construir 
um software de alta qualidade. 
Mas, caro aluno, você pode estar se perguntan-
do: processo e engenharia de software são a mesma 
coisa?
A resposta é “sim” e “não”. Processo de software 
define a abordagem que é adotada quando o softwa-
re é elaborado. A Engenharia de Software engloba 
também as tecnologias que constituem um processo, 
como métodos, técnicas e ferramentas de desenvol-
vimento. Assim, a Engenharia de Software engloba 
os processos de software.
Podemos definir Engenharia de Software como 
um processo que envolve a criação e a utilização de 
sólidos princípios de engenharia a fim de obter sof-
tware com as características:
 D de alta qualidade
 D produzido de maneira econômica
 D que seja confiável
 D que trabalhe eficientemente em máquinas reais
 D que seja entregue no prazo
 D que satisfaça o cliente 
A Engenharia de Software é uma tecnologia em 
camadas, apoiada fundamentalmente num compro-
misso organizacional com a qualidade, como mostra 
a figura 3. Nesta abordagem, podemos observar que 
o alicerce da Engenharia de Software é a camada de 
processo, que funciona como um adesivo que man-
tém unidas as camadas ligadas à tecnologia. 
Figura 3
Engenharia de Software: uma tecnologia em camadas
O processo forma uma base para o controle 
gerencial de projetos de software e estabelece o 
contexto no qual os métodos e as técnicas são 
aplicados, os produtos do trabalho são produzidos, os 
marcos são estabelecidos, a qualidade é assegurada e 
as modificações adequadamente geridas.
Engenharia de Softwares e Engenharia de Requisitos 
18
Os métodos fornecem as técnicas de “como fazer” 
a construção de software. Abrangem um amplo con-
junto de tarefas que incluem comunicação, análise de 
requisitos, modelagem de projeto, construção de pro-
gramas, testes e manutenção.
As ferramentas fornecem apoio automatizado ou 
semi-automatizado para o processo e seus métodos.
Para que a Engenharia de Software possa ser apli-
cada como uma abordagem disciplinada para o de-
senvolvimento, operação e manutenção de um sof-
tware, um processo deve ser definido. De uma forma 
geral, um processo é caracterizado por fases: 
1. Fase de Definição 
2. Fase de Desenvolvimento 
3. Fase de Manutenção 
1. Fase de Definição: esta fase se concentra 
no “quê” o sistema de software irá realizar, isto é, 
identifica:
• que informação deve ser processada 
• que função e desempenho são desejados 
• que comportamento deve ser esperado do sis-
tema 
• que interfaces devem ser estabelecidas 
• que restrições de projeto existem 
• que critérios de validação são necessários 
Nessa fase, os requisitos-chave do sistema e do 
software são identificados. Esta fase engloba 3 im-
portantes etapas:
i. Engenharia de sistemas ou de informação 
ii. Planejamento do projeto 
iii. Análise de requisitos 
2. Fase de Desenvolvimento: esta fase foca-
liza “como” o desenvolvimento será realizado, isto é 
, define:
• como os dados devem ser estruturados 
• como as funções devem ser implementadas 
• como os detalhes procedimentais devem ser 
implementados 
• como as interfaces devem ser caracterizadas 
• como o projeto deve ser traduzido em uma lin-
guagem de programação 
• como o teste vai ser realizado 
Nesta fase, 3 etapas técnicas específicas ocorre-
rão:
i. Projeto do Software
ii. Geração de Código 
iii. Teste de Software 
3. Fase de Manutenção: esta fase tem como 
alvo as modificações e manutenções que o software 
sofrerá. Quatro tipos de modificações são encontra-
das durante essa fase:
• Manutenção Corretiva: modifica o software 
para corrigir defeitos 
• Manutenção Adaptativa: modifica o software 
para acomodar mudanças no seu ambiente ex-
terno (processador, sistema operacional, etc)
• Manutenção de Aperfeiçoamento: aprimora o 
software além dos requisitos funcionais origi-
nais (cliente/usuário reconhece e solicita fun-
cionalidades adicionais que trarão benefícios, à 
medida que o software é usado).
• Manutenção Preventiva: faz modificações nos 
programas de modo que eles possam ser mais 
facilmente corrigidos, adaptados e melhorados.
Estas 3 fases são complementadas por ativida-
des “guarda-chuva”:
 D Controle e Rastreamento do Projeto
 D Gestão de Riscos 
 D Revisões Técnicas Formais 
 D Garantia de Qualidade 
 D Gestão de Configuração de Software
 D Produção e Preparação de Produtos do Traba-
lho (documentos) 
 D Gestão de Reusabilidade 
 D Medição 
Engenharia de Softwares e Engenharia de Requisitos 
19
Essas atividades são aplicadas ao longo do pro-
cesso de software.
Padrões, Avaliação e Tecnologias 
de Processo 
De acordo com Pressman (2010), um processo de 
software pode ser definido como uma coleção de pa-
drões que definem um conjunto de atividades, ações, 
tarefas de trabalho e produtos de trabalho necessá-
rios para o desenvolvimento de software de compu-
tador. 
Em termos gerais, um padrão de processo nos 
fornece um gabarito que permite que sejam listadas 
as características mais importantes do processo de 
software. Mas é interessante notar, caro aluno, que 
uma equipe de desenvolvimento pode construir, pela 
combinação de padrões, um processo que melhor sa-
tisfaça às necessidades do projeto.
Descrever um padrão de projeto é uma tarefa mui-
to importante, pois permite se identificar particulari-
dades que facilitem a comparação entre os padrões, 
auxiliando na decisão de escolha por um padrão es-
pecífico. Gamma et al (1994) propõemum gabarito 
para esta definição, dividido em seções, como apre-
sentado a seguir:
• Nome do padrão e Classificação: o nome 
é muito importante para um padrão, pois deve 
indicar a essência do padrão em poucas pala-
vras. 
• Intenção do padrão: descreve o que o pa-
drão faz, qual a sua intenção e qual problema o 
padrão se propõe a resolver.
• Também conhecido como: um outro nome 
pelo qual o padrão é conhecido, caso exista.
• Motivação: um exemplo de problema de pro-
jeto e como a utilização do padrão resolve este 
problema.
• Aplicabilidade: condições em que o padrão 
pode ser aplicado, exemplo de situação em que 
o padrão é aplicado e como identificar essas 
situações.
• Estrutura: uma representação gráfica das 
classes no padrão utilizando uma linguagem de 
modelagem, em que possam ser representados 
os relacionamentos entre os objetos e sequên-
cias de requisições.
• Participantes: apresenta as classes e objetos 
que fazem parte do padrão e quais as suas res-
ponsabilidades.
• Colaborações: como os participantes colabo-
ram para atender as suas responsabilidades.
• Consequências: descreve como o padrão al-
cança seus objetivos, quais as decisões e re-
sultados de usar o padrão e que aspectos da 
estrutura do sistema podem ser variados inde-
pendentemente.
• Implementação: que detalhes de implemen-
tação devem ser observados se o padrão for 
implementado. Deve ser observado se existem 
detalhes específicos para uma determinada lin-
guagem.
• Exemplo de código: um exemplo de código 
que mostre como o padrão deve ser implemen-
tado em alguma linguagem.
• Usos conhecidos: exemplos do padrão en-
contrados em sistemas reais.
• Padrões relacionados: padrões que se as-
semelham a este padrão e quais as diferenças. 
Apresenta também outros padrões que podem 
ser utilizados em conjunto.
Engenharia de Softwares e Engenharia de Requisitos 
20
A existência ou a simples escolha de um processo de software não garante que o software será entregue 
no prazo, que ele atenda as necessidades do projeto e possua as características técnicas que garantirão sua 
qualidade no longo prazo. Os padrões de processo precisam estar ligados de forma sólida às práticas da 
Engenharia de Software. Além disso, o processo em si deve ser avaliado para garantir que ele satisfaça a um 
conjunto de critérios essenciais para o desenvolvimento bem sucedido. O relacionamento entre o processo 
de software e os métodos aplicados para sua avaliação e melhoria é mostrado na figura 4.
Figura 4
Processo de Software, Avaliação e Melhoria de Processo
Como vimos, os modelos de processo podem e 
devem ser adaptados para o uso de uma determina-
da equipe de projeto de software. Para que se possa 
conseguir isso, foram desenvolvidas diversas ferra-
mentas de tecnologia de processo de forma a ajudar 
as organizações a analisar o processo que utiliza, or-
ganizar as tarefas de trabalho, controlar e monitorar 
o progresso do desenvolvimento e ainda gerenciar 
sua qualidade técnica.
Os componentes da equipe de desenvolvimento 
podem utilizar as ferramentas para desenvolver um 
checklist das tarefas de trabalho a seu cargo. As fer-
ramentas de tecnologia de processo também podem 
ser utilizadas para coordenar e gerenciar o uso de 
outras ferramentas de engenharia de software apoia-
das por computador adequadas às diversas tarefas 
de trabalho.
Como vimos neste capítulo, a Engenharia de Sof-
tware é uma disciplina que integra processo, métodos 
e ferramentas para o desenvolvimento de projetos de 
software. Há diversos modelos de processo, mas todos 
possuem algumas características em comum, definindo 
um conjunto de atividades de arcabouço, uma coleção 
de tarefas para que se consiga realizar as atividades, 
produtos de trabalho produzidos nas tarefas e um con-
junto de atividades guarda-chuva que apóiam as ativi-
dades de todo o processo. 
Vimos, também, que padrões de processo podem 
ser utilizados para definir as características de um pro-
cesso.
Engenharia de Softwares e Engenharia de Requisitos 
21
Exercícios do Capítulo 2 
1) Processos de software podem ser construídos de modelos pré-existentes objetivando 
se adequar às necessidades de um determinado projeto
a) Verdadeiro
b) Falso
2) A essência da prática da engenharia de software pode ser resumida em compreender o 
problema, planejar a solução, executar o plano e examinar o resultado.
a) Verdadeiro
b) Falso
3) Qual dos itens listados abaixo não se constitui numa das camadas da engenharia de 
software?
a) Processo
b) Manufatura
c) Métodos
d) Ferramentas
4) Cite que tipos de manutenção um software pode sofrer.
5) As atividades “guarda-chuva” dão “cobertura” para as fases envolvidas na produção de 
software. Cite algumas dessas atividades.
6) Há uma ilusão por parte de alguns desenvolvedores que basta selecionar um modelo 
de processo e aplicá-lo para se obter software de qualidade, dentro do prazo e custos 
estabelecidos. Comente sobre esse “mito”.
Engenharia de Softwares e Engenharia de Requisitos 
22
Modelos de Processo 
Caro aluno, neste capítulo definiremos o que é ciclo de vida de software, quais suas principais 
etapas e descreveremos os principais modelos de processo de software: Modelo em Cascata, Mo-
delos Evolucionários (Modelo de Prototipagem, Modelo Espiral e Modelo Concorrente), Modelos 
Incrementais (Modelo RAD e Modelo Incremental), Modelo Baseado em Componentes, Modelo de 
Métodos Formais, Processo Unificado e Métodos Ágeis de Desenvolvimento.
Ciclo de Vida e Modelos de Processo 
O ciclo de vida de um software descreve as fases pelas quais o software passa desde a sua concepção até 
a descontinuidade de seu uso. O conceito de ciclo de vida de um software é muitas vezes confundido com o 
de modelo de processo, mas são conceitos bem diferentes, como veremos a seguir. 
Existem várias propostas e denominações para as 
fases do ciclo de vida de um software. Nesta nossa 
abordagem, vamos trabalhar com 4 fases, que são 
as mais típicas em diversos ciclos de vida, de acordo 
com a proposta de Leite (2007). Cada fase inclui um 
conjunto de atividades ou disciplinas que devem ser 
realizadas pelas pelos envolvidos no processo de de-
senvolvimento. Essas fases são:
1. Fase de Definição
2. Fase de Desenvolvimento
3. Fase de Operação
4. Fase de Retirada
1. Fase de Definição
A fase de definição do software ocorre em con-
junto com outras atividades como a BPM – Business 
Process Modeling ou Modelagem de Processos de 
Negócios e Análise de Sistemas. Nestas atividades, 
diversos profissionais fazem o levantamento da situ-
ação atual em busca da identificação de problemas, 
para que possam elaborar propostas de solução de 
sistemas computacionais que os resolvam. Dentre as 
propostas apresentadas, deve-se fazer um Estudo de 
Viabilidade, incluindo a Análise de Custo-Benefício, 
para se decidir qual solução será a escolhida.
O resultado desta atividade deve incluir a decisão 
se o sistema será adquirido ou desenvolvido, indi-
cando informações sobre necessidades de hardware, 
ferramentas de software, pessoal, procedimentos, in-
formação e documentação.
Caso haja uma decisão pelo desenvolvimento do 
sistema, no escopo da Engenharia de Software, tor-
na-se essencial elaborar o documento de Proposta de 
Desenvolvimento de Software, que pode ser a base 
de um Contrato de Desenvolvimento.
Nesta fase, os profissionais devem realizar uma 
tarefa de extrema importância, que é fazer o levan-
tamento dos Requisitos de Software e Modelos de 
Domínio. Os requisitos são fundamentais para que o 
engenheiro de software possa elaborar um Plano de 
Desenvolvimento de Software, indicando em deta-
lhes os recursos necessários (humanos e materiais), 
bem como as estimativas de prazos e custos (crono-
grama e orçamento).Engenharia de Softwares e Engenharia de Requisitos 
23
2. Fase de Desenvolvimento
A fase de desenvolvimento ou de produção do sof-
tware inclui todas as atividades que têm por objetivo 
a construção do produto. Esta fase inclui as ativida-
des de projeto, implementação, verificação e valida-
ção do software.
 D Projeto
A atividade de projeto compreende todo o es-
forço de concepção e modelagem que tem por 
objetivo descrever como o software será imple-
mentado. O projeto inclui:
o Projeto conceitual: envolve a elaboração das 
ideias e conceitos básicos que determinam os 
elementos fundamentais do software a ser de-
senvolvido.
o Projeto da interface com o usuário: envolve 
a elaboração das formas como o usuário vai 
interagir para realizar suas tarefas, a escolha 
dos objetos de interfaces (botões, menus, cai-
xas de texto, etc.), o layout de janelas e telas, 
dentre outros; a interface deve garantir uma 
usabilidade satisfatória do software e é um fa-
tor fundamental de sucesso do software.
o Projeto da arquitetura do software: se refere à 
elaboração de uma visão macroscópica do sof-
tware em relação aos componentes que intera-
gem entre si. São exemplos de visões arquite-
tônicas, a visão conceitual, visão de módulos, 
visão de código e visão de execução.
o Projeto dos algoritmos e estruturas de dados: 
objetiva determinar, de maneira independente 
da linguagem de programação a ser adotada, 
as soluções algorítmicas e as estruturas de da-
dos associados.
 D Implementação 
A implementação envolve as atividades de co-
dificação, compilação, integração e testes. A 
codificação visa traduzir o projeto num progra-
ma utilizando linguagens e ferramentas ade-
quadas. A codificação deve refletir a estrutura e 
o comportamento descrito no projeto da arqui-
tetura do software. Os testes podem ser inicia-
dos durante a fase de implementação. A depu-
ração de erros ocorre durante a programação 
utilizando técnicas e ferramentas adequadas. É 
fundamental que se adote um controle e ge-
renciamento de versões para que se tenha total 
controle de tudo o que está sendo codificado.
 D Verificação e Validação
São atividades que se destinam a mostrar que 
o sistema está de acordo com a especificação 
e que ele atende às expectativas de clientes e 
usuários. A validação visa assegurar que o pro-
grama está fazendo o que foi definido na sua 
especificação. A verificação visa certificar se o 
programa está correto, isto é, se não possui 
erros de execução e está fazendo de forma cor-
reta suas funcionalidades. Existem diferentes 
formas de verificação e validação. Os testes de 
correção, desempenho, confiabilidade, robus-
tez, usabilidade, dentre outros, podem ser usa-
dos para avaliar diversos fatores de qualidade 
a partir da execução do software. 
3. Fase de Operação
A fase de operação envolve diferentes tipos de ati-
vidades:
• Distribuição e entrega
• Instalação e configuração
• Utilização
• Manutenção
Engenharia de Softwares e Engenharia de Requisitos 
24
A distribuição e entrega pode ser feita diretamente 
pelo desenvolvedor (em caso de software personali-
zado) ou em um pacote a ser vendido em prateleiras 
de lojas ou para ser baixado pela internet.
O processo de instalação e configuração, normal-
mente, pode ser feito com a ajuda de software de 
instalação disponibilizados pelos fabricantes dos am-
bientes operacionais.
 A utilização é a efetiva entrada em operação 
do software. A qualidade da utilização reflete a usa-
bilidade do software.
A manutenção normalmente ocorre de forma cor-
retiva, adaptativa, de aperfeiçoamento e evolutiva. 
As manutenções podem ser relativas à resolução de 
problemas referentes à qualidade do software (fa-
lhas, baixo desempenho, baixa usabilidade, falta de 
confiabilidade, etc.), à produção de novas versões 
do software de forma a atender aos novos requisi-
tos dos clientes, ou adaptar-se às novas tecnologias 
que surgem (hardware, plataformas operacionais, 
novas linguagens e paradigmas, etc). Mudanças no 
domínio de aplicação implicam em novos requisitos e 
incorporação de novas funcionalidades. Surgimento 
de novas tecnologias de software e hardware e mu-
danças para uma plataforma mais avançada também 
requerem evolução.
4. Fase de retirada
A fase de retirada ou desuso de um software é um 
grande desafio para os tempos atuais. Há diversos 
sistemas que estão em funcionamento em empre-
sas, que possuem ótimos níveis de confiabilidade e 
de correção. No entanto, estes sistesmas precisam 
evoluir para novas plataformas operacionais ou para 
permitirem a incorporação de novos requisitos e fun-
cionalidades. A retirada desses sistemas legados em 
uma empresa é sempre uma decisão difícil: como se 
desfazer daquilo que é confiável e ao qual os funcio-
nários estão acostumados, após anos de treinamento 
e utilização?
Nestes casos, processos de reengenharia podem 
ser aplicados para viabilizar a transição ou a migra-
ção de um software legado para um novo software 
de forma a proporcionar uma retirada mais suave.
Para resolver problemas reais, um engenheiro de 
software deve incorporar uma estratégia de desen-
volvimento que abrange as camadas de processo, 
métodos e ferramentas e as fases genéricas da En-
genharia de Software. Essa estratégia é definida 
como Modelo de Processo. 
O modelo de processo é escolhido com base:
• na natureza do projeto e da aplicação a ser 
desenvolvida
• nos métodos e ferramentas a serem utilizados 
• nos controles e produtos que precisam ser en-
tregues 
Alguns Modelos de Processo incluem:
• Modelo em Cascata
• Modelo de Prototipação 
• Modelo RAD 
• Modelo Incremental
• Modelo Espiral
• Modelo de Desenvolvimento Baseado em Com-
ponentes
• Modelo de Desenvolvimento Concorrente
• Modelo de Métodos Formais
• Modelos de Processos Ágeis
No que se segue estes modelos serão agrupados 
em categorias e detalhados, de forma que você, caro 
aluno, possa conhecer suas características, potencia-
lidades, limitações e aplicações mais adequadas.
Engenharia de Softwares e Engenharia de Requisitos 
25
Modelos Prescritivos de Processo
Processos prescritivos são uma categoria que en-
globa os processos que possuem pontos observáveis 
que a cada passo podem ser verificados e classifica-
dos como válidos ou sujeitos a ajustes.
Enquanto um modelo descritivo retrata como um 
processo é executado, um modelo prescritivo retrata 
como um processo deveria ser executado. Assim, um 
modelo prescritivo é uma recomendação que pode 
ser adaptada ou melhorada pela empresa/equipe de 
software que for adotá-la.
Os instrumentos prescritivos do processo de pla-
nejamento estratégico explicitam o que deve ser fei-
to pela organização para se direcionar o esforço de 
desenvolvimento de software. Um modelo prescritivo 
de processo atua como complemento com conjun-
tos explícitos de tarefas explícitas para o desenvolvi-
mento. Cada modelo prescritivo de processo também 
prescreve um fluxo de trabalho ou maneira como os 
elementos se inter-relacionam.
Há vários modelos que são classificados nesta ca-
tegoria:
• Modelo em Cascata
• Modelos Evolucionários
o Modelo de Prototipagem
o Modelo Espiral
o Modelo Concorrente
• Modelos Incrementais
o Modelo RAD 
o Modelo Incremental
• Modelo Baseado em Componentes
• Modelo de Métodos Formais
• Processo Unificado
Modelo em Cascata
No modelo em cascata, também conhecido como ciclo de vida clássico, o processo de desenvolvimento 
de software é visto como uma abordagem sistemática e sequencial que começa com a especificação dos 
requisitos do cliente e progride seguindo as etapas de planejamento, modelagem, construção e implantação 
do sistema, conforme ilustra a figura 5, culminando na manutenção progressiva do produto entregue.
Figura 5
Modelo em CascataEste modelo é o paradigma mais antigo da Enge-
nharia de Software e é bastante criticado em função 
dos problemas encontrados nos projetos em que é 
aplicado. A realidade tem mostrado que num projeto 
raramente se segue o fluxo sequencial que o modelo 
propõe, gerando problemas futuros que oneram os 
custos e prazos. Uma das causas mais comuns deste 
problema é a dificuldade do cliente em declarar cla-
ramente todas as suas necessidades e expectativas, 
ou seja, de definir todos os requisitos inicialmente. O 
foco incorreto ou não claro pode gerar uma distorção 
que reflete diretamente na percepção de qualidade 
por parte do próprio cliente. Isso pode levar a en-
tregas parciais do produto, o que exige que o cliente 
tenha muita paciência durante os aceites parciais que 
são formalizados em um Documento de Encerramen-
to do Projeto com observações no campo Restrições 
“Entrega Parcial de Projeto”, que contém detalhes 
Engenharia de Softwares e Engenharia de Requisitos 
26
quanto à aceitação condicional do projeto por parte 
do cliente.
Os trabalhos de desenvolvimento de software atu-
ais seguem ritmos muito rápidos, sujeitos a diversas 
modificações, o que torna o modelo em cascata ina-
dequado para estes tipos de projeto. Mas, cumpre 
ressaltar, caro aluno, que embora o Modelo em Cas-
cata ou Ciclo de Vida Clássico tenha fragilidades, ele 
é significativamente melhor do que uma abordagem 
casual para o desenvolvimento de software.
Modelos Evolucionários de 
Processo
São modelos que consideram a natureza evolutiva 
do software. Os modelos evolucionários são iterati-
vos. São implementados de forma a permitir o desen-
volvimento de versões cada vez mais completas do 
software. Suas características incluem:
• São usados quando o deadline (limite de tem-
po) não é adequado para o desenvolvimento 
do software, ou seja, a data de término não 
é realística (por exemplo, prazos reduzidos de 
mercado face à competitividade).
• Uma versão limitada pode ser introduzida para 
atender a essa competitividade e às pressões 
do negócio. 
• São liberados produtos “core” (“núcleo dos pro-
dutos”) ao longo do desenvolvimento.
• Os detalhes e extensões do projeto são defini-
dos ao longo do desenvolvimento. 
Os modelos que são agrupados nesta categoria 
são: Prototipação, Modelo Espiral e Modelo Concor-
rente, que são apresentados no que se segue.
Prototipação
É um modelo de processo que possibilita que o 
desenvolvedor crie um modelo do software que deve 
ser construído. Idealmente, o modelo (protótipo) ser-
ve como um mecanismo para identificar os requisitos 
de software. É apropriado para quando o cliente defi-
niu um conjunto de objetivos gerais para o software, 
mas não identificou requisitos de entrada, processa-
mento e saída com detalhes. 
Envolve o desenvolvimento de uma versão inicial 
do sistema baseada no atendimento dos requisitos 
ainda pouco definidos. Este processo permite a des-
coberta de falhas difíceis de serem encontradas na 
comunicação verbal, servindo de apoio à fase de 
levantamento de requisitos prevenindo as possíveis 
falhas no sistema. 
O objetivo principal de um protótipo é simular a 
aparência e funcionalidade do software permitindo 
que os clientes, analistas, desenvolvedores e geren-
tes compreendam plenamente os requisitos do siste-
ma interagindo, avaliando, alterando e aprovando as 
características mais relevantes que o produto deva 
ter. A figura 6 ilustra este processo.
Figura 6
Modelo de Prototipação
Certamente a redução de custos no desenvolvi-
mento é um dos grandes ganhos de da prototipação, 
pois envolve diretamente o usuário final permitindo 
um desenvolvimento mais próximo dos desejos do 
cliente priorizando a facilidade de uso. Assim, pode-
-se obter um nível de satisfação maior em função 
do menor número de erros ou falhas de desenvolvi-
mento comuns na passagem de informação entre o 
analista (que fez o levantamento de requisitos) e o 
desenvolvedor (equipe de desenvolvimento). 
Engenharia de Softwares e Engenharia de Requisitos 
27
Um dos riscos envolvidos neste modelo é o descomprometimento com a análise do produto, visto que os envolvi-
dos podem se apoiar totalmente no modelo prototipado gerando uma expectativa muitas vezes irrealista de desem-
penho, em função do protótipo ser muito mais enxuto do que o produto final e estar em ambiente controlado. 
Além disso, o cliente não sabe que o software que ele vê não considerou, durante o desenvolvimento, a qualidade 
global e a manutenibilidade a longo prazo. Ele pode, também, não aceitar facilmente a ideia de que a versão final 
do software está sendo construída e tentar forçar a utilização do protótipo como produto final. 
Outro risco deste modelo é que o desenvolvedor frequentemente faz uma implementação comprometida (utili-
zando partes de programas existentes, geradores de relatórios, geradores de janelas) com o objetivo de produzir 
rapidamente um protótipo executável. Depois de um tempo ele se familiariza com essas escolhas, e pode se esque-
cer que elas não são apropriadas para o produto final.
Ainda que possam ocorrer problemas, a prototipação é um modelo eficiente. A chave para seu sucesso é 
definirem-se as regras do jogo logo no começo. O cliente e o desenvolvedor devem ambos concordar que o 
protótipo seja construído para servir como um mecanismo a fim de se definir os requisitos do projeto. A figura 
7 traz uma outra visão deste processo. 
Modelo Espiral
Desenvolvido para abranger as melhores características do Modelo em Cascata e da Prototipação, acres-
centando, ao mesmo tempo, um novo elemento: a análise de riscos.
Figura 7 Outra visão do Modelo de Prototipação
Engenharia de Softwares e Engenharia de Requisitos 
28
O modelo em espiral foi desenvolvido por Barry Boehm (1988) em seu artigo intitulado “A Spiral Model of 
Software Development and Enhancement”. Este modelo foi o primeiro a explicar o porquê do modo iterativo 
e elencar suas vantagens. As iterações têm uma duração típica de seis meses a dois anos. Cada fase inicia-se 
com um objetivo esperado e termina como uma revisão pelo cliente do progresso (que deve ser interna) e 
assim por diante. Esforços de análise e engenharia são aplicados em cada fase do projeto, tendo sempre o 
foco no objetivo do projeto. A figura 8 ilustra este processo.
As principais características deste modelo são:
• Engloba a natureza iterativa da Prototipação 
com os aspectos sistemáticos e controlados do 
Modelo em Cascata.
• Fornece potencial para o desenvolvimento rápi-
do de versões incrementais do software.
• O processo se inicia com a equipe de desen-
volvimento movendo-se em volta da espiral, no 
sentido horário, a partir do centro.
• O primeiro circuito em torno da espiral pode 
resultar na especificação do produto.
• Nas primeiras iterações, a versão incremental 
pode ser um modelo em papel ou um protóti-
po.
• Nas iterações mais adiantadas são produzidas 
versões incrementais mais completas e melho-
radas.
É uma abordagem realística para o desenvolvi-
mento de software de grande porte. Como o softwa-
re evolui na medida em que o processo avança, o 
cliente e o desenvolvedor entendem melhor e rea-
gem aos riscos em cada nível evolucionário. Para pe-
quenos projetos, os conceitos de desenvolvimento de 
software ágil tornam-se uma alternativa mais viável. 
Como vantagens deste modelo, podemos citar as 
estimativas realísticas dadas à identificação de pro-
Engenharia de Softwares e Engenharia de Requisitos 
29
blemas importantes logo no início do processo, ver-
satilidade para lidar com mudanças (quando inevi-
táveis), desenvolvimento antecipado por parte dos 
engenheiros de software que têm visibilidade das 
necessidades por fases, Usa prototipagem (em qual-
quer estágio de evolução do produto)como mecanis-
mo de redução de risco.
No entanto, o uso do modelo Espiral exige con-
siderável experiência na determinação de riscos e 
depende dessa experiência para ter sucesso. Além 
disso, pode ser difícil convencer os clientes que uma 
abordagem “evolutiva” é controlável.
Modelo de Desenvolvimento Concorrente
De acordo com Pressman (2010), o modelo de 
Desenvolvimento Concorrente, também chamado de 
Engenharia Concorrente, pode ser representado, es-
quematicamente, como uma série de atividades de 
arcabouço, ações e tarefas da Engenharia de Softwa-
re e seus estados associados. 
Um exemplo do uso deste modelo pode ver visto 
na figura 9. A figura traz a atividade “Modelagem” do 
modelo Espiral (veja figura 8), espelhada no modelo 
Concorrente. 
Figura 9
Transições de Estado no Modelo de Desenvolvimento Concorrente
No modelo Concorrente, uma atividade pode estar 
em qualquer um dos estados apresentados na figu-
ra (em desenvolvimento, sob inspeção, aguardando 
modificações, etc) a qualquer tempo. O modelo defi-
ne uma série de eventos que vão disparar transições 
de um estado para outro, para cada uma das ativida-
des, ações ou tarefas da Engenharia de Software. Por 
exemplo, suponha que durante os estágios da etapa 
de projeto, descobre-se uma inconsistência no mo-
delo de análise. Isso geraria o evento “correção no 
modelo de análise”, que, por sua vez, implicaria na 
passagem da atividade de análise do estado “pronto” 
para o estado “aguardando modificações”
De forma geral, as principais características deste 
modelo são:
• Todas as atividades ocorrem em paralelo, mas 
estão em diferentes estados.
Engenharia de Softwares e Engenharia de Requisitos 
30
• O modelo define uma série de eventos que vão 
disparar transições de estado para estado, para 
cada uma das atividades.
• Em vez de usar uma sequência como o modelo 
em cascata, ele define uma rede de atividades. 
• Eventos gerados dentro de uma certa atividade 
ou em algum outro lugar da rede de atividades 
disparam transições entre estados de uma ati-
vidade
• Pode ser aplicado a todo tipo de desenvolvi-
mento de software e fornece uma visão exata 
de como está o estado do projeto. 
• Em vários projetos pode existir uma simultanei-
dade (concorrência) entre as várias atividades 
de desenvolvimento e de gestão de projetos. 
• É representado como uma série de grandes 
atividades técnicas, tarefas e seus estados as-
sociados (fornece um panorama preciso do es-
tado atual do projeto).
O software moderno é caracterizado por modifica-
ções contínuas, prazos muito curtos e por uma ne-
cessidade premente de satisfazer o usuário ou cliente. 
Os modelos evolucionários de processo foram criados 
com o objetivo de resolver estes problemas, mas tam-
bém têm suas fragilidades. Uma delas é que a proto-
tipagem pode trazer problemas para o planejamento 
do projeto em função do número impreciso de ciclos 
necessários para se concluir o produto. Outra se refere 
ao foco dado à flexibilidade e extensibilidade ao invés 
da alta qualidade. Se o foco for centrado na qualidade, 
o projeto pode resultar em atraso, o que pode compro-
meter a competitividade do empreendimento.
Modelos Incrementais de Processo
Caro aluno, há diversas situações em que os re-
quisitos iniciais do software estão razoavelmente 
bem definidos, mas o escopo global do processo de 
desenvolvimento claramente elimina uma aborda-
gem puramente linear ou sequencial. Adicionalmente 
pode haver a necessidade de se fornecer rapidamente 
um conjunto limitado de funcionalidades do software 
aos usuários e depois refinar, melhorar e expandir 
aquela funcionalidade em versões mais avançadas 
do software. Nestes casos, os modelos de processo 
que produzem software em incrementos são os mais 
indicados.
Os processos incrementais que discutiremos aqui 
incluem o Modelo Incremental e o Modelo RAD – Ra-
pid Application Development (Desenvolvimento Rápi-
do de Aplicação).
Modelo Incremental
O modelo incremental combina elementos do mo-
delo em cascata, mas aplicados de forma interativa. 
O modelo de processo incremental é interativo como 
a prototipagem, mas diferentemente da prototipa-
gem, o incremental tem como objetivo apresentar 
um produto operacional a cada incremento realizado. 
Este processo pode ser visto na figura 10.
Esse modelo é muito útil quando a empresa não 
possui mão de obra disponível, num dado período, 
para uma implementação completa, dentro do prazo 
estipulado.
Engenharia de Softwares e Engenharia de Requisitos 
31
De uma forma geral, o Modelo Incremental apre-
senta as características:
• Combina elementos do Modelo em Cascata 
(aplicado repetitivamente) com a filosofia itera-
tiva da Prototipação.
• Aplica sequências lineares de uma forma racio-
nal à medida que o tempo passa.
• Cada sequência linear produz um incremento 
do software e pode gerar uma entrega parcial 
do produto.
• Os primeiros incrementos são versões simplifi-
cadas do produto final.
• O primeiro incremento é chamado de “núcleo 
do produto” (core). 
Um exemplo clássico de aplicação do Modelo In-
cremental é no desenvolvimento de um processador 
de texto. Para este projeto as etapas incrementais 
podem ser assim definidas:
[1] Primeiro Incremento: poderia efetuar as fun-
ções de controle de versões de arquivos, edi-
ção e produção de documentos 
Figura 10
Modelo de Processo Incremental
[2] Segundo Incremento: adicionaria capacidade 
de edição e de produção de documentos mais 
sofisticadas 
[3] Terceiro Incremento: incluiria a verificação 
sintática e gramatical 
[4] Quarto Incremento: adicionaria a capacidade 
avançada de disposição de página 
Note que todo o processo pode se repetir até que 
um produto completo seja produzido. 
Modelo RAD - Rapid Application Develop-
ment
O modelo RAD - Rapid Application Development 
(Desenvolvimento Rápido de Aplicação) é uma adap-
tação do modelo em Cascata, mas que enfatiza um 
desenvolvimento extremamente rápido. A “alta ve-
locidade” é conseguida através de uma abordagem 
de construção baseada em componentes, ou seja, o 
sistema é modularizado.
Se os requisitos forem bem definidos e o objetivo 
do projeto for restrito, a equipe pode criar um siste-
ma plenamente funcional em pouco tempo.
Engenharia de Softwares e Engenharia de Requisitos 
32
O RAD enquadra-se no modelo de atividades de arcabouço do Modelo em Cascata:
• Especificação: atividade em que se entende o problema de negócio, as características das informações 
e é realizado o levantamento de requisitos.
• Planejamento: atividade essencial. Várias equipes trabalham em paralelo em diferentes funções.
• Modelagem: estabelece representações de projeto que servem como base para a atividade de constru-
ção. Abrange três fases:
o Modelagem de negócio
o Modelagem de dados
o Modelagem de processo 
• Construção: faz uso de componentes de software preexistentes e geração de códigos.
• Implantação: estabelece a base para iterações subsequentes, se necessárias.
A figura 10 apresenta a representação esquemática do modelo RAD em relação ao modelo sequencial 
tradiconal.
Figura 11 Modelo RAD x Modelo Tradicional
Fonte: http://www.etondigital.com/services/rapid-application-development/
As situações de desenvolvimento mais adequadas 
para se utilizar o Modelo RAD incluem: 
• Projetos em que os requisitos estão bem defini-
dos, o objetivo do sistema é restrito e se deseja 
criar um “sistema plenamente funcional” den-
tro de períodos muito curtos (por exemplo, de 
60 a 90 dias, como a figura 11 sugere)
• Projetos em que há fortes restrições de tempo 
impostas pelo cliente .
• Aplicações que podem ser modularizadas de 
forma que cada função principal possa ser 
completada em menos de 3 meses. 
• Projetos em que cada função principal possaser alocada para uma equipe distinta e depois 
integradas para formar o todo do produto.
Engenharia de Softwares e Engenharia de Requisitos 
33
Mas, a utilização do modelo RAD também pode 
implicar em problemas. Para projetos grandes, mas 
mensuráveis, o RAD requer um número elevado de 
recursos humanos que sejam suficientes para criar 
um número adequado de equipes. Além disso, o RAD 
requer um comprometimento entre desenvolvedores 
e clientes para que as atividades possam ser realiza-
das rapidamente e o sistema seja concluído em um 
tempo curto. Se o comprometimento for abandonado 
por qualquer das partes, o projeto falhará. O uso do 
RAD também não é apropriado quando os riscos téc-
nicos são grandes (por exemplo, quando a aplicação 
faz uso de uma nova tecnologia).
Desenvolvimento Baseado em 
Componentes
O Desenvolvimento Baseado em Componentes ou 
CBD- Component-based Development, também é co-
nhecido como Component-based Software Enginee-
ring (CBSE) ou simplesmente como Componente de 
Software. Hoje em dia é muito comum que os desen-
volvedores utilizem componentes de software que 
são encontrados em bibliotecas de uso gratuito ou 
mesmo disponíveis para compra. Estes componentes 
são conhecidos como COTS– Commercial-Off-The-
-Shelf, ou software comercial de prateleira. Geral-
mente estes componentes oferecem funcionalidades 
com interfaces bem definidas que podem ser facil-
mente integrados no software sendo desenvolvido.
O método de Desenvolvimento Baseado em Com-
ponentes incorpora as características de construção 
de componentes de biblioteca ao Modelo Espiral. 
De natureza evolucionária, adota uma abordagem 
iterativa para a criação de software. Assim, o mo-
delo constrói aplicações a partir de componentes de 
software previamente preparados. As atividades de 
modelagem e construção começam com a identifica-
ção de componentes candidatos. Esses componen-
tes podem ser projetados como módulos de software 
convencional ou como classes ou pacotes de classes 
orientadas a objeto.
No paradigma orientado a objetos uma classe 
encapsula dados e algoritmos, que também podem 
ser utilizados para manipular os dados. Através des-
ta abordagem, uma biblioteca de classes pode ser 
construída com as classes identificadas no desenvol-
vimento do software e a partir de então toda iteração 
da espiral deverá verificar o conteúdo da biblioteca 
que pode ser reutilizado. A figura 12 ilustra este pro-
cesso.
Figura 12
Modelo do Desenvolvimento Baseado em Componentes
Engenharia de Softwares e Engenharia de Requisitos 
34
O modelo de Desenvolvimento Baseado em Componentes leva ao reuso de 
software, e a reusabilidade fornece aos engenheiros vários benefícios. Com base 
nesta reusabilidade, estudos relatam uma redução de 70% no prazo do ciclo de 
desenvolvimento e de 84% no custo dos projetos desenvolvidos neste modelo de 
processo, com índices de produtividade em torno de 26.2, superior ao índice pa-
drão de 16.9 da indústria. [PRESSMAN, 2006].
O reuso de software se refere à utilização de software existente para o desenvolvimento de um novo sof-
tware. A decisão quanto à utilização de componentes reutilizáveis envolve comparações entre o investimento 
necessário para a sua aquisição e os gastos para o desenvolvimento de uma solução customizada. Devem ser 
estimados os custos e benefícios líquidos no investimento em reuso de software e serem avaliados os ganhos 
com a adoção do reuso.
Muitos métodos para o reuso estão em prática no mercado atual, sendo sua escolha determinada pela sua 
adequação ao modelo de negócio ou às tecnologias utilizadas.
O RiSE - Reuse in Software Engineering, por exemplo, é um esforço em direção a um efetivo framework de 
métodos, processos, ferramentas e boas práticas relacionados ao reuso de software que compreende aspectos 
técnicos e não técnicos.
O CRUISE - Component Reuse in Software Engineering, no formato de livro on line e livre com foco em 
reuso de software, é um dos primeiros esforços em mapear o reuso de software que cita as áreas chave, de-
senvolvimento baseado em componentes, reengenharia, ferramentas, qualidade de componentes de software, 
métricas para reuso, repositórios, engenharia de domínio, linhas de produtos, entre outros aspectos.
O RAD - Rapid Application Development, visto anteriormente, é um modelo de processo de desenvolvimen-
to de software iterativo e incremental que enfatiza um ciclo de desenvolvimento extremamente curto (entre 60 
e 90 dias) tendo um foco considerável no reuso para se atingir um prazo tão justo tornando-o uma técnica de 
quarta geração que reutiliza componentes de programas existentes ou cria componentes reutilizáveis.
Modelo de Métodos Formais
Os métodos formais são técnicas baseadas em for-
malismos matemáticos que podem ser usados para a 
especificação, desenvolvimento e verificação de sis-
temas de software. Seu uso para o desenvolvimento 
de software é motivado pela base que fornecem ga-
rantindo confiabilidade e robustez a um projeto, uma 
vez que executam análises matemáticas apropriadas. 
No entanto, o alto custo do uso de métodos formais 
restringe o seu uso ao desenvolvimento de sistemas 
de alta integridade, no qual há alta probabilidade das 
falhas conduzirem à perda de vidas ou sérios preju-
ízos (como nas missões espaciais e no controle de 
vôos, por exemplo). 
Engenharia de Softwares e Engenharia de Requisitos 
35
No modelo de Métodos Formais, também conhe-
cido como Engenharia de Software Cleanroom (Sala 
Limpa), uma questão fundamental é garantir que o 
software é realmente uma solução para o problema 
proposto. Para realizar tal tarefa, deve-se primeiro 
construir um modelo da solução (especificação) uti-
lizando uma linguagem formal. Tendo este modelo 
formal como base, o método permite:
• realizar provas matemáticas que garantem que 
este modelo possui as propriedades requisita-
das (verificação);
• analisar se a solução proposta é aceitável do 
ponto de vista de desempenho, indicando quais 
as melhores estratégias para implementação a 
serem seguidas;
• validar o modelo através de simulações; 
• realizar o desenvolvimento do software poden-
do-se provar que a implementação está correta 
(geração de código correto). 
Dentre os vários métodos de especificação formal 
existentes, destacam-se o método Z, que já foi uti-
lizado em várias aplicações práticas, e o método de 
gramáticas de grafos, por possuir uma linguagem vi-
sual de representação e descrever com naturalidade 
fenômenos de sistemas concorrentes. 
De uma maneira mais abrangente, podemos ca-
racterizar assim o modelo de Métodos Formais:
• Permite especificar, desenvolver e verificar um 
software através de uma rigorosa notação ma-
temática. 
• Fornece um mecanismo para eliminar muitos 
problemas encontrados nos outros modelos, 
como por exemplo, ambiguidade, incomple-
tude e inconsistência, que podem ser desco-
bertos e corrigidos mais facilmente através de 
análise matemática. 
• Promete o desenvolvimento de software livre 
de defeitos. 
• Consome muito tempo de desenvolvimento e é 
muito caro. 
Como poucos desenvolvedores possuem o conhe-
cimento necessário para utilizá-lo, são requeridos 
muitos cursos e treinamentos. É difícil usar tais mo-
delos matemáticos formais como meio de comuni-
cação com a maioria dos clientes. Assim, como já 
dissemos, sua área de aplicação é muito restrita, 
abrangendo, principalmente, aplicações críticas.
Links Interessantes
Caro aluno,
Para mais informações sobre os Métodos Formais, 
consulte o link:
http://www.tiosam.org/enciclopedia/index.
asp?q=Métodos_formais
Para entender como funciona o controle de tráfego 
aéreo (projeto crítico), assista ao filme:
http://youtu.be/7wsrs3a-y3M
Processo Unificado
O Processo Unificado (PU) ou Unified Process