122890

Prévia do material em texto

Modelos de ciclo de vida de software
Você vai compreender o que é produto software, os métodos ágeis no desenvolvimento, princípios do
manifesto ágil, conceitos de Engenharia de Software, modelos de qualidade e como métricas contribuem
para melhorar processos e resultados.
Prof. Carlos Alberto de Farias
1. Itens iniciais
Propósito
O conhecimento sobre métodos ágeis, medição e qualidade de software é fundamental para profissionais da
área de TI, pois permite gerenciar projetos com mais eficiência, controlar custos e prazos, além de
implementar melhorias contínuas nos processos de desenvolvimento.
Objetivos
Propor melhorias no gerenciamento de projetos de software, utilizando técnicas de qualidade para
rastreamento, monitoramento e controle eficazes.
 
Classificar os diferentes modelos de ciclo de vida de software, analisando suas características,
aplicações e adequação a distintos contextos de desenvolvimento.
Introdução
Neste conteúdo, você vai explorar os principais conceitos relacionados ao desenvolvimento de software,
entendendo desde o que é um produto software até como ele é planejado, construído e gerenciado dentro de
projetos. Serão apresentados os fundamentos do Manifesto Ágil para Desenvolvimento de Software, seus 12
princípios norteadores e a importância de sua aplicação no contexto de projetos modernos. Você também terá
contato com conceitos essenciais da Engenharia de Software e com as principais atividades envolvidas no
processo de desenvolvimento.
 
Além disso, será possível conhecer a Declaração de Interdependência no gerenciamento de projetos ágeis e
alguns dos métodos mais utilizados nesse modelo, como o Feature Driven Development (FDD), o Dynamic
Systems Development Method (DSDM) e o Crystal. Esses métodos oferecem abordagens diferentes, mas
complementares, para a condução eficiente de projetos, promovendo entregas incrementais e foco nas
necessidades do cliente.
 
Outro ponto central é a medição e os modelos de qualidade de software. Entender como implantar programas
de medição nas organizações permite controlar melhor os processos e melhorar continuamente a qualidade
dos produtos desenvolvidos. Essa prática é essencial para garantir desempenho, produtividade e
confiabilidade em soluções tecnológicas.
 
A adoção de métricas eficazes está diretamente ligada ao sucesso dos projetos, já que muitas iniciativas
fracassam ou enfrentam atrasos e custos excessivos justamente pela falta de controle adequado. Assim, este
conteúdo oferece uma base sólida para profissionais que desejam atuar com eficiência na área de
desenvolvimento de software, com foco em qualidade, agilidade e resultados sustentáveis.
• 
• 
1. O que é engenharia de software
Contextualização
O mundo moderno exige cada vez mais tecnologia e novas plataformas de gestão da informação e
comunicação.
 
O software hoje está voltado não só para a web, mas também para diversos segmentos como indústria,
comércio, saúde, segurança e muito mais. Além disso, atua na inteligência artificial, estando presente nos
eletrodomésticos como TV, geladeiras, lavadoras, micro-ondas, sistema elétrico residencial e muitos outros.
O que é projeto?
Projeto é um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo.
Também pode ser descrito como: “uma original organização de pessoas e recursos para atingir um
propósito específico, num período de tempo finito”.
Esmiuçando um pouco essa definição, temos:
Original
Cada projeto é diferente de todos os outros.
Organização de pessoas e recursos
Uma mistura de talentos e conhecimentos humanos, com recursos técnicos e físicos.
Para atingir um propósito específico
Enfatiza a necessidade de os projetos terem sempre um objetivo tangível e realizável.
Num período de tempo finito
Diferencia um projeto de um processo.
O que é software?
Software é “uma sequência de instruções a serem executadas, com o objetivo de gerar informações
a partir de uma série de dados coletados ou armazenados”. Também podemos definir como sendo
“os programas que comandam o funcionamento de um computador”.
Podemos classificar o software como a parte lógica cuja função é fornecer instruções para o hardware.
 Composição e classificação do software
Composição do software
Um software é composto por módulos, instruções, bibliotecas, que gera um programa executável que
lê dados denominados “entradas” ou inputs ao final do processo de desenvolvimento, e este, quando
executado, recebe algum tipo de “entrada” de dados (input), processa as informações e libera uma
“saída” (output) como resultado deste processamento.
Classificação do software
Podem os softwares podem ser classificados em três tipos:
Software de sistema: é o conjunto de informações que gerenciam o hardware, que permitindoe
a interação entre o usuário e os periféricos do computador. Exemplos: Windows e Linux.
Software de orogramação: é o conjunto de ferramentas que permitem ao programador
desenvolver sistemas informáticos. Exemplos: exemplo, C++, C#, VB, ASP, Delphi, GO.
Software de aplicação: são programas de computadores que permitem ao usuário executar
uma série de tarefas específicas em diversas áreas de atividade. Exemplos: planilha eletrônica,
editores de texto e editores de apresentações (como PowerPoint).
Manifesto
Diferentes tipos de projetos necessitam de diferentes métodos de gerenciamento. A abordagem ágil é muito
utilizada em projetos orientados a valor.
 
Existem diversos tipos de abordagens ágeis, e estas buscam estar alinhadas com diversos princípios definidos
no documento Manifesto for Agile Software Development, criado em fevereiro de 2001 por diversos
especialistas em projetos de software.
 
Tipos de programação ágil:
• 
• 
• 
Manifesto para desenvolvimento ágil de software
Estamos descobrindo maneiras melhores de desenvolver softwares, fazendo-os nós mesmos e ajudando
outros a fazerem o mesmo. Através deste trabalho, passamos a valorizar (valores declarados do Manifesto):
 
Indivíduos e interações mais que processos e ferramentas;
 
Software em funcionamento mais que documentação abrangente;
 
Colaboração com o cliente mais que negociação de contratos;
 
Responder a mudanças mais que seguir um plano.
 
Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda. A seguir, vamos
verificar cada um desses itens.
Programação extrema – XP (eXtreme
Programming) 
Muito
utilizado
para equipes
pequenas e
médias que
desenvolvem
softwares
com
requisitos
vagos e em
constantes
mudanças.
 A estratégia
adotada é de
constante
acompanhamento
e realização de
vários pequenos
ajustes durante o
desenvolvimento
de software. Tem
valores
fundamentais
como:
comunicação,
simplicidade,
feedback,
coragem e
respeito.
 Em um projeto,
existem
variáveis de
controle do tipo
custo, tempo,
qualidade e
escopo. O XP
tem um foco
explícito em
escopo. Assim,
recomenda-se
a priorização de
funcionalidades
que
representem o
maior valor
possível para o
negócio.
 Um fator
