Modelos de Processo

Prévia do material em texto

Londrina 
2014 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
GUSTAVO MAFRA 
JHONATAN SOARES 
MATEUS FERRER 
RICARDO SUZUKI 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
CENTRO DE CIÊNCIAS EMPRESARIAIS E SOCIAIS APLICADAS 
ANALISE E DESENVOLVIMENTO DE SISTEMA 
MODELOS DE PROCESSO 
 
Londrina 
2014 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
MODELOS DE PROCESSO 
 
Trabalho de Modelos de Processo apresentado à 
Universidade Norte do Paraná - UNOPAR, como 
requisito parcial para a obtenção de média bimestral na 
disciplina de Engenharia de Software 
 
Orientador: Prof. Luiz Claudio Perini 
 
GUSTAVO MAFRA 
JHONATAN SOARES 
MATEUS FERRER 
RICARDO SUZUKI 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
SUMÁRIO 
1 INTRODUÇÃO ..................................................................................................... 3 
2 MODELO DE PROCESSO AGIL ......................................................................... 4 
2.1 CONCEITOS .................................................................................................... 4 
2.2 CARACTERISTICAS ........................................................................................ 4 
2.2.1 História do Desenvolvimento Ágil.................................................................. 5 
2.2.2 Agilidade ....................................................................................................... 6 
2.2.3 O Custo das Mudanças ................................................................................. 7 
2.3 CICLO DE VIDA ............................................................................................... 7 
2.4 APLICACAO ..................................................................................................... 8 
2.4.1 Casos de Sucesso ........................................................................................ 8 
2.5 EXEMPLOS DE MODELO ............................................................................. 10 
2.5.1 FDD ............................................................................................................. 10 
2.5.1.1 CONCEITO ................................................................................................. 10 
2.5.1.2 CARACTERISTICAS .................................................................................. 11 
2.5.1.3 CICLO DE VIDA .......................................................................................... 12 
2.5.1.4 APLICAÇÕES(NA PRATICA) ..................................................................... 15 
2.5.2 EXTREME PROGRAMMING (XP) .............................................................. 17 
2.5.2.1 CONCEITOS ............................................................................................... 17 
2.5.2.2 CARACTERISTICAS .................................................................................. 17 
2.5.2.3 CICLO DE VIDA XP .................................................................................... 18 
3 MODELO DE PROCESSO EVOLUCIONÁRIO .................................................. 25 
3.1 CONCEITO ..................................................................................................... 25 
3.1.1 CARACTERISTICAS .................................................................................. 25 
3.2 CICLO DE VIDA ............................................................................................. 26 
3.3 EXEMPLOS DE PROCESSO ......................................................................... 28 
3.3.1 MODELO DE MÉTODOS FORMAIS .......................................................... 28 
3.3.1.1 CONCEITOS ............................................................................................... 28 
3.3.1.2 CARACTERISTICAS .................................................................................. 28 
3.3.1.3 CICLO DE VIDA .......................................................................................... 29 
3.3.1.4 APLICACAO ............................................................................................... 30 
3.3.2 MODELO DE PROCESSO INCREMENTAL ............................................... 31 
3.3.2.1 CONCEITO ................................................................................................. 31 
3.3.2.2 CARACTERISTICAS .................................................................................. 33 
3.3.2.3 CICLO DE VIDA .......................................................................................... 33 
3.3.2.4 APLICAÇÃO ............................................................................................... 35 
3.3.3 MODELO DE PROCESSO CONCORRENTE ............................................ 35 
3.3.3.1 CONCEITO ................................................................................................. 35 
3.3.3.2 CARACTERISTICAS .................................................................................. 36 
3.3.3.3 CICLO DE VIDA .......................................................................................... 36 
3.3.3.4 APLICAÇÃO ............................................................................................... 37 
4 CONCLUSÃO .................................................................................................... 40 
REFERÊNCIAS ......................................................................................................... 41 
 3 
1 INTRODUÇÃO 
Um processo de software é um conjunto de atividades e resultados associados que 
produzem um produto de software. Portanto, um processo de software se dá pela 
estruturação de um conjunto de atividades que resultam num produto software. Um 
processo deve contribuir na redução de custos, aumento de qualidade e de 
produção. Um processo que não suporta esses objetivos não é considerado um 
processo adequado. 
Um processo de software pode conter diversas atividades. As principais atividades 
que normalmente todo processo possui são: especificação, projeto, implementação, 
validação, manutenção e evolução. As atividades constituem um conjunto mínimo 
para se obter um produto de software. 
Quando temos um processo definido temos a garantia de uma estabilidade, controle 
e organização. 
 4 
2 MODELO DE PROCESSO AGIL 
2.1 CONCEITOS 
 
A metodologia ágil (em inglês Agile Modeling, ou AG) surgiu no início da década de 
70 após o fracasso de alguns grandes projetos de software. A deficiência no 
gerenciamento das atividades, atrasos na entrega e sistemas que não refletiam a 
verdadeira necessidade do cliente eram características habitualmente atribuídas à 
metodologia tradicional. 
A existência de uma crise do software não foi um consenso entre os profissionais da 
área naquela época. Mas para tornar possível a solução dos problemas 
enfrentados, foi criada uma nova metodologia com uma abordagem bem 
diferenciada. 
Os métodos ágeis são um conjunto de práticas onde os princípios e valores são 
aplicados por profissionais de software no dia a dia e seguidos como guia. Não é um 
processo que define detalhadamente como criar um modelo, mas indica caminhos 
para obtenção de melhores resultados. 
A expressão “Métodos Ágeis” é conhecida há muito tempo, porém, apenas 
recentemente começou a se tornar popular no Brasil. Ser ágil geralmente é 
confundido com falta de controle e completa anarquia, quando na verdade, ter 
agilidade, ao contrário do que parece, exige bastante organização. 
O objetivo da Metodologia Ágil é acelerar o desenvolvimento do software através do 
desenvolvimento de versões mínimas. Dessa forma, as funcionalidades são 
desenvolvidas por partes,há uma interatividade direta com o cliente e os testes são 
realizados em paralelo ao ciclo de desenvolvimento. 
Agilidade envolve disciplina e trabalho coordenado, podendo tratar de projetos de 
vários segmentos e portes. Agilidade é também a habilidade de criar e responder a 
mudanças com respeito ao resultado financeiro do projeto em um turbulento 
ambiente de negócios. 
Em 2001, um grupo de profissionais da área de desenvolvimento de software se 
reuniu para discutir assuntos relacionados à agilidade. Como consequência desse 
encontro, foram definidas boas práticas para utilização dos Métodos Ágeis no 
gerenciamento de projetos. Essas práticas foram denominadas “Manifesto Ágil”. 
 
 
2.2 CARACTERISTICAS 
 
O desenvolvimento ágil possui princípios que o caracterizam, são eles: a satisfação 
do cliente, a entrega incremental, equipes de projetos pequenas e altamente 
motivadas, métodos informais, poucos artefatos de engenharia de software, 
simplicidade no desenvolvimento geral. No desenvolvimento ágil procura-se entregar 
um software funcional o mais cedo possível do que gastar horas, dias, semanas ou 
até meses com a análise e projeto de um software. Também temos a priorização de 
 5 
uma comunicação muito mais ativa e contínua entre os desenvolvedores e os 
clientes. 
Todos os envolvidos e interessados no projeto, tais como os gerentes, clientes e os 
usuários finais, trabalham em conjunto e de forma auto-organizável em uma equipe 
ágil que controla o seu próprio objetivo. Essa equipe sabe que é fundamental uma 
comunicação acelerada e colaboração constante entre todos os participantes, 
sempre tirando dúvidas e ajudando uns aos outros. 
Trabalhar de maneira ágil atualmente é extremamente importante para o sucesso de 
qualquer projeto devido aos ambientes modernos que estão em constante mudança 
de forma bastante acelerada. Cada vez mais se tem provado que o desenvolvimento 
ágil tem sido disparadamente a melhor alternativa para esses tipos de projetos 
entregando sistemas corretos e completos rapidamente. 
O desenvolvimento ágil tem atividades básicas como comunicação, planejamento, 
modelagem, construção e emprego. No entanto, elas são realizadas através de um 
conjunto pequeno de tarefas que impulsiona a equipe para o desenvolvimento e 
entrega de forma imediata. 
Diferente de outras abordagens o desenvolvimento ágil considera como um artefato 
apenas o incremento de software operacional que seja entregue na data combinada 
com o cliente. Ou seja, quaisquer outros documentos como casos de uso, modelos, 
projetos não são considerados entregas. Apenas o software operacional e 
funcionando. 
2.2.1 História do Desenvolvimento Ágil 
O movimento ágil surgiu em 2001 com Kent Beck e mais dezesseis experientes e 
renomados desenvolvedores, autores, e consultores na área de software. Esses 
autores assinaram o "Manifesto para o Desenvolvimento Ágil de Software". Esse 
manifesto ágil dizia que eles estavam desenvolvendo e ajudando outros a 
desenvolver software, desvendando formas melhores de desenvolvimento. Através 
deste trabalho os autores do manifesto passaram a valorizar o seguinte: 
Indivíduos e interações acima de processos e ferramentas 
Software funcional acima de documentação completa 
Colaboração dos clientes acima de negociação contratual 
Respostas a mudanças acima de seguir um plano 
Com isso, os autores manifestaram que embora os itens do lado direito tenha valor, 
os itens da esquerda são mais ainda valorizados. 
Portanto, o desenvolvimento ágil tenta de certa forma atacar os antigos princípios da 
engenharia de software e valorizar novas formas de desenvolver software. Em 
essência os métodos ágeis foram desenvolvidos a partir de um esforço para sanar 
as fraquezas que existia na engenharia de software convencional. Vale salientar que 
o desenvolvimento ágil procura sanar as fraquezas que existiam e não apagar todo 
conhecimento já existente. Pelo contrário, os princípios, conceitos e métodos 
continuam valendo, e muito, porém sendo adaptada aos desafios atuais. 
Por muitos anos as ideias por trás do desenvolvimento ágil são conhecidas pelos 
desenvolvedores, no entanto, somente há menos de quinze anos que elas realmente 
se consolidaram como um "movimento". 
Apesar dos benefícios oferecidos pelo desenvolvimento ágil ele não é indicado para 
todos os projetos, produtos, empresas, ambientes, contextos e pessoas. Em 
algumas oportunidades já vivenciei experiências de pessoas que simplesmente não 
 6 
