Gestão de Projecto. Sumário

Transcrição

1 (QJHQKDULDGH6RIWZDUH Gestão de Projecto Carla Ferreira Sumário Caracterização Objectivos Problemas Qualidades Factores Não-Técnicos Técnicas Casos Notáveis Exemplo Conclusões Gestão de Projecto 2 1

2 Objectivos A gestão de projecto é responsável por assegurar que o desenvolvimento de software está de acordo com os objectivos, políticas e requisitos da organização A gestão de projecto deve Planear o projecto Estimar o esforço Monitorar o projecto Gerir os riscos Gestão de Projecto 3 Problemas O desenvolvimento de software apresenta, com bastante frequência, os seguintes problemas: Os produtos são entregues com atraso relativamente aos prazos estabelecidos O desenvolvimento tem custos finais muito superiores às estimativas iniciais Os produtos entregues não satisfazem os requisitos dos utilizadores Gestão de Projecto 4 2

3 Problema Estes problemas, que também acontecem nas outras engenharias, são ainda mais difíceis de gerir devido aos aspectos distintivos do software: O produto é intangível Não existe um processo industrial normalizado Não existe experiência suficiente que permita reduzir a incerteza novos problemas, novas tecnologias,... Gestão de Projecto 5 Qualidades A boa gestão de projecto deve planear e monitorar o projecto de modo a garantir que este é levado a cabo de acordo com determinados níveis de qualidade, respeitando os prazos e o orçamento Este tópico pode ser entendido como a avaliação e validação do processo de desenvolvimento Gestão de Projecto 6 3

4 Factores Não-Técnicos Gestão de Equipas de Desenvolvimento Estilos de trabalho Papéis da equipa Características da equipa Estrutura organizacional da equipa Reuniões Gestão de Projecto 7 Estilos de Trabalho Os elementos da equipa têm diferentes estilos de trabalho. É da responsabilidade de todos os elementos tirarem partido das características próprias de cada elemento para aumentar a produtividade: Extrovertidos comunicam as suas ideias de imediato Introvertidos fazem perguntas antes de tomar uma decisão Intuitivos baseiam as suas decisões nas emoções Racionais baseiam-se mais nos factos Gestão de Projecto 8 4

5 Estilos de Trabalho INTUITIVO INTROVERTIDO INTUITIVO INTUITIVO INTROVERTIDO: EXTROVERTIDO: Faz perguntas Expressa opiniões Reconhece sentimentosreconhece sentimentos RACIONAL INTROVERTIDO: Faz perguntas Decide logicamente RACIONAL EXTROVERTIDO: Expressa opiniões Decide logicamente EXTROVERTIDO RACIONAL Gestão de Projecto 9 Papéis da Equipa Existem diferentes papéis na equipa que podem ser desempenhados pela mesma ou por diferentes pessoas. Estes papéis estão ligados às actividades: Análise de requisitos Desenho de sistema Desenho de programa Implementação Testes Treino Manutenção Verificação de qualidade Gestão de Projecto 10 5

6 Características da Equipa Motivação no trabalho Experiência no domínio das aplicações semelhantes Experiência com tecnologia, ferramentas e linguagens semelhantes Capacidade de partilhar responsabilidades Capacidade de gestão Capacidade de comunicação (ver figura) Gestão de Projecto 11 Comunicação na Equipa Adicionar recursos humanos a um projecto atrasado ainda o atrasa mais Brooks s Law Gestão de Projecto 12 6

7 Organização do Projecto A escolha de uma estrutura de trabalho depende de diversos factores: A experiência e o estilo de trabalho dos membros da equipa O número de pessoas na equipa O tipo do modelo do processo de desenvolvimento Gestão de Projecto 13 Equipa Hierárquica Secretário Programador Gestor/Programador Chefe Programador Programador Programador Gestão de Projecto 14 7

8 Equipa Plana Não existe UM líder do grupo, existem líderes Existe uma identidade de equipa Existe respeito mútuo entre os elementos da equipa O código é partilhado em vez de pertencer a um programador Gestão de Projecto 15 Diferentes Estruturas Hierárquica reduz comunicação Muito estáveis Repetitivos Grande dimensão Plana é mais democrática e aumenta a comunicação Aumenta a qualidade do produto e produtividade Alto grau de indefinição Problemas difíceis - novas técnicas e tecnologias Projectos pequenos Variações são possíveis sempre que adequadas, mesmo durante o ciclo de vida do projecto Gestão de Projecto 16 8

9 Outras Estruturas Separar a gestão de projecto da liderança técnica pois é difícil encontrar alguém que possui ambas as características Subdividir a equipa em diversas equipas planas que respondem a um líder técnico o qual responde ao líder de projecto A anterior com participação simultânea do mesmo elemento em diversas equipas Gestão de Projecto 17 Reuniões As reuniões podem levar muito tempo sem obter os resultados desejados, assim deve-se assegurar que: o objectivo seja claro os participantes estejam preparados os participantes não faltem ou cheguem atrasados a discussão não se afaste do objectivo se evitem os argumentos, a não participação, ou o domínio da discussão as decisões sejam aplicadas após a reunião Gestão de Projecto 18 9

10 Técnicas Planificação do projecto Monitorização do projecto Gestão de Riscos Estimação do Esforço Gestão de Configurações Gestão de Projecto 19 Plano do Projecto Para comunicar com os clientes deve-se fazer um plano do projecto que identifica as necessidades do cliente e indica como se espera que sejam satisfeitas. Plano do projecto deve conter os seguintes itens: 1. Âmbito do projecto identifica a fronteira 2. Calendarização do projecto inclui uma estrutura de divisão do trabalho, deliverables, etc 3. Organização da equipa a lista das pessoas da equipa e indicação de qual vai ser o seu envolvimento Gestão de Projecto 20 10

11 Plano do Projecto 4. Descrição técnica dos sistemas propostos hardware e software 5. Standards, técnicas e ferramentas a usar 6. Plano de qualidade indica como os testes, inspecções e verificações vão ajudar a avaliar a qualidade 7. Plano de gestão de configurações indica como preservar a rastreabilidade 8. Plano de documentação indica quais os documentos e quem é responsável por os gerar 9. Plano de gestão de dados indica como os dados são recolhidos, guardados e manipulados 10. Plano de gestão de recursos indica como os recursos vão ser usados Gestão de Projecto 21 Plano do Projecto 11. Plano de testes indica como se gera os dados para os testes, como se testa cada módulo, como se testa a integração de módulos Plano de treino indica como se pretende treinar os utilizadores 13. Plano de segurança indica como os dados são protegidos Plano de gestão do risco registar as decisões sobre a redução do risco 15. Plano de manutenção indica quem tem as responsabilidades de alterar o código, alterar a documentação... Gestão de Projecto 22 11

12 Calendarização e Deliverables A calendarização do projecto descreve: o ciclo de desenvolvimento de um particular projecto enumerando as etapas do projecto e dividindo-as em actividades as dependências entre as actividades a estimativa de duração de cada actividade É necessário definir os deliverables a entregar aos clientes durante o processo: documentos demonstrações Os deliverables estão por vezes associados a marcos do desenvolvimento Gestão de Projecto 23 Divisão do Trabalho Uma estrutura de divisão do trabalho permite representar o projecto como um conjunto de actividades discretas estando relacionadas através de: percursor, que estabelece as condições necessárias ao início da tarefa duração, tempo necessário à execução da tarefa data término, em que a actividade deve estar terminada Um grafo de actividades mostra as dependências. Gestão de Projecto 24 12

13 Monitorização do Projecto Monitorar o projecto é uma actividade contínua que segue a execução do projecto comparando o progresso planeado com o progresso de facto Gestão de Projecto 25 Estimar o Término Para estimar o término anota-se o grafo de actividades com as durações das actividades Para descobrir o tempo mínimo para o término do projecto e quais as actividades mais críticas utiliza-se o método do caminho crítico. Este método considera para cada actividade: tempo real estimado tempo disponível tempo livre = tempo disponível - tempo real estimado tempo livre = tempo de início tarde tempo de início cedo O caminho crítico é aquele em que o tempo livre em todos os nós é zero Gestão de Projecto 26 13

14 : ; Método do Caminho Crítico Variações no caminho crítico são as que maiores consequências têm no projecto Ciclos no grafo, repetição de actividades devido a situações de insucesso, alteram qual é o caminho crítico pelo que as suas implicações são mais difíceis de avaliar Gráficos de barras são usados para ilustrar a aplicação do método do caminho crítico e visualizar a afectação dos recursos pelas actividades Gestão de Projecto 27 Gantt ' ' & ' ID Task Name Duration Start Finish 1!" #$% & & #$( '& 10 )* +, (.!" #$% & ' & ' / ' & ' & ' 11 0, (!" #$% & ' & ' 6, & ' & ' 12 Aprender Microsoft Project 1 hr Wed Wed Iniciação ao Java 3 hrs Wed Fri Ver "Levantamento de requisitos" 4 hrs Wed Sat Procurar "use cases" na Net 8 hrs Wed Fri Levantamento dos ambientes de desenvolvim 5 hrs Wed Wed , ! (!" #$ 8& ' & ' 6 9 & ' & ' 18 Fazer Modelo do Domínio 0,88 day Wed Sat ª Iteração do Volere 0,56 day Wed Thu ( 0, ! !" #$' (& '& ' / ' & ' & ' 21 Modelo do Domínio e Modelo de Análise 0,63 day Wed Fri Continuação do Volere 0,63 day Wed Thu , ! !" #$% '& '& ' 6, ( & ' & ' 24 Modelo do Domínio e Modelo de Análise 0,63 day Wed Fri Modelação de alguns casos de utilização 0,25 day Wed Wed Continuação do Volere 0,75 day Wed Fri Fazer Protótipo com Tecnologias Java 1,25 day Wed Sat , ! ! " #$% & '& ' 6 ' & ' & ' 29 Continuação do Volere 0,5 day Wed Thu Diagramas de Colaboração e Modelo de Aná 4 days Wed Sat Finalização do Protótipo com Tecnologias Ja 1,88 day Wed Sat Apr '00 F S S M T W Gestão de Projecto 28 14

15 ID Gantt 0 Apr Apr Apr May May May May May T W T F S S M T W T F S S M T W T F S S M T W T F S S M T W T F S S M T W T F S S M T W T F S S M T W <= B >? C= A D B =E?F GHEI JF K= L?F M = N OF DI PQ?F RI Q B S A T!F <= >? UQ =L? M = N OF C=A F K=L?F RI Q B S A T D I PQ?F GHEI >?F D B= E?F UQ =L?F <,= >? M = N OF K=L?F C,= A F RI Q B S A T D I PQ?F GHEI >?F D B= E?F <= >?F U,Q = L? M = N OF C=A F K=L?F RI Q B S A T M = N OF C=A F K=L?F RI Q B S A T D B =E?F U,Q = L?F <= >? D I PQ?F GHEI >? UQ =L?F <,= >?F D B= E? RI Q B S A T!F UQ =L?F <,= >?F D B= E?F K D I >?F G EI J <= >?F U,Q = L?F Gestão de Projecto 29 Gestão do Risco Um risco é um acontecimento não desejado que tem consequências negativas. Os riscos distinguem-se por três aspectos: Impacto do risco perda associada ao acontecimento, tempo, qualidade, dinheiro, controle. Por exemplo uma alteração profunda de requisitos leva a uma perda de tempo e dinheiro se o desenho não for suficientemente flexível. Probabilidade do risco a frequência do acontecimento, pelo que a probabilidade de ocorrência do acontecimento deve ser estimada. Controlo do risco capacidade de controlar a ocorrência do acontecimento, o que pode ser feito para minimizar ou evitar o impacto do acontecimento. Gestão de Projecto 30 15

16 V V V Actividades de Gestão do Risco A gestão do risco envolve vários passos: 1. Avaliar o risco 1. Identificar o risco 2. Analisar o risco 3. Atribuir prioridades ao risco 2. Controlar o risco 1. Reduzir o risco 2. Plano de gestão do risco 3. Resolução do risco Gestão de Projecto 31 Actividades de Gestão do Risco Identificar o Risco Se o sistema for idêntico a um sistema desenvolvido anteriormente e se existir uma lista de verificação pode-se usar essa lista para verificar se o novo projecto apresenta alguns dos riscos enumerados Ver os riscos associados a cada uma das actividades do processo de desenvolvimento Analisar os pressupostos e decisões sobre como o projecto vai ser executado, quem o vai executar e com que recursos Gestão de Projecto 32 16

17 W W W V V X X X X X X Actividades de Gestão do Risco Analisar o Risco Saber quando, como e onde podem ocorrer os riscos Atribuir Prioridades ao Risco Toma-se em consideração a probabilidade de o risco acontecer e o impacto da sua ocorrência Gestão de Projecto 33 Actividades de Gestão do Risco Redução do Risco Evitar o risco, alterando os requisitos Transferir o risco, atribuindo o risco a outros sistemas ou fazendo um seguro Assumir o risco e controlar o risco com os recursos do projecto por exemplo protótipos Verificar se o custo associado à redução do risco compensa, (risco antes redução risco após redução) / custo da redução Plano de Gestão do Risco Registar as decisões sobre a redução do risco Resolução do Risco Monitorizar o projecto de acordo com o plano Gestão de Projecto 34 17

18 Y Y Y Y W W Z X X Medida e Estimação Uma medida é uma aplicação que tem como domínio de um conjunto de entidades e atributos do mundo real e codomínio uma representação ou modelo do mundo matemático Existem dois tipos de sistemas: 6LVWHPDVGHPHGLGD são usados para avaliar uma entidade caracterizando numericamente um dos seus atributos 6LVWHPDVGHHVWLPDomR são usados para predizer acerca de um atributo de uma entidade no futuro Uma medida é válida se caracteriza com exactidão o atributo que mede Um sistema de estimação é válido se prediz com exactidão Gestão de Projecto 35 Validar os Sistemas MeE Para validar um sistema de medida e estimação compara-se os resultados com dados conhecidos do ambiente Para validar um sistema de medida é necessário demonstrar que a relação entre a medida e a qualidade se mantém se P1 tem mais qualidade que P2 então m(p1) > m(p2) m(p1,p2) = m(p1) + m(p2) A validação assegura que as medidas foram bem definidas e são coerentes com o comportamento real Gestão de Projecto 36 18

19 V V V V V V Estimação É necessário estimar para responder às seguintes perguntas: Que quantidade de HVIRUoR é necessária para terminar uma actividade? Quanto WHPSR é necessário para terminar uma actividade? Qual é o FXVWR total de uma actividade? Gestão de Projecto 37 Estimação do Esforço Que esforço, pessoas/mês, é necessário para terminar o projecto? Experiência dos peritos Métodos algorítmicos Métodos automáticos A estimação deve ser feita o mais cedo possível e repetidamente durante todo o projecto Quanto mais se avança no projecto mais correctas são as estimativas e menos necessárias Gestão de Projecto 38 19

20 W W W W W W Precisão das Estimativas 4x INTERVALO DE VARIAÇÃO x 0.25x Viabilidade Levantamento Desenho Requisitos Arquitectura Desenho Detalhado Desenvolvimento Entrega Teste Gestão de Projecto 39 Causas da Imprecisão Pedidos de alteração frequente por parte dos utilizadores Tarefas ignoradas Utilizadores não sabem bem quais são os requisitos Análise insuficiente quando se desenvolve uma estimativa Falta de coordenação entre os diversos elementos da equipa Falta de um método adequado para fazer a estimação Gestão de Projecto 40 20

21 [ Influenciam a Estimação Factores que influenciam a estimação \ Complexidade do sistema \ Integração com sistemas existentes \ Tamanho do sistema em termos de funções \ Aptidão dos membros do projecto \ Experiência dos membros do projecto com o domínio da aplicação, as linguagens de programação, o hardware \ Antecipação e frequência das alterações aos requisitos de utilizador \ Dimensão da equipa \ Extensão das regras de programação e documentação \ Disponibilidade de ferramentas como os geradores de aplicações Gestão de Projecto 41 Duas Abordagens Top-Down a estimação é feita a partir do nível do sistema e tendo em consideração a funcionalidade total ] Não considera os detalhes Bottom-Up a estimação é feita, após uma decomposição do sistema em componentes, adicionando a estimação relativa ao desenvolvimento de cada componente ] Subestima custos de integração Gestão de Projecto 42 21

22 ^ ^ ^ ^ ^ ^ Experiência dos Peritos Baseada na experiência Baseada na semelhança Pode acontecer que não sejam evidentes a diferenças entre dois projectos e mesmo que as diferenças sejam identificadas é difícil avaliar do seu impacto no custo, e.g., a diferença de produtividade entre dois programadores pode ser de 10X Pode-se normalizar as estimativas individuais de vários peritos, pessimista, optimista e média Gestão de Projecto 43 Métodos Algorítmicos Existem modelos que expressam a relação entre o esforço e os factores que o influenciam Estes modelos são representados por equações em que o esforço é a variável dependente de um conjunto de variáveis independentes que representam os factores que influenciam o esforço E = (a + bs c )m(x) a, b e c são constantes, S é a dimensão estimada do sistema, X é um vector de factores de custo e m um multiplicador de ajuste. Estes valores são calculados usando dados empíricos de projectos passados Gestão de Projecto 44 22

23 COnstructive COst MOdel Dá ênfase à estimação da dimensão e considera diferentes estimações para três etapas do projecto: 1. Pontos de objecto são estimados no início do projecto quando não se tem uma noção da dimensão do produto final 2. Pontos de função são estimados em função do resultado do levantamento de requisitos 3. Linhas de código são estimadas quando já foi desenhada a arquitectura do sistema Gestão de Projecto 45 Pontos de Objecto Durante a fase inicial constróem-se protótipos para avaliar e resolver o risco associado a interfaces utilizador, interacção de sistemas, maturidade tecnológica... Contabiliza indicadores de alto nível: ] Ecrãs ] Relatórios ] Componentes 3GL Gestão de Projecto 46 23

24 Pontos de Função Durante a segunda fase foi decidido avançar com o projecto e está-se a explorar diferentes arquitecturas da solução Contabiliza a dimensão em função dos requisitos: ] Entradas ] Saídas ] Interrogações ] Ficheiros ] Interfaces Gestão de Projecto 47 Linhas de Código Durante a terceira fase a arquitectura do sistema já está definida e sabe-se quais os seus principais módulos Contabiliza a dimensão de cada módulo em termos da estimativa do número de linhas de código Gestão de Projecto 48 24

25 ^ ^ COCOMO 2.0 E = bs c m(x) S (Size) representa o tamanho estimado que pode ser calculado em ponto de objectos, pontos de função ou linhas de código S é ajustado por b, c e X. Os factores de ajuste são apresentados a seguir Gestão de Projecto 49 Factores de Ajuste Factores de escala Experiência no domínio da aplicação Conhecimento da arquitectura Resolução do risco Coesão da equipa Maturidade do processo... Factores do produto (factores de custo) Fiabilidade do sistema Complexidade Reutilização Documentação... Gestão de Projecto 50 25

26 ^ ^ ^ Factores de Ajuste Factores da plataforma (factores de custo) Estabilidade do software e hardware usados no desenvolvimento... Factores da equipa (factores de custo) Aptidão dos membros Continuidade da equipa... Factores do projecto (factores de custo) Utilização de ferramentas Desenvolvimento distribuído... Gestão de Projecto 51 Calibração do Modelo Os modelos devem ser calibrados para reflectir circunstâncias específicas de modo a ] reduzir a complexidade e a diversidade do modelo ] reduzir a avaliação subjectiva inerente aos factores de ajuste Gestão de Projecto 52 26

