Gerenciamento de Projetos de Software

ETEC DE SÃO PAULO
Alan Ono Osanai Pan
Alexandre Vinícius Ascencio Arteaga
Allan Alves Sallum
André Fábian Calle Huanca
João Henrique Queiroz Simões
GERENCIAMENTO DE PROJETOS DE SOFTWARE
Atividade, planejamento, programação e gerenciamento de riscos
SÃO PAULO
2023
Alan Ono Osanai Pan
Alexandre Vinícius Ascencio Arteaga
Allan Alves Sallum
André Fábian Calle Huanca
João Henrique Queiroz Simões
GERENCIAMENTO DE PROJETOS DE SOFTWARE
Atividade, planejamento, programação e gerenciamento de riscos
Trabalho sobre Gerenciamento de Projetos

de Software à Escola Técnica Estadual de
São Paulo (ETESP), como parte das
exigências para a conclusão da competência
Análise e Projetos de Sistemas.
Orientador: Prof. Luiz Ricardo de Souza
SÃO PAULO
2023
SUMÁRIO
Introdução ............................................................................................................................................... 4
Atividade ................................................................................................................................................. 5
Processos de software ........................................................................................................................ 5
Modelos de processos de software .................................................................................................... 7
O modelo em cascata ...................................................................................................................... 8
Desenvolvimento incremental ...................................................................................................... 12
Engenharia de software orientada a reuso ................................................................................... 15
Atividades do processo ..................................................................................................................... 17
Especificação de software ............................................................................................................. 17
Projeto e implementação de software.......................................................................................... 19
Validação de software ................................................................................................................... 23
Evolução do software .................................................................................................................... 27
Planejamento ........................................................................................................................................ 29
Estágios do planejamento ................................................................................................................. 29
Estágio de proposta....................................................................................................................... 29
Estágio de iniciação ....................................................................................................................... 30
Estágio de adaptação .................................................................................................................... 30
Definição de preço de software ........................................................................................................ 31
Desenvolvimento dirigido a planos ................................................................................................... 33
Planos de projeto .......................................................................................................................... 34
Processo de planejamento ............................................................................................................ 35
Planejamento ágil.............................................................................................................................. 37
Extreme Programming (XP) ........................................................................................................... 38
Scrum............................................................................................................................................. 39
Método de Desenvolvimento de Sistemas Dinâmicos (DSDM) .................................................... 40
Técnicas de estimativa ...................................................................................................................... 42
O modelo COCOMO II ................................................................................................................... 42
Modelo de composição de aplicação ........................................................................................ 43
Modelo de projeto preliminar ................................................................................................... 43
Modelo de reuso ....................................................................................................................... 44
Modelo de pós-arquitetura ....................................................................................................... 45
Observações sobre os submodelos ........................................................................................... 45
O método delphi ........................................................................................................................... 46
Análise de pontos por função ....................................................................................................... 48
Programação ......................................................................................................................................... 50
O que é? ............................................................................................................................................ 50
Como fazer? ...................................................................................................................................... 50
Como calcular a estimativa de tempo? ............................................................................................. 50
Estimativa do tamanho ................................................................................................................. 51
Como contar os pontos de função? .......................................................................................... 51
Estimativa de empenho................................................................................................................. 53
Estimativa de tempo ..................................................................................................................... 54
Gerenciamento de riscos ...................................................................................................................... 55
Identificar os riscos ........................................................................................................................... 56
Gerenciamento de riscos .................................................................................................................. 57
Identificar as fontes de riscos........................................................................................................ 59
Metodologia ...................................................................................................................................... 59
Análise qualitativa dos riscos ........................................................................................................ 61
Tipos de riscos ................................................................................................................................... 63
Considerações finais .............................................................................................................................. 71
Referências ............................................................................................................................................ 73
INTRODUÇÃO
Todo software deve ser feito para atender as necessidades dos clientes, isso é
fato. Logo, o gerenciamento de projetos de software é uma atividade ortogonal em
relação as demais atividades, pois atua como um guia para a boa execução do projeto,
já que todas as empresas trazem riscos no desenvolvimento de software. Em resumo,
o gerenciamento de projetos de software é essencial para manter a organização, a
eficiência e a qualidade ao longo do desenvolvimento, garantindo que o produto final
atenda aos requisitos, seja entregue a tempo e dentro do orçamento planejado.
Mas para compreender melhor, é necessário entender. O que é um projeto de

software? Um projeto de software é uma atividade que busca criar um produto ou
sistema de software específico. Sua realização envolve a execução de várias etapas,
que garantem e promovem sua qualidade. Essa área se desenvolveu bastante na era
da tecnologia em que vivemos, afetando todos os aspectos de nossas vidas, o que
gerou uma crescente demanda por soluções computadorizadas.
Para fazer um bom gerenciamento de projetos de software, é necessário seguir

uma série de etapas, sendo elas: a atividade, o planejamento, a programação e o
gerenciamento de riscos, que devem ser executadas de maneira colaborativa, o que
requer uma boa comunicação no ambiente de trabalho com uma equipe de
desenvolvimento bem coordenada e informada, considerada essencial para melhorar
a troca de ideias e a discussão de soluções.
Nessa indústria, o papel de um gerente é de extrema importância, pois ele

controla e gerencia as atividades envolvidas na produção, tornando-se aquele que
assume a responsabilidade da execução do projeto de software. Este precisa de
habilidades técnicas, gerenciais e de liderança para garantir uma execução bem-
sucedida de projetos.
4
ATIVIDADE
Processos de software
Um processo de software é um conjunto de atividades relacionadas que levam

à produção de um produto de software. Essas atividades podem envolver o
desenvolvimento de software a partir do zero em uma linguagem padrão de
programação como Java ou C. No entanto, aplicações de negócios não são
necessariamente desenvolvidas dessa forma. Atualmente, novos softwares de
negócios são desenvolvidos por meio da extensão e modificação de sistemas
existentes ou por meio da configuração e integração de prateleira ou componentes do
sistema.
Existem muitos processos de software diferentes, mas todos devem incluir

quatro atividades fundamentais para a engenharia de software:
1. Especificação de software. A funcionalidade do software e as restrições a

seu funcionamento devem ser definidas.
2. Projeto e implementação de software. O software deve ser produzido para

atender às especificações.
3. Validação de software. O software deve ser validado para garantir que

atenda às demandas do cliente.
4. Evolução de software. O software deve evoluir para atender às necessidades

de mudança dos clientes.
De alguma forma, essas atividades fazem parte de todos os processos de

software. Na prática, são atividades complexas em si mesmas, que incluem
subatividades como validação de requisitos, projeto de arquitetura, testes unitários
etc. Existem também as atividades que dão apoio ao processo, como documentação
e gerenciamento de configuração de software.
5
Ao descrever e discutir os processos, costumamos falar sobre suas atividades,
como a especificação de um modelo de dados, o projeto de interface de usuário etc.,
bem como a organização dessas atividades. No entanto, assim como as atividades,
as descrições do processo também podem incluir:
1. Produtos, que são os resultados de uma das atividades do processo. Por

exemplo, o resultado da atividade de projeto de arquitetura pode ser um modelo da
arquitetura de software.
2. Papéis, que refletem as responsabilidades das pessoas envolvidas no

processo. Exemplos de papéis são: gerente de projeto, gerente de configuração,
programador etc.
3. Pré e pós-condições, que são declarações verdadeiras antes e depois de

uma atividade do processo ou da produção de um produto. Por exemplo, antes do
projeto de arquitetura ser iniciado, pode haver uma pré-condição de que todos os
requisitos tenham sido aprovados pelo cliente e, após a conclusão dessa atividade,
uma pós-condição poderia ser a de que os modelos UML que descrevem a arquitetura
tenham sido revisados.
Os processos de software são complexos e, como todos os processos

intelectuais e criativos, dependem de pessoas para tomar decisões e fazer
julgamentos. Não existe um processo ideal, a maioria das organizações desenvolve
os próprios processos de desenvolvimento de software. Os processos têm evoluído
de maneira a tirarem melhor proveito das capacidades das pessoas em uma
organização, bem como das características específicas do sistema em
desenvolvimento. Para alguns sistemas, como sistemas críticos, é necessário um
processo de desenvolvimento muito bem estruturado; para sistemas de negócios, com
requisitos que se alteram rapidamente, provavelmente será mais eficaz um processo
menos formal e mais flexível.
Os processos de software, às vezes, são categorizados como dirigidos a planos

ou processos ágeis. Processos dirigidos a planos são aqueles em que todas as
atividades são planejadas com antecedência, e o progresso é avaliado por
comparação com o planejamento inicial. Em processos ágeis, o planejamento é
gradativo, e é mais fácil alterar o processo de maneira a refletir as necessidades de
6
mudança dos clientes. Conforme Boehm e Turner (2003), cada abordagem é
apropriada para diferentes tipos de software. Geralmente, é necessário encontrar um
equilíbrio entre os processos dirigidos a planos e os processos ágeis.
Embora não exista um processo ‘ideal’ de software, há espaço, em muitas

organizações, para melhorias no processo de software. Os processos podem incluir
técnicas ultrapassadas ou não aproveitar as melhores práticas de engenharia de
software da indústria. De fato, muitas empresas ainda não se aproveitam dos métodos
da engenharia de software em seu desenvolvimento de software.
Em organizações nas quais a diversidade de processos de software é reduzida,

os processos de software podem ser melhorados pela padronização. Isso possibilita
uma melhor comunicação, além de redução no período de treinamento, e torna mais
econômico o apoio ao processo automatizado. A padronização também é um
importante primeiro passo na introdução de novos métodos e técnicas de engenharia
de software, assim como as boas práticas de engenharia de software.
Modelos de processos de software
Como explicado anteriormente, um modelo de processo de software é uma

representação simplificada de um processo de software. Cada modelo representa
uma perspectiva particular de um processo e, portanto, fornece informações parciais
sobre ele. Por exemplo, um modelo de atividade do processo pode mostrar as
atividades e sua sequência, mas não mostrar os papéis das pessoas envolvidas.
Nesta seção, apresento uma série de modelos gerais de processos (algumas vezes,
chamados ‘paradigmas de processo’) a partir de uma perspectiva de sua arquitetura.
Ou seja, nós vemos um framework do processo, mas não vemos os detalhes de suas
atividades específicas.
Esses modelos genéricos não são descrições definitivas dos processos de

software. Pelo contrário, são abstrações que podem ser usadas para explicar
diferentes abordagens de desenvolvimento de software. Você pode vê-los como
7
frameworks de processos que podem ser ampliados e adaptados para criar processos
de engenharia de software mais específicos.
Os modelos de processos que abordo aqui são:
1. O modelo em cascata. Esse modelo considera as atividades fundamentais

do processo de especificação, desenvolvimento, validação e evolução, e representa
cada uma delas como fases distintas, como: especificação de requisitos, projeto de
software, implementação, teste e assim por diante.
2. Desenvolvimento incremental. Essa abordagem intercala as atividades de

especificação, desenvolvimento e validação. O sistema é desenvolvido como uma
série de versões (incrementos), de maneira que cada versão adiciona funcionalidade
à anterior.
3. Engenharia de software orientada a reuso. Essa abordagem é baseada na

existência de um número significativo de componentes reusáveis. O processo de
desenvolvimento do sistema concentra-se na integração desses componentes em um
sistema já existente em vez de desenvolver um sistema a partir do zero.
Esses modelos não são mutuamente exclusivos e muitas vezes são usados em
conjunto, especialmente para o desenvolvimento de sistemas de grande porte. Para
sistemas de grande porte, faz sentido combinar algumas das melhores características
do modelo em cascata e dos modelos de desenvolvimento incremental. É preciso ter
informações sobre os requisitos essenciais do sistema para projetar uma arquitetura
de software que dê suporte a esses requisitos. Você não pode desenvolver isso
incrementalmente. Os subsistemas dentro de um sistema maior podem ser
desenvolvidos com diferentes abordagens. As partes do sistema que são bem
compreendidas podem ser especificadas e desenvolvidas por meio de um processo
baseado no modelo em cascata. As partes que são difíceis de especificar
antecipadamente, como a interface com o usuário, devem sempre ser desenvolvidas
por meio de uma abordagem incremental.
O modelo em cascata
8
O primeiro modelo do processo de desenvolvimento de software a ser
publicado foi derivado de processos mais gerais da engenharia de sistemas (ROYCE,
1970). Esse modelo é ilustrado na Figura 1 Por causa do encadeamento entre uma
fase e outra, esse modelo é conhecido como ‘modelo em cascata’, ou ciclo de vida de
software. O modelo em cascata é um exemplo de um processo dirigido a planos —
em princípio, você deve planejar e programar todas as atividades do processo antes
de começar a trabalhar nelas.
Os principais estágios do modelo em cascata refletem diretamente as

atividades fundamentais do desenvolvimento:
1. Análise e definição de requisitos. Os serviços, restrições e metas do sistema

são estabelecidos por meio de consulta aos usuários. Em seguida, são definidos em
detalhes e funcionam como uma especificação do sistema.
2. Projeto de sistema e software. O processo de projeto de sistemas aloca os

requisitos tanto para sistemas de hardware como para sistemas de software, por meio
da definição de uma arquitetura geral do sistema. O projeto de software envolve
identificação e descrição das abstrações fundamentais do sistema de software e seus
relacionamentos.
3. Implementação e teste unitário. Durante esse estágio, o projeto do software

é desenvolvido como um conjunto de programas ou unidades de programa. O teste
unitário envolve a verificação de que cada unidade atenda a sua especificação.
9
Figura 1 – O modelo em cascata
Fonte: SOMMERVILLE, Ian. Engenharia de software. 9° Edição. São Paulo: Pearson Prentice Hall,
2011
4. Integração e teste de sistema. As unidades individuais do programa ou
programas são integradas e testadas como um sistema completo para assegurar que
os requisitos do software tenham sido atendidos. Após o teste, o sistema de software
é entregue ao cliente.
5. Operação e manutenção. Normalmente (embora não necessariamente),

essa é a fase mais longa do ciclo de vida. O sistema é instalado e colocado em uso.
A manutenção envolve a correção de erros que não foram descobertos em estágios
iniciais do ciclo de vida, com melhora da implementação das unidades do sistema e
ampliação de seus serviços em resposta às descobertas de novos requisitos.
Em princípio, o resultado de cada estágio é a aprovação de um ou mais

documentos (‘assinados’). O estágio seguinte não deve ser iniciado até que a fase
anterior seja concluída. Na prática, esses estágios se sobrepõem e alimentam uns
aos outros de informações. Durante o projeto, os problemas com os requisitos são
identificados; durante a codificação, problemas de projeto são encontrados e assim
por diante. O processo de software não é um modelo linear simples, mas envolve o
feedback de uma fase para outra. Assim, os documentos produzidos em cada fase
podem ser modificados para refletirem as alterações feitas em cada um deles.
Por causa dos custos de produção e aprovação de documentos, as iterações

podem ser dispendiosas e envolver significativo retrabalho. Assim, após um pequeno
10
número de iterações, é normal se congelarem partes do desenvolvimento, como a
especificação, e dar-se continuidade aos estágios posteriores de desenvolvimento. A
solução dos problemas fica para mais tarde, ignorada ou programada, quando
possível. Esse congelamento prematuro dos requisitos pode significar que o sistema
não fará o que o usuário quer. Também pode levar a sistemas mal estruturados,
quando os problemas de projeto são contornados por artifícios de implementação.
Durante o estágio final do ciclo de vida (operação e manutenção), o software é

colocado em uso. Erros e omissões nos requisitos originais do software são
descobertos. Os erros de programa e projeto aparecem e são identificadas novas
necessidades funcionais. O sistema deve evoluir para permanecer útil. Fazer essas
alterações (manutenção do software) pode implicar repetição de estágios anteriores
do processo.
O modelo em cascata é consistente com outros modelos de processos de

