Metodologia de desenvolvimento de sistemas

Prévia do material em texto

Metodologia de 
Desenvolvimento de 
Sistemas 
Metodologia de 
Desenvolvimento de 
Sistemas 
1ª edição
2019
Autoria
Parecerista Validador
Samira Santos da Silva
Sandra Gavioli Puga / José Leão
*Todos os gráficos, tabelas e esquemas são creditados à autoria, salvo quando indicada a referência.
Informamos que é de inteira responsabilidade da autoria a emissão de conceitos. Nenhuma parte
desta publicação poderá ser reproduzida por qualquer meio ou forma sem autorização. A violação dos
direitos autorais é crime estabelecido pela Lei n.º 9.610/98 e punido pelo artigo 184 do Código Penal.
4
Sumário
Sumário
Unidade 1
1. Histórico do Desenvolvimento de Software ...........8
Unidade 2
2. Fundamentos de Desenvolvimento de Software ..22
Unidade 3
3. Modelos do Ciclo de Vida de Projetos de 
Desenvolvimento de Software .................................................35
Unidade 4
4. Modelos MDS ............................................................50
Unidade 5
5. Processos de MDS .....................................................63
Unidade 6
6. Tipos MDS .................................................................77
5
Sumário
Unidade 7
7. Qualidade em MDS ...................................................91
Unidade 8
8. Estudos de Casos com Uso de Software CASE .. 105
6
Palavras do professor
Seja bem-vindo à disciplina de Metodologia de Desenvolvimento de 
Sistemas. A proposta principal deste estudo é abordar os diversos 
conceitos referentes às metodologias existentes para o desenvolvimento 
de softwares, de forma a levá-lo à plena compreensão e utilização dessas 
metodologias em possíveis projetos durante sua carreira acadêmica e 
profissional. Assim, você estará preparado para atender às demandas do 
mercado. 
Ao longo das unidades, serão apresentados os fundamentos do 
desenvolvimento de sistemas, tendo como foco as etapas que constituem 
o desenvolvimento e a introdução ao conceito de metodologia de 
desenvolvimento. Serão evidenciados também os modelos existentes 
para o ciclo de vida de projetos e para o desenvolvimento de softwares, 
assim como os processos, tipos e métricas de qualidade referentes às 
metodologias de desenvolvimento de software. Com o domínio desses 
conceitos, você poderá tomar decisões mais acertadas em seus projetos 
futuros. 
Por fim, será mostrado como o uso de um software CASE pode auxiliar 
o estudo de caso no desenvolvimento de sistemas. Sua compreensão é 
fundamental para que seja possível usufruir de todos os benefícios dessa 
ferramenta, que facilita desde a análise de requisitos até a execução de 
testes. 
Bons estudos!
7
Objetivos da disciplina
• Identificar os fundamentos de metodologia de desenvolvimento 
de sistemas.
• Descrever a história e evolução das metodologias de 
desenvolvimento de sistemas.
• Apontar as diferentes metodologias para desenvolvimento de 
sistemas.
• Descrever e aplicar os processos e tipos de metodologias de 
desenvolvimento de sistemas.
• Definir o conceito de ciclo de vida de projetos de desenvolvimento 
de sistemas.
• Aplicar softwares CASE a estudos de caso e situações-problema no 
desenvolvimento de sistemas.
8
 1Unidade 11. Histórico do Desenvolvimento 