importante no
XP é que ele
incentiva o
controle da
qualidade
como variável
do projeto,
pois o
pequeno
ganho de
curto prazo na
produtividade,
ao diminuir a
qualidade,
não é
compensado
por perdas
em médio e
longo prazo.
Método Scrum 
Scrum não é
um processo
prescribente,
ou seja, não
descreve o
que fazer
em cada
situação. Ele
é usado para
trabalhos
complexos
nos quais é
impossível
predizer
tudo o que
irá ocorrer.
 É um processo
de
desenvolvimento
iterativo e
incremental
(criado em
resposta às
fraquezas do
modelo em
cascata) para
gerenciamento
de projetos e
desenvolvimento
ágil de software.
 Muito usado
em trabalhos
complexos,
nos quais não
há previsão
exata do que
se pretende
desenvolver.
No caso do
Scrum, o
projeto é
dividido em
ciclos
(chamados de
sprints), que
correspondem
à iteração.
 Projetos
orientados a
valor
geralmente
são realizados
por
profissionais
do
conhecimento
e têm elevado
grau de
incerteza, por
terem grande
indefinição do
escopo e
elevado
número de
mudanças.
• 
• 
• 
• 
Indivíduose interações
Observe que o primeiro valor do manifesto deixa claro uma importante mensagem. Processos e as
ferramentas serão necessários no projeto; porém, devemos tentar concentrar a atenção da equipe
sobre os indivíduos e interações envolvidos no projeto.
Lembre-se que projetos são realizados por pessoas, e não por ferramentas, assim como os problemas
são resolvidos por pessoas, e não por processos.
Focando primariamente no desenvolvimento dos indivíduos envolvidos no projeto e enfatizando as
interações produtivas e eficazes, melhoramos as chances de sucesso do projeto.
Isso, no entanto, não quer dizer que processos e ferramentas não podem ajudar na conclusão de um
projeto com êxito. Processos e ferramentas bem desenhados e adequados são ativos de grande
importância.
São as denominadas ferramentas CASE (Computer-Aided Software Engineering), que correspondem a
todas as ferramentas que auxiliam os projetos de software, indo da análise de requisitos, modelagem
até a implementação e os testes.
Seu objetivo é auxiliar o desenvolvedor em todo o ciclo de desenvolvimento de software.
Software em funcionamento
O segundo valor do manifesto destaca a necessidade de entregar o software. Projetos de software
são iniciados com o objetivo de criar valor para a empresa por meio de um produto de software de
alta qualidade, mas muitas vezes entregar em partes intermediárias (incrementos).
Raramente a documentação é atualizada de forma completa e reflete a realidade do software, porém
é essencial documentar o que é preciso em um software, sem exagero.
Lembre-se sempre que software sem documentação é certamente problemático e dificulta o suporte
e a manutenção. Contudo, uma documentação completa sem software não agrega absolutamente
nada.
Colaboração com o cliente
O terceiro valor reforça a necessidade de ser flexível e eficiente, em vez de rígidos e não
cooperativos. É semelhante à diferença entre “estar certo” e “fazer a coisa certa”.
Poderíamos construir o produto exatamente como originalmente especificado, mas se o cliente mudar
de ideia ou de prioridade, você não concorda que devemos ser flexíveis e trabalhar para a nova meta?
É claro que sim. As mudanças e ajustes deverão ser refletidos em aditivos contratuais ou ajustes, mas
não deve ser um impeditivo para a continuidade do desenvolvimento e entrega do software.
Atualmente existem diversas novas formas de contratos para acolher projetos com características
ágeis, como pagamento de preço fixo por interação (ou sprint), pagamento por pontos, histórias ou
outras que permitem a flexibilidade necessária para projetos orientados a valor.
Responder a mudanças 
Em projetos com grande número de incertezas, é quase certo que os planos iniciais serão alterados.
Em vez de investir esforços na tentativa de trazer o projeto de volta aos planos originais, nós
deveríamos gastar esforço e energia para responder às inevitáveis mudanças no projeto.
Observe que esse valor não está sugerindo abandonar o planejamento e apenas reagir às mudanças.
Nós ainda precisamos planejar, mas temos de reconhecer que os planos iniciais foram criados quando
conhecíamos menos sobre o projeto (no início), e com o desenvolvimento do trabalho, vamos precisar
atualizar o plano.
Muitos dos métodos ágeis focam em macroplanos superficiais (criação de histórias, product release,
casos de uso etc.) e em um planejamento específico para iterações (ou sprints).
Saiba mais
Conheça os 12 princípios por trás do Manifesto. 
Declaração de Interdependência
Em 2005, a Agile Leadership Network - ALN criou a Declaração de Interdependência para Gerenciamento de
Projetos Ágeis.
 
Esse documento promove abordagens ágeis e adaptáveis para unir as pessoas, projetos e valor. Para alcançar
esses resultados:
 
Aumentamos o retorno sobre o investimento, fazendo fluxo contínuo de valor, o nosso foco;
 
Entregamos resultados confiáveis por envolver os clientes em interações frequentes e compartilhamos
a propriedade;
 
Esperamos a incerteza e a gerenciamos através de iterações, antecipações e adaptações;
• 
• 
• 
 
Liberamos a criatividade e a inovação, reconhecendo que os indivíduos são a melhor fonte de valor, e
criando um ambiente onde eles podem fazer a diferença;
 
Melhoramos o desempenho através de prestação de contas do grupo para resultados e
responsabilidade compartilhada para a eficácia do time;
 
Melhoramos a eficácia e confiabilidade por meio de estratégias específicas, processos e práticas.
Outras metodologias e frameworks ágeis
Feature Driven Development - FDD (Desenvolvimento Dirigido a
Funcionalidades)
Foi concebido originalmente por Jeff de Luca. O FDD surgiu em Singapura, entre os anos de 1997 e 1999 com
base no método Coad (Criado por Peter Coad – 1980/1990) e nos processos interativos e lean já utilizados por
de Luca.
 
É uma abordagem poderosa para o desenvolvimento de produtos. Busca o desenvolvimento por
funcionalidade através de um requisito funcional do sistema. Uma equipe de projeto seguindo o método FDD
primeiro desenvolve um modelo global para o produto, constrói uma lista de recursos e planeja o trabalho.
 
A equipe então se move através da concepção e construção de iterações para desenvolver cada recurso. O
FDD busca apresentar resultados frequentes, tangíveis e funcionais.
Atenção
O FDD pode atuar em conjunto com outras metodologias, principalmente com o Scrum, encaixando-se
perfeitamente como metodologia de engenharia ágil de software com projeto ágil. 
Desenvolva um modelo global para o produto.
 
