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, bemcomo provê autenticação e autorização ao usuário. Por fim, a quarta camada fornece recurso de interface com 
usuário. O número de camadas nesse padrão é arbitrário.
3.3.2 Arquitetura de software MVC
As características de separação e independência em um padrão de arquitetura são essenciais visto que 
possibilitam com que alterações sejam localizadas. O padrão MVC (Modelo-Visão-Controlador ou Model-View-
Controller) separa os componentes de um sistema em camadas Modelo, Visão e Controlador de forma que seja 
possível alterá-los independentemente. Exemplo disso seria trocar a camada de visão sem ter que alterar as 
restantes. 
A Figura 22 a seguir faz uma analogia da atividade “assistir à TV” com o padrão MVC. O usuário utiliza o controle 
para interagir com as funcionalidades do sistema que estão no modelo. O modelo é um DVD que é quem gerencia 
o que vai ser exibido, de acordo com o que for determinado pelo controle. A camada de visualização, nesse caso, 
é a TV que recebe as ordens da camada modelo (DVD) sobre o que exibir.
Figura 22 – Analogia do modelo MVC com um usuário que assiste a uma TV
Usuário Controlador
Fonte: Adaptada de SHUTTERSTOCK, 2018.
46
Metodologia de Desenvolvimento de Sistemas | Unidade 3 - Modelos do Ciclo de Vida de Projetos de Desenvolvimento de Software
Esse padrão geralmente é utilizado no gerenciamento de iteração em sistemas baseados na Web. O Quadro 2 
resume o padrão MVC. 
Quadro 2 – Descrição da arquitetura de software MV
Nome MVC
Descrição
Separa a apresentação e a interação dos dados do sistema. O componente 
modelo gerencia o sistema de dados e as operações associadas a eles. O 
componente visão define como os dados são apresentados ao usuário. O 
componente controlador gerencia a interação do usuário (ex.: mouse) e passa as 
interações para os outros componentes. 
Exemplo Sistema aplicativo baseado na internet.
Quando é usado Quando existem diversas maneiras de visualizar e interagir com dados. 
Vantagens 
Permite que dados sejam alterados independentemente da sua representação 
e vice-versa. 
Desvantagens Em sistemas simples, o código fica complexo. 
Fonte: Elaborado pela autora.
3.3.3 Arquitetura cliente-servidor
O padrão de arquitetura cliente-servidor é bastante utilizado em sistemas distribuídos, mas pode também ser 
implementado em um único computador. Sua descrição é apresentada no Quadro 3. Nesse tipo de padrão, o 
sistema se organiza como um conjunto de serviços e servidores associados e clientes que utilizam esses serviços.
Quadro 3 – Descrição da arquitetura de software cliente-servidor
Nome Cliente-servidor
Descrição
Funcionalidades associadas a serviços que são oferecidos por servidores. Clientes 
podem solicitar serviços. 
Exemplo Biblioteca de vídeos organizados como um sistema cliente-servidor.
Quando é usado
Quando banco de dados compartilhado precisa ser acessado a partir de uma 
série de locais. 
Vantagens Servidores podem ser distribuídos através de uma rede. 
Desvantagens
Cada serviço é um ponto único de falha suscetível a ataques. Desempenho 
depende da rede. 
Fonte: Elaborado pela autora.
47
Metodologia de Desenvolvimento de Sistemas | Unidade 3 - Modelos do Ciclo de Vida de Projetos de Desenvolvimento de Software
Os principais elementos dessa abordagem são:
1. Um conjunto de servidores oferecendo serviços a outros componentes. Ex.: servidores de impressão que 
oferecem serviços de impressão.
2. Um conjunto de clientes que podem chamar pelos serviços que servidores oferecem.
3. Uma rede que permita aos clientes acessar esses serviços. 
Neste tipo de arquitetura, como nos outros padrões, também se faz presente a separação e a independência. 
Serviços e servidores podem ser alterados sem modificar o restante dos sistemas. Além disso, clientes precisam 
conhecer os servidores e serviços disponíveis, mas servidores não precisam conhecer os clientes. Solicitações são 
feitas por clientes a um servidor que deve respondê-las. 
A Figura 23 contém um exemplo de um sistema multiusuário que utiliza internet para fornecer uma biblioteca de 
filmes e fotos e que usa o modelo cliente-servidor. Servidores diferentes gerenciam mídias diferentes devido às 
suas diferenças. O servidor de catálogos deve fornecer consultas rápidas, além de comércio eletrônico. Por fim, 
um servidor para rodar o programa do cliente numa interface rodando em um browser da internet é utilizado.
Figura 23 – Uma arquitetura cliente-servidor para biblioteca de filmes
Cliente 1
Internet
Servidor de
catálagos
Catálogo de
Biblioteca
Servidor
de vídeos
Servidor
de Fotos
Servidor
Web
Informações sobre
vídeos/fotos
Arquivo de
Filmes
Arquivo de
Fotos
Cliente 2 Cliente 3 Cliente 4
Fonte: Elaborada pela autora.
3.4 Estudo de caso
Nesta seção, desenvolveremos um estudo de caso com o objetivo de consolidar os principais conceitos teóricos 
descritos nesta unidade e prover uma visão prática de como decidir em um projeto do mundo real em relação a 
qual modelo de ciclo de vidas utilizar. 
O sistema do estudo de caso descrito a seguir será chamado de Sistema de Controle Acadêmico (SCA). Uma 
universidade necessita de um software para a gestão dos diversos processos acadêmicos, como matrícula 
em disciplina, lançamento de notas, alocação de recursos para professores, entre outras ações. Após um 
levantamento, obteve-se uma lista de requisitos iniciais. A universidade tem urgência em utilizar o sistema, visto 
48
Metodologia de Desenvolvimento de Sistemas | Unidade 3 - Modelos do Ciclo de Vida de Projetos de Desenvolvimento de Software
que o início do semestre letivo já está próximo e pelo menos as funcionalidades básicas relacionadas à matrícula 
de alunos não podem demorar a ser implementadas. Além disso, não se tem uma ideia total de como deve ser o 
sistema, apenas uma ideia inicial. 
Considerando a descrição do parágrafo acima, qual seria o modelo de ciclo de vida ideal para o processo do 
desenvolvimento do software SCA? Analisando as informações obtidas, podemos verificar que o modelo ideal 
seria um dos modelos do tipo incremental. Assim, o cliente, que no caso seria a universidade, logo ao final do 
primeiro ciclo já teria uma versão inicial do sistema que poderia ir sendo utilizada. Além disso, a universidade não 
tem uma ideia consistente do que deseja no software, apenas uma ideia dos requisitos iniciais. Desenvolvendo-o 
de forma incremental e com a utilização pela universidade de cada versão, provavelmente serão descobertos 
novos requisitos. Um exemplo de modelo que poderia ser aplicado nesta situação seria o RAD (Rapid Application 
Development) que preza pelo ciclo de desenvolvimento curto.
Síntese da unidade
Nesta unidade, abordamos a definição de ciclo de vida de projetos, suas etapas e os principais modelos existentes. 
Além disso, apresentamos a definição de arquitetura de software, citando também alguns dos padrões de 
arquitetura mais utilizados. Por fim, aplicamos alguns dos conceitos abordados durante a unidade através da 
definição de um estudo de caso.
49
Considerações finais
Desenvolver softwares é um processo complexo, pois seu sucesso 
depende tanto de pessoas quanto de processos e ferramentas. Existe uma 
infinidade de modelos de processo. Entretanto, todos possuem pontos 
positivos e negativos. Todos possuem fases que são comuns à maioria dos 
processos. O ideal é procurar pelo o que mais se adéqua à aplicação a ser 
desenvolvida.
50
 4Unidade 44. Modelos MDS 
