Engenharia de Software II
Aula 19
Ementa
• Processos de desenvolvimento de software • Estratégias e técnicas de teste de software • Métricas para software
• Gestão de projetos de software
– Conceitos (Cap. 21) – Métricas (Cap. 22) – Estimativas – Cronogramação – Gestão de risco – Gestão de qualidade – Gestão de modificações
Gestão de Projetos
• A construção de software é um empreendimento
complexo.
– Frequentemente, envolve muitas pessoas trabalhando durante um período longo de tempo.
• Por isso, é necessário gerir o projeto de software.
– Planejar, monitorar e controlar o pessoal, o processo e eventos que ocorrem à medida que o software evolui de um
• A gestão efetiva de projetos focaliza quatro fatores:
– Pessoal – Produto
– Processo – Projeto
Processo
• O gerente de projeto deve decidir qual
modelo
de processo
é mais apropriado considerando:
– O cliente que solicitou o produto
– O pessoal que executará o trabalho – As características do produto
– O ambiente de projeto no qual a equipe trabalha
• Selecionado o modelo de processo, a equipe
define um plano preliminar de projeto.
• Uma vez estabelecido o plano preliminar, a
decomposição do processo tem início.
– As tarefas de trabalho são definidas para cada atividade de arcabouço.
Fusão do Produto e do Processo
• O planejamento do projeto tem início com a
fusão do produto e do processo.
– Cada função a ser trabalhada pela equipe deve
passar pelo conjunto de atividades de arcabouço que foi definido.
• É criada uma matriz cujas linhas são as funções
e as colunas são as atividades de arcabouço.
– O gerente preenche a matriz com as tarefas de
trabalho e as datas de começo e fim estimadas para cada tarefa.
Exemplo
Produção de documento Gestão de arquivo Capacidade de lay-out de página Edição automática de cópia Edição e Formatação Texto de Entrada Implantação Construção Modelagem Planejamento ComunicaçãoExemplo de decomposição da
atividade de comunicação
• Tarefas de trabalho:
1. Rever a solicitação do cliente.
2. Planejar e marcar um encontro formal com o cliente. 3. Fazer pesquisa para especificar a solução proposta e
abordagens existentes.
4. Preparar uma agenda formal para a reunião. 5. Conduzir a reunião.
6. Desenvolver, em conjunto, casos de uso que descrevam o software do ponto de vista do usuário.
7. Rever cada caso de uso quanto à correção, consistência e ausência de ambiguidade.
8. Rever a coleção de caso de uso com todos os interessados. 9. Modificar os casos de uso na medida do necessário.
Projeto
• Dez sinais que indicam que um projeto de software está comprometido:
1. A equipe não entende as necessidades do cliente. 2. O escopo do produto está mal-definido.
3. As modificações são mal-gerenciadas.
4. A tecnologia escolhida sofre modificações.
5. As necessidades do negócio modificam-se ou foram mal definidas.
6. Os prazos são irreais.
7. Os usuários são resistentes.
8. O patrocínio é perdido ou nunca foi obtido.
9. A equipe de projeto não tem pessoal qualificado.
Projeto
• Regra 90-90
– Os primeiros 90% de um sistema absorvem 90% do esforço e do prazo.
– Os últimos 10% gastam os outros 90% do esforço e prazo alocados.
• Como um gerente evita esses problemas?
– Comece com o pé direito.
– Mantenha a energia de momento. – Acompanhe o progresso.
– Tome decisões adequadas. – Faça uma análise a posteriori.
Ementa
• Processos de desenvolvimento de software • Estratégias e técnicas de teste de software • Métricas para software
• Gestão de projetos de software
– Conceitos (Cap. 21) – Métricas (Cap. 22) – Estimativas – Cronogramação – Gestão de risco – Gestão de qualidade – Gestão de modificações
Métricas de Processo e Projeto
• A medição pode ser aplicada:
– Ao processo de software com o objetivo de melhorá-lo de forma contínua.
– Ao longo do projeto para auxiliar na estimativa, no controle de qualidade, na avaliação de produtividade e no controle do projeto.
– Para avaliar a qualidade dos produtos de trabalho (cap. 15).
• A medição é uma ferramenta de gestão.
– Se conduzida adequadamente, fornece conhecimento a um gerente de projeto.
– Como resultado, apóia o gerente na tomada de decisões que levará ao sucesso.
Métricas de processo vs.
Métricas de projeto
• Métricas de Processo
– São coletadas no decorrer de todos os projetos e durante longos períodos. – Sua intenção é melhorar o processo de software em si. – Contribuem para o desenvolvimento de métricas de projeto.• Métricas de Projeto
– Permitem ao gerente de software: • Avaliar o estado do projeto. • Acompanhar riscos potenciais. • Descobrir áreas-problemas. • Ajustar o fluxo de trabalho ou tarefas. • Avaliar a capacidade da equipe.Exemplos de
Métricas de Processo
• Medidas dos erros descobertos antes da
entrega do software.
• Defeitos entregues aos usuários finais e
por eles relatados.
• Produtos de trabalho entregues
(produtividade).
• Esforço humano despendido.
• Tempo gasto.
Métricas públicas e privadas
• Os dados coletados com base individual devem
ser privados e servir com indicador apenas para
o indivíduo.
– Servem para ajudar o engenheiro de software a aperfeiçoar seu trabalho individual.
– Algumas métricas são privadas de uma determinada equipe.
– Ex.: Proporção de defeitos por indivíduo.
• Métricas públicas geramente assimilam
Métricas de Projeto
• A primeira aplicação de métricas de projeto ocorre durante a estimativa.
– Métricas coletadas de projetos anteriores são usadas como base, a partir da qual estimativas de esforço e de tempo são feitas.
• Conforme o projeto prossegue, medidas de esforço e de tempo são feitas para o trabalho atual.
– As medidas são comparadas com as estimativas .
• Quando o trabalho técnico inicia-se outras métricas tornam-se importantes.
– Taxa de produção = número de modelos criados – Horas de revisão
– Pontos por função
Objetivo das Métricas de Projeto
• O objetivo das métricas de projeto é
duplo:
– Minimizar o cronograma de desenvolvimento,
fazendo os ajustes necessários para evitar
atrasos, problemas e riscos em potencial.
– Avaliar a qualidade do produto durante sua
evolução e, quando necessário, modificar a
abordagem técnica.
Medição de Software
• Vimos que a medição de software pode
ser categorizada de dois modos:
– Medidas diretas
• Custo e esforço aplicados • Linhas de código
• Velocidade de execução
• Defeitos relatados durante um certo período
– Medidas indiretas
• Funcionalidade, qualidade, complexidade, eficiência, confiabilidade, etc.
Comparação de métricas
• As métricas precisam ser normalizadas para ser comparadas:
– Se a equipe A encontrou 342 erros antes da entrega e a equipe B encontrou 184 erros, qual das equipes é mais eficiente na descoberta de erros?
• Opções para normalização:
– Tamanho = Métrica LOC ou KLOC
• Vantagem: fácil de ser calculada
• Desvantagens: dependentes de linguagem de programação, penalizam programas curtos e bem projetados, difícil de ser estimado.
– Função = Métrica Pontos por Função
• Vantagem: independente da linguagem de programação, pode ser calculada no início do projeto.
• Desvantagem: cálculo baseado em dados subjetivos, difícil de coletar informação necessária.
LOC vs. Ponto por Função
• Uma LOC de C++ fornece
aproximadamente 2,4 vezes mais
funcionalidade que uma LOC de C.
• Uma LOC de Smalltalk fornece 4 vezes
mais funcionalidade que uma LOC de
Ada, COBOL ou C.
• É possível estimar pontos por função
usando uma tabela com dados para cada
linguagem.
Outras possíveis
métricas para normalização
• Métricas orientadas a objeto
– Número de scripts de cenário – Número de classes-chave
– Número de classes de apoio
• Métricas orientadas a caso de uso
– Número de casos de uso
• Métricas de projeto de engenharia da web
– Número de páginas estáticas – Número de páginas dinâmicas – Número de links internos
