Engenharia de Software: Conceitos e Processos

Prévia do material em texto

2013
EngEnharia dE Software
Prof. Djone Kochanski
Copyright © UNIASSELVI 2013
Elaboração:
Prof. Djone Kochanski
Revisão, Diagramação e Produção:
Centro Universitário Leonardo da Vinci – UNIASSELVI
Ficha catalográfica elaborada na fonte pela Biblioteca Dante Alighieri 
UNIASSELVI – Indaial.
K766e
Kochanski, Djone
Engenharia de software / Djone Kochanski. Indaial : Uniasselvi, 2013.
 
172 p. : il
 
ISBN 978-85-7830-753-0
 1. Engenharia de software. I. Centro Universitário Leonardo da Vinci.
COD 005.102
Impresso por:
III
aprEsEntação
Caro(a) acadêmico(a)! Seja bem-vindo à disciplina de Engenharia de 
Software!
Você está iniciando os estudos de uma das disciplinas mais 
fascinantes da área de Computação/Informática. Ela é especial em função da 
amplitude de abrangência, quando software está em pauta. Nesta disciplina, 
você estudará importantes conceitos relacionados a aspectos técnicos da 
construção de software, bem como os aspectos gerenciais que envolvem o 
processo de software. 
O conteúdo deste Caderno de Estudos foi elaborado de forma a permitir 
uma visão adequada dos principais elementos relacionados à Engenharia de 
Software. Este conteúdo servirá como base para aprofundamentos nas demais 
subáreas deste campo de conhecimento. 
O campo da Engenharia de Software é bastante amplo, englobando, 
desde aspectos técnicos como arquitetura de software até métodos para gestão 
de pessoas em projetos. É uma importante área de conhecimento que poderá 
servir de fonte de informação para outras áreas, mesmo que não estejam 
relacionadas ao desenvolvimento de software.
Este Caderno de Estudos está dividido em três unidades. Iniciaremos 
nossos estudos a partir de uma perspectiva histórica da Engenharia de 
Software, complementando com importantes conceitos da área. Em seguida, 
estudaremos conceitos-chave relativos a Projetos de Software, uma das 
subáreas mais importantes da Engenharia de Software. Por fim, estudaremos 
importantes conceitos relativos à qualidade de software.
Desejo a você uma excelente experiência nos estudos dos conteúdos 
dessa disciplina!
Prof. Djone Kochanski
IV
Você já me conhece das outras disciplinas? Não? É calouro? Enfim, tanto 
para você que está chegando agora à UNIASSELVI quanto para você que já é veterano, há 
novidades em nosso material.
Na Educação a Distância, o livro impresso, entregue a todos os acadêmicos desde 2005, é 
o material base da disciplina. A partir de 2017, nossos livros estão de visual novo, com um 
formato mais prático, que cabe na bolsa e facilita a leitura. 
O conteúdo continua na íntegra, mas a estrutura interna foi aperfeiçoada com nova 
diagramação no texto, aproveitando ao máximo o espaço da página, o que também 
contribui para diminuir a extração de árvores para produção de folhas de papel, por exemplo.
Assim, a UNIASSELVI, preocupando-se com o impacto de nossas ações sobre o ambiente, 
apresenta também este livro no formato digital. Assim, você, acadêmico, tem a possibilidade 
de estudá-lo com versatilidade nas telas do celular, tablet ou computador. 
 
Eu mesmo, UNI, ganhei um novo layout, você me verá frequentemente e surgirei para 
apresentar dicas de vídeos e outras fontes de conhecimento que complementam o assunto 
em questão. 
Todos esses ajustes foram pensados a partir de relatos que recebemos nas pesquisas 
institucionais sobre os materiais impressos, para que você, nossa maior prioridade, possa 
continuar seus estudos com um material de qualidade.
Aproveito o momento para convidá-lo para um bate-papo sobre o Exame Nacional de 
Desempenho de Estudantes – ENADE. 
 