conseguiram se adaptar ao desenvolvimento ágil. Em outras situações empresas 
também não conseguiram aderir ao ágil, muito devido aos próprios clientes não 
conseguirem se encaixar na nova filosofia proposta. O desenvolvimento ágil, por 
outro lado, é fortemente indicado para negócios que mudam rapidamente, ser ágil é 
fundamental para dar respostas ao ambiente de negócios. Atualmente as condições 
de mercado estão sempre mudando e muito rapidamente. Por isso os clientes 
precisam de respostas rápidas. As mudanças são caras, ainda mais quando são 
feitas sem controle e mal gerenciadas. A abordagem ágil tem como uma 
característica bastante forte reduzir os custos destas mudanças ao longo de todo o 
processo de software. 
2.2.2 Agilidade 
Segundo o autor Ivar Jacobson, muito conhecido na engenharia de software, 
agilidade não é somente uma palavra da moda quando descrevemos um moderno 
processo de software. Agilidade é quando uma equipe é rápida e capaz de 
responder apropriadamente as mudanças no software, ou mudanças ocorridas nos 
membros da equipe, ou ainda as mudanças que envolvem o surgimento de novas 
tecnologias, ou então quaisquer outras mudanças que causem impacto no produto 
em construção ou no projeto que cria o produto. Dessa forma, o suporte para 
mudanças deve ser incorporado em tudo o que fazemos em software. Ivar Jacobson 
ainda acrescenta que uma equipe ágil também sabe reconhecer que o software é 
desenvolvido por pessoas trabalhando em equipes e que as suas habilidades e 
capacidades em colaborar estão no cerne do sucesso do projeto. 
Portanto, podemos analisar que incorporar o espírito da mudança é o principal meio 
para sermos ágeis. No entanto, ser ágil não é somente responder às mudanças, 
devemos abraçar a filosofia que é proposta no manifesto que foi discutido na seção 
"História do desenvolvimento ágil". O manifesto ágil incentiva a estruturação e as 
atitudes em equipe tornando a comunicação mais fácil entre os membros da equipe, 
entre o pessoal ligado a tecnologia e outras áreas, entre os desenvolvedores e os 
gerentes. O manifesto Também enfatiza a entrega rápida do software operacional, a 
diminuição da importância dos artefatos, assumir o cliente como parte da equipe de 
desenvolvimento de software, reconhecer que planejamento tem limites quando o 
negócio é mutável e dessa forma o planejamento também deve ser flexível o 
suficiente para acomodar essas mudanças. 
Por fim, salienta-se que a agilidade pode ser aderida em qualquer processo de 
software. No entanto, devemos considerar que a equipe deve ser adaptada e 
alinhada a essa nova realidade. Uma situação que ocorre na maioria dos projetos 
que passam a ser ágeis, deixando assim outras formas tradicionais de 
desenvolvimento, é a tentativa de tornar o projeto totalmente ágil em poucos dias ou 
semanas. Vivenciei projetos que fracassaram ao tentar essa abordagem 
desesperada de se tornar ágil. O ideal é que a agilidade seja gradativamente 
empregada ao projeto procurando inicialmente fazer um planejamento ágil de 
entregas curtas ao cliente e de forma incremental, dividindo as tarefas com os 
membros da equipe, depois tentando eliminar artefatos que não são essenciais aos 
projetos, e assim por diante. O ideal é aos poucos fazer a equipe entender como 
funciona o desenvolvimento ágil, sempre aderindo aos poucos. De preferência seria 
interessante termos um profissionalmais experiente com o desenvolvimento ágil 
 7 
para que ele possa instruir a equipe a começar e dar prosseguimento até que a 
equipe obtenha o amadurecimento necessário. 
2.2.3 O Custo das Mudanças 
Conforme os estudos realizados durante décadas afirma-se que os custos das 
mudanças aumentam cada vez mais conforme o avanço do projeto. Quando 
estamos na fase de requisitos e precisamos adicionar novas funcionalidades a um 
requisito ou alterar requisitos já existentes é simples e barato efetuá-las. No entanto, 
se já estamos testando a nossa aplicação e o cliente requisita uma mudança que 
afetará diversos componentes, requerendo novos testes, mudanças na arquitetura, 
etc., teremos um custo muito maior. Dessa forma, os custos sempre crescem 
rapidamente conforme a evolução do projeto. 
Uma das grandes características dos métodos ágeis é que se temos um processo 
ágil bem elaborado, esse custo de realizar uma mudança é menor. O segredo desse 
custo menor nas mudanças é que os métodos ágeis trabalham com entregas 
incrementais, os testes são contínuos e a programação é realizada em pares. Todas 
essas praticas e outras desenvolvidas nos métodos ágeis contribuem para essa 
mudança não ser tão significativa. Há um grande número de publicações e 
experiências compartilhadas na área de desenvolvimento de software que os 
métodos ágeis reduzem de forma bastante significativa os custos das alterações. A 
minha experiência que já vivenciou os dois lados, métodos tradicionais e métodos 
ágeis, também confirma essa afirmação. Além dos métodos ágeis mudarem a 
filosofia de que não deveríamos mexer em nada e um contrato deve ser seguido até 
o fim, também temos as práticas que se aplicadas tendem a ajudar de forma 
bastante significativa o impacto dessas mudanças. 
 
2.3 CICLO DE VIDA 
 
Para termos agilidade devemos seguir os 12 princípios estabelecidos pela Agile 
Allince, são eles: 
 
 A prioridade principal é sempre satisfazer o cliente por meio de entregas 
rápidas e contínuas de software operacional. 
 Devemos sempre acolher os pedidos de modificações, mesmo que estes 
sejam atrasados. Os processos ágeis se aproveitam das mudanças como 
uma vantagem competitiva na relação com o cliente. 
 Entregue software funcional de forma frequente, seja em algumas semanas 
ou alguns meses, dando preferência para intervalos mais curtos. 
 Os responsáveis pela área comercial e os desenvolvedores devem trabalhar 
em conjunto diariamente ao longo de todo projeto. 
 Sempre devemos construir projetos com indivíduos motivados. Devemos dar 
a eles o ambiente e apoio necessário, além de confiarmos neles para ter o 
trabalho feito. 
 A conversa aberta e de forma presencial é o método mais eficiente e efetivo 
de transmitir as informações para dentro de uma equipe de desenvolvimento. 
 8 
 A principal medida de progresso do projeto é o software em funcionamento. 
 Os processos ágeis promovem desenvolvimento sustentável, ou seja, todos 
os envolvidos devem estar capacitados a manter um ritmo constante 
indefinidamente. 
 A atenção contínua com a excelência técnica e com bons projetos aumenta a 
agilidade. 
 Manter a simplicidade é considerado essencial. 
 As melhores arquiteturas, requisitos e projetos estão ligados às equipes auto-
organizáveis. 
 A equipe se autoavalia, em intervalos regulares, no intuito de se tornarem 
cada vez mais eficientes. Dada essa autoavaliação a equipe procurar formas 
de ajustar o seu comportamento de acordo com isso. 
 
Certos modelos de processo ágil ignoram alguns princípios, outros atribuem um 
peso maior a alguns princípios. No entanto, os princípios definem um espírito ágil 
que é mantido em cada um dos modelos de processo existentes atualmente. 
 
2.4 APLICACAO 
2.4.1 Casos de Sucesso 
Svensson e Höst nos seus estudos publicados relataram os resultados da adoção do 
desenvolvimento ágil em uma organização de grande porte que tem cerca de 1.500 
pessoas. Através de um projeto piloto que durou oito meses constatou-se que 
adoção dos métodos ágeis teve um efeito bastante positivo tanto pelo ponto de vista 
da empresa quanto do cliente. 
Ilieva também relatou sua experiência com desenvolvimento ágil e desenvolvimento 
tradicional onde foram utilizados dois projetos similares em tamanho, esforço e 
tecnologia adotada. Desenvolveu-se um software primeiramente utilizando um 
projeto de desenvolvimento baseado em um modelo tradicional e depois utilizando 
desenvolvimento ágil. Constatou-se que houve um aumento de produtividade em 
41,23% com redução de esforço homem/hora de 11,45% e redução de defeitos em 
13,33%. Ou seja, trabalhou-se menos, produziu-se mais e ainda tivemos uma 
redução dos erros encontrados. 
Paulo Cheque Bernardo e Fabio Kon também relataram como foi a experiência em 
utilizar métodos ágeis na re-implementação de um sistema de grande porte 
desenvolvido para Universidade de São Paulo (USP). O sistema controla 
aproximadamente 25 mil alunos matriculados e outorga cerca de 5 mil títulos por 
ano. Além disso, o sistema também controla todos os dados do programa de pós-
graduação da universidade e todo o histórico da vida acadêmica dos alunos. Com o 
intuito de modernizar os antigos sistemas que mantinham todos esses dados criou-
se um novo sistema desenvolvido através de práticas de métodos ágeis de 
desenvolvimento. 
O desenvolvimento do novo software se deu de forma incremental e seguindo a 
filosofia dos métodos ágeis. Entre as práticas adotadas tem-se: 
 9 
 Planejamento e Fases pequenas: As iterações eram curtas com pequenas 
fases de desenvolvimento. Foi utilizado o software XPlanner para auxiliar no 
planejamento. 
 
 Design simples: O sistema foi bem modularizado e sem flexibilidade 
desnecessária, como enfatizado no desenvolvimento ágil. Além disso, 
técnicas como programação orientada a objetos, reflexão e AOP ajudaram no 
desenvolvimento de um design simples. 
 
 Testes: Ferramentas como JUnit, TestNG, Selenium, Emma, Ant e 
CruiseControl auxiliaram no desenvolvimento dos testes de unidade, 
aceitação, segurança e desempenho que são executadas várias vezes por 
dia. 
 
 Refatoração: Devido a segurança fornecida pelos testes automatizados o 
sistema recebe diariamente várias refatorações, algumas envolvendo grandes 
quantidades de código. A IDE Eclipse também fornece auxilio para fazer as 
refatorações no sistema. 
 
 Programação em pares: Os programadores trabalham em pares de modo a 
espalhar o conhecimento do projeto por toda a equipe. 
 
 Padronização e Propriedade coletiva do código: Ferramentas como 
CheckStyle auxiliam na criação e verificação automática de padrões de estilos 
de código. Todos os programadores trabalham em vários módulos do projeto 
sem restrições. 
 
 Integração contínua: O sistema ganhou um repositório único gerenciado pelo 
SVN. Todos os desenvolvedores podem trabalhar em qualquer parte do 
código e o processo de integração das mudanças é simples e ágil. 
 
 Cliente junto aos desenvolvedores: O feedback dos usuários é sempre muito 
rápido e com isso as correções e refinamentos são diariamente colocadas em 
produção. O contato permanente dos desenvolvedores com os clientes 
também permitiram um contato mais direto e frequente, diminuindo a 
burocracia na coleta de requisitos. 
 
Os números relatados também é algo que impressionado neste projeto da USP. O 
sistema começou a ser desenvolvido em maio de 2006 e entrou em produção em 
julho do mesmo ano. A equipe tinha uma mescla de dois programadores sênior e 
dois estagiários sendo que alguns possuíam maior conhecimento das tecnologias e 
outros tinham uma maior familiaridade com as regras de negócio e com os códigos 
já existentes nos antigos sistemas. O sistema possui cerca de 15 mil linhas de 
código com aproximadamente 100 classes Java e 50 arquivos JSP. Emrelação aos 
testes automatizados há cerca de 5 mil linhas de código de teste divididos em 50 
classes. Os testes são executados várias vezes ao dia. 
Esses são apenas alguns dos casos de sucessos encontrados na indústria de 
software. Esses estudos mostram o quanto o desenvolvimento ágil pode fazer a 
diferença em pequenos, médios e grandes projetos. É sempre interessante tirarmos 
 10 
o maior proveito possível dessas experiências até como forma de beneficiar o nosso 
projeto com práticas que já deram certo em outros projetos. 
 
2.5 EXEMPLOS DE MODELO 
2.5.1 FDD 
 
2.5.1.1 CONCEITO 
 
Entre as metodologias ágeis que existiam antes do manifesto ágil, o FDD “Feature 
Driven Developement” é uma delas. 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 Jeff de Luca. 
O FDD, assim como a teoria de sistemas afirma, entende que a soma das partes é 
maior do que o todo. Desta forma, apesar de criar um modelo abrangente baseado 
no todo que será desenvolvido, esta fase inicia-se com o detalhamento do domínio 
do negócio com divisão de áreas que serão modeladas. O modelo só está pronto 
quando todos da equipe estiverem de acordo, o planejamento é feito com base na 
lista de funcionalidades. Se fossemos trabalhar com FDD em conjunto com o Scrum, 
a lista de funcionalidades seria utilizada no backlog de produtos, como histórias de 
usuários a serem desenvolvidas. 
Peter Coad e seus colegas criaram um modelo de processo prático para a 
engenharia de software orientada a objetos chamada Desenvolvimento Dirigido a 
Funcionalidade ou Feature Driven Development (FDD). Após o trabalho de Coad 
surgiu outro modelo de processo que aperfeiçoou o trabalho desenvolvido. Este 
trabalho foi realizado por Stephen Palmer e John Felsing que descreveram um 
processo ágil adaptativo que pode ser aplicado em projetos de médio e grande 
porte. 
 
Seguindo as outras abordagens ágeis, o FDD também evidencia a colaboração 
entre as pessoas da equipe, gerencia os problemas e complexidades de projetos 
utilizando a decomposição baseada em funcionalidades que é seguida pela 
integração dos incrementos de software e por fim também enfatiza a comunicação 
de detalhes técnicos usando formas verbais, gráficos e texto. Além disso, o FDD 
enfatiza as atividades de garantia da qualidade por meio da estratégia de 
desenvolvimento incremental, inspeções de código e de projeto, auditorias, coleta de 
métricas e o uso de padrões para análise, projeto e construção. 
 
O FDD preconiza que a funcionalidade é uma função valorizada pelo cliente passível 
de ser implementada em até duas semanas ou menos. Essa ênfase na definição de 
funcionalidades tem como benefícios uma descrição mais fácil das funcionalidades 
 11 
por parte do usuário, uma melhor compreensão como elas se relacionam entre si e 
uma melhor revisão das ambiguidades, erros ou omissões. Isso ocorre porque elas 
são pequenas, formadas em pequenos blocos. Além disso, outro benefício é que as 
funcionalidades podem ser organizadas em um agrupamento hierárquico 
relacionados com o negócio, pode ser entregue a cada duas semanas, o projeto e o 
código são mais facilmente inspecionados e o planejamento, cronograma e 
acompanhamento do projeto são guiados pela hierarquia de funcionalidades ao 
invés de tarefas de engenharia de software. 
 
Coad e seus colegas sugerem os seguintes modelos para definirmos uma 
funcionalidade: 
 
<ação> o <resultado> <por|para quem|de|para que> um <objeto> 
 
 Onde objeto é "uma pessoa, local ou coisa". 
 
 Um exemplo de funcionalidades poderia ser: 
 
 Adicione o produto ao carrinho 
 
 Mostre as especificações técnicas do produto 
 
O FDD também define cinco processos, são eles: Desenvolver um Modelo Geral, 
Construir uma Lista de Funcionalidades, Planejar por Funcionalidades, Projetar por 
Funcionalidade, Desenvolver por Funcionalidade. 
 
Um aspecto interessante do FDD em relação a outros métodos ágeis é que ele dá 
maior ênfase às diretrizes e técnicas de gerenciamento de projetos do que outros 
métodos ágeis disponíveis. 
 
 
2.5.1.2 CARACTERISTICAS 
 
O FDD busca o desenvolvimento por funcionalidade, ou seja, por um requisito 
funcional do sistema. É pratico para o trabalho com projetos iniciais ou projetos com 
codificações existentes. Apesar de ter algumas diferenças entre o FDD e o XP, é 
possível utilizar as melhores práticas de cada metodologia. O FDD atua muito bem 
em conjunto com o Scrum, pois o Scrum atua no foco do gerenciamento do projeto e 
o FDD atua no processo de desenvolvimento. 
Assim como acontece na metodologia XP, o FDD faz uso de teste de software. 
Desta forma é possível utilizar TDD, aliás, é indicada a utilização deste para manter 
a qualidade do software. 
 
 
 12 
2.5.1.3 CICLO DE VIDA 
O Feature-Driven Development (FDD) é um processo de 
desenvolvimento orientado por funcionalidades. Auxilia no 
desenvolvimento e gerenciamento da produção de software e possui 
duas fases distintas e cinco processos bem definidos, conforme 
HEPTAGON (2007). 
Suas fases são: 
• Concepção e Planejamento 
• Construção 
 
E possui cinco processos: 
 
DMA (Desenvolver um Modelo Abrangente): esta é a fase 
inicial, em que é desenvolvida a visão geral do produto, quando a equipe 
deverá começar a ser formada, a análise de domínio é produzida, assim 
como o estudo da documentação utilizada, desenvolvimento de modelos 20 
 e refinamentos destes. Ao final alguns diagramas como de classe e de 
seqüência estarão disponíveis. 
CFL (Construir a lista de Funcionalidades): neste 
Processo, a equipe irá desenvolver a lista de funcionalidades do software, 
as funcionalidades listadas são criadas a partir de valores que sejam 
gerados ao cliente e não valores técnicos. 
PPF (Planejar por Funcionalidades): neste as 
funcionalidades são estudadas, são avaliadas as dependências entre 
classes, organizadas em seqüência de desenvolvimento e as equipes de 
desenvolvimento já têm atribuídas suas atividades. O esforço para 
desenvolvimento já é identificado neste processo. 
DPF (Detalhar por Funcionalidades): aqui é realizado o 
trabalho para definição dos pacotes que atenderão as funcionalidades 
planejadas. Neste processo também é feito um refinamento dos modelos 
tanto de classe como de seqüência, além de uma inspeção nos 
documentos gerados. 
CPF (Construir por Funcionalidades): este processo é o de 
transformar tudo em código, software, até gerar o pacote de instalação, 
passando por inspeções, testes antes de chegar à versão final. 21 
 
 
 13 
 
Figura 1:Feature-Driven Development (HEPTAGON, 2007) 
 
É importante observar que o FDD é voltado ao uso de 
análise orientada a objetos. O modelo gráfico, apresentado na figura acima, 
apresenta as fases e os processos: 
• Estrutura FDD 
• Requisitos 
• Fase de concepção (DMA,CFL,PPF) 
• Construção (DPF, CPF) 
• Produto final. 
 
Com base na lista de funcionalidades, deve-se planejar por funcionalidade, mas este 
planejamento é incremental. Isto em conjunto com o Scrum, deve ser analisado 
como etapa de desenvolvimento do incremento, então este planejamento é feito com 
base no que será desenvolvido naquele incremento. 
Vamos novamente ao Scrum, separando o que será feito na Sprint. Colocamos no 
backlog da Sprint. O que está no backlog da sprint são funcionalidades que serão 
desenvolvidas durante a sprint (que pode ser de duas a quatro semanas), estas 
tarefas são então planejadas com maior rigor, neste ponto, temos então o 
planejamento incremental, ou seja, planejamos apenas o que vamos desenvolver. 
Nesta etapa os envolvidos no processo resumem-se apenas à equipe, ou seja, os 
desenvolvedores, analistas,testadores, etc., que vão atuar no processo. Eles devem 
selecionar os itens com base no tempo que eles possuem e nas qualificações atuais 
da equipe. 
Após o planejamento, é feito o detalhamento, nesta fase é de extrema importância 
que o desenho esteja de acordo com o que o cliente deseja, então é mantido contato 
constante com o cliente, como em todas as metodologias ágeis. 
Esta documentação é a base para o desenvolvimento, não deve-se perder tempo 
com documentação que não será utilizada, mas é necessário documentar. 
Posteriormente inicia-se a fase de desenvolvimento, esta fase é a etapa de 
desenvolvimento e teste real. 
 14 
O desenvolvimento também é incremental, e indica-se a utilização de testes do início 
ao fim do processo, além da utilização de integração continua. 
Um ponto que diverge do XP é que no FDD é incentivado o desenvolvedor como 
único responsável pelo módulo que este desenvolve, já no XP, o código é 
comunitário. 
 
 
Figura 2: Integração contínua 
 
A utilização da integração continua permite que a equipe esteja em contato 
constante com o cliente, tornando o processo ágil e com entregas constantes. 
Como cada fase apresentada acima é específica e curta, e as fases se completam, 
são necessários relatórios para manter o controle, para analisar a quantidade de 
recursos que estão sendo desenvolvidos, semelhante ao burndow e o burnup do 
Scrum. 
Segundo a metodologia, 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%. 
Além disso, o FDD possui as chamadas melhores práticas que indicam boas práticas 
ao desenvolver com o FDD, são elas: 
Modelagem Orientada a Objetos do Domínio; 
Desenvolvimento por funcionalidade; 
Classe proprietária, ou seja, a unidade é feita individualmente, evitando-se assim 
conflitos na equipe; 
Equipes de recursos: são equipes pequenas, destinadas a desenvolver recursos 
necessários ao projeto, de forma secundária; 
Inspeção é realizada constantemente para garantir a boa qualidade do código e do 
projeto; 
Gerenciamento de configuração; 
Integração contínua para demonstrar constantemente as funcionalidades ao cliente 
e; 
Visibilidade de progressos e resultados. 
 
 15 
2.5.1.4 APLICAÇÕES(NA PRATICA) 
 
FDD e Desenvolvimento Web 
 
TAMANHO DO PROJETO 
Como regra geral, FDD é extremamente eficaz em grandes projetos com lógica de 
negócios complexos. Não é tão eficaz em pequenos projectos com pouca lógica de 
negócios. Isso não quer dizer que você não pode usar elementos do FDD para 
ajudar a gerenciar seus projetos melhor, mas é muito difícil de fazer cumprir código e 
revisões de projeto (ver processos 4 e 5), quando você tiver apenas um 
desenvolvedor no projeto! 
TECNOLOGIA 
Não há nada no FDD que dita o que a tecnologia de usar. No entanto, o simples fato 
de que o primeiro processo é objeto principalmente modelagem significa que se você 
não estiver usando uma tecnologia de OO, usando FDD não vai ser simples. Dito 
isto, eu tenho usado com sucesso os aspectos da FDD em projetos web usando 
uma variedade de tecnologias web orientado como ASP, JSP e PHP. 
PESSOAS 
A chave para o FDD é um processo, a chave para processar alguém está tendo um 
grande modelador objeto e um grande gerente de projeto. Nota: não importa o 
processo que você usa, você precisa de pessoas boas. No processo, incluindo FDD 
irá ajudá-lo se você não tem as pessoas certas. Se você está pensando em FDD 
para ajudá-lo a resolver este problema, pense novamente. 
O QUE NÃO COBRE 
Você precisa estar bem ciente de que FDD, citando Fred Brooks, não é uma bala de 
prata. Não abrange todos os aspectos do desenvolvimento. Há muitos aspectos de 
um projeto padrão que você ainda precisa de gerir fora do que FDD pode 
ajudar. Estes aspectos incluem 
Levantamento de requisitos 
Design de interface 
Prova 
Desenvolvimento 
UM PONTO DE PARTIDA 
Tentando implementar um novo processo é difícil, independentemente do processo 
que você escolher. Não só você tem que aprender o processo, você também tem 
que produzir um resultado ao mesmo tempo. Esteja preparado para uma certa 
confusão e dificuldade que anda de mãos dadas com a tentativa nada de novo. Dito 
isto, a estrutura do FDD pode ser facilmente adaptado para mover-se gradualmente 
a partir de seu processo existente para uma abordagem FDD. 
O que eu encontrei para ser uma maneira eficaz de começar é olhar para projectos 
de uma forma FDD - ou seja, começar a pensar em projetos como um conjunto de 
características. Esta abordagem pode ser utilizada em quase qualquer projecto, 
independentemente do tamanho ou da tecnologia. 
Definir um projeto como uma lista de recursos ou funções 
Em algum ponto, cada projeto precisa ser definido por aquilo que ele faz ou o que a 
funcionalidade que ele proporciona. Ao listar todas essas funções (ou recursos) do 
sistema, você está definindo o que é que você precisa para construir para concluir o 
projeto. 
 16 
A chave é certificar-se você usar a mesma linguagem que o cliente, não use termos 
técnicos que o cliente não vai entender porque eles não se importam se você 
construir. Se eles entendem o recurso, eles se preocupam com se ele tem ou não foi 
construído. 
 
Plano de desenvolvimento com base em características 
Uma vez que você sabe o que você tem que construir, é uma tarefa bastante 
simples para trabalhar fora da ordem. Como alguns recursos estarão dependentes 
dos outros, eles têm claramente a ser construído. Seja qual for o fim, agora você tem 
um plano de desenvolvimento que você usa para acompanhar o seu progresso. 
Acho que é útil para obter o principal desenvolvedor para fornecê-lo com a estrutura 
da ordem e tempo para o plano de desenvolvimento, dessa forma, eles se 
comprometem com o plano e eu temos algo para voltar para quando as coisas não 
estão acontecendo quando é suposto para. 
 
Reuniões de status do projeto semanal com base em características 
concluídas 
Se você tem uma lista do que precisa ser feito e quando, é fácil então acompanhar o 
progresso e relatório de volta para o cliente. É incrível como ela é eficaz para ser 
capaz de dizer a um cliente que recursos tenham sido concluídas e que você está 
trabalhando atualmente. 
Como gerente de projeto, você também descobrir sobre problemas muito cedo no 
pedaço e ter a chance de enfrentá-los antes que se tornem um grande problema. 
 17 
2.5.2 EXTREME PROGRAMMING (XP) 
2.5.2.1 CONCEITOS 
 
O método XP, talvez seja o mais usado dos métodos de desenvolvimento ágeis. 
Este método foi escrito por Kent Beck e recentemente foi refinado, esta variação foi 
denominada IXP (Industrial XP) que tende a ser o processo ágil para grande 
organizações usarem. 
Beck definiu um conjunto de cinco valores para estabelecer as bases para todo 
trabalho realizado como parte da XP. Comunicação, simplicidade, 
feedback(realimentação ou retorno), coragem e respeito. Estes valores são usados 
como um direcionador das atividades específicas da XP. 
Para conseguir uma comunicação efetiva entres os envolvidos no desenvolvimento 
do software, a XP enfatiza a colaboração estreita entre clientes e desenvolvedores, 
o estabelecimento de metáforas eficazes para comunicar conceitos importantes, 
feedback contínuo e evitar documentação volumosa. 
Para alcançar a simplicidade a XP restringe os desenvolvedores a projetar apenas 
as necessidades imediatas. O intuito é facilitar a implementação do código. Se o 
projeto tiver que ser melhorado, ele poderá ser refabricado futuramente. 
 
2.5.2.2 CARACTERISTICAS 
O feedback provém de três fontes: software implementado, cliente e outros 
membros da equipe de software. Através da elaboração e implementação de uma 
estratégia eficaz, o software propicia um feedback para a equipe ágil. No métodoXP, 
todos os requisitos são expressos como cenários, que são implementados 
diretamente como uma serie de tarefas. Os programadores trabalham em pares e 
desenvolvem testes para cada tarefa antes da escrita do código, assim exercitando 
cada operação de acordo com sua funcionalidade especificada. Sempre que um 
incremento é entregue para o cliente, os casos de uso são usados para base de 
testes de aceitação e gera uma forma de feedback. Conforme o surgimento de 
novas necessidades, rapidamente a equipe informa o cliente sobre o impacto nos 
custos e no cronograma do desenvolvimento do software. 
Um preceito fundamental na engenharia de software é que você deve projetar para a 
mudança, antecipando melhorias futuras para o software e projeta-lo para que seja 
facilmente implementado. Beck afirmou este preceito, apontando que certas praticas 
da XP exige coragem, uma palavra melhor seria disciplina. A maioria das equipes de 
software argumentam que “projetar para o amanhã” poupará tempo e esforços a 
longo prazo. Uma equipe XP ágil deve ter disciplina (coragem) para projetar hoje, 
reconhecendo que as necessidades futuras podem mudar dramaticamente exigindo, 
consequentemente, substancial retrabalho em relação ao projeto e ao código 
implementado. 
 
 18 
2.5.2.3 CICLO DE VIDA XP 
A XP emprega uma abordagem orientada a objetos como seu paradigma de 
desenvolvimento preferido, envolvendo um conjunto de regras e práticas constantes 
no contexto de quatro atividades metodológicas . 
Planejamento – Esta atividade se inicia com a pratica de ouvir, que é uma atividade 
de levantamento de requisitos que capacita os membros da equipe que irá 
desenvolver o software a entender o ambiente de negócio e possibilitando observar 
os resultados solicitados, fatores principais e funcionalidades. 
A atividade de “ouvir” conduz a criação de “histórias” que descrevera requisitos para 
a construção do software. Cada história é escrita pelo cliente e é colocada em uma 
ficha. O cliente atribui uma valor (uma propriedade) à história baseando-se no valor 
do negócio global do recurso ou função. Então a equipe de software avaliam e 
atribuem um custo que é baseado em semanas de desenvolvimento. Se for avaliado 
em mais de três semanas é solicitado ao cliente dividir a história, ocorrendo uma 
nova atribuição de custo. É importante notar que novas histórias podem ser escritas 
a qualquer momento. 
Clientes e desenvolvedores decidem juntos como agrupar historias para o próximo 
incremento a ser desenvolvido. Assim chegam a uma concordância sobre quais 
histórias serão incluídas, data de entrega e outras questões. A equipe ordena as 
histórias em uma das três formas: (1) Todas serão implementadas imediatamente. 
(2) As histórias de maior valor serão deslocadas para cima e serão implementadas 
primeiro. (3) As histórias de maior risco serão deslocadas para cima e serão 
implementadas primeiro. 
Depois da entrega do primeiro incremento, a equipe calcula a velocidade do projeto, 
este calculo é utilizado para estimar as datas de entrega e o cronograma para as 
versões subsequentes e determinar se foi assumido um compromisso exagerado 
para todas as histórias. Caso tenha ocorrido o exagero, o conteúdo dos incrementos 
é modificado ou as datas de entregas são alteradas. 
Projeto – O projeto XP adota um princípio que é preferível sempre um projeto 
simples do que uma representação mais complexa. 
A XP encoraja o uso de cartões CRC como mecanismo eficaz para pensar sobre o 
software em um contexto orientado a objetos. Estes cartões identificam e organizam 
as classes orientadas a objetos relevantes para o incremento do software corrente. 
Se for encontrado uma problema difícil no projeto, é recomendado imediatamente a 
criação de um protótipo operacional dessa parte do projeto (Solução Pontual). O 
objetivo é reduzir o risco para quando a verdadeira implementação iniciar e validar 
as estimativas originais para a história contendo o problema de projeto. 
Como o projeto XP não usa praticamente nenhuma notação e produz poucos 
artefatos, o projeto é visto como algo transitório que pode ser continuamente 
modificado. É importante lembrar que o esforço necessário para a refabricação pode 
aumentar à medida que o tamanho de uma aplicação cresça. 
Codificação – Depois de desenvolvidas as histórias e o trabalho preliminar de 
elaboração ter sido feito, a equipe passa a desenvolver uma serie de testes de 
unidades que exercitarão cada uma das histórias a ser inclusas na incrementação 
corrente. Estando o código completo, este pode ser testado em unidade 
imediatamente e gerar feedback para os desenvolvedores. 
Um conceito-chave na atividade de codificação é a programação em dupla. Isso 
fornece um mecanismo para resolução de problemas em tempo real e garantia da 
 19 
qualidade em tempo real. Cada pessoa assume um papel ligeiramente diferente, 
enquanto um poderia pensar nos detalhes da codificação o outro assegura que 
padrões de codificação sejam seguidos. 
Conforme a dupla completa o trabalho, o código é integrado ao trabalho de outros 
por uma equipe de integração ou pela própria dupla. 
Testes – Os testes de unidade criados devem ser implementados usando-se uma 
metodologia que os capacite a ser automatizados. Isso encoraja uma estratégia de 
testes de regressão em que o código for modificado. 
Os testes de integração e validação do sistema podem ocorrer diariamente. Isso dá 
a equipe uma indicação contínua do progresso e também permite lançar alertas logo 
no início, caso as coisas não andem bem. 
Os testes de aceitação, são especificados pelo cliente e mantêm o foco nas 
características e na funcionalidade do sistema total que são visíveis e que podem 
ser revista pelo cliente. 
 
 
2.5.3 LEAN 
2.5.3.1 Conceito 
O termo Lean foi utilizado pela primeira vez em 1990, dando destaque ao sistema de 
produção aplicado pela Toyota na década de 1960 para construção de automóveis 
(POPPENDIECK e POPPENDIECK, 2011). 
Sua aplicação em desenvolvimento de software surgiu em conjunto com o Manifesto 
Ágil (BECK, BEEDLE, et al., 2001) e das metodologias que foram aplicadas a partir 
dessa abordagem. Os princípios discutidos pelo Lean deixam claro o foco na 
necessidade do cliente e contrastam, em alguns momentos, com conceitos básicos 
defendidos em outros modelos da Engenharia de Software. 
São sete os princípios defendidos pelo Lean para desenvolvimento de software 
(POPPENDIECK e POPPENDIECK, 2011), descritos no Quadro 2. Dentre eles, 
podem-se destacar a eliminação de desperdícios e a entrega rápida de parte do 
produto, discutidos e enfatizados por diversos trabalhos. 
 
