Avaliação da Ferramenta Methodology Explorer Marília Lima, Hermano Perrelli Centro de Informática Universidade Federal de Pernambuco (UFPE) Caixa Postal 15.064 91.501-970 Recife PE Brasil {msml,hermano}@cin.ufpe.br Resumo. Este trabalho descreve o processo de avaliação da ferramenta Methodology Explorer, desenvolvida pelo Centro de Informática UFPE, cujo foco é o processo de desenvolvimento de software e encontra-se, atualmente, na versão 1.0. A sua avaliação foi realizada com o objetivo de delinear novas funcionalidades, baseada numa visão de médio e longo prazo, assim como aumentar a sua qualidade no que se refere a eficiência e facilidade de uso. 1. Introdução O sistema Methodology Explorer é uma ferramenta desenvolvida pelo Centro de Informática da Universidade Federal de Pernambuco e tem seu foco voltado para o processo de desenvolvimento de software. Tem como objetivo principal permitir, de maneira intuitiva e eficiente, a definição de componentes de processos adequados a uma organização e seus projetos. Um componente é uma unidade da metodologia que pode ser manipulada isoladamente, por exemplo: artefato, atividade, conjunto de atividades etc [Junior 2002]. Atualmente a ferramenta encontra-se na versão 1.0 e através dela, o usuário - em geral, engenheiro de processos ou projetista de metodologias - poderá cadastrar novos componentes ou criar componentes a partir de outros já existentes. Além disso, poderá alterar, remover e consultar componentes já criados. Tais componentes podem ser exportados da ferramenta, gerando páginas HTML que podem ser visualizados sem utilizar a ferramenta. Considerando uma visão de curto e médio prazo, espera-se que as próximas versões da ferramenta incorporem as seguintes características: Seja robusta o suficiente para permitir cadastrar, recuperar e manipular componentes metodológicos de uma maneira simples, rápida e fácil; Possua regras de consistência no momento de cadastrar os componentes, evitando assim, erros no momento de definir novo componentes a partir de outros já existentes; Permitir que durante o fluxo de instanciação dos componentes as visões de projeto e organização sejam consideradas. Em longo prazo espera-se que através da ferramenta Methodology Explorer o usuário seja capaz de caracterizar projetos, acompanhar e gerenciar sua execução de acordo com o processo associado.
Considerando estas visões de futuro, o objetivo deste trabalho é delinear novas possibilidades para a ferramenta. Não restringindo apenas a novas funcionalidades, mas inclusive aumentar a qualidade do produto disponibilizado no que se refere a eficiência e facilidade de uso. A seguir é descrita a metodologia definida para atingir esses objetivos. 1.1. Metodologia A metodologia para desenvolvimento deste trabalho de avaliação foi definida por quatro etapas bem distintas, conforme figura abaixo. Teste Avaliação ISO 12119 Benchmarks Avaliação Final Figura 1. Metodologia de Desenvolvimento do Trabalho A seguir temos a descrição de cada etapa: Etapa I Conformidade com a Norma ISO/IEC 12119: avaliação da ferramenta Methodology Explorer, versão 1.0, segundo os Requisitos de Qualidade para pacotes de software definidos pela norma NBR ISO/IEC 12119 com o intuito de observar sua conformidade com a mesma, e levando assim a desenvolver uma ferramenta de maior qualidade do ponto de vista do usuário final. Etapa II Testes: avaliação da ferramenta propriamente dita, teste de suas funcionalidades e facilidade de uso. Etapa III Benchmark: realização de um benchmark com as ferramentas: Config e AdaptPro Estação TABA e APSEE Prosoft com o objetivo de comparar os resultados produzidos por cada uma e delinear futuras versões para a Methodology Explorer. Este benchmark consistiu da modelagem das disciplinas de Requisitos e Análise e Projeto do RUP Rational Unified Process. [RUP] Etapa IV: reunir os resultados obtidos nas três etapas anteriores (teste, avaliação segundo ISO 12119 e benchmark) de forma a gerar um conjunto de recomendações para futuras versões da ferramenta.
2. Avaliação de Conformidade com a Norma NBR ISO/IEC 12119 2.1. Descrição da Norma A Norma NBR ISO/IEC 12119 Pacotes de software Teste e requisitos de qualidade é aplicável a pacotes de software. São exemplos: processadores de texto, planilhas eletrônicas, bancos de dados, software gráficos, programas para funções técnicas ou científicas e programas utilitários. Esta norma estabelece requisitos de qualidade e instruções de teste (em particular para teste por terceira parte) para pacotes de software, sendo estruturada conforme figura abaixo [NBR ISO/IEC 12119]. Norma ISO/IEC 12119 Requisitos de Qualidade Instruções para Teste Descrição de Produto Documentação de Usuário Programas e Dados Pré-requisitos de Teste Atividades de Teste Registros de Teste Relatório de Teste Teste de Acompanhame nto Figura 2. Estrutura da Norma NBR ISO/IEC 12119 Desta forma, a norma ISO 12119 não trata de processos de produção de software, trata de pacotes de software da forma como são oferecidos e liberados para uso. Ou seja, o sistema de qualidade do produtor está fora do escopo desta norma. Neste sentido, os potenciais usuários desta norma podem ser: Fornecedores que estejam especificando os requisitos para um pacote de software, projetando um modelo para descrever produtos, divulgando seus próprios produtos, submetendo produtos à certificação; Entidades de certificação que pretendam estabelecer um modelo de certificação por terceira parte; Entidades de credenciamento que credenciam entidades de certificação ou laboratórios de teste; Laboratórios que deverão seguir as instruções de teste para certificação ou para a emissão de marca de conformidade com a norma; Auditores quando julgam a competência de laboratórios de teste; Compradores que pretendam comparar os requisitos necessários para executar uma determinada tarefa com a informação presente nas descrições de produtos existentes ou verificar se os requisitos foram atendidos; Usuários que pretendam se beneficiar com produtos melhores.
O contexto deste trabalho se encaixa como um usuário do tipo fornecedor que deseja avaliar a conformidade do seu produto com a norma. A seguir temos a listagem de algumas das definições utilizadas pela norma e seu entendimento é de fundamental importância para o entendimento da avaliação apresentada adiante. Estas são: Documento de Requisitos: documento contendo quaisquer combinações de recomendações, requisitos ou regulamentações a serem atendidas por um pacote de software. Descrição de Produto: documento expondo as propriedades de um pacote de software, com o principal objetivo de auxiliar os potenciais compradores na avaliação adequada do produto antes de sua aquisição. Documentação de Usuário: conjunto completo de documentos, disponível na forma impressa ou não, que é fornecido para a utilização do produto, sendo também uma parte integrante do produto. Documentação de Pacote: documentação de usuário e o documento de requisitos. Função: implementação de um algoritmo em um programa com o qual o usuário ou o programa pode realizar toda uma tarefa ou parte dela. Guia de teste (test case): instrução documentada para o responsável pelo teste que especifica como deve ou convém que seja testada uma função ou uma combinação de funções. A norma ISO/IEC 12119 estabelece que um pacote de software está em conformidade com a mesma se atende a todos os requisitos 1 estabelecidos para o Documento de Requisitos, Documentação de Usuário e Programas e Dados integrantes do software. Os requisitos indicados pelo uso da forma verbal convém que são opcionais [NBR ISO/IEC 12119]. Nas subseções a seguir, será apresentada uma avaliação da ferramenta Methodology Explorer segundo os Requisitos de Qualidade. O resultado é apresentado no formato de tabela onde a cada requisito está associada uma breve descrição e um indicativo, conforme legenda a seguir, se o mesmo foi atendido pela ferramenta sob análise, a Methodology Explorer. Tabela 1. Legenda dos Indicativos de Conformidade Símbolo Significado Não se aplica Requisito Atendido Requisito Não-atendido? Não passível de avaliação 1 Os requisitos sobre a documentação de usuário, programas e dados contêm muitos requisitos gerais, mas não incluem todas as propriedades que os usuários possam desejar.
2.2. Avaliação da Descrição do Produto Nesta seção é apresentada um tabela para o conjunto de requisitos estabelecidos para a Descrição de Produto. As informações abaixo foram obtidas a partir do website onde a ferramenta encontra-se disponível para download. Os dados encontrados estão distribuídos ao longo dos tópicos apresentados no site, ou seja, não estão concentrados em um único documento ou seção específica com determina a Norma. Tabela 2. Requisitos sobre o conteúdo da Descrição de Produto Características Subcaracterísticas Requisito Atendid o Requisitos Gerais Requisitos gerais Livre de inconsistências internas Declarações sobre Funcionalidade Declarações sobre Confiabilidade Declarações sobre Usabilidade Cada declaração deve ser correta e possível de teste Convém que a descrição seja suficientemente inteligível, completa, boa organização e apresentação. Convém que cada termo utilizado tenha um único significado Manutenção Declarar se existe manutenção, e existindo o que está incluído Visão geral das funções Disponibilizar visão geral das funções (nem todas precisam ser mencionadas), dados necessários e facilidades oferecidas Para cada função declarada identificar se a mesma é parte do produto, de uma extensão ou de um suplemento sem garantia por exemplo Valores-limite Identificar Valores-limite, se existirem. Exemplos: número máximo de registros eu um arquivo, número máximo de critérios de busca, tamanho mínimo de amostra etc Declarações sobre confiabilidade Incluir informações sobre procedimentos para preservação dos dados Interface com usuário O tipo de interface com o usuário deve ser especificado, por exemplo: menu, janela, linha de comando etc. Conhecimento requerido Conhecimentos específicos requeridos para a aplicação do produto devem ser descritos, por exemplo: conhecimento de outro idioma diferente daquele em que foi escrita a descrição de produto, conhecimento de uma área técnica, conhecimento de um sistema operacional etc Adaptação às necessidades dos Identificar as ferramentas de adaptação e as usuários condições de uso caso o produto possa ser adaptado pelo usuário, por exemplo: parâmetros de configuração, mudança de algoritmo para computação atribuição de teclas de função etc.?
Declarações sobre Eficiência Declarações sobre Manutenibilidade Declarações sobre Portabilidade Proteção contra infrações e direitos autorais Declarações sobre Eficiência Declarações sobre Manutenibilidade Declarações sobre Portabilidade Declarar proteção contra infrações e direitos autorais, se existir. Pode incluir dados sobre o comportamento? do produto em relação ao tempo, tais como tempo de resposta e taxas de throughput para uma/cada função sobre condições estabelecidas Pode conter declarações sobre? manutenibilidade Pode conter declarações sobre portabilidade?? 2.3. Avaliação da Documentação do Usuário Nesta seção é apresentada um tabela para o conjunto de requisitos estabelecidos para a Documentação de Usuário. Tabela 3. Requisitos sobre o conteúdo da Documentação de Usuário Característica Requisito Atendido Completitude Todas as funções devem ser completamente descritas Todo valor-limite citado na descrição de produto deve ser repetido? Incluir manual de instalação com todas as informações necessárias, caso a instalação possa ser feita pelo usuário 2 Convém que o manual de instalação estabeleça o espaço de armazenamento mínimo e máximo para a instalação do produto Correção Todas as informações na documentação de usuário devem estar corretas. Convém que a documentação de usuário não contenha ambigüidades nem erros Consistência Não deve apresentar contradições internas nem com a Descrição de Produto. Convém que cada termo tenha um único significado em toda documentação Inteligibilidade Convém que a documentação de usuário seja inteligível pela classe de usuários que normalmente executa a tarefa a ser? atendida pelo produto, utilizando, por exemplo, uma seleção apropriada de termos, exibições gráficas, explicações detalhadas citando fontes úteis de informação Apresentação e Convém que a documentação de usuário possua boa Organização apresentação e organização, de tal modo que quaisquer relacionamentos sejam facilmente identificados. Convém que todo documento tenha índice analítico e remissivo Convém que o procedimento para impressão do documento seja indicado, caso não esteja na forma impressa 2 O manual é citado no documento e disponibilizado juntamente com o arquivo de instalação.
2.4. Avaliação de Programas e Dados Nesta seção é apresentada um tabela para o conjunto de requisitos estabelecidos para o item Programas e Dados. Tabela 4. Requisitos sobre o conteúdo da Documentação de Usuário. Característica Subcaracterística Requisito Atendid o Funcionalidade Instalação Deve ser passível de instalação com sucesso seguindo o manual, se puder ser feita pelo 3 usuário. Presença de funções Todas funções mencionadas na documentação de usuário devem ser executáveis da mesma forma nela descrita. Correção Os programas e dados devem corresponder a todas as declarações contidas na descrição de produto e na documentação de usuário As funções devem ser executadas de maneira correta para a realização de uma tarefa. Consistência Os programas e dados não devem conter contradições internas, contradições com a descrição do produto e nem com a documentação de usuário. Convém que o controle da operação do programa pelo usuário e o comportamento do programa (por exemplo, mensagens, formatos de tela de entrada e relatórios impressos) sejam estruturados de maneira uniforme. Confiabilidade Confiabilidade O sistema não deve entrar em um estado no qual o usuário não consiga controlá-lo, nem 4 deve corromper ou perder dados. Os programas devem reconhecer as violações da sintaxe estabelecida para entrada de dados.? Usabilidade Inteligibilidade Convém que as perguntas, mensagens e resultados dos programas sejam inteligíveis. 5 Apresentação e organização Deve ser possível sempre ao usuário descobrir que função está sendo executada. Convém que os programas forneçam ao usuário informações claramente visíveis e fáceis de serem lidas. Convém que o usuário seja guiado por informações codificadas e agrupadas adequadamente. Onde for necessário, convém que o usuário seja alertado pelos programas. 3 Instalação realizada com sucesso após detalhamento da versão inicial do manual de instalação 4 Problemas encontrados foram corrigidos, resultando numa nova versão da ferramenta. 5 Mensagens de erro não esclarecedoras
Convém que as mensagens dos programas sejam projetadas de forma que o usuário possa diferenciá-las facilmente pelo tipo, por exemplo: confirmação, solicitações, advertências, mensagens de erro. Convém que os formatos de tela de entrada, relatórios e de outras de entrada e saída sejam projetadas para serem claros e com boa apresentação e organização. Operacionalidade A execução de funções que tem conseqüências graves deve ser reversível, ou os programas devem dar uma clara mensagem sobre as conseqüências e requisitar confirmação antes da execução do comando. Convém que o usuário seja capaz de acessar subitens de um texto de documentação de forma direta caso o mesmo seja exibido em um diálogo. Exemplo: pela seleção em uma tabela de conteúdo exibida na tela, ou por uma função de busca baseada em palavraschave. Eficiência Eficiência Deve estar em conformidade com as declarações de eficiência citadas em sua descrição Manutenibilidade Manutenibilidade Deve estar em conformidade com as declarações de manutenibilidade citadas em sua descrição Portabilidade Portabilidade Deve estar em conformidade com as declarações de portabilidade citadas em sua descrição 3. Benchmark Nesta seção é descrita a terceira etapa da metodologia utilizada, a realização de um benchmark. Como descrito na seção 1.1, este benchmark consistiu em modelar um processo formado pelas disciplinas de Requisitos e Análise e Projeto do RUP. Foram utilizadas as seguintes ferramentas, além da própria Methodology Explorer: APSEE Projeto Prosoft. Integração de Ferramentas para Gerência do Processo de Desenvolvimento de Software. O Ambiente Prosoft - Projeto de Ambiente de Desenvolvimento de Software, está sendo desenvolvido no Instituto de Informática da Universidade Federal do Rio Grande do Sul (Brasil), em um programa de cooperação internacional com o Institut für Informatik - Universität Stuttgart (Alemanha) [APSEE]. A ferramenta APSEE foi inserida no ambiente Prosoft com o objetivo de auxiliar as diferentes etapas do ciclo de vida de processos, como modelagem, execução, instanciação, validação, avaliação, reutilização, adaptação e aperfeiçoamento. Config e AdaptPro Estação TABA. O projeto Estação TABA é desenvolvido pela Universidade Federal do Rio de Janeiro e tem como objetivo a geração de ambientes de desenvolvimento de software
adequados às particularidades de processos de desenvolvimento e projetos específicos. A ferramenta Config permite a configuração de ambientes organizacionais, enquanto que a AdaptPro permite a instanciação de processos de software em ambientes configurados pela Estação TABA [TABA]. Para cada ferramenta citada acima será apresentado, nas seções a seguir, o resultado da modelagem proposta como benchmark. 3.1 Ferramenta Methodology Explorer Na figura baixo temos a visão do processo instanciado na ferramenta Methodology Explorer. Figura 2. Visão do Processo Modelado na Ferramenta Methodology Explorer. Em seguida, o processo foi publicado através da geração de um website. Esta operação é disponibilizada pela ferramenta através da funcionalidade Web Publisher.
Figura 3. Funcionalidade Web Publisher. Figura 4. Website gerado pelo Web Publisher do Methodology Explorer. Uma vez que os processos base foram definidos, o usuário poderá criar novos processos a partir destes. Esta tarefa é possível através da funcionalidade Instance Creator, conforme ilustrado nas figuras a seguir.
Figura 5. Instance Creator Selecionando a Metodologia base.
Figura 6. Instance Creator Selecionado os componentes. Figura 7. Nova metodologia instanciada a partir do Instance Creator do Methodology Explorer. Em resumo, atualmente através da ferramenta Methodology Explorer é possível definir um novo processo, instanciar processos a partir de outros já modelados e publicá-los em forma de website. 3.2 Ferramentas Config e AdaptPro Estação TABA Através da Estação TABA o benchmark poderia ser realizado com a utilização da ferramenta Config, que permite a configuração de um ambiente baseado num processo, e pela ferramenta AdaptPro, utilizada para instanciar um processo para um determinado projeto. Contudo, não foi possível realizar o benchmark proposto em função das ferramentas acima citadas não estarem disponíveis publicamente. Embora a realização do benchmark tenha sido inviável, decidimos acrescentar algumas telas que permitem visualizar algumas das funcionalidades oferecidas pelas ferramentas Config e AdaptPro. As figuras apresentam funcionalidades da ferramenta Config onde o usuário poderá caracterizar uma dada Organização e definir seus processos base.
Figura 8. Caracterizando uma Organização na ferramenta Config, Estação TABA.
Figura 9 e 10. Caracterizando um Processo Padrão para a Organização com a ferramenta Config, Estação TABA. Uma vez configurado o ambiente da Organização através da ferramenta Config, o usuário poderá, então, caracterizar um processo para uma determinado projeto a partir da ferramenta AdaptPro (vide figuras a seguir).
Figura 11. Definindo um Processo para um Projeto com a Ferramenta AdaptPro, Estação TABA.
Figura 12. Definindo o Ciclo de Vida do Processo com a ferramenta AdaptPro, Estação TABA.
Figura 13. Visualizando o Processo Definido com a ferramenta AdaptPro, Estação TABA. Em função dessas ferramentas, Config e AdaptPro, disponibilizarem um grande número de funcionalidades não seria possível no espaço deste artigo apresentar as respectivas telas para cada uma das mesmas. Sendo assim, são listadas abaixo as visões contempladas e consideradas pela Estação TABA para definição e instanciação de processos: Visão da Organização: caracterização da organização, cultura e objetivos na área de software. Definição de processos padrão para a organização, considerando aspectos de Qualidade de Software como as atividades propostas pelo CMM e pela norma NBR ISO12207. Visão de Projeto: caracterização e planejamento do processo para um projeto específico, levando em consideração suas particularidades. 3.3 Ferramenta APSEE Ambiente Prosoft Ao contrário das ferramentas citadas anteriormente, a APSEE utiliza uma linguagem de modelagem, chamada PML Process Modeling Language, através da qual o usuário pode definir seus processos. De forma resumida, segue na tabela abaixo uma legenda para cada elemento da linguagem utilizado no benchmark.
Tabela 5. Alguns Elementos da Linguagem PML, APSEE Prosoft. Elemento Significado Atividades Atividade Folha Atividade Decomposta (fragmento) Conexão entre Atividades Conexão Simples de Seqüência, onde dependência pode ser uma conexão do tipo: end-start, start-start, end-end ou? (indefinido). Conexão Simples de Feedback, onde condição é uma expressão lógica avaliada em tempo de execução. Conexão Múltipla de Join, onde Tipo pode ser: AND, OR ou XOR; e Tipo_Dep pode ser: end-start, startstart, end-end ou? (indefinido). Conexão Múltipla de Branch, onde Tipo pode ser: AND, OR ou XOR; e Tipo_Dep pode ser: end-start, startstart, end-end ou? (indefinido). Artefato Artefato Conexão entre artefatos e atividades. A seguir são apresentadas algumas figuras que representam a modelagem da disciplina de Requisitos na ferramenta APSEE utilizando a linguagem PML.
Figura 14. Modelagem Disciplina de Requisitos na APSEE Prosoft. Figura 15. Detalhando a Modelagem da Atividade Decomposta Analyse the Problem da Disciplina de Requisitos na APSEE Prosoft. As Atividades, Papéis (Roles) e Artefatos definidos na ferramenta podem ser criados sob uma hierarquia, facilitando assim sua contextualização no processo. Nas figuras a seguir, são apresentadas as hierarquias definidas para os Papéis e Artefatos das disciplinas consideradas no benchmark. Lembrando que esta hierarquia pode ser definida livremente pelo usuário, ou seja, da forma que lhe for mais conveniente. Para a execução deste benchmark foi escolhida a hierarquia definida pelo próprio RUP.
Figura 16. Hierarquia de Artefatos Modelada na Ferramenta APSEE Prosoft. Figura 17. Hierarquia de Papéis Modelada na Ferramenta APSEE Prosoft. Assim como a Estação TABA, a ferramenta APSEE também incorpora as visões da organização e de projetos específicos para permitir a definição, instanciação, e execução dos processos. A seguir, temos uma tabela onde são apresentadas de forma sucinta as funcionalidades ou características disponibilizadas por cada ferramenta utilizada por este benchmark. Tabela 6. Conclusão do Benchmark: funcionalidades de cada Ferramenta. Características Methodology Explorer Config e AdaptPro - Estação TABA APSEE - Prosoft Modelagem de qualquer processo Linguagem de modelagem Instanciação a partir de um processo padrão Hierarquia de artefatos, atividades, ferramentas e papéis. Visão de Projeto Visão da Organização Acompanhamento das atividades durante execução do projeto Métrica Conhecimento do Processo Compatibilização com CMM e ISO Políticas de Instanciação
4. Recomendações Como última etapa da metodologia de desenvolvimento definida para este trabalho, citada na seção 1.1, este tópico tem como objetivo reunir um conjunto de recomendações para a evolução da ferramenta Methodology Explorer a partir dos resultados obtidos nas etapas anteriores: avaliação segundo a norma ISO 12119, testes gerais e execução de um benchmark. Desta forma, as recomendações estão organizadas segundo dois grupos: Conformidade com a Norma ISO 12119 e Novas Características e Funcionalidades. Este último tem como objetivo listar novas funcionalidades que venham a permitir permitir a instanciação de um processo para um projeto específico de uma organização, assim como acompanhar sua execução. 4.1 Recomendações para Conformidade com a Norma ISO/IEC 12119 Disponibilizar a qualquer pessoa interessada um documento sob o título Descrição do Produto contendo todas as informações exigidas pela norma, vide seção 2.2. Este documento pode ser feito em qualquer formato, como por exemplo: doc, html ou pdf; o importante é que as informações estejam agrupadas sob o título Descrição de Produto. Disponibilizar aos usuários da ferramenta um documento sob o título Documentação do Usuário contendo todas as informações exigidas pela norma. Para isto, é suficiente complementar o manual do usuário já existente com as informações não disponibilizadas, vide seção 2.3. Em relação à utilização do software propriamente dito: o Disponibilizar um manual de instalação com um passo a passo detalhado e explícito, de forma que a execução dos mesmos não exija um conhecimento adquirido previamente pelo usuário. o Resolver o aspecto de lentidão na execução quando o usuário entra com muitos dados. Atualmente, à medida que as informações são cadastradas a execução da funcionalidade salvar vai ser tornando cada vez mais lenta. o Emitir mensagens de erro que sejam claras o suficiente para que o usuário possa identificar onde está acontecendo o problema e como resolvê-lo. o Projetar o layout das mensagens emitidas de forma que o usuário possa diferenciá-las pelo tipo, por exemplo: confirmação, solicitação, advertências e mensagens de erro. o Requisitar confirmação antes da execução de comandos como excluir, sair e fechar. Em relação a este último, solicitar ao usuário confirmação se as alterações realizadas devem ser salvas ou não quando o mesmo executa a funcionalidade fechar metodologia. 4.1 Recomendações para Novas Características e Funcionalidades Aspectos relacionados ao site do Projeto Methodology Explorer, http://www.cin.ufpe.br/~mexplorer:
o Disponibilizar informações de forma estruturada sobre o projeto de desenvolvimento da ferramenta: objetivos do projeto, objetivos da ferramenta, equipe, histórico, usuários da ferramenta e publicações relacionadas. o Analisar a necessidade de criar uma versão em inglês do site, considerando qual o público-alvo esperado para a ferramenta. Em relação ao Manual do Usuário disponibilizado: o Criar uma seção com exemplos de processos definidos na ferramenta. Estes exemplos orientam o usuário e demonstram todo o potencial da ferramenta. o Informar mais detalhes sobre a funcionalidade Web Publisher : que informações são publicadas. Em relação à funcionalidade Web Publisher : o Gerar o website em inglês, uma vez que a ferramenta está em inglês. o Disponibilizar templates para que o usuário tenha mais de uma opção de layout de página. o Melhorar a navegabilidade no website gerado de forma que o usuário possa identificar em que item do menu ele se encontra durante a navegação. Em relação a novas funcionalidades o Criar a visão de Projeto permitir que o usuário caracterize um projeto e associe um processo ao mesmo. o Permitir que artefatos, papéis, atividades, ferramentas sejam definidos de forma estruturada, cada qual com entradas para as informações relevantes ao seu contexto. o Permitir o acompanhamento das atividades de cada participante do projeto, ou seja, visualizar o status das atividades e artefatos definidos para cada pessoa no projeto. o Permitir, ao término do projeto, que seja analisada a aderência do processo escolhido ao tipo de projeto em questão. Disponibilizar essas informações no momento em que o usuário instancie um processo para um novo projeto. 5. Avaliação Final e Conclusões A partir dos resultados obtidos com a execução do benchmark chegamos a uma visão de que os processos caminham para uma particularização em função da cultura da organização e de características específicas dos projetos aos quais estão relacionados. Ou seja, cada empresa pode ter processos que se adequam melhor às necessidades e objetivos de cada projeto e da própria empresa. Nesse contexto, a principal evolução da ferramenta Methodology Explorer seria permitir esta particularização dos processos em função da organização e de seus
projetos. Um outro fator importante a ser considerado trata-se das documentações disponibilizadas aos usuários. Uma boa documentação é de fundamental importância para que o usuário consiga utilizar toda a potencialidade da ferramenta e da forma mais adequada. E neste caso, uma boa opção seria disponibilizar exemplos de processos, já conhecidos, definidos na ferramenta de forma que o usuário tenha exemplos práticos e reais nos quais possa basear-se. 6. Referências APSEE Prosoft Projeto de Ambiente de Desenvolvimento de Software. UFRGS http://www.inf.ufrgs.br/~prosoft/ Colombo, R., Tsukumo, A., et al. (1997) Qualidade de Software: Visões de Produto e Processo de Software, II Escola de Informática da SBC, Piracicaba, SP, p.173-189. Colombo, R., Guerra, A. The Evaluation Method for Software Product. CenPRA Centro de Pesquisas Renato Archer. Estação TABA UFRJ. Meta-Ambiente para instanciação de Ambientes de Desenvolvimento de Software convencionais e Orientados a Domínios. http://www.cos.ufrj.br/~taba Ferramenta Methodology Explorer, http://www.cin.ufpe.br/~mexplorer Junior, C. R. S. (2002) Documento de Requisitos do Sistema Methodology Explorer, versão 3.0, http://www.cin.ufpe.br/~mexplorer NBR ISO/IEC 12119, Tecnologia de informação Pacotes de Software Teste e requisitos de qualidade, Rio de Janeiro, 1998. RUP Rational Unified Process, http://www.rational.com