Modelo descritivo de processo de software

BECKER-KORNSTAEDT (2001) apresenta uma abordagem para modelagem descritiva de processo de software desenvolvida em pesquisas no Instituto Experimental de Engenharia de Software (IESE – Institute for Experimental Software

Engineering). A abordagem apresenta três passos genéricos (Figura 19): coleta de conhecimentos do processo, criação do modelo e revisão.

Figura 19: Passos do modelo descritivo de processo de software do IESE.

Coleta de conhecimentos do processo Criação do modelo Revisão Comunicação Modelagem Descritiva do processo de software Melhoria Mensuração ... Processo atual

Propósi tos do modelo

Coleta de conhecimentos do processo Criação do modelo Revisão Comunicação Modelagem Descritiva do processo de software Melhoria Mensuração ... Processo atual

Propósi tos do modelo

Fonte: BECKER-KORNSTAEDT (2001, p. 314).

No primeiro passo são coletadas informações sobre atividades, artefatos, papéis, ferramentas, fluxos entre atividades, fluxo de artefatos, utilização de ferramentas e papéis envolvidos durante a execução do processo. No segundo passo, as

informações coletadas são utilizadas na formalização do modelo de processo atual e, finalmente, no terceiro passo, são conduzidas revisões no modelo descritivo criado. A abordagem também prevê ciclos de retorno ao passo 1 quando, por exemplo, faltam informações ao criar o modelo (passo 2) ou quando o modelo mostra-se incompleto ou incorreto no passo 3. O detalhamento dos três passos genéricos do modelo dependerá dos propósitos da modelagem, nível de detalhamento desejado e/ou intenções dos usuários do modelo de processo de software. As seções seguintes apresentarão brevemente os resultados de dois estudos nos quais o modelo genérico foi refinado.

Estudo 4: DaimlerChrysler

BECKER-KORNSTAEDT & BELAU (2000) relatam o estudo conduzido na Divisão de Infraestrutura Espacial da DaimlerChrysler Aeroespacial AG (Dasa). Nesse estudo, o modelo genérico foi refinado em oito fases:

Fase Objetivo Definição dos

objetivos e escopo

Definição do escopo da modelagem de atividades, características do modelo e contexto organizacional da modelagem de atividades. Além disso, é determinado o nível de visibilidade do processo de acordo com os interesses dos usuários do modelo de processo.

Seleção ou desenvolvimento de

um esquema de modelagem

Identificar e definir a estrutura das informações a serem coletadas pelo modelo bem como os relacionamentos entre essas entidades de informação. Essa fase deve estar alinhada aos objetivos e escopo definidos na fase anterior.

Seleção de linguagem

Determinar a notação por meio da qual o modelo de processo será descrito.

Seleção de ferramentas

Selecionar uma linguagem para modelagem que suporte o formalismo definido na fase anterior.Editores gráficos podem ser empregados para representar o modelo de processo.

Coleta de conhecimento do processo

Adquirir todas as informações necessárias para descrever o processo. Os meios de aquisição de informações podem ser entrevistas, observações e análise de documentos e produtos do processo.

Criação do modelo Classificar, organizar e interpretar as informações coletadas para criar o modelo de processo de software. Diversas iterações são realizadas até os participantes concordarem com o modelo de processo criado. Se necessário, visões do processo são criadas para atender aos pontos de vista de cada usuário ou grupo de usuário do processo.

Análise do modelo de processo

Verificar o modelo de processo criado para averiguar sua completitude, exatidão e consistência.

Análise do processo Utilizar o modelo de processo descrito para verificar a fidelidade do modelo de processo em relação ao processo real.

A descrição do processo de software ocorreu, principalmente, por meio de entrevistas estruturadas (formulários estruturados). Foram estabelecidas duas entrevistas com duração máxima de duas horas para cada participante do processo de software as quais permitiram descrever atividades, artefatos, critérios de entrada/saída e papéis. Foram entrevistados sete participantes durante três dias consecutivos totalizando noventa minutos de entrevistas. Adicionalmente, foram consultadas documentações geradas durante o processo de desenvolvimento.