2.5.3.2 Características do Lean 
 Eliminar o desperdício 
 Fortalecer o time 
 Entregas rápidas 
 Otimizar o todo 
 Construir qualidade 
 Adiar decisões 
 Amplificar conhecimento 
 
 
 20 
São considerados como desperdícios: 
 Trabalho parcialmente feito – O famoso “está pronto, só falta testar”. É 
fundamental que as equipes criem uma boa definição de “pronto/done” para 
evitar retrabalhos em itens teoricamente finalizados. 
 Processos extras – Documentação “pesada” exigida que não agrega valor ao 
software final. 
Fortalecer o time 
Criar um ambiente onde a equipe trabalhe de forma auto-organizada e auto-dirigida, 
evitando micro-gerenciamento. 
Entregas rápidas 
Maximizar o ROI (Return Of Investiment) do projeto, entregando software de valor de 
forma rápida e contínua. 
 Otimizar o todo 
Entender que o software concluído é muito mais que a soma das partes entregues e 
verificar como ele está alinhado com os objetivos da empresa. 
 Construir qualidade 
Garantir qualidade no desenvolvimento do software utilizando técnicas como: 
Teste unitário através de TDD : Escrever o teste / teste falho / escrever o código 
para passar o teste 
Fatoração: Melhorar e refinar o código escrito,evitando manter legados de débitos 
técnicos e fazendo com o que o software continue se comportando da mesma 
maneira. 
Integração contínua: Compilação automática do repositório de código, verificando se 
o código inserido não prejudicou demais funcionalidades do software. 
 Adiar decisões 
Deixar as decisões e comprometimentos para o último momento responsável, 
permitindo coletar informações e ter experiências para fortalecer a tomada de 
decisão. 
Amplificar conhecimento 
Priorizar a comunicação e o feedback contínuos entre equipes e usuários durante o 
processo de desenvolvimento de software. 
 
2.5.3.3 Ciclo de Vida 
Ciclo de vida do Lean em uma empresa 
 21 
 
 
 
O ponto chave aqui é que embora a maioria dos esforços de melhoria tenham sido 
gastos na produção, isso é geralmente a menor área de impacto, uma vez que 
 22 
tipicamente mais de 80% do custo é comprometido antes mesmo dele ir para a 
produção. Ainda, apenas 20% do custo pode ser adicionado antes desse ponto, 
então esse fato pode facilmente permanecer escondido. A maioria dos re-projetos de 
processos em operações existentes é o desperdício da correção do pobre projeto 
inicial do sistema. 
 
 
2.5.3.4 Aplicações 
Esta cada vez mais evidente que o Lean é um sistema de negócios que pode ser 
aplicado a qualquer setor, pois permite atender os clientes com alta qualidade 
,baixos custos e prazos de entrega adequados. 
O sucesso ao longo prazo dessa filosofia de negócios deve-se ao modo de pensar 
Lean que deve estar presente em todos os lugares e áreas de negócios incluindo os 
trabalhos de desenvolvimento de software. 
As aplicações dos conceitos Lean fazem o trabalho e informações fluírem mais 
visivelmente. 
 
 
2.5.4 KANBAM 
2.5.4.1 Conceito Kanban 
Kanban significa cartão visual e isso explica todo o seu processo. O sistema é 
originado no Japão, onde o executivo Taiichi Ohno observou nos supermercados 
americanos a reposição de produtos nas prateleiras dos mercados, onde os próprios 
clientes eram quem alertam a reposição da mercadoria. 
O sistema está relacionado ao sistema de “puxar” a produção. Onde se pode 
controlar o fluxo da geração a fim de se obter a mercadoria. Com isso o executivo 
resolveu implantar esse sistema em sua empresa, que era a Toyota, adaptando-a 
para a linha de produção. Ao se implantar este método, foi possível reparar melhoras 
na produção da Toyota. 
O Kanban é baseado na ideia onde atividades em andamento devem ser limitadas. 
Um novo item só pode ser iniciado quando o item em andamento é finalizado ou 
quando uma função automática inicia o mesmo instantaneamente. 
O Kanban, basicamente, tem como principal objetivo transformar o trabalho em 
andamento visível para toda equipe, criando um sinal visual que indica que o novo 
trabalho pode ou não ser iniciado e se o limite acordado para cada fase está sendo 
respeitado. 
Dadas as prescrições, percebe-se que o Kanban baseia-se em um processo onde o 
fluxo de trabalho é contínuo, ou seja, diferente de Scrum, não há um ciclo de 
trabalho definido onde, conhecida uma atividade, a mesma é estimada e colocada 
neste ciclo. 
 23 
Kanban controla as entradas de itens de trabalho e a vazão que é dada de acordo 
com o WIP definido. 
A esta vazão dos itens de trabalho dá-se o nome de leadtime, que representa o 
tempo de um item de trabalho desde a sua entrada no fluxo de trabalho mapeado 
até a sua saída. Kanban permite a combinação de ferramentas de diversos métodos 
até se obter o processo adequado. Baseia-se fortemente no pensamento Lean 
[Poppendieck 2003] e estimula a melhoria contínua do processo, de forma a tornar 
possível dar respostas rápidas ao cliente. 
Kanban é um método de desenvolvimento de software com fortes bases em práticas 
Lean, e que tem como objetivo aperfeiçoar o processo de desenvolvimento de 
software pré-existente. Este método limita o trabalho em progresso, apresentando a 
evolução de forma visual, tornando os problemas evidentes e cultivando uma cultura 
de melhoria contínua. 
 
PRÉ-REQUISISTOS PARA IMPLANTAÇÃO DO KANBAN 
 • Produção nivelada: produzir apenas a quantidade necessária para o processo 
subseqüente de acordo com a demanda de quantidade e variedade; 
• Redução de tempo de Preparação: adaptar os equipamentos produtivos para 
setups mais rápidos. 
 • Layout das máquinas: buscar o melhor layout para um trabalho mais produtivo, 
permitindo que um operador execute várias funções. 
• Padronização dos trabalhos: padronizar as rotinas e os processos, criando 
manuais que facilitem o uso por qualquer operador;. 
• Aperfeiçoamento das atividades: as atividades devem ser constantemente 
reavaliadas, proporcionando uma melhoria contínua nas rotinas e processos. 
• Automação: automatizar o máximo 
possível cada processo de fabricação, 
garantindo a qualidade e a velocidade das atividades. 
 
2.5.4.2 Caracteristicas Kanban 
Recorrendo aos conceitos anteriores e focalizando suas características básicas, 
pode-se dizer que o sistema kanban é um sistema de controle do fluxo de 
informações e produção em um ambiente JIT, que controla harmoniosamente a 
produção dos produtos necessários nas quantidades e no tempo necessário, 
reduzindo os tempos de espera, diminuindo os estoques, melhorando a 
produtividade e interligando todas as operações de produção interna na fábrica e os 
processos de fornecimento de materiais de fornecedores externos. 
Minimizar o inventário em processo e os estoques de produtos acabados;Minimizar a 
flutuação dos materiais em processo, visando simplificar o seu controle; 
Reduzir o "lead time" de produção, 
Evitar a transmissão de flutuações ampliadas de demanda ou do volume de 
produção entre processos; 
Descentralizar o controle da fábrica, fornecendo aos operadores e supervisares de 
área tarefas no controle de produção e de estoque; 
Permitir uma maior capacidade reativa do setor produtivo à mudança da demanda; 
Reduzir os defeitos através da diminuição dos lotes de fabricação; 
Permitir o controle visual ao longo das etapas de fabricação; e 
 24 
Fornecer os materiais sincronizadamente, em tempo e quantidade, conforme sua 
necessidade, no local certo. 
Uma outra característica importante do modelo Kanban é o conceito de "puxar 
tarefa" quando há capacidade de processá-la. Esse recurso vai de encontro ao 
tradicional modelo de "empurrar tarefa" conforme sua demanda, mantendo assim o 
bom desempenho da equipe. Portanto, ao invés dos membros que produzem o 
produto receberem atividades conforme suas demandas, os requisitos são 
adicionados a lista de backlog e "puxados" pelos membros que liberam suas 
atividades correntes e se tornam disponíveis para iniciar uma nova tarefa. 
 
2.5.4.3 Ciclo de vida 
Existem várias técnicas interessantes para o modelo Kanban em termos de 
planeamento de entregas e gestão de compromissos, no entanto não há nenhuma 
técnica específica ou obrigatória a ser seguida. 
Neste sentido Kanban deixa-nos abertos a novas formas e técnicas até 
encontrarmos a que melhor se encaixe no contexto do Projecto. 
Provavelmente veremos algumas “boas práticas” surgir ao longo do tempo. Conceito 
Kanban 
O ciclo de vida mais usado é um painel com colunas e cores para cada etapa a ser 
cumprida. 
2.5.4.4 Aplicação do Kanban 
Pode ser usado em modelos ágeis ou tradicionais, moldando a cultura da 
organização e encorajando a melhoria contínua. É baseado na ideia de que as 
atividades em andamento devem ser limitadas (WIP – work in progress). Novas 
funcionalidades só devem ser iniciadas quando uma peça de trabalho existente é 
liberada ou quando uma função automática inicia isso. 
O processo é mapear o fluxo de valor e limitar as atividades em andamento para 
cada estágio desse processo. Existe o risco do processo ficar parado, caso certa 
quantidade de itens detrabalho ficar bloqueada. Isso exige que toda a equipe de 
software se mobilize para resolver o problema e restaurar o fluxo habitual. Kanban 
usa um quadro branco com post-its, ou um sistema de cartões eletrônicos, provendo 
transparência ao processo e ao fluxo e encorajando a evolução incremental. A 
abordagem Kanban não demanda revolução drástica na empresa, mas sim uma 
adaptação gradual. 
Como consequência das atividades em andamento limitadas, Kanban fornece 
previsibilidade de tempo em ciclos e faz as entregas mais confiáveis. A obrigação de 
focar os esforços nas tarefas que estão paradas encoraja melhoria de qualidade e 
diminuição de retrabalho. 
 
 25 
3 MODELO DE PROCESSO EVOLUCIONÁRIO 
3.1 CONCEITO 
 