27 a a Duração do Projecto A duração do projecto pode ser estimada a partir da dimensão A duração pode também ser calculada a partir do esforço mas o número de engenheiros da equipa não tem uma influência determinante ] Equipas maiores têm uma produtividade menor por elemento Os projectos podem ser mal sucedidos se não planearem uma duração suficiente Gestão de Projecto 53 Exemplo - COCOMO 2.0 E = 2.94 * EAF * (KSLOC) EE EAF factor de ajustamento de esforço depende dos factores de custo EE expoente de escala depende dos factores de escala KSLOC Source Lines of Code E = 2.94 * (1.0) * (8) = 28.9 pessoa/mês Gestão de Projecto 54 27

28 ^ a Exemplo - COCOMO 2.0 Complexidade elevada (1.34) e experiência na utilização de ferramentas e linguagens (1.09) EAF = 1.34 * 1.09 = 1.46 E = 2.94 * (1.46) * (8) = 42.3 pessoa/mês Gestão de Projecto 55 Exemplo - COCOMO 2.0 Duração = 3.67 * (E) SE E esforço SE expoente de planeamento depende dos factores de escala D = 3.67 * (42.3) = 12.1 meses Nº de pessoas = (42.3 pessoa/mês) / (12.1 meses) = 3.5 pessoas Gestão de Projecto 56 28