Crie uma lista de funcionalidades.
 
Planeje por funcionalidade.
 
Projete por funcionalidade.
 
Construa por funcionalidade.
• 
• 
• 
• 
• 
• 
• 
• 
 
O FDD recomenda uma série de boas práticas oriundas da Engenharia de Software, como:
 
Modelagem de domínio do objeto: as equipes de explorar e explicar o domínio (ou ambiente de
negócios) do problema a ser resolvido;
 
Desenvolvimento por funcionalidade: esta prática envolve decompor as necessidades em
funcionalidades e definir períodos de desenvolvimento de uma ou mais funcionalidades em intervalos
de duas semanas ou mais curtos;
 
Propriedade individual (código): as áreas de código devem ter um único proprietário para garantir
consistência, desempenho e integridade conceitual. (Nota-se que é bem diferente da ideia de
propriedade código coletiva do XP, que visa difundir o conhecimento para outros membros da equipe);
 
Times dinâmicos: devem-se formar pequenas equipes, de forma dinâmica, de acordo com
características de cada projeto. Os times ajudam a mitigar o risco associado à propriedade individual;
 
Inspeções: são revisões que ajudam a garantir boa qualidade e design de código;
 
Gerenciamento de configuração: essa prática envolve rotulagem de código, controle de alterações e
gerenciamento do código-fonte;
 
Construções regulares: através de entregas pequenas e constantes, o time incrementa o produto de
software com a nova funcionalidade desenvolvida. Esta prática também permite criar facilmente uma
versão demo;
 
Visibilidade: controle e acompanhamento do progresso dos resultados, baseados em funcionalidades
desenvolvidas.
 
Para comparação, é importante mostrar o percentual de tempo gasto em cada etapa:
 
Levantamento do domínio da aplicação = 1%;
 
Projeto = 40%;
 
Inspeção do projeto = 3%;
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
 
Desenvolvimento = 45%;
 
Inspeção do código = 10%;
 
Integração = 1%.
Você poderá aprofundar seus conhecimentos sobre o FDD, acessando o Feature Driven Development, website
oficial da metodologia. 
Feature Driven Development
Consultado na internet em 16 maio 2019.
Dynamic Systems Development Method - DSDM (Metodologia de Desenvolvimento de Sistemas Dinâmicos),
foi um dos pioneiros dos métodos ágeis. É uma metodologia de desenvolvimento bastante prescritiva,
baseada em Rapid Application Development - RAD (Desenvolvimento Rápido de Aplicações), que enfatiza o
envolvimento constante do usuário durante todoo projeto.
 
Oferece uma metodologia para construir e manter sistemas que atendem restrições de prazo apertado,
através do uso da prototipagem incremental. Cria três ciclos iterativos, abrangendo aspectos de um projeto
ágil, analisando sempre a viabilidade e necessidade do negócio para a implementação.
Ciclo de vida do DSDM
O ciclo de vida do DSDM é iterativo e incremental. Portanto, a solução não pode ser entregue à empresa de
uma só vez, mas de uma série de incrementos que facilitam a solução com cada entrega.
 
Dessa forma, as necessidades de negócios urgentes podem ser priorizadas e abordadas cedo, enquanto
características menos importantes são implementadas e entregues mais tarde.
 
A natureza iterativa permite que os representantes de negócios vejam e se envolvam no trabalho em
construção, analisando e já sugerindo os ajustes e alterações necessárias durante o desenvolvimento de um
incremento da solução.
 
O DSDM pode ser utilizado sozinho como metodologia ágil, porém o seu uso com outros métodos e boas
práticas de gerenciamento de projetos ou técnicas de desenvolvimento detalhados podem contribuir para a
melhora nos processos e resultados.
 
Os ciclos são:
 
1. A iteração de modelos funcionais: neste ciclo, é produzido um conjunto de protótipos incrementais que
demonstram a funcionalidade para o cliente;
 
• 
• 
• 
2. A iteração de projeto e desenvolvimento: neste ciclo, revisitamos os protótipos desenvolvidos durante a
iteração de modelos funcionais para assegurar que cada um tenha passado por um processo de engenharia
para capacitá-los a oferecer aos usuários finais valor de negócio em termos operacionais;
 
3.Implementação: no qual colocamos a última versão do incremento de software (um protótipo
operacionalizado) no ambiente operacional.
Atenção
 Em qualquer dos casos, o trabalho do desenvolvimento do DSDM continua, retornando à atividade de
iteração do modelo funcional. 
Conteúdo interativo
Acesse a versão digital para ver mais detalhes da imagem
abaixo.
 Ciclo de vida DSDM.
Você poderá aprofundar seus conhecimentos sobre o DSDM, acessando o site oficial da metodologia,
Crystal
Crystal é uma família de metodologias (Família Crystal de Metodologia) desenvolvidas por Alistair Cockburn,
em meados da década de 1990.
 
Ela inclui um grande número de métodos diferentes, que são selecionados de acordo com as características
do projeto a ser desenvolvido, destinadas para projetos que vão desde aqueles executados por pequenas
equipes de desenvolvimento com baixa criticidade e provê abordagens até com grandes equipes que
implementam sistemas de alta criticidade.
 
Características comuns à família Crystal:
 
Desenvolvimento incremental com ciclos de no máximo quatro meses;
 
Ênfase maior na comunicação e cooperação das pessoas;
 
Não limitação de quaisquer práticas de desenvolvimento, ferramentas ou produtos de trabalho;
 
Incorporação de objetivos para reduzir produtos de trabalho intermediários e desenvolvê-los como
projetos evoluídos;
 
Utilização de cores diferentes para indicar o "peso" do projeto e qual metodologia aplicar.
Conteúdo interativo
Acesse a versão digital para ver mais detalhes da imagem
abaixo.
 Método Crystal. 
Princípios ágeis da família Crystal:
 
Entregas frequentes.
• 
• 
• 
• 
• 
• 
 
Melhoria reflexiva: verificação constante e busca contínua de promoção de melhoria e implementação
de novos métodos;
 
Comunicação osmótica: membros são alocados próximos uns dos outros para melhorar a comunicação,
conceito também conhecido como War Room (Sala de Guerra);
 
Segurança pessoal: o Crystal defende um ambiente seguro para que todos possam apresentar suas
dúvidas e questionamentos;
 
Foco: cada membro do time deve saber o que precisa fazer e ter liberdade suficiente para trabalhar no
que é necessário;
 
Fácil acesso ao usuário: fácil acesso aos usuários chaves e rápido feedback;
 
