USO DO QFD NA ESCOLHA DE PACOTE DE SOFTWARE DE SISTEMAS DE INFORMAÇÃO

Transcrição

1 USO DO QFD NA ESCOLHA DE PACOTE DE SOFTWARE DE SISTEMAS DE INFORMAÇÃO Jusane Farina Lara 1 1 ICMC- Instituto de Ciências Matemáticas e Computação, São Carlos, SP UNOESC Universidade do Oeste de Santa Catarina, Chapecó, SC, Brasil Rosely Sanches 2 2 ICMC-Instituto de Ciências Matemáticas e Computação Caixa Postal 668, São Carlos, SP, Brasil Abstract Since the great deal of software packages that exist nowadays to the applications of the system of information and also the difficulty that a client has to choose the packages that supplies the necessities, in that work is presented the use of QFD for choose of software package in system of information. The QFD will be used to translate the customer s needs into requirements of software packages using the rule NBR from the ABNT (Brazilian of Technical Rules). Keywords: Software Package, Rule NBR 12119, Quality Function Deployment (QFD) 1 Introdução Atualmente, as pessoas enfrentam dificuldade quando desejam adquirir um pacote de software para uma mesma aplicação na área de Sistemas de Informação que atenda as suas necessidades específicas. Um dos motivos é porque estão surgindo inúmeros pacotes de software, como por exemplo, pacotes para folha de pagamento, controle de estoque, etc. Diante de muitas opções de pacote de software para a mesma aplicação, o cliente defronta-se com um dilema: Qual escolher? A reação natural é que a escolha seja feita por aquele pacote que atenda melhor suas necessidades. Um dos problemas que surge e interfere na escolha relaciona-se a como traduzir as necessidades do cliente em requisitos de pacote de software. Essa tradução não é uma tarefa trivial, o processo de conversão é complicado e problemático. O problema de conversão das necessidades e desejos dos clientes em requisitos de pacote de software, é o mesmo encontrado nos setores de manufatura e serviço (ASI, 1995). Assim, neste trabalho, para solucionar o problema de tradução dos requisitos será utilizada uma abordagem do programa de Gerenciamento da Qualidade Total (TQM), originalmente utilizada em ambientes de manufatura tradicionais que pode ser de grande valia para introduzir qualidade no processo de seleção de pacote de software. Essa abordagem denomina-se QFD (Quality Function Deployment) (Haag, 1996).

2 O QFD é mais originalmente direcionado para desenvolvimento de software, mas neste trabalho ele será adaptado para seleção de pacote de software. Este trabalho está organizado em cinco seções. Nesta Seção foram apresentados a motivação e o objetivo deste trabalho. Na Seção 2 é apresentada a elaboração da matriz Casa da Qualidade, gerada em quatro etapas. Na Seção 3 é apresentado um Procedimento de Avaliação de Pacote de Software. Por fim, na Seção 4 são apresentadas as conclusões deste trabalho. 2 Elaboração da Matriz Casa da Qualidade Neste trabalho, a matriz Casa da Qualidade é gerada em quatro etapas. Na primeira etapa, determinam-se os requisitos do cliente e o grau de importância desses requisitos. Na segunda etapa, determinam-se os requisitos de produto. Na terceira etapa, elabora-se a matriz de relacionamentos e na quarta etapa, faz-se a geração do grau de importância das características de pacote de software. Para auxiliar a primeira etapa, instanciou-se o processo de aquisição de conhecimento IPAIA para o domínio QFD Casa da Qualidade. Esse processo de aquisição de conhecimento foi desenvolvido a partir do processo IPAIA genérico (Jubileu, 1999). 2.1 Processo de Aquisição de IPAIA, Instanciado para o Domínio QFD Casa da Qualidade O processo para aquisição de conhecimento explícito IPAIA (Jubileu, 1999) tem âmbito geral, podendo ser utilizado em qualquer domínio de conhecimento. O processo de aquisição de conhecimento IPAIA, contém cinco fases: (1) Início do Processo de Aquisição de, (2) Preparação da Sessão de Aquisição de, (3) Aquisição de, (4) Implementação do e (5) Avaliação do. A primeira fase é realizada apenas uma vez, ao contrário das fases seguintes que são executadas tantas vezes quantas forem necessárias, com o intuito de lapidar cada vez mais o conhecimento das necessidades do cliente. Na instanciação do processo para o domínio QFD Casa da Qualidade eliminou-se da fase 1 a atividade análise do problema, pois nem sempre o cliente tem a visão geral do domínio de conhecimento do pacote a ser adquirido. A Figura 2.1 representa a instanciação do processo IPAIA para o domínio QFD Casa da Qualidade. 3. Aquisição de 1. Início do Processo de A.C. 2. Preparação da Sessão de A.C. 5. Avaliação do 4. Implementação do Figura 2.1 Processo de Aquisição de IPAIA Instanciado

