Aulas14e15-GPR

Introdução à Engenharia de

Software – Aulas 14 e 15

Gerência de Projetos de Software

Primeira Parte

Roteiro

● Projeto de Software

● Gerência de Projeto de Software (GPR) ● Motivação

● O Papel do Gerente de Projeto ● Principais Conceitos

Relação entre os Conceitos Objetivos

Problema e Escopo Estimativa

Cronograma Riscos

Definições de Projeto

● Empreendimento temporário realizado para criar um

produto, serviço ou resultado único – PMBOK

● Esforço com datas definidas de início e fim, gasto para

gerar um produto ou serviço de acordo com requisitos e recursos estabelecidos – ISO/IEC 12207

Definições de Projeto

● Empreendimento em que recursos humanos,

financeiros e materiais são organizados de forma a realizar um escopo de trabalho único sobre uma dada especificação, dentro de restrições de tempo e custo, para obter uma mudança benéfica e individualizada, através da entrega de objetivos qualitativos e quantificados - Turner, J.R. The Handbook of Project Based Management: Improving Processes for Achieving Your Strategic Objectives. 1992

Quatro P's

PROJETO PESSOAS PROCESSO

Gerência de Projeto de Software

(GPR)

Definições de Gerência de Projeto

de Software

● A arte de direcionar e coordenar recursos humanos

e materiais para atingir objetivos bem definidos, dentro de limites de tempo e orçamento, e satisfazendo os

participantes do projeto

● A aplicação de conhecimento, habilidades,

ferramentas, e técnicas às atividades de projeto de

forma a atender ou superar as necessidades e

Propósito da GPR

● Segundo o MPS.BR:

Estabelecer e manter planos que definem as

atividades, recursos e responsabilidades do projeto

Prover informações sobre o andamento do projeto que

permitam a realização de correções quando houver

Propósito da GPR

● Continuação:

O propósito deste processo evolui à medida que a organização cresce em maturidade

A partir do nível E, alguns resultados evoluem e outros são incorporados, de forma que a gerência de projetos passe a ser realizada com base no processo definido para o projeto e nos planos integrados

No nível B, a gerência de projetos passa a ter um enfoque quantitativo, refletindo a alta maturidade que se espera da

Alguns Problemas Típicos

● Custos mal dimensionados

● Cronogramas não realistas

● Não se atinge os objetivos definidos ● Falta clareza nos objetivos

● Faltam indicadores de desempenho

● Faltam premissas sólidas para estimar ● Faltam definições acerca de papéis e de

responsabilidades

● Há pouca participação e comprometimento dos níveis

operacionais ou gerenciais

● Há falhas na comunicação da equipe

Dificuldades Específicas

● Projetos de software são difíceis porque software é...

Complexo

● Tamanho, número de estados, precisão e detalhamento

Invisível

● Imaterialidade, Intangibilidade, Entidade Conceitual e

Abstrata

Modificável

● Mudanças “simples e fáceis”, evolução constante e

contínua

A Idéia

● Princípios técnicos e gerenciais devem guiar o

planejamento e o acompanhamento de projetos de software

O planejamento indica o caminho certo

● Onde queremos chegar e quais os recursos disponíveis?

Sem acompanhamento não sabemos se o plano está sendo seguido, ou se há problemas não previstos

Um Cenário da Síndrome dos 90%

Era uma vez, um jovem engenheiro que foi escolhido para “escrever” um programa de computador.

Conhecia Assembly e FORTRAN, mas não sabia nada sobre engenharia de software, muito menos sobre planejamento e acompanhamento de projetos...

Seu chefe lhe passou alguns manuais e uma descrição verbal do que tinha que ser feito.

Um Cenário da Síndrome dos 90%

O jovem engenheiro leu os manuais e começou a escrever código.

Depois de duas semanas o seu chefe queria saber como estava o projeto.

“Está muito bem!” - disse o engenheiro com entusiasmo juvenil - “Era bem mais simples do que eu pensava! Estou provavelmente perto de 75% do fim.”

O chefe sorriu e o encorajou a continuar naquele ritmo. Combinaram um novo encontro dentro de uma semana.

Um Cenário da Síndrome dos 90%

Depois de uma semana o chefe chamou novamente o engenheiro para saber sobre o andamento do projeto.

“Tudo está indo bem!” - disse o jovem - “Mas eu tive alguns pequenos problemas. Vou tratá-los e logo tudo estará nos trilhos novamente.”

“Mas como fica o nosso prazo?” - perguntou o chefe. “Não haverá problemas. Estou perto de 90% do fim do projeto.”

