Passo: Definição das Atividades do Processo

Cada uma das atividades contida nos subprocessos do PGIGR (Tabela 3) foi detalhada utilizando o template de atividades proposto pela SOFTEX (2007), conforme apresentado na Tabela 17 do APÊNDICE A.

O detalhamento da criação dos subprocessos e suas respectivas atividades está descrito nas seções subsequentes.

3.5.3.1. Subprocesso: Categorizar o Processo de Software da organização de TI

Este subprocesso foi elaborado com o intuito de proporcionar uma categorização do processo de desenvolvimento de software da organização de TI avaliando algumas características que são fundamentais para que a criação de indicadores seja feita de forma correta.

Para a elaboração deste subprocesso foram utilizados conceitos propostos por Solingen e Berghout (1999, p. 21), visando complementar o processo GQM. Segundo os autores, a medição em processos de software tem como objetivo prover informações que podem ser aplicadas em três diferentes aspectos:

1. Adquirir melhor entendimento das necessidades. 2. Permitir maior controle do processo e produtos gerados. 3. Permitir o aprimoramento do processo existente.

O PGIGR adaptou esse conceito proposto por Solingen e Berghout (1999) com o intuito de avaliar alguns aspectos (características) do processo de software das organizações de TI antes de definir os indicadores. O objetivo é melhor direcionar a geração de indicadores para a gestão de requisitos, de acordo com algumas características do processo de desenvolvimento de

software da organização de TI, pois, segundo Jones (1992), um dos grandes problemas na

definição de indicadores é falta de uma contextualização da situação atual da organização. Para isso, o PGIGR propõe quatro categorias de classificação: Inicial, Entendimento, Controle e Aprimoramento, conforme pode ser visualizado na Figura 13.

Figura 13 - Categorias de Classificação do Processo de Software da Organização de TI (Adaptada de Solingen e Berghout, 1999)

A estrutura proposta visa permitir um melhor entendimento do processo de desenvolvimento de software da organização para então direcionar a geração de indicadores. Como exemplo, pode-se dizer que não adianta uma organização querer definir indicadores para aprimorar o seu processo de gerência de requisitos se ela não possui o mínimo de organização e infra-estrutura necessárias para tal. Isso provavelmente acarretaria na geração de informações ambíguas e inconsistentes. Ela também possibilita uma evolução gradual da organização quanto a utilização de indicadores para uma correta gestão de requisitos.

Esta etapa do processo visa evitar com que a organização defina um conjunto de indicadores que estão além do que o seu processo atual e/ou infra-estrutura podem suportar.

Este subprocesso é composto por duas atividades: Definir os Envolvidos e Definir

Categoria. Na Figura 14 é apresentado o diagrama do subprocesso contendo as atividades,

artefatos e responsabilidades. O processo (APÊNDICE A) apresenta o detalhamento de cada uma das atividades.

Figura 14 - Subprocesso para Categorizar o Processo de Software da Organização de TI

O conceito, empregado nesta pesquisa para de classificar o processo de desenvolvimento de software da organização de TI, baseou-se em áreas de processo do CMMI (2001) e do MPS.BR (SOFTEX, 2007). Para cada uma das categorias foram definidas características baseadas em práticas que são empregadas em ambos os processos supracitados e que se mostraram importantes para a geração de indicadores para a gerência de requisitos. As características definidas para cada categoria podem ser visualizadas a seguir na Matriz de Categorização - Tabela 4.

Tabela 4 - Matriz de Categorização do processo de software da Organização de TI

CATEGORIZAR O PROCESSO DE SOFTWARE DA ORGANIZAÇÃO DE TI

1º - INICIAL 2º - ENTENDIMENTO 3º - CONTROLE 4º - APRIMORAMENTO

A organização não possui os requisitos necessários para se enquadrar na categoria Entendimento A organização possui práticas de gerência de projetos de desenvolvimento de software; e A organização possui ferramenta para controle de atividades dos projetos. (Ex.: Microsoft Project); e A organização possui práticas de gerência de requisitos; e A organização utiliza práticas e ferramentas de controle de versão para os artefatos de requisitos; e A organização possui práticas de medição de tamanho de software. A organização possui uma base histórica de métricas e indicadores; e A organização possui um processo padronizado de gerência de requisitos; e A organização possui um processo padronizado de gerência de projetos A organização possui um baseline de desempenho do processo de requisitos;

