avaliacao da ferramenta methodology explorer
TRANSCRIPT
![Page 1: Avaliacao Da Ferramenta Methodology Explorer](https://reader034.vdocuments.site/reader034/viewer/2022042616/55cf9c2f550346d033a8f07e/html5/thumbnails/1.jpg)
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.
![Page 2: Avaliacao Da Ferramenta Methodology Explorer](https://reader034.vdocuments.site/reader034/viewer/2022042616/55cf9c2f550346d033a8f07e/html5/thumbnails/2.jpg)
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
![Page 3: Avaliacao Da Ferramenta Methodology Explorer](https://reader034.vdocuments.site/reader034/viewer/2022042616/55cf9c2f550346d033a8f07e/html5/thumbnails/3.jpg)
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
![Page 4: Avaliacao Da Ferramenta Methodology Explorer](https://reader034.vdocuments.site/reader034/viewer/2022042616/55cf9c2f550346d033a8f07e/html5/thumbnails/4.jpg)
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.
![Page 5: Avaliacao Da Ferramenta Methodology Explorer](https://reader034.vdocuments.site/reader034/viewer/2022042616/55cf9c2f550346d033a8f07e/html5/thumbnails/5.jpg)
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.
—
![Page 6: Avaliacao Da Ferramenta Methodology Explorer](https://reader034.vdocuments.site/reader034/viewer/2022042616/55cf9c2f550346d033a8f07e/html5/thumbnails/6.jpg)
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.
![Page 7: Avaliacao Da Ferramenta Methodology Explorer](https://reader034.vdocuments.site/reader034/viewer/2022042616/55cf9c2f550346d033a8f07e/html5/thumbnails/7.jpg)
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
![Page 8: Avaliacao Da Ferramenta Methodology Explorer](https://reader034.vdocuments.site/reader034/viewer/2022042616/55cf9c2f550346d033a8f07e/html5/thumbnails/8.jpg)
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
![Page 9: Avaliacao Da Ferramenta Methodology Explorer](https://reader034.vdocuments.site/reader034/viewer/2022042616/55cf9c2f550346d033a8f07e/html5/thumbnails/9.jpg)
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”.
![Page 10: Avaliacao Da Ferramenta Methodology Explorer](https://reader034.vdocuments.site/reader034/viewer/2022042616/55cf9c2f550346d033a8f07e/html5/thumbnails/10.jpg)
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.
![Page 11: Avaliacao Da Ferramenta Methodology Explorer](https://reader034.vdocuments.site/reader034/viewer/2022042616/55cf9c2f550346d033a8f07e/html5/thumbnails/11.jpg)
Figura 5. “Instance Creator” – Selecionando a Metodologia base.
![Page 12: Avaliacao Da Ferramenta Methodology Explorer](https://reader034.vdocuments.site/reader034/viewer/2022042616/55cf9c2f550346d033a8f07e/html5/thumbnails/12.jpg)
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.
![Page 13: Avaliacao Da Ferramenta Methodology Explorer](https://reader034.vdocuments.site/reader034/viewer/2022042616/55cf9c2f550346d033a8f07e/html5/thumbnails/13.jpg)
Figura 8. Caracterizando uma Organização na ferramenta Config, Estação TABA.
![Page 14: Avaliacao Da Ferramenta Methodology Explorer](https://reader034.vdocuments.site/reader034/viewer/2022042616/55cf9c2f550346d033a8f07e/html5/thumbnails/14.jpg)
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).
![Page 15: Avaliacao Da Ferramenta Methodology Explorer](https://reader034.vdocuments.site/reader034/viewer/2022042616/55cf9c2f550346d033a8f07e/html5/thumbnails/15.jpg)
Figura 11. Definindo um Processo para um Projeto com a Ferramenta AdaptPro, Estação TABA.
![Page 16: Avaliacao Da Ferramenta Methodology Explorer](https://reader034.vdocuments.site/reader034/viewer/2022042616/55cf9c2f550346d033a8f07e/html5/thumbnails/16.jpg)
Figura 12. Definindo o Ciclo de Vida do Processo com a ferramenta AdaptPro, Estação TABA.
![Page 17: Avaliacao Da Ferramenta Methodology Explorer](https://reader034.vdocuments.site/reader034/viewer/2022042616/55cf9c2f550346d033a8f07e/html5/thumbnails/17.jpg)
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.
![Page 18: Avaliacao Da Ferramenta Methodology Explorer](https://reader034.vdocuments.site/reader034/viewer/2022042616/55cf9c2f550346d033a8f07e/html5/thumbnails/18.jpg)
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.
![Page 19: Avaliacao Da Ferramenta Methodology Explorer](https://reader034.vdocuments.site/reader034/viewer/2022042616/55cf9c2f550346d033a8f07e/html5/thumbnails/19.jpg)
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.
![Page 20: Avaliacao Da Ferramenta Methodology Explorer](https://reader034.vdocuments.site/reader034/viewer/2022042616/55cf9c2f550346d033a8f07e/html5/thumbnails/20.jpg)
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
![Page 21: Avaliacao Da Ferramenta Methodology Explorer](https://reader034.vdocuments.site/reader034/viewer/2022042616/55cf9c2f550346d033a8f07e/html5/thumbnails/21.jpg)
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:
![Page 22: Avaliacao Da Ferramenta Methodology Explorer](https://reader034.vdocuments.site/reader034/viewer/2022042616/55cf9c2f550346d033a8f07e/html5/thumbnails/22.jpg)
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
![Page 23: Avaliacao Da Ferramenta Methodology Explorer](https://reader034.vdocuments.site/reader034/viewer/2022042616/55cf9c2f550346d033a8f07e/html5/thumbnails/23.jpg)
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