C:\Documents And Settings\Juliana\Desktop\Palestra 19 03 2010

814 visualizações

Publicada em

Palestra oferecida na Faculdade Anhanguera de Anápolis no dia 19/03/2010.

Publicada em: Tecnologia
0 comentários
3 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
814
No SlideShare
0
A partir de incorporações
0
Número de incorporações
45
Ações
Compartilhamentos
0
Downloads
40
Comentários
0
Gostaram
3
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

C:\Documents And Settings\Juliana\Desktop\Palestra 19 03 2010

  1. 1. Processo de desenvolvimento de software X Processo de gerenciamento de projeto: uma visão prática Professor: Leandro Rosa de Assi s
  2. 2. Por que gerenciar Projetos na área de TI ? <ul><li>Em 1994 o Standish Group analisou 3682 projetos e percebeu que 83,2% foram cancelados ou entregues excedendo o prazo ou o custo </li></ul><ul><ul><li>Em 2002, Jim Jonhson apontou que 64% das funcionalidades implementadas são raramente ou nunca utilizadas </li></ul></ul>
  3. 3. Por que gerenciar Projetos na área de TI ? <ul><ul><li>Em 2006 o PMI* Brasil divulgou um relatório onde no qual o não-cumprimento do prazos foi um dos principais problemas no gerenciamento de projetos em 87% dos projetos analisados </li></ul></ul><ul><li>* PMI (Project Management Institute): organização mundial de grande prestígio na área de gerenciamento de projeto desde 1969 Pensilvânia (E.U.A), com vários chapter no mundo inclusive em Goiás. </li></ul>
  4. 4. Por que gerenciar Projetos na área de TI ? <ul><li>Conclusão: </li></ul><ul><ul><li>Baixa exatidão entre o planejado e realizado </li></ul></ul><ul><ul><li>Imaturidade da indústria de software em realizar previsões e estimativas </li></ul></ul><ul><ul><li>Baixo senso de prioridade </li></ul></ul><ul><ul><li>Gastos além do previsto </li></ul></ul><ul><ul><li>Pouco alinhamento com os interesses do negócio </li></ul></ul><ul><ul><li>Resumindo: estratégias de planejamento incompatíveis com a realidade de projetos </li></ul></ul>
  5. 5. Por que gerenciar Projetos na área de TI?
  6. 6. Gestão de Projetos <ul><li>Métodos e ferramentas que organizam as tarefas, identificando seqüenciamento de execução e dependências existentes </li></ul><ul><li>Apóia a alocação de recursos e tempo </li></ul><ul><li>Rastreamento da execução das atividades </li></ul><ul><li>Medição do progresso relativo ao que foi definido no plano de projeto </li></ul>
  7. 7. Gestão de Projetos: Plano de Projeto <ul><li>O plano de projeto é um guia essencial à condução do projeto sem o qual o gerente fica perdido </li></ul><ul><li>O plano constitui uma base para execução sistemática do projeto além de servir como mecanismo eficiente de comunicação entre membros da equipe e entre empresa desenvolvedora de produto de software e (empresa) cliente. </li></ul><ul><li>Segundo o PMI (Project Management Institute) em sua “bíblia”, o PMBOK 4 ª edição , gerencia-se projetos em nove áreas. A ver: </li></ul>
  8. 8. Gestão de Projetos: PMBOK 4ª edição
  9. 9. Gestão de Projetos: ciclo de vida de um projeto <ul><li>Iniciar </li></ul><ul><li>Forte participação do Gerente de Projeto e Solicitante de Projeto que por natureza gerencia o a Gestão de Demandas em um processo de desenvolvimento de software </li></ul><ul><li>Planejar </li></ul><ul><li>Atuação do Gerente de Projeto para organizar o planejamento da fase execução à luz do modelo de disciplinas e iterações do RUP </li></ul><ul><li>Executar </li></ul><ul><li>Execução de atividades inerentes aos papéis definidos no processo de desenvolvimento software </li></ul><ul><li>Encerrar </li></ul><ul><li>Formalidades documentas e transferência de conhecimentos/resultados </li></ul>
  10. 10. Modelo tradicional: RUP
  11. 11. Representação do modelo tradicional RUP em um cronograma
  12. 12. Fase “Iniciar” <ul><li>Desenvolvimento (Solicitante do Projeto) e validação (Gerente de Projeto) do “Termo de Abertura” de um projeto </li></ul><ul><li>Processo de desenvolvimento de software: a modelagem de negócio deverá compor o escopo da necessidade, parte integrante do “Termo de abertura” </li></ul>
  13. 13. Atenção especial: Gestão de Demandas <ul><li>Recebimento e liberação de demandas </li></ul><ul><ul><li> Recebimento de ordem de serviço </li></ul></ul><ul><ul><li> Análise de ordem de serviço </li></ul></ul><ul><li>Planejamento e aceitação </li></ul><ul><ul><li> Definição do escopo de atendimento da ordem de serviço </li></ul></ul><ul><ul><li> Elaboração do plano de atendimento da ordem de serviço </li></ul></ul>
  14. 14. Fase “Iniciar” <ul><ul><li>Processo de desenvolvimento de software: face às demandas determinadas no “Termo de Abertura” desenvolver o escopo da solução utilizando técnicas de estimativas e de análise de impacto no produto de software a ser alterado </li></ul></ul>
  15. 15. Fase “Iniciar” Desenvolvimento do Escopo da solução para composição do Plano de Projeto Execução: Processo de desenvolvimento de software Base histórica <ul><li>Disciplinas: </li></ul><ul><li>Modelagem de Negócio (parte integrante do “Termo de Abertura”) </li></ul><ul><li>Análise de Requisito </li></ul><ul><li>Projeto </li></ul><ul><li>Codificação </li></ul><ul><li>Teste </li></ul><ul><li>Gerência de Configuração </li></ul>
  16. 16. Fase “Iniciar” <ul><li>Utilizando a técnica PERT (Program Evaluation and Review Technique)para estimar tarefas e formação da Base Histórica: </li></ul>
  17. 17. Fase “Iniciar” <ul><ul><li>Identificar a capacidade de esforço da equipe pesquisando alocação do recurso (via ferramental: MS PROJECT, PROJECT WEB ACCESS e outros) </li></ul></ul><ul><ul><li>Aceitar o “Termo de Abertura” caso a capacidade de esforço seja suficiente para atender a demanda </li></ul></ul><ul><li>Criação do “Plano de Gerenciamento” </li></ul><ul><li>Registrar aceites do “Plano de Gerenciamento” </li></ul>
  18. 18. Detalhando um Plano de Gerenciamento ou Plano de Projeto
  19. 19. Fase “Iniciar” Calcular capacidade de esforço Desenvolver escopo da solução Aceitar “Termo de abertura” Criar “Plano de Gerenciamento” Registros de aceites do “Plano de Gerenciamento Aceites dos envolvidos previsto em uma “Matriz de Responsabilidades” Processo de desenvolvimento de SW
  20. 20. Fase “Planejar” <ul><li>Aplicar no cronograma o planejamento de marcos e alocação de recursos da fase de execução </li></ul><ul><li>Salvar linha de base da fase de execução </li></ul><ul><li>Apresentar o planejamento da fase de execução aos recursos do projeto </li></ul>
  21. 21. Planejamento da execução do projeto e a respectiva alocação dos recursos
  22. 22. Fase “Execução” <ul><li>Processo de desenvolvimento de software : execução das disciplinas previstas no processo e/ou complexidade da demanda face ao que foi determinado no escopo da solução </li></ul>Desenvolver: Requisito Desenvolver: Projeto Desenvolver: Código fonte Aplicar: Teste Aplicar: Gerência de Configuração <ul><li>Plano de Gerenciamento : </li></ul><ul><li>Escopo da solução (estimativa e impacto por disciplina) </li></ul><ul><li>Marcos de entrega por escopo da solução </li></ul><ul><li>Plano de contingência e atenuante de riscos </li></ul><ul><li>Outros </li></ul>
  23. 23. Fase “Execução” : Gerência de Configuração <ul><li>A gestão de configuração deve controlar as versões dos itens de software de cada ordem de serviço e componentes reutilizáveis </li></ul><ul><li>Itens de software são programas de computador, ordens de serviço, documentos específicos lógica e física de projetos, procedimentos documentados, planos de projeto, etc. </li></ul>
  24. 24. Fase “Execução” : Gerência de Configuração
  25. 25. Fase “Execução” : atuação do responsável pela Gerência de Configuração (apoiada pelo Gerente de Projeto)
  26. 26. Fase “Execução” : iterações do modelo RUP ao auxílio da Gestão de Projetos X Gerência de Configuração e demais disciplinas
  27. 27. Fase “Execução” <ul><li>O Gerente de Projeto deverá monitorar e controlar: </li></ul><ul><ul><li>As mudanças ocasionadas em função de: </li></ul></ul><ul><ul><li>* Estouro de estimativas no consumo do esforço </li></ul></ul><ul><ul><li>*Alteração do escopo das necessidades </li></ul></ul><ul><ul><li>* Impactos gerados por outros projetos </li></ul></ul><ul><ul><li>Técnicas: reuniões de acompanhamento, relatórios de conclusão de tarefas e apropriação de horas </li></ul></ul>
  28. 28. Fase “Executar” <ul><ul><li>Estouro de Custo (esforço em horas X valor hora ) </li></ul></ul><ul><ul><li>Riscos via plano de ação (contingência e atenuante) </li></ul></ul><ul><ul><li>Recursos humanos no tocante a produtividade e/ou retrabalho (o Gerente de Projeto deve ter atenção especial nas apropriações de horas em retrabalho) </li></ul></ul>
  29. 29. Fase “Executar” <ul><ul><li>Ações/tarefas de dependência com o cliente externo que podem impactar marcos de entrega (Ex.: instalação do servidor de banco de dados, validação de requisitos via prototipação de interface) </li></ul></ul><ul><ul><li>Apropriação de horas dos recursos para garantir a formação da Base Histórica </li></ul></ul>
  30. 30. Fase “Executar” Alteração do escopo de necessidades (Termo de Abertura desenvolvido pelo Solicitante do Projeto) Desenvolvimento de novo Escopo da Solução Desenvolvimento de novos marcos de entrega Registro de mudança (solicitante) Demais alterações no Plano de Projeto Análise Mudança aceita Mudança não aceita
  31. 31. Fase “Encerrar” <ul><li>Via ferramental concluir todas as atividades do projeto </li></ul><ul><li>Notificar aos envolvidos (determinados pela matriz de responsabilidades), o encerramento do projeto </li></ul><ul><li>Realizar a transição de resultados do projeto </li></ul>
  32. 32. Fase “Encerrar” Lições aprendidas Registro de problemas Casos de sucesso: na execução das disciplinas do processo de desenvolvimento de software Gestão do conhecimento Capital Intelectual
  33. 33. Fase “Encerrar” <ul><li>Responsabilidades do Escritório de Projetos(PMO): </li></ul><ul><ul><li>auditoria em conteúdo dos projetos(artefatos e cronograma) </li></ul></ul><ul><ul><li>evidência de necessidade de alterações no processo de gerenciamento de projeto e/ou interfaces com processos técnicos (processo de desenvolvimento de software é um exemplo) </li></ul></ul>
  34. 34. <ul><li>“ Realizar revisões de todo o trabalho com os colegas de forma que mais de uma pessoa esteja a par das atividade desenvolvidas” </li></ul><ul><li>Do livro Engenharia de Software, Roger S. Pressman </li></ul>
  35. 35. <ul><li>Obrigado!! </li></ul><ul><li>Contatos: </li></ul><ul><ul><li>Celular: 62 96725291 </li></ul></ul><ul><ul><li>E-mail: leandro@tsheet.com.br </li></ul></ul>

×