Planejamento e Gerência de Projetos (cont.) Profª Rafaella Matos
Declaração de escopo
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
Declaração de escopo 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
Declaração de escopo Objetivos não devem ser descritos como: Executar tal ação Gerar tal diagrama ou tal relatório Implementar este ou aquele requisito
Declaração de escopo 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
Declaração de escopo 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.
Declaração de escopo 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
Declaração de escopo 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
Declaração de escopo d) Outras informações: Principais riscos Tecnologias a serem usadas...
Declaração de escopo É 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
Declaração de escopo 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
Declaração de escopo 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.
Declaração de escopo 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 Continua sendo uma medida popular Primeira técnica Rapidamente evoluiu para KSLOC MSLOC GSLOC Surgiu na época que as linguagens de programação eram fortemente orientadas a linhas de código. Ex: FORTRAN 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 As linguagems atuais não são mais tão restritivas, fazendo mais sentido falar em comandos em vez de linhas
Estimação KSLOC 1. KSLOC otimista 2. KSLOC pessimista Consiste em reunir a equipe e discutir o sistema a ser 3. KSLOC esperado 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
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 Comandos executáveis Declarações Diretivas de compilação Não contáveis Comentários Linhas em branco
Em relação a forma como o código é produzido Contáveis Linhas: Programadas Copiadas ou reusadas modificadas Não contáveis Linhas: Geradas por geradores automáticos Removidas
Em relação aos comandos na maioria das linguagens Contáveis 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 Não contáveis 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 Quantas LOC tem o código abaixo? 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 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
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