de Software 
Para iniciar seus estudos
Nesta unidade, será apresentado o conceito de metodologia de 
desenvolvimento de software, assim como as diversas metodologias de 
desenvolvimento que foram surgindo ao longo dos anos. Além disso, será 
contextualizado o surgimento de cada metodologia, de forma a justificar 
sua existência. Compreender a evolução das metodologias no decorrer 
do tempo ajudará você a assimilar melhor a aplicação das mesmas ao 
desenvolvimento de softwares em seu cotidiano.
Objetivos de Aprendizagem
• Definir o conceito de metodologia de desenvolvimento de 
sistemas.
• Descrever a história e evolução no decorrer dos anos do conceito 
de metodologia de desenvolvimento de sistemas.
9
Metodologia de Desenvolvimento de Sistemas | Unidade 1 - Histórico do Desenvolvimento de Software 
Introdução da unidade
A compreensão do conceito de metodologia de desenvolvimento de sistemas é fundamental para qualquer 
profissional na área de TI atualmente. Mesmo quando o profissional não trabalha diretamente com a codificação 
de sistemas, isso se faz importante. Todas as outras áreas em uma empresa que desenvolve softwares participam 
desse processo e, portanto, devem conhecê-lo. Por esse motivo, nesta unidade será definido tal conceito.
Por fim, será apresentado como a evolução das metodologias de desenvolvimento resultou nas técnicas mais 
utilizadas nos dias atuais. Assim sendo, compreender a história do desenvolvimento de sistemas possibilita 
assimilar melhor como as metodologias recentes surgiram. Também será possível perceber que o aprimoramento 
no modo como o software vinha sendo desenvolvido resultou em uma gama de métodos que atendem a diversos 
tipos de aplicações.
1.1 Histórico do desenvolvimento de software
Ao longo dos anos, a utilização de softwares foi se tornando essencial no dia a dia das pessoas. Estão presentes 
em todos os segmentos, desde o gerenciamento de caixas de supermercado, no auxílio a médicos durante a 
execução de uma cirurgia em pacientes e até mesmo no controle de pouso e decolagem de uma aeronave. 
Por isso, o funcionamento correto de um software é de extrema importância, visto que erros desse sistema de 
processamento de dados podem causar tanto prejuízos financeiros como danos fatais. 
Devido ao fato de que o desenvolvimento de sistemas pode ser visto como algo complexo, diferentes metodologias 
foram sendo propostas no decorrer dos anos. Elas foram se adaptando ao ambiente em que o software seria 
construído, para garantir a qualidade do que estava sendo produzido. 
Nesta unidade, será abordada a definição do conceito de metodologia de desenvolvimento de software. Em 
seguida, será apresentada a forma como as metodologias de desenvolvimento de software evoluíram ao longo 
dos anos, até chegarem aos métodos mais recorrentes dos dias atuais.
1.1.1 Metodologia de desenvolvimento de software
Define-se como metodologias de desenvolvimento de softwares a estrutura básica para se controlar o modo como 
um sistema deve ser construído. Uma metodologia contém regras, padrões, práticas e conceitos necessários 
para o desenvolvimento de um software, de forma que o mesmo atinja os padrões necessários de qualidade, 
minimizando-se os riscos e custos 
No decorrer dos anos, o uso de softwares foi se difundindo por vários segmentos, tanto técnicos como de negócios, 
fazendo com que as metodologias se adaptassem e evoluíssem. 
Sabendo-se que uma metodologia é um conjunto de métodos, deve-se, também, entender o que é um método 
e qual é a sua função. 
Um método pode ser definido como uma abordagem técnica detalhada passo a passo, a fim de executar uma ou 
mais tarefas estabelecidas pela metodologia. Em outras palavras, a principal função do método é basear-se em 
procedimentos para atingir um objetivo. 
10
Metodologia de Desenvolvimento de Sistemas | Unidade 1 - Histórico do Desenvolvimento de Software 
A metodologia a ser utilizada no desenvolvimento de um sistema deve ser escolhida de forma cautelosa, 
baseando-se na natureza do projeto e no produto final a ser desenvolvido, bem como dos métodos e ferramentas 
que serão empregados e dos controles e produtos parciais desejados.
1.2 Evolução das metodologias de desenvolvimento de 
software
Desenvolver softwares nem sempre é uma tarefa fácil. Existe cada vez mais demanda por softwares que sejam 
eficazes, ou seja, que realizam de fato sua função e que sejam ao mesmo tempo eficientes, consumindo pouca 
memória e pouco poder de processamento computacional. Além disso, devem ser de fácil utilização pelo usuário 
final. 
Apesar dos grandes avanços em termos de tecnologia, pode-se perceber que muitas equipes de desenvolvimento 
ainda entregam softwares que acabam falhando com o usuário em algum momento da operação. Quandoisso 
acontece, raramente é uma falha técnica. Pode-se dizer que, na maioria das vezes, a falha de um sistema é 
resultado da ausência ou utilização de forma errada de metodologias de desenvolvimento. 
Nos primórdios do desenvolvimento de software, o modelo básico utilizado foi o “codificar e corrigir”, que consistia 
nas seguintes etapas:
1. Escrever um código.
2. Corrigir os problemas deste código.
O modelo básico de desenvolvimento de software consistia em uma espécie de “tentativa e erro”. Era um processo 
considerado artesanal, em que a produção consistia em gerar versões que seriam refinadas sucessivamente com 
o objetivo de eliminar falhas até que o cliente se mostrasse satisfeito. Também não existia uma documentação 
informando os requisitos do software. Tal levantamento era feito de maneira informal e dificilmente o problema 
era modelado, diferentemente do método ágil, em que aplicamos os conceitos de iteração. 
Além da ausência das boas práticas de engenharia de software, o trabalho era todo centrado no programador. 
Nesse cenário, não se fazia o uso de documentações. O software era visto como uma obra de arte e como produto 
central, portanto, não sendo planejado. 
Não obstante os problemas mencionados, o modelo dos primórdios trazia consigo ainda outras desvantagens.
Após um grande número de correções, a estrutura do código se tornava fraca, levando a um alto custo nas próximas 
correções. Isso ressaltava a necessidade de projetar o software antes de codificá-lo. Outro problema é que esse 
tipo de software não contemplava todas as expectativas do usuário após a entrega. Isso evidenciava a necessidade 
do levantamento dos requisitos do software antes de sua codificação. Por fim, o código produzido nesse modelo 
era difícil de ser testado e de ser modificado, caso houvesse necessidade. Isso salientou a necessidade de haver 
uma fase de testes e modificações já planejadas desde o princípio.
Partindo do cenário citado nos parágrafos anteriores, a necessidade de desenvolver softwares de maneira mais 
profissional e organizada se fez clara. A crise do software na década de 1970 foi o que impulsionou a discussão 
sobre formas metodizadas para o desenvolvimento de softwares. O termo “crise de software” diz respeito aos 
problemas enfrentados pelos desenvolvedores da época, devido à grande demanda por sistemas cada vez mais 
complexos, além da ausência de técnicas de desenvolvimento que facilitassem todo o processo. 
11
Metodologia de Desenvolvimento de Sistemas | Unidade 1 - Histórico do Desenvolvimento de Software 
Naquela época, a Conferência da Organização do Tratado do Atlântico Norte (OTAN), que reunia países ocidentais 
e capitalistas, liderados pelos Estados Unidos, marcava o surgimento da engenharia de software. A reunião tinha 
como objetivo a definição de práticas que levassem a melhorias na construção de sistemas.
Figura 1 – Donald Trump dando um discurso durante a OTAN do ano de 2018
Fonte: SHUTTERSTOCK, 2018.
Para saber mais acerca das metodologias de desenvolvimento de software, acesse a Internet 
e pesquise alguns temas sobre a crise do software da década de 1970. 
Saiba mais
12
Metodologia de Desenvolvimento de Sistemas | Unidade 1 - Histórico do Desenvolvimento de Software 
A construção dos primeiros aviões passou pelas mãos dos irmãos Wright. Entretanto, até 
que a ideia funcionasse, houve muito desperdício de recursos, devido às inúmeras tentativas 
sem sucesso. O procedimento funcionava da seguinte forma: a aeronave era construída por 
completo e, ao final, era empurrada de um penhasco. Caso o teste falhasse, a aeronave seria 
destruída e começariam tudo outra vez. Imagine se o desenvolvimento de softwares também 
fosse assim?!
Tendo como motivação inicial a crise de software dos anos 1970, diversos modelos de desenvolvimento foram 
propostos. O primeiro modelo de desenvolvimento proposto é denominado modelo em cascata (ROYCE, 1970), 
também chamado de clássico ou linear, foi um dos primeiros modelos de desenvolvimento de sistemas. Sua 
primeira descrição formal pode ser encontrada em um artigo publicado por Winston W. Royce no ano de 1970. 
Apesar disso, Royce não utilizava o termo “waterfall” ou cascata em seu artigo. Essa metodologia surgiu como 
uma nova forma de desenvolver software que pudesse minimizar os problemas da utilização do modelo artesanal 
da produção de sistemas.
Figura 2 – Winston W. Royce, autor da primeira descrição formal do modelo cascata
Fonte: WINSTON..., 2017.
13
Metodologia de Desenvolvimento de Sistemas | Unidade 1 - Histórico do Desenvolvimento de Software 
Nesse modelo, o desenvolvimento de software é visto de forma sequencial, com um fluir constante para 
frente, como uma cascata, contendo as seguintes fases: levantamento e análise de requisitos, projeto (design), 
desenvolvimento, testes (validação) e operação (manutenção). Cada etapa é fechada em relação às suas 
próximas tarefas, permitindo que uma fase se inicie apenas após a finalização da fase anterior. Entretanto, existe 
a possibilidade de voltar à fase anterior da cascata, caso seja necessário, o que acontece principalmente em 
sistemas mais complexos. Nessa abordagem, é importante que todos da equipe compreendam bem todos os 
pontos que o software deve contemplar. 
A Figura 3 ilustra o processo proposto pelo modelo em cascata.
Figura 3 – Modelo em cascata proposto por Royce em 1970
Requisitos
Design
Análise
Desenvolvimento
Testes
Operação
Fonte: Adaptada de ROYCE, 1970.
Existe também outro modelo intitulado de desenvolvimento iterativo e incremental. Esse modelo surgiu em 
sequência ao modelo cascata. Muitos exemplos de sua utilização podem ser encontrados no artigo de Craig Larman 
e Victor Basili, chamado “Iterative and incremental development: a brief history”. O projeto Mercury, desenvolvido 
pela NASA, agência especial norte-americana, foi um dos primeiros a utilizá-lo. Alguns dos engenheiros do 
Mercury, mais tarde, formaram uma nova divisão dentro da International Business Machines (IBM), que utilizou o 
desenvolvimento iterativo e incremental para a construção do software de um ônibus espacial, entre os anos 
de 1977 e 1980. O software resultou em grande sucesso e contava com 17 iterações que duraram 31 meses, o 
que equivale a aproximadamente oito semanas por iteração. A motivação deles para evitar o modelo cascata foi 
que os requisito do software do ônibus mudavam constantemente durante o processo de desenvolvimento do 
software. 
A ideia principal do modelo iterativo e incremental é desenvolver um sistema por meio de repetidos ciclos 
(iterativo) pelas fases, que são semelhantes às fases do modelo cascata, porém, desenvolvendo pequenas partes 
(novas funcionalidades) por vez (incremental). Dessa forma, à cada iteração, novas informações em relação ao 
domínio do problema podem ser adquiridas, possibilitando que novas versões tenham funções adicionais sem 
causar grandes prejuízos ao desenvolvimento. 
14
Metodologia de Desenvolvimento de Sistemas | Unidade 1 - Histórico do Desenvolvimento de Software 
As fases básicas desse tipo de modelo são: análise, projeto, implementação e testes. Essa abordagem contrasta 
com o modelo cascata, visto que as fases são realizadas apenas uma vez. 
A Figura 4 ilustra o funcionamento desse modelo.
Figura 4 – Modelo iterativo e incremental inicialmente utilizado em projetos da NASA entre 1977 e 1980
Fonte: Adaptada de PRESSMAN, 2016.
O principal processo de desenvolvimento que contempla a metodologia iterativa e incremental é o Rational Unified 
Process - Processo Unificado Racional (RUP), que foi patenteado pela empresa Rational. 
De forma semelhante ao modelo iterativo e incremental, a abordagem de desenvolvimento de software denominada 
prototipação também visa resolver problemas recorrentes das alterações constantes em um software. Ela permite 
que versões iniciais do sistema sejam verificadas antes de prosseguir com o desenvolvimento. Sua prática foium dos pontos que Frederick P. Brooks aborda em seu livro de 1975, chamado “The mythical man-month”, e o 
artigo do seu aniversário de 10 anos, denominado “No silver bullet”. Um dos primeiros exemplos de aplicação da 
prototipagem em softwares de grande escala foi na implementação do tradutor Ada/ED, da Universidade de Nova 
York, utilizado na linguagem de programação Ada. O tradutor foi implementado na linguagem SETL, privilegiando 
clareza de design e interface de usuário em detrimento à velocidade e eficiência. O sistema Ada/ED foi a primeira 
implementação Ada, certificada no dia 11 de abril de 1983.
Figura 5 – Frederick P. Brooks, um dos precursores na consolidação da prototipagem como modelo de desenvolvimento de 
software
Fonte: FRED..., 2016.
15
Metodologia de Desenvolvimento de Sistemas | Unidade 1 - Histórico do Desenvolvimento de Software 
Existem três formas de criar uma aplicação protótipo para ser validada.
• A primeira é criar o protótipo no papel ou mesmo no computador que retrate a interação homem-
máquina. Nesse caso, pode-se entregar ao usuário um protótipo de uma interface gráfica de usuário, por 
exemplo, e pedir que ele interaja com o protótipo realizando sugestões sempre que necessário.
• A segunda é implementar uma funcionalidade dentre as que estão no escopo do software que está sendo 
desenvolvido.
• A terceira é utilizar-se de um software já pronto que tenha parte ou todas as funcionalidades necessárias. 
Essa última é mais utilizada em softwares que estão parcialmente prontos, mas que precisam de funções 
adicionais ou até mesmo melhorias. 
Na maioria dos casos, a prototipagem ajuda a encontrar requisitos ainda não descobertos, bem como garantir 
que funcionalidades individuais funcionem corretamente. 
Um ponto negativo desse modelo é que, em alguns casos, desenvolvedores realizam concessões temporárias, a 
fim de colocarem o protótipo do software em funcionamento, mas que acabam ficando até a versão final. Para 
sua utilização com eficiência, é necessário que usuário e desenvolvedor entendam que o protótipo é apenas uma 
versão que ajuda na definição dos requisitos de um software. 
A Figura 6 ilustra o funcionamento do modelo prototipagem.
Figura 6 – Modelo prototipagem utilizado amplamente nos anos 80
Requisitos
Definição 
Projeto de sistema
Codificação, teste, ...
Investigação inicial Implementação Manutenção
Fonte: Adaptada de PRESSMAN, 2016. 
O modelo espiral (BOEHM, 1988) foi descrito por Barry Boehm em seu artigo de 1988, denominado “A spiral 
model of software development and enhancement”. Esse modelo busca acomodar as fases do modelo cascata 
em um ciclo mais dinâmico, que passa pelas mesmas fases diversas vezes, aumentando gradualmente os 
níveis de complexidade. Nessa abordagem, começa-se com entradas pequenas, calculando que alterações de 
funcionalidades específicas sejam realizadas antes do sistema todo estar pronto, visto que o custo da alteração 
da aplicação nesse ponto seria maior.
16
Metodologia de Desenvolvimento de Sistemas | Unidade 1 - Histórico do Desenvolvimento de Software 
Figura 7 – Barry Boehm, criador do modelo espiral
Fonte: O LENDÁRIO..., 2018.
O modelo espiral consiste em uma sequência de iterações, em que cada iteração é uma volta em um espiral, e 
cada fase ou atividade no desenvolvimento é um setor ou quadrante da volta. A metodologia espiral engloba as 
melhores práticas dos métodos acima citados, inovando ao trazer também uma nova etapa, chamada “análise de 
riscos”. Conforme ilustra a Figura 8, essa abordagem contém quatro estágios definidos pelos quatro quadrantes 
sobrepondo o espiral.
Figura 8 – Modelo espiral proposto por Barry Boehm em 1988
Fonte: Adaptada de PRESSMAN, 2016.
Ao analisar a figura, é possível observar que:
17
Metodologia de Desenvolvimento de Sistemas | Unidade 1 - Histórico do Desenvolvimento de Software 
• O primeiro estágio (quadrante superior esquerdo) consiste na determinação dos objetivos, soluções 
alternativas e restrições do software.
• No segundo estágio (quadrante superior direito), são analisados os riscos que as decisões tomadas no 
estágio anterior trazem. Nessa etapa, decide-se se a próxima etapa será executada ou não. Geralmente, 
pode-se construir protótipos e realizar simulações do software.
• Já no terceiro estágio (quadrante inferior direito), realiza-se o desenvolvimento do software, englobando 
as etapas de design, especificação, codificação e verificação. Todas as especificações realizadas devem ser 
verificadas de forma apropriada.
• Por fim, o quarto estágio (quadrante inferior esquerdo) consiste na revisão das etapas anteriores, bem 
como o planejamento da próxima fase. Baseando-se nos resultados obtidos nas fases anteriores, pode-se 
planejar como será a próxima fase.
Após a finalização de um ciclo, compreendendo as quatro fases, recomeça-se checando se os requisitos da 
iteração anterior ainda são válidos, incluindo novas funcionalidades, se necessário. 
Na etapa em que os testes são realizados, pode-se contar com a ajuda do cliente para verificar se aquele sistema 
realmente é o que ele está buscando. Assim, uma alteração realizada nas iterações iniciais não teria um custo tão 
alto quanto nas iterações finais. Apesar de o modelo espiral apresentar diversas vantagens, é necessário um nível 
adequado de experiência com essa metodologia para determinar a avaliação dos riscos de forma correta. Se um 
grande risco não for detectado, problemas surgirão nas iterações seguintes. 
O fechamento da era de modelos baseados em cascata é realizado com o surgimento do vorgehensmodell ou 
modelo em “V”, proposto por Paul Rook no fim da década de 1980. Nesse modelo, a dependência entre as fases 
de desenvolvimento e verificação são mostradas de forma explícita. 
Na Figura 9, pode-se verificar as fases do modelo em V. Do lado esquerdo, temos as tarefas de desenvolvimento. 
Do lado direito, as tarefas de testes. As setas em cinza claro indicam qual teste uma tarefa de desenvolvimento 
deve planejar. Os testes são planejados de cima para baixo, conforme as atividades de desenvolvimento vão 
sendo executadas. Após a etapa de implementação, cada teste planejado é executado de baixo para cima.
Figura 9 – Modelo em V proposto por Paul Rook no final da década de 80
Requisitos
do cliente
Requisitos
funcionais
Design
(alto nível)
Design
(detalhado)
Teste de
Unidade
Teste de
Integração
Teste do
sistema
Teste de
aceitação
Implementação
Fonte: Adaptada de PRESSMAN, 2016.
18
Metodologia de Desenvolvimento de Sistemas | Unidade 1 - Histórico do Desenvolvimento de Software 
Apesar de ser simples, fácil de usar e de deixar explícitas as atividades de teste durante o processo, esse modelo 
funciona bem apenas para sistemas mais simples, visto que exige plena compreensão dos requisitos do sistema. 
Além disso, há uma certa dificuldade em se seguir o fluxo sequencial do modelo, já que para passar à próxima fase 
é necessário que a anterior esteja plenamente concluída. 
O termo Desenvolvimento Rápido de Aplicação (MARTIN, 1991) ou Rapid Application Dev (RAD), foi registrado 
por James Martin, em 1991. Esse modelo também pode ser considerado iterativo e incremental, porém enfatiza 
um ciclo de desenvolvimento bastante curto, com duração média entre 30 e 90 dias, e sugere a divisão de 
trabalho em equipes distintas. O número de fases no RAD pode variar entre quatro a seis fases, dependendo 
de qual abordagem da literatura será considerada. Nesta unidade, abordaremos um modelo com cinco fases, 
conforme mostra a Figura 10.
Figura 10 – Fases do desenvolvimento Rápido de Aplicação (RAD)
Análise Inicial
Modelagem de dados
Modelagem de Processo
Geração da aplicaçãoTestes e correções
Entrega
Modelagem de negócio
Fonte: Adaptada de MARTIN, 1991.
As cinco fases aqui consideradas serão: modelagem de negócio, modelagem de dados, modelagem do processo, 
geração da aplicação e testes e modificações.
A fase modelagem de negócio modela o fluxo de informações entrefunções ou módulos. A modelagem de dados 
define as classes e suas relações de acordo com a necessidade da aplicação. A modelagem do processo baseia-se 
na fase anterior para criar o fluxo de dados por meio de diagramas de classes, casos de uso, etc. Na geração da 
aplicação, o software é de fato desenvolvido. Por fim, testes e modificações dos módulos são realizados a fim de 
corrigir possíveis falhas existentes na fase de testes e modificações. 
O RAD é útil quando existe a possibilidade de se modularizar o projeto (o que muitas vezes não é possível). Além 
disso, as tarefas devem ser possíveis de serem divididas em equipes. Por fim, essa metodologia também não se 
aplica a sistemas que não podem ser finalizados no prazo de 90 dias.
No período entre 1990 e 2005, houve uma ascensão do que chamamos de métodos ágeis. Esses métodos 
envolvem um conjunto de metodologias, com o intuito de acelerar o ritmo do desenvolvimento de softwares, 
visto que os modelos tradicionais de desenvolvimento acabavam sendo apontados como lentos e burocráticos. 
19
Metodologia de Desenvolvimento de Sistemas | Unidade 1 - Histórico do Desenvolvimento de Software 
Se antes o desenvolvimento de um software poderia demorar até anos, o objetivo era conseguir fazê-lo em meses 
ou até mesmo semanas. Com a origem desse conceito datada por volta de 1990, o conceito de agile não demorou 
a ser difundido, resultando na criação de diversos modelos que suportam essa metodologia. 
A Tabela 1 exibe alguns dos métodos propostos no período acima citado e suas principais características.
Tabela 1 – Ano de surgimento e principais características de algumas metodologias ágeis
Ano de Surgimento Metodologia Principais características
1995 Dynamic Systems 
Development 
Method (DSDM)
Define qualidade e esforço em termos de custo e tempo no 
princípio do desenvolvimento e ajusta as entregas do projeto 
para atender aos critérios definidos através da categorização 
dos “entregáveis” em: “deve ter”, “deveria ter”, “poderia ter” 
e “não terá”. 
1995 Scrum Projetos são divididos em ciclos (tipicamente mensais) 
chamados de Sprints. Funcionalidades do sistema são 
mantidas no Product Backlog. Existem três papéis na equipe 
do Scrum: Scrum Master, Product Owner e DevTeam. 
1996 Crystal Seus métodos possuem quatro funções: patrocinador 
executivo, designer principal, desenvolvedores e usuários 
experientes. Muitas estratégias e técnicas são empregadas 
para alcançar a agilidade. 
1996 Extreme 
Programming
Torna possível evitar com que o custo do software tenha um 
aumento extremo com o tempo. Seus principais atributos 
são: desenvolvimento incremental, escalonamento flexível, 
códigos de teste automatizados, comunicação verbal, etc. 
1997 Feature-driven 
Development (FDD)
Opera com o princípio de concluir um projeto dividindo-o 
em funções pequenas, com valor para o cliente, e que 
podem ser entregues em menos de duas semanas. Possui 
dois princípios fundamentais: o desenvolvimento de software 
é uma atividade humana e o desenvolvimento de software é 
uma funcionalidade valiosa para o cliente. 
2005 Agile Unified 
Process (AUP)
É a evolução do Rational Unified Process (RUP) e combina 
técnicas existentes como Test Driven Development (TDD) 
e Agile Modeling para entregar um produto de melhor 
qualidade. 
Fonte: Adaptada de PRESSMAN, 2016.
Em 2001, o Manifesto Ágil foi escrito explicando exatamente como um método ágil deveria ser, seu conceito, 
além dos 12 princípios de um método ágil. A partir desse momento, o surgimento e, principalmente, a utilização 
de metodologias ágeis, não parou mais. Ao contrário, em grande parte das empresas atualmente, as técnicas 
de desenvolvimento tradicionais já foram substituídas por metodologias ágeis, levando-nos a crer que estamos 
vivendo a “era agile”. 
20
Metodologia de Desenvolvimento de Sistemas | Unidade 1 - Histórico do Desenvolvimento de Software 
A Figura 11 apresenta a relação dos métodos citados nesta unidade e sua localização na linha do tempo de 
acordo com o ano de seu surgimento. Nela, é possível notar a grande concentração de métodos ágeis surgindo 
entre os anos de 1995 e 2000, devido a um grande interesse no aumento da produtividade naquela época.
Figura 11 – Linha do tempo dos métodos de desenvolvimento de software
Fonte: Adaptada de PRESSMAN, 2016.
Os modelos para o desenvolvimento de software não terminam por aí. De 2005 até os dias atuais, diversos 
modelos vêm sendo propostos para suprir diferentes necessidades vindas de diferentes aplicações. Entretanto, 
os modelos descritos nesta unidade ainda são os mais utilizados. 
Síntese da unidade
Nesta unidade, foi tratada a definição do conceito de metodologia de desenvolvimento de softwares. Além disso, 
foi apresentado como se deu o surgimento de algumas das principais metodologias existentes, que são utilizadas 
até os dias atuais.
21
Considerações finais
Atualmente, todas as empresas que desenvolvem softwares, 
independentemente do segmento a que são direcionados, utilizam uma 
metodologia de desenvolvimento, por vezes mais de uma metodologia 
pode ou deve ser utilizada para garantir o nível de qualidade. Muitas 
empresas, principalmente que desenvolvem softwares para a área 
governamental, têm suas metodologias auditadas pela ISO, sendo esta 
uma exigência de vários órgãos governamentais. 
22
 2Unidade 22. Fundamentos de 
