1 gerência de projetos

298 visualizações

Publicada em

0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
298
No SlideShare
0
A partir de incorporações
0
Número de incorporações
1
Ações
Compartilhamentos
0
Downloads
6
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

1 gerência de projetos

  1. 1. Gerência de ProjetosLeonardo Queiroz Oliveira
  2. 2. Gerente de Projetos• Responsável pelo desenvolvimento deplanos e cronogramas do projeto;• Supervisionam o trabalho para assegurarque seguem os padrões estabelecidos;• Monitoram o desenvolvimento paraverificar se está dentro do prazo e doorçamento.
  3. 3. Projetos de SW• Engenharia de Software é diferente das outrasengenharias:– O produto é intangível – os gerentes de projeto não podem ver oprogresso e dependem de documentos e relatórios para isso;– Não existem processos-padrão de software – em outrasengenharias clássicas, há processos bem compreendidos, aocontrário do software;– Muitos projetos de grande porte são “únicos” – a experiência deum gerente de projetos sofre obsolescência ao longo do tempo.
  4. 4. Atividades• Atividades do Gerenciamento de Projetos:– Elaboração da proposta;– Planejamento e desenvolvimento docronograma;– 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. 5. Sumário1. Gerenciamento de Riscos2. Gerenciamento de Pessoas3. Planejamento de Projeto4. Estimativa de Tamanho5. Estimativa de Recursos6. Cronograma do Projeto7. Monitoração e Controle de Projetos8. Gerenciamento da Qualidade
  6. 6. Gerenciamento de Riscos
  7. 7. 1. Gerenciamento de Riscos• O gerenciamento de riscos está sendoconsiderado, cada vez mais, como uma dasprincipais atividades dos gerentes de projeto;• Consiste em prever os riscos que podem afetar ocronograma do projeto ou a qualidade do softwareque está sendo desenvolvido;• Consiste também em tomar providências paraevitar e mitigar riscos;• De maneira simplificado, risco é algo que seriapreferível não ocorrer.
  8. 8. 1. Gerenciamento de Riscos• Categorias de riscos:– Riscos de projeto – afetam o cronograma ou osrecursos do projeto;• Ex: perda de um projetista experiente.– Riscos de produto – afetam a qualidade ou odesempenho do software;• Ex: componente comprado não funciona como esperado.– Riscos de negócio – afetam a organização quedesenvolve ou adquire o software;• Ex: concorrente lança um produto semelhante.
  9. 9. Risco Categoria DescriçãoRotatividade de pessoal Projeto Pessoal experiente deixará o projetoantes do seu término.Mudança de gerência Projeto Haverá uma mudança na gerência daorganização com diferentes prioridades.Mudança de requisitos Projeto e produto Haverá um número maior de mudançasde 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 nomercado antes da conclusão do sistema.Possíveis riscos de software
  10. 10. 1.1. Identificação de Riscos• Primeiro estágio do gerenciamento deriscos;• Os riscos não devem ser avaliados oupriorizados ainda, apenas identificados;• Deve ser realizada como um processo emequipe, usando brainstorming;• A experiência é muito importante.
  11. 11. 1.1. Identificação de Riscos• Tipos de risco usados na identificação:– Riscos de tecnologia – derivam de tecnologias de software ou hardwareusadas;– 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 softwaresde apoio;– Riscos de requisitos – derivam de mudanças de requisitos de cliente e doprocesso de gerenciamento de mudanças de requisitos;– Riscos de estimativas – derivam de estimativas de gerenciamento dascaracterísticas de sistema e recursos necessário para construção.
  12. 12. Tipo de Risco Riscos PossíveisTecnologia O banco de dados usado no sistema não pode processar tantastransações por segundo como esperado.Os componentes de software que devem ser reusados contêm defeitosque 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 momentoscríticos.O treinamento necessário para o pessoal não está disponível.Organizacional A organização é reestruturada, de modo que uma gerência diferentetornou-se responsável pelo projeto.Problemas financeiros da organização forçam reduções no orçamentodo 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ãopropostas.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. 13. 1.2. Análise de Riscos• Nessa etapa, deve-se fazer uma avaliação dos riscos identificadosquanto à 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. 14. 1.2. Análise de Riscos• Os riscos catastróficos sempre devem serconsiderados, assim como os riscos sérios que tenhamprobabilidade acima da média;• Recomenda-se identificar os “10 maiores riscos” doprojeto e monitorá-los;• Esse número não é exato, mas deve ser gerenciável;• Gerenciar riscos demais exige muitas informações epode aumentar o orçamento.
  15. 15. Risco Probabilidade EfeitosProblemas financeiros da organização forçamreduções no orçamento do projeto.Baixa CatastróficosÉ impossível recrutar pessoal com as habilidadesnecessárias para o projeto.Alta CatastróficosO mais qualificado está doente nos momentos críticosdo projeto.Média SériosO tempo necessário para desenvolver o software foisubestimado.Alta SériosO tamanho do software foi subestimado. Alta ToleráveisA taxa de reparo de defeitos foi subestimada. Média ToleráveisAnálise de riscos
  16. 16. 1.3. Planejamento de Riscos• Essa etapa define estratégia para tratar os riscos escolhidospara serem gerenciados na análise;• Essas estratégias se dividem em três categorias:– Estratégias de prevenção – servem para diminuir a probabilidadede ocorrência do risco;– Estratégias de minimização – servem para reduzir o impacto dorisco;– Planos de contingência – preparam para o pior e definem açõespara lidar com o problema.
  17. 17. Risco EstratégiaProblemas de recrutamento Alertar o cliente sobre as dificuldades potenciais e apossibilidade de atrasos; investigar a compra decomponentes.Doença do pessoal daequipeReorganizar a equipe de maneira que haja maissuperposição de trabalho e, portanto, as pessoascompreendam as tarefas uns dos outros.Mudanças de requisitos Derivar informações de rastreabilidade para avaliar oimpacto das mudanças de requisitos e maximizar oocultamento de informações no projeto.Prazo de desenvolvimentosubestimadoVerificar a compra de componentes e verificar o uso de umgerador de programa.Estratégias de gerenciamento de riscos
  18. 18. 1.4. Monitoração de Riscos• O gerente deve avaliar cada um dos riscosidentificados para saber se o risco está ounão se tornando mais ou menos provável ese os efeitos mudaram;• Para isso, deve-se observar fatores queforneçam indícios;• Essa monitoração deve ser um processocontínuo, realizado no mínimo a cadarevisão de progresso.
  19. 19. Gerenciamento de Pessoas
  20. 20. 2. Gerenciamento de Pessoas• As pessoas que trabalham em uma organização sãoseus maiores ativos;• Custa muito recrutar boas pessoas;• Cabe aos gerentes atribuir responsabilidades àspessoas condizentes com suas experiências ehabilidades;• O respeito às pessoas garante o melhor retorno sobreos investimentos;• É importante conhecer as questões técnicas de umprojeto, mas nem sempre um bom engenheiro desoftware é um bom gestor de pessoas.
  21. 21. 2. Gerenciamento de Pessoas• Fatores críticos no gerenciamento de pessoas:– Consistência: tratar as pessoas da mesma forma, por mais que oreconhecimento seja diferente;– Respeito: respeitar as diferentes habilidades e não tirar decisõesprecipitadas sobre competência;– Inclusão: pessoas contribuem efetivamente quando sentem quesão ouvidas;– Honestidade: ser honesto sobre o que vai bem e o que vai malna equipe. Ser honesto quanto ao conhecimento técnico.
  22. 22. 2.1. Motivação de Pessoas• Pessoas contribuem com o melhor de suashabilidades quando estão motivadas;• Organizar o trabalho e o ambiente detrabalho pode contribuir para isso;• Pessoas desmotivadas são desinteressadas,não são produtivas e estão mais propensas aerros;• Pessoas são motivadas por satisfazer suasnecessidades, em diversos níveis.
  23. 23. Necessidades FisiológicasNecessidades de SegurançaNecessidades SociaisNecessidades de AutoestimaNecessidades de Autorrealização
  24. 24. 2.1. Motivação de Pessoas• Pessoas em organizações de software em geral nãopassam por necessidades básicas;• Necessidades Sociais: As pessoas precisam se relacionar,mesmo que através de mídias sociais. É importante que seconheçam;• Autoestima: Pessoas devem se sentir valorizadas pelaorganização (reconhecimento) e devem ser remuneradas deacordo com suas habilidades e experiência;• Autorrealização: dar responsabilidade às pessoas; atribuircom tarefas possíveis, mas desafiadoras; fornecer umprograma de treinamento.
  25. 25. 2.1. Motivação de Pessoas• Dificuldades pessoais afetam a motivação, pois aspessoas não conseguem se concentrar no seutrabalho;• Pessoas que esperam fazer um certo tipo de trabalho esão direcionadas para outro podem se sentirdesmotivadas;• Um grupo coeso é motivador para muitas pessoas.Empregos satisfatórios fazem com que as pessoasgostem de ir trabalhar;• É importante pensar não só na motivação pessoal, mastambém na motivação do grupo.
  26. 26. 2.1. Motivação de Pessoas• Tipos de personalidade influenciam na motivação:–Pessoas orientadas a tarefas: motivadas pelo trabalho quefazem (desafio intelectual do desenvolvimento de software);–Pessoas automotivadas: motivadas pelo sucesso ereconhecimento pessoal. Tem objetivos de longo prazo e semotivam com a progressão na carreira;–Pessoas orientadas a interações: motivadas pela presençae ações dos colegas de trabalho.• Pessoas orientadas a interações preferem trabalhar em grupoe as demais preferem trabalhar individualmente;• A motivação é uma composição dos tipos citados, masgeralmente um tipo é determinante em cada momento.
  27. 27. Planejamento de Projeto
  28. 28. 3. Planejamento de Projeto• O Plano de Projeto elaborado no início de umprojeto deve ser usado como guia;• Esse plano inicial deve ser o melhor possível emface das informações disponíveis;• Ele deve evoluir à medida que o projeto progride emelhores informações se tornem disponíveis;• O planejamento de projeto é um processo iterativoque só termina ao final do projeto.
  29. 29. 3. Planejamento de Projeto• No ciclo de vida do projeto, o planejamento ocorre em trêsestágios:– Proposta: decidir se tem os recursos e competências para oprojeto; calcular o preço para o cliente; estabelecer um contrato;– Iniciação: planejar quem vai trabalhar no projeto; como osrecursos 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 acapacidade da equipe; mudanças de requisitos exigemmudanças no cronograma.
  30. 30. 3. Planejamento de Projeto• Os parâmetros que mais influenciam no custo deum 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 maiorcusto é o de esforço;• Uma vez que você ganhou um contrato, o esboçodo plano de projeto precisa ser refinado.
  31. 31. 3. Planejamento de Projeto• O gerente de projeto deve elaborar outros planos:– Plano de Qualidade – descreve os procedimentos e os padrões dequalidade usados no projeto;– Plano de Validação – descreve a abordagem , os recursos e ocronograma usados para a validação do sistema;– Plano de Gerenciamento de Configuração – descreve osprocedimentos e as estruturas de gerenciamento de configuração;– Plano de Manutenção – prevê os requisitos de manutenção dosistema, os custos de manutenção e o esforço necessário;– Plano de Desenvolvimento de Pessoal – descreve como ashabilidades e a experiência dos membros da equipe de projeto serãodesenvolvidas.
  32. 32. 3. Planejamento de Projeto• O Plano de Projeto estabelece os recursosdisponíveis para o projeto, a estrutura analíticado projeto e um cronograma para realizar otrabalho;• Em algumas organizações, o plano de projeto éum único documento que inclui diferentes tiposde planos;• Em outros casos, o plano de projeto estárelacionado apenas ao processo dedesenvolvimento.
  33. 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, aspessoas envolvidas e seus papéis na equipe;• Análise de riscos – descreve os possíveis riscos do projeto, a probabilidade da ocorrência dessesriscos 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 apoionecessá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 marcose os produtos a serem entregues com cada atividade;• Cronograma do projeto – apresenta as dependências entre as atividades, o prazo estimadonecessá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 gerenciamentoque devem ser produzidos.
  34. 34. 3.2. Marcos e produtos a serem entregues• Como o software é intangível, os gerentes de projetoprecisam de informações para realizar seu trabalho, naforma 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 ecronograma;• Ao planejar um projeto, deve-se estabelecer uma série demarcos;• Um marco é um ponto final reconhecível de uma atividadedo processo de software;• A cada marco deve existir uma saída forma, como umrelatório, que possa ser apresentado à gerência.
  35. 35. 3.2. Marcos e produtos a serem entregues• Para estabelecer os marcos, o processode software deve ser decomposto ematividades básicas com saídasassociadas;• A seguir, se vê um exemplo de marcos emum processo de requisitos:
  36. 36. Estudo deviabilidadeAnálise derequisitosDesenvolvimentode protótipoEstudo deprojetoEspecificaçãode requisitosRelatório deviabilidadeDefinição derequisitosRelatório deavaliaçãoProjeto dearquiteturaRequisitosde sistemaMarcos em um processo de requisitosATIVIDADESMARCOS
  37. 37. Estimativa de Tamanho
  38. 38. 4. Estimativa de Tamanho• Existem vários métodos que podem ser utilizados pararealizar 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 deprofissionais é o IFPUG (International Function Point UsersGroup), representado no Brasil pelo BFPUG (BrazilianFunction Point Users Group).
  39. 39. Tipos de Pontos de FunçãoTipos Sigla SiglaInglêsDefinição Oficial ExemplosEntradasexternasEE EI Processo elementar no qualdados cruzam a fronteira doproduto de fora para dentro.Nos casos de uso: fluxos,subfluxos e fluxos alternativos deinclusão, alteração e exclusão.ConsultasexternasCE EQ Processo elementar que resultaem recuperação de dados de umou mais arquivos lógicos.Nos casos de uso: fluxos,subfluxos e fluxos alternativos depesquisa.SaídasexternasSE EO Processo elementar no qualdados derivados cruzam afronteira do produto de dentropara fora.Relatórios; interfaces comsistemas externos de saída.Arquivoslógicos internosALI ILF Grupo de dados logicamentecorrelatos, identificável pelousuário, que reside inteiramentedentro de um aplicativo.Tabelas de banco de dadosmapeadas em classes que sãoconsultadas de maneiraindependente de outras; emestruturas de agregação se temapenas um arquivo lógico.Arquivos deinterfaceexternaAIE EIF Grupo de dados logicamentecorrelatos, identificável pelousuário, que é apenas consultadopela aplicação, sendo mantidopor outros aplicativos.Interfaces com sistemas externosde entrada; views de banco dedados.
  40. 40. ParâmetrosParâmetro Sigla SigleInglêsDefinição Oficial ExemplosTipos deElementos deDadosTED DET Número de campos distintos enão-repetitivos, identificáveispelo usuário.Campos, botões e mensagensexistentes em uma interface deum fluxo de caso de uso.Tipos deArquivosReferenciadosTAR FTR Número de arquivos lógicosreferenciados por um processoelementar.Número de arquivos lógicosreferenciados por um fluxo decaso de uso.Tipos deElementosReferenciadosTER RET Número de grupos de elementosde dados dentro de um arquivológico.Número de tabelas quecompõem o arquivo lógico.
  41. 41. Transações (Processos Elementares)EE TED < 5 5 <= TED <= 15 TED > 15TAR < 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 > 19TAR < 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 > 19TAR < 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. 42. Arquivos LógicosALI TED < 20 20 <= TED <= 50 TED > 50TER < 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 > 50TER < 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. 43. Características• Um conjunto de 14 características do sistema servem parafazer um ajuste na contagem de pontos de função, variandoesse ajuste 35% para mais ou para menor;• Cada característica é avaliada em uma escala de 0 (seminfluência) até 5 (influência forte);• É feita a soma da influência de todas as características e sechega 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. 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
  45. 45. Estimativa de Recursos
  46. 46. 5. Estimativa de Recursos• Normalmente a estimativa de recursoshumanos é baseada em um histórico deinformações da própria organização, deliteratura especializada ou benchmarking;• Quanto a outros recursos, devem seridentificados pelo gerente. Histórico deprojetos semelhantes pode ajudar naidentificação.
  47. 47. Cronograma de Projeto
  48. 48. 6. Cronograma de Projeto• O gerente de projetos deve estimar o tempo e recursos necessários paraconcluir atividades, organizando-as em uma sequência coerente;• Nem sempre experiências com outros projetos são aproveitadas, poisgeralmente são diferentes e utilizam metodologias e ferramentas diferentes;• Os cronogramas devem ser atualizados à medida que mais informações sobreo progresso se tornam disponíveis;• Algumas atividades são executadas em paralelo e o gerente deve trabalharpara que os recursos sejam utilizados de forma otimizada;• Uma atividade deve ter no mínimo 1 semana. Menos do que isso se gastamuito tempo fazendo revisões de cronograma;• Além disso, uma atividade não deve passar de 8 a 10 semanas. Se levar maistempo que isso, deve ser subdividida.
  49. 49. 6. Cronograma de Projeto• Durante o andamento do projeto, problemas podem ocorrer,como: alguém fica doente, pode haver atraso na entrega dealgum hardware ou software adquirido, etc;• Deve-se prestar atenção também aos recursos necessários paracada tarefa: pessoas, equipamentos, orçamento para viagens,etc;• Uma boa regra prática é fazer a estimativa como se nada fossedar errado e, então, aumentar a estimativa para cobrir problemasnão previstos, usando um coeficiente de contingência;• Esse coeficiente depende do tipo de projeto, prazo, padrõesutilizados e experiência dos engenheiros de software.
  50. 50. Processo de desenvolvimento do cronograma doprojetoEstimar recursospara atividadesIdentificaratividadesIdentificardependênciasentre atividadesAlocar pessoaspara atividadesCriar diagramasde projetoRequisitosde softwareDiagramas deatividades ediagramas de barras
  51. 51. 6. Cronograma de Projeto• Para representar o cronograma, normalmente utilizamosdiagramas;• Diagrama de barras – mostra quais tarefas podem serexecutadas simultaneamente e quais devem ser executadasem sequência devido à dependência de uma atividadeanterior;• Diagrama de redes – mostra com mais clareza qual ocaminho crítico do projeto, aquele onde não pode haveratraso;• O digrama de barras é também chamado de Gráfico deGantt;• Nos próximos slides, vemos exemplos de ambos.
  52. 52. Diagrama de Redes de AtividadesInícioT1T3T2T4T5T6 T8FimT7M115 dias 10 dias7 dias3 dias7 dias14/02/2011 18/03/20117 dias 7 dias15 dias08/04/2011
  53. 53. Diagrama de Barras de Atividades (Gráfico de Gantt)
  54. 54. Monitoração e Controle de Projetos
  55. 55. 7. Monitoração e Controle de Projetos• O objetivo principal dessa etapa é detectarproblemas e desvios do plano o mais cedopossível, de modo que seja possível aplicarações corretivas eficazes;• Além disso, deve-se gerar informaçõespara preservar a memória da execução decada projeto, para que seja possívelmelhorar os processos em projetos futuros.
  56. 56. 7. Monitoração e Controle de Projetos• Essa etapa é dividida nas seguintes atividades:– Monitoração do escopo – acompanhamento e registrodas variações do escopo;– Medição de progresso – acompanhamento do esforçodespendido no projeto, comparando-o com o previsto eprojetando os esforços e prazos futuros;– Monitoração dos riscos – acompanhamento dos riscosprevistos e concretizados, bem como atualização dasprobabilidades, efeitos e estratégias.
  57. 57. Gerenciamento da Qualidade
  58. 58. 8. Gerenciamento da Qualidade• Qualidade de software é um conceitocomplexo e não é diretamente equiparávelà qualidade na manufatura;• Na manufatura, a noção de qualidade é ade que o produto desenvolvido deveatender às suas especificações;• Isso deveria ser aplicado a todos osprodutos (inclusive software), mas:
  59. 59. 8. Gerenciamento da Qualidade• Além das características que o cliente deseja, quemdesenvolve 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 dequalidade (facilidade de manutenção, p. ex.) de maneiranão ambígua;• É muito difícil escrever especificações de softwarecompletas. O produto pode atender às especificação, masnão atender às necessidades do cliente.
  60. 60. 8. Gerenciamento da Qualidade• Algumas pessoas acham que a qualidade pode serconseguida através de padrões e procedimentos queverifiquem se esses padrões são seguidos;• Bons gerentes de qualidade tem por objetivo desenvolveruma “cultura de qualidade”;• Todos os responsáveis pelo desenvolvimento devem estarcomprometidos em atingir um alto nível de qualidade;• Eles encorajam a equipe a assumir responsabilidade pelaqualidade e a trabalhar pela melhoria da qualidade dosprodutos.
  61. 61. 8. Gerenciamento da Qualidade• O gerenciamento de qualidade de software pode serestruturados em 3 atividades:– Garantia da qualidade: procedimentos e padrões que conduzema um software de alta qualidade;– Planejamento da qualidade: seleção de procedimentos epadrões apropriados para um projeto de software específico;– Controle de qualidade: definição e aprovação de processos queassegurem que a equipe de software tenha seguido osprocedimentos e padrões de qualidade do projeto.
  62. 62. 8. Gerenciamento da Qualidade• A suposição de que a qualidade do processo dedesenvolvimento afeta diretamente a qualidadedos produtos entregues provém da manufatura;• Software não é manufaturado, é projetado;• O desenvolvimento de software é um projeto maiscriativo do que mecânico• A habilidade e experiência das pessoas é decisivapara a qualidade;• Fatores externos (pressão para liberação rápida, p.ex.) também afetam a qualidade do software.
  63. 63. Obrigado!

×