Para iniciar seus estudos
Nesta unidade, você compreenderá algumas das diferentes metodologias 
de desenvolvimento de software existentes. Além disso, realizaremos uma 
comparação entre diferentes metodologias, bem como a exploração dos 
conceitos em um estudo de caso. A partir destes conceitos, suas decisões 
acerca de quais métodos utilizar em projetos futuros serão as mais 
corretas possíveis. 
Objetivos de Aprendizagem
• Descrever as principais metodologias de desenvolvimento de 
sistemas existentes para que sejapossível sua aplicação em 
diferentes processos.
• Realizar comparações entre metodologias existentes.
• Analisar estudos de caso.
51
Metodologia de Desenvolvimento de Sistemas | Unidade 4 - Modelos MDS 
Introdução da unidade
A utilização de padrões no desenvolvimento de software se consolidou à medida que os softwares se tornaram 
mais complexos. A necessidade de sistemas com um grande número de funcionalidades fez com que o processo 
de desenvolvimento requeresse uma organização mais formal, de forma que prazos pudessem ser cumpridos, 
e padrões de qualidade, atingidos. Por esse motivo, a utilização de metodologias de desenvolvimento de 
sistemas se tornou algo de extrema importância para a maioria das equipes de desenvolvimento. Esta unidade 
abordará diferentes tipos de metodologias de desenvolvimento de sistemas, com o intuito de compará-las. 
Compreendê-las possibilita que fiquem claras suas vantagens e desvantagens, resultando na tomada das 
melhores decisões sobre métodos para o desenvolvimento de seus projetos.
4.1 Modelos MDS
O surgimento das metodologias de software se deu a partir da grande necessidade de padronizar o processo 
de análise e desenvolvimento de software. O rápido avanço da tecnologia resultou em hardwares cada vez mais 
potentes. Assim, o desenvolvimento de softwares de grande porte se tornou algo mais usual. 
A forma como softwares estavam sendo desenvolvidos não suportava a produção em tal escala. A partir disso, 
surgiram os métodos para padronização e documentação do desenvolvimento de software, fazendo com que 
agora se tornasse viável. Ao longo dos anos, diversas metodologias, pelas mudanças nos padrões, foram surgindo 
a fim atender às necessidades de mercado. Nesta unidade, serão apresentadas as principais metodologias de 
desenvolvimento, bem como uma comparação entre elas e um estudo de caso aplicando os conceitos abordados.
4.1.1 Principais MDS
Uma metodologia de desenvolvimento de software pode ser vista como uma coleção de métodos designados 
para cada atividade ou fase do projeto de um sistema. Nesta seção, serão abordados três dos principais tipos 
de metodologia de desenvolvimento de sistemas, que possuem o intuito de agilizar, organizar e estabelecer 
padrões que garantem maior qualidade do software: metodologia estruturada, metodologia orientada a objetos 
e metodologia ágil.
4.1.2 Metodologia estruturada
A metodologia estruturada surgiu no início da década de 1980 (OLIVEIRA, 1999), com o intuito de solucionar 
os problemas existentes do método de programação linear, método apelidado de “código espaguete”, devido à 
falta de organização existente, fazendo alusão a um emaranhado semelhante a um macarrão. A proposta foi de 
uma abordagem que fosse estruturada para a programação de computadores. Essa nova forma de desenvolver 
criou padrões para os métodos de desenvolvimento, de forma que se tornou indispensável para os profissionais 
daquela época. Ao longo da sua extensiva utilização por mais de uma década, incorporou banco de dados 
relacionais, ferramentas CASE, além de realizar diversas simplificações e melhorias. 
52
Metodologia de Desenvolvimento de Sistemas | Unidade 4 - Modelos MDS 
O termo “estruturada” diz respeito ao fato de que métodos dessa metodologia seguem uma espécie de “passo a 
passo”, chegando a uma estrutura formal final que deve sempre ser seguida. Cada passo é realizado baseando-se 
no resultado do passo anterior. A principal utilização dessa metodologia está associada à documentação e 
análise de projeto de sistemas. Diferentemente da metodologia orientada a objetos (abordada a seguir), seus 
métodos seguem um desenvolvimento estruturado orientado a processos, em vez de serem orientadas a objetos. 
Processos são a forma como os dados vão sendo transformados.
Grande parte das metodologias estruturas são definidas em uma abordagem chamada top-down (de cima para 
baixo). Em outras palavras, é feito um enfoque mais abrangente até chegar ao mais detalhado, passando por 
camadas especificadas do genérico ao mais específico. 
Essa metodologia engloba diversos métodos e processos de software. Alguns dos principais métodos da 
metodologia estruturada são: análise estruturada, projeto estruturado, programação estruturada, análise 
essencial, Structured Analysis and Design Technique (SADT), Diagrama de Fluxo de Dados (DFD) e Modelo Entidade-
Relacionamento (MER). Nesta seção, será feito um enfoque na análise estruturada.
Análise estruturada
Análise estruturada é uma abordagem tradicional para o desenvolvimento de sistemas que foi utilizada durante 
um longo período, principalmente devido à facilidade em sua compreensão (SHELLY,2012). Essa técnica utiliza 
uma sequência de fases, também chamada de Ciclo de Vida de Desenvolvimento de Sistemas (Systems Development 
Life Cycle - SDLC), para planejar, analisar, projetar, implementar e apoiar a construção de um sistema. Mesmo com 
suas modificações ao longo dos anos, essa técnica ainda se faz presente no desenvolvimento de software em 
diversas empresas. Sendo baseada em um plano similar ao modelo para construção de edifícios, algumas vezes 
aparece na literatura como abordagem preditiva. 
A análise estruturada se utiliza de um conjunto de modelos de processo para descrever graficamente um 
sistema. Por vezes, é chamada de “técnica centrada no processo”, devido ao fato de que foca, principalmente, 
nos processos que fazem com que os dados se tornem informações úteis. A análise estruturada não modela só 
os processos, mas também aborda a estrutura e organização dos dados, o projeto do banco de dados relacional 
e os problemas da interface do usuário. 
Um modelo de processo indica os dados que entram e saem dos processos do sistema. Processos recebem os 
dados de entrada, transformando-os por meio das regras de negócios e gerando dados de saída. A Figura 24 
exemplifica um modelo de processo que representa um sistema de registro escolar e é chamado de Diagrama de 
Fluxo de Dados (Data Flow Diagram – DFD), devido ao fato de utilizar diversos símbolos e formas para representar 
o fluxo, o processamento e o armazenamento dos dados.
53
Metodologia de Desenvolvimento de Sistemas | Unidade 4 - Modelos MDS 
Figura 24 – Diagrama de fluxo de dados para um sistema de registro escolar
Alunos
Cursos
Lista de
Aluno
Matricular
Alunos
DADOS DE
REGISTRO
DADOS DO CURSO
ENTRADA
SAÍDA
Sistema de Registro Escolar
Fonte: Adaptada de SHELLY, 2012.
A análise estruturada foca na utilização do SDLC para planejar e administrar o processo de desenvolvimento 
de sistemas. O SDLC especifica atividades e funções que todos os desenvolvedores de sistemas realizam, 
independentemente da abordagem utilizada. O modelo em cascata pode ser utilizado para ilustrar a movimentação 
dos dados no SDLC. O resultado de cada uma das suas fases é chamado de “entregável” ou produto final, que flui 
em direção à fase seguinte. 
Alguns analistas veem desvantagens na utilização de modelos que descrevem o SDLC, como o modelo em 
cascata, pelo fato de que na maioria das vezes não fica clara a interatividade entre as fases. Entretanto, na maior 
parte das vezes, as fases do SDLC não são seguidas com rigidez. Geralmente, modelos são descritos de forma que 
as fases adjacentes possam interagir entre si, como mostram as setas pontilhadas da Figura 25. Já outros analistas 
compreendem o fluxo de dados nesse modelo como sendo bidirecional, com ênfase na interação e entrada de 
usuário. Dessa forma, o modelo seria mais semelhante aos modelos das metodologias ágeis.
.
54
Metodologia de Desenvolvimento de Sistemas | Unidade 4 - Modelos MDS 
Figura 25 – As fases e os “entregáveis” do SDLC no modelo em cascata
Solicitação 
do Sistema
Fase 1
Planejamento de
Sistema
Relatório de
Investigação
Preliminar
Documento de
Requisitos do 
Sistema
Especificação do
Projeto do Sistema
Sistema 
Funcionando
Completamente
Sistema Efetivo
Fase 3
Projeto de Sistema
Fase 2
Análise deSistema
Fase 4
Implementação de
Sistema
Fase 5
Segurança e Suporte
de Sistema
Fonte: Adaptada de SHELLY, 2012.
O modelo SDLC, geralmente é composto por cinco etapas: planejamento de sistema, análise de sistema, projeto 
de sistema, implementação de sistema e suporte e segurança de sistema. Essas etapas serão descritas a seguir.
Planejamento de sistema
A fase de planejamento de sistema recebe como entrada a “solicitação do sistema”, que é um documento 
descrevendo a necessidade ou motivação para um novo sistema que atua em uma questão de negócio, problemas 
ou mudanças desejadas em um sistema já existente. Em muitos casos, a inclusão de requisitos de Tecnologia da 
Informação (TI) por gerentes e usuários no plano de negócio acaba gerando solicitações de sistema. Solicitações 
de sistema podem vir do chefe de departamento, do gerente superior, da equipe de planejamento ou até mesmo 
55
Metodologia de Desenvolvimento de Sistemas | Unidade 4 - Modelos MDS 
do departamento de TI. Solicitações podem estar em diferentes escalas. Uma solicitação menor pode pedir um 
novo recurso no sistema, e uma solicitação maior pode envolver a criação de um sistema. 
O objetivo dessa fase é realizar investigações iniciais para avaliar uma oportunidade ou problema de negócio 
relacionado à TI. Essa investigação é extremamente importante, visto que afetará todos as fases seguintes. 
Nessa etapa, uma parte essencial da investigação é o estudo da viabilidade, que avalia os custos e benefícios, 
recomendando ações baseadas nisso. 
Suponha que o analista receba a solicitação de sistema para mudar o software. 
O primeiro passo é verificar se faz sentido realizar a investigação preliminar. Caso a investigação seja feita, pode 
ser que conclua que não é necessário realizar alteração alguma no sistema, pois o problema não está nele. Caso 
contrário, se for descoberto que o sistema realmente necessita de alterações, segue-se para a próxima etapa.
Análise de sistema
O objetivo da fase de análise de sistemas é construir um modelo lógico do sistema a ser desenvolvido. Como 
passo inicial, deve-se modelar requisitos, investigando processos de negócio e documentando as funcionalidades 
que o sistema deve ter para satisfazer às necessidades do usuário. Na modelagem de requisitos, continua-se 
a investigação iniciada na etapa de planejamento do sistema. Para compreender o sistema, pode-se realizar 
entrevistas, pesquisas, fazer uma revisão de documentos existentes, realizar observação ou amostragem. Essas 
técnicas resultam em modelos de negócio, modelos de processo e de dados e modelos de objetos. O resultado final 
dessa fase, também chamado de “entregável”, é o documento de requisitos do sistema. Ele descreve requisitos 
de usuário e de gerenciamento, os custos e benefícios, além de alternativas para estratégias de desenvolvimento. 
Projeto de sistema
O objetivo da etapa de projeto de sistema é criar um modelo físico que contemple os requisitos documentados 
para o sistema. O projeto da interface de usuário, a identificação das saídas, entradas e processos são englobados 
nessa etapa. Além disso, são projetados controles internos e externos para garantir que o sistema seja confiável, 
consistente e seguro. É também nesta etapa que se decide sobre a arquitetura do software que será usada pelos 
programadores para transformar o projeto lógico em código. 
O resultado dessa etapa é a especificação do projeto do sistema que é apresentado à gestão e ao usuário para 
revisão e aprovação. A participação de ambos é fundamental para evitar com que haja mal-entendidos sobre o 
que o sistema fará, o modo como ele fará e qual será o custo.
Implementação de sistema
A etapa de implementação de sistema é quando, de fato, o sistema é construído. Independentemente da 
metodologia utilizada, seja orientada a objetos, seja estrutura, as ações a serem realizadas são as mesmas: escrever 
o programa, testá-lo, documentá-lo e instalá-lo. O objetivo dessa fase é fornecer um sistema completamente 
funcional e documentado. Em outras palavras, ao final dessa fase, o sistema deve estar pronto para uso. Pode 
incluir, também, conversão de arquivos para serem executados no novo sistema, capacitação de usuários e tudo o 
que for necessário para realizar a transição para o novo sistema. Por fim, pode incluir uma avaliação para verificar 
se seu funcionamento, seus custos e benefícios estão dentro do esperado. 
Suporte e segurança de sistema
A última etapa é o suporte e segurança de sistema. Consiste em manter, aprimorar e proteger o sistema. A 
manutenção corrige erros e adapta o sistema ao ambiente. O aprimoramento provê novas funcionalidades 
56
Metodologia de Desenvolvimento de Sistemas | Unidade 4 - Modelos MDS 
para obter mais benefícios. Já a segurança protege o sistema de ameaças internas e externas. Um sistema bem 
desenvolvido deve ser seguro, confiável, fácil de dar manutenção e escalável.
Apesar de existirem cinco fases na análise estruturada, o desenvolvimento de um sistema 
nunca chega ao fim, visto que as regras de negócio estão sempre mudando, o que leva à 
necessidade frequente de alteração do software.
Fique atento!
4.1.3 Metodologia orientada a objetos
Com o início da programação orientada a objetos e a consolidação de seus conceitos, sua utilização começou a 
se dar em grande escala nos meios acadêmicos. 
A partir da década de 1990 (OLIVEIRA, 1999), metodologias orientadas a objetos começaram a ser estudadas e 
aprimoradas. O objetivo do surgimento dessas metodologias era superar as limitações impostas pelos métodos 
existentes naquela época, grande parte baseados na metodologia estruturada. A cada dia, essa metodologia 
recebe mais adeptos na preferência em relação à estruturada. Sua função é designada como visualizar, modelar 
e implementar sistemas como uma coleção de objetos que interagem entre si, utilizando-se de linguagens de 
modelagem especializadas, atividades e técnicas necessárias para abordar problemas específicos do paradigma 
orientado a objetos (KHAN, 2011). 
As metodologias orientadas a objetos (OO) podem ser divididas em duas categorias (KHAN,2011): metodologias 
OO da primeira geração e metodologias OO da segunda geração. A primeira geração consistia, na verdade, de 
metodologias híbridas, parte estruturada e parte orientada a objetos. A fase de análise era realizada utilizando as 
técnicas de análise estruturada, resultando em: diagramas de fluxo de dados, diagramas entidade-relacionamento 
e diagramas de transição de estado. Já a fase de projeto se concentrava, principalmente, no mapeamento dos 
resultados da etapa de análise para um diagrama de software orientado a objetos. Por vezes, a literatura refere-se 
a essas metodologias como transformativas. Já as metodologias OO da segunda geração apareceram entre os 
anos de 1992 e 1996, consistindo-se em uma evolução das metodologias da primeira geração. As metodologias 
de ambas as gerações são denominadas “seminais”, visto que foram pioneiras em um campo ainda não explorado, 
que era análise e projeto OO, consistindo em uma base para as evoluções seguintes. 
Na metodologia orientada a objetos, não se estrutura o processo como na estruturada. A metodologia 
estruturada considera dados e processos como entidades diferentes. Na metodologia OO, dados e os processos 
que manipulam esses dados são combinados em um componente chamado objeto. Além disso, considera-se 
não só o conceito de classe, mas também o conceito de herança. A principal característica desses métodos é 
não compreender os problemas pelo clássico caminho entrada-processamento-saída. Além disso, processos e 
funções são substituídos por objetos, classes e seus relacionamentos. 
Alguns conceitos de orientação a objetos são necessários para a plena compreensão dessa metodologia. Um 
objeto é um componente que armazena dados e operações que manipulam dados. Podem compor outros objetos 
e ser compostos por objetos. Operações são espécies de funções com o intuito de ler ou manipulardados de 
determinado objeto. Na orientação a objetos, operações são representadas pelo que chamamos de “métodos”. 
Solicitações são chamadas aos métodos com objetivo de executar determinada operação usando um ou mais 
57
Metodologia de Desenvolvimento de Sistemas | Unidade 4 - Modelos MDS 
objetos. Classe é a implementação de fato do tipo de um objeto. Descreve os dados e os métodos específicos que 
todo objeto daquele tipo conterá. 
Um exemplo da aplicação desses conceitos seria imaginar a cadeira específica em que você está sentado neste 
momento. Ela é um objeto ou instância específica da classe de cadeiras. 
A classe de cadeiras possui atributos (dados), tais como custo, dimensão, peso, cor, etc. A cadeira é um móvel 
e, portanto, herda as características que são comuns a todos os móveis. Esse conceito é chamado de herança. 
As características (dados e operações) de uma classe são reutilizadas a cada nova instância/objeto criado, o que 
economiza esforço, código, tempo e aumenta a confiabilidade do sistema. 
Metodologias OO facilitam a modelagem de um problema do mundo real para o contexto do computador, 
visto que englobam conceitos, como grupo, herança e abstração de dados, que são comuns ao mundo real. A 
desvantagem na sua utilização é que alguns bancos de dados e linguagens ainda não estão totalmente equipados 
para prover pura orientação a objetos. Alguns dos principais métodos existentes na metodologia orientada a 
objetos são: análise orientada a objetos, design orientado a objetos e Rational Unified Process (RUP). Nesta seção, 
será abordada a análise orientada a objetos.
Análise orientada a objetos
Diferentemente da análise estruturada, que separa processos e dados, a análise OO combina ambos em objetos. 
O conceito de OO é utilizado para modelar os problemas do mundo real em operações e processos. O resultado 
disso é uma série de objetos que representam pessoas, coisas, transações e eventos do mundo real. Por meio da 
utilização de linguagens de programação OO, o programador consegue criar objetos no código. 
Objetos são instâncias específicas de determinada classe (em que são definidas propriedades). Uma classe 
pode também herdar as características de outra classe, como mostra a Figura 26. Ela apresenta um exemplo 
de um diagrama de classes UML bem simples. Ela contém as classes pessoa, professor e aluno. As duas últimas 
herdam as propriedades da classe pessoa (nome, endereço e RG). Apesar disso, ambas também possuem suas 
características específicas. Por exemplo, um aluno possui uma matrícula e esse atributo não existe na classe 
professor.
Figura 26 – Diagrama de classes UML exemplificando a herança
Pessoa
Nome
Endereço
RG
Professor Aluno
Nome
Endereço
RG
Nome
Endereço
RG
Sala
Telefone
Data_de_Contratacao
Curso
Matrícula
Orientador
Herda Herda
Fonte: Adaptada de SHELLY, 2012.
58
Metodologia de Desenvolvimento de Sistemas | Unidade 4 - Modelos MDS 
No projeto OO, processos internos a um objeto (os chamados métodos) podem alterar suas propriedades. 
Exemplo disso seria um site de uma loja on-line que contém um objeto pedido, que deve conter um atributo 
chamado status. Quando o objeto cliente pede para cancelar o pedido, o atributo status do pedido muda seu valor. 
Nessa abordagem, é possível o envio de informações entre objetos por uma mensagem. Mensagens podem 
requerer uma informação ou determinado comportamento de outro objeto. Exemplo disso seria o objeto pedido 
solicitar ao cliente o endereço para envio. A análise OO faz uso de modelos de objetos para representar dados 
e comportamentos e ilustrar como objetos afetam outros objetos. Descrever objetos e métodos que apoiam as 
operações de negócio possibilita que componentes reutilizáveis sejam desenvolvidos, acelerando o processo de 
desenvolvimento. 
O processo de análise e projeto nos métodos OO segue um conjunto de fases, semelhantemente ao SDLC, 
embora haja uma variação no número e nomes das fases. Além disso, elas tendem a ser mais interativas. 
A figura 4 ilustra um modelo para desenvolvimento de software contendo as seguintes fases: planejamento, análise 
e projeto. A interação entre essas fases produz protótipos que são posteriormente testados e implementados. 
Esse modelo é bastante interativo e pode representar com precisão processos de negócio do mundo real.
Figura 27 – Um modelo interativo frequentemente utilizado por métodos OO
Fonte: Adaptada de SHELLY, 2012.
A metodologia OO se tornou popular, principalmente, devido à transição nos últimos anos de linguagens de 
programação estruturadas para linguagens orientadas a objetos, tais como: Java, Smalltalk, C++, Python, Perl, 
entre outras.
4.1.3.1 Metodologia ágil
As metodologias ágeis surgiram no ano de 1995 (KHAN, 2011). A definição de que metodologias ágeis são 
apenas abordagens de code-and-fix (programar e corrigir) de forma controlada, com pouca ou nenhuma clareza 
do processo, é somente verdade para uma pequena, mas influente minoria de suas abordagens. Essa minoria é 
baseada na prática do projeto do programa, codificação e teste, a fim de aprimorar a flexibilidade e produtividade 
59
Metodologia de Desenvolvimento de Sistemas | Unidade 4 - Modelos MDS 
no desenvolvimento do software. A maioria das abordagens ágeis, no entanto, englobam processos explícitos, 
apesar de haver um esforço para deixá-los o mais leve possível. 
De forma geral, abordagens ágeis fragmentam as fases em iterações sucessivas, compostas por todas as fases, só 
que de menor tamanho, de forma que se mantenha um maior controle e agilidade. Além disso, os erros podem 
ser detectados e corrigidos mais cedo (PRESSMAN; MAXIM, 2016). 
Se comparássemos análise estruturada e metodologia ágil na construção de um edifício, verificaríamos que 
a primeira construiria um plano geral para o edifício, enquanto a segunda buscaria desenvolver o edifício de 
forma incremental, prototipando cada incrementando e ajustando-o conforme o desejo do usuário. Conforme 
o processo ágil vai se consolidando, desenvolvedores podem revisar, estender ou mesclar versões antigas ao 
produto final. A abordagem ágil prioriza o feedback contínuo, de forma que em etapas incrementais seguintes 
não existam erros corrigidos no passado. 
A abordagem ágil foi consolidada a partir do “Manifesto ágil”, que foi criado por um grupo de pessoas que já 
utilizavam essas práticas em 2000, que atualmente são a base para a utilização de métodos ágeis. Apesar de só 
recentemente sua grande exploração ter se difundido, métodos ágeis foram utilizados com sucesso na produção 
do setor automotivo japonês antes mesmo de serem incorporados ao desenvolvimento de softwares. Nesse 
sentido, sua utilização fez sucesso devido aos benefícios do trabalho em equipe e metas de curto prazo, o que 
resultou em produtos de alta qualidade e baixo custo. 
A organização do processo ágil, geralmente, se dá em espiral, com cada iteração desenvolvendo um incremento 
do software baseado no feedback do usuário sobre o que foi desenvolvido na iteração anterior. A interação entre 
desenvolvedores e usuários é constante nesse tipo de metodologia. É importante que a equipe de desenvolvedores 
seja hábil em identificar a completude da informação a ser entregue aos usuários. Muitas vezes são necessárias 
muitas iterações para que o usuário final possa reconhecer valor na informação recebida. A organização em 
espiral tem o objetivo de reduzir riscos no processo, associados, principalmente, com a construção de um software 
diferente do desejado, além de acelerar o processo de desenvolvimento.
Note que uma iteração de um modelo espiral se assemelha bastante ao modelo SDLC.
Diversas variações adaptativas e métodos relacionados existem e há uma expectativa de que isso perdure ainda 
por bastante tempo. Algumas das abordagens que contemplam a metodologia ágil são: Feature Driven Development 
(FDD), Enterprise Unified Process (EUP), Scrum, Crystal (e suas variações), DSDM, Programação Extrema (Extreme 
Programming – XP),entre outras. 
Métodos ágeis se tornaram extremamente populares recentemente, mas é necessária a avaliação de suas 
vantagens e desvantagens para tomar a decisão de quando utilizá-los. Como vantagem, podemos citar que 
métodos ágeis possibilitam que desenvolvedores sejam flexíveis e responsivos. Entretanto, ao mesmo tempo, 
contêm uma documentação muito simples e podem prover mais riscos que as outras metodologias. Além disso, 
o fato de o processo seguir em iterações pode gerar prejuízos em termos de tempo e dinheiro, se não forem bem 
implementadas.
Por fim, é necessário que o analista de sistemas compreenda bem as vantagens e desvantagens de diferentes 
métodos de diferentes metodologias para chegar à conclusão de qual é a melhor opção para determinado projeto.
60
Metodologia de Desenvolvimento de Sistemas | Unidade 4 - Modelos MDS 
4.2 Comparação entre diferentes MDS
As metodologias de desenvolvimento de sistemas apresentadas na Seção 4.1 possuem vantagens e desvantagens. 
Por esse motivo, ao decidir em relação a qual aplicar no desenvolvimento de um sistema, é necessário analisá-
las cautelosamente. O Quadro 4 apresenta uma comparação entre as diferentes metodologias abordadas. São 
apresentadas a descrição, principais ferramentas de modelagem, vantagens e desvantagens para cada uma delas. 
Quadro 4 – Comparação entre diferentes metodologias de desenvolvimento de software
Análise Estruturada Análise OO Métodos Ágeis
Descrição Representa o sistema 
em termos dos dados e 
processos que manipulam 
estes dados. Sistema é 
organizado em fases, como 
no SDLC, com “entregáveis” 
sendo o resultado de cada 
uma. 
Compreende o sistema 
em termos de objetos 
que são consistidos por 
dados e processos. Objetos 
representam coisas/
pessoas do mundo real. 
Comparada à estruturada, 
tende a ser mais iterativa. 
Enfatiza um intenso 
trabalho em equipe. 
Divide o processo de 
desenvolvimento em 
iterações que adicionam 
funcionalidades 
ao sistema. Tenta 
diminuir os riscos 
adicionando recursos 
incrementalmente. 
Tipicamente utiliza o 
modelo espiral. 
Ferramentas 
para 
Modelagem 
Diagramas de Fluxo de 
Dados (DFD) e descrições 
de processo. 
Diagramas orientados a 
objetos (Ex: UML). 
Ferramentas 
para aprimorar a 
comunicação (Ex: 
softwares colaborativos, 
brainstorming e 
whiteboards). 
Vantagens Método tradicional que 
é baseado em uma boa 
documentação. Iteração 
de fases pode prover 
flexibilidade quando 
comparado a outros 
métodos. 
Facilmente integrado 
com linguagens de 
programação OO. 
Modularidade e reúso do 
código, reduzindo custos 
e tempos. Fácil de dar 
manutenção e escalável. 
Muito flexível e eficiente 
diante de mudanças. 
Enfatiza a interação do 
time e os frequentes 
entregáveis reduzem o 
risco do projeto. 
61
Metodologia de Desenvolvimento de Sistemas | Unidade 4 - Modelos MDS 
Desvantagens Mudanças podem ser 
caras, principalmente nas 
últimas fases. Requisitos 
são definidos no princípio 
e podem mudar ao longo 
do tempo. Usuários podem 
mudar de ideia ao longo do 
tempo. 
Interação de objetos e 
classes pode ser complexa 
em sistemas maiores. 
Membros da equipe 
necessitam algum nível 
de habilidade técnica 
e de comunicação. 
Falta de estrutura e 
documentação pode 
gerar fatores de risco. 
Quando requisito muda, 
todo o projeto deve ser 
alterado. 
Fonte: Adaptado de SHELLY, 2012.
4.3 Estudo de caso
Um software para controle de gastos em uma empresa deve ser construído. A equipe de desenvolvimento é 
bastante colaborativa e está bastante engajada no projeto. Têm-se uma ideia inicial das funcionalidades que 
devem existir no software, entretanto, ainda não existe uma lista fechada de requisitos. O cliente necessita que uma 
versão inicial do software esteja pronta o mais rápido possível, visto que sua empresa já está em funcionamento 
sem a gestão dos gastos. 
Nesse exemplo, métodos que fazem parte das metodologias ágeis seriam adequados. O fato de que os membros 
da equipe de desenvolvimento estão bastante comprometidos com o projeto possibilita a aplicação de métodos 
ágeis no processo de desenvolvimento. Além disso, os requisitos estão bastante sujeitos a mudanças. Utilizar 
metodologias ágeis faz com que exista uma redução dos riscos associados a mudanças nos requisitos. Por fim, 
como existe uma necessidade de que uma versão inicial do software esteja pronta rapidamente, metodologias 
ágeis seriam adequadas, pois com poucas iterações já se tem um sistema em funcionamento.
Síntese da unidade
Nesta unidade, foram abordados os conceitos relacionados às principais metodologias de desenvolvimento 
de software: metodologia estruturada, metodologia orientada a objetos e metodologia ágil. Além disso, uma 
comparação entre essas metodologias foi realizada, a fim de destacar suas vantagens e desvantagens. Por fim, 
um estudo de caso possibilitou a aplicação dos conceitos abordados.
62
Considerações finais
As metodologias de desenvolvimento de sistemas não se mantêm 
constantes. Ao contrário, são adaptativas e se modificam ao longo do 
tempo, a fim de se adequarem às necessidades existentes no momento 
presente. A tendência é que, com o passar dos anos, novas metodologias 
surjam e, com elas, novos métodos e novas técnicas para desenvolver 
softwares.
63
 5Unidade 55. Processos de MDS
