Gerência de Processos Processo Iterativo - Parte III

Apresentação em tema: "Gerência de Processos Processo Iterativo - Parte III"— Transcrição da apresentação:

1 Gerência de Processos Processo Iterativo - Parte III
Mestrado de Informática / UFPB Francilene Procópio Garcia, D.Sc. Processo Iterativo - Parte III

2 Planejamento é parte da Gestão!
O desafio: desenvolver um plano que melhor faça uso dos recursos disponíveis na produção de software… A gestão de projetos de software envolve a gerência de pessoas - organizadas em equipes - e a alocação de responsabilidades para geração de resultados A automação do processo de desenvolvimento a partir de um repositório digital de artefatos também apoia na gestão objetiva - a qualidade dos artefatos e suas mudanças medem a saúde do plano

3 Por Quê Iterativo? Tradicionalmente, os projetos eram organizados para acontecerem de forma sequencial - cada ciclo ocorria apenas uma vez - cascata Ciclos Iterativos são mais flexíveis e menos arricados ...

4 Planejamento do Processo Iterativo
Aspectos chaves: Os projetos podem se encaixar no que foi planejado ou não A quebra e o escalonamento de atividades (WBS) constituem a arquitetura de um plano. Deve encapsular as mudanças, evoluíndo através do ciclo de vida O custo e o cronograma podem ser estimados através de técnicas (top-down e bottom-up) de análise de projeto

5 Planejamento do Processo Iterativo
Como o desenvolvimento de software, o planejamento do projeto requer um processo iterativo Os planos contemplam duas partes: engenharia (desenvolvimento do plano) e produção (execução do plano) Os planos evoluem conforme o entendimento vai emergindo acerca do problema e de sua solução De forma similar, erros achados no início causam menor impacto ao sucesso do projeto

6 Estrutura de Escalonamento de Atividades
Um bom escalonamento de atividades (work breakdown structure - WBS) e sua sincronização com o framework do processo são críticos ao sucesso do projeto O escalonamento depende de alguns fatores: estilo de gestão do projeto cultura organizacional preferência do cliente limitações financeiras entre outros parâmetros específicos a cada projeto Resultado esperado: a quebra do projeto em tarefas discretas e objetivas

7 Estrutura Convencional do Escalonamento de Atividades
Alguns parâmetros auxiliam na decomposição do trabalho em tarefas: subsistemas do produto componentes funções unidades organizacionais fases do ciclo de vida localidades geográficas Em geral, alcança-se uma primeira decomposição via subsistemas (primeiro nível) e, em seguida, organizam-se os componentes

8 [Estrutura de Diretório do Produto]
Reúne todas os artefatos associados às versões produzidas - em resposta ao desenvolvimento do ciclo de vida Um sistema X, consiste de N subsistemas, cada subsistema pode envolver N componentes

9 [Estrutura de Diretório dos Subsistemas]
Reúne todas informações de um subsistema em particular O sistema y, por exemplo, apresenta três subsistemas (A, B e N) - cada um com suas informações acerca do design e implementação

10 [Estrutura de Diretório dos Componentes]
O número de componentes é resultado das decisões de projeto do subsistema. A estrutura de diretório que segue deve ser instanciada para cada componente

11 Dificuldades Típicas com o Escalonamento Convencional
Como são organizados prematuramente ao longo do projeto do produto (design), as vezes torna-se complicado lidar com mudanças São decompostos, planejados e orçados prematuramente - resultando em dados superficiais ou com muitos detalhes São específicos a cada projeto, de forma que comparações entre projetos são difíceis ou impossíveis

12 Saída: Escalonamento Evolutivo
O escalonamento deve evoluir com o framework do processo - e NÃO com o framework do produto Hierarquia básica : Primeiro nível - o fluxo de atividades (gestão, ambiente, requisitos, design, implementação, avaliação e entrega) - são, em geral, alocadas a um único grupo e contemplam formas de planejamento para comparação entre projetos Segundo nível - cada fase do ciclo de vida (elaboração, planejamento, construção e transição) - evoluem mais naturalmente com o crescente nível de entendimento dos requisitos, arquitetura e riscos Terceiro nível - focam nas atividades e artefatos presentes em cada fase - o menor nível da hierarquia, onde se levanta custos

13 Escalonamento Evolutivo
Aspectos a serem considerados: Escala. Projetos maiores terão maior número de subestruturas Estrutura organizacional. Projetos com subcontratantes ou envolvendo múltiplas entidades devem incluir diferentes necessidades e alocações Nível do desenvolvimento. Dependendo da caracterização do projeto, podem existir ênfases nos requisitos, no projeto, ou no fluxo de implementação. Por exemplo, um projeto de reengenharia (componentes existentes) deve ter foco nos requisitos Contexto do negócio. Projetos comerciais requerem, por exemplo, uma subestrutura bem elaborada p/ entrega Experiência anterior