O software evolui ao longo do tempo e conforme o desenvolvimento deste software 
avança também temos mudanças nas necessidades de negócio e de produtos que 
mudam frequentemente. Isso torna inadequado seguirmos um planejamento em 
linha reta de um produto. Os modelos de processo evolucionário tornaram-se 
realidade para que possamos desenvolver um produto que evolua ao longo do 
tempo. 
Tem como base a ideia de desenvolver uma implementação inicial, expor o resultado 
ao comentário do usuário e fazer seu aprimoramento por meio de muitas versões, 
até que um sistema adequado tenha sido desenvolvido. 
Em vez de ter as atividades de especificação, desenvolvimento e validação em 
separado, todo esse trabalho é realizado concorrentemente com um rápido feedback 
por meio dessas atividades. 
A abordagem evolucionária do desenvolvimento de software, muitas vezes, é mais 
eficaz do que a abordagem em cascata, no sentido de produzir sistemas que 
atendam às necessidades imediatas dos clientes. 
A especificação pode ser desenvolvida gradativamente. À medida que os usuários 
desenvolvem uma compreensão melhor de seus problemas, isso pode ser refletido 
na melhoria do software em construção. 
3.1.1 CARACTERISTICAS 
 
Modelos evolucionários são caracterizados por serem iterativos e apresentarem 
características que possibilitem desenvolvermos versões cada vez mais completas 
do software. 
Os processos evolucionários se caracterizam por dois modelos comuns: 
Prototipação e Espiral. 
 
- Prototipação: A prototipação é utilizada quando o desenvolver não tem certeza 
quanto à eficiência de um algoritmo, ou quanto à adaptabilidade de um sistema 
operacional ou ainda quanto à forma em que deva ocorrer a interação entre o cliente 
e o sistema. Quando temos essa situação a prototipação é uma excelente 
alternativa. Vale ressaltar que a prototipação pode ser utilizada em qualquer 
processo de software, visto que a prototipação auxilia os interessados a 
compreender melhor o que está para ser construído. 
- Modelo espiral: O famoso modelo espiral foi proposto por Boehm. Esse é um 
modelo de processo de software evolucionário que também é iterativo como a 
prototipação, porém com aspectos sistemáticos e controlados do modelo cascata. O 
modelo espiral fornece um grande potencial para que possamos ter rápido 
desenvolvimento de versão cada vez mais completas. 
 
 26 
 
3.2 CICLO DE VIDA 
A prototipação se dá basicamente com a comunicação que ocorre através de uma 
reunião com todos os envolvidos a fim de definir objetivos gerais do software e 
identificar quais requisitos já estão bem conhecidos e esquematizar as áreas que 
realmente necessitam de uma definição mais ampla. Uma iteração de prototipação 
deve ser planejada rapidamente e dessa forma ocorre a modelagem na forma de um 
projeto rápido. O projeto rápido foca na representação dos aspectos do software que 
serão visíveis aos usuários como layout da interface e os formatos de exibição. Esse 
projeto rápido leva à construção de um protótipo que será avaliado pelo cliente. O 
cliente por sua vez retornará um feedback á equipe de software que irá aprimorar os 
requisitos. A iteração vai ocorrendo conforme vamos ajustando o protótipo às 
necessidades dos usuários. A Figura 1 demonstra essas etapas 
 
Figura 1. Etapas da Prototipação de forma iterativa. 
De forma geral o protótipo auxilia na identificação dos requisitos do software. Os 
protótipos podem ser descartados quando usamo-los apenas para entender um 
determinado requisito ou pode ser utilizado como um produto evolucionário que 
servirá para o cliente. 
 
Um modelo espiral possui diversas atividades definidas pela engenharia de software, 
onde cada uma dessas atividades representa um segmento do caminho espiral. 
Para termos uma ideia melhor, a Figura 2 demonstra o modelo espiral. 
 27 
 
Figura 2. Ilustrando o Modelo espiral. 
Sempre iniciamos pelo centro da espiral e prosseguimos no sentido horário. 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 vamos evoluindo para versões cada vez mais sofisticadas do 
software. Cada passagem pela parte de 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 cliente após uma entrega. Também teremos um 
ajuste no número de iterações planejadas para completar o software. 
Podemos notar que diferente de outros modelos que terminam quando o software é 
entregue, o modelo espiral pode ser adaptado a cada entrega. O projeto finaliza 
quando o cliente fica satisfeito, quando o software é retirado de operação ou uma 
data encerra definitivamente o projeto. 
O modelo espiral é largamente utilizado e é considerada uma abordagem realista 
para desenvolver sistemas em larga escala. 
Neste artigo vimos o que são os modelos prescritivos e quais são os modelos que 
fazem parte deles. Também vimos mais especificamente dois modelos bastante 
utilizados que é o modelo incremental e o modelo evolucionário. Também vimos 
outros dois modelos que os modelos evolucionários se caracterizam, são eles a 
prototipação e o modelo espiral. Dois modelos muitos utilizados e que servem como 
base para outros modelos atuais. 
 
 28 
3.3 EXEMPLOS DE PROCESSO 
3.3.1 MODELO DE MÉTODOS FORMAIS 
3.3.1.1 CONCEITOS 
As propriedades desejadas de uma especificação formal (consistência, totalidade e 
ausência de ambiguidade) são os objetivos de todos os métodos de especificação. 
No entanto, a linguagem de especificação com base matemática, usada para 
métodos formais, resulta em uma possibilidade de obter essas propriedades. A 
sintaxe formal de uma linguagem de especificação possibilita que os requisitos 
sejam interpretados de uma única maneira ou uma notação gráfica deve ser 
interpretada por um leitor. 
Sem aprofundar em detalhes da matemática, vamos consideram um exemplo para 
introduzirmos os conceitos da matemática e ilustrar o uso da especificação 
matemática. 
 
O modelo de métodos formais engloba um conjunto de atividades que conduzem à 
especificação matemática formal do software. Os métodos formais possibilitam 
especificar, desenvolver e verificar um sistema baseado em computador através da 
aplicação de uma notação matemática rigorosa. Uma variação dessa abordagem, 
chamada engenharia de software ‘cleanroom’ (sala limpa/leve), é aplicada 
atualmente por algumas organizações de desenvolvimento de software. 
Quando são utilizados métodos formais durante o desenvolvimento, este oferecem 
um mecanismo que elimina muitos dos problemas difíceis de ser superados com o 
uso de outros paradigmas de engenharia de software. Ambiguidade, incompletude e 
inconsistência podem ser descobertas e corrigidas com mais facilidade, devido à 
aplicação de analise matemática. Quando são utilizados métodos formais durante o 
projeto, servem como base para verificar a programação e possibilitando que se 
descubra e se corrijam erros quepoderiam passar despercebidos. 
 
3.3.1.2 CARACTERISTICAS 
 
Embora não seja uma abordagem predominante, o modelo de métodos formais 
oferece a promessa de software sem defeitos. No entanto, foram mencionados 
motivos para preocupação a respeito de sua aplicabilidade em um ambiente de 
negócios: 
 Atualmente, o desenvolvimento de modelos formais consome muito tempo e 
dinheiro. 
 29 
 Pelo fato de poucos desenvolvedores de software possuírem formação e 
experiência necessária para aplicação dos métodos formais, é necessário 
treinamento extensivo. 
 É difícil usar os modelos como um meio de comunicação com cliente 
tecnicamente despreparados. 
Apesar dessas preocupações, a abordagem de métodos formais tem conquistado 
adeptos entre os desenvolvedores de software que precisam desenvolver software 
com fator critico de segurança. 
 
3.3.1.3 CICLO DE VIDA 
 
A engenharia de software sala limpa usa uma versão especializada do modelo de 
métodos formais. Uma sequencia de incrementos de software é desenvolvida por 
pequenas equipes de software independentes. À medida que cada incremento é 
certificado, ele é integrado no todo. Daí o motivo pelo qual o sistema cresce com o 
tempo. 
A sequencia das tarefas sala limpa esta ilustrada abaixo. 
 
 
 De acordo com a sequencia para incrementos cleanrun, ocorrem as seguinte 
tarefas: 
Planejamento de incremento – É desenvolvido um plano de projeto que adota a 
estratégia incremental. São criados a funcionalidade de cada incremento, seu 
tamanho projetado e um cronograma de desenvolvimento sala limpa. Deve ter 
cuidado para garantir que os incremento certificados serão integrados no seu devido 
tempo. 
Coleta dos requisitos – Usando técnicas similares à engenharia de requisitos, é 
 30 
desenvolvida uma descrição mais detalhada dos requisitos no nível do cliente. 
Especificação da estrutura de caixa. É usando um método de especificação que 
emprega estruturas de caixas para descrever a especificação funcional. As 
estruturas de caixas isolam e separam a definição criativa de comportamento, dados 
e procedimentos em casa nível de refinamento. 
Projeto formal – Por meio da abordagem de estrutura de caixas, o projeto sala 
limpa é uma extensão natural e contínua da especificação. As especificações são 
refinadas iterativamente para se tornarem análogas aos projetos arquitetônicos e no 
nível de componentes. 
Verificação de correção - A equipe sala limpa executa uma série de atividades de 
verificação rigorosa de correção sobre o projeto e depois sobre o código. A 
verificação começa com a estrutura de caixas de nível mais alto e se move em 
direção ao detalhe do projeto. O primeiro nível de verificação de correção ocorre 
aplicando uma série de perguntas de correção. Se as perguntas não demonstrarem 
que a especificação esta correta, utilizam-se métodos mais formais. 
Geração de código, inspeção e verificação – As especificações de estrutura de 
caixa, representadas em uma linguagem especializada, são traduzidas e linguagem 
de programação apropriada. São usadas revisões técnicas para garantir a 
conformidade da semântica do código e das estruturas de caixa e correção sintática 
do código. Então é executada a verificação de correção para o código fonte. 
Planejamento do teste estatístico – É analisado o uso do software e é planejada e 
projetada uma série de casos de teste que experimentam uma distribuição de 
probabilidades de uso. Essa atividade sala limpa é executada em paralelo à 
especificação, verificação e geração de código. 
Teste estatístico de uso – É sempre necessário projetar um número finito de casos 
de teste. As técnicas estatísticas de uso executam uma série de testes derivados de 
uma amostragem estatística de todas as execuções de programa possíveis por 
todos os usuários de uma população-alvo. 
Certificação – Uma vez completadas a verificação, inspeção e teste de uso, o 
incremento é certificado como pronto para a integração. 
As quatros primeiras atividades no processo sala limpa preparam o cenário para as 
atividades de verificação formal que vem em seguida. Por isso, começa a discussão 
da abordagem sala limpa com as atividades de modelagem que são essências para 
a verificação formal a ser aplicada. 
 
 
3.3.1.4 APLICACAO 
Exemplo (Um tratador de blocos): Uma das partes mais importantes de um SO 
simples é o subsistema que mantém os arquivos criados pelos usuários. Parte do 
subsistema de arquivos é o tratador de blocos. Os arquivos no sistema de 
armazenamento de arquivos são formados por blocos de armazenamento mantidos 
em um dispositivo de armazenamento. Durante a operação do computador, arquivos 
são criados e excluídos, e isso requer a aquisição e liberação de blocos de 
armazenamento. Para enfrentar a tarefa, o subsistema de arquivamento devera 
manter um reservatório de blocos não utilizados e manter controle de blocos que 
estão correntemente em uso. Quando os blocos são liberados porque um arquivo foi 
excluído, eles normalmente são acrescentados a uma fila de blocos à espera de 
 31 