Para iniciar seus estudos
Nesta unidade, você compreenderá a definição de processo de 
desenvolvimento de software. Também assimilará os diversos tipos 
de fluxo de processos existentes, as diversas métricas para avaliar um 
processo e a forma como um processo unificado se organiza. Com a 
aprendizagem desses conceitos, você poderá fazer as melhores escolhas 
em seus projetos futuros.
Objetivos de Aprendizagem
• Definir processo de desenvolvimento de software e fluxo de 
processo de software.
• Aplicar métricas de projeto e processo de software.
• Definir a aplicação do processo unificado.
64
Metodologia de Desenvolvimento de Sistemas | Unidade 5 - Processos de MDS
Introdução da unidade
Esta unidade abordará diversos conceitos relacionados ao processo de desenvolvimento de software. 
Apresentaremos sua definição de forma que seja possível compreender sua localização dentro da engenharia 
de software. Abordaremos, também, os diversos tipos de fluxo de processo: linear, iterativo, evolucionário e 
paralelo. Compreender as suas diferenças possibilita que você saiba quando utilizá-los em seus projetos futuros. 
Além disso, evidenciaremos a definição de métricas de processo e projeto de software e apresentaremos alguns 
dos seus exemplos. Dessa forma, será possível assimilar as principais características por trás das métricas e sua 
importância, de modo que você se sentirá motivado a utilizá-las em seus projetos. Por fim, definiremos o processo 
unificado, um exemplo de processo que se utiliza das fases genéricas de um processo de desenvolvimento de 
software.
5.1 Processos de MDS
Nesta unidade, algumas definições sobre o processo de desenvolvimento de software serão abordadas. 
Inicialmente, a definição de processo de desenvolvimento de software será estabelecida, bem como as principais 
atividades de um processo genérico. Em seguida, os tipos mais básicos de fluxo de processos de desenvolvimento 
serão apresentados. Por fim, a importância das métricas na avaliação do processo e projeto de desenvolvimento 
de software será evidenciada, bem como será dado um exemplo de processo que pode ser representado utilizando 
as atividades genéricas, denominado processo unificado.
5.1.1 Definição de processo de desenvolvimento de software
De acordo com Pressman e Maxim, uma visão de um ponto de vista diferente sobre o processo de software, 
compreendido pela visão de um economista, Howard Beatjer Jr., é dada pelo seguinte trecho:
Porque o software, como todo capital, é conhecimento incorporado, e porque esse conhecimento é, 
inicialmente, disperso, tácito, latente e, em considerável medida, incompleto, o desenvolvimento 
de software é um processo de aprendizadosocial. Esse processo é um diálogo no qual o 
conhecimento, que deverá se tornar o software, é coletado, reunido e incorporado ao software. 
O processo possibilita a interação entre usuários e projetistas, entre usuários e ferramentas em 
evolução e entre projetistas e ferramentas em evolução (tecnologia). Trata-se de um processo 
iterativo no qual a própria ferramenta em evolução serve como meio de comunicação, com cada 
nova rodada do diálogo extraindo mais conhecimento útil das pessoas envolvidas (PRESSMAN; 
MAXIM, 2016, p. 30).
Podemos, de fato, entender a construção de um software como um processo de aprendizado social iterativo, cujo 
resultado (definido por Howard como “capital de software”) seria a integração do conhecimento que é coletado, 
filtrado e organizado durante o processo. 
O processo de software, de um ponto de vista mais técnico, pode ser definido como uma metodologia para 
atividades, ações e tarefas, cujo objetivo final é desenvolver um software de qualidade. O processo de software 
define a abordagem que será utilizada de acordo com a engenharia de software. Entretanto, a engenharia de 
65
Metodologia de Desenvolvimento de Sistemas | Unidade 5 - Processos de MDS
software também incorpora as tecnologias que fazem parte do processo. Exemplo disso seriam as ferramentas 
automatizadas.
Compreendendo o processo de software como parte da engenharia de software, é importante 
notar que esse processo deve se adaptar de forma que se adeque aos produtos desenvolvidos 
e às necessidades do mercado.
De forma geral, podemos compreender o processo de software como uma série de passos previsíveis para a 
construção de um sistema. Ele pode ser visto como uma espécie de roteiro para que um software de qualidade 
seja produzido dentro de um prazo estabelecido. Geralmente, o processo de software é adaptado por engenheiros 
de software e gerentes para se adequar ao contexto em que será aplicado e, então, seus passos são seguidos. 
Clientes/usuários também têm um papel fundamental no processo de definição, construção e teste do software.
A importância do processo de software se dá, principalmente, pelo fato de que ele favorece com que haja 
controle, estabilidade e organização em uma atividade que poderia se tornar caótica sem essas características. 
Um processo deve ser “ágil” e, para isso, deve requerer somente atividades, controles e produtos adequados para 
a equipe que esteja produzindo e para o produto a ser produzido, além de atender às expectativas de negócio da 
organização. 
O processo de software a ser adotado vai depender do sistema a ser desenvolvido, além das características 
específicas da equipe que vai atuar no seu desenvolvimento. As etapas envolvidas serão diferentes se o sistema a 
ser construído é o software que atua no controle e gerenciamento do tráfego aéreo ou se o sistema é um website 
de uma loja que venda produtos eletrônicos na Internet. 
Os produtos de trabalho ou artefatos envolvidos no processo de software são os programas, documentos e dados 
que foram gerados como resultado das sequências de atividades e tarefas envolvidas no processo do software. 
As atividades, ações e tarefas realizadas dentro de um processo devem-se alocar dentro de uma metodologia 
ou modelo que determina como elas vão se relacionar entre si e também com o processo. A Figura 28 ilustra um 
exemplo de um processo de software genérico.
66
Metodologia de Desenvolvimento de Sistemas | Unidade 5 - Processos de MDS
Figura 28 – Um modelo para um processo de software genérico
Fonte: Adaptada de PRESSMAN; MAXIM, 2016.
67
Metodologia de Desenvolvimento de Sistemas | Unidade 5 - Processos de MDS
Na figura acima, é possível identificar uma sequência com n atividades metodológicas. Atividades metodológicas 
são compostas por um conjunto de k ações de engenharia de software. Ações são compostas por um conjunto 
de tarefas que podem indicar as tarefas programadas para entrega e artefatos de software, ou seja, os programas 
que serão implementados, as garantias que serão requeridas no processo e, por fim, os prazos das entregas 
parciais, com o objetivo de avaliar o progresso. De forma geral, uma metodologia de processo precisa definir 
cinco atividades metodológicas: comunicação, planejamento, modelagem, construção e entrega. Além dessas 
atividades, podem ser aplicadas um conjunto de atividades de apoio durante o processo, com o objetivo, por 
exemplo, de avaliar o controle do projeto.
Uma afirmação interessante sobre processo de desenvolvimento de software encontrada em 
Pressman e Maxim e mencionada pelo engenheiro de software americano Tom DeMarco é a 
seguinte: “Achamos que desenvolvedores de software não percebem uma verdade essencial: 
a maioria das organizações não sabe o que faz. Elas acham que sabem, mas não sabem” 
(PRESSMAN; MAXIM, 2016, p. 36).
5.2 Principais fluxos de processos de desenvolvimento de 
software
Tendo em vista as atividades genéricas que se fazem presentes em processos de software, faz-se necessário 
apresentar a definição do conceito de fluxo de processo. Podemos definir o fluxo do processo de desenvolvimento 
de sistemas como a forma como as atividades metodológicas são dispostas. Outra forma de visualizar seu 
significado é compreendê-lo como sendo maneiras de se organizarem ações e tarefas que fazem parte das 
atividades, com relação à ordem de execução e tempo. Fluxos de processo podem ser categorizados em quatro 
tipos: linear, iterativo, evolucionário e paralelo. 
O fluxo de processo de software linear executa cada uma das atividades metodológicas em sequência, uma 
seguida da outra, como se fossem uma série de atividades. Nesse fluxo, inicia-se pela etapa de comunicação e 
finaliza-se com a entrega do sistema ao cliente e a implantação no ambiente do usuário. A Figura 29 exemplifica 
o fluxo de processo linear.
Figura 29 – Fluxo de processo linear
Comunicação Planejamento Modelagem Construção Entrega
Fonte: Adaptada de PRESSMAN; MAXIM, 2016.
68
Metodologia de Desenvolvimento de Sistemas | Unidade 5 - Processos de MDS
Já o fluxo de processo iterativo organiza as atividades em uma sequência, como no fluxo linear, mas possui como 
diferença a característica de poder repetir uma ou mais atividades antes de prosseguir para a seguinte. Um 
exemplo de uma ilustração desse processo é mostrado na Figura 30.
Figura 30 – Fluxo de processo iterativo
Comunicação Planejamento Modelagem Construção Entrega
Fonte: Adaptada de PRESSMAN; MAXIM, 2016.
Um processo de software que segue o fluxo de processo evolutivo organiza as suas atividades de forma circular, 
de modo que a cada volta no círculo, passando pelas cinco atividades, um novo incremento do software seja 
produzido. Assim, o software é entregue por completo ao final de várias voltas. A Figura 31 demonstra esse 
processo.
Figura 31 – Fluxo de processo evolutivo
Liberado
por
Incremento
Planejamento
Comunicação
Entrega Construção
Modelagem
Fonte: Adaptada de PRESSMAN; MAXIM, 2016.
Por fim, o fluxo paralelo dispõe as atividades de modo que seja possível executar uma atividade em paralelo 
com outras. No caso do exemplo da Figura 32, a etapa de modelagem poderia ser realizada em paralelo com a 
construção de um outro aspecto do software.
69
Metodologia de Desenvolvimento de Sistemas | Unidade 5 - Processos de MDS
Figura 32 – Fluxo de processo paralelo
Comunicação Planejamento
Modelagem
Construção
Tempo
Entrega
Fonte: Adaptada de PRESSMAN; MAXIM, 2016.
Existem diversos mecanismos para a avaliação de processos de softwares, que possibilitam garantir com que o 
trabalho tenha sido feito de forma correta. Geralmente, essas métricas conseguem medir a “maturidade” do 
processo de software. Entretanto, a melhor forma de avaliar a qualidade de um processo de software é verificar 
a qualidade do software, o cumprimento de prazos e a viabilidade a longo prazo do sistema a ser desenvolvido. 
Esses quesitos conseguem dar uma ideia de forma precisa sobre a eficáciado processo de software utilizado. 
Sobre esse assunto, veremos mais detalhadamente na próxima seção. 
5.3 Métricas de processo e projeto de desenvolvimento de 
software
A medição do andamento do processo e do projeto de um software nos possibilita ter um mecanismo de avaliação 
objetiva para chegar a uma conclusão precisa sobre se os objetivos estipulados no princípio do desenvolvimento 
estão sendo atingidos. Como expressado em Pressman e Maxim, Lord Kelvin disse, certa vez:
Quando você pode medir o que você está falando e expressar em números, você sabe alguma coisa 
sobre aquilo; mas quando você não pode medir, quando você não pode expressar em números, o 
seu conhecimento é algo escasso e insatisfatório: pode ser o começo do conhecimento, mas você 
avançou muito pouco, em seu raciocínio, para o estágio de uma ciência (PRESSMAN; MAXIM, 
2016, p. 703).
As medições podem ser utilizadas no processo de software com o intuito de obter uma melhoria contínua no 
processo. Sua importância se dá, por exemplo, nas estimativas, na produtividade, controle de qualidade e no 
controle do projeto. Além disso, medições podem ser usadas na avaliação da qualidade dos artefatos produzidos 
a cada atividade executada, bem como podem ajudar na tomada de decisões em relação ao andamento do 
projeto. 
Uma equipe de software que está envolvida em um processo de software se preocupa, primariamente, com métricas 
de produtividade e qualidade. Essas métricas dizem respeito ao resultado do que foi feito em função do esforço 
70
Metodologia de Desenvolvimento de Sistemas | Unidade 5 - Processos de MDS
e tempo aplicados e à adequação para uso dos artefatos produzidos. Se o intuito da medição é planejamento e 
estimativa, o interesse nessas medidas é ao longo do tempo. De acordo com Pressman e Maxim (2016), algumas 
das perguntas que poderiam ser feitas são as seguintes:
• Com que nível de qualidade o software foi produzido? 
• De que maneira a produtividade passada e os dados referentes à qualidade podem beneficiar o presente?
• De que forma utilizar esses dados pode te ajudar a realizar estimativas e planos de maneira mais precisa?
Podemos compreender métricas de projeto e processo de software como medidas quantitativas que permitem 
à equipe de desenvolvimento a avaliação da eficácia do processo de software e os projetos que são executados 
usando o processo. O objetivo desses dados é compará-los com dados do passado, a fim de verificar se ocorreram 
melhorias tanto de qualidade quanto de produtividade. Além disso, métricas podem ser utilizadas para a detecção 
de áreas que possuam problemas para que possam ser corrigidas e o processo de software aprimorado. 
A tarefa de analisar e avaliar as métricas de software é destinada aos gerentes de software. Os dados para realizar 
essa análise geralmente são coletados por engenheiros de software. A importância de se utilizar métricas de 
processo e projeto de software é imensa. Caso esses dados não fossem medidos, a avaliação seria feita somente 
de forma subjetiva, não permitindo a existência de uma avaliação mais eficaz e precisa. Por meio da medição, é 
possível que tendências boas e ruins sejam constatadas e, assim, levar ao aprimoramento das estimativas com o 
passar do tempo. 
Para a medição do processo e projeto de software, é necessário, a princípio, um conjunto restrito de medidas de 
processo, projeto e produto que sejam coletadas com facilidade. Elas podem, por exemplo, ser normalizadas 
utilizando-se de métricas que são orientadas a tamanho ou função. O resultado da normalização é comparado 
com valores anteriores que foram obtidos em projetos similares. Por fim, são detectadas as tendências e obtidas 
as conclusões.
Uma forma de garantir com que o trabalho de medição de processo e projeto de software seja 
empregado de forma correta é utilizar um sistema de medições que seja consistente, porém 
simples, que nunca deve ser usado para avaliar, recompensar ou até mesmo punir indivíduos 
da equipe pelo seu desempenho pessoal.
Fique atento!
No livro de (PARK, 1996), que consiste em um guia para medições de software, são ressaltadas as razões pelas 
quais medimos:
1. Caracterizar, na busca por conhecer processos, produtos, recursos e ambientes, bem como para definir 
embasamento para futuras comparações.
2. Avaliar, a fim de estabelecer o status atual em comparação com o planejado.
3. Prever compreendendo a forma como processos se relacionam e modelando estas relações.
71
Metodologia de Desenvolvimento de Sistemas | Unidade 5 - Processos de MDS
4. Melhorar reconhecendo etapas, origens de problemas, inabilidades, dentre outros recursos que podem 
ser melhorados afim de aumentar a qualidade do processo e do produto.
Utilizada como ferramenta de gerenciamento, a medição proporciona discernimento ao gerente de projeto. Por 
consequência, a equipe de desenvolvimento, como um todo, tomará as melhores decisões que levarão a um 
projeto de sucesso. 
5.3.1 Métricas de processo x Métricas de projeto
Apesar de métricas de processo e projeto por muitas vezes serem as mesmas, é interessante destacar as 
características de cada uma delas. As métricas de processo são obtidas de todos os projetos que foram realizados 
por um longo período de tempo. Seu principal objetivo é o levantamento de indicadores de processo que resultam 
na melhoria do processo de software à longo prazo. Já as métricas de projeto permitem com que o gerente de 
projetos: avalie o andamento do projeto, traçe potenciais riscos, descubra possíveis áreas problemáticas com 
antecedência, realize ajustes no fluxo de tarefas e avalie a habilidade da equipe de projeto no controle de 
qualidade do software final. 
Na maior parte das vezes, as mesmas métricas são utilizadas tanto no domínio do processo quando no domínio 
do projeto. Exemplo disso pode ser visto nas seções 5.3.2 e 5.3.3 onde serão abordados dois tipos de métricas de 
software que podem ser utilizadas tanto como métrica de processo quanto métrica de projeto.
Métricas de processo possuem impacto a longo prazo e seu objetivo consiste em melhorar 
o próprio processo. As métricas de projeto frequentemente acabam contribuindo para o 
desenvolvimento de métricas de processo. 
Saiba mais
Não se deve utilizar métricas para comparar indivíduos ou equipes do desenvolvimento de 
um software, visto que existem muitos fatores que afetam o processo.
Fique atento!
5.3.2 Métricas orientadas a tamanho
Para compreender as métricas orientadas a tamanho, vamos primeiro analisar um exemplo de situação. Suponha 
que os membros de duas equipes de projetos diferentes, equipe X e equipe Y, registrem todos os erros encontrados 
durante o processo de software dos seus respectivos projetos. As medidas dos membros de cada equipe são 
combinadas a fim de obter uma medida por equipe. A equipe X encontrou 330 erros durante o processo de 
72
Metodologia de Desenvolvimento de Sistemas | Unidade 5 - Processos de MDS
software. Já a equipe Y encontrou 170. Sendo iguais em todas as características restantes, qual foi a equipe mais 
eficaz na descoberta de erros no processo? Esta é uma pergunta difícil de se responder, visto que não se sabe o 
tamanho ou a complexidade do projeto de cada equipe. Entretanto, se normalizarmos as medidas, poderíamos 
comparar os valores obtidos por ambas as equipes de maneira mais justa.
Métricas de software orientadas a tamanho são estabelecidas com base em medidas de qualidade ou 
produtividade que são normalizadas considerando o tamanho do software desenvolvido. Dessa forma, se uma 
organização preserva um registro com o histórico dos projetos desenvolvidos, a elaboração de uma tabela de 
medidas orientadas a tamanho se torna possível, como ilustra a Tabela 2 a seguir.
Tabela 2 – Métricas orientadas a tamanho
Projeto Linhas de Código Esforço Custo Pág. Doc. Erros Defeitos Pessoas
Alfa 12100 24 168 365 134 29 3
Beta 27200 62 440 1224 321 86 5
Gama 20200 43 314 1050 256 64 6
... ... ... ... ... ... ... ...
Fonte:Adaptada de PRESSMAN; MAXIM, 2016.
No exemplo da figura acima, temos o registro de cada um dos projetos que foi desenvolvido por determinada 
organização ao longo dos anos e algumas medidas que correspondem a eles. Considere, por exemplo, a linha 
correspondente ao projeto denominado Alfa. Esse projeto resultou em 12.100 linhas de código, tendo a 
contribuição de 24 pessoas/mês e o custo de 168 mil dólares. É importante notar que tanto o trabalho quanto 
o custo na tabela correspondem a todas as atividades de engenharia de software, não contemplando apenas a 
etapa de codificação. Além disso, outras informações a respeito desse projeto é que foram criadas 365 páginas 
de documentação, 134 erros foram encontrados durante o processo de software todo e 29 defeitos foram 
apresentados após a entrega do software para o cliente no primeiro ano do sistema em operação. Por fim, na 
parte de codificação do software, três pessoas estavam envolvidas. 
Partindo da Tabela 2, é possível escolher, por exemplo, o número de linhas de código como um valor de 
normalização. Seguem abaixo alguns exemplos de métricas simples orientadas a tamanho que poderiam ser 
utilizadas normalizando pelo número de linhas de código:
• Erros por MLDC (1.000 linhas de código).
• Defeitos por MLDC.
• Custo por MLDC.
• Páginas de documentação por MLDC.
Além disso, outras métricas interessantes seriam:
• Erros por pessoa-mês.
• MLDC por pessoa-mês.
• Custo por página de documentação.
73
Metodologia de Desenvolvimento de Sistemas | Unidade 5 - Processos de MDS
Apesar da ampla utilização das métricas orientadas a tamanho, ainda existe um grande 
debate sobre sua validade e aplicabilidade.
Saiba mais
Métricas orientadas por tamanho são simples e rápidas. Entretanto, nem sempre são aceitas como a melhor 
forma de medir processos de software. A maior razão para isso é o fato de elas utilizarem as linhas de código 
como principal medida. Os defensores da utilização da medida LDC (linhas de código) alegam que LDC é uma 
característica que qualquer projeto de desenvolvimento de software possui e, por isso, pode ser facilmente obtida. 
Além disso, diversos modelos para estimativa de software existentes recebem como entrada LDC e diversos 
métodos da literatura e dados já utilizam LDC. 
Em contrapartida, oponentes da medida afirmam que LDC é bastante dependente da linguagem de programação 
e, na avaliação de produtividade, programas bem projetados e menores seriam penalizados, linguagens 
procedurais não poderiam ser utilizadas com essas métricas. Também defendem que a estimativa de LDC é algo 
difícil de planejar, visto que no princípio do projeto é difícil ter uma noção do número de linhas que o código 
conterá.
5.3.3 Métricas orientadas a função
Outra métrica que utiliza a normalização de medidas é a métrica de software orientada a função. A diferença em 
relação à métrica orientada a tamanho é o fato de que a normalização na métrica orientada a função acontece 
usando uma medida da funcionalidade fornecida pelo sistema como valor de normalização. A métrica orientada 
a função mais utilizada atualmente é a Pontos de Função (Function Point – FP). O cálculo de pontos de função 
tem como base as características de domínio de informação e a complexidade do software. 
Assim como LDC, a utilização do ponto de função como métrica é, por vezes, bastante controverso. Os defensores 
da métrica afirmam que essa função é independente da linguagem de programação, o que faz ela ser ideal para 
aplicações com diferentes linguagens. É ideal que elas sejam convencionais ou não procedurais e que a métrica 
é baseada em dados com grandes chances de serem conhecidos na evolução de um projeto. Sendo assim, FP 
se torna mais atraente na elaboração de estimativas. Já os oponentes à métrica alegam que é necessário um 
pouco de “jeitinho” no método, visto que ele é baseado em dados subjetivos em vez de objetivos, as contagens 
do domínio de informações podem ser algo difícil de ser computado. Também alegam que a FP é apenas um 
número, não tendo significado físico claro.
Existem diversos tipos de métricas aqui não abordados. Para determinar a melhor métrica 
para um processo de software específico, é necessário analisar o contexto em que o software 
está sendo desenvolvido e sua aplicação final. 
Saiba mais
74
Metodologia de Desenvolvimento de Sistemas | Unidade 5 - Processos de MDS
5.4 O processo unificado
De acordo com o livro que deu origem ao processo unificado (JACOBSON, 1999), o mesmo foi fruto de uma busca 
por um processo de software que fosse “dirigido a casos de uso, centrado na arquitetura, iterativo e incremental”. 
Entre as características do processo unificado, está o fato de ele buscar o aproveitamento dos melhores recursos 
e características dos modelos tradicionais de desenvolvimento de software, enquanto os adapta de modo a 
implementar muitos dos princípios do desenvolvimento ágil de software. Além disso, o processo unificado tem 
por característica o reconhecimento da importância da comunicação com o cliente e de métodos racionalizados 
que possam descrever a visão do cliente sobre o sistema desejado (ex.: casos de uso). Por fim, enfatiza o papel 
da arquitetura de software, o que ajuda o arquiteto a ter foco nas metas corretas, e sugere um fluxo de processo 
iterativo e incremental, de forma que dá uma sensação evolucionária necessária no desenvolvimento moderno. 
Em meados de 1990, James Rumbaugh, Grady Booch e Ivar Jacobson começaram a trabalhar em um método 
unificado que combinasse as melhores características de cada um dos métodos individuais de análise e 
projeto orientados a objetos. O resultado foi a Linguagem de Modelagem Unificada (UML), que é utilizada até 
os dias atuais para modelar sistemas. Em 1997, a UML se tornou de fato um padrão no desenvolvimento de 
softwares orientados a objetos. Durante os anos que se seguiram, os três autores da UML desenvolveram o 
Processo Unificado (UP), um método de engenharia de software orientada a objetos utilizando UML. Atualmente, 
tanto o processo unificado quanto a UML são amplamente utilizados.
5.4.1 Fases do processo unificado
O processo unificado pode ser descrito utilizando as atividades genéricas abordadas na Seção 5.1, que são úteis em 
quaisquer processos. A fase de concepção envolve as atividades de comunicação com o cliente e planejamento. 
Nessa fase, com a colaboração de clientes, as necessidades de negócio do software são identificadas e propõe-se 
uma arquitetura simples para os sistemas, além de se desenvolver um planejamento para a natureza iterativa e 
incremental do projeto. A fase de elaboração envolve as atividades de comunicação e modelagem do modelo 
de processo genérico. Nessa fase, são refinados e expandidos os casos práticos preliminares desenvolvidos na 
concepção. Divide-se a visão da arquitetura em cinco modelos: modelo de caso prático, modelo de requisitos, 
modelo de projeto, modelo de implementação e modelo de emprego. Na elaboração, há também uma revisão 
do plano de forma bastante cuidadosa para ver se não é necessária alguma alteração. 
A fase de construção é idêntica à atividade genérica de construção definida para um processo de software 
qualquer. Sua entrada é o modelo de arquitetura. Essa fase desenvolve ou agrega componentes de software, 
de forma que cada caso prático se torne uma funcionalidade no sistema. Modelos de requisitos e projeto são 
finalizados e implementam-se no código-fonte todas as funções exigidas para o incremento de software. 
A fase de transição engloba os últimos estágios da atividade de construção e a primeira parte da atividade de 
emprego/entrega, consistindo na entrega e no feedback do usuário. Testes beta com usuário são realizados na 
busca de encontrar defeitos ou mudanças necessárias no software. Manuais técnicos e de usuários são elaborados, 
e nessa fase o resultado é uma versão utilizável do software. Por fim, a fase de produção consiste na fase final 
do emprego/entrega do software.Essa fase engloba o monitoramento da utilização do software pelo usuário, 
enquanto disponibiliza-se suporte ao mesmo, implementando e analisando relatórios de defeitos ou mudanças. 
A Figura 33 ilustra as fases do processo unificado, bem como as atividades genéricas existentes nos processos de 
software.
75
Metodologia de Desenvolvimento de Sistemas | Unidade 5 - Processos de MDS
Figura 33 – O processo unificado
Planejamento
Comunicação
Modelagem
ConstruçãoEntrega/
Emprego
Incremento de
Software
Produção
Transição
Versão
Concepção
Elaboração
Construção
Fonte: Adaptada de PRESSMAN; MAXIM, 2016.
Síntese da unidade
Esta unidade abordou o conceito de processo de desenvolvimento de softwares e conceitos relacionados, tais 
como: principais fluxos de processo, métricas de processo e projeto de software e o processo unificado.
76
Considerações finais
A compreensão do processo de desenvolvimento de software é essencial 
para sua utilização de forma eficaz e eficiente, porque possibilita 
que decisões sejam tomadas de forma mais precisa. Desse modo, 
evitam-se prejuízos, tanto em termos de tempo quanto em termos 
financeiros, levando o software desenvolvido a atender às expectativas de 
negócio da organização. 
77
 6Unidade 66. Tipos MDS 
