2. Gerente de Projetos
• Responsável pelo desenvolvimento de
planos e cronogramas do projeto;
• Supervisionam o trabalho para assegurar
que seguem os padrões estabelecidos;
• Monitoram o desenvolvimento para
verificar se está dentro do prazo e do
orçamento.
3. Projetos de SW
• Engenharia de Software é diferente das outras
engenharias:
– O produto é intangível – os gerentes de projeto não podem ver o
progresso e dependem de documentos e relatórios para isso;
– Não existem processos-padrão de software – em outras
engenharias clássicas, há processos bem compreendidos, ao
contrário do software;
– Muitos projetos de grande porte são “únicos” – a experiência de
um gerente de projetos sofre obsolescência ao longo do tempo.
4. Atividades
• Atividades do Gerenciamento de Projetos:
– Elaboração da proposta;
– Planejamento e desenvolvimento do
cronograma;
– Custo do projeto;
– Monitoração e revisões do projeto;
– Seleção e avaliação de pessoal;
– Elaboração de relatórios e apresentações.
5. Sumário
1. Gerenciamento de Riscos
2. Gerenciamento de Pessoas
3. Planejamento de Projeto
4. Estimativa de Tamanho
5. Estimativa de Recursos
6. Cronograma do Projeto
7. Monitoração e Controle de Projetos
8. Gerenciamento da Qualidade
7. 1. Gerenciamento de Riscos
• O gerenciamento de riscos está sendo
considerado, cada vez mais, como uma das
principais atividades dos gerentes de projeto;
• Consiste em prever os riscos que podem afetar o
cronograma do projeto ou a qualidade do software
que está sendo desenvolvido;
• Consiste também em tomar providências para
evitar e mitigar riscos;
• De maneira simplificado, risco é algo que seria
preferível não ocorrer.
8. 1. Gerenciamento de Riscos
• Categorias de riscos:
– Riscos de projeto – afetam o cronograma ou os
recursos do projeto;
• Ex: perda de um projetista experiente.
– Riscos de produto – afetam a qualidade ou o
desempenho do software;
• Ex: componente comprado não funciona como esperado.
– Riscos de negócio – afetam a organização que
desenvolve ou adquire o software;
• Ex: concorrente lança um produto semelhante.
9. Risco Categoria Descrição
Rotatividade de pessoal Projeto Pessoal experiente deixará o projeto
antes do seu término.
Mudança de gerência Projeto Haverá uma mudança na gerência da
organização com diferentes prioridades.
Mudança de requisitos Projeto e produto Haverá um número maior de mudanças
de requisitos do que o previsto.
Tamanho subestimado Projeto e produto O tamanho do sistema foi subestimado.
Concorrência de produto Negócios Um produto concorrente foi lançado no
mercado antes da conclusão do sistema.
Possíveis riscos de software
10. 1.1. Identificação de Riscos
• Primeiro estágio do gerenciamento de
riscos;
• Os riscos não devem ser avaliados ou
priorizados ainda, apenas identificados;
• Deve ser realizada como um processo em
equipe, usando brainstorming;
• A experiência é muito importante.
11. 1.1. Identificação de Riscos
• Tipos de risco usados na identificação:
– Riscos de tecnologia – derivam de tecnologias de software ou hardware
usadas;
– Riscos de pessoal – associados às pessoas da equipe de desenvolvimento;
– Riscos organizacionais – derivam do ambiente organizacional;
– Riscos de ferramentas – derivam de ferramentas CASE e outros softwares
de apoio;
– Riscos de requisitos – derivam de mudanças de requisitos de cliente e do
processo de gerenciamento de mudanças de requisitos;
– Riscos de estimativas – derivam de estimativas de gerenciamento das
características de sistema e recursos necessário para construção.
12. Tipo de Risco Riscos Possíveis
Tecnologia O banco de dados usado no sistema não pode processar tantas
transações por segundo como esperado.
Os componentes de software que devem ser reusados contêm defeitos
que limitam sua funcionalidade.
Pessoal É impossível recrutar pessoal com as habilidades necessárias.
O pessoal mais qualificado está doente e não disponível nos momentos
críticos.
O treinamento necessário para o pessoal não está disponível.
Organizacional A organização é reestruturada, de modo que uma gerência diferente
tornou-se responsável pelo projeto.
Problemas financeiros da organização forçam reduções no orçamento
do projeto.
Ferramentas O código gerado pelas ferramentas CASE é ineficiente.
As ferramentas CASE não podem ser integradas.
Requisitos Mudanças de requisitos que requerem retrabalho maior de projeto são
propostas.
Os cliente não compreendem o impacto das mudanças de requisitos.
Estimativas O prazo necessário para desenvolver o software foi subestimado.
A taxa de reparo de defeitos foi subestimada.
O tamanho do software foi subestimado.
Riscos e tipos de risco
13. 1.2. Análise de Riscos
• Nessa etapa, deve-se fazer uma avaliação dos riscos identificados
quanto à sua probabilidade e gravidade;
• Probabilidade:
– Muito baixa: < 10%
– Baixa: 10-25%
– Média: 25-50%
– Alta: 50-75%
– Muito alta: > 75%
• Efeitos:
– Catastróficos
– Sérios
– Toleráveis
– Insignificantes
14. 1.2. Análise de Riscos
• Os riscos catastróficos sempre devem ser
considerados, assim como os riscos sérios que tenham
probabilidade acima da média;
• Recomenda-se identificar os “10 maiores riscos” do
projeto e monitorá-los;
• Esse número não é exato, mas deve ser gerenciável;
• Gerenciar riscos demais exige muitas informações e
pode aumentar o orçamento.
15. Risco Probabilidade Efeitos
Problemas financeiros da organização forçam
reduções no orçamento do projeto.
Baixa Catastróficos
É impossível recrutar pessoal com as habilidades
necessárias para o projeto.
Alta Catastróficos
O mais qualificado está doente nos momentos críticos
do projeto.
Média Sérios
O tempo necessário para desenvolver o software foi
subestimado.
Alta Sérios
O tamanho do software foi subestimado. Alta Toleráveis
A taxa de reparo de defeitos foi subestimada. Média Toleráveis
Análise de riscos
16. 1.3. Planejamento de Riscos
• Essa etapa define estratégia para tratar os riscos escolhidos
para serem gerenciados na análise;
• Essas estratégias se dividem em três categorias:
– Estratégias de prevenção – servem para diminuir a probabilidade
de ocorrência do risco;
– Estratégias de minimização – servem para reduzir o impacto do
risco;
– Planos de contingência – preparam para o pior e definem ações
para lidar com o problema.
17. Risco Estratégia
Problemas de recrutamento Alertar o cliente sobre as dificuldades potenciais e a
possibilidade de atrasos; investigar a compra de
componentes.
Doença do pessoal da
equipe
Reorganizar a equipe de maneira que haja mais
superposição de trabalho e, portanto, as pessoas
compreendam as tarefas uns dos outros.
Mudanças de requisitos Derivar informações de rastreabilidade para avaliar o
impacto das mudanças de requisitos e maximizar o
ocultamento de informações no projeto.
Prazo de desenvolvimento
subestimado
Verificar a compra de componentes e verificar o uso de um
gerador de programa.
Estratégias de gerenciamento de riscos
18. 1.4. Monitoração de Riscos
• O gerente deve avaliar cada um dos riscos
identificados para saber se o risco está ou
não se tornando mais ou menos provável e
se os efeitos mudaram;
• Para isso, deve-se observar fatores que
forneçam indícios;
• Essa monitoração deve ser um processo
contínuo, realizado no mínimo a cada
revisão de progresso.
20. 2. Gerenciamento de Pessoas
• As pessoas que trabalham em uma organização são
seus maiores ativos;
• Custa muito recrutar boas pessoas;
• Cabe aos gerentes atribuir responsabilidades às
pessoas condizentes com suas experiências e
habilidades;
• O respeito às pessoas garante o melhor retorno sobre
os investimentos;
• É importante conhecer as questões técnicas de um
projeto, mas nem sempre um bom engenheiro de
software é um bom gestor de pessoas.
21. 2. Gerenciamento de Pessoas
• Fatores críticos no gerenciamento de pessoas:
– Consistência: tratar as pessoas da mesma forma, por mais que o
reconhecimento seja diferente;
– Respeito: respeitar as diferentes habilidades e não tirar decisões
precipitadas sobre competência;
– Inclusão: pessoas contribuem efetivamente quando sentem que
são ouvidas;
– Honestidade: ser honesto sobre o que vai bem e o que vai mal
na equipe. Ser honesto quanto ao conhecimento técnico.
22. 2.1. Motivação de Pessoas
• Pessoas contribuem com o melhor de suas
habilidades quando estão motivadas;
• Organizar o trabalho e o ambiente de
trabalho pode contribuir para isso;
• Pessoas desmotivadas são desinteressadas,
não são produtivas e estão mais propensas a
erros;
• Pessoas são motivadas por satisfazer suas
necessidades, em diversos níveis.
24. 2.1. Motivação de Pessoas
• Pessoas em organizações de software em geral não
passam por necessidades básicas;
• Necessidades Sociais: As pessoas precisam se relacionar,
mesmo que através de mídias sociais. É importante que se
conheçam;
• Autoestima: Pessoas devem se sentir valorizadas pela
organização (reconhecimento) e devem ser remuneradas de
acordo com suas habilidades e experiência;
• Autorrealização: dar responsabilidade às pessoas; atribuir
com tarefas possíveis, mas desafiadoras; fornecer um
programa de treinamento.
25. 2.1. Motivação de Pessoas
• Dificuldades pessoais afetam a motivação, pois as
pessoas não conseguem se concentrar no seu
trabalho;
• Pessoas que esperam fazer um certo tipo de trabalho e
são direcionadas para outro podem se sentir
desmotivadas;
• Um grupo coeso é motivador para muitas pessoas.
Empregos satisfatórios fazem com que as pessoas
gostem de ir trabalhar;
• É importante pensar não só na motivação pessoal, mas
também na motivação do grupo.
26. 2.1. Motivação de Pessoas
• Tipos de personalidade influenciam na motivação:
–Pessoas orientadas a tarefas: motivadas pelo trabalho que
fazem (desafio intelectual do desenvolvimento de software);
–Pessoas automotivadas: motivadas pelo sucesso e
reconhecimento pessoal. Tem objetivos de longo prazo e se
motivam com a progressão na carreira;
–Pessoas orientadas a interações: motivadas pela presença
e ações dos colegas de trabalho.
• Pessoas orientadas a interações preferem trabalhar em grupo
e as demais preferem trabalhar individualmente;
• A motivação é uma composição dos tipos citados, mas
geralmente um tipo é determinante em cada momento.
28. 3. Planejamento de Projeto
• O Plano de Projeto elaborado no início de um
projeto deve ser usado como guia;
• Esse plano inicial deve ser o melhor possível em
face das informações disponíveis;
• Ele deve evoluir à medida que o projeto progride e
melhores informações se tornem disponíveis;
• O planejamento de projeto é um processo iterativo
que só termina ao final do projeto.
29. 3. Planejamento de Projeto
• No ciclo de vida do projeto, o planejamento ocorre em três
estágios:
– Proposta: decidir se tem os recursos e competências para o
projeto; calcular o preço para o cliente; estabelecer um contrato;
– Iniciação: planejar quem vai trabalhar no projeto; como os
recursos serão alocados; refinar as estimativas iniciais;
– Durante o projeto: ao adquirir experiência e informações, à
medida que monitora e conhece melhor o sistema e a
capacidade da equipe; mudanças de requisitos exigem
mudanças no cronograma.
30. 3. Planejamento de Projeto
• Os parâmetros que mais influenciam no custo de
um projeto de software são:
– Custos de esforço;
– Custos de hardware e software;
– Custos de viagens e treinamentos;
• Na maioria dos projetos de software, o maior
custo é o de esforço;
• Uma vez que você ganhou um contrato, o esboço
do plano de projeto precisa ser refinado.
31. 3. Planejamento de Projeto
• O gerente de projeto deve elaborar outros planos:
– Plano de Qualidade – descreve os procedimentos e os padrões de
qualidade usados no projeto;
– Plano de Validação – descreve a abordagem , os recursos e o
cronograma usados para a validação do sistema;
– Plano de Gerenciamento de Configuração – descreve os
procedimentos e as estruturas de gerenciamento de configuração;
– Plano de Manutenção – prevê os requisitos de manutenção do
sistema, os custos de manutenção e o esforço necessário;
– Plano de Desenvolvimento de Pessoal – descreve como as
habilidades e a experiência dos membros da equipe de projeto serão
desenvolvidas.
32. 3. Planejamento de Projeto
• O Plano de Projeto estabelece os recursos
disponíveis para o projeto, a estrutura analítica
do projeto e um cronograma para realizar o
trabalho;
• Em algumas organizações, o plano de projeto é
um único documento que inclui diferentes tipos
de planos;
• Em outros casos, o plano de projeto está
relacionado apenas ao processo de
desenvolvimento.
33. 3.1. Plano de Projeto
• Introdução – descreve brevemente os objetivos e estabelece as restrições (por exemplo, orçamento,
prazo, etc.) que afetam o gerenciamento do projeto;
• Organização do projeto – descreve o modo como a equipe de desenvolvimento está organizada, as
pessoas envolvidas e seus papéis na equipe;
• Análise de riscos – descreve os possíveis riscos do projeto, a probabilidade da ocorrência desses
riscos e as propostas de estratégias de redução de riscos;
• Requisitos de recursos de hardware e de software – especificam o hardware e o software de apoio
necessários para realizar o desenvolvimento, incluindo estimativas de preço e prazo de entrega;
• Estrutura analítica – estabelece a estrutura analítica do projeto em atividades e identifica os marcos
e os produtos a serem entregues com cada atividade;
• Cronograma do projeto – apresenta as dependências entre as atividades, o prazo estimado
necessário para atingir cada marco e a alocação de pessoas nas atividades;
• Mecanismos de monitoração e elaboração de relatórios – definem os relatórios de gerenciamento
que devem ser produzidos.
34. 3.2. Marcos e produtos a serem entregues
• Como o software é intangível, os gerentes de projeto
precisam de informações para realizar seu trabalho, na
forma de relatórios e documentos;
• Sem isso, é impossível avaliar quão bem o projeto está
progredindo e realizar revisões de estimativas de custo e
cronograma;
• Ao planejar um projeto, deve-se estabelecer uma série de
marcos;
• Um marco é um ponto final reconhecível de uma atividade
do processo de software;
• A cada marco deve existir uma saída forma, como um
relatório, que possa ser apresentado à gerência.
35. 3.2. Marcos e produtos a serem entregues
• Para estabelecer os marcos, o processo
de software deve ser decomposto em
atividades básicas com saídas
associadas;
• A seguir, se vê um exemplo de marcos em
um processo de requisitos:
36. Estudo de
viabilidade
Análise de
requisitos
Desenvolvimento
de protótipo
Estudo de
projeto
Especificação
de requisitos
Relatório de
viabilidade
Definição de
requisitos
Relatório de
avaliação
Projeto de
arquitetura
Requisitos
de sistema
Marcos em um processo de requisitos
ATIVIDADES
MARCOS
38. 4. Estimativa de Tamanho
• Existem vários métodos que podem ser utilizados para
realizar estimativas de tamanho, como: pontos de função,
pontos de objeto, COCOMO, entre outros;
• Nós vamos estudar a métrica chamada pontos de função;
• O instituto responsável pelas técnicas e pela certificação de
profissionais é o IFPUG (International Function Point Users
Group), representado no Brasil pelo BFPUG (Brazilian
Function Point Users Group).
39. Tipos de Pontos de Função
Tipos Sigla Sigla
Inglês
Definição Oficial Exemplos
Entradas
externas
EE EI Processo elementar no qual
dados cruzam a fronteira do
produto de fora para dentro.
Nos casos de uso: fluxos,
subfluxos e fluxos alternativos de
inclusão, alteração e exclusão.
Consultas
externas
CE EQ Processo elementar que resulta
em recuperação de dados de um
ou mais arquivos lógicos.
Nos casos de uso: fluxos,
subfluxos e fluxos alternativos de
pesquisa.
Saídas
externas
SE EO Processo elementar no qual
dados derivados cruzam a
fronteira do produto de dentro
para fora.
Relatórios; interfaces com
sistemas externos de saída.
Arquivos
lógicos internos
ALI ILF Grupo de dados logicamente
correlatos, identificável pelo
usuário, que reside inteiramente
dentro de um aplicativo.
Tabelas de banco de dados
mapeadas em classes que são
consultadas de maneira
independente de outras; em
estruturas de agregação se tem
apenas um arquivo lógico.
Arquivos de
interface
externa
AIE EIF Grupo de dados logicamente
correlatos, identificável pelo
usuário, que é apenas consultado
pela aplicação, sendo mantido
por outros aplicativos.
Interfaces com sistemas externos
de entrada; views de banco de
dados.
40. Parâmetros
Parâmetro Sigla Sigle
Inglês
Definição Oficial Exemplos
Tipos de
Elementos de
Dados
TED DET Número de campos distintos e
não-repetitivos, identificáveis
pelo usuário.
Campos, botões e mensagens
existentes em uma interface de
um fluxo de caso de uso.
Tipos de
Arquivos
Referenciados
TAR FTR Número de arquivos lógicos
referenciados por um processo
elementar.
Número de arquivos lógicos
referenciados por um fluxo de
caso de uso.
Tipos de
Elementos
Referenciados
TER RET Número de grupos de elementos
de dados dentro de um arquivo
lógico.
Número de tabelas que
compõem o arquivo lógico.
41. Transações (Processos Elementares)
EE TED < 5 5 <= TED <= 15 TED > 15
TAR < 2 Simples (3) Simples (3) Média (4)
TAR = 2 Simples (3) Média (4) Alta (6)
TAR > 2 Média (4) Alta (6) Alta (6)
CE TED < 6 6 <= TED <= 19 TED > 19
TAR < 2 Simples (3) Simples (3) Média (4)
2 <= TAR <= 3 Simples (3) Média (4) Alta (6)
TAR > 2 Média (4) Alta (6) Alta (6)
SE TED < 6 6 <= TED <= 19 TED > 19
TAR < 2 Simples (4) Simples (4) Média (5)
2 <= TAR <= 3 Simples (4) Média (5) Alta (7)
TAR > 2 Média (5) Alta (7) Alta (7)
42. Arquivos Lógicos
ALI TED < 20 20 <= TED <= 50 TED > 50
TER < 2 Simples (7) Simples (7) Média (10)
2 <= TER <= 5 Simples (7) Média (10) Alta (15)
TER > 5 Média (10) Alta (15) Alta (15)
AIE TED < 20 20 <= TED <= 50 TED > 50
TER < 2 Simples (5) Simples (5) Média (7)
2 <= TER <= 5 Simples (5) Média (7) Alta (10)
TER > 5 Média (7) Alta (10) Alta (10)
43. Características
• Um conjunto de 14 características do sistema servem para
fazer um ajuste na contagem de pontos de função, variando
esse ajuste 35% para mais ou para menor;
• Cada característica é avaliada em uma escala de 0 (sem
influência) até 5 (influência forte);
• É feita a soma da influência de todas as características e se
chega ao NI (nível de influência);
• Essa soma pode variar de 0 até 70;
• O cálculo do ajuste é feito da seguinte forma:
0,65 + 0,01 x NI
• O ajuste, por sua vez, pode variar de 65% até 0,65 + 0,7 =
135%.
44. Características
• As características são:
– Teleprocessamento
– Processamento Distribuído
– Desempenho
– Utilização de Máquina
– Volume das Transações
– Entrada de Dados On-line
– Usabilidade
– Atualização On-line
– Complexidade do Processamento
– Reutilização de Código
– Facilidade de Implantação
– Facilidade de Operação
– Operação em Múltiplos Locais
– Facilidade de Manutenção / Alteração
46. 5. Estimativa de Recursos
• Normalmente a estimativa de recursos
humanos é baseada em um histórico de
informações da própria organização, de
literatura especializada ou benchmarking;
• Quanto a outros recursos, devem ser
identificados pelo gerente. Histórico de
projetos semelhantes pode ajudar na
identificação.
48. 6. Cronograma de Projeto
• O gerente de projetos deve estimar o tempo e recursos necessários para
concluir atividades, organizando-as em uma sequência coerente;
• Nem sempre experiências com outros projetos são aproveitadas, pois
geralmente são diferentes e utilizam metodologias e ferramentas diferentes;
• Os cronogramas devem ser atualizados à medida que mais informações sobre
o progresso se tornam disponíveis;
• Algumas atividades são executadas em paralelo e o gerente deve trabalhar
para que os recursos sejam utilizados de forma otimizada;
• Uma atividade deve ter no mínimo 1 semana. Menos do que isso se gasta
muito tempo fazendo revisões de cronograma;
• Além disso, uma atividade não deve passar de 8 a 10 semanas. Se levar mais
tempo que isso, deve ser subdividida.
49. 6. Cronograma de Projeto
• Durante o andamento do projeto, problemas podem ocorrer,
como: alguém fica doente, pode haver atraso na entrega de
algum hardware ou software adquirido, etc;
• Deve-se prestar atenção também aos recursos necessários para
cada tarefa: pessoas, equipamentos, orçamento para viagens,
etc;
• Uma boa regra prática é fazer a estimativa como se nada fosse
dar errado e, então, aumentar a estimativa para cobrir problemas
não previstos, usando um coeficiente de contingência;
• Esse coeficiente depende do tipo de projeto, prazo, padrões
utilizados e experiência dos engenheiros de software.
50. Processo de desenvolvimento do cronograma do
projeto
Estimar recursos
para atividades
Identificar
atividades
Identificar
dependências
entre atividades
Alocar pessoas
para atividades
Criar diagramas
de projeto
Requisitos
de software
Diagramas de
atividades e
diagramas de barras
51. 6. Cronograma de Projeto
• Para representar o cronograma, normalmente utilizamos
diagramas;
• Diagrama de barras – mostra quais tarefas podem ser
executadas simultaneamente e quais devem ser executadas
em sequência devido à dependência de uma atividade
anterior;
• Diagrama de redes – mostra com mais clareza qual o
caminho crítico do projeto, aquele onde não pode haver
atraso;
• O digrama de barras é também chamado de Gráfico de
Gantt;
• Nos próximos slides, vemos exemplos de ambos.
52. Diagrama de Redes de Atividades
Início
T1
T3
T2
T4
T5
T6 T8
Fim
T7
M1
15 dias 10 dias
7 dias
3 dias
7 dias
14/02/2011 18/03/2011
7 dias 7 dias
15 dias
08/04/2011
55. 7. Monitoração e Controle de Projetos
• O objetivo principal dessa etapa é detectar
problemas e desvios do plano o mais cedo
possível, de modo que seja possível aplicar
ações corretivas eficazes;
• Além disso, deve-se gerar informações
para preservar a memória da execução de
cada projeto, para que seja possível
melhorar os processos em projetos futuros.
56. 7. Monitoração e Controle de Projetos
• Essa etapa é dividida nas seguintes atividades:
– Monitoração do escopo – acompanhamento e registro
das variações do escopo;
– Medição de progresso – acompanhamento do esforço
despendido no projeto, comparando-o com o previsto e
projetando os esforços e prazos futuros;
– Monitoração dos riscos – acompanhamento dos riscos
previstos e concretizados, bem como atualização das
probabilidades, efeitos e estratégias.
58. 8. Gerenciamento da Qualidade
• Qualidade de software é um conceito
complexo e não é diretamente equiparável
à qualidade na manufatura;
• Na manufatura, a noção de qualidade é a
de que o produto desenvolvido deve
atender às suas especificações;
• Isso deveria ser aplicado a todos os
produtos (inclusive software), mas:
59. 8. Gerenciamento da Qualidade
• Além das características que o cliente deseja, quem
desenvolve também pode ter seus requisitos (manutenção,
p. ex.) que não estão na especificação;
• Não sabemos especificar certas características de
qualidade (facilidade de manutenção, p. ex.) de maneira
não ambígua;
• É muito difícil escrever especificações de software
completas. O produto pode atender às especificação, mas
não atender às necessidades do cliente.
60. 8. Gerenciamento da Qualidade
• Algumas pessoas acham que a qualidade pode ser
conseguida através de padrões e procedimentos que
verifiquem se esses padrões são seguidos;
• Bons gerentes de qualidade tem por objetivo desenvolver
uma “cultura de qualidade”;
• Todos os responsáveis pelo desenvolvimento devem estar
comprometidos em atingir um alto nível de qualidade;
• Eles encorajam a equipe a assumir responsabilidade pela
qualidade e a trabalhar pela melhoria da qualidade dos
produtos.
61. 8. Gerenciamento da Qualidade
• O gerenciamento de qualidade de software pode ser
estruturados em 3 atividades:
– Garantia da qualidade: procedimentos e padrões que conduzem
a um software de alta qualidade;
– Planejamento da qualidade: seleção de procedimentos e
padrões apropriados para um projeto de software específico;
– Controle de qualidade: definição e aprovação de processos que
assegurem que a equipe de software tenha seguido os
procedimentos e padrões de qualidade do projeto.
62. 8. Gerenciamento da Qualidade
• A suposição de que a qualidade do processo de
desenvolvimento afeta diretamente a qualidade
dos produtos entregues provém da manufatura;
• Software não é manufaturado, é projetado;
• O desenvolvimento de software é um projeto mais
criativo do que mecânico
• A habilidade e experiência das pessoas é decisiva
para a qualidade;
• Fatores externos (pressão para liberação rápida, p.
ex.) também afetam a qualidade do software.