Os indicadores gerados na categoria Entendimento têm o intuito de dar uma visibilidade e maior entendimento da situação atual dos projetos de desenvolvimento de software da organização no que tange à gestão de requisitos. Para que a organização ingresse nessa categoria, foram coletadas algumas práticas das áreas de processo do nível 2 de maturidade (Gerenciado) do CMMI (2001) e do nível G (Parcialmente Gerenciado) do MPS.BR, visando garantir a existência de um mínimo de organização para sustentar um processo consistente de geração e manutenção de indicadores para gerenciar requisitos. As características definidas para a categoria Entendimento foram:

1. A organização possui práticas de gerência de projetos de desenvolvimento de

software

Esta característica é necessária para criar insumos para fonte de coleta de várias medidas básicas e derivadas que são utilizadas nos indicadores propostos. Visa-se constatar evidências que demonstrem que a organização possui práticas de gerência de projetos no seu processo de desenvolvimento de software. Ela se baseia em práticas da área de processo de Gerência de Projetos contida no nível 2

de maturidade do CMMI (2001) e do nível G (Parcialmente Gerenciado) do MPS.BR (SOFTEX, 2007).

2. A organização de TI possui ferramenta para controle de atividades dos projetos (Ex.: cronograma)

Esta característica objetiva constatar evidências de utilização de uma ferramenta de controle de atividades para gerenciar projetos de desenvolvimento de software. Esta característica é necessária porque a ferramenta de controle de atividades é a fonte de coleta de várias medidas básicas e derivadas que são utilizadas nos indicadores propostos. Ela se baseia em práticas da área de processo de Gerência de Projetos contida no nível 2 (Gerenciado) de maturidade do CMMI (2001) e do nível G (Parcialmente Gerenciado) do MPS.BR (SOFTEX, 2007). Um dos resultados esperados pelo MPS.BR neste nível é o orçamento e o cronograma do projeto, no qual marcos e/ou pontos de controle são estabelecidos e mantidos (GPR5).

3. A organização possui práticas de gerência de requisitos

Esta característica é necessária por quanto é preciso ter atividades de requisitos planejadas, pois elas servirão de insumo para coleta de medidas básicas do processo de requisitos. Visa-se constatar evidências da existência de práticas de gerência de requisitos nos projetos de desenvolvimento de software. Esta característica está embasada em práticas da área de processo de Gerência de Requisitos, contida no nível 2 (Gerenciado) de maturidade do CMMI (2001) e no nível G (Parcialmente Gerenciado) do MPS.BR (SOFTEX, 2007). O propósito do processo Gerência de Requisitos é gerenciar os requisitos dos produtos e componentes do produto do projeto e identificar inconsistências entre os requisitos, os planos do projeto e os produtos de trabalho do projeto.

4. A organização utiliza práticas e ferramentas de controle de versão para os artefatos de requisitos

Esta característica é necessária porque vários indicadores utilizam o quantitativo de alterações em artefatos de requisitos como medida derivada, o que tornaria praticamente inviável a coleta dessas informações sem uma ferramenta adequada de controle de versões. Aqui visa-se constatar evidências da utilização de uma ferramenta e práticas de controle de versão nos projetos de desenvolvimento de

software. Esta característica está embasada em práticas da área de processo de

Gerência de Configuração contida no nível 2 (Gerenciado) de maturidade do CMMI (2001) e no nível F (Gerenciado) do MPS.BR (SOFTEX, 2007). O nível F do MPS.BR tem como uma das áreas de processo a Gerência de Configuração. O propósito do processo de Gerência de Configuração é estabelecer e manter a integridade de todos os produtos de trabalho de um processo ou projeto e disponibilizá-los a todos os envolvidos.

5. A organização possui práticas de medição de tamanho de software

Foi constatado que alguns indicadores ficam muito vagos e ineficientes caso não tenham como medida derivada um indicativo de tamanho do software. Visa-se constatar evidências da utilização de técnicas de mensuração de tamanho do

software nos projetos de desenvolvimento de software. Esta característica está

embasada em prática da área de processo de Medição contida no nível 2 de maturidade (Gerenciado) do CMMI (2001) e no nível F (Gerenciado) do MPS.BR (SOFTEX, 2007). O propósito do processo Medição é coletar, analisar e relatar os dados relativos aos produtos desenvolvidos e aos processos implementados na organização e em seus projetos, de forma a apoiar os objetivos organizacionais.

Caso a organização não possua todas as características listadas acima para ingressar na categoria de Entendimento (segunda), o PGIGR sugere que a organização ajuste o seu processo de desenvolvimento de software para atendê-las, antes de ingressar na categoria, ficando, a princípio, na categoria Inicial (primeira), conforme representado na Figura 13 e Tabela 4 acima. Isso porque as características definidas como necessárias pelo PGIGR objetivam avaliar a existência de um conjunto mínimo de organização e padronização para que haja fontes para uma correta coleta de medidas básicas e derivadas, que são insumos fundamentais para que os indicadores propostos possam ser gerados de forma consistente.