3 As fases do Processo de Aquisição de IPAIA instanciado para o domínio QFD Casa da Qualidade são descritas, detalhadamente, a seguir. Fase 1 Início do Processo de Aquisição de As atividades dessa fase, citadas a seguir, são consideradas críticas, pois nas fases subseqüentes podem ser desperdiçados muito tempo, esforços e recursos caso essa fase seja concluída de maneira incompleta. Selecionar a área de aplicação do pacote a ser adquirido; Definir o patrocinador; Selecionar os potenciais membros das sessões de aquisição de conhecimento. Dentre esses estão o engenheiro de conhecimento, os anotadores, os possíveis especialistas de domínio e os clientes. Estimular os possíveis participantes das sessões de aquisição de conhecimento realizando uma palestra inicial que deve focalizar o que é aquisição de conhecimento, sua importância para a organização, os principais conceitos relacionados à aquisição de conhecimento, entre outros. Na instanciação do processo IPAIA para o domínio QFD Casa da Qualidade existem dois tipos de ciclos, o ciclo de Visão Geral das Principais Necessidades do Pacote e o ciclo de Determinação de Importância das Características do Pacote. Primeiro Ciclo do Processo IPAIA Instanciado para o domínio QFD Casa da Qualidade: Ciclo de Visão Geral das Principais Necessidades do Pacote Esse ciclo tem como objetivos adquirir uma visão geral do domínio do conhecimento do pacote a ser adquirido e uma visão detalhada das características desse pacote. Nesse ciclo deseja-se conhecer as expectativas, os desejos declarados e os desejos implícitos do cliente, com relação ao software de prateleira que ele deseja adquirir. Para auxiliar essa atividade escolheu-se a técnica de brainstorming estruturado. A Figura 2.2 sintetiza os passos do primeiro ciclo de aquisição de conhecimento, detalhados a seguir. Preparação da Sessão de Brainstorming: nesse passo são selecionados os membros que participarão da sessão de brainstorming e é elaborado um plano (Quadro 2.1) para auxiliar o engenheiro de conhecimento a conduzir a sessão de brainstorming. Ciclo de Visão Geral das Principais Necessidades do Pacote Domínio de Equipe de A.C. Ciclo de Determinação de Importância das Características do Pacote 2. Preparação da Sessão de Brainstorming Estruturado Equipe A.C. selecionada Plano Sessão Brainstorming Estruturado TDRC inspecionada 5. Avaliação do TDRC Tabela Aquisição de 4. Implementação do Listagem de idéias Obtenção da Voz do Cliente Tabela 2.2 Figura 2.2 Primeiro Ciclo de Aquisição de IPAIA Instanciado

4 Plano Para Sessão De Brainstorming Estruturado 1 Introdução: o objetivo deste plano é orientar o engenheiro de conhecimento a conduzir uma sessão de brainstorming; 2 Gerenciamento: devem ser identificados os dados gerais para a realização da sessão de brainstorming; Local da Sessão: <local físico onde ocorrerá a sessão> Data da Sessão: <dd/mm/aa> Horário: <hh:mm> Tempo Total: <duração da sessão de aquisição de conhecimento> Engenheiro de : <nome> Anotadores/Assistentes: <nome> Especialista do Domínio: <nome especialista> Cliente: <nome do cliente> Meta da Sessão: adquirir uma visão geral do domínio do conhecimento do pacote a ser adquirido e uma visão detalhada das características desse pacote. 3 Tarefas: 3.1 O Engenheiro de deve deixar claro o motivo da participação de cada membro da equipe de aquisição de conhecimento, motivandoos e deixando-os relaxados para que a sessão transcorra de forma efetiva. Além disso, deve deixar claro o seu papel durante a sessão e o papel dos anotadores que devem registrar as informações relatadas tão logo apresentadas; Brainstorming Estruturado: 3.2 Levantar uma das funcionalidades considerando a listagem de idéias; 3.3 Solicitar que cada especialista exponha seu conhecimento a respeito da função levantada; 3.4 Anotar as respostas na coluna Dados Originais (Tabela 2.2); 3.5 Repetir as tarefas 3.2, 3.3 e 3.4 até que todas as funcionalidades identificadas tenham sido discutidas; 3.6 Converter os dados originais da segunda coluna para requisitos do cliente da quarta coluna da Tabela Cronograma: é importante a elaboração de um cronograma para melhor utilizar o tempo não atrapalhando, assim, o cotidiano dos membros de aquisição de conhecimento. 5 Recursos: preparar o local selcionado dispondo as cadeiras de forma circular, para que todos se vejam, e distribuindo papel e caneta a todos os membros da sessão para anotações. Se no local houver uma mesa onde todos possam se posicionar em forma circular, ótimo; caso não haja mesa, serão necessárias pranchetas que servirão de apoio para escrever. Quadro 2.1 Estrutura do Plano para a Sessão de Brainstorming Estruturado Aquisição do : nesse passo o plano para a sessão de brainstorming, elaborado anteriormente, é colocado em prática para se adquirir os conhecimentos de âmbito geral a respeito do pacote a ser adquirido pelo cliente. Durante a realização da sessão de brainstorming o Engenheiro de deve perguntar aos Especialistas de Domínio quais são as suas exigências de qualidade para o pacote a ser adquirido. Como trata-se de brainstorming estruturado, utiliza-se uma listagem de idéias a partir da qual todos os membros do grupo expõem seus comentários. Para a criação da listagem de idéias considerou-se as características de qualidade da norma (NBR 12119, 1996). As respostas devem ser anotadas na coluna dados originais da Tabela 2.2. Posteriormente, deve-se converter os dados originais da segunda coluna para requisitos do cliente da quarta coluna (Tabela 2.2). Para auxiliar essa etapa utiliza-se a técnica de desdobramento da cena (Cheng, 1995). O engenheiro de conhecimento deve exercer a função de moderador durante a aquisição de conhecimento. Pacote de Software: Identificação dos Clientes: N o Dados Originais Desdobramento da Cena (Onde, Como, Por que) Requisito do Cliente Tabela 2.2 Obtenção da Voz dos Clientes Implementação do : nesse passo o engenheiro de conhecimento deve fazer a preparação da tabela de desdobramento dos requisitos do cliente. Para elaborar essa tabela utiliza-se a técnica diagrama de afinidades (Cheng, 1995).

5 Nesse ciclo são preenchidas apenas as três primeiras colunas da tabela de desdobramento dos requisitos do cliente (Tabela 2.3). A coluna de grau de importância será preenchida no próximo ciclo. Nível Primário Nível Secundário Nível Terciário Grau de Importância Tabela 2.3 Tabela de Desdobramento dos Requisitos do Cliente (TDRC) Avaliação do : nesse passo o conhecimento adquirido deve ser verificado e validado. A verificação do conhecimento refere-se à confiabilidade conceitual e é realizada por meio de uma inspeção (Andert, 1999). Essa inspeção é realizada junto ao especialista de domínio, os clientes e o engenheiro de conhecimento, a fim de checar a consistência e completitude do conhecimento conceitual do domínio adquirido. Se o conhecimento adquirido referente ao domínio da aplicação não estiver completo, executa-se um outro ciclo brainstorming, caso contrário, inicia-se o segundo ciclo do processo IPAIA instanciado: Ciclo de Determinação de Importância das Características do Pacote. Segundo Ciclo do Processo IPAIA Instanciado para o domínio QFD Casa da Qualidade: Ciclo de Determinação de Importância das Características do Pacote O objetivo desse ciclo é adquirir o grau de importância para cada característica obtida no primeiro ciclo. O grau de importância deve ser obtido a partir do ponto de vista do cliente. Assim, nesse ciclo é selecionada a técnica de entrevista estruturada com o cliente. A Figura 2.3 sintetiza os passos do segundo Ciclo de Aquisição de. Ciclo de Determinação de Importância das Características do Pacote TDRC (três primeiras colunas) 2.Prepração Sessão Entrevista Estruturada Representante do Cliente selecionado Matriz Casa da Qualidade 5. Avaliação do conhecimento Plano Sessão Entrevista Estruturada TDRC (4 a coluna) 3. Aquisição de 4. Implementação do Figura 2.3 Segundo Ciclo de Aquisição de IPAIA Instanciado Preparação da Sessão de Entrevista: nesse passo é selecionado o representante do cliente que participará da sessão de entrevista e é elaborado um plano (Quadro 2.2) para auxiliar o engenheiro de conhecimento a conduzir a sessão de entrevista. Aquisição e Implementação do : nesse passo o plano para a sessão de entrevista, elaborado anteriormente, é colocado em prática a fim de se completar a tabela de desdobramento dos requisitos do cliente (Tabela 2.3), preenchendo-se a quarta coluna com o grau de importância de cada uma das características do pacote.

