Next: Proposta de um Up: Uma proposta para Previous: Introdução
As diretrizes para construir um modelo de rastreamento estão baseadas em nossa experiência com outros projetos, cursos de extensão e nos trabalhos [2], [3], [4], [7], [10], [11] e [14]. A seguir identificamos e discutimos essas diretrizes.
Os objetivos do gerenciamento de projeto são planejar, escalonar e supervisionar um conjunto de tarefas para desenvolver software. A execução destas tarefas permitirá a identificação de uma rede de trabalhos realizados, que será gerenciada através do nosso modelo proposto. Entre os conceitos de gerenciamento que incluímos no nosso modelo são: reunião, tarefa, relatório, decisão (organizacional ou gerencial), recursos (humanos, fisíco, financeiro), tempo e ação.
Identificar atividades e tarefas
O nosso modelo incorpora os conceitos de atividade e tarefa. Neste artigo, atividade refere-se às ações burocráticas (por exemplo, entrevistas, reuniões), enquanto tarefas representam a definição e execução de trabalhos específicos (modelagem, implementação, etc). O nosso modelo de rastramento expressa que uma atividade ou tarefa pode estar composta de outras atividades e tarefas, respectivamente. A relevância das atividades e tarefas é que elas representam aspectos sociais e técnicos do processo de desenvolvimento. Portanto, são uma fonte de informação e reflexão do sucesso ou fracasso de um projeto.
Identificar agentes do processo de desenvolvimento de software
Diversas agentes (pessoas) com diferentes domínios de conhecimentos contribuem no desenvolvimento de um software. Por exemplo, os clientes e usuários finais fornecem requisitos; o engenheiro de requisitos ajuda aos clientes e usuários a descobrir, entender seus próprios requisitos. Portanto, se identificamos os agentes participantes de um processo de desenvolvimento, então o modelo de rastreamento contribuirá para estabelecer relacionamentos entre agentes com componentes de processo de desenvolvimento (documentos, diagramas, programas) e atividades e tarefas. Como exemplo de rastreamento entre agentes e documentos teríamos a identificação dos documentos produzidos pelos agentes desenvolvedores.
Documentar o processo de desenvolvimento
O processo de software é um conjunto de trabalhos e resultados associados. Uma forma de tornar o processo visível é através de documentos. Esses documentos são produzidos e/ou fornecidos pelos diferentes agentes envolvidos no processo de desenvolvimento. Se os agentes desenvolvedores documentarem o processo, então há necessidade de consistência e ordenamento entre os documentos produzidos. Neste contexto, a contribuição do nosso modelo de rastreamento será o estabelecimento de relacionamentos bidirecionais entre os vários documentos intermediários e o produto final. Os documentos podem incluir: documento de especificação, pré-desenvolvimento (mail, livros, relatórios, etc), documentos intermediários (modelagem, projeto, etc) e documentos finais. Esses relacionamentos contribuem para manter o relacionamento entre documentos e a preservar consistência entre os mesmos. Por exemplo, quando uma modificação for feita, todas as representações e documentações relacionadas de um projeto, deveriam ser encontradas e atualizadas.
Identificar propriedades dos requisitos
Existem várias definições de requisitos [18]. Tradicionalmente tem sido identificados requisitos funcionais e não funcionais. O rastreamento funcional depende do método usado para o desenvolvimento do software[10], isto é, das peças de desenvolvimento (exemplos, documentos e programas) que o processo produz. O rastreamento não-funcional é mais complexo de ser estabelecido pois requisitos não-funcionais são alocados a diferentes unidades de projeto. No momento, estamos trabalhando somente com requisitos funcionais.
O nosso modelo inclue o conceito de requisito com algunas propriedades (estado, prioridade e tipo: volátil e permanente) extraídas e discutidas no trabalho de [16], que representam a fonte de informação do produto final. Por exemplo, gerentes ou engenheiros de requisitos podem consultar pelo estado da implementação dos requisitos prioritários de um projeto.
Documentar o raciocínio dos desenvolvedores
Após um bom entendimento das reais necessidades do usuário, os projetistas propõem uma solução técnica para o problema. Geralmente, a solução consiste em um conjunto de diagramas, uma arquitetura, especificação dos algoritmos e estruturas de dados. O projetista chega a esse resultado através de um processo iterativo que combina intuição e julgamento, baseados na experiência e em um conjunto de princípios e heurísticas. Geralmente, as atividade (reuniões, entrevistas) e tarefas feitas antes e durante o desenvolvimento estão apenas nas mentes dos desenvolvedores, já que assumem um conhecimento tácito entre eles ou porque os projetos sempre são solicitados e feitos com urgência. Portanto, o conhecimento dos desenvolvedores experientes fica restrito à comunicação entre o grupo de desenvolvedores, dificultando que integrantes menos experientes de outros grupos aproveitem esse conhecimento.
Se o raciocínio da criação ou modificação de componentes for documentado, então existirá um conjunto de justificativas de um projeto. Neste contexto, o nosso modelo pode contribuir para projetar, ordenar e relacionar o conhecimento técnico e social que surge do processo de desenvolvimento de software.
Identificar e atribuir responsabilidades
Grandes projetos são desenvolvidos por diferentes grupos de desenvolvimento. Cada desenvolvedor possui um papel e um conjunto de tarefas bem definidas. Na medida que o desenvolvimento de um software evolue, o gerente de projeto pode introduzir e atribuir tarefas a novos integrantes. Dependendo do tamanho e complexidade de um projeto, uma tarefa pode ser atribuída a uma ou várias pessoas (grupo). Portanto, se um conjunto de tarefas é escalonado e atribuído a um grupo de pessoas, então indiretamente estabeleceremos relacionamentos de responsabilidade entre agentes e tarefas. Se o gerente desejar supervisionar o conjunto de tarefas, o nosso modelo poderia contribuir para implementar os relacionamentos bidirecionais de responsabilidade entre agentes e tarefas. Assim, por exemplo, o rastreamento das informações permitiria a identificação dos responsáveis por uma tarefa. Esta diretriz de responsabilidade pode ser aplicada nas diferentes fases de um processo de desenvolvimento.
Introduzir rastreamento horizontal e vertical
O rastreamento horizontal estabelece associações entre elementos de uma mesma fase de desenvolvimento do software. Por exemplo, considere um documento de requisito. Neste caso, podem existir referências cruzadas entre requisitos. O rastreamento vertical está centrado no relacionamento entre elementos de diferentes fases do processo de desenvolvimento. Por exemplo, o gerente pode estar interessado em saber em qual módulo está implementado um determinado requisito.
Se existe uma preocupação de se manter a consistência e integridade dos diferentes tipos documentos do processo de desenvolvimento, então os rastreamentos horizontal e vertical podem contribuir para que os desenvolvedores criem um software que responda às expectativas dos seus usuários.
Considerar o grau de granularidade no rastreamento de informação
O programador de um modelo de rastreamento deve considerar o grau de granularidade que seu modelo suporta. Por exemplo, o implementador deve decidir se um requisito estará relacionado com um programa ou um fragmento de código (função ou variável).
Considerando os relacionamentos estabelecidos entre os conceitos mencionados até agora, podemos indicar que nosso modelo possui uma alta granularidade.
Validar e verificar o projeto
Rastreamento é essencial para verificação e validação sendo necessário para um melhor entendimento do processo usado para o desenvolvimento de software e os produtos resultantes [9]. A validação e verificação no nosso modelo é possível pela diretriz de rastreamento horizontal e vertical, pela alta granularidade do modelo, e pelo gerenciamento dos documentos do processo de desenvolvimento.