2.Gerência de Projetos: Métricas de Software

Transcrição

1 2.Gerência de Projetos: Métricas de Software A seguir consideraremos os conceitos fundamentais que levam à administração efetiva de projetos de software. Vamos considerar o papel da administração e das métricas de software e o impacto das mesmas sobre a gerência de projetos.

2 2.1 O processo de gerência de projetos A gerência de projetos é a primeira camada do processo de engenharia de software. Ela abrange todo o processo de desenvolvimento, do começo ao fim. Uma vez que a gerência de projetos de software é tão importante para o sucesso de um projeto, seria razoável presumir-se que todos os gerentes de projetos entendem como colocá-la em prática.

3 2.1.1 Iniciando um projeto de software Antes que um projeto possa ser planejado, os objetivos e o escopo devem ser estabelecidos, soluções alternativas devem ser consideradas e as restrições administrativas e técnicas, identificadas. O desenvolvedor e o cliente devem reunir-se para definir os objetivos e o escopo do projeto. Os objetivos identificam as metas globais e o escopo identifica as funções primárias que o software deve realizar.

4 2.1.2 Medidas métricas Na maioria dos empreendimentos técnicos, as medições e as métricas ajudam-nos a entender o processo técnico usado para se desenvolver um produto. As métricas de software foram desenvolvidas a fim de oferecer a gerentes e profissionais técnicos à devida compreensão sobre o processo de engenharia de software e sobre o produto que ele produz.

5 2.1.3 Estimativa Uma das atividades fundamentais do processo de gerenciamento de projetos de software é o planejamento. Quando o projeto de software é planejado, estimativas do esforço humano exigido, duração cronológica do projeto devem ser derivadas. Uma série de técnicas de estimativas foram disponibilizadas para o desenvolvimento de software, todas têm os seguintes atributos em comum: O escopo deve ser estabelecido antecipadamente ao projeto; Métricas são utilizadas e históricos do passado são usados como base; O projeto é dividido em pequenas partes, que são estimadas individualmente;

6 2.1.4 Análise dos riscos Sempre que um programa de computador for construído haverá áreas de incerteza. A análise de riscos é crucial para um bom gerenciamento de projeto de software e, contudo, muitos projetos são levados a efeito sem nenhuma consideração específica de riscos. A análise de risco é, de fato, uma série de passos de administração de riscos que nos possibilita atacar o risco. Esses passos são aplicados em todo o processo de engenharia de software.

7 2.1.5 Determinação de Prazos Todo software tem uma programação de atividades para sua realização, mas nem todos os programas são criados igualmente. A programação se desenvolve por si mesma ou foi planejada antecipadamente? Os gerentes se concentraram somente na data final de entrega ou um curso bem definido foi identificado e monitorado para garantir que o prazo final seja cumprido? A programação do projeto de software não é, de fato, absolutamente diferente de qualquer projeto de engenharia. Uma rede de tarefas é criada.

8 2.1.6 Monitoração e controle Logo que a programação de desenvolvimento for estabelecida, iniciar-se-á a atividade de monitoração e controle. Cada tarefa anotada no programa é então rastreada pelo gerente de projetos. Dessa forma, o desenvolvimento de software pode ser mais bem controlado.

9 2.2 Métricas de produtividade e qualidade de software Medir é fundamental em qualquer disciplina de engenharia, e a engenharia de software não é exceção. Métricas de software referem-se a uma ampla variedade de medidas de software de computador. Dentro do contexto de gerenciamento de projetos de software, estamos preocupados primeiramente com métricas de produtividade e de qualidade.

10 2.3 Medidas do software O software é medido por muitas razões: (1) indicar a qualidade do produto; (2) avaliar a produtividade das pessoas que produzem o produto; (3) avaliar os benefícios derivados de novos métodos e ferramentas de software; (4) formar uma linha básica para estimativas; (5) ajudar a justificar os pedidos de novas ferramentas ou treinamento adicional. As divisões do mundo físico podem ser divididas em duas categorias: medidas diretas (comprimento de um parafuso) e medidas indiretas (qualidade do parafuso produzido, medida pela contagem dos parafusos rejeitados). As métricas de software podem ser divididas em categorias de maneira idêntica.

11 2.3 Medidas do software Entre as medidas do processo de engenharia de software incluem-se o custo e o esforço aplicados. As medidas diretas do produto incluem as linhas de código (LOC) produzidas, velocidade de execução, tamanho de memória e defeitos registrados ao longo de certo espaço de complexidade. As medidas indiretas do produto incluem funcionalidade, qualidade, complexidade, eficiência, confiabilidade, manutenibilidade e muitas outras.

12 2.3.1 Métricas orientadas ao tamanho Se uma organização de software mantiver registros simples, uma tabela de dados orientados ao tamanho poderá ser criada. A tabela relaciona cada projeto de desenvolvimento de software que foi concluído no decorrer dos últimos anos aos correspondentes dados orientados ao tamanho desse projeto. Projeto Esforço $ KLOC Págs. Docum. Erros pessoas Aaa Ccc fff

13 2.3.1 Métricas orientadas ao tamanho A partir dos dados brutos contidos na tabela, um conjunto de métricas de qualidade e de produtividade orientadas ao tamanho pode ser desenvolvido para cada projeto. Produtividade = KLOC/pessoa-mês Qualidade = defeitos/kloc Custo = $/KLOC Documentação = páginas / KLOC As métricas orientadas ao tamanho provocam controvérsias e não são universalmente aceitas como a melhor maneira de se medir o processo de desenvolvimento de software. A maior parte da controvérsia gira em torno do uso de linhas de código como uma medida-chave.

14 2.3.2 Métricas orientadas à função Métricas de software orientada à função são medidas indiretas do software e do processo por meio da qual ele é desenvolvido. Em vez de controlar as linhas de código, a métrica orientada à função concentra-se na funcionalidade ou utilidade do programa. Métricas orientadas à função foram abordadas pela primeira vez por Albrecht, que sugeriu um abordagem à medição da produtividade chamada método do ponto-porfunção(function point).

15 2.3.2 Métricas orientadas à função Número de entradas do usuário: Cada entrada do usuário que proporcione dados distintos orientados à aplicação é contadas. As entradas devem ser distinguidas das consultas, as quais são contadas separadamente. Número de saída do usuário: Cada saída do usuário que proporcione informações orientadas à aplicação é contada. Nesse contexto, saída refere-se a relatórios, telas, mensagens de erro, etc. Número de consultas do usuário: Uma consulta é definida como uma entrada on-line que resulte na geração de alguma resposta de software imediata na forma de uma saída on-line. Número de arquivos: Cada arquivo-mestre lógico, isto é, um agrupamento lógico de dados, que pode ser uma parte de um grande banco de dados ou um arquivo convencional, é contado. Número de interfaces externas: Todas as interfaces legíveis por máquina que sejam usadas para transmitir informações a outro sistema são contadas.

16 2.3.2 Métricas orientadas à função

17 2.4 Métricas de qualidade do software A qualidade pode ser medida ao longo do processo de engenharia de software e depois que o software for entregue ao cliente e aos usuários. Métricas derivadas antes que o software seja entregue oferecem uma base quantitativa para se tomar decisões referentes a projeto e testes. Métricas de qualidade nessa categoria incluem a complexidade do programa, modularidade efetiva e, acima de tudo, tamanho do programa. Métrica usadas após a entrega concentram-se no número de defeitos descobertos e na manutenibilidade do sistema. É importante enfatizar que após a entrega as métricas de qualidade de software dão aos gerentes e ao pessoal técnico uma indicação post-mortem da efetividade do processo de engenharia de software.

18 2.4.1 Uma visão geral dos fatores que afetam a qualidade Há algumas décadas foi definido um conjunto de fatores da qualidade que era um primeiro passo na direção do desenvolvimento de métricas para a qualidade do software. Esses fatores avaliavam o software a partir de três pontos de vista distintos: (1) operação do produto; (2) revisão do produto; e (3) transição do produto. A relação entre esses fatores da qualidade chamamos de framework.