Desenvolvimento de Software
Para iniciar seus estudos
Nesta unidade, apresentaremos os conceitos básicos para a compreensão 
de metodologias de desenvolvimento de software. Daremos a definição de 
software enquanto produto, visto que essa definição é a que se aplica ao 
desenvolvimento de softwares para o mercado. Além disso, abordaremos 
as etapas no desenvolvimento de software, a definição de modelo de ciclo 
de vida, bem como o conceito de metodologia de desenvolvimento de 
software. Todos esses conceitos são importantes para o desenvolvimento 
de softwares mais robustos e com mais qualidade.
Objetivos de Aprendizagem
• Identificar os princípios que envolvem o desenvolvimento de 
software.
• Descrever os conceitos de software enquanto produto, modelos de 
ciclo de vida e metodologias para o desenvolvimento de software.
23
Metodologia de Desenvolvimento de Sistemas | Unidade 2 - Fundamentos de Desenvolvimento de Software
Introdução da unidade
O objetivo desta unidade é contextualizar os fundamentos do desenvolvimento de software e suas etapas, bem como 
apresentar as metodologias de desenvolvimento de software mais utilizadas no momento. Esse conhecimento 
possibilitará ao aluno compreender outros níveis de complexidade de metodologia de desenvolvimento de 
software, do básico ao complexo, facilitando reconhecer no ambiente corporativo das empresas situações em 
que a escolha e aplicação de métodos sejam necessárias. Nesta unidade, será apresentado o conceito de software 
como produto, que é o interesse de equipes que desenvolvem para atender o mercado corporativo. Também 
serão expostas algumas metodologias de desenvolvimento de software existentes. Por fim, serão abordados os 
modelos de ciclo de vida para que o aluno possa entender os seus conceitos e aplicação simultânea com as 
metodologias de desenvolvimento de software.
2.1 Fundamentos de desenvolvimento de Software
Nesta unidade, abordaremos os princípios para a compreensão do desenvolvimento de software. Primeiramente, 
apresentaremos a definição de software enquanto produto categorizando-o em produtos genéricos e sob 
encomenda. Em seguida, definiremos o conceito de desenvolvimento de software apresentando cada uma das 
suas etapas. Então elucidaremos o conceito de modelo de ciclo de vida, exemplificando com a apresentação de 
dois tipos de modelo, em cascata e iterativo e incremental. Por fim, apresentaremos a definição de metodologias de 
desenvolvimento de softwares, ilustrando seu conceito com a descrição de algumas das principais metodologias.
2.1.1 O que é um software?
Programas de computador são escritospor diversas pessoas. Profissionais em empresas escrevem programas 
que simplificam seu trabalho. Pesquisadores escrevem programas que realizam seus experimentos. E alguns 
programadores escrevem programas apenas por hobby. Entretanto, a maior parte do desenvolvimento de software 
é realizada com o intuito profissional, a fim de construí-los para um propósito de negócio. Em geral, softwares 
desse tipo são produzidos por equipes em vez de apenas uma pessoa. Devido a seu alto custo, tanto em termos 
de dinheiro quanto em termos de tempo, geralmente um software é desenvolvido uma vez e mantido durante 
um longo tempo, tendo apenas algumas alterações nesse período. Atualmente, em função do dinamismo dos 
negócios e da disponibilidade de novas tecnologias, métodos voltados ao rápido desenvolvimento e entrega têm 
sido fortemente utilizados, atendendo a um escopo reduzido, porém com forte interação com os usuários. 
Na engenharia de software, tem-se como objetivo apoiar o desenvolvimento de softwares profissionais, visto que 
se integrarão com outros softwares e, assim, farão parte de um sistema completo, requerendo, portanto, diversos 
cuidados, diferentemente de outros tipos de softwares. As técnicas existentes nela apoiam todos os passos no 
desenvolvimento de um software, desde a especificação, passando pelo projeto até a evolução do software. 
Softwares pessoais geralmente não requerem esse tipo de preocupação.
Quando pensamos no conceito de software, geralmente nos referimos a um programa de computador. 
Entretanto, a engenharia de software não diz respeito apenas ao programa de computador, mas também à toda 
documentação e dados de configuração que são necessários para que o programa funcione de forma correta. 
Um sistema de software que foi desenvolvido com intuito profissional é, na maioria das vezes, mais do que apenas 
o programa em si. Inclui a integração de diversos programas e arquivos de configuração. Pode incluir, também, 
uma documentação do sistema para que outra equipe consiga entendê-lo, uma documentação de usuário para 
que usuários consigam interagir com o sistema e até mesmo sites em que o programa possa ser atualizado. 
Uma diferença fundamental entre o desenvolvimento de forma profissional e de forma amadora é a necessidade 
de um manual existente no primeiro. Se quem está escrevendo o software é a própria pessoa que vai utilizá-lo, 
24
Metodologia de Desenvolvimento de Sistemas | Unidade 2 - Fundamentos de Desenvolvimento de Software
não há necessidade de especificar manuais do programa. Entretanto, caso seja um software profissional, isto se 
torna fundamental, visto que alterações futuras, por exemplo, podem ser realizadas por uma equipe diferente 
daquela que o escreveu. Esses pontos são fundamentais para longevidade do software.
Engenheiros de software, de forma geral, se preocupam em desenvolver o que chamamos de produto de software, 
ou seja, um software que pode ser vendido para um cliente. Existem dois tipos de produtos de software: produtos 
genéricos e produtos sob encomenda.
2.1.2 Produtos genéricos
Produtos genéricos são softwares do tipo stand alone (capazes de operar independentemente de outro hardware/
software) produzidos por empresas de desenvolvimento e vendidos para quaisquer clientes que queiram comprá-
los. Exemplos mais comuns desse tipo de software são os softwares para PCs, como ferramentas de banco de 
dados, editores de texto, editores gráficos e ferramentas para gestão de projetos. Além desses exemplos, podemos 
citar o que chamamos de aplicações verticais. Essas aplicações são desenvolvidas para atender a determinado 
nicho. Exemplos disso são os softwares para controle de estoque, sistema de gestão de biblioteca e sistemas 
de contabilidade, desde que desenvolvidos especificamente para serem executados de forma individual, pois 
sistemas de contabilidade e controle de estoques hoje fazem parte de produtos Enterprise Resource Planning (ERP).
Figura 12 – Editor de texto: exemplo de um produto genérico
Fonte: SHUTTERSTOCK, 2018.
2.1.3 Produtos sob encomenda
Produtos sob encomenda são softwares encomendados por um cliente em particular. Por essa razão, esse software 
acaba tendo as características específicas exigidas pelo cliente. Alguns exemplos desse tipo de software são os 
sistemas de controle de dispositivos eletrônicos, sistemas para dar apoio a uma parte específica do negócio ou 
até mesmo sistemas de controle de tráfego aéreo.
25
Metodologia de Desenvolvimento de Sistemas | Unidade 2 - Fundamentos de Desenvolvimento de Software
Figura 13 – Sistema de controle de tráfego aéreo: exemplo de um produto sob encomenda
Fonte: SHUTTERSTOCK, 2018.
2.2 O que é o desenvolvimento de software?
Desenvolver um software é uma atividade complexa, exige inúmeros passos até a operação correta do mesmo. O 
resultado disso é que muitos projetos de desenvolvimento de softwares são abandonados no meio do caminho, 
seja por falta de tempo, seja de dinheiro. Um estudo realizado pelo Standish Group em 1994 relata que 10% dos 
projetos não terminavam dentro do prazo estabelecido. Além disso, cerca de 60% dos projetos obtinham um 
custo maior do que o esperado. A situação atualmente não está nada diferente.
Tentativas para minimizar as dificuldades de se desenvolver softwares, como as citadas no parágrafo anterior, 
envolvem a definição de um processo de desenvolvimento de software. Um processo de desenvolvimento de 
software consiste em todas as atividades para definir, desenvolver, testar e manipular um software. Entre os 
principais objetivos de um processo no desenvolvimento de software, estão: definir as atividades a serem 
executadas; definir quando, como e quem vai executá-las; estabelecer formas de verificar o andamento do 
desenvolvimento; padronizar a forma como o software é desenvolvido em uma empresa. Existem vários processos 
de desenvolvimentos de software. Alguns exemplos de processos já existentes são o ICONIX, o Rational Unified 
Process (RUP) e o Enterprise Unified Process (EUP). 
Um processo de desenvolvimento agrupa as tarefas necessárias para a construção de softwares em atividades. 
Existem diversos processos de softwares propostos. Apesar disso, é um consenso na comunidade de engenharia 
de software que não existe um processo único ideal para todas as situações. Existem processos que se adaptam 
melhor em diferentes situações. Entretanto, podemos definir algumas atividades que estão presentes na maioria 
dos processos, com uma ou outra modificação. Nessa seção, descreveremos as atividades típicas de um processo 
de desenvolvimento de softwares, que são: levantamento de requisitos, análise, projeto, implementação, testes e 
implantação.
26
Metodologia de Desenvolvimento de Sistemas | Unidade 2 - Fundamentos de Desenvolvimento de Software
2.2.1 Levantamento de requisitos
A etapa de levantamento de requisitos consiste na compreensão do problema no qual o desenvolvimento do 
software está imerso. O principal objetivo dessa etapa é fazer com que usuário e desenvolvedores tenham a mesma 
visão do sistema que deve ser construído. Para isso, clientes e desenvolvedores realizam um levantamento das 
necessidades dos futuros usuários do sistema que será desenvolvido. Denominamos tais necessidades como 
requisitos.
Por vezes, o termo levantamento de requisitos é encontrado na literatura como elicitação de 
requisitos ou até mesmo análise de requisitos.
Fique atento!
Geralmente, os requisitos são condições, capacidades e funcionalidades que estão relacionadas ao domínio do 
problema e que devem ser trazidas para o sistema. Durante essa etapa, é necessário também que a equipe de 
desenvolvimento procure entender o domínio que deve ser compreendido pelo sistema. Existem diversas técnicas 
para isso, como: leitura de material de referência; imersão no ambiente do usuário para observação; entrevista 
com usuários e especialistas; workshops; entre outras.
O resultado da etapa de levantamento de requisitos é o documento derequisitos, contendo diversos tipos de 
requisitos para o sistema a ser desenvolvido. Esse documento pode vir até mesmo escrito em linguagem informal. 
Um documento como esse, normalmente, contém:
1. Requisitos funcionais: definem as funcionalidades que devem existir no sistema. Um exemplo desse 
requisito seria: “O sistema deve permitir que cada recepcionista cadastre um novo paciente”.
2. Requisitos não-funcionais: definem as restrições existentes em relação às funcionalidades do sistema. 
Alguns dos tipos de requisitos não funcionais serão listados a seguir.
a. Confiabilidade: consiste em medidas quantitativas que dizem respeito à confiabilidade exigida do sistema. 
Exemplo disso seria definir um requisito que determina qual deve ser o tempo médio mínimo entre falhas. 
Dessa forma, conseguimos “exigir” que o sistema tenha o mínimo de confiabilidade.
b. Desempenho: corresponde a requisitos que vão estabelecer o tempo de resposta esperado para 
determinadas funcionalidades ou até mesmo a quantidade máxima de memória requerida pelo sistema.
c. Portabilidade: requisitos que vão restringir os componentes de hardware ou software com os quais o 
sistema terá de interagir. Geralmente, estão ligados aos sistemas operacionais e plataformas sob os quais 
o software deverá ser executado.
d. Segurança: esse tipo de requisito diz respeito a limitar acessos não autorizados a determinadas partes 
do sistema (ou a todo o sistema), seja por acessos internos, seja externos, a fim de garantir o mínimo 
de segurança. Temos de considerar que, atualmente, temos a Lei Geral de Proteção de Dados do Brasil 
(LGPD), uma política internacional de proteção ao dado que está sendo implantada no Brasil, de forma 
que essas leis devem ser consideradas. 
27
Metodologia de Desenvolvimento de Sistemas | Unidade 2 - Fundamentos de Desenvolvimento de Software
e. Usabilidade: requisitos que vão afetar a usabilidade do sistema. O impacto se dá, principalmente, na 
facilidade de uso e na necessidade de realizar treinamentos com usuários ou não.
 3. Requisitos normativos: são restrições que limitam o desenvolvimento do sistema. Podem dizer respeito, 
