Gestão da Tecnologia de Informação Gerenciamento de Projetos de Software – GTI16 Prof. André Campos 22 a 25 de novembro de 2005

Gestão da Tecnologia de Informação

Gerenciamento de Projetos de Software – GTI16

Prof. André Campos

22 a 25 de novembro de 2005

Ger. Proj. de Software GTI - 16 2

Eng. Civil vs. Eng. de Software

• Porque pontes são geralmente construídas a tempo e a um custo conhecido... e softwares raramente os são?– 3000 anos de experiência a mais– Engenharia Civil: Clara separação entre especificação e execução

• Especificação detalhada antes de “colocar a mão na massa”• Uma vez que a especificação é aceita, pouco se pode fazer para alterar• Terrenos não estão constantemente mudando

– Engenharia de Software: a especificar faz parte da execução• Códigos fontes são também especificações• Tendência a clientes solicitar mudanças constantemente• Em negócios, mudança é uma NECESSIDADE

• Conclusão– Projetos de software possuem maiores riscos e devem ser

gerenciados com a atenção voltada às mudanças.


Objetivos do módulo

• Módulos anteriores– Gestão de projetos (GTI-10)

• Práticas em projetos de qualquer área• Grupos de processos

– Iniciação, Planejamento, Execução, Controle, Finalização

– Engenharia de software (GTI-15)• Conceitos iniciais, práticas e ferramentas do

desenvolvimento de projetos de software

• Este módulo– Apresentar um conjunto de processos e metodologias

úteis no gerenciamento de projetos de software


Agenda do curso

• Aula 1 – Conceitos iniciais– Proj. de software, PMBOK, planejamento e estimativas

• Aula 2 – Processo Unificado– Conceitos básicos, fases, marcos e iterações

• Aula 3 – Processo Unificado– Disciplinas e Atividades

• Aula 4 – Metodologias ágeis e Descentralização– XP e Scrum– Desenvolvimento descentralizado


Avaliação

• Trabalho individual– Proposta de um processo para um cenário fictício

• Trabalho em grupo– Atividades realizadas durante o módulo

Gestão de projetosde Software

GTI-16Aula 1

Conceitos iniciais


Gerenciamento de Projetos

• Projeto– Empreendimento temporário (início e término definidos),

conduzido por pessoas para atender objetivos dentro de parâmetros de:

• Prazo• Qualidade • Custo

• Gestão de projetos– Combinação de recursos (humanos e materiais) através

de metodologias e técnicas para atender os objetivos de um projeto


Como gerenciar?

• Solução: Usar uma metodologia– Adotar práticas que ajudaram outros projetos pode

beneficiar o seu– Guia de referência sobre o que deve ser considerado

• Que metodologia utilizar?

Metodologia de desenvolvimento de software

Metodologia de gerenciamento de projetos


Gestão de projetos vs.Gestão de projetos de software

Metodologias de gerenciamento de projetos

Informa que deve haver fases e um planejamento realizado antes de cada fase

Informa que papéis e responsabilidades devem ser definidos

Define um framework de gerenciamento

Metodologias de desenvolvimento de software

Informa que fases existem e que atividades devem ser consideradas no planejamento

Informa os papéis e responsabilidades da fase de desenvolvimento

Define como o framework será colocado em prática


Exemplo de metodologia de gerenciamento de projetos

• PMBOK– Framework geral para desenvolvimento de projetos– Define diretrizes sobre gerenciamento

• O que pensar e como atuar• Como organizar as atividades• De que preciso quando for realizar uma determinada atividade

– Terminologia independente de área (civil, TI,...)– Tem se tornado um padrão (ex. Cesar)– Organizado em

• Grupos de processos• Áreas de conhecimento


Processos de um projeto (PMBOK)

• Iniciação

• Planejamento

• Execução

• Controle

• Encerramento

• Definição de necessidades, demandas, metas e escopo;

• Identificação de restrições e premissas• Definição de uma estratégia• Determinação dos recursos e orçamento

necessários

• Criação do plano de execução e controle do projeto

• Definição da equipe de desenvolvimento• Definição de mecanismos de controle• Alocação e implementação de recursos• Gerenciamento da execução• Implementação de procedimentos de garantia