serem acrescentados ao reservatório de blocos não utilizados. 
Para esse subsistema, o estado é a coleção de blocos livres, a coleção de blocos 
utilizados e a fila de blocos devolvidos. A invariante de dados, expressão em 
linguagem natural é 
 Nenhum bloco será marcado como não usado e usado ao mesmo tempo. 
 Todos os conjuntos de blocos mantidos na fila serão subconjuntos da coleção 
de blocos usados correntemente . 
 Nenhum elemento da fila terá o mesmo número de blocos. 
 A coleção formada por blocos usados e blocos não usados será a coleção 
total dos blocos que formam os arquivos. 
 A coleção de blocos não usados não terá número de blocos duplicados. 
 A coleção de blocos usados não terá número de blocos duplicados. 
Algumas das operações associadas a esses dados são: Acrescentar uma coleção 
de blocos ao fim da fila, remover uma coleção de blocos usados da frente da fila e 
coloca-los em uma coleção de blocos não usados e verificar se uma fila de blocos 
está vazia. 
A precondição de acrescentar é que os blocos a ser adicionados devem estar na 
coleção de blocos usados. A pós-condição é que a coleção de blocos agora se 
encontra no fim da fila. A precondição de remover é que a fila deve ter pelo menos 
um item nela. A pós-condição é que os blocos devem ser adicionados à coleção de 
blocos não usados. A operação verificar não tem precondição. Isso significa que a 
operação é sempre definida, independente do valor do do estado. A pós-condição 
fornece o valor ‘true’ se a fila estiver vazia e ‘false’ caso contrario. 
 
 
3.3.2 MODELO DE PROCESSO INCREMENTAL 
3.3.2.1 CONCEITO 
Em várias situações, os requisitos iniciais do software são razoavelmente bem 
definidos, entretanto, devido ao escopo geral do trabalho de desenvolvimento, o uso 
de um processo puramente linear não é utilizado. Pode ser necessário o rápido 
fornecimento de um determinado conjunto funcional aos usuários, para somente 
após esse fornecimento, refinar e expandir sua funcionalidade em versões de 
software posteriores. Em tais casos, pode-se optar por um modelo de processo 
projetado para desenvolver o software de forma incremental. 
Podemos definir o modelo incremental como um processo de ciclo de vida iterativo e 
incremental com características do ciclo de vida sequencial (TRAMMELL, 1996). No 
modelo em cascata as fases são sequenciais: os requisitos são definidos, o projeto 
do sistema é criado, implementado e testado, é feita a integração e teste de sistema 
para finalmente entrar em produção. 
“O modelo incremental combina elementos do modelo em cascata aplicado de 
maneira iterativa” (PRESSMAN, 2006), ou seja, a cada incremento é fornecida uma 
parte do sistema aos clientes. O cliente define quais são os serviços principais e a 
 32 
partir da identificaçãodos serviços é feito o levantamento de requisitos e mapeado o 
primeiro incremento. 
Os processos de especificação, projeto, implementação e testes são feitos a cada 
incremento até o produto final ser entregue ao cliente gerando um sistema completo, 
conforme mostra a Figura 2.1. 
 
 
Figura 2.1: Modelo incremental 
“Quando um modelo incremental é usado, o primeiro incremento é frequentemente 
chamado de núcleo do produto” (PRESSMAN, 2006). O núcleo do produto serve de 
base para os outros incrementos. 
A cada incremento entregue ao cliente é desenvolvido um plano para o próximo 
incremento. Este processo é feito a cada termino e início dos incrementos e tem por 
objetivo alterar o núcleo do produto para atender o cliente (PRESSMAN, 2006). 
A interação do usuário é primordial no desenvolvimento incremental principalmente 
na definição dos principais serviços e no retorno (feedback) da utilização do sistema. 
As principais características do modelo incremental segundo Sommerville (2007) 
são: 
 Os processos de especificação, projeto e implementação são concorrentes. 
 O sistema é desenvolvido em uma série de incrementos. 
 Ferramentas de apoio ao desenvolvimento interativo. 
De acordo com Sommerville (2007), as vantagens do desenvolvimento incremental 
são: 
 Entrega dos incrementos ao cliente, ou seja, partes do sistema em 
funcionamento. 
 Participação dos clientes ou usuários no processo de desenvolvimento 
incremental. 
Alguns dos problemas do desenvolvimento incremental segundo Sommerville (2007) 
são: 
 Problemas no gerenciamento de grandes sistemas 
 Problemas em montar um contrato para atender ambas as partes 
interessadas 
 
 
 33 
3.3.2.2 CARACTERISTICAS 
 
O modelo incremental combina elementos dos fluxos de processos lineares e 
paralelos. O modelo aplica sequências lineares, de forma escalonada, à medida que 
o tempo vai avançando. Cada sequência linear gera “incrementais” do software de 
maneira similar aos incrementais gerados por um fluxo de processos evolucionários. 
Por exemplo, um software de processamento de texto desenvolvido com o emprego 
do paradigma incremental, poderia liberar funções básicas de gerenciamento de 
arquivos, edição de produção de documentos no primeiro incremento; recursos mais 
sofisticados de edição e produção de documentos no segundo; revisão ortográfica e 
gramatical no terceiro; e, finalmente, recursos avançados de formatação (layout) de 
página no quarto incremento. Deve-se notar que o fluxo de processo para qualquer 
incremento pode incorporar o paradigma de prototipação. 
Quando se utiliza um modelo incremental, frequentemente, o primeiro incremento é 
um produto essencial. Isto é, as os requisitos básicos são atendidos, porém, muito 
recursos complementares (alguns conhecidos, outros não) ainda não são entregues. 
Esse produto essencial é utilizado pelo cliente (ou passa por uma avaliação 
detalhada). Como resultado do uso e/ou avaliação, é desenvolvido um planejamento 
para o incremento seguinte. O planejamento já considera a modificação do produto 
essencial para melhor se adequar as necessidades do cliente e a entrega de 
recursos e funcionalidades adicionais. Esse processo é repetido após a liberação de 
cada incremento, até que seja produzido o produto completo. 
O modelo de processo incremental tem seu foco voltado para a entrega de um 
produto operacional com cada incremento. Os primeiros incrementos são versões 
seccionadas do produto final, mas eles realmente possuem capacidade para atender 
ao usuário e também oferecem uma plataforma para avaliação do usuário. 
O desenvolvimento incremental é particularmente útil nos casos em que não há 
pessoal disponível para uma completa implementação na época de vencimento do 
prazo estabelecido para o projeto. Os primeiros incrementos podem ser 
implementados com número mais reduzido de pessoal. Se o produto essencial for 
bem acolhido, então um pessoal adicional (se necessário) poderá ser acrescentado 
para implementar o incremento seguinte. Alem disso, os incrementos podem ser 
planejados para administrar riscos técnicos. Por exemplo, um sistema importante 
pode exigir a disponibilidade de novo hardware que ainda está em desenvolvimento 
e cuja data de entrega é incerta. Poderia ser possível planejar incrementos iniciais 
de modo a evitar o uso desse hardware, possibilitando, portanto, a liberação de 
funcionalidade parcial aos usuários finais, sem um atraso excessivo. 
 
3.3.2.3 CICLO DE VIDA 
 
O modelo de processo incremental é interativo igual à prototipagem, mais diferente a 
prototipagem o incremental tem como objetivo, apresentar um produto operacional a 
cada incremento realizado. 
Esse modelo é muito útil quando a empresa não possui mão de obra disponível no 
momento para uma implementação completa, dentro do prazo estipulado. 
 34 
O desenvolvimento de um produto comercial de software é uma grande tarefa que 
pode ser estendida por vários meses, possivelmente um ano ou mais. Por isso, é 
mais prático dividir o trabalho em “pedaços” menores ou iterações. Cada iteração 
resultará num incremento. 
Iterações são passos em fluxo de trabalho e incrementos são crescimentos do 
produto. 
O princípio subjacente ao processo incremental e iterativo é que a equipa envolvida 
possa refinar e alargar pouco-a-pouco a qualidade, detalhe e âmbito do sistema 
envolvido. 
Por exemplo, numa primeira iteração deve-se identificar a visão global e determinar 
a viabilidade econômica do sistema, efetuar a maior parte da análise e um pouco de 
desenho e implementação.Numa segunda iteração, deve-se concluir a análise, fazer 
uma parte significativa do desenho e um pouco mais de implementação. 
Numa terceira iteração, deve-se concluir o desenho, fazer-se parte substancial da 
implementação, testar e integrar um pouco, etc. Ou seja, a principal consequência 
da aproximação iterativa é que os produtos finais de todo o processo vão sendo 
amadurecidos e completados ao longo do tempo, mas cada iteração produz sempre 
um conjunto de produtos finais. 
 
A cada iteração é feito: 
 
- Análise (refinamento de requisitos, refinamento do modelo conceitual) 
- Projeto (refinamento do projeto arquitetural, projeto de baixo nível) 
- Implementação (codificação e testes) 
- Transição para produto (documentação, instalação, ...) 
 
 
 
Vantagens do processo incremental e iterativo 
 
- Possibilidade de avaliar mais cedo os riscos e pontos críticos do projeto, e 
identificar medidas para eliminá-los ou controlar; 
 
 35 
- Redução dos riscos envolvendo custos a um único incremento. Se a equipa que 
desenvolve o software precisar repetir a iteração, a organização perde somente o 
esforço mal direcionado de uma iteração, não o valor de um produto inteiro; 
 
- Definição de uma arquitetura que melhor possa orientar todo o desenvolvimento; 
- Disponibilização natural de um conjunto de regras para melhor controlar os 
inevitáveis pedidos de alterações futuras; 
 
- Permite que os vários intervenientes possam trabalhar mais efetivamente pela 
interação e partilha de comunicação daí resultante; 
 
 - Existe sempre algo para entregar ao cliente apressado (a última iteração); 
 
- Os requisitos mudam com o tempo e um processo iterativo e incremental mantém 
frequentes os contactos com o cliente, o que ajuda a manter os requisitos 
sincronizados; 
 
- Redução do risco de lançar o projeto no mercado fora da data planeada. 
Identificando os riscos numa fase inicial, o esforço despendido para gerenciá-los 
ocorre cedo, quando as pessoas estão sob menos pressão do que numa fase final 
de projeto; 
 
- Aceleração do tempo de desenvolvimento do projeto como um todo, porque a 
equipa que desenvolve o software trabalha de maneira mais eficiente quando 
pretende alcançar resultados de escopo pequeno eclaro; 
 