engenharia, e a documentação é produzida em cada fase do ciclo. Dessa forma, o
processo torna-se visível, e os gerentes podem monitorar o progresso de acordo com
o plano de desenvolvimento. Seu maior problema é a divisão inflexível do projeto em
estágios distintos. Os compromissos devem ser assumidos em um estágio inicial do
processo, o que dificulta que atendam às mudanças de requisitos dos clientes.
Em princípio, o modelo em cascata deve ser usado apenas quando os

requisitos são bem compreendidos e pouco provavelmente venham a ser
radicalmente alterados durante o desenvolvimento do sistema. No entanto, o modelo
em cascata reflete o tipo de processo usado em outros projetos de engenharia. Como
é mais fácil usar um modelo de gerenciamento comum para todo o projeto, processos
de software baseados no modelo em cascata ainda são comumente utilizados.
Uma variação importante do modelo em cascata é o desenvolvimento formal

de um sistema, em que se cria um modelo matemático de uma especificação do
sistema. Esse modelo é então refinado, usando transformações matemáticas que
preservam sua consistência, em código executável. Partindo do pressuposto de que
suas transformações matemáticas estão corretas, você pode, portanto, usar um forte
argumento de que um programa gerado dessa forma é consistente com suas
especificações.
11
Processos formais de desenvolvimento, como os baseados no método B
(SCHNEIDER, 2001; WORDSWORTH, 1996), são particularmente adequados para o
desenvolvimento de sistemas com requisitos rigorosos de segurança, confiabilidade e
proteção. A abordagem formal simplifica a produção de casos de segurança ou
proteção. Isso demonstra aos clientes ou reguladores que o sistema realmente
cumpre com seus requisitos de proteção ou segurança.
Processos baseados em transformações formais são geralmente usados

apenas no desenvolvimento de sistemas críticos de segurança ou de proteção. Eles
exigem conhecimentos especializados. Para a maioria dos sistemas, esse processo
não oferece custo-benefício significativo sobre outras abordagens para o
desenvolvimento de sistemas.
Desenvolvimento incremental
O desenvolvimento incremental é baseado na ideia de desenvolver uma

implementação inicial, expô-la aos comentários dos usuários e continuar por meio da
criação de várias versões até que um sistema adequado seja desenvolvido (Figura 2).
Atividades de especificação, desenvolvimento e validação são intercaladas, e não
separadas, com rápido feedback entre todas as atividades.
Desenvolvimento incremental de software, que é uma parte fundamental das

abordagens ágeis, é melhor do que uma abordagem em cascata para a maioria dos
sistemas de negócios, e-commerce e sistemas pessoais. Desenvolvimento
incremental reflete a maneira como resolvemos os problemas. Raramente elaboramos
uma completa solução do problema com antecedência; geralmente movemo-nos
passo a passo em direção a uma solução, recuando quando percebemos que
cometemos um erro. Ao desenvolver um software de forma incremental, é mais barato
e mais fácil fazer mudanças no software durante seu desenvolvimento.
12
Figura 2 – Desenvolvimento incremental
2011
Cada incremento ou versão do sistema incorpora alguma funcionalidade
necessária para o cliente. Frequentemente, os incrementos iniciais incluem a
funcionalidade mais importante ou mais urgente. Isso significa que o cliente pode
avaliar o sistema em um estágio relativamente inicial do desenvolvimento para ver se
ele oferece o que foi requisitado. Em caso negativo, só o incremento que estiver em
desenvolvimento no momento precisará ser alterado e, possivelmente, nova
funcionalidade deverá ser definida para incrementos posteriores.
O desenvolvimento incremental tem três vantagens importantes quando

comparado ao modelo em cascata:
1. O custo de acomodar as mudanças nos requisitos do cliente é reduzido. A

quantidade de análise e documentação a ser refeita é muito menor do que o
necessário no modelo em cascata.
2. É mais fácil obter feedback dos clientes sobre o desenvolvimento que foi
feito. Os clientes podem fazer comentários sobre as demonstrações do software e ver
o quanto foi implementado. Os clientes têm dificuldade em avaliar a evolução por meio
de documentos de projeto de software.
3. É possível obter entrega e implementação rápida de um software útil ao

cliente, mesmo se toda a funcionalidade não for incluída. Os clientes podem usar e
obter ganhos a partir do software inicial antes do que é possível com um processo em
cascata.
13
O desenvolvimento incremental, atualmente, é a abordagem mais comum para
o desenvolvimento de sistemas aplicativos. Essa abordagem pode ser tanto dirigida a
planos, ágil, ou, o mais comum, uma mescla dessas abordagens. Em uma abordagem
dirigida a planos, os incrementos do sistema são identificados previamente; se uma
abordagem ágil for adotada, os incrementos iniciais são identificados, mas o
desenvolvimento de incrementos posteriores depende do progresso e das prioridades
dos clientes.
Do ponto de vista do gerenciamento, a abordagem incremental tem dois

problemas:
1. O processo não é visível. Os gerentes precisam de entregas regulares para

mensurar o progresso. Se os sistemas são desenvolvidos com rapidez, não é
economicamente viável produzir documentos que reflitam cada uma das versões do
sistema.
2. A estrutura do sistema tende a se degradar com a adição dos novos

incrementos. A menos que tempo e dinheiro sejam dispendidos em refatoração para
melhoria do software, as constantes mudanças tendem a corromper sua estrutura.
Incorporar futuras mudanças do software torna-se cada vez mais difícil e oneroso.
Os problemas do desenvolvimento incremental são particularmente críticos

para os sistemas de vida-longa, grandes e complexos, nos quais várias equipes
desenvolvem diferentes partes do sistema. Sistemas de grande porte necessitam de
um framework ou arquitetura estável, e as responsabilidades das diferentes equipes
de trabalho do sistema precisam ser claramente definidas, respeitando essa
arquitetura. Isso deve ser planejado com antecedência, e não desenvolvido de forma
incremental.
Você pode desenvolver um sistema de forma incremental e expô-lo aos

comentários dos clientes, sem realmente entregá-lo e implantá-lo no ambiente do
cliente. Entrega e implantação incremental significa que o software é usado em
processos operacionais reais. Isso nem sempre é possível, pois experimentações com
o novo software podem interromper os processos normais de negócios.
14
Engenharia de software orientada a reuso
Na maioria dos projetos de software, há algum reuso de software. Isso acontece

muitas vezes informalmente, quando as pessoas envolvidas no projeto sabem de
projetos ou códigos semelhantes ao que é exigido. Elas os buscam, fazem as
modificações necessárias e incorporam-nos a seus sistemas.
Esse reuso informal ocorre independentemente do processo de

desenvolvimento que se use. No entanto, no século XXI, processos de
desenvolvimento de software com foco no reuso de software existente tornaram-se
amplamente usados. Abordagens orientadas a reuso dependem de uma ampla base
de componentes reusáveis de software e de um framework de integração para a
composição desses componentes. Em alguns casos, esses componentes são
sistemas completos (COTS ou de prateleira), capazes de fornecer uma funcionalidade
específica, como processamento de texto ou planilha.
Um modelo de processo geral de desenvolvimento baseado no reuso está na

Figura 3 embora o estágio de especificação de requisitos iniciais e o estágio de
validação sejam comparáveis a outros processos de software, os estágios
intermediários em um processo orientado a reuso são diferentes. Esses estágios são:
1. Análise de componentes. Dada a especificação de requisitos, é feita uma

busca por componentes para implementar essa especificação. Em geral, não há
correspondência exata, e os componentes que podem ser usados apenas fornecem
alguma funcionalidade necessária.
2. Modificação de requisitos. Durante esse estágio, os requisitos são analisados

usando-se informações sobre os componentes que foram descobertos. Em seguida,
estes serão modificados para refletir os componentes disponíveis. No caso de
modificações impossíveis, a atividade de análise dos componentes pode ser
reinserida na busca por soluções alternativas.
3. Projeto do sistema com reuso. Durante esse estágio, o framework do sistema

é projetado ou algo existente é reusado. Os projetistas têm em mente os componentes
15
que serão reusados e organizam o framework para reuso. Alguns softwares novos
podem ser necessários, se componentes reusáveis não estiverem disponíveis.
4. Desenvolvimento e integração. Softwares que não podem ser adquiridos

externamente são desenvolvidos, e os componentes e sistemas COTS são integrados
para criar o novo sistema. A integração de sistemas, nesse modelo, pode ser parte do
processo de desenvolvimento, em vez de uma atividade separada.
Existem três tipos de componentes de software que podem ser usados em um

processo orientado a reuso:
1. Web services desenvolvidos de acordo com os padrões de serviço e que

estão disponíveis para invocação remota.
2. Coleções de objetos que são desenvolvidas como um pacote a ser integrado

com um framework de componentes, como NET ou J2EE.
Figura 3 – Engenharia de software orientada a reuso
2011
3. Sistemas de software stand-alone configurados para uso em um ambiente
particular.
Engenharia de software orientada a reuso tem a vantagem óbvia de reduzir a

quantidade de software a ser desenvolvido e, assim, reduzir os custos e riscos.
Geralmente, também proporciona a entrega mais rápida do software. No entanto,
compromissos com os requisitos são inevitáveis, e isso pode levar a um sistema que
não atende às reais necessidades dos usuários. Além disso, algum controle sobre a
evolução do sistema é perdido, pois as novas versões dos componentes reusáveis
não estão sob o controle da organização que os está utilizando.
16
Atividades do processo
Processos reais de software são intercalados com sequências de atividades

técnicas, de colaboração e de gerência, com o intuito de especificar, projetar,
implementar e testar um sistema de software. Os desenvolvedores de software usam
uma variedade de diferentes ferramentas de software em seu trabalho. As ferramentas
são especialmente úteis para apoiar a edição de diferentes tipos de documentos e
para gerenciar o imenso volume de informações detalhadas que é gerado em um
projeto de grande porte.
As quatro atividades básicas do processo — especificação, desenvolvimento,

validação e evolução — são organizadas de forma diferente conforme o processo de
desenvolvimento. No modelo em cascata são organizadas em sequência, enquanto
que no desenvolvimento incremental são intercaladas. A maneira como essas
atividades serão feitas depende do tipo de software, das pessoas e das estruturas
organizacionais envolvidas. Em extreme programming, por exemplo, as
especificações estão escritas em cartões. Testes são executáveis e desenvolvidos
antes do próprio programa. A evolução pode demandar reestruturação substancial do
sistema ou refatoração.
Especificação de software
Especificação de software ou engenharia de requisitos é o processo de

compreensão e definição dos serviços requisitados do sistema e identificação de
restrições relativas à operação e ao desenvolvimento do sistema. A engenharia de
requisitos é um estágio particularmente crítico do processo de software, pois erros
nessa fase inevitavelmente geram problemas no projeto e na implementação do
sistema.
O processo de engenharia de requisitos (Figura 4) tem como objetivo produzir

um documento de requisitos acordados que especifica um sistema que satisfaz os
17
requisitos dos stakeholders. Requisitos são geralmente apresentados em dois níveis
de detalhe. Os usuários finais e os clientes precisam de uma declaração de requisitos
em alto nível; desenvolvedores de sistemas precisam de uma especificação mais
detalhada do sistema.
Existem quatro atividades principais do processo de engenharia de requisitos:
1. Estudo de viabilidade. É feita uma estimativa acerca da possibilidade de se

satisfazerem as necessidades do usuário identificado usando-se tecnologias atuais
de software e hardware. O estudo considera se o sistema proposto será rentável a
partir de um ponto de vista de negócio e se ele pode ser desenvolvido no âmbito das
atuais restrições orçamentais. Um estudo de viabilidade deve ser relativamente barato
e rápido. O resultado deve informar a decisão de avançar ou não, com uma análise
mais detalhada.
2. Elicitação e análise de requisitos. Esse é o processo de derivação dos

requisitos do sistema por meio da observação dos sistemas existentes, além de
discussões com os potenciais usuários e compradores, análise de tarefas, entre
outras etapas. Essa parte do processo pode envolver o desenvolvimento de um ou
mais modelos de sistemas e protótipos, os quais nos ajudam a entender o sistema a
ser especificado.
3. Especificação de requisitos. É a atividade de traduzir as informações obtidas

durante a atividade de análise em um documento que defina um conjunto de
requisitos. Dois tipos de requisitos podem ser incluídos nesse documento. Requisitos
do usuário são declarações abstratas dos requisitos do sistema para o cliente e
usuário final do sistema; requisitos de sistema são uma descrição mais detalhada da
funcionalidade a ser provida.
4. A validação de requisitos. Essa atividade verifica os requisitos quanto a

realismo, consistência e completude. Durante esse processo, os erros no documento
de requisitos são inevitavelmente descobertos. Em seguida, o documento deve ser
modificado para correção desses problemas.
18
Figura 4 – Os requisitos da engenharia de processos
2011
Naturalmente, as atividades no processo de requisitos não são feitas em
apenas uma sequência. A análise de requisitos continua durante a definição e
especificação, e novos requisitos emergem durante o processo. Portanto, as
atividades de análise, definição e especificação são intercaladas. Nos métodos ágeis,
como extreme programming, os requisitos são desenvolvidos de forma incremental,
de acordo com as prioridades do usuário, e a elicitação de requisitos é feita pelos
usuários que integram equipe de desenvolvimento.
Projeto e implementação de software
O estágio de implementação do desenvolvimento de software é o processo de

conversão de uma especificação do sistema em um sistema executável. Sempre
envolve processos de projeto e programação de software, mas, se for usada uma
abordagem incremental para o desenvolvimento, também pode envolver o
refinamento da especificação do software.
Um projeto de software é uma descrição da estrutura do software a ser

implementado, dos modelos e estruturas de dados usados pelo sistema, das
interfaces entre os componentes do sistema e, às vezes, dos algoritmos usados. Os
19
projetistas não chegam a um projeto final imediatamente, mas desenvolvem-no de
forma iterativa. Eles acrescentam formalidade e detalhes, enquanto desenvolvem seu
projeto por meio de revisões constantes para correção de projetos anteriores.
A Figura 5 é um modelo abstrato de processo que mostra as entradas para o

processo de projeto, suas atividades e os documentos produzidos como saídas dele.
O diagrama sugere que os estágios do processo de projeto são sequenciais. Na
realidade, as atividades do processo são intercaladas. Feedback de um estágio para
outro e consequente retrabalho são inevitáveis em todos os processos.
A maioria dos softwares interage com outros sistemas de software, incluindo o

sistema operacional, o banco de dados, o middleware e outros aplicativos. Estes
formam a ‘plataforma de software’, o ambiente em que o software será executado.
Informações sobre essa plataforma são entradas essenciais para o processo de
projeto, pois os projetistas devem decidir a melhor forma de integrá-la ao ambiente do
software. A especificação de requisitos é uma descrição da funcionalidade que o
software deve oferecer, e seus requisitos de desempenho e confiança. Se o sistema
for para processamento de dados existentes, a descrição desses dados poderia ser
incluída na especificação da plataforma; caso contrário, a descrição dos dados deve
ser uma entrada para o processo de projeto, para que a organização dos dados do
sistema seja definida.
20
Figura 5 – Um modelo geral do processo de projeto
2011
As atividades no processo de projeto podem variar, dependendo do tipo de
sistema a ser desenvolvido. Por exemplo, sistemas de tempo real demandam projeto
de timing, mas podem não incluir uma base de dados; nesse caso, não há um projeto
de banco de dados envolvido. A Figura 5 mostra quatro atividades que podem ser
parte do processo de projeto de sistemas de informação:
1. Projeto de arquitetura, no qual você pode identificar a estrutura geral do