de qualidade• Avaliação de desempenho• Aplicação de ações corretivas• Controle de conformidade ao planejamento

• Aceitação de entregas• Documentação de lições aprendidas• Liberação de recursos


Áreas de conhecimento

• Cada processo pode ser classificado dentro de uma área de conhecimento:– Gerenciamento de Integração– Gerenciamento de Escopo– Gerenciamento de Tempo– Gerenciamento de Custos– Gerenciamento de Qualidade– Gerenciamento de Recursos Humanos– Gerenciamento de Comunicações– Gerenciamento de Riscos– Gerenciamento de Aquisições


Gerenciamento de integração

• Coordenação do plano do projeto• Processos

– (A) Desenvolvimento do plano do projeto– (B) Execução do plano do projeto– (C) Controle integrado de mudanças

A

BC

Planejamento

ExecuçãoControle


Gerenciamento de escopo• Definição das atividades do projeto• Processos

– (A) Iniciação– (B) Planejamento de escopo– (C) Definição de escopo– (D) Verificação do escopo– (E) Controle de mudanças do escopo

A

DE

Iniciação

ExecuçãoControle

BPlanejamento

C


Gerenciamento de tempo

• Elaboração e controle do cronograma• Processos

– (A) Definição das atividades– (B) Seqüenciamento de atividades– (C) Estimativa de duração das atividades– (D) Desenvolvimento do cronograma– (E) Controle do cronograma

E

CDExecução

Controle APlanejamento

B


Gerenciamento de custos

• Estimativas de custos e recursos• Processos

– (A) Planejamento de recursos– (B) Estimativa de custos– (C) Elaboração de orçamentos de custos– (D) Controle de custos

D

CBExecução

Controle APlanejamento


Gerenciamento da qualidade

• Assegura o projeto atender os requisitos• Processos

– (A) Planejamento da qualidade– (B) Garantia de qualidade– (C) Controle de qualidade

A

BC

Planejamento

ExecuçãoControle


Gerenciamento de recursos humanos

• Interação entre pessoas– Liderança, orientação, resolução de conflitos, avaliação de

desempenho,...

• Processos– (A) Planejamento organizacional– (B) Montagem de equipes– (C) Desenvolvimento de equipes

A

BC

Planejamento

Execução


Gerenciamento de comunicações

• Garantir o bom fluxo de informações• Processos

– (A) Planejamento de comunicações– (B) Distribuição de informações– (C) Relatório de desempenho– (D) Encerramento administrativo

A

BC

Planejamento

ExecuçãoControle D Encerramento


Gerenciamento de riscos

• Identificação, análise e contorno de potenciais riscos• Processos

– (A) Planejamento de gerenciamento de riscos

– (B) Identificação de riscos

– (C) Análise qualitativa de riscos

– (D) Análise quantitativa de riscos

– (E) Planejamento de respostas

– (F) Monitoramento e controle de riscos

D

C

B

Controle

A

Planejamento

E

F


Gerenciamento de aquisições

• Compra de bens ou serviços externos• Processos

– (A) Planejamento de aquisições

– (B) Planejamento de solicitações

– (C) Solicitação de propostas

– (D) Seleção de fornecedores

– (E) Gerenciamento de contratos

– (F) Encerramento de contratos

D

C

B Encerramento

A

Planejamento

E

F

Execução


Ferramentas dePlanejamento

Como isso se enquadra em projetos de desenvolvimento de software?

• Ferramentas de planejamento– Como definir o escopo do software a ser desenvolvido?– Como estimar seu custo?– Como avaliar os riscos associados?

• Metodologia de desenvolvimento de software– Como assegurar as restrições de Prazo, Custo e Qualidade

Metodologia dedesenvolvimento de software

Metodologia de gerenciamento de projetos


Planejamento (PMBOK)

• Escopo• Tempo• Custos• Qualidade• Recursos humanos• Comunicações• Riscos• Aquisições• Integração

• Planejamento do escopo• Definição do escopo• Definição das atividades

• Seqüenciamento das atividades• Estimativa de duração das atividades• Desenvolvimento do cronograma

• Planejamento de recursos• Estimativas de custos• Elaboração de orçamentos• Planejamento da qualidade

• Planejamento organizacional• Montagem de equipes• Planejamento de comunicações• Planejamento de gerência de riscos

