Características que influenciam na escolha de um modelo de processo de desenvolvimento de software analisadas quanto ao seu impacto nas atividades de gerenciamento de projeto

Prévia do material em texto

CARACTERÍSTICAS QUE INFLUENCIAM NA ESCOLHA DE UM MODELO DE 
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE ANALISADAS QUANTO AO 
SEU IMPACTO NAS ATIVIDADES DE GERENCIAMENTO DE PROJETO1 
Marco Antonio Santos Rocha de Sousa2 
Sérgio Piter Nogueira3 
 
 
RESUMO 
 
A escolha de um modelo de processo de desenvolvimento é parte do trabalho da equipe de gerenciamento do 
projeto e além de ter influência sobre o produto entregue, tem grande influência sobre os resultados do 
projeto e sobre a forma como o mesmo será executado. O objetivo deste trabalho é identificar as 
características, que devem ser levadas em consideração durante a escolha de um modelo de processo de 
desenvolvimento, com o intuito de evitar discordância entre as expectativas geradas pelos requisitos de 
projeto coletados e as contribuições que o modelo escolhido é capaz ou não é capaz de trazer para o projeto, 
através de uma análise voltada para o impacto destes modelos nas atividades de gerenciamento de projeto. 
 
Palavras-chave: Modelos de Processo de Desenvolvimento; Gerenciamento de Projetos. 
 
 
1 Modelo de artigo científico organizado pelo Núcleo de Normatização e Planejamento de Pesquisa da Faculdade 
Pitágoras. 2010. 
2Aluno(a) do Curso de Especialização em Gerenciamento de Projetos. Graduado(a) no curso Sistemas de informação. 
Atua profissionalmente como Gerente de Projetos. E-mail: mrochadesousa@gmail.com.br. 
3 Professor(a) Orientador(a), Especialista. Atua profissionalmente como coordenador de Pós Graduação na Faculdade 
Pitágoras de Uberlândia. E-mail: sergio.piter@kroton.com.br. 
 
 
2 
Sumário 
 
1. Introdução ................................................................................................................................................... 3 
2. Referencial Teórico .................................................................................................................................... 5 
2.1. Modelos de Processo de Desenvolvimento ................................................................................................ 5 
2.2. Relação entre Modelos de Processos de Desenvolvimento e Metodologia de Gerenciamento do Projetos 
do PMI ................................................................................................................................................................ 6 
2.3. Metodologia utilizada ................................................................................................................................. 7 
3. Principais modelos de Processo de desenvolvimento .............................................................................. 10 
3.1. Modelo Cascata ........................................................................................................................................ 10 
3.2. Modelo de processo Incremental e Modelos Evolucionários (Prototipação e Espiral) ............................ 13 
3.3. Scrum ....................................................................................................................................................... 18 
3.4. Características decisivas para a escolha de um modelo de processo de desenvolvimento de software ... 26 
4. Considerações Finais ................................................................................................................................ 31 
5. Referências ............................................................................................................................................... 32 
 
 
 
3 
1. Introdução 
 
O desenvolvimento de software evoluiu significativamente desde a invenção do computador pessoal, 
da internet e das redes sociais. Programas de computadores fazem parte de nossa vida de tal maneira que é 
difícil imaginar um ramo de atividade que não se utilize da capacidade destes programas na resolução de 
problemas cotidianos. 
Exatamente pela capacidade de resolver problemas cotidianos que os programas de computadores se 
popularizaram e cresceram tão rapidamente em volume e complexidade para atender os diversos modelos de 
negócio existentes, conforme Sommerville (2013) praticamente todos os países , hoje em dia, dependem de 
complexos sistemas. E se o software suporta modelos de negócio cada vez mais complexos, o processo para 
produção ou desenvolvimento deste software também passa a sê-lo, e passa a exigir profissionais cada vez 
mais especializados e o trabalho em grupo passou a ser uma regra. Desta maneira o desenvolvimento de 
software deixou de ser uma atividade individual para se tormar uma atividade social ou conforme Pressman 
(2009) “um processo de aprendizado social iterativo”. 
A maneira como esta atividade social é organizada para que não se torne caótica é chamada processo 
de software por Sommerville (2013) que o define como “conjunto de atividades e resultados associados que 
levam à produçãode um produto de software”. Mas as possibilidades de abordagem das atividades de 
construção de software são inúmeras, algumas destas abordagems já foram estruturadas, testadas, seus 
resultados foram análisados e hoje elas funcionam como modelos de processo de desenvolvimento de 
software. 
No âmbito do gerenciamento de projetos o modelo de processo de desenvolvimento de software 
adotado tem influência na disposição das atividades da equipe de desenvolvimento e afeta diretamente os 
requisitos de projeto, definidos por Mulcahy (2013) como “expectativas para como o projeto deveria ser 
inicalizado, planejado, executado, controlado e encerrado”, portanto por ter influência sobre todo o ciclo do 
projeto o modelo de processo de desenvolvimento adotado é extremamente relevante sob a ótica de 
gerenciamento de projetos. 
Este trabalho tem como objetivo analisar as características que influenciam na escolha de um modelo 
de processos de desenvolvimento com foco no impacto desta escolha para as atividades de gerenciamento de 
projeto, será realizado através de pesquisa bibliográfica e do estudo dos principais modelos de processo de 
desenvolvimento. Serão identificadas e analisadas as principais características destes modelos, e dos 
ambientes nos quais estão inseridos, que possam ser utilizados como crítérios para a sua seleção, visando o 
máximo de aproveitamento da capacidade que estes possuem em resolver problemas do cotidiano para o 
gerenciamento de projetos e desenvolvimento de software. 
No capítulo 2 é apresentado o referencial teórico utilizado no desenvolvimento do trabalho, as 
principais referencias e trabalhos anteriores utilizados como referência e como fonte para os fundamentos 
 
 
4 
teóricos deste trabalho são citados e discutivos neste capítulo. No capítulo 3 os fundamentos teóricos 
apresentados no capítulo 2 são utilizados para analisar os principais modelos de desenvolvimento de 
software escolhidos e com base nesta análise são apresentadas as características decisivas para a escolha de 
um modelo de desenvolvimento de software encontradas. O capítulo 4 são apresentadas as considerações 
finais do projeto. 
 
 
 
 
 
 
5 
2. Referencial Teórico 
 
Antes de estudar e analisar os principais modelos de processo de desenvolvimento teremos que 
definir o que é um modelo de processo, relacioná-lo com a metodologia de gerenciamento de projetos e 
definir uma metodologia para analisa-los. 
 
2.1. Modelos de Processo de Desenvolvimento 
 
O Processo de desenvolvimento de software segundo Pressman (2009) define a abordagem adotada 
conforme um software é elaborado pela engenharia, propicia estabilidade, controle e organização para uma 
atividade que pode, sem controle, tornar-se bastante caótica. É, segundo Baetjer (apud Pressman, 2009) umamaneira de controlar a interação entre usuários e projetistas, entre usuários e ferramentas em evolução e entre 
projetistas e ferramentas em evolução. 
Para estudar os modelos de processos de desenvolvimento Pressman (2009) agrupou conjuntos 
comuns de tarefas e ações de engenharia de software em atividades metodológicas, e definiu cinco atividades 
metodológicas genéricas: 
 Comunicação: Antes de iniciar é necessário comunicar-se e colaborar com o cliente com 
