Descrever o elemento do processo de software Objetivo: Descrever o elemento do processo de software.

Finalidade: Atribuir visibilidade ao processo de software progressivamente.

Como:

- Selecionar o elemento do processo de software de acordo com a estratégia de descrição definida no passo 1 dessa fase;

- Elaborar instrumentos de coleta de dados estruturados.

- Descrever o elemento do processo de software de acordo com a notação previamente definida na Fase de Definição de Padrões (Passo 2).

4.3.2 Instrumentos utilizados na descrição dos componentes do processo

O preenchimento e análise dos instrumentos de coleta de dados bem como a modelagem do processo com base nesses instrumentos será exemplificado somente uma vez para não tornar aplicação da abordagem repetitiva e extensa. Será apresentado um exemplo de cada instrumento com dados reais coletados durante a realização do estudo e as demais informações serão resumidas na seção seguinte. O preenchimento do Instrumento de coleta de dados sobre atividades inicia com a identificação da fonte (Agente entrevistado e observado), data e horário de início e término da coleta (vide Figura 31 – linha ‘A’). A identificação única da atividade observada, nesse caso, foi definida por meio de um nome único (linha ‘B’). A linha ‘C’ é utilizada para determinar a atividade de alto nível (uma fase do ciclo de vida, por exemplo) a qual está submetida à atividade descrita. Atividades complexas que demandam diversas ações distintas para cumprir um objetivo podem requerer sua divisão. Por exemplo, a atividade Engenharia de Requisitos poderia ser dividida em outras sub-atividades: Coleta, Análise, Modelagem, Verificação & Validação e Gerenciamento. Todas essas submissas à atividade de Engenharia de Requisitos.

A linha ‘D’ é utilizada para descrever, objetivamente, a atividade em questão. A linha ‘E’ é utilizada para classificar o tipo da atividade. Caso a atividade seja composta por mais de uma sub-atividade, essa é classificada como ‘Atividade’, caso contrário, a atividade não agrega outras atividades (atômica), é classificada como ‘Sub- atividade’. Atividades classificadas como sub-atividades devem, obrigatoriamente, ser submissas hierarquicamente a outra atividade (linha ‘C’). A linha ‘F’ depende da classificação da atividade descrita na linha ‘E’, ou seja, se a atividade é classificada como sub-atividade, essa é, portanto, tipo ‘Executável’. Atividades tipo ‘Executável’ são realizadas por agentes. Caso a atividade seja de alto nível (classificada como ‘Atividade’ na linha ‘E’), é tipo ‘Não-executável’. Atividades que agrupam outras atividades não são realizadas por agentes, apenas são utilizadas para agrupar um conjunto de sub-atividades com o objetivo, por exemplo, de organizar ou diminuir a complexidade. Normalmente, atividades ‘Não-executáveis’ são fases do ciclo de vida do desenvolvimento do software.

Figura 31: Instrumento de coleta de dados 7 (atividades) aplicado no estudo de caso.

A Fonte: Agente 1

Data Coleta: 02/09/2002

Hora início: 14:00 Hora término: 18:00 Propriedades Descritivas (“Perspectiva Informacional”)

B _{Identificador: Atendimento}

C _{Hierarquia: 1. Não está submissa a outra atividade} D _Descrição:

Atividade responsável pelo registro, análise e encaminhamento de solicitações (Ocorrências) de clientes no que se refere a erros do software, adição de novas funcionalidades, orientação a clientes etc.

E _{Classificação:} ⌧ Atividade Sub-Atividade

F _Tipo: Atividade Executável ⌧ Atividade Não executável

G _{Procedimento(s):}

1. Preencher todos os dados da solicitação;

3. Identificar o usuário e funcionário que registrou a solicitação; 4. Encaminhar a solicitação ao agente responsável;

5. Definir a prioridade da solicitação;

6. Retornar ao usuário solicitante sobre os encaminhamentos;

H _{Subatividades:} 1. Registrar Solicitação; 2. Classificar Solicitação; 3. Analisar Ocorrência; 4. Retornar Feedback; 5. Gerenciar Tarefa.

I _Meta(s): 1. Registrar corretamente as solicitações e encaminhar a ocorrência.

Propriedades Estáticas (Perspectiva Funcional e Organizacional)

J Atividade / Artefato Solicitação Ocorrência Feedback Controle de Tarefa

Registrar Solicitação Consumido Produzido

Classificar Ocorrência Consumido

Analisar Ocorrência Modificado

Retornar Feedback Consumido Produzido

Atualizar Ocorrência Modificado

Controlar Tarefa Consumido Consumido Consumido Produzido

