Engenharia de Software II Aula 28 Revisão para a Prova 2 http://www.ic.uff.br/~bianca/engsoft2/ Aula 28-28/07/2006 1
Matéria para a Prova 2 Gestão de projetos de software Conceitos (Cap. 21) Métricas (Cap. 22 Seções 22.1 e 22.2) Estimativas (Cap. 23 Seções 23.1 a 23.7) Cronogramação (Cap. 24) Gestão de risco (Cap. 25) Gestão de qualidade (Cap. 26 Seções 26.1 a 26.7) Gestão de modificações (Cap. 27 Seções 27.1 a 27.3) Reengenharia e engenharia reversa (Cap. 31 Seções 31.1 a 31.6) Aula 28-28/07/2006 2
Conceitos de Gestão de Processos Quais são as principais conseqüências de um projeto mal gerido? Atrasos no cronograma, produto de baixa qualidade, gastos fora do orçamento. Que qualidades deve ter um bom líder de equipe? Habilidade de motivar a equipe, organização, criatividade, entendimento do problema e comprometimento com a qualidade. Aula 28-28/07/2006 3
Conceitos de Gestão de Processos Descreva cada um dos paradigmas de equipe abaixo: Fechado: organização hierárquica, cada um dos membros da equipe tem um papel definido na hierarquia. Aleatório: a equipe é fracamente estruturada e sua organização depende da iniciativa individual. Aberto: baseada na colaboração, com intensa comunicação e tomada de decisões baseada no consenso. Síncrono: baseada na decomposição de um problema e organiza os membros da equipe para trabalhar em cada parte, sem muita comunicação. Aula 28-28/07/2006 4
Conceitos de Gestão de Processos Qual deve ser a primeira atividade na gestão de um projeto de software? Determinação do escopo. Como é feita a decomposição do problema no início do projeto? A funcionalidade que precisa ser entregue e o processo que será usado para entregá-la são refinadas para fornecer mais detalhes. Aula 28-28/07/2006 5
Métricas de Processo e Projeto Qual é a diferença entre métricas de processo e métricas de projeto? As métricas de processo são coletadas no decorrer de vários projetos e sua intenção é melhorar o processo de software em si. As métricas de projeto permitem ao gerente acompanhar, avaliar e ajustar um determinado projeto. Aula 28-28/07/2006 6
Métricas de Processo e Projeto Qual é a função das métricas privadas? Elas devem ser usadas como a única forma de avaliar o desempenho de um indivíduo? As métricas privadas servem para ajudar o engenheiro de software a aperfeiçoar seu trabalho individual. Elas não devem ser usadas como única forma de avaliação. Outras considerações subjetivas devem ser levadas em conta pelo gerente. Aula 28-28/07/2006 7
Métricas de Processo e Projeto A equipe A encontrou 342 erros durante o processo de engenharia de software. A equipe B encontrou 184 erros. Que medidas adicionais devem ser tomadas com relação aos projetos A e B para determinar qual das equipes encontrou erros mais eficientemente? Que métricas seriam necessárias para fazer essa determinação? Que dados históricos poderiam ser utilizados? Deve-se utilizar uma métrica de tamanho (LOC ou FP) para normalizar o número de erros de acordo com o tamanho de cada projeto. Além disso, pode-se utilizar dados históricos a respeito de projetos do mesmo tipo e tamanho que os projetos A e B para determinar se o número de erros encontrado está de acordo com o esperado para projetos do mesmo tipo. Aula 28-28/07/2006 8
Métricas de Processo e Projeto Qual é a vantagem e a desvantagem de se utilizar LOC como uma métrica de tamanho? A vantagem é que a métrica LOC é fácil de ser calculada depois que o código foi gerado. A desvantagem é que ela é dependente da linguagem de programação, penaliza programas curtos e bem projetadas e é difícil de ser estimada durante o projeto. Aula 28-28/07/2006 9
Métricas de Processo e Projeto Qual é a vantagem e a desvantagem de se utilizar FP como uma métrica de tamanho? A vantagem é que a métrica FP é independente de linguagem de programação e pode ser calculada antes da geração de código. A desvantagem é que ela é baseada em dados subjetivos e é difícil de ser calculada. Aula 28-28/07/2006 10
Estimativas de Projeto de Software Que tipo de informação é extremamente útil na estimativa de projetos de software? Justifique sua resposta. Informação histórica de projetos semelhantes. Porque ela pode ser usada para gerar estimativas quantitativas para o novo projeto. Aula 28-28/07/2006 11
Estimativas de Projeto de Software O que é viabilidade de software? Por que ela deve ser estimada? A viabilidade determina se um software pode ou não ser construído dadas as condições tecnólogicas, financeiras, de tempo e de recursos. Ela deve ser estimada, porque se o software não for considerado viável dadas as condições atuais, a sua construção deve ser descartada até que as condições se modifiquem. Aula 28-28/07/2006 12
Estimativas de Projeto de Software Quais as dificuldades de se usar casos de uso para estimar o tamanho de um projeto? Casos de uso não têm um formato padrão, são escritos em diferentes níveis de abstração, representam uma visão externa e não indicam a complexidade de cada função a ser desenvolvida. Aula 28-28/07/2006 13
Estimativas de Projeto de Software O que é um modelo de estimativa empírico? Quais são as limitações desse tipo de modelo? Dados valores para o tamanho do software (LOC ou FP), um modelo de estimativa empírica estima o esforço requerido. Como os parâmetros dos modelos são baseados em projetos anteriores, o modelo só é válido para uma classe específica de projetos. Aula 28-28/07/2006 14
Cronogramação O que um gerente de software deve fazer se no início do projeto percebe que a data de entrega é impraticável? O gerente deve tentar proteger a equipe da pressão do cronograma, modificando o projeto de alguma forma. Uma opção é contratar mais pessoal. Outra solução é usar um modelo incremental e só garantir alguma funcionalidade no primeiro incremento. Aula 28-28/07/2006 15
Cronogramação Explique os seguintes princípios básicos de cronogramação: Compartimentalização: o projeto deve ser decomposto em um certo número de tarefas e atividades. Interdependência: a dependência entre as tarefas e atividades deve ser determinada; algumas devem ocorrer em seqüência, outras podem ocorrer em paralelo. Definição de marcos de referência: marcos de referência devem ser definidos, indicando que naquele ponto um ou mais produtos de trabalho estarão prontos e revisados quanto à qualidade. Aula 28-28/07/2006 16
Cronogramação Qual é a desvantagem de se integrar novos programadores à equipe durante o projeto? Normalmente leva a atrasos, porque os programadores antigos tem que parar seu trabalho para treinar os novos programadores. Aula 28-28/07/2006 17
Cronogramação O que é o caminho crítico de um projeto? Dê um exemplo de método para calcular o caminho crítico dadas as durações e interdependências entre as tarefas. O caminho crítico é a cadeia de tarefas que determina a duração de um projeto. Se qualquer uma dessas tarefas atrasar, o projeto será atrasado. Ex.: PERT. Aula 28-28/07/2006 18
Cronogramação Qual é o objetivo da análise de valor agregado? O objetivo da análise de valor agregado é avaliar o progresso do projeto, através do cálculo da porcentagem de execução usando uma escala comum. Aula 28-28/07/2006 19
Gestão de Risco O que é risco? Dê um exemplo de risco para um projeto de software? Risco é um problema em potencial que se ocorrer causa conseqüências indesejadas para o projeto. Ex.: rotatividade alta de pessoal, estimativas de tamanho mal-feita, resistência dos usuários ao sistema. Aula 28-28/07/2006 20
Gestão de Risco Qual é a diferença entre uma estratégia reativa e uma estratégia proativa na gestão de riscos? A estratégia reativa apenas reserva recursos para lidar com os riscos quando eles se tornam problemas. A estratégia proativa estabelece um plano para administrar os riscos que começa a ser executado no início do projeto. Aula 28-28/07/2006 21
Gestão de Risco Qual a diferença entre um risco previsível e um risco conhecido? Um risco previsível é aquele extrapolado de projetos anteriores. Um risco conhecido é aquele descoberto após uma avaliação cuidadosa do projeto. O que é um risco de negócio? Dê um exemplo. Um risco de negócio acontece por questões comerciais, estratégicas e gerenciais que impedem a construção do software. Exemplo: perda de apoio da gerência superior. Aula 28-28/07/2006 22
Gestão de Risco Qual é o método mais comumente usado para a identificação de riscos? É uso de uma checklist que identifica os riscos mais comuns de projetos de software. Você pode pensar em uma situação em que um risco de alta probabilidade e alto impacto não seria considerado como parte do plano RMMM? Sim. Se o custo esperado de gerenciar o risco for maior do que o benefícios esperado de atenuá-lo. Aula 28-28/07/2006 23
Gestão de Qualidade O que é controle de variação? Como ele é aplicado no contexto de engenharia de software? Controlar a variação é fazer com que um processo possa ser repetido gerando sempre os mesmos resultados. No contexto de engenharia de software, controla-se a variação no processo genérico que aplicamos. Aula 28-28/07/2006 24
Gestão de Qualidade A qualidade de software pode ser definida como a satisfação dos requisitos do cliente? Responda sim ou não e justifique a sua resposta. Não. Além da satisfação dos requisitos funcionais, a qualidade inclui seguir normas de desenvolvimento explicitamente documentadas e outras características implícitas em qualquer projeto de software (manutenibilidade, usabilidade). Aula 28-28/07/2006 25
Gestão de Qualidade Qual é a função principal do grupo SQA? É garantir a qualidade, através de supervisão e auditorias. Descreva os passos da organização de uma revisão técnica formal antes da reunião propriamente dita. O produtor entrega o produto pronto ao líder do projeto. O líder do projeto escolhe um líder para a revisão, que por sua vez escolhe três revisores e entrega cópias do projeto a eles. O líder da revisão e os revisores devem estudar e revisar o produto antes da reunião. Aula 28-28/07/2006 26
Gestão de Qualidade Por que uma medida de confiabilidade é considerada de maior importância para o usuário do que uma medida de erros por linha de código? Porque ela reflete apenas os erros que serão percebidos pelo usuário e em que taxa eles ocorrerão. Aula 28-28/07/2006 27
Gestão de Qualidade Para que servem os modelos de amplificação de defeitos? Para modelar a geração e a detecção de erros durante o processo. Usando esses modelos, podemos calcular o efeito da introdução de RTFs no processo. O que pode ser descoberto através de técnicas de garantia estatística da qualidade de software? Pode-se descobrir quais são os elementos do processo que introduzem a maioria dos erros importantes, para tentar aperfeiçoá-lo. Aula 28-28/07/2006 28
Gestão de Modificações Por que é inevitável que um software de computador seja modificado enquanto ele está sendo desenvolvido ou depois de pronto? Dê exemplos específicos. Porque sempre vão existir modificações no ambiente externo ao projeto como condições de negócio e necessidades do cliente. Além disso, durante o projeto é muito provável que se queira modificar a abordagem técnica depois de algumas tentativas. Aula 28-28/07/2006 29
Gestão de Modificações Qual é o motivo da criação de referenciais que não podem ser modificados sem um processo formal de modificação? O motivo é evitar a confusão que existiria caso produtos considerados prontos fossem modificados sem motivo ou sem avisar todo o pessoal necessário. Aula 28-28/07/2006 30
Gestão de Modificações Dê três exemplos de itens de configuração de um software. Código fonte, planos de teste, modelos de análise. Por que as ferramentas que foram usadas para construir o software devem fazer parte da configuração? Porque se o software tiver que ser modificado, pode ser necessário utilizar as mesmas ferramentas utilizadas anteriormente. Aula 28-28/07/2006 31
Gestão de Modificações Para que serve a ferramenta CVS? Para o controle de versão. A ferramenta estabelece um repositório que mantém todas as versões de um arquivo em um único arquivo. Ela protege contra modificações simultâneas de um arquivo. Além da revisão técnica formal, o que deve ser feito para garantir que uma modificação foi adequadamente implementada? Deve-se fazer uma auditoria de configuração de software, que garante que a modificação foi feita sem mudanças adicionais e que todos os itens de configuração foram atualizados. Aula 28-28/07/2006 32
Reengenharia A reengenharia de um processo de negócio necessariamente leva a uma reengenharia do software? Responda sim ou não e justifique a sua resposta. Não. A reengenharia de um processo de negócio pode levar à criação de um novo software, caso as mudanças sejam muito significativas. Neste caso, o software anterior deixa de ser útil até para uma reengenharia. Aula 28-28/07/2006 33
Reengenharia Qual é o objetivo da engenharia reversa no contexto da engenharia de software? O objetivo é recuperar o projeto (de dados, procedimento e interface) a partir do código-fonte do programa. Qual é a diferença entre uma reestruturação de código e um processo de engenharia avante? A reestruturação de código altera a lógica interna de um programa sem afetar a arquitetura global. A engenharia avante reconstrói um novo programa (novo projeto) a partir do projeto extraído através de engenharia reversa. Aula 28-28/07/2006 34
Reengenharia Para que serve a análise de inventário no processo de reengenharia? Serve para selecionar os programas que devem ser submetidos ao processo de reengenharia. Que técnicas podem ser usadas para a reestruturação de código? Técnicas: 1) Modelagem do código usando álgebra booleana + aplicação de regras de transformação, 2) Mapeamento dos recursos que são intercambiados entre módulos + reestruração para minimizar acoplamento. Aula 28-28/07/2006 35
Reengenharia Quais custos e benefícios devem ser levados em consideração quando tentamos decidir se vale à pena submeter uma aplicação existente à reengenharia? Custo anual de manutenção do software antes e depois da reengenharia; custo do investimento de reengenharia, considerados os riscos. Aula 28-28/07/2006 36