objetivo de fazer o levantamento das necessidades que ajudarão a definir as funções e 
características do software. Esta atividade metodológica compreende as atividades necessárias 
para o início do Projeto e levantamento das necessidades junto ao cliente; 
 Planejamento: Um projeto de software é tão complexo que precisa ser decomposto através de 
um plano de projeto de software que define como será realizado o trabalho de engenharia de 
software. Compreende a criação de estimativas, do cronograma do projeto e acompanhamento 
e atualização destes artefatos; 
 Modelagem: Compreende a análise e criação de modelos para que as necessidades do software 
sejam melhor compreendidas e a confecção de um projeto que levará ao cumprimento destas 
necessidades; 
 Construção: Atividade que combina geração de código e testes necessários para revelar erros 
na codificação; 
 Emprego: O software é entregue ao cliente, que avalia o produto entregue e fornece feedback. 
Compreende as atividades de entrega, suporte e feedback. 
 
 
 
6 
A definição destas cinco atividades metodológicas é uma generalização para melhor entendimento 
do processo de desenvolvimento, além destas atividades metodológicas existem atividades de apoio - 
controle e acompanhamento do andamento do projeto e suas entregas, administração de riscos, revisões 
técnicas, gerenciamento de configuração, preparo de artefatos, e etc - que em geral são aplicadas ao longo de 
todo o projeto, ajudando a equipe a gerenciar, controlar o progresso, a qualidade, as mudanças e o risco no 
projeto. 
Outro aspecto importante para a análise dos modelos de processo de desenvolvimento é o fluxo de 
processo, que descreve como as ações e tarefas de cada uma das atividades metodológicas são organizadas 
em relação à sequência e ao tempo. Os seguintes fluxos de processo foram listados por Pressman (2009): 
 Fluxo de processos linear: Executa cada uma das cinco atividades em sequência; 
 Fluxo de processos iterativo: Repete uma ou mais atividades antes de prosseguir para a 
atividade seguinte; 
 Fluxo de processos evolucionário: Executa as atividades de forma circular, cada vez que o 
processo passa pelas cinco atividades ele entrega uma versão mais completa do software; 
 Fluxo de processos paralelo: Executa uma ou mais atividades em paralelo com outras 
atividades. 
 
2.2. Relação entre Modelos de Processos de Desenvolvimento e Metodologia de Gerenciamento do 
Projetos do PMI 
 
O Project Management Institute (PMI, 2013) - organização sem fins lucrativos responsável por 
pesquisar, publicar e prover acreditação em gerenciamento de projetos - define gerenciamento de Projetos 
como “aplicação de conhecimentos, habilidades, ferramentas e técnicas às atividades de gerenciamento do 
projeto a fim de atender aos seus requisitos”, as atividades de gerenciamento citadas acima são detalhadas 
pelo PMI como processos agrupados em uma matriz com um eixo de 5 grupos de processos (iniciação, 
planejamento, execução, monitoramento e controle, e encerramento) e outro eixo de 10 áreas de 
conhecimento (integração, escopo, tempo, custo, qualidade, recursos humanos, comunicações, riscos, 
aquisições e partes interessadas). 
 Enquanto o PMI (2013) afirma que o gerenciamento de projetos trata da aplicação de habilidades, 
ferramentas e técnicas em um âmbito gerencial identificando processos necessários para a boa execução de 
projetos, sem listar atividades específicas necessárias para obtenção do software, Sommerville (2013) afirma 
que um modelo de processo de desenvolvimento “é uma representação abstrata de um processo de software” 
e trata da definição de atividades, ações e tarefas necessárias para desenvolvê-lo. O escopo de trabalho de 
 
 
7 
cada uma das metodologias (gerenciamento de projetos e modelo de processo de desenvolvimento) é 
independente, mas isto não significa que não exista relação entre elas. 
De uma forma simplista, podemos afirmar que a metodologia de gerenciamento de projetos nos dita 
o que precisa ser feito enquanto o modelo de processo de desenvolvimento nos orienta sobre como e quando 
cada uma das atividades deve acontecer. 
 
 
Figura 1 - Camadas da engenharia de software. Fonte: Pressman (2009) 
 
 Pressman (2009) definiu a engenharia de software como uma tecnologia em camadas (representada 
pela Figura 1) fundamentada em um comprometimento organizacional com a qualidade, que se encontra na 
base da pirâmide. Acima desta camada está a camada de camada de processos que é responsável por manter 
as demais camadas coesas e constitui a base para o controle do gerenciamento de projetos, principal ponto de 
atuação da metodologia de gerenciamento de projetos. O modelo de desenvolvimento de software escolhido 
exerce forte influência sobre a camada seguinte: a camada de métodos, que é responsável por fornecer 
informações técnicas sobre os métodos utilizados durante a realização em atividades específicas do processo 
de desenvolvimento de software. 
 
2.3. Metodologia utilizada 
 
Para identificar as características decisivas na escolha de um modelo de processo de 
desenvolvimento temos que definir sob qual perspectiva iremos analisar os modelos escolhidos. Um ponto de 
partida é analisa-los através da própria definição de modelo de processo de desenvolvimento dada por 
Pressman (2009): 
 
 
 
 
 
 
8 
 Definições e ênfases dadas a cada uma das cindo atividades metodológicas: 
o Comunicação; 
o Planejamento; 
o Modelagem; 
o Construção; 
o Emprego; 
 Definições ligadas aos fluxos de processos característicos do modelo de processo de 
desenvolvimento em questão; 
Como o objetivo deste trabalho é identificar características decisivas durante a escolha de um 
modelo de processo de desenvolvimento para que este influencie positivamente as práticas de gerenciamento 
de projeto, nada mais justo que analisarmos cada um dos modelos quanto ao impacto das definições destes 
modelos em áreas definidas pela Metodologia de Gerenciamento de Projetos: 
 Itens relacionados aos requisitos de Projeto (impactos em cada uma das 10 áreas de 
conhecimento) e suas definições de acordo com PMI (2013): 
o Integração: processos e atividades para identificar, definir, combinar, unificar e 
coordenar os vários processos e atividades dentro dos grupos de processos de 
gerenciamento do projeto; 
o Escopo: processos necessários para assegurar que o projeto inclui todo o trabalho 
necessário; 
o Tempo: processos necessários para gerenciar o término pontual do projeto; 
o Custos: processos envolvidos em planejamento, estimativas, orçamentos, 
financiamentos, gerenciamento e controle dos custos; 
o Qualidade: processos e atividades que determinam as políticas de qualidade, 
objetivos e responsabilidades, para que as necessidades sejam atendidas; 
o Recursos humanos: processos que organizam, gerenciam e guiam a equipe do 
projeto; 
o Comunicações: processos necessários para assegurar que as informações sejam 
planejadas, coletadas, criadas, distribuídas, armazenadas, recuperadas, gerenciadas, 
controladas, monitoradas e dispostas de maneira oportuna e apropriada; 
o Riscos: processos de planejamento, identificação, análise, planejamento de respostas 
e controlede riscos de um projeto; 
o Aquisições: processos necessários para comprar ou adquirir produtos, serviços ou 
resultados externos à equipe do projeto; 
 
 
9 
o Partes Interessadas: processos exigidos para identificar as pessoas, grupos ou 
organizações que podem impactar ou serem impactados pelo projeto; 
 Itens relacionados os requisitos do Produto (requisitos funcionais e não funcionais do 
produto); 
 Características relacionadas aos Fatores Ambientais da Empresa ou condições que não estão 
