Post on 14-Nov-2018
Gerência de ProjetosProf. Dr. Sandro Ronaldo Bezerra Oliveira
srbo@ufpa.br
www.ufpa.br/srbo
Laboratório de Tecnologia de Software – LTS
www.ufpa.br/lts
Rede Paraense de Pesquisa em Tecnologias de
Informação e Comunicações
www.ufpa.br/redetic
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
2
Agenda Motivação
MPS-BR
Gerência de Projetos - GPR
GPR no Contexto do MR-MPS
Resultados Esperados do GPR
Características de Empresas com GPR
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
3
O que é Qualidade? Qualidade está fortemente relacionada à
Conformidade com os Requisitos.
O que é “conformidade em relação a requisitos”?
observado x especificado.
Pode haver problemas na observação.
Pode haver problemas na especificação.
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
4
O que é Qualidade? Qualidade diz respeito à Satisfação do Cliente.
Requisitos são especificados por pessoas e com o
objetivo de satisfazer outras pessoas.
Uma especificação depende das escolhas feitas (clientes
alvo).
Pode haver problemas na especificação.
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
Benefícios da Qualidade Na visão do fornecedor (ex: equipe interna de TI ou
fornecedor externo – do mercado)
Maior produtividade
Maior precisão nas estimativas
Redução de defeitos no produto
Aumento da confiabilidade do produto
Menos esforço de re-trabalho
Menos horas extras de trabalho
Redução do tempo para atender o mercado
Redução de custo de desenvolvimento e manutenção
Maior competitividade
Maior índice de satisfação do cliente/usuário final5
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
Qualidade de Software
6
Conjunto de características a serem satisfeitas em
um determinado grau, de modo que o software
satisfaça às necessidades de seus usuários.
Usuários
Finais
Desenvolvedores
Usuários
Indiretos
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
7
Qualidade de Software O aspecto não repetitivo do desenvolvimento de
software torna essa atividade difícil e em boa medida
imprevisível.
Delimitar o escopo de um sistema não é trivial.
A volatilidade dos requisitos é lugar comum no
desenvolvimento de software.
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
8
Qualidade de Software Fatores que afetam o desenvolvimento e que
influenciam no julgamento dos usuários:
Tamanho e complexidade do software;
Número de pessoas envolvidas no projeto;
Métodos, técnicas e ferramentas utilizadas;
Custo x benefício do sistema;
Custos associados à existência de erros;
Custos associados à detecção e remoção de erros;
Etc.
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
9
Qualidade do Produto x
Qualidade do Processo
Qualidade do produto de software não se atinge de
forma espontânea.
A qualidade do produto depende fortemente da
qualidade do processo de desenvolvimento.
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
10
Qualidade do Processo Um bom processo não garante que os produtos produzidos
são de boa qualidade, mas é um indicativo de que a
organização é capaz de produzir bons produtos.
Motivação para a busca da Qualidade do Processo de
Software:
Aumento da qualidade do produto.
Diminuição do retrabalho.
Maior produtividade.
Redução do tempo para atender o mercado (time to market).
Maior competitividade.
Maior precisão nas estimativas.
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
11
Qualidade do Processo A implantação de um Programa de Qualidade começa
pela definição e implantação de um processo de
software.
Processos têm de ser definidos caso a caso, levando-
se em consideração as características específicas do
projeto em questão: equipe, domínio de aplicação, tipo
de software, tecnologias a serem adotadas, restrições
de negócio (cronograma, custo, qualidade) etc.
Apoio de Normas e Modelos de Qualidade de Processos
de Software.
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
12
MPS.BR Dezembro de 2003: Início do Programa mobilizador
para a Melhoria do Processo de Software Brasileiro,
coordenado pela SOFTEX (Associação para Promoção
da Excelência do Software Brasileiro), com apoio do
Ministério da Ciência e Tecnologia (MCT) e do Banco
Interamericano de Desenvolvimento (BID).
Abril de 2005: Versão 1.0
Maio de 2006: Versão 1.1
Junho de 2007: Versão 1.2
Maio de 2009: Versão 2009
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
13
MPS.BR: Objetivo e Metas
Objetivo: Melhoria de processos de software nas micros, pequenas e médias empresas (PMEs), a um custo acessível, em diversos locais do país.
Como?
Desenvolvimento (e Aprimoramento) do Modelo MPS.BR.
Implementação e Avaliação do Modelo MPS.BR em Empresas, com foco em grupos de empresas.
Nível G
17
Parcialmente Gerenciado
Composto pelos Processos Gerência de Projetos – GPR
Gerência de Requisitos – GRE
A Implementação dos Processos deve Satisfazer Atributo de Processo 1.1 (AP 1.1)
O Processo é Executado
Atributo de Processo 2.1 (AP 2.1)
O Processo é Gerenciado
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
Gerência de Projetos -
GPR Segundo MR-MPS
“O propósito do processo Gerência de Projetos é
estabelecer e manter planos que definem as atividades,
recursos e responsabilidades do projeto, bem como
prover informações sobre o andamento do projeto que
permitam a realização de correções quando houver
desvios significativos no desempenho do projeto.”
18
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
Contexto - GPR
19
Estabelecer
EstimativasDados do
Planejamento
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
Resultados Esperados -
GPR
20
Estabelecer Estimativas
Dados do
Planejamento
Dimensionar
Tarefas e
Produtos de
Trabalho
Definir
Escopo do
Trabalho
Definir
Ciclo de Vida
do Projeto
Determinar
Estimativas
de Esforço
e Custo
GPR1 GPR2
GPR3
GPR4
- WBS ou EAP
- Documento de Visão
- Lista de Tarefas, Casos de
Uso, Requisitos, Estórias
- Complexidade do Número
de Requisitos
- EAP com Dados Históricos
- Pontos por Função (FPA)
- Pontos por Casos de Uso
(UCP)
- Ciclo de Vida
- Fases do Ciclo de Vida
- Estrutura de Organização
das Atividades
- Relacionamento das
Atividades
- Estimativas de Esforço e
Custo usando Modelos e/ou
Dados Históricos
- Consideram: Escopo
Produtos, Riscos, Mudanças,
Ciclo de Vida, Viagens, Nível
de Competência da Equipe
- Produtividade: Tecnologia,
Experiência
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
Contexto de GPR
21
Desenvolver
um
Plano de Projeto
Estabelecer
EstimativasDados do
Planejamento
Plano do
Projeto
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
Resultados Esperados -
GPR
22
Desenvolver um Plano de Projeto
Dados do
Planejamento
Identificar
Riscos
do
Projeto
Estabelecer
Orçamento
e
Cronograma
Planejar RH
considerando
Conhecimento
e Perfil
Planejar
Recursos e
Ambiente de
Trabalho
GPR5 GPR6 GPR7
GPR8
- Para Cronograma usa-se:
WBS ou EAP, Estimativas de
Esforço, Custo, Ciclo de Vida,
Dependência entre Tarefas,
Pontos de Controle e Marcos
- Para Orçamento usa-se:
Cronograma e Estimativa de
Custo
Planejar
Gerência
de
Dados
GPR9
Estabelecer
Plano
de
Projeto
GPR10
Plano do
Projeto
- Identificar, Analisar e
Priorizar os Riscos
- Planilha de Riscos com:
Identificador, Descrição,
Probabilidade, Impacto e
Prioridade no seu Tratamento
- Deve-se Monitorar e
Atualizar a Planilha
- Determinar Funções,
Responsabilidades, Relações
Hierárquicas do Projeto
- Inclui informações de como
e quando o Recurso será
Envolvido, Critérios para sua
Liberação, Mapa de
Competências da Equipe e
Identificação da Necessidade
de Treinamento
- Treinamento pode ser
Formal e Informal: Sala de
Aula, on-line, baseado em
Computador, Leituras,
Aconselhamentos e
Orientações
- Equipamentos, serviços,
Ferramentas, Componentes,
Viagens e Requisitos de
Processo
- Dados: Relatórios, Dados
Informais, Estudos e Análises
Atas de Reunião, Lições
Aprendidas, Documentações,
Artefatos Gerados.
- Em qualquer Formato e
Meio
- Foco na Identificação,
Coleta, Armazenamento e
Distribuição para garantir
Segurança, Integridade e
Acesso
- Todos os Planos que
afetam o Projeto devem
estar Integrados e levar
em consideração a
Dependência entre eles
- Importante existir
Alinhamento entre o que foi
Estimado e o que está sendo
Planejado e o que será
Acompanhado
- Quando necessário o Plano
deve ser Revisto
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
Contexto de GPR
23
Obter
Comprometimento
com o Plano
Desenvolver
um
Plano de Projeto
Estabelecer
EstimativasDados do
Planejamento
Plano do
Projeto
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
Resultados Esperados -
GPR
24
Obter Comprometimento com o Plano
- Examina Aspectos
Técnicos, Financeiros e
Humanos, Objetivos de
Negócio da Organização
- Em Marcos do Projeto uma
Confirmação da Continuidade
do Projeto é necessária
Avaliar a
Viabilidade
de Atingir
Metas
GPR11
Plano do
Projeto
Revisar
Plano e Obter
Compromisso
GPR12
- Revisar o Planejamento
com os Interessados e
Conciliar as Diferenças
Existentes
- Realizar Negociações a
partir de Variáveis do Projeto
- Obter Compromisso envolve
interação entre Interessados
Internos e Externos
- Reunião de Kick off
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
Contexto de GPR
25
Obter
Comprometimento
com o Plano
Monitorar o Projeto
em Relação
ao Plano
Gerenciar
Ações Corretivas
até Encerramento
Desenvolver
um
Plano de Projeto
Estabelecer
EstimativasDados do
Planejamento
Plano do
Projeto
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
Resultados Esperados -
GPR
26
Monitorar o Projeto em
Relação ao Plano
- Avaliar Aderência aos
Planos Continuamente ao
longo do Ciclo de Vida
- Os Resultados e Critérios
de Conclusão das Tarefas
são Analisados, as Entregas
são Avaliadas, Cronograma,
Esforços e Uso dos Recursos
são Examinados
- Realizar Análises e Tomar
Decisões considerando as
Variações dos Dados e
Desvios entre Resultados e
Valores Atuais e Esperados
Gerenciar
Planejamento
do
Projeto
GPR13
Plano do
Projeto
Realizar
Revisões
em
Marcos
GPR15
Gerenciar
Envolvimento
dos
Interessados
GPR14
Gerenciar Ações
Corretivas até
Encerramento
Identificar e
Analisar
Problemas nas
Monitorações
GPR16
Tratar
Problemas
(Ações
Corretivas)
GPR17
- Os Interessados
Relevantes devem ser
Identificados, em que Fases
e Como eles são Envolvidos
- Comunicações, Revisões
em Marcos,
Comprometimentos
- Definir e Monitorar um
Plano de Gerência de
Comunicações
- Os Compromissos
Assumidos estão sendo
cumpridos e negociados
- Revisões em Marcos
não podem ser confundidas
com Acompanhamento
Diário
- Marcos devem ser definidos
previamente
- Verificar o Andamento do
Projeto
- As Atividades de Revisão
possibilitam a Identificação
de Problemas
- Problemas devem ser
Analisados e Registrados em
Ferramentas, Planilhas ou
outro Meio de Gerência
- Ações Corretivas devem
ser estabelecidas para
Resolver os Problemas
- Ações Corretivas devem ser
Gerenciadas até serem
Concluídas
- Registrar: o Controle dos
Problemas, as Ações
Tomadas, os Responsáveis e
os Resultados
- Caso não se consiga
resolver em um nível,
deve-se Escalonar a
Resolução a Níveis
Superiores de Gerência
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
Características de
Empresas Organizações têm maior probabilidade de cumprir
compromissos de requisitos, prazos e custos, mas desde que sejam semelhantes a outros realizados anteriormente.
A organização é disciplinada, mas não está bem preparada para mudanças.
Há preocupação com a gerência do projeto. Os gerentes acompanham custos, cronogramas e funcionalidades de cada um dos projetos. Porém, a gerência ainda não é pró-ativa, tomando ações normalmente quando se está diante de uma crise.
Os projetos podem ter processos diferentes. No entanto, existe uma política para guiar os projetos no estabelecimento desses processos.
27