Prof. Doutor

Rogério Patrício Chagas do Nascimento

Professor Associado do Departamento de Computação (DCOMP)/UFS

Assessor do Reitor para Cidades Inteligentes, Diretor Científico da EATIS.org

rogerio@ufs.br

GpESGrupo de Pesquisa em Engenharia de Software

Gestão de Projetos de SW OO:Métricas, Estimações e Planejamentos

Practice 4

2

Sumário

▪ Gestão de Projetos de SW OO– Processos de SW OO

▪ já vimos o Modelo Recursivo-Paralelo

▪ veremos técnicas e heurísticas de uso na próxima aula teórica.

– Métricas e Estimação/Planejamento para Projetos de SW OO

▪ na literatura..

▪ para a Lacertae Software

▪ Estimação e Planejamento em Geral▪ observações finais

▪ opções

▪ exemplos de Modelos Empíricos

3

Gestão de Projeto de SW OO

– determinar quanto dinheiro,

– esforço,

– recursos e

– tempo requer a construção de um Produto de SW OO

▪ Quem faz?– Gestores de Projetos de SW

– Engenheiros de SW (Analistas e Arquitetos)

▪ compilam as medidas

▪ auxiliam nas medições

4

Métricas OO na Literatura..

▪ definem e quantidade de um conjunto padrão de elementos de UML, nomeadamente:– use cases

– classes

– subsistemas

– componentes

– interfaces

– páginas Web

– scripts

são medidas (ou classificadores) que usamos para medir o

esforço requerido ao desenvolvimento do Produto de SW

5

Tipos de Métricas OO- Encontradas na Literatura

▪ Métricas para o Modelo de Desenho OO

▪ Métricas Orientadas a Classes– métricas de Lorenz & Kidd– métricas de CK (Chidamber & Kemerer)

▪ Métodos ponderados por Classe▪ Árvore de profundidade de Herança▪ Número de Descendentes▪ Acoplamento entre Classes▪ Respostas para uma Classe▪ Carência de Coesão do Métodos

– MDOO – Métricas para o Desenho OO▪ Fator de Herança de Métodos▪ Fator de Acoplamento▪ Fator de Polimorfismo

▪ Métricas orientadas a operações, métodos ou serviços

▪ Métricas para Testes OO

6

Métricas de Lorenz & Kidd- Adotadas pela Lacertae SW

▪ número de classes-chave– é uma indicação do esforço necessário para desenvolver o SW

– … e da quantidade (potencial) de classes reutilizáveis

▪ durante o desenvolvimento do sistema

Também chamadas de “Componentes Altamente Independentes”

7

Métricas de Lorenz & Kidd- Adotadas pela Lacertae SW

▪ número de classes de suporte– não fazem parte do domínio do problema

▪ mas são necessárias para implementá-lo

– exemplos:

▪ Interfaces Gráficas dos Usuários (GUI)

– janelas, botões, caixas de diálogos, etc.

▪ Acesso às bases de dados e sua manipulação

▪ Acesso a outros programas ou aplicações legadas

Estas classes são definidas interativamente durante o

Processo Recursivo-Paralelo

8

Métricas de Lorenz & Kidd- Adotadas pela Lacertae SW

▪ número de subsistemas– facilita um planejamento razoável na divisão do trabalho entre os

membros da equipe de desenvolvimento

Consiste numa agregação de Classes que dão suporte a

uma função visível ao usuário final do Sistema

9

Métricas de Lorenz & Kidd- Adotadas pela Lacertae SW

▪ número de cenários

(ou casos de utilização)– a quantidade de cenários

está diretamente relacionada ao tamanho da aplicação

– podem ser gerados automaticamente a partir de uma ferramenta CASE

será a quantidade de testes que devem ser realizados

quando o sistema estiver pronto

Iniciador Ação Participante

<objecto

que

solicita

o

serviço

>

<resultado

da

solicitaçã

o>

<objecto servidor

que cumpre a

petição>

…

…

10

Estimações e Planificações OOde Lorenz & Kidd - Adotadas pela Lacertae SW

▪ primeiros passos para esta Estimação OO:

– decomposição de esforços usando

▪ Classes-chave

▪ Classes de Suporte

– determinar a quantidade de classes-chave

A Estimação é mais uma arte do que uma ciência –

o que não exclui o uso de um enfoque sistemático!

11

Estimações e Planejamentos OOde Lorenz & Kidd - Adotadas pela Lacertae SW

▪ classificar o tipo de Interface do Produto e desenvolver um Multiplicador para as Classes de Suporte– multiplicar a quantidade de classes-

chave pelo Multiplicador para obter umaestimação do número de classes de suporte

Interface Multiplicador

não

gráfica

2

baseada

em texto

2,25

GUI 2,5

GUI

complexa

3,0

12

Estimações e Planejamentos OOde Lorenz & Kidd - Adotadas pela Lacertae SW

– multiplicar a quantidade total de Classes (classes-chave + classes de suporte) pelo“número médio de unidades de trabalho(dias-pessoa) por classe”

▪ Lorenz & Kidd sugere entre 15 e 20 dias-pessoa por classe

– determinar a quantidade de esforço estimada

exemplo

:: se modelarmos 10 classes-chave

:: e utilizarmos GUI, então teremos 25 classes de suporte

:: 35 classes * 20 dias-pessoa (máximo) = 750 dias-pessoa

13

Estimação em Geral- Observações

▪ Estimação requer – Experiência– Boa informação histórica– Coragem para confiar em prognósticos

▪ Riscos inerentes– Complexidade do projeto– Tamanho do projeto– Grau de definição dos requisitos– Maturidade do Processo de Software

▪ Agregação de projetos por– Tamanho de equipe– Área de aplicação– Complexidade

14

Estimação do Projeto de SW- Opções

▪ Má ideia deixar a estimação para depois

▪ Deve-se basear as estimações em projetos similares já terminados

▪ Algumas ferramentas automáticas podem ser muito úteis

▪ Utilizar técnicas de decomposição para gerar estimativas de custo e esforço

▪ Utilizar modelos empíricos

15

Estimação do Projeto de SW- Exemplos de Modelos Empíricos

▪ COCOMO (1981) e COCOMO II (1996)

▪ Modelo de Walston-Felix E=5.2 x KLDC 0.91

▪ Análise de regressão E = A + B x (ev) c

▪ Modelo de Matson, Barnett e Mellichamp

– E = 585,7 + 15,12 PF

▪ Métricas de línea base = [LDC/pontos de função]/pessoa-mês

▪ Métricas de línea base x variáveis de estimação = projeções de custo e esforço

▪ VE= (Sopt+4Sm + Spess)/6 Lorenz & Kidd: Métricas de SW OO orientadas a

Classes que usaremos para a Lacertae SW

próximas aulas teóricas

17

Ferramentas CASE

– Noções teórico-práticas..

Processos de SW OO

– quando concluir as iterações AOO, DOO e Testes OO..

Bons caminhos!

Obrigado pela atenção! Thanks for listening! Merci pour votre attention!

rogerio@dcomp.ufs.br

@Patricium