sistema, os componentes principais (algumas vezes, chamados subsistemas ou
módulos), seus relacionamentos e como eles são distribuídos.
2. Projeto de interface, no qual você define as interfaces entre os componentes

do sistema. Essa especificação de interface deve ser inequívoca. Com uma interface
precisa, um componente pode ser usado de maneira que outros componentes não
precisam saber como ele é implementado. Uma vez que as especificações de
interface são acordadas, os componentes podem ser projetados e desenvolvidos
simultaneamente.
3. Projeto de componente, no qual você toma cada componente do sistema e

projeta seu funcionamento. Pode-se tratar de uma simples declaração da
funcionalidade que se espera implementar, com o projeto específico para cada
21
programador. Pode, também, ser uma lista de alterações a serem feitas em um
componente reutilizável ou um modelo de projeto detalhado. O modelo de projeto
pode ser usado para gerar automaticamente uma implementação.
4. Projeto de banco de dados, no qual você projeta as estruturas de dados do

sistema e como eles devem ser representados em um banco de dados. Novamente,
o trabalho aqui depende da existência de um banco de dados a ser reusado ou da
criação de um novo banco de dados.
Essas atividades conduzem a um conjunto de saídas do projeto, que também

é mostrado na Figura 5. O detalhe e a apresentação de cada uma variam
consideravelmente. Para sistemas críticos, devem ser produzidos documentos
detalhados de projeto, indicando as descrições precisas e exatas do sistema. Se uma
abordagem dirigida a modelos é usada, essas saídas podem ser majoritariamente
diagramas. Quando os métodos ágeis de desenvolvimento são usados, as saídas do
processo de projeto podem não ser documentos de especificação separados, mas ser
representadas no código do programa.
Métodos estruturados para projeto foram desenvolvidos nas décadas de 1970

e 1980, e foram os precursores da UML e do projeto orientado a objetos (BUDGEN,
2003). Eles estão relacionados com a produção de modelos gráficos do sistema e, em
muitos casos, geram códigos automaticamente a partir desses modelos.
Desenvolvimento dirigido a modelos (MDD, do inglês model-driven development) ou
engenharia dirigida a modelos (SCHMIDT, 2006), em que os modelos de software são
criados em diferentes níveis de abstração, é uma evolução dos métodos estruturados.
Em MDD, há uma ênfase maior nos modelos de arquitetura com uma separação entre
os modelos abstratos independentes de implementação e específicos de
implementação. Os modelos são desenvolvidos em detalhes suficientes para que o
sistema executável possa ser gerado a partir deles.
O desenvolvimento de um programa para implementar o sistema decorre

naturalmente dos processos de projeto de sistema. Apesar de algumas classes de
programa, como sistemas críticos de segurança, serem normalmente projetadas em
detalhe antes de se iniciar qualquer implementação, é mais comum os estágios
posteriores de projeto e desenvolvimento de programa serem intercalados.
Ferramentas de desenvolvimento de software podem ser usadas para gerar um
22
esqueleto de um programa a partir do projeto. Isso inclui o código para definir e
implementar interfaces e, em muitos casos, o desenvolvedor precisa apenas
acrescentar detalhes da operação de cada componente do programa.
Programação é uma atividade pessoal, não existe um processo geral a ser

seguido. Alguns programadores começam com componentes que eles compreendem,
desenvolvem-nos e depois passam para os componentes menos compreendidos.
Outros preferem a abordagem oposta, deixando para o fim os componentes familiares,
pois sabem como desenvolvê-los. Alguns desenvolvedores preferem definir os dados
no início do processo e, em seguida, usam essa definição para dirigir o
desenvolvimento do programa; outros deixam os dados não especificados durante o
maior período de tempo possível.
Geralmente, os programadores fazem alguns testes do código que estão

desenvolvendo, o que, muitas vezes, revela defeitos que devem ser retirados do
programa. Isso é chamado debugging. Testes de defeitos e debugging são processos
diferentes. Testes estabelecem a existência de defeitos; debugging diz respeito à
localização e correção desses defeitos.
Quando você está realizando debugging, precisa gerar hipóteses sobre o

comportamento observável do programa e, em seguida, testar essas hipóteses, na
esperança de encontrar um defeito que tenha causado uma saída anormal. O teste
das hipóteses pode envolver o rastreio manual do código do programa, bem como
exigir novos casos de teste para localização do problema. Ferramentas interativas de
depuração, que mostram os valores intermediários das variáveis do programa e uma
lista das instruções executadas, podem ser usadas para apoiar o processo de
depuração.
Validação de software
Validação de software ou, mais genericamente, verificação e validação (V&V),

tem a intenção de mostrar que um software se adequa a suas especificações ao
mesmo tempo em que satisfaz as especificações do cliente do sistema. Teste de
23
programa, em que o sistema é executado com dados de testes simulados, é a principal
técnica de validação. A validação também pode envolver processos de verificação,
como inspeções e revisões, em cada estágio do processo de software, desde a
definição dos requisitos de usuários até o desenvolvimento do programa. Devido à
predominância dos testes, a maior parte dos custos de validação incorre durante e
após a implementação.
Com exceção de pequenos programas, sistemas não devem ser testados como
uma unidade única e monolítica. A Figura 2.6 mostra um processo de teste, de três
estágios, nos quais os componentes do sistema são testados, em seguida, o sistema
integrado é testado e, finalmente, o sistema é testado com os dados do cliente.
Idealmente, os defeitos de componentes são descobertos no início do processo, e os
problemas de interface são encontrados quando o sistema é integrado. No entanto,
quando os defeitos são descobertos, o programa deve ser depurado, e isso pode
requerer que outros estágios do processo de testes sejam repetidos. Erros em
componentes de programa podem vir à luz durante os testes de sistema. O processo
é, portanto, iterativo, com informações realimentadas de estágios posteriores para
partes anteriores do processo.
Figura 6 – Estágios de testes
2011
Os estágios do processo de teste são:
1. Testes de desenvolvimento. Os componentes do sistema são testados pelas

pessoas que o desenvolveram. Cada componente é testado de forma independente,
separado dos outros. Os componentes podem ser entidades simples, como funções
ou classes de objetos, ou podem ser agrupamentos coerentes dessas entidades.
Ferramentas de automação de teste, como JUnit (MASSOL e HUSTED, 2003), que
podem reexecutar testes de componentes quando as novas versões dos
componentes são criadas, são comumente usadas.
24
2. Testes de sistema. Componentes do sistema são integrados para criar um
sistema completo. Esse processo se preocupa em encontrar os erros resultantes das
interações inesperadas entre componentes e problemas de interface do componente.
Também visa mostrar que o sistema satisfaz seus requisitos funcionais e não
funcionais, bem como testar as propriedades emergentes do sistema. Para sistemas
de grande porte, esse pode ser um processo multiestágios, no qual os componentes
são integrados para formar subsistemas individualmente testados antes de serem
integrados para formar o sistema final.
3. Testes de aceitação. Esse é o estágio final do processo de testes, antes que

o sistema seja aceito para uso operacional. O sistema é testado com dados fornecidos
pelo cliente, e não com dados advindos de testes simulados. O teste de aceitação
pode revelar erros e omissões na definição dos requisitos do sistema, pois dados reais
exercitam o sistema de formas diferentes dos dados de teste. Os testes de aceitação
também podem revelar problemas de requisitos em que os recursos do sistema não
atendam às necessidades do usuário ou o desempenho do sistema seja inaceitável.
Os processos de desenvolvimento de componentes e testes geralmente são

intercalados. Os programadores criam seus próprios dados para testes e,
incrementalmente, testam o código enquanto ele é desenvolvido. Essa é uma
abordagem economicamente sensível, pois o programador conhece o componente e,
portanto, é a melhor pessoa para gerar casos de teste.
Se uma abordagem incremental é usada para o desenvolvimento, cada

incremento deve ser testado enquanto é desenvolvido — sendo que esses testes
devem ser baseados nos requisitos para esse incremento. Em extreme programming,
os testes são desenvolvidos paralelamente aos requisitos, antes de se iniciar o
desenvolvimento, o que ajuda testadores e desenvolvedores a compreender os
requisitos e garante o cumprimento dos prazos enquanto são criados os casos de
teste.
25
Figura 7 – Fases de testes de um processo de software dirigido a planos
2011
Quando um processo de software dirigido a planos é usado (por exemplo, para
o desenvolvimento de sistemas críticos), o teste é impulsionado por um conjunto de
planos de testes. Uma equipe independente de testadores trabalha a partir desses
planos de teste pré-formulados, que foram desenvolvidos a partir das especificações
e do projeto do sistema. A Figura 7 ilustra como os planos de teste são o elo entre as
atividades de teste e de desenvolvimento. Esse modelo é, às vezes, chamado modelo
V de desenvolvimento (gire a figura de lado para ver o V).
O teste de aceitação também pode ser chamado ‘teste alfa’. Sistemas sob
encomenda são desenvolvidos para um único cliente. O processo de testes-alfa
continua até que o desenvolvedor do sistema e o cliente concordem que o sistema
entregue é uma implementação aceitável dos requisitos.
Quando um sistema está pronto para ser comercializado como um produto de

software, costuma-se usar um processo de testes denominado ‘teste beta’. Este teste
envolve a entrega de um sistema a um número de potenciais clientes que
concordaram em usá-lo. Eles relatam problemas para os desenvolvedores dos
sistemas. O produto é exposto para uso real, e erros que podem não ter sido
antecipados pelos construtores do sistema são detectados. Após esse feedback, o
sistema é modificado e liberado para outros testes-beta ou para venda em geral.
26
Evolução do software
A flexibilidade dos sistemas de software é uma das principais razões pelas

quais os softwares vêm sendo, cada vez mais, incorporados em sistemas grandes e
complexos. Uma vez que a decisão pela fabricação do hardware foi tomada, é muito
caro fazer alterações em seu projeto. Entretanto, as mudanças no software podem ser
feitas a qualquer momento durante ou após o desenvolvimento do sistema.
Figura 8 – Evolução do sistema
2011
Mesmo grandes mudanças são muito mais baratas do que as correspondentes
alterações no hardware do sistema.
Historicamente, sempre houve uma separação entre o processo de

desenvolvimento e o de evolução do software (manutenção de software). As pessoas
pensam no desenvolvimento de software como uma atividade criativa em que um
sistema é desenvolvido a partir de um conceito inicial até um sistema funcional. Por
outro lado, pensam na manutenção do software como maçante e desinteressante.
Embora os custos de manutenção sejam frequentemente mais altos que os custos
iniciais de desenvolvimento, os processos de manutenção são, em alguns casos,
considerados menos desafiadores do que o desenvolvimento do software original.
Essa distinção entre o desenvolvimento e a manutenção é cada vez mais

irrelevante. Poucos sistemas de software são completamente novos, e faz muito mais
sentido ver o desenvolvimento e a manutenção como processos contínuos. Em vez
de dois processos separados, é mais realista pensar na engenharia de software como
um processo evolutivo (Figura 8), no qual o software é constantemente alterado
27
durante seu período de vida em resposta às mudanças de requisitos e às
necessidades do cliente.
28
PLANEJAMENTO
Estágios do planejamento
O planejamento é uma parte essencial do gerenciamento de projetos, pois

fornece uma estrutura e um roteiro para orientar a equipe durante todo o processo de
desenvolvimento do software. Um gerente competente sabe elaborar um plano
eficiente, definindo tarefas que precisam ser realizadas dentro de um cronograma
viável, distribuindo o trabalho de forma adequada entre os membros da equipe,
estimando custos e antecipando possíveis obstáculos que possam surgir ao longo do
projeto.
O plano evolui de acordo com o ciclo de vida do projeto, passando por três
estágios distintos:
Estágio de proposta
Durante o estágio de proposta para desenvolvimento ou fornecimento de um

sistema de software, é essencial que o gerente elabore um plano para avaliar a
viabilidade do projeto e estimar os custos envolvidos. É importante ressaltar que,
nessa fase inicial, o plano será puramente especulativo, uma vez que os requisitos do
sistema ainda não foram totalmente definidos. O foco estará na descrição detalhada
da funcionalidade necessária, na apresentação de uma estratégia convincente para a
execução do projeto e na visão geral do produto final.
Embora esse plano inicial seja especulativo, ele servirá como base para a
proposta. Normalmente, quando o contrato é conquistado, é necessário realizar um
replanejamento do projeto, levando em consideração eventuais alterações e requisitos
adicionais que possam surgir desde a elaboração da proposta.
29
Nesse sentido, é fundamental ter flexibilidade e capacidade de adaptação para
garantir o sucesso do projeto, pois o planejamento permitirá ajustar o plano inicial de
acordo com as mudanças e desafios que surgirem ao longo do desenvolvimento do
sistema de software.
Estágio de iniciação
Após a conquista do contrato, o gerente tem acesso a informações mais

detalhadas, o que possibilita aprimorar as estimativas iniciais de esforço e criar um
plano de iniciação do projeto. Mesmo que os requisitos ainda não estejam totalmente
definidos, especialmente em abordagens ágeis, o novo plano desempenha um papel
fundamental na tomada de decisões, formação da equipe, elaboração do orçamento
e definição de prazos. Além disso, serve como base para a alocação de recursos e a
contratação de novos colaboradores, caso seja necessário reforçar a equipe.
É igualmente importante que o plano inclua mecanismos de monitoramento

para comparar o progresso real com o planejado ao longo do projeto. Embora existam
diversos métodos formais adotados pela maioria das organizações, um gerente
competente é capaz de compreender o que está acontecendo por meio de discussões
informais com a equipe. A monitoração informal desempenha um papel fundamental
ao antecipar possíveis problemas, revelando dificuldades à medida que surgem e
permitindo que sejam abordadas rapidamente. Isso possibilita uma resposta mais
rápida e efetiva, garantindo que o projeto se mantenha no caminho certo.
Estágio de adaptação
O gerente do projeto realiza ajustes periódicos no plano à medida que adquire

experiência e informações sobre o progresso do trabalho, utilizando esse
conhecimento para atualizar as estimativas de tempo até a conclusão do projeto.
Mudanças nos requisitos podem demandar uma reestruturação do plano, com uma
30
nova divisão de tarefas e um ajuste no cronograma. Em abordagens ágeis, os planos
são de curto prazo e passíveis de mudanças contínuas à medida que o software
evolui.
O plano de projeto é um documento em constante evolução durante o processo

de desenvolvimento. Seu propósito é garantir que a equipe compreenda o que deve
ser alcançado e quando deve ser entregue. Assim, o cronograma, a estimativa de
custos e os riscos precisam ser atualizados à medida que o software é desenvolvido.
Mesmo em metodologias ágeis, é necessário um plano de iniciação de projeto para
alocar recursos, embora esse plano seja menos detalhado e contenha apenas
informações essenciais sobre a divisão do trabalho e o cronograma. Durante o
desenvolvimento, um plano de projeto e estimativas de esforço informais são
delineados para cada versão do software, com a participação de toda a equipe no
processo de planejamento.
Definição de preço de software
A definição do preço de um produto de software vai além do simples cálculo

dos custos de desenvolvimento e lucro dos desenvolvedores. Na prática, a relação
entre o custo do projeto e o preço proposto para o cliente é complexa e envolve
diversos aspectos organizacionais, econômicos, políticos e comerciais, como
apresentado na Tabela 1. Ao estabelecer o preço, é necessário levar em
consideração também questões relacionadas à organização, os riscos associados
ao projeto e o tipo de contrato a ser utilizado, pois esses fatores podem afetar o
preço de forma significativa. Dessa forma, a definição do preço do projeto deve ser
uma atividade colaborativa, envolvendo a equipe de marketing e vendas, a alta
gerência e os gerentes de projeto, para garantir uma decisão fundamentada e
alinhada com os objetivos da empresa.
A empresa de software TechSol, especializada em desenvolvimento de