Para iniciar seus estudos
Nesta unidade, você compreenderá duas implementações de processos 
bastante utilizadas nas organizações que desenvolvem softwares em 
grande escala: o RUP e o Scrum. A decisão sobre qual será o melhor 
para determinado contexto só é possível após uma análise clara das 
características de cada um deles em conjunto com as características do 
projeto e da organização. Conhecê-los permitirá a você realizar escolhas 
bem mais assertivas em projetos futuros.
Objetivos de Aprendizagem
• Definir duas das implementações de processo mais utilizadas 
atualmente, o RUP, representando um processo unificado, e o 
Scrum, ilustrando um processo ágil. 
78
Metodologia de Desenvolvimento de Sistemas | Unidade 6 - Tipos MDS 
Introdução da unidade
Apesar de existirem atividades genéricas que são comuns à maioria dos processos de desenvolvimento de 
software, a implementação de um processo pode se dar de diferentes formas. Esta unidade visa apresentar dois 
exemplos de implementações de processo: o RUP, representando processos unificados, e o SCRUM, representando 
processos ágeis. A principal característica de um processo unificado é o fato de ele combinar características 
que estão presentes em diferentes modelos. Já os métodos ágeis têm por característica principal a agilidade na 
entrega de uma versão em funcionamento ao cliente. Com o conhecimento de ambas abordagens, será possível 
que você compreenda as principais características, vantagens, desvantagens e descubra onde e como aplicá-las.
6.1 Tipos MDS
Esta unidade possui como foco apresentar dois tipos de implementação de processos, o Rational Unified Process 
(RUP), um processo unificado, e o Scrum, representando um processo ágil. Primeiramente, serão apresentadas 
as definições do RUP, bem como suas vantagens e desvantagens. Em seguida, serão abordados os conceitos 
incorporados ao Scrum, bem como os papéis, responsabilidades e artefatos presentes nele.
6.1.1 Rational Unified Process (RUP)
O Rational Unified Process (RUP) pode ser visto como uma instância específica e detalhada do processo unificado 
(KRUCHTEN, 2003). Consistindo em um processo moderno, suas origens estão na Unified Modeling Language 
(UML) e no processo unificado (JACOBSON, 1999). Sua criação foi idealizada pela Rational Software Corporation. 
Entretanto, em fevereiro de 2003, foi adquirido pela IBM. Pode-se dizer que o RUP é um processo híbrido, visto 
que reúne diversas características de modelos genéricos. A Figura 34 mostra uma fotografia de Philippe Kruchten, 
autor do RUP, durante um evento de engenharia de software.
Figura 34 – Philippe Kruchten (à direita), o engenheiro de software canadense precursor do RUP
Fonte: Foto de Artem Marchenko, 2008.
79
Metodologia de Desenvolvimento de Sistemas | Unidade 6 - Tipos MDS 
O RUP normalmente enxerga o processo em três perspectivas:
1. Perspectiva dinâmica: mostra as fases do modelo no decorrer do tempo.
2. Perspectiva estática: mostra as atividades realizadas durante o processo.
3. Perspectiva prática: sugere práticas que sejam boas para o processo.
São quatro as fases do modelo RUP para um processo de software. Diferentemente de um modelo cascata, por 
exemplo, as fases no RUP são relacionadas ao negócio, e não a assuntos técnicos. A Figura 35 exemplifica as fases 
existentes no modelo de processo RUP.
Figura 35 – Fases que constituem o Rational Unified Process
Iteração de Fase
Concepção Elaboração Construção Transição
Fonte: Adaptada de SOMMERVILLE, 2007.
A fase concepção tem como principal objetivo o estabelecimento de um caso de negócio para o projeto. Casos de 
negócio consistem nas ideias de um projeto ou tarefa. Nessa fase, é necessária a identificação do que chamamos 
de entidades externas, que são pessoas ou sistemas que vão interagir com o software. Tendo essa informação, 
avalia-se o quanto o software a ser construído vai contribuir para o negócio. Caso conclua-se que sua importância 
é pequena, sua construção pode ser abortada. 
A fase elaboração tem como finalidade a compreensão do problema a ser solucionado através do software, bem 
como o estabelecimento da arquitetura do sistema, do plano do projeto e da identificação dos principais riscos 
do projeto. O resultado dessa fase é um modelo de requisitos para o sistema. Esse modelo pode ser representado 
com diagramas de casos de uso UML, uma descrição da arquitetura ou até mesmo um plano de desenvolvimento 
do software. 
Na fase de construção, o sistema é projetado, codificado e testado. As partes do sistema são desenvolvidas em 
paralelo e, ao final, integradas. O resultado da fase de construção é um software já em estado de funcionamento, 
contendo uma documentação que pode ser entregue aos usuários para que já consigam fazer uso do sistema. 
A fase final do RUP denomina-se transição. Nessa fase, é realizada a transferência do sistema do ambiente 
de desenvolvimento para o ambiente em que o sistema atuará de fato, ou seja, o ambiente do usuário ou de 
produção. Diversos modelos de processo de software ignoram essa etapa, visto que é uma atividade cara, que 
costuma gerar problemas. Entretanto, possui grande importância na construção de um software de sucesso. O 
resultado dessa fase é um sistema documentado já funcionando de forma correta no ambiente do usuário ou de 
produção. 
Conforme ilustrou a Figura 35, a característica iterativa do modelo RUP se dá de duas maneiras. A primeira é que 
cada fase pode ser executada em iterações, sendo aplicada a um novo incremento a cada iteração. A segunda 
é a execução do conjunto de fases de forma incremental, na qual o conjunto de fases atua sob um mesmo 
incremento a cada iteração. 
80
Metodologia de Desenvolvimento de Sistemas | Unidade 6 - Tipos MDS 
A perspectiva estática, anteriormente mencionada, dá visibilidade às atividades que ocorrem ao longo do 
processo. Essas atividades no RUP são denominadas workflows. No total, são seis workflows centrais, identificados 
no processo, e três workflows de apoio. Como RUP foi pensado baseado na UML, a descrição do workflow é em 
torno de modelos UML. O Quadro 5 descreve os workflows.
Quadro 5 – Workflows estáticos no RUP
Workflow Descrição
Modelagem de negócios Utilização dos casos de uso de negócios para 
modelagem dos processos de negócios. 
Requisitos Identificação dos atores que interagem com o 
sistema e desenvolvimento dos casos de uso que 
modelam os requisitos do sistema. 
Análise e Projeto Modelos de arquitetura, modelos de componentes, 
modelos de objetos e modelos de sequência são 
utilizados para a criação e documentação do 
modelo de projeto. 
Implementação A implementação dos componentes é realizada 
bem como a estruturação destes componentes 
em subsistemasde implementação. Esse processo 
pode ser acelerado através da geração de código 
automático usando modelos de projeto. 
Teste Realizado à cada iteração, é executado em conjunto 
com a implementação. O teste segue a conclusão 
da implementação. 
Implantação Uma versão do sistema é criada, entregue ao 
usuário para instalação no seu ambiente de 
utilização. 
Gerenciamento de configuração e mudanças 
(apoio)
Apoia o gerenciamento das mudanças no sistema. 
Gerenciamento de projeto (apoio) Apoia o gerenciamento do desenvolvimento de 
software. 
Meio ambiente (apoio) Está associado à disponibilização dos recursos 
necessários à equipe de desenvolvimento. 
Fonte: Adaptado de SOMMERVILLE, 2007.
A vantagem da visualização de perspectivas estáticas e dinâmicas é que as fases do RUP não estão diretamente 
associadas a workflows (atividades) específicos. Sendo assim, diversos workflows podem estar ativos em todas as 
fases do processo. Em fases iniciais, será comum um esforço maior dos workflows relacionados à modelagem e 
requisitos do software. Já nas fases finais, serão comuns os workflows relacionados à teste e implantação. 
81
Metodologia de Desenvolvimento de Sistemas | Unidade 6 - Tipos MDS 
A perspectiva prática do RUP sugere e descreve uma sequência de boas práticas de engenharia de software para 
utilização durante o processo de desenvolvimento de software. De acordo com Sommerville (2007), seis boas 
práticas são recomendadas:
Quadro 6 – Boas práticas recomendadas no RUP
Prática Descrição
Desenvolver software iterativamente Analisar as prioridades do cliente para planejar 
incrementos do sistema. Desenvolver recursos com 
alta prioridade primeiro. 
Gerenciar requisitos Realizar a documentação dos requisitos e 
acompanhamento das suas mudanças. Somente 
aceitar mudanças após analisar seus impactos. 
Usar arquiteturas baseadas em componentes Utilizar componentes na estruturação da 
arquitetura do sistema. 
Modelar o software visualmente Representar as perspectivas estáticas e dinâmicas 
do sistema usando modelos gráficos da UML. 
Verificar a qualidade do software Garantir que o software atenda aos padrões de 
qualidade da empresa. 
Controlar as mudanças do software Utilizar um sistema de gerenciamento de mudanças 
e ferramentas de gerenciamento de configuração. 
Fonte: Adaptado de SOMMERVILLE, 2007.
Nem todos os tipos de desenvolvimento podem se adequar ao RUP, como o desenvolvimento de software embutido. 
No entanto, ele pode se adequar a diversas situações, porque combina três modelos de processo genéricos: cascata, 
iterativo e incremental. O que o RUP traz de mais novo entre os processos existentes é a separação de fases e 
workflows (atividades) e o fato de incluir a implantação do sistema no ambiente do usuário como parte do processo.
Fases são dinâmicas e possuem metas. Workflows são estáticos e são atividades técnicas, que podem estar 
associados a mais de uma fase e ser utilizados ao longo de todo o processo de desenvolvimento, com o objetivo 
de atingir metas específicas. A Figura 36 ilustra o andamento das atividades (workflows) ao longo do processo. É 
possível perceber na figura em quais fases do RUP existem maiores demandas/esforços de cada workflow.
82
Metodologia de Desenvolvimento de Sistemas | Unidade 6 - Tipos MDS 
Figura 36 – Fases (colunas) e workflows (linhas) que constituem o RUP
Modelagem de Negócio
Iniciação
I2 E1 E2 C1 C2 C3 C4 T1 T2
Elaboração Construção Transição
Requisitos
Análise e Design
Implementação
Teste
Implantação
Fonte: Adaptada de SOMMERVILLE, 2007.
6.1.2 Vantagens x Desvantagens da implementação do RUP
Entre as diversas vantagens dos modelos RUP, podemos citar o fato de que sua natureza iterativa e incremental 
ajuda a suavizar riscos precoces, fazendo com que erros sejam corrigidos assim que detectados (PRESSMAN; 
MAXIM, 2016). A visibilidade do progresso também fica mais clara, visto que se tem um sistema em funcionamento 
muito cedo. Outra vantagem é seu foco no comprometimento com o usuário, pelas constantes verificações sobre 
se o sistema está atendendo às suas expectativas. Podemos também citar a questão do aumento da produtividade 
e a diminuição do número de defeitos encontrados.
É importante destacar a diferença entre erros e defeitos. Erros são problemas encontrados 
ao longo do processo de desenvolvimento de software. Defeitos são problemas encontrados 
pelo usuário durante o real funcionamento do sistema em seu ambiente.
Fique atento!
Por fim, podemos também citar como um benefício da utilização do RUP a possibilidade de um maior controle 
da complexidade do sistema. Em sistemas grandes, por vezes, se torna difícil um controle maior sobre sua 
complexidade. Como o RUP constrói o sistema de forma incremental, é possível ir verificando ao longo das iterações 
se o sistema não está se tornando complexo demais. Se for o caso, simplificações podem ser implementadas.
Existem também algumas limitações trazidas pela utilização do RUP. Em projetos de pequeno porte, pode não 
ser viável a sua aplicação, visto que ele se torna complexo e trabalhoso, além da possibilidade de realizar um 
investimento em suporte. Outra questão é que a utilização do RUP de maneira eficaz exige uma certa experiência 
da equipe, o que só é possível de se obter após anos de utilização. Os benefícios com o RUP geralmente não vêm 
de forma imediata. A equipe deve ser bem treinada, a metodologia deve ser adaptada ao contexto no qual será 
utilizada e leva certo tempo até que a metodologia seja absorvida de maneira ideal pela equipe.
83
Metodologia de Desenvolvimento de Sistemas | Unidade 6 - Tipos MDS 
6.2 Scrum
O Scrum foi desenvolvido primariamente como uma forma de gerenciar projetos para organizações que fabricavam 
carros e produtos de consumo. Sua proposta foi realizada no artigo “The new product development game”, escrito 
por Hirotaka Takeuchi e Ikujiro Nonaka e publicado no ano de 1986 (TAKEUCHI; NONAKA, 1986). Eles perceberam 
que os projetos nos quais havia pequenas equipes com indivíduos com capacidades multidisciplinares obtinham 
maior sucesso. Então acabaram associando essas equipes à formação Scrum em jogos de rugby, esporte bastante 
popular nos Estados Unidos, devido a algumas semelhanças encontradas com o jogo. 
Figura 37 – Exemplo da jogada Scrum do rugby
Fonte: SHUTTERSTOCK, 2018.
No esporte denominado rugby, a palavra “Scrum” é o nome de uma jogada que tem por 
objetivo a reposição de bola em disputa. Ela é utilizada para o reinício do jogo em alguns 
casos.
Saiba mais
Passado algum tempo, no ano de 1993, Jeff Sutherland, John Scumniotales e Jeff McKenna, da empresa Easel 
Corporation projetaram, documentaram e implementaram o Scrum da forma como ele é hoje, baseando-se nas 
ideias do artigo de Takeuchi e Nonaka. Ken Schwaber, em 1995, era CEO da Advanced Development Methods 
e formalizou a definição do Scrum para apresentação em uma conferência de orientação a objetos, a Ospsla, 
em Austin, no Texas, e ajudou na implantação desse método no desenvolvimento de softwares em diversas 
organizações. Suas definições podem ser encontradas no artigo “Scrum development process” (SCHWABER, 1997). 
O Scrum pode ser compreendido como uma metodologia ágil que tem como principal finalidade o gerenciamento 
de projetos de software, tarefa que vem realizando com sucesso. Apesar de hoje sua aplicação se dar em maior 
escala no âmbito do desenvolvimento de software, teoricamente, o Scrum pode ser aplicado em diversos contextos 
em que um conjunto de pessoas necessitem trabalhar juntas a fim de atingir determinado objetivo. 
84
Metodologia de Desenvolvimento de Sistemas | Unidade 6 - Tipos MDS 
O foco da abordagem Scrum é controlar processos empíricos priorizando a entrega de valor do negócio no menor 
prazo possível. Projetos dentro do Scrum se dividem em ciclos curtos que se repetem (iteração) para que seja 
possível realizar modificações e adaptações, de forma a corrigir possíveis desvios (incremental). Osciclos, que 
podem durar entre duas e quatro semanas, são denominados sprints.
Processos empíricos são baseados a partir de experiência obtida e da utilização do que é 
conhecido para realizar tomada de decisões.
Saiba mais
Visto como uma abordagem ágil, o fato de o Scrum carregar características de natureza incremental e iterativa 
permite que sejam otimizadas a previsibilidade e a gestão de riscos do projeto. O controle de um processo 
empírico, como no Scrum, é baseado em três pilares de sustentação, como mostra o Quadro 7.
Quadro 7 – Pilares de sustentação do controle de processos empíricos
Pilar Descrição
Transparência
Define que aspectos relacionados ao processo, que afetam o resultado, devem 
ser visíveis aos que controlam os resultados. Em outras palavras, deve existir 
um padrão comum entre quem construiu um sistema e quem inspecionou o 
resultado para que a definição de pronto seja a mesma para ambos. 
Inspeção
Define que processos devem estar em constante inspeção para que variações 
sejam detectadas. Essas variações no processo podem ser causadas até mesmo 
pelo ato de inspeção. É importante ressaltar que a inspeção não deve ser tão 
frequente a ponto de prejudicar o andamento do projeto. A inspeção deve ser 
aplicada por inspetores especializados. 
Adaptação
Se a inspeção detectar que existe uma variação que está fora dos limites aceitáveis, 
o processo ou o material produzido deve ser ajustado assim que possível. Para 
contribuir com a inspeção e adaptação, o Scrum possui quatro eventos formais: 
reunião de planejamento da sprint, reunião diária, reunião de revisão da sprint e 
retrospectiva da sprint.
Fonte: Adaptado de CRUZ, 2015.
Entre as principais vantagens do Scrum, podemos citar a grande motivação partindo dos membros da equipe, 
devido ao interesse em realizar a entrega das sprints (entregas incrementais) no prazo. Como o projeto fica descrito 
em um quadro, sua visualização é facilmente realizada, deixando mais claros os objetivos a todos os membros 
da equipe. Além disso, no Scrum a qualidade é mais importante que o prazo de entrega. Geralmente, o produto 
resultante das sprints possuem poucos erros. Por fim, também é possível alterar as prioridades das entregas, caso 
alguma mudança no contexto tenha gerado isso. 
Existem também algumas limitações associadas à utilização do Scrum. Como o Scrum visa bastante à qualidade 
do produto, isso pode acabar resultando no não cumprimento de prazos estipulados no começo do projeto. Outra 
questão é o fato de que no Scrum pode haver uma espécie de desordem nas funções, visto que elas não estão 
bem definidas no projeto, deixando, por exemplo, programadores confusos quanto à realização de suas tarefas. 
85
Metodologia de Desenvolvimento de Sistemas | Unidade 6 - Tipos MDS 
Por fim, no Scrum há uma certa ausência em termos de documentação, quando comparado às metodologias 
tradicionais. Isso pode causar problemas quando é necessário voltar a um determinado ponto do projeto e esse 
ponto não está documentado.
6.2.1 Papeis e responsabilidades no Scrum
A equipe que está envolvida no Scrum é chamada de time. Geralmente, é bem pequena e realiza eventos (tarefas) 
que possuem curta duração a cada ciclo, a fim de construir o produto final. A definição clara dos papéis de cada 
um no time do Scrum é fundamental para o sucesso de sua aplicação. O time do Scrum é constituído por três 
papéis: Scrummaster, Product Owner e o time de desenvolvimento.
Scrummaster
O Scrummaster tem a responsabilidade de garantir que a ideia do Scrum seja compreendia e aplicada por todos 
da equipe, de forma que o time adira aos valores, práticas e regras do Scrum. A função do Scrummaster também 
é treinar o time, de modo a levá-lo a ser mais produtivo e a desenvolver produtos de maior qualidade. Entre os 
praticantes, o Scrummaster é chamado de servo-líder do time. A Figura 38 apresenta um ilustração do Scrummaster. 
Figura 38 – Scrummaster no Scrum
Fonte: SHUTTERSTOCK, 2018.
É também papel do Scrummaster ajudar o time de desenvolvimento a compreender e utilizar o conceito 
de autoorganização e interdisciplinaridade. Entretanto, não é função do Scrummaster gerenciar o time de 
desenvolvimento. O que o Scrummaster faz, em suma, é treinar o time de desenvolvimento quando ele ainda não 
é bem compreendido, removendo quaisquer impedimentos que atinjam os objetivos estabelecidos.
86
Metodologia de Desenvolvimento de Sistemas | Unidade 6 - Tipos MDS 
Apesar de ser possível que o Scrummaster seja um membro do time de desenvolvimento, isso 
não é adequado, porque pode levar à confusão devido a ele ter de desempenhar tarefas em 
ambos os papéis.
O Scrummaster nunca deve ser o Product Owner, visto que os conflitos gerados devido a isso 
seriam muito grandes.
Fique atento!
Em processos controlados pelo Scrum, não existe um gerente ou um coordenador para liderar o projeto. Existe o 
Scrummaster, que é uma espécie de coach, ou seja, uma pessoa que apesar de não gerenciar o time, dá orientações, 
de forma a guiá-lo para direções assertivas. Um técnico de futebol, apesar de dar as instruções para os jogadores 
e poder interferir quando necessário, após o início do jogo os jogadores são os responsáveis por colocar as 
instruções em prática. O Scrummaster possui papel semelhante. As interferências podem ser, por exemplo, sobre 
regras não cumpridas, fuga do time das técnicas ágeis e até mesmo de etapas que não foram realizadas. Apesar 
do sucesso da aplicação do Scrum não ser totalmente dependente do Scrummaster, pode-se dizer que ele é o 
papel mais importante do Scrum. 
Product Owner
O Product Owner é o único responsável por gerenciar o backlog do produto (artefato que será definido na Seção 
6.2.2) e por garantir com que o trabalho desenvolvido pelo time tenha valor agregado. Ele também faz com 
que o backlog esteja visível a todos. Sendo o dono do produto, é ele quem tenta entender o negócio do produto 
e fazer com que o time também compreenda de forma que o produto esteja de acordo com o que o cliente 
deseja. Ele defende e prioriza os valores descritos no backlog de produtos. Dentre as responsabilidades do Product 
Owner, podemos citar as seguintes: a maximização do valor do produto e do trabalho do time desenvolvimento; 
a expressão clara dos itens que compõem o backlog em ordem de prioridade que defina as expectativas do 
cliente; assegurar que o trabalho realizado pelo time de desenvolvimento seja de valor; assegurar que o backlog 
do produto seja claro e transparente a todos os interessados; e garantir a compreensão do backlog pelo time 
desenvolvimento para que o que esteja sendo construído seja o que realmente o cliente espera. 
O Product Owner desempenha o papel mais importante para a compreensão das expectativas do cliente sobre 
o produto final. Um excelente time de desenvolvimento pode acabar construindo um sistema erroneamente 
que não atende às expectativas do negócio do cliente se o Product Owner não desempenhar seu papel de forma 
correta. A Figura 39 ilustra as tarefas de um Product Owner.
87
Metodologia de Desenvolvimento de Sistemas | Unidade 6 - Tipos MDS 
Figura 39 – Product Owner no Scrum
Fonte: SHUTTERSTOCK, 2018.
O Product Owner deve ser uma pessoa, e não um grupo de pessoas que tomam as decisões.
Fique atento!
Time de Desenvolvimento
É responsável por realizar o desenvolvimento e fazer com que o backlog do produto (com seus requisitos) se 
transforme em incrementos de funcionalidades, que, juntos formam o sistema que será entregue ao cliente. Todos 
os trabalhos técnicos que estão envolvidos no desenvolvimento são realizados pelo time de desenvolvimento, 
que deve ser multidisciplinar. Apesar de os integrantes do time possuírem habilidades específicas, todos são 
denominados desenvolvedores e a responsabilidade de uma entrega continua sendo de todos. E, para tanto, o 
time, por si só, deve se organizar para decidir como fará isso. As decisões dos desenvolvedores são em relação a 
tecnologias, arquiteturasde softwares, designers, melhores padrões de código e tudo o que envolva a construção 
de um sistema com maior qualidade e de forma que sempre seja possível ter uma versão do sistema já em 
funcionamento. 
O time de desenvolvimento desempenha o papel que mais afeta na qualidade técnica e funcional do produto 
final. O número de pessoas no time não deve ser muito grande, mas deve ter o tamanho suficiente para ser 
ágil e conseguir completar uma parcela significativa do trabalho sem estender os limites da sprint. Geralmente, 
o número de pessoas varia entre três e nove integrantes. Um número grande de pessoas dificulta que todos 
tenham conhecimento real em relação ao que está sendo construído, além de ser mais difícil de coordenar. A 
Figura 40 ilustra um time Scrum e seus membros. Na parte inferior, há destaque para o time de desenvolvimento.
88
Metodologia de Desenvolvimento de Sistemas | Unidade 6 - Tipos MDS 
Figura 40 – Time do Scrum
Fonte: SHUTTERSTOCK, 2018.
6.2.2 Artefatos do Scrum
Artefatos são os objetos utilizados e manipulados pelos diferentes papéis no Scrum ao longo do processo. Os 
artefatos só Scrum incluem o backlog, o burndown e o taskboard. 
Backlog
No Scrum, o backlog compreende os requisitos que o sistema deverá ter, bem como o entendimento necessário 
para que os requisitos sejam atendidos, funcionalidades, desenvolvidas, e o produto, entregue. Em suma, ele 
pode ser visto como uma lista com todas as funções, características, melhorias, tecnologias e correções que 
constituem as próximas versões de um produto. O backlog pode ser classificado em três conjuntos:
• Backlog do produto: backlog completo que será trabalhado ao longo do projeto.
• Backlog da versão de entrega: fragmento do backlog que deverá ser entregue na próxima versão do 
sistema.
• Backlog da sprint: fragmento do backlog que será considerado para trabalhar em determinada sprint (ou 
ciclo de desenvolvimento). 
Burndown
O burndown é um gráfico que ilustra de forma visual o somatório das estimativas de esforços restantes do backlog. 
Dessa forma, é possível fazer uma comparação com o que se estimou e o esforço que de fato foi dispensado. O 
burndown pode ser esboçado tanto para o backlog do produto quanto para o backlog da sprint. 
Taskboard
O taskboard é um quadro de tarefas colocado na parede, em que: na primeira coluna, o time coloca as estórias 
– descrição resumida de uma funcionalidade requerida pelo cliente –; na segunda coluna, as tarefas contidas 
89
Metodologia de Desenvolvimento de Sistemas | Unidade 6 - Tipos MDS 
na estória que ainda devem ser feitas; na terceira coluna, as tarefas que estão sendo feitas; na quarta coluna as 
tarefas que necessitam ser testadas; na última, as tarefas finalizadas. A ideia de usar algo visual para representar 
o andamento do projeto é bastante eficiente para deixar clara sua situação. A Figura 41 ilustra um exemplo de 
taskboard.
Figura 41 – Exemplo de taskboard
Fonte: SHUTTERSTOCK, 2018.
Síntese da unidade
Esta unidade abordou implementações de dois tipos de processo, o RUP, ilustrando um processo unificado, e o 
Scrum, ilustrando um processo ágil. As principais características de ambas as implementações foram destacadas 
ao longo da unidade. 
90
Considerações finais
Scrum e RUP são duas das implementações de processo mais utilizadas 
atualmente. Compreendendo suas definições, você estará, sem dúvidas, 
mais preparado para o mercado.
91
 7Unidade 77. Qualidade em MDS