Um Cenário da Síndrome dos 90%

O jovem engenheiro ficou perto dos 90% de completude pelo resto do projeto. O projeto só foi finalizado, com a ajuda de outros, com um mês de atraso.

Papel do Gerente de Projeto

● O

gerente de um projeto deve eliminar todos os

obstáculos que afastam os desenvolvedores do

trabalho realmente importante: melhorar a qualidade

do produto

Preocupações do Gerente de

Projeto

Formação da equipe Estimativa de custo Definição de cronograma Monitoramento do projeto Disponibilidade de recursos

Comunicação com cliente Avaliação de riscos

Qualidade do produto

Trabalho do Gerente de Projeto

● Fatores críticos de sucesso

Definir corretamente o escopo do problema Negociar com todos os envolvidos

Manter a motivação inicial Acompanhar o progresso

Tomar decisões adequadas e em tempo Guardar histórico do projeto

Trabalho do Gerente de Projeto

● Sem estes fatores

críticos o projeto pode enfrentar problemas

● Infelizmente não há

muitas opções de correção...

Conceitos Importantes

● Objetivo ● Escopo ● Estimativas Tamanho Tempo Esforço Custo ● Recursos ● Equipe ● Ciclo de Vida ● Marcos ● Cronograma ● Orçamento ● WBS e PBS ● Viabilidade ● Comunicação ● Riscos Problema

Relação entre os Conceitos

Objetivo Escopo Estimativas Recursos Equipe Atividades Ciclo de Vida Marcos PBS Comunicação Riscos Cronograma

Relação entre os Conceitos

Plano de Projeto

Execução do Projeto

Objetivo

● Resultado específico que deve ser alcançado pelo

projeto

● Expressa uma intenção descrita como uma mudança

proposta

● É observável e mensurável

● Clareza nos objetivos é fator crítico para o sucesso do

Hierarquia de Objetivos

● Meta: Razão do projeto; aquilo que justifica a sua

existência

Escopo: Os objetivos específicos para atingir a meta do

projeto

● Requisitos: Necessidades específicas atendidas pelo

projeto

● Restrições: Limitações impostas ao projeto

Exemplo de Hierarquia de Objetivos

● Meta:

Adaptar o sistema às mudanças ocorridas na lei 8045/2006 do ICMS

● Escopo:

Registrar notas fiscais inter-estaduais segundo as alíquotas definidas na lei

● Requisitos:

Cadastrar as alíquotas de cada estado

Calcular o imposto devido na nota fiscal de acordo com a alíquota do estado destino

● Restrições:

O sistema deve operar de acordo com a nova legislação a partir de 20/09/2006

Dica Sobre Escrita de Objetivos

● Utilize verbos fortes

Fraco Coordenar Participar Contribuir Assistir Apoiar Melhorar Integrar Fomentar Colaborar FORTE Estabelecer Cadastrar Instalar Erradicar Registrar Dirigir Eliminar Imprimir Apresentar Excluir

Problema do Projeto

● Planejar exige compreensão do problema

● Esta descoberta de informações sobre o problema será

essencial para as estimativas necessárias para o planejamento

● Exemplos de técnicas para obter compreensão:

Reuniões e entrevistas preliminares com especialistas na área

Perguntas Relevantes

● Quem está por trás do pedido desse trabalho? ● Quem vai utilizar a solução?

● Qual será o benefício econômico de uma solução de

sucesso?

● Existem outras alternativas de solução?

● Quais são as fontes de informação sobre o problema? ● Como o cliente caracteriza “boas” saídas geradas por

Perguntas Relevantes

● Que problemas essa solução vai atacar?

● Existe alguma restrição que afetará a solução? Algum

limite de desempenho, por exemplo?

● Em que ambiente a solução será utilizada? ● Existem outras alternativas de solução?

Meta Perguntas

● Você é a pessoa mais indicada para fornecer essas

respostas?

● Há outras pessoas que eu deveria consultar? ● Suas respostas são “oficiais”?

● Minhas questões foram relevantes? ● Estou fazendo perguntas demais?

Escopo do Produto

● Descreve, em alto nível:

Dados e controles a serem processados Funções

Interfaces Restrições

Desempenho, confiabilidade e outras características de qualidade

● Em essência é uma narrativa que delimita o problema ● Geralmente é feita uma decomposição

WBS e PBS

● Escopo do Produto x Escopo do Projeto ● Escopo do projeto inclui

Objetivos, restrições, premissas...

● É possível incluir, como parte do escopo do projeto

