Planejamento e Gerência de Projetos · Processo definir o escopo [email protected] Engenharia de Software Entradas: Termo de abertura Ativos e processos organizacionais

Profª Rafaella Matos

Planejamento e Gerência de

Projetos (cont.)

[email protected] Engenharia de Software

Declaração de escopo

Engenharia de Software [email protected]

Processo definir o escopo


Entradas: Termo de abertura Ativos e processos organizacionais

Ferramentas e técnicas Opinião especializada Análise de produto Identificação de alternativas Oficinas

Saídas: Declaração do escopo do projeto Atualização de documentos do projeto

Especificação do escopo

Escopo do produto:

Características e funcionalidades

que o produto deve ter quando estiver

pronto

Escopo do projeto:

Trabalho que deve ser feito para

construir o produto



Planejador do projeto estabelece quais os

objetivos finais

Definir onde o projeto vai chegar é

necessário para se estabelecer um bom

plano

O objetivo do projeto deve ser um conjunto

de artefatos, coisas palpáveis



Objetivos não devem ser descritos como:

Executar “tal” ação

Gerar “tal” diagrama ou “tal” relatório

Implementar “este” ou “aquele” requisito



a) Descrição do produto do projeto

Refinamento da definição do produto descrito em

alto nível no termo de abertura

Não inserção de novas características em

relação ao termo de abertura

Qualquer alteração deverá ser negociado pelas

partes



b) Principais entregas do projeto Momentos em que o cliente recebe alguma

entrega do desenvolvedor

Normalmente versões implementadas do sistema

Lista poderá incluir outros itens como Projeto

Manuais

Discos de instalação

Treinamento

Etc.

Engenharia de Software


c) Objetivos do projeto

Itens quantificáveis que serão usados para determinar se

o projeto foi um sucesso ou não

Devem incluir

Planos ou métricas relacionadas a prazo

Custo e qualidade do produto

Podem ser quantificáveis

Cliente satisfeito

Sistema fácil de usar

Evitar objetivos vagos e de avaliação subjetiva

Desenvolver tecnologia de última geração Engenharia de Software


d) Critérios de aceitação

Definir o processo e os critérios para que o produto,

como um todo seja aceito e o projeto seja finalizado



d) Outras informações:

Principais riscos

Tecnologias a serem usadas

...



É o documento-base em que deve haver

concordância entre cliente e gerente de

projeto

A partir deste documento o projeto com um

todo passa a ser planejado



Momento em que a análise de requisitos

ainda não foi realizada

Processo posterior que aprofunda o escopo

As informações contidas na declaração do

escopo são frutos de entendimentos prévios

A análise de requisitos que virá depois

deverá aprofundar o escopo, mas não

aumentá-lo em abrangência


Por exemplo:

Na análise de requisitos pode-se detalhar como será

realizado o processo de venda, mas, se não estava

prevista a implementação de uma folha de pagamento na

declaração do escopo, então, a necessidade de inclusão

desse item se tornará necessária a renegociação do

escopo com o cliente.



Exemplo: Descrição do escopo combinado com

cliente/solicitante

Este projeto tem como escopo a realização de uma turma

de treinamento em gerenciamento de projetos, tendo

como público alvo os profissionais que trabalham em

projetos de Tecnologia da Informação e de Engenharia.

Esse treinamento deve ter como base a metodologia

“Basic Methodware” de gerenciamento de projetos.


Problema!

Especificar o escopo do produto (sem planejamento)

para posteriormente especificar o escopo do projeto

Especificar o escopo do projeto (impreciso) e uma das

atividades ser a especificação do escopo do produto


Solução Para a especificação de escopo do projeto, é possível iniciar

com o escopo do produto

O nível de refinamento e detalhe será diretamente proporcional ao risco envolvido

Existem diferentes opções para especificar o escopo do produto:

Documento de visão (RUP)

Histórias (métodos ágeis)

Casos de uso

Cenários

Narrativa livre

Etc

O plano deve ser refinado sempre que mais conhecimento for adquirido


Detalhar o escopo

Granularidade:

Nível de detalhe adotado à medida que um plano de

projeto é desenvolvido

Granularidade fina:

Fornece mais detalhes das atividades que são

planejadas para prazos mais curtos, com maior

acompanhamento e controle

Granularidade grossa:

Fornece menos detalhes das atividades e são

planejadas com prazos maiores


Detalhar o escopo Planejar em granularidade grossa é uma atividade

propensa a erros

Para evitar:

Aplicar a técnica dividir para conquistar Quebrar o problema em problemas menores

Planejar em granularidade fina

Inferir o planejamento completo a partir das partes

Documento resultante (método clássico)

Estrutura analítica do projeto – EAP ou