Para iniciar seus estudos
Nesta unidade, você conseguirá compreender conceitos relacionados à 
qualidade em metodologias de desenvolvimento de software. Eles são 
aplicados em grande parte nas organizações que desenvolvem softwares 
nos dias dia hoje. Por isso, conhecê-los é algo extremamente importante. 
Objetivos de Aprendizagem
• Definir conceitos relacionados à qualidade em metodologias de 
desenvolvimento de software.
• Verificar a qualidade do processo e testes de software e validação 
de requisitos.
• Aprender a analisar se a qualidade do processo e testes de software 
e validação de requisitos é adequada ou não para a empresa.
92
Metodologia de Desenvolvimento de Sistemas | Unidade 7 - Qualidade em MDS
Introdução da unidade
A qualidade de software é um ponto do processo de desenvolvimento, o qual deve-se dar bastante atenção. 
Apesar de muitas organizações visarem apenas ao lucro, um processo de desenvolvimento com qualidade acaba 
resultando em ótimos softwares, o que também impacta em questões financeiras. Sendo assim, a qualidade do 
software produzido pode impactar diretamente nos lucros de uma empresa. Nesta unidade, serão evidenciados 
os termos de processos de desenvolvimento, destacando modelos de maturidade que visam avaliar a qualidade 
de um processo com parâmetros internacionais e nacionais, o CMMI e o MPS-BR, respectivamente. Ambos são 
bastante utilizados nas principais organizações da atualidade. Além disso, serão apresentadas também as formas 
de realização de teste de software e validação de requisitos. Essas tarefas possuem como objetivo evitar que erros 
sejam encontrados por clientes após a entrega. Conhecê-los é fundamental para que você compreenda sua 
importância e contexto de aplicação.
7.1 Qualidade em MDS
A qualidade em metodologias de desenvolvimento de software se faz extremamente importante. As principais 
organizações que produzem softwares na atualidade atingiram determinados patamares devido principalmente 
à qualidade de seus produtos. Por esse motivo, qualidade é fundamental para qualquer situação. Nesta unidade, 
serão abordados o conceito de qualidade do processo de software, focando nos modelos de referência CMMI e 
MPS-BR, bem como a apresentação de formas de teste de software, além dos conceitos relacionados à validação 
de requisitos.
7.1.1 Qualidade do processo de software
A garantia da definição e normatização de processos de desenvolvimento é o propósito da área de engenharia de 
software denominada qualidade de software. Apesar do fato de que a maioria das abordagens para melhoria do 
software atuarem especificamente no processo, a finalidade ainda sim é a garantia de que o sistema desenvolvido 
terá as características que o cliente deseja e que foram estabelecidas no princípio do projeto.
A definição de processo é dada pelo padrão IEEE 610.12-1990 da seguinte forma: “Processo é uma sequência de 
passos realizados para um determinado propósito”.
Entretanto, aqui, estamos interessados em processos de softwares. A definição de processo de softwares é dada 
pelo modelo de referência CMMI (Capability Maturity Model Integration) como o seguinte: “Um processo de software 
é um conjunto de atividades, métodos, práticas e tecnologias que as pessoas utilizam para desenvolver e manter 
software e produtos relacionados”.
Em outras palavras, podemos definir um processo de software como sendo uma sequência de atividades, 
métodos, práticas e tecnologias, a fim de garantir que o software possa ser desenvolvido de forma organizada e 
previsível. A Figura 42 exemplifica um processo de desenvolvimento de software que parte dos requisitos escritos, 
baseando-se nas necessidades do usuário e, ao longo do desenvolvimento, produtos intermediários vão sendo 
produzidos. Por fim, o produto final é entregue ao cliente.
93
Metodologia de Desenvolvimento de Sistemas | Unidade 7 - Qualidade em MDS
Figura 42 – Processo de desenvolvimento de software
Requisitos do
Usuário
Processo de
desenvolvimento
Entrega do
Produto Final
Produtos
Intermediários
Produto Final
Fonte: Elaborada pelo autor.
A qualidade também é descrita pela norma ISO 9000, do ano de 2000, em que se cumprem requisitos que 
foram estabelecidos no princípio, o que pode se dar para um produto, um processo ou até mesmo um sistema. A 
qualidade do software e do seu processo de desenvolvimento estão intimamente relacionadas, visto que a busca 
por um software de mais qualidade tipicamente passa pela melhoria do processo de desenvolvimento. 
Existe umademanda cada vez maior para que empresas produzam softwares com mais qualidade em um curto 
prazo de tempo. Por esse motivo, existem diversas tentativas de proposição de abordagens para melhoria no 
processo de desenvolvimento de software, de forma a levar a uma maior produtividade e agilidade sem perder 
a qualidade. Os modelos que foram desenvolvidos possuem o propósito de apoiar a melhoria dos processos de 
software (MPS) e permitem a superação dos fatores críticos de forma mais rápida. 
Alguns dos modelos mais utilizados são baseados no que chamamos de maturidade. Esse conceito pode ser 
entendido como a capacidade de se repetir uma série de resultados de uma maneira previsível (PRESSMAN, 
2016). Um dos principais modelos baseados em maturidade atualmente é o Capability Maturity Model Integration 
(CMMI) que atua não só na esfera brasileira, mas também mundial. Já considerando apenas a esfera nacional, o 
modelo MPS-BR (Melhoria de Processo de Software Brasileiro) possui grande adesão por uma considerável parte 
de empresas brasileiras que objetivam a melhoria de seus processos e o destaque em competência, para só então 
buscar a utilização de um modelo reconhecido internacionalmente para competir com o mercado externo.
É importante destacar que os modelos CMMI e MPS-BR são constituídos por diferentes níveis 
de maturidade, apesar de ambos disponibilizarem formas para medir o grau de progresso 
atingido na implementação de projetos de software.
Saiba mais
A seguir, abordaremos algumas definições referentes aos modelos de melhoria de processo de software CMMI e 
MPS-BR, respectivamente.
94
Metodologia de Desenvolvimento de Sistemas | Unidade 7 - Qualidade em MDS
7.1.2 CMMI
O Software Engineering Institute (SEI), órgão integrante da universidade norte-americana Carnegie Mellon, é um 
instituto que foi criado com o objetivo de melhorar a capacidade da indústria de software na América do Norte. 
Estudos, em 1980, pelo SEI, visavam analisar a capacidade dos serviços de software prestados. Como resultado 
dessa análise, foi criado o Modelo de Maturidade e Capacidade (CMM - Capability Maturity Model) pelo instituto, 
modelo este que tem influenciado bastante a comunidade de engenharia de software a ter uma preocupação 
maior com a melhoria do processo. A partir desse modelo, outros, que se preocupam com a maturidade e 
capacidade, foram desenvolvidos ao longo do tempo. Exemplos disso seriam o Modelo de Maturidade e de 
Capacidade de Pessoas (CMM-P) e o Modelo de Capacidade de Engenharia de Sistemas.
Mais tarde, o SEI embarcou em uma tentativa de integrar diferentes modelos de capacidade baseados na 
maturidade do processo, incluindo seus próprios modelos. O modelo resultante disso foi o Modelo de Capacidade 
Integrado (CMMI). O objetivo com o CMMI era a substituição dos CMMs e a integração de outros modelos de 
maturidade e de capacidade. O CMMI conta com duas versões: por estágio e contínua. Além disso, ele trata 
alguns dos pontos fracos do CMM corrigindo-os. 
Pode-se entender o modelo CMMI como um framework para a melhoria de processos de software. A versão 
do CMMI por estágios é similar ao CMM para o desenvolvimento e permite com que os procedimentos para a 
produção de softwares sejam avaliados, e a eles seja dado um nível de maturidade, indo de 1 a 5. Já sua versão 
contínua permite a classificação de 22 áreas de processo com valores indo de 0 a 5. 
O modelo CMMI é bastante complexo, estando contido em um documento com mais de mil páginas que 
o descreve. Dessa forma, aqui faremos uma simplificação da sua composição. Os principais elementos deste 
modelo são:
1. Um conjunto de 22 áreas que está associado às atividades de software e que é importante para a melhoria 
e capacidade de processo. Essas áreas são divididas em 4 categorias no modelo contínuo. O Quadro 8 
exibe essa relação.
Quadro 8 – Categorias e áreas de processo do CMMI contínuo
Categoria Área de Processo
Gerenciamento de Processos Definição do processo organizacional.
Foco de processo organizacional.
Treinamento organizacional.
Desempenho de processo organizacional.
Inovação e implantação organizacional.
95
Metodologia de Desenvolvimento de Sistemas | Unidade 7 - Qualidade em MDS
Categoria Área de Processo
Gerenciamento de Projetos Planejamento de projeto.
Monitoração e controle de projeto.
Gerenciamento de acordo com fornecedores.
Gerenciamento de projeto integrado.
Gerenciamento de riscos.
Gerenciamento quantitativo de projeto.
Engenharia Gerenciamento de requisitos.
Desenvolvimento de requisitos.
Solução técnica.
Integração de produto.
Verificação.
Validação.
Suporte Gerenciamento de configuração.
Garantia de qualidade de processo e produto.
Medição e análise.
Análise de decisão e resolução.
Análise causal e resolução.
Fonte: Baseado em PRESSMAN, 2016.
2. Um conjunto de metas que descrevem, de forma abstrata, uma condição desejável para ser obtida por 
organizações. Elas podem ser divididas em metas específicas e metas genéricas. Metas específicas para 
uma área de processo aborda um estado ou condição desejável pra ela. Já as metas genéricas estão 
associadas ao emprego de boas práticas. O Quadro 9 mostra exemplos de metas específicas e genéricas 
do CMMI.
Quadro 9 – Metas específicas e genéricas no modelo CMMI
Meta Área de processo Tipo
Ações corretivas são gerenciadas até a conclusão, 
quando o desempenho ou os resultados se desviam 
significativamente do plano.
Monitoração e controle 
de projeto
Meta específica
O desempenho real e o progresso do projeto são 
monitorados contra o plano de projeto. 
Monitoração e controle 
de projeto
Meta específica
96
Metodologia de Desenvolvimento de Sistemas | Unidade 7 - Qualidade em MDS
Meta Área de processo Tipo
Os requisitos são analisados e validados, e 
uma definição da funcionalidade requerida é 
desenvolvida.
Desenvolvimento de 
requisitos
Meta específica
Causa raiz de defeitos e outros problemas são 
sistematicamente determinados.
Análise causal e 
resolução 
Meta específica
O processo é institucionalizado como um processo 
definido. 
- Meta genérica
O processo permite e dá apoio à realização de 
metas específicas da área de processo de forma 
a transformar produtos de trabalho de entrada 
identificável para gerar produtos de trabalho de 
saída identificável.
- Meta genérica 
Fonte: Baseado em PRESSMAN, 2016.
3. Uma série de boas práticas que descrevem o que deve ser feito para alcançar uma meta. Diversas práticas, 
específicas ou genéricas, podem estar associadas a uma mesma meta, dentro de uma área de processo. 
O Quadro 10 ilustra alguns exemplos de boas práticas. 
Quadro 10 – Metas e práticas associadas ao CMMI
Meta Práticas associadas
Os requisitos são analisados e validados, 
e uma definição da funcionalidade 
requerida é desenvolvida. 
Analisar sistematicamente os requisitos derivados para 
garantir que eles são necessários e suficientes. 
Validar os requisitos para garantir que o produto resultante 
executará conforme o pretendido no ambiente do usuário, 
usando várias técnicas.
Causa raiz de defeitos e outros problemas 
são sistematicamente determinados.
Selecionar os defeitos críticos e outros problemas para 
análise.
Realizar uma análise causal de defeitos selecionados e outros 
problemas e propor ações para solucioná-los.
O processo é institucionalizado como um 
processo definido.
Estabelecer e manter uma política organizacional para 
planejar e executar o processo de desenvolvimento de 
requisitos.
Atribuir responsabilidades e autoridade para executar o 
processo, desenvolver os produtos de trabalho e prestar os 
serviços do processo de desenvolvimento de requisitos.
Fonte: Baseado em PRESSMAN, 2016.
97
Metodologia de Desenvolvimento de Sistemas | Unidade 7 - Qualidade em MDS
Apesar de existirem práticas associadas sugeridas para se conseguir atingir uma meta, o 
CMMI ressalta que o mais importante é a meta. Portanto, qualquer caminho é válido para se 
atingir essa meta.
Fiqueatento!
Utilizar o CMMI para avaliação consiste em examinar os processos (ou áreas de processos) em uma organização 
e classificá-los em uma escala com seis níveis de maturidade. Quanto mais maduro um processo melhor. Essa 
escala é definida da seguinte forma (PRESSMAN, 2016):
Quadro 11 – Escala dos níveis de maturidade no CMMI
Nível de Maturidade Descrição
Incompleto Ao menos 1 das metas específicas associadas à área do processo não 
está satisfeita e não existem metas genéricas. 
Executado Metas associadas com a área de processos são satisfeitas, e o escopo de 
trabalho de todos os processos é comunicado a todos os membros da 
equipe de forma explícita.
Gerenciado Metas associadas com a área de processo são satisfeitas, políticas 
organizacionais devem ser utilizadas, planos de projeto são 
documentados (definindo metas de projeto) e o gerenciamento de 
recursos e controle de processos devem estar em ordem. 
Definido Padronização e implantação de processos organizacionais. 
Gerenciado quantitativamente Há uma responsabilidade organizacional de utilizar métodos estatísticos/
quantitativos para controlar os subprocessos. 
Otimizando Deve-se utilizar medições de processo e produto para dirigir a melhoria 
de processos. Processo devem ser adaptados às necessidades do 
negócio. 
Fonte: Baseado em PRESSMAN, 2016.
98
Metodologia de Desenvolvimento de Sistemas | Unidade 7 - Qualidade em MDS
A Figura 43 ilustra a disposição dos níveis de maturidade de processos no CMMI.
Figura 43 – Níveis de maturidade do CMMI
Nível 1 - Inicial
Nível 2 - Gerenciado
Nível 3 - Definido
Nível 4 - Gerenciado
Quantitativamente
Nível 5 - Otimizado
Fonte: Elaborada pelo autor.
As descrições aqui apresentadas são bastante simples. Para a utilização do CMMI, é necessário trabalhar com 
uma descrição mais detalhada. Com esse propósito, existem diversos manuais do CMMI disponibilizados de 
forma gratuita na internet.
7.1.3 MPS-BR
Criado pela reunião de organizações ligadas ao desenvolvimento de software, como a Softex (SP), RioSoft (RJ), 
o COPPE/UFRJ (RJ) e o CESAR (PE), o MPS-BR (Melhoria do Processo de Software Brasileiro) pode ser visto como 
um modelo para melhorar a capacidade de desenvolvimento de softwares nas empresas do Brasil (BR, 2011). 
Desenvolvido em 2003, e também baseado na maturidade de processos, o MPS-BR levou em consideração 
algumas normas e modelos que são internacionalmente conhecidos, tais como CMMI, norma ISO/IEC 12207 e 
norma ISO/IEC 15504, adaptando-os para as características específicas do mercado brasileiro.
No modelo MPS-BR, os níveis de maturidade definem patamares de forma a indicar a evolução dos processos. 
Conhecer o nível de maturidade em que se encontra uma organização permite com que seja possível a predição 
do seu desempenho futuro ao realizar a execução de um ou mais processos. São 7 os níveis de maturidade, como 
indica a Figura 44.
99
Metodologia de Desenvolvimento de Sistemas | Unidade 7 - Qualidade em MDS
Figura 44 – Níveis de maturidade do MPS-BR
Em otimizaçãoA
B
C
D
E
F
G
Gerenciado Quantitativamente
Definido
Largamente definido
Parcialmente definido
Gerenciado
Parcialmente gerenciado
Fonte: Elaborada pelo autor.
O Quadro 12, a seguir, apresenta uma descrição para os 7 níveis de maturidade do modelo MPS-BR.
Quadro 12 – Escala de níveis de maturidade do MPS-BR
Nível de Maturidade Descrição
Em otimização Inovação e análise de causas são algumas das 
preocupações.
Gerenciado quantitativamente O desempenho e a gerência quantitativa dos 
processos são avaliados.
Definido O gerenciamento de riscos ocorre. 
Largamente definido Além de outras atividades, abrange verificação, 
validação, instalação e integração de componentes.
Parcialmente definido Envolve treinamento, adaptação de processos 
para gerência de projetos, melhoria e controle do 
processo organizacional.
Gerenciado Inclui medição, gerência de configuração, aquisição 
e garantia de qualidade. 
Parcialmente gerenciado Inicia-se o gerenciamento de requisitos e projetos.
Fonte: Baseado em MPS.BR, 2011.
100
Metodologia de Desenvolvimento de Sistemas | Unidade 7 - Qualidade em MDS
A obtenção da certificação MPS-BR por organizações abre portas para as empresas concorrerem em licitações 
do governo, visto que em muitas delas a certificação é uma exigência. O modelo MPS-BR também pode ser 
considerado, em detrimento ao CMMI em organizações de médio e pequeno porte, visto que sua implementação 
custa consideravelmente menos que a aplicação do modelo CMMI, por exemplo.
7.2 Modelos de teste de software
O teste de software tem como finalidade mostrar que um sistema faz o que é suposto que ele faça e expor 
defeitos antes que o usuário faça uso do software (SOMMERVILLE, 2007). Durante esta etapa, dados hipotéticos 
são apresentados ao sistema, a fim de verificar sua saída que é analisada com o objetivo de encontrar erros, 
anomalias ou quaisquer informações sobre características que estão funcionando mal no programa. 
Entre os objetivos do teste software, podemos citar dois como principais:
1. Mostrar tanto ao desenvolvedor quanto ao cliente que o sistema atende aos requisitos, ou seja, que 
ele faz aquilo que foi solicitado. Em softwares customizados, isso significa que deve existir, ao menos, 
um teste por requisitos. Já nos softwares genéricos, devem haver testes para todas as características do 
sistema além da sua integração.
2. Encontrar situações/entradas que fazem com que o sistema se comporte de forma incorreta, indesejável 
ou diferente do que foi especificado. Os defeitos de software é o que causam essas situações. Como 
exemplos, há panes, processamentos incorretos, dados corrompidos, entre outros. 
A Figura 45 ilustra um modelo para teste de programas, contendo entradas que geram saídas anômalas.
Figura 45 – Um modelo para teste de programas
Sistema
Saídas
e resultados
de teste
Entradas
de
dados
de teste
Entradas que
causam
comportamentos
anômalos
Saídas que
revelam
defeitos
Fonte: Baseado em SOMMERVILLE, 2007.
De forma geral, podemos categorizar os testes de acordo com suas características e objetivos em dois tipos: 
testes caixa-branca e testes caixa-preta. Testes caixa-branca buscam avaliar o comportamento interno dos 
componentes de software. Esse tipo de teste avalia o código-fonte do sistema para verificar ciclos, condições, 
caminhos lógicos, etc. Já os testes caixa-preta avaliam um software como se ele fosse uma caixa-preta, ou seja, o 
comportamento interno do software não é levado em consideração. Basicamente, entradas são apresentadas a 
um sistema, e as respostas obtidas são comparadas às respostas esperadas. O objeto a ser testado pode ser um 
método, uma função, um programa, um componente, conjuntos de programas ou até mesmo funcionalidades. 
101
Metodologia de Desenvolvimento de Sistemas | Unidade 7 - Qualidade em MDS
Ao longo do processo de desenvolvimento, o software geralmente passa por três tipos de teste: testes em 
desenvolvimento, testes de release e testes de usuário. Vejamos a seguir um pouco mais sobre cada um desses 
testes.
7.2.1 Testes em desenvolvimento
Os testes em desenvolvimento são constituídos por todas as atividades de testes que são realizadas pela equipe 
de desenvolvimento ao longo do projeto. O objetivo é a descoberta de bugs e defeitos. Geralmente, os projetistas 
do sistema ou até mesmo os programadores são os responsáveis por realizar esse tipo de teste. 
Testes em desenvolvimento podem ser divididos em três categorias de acordo com a abrangência do que está 
sendo testado:
1. Testes unitários: neste tipo de teste, as unidades individuais de programas são testadas separadamente. 
Essas unidades consistem em classes, objetos e métodos.
2. Teste de componentes: neste tipo de teste, há uma integração de unidades individuais, a fim de 
criar componentes compostos. Geralmente, teste de componentes buscam testar as interfaces dos 
componentes. 
3. Teste de sistema: neste tipo de teste, uma parte ou todoscomponentes do sistema são combinados, a 
fim de testar o sistema como um todo. O objetivo é o teste das interações entre componentes.
7.2.2 Testes de release
O teste de release possui o objetivo de testar o sistema, a fim de verificar se ele atende aos requisitos buscados 
pelos interessados no sistema. Este teste é realizado por uma equipe especializada para isso, e o sistema a ser 
testado já deve ser uma versão completa que será disponibilizada aos usuários posteriormente. Desse modo, 
testes de release devem demonstrar que o sistema é funcional, possui desempenho e funcionalidade e que não 
apresentará falhas na sua utilização. Geralmente, são testes caixa-preta, visto que sua elaboração é baseada 
somente nas especificações previamente acordadas, ou seja, não se olha o código para desenvolver os testes.
7.2.3 Testes de usuário
Testes de usuário, assim como o próprio nome diz, possuem a participação do usuário, utilizando o sistema em 
seu próprio ambiente. Em algumas situações, esse usuário pode ser, por exemplo, o grupo de marketing interno 
de uma empresa que verificará se o teste pode ser comercializado ou não. 
Na prática, os testes de usuário podem ser divididos em três tipos:
1. Teste Alfa: usuários do software colaboram com a equipe de desenvolvimento, a fim de testar o software 
dentro da organização de desenvolvimento. 
2. Teste Beta: um release do sistema é disponibilizado aos usuários para que estes possam explorar o sistema 
com a finalidade de descobrir problemas que os desenvolvedores não conseguiram encontrar. 
102
Metodologia de Desenvolvimento de Sistemas | Unidade 7 - Qualidade em MDS
3. Teste de Aceitação: clientes testam um sistema, a fim de decidir se o sistema está pronto para ser aceito 
e, em seguida, implantado no ambiente do cliente. 
7.3 Validação de requisitos
De acordo com Sommerville (2007), a validação “é o processo pelo qual se verifica se os requisitos definem o 
sistema que o cliente realmente quer”. Em outras palavras, confirma se o que o cliente tem em mente para o 
sistema requerido realmente está escrito no documento de requisitos. A validação acontece em concomitância 
com a análise, no intuito de encontrar problemas nos requisitos. 
A validação de requisitos se faz extremamente importante, visto que erros na especificação dos requisitos que 
forem encontrados somente na etapa de desenvolvimento ou até mesmo quando o sistema já está em uso podem 
gerar altos custos em sua solução. Consertar erros na especificação pode ser algo simples a se fazer, quando o 
sistema ainda não foi implementado. Caso isso já tenha ocorrido, envolve alterações não só no documento, mas 
na codificação do sistema o que exige também que o sistema deva ser retestado. 
Ao longo do processo de validação de requisitos, existe uma série de verificações que deve ser realizada, utilizando 
o documento de requisitos. Algumas dessas verificações são:
1. Verificações de validade: A princípio, requisitos iniciais podem ser levantados. Entretanto, uma análise 
mais aprofundada pode fazer com que requisitos adicionais sejam especificados, devido à descoberta de 
novas funcionalidades exigidas pelo cliente. 
2. Verificações de consistência: Não deve haver conflito entre requisitos especificados. Em outras palavras, 
não devem existir restrições contraditórias, por exemplo. 
3. Verificações de completude: O documento de requisitos deve conter todas as funcionalidades e 
restrições pretendidas pelo usuário com o sistema. 
4. Verificações de realismo: Requisitos devem ser verificados para ver a possibilidade de serem 
implementados, considerando a tecnologia, orçamento e cronograma existentes. 
5. Verificabilidade: Requisitos devem ser passíveis de verificação. Em outras palavras, deve-se escrever um 
conjunto de teste para testar cada um dos requisitos especificados.
Existem também diferentes tipos de técnicas que podem ser utilizadas individualmente ou em conjunto para 
validar os requisitos:
1. Revisões de requisitos: uma equipe de revisores verifica se os requisitos possuem erros ou inconsistências 
de forma sistemática.
2. Prototipação: um modelo executável do software é apresentado a usuários e clientes, a fim de verificarem 
se o sistema está atendendo às suas necessidades.
3. Geração de casos de teste: requisitos necessitam ser testáveis. Se testes já forem executados na etapa 
de validação de requisitos, problemas serão evitados em etapas seguintes. Se é difícil projetar um caso de 
teste para um requisito, o mesmo deve ser reconsiderado. O desenvolvimento de testes antes mesmo da 
implementação dos requisitos é parte integrante de diversos métodos de desenvolvimento de software.
103
Metodologia de Desenvolvimento de Sistemas | Unidade 7 - Qualidade em MDS
Os problemas encontrados na validação de requisitos são de extrema importância. Entretanto, a validação ainda 
é uma etapa difícil de ser executada, visto que mostrar que os requisitos atendem às necessidades de um cliente, 
sem de fato implementá-los, podem acabar sendo uma tarefa trabalhosa. Por esse motivo, nem sempre é possível 
encontrar todos os problemas nesta fase. Sendo assim, mesmo após o ajuste do documento de requisitos, ainda 
sim podem ocorrer mudanças futuras decorrentes de problemas encontrados neste documento. 
Síntese da unidade
Esta unidade abordou o conceito de qualidade do processo de software, destacando dois modelos destinados para 
realizar esse tipo de avaliação, o CMMI e o MPS-BR. Além disso, apresentamos modelos de teste de software que 
podem ser divididos em teste de desenvolvimento, teste de release e teste de usuário. Por fim, foram discutidas 
questões referentes à validação de requisitos.
104
Considerações finais
A qualidade em metodologias de desenvolvimento de software acaba 
resultando na qualidade do sistema desenvolvido, o que geralmente é 
uma das principais metas de quaisquer organizações. Portanto, deve ser 
tratada com bastante seriedade, e esforços devem ser levantados para que 
sua manutenção seja efetuada de forma correta.
105
 8Unidade 88. Estudos de Casos com Uso de 
