UNIVERSIDADE FEDERAL DE PERNAMBUCO GRADUAO EM CINCIA DA COMPUTAO CENTRO DE INFORMTICA

DEFINIO DE CRITRIOS DE HOMOLOGAO,

PARA PRODUTOS DE SOFTWARE COM ESPECIFICAO INCIPIENTE, BASEADA EM UCD

TRABALHO DE GRADUAO

Aluna: Viviane Eugnia Siqueira de Souza (vess@cin.ufpe.br) Orientador: Alexandre Marcos Lins de Vasconcelos (amlv@cin.ufpe.br)

Dezembro de 2008

 When you can measure what you are speaking about, and express it in numbers, you know something about it; but when you can not measure it, and when you can not express it in numbers, your knowledge is of a meagre and unsatisfactory kind." Lord Kelvin

Pgina 2 de 64

Agradecimentos
Agradeo aos meus pais, irm e cunhado pelo apoio fornecido em todos os momentos que precisei, e pelo orgulho que demonstram ao falar das minhas vitrias, que na verdade so sempre nossas. Agradeo de forma muito carinhosa aos meus scios por me incentivarem e apoiarem, alm de contriburem de forma essencial para construo desse processo e execuo do estudo de caso. Agradeo ao meu namorado que sempre esteve presente e disponvel para me ajudar e representa a voz de razo nos momentos mais complicados. Por fim, agradeo aos representantes da empresa onde o estudo de caso foi realizado por estarem sempre dispostos a contribuir para o sucesso do projeto e por permitirem a citao do projeto neste trabalho.

Pgina 3 de 64

Resumo
Atravs da utilizao de tcnicas de design centrado no usurio, as atividades de definio de critrios de homologao podem ser realizadas mesmo com uma incipiente especificao do software. Embora a definio do software esteja incipiente, as expectativas dos usurios esto disponveis e podem ser explicitadas atravs da anlise do conhecimento tcito dos futuros usurios. A dificuldade em se definir a qualidade e o controle desta vem justamente das necessidades implcitas do software. O estudo de tcnicas de design centrado no usurio evoluiu bastante nos ltimos anos, devido ao grande interesse das organizaes que buscam solues aderentes s suas necessidades e projetos com boa usabilidade. Porm, as tcnicas de design centrado no usurio so adequadas no s para projeto de sistemas e interfaces. Estas podem ser usadas como importante estratgia de captura de informaes sobre a qualidade do software a ser projetado. O trabalho proposto neste documento busca abordar esse tema atravs da definio de um processo para orientar as atividades de coleta de informaes e mapeamentos dessas informaes em mtricas e critrios de homologao para posterior avaliao do software. Alm da exposio, o processo colocado em prtica atravs de um estudo de caso.

Pgina 4 de 64

ndice
Agradecimentos ............................................................................................................. 3 Resumo.......................................................................................................................... 4 ndice.............................................................................................................................. 5 ndice de Ilustraes ...................................................................................................... 7 ndice de Tabelas ........................................................................................................... 8 1 Introduo ............................................................................................................... 9 1.1 Motivao......................................................................................................... 9 1.2 Abordagem do Trabalho ................................................................................ 10 1.3 Estrutura do Documento ................................................................................ 11 2 Avaliao de Produtos de Software ...................................................................... 12 2.1 O que Avaliao de Produtos de Software? ............................................... 12 2.2 Como Avaliar? ............................................................................................... 14 2.2.1 Modelos de Qualidade ............................................................................ 14 2.3 O que So Mtricas de Software? ................................................................. 15 2.4 Porque avaliar um software? ......................................................................... 16 2.4.1 Importncia da avaliao para exportao de software.......................... 17 2.4.2 Competitividade na indstria de software ............................................... 18 2.4.3 Garantias na aquisio de software........................................................ 19 2.5 LAPS.............................................................................................................. 20 2.5.1 Mdulos de Avaliao............................................................................. 20 2.5.2 Diferenciais LAPS ................................................................................... 22 3 Design Centrado no Usurio ................................................................................. 24 3.1 Motivao....................................................................................................... 24 3.2 Princpios Bsicos.......................................................................................... 24 3.2.1 Processo baseado em pessoas .............................................................. 25 3.3 Viso Geral de Tcnicas e Mtodos .............................................................. 25 3.3.1 Questionrios.......................................................................................... 26 3.3.2 Tcnica de anlise de incidentes crticos: CIT........................................ 27 3.3.3 Avaliao por inspeo........................................................................... 27 3.3.4 Abordagem etnogrfica (mtodos de anlise observacional) ................. 27 3.3.5 Sorteio de Cartas .................................................................................... 28 3.3.6 Grupo Focal ............................................................................................ 28 3.3.7 Prottipo em papel.................................................................................. 28 3.4 Viso Geral do Processo ............................................................................... 29 3.5 Como utilizado na prtica?.......................................................................... 31 4 O Processo de Definio de Critrios de Homologao ....................................... 32 4.1 Motivao....................................................................................................... 32 4.2 Viso Geral .................................................................................................... 32 4.3 A Estrutura do Processo ................................................................................ 33 4.4 Descrio do Processo .................................................................................. 34 4.4.1 Objetivos................................................................................................. 34 4.4.2 Papis envolvidos ................................................................................... 35 4.4.3 Subprocessos ......................................................................................... 35 4.4.4 Entradas ................................................................................................. 35 4.4.5 Sadas..................................................................................................... 35

Pgina 5 de 64

4.5 Definir Papis e Responsabilidades .............................................................. 36 4.6 Subprocesso: Imerso no contexto da aplicao, da organizao e dos usurios .................................................................................................................... 37 4.6.1 Estudo da Organizao e identificao de prioridades ........................... 38 4.6.2 Anlise da Especificao Geral do Software .......................................... 38 4.6.3 Aplicao de Questionrio de Perfil ........................................................ 39 4.6.4 Definio de Perfis.................................................................................. 40 4.7 Subprocesso: Definio da Bancada de Testes ............................................ 41 4.7.1 Aplicao do Questionrio de Infra-estrutura.......................................... 42 4.7.2 Entrevista de identificao do ambiente de produo............................. 42 4.7.3 Preenchimento de Formulrio de Bancada de Testes ............................ 43 4.8 Subprocesso: Definio de mtricas e critrios de homologao.................. 44 4.8.1 Estudo Etnogrfico.................................................................................. 45 4.8.2 Questionrio de expectativas.................................................................. 46 4.8.3 Focus Group ........................................................................................... 46 4.8.4 Compilao de Dados e Definio de Mtricas ...................................... 47 4.8.5 Definio de Escalas de Aceitao......................................................... 48 4.9 Consideraes Finais .................................................................................... 49 5 Estudo de Caso..................................................................................................... 51 5.1 Objetivos do Estudo de Caso......................................................................... 51 5.2 O Escopo de Realizao do Estudo de Caso ................................................ 51 5.3 Metodologia de Trabalho ............................................................................... 53 5.4 Cronograma de Trabalho ............................................................................... 54 5.5 Relato do Estudo de Caso ............................................................................. 55 5.5.1 Subprocesso: Imerso no contexto da aplicao, dos usurios e da organizao........................................................................................................... 55 5.5.2 Subprocesso: Definio da Bancada de Testes ..................................... 56 5.5.3 Subprocesso: Definio de mtricas e escalas de aceitao ................. 57 5.6 Consideraes Finais .................................................................................... 58 6 Concluso e Trabalhos Futuros ............................................................................ 60 6.1 Principais Contribuies................................................................................. 60 6.2 Principais Dificuldades Encontradas .............................................................. 60 6.3 Trabalhos Relacionados ................................................................................ 61 6.4 Trabalhos Futuros.......................................................................................... 61 6.5 Consideraes Finais .................................................................................... 62 Referncias .................................................................................................................. 63

Pgina 6 de 64

ndice de Ilustraes
Ilustrao 1: Processo de Avaliao de Software - ISO 14598-5 ................................. 13 Ilustrao 2: Modelo de Qualidade - ISO 9126 (Qualidade interna e externa) ............. 14 Ilustrao 3: Modelo de Qualidade - ISO 9126 (Qualidade em uso) ............................ 14 Ilustrao 4: Mdulos LAPS ......................................................................................... 21 Ilustrao 5: Processo de Design Centrado no Usurio............................................... 30 Ilustrao 6: Processo de Definio de Mtricas e Critrios de Homologao ............ 34 Ilustrao 7: Fluxo de Subprocessos ........................................................................... 36 Ilustrao 8: Subprocesso de Imerso no contexto da aplicao, da organizao e dos usurios........................................................................................................................ 37 Ilustrao 9: Subprocesso: Definio da Bancada de Testes ...................................... 41 Ilustrao 10: Suprocesso de Definio de Mtricas e Escalas de Aceitao ............. 44 Ilustrao 11: Mtricas de Usabilidade......................................................................... 58

Pgina 7 de 64

ndice de Tabelas
Tabela 1: Papis e Responsabilidades ........................................................................ 37 Tabela 2: Estudo da Organizao e identificao de prioridades ................................ 38 Tabela 3: Anlise da Especificao Geral do Software................................................ 39 Tabela 4: Aplicao de Questionrio de Perfil ............................................................. 40 Tabela 5: Definio de Perfis ....................................................................................... 40 Tabela 6: Aplicao do Questionrio de Infra-estrutura ............................................... 42 Tabela 7: Entrevista de identificao do ambiente de produo .................................. 43 Tabela 8: Preenchimento de Formulrio de Bancada de Testes ................................. 43 Tabela 9: Estudo Etnogrfico ....................................................................................... 45 Tabela 10: Questionrio de expectativas ..................................................................... 46 Tabela 11: Focus Group............................................................................................... 47 Tabela 12: Compilao de Dados e Definio de Mtricas.......................................... 48 Tabela 13: Definio de Escalas de Aceitao ............................................................ 49

Pgina 8 de 64

1 Introduo
Este captulo introduz o trabalho descrito neste documento, relatando em linhas gerais a pesquisa desenvolvida. Na Seo 1.1 descrita a motivao do trabalho realizado, apresentando as principais necessidades existentes, que levaram ao seu desenvolvimento. A Seo 1.2 descreve os principais objetivos da pesquisa realizada, definindo a abordagem utilizada para alcanar tais objetivos. A Seo 1.3 apresenta a organizao deste documento, definindo o assunto abordado em cada um dos captulos.

1.1 Motivao
A atividade de desenvolvimento de software torna-se cada vez mais complexa, medida que usurios sentem a necessidade de interagir com sistemas para realizao de diversas tarefas, da forma mais automatizada, confortvel e funcional possvel. Assim, os processos de concepo, elaborao e construo do software precisaram abandonar o paradigma da velha computao, onde era valorizado o que as mquinas podiam fazer e partir para o paradigma da nova computao [1]. Este valoriza o que os usurios so capazes de realizar atravs do software, deixando clara a importncia qualidade dos produtos de software para o sucesso na sua adoo. A fim de atender essas necessidades dos usurios, tornou-se essencial orientar o desenvolvimento do software com foco na qualidade do produto. Entende-se por produto de software, o conjunto de programas de computador, procedimentos, possvel documentao e dados associados [2]. Porm, para garantir a qualidade de um produto de software, necessrio identificar as exigncias implcitas e explcitas para, posteriormente, avali-lo. O processo de identificao de exigncias relativamente simples em softwares concludos, pois o feedback de futuros usurios pode ser utilizado como fonte crucial de informao. No entanto, esse processo de identificao de exigncias ainda bastante complexo em software em fase de concepo, pois envolve o conhecimento tcito e

