Engenharia de Software II Aula 18 http://www.ic.uff.br/~bianca/engsoft2/ Aula 18-23/05/2006 1
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 Estimativas Cronogramação Gestão de risco Gestão de qualidade Gestão de modificações Reengenharia e engenharia reversa Aula 18-23/05/2006 2
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 Projetos mal geridos levam a prazos de entrega inexeqüíveis, fogem do orçamento e geram produtos de baixa qualidade. A gestão efetiva de projetos focaliza quatro fatores: Pessoal Produto Processo Projeto Aula 18-23/05/2006 3
Quatro Ps Pessoal Considerado como o fator mais importante para o sucesso de um projeto de software por muitos executivos. A gestão de pessoal inclui recrutamento, seleção, gestão de desempenho, treinamento, renumeração, desenvolvimento de carreira, projeto do trabalho e desenvolvimento de equipe. Produto Antes de um projeto ser planejado, devem ser definidos os objetivo e o escopo do produto. A gestão de produto inclui engenharia de processo do negócio e engenharia de requisitos. Aula 18-23/05/2006 4
Quatro Ps (cont.) Processo Fornece o arcabouço a partir do qual pode ser estabelecido um plano para o desenvolvimento do software. Inclui as atividades de arcabouço e as atividades guarda-chuva. Projeto O gerente de projeto deve entender os fatores críticos de processo e desenvolver uma abordagem de bom senso para planejar, monitorar e controlara o projeto. Aula 18-23/05/2006 5
Pessoal Participam do projeto de software as seguintes categorias de pessoas interessadas: Gerentes Seniores Definem aspectos do negócio que têm influência sobre o projeto. Gerentes de projeto Devem planejar, motivar, organizar e controlar os profissionais técnicos. Profissionais Fornecem as aptidões técnicas necessárias para fazer a engenharia de um produto. Clientes Especificam os requisitos para o software. Usuários finais Interagem com o software depois que ele é liberado para uso. Aula 18-23/05/2006 6
Líderes de Equipe Nem todo profissional competente é capaz de se tornar um bom gerente de projeto. Para ser um bom líder de equipe, o gerente tem que ter: Motivação: habilidade de encorajar o pessoal técnico. Organização: habilidade de moldar processos permitindo que o conceito inicial se torne um produto final. Inovação: habilidade de encorajar o pessoal a criar e a se sentir criativo. Além disso, o gerente deve adotar uma postura de solução de problemas. O gerente deve se concentrar no entendimento do problema, gerir o fluxo de idéias e deixar claro que a qualidade não deve ser comprometida. Aula 18-23/05/2006 7
A Equipe de Software A melhor estrutura de equipe depende de vários fatores: Dificuldade do problema Tamanho do problema (linhas de código ou pontos por função) Período durante o qual a equipe ficará junta. Grau de modularização. Qualidade e confiabilidade exigidas pelo sistema. O grau de comunicação exigido pelo projeto. Aula 18-23/05/2006 8
A Equipe de Software (cont.) Existem quatro paradigmas para equipes de software: Paradigma fechado Hierarquia tradicional de autoridades Funciona melhor para produzir software bastante semelhante a anteriores, mas não permite muita inovação. Paradigma aleatório Estrutura uma equipe fracamente e depende da iniciativa individual. Mais adequado quando é necessário inovação, mas não funciona quando for necessário desempenho ordenado. Paradigma aberto O trabalho é realizado em colaboração, com intensa comunicação e tomada de decisões baseadas no consenso. Adequado à solução de problemas complexos, mas pode não ser muito eficiente. Paradigma síncrono Apóia-se na compartimentalização natural de um problema e organiza os membros da equipe pra trabalhar em cada parte, sem muita comunicação. Aula 18-23/05/2006 9
Equipes ágeis A filosofia ágil incentiva a satisfação do cliente e a entrega incremental de software desde o início. Para a equipe, a filosofia ágil enfatiza a competência individual combinada com a colaboração do grupo. Uma equipe ágil é uma equipe auto-organizada que tem autoridade pra planejar e tomar decisões críticas. Usa elementos dos paradigmas aleatório, aberto e síncrono. Aula 18-23/05/2006 10
O Produto No início do projeto, o gerente passa por um dilema: É necessário criar estimativas quantitativas e planos organizados sem informação sólida disponível (requisitos indefinidos). A determinação do escopo do software deve ser a primeira atividade de gestão de um projeto de software. Logo depois, é feita a decomposição do problema. Aula 18-23/05/2006 11
Escopo do Software O escopo é definido pela resposta às seguintes questões: Contexto Como o software se encaixa no contexto de um sistema maior? Objetivos da informação Que objetos de dados visíveis para o cliente são produzidos como saída? Que objetos são necessários como entrada? Função e desempenho Que função o software desempenha para transformar os dados de entrada em saídas? Aula 18-23/05/2006 12
Decomposição do Problema As funções do software, identificadas no escopo, são avaliadas e refinadas para fornecer mais detalhes. A decomposição é aplicada em duas áreas principais: A funcionalidade que precisa ser entregue. O processo que será usado para entregá-la. Aula 18-23/05/2006 13
Exemplo Decomposição do Problema Produto de Processamento de Texto Entrada tanto por voz quanto por teclado Preparação automática de índices Edição automática Verificação da sintaxe Verificação gramatical Verificação de referências Correção maiúscula/minúscula Aula 18-23/05/2006 14