Uma WBS (Work Breakdown Structure – Estrutura Analítica do Projeto)

Uma PBS (Product Breakdown Structure – Estrutura Analítica do Produto)

Estimativas de Software

● Planejamento envolve estimativa acerca da

quantidade de dinheiro, esforço, recursos e tempo

necessário para construir um produto

● Por que é importante?

Abordagem “Indiana Jones” é arriscada quando se quer construir um artefato complexo

● Por onde começar?

Estimativa se inicia com a descrição do escopo do produto

● Qual o resultado?

Definição de tarefas e respectivas estimativas de custo, esforço e tempo

Cenário Típico

EXECUTIVO: Quanto tempo você acha que este projeto

demorará? Precisamos deste software em três meses para uma demonstração. Não posso te dar mais nenhum recurso, e você terá que trabalhar com o pessoal que tem atualmente. Aqui está uma lista de funcionalidades que preciso

GERENTE DE PROJETO: Ok. Deixe-me avaliar alguns

Cenário Típico

Mais tarde...

GERENTE DE PROJETO: Nós estimamos que o projeto

levará cinco meses para ficar pronto...

EXECUTIVO: Cinco meses!? Você não me escutou?!

Eu disse que precisamos deste software pronto em três meses para uma demonstração!

Definição de Estimativa

● (1) Avaliação incerta ou cálculo grosseiro

● (2) Cálculo preliminar do custo de um projeto

● (3) Julgamento baseado em impressões; opinião

The American Heritage Dictionary, Second College Edition, 1985

● Geralmente executivos querem saber de compromissos

ou de planos para alcançar um objetivo de negócio

● Não assuma que as estimativas devem ser iguais ao

compromisso ou aos objetivos de negócio

Se um objetivo de negócio é desejável ou mesmo

Estimativas e Probabilidades

● Estimativas geralmente são apresentadas como

números pontuais

Único resultado possível

Probabilidade 100%

Estimativas e Probabilidades

● Estimativas realistas consideram que projetos de

software

São cercados de incertezas

Podem ser acometidos por mudanças inesperadas Podem ser acometidos por problemas

● Os resultados de um projeto de software seguem na

realidade uma distribuição de probabilidades

Estimativas e Probabilidades

● Uma representação mais realista:

100%

Probabilidade

Prazo (ou custo ou esforço)

Resultado Nominal (Estimativa 50/50)

Teste

● Quão bom você é com estimativas?

● Para cada questão dada no slide seguinte preencha as

lacunas com limites inferiores e superiores que te dêem, na sua opinião, 90% de chance de acerto

Tome cuidado para não fazer o intervalo entre os limites nem muito grande nem muito pequeno

● 10 minutos para responder

● Observação sobre a autoria do teste:

“This quiz is from Software Estimation by Steve McConnell (Microsoft Press, 2006) and is © 2006 Steve McConnell. All Rights Reserved. Permission to copy this quiz is granted provided that this copyright

Perguntas do Teste

1) Temperatura da superfície do sol – graus centígrados 2) A latitude de Shanghai – graus para sul ou para norte 3) Área do continente asiático – km2

4) O ano de nascimento de Alexandre, o Grande – ano (AC ou DC)

5) Valor total de moeda corrente em circulação nos E.U.A. Em 2004 – dólares

6) Volume total dos Grandes Lagos, na América do Norte – litros ou km ao cubo

7) Receita mundial total do filme Titanic – dólares

Respostas do Teste

1) Temperatura da superfície do sol – 6000º C

2) A latitude de Shanghai – 31 graus para o Norte

3) Área do continente asiático – 44.390.000 km2

4) O ano de nascimento de Alexandre, o Grande – 356 AC

5) Valor total de moeda corrente em circulação nos E.U.A. Em 2004 – $719,9 bilhões de dólares

6) Volume total dos Grandes Lagos, na América do Norte – 6,8 x 10^23 litros (23.000 km ao cubo)

7) Receita mundial total do filme Titanic – 1,835 bilhões de dólares

8) Cumprimento total da costa do Oceano Pacífico – 135.663 km

Teste

● Quantos pontos você fez?

● Resultados da aplicação do teste:

Participantes 15% 10% 20% 25% 5%

Lições do Teste

● Se estávamos estimando com 90% de confiança, então

teríamos que ter acertado 9 questões!

● Percentuais específicos de confiança não tem

significado real se não são apoiados por alguma análise estatística

● Evite a utilização de intervalos artificialmente pequenos ● Você sentiu pressão para fazer os intervalos entre os

limites menores ou maiores?