aplicativos móveis, teve a oportunidade de concorrer a um projeto de dois anos para
uma grande empresa de transporte. Embora os custos estimados fossem de R$2
31
milhões, a TechSol decidiu adotar uma estratégia de preço para ganhar, oferecendo
um valor de R$1,5 milhão para o cliente. Embora isso signifique uma margem de lucro
menor, a TechSol busca conquistar o cliente e estabelecer uma parceria de longo
prazo, abrindo portas para projetos futuros mais lucrativos e aumentando sua
visibilidade no mercado. Ao fornecer um aplicativo móvel de alta qualidade e garantir
a satisfação do cliente, eles esperam obter recomendações e atrair mais clientes em
potencial, justificando o investimento inicial em uma estratégia de preço competitivo.
Tabela 1 - Fatores que alteram a precificação
Fator Descrição
Oportunidade de mercado Uma organização de desenvolvimento pode optar por estabelecer um preço
baixo visando entrar em um novo segmento de mercado de software. Ao
aceitar um lucro menor em um projeto, a organização pode se beneficiar ao
ter a oportunidade de obter lucros maiores no futuro. Além disso, a
experiência adquirida neste projeto pode ser valiosa para o desenvolvimento
de novos produtos, agregando valor à organização.
Incerteza de estimativa de É possível aumentar o preço por uma contingência de lucro caso a organização
custo esteja incerta quanto à estimativa de custo.
Condições contratuais Em alguns casos, o desenvolvedor de software pode oferecer um preço menor
ao cliente se ele permitir que o código-fonte seja mantido e reutilizado em
outros projetos. Isso pode ser vantajoso para ambas as partes, pois o cliente
paga menos e o desenvolvedor pode aproveitar o código em futuras tarefas.
Volatilidade de requisitos A estratégia envolve a redução inicial do preço para garantir o contrato e, em
seguida, cobrar valores mais altos por alterações nos requisitos, buscando
equilibrar os custos adicionais e o esforço necessário para atender às novas
demandas.
Saúde financeira Desenvolvedores em dificuldades financeiras podem reduzir seus preços para
garantir contratos e evitar a saída do mercado. Em tempos econômicos difíceis,
o fluxo de caixa se torna prioritário em relação aos lucros imediatos, sendo
uma estratégia importante para manter a sustentabilidade do negócio.
32
No estágio de proposta de um projeto, discute-se o custo antes da formalização
do contrato. Uma vez que um acordo é alcançado, inicia-se a negociação e
estabelece-se uma especificação detalhada que fica restrita ao custo acordado. Tanto
o comprador quanto o vendedor devem concordar com a funcionalidade aceitável do
sistema. Em muitos projetos, o custo é um fator fixo, e não os requisitos do projeto.
Para garantir que o custo não seja excedido, pode ser necessário fazer alterações nos
requisitos.
Desenvolvimento dirigido a planos
Essa é uma abordagem que faz o processo de desenvolvimento com um plano

detalhado. Um plano é criado para organizar o trabalho a ser feito, quem o fará,
quando e o que deve ser feito (cronograma). O gerente utiliza esse planejamento
como base para tomar decisões e medir o progresso do trabalho. O desenvolvimento
dirigido a planos pode ser considerado uma forma “tradicional” de gerenciamento de
projeto ainda mais em contraponto ao planejamento ágil o qual aborda o plano de
forma mais flexível.
Como toda abordagem, existem vantagens e desvantagens que tornam essa

abordagem mais adequada para certos tipos de projetos ou equipes de
desenvolvimento. Nesse sentido, é fundamental que o gerente esteja ciente das
características do projeto em questão para adotar o método de planejamento mais
adequado. No caso do desenvolvimento orientado a planos, ele é mais indicado para
sistemas de grande porte que requerem uma análise inicial extensa e minuciosa.
Essa abordagem permite uma análise aprofundada dos requisitos e uma

definição clara do escopo do projeto antes do início do desenvolvimento. Isso ajuda a
identificar potenciais desafios, planejar adequadamente os recursos necessários e
antecipar possíveis problemas. Portanto, para projetos complexos e de grande escala,
o desenvolvimento orientado a planos pode ser mais eficaz.
No entanto, é importante ressaltar que essa abordagem pode ser menos

flexível em lidar com mudanças e imprevistos ao longo do projeto. Portanto, é
33
necessário equilibrar a necessidade de um planejamento detalhado com a capacidade
de adaptação às mudanças que possam surgir durante o desenvolvimento.
Planos de projeto
O plano de projeto tem como objetivo definir os recursos disponíveis, a

alocação de tarefas e o cronograma, além de identificar potenciais riscos para o
projeto e determinar a abordagem a ser adotada para o gerenciamento de riscos.
Embora as especificidades possam variar de acordo com diferentes fatores,
geralmente, o plano de projeto segue o seguinte modelo:
1. Introdução. Uma visão geral do projeto, incluindo seu objetivo,

escopo e principais stakeholders envolvidos.
2. Objetivos do projeto. Os resultados esperados e as metas a

serem alcançadas pelo projeto.
3. Recursos. A lista dos recursos necessários para o projeto, como

equipe, ferramentas, equipamentos e orçamento disponível.
4. Divisão de trabalho. A atribuição de tarefas específicas para os

membros da equipe, definindo responsabilidades e prazos.
5. Cronograma. Um plano de tempo que mostra as atividades do

projeto, suas dependências e duração estimada, resultando em um
cronograma geral.
6. Gerenciamento de riscos. A identificação dos riscos potenciais

associados ao projeto, sua análise de impacto e probabilidade, além das
estratégias para mitigar e monitorar esses riscos ao longo do desenvolvimento.
7. Comunicação. Uma estratégia para a comunicação interna e

externa durante o projeto, incluindo relatórios de progresso, reuniões e canais
de comunicação utilizados.
34
8. Controle de qualidade. As atividades e processos garantirão a
qualidade do trabalho realizado, incluindo testes, revisões e avaliações.
9. Monitoramento e controle. Os métodos e indicadores utilizados

para acompanhar o progresso do projeto, comparando-o com o plano inicial e
realizando ajustes conforme necessário.
10. Encerramento do projeto. As atividades relacionadas ao

encerramento formal do projeto, como a entrega final, a documentação e a
avaliação de lições aprendidas.
É importante ressaltar que cada plano de projeto pode ser adaptado de acordo
com as necessidades específicas e características do projeto em questão. Além disso,
é possível desenvolver uma série de planos complementares para dar suporte a
outras atividades do processo.
Tabela 2 - Planos suplementares
Plano Descrição
Plano de qualidade Descreve os procedimentos de qualidade e as

normas que serão usadas em um projeto.
Plano de validação Descreve a abordagem, os recursos e as estruturas

de gerenciamento de configuração que serão
usados.
Plano de gerenciamento de configuração Descreve os procedimentos e as estruturas de

gerenciamento de configuração que serão usados
Plano de manutenção prevê os requisitos de manutenção, custos e esforço.
Plano de desenvolvimento pessoal Descreve como as habilidades e experiências dos

membros de equipe do projeto serão desenvolvidas.
Por exemplo: O modelo P-CMM.
2011
Processo de planejamento
35
Embora o gerente seja o responsável por essa tarefa, é importante que toda a
equipe participe ativamente. Cada membro da equipe possui conhecimento específico
sobre o trabalho que desempenha, o que contribui para a elaboração de um plano
mais completo e eficiente.
O planejamento ocorre na fase de iniciação do projeto e é importante ressaltar

que o plano não é algo fixo, ele estará sujeito a alterações à medida que a equipe
adquire mais informações sobre o sistema e o ambiente de trabalho, além das
mudanças nas metas e requisitos, discutidos na fase de adaptação.
No início do planejamento, é necessário identificar alguns elementos que

afetarão o projeto do início ao fim. Esses elementos incluem as limitações do projeto,
como disponibilidade de ferramentas e pessoal, data de entrega, orçamento e
infraestrutura do ambiente de trabalho. Essas limitações devem ser consideradas em
todas as etapas do planejamento.
Após identificar as limitações, é hora de estabelecer formas de monitorar o

andamento do projeto. Para isso, são utilizados os milestones. Os milestones são
pontos no cronograma nos quais é possível avaliar o progresso, como a entrega do
sistema para testes. Também é necessário identificar os entregáveis do projeto, que
são os produtos de trabalho que serão entregues ao cliente, como um documento de
requisitos para o sistema.
Com essas informações em mãos, é possível elaborar um cronograma

estimado para o projeto e iniciar ou permitir que as atividades definidas no cronograma
sejam executadas. Após um período de tempo, geralmente de duas a três semanas,
é importante revisar o progresso e observar as discrepâncias em relação ao
cronograma previsto.
É normal que ocorram pequenos desvios em relação às estimativas iniciais,

pois os parâmetros do projeto são aproximados. Nesses casos, é necessário fazer
modificações no plano original. É fundamental ser realista ao criar o plano do
projeto, considerando que problemas e atrasos podem surgir ao longo do caminho.
Os pressupostos iniciais e o cronograma devem ser pessimistas, e o plano deve
incluir contingências suficientes para evitar a renegociação constante dos milestones
e das restrições do projeto durante o processo de planejamento.
36
Figura 9 - Diagrama UML do processo de planejamento de projeto.
[Projeto
<<sistem [não terminado]
Identifica
a>> terminado]
r
Definir
Identifica Cronogra
r riscos Definir
Cronogra Definir
Cronogra
Identifica [problem
r as
[desvios e problemas
entregáv graves]
menores]
Iniciar Replaneja
ações de r projeto
2011
Quando problemas graves surgem no desenvolvimento de um projeto, é

necessário tomar ações de mitigação de riscos para reduzir as chances de falhas. Isso
pode envolver replanejamento do projeto, renegociação das restrições e entregáveis
com o cliente, e estabelecimento de um novo cronograma. Caso essas medidas não
sejam eficazes, uma revisão técnica formal pode ser necessária para encontrar uma
abordagem alternativa e verificar se os objetivos do projeto ainda estão alinhados com
o cliente e a equipe de desenvolvimento.
Em alguns casos, o projeto pode ser cancelado devido a falhas técnicas,

gerenciais ou mudanças externas que afetam seu propósito. Durante o longo
período de desenvolvimento de um grande projeto de software, é comum que os
objetivos do negócio e as prioridades se alterem, o que pode resultar na suspensão
do desenvolvimento ou em grandes mudanças para atender às novas metas
organizacionais.
Planejamento ágil
Ao contrário da abordagem orientada a planos, os métodos ágeis não se

baseiam em um planejamento inicial rígido. Em vez disso, o projeto é entregue em
37
incrementos, os quais são planejados durante o desenvolvimento. Esse método
prioriza a entrega de software funcional em detrimento de documentação abrangente
que apenas relata se os objetivos foram atingidos.
Uma diferença marcante em relação ao plano tradicional é que o método ágil

não se apega a ferramentas e processos rigidamente estabelecidos, priorizando a
interatividade e colaboração da equipe. A funcionalidade dos processos em vigor é
constantemente avaliada e adaptada conforme necessário.
No estágio de proposta, é muito mais importante que o gerente possa extrair

todos os requisitos do cliente, auxiliando-o a estruturar o escopo do software, do que
simplesmente negociar termos contratuais. Essa colaboração inicial com o cliente
permite um desenvolvimento mais independente e eficiente.
A abordagem ágil apresenta vantagens significativas ao lidar com ambientes

imprevisíveis e instáveis, pois é mais flexível para lidar com mudanças durante o
desenvolvimento, priorizando a satisfação do cliente. No entanto, é importante
considerar que em projetos extensos, onde a equipe adquire mais informações ao
longo do processo, essa flexibilidade pode levar a uma falta de estrutura e
organização. Nesses casos, uma abordagem mais próxima do modelo tradicional
pode ser mais adequada.
Como mencionado anteriormente, existem várias metodologias ágeis

disponíveis. Algumas das principais são o Extreme programing (XP), Scrum, DSSD.
Cada uma dessas metodologias possui suas características e abordagens
específicas, permitindo que equipes escolham a que melhor se adapte às suas
necessidades e contextos de projeto. Essas metodologias ágeis compartilham a
ênfase na colaboração, flexibilidade e entrega incremental de valor, oferecendo
alternativas eficazes aos métodos tradicionais de desenvolvimento de software.
Extreme Programming (XP)
O Extreme Programming (XP) visa a entrega rápida, flexível e de alta qualidade.

Com ênfase na comunicação, colaboração e simplicidade, o XP promove iterações
38
curtas de trabalho, entrega contínua de valor e adaptação aos requisitos em constante
mudança.
Uma das principais características do XP é a colaboração intensa entre a

equipe de desenvolvimento e os stakeholders. Através de práticas como programação
em pares e revisões de código contínuas, os membros da equipe compartilham
conhecimento, melhoram a qualidade do código e promovem a troca de ideias para
encontrar soluções eficazes.
Essa metodologia valoriza a simplicidade como uma abordagem para lidar com
problemas complexos. Os desenvolvedores são incentivados a buscar soluções
simples, evitando o excesso de complexidade desnecessária. Isso permite um
desenvolvimento mais ágil, focado na entrega de valor e na resposta rápida às
mudanças nas necessidades dos clientes.
Outro aspecto importante do XP é a ênfase na qualidade do software. Práticas

como testes automatizados, refatoração e integração contínua são amplamente
utilizadas para garantir a robustez, confiabilidade e manutenibilidade do código. Isso
resulta em um software de alta qualidade, reduzindo o risco de erros e facilitando
futuras modificações.
Figura 10 - Planejamento em XP
Identificaçã Estimativa Planejamen Planejamen Planejamen

o de estória inicial to de to de to de
2011.
Scrum
O Scrum é um framework amplamente utilizado no desenvolvimento de projetos

de software. Baseado em três pilares fundamentais: transparência, inspeção e
adaptação, o Scrum permite que equipes entreguem resultados de qualidade de forma
iterativa e incremental. O trabalho é dividido em iterações chamadas de Sprints, com
39
duração fixa de duas a quatro semanas. A equipe Scrum é autogerenciável e
multifuncional, com o Scrum Master garantindo o cumprimento do framework e o
Product Owner representando os interesses do cliente.
O método utiliza o Product Backlog, uma lista priorizada de requisitos,

funcionalidades e melhorias, para selecionar os itens a serem trabalhados em cada
Sprint. Durante o Sprint, a equipe colabora diariamente nas reuniões de
acompanhamento conhecidas como Daily Scrum. Ao final de cada Sprint, ocorrem a
Revisão do Sprint, onde o trabalho concluído é apresentado, e a Retrospectiva do
Sprint, para refletir sobre o processo de trabalho.
Ele oferece benefícios como flexibilidade, visibilidade do progresso, melhoria

contínua e foco na entrega de qualidade ao cliente. No entanto, é importante adaptar
o Scrum às necessidades específicas de cada projeto e equipe.
O Scrum é visualmente ilustrado por meio de um framework composto por

várias etapas interligadas, representadas na figura 11 que ilustra o fluxo do processo.
Figura 11 - Fluxo do processo Scrum
A cada
24 horas
30 dias
Sprint
Product Backlog Sprint Backlog Entrega

incrementada do
software
Método de Desenvolvimento de Sistemas Dinâmicos (DSDM)
40
A DSDM (Dynamic Systems Development Method) visa à entrega eficiente e
rápida de soluções de negócio. Com foco na colaboração, entrega incremental e
priorização dos requisitos do negócio, a DSDM proporciona uma abordagem
estruturada para o desenvolvimento ágil de software. Ao incorporar as necessidades
e expectativas dos usuários, clientes e demais envolvidos, busca-se garantir que o
resultado final atenda aos requisitos reais do negócio.
Um dos princípios-chave da DSDM é a entrega incremental de funcionalidades

