Capítulo 3 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger...

Engenharia de Software: Teoria e PráticaShari Lawrence Pfleeger Capítulo 3 Prentice Hall

Acompanhamento do progresso de projetos Você entende meu problema e minhas

necessidades? Você pode projetar um sistema que resolverá meu

problema ou satisfará minhas necessidades? Quanto tempo você levará para desenvolver meu

sistema? Quanto irá custar o desenvolvimento desse

sistema?


Cronograma de projetos

Documentos Demonstrações de funções Demonstrações de subsistemas Demonstrações de precisão Demonstrações de confiabilidade, segurança

ou desempenho


Marco e atividades Atividade: parte do projeto que acontece ao

longo de determinado período Marco: finalização de uma atividade — a

momento específico no tempo Precursor: evento ou conjunto de eventos que

deve ocorrer antes de a atividade começar Duração: tempo necessário para completar a

atividade Data prevista: aquela na qual a atividade deve

estar concluída


Tempo de folga ou tempo livre

Tempo de folga = tempo disponível – tempo real = tempo mais tardio para começar – tempo mais antecipado para começar


Pessoal necessário para o projeto Principais atividades de um projeto:

análise de requisitos projeto do sistema projeto do programa implementação do programa teste treinamento manutenção garantia da qualidade


Escolhendo o pessoal Capacidade para desempenhar o trabalho Interesse no trabalho Experiência com

aplicações semelhantes ferramentas ou linguagens semelhantes técnicas semelhantes ambiente de desenvolvimento semelhante

Treinamento Capacidade para se comunicar com outras pessoas Capacidade para compartilhar responsabilidades Habilidades de gerenciamento


Estilos de trabalho

Extrovertidos: tendem a afirmar suas idéias Introvertidos: pedem sugestões Intuitivos: baseiam suas decisões nos

sentimentos Racionais: baseiam suas decisões em fatos


Organização do projeto

Depende da experiência e do estilo de trabalho dos membros da

equipe do número de pessoas na equipe dos estilos de gerenciamento dos clientes e

desenvolvedores Exemplos:

programador-chefe da equipe Abordagem “sem influência do ego”


Estimativa de esforço Julgamento de especialista

analogias proporção técnica de Delphi modelo de Wolverton

Métodos algorítmicos: E = (a + bSc) m(X) modelo de Walston e Felix: E = 5.25S 0.91

modelo de Bailey e Basili: E = 5.5 + 0.73S1.16


Técnica Bailey-Basili• Minimiza a estimativa de erro padrão para produzir uma equação como:

E = 5.5 + 0.73S1.16

• Ajuste inicial da estimativa com base na razão de erros.

Se R for a razão entre o esforço real, E, e o esforço previsto, E’, então o ajuste do esforço é definido como

ERadj = R – 1 if R > 1

= 1 – 1/R if R < 1

• Assim, a estimativa de esforço inicial E foi ajustada desse maneira:

Eadj = (1 + ERadj)E if R > 1

= E/(1 + ERadj) if R < 1


Modelo COCOMO: Estágios de desenvolvimento Composição da aplicação: prototipagem para resolver questões de alto risco envolvendo

interface com os usuários estimativa de tamanho a partir de pontos de aplicação

Projeto inicial: explorar arquiteturas e conceitos de operação alternativos estimativa de tamanho a partir de pontos de função

Fase posterior à arquitetura: desenvolvimento já começou estimativa de tamanho a partir de linhas de código


Métodos de aprendizado automático Exemplo: raciocínio baseado em casos

usuário identifica um novo problema como um caso sistema obtém casos semelhantes a partir de um

repositório de informações históricas sistema reutiliza o conhecimento de casos anteriores sistema sugere uma solução para o novo caso

Exemplo: redes neurais Utiliza dados de projetos anteriores


Modelo de esforço

Magnitude Média de Erros Relativos (MMER) Valor absoluto

[(real - estimado)/real] objetivo: deve ser 0,25 ou menos

Pred(x/100): porcentagem de projetos para os quais a estimativa está dentro de x% do valor real objetivo: deve ser 0,75 ou maior que x = 0,25


Gerenciamento de riscos

Impacto do risco: perda associada de um evento Probabilidade do risco: a probabilidade de o evento

ocorrer Controle do risco: grau em que podemos mudar o

resultado

Exposição ao risco = (probabilidade do risco) x (impacto do risco)


Três estratégias para redução de riscos Evitar o risco: modificar os requisitos quanto ao

desempenho ou à funcionalidade Transferir o risco: transferir o risco a outros

sistemas ou realizar um contato seguro Assumir o risco: aceitar o risco e controlá-lo

influência da redução do risco = exposição ao risco antes da redução – exposição ao risco depois da redução : pelo custo da redução do risco


Dez principais itens de risco segundo Boehm

Pessoal insuficiente Cronogramas e orçamentos não realistas Desenvolvimento das funções de softwares erradas Desenvolvimento de uma interface com o usuário

inadequada Simplificação dos requisitos Fluxo contínuo de modificações nos requisitos Insuficiência nas tarefas realizadas externamente Insuficiência nos componentes fornecidos externamente Insuficiência no desempenho em tempo real Exceder a capacidade da ciência da computação


Conteúdo do plano de projeto

Escopo do projeto Cronograma do projeto Organização da equipe do

projeto Descrição técnica do sistema Padrões, procedimentos,

técnicas e ferramentas do projeto

Plano de garantia da qualidade Plano de gerência de

configuração

Plano de documentação Plano de gerência de

dados Plano de gerência de

recursos Plano de testes Plano de treinamento Plano de segurança Plano de gerência de

riscos Plano de manutenção


Alpha AXP, da Digital: Modelo de gerenciamento de inscrição Estabelecimento de visão compartilhada

apropriadamente ampla Delegação completa e obtenção de

comprometimentos específicos dos participantes Inspeção rígida e fornecimento de feedback de

apoio Reconhecimento de todo o avanço e aprendizado

com o processo do programa


Lockheed Martin: Modelando a responsabilidade Organização em matriz

cada engenheiro pertencia a uma unidade funcional com base em um tipo de habilidade

Desenvolvimento integrado de produto combina indivíduos de diferentes grupos funcionais

dentro de uma unidade de trabalho interdisciplinar com canais de responsabilidade separados

Cada atividade acompanhada utilizava estimação de custos, análise do caminho crítico ou acompanhamento do cronograma valor ganho era utilizado como medida comum para

comparar o progresso


Estabelecendo marcos Objetivos: Por que o sistema está sendo desenvolvido? Marcos e cronogramas: O que deve ser feito e quando? Responsabilidades: Quem é responsável por uma

função? Abordagem: Como o trabalho será tecnicamente

realizado e em termos de gerenciamento? Recursos: Quanto de cada recurso é necessário? Viabilidade: Isso pode ser realizado e será que existe

uma boa razão para isso em termos de negócios?

Capítulo 3 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger...

Documents

Transcript of Capítulo 3 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger...