Você está na página 1de 40
TESE DE DOUTORADO EM DIREÇÃO A UM MÉTODO BASEADO EM MÉTRICAS PARA PREDIÇÃO DE IMPACTO
TESE DE DOUTORADO EM DIREÇÃO A UM MÉTODO BASEADO EM MÉTRICAS PARA PREDIÇÃO DE IMPACTO
TESE DE DOUTORADO EM DIREÇÃO A UM MÉTODO BASEADO EM MÉTRICAS PARA PREDIÇÃO DE IMPACTO

TESE DE DOUTORADO

EM DIREÇÃO A UM MÉTODO BASEADO EM MÉTRICAS PARA PREDIÇÃO DE IMPACTO EM ATIVIDADES DE CODIFICAÇÃO EM PROJETOS DE SOFTWARE

ANDERSON FONSECA E SILVA ORIENTADOR - VINICIUS CARDOSO GARCIA

EM DIREÇÃO A UM MÉTODO BASEADO EM MÉTRICAS PARA PREDIÇÃO DE IMPACTO EM ATIVIDADES DE CODIFICAÇÃO EM PROJETOS DE SOFTWARE

u

CENÁRIO

2

u

Crescimento de Gastos com Software Corporativo

 

u

Mercado Indiano por volta de 15,3% em 2018

u

Mercado Global 9,4% em 2018 – US$ 387Bi (GARTNER 2017)

u

Agências Federais Americanas US$ 81Bi em 2019 (WHITEHOUSE 2018)

u

Provisionamento de Gastos com SW para o Departamento de Defesa Americano (US$ 36Bi) 2018:

u

23% Modernização e desenvolvimento;

u

10.6% serviços provisionados;

u

66,5% operações e manutenção

23% Modernização e desenvolvimento; u 10.6% serviços provisionados; u 66,5% operações e manutenção

MOTIVAÇÃO

3

MOTIVAÇÃO 3 Custos de manutenção em desenvolvimento de software como um percentual do custo total P

Custos de manutenção em desenvolvimento de software como um percentual do custo total P FLORIS (2010).

MOTIVAÇÃO 3 Custos de manutenção em desenvolvimento de software como um percentual do custo total P

MOTIVAÇÃO

4

MOTIVAÇÃO 4

JORNADA

5

JORNADA 5 Modelo de transferência de tecnologia GORSCHEK et al. (2006)
JORNADA 5 Modelo de transferência de tecnologia GORSCHEK et al. (2006)

Modelo de transferência de tecnologia GORSCHEK et al. (2006)

JORNADA 5 Modelo de transferência de tecnologia GORSCHEK et al. (2006)

JORNADA

6

u Projetos em execução dentro de uma consultoria de TI com atuação global (~400k colaboradores / > 2k em Recife / 800 atuando com projetos OO)

u Envolvidos

u

Arquiteto de Software (o Autor)

u

Analistas

u

Desenvolvedores

u

Gerentes de Projeto

u

Clientes

Arquiteto de Software (o Autor) u Analistas u Desenvolvedores u Gerentes de Projeto u Clientes

PROBLEMAS

7

u

Entendimento sobre os resultados entregues pelos processos e ferramentas

u

Iniciativas com relação a qualidade do design à medida em que os projetos evoluiam

u

Práticas de construção que impactam sobre a manutenibilidade e entropia do projeto

u

O custo sobre alterações de funcionalidades em tempo de manutenção do projeto

e entropia do projeto u O custo sobre alterações de funcionalidades em tempo de manutenção do

IMPACTOS

8

u Contingenciamento dos riscos do projeto por meio do aumento na precificação das propostas, registrando um conjunto de premissas, como uma forma de justificar eventuais problemas nas entregas, os efeitos colaterais possíveis das abordagens consiste:

u

Perda de competitividade no mercado, dado que, o demandante estará pagando por eventuais problemas, sem ter a visibilidade se tais incidentes acontecerão ou,

u

Desgaste em tentativas de negociação dos itens premissados como risco em um novo contrato, aditivo ou algo similar.

Desgaste em tentativas de negociação dos itens premissados como risco em um novo contrato, aditivo ou

OBJETIVO

9

u ESTABELECER UMA ABORDAGEM PARA O MONITORAMENTO SOBRE A QUALIDADE DOS PROJETOS DE FORMA CONTÍNUA, SENDO POSSÍVEL CARACTERIZAR E DIRECIONAR AÇÕES COM BASE EM:

INDICADORES, PROJEÇÕES DE CUSTOS, CLASSIFICAÇÃO E MELHORIA EM PARTES DO SISTEMA.

E DIRECIONAR AÇÕES COM BASE EM: INDICADORES, PROJEÇÕES DE CUSTOS, CLASSIFICAÇÃO E MELHORIA EM PARTES DO

ROADMAP

ROADMAP 10

10

ROADMAP 10

REVISÃO DA LITERATURA

11

ESBE – Evidence-Based Software Engineering

1990 - 2016

194 Publicações

Escassez no surgimento de novas métricas e modelos de avaliação de qualidade de software

• 194 Publicações • Escassez no surgimento de novas métricas e modelos de avaliação de qualidade
• 194 Publicações • Escassez no surgimento de novas métricas e modelos de avaliação de qualidade
• 194 Publicações • Escassez no surgimento de novas métricas e modelos de avaliação de qualidade

FUNDAMENTAÇÃO TEÓRICA

FUNDAMENTAÇÃO TEÓRICA 12

12

FUNDAMENTAÇÃO TEÓRICA 12

FUNDAMENTAÇÃO TEÓRICA

REPOSITÓRIO DE CODIGO E CONTROLE DE VERSÃO

Análise de refatoramento

Evolução de code smells

Efetividade na análise estática

Análise de métrica de qualidade

Visualização e evolução de software

de qualidade Visualização e evolução de software MÉTRICAS DE SOFTWARE Antes de 1992 – Foco em

MÉTRICAS DE SOFTWARE

Antes de 1992 – Foco em complexidade

Após 1992 – Medições em Linguagens OO

A partir de 2000 – Poucos trabalhos relacionados

MODELOS DE AVALIAÇÃO DE QUALIDADE DE SW (AQS)

Modelos proprietários e específicos

Falta de clareza nos mapeamentos entre atributos e propriedades

MONITORAMENTO EM AQS

Código-fonte foi o principal artefato utilizado para avaliar a qualidade de forma interna (OUHBI et al.

2014)

DÉBITO TÉCNICO (DT)

Uso de técnicas para a organizar, visualizar, identificar e gerenciar DT não tem sido fornecidas de forma facilmente integradas para software na prática (IZURIETA et al. 2012)

13