Vale ressaltar que o fato da organização não possuir todas as características exigidas pela categoria Entendimento não significa que ela não conseguirá gerar alguns indicadores propostos. Talvez seja possível gerar alguns indicadores, porém a organização corre o risco de despender um esforço muito grande para gerá-los e mantê-los, além de correr o risco de gerar informações inconsistentes e ambíguas.

Os indicadores gerados na Categoria Controle têm o intuito de serem utilizados durante a execução do projeto, permitindo que o gerente tenha maior controle do projeto e possa tomar

medidas corretivas durante a execução do mesmo. Para que a organização ingresse nessa categoria, foram utilizados conceitos do nível 3 de maturidade (Definido) do CMMI (2001) e do nível E (Parcialmente Definido) do MPS.BR (SOFTEX, 2007). Neste ponto, o PGIGR procura aferir se a organização possui um repositório com medidas históricas coletadas a partir da execução de projetos na categoria Entendimento, assim como a padronização de alguns processos. As características definidas para esta categoria Controle são:

1. A organização possui uma base histórica (repositório de medidas) de métricas e indicadores

O intuito é que haja um conjunto de medidas previamente coletadas durante a categoria de Entendimento para que se possa gerar dados comparativos entre projetos que apresentam semelhanças, visando gerar gráficos de controle com limites superior e, conforme exemplos apresentados no Quadro 2 do referencial teórico. Esta característica está embasada na área de processo de gerência de projetos do MPS.BR (SOFTEX, 2007). Um dos produtos esperados da gerência de projetos para o nível E (Parcialmente Definido) é a definição de um repositório de medidas da organização (DFP6). O repositório de medidas da organização deve ser, continuamente, atualizado com dados dos projetos executados na categoria Entendimento, para que, na categoria de Controle, dados históricos sejam utilizados em novos projetos. Como critério de avaliação visando migrar para a categoria Controle do PGIGR, sugere-se um quantitativo de métricas de gerência de requisitos coletadas a partir de três projetos similares (mesma tecnologia, mesmo método de desenvolvimento e complexidade) e, preferencialmente, já concluídos.

2. A organização possui um processo padronizado de gerência de requisitos

O PGIGR propõe que a organização tenha um processo padrão para gerenciar requisitos, antes de ingressar na categoria de Controle. Isso se faz necessário para que a organização colete medidas básicas e derivadas que sejam equivalentes, o que possibilita uma correta e efetiva comparação entre os indicadores gerados, já que os mesmo são resultado de um processo equivalente. Esta característica está embasada no nível E (Parcialmente Definido) de maturidade do MPS.BR (SOFTEX, 2007). A implementação do nível E numa organização tem como foco principal a padronização dos processos da organização, através da definição de processos padrão.

O PGIGR propõe que a organização tenha um processo padrão de gerenciamento de projetos antes de ingressar na categoria de Controle. Isso se faz necessário para que a organização colete medidas básicas e derivadas que sejam equivalentes, o que possibilita uma efetiva comparação entre os indicadores gerados na categoria controle, já que os mesmo são resultado de um processo equivalente. Esta característica está embasada no nível E (Parcialmente Definido) de maturidade do MPS.BR (SOFTEX, 2007). Assim como para a gerência de requisitos, é importante que a organização também padronize o seu processo de gerência de projetos.

O objetivo da categoria Aprimoramento é permitir que uma organização avalie a evolução da gestão de requisitos a partir de aprimoramentos realizados no processo de desenvolvimento de software. Os indicadores gerados nesta categoria darão uma visão do comportamento do processo antes e depois das medidas de aprimoramento. Isso sugere que esses indicadores deverão ser avaliados após a conclusão dos projetos.

Segundo KULPA e JOHNSON (2004), oobjetivo dos modelos de desempenho é permitir a previsão de desempenho futuro dos processos a partir de outros atributos do processo ou produtos. Estes modelos descrevem relacionamentos entre atributos do processo e produtos de trabalho. Modelos de desempenho são utilizados principalmente nas estimativas que servem de base para o planejamento e na monitoração dos projetos.