Ambiente automatizado: testes automatizados, controle de configurações, integração contínua etc.
 
Você poderá aprofundar seus conhecimentos sobre o Crystal, acessando o: Alistair Cockburn, web site do
criador destas metodologias. 
Verificando o aprendizado
Questão 1
Analisando o conteúdo da aula, faça uma reflexão sobre as características dos princípios ágeis e das
metodologias apresentadas e verifique se você utiliza (ou poderia utilizar) alguma destas características em
seu dia a dia nos projetos de software.
 
I) Processos e ferramentas não são importantes segundo o Manifesto Ágil, já que priorizam indivíduos e
interações.
II) Colaboração com o cliente mais que negociação de contratos significa que não vamos ignorar os contratos,
mas a prioridade é atender o cliente e não parar o projeto para discutir contratos. Os contratos podem/devem
ser negociados sem prejudicar o trabalho em andamento.
III) Nos métodos ágeis não planejamos (executamos direto para ganhar tempo).
 
Assinale a alternativa correta:
A Apenas a alternativa II está correta.
• 
• 
• 
• 
• 
• 
B Apenas as alternativas I e II estão corretas.
C Apenas as alternativas II e III estão corretas.
D Apenas a alternativa III está correta.
E Todas as alternativas estão corretas.
A alternativa A está correta.
Indivíduos e interações mais que processos e ferramentas:
Observe que o primeiro valor do manifesto deixa claro uma importante mensagem, processo, e as
ferramentas provavelmente serão necessárias no projeto, porém devemos tentar concentrar a atenção da
equipe sobre os indivíduos e interações envolvidos no projeto.
Lembre que projetos são realizados por pessoas, e não por ferramentas, assim como os problemas são
resolvidos por pessoas, e não processos.
Focando primariamente no desenvolvimento dos indivíduos envolvidos no projeto e enfatizando as
interações produtivas e eficazes, melhoramos as chances de sucesso do projeto.
Lembre que isso não é dizer que processos e ferramentas não podem ajudar na conclusão de um projeto
com êxito. Processos e ferramentas bem desenhados e adequados são ativos de grande importância.
Responder a mudanças mais que seguir um plano:
Em projetos com grande número de incertezas, é quase certo que os planos iniciais serão alterados. Em
vez de investir esforços na tentativa de trazer o projeto de volta aos planos originais, nós deveríamos
gastar esforço e energia responder às inevitáveis mudanças no projeto.
Observe que este valor não está sugerindo abandonar o planejamento e apenas reagir às mudanças. Nós
ainda precisamos planejar, mas temos de reconhecer que os planos iniciais foram criados quando
conhecíamos menos sobre o projeto, e com o desenvolvimento do trabalho, vamos precisar atualizar o
plano.
Muitos dos métodos ágeis focam em macroplanos superficiais (criação de histórias, product release, casos
de uso etc.) e um planejamento mais específico para iterações (ou sprints).
Questão 2
Indique a alternativa que NÃO é um dos 12 princípios ágeis:
A Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto.
B Simplicidade - a arte de maximizar a quantidade de trabalho não realizado é essencial.
C Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferência
à menor escala de tempo.
D Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte necessário e
confie neles para fazer o trabalho.
E Mudanças nos requisitos não são bem-vindas, quando tardiamente no desenvolvimento aumentam as
despesas e desanimam a equipe.
A alternativa E está correta.
Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento. Processos ágeis tiram
vantagem das mudanças visando vantagem competitiva para o cliente.
Questão 3
É uma abordagem simples de entender e poderosa para o desenvolvimento de produtos. Uma equipe de
projeto seguindo este método irá primeiro desenvolver um modelo global para o produto, construir uma lista
de recursos e planejar o trabalho. A equipe então se move através da concepção e construçãode iterações
para desenvolver cada recurso. Este método busca apresentar resultados frequentes, tangíveis e funcionais.
 
A descrição acima refere-se a que método?
A Feature Driven Development - FDD (Desenvolvimento dirigido a funacionalidades).
B Crystal Red.
C Dynamic Systems Development Method - DSDM (Metodologia de Desenvolvimento de Sistemas
Dinâmicos).
D Crystal Yellow.
E Crystal Clear.
A alternativa A está correta.
O FDD - Feature Driven Development significa “desenvolvimento dirigido a funcionalidades” e busca o
desenvolvimento por funcionalidade através de um requisito funcional do sistema.
Uma equipe de projeto seguindo o método FDD irá primeiro desenvolver um modelo global para o produto,
construir uma lista de recursos e planejar o trabalho.
Questão 4
Este método foi um dos pioneiros dos métodos ágeis. É uma metodologia de desenvolvimento bastante
prescritiva, baseada em Rapid Application Development - RAD (Desenvolvimento Rápido de Aplicações), que
enfatiza o envolvimento constante do usuário durante todo o projeto.
 
Cria um amplo ciclo de vida de projeto, abrangendo aspectos de um projeto ágil analisando sempre a
viabilidade e necessidade do negócio para a implementação.
 
O ciclo de vida deste método é iterativo e incremental. Portanto, a solução não pode ser entregue à empresa
de uma só vez, mas de uma série de incrementos que melhoram a solução com cada entrega.
 
Dessa forma, as necessidades de negócios urgentes podem ser priorizadas e abordadas cedo, enquanto
características menos importantes são implementadas e entregues mais tarde.
 
A descrição acima refere-se a que método?
A Feature Driven Development - FDD (Desenvolvimento Dirigido a Funcionalidades).
B Crystal Red.
C Dynamic Systems Development Method - DSDM (Metodologia de Desenvolvimento de Sistemas
Dinâmicos).
D Crystal Yellow.
E Crystal Clear.
A alternativa C está correta.
O DSDM é o método que cria um amplo ciclo de vida de projeto, abrangendo aspectos de um projeto ágil,
analisando sempre a viabilidade e a necessidade do negócio para a implementação, podendo ser iterativo e
incremental.
2. Modelos de ciclo de vida de software
Contextualização e modelos
O mundo moderno exige cada vez mais tecnologia e novas plataformas de gestão da informação e
comunicação.
 