19 2.4.2 Medida da Qualidade Medidas mais utilizadas para qualidade: Corretitude: Um programa deve operar corretamente; caso contrário, oferecerá pouco valor aos seus usuários. Manutenibilidade: A manutenção de software é responsável por mais esforço do que qualquer outra atividade de engenharia de software. Integridade: Esse atributo mede a capacidade que um sistema tem de suportar ataques à sua integridade. Usabilidade: Se um programa não for user friendly frequentemente estará destinado ao fracasso, mesmo que as funções que ele execute sejam valiosas.

20 2.5 Resumo A medição possibilita que gerentes e profissionais entendam melhor o processo de engenharia de software e o produto que ele produz. Usando medidas diretas e indiretas, as métricas de produtividade e qualidade podem ser definidas.

21 3 Administração de projetos: estimativas O processo de administração de projetos de software inicia-se com um conjunto de atividades que são coletivamente denominadas planejamento de projetos. A primeira dessas atividades é a realização de estimativas. Quando queremos que estimativas sejam feitas, olhamos para o futuro e aceitamos certo grau de incerteza como coisa esperada.

22 3.1 Observações sobre a realização de estimativas Um destacado executivo foi indagado cera vez sobre qual característica em particular foi considerada a mais importante num gerente de projetos. Sua resposta:...uma pessoa com capacidade para saber o que acontecerá de errado antes que isso de fato aconteça... Poderíamos acrescentar:...e a coragem para estimar quando o futuro estiver nebuloso... A estimativa dos recursos, custo e programação de atividades para um esforço de desenvolvimento de software exige experiência, acesso a boas informações históricas e a coragem para se comprometer com medidas quantitativas quando dados qualitativos forem tudo o que existir.

23 3.1 Observações sobre a realização de estimativas A realização de estimativas carrega riscos inerentes, e os fatores que aumentam os riscos são: Complexidade do projeto: a complexidade é uma medida relativa que é afetada pela familiaridade que se tem com o esforço passado. Tamanho do projeto: à medida que o tamanho aumenta, a interdependência entre vários elementos do software cresce rapidamente. Estrutura do projeto: a palavra estrutura refere-se à facilidade com que as funções podem ser dispostas em compartimentos e à natureza hierárquica da informações que devem ser processadas.

24 3.2 Objetivos do planejamento de projetos O gerente de projetos de software confronta-se com um dilema logo no começo de um esforço de desenvolvimento. São exigidas estimativas quantitativas, mas não existem informações sólidas disponíveis. O objetivo do planejamento de projetos de software é fornecer uma estrutura que possibilite ao gerente fazer estimativas razoáveis de recursos, custos e prazos. Essas estimativas são realizadas dentro de um plano de tempo limitado ao início de um projeto de software e devem ser regularmente atualizadas à medida que o projeto progride.

25 3.3 Escopo do Software O escopo do software descreve a função, o desempenho, as restrições, as interfaces e a confiabilidade. As funções descritas na declaração do escopo são avaliadas e, em certos casos, refinadas para oferecer mais detalhes antes do início da estimativa. A função, o desempenho e as restrições devem ser avaliadas em conjunto. A mesma função pode precipitar uma diferença de ordem de magnitude no esforço de desenvolvimento quando considerada no contexto de diferentes limites de desempenho.

26 3.3 Escopo do Software O conceito de interface é interpretado de maneira a ter os seguintes significados: (1) hardware que executa o software e dispositivos que são indiretamente controlados pelo software; (2) software que já existe e que deve ser ligado ao novo software; (3) pessoas que fazem uso do software por meio de terminais ou outros dispositivos de entrada/saída; (4) procedimentos que precedem ou sucedem o software como uma série sequencial de operações. O aspecto menos preciso do escopo do software é a discussão da confiabilidade. Existem medidas de confiabilidade de software, mas raramente elas são usadas essa etapa de um projeto.

27 3.4 Recursos A segunda tarefa de planejamento de software é a estimativa dos recursos exigidos para se levar a efeito o esforço de desenvolvimento do software.. Primeiramente as ferramentas de hardware e software, devem existir para sustentar o esforço de desenvolvimento. Em seguida o recurso primordial, pessoas, sempre é exigido. Cada recurso é especificado segundo quatro características: descrição do recurso, uma declaração da disponibilidade, tempo cronológico em que o recurso será exigido e por quanto tempo o recurso será aplicado.