Os conceitos empregados nesta categoria foram extraídos do nível 4 de maturidade (Gerenciado Quantitativamente) do CMMI (2001) e nível B (Gerenciado Quantitativamente) do MPS.BR. Um dos produtos esperados pelo nível B (Gerenciado Quantitativamente) do MSP.BR é a utilização dos resultados históricos do seu desempenho (baseline). Neste ponto, o PGIGR procura aferir se há um baseline com a qual o desempenho dos projetos atuais pode ser comparado. A característica definida para a categoria Aprimoramento é:

1. A organização possui baseline de desempenho do processo de requisitos

O PGIGR sugere que a organização tenha aproximadamente 20 medições distintas dos indicadores em seu baseline, antes de passar para a categoria de Aprimoramento. Isso permitirá que alterações feitas no processo possam ser aferidas e comparações estatísticas possam ser feitas a partir de medidas coletadas na categoria de Controle e armazenadas. Esta característica está embasada em um

dos produtos esperados pelo nível B (Gerenciado Quantitativamente) do MPS.BR (SOFTEX, 2007).

Para facilitar a visualização do processo de categorização da organização, o PGIGR apresenta a Figura 24 do APÊNDICE A. Trata-se de uma espécie de fluxograma, onde é possível ter uma visão macro da sequência das etapas de categorização do processo de desenvolvimento de software da organização de TI pode ser melhor visualizada.

3.5.3.2. Subprocesso: Definir Foco dos Indicadores

Esse subprocesso foi criado com o intuito de direcionar a organização para aspectos determinantes no que tange a criação de indicadores. O PGIGR adaptou conceitos propostos por Solingen e Berghout (1999, p. 11 - 17), no qual os autores indicam que a definição de objetivo para o aprimoramento do processo de desenvolvimento de software através de medições pode possuir quatro vertentes distintas: risco, custo, tempo e qualidade.

Partindo desse princípio, o PGIGR adaptou a ideia original e criou o conceito de

dimensões foco (Figura 15), com o intuito de melhor direcionar o foco da geração de

indicadores naquilo que a organização considera mais relevante, de acordo com suas principais necessidades e características.

O PGIGR propõe que a organização deve avaliar suas características, necessidades e questionar o que é mais prioritário para ela no que tange a gestão de requisitos, de acordo com a sua categorização (classificação), definida no subprocesso anterior.

Para este subprocesso foi definida uma única atividade: Definir Dimensão Foco. Na Figura 16 é apresentado o diagrama do subprocesso com a atividade, artefatos e responsabilidades. No processo PGIGR (APÊNDICE A) é apresentado o detalhamento da atividade.

Com o intuito de facilitar a análise e definição da escolha da dimensão foco que será utilizada, o PGIGR apresenta uma matriz contendo cada uma das dimensões foco e uma descrição para cada uma das categorias, conforme apresentado na Tabela 5. Isso facilita para os usuários do processo, pois eles conseguem mais fácil e rapidamente definir qual deve ser o foco de seus indicadores, de acordo com aquilo que for definido como prioritário pela organização.

Tabela 5 - Matriz contendo as dimensões foco e descrição para cada uma das categorias

Dimensão Foco Categoria Descrição

R I S C O

Entendimento A organização necessita melhor entender os riscos relacionados à

gerência de requisitos nos projetos de software.

Controle A organização necessita melhor monitorar os riscos relacionados à

gerência de requisitos nos projetos de software.

Aprimoramento A organização deseja minimizar os riscos relacionados à gerência de

requisitos nos projetos de software.

T EM P O

Entendimento A organização necessita melhor entender o tempo/esforço despendido

nas atividades de requisitos em projetos de software.

Controle A organização necessita melhor monitorar o tempo/esforço despendido

nas atividades de requisitos em projetos de software.

Aprimoramento A organização deseja reduzir o tempo/esforço despendido nas

atividades de requisitos em projetos de software.

CUST

O

Entendimento A organização necessita melhor entender os custos despendidos nas

atividades de requisitos em projetos de software.

Controle A organização necessita melhor monitorar os custos despendidos nas

atividades de requisitos em projetos de software.

Aprimoramento A organização deseja reduzir os custos despendidos nas atividades de

requisitos em projetos de software.

Q U A

L

I

D A D

E _Entendimento A organização necessita melhor entender a qualidade dos produtos

gerados pelas atividades de requisitos em projetos de software.

Controle A organização necessita melhor monitorar a qualidade dos produtos

gerados pelas atividades de requisitos em projetos de software.

Aprimoramento A organização deseja aprimorar a qualidade dos produtos gerados

pelas atividades de requisitos em projetos de software.

3.5.3.3. Subprocesso: Definir Objetivos (Metas)