por exemplo, ao custo e prazo máximo de entrega do sistema ou até mesmo a aspectos legais (necessidade 
de licença), componentes de hardware ou software que necessitam ser adquiridos, além de atender a 
aspectos específicos da legislação brasileira, etc. Também podem ser regras de negócio, restrições ou 
políticas do domínio do problema que afetam o desenvolvimento.
Requisitos devem ser estabelecidos de modo que seja possível sua verificação. Além disso, clientes devem ser 
capazes de compreendê-los, bem como todos da equipe. Ele não deve conter as soluções técnicas a serem 
adotadas, mas sim responder à pergunta: “O que o usuário precisa neste sistema?”. Nesse documento, é 
interessante que os requisitos apareçam ordenados de acordo com a prioridade que é definida pelo valor que 
sua implementação traz ao cliente. Essa prioridade ajudará a equipe técnica a tomar decisões ao longo do 
desenvolvimento. 
Essa etapa é a mais importante em termos financeiros, visto que uma especificação incorreta leva a sistemas 
inconsistentes, que não serão utilizados de fato, resultando em desperdício de dinheiro e tempo. Além disso, esse 
documento pode ser visto como um termo de consentimento entre a equipe técnica e o cliente. Nesse sentido, 
ele é a garantia para a equipe de desenvolvimento de que aquilo que foi implementado realmente era o que o 
cliente concordou ao assinar o documento de requisitos.
2.2.2 Análise
Por vezes, a etapa de levantamento de requisitos (definida anteriormente) em conjunto com a etapa de análise 
recebem o nome de engenharia de requisitos. Nesta seção, abordaremos a fase de análise. Num contexto geral, 
o termo “analisar” significa dividir um sistema em componentes e verificar como interagem, a fim de entender o 
funcionamento do sistema. No contexto de sistemas de softwares, essa etapa consiste em um estudo detalhado 
dos requisitos que foram levantados na etapa anterior. Com base nesse estudo, modelos que representem o 
sistema são construídos.
Eventualmente, o termo análise é encontrado na literatura como análise de requisitos.
Fique atento!
Assim como o levantamento de requisitos, a análise de requisitos não leva em consideração o ambiente tecnológico 
a ser utilizado. Esta não é uma preocupação da análise de requisitos. É necessário primeiro especificar de forma 
bem clara o que deve ser feito, para só então definir como fazê-lo. Portanto, deve-se dedicar tempo para que o 
problema seja definido por completo para só então implementá-lo. Muitas equipes pecam por ignorarem essa 
etapa, o que resulta em problemas em etapas futuras. 
28
Metodologia de Desenvolvimento de Sistemas | Unidade 2 - Fundamentos de Desenvolvimento de Software
Os modelos construídos na etapa de análise devem ser validados e verificados. A validação tem como objetivo 
garantir que as necessidades que o cliente possui estão sendo atendidas pelo sistema. A pergunta que deve-se 
fazer é: “Estamos construindo o sistema correto?”. Para ter certeza da resposta, modelos são apresentados a 
futuros usuários para que possam ser validados. A validação evita que se descubra em etapas tardias que o 
sistema em construção não é o que o cliente queria. 
Já a verificação tem por objetivo verificar se modelos construídos condizem com os requisitos definidos. A 
pergunta que se deve fazer é: “Estamos construído o sistema corretamente?”. Modelos nessa etapa são analisados 
separadamente, bem como a consistência da sua integração. A validação é tipicamente uma atividade de análise, 
enquanto a verificação é uma atividade típica da fase de projeto (que veremos a seguir). 
Um dos resultados da etapa de análise é o modelo de objetos representando as classes que compõem o sistema. 
Outro resultado é um modelo funcional do sistema a ser desenvolvido. Ao longo dos anos, diversas ferramentas 
foram propostas para auxiliar na etapa de modelagem. Cada uma é útil para modelar determinado aspecto do 
sistema. Pode-se, também, utilizar mais de uma ferramenta para capturar diferentes aspectos.
A modelagem de dados consiste em criar modelos que expliquem ou descrevam o comportamento de um 
sistema. No caso da modelagem para o projeto de software, esse modelo descreve o sistema a ser construído. As 
principais ferramentas para realizar análise na Unified Modeling Language (UML) são o diagrama de casos de uso e 
o diagrama de classes. Outros diagramas da UML também podem ser utilizados.
2.2.3 Projeto
Na análise, a preocupação está em aspectos que são independentes da implementação do sistema. Já na fase de 
projeto, estabelece-se “como” o sistema funcionará para que atenda aos requisitos, considerando os recursos 
tecnológicos existentes. No projeto, adicionam-se restrições de tecnologia aos modelos construídos na fase de 
análise. Tais restrições podem estar ligadas à arquitetura do sistema, ao padrão de interface gráfica, à linguagem 
de programação, entre outros.
Você também pode encontrar o termo projeto na literatura como “design” ou “desenho”.
Fique atento!
O resultado dessa etapa é uma descrição computacional de o que o software deve fazer, que precisa condizer com 
a descrição produzida pela etapa de análise. Em alguns casos, restrições de tecnologia já ficam subentendidas 
da etapa de análise. Em outros casos, devem ser especificadas nessa etapa. Mas, independentemente disso, essa 
etapa é direcionada pelos modelos produzidos na etapa anterior e pelo planejamento do sistema.
29
Metodologia de Desenvolvimento de Sistemas | Unidade 2 - Fundamentos de Desenvolvimento de Software
Apesar de apresentarmos a análise e o projeto de forma separada nesta unidade, nem 
sempre há uma distinção bem clara entre as duas etapas. Pelo contrário, frequentemente 
essas duas etapas se misturam.
Fique atento!
As duas atividades principais nessa etapa são o projeto da arquitetura e oprojeto detalhado. O projeto da 
arquitetura reside na distribuição das classes de objetos relacionadas do sistema em subsistemas e seus 
componentes. Pode-se, também, distribuir esses componentes de forma física pelos recursos de hardware 
disponíveis. Geralmente, os diagramas de implementação UML são utilizados nessa atividade do projeto.
O projeto de arquitetura também é chamado de “projeto de alto nível”. Já o projeto detalhado 
pode vir com a nomenclatura “projeto de baixo nível”.
Saiba mais
Já no projeto detalhado, modelam-se as colaborações entre objetos de cada módulo, a fim de realizar as 
funcionalidades deste. Nessa atividade, também são realizados projetos da interface com o usuário, do banco de 
dados, dos algoritmos a serem utilizados e é considerada a distribuição do sistema. Geralmente, são utilizados 
diagrama de classes, diagrama de casos de uso, diagrama de interação e diagrama de atividades nessa atividade 
do projeto. 
2.2.4 Implementação
A etapa de implementação consiste em codificar o sistema, ou seja, traduzir a descrição computacional resultante 
da etapa de projeto em um código executável por meio do uso de linguagens de programação. Em processos que 
seguem o paradigma da orientação a objetos, a implementação consiste na criação do código-fonte das classes 
do sistema usando linguagens, como C++, C#, Java, etc. Essa etapa pode consistir na programação desde o início 
ou pode também fazer reuso de componentes de softwares, bibliotecas e frameworks, a fim de tornar mais rápida 
sua execução.
2.2.5 Testes 
A especificação realizada na fase de projeto passa por diversos testes, com o propósito de realizar a verificação do 
sistema. O principal resultado dessa etapa é o relatório de testes, que contém informações sobre possíveis erros 
30
Metodologia de Desenvolvimento de Sistemas | Unidade 2 - Fundamentos de Desenvolvimento de Software
que forem identificados no software. Após a execução dos testes, partes individuais do sistema são integrados 
para, assim, formar o produto de software. 
Há uma tendência nos desenvolvedores de simplificar em demasia as atividades de testes, seja por problemas 
de prazo, pela ansiedade da própria equipe de desenvolvimento ou, principalmente, pelos usuários. Porém, as 
etapas de teste não podem de forma alguma serem minimizadas. Ao contrário, devem ser criadas estratégias, 
selecionar profissionais do cliente e analistas de teste que executarão tais atividades. Considera-se que a equipe 
de desenvolvimento deve ter no seu quadro perfis específicos para as atividades de teste.
2.2.6 Implantação 
A implantação consiste no empacotamento, distribuição e instalação do sistema no ambiente do usuário. Aqui 
os manuais do sistema são escritos, arquivos são carregados, dados são importados para o sistema e usuários são 
capacitados para usar o sistema de forma correta. Por fim, pode ocorrer também a migração não só de sistemas 
de softwares, mas também de dados preexistentes.
2.3 O que são modelos de ciclo de vida?
O desenvolvimento de softwares pode envolver diversas fases (descritas na seção anterior). Denominamos modelo 
de ciclo de vida um encadeamento específico dessas fases na construção de um software. Existe uma diversidade 
de modelos de ciclo de vida. Alguns deles foram apresentados na unidade anterior. A principal diferença entre 
eles está na maneira como as diversas fases são encadeadas. Nesta seção, descreveremos dois modelos de ciclo 
de vida: modelo em cascata; modelo iterativo e incremental.
2.3.1 Modelo em cascata
O modelo de ciclo de vida em cascata é também chamado de clássico ou linear e tem como característica 
principal uma tendência na progressão sequencial entre uma fase e a seguinte. Ocasionalmente, pode haver 
uma retroalimentação entre uma fase e a fase anterior. Mas, de forma geral, as fases seguem em sequência. A 
Figura 14 ilustra o modelo em cascata.
Figura 14 – Modelo em cascata
Requisitos
Design
Análise
Desenvolvimento
Testes
Operação
Fonte: Elaborada pela autora.
31
Metodologia de Desenvolvimento de Sistemas | Unidade 2 - Fundamentos de Desenvolvimento de Software
Existem diversos problemas provenientes da utilização desse modelo. A maioria deles provém da sequencialidade 
das fases. O primeiro problema é que projetos no mundo real dificilmente seguem o fluxo sequencial. Existem 
diversas atividades que podem ser desenvolvidas em paralelo. Além disso, o fato de que essa abordagem define 
que todos os requisitos devem ser levantados no começo do desenvolvido limita a possibilidade da descoberta 
de novos requisitos posteriormente, após testes com o usuário. Por fim, só há uma versão pronta do sistema ao 
chegar ao final do ciclo. Em algumas situações, o usuário não quer esperar todo esse tempo para ter uma versão 
inicial que ele já possa utilizar. 
Mesmo com todos esses problemas, o modelo em cascata foi utilizado durante bastante tempo. Atualmente, sua 
utilização não é mais viável, devido à grande complexidade dos sistemas.
2.3.2 Modelo iterativo e incremental
O modelo de ciclo de vida incremental e iterativo foi proposto na tentativa de solucionar os problemas 
impostos pelo modelo em cascata. Um processo de desenvolvimento segundo essa abordagem considera 
o desenvolvimento em ciclos. Cada ciclo contém as seguintes fases: análise; projeto; implementação; testes. 
Diferentemente da abordagem em cascata, em que essas etapas são realizadas uma única vez, nesta abordagem, 
em cada ciclo, todas essas etapas são executadas novamente. A Figura 15 exibe o modelo iterativo e incremental.
Figura 15 – Modelo de ciclo de vida iterativo e incremental
Fonte: Elaborada pela autora.
O que muda de um ciclo para o outro é o subconjunto de requisitos considerado. Portanto, a cada ciclo, um 
subconjunto de requisitos diferente é desenvolvido. No ciclo seguinte, um novo subconjunto de requisitos é 
considerado criando um novo incremento do sistema, com mais funcionalidades implementadas a cada ciclo. 
Podemos entender esse método como uma generalização do método em cascata. Considerando cada ciclo 
individualmente, podemos dizer que ali existe um desenvolvimento em camada. 
Essa abordagem só funciona se é possível particionar os requisitos em subconjuntos para que cada subconjunto 
seja implementado em um ciclo diferente. Para decidir quais subconjuntos de requisitos serão desenvolvidos 
primeiro, considera-se a prioridade que cada requisito tem para o cliente e seu risco. Com a abordagem 
incremental, o usuário participa de forma ativa do desenvolvimento do software, o que diminui as chances da 
construção de um sistema diferente do que ele deseja.
32
Metodologia de Desenvolvimento de Sistemas | Unidade 2 - Fundamentos de Desenvolvimento de Software
O modelo de ciclo de vida incremental e iterativo tem por característica o desenvolvimento 
de software em vários passos similares (iterativo), com cada passo estendendo o sistema e 
deixando-o com mais funcionalidades (incremental).
Uma desvantagem frequentemente elucidada dessa abordagem é o fato da possibilidade do usuário já se 
entusiasmar em demasia com a primeira versão do sistema e pensar que esta já corresponde ao sistema final. 
Entretanto, existem várias atividades não sistêmicas que podem e devem ser desenvolvidas com os usuários, 
para que eles conheçam o ciclo de vida do projeto e a estratégia na aplicação de cada ciclo, acrescendo, ainda, as 
vantagens, como o fato de que riscos do projeto nessa abordagem podem ser melhor gerenciados e mitigados, 
fazendo com que mesmo sim valha a pena sua utilização.
2.4 O que são metodologias de desenvolvimento de software?
Podemos definir uma metodologia de desenvolvimento de software como sendo um conjunto de modelos de 
processo ou métodos que possuem alguma característica em comum. Elas são utilizadas para o estabelecimento 
de ordem, definição de padrões e para utilização de técnicas já provadas no desenvolvimento de sistemas, que 
agilizam o processo e garantem o máximo de qualidadeno software. As principais abordagens de metodologias 
de desenvolvimento de software são: metodologia estruturada; metodologia orientada a objetos; metodologia 
ágil. As principais diferenças entre elas estão nas técnicas de construção do processo de negócio, nas definições 
dos dados e nos modelos de eventos.
2.4.1 Metodologia estruturada
Em metodologias do tipo estruturada definem-se uma sucessão de processos detalhados desde o nível macro 
até o nível mais baixo. Em outras palavras, estabelece-se uma visão top-down de sistemas. Entre as metodologias 
existentes, a metodologia estruturada é a mais antiga, estando ainda em uso em algumas instituições. 
A representação dos elementos do sistema nessa metodologia é dada pelo uso do Data Flow Diagram (DFD) ou 
Diagrama de Fluxo de Dados. Esse diagrama descreve o fluxo dos dados no sistema. Já o Entity Relation Diagram (DER) 
ou Diagrama Entidade Relacionamento descreve o relacionamento entre entidades, que podem ser, por exemplo, 
objetos ou pessoas. Ele normaliza os dados do ambiente e define os dados para a aplicação. Nele, determinam-se 
os registros estruturados para serem definidos nas bases de dado. Em outras palavras, especifica-se como dados 
devem entrar e sair dos processos a serem armazenados no sistema. 
Para armazenar as descrições em um repositório, pode-se fazer uso de ferramentas CASE. O resultado é um 
modelo lógico do negócio que representa uma abstração do mundo real. Existem outros métodos que fazem 
parte dessa metodologia, mas não foram abordados aqui.
33
Metodologia de Desenvolvimento de Sistemas | Unidade 2 - Fundamentos de Desenvolvimento de Software
2.4.2 Metodologia Orientada a Objetos
A metodologia de desenvolvimento orientada a objetos entende cada processo como uma coleção de objetos. A 
metodologia utiliza os termos da orientação a objetos como sua base, tais como encapsulamento, requerimento, 
herança e classe. Tendo também seu próprio conjunto de diagramas, a metodologia faz uso de diagramas similares 
à metodologia estruturada. Por vezes, essa metodologia é descrita como contendo quatro fases: análise; projeto 
do sistema; projeto dos objetos; implementação. 
Atualmente, a metodologia orientada a objetos tem sido bastante aceita pelo mercado, em comparação com a 
metodologia estruturada. É possível a transição da metodologia estruturada para a orientada a objetos. Cerca de 
47 metodologias “pontes” têm sido utilizadas com essa função.
2.4.3 Metodologia ágil
O desenvolvimento de software ágil, que começou a partir da metade de 1990, pode ser visto como uma reação 
contra métodos chamados “pesados”, que continham regulamentação bastante restrita e burocrática, como o 
modelo em cascata, por exemplo. A metodologia ágil surgiu para superar os problemas do modelo em cascata 
trazidos pela sua lentidão, burocracia e contradição à forma usual com que os engenheiros de software sempre 
realizaram seu trabalho com eficiência. 
Primitivamente, métodos ágeis eram denominamos “métodos leves”. Durante uma reunião no ano de 2001, 
membros ativos da comunidade se reuniram em Snowbird, nos Estados Unidos, adotando, assim, o nome 
métodos ágeis. Posteriormente, formou-se a Agile Alliance, organização sem fins lucrativos com o objetivo de 
promover o desenvolvimento ágil.
Os métodos ágeis iniciais são os seguintes: Scrum, Crystal Clear, Programação Extrema, Adaptive Software 
Development, Feature Driven Development e Dynamic Systems Development Method. Mais tarde, outros métodos 
foram surgindo e, atualmente, métodos ágeis são bastante utilizados no processo de desenvolvimento de muitas 
empresas. A utilização dos métodos ágeis tem crescido exponencialmente, em função das empresas startups 
que desenvolvem novas soluções aproveitando a oferta de oportunidades geradas pelas novas tecnologias, 
como Internet das Coisas (IoT), e também por empresas tradicionais que, em função do dinamismo do mercado, 
necessitam rapidamente de se adaptarem ao mundo digital.
Síntese da unidade
Esta unidade teve como objetivo definir alguns conceitos básicos para a compreensão do desenvolvimento de 
softwares. Foram apresentados os conceitos de software com produto, bem como a definição de desenvolvimento 
de software, modelos de ciclo de vida e metodologia de desenvolvimento de software.
34
Considerações finais
Compreender os conceitos básicos no desenvolvimento de software 
possibilita que conceitos complexos sejam assimilados de maneira mais 
fácil no futuro.
35
 3Unidade 33. Modelos do Ciclo de Vida de 
