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.

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.

AvaliaçãoISO 12119

Teste

Benchmarks

Avaliação Final

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].

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.

Norma ISO/IEC 12119

Requisitos deQualidade

Instruções paraTeste

Descrição deProduto

Documentaçãode Usuário

Programas eDados

Pré-requisitosde Teste

Atividades deTeste

Registros deTeste

Relatório deTeste

Teste deAcompanhame

nto

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 requisitos1 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 Atendido

Livre de inconsistências internas

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.

Requisitos gerais

Convém que cada termo utilizado tenha um único significado

Requisitos Gerais

Manutenção Declarar se existe manutenção, e existindo o que está incluído

Disponibilizar visão geral das funções (nem todas precisam ser mencionadas), dados necessários e facilidades oferecidas

Visão geral das funções

Para cada função declarada identificar se a mesma é parte do produto, de uma extensão ou de um suplemento sem garantia por exemplo

Declarações sobre Funcionalidade

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

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

Declarações sobre Usabilidade

Adaptação às necessidades dos usuários

Identificar as ferramentas de adaptação e as 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.

—

Proteção contra infrações e direitos autorais

Declarar proteção contra infrações e direitos autorais, se existir.

?

Declarações sobre Eficiência Declarações sobre Eficiência 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

?

Declarações sobre Manutenibilidade Declarações sobre Manutenibilidade Pode conter declarações sobre

manutenibilidade ?

Declarações sobre Portabilidade Declarações sobre Portabilidade 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 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

Completitude

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

Todas as informações na documentação de usuário devem estar corretas.

Correção

Convém que a documentação de usuário não contenha ambigüidades nem erros

Não deve apresentar contradições internas nem com a Descrição de Produto.

Consistência

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

?

Convém que a documentação de usuário possua boa 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

Apresentação e Organização

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 Atendido

Instalação Deve ser passível de instalação com sucesso seguindo o manual, se puder ser feita pelo usuário.

3

Presença de funções Todas funções mencionadas na documentação de usuário devem ser executáveis da mesma forma nela descrita.

Os programas e dados devem corresponder a todas as declarações contidas na descrição de produto e na documentação de usuário

— Correção

As funções devem ser executadas de maneira correta para a realização de uma tarefa.

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.

Funcionalidade

Consistência

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.

O sistema não deve entrar em um estado no qual o usuário não consiga controlá-lo, nem deve corromper ou perder dados.

4 Confiabilidade Confiabilidade

Os programas devem reconhecer as violações da sintaxe estabelecida para entrada de dados.

?

Inteligibilidade Convém que as perguntas, mensagens e resultados dos programas sejam inteligíveis.

5

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.

Usabilidade

Apresentação e organização

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.

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.

Operacionalidade

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 palavras-chave.

—

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, start-start, 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, start-start, 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