- Altamente motivador para a equipa de desenvolvimento (e o cliente) ver o software 
funcionando cedo. 
 
3.3.2.4 APLICAÇÃO 
Amplamente usado em sistemas pequenos, o modelo incremental é usado quando 
se quer um sistema com várias versões. Usado em softwares de comércios de 
médio porte, onde se tem sempre a atualização da regra de negócio e requisitos do 
cliente, fazendo assim com que o software tenha sempre um incremento, mas 
sempre sendo analisado se essa nova atualização. 
 
3.3.3 MODELO DE PROCESSO CONCORRENTE 
3.3.3.1 CONCEITO 
O modelo de desenvolvimento concorrente possibilita à equipe de software 
representar elementos concorrentes e iterativos de qualquer um dos modelos de 
 36 
processos. A atividade de modelagem definida para o modelo espiral é realizada 
invocando uma ou mais das seguintes ações de engenharia de software: 
prototipagem, análise e projeto. 
A figura 1 mostra um esquema de uma atividade da engenharia de software, dentro 
da atividade de modelagem, usando uma abordagem de modelagem concorrente. A 
atividade modelagem poderia estar em qualquer um dos estados observados em 
qualquer instante determinado. Similarmente, outras atividades, ações ou tarefas 
podem ser representadas de maneira análoga. Todas as atividades de engenharia 
de software existem concorrentemente, porém estão em diferentes estados. 
Por exemplo, no inicio de um projeto, a atividade de comunicação completou sua 
primeira iteração e se encontra em no estado ‘aguardando modificações’. A atividade 
de modelagem que se encontra no estado inativo enquanto a comunicação inicial 
era completada, agora faz uma transição para o estado em desenvolvimento. Se o 
cliente indicar que mudanças nos requisitos devem ser feitas, a atividades de 
modelagem passa do estado ‘em desenvolvimento’ para o estado ‘aguardando 
modificações’. 
 
3.3.3.2 CARACTERISTICAS 
Um modelo de processo concorrente é conduzido por necessidades do usuário, 
decisões da gerência e resultados de revisão. É representado como uma série de 
grandes atividades técnicas, tarefas e seus estados associados. 
 
Todas as atividades existem concorrentemente, mas estão em diferentes estados. 
Por exemplo: Enquanto o desenvolvedor se comunica com o cliente, a atividade de 
análise está no estado “aguardando modificações”, quando essa comunicação 
termina, ela evolui para a fase “em desenvolvimento”. Assim, o modelo de processo 
concorrente define uma série de eventos que vão disparar transições de estado para 
estado, para cada uma das atividades de engenharia de software. 
 
O modelo de processo concorrente é aplicável a todos os tipos de desenvolvimento 
de software e fornece um panorama preciso do estado atual de um projeto. Não 
segue uma sequência de eventos, define uma rede de atividades, que transitarão de 
um estado a outro. 
 
3.3.3.3 CICLO DE VIDA 
A modelagem concorrente define uma serie de eventos que irão disparar transições 
de estado para estado para cada uma das atividades da engenharia de software. 
 37 
 
Figura 1 
 
Outros exemplo, durante estágios de projeto iniciais, uma inconsistência no modelo 
de requisitos não é descoberta. Isso gera o evento correção de modelo de análise, 
que irá disparar a ação de análise de requisitos, passando dos estado concluído 
para o estado aguardando modificações. 
A modelagem concorrente se aplica a todos os tipos de desenvolvimento de 
software e fornece uma imagem precisa do estado atual de um projeto. Em vez de 
limitar as atividades da engenharia de software a uma sequência de eventos, ela 
define uma rede de processos. Cada atividade, ação ou tarefa na rede existe 
simultaneamente com outras atividades. Eventos gerados em um ponto da rede de 
processos disparam transições entre os estados. 
 
3.3.3.4 APLICAÇÃO 
Por exemplo, a fase de Especificação pode estar em um, dentre diversos estados 
(desenvolvimento, completo, revisado e controlado no repositório). A criação e toda 
revisão à especificação original, ativa a fase do desenvolvimento de forma que ha 
um ciclo constante entre os estados. 
 38 
3.3.4 MODELO ESPIRAL 
3.3.4.1 Conceito 
modelo em espiral foi proposto por Boehm em 1988 como forma de integrar os 
diversos modelos existentes à época, eliminando suas dificuldades e explorando 
seus pontos fortes. Este modelo foi desenvolvido para abranger as melhores 
características tanto do ciclo de vida clássico como da prototipação, acrescentando, 
ao mesmo tempo, um novo elemento - a análise de riscos - que falta a esses 
paradigmas. 
Entretanto a integração não se dá através da simples incorporação de 
características dos modelos anteriores. O modelo em espiral assume que o processo 
de desenvolvimento ocorre em ciclos, cada um contendo fases de 
avaliação e planejamento, onde a opção de abordagem para a próxima fase (ou 
ciclo) é determinada. Estas opções podem acomodar características de outros 
modelos. 
O objetivo do modelo espiral é prover um metamodelo que pode acomodar diversos 
processos específicos. Isto significa que podemos encaixar nele as principais 
características dos modelos vistos anteriormente, adaptando-os a necessidades 
específicas de desenvolvedores ou às particularidades do software a ser 
desenvolvido. Este modelo prevê prototipação, desenvolvimento evolutivo e cíclico, e 
as principais atividades do modelo cascata. 
Sua principal inovação é guiar o processo de desenvolvimento gerado a partir deste 
metamodelo com base em análise de riscos e planejamento que é realizado durante 
toda a evolução do desenvolvimento. Riscos são circunstâncias adversas que 
podem surgir durante o desenvolvimento de software impedindo o processo ou 
diminuindo a qualidade do produto. São exemplos de riscos: pessoas que 
abandonam a equipe de desenvolvimento, ferramentas que não podem ser 
utilizadas, falha em equipamentos usados no desenvolvimento ou que serão 
utilizados no produto final, etc. A identificação e o gerenciamento de riscos é hoje 
uma atividade importantíssima no desenvolvimento de software devido à imaturidade 
da área e à falta de conhecimento, técnicas e ferramentas adequadas. 
3.3.4.2 Caracteristicas do modelo espiral 
• Determinação dos objetivos, alternativas e restrições; 
• Análise de risco e prototipação; 
• Validação e verificação; 
• Planejamento da fase seguinte. 
Esta concepção tende a criar um roteiro de atividades e etapas para que se alcance 
uma maturidade do processo evolutivo de desenvolvimento de sistemas complexos 
e obter, ao final, um produto em sua forma mais completa possível. 
O modelo em espiral, por suas características de avaliação e planejamento 
baseadas em risco, exige que se tenha gerentes e técnicos experientes. 
As tarefas gerenciais para acompanhamento e controle do projeto tornam-se mais 
 39 
difíceis, uma vez que o modelo em espiral pode levar ao desenvolvimento em 
paralelo de múltiplas partes do projeto, cada uma sendo abordada de modo 
diferenciado. É necessário o uso de técnicas específicas para estimar e sincronizar 
cronogramas, bem como para determinar os indicadores de custo e progresso mais 
adequados. 
 
3.3.4.3 Ciclo de vida do modelo espiral 
O modelo espiral descreve um fluxo de atividades cíclico e evolutivo constituído de 
quatro estágios. 
No estágio 1 devem ser determinados objetivos, soluções alternativas e restrições. 
No estágio 2, devem ser analisados os riscos das decisões do estágio anterior. 
Durante este estágio podem ser construídos protótipos ou realizar-se simulações do 
software. 
O estágio 3 consiste nas atividades da fase de desenvolvimento, incluindo design, 
especificação, codificação e verificação. A principal característica é que a cada 
especificação que vai surgindo a cada ciclo - especificação de requisitos, do 
software, da arquitetura, da interface de usuário e dos algoritmos e dados- deve ser 
feita a verificação apropriadamente. 
O estágio 4 compreende a revisão das etapas anteriores e o planejamento da 
próxima fase. Neste planejamento, dependendo dos resultados obtidos nos estágios 
anteriores - decisões, análise de riscos e verificação, pode-se optar por seguir o 
desenvolvimento num modelo Cascata (linear), Evolutivo ou Transformação. Por 
exemplo, se já no primeiro ciclo, os requisitos forem completamente especificados e 
validados pode-se optar por seguir o modelo Cascata. Caso contrário, pode-se optar 
pela construção de novos protótipos, incrementando-o, avaliando novos riscos e 
replanejando o processo. 
3.3.4.4 Aplicações na pratica 
O modelo espiral é mais adequado para sistemas complexos e que exijam um alto 
nível de interações com os usuários, a fim de possibilitar a abordagem de todos os 
problemas desse sistema. 
Usado com mais frequência em grandes projetos. 
 40 
4 CONCLUSÃO 
Observando todos os modelos de softwares disponíveis, vemos que cada vez mais 
empresas estão utilizando destes recursos para gerenciar seus projetos com mais 
integridade, segurança e precisão das informações internas e as fornecidas aos 
clientes, trazendo confiança e respeito para a empresa e todo o quadro de 
funcionários envolvidos nela. Para projetos que tenham um ciclo de vida mais curto, 
que tenha menores prazos, é sempre ideal utilizar o modelo ágil, devido a sua 
benéfica capacidade de realizar o projeto com qualidade, prazos otimizados e custos 
dentro do orçamento, trazendo lucro para a empresa desenvolvedora e para o 
cliente que aproveita melhor o seu produto. 
 41 
REFERÊNCIAS 
ROCHA, Fabio Gomes. Introdução ao FDD - Feature Driven Development 
<http://www.devmedia.com.br/introducao-ao-fdd-feature-driven-development/27971> 
Acesso em 15/03/2014. 
 
CUNHA, C. R., FILIPAKIS, C. D. Proposta de Utilização de FDD e APF para 
Melhoria do Processo de Software. In: ENCONTRO DE COMPUTAÇÃO E 
INFORMÁTICA DO TOCANTINS, 14. 2012, Palmas. Anais... Palmas: 
CEULP/ULBRA, 2012. P. 142-151. 
Disponível em <http://ulbra-to.br/encoinfo/artigos/2012/Proposta_de_Utilizacao_de_ 
FDD_e_APF_para_Melhoria_do_Processo_de_Software.pdf.> Acesso dia 
15/03/2014 
 
LESSA, Rafael Orivaldo. Modelo de Processo de Engenharia de Software. UNISUL. 
Disponível em <http://inf.unisul.br/~pacheco/princ_eng_sw/02_Artigo.pdf> Acesso 
dia: 15/03/2014 
 
BERTHOLDO, Leonardo. Aplicação do Scrum ao modelo incremental. Disponível 
em: 
<http://www.ft.unicamp.br/liag/Gerenciamento/monografias/Monografia_ModeloIncre
mental_SCRUM.pdf> Acesso dia: 15/03/2014 
 
PRESSMAN, Roger. Engenharia de Software 9ª Edição. 
 
SOMMERVILE, Ian. Engenharia de Software 7ª Edição;