Work Breakdown Structure – WBS


Estrutura Analítica do Projeto - EAP

Técnica criada nos EUA

pelo departamento de

defesa e NASA em 1962

Define elementos e suas

decomposições


Características da EAP

Não determina sequência entre elementos (somente

decomposição)

Precisa ter 100% de cobertura

O somatório do trabalho das partes deve ser

equivalente ao todo


Características da EAP

No primeiro nível é representado o produto

completo

No segundo nível podem ser representados

Fases do desenvolvimento

Produtos parciais

Nos demais níveis são representados

Decomposições das fases

Pacotes de trabalhos (tarefas)

Cada nível deve ser numerado: 1, 2.3, 5.3.4, etc


Exemplos de EAP


Como construir EAP

Abordagem top-down

Pense no panorama geral

Insira as grandes fases ou produtos parciais

Repita a decomposição para os demais níveis

Abordagem bottom-up

Faça um brainstorming com a equipe, visando

identificar tarefas pontuais necessárias

Organize as tarefas obtidas gerando fases ou

produtos parciais de alto nível


Quando parar de decompor a EAP?

Quando for possível estimar com segurança o

pacote de trabalho

Pacotes de trabalho muito grandes

Imprecisão nas estimativas

Incapacidade de monitoramento e controle

precisos

Pacotes de trabalho muito pequenos

Ineficiência no planejamento, monitoramento e

controle


Exercício

Faça uma EAP para o churrasco editando e

complementando a EAP parcial abaixo:


Definir as atividades

Para cada pacote de trabalho da EAP definir:

As atividades necessárias para gerar o pacote

de trabalho

Os recursos necessários para executar as

atividades

Exemplo para o pacote de trabalho 2.1 compar

bebidas

Atividade: ir ao supermercado adquirir as

bebidas

Recurso: uma pessoa, um carro, dinheiro


Definir a sequência das atividades

Para executar uma determinada atividade, outras

atividades precisam já ter sido concluídas

Assim é necessário estabelecer as

dependências (ou sequências) das atividades

Dependências para a atividade ir ao

supermercado adquirir bebidas

Definir a quantidade de bebidas a serem

compradas

Escolher supermercado com melhor preço


Exercício

Estabeleça atividades necessárias para

cada pacote de trabalho

Estabeleça a lista de dependência de

cada atividade


Planejamento em ciclos iterativos


Planejamento de projetos com ciclos

iterativos

Objetivo:

Criar um plano para o projeto como um todo

Atividades:

Estimar esforço total para realizar o projeto

Em função do esforço total, calcular o tempo

linear necessário e o tamanho médio da equipe

Estimar a duração e o esforço nas diferentes

fases do projeto

Estimar duração e o número dos ciclos iterativos


Estimativas de esforço

Conhecer o esforço em horas de trabalho

Objetivo:

Planejar um projeto conhecendo a sua duração e

custo.

Técnica mais antiga:

SLOC – baseada em linhas de código

Técnicas paramétricas:

Utilizam pelo menos um parâmetro como base


SLOC e KSLOC


LOC – Line of Codes

SLOC – Source Lines of Codes

Primeira técnica

Estimar o número de linhas que um

programa deverá ter, com base em opinião

de especialistas e no histórico de projetos

passados

Surgiu na época que as

linguagens de programação eram

fortemente orientadas a linhas de

código. Ex: FORTRAN

As linguagems atuais não são mais tão restritivas, fazendo mais sentido falar em comandos em vez de linhas

Rapidamente evoluiu para • KSLOC • MSLOC • GSLOC

Continua sendo uma medida popular

Estimação KSLOC


Consiste em reunir a equipe e discutir o sistema a ser

desenvolvido

Cada participante dá sua opinião sobre a quantidade de

KSLOC que será necessária para desenvolver o sistema,

dos quais deve-se chegar a 3 valores:

KSLOC = (4*KSLOCesperado+KSLOCotimista+KSLOCpessimista)/6

Essas estimativas devem ser comparadas com a

informação real ao final do projeto

Feedback ajuda a equipe em futuras previsões

1. KSLOC otimista 2. KSLOC

pessimista 3. KSLOC esperado

Estimação KSLOC


Erros de previsão de 20% ou 30% não são

significativos

Aceitável prever 10.000 linhas de código para um

projeto de 12.000 ou 13.000 linhas

Problema seria uma previsão de 10.000 linhas de

código para um projeto que ao final tivesse

30.000 ou 40.000 linhas

Erro de 200% e 300% respectivamente

Como contar linhas de código


Else conta?

Declaração de variável conta?

Em relação ao tipo de comando

Contáveis Não contáveis


Comandos executáveis

Declarações

Diretivas de compilação

Comentários

Linhas em branco