6 Plano Para Sessão De Entrevista Estruturada 1 Introdução: o objetivo deste plano é orientar o engenheiro de conhecimento a conduzir uma sessão de entrevista estruturada; 2 Gerenciamento: devem ser identificados os dados gerais para a realização da sessão de entrevista estruturada; Local da Sessão: <local físico onde ocorrerá a sessão> Data da Sessão: <dd/mm/aa> Horário: <hh:mm> Tempo Total: <duração da sessão de aquisição de conhecimento> Engenheiro de : <nome> Entrevistado/Fonte de : <nome do entrevistado> Meta da Sessão: questionar sobre o grau de importância de cada uma das características do pacote identificadas no primeiro ciclo. 3 Tarefas: 3.1 Deve ser exposto ao entrevistado a importância de suas informações. 3.2 Apresentar a Tabela de Desdobramento dos Requisitos do Cliente (Tabela 2.3) e questionar o cliente quanto à prioridade. 3.3 A escala de valores possíveis para o grau de importância deve ser de um a cinco. O valor um corresponde a nenhuma importância, o valor dois corresponde a pouca importância, o valor três corresponde a alguma importância, o valor quatro corresponde a importante e o valor cinco corresponde a muito importante. 4 Cronograma: deve ser estipulado um tempo para o entrevistado responder as questões. 5 Recursos: o local selecionado para a entrevista deve ser isolado de quaisquer outras pessoas que não façam parte da sessão, para que não haja interferência na lógica de raciocínio do cliente. Quadro 2.2 Estrutura do Plano para a Sessão de Entrevista Estruturada Avaliação do : nesse passo o conhecimento adquirido na tabela de desdobramento dos requisitos do cliente (TDRC) é verificado e validado. Isso é realizado conferindo a consistência e completitude do conhecimento obtido anteriormente e junto ao cliente. 2.2 Estratégia para Elaboração da Matriz Casa da Qualidade A estratégia para elaboração da matriz Casa da Qualidade é composta de quatro etapas (Figura 2.4): Requisitos do Cliente e o seu Grau de Importância Requisitos de Produto Matriz de Relacionamentos Geração do Grau de Importância das Características de Pacote de Software Requisitos do Cliente Grau Importância Características de Pacote de Software Descrição do Produto Manual do Usuário Programas e Dados Matriz de Relacionamentos Grau de Importância das Características de Pacote de Software Geração do Grau de Importância (%) Necessidades do Cliente (%) Figura 2.4 Partes da matriz Casa da Qualidade Procedimento para Determinação dos Requisitos do Cliente e do seu Grau de Importância Para auxiliar a obtenção das necessidades e desejos do cliente com relação às características do pacote a ser adquirido e na determinação do grau de importância dessas características, utilizou-se o processo de aquisição de conhecimento IPAIA, instanciado para o domínio QFD Casa da Qualidade, apresentado na seção anterior.

7 Procedimento para Determinação dos Requisitos de Produto Considerando-se o QFD tradicional, na primeira matriz Casa da Qualidade os requisitos do cliente são transformados em requisitos de produto; na segunda matriz Desdobramento das Partes os requisitos de produto são traduzidos em características das partes, e assim sucessivamente. No caso deste trabalho, utiliza-se apenas a primeira matriz Casa da Qualidade. Nas colunas dessa matriz são colocadas as características de qualidade para pacote de software (norma NBR 12119): descrição do produto, manual do usuário e programas e dados. O requisito de qualidade descrição do produto compõe-se das seguintes subcaracterísticas: requisitos gerais sobre o conteúdo da descrição do produto; identificações e indicações; declarações sobre funcionalidade, confiabilidade, usabilidade, eficiência e manutenibilidade. O requisito de qualidade manual do usuário está subdividido em completitude, correção, consistência, apresentação e organização. As subcaracterísticas do requisito de qualidade programas e dados são: funcionalidade, confiabilidade, usabilidade, eficiência, manutenibilidade e portabilidade. Um pacote de software está em conformidade com a norma NBR se atende a todos os requisitos definidos acima. Procedimento para Elaboração da Matriz de Relacionamentos O processo de correlação consiste em identificar o grau de influência ou interferência que os requisitos do cliente exercem sobre as características de pacote de software. Para se executar a correlação entre os requisitos do cliente e as características de pacote de software, considera-se individualmente cada item dos requisitos do cliente e define-se a sua correlação com todos os itens das características de pacote de software. Adota-se a seguinte escala para quantificar os relacionamentos: relacionamento forte vale nove (9) pontos, relacionamento moderado vale três (3) pontos e relacionamento fraco vale um (1) ponto. Geração do Grau de Importância das Características de Pacote Para realizar a geração do grau de importância das características de pacote, deve-se multiplicar o valor de cada correlação pelo respectivo grau de importância do requisito do cliente. Anotar o resultado no canto inferior de cada célula da matriz Casa da Qualidade. Em seguida, determina-se o grau de importância de cada característica de pacote (antepenúltima linha da matriz), somando-se os valores obtidos em cada coluna e colocando o resultado final dessa soma na célula correspondente. A geração do grau de importância das características de pacote (penúltima linha da matriz) pode então ser obtida, convertendo-se os valores do grau de importância em valores percentuais. Para isso, deve-se dividir o valor de cada coluna somatório da linha de grau de importância das características de pacote de software. Finalmente, deve-se somar os valore obtidos na penúltima linha da matriz da Figura 2.4 para cada uma das características de pacote de software e transcrever os resultados para as células correspondentes da última linha da matriz. 3 Procedimento de Avaliação de Pacote de Software Para realizar a avaliação de qualidade de pacote de software é necessário um modelo de processo de avaliação. O modelo de processo de avaliação é composto por três passos, que são: medição, pontuação e julgamento. Maiores detalhes sobre esse modelo estão descritos em (Lara, 2001). Para medição, as métricas criadas em forma de questionários apresentados em (Lara, 2001) são respondidos considerando-se o pacote de software.