• Identificação de riscos• Análise de riscos• Planejamento de respostas

• Planejamento de aquisições• Planejamento de solicitações

• Desenvolvimento do plano de projeto


“implementando” o framework

• Escopo– Como definir o escopo de um software?

• Tempo– Como estimar o tempo de desenvolvimento?

• Custos– Como estimar os custo de desenvolvimento?

• Riscos– Como minimizar os riscos?

• Qualidade– Como garantir a qualidade do software?

• Recursos Humanos– Como definir minha equipe? Que papéis? Como gerenciá-la?

• Comunicação– Como compartilhar informações?

Metodologia dedesenvolvimento


Definindo o escopo de uma aplicação

• Essencial para definir o sucesso de um projeto– O produto deve atender a um conjunto de requisitos

• O que são requisitos?– Descrição de necessidades ou desejos para um produto

• Elaboração de requisitos– 1º passo para todas as demais atividades– Se todos os requisitos forem identificados no início do projeto (!!!)

não haverá surpresas na entrega do produto

• Etapas– Analisar o problema– Identificar as necessidades– Definir as características do sistema


Analisando o problema

• Muitos projetos de software não têm sucesso devido ao pouco investimento:

– No entendimento dos reais problemas das organizações– Na coleta das necessidades– No ambiente que o sistema vai estar inserido

• Passos da análise de um problema1. Concordância sobre a definição do problema2. Identificação dos interessados no projeto3. Identificação da “fronteira” do projeto4. Identificação das restrições do projeto5. Elaboração de um vocabulário comum


Identificando as necessidades


Identificando as necessidades (1)

• Principais causas de atrasos e cancelamento de projetos

Requisitos incompletos 13,1%

Falta de envolvimento do usuário 12,4%

Falta de recursos 10,6%

Expectativas não realistas 9,9%

Falta de apoio executivo 9,3%

Mudança de requisitos 8,7%

Falta de planejamento 8,1%

Projeto se tornou desnecessário 7,5%

Falta de gerenciamento 6,2%

Outros 16,2%The Standish Group´s CHAOS report


Identificando as necessidades (2)

• Porque é difícil identificar as necessidades do usuário?

– O usuário sabe o que quer, mas não sabe como quer

– Desejo que “partir pra execução”

– Falta de entendimento comum

• Técnicas

Técnica Facilidade de comunicação

Brainstorming Baixa

Role playing Baixa

Protótipo Média

Entrevista Alta


Definindo as características do sistema

• Definição de características de alto nível de abstração– Serviços que o sistema oferece para o usuário

• Categorização– Requisitos dos usuários– Requisitos do sistema– Requisitos funcionais– Requisitos não-funcionais

• Especificação em linguagem natural– Ex1: “Para acessar o protocolo via telefone, o usuário digitar o 9

durante ou logo após a mensagem. O sistema irá responder com uma mensagem informando os dados do protocolo”.

– Ex2: “O sistema terá três estados: em espera, informando opções ou informando dados. Para ir do estado de espera para o estado ...”


Refinando os requisitos

• Requisitos do produto– Funcionalidades– Descrição em linguagem natural

• Requisitos detalhados– Cada metodologia utiliza sua própria ferramenta

• Exemplo 1: Casos de uso (UP)• Exemplo 2: História do usuário (XP)


Estimativa de tempo / custo em projetos de software

• Tempo e custo estão associados a volume de trabalho e a experiência da equipe

• Métricas de software– Correlaciona projetos anteriores com os atuais– É possível “medir” um software?– Caso:

• Qual o tempo necessário para se desenvolver um portal de educação para o estado?

• Tipos de métricas– Orientadas ao tamanho– Orientadas a função– Orientadas a objeto– Modelagens paramétricas


Métricas orientadas ao tamanho

• Ex: Projeto TV Digital Brasileira– Setop Box, S.O., middleware, aplicações– JavaTV

• Qual é o tamanho do pacote JavaTV?

• Quanto tempo a Sun levou desenvolvendo?

• Tamanho– Linhas de código (LOC)

• LOC realmente mede tamanho?– Herança do modelo de manufatura

• “Quantas peças foram produzidas?”

– Não, mas provê indicativos de produtividade e qualidade• Produtividade: K-LOC / pessoa-mês