As informações coletadas, incluindo os questionários e consultas a documentos da organização, foram descritas em um arquivo texto. As informações fragmentadas nos questionários foram agrupadas por elementos do processo de software (atividades, sub-atividades, artefatos etc). O texto resultante permitiu a identificação de e correção de inconsistências (os entrevistados por diversas vezes se referiam ao mesmo elemento do processo de software com diferentes nomes). Além disso, foi observado que ocorria variações na execução de determinados processos, por exemplo, determinadas sub-atividades ocorriam apenas em determinados tipos de projetos.

A primeira versão do modelo descritivo do processo apresentou seis fases, 20 artefatos, 26 atividades, diversas sub-atividades e papéis para cada atividades (no estudo não foi explicitado o número de sub-atividades e papéis descritos). A versão do modelo foi enviada para avaliação da pessoa responsável pelo acompanhamento do estudo na empresa o qual apresentou sugestões que foram incorporadas gerando, desse modo, a segunda versão do modelo descritivo. Um novo ciclo de entrevistas foi realizado e mudanças foram incorporadas ao modelo. A fidelidade do modelo descritivo foi atestada pelo acompanhamento da execução do processo real. A comparação do modelo descrito com o processo real resultou nas seguintes observações: (1ª) variações no processo de software executado entre diferentes equipes e, (2ª) reincidência de atividades/sub-atividades em diferentes fases indicando a dificuldade em definir os limites entre as fases.

Diversas lições foram apresentadas pelos autores a partir do estudo conduzido na DASA. A limitação de bibliografia relacionada à descrição de processo de software dificultou a aquisição de informações e/ou experiências que poderiam ser

incorporadas ao estudo sugerindo, portanto, a necessidade de mais pesquisas nessa área. Uma única fonte de dados pode não ser suficiente para desenvolver um modelo descritivo de processo de software sendo, necessário, que diferentes fontes sejam utilizadas: artefatos, entrevistas de executores do processo, observação do processo de software real em execução ao entrevistar o executor do processo de software, considerar os diferentes papéis desempenhados durante o processo e, se possível, em diferentes projetos.

O conhecimento sobre o processo de software relatado pelos entrevistados, muitas vezes, diferenciava-se da prática, sugerindo, portanto, que a descrição do modelo de processo de software seja realizada por uma pessoa neutra (externa ao processo). O tempo gasto em entrevistas pela pessoa responsável pela descrição do processo pode ser reduzido se houver um conhecimento geral antecipado do processo, por exemplo, pela consulta a documentos e entrevista de um único executor do processo que tenha uma visão geral do processo de software para esclarecimentos pontuais. Essa constatação indica que a coleta de dados poderia ser realizada em duas etapas: entrevista preparatória que resultaria em uma visão geral do processo e, entrevista detalhada para obter dados mais específicos do processo de software. Essa abordagem para coleta de dados é particularmente interessante pelo fato dos executores nem sempre disporem de muito tempo para entrevistas.

Finalmente, a descrição do modelo de processo de software por meio de texto (linguagem natural) foi útil por facilitar a compreensão do modelo descritivo pelos executores do processo, entretanto, dificultou a verificação de inconsistências e análise de dados. Assim, o modelo descritivo de processo de software poderia ser realizado de duas formas: em linguagem natural para facilitar a compreensão dos executores do processo e, em linguagem mais formal, por exemplo, utilizando uma notação gráfica.

Estudo 5: Thales