Pgina 9 de 64

expectativas dos futuros usurios, informaes sobre o negcio da aplicao, alm da entropia da infra-estrutura na qual o software ser implantado. Mediante essas dificuldades, o trabalho proposto neste documento busca abordar esse tema, que embora seja essencial, ainda permanece polmico e pouco difundido na engenharia de software. Alm dos fatores mencionados anteriormente, um importante fator que motivou o desenvolvimento deste trabalho foi o fato da autora se aperfeioar em qualidade de software desde 2006. Atuando como Gerente de Qualidade e Gerente de Projetos em uma empresa de desenvolvimento de software e avaliao de produtos, a autora precisou coordenar a construo da tecnologia de avaliao da empresa, e participar como consultora assistente da especificao de exigncias implcitas e explcitas de um software em fase de concepo, o relato desta experincia se encontra brevemente descrito na seo de Estudo de Caso, do Captulo 5. Mediante essas circunstncias, este trabalho busca propor uma soluo para os problemas enfrentados, de forma que as atividades de especificao de mtricas e critrios de homologao possam vir a ser executadas de uma maneira simplificada e estruturada dentro do processo de avaliao, e sem os problemas previamente identificados.

1.2 Abordagem do Trabalho

O objetivo principal desta proposta desenvolver um processo de definio de mtricas de qualidade e critrios de homologao. Essa atividade bastante complexa, pois softwares em fase de concepo no possuem uma especificao completa e a identificao das necessidades da organizao e dos usurios so fracamente definidas. Visto que atender s necessidades acima fator crucial para o sucesso e adoo do software, foi desenvolvido neste trabalho um processo de definio de critrios de homologao adaptando tcnicas de design centrado no usurio para identificar as necessidades e defini-las de forma quantitativa. Assim, o futuro fornecedor do software poder orientar o desenvolvimento com foco na garantia da qualidade do produto e ser homologado de forma imparcial numa posterior avaliao. Este objetivo est organizado e dividido nas seguintes metas: 1. Estudo da avaliao de produtos de softwares Pgina 10 de 64

2. Estudo de design centrado no usurio 3. Criao do Processo de Definio de Mtricas de Qualidade e Critrios de Homologao baseado em tcnicas de design centrado no usurio. 4. Realizar um estudo de caso para testar o processo proposto

1.3 Estrutura do Documento

Alm deste captulo introdutrio, o trabalho est organizado da forma descrita a seguir: O Captulo 2 consolida alguns aspectos a respeito da avaliao de produtos de software na literatura e uma viso geral da tecnologia LAPS de avaliao. O Captulo 3 apresenta uma viso geral de Design Centrado no Usurio (Usercentered design UCD) que ir orientar a definio do processo proposto nesse trabalho. No Captulo 4 propomos a configurao do processo que descreve em detalhes as atividades, entradas, sadas, papis e responsabilidades do processo de definio de critrios de homologao para produtos de software. O objetivo do processo ser descrito em um nvel de detalhes suficiente, de forma que o mesmo possa ser utilizado por qualquer consultor treinado. Para contemplar um maior nvel de detalhes de informaes, alguns templates detalhados sero propostos tambm nesse captulo para orientar de forma mais objetiva algumas atividades consideradas chaves no contexto de definio de critrios de homologao. No Captulo 5 apresenta-se o estudo de caso do processo proposto em um projeto real. Resultados da aplicao do processo proposto tambm so apresentados neste captulo. No Captulo 6 apresentamos as concluses do trabalho, as contribuies trazidas por este, as principais dificuldades enfrentadas, os trabalhos relacionados e possveis extenses para trabalhos futuros a partir desse trabalho.

Pgina 11 de 64

2 Avaliao de Produtos de Software

Neste captulo so apresentados conceitos relacionados avaliao de produtos de software, sendo apresentadas algumas normas nacionais e internacionais de qualidade que serviram como base para o processo descrito nesta dissertao. A Seo 2.1 descrever conceitos bsicos que definem a avaliao de software. A Seo 2.2 apresenta os benefcios de uma avaliao. A Seo 2.3 apresenta a tecnologia LAPS de Avaliao de Produtos de Software. Nesta Seo feito um detalhamento dos mdulos de qualidade avaliados pelo laboratrio e seus diferenciais.

2.1 O que Avaliao de Produtos de Software?

A avaliao de produtos de software definida, de acordo com a ISO 145985[3], como: Operao tcnica que consiste em elaborar um julgamento de uma ou mais caractersticas de um produto de software de acordo com um procedimento definido. O processo de avaliao deve possuir 4 caractersticas principais: 1. Repetvel; 2. Reprodutvel; 3. Imparcial; 4. Objetivo. O processo pode ser instanciado para avaliao do produto por

desenvolvedores, adquirentes ou agentes externos dependendo dos objetivos e infraestrutura da organizao. Abaixo mostraremos o processo proposto na ISO 14598-5 para avaliao por agentes externos.

Pgina 12 de 64

Ilustrao 1: Processo de Avaliao de Software - ISO 14598-5

Cada fase descrita acima possui uma srie de recomendaes, porm, como toda norma, ela recomenda o que fazer, mas no explica como deve ser feito. Alm dessa dificuldade em definir como ser a avaliao, ainda enfrentamos o problema da imaturidade da indstria de software que veio se consolidar como indstria propriamente dita h menos de 50 anos. Bastante diferente da engenharia, por exemplo, que j possui padres muito bem definidos e quantificveis. As etapas Estabelecimento dos requisitos da avaliao e Especificao da avaliao so etapas crucias da avaliao, pois neste momento que precisamos definir o QUE ser medido no software e quais so os nveis aceitveis dessas medidas. Nas prximas sees falaremos um pouco mais dessas duas etapas.

Pgina 13 de 64

2.2 Como Avaliar?

2.2.1 Modelos de Qualidade
Para que a avaliao seja mais efetiva importante que se utilize um modelo de qualidade que permita estabelecer e avaliar requisitos de qualidade e tambm que o processo de avaliao seja bem definido e estruturado [4]. Recomenda-se, na norma ISO 14598, a utilizao do modelo de qualidade proposto na ISO 9126, que o mais difundido na indstria. Este modelo prope a diviso da qualidade do produto de software em qualidade interna, externa e em uso.

Ilustrao 2: Modelo de Qualidade - ISO 9126 (Qualidade interna e externa)

Ilustrao 3: Modelo de Qualidade - ISO 9126 (Qualidade em uso)

Pgina 14 de 64

A qualidade interna considera o produto como um item esttico e o avalia sem precisar execut-lo. A qualidade externa avalia o software em execuo por profissionais capacitados. J a qualidade em uso prope que o software seja inserido no seu ambiente de produo e testado por futuros usurios, onde a partir dessa utilizao deve-se captar a impresso causada pelo software e mtricas. Cada viso da qualidade, descritas acima, possuem um conjunto de caractersticas e sub-caractersticas de qualidade que fornecem a base para a especificao dos requisitos de qualidade. As sub-caractersticas so discretizadas atravs de propriedades mensurveis, fsicas ou abstratas, de uma entidade, conhecidas como atributos de qualidade. Os requisitos da qualidade do produto de software so essenciais para: Especificao; Planejamento; Desenvolvimento; Avaliao.

A aplicao de normas internacionais ajuda a garantir que os critrios de homologao do software sejam: Claros e precisos; Compatveis com as necessidades dos usurios; Corretos, completos e consistentes; Verificveis e mensurveis.

2.3 O que So Mtricas de Software?

Segundo a ISO 14598-1: Todo atributo interno quantificvel do software e todo atributo externo quantificvel do software interagindo com seu ambiente e que se correlacione com uma caracterstica pode ser definido como uma mtrica.

Pgina 15 de 64

No contexto do mercado de software, Paul Goodman define mtricas de software como: A aplicao contnua de tcnicas de medies aos processos de desenvolvimento e aos produtos de software para o fornecimento de informaes gerenciais, que conseqentemente so utilizadas para a melhoria dos processos e da qualidade do produto[5]. Toda mtrica definida precisa ser medida. Segundo Norman Fenton, medio o processo atravs do qual smbolos e nmeros so atribudos a atributos de entidades do mundo real de uma maneira que os mesmos possam ser descritos atravs de regras claramente definidas. [5] Uma entidade uma pessoa, lugar, evento, perodo de tempo ou outro objeto que ser caracterizado pela medio. J um atributo uma caracterstica ou propriedade de uma entidade. Para medir precisamos determinar a entidade e o seu atributo a ser medido. Alm de explicitar as regras que definem como os atributos sero medidos [6]. As mtricas possuem as seguintes propriedades desejveis: 1. Facilmente calculada, entendida e testada; 2. Passvel de estudos estatsticos; 3. Expressa em alguma unidade; 4. Obtida o mais cedo possvel no ciclo de vida do software; 5. Passvel de automao; 6. Repetvel e independente do observador; 7. Sugere uma estratgia de melhoria. Porm, a mtrica por si s no explica nada, pois esta precisa estar inserida em um contexto e associada ao contexto de cada produto. Por exemplo, podemos ter uma nica mtrica aplicada a dois produtos de software diferentes e que proporcionem o mesmo resultado e mesmo assim um produto pode ter qualidade e o outro no. Depende do quo complexo cada produto desses e qual a real necessidade de quem os utilizar. Para tanto so utilizadas escalas de aceitao para cada mtrica.

2.4 Porque avaliar um software?

Grandes empresas com foco em alta produtividade geralmente investem muitos recursos em aquisio de software e automatizao de atividades. Porm, como esta Pgina 16 de 64

empresa pode saber que est adquirindo o melhor software disponvel no mercado? Quem garante que ela no passar dias com sua linha de produo parada em virtude da indisponibilidade de um sistema? Visto que a falta de qualidade de algum sistema desses pode causar indisponibilidade de servios para diversos clientes, falta de credibilidade da empresa e perdas milionrias, no possvel adquirir um software tendo como nico parmetro o seu preo. Geralmente empresas que utilizam softwares nesse contexto, compram softwares relativamente maduros e indicados por outras pessoas. Porm, no h garantia que esse sistema ir se adaptar s necessidades da empresa e sua infraestrutura. Em muitos casos, verifica-se a qualificao da empresa fornecedora atravs das suas certificaes. Porm, a grande parte das certificaes de empresas de software relativa qualidade de processo, que no implica diretamente na qualidade do produto. Uma questo que envolve tantos recursos e expectativas no deve ser tratada de forma parcial, necessrio identificar quantitativamente a qualidade do produto e a sua aderncia organizao adquirente. Evitando assim uma perda de produtividade absurda apenas porque o software de difcil manipulao ou no pode ser evoludo para atender requisitos posteriores, por exemplo. Assim, uma avaliao de um produto de software quantitativa, imparcial e que identifique a aderncia do software s necessidades especficas de uma organizao essencial para o sucesso e adoo de um software. A avaliao de um software, assim como seu desenvolvimento, possui um custo associado, desta forma para que esse processo seja iniciado necessrio que a qualidade do produto esteja associada aos objetivos estratgicos da empresa.

2.4.1 Importncia da avaliao para exportao de software

De acordo com o Ministrio de Cincia e Tecnologia [7], o Brasil um dos dez maiores mercados do mundo, em se tratando de tecnologia da informao. Devido a este fator, a indstria nacional, apesar de diversificada e sofisticada, dedica-se em maior parte, a atender ao mercado interno.

Pgina 17 de 64