A criação desse subprocesso visa definir os objetivos (metas) para a dimensão foco previamente selecionada, de acordo com a categorização da organização de TI.

Para este subprocesso foram criadas duas atividades: Selecionar Objetivo(s) pré-

definido(s) para a Gerência de Requisitos e Criar Objetivo(s). Na Figura 17 é apresentado o

diagrama do subprocesso com as atividades, artefatos e responsabilidades. O APÊNDICE A apresenta o detalhamento de cada uma das atividades.

Subprocesso – Definir Objetivos (Metas)

Definir Objetivos (Meta) Legenda Objetivo não selecionado Objetivo(s) Definido(s) Papéis:zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz GP – Gerentes de Projetos AM – Analista de Métricas EP – Engenheiro de Processo AR – Analista de Requisitos Artefatos: zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz

MTO – Matriz contendo os objetivos para cada categoria e dimensão foco OBJ - Objetivo(s) DMF - Dimensão Foco Criar Objetivo(s) GP AM EP AR Selecionar Objetivo(s) pré-definido(s) para a Gestão de Requisitos GP AM EP AR Dimensão Foco Definida Símbolos

Início ou fim do processo Atividades do processo Papel Produto requerido Produto gerado MTO DMF MTO OBJ OBJ Objetivo Selecionado

Figura 17 - Subprocesso para Definir Objetivos (Metas)

Esta etapa do processo utiliza os conceitos originalmente apresentados pelo GQM (BASILI, CALDIERA e ROMBACH, 2002), que também possui a etapa de definição de objetivos. Complementarmente, o PGIGR apresenta uma matriz (Tabela 6) onde cada uma das categorias (Entendimento, Controle e Aprimoramento) foi cruzada com cada uma das dimensões foco (Tempo, Custo, Qualidade e Risco). Para cada categoria/dimensão foco foi definido no PGIGR um objetivo específico para a gerência de requisitos. A organização pode utilizar os objetivos propostos, pode adequá-los às suas necessidades ou pode criar novos. Essa matriz visa facilitar e agilizar a escolha de objetivos, já que apresenta um conjunto pré-definido de acordo com cada categoria e dimensão foco, minimizando as chances da organização definir objetivos de forma equivocada, pois direciona os usuários do processo.

Tabela 6 - Matriz contendo sugestões de objetivos (metas) para cada categoria e dimensão foco

OBJETIVOS (Metas)

Categoria Dimensão Foco

ENTENDIMENTO CONTROLE APRIMORAMENTO

TEMPO (T)

Conhecer o esforço e/ou prazo necessário para executar as atividades de requisitos. (Meta T1)

Monitorar e controlar se o esforço e/ou prazo das atividades de requisitos estão dentro dos valores estipulados. (Meta T2)

Reduzir o esforço e/ou prazo para executar as atividades de requisitos. (Meta T3)

CUSTO (C)

Conhecer o custo

despendido para executar as atividades de requisitos. (Meta C1)

Monitorar e controlar se os custos das atividades de requisitos estão dentro dos valores estipulados. (Meta C2)

Reduzir os custos das atividades de requisitos. (Meta C3)

QUALIDADE (Q) Conhecer a qualidade dos _{artefatos de requisitos.}

(Meta Q1)

Monitorar e controlar se a qualidade dos artefatos de requisitos está dentro dos valores estipulados. (Meta Q2)

Aprimorar a qualidade dos artefatos de requisitos e minimizar retrabalho. (Meta Q3) RISCO (R) Entender os riscos relacionados ao gerenciamento de requisitos (Meta R1) Monitorar e controlar os riscos relacionados ao gerenciamento dos requisitos (Meta R2) Reduzir os riscos relacionados ao gerenciamento dos requisitos (Meta R3)

Com o intuito de possibilitar uma rastreabilidade entre os indicadores e objetivos, foi definida uma forma de identificação do objetivo, no qual o mesmo inicia com a primeira letra, que representa a da dimensão foco, e tem um seqüencial numérico, de acordo com o quantitativo de objetivos criados. Isso pode ser visualizado nos parênteses apresentados na Tabela 6.

3.5.3.4. Subprocesso: Definir Perguntas

O objetivo deste subprocesso é definir as perguntas para o aferir se os objetivos (metas) previamente traçados foram ou não atendidos.

Para este subprocesso foram criadas duas atividades: Selecionar Perguntas pré-definidas e Criar Pergunta(s). Na Figura 18 é apresentado o diagrama do subprocesso com as atividades, artefatos e responsabilidades. O processo apresenta o detalhamento de cada uma das atividades.