Planejamento/Gerenciamento Alexandre Mota (acm@cin.ufpe.br)

Planejamento/Gerenciamento

Alexandre Mota (acm@cin.ufpe.br)

Tempo de Desenvolvimento A partir da rede de atividades

Grafo interligando tarefas com tempo Determinar o caminho crítico

O caminho que leva mais tempo para concluir

Gerente deve dar especial atenção às tarefas contidas no caminho crítico

É crucial ter folgas no caminho crítico

Identificação de RiscosRisco Probabilida

deEfeitos

Pessoal doente Moderada Sério

Tamanho do software desconhecido

Alta Tolerável

... … …

Pessoal qualificado não disponível

Alta Catastrófico

Estratégias de Gerenciamento

Risco Estratégia

Pessoal doente

Reorganizar equipe para ter sobreposição de pessoas/trabalho

Recrutamento

Alertar cliente sobre possível atraso

… …

Mudança nos requisitos

Analisar rastreamento entre requisitos para determinar impacto

Sumário de Gerenciamento Manter informação sempre

atualizada Principalmente tempo e riscos

Colocar pessoas ociosas para revisar trabalho de pessoas ativas (extreme programming) – Qualidade

Avaliar trabalho futuro HOJE Estar sempre com o plano em mãos

Por que Mensurar? Indicar a qualidade do produto Avaliar produtividade Formar base para estimativas Determinar benefícios derivados de

novos métodos e ferramentas da ES Justificar aquisição de ferramentas e

treinamento

Utilização de Métricas

Projeto Esforço $ KLOC Págs.docum. Erros Pessoas

projA-01 24 168 12.1 365 29 3

projB-04 62 440 27.2 1224 86 5

projC-03 43 314 20.2 1050 64 6

MÉTRICAS DERIVADAS

PRODUTIVIDADE =

QUALIDADE =

CUSTO =

DOCUMENTAÇÃO =

KLOC / Pessoas-mês

Erros / KLOC

$ / LOC

Págs.docum. / KLOC

Métricas de Software

Método de Wideband-Delphi

Método de Lógica-Fuzzy

Pontos por Função

COCOMO

Wideband-Delphi Originado pela Rand Corporation e

refinado por Boehm Consiste em obter consenso a

partir de estimativas individuais As estimativas são geradas após

reuniões entre os desenvolvedores O consenso se dá através de

discussões em grupo sobre as estimativas individuais (anônimas)

Wideband-Delphi O procedimento é:

1. Grupo de especialistas recebe especificações e formulário de estimativa

2. Há uma reunião para discutir objetivos, limitações e características do projeto

3. Daí, anonimamente, cada um lista as tarefas e suas estimativas

4. Estimativas são agrupadas por um moderador e apresentadas ao grupo

5. Só a estimativa do especialista é marcada no formulário. As outras ficam iguais.

Wideband-Delphi O procedimento é:

6. Há outra reunião para discutir resultados. Cada especialista revê sua lista de tarefas mas não as estimativas

7. Este processo volta ao passo 3 Até que as estimativas estejam próximas o suficiente

Wideband-DelphiProjeto: Extensão do RoseEstimador: AlexandreData: 01/03/2003Aqui está o limite das estimativas da 1a rodada

0 20 40 60 80 100

X X* X! X X

X – estimativasX* - sua estimativaX! – estimativa mediana

Método de Lógica-Fuzzy Estimativa é baseada em dados

históricos Sistemas são divididos em

categorias de tamanhos A escala de tamanhos é dada por

logaritmos e ajustadas Divisão vai até ponto onde sistema

atual pode ser encaixado em alguma categoria

Exemplo de Lógica-Fuzzy Suponha que seu menor programa

tenha 173 LOC e o maior 10341 E deseja-se dividir essa região em

5 categorias Calculam-se, log 173=2.238 e

log 10341=4.014 E dividem-se (4014 – 2238) por 4

para obter o incremento (0.444)

Exemplo de Lógica-Fuzzy

Categoria LOC

Muito pequeno 173

Pequeno 481

Médio 1338

Grande 3719

Muito grande 10341

Método de Lógica-Fuzzy Considerações Importantes:

Ter dados históricos sobre um grande número de projetos para ter como comparar com as várias categorias

Deve-se atualizar as categorias tão logo haja dados suficientes

As categorias também devem ser ajustadas de acordo com os projetos futuros esperados

Modelos de ciclo de vida Construa e Conserte (Code-and-Fix,

Build-and-Fix) Cascata (“Waterfall”)

Cascata Modificado Prototipação Espiral Formal Baseado em reuso

Construa e Conserte

ConstruaVersão 1

Modifique atécliente estarsatisfeito

Fase demanutenção

Desvantagens Sem especificação Sem projeto Não gerencia riscos

Vantagens Baixa sobrecarga de

desenvolvimento Não precisa de

especialização Para sistemas muito

pequenos

Modelo Cascata

