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.
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. Quando isso 
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 foi 
um 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 entre funçõ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 extremocom 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. 
	Unidade 1
	1. Histórico do Desenvolvimento de Software 
	Unidade 2
	2. Fundamentos de Desenvolvimento de Software
	Unidade 3
	3. Modelos do Ciclo de Vida de Projetos de Desenvolvimento de Software
	Unidade 4
	4. Modelos MDS 
	Unidade 5
	5. Processos de MDS
	Unidade 6
	6. Tipos MDS 
	Unidade 7
	7. Qualidade em MDS
	Unidade 8
	8. Estudos de Casos com Uso de Software CASE