28 3.4.1 Recursos humanos O número de pessoas exigido num projeto de software pode ser determinado somente depois que uma estimativa do esforço de desenvolvimento (pessoas-mês ou pessoas-ano) for feita.

29 3.4.2 Recursos de hardware Três categorias de hardware devem ser consideradas durante o planejamento do projeto: o hardware de desenvolvimento, o hardware de produção e outros elementos de hardware do novo sistema.

30 3.4.3 Recursos de software Atualmente, os engenheiros de software usam um conjunto de ferramentas que, de muitas maneiras, é análogo às ferramentas de projeto auxiliadas por computador e engenharia auxiliada por computador usadas pelos engenheiros de hardware. Ferramentas de planejamento de Sistemas de Informação. Ao modelar os requisitos estratégicos de informação de uma organização, as ferramentas de planejamento de sistemas de informação proporcionam um meta-modelo a partir do qual sistemas de informações específicos são derivados. Ferramenta de Gerenciamento de Projetos. Usando estas ferramentas de gerenciamento, o gerente de projetos pode gerar estimativas do esforço, custo e duração de um projeto de software; definir uma estrutura de divisão do trabalho; planejar uma programação de atividades de projeto; e monitorar projetos em base contínua.

31 3.4.3 Recursos de software Ferramentas de Apoio. A categoria das ferramentas de apoio abrange as ferramentas de produção de documentos, software de sistemas em rede, banco de dados, correspondência eletrônica e ferramentas de gerenciamento de configuração, usadas para controlar e gerenciar a informação que é criada à medida que o software é desenvolvido. Ferramentas de Análise e Projeto. As ferramentas de análise e projeto possibilitam que um engenheiro de software crie um modelo do sistema a ser construído. Essas ferramentas ajudam na criação de um modelo bem como na avaliação de sua qualidade. Ao realizarem a verificação da consistência e da validade de cada modelo, as ferramentas de análise e projeto fornecem ao engenheiro de software esclarecimentos e ajuda para eliminar erros antes que estes se propaguem no programa.

32 3.4.3 Recursos de software Ferramentas de Programação. Utilitários básicos, editores, compiladores e depuradores são uma parte legítima de ferramentas CASE. Ferramentas de programação orientadas a objeto, linguagens de programação de quarta geração, sistemas avançados de consulta de banco de dados e um amplo conjunto de ferramentas de computadores pessoais, todos caem nesta categoria de ferramentas CASE. Ferramentas de Integração e Testes. As ferramentas de testes oferecem uma variedade de diferentes níveis de apoio aos passos de testes de software que são aplicados como parte do processo de engenharia de software. Estas ferramentas podem ajudar a reduzir a quantidade de esforço aplicado ao processo de teste.

33 3.4.3 Recursos de software Ferramentas de Construção de Protótipos e Simulação. As ferramentas de construção de protótipos e simulação envolvem um amplo conjunto de ferramentas que variam em grau de sofisticação, partindo de simples screen painters até produtos de simulação para análise da determinação de tempo e de tamanho em sistemas embutidos de tempo real. Em seu aspecto mais fundamental, estas ferramentas se concentram na criação de telas e relatórios que possibilitarão ao usuário entender o domínio de entrada e de saída de uma sistema. Ferramentas de Manutenção. A ferramentas de manutenção podem ajudar a decompor um programa existente e proporcionam esclarecimentos ao engenheiro, porém o engenheiro deve aplicar a intuição, a percepção de projeto e a inteligência humana para concluir o processo de engenharia reversa e/ou para fazer a reengenharia da aplicação.

34 3.4.3 Recursos de software Ferramentas de Framework. Estas ferramentas disponibilizam uma plataforma a partir da qual um ambiente integrado de suporte a projetos pode ser criado. Oferecem capacidades de gerenciamento de configuração e gerenciamento de banco de dados.