Software CASE 
Para iniciar seus estudos
Nesta unidade, você compreenderá diferentes conceitos relacionados 
às ferramentas CASE que auxiliam o processo de desenvolvimento de 
software. Conhecer estas ferramentas possibilita compreender quando 
e onde utilizá-las e, assim, usufruir de seus benefícios da melhor forma 
possível em seus projetos futuros.
Objetivos de Aprendizagem
• Definir os diferentes conceitos relacionados às ferramentas CASE 
e sua aplicação. 
106
Metodologia de Desenvolvimento de Sistemas | Unidade 8 - Estudos de Casos com Uso de Software CASE 
Introdução da unidade
A produção de softwares tem crescido amplamente nos dias atuais, principalmente devido à evolução constante 
dos hardwares que os suportam. Nesse sentido, cada vez mais, organizações têm utilizado metodologias e 
ferramentas auxiliares a fim de aumentarem a produtividade e melhorarem a qualidade de seu produto final. 
Ferramentas CASE podem ser vistas como softwares que suportam as atividades que estão envolvidas em um 
processo de desenvolvimento de sistemas. Sua utilização é fundamental para que se desenvolva um software 
de qualidade, entre outras vantagens. Nesta unidade, serão abordados seus principais conceitos, categorias e 
exemplos, bem como um estudo de caso com sua aplicação. O estudo das ferramentas CASE possibilita sua 
utilização e a capacidade de extrair o máximo de benefícios que elas possam trazer para seus projetos.
8.1 Estudos de casos com uso de software CASE
Ferramentas CASE são utilizadas para apoiar as diversas atividades do processo de desenvolvimento de software 
(VAVASSORI, 2001). Sua utilização e compreensão se fazem extremamente importantes, principalmente em 
sistemas de grande porte. Nesta unidade, serão abordados conceitos relacionados a ferramentas CASE, seu 
histórico, workbenches e a importância de sua utilização. Além disso, as principais categoriasem que as ferramentas 
se agrupam e exemplos de ferramenta também serão apresentados. Por fim, apresentaremos também um estudo 
de caso pra esse tipo de ferramenta.
8.1.1 Ferramentas CASE
O papel dos sistemas de softwares é fundamental nos dias atuais. Com diferentes funções, os sistemas estão cada 
vez mais adaptados para atenderem às necessidades de diferentes usuários. Entretanto, independentemente da 
atuação de um sistema de software, seja ela científica, militar, industrial ou comercial, o principal objetivo em um 
sistema de software é sempre a qualidade. 
A engenharia de software vem cumprindo um papel importante na garantia do desenvolvimento de softwares 
de qualidade. Desde o levantamento dos requisitos até o teste de software, o estabelecimento do processo de 
desenvolvimento de software vem recebendo aprimoramentos e acabou por se tornar algo essencial no projeto 
de qualquer sistema de computador. Modelos, metodologias e formalismos foram propostos a fim de dar suporte 
ao processo, de forma que custos sejam minimizados, a produtividade seja aumentada e a qualidade do software 
final seja ampliada. 
A incorporação de métodos formais tem sido útil, visto que sua utilização agrega o rigor matemático ao processo, 
o que promove diversos benefícios. Notações, por exemplo, permitem que ambiguidades sejam removidas. Já 
técnicas de verificação permitem que o sistema seja definido como correto antes mesmo da sua implementação. 
Regras de transformação possibilitam que o sistema seja especificado em uma linguagem abstrata. Assim, 
permite que uma especificação mais concreta e semanticamente idêntica seja construída, utilizando até mesmo 
ferramentas que o fazem de forma automática. 
Entretanto, apesar de tanta sofisticação dos métodos de desenvolvimento de software, um efeito colateral 
é gerado: a alta complexidade do processo de gerenciamento do processo. Assim como em uma fábrica, o 
107
Metodologia de Desenvolvimento de Sistemas | Unidade 8 - Estudos de Casos com Uso de Software CASE 
desenvolvimento de software exige a utilização de ferramentas de apoio que visam minimizar os problemas 
resultantes das limitações existentes na natureza humana. 
Nesse contexto, surgiram as diversas ferramentas Computer-Aided Software Engineering (CASE), com o objetivo de 
dar suporte às inúmeras fases do processo de software. De acordo com Sommerville (2007), CASE é uma forma da 
engenharia de software ser auxiliada pelo computador. Em outras palavras, é “o processo de desenvolvimento de 
software com uso de suporte automatizado”.
A palavra “CASE” é, por vezes, utilizada para designar as ferramentas que dão suporte aos processos de software. 
Contudo, o termo “CASE” denota a tecnologia que existe no uso de ferramentas computacionais para o 
desenvolvimento de programas. Em outras palavras, é a combinação de ferramentas de apoio e engenharia de 
software. O ideal é denominar “ferramentas CASE” para os softwares de apoio, e “CASE”, a tecnologia em si. A 
Figura 46 exemplifica um diagrama de casos de uso para uma ferramenta CASE.
Figura 46 – Exemplo de diagrama de casos de uso para uma ferramenta CASE
criar projeto
adicionar modelo
ao projeto
verificar modelo
adicionar diagrama
ao modelo
adicionar diagrama de
casos de uso
adicionar diagrama
de classe
gerar código
salvar projeto
abrir projeto
Servidor de Arquivos
Desenvolvedor
Fonte: Elaborada pelo autor.
8.1.2 Breve histórico das ferramentas CASE
Em 1982, surgiram as primeiras ferramentas CASE comerciais. Entretanto, somente a partir de 1985 a utilização 
desse tipo de ferramenta começou a ficar mais frequente, visto que, naquela época, houve um grande interesse 
da comunidade de engenharia de software no desenvolvimento de ferramentas mais sofisticadas. Em uma 
pesquisa realizada por Aubrey Moore, em 1990, levantaram-se os seguintes dados (MOORE, 1996):
• Foram identificados mais de 470 vendedores de ferramentas CASE, e novas ferramentas surgem a cada 
mês.
108
Metodologia de Desenvolvimento de Sistemas | Unidade 8 - Estudos de Casos com Uso de Software CASE 
• Em 1990, o mercado de ferramentas CASE movimentou 4,8 bilhões de dólares. 
• Em 1995, o crescimento estimado no mercado de ferramentas CASE subiu para 12,11 bilhões de dólares.
A sofisticação das ferramentas CASE foi possível devido a dois importantes eventos:
• O rápido progresso dos computadores pessoais e workstations no início dos anos 1980. O aumento na 
capacidade de memória e processador, bem como o surgimento de uma interface gráfica facilitaram a 
interação humano-computador. 
• Uma série de modelos que poderiam ser suportados por ferramentas surgiram como resultado de diversas 
pesquisas sobre o desenvolvimento de software.
No meio acadêmico, em instituições governamentais e órgãos de defesa, os investimentos em pesquisas no 
desenvolvimento de ferramentas CASE vêm aumentando consideravelmente.
8.1.3 Workbenches
Sommerville (2007) define um “CASE workbench” como um conjunto integrado de ferramentas CASE que 
trabalham juntas no apoio a uma grande atividade do processo, por exemplo, projeto de software ou gerenciamento 
de configuração. Em outras palavras, podemos compreender um workbench como um conjunto de ferramentas 
CASE que objetivam o fornecimento de suporte a uma fase em particular do processo de software. 
A vantagem no agrupamento de ferramentas em um workbench é o fato de que, juntas, elas podem promover um 
suporte maior do que trabalhando individualmente. Outras ferramentas podem implementar e solicitar serviços 
comuns, por exemplo. Entre as diversas fases do processo, as fases de análise e design, programação e teste são 
as que mais se beneficiam com a utilização de workbenches. Isso pode ser explicado pelo fato de que estas são as 
fases melhor compreendidas dentro do processo. Sendo assim, ferramentas eficientes para suporte dessas fases 
se unificam, a fim de aumentar ainda mais a produtividade. 
Conforme a integração vai se consolidando, workbenches acabam se assemelhando a um sistema aberto. Essa 
postura resulta em algumas vantagens:
• Facilidade na adição de novas ferramentas que atendem a necessidades particulares de uma organização 
ou substituição de ferramentas antigas por ferramentas mais adequadas. 
• As ferramentas possuem como saída arquivos que podem ser utilizados por sistemas de gerenciamento 
de configuração. 
• Workbenches são fáceis de escalar.
• As necessidades da organização não são reprimidas durante a utilização de workbenches. Exemplo disso 
seria o fato de que a troca de uma ferramenta obsoleta por outra mais recente não afeta o funcionamento 
da empresa. Basta desligar apenas a ferramenta a ser removida.
109
Metodologia de Desenvolvimento de Sistemas | Unidade 8 - Estudos de Casos com Uso de Software CASE 
8.1.4 Importância das ferramentas CASE
As ferramentas CASE envolvem recursos para a gerência, análise de requisitos, modelagem, codificação, execução 
de testes e manutenção do software. De forma geral, seu apoio representa um enorme diferencial na execução de 
um processo de software. Entretanto, a integração provida por elas resulta nos maiores benefícios. 
Exemplo disso seria o desenvolvimento de projetos em larga escala com a utilização de uma ferramenta (ou 
um conjunto delas) para cada fase do processo. Processos e fluxos de dados são definidos por uma ferramenta 
de análise estruturada. Outra ferramenta é utilizada para desenvolver o modelo entidade-relacionamento. 
Engenheiros possuem a responsabilidade de garantir com que os documentos que transitam entre as fases do 
processo possuam uma correspondência, o que nem sempre é atingido. Pela integração de sistemas, problemas 
como esse seriam automaticamente solucionados pelas ferramentas, de forma que erros seriam eliminados, e o 
trabalho de desenvolvedores, diminuído. 
Diversas outras vantagens podem ser mencionadas ao trabalhar com ferramentas CASE. A primeira delas 
é a redução de custos, visto que muitas tarefas manuais acabamsendo automatizadas com a utilização da 
ferramenta. O tempo dedicado ao desenvolvimento também é reduzido, uma vez que ferramentas CASE apoiam 
a padronização e evitam repetição e reuso. A qualidade de projetos de alta complexidade consegue ser mantida, 
já que sua utilização favorece a consistência e a coordenação. Por fim, o uso das ferramentas CASE promove uma 
documentação de alta qualidade e cria sistemas de fácil manutenção, devido à rastreabilidade dos requisitos.
8.2 Tipos de Ferramentas CASE
A tecnologia CASE pode ser categorizada em três classes: tecnologia de suporte ao processo de produção; 
Tecnologia de gerenciamento de processo; tecnologia meta-CASE. O Quadro 13 apresenta a definição de cada 
uma dessas classes.
Quadro 13 – Categorias da tecnologia CASE
Categoria Descrição
Tecnologia de suporte ao processo de 
produção
Ferramentas que apoiam as atividades do processo, como 
especificação, design, implementação e teste. 
Tecnologia de gerenciamento de 
processo
Ferramentas que apoiam a modelagem e o gerenciamento de 
processo. São ferramentas que interagem com as de suporte ao 
processo de produção, com o objetivo de direcionar/gerenciar 
suas tarefas em uma atividade específica. Essas ferramentas 
necessitam de bastante pesquisa, visto que ainda são imaturas. 
Tecnologia meta-CASE Ferramentas utilizadas para criação de ferramentas de suporte ao 
gerenciamento de processo e processo de produção. Existe pouca 
utilização deste tipo, visto que são difíceis de se empregar. 
Fonte: Elaborado pelo autor.
110
Metodologia de Desenvolvimento de Sistemas | Unidade 8 - Estudos de Casos com Uso de Software CASE 
A classificação das ferramentas CASE pode se dar por meio de diversos critérios. Nesta unidade, serão abordadas 
a classificação por funcionalidade e por fase do processo de software.
8.2.1 Classificação por funcionalidade
A classificação das ferramentas CASE por funcionalidade é definida de acordo com a funcionalidade das 
ferramentas. O Quadro 14 exibe os tipos de ferramentas, sua descrição e exemplos.
Quadro 14 – Classificação de ferramentas CASE por funcionalidade
Tipo Descrição Exemplos
Gerenciamento Úteis na representação dos 
elementos de um processo e 
seus relacionamentos. Permitem 
a compreensão do processo, 
bem como das atividades 
envolvidas na sua execução. 
Ferramentas para estimativa de 
custos.
Edição Auxiliam na codificação, 
modelagem gráfica e 
documentação.
Editores de texto e editores de 
diagrama.
Gerenciamento de configuração Suporte às tarefas de controle de 
versão, controle de mudanças, 
identificação, auditoria, entre 
outras. 
Sistemas para o controle de 
versão e para o gerenciamento 
de mudanças. 
Prototipagem Auxiliam na criação rápida 
de protótipos. Apoiam a 
definição de layouts de tela e 
sua integração com o design de 
dados, bem como a geração de 
código-fonte. 
Linguagens de alto nível e 
geradores de interface gráfica. 
Suporte à programação Faz com que seja possível o 
desenvolvimento de softwares 
em linguagens mais próximas 
das que o ser humano pode 
compreender. 
Editores, interpretadores, 
compiladores. 
Análise de programas Realizam uma análise do código 
e interagem com o sistema em 
execução. Servem para geração 
de casos de teste e inspeção do 
fluxo do programa.
Analisadores dinâmicos e 
estáticos. 
111
Metodologia de Desenvolvimento de Sistemas | Unidade 8 - Estudos de Casos com Uso de Software CASE 
Tipo Descrição Exemplos
Teste Úteis para controle e 
coordenação dos testes de 
software. 
Comparadores de arquivos, 
geradores de dados de teste, etc. 
Depuração Realizam inspeção do código-
fonte em execução.
Sistemas de depuração.
Documentação Suportam a produção e 
publicação de documentação.
Processadores de texto e editores 
de imagens. 
Reengenharia Auxiliam na engenharia reversa e 
na reestruturação de código. 
Sistemas de reestruturação de 
programas. 
Fonte: Adaptado de VAVASSORI, 2001.
8.2.2 Classificação por fase do processo
As ferramentas CASE também podem ser classificadas conforme as fases do processo de desenvolvimento de 
software nas quais são empregadas. O Quadro 15, apresentada a seguir, indica, em suas colunas, as diferentes 
fases do processo e, em suas linhas, ferramentas que podem ser utilizadas em cada uma das fases. A indicação 
de que uma ferramenta é utilizada em uma fase é dada pelo sombreado cinza.
Quadro 15 – Classificação de ferramentas CASE por fase do processo
Especificação Design Implementação Verificação/Validação
Geração de dados de 
teste
Modelagem e 
simulação
Transformação de 
programas
Depuração interativa
Análise de programas
Processamento de 
linguagem
Suporte a método
Gerenciamento de 
interface de usuário
112
Metodologia de Desenvolvimento de Sistemas | Unidade 8 - Estudos de Casos com Uso de Software CASE 
Dicionário de dados
Edição de diagramas
Prototipagem
Gerenciamento de 
configuração
Preparação de 
documentos
Edição de texto
Estimação e 
planejamento
Fonte: Adaptado de VAVASSORI, 2001.
Apesar de haver ferramentas CASE em todas as atividades do processo, ainda existe alguma defasagem em 
termos da qualidade do suporte que essas ferramentas oferecem para alguns tipos de atividades. Isso mostra 
que tais atividades que não são plenamente apoiadas ainda não são completamente compreendidas. Ao longo 
do tempo, conforme as ferramentas se amadurecerem, possivelmente essa situação se tornará melhor. 
8.2.3 Exemplos de ferramentas CASE
Atualmente, existem inúmeras ferramentas CASE no mercado. Elas contribuem bastante para a qualidade do 
processo e, como resultado, do produto final. Entretanto, elas não resolvem todos os problemas. É necessário 
compreender a real contribuição, deficiências, possibilidades e capacidades que envolvem as ferramentas CASE 
para só então aplicá-las às atividades de processos. Serão abordados a seguir três exemplos de ferramentas CASE 
existentes no mercado: Pencil Project; Edraw Professional Diagram Solution; Bizagi Modeler. 
Pencil Project
O Pencil Project consiste em uma ferramenta utilizada na construção de wireframes para interfaces. Wireframes são 
espécies de protótipos para interfaces gráficas que permitem visualizar como será a interação do usuário antes 
que a finalização esteja pronta. O software, que é open source, fornece uma coleção de modelos que permitem 
que rapidamente se desenvolva, por meio de um desenho ou até mesmo de um diagrama, um rascunho do que 
se deseja produzir. A Figura 47 exemplifica a interface do Pencil Project e o rascunho de uma tela de um aplicativo 
para smartphone.
113
Metodologia de Desenvolvimento de Sistemas | Unidade 8 - Estudos de Casos com Uso de Software CASE 
Figura 47 – Interface do Pencil Project na construção de um protótipo
Fonte: Elaborada pelo autor.
Além de fornecer recursos para implementações de telas para interface gráfica, o Pincel Project também permite 
que sejam criados diagramas que podem incorporar diferentes recursos, dependendo do modelo selecionado. A 
Figura 48 ilustra um projeto simples com Pencil Project representado por meio de um diagrama. 
Figura 48 – Interface do Pencil Project na construção de um diagrama
Fonte: Elaborada pelo autor.
114
Metodologia de Desenvolvimento de Sistemas | Unidade 8 - Estudos de Casos com Uso de Software CASE 
O Pencil Project é um software open source que está disponível para diversas plataformas. 
Pesquise pelo software Pencil Project.
Saiba mais
Existem diversas vantagens associadas à utilização do Pencil Project. A primeira delas é o fato de ser um software 
open source de alta qualidade e multiplataforma, ou seja, ele executa no Linux, Windows e Mac. Sua interface é 
bastante intuitiva, visto que seus recursos são organizados em coleções. Ele permite a exportação em diversos 
formatos e suporta os seguintes diagramas: de casos de uso, de classes, de estados, de atividades, de comunicação, 
de sequência, de componentes, de estrutura composta, de deployment, de objetose de pacotes. 
Edraw Professional Diagram Solution
O Edraw é um software multiplataforma com o intuito de auxiliar na produção de fluxogramas, mapas mentais, 
organogramas, UML e até mesmo diagramas de rede. Ele possui uma ampla galeria de exemplos e modelos que 
podem ser utilizados com tal objetivo. Seus recursos para a criação de diagramas são simples e fáceis de serem 
utilizados. Coleções de recursos são organizadas por modelos e a interface é bastante intuitiva. A Figura 49 exibe 
um template oferecido pelo Edraw para a construção de mapas mentais. 
Figura 49 – Interface do Edraw na construção de um mapa mental
Fonte: Elaborada pelo autor.
Existem diversas vantagens associadas à utilização do Edraw. É possível a criação de forma bem fácil e rápida de 
fluxogramas e gráficos de negócio. Além disso, o software disponibiliza uma grande variedade de templates prontos, 
115
Metodologia de Desenvolvimento de Sistemas | Unidade 8 - Estudos de Casos com Uso de Software CASE 
que podem facilmente ser utilizados. Suporta fluxogramas, gráficos de negócio, organogramas, diagramas em 
RH, fluxos de programação e de trabalhos e diagramas de rede. Fornece diversas fontes, cores, estilos, formas e 
símbolos. Por fim, o Edraw permite a exportação de arquivos em diversos formatos.
A versão trial do Edraw pode ser obtida na internet de forma gratuita. Pesquise por Free 
Download Edraw Max for Linux.
Saiba mais
Bizagi Modeler
O modelador de processos Bizagi consiste em uma ferramenta para gestão de processos ágeis que permite a 
criação de desenhos, diagramas, documentos e publicações de processos utilizando o padrão Business Process 
Model and Notation (BPMN). Uma característica diferente do Bizagi é o fato de permitir publicações para web. Sua 
exportação e importação se dá em arquivos no formato XML. Além disso, oferece suporte a regras de negócio, 
arquitetura orientada a serviços, monitoramento de atividades de negócio e gestão de riscos.
Figura 50 – Exemplo de modelo de processo utilizando o Bizagi Modeler
Fonte: CERTIFICATION..., 2014.
Existem diversas vantagens associadas à utilização do Bizagi. Podemos citar a facilidade na utilização das notações 
MPMN de negócios, por exemplo. Além disso, ele provê uma gama de templates prontos e de fácil utilização, 
bem como a exportação em diferentes formatos. Por fim, ele possui diversos guias para a sua utilização, oferece 
a opção de arrastar e soltar símbolos, o que otimiza o design, e fornece uma farta documentação a partir do 
desenho do processo.
116
Metodologia de Desenvolvimento de Sistemas | Unidade 8 - Estudos de Casos com Uso de Software CASE 
O Bizagi Modeler pode ser encontrado na internet. Pesquise pelo software Bizagi.
Saiba mais
8.3 Estudo de caso
A seleção de uma ferramenta CASE exige a definição de diversos parâmetros que devem ser observados e 
analisados. Existem variados processos para a escolha de ferramentas, mas estes não servem em todas as 
situações. Os pontos que eles levam em consideração podem ser inúteis em alguns tipos de organização. Para 
a realização de um estudo de caso sobre qual ferramenta utilizar em determinada situação, seguem abaixo as 
principais sugestões a serem seguidas:
• Identifique o problema a ser solucionado. O problema a ser resolvido deve estar bem definido muito 
antes da compra de uma ferramenta. Existem pesquisas que mostram que, no desenvolvimento de 
softwares, 70% das ferramentas adquiridas deixam de ser utilizadas após dois anos da sua aquisição, 
sendo que, das que ainda permanecem sendo utilizadas, somente 10% são empregadas de forma correta 
(VAVASSORI, 2001). 
• Identifique os tipos de ferramentas disponíveis. Existe uma infinidade de ferramentas CASE no 
mercado. Algumas características que podem ser utilizadas para a escolha são: propósito, suporte à 
integração, ano de fabricação, fabricante e preço. 
• Decida se irá seguir algum processo de seleção. Existem diversos processos de seleção e, muitas 
vezes, eles acabam divergindo em algum ponto em relação ao que é buscado pela organização. Apesar 
de seguirem o modelo de seleção, é possível que sejam realizadas adaptações, a fim de se adequarem 
melhor à natureza de cada organização. 
• Analise e avalie as ferramentas candidatas. Alguns pontos que podem ser considerados: poder, robustez, 
qualidade do suporte, facilidade de introdução na organização, facilidade de uso, funcionalidade, etc. 
O processo de adoção de uma ferramenta CASE se assemelha bastante ao processo de desenvolvimento de 
software. Analisar quais são os requisitos que essa ferramenta deve ter é fundamental. Exemplo disso é que a 
descoberta tardia de que a ferramenta escolhida não possui todos os requisitos exigidos pode trazer prejuízos à 
organização. Por fim, apesar da adoção e implantação de ferramentas CASE exigir um certo esforço, a redução 
dos custos no dia a dia e o aumento da qualidade do produto justificará todo o trabalho empregado.
 