L Papéis: Atendente e Cliente/usuário; M Fluxo de entrada entre atividades: Não possui

N Fluxo de saída entre atividades: 1. Implementação 2. Gerência de tarefas

O Ferramentas: Gerenciador de Ocorrência, Gerenciador de E-mail e Gerenciador de Tarefas.

Propriedades Dinâmicas (Perspectiva Comportamental) CRITÉRIOS DE ENTRADA

P _{Atividade / Artefato Solicitação do Cliente Ocorrência Feedback Controle de Tarefa} Registrar Solicitação Dados da solicitação

Classificar Ocorrência Registrada

Analisar Ocorrência Classificada

Retornar Feedback Analisada

Atualizar Ocorrência Encaminhada

Controlar Tarefa Preenchida Encaminhada Preenchido

CRITÉRIOS DE SAÍDA

Q _{Atividade / Artefato Solicitação Ocorrência Feedback Controle de Tarefa}

Registrar Solicitação Registro completo

Classificar Ocorrência Classificada

Analisar Ocorrência Analisada

Retornar Feedback Encaminhada Usuário informado

Atualizar Ocorrência Encaminhada

Controlar Tarefa Consumido Consumido Usuário informado Registro completo R _{Estados possíveis da atividade: Em espera, Cancelada e Finalizada.}

Os procedimentos a serem realizados na atividade são relacionados na linha ‘G’. O fato de serem listados numericamente não indica necessariamente a ordem de execução, no entanto, sinalizam que todos os itens relacionados devem ser cumpridos pelo agente para que a atividade seja concluída. Na linha ‘H’ são relacionadas as sub-atividades (caso a atividade descrita seja classificada como ‘Atividade’ (linha ‘E’) da atividade. A numeração das sub-atividades também não indica ordem de execução. O resultado global da atividade descrita é delineado na linha ‘I’, ou seja, o que se espera da atividade após finalizada.

Na linha ‘J’ (que envolve mais de uma linha dependendo do número de sub-atividades pertencentes à atividade descrita, portanto, o número de linha e coluna pode variar conforme a atividade) são descritas na forma de uma matriz a relação ‘Atividade x Artefato’. A relação entre esses dois elementos pode ser classificada em três tipos: produzido (artefato produzido pela atividade), consumido (artefato utilizado na execução da atividade) ou modificado (artefato utilizado e modificado pela atividade). Os agentes envolvidos na atividade são relacionados na linha ‘L’. Na linha ‘M’ são relacionados os fluxos de entradas da atividade descrita. No caso do exemplo, a atividade de Suporte é a primeira atividade do ciclo de vida da empresa e, portanto, não possui fluxo de entrada. As saídas para outras atividades são relacionadas na linha ‘N’ (os números não indicam seqüência). Na linha ‘O’ são descritas todas as ferramentas utilizadas na execução da atividade. São consideradas ferramentas: ferramentas automatizadas (CASES e não CASES), hardware (por exemplo, estação de teste, máquinas executando sistemas operacionais diferentes etc).

Os critérios que determinam o início e término de uma atividade são registrados nas linhas ‘P’ e ‘Q’ respectivamente. As informações são dispostas na forma de matriz. Nesse estudo de caso, os critérios foram baseados na relação atividade – artefato. No entanto, os critérios de entrada e saída podem abranger a relação entre outros elementos do processo de software. Além disso, o critério (seja ele de entrada ou saída) deve ser adequadamente especificado para evitar interpretações equivocadas. Por exemplo, a primeira relação na linha ‘P’ (entre a atividade Registrar solicitação e o artefato Solicitação do cliente) da Figura 31 indica “Dados da solicitação” como critério de entrada. Entretanto, quais são os dados? Quais informações são obrigatórias? Essas

questões não podem ficar sem respostas. Dessa forma, ao descrever o processo de software, os critérios de entrada e saída também devem ser especificados no Guia de Processo de Software. Finalmente, na linha ‘R’ são descritos os possíveis estados da atividade. Os estados também devem ser detalhados no Guia de Processo de Software para definir exatamente quando uma atividade entra ou sai de um determinado estado.

Após a descrição das atividades e sub-atividades da Etapa de Suporte (seguindo a ordem de descrição dos elementos do processo de software do estudo de caso: atividades/sub-atividades, artefatos, papéis e ferramentas) foi iniciado a descrição dos artefatos. Foi utilizado o instrumento 9. A Figura 32 apresenta um exemplo do instrumento aplicado ao artefato Ocorrência.

Figura 32: Instrumento de coleta de dados 8 (artefatos) aplicado no estudo de caso.

A _{FONTE: BANCO DE DADOS DE OCORRÊNCIAS}