Identificando os elementos de dados

Para concluir a identificação de dados, basta fazer uma lista de todos os elementos de dados que são necessário recolher para construção dos indicadores sugerido na Seção3.2.6. Dando continuidade ao exemplo anterior (Figura3.4), é necessário a coleta das seguintes informações:

• Projeto ao qual pertence o defeito; • Classificação do defeito quanto ao tipo; • Data em que o defeito foi identificado.

Essa identificação se faz necessária, pois mapeia os elementos de dados para construção desse indicador. Do mesmo modo fazendo o mesmo para cada um dos indicadores criados, obtém-se um conjunto completo dos elementos de dados que devem ser coletados ao longo do processo de desenvolvimento. Até o momento, devido ao trabalho feito anteriormente, pode-se afirmar que cada um desses elementos corresponde a pelo menos uma proposta objetiva de medição, que por sua vez está alinhada com as metas de negócio da organização. Sendo este, o principal benefício trazido pelo Goal-Driven Software Measurement: a possibili- dade de mapear cada um dos elementos de dados com as metas que motivaram sua coleta. A Tabela3.9apresenta todos os elementos de dados que são necessários para a construção dos indicadores enumerados na Seção3.2.6.

Table 3.9: Elementos de dados identificados

Entidade Grupo Elemento de dado Indicadores

Conjunto de

ED-1 Estado do defeito; I-1

Defeito Classificação quanto ao tipo do defeito; I-2 Esforço

ED-2

Atividade por pessoa; I-3

Estado da atividade; I-7

Número de atividade; Produtividade por pessoa;

Planejamento e Acompanhamento

ED-3 Tamanho estimado do esforço por tarefa; I-4 Tamanho de esforço realizado por tarefa; I-5

ED-4

Distribuição de incertezas; I-6

Custo estimado; I-8

Custo realizado; I-9

Quantidade de itens que chegam; Quantidade de itens que encerram;

Para cada elemento de dado, a Tabela3.9informa na sua ultima coluna a relação dos indicadores para os quais contribui. As outras etapas do processo GQ(I)M foram omitida por estar voltada para situações em que a política de medição tem como foco uma organização específica, o que a torna incompatível com a natureza deste trabalho. A Figura3.5ilustra todas as etapas desse capitulo.

O próximo capítulo descreve o conjunto de indicadores como resultado desse método. Esses indicadores foram instanciados em uma base não real, sendo utilizados como uma fonte de dados para nosso estudo de caso do Capítulo5.

Método para Construção dos Indicadores 34 Metas de medição(5) 01 - Defeitos MT-01.01 MT-01.02 MT-01.03 02 - Esforço MT-01.05 MT-01.06 MT-02.01 MT-01.04 03 - Planejamento MT-02.01 MT-02.02 MT-02.04 MT-01.08 04 - Acompanhamento MT-02.02 MT-02.03 MT-01.07 Perguntas(6) Indicadores(6) Elementos de Dados(7) MT-01-GQ1 MT-02-GQ2 MT-03-GQ3 MT-04-GQ4

I-1 I-2 I-3 I-4 I-5 I-6 I-7 I-8 I-8

ED-1 ED-2 ED-3 ED-4

Metas de negócios(01) Questões levantadas (2) Submetas (3) MT-01 MT-02 Q1.1 Q1.2 Q1.3 Q1.4 Q1.5 Q1.6 Q1.7 Q1.8 Q2.1 Q2.2 Q2.3 Q2.4 MT-01.01 MT-01.2 MT-01.3 MT-01.4 MT-01.5 MT-01.6 MT-01.7 MT-01.8 MT-02.1 MT-02.2 MT-02.3 MT-02.4 Entidades e Atributos (4)

4

Conjunto de Indicadores

A proposta dessa dissertação é utilizar um conjunto de indicadores para auxiliar o gerente de projeto em suas atividades. Neste contexto, o conjunto de indicadores se torna uma ferra- menta para gestão de projetos, tornando eficaz na obtenção de evidências e ou informações, fornecendo diferentes dimensões do processo de desenvolvimento de software. Com isso, o gerente de projeto pode tomar decisões para alcançar as metas propostas. Entretanto escolher quais indicadores utilizar não é uma tarefa trivial, sendo este objeto de estudo. Nesse contexto, este dissertação propõe um conjunto de indicadores para o processo de desenvolvimento de software nas áreas de tempo e custo seguindo as boas praticas do PMBOK. Para a criação dos indicadores foi utilizada a técnica de GQ(I)M demostrando no Capítulo3com algumas adaptações, sendo também uma contribuição deste trabalho. Portanto, o método serviu como uma base para geração desses indicadores. Além disso, foi utilizada a expertise de dois engenheiros de software com experiências em gerência de projetos, um com oito anos e o outro com quatro anos. Os engenheiros de software auxiliaram nas etapas do método utilizado para a criação dos indicadores.

Na Seção3.2.6foi elaborado um conjunto de perguntas e são identificados vários indi- cadores que contribuem para a resposta a essas perguntas. Neste Capítulo iremos descrever e discutir os indicadores criados com as seguintes informações:

• Descrição – breve descrição da informação contida no indicador; • Ilustração – forma de apresentação do indicador;

• Aplicabilidade – descrição da contribuição trazida pelas informações contidas no indi- cador;

• Variações possíveis – descrição das diferentes formas de construção do indicador; • Perguntas - lista o grupo de perguntas que podem ser respondida pelo indicador.

Conjunto de Indicadores 36 Serão apresentados os 09 indicadores propostos na Seção3.2.6. As seções4.1a4.9apre- sentam a documentação de cada um deles.

4.1 Defeitos(Bloqueio) x Pedido

Distribuição por tempo(nesse caso é semanal) do total de pedidos que foi registrado e a quantidade de defeitos do tipo bloqueio. Com isso podemos saber, por exemplo, quantos são os defeitos que estão impactando em outros pedidos. A Figura5.2ilustra um exemplo desse indicador.

Figure 4.1: Indicador 01 (I-1) - Total de Defeitos(bloqueio) x Pedidos

Aplicabilidade O conhecimento da quantidade de defeitos que são de alta prioridade, pois estão impedindo o fechamento de uma determinada solicitação. A mitigação e o acompanhamento desses defeitos pode ser útil para guiar atividades de melhoria de processo que visam à redução dos defeitos e à detecção precoce dos mesmos. Além disso, a linha do total de defeitos(bloqueio) deve fazer uma curva para baixo. Uma curva para cima indicaria que o trabalho em um número crescente de requisitos está sendo atrasado.

Variações possíveis Esse indicador pode sofrer alterações, como: 1. Identificar Todos os defeitos registrados;

3. Mudar a dimensão tempo para mês ou dia.

Para cada uma das situações acima, há ainda duas opções: considerar defeitos perten- centes a um projeto individual, ou considerar um conjunto de projetos.

Perguntas - MT-0.1-GQ1.