14 Escalonamento Evolutivo vs. Custo
O custo de diferentes categorias de empregados define estes números. Por exemplo, gestão, requisitos e design tendem a usar pessoal mais experiente (mais caros!)

15 Escalonamento Evolutivo: Distribuição Esforço e Tempo por Fase

16 Estimando Custo e Cronograma
Considere duas perspectivas: Top-down (entendimento geral de requisitos e limitações) - orçamento e cronograma macros Bottom-up (micro análise do orçamento e cronogramas) Sequência do planejamento top-down: Caracterização inicial (tamanho, processo, ambiente, pessoas, qualidade requerida) Esforço e cronograma macros (modelo estimativas) Partição do esforço estimado (tabelas anteriores) Decomposição de cada elemento em níveis menores (orçamentos e milestones mais específicos)

17 Estimando Custo e Cronograma
Sequência do planejamento bottom-up: Os níveis menores são organizados em tarefas mais detalhadas, para as quais orçamentos e cronogramas são estimados As estimativas são combinadas e integradas aos níveis maiores - mediante alguma base de negociação Comparações são feitas com os orçamentos e cronogramas da fase anterior (top-down) - ajustes são realizados entre as duas estimativas

18 Planejamento Iterativo
Planejar o conteúdo e cronograma dos milestones críticos e iterações intermediárias é o caminho mais indicado para se gerenciar riscos Um plano evolutivo é melhor porque sempre haverão ajustes a serem feitos até que as circunstâncias do projeto estejam bem compreendidas Iterações são, então, usadas para sincronização de mudanças que ocorrem em todo o projeto

19 Planejamento Iterativo
Planejamento bottom-up de tarefas baseado nas métricas das iterações anteriores Planejamento top-down de tarefas baseado na macro análise de projetos anteriores 100% Ênfase do Planejamento Engenharia Produção

20 Planejamento Iterativo: Ciclo Incremental
A estratégia incremental define as demandas do usuário, os requisitos do sistema e procede com a construção: Uma iteração rápida no planejamento: para definir escopo e visão (business case) Uma iteração na elaboração: definição de requisitos e estabelecimento da arquitetura Várias iterações na construção: implementação dos use cases com base na arquitetura Várias iterações de transição: migrando o produto para os seus usuários Funciona bem para: Domínio conhecido Riscos conhecidos Equipe experiente

21 Planejamento Iterativo: Ciclo Evolucionário
A estratégia evolucionária difere da incremental ao admitir que as demandas do usuário não estão completamente definidas: Uma iteração rápida no planejamento: para definir escopo e visão (business case) Várias iterações na elaboração: onde os requisitos são refinados a cada iteração Uma iteração na construção: implementação dos use cases com base na arquitetura Várias iterações de transição: migrando o produto para os seus usuários Funciona bem para: Domínio desconhecido Equipe inexperiente

22 Planejamento Iterativo: Ciclo Entrega Incremental
A estratégia da entrega incremental é apropriada quando as pressões do time-to-market são fortes: Uma iteração rápida no planejamento: para definir escopo e visão (business case) Uma iteração na elaboração: definição de requisitos e estabelecimento da arquitetura Uma iteração na construção: implementação dos use cases com base na arquitetura Várias iterações de transição: migrando o produto para os seus usuários Funciona bem para: Domínio conhecido (estabilidade, baixa inovação) Equipe experiente Versões são importantes p/cliente

23 Planejamento Iterativo: Ciclo “Grande Projeto”
Uma degeneração do cascata (na prática, é difícil evitar iterações adicionais na fase de transição): Uma iteração rápida no planejamento: para definir escopo e visão (business case) Uma iteração (lonha) na construção: implementação dos use cases com base na arquitetura Várias iterações de transição: migrando o produto para os seus usuários Funciona bem para: Pequenos ajustes em funcionalidades de produtos existentes Funcionalidades bem entendidas Equipe experiente

24 Planejamento Iterativo: Ciclo Híbrido
Na prática, poucos projetos seguem completamente uma dada estratégia Busca-se alguma forma híbrida - uma vantagem do planejamento iterativo: Para problemas complexos e desconhecidos: aumenta-se o número de iterações na fase de elaboração Para problemas de desenvolvimento complexo: aumenta-se o número de iterações na fase de construção Para entregar versões do produto numa série incremental: aumenta-se o número de iterações na transição