Processo de desenvolvimento de software X Processo de
gerenciamento de projeto: uma visão prática
Professor: Leandro Rosa de Assis
Por que gerenciar Projetos na área de TI ?
• Em 1994 o Standish Group analisou 3682 projetos e percebeu que 83,2% foram cancelados ou entregues excedendo o prazo ou o custo
• Em 2002, Jim Jonhson apontou que 64% das funcionalidades implementadas são raramente ou nunca utilizadas
Por que gerenciar Projetos na área de TI ?
• 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
* 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.
Por que gerenciar Projetos na área de TI ?
• Conclusão:– Baixa exatidão entre o planejado e realizado– Imaturidade da indústria de software em realizar
previsões e estimativas– Baixo senso de prioridade– Gastos além do previsto– Pouco alinhamento com os interesses do negócio– Resumindo: estratégias de planejamento
incompatíveis com a realidade de projetos
Por que gerenciar Projetos na área de TI?
Gestão de Projetos
• Métodos e ferramentas que organizam as tarefas, identificando seqüenciamento de execução e dependências existentes
• Apóia a alocação de recursos e tempo• Rastreamento da execução das atividades• Medição do progresso relativo ao que foi
definido no plano de projeto
Gestão de Projetos: Plano de Projeto
• O plano de projeto é um guia essencial à condução do projeto sem o qual o gerente fica perdido
• 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.
• Segundo o PMI (Project Management Institute) em sua “bíblia”, o PMBOK 4 ª edição , gerencia-se projetos em nove áreas. A ver:
Gestão de Projetos: PMBOK 4ª edição
Gestão de Projetos: ciclo de vida de um projeto
• Iniciar 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
• PlanejarAtuação do Gerente de Projeto para organizar o planejamento da fase execução à luz do modelo de disciplinas e iterações do RUP
• ExecutarExecução de atividades inerentes aos papéis definidos no processo de desenvolvimento software
• Encerrar Formalidades documentas e transferência de conhecimentos/resultados
Modelo tradicional: RUP
Representação do modelo tradicional RUP em um cronograma
Fase “Iniciar”
• Desenvolvimento (Solicitante do Projeto) e validação (Gerente de Projeto) do “Termo de Abertura” de um projeto
• Processo de desenvolvimento de software: a modelagem de negócio deverá compor o escopo da necessidade, parte integrante do “Termo de abertura”
Atenção especial: Gestão de Demandas
•Recebimento e liberação de demandas
Recebimento de ordem de serviçoAnálise de ordem de serviço
•Planejamento e aceitação
Definição do escopo de atendimento da ordem de serviçoElaboração do plano de atendimento da ordem de serviço
•Recebimento e liberação de demandas
Recebimento de ordem de serviçoAnálise de ordem de serviço
•Planejamento e aceitação
Definição do escopo de atendimento da ordem de serviçoElaboração do plano de atendimento da ordem de serviço
Fase “Iniciar”
• 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
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
Disciplinas:•Modelagem de Negócio (parte integrante do “Termo de Abertura”)•Análise de Requisito•Projeto•Codificação•Teste•Gerência de Configuração
Fase “Iniciar”
• Utilizando a técnica PERT (Program Evaluation and Review Technique)para estimar tarefas e formação da Base Histórica:
Fase “Iniciar”• Identificar a capacidade de esforço da equipe
pesquisando alocação do recurso (via ferramental: MS PROJECT, PROJECT WEB ACCESS e outros)
• Aceitar o “Termo de Abertura” caso a capacidade de esforço seja suficiente para atender a demanda
• Criação do “Plano de Gerenciamento”
• Registrar aceites do “Plano de Gerenciamento”
Detalhando um Plano de Gerenciamento ou Plano de Projeto
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
Fase “Planejar”
• Aplicar no cronograma o planejamento de marcos e alocação de recursos da fase de execução
• Salvar linha de base da fase de execução• Apresentar o planejamento da fase de
execução aos recursos do projeto
Planejamento da execução do projeto e a respectiva alocação dos recursos
Fase “Execução”
• 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
Desenvolver: Requisito
Desenvolver: Projeto
Desenvolver: Código fonte
Aplicar: Teste
Aplicar: Gerência de Configuração
Plano de Gerenciamento:
• Escopo da solução (estimativa e impacto por
disciplina)• Marcos de entrega por
escopo da solução• Plano de contingência e
atenuante de riscos• Outros
Fase “Execução” : Gerência de Configuração
• 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
• 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.
Fase “Execução” : Gerência de Configuração
Fase “Execução” : atuação do responsável pela Gerência de Configuração (apoiada pelo
Gerente de Projeto)
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
Fase “Execução”
• O Gerente de Projeto deverá monitorar e controlar:– As mudanças ocasionadas em função de:
* Estouro de estimativas no consumo do esforço
*Alteração do escopo das necessidades* Impactos gerados por outros projetos
– Técnicas: reuniões de acompanhamento, relatórios de conclusão de tarefas e apropriação de horas
Fase “Executar”
– Estouro de Custo (esforço em horas X valor hora )
– Riscos via plano de ação (contingência e atenuante)
– 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)
Fase “Executar”
– 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)
– Apropriação de horas dos recursos para garantir a formação da Base Histórica
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
Fase “Encerrar”
• Via ferramental concluir todas as atividades do projeto
• Notificar aos envolvidos (determinados pela matriz de responsabilidades), o encerramento do projeto
• Realizar a transição de resultados do projeto
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
Fase “Encerrar”
• Responsabilidades do Escritório de Projetos(PMO): – auditoria em conteúdo dos projetos(artefatos e
cronograma)– 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)
“Realizar revisões de todo o trabalho com os colegas de forma que mais de uma pessoa esteja a par das atividade desenvolvidas”
Do livro Engenharia de Software, Roger S. Pressman
Top Related