e gerenciar DT não tem sido fornecidas de forma facilmente integradas para software na prática (IZURIETA

14

A TESE

VISÃO GERAL

VISÃO GERAL 15

15

VISÃO GERAL 15

COLETAR

COLETAR 16

16

COLETAR 16

COLETAR

CARACTERIZAR

COLETAR CARACTERIZAR 17

17

COLETAR CARACTERIZAR 17

COLETAR

18

PROPRIEDADES DO DESIGN

Bansiya 2002
Bansiya 2002
COLETAR 18 PROPRIEDADES DO DESIGN Bansiya 2002 Correlação de Pearson R

Correlação de Pearson R

COLETAR 18 PROPRIEDADES DO DESIGN Bansiya 2002 Correlação de Pearson R

COLETAR

EVOLUÇÃO DE NÃO-CONFORMIDADES

COLETAR EVOLUÇÃO DE NÃO- CONFORMIDADES 19

19

COLETAR EVOLUÇÃO DE NÃO- CONFORMIDADES 19

AVALIAR

MANUTENIBILIDADE

AVALIAR MANUTENIBILIDADE 20 31 classes = 43,31% do Tamanho Total do Projeto em LoC

20

AVALIAR MANUTENIBILIDADE 20 31 classes = 43,31% do Tamanho Total do Projeto em LoC
AVALIAR MANUTENIBILIDADE 20 31 classes = 43,31% do Tamanho Total do Projeto em LoC

31 classes = 43,31% do Tamanho Total do Projeto em LoC

AVALIAR MANUTENIBILIDADE 20 31 classes = 43,31% do Tamanho Total do Projeto em LoC
AVALIAR MANUTENIBILIDADE 20 31 classes = 43,31% do Tamanho Total do Projeto em LoC

AVALIAR

MANUTENIBILIDADE

AVALIAR MANUTENIBILIDADE 21 Se considerarmos o fator tempo descrito na pág 24. da tese, onde o

21

AVALIAR MANUTENIBILIDADE 21 Se considerarmos o fator tempo descrito na pág 24. da tese, onde o

Se considerarmos o fator tempo descrito na pág 24. da tese, onde o entendimento do produto a ser mantido gira em torno de 30%

Classe

1 = 62h entendimento => 144h para a correção.

Ou seja, o tempo total de atuação 206h = 25 Dias

62h entendimento => 144h para a correção. Ou seja, o tempo total de atuação 206h =

seria

algo factível?!

62h entendimento => 144h para a correção. Ou seja, o tempo total de atuação 206h =

AVALIAR

MANUTENIBILIDADE

22

AVALIAR MANUTENIBILIDADE 22
AVALIAR MANUTENIBILIDADE 22

AVALIAR

DÉBITO TÉCNICO E JUROS

Débito Técnico = postegar a qualidade para um instante futuro; Juros = adequação de pontos onde serão corrigidos os débitos técnicos.

23

a qualidade para um instante futuro; Juros = adequação de pontos onde serão corrigidos os débitos
a qualidade para um instante futuro; Juros = adequação de pontos onde serão corrigidos os débitos

AVALIAR

DÉBITO TÉCNICO E JUROS

24

AVALIAR DÉBITO T É CNICO E JUROS 24
AVALIAR DÉBITO T É CNICO E JUROS 24
AVALIAR DÉBITO T É CNICO E JUROS 24

DIRECIONAR

25

ÍNDICE DE PRIORIZAÇÃO NA CORREÇÃO DE NÃO-CONFORMIDADES

DIRECIONAR 25 ÍNDICE DE PRIORIZAÇÃO NA CORREÇÃO DE NÃO- CONFORMIDADES
DIRECIONAR 25 ÍNDICE DE PRIORIZAÇÃO NA CORREÇÃO DE NÃO- CONFORMIDADES

DIRECIONAR

26

ÍNDICE DE PRIORIZAÇÃO NA CORREÇÃO DE NÃO-CONFORMIDADES

DIRECIONAR 26 ÍNDICE DE PRIORIZAÇÃO NA CORREÇÃO DE NÃO- CONFORMIDADES
DIRECIONAR 26 ÍNDICE DE PRIORIZAÇÃO NA CORREÇÃO DE NÃO- CONFORMIDADES

27

VERIFICAÇÕES

VERIFICAÇÕES

28

Neste item não foram executadas avaliações em laboratórios com alunos da Universidade, as avaliações foram executadas em projetos reais, dado que, existia a demanda por um cliente da consultoria exigindo uma forma de visualizar a qualidade dos seus projetos alinhado com os propósitos desta tese.

Sendo assim, a avaliação foi apresentada a um cliente real.

Em 13 de abril de 2018, apresentamos à banca de qualificação o trabalho proposto, com uma duração de 3 horas, evidenciamos os levantamentos feitos em projetos reais, e após os esclarecimentos de dúvidas e direcionamentos de melhorias feitos pelos membros da banca, a proposta foi aprovada por unanimidade.

de dúvidas e direcionamentos de melhorias feitos pelos membros da banca, a proposta foi aprovada por

VERIFICAÇÕES

29

Se constitui na apresentação da solução candidata na indústria, coletando os feedbacks dos participantes.

Neste sentido, tivemos por volta de 31 e-mails cotendo discussões sobre a solução, com representantes do segmento da industria de Telecom, 3 reuniões presenciais para a apresentação da proposta e coleta de feedbacks.

Do staff envolvidos nas discussões podemos considerar: 4 analistas de sistemas, 2 arquitetos, 1 gerente e 1 gerente senior.

staff envolvidos nas discussões podemos considerar: 4 analistas de sistemas, 2 arquitetos, 1 gerente e 1
staff envolvidos nas discussões podemos considerar: 4 analistas de sistemas, 2 arquitetos, 1 gerente e 1

VERIFICAÇÕES

VERIFICAÇÕES 30

30

VERIFICAÇÕES 30

31

TRABALHOS RELACIONADOS E CASES

CASES

ü CASOS PRÁTICOS

ü LPE – Mídia

32

ü Consumo e esforço na execução de atividades de manutenção

ü BLODES – Telecomunicações

ü Visão de qualidade considerando design e manuteniblidade

ü NPC – Financeiro

ü Situação do projeto legado (Onda-1) em termos de manutenibilidade

design e manuteniblidade ü NPC – Financeiro ü Situação do projeto legado (Onda-1) em termos de

TRABALHOS RELACIONADOS

33

TRABALHOS RELACIONADOS 33

TRABALHOS RELACIONADOS

Limitações encontradas

34

- A confiabilidade quanto ao custo e projeção de manutenção, dada a utilização de métricas de esforço como Use-Case Point, COCOMO, WMFP ou outra abordagem diferente de PF, dado que esta proposta se utiliza de Backfiring.

- Possibilidade na variação e simulação na substituição de métricas com a mesma abordagem, por exemplo: LCOM4 x TCC/LCC para análise de coesão ou McCabe x CK Metrics x Fan-In/Fan-Out para complexidade.

por exemplo: LCOM4 x TCC/LCC para análise de coesão ou McCabe x CK Metrics x Fan-In/Fan-Out

35

CONSIDERAÇÕES

CONSIDERAÇÕES

36

Dado que sistemas de software carecem de artefatos consistentes, e tomando por base somente o código-fonte dos projetos, investigar e entender o porquê das métricas de software coletadas não apresentarem um modelo onde, efetivamente, os resultados obtidos fornecem a visibilidade necessária para suportar decisões estratégicas;

Neste sentido, onde os entendimentos foram obtidos e descritos nos Capítulos 2 e 3, no qual os modelos identificados tratavam este objetivo de forma parcial ou seus formatos eram proprietários não permitindo uma abordagem direta com uso de métricas, mapeamentos entre níveis de qualidade e visão financeira.

não permitindo uma abordagem direta com uso de métricas, mapeamentos entre níveis de qualidade e visão

CONSIDERAÇÕES

37

Considerando as métricas de software obtidas e apresentadas em um nível executivo, entender e definir como os resultados obtidos poderiam ser apresentados de forma a subsidiar seguramente uma visão sobre a real situação do projeto, em forma de indicadores;

Seguramente o uso de indicadores e dashboards por si, se tornam

facilitadores do entendimento, porém, durante as atuações no dia a dia dos projetos, o grande desafio esteve em responder perguntas sobre:

Como está a qualidade

devemos começar as melhorias

?,

O que significam tais resultados

?

?

Por onde

Enfim, o que se buscou neste objetivo foi transmitir de forma clara, como os resultados obtidos a partir do código-fonte poderiam ser tornar de fácil entendimento para uma audiência em nível estratégico sem a necessidade de um tradutor, um suporte técnico.

de fácil entendimento para uma audiência em nível estratégico sem a necessidade de um tradutor, um
de fácil entendimento para uma audiência em nível estratégico sem a necessidade de um tradutor, um

CONSIDERAÇÕES

38

Entendendo os indicadores recebidos quanto à saúde de um projeto, direcionar um modelo de avaliação e predição de impactos nos custos de forma a subsidiar a tomada de decisão.

Este objetivo se tornou importante devido à questão financeira, pois, é bastante comum que em tomadas de decisão se considere o fator custo e quais as ações pertinentes para o controle do orçamento.

Deste modo, esta tese apresentou uma visão de projeção de custos por um período de 10 anos, baseando-se em fatores descritos na Seção

4.3.2.

uma visão de projeção de custos por um período de 10 anos, baseando-se em fatores descritos
uma visão de projeção de custos por um período de 10 anos, baseando-se em fatores descritos

CONSIDERAÇÕES

39

Estabelecer uma abordagem para o monitoramento dos projetos de forma contínua, sendo possível direcionar ações com base em indicadores, projeções de custos, classificação e melhoria contínua em partes do sistema.

Para este item, foi elaborado um índice de priorização conforme a Seção 4.4.1 onde o que se procurou atender foi como se iniciar um trabalho corretivo com resultados vísiveis a curto prazo, dado que, as atividades de construção continuam existindo em paralelo.

Neste sentido, é comum que trabalhos de refatoramento não se reflitam de forma imediata caso as classes envolvidas não estejam relacionadas às demandas correntes, o que de certo modo, gera dúvidas se a tomada de decisão de correção e melhorias de fato foi efetiva.

correntes, o que de certo modo, gera dúvidas se a tomada de decisão de correção e
correntes, o que de certo modo, gera dúvidas se a tomada de decisão de correção e

40

Dúvidas?

Muito obrigado… J