valiosas. Por meio da entrega contínua de incrementos de software funcional, é
possível obter feedback rápido e realizar ajustes e melhorias ao longo do
desenvolvimento, o método também se destaca pela gestão proativa de riscos.
Através de uma abordagem interativa e um processo colaborativo de tomada de
decisões, a metodologia busca identificar e mitigar riscos desde o início do projeto.
Adicionalmente, a DSDM prioriza os requisitos do negócio, selecionando e

refinando funcionalidades de acordo com sua importância. Dessa forma, o foco é
direcionado às necessidades mais relevantes, permitindo uma abordagem para a
implementação das demais funcionalidades.
Figura 12 - Dinâmica da metodologia DSDM
Pré-Projeto
Viabilidade
Exploração Implementação
de incremento
Pós-Projeto
Engenharia
41
Técnicas de estimativa
A estimativa de software desempenha um papel crucial no desenvolvimento de

projetos de softwares bem-sucedidos. Ela envolve a previsão dos esforços
necessários, recursos e prazos para concluir uma tarefa de desenvolvimento de
software. No entanto, estimar com precisão o tempo e os recursos necessários para
um projeto de software pode ser um desafio complexo, devido à natureza única e
variável de cada projeto.
Para isso existem várias técnicas disponíveis para auxiliar no processo de

estimativa de software. Essas técnicas foram desenvolvidas ao longo dos anos e são
usadas para fornecer estimativas mais confiáveis e fundamentadas. Nesta introdução,
vamos explorar algumas das técnicas mais comumente utilizadas.
O modelo COCOMO II
COCOMO II é um modelo amplamente utilizado para estimar o esforço, o

cronograma e os custos de um projeto de software. Ele foi desenvolvido com base em
dados coletados de uma grande quantidade de projetos de software, permitindo a
criação de fórmulas que relacionam o tamanho do sistema, os fatores do projeto e da
equipe ao esforço necessário para desenvolver o software. O COCOMO II é um
modelo bem documentado e não proprietário, fornecendo uma estrutura detalhada
para estimativas de software.
O COCOMO II é composto por diferentes submodelos que são aplicados em

diferentes estágios do desenvolvimento do projeto:
Tabela 3 - Modelos de estimativa COCOMO
Modelo Base Uso
Modelo de composição de Número de pontos de aplicação Sistemas desenvolvidos usando

aplicação linguagens dinâmicas,
42
programação DB etc.
Modelo de projeto preliminar Número de pontos de função Estimativa de esforço inicial

baseada nos requisitos de sistema
e em opções de projeto
Modelo de reúso Número de linhas de código Esforço para integrar

componentes reusáveis ou código
gerado automaticamente
Modelo de pós-arquitetura reusado ou gerado Número de Esforço de desenvolvimento

linhas de código-fonte baseado em especificações de
projeto de sistema
2011.
Modelo de composição de aplicação
Este modelo é usado para estimar o esforço necessário para desenvolver

sistemas a partir de componentes reutilizáveis, scripts ou programação de banco de
dados. Ele baseia-se em estimativas de pontos de aplicação e produtividade para
calcular o esforço necessário.
𝐸𝑠𝑓𝑜𝑟ç𝑜 (𝑃𝑀) = (𝑁𝐴𝑃 × (1 – %𝑟𝑒ú𝑠𝑜/100)) / 𝑃𝑅𝑂𝐷
A PM representa a estimativa de esforço em pessoa-mês, indicando a

quantidade de trabalho necessária para concluir um projeto. NAP é o número total de
pontos de aplicação do sistema entregue, que mede a complexidade e o escopo do
sistema desenvolvido. %reúso é uma estimativa da quantidade de código
reaproveitado durante o desenvolvimento. E PROD representa a produtividade de
pontos de aplicação, relacionando a quantidade de pontos entregues com o esforço
investido.
Modelo de projeto preliminar
43
Esse modelo é usado nas fases iniciais do projeto, quando os requisitos do
usuário já estão estabelecidos. Ele utiliza uma fórmula-padrão de estimativa com
multiplicadores simplificados para obter uma estimativa rápida e aproximada do
esforço necessário.
𝐸𝑠𝑓𝑜𝑟ç𝑜 (𝑃𝑀) = 𝐴 × 𝑇𝑎𝑚𝑎𝑛ℎ𝑜^𝐵 × 𝑀
A estimativa de esforço em pessoa-mês (PM) é calculada levando em

consideração diversos fatores. Um desses fatores é o coeficiente de ajuste (A), que é
baseado em dados históricos e geralmente tem o valor de 2,94. Outro elemento
importante é o tamanho do sistema em KSLOC (Kilo Source Lines Of Code). Além
disso, o expoente (B) desempenha um papel crucial ao refletir a complexidade do
projeto. Todos esses componentes são levados em consideração para estimar o
esforço necessário para o desenvolvimento de um sistema.
Modelo de reuso
Esse modelo é aplicado quando o reúso de código é uma parte significativa do

projeto. Ele estima o esforço necessário para integrar componentes reutilizáveis e
códigos gerados automaticamente, levando em consideração a quantidade de código
reutilizado e os custos adicionais envolvidos na adaptação e integração.
𝐸𝑠𝑓𝑜𝑟ç𝑜 𝑝𝑎𝑟𝑎 𝑐ó𝑑𝑖𝑔𝑜 𝑔𝑒𝑟𝑎𝑑𝑜 (𝑃𝑀𝐴𝑢𝑡𝑜) = (𝐴𝑆𝐿𝑂𝐶 × 𝐴𝑇/100) / 𝐴𝑇𝑃𝑅𝑂𝐷
𝐸𝑠𝑓𝑜𝑟ç𝑜 𝑝𝑎𝑟𝑎 𝑐ó𝑑𝑖𝑔𝑜 𝑟𝑒𝑢𝑡𝑖𝑙𝑖𝑧𝑎𝑑𝑜 (𝑃𝑀𝑅𝑒𝑢𝑠𝑒𝑑) = 𝐸𝑆𝐿𝑂𝐶 × (1 – 𝐴𝑇/100) × 𝐴𝐴𝑀
𝐸𝑠𝑓𝑜𝑟ç𝑜 𝑡𝑜𝑡𝑎𝑙 𝑛𝑒𝑐𝑒𝑠𝑠á𝑟𝑖𝑜 = 𝑃𝑀𝐴𝑢𝑡𝑜 + 𝑃𝑀𝑅𝑒𝑢𝑠𝑒𝑑
Ao calcular a estimativa de esforço em pessoa-mês para código gerado

automaticamente (PMAuto), é necessário levar em consideração diversos fatores. Um
deles é o ASLOC, que representa o número total de linhas de código reutilizadas,
incluindo o código gerado. Além disso, a porcentagem de código reutilizado gerado
automaticamente (AT) também é importante para essa estimativa. A produtividade dos
engenheiros na integração do código (ATPROD) também desempenha um papel
significativo. Outro fator considerado é o número de linhas equivalentes de novo
44
código-fonte (ESLOC). Por fim, o multiplicador de ajuste de adaptação (AAM) é
utilizado para aprimorar a precisão da estimativa. Todos esses elementos são levados
em conta para estimar o esforço necessário para o desenvolvimento de código gerado
automaticamente.
Modelo de pós-arquitetura
Este é o modelo mais detalhado do COCOMO II e é utilizado após o projeto da

arquitetura do sistema. Ele permite estimativas mais precisas, considerando a
decomposição do sistema em objetos ou módulos. Esse modelo utiliza a fórmula
básica de cálculo de esforço, levando em conta o tamanho do sistema, os custos de
reúso e o número de linhas de código modificadas.
𝐸𝑠𝑓𝑜𝑟ç𝑜 (𝑃𝑀) = 𝐴 × 𝑇𝑎𝑚𝑎𝑛ℎ𝑜^𝐵 × 𝑀
A estimativa de esforço em pessoa-mês (PM) para o desenvolvimento de um

sistema leva em consideração o coeficiente de ajuste (A) baseado em dados
históricos, o tamanho total do sistema em KSLOC considerando código novo,
reutilizado e modificado, o expoente (B) que reflete a complexidade do projeto, e um
multiplicador (M) que considera atributos de produto, processo e organização. Esses
elementos combinados permitem uma estimativa mais precisa do esforço necessário,
facilitando o planejamento e o controle do desenvolvimento do sistema.
Observações sobre os submodelos
Os multiplicadores (M) podem variar dependendo dos atributos específicos do

projeto e podem ser obtidos através de tabelas e escalas de classificação. Esses
multiplicadores são multiplicados entre si para obter o valor final de M.
As fórmulas mencionadas são simplificações e que o COCOMO II oferece uma

variedade de multiplicadores e ajustes adicionais para levar em consideração
45
aspectos específicos de cada projeto. Os valores dos multiplicadores e os detalhes
completos das fórmulas podem ser encontrados na documentação oficial do
COCOMO II.
Cada submodelo incorpora atributos específicos do projeto, como

confiabilidade, complexidade, experiência da equipe e outros fatores que afetam a
estimativa de esforço. Os valores desses atributos são avaliados e utilizados nas
equações para refinar as estimativas.
COCOMO II não fornece estimativas precisas por si só. Ele é uma ferramenta
que requer a experiência e o conhecimento do estimador para ajustar os parâmetros
corretamente e interpretar os resultados. As estimativas resultantes do COCOMO II
devem ser usadas como diretrizes iniciais e podem ser refinadas à medida que mais
informações se tornem disponíveis durante o desenvolvimento do projeto.
O método delphi
O método Delphi é uma abordagem de tomada de decisões baseada em

consenso e na coleta de opiniões de especialistas em determinado assunto.
Desenvolvido originalmente na década de 1950 pela RAND Corporation, o método
Delphi tem sido amplamente utilizado em diversas áreas, como pesquisa acadêmica,
planejamento estratégico, previsões de mercado e tomada de decisões em grupo.
O objetivo é alcançar um consenso confiável em um grupo de especialistas,

mesmo quando esses especialistas estão geograficamente dispersos ou quando a
interação face a face não é possível. Isso é alcançado por meio de um processo
iterativo de coleta de informações e feedback anônimo.
O processo típico do método Delphi envolve as seguintes etapas:
Seleção dos especialistas. Um grupo de especialistas é selecionado com

base em sua experiência e conhecimento no assunto em questão. Esses especialistas
podem ser acadêmicos, profissionais da indústria ou qualquer pessoa com
conhecimentos relevantes.
46
Questionários. Um facilitador ou coordenador prepara uma série de
questionários e enquetes contendo perguntas relacionadas ao problema em
discussão. Os especialistas respondem individualmente aos questionários,
fornecendo suas opiniões e justificativas.
Feedback e resumo. O facilitador coleta as respostas dos especialistas e

resume os resultados de forma anônima. As opiniões individuais não são identificadas,
a fim de evitar influências externas e permitir que todos os participantes se expressem
livremente.
Iterações. O processo é repetido por várias rodadas, com os especialistas

recebendo os resultados e um resumo das opiniões do grupo a cada iteração. Eles
têm a oportunidade de reavaliar suas respostas anteriores com base no feedback
fornecido.
Convergência e consenso. Com o passar das iterações, espera-se que as

opiniões dos especialistas se aproximem e um consenso comece a emergir. O
processo continua até que um nível satisfatório de concordância seja alcançado.
Figura 13 - Questionário Delphi
Realização de um
questionário
Análise das respostas
Sim Atingiu-se consenso? Não
Tabelamento de resposta e
entrega da informação a
equipe
47
Uma das principais vantagens do método Delphi é a sua capacidade de
explorar uma ampla gama de opiniões e conhecimentos especializados, ao mesmo
tempo em que evita conflitos e pressões de grupo. Além disso, o anonimato dos
especialistas promove a liberdade de expressão e reduz possíveis influências
hierárquicas ou preconceitos.
Porém, o método Delphi também apresenta algumas limitações. O processo

pode ser demorado, especialmente quando há necessidade de várias iterações. Além
disso, a qualidade das respostas depende da expertise e da disponibilidade dos
especialistas, bem como da formulação adequada das perguntas.
Análise de pontos por função
A Análise de Pontos por Função (APF) é uma técnica de medição e estimativa

utilizada para quantificar o tamanho funcional de um sistema de software.
Desenvolvida por Allan Albrecht no final da década de 1970, a APF é amplamente
adotada na indústria de software como uma métrica objetiva para medir a
funcionalidade de um sistema, independentemente da tecnologia ou linguagem de
programação utilizada.
A APF baseia-se na ideia de que as funcionalidades de um sistema podem ser

classificadas em diferentes categorias, conhecidas como elementos de contagem. Os
elementos de contagem incluem funções de entrada, funções de saída, funções de
consulta, funções de arquivo e funções de interface do usuário. Cada função é
avaliada com base em sua complexidade e impacto no sistema.
O processo de análise de pontos por função geralmente segue as seguintes

etapas:
Identificação das funções. A equipe responsável pela APF identifica as

principais funcionalidades do sistema que serão contadas. Isso envolve uma análise
detalhada dos requisitos e especificações do software.
48
Classificação das funções. Cada função é classificada em uma das
categorias mencionadas anteriormente (entrada, saída, consulta, arquivo, interface do
usuário) com base em sua finalidade e comportamento.
Avaliação da complexidade. Para cada função identificada, a complexidade

é avaliada levando em consideração fatores como o número de campos envolvidos,
as regras de negócio relacionadas e a interação com outros componentes do sistema.
Contagem dos pontos por função. Com base na classificação e

complexidade das funções, os pontos por função são atribuídos. Existem fórmulas
padronizadas que associam os valores de pontos a diferentes combinações de
categorias e complexidades.
Cálculo do tamanho funcional. A soma dos pontos por função atribuídos a

todas as funcionalidades resulta no tamanho funcional do sistema, que é uma medida
objetiva e independente da tecnologia utilizada.
A análise de pontos por função oferece várias vantagens. Ela fornece uma
métrica consistente e comparável para medir o tamanho funcional de sistemas,
permitindo estimativas mais precisas de esforço, tempo e custo de desenvolvimento.
Além disso, a APF é independente de tecnologia, o que significa que pode ser aplicada
a diferentes tipos de sistemas, independentemente da linguagem de programação ou
plataforma.
No entanto, a análise de pontos por função também apresenta algumas

limitações. A atribuição de pontos por função requer um entendimento detalhado dos
requisitos e especificações do sistema, o que pode exigir esforço e tempo
significativos. Além disso, a subjetividade na avaliação da complexidade pode levar a
variações nas estimativas entre diferentes analistas.
49
PROGRAMAÇÃO
O que é?
A programação de um projeto de software é o roteiro de todas as atividades a

serem feitas em um projeto de software, com a ordem de precedência entre elas e o
horário de ocorrência de cada atividade. Geralmente são definidas várias tarefas, e os
marcos do projeto, que tem que ser organizados mantendo vários fatores em mente.
Assim, temos que considerar a organização das tarefas, que estão no caminho crítico
da programação, que são essenciais para terminarmos o projeto dentro do tempo
definido. A organização das tarefas que ficam fora do caminho crítico tem menos
impacto sobre toda a programação do projeto.
Como fazer?
Para fazer a programação de um projeto de software é necessário, dividir as