Entretanto, a crescente abertura e internacionalizao dos mercados tm aumentado intensamente a competio no mercado interno, exigindo que a indstria brasileira de software amplie sua participao no mercado global de software e servios. Dessa forma, imperativo atingir padres internacionais de qualidade e produtividade no setor de software, como condio essencial na busca da competitividade mundial nesta indstria. Alm disso, aspectos como a acessibilidade, usabilidade e a localizao dos produtos exigem uma correta adequao dos produtos aos mercados cada vez mais exigentes. Este cenrio levou o governo federal a considerar a qualidade de software como a principal motivao das medidas dedicadas pelo ao setor no mbito da Poltica Industrial, Tecnolgica e de Comrcio Exterior PITCE [7]. Assim, para garantir a qualidade do produto necessrio analis-lo de forma criteriosa e verificar se o software se adequa s necessidades dos futuros usurios. Assim, importante que a avaliao seja baseada em tcnicas e padres maduros disponibilizados pelas principais instituies normativas em sinergia com programas de apoio a esta iniciativa: Programas: o MCT/PBQP - Programa Brasileiro da Qualidade e Produtividade, do Ministrio de Cincia e Tecnologia o MCT/GT4: Grupo de Trabalho Qualidade e Produtividade em Software, do Ministrio de Cincia e Tecnologia o SOFTEX - Sociedade Brasileira para Promoo da Exportao de Software rgos normativos: o ISO International Organization for Standardization o ABNT Associao Brasileira de Normas Tcnicas o IEEE - Institute of Electrical and Electronics Engineers, Inc.

2.4.2 Competitividade na indstria de software

Seja qual for o mercado-alvo para um novo produto de software, as condies de competio tornar-se-o cada vez mais acirradas. Dentro deste contexto, tambm

Pgina 18 de 64

no h espao para produtos que no tenham um padro de qualidade mundial e que atendam as necessidades do seu cliente-alvo ou e/ou usurio-final. O contexto nacional caracterizado pela necessidade de um processo gil e de custo adequado de avaliao do produto de software que possa estar alinhado s estratgias da empresa. A rapidez relativa de desenvolvimento de produtos complexos requer apoio de servios especializados no sentido de garantir que tais produtos possam ganhar o mercado com relativa segurana. Alm disso, importante a propagao da idia de que a qualidade do produto de software representa um conjunto de caractersticas que so construdas com o produto ao longo de processos de desenvolvimento. Para uma empresa desenvolvedora de software, o investimento no

desenvolvimento de um produto de software pequeno quando comparado ao investimento necessrio introduo deste produto no mercado. Uma avaliao prvia desse produto traz maior segurana ao se fazer os investimentos necessrios sua comercializao. Alm disso, o maior ganho para a indstria de software nacional a existncia de uma alternativa transparente e imparcial para avaliar seu produto. A chave para tornar esta alternativa atraente para a indstria o fato dela poder se valer da avaliao como um diferencial estratgico, que diferencia o bom produto de outro de qualidade inferior.

2.4.3 Garantias na aquisio de software

A definio, escolha e obteno de software que sejam adequados estratgia de uma organizao podem ser fatores determinantes para o sucesso de empreendimentos envolvendo instituies pblicas e privadas, pois o uso das tecnologias da informao e comunicao est intensamente presente nas atividades do dia-a-dia das pessoas e empresas. Portanto, a aquisio de produtos de software uma tarefa extremamente crtica para as empresas que os compram. Porm, a diversidade de solues disponveis e falta de indicadores para compar-las torna o processo de aquisio ainda mais complexo. Em virtude deste complicador, em inmeros casos, os objetivos estabelecidos ficam distantes dos resultados efetivamente alcanados e a qualidade destes fica aqum do esperado. Pgina 19 de 64

Neste contexto, com a especificao prvia dos critrios de qualidade dos produtos, proposta por esse trabalho, os adquirentes podero analisar as opes existentes e adquirir os produtos levando em conta a qualidade do software.

2.5 LAPS
O LAPS, Laboratrio de Avaliao de Produtos de Software [8], teve incio no ano de 2004, em parceria com o Centro de Informtica da Universidade Federal de Pernambuco (CIn-UFPE). Surgiu a partir da identificao da necessidade de se avaliar, de forma integrada e flexvel, a qualidade do produto de software. O laboratrio tem como misso utilizar e promover a utilizao de solues e ferramentas de alta tecnologia na avaliao de produtos de software, contribuindo para o sucesso dos clientes atravs da garantia da qualidade de seus produtos. Inicialmente, o laboratrio definiu os processos de avaliao de software e o portflio de servios, alm do credenciamento dos colaboradores na metodologia MEDE-PROS [9]. Posteriormente, o laboratrio executou 6 avaliaes-piloto para validao de sua tecnologia. Houve tambm algumas iniciativas de propaganda do laboratrio, tais como cursos de qualidade de produtos de software e o Frum Melhoria do Produto de Software Brasileiro [8]. Estas iniciativas foram extremamente importantes para ressaltar a importncia do tema no contexto nacional. Na fase de estruturao inicial o LAPS contou com o apoio decisivo do CIn-UFPE atravs de recursos humanos, infra-estrutura e parceria na publicao de artigos e trabalhos acadmicos de graduao e ps-graduao. Atravs dos projetos-piloto de avaliao, o laboratrio pde medir eficcia da tecnologia LAPS e da sua metodologia de avaliao. Assim, o LAPS adquiriu o knowhow necessrio para realizar avaliaes de produtos de software e teve a oportunidade de identificar seus pontos de melhoria.

2.5.1 Mdulos de Avaliao

O LAPS prope um modelo de avaliao quantitativa baseado no conceito de mdulos. Um mdulo de avaliao LAPS um conjunto de definies, mtricas e artefatos dirigidos por um processo com a finalidade de avaliar um software de acordo com a caracterstica solicitada pelo cliente.

Pgina 20 de 64

A metodologia adotada para a criao dos mdulos foi baseada na norma ISO/IEC 9126, permitindo a identificao e combinao, por grau de importncia, a anlise a ser feita. Sendo assim, a avaliao pode ser feita de forma especfica ou abrangente.

Ilustrao 4: Mdulos LAPS

A tecnologia LAPS foi desenvolvida com foco na extensibilidade e possvel incluso de novos mdulos. Atualmente, a tecnologia LAPS possui os seguintes mdulos: Cdigo Fonte - Identificao do grau de qualidade do cdigo escrito, avaliado de acordo com padres e estilo de programao difundidos na indstria; Usabilidade Deteco de no-conformidades em relao a normas e padres de usabilidade; Funcionalidade - Avaliar o conjunto de funes especificadas e suas propriedades verificando seu grau de adequao;

Pgina 21 de 64

Falhas e Recuperao - Analisa falhas de um sistema computacional visando determinar o ndice de erros e como o sistema se comporta quando submetido a estes; Desempenho - Estima tempo e recursos consumidos, identificando se o sistema atende s necessidades de performance dos usurios no ambiente real; Arquitetura - Avalia se a arquitetura projetada para o sistema capaz de atender s funcionalidades desejadas; Portabilidade - Medir a facilidade com a qual a unidade de software pode ser transferida de um sistema computacional ou ambiente para outro [10]; Controle de Acesso e Proteo de Dados Verificar a implementao de uma srie de controles (polticas, prticas, procedimentos, estruturas organizacionais e funes de software); Documentao do Usurio - Avalia se a documentao do usurio est clara no ensino da utilizao do produto segundo as normas e padres; Documentao do Sistema - Visa medir a qualidade dos documentos gerados no processo de desenvolvimento do sistema; Competidores - Avaliar a posio do produto no mercado em relao aos seus concorrentes; Especialista - Inspeo de um produto de software por um profissional experiente no domnio da aplicao, visando identificar possveis problemas referentes ausncia de regras de negcio importantes no contexto do sistema.

2.5.2 Diferenciais LAPS

Avaliao Abrangente e Quantitativa A avaliao abrangente do produto toma como referncia uma viso geral e leva em considerao o contexto no qual o produto estar inserido. Assim, uma avaliao abrangente contempla, por exemplo: Inspeo dos aspectos dinmicos (funcionais) de um produto, de modo a exercitar o software com dados reais em ambientes controlados.

Pgina 22 de 64

Utilizao de tcnicas de anlise esttica, verificando o software em busca de determinadas propriedades. A avaliao abrangente torna-se mais poderosa quando aliada a um carter quantitativo, ao passo que fornece um meio efetivo para identificao e comparao de caractersticas dos produtos de software. Avaliao por Especialista no Domnio A participao de um avaliador especialista do domnio, profissional

especializado na rea objeto do software avaliado, um importante fator para contribuio da identificao de necessidades implcitas e na medio do grau de aderncia funcional do sistema ao seu uso proposto no dia-a-dia dos usurios finais [11]. O especialista no domnio da aplicao capaz de verificar o cumprimento dos requisitos definidos e identificar a acurcia e adequao s necessidades implcitas. Equipe independente de homologao Uma avaliao de software requer um ambiente controlado, uma srie de ferramentas de medio, alm de recursos humanos altamente especializados e caros. Para uma empresa que libera releases de um software mensalmente seria complexo manter toda essa estrutura para avaliar seu produto in house. J para empresas que adquirem software esporadicamente, a situao muito mais complexa, pois o custo da instalao do ambiente de homologao pode superar o valor do prprio software. Alm de manter a tecnologia de avaliao aderente s constantes mudanas tecnolgicas e de metodologias de desenvolvimento. Neste contexto, uma avaliao de terceira parte constitui um elemento importante no processo de homologao de software.

Pgina 23 de 64

3 Design Centrado no Usurio

Este captulo ir embasar o design centrado no usurio. Na Seo 3.1 descrita a motivao para utilizao de design centrado no usurio. A Seo 3.2 descreve os princpios bsicos, a Seo 3.3 detalha as tcnicas e mtodos e a 4.4 descreve o processo. J a Seo 3.5 apresenta como as tcnicas so usadas na prtica.

3.1 Motivao
O design centrado no usurio prope deslocar o foco do design da aplicao para o usurio que utilizar o sistema. Tendo como principais objetivos melhorar a usabilidade da aplicao e aumentar a utilidade e qualidade dos sistemas. Avaliar as pessoas importante, pois muitas vezes (pra no dizer todas), no h condies de mudar este importante fator: quem vai usar a soluo. Processos relacionados participao de usurios nos projetos existem desde o incio da informtica, mas s recentemente tm-se percebido a real importncia do uso destas metodologias no sucesso ou fracasso de um projeto. As tcnicas de User-Centered Design, que ao mesmo tempo um processo e uma "filosofia", procuram garantir a aderncia do software que est sendo desenvolvido aos seus usurios finais. O resultado um custo menor e uma maior satisfao e produtividade por parte do usurio. O envolvimento do usurio desde os estgios iniciais fundamental e garante inclusive uma aceitao maior do resultado [12]. O no envolvimento do usurio no processo certamente vai causar uma diferena de expectativa, que gerar alteraes de escopo e conseqentemente custo.

3.2 Princpios Bsicos

O design centrado no usurio se baseia em projetar sistemas atravs de um processo focado em objetivos de usabilidade, caractersticas dos usurios, ambiente, tarefas e fluxo de atividades. O UCD segue uma srie bem definida de mtodos e tcnicas para anlise, projeto e avaliao de softwares. Este processo interativo,

Pgina 24 de 64