● Se você se sente pressionado a fazer os intervalos

menores, poderá verificar facilmente que esta pressão geralmente vem de uma fonte externa, e não de você

Representatividade do Teste

● Quão representativo é este teste para estimativas de

software reais?

● Gerentes de software geralmente têm que estimar

Projetos em áreas de negócio com as quais não estão familiarizados

Projetos que implementam novas tecnologias Impacto de novas ferramentas na produtividade A produtividade de pessoal desconhecido

Alternativa para o Cenário Típico

EXECUTIVO: Quanto tempo você acha que este projeto

demorará? Precisamos deste software em três meses para uma demonstração. Não posso te dar mais nenhum recurso, e você terá que trabalhar com o pessoal que tem atualmente. Aqui está uma lista de funcionalidades que preciso

GERENTE DE PROJETO: Deixe-me ver se entendo o

que você está me pedindo. É mais importante pra gente entregar 100% destas funcionalidades, ou é mais importante ter algo pronto para a demonstração?

Alternativa para o Cenário Típico

EXECUTIVO: Temos que ter algo pronto para a

demonstração. Gostaríamos que fosse 100% das funcionalidades, se possível.

GERENTE DE PROJETO: Quero ter certeza de que

satisfarei suas prioridades. Acontece que não conseguiremos entregar 100% das funcionalidades a tempo para a demonstração. Devemos estar preparados para lançar o que tivermos pronto na época da demonstração ou devemos nos organizar para entregar

Alternativa para o Cenário Típico

EXECUTIVO: Temos que ter algo pronto para a

demonstração. Logo, no pior caso temos que entregar algo, mesmo que não seja 100% do que queremos.

GERENTE DE PROJETO: Ok. Bolarei um plano para a

entrega do maior número possível de funcionalidades que pudermos entregar em três meses.

Tamanho de Software

● Estimativa de projeto é tão boa quanto a estimativa de

tamanho do trabalho a realizar

● Tamanho de software é geralmente estimado usando

métricas como

LOC (Lines of Code – Linhas de Código) FP (Function Points – Pontos de Função) OP (Object Points – Pontos de Objeto)

● Estimativa de tamanho deve ser feita no início do

Estimativa de Produtividade

● Relação entre tamanho de produto correto e esforço

necessário para gerá-lo

Exemplo: LOC/PM (linhas de código por pessoa-mês)

● Uso de LOC pode ser problemático

O que é uma linha de código nas linguagens atuais?

Quanto mais expressiva a linguagem menor a produtividade aparente

● Uso de métricas associadas a funcionalidade é uma

alternativa

Mas estimativas baseadas em funcionalidade geralmente são altamente dependente das pessoas fazendo as

Técnicas de Estimativa

● Modelagem Algorítmica

Um modelo é desenvolvido usando informações históricas de custo que relacionam alguma métrica de software (geralmente o tamanho) ao custo. Uma estimativa desta métrica é feita e a partir do modelo o custo é previsto.

● Opinião de especialista

Vários especialistas (no domínio da aplicação, nas técnicas de desenvolvimento) são consultados. Cada um estima o custo. Estas estimativas são comparadas, discutidas e refeitas até que seja obtido consenso.

Técnicas de Estimativa

● Lei de Parkinson

O trabalho se expande para preencher o tempo disponível O custo é avaliado a partir dos recursos disponíveis

● Preço para Ganhar

A estimativa de custo do projeto é exatamente aquilo que o cliente tem disponível para gastar com o projeto

O esforço dependerá do orçamento do cliente e não da funcionalidade do software

Cronograma

● Princípios de Cronograma

Decomposição de tarefas e respectivos produtos Identificação de interdependências entre tarefas

Distribuição do esforço para as pessoas ao longo do tempo

Garantia de que os recursos estarão disponíveis Atribuição de responsabilidades a indivíduos

Resultados mensuráveis devem ser definidos para cada tarefa

Negociação do Cronograma

● O gerente de projeto deve proteger sua equipe de projetos

com cronograma impossível

Estimativas, métricas e base histórica são essenciais para provar a inviabilidade de cronogramas “impostos”

● Alternativas de negociação

Aumentar os recursos do projeto Diminuir o escopo do software

Evolução do Cronograma

● Tipos de Planejamento

Estratégico: abstrato e de longo prazo Tático: detalhado e de curto prazo

● Inicialmente há um macro-cronograma

Principais atividades, produtos e deadlines (prazos)

● Antes de cada nova etapa define-se um cronograma

detalhado

Relação entre Esforço e Pessoas