Definição deRequisitos

Projeto doSistema

ImplementaçãoE testes

Integração eTestes

Operação emanutenção

Características do Modelo Cascata Desvantagens

Partição inflexível do projeto em estágios distintos

Dificuldade para lidar com as mudanças nos requisitos do sistema

Não gerencia riscos Vantagens

Orientado a documentação Manutenção é mais simples

Características do Modelo Cascata* Desvantagens

Milestones podem tornar-se ambíguos Atividades em paralelo podem levar a

problema de comunicação, suposições errôneas e ineficiência

Vantagens Atividades podem ser sobrepostas Mais fácil de lidar com mudanças nos

requisitos Capacidade para gerenciar riscos

Processo Evolucionário Desenvolvimento exploratório (Protótipo

evolucionário) Construa, avalie e evolua para produto

Trabalhar com os clientes até se obter o produto final a partir de uma especificação bem-definida e completa do sistema.

Protótipo descartável Construa, use e descarte

Obter requisitos do cliente. Inicia-se com uma especificação incompleta e simples do sistema

Processo EvolucionárioAtividades

concorrentes

Especificação

Desenvolvimento

Validação

Versãoinicial

Versãofinal

Versõesintermediárias

Descriçãosuperficial

Perspectivas Desvantagens

Falta de visibilidade do processo Sistemas são geralmente mal estruturados Conhecimentos específicos (ling. de prot.

rápida) podem ser necessários Aplicações

Sistemas interativos de pequeno e médio porte

Partes de sistemas grandes (interface com usuário)

Sistemas com vida útil curta

Processo Formal Transformação de uma

especificação formal em um programa executável

Pode ser empregado de duas formas: Através de um cálculo de

refinamentos Implementação é derivada por

construção, garantindo corretude Através de passos de refinamento

Versão mais concreta do sistema é proposta e depois deve-se verificá-la em relação a anterior

Processo Formal

Definição derequisitos

Especificaçãoformal

Transformaçãoformal

Integração etestes

Perpectivas Desvantagens

Necessita de profissionais altamente qualificados para aplicar a técnica

Alguns aspectos ainda são difíceis de especificar (GUI)

Vantagens Garantia de segurança e confiabilidade

Aplicações Sistemas críticos e complexos

Processo baseado em Reuso Baseado no reuso sistemático de

componentes existentes na própria empresa ou no mercado

Estágios do processo Análise dos componentes Modificação dos requisitos Projeto do sistema com reuso Desenvolvimento e integração Validação

Essa abordagem está se tornando cada vez mais importante, mas ainda faltam casos experimentais bem-sucedidos

Processo baseado em Reuso

EspecificaçãoDe requisitos

Análise decomponentes

ModificaçãoDe requisitos

Projeto comreuso

Desenvolv. Eintegração

Validação doSistema

Processo Iterativo Os requisitos do sistema SEMPRE

mudam durante o desenvolvimento

Iteração pode ser aplicado a qualquer um dos processos de desenvolvimento

Duas abordagens são destacadas: Desenvolvimento incremental Desenvolvimento em espiral

Desenvolvimento Incremental Ao invés de entregar o sistema

completo, divide-se o sistema em partes de tal forma a cada entrega corresponder a alguma funcionalidade do sistema

Requisitos do usuário são priorizados e os quanto maior a prioridade mais cedo tal funcionalidade deve ser entregue

Uma vez que o desenvolvimento de um incremento seja iniciado, esses requisitos são fixados enquanto que os posteriores são deixados serem modificados

Desenvolvimento Incremental

Desenvolv.incremento

Validaçãoincremento

Integraçãoincremento

Validação dosistema

Requisitossuperficiais

Requisitos emincrementos

Projeto daarquitetura

Sistema incompleto

Sistemacompleto

Vantagens Solicitações dos clientes são entregues

a cada incremento. Assim, as funcionalidades são entregues o mais cedo possível

Incrementos iniciais servem de protótipo para obter requisitos para incrementos posteriores

Diminuição do risco de falha de todo o projeto

Serviços de maior prioridade tendem a receber maior ênfase em testes

Modelo Espiral Forma Simplificada

Modelo cascata mais análise de riscos Precede cada fase por

Alternativas Análise de riscos

Procede cada fase por Avaliação Planejamento da fase seguinte

Modelo Espiral Simplificado

Se os riscos não podem ser resolvidos, projeto é terminado imediatamente

Modelo Espiral Completo Dimensão Radial

Custo acumulado atualizado Dimensão Angular

Progresso através da espiral

Modelo Espiral Completo

Características do Modelo Espiral Desvantagens

Bem aplicado somente a sistemas de larga escala

Sistemas devem ser produtos internos da empresa

Vantagens Fácil de decidir o quanto testar Não faz distinção entre desenvolvimento

e manutenção

Bibliografia Leitura adicional

Software Engineering. I.Sommerville A Discipline for Software Engineering.

W.S.Humphrey