Bons estudos!
NOTA
V
VI
VII
UNIDADE 1 – PROCESSOS E REQUISITOS DE SOFTWARE ...................................................... 1
TÓPICO 1 – FUNDAMENTOS DE ENGENHARIA DE SOFTWARE ........................................... 3
1 INTRODUÇÃO ..................................................................................................................................... 3
2 PERSPECTIVA HISTÓRICA DA ENGENHARIA DE SOFTWARE ........................................... 4
3 ENGENHARIA DE SOFTWARE ........................................................................................................ 11
RESUMO DO TÓPICO 1........................................................................................................................ 17
AUTOATIVIDADE ................................................................................................................................. 18
TÓPICO 2 – PROCESSOS DE SOFTWARE ........................................................................................ 19
1 INTRODUÇÃO ..................................................................................................................................... 19
2 CICLOS DE VIDA DE SOFTWARE .................................................................................................. 22
3 MODELO CLÁSSICO .......................................................................................................................... 24
4 MODELO ESPIRAL ............................................................................................................................. 27
5 MODELO PROTOTIPAÇÃO ............................................................................................................. 29
6 MODELO RAD ..................................................................................................................................... 31
7 MODELO DE QUARTA GERAÇÃO ................................................................................................ 32
8 MODELO ALTERNATIVO ................................................................................................................. 35
RESUMO DO TÓPICO 2........................................................................................................................ 38
AUTOATIVIDADE ................................................................................................................................. 39
TÓPICO 3 – REQUISITOS DE SOFTWARE ....................................................................................... 41
1 INTRODUÇÃO ..................................................................................................................................... 41
2 REQUISITOS ......................................................................................................................................... 42
LEITURA COMPLEMENTAR ............................................................................................................... 52
RESUMO DO TÓPICO 3........................................................................................................................ 62
AUTOATIVIDADE ................................................................................................................................. 63
UNIDADE 2 – DESIGN E DESENVOLVIMENTO DE SOFTWARE ............................................. 65
TÓPICO 1 – DESIGN DE SOFTWARE ................................................................................................. 67
1 INTRODUÇÃO ..................................................................................................................................... 67
2 TIPOS DE DESIGN ............................................................................................................................... 68
3 ARQUITETURA DE SOFTWARE ...................................................................................................... 70
4 MODULARIDADE ............................................................................................................................... 72
5 DESIGN DE INTERFACES COM O USUÁRIO ............................................................................. 74
6 INDEPENDÊNCIA DOS COMPONENTES ................................................................................... 76
RESUMO DO TÓPICO 1........................................................................................................................78
AUTOATIVIDADE ................................................................................................................................. 79
TÓPICO 2 – DESENVOLVIMENTO DE SOFTWARE ...................................................................... 81
1 INTRODUÇÃO ..................................................................................................................................... 81
2 PADRÕES DE CODIFICAÇÃO ......................................................................................................... 81
3 NOTAÇÕES ........................................................................................................................................... 87
sumário
VIII
4 ESTILOS DE Indentação ..................................................................................................................... 89
RESUMO DO TÓPICO 2........................................................................................................................ 97
AUTOATIVIDADE ................................................................................................................................. 98
TÓPICO 3 – GERENCIAMENTO DE PROJETOS DE SOFTWARE .............................................. 99
1 INTRODUÇÃO ..................................................................................................................................... 99
2 ABRANGÊNCIA DO GERENCIAMENTO DE PROJETOS ........................................................ 100
3 DEFINIÇÃO DE PAPÉIS E RESPONSABILIDADES ................................................................... 103
4 FUNÇÕES E RESPONSABILIDADES ............................................................................................. 103
5 GESTÃO DE PESSOAS ....................................................................................................................... 105
LEITURA COMPLEMENTAR ............................................................................................................... 112
RESUMO DO TÓPICO 3........................................................................................................................ 117
AUTOATIVIDADE ................................................................................................................................. 118
UNIDADE 3 – QUALIDADE DE SOFTWARE ................................................................................... 119
TÓPICO 1 – INTRODUÇÃO À QUALIDADE DE SOFTWARE .................................................... 121
1 INTRODUÇÃO ..................................................................................................................................... 121
2 FUNDAMENTOS DE QUALIDADE DE SOFTWARE .................................................................. 122
3 MELHORIA DA QUALIDADE ......................................................................................................... 129
RESUMO DO TÓPICO 1........................................................................................................................ 137
AUTOATIVIDADE ................................................................................................................................. 138
TÓPICO 2 – MEDIÇÃO DE SOFTWARE ............................................................................................ 139
1 INTRODUÇÃO ..................................................................................................................................... 139
2 MODELO GQM .................................................................................................................................... 140
3 MODELO PSM ...................................................................................................................................... 159
LEITURA COMPLEMENTAR ............................................................................................................... 162
RESUMO DO TÓPICO 2........................................................................................................................ 165
AUTOATIVIDADE ................................................................................................................................. 166
REFERÊNCIAS ......................................................................................................................................... 167
1
UNIDADE 1
PROCESSOS E REQUISITOS DE 
SOFTWARE
OBJETIVOS DE APRENDIZAGEM
PLANO DE ESTUDOS
Esta unidade tem por objetivos:
• compreender os conceitos fundamentais da Engenharia de Software;
• entender a área de Engenharia de Software de maneira sistêmica;
• compreender os principais processos de software;
• conhecer a importância de requisitos de software.
Esta unidade está dividida em três tópicos, sendo que ao final de cada um 
deles, você encontrará atividades que lhe auxiliarão na apropriação de 
conhecimentos.
TÓPICO 1 – FUNDAMENTOS DE ENGENHARIA DE SOFTWARE
TÓPICO 2 – PROCESSOS DE SOFTWARE
TÓPICO 3 – REQUISITOS DE SOFTWARE
2
3
TÓPICO 1
UNIDADE 1
FUNDAMENTOS DE ENGENHARIA DE SOFTWARE
1 INTRODUÇÃO
Quando se fala em Engenharia de Software, logo se imagina que, por se 
tratar de uma engenharia, tenha um cunho técnico relativamente alto. Porém, 
embora as questões técnicas precisem ser consideradas, elas são apenas meios 
para atingir os objetivos. Para a Engenharia de Software o computador, a teoria da 
computação e até mesmo os algoritmos, são apenas ferramentas necessárias para 
prover a solução para um problema (PFLEEGER, 2004).
A Engenharia de Software tem como enfoque lidar com os aspectos de 
produção de software em todas as fases do seu ciclo de vida (SOMMERVILLE, 
2003). O ciclo de vida de um software inicia no momento em que são registradas 
as primeiras especificações de funcionamento, até o momento em que o software 
deixa de ser utilizado pelos seus usuários. Isso significa que tipicamente um 
software possui um ciclo de vida longo, se considerarmos o esforço necessário 
para a produção de um software.
Por outro lado, a Engenharia de Software pode ser vista como um framework 
para o planejamento, conceituação e projeto de software (PETERS; PEDRYCS, 
2001). Na abordagem de framework pode-se considerar o conjunto de aspectos 
construtivos, seus desafios e considerações sobre produzir tudo ou adquirir 
partes e fazer com que as mesmas funcionem de maneira harmoniosa.
Acrescentaria ainda a estas, a abordagem de gestão das pessoas que 
realizam os processos de software. A produção de software é altamente dependente 
de pessoas e seus talentos e habilidades, logo, também é tarefa da Engenharia de 
Software a gestão adequada desse importante componente. “A adição de recursos 
humanos a um projeto de software atrasado irá atrasá-lo ainda mais”. (BROOKS, 
2009, p. 24). Considerando que a afirmação de Brooks é verdadeira, incorporar 
novos elementos à equipe ou substituir componentes desta, pode comprometer 
severamente o resultado final de um projeto de software.
O fato é que, independente da abordagem que se utilize, a Engenharia de 
Software lida com desafios constantemente. Produzir algo que ninguém sabe o 
que e como será, de forma que não se pode demonstrar de maneira precisa. Isso 
é no mínimo um trabalho a ser respeitado.
UNIDADE 1 | PROCESSOS E REQUISITOS DE SOFTWARE
4
2 PERSPECTIVA HISTÓRICA DA ENGENHARIA DE SOFTWARE
Ao iniciarmos os estudos de uma nova área de conhecimento, uma das 
primeiras dúvidas que temos é sobre sua origem e evolução que a trouxe ser o que 
é nos dias atuais. Refletindo sobre a origem da área de Engenharia de Software, 
pode-se iniciar a partir de seu nascimento formal que ocorreu no início da década 
de 1970 ou buscarmos raízes mais profundas lá no século XIX.
Almeida (2002) nos ensina que em 1843, Lady Ada, uma condessa 
considerada gênio na área da matemática trabalhou com Charles Babbage no 
desenvolvimento da máquina analítica, tratando dos conceitos relacionados às 
instruções que deveriam ser executadas.Na época, este conjunto de instruções 
era conhecido como sub-rotina. Nascia então o conceito das instruções de 
sequência, seleção e repetição. Estes conceitos podem ser considerados as raízes 
mais profundas do que conhecemos atualmente por software.
FIGURA 1 – MÁQUINA ANALÍTICA DE CHARLES BABBAGE
FONTE: O autor
A máquina proposta do Babbage foi concebida em uma época que 
a tecnologia disponível era apenas dispositivos mecânicos. Por conta dessa 
limitação tecnológica não foi possível concluir o projeto que ficou inacabado. 
Independente disso, os conceitos de Babbage e Ada foi de grande valia para a 
evolução tecnológica para chegarmos ao estágio atual.
A partir destes conceitos fundamentais, foram construídos os alicerces do 
funcionamento dos softwares. A primeira aplicação de processamento de dados 
em grande escala foi realizada no final do século XIX. Na oportunidade foram 
tabulados os dados do censo americano de 1890 através de máquinas concebidas 
por Herman Hollerith. Nestas máquinas os dados eram representados sob a 
forma de perfurações devidamente posicionadas em fita de papel.
TÓPICO 1 | FUNDAMENTOS DE ENGENHARIA DE SOFTWARE
5
Neste momento da história não se diferenciava com clareza o que 
era hardware e o que era software, pois os equipamentos eram basicamente 
eletromecânicos. Na realidade o termo software foi criado apenas na década de 1940 
como forma de diferenciar a parte lógica da física de um sistema computacional.
FIGURA 2 – MÁQUINA TABULADORA DE HOLLERITH
FONTE: O autor
O terceiro grande marco fundamental para a área é plantado por Alan 
Turing no ano de 1937 ao propor um modelo de ações a serem realizadas por um 
tipo especial de máquina. “A Máquina Universal de Turing é capaz de calcular 
qualquer coisa que seja calculável”. (FOROUZAN; MOSHARRAF, 2011, p. 4). 
A partir daqui o software deixa de ser apenas um conceito e passa a 
ter utilidade em uma máquina que o executa de forma autônoma. É aí que os 
desafios enfrentados atualmente pela Engenharia de Software tem sua origem. 
Embora neste momento o conceito de Engenharia de Software estivesse longe de 
ser formalizado.
O momento da criação do conceito de máquina universal é muito especial 
para a área de computação/informática, pois é uma espécie de “big bang“ a partir 
do qual surge um grande ciclo evolutivo de tecnologia. Turing defendia a teoria 
de que “todo problema desde que expresso de maneira lógica apropriada, poderia 
sempre ser resolvido”. (STRATHERN, 2000, p. 53).
UNIDADE 1 | PROCESSOS E REQUISITOS DE SOFTWARE
6
FIGURA 3 – ALAN MATHISON TURING
FONTE: Disponível em: <www.computerhistory.org>. Acesso em: 
10 mar. 2012.
Seguindo a corrente de evolução, foram criados os computadores 
eletromecânicos e posteriormente os eletrônicos. Um dos mais conhecidos é o 
ENIAC (Eletronic Numeric Integrator and Calculator), criado pelos Professores John 
William Mauchly e John Pesper Eckert Jr. da Universidade da Pensilvânia. O 
ENIAC entrou em operação no ano de 1946 (ALMEIDA, 2002). Naquele momento 
da história, os computadores executavam instruções com base em painéis de 
chaveamento.
Em seguida passou-se a realizar codificação com instruções de máquina, 
até que surgem as linguagens de programação. Uma das primeiras linguagens 
de programação consideradas na época de alto nível foi criada por John Mauchly 
em 1949 e denominada de Short Order Code. Na década de 1950, as principais 
linguagens de programação em uso eram APT, FORTRAN e FLOW-MATIC.
Logo surgiu a necessidade de uma linguagem de programação simples 
e padronizada para aplicações comerciais. Cria-se então a partir da linguagem 
Flow-Matic de Grace Murray Hopper o COBOL (Common Business Oriented 
Language). Grace Hopper compôs a equipe que desenvolveu o COBOL e por sua 
contribuição à humanidade, merece nosso respeito e admiração.
As linguagens de programação permitiram o desenvolvimento de softwares 
cada vez mais sofisticados e com quantidade crescente de funcionalidades. À 
medida que a complexidade e quantidade de funcionalidades crescia, também 
era crescente o volume de problemas enfrentados com a qualidade do software 
que estava sendo produzido.
TÓPICO 1 | FUNDAMENTOS DE ENGENHARIA DE SOFTWARE
7
FIGURA 4 – GRACE MURRAY HOPPER
FONTE: Disponível em: <www.computerhistory.org>. Acesso em: 10 
mar. 2012.
A situação da indústria de software ao final da década de 1960 estava 
complicada. Os usuários e desenvolvedores enfrentavam diversos problemas 
relacionados ao processo de desenvolvimento. Estes problemas estavam 
intimamente ligados a como os softwares eram construídos, implantados e mantidos, 
bem como ao crescimento das demandas e problemas comportamentais. A esta 
situação denominou-se crise de software (MAFFEO, 1992). A crise de software é 
ocasionada por um conjunto de problemas que podem abranger (REZENDE, 
1997):
• como softwares são construídos;
• como softwares são implantados, sejam novos ou substituindo softwares 
anteriores;
• como softwares são mantidos, dada a crescente demanda e complexidade;
• como as necessidades e demandas dos usuários são atendidas;
• como as questões comportamentais, políticas, culturais e filosóficas são 
tratadas.
A crise de software é reconhecida no momento que uma aplicação de 
software não satisfaz as necessidades das pessoas para as quais foi projetado. Estas 
pessoas podem abranger não apenas os usuários do software, mas também todas 
as demais pessoas afetadas pelas consequências geradas pela não realização 
adequada da funcionalidade para a qual o software foi projetado. Alguns exemplos 
de afetados são os desenvolvedores do software, os usuários diretos e indiretos, os 
administradores de negócios, entre outros.
UNIDADE 1 | PROCESSOS E REQUISITOS DE SOFTWARE
8
Os principais fatores que levam à ocorrência da crise de software são 
aqueles diretamente relacionados à maneira como as aplicações de software 
são construídas, implantadas e mantidas. Além disso, a crise de software pode 
ocorrer quando as demandas de necessidades não são atendidas, seja por baixa 
produtividade, seja pela alta demanda de soluções de software para atender às 
necessidades de negócio. As questões comportamentais relacionadas ao processo 
de software também podem levar ao que se denomina crise de software.
Ao examinarmos algumas possíveis causas da crise de software podemos 
nos deparar com diversas. A cada dia que passa é crescente a necessidade de 
soluções de software mais eficientes. Além disso, a velocidade que os requisitos 
dos usuários mudam é tipicamente maior do que a equipe de desenvolvimento 
é capaz de atender. Pfleeger (2004, p. 111) nos ensina que “um requisito é uma 
característica do sistema ou a descrição de algo que o sistema é capaz de realizar, 
para atingir os seus objetivos”.
A velocidade de mudança nos requisitos, muitas vezes, vem de origens 
não controladas, como mudanças de legislação, normas ou processos aos quais as 
empresas estejam subordinadas. Neste caso podemos compreender que a crise de 
software pode ocorrer por fatores internos e teoricamente controláveis, bem como 
externos, ou seja, sobre os quais não exercemos qualquer controle.
É possível ainda que a complexidade da mudança imposta seja alta, 
requerendo maior tempo para sua realização. Muitos projetos de software nascem 
com prazos definidos antes mesmo de se ter os principais requisitos levantados. 
Isto definitivamente é algo que pode comprometer significativamente o processo 
de desenvolvimento. Um projeto de software iniciado com requisitos incompletos 
fatalmente terá um design deficitário.
Caro acadêmico! Neste Caderno de Estudos, o termo design é utilizado para 
designar a fase do ciclo de vida de software em que é realizada a definição de como o produto 
(software) será construído do ponto de vista técnico (arquitetura, dados e procedimentos). 
Esta fase também é tipicamente chamada de projeto (tradução do termo em inglês), porém 
na Engenharia de Software também utilizamos o termo projetopara denominar o processo 
de gestão de todas as atividades que envolvem o desenvolvimento do produto. Então, 
quando falarmos em design estaremos nos referindo à fase do ciclo de vida de software e 
quando falarmos em projeto estaremos nos referindo ao processo de gestão da construção 
do produto.
UNI
TÓPICO 1 | FUNDAMENTOS DE ENGENHARIA DE SOFTWARE
9
Para agravar ainda mais o cenário, a inexistência de métricas adequadas 
para obtenção de medidas de software antes de seu desenvolvimento, é a gota 
d’água final ou a “pá de cal” sobre a equipe de desenvolvimento. As métricas 
de software são um capítulo a parte nessa discussão, pois a questão é bem mais 
complexa do que se possa imaginar. Voltaremos ao assunto mais tarde.
O que pode ser observado em parcela significativa de equipes de 
desenvolvimento de software é a adoção de práticas absurdamente obsoletas. Aliado 
a estas práticas, tipicamente se encontra uma grande desigualdade na distribuição 
do tempo dedicado às fases do ciclo de vida de software. É muito comum reduzir 
requisitos em função da falta de tempo ou eliminar atividades do processo de 
desenvolvimento com o objetivo de reduzir o tempo total do processo.
As atividades que tipicamente são mais sacrificadas são a análise, design e 
testes. Um agravante é a inexistência da definição de um padrão de processo a ser 
seguido. Padrões desenvolvidos e publicados não faltam, porém a adoção destes 
é que não se observa em muitas equipes de desenvolvimento. A inexistência de 
padrão de processo de software multiplica a dificuldade de realizar manutenção.
Muitos ainda subestimam a atividade de desenvolvimento de software, 
acreditando ser simples e fácil iniciar um software sem a definição de uma estrutura 
e arquitetura adequadas e evoluir este software até ele se tornar um produto com 
um conjunto significativo de funcionalidades. Desenvolver software não é uma 
atividade simples, logo, requisitos, arquitetura e estruturas de programas e 
dados não podem ser colocadas em segundo plano. Se as bases do novo software 
desenvolvido não forem sólidas, todo o restante do software desenvolvido será 
igualmente frágil.
Encontra-se também a ausência de valorização da fase de análise, 
na qual os requisitos são obtidos e especificados. Muitos dos softwares que há 
em uso mundo afora não precisariam existir se as necessidades tivessem sido 
devidamente entendidas e o processo de trabalho adequadamente analisado e 
modelado. Muitas vezes implementamos softwares para solucionarmos problemas 
que sequer existem.
Caro acadêmico! Neste Caderno de Estudos nos referiremos às pessoas 
que atuam no desenvolvimento de software como profissionais de software. Esta forma 
foi escolhida pelo fato de que no Brasil chamamos de engenheiros de software apenas 
profissionais formados em cursos de graduação em Engenharia de Software. Se você 
aprofundar seus conhecimentos com literaturas clássicas da área provavelmente encontrará 
o termos “engenheiro de software” sendo largamente utilizado. Isto se dá em função do 
profissional de software ser chamado de “Software Engineer” nos EUA, de onde vem boa 
parte das grandes contribuições científicas da área.
UNI
UNIDADE 1 | PROCESSOS E REQUISITOS DE SOFTWARE
10
Além destes fatores podemos encontrar também um abismo de 
concordância entre os pesquisadores da área de Engenharia de Software e os 
profissionais que estão diariamente envolvidos com o processo de software. 
Pesquisadores acreditam que os profissionais não dão importância para o 
conteúdo de suas pesquisas e os profissionais acreditam que os resultados de 
pesquisas não podem ser aplicados à suas realidades. 
Quanto maior for o abismo entre as teorias de pesquisadores e os 
profissionais de software, maiores serão as dificuldades enfrentadas e maior 
será a crise resultante. É importante que profissionais de software empreendam 
iniciativas de adoção de modelos formais. 
Para o sucesso nesta adoção é recomendado que esta seja feita de maneira 
evolutiva e controlada. Apenas após comprovados os resultados com a adoção de 
uma parcela do processo é que se deveria seguir com novas iniciativas.
Devido à natureza intangível do software, há a tendência de entendimento 
de que só há algo realizado se houver código construído. Isso de fato pode ser 
uma verdade em algumas metodologias, porém não se pode ignorar que, por 
exemplo, casos de uso, diagramas de classes, diagramas E-R etc., também são 
artefatos valiosos e representam entregas do processo.
Ao ler este conteúdo em seu Caderno de Estudos, uma das perguntas que 
pode lhe ocorrer é: Com toda evolução tecnológica ocorrida desde a década de 
1970, será que ainda enfrentamos estes problemas? A resposta é sim. Na verdade, 
atualmente estamos enfrentando uma crise ainda maior, pois a natureza dos 
problemas com os quais lidamos também evoluiu e a complexidade dos processos 
cresceu.
Com o crescimento da complexidade dos problemas de negócio a 
serem resolvidos, cresceu também a necessidade de crescimento da equipe de 
desenvolvimento. O crescimento da equipe de desenvolvimento adiciona força 
de trabalho, porém traz desafios gerenciais. A partir daí começa a entrar em cena 
a importância dos aspectos gerenciais da Engenharia de Software. O maior clássico 
sobre este assunto “O Mítico Homem-Mês” está na leitura complementar desta 
unidade. Não deixe de ler!
TÓPICO 1 | FUNDAMENTOS DE ENGENHARIA DE SOFTWARE
11
FIGURA 5 – LIVRO: O MÍTICO HOMEM-MÊS
FONTE: O autor
O livro O Mítico Homem-Mês rendeu a Frederick Books Jr. diversas premiações, 
dentre elas a Medalha Nacional de Tecnologia americana no ano de 1985 e o Turing Award no 
ano de 1999. O Turing Award é uma honraria concedida anualmente pela ACM (Association 
for Computing Machinery) para uma pessoa que tenha realizado contribuições significativas 
à área da computação. Este prêmio é conhecido como “Prêmio Nobel da Computação” e 
leva o nome de Turing pelas contribuições de Alan Turing para a ciência da computação 
moderna.
UNI
Embora tenham se passado várias décadas desde que a existência de 
uma crise de software tenha sido reconhecida, ainda hoje enfrentamos muitos dos 
problemas identificados lá no final da década de 1960. Ainda hoje enfrentamos 
problemas no processo de análise, no processo de construção, na forma como 
o software é implantado e mantido e nas consequências geradas aos usuários 
finais. As atuais exigências de disponibilidade de funções executadas por software 
requerem que os profissionais de software melhorem continuamente os processos 
de Engenharia de Software. Mas afinal o que é Engenharia de Software? Vejamos 
em detalhes no tópico a seguir.
3 ENGENHARIA DE SOFTWARE
No final da década de 1960 nasceu o termo Engenharia de Software. Fritz 
Bauer (Friedrich Ludwig Bauer) foi quem definiu em 1968 o termo pela primeira 
vez como sendo “o estabelecimento e uso de sólidos princípios de engenharia 
para que se possa obter economicamente um software que seja confiável e que 
funcione eficientemente em máquinas reais” (PRESSMAN, 1995).
http://pt.wikipedia.org/wiki/Computa%C3%A7%C3%A3o
http://pt.wikipedia.org/wiki/Pr%C3%AAmio_Nobel
UNIDADE 1 | PROCESSOS E REQUISITOS DE SOFTWARE
12
A definição de Bauer de fato abrange o que pode ser reconhecido como 
importante no que conhecemos por Engenharia de Software. Por sólidos princípios 
de engenharia podemos entender os processos necessários para a construção de 
software de forma adequada. O software deve ser confiável e também funcionar de 
maneira eficiente em nossos equipamentos.
FIGURA 6 – FRIEDRICH LUDWIG BAUER
FONTE: Disponível em: <www.computerhope.com>. Acesso em: 
10 mar. 2013.
O objetivo da Engenharia de Software é prover soluções de software aplicáveis 
às necessidades para as quais foi concebido, construídos de forma produtiva e 
entregando alto grau de qualidade. O engenheiro de software ao aplicar de forma 
adequada os métodos, ferramentas e procedimentos da Engenharia de Software 
torna-se um criador de soluçõesque atendam as necessidades do mundo real.
No início da década de 1990 se apregoava que no futuro próximo seria tão 
simples desenvolver software que programadores não seriam mais necessários. 
Diante disso, muitos estudantes da área e profissionais passaram por momentos 
de preocupação em relação a seus futuros. Alguns visionários acreditavam 
que em breve as ferramentas de desenvolvimento seriam tão sofisticadas a 
ponto de qualquer usuário poder definir sua aplicação sem a necessidade de 
programadores.
Felizmente as previsões não se confirmaram e programadores são cada 
vez mais importantes e valorizados. Porém, se considerarmos que o processo 
de software tem forte dependência de material humano poderíamos caracterizá-
lo como artesanal. Certo? Certíssimo! Por mais que tenhamos ferramentas 
modernas para auxiliar o processo de software, o elemento humano ainda é e 
deverá continuar sendo o principal pilar do processo.
TÓPICO 1 | FUNDAMENTOS DE ENGENHARIA DE SOFTWARE
13
Porém o fato do processo de software ainda poder ser caracterizado 
como um processo artesanal não significa que ele não possa ou não deva seguir 
processos formalizados. Na realidade, é justamente por este motivo que se faz 
tão importante a adoção de melhores métodos e formalização de procedimentos.
Diante desse contexto, a Engenharia de Software é uma área que ganha 
importância a cada dia, pois a dependência humana de softwares é cada vez maior. 
Atualmente uma parcela significativa da população utiliza software com um grau 
relevante de dependência. Dependemos de softwares para nos comunicarmos, 
nos informarmos, fazermos operações bancárias, fazermos compras num 
supermercado etc. 
Nos escritórios de empresas e instituições são utilizados editores de 
textos, planilhas, softwares de apresentação, entre outros diversos softwares e 
sistemas computacionais. Nossas contas do dia a dia são controladas por sistemas 
computacionais e sem os mesmos nossa realidade seria muito diferente, pois 
estaríamos bastante limitados em relação às possibilidades atuais.
Os processos precisam ser cada vez mais eficientes e ágeis para que as 
empresas possam se manter competitivas, gerar empregos e renda para os 
colaboradores. Toda essa realidade seria significativamente diferente sem a 
existência de softwares como temos atualmente. Porém, toda essa dependência 
pode aumentar também as consequências do funcionamento inadequado destes 
softwares.
Os softwares utilizados diariamente precisam estar livres de falhas. Dado o 
grau de dependência que indistintamente temos dos softwares que utilizamos no 
dia a dia. Quaisquer falhas que venham a ocorrer podem ter sérias consequências. 
Os softwares devem estar disponíveis aos usuários e executar suas funcionalidades 
de acordo com as regras de negócios, além de atender à legislação.
Para Sommerville (2003) a Engenharia de Software está focada em todos os 
aspectos relacionados à construção de software. É uma disciplina de engenharia 
cujo objetivo é tratar das questões ligadas ao processo de software. A abrangência 
é bastante ampla, iniciando muito antes de haver uma especificação de software, 
indo até o último momento de utilização do referido software. Na verdade 
estamos utilizando o software como elemento base, mas a Engenharia de Software 
abrange também todos os artefatos relacionados ao processo de software, como 
documentação, gestão e muitos outros.
Contribuindo na explicação do que é Engenharia de Software, Pfleeger 
(2004) argumenta que software abrange muito mais nosso mundo que efetivamente 
imaginamos, tornando nossas vidas mais confortáveis, eficientes e efetivas. Há 
aplicações de software sendo utilizadas nas mais diversas situações do cotidiano 
que nos afetam direta ou indiretamente. Por este motivo, é crescente a importância 
da existência de softwares que atendam às necessidades para as quais eles foram 
UNIDADE 1 | PROCESSOS E REQUISITOS DE SOFTWARE
14
projetados e construídos. A abordagem que se pretende dar é a de que “as boas 
práticas de engenharia de software devem assegurar que o software tenha uma 
contribuição positiva em nossas vidas”. (PFLEEGER, 2004, p. 1).
De forma mais objetiva, a mensagem que Pfleeger (2004) pretende passar 
é que a Engenharia de Software é um meio para solucionar problemas de forma 
adequada. Isso pode implicar inclusive a decisão de que eventualmente a melhor 
solução seja não implementar um software para realização da atividade em questão. 
Devemos empregar as ferramentas, técnicas e procedimentos da Engenharia de 
Software para a solução de problemas e/ou necessidades.
Quando nos referimos à Engenharia de Software há a tendência de se 
pensar apenas nos aspectos tecnológicos, porém é importante observar que 
compreende também aspectos gerenciais. Na realidade, se considerarmos o 
aspecto que representa os maiores desafios, decididamente os aspectos gerenciais 
são os que mais consomem energias dos profissionais de software.
Em relação à questão gerencial Maffeo (1992) argumenta sabiamente que 
o elemento básico do processo de desenvolvimento de software são as pessoas. 
Diante da evolução tecnológica que vivemos, reconhecer que os seres humanos 
são o elemento chave para o sucesso pode causar um choque de paradigmas para 
muitas pessoas. Porém, de fato o elemento humano é fundamental no processo 
de construção de softwares. E efetivamente isso se comprova cada vez mais nas 
equipes de desenvolvimento mundo afora.
Embora tenhamos disponíveis diversas ferramentas sofisticadas para 
apoiar o processo de software a Engenharia de Software ainda tem forte dependência 
do fator humano. O desenvolvimento de software pode ser considerado como 
uma forma sistemática de fazer arte. E o que confere beleza a esta arte é quanto 
ela auxilia na solução de problemas impostos.
Pelo fato do processo de software ter forte dependência do fator humano, 
a Engenharia de Software lida também com a questão da produtividade. As 
questões de produtividade envolvem medição de software, estimativas de esforço, 
definição de indicadores, desenvolvimento de cronograma, coleta de dados de 
produtividade, análise dos dados de produtividade, entre outras atividades. 
O processo requer planejamento, organização, controle, além dos aspectos de 
motivação e liderança.
Toda a preocupação com a melhoria dos processos de Engenharia de 
Software tem como finalidade a produção e entrega de software de qualidade. 
E qualidade é algo que merece especial atenção. O assunto será devidamente 
abordado na Unidade III deste Caderno de Estudos.
Pressman (1995) categoriza os elementos fundamentais da Engenharia de 
Software em três: métodos, ferramentas e procedimentos. Os métodos podem ser 
entendidos como os roteiros a serem seguidos para realização de determinada 
TÓPICO 1 | FUNDAMENTOS DE ENGENHARIA DE SOFTWARE
15
atividade. Exemplos são as atividades de planejamento, realização de estimativas, 
design de sistemas, definição de arquitetura de software, técnicas de programação, 
formas de realização de testes e manutenção de softwares, entre outros.
As ferramentas podem ser entendidas como o meio para realização das 
atividades. Elas servem de apoio aos métodos, permitindo que as atividades 
sejam desenvolvidas de forma mais eficiente e eficaz. Exemplos de ferramentas 
são as linguagens de programação, bancos de dados, softwares de modelagem de 
dados, softwares para modelagem de projetos, entre outros.
Os procedimentos podem ser entendidos como as ações realizadas, 
ou seja, a aplicação dos métodos e das ferramentas. Os procedimentos são as 
atividades detalhadas que são executadas para realização, por exemplo, de um 
método de planejamento apoiado por uma ferramenta de cronograma. Do ponto 
de vista técnico, a utilização adequada destes três elementos fundamentais é que 
nos permitirão obtenção de melhores resultados em processos de Engenharia de 
Software.
Em relação às ferramentas, houve um grande salto evolutivo a partir da 
década de 1990. Porvolta dessa época surgiram ferramentas de requisitos, de 
modelagem, de design, de testes e principalmente de programação. E a partir 
da metade da décade de 1990 iniciou-se de maneira mais intensa a corrida 
para o paradigma de orientação a objetos. Nos primeiros anos desse período a 
opinião dos desenvolvedores ainda estava dividida entre permanecer no modelo 
estruturado ou migrar para a orientação a objetos.
Neste período de transição o que se viu foram muitos softwares sendo 
construídos em linguagens orientadas a objetos com porções significativas 
de código idêntico ao escrito no paradigma estruturado. A migração para a 
orientação a objetos não foi tão suave e simples quanto poderia ter sido. A partir 
do início dos anos 2000 é que a orientação a objetos começou a ser utilizada de 
forma mais intensa. É certo que ainda hoje há softwares utilizando linguagens 
baseadas ou orientadas a objetos com códigos estruturados. Porém atualmente 
poucos questionam a orientação a objetos como principal paradigma.
Algo muito semelhante ocorreu com iniciativas de adotação de bancos 
de dados orientados a objetos. Houve um vai e vem de paradigmas. A principal 
causa dessas situações está relacionada à falta de uma análise prévia criteriosa 
em relação à aderência do modelo à realidade de negócio para a qual o software 
deverá ser desenvolvido. 
Da mesma forma como linguagens estruturadas não foram criadas para 
desenvolver quaisquer aplicações, as orientadas a objetos não o foram. Não seria 
a falta de aderência entre negócio e tecnologia uma das causas dos baixos níveis 
de qualidade de alguns softwares? Fica a questão para reflexão.
UNIDADE 1 | PROCESSOS E REQUISITOS DE SOFTWARE
16
Em relação à Engenharia de Software, Sommerville (2003) destaca alguns 
pontos-chave:
• a Engenharia de Software é uma disciplina da engenharia que se ocupa de todos 
os aspectos da produção de software;
• os produtos de software consistem de programas desenvolvidos e da 
documentação associada. Os atributos essenciais dos produtos são a facilidade 
de manutenção, a confiança, a eficiência e a facilidade de uso;
• o processo de software consiste em atividades envolvidas no desenvolvimento 
de produtos de software. As atividades básicas são a especificação, o 
desenvolvimento, a validação e a evolução do software;
• métodos são os meios organizados de produzir software. Eles incluem sugestões 
sobre o processo a ser seguido, as notações a serem utilizadas, as regras que 
regem as descrições de sistema produzidas e as diretrizes do projeto;
• as ferramentas CASE são sistemas de software projetados para dar apoio às 
atividades de rotina no processo de software, tais como editar diagramas de 
projeto, verificar a consistência de diagramas e manter o controle dos testes de 
programa que são realizados;
• os engenheiros de software têm responsabilidades para com a engenharia como 
profissão e a sociedade. Eles não devem se preocupar exclusivamente com 
questões técnicas.
17
Caro(a) acadêmico(a)! Nesse tópico, você estudou que:
• A Engenharia de Software é uma área que passou a ser formalizada a partir 
do início da década de 1970. Até este momento, as ferramentas, métodos e 
procedimentos utilizados não estavam formalmente subordinados a uma área 
específica. Cada desenvolvedor utilizava as ferramentas mais úteis aos seus 
processos de trabalho.
• A Engenharia de Software surgiu a partir da necessidade de formalização e 
aperfeiçoamento dos métodos de construção de software. A principal motivação 
foram as consequências geradas a partir de processos de software inadequados. 
Esta consequência foi denominada de crise de software entre o final da década 
de 1960 e início da década de 1970.
• A partir do momento em que a Engenharia de Software passou a ser reconhecida 
como uma subárea da Computação/Informática diversos pesquisadores 
desenvolveram métodos e técnicas para aperfeiçoar as práticas diárias 
no processo de desenvolvimento de software. Tais subsídios permitiram 
compartilhamento de experiências e métodos para melhorar a qualidade do 
software produzido.
• A Engenharia de Software veio para auxiliar os profissionais de software nas 
dificuldades encontradas no processo de produção de soluções de software 
para atender à crescente necessidade de soluções. Isso tudo sem deixar de 
considerar os aspectos técnicos e aspectos gerenciais.
• A produção de software é uma atividade que depende fortemente da habilidade 
humana. Diante disso, o fator humano é um importante quesito a ser 
considerado e gerenciado. Tais características consideram a necessidade de 
desenvolvimento de habilidades interpessoais, trabalho em equipe, motivação, 
liderança, entre outros.
RESUMO DO TÓPICO 1
18
Caro(a) acadêmico(a)! Como forma de fixar o conteúdo estudado realize 
a autoatividade proposta a seguir:
1 Aponte dois problemas que podem levar à crise de software.
2 Quando podemos reconhecer que há uma crise de software?
3 Quais são as atividade do desenvolvimento de software que são tipicamente 
mais sacrificadas?
4 Quais são os elementos fundamentais da Engenharia de Software?
AUTOATIVIDADE
19
TÓPICO 2
PROCESSOS DE SOFTWARE
UNIDADE 1
1 INTRODUÇÃO
Numa atividade de engenharia é necessário que se defina o método de 
construção que será adotado. No momento em que se decide construir um software 
para atender a uma necessidade de negócio ou entregar alguma ferramenta, 
recurso ou opção de entretenimento é importante que se decida qual o processo 
que será seguido.
A criação de um software é uma atividade intelectual de alto nível de 
complexidade. E é justamente por se tratar de uma atividade complexa que é 
fundamental que se saiba quais são as etapas que comporão tal processo. A adoção 
de processos bem definidos melhora a visibilidade da construção de software.
Aparentemente todo e qualquer software pode ser construído sem que 
um roteiro pré-definido seja seguido. Isso pode ser verdade se você estiver 
desenvolvendo um software por interesse pessoal nas horas vagas e para passar 
o tempo (hobby). Neste caso o seu compromisso está tipicamente limitado à sua 
satisfação em construir o software.
No desenvolvimento de software por hobby a necessidade de refazer uma 
parte do trabalho pode representar apenas mais algumas horas dedicadas a um 
feito que lhe proporcionará satisfação. Já no desenvolvimento profissional de 
software o cenário pode ser radicalmente diferente. Até mesmo o desenvolvimento 
de uma PoC (Proof of Concept – Prova de Conceito) que requeira muito retrabalho 
poderá se tornar algo bastante indesejado.
No desenvolvimento profissional de software é altamente desejável que 
se siga um processo que reduza, dentro do possível, o desperdício de tempo 
e maximize os resultados obtidos. Os resultados esperados são tipicamente 
funcionalidades de software com alta qualidade.
Dada à importância do processo de desenvolvimento de software é 
imperativo que se estabeleça e siga um modelo que possibilite obter software de 
alta qualidade. Deverá haver equilíbrio entre otimização do tempo e realização 
das etapas críticas do processo. O segredo do universo está no equilíbrio. 
Em relação ao processo de desenvolvimento de software, Brooks (2009) 
sugere que se explorem as opções existentes no mercado para evitar construir 
algo que pode ser comprado. Ele indica a utilização de prototipação para o 
UNIDADE 1 | PROCESSOS E REQUISITOS DE SOFTWARE
20
estabelecimento de requisitos de software. Crescer os softwares organicamente 
através da adição de funções à medida que são executados, usados e testados. 
Identificar e desenvolver os grandes profissionais da geração em ascensão.
Todo produto de software é construído com base em um modelo de 
processo, também conhecido como paradigma de desenvolvimento ou ainda 
ciclo de vida. Um ciclo de vida de software compreende um conjunto de etapas 
envolvendo métodos, ferramentas e procedimentos para a obtenção do produto 
de software desejado (PRESSMAN, 1995).O ciclo de vida de software é um processo de engenharia que notadamente 
requer que algumas etapas sejam seguidas em determinada ordem para que se 
possa obter um produto final com o grau de qualidade desejado. De acordo com 
Pfleeger (2004, p. 36), todo processo tem as seguintes características:
• o processo prescreve todas as principais atividades;
• o processo gera produtos intermediários e finais, com base nos recursos e 
restrições existentes;
• o processo pode ser composto por uma hierarquia de processos onde cada 
subprocesso possa ter seu modelo;
• cada atividade do processo possui critérios de entrada e saída, permitindo 
saber quando ele começa e quando termina;
• as atividades são organizadas sequencialmente, de forma que a ordem entre as 
atividades seja clara;
• todo processo possui um conjunto de diretrizes que ajudam a explicar os 
objetivos de cada atividade.
Não é necessário seguir na íntegra um modelo de ciclo de vida proposto 
por algum pesquisador da área de Engenharia de Software. O ciclo de vida 
adotado pode ser adaptado de algum modelo anteriormente proposto por algum 
pesquisador ou totalmente personalizado de acordo com as necessidades e 
realidade da equipe e natureza do software a ser desenvolvido. Um ciclo de vida 
de software também pode ser construído através de melhores práticas de diversos 
modelos amplamente conhecidos.
De uma forma geral, qualquer processo de software ou ciclo de vida possui 
três fases que são comuns a qualquer abordagem adotada. Pfleeger (2004) diz que 
estas três fases são definição, desenvolvimento e manutenção. 
De fato não há como desenvolvermos algo sem que seja definido, mesmo 
que superficialmente. O desenvolvimento é o processo principal, pois é o momento 
em que os artefatos são produzidos. Já a manutenção é a fase de maior duração 
dentro do ciclo de vida de um software, pois tipicamente ocorre até próximo de 
sua desativação.
A fase de definição está focada em descrever o que o software deverá 
fazer (PRESSMAN, 1995). É nesta fase que são definidos os requisitos funcionais 
TÓPICO 2 | PROCESSOS DE SOFTWARE
21
e não funcionais. Os requisitos funcionais estão relacionados à descrição das 
funcionalidades que o software deverá atender. Já os requisitos não funcionais 
estão relacionados aos recursos tecnológicos que deverão ser atendidos.
Para facilitar o entendimento dos requisitos não funcionais vejamos 
alguns exemplos: um requisito não funcional pode ser a necessidade de utilizar 
o software em ambiente local, em rede local e/ou numa rede de longa distância, se 
o software deverá ser utilizado em diferentes Sistemas Operacionais, se o software 
deverá utilizar determinado banco de dados, entre outros requisitos que não 
estejam relacionados às regras de negócio que deverão ser atendidas.
Na fase de desenvolvimento ocorre a definição de como o software 
deverá ser desenvolvido (PRESSMAN, 1995). A fase de desenvolvimento pode 
compreender diversas subfases, dentre as quais as mais comuns são definição 
das estruturas de dados, modelagem de banco de dados, arquitetura, design, 
programação e testes. Boa parte dos ciclos de desenvolvimento utiliza algumas 
destas subfases como fases, conforme a importância no processo.
Na fase de manutenção são realizadas as mudanças necessárias no 
software (PRESSMAN, 1995). Estas mudanças podem ser exigidas por diversos 
motivos que podem ser categorizadas como corretivas, adaptativas, perfectivas e 
evolutivas (SWEBOK, 2004). 
As manutenções corretivas tipicamente reativas e visam eliminar falhas 
ou erros encontrados após a entrega do software para utilização. Este tipo de 
manutenção é pouco desejada e deve representar um pequeno percentual do 
esforço da equipe de desenvolvimento. 
As manutenções adaptativas são menos comuns de ocorrer. Elas visam, 
por exemplo, a mudança ou atualização de plataforma tecnológica. Ela também 
pode ser realizada para manter o software em uso num ambiente diferente ou num 
ambiente em mudança. Este tipo de manutenção também não é desejável, pois 
pode representar grande volume de esforço para sua realização.
As atividades realizadas para tornar o software mais performático 
ou melhorar sua estrutura de construção de forma a facilitar o processo de 
manutenção é definido como manutenção perfectiva. Este tipo de manutenção 
pode ser necessário nas primeiras vesões do software para aperfeiçoamento no 
desempenho de determinadas rotinas. Também pode ocorrer no momento que se 
identifica a necessidade de reescrever partes do código para deixa-lo melhor para 
realizar manutenções.
Já as manutenções evolutivas visam promover melhorias em requisitos 
funcionais e/ou não funcionais. A manutenção evolutiva é realizada para evitar 
que determinadas falhas, tipicamente de especificação, se tornem falhas efetivas, 
corrigindo-as antecipadamente. Esta manutenção deve entregar funcionalidades 
de alto valor para o negócio.
UNIDADE 1 | PROCESSOS E REQUISITOS DE SOFTWARE
22
A fase de manutenção pode ser vista sob duas óticas: nobre e não nobre. A 
manutenção é considerada nobre quando as alterações que estão sendo realizadas 
são motivadas por alterações nos requisitos ou necessidades dos usuários. Ela é 
considerada não nobre quando alterações precisam ser promovidas para corrigir 
falhas, tipicamente conhecidas como bugs.
Uma das grandes dúvidas que surge em relação aos tipos de manutenção 
é a distribuição ideal de esforço em cada uma delas. Esta distribuição pode variar 
com base em diversos fatores técnicos e ambientais. Porém uma distribuição 
desejável é 20% do esforço dedicado a manutenções corretivas, adaptativas 
e perfectivas e 80% em manutenções evolutivas. Destes 80% de manutenção 
evolutiva, seria interessante dedicar 30% para projetos de inovação e 50% com 
inclusão, alteração e exclusão de funcionalidades.
É certo que esta não é uma meta facilmente atingível, porém serve 
como indicador e norteador a ser observado e perseguido. Podemos comparar 
grosseiramente à qualidade total, que é uma meta ousada e que requer constante 
esforço e trabalho em melhoria contínua para aproximação à mesma.
2 CICLOS DE VIDA DE SOFTWARE
Existem diversos modelos de processo de software propostos. Alguns 
apresentam superficialmente a concepção do modelo e outros detalham 
exaustivamente as fases e subfases do processo. É importante que cada equipe de 
desenvolvimento se inspire no modelo de processo que esteja mais aderente à sua 
realidade, customize e promova melhorias contínuas neste modelo. Pfleeger (2004) 
apresenta algumas razões para a realização dessa modelagem de processo:
• melhora o entendimento do processo para a equipe de desenvolvimento;
• permite a melhoria do processo pela equipe envolvida;
• o modelo reflete os objetivos do desenvolvimento de software;
• proporciona visibilidade sobre necessidades de adequação em função da 
natureza do projeto.
Pfleeger (2004, p. 38) descreve ainda que “todo processo de desenvolvimento 
de software tem como entrada os requisitos do sistema e como saída um produto 
fornecido”.
Todo software possui um ciclo de vida através do qual ele é ou será 
construído, logo, compreender os aspectos dos principais modelos de ciclo de 
vida pode auxiliar na adoção de um dos modelos. Também servirá de importante 
embasamento teórico para a construção de um ciclo de vida mais adequado à 
realidade e necessidade da organização. Os ciclos de vida de software podem ser 
categorizados como, linear, incremental ou iterativo. 
TÓPICO 2 | PROCESSOS DE SOFTWARE
23
2 CICLOS DE VIDA DE SOFTWARE
No modelo linear, o software será entregue com todas suas funcionalidades 
em apenas uma fase. Este ciclo de vida é mais simples de entender, pois segue o 
fluxo natural do desenvolvimento de qualquer outro tipo de produto. Este ciclo 
de vida entra na fase de manutenção quando todas as funcionalidades definidas 
estiverem concluídas e entregues.
Foi a primeira categoria de ciclos de vida descrita de maneira formal, 
justamente pelofato de seguir um fluxo mais natural e compreensível. Ele pode 
ser adotado na construção de qualquer software, porém vem sendo cada vez 
menos utilizado pelo fato do tempo de entrega ser tipicamente longo.
No modelo incremental uma versão básica é disponibilizada ao final 
do primeiro ciclo e nos ciclos seguintes novas funcionalidades são agregadas 
até que se tenha o produto completo. Este modelo pode ser utilizado de forma 
independente ou em conjunto com o iterativo.
Já no modelo iterativo uma versão básica de boa parte das funcionalidades é 
disponibilizada no primeiro ciclo e funções mais aperfeiçoadas são disponibilizadas 
em ciclos posteriores. A cada ciclo são realizados aperfeiçoamentos nas 
funcionalidades até que todas as funcionalidades estejam completas.
Para cada uma destas categorias de ciclos de vida de software há um ou 
mais modelos formais disponíveis para adoção. Entre os modelos de ciclo de vida 
de software mais conhecidos está o clássico, também conhecido como modelo 
cascata (waterfall), espiral e prototipação. Além deste, há os modelos RAD, 
modelo de quarta geração ou técnicas de quarta geração, modelo em V, modelo 
transformacional, modelo evolucionário, entre outros.
Independente do ciclo de vida que seja adotado é muito importante que 
se tenha clareza do que deve ser realizado em cada fase do referido ciclo de vida. 
Por exemplo, na fase de análise é realizada a determinação do que o software 
deverá fazer. E na fase de design é realizada a determinação de como o software 
será construído. 
UNIDADE 1 | PROCESSOS E REQUISITOS DE SOFTWARE
24
FIGURA 7 – INFLUÊNCIA DE CADA FASE DO CICLO DE VIDA NOS CUSTOS DO SOFTWARE
FONTE: O autor
Cada fase de um ciclo de vida de software tem sua finalidade e importância, 
logo, tratar determinada fase sem a devida atenção pode ser nocivo à saúde do 
software que será construído. O resultado típico que se observa é software com 
baixa qualidade.
A falta de valorização das fases de análise e design tipicamente geram sérias 
consequências no processo de manutenção. Não é incomum vermos softwares 
entrando em manutenção antes mesmo de serem concluídos. Se analisarmos 
a distribuição de tempo investido em cada fase do ciclo de vida poderemos 
observar que a manutenção é a mais longa e tipicamente a que mais consome 
recursos (humanos e financeiros).
3 MODELO CLÁSSICO
O ciclo de vida clássico, também muito conhecido como modelo cascata 
(waterfall), é uma abordagem sequencial sistemática do desenvolvimento de 
software. Este ciclo de vida foi modelado com base no ciclo da engenharia 
convencional (PRESSMAN, 1995). O conjunto de fases que o compõe pode variar 
conforme a necessidade da equipe em questão.
 