117
Metodologia de Desenvolvimento de Sistemas | Unidade 8 - Estudos de Casos com Uso de Software CASE 
Síntese da unidade
Esta unidade abordou diversos conceitos relacionados ao uso do software CASE. Foram apresentadas as definições 
de ferramentas CASE, um breve histórico dessas ferramentas, workbenches, bem como sua importância. A 
categorização das ferramentas e seus exemplos também foi abordada. Por fim, apresentou-se um estudo de caso.
118
Considerações finais
As ferramentas CASE utilizadas, sejam em conjunto, sejam de forma 
individual, possuem enorme potencial para mudar todo um processo de 
desenvolvimento de software, desde que utilizadas de forma correta.
119
Referências bibliográficas
BOEHM, Barry W. A spiral model of software development and 
enhancement. Computer, v. 21, 1988.
BR, MPS. MPS.BR – Melhoria de Processo do Software Brasileiro, 2011. 
Disponível em: <http://www.softex.br/wp-content/uploads/2015/09/
palestraKival.pdf>. Acesso em: 29 out. 2018.
BROOKS JR., Frederick P. The mythical man-month. Boston: Addison-
Wesley, 1975.
CARVALHO, André C. P. L. F. de; LORENA, Ana Carolina. Introdução à 
computação: hardware, software e dados. Rio de Janeiro: LTC, 2016.
CERTIFICATION Process. Wikimedia Commons, the free media 
repository, 10 jul. 2014. Disponível em: <https://commons.
w i k i m e d i a . o rg / w / i n d e x . p h p ? t i t le = Fi le : Ce r t i f i c a t i o n Pro ce s s .
png&oldid=128585781>. Acesso em: 05 fev. 2019.
CORDELLI, Rosa Lantmann; LAUREANO, Marcos Aurelio Pchek. 
Fundamentos de software: desempenho de sistemas computacionais. 
São Paulo: Erica, 2014.
CRUZ, Fábio. Scrum e Agile em projetos: guia completo. 2. ed. Rio de 
Janeiro: Brasport, 2015.
Foto de Artem Marchenko. Artem Marchenko and Philippe Kruchten. 
05 ago. 2008. Disponível em: <https://www.flickr.com/photos/
artemfinland/2736917591>. Licenciada por Creative Commons. Acesso 
em: 31 jan. 2019.
120120
FRED Brooks. Wikimedia Commons, the free media repository. 30 nov. 
2016. Disponível em: <https://commons.wikimedia.org/wiki/File:Fred_
Brooks.jpg?uselang=pt-br >. Acesso em: 15 jan. 2019. 
JACOBSON, Ivar; BOOCH, Grady; RUMBAUGH, James. The unified 
software development process. Boston: Addison-Wesley, 1999.
KHAN, Usman Ali; AL-BIDEWI, I. A.; GUPTA, Kunal. Object-oriented 
software methodologies: roadmap to the future. International Journal 
of Computer Science Issues (IJCSI), 2011.
KRUCHTEN, P. The rational unified process: an introduction. Boston: 
Addison-Wesley Professional, 2003.
MACHADO, Felipe Nery Rodrigues. Banco de dados: projeto e 
implementação. São Paulo: Erica, 2014. 
MACHADO, Rodrigo Prestes; FRANCO, Márcia Islabão; BERTAGNOLLI, 
Silvia de Castro. Desenvolvimento de software III: programação de 
sistemas web orientada a objetos em Java. Porto Alegre: Bookman, 2016. 
MARTIN, James. Rapid application development. Londres: Macmillan 
Publishing, 1991.
MOORE, Aubrey. CASE: computer aided software engineering - Brief 
outline of CASE history. South Yorkshire: SheffieldHallan University, 1996. 
Disponível em: <http://www.shu.ac.uk/schools/cms/student/amoore/
case/caseh.html>. 
O LENDÁRIO Barry Boehm. Wikimedia Commons, the free media 
repository. 09 jan. 2018. Disponível em: <https://commons.wikimedia.
org/wiki/File:O_lend%C3%A1rio_Barry_Boehm.jpg>. Acesso em: 18 jan. 
2019.
OLIVEIRA, Jair Figueiredo de. Metodologia para desenvolvimento de 
projeto de sistemas. 4. ed. São Paulo: Érica, 1999. 
121121
PARK, Robert E.; GOETHERT, Wolfhart B.; FLORAC, William A. Goal driven 
software measurement: a guidebook. Pittsburgh: Carnegie Mellon 
University, 1996.
PRESSMAN, Roger S.; MAXIM, Bruce R. Engenharia de software: uma 
abordagem profissional. 8. ed. Porto Alegre: AMGH, 2016.
ROYCE, Winston W. Managing the development of large software systems. 
Proceedings of the IEEE WESCON, 26, 328-388,1970.
SCHWABER, Ken. Scrum development process: business object design 
and implementation. New York City: Springer, 1997.
SHELLY, Gary B.; ROSENBLATT, Harry J. System analysis and design. 9. ed. 
Boston: Shelly Cashman Series, 2012.
SOMMERVILLE, Ian. Engenharia de software. 8. ed. São Paulo: Pearson 
Education, 2007.
STAIR, Ralph M.; REYNOLDS, George W. Princípios de sistemas de 
informação. 11. ed. São Paulo: Cengage Learning Editores, 2016.
SUTHERLAND, Jeff. Scrum: a arte de fazer o dobro do trabalho na metade 
do tempo. São Paulo: Casa da Palavra, 2016.
TAKEUCHI, Hirotaka; NONAKA, Ikujiro. The new product development 
game. Harvard business review, 1986.
VAVASSORI, Fabiane Barreto; SOUZA, Everton Wilson; FIAMONCINI, Julio 
César. Ferramenta CASE para gerenciamento de projetos e métricas de 
software. Tools Session of XV SBES. Rio de Janeiro, 2001.
WINSTON W. Royce. Wikimedia Commons, the free media repository. 
12 nov. 2017. Disponível em: <https://commons.wikimedia.org/w/index.
php?title=File:WWRoyce.jpg&oldid=267242795>. Acesso em: 15 jan. 
2019.
	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