onde as etapas de design e avaliao so priorizadas no incio do projeto, postergando a implementao. De acordo com Jeffrey Rubin [13], os principais aspectos do UCD so: 1. Foco em usurios e atividades a. Busca de informaes estruturada e sistemtica b. Profissionais treinados e experientes para conduzir as sesses de coleta de dados 2. Medio e testes empricos de utilizao de produto a. Foco na facilidade de uso e aprendizagem b. Teste atravs de prottipos com futuros usurios 3. Design interativo a. Produto projetado, modificado e testado constantemente. b. Proporcionar o redesigning cedo atravs de testes de modelos conceituais e exposio de percepes.

3.2.1 Processo baseado em pessoas

Os stakeholders responsveis por repassar informaes aos projetistas do sistema sero extremamente importantes, pois conhecem as necessidades e preferncias dos usurios finais. No entanto, necessrio ter bastante cuidado para que o design no seja baseado apenas nas necessidades de uma parcela de usurios. Estas pessoas podem ser usadas para definir rumos estratgicos do produto ou servio e tomar decises tticas. As consideraes de cada pessoa so to relevantes quanto o seu grau de proximidade com o sistema. Porm, no so s os principais usurios do sistema que sero ouvidos, pois o processo de definio de perfil e prioridade auxilia os designers a compreender o que contemplar e o que no contemplar em um software. [14]

3.3 Viso Geral de Tcnicas e Mtodos

As tcnicas e mtodos utilizados no processo de design centrado no usurio so tcnicas genricas que combinam teoria de cognio em seres humanos e informaes especficas sobre funes e tarefas para definir classes representativas de usurios. Nas prticas de UCD [15], algumas questes so essenciais: Pgina 25 de 64

1. Quem o usurio? 2. Quais as tarefas e metas do usurio? 3. Qual o nvel de experincia do usurio com o sistema a ser desenvolvido, com atividades similares e com o ambiente? 4. Que funcionalidades o usurio espera? 5. Que informaes o usurio precisa, e mostradas de que forma? 6. Como o usurio acha que o software deveria funcionar? Anlise de usurios no deve ser baseada em suposies. Para isso, necessrio: Observar, entrevistar e promover pesquisas para analisar os usurios; Podem ser utilizadas sesses de discusses com os usurios para se determinar suas necessidades e caractersticas. importante tambm observar usurios no trabalho isso permite avaliar situaes reais. Em geral, grande parte das tarefas de design centrado no usurio realizada em campo, isto , no ambiente de trabalho ou onde os futuros usurios exercem suas atividades. Todas as questes citadas acima sero definidas a seguir em suas tcnicas especficas. O objetivo da utilizao destas tcnicas explicitar informaes crticas na fase inicial do projeto, quando as implicaes podem ser examinadas e atendidas com menor impacto.

3.3.1 Questionrios
Questionrios so excelentes fontes de feedback dos usurios aps utilizar sistemas, porm tambm so extremamente teis para identificar de forma objetiva o perfil das pessoas. Os questionrios devem ser normalizados e as respostas so analisadas psicometricamente. Uma avaliao global desses questionrios tambm fornece informaes sobre [16]: Eficcia percebida; Controle; Aprendizagem;

Pgina 26 de 64

Satisfao.

3.3.2 Tcnica de anlise de incidentes crticos: CIT

A tcnica de anlise de incidentes crticos um mtodo de identificao de fatos incomuns por parte dos utilizadores, a fim de adquirir conhecimentos sobre como melhorar a qualidade de um sistema/processo. A tcnica uma mistura de outras tcnicas, por exemplo, um questionrio de tipo aberto, retrospectiva de dados, entrevistas. As trs fases da CIT so: 1. Recolher fatos; 2. Analisar o contedo; 3. Inferir a forma de melhorar a qualidade com base nas experincias anteriores. O aspecto mais importante na execuo de um CIT identificar o que levou o sistema a responder de forma especfica e qual foi o resultado do evento, a fim de conhecer as formas de prev-lo no futuro.

3.3.3 Avaliao por inspeo

A avaliao por inspeo proveniente da experincia, baseada em mtodos heursticos, promovida por Jacob Nielsen. Dentre os tipos mais utilizados de avaliao por inspeo, encontram-se a avaliao heurstica, o uso de checklists para avaliao ergonmica e o percurso cognitivo [17]. Para tal avaliao utilizam-se entrevistas e questionrios com o propsito de evocar as opinies subjetivas, e a compreenso dos usurios a respeito do sistema.

3.3.4 Abordagem etnogrfica (mtodos de anlise observacional)

Anlise etnogrfica observacional uma tcnica que utiliza uma perspectiva naturalista obtendo o material a partir das experincias em primeira mo de um usurio no seu lugar de trabalho, em vez de uma definio artificial ou experimentao. Ela visa compreender ambientes de trabalho e atividades que ocorrem naturalmente, do ponto de vista das pessoas que realmente conhecem as regras de negcio do sistema. O princpio da etnografia reside na sua capacidade de tornar visveis os aspectos fsicos e sociais do mundo real [18].

Pgina 27 de 64

Esta abordagem til para todos os tipos de contextos e tecnologias, pois permite analisar como a tecnologia est integrada no ambiente real de uso, uma vez que existem problemas e prticas que so difceis de prever ou antecipar na anlise da interao com uma ferramenta em um ambiente artificial de teste. justo dizer que esta a parte mais visvel de todos os mtodos listados acima, mas ele retorna uma riqueza de informaes que nenhum outro mtodo capaz.

3.3.5 Sorteio de Cartas

O objetivo desta tcnica descobrir os modelos mentais dos usurios sobre as informaes do sistema em questo. A tcnica se baseia nos seguintes passos: 1. criada uma carta contendo conceitos do sistema. Os conceitos so identificados atravs da anlise da tarefa e entrevistas com os usurios para saber o que os usurios desejam. 2. As cartas so distribudas entre os usurios de forma aleatria 3. Os usurios classificam os cartes de acordo com a similaridade. Eles no recebem instrues detalhadas, mas aconselha-se observar quais cartes so semelhantes. 4. Unem-se os grupos em grupos maiores 5. Analisar como usurios divergem na identificao de entidades e nomes propostos para identific-las.

3.3.6 Grupo Focal

Um grupo focal rene diversos stakeholders em um grupo de discusso heterogneo. Ajuda a identificar questes que precisaro ser combatidas por divergncias e proporciona uma perspectiva multi-facetada como soluo para os problemas. [19] Os grupos de foco so baseados em anlise tcnica, mas tm sido usados para aproximar usurios efetivamente atravs da participao em uma fase precoce do projeto. As reunies podem ser gravadas para posterior anlise.

3.3.7 Prottipo em papel

Este mtodo apresenta a utilizao de materiais e equipamentos simples para criar um documento baseado em uma simulao do sistema ou interface com o objetivo de explorar as necessidades dos usurios. Quando o prottipo for utilizado,

Pgina 28 de 64

um membro da equipe do projeto senta-se em frente ao usurio e 'desempenha o computador', movendo em torno de interface elementos em resposta a aes do usurio. O usurio faz selees e ativa elementos da interface, usando seus dedos como um mouse e informar as entradas inseridas. Outra pessoa facilita a tarefa, fornecendo instrues e incentivando o usurio a expressar os seus pensamentos e impresses. O mtodo tem ampla aplicabilidade. No entanto, mais adequado em contextos onde fcil simular comportamento do sistema.

3.4 Viso Geral do Processo