O ciclo de vida clássico foi proposto por Winston W. Royce no ano de 1970 
como um conjunto de estágios a serem seguidos para a obtenção de um produto 
de software. Posteriormente diversas variações do modelo foram propostas. Cada 
uma com o objetivo de eliminar fragilidades ou promover adaptações para 
melhorar a utilização do modelo.
TÓPICO 2 | PROCESSOS DE SOFTWARE
25
Royce (1970) propôs o modelo clássico com as fases de requisitos de 
sistema, requisitos de software, análise, design de programa, codificação, teste e 
manutenção. O ciclo de vida clássico tem como característica marcante o fato 
de todas as fases de desenvolvimento ter momentos de início e término bem 
definidos, ou seja, uma fase só inicia se a anterior estiver concluída.
FIGURA 8 – CICLO DE VIDA CLÁSSICO
FONTE: Royce (1970)
Na fase de requisito de sistemas são estabelecidos os requisitos para todos 
os elementos do sistema. Nesta fase são coletados requisitos em nível de sistemas 
ou alto nível sem aprofundamento em análise ou design.
Os requisitos necessários ao software são coletados na fase de requisitos 
de software. Nesta fase também é compreendido o domínio da informação, 
desempenho e interfaces necessárias. O artefato resultante é um conjunto de 
requisitos devidamente documentados.
 
A fase de análise compreende as atividades de análise do sistema no 
contexto da aplicação e análise das integrações com os demais sistemas. Nesta 
fase é intensificada a coleta de requisitos em níveis de detalhes mais específicos. 
É importante que o analista compreenda o domínio de informações necessárias 
ao software, permitindo detalhar as funções que o mesmo deve desempenhar. 
Tipicamente o artefato gerado nesta fase é a documentação dos requisitos que 
será utilizada nas fases seguintes do ciclo de desenvolvimento.
UNIDADE 1 | PROCESSOS E REQUISITOS DE SOFTWARE
26
O design de programa ou simplesmente design é uma fase que compreende 
a definição das estruturas de dados, arquitetura de software, decisão sobre detalhes 
procedimentais e caracterização de interfaces (PRESSMAN, 1995). Esta fase 
também deve gerar artefatos de documentação. As definições realizadas nesta 
fase são vitais para o processo de construção e manutenção do futuro software, 
pois uma vez definida a arquitetura do software a sua forma de construção estará 
apoiada nesta arquitetura.
Embora tipicamente se acredite que a maior dificuldade em criar uma nova 
geração de software esteja na linguagem ou ambiente de programação, na realidade os 
maiores desafios poderão estar relacionados às questões arquiteturais.
UNI
A fase de codificação é destinada à transcrição do design para uma 
linguagem de programação. O objetivo é realizar a programação do que foi 
definido nas fases de análise e design. Esta fase é amplamente beneficiada em 
termos de esforço na maioria dos projetos. Porém ela pode ser reduzida caso nas 
fases anteriores os artefatos gerados tenham a riqueza e consistência necessárias.
Nos testes é verificado se o produto está atendendo aos requisitos 
estabelecidos e também se o produto está livre de falhas. E por último, na fase de 
operação que é tipicamente referenciada como fase de manutenção, as eventuais 
falhas identificadas são corrigidas e novas funcionalidades são agregadas ao 
produto.
O modelo clássico tem como potencialidade a visibilidade da fase em 
que o projeto se encontra. O que também favorece o modelo é a necessidade de 
conclusão de uma fase para iniciar a seguinte. Ao seguir tal premissa do modelo, 
podemos nos beneficiar da existência de artefatos completos para subsidiar a fase 
seguinte.
Neste modelo pode ser interessante adotar também uma metodologia 
de processo de passagem de portões (stage-gate process). A ideia básica é realizar 
um processo de validação dos artefatos produzidos na fase para início da fase 
seguinte. Uma forma prática de implementar pode ser através de uma revisão 
por pares dos artefatos gerados.
O que conspira contra o modelo clássico é que geralmente é difícil poder 
seguir um fluxo sequencial no desenvolvimento de software. Outra dificuldade é 
conseguir que o usuário detalhe todas as suas necessidades no início do projeto. 
O que é relativamente natural, pois na medida em que o projeto avança e os 
TÓPICO 2 | PROCESSOS DE SOFTWARE
27
requisitos são transformados em funcionalidades de software, novas possibilidades 
e funcionalidades poderão ser percebidas. Ameaça o uso do modelo também, o 
fato de que o usuário só terá algo para utilizar quando todo o processo estiver 
concluído.
Outros autores destacam diferentes fases do modelo clássico. Por 
exemplo, Sommerville (2003) destaca as fases de definição de requisitos, projeto 
de sistemas e de software, implementação e teste de unidades, integração e teste 
de sistemas e operação e manutenção. Já Pfleeger (2004) descreve as fases de 
análise de requisitos, projeto do sistema, projeto do programa, codificação, teste 
de unidades e de integração, teste do sistema, teste de aceitação e operação e 
manutenção.
Neste caso não cabe discutir quem está certo ou não. O que importa é que 
cada autor chama a atenção para as fases que são mais relevantes de acordo com 
sua experiência e realidade em termos de processos de software.
4 MODELO ESPIRAL
O modelo espiralfoi proposto por Barry Boehm no ano de 1988 como uma 
abordagem para contribuir na melhoria da situação dos processos de software da 
época. O maior diferencial está na abordagem orientada a riscos, ao invés das 
abordagens orientadas à documentação e codificação.
O ciclo de vida espiral permite acompanhar a evolução dos requisitos, 
disponibilizando-os segundo a prioridade das necessidades do usuário. Este 
modelo facilita a incorporação de novos requisitos de forma evolutiva. Ele 
combina características do ciclo de vida clássico e da prototipação.
No modelo espiral, o desenvolvimento é progressivo a cada ciclo, sendo 
que em uma ou mais fases de engenharia e protótipos podem ser desenvolvidos 
para definir melhor o problema e refinar os requisitos. A técnica de prototipação 
é utilizada como um mecanismo de redução dos riscos.
De acordo com Sommerville (2003), cada ciclo da espiral é dividido em 
quatro setores:
• Definição de objetivos: são definidos os objetivos para a fase, identificadas as 
restrições, preparado um plano de gerenciamento detalhado, identificados os 
riscos e planejadas estratégias para tratamento dos riscos identificados.
• Avaliação e redução de riscos: para cada risco identificado é realizada uma 
análise detalhada e estabelecidos planos para tratamento dos riscos de forma a 
reduzir sua probabilidade e impacto.
• Desenvolvimento e validação: com base nos riscos identificados uma estratégia 
de desenvolvimento é adotada para reduzir a probabilidade de ocorrência do 
risco.
UNIDADE 1 | PROCESSOS E REQUISITOS DE SOFTWARE
28
• Planejamento: é realizada uma revisão do projeto e decidido pela sua 
continuidade ou não do próximo ciclo. Havendo a decisão de continuar, os 
planos para a próxima fase são estabelecidos.
Uma consideração importante sobre este modelo é que um risco pode 
ser simplesmente algum evento que se ocorrer pode resultar em problemas para 
o projeto. Estes eventos podem representar problemas de performance, atrasos 
em entregas do projeto, incompatibilidade de ferramentas, entre outros que 
representem algum impacto no resultado final do software. Este resultado alterado 
pode representar diversas influências sobre o software entregue.
FIGURA 9 – MODELO ESPIRAL
FONTE: Sommerville (2003)
Além da característica de avaliação dos riscos, neste modelo podem ser 
implementados ciclos com quantidade de requisitos a ponto de facilitar o controle 
do progresso. Dessa forma é possível realizar entregas de artefatos de valor em 
períodos de tempo menores, gerindo a expectativa dos usuários e realizando 
entregas de valor.
O que conspira contra o modelo espiral é a dificuldade de convencer os 
usuários das vantagens do uso do modelo evolutivo. Este modelo exige que a 
equipe de desenvolvimento tenha experiência na avaliação dos riscos. Caso um 
grande risco seja descoberto, este fato poderá inviabilizar o produto. Contribui 
também o fato de não haver um histórico suficiente de projetos desenvolvidos 
nesse modelo para que possa ser determinada sua real eficácia.
TÓPICO 2 | PROCESSOS DE SOFTWARE
29
5 MODELO PROTOTIPAÇÃO
Dentre o grande conjunto de desafios que representam os processos de 
Engenharia de Software está a dificuldade em certificar-se de que os requisitos 
definidos são efetivamente o que o usuário/cliente necessita. Para reduzir a lacuna 
de entendimento foi criada a técnica de prototipação.
A prototipação é uma técnica em que são produzidas versões iniciais 
ou modelos visuais que representam como o software ficará depois de pronto. A 
ideia dessa representação é permitir avaliar as características do software antes 
que ele seja efetivamente desenvolvido. Um modelo visual permite melhorar o 
entendimento dos requisitos que se pretende implementar no software.
No modelo de prototipação é elaborada uma representação do modelo do 
produto através de suas principais funcionalidades. O modelo permite realizar 
a validação de um conjunto de requisitos que deverão ser implementados. 
A prototipação é um modelo utilizado com grau de sucesso satisfatório, pois 
permite ao usuário compreender com mais clareza como o software ficará depois 
de pronto.
FIGURA 10 – MODELO PROTOTIPAÇÃO
FONTE: Pressman (1995)
A característica fundamental do modelo de prototipação é a representação 
do produto através de suas funcionalidades. A ideia chave deste ciclo de vida é 
a criação de um modelo para validar o conjunto de requisitos a serem atendidos.
UNIDADE 1 | PROCESSOS E REQUISITOS DE SOFTWARE
30
Ele pode ser entendido como uma técnica para a identificação de requisitos 
de entrada e saída por parte dos usuários, representando aspectos visíveis a ele, o 
que permite melhor entendimento daquilo que será entregue no final do projeto. 
Ele permite ainda a verificação da eficiência de determinadas rotinas ou fluxos de 
atividades.
Outra característica que pode ser de grande valia é a possibilidade de 
verificação do comportamento do software em determinado ambiente operacional. 
Em resumo, neste ciclo de vida, é realizado o desenvolvimento de um protótipo 
que permita ao usuário identificar as tarefas que deverão ser executadas pelo 
software.
O modelo de prototipação abrange as atividades de coleta e refinamento 
dos requisitos, projeto rápido, construção do protótipo, avaliação do protótipo 
pelo usuário/cliente, refinamento do protótipo e engenharia do produto.
Na fase de coleta e refinamento dos requisitos é realizada a definição 
dos objetivos globais do produto, são identificadas as exigências conhecidas e 
identificadas as necessidades de definições adicionais.
No projeto rápido é criada uma representação dos aspectos visíveis do 
produto, construído um protótipo para avaliação com o usuário/cliente e realizado 
o refinamento dos requisitos do produto que será desenvolvido.
Uma vez com as características básicas definidas pode-se partir para a 
construção do protótipo. No processo de construção do protótipo tipicamente não 
são levadas em consideração quaisquer boas práticas de construção de software, 
pois o protótipo será apenas uma representação do software a ser construído.
Tendo o protótipo pronto, este poderá ser avaliado pelo usuário/cliente. 
Em se tratando de haver necessidade de alterações, o processo segue para a fase 
de refinamento. Uma vez validado o modelo e reduzida a lacuna de entendimento 
dos requisitos, pode-se partir para a construção do produto.
Na fase de engenharia do produto é que o software representado pelo 
protótipo será construído. A ideia básica deste modelo de processos é que o 
protótipo seja descartado e o processo construtivo siga as boas práticas de 
Engenharia de Software.
Este modelo de ciclo de vida devidamente utilizado pode auxiliar 
significativamente o processo de desenvolvimento de software, reduzindo 
retrabalho e principalmente gerenciando adequadamente a expectativa dos 
usuários/clientes. No momento que o software funcional é entregue ao usuário/
cliente não deverá haver diferenças significativas entre o que foi validado em 
termos de protótipo e o software construído.
TÓPICO 2 | PROCESSOS DE SOFTWARE
31
A utilização de prototipação é recomendada por diversos autores e 
também por personalidades da área como Brooks (2009, p. 174) que sugere ”usar 
a prototipagem rápida como parte de uma iteração planejada no estabelecimento 
de requisitos de software”. 
Uma das fragilidades do ciclo de prototipação é a dificuldade do usuário/
cliente compreender que o software apresentado é apenas um modelo e não possui 
as funcionalidades que apresenta nas interfaces que ele vê. O usuário imagina 
que o protótipo é uma versão que ele poderá utilizar imediatamente e não sabe 
que o protótipo foi construído sem levar em consideração requisitos de qualidade 
e manutenibilidade. 
Em geral o que ocorre é grande pressão por parte do usuário em tornar 
o protótipo a versão de trabalho, efetuando apenas pequenos ajustes. O risco 
neste caso é de fragilizar o software pela falta de um processo de desenvolvimentoadequado.
6 MODELO RAD
Com a crescente necessidade de modelos de processos de software 
mais ágeis, no início da década de 1990, James Martin propôs o Modelo de 
Desenvolvimento Rápido de aplicações. Este modelo é conhecido como RAD 
(Rapid Application Development) e é um processo interativo e incremental que 
possui tipicamente um ciclo bastante curto.
O tempo deste ciclo pode variar de equipe para equipe, porém é 
recomendado que ele não seja superior a 90 dias. Este modelo pode ter diversas 
fases e estas variam de acordo com o autor consultado. De forma genérica, ele 
possui as fases de definição, desenvolvimento e manutenção.
FIGURA 11 – MODELO RAD
FONTE: O autor
A fase de definição é realizada a análise global do sistema, ou seja, a fase 
em que são coletados os requisitos. Nesta fase é realizado também o design que 
compreende o planejamento do processo de desenvolvimento. Além disso, são 
realizadas as validações necessárias.
Na fase de desenvolvimento é feito um desenho de interface, realizada a 
codificação e os testes de software. Esta fase é geralmente baseada em uma ou mais 
linguagens de programação.
UNIDADE 1 | PROCESSOS E REQUISITOS DE SOFTWARE
32
Já na fase de manutenção é realizada a evolução do software durante 
sua vida operacional. Nesta fase são realizadas modificações por alterações de 
requisitos, identificação de falhas ou alterações no ambiente do usuário.
Este modelo é recomendado para o desenvolvimento de software com 
pequena distribuição. Ele é apropriado para ambientes em que se possa fazer 
uso de componentes visuais ou classes pré-existentes como APIs (Application 
Programming Interface ou Interface de Programação de Aplicativos).
O modelo RAD pode ser eficientemente utilizado em projetos cujo escopo 
seja restrito e que o desempenho não seja requisito determinante. Também 
pode ser utilizado em projetos em que o software pode ser dividido em diversos 
módulos independentes.
Neste ponto cabe observarmos que o modelo de processo RAD não é 
adequado para qualquer tipo de software ou necessidade de aplicação. O desejo 
por modelos mais ágeis e eficientes existe desde que os primeiros softwares foram 
criados, porém a “natureza força ao equilíbrio”. Em outras palavras se quer dizer 
que não há como utilizar um modelo ágil em todas as situações. Softwares que 
requerem uma abordagem mais robusta requerem modelos de processos mais 
formais.
Para adoção de modelos mais ágeis como o RAD é recomendado que 
a plataforma de desenvolvimento privilegie a agilidade. O uso de linguagens 
de programação baseadas em componentes visuais e que tenham recursos de 
assistente de criação de aplicações é altamente recomendado em conjunto com 
este modelo.
7 MODELO DE QUARTA GERAÇÃO
À medida que as ferramentas de desenvolvimento passaram a oferecer 
novos recursos aos profissionais de software, novos modelos de processos 
também foram desenvolvidos. E o momento em que surgiram as ferramentas de 
quarta geração foi marcante para a Engenharia de Software, pois se vislumbrou 
um possível divisor de águas em relação à como softwares eram especificados e 
desenvolvidos.
Naquele momento da história acreditava-se que em pouco tempo os 
usuários poderiam criar suas aplicações de maneira simples e rápida, sem a 
necessidade do esforço gigantesco de programadores e demais profissionais 
envolvidos no processo de software. Acreditava-se vque em breve o papel dos 
profissionais de desenvolvimento de software seria extinto.
Na época, tal crença era tão forte que Edward Yourdon, um consultor na 
área de Ciência da Computação, professor universitário, defensor da programação 
estruturada e autor de diversos livros, escreveu a obra entitulada Declínio e 
Queda dos Analistas e Programadores.
TÓPICO 2 | PROCESSOS DE SOFTWARE
33
Yourdon realizou importantes contribuições para a área de Engenharia de 
Software, porém, aos olhos da maioria dos profissionais de software, nesta obra, do ano 
de 1992, ele exagerou. A comunidade de profissionais de software criticou Yourdon 
de maneira bastante dura, até que em 1996 ele escreveu uma obra para se retratar. 
A esta obra ele chamou Ressurreição e Ascenção dos Analistas e Programadores.
FIGURA 12 – LIVRO DECLÍNIO E QUEDA DOS ANALISTAS E 
PROGRAMADORES
FONTE: O autor
FIGURA 13 – LIVRO RESSURREIÇÃO E ASCENÇÃO DOS 
ANALISTAS E PROGRAMADORES
FONTE: O autor
Não foi a primeira vez e não será a última que alguém não acertou em 
suas previsões. O papel dos visionários tem grande valor para o progresso da 
tecnologia. Mesmo que as previsões não se confirmem. No ano de 1997, Yourdon 
publicou a obra Projetos Virtualmente Impossíveis. Nela são descritas diversas 
razões pelas quais os projetos se tornam virtualmente impossíveis. 
UNIDADE 1 | PROCESSOS E REQUISITOS DE SOFTWARE
34
Entre estas razões destacadas estão as questões políticas, promessas e 
otimismos ingênuos em relação às entregas e à mentalidade de que programadores 
não precisam dormir. Acrescenta-se também pressão intensa provocada pela 
globalização de mercados, aparecimento de novas tecnologias e mudanças de 
legislação, além de crises inesperadas.
FIGURA 14 – LIVRO: PROJETOS VIRTUALMENTE IMPOSSÍVEIS
FONTE: O autor
Para a felicidade dos profissionais de software as previsões em relação à sua 
obsolecência profissional estavam equivocadas. O que se observa mais de vinte 
anos depois de tais previsões é que profissionais de software são cada vez mais 
importantes e valorizados. Mas vamos às características do modelo de processo 
de quarta geração. 
O modelo de quarta geração, também conhecido como técnica de quarta 
geração, é baseado na utilização de ferramentas de alto nível para especificação 
e desenvolvimento de softwares. Este modelo visa permitir ao desenvolvedor 
especificar software de uma forma que esteja próxima à linguagem natural. É uma 
técnica adequada para desenvolvimento de aplicações pequenas e intermediárias.
A técnica de quarta geração pode abranger as ferramentas de consulta 
a bancos de dados, geração de relatórios, manipulação de dados, interação e 
definição de telas, geração de códigos e capacidade gráfica de alto nível.
TÓPICO 2 | PROCESSOS DE SOFTWARE
35
FIGURA 15 – MODELO DE QUARTA GERAÇÃO
FONTE: Pressman (1995)
Este modelo de processo de software abrange as atividades de coleta de 
requisitos, estratégia de projeto, implementação usando ferramentas de quarta 
geração e testes. Na coleta de requisitos é realizado o levantamento dos requisitos 
junto ao usuário e tradução dos mesmos num protótipo operacional. Já a estratégia 
de projeto abrange o planejamento de como desenvolver o produto para garantir 
a qualidade e manutenibilidade.
Na implementação é realizada a representação dos requisitos numa 
ferramenta de desenvolvimento, resultando em geração automática de código 
e a ligação da aplicação com a estrutura de dados necessária. Os testes visam à 
verificação do produto gerado versus especificações iniciais e o desenvolvimento 
da documentação do produto gerado.
O que conspira contra o modelo de quarta geração é que cada ferramenta 
permite o desenvolvimento de produtos para domínios de aplicações muito 
específicos. Além disso, ainda não há ambientes de quarta geração que possam 
ser utilizados com igual facilidade para todas as categorias de software.
Registrem-se ainda dificuldades de utilização das ferramentas, ineficiência 
do código gerado e manutenibilidade questionável. Por estes motivos, em geral o 
uso da técnica de quarta geração é limitado ao desenvolvimento de um universo 
restrito de sistemas.
8 MODELO ALTERNATIVO
O modelo alternativo incorpora as características dos demais modelos, 
utilizando em maior grau, os processos mais adequados para a aplicação a ser 
desenvolvida. Além disso, podem-se adotar boas práticas de metodologias de 
desenvolvimento de software clássicas ou ágeis.
UNIDADE 1 | PROCESSOS E REQUISITOS DE SOFTWARE
36
Neste modelo de processo de software pode, por exemplo, ser efetuado 
o levantamento