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

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

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 ...

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

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

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

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

[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

[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

[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

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

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

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

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!)

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

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)

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

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

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

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

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

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

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

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