29 Versões de Software Os produtos de software podem ter diversas versões devido ao desenvolvimento incremental e iterativo ou porque se deseja ter variações de funcionalidade e de não funcionalidade As versões de software devem ser mantidas por diferentes razões A nova versão tem erros Existem utilizadores que continuam a usar versões antigas Gestão de Projecto 57 Gestão de Configurações Tem dois objectivos distintos Suporte à gestão Suporte ao desenvolvimento Gestão de Projecto 58 29

30 Gestão de Configurações Trata os seguintes aspectos Identificação de configurações com que pedaço de software se está a trabalhar Controlo de configurações controlo da versão de um produto e das alterações a ele feitas Auditoria de componentes registo e relatório do estado dos componentes de um produto Revisão de produto validação da completude de um produto e sua manutenção consistente com os restantes componentes Gestão de Projecto 59 Gestão de Configurações Gestão de integrações gestão dos processos e ferramentas que a equipa usa para criar uma versão do produto Gestão de processo assegurar que o processo de desenvolvimento é seguido pela equipa Trabalho de grupo controlo das interacções entre as pessoas que estão a desenvolver o software Gestão de Projecto 60 30

31 Espaço de Trabalho Espaço de Trabalho é o espaço onde o programador tem todos os artefactos que necessita para fazer o seu trabalho Código fonte do produto Código fonte de testes Bibliotecas Scripts de compilação... Gestão de Projecto 61 Sequência de Código Sequência de Código é a progressão, ao longo do tempo, de um conjunto de ficheiros fonte e outros artefactos que formam um componente Versão de Artefacto cada revisão de um ficheiro fonte ou de um artefacto ao longo de uma sequência de código Gestão de Projecto 62 31

32 Configuração Configuração é uma fotografia da sequência de código que contem uma versão de cada componente da sequência de código Versão de Sequência de Código é uma configuração a que é dado um nome distinto através de uma etiqueta Gestão de Projecto 63 Ramo Ramo é uma sequência de código que se separa da sequência principal com um objectivo particular Divisão de trabalho Nova release do produto... Merge é o processo em que um ramo é reincorporado na sequência de código principal Gestão de Projecto 64 32

33 Diagrama Gestão de Projecto 65 Estabilidade vs Progresso A rapidez de desenvolvimento é essencial e qualidade e gestão de versões fica para depois Qualidade é essencial e seguem-se os procedimentos, uma release de cada vez, reduzindo a produtividade e possivelmente deixando os programadores frustrados Gestão de Projecto 66 33

34 b b b Princípios Utilizar controlo de versões Fazer integrações periódicas permite ter uma ideia do estado actual Permitir trabalho autónomo cada programador pode necessitar de trabalhar em pontos diferentes da sequência de código Utilizar ferramentas Gestão de Projecto 67 Arquitectura A arquitectura influência o controlo de versões pois define O que é o produto As relações entre entre os componentes A estrutura de directórios do código fonte e vice-versa... Gestão de Projecto 68 34

35 b b b Organização A organização influência o controlo de versões pois estabelece Distância física entre os membros da equipa Cultura e e dinâmica da equipa Estrutura organizacional da equipa e vice-versa... Gestão de Projecto 69 35