tarefas do projeto em pequenas e menores, assim descobrindo várias outras tarefas
relacionadas ao projeto de software, sendo essencial correlacionar todas elas de
forma com que elas fiquem gerenciáveis, também tendo que fazer uma estimativa de
tempo que encaixe melhor para cada tarefa, dividindo o tempo no mercado de trabalho
e unidades de funcionários, atribuindo um número adequado de trabalho e
funcionários para cada tarefa, e por fim calcular o tempo total da execução do projeto
do início ao fim.
Como calcular a estimativa de tempo?
50
Estimativa do tamanho
O tamanho do software pode ser estimado na medida KLOC,

acrónimo para Kilo Lines of Code(em português, mil linhas de código) ou pelo cálculo
de pontos de função do software. Com o KLOC sendo uma medida para o tamanho
de grandes programas de computadores, que pode ser usado como base para estimar
o tamanho de outros programas, para estimar o seu prazo e custo. E com a análise
por ponto de função sendo uma das técnicas mais usadas para se medir projetos de
desenvolvimento de software, estabelecendo o tamanho do software considerando as
suas funcionalidades implementadas, com essa medida não dependendo da
tecnologia e/ou linguagem de programação usada.
Como contar os pontos de função?
Para se contar os pontos de função, temos que seguir os seguintes passos:
Primeiro é necessário determinar o tipo de contagem (onde será determinado

o que será medido), os três tipos de contagem são:
A contagem de projeto de desenvolvimento, que mede a funcionalidade

fornecida aos usuários finais quando o projeto estiver pronto, na sua instalação,
também abrangendo a conversão dos dados necessários para a construção dos
softwares.
A contagem de projeto de melhoria (manutenção), que mede as modificações

em um software já existente, que inclui a adição, a alteração e a exclusão de algumas
funções do sistema, além das funções de conversão de dados.
A contagem de aplicação, que mede a funcionalidade fornecida ao usuário pela

aplicação instalada e em produção para que a atual funcionalidade tenha uma medida.
No segundo passo, temos que identificar o escopo da contagem e a fronteira

da aplicação, é nesse momento que são identificados todos os relacionamentos do
51
sistema e/ou da funcionalidade que está sendo contada com o seu exterior(o que está
fora da fronteira) e são identificadas as pertinências dos dados e os processos
suportados pelo sistema/funcionalidade que está sendo contado(a), basicamente a
fronteira da aplicação define o que é externo para a aplicação e o escopo define um
conjunto ou subconjunto de software de tamanho conhecido.
No terceiro e quarto passo temos que contar as funções de dados e as funções

de transação, é nesse momento em que são contados os pontos de função não
ajustados:
Funções de dados:
Arquivos Lógicos Internos (ALIs);
Arquivos de Interface Externa (AIEs).;
Funções de Transação:
Entradas Externas (EE);
Saídas Externas (SE);
Consultas Externas (CE);
O quinto passo é o cálculo do Fator de Ajuste. Estes fatores estão relacionados

com as características da aplicação. É nesse passo que ocorre a correção das
distorções da etapa anterior (cálculo das funções de dados e das funções de
transação) e baseia-se nas características gerais do sistema, que são relacionados a
14 itens que determinam o valor do nível de influência de cada um desses itens do
dimensionamento do sistema. Os itens são:
1. Comunicação de dados;
2. Processamento distribuído;
3. Performance;
4.Configuração do equipamento;
52
5. Volume de transações;
6. Entrada de dados on-line;
7. Interface com o usuário;
8. Atualização on-line;
9. Processamento complexo;
10. Reusabilidade;
11. Facilidade de implantação;
12. Facilidade operacional;
13.Múltiplos locais;
14. Facilidade de mudanças (Flexibilidade);
Deve ser atribuído a cada uma das Características Gerais do Sistema (GSCs),
um peso, que varia de 0 (sem influência) a 5 (forte influência) e a soma deles deve
resultar no valor do Grau Total de Influência (TDI). As características são resumidas
no fator de ajuste, que quando aplicado, corrige o valor de Pontos de Função não
ajustados em cerca de mais ou menos 35% criando o Ponto de Função Ajustado.
O sexto e último passo é o cálculo dos pontos de função ajustados. É nesse

passo que é feita a correção de possíveis distorções ocorridas durante o cálculo dos
pontos de função não ajustados, aproximando as medidas da situação real.
Normalmente e contratualmente, os fatores de ajuste são iguais a 1 para que não
influenciem nos pontos de função não ajustados.
Estimativa de empenho
Os gestores estimam esforços em termos de demanda pessoal e funcionários-

hora necessários para produzir o software. Para tamanho esforço software estimado
deve ser conhecido. Isso pode ser obtido pela experiência dos gestores da
53
organização, dados históricos ou software tamanho podem ser convertidos em
esforços, utilizando algumas fórmulas.
Estimativa de tempo
Depois que o tamanho e os esforços são estimados, o tempo necessário para

produzir o software pode ser estimado. Os esforços exigidos são divididos em
subcategorias conforme as especificações de requisitos e da interdependência dos
vários componentes de software. Tarefas são divididas em pequenas tarefas,
atividades ou eventos por meio do trabalho estrutura revolucionária (WBS). As tarefas
são agendadas no dia-a-dia ou em meses de calendário. E assim, a soma do tempo
necessário para concluir todas as tarefas em horas ou dias, é o tempo total investido
para concluir o projeto.
54
GERENCIAMENTO DE RISCOS
O desenvolvimento de softwares é uma atividade complexa que exige

planejamento, decisão e estratégia para produzir um produto final com qualidade e
que atenda às necessidades do cliente. Os projetos de software envolvem uma série
de variáveis determinantes para o seu sucesso, que precisam ser gerenciadas e
estimadas para não comprometer o que foi previamente estabelecido.
Sendo assim, um projeto deve ser considerado um esforço temporário

empreendido para criar um produto, serviço ou resultado exclusivo. O gerenciamento
dos riscos em projetos pode ser considerado fundamental para que o projeto atinja
seus objetivos e satisfaça às necessidades (do cliente, da organização, do financiador,
etc.) dentro do prazo estabelecido.
Neste cenário faz necessária estimativa relacionada ao prazo

(cronograma) de um projeto, pois o ciclo de vida de um projeto é afetado por diversos
fatores como custo, escopo, equipe de desenvolvimento, consultoria, stakeholders,
dentre outros.
De acordo com o 2015 CHAOS Report do Standish Group, o percentual

de projetos de software entregues dentro do tempo, custo e especificações previstos
era de 29%, e o percentual de projetos que eram concluídos com extrapolação de
orçamento, ou prazo (comprometendo os recursos e funções previamente
especificados) era de 52%, ambas as estimativas são positivas com relação à
pesquisa de 2014, que apontava 28% e 55%, respectivamente. O relatório também
evidencia que o percentual de projetos cancelados ou falidos, antes de serem
finalizados era de 19%, uma estiva negativa em relação à pesquisa de 2014, que
consistia em 17%.
Várias pesquisas apontam fracassos em projetos de softwares

decorrentes de falhas no gerenciamento, e por isso, a disciplina de gestão de projetos
tem ganhado importância no meio empresarial por direcionar os recursos para o
alcance das metas estratégicas.
55
O sucesso de projetos de software é um objetivo que deve ser priorizado,
mas por outro lado, não é tão fácil de ser alcançado, pois o seu ciclo de vida, assim
como o de qualquer projeto, é caracterizado por riscos e incertezas que estão
diretamente relacionados ao sucesso do projeto.
Segundo Kelton et al. (2004), a simulação computacional consiste em

um conjunto de métodos aplicados para a análise de uma ampla variedade de
modelos de sistemas do mundo real, por meio de software projetado para imitar as
operações, e/ou características do sistema.
Sendo assim, a Simulação de Monte Carlo (SMC)se apresenta como

uma técnica de grande valor para diversas áreas do conhecimento, podendo ser
aplicado na análise dos riscos em projetos, pois a sua aplicação proporciona valores
e estimativas que representam informações cruciais para a equipe de projetos e ao
tomador de decisão, visto que a eficiência no planejamento, só será atingida, se as
melhores decisões forem tomadas e a melhor estratégia for adotada.
Deste modo, o presente trabalho tem como objetivo analisar os fatores

de risco em um projeto de software, utilizando o método de Monte Carlo, para obter
estimativas acerca do cronograma desse projeto. (HENRIQUE e RODRIGUES, 2017).
Identificar os riscos
O processo de identificar os riscos fornece as ferramentas e meios para que

sejam identificados os riscos relacionados ao projeto. Quaisquer riscos ignorados
durante esse processo podem ser mais difíceis de serem solucionados mais tarde.
Neste processo, participam o time do projeto, especialistas nos assuntos abordados
pelo mesmo, os stakeholders e outros gerentes de projeto. (KWAK e STODDARDB,
2004)
O objetivo por trás de identificar o risco é considerá-los antes que eles

se tornem problemas e incorporar esta informação no processo de gerenciamento de
projetos. Qualquer pessoa que esteja trabalhando em um projeto pode identificar
56
riscos, pois cada indivíduo tem algum conhecimento especial sobre diferentes partes
do projeto. Durante essa identificação, incertezas e questões de extrema importância
para o projeto são transformadas em diferentes riscos que podem ser descritos e
medidos. (ZAMITH, 2007)
Segundo o mesmo autor, durante esta função, todos os riscos são

escritos com o formato de duas partes na qual a primeira é a declaração do risco,
escrito como uma declaração consistente, clara e que contém as informações para a
melhor compreensão da causa, da preocupação e do seu impacto. Já a segunda parte
inclui outros detalhes de apoio na forma de um contexto.
Existem muitos métodos para a identificação de riscos. Dentre eles,

temos: checklist, comparação análoga, análise de premissas, entrevista com
especialistas, fatores de risco e técnicas Delphi. Estes métodos citados são os que
podem ser aplicados a todas as saídas do projeto que são o custo, esforço, prazo e
qualidade.
O MPS.BR visa o aumento da qualidade dos processos de

desenvolvimento de software em organizações que não possuem tantos recursos para
investimento em qualidade. Este modelo não define novos conceitos, mas adequam
as estratégias de implementação à realidade brasileira, sendo que o nível C abrange
a gerência de risco. (WEBBER, ARAÚJO, et al., 2004)
Para o CMMI, a identificação de potenciais situações que poderiam

afetar negativamente o projeto é a base para a gerência de risco bem-sucedida. O
uso de categorias e parâmetros desenvolvidos na estratégia de gerenciamento dos
riscos, juntamente com as fontes identificadas de risco, pode fornecer disciplina e
otimização apropriadas à identificação do risco. (TEAM, 2002) (MACEDO, 2015).
Gerenciamento de riscos
Segundo Kerzner (2009), é importante determinar uma estratégia de

gerenciamento de riscos no início de um projeto, e que esse risco seja constantemente
57
abordado ao longo do ciclo de vida do projeto. O gerenciamento de riscos compreende
várias ações relacionadas aos riscos: planejamento, identificação, análise, resposta
(tratamento), e por fim, monitoramento e controle.
Segundo o PMI (2013, p. 309), o gerenciamento dos riscos do projeto,

tem o objetivo de “aumentar a probabilidade e o impacto dos eventos positivos e
reduzir a probabilidade e o impacto dos eventos negativos no projeto”.
A seguir, a Tabela 4 especifica os processos do Gerenciamento de

riscos:
Tabela 4 – Processos do Gerenciamento de Riscos
Planejar o Gerenciamento de Riscos: O processo de desenvolvimento e

documentação de uma estratégia eficiente e métodos para conduzir e lidar
com o Gerenciamento de riscos.
Identificar os Riscos: O processo de análise das áreas do projeto e de cada
processo técnico crítico, a fim de identificar e documentar os riscos
associados.
Realizar Análise de Risco: O processo de análise dos riscos identificados,
para estimar a probabilidade e o impacto no projeto. Inclui análise de risco
qualitativa e análise de risco quantitativa.
Planejar Resposta ao Risco: O processo que identifica, avalia, seleciona e
implementa uma ou mais estratégias para definir o risco em níveis aceitáveis,
de acordo com as restrições e objetivos do projeto.
Monitorar e Controlar Riscos: O processo que rastreia e avalia
constantemente o desempenho das ações de resposta a riscos e fornece
inputs para atualizar as estratégias de respostas aos riscos.
Fonte: Elaborado pelos autores a partir de Kerzner (2009)
Analisando os processos do Gerenciamento de riscos descritos na
Tabela 4, é possível concluir que cada um dos processos deve ser executado com
eficiência e comprometimento por parte da equipe de projetos, pois se um processo
contiver falhas ou apresentar conclusões inconsistentes, isso torna o sucesso do
projeto cada vez mais difícil.
58
No entanto, para que um projeto de software seja bem gerenciado é
preciso que alguns parâmetros sejam analisados corretamente, como por exemplo: o
escopo do software, os riscos a serem considerados, os recursos necessários, as
tarefas que precisam ser realizadas, os indicadores que necessitam de
acompanhamento, os esforços e custos aplicados, além da sistemática a ser adotada.
(PRESSMAN, 2006)
Com base nesse cenário, a utilização de técnicas de previsão pode ser

fundamental para a construção de estimativas e previsões acerca dos fatores
relacionados ao gerenciamento dos riscos em projetos, pois a aplicação destas
técnicas visa auxiliar a tomada de decisão por parte dos gerentes de projeto.
Identificar as fontes de riscos
Outra prática necessária dentro da gestão de riscos é realizar de forma

contínua uma sondagem das fontes de incerteza, que podem ser: tecnológica,
ambiente, mercado, socio-humana (MONTEIRO, SUZANA e HERMANO, 2013). A
incerteza tecnológica depende da extensão na qual o projeto usa nova tecnologia ou
tecnologia madura. A incerteza de ambiente pode ser oriunda do ambiente externo ou
interno ao projeto. Fatores políticos, burocráticos, interesse pessoal, jogo de poder
impactam nas incertezas no contexto ambiental do projeto. A incerteza de mercado
estar relacionada às incertezas dos usuários, do comportamento dos clientes, da
economia e a incerteza socio-humana leva em consideração as relações entre as
pessoas de uma organização. (MARINHO e MOURA, 2017).
Metodologia
A pesquisa está dividida em três etapas: a primeira etapa consiste em uma

pesquisa exploratória para identificar os fatores, motivos e vantagens acerca da
59
aplicação da Simulação de Monte Carlo (SMC) no gerenciamento de riscos em
projetos, ressaltando a sua importância para analisar a viabilidade e obter estimativas
válidas dentro do cenário simulado.
Segundo Gil (2002), as pesquisas exploratórias têm como objetivo

“proporcionar maior familiaridade com o problema, com vistas a torná-lo mais explícito
ou a constituir hipóteses”. O autor afirma que, mesmo que o planejamento da pesquisa
exploratória seja altamente flexível, na maioria dos casos, ela assume a forma de
pesquisa bibliográfica ou de estudo de caso.
A segunda etapa baseia-se na elaboração de um Diagrama de Ishikawa

(também conhecido como Diagrama de Causa e Efeito ou Diagrama de Espinha de
Peixe), com base nos fatores levantados na pesquisa exploratória, a fim de
proporcionar uma análise eficiente do conhecimento apresentado. Neste tipo de
diagrama, as causas ou fatores são representados por setas que contribuem para o
efeito (problema) a ser analisado. As causas ou fatores complexos podem ser
decompostos em detalhes (causas primárias e causas secundárias), sem prejudicar a
visão de conjunto (DAYCHOUM, 2007). Dessa forma, o gerenciamento será
direcionado a um controle mais eficiente, em relação ao processo como um todo.
Assim, ao fragmentar o processo em processos menores, torna-se mais fácil
identificar um problema e atuar diretamente sobre sua causa. (BARRETO e LOPES,
2005)
A terceira e última etapa, consiste na aplicação da SMC no cronograma