8 No passo referente à pontuação, o nível de pontuação é avaliado considerando-se as respostas dadas nos questionários. O julgamento é uma decisão do cliente. O pacote de software que estiver com o valor medido mais próximo das necessidades do cliente, é um bom parâmetro para o cliente tomar sua decisão. 4 Conclusão Este trabalho teve como objetivo contribuir para a primeira parte do problema que interfere na escolha de um pacote de software, ou seja, na tradução das necessidades do cliente em requisitos de pacote de software. Para solucionar esse problema utilizou-se o método QFD. Apesar do QFD ser mais originalmente utilizado para desenvolvimento de software, neste trabalho ele foi adaptado para auxiliar na escolha de um pacote de software. O segundo problema que surge na escolha é saber que características do pacote de software devem ser observadas para que se compreenda melhor sua potencialidade e sua adequação às reais necessidades do cliente. Para solucionar esse problema foi desenvolvido um procedimento para escolha de pacote de software na área de sistemas de informação (Lara 2001). Esse procedimento avalia vários pacotes de software e inclui informações sobre as necessidades do cliente produzidas na matriz Casa da Qualidade, a qual foi apresentada neste trabalho. O que motivou o desenvolvimento deste trabalho foi a dificuldade que as pessoas enfrentam quando desejam adquirir um pacote de software para a mesma aplicação. Em função dessa dificuldade, utilizou-se o Processo de Aquisição de IPAIA, instanciado para o domínio QFD Casa da Qualidade. A realização da sessão de brainstorming estruturado no Processo de Aquisição de IPAIA instanciado, facilitou a obtenção das necessidades e desejos dos clientes e também foi importante no direcionamento das idéias para as características de pacote de software, reduzindo o tempo da sessão, sem reduzir os limites da imaginação. 5 Referências Bibliográficas (Andert, 1999) Andert, Ed. P. Jr. Expert System Software Verification, Validation and Test. Published in: ASQC Proceedings of the Second International Conference on Software Quality, 1992, [on line], [10/03/1999], Disponível na internet: (ASI, 1995) American Supplier Institute (ASI), Quality Function Deployment for Products: Implementation Manual, Dearborn, (Cheng, 1995) Cheng, L. C.; e outros, QFD: Planejamento da Qualidade, Belo Horizonte, UFMG, Escola de Engenharia, Fundação Christiano Ottoni, 1995, 262p. (Haag, 1996) Haag, S.; Raja, M. K., Schakade, L., Quality Function Deployment Usage in Software Development, Communications of the ACM, v.39, n.1, p.41-49, janeiro, (Jubileu, 1999) Jubileu, Andrea Padovan, Adquisição de Como Apoio ao Método de Engenharia Reversa FUSION-RE/I, Dissertação de Mestrado, ICMC-USP, 1999, 140p. (Lara, 2001) Lara, Jusane Farina, Um Procedimento para Escolha de Pacote de Software na área de Sistemas de Informação, VI Simpósio de Teses e Dissertações Defendidas, ICMC-USP, maio, (NBR 12119, 1996) NBR 12119, Tecnologia de Informação Pacotes de Software Teste e requisitos de qualidade Versão brasileira baseada na norma ISO/IEC 12119/1994, agosto, 1996.