Projetos de Desenvolvimento 
de Software
Para iniciar seus estudos
Nesta unidade, você compreenderá os principais conceitos relacionados ao 
ciclo de vida de projetos de software. Conhecer esses conceitos é essencial 
para a tomada correta de decisões relacionadas ao desenvolvimento 
de software em ambientes de desenvolvimento, como empresas, por 
exemplo. 
Objetivos de Aprendizagem
• Compreender os princípios que envolvem o ciclo de vida de 
projetos de software.
• Compreender os conceitos de arquitetura de software e da 
aplicação do conteúdo abordado através de um estudo de caso.
36
Metodologia de Desenvolvimento de Sistemas | Unidade 3 - Modelos do Ciclo de Vida de Projetos de Desenvolvimento de Software
Introdução da unidade
Esta unidade possui como foco apresentar diversos conceitos relacionados ao ciclo de vida de projetos de 
software. Além de detalharmos as etapas típicas de um ciclo de vida, apresentaremos também alguns dos principais 
modelos de ciclo de vida que podem ser utilizados no desenvolvimento de diferentes tipos de software. São eles 
os modelos sequenciais, incrementais e iterativos. Conhecê-los faz com que a decisão sobre quando aplicá-los 
se torne mais fácil. Apresentaremos também o conceito de arquitetura de software, ilustrando o conceito com 
três dos padrões de arquitetura mais utilizados: Arquitetura em Camadas, Cliente-Servidor, MVC, sendo o último 
um dos mais populares em empresas atualmente. Por fim, ilustraremos como é o processo de decisão sobre um 
modelo de ciclo de vida através da apresentação de um estudo de caso. 
3.1 Modelos do ciclo de vida de projetos de desenvolvimento 
de software
Quando pensamos no desenvolvimento de software, queremos ir logo para a parte da codificação em si. 
Entretanto, existem algumas etapas que necessitam ser realizadas antes de colocar, de fato, a mão na massa. 
Decisões relacionadas aos modelos de ciclo de vida de projetos de desenvolvimento de softwares são algumas 
delas. 
Nesta unidade, abordaremos o conceito de Ciclo de Vida de Projetos de Softwares, bem como alguns dos principais 
modelos existentes. Além disso, apresentaremos e discutiremos o conceito de arquitetura de software juntamente 
com alguns dos padrões existentes. Por fim, apresentaremos um estudo de caso que ilustra a aplicação de 
modelos de ciclo de vida no desenvolvimento de softwares.
3.1.1 Ciclo de vida de projetos de software
Para compreender a definição de ciclo de vida de projetos, primeiramente é necessário compreender a definição 
de projeto. De acordo com o PMBOK (Project Management Body of Knowledge), um conjunto de práticas na gestão 
de projetos desenvolvido pelo instituto PMI, a definição de projeto é dada pelo seguinte trecho:
Um projeto é um esforço temporário, empreendido para criar um produto, serviço ou resultado 
exclusivo. Os projetos e as operações diferem, principalmente, no fato de que os projetos são 
temporários e exclusivos, enquanto as operações são contínuas e repetitivas.
De forma geral, o objetivo de um projeto é entregar um produto ou serviço. Quando estamos nos referindo ao 
desenvolvimento de software, o produto do projeto não é algo produzido com ferro derretido que sai moldado de 
uma forma, mas sim algo mais complexo. 
O processo de produção de um software deve ser mais elaborado, o que resulta em um processo mais complexo. Ele 
demanda uma série de atividades que devem ser realizadas de acordo com critérios estabelecidos previamente.Essas atividades são agrupadas por questão de organização e afinidade entre fases, que são então colocadas em 
sequência, considerando uma ordem lógica, de forma que sejam executadas na linha do tempo, que vai do início 
ao fim do projeto. O sequenciamento das fases do projeto de acordo com os critérios adotados é chamado de 
ciclo de vida do projeto (STAIR, 2016).
37
Metodologia de Desenvolvimento de Sistemas | Unidade 3 - Modelos do Ciclo de Vida de Projetos de Desenvolvimento de Software
Os critérios adotados em um ciclo de vida do projeto são os métodos ou processos escolhidos 
para ele.
Saiba mais
Outra forma de definição de ciclo de vida de um projeto de software é dada pela norma NBR ISO/IEC 12207:1998 
que o define oficialmente como sendo uma:
Estrutura contendo processos, atividades e tarefas envolvidas no desenvolvimento, operação e 
manutenção de um produto de software, abrangendo a vida do sistema, desde a definição de seus 
requisitos até o término de seu uso.
Em outras palavras, os modelos de ciclo de vida são o esqueleto ou as estruturas predefinidas nas quais 
encaixamos as fases do processo. A primeira escolha a ser feita no processo de desenvolvimento de um software é 
sobre o modelo de ciclo de vida. Partindo dessa escolha, a melhor forma de obter as necessidades do cliente será 
definida, além da provável data em que o mesmo receberá uma primeira versão do sistema em funcionamento. 
A duração do ciclo de vida de um software vai do começo da sua produção até o momento em que seu uso é 
extinguido. Em geral, os ciclos de vida envolvem as seguintes fases que serão detalhadas a seguir: Planejamento, 
Análise e Especificação de Requisitos, Projeto, Implementação, Testes, Entrega e Implantação, Operação e 
Manutenção.
3.1.2 Planejamento
Na etapa de planejamento, o escopo do software é determinado. Deve-se também fornecer uma estrutura de 
modo que possibilite ao gerente a realização de estimativas iniciais tanto de recursos quanto de custos e prazos. 
É normal, na fase de planejamento, o gerente de projetos construir cronogramas de atividades considerando 
recursos necessários e custo de horas, assim também como recursos dos clientes. Além disso, deve-se elaborar 
um plano de projeto que deve ser definido a partir do processo a ser utilizado.
3.1.3 Análise e especificação de requisitos
Na etapa de análise e especificação de requisitos, o escopo do software é refinado, sendo necessário, conforme 
as boas práticas do PMI (Project Management Institute), gerar um documento de change management, ou mudança 
de documento, para documentar as possíveis incongruências entre o escopo original e o refinado, considerando 
também as mudanças que podem impactar o prazo e o custo do projeto. O objetivo aqui é analisar o domínio do 
problema e da solução e definir exatamente o que o software deve fazer, ou seja, quais as funcionalidades que 
deverão existir e de que modo o software deve se comportar. Um documento com os requisitos do software deve 
ser gerado de forma que não haja ambiguidades ou inconsistência entre os mesmos.
38
Metodologia de Desenvolvimento de Sistemas | Unidade 3 - Modelos do Ciclo de Vida de Projetos de Desenvolvimento de Software
3.1.4 Projeto
A etapa de projeto envolve duas grandes etapas: o projeto da arquitetura do software, bem como o projeto 
detalhado. O resultado da etapa anterior é utilizado como insumo. Aqui pode-se definir, por exemplo, tipos 
de dados a serem utilizados e mecanismo de acesso a eles. Além disso, são fornecidos detalhes essenciais à 
implementação.
3.1.5 Implementação
Na etapa de implementação, o projeto que está no papel é traduzido para uma forma que seja passível de 
execução por um computador. Em outras palavras, o código é de fato escrito, implementando funcionalidades 
que foram identificadas no início do processo.
3.1.6 Testes
Nesta etapa, são executados testes unitários de diversos componentes e anotando os resultados. Além disso, a 
integração de componentes e o sistema como um todo também são testados. O objetivo é encontrar bugs ou 
defeitos.
Alguns modelos de processo já preveem testes nas etapas iniciais do ciclo de vida, assim 
como definem estratégias e roteiro, considerando a participação do usuário e do perfil do 
Analista de Teste.
Fique atento!
3.1.7 Entrega e implantação
Na etapa de entrega e implantação, o software é instalado no ambiente de produção. Portanto, envolve a 
capacitação de usuários, a configuração do ambiente de produção e conversão de bases de dados, caso seja 
necessário. O objetivo maior desta etapa é realizar o Teste de Aceitação com o usuário. Em outras palavras, 
verifica-se se o software satisfaz os requisitos que foram impostos pelos usuários. Alguns métodos de ciclo de 
vida denominam esta fase como Homologação. 
3.1.8 Operação
39
Metodologia de Desenvolvimento de Sistemas | Unidade 3 - Modelos do Ciclo de Vida de Projetos de Desenvolvimento de Software
A etapa de operação consiste na real utilização do software pelo usuário no seu ambiente de trabalho. Esta etapa 
é executada após o teste de aceitação da etapa anterior ser concluído com sucesso. 
3.1.9 Manutenção
A manutenção consiste em fazer alterações no software por algum motivo específico. As manutenções podem ser 
Adaptativas, Evolutivas e Corretivas. A manutenção adaptativa tem por objetivo a adequação do software a seu 
ambiente. A manutenção evolutiva tem o intuito de melhorar a qualidade do software geralmente acrescentando 
novas funcionalidades. Por fim, a manutenção corretiva visa corrigir erros que não foram detectados na etapa 
de teste. Normalmente, nesta fase do projeto, as empresas optam por capacitar e manter uma equipe específica 
para dar sustentação ao sistema.
3.2 Principais modelos do ciclo de vida
A primeira escolha software a ser feita no processo de software é a decisão em relação a qual modelo de ciclo de 
vida utilizar. Essa escolha será influenciada pela forma mais adequada de atender às necessidades do cliente, 
da cultura da equipe de TI atual, bem como quando ele deseja receber uma versão inicial do mesmo em 
funcionamento. A Figura 16 ilustra o funcionamento de três das principais abordagens para definir o ciclo de 
vida. 
Figura 16 – Diferença entre os modelos de ciclo de vida: sequencial, incremental e iterativo
Software desejado = + + 
Sequencial Versão 1 Versão 2 Versão 3
Incremental
Iterativo
Fonte: Elaborada pelo autor.
40
Metodologia de Desenvolvimento de Sistemas | Unidade 3 - Modelos do Ciclo de Vida de Projetos de Desenvolvimento de Software
Para decidir sobre qual modelo utilizar, é necessário ter em mente que não existe um modelo ideal. Características 
como perfil e complexidade do problema do cliente, tempo e custo máximo, equipe envolvida e ambiente onde 
o software irá executar são fatores que influenciarão diretamente na escolha de um modelo de ciclo de vida a ser 
utilizado. 
Do mesmo modo, é raro que uma empresa utilize um único ciclo de vida. Na maior parte das vezes, o processo 
se dá com mais de um ciclo de vida envolvido. Ciclos de vida podem se comportar de maneira sequencial (uma 
fase segue a outra em ordem), iterativa (fases possuem retroalimentação) ou até mesmo incremental (software 
é aprimorado a cada fase) (PRESSMAN, 2016). A seguir, veremos essas três formas de gerar ciclos de vida no 
desenvolvimento de softwares.
3.2.1 Modelos sequenciais
Modelos sequenciais organizam o processo de desenvolvimento de software em uma sequência linear de fases. 
Este modelo se aplica em situações onde requisitos estão bem definidos visto que cada fase somente acontece 
uma vez, dificultando a descoberta e implementação de requisitos na fase desenvolvimento, por exemplo. 
Softwares mais simples podem ser desenvolvidos utilizando este modelo. Um exemplo deste tipo de modelo é o 
Cascata, exemplificado na Figura 17.
Figura 17 – Modelo de ciclo de vida em cascata
Requisitos
Design
Análise
Desenvolvimento
Testes
Operação
Fonte:Elaborada pela autora.
3.2.2 Modelos incrementais
Modelos sequenciais propõem o desenvolvimento de softwares em incrementos ou módulos. Dessa forma, seu 
desenvolvimento segue o fluxo sequencial sendo, por exemplo, um requisito implementado por vez, passando 
por todas as etapas do desenvolvimento. Dessa forma, o cliente já possui uma versão inicial do sistema bem 
antes que o modelo sequencial. Outra vantagem é que o cliente vai avaliando o avanço do desenvolvimento dos 
incrementos/módulos e checando se o software que está sendo construído é o que ele realmente quer. Em relação 
41
Metodologia de Desenvolvimento de Sistemas | Unidade 3 - Modelos do Ciclo de Vida de Projetos de Desenvolvimento de Software
a suas desvantagens, podemos citar o fato de que requisitos instáveis ou incompletos geram muitas mudanças nos 
incrementos. Além disso, a gestão do projeto se torna mais complexa utilizando este modelo. Um exemplo disso 
deste modelo é o RAD (Rapid Application Development) que preza pelo ciclo de desenvolvimento curto, mostrado na 
Figura 18.
Figura 18 – Fases do desenvolvimento rápido de aplicação (RAD)
Análise Inicial
Modelagem de negócio
Testes e correções
Entrega
Modelagem de dados
Modelagem de Processo
Geração da aplicação
Fonte: Elaborada pela autora.
3.2.3 Modelos iterativos
Nos modelos iterativos, não se tem a preocupação em entregar versões que o usuário já consiga operar já no 
primeiro ciclo de vida. O que geralmente são produzidos são protótipos ou modelos para checar se o que está 
sendo desenvolvido é o que o usuário precisa. À medida que os requisitos vão ficando mais claros e constantes, 
versões que o usuário já consiga manipular vão surgindo. Esta abordagem permite aos usuários finais refinarem 
cada vez mais o propósito do software, abrangências e funcionalidades.
Modelos iterativos podem ser empregados para solução de problemas mais complexos, bem como quando 
requisitos mudam a todo momento ou quando não se sabe elucidar ao certo todos os requisitos no início do 
processo. Exemplos de modelos iterativos são o RUP (Rational Unified Process) e o Modelo Espiral, que é ilustrado 
na Figura 19.
42
Metodologia de Desenvolvimento de Sistemas | Unidade 3 - Modelos do Ciclo de Vida de Projetos de Desenvolvimento de Software
Figura 19 – Modelo de ciclo de vida espiral
Fonte: Elaborada pela autora.
3.3 Arquitetura de software
A arquitetura de software é uma descrição em alto nível de abstração que mostra uma visão completa da estrutura 
do sistema (PRESSMAN, 2016). Essa descrição deve dar suporte às funcionalidades existentes no sistema, 
portanto seu comportamento dinâmico deve ser levado em consideração. Além disso, também deve estar em 
conformidade com a qualidade, fazendo com que os requisitos não funcionais sejam de fato aplicados. No nível 
da arquitetura, detalhes de implementação devem ser ocultados. 
Não fazem parte da arquitetura de software o design detalhado (ou de baixo nível) que mostra o projeto dos 
componentes internos, modelos de dados e implementação. Além disso, a arquitetura do sistema físico, que 
inclui processador, topologia de rede, arquitetura de elementos de hardwares, entre outros, também não está 
incluída em arquitetura de software.
43
Metodologia de Desenvolvimento de Sistemas | Unidade 3 - Modelos do Ciclo de Vida de Projetos de Desenvolvimento de Software
Figura 20 – O papel da arquitetura de software no desenvolvimento de software
Requisitos
Requisitos
Arquitetura de Software
Código
Código
?
Fonte: Elaborada pela autora.
Ao longo dos anos, softwares passaram a ter grande importância. Se no início eram aplicações mais simples, 
atualmente estão se tornando cada vez mais complexos, chegando ao ponto de controlar decolagem e pouso de 
aeronaves. Suas funcionalidades simples no princípio de sua popularização, como na utilização de planilhas, não 
chegam próximas da complexidade dos softwares mais recentes contendo um número enorme de funcionalidades, 
como no controle de usinas, por exemplo. Para que isso pudesse acontecer, houve modificações na arquitetura 
dos softwares daquela época para que pudessem suportar tamanha complexidade.
Softwares que são bem arquitetados possuem diversas vantagens. A primeira delas é o fato de que suportam um 
aumento de carga considerável sem perda de desempenho. Além disso, podem ser facilmente escalados. Por fim, 
a arquitetura de um software pode também servir para gerar uma estimativa de custo e gerência de determinado 
projeto. Normalmente, características de arquitetura e custos são computados durante a análise de viabilidade e 
pré-projeto, pois influenciam escopo, prazo e custo do projeto de software.
Os padrões de arquitetura de software surgiram como formas de apresentar, compartilhar e reutilizar conhecimento 
sobre sistemas de software. Propostos na década de 90, são amplamente utilizados até os dias de hoje. Para 
compreender a definição de um padrão de arquitetura de software, é necessário pensar em uma descrição 
abstrata, estilizada, de boas práticas já experimentadas e testadas em diversas aplicações e ambientes. Portanto, 
um padrão de arquitetura deve conter a descrição de uma organização de um sistema que obteve sucesso 
anteriormente. Além disso, deve informar também sobre quando é melhor sua utilização, bem como seus pontos 
fortes e fracos. A seguir, descreveremos três dos principais tipos de padrões de arquitetura (SOMMERVILLE, 2007): 
em Camadas, MVC e Cliente-Servidor.
44
Metodologia de Desenvolvimento de Sistemas | Unidade 3 - Modelos do Ciclo de Vida de Projetos de Desenvolvimento de Software
3.3.1 Arquitetura de software em camadas
O padrão de arquitetura em camadas é uma forma de obter separação e independência entre os componentes 
do software. Neste padrão, as diversas funcionalidades do sistema são distribuídas em camadas separadas, onde 
cada camada só depende dos recursos e serviços que são oferecidos pela camada imediatamente inferior. O 
Quadro 1 mostra algumas das características deste padrão.
Quadro 1 – Descrição da arquitetura de software em camadas
Nome Arquitetura em camadas
Descrição Organiza o sistema em camadas com funcionalidades distribuídas entre elas. Uma 
camada fornece serviços à superior.
Exemplo Sistema de compartilhamento de documentos com direitos autorais, em bibliotecas 
diferentes.
Quando é 
usado
Usado na construção de novos recursos em cima de sistemas existentes, quando o 
desenvolvimento está espalhado por várias equipes.
Vantagens Substituição de camadas inteiras (mantendo interface). 
Desvantagens É difícil a separação clara entre camadas. Desempenho pode ser prejudicado. 
Fonte: Elaborado pela autora.
Esta abordagem suporta o desenvolvimento incremental de sistemas. Ao se desenvolver uma camada, alguns dos 
seus serviços já podem ser disponibilizados ao usuário. A arquitetura é passível de mudança e portável. Contanto 
que sua interface não seja alterada, uma camada pode ser trocada por outra equivalente. E, caso uma camada 
seja alterada, somente a camada adjacente é afetada. 
Na Figura 21 a seguir, exemplificamos uma arquitetura em quatro camadas.
Figura 21 – Exemplo de arquitetura em camadas
Interface de usuário
Gerenciamento de interface de usuário
Autenticação e autorização
Lógica de negócio principal/funcionalidade de 
aplicação Recursos de sistema
Apoio de sistema (SO, banco de dados, etc.)
Fonte: Elaborada pela autora.
45
Metodologia de Desenvolvimento de Sistemas | Unidade 3 - Modelos do Ciclo de Vida de Projetos de Desenvolvimento de Software
No exemplo da figura anterior, a camada mais baixa contém softwares de apoio ao sistema, como banco 
de dados ou sistema operacional. A segunda camada é a camada de aplicação, incluindo componentes que 
estejam relacionados com o funcionamento da aplicação e componentes utilitários que sejam utilizados por 
componentes da aplicação. A terceira camada se preocupa com o gerenciamento de interface de usuário, bem