O software hoje está voltado não só para a web, mas também para diversos segmentos como indústria,
comércio, saúde, segurança e muito mais. Além disso, atua na inteligência artificial, estando presente nos
eletrodomésticos como TV, geladeiras, lavadoras, micro-ondas, sistema elétrico residencial e muitos outros.
Estudado dentro da área de Engenharia de Software, é considerado um fator fundamental para a obtenção de
softwares de qualidade.
Por que é importante utilizar um modelo de ciclo de vida para desenvolver softwares?
A resposta é simples: o modelo de ciclo de vida é a primeira escolha a ser feita no processo de software, que
abrange a vida do sistema, desde a definição de requisitos até a conclusão do projeto e entrega do produto.
Comentário
Esse ciclo de vida está agrupado em fases, como: definição de requisitos, análise, projeto,
desenvolvimento, teste e implantação. Em cada fase são definidas, além das atividades, as funções e
responsabilidades de cada membro da equipe do projeto. 
É necessário conhecer as características do projeto a ser desenvolvido para escolhermos o melhor ciclo de
vida e os recursos humanos empregados no projeto.
 
Esses devem ser reconhecidamente capazes de enfrentar os desafios que se apresentam diante das
dificuldades inerentes de todo e qualquer projeto de software.
 
Principais modelos de ciclo de vida de software:
 
Cascata;
 
Modelo em V;
 
Modelo incremental;
 
Evolutivo;
 
Iterativo e incremental;
 
RAD;
 
Prototipagem;
 
Espiral;
 
Modelo de ciclo de vida associado ao RUP.
 
Assista ao vídeo e veja esses modelos mais detalhadamente.
Conteúdo interativo
Acesse a versão digital para assistir ao vídeo.
Cascata
O modelo cascata, ou sequencial linear, é considerado o mais antigo e o mais usado na engenharia de
software em todo o mundo. Este é o grande mérito deste modelo.
Seu nome foi atribuído devido à sequência com que cada fase do desenvolvimento dependia do
término da fase anterior, ou seja, o resultado de uma fase era utilizado com a entrada para a fase
seguinte.
Nesse modelo, a ênfase maior ficava por conta das fases de análise e projeto antes de iniciar a implementação
(codificação).
• 
• 
• 
• 
• 
• 
• 
• 
• 
Conteúdo interativo
Acesse a versão digital para ver mais detalhes da imagem
abaixo.
Modelo cascata.
É possível retornar a uma etapa anterior; entretanto deve-se analisar muito bem em relação às áreas técnica e
financeira, sem prejuízo das partes envolvidas.
Modelo em V
Este modelo é uma variação do cascata, ajustando as atividades de testes com as fases de análise e projeto.
 
Da mesma forma que no cascata, o modelo em V é sequencial, o que significa que cada fase necessita ser
concluída antes do início da fase seguinte.
Conteúdo interativo
Acesse a versão digital para ver mais detalhes da imagem
abaixo.
Vantagens do modelo cascata 
A fase de
análise de
requisitos
(única) leva
ao projeto
do sistema
e, por sua
vez, antes
da fase de
codificação;
 Ao final de
cada fase e
antes de
iniciar a
seguinte,
devem ser
feitas
revisões
com a
participação
do usuário;
 Cada etapa
(fase) deve
passar por
aprovação e
documentação,
visando o
passo
seguinte.
Desvantagens do modelo cascata 
O fluxo
sequencial
proposto
pelo
modelo
geralmente
não é
seguido;
 O modelo
cascata
exige que os
requisitos
sejam
claramente
definidos e
completos,
pois são
estabelecidos
na fase
inicial do
projeto;
 O módulo
executável para
testes somente
fica disponível ao
final do projeto,
isto é, na etapa
avançada do
desenvolvimento,
exigindo um
grande esforço.
• • • 
• • • 
Modelo em V.
Como podemos observar, no modelo em V os procedimentos de testes são planejados em praticamente todas
as fases do desenvolvimento, diferentemente do que ocorre no modelo em cascata.
Incremental
 Assista o vídeo e conheça o modelo incremental.
Conteúdo interativo
Acesse a versão digital para assistir ao vídeo.
No modelo incremental, as novas funcionalidades ou necessidades do usuário são integradas de forma
segmentada e em série até a conclusão do produto final.
 
Este modelo se propõe a aumentar pouco a pouco o software, conforme as necessidades surgem.
Conteúdo interativo
Acesse a versão digital para ver mais detalhes da imagem
abaixo.
Vantagens do modelo em V 
Maior chance de
sucesso quando
comparado com o
modelo cascata,
devido ao
desenvolvimento de
planos de teste desde
as fases iniciais;
 Funciona
bem para
projetos
pequenos,
nos quais os
requisitos
são
facilmente
entendidos.
Desvantagens do modelo em V 
Tão
rígido
quanto
o
modelo
cascata;
 Requisitos devem ser
estabelecidos
corretamente e de
forma clara no início
do projeto.
• • 
• • 
Modelo incremental.
O modelo incremental deve ser adotado quando os requisitos são claramente conhecidos na fase inicial do
desenvolvimento e há a necessidade de entrega de um módulo ou funcionalidade do software em curto
espaço de tempo.
Atenção
É importante notar que, a cada incremento, uma nova versão do software é produzida. 
Conteúdo interativo
Acesse a versão digital para ver mais detalhes da imagem
abaixo.
Fases do modelo incremental.
Modelo evolutivo
O modelo evolutivo obedece a um processo que visa o desenvolvimento do software a partir de requisitos de
protótipos iniciais.
 
Neste modelo, as versões parciais são desenvolvidas para atender aos requisitos levantados inicialmente.
Assim, a primeira versão é usada para refinar os requisitos visando uma segunda versão e, a partir do
conhecimento obtido com o uso, o desenvolvimento prossegue, evoluindo, então, o produto.
Iterativo e incremental
Assista ao vídeo e conheça o modelo iterativo e incremental.
Conteúdo interativo
Acesse a versãodigital para assistir ao vídeo.
O processo de desenvolvimento em cascata apresenta uma série de vantagens, porém tem também
alguns pontos fracos. Para solucionar este impasse, estudiosos de TI criaram o modelo de
desenvolvimento iterativo e incremental.
Esse modelo trouxe bastante agilidade e flexibilidade nos processos de desenvolvimento de software, o que
permitiu uma maior capacidade de lidar com as demandas do mercado e, assim, atingir melhores resultados
em médio e longo prazo.
 
Vantagens do modelo incremental 
A entrega da
primeira versão
apresenta um menor
custo e menos
tempo se
comparado com os
modelos em cascata
e em V;
 Poucos riscos
associados ao
desenvolvimento
dos incrementos
devido ao seu
tamanho
reduzido.
Desvantagens do modelo incremental 
No caso de requisitos mal definidos ou
incompletos, alguns incrementos
podem ser retrabalhados, o que gera
custos e atrasos.
• • 
Vantagens do modelo evolutivo 
É usado quando
os requisitos se
apresentam
incompletos no
início do
desenvolvimento;
 Com o uso do
sistema, o
conhecimento sobre
o produto vai
aumentando e,
consequentemente,
melhorando os
requisitos.
Desvantagens do modelo evolutivo 
É necessário um
rígido controle
sobre os custos,
grande
preocupação
com o
cronograma e
com a
configuração do
software;
 Usuários
precisam
estar
preparados
quanto aos
resultados
iniciais, que
podem
parecer
insatisfatórios.
• • 
• • 
Basicamente, este modelo divide o desenvolvimento do software em pequenos ciclos ou módulos ou novas
funcionalidades. Cada funcionalidade deve corresponder a uma necessidade do usuário à medida que for
necessária à sua construção.
 
Para o desenvolvimento de cada funcionalidade, é utilizado um pequeno modelo em cascata, objetivando,
assim, atender às necessidades sempre que se fizer necessário.
 
Precisamos, então, identificar as necessidades dos usuários e definir uma escala de prioridades para cada
uma dessas funcionalidades.
Conteúdo interativo
Acesse a versão digital para ver mais detalhes da imagem
abaixo.
Modelo de desenvolvimento iterativo e incremental.
Outros modelos
RAD (Rapid Application Development)
O modelo RAD é um modelo de desenvolvimento de software incremental que enfatiza um ciclo de
desenvolvimento curto e se apresenta de forma sequencial linear.
A rapidez ou velocidade com que o software é desenvolvido se deve pelo fato de várias equipes trabalharem
em paralelo, quando o produto pode ser dividido em módulos. Um projeto de software que utiliza o RAD
consome em média de 60 a 90 dias.
 
O uso deste modelo exige requisitos bem definidos e estabilizados, além de escopo restrito e com
possibilidade de ser dividido em módulos.
Conteúdo interativo
Acesse a versão digital para ver mais detalhes da imagem
abaixo.
Modelo de desenvolvimento iterativo e incremental.
Prototipagem
O modelo prototipagem é utilizado quando é definido um conjunto de objetivos gerais para o software, mas os
detalhes não estão claramente definidos como requisitos de entrada, processamento ou saída.
 
O ciclo do modelo prototipagem começa com a comunicação entre o engenheiro de software e o cliente,
quando são definidos os objetivos gerais do software, identificando as necessidades conhecidas e são
verificadas as áreas que necessitam de mais definição.
 
Os usuários podem fazer simulações com o protótipo, identificando mais detalhadamente funcionalidades que
deverão ser disponibilizadas futuramente.
 
A versão inicial do software ajuda a determinar a viabilidade técnica, custos e prazo do projeto.
 
É importante haver uma forte interação com o usuário para que rapidamente o protótipo seja implementado de
acordo com as etapas:
 
Obtenção dos requisitos;
 
Vantagens do modelo RAD 
O ciclo de
desenvolvimento é
extremamente curto
se comparado com
os demais modelos;
 Distribuição de
tarefas é
facilitada entre
as equipes de
desenvolvimento.
Desvantagens do modelo RAD 
Requer equipes
de
desenvolvimento
adequadas para
atender à
demanda de
projetos grandes
e escaláveis;
 Não é
apropriado
quando os
riscos são
grandes;
 Não é
apropriado
quando o
sistema
precisa
interagir
com
outros
sistemas.
• • 
• • • 
• 
Projeto rápido;
 
Construção do protótipo;
 
Avaliação do protótipo;
 
Refinamento do protótipo;
 
Construção do produto.
Modelo espiral
O modelo espiral se divide em duas etapas principais: análise de riscos e prototipagem. A cada novo ciclo,
esse modelo testa constantemente erros que podem vir a acontecer.
 
A cada iteração, a volta da espiral pode ser baseada em um modelo diferente e pode ter diferentes atividades.
Ou seja, a cada repetição é refeita a análise de a prototipação até que não existam grandes riscos no
desenvolvimento.
 
No modelo espiral, em cada repetição do ciclo devem ocorrer no projeto:
 
Determinação de objetivos.
 
Avaliação e redução de riscos.
 
Desenvolvimento e validação.
 
• 
• 
• 
• 
• 
Vantagens do modelo prototipagem 
O
protótipo
deve ser
avaliado
pelo
usuário;
 A interação do usuário
com o protótipo é
fundamental para ajustar
as necessidades
funcionais.
Desvantagens do modelo prototipagem 
O
usuário
pode
pensar
que a
maior
parte do
software
está
pronta;
 O protótipo pode
crescer de maneira
não planejada, com
risco de se tornar um
incremento funcional;
 
O protótipo pode
confundir o usuário
iludido por um
desempenho melhor
do que um incremento
funcional;
 
O fato de o protótipo
não implementar toda
a funcionalidade pode
causar frustação para
o usuário quando o
sistema completo é
entregue.
• • 
• • 
• 
• 
• 
• 
• 
Planejamento da próxima iteração.
 
Os riscos são considerados à medida que cada evolução é realizada.
 
A primeira atividade se dá com o desenvolvimento de uma especificação de produto, as próximas passagens
podem ser usadas para desenvolver um protótipo e assim sucessivamente.
Conteúdo interativo
Acesse a versão digital para ver mais detalhes da imagem
abaixo.
Modelo espiral.
Cada passagem pela fase do planejamento, por exemplo, resulta em ajustes no planejamento do projeto. O
custo e o cronograma são sempre ajustados de acordo com o feedback obtido do usuário após uma entrega.
 
Na imagem, cada loop representa uma fase de desenvolvimento do software.
RUP (Rational Unified Process)
O RUP foi desenvolvido em 1999 por Jacobson, Booch e Rumbaugh depois de terem definido a UML. É um
processo que integra ciclos, fases e disciplinas, visando a qualidade no gerenciamento de projetos.
 
O ciclo de vida do desenvolvimento do software é dividido nas seguintes fases:
• 
Vantagens do modelo espiral 
Muita
análise
de
riscos;
 Bom para
projetos
grandes
e críticos;
 Software é
produzido
cedo no
ciclo de
vida.
Desvantagens do modelo prototipagem 
Pode
ser
custoso;
 Análise de
riscos
requer
experiência;
 Não se
aplica
bem a
projetos
menores.
• • • • • • 
Concepção
Define o escopo do projeto.
Elaboração
Planeja o projeto, define e valida a arquitetura.
Construção
Construção do software.
Transição
Implantação do software.
As disciplinas requisitos, análise, projeto, implementação, testes e implantação vão estar presentes em cada
uma dessas fases, com maior ou menor ênfase, conforma mostra a imagem:
Conteúdo interativo
Acesse a versão digital para ver mais detalhes da imagem
abaixo.
Disciplinas do modelo RUP.
Verificando o aprendizado
Questão 1
(Fonte: FUNRIO 2013 – MPOG Analista de Tecnologia da Informação)
 