sob controle imediato da equipe e que influenciam, restringem ou direcionam o projeto; 
 Fatores ambientais do Cliente ou condições que estão relacionados ao ambiente no qual o 
cliente está inserido, mas não estão sob controle imediato do mesmo e também influenciam, 
restringem ou direcionam o projeto; 
 Características relacionadas aos Ativos de Processos Organizacionais: Planos, processos, 
políticas, procedimentos e bases de conhecimento específicas usadas pela organização 
executora; 
 
 
 
10 
3. Principais modelos de Processo de desenvolvimento 
 
A seguir trataremos dos principais modelos de processo de desenvolvimento de software fazendo uso 
do embasamento teórico levantado no capítulo anterior que contempla as definições e características de 
modelo de processo de desenvolvimento e das áreas de conhecimento definidas pelo PMI. 
Serão explorados e analisados os modelos de processo prescritivos, como modelo cascata, modelos 
de processo incremental e evolucionários, como prototipação e espiral, além do Scrum, modelo de processo 
baseado em processos ágeis. 
 
3.1. Modelo Cascata 
 
O modelo cascata, em inglês Watterfall Model é o mais comum e mais utilizado modelo de 
desenvolvimento de software de acordo com Hirama (2012). É também definido por ele como “Um conjunto 
de fases em sequência, nas quais o trabalho anterior deve estar finalizado e verificado antes de se iniciar a 
próxima fase”, portanto caracteriza-se principalmente pelo seu fluxo de processos linear, conforme Figura 2. 
 
 
Figura 2 - Representação do modelo cascata. Fonte: Pressman (2009) 
 
Este modelo é indicado para projetos em que os problemas são bem compreendidos e documentados 
pois sugere uma abordagem sequencial e sistemática para o desenvolvimento de software. 
Os modelos sequenciais, como o modelo cascata, sugerem um fluxo de processos lineares que 
frequentemente é inadequado para considerar características dos sistemas modernos. Entretanto, eles têm 
aplicabilidade em situações em que os requisitos são bem definidos e estáveis. 
As características abaixo relatadas através da análise deste modelo são tendências observadas através 
da análise deste modelo e não devem ser tratadas como premissas ou saídas obrigatórias de projetos que 
utilizam este modelo: 
 
 
 
11 
 Atividades metodológicas: 
o Ênfase nas atividades metodológicas executadas no início do projeto: Comunicação, 
Planejamento e Modelagem, pois se espera que não seja necessário realizar 
mudanças no plano de projeto e modelo construído e que estes possibilitem à fase de 
construção o atendimento dos requisitos; 
 Fluxo de Processo: 
o Linear; 
 Requisitos de Projeto em cada uma das áreas: 
o Gerenciamento da integração: 
 Deve ser disponibilizado quantidade significativa de tempo para as fases 
iniciais do projeto responsáveis pela definição de escopo, plano de projeto e 
modelagem (comunicação, planejamento e modelagem), pois há pouca 
flexibilidade para alterações no plano de projeto e modelos definidos; 
 Mudanças de escopo são tratadas como exceções à regra, o padrão é que não 
haja mudanças; 
 A rigidez no cumprimento dos processos pode fazer com que atividades 
sejam bloqueadas por que as suas predecessoras ainda não foram realizadas. 
o Gerenciamento do escopo: 
 Devido à complexidade ou à quantidade excessiva de requisitos o cliente 
pode ter dificuldades de identificar e detalhar cada um deles no início do 
projeto; 
o Gerenciamento do tempo: 
 Com escopo e período pré-definidos nas fazes anteriores do projeto há 
previsibilidade do ritmo de trabalho necessário para que a data final do 
projeto seja atingida; 
o Gerenciamento de custos: 
 Desconsideradas as possíveis mudanças de escopo e os riscos do projeto, 
podemos afirmar que há previsibilidade de custos a longo prazo; 
 
 
 
 
 
 
12 
o Gerenciamento da qualidade: 
 A qualidade do software entregue está diretamente ligada à completude dos 
requisitos expressados pelo cliente e ao correto entendimento destes pela 
equipe de desenvolvimento. Contudo, a percepção do cliente quanto a estes 
requisitos pode mudar conforme o projeto é desenvolvido, neste caso a 
qualidade percebida pelo cliente será comprometida; 
o Gerenciamento de recursos Humanos: 
 Cada uma das atividades metodológicas exige que um perfil de profissional 
seja alocado ao projeto, a equipe do projeto muda sempre que novas 
atividades forem iniciadas; 
o Gerenciamento das Comunicações: 
 As comunicações tendem a ser realizadas pelas vias formais, sempre bem 
documentadas; 
o Gerenciamento dos Riscos: 
 Os riscos não são compartilhados de forma equitativa entre o cliente, 
patrocinador e o executor do projeto, a forma de contratação geralmente é 
por escopo fechado e o custo cobrado pelo executor do projeto costuma 
incluir o aceite do risco da implementação dos requisitos seja mais 
complexa e ter maior custo que o previsto; 
o Gerenciamento das Aquisições: 
 A terceirização à distância se torna uma possibilidade factível, escopo fixo e 
pouca necessidade de comunicação com o cliente favorecem para que isso 
ocorra; 
o Gerenciamento das Partes interessadas: 
 É de interesse do cliente que o não haja mudanças, pois as mesmas 
costumam impactar no custo do projeto, e é de interesse do fornecedor que 
todas as alterações, por menores que sejam, sejam tratadas como mudanças, 
para que ele não precise absorver escopo não contemplado. Os interesses de 
ambas as partes se mal administrados podem ser fonte de problemas para a 
relação entre o cliente e a equipes do projeto; 
 
 
 
 
 
13 
 
 Requisitos de Produto: 
o A ênfase nas atividades metodológicas iniciais favorece a criação de softwares com 
arquitetura escalável e reutilizável, pois espera-se que seja determinado tempo 
exclusivo e suficiente para a realização estas atividades e que as próximas atividades 
sejam iniciadas apenas após sua conclusão; 
o Versão operacional do produto só estará disponível ao final do projeto; 
 Fatores ambientais do cliente: 
o Ambiente de negócios estável e previsível são fatores que contribuem 
favoravelmente para o sucesso de projetos que utilizam este modelo; 
o Exige pouca interação do fornecedor com o cliente e essa interação acontece em 
fases específicas e pré-determinadas do ciclo de vida do projeto; 
o A previsibilidade de custos e prazos a longo é alcançada devido ao escopo do projeto 
e as atividades necessárias para o cumprimento deste escopo serem definidas nas 
fases iniciais do projeto; 
 Fatores ambientais da empresa: 
o Cultura focada em atender ao processo: realização mandatória de todas as atividades 
listadas mesmo que estas não agreguem valor ao produto final; 
o Há previsibilidade de uso dos recursos a longo prazo: com escopo, prazo, custo e 
qualidade definidos no início do projeto, há facilidade em determinar quais recursos 
serão necessários do início ao fim do projeto; 
 Ativos de Processos Organizacionais 
o Conhecimento prévio dos processos de negócio do cliente é um ativo importante 
para que o fornecedor possa avaliar os riscos do projeto; 
 
3.2.Modelo de processo Incremental e Modelos Evolucionários (Prototipação e Espiral) 
 
Os modelos de processos não se restringem à utilização de apenas um fluxo de processos, muitas 
vezes eles combinam fluxos de processos para obter resultados que não seriam possíveis quando utilizado 
apenas um fluxo. Um exemplo é o Modelo Incremental que conforme Pressman (2009) “combina elementos 
dos fluxos de processos lineares e paralelos [...], aplica sequencias lineares, de forma escalonada, à medida 
 
 
14 
que o tempo vai avançando”. Na Figura 3 podemos observar que as atividades metodológicas se repetem n 
vezes, no qual n representa a quantidade de incrementos de software entregues ao cliente. 
 
 
Figura 3 - Representação do modelo incremental. Fonte: Pressman (2009) 
 
A escolha deste modelo acontece geralmente quando é necessário obter parte funcional do software 
antes da conclusão do projeto ou quando é possível obter apenas parte dos requisitos antes do início do 
mesmo. 
Modelos de processos evolucionários, tem como sua principal característica a utilização de um fluxo 
de processos evolucionário, muito parecido com o fluxo incremental, mas com uma sutil diferença. No fluxo 
incremental cada incremento de software pode ser tratado como uma entrega que comtempla um conjunto 
diferente de funcionalidades expressas através de novos requisitos, enquanto para os modelos que seguem o 
processo evolucionário, as iterações são tratadas como uma forma de refinar as funcionalidades existentes. 
Entre os principais modelos evolucionários temos a prototipação e o modelo espiral. A Prototipação 
é frequentemente utilizada quando o cliente define uma série de objetivos gerais para o software, mas não 
identifica detalhadamente os requisitos para as funções e recursos do mesmo, ou em outros casos quando há 
insegurança quanto à implementação de um algoritmo, utilização de um componente, quanto à interação com 
um sistema externo ou até mesmo quanto à interface ou à forma de interação homem/máquina. 
De acordo com Pressman (2009) o paradigma da prototipação, ilustrado na Figura 4, começa com a 
comunicação, fase em que os requisitos são minimamente identificados. Em seguida uma iteração de 
prototipação é planejada rapidamente e resulta na criação de um projeto rápido e modelagem do protótipo 
que será construído e apresentado. Como resultado do projeto rápido temos a disponibilização de um 
 
 
15 
protótipo que será testado e apresentado ao cliente, que expressará sua impressão e os comentários do cliente 
auxiliarão os integrantes da equipe no detalhamento e validação dos requisitos que serão insumo para uma 
nova iteração. 
 
 
Figura 4 - Representação do paradigma da prototipação. Fonte: Pressman (2009) 
 
O ciclo de vida do modelo de processo de prototipação pode ser executado e repetido até que o 
cliente obtenha um produto pronto ou a prototipação pode ser utilizada como uma técnica implementada no 
contexto de qualquer um dos outros modelos com objetivo de auxiliar os interessados na melhor 
compreensão do que está para ser construído. 
Outro modelo de processo de software que também utiliza fluxo de processos evolucionário, mas que 
no entanto adiciona a aspectos sistemáticos e controlados do modelo cascata, é o modelo de processo em 
espiral. Segundo Boehn apud Pressman (2009): 
“[O modelo espiral] possui duas características principais que o distinguem. A primeira consiste em 
uma abordagem cíclica, voltada para ampliar, incrementalmente, o grau de definição e a 
implementação de um sistema, enquanto diminui o grau de risco do mesmo. A segunda característica 
consiste em uma série de pontos âncora de controle para assegurar o comprometimento de 
interessados quanto à busca de soluções de sistema que sejam mutuamente satisfatórias e praticáveis.” 
Tanto a característica cíclica quanto os pontos âncora citados por Boehn podem ser observados 
Figura 5 que representa o modelo espiral. Ao unir as principais características do modelo cascata e 
prototipação obtemos um modelo que além de fornecer organização, através de um processo com 
 
 
16 
características lineares, também fornece a capacidade de refinamento e averiguação dos requisitos, típico de 
um processo cíclico baseado em prototipação. 
 
Figura 5 - Representação modelo espiral. Fonte: Pressman (2009) 
 
O maior ponto em comum entre o modelo de processo incremental e os modelos evolucionários 
(prototipação e espiral), é a possibilidade de realização de entregas parciais e o fato da opinião do cliente 
sobre o sistema que está sendo desenvolvido ser ouvida antes da entrega final do projeto, guiando a equipe 
na identificação de melhorias e refinamentos tanto no processo de desenvolvimento quanto nos requisitos do 
produto que será entregue. Por este motivo eles serão analisados em conjunto: 
 
 Atividades metodológicas: 
o Maior ênfase nas atividades de comunicação construção e emprego, o foco é 
apresentar ao cliente partes funcionais do software para que através do feedback dele 
o produto entregue em um novo ciclo ou iteração seja ajustado; 
 Fluxo de Processo: 
o Iterativo ou evolucionário. Ambos possibilitam que o processo seja alterado e 
adaptado para a próxima iteração/ciclo, com a diferença de que em um ciclo 
evolucionário os requisitos de uma mesma funcionalidade também podem ser 
alterados e adaptados, enquanto que em um ciclo iterativo, cada iteração trabalha em 
um conjunto de funcionalidades diferentes; 
 
 
 
17 
 Requisitos de Projeto em cada uma das áreas: 
o Gerenciamento da integração: 
 O plano de projeto é parcialmente flexível, as mudanças são bem vindas mas 
geralmente só serão implantadas a partir do novo ciclo/iteração; 
 Para que as mudanças e refinamento dos requisitos sejam controlados e 
implantados com eficiência a cada ciclo/iteração é indicada a utilização de 
uma ferramenta para gestão dos requisitos e conhecimento obtido nos feed-
backs; 
o Gerenciamento do escopo: 
 A identificação detalhada dos requisitos ocorre de forma contínua durante 
todo o projeto, favorecendo a completude dos mesmos; 
 No início do projeto o escopo não é completamente previsível, mudanças 
poderão e deverão acontecer e ao final o resultado pode ser um produto 
diferente do imaginado no início do projeto; 
o Gerenciamento do tempo: 
 Geralmente não se consegue prever com exatidão a data de conclusão do 
projeto, mas existe controle das datas marco das iterações/ciclos em 
execução; 
o Gerenciamento de custos: 
 Os custos das iterações/ciclos em execução são controlados e previsíveis, 
assim como suas datas marco, há previsibilidade de custos a curto e médio 
prazo; 
o Gerenciamento da qualidade: 
 A qualidade do produto é aprimorada conforme as iterações/ciclos são 
concluídas, e conta com a contribuição do cliente; 
o Gerenciamento de recursos Humanos: 
 As atividades metodológicas serão novamente executadas a cada 
ciclo/iteração, desta maneira a maioria dos perfis profissionais serão 
necessários até o fim do projeto; 
o Gerenciamento das Comunicações: 
 Além das comunicações formais oficiais as comunicações informais ou até 
não-verbais são de grande relevância para o projeto, principalmente durante 
as revisões realizadas pelo cliente; 
 
 
18 
 Requisitos de Produto: 
o Favorece a evolução contínua do software a cada iteração/ciclo entregue; 
 Fatores ambientais do cliente: 
o Em um ambiente de negócios em constante mudança ou quando há urgência no 
atendimento de requisitos novos e pontais estes modelos são atrativos pois existe a 
possiblidade de mudança de requisitos a cada iteração/ciclo e atendimento 
relativamente rápido destasnecessidades; 
 Fatores ambientais da empresa: 
o Os modelos Incremental e Espiral estão relacionados à uma cultura organizacional 
equilibrada, que apesar de entender a necessidade de cumprimento de processos, 
também se preocupa com o atendimento das necessidades do cliente; 
o O modelo de prototipação é favorecido quando utilizado em uma cultura em que o 
atendimento às necessidades do cliente é mais importante que o atendimento aos 
processos; 
 
3.3. Scrum 
 
Como exemplo de modelo de processo de desenvolvimento ágil analisaremos o modelo Scrum, 
principal representante dos Métodos ágeis. 
Em um ambiente computacional moderno, que se presta a atender processos de negócio dinâmicos 
que exigem constantes mudanças, é praticamente impossível prever como o mesmo irá evoluir a longo prazo. 
Nem sempre é possível especificar com completude os requisitos detalhados do sistema antes que o projeto 
se inicie, e para construir software para estes ambientes é necessário que o modelo de processo adotado 
propicie que as entregas sejam realizadas com agilidade e que mudanças sejam tratadas como parte do 
processo e não exceção à regra. 
No entanto, o grande problema com as mudanças é que em num ambiente em que se espera que haja 
relativa organização e precisão nas estimativas a longo prazo elas tem um custo elevado. O que se pretende 
com processos ágeis em relação ao custo do projeto, exemplificado na Figura 6, é que parte dos custos com 
mudanças sejam absorvidos no início do projeto e que o projeto seja realinhado às expectativas dos clientes 
para que mudanças maiores não sejam necessárias nas fases finais do projeto. 
 
 
 
19 
 
 Figura 6 - Comportamento do custo de desenvolvimento quando relacionado ao progresso do cronograma para diversos 
processos. Fonte: Pressman (2009) 
 
 Os modelos de processo prescritivos têm uma falha essencial, eles não levam em consideração as 
fragilidades das pessoas que especificam, modelam, projetam e desenvolvem o software. Cockburn (apud 
Pressman, 2009) afirma que podemos "Lidar com as fraquezas comuns das pessoas com disciplina e/ou 
tolerância [os modelos de processos prescritivos optam por disciplina.] Como a consistência nas ações é uma 
fraqueza humana, as metodologias com disciplina elevada são frágeis". Para que funcionem, os modelos de 
processos devem fornecer um mecanismo realista que estimule a disciplina necessária ou, então, devem ter 
características que apresentem tolerância com os desvios nos processos e com as falhas e incompletudes dos 
requisitos, deslizes que comumente são cometidos pelas pessoas que realizam trabalhos de engenharia de 
software ou que estão presentes de alguma forma no processo de desenvolvimento de software. 
 Invariavelmente, práticas tolerantes são mais facilmente adotadas e sustentadas pelas pessoas 
envolvidas, porém podem ser menos produtivas. Agilidade consiste em algo mais que uma resposta positiva 
à mudança, ela incentiva a estruturação e as atitudes em equipe que tornam a comunicação mais fácil entre os 
seus integrantes, e não apenas entre os membros da equipe de desenvolvimento, mas também entre todas as 
partes interessadas do projeto, incluindo cliente, patrocinador, equipe comercial, gerentes funcionais, etc. 
 Esta mudança de atitude reforça a importância do cliente como parte integrante da equipe do projeto, 
importância desestimulada devido à árdua negociação diante das mudanças que não são facilmente aceitas 
quando utilizamos processos prescritivos. Entregas rápidas e operacionais são priorizadas e artefatos 
intermediários de modelagem e projeto tem menor importância, já que na perspectiva ágil reconhecemos que 
o planejamento, em um mundo incerto, tem seus limites e que o plano deve ser flexível. 
As metodologias ágeis têm como fim a criação de um modelo que seja capaz de administrar a 
imprevisibilidade, através de processos que permitem que o projeto e as condições técnicas do mesmo sejam 
 
 
20 
alterados rapidamente. Mas essa flexibilidade e adaptação contínua podem não ser sinônimo de progresso, 
sem controle as mudanças podem minar o avanço do desenvolvimento. Por este motivo a adoção de 
metodologias ágeis não necessariamente significa que o cliente irá ditar o ritmo do desenvolvimento do 
projeto sem controle algum por parte da equipe de gerenciamento. 
O Scrum é um dos principais modelos de processos de desenvolvimento na categoria modelos de 
processos ágeis. Segundo Pressman (2009) foi concebido por Jeff Sutherland e sua equipe nos anos 90 e 
aprimorado por Shwaber e Beedle. Os princípios do Scrum estão em concordância com o Manifesto Ágil 
publicado por Beedle et al (2001): 
 Garantir a satisfação do cliente entregando rapidamente e continuamente softwares 
funcionais; 
 Softwares funcionais são entregues frequentemente (semanas, ao invés de meses); 
 Softwares funcionais são a principal medida de progresso do projeto; 
 Até mesmo mudanças tardias de escopo no projeto são bem-vindas. 
 Cooperação constante entre pessoas que entendem do 'negócio' e desenvolvedores; 
 Projetos surgem através de indivíduos motivados, e que deve existir uma relação de 
confiança. 
 Design do software deve prezar pela excelência técnica; 
 Simplicidade; 
 Rápida adaptação às mudanças; 
 Indivíduos e interações mais do que processos e ferramentas; 
 Software funcional mais do que documentação extensa; 
 Colaboração com clientes mais do que negociação de contratos; 
 Responder a mudanças mais do que seguir um plano. 
 
O modelo enfatiza um conjunto de papéis, práticas e artefatos que juntos provaram ser eficazes para 
projetos com prazos de entregas apertados, requisitos mutáveis e críticos de negócio e conforme 
SCHWABER e SUTHERLAND (2013) os principais papéis definidos pelo Scrum para o desenvolvimento 
de software são: 
 Product Owner (dono do produto): é o dono do produto, é responsável por gerenciar o 
registro de itens pendentes de trabalho (Backlog) do produto; 
 Time de desenvolvimento: é o grupo de profissionais que realizam o trabalho com objetivo 
de entregar uma versão utilizável do produto ao cliente. Devem ser auto organizáveis, 
multifuncionais, podem ter habilidades especializadas, mas devem reconhecer que a 
responsabilidade pelo que está sendo desenvolvido é do time como um todo; 
 Scrum Master: é responsável por garantir que o Scrum seja entendido e aplicado, é 
responsável por conduzir as reuniões diárias e direcionar minimamente a equipe; 
 
 
 
21 
Estas são as práticas, ou eventos, definidos pelo Scrum: 
 Sprints (Corridas de curtas distancias): são unidades de trabalho com tempo pré-definido, 
geralmente curto, entre 15 a 30 dias, com o objetivo de atender a uma quantidade de 
requisitos ou funcionalidades selecionadas anteriormente; 
 Reunião de detalhamento do Backlog: Reunião onde os itens de trabalho pendentes são 
