1 gerência de projetos

Gerência de Projetos

Leonardo Queiroz Oliveira

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.

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.

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.

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

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.


• 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.

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

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.

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.

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

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

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.

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

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.

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

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.

Gerenciamento de Pessoas

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.

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.

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.

Necessidades Fisiológicas

Necessidades de Segurança

Necessidades Sociais

Necessidades de Autoestima

Necessidades de Autorrealização

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.

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.

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.

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.

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.


• 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.

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.


• 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.

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.

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.

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:

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

Estimativa de Tamanho

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).

Tipos de Pontos de FunçãoTipos Sigla Sigla

InglêsDefiniçã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.

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.

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


2 <= TAR <= 3 Simples (3) Média (4) Alta (6)


SE TED < 6 6 <= TED <= 19 TED > 19


2 <= TAR <= 3 Simples (4) Média (5) Alta (7)


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)

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%.

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

Estimativa de Recursos

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.

Cronograma de Projeto

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.

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.

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

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.

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

Diagrama de Barras de Atividades (Gráfico de Gantt)

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.


• 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.

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:

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.

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.

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.


• 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.

Obrigado!

1 gerência de projetos

Documents

Transcript of 1 gerência de projetos