Enquanto os princpios bsicos e tcnicas utilizadas no design centrado no usurio so sempre os mesmos, o processo de UCD exibe uma srie de caractersticas adaptveis. Um tpico processo baseado em UCD segue os seguintes passos [20]: 1. Anlise a. Viso, objetivos, desafios, percepes e constataes; b. Stakeholders analisados i. Lista de categorias de usurios ii. Matriz de categorias de usurios considerando conhecimento, experincia e habilidades iii. Perfis (detalhes, fatos, imagens) iv. Pessoas/Caracterizao nome) v. Tcnica: Estudos de campo, questionrio de contextualizao c. Anlise de tarefas e objetivos i. Lista de tarefas ii. Matriz de tarefas d. Anlise de arquitetura i. Lista de contedos ii. Matriz de contedos dos usurios iii. Hierarquia e relacionamentos (composta por stakeholder e

Pgina 29 de 64

e. Anlise de fluxo i. Fluxos ii. Cenrios 2. Design a. Modelo conceitual/mental, metforas e conceitos de projeto b. Design de navegao c. Quadro de histrias d. Prottipos de baixa fidelidade e. Prottipos de alta fidelidade 3. Avaliao (interativamente com o design) a. Explorao do design b. Avaliao heurstica c. Reviso de guidelines d. Testes dos prottipos 4. Implementao 5. Implantao Uma outra possibilidade de processo o exposto na Ilustrao 5 abaixo:

Ilustrao 5: Processo de Design Centrado no Usurio

Porm, independente do processo utilizado, o foco na qualidade em uso do produto e como ele se adaptar posteriormente ao ambiente no qual estar inserido sempre orientar as atividades.

Pgina 30 de 64

3.5 Como utilizado na prtica?

O Design Centrado no Usurio j uma realidade presente em vrias empresas nacionais e internacionais. O processo utilizado principalmente ao projetar softwares que sero utilizados por milhares de pessoas de perfis bastante diferentes. Por exemplo, a Microsoft, maior empresa fornecedora de software do mundo, publica em seu guia de recomendaes os princpios que adota para o desenvolvimento de seus produtos [21]. J a IBM mantm um site na Internet [22] especializado em questes relativas ao projeto centrado no usurio e usabilidade, ou, como a prpria empresa chama, facilidade de uso (Ease of Use).

Pgina 31 de 64

4 O Processo de Definio de Critrios de Homologao

Este captulo ir descrever o processo de definio de critrios de homologao. Na Seo 4.1 descrita a motivao para definio do processo. A Seo 4.2 descreve a viso geral, a Seo 4.3 detalha a estrutura e a 4.4 descreve o processo. As Sees 4.5, 4.6 e 4.7 apresentam os suprocessos definidos e finalmente na seo 4.8 as consideraes finais so apresentadas.

4.1 Motivao
Grande parte dos usurios comuns vivencia experincias ruins na utilizao de softwares. Geralmente, esses usurios desistem de utiliz-los, criam certa resistncia sua adoo ou perdem muito tempo se adaptando s exigncias e problemas dos sistemas. Diversas corporaes j identificaram essa e dificuldade e sofrem com o prejuzo associado a uma m aquisio de software. Desta forma, pretendemos criar um processo de definio de critrios de homologao de produtos de software baseado em tcnicas de design centrado no usurio. Este processo objetiva identificar as necessidades implcitas e explcitas do produto atravs do UCD e, ao invs de projetar o sistema (objetivo geral das tcnicas de UCD), estas informaes sero utilizadas para definir critrios de homologao quantitativos. A adoo do design centrado no usurio poder amenizar o maior problema da aquisio de servios de desenvolvimento de software: a fraca especificao dos objetivos do sistema.

4.2 Viso Geral

O processo de definio de critrios de homologao proposto neste trabalho pode ser inserido na etapa que precede o processo de desenvolvimento com os mais variados ciclos de vida e tecnologias. O mesmo est descrito de forma independente dos processos de desenvolvimento e gerenciamento existentes e atende aos requisitos da ISO 14598. Tambm so fornecidos templates auto-explicativos, que devem ser

Pgina 32 de 64

utilizados pela equipe de coleta de informaes para apoiar e conduzir a realizao das atividades descritas no processo. Com o desenvolvimento da proposta, procuramos criar um processo que fosse genrico o suficiente para atender a diversos perfis de organizaes existentes, mas que tambm contemplasse as tcnicas indicadas pelo design centrado no usurio e atividades requeridas pela ISO para um processo bem-estruturado. Desta forma, podemos dizer que a principal contribuio deste processo fornecer um conjunto coerente de atividades e artefatos direcionados para a definio quantitativa da qualidade dos produtos de software, podendo ser aplicado em diferentes tipos de organizaes. Como procuramos propor um processo completo para ser adaptado, importante que, ao utiliz-lo, os consultores planejem a adaptao necessria para o processo atender a realidade da organizao-cliente, removendo atividades que no sejam necessrias e realizando outros ajustes que no influenciem na imparcialidade do processo. Caso contrrio, o resultado do processo pode apresentar critrios de homologao bem diferentes da necessidade da organizao.

4.3 A Estrutura do Processo

Para facilitar a visualizao do fluxo macro do processo e de seus subprocessos, alguns diagramas foram definidos. Para a construo dos diagramas foi utilizada a notao grfica do SPEM [23]. Essa notao no ser apresenta neste trabalho visto que j est bem difundida na literatura. A Ilustrao 6 apresenta o uma viso macro do Processo de Definio de Critrios de Homologao, refletindo os artefatos envolvidos.

Pgina 33 de 64

Ilustrao 6: Processo de Definio de Mtricas e Critrios de Homologao

4.4 Descrio do Processo

Abaixo se apresenta em detalhes o processo de Definio de critrios de homologao. Para facilitar o seu entendimento e descrio, o mesmo est subdivido em trs subprocessos que resumem as atividades a serem realizadas no contexto da avaliao. Os subprocessos tambm esto descritos abaixo.

4.4.1 Objetivos
Planejar e executar atividades de anlise de perfil dos usurios Estabelecer caractersticas de qualidade a serem avaliadas, alinhadas aos objetivos do projeto e da organizao baseado em tcnicas de design centrado no usurio; Prover mtricas e escalas de aceitao que possibilitem a tomada de decises baseadas em dados quantitativos e de acordo com as necessidades da organizao; Pgina 34 de 64

4.4.2 Papis envolvidos

Especialistas em Qualidade de Software Especialistas em Design centrado no usurio Especialistas em Tecnologia Consultores assistentes Equipe de fornecimento de informaes

4.4.3 Subprocessos
Imerso no contexto da aplicao, da organizao e dos usurios Identificao da bancada de testes Definio dos critrios de homologao

4.4.4 Entradas
Especificao do sistema a ser desenvolvido Lista de mdulos a serem definidos critrios de homologao Templates do processo

4.4.5 Sadas
Mtricas e critrios de homologao Bancada de testes

Os subprocessos sero detalhados nas sees 4.6, 4.7 e 4.8, de forma que para cada um deles sero descritas as principais atividades e as suas respectivas entradas e sadas. A Ilustrao 7 representa os subprocessos citados.

Pgina 35 de 64

Ilustrao 7: Fluxo de Subprocessos

4.5 Definir Papis e Responsabilidades

Os papis envolvidos na prestao de um servio de definio de critrios de homologao vo desde profissionais com elevada experincia em TI at profissionais aptos para avaliar comportamento e intenes dos futuros usurios. Outros papis foram criados para suportar as atividades especficas do processo. Na Tabela 1 esto descritas as responsabilidades dos papis definidos para o processo proposto neste trabalho. Os responsveis e responsabilidades correspondentes so os seguintes:
Responsvel Responsabilidades

Especialistas em Design centrado no usurio Orientar a aplicao das tcnicas de UCD no processo de captura de informaes Especialistas em Qualidade de Software Analisar como aplicar informaes obtidas em mtricas de qualidade de software Especialista em Tecnologia Avaliar como as restries e complexidades do software podem ser dirimidas

Pgina 36 de 64

Consultores assistentes Fornecedores de informaes

Auxiliar especialistas em suas atividades Fornecer documentao e informaes

requisitadas pela equipe de coleta Tabela 1: Papis e Responsabilidades

Nas prximas sees sero descritos os subprocessos do processo de definio de critrios de homologao.

4.6 Subprocesso: Imerso no contexto da aplicao, da organizao e dos usurios

Este subprocesso extremamente crtico, pois se for mal executado ir refletir nos demais processos. Desta forma, necessrio realizar suas atividades de forma controlada e objetiva. Neste momento sero executadas outras atividades de suporte ao processo de operao que no sero citadas, pois no so essenciais para o entendimento do processo. A composio do subprocesso est exposta na Ilustrao 8 abaixo.

Ilustrao 8: Subprocesso de Imerso no contexto da aplicao, da organizao e dos usurios

Pgina 37 de 64

4.6.1 Estudo da Organizao e identificao de prioridades

Processo: Imerso no contexto da aplicao, Atividade: Estudo da da organizao e dos usurios identificao de prioridades Objetivos: Conhecer mdulos que sero contemplados Conhecer a organizao adquirente e sua estrutura organizacional Identificar em que camada hierrquica da organizao o software ser utilizado Entradas: Lista de Mdulos de Avaliao selecionados Organizao Passos: Analisar mdulos LAPS selecionados Anlise da organizao cliente Sadas: Organograma da empresa (setor onde o software estar inserido) Organizao e

Responsvel: Equipe do projeto Tabela 2: Estudo da Organizao e identificao de prioridades Analisar mdulos LAPS selecionados Dentre os mdulos LAPS disponveis para avaliao, cada projeto utilizar um subconjunto especfico e de acordo com as necessidades da organizao. Estes mdulos devero ser selecionados pelo cliente, se necessrio acompanhado por um consultor. Anlise da Organizao Cliente Aps identificar os mdulos selecionados, ser necessrio identificar o contexto em que ele ser utilizado. Esta anlise de posicionamento do software ser muito importante para definio de escalas de aceitao, pois dependendo do perfil dos futuros usurios e da forma como o software estar distribudo, estas podero variar bastante.

4.6.2 Anlise da Especificao Geral do Software

Processo: Imerso no contexto da aplicao, da Atividade: Anlise da Especificao organizao e dos usurios Geral do Software Objetivos: Entender os objetivos do software a ser desenvolvido Conhecer regras de negcio no qual o software estar inserido Sadas:

Entradas:

Pgina 38 de 64

Especificao Geral do Software

Passos: Analisar escopo do software Entender conceitos tcnicos presentes na especificao do software

Responsvel: Equipe do projeto Tabela 3: Anlise da Especificao Geral do Software Analisar escopo do software Para definio dos critrios de homologao necessrio receber uma especificao do software, em geral essa especificao no o documento de requisitos, pois este s ser desenvolvido na fase de produo do software. Desta forma, necessrio analisar com cuidado o documento de especificao entregue e apreender ao mximo o objetivo da organizao com a implantao do sistema. Entender conceitos tcnicos presentes na especificao do software Visto que a avaliao de software est inserida em diversos mercados verticais de TI, geralmente o produto a ser avaliado representa uma realidade bastante diferente da realidade do avaliador. Desta forma, faz-se necessrio que os responsveis pela coleta de dados conheam ao menos os conceitos tcnicos presentes na especificao. Essa imerso no contexto da aplicao pode ser feita em conjunto com uma equipe tcnica disponibilizada pela organizao.

4.6.3 Aplicao de Questionrio de Perfil

Processo: Imerso no contexto da aplicao, Atividade: Aplicao do Questionrio de Perfil da organizao e dos usurios Objetivos: Definir quem so as pessoas responsveis por fornecer informaes Conhecer a proximidade de cada futuro usurio com TI e com o sistema que ser desenvolvido Sadas: Lista de responsveis por fornecer informaes equipe de coleta de dados Questionrio de Perfil respondido Passos: Identificar perguntas do Questionrio de Perfil que so relevantes para os mdulos selecionados Identificao de todos envolvidos na coleta de informaes

Entradas: Template do Questionrio de Perfil

Pgina 39 de 64

Envio e recebimento dos questionrios

Responsvel: Organizao cliente e gerente do projeto Tabela 4: Aplicao de Questionrio de Perfil Identificar perguntas do Questionrio de Perfil que so relevantes para os mdulos selecionados O LAPS conta com um template de Questionrio de Perfil onde diversas questes relevantes a todos mdulos LAPS so levantadas, visto que nem toda avaliao utiliza todos mdulos, deve-se fazer uma seleo das perguntas a serem utilizadas no questionrio de perfil de cada projeto de acordo com a relevncia de cada pergunta para os mdulos selecionados e para o escopo do projeto em questo. Identificao de todos envolvidos na coleta de informaes Visto que o processo de definio de critrios de homologao do LAPS baseado em UCD, necessrio contar com o comprometimento da organizao para ceder alguns futuros usurios do sistema para ser realizada a coleta de informaes. Essa seleo de futuros usurios deve ser realizada contemplando todos os nveis de interao posterior com o sistema, para que o sistema esteja adequado s necessidades de toda organizao. Envio e recebimento dos questionrios Aps identificar perguntas-chave do questionrio de perfil, deve-se enviar os questionrios para os futuros usurios selecionados. No envio, deve-se estabelecer o prazo de recebimento e o cumprimento do prazo deve ser monitorado pelo gerente do projeto.

4.6.4 Definio de Perfis

Processo: Imerso no contexto da aplicao, da organizao e dos Atividade: usurios Objetivos: Identificar posicionamento e relevncia de cada futuro usurio envolvido no processo de coleta de informaes Entradas: Questionrio de Perfis respondido Template da Lista de Perfis Sadas: Lista de perfis Perfis Definio de

Passos: Avaliao das respostas dos Questionrios de perfis Identificao e definio de perfis de usurios

Responsvel: Especialista em Design Centrado no Usurio Tabela 5: Definio de Perfis

Pgina 40 de 64

Avaliao das respostas dos Questionrios de perfis O consultor dever analisar as respostas dos usurios do sistema e verificar se todas as perguntas foram respondidas conforme o indicado. Caso seja necessrio, o consultor poder requisitar que outros futuros usurios tambm respondam o questionrio e participem da coleta de informaes. Identificao e definio dos perfis de usurios No documento lista de perfis, esto listadas algumas informaes relevantes que podem ser inferidas atravs das respostas do questionrio de perfil. Atravs destes dados, o avaliador dever identificar o perfil de cada usurio e os separar para orientar a busca de informaes nos usurios mais especializados em cada parte do futuro sistema.

4.7 Subprocesso: Definio da Bancada de Testes

A bancada de testes no conceito de homologao de produtos de software definida como a infra-estrutura utilizada para reproduzir o contexto no qual a aplicao estar inserida e as ferramentas que sero utilizadas para homologar o produto. Neste documento iremos abstrair as ferramentas que sero utilizadas, pois estas sero relevantes apenas na etapa posterior de avaliao do produto desenvolvido (ou em desenvolvimento). A composio do subprocesso est exposta na Ilustrao 9 a seguir.

Ilustrao 9: Subprocesso: Definio da Bancada de Testes

Pgina 41 de 64

4.7.1 Aplicao do Questionrio de Infra-estrutura

Processo: Definio da Bancada de Testes Atividade: Aplicao do Questionrio de Infra-estrutura Objetivos: Definir configuraes de hardware, software e comunicao onde cada usurio utilizar o sistema Sadas:

Entradas: Template do Questionrio de identificao de infra-estrutura

Passos: Identificar perguntas do Questionrio de infra-estrutura que so relevantes para os mdulos selecionados e para o escopo do projeto Recebimento dos questionrios respondidos

Responsvel: Especialista em Tecnologia, Organizao Cliente e Gerente do projeto Tabela 6: Aplicao do Questionrio de Infra-estrutura Identificar perguntas do Questionrio de infra-estrutura que so relevantes para os mdulos selecionados O LAPS conta com um template de Questionrio de infra-estrutura onde diversas questes relevantes a todos mdulos LAPS so levantadas, visto que nem toda avaliao utiliza todos mdulos, deve-se fazer uma seleo das perguntas a serem utilizadas no questionrio de infra-estrutura de cada projeto de acordo com a relevncia de cada pergunta para os mdulos selecionados e para o escopo do projeto em questo. Este questionrio pode ser enviado em conjunto com o questionrio de perfil. Envio e recebimento dos questionrios Aps identificar perguntas-chave do questionrio de infra-estrutura, deve-se enviar os questionrios para os futuros usurios selecionados. No envio, deve-se estabelecer o prazo de recebimento e o cumprimento do prazo deve ser monitorado pelo gerente do projeto.

4.7.2 Entrevista de identificao do ambiente de produo

Processo: Definio da Bancada de Testes Atividade: Entrevista de identificao do

ambiente de produo Objetivos: Identificar possveis entropias / restries que o produto ter onde ser implantado. Sadas:

Entradas:

Pgina 42 de 64

Relao da equipe responsvel pela infra-estrutura

Dados sobre ambiente de produo

Passos: Analisar infra-estrutura onde o software ser implantado Levantamento da topologia da rede

Responsvel: Especialista em Tecnologia e Organizao Cliente Tabela 7: Entrevista de identificao do ambiente de produo Analisar infra-estrutura onde o software ser implantado Caso o sistema seja implantado nas dependncias da organizao, ser necessrio requisitar o acompanhamento da equipe de administrao de TI da organizao. Deve-se fazer o levantamento da configurao do servidor e verificar a existncia de outros processos paralelos e recursos efetivamente disponveis para o sistema. Levantamento da topologia da rede Para sistemas que utilizem rede, necessrio definir a entropia causada por esta na avaliao de desempenho, por exemplo. Desta forma, deve-se levantar os ns da rede e o nvel de sobrecarga destes, alm de definir o nvel de impedncia a ser enfrentado no trfego de dados do sistema.

4.7.3 Preenchimento de Formulrio de Bancada de Testes

Processo: Definio da Bancada de Testes Atividade: Preenchimento de Formulrio de Bancada de Testes Objetivos: Estabelecer, a priori, onde o sistema ser implantado e em quais condies a sua aderncia ser homologada Sadas: Bancada de Testes

Entradas: Template do Formulrio de Bancada de Testes Dados sobre infra-estrutura e ambiente de produo

Passos: Compilao de questionrios de infra-estrutura e dados do ambiente de produo Preenchimento do formulrio

Responsvel: Especialista em Tecnologia e Consultor Assistente Tabela 8: Preenchimento de Formulrio de Bancada de Testes Compilao de questionrios de infra-estrutura e dados do ambiente de produo

Pgina 43 de 64

A infra-estrutura disponvel para a maioria dos usurios deve ser semelhante, por isso necessrio identificar essas semelhanas, compilar os questionrios com intuito de criar o macro-grupo de diversidades de infra-estruturas para as quais o sistema precisar estar preparado. Alm de compilar os dados dos usurios, tambm ser necessrio compilar os dados do ambiente de produo para que estes sejam compreendidos pelo futuro fornecedor do sistema. Preenchimento do formulrio O preenchimento do formulrio deve iniciar com uma seleo de itens que so essenciais para compreenso da bancada de teste. Posteriormente, deve-se preencher os itens considerados essenciais com os dados compilados.

4.8 Subprocesso: homologao

Definio

de

mtricas

critrios

de

Este subprocesso o mais longo e mais complexo, pois envolver todo conhecimento gerado nos subprocessos anteriores e exigir uma capacitao diferente das caractersticas dos profissionais de TI, portanto a equipe deve ser multidisciplinar. Os passos deste subprocesso podem ser vistos na Ilustrao 10:

Ilustrao 10: Suprocesso de Definio de Mtricas e Escalas de Aceitao

Pgina 44 de 64

4.8.1 Estudo Etnogrfico

Processo: Definio de objetivos e critrios de homologao Objetivos: Conhecer a realidade onde o sistema estar inserido e identificar, na convivncia, os problemas dos usurios Sadas: Resultado da entrevista e da anlise da tarefa Atividade: Estudo Etnogrfico

Entradas: Lista de perfis

Passos: Separao dos perfis de usurios em grupos Realizar anlise da tarefa com cada grupo de usurios Realizao da Entrevista Semi-estruturada baseada em portflio LAPS e anlise da tarefa

Responsvel: Especialista em Design Centrado no Usurio e Assistente de Avaliao Tabela 9: Estudo Etnogrfico Separao dos perfis de usurios em grupos Cada grupo de usurios ter um papel especfico na utilizao do sistema e especialista em cada parte do software que ser desenvolvido. Conforme preconiza o UCD, deve-se analisar a perspectiva de todos os usurios (mesmo que este use menos assiduamente o sistema). A separao dos perfis em grupos permitir que a anlise da tarefa seja realizada de forma mais efetiva, pois cada usurio ir demonstrar a parte do sistema na qual ele tem mais proximidade. Realizar anlise da tarefa com cada grupo de usurios Aps a separao dos grupos e das atividades para cada um, deve-se pedir para que estes realizem suas tarefas cotidianas, onde ser analisada a interao destes com o sistema atual e identificaremos como o sistema a ser desenvolvido dever se comportar e o que dever ser priorizado. Realizao da Entrevista Semi-estruturada baseada em portflio LAPS e anlise da tarefa Durante a anlise da tarefa, devem surgir dvidas sobre regras de negcio e necessidades da organizao. Alm da tecnologia LAPS que possui uma srie de perguntas essenciais para definio de mtricas para cada mdulo. Desta forma, deve-se criar uma entrevista semi-estrutura para eliminar dvidas com cada grupo e utilizar a tcnica de UCD conhecida como Anlise de situaes crticas para construo da entrevista, onde se levantam as dificuldades/facilidades percebidas na realizao da tarefa e questiona-se o usurio sobre tais acontecimentos.

Pgina 45 de 64

4.8.2 Questionrio de expectativas

Processo: Definio de objetivos e critrios de Atividade: Questionrio de expectativas homologao Objetivos: Ter conhecimento macro das expectativas de cada usurio em relao ao sistema Sadas: Questionrios respondidos de expectativas

Entradas: Template do questionrio de expectativas Template do Roteiro do Focus Group

Roteiro do focus group

Passos: Identificar questes a serem selecionadas do template do questionrio de expectativas Envio e recebimento dos questionrios Definio de questes a serem levantadas nos focus groups

Responsvel: Especialista em Design Centrado no Usurio, Gerente do projeto, Consultor Assistente e Organizao Cliente Tabela 10: Questionrio de expectativas Identificar questes a serem selecionadas do template do questionrio de expectativas O LAPS conta com uma srie de questes referentes s expectativas dos usurios e o grau de satisfao de acordo com cada indicador. Desta forma, as questes aplicveis devero ser selecionadas para obter o mximo de informaes relevantes para definio de critrios de homologao do sistema. Envio e recebimento dos questionrios Os questionrios sero enviados aos responsveis por fornecer informaes na coleta de dados e o prazo de recebimento deve ser monitorado pelo gerente do projeto. Ao receber os questionrios, deve-se avaliar as expectativas conflitantes que sero tratadas no focus group. Definio de questes a serem levantadas no focus group Dependendo do nvel de questes a serem tratadas no focus group, podem ser organizadas mais de uma reunio dividindo os grupos por reas de interesse. Considerando a necessidade de apenas um, deve-se ter cuidado na seleo de questes para que todos entrem em acordo da melhor forma possvel e todos compreendam os impasses e o debate.

4.8.3 Focus Group

Processo: Definio de objetivos e critrios de Atividade: Focus Group

Pgina 46 de 64

homologao Objetivos: Realizao de debate em grupo para que a especificao da qualidade do sistema esteja aderente a todos os futuros usurios. Sadas: Caractersticas prioritrias de avaliao

Entradas: Roteiro do focus group

Passos: Alinhar expectativas de todos os usurios Identificar as caractersticas de avaliao prioritrias

Responsvel: Especialista em Design Centrado no Usurio, Especialista em Qualidade e Consultores Assistentes Tabela 11: Focus Group Alinha expectativas de todos os usurios O focus group j possui um roteiro definido, mas nada impede que outras questes conflitantes tambm sejam debatidas, o importante que todos possuam a mesma viso do produto. Ao iniciar a sesso ser necessrio mediar vontades de diferentes nveis de usurios e auxili-los a entrar em um consenso. Identificar as caractersticas de avaliao prioritrias Tendo as expectativas definidas, necessrio conciliar as caractersticas prioritrias. Visto que os mdulos j foram selecionados pela organizao, provvel que esta atividade seja amena, caso contrrio deve-se orientar o debate para os objetivos iniciais e garantir que estes sejam mantidos.

4.8.4 Compilao de Dados e Definio de Mtricas

Processo: Definio de objetivos e critrios de Atividade: Compilao de Dados e Definio homologao Objetivos: Definio de mtricas capazes de avaliar pontos considerados crticos pela organizao e pelos usurios Sadas: Documento de Critrios de homologao (com mtricas) de Mtricas

Entradas: Toda documentao gerada durante o processo Template do Documento de Critrios de Homologao Portflio de Mtricas LAPS

Pgina 47 de 64

Passos: Definir objetivos da medio (Nvel conceitual) Anlise do portflio de mtricas LAPS Identificao de outras mtricas essenciais

Responsvel: Especialista em Qualidade e Consultores Assistentes Tabela 12: Compilao de Dados e Definio de Mtricas

Definir objetivos da medio (Nvel conceitual) Definir o objeto da medio (artefatos, software, sutes de teste, testabilidade, manutenibilidade, uso de hardware, uso de banda, entre outros). Criar questes tentando caracterizar o objeto de medida com respeito aos problemas de qualidade e determinar a qualidade atravs do ponto de vista selecionado. Anlise do portflio de mtricas LAPS A tecnologia LAPS conta com um extenso portflio de mtricas associadas aos mdulos de avaliao. Atravs das questes definidas no passo anterior, deve-se verificar se as mtricas do portflio LAPS so capazes de responder todas as questes. Ao identificar mtricas que respondem s questes, deve-se inclu-las no documento de critrios de homologao para posteriormente definirmos suas escalas de aceitao. Identificao de outras mtricas essenciais Visto que cada organizao possui peculiaridades, provvel que algumas questes no sejam respondidas apenas com o portflio de mtricas LAPS. Neste caso, deve-se definir quais dados sero coletados, considerando a sua quantidade, qualidade e maturidade. A partir dessas informaes devese definir mtricas objetivas que possam responder s questes pendentes.

4.8.5 Definio de Escalas de Aceitao

Processo: homologao Objetivos: Definir os critrios de homologao de acordo com as necessidades da organizao e as expectativas dos usurios. Sadas: Documento de critrios de Definio de objetivos e critrios de Atividade: Definio de Escalas de Aceitao

Entradas:

Pgina 48 de 64

Bancada de teste Documento de critrios de homologao (com mtricas) Anlise do focus group, dos questionrios e das entrevistas

homologao

Passos: Definir propsito e ponto de vista considerando o ambiente Identificao de escalas de referncia Definio de escalas de aceitao

Responsvel: Especialista em Qualidade, em Tecnologia, em Design Centrado no Usurio, Gerente do projeto e consultores assistentes Tabela 13: Definio de Escalas de Aceitao

Definir propsito e ponto de vista considerando o ambiente Para avaliar posteriormente a conformidade do software em relao s necessidades do cliente, necessrio determinar faixa de aceitao de cada mtrica. Esta individualizao de escalas de aceitao facilitar a visualizao dos resultados e dever considerar o ponto de vista e o ambiente, alm do propsito da avaliao. Identificao de escalas de referncia As mtricas do portflio LAPS contam com uma escala de aceitao de referncia baseada na literatura e as mtricas que so definidas em virtude das caractersticas especficas da organizao j devem contar com suas escalas de aceitao de referncia. Portanto, deve-se proceder a anlise destas escalas para nortear a posterior definio de escalas de um software especfico. Definio de escalas de aceitao De acordo com as decises tomadas em reunio, expectativas dos usurios, necessidades da organizao e escalas de referncia, definem-se as escalas de aceitao do software. Posteriormente, necessrio preencher o documento de critrios de homologao indicando quais mtricas so utilizadas para homologao e como so medidas, alm de fornecer uma explicao sucinta de cada uma.

4.9 Consideraes Finais

Neste captulo, foi apresentada a proposta de um processo para suportar as atividades de definio de critrios de homologao de produtos em fase de especificao. O processo proposto por esse trabalho est alinhado s tcnicas de design centrado no usurio. O processo tambm foi fundamentado em uma reviso

Pgina 49 de 64

bibliogrfica da Avaliao de Produtos de Software e Modelos de Qualidade, e na experincia prtica da autora. Templates, artefatos, e passos tambm foram descritos no processo. No prximo captulo ser avaliada a sua utilizao e como cada subprocesso foi executado.

Pgina 50 de 64

5 Estudo de Caso
Este captulo ir descrever a aplicao do processo em um projeto real. Na Seo 5.1 descrito objetivo do Estudo de Caso. A Seo 5.2 descreve o escopo de Realizao do Estudo de Caso. A Seo 5.3 apresenta a Metodologia de Trabalho e a Seo 5.4 informa o Cronograma de Trabalho. J na Seo 5.5 o Estudo de Caso relatado e finalmente na Seo 5.6 as consideraes finais so apresentadas.

5.1 Objetivos do Estudo de Caso

O processo de definio de mtricas e escalas de aceitao proposto por este trabalho foi aplicado em um projeto real de Auxlio a Termo de Referncia para especificao do software, com o objetivo de definir a priori como o software ser homologado. O processo foi definido na reviso da literatura de design centrado no usurio. Contudo, os resultados iniciais do estudo de caso, a ser descrito neste captulo, tambm proveram insumos para a definio do processo final deste trabalho. A aplicao prtica do processo de definio de mtricas e escalas de aceitao proposto neste trabalho tem como principais objetivos os seguintes aspectos: 1. Disponibilizar critrios quantitativos capazes de atestar a qualidade do software; 2. Permitir que o software a ser adquirido atenda s necessidades funcionais e no-funcionais do adquirente; 3. Realizar posterior avaliao probatria para aceitao.

5.2 O Escopo de Realizao do Estudo de Caso

A organizao utilizada na aplicao do estudo de caso foi uma empresa pblica de abrangncia nacional cuja sede est estabelecida no estado de Pernambuco. Essa empresa no possui foco em desenvolvimento de software, mas potencial adquirente de produtos atravs de licitaes. A empresa possui um setor jurdico que coordena aspectos legais de uma licitao e o responsvel pela verba a ser utilizada no desenvolvimento do software responsvel por especificar caractersticas e funcionalidades do produto. O projeto a ser licitado pela organizao, objeto do estudo de caso, o seguinte: Pgina 51 de 64

Um sistema de cadastro e gerao de relatrios, o qual chamaremos de Produto 1;

A atividade a ser realizado pelo Produto 1 considerada uma atividade crtica para o funcionamento da empresa e atualmente realizada atravs de planilhas Excel e sistemas legados. As planilhas so pouco intuitivas, de difcil atualizao e elevam consideravelmente o tempo de gerao de relatrios e sua conseqente anlise. J os sistemas legados contemplam apenas uma parte dos dados que precisam ser gerenciados, portanto no proporcionam relatrios completos e capazes de suprir a necessidade de informao do cliente. Novos mdulos devero ser especificados posteriormente para o produto1, porm estes no sero contemplados no estudo de caso, pois contar com outra licitao e outro processo de especificao. O projeto acima foi selecionado com base nos seguintes critrios: 1. Projeto gerenciado pelo setor da empresa situado em Recife; 2. Prazo suficiente para a execuo do processo de definio de mtricas e escalas de aceitao. Porm, no haver tempo hbil para validao das mtricas atravs de uma posterior avaliao. A empresa do escopo do estudo de caso possui em mdia 5500 funcionrios, porm o projeto acima envolveu um total de 7 pessoas da equipe que utilizar posteriormente o produto. Das sete pessoas, 5 utilizaro o software assiduamente e 2 so especialistas no domnio da aplicao. O projeto est em fase de concluso do edital, onde este dever ser disponibilizado em breve. Com base nos resultados do estudo de caso a organizao documentou os critrios de homologao e poder exigir a posteriori que o produto esteja conforme a especificao. Com relao ao tempo de realizao do estudo de caso, o incio foi em 11 de setembro de 2008 e foi concludo em 17 de outubro de 2008, resultando em um total de 1 ms e uma semana. Porm, o primeiro contato para realizao do servio foi em maro de 2008 atravs de reunio com o cliente. Permitindo que o planejamento do estudo de caso e a preparao do processo fosse realizado a priori. No contexto do estudo de caso, a necessidade de contratao de recursos externos para definio de mtricas e critrios de aceitao do software surgiu aps

Pgina 52 de 64

experincias mal-sucedidas de aquisio de outros softwares pela organizao, os quais no eram capazes de realizar atividades bsicas. Durante a realizao do estudo de caso, surgiu a necessidade de informaes que no haviam sido contempladas inicialmente, implicando na atualizao e evoluo do processo. Outro fator motivador para a definio dos critrios de homologao foi o fato de que a empresa vencedora da licitao precisar desenvolver o produto1 com foco na garantia da qualidade deste, pois a avaliao ser realizada em etapas intermedirias do desenvolvimento e na entrega do produto final.

5.3 Metodologia de Trabalho

A autora desse trabalho atuou na definio das mtricas e dos critrios de aceitao, dando suporte empresa na especificao do Termo de Referncia, de setembro a outubro de 2008. O servio foi executado com base nas prticas descritas no processo proposto por esse trabalho. Como o processo ainda no estava descrito em sua verso final, o estudo de caso funcionou tambm como um relato de experincia, visto que alguns de seus resultados foram utilizados para a composio e otimizao do processo descrito. A equipe responsvel pela realizao do projeto contou com a participao de 3 PhDs, 1 Engenheiro Eltrico e 2 Consultores Assistentes. Esse grupo possua como principais responsabilidades: 1. Auxiliar a empresa na especificao geral do software a ser desenvolvido; 2. Definir em conjunto com a empresa o cronograma de desenvolvimento e marcos de avaliao intermediria do produto1; 3. Fornecer parecer tcnico sobre o termo de referncia fornecido; 4. Definir mtricas e escalas de aceitao para posterior avaliao do software. A autora deste trabalho atuou como responsvel pela ltima atividade citada acima desempenhando o papel de Especialista em UCD e consultora assistente em contato direto com a equipe disponibilizada pela empresa para fornecer informaes.

Pgina 53 de 64

5.4 Cronograma de Trabalho

As atividades do estudo de caso foram iniciadas em setembro, quando o contrato de prestao de servio foi assinado. A fase de planejamento foi iniciada neste mesmo ms, com as seguintes prioridades: 1. Analisar Termo de Referncia (TR) a ser fornecido; 2. Sugerir melhorias no TR; 3. Receber feedback e trat-lo; 4. Definir mtricas e escalas de aceitao. A execuo do estudo de caso foi iniciada atravs das seguintes atividades: Reunio de kick-off; Envio do questionrio de perfil e infra-estrutura a fim de identificar caractersticas e relevncia dos stakeholders (foi realizada uma adaptao no template da proposta para se adequar ao contexto do projeto); Levantamento, junto aos tcnicos da empresa, de regras de negcios e restries da aplicao; Posterior entrevista semi-estruturada para eliminar dvidas; Identificao da topologia da rede junto ao setor responsvel da organizao; Anlise da tarefa de cadastro e gerao de relatrios atual; Identificao das funcionalidades e informaes necessrias a serem armazenadas pelo sistema; Levantamento de expectativas dos usurios e conflitos entre estas expectativas; Focus Group para eliminar conflitos; Sugesto de melhorias no TR; Definio de mtricas e escalas de aceitao.

As reunies citadas acima ocorreram nos meses de setembro e outubro de 2008 e os resultados das mesmas sero apresentados na seo a seguir.

Pgina 54 de 64

5.5 Relato do Estudo de Caso

Esta seo descreve como foi realizado o estudo de caso e quais foram os resultados obtidos. Iremos descrever as atividades do processo que foram realizadas, qual o resultado da execuo de cada atividade, os benefcios e as principais dificuldades enfrentadas pela equipe do projeto, porm no poderemos expor os artefatos gerados em virtude do termo de confidencialidade assinado com a organizao onde o estudo de caso foi aplicado. Para algumas situaes iremos descrever como contornamos as dificuldades identificadas ou como o processo proposto pde ser melhorado para suportar de forma otimizada algumas atividades. Antes do incio das atividades do processo de definio de critrios de homologao propriamente dito foi necessrio um nivelamento do conhecimento bsico com o outro consultor assistente que tambm participou da coleta de informaes. O contedo dos captulos 3 e 4 foram transmitidos para este de forma detalhada, e tambm para o especialista em qualidade de software atravs de uma viso macro. Iremos descrever nas subsees seguintes os resultados gerados pela execuo dos trs subprocessos do processo proposto no Captulo 4: Imerso no contexto da aplicao, dos usurios e da organizao, Definio da Bancada de Testes e Definio de mtricas e escalas de aceitao. Na seo de cada subprocesso iremos descrever em detalhes as atividades aplicadas no estudo de caso e os resultados gerados pela execuo das mesmas. Algumas atividades paralelas que no fazem parte do escopo do processo, mas fizeram parte do projeto, foram omitidas neste relato do estudo de caso, pois no implicaram em nenhuma alterao do processo.

5.5.1 Subprocesso: Imerso no contexto da aplicao, dos usurios e da organizao

No subprocesso de imerso no contexto da aplicao, dos usurios e da organizao, todas as atividades previstas foram realizadas. Os mdulos selecionados foram: Confiabilidade Pgina 55 de 64

Manutenibilidade Usabilidade Funcionalidade Desempenho

Na mesma reunio onde a lista de mdulos selecionados foi entregue, foi feita uma explanao geral dos objetivos da organizao atravs da adoo do software e a especificao deste foi entregue. A relao de futuros usurios envolvidos na disponibilizao de informaes foi repassada informalmente e os questionrios de perfis e infra-estrutura foram enviados. Enquanto os questionrios no eram recebidos, os consultores assistentes definiram um prazo para anlise da especificao. Aps o recebimento dos questionrios respondidos foram definidos perfis de usurios de acordo com as respostas e seus nveis de relevncia para o projeto. Finalmente aps identificar perfis de usurios e conhecer os macro-objetivos do software, foi marcada uma reunio com tcnicos especialistas no negcio da aplicao para eliminao de dvidas conceituais na especificao. Desta forma as atividades 4.6.3 e 4.6.4 foram inseridas no meio da atividade 4.6.2 com intuito de conhecer e avaliar as informaes repassadas pelos tcnicos.

5.5.2 Subprocesso: Definio da Bancada de Testes

O questionrio de infra-estrutura foi enviado aos usurios em conjunto com o questionrio de perfil para que estes respondessem com presteza. Aps o conhecimento do escopo do software e as restries inerentes sua implantao, procedeu-se a anlise do ambiente no qual ele ser instalado, em produo. Visto que o software em questo ser um sistema web e utilizar um banco de dados distante do servidor de aplicao, foi necessrio identificar toda topologia da rede e a entropia presente na comunicao entre essas duas entidades. Com o questionrio de infra-estrutura respondido e as informaes do ambiente coletadas, procedeu-se o preenchimento do formulrio de bancada de teste. Tendo em vista que o Sistema Operacional no qual o sistema ser implantado estar instalado

Pgina 56 de 64

em uma VMWare, foi necessrio incluir alguns itens no formulrio da bancada de testes.

5.5.3 Subprocesso: Definio de mtricas e escalas de aceitao

Atravs dos perfis identificados, foram criados dois grupos de interao e cada grupo realizou suas atividades cotidianas assistidos por dois consultores assistentes. Aps a anlise da tarefa, foi realizada uma entrevista semi-estruturada baseada nos pontos crticos, identificados por ambos os consultores, da utilizao do sistema atual de cadastro e gerao de relatrios. Aps a realizao das etapas anteriores, os responsveis por coletar informaes estavam com uma viso relativamente madura dos objetivos do projeto e da avaliao, criando assim os questionrios de expectativas de acordo com esse conhecimento adquirido. Conforme esperado, alguns usurios possuam expectativas diferentes e pensavam em funcionalidades diferentes para o software, estas divergncias foram levadas reunio de focus group e foram resolvidas com certa facilidade, assim como as prioridades da avaliao. Aps a fase de contato intenso com os usurios, foi necessrio traduzir todo conhecimento adquirido em mtricas. Utilizou-se toda documentao gerada pelo processo e aps uma reviso minuciosa desta, as questes de mais alto nvel que precisaro ser identificadas na avaliao foram selecionadas. Tendo estas questes em mos, fez-se uma anlise de compatibilidade com o portflio LAPS, constatando que nem todas as questes puderam ser relacionadas com as mtricas existentes. Desta forma, foram criadas novas mtricas e o portflio foi expandido. Aps a definio das mtricas, as escalas de aceitao foram definidas, algumas delas em parceria com os responsveis pela futura manuteno do sistema e todas tendo em vista as vontades explicitadas durante o processo de captura de informaes. Porm, nem todas as escalas ficaram aderentes s escalas de referncia visto que a aplicao crtica para organizao e exige critrios de homologao mais rgidos.

Pgina 57 de 64

Por questes confidenciais, as mtricas no podero ser disponibilizadas na ntegra. Portanto, ilustraremos abaixo apenas algumas mtricas do mdulo de Usabilidade.

Ilustrao 11: Mtricas de Usabilidade

5.6 Consideraes Finais

Este captulo apresentou o relato de um estudo de caso da aplicao prtica do processo de definio de critrios de homologao proposto por esse trabalho. O estudo de caso foi utilizado tambm como um relato de experincia, visto que proveu insumos para a melhoria de algumas prticas do processo proposto. Visto que o tempo de execuo do estudo foi bastante curto, ainda no foi possvel observar todos os benefcios do processo. A definio objetiva e quantitativa da qualidade para solucionar problemas do processo de aquisio da organizao do estudo de caso foi um dos maiores ganhos. A inadequao do software poder ser identificada atravs das avaliaes posteriores, objetivando melhores resultados no processo de aquisio. Os custos da execuo do processo foram mensurados em termos de esforo, e as atividades foram planejadas para atender aos limites definidos pela organizaocliente. Atravs da execuo do estudo de caso evidenciamos que a necessidade constante de mo-de-obra para a realizao da coleta de informaes pode ser fator

Pgina 58 de 64

complicador na execuo do projeto, mas as atividades no foram prejudicadas pelas restries de custos definidas. Por outro lado, os benefcios alcanados no puderam ser mensurados em uma unidade de valor, visto que ainda ser necessrio avaliar o produto e verificar se este adequado organizao. O estudo de caso foi planejado e apoiado pela gerncia da organizao. Entretanto, mesmo com o apoio da gerncia, problemas aconteceram ao longo de sua execuo, visto que viagens e indisponibilidade de algumas pessoas atrapalharam o andamento do processo de coleta de informaes. Esses problemas foram contornados e compreendidos atravs de uma extenso do prazo de concluso do projeto.

Pgina 59 de 64

6 Concluso e Trabalhos Futuros

Este captulo ir descrever a aplicao do processo no projeto real, abordando os seguintes aspectos. Na Seo 6.1 so descritas as principais contribuies do trabalho. A Seo 6.2 relata as principais dificuldades enfrentadas. A Seo 6.3 apresenta os trabalhos relacionados e a Seo 6.4 planeja os trabalhos futuros. J na seo 6.5 as consideraes finais so apresentadas.

6.1 Principais Contribuies

Este trabalho foi motivado pela grande dificuldade atual de se praticar uma avaliao quantitativa de produtos de software, principalmente de acordo com as necessidades dos usurios. Portanto suas principais contribuies foram: Fornecer uma nova abordagem para o design centrado no usurio, diferente do projeto de solues e avaliao de usabilidade Viso quantitativa para as tcnicas de UCD Considerar necessidades especficas de cada organizao ao avaliar seus softwares Identificao de critrios de homologao em produtos com especificao incipiente.

6.2 Principais Dificuldades Encontradas

O processo foi definido por uma especialista em qualidade de software, com auxlio de profissionais de outras reas. No entanto, ainda enfrentamos as seguintes dificuldades: Transformar impresses e dados coletados com usurios em mtricas e escalas de aceitao Garantir que a mtrica no poder ser burlada ou contestada Efetividade das mtricas Gerenciamento do contato e disponibilidade dos fornecedores de informao O estudo de caso no contou com o perfil proposto de especialista em design centrado no usurio, desta forma foi necessrio utilizar o

Pgina 60 de 64

conhecimento apreendido durante a definio do processo para minimizar esta dificuldade.

6.3 Trabalhos Relacionados

Visto que a autora trabalha na tecnologia LAPS h mais de um ano, alguns trabalhos j foram produzidos anteriormente em temas relacionados ao processo proposto neste documento: Extenso do portflio de mtricas; Melhoria dos processos de avaliao dos mdulos LAPS; Definio de escalas de aceitao referncia; Estudo de ferramentas capazes de automatizar o processo de avaliao de produtos de software; Atualizao da tecnologia LAPS para adequ-la a incluso deste processo. Alm dos trabalhos citados acima, durante o estudo de caso tambm tivemos as seguintes contribuies: Sugesto de melhorias de aspecto tcnico e operacional no termo de referncia; Auxlio na definio do cronograma de desenvolvimento e indicao de milestones onde avaliaes devem ser realizadas.

6.4 Trabalhos Futuros

Os trabalhos futuros abaixo so um conjunto de expectativas no s da autora, mas da equipe que realiza estudos em conjunto e da empresa na qual ela trabalha: Utilizar de forma mais estruturada a abordagem do GQM (Goals, Questions, Metrics) para definio de novas mtricas; Criao de base de conhecimento com portflio de mtricas e documentar a utilizao da mtrica ligada s caractersticas do projeto, a fim de permitir uma posterior seleo automtica de mtricas a partir das caractersticas do projeto; Avaliao do produto utilizado como estudo de caso atravs das mtricas especificadas e validar as escalas de aceitao definidas;

Pgina 61 de 64

Documentar melhor o estudo de caso com intuito de organizar um artigo publicvel em congresso; Inserir pesos nas caractersticas de qualidade para dar uma nota final ao software.

6.5 Consideraes Finais

O novo processo de definio de critrios de homologao proposto neste documento objetiva permitir que organizaes definam a priori a qualidade dos seus produtos, que os softwares produzidos no Brasil tenham condies de concorrer no mercado internacional e que empresas que adquirem softwares consigam garantir que seus fornecedores iro entregar o produto de acordo com as necessidades dos usurios e da organizao. Desta forma, acredito que outros servios no mesmo contexto deste estudo de caso devero ser brevemente realizados. Mesmo diante esse contexto motivador, a aplicao das tcnicas de design centrado no usurio no trivial, requer tempo, esforo, capacitao e, acima de tudo, comprometimento por parte da organizao. A existncia de um processo para guiar a execuo das atividades se mostrou essencial para viabilizar a prestao do servio sem fugir do seu objetivo.

Pgina 62 de 64

Referncias
[1] Critrios Ergonmicos da Usabilidade, 2006. http://www.maxwell.lambda.ele.puc-rio.br [2] ISO/IEC 9126-1. Software engineering Product Quality Part 1: Quality model, 2002. [3] ISO 14598-5. Information Technology Evaluation of Software Products, 1998. [4] NBR 14598. Guia Para Utilizao das Normas Sobre Avaliao de Qualidade de Produto de Software, 2002. [5] FEITOSA, C. Definio de um Processo de Medio e Anlise com base nos Requisitos do CMMI, 2004 [6] ISO/IEC 15939, Software Engineering - Software Measurement Process [7] MCT, Ministrio de Cincia e Tecnologia. www.mct.gov.br [8] LAPS, Laboratrio de Avaliao de Produto de Software. http://www.cin.ufpe.br/laps [9] CENPRA Centro de Pesquisas Renato Archer e DQS Diviso de Qualidade de Software. Descrio do MEDE-PROS. [10] SOFTTEX - Associao para Promoo da Excelncia do Software Brasileiro. MPS-BR - Melhoria do Processo de Software Brasileiro, 2004. [11] LAPS, Laboratrio de Avaliao de Produto de Software Mdulos de Avaliao http://php.cin.ufpe.br/~laps/laps/modulos-iframe.php#4 [12] MARAVITCH, J. Um processo para avaliao de produtos de software atravs de anlise por especialista, 2005. TG 2005 CIn/UFPE. [13] Hackos, J.T., Redish, J.C. User and Task Analysis for Interface Design. John Wiley &Sons, 1998. [14] Handbook of Usability Testing: How to Plan, Design, and Conduct Effective Tests. Jeffrey Rubin [15] Quality in use: Meeting user needs for quality. Nigel Bevan [16] CYBIS, W. . Abordagem ergonmica para interfaces de computador. Florianpolis: LabIUtil, 1997. Apostila de treinamento. [17] Entrevistas, Cleidson de Souza, Departamento de Informtica - Universidade Federal do Par.

Pgina 63 de 64

[18] Hix, D.; Hartson, H. R. Developing User Interfaces: ensuring usability through product & process, John Wiley and Sons, 1993. [19] ISO 13407. Human-centered design processes for interactive systems, 1999. [20] MOO, S. . O uso de cenrios como uma tcnica de apoio para avaliaes ergonmicas de softwares interativos. Florianpolis, 1996. Dissertao de Mestrado apresentada ao Programa de Ps-graduao em Engenharia de Produo da UFSC. [21] Site Microsoft. www.microsoft.com/playtest/Publications/User%20Centered%20Game%20Design.doc [22] Site IBM. https://www-01.ibm.com/software/ucd/ucd.html [23] Object Management Group, Software Process Engineering Metamodel Specification (SPEM), Formal Submission, OMG document number formal/02-11-14, November 2002.

Pgina 64 de 64