priorizados e melhor detalhados, é realizada antes do planejamento e execução da Sprint; 
 Reunião de planejamento da Sprint: É uma reunião de no máximo 8 horas, que acontece com 
a participação de toda a equipe e tem como objetivo criar um plano que define os objetivos e 
entregas do Sprint; 
 Reuniões Diárias: São reuniões curtas (de tipicamente 15 minutos), realizadas diariamente 
pela equipe Scrum. A equipe deve ser auto gerenciável, mas, para guiar a execução e 
organização das atividades, nestas reuniões são feitas três perguntas a todos os integrantes da 
equipe: 
o O que foi realizado no dia anterior? 
o Quais os problemas encontrados? 
o O que se planeja realizar no dia de hoje? 
 Revisão da Sprint: É uma reunião de no máximo 4 horas realizada ao final da Sprint para 
inspecionar o incremento e atualizaro Backlog do Produto. 
Além de papéis e práticas, o Scrum recomenda a utilização de uma série de artefatos: 
 Backlog do Produto (Registro itens pendentes de trabalho): lista utilizada para identificar e 
priorizar os requisitos ou funcionalidades que fornecem valor comercial ao cliente. 
Alterações são aceitas mas devem ser realizadas no Backlog do produto orientando os 
próximos Sprints; 
 Backlog da Sprint: representa um conjunto de itens do Backlog do produto selecionados para 
a Sprint atual. Os Sprints que já estão em andamento não podem sofrer alterações, isso 
permite que os membros da equipe trabalhem em um ambiente minimamente controlável; 
 User Stories: Descrições refinadas dos itens do Backlog do produto, colhidas na reunião de 
detalhamento do Backlog, que guiam o time durante a execução da Sprint; 
 
 
 
22 
 
Figura 7 - Representação do Scrum. Fonte: Pressman (2009) 
 
A Figura 7 representa os principais aspectos do Scrum e sua abordagem iterativa e incremental, que 
possibilita o aperfeiçoamento continuo dos requisitos e das práticas de desenvolvimento. A repriorização e 
descarte de itens de Backlog que acontece a cada Sprint, faz com que o produto propicie máximo valor ao 
negócio. 
Seguem abaixo as características observadas para o Scrum: 
 Atividades metodológicas: 
o Foco nas atividades metodológicas de comunicação, construção e emprego, com 
objetivo de realizar entregas funcionais e colher o feed-back do cliente. As 
atividades de planejamento e modelagem não são negligenciadas, mas não há a 
preocupação em planejar todo o projeto e construir o modelo completo do sistema 
antes do seu desenvolvimento, o foco do planejamento e modelagem está voltado 
apenas para o sprint atual. 
 Fluxo de Processo: 
o Iterativo e evolucionário, lições aprendidas de cada um dos sprints devem ser 
comunicadas e utilizadas nos próximos sprints; 
 
 
 
 
 
 
23 
 Requisitos de Projeto em cada uma das áreas: 
o Gerenciamento da integração: 
 Quando comparado com modelo cascata pouco tempo é disponibilizado para 
as atividades de planejamento e modelagem que frequentemente são 
realizadas em paralelo com a atividade de construção; 
 O progresso é monitorado e verificado através das funcionalidades 
entregues, elas são as medidas de progresso; 
 Custo da mudança se mantem estável ou cresce muito pouco conforme o 
projeto evolui; 
o Gerenciamento do escopo: 
 Existe identificação e detalhamento contínuo de requisitos durante todo o 
projeto e isso abre precedente para uma série de possibilidades: o cliente 
pode abrir mão de requisitos não prioritários, pode repriorizar os requisitos, 
os usuários tem tempo para analisar, experimentar e tomar decisões sobre os 
requisitos já que eles são refinados com o tempo; 
 Como o escopo está constantemente sendo definido e refinado é difícil 
manter uma documentação completa e atualizada do mesmo, além disso não 
há previsibilidade do escopo do projeto como um todo; 
o Gerenciamento do tempo: 
 O cronograma é controlado através das funcionalidades entregues em cada 
uma das iterações, mas são controladas apenas entregas de curto prazo, 
geralmente associadas ao sprint atual ou aos próximo sprints; 
o Gerenciamento de custos: 
 Assim como o escopo é refinado com o tempo, os custos também são 
refinados com o tempo quando a metodologia Scrum é utilizada, a 
flexibilização do escopo acaba sendo refletiva na flexibilização dos custos. 
O que não significa que não há controle sobre os custos, cliente e fornecedor 
devem adotar uma medida de produtividade para que a remuneração seja 
realizada através dela, não é aconselhado que a remuneração seja realizada 
sobre as horas trabalhadas, que podem variar, mas sim sobre as 
funcionalidades entregues; 
 
 
 
 
 
24 
o Gerenciamento da qualidade: 
 O cliente participa ativamente do processo de desenvolvimento através do 
seu representante. Possíveis dúvidas sobre o entendimento dos requisitos são 
sanadas durante o próprio processo de desenvolvimento e o cliente também 
tem a possibilidade de realizar validações parciais, isto favorece para a 
melhoria da quantidade do produto final do que diz respeito à satisfação do 
cliente; 
o Gerenciamento de recursos Humanos: 
 Como as atividades metodológicas são realizadas de forma cíclica durante 
toda a duração do projeto, não existe a necessidade de 
mobilização/desmobilização dos recursos humanos sempre que uma 
atividade é concluída; 
o Gerenciamento das Comunicações: 
 As comunicações formais ainda estão presentes, mas existem uma tendência 
de valorização das comunicações informais e diretas, pois a presença 
constante do cliente ou de seus representantes favorece este tipo de 
comunicação; 
o Gerenciamento dos Riscos: 
 Os riscos são distribuídos de forma equitativa entre o cliente, patrocinador e 
executor do projeto, a forma de contratação geralmente é por entrega. 
Detalhamentos não presentes nos levantamentos iniciais não geram custo 
extra ou geram pouco custo extra, pois são identificados ainda durante o 
desenvolvimento. Há flexibilidade de inclusão ou remoção de novos 
requisitos que geralmente são admitidos apenas nos próximos Sprints que 
refletirão as próximas entregas. 
o Gerenciamento das Aquisições: 
 A grande necessidade de comunicação com o cliente, flexibilidade de escopo 
e valorização da comunicação direta e presencial com o cliente trazem 
obstáculos para a terceirização à distância; 
o Gerenciamento das Partes interessadas: 
 Cliente e executor do projeto tendem a se relacionar melhor, pois as 
responsabilidades sobre as mudanças de escopo e melhorias são 
compartilhadas entre as partes, gerir as partes interessadas se torna uma 
tarefa menos desgastante; 
 
 
25 
 Requisitos de Produto: 
o A ênfase nas atividades metodológicas de comunicação, construção e emprego 
favorece a criação de softwares de maneira ágil e com melhor aderência às 
necessidades do cliente e aos ambientes de negócio que exigem mudanças 
constantes dos requisitos; 
o Versões operacionais intermediárias funcionais do produto são disponibilizadas 
periodicamente durante o processo de desenvolvimento; 
 Fatores ambientais do cliente: 
o Ambientes de negócios que exigem adaptações constantes nos requisitos e urgência 
em atender estas mudanças são atendidos com facilidade por este modelo de 
processo de desenvolvimento; 
o Acesso direto e irrestrito ao cliente é essencial para o sucesso na adoção deste 
modelo; 
o Quando há necessidade de que os custos totais do projeto sejam 100% previsíveis 
este modelo não é recomendado; 
 Fatores ambientais da empresa: 
o Cultura focada em atender à necessidade do cliente: foco em atividades que 
realmente agreguem valor ao produto final; 
o Melhorias são bem vindas, mudanças são tratadas como comportamento padrão para 
o refinamento e repriorização dos requisitos que realmente trarão valor para o 
software; 
o Valorização do atendimento imediato em detrimento do planejamento de capacidade 
e previsibilidade de uso dos recursos a longo prazo: o escopo, prazo e custo do 
projeto é melhor definido durante a execução do projeto. 
 Ativos de Processos Organizacionais: 
o Políticas que favoreçam à adaptação dos processos ao comportamento das pessoas, e 
não o inverso, são fatores positivos à adoção deste modelo; 
 
 
 
 
 
 
26 
3.4. Características decisivas para a escolha de um modelo de processo de desenvolvimento de 
software 
 
Durante a análise dos modelos de processo de desenvolvimento, utilizando as metodologias 
propostas que incluem análise da importânciade cada uma das cinco atividades metodológicas para os 
modelos de processo e do fluxo de processos utilizado em cada modelo, além da análise do impacto do 
modelo em cada uma das 10 áreas de conhecimento da metodologia de Gerenciamento de Projetos definida 
pelo PMI, identificamos uma série características relevantes para a escolha de um modelo de processo de 
desenvolvimento. 
As características elencadas estão relacionadas ao projeto, aos fatores ambientais do cliente ou aos 
ativos e fatores ambientais da organização responsável pelo desenvolvimento. Cada uma das características 
quando analisadas podem indicar maior ou menor aderência a um dos modelos analisados e juntas elas 
podem auxiliar a equipe de gerenciamento do projeto na escolha de um modelo de processo de 
desenvolvimento adequado à realidade dos envolvidos. 
Seguem características identificadas e a indicação do modelo que tem melhor alinhamento com a 
atividade descrita: 
1) Ênfase em cada uma das 5 atividades metodológicas: 
Foco nas atividades iniciais Planejamento e Modelagem ou nas atividades finais Construção 
e Emprego? 
 Foco nas atividades iniciais: Cascata; 
 Foco equilibrado: Incremental ou evolucionário; 
 Foco nas atividades finais – Métodos ágeis; 
2) Fluxo de Processos; 
O fluxo de processos é linear ou iterativo e evolucionário? 
 Fluxo de processos linear: Cascata; 
 Fluxo de processos iterativo ou evolucionário: Incremental ou evolucionário; 
 Fluxo de processos iterativo e evolucionário: Métodos ágeis; 
 
 
 
 
 
 
 
 
 
27 
3) Requisitos de Projeto em cada uma das áreas de conhecimento do gerenciamento de projetos: 
 3.1) Integração: 
Durante o projeto há a necessidade de alterações no plano de projeto? 
 Sim: Métodos ágeis; 
 Não é possível determinar: Incremental ou evolucionário; 
 Não: Cascata; 
Durante o projeto mudanças de escopo serão necessárias? 
 Sim: Métodos ágeis; 
 Não é possível determinar: Incremental ou evolucionário; 
 Não: Cascata; 
Há flexibilidade no cumprimento dos processos? Processos rígidos são necessários? 
Processos flexíveis são viáveis? 
 Sim, há flexibilidade: Métodos ágeis; 
 Há flexibilidade com restrições: Incremental ou evolucionário; 
 Não há flexibilidade: Cascata; 
Planejamento e modelagem podem ser realizados paralelamente à construção? 
 Sim: Métodos ágeis; 
 Há a possibilidade de paralelismo com restrições: Incremental ou 
evolucionário; 
 Não: Cascata; 
3.2) Escopo: 
O cliente consegue definir o escopo com completude no início do projeto? Ou é 
preferível que o escopo seja detalhado no decorrer do projeto? 
 Sim, o escopo será definido com completude antes do início do projeto: 
Cascata; 
 Escopo parcialmente definido: Incremental ou evolucionário; 
 Não é possível definir: Métodos ágeis; 
É necessária documentação extensa e completa dos requisitos? 
 Sim, documentação completa é necessária: Cascata; 
 Documentação parcial é necessária: Incremental ou evolucionário; 
 Entrega da documentação de requisitos não possui grande relevância: 
Métodos ágeis; 
 
 
 
 
28 
3.3) Tempo: 
Há necessidade de previsibilidade da data final do projeto? 
 Sim: Cascata; 
 Uma estimativa é necessária: Incremental ou evolucionário; 
 Não há a necessidade de prever data final do projeto: Métodos ágeis; 
O controle de cronograma é realizado através das atividades concluídas ou das 
funcionalidades entregues? 
 Atividades concluídas são medida de progresso: Cascata; 
 Atividades e Funcionalidades em conjunto são medida de progresso: 
Incremental ou evolucionário; 
 Funcionalidades entregues são medida de progresso: Métodos ágeis; 
3.4) Custos: 
Há necessidade de prever os custos do projeto a longo prazo? 
 Sim, os custos devem ser previstos antecipadamente: Cascata; 
 Há necessidade de previsibilidade mínima, mas os custos são flexíveis: 
Incremental ou evolucionário; 
 Não, os custos são dinâmicos e avançam conforme as entregas são 
realizadas: Métodos ágeis; 
3.5) Qualidade: 
Qualidade é melhor expressada pelo atendimento dos requisitos levantados ou pela 
impressão final do cliente? 
 Requisitos atendidos como medida de qualidade: Cascata; 
 Ambos são importantes: Incremental ou evolucionário; 
 Impressão final do cliente como medida de qualidade: Métodos ágeis; 
3.6) Recursos humanos: 
Existe flexibilidade no uso dos recursos? Ou eles serão alocados no projeto até sua 
conclusão? Os recursos participam do projeto como um todo ou são 
mobilizados/desmobilizados quando necessário? 
 Recursos são mobilizados e desmobilizados a etapa do projeto: Cascata; 
 Parte dos recursos são mobilizados e desmobilizados a cada etapa do projeto 
e parte dos recursos participam do projeto até o fim – Incremental ou 
evolucionário; 
 Recursos participam do projeto como um todo – Métodos ágeis; 
 
 
 
 
29 
3.7) Comunicações: 
Há necessidade de formalização das comunicações ou elas podem ser realizadas 
através de vias não formais? 
 Comunicações formais são essenciais: Cascata; 
 Há a necessidade do mínimo de comunicações formais mas comunicações 
não formais também são valorizadas: Incremental ou evolucionário; 
 Comunicações não formais são priorizadas: Métodos ágeis; 
3.8) Riscos: 
A equipe tem capacidade de avaliar os riscos do projeto e precificar estes riscos 
antes do início do projeto? 
 Sim, os riscos são previsíveis e podem ser precificados com precisão: 
Cascata; 
 Parte dos riscos pode ser previstos e quantificados: Incremental ou 
evolucionário; 
 Não, riscos são difíceis de prever e quantificar: Métodos ágeis; 
3.9) Aquisições: 
A terceirização à distância ou quarteirização de partes completas do software é 
necessária? 
 Sim: Cascata; 
 Não é possível prever: Incremental ou evolucionário; 
 Não há essa possibilidade: Métodos ágeis; 
3.10) Partes interessadas: 
Ambos, cliente e equipe de desenvolvimento, tem maturidade para tratar de 
alterações de escopo e melhorias sem prejudicar a relação entre as partes? 
 Sim: Cascata; 
 Sim com ressalvas: Incremental ou evolucionário; 
 Não há maturidade: Métodos ágeis; 
4) Requisitos de produto: 
Criação de software com arquitetura escalável e reutilizável é mais importante que evolução 
contínua do produto? 
 Sim: Cascata; 
 Ambos são igualmente importantes: Incremental ou evolucionário; 
 Não: Métodos ágeis; 
 
 
30 
Criar software de maneira rápida para atender ambiente de negócios que exigem mudanças 
constantes é um requisito do produto? 
 Sim: Métodos ágeis; 
 Sim com ressalvas: Incremental ou evolucionário; 
 Não: Cascata; 
5) Fatores ambientais do cliente: 
O cliente possui ambiente de negócios estável e previsível ou dinâmico e variável? 
 Cliente possui ambiente estável: Cascata; 
 Intermediário: Incremental ou evolucionário; 
 Cliente possui ambiente dinâmico e variável: Métodos ágeis; 
O cliente está disponível para que possa interagir com a equipe de desenvolvimento durante 
o projeto? 
 Não: Cascata; 
 Disponibilidade limitada: Incremental ou evolucionário; 
 Sim: Métodos ágeis; 
6) Fatores ambientais da empresa: 
A empresa possui cultura focada em atendimento aos processos ou cultura focada em 
atendimento às necessidades dos clientes? 
 Cultura focada em processos: Cascata; 
 Cultura equilibrada: Incremental ou evolucionário; 
 Cultura focada em atender o cliente: Métodos ágeis; 
Melhorias são bem vindas, mudanças são tratadas como parte necessária para o refinamento 
e repriorização dos requisitos? 
 Não, melhorias são consideradas exceção ao processo: Cascata; 
 Melhoriassão previstas, com ressalvas: Incremental ou evolucionário; 
 Sim, melhorias são previstas e fazer parte do processo – Métodos ágeis; 
7) Ativos de Processos organizacionais: 
Há conhecimento prévio dos processos de negócio do cliente? 
 Sim: Cascata; 
 Conhecimento restrito: Incremental ou evolucionário; 
 Não: Métodos ágeis; 
 
 
31 
4. Considerações Finais 
 
Através da pesquisa bibliográfica sobre o tema identificamos que o modelo de processo de 
desenvolvimento pode ser de maneira simplória definido como forma de organizar as atividades de 
desenvolvimento com o objetivo de obter um produto de software que atenda aos requisitos de produto 
levantados. Mas também identificamos que além do produto que será entregue (o que) a maneira como este 
produto será entregue (como, quando, a que custo, com que qualidade) e as variáveis que irão reger a relação 
entre o cliente e a organização que realiza o desenvolvimento (comunicação, riscos, interesses das partes), 
características que compõem os requisitos de projeto, são igualmente importantes e principalmente 
impactadas pela escolha do modelo de processo de desenvolvimento. 
Independente do modelo de processos de desenvolvimento adotado, todos são capazes de entregar 
software que contemple uma lista pré-definida de requisitos de produto. Com maior ou menor dificuldade 
quaisquer um dos modelos é capaz de entregar um produto que atenda à um conjunto de requisitos funcionais 
e não funcionais (software escalável, interoperável, eficiente, portável, confiável). Isto acontece por que 
todos os modelos existentes fazem uso das mesmas atividades metodológicas, o que os diferencia portanto é 
a capacidade de fazer jus aos requisitos de projeto. Nem todos os modelos de processos de desenvolvimento 
são capazes de realizar entregar parciais, ou fornecer estimativas precisas de tempo e custo, ou lidar com 
mudanças de forma positiva, ou utilizar lições aprendidas para melhoria dos processos de um projeto em 
andamento. 
Por este motivo é importantíssimo estar ciente de que uma série de características, algumas ligadas 
aos requisitos de produto e muitas relacionadas aos requisitos de projeto, devem ser levadas em consideração 
para que o modelo de processo de desenvolvimento mais adequado seja escolhido e adotado, e para que a 
máxima capacidade que este modelo possui em entregar um produto de qualidade, e em gerir esta relação 
entre o cliente e a organização responsável pelo desenvolvimento, seja aproveitada. 
Mas a escolha do modelo de processo de desenvolvimento, além de representar um bônus quando o 
processo estiver alinhado com os requisitos de produto e projeto, também pode representar um ônus. Por 
exemplo, quando o cliente decide por utilizar o modelo cascata de desenvolvimento com escopo pré-definido 
e custo fixo para mitigar o risco financeiro do projeto, ele deve estar ciente de que desta maneira ele se expõe 
a outro risco relacionado à completude do escopo, que pode não ter sido completamente definido e mudanças 
de escopo quando mal administradas podem representar um problema ao projeto. O mesmo acontece quando 
um processo baseado em metodologia ágil como o Scrum é utilizado em ambientes em que o cliente não está 
disponível para participar das reuniões de revisão do backlog. 
Desta maneira independente do modelo de processo adotado é necessário conhecer as características 
que podem ser decisivas para a escolha de um modelo que seja capas de trazer mais benefícios que 
problemas ao processo de desenvolvimento de software. 
 
 
32 
5. Referências 
 
Pressman, Roger S. Engenharia de Software: Uma Abordagem Profissional. 7ª ed. São Paulo: AMGH 
Editora. 2009. 773 p. 
 
PMI, Project Management Institute. Um guia do Conhecimento em Gerenciamento de Projetos (Guia 
PMBOK). 5ª ed. Pennsylvania: Project Management Institute. 2013. 567 p. 
 
MULCAHY, Rita. Rita Mulcahy’s Preparatório para o Exame de PMP. 8ª ed. Estados Unidos: RMC 
Publications. 2013. 611 p. 
 
HIRAMA, Kechi. Engenharia de Software - Qualidade e Produtividade com Tecnologia. São Paulo: 
Elsevier Editora. 2012. 207 p. 
 
ABREU, Christian Rogério e SCHOEFFEL, Pablo. Estudo, Síntese e análise de viabilidade de contratos 
ágeis para o desenvolvimento de software. Universidade do Estado de Santa Catarina. 2014. 32 p. 
 
BEEDLE, Mike. et al. Manifesto para o desenvolvimento ágil de software. Manifesto Ágil. 2001. 
Disponível em <http://www.manifestoagil.com.br/>. Acesso em: 9 set. 2015. 
 
SOMMERVILLE, Ian. Engenharia de software. 6ª ed. São Paulo: Pearson Education do Brasil. 2013. 585 
p. 
 
SCHWABER, Ken e SUTHERLAND, Jeff. The Scrum GuideTM - The definitive Guide to Scrum: The 
Rules of the Game. 2013. Disponível em: <http://www.scrumguides.org/docs/scrumguide/v1/scrum-guide-
us.pdf>. Acesso em: 4 nov. 2015.