● A relação entre pessoas e tempo não é linear

O mito do homem-mês

● Se o projeto atrasar, basta adicionar mais pessoas

● Adicionar pessoas a uma equipe

Dificulta a comunicação

● Mais caminhos de comunicação

● Caminhos mais complexos e com mais ruído

Interrompe o trabalho

● Repasse de informações e orientação dos novos

Exemplo de Alocação de Esforço

● Atividades “front-end”

Comunicação com cliente Análise Projeto Revisão e modificação ● Atividades de construção Codificação ● Teste e instalação Teste unitário e de integração 40-50% 40-50% 30-40% 30-40% 15-20% 15-20%

Rede de Tarefas

I . 1 C o n c e p t s c o p i n g I . 3 a T e c h . R i s k A s s e s s m e n t I . 3 b T e c h . R i s k A s s e s s m e n t I . 3 c T e c h . R i s k A s s e s s m e n t T h r e e I . 3 t a s k s a r e a p p l i e d i n p a r a l l e l t o 3 d i f f e r e n t c o n c e p t f u n c t i o n s T h r e e I . 3 t a s k s a r e a p p l i e d i n p a r a l l e l t o 3 d i f f e r e n t c o n c e p t f u n c t i o n s I . 4 P r o o f o f C o n c e p t I . 5 a C o n c e p t I m p l e m e n t . I . 5 b C o n c e p t I m p l e m e n t . I . 5 c C o n c e p t I m p l e m e n t . I . 2 C o n c e p t p l a n n i n g I . 6 C u s t o m e r R e a c t i o n I n t e g r a t e a , b , c

Gráfico de Gantt (de Barras)

I . 1 . 1 I d e n t if y n e e d a n d b e n e f i t s M e e t w it h c u s t o m e r s I d e n t if y n e e d s a n d p r o j e c t c o n s t r a i n t s E s t a b l is h p r o d u c t s t a t e m e n t M i l e s t o n e : p r o d u c t s t a t e m e n t d e f i n e d I . 1 . 2 D e f i n e d e s i r e d o u t p u t / c o n t r o l / i n p u t ( O C I ) S c o p e k e y b o a r d f u n c t i o n s S c o p e v o i c e in p u t f u n c t i o n s S c o p e m o d e s o f in t e r a c t i o n S c o p e d o c u m e n t d i a g n o s t i c s S c o p e o t h e r W P f u n c t io n s D o c u m e n t O C I F T R : R e v ie w O C I w i t h c u s t o m e r R e v i s e O C I a s r e q u i r e d ; M i l e s t o n e ; O C I d e f i n e d I . 1 . 3 D e f i n e t h e f u n c t i o n a li t y / b e h a v io r D e f i n e k e y b o a r d f u n c t i o n s D e f i n e v o i c e in p u t f u n c t i o n s D e c r ib e m o d e s o f in t e r a c t i o n D e c r ib e s p e l l/ g r a m m a r c h e c k D e c r ib e o t h e r W P f u n c t io n s F T R : R e v ie w O C I d e f i n i t i o n w i t h c u s t o m e r R e v i s e a s r e q u i r e d M i l e s t o n e : O C I d e f i n t i t i o n c o m p l e t e I . 1 . 4 I s o la t e s o f t w a r e e l e m e n t s M i l e s t o n e : S o f t w a r e e l e m e n t s d e f i n e d I . 1 . 5 R e s e a r c h a v a i la b i l it y o f e x i s t in g s o f t w a r e R e s e a c h t e x t e d i t i o n g c o m p o n e n t s R e s e a r c h v o ic e i n p u t c o m p o n e n t s R e s e a r c h f i l e m a n a g e m e n t c o m p o n e n t s R e s e a r c h S p e ll / G r a m m a r c h e c k c o m p o n e n t s w e e k 1 w e e k 2 w e e k 3 w e e k 4 W o r k t a s k s w e e k 5

Princípio W5HH para Gestão

● Por que (Why) o projeto deve ser desenvolvido? ● O que (What) vai ser feito?

● Quando (When) vai ser feito?

● Quem (Who) é responsável por uma dada tarefa? ● Onde (Where) os envolvidos estão localizados na

organização?

● Como (How) o trabalho será conduzido técnica e

gerencialmente?

Referências

Sommerville, I. (2007) Software Engineering. Oitava Edição. Addison-Wesley

Pressman, R. S. (2005) Software Engineering – A Practitioner's Approach. Sexta Edição. MCGraw-Hill

McConnell, S. (2006) Software Estimation – Demystifying the Black Art. Microsoft Press.