Medição de Software
A estrutura para medição de software é baseada em três princípios -
- Classificação das entidades a serem examinadas
- Determinar metas de medição relevantes
- Identificar o nível de maturidade que a organização atingiu
Classificação das entidades a serem examinadas
Na engenharia de software, existem principalmente três classes de entidades. Eles são -
- Processes
- Products
- Resources
Todas essas entidades têm entidades internas e externas.
Internal attributessão aqueles que podem ser medidos puramente em termos do processo, produto ou recursos em si. Por exemplo: tamanho, complexidade, dependência entre módulos.
External attributessão aqueles que podem ser medidos apenas no que diz respeito à sua relação com o meio ambiente. Por exemplo: O número total de falhas experimentadas por um usuário, o tempo que leva para pesquisar o banco de dados e recuperar informações.
Os diferentes atributos que podem ser medidos para cada uma das entidades são os seguintes -
Processos
Processos são coleções de atividades relacionadas a software. A seguir estão alguns dos atributos internos que podem ser medidos diretamente para um processo -
A duração do processo ou uma de suas atividades
O esforço associado ao processo ou uma de suas atividades
O número de incidentes de um tipo especificado que surgem durante o processo ou uma de suas atividades
Os diferentes atributos externos de um processo são custo, controlabilidade, eficácia, qualidade e estabilidade.
Produtos
Produtos não são apenas os itens que a gerência está comprometida em entregar, mas também qualquer artefato ou documento produzido durante o ciclo de vida do software.
Os diferentes atributos internos do produto são tamanho, esforço, custo, especificação, comprimento, funcionalidade, modularidade, reutilização, redundância e correção sintática. Entre eles, o tamanho, o esforço e o custo são relativamente fáceis de medir do que os outros.
Os diferentes atributos de produtos externos são usabilidade, integridade, eficiência, testabilidade, reutilização, portabilidade e interoperabilidade. Esses atributos descrevem não apenas o código, mas também os outros documentos que suportam o esforço de desenvolvimento.
Recursos
Essas são entidades exigidas por uma atividade de processo. Pode ser qualquer entrada para a produção do software. Inclui pessoal, materiais, ferramentas e métodos.
Os diferentes atributos internos para os recursos são idade, preço, tamanho, velocidade, tamanho da memória, temperatura, etc. Os diferentes atributos externos são produtividade, experiência, qualidade, usabilidade, confiabilidade, conforto etc.
Determinando metas de medição relevantes
Uma determinada medição será útil apenas se ajudar a compreender o processo ou um de seus produtos resultantes. A melhoria no processo ou produtos pode ser realizada somente quando o projeto tiver metas claramente definidas para os processos e produtos. Uma compreensão clara dos objetivos pode ser usada para gerar métricas sugeridas para um determinado projeto no contexto de uma estrutura de maturidade de processo.
O paradigma Goal – Question – Metric (GQM)
A abordagem GQM fornece uma estrutura envolvendo as três etapas a seguir -
Listando os principais objetivos do projeto de desenvolvimento ou manutenção
Derivar as perguntas de cada meta que devem ser respondidas para determinar se as metas estão sendo cumpridas
Decida o que deve ser medido para poder responder às perguntas de forma adequada
Para usar o paradigma GQM, primeiro expressamos os objetivos gerais da organização. Em seguida, geramos as perguntas de forma que as respostas sejam conhecidas para que possamos determinar se os objetivos estão sendo alcançados. Posteriormente, analise cada pergunta em termos de qual medida precisamos para responder a cada pergunta.
Metas típicas são expressas em termos de produtividade, qualidade, risco, satisfação do cliente, etc. Metas e perguntas devem ser construídas em termos de seu público.
Para ajudar a gerar os objetivos, perguntas e métricas, Basili & Rombach forneceram uma série de modelos.
Purpose - Para (caracterizar, avaliar, prever, motivar, etc.) o (processo, produto, modelo, métrica, etc.) a fim de compreender, avaliar, gerenciar, projetar, aprender, melhorar, etc. Example: Caracterizar o produto para aprendê-lo.
Perspective - Examine o (custo, eficácia, correção, defeitos, mudanças, medidas do produto, etc.) do ponto de vista do desenvolvedor, gerente, cliente, etc. Example: Examine os defeitos do ponto de vista do cliente.
Environment - O ambiente consiste no seguinte: fatores de processo, fatores de pessoas, fatores de problema, métodos, ferramentas, restrições, etc. Example: Os clientes deste software são aqueles que não conhecem as ferramentas.
Medição e melhoria de processos
Normalmente, a medição é útil para -
- Compreender o processo e produtos
- Estabelecendo uma linha de base
- Acessando e prevendo o resultado
De acordo com o nível de maturidade do processo dado pela SEI, o tipo de medição e o programa de medição serão diferentes. A seguir estão os diferentes programas de medição que podem ser aplicados em cada um dos níveis de maturidade.
Level 1: Ad hoc
Nesse nível, as entradas são mal definidas, enquanto as saídas são esperadas. A transição da entrada para a saída é indefinida e não controlada. Para este nível de maturidade do processo, as medições de linha de base são necessárias para fornecer um ponto de partida para a medição.
Level 2: Repeatable
Nesse nível, as entradas e saídas do processo, restrições e recursos são identificáveis. Um processo repetível pode ser descrito pelo diagrama a seguir.
As medidas de entrada podem ser o tamanho e a volatilidade dos requisitos. A saída pode ser medida em termos de tamanho do sistema, os recursos em termos de esforço da equipe e as restrições em termos de custo e cronograma.
Level 3: Defined
Nesse nível, as atividades intermediárias são definidas e suas entradas e saídas são conhecidas e compreendidas. Um exemplo simples do processo definido é descrito na figura a seguir.
A entrada e a saída das atividades intermediárias podem ser examinadas, medidas e avaliadas.
Level 4: Managed
Nesse nível, o feedback das atividades iniciais do projeto pode ser usado para definir prioridades para as atividades atuais e, posteriormente, para as atividades do projeto. Podemos medir a eficácia das atividades do processo. A medição reflete as características do processo geral e da interação entre as atividades principais.
Level 5: Optimizing
Nesse nível, as medidas das atividades são usadas para melhorar o processo, removendo e adicionando atividades do processo e alterando a estrutura do processo dinamicamente em resposta ao feedback da medição. Assim, a mudança de processo pode afetar a organização e o projeto, bem como o processo. O processo atuará como sensores e monitores e podemos alterar o processo significativamente em resposta aos sinais de alerta.
Em um determinado nível de maturidade, podemos coletar as medidas para esse nível e todos os níveis abaixo dele.
Identificando o nível de maturidade
A maturidade do processo sugere medir apenas o que é visível. Assim, a combinação de maturidade de processo com GQM fornecerá medidas mais úteis.
Em level 1, é provável que o projeto tenha requisitos mal definidos. Nesse nível, a medição das características do requisito é difícil.
Em level 2, os requisitos são bem definidos e as informações adicionais, como o tipo de cada requisito e o número de mudanças em cada tipo, podem ser coletadas.
Em level 3, atividades intermediárias são definidas com critérios de entrada e saída para cada atividade
O objetivo e a análise da pergunta serão os mesmos, mas a métrica irá variar com a maturidade. Quanto mais maduro o processo, mais ricas serão as medições. O paradigma GQM, em consonância com a maturidade do processo, tem sido usado como base para diversas ferramentas que auxiliam os gestores na concepção de programas de medição.
O GQM ajuda a entender a necessidade de medir o atributo e a maturidade do processo sugere se somos capazes de medi-lo de maneira significativa. Juntos, eles fornecem um contexto para medição.