O estudo (BECKER-KORNSTAEDT, NEU & HIRCHE, 2001) foi realizado na subsidiária alemã da Thales, cujas atividades estão voltadas para sistemas de segurança e aeroespacial. O motivo da parceria entre o IESE e a Thales foi a intenção da subsidiária melhorar o processo de software e alcançar um nível superior no modelo SPICE. Parametrizado nessa intenção, o Grupo de Processo de Engenharia de Software (GPES) da empresa elegeu a descrição do processo de software como um fator chave para alcançar o seu objetivo. A descrição do processo de software envolveu dois pesquisadores do IESE, três membros do GPES e diversos participantes do processo na Tales. O estudo de caso foi dividido em cinco estágios:

Estágio Objetivo

Preparação Fornecer uma visão geral do processo de software antes de iniciar as atividades de modelagem resultando na descrição em alto nível das principais atividades, artefatos e critérios de entrada e saída.

Treinamento Apresentar os principais conceitos e terminologias relacionadas à modelagem de processos de software.

Modelagem inicial do processo

Transferir tecnologias para os participantes da empresa. Treinar os participantes na coleta e descrição do processo de software. A primeira versão descritiva de alto nível do processo de software deve ser gerada nesse estágio.

Elaboração do modelo

Detalhar o modelo descritivo de processo de software gerado no estágio anterior (Modelagem inicial do processo).

Revisão Verificar inconsistências no modelo descritivo gerado no estágio anterior (Elaboração do Modelo). Deve ser gerada nesse estágio a versão final do modelo descritivo do processo de software.

A análise de documentos (Estágio de Preparação) durou aproximadamente dois dias. Foram descritos em linguagem natural os elementos de processo de alto nível: atividades, artefatos, papéis e critérios de entrada e saída. Além disso, também foi realizada a descrição de fluxos de produtos (consumidos, produzidos e modificados) entre atividades e artefatos e descrição dos papéis para cada atividade. O treinamento foi realizado por meio de workshop que ocorreu em um único dia (aproximadamente 8h00m). O workshop abordou conceitos relacionados à modelagem de processo de software, utilização de ferramentas relacionadas à modelagem de processo de software (ferramenta Spearmint) e apresentação de exemplos (modelos de processo descritos). No Estágio de Modelagem Inicial do Processo, as informações de alto nível coletadas no primeiro estágio foram modeladas por intermédio da ferramenta

Spearmint – Software Process Elicitation, Analysis, Review and Modeling in an

Integrated Environment – vide Figura 21. A ferramenta utiliza ícones para representar os quatro elementos básicos de processo de software: atividade, artefato, papel e ferramenta e; seis tipos de relacionamentos entre os elementos: consome, produz, modifica, envolve, usa e contém (vide Quadro 2):

Quadro 2: Notações gráficas utilizadas pela ferramenta Spearmint. Atividade / sub-atividade

Artefato Papel Ferramenta

Consome: apenas é possível de artefato para atividade. Produz: apenas é possível de atividade para artefato. Modifica: apenas é possível entre atividade e artefato. Envolve: apenas é possível entre atividade e papel. Usa: apenas é possível entre atividade e ferramenta

Contém: apenas visível em árvore, não há uma notação gráfica explícita para esse relacionamento.

A ferramenta Spearmint também possui representações para execução de atividades em paralelo (Quadro 3). Quatro possíveis estados são representados: Quadro 3: Notações gráficas utilizadas para representar execução em paralelo.

Utilizado para representar atividades em paralelo.

x

“and”: significa que pelo menos duas (ou mais) atividades devem _{ser executadas antes ou depois do novo estado.}

+

"or": significa que qualquer atividade de no mínimo duas atividades poderiam ser executadas antes ou depois do novo estado (disjunção inclusiva ou soma lógica).

⊕

"xor": significa que exatamente uma de um grupo de atividade deveria ser executada antes ou depois do novo estado (disjunção exclusiva).

"nil": significa que não há atividade envolvida.

O exemplo ilustrado na Figura 20 demonstra a utilização da representação de junção e disjunção. Nesse exemplo, o fluxo de controle é unificado em

No documento Modelagem descritiva iterativa e incremental de processo de software: uma experiência em uma microempresa de desenvolvimento de software (páginas 70-75)