Em relação a forma como o código é

produzido



Linhas:

Programadas

Copiadas ou reusadas

modificadas

Linhas:

Geradas por geradores

automáticos

Removidas

Em relação aos comandos na

maioria das linguagens



Comandos:

Null, continue e no-op

Que instanciam elementos

genéricos

Pares begin-end ou {...} usados

em comandos estruturados

Comandos elseif

Palavras-chave como division,

interface e implementation

Comandos:

Vazios como “;”, quando sozinhos em

uma linha

Pares begin-end ou {...} usados para

delimitar bloco principal ou

procedimentos e funções

Expressões lógicas em comandos IF,

WHILE ou REPEAT

Símbolos que servem como

finalizadores de comandos executáveis

Símbolos THEN, ELSE, OTHERWISE,

qualdo sozinhos em uma linha

Exemplo


Exercício


Par begin-end usado para delimitar o bloco

principal de procedimentos e funções

Par begin-end usado em comando

estruturado

ELSE usado sozinho em uma linha

Comandos executáveis

Comandos vazio sozinho em linha

Quantas LOC tem o código abaixo?

TOTAL = 5 linhas de código

Outras técnicas baseadas em linhas

de código

COCOMO – Constructive Cost Model

COCOMO II ou CII: Adequada ao UP


Estimação para análise de pontos de

função

Análise por Pontos de Função – APF

Baseada em requisitos

Portanto aplicável a partir do momento que os

requisitos funcionais do sistema tenham sido

definidos

Estes são convertidos em valores numéricos e

ajustados a capacidade da empresa

desenvolvedora

Medida independente da linguagem de

programação e tecnologia aplicada


Estimação para análise de pontos de

função - APF

3 contagens específicas de pontos de função:

a) Contagem para desenvolvimento de projeto

Estima o esforço para o desenvolvimento de um novo

projeto

b) Contagem para melhoria de projeto

Usada para evolução de software, com funcionalidades

adicionadas, alteradas e removidas

c) Contagem de aplicação

Usada para contar pontos de função de aplicações

existentes.


Outras técnicas baseadas em

funcionalidades aparentes

Pontos de caso de uso

Compatível com o UP

Pontos de história

Preferida pelos adeptos de métodos ágeis


Estimação de duração do esforço

nas diferentes fases do projeto

Processo UP: 4 fases

Em um projeto típico com tamanho e esforço

moderados

a) Concepção: 10% do tempo e 5% do esforço

b) Elaboração: 30% do tempo e 20% do esforço

c) Construção: 50% do tempo e 65% do esforço

d) Transição: 10% do tempo e 10% do esforço


Processo UP – 4 fases

Um projeto típico onde o esforço (E) foi

estimado em 40 desenvolvedores-mês

(APF):

Tempo linear ideal (T):

T = 8,5 meses [email protected] Engenharia de Software

Exemplo de duração das fases: 40

desenvolvedores-mês

Concepção: 10% do tempo e 5% do esforço

Elaboração: 30% do tempo e 20% do esforço

Construção: 50% do tempo e 65% do esforço

Transição: 10% do tempo e 10% do esforço

__________________________________________

Concepção: 10% de 8,5 = 0,85 meses

Elaboração: 30% de 8,5 = 2,55 meses

Construção: 50% de 8,5 = 4,25 meses

Transição: 10% de 8,5 = 0,85 meses


Exemplo de tamanho médio da

equipe: 40 desenvolvedores-mês

Concepção: 10% do tempo e 5% do esforço

Elaboração: 30% do tempo e 20% do esforço

Construção: 50% do tempo e 65% do esforço

Transição: 10% do tempo e 10% do esforço

__________________________________________

Concepção: 5% de 40 = 2 desenvolvedores/mês

Concepção = 2 / 0,85

Média de 2,35 desenvolvedores na fase


Grafo de dependência entre as

atividades

Várias ferramentas permitem a

elaboração quase automática dos

grafos de dependência

Diagramas ou Rede PERT

Ferramenta gratuita: OpenProj

Definir:

Conjunto de atividades

Dependências

Duração


Principais práticas – Padrões de

gerenciamento de projetos


Project Management Body of Knowledge

(PMBOK)

ISO 10006: 1997, Quality management -

Guidelines to quality in project management;

PRINCE2™: Projects IN a Controlled

Environment

…

Considerações finais


Gerência de projetos é um assunto extenso,

muitas questões acabam por ser desprezadas

durante o desenvolvimento de um software

Um projeto que não é bem planejado desde o

início dificilmente será depois de iniciado

Planejamento e Gerência de Projetos · Processo definir o escopo [email protected] Engenharia de Software Entradas: Termo de abertura Ativos e processos organizacionais

Documents