de um projeto de software, a fim de propor uma análise dos resultados para avaliar as
estimativas e chegar a uma conclusão acerca do modelo simulado. Para consolidar a
aplicação da SMC, foram estabelecidos 3 cenários de duração para cada etapa do
projeto: Realista, Otimista (10% maior que a Realista) e pessimista (10% menor que
a Realista). Esses cenários foram empregados, para sustentar as incertezas acerca
do projeto, sendo determinantes para a viabilidade e o sucesso do mesmo.
A aplicação da simulação decorreu para proporcionar a análise

quantitativa dos dados através de um estudo de caso, relacionado a um fenômeno
passado ou atual, estruturada com base em múltiplas fontes. Os dados foram
60
dispostos em planilhas do Excel2016 e, por meio de análise, os riscos foram
identificados para a aplicação da Simulação Monte Carlo.
As fases para realização da simulação no presente trabalho seguiram o

esquema representado na Figura 14 a seguir.
Figura 14 – Fases no estudo de uma simulação
Fonte: Elaborado pelos autores a partir de Law e Kelton (1991)
Análise qualitativa dos riscos
É o processo que, através da análise dos riscos, estima a probabilidade

de ocorrência e o grau de impacto. A análise deve identificar os riscos, probabilidades
e atitudes de cada uma das partes interessadas em relação a eles. A realização desse
processo é frequentemente a maneira mais rápida e econômica de planejar as
respostas aos riscos (PMI, 2004).
Os riscos são analisados basicamente através da probabilidade e

impacto. A probabilidade é a possibilidade de ocorrência, que é a razão do número de
chances pela qual um evento de risco pode acontecer (ou não acontecer) pela soma
das chances do acontecimento (ou não acontecimento). O impacto pode ser positivo
ou negativo nos objetivos planejados dependendo do evento. A análise de impacto
61
inclui a quantificação de suas respectivas severidades de impacto, probabilidade e
sensibilidade de mudanças (Charette, 2005, Schuyler, 2001).
O processo de análise qualitativa de riscos avalia a probabilidade e o

grau de impacto dos riscos identificados segundo a Tabela 5, que é a matriz de
probabilidade e grau de impacto, que é um jeito usual de se determinarem os riscos
que devem ser tratados ou não, considerando as duas variáveis da tabela.
Tabela 5 – Matriz de probabilidade e grau de impacto
Fonte: PMI(2004)
As categorias da probabilidade são divididas entre: Remota, Baixa,

Média, Alta e Muito Alta, e do grau de impacto são divididos entre: Muito Baixo, Baixo,
Médio, Alto e Muito Alto.
Com base na Tabela 5, determina-se qual é a estratégia mais indicada

para o planejamento do gerenciamento dos riscos segundo seu grau de impacto e
probabilidade nos objetivos do projeto. Depois, são selecionadas as categorias que
deverão ter os fatores de riscos mitigados, quais deverão ter os fatores de risco
evitados e quais serão aceitos (Martins, 2010).
Os riscos e as estratégias na avaliação qualitativa de riscos são usados

para o processo de planejamento de respostas aos riscos, no qual serão constituídas
ações preventivas ou corretivas.
62
O controle de riscos é bastante flexível, permitindo vários jeitos de ações.
Segundo Kerzner (2006), existem três categorias de atitudes a serem tomadas no
controle de riscos:
• Aceitar o Risco: O risco está identificado, sabe-se da sua

consequência e probabilidade, mas não é realizada nenhuma medida
preventiva e/ou corretiva, pois o custo das medidas é maior que o benefício que
delas resultam.
• Mitigar o risco: Procura reduzir a consequência do risco. Realizar

ações preventivas e/ou corretivas para reduzir o impacto no projeto é mais
eficaz que tentar reparar as consequências depois de ocorrido o problema.
• Evitar o risco: É mudar a forma do desenvolvimento da atividade,

usando medidas preventivas e/ou corretivas para eliminar o risco ou a condição
ou para proteger os objetivos da atividade desses perigos. Embora não seja
possível eliminar todos os eventos de risco, alguns riscos específicos podem
ser evitados.
Tipos de riscos
Para compreender esses riscos é essencial para um gerenciamento eficaz e

para garantir o sucesso dos projetos. Vamos examinar alguns dos principais tipos de
riscos em projetos de software e discutir suas características distintas.
1. Requisitos do projeto mal-entendidos: Esse risco se dá

quando, após o cliente explicar o requisito do projeto, os membros da equipe
não entendem o que o cliente realmente queria. A orientação é mitigar,
segundo a matriz de probabilidade e grau de impacto, pois a chance de
probabilidade é média e o grau e impacto é médio. Ação corretiva para este
risco é validação junto ao cliente obre os requisitos, o responsável é da equipe
63
envolvida com o projeto. As ações preventivas são reunião com o cliente para
melhorar entendimento – a responsável é a equipe envolvida com o projeto – e
elaboração de protótipos para validação junto ao usuário – o responsável é a
equipe envolvida com o projeto.
2. Introdução de Nova tecnologia: Esse risco se dá quando uma

tecnologia é dotada durante o projeto. A orientação é mitigar, segundo a matriz
de probabilidade e grau de impacto, pois a chance de probabilidade é média e
o grau de impacto é médio. A ação corretiva para este risco é treinamento para
a equipe sobre o assunto novo – o responsável é o gerente de projeto. A ação
preventiva é atribuir papéis e responsabilidades para os membros da equipe –
o responsável é o gerente de projeto.
3. Mudança de membros da equipe: Esse risco se dá quando

algum membro da equipe sai do projeto ou alguma pessoa é contratada para
entrar no projeto. A orientação é aceitar, segundo a matriz de probabilidade e
grau de impacto, pois a chance de probabilidade é baixa e o grau de impacto é
médio. Não possui ações preventivas e corretivas.
4. Cronograma fora da realidade: Esse risco ocorre quando o

cronograma do projeto extrapola o cronograma real do projeto. A orientação é
mitigar, segundo a matriz de probabilidade e grau de impacto, pois a chance
de probabilidade é alta e o grau de impacto é médio. A ação corretiva é possuir
uma base sobre cronogramas de projetos anteriores – a responsável é a equipe
envolvida com o projeto. A ação preventiva é estabelecer um procedimento
para estimar prazo e custo dos projetos – o responsável é o gerente de projeto.
5. Criação de requisitos pela equipe de desenvolvimento:

Adicionar funcionalidades no projeto que não foram solicitadas pelo cliente. A
orientação é aceitar, segundo a matriz de probabilidade e grau de impacto, pois
a chance de probabilidade é média e o grau de impacto é baixo. Não possui
ações preventivas e corretivas.
6. Desenvolvimento errado dos requisitos: O desenvolvimento do

requisito não é de acordo com o que o cliente queria. A orientação é evitar,
64
segundo Revista Eletrônica Sistemas & Gestão a matriz de probabilidade e
grau de impacto, pois a chance de probabilidade é média e o grau de impacto
é muito alto. A ação corretiva é marcar reunião diária com os membros
envolvidos do projeto – a responsável é a equipe. A ação preventiva é garantir
que a comunicação entre a equipe está boa– o responsável é o gerente de
projeto.
7. Falha de comprometimento do cliente: Esse risco ocorre

quando o cliente não está comprometido com o projeto, por exemplo, falta de
reuniões com a equipe. A orientação é aceitar, segundo a matriz de
probabilidade e grau de impacto, pois a chance de probabilidade é remota e o
grau de impacto é médio. Não possui ações preventivas e corretivas.
8. Falta de motivação da equipe: A equipe não tem motivação

durante o projeto. A orientação é aceitar, segundo a matriz de probabilidade e
grau de impacto, pois a chance de probabilidade é baixa e o grau de impacto é
médio. Não possui ações preventivas e corretivas.
9. Pessoal insuficiente: A quantidade de pessoas na equipe não é

suficiente para o projeto. A orientação é mitigar, segundo a matriz de
probabilidade e grau de impacto, pois a chance de probabilidade é baixa e o
grau de impacto é muito alto. Ação corretiva é atribuir mais funções para cada
pessoa do projeto – o responsável é o gerente de projeto. A ação preventiva é
contratar mais pessoas para a equipe do projeto – o responsável é o gerente
do projeto.
10. Sem definição de função dos membros da equipe: As pessoas

do projeto não possuem funções definidas. A orientação é aceitar, segundo a
matriz de probabilidade e grau de impacto, pois a chance de probabilidade é
média e o grau de impacto é baixo. Não possui ações preventivas e corretivas.
11. Mudança de requisito: Esse risco se dá quando a equipe

desenvolve um requisito e este muda o seu entendimento ou não é mais
necessário ser adotado no projeto. A orientação é evitar, segundo a matriz de
probabilidade e grau de impacto, pois a chance de probabilidade é muito alta e
65
o grau de impacto é alto. A ação corretiva é usar os métodos ágeis para o
desenvolvimento do projeto – o responsável é o gerente do projeto. As ações
preventivas são reunião entre a equipe do projeto e o cliente, definir de pronto
o requisito e validação com o cliente após o término de um requisito. Os
responsáveis pelas ações preventivas são o gerente de projeto e a equipe.
12. Falta de Cooperação dos usuários: Os usuários não cooperam

com o projeto, por exemplo, não fazem testes para poder avaliar se está certo
ou não os requisitos desenvolvidos. A orientação é aceitar, segundo a matriz
de probabilidade e grau de impacto, pois a chance de probabilidade é baixa e
o grau de impacto é médio. Não possui ações preventivas e corretivas.
13. Falta de metodologia efetiva para o gerenciamento do

projeto: Nos dois projetos, não consta uma metodologia definida para o
gerenciamento de projeto. A orientação é mitigar, segundo a matriz de
probabilidade e grau de impacto, pois a chance de probabilidade é média e o
grau de impacto é alto. A ação corretiva é definir a metodologia que será
realizada durante o projeto – o responsável é o gerente de projeto. A ação
preventiva é definir no começo do projeto, qual metodologia será adotada até
o final – o responsável é a equipe envolvida como o projeto.
14. Falta de habilidade na gerência do projeto: O gerente de

projeto não tem habilidade para exerce a função na gerência. A orientação é
de probabilidade é média e o grau de impacto é alto. A ação corretiva é
treinamento para o gerente de projeto. A ação preventiva é definir a pessoa da
equipe que possui maior habilidade para ser o gerente do projeto – a
responsável é a equipe envolvida com o projeto.
15. Ferramentas impróprias para o desenvolvimento: No

desenvolvimento do projeto, a equipe utiliza ferramentas que não precisam
realmente ser utilizadas. A orientação é aceitar, segundo a matriz de
probabilidade e grau de impacto, pois a chance de probabilidade é remota e o
66
16. Componentes do projeto desenvolvidos externamente:
Componentes do projeto não foram desenvolvidos pela equipe envolvida com
o projeto. A orientação é aceitar, segundo a matriz de probabilidade e grau de
impacto, pois a chance de probabilidade é baixa e o grau de impacto é baixo.
Não possui ações preventivas e corretivas
17. Custo mal estimado: O custo do projeto no início não é o

realmente o preço real. A orientação é aceitar, segundo a matriz de
probabilidade e grau de impacto, pois a chance de probabilidade é média e o
grau de impacto é baixo. Não possui ações preventivas e corretivas.
18. Quebra de Equipamento: Quando um equipamento no ambiente

da equipe quebra ou danifica ou para de funcionar. A orientação é mitigar,
probabilidade é baixa e o grau de impacto é muito alto. A ação corretiva é
reparar o equipamento ou comprar um novo – o responsável é o gerente do
projeto. A ação preventiva é realizar manutenção dos equipamentos
esporadicamente – o responsável é o gerente do projeto.
19. Erros de Digitação: Esse risco é quando alguma funcionalidade

contém erros de ortografia. A orientação é aceitar, segundo a matriz de
20. Cliente insatisfeito com o produto: Após a equipe mostrar para

o cliente o produto após ser desenvolvido, o cliente não fica satisfeito com o
trabalho da equipe. A orientação é evitar, segundo a matriz de probabilidade e
é muito alto. A ação corretiva é negociar solução com o cliente – os
responsáveis são a equipe envolvida com o projeto e o cliente. A ação
preventiva é participação do cliente durante todo o projeto – os responsáveis
são a equipe envolvida com o projeto e o cliente.
21. Perda de dados do documento de requisitos: Esse risco se dá

quando o documento de requisitos do projeto perde alguns dados para o
67
desenvolvimento do projeto. A orientação é mitigar, segundo a matriz de
grau de impacto é muito alto. A ação corretiva é realizar nova reunião com o
cliente para recuperar os dados perdidos – a responsável é a equipe envolvida
com o projeto. A ação preventiva é realizar back-up do documento de requisitos
– a responsável é a equipe envolvida com o projeto.
22. Falta de realização de testes durante o desenvolvimento do

projeto: No projeto, não consta a realização de testes durante o seu
desenvolvimento. A orientação é mitigar, segundo a matriz de probabilidade e
é alto. As ações corretivas são realizar treinamento de testes para a equipe e
inserir alguma metodologia que usa testes para a validação das funções
desenvolvidas. A responsável pelas ações corretivas é a equipe envolvida com
o projeto. A ação preventiva é definir a fase de realização de testes no
planejamento do projeto – o responsável é a equipe envolvida com o projeto.
23. Crescimento de requisitos não previstos: Os requisitos que

não foram previstos durante o início do projeto, aparecem ao decorrer do
projeto. A orientação é aceitar, segundo a matriz de probabilidade e grau de
impacto, pois a chance de probabilidade é baixa e o grau de impacto é médio.
Não possui ações preventivas e corretivas.
24. Entrega prematura do produto: A equipe entrega para o cliente

o produto incompleto, faltando algumas funcionalidades. A orientação é mitigar,
probabilidade é remota e o grau de impacto é muito alto. As ações corretivas
são definir junto ao cliente a definição de pronto do requisito e verificar junto ao
cliente se o requisito está pronto. A responsável pelas ações corretivas é a
equipe envolvida com o projeto e o cliente. A ação preventiva é definir os
requisitos essências do produto – os responsáveis são a equipe envolvida com
o projeto e o cliente.
25. Atrito entre os desenvolvedores: Esse risco ocorre quando os

desenvolvedores discutem entre si ou não tem afinidade uns com os outros. A
68
orientação é aceitar, segundo a matriz de probabilidade e grau de impacto, pois
a chance de probabilidade é remota e o grau de impacto é baixo. Não possui
ações preventivas e corretivas.
26. Mudança do ambiente do desenvolvimento do projeto: Esse

risco é quando a equipe muda o local de trabalho. A orientação é aceitar,
probabilidade é remota e o grau de impacto é médio. Não possui ações
preventivas e corretivas.
27. Desenvolvimento com baixa qualidade: Funcionalidades do

projeto não são desenvolvidas com qualidade. A orientação é mitigar, segundo
a matriz de probabilidade e grau de impacto, pois a chance de probabilidade é
baixo e o grau de impacto é alto. As ações corretivas são realizar novamente o
requisito e inspecionar o requisito que está sendo implementado para verificar
se não está com baixa qualidade. A responsável pelas ações corretivas é a
equipe envolvida com o projeto. A ação preventiva é definir um número máximo
de requisitos que um membro da equipe possa desenvolver em um tempo – a
responsável é a equipe envolvida com o projeto.
28. Ignorar o risco presente no projeto: Esse risco se dá quando a

equipe ignora o risco presente no projeto, não tratando ele. A orientação é
de probabilidade é remota e o grau de impacto é alto. A ação corretiva é
verificar se o risco tem um impacto que prejudica o projeto. Caso tenha, deve
ser realizada uma análise nesse risco. A responsável pela ação corretiva é a
equipe envolvida com o projeto. A ação preventiva é definir o gerenciamento
de risco no planejamento do projeto, sendo responsável a equipe envolvida
com o projeto.
29. Conflitos de versões do produto: Esse risco ocorre quando uma

