Projectos de Software Patrícia Macedo Engenharia de Software 2005/2006 EST, Setúbal Gestão de Projecto Engenharia de Software 2 1
Estrutura de Conceitos Engenharia de Software 3 Estruturas das Equipas Descentralizado democrático Descentralizado controlado Centralizado controlado A estrutura adoptada deve depender: Da dificuldade do problema Tamanho do software a desenvolver Tamanho da equipa necessária Modularidade do problema Qualidade e fiabilidade requeridas Rigidez na data de entrega Grau de sociabilização requerido Engenharia de Software 4 2
Problemas na gestão de equipas Ambiente de trabalho frenetico Frustação individual ou colectiva Má coordenação de procedimentos Má definição das funções de cada membro da equipa Definição pobre ou inadequada do modelo de processos Engenharia de Software 5 Selecção e coordenação do processo A selecção do processo e da metodologia deve ter em conta: Experiência da equipa com os vários processos de desenvolvimento O tipo de produto requerido Planeamento do produto e do processo Definição de actividades básicas Estimação de recursos para cada actividade e por função Detalhe das actividades básicas Engenharia de Software 6 3
Métricas do projecto As métrica do projectos servem para: Planear o desenvolvimento Avaliar a qualidade dos produtos. os indicadores registados em projectos anteriores servem de guia para prever o esforço, o tempo e o custo de novos projectos. Engenharia de Software 7 Medida, Métrica e Indicadores Medida Valor quantitativo da extensão, quantidade, dimensão, capacidade ou tamanho de algum atributo. Medição Acto de determinar uma medida Métrica- Medida quantitativa para do grau de posse de um atributo de um produto ou de um processo. Indicador métrica ou conjunto de métricas que proporcionam uma visão aprofundada do processo de software, do projecto ou do próprio software. Engenharia de Software 8 4
Propriedades que deve ter uma Métrica Uma "boa" métrica deverá auxiliar no desenvolvimento de modelos capazes de estimar os parâmetros de um processo ou produto e não apenas descrevê-los. Para tal deverá ter as seguintes características: Mensurabilidade, para o que deve ter uma definição inequívoca, por forma a ser claro como é determinada; Repetibilidade, isto é, tomar o mesmo valor, mesmo quando calculada por pessoas diferentes, ou em instantes distintos; Baixo custo, para o que deve ser fácil e rápida de obter (de preferência de uma forma automática); Validade, ou seja, permitir medir, com objectividade, aquilo para que foi proposta; Robustez, isto é, não ser muito sensível a variações não significativas do processo ou produto. Engenharia de Software 9 Medidas, métricas e Indicadores Engenharia de Software 10 5
Indicadores de processo e de projecto Indicadores de processo permitem: avaliar o modelo de processo, as tarefas e produtos de trabalho. São recolhidos a partir de todos os projectos durante algum tempo. Indicadores de projecto permitem: Avaliar o estado do projecto Monitorizar os riscos potenciais Detectar áreas problemas Ajustar fluxos e tarefas Avaliar o controlo de qualidade da equipa de trabalho Engenharia de Software 11 Indicadores do processo A eficacia do processo pode ser determinada em função dos seguintes indicadores: Nº de erros encontrados Quantidade de esforço dispendido Nº de erros informados encontrados pelos utilizadores Tempo do projecto Engenharia de Software 12 6
Métricas do projecto As métrica do projectos servem para: Planear o desenvolvimento Avaliar a qualidade dos produtos. os indicadores registados em projectos anteriores servem de guia para prever o esforço, o tempo e o custo de novos projectos. Engenharia de Software 13 Métricas do projecto Métricas sobre as pessoas envolvidas Produtividade individual Produtividade da equipa Fiabilidade da equipa Fiabilidade individual Métricas sobre a medição do progresso do projecto Valor ganho Variação ao Planeado Variação do custo Engenharia de Software 14 7
Métricas do produto de software Métricas qualidade usabilidade, desempenho, adaptabilidade, portabilidade dimensão complexidade funções Engenharia de Software 15 Métricas de dimensão 1. Linhas de código LOC lines of code KLOC milhares de linhas de código Erros por KLOC Defeitos por KLOC Custo por KLDC 2. Número de componentes 3. Número de módulos Engenharia de Software 16 8
Métricas de complexidade Métrica de complexidade: forma utilizada para prever informação crítica acerca de fiabilidade e manutibilidade dos sistemas de software através da análise automática de informação procedimental de desenho [McCabe] Baseiam-se fundamentalmente no código fonte Decorrem principalmente nas fases de teste e manutenção Engenharia de Software 17 Métricas de software- complexidade Métrica de Halstead Estima o esforço empregue na programação. Ela baseia-se em medidas objectivas de código, e está relacionada com a teoria da informação, possuindo as seguintes qualidades mensuráveis, definidas para um dado programa codificado em qualquer linguagem de programação: n1, número de operadores únicos e distintos que aparecem no código n2, número de operandos únicos e distintos que aparecem no código N1, número total de ocorrências de operadores no código N2, número total de ocorrências de operandos no código; Número ciclomático de McCabe A métrica de complexidade de McCabe C está baseada no grafo de controlo de fluxo, e é definida por C=e-n+2.p, sendo e o número de ligações (também conhecidas como edges), n o número de nós e p é o número de componentes ligados do grafo. Engenharia de Software 18 9
Métricas orientadas à função Mede-se: Nº de entradas Nº de saídas Nº de Consultas Nº de ficheiros Nº de interfaces Engenharia de Software 19 Métricas de OO ObjectMetrix - Definem e conta um conjunto normalizados de elementos de UML, nomeadamente Use cases Classes Subsystems Componentes Interfaces Scripts Engenharia de Software 20 10
Perigos na medição Medir demais, ou antes demais Medir pouco, ou tarde demais Medir as coisas erradas Definição imprecisa das métricas Usar as métricas para motivar em vez de para compreender Colectar dados que não são usados Mal interpretação dos dados Engenharia de Software 21 Exercicio 1 PSP Personal Software Process Watts Humphrey desenvolveu o Personal Software Process PSP para melhorar as habilidades individuais dos engenheiros de software. Sua abordagem ressalta os tempos individuais com a finalidade de monitorar e medir as habilidades individuais. Um dos resultados dessa medida é a produtividade individual. A medida usual de produtividade é a de linhas de código produzidas or dia (LOC/dia). Adicionalmente, erros são controlados e arquivados. Isto permite que um indivíduo aprenda onde os erros ocorrem e busque técnicas diferentes para melhorar este valor. Além disso, a produtividade pode ser usada para avaliar os atrasos dos cronogramas propostos. Engenharia de Software 22 11
O programador gastou 360+270+150+120=900 minutos para escrever e testar o programa de 160 LOC. Supondo uma dia de trabalho de 5 horas x dia (300 minutos/dia), X gastou 3 dias para programas as 160 LOC. Isso dá uma produtividade de 53 LOC/dia. Quando o gerente de X fizer o planeamento semanal dum projecto de 1000 LOC, X é capaz de prever que o projecto irá demorar quatro semanas. Data Início Fim Interrupções Delta Tarefa 1/1/01 09:00 15:30 30 almoço 360 Código 50 LOC 3/1/01 09:00 14:00 30 almoço 270 Código 60 LOC 4/1/01 09:00 11:30 150 Código 50 LOC 12:00 14:00 120 Teste Engenharia de Software 23 Exercicio 1 Usando a tabela de tempo a seguir, calcule a produtividade do programador em LOC/dia. Assuma que o projecto 1 tinha 120 LOC e o projecto 2 tinha 180 LOC Data Início Fim Interrupções Delta Tarefa 1/2/01 08:30 16:30 60 almoço Projecto 1 2/2/01 09:00 17:00 30 almoço Projecto 1 5/2/01 09:00 17:30 30 almoço Projecto 2 6/2/01 07:30 12:00 Projecto 2 Engenharia de Software 24 12
Resolução Engenharia de Software 25 Exemplo de modelo para monotorizar o progresso de um projecto Análise do valor agregado Uma abordagem para medir o progresso num projecto de software é calcular o quanto foi alcançado. Isso é chamado de análise do valor agregado. Basicamente, é a percentagem do tempo estimado que foi completada. Medidas adicionais podem ser calculadas. Embora isso seja baseado na estimativa do esforço, poderia ser baseado em qualquer quantidade que possa ser estimada e que seja relacionada ao progresso. Engenharia de Software 26 13
Medidas básicas: BCW Budgeted Cost of Work (esforço estimado para cada tarefa) BCWS - (Budgeted Cost of Work Scheduled (Total do esforço programado, soma do estimado das tarefas todas num periodo específico de tempo) BAC Budgeted at Completion (Total do esforço do projecto) PV Planned Value= PV = BCW/BAC (% do esforço total estimado agendado duma tarefa em relação ao esforço total) BCWP Budgeted Cost of Work Performed ( Custo orçamentado do trabalho executado, soma dos esforços estimados para uma tarefa de trabalho completada num tempo específico) ACWP Actual Cost of Work Performed (Custo real do trabalho executado, soma dos esforços reais para as tarefas de trabalho completadas) Engenharia de Software 27 Indicadores de progresso: EV Earned Value = BCWP/BAC = PV de todas as tarefas de trabalho completadas SPI Schedule Performance Index = BCWP / BCWS SV Schedule Variation = BCWP- BCWS CPI Cost Performance Index = BCWP/ACWP CV Cost Variation = BCWP- ACWP Engenharia de Software 28 14
Tarefa Esforço estimado Esforço actual Data estimada Data actual (prog/dias) (prog/dias) de término de término 1 5 10 25/01/01 01/02/01 2 5 20 15/02/01 15/02/01 Exercicio 3 120 80 15/05/01 4 60 50 15/04/01 01/04/01 5 60 50 01/07/01 6 80 70 01/09/01 total 330 280 Calcule para a data 1/04/2004 os indicadores : BAC BCWP EV BCWS SPI e o SV AWCP Engenharia de Software 29 Resolução Engenharia de Software 30 15