Considere o seguinte problema encontrado em projetos de desenvolvimento de software: projetos reais
raramente seguem um fluxo sequencial. Apesar de um modelo linear poder acomodar a iteração, ele o faz
indiretamente.
 
Como resultado, as modificações podem causar confusão à medida que a equipe de projeto prossegue. Esse
é um dos problemas que são algumas vezes encontrados quando é aplicado qual modelo de
desenvolvimento?
A Em cascata.
B Iterativo e incremental.
C Iterativo.
D Incremental.
E Evolutivo
A alternativa A está correta.
O problema do modelo em cascata é a necessidadede um fluxo sequencial, enquanto os projetos do
mundo real não seguem necessariamente esta sequencialidade.
Questão 2
(Fonte: FCC 2013 – AL-RN Analista Legislativo – Analista de Sistemas).
 
O primeiro modelo de desenvolvimento de software a ser publicado foi derivado de processos mais gerais da
engenharia de sistemas. Por causa do encadeamento entre uma fase e outra, esse modelo é conhecido como
modelo em cascata ou ciclo de vida de software.
 
Dentre seus principais estágios, se encontra a análise e definição de requisitos, o projeto de sistema e
software e...
A A análise de recursos e software.
B O desenvolvimento incremental.
C A geração de relatórios de teste.
D As pesquisas e testes.
E Implementação e teste unitário.
A alternativa E está correta.
De acordo com o modelo cascata apresentado, após a fase de projeto vem a de implementação e teste
unitário.
Questão 3
(Fonte: FUMARC 2012 – TJ-MG Oficial Judiciário – Assistente Técnico de Sistemas).
 
Em relação aos modelos de processos de software, pode-se dizer que os modelos incremental e evolucionário
têm a característica de serem iterativos.
 
Assinale a alternativa que melhor descreve um modelo de produção de software iterativo:
A Os incrementos de um software são entregues ao cliente de uma só vez.
B Um modelo de produção de software iterativo é composto pelas fases de análise de requisitos, projeto,
implementação, testes (validação), integração e manutenção de software.
C
A abordagem iterativa possibilita desenvolver um sistema de software de forma incremental, permitindo ao
desenvolvedor tirar vantagem daquilo que foi aprendido durante a fase inicial de desenvolvimento de uma
versão do sistema. O aprendizado ocorre simultaneamente tanto para o desenvolvedor quanto para o
usuário do sistema.
D Os incrementos de um software são entregues ao cliente somente duas vezes.
E
 Um modelo de produção de software iterativo é composto pelas fases de análise de requisitos, projeto
e implementação.
 
A alternativa C está correta.
Os incrementos são entregues durante todos os ciclos. A etapa de manutenção não entra no ciclo, vai até
desde a elicitação de requisitos até a integração e implantação no cliente. A abordagem iterativa trabalha
também de forma incremental.
Questão 4
(Fonte: UFF 2009 – Analista de Tecnologia da Informação).
 
Em relação aos ciclos de vida do software, o desenvolvimento de sistemas por meio de ciclo de vida iterativos
garante ao sistema:
A Atualização contínua
B Legalidade
C Segurança
D Legibilidade
E Utilização mínima de recursos
A alternativa A está correta.
De acordo com o conteúdo que discutimos nas aulas, o modelo iterativo permite que o software seja
desenvolvido em ciclos, atualizando as suas necessidades em cada ciclo.
Questão 5
(Fonte: CESPE 2010 – Detran-ES – Analista de Sistemas).
Quando um aplicativo de software desenvolvido em uma organização atinge, no fim do seu ciclo de vida, a
fase denominada aposentadoria, descontinuação ou fim de vida, todos os dados por ele manipulados podem
ser descartados.
 
Assinale a alternativa correta:
A Verdadeiro
B Falso
A alternativa B está correta.
Não podemos descartar os dados, somente o software que será substituído por outro.
Questão 6
(Fonte: FCC 2013 – DPE-SP – Agente de Defensoria – Analista de Sistemas).
 
A prototipação representa uma técnica poderosa para o desenvolvimento de sistemas, mais especificamente
do software desses sistemas. Sobre as funções desempenhadas por um protótipo, é correto afirmar que ele:
A Permite avaliar o desempenho geral da equipe de desenvolvimento de software.
B Não permite que sejam realizados testes, visando verificar o funcionamento do sistema final, ainda que
sejam testes parciais.
C É inteiramente descartado, não sendo aproveitada nenhuma parte do código de software no sistema
final entregue ao cliente.
D Não possibilita avaliar a qualidade do software produzido.
E Pode auxiliar na validação de requisitos do sistema, bem como propiciar a inserção de novos requisitos
ainda não identificados.
A alternativa E está correta.
O propósito básico da prototipação é sempre auxiliar na validação e elicitação de requisitos (necessidades)
do software.
Questão 7
(Fonte: FCC 2012 – TST – Analista Judiciário – Analista de Sistemas).
 
O ciclo de vida de um sistema especifica todas as fases de desenvolvimento, desde sua concepção até o
processo de manutenção e declínio. No que diz respeito ao desenvolvimento de softwares, existem alguns
processos conhecidos.
 
Um desses processos tem característica iterativa e incremental, inicia cada fase do projeto realizando um
planejamento prévio, realiza a execução da fase, verifica o progresso e os resultados da fase (riscos, lições
aprendidas) e incrementa novos objetivos para a fase seguinte, seguindo para a próxima iteração. O modelo
de software em questão é:
A O modelo espiral.
B O modelo cascata.
C A prototipação.
D RAD.
E O modelo evolutivo.
A alternativa A está correta.
O modelo espiral caracteriza-se pelo planejamento e pela análise de risco em cada fase da espiral.
Questão 8
Observe um modelo de ciclo de vida para desenvolvimento de sistemas. Nessa abordagem, o
desenvolvimento do produto de software é dividido em ciclos, sendo identificadas, em cada ciclo, as fases de
análise, projeto, implementação e testes.
Conteúdo interativo
Acesse a versão digital para ver mais detalhes da imagem
abaixo.
Esse modelo é conhecido como ciclo de vida…
A Por prototipação em cascata.
B Por estágios em módulos.
C Iterativo e incremental.
D Evolutivo e procedural. 
E Iterativo e evolutivo
A alternativa C está correta.
De acordo com o que discutimos nas aulas, o modelo que é dividido em ciclos e contempla as fases do
modelo é o iterativo e incremental.
Questão 9
(Fonte: IADES 2010 – CFA Analista de Sistemas).
 
O modelo espiral para a Engenharia de Software foi desenvolvido acrescentando-se novos elementos às
melhores características de outros modelos. Segundo o modelo espiral, a determinação dos objetivos,
alternativas e restrições está relacionada à atividade de:
A análise de risco.
B planejamento.
C engenharia.
D avaliação feita pelo cliente.
E feedback do cliente.
A alternativa B está correta.
A etapa de planejamento é caracterizada pela especificação dos objetivo, alternativas e restrições do
software.
Questão 10
No que se refere aos modelos de desenvolvimento e ciclos de vida, julgue o item que segue.
 
No modelo iterativo, divide-se o desenvolvimento em iterações. A cada iteração, podem ser acrescentadas
novas funcionalidades ao software.
 
Uma iteração parte do estado no qual se encontravam os artefatos ao término da iteração anterior e resulta
em um incremento. Uma iteração pode ter disciplinas como captura de requisitos, análise, projeto,
implementação e teste.
A Verdadeiro
B Falso
A alternativa A está correta.
Cada iteração passa por pequenos modelos em cascata, nos quais novas funcionalidades são adicionadas
ao software.
Questão 11
Discuta como o modelo cascata e a prototipação podem ser utilizados no modelo em espiral.
Chave de resposta
Podemos utilizar a prototipação na análise de riscos e utilizar o modelo cascata na engenharia.
3. Conclusão
Considerações finais
Neste conteúdo, abordamos os principais fundamentos do desenvolvimento de software, começando pela
compreensão do que é um produto software e como ele é planejado, construído e gerenciado ao longo de seu
ciclo de vida. Exploramos o Manifesto Ágil para Desenvolvimento de Software e seus 12 princípios, que
orientam práticas mais flexíveis, colaborativas e centradas no valor entregue ao cliente. Também discutimos
conceitos fundamentais da Engenharia de Software e as principais atividades envolvidas no processo de
desenvolvimento.
 
Aprofundamos o estudo dos métodos ágeis mais utilizados no mercado, como o Feature Driven Development
(FDD), o Dynamic Systems Development Method (DSDM) e o Crystal, além de apresentar a Declaração de
Interdependência,que reforça a colaboração e a responsabilidade compartilhada em projetos ágeis. Esses
métodos se destacam por sua capacidade de promover entregas incrementais e adaptar-se rapidamente a
mudanças.
 
Na sequência, exploramos os modelos de qualidade de software e a importância da medição como prática
contínua para garantir desempenho, produtividade e confiabilidade. Discutimos a implantação de programas
de medição nas organizações, destacando que as métricas são ferramentas essenciais para o controle dos
processos e para o sucesso dos projetos.
 
Concluímos que a falta de controle é um dos principais fatores que comprometem os prazos, os custos e a
implantação de grandes projetos. Por isso, o domínio desses conceitos é indispensável para profissionais que
desejam atuar com competência na área de desenvolvimento de software, contribuindo para a entrega de
soluções de alta qualidade em um mercado cada vez mais exigente.
Explore +
Leia o texto: 
 
Aplicação de metodologias ágeis para desenvolvimento de software: um estudo de caso na empresa
Alliance Software.
 
Busque os textos na internet:
 
Ciclo de vida iterativo e incremental.
Comparação geral das metodologias clássicas de desenvolvimento de software.
Referências
AGILE MANIFESTO. Os 12 princípios por trás do Manifesto Ágil. Consultado na internet em 15 mai.
2019.
 
BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML: guia do usuário. Rio de Janeiro: Campus, 2000.
• 
• 
• 
• 
• 
https://cdn-conteudo.ensineme.com.br/Aplicacaode_Metodologias_Ageispara_Desenvolvimentode_Softwareum_Estudode_Casona_Empresa_Alliance_Software_414a221b23.pdf
https://cdn-conteudo.ensineme.com.br/Aplicacaode_Metodologias_Ageispara_Desenvolvimentode_Softwareum_Estudode_Casona_Empresa_Alliance_Software_414a221b23.pdf
 
FDD. Feature Driven Development. Consultado na internet em 15 mai. 2019.
 
GORDON, S.R.; GORDON, J.R. O ciclo de vida do desenvolvimento de sistemas. In: Sistemas de
informação: uma abordagem gerencial. LTC, 2006. Consultado na internet em 17 mai. 2019.
 
PFLEEGER, Shari Lawrence. Engenharia de Software: teoria e prática. 2. ed. São Paulo: Pearson, 2003.
 
PRESSMAN, Roger S. Uma abordagem profissional. 8. ed. Rio de janeiro: Bookman, 2016.
 
SOMMERVILLE, Ian. Engenharia de Software. 9. ed. São Paulo: Pearson, 2011.
• 
• 
• 
• 
• 
	Modelos de ciclo de vida de software
	1. Itens iniciais
	Propósito
	Objetivos
	Introdução
	1. O que é engenharia de software
	Contextualização
	O que é projeto?
	Original
	Organização de pessoas e recursos
	Para atingir um propósito específico
	Num período de tempo finito
	O que é software?
	Composição e classificação do software
	Composição do software
	Classificação do software
	Manifesto
	Manifesto para desenvolvimento ágil de software
	Indivíduos e interações
	Software em funcionamento
	Colaboração com o cliente
	Responder a mudanças
	Saiba mais
	Declaração de Interdependência
	Outras metodologias e frameworks ágeis
	Feature Driven Development - FDD (Desenvolvimento Dirigido a Funcionalidades)
	Atenção
	Ciclo de vida do DSDM
	Atenção
	Conteúdo interativo
	Crystal
	Conteúdo interativo
	Verificando o aprendizado
	2. Modelos de ciclo de vida de software
	Contextualização e modelos
	Comentário
	Conteúdo interativo
	Cascata
	Conteúdo interativo
	Modelo em V
	Conteúdo interativo
	Incremental
	Conteúdo interativo
	Conteúdo interativo
	Atenção
	Conteúdo interativo
	Modelo evolutivo
	Iterativo e incremental
	Conteúdo interativo
	Conteúdo interativo
	Outros modelos
	RAD (Rapid Application Development)
	Conteúdo interativo
	Prototipagem
	Modelo espiral
	Conteúdo interativo
	RUP (Rational Unified Process)
	Concepção
	Elaboração
	Construção
	Transição
	Conteúdo interativo
	Verificando o aprendizado
	Questão 8
	Conteúdo interativo
	3. Conclusão
	Considerações finais
	Explore +
	Referências