Gerência de Projetos e Manutenção de Software Aula 10 Medição / Manutenção / Reutilização / Encerramento Andréa Magalhães Magdaleno andrea@ic.uff.br 2018.02
Agenda Medição Manutenção Reutilização Encerramento do Projeto Próximos Passos GPMS 2018.02 2
MEDIÇÃO
Medição Por que medir? O que significa uma medição? Medição é o caminho para maturidade! GPMS 2018.02 4
Medição Medições permitem: Aumentar a visibilidade do produto, projeto ou processo Tomadas de decisão objetivas ( eu acho x eu tenho certeza ) 2 3 4 5 9 7 8 Processo Projeto Produto GPMS 2018.02 5
Baseline de medições Medições isoladas usualmente são inúteis A partir de diversas medições em contextos semelhantes é possível Estabelecer uma baseline Comparar as novas medições com a baseline GPMS 2018.02 6
Medindo pessoas? Importante Não utilizar medições de Engenharia de Software para punir ou premiar indivíduos!!! Medições devem ser utilizadas para aprimorar o produto, projeto ou processo GPMS 2018.02 7
O que medir? Existe uma técnica que nos apoia nessa tarefa Goal-Question-Metric (GQM) Algoritmo 1. Definir os objetivos de negócio (Goal) 2. Definir questões que permitem verificar se cada objetivo está sendo atingido (Question) 3. Definir medidas que apoiam na resposta de cada questão (Metric) GPMS 2018.02 8
Exemplo: processo de Gerência de Configuração O que medir em Gerência de Configuração? A efetividade do processo Os custos associados Os benefícios obtidos Sugestão: Aplicar GQM Começar a medir antes de modificar o processo GPMS 2018.02 9
Exemplo: processo de Gerência de Configuração Métricas Custo de operação Número de sistemas/ics sob gerência de configuração Número de solicitações de modificação por mês Tempo gasto para resolução de solicitações de modificação Carga de disco/memória/processamento do servidor de GC Densidade de defeitos por severidade Número de achados na auditoria de GC Tempo gasto para resolução dos achados de auditoria Intervalo entre releases Número de releases corretivas GPMS 2018.02 10
Como analisar as métricas obtidas? É possível definir um limite (threshold) para a métrica em questão Se a métrica passar desse limite, é necessário fazer uma análise de causa Qual seria um limite apropriado? Que tal deixar a própria história determinar esse limite? GPMS 2018.02 11
Processos estáveis x capazes Nem sempre o processo mais rápido é um processo estável ou capaz Um processo estável permite que o desempenho futuro seja previsível em função do desempenho passado Um processo capaz é um processo estável em que o desempenho atende aos requisitos do usuário GPMS 2018.02 12
Processos estáveis x capazes Problema: Ir em até 20 minutos de Icaraí para São Francisco Processos Ir de carro Ir de ônibus Ir de bicicleta Ir a pé Quais processos são estáveis? Quais processos são capazes? GPMS 2018.02 13
Processos estáveis x capazes carro ônibus probabilidade probabilidade tempo 20 min tempo 20 min a pé bicicleta probabilidade probabilidade estável e capaz tempo 20 min tempo 20 min GPMS 2018.02 14
Gráfico de controle O gráfico de controle é um artefato que nos permite analisar a estabilidade de um processo Foi criado em 1920 por Walter Shewhart 12,0 10,0 8,0 6,0 4,0 2,0 0,0 1 3 5 7 9 11 13 15 17 19 GPMS 2018.02 +3σ +2σ +1σ μ -1σ -2σ -3σ Solicitações corretivas 15
Algoritmo para construção do gráfico de controle 1. Coletar uma série temporal da métrica desejada 2. A partir da série temporal da métrica desejada calcular 1. Média: µ = 1 n x i n i= 1 2. Desvio-padrão: σ = 1 n ( x i µ ) 1 i= n 1 2 GPMS 2018.02 16
Algoritmo para construção do gráfico de controle 3. Desenhar um gráfico com linhas delimitando Média 1 desvio-padrão para cima e para baixo da média 2 desvios-padrão para cima e para baixo da média 3 desvios-padrão para cima e para baixo da média 4. Desenhar os pontos da série desejada e conectar os pontos via uma linha GPMS 2018.02 17
Exemplo número de solicitações corretivas por semana Passo 1 coleta de métricas Semana 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Solicitações corretivas Passo 2 cálculo de média e desvio padrão μ 5,65 σ 1,39 5 6 5 9 6 5 4 6 7 5 6 5 5 7 6 3 4 5 8 6 GPMS 2018.02 18
Exemplo número de solicitações corretivas por semana Passos 3 e 4 desenho do gráfico de controle Semana 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Solicitações 5 6 5 9 6 5 4 6 7 5 6 5 5 7 6 3 4 5 8 6 corretivas +3σ 9,89,89,89,89,89,89,89,89,89,89,89,89,89,89,89,89,89,89,89,8 +2σ 8,48,48,48,48,48,48,48,48,48,48,48,48,48,48,48,48,48,48,48,4 +1σ 7,07,07,07,07,07,07,07,07,07,07,07,07,07,07,07,07,07,07,07,0 μ 5,75,75,75,75,75,75,75,75,75,75,75,75,75,75,75,75,75,75,75,7-1σ 4,34,34,34,34,34,34,34,34,34,34,34,34,34,34,34,34,34,34,34,3-2σ 2,92,92,92,92,92,92,92,92,92,92,92,92,92,92,92,92,92,92,92,9-3σ 1,51,51,51,51,51,51,51,51,51,51,51,51,51,51,51,51,51,51,51,5 GPMS 2018.02 19
Exemplo número de solicitações corretivas por semana Passos 3 e 4 desenho do gráfico de controle 12,0 10,0 8,0 6,0 4,0 2,0 0,0 1 3 5 7 9 11 13 15 17 19 GPMS 2018.02 +3σ +2σ +1σ μ -1σ -2σ -3σ Solicitações corretivas 20
Análise do gráfico de controle Causa comum de variação Dentro dos limites de probabilidade Existe em todo processo estável e previsível Causa especial de variação Foge aos limites de probabilidade Precisa ser analisada e evitada para que o processo possa ser estável e previsível GPMS 2018.02 21
Análise do gráfico de controle Quando o comportamento do gráfico foge do esperado... É necessário achar uma causa atribuível O processo pode estar instável Situações a serem analisadas 1 evento além de μ ± 3σ 2 de 3 eventos sucessivos do mesmo lado além de μ ± 2σ 4 de 5 eventos sucessivos do mesmo lado além de μ ± 1σ 8 eventos sucessivos do mesmo lado de μ GPMS 2018.02 22
Análise do gráfico de controle 20,0 15,0 10,0 5,0 0,0-5,0 1 3 5 7 9 11 13 15 17 19 +3σ +2σ +1σ μ -1σ -2σ -3σ Solicitações corretivas GPMS 2018.02 23
MANUTENÇÃO DE SOFTWARE
O que é a manutenção? O processo de modificar um sistema de software ou componente, depois da entrega, para corrigir falhas, melhorar desempenho ou outros atributos, ou adaptar a mudanças no ambiente. IEEE Std 620.12 1990 Leonardo Murta Manutenção GPMS de 2018.02 Software 25 25
Quando inicia a manutenção? Desenvolvimento Release Manutenção Leonardo Murta Manutenção GPMS de 2018.02 Software 26 26
Quando inicia a manutenção? Desenvolvimento Release Manutenção Desenv. Desenv. Release Desenv. Release Manut. Manut. Leonardo Murta Manutenção GPMS de 2018.02 Software 27 27
Quais são os tipos de manutenção? Manutenção Correção Evolução Emergencial Corretiva Preventiva Adaptativa Perfectiva Leonardo Murta Manutenção de Software 28
Quais são os tipos de manutenção? Manutenção corretiva Reativa Corrige problemas reportados Faz o software voltar a atender aos requisitos Manutenção emergencial Não programada Mantém temporariamente o sistema funcionando Necessita uma manutenção corretiva posterior Leonardo Murta Manutenção GPMS de 2018.02 Software 29 29
Quais são os tipos de manutenção? Manutenção preventiva Pró-ativa Corrige problemas latentes Manutenção adaptativa Mantém o software usável após mudanças no ambiente Manutenção perfectiva Provê melhorias para o usuário Melhora atributos de qualidade do software Leonardo Murta GPMS 2018.02 30 30
Contratos de manutenção Tipo 1 Um único contrato para desenvolvimento e manutenção Valor fixo, disponível para todos os tipos de manutenção Tipo 2 Contrato separado para manutenção Período de manutenções corretivas predefinido Cada manutenção preventiva, adaptativa ou perfectiva contratada separadamente Leonardo Murta Manutenção GPMS de 2018.02 Software 31 31
Boas práticas para manutenção (de código) Legibilidade Estruturação Redução da complexidade Comentários precisos Indentação e espaçamento Evitar o uso de armadilhas clássicas das linguagens Ex.: Goto, herança múltipla, etc. Usar técnicas que ajudam a rastrear erros Ex.: Controle de exceções Leonardo Murta Manutenção GPMS de 2018.02 Software 32 32
Boas práticas para manutenção (de código) Rastreabilidade Código para requisitos, análise e projeto Código para solicitações de modificação Padronização Inspeções Testes Atualização da documentação Ex.: Modelos Leonardo Murta Manutenção GPMS de 2018.02 Software 33 33
Frases para pensar... Fazer é só uma vez, manter é para sempre Se você não tem tempo para fazer direito, quando terá tempo para fazer de novo? GPMS 2018.02 34
REUTILIZAÇÃO DE SOFTWARE Curso 01/04/2011 de Reutilização 35
Motivação A Reutilização é inerente ao processo de solução de problemas utilizado pelos seres humanos A medida em que soluções são encontradas, estas são utilizadas em problemas similares Nossa capacidade de abstração garante a adaptação necessária ao novo contexto O problema, portanto, não é a falta de reutilização na Engenharia de Software, mas a falta de uma sistemática ampla e formal para realizá-la GPMS 2018.02 36
Motivação A Reutilização de Software visa sistematizar e difundir práticas de reutilização na organização Como? Aplicando técnicas de engenharia de domínio para definir o escopo, especificar a estrutura e construir ativos reutilizáveis para uma classe de sistemas, subsistemas ou aplicações GPMS 2018.02 37
Reutilização de Software A Reutilização de Software é a disciplina responsável pela criação de sistemas de software a partir de software preexistente [KRUEGER, 1992] Consiste na incorporação de software existente ou conhecimento referente a esse software para construir um novo GPMS 2018.02 38
Benefícios Melhores índices de produtividade Produtos de melhor qualidade, mais confiáveis, consistentes e padronizados Redução dos custos e tempo envolvidos no desenvolvimento de software Maior flexibilidade na estrutura do software produzido, facilitando sua manutenção e evolução GPMS 2018.02 39
Desafios Identificação, recuperação e modificação de artefatos reutilizáveis Compreensão dos artefatos recuperados Qualidade de artefatos reutilizáveis Composição de aplicações a partir de componentes Barreiras psicológicas, legais e econômicas Necessidade da criação de incentivos à reutilização GPMS 2018.02 40
Desenvolvimento baseado em reutilização O processo de Reutilização de Software é composto por dois processos principais Desenvolvimento para Reutilização Produção de ativos reutilizáveis para um domínio específico através de técnicas de Engenharia de Domínio (ED) Desenvolvimento com Reutilização Construção de aplicações com base na instanciação dos artefatos gerados através de técnicas de Engenharia de Aplicação (EA) GPMS 2018.02 41
ENGENHARIA DE DOMÍNIO Curso 01/04/2011 de Reutilização 42
Engenharia de Domínio Domínio: Área de conhecimento ou atividade caracterizada por um conjunto de conceitos conhecidos dos profissionais dessa área (RUP, 1998). Exemplos: Óleo e Gás Seguros Telefonia móvel 01/04/2011 Curso de Reutilização GPMS 2018.02 43 43
Engenharia de Domínio Componentes? Arquitetura? Reuso? 01/04/2011 Curso de Reutilização GPMS 2018.02 44 44
Engenharia de Domínio Uma abordagem baseada em reutilização para definição do escopo, especificação da estrutura, e construção de recursos para uma classe de sistemas, subsistemas ou aplicações (ISO/IEC 12207). Processo de identificação e organização do conhecimento sobre uma classe de problemas, o domínio do problema, para suportar sua descrição e solução (ARANGO, PRIETO-DIAZ, 1991) 01/04/2011 Curso de Reutilização GPMS 2018.02 45 45
Engenharia de Domínio Objetivos: Originar meta-sistemas, ou seja, sistemas que são reutilizados na construção de aplicações específicas Descobrir e definir modelos de domínio e arquiteturas comuns às famílias de aplicações para suportar reutilização pré-planejada Tornar explícito e formalizar as teorias específicas ao domínio que permitem aos projetistas e especialistas do domínio raciocinar sobre problemas e sistemas no domínio da aplicação 01/04/2011 Curso de Reutilização GPMS 2018.02 46 46
Engenharia de Domínio Etapas: Análise de Domínio: o conhecimento existente sobre o domínio é estudado e formalizado através de um modelo de domínio Projeto de Domínio: arquiteturas de software são construídas para atender aos requisitos identificados no modelo de domínio Implementação do Domínio: artefatos reutilizáveis são implementados para compor as arquiteturas 01/04/2011 Curso de Reutilização GPMS 2018.02 47 47
Engenharia de Domínio Profissionais envolvidos: Fontes: usuários finais que utilizam aplicações no domínio e especialistas de domínio que provêm informações a respeito de conceitos e funcionalidades relevantes no domínio Produtores: analistas e projetistas do domínio que capturam as informações do domínio das fontes e aplicações existentes e realizam a análise, projeto e implementação dos artefatos reutilizáveis (i.e. Engenheiros de Domínio) Consumidores: desenvolvedores de aplicações e interessados no entendimento do domínio (SIMOS, 01/04/2011 1996; WERNER e BRAGA, Curso 2005) de Reutilização GPMS 2018.02 48 48
Engenharia de Domínio Produtos: Modelos conceituais que capturam os principais conceitos e funcionalidades do domínio Estrutura arquitetural a ser seguida pelas aplicações Artefatos implementacionais Documentação associada Obs. Servem como fonte unificada de referência (repositório de conhecimento) 01/04/2011 Curso de Reutilização GPMS 2018.02 49 49
Modelagem de características Característica Um aspecto, uma qualidade, ou uma característica visível ao usuário, proeminente ou distinta, de um sistema de software (KANG et al., 1990) Objetivo: capturar e gerenciar as similaridades e diferenças, de forma a facilitar o entendimento de clientes e desenvolvedores no que se refere às capacidades gerais de um domínio, que são expressas através de características (KANG et al., 1990) 01/04/2011 Curso de Reutilização GPMS 2018.02 50 50
Modelagem de características Variabilidade: Habilidade que um sistema ou artefato de software possui de ser alterado, customizado, ou configurado para um contexto em particular (BOSCH, 2004). Ponto de variação: característica que reflete a parametrização no domínio de uma maneira abstrata. Um ponto de variação é configurável através das variantes Variantes: características que atuam como alternativas para se configurar um ponto de variação Invariantes: características fixas, que representam elementos não configuráveis em um domínio 01/04/2011 Curso de Reutilização GPMS 2018.02 51 51
Modelagem de características Opcionalidade: Elementos opcionais: podem ou não estar presentes nos produtos derivados a partir da linha de produtos Elementos mandatórios: devem obrigatoriamente estar presentes em todos os produtos derivados a partir da linha de produtos Relações: Dependência: relação que representa a necessidade de seleção de elementos em conjunto Mútua exclusividade: relação que representa a incompatibilidade da seleção conjunto de determinados elementos 01/04/2011 Curso de Reutilização GPMS 2018.02 52 52
Abordagens Existentes Primeiras abordagens: Draco (NEIGHBORS, 1989) FODA (Feature Oriented Domain Analysis) (KANG et al., 1990) Facetas (PRIETO, 1991) EDLC (Evolutionary Domain Life Cycle) (GOMMA, 1992) ODM (Organization Domain Modeling) (SIMOS, 1996) FODACom (GRISS, 1998) Abordagens mais recentes: FORM (Feature-Oriented Reuse Method) (KANG, 2002) Odyssey-FEX (OLIVEIRA, 2006)... (WERNER e BRAGA, 2005) Abordagens que mesclam outras técnicas: DBC, ontologias, CSCW, gestão do conhecimento, agentes, aspectos, etc 01/04/2011 Curso de Reutilização GPMS 2018.02 53 53
Abordagens Existentes Exemplo Notação FODA: (KANG et al., 1990; OLIVEIRA, 2006) 01/04/2011 Curso de Reutilização GPMS 2018.02 54 54
Abordagens Existentes Exemplo Notação Czarnecki: 01/04/2011 Curso de Reutilização GPMS 2018.02 55 55
Abordagens Existentes Exemplo Notação Odyssey-FEX: (OLIVEIRA, 2006) 01/04/2011 Curso de Reutilização GPMS 2018.02 56 56
ENGENHARIA DE APLICAÇÃO Curso 01/04/2011 de Reutilização 57
Engenharia de Aplicação Estudo e uso de técnicas, processos e métodos para a produção de aplicações baseadas em reutilização (SIMOS, 1998) Desenvolve produtos de software baseado nos artefatos gerados pelo processo de Engenharia de Domínio (SEI, 2005) 01/04/2011 Curso de Reutilização GPMS 2018.02 58 58
Engenharia de Aplicação Atividade de recorte Seleção dos componentes necessários à aplicação em um alto nível de abstração, por meio do modelo do domínio, descendo gradualmente em níveis de abstração até conseguir atingir os componentes implementados ou semidesenvolvidos do domínio (MILER, 2000) Fortemente influenciada pela variabilidade modelada no domínio Características variáveis em artefatos do domínio determinam o tipo de aplicação que será instanciada GPMS 2018.02 59
Engenharia de Aplicação Possibilidade de utilização de um método de desenvolvimento conhecido pela organização, porém incorporando atividades de reutilização. Ex.: Desenvolvimento baseado em componentes (DIGRE, 1998) Arquitetura de Software (ARPA, 1994) Na EA os componentes são efetivamente reutilizados e combinados entre si para a construção de aplicações reais. (MILER, 01/04/2011 2000) Curso de Reutilização GPMS 2018.02 60 60
Engenharia de Aplicação Etapas: Análise da Aplicação: seleção do conhecimento e artefatos do domínio que são necessários para construir uma aplicação a partir de requisitos iniciais. Projeto da Aplicação: identificação na arquitetura de software dos artefatos que serão combinados na construção da aplicação. Implementação da Aplicação: os artefatos reutilizáveis selecionados são implementados para compor a aplicação. 01/04/2011 Curso de Reutilização GPMS 2018.02 61 61
LINHA DE PRODUTOS Curso 01/04/2011 de Reutilização 62
Linha de Produtos Definição Conjunto de sistemas de software que compartilham um conjunto de características comuns e controladas, que satisfazem necessidades de um segmento de mercado em particular, e são desenvolvidas a partir de artefatos (core assets), de forma predefinida(northrop, 2002). 01/04/2011 Curso de Reutilização GPMS 2018.02 63 63
Linha de Produtos Etapas (NORTHROP, 2002) 01/04/2011 Curso de Reutilização GPMS 2018.02 64 64
Linha de Produtos Desenvolvimento de núcleo de artefatos Escopo da linha de produtos Artefatos do núcleo Plano de Produção 01/04/2011 Curso de Reutilização GPMS 2018.02 65 65
Linha de Produtos Desenvolvimento do Produto Análise do domínio da aplicação Possibilidade de evolução da LP! Instanciação da arquitetura do produto Povoamento da arquitetura 01/04/2011 Curso de Reutilização GPMS 2018.02 66 66
ENCERRAMENTO DO PROJETO
Encerramento Verificação de todos os grupos de processos para determinar se seus processos foram encerrados Homologação e encerramento de contratos realizados com fornecedores de recursos e serviços utilizados durante o projeto Fechamento da subcontratação Fechamento de projeto ou fase Disseminação das informações finais sobre o projeto, como lições aprendidas e resultados obtidos Também pode indicar o fim prematuro do projeto, por cancelamento. GPMS 2018.02 68
Encerramento Não é hora de relaxar Se o gerente relaxa, a equipe perde o foco e relaxa também Também não é hora de se desesperar Calma Organize e trate o trabalho final como um mini projeto Comunique-se com a equipe, mas deixe que os membros terminem suas tarefas Confira a qualidade Trabalhe em turnos se a sobrecarga for inevitável GPMS 2018.02 69
Encerramento Postmortem Revisão da qualidade dos produtos A meta foi obtida? A visão do projeto foi alcançada? Produtos com qualidade desejada? Revisão da qualidade dos processos O projeto estava no caminho certo do início ao fim? O planejamento foi correto? Examinando o valor do projeto Quanto vale o projeto? Lições aprendidas Alterações no processo organizacional GPMS 2018.02 70
Encerramento Obtendo a aprovação final Aceitação informal Prazo concluído e produtos gerados Aceitação formal Depende de um acordo de aceitação do projeto estabelecido no início do projeto GPMS 2018.02 71
Encerramento Declaração... de vitória... de fracasso GPMS 2018.02 72
Exercício Preparar o relatório de encerramento com as lições aprendidas do seu trabalho GPMS 2018.02 73
PRÓXIMOS PASSOS
Cronograma Data Atividade 08/11/2018 Não haverá aula Profª em conferência 15/11/2018 Feriado 22/11/2018 Prova 2 29/11/2018 Seminário em Grupo 2 06/12/2018 VS e VR 13/12/2018 VS para quem fez VR GPMS 2018.02 75
Seminários Apresentação do andamento do trabalho Apresentação com duração de 20 minutos por grupo Entrega de slides e relatório do trabalho Opcional o uso do quadro 1º. Seminário Escopo do produto Escopo do projeto Estimativas de esforço e custo EAP Orçamento Cronograma Versão parcial do produto ** Plano de projeto 2º. Seminário Plano de comunicação Análise de riscos Monitoramento e controle Gráfico de burndown Análise de valor agregado Plano de gerência de configuração Gestão de mudanças Lições aprendidas Versão final do produto ** Relatório de encerramento do projeto GPMS 2018.02 76
Dúvidas? GPMS 2018.02 77
Gerência de Projetos e Manutenção de Software Aula 10 Medição / Manutenção / Reutilização / Encerramento Andréa Magalhães Magdaleno andrea@ic.uff.br 2018.02