• Qualidade: bugs / K-LOC


Métricas orientadas a função

• Medição de software do ponto de vista do usuário– Como os usuários “enxergam” o sistema– Mede o que o sistema faz e não como é feito

• Medição por “Ponto-por-função” (FP)– Dados quantitativos

• número de funcionalidades– Dados qualitativos

• Avaliação empírica da complexidade das funcionalidades

• Características– Fornece medidas consistentes– Mede funcionalidades– Independente de tecnologia (ling. de programação)– Simples

• Realmente mede esforço?– Aplicações O-O baseadas em reutilização?


Métricas orientadas a objeto

• Similar ao LOC porém examina atributos em termos de O-O– Herança, polimorfismo, encapsulamento, etc.

• Número significativo de contagens:– Número de classes– Número de métodos– Média de métodos por classe– Média de linha de código por método– Profundidade máxima de hierarquia– Profundidade média– Etc.

• Realmente mede esforço?– Mesmo que LOC, porém com um nível de abstração maior– Indicadores de produtividade


Estimando erros

• Há sempre uma relação linear entre número de pessoas e tempo?

• E o tempo necessário para se chegar aos requisitos (funcionalidades)?

• E as mudanças ocasionais durante o projeto (quando não houver, desconfie se o projeto não está sendo deixado de lado)?

• E os bugs que aparecerão (sempre ocorrerá)?• E as dependência de componentes?


Esforço tempo e custo

• LOC, PF,... medem esforço (vol. de trabalho)• Mas como estimar tempo?

– A produtividade da equipe pode ser medida (métrica) em projetos anteriores em PF/homem-mês

– Caso fictício• produtividade da equipe = 15 PF/HM• Sistema correspondente a 750 PF• PF = num.desenvolvedores * meses * produtividade• 750 = num.desenvolvedores * meses * 15• num.pessoas = 50 / meses, ou• meses = 50 / num.desenvolvedores• Restrição do projeto: 1 ano num.desenvolvedores = 50 / 48 ≈ 4]

• “Nove mulheres podem gerar um bebê em um mês?”– Brooks, F. (1975) The Mythical Man-Month


Minimizando riscos

• Projetos de software gerenciamento de mudanças– Riscos relacionados ao projeto: afetam a programação– Riscos relacionados ao produto: afetam a qualidade do software– Riscos relacionados aos negócios: afetam a organização

Risco Tipo

Rotatividade de pessoal Projeto

Mudança de gerenciamento Projeto

Indisponibilidade de recursos Projeto

Alteração nos requisitos Projeto e produto

Atrasos na especificação Projeto e produto

Esforço subestimado Projeto e produto

Ferramentas inadequadas Produto

Mudança de tecnologia Negócios


Gerenciamento de riscos

• Identificação– Tecnologia, pessoal,

organizacional, ferramentas, requisitos, estimativas

• Análise– Avaliação de probabilidade e

conseqüência dos riscos– Definição de prioridades

• Planejamento– Estratégias preventivas– Estratégias de minimização– Planos de contingência

• Monitoramento– Avaliação periódica de tendências

Identificação

Análise

Planejamento

Monitoramento

Lista de riscos em potencial

Lista de riscos priorizados

Plano de prevenção e contingência

Avaliação de riscos


Garantindo a qualidade

• Do processo ou do produto?• Atividades

– Garantia de qualidade– Planejamento de qualidade– Controle de qualidade

• Módulo específico no curso: GTI-17


Atividade em grupo

• Avalie os processos de software existentes no seu setor– Como as metas dos projetos são traçadas?– Como o escopo de um projeto e de um produto é definido?– Como os requisitos são levantados? As restrições são traçadas?– Há um planejamento de recursos? Como ele é feito?– Como as estimativas de custo e tempo são realizadas?– Há um planejamento de pessoal?– Como as modificações no planejamento são operacionalizadas?– Os riscos dos projetos são levados em conta?– Há um processo de execução definido?– Há uma forma de avaliação / controle sobre a execução?– Há uma avaliação de desempenho? Como?– O projeto é documentado para futuros projetos? O que é

documentado?

Documents

Gestão da Tecnologia de Informação Gerenciamento de Projetos de Software – GTI16 Prof. André Campos 22 a 25 de novembro de 2005