versão do produto não é compatível com algumas funcionalidades do produto
mais atualizado. A orientação é evitar, segundo a matriz de probabilidade e
grau de impacto, pois a chance de probabilidade é alta e o grau de impacto é
alto. A ação corretiva é padronizar as versões do produto – a responsável é a
69
equipe envolvida com o projeto. A ação preventiva é possuir um controle de
versões do produto que está sendo desenvolvido – a responsável é a equipe
envolvida com o projeto.
(MACEDO, 2015)
70
CONSIDERAÇÕES FINAIS
Alan: Com tudo isso, foi possível observar que o gerenciamento de projetos de
software inclui as diversas atividades do projeto, junto com o planejamento, a
programação e o gerenciamento de riscos do projeto, em que todas essas partes
devem ser trabalhadas de forma comunicativa e estratégica. Para a construção
eficiente e eficaz de um software de qualidade, dentro dos prazos e custos esperados,
que atenda às necessidades do cliente e do mercado.
Alexandre: Após o que foi mostrado é capaz de perceber a importância de um bom

gerenciamento de projetos de software que serve como uma estrutura e base para o
projeto, garantindo a eficiência e qualidade. Há diversos fatores que são importantes
para se ter um bom gerenciamento de projetos de software como a comunicação, uma
boa liderança, etc. que foram abordados mais acima. Para completar é possível ver
que essa é uma área que está se desenvolvendo bastante atualmente o que requer
um bom investimento para que seja possível extrair o máximo de desempenho em
seu projeto.
Allan: O gerenciamento de projeto de software é um processo complexo que demanda

tempo e esforços necessários para a criação de um produto cujo principal objetivo é
alcançar a maior qualidade possível. Portanto, não é novidade ressaltar que cada uma
de suas etapas (atividades, planejamento, programação, gerenciamento de riscos)
cumprem um papel necessário para que o software seja satisfatório para o cliente para
o qual foi projetado.
André: O estudo abrangente sobre gerenciamento de projetos de software enfocou

aspectos cruciais como planejamento, gerenciamento de risco, programação e
atividades. O planejamento foi identificado como a base sólida para o sucesso do
projeto, permitindo estabelecer metas claras, alocar recursos de maneira adequada e
definir etapas bem estruturadas. Juntamente com isso, o gerenciamento de risco
desempenhou um papel crucial na identificação e mitigação de incertezas, preparando
a equipe para enfrentar desafios e imprevistos ao longo do desenvolvimento do
71
software. Além disso, a programação e o gerenciamento eficiente das atividades
foram destacados como elementos-chave para a execução bem-sucedida do projeto,
garantindo uma distribuição equilibrada das tarefas e permitindo o acompanhamento
contínuo do progresso, o que possibilitou a identificação precoce de problemas e a
tomada de ações corretivas. Em conjunto, esses conteúdos essenciais reforçam a
importância crítica do gerenciamento de projetos de software para alcançar resultados
de alta qualidade e sucesso na área de desenvolvimento de software.
João: O gerenciamento de softwares é crucial para a produção eficiente de programas

e aplicativos, evidenciando sua abrangência. Com uma abordagem estratégica,
equipes de desenvolvimento podem otimizar recursos, minimizar riscos e se adaptar
rapidamente às mudanças do mercado. Além disso, o gerenciamento assegura a
qualidade do produto, a satisfação do cliente e envolve habilidades de liderança,
comunicação e planejamento estratégico. Investir nessa área é essencial para o
sucesso e competitividade das organizações na era digital.
72
REFERÊNCIAS
ANA. Contagem de pontos de função, 2017. Disponível em:

<https://www.devmedia.com.br/contagem-de-pontos-de-funcao/34390>. Acesso em:
06 jul. 2023. Às 21:59.
BARRETO, J.; LOPES, L. F. Análise de falhas no processo logístico devido á falta

de um controle de qualidade. 2005. 25 f.Dissertação - PPGEP – Programa de Pós-
Graduação de Engenharia de Produção, Universidade Federal de Santa Catarina,
Florianópolis, 2005 Disponível em:
<https://producaoonline.org.br/rpo/article/view/331/427>. Acesso em: 13 jul. 2023. Às
11:45.
CHARETTE, R. Why software fails. 9ª. ed. [S.l.]: IEEE Spectrum, v. 42, 2005. 42-49
p.
EXTREME PROGRAMMING: o que é e como funciona?. Stydle, 2023. Disponível

em: <https://www.sydle.com/br/blog/extreme-programming>. Acesso em: 18 jul.
2023. Às 16:33.
FERREIRA, A. O que é Scrum?, 2019. Disponível em: <https://k21.global/br/blog/o-

que-e-scrum?>. Acesso em: 18 jul. 2023. Às 10:01.
GERÊNCIA E QUALIDADE DE SOFTWARE - Aula 11 - Gerência de projetos de

software. [S. l.: s. n], 2018. 1 vídeo (24 min). Publicado pelo canal UNIVESP.
Disponível em: <https://youtu.be/X8nWReaZSXI>. Acesso em: 16 jul. 2023. Às
16:48.
GERENCIAMENTO DE PROJETOS DE SOFTWARE. Tutorialspoint, 2014.

Disponível em:
<https://www.tutorialspoint.com/pg/software_engineering/software_project_managem
ent.htm#>. Acesso em: 04 jul. 2023. Às 14:27.
GIL, A. C. Como elaborar projetos de pesquisa. 4ª. ed. São Paulo: Atlas, 2002.
HENRIQUE, P.; RODRIGUES, F. GERENCIAMENTO DOS RISCOS EM

PROJETOS DE SOFTWARE: UMA APLICAÇÃO DA SIMULAÇÃO DE MONTE
CARLO NO CRONOGRAMA DE UM PROJETO. 2016.19 f.Dissertação - Faculdade
de Tecnologia de Taquaritinga, 2016 Disponível em:
<https://revista.fatectq.edu.br/interfacetecnologica/article/view/135/117>. Acesso em:
13 jul. 2023. Às 09:23.
HIGOR. Modelos de processos ágeis: conceitos e princípios, 2014. Disponível em:

<https://www.devmedia.com.br/modelos-de-processos-ageis-conceitos-e-
principios/30059>. Acesso em: 17 jul. 2023. Às 20:54.
73
KELTON, W. D.; SADOWSKI, R. P.; STURROCK, D. T. Simulation with ARENA. 3ª.
ed. New York: McGraw-Hill, 2004.
KERZNER, H. R. Project Management: A Systems Approach to Planning,

Scheduling, and Controlling. 10ª. ed. Hoboken, Nova Jersey: John Wiley & Sons Inc,
2009.
KLOC. Wikipédia, 2018. Disponível em: <https://pt.wikipedia.org/wiki/Kloc> Acesso

em: 04 jul. 2023. Às 21:32.
KWAK, Y.; STODDARDB, J. Project risk management: lessons learned from

software development environment. 11ª. ed. [S.l.]: Technovation, v. 24, 2004. 915-
920 p.
MACEDO, M. H. B. GERENCIAMENTO DE RISCO APLICADO AO

DESENVOLVIMENTO DE SOFTWARE. 2015.13 f.Dissertação - Universidade
Federal de Alfenas, Alfenas, 2015 Disponível em:
<https://www.revistasg.uff.br/sg/article/view/V10N1A13/SGV10N1A13>. Acesso em:
13 jul. 2023. Às 14:12.
MARINHO, M. L. M.; MOURA, H. P. D. M. Gerenciamento das Incertezas em

Projetos de Software. 2017.7 f.Dissertação - Centro de Informática, Universidade
Federal Rural de Pernambuco (UFRPE), Pernambuco, 2017 Disponível em:
<https://reer.emnuvens.com.br/reer/article/download/148/49>. Acesso em: 13 jul.
2023. Às 15:21.
MARQUES, J. Método DELPHI: caracterização e potencialidades na pesquisa em

educação, 2018. Disponível em:
<https://www.scielo.br/j/pp/a/MGG8gKTQGhrH7czngNFQ5ZL/?lang=pt>. Acesso em:
18 jul. 2023. Às 21:29.
MÉTODOS DE ESTIMATIVA PARA PROJETOS DE SOFTWARE. Micreiros.com,

2011. Disponível em: <https://micreiros.com/metodos-de-estimativas-para-projetos-
de-software/>. Acesso em: 18 jul. 2023. Às 18:26.
MONTEIRO, M. M. L.; SUZANA, S.; HERMANO, M. An Approach Related to

Uncertainty in Software Projects. Proceedings of the 2013 IEEE International
Conference on Systems, Man, and Cybernetics. [S.l.: s.n.]. 2013. p. 894-899.
O QUE É ANÁLISE DE PONTOS DE FUNÇÃO, OBJETIVOS E REFERÊNCIAS.

Fattocs, 2020. Disponível em: <https://www.fattocs.com/blog/o-que-a-analise-de-
pontos-de-funcao-quais-seus-objetivos-e-referencias/>. Acesso em: 18 jul. 2023.
O QUE É EXTREME PROGRAMMING. [S. l.: s. n], 2022. 1 vídeo (8 min). Publicado
pelo canal Celso Kitamura. Disponível em: <https://youtu.be/oicEg7xHy-I>. Acesso
em: 18 jul. 2023. Às 17:05.
O QUE É GESTÃO ÁGIL DE PROJETOS? #Scrum #Kanban #Agile #Sprint. [S. l.: s.
n], 2021. 1 vídeo (15 min). Publicado pelo canal Mario Trentim - Gestão &
74
Tecnologia. Disponível em: <https://youtu.be/Ipjxv5uU1R8>. Acesso em: 16 jul.
2023. Às 18:13.
PLANEJAMENTO DE PROJETOS: entenda como funciona na prática, suas etapas e

importância!. Pontoel, 2023. Disponível em:
<https://www.pontotel.com.br/planejamento-de-projetos/>. Acesso em: 16 jul. 2023.
Às 14:25.
PMI. Um guia do conhecimento em gerenciamento de projetos (Guia PMBOK). 5ª.

ed. [S.l.]: Project Management Institute, 2013.
PMI. Um guia do conjunto de conhecimentos em gerenciamento de projetos. 3ª. ed.

[S.l.]: Project Management Intitute, 2004.
PRESSMAN, R. Engenharia de software: uma abordagem profissional. 8ª. ed. Porto

Alegre: AMGH, 2016.
PRESSMAN, R. S. Engenharia de Software. 6ª. ed. Rio de Janeiro: McGraw-Hill,

2006.
PROJETOS DE PROGRAMAÇÃO - Organize qualquer projeto. [S. l.: s. n], 2021. 1

vídeo (12 min). Publicado pelo canal Dev Aprender | Jhonatan de Souza. Disponível
em: <https://youtu.be/0kIIVz3ZD6U>. Acesso em: 17 jul. 2023. Às 14:25
SCHUYLER, J. Risk and decision analysis in projects. 2ª. ed. Newtown Square,
USA: [s.n.], 2001.
SOMMERVILLE, Ian. Engenharia de software. Tradução: Kalinka O; Ivan B. 9ª. ed.

São Paulo: Pearson Education, 2011.
TEAM, C. P. CMMI for Systems Engineering, Software Engineering, Integrated

Product and Process Development, and Supplier Sourcing (CMMI-SE/SW/IPPD/SS,
V1.1). [S.l.]: Capability Maturity Model Integration (CMMI SM) Version 1.1, 2002.
WEBBER, K. C. et al. Modelo de referência e método de avaliação para melhora de

processo de software. [S.l.]: IV Simpósio Brasileiro de Qualidade de Software, 2004.
ZAMITH, J. Gestão de riscos e prevenção de perdas: um novo paradigma para a

segurança nas organizações. 1ª. ed. Rio de Janeiro: FGV, 2007. 112 p.
75

Gerenciamento de Projetos de Software - Uma Analise Geral

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Gerenciamento de Projetos de Software - Uma Analise Geral

Enviado por

Direitos autorais:

Formatos disponíveis

ETEC DE SÃO PAULO

Alan Ono Osanai Pan

Alexandre Vinícius Ascencio Arteaga

Allan Alves Sallum

André Fábian Calle Huanca

João Henrique Queiroz Simões

Atividade, planejamento, programação e gerenciamento de riscos

Alexandre Vinícius Ascencio Arteaga

Allan Alves Sallum

André Fábian Calle Huanca

João Henrique Queiroz Simões

GERENCIAMENTO DE PROJETOS DE SOFTWARE

Atividade, planejamento, programação e gerenciamento de riscos

Trabalho sobre Gerenciamento de Projetos

Orientador: Prof. Luiz Ricardo de Souza

Mas para compreender melhor, é necessário entender. O que é um projeto de

Para fazer um bom gerenciamento de projetos de software, é necessário seguir

Nessa indústria, o papel de um gerente é de extrema importância, pois ele

Um processo de software é um conjunto de atividades relacionadas que levam

Existem muitos processos de software diferentes, mas todos devem incluir

1. Especificação de software. A funcionalidade do software e as restrições a

2. Projeto e implementação de software. O software deve ser produzido para

3. Validação de software. O software deve ser validado para garantir que

4. Evolução de software. O software deve evoluir para atender às necessidades

De alguma forma, essas atividades fazem parte de todos os processos de

1. Produtos, que são os resultados de uma das atividades do processo. Por

2. Papéis, que refletem as responsabilidades das pessoas envolvidas no

3. Pré e pós-condições, que são declarações verdadeiras antes e depois de

Os processos de software são complexos e, como todos os processos

Os processos de software, às vezes, são categorizados como dirigidos a planos

Embora não exista um processo ‘ideal’ de software, há espaço, em muitas

Em organizações nas quais a diversidade de processos de software é reduzida,

Modelos de processos de software

Como explicado anteriormente, um modelo de processo de software é uma

Esses modelos genéricos não são descrições definitivas dos processos de

Os modelos de processos que abordo aqui são:

1. O modelo em cascata. Esse modelo considera as atividades fundamentais

2. Desenvolvimento incremental. Essa abordagem intercala as atividades de

3. Engenharia de software orientada a reuso. Essa abordagem é baseada na

Os principais estágios do modelo em cascata refletem diretamente as

1. Análise e definição de requisitos. Os serviços, restrições e metas do sistema

2. Projeto de sistema e software. O processo de projeto de sistemas aloca os

3. Implementação e teste unitário. Durante esse estágio, o projeto do software

5. Operação e manutenção. Normalmente (embora não necessariamente),

Em princípio, o resultado de cada estágio é a aprovação de um ou mais

Por causa dos custos de produção e aprovação de documentos, as iterações

Durante o estágio final do ciclo de vida (operação e manutenção), o software é

O modelo em cascata é consistente com outros modelos de processos de

Em princípio, o modelo em cascata deve ser usado apenas quando os

Uma variação importante do modelo em cascata é o desenvolvimento formal

Processos baseados em transformações formais são geralmente usados

O desenvolvimento incremental é baseado na ideia de desenvolver uma

Desenvolvimento incremental de software, que é uma parte fundamental das

O desenvolvimento incremental tem três vantagens importantes quando

1. O custo de acomodar as mudanças nos requisitos do cliente é reduzido. A

3. É possível obter entrega e implementação rápida de um software útil ao

Do ponto de vista do gerenciamento, a abordagem incremental tem dois

1. O processo não é visível. Os gerentes precisam de entregas regulares para

2. A estrutura do sistema tende a se degradar com a adição dos novos

Os problemas do desenvolvimento incremental são particularmente críticos

Você pode desenvolver um sistema de forma incremental e expô-lo aos

Na maioria dos projetos de software, há algum reuso de software. Isso acontece