projecto cheques-prenda sonae sierra - universidade nova de … · 2015-10-03 · fig. 9 - etapas...

PROJECTO CHEQUES-PRENDA SONAE SIERRA

por

HUGO ALEXANDRE ALVES RESENDE MARTINS

Trabalho de projecto apresentado como requisito

parcial para a obtenção do grau de

Mestre em Estatística e Gestão de Informação

pelo

Instituto Superior de Estatística e Gestão de Informação

da

Universidade Nova de Lisboa

2010

Projecto Cheques-Prenda Sonae Sierra

ii


iii

Agradecimentos

Em primeiro lugar, agradeço aos meus pais e à Ana, pelo apoio e compreensão

demonstrados durante os últimos dois anos que dediquei a este trabalho.

Ao Professor Doutor Miguel de Castro Simões Ferreira Neto, pelo apoio, motivação, e

sugestões dadas na revisão do trabalho.

À empresa Sonae Sierra, pela disponibilidade e apoio na realização deste projecto.


iv

Resumo

É atributo da qualidade de software a usabilidade deste. Usabilidade é o termo que designa

o grau de facilidade com que o usuário de um sistema realiza seus objectivos. A qualidade do

interface é fundamental na interacção pessoa-máquina. Para obter esta qualidade é

necessário haver uma avaliação durante o processo de design, permitindo assim a

identificação e ajustes ao modelo. Serão apresentados conceitos de qualidade de uso de

interfaces, métodos de avaliação e suas vantagens e desvantagens, indo de encontro às

necessidades reais do usuário, ou seja, facilidade de uso.

Indissociável a um sistema de software, surge o processo de modelação de desenvolvimento

que o antecedeu. A engenharia de software é uma área do conhecimento da computação

voltada para a especificação, desenvolvimento e manutenção de sistemas de software. Os

modelos de desenvolvimento definem ordem para uma actividade iminentemente caótica.

Estes são escolhidos com base na natureza do projecto, ferramentas ao dispor e nos

controlos e entregas requeridas. Serão apresentados alguns processos de desenvolvimento,

destacando suas características, vantagens e desvantagens, objectivando organização,

produtividade e qualidade.


v

Abstract

Usability is an attribute of software quality. It defines the ease with which the user of a

system accomplishes its objectives. The quality of the interface is fundamental in human-

machine interaction. For this quality is necessary to have an assessment during the design

process, allowing the identification and adjustments to the model. Quality concepts will be

presented to use interfaces, evaluation methods and their advantages and disadvantages,

meeting with the real needs of the user, the ease of use.

Connected to a software system, comes the modeling process of development that

preceded it. Software engineering is a knowledge field of computing focused on the

specification, development and maintenance of software systems. Development models

define the order for an activity inherently chaotic. These are chosen based on the nature of

the project tools at your disposal and the control and delivery requirements. We introduce

some development processes, highlighting their features, advantages and disadvantages,

with organization, productivity and quality in the main goal.


vi

Palavras-chave

Usabilidade, Problemas de usabilidade, Engenharia de Software, Qualidade de Software,

Processos de desenvolvimento de software, Testes de usuário, Análise Custo-benefício.


vii

Keywords

Usability, Usability problems, Software engineering, Software Quality, Software development

processes, User testing, Cost-benefit analysis.


viii

Glossários de termos

Stock - Quantidade de mercadorias em armazém; existências.

Software - Conjunto de meios não materiais (em oposição ao hardware) que servem

para o tratamento automático da informação e permitem o “diálogo” entre o

homem e o computador.

Standards - Padrão de referência.

Helpdesk - Serviço que visa o atendimento e reclamações de clientes. Serviço de apoio

ou de assistência técnica.

Checklist - Lista de controlo ou de verificação.

Flash - Software primariamente de gráfico vectorial, apesar de suportar imagens

bitmap e vídeos, utilizado geralmente para a criação de animações

interactivas que funcionam embutidas num navegador Web.

Developer - Responsável pela programação, manutenção e desenvolvimento de um dado

software.

Feedback - Reenvio à origem de informação sobre o resultado de um trabalho

efectuado.

CSS - Cascading Style Sheets. Linguagem de estilo utilizada para definir a

apresentação de documentos escritos em uma linguagem de marcação, como

o HTML ou XML.

HTML - Linguagem de marcação utilizada para produzir páginas na Web.

XML - Formato de linguagem para a criação de documentos com dados

organizados de forma hierárquica, como se vê, frequentemente, em

documentos de texto formatados, imagens vectoriais ou bancos de dados.

Breadcrumb - Caminho feito pelo usuário desde a página inicial até à corrente página

aberta pelo usuário.


ix

Acrónimos

Fig. - Figura

IA - Inteligência Artificial

ISO - International Organization for Standardization

NATO - North Atlantic Treaty Organization

R$ - Moeda Real Brasileiro

€ - Moeda Euro

OCDE - Organização para a Cooperação e Desenvolvimento Económico

Eurostat - Gabinete de Estatísticas da União Europeia

TI - Tecnologias de Informação

Tab. - Tabela

CSS - Cascading Style Sheets

HTML - Hypertext Markup Language

XML - eXtensible Markup Language

FAQ - Frequently Asked Questions

Graf. - Gráfico


x

Índice

Agradecimentos …. III

Resumo …. IV

Abstract …. V

Palavras-chave …. VI

Keywords …. VII

Glossário de termos …. VIII

Acrónimos …. IX

Índice …. X

Índice de figuras …. XIV

Índice de tabelas …. XVI

Índice de gráficos …. XVII

Capítulo I – Introdução e problema …. 1

1. Introdução e enquadramento …. 1

2. Apresentação do tema …. 3

3. Objectivos …. 5

4. Questões de investigação …. 6

Capítulo II – Revisão da literatura …. 7

1. Enquadramento …. 7

2. Usabilidade …. 10

2.1. Introdução …. 10

2.2. Definição …. 10

2.3. Testes de usabilidade …. 11

2.3.1. Avaliação heurística …. 11

2.3.1.1. Definição …. 11

2.3.1.2. Vantagens / Desvantagens …. 12

2.3.2. Avaliação baseada em guias de estilo ou guias de recomendação …. 13

2.3.2.1. Definição …. 13



xi

2.3.3. Inspecção por checklist …. 14

2.3.3.1. Definição …. 14


2.3.4. Teste empírico com usuários …. 18

2.3.4.1. Definição …. 18


2.4. Comparação …. 23

2.5. Casos de estudo na literatura …. 25

3. Engenharia de software …. 28


3.2. Definição …. 29

3.3. Processos de desenvolvimento de software …. 30

3.3.1. Modelo sequencial linear (ou em cascata) …. 30

3.3.1.1. Definição …. 30


3.3.2. Modelo em espiral …. 32

3.3.2.1. Definição …. 32


3.3.3. Modelo de prototipagem evolucionária …. 35

3.3.3.1. Definição …. 35


3.3.4. Modelo ágil …. 36

3.3.4.1. Definição …. 36


3.4. Comparação …. 42

3.5. Casos de estudo na literatura …. 45

4. Síntese da investigação …. 48

Capítulo III – Contexto empresarial …. 51

1. Estudo de viabilidade …. 51


1.2. Documento de Estudo Apresentado …. 52

2. Análise Custo-benefício …. 61


2.2. Documento de Análise Apresentado …. 61

Capítulo IV – Planeamento, desenvolvimento e implementação …. 67

1. Metodologia adoptada …. 67


xii

1.1. Apresentação …. 67

1.2. Justificação …. 67

1.3. Cronograma previsto …. 77

2. Hardware, software e arquitectura de sistema …. 79

3. Diagrama de actividades …. 83


3.2. Actividades …. 83

3.2.1. Actividade Provisionamento de cheques – Etapa encomenda …. 85

3.2.2. Actividade Provisionamento de cheques – Etapa gestão …. 86

3.2.3. Actividade Venda de cheques – Grandes clientes …. 87

3.2.4. Actividade Venda de cheques – Pequenos clientes …. 88

3.2.5. Actividade Depósitos …. 89

3.2.6. Actividade Compensações – Centro Comercial …. 90

3.2.7. Actividade Compensações – Central (MKTB2B) …. 91

3.2.8. Actividade Reposição fundo de caixa (Petty-Cash) …. 92

4. Desenvolvimento …. 93

4.1. Cronograma real …. 93

5. Implementação …. 94

5.1. Apresentação e discussão dos resultados …. 94

5.1.1. Testes de usabilidade …. 94

5.1.1.1. Cenários “Apresentação” …. 94

5.1.1.2. Cenários “Serviços Core” …. 99

5.1.1.3. Cenários “Utilitários” …. 108

5.1.1.4. Cenários “Reports” …. 123

5.1.1.5. Cenários “Administração” …. 134

5.1.2. Sumário …. 135

5.2. Cronograma previsto vs. real …. 147

6. Desenvolvimentos futuros …. 148

Capítulo V – Conclusões …. 149

Referências bibliográficas …. 152

Anexos

Anexo A – Checklist gerado e distribuído por Meyers

Anexo B – Documento especificação técnica

Anexo C – Checklist para testes de usabilidade

Anexo D – Cenários para testes de usabilidade


xiii


xiv

Índice de figuras

Fig. 1 - Visão, Conhecimento e Inovação (Johannessen, Olsen et al. 1999)

Fig. 2 - Conhecimento e Inovação (Nonaka 2007)

Fig. 3 - Framework de usabilidade segundo norma ISO 9241-11 (ISO 1997)

Fig. 4 - Gráfico usuários vs. Percentual de erros de usabilidade (Nielsen and Landauer 1993)

Fig. 5 - Testes em laboratório

Fig. 6 - Testes presenciais no ambiente do usuário

Fig. 7 - Testes remotos no ambiente do usuário

Fig. 8 - Engenharia de software, uma tecnologia em camadas

Fig. 9 - Etapas de implementação no desenvolvimento de software (Royce 1970)

Fig. 10 - Modelo em espiral (Boehm 1988)

Fig. 11 - Modelo em espiral simplificado

Fig. 12 - Modelo de prototipagem evolucionária

Fig. 13 - Metodologia Ágil, SCRUM

Fig. 14 - Metodologia Ágil, Extreme Programming

Fig. 15 - Custo da mudança num modelo tradicional (Pressman 2001)

Fig. 16 - Típica infra-estrutura virtual

Fig. 17 - Actividade Provisionamento de cheques – Etapa Encomenda

Fig. 18 - Actividade Provisionamento de cheques – Etapa gestão

Fig. 19 - Actividade Venda de cheques – Grandes clientes

Fig. 20 - Actividade Venda de cheques - Pequenos clientes

Fig. 21 - Actividade Depósitos

Fig. 22 - Actividade Compensações – Centro Comercial


xv

Fig. 23 - Actividade Compensações – Central (MKB2B)

Fig. 24 - Actividade Reposição fundo de caixa (Petty-Cash)


xvi

Índice de tabelas

Tab. 1 - Vantagens/Desvantagens da Avaliação Heurística

Tab. 2 - Vantagens/Desvantagens da Avaliação baseada em guias de estilo ou guias de

recomendação

Tab. 3 - Vantagens/Desvantagens da Inspecção por checklist

Tab. 4 - Vantagens/Desvantagens do Teste empírico com usuários

Tab. 5 - Vantagens/Desvantagens do Modelo sequencial linear (ou em cascata)

Tab. 6 - Vantagens/Desvantagens do Modelo em espiral

Tab. 7 - Vantagens/Desvantagens do Modelo de prototipagem evolucionária

Tab. 8 - Vantagens/Desvantagens do Modelo ágil

Tab. 9 - Scrum Backlog Processo de Negócio

Tab. 10- Scrum Backlog Processo de Desenvolvimento de Software

Tab. 11- Scrum Backlog Processo de Operação/Manutenção

Tab. 12- Cronograma previsto (a)

Tab. 13- Cronograma previsto (b)

Tab. 14- Cronograma real (a)

Tab. 15- Cronograma real (b)


xvii

Índice de gráficos

Graf. 1 - Checklist – Variação Facilidade de utilização

Graf. 2 - Checklist – Respostas Facilidade de utilização

Graf. 3 - Checklist – Variação Assimilação da informação

Graf. 4 - Checklist – Respostas Assimilação da informação

Graf. 5 - Checklist – Variação Organização da informação

Graf. 6 - Checklist – Respostas Organização da informação

Graf. 7 - Checklist – Variação Mensagens do sistema

Graf. 8 - Checklist – Respostas Mensagens do sistema

Graf. 9 - Checklist – Variação Nomenclatura

Graf. 10 - Checklist – Respostas Nomenclatura

Graf. 11 - Checklist – Variação Layout do interface

Graf. 12 - Checklist – Respostas Layout do interface

Graf. 13 - Checklist – Variação All Values

Graf. 14 - Checklist – Respostas All Values


1

Capítulo I – Introdução e problema

1. Introdução e enquadramento

A Sonae Sierra é responsável pela gestão de um vasto portfólio de centros comerciais e de

lazer. O modelo de negócio assenta numa estrutura integrada que reflecte as actividades de

propriedade, promoção e gestão de centros comerciais.

Como estratégia de futuro, a Sonae Sierra pretende manter-se concentrada no “núcleo

duro” das suas actividades integradas de investimento, promoção e gestão de centros

comerciais e lazer, criando “destinos de eleição” para os consumidores:

Tendo uma concepção integrada da indústria de centros comerciais e de lazer, em

que o valor acrescentado é conseguido não só pela promoção imobiliária, mas

também por uma activa gestão operacional da propriedade;

Procurando, em todas as áreas geográficas que pretende explorar, inovar o mercado

e renovar os conceitos de negócio instalados, através de parcerias locais, com

actuações e investimentos de longo prazo;

Criando e desenvolvendo conceitos e serviços que acrescentam valor à oferta de

imobiliário de retalho e que produzam, directa ou indirectamente, crescimento de

proveitos.

Sobre o domínio do conceito de inovação foi criado o serviço de Cheque-Prenda. Como o

próprio nome indica é um cheque que pode ser utilizado num determinado grupo de lojas

aderentes ao programa em qualquer centro Sonae Sierra garantindo uma ampla liberdade

de escolha a quem o recebe. Os valores disponíveis cifram-se nos 50€, 25€, 10€ e 5€ nos

centros europeus e R$75 e R$50 nos centros do Brasil.

O serviço aponta para dois targets:

O consumidor comum que compra para oferecer;

Empresas que desejam valorizar o seu relacionamento com colaboradores, clientes e

fornecedores, comprando e oferecendo a estes.

Sendo o serviço transparente para estes dois targets, não o é para a empresa emissora, que

além de querer responder às novas tendências de negócio, pretende ter um sistema que

centralize e agilize o ciclo de vida de um Cheque-prenda.


2

Com este projecto pretendemos implementar um sistema que atenda às necessidades da

empresa Sonae Sierra nas áreas de:

BackOffice, onde se irá controlar o ciclo de vida de um Cheque-Prenda, desde a sua

encomenda até à sua compensação;

FrontOffice, ou balcão de atendimento ao público, onde se irá vender ou compensar

o cheque.

A equipa de projecto será composta por três pessoas, estando só uma destas a fulltime. O

gestor sendo o elemento não a fulltime, em certas fases de projecto será igualmente

developer. Todos os elementos da equipa têm participação em todas as etapas de

desenvolvimento do software, que vão desde o estudo de viabilidade até à entrega de

produto e seu plano de manutenção.

Nesta equipa desempenho o papel de gestor de projecto, fazendo a ponte entre o negócio e

a equipa de projecto. Participo igualmente como developer.


3

2. Apresentação do tema

Nos últimos anos tem-se assistido à massificação de produtos para consumo existentes no

mercado. Esta massificação leva à diferenciação de cada um nos seus gostos. Concerteza já

nos perguntámos: o que oferecer a alguém? Será que essa pessoa vai gostar? Para esta e

outras perguntas surgiu o conceito de Cheque-Prenda. Simples, prático, eficaz, inovador,

dando a liberdade de escolha a quem os recebe.

Para o consumidor final todo este processo resume-se à compra e à troca deste por outro

produto, mas para a empresa emissora é mais do que isso. Desde a sua emissão até à sua

compensação vai um longo percurso, sendo este aquele que queremos traduzir num único

sistema aplicacional.

Nem sempre a inovação é o resultado da criação de algo totalmente novo. Podemos pensar

que novas ideias poderão não criar algo de novo, mas sim transformar/recombinar

processos já existentes com o objectivo de agregar valor e simplificar o processo no seu todo

(Popadiuk and Choo 2006). Este problema será discutido mais à frente.

O sistema aplicacional a desenvolver, irá traduzir um sistema simples que de uma forma fácil

mostre:

Em que centro comercial está um determinado cheque?

Onde foi um vendido um determinado cheque? Por quem e a quem?

Onde foi compensado um determinado cheque? Por quem e a quem?

Gestão documental de facturas e recibos;

Reports de Vendas vs. Clientes;

Entre outros dados.

Tendo então como base este conhecimento, a empresa poderá em última instância,

responder a questões como:

Já que tenho que manter um stock de cheques, qual o número de cheques que devo

encomendar à Casa da Moeda1 de forma a que o tempo entre o investimento e o

lucro seja reduzido?

Quais os centros que vendem mais, e com os quais tenho que me preocupar de

forma a manter um stock constante?

1 A Imprensa Nacional – Casa da Moeda (INCM) é uma sociedade anónima de capitais públicos. A empresa tem

a seu cargo a produção e bens e serviços fundamentais ao funcionamento do Estado português, como a cunhagem da moeda metálica e a edição de publicações oficiais, onde se destaca o Diário da República.


4

Poderei ter um único repositório de dados, onde esteja transparecido todo o ciclo de

vida de um Cheque-Prenda?

Poderei criar um sistema onde todas as requisições sejam feitas online, só existindo o

papel na figura do cheque e no recibo de compra, minorando os custos?


5

3. Objectivos

O desenvolvimento de software em grande escala obriga à adopção de um processo de

engenharia de software que defina uma abordagem sistemática para a gestão e concepção

das várias valências envolvidas na produção e manutenção do software. O objectivo é

assegurar a produção de software com elevada qualidade, que responda aos requisitos do

usuário final, dentro dos prazos previstos no projecto e utilizando os recursos

dimensionados.

Assim define-se como principal objectivo deste trabalho: Apresentar uma aplicação simples,

intuitiva e agregadora de todos os módulos que constituem o ciclo de vida de um Cheque-

Prenda. Fazendo esta agregação pretende-se identificar todas as variáveis

comportamentais deste associado ao consumidor e/ou empresa, perseguindo a Sonae

Sierra, uma política de ligação directa com os seus targets.

Com a construção deste sistema, pretende-se alcançar os seguintes objectivos específicos:

1. Consoante as vendas, apurar as necessidades de stock de cheques, por centro ou

serviços centrais;

2. Utilizando métricas, propor encomendas de cheques à Casa da Moeda, gerando toda

a documentação necessária;

3. Dar entrada das encomendas realizadas;

4. Distribuição/Controle do stock de cheques, nos centros ou serviços centrais;

5. Venda de cheques a consumidores, lojistas ou empresas;

6. Compensação de cheques a lojistas e apuramento de fee a reter;

7. Controle dos cheques fora da validade;

8. Controle dos cheques que saíram do circuito (em caso de furto ou perca no

transporte entre centros e/ou serviços centrais);

9. Apuramento de métricas associadas à relação cheques/lojistas e

cheques/consumidor.

A nível departamental temos como objectivos:

1. Entregar o produto;

2. Obedecer aos requisitos do cliente;

3. Continuarmos activos e sólidos após a entrega;

4. O cliente pretender utilizar os nossos serviços no futuro.


6

4. Questões de investigação

Dada a natureza deste projecto, este traduz-se numa operação limitada no tempo e no

custo. Apesar de todos os recursos terem sido postos à disposição, embora não em fulltime,

como contrapartida pretende-se que este seja um projecto com um tempo de execução

rápido, não ultrapassando os seis meses.

Desta forma as questões de investigação são:

Qual o melhor processo de desenvolvimento de software a aplicar de forma a obter

um conjunto de resultados bem definidos garantindo a qualidade de standards e

requisitos, nos tempos previstos e dentro dos custos definidos pela organização?

Qual a melhor estratégia de desenho de forma a procurar a simplificação de

processos, procurando atingir o conceito de self explained?

Poderá a IA, substituir o humano em alguns módulos deste ciclo de vida do Cheque-

Prenda? Como exemplo refiro a questão das encomendas de cheques à Casa da

Moeda conforme as necessidades e estatística do passado;

Testes de qualidade do software e uma correcta gestão do risco, como forma de

minorar o erro e minimizar o tempo e recursos de manutenção.


7

Capítulo II – Revisão da literatura

1. Enquadramento

Definimos previamente como um dos objectivos deste trabalho apresentar uma aplicação

simples, intuitiva e agregadora de todos os módulos que constituem o ciclo de vida de um

Cheque-Prenda.

Nem sempre a inovação é o resultado da criação de algo totalmente novo. Podemos pensar

que novas ideias poderão não criar algo de novo, mas sim transformar/recombinar

processos já existentes com o objectivo de agregar valor e simplificar o processo no seu

todo.

Podemos então entender como inovação, a implementação de um produto (bem ou serviço)

novo ou significativamente melhorado, ou um processo, ou um novo método de marketing,

ou um novo método organizacional nas práticas de negócios, na organização do local de

trabalho ou nas relações externas (OCDE and Eurostat, Manual de Oslo, 1996).

O conceito de inovação pode ser diferenciado em quatro tipos de inovação (OCDE and

Eurostat, Manual de Oslo, 1996):

Inovação de produto. Produtos ou serviços, novos ou significativamente melhorados.

Alterações significativas nas especificações técnicas, componentes, materiais,

software incorporado, interface com o usuário ou outras características funcionais;

Inovação de processo. Métodos de produção ou distribuição, novos ou

significativamente melhorados. Alterações significativas de técnicas, equipamentos

ou software;

Inovação de marketing. Implementação de um novo método de marketing com

mudanças significativas na concepção do produto ou em sua embalagem, no

posicionamento do produto, em sua promoção ou na fixação de preços;

Inovação organizacional. Implementação de um novo método organizacional nas

práticas de negócios da empresa, na organização do seu local de trabalho ou em suas

relações externas.

Podemos afirmar que existe uma relação benéfica entre a pesquisa científica e inovação.

Elementos como a criatividade podem sustentar o conceito de inovação, mas a necessidade

de uma base de conhecimento prévio principalmente tácito e de pesquisa científica, vai

actuar como catalisador na ampliação de horizontes e quebra de paradigmas estabelecidos.


8

Como tal em organizações, o processo de criação de conhecimento organizacional é o

principal factor para a geração de inovação.

Segundo o modelo desenvolvido por Johannessen, Olsen e Olaisen (1999) a inovação tem

como input conhecimento para produzir conhecimento. Segundo o modelo apresentado em

seguida, a visão de uma organização direcciona a criação do conhecimento, que por outro

lado suporta a inovação organizacional e permite a integração e aplicação do conhecimento.

Fig. 1 – Visão, Conhecimento e Inovação (Johannessen, Olsen et al. 1999)

Outros autores como Nonaka (2007), entendem o processo de criação de conhecimento

organizacional, como a capacidade da organização para criar conhecimento, difundi-lo em

todas as áreas e incorporá-lo a bens, serviços e sistemas. Este processo tem por base a

inovação contínua e em espiral.

Fig. 2 – Conhecimento e Inovação (Nonaka 2007)

Em paralelo, Popadiuk e Choo (2006) partem da definição de inovação como sendo a de

novas ideias que transformam processos, serviços ou bens, com o objectivo de agregar valor.

Como base considera-se que as ideias surgem da interacção entre pessoas num ambiente


9

próprio e estimulador à sua criação. Estes autores afirmam a existência de duas dimensões

do conhecimento necessárias à inovação:

Capacidade organizacional para criação de inovação. Relacionado com a exploração

do conhecimento onde interage o conhecimento tácito e explícito;

Conhecimento do mercado. Relacionado com a aplicação do conhecimento.

Henderson e Clark (1990) classificam as inovações em dois tipos:

Inovações radicais, as que destroem competências, quando cria-se um novo design

conceptual no produto, mudando tanto o conhecimento embutido nos componentes

quanto a arquitectura entra as suas partes. São ocorrências a nível mundial, que

revolucionam a indústria, baseando em melhorias substanciais de desempenho e

geralmente assentes em novas tecnologias, ou novos modelos de negócio;

Inovações incrementais, as quais aprimoram competências ao adicionar

conhecimento, provocando mudanças no produto existente e aproveitando o

potencial do design já estabelecido. Visa uma melhoria contínua em processos

existentes, ou por redução dos custos do processos, ou melhorando processos

produtivos.

Com base nas definições de inovação de Henderson e Clark (1990), Popadiuk e Choo (2006)

afirmam que as inovações incrementais surgem da socialização e externalização do

conhecimento tácito.

Com este projecto propomo-nos a inovar sobre os processos já existentes. Embora hoje

alguns destes processos se baseiem na utilização de folhas Excel e troca de emails, sentimos

que poderemos utilizar o conhecimento já existente na organização, para desenvolver um

produto unificador de processos, intuitivo e de fácil utilização por parte de todos os

intervenientes no processo.


10

2. Usabilidade

2.1. Introdução

Termos um único repositório de dados, com um único interface que em termos de layout

seja partilhado por todos os intervenientes no sistema, onde existam mensagem de erro ou

sucesso standard entre todos os módulos, tem as suas vantagens. Desenhar interfaces

intuitivas para o usuário é uma das bases para o desenho de sistemas.

Se os usuários virem que o sistema não é intuitivo, usável, pode levar à rejeição do sistema

no momento e no futuro, comprometendo o tempo de vida deste.

Usabilidade está directamente ligada ao diálogo na interface e à capacidade do sistema

permitir que o usuário alcance as suas metas de interacção com este.

2.2. Definição

Segundo definição da International Organization for Standardization, usabilidade é a medida

resultante de uma medição, pela qual um produto pode ser usado por usuários específicos

para alcançar objectivos específicos com efectividade, eficiência e satisfação em um

contexto de uso específico (ISO 1997).

A efectividade é avaliada quer em termos de finalização de uma tarefa, quer pela qualidade

do resultado obtido. A eficiência refere-se à medição do esforço, recursos necessários e

erros cometidos, com vista a um dado objectivo. A satisfação é um tema subjectivo e está

relacionado com o nível de conforto que o usuário tem ao utilizar o interface.

A preocupação base da usabilidade é dotar os interfaces de características que tornem os

sistemas mais fáceis de usar e self explained.

O uso de testes de usabilidade permite:

Reduzir o número de chamadas de helpdesk por parte do usuário. Fraca usabilidade é

umas das principais razões de chamadas de suporte. O maior número de chamadas

implica um maior número de recursos, o que implica um maior custo à organização;

Reduzir o custo associado à formação. Um produto de fácil aprendizagem, faz com

que o usuário retenha mais depressa e por mais tempo o conhecimento;


11

A facilidade de uso está ligada à aceitação mais fácil do produto. Questões como a

fidelidade a um produto e a sua recomendação a outros usuários são aqui tocadas;

Diferenciação do produto face à concorrência. Se dois produtos se equivalem em

termos de características, ganha o que tiver melhor usabilidade.

É um dos objectivos deste trabalho dar uma descrição pormenorizada de alguns testes de

usabilidade utilizados, tal como as suas vantagens e desvantagens e melhor ou pior

adaptabilidade ao processo de desenvolvimento que queremos implementar.

2.3. Testes de usabilidade

2.3.1. Avaliação heurística

2.3.1.1. Definição

Entende-se por avaliação heurística o processo de estimar o estado da usabilidade de uma

dada aplicação, confrontando-o com regras bem conhecidas. Desse processo resulta uma

classificação baseada no cumprimento dessas regras.

Nielson e Molish (1990) desenvolveram um método de avaliação heurística usando um

conjunto simples e geral de heurísticas:

1. Diálogo simples e natural;

2. Falar a língua materna do usuário;

3. Minimizar o recurso à memória do usuário;

4. Ser consistente;

5. Transmitir feedback;

6. Existência de saídas desmarcadas;

7. Existência de shortcuts;

8. Existência de mensagens de erros claras;

9. Prevenir o erro.

O conjunto final de heurísticas foi lançado por Nielsen (1994). Estes dez princípios para o

desenho de interfaces, ainda hoje são utilizados:


12

1. Feedback. O sistema deve informar continuamente ao usuário, sobre o estado das

suas acções;

2. Falar a linguagem do usuário. A terminologia utilizada deve ser baseada na

linguagem do usuário e não orientada ao sistema;

3. Saídas claramente desmarcadas. O usuário é o administrador do sistema. Ele pode a

qualquer momento, abortar uma tarefa e retornar ao estado anterior;

4. Consistência. Um mesmo comando ou acção deve ter sempre efeito igual. A mesma

operação deve ser apresentada na mesma localização e deve ser formatada da

mesma maneira para facilitar o reconhecimento;

5. Prevenir erros. Conhecer as situações que mais provocam erros e modificar a

interface de modo a que estes não ocorram;

6. Minimizar a sobrecarga de memória do usuário. O sistema deve mostrar os

elementos de diálogo e permitir que o usuário faça as suas escolhas, sem

necessidade de lembrar um comando específico;

7. Atalhos. Para usuários experientes executarem as operações mais rapidamente; Para

recuperar informação que se encontra distante por navegação, da interface principal;

8. Diálogos simples e naturais. Deve-se apresentar exactamente a informação que o

usuário precisa no momento, nem mais nem menos; a sequência de interacção e o

acesso aos objectos devem ser compatíveis com o modo pelo qual o usuário realiza

as suas tarefas;

9. Boas mensagens de erro. Linguagem clara e sem códigos. Não devem culpar ou

intimidar o usuário;

10. Ajuda e documentação. O ideal é que um sistema seja tão intuitivo que não

necessite de ajuda ou documentação. Se for necessária ajuda deve estar facilmente

acessível.

2.3.1.2. Vantagens / Desvantagens

Baixo Custo;

Intuitivo, aumentado a motivação para o fazer;

Não requer um planeamento minucioso;

Pode ser usado durante a fase de desenvolvimento, de forma a minorar o tempo de

aceitação do cliente.

Problemas de usabilidade poderão ser detectados, mas sem sugestões directas de

como os resolver;

Quer o tempo de desenho, quer o desenvolvimento poderão ser afectados.


13

Tab. 1 – Vantagens/Desvantagens da Avaliação Heurística

2.3.2. Inspecção baseada em guias de estilo ou guias de recomendação


A inspecção baseada em guias normalmente é utilizada em conjunto com outros métodos de

avaliação, como por exemplo, a avaliação heurística. Os guias baseiam-se em conjuntos de

requisitos, critérios ou princípios básicos a serem verificados no sistema em avaliação. Pela

própria natureza de um guia, este destina-se a avaliar problemas gerais e repetitivos do

sistema.

Guias de estilo

Normalmente documentos internos a uma organização com descrições detalhadas de

elementos iterativos específicos a um sistema, como menus, janelas, entre outros. Tem por

objectivo estabelecer padrões e modelos de forma à uniformização de sistemas (internos e

externos), e identificação de uma imagem única de organização.

Guias de recomendação

Normalmente documentos publicados em livros, relatórios ou artigos, com recomendações

geradas e validadas a partir de observações empíricas ou experiência prática do seu autor.

Os guias de estilo e os guias de recomendações, apresentam sugestões e/ou recomendações

com vista a uma melhor usabilidade, tendo como base a padronização de produtos e a

experiência na construção passada de sistemas.


Base sólida e eficaz para detecção de problemas gerais e repetitivos do sistema;

Uniformização na interacção com o usuário;

Melhorar a consistência do sistema.


14

Não é garantido que resolva todos os problemas de usabilidade do sistema avaliado.

Tab. 2 – Vantagens/Desvantagens da Avaliação baseada em guias de estilo ou guias de recomendação

2.3.3. Inspecção por checklist


Ao contrário das avaliações heurísticas, são mais as qualidades explícitas das ferramentas

(lista de verificação) e menos os conhecimentos implícitos dos avaliadores que determinam

as possibilidades para avaliação.

Uma inspecção por checklist é conduzida percorrendo um conjunto de guias de

recomendação. Este tipo de inspecção pode ser curta ou longa, pretendendo atingir um

menor ou maior âmbito.

Nielsen e Tahir (2002) sugerem uma avaliação de sites a partir de uma checklist de 113

directrizes de usabilidade. Das 113 directrizes, Meyers (2010), como forma de mapear o seu

conhecimento e experiência como avaliador de sites surgiu com 25 directrizes. Estas

apontam fundamentalmente aos pontos críticos na usabilidade num site, adaptando-se de

uma forma mais eficaz ao processo de engenharia de software nos nossos dias (Qualidade

vs. Tempo). É de salientar que pelo próprio autor, nem todas as directrizes são

necessariamente aplicáveis a todos os sites.

Meyers (2010) agrupou a sua checklist em quatro secções:

Acessibilidade. Contém questões de acessibilidade tradicional, tal como aspectos

que podem fixar ou não, um usuário no site.

1. Tempo de resposta do site no carregamento. Com a panóplia de sites existentes,

o facto de um ser lento leva-o a perder para outros que são rápidos;

2. Contraste letra/background adequado. Um bom e confortável contraste entre as

cores de letra e fundo, permitem a boa visão deste;


15

3. Letra com tamanho e espaçamento de fácil leitura. Uma letra de tamanho

pequeno, poderá aumentar o conteúdo de janela visível, mas a massificação de

informação tal como o desconforto na visão deverá prevalecer;

4. Flash e outros Add-ons usados adequadamente. Novas tecnologias poderão ser

usadas, mas só quando o tempo de carregamento destas for baixo, o fim o

justificar e o usuário ser capaz de as usufruir;

5. Imagens com legendas ou tooltips. Estar atento a usuários com deficiências, que

utilizam esta tecnologia para a compreensão de imagens;

6. Páginas de erro personalizadas. Uma página com o erro standard dado pelo

browser é meio caminho para a perca de um usuário;

Identificação. Contém questões sobre a identificação da empresa.

7. Logo de empresa visível. Colocar o logo de empresa onde seja fácil de encontrar.

Como standard no canto superior esquerdo.

8. Objectivo do site intuitivo. Responder à pergunta “O que fazemos?” de forma

concisa e descritiva;

9. Homepage intuitiva e de fácil e rápida compreensão. Definir um espaço de

tempo, normalmente entre 5 e 10 segundos, que é o que leva a termos uma ideia

geral do objectivo do site;

10. Rápido acesso à informação da empresa;

11. Rápido acesso aos contactos da empresa. Como poder contactar a empresa em

caso de dúvida, informação ou problema;

Navegação. Após a correcta identificação da empresa, o usuário precisa de localizar

rapidamente a informação que interessa para ele.

12. Navegação do site é de fácil identificação e localização. Navegação de fácil

localização, leitura e usabilidade;

13. Textos de navegação concisos e de fácil compreensão;

14. Baixo número de botões/links;

15. Logo de empresa com link para a homepage. Por ser um standard, o usuário

espera que ao pressionar o logo da empresa, seja redireccionado para a

Homepage;

16. Links consistentes e de fácil identificação. Por ser um standard, o usuário espera

que uma referência a um link esteja identificado com uma azul, ou sublinhado;

17. Motor de pesquisa de fácil acesso. Caso o site o possua, como standard localiza-

se no canto superior direito, acompanhado por um botão simples e claro;


16

Conteúdo. Fundamental, contudo conciso, consistente, organizado e de fácil

entendimento.

18. Posições do texto bem definidas. Manter o texto bem organizado, utilizando

tamanhos de letra e espaçamentos de forma a delimitar áreas e/ou assuntos;

19. Conteúdo crítico no topo da página. Toda a informação crítica que queremos dar

ao usuário (normalmente na homepage) deverá estar localizada no topo desta;

20. Estilos e cores consistentes. Manter o usuário focado no site e em todas as

páginas que o constituem, mantendo a consistência e comportamento deste;

21. Utilização moderada do destaque (bold). Utilizar o destaque de forma

moderada, não correndo o risco de ao inseri-lo em todo o texto, perdê-lo para o

usuário;

22. Anúncios e pop-ups discretos. Minimizar a existência destes, mas quando

precisos, directos e simples;

23. Conteúdo conciso e sem repetições. Textos concisos, directos ao assunto e sem

repetições;

24. URLs significativos. Nem sempre possível devido aos editores de página, mas

quando for possível, inserir alguma descrição do destino no próprio path;

25. Títulos de página HTML. Cada página deverá ter um título descritivo, único e

conciso que a distinga.

Tal como no checklist, Meyers (2010) procurou manter a simplicidade no tipo de resposta

com três categorias básicas:

Verde Check (V) = Aprovado

Vermelho Check (V) = São precisos ajustes

Vermelho Cross (X) = Reprovado

Está disponível no Anexo A, o checklist gerado e distribuído por Meyers.

Como outro exemplo temos as normas ISO 9241-11 (ISO 1997) que define usabilidade como

a capacidade de um produto pode ser usado por usuários específicos para alcançar

objectivos específicos com efectividade, eficiência e a satisfação em um contexto de uso

específico.


17

Fig. 3 – Framework de usabilidade segundo a norma ISO 9241-11 (ISO 1997)

Usuário. Usuário que interage com o produto;

Contexto de uso. Usuários, tarefas, equipamentos, ambiente físico e social em que o

produto é usado;

Efectividade. Permite que o usuário atinja os objectivos iniciais de interacção, e tanto

é avaliado em termos de finalização de uma tarefa como também em termos de

qualidade do resultado obtido;

Eficiência. Refere-se à quantidade de esforço e recursos necessários para se chegar a

um determinado objectivo;

Satisfação. Traduz o nível de conforto que o usuário sente ao utilizar a interface,

medido a nível objectivo e/ou subjectivo. As medidas objectivas de satisfação têm

como base a observação do comportamento do usuário (postura e movimento

corporal) ou na monitorização das respostas fisiológicas. As medidas subjectivas são

produzidas pela quantificação das reacções, atitudes e opiniões expressas pelos

usuários.

Outro exemplo de checklist é proposto pelo site Ergolist. Aqui temos a vantagem de

podermos preencher a checklist e obter seus resultados online.

Quer Nielsen e Tahir (2002), quer Meyers (2010), afirmam que os checklists propostos são

apenas guias de recomendação. Cada organização, cada projectista, cada developer, deverá

definir o seu próprio checklist, adequado ao projecto e usuários a que se destina.


18


Devido ao conhecimento estar embutido na própria checklist, poderá ser realizado

por projectistas do sistema e não por profissionais em interfaces;

Facilidade de identificação de problemas gerais e repetitivos;

Sistematização que leva o avaliador, obrigatoriamente, a uma visão de todo o

sistema;

Redução do custo de avaliação, pois é um método de rápida aplicação.

O resultado da aplicação do checklist não identifica todos os tipos de problema de

usabilidade por não envolver ensaios de avaliação com usuários.

Tab. 3 – Vantagens/Desvantagens da Inspecção por checklist

2.3.4. Teste empírico com usuários


São testes baseados na observação da interacção homem-máquina. Consiste em observar e

monitorizar a interacção do usuário com o sistema, num ambiente controlado, ao longo de

várias actividade previamente planeadas, estando estão ligadas às funcionalidades core do

sistema.

Esta ligação permite que funcionalidades na interface do sistema sejam testadas pelo

usuário, ao mesmo tempo que observadores, capturam informação com recurso a meios

auxiliares, tais como, câmeras de vídeo, gravadores áudio, software de monitorização, etc. É

de notar que o usuário deverá ser sempre informado das condições em que serão feitos os

testes e dos meios de captação de informação usados.

Os testes empíricos podem ser:

Qualitativos. Através de técnicas de verbalização e co-descoberta;

Quantitativos. Com aplicação de métodos de medida de desempenho.


19

A verbalização pode ser caracterizada como a conversa do usuário, durante ou após a

realização do teste, sobre os problemas encontrados. Pode ser estimulada pelo observador.

A co-descoberta é o teste aplicado semelhante à verbalização, com a diferença da

participação simultânea de dois usuários na realização da mesma tarefa.

O método de medida de desempenho é usado para aferir o tempo total gasto pelo usuário

para completar uma ou mais tarefas específicas e verificar se elas foram finalizadas sem

erros.

Outro factor crucial de sucesso para este tipo de teste é o número de usuários envolvidos

neste. Estes por norma são seleccionados através de um questionário, no qual é aferido o

perfil do usuário que se pretende. Para esta selecção é recomendado (Prates and Barbosa

2003):

Igual número de homens e mulheres, caso o sexo do participante não for uma das

características de perfil requerido;

Experiência de utilização no sistema, ou em similares.

Segundo Nielsen e Laundauer (1993) os melhores resultados apresentam-se com um

universo de não mais de cinco pessoas correndo o maior número de pequenas actividades.

Na sua pesquisa, Nielsen e Laundauer (1993), mostraram que o número de problemas de

usabilidade encontrados num teste de usabilidade com n usuários é dado por:

N(1-(1-L)n)

N é o número total de problemas de usabilidade no desenho de sistema e L a proporção de

problemas de usabilidade descobertos a quando o teste de um único usuário. O valor típico

para L é 31%, sendo este valor determinado pelos autores pela sua experiência em projectos

anteriores. Aplicando L à função temos o seguinte gráfico.


20

Fig. 4 – Gráfico Usuários vs. Percentual de erros de usabilidade (Nielsen and Landauer 1993)

Analisando o gráfico podemos constatar:

1. Zero usuários geram zero erros de usabilidade reportados;

2. Um único usuário consegue identificar aproximadamente 30% dos problemas da

aplicação;

3. Cada novo usuário encontra igualmente 30% de problemas. Destes uma parte

representam novos problemas, enquanto a outra representam problemas já

encontrados por usuários anteriores;

4. A partir de cinco usuários, o aumento no número de usuários não corresponde a um

ganho significativo.

Segundo Nielsen e Laundauer (1993) a percentagem de erros de usabilidade encontrados

por um grupo de cinco usuários é de 85%, o que representa a melhor relação Custo-

benefício. Para estes autores se efectuarmos o teste com quinze usuários teremos

potencialmente encontrado todos os problemas da aplicação, mas mais vale efectuarmos

três vezes o teste com cinco usuários do que uma só vez com quinze. Isto porque ao

efectuarmos um teste a uma solução, esta é reavaliada e não teremos forma de a testar

novamente se no primeiro teste já tivermos utilizado os quinze usuários. Assim, esperando

que no máximo a cada teste com cinco usuários se encontrem 85% dos problemas

caminharemos para uma solução óptima.

Após a definição do universo de usuários, definimos a estrutura onde o teste vai ocorrer.

Para tal existem três possibilidades:


21

Fig. 5 – Testes em laboratório

Testes em laboratório. Todas as variáveis estão sendo monitorizadas e podem ser

alteradas conforme necessidade. Como desvantagem temos a ansiedade do usuário

por estar num ambiente fechado e considerar que pode estar a ser testado;

Fig. 6 – Testes presenciais no ambiente do usuário


22

Testes presenciais no ambiente do usuário. Estamos perante o ambiente real de

utilização do software, mas como desvantagem a distracção que factores externos

podem trazer ao observador e usuário;

Fig. 7 – Testes remotos no ambiente do usuário

Testes remotos no ambiente do usuário. É utilizado um software de monitorização

remoto. Tem a vantagem de libertar o usuário de qualquer pressão, mas impossibilita

o observador de qualquer controle;

Em relação ao tempo estimado para um teste, é de interesse que este não seja nem muito

curto e nem muito longo. O tempo de realização moderado, que não canse o usuário e nem

afecte a qualidade do teste, poderá ser encontrado realizando um teste piloto de forma a

apurar o tempo médio de realização de um conjunto de actividades.


Número reduzido de usuários requeridos para testes;

Facilidades de identificação de problemas gerais e repetitivos.


23

Testes dispendiosos, pois envolvem o uso de equipamentos especiais, a presença

efectiva de usuários finais e a necessidade de tempo adicional para a organização

precisa dos dados;

A sua aplicação deve ser bem avaliada quanto ao custo vs. benefício.

Tab. 4 – Vantagens/Desvantagens do Teste empírico com usuários

2.4. Comparação

O teste de usabilidade por avaliação heurística permite uma avaliação contínua do processo,

aliado ao baixo custo. Envolve especialistas avaliando o design com base em um conjunto de

critérios de usabilidade ou heurísticas. O design é avaliado em busca de instâncias nas quais

esses critérios são violados.

Embora simples e relativamente rápido, o avaliador terá que ter um amplo conhecimento,

para a aplicação correcta das heurísticas. Por outro lado, resultados anteriores mostram que

são necessários de 2 a 5 avaliadores para se conseguir um bom resultado.

Quais são então bons candidatos para um teste de usabilidade por avaliação heurística?

Sistemas com um baixo custo orçamentado, e que exigem testes de usabilidade simples e

rápidos de forma a não afectar prazos de entrega, podendo estes mesmos serem feitos

durante a etapa de desenvolvimento. A existência de pelo menos dois avaliadores com

amplo conhecimento é requisito mínimo.

O teste de usabilidade por inspecção baseada em guias de estilo ou guias de recomendação

pretende ser usada como um add-on a outros métodos de avaliação, como por exemplo a

avaliação heurística. Os guias não são mais do que um conjunto de requisitos, critérios ou

princípios básicos a serem verificados, podendo estes basear-se em padrões e modelos

usados pela organização – guias de estilo – ou em documentos, artigos ou relatórios

publicados e validados pela experiência do seu autor – guias de recomendação.

Quais são então bons candidatos para um teste de usabilidade por inspecção baseada em

guias de estilo ou guias de recomendação? Neste caso poderemos considerar que serão os

mesmos que os apontados para uma avaliação heurística, contudo o tempo extra requerido

poderá afectar o prazo de projecto.

Ao contrário da avaliação heurística, no teste de usabilidade de inspecção por checklist as

qualidades explícitas de uma lista de verificação sobrepõem-se aos conhecimentos implícitos

dos avaliadores. Esta técnica de avaliação pretende descobrir os defeitos ergonómicos mais


24

flagrantes de uma interface. Como tal avaliações mais detalhadas, envolvendo interfaces

complexas, devem ser realizadas por outras técnicas como heurísticas e/ou ensaios de

interacção com usuários.

O tempo afecto a este tipo de avaliação é proporcional à abrangência dos guias de

recomendação que a constituem. Normalmente o tempo é curto pois estes apontam

fundamentalmente aos pontos críticos na usabilidade.

Quais são então bons candidatos para um teste de usabilidade de inspecção por checklist?

Sistemas com um baixo custo orçamentado, coincidindo com o baixo custo deste tipo de

avaliação. No entanto algum tempo de projecto terá que ser dedicado à feitura de uma

checklist própria, adequada ao projecto e seus usuários.

O teste de usabilidade empírico com usuários tem por objectivo observar e monitorizar a

interacção do usuário com o sistema, num ambiente controlado, onde várias funcionalidades

core do sistema são testadas. Ao mesmo tempo que o usuário realiza uma tarefa este é

observado, revelando assim erros cometidos e frustração ou rapidez no processo e

satisfação. Software e/ou hardware de monitorização é usado, com vista a registar toda a

interacção, para estudo posterior.

O tempo para a realização deste tipo de teste requer-se moderado, com vista a não cansar o

usuário, mas ao mesmo tempo não afectar a qualidade do mesmo. O correcto estudo da

relação custo vs. benefício deve ser bem avaliado.

Quais são então bons candidatos para um teste de usabilidade empírico com usuários?

Sistemas que são construídos a pensar no negócio, sendo fundamentais para este, tendo já

previsto no orçamento um custo elevado para este tipo de avaliação. O tempo de projecto

dedicado a estudar a interacção entre este e o usuário e a aperfeiçoá-la é requisito principal

com vista à correcta e fácil entrada em produção.

A usabilidade de um sistema é condição essencial para a sua aceitação pelo usuário. Deve-se

ter em conta que a elaboração e realização de testes de usabilidade aplicados a um sistema,

é um indicador infalível para problemas que poderão ocorrer a quando a sua passagem a

produtivo. Estes devem ser tidos como parte integrante do processo de desenvolvimento de

software, não devendo ser encarados como descartáveis para redução de custos e/ou prazos

de entrega.

2.5. Casos de estudo na literatura


25

Um teste de usabilidade na sua forma mais simples, por exemplo estando lado a lado com o

usuário vendo este usando o software, pode ser a condição que separa o sucesso do

fracasso do projecto. Este simples teste apresenta para a organização um custo

negligenciável, aumentando este conforme o rigor que queiramos atribuir ao teste.

O uso de testes de usabilidade na implementação de sistemas e portais corporativos, deverá

no curto prazo tornar-se como que obrigatório. Um teste bem planeado, com usuários

treinados, ferramentas e procedimentos bem definidos, permite não só efectuar testes de

qualidade, como por consequência apontar à melhoria do produto.

Anacleto e Floriano (2008) elaboraram um artigo que tem como objectivo apresentar todos

os aspectos a serem considerados durante o planeamento deste tipo de testes. Para estes a

realização de testes é parte essencial no processo de desenvolvimento de um software ou

portal corporativo. A partir deste é possível detectar erros, verificar inconsistências e avaliar

a experiência dos usuários no contacto com o produto. Igualmente os dados importados dos

testes influenciam a tomada de decisões importantes sobre o planeamento do projecto,

como o prazo para produção e estratégia de evolução.

Para os autores um teste de usabilidade deve contemplar as seguintes dimensões:

Usuários. Num teste de usabilidade, a escolha dos participantes revela-se de grande

importância. Estes devem representar de uma forma inequívoca os usuários finais do

sistema, uma vez que as decisões tomadas após avaliação dos resultados obtidos por

este grupo irão influenciar toda a organização.

Ferramenta de Colecta de Dados. Os dados recolhidos provêm sempre da interacção

do usuário com o sistema. Esta ferramenta deverá sempre tocar em dois pontos: o

registo do comportamento do usuário e sistema durante a realização do teste; e a

realização de entrevistas e/ou preenchimento de questionários pelo usuário.

Equipa de acompanhamento. Uma equipa especializada deverá acompanhar o teste,

garantido o cumprimento dos procedimentos especificados, aplicando com eficácia o

teste e garantindo assim a qualidade dos resultados.

Report. Após a obtenção de dados a partir dos testes de usabilidade, é necessário

analisá-los e documentá-los. Com base em medidas de avaliação definidas pela

equipa de desenvolvimento será possível aos avaliadores tirar conclusões sobre a

qualidade do sistema para os usuários.

Em género de conclusão, os autores afirmam que elaborar um plano de testes consistente é

o primeiro passo para assegurar a qualidade dos resultados finais. A consistência destes tem

forte impacto nas conclusões obtidas. Esta qualidade ajuda à tomada de decisão, que tem


26

como objectivo único, a de melhorar o produto final e garantir que ele cumpra seus

objectivos.

Outro autor, Kaufman (2006), partilha da mesma opinião que os anteriores autores. Existem

muitos benefícios num teste de usabilidade, contribuindo estes para um produto final de

melhor qualidade e uma melhor compreensão dos usuários para os quais estamos a

projectar o sistema. Neste artigo o autor pretende transmitir quer ao fornecedor de produto

(equipa de desenvolvimento), quer à organização (cliente), algumas best practices para

testes de usabilidade.

Para este autor (Kaufman 2006) cada teste é um teste, e todos eles diferem no âmbito que

pretendem atingir. Testar uma nova funcionalidade no sistema é diferente que testar um

conjunto de funcionalidades baseadas num cenário de teste.

Independente do âmbito, existem pontos que a equipa terá que considerar:

Testar com um número razoável de participantes. No mínimo 5, no máximo 20

participantes. Os participantes podem pertencer à organização cliente, ou ser

contratados. Em qualquer dos casos, todos estes esperam algum incentivo para

participar no estudo.

Saber o tempo que vai demorar. Estabelecer um tempo definido para recolher,

analisar e apresentar os resultados. Este normalmente pode ir desde as duas

semanas, até às seis semanas. Uma sessão para um teste de usabilidade deverá durar

de uma hora a uma hora e meia.

Localização do teste. O local para teste pode ser tão simples como uma sala de

reuniões, como tão complexo como uma sala própria e preparada para testes de

usabilidade.

Para kaufman (2006), todos os testes deverão ser moderados tomando as seguintes

premissas:

Manter os participantes focados na tarefa. Durante o tempo de teste todo o usuário

tende a distrair-se. É preciso incentivá-lo e mantê-lo concentrado;

Tomar notas. Focar-se principalmente nos comportamentos do usuário;

Deixar o usuário cometer erros. Poderá revelar aspectos do interface que precisam

de ser melhorados;

Responder a questões com questões. Assim poderemos forçar o usuário a dar mais

feedback;

Não ensinar o usuário a resolver uma tarefa. Assim poderá sugerir e discutir

soluções que poderão resolver alguma questão de usabilidade;


27

Não explicar o interface. O usuário deverá procurar entendê-lo, ou caso contrário

comunicá-lo ao avaliador.

Todos os resultados obtidos deverão ser agrupados por observações semelhantes,

procurando assim tendências de comportamento. Organizar estes por gravidade de

problema de usabilidade e apresentar as conclusões à equipa de projecto.


28

3. Engenharia de software

3.1. Introdução

Muitas áreas de negócio possuem requisitos específicos no seu negócio para os quais os

pacotes disponíveis no mercado não dão respostas. Nestes casos recorre-se tipicamente ao

desenvolvimento de software à medida.

O desenvolvimento de software em grande escala obriga a adopção de um processo de

engenharia de software que defina uma abordagem sistemática para a gestão concepção

das várias valências envolvidas na produção e manutenção do software.

Como assegurar a produção de software com elevada qualidade, que responda aos

requisitos do usuário final, dentro dos prazos previstos no projecto e utilizando os recursos

dimensionados?

Aqui entra a disciplina de Engenharia de Software, uma tecnologia em camadas:

Fig. 8 – Engenharia de Software, uma tecnologia em camadas

Foco na qualidade. Toda a engenharia deve-se comprometer na procura da

qualidade;

Processos. É a base da engenharia de software. Constitui o elo de ligação entre as

ferramentas e métodos;

Métodos. Fornecem a definição de “como fazer” o desenvolvimento de software;

Ferramentas. Proporcionam apoio automatizado ou semi-automatizado para os

processos e métodos.

Estes elementos possibilitam um processo de desenvolvimento claro, eficiente, visando

garantir ao developer e seus clientes, a produção de um software de qualidade.


29

Para resolver problemas reais deveremos portanto aplicar uma estratégia de

desenvolvimento que contemple as camadas de processos, métodos e ferramentas. Esta

estratégia é o modelo de processo ou paradigma da engenharia de software.

3.2. Definição

Um processo de desenvolvimento de software é um conjunto de actividades, parcialmente

ordenadas, com a finalidade de obter um produto de software. O processo de

desenvolvimento de software pode, numa visão genérica, ser estruturado em três fases

distintas que correspondem ao seu ciclo de vida:

Fase de definição, ou concepção inicial do produto;

Fase de desenvolvimento, englobando a fase de validação;

Fase de manutenção, que decorre desde a entrega ao cliente até ao envelhecimento

do produto, englobando o processo de evolução do software.

Estas três fases existem em qualquer projecto, independentemente da sua área de

aplicação, dimensão ou complexidade.

O processo de desenvolvimento é uma actividade arriscada, sendo os maiores riscos:

Gastos que superam o orçamento;

Cronograma superado no tempo;

Funcionalidade deficiente face aos problemas do usuário;

Qualidade medíocre do sistema.

A qualidade de um software é dependente de:

Eficácia. Faz aquilo a que se destina, nem mais e nem menos;

Desempenho. Executa com uma eficiência aceitável;

Disponibilidade. Inicia a operação a quando necessário;

Confiabilidade. Probabilidade do software concluir com êxito uma tarefa, uma vez

que a tenha iniciado;

Segurança. Uma falha de software não cause perdas de informação ou danos físicos.

Várias técnicas têm sido dissecadas com o intuito de reduzir os riscos dos projectos e tornar

a sua actividade mais produtiva. Um marco neste sentido foi a criação da disciplina de

Engenharia de Software em 1968, durante uma conferência da NATO (Galler 1969). Esta


30

surgiu com o objectivo de atender às necessidades desta organização no desenvolvimento

de sistemas de defesa.

A engenharia de software deu origem a vários processos de modelação do desenvolvimento,

sendo o mais conhecido e antigo o processo linear e sequencial de desenvolvimento.

É um dos objectivos deste trabalho descrever os principais métodos, ferramentas e

procedimentos, destacando as suas características, vantagens e desvantagens, numa

tentativa de oferecer uma visão geral sobre estes com vista à melhoria do processo e do

produto, com benefícios directos para a organização.

Um processo de modelação de desenvolvimento de software é escolhido baseado na

natureza do projecto e aplicação nos métodos e ferramentas a serem utilizados e nos

controles e entregas requeridas. Os modelos definem ordem para uma actividade

inerentemente caótica.

3.3. Processos de desenvolvimento de software

3.3.1. Modelo sequencial linear (ou em cascata)


A primeira descrição do modelo foi proposto por Royce (1970), como um conceito inicial, um

modelo que argumentava ainda ser um risco e um convite para falhas.

O modelo sugere uma abordagem sistemática e sequencial para o desenvolvimento de

software, que começa com a especificação dos requisitos pelo cliente, progride com a

análise, desenho, codificação e testes, acabando na manutenção do software finalizado.


31

Fig. 9 – Etapas de implementação no desenvolvimento de software (Royce 1970)

Este deveria ser expandido para um modelo iterativo, onde o feedback de cada fase

influenciava a seguinte. Porém o modelo não se tornou iterativo mas sequencial conforme a

sua primeira versão.

Segundo o modelo original de Royce (1970), as fases têm a seguinte ordem:

1. Requisitos de sistema e software. O software está sempre incluído num sistema,

(hardware, bases de dados e pessoas, todos interagindo). Como tal o apuramento de

requisitos para todos os elementos do sistema é requerido, com vista à correcta

ligação ao software;

2. Análise. Levantamento rigoroso de requisitos, focado essencialmente no software. È

definido o âmbito da informação, funcionalidade, comportamento, performance e

interface;

3. Desenho. Apresenta os requisitos a nível técnico;

4. Codificação. Tradução do projecto numa linguagem de programação. A sua

qualidade, robustez e performance é fruto de um desenho detalhado;

5. Testes. Ambiente de testes do programa codificado. Pode ser realizado a nível

interno ou focado nas funcionalidades externas;

6. Manutenção. Corrige e adapta o software gerado.

O modelo pressupõe que o desenvolvimento segue linearmente da análise até a codificação

e teste. Os resultados de cada fase não podem ser alterados posteriormente e o produto só

existe no fim.


32


É sempre preferível a uma abordagem casual de desenvolvimento de software;

Estabelece padrões para a análise, desenho, codificação, testes e manutenção;

Etapas semelhantes às etapas genéricas aplicáveis a todos os processos de

desenvolvimento de software.

Dificuldade na estimação de custos;

A análise de requisitos só é efectivamente validada após a entrega do produto;

Os usuários não sabem antecipadamente todos os requisitos da aplicação;

Metodologia não antecipa as modificações ao software;

Um projecto dificilmente segue a ordem sequencial proposta e mudanças poderão

provocar o caos.

Tab. 5 – Vantagens/Desvantagens do Modelo sequencial linear (ou em cascata)

3.3.2. Modelo em espiral


Este modelo foi definido por Boehm (1988) como forma de integrar os diversos modelos

existentes eliminando os seus pontos fracos e explorando os seus pontos fortes, adaptando-

os a necessidades específicas de developers ou às particularidades do software a ser

desenvolvido. Este modelo prevê prototipagem, desenvolvimento evolutivo e cíclico e as

principais actividades do modelo de cascata, mas contudo acrescenta um novo elemento – a

análise de riscos. De facto Boehm (1988) não foi o primeiro a discutir o desenvolvimento

iterativo e incremental (Royce 1970), mas foi o primeiro a explicar o porque do modo

iterativo.

Este modelo assume que o processo de desenvolvimento ocorre em ciclos, cada um

contendo fases de avaliação e desenvolvimento, onde a opção de abordagem para o ciclo

seguinte é determinada.


33

Fig. 10 – Modelo em espiral (Boehm 1988)

O modelo original em espiral descreve-se num fluxo de actividades cíclico e evolutivo

constituído por quatro etapas:

1. Determinar objectivos. Devem ser determinados objectivos, soluções, alternativas e

restrições;

2. Identificar e resolver riscos. Devem ser analisados os riscos das decisões da etapa

anterior. Durante esta podem ser construídos protótipos ou realizar-se simulações de

software;

3. Desenvolvimento e teste. Consiste nas actividades da fase de desenvolvimento,

incluindo desenho, especificação, codificação e testes;

4. Planear a próxima iteração. Compreende a revisão das etapas anteriores e o

planeamento da próxima fase. Neste planeamento, dependendo dos resultados

obtidos nas etapas anteriores, pode-se optar por seguir outro processo de

desenvolvimento de software. Por exemplo, se na primeira etapa, os requisitos

foram completamente especificados e validados, pode-se optar por seguir o modelo

em cascata. Caso contrário, pode-se optar pela construção de novos protótipos,

avaliando novos riscos e replaneando o processo.


34

Fig. 11 – Modelo em espiral simplificado

O modelo em espiral surge hoje como a abordagem mais realista do desenvolvimento de

software, tendo surgido ao longo do tempo variações a este, considerando entre três a seis

etapas ou sectores da espiral.


Permitir que ao longo de cada ciclo se obtenha versões do sistema mais complexas,

recorrendo à prototipagem para reduzir riscos;

Estimativas tornam-se realistas com o progresso do trabalho, porque problemas e

evoluções importantes são descobertos mais cedo;

Lidar melhor com a mudança.

A dificuldade em tornar esta abordagem evolutiva controlável;

O protótipo pode não cumprir os requisitos de desempenho do sistema final por

estar incompleto, e pode reflectir somente algumas características do sistema;

O protótipo poderá tornar-se no produto final, não tendo a devida preparação para

o ser;

O modelo poderá levar a vários desenvolvimentos em paralelo, sendo preciso fazer

uma correcta gestão e sincronização destes.

Tab. 6 – Vantagens/Desvantagens do Modelo em espiral


35

3.3.3. Modelo de prototipagem evolucionária


Ao contrário de outros modelos pretende-se, não desenvolver em primeira análise uma

versão do produto final, mas sim construir uma série de versões provisórias que são

chamadas protótipos.

O protótipo é um modelo operacional do software a ser desenvolvido (Budde and

Zullighoven 1990).

A prototipagem evolutiva é aquela em que uma primeira versão do software é desenvolvida

a partir de uma versão inicial do documento de especificação de requisitos, visando abordar

a questão de interface com o usuário, para validar requisitos ou apresentar a viabilidade do

sistema. Incrementos de funcionalidade são incorporados ao protótipo de modo a serem

cumpridos todos os requisitos definidos no projecto. No final os requisitos iniciais são

alterados de forma a produzir a especificação final dos requisitos.

É de notar que o protótipo serve apenas como um mecanismo para a identificação dos

requisitos do software. Com o fim da prototipagem, temos o sistema todo delineado e já

especificado. A partir desse momento, o protótipo deve ser usado apenas como documento

base para o que deve ser desenvolvido. O desenvolvimento de software, atendendo a

factores como a qualidade, análise de risco e manutenção, começa aqui.

Fig. 12 – Modelo de prototipagem evolucionária


36

Protótipos evolutivos proporcionam a aproximação do sistema com as necessidades dos

usuários, bem como alta qualidade do projecto, facilidade de uso, boa manutenção e

reduzido esforço no desenvolvimento (Gordon and Bieman 1995).

No entanto, como o modelo em espiral, este modelo também requer acompanhamento

muito criterioso e bem feito. Além disso, é necessário que o desenho seja de excelente

qualidade para que a estrutura do produto não se degenere ao longo dos protótipos.


Melhora a qualidade da especificação do software a ser desenvolvido, contribuindo

para uma queda nos custos de desenvolvimento e manutenção;

É de grande utilidade quando os requisitos mudam rapidamente e o cliente está

relutante em aceitar um conjunto de requisitos;

Antecipa a formação dos usuários;

Partes do protótipo podem ser aproveitadas no desenvolvimento do sistema.

O custo na maioria dos casos é considerado muito alto;

O cliente tende a confundir o protótipo com uma versão do sistema;

É impossível determinar com exactidão o tempo de projecto;

Não há forma de saber o número de iterações que serão necessárias atingir até ao

produto final.

Tab. 7 – Vantagens/Desvantagens do Modelo de prototipagem evolucionária

3.3.4. Modelo ágil


Agile software development ou Método ágil é um conjunto de metodologias de

desenvolvimento de software. Este tipo de desenvolvimento à semelhança de outras

metodologias já descritas providencia uma estrutural conceitual para reger projectos de

engenharia de software.


37

As definições modernas de desenvolvimento de software ágil evoluíram a partir da metade

de 1990 como parte de uma reacção contra modelos de desenvolvimento caracterizados por

serem lentos, burocráticos e contraditórios à forma como os engenheiros de software

sempre realizaram o seu trabalho. Um dos exemplos é o modelo em cascata. Uma visão que

levou ao desenvolvimento de métodos ágeis e iterativos era o querer regressar às práticas

de desenvolvimento inicias na história do desenvolvimento de software.

O termo “Método ágil” tornou-se popular em 2001 quando dezassete especialistas em

processos de desenvolvimento de software reuniram-se em Snowbird UT, representando os

métodos Scrum (Ken 2002), Extreme Programming (XP) (Beck 1998) e outros, com o

objectivo de estabelecer princípios comuns compartilhados por todos esses métodos. Foi

então criada a Agile Alliance e o estabelecimento do Manifesto Ágil.

Os valores do manifesto ágil:

Indivíduos e interacções são mais importantes que processos de ferramentas;

Software funcionando é mais importante do que documentação completa e

detalhada;

Colaboração com o cliente é mais importante do que negociação de contratos;

Adaptação a mudanças é mais importante do que seguir o plano inicial.

Não se trata de um desprezo aos elementos e ferramentas tradicionais de desenvolvimento

de software, mas sim do estabelecimento de uma escalada de valores, na qual a flexibilidade

e a colaboração são mais relevantes do que a rigidez de processos e planeamento clássicos.

Os princípios por trás do manifesto ágil:

Satisfazer o cliente através de entregas rápidas e contínuas de software que agrega

valor;

Receber bem mudanças de requisitos, mesmo numa fase avançada do

desenvolvimento. Processos ágeis gerem a mudança para a vantagem competitiva do

cliente;

Entregar software funcional frequentemente, com um intervalo de semanas ou

meses, com preferência para intervalos mais curtos;

Pessoas ligadas ao negócio e developers devem trabalhar diariamente juntos pelo

projecto;

Construir projectos com pessoas motivadas. Proporcionar o ambiente e suporte que

precisam e dar-lhes confiança para ter o trabalho executado;

Privilegiar a conversa cara-a-cara, com vista à maior eficiência e efectividade no

transporte de informação para dentro e para fora da equipa de desenvolvimento;

Software funcional é a principal medida de progresso;


38

Processos ágeis promovem desenvolvimento sustentável. Os patrocinadores,

developers e usuários devem ser capazes de manter um ritmo constante

indefinidamente;

Atenção contínua à excelência técnica e bom design melhora a agilidade;

Simplicidade – a arte de maximizar a quantidade de trabalho não realizado – é

essencial;

As melhores arquitecturas, requisitos, e designs emergem de equipas auto-

organizadas;

Em intervalos regulares, as equipas reflectem sobre como se tornar mais efectivos,

então ajustam o seu comportamento de acordo.

Algumas metodologias ágeis:

Scrum

Metodologia ágil para gerir projectos geralmente de software, podendo contudo ser usada

para o desenvolvimento de produtos físicos. O nome foi inspirado numa jogada de Rugby.

Após o agrupamento em torno da bola, oito jogadores por equipa reiniciam o jogo.

O Scrum foi inicialmente concebido como uma Framework para gerir projectos em fábricas

de automóveis e produtos de consumo, por Takeuchi e Nonaka (1986). Eles notaram que

equipas pequenas e multidisciplinares produziram os melhores resultados em projectos

tendo associado estas equipas altamente eficazes à formação do Rugby.

O Scrum é baseado em ciclos de duas a quatro semanas, chamados de sprints. Cada sprint

tem como objectivo entregar um incremento de software finalizado.

O backlog de produto contém a lista de tudo o que é objectivo entregar. Quem define essa

lista é o Product Owner que prioritiza os itens.

A equipa define uma lista de itens que cabem dentro de cada sprint a que damos o nome de

Sprint Backlog. Ocorre diariamente uma reunião de no máximo quinze minutos onde equipa

se alinha em relação ao desenvolvimento dos itens no Sprint Backlog. É prática cada equipa

ser constituída por 5 a 9 elementos multifuncionais.

No fim de cada sprint ocorre uma reunião, Sprint Review, onde tudo o que foi desenvolvido

no sprint é apresentado ao cliente. É este que face ao desenvolvido, indica se o sprint

atingiu o objectivo proposto.

O processo é repetido a cada ciclo de desenvolvimento.

Existe ainda o papel do Scrum Master, que verifica se a equipa está respeitando os valores e

práticos do Scrum. É de notar que o Scrum Master ao contrário do Product Owner, não é o


39

responsável de projecto, é sim a pessoa que foca a equipa na meta de cada sprint, sendo

igualmente responsável na coordenação da reunião diária da equipa.

Fig. 13 – Metodologia ágil – Scrum

Extreme Programming (XP)

Metodologia ágil para gerir projectos de software, onde equipas pequenas e médias

desenvolvem com base em requisitos vagos e em constante mudança. Como resposta

adoptam uma estratégia de constante refactor de código, onde o sistema começa a ser

implementado logo no início do projecto e vai ganhando novas funcionalidades ao longo do

tempo.

A entrega rápida de software é uma das principais características do XP. Existe um

envolvimento do usuário, tornando-se este, um elemento activo da equipa de

desenvolvimento.

No XP não existe o processo de design tradicional com a elaboração de requisitos e

arquitectura de sistema. Este é substituído por metáforas que circulam à volta de histórias

do usuário. A metáfora pretende contextualizar uma situação do mundo real do usuário a

aplicar no sistema a desenvolver.

As histórias do usuário são a base para a criação de estimativas de tempo que serão usadas

nas reuniões de planeamento de entregas. Cada história deve levar entre duas a três

semanas a ser implementada e deve-se traduzir numa iteração individual de

desenvolvimento, sendo a história utilizada como base de elaboração dos testes de

aceitação. O sistema deverá reproduzir fielmente a história do usuário.


40

Os quatro valores fundamentais do XP:

Feedback. O usuário aprende com o sistema que utiliza e reavalia as suas

necessidades, gerando feedback para a equipa de desenvolvimento;

Comunicação. A boa comunicação entre o usuário e a equipa permite que todo o

projecto seja tratado com atenção e agilidade.

Simplicidade. Desenvolver apenas o que é de valor para o usuário atendendo à sua

necessidade, nada menos e nada mais;

Coragem. A equipa precisa de acreditar que poderá levar o projecto a bom porto,

atendendo às práticas e valores do XP.

O XP baseia-se nas seguintes práticas:

Cliente presente. O XP parte do princípio que o usuário conduz o desenvolvimento a

partir do feedback que recebe do sistema. Como tal a sua presença como membro

activo da equipa de desenvolvimento é requerida;

Jogo de planeamento. Todo o projecto é dividido em releases e iterações, de modo a

que o usuário e equipa se reúnam e revejam o planeamento;

Stand Up Meeting. A equipa de desenvolvimento reúne-se a cada manhã de forma a

avaliar o trabalho feito no dia anterior e a prioritizar o do dia corrente. A reunião é

rápida e feito em pé;

Programação em par. Os developers trabalham aos pares diante de cada

computador, produzindo o mesmo código. Esta solução permite que o código seja

permanentemente revisto enquanto é construído. Novas soluções inovadoras

poderão igualmente sair desta parceria;

Desenvolvimento guiado pelos testes. Antes da codificação, os developers

associados a cada iteração escrevem os testes que a validam. Assim aprofundam o

entendimento das necessidades do usuário;

Refactoring. Acto de alterar o código sem afectar a funcionalidade que ele

implementa. Para tal o código deverá expressar a sua funcionalidade de uma forma

simples e de fácil compreensão;

Código colectivo. Uma parte do código não é prioridade do developer que o

desenvolveu, pertence ao colectivo. Como tal qualquer membro da equipa poderá

alterar algo que achar importante sem pedir autorização;

Código padronizado. Padrões na codificação são partilhados e usados por toda a

equipa, de forma à simplificação e fácil compreensão do código gerado.


41

Design simples. A simplicidade do design de forma a obter um rápido feedback do

usuário. Codificação simples de modo a somente atender à necessidade da

funcionalidade que está a implementar;

Metáfora. Criação de metáforas para atender às necessidades do cliente, visto estas

terem o poder de transformar ideias complexas em formas simples;

Ritmo sustentável. O XP recomenda que a equipa trabalhe apenas oito horas por

dias evitando horas extraordinárias. O tempo de descanso é crucial;

Integração contínua. Cada par integra o seu código com o geral, várias vezes ao dia.

Esta integração permite testar se o sistema como um todo contínua a funcionar bem;

Releases curtos. O XP tem como objectivo gerar um fluxo contínuo de valor para o

usuário. Releases curtos são produzidos mais rapidamente, de forma a obter o mais

rápido feedback do usuário.

Fig. 14 – Metodologia ágil – Práticas XP

Quer o Scrum (Ken 2002), quer o Extreme Programming (XP) (Beck 1998), partilham a

premissa de que o usuário aprende sobre as suas necessidades, acedendo e utilizando o

sistema que está sendo produzido. Com base no feedback do sistema, o usuário reavalia os

seus requisitos, gerando mudanças a ser introduzidas no sistema. Pretende-se assim que o

usuário mostre o caminho, pois ele, mais do ninguém sabe o que tem valor para o seu

negócio.



42

É dada prioridade às funcionalidades que agregam valor, promovendo a satisfação

do cliente;

Velocidade no desenvolvimento;

Maior motivação das equipas;

Prioridades podem ser alteradas;

Diminuição de bugs.

Falta de estrutura e documentação necessárias;

Requer developers experientes;

Devido à mudança de cultura, implica uma dificuldade de negociação contratual;

Sensação de informalidade.

Tab. 8 – Vantagens/Desvantagens do Modelo ágil

3.4. Comparação

O modelo sequencial linear (ou em cascata) é o mais antigo e conhecido modelo de

desenvolvimento de software. A característica mais distinta deste é o processo passo a passo

sequencial da análise de requisitos até à manutenção.

Contudo a maior fraqueza deste prende-se com o depois dos requisitos de projecto estarem

definidos numa primeira fase, não haver nenhuma maneira formal para fazer alterações a

estes, caso os requisitos mudem ou informação adicional ser fornecida à equipa de projecto.

Como a mudança de requisitos é algo comum durante longos ciclos de desenvolvimento, o

produto final ao entrar em produção, poderá já ser obsoleto. Logo este modelo de

desenvolvimento mostra-se uma má escolha para projectos onde os requisitos não são bem

conhecidos ou compreendidos pela equipa de desenvolvimento. Poderemos igualmente

extrapolar que não seja um bom modelo para projectos complexos ou projectos que se

espera ter um período de desenvolvimento de largos meses.

Quais são então bons candidatos para um modelo de desenvolvimento em cascata?

Sistemas que têm bem definidos e compreendidos os requisitos de projecto, de curta

duração ou longa duração.

Em resposta às deficiências e falhas do modelo sequencial linear, muitos modelos foram

desenvolvidos, sempre com o intuito de acrescentar alguma iteração ao processo de

desenvolvimento de software.


43

No modelo em espiral a equipa de desenvolvimento começa com um pequeno conjunto de

requisitos e passa por cada fase de desenvolvimento (à excepção da instalação e

manutenção), atendendo aos requisitos da iteração inicial. Com base na anterior iteração,

através de um processo de análise de risco, a equipa adiciona requisitos iniciando uma nova

iteração (espiral) até que o projecto esteja pronto para a fase de instalação e manutenção,

ou seja, em produção. Cada uma das iterações anteriores à versão de produção considera-se

como sendo um protótipo.

A vantagem deste modelo em relação ao anterior é que a abordagem iterativa permite

iniciar o projecto mesmo não sendo claros os requisitos de sistema para a equipa de

projecto. Como cada protótipo é testado, o feedback do usuário é usado para garantir que o

projecto esta no trilho certo. Hoje no meio empresarial, o modelo em espiral é o modelo de

desenvolvimento mais usado.

Quais são então bons candidatos para um modelo de desenvolvimento em espiral?

Sistemas que ainda não têm bem definidos e compreendidos os requisitos de projecto, e que

se prevêem de longa duração, ou se de pouca, com deliverables curtos.

Na demanda por menores tempos no desenvolvimento de software e melhor e maior

iteração com o usuário, surge o modelo de prototipagem evolucionária, tendo sido este

apresentando como a melhor forma de adicionar funcionalidade a uma aplicação. Após uma

rápida colecta de requisitos, um protótipo é construído e apresentado ao usuário. O

feedback deste fornece um novo loop para melhorar ou adicionar funcionalidade à

aplicação.

A vantagem ou desvantagem deste modelo prende-se com o tempo de colocação no

mercado poder ser bastante reduzido ou bastante longo. Poderá ser reduzido pois ignora

algumas das etapas de modelos tradicionais, em favor do rápido desenvolvimento de

software. Por outro lado pode ser estendido se entrarmos num ciclo de muitas iterações

com o usuário, ou se simplesmente, a falta de uma fase de testes real, provocar a falha do

produto.

Quais são então bons candidatos para um modelo de prototipagem evolucionária?

Sistemas que ainda não têm bem definido e compreendido os requisitos de projecto, que se

prevêem de curta duração e de orçamento baixo, onde preferencialmente a equipa de

desenvolvimento ou o seu gestor pertença à organização, tendo já algum backlog sobre o

tipo de usuários e negócio.

Numa contraposição total face ao modelo em cascata surgiu o modelo ágil de

desenvolvimento de software. Este consiste numa série de ciclos ou iterações curtas –

poucas semanas – de desenvolvimento com um grau de colaboração entre os envolvidos


44

bastante alta. Cada um destes ciclos representa mini-projectos dentro do todo, com todas as

fases típicas de projecto, apresentando no final de cada ciclo uma nova funcionalidade.

A vantagem deste modelo está na velocidade com que se produz software, na motivação

que produz na equipa de desenvolvimento ao gerar num curto espaço de tempo algo de

palpável, na focalização específica às funcionalidades que agregam valor para o cliente.

Como desvantagens este modelo requer uma equipa ou gestor experiente, de forma a ir

dando ao cliente uma perspectiva do prazo de fim de projecto face a novos pedidos, assim

como os custos associados que irão ser conhecidos só ao longo deste, prevendo-se contudo

que sejam baixos.

Quais são então bons candidatos para um modelo ágil de desenvolvimento? Sistemas onde

os requisitos vão emergindo e mudando rapidamente, podendo ser de curta ou média

duração. Poucas pessoas, mas competentes e com experiência de forma a promover e

optimizar a comunicação

Todos os modelos descritos, tal como outros existentes, devem ser encarados como sendo

estratégias para o desenvolvimento de software de qualidade. Cada uma destas fornece à

equipa de desenvolvimento, as ferramentas correctas para criar um software que atende a

uma necessidade de negócio. O conhecimento das necessidades é condição fundamental

para a escolha do modelo.

A escolha do modelo deve levar em conta factores como:

Cultura da empresa;

Nível de maturidade dos processos;

Natureza da aplicação;

Orçamento;

Experiência e competência da equipa;

Prazos de entrega.

3.5. Casos de estudo na literatura

Consideramos como métodos tradicionais, o modelo sequencial linear (ou em cascata), o

modelo em espiral e o modelo de prototipagem evolucionária. Como métodos ágeis, temos

o modelo Scrum e o modelo Extreme Programming (XP).


45

O processo de desenvolvimento de software tem uma grande dependência da performance

das pessoas que constituem a equipa, tal como qualquer actividade que envolva interacção

humana (Moe, Dingsoyr et al. 2010).

Moe e Dingsoyr (2010) afirmam que na metodologia tradicional, o trabalho é coordenado

por uma hierarquia que envolve um comando e estilo de gestão, no qual há uma separação

clara de papéis. Numa metodologia ágil, o trabalho é coordenado como por auto-gestão da

própria equipa, decidindo esta o seu estilo de gestão. Para estes autores o grande desafio de

uma abordagem ágil está na transição da equipa para este tipo de abordagem invertendo

completamente o seu papel. Não é razoável pensar que uma equipa habituada a ser

coordenada, de repente seja posta em auto-gestão e que tenha a capacidade para se auto-

coordenar e trabalhar eficazmente como equipa ágil.

Foi objectivo destes autores desenvolver um estudo longitudinal, envolvendo várias equipas

a trabalhar já agilmente ou a começar a transição, procurando entender a natureza da

relação entre pessoas (na equipa ou com a organização) neste novo meio de auto-gestão.

Procurou-se assim recolher informações para a compreensão de como introduzir uma

abordagem ágil numa organização, habituada a uma abordagem tradicional.

O estudo teve a duração de nove meses e afirma que para a adopção deste tipo de

abordagem ágil numa organização com sucesso, vários requisitos têm que ser cumpridos.

Uma equipa altamente especializada, possuindo uma divisão de trabalho própria, é factor

importante para a entrega eficaz. A transição do trabalho individual hierarquizado, para um

trabalho de equipa de auto-gestão, requer uma reorientação tanto do developer, quer da

própria organização que terá que apoiar incondicionalmente esta nova abordagem.

Sumrell (2007) descreve a experiência da sua empresa de desenvolvimento de software, a

quando esta reorientação. Uma organização que sentiu a necessidade de se distanciar de

modelos sequenciais lineares com seis meses de duração, e aproximar-se de práticas mais

ágeis, como forma de subsistência num mercado tão mutável como é o de desenvolvimento

de software.

Depois de pesquisar sobre várias metodologias de desenvolvimento, depois de assistir a

várias formações, uma das equipas tester de desenvolvimento aderiu ao modelo ágil Scrum,

que parecia ser o mais ajustado à organização. O conhecimento foi sendo adquirido por

elementos da equipa, que nos tempos livres, informavam e treinavam outros elementos.

Para Megan Sumrell (2007) a transição para uma abordagem ágil não foi simples. Existiram

várias pequenas coisas que poderiam ter sido feitas, de forma a garantir uma mais fácil e

menos frustrante transição. Deste modo a autora enumera algumas lições aprendidas

durante a transição:


46

1. Obter ajuda de especialistas já com alguma experiência cedo. Não podemos pensar

que a equipa tendo enraizado um modelo de processo, consegue passar para outro

rapidamente e com eficácia. Pressupor que a organização pela sua natureza, não se

vai conseguir adaptar a uma nova abordagem só por o caminho à frente parecer

impossível é errado. Um consultor de fora com experiência poderá ser o mais

indicado para ajudar;

2. Uma mudança de abordagem pressupõe uma reorientação de toda a equipa. Desde

cedo garantir e comunicar à equipa que os papéis e responsabilidades de cada um

serão diferentes;

3. Cada membro da equipa desempenha um papel importante na qualidade do

software desenvolvido, mesmo antes dos testers de produto entrarem em cena. Os

testes de produto começam desde o primeiro dia, numa etapa final em cada

iteração. Exige-se entregas com qualidade neste tipo de abordagem. Recomenda-se a

utilização de algum tipo de software que efectue testes leves automatizados;

4. Não esperar que a transição seja fácil e que ocorra do dia para a noite. Ir devagar

partilhando com a equipa todos os progressos ao longo do processo, é o mais

sensato.

Outro factor importante no processo de desenvolvimento de software é o tempo de

desenvolvimento do produto. A necessidade de uma organização, cada vez mais deixou de

ser algo que é planeado com tempo, passando a ser algo que é preciso para o momento,

sobe pena de se tornar obsoleto. Hoje os contratos são dados em função do tempo de

desenvolvimento, deixando o factor custo para um segundo plano. Como tal o processo de

desenvolvimento deve ser adaptado à necessidade da organização cliente.

Podemos afirmar que o modelo ágil nada possui de novo em relação aos métodos

tradicionais de desenvolvimento de software (Highsmith and Cockburn 2001). No limite

poderemos dizer que cada iteração existente no modelo ágil pode ser entendida como mini-

cascastas (modelo sequencial e linear). As pessoas e o tempo para implementação são o

enfoque principal deste modelo, ao contrário dos outros métodos tradicionais, onde os

processos e documentação sobre estes prevalecem.

Um modelo tradicional é um modelo preditivo, ao contrário de um modelo ágil que é

adaptativo. Um modelo adaptativo procura adaptar-se a factores decorrentes durante a fase

de implementação, ao invés de procurar analisar previamente tudo o que pode acontecer

durante a implementação. Esta análise prévia poderá constituir um maior custo e tempo de

desenvolvimento à organização, pois qualquer alteração ao projecto provoca uma alteração

ao planeamento de entregas e recursos previamente estabelecido. Noutra perspectiva

poderá ser o garante de que o projecto não se prolonga no tempo, cumprindo os prazos

acordados.


47

A possibilidade de um modelo aceitar bem a mudança devia ser logo o factor de escolha

para qualquer equipa de desenvolvimento, visto esta ser algo que vai sempre acontecer em

qualquer projecto. O problema está no como receber, avaliar e responder à mudança. No

limite podemos entrar num loop de iterações com o cliente, o que vai atrasar os prazos

acordados e aumentar os custos de projecto.

De uma maneira geral, um modelo tradicional deve ser aplicado a situações onde os

requisitos de software são conhecidos, são estáveis e onde o futuro se prevê controlável.

Normalmente esta situação é difícil de atingir, visto a dinâmica da organização não o

permitir. Pressman (2001) estima que caso alguma alteração tenha como custo “1x” quando

feita na fase de requisitos, ela terá um custo de “60x a 100x” quando feita na fase de

implementação. Como tal o autor afirma que alterações a modelos tradicionais não são

desejáveis.

Fig. 15 – Custo da mudança num modelo tradicional (Pressman 2001)

Um artigo (Charette 2001) comparando métodos ágeis com métodos tradicionais mostra

que os primeiros obtiveram melhores resultados em termos de cumprimento de prazos, de

custos e padrões de qualidade. O artigo também menciona o facto o tamanho das equipas a

utilizar este tipo de metodologia tem crescido contrariando o número aconselhável pela

própria definição desta, ou seja, por equipas pequenas ou médias até 12 developers. Num

universo de mais de 200 empresas, cerca de 15% dos projectos estão sendo desenvolvidos

por equipas de 21 a 50 pessoas, e 10% são desenvolvidos por equipas com mais de 50

pessoas.


48

4. Síntese da investigação

O teste de usabilidade usa-se como método de verificação da facilidade de uso de um

sistema e sua interface, tendo como target os usuários finais. Durante esta verificação não

só erros de interface poderão surgir, mas também erros de sistema.

Tipicamente usuários representando os principais grupos de perfis, são incentivados a usar o

sistema, sendo a sua interacção com o este gravada e anotada. Com estes poderá estar o

avaliador/facilitador, que deverá guiar o usuário pelo teste e incentivar à verbalização dos

seus problemas e desconfortos.

A participação de pelo menos cinco usuários representando os principais grupos de perfis é

recomendada. Segundo Nielsen e Laundauer (1993), este número de usuários consegue

encontrar 85% dos erros de usabilidade, o que se traduz na melhor relação Custo-benefício.

Possivelmente se com este mesmo grupo de usuário efectuarmos outro teste, acreditamos

que se poderá atingir os 100% de erros encontrados.

A localização do teste depende sempre do rigor que queiramos que este tenha. Poderá ir do

mais simples, como uma sala de reuniões, até ao mais complexo, um laboratório de

usabilidade, onde é posto à disposição do avaliador/facilitador, ferramentas de hardware e

software com vista a captar com mais rigor comportamentos e frustrações do usuário.

O tempo de duração de um teste deverá ser moderado. Por um lado queremos que este seja

rigoroso, mas por outro não queremos cansar o usuário. Recomenda-se que este tenha a

duração de uma hora, uma hora e meia no máximo.

Após os testes, todos os dados recolhidos são analisados, agrupados conforme a gravidade e

é gerado um relatório contendo as correcções/recomendações para a equipa de projecto. O

avaliador/facilitador deverá estar sempre disponível, para com a equipa de projecto

encontrar soluções para os problemas encontrados.

O custo de um teste de usabilidade pode ser baixo ou alto, tudo depende do rigor que

queiramos adicionar ao processo. Contudo será sempre baixo se comparado ao custo da

alteração já numa fase de implementação do projecto.

Na Engenharia de Software, toda a investigação feita resume-se a para além de conhecer os

métodos e seus modelos, responder a três perguntas:

Como posso precaver o fracasso?


49

Ignorar o cliente e/ou usuário final, é um dos problemas mais críticos que a utilização de

uma metodologia pode apresentar. A falta de envolvimento de ambos durante todo o

desenvolvimento está a condenar o projecto ao fracasso.

A falta de suporte executivo da organização, tal como a pouca agilidade da equipa para

responder às mudanças, influenciam de forma negativa no projecto. Ambos requerem uma

boa gestão a nível da equipa de projecto e ambiente externo ao projecto.

Outra causa para o fracasso prende-se com a incapacidade para controlar e mediar conflitos

entre vários intervenientes, tais como, a equipa, o cliente, o usuário entre outros. Tais

conflitos poderão relacionadas com:

Objectivos contrários. Não existe uma visão comum entre o que o cliente deseja e o

que a equipa de projecto está a desenvolver;

Falha de comunicação. Existe pouca documentação do produto em construção,

originando mal-entendidos;

Expectativas irrealistas. Conforme os recursos e âmbito de projecto, o cliente pode

não estar ciente e compreender os prazos de projecto.

A falta de recursos humanos, de infra-estrutura ou financeiros, assim como estimativas

pouco reais de custos e de cronograma, também são apontados como factores que

provocam o fracasso de um projecto.

O que diferencia um método tradicional de um método ágil de desenvolvimento?

Nos métodos tradicionais um projecto é encarado como um todo e só faz sentido falar de

sucesso quando a totalidade deste é entregue ao cliente. Nos métodos ágeis um conjunto

mínimo de funcionalidades já atribui valor para o cliente, o que faz com que mesmo que o

projecto seja descontinuado, já houve retorno para o cliente. É verdade que o modelo de

prototipagem evolucionária, sendo um método tradicional, já permite a entrega de

protótipos durante a fase de desenvolvimento, podendo parecer que entramos numa

contradição, mas não. No método tradicional o desenvolvimento baseia-se num crescendo

das funcionalidades do produto até à sua entrega, enquanto na metodologia ágil, uma

funcionalidade é individualizada, sendo esta entregue ao cliente, podendo este obter um

retorno prévio da funcionalidade. Numa metodologia ágil o sucesso é algo progressivo,

enquanto na metodologia tradicional este acontece só no final.

Nos métodos ágeis o custo de projecto está associado em 100% ao trabalho realizado, ao

contrário dos métodos tradicionais que está associado em 100% aos requisitos especificados


50

e aprovados pelo cliente. Tal é deveras importante pois o cliente não tem nas metodologias

ágeis uma visão geral sobre o custo do projecto, ao contrário da metodologia tradicional.

Tais diferenças ajudam na resposta à segunda pergunta.

Quando devo escolher um método, em detrimento do outro?

Se o âmbito do projecto está bem fechado, os requisitos deste bem delineados e aprovados

pelo cliente, não existindo para este sucesso no projecto a não ser que o produto esteja

entregue a 100%, então adoptar uma metodologia ágil é complicar o que pode ser bastante

simples. É ignorar todos os guias de base já delineados, é ignorar a capacidade de se ter um

cronograma de projecto, é transmitir ao cliente desconhecimento.

Se o custo do projecto estiver associado a um âmbito já fechado de projecto, em oposição

ao custo associado ao trabalho efectuado, então ir para uma metodologia ágil poderá ser má

política. O montante a receber pelo cliente será sempre o mesmo, não recebendo mais por

entregarmos funcionalidades.

Nos métodos tradicionais o risco deve ser gerido pela equipa de desenvolvimento, ao

contrário dos métodos ágeis, que deve ser pelo cliente.


51

Capítulo III – Contexto empresarial

1. Estudo de viabilidade

1.1. Introdução

Antes de avançar com uma análise mais detalhada dos requisitos de um projecto, deve ser

feito um estudo de viabilidade Tal como o próprio nome sugere, pretende-se com este

estudo avaliar se, de um ponto de vista tecnológico e organizacional, o projecto é viável.

O sucesso de um projecto de desenvolvimento de software articula-se em cinco áreas

(Lester 1998):

Compromisso por parte da administração, sendo este uma condição chave para o

sucesso;

Estrutura de organização e processos que suporta o risco;

Novas ideias, novos conceitos, que estimulam a equipa para o desenvolvimento;

Equipa com recursos humanos e técnicos apropriados, capazes de comunicar

eficazmente entre si e com o cliente;

Gestão do projecto capaz de centrar-se sobre a diminuição de incertezas o mais

rápido possível.

Uma forma de avaliar a viabilidade de um projecto é obter, através da interacção com os

stakeholders do projecto (em reuniões ou entrevistas, por exemplo), a resposta às seguintes

perguntas:

Será que o sistema está enquadrado na estratégia da organização?

Dadas as restrições tecnológicas, organizacionais (económicas, políticas, ambientais,

recursos disponíveis) e temporais associadas ao projecto, será que o sistema pode

ser implementado?

Caso haja a necessidade de integração entre diferentes sistemas, será que esta é

possível?

Como pode a optimização do processo ser medida, de forma a termos o melhor

processo, mais intuitivo, mais simples, abrangente, sem saltarmos estados do

processo?

A questão mais crítica é a primeira, já que um sistema que não contribua para os objectivos

da organização não lhe traz qualquer valor acrescentado e como tal a sua existência não se

justifica. Apesar de parecer óbvio, são frequentemente desenvolvidos sistemas que não


52

contribuem para os objectivos das respectivas organizações quer seja por interesses

externos (políticos ou organizacionais), por falta de clareza na definição dos objectivos da

organização, por orçamento de projecto reduzido ou mesmo pela lenta resposta de

unidades de negócio e responsáveis, a problemas críticos, riscos ou actividades de projecto.

O estudo Standish (International 1995) define como insucesso um projecto que foi cancelado

ou que ultrapassou o seu orçamento, tempo de entrega e objectivos organizacionais. Pelo

contrário como projecto de sucesso, o que cumpriu o orçamento, tempo de entrega e

objectivos organizacionais.

É importante identificar que informação e/ou actores são necessários para responder às

questões levantadas anteriormente, procedendo-se de seguida à recolha de todos os dados

disponíveis para clarificar ao máximo o âmbito do projecto e avaliar a sua viabilidade.

Tipicamente, quem poderá fornecer esta informação são os usuários dos sistemas actuais e

do sistema a implementar, os responsáveis pelos departamentos nos quais o sistema será

usado, técnicos que estejam familiarizados com as tecnologias envolvidas (do novo sistema e

dos sistemas existentes), responsáveis pela manutenção futura do sistema a implementar e,

de um modo geral, todos aqueles que terão qualquer tipo de interacção com o novo sistema

(ou que sejam por ele afectados).

1.2. Documento de Estudo Apresentado

Designação do portal

“Gift.Certificates Portal”

O nome de portal foi escolhido atendendo a:

Representar o conceito principal do portal, cheques-prenda;

O inglês por ser a língua transversal a toda a Sonae Sierra, e a única utilizada em todo o portal;

A utilização do ponto entre a palavra Gift e Certificates, de modo a manter a uniformização com um outro portal, o SierraCentres.networks.

O endereço intraweb foi escolhido tomando em conta que o portal é interno à rede Sonae

Sierra, e em linha com o modelo de endereços aplicado pela organização, ou seja:


53

http://*.sonaesierra.com, tendo ficado, http://giftcertificates.sonaesierra.com

Logotipo

O logotipo do portal foi escolhido atendendo a:

Apoiar o nome do portal;

Uniformização de cores, tamanho e formatação em relação a outros portais;

No portal SierraCentres.networks o logotipo usado é o seguinte:

Em comparação o novo portal Gift.Certificates terá as seguintes modificações:

A palavra SierraCentres.networks passará para Gift.Certificates;

A imagem de fundo de um centro comercial irá ser alterada, mantendo contudo os tons de azul, para uniformização e manutenção das cores corporate.

Descrição

Sobre o domínio do conceito de inovação, procurando transmitir valor e apoio ao negócio do

seu lojista, a Sonae Sierra criou o serviço de Cheque-Prenda. Como o próprio nome indica é

um cheque que pode ser utilizado num determinado grupo de lojas aderentes ao programa

em qualquer centro Sonae Sierra garantindo uma ampla liberdade de escolha a quem o

recebe. Os valores disponíveis cifram-se nos 50€, 25€, 10€ e 5€ nos centros europeus e R$75

e R$50 nos centros do Brasil.

O serviço aponta para dois targets:

O consumidor comum que compra para oferecer;

Empresas que desejam valorizar o seu relacionamento com colaboradores, clientes e

fornecedores, comprando e oferecendo a estes.

http://*.sonaesierra.com/

http://giftcertificates.sonaesierra.com/


54

Sendo o serviço transparente para estes dois targets, não o é para a empresa emissora, que

além de querer responder às novas tendências de negócio, pretende ter um sistema que

centralize e agilize o ciclo de vida de um Cheque-prenda.

Com este projecto pretendemos implementar um sistema que atenda às necessidades da

empresa Sonae Sierra nas áreas de:

BackOffice, onde se irá controlar o ciclo de vida de um Cheque-Prenda, desde a sua

encomenda até à sua compensação;

FrontOffice, ou balcão de atendimento ao público, onde se irá vender ou compensar

o cheque.

Objectivo

O desenvolvimento de software em grande escala obriga à adopção de um processo de

engenharia de software que defina uma abordagem sistemática para a gestão e concepção

das várias valências envolvidas na produção e manutenção do software. O objectivo é

assegurar a produção de software com elevada qualidade, que responda aos requisitos do

usuário final, dentro dos prazos previstos no projecto e utilizando os recursos

dimensionados.

Assim define-se como principal objectivo deste trabalho: Apresentar uma aplicação simples,

intuitiva e agregadora de todos os módulos que constituem o ciclo de vida de um Cheque-

Prenda. Fazendo esta agregação pretende-se identificar todas as variáveis comportamentais

deste associado ao consumidor e/ou empresa, perseguindo a Sonae Sierra, uma política de

ligação directa com os seus targets.

Com a construção deste sistema, pretende-se alcançar os seguintes objectivos específicos:

Consoante as vendas, apurar as necessidades de stock de cheques, por centro ou

serviços centrais;

Utilizando métricas, propor encomendas de cheques à Casa da Moeda, gerando toda

a documentação necessária;

Dar entrada das encomendas realizadas;

Distribuição/Controle do stock de cheques, nos centros ou serviços centrais;

Venda de cheques a consumidores, lojistas ou empresas;

Venda de cheques a lojistas e apuramento de fee a reter;

Controle dos cheques fora da validade;


55

Controle dos cheques que saíram do circuito (em caso de furto ou perca no

transporte entre centros e/ou serviços centrais);

Apuramento de métricas associadas à relação cheques/lojistas e

cheques/consumidor.

Justificação

Para o consumidor final todo este processo resume-se à compra e à troca do Cheque-Prenda

por outro produto. Para o lojista todo este processo baseia-se na entrega e compensação do

Cheque-Prenda. Mas para a empresa emissora é mais do que isso. Desde a sua emissão até à

sua compensação vai um longo percurso, sendo este aquele que queremos traduzir num

único sistema aplicacional.

O sistema aplicacional a desenvolver, irá traduzir um sistema simples que de forma fácil

mostre:

Em que centro comercial está um determinado cheque?

Onde foi um vendido um determinado cheque? Por quem e a quem?

Onde foi compensado um determinado cheque? Por quem e a quem?

Gestão documental de facturas e recibos;

Reports de Vendas vs. Clientes;

Entre outros dados.

Tendo então como base este conhecimento, a empresa poderá em última instância,

responder a questões como:

Já que tenho que manter um stock de cheques, qual o número de cheques que devo

encomendar à Casa da Moeda de forma a que o tempo entre o investimento e o

lucro seja reduzido?

Quais os centros que vendem mais, e com os quais tenho que me preocupar de

forma a manter um stock constante?

Poderei ter um único repositório de dados, onde esteja transparecido todo o ciclo de

vida de um Cheque-Prenda?

Poderei criar um sistema onde todas as requisições sejam feitas online, só existindo o

papel na figura do cheque e no recibo de compra, minorando os custos?


56

Entrega de Produto

Cronograma de entrega - Produtos Intermédios

Nov.

2009

Dez.

2009

Jan.

2010

Fev.

2010

Mar.

2010

Abr.

2010

Mai.

2010

Jun.

2010

Jul.

2010

Ago.

2010

Cronograma de

Projecto

Estudo de

Viabilidade

Análise Custo-

benefício

Especificação de

Requisitos

Entregas de

Funcionalidades

Diagramas de

Actividade

Resultados Testes

de Usabilidade

Plano de Formação

Cronograma de entrega – Produto final

Jan.

2010

Fev.

2010

Mar.

2010

Abr.

2010

Mai.

2010

Jun.

2010

Jul.

2010

Ago.

2010

Set.

2010

Out.

2010

Código Fonte

Formação

Portal

Documentação

Usuário

Documentação

Administrador


57

Restrições

O portal estará disponível na rede interna Sonae Sierra. Qualquer computador ligado a esta

poderá aceder ao portal, utilizando um browser para o efeito. O portal é compatível com os

browsers MS Internet Explorer 6+, Mozilla Firefox 3+ ou Apple Safari.

Só utilizadores autenticados poderão aceder a funcionalidades core do portal

Gift.Certificates, estando estas agrupadas e disponíveis por função de colaborador.

Não será necessária a aquisição de servidores, visto a arquitectura de infra-estrutura da

organização basear-se em máquinas virtuais VMWare.

Alternativas

Em relação à tecnologia aplicada no portal:

Caso a linguagem .NET apresente alguma restrição de difícil ou impossível resolução,

poderemos utilizar a linguagem Java, da qual a equipa possui igualmente experiência

de implementação;

Caso a base de dados MS SQL Server não suporte a carga de aplicação, poderemos

utilizar MaxDB, utilizada no sistema SAP.

Caso o motor de reports MS SQL Reports apresente alguma limitação poderemos

usar a motor de reports MicroStrategy.

Em relação ao problema que o portal pretende dar solução:

Se o novo sistema não fosse implementado, quais seriam as alternativas para a

organização? A alternativa é simplesmente deixar tudo como está. Existe neste

momento uma solução, tendo como desvantagens o tempo de mora de um workflow

inteiro, a quantidade de informação dispersa, administração e controle de processo

difíceis e morosos, entre outras;

De que forma é que o sistema irá contribuir directamente para os objectivos da

organização? A cultura empresarial da Sonae Sierra baseia-se em valores e princípios

como a liderança, a disponibilidade para a mudança, a lealdade, rigor e

transparência. A Sonae Sierra aposta no desenvolvimento de capacidades como


58

forma de criar valor, conduzindo os negócios a posições de liderança, no âmbito

onde operam, e baseia a sua prática quotidiana no profissionalismo, na lealdade, na

gestão do risco e na adopção de métodos de gestão que, de forma célere, detectem

e corrijam situações adversas.

De que forma é que o sistema irá contribuir directamente para os objectivos da

organização, no ponto de vista tecnológico? A tecnologia é a força que sustenta

qualquer organização. Para alcançarem o sucesso, as empresas devem inovar na

utilização das tecnologias, pois só assim conseguirão gerir mais facilmente a mudança

e agarrar as oportunidades. Com uso das tecnologias pretendemos transformar um

processo que é difícil de gerir, em algo simples, visualizável, intuitivo e rápido no

apoio à decisão.

Com que facilidade se consegue partilhar informação entre este sistema e outros da

organização? Estando o portal na infra-estrutura Sonae Sierra, toda a informação

recolhida por este e armazenada em base de dados, poderá ser acedida e consultada

por outros portais ou aplicações, desde que estejam localizados na mesma infra-

estrutura. Também o motor de reports deste portal poderá ser invocado por outros

portais ou aplicações para visualização de informação.

Recursos Requeridos

A equipa de projecto será composta por três pessoas, estando uma a fulltime. O gestor

sendo o elemento não a fulltime, em certas componentes de projecto será igualmente

developer. Não haverá qualquer custo extra por estas três pessoas, visto já serem

colaboradores internos da organização.

Face ao sucesso que tem sido o portal SierraCentres.networks na organização, e querendo o

portal Gift.Certificates ir beber deste algumas boas práticas e interface, a tecnologia utilizada

no desenvolvimento deste, irá ser utilizada no novo. Irá ser usada como linguagem de

desenvolvimento .NET, como motor de bases de dados, o Microsoft SQL Server, e como

motor de reports, o Microsoft SQL Reports. Não haverá portanto qualquer custo extra, pois

será utilizada a mesma licença de Microsoft Visual Studio para desenvolvimento, tal como

será criada uma nova instância de base de dados e reports, na mesma máquina utilizada pelo

portal SierraCentres.networks.

A arquitectura de infra-estrutura deverá atender às premissas:


59

Confidencialidade dos dados e arquivo electrónico;

Rapidez de acesso e resposta do sistema, face ao elevado número de acessos

esperado;

Atomicidade, consistência e durabilidade dos dados;

Plano eficaz de Disaster Recovery;

Estruturas independentes para desenvolvimento, testes (qualidade) e produção.

Como tal foi pensada e desenhada a seguinte estrutura:

Estrutura de Desenvolvimento. Desenvolvimento de novas features; Verificação e

correcção de bugs;

Estrutura de Testes/Qualidade. Imagem perfeita da estrutura de produção; Testes

de novas features e correcções de bugs; Testes de performance;

Estrutura de Produção.

O desenho da infra-estrutura teve como base a experiência ganha noutros portais que

consideramos de igual dimensão, os quais foram sendo ajustados em termos de hardware

conforme as necessidades.

Riscos

Tipo Prob. Efeitos Estratégia

Preventiva

Estratégias

Correctivas

Abandono

Elemento

De Equipa

Pessoal Baixo Tolerável - Backup diário

- Fomentar a

comunicação

- Gestor developer

- Sobrecarregar

grupo

- Contratar

Alteração

Requisitos

Planeamento Alto Sério - Boa definição

- Sobrecarregar

grupo

- Aprender

Carga

Servidor

Aplicacional

Tecnológico Baixo Tolerável - Apurar necessidade

face a portais já

existentes

- Requisitos mínimos

tecnológicos

- Mover recursos

tecnológicos

(+CPU, +Memória,

+Disco)

Carga Motor

DB

Tecnológico Baixo Tolerável - Apurar necessidade

face a portais já

existentes

- Mover recursos

tecnológicos

(+CPU, +Memória,


60

- Requisitos mínimos

tecnológicos

+Disco)

- Query Sniffer

Impopularid

ade

Pessoal Médio Sério - Envolver a

organização

- Publicitar sistema

-Publicitar sistema

Inaptidão

Tecnológica

Pessoal Médio Sério - Formação - Formação

Modelo de Processo

Um modelo ágil de desenvolvimento de software irá ser usado neste projecto,

proporcionando ao longo do tempo de desenvolvimento a existência de pequenos

protótipos a cada nova feature de portal.

Testes de usabilidade irão ser criados, utilizados e medidos, como forma de facilitar a

entrada do portal em produtivo e redução do risco de falha.

Apesar de um dos objectivos do portal ser a intuitividade, estabelecer-se-á um plano de formação.


61

2. Análise Custo-benefício

2.1. Introdução

Aquando da avaliação de uma determinada decisão ou projecto por parte de um agente

económico é feita uma análise Custo-benefício. Esta consiste genericamente na valorização

em termos monetários de todos os efeitos previsíveis da decisão no projecto em causa para

o conjunto de períodos levados em conta na análise. A avaliação deverá também englobar

todos os grupos potencialmente influenciados pela decisão ou projecto em causa, e não

apenas a entidade que dele está encarregue.

Este tipo de análise começa por definir, para cada grupo potencialmente afectado, os efeitos

previsíveis associados à decisão. Seguidamente todos os efeitos são valorizados em termos

monetários, apresentando os efeitos positivos (benefícios) e os efeitos negativos (custos).

2.2. Documento de Análise Apresentado

Introdução

Uma análise Custo-benefício consiste genericamente na valorização em termos monetários

de todos os efeitos previsíveis da decisão no projecto em causa para o conjunto de períodos

levados em conta na análise. A avaliação deverá também englobar todos os grupos

potencialmente influenciados pela decisão ou projecto em causa, e não apenas a entidade

que dele está encarregue.

Com este documento pretendemos mostrar que o Projecto Portal Gift.Certificates Sonae

Sierra é um projecto bom e viável para a Sonae Sierra, apontando já a duas prévias

conclusões:

1. Os custos de projecto praticamente negligenciáveis para a organização;

2. Os benefício que a organização terá deste projecto.

Iremos analisar os custos que a Sonae Sierra terá de suportar na duração e manutenção

deste projecto.


62

Iremos igualmente analisar os benefícios, qualitativos e quantitativos que esperamos que a

Sonae Sierra obtenha.

Análise de Custos

O Projecto Portal Gift.Certificates Sonae Sierra será inteiramente suportado pela Direcção de

Sistemas de Informação, departamento TI da Sonae Sierra. Uma das áreas afectas a este

departamento é a de desenvolvimento interno, constituída por cinco pessoas. É da

responsabilidade desta área todo o desenvolvimento e suporte de produtos feitos dentro da

Sonae Sierra, sendo o nosso cliente a própria Sonae Sierra.

A infra-estrutura onde estará o portal montado será igualmente suportada pelo

departamento, mantendo-se a mesma lógica de outros portais disponibilizados à

organização.

O departamento cobrará a cada aderente ao sistema, ou seja, a cada centro, uma fee mensal

que irá diluir o custo do desenvolvimento por dois anos, e que prevê a infra-estrutura,

suporte e manutenção do portal. Este valor não ultrapassará os 50,00 € mensais nos

primeiros dois anos, podendo baixar consoante mais países e centros forem aderindo ao

programa Cheque-Prenda. Caso todo o universo Sonae Sierra adira, a fee mensal rondará no

máximo os 40,00 €. Ao fim dos dois anos dependendo ou não de possíveis melhorias ao

portal que se queiram aplicar a fee mensal poderá passar para os 15,00 € mensais.

Com mais detalhe iremos analisar os custos com:

Recursos Humanos;

Recursos Infra-estruturais;

Software e arquitectura;

Formadores e material de formação;

Operação e manutenção.

Recursos Humanos


63

A equipa de projecto será composta por três pessoas, estando uma a fulltime. O gestor

sendo o elemento não a fulltime, em certas componentes de projecto será igualmente

developer. Não haverá qualquer custo extra por estas três pessoas, visto já serem

colaboradores internos da organização. Não se prevê qualquer compensação monetária

após a entrega do projecto.

Como já referido anteriormente a equipa de desenvolvimento interno é constituída por

cinco pessoas. Estando uma a fulltime e as outras alocadas a full ou a part, ficamos com três

elementos, para outros projectos e suporte global. Poderá acontecer que uma das pessoas

alocadas a partime possa tirar algum tempo para ajudar noutro projecto, não podendo

contudo afectar os prazos de projecto.

Um grupo de cinco pessoas externas à equipa e representativas dos vários grupos de perfil

que vão utilizar o portal já foram convidadas e aceitaram participar nos testes de usabilidade

do portal. Não se prevê qualquer compensação monetária após o teste.

Recursos Infra-estruturais

Como já referido anteriormente toda a infra-estrutura onde reside o portal será

inteiramente suportada pela Direcção de Sistemas de Informação. O centro poderá requerer

mais uma estação de trabalho para acesso via browser ao portal. Esta estação de trabalho e

ligação à nossa rede será cobrado, conforme a política já conhecida.

Software e Arquitectura

Face ao sucesso que tem sido o portal SierraCentres.networks na organização, e querendo o

portal Gift.Certificates ir beber deste algumas boas práticas e interface, a tecnologia utilizada

no desenvolvimento deste, irá ser utilizada no novo. Irá ser usada como linguagem de

desenvolvimento .NET, como motor de bases de dados, o Microsoft SQL Server, e como

motor de reports, o Microsoft SQL Reports. Não haverá portanto qualquer custo extra, pois

será utilizada a mesma licença de Microsoft Visual Studio para desenvolvimento, tal como

será criada uma nova instância de base de dados e reports, na mesma máquina utilizada pelo

portal SierraCentres.networks.

A arquitectura de infra-estrutura deverá atender às premissas:


64



esperado;



Estruturas independentes para desenvolvimento, testes/qualidade e produção.

Como tal foi pensada e desenhada a seguinte estrutura:

Estrutura de Desenvolvimento. Desenvolvimento de novas features; Verificação e

correcção de bugs;

Estrutura de Testes/Qualidade. Imagem perfeita da estrutura de produção; Testes

de novas features e correcções de bugs; Testes de performance;

Estrutura de Produção.

O desenho da infra-estrutura teve como base a experiência ganha noutros portais que

consideramos de igual dimensão, os quais foram sendo ajustados em termos de hardware

conforme as necessidades.

Formadores e Material de Formação

Um dos objectivos deste portal é ser intuitivo. Se o produto é de fácil aprendizagem, o

usuário aprende mais depressa e retém por mais tempo esse conhecimento. Irá contudo ser

posto à disposição do usuário final um manual de utilização, apresentações, uma área de

FAQ e de contactos, tal como à área de helpdesk, um manual de administração e de risco.

Irá ser criado pela equipa de projecto uma pequena, mas esclarecedora apresentação do

portal, que será mostrada em videoconferência. Neste momento toda a organização Sonae

Sierra está conectada pelo sistema de videoconferência, permitindo este acesso remoto a

uma estação de trabalho. Logo poderá ser dada formação online a cada centro. Prevê-se

uma semana de formação contemplando todos os centros de Portugal e Espanha. Não se

prevê qualquer custo adicional para este plano de formação.

Operação e Manutenção


65

Como já referido o departamento cobrará a cada aderente ao sistema, ou seja, a cada

centro, uma fee mensal que irá diluir o custo do desenvolvimento por dois anos, e que prevê

a infra-estrutura, suporte e manutenção do portal. Este valor não ultrapassará os 80,00 €

mensais nos primeiros dois anos, podendo baixar consoante mais países e centros forem

aderindo ao programa Cheque-Prenda. Caso todo o universo Sonae Sierra adira, a fee

mensal rondará os 50,00 €.

Ao fim dos dois anos dependendo ou não de possíveis melhorias ao portal que se queiram

aplicar a fee mensal poderá passar para os 30,00 € mensais.

Análise de Benefícios

Iremos analisar os benefícios deste projecto, dividindo em dois grupos:

Benefícios Qualitativos;

Benefícios Quantitativos.

Benefícios Qualitativos

A Sonae Sierra BackOffice irá ter num só sistema a gestão de todo o ciclo de vida de

um Cheque-Prenda, desde a sua encomenda até à sua compensação ou anulação.

Toda a informação concentrada num só local;

A Sonae Sierra FrontOffice, ou balcão de atendimento ao público, que irá ter um

sistema simples e eficaz, para a venda ou recepção de cheque para compensação;

O controle ao segundo de stocks de cheques, quer no centro, quer no armazém;

Geração de reports de encomenda, vendas, compensações, como forma de

optimização do negócio;

Ganho de tempo face ao sistema anterior. O tempo é precioso para qualquer

colaborador, podendo este ser realocado para outras tarefas;

O conhecimento ganho pela equipa de desenvolvimento, traduzido em

documentação. Esta documentação irá servir para a organização face ao ingresso de

novos colaboradores, poupar tempo na sua formação;

Face ao estudo de todo o workflow do Cheque-Prenda para implementação num

portal, identificar possíveis melhorias com vista à optimização do processo.


66

Benefícios Quantitativos

O custo do projecto, traduzido numa fee mensal, é negligenciável face ao orçamento anual

de cada centro. A optimização do tempo de cada colaborador afecto ao portal e a

possibilidade de captar novos clientes ao seu centro por ser um centro aderente ao Cheque-

Prenda são benefícios suficientes para o centro.


67

Capítulo IV – Planeamento, Desenvolvimento e Implementação

1. Metodologia adoptada

1.1. Apresentação

Como metodologia de desenvolvimento optámos pelo método Scrum, uma metodologia ágil.

Cumprindo esta abordagem ágil, a cada incremento de funcionalidade irá ser feito um teste

de usabilidade a dois ou mais usuários. A cada usuário serão distribuídos dois documentos:

1. Documento de cenário. O usuário terá que cumprir um ou mais cenários,

associados à funcionalidade;

2. Documento de avaliação de teste. O usuário quer por checklist, quer por palavras,

terá que expressar as dificuldades e/ou sucessos que sentiu no cumprimento do

cenário.

1.2. Justificação

A escolha deste método deveu-se principalmente à conjugação perfeita da natureza do

projecto com os valores do manifesto ágil:

Indivíduos e interacções são mais importantes que processos de ferramentas. É

fundamental a ajuda de todos os usuários finais que irão estar ligados à ferramenta.

A optimização do processo só pode acontecer com o conhecimento e ideias destes;

Software funcionando é mais importante do que documentação completa e

detalhada. É fundamental que todo o portal esteja a funcionar a 100% antes da sua

passagem a produção devido à sensibilidade do negócio. A qualidade de

implementação é de grande importância, não descurando ao mesmo tempo a

documentação final;

Colaboração com o cliente. É fundamental transmitir ao cliente que o produto já vai

tendo algum valor ao longo do desenvolvimento, não esperando só pelo fim;


68

Adaptação a mudanças. É fundamental termos uma metodologia que reaja bem à

mudança, pois esta concerteza vai acontecer. Novas ideias, algumas alterações irão

sempre surgir, como é típico num portal novo.

Resumindo o método Scrum é baseado em ciclos de duas a quatro semanas, chamados de

Sprints. Prevemos que nesta implementação haja ciclos de no mínimo 1 dias e no máximo de

três semanas.

É de notar que iremos usar este método não só para o desenvolvimento de software, mas

igualmente para a produção de documentação, estudo de viabilidade, análise Custo-

benefício, e outros processos. Cada processo será encarado como um Sprint.

Cada Sprint tem como objectivo entregar um incremento de documentação ou software

finalizado, ou seja, nova informação ou funcionalidade no conjunto que constitui o produto

final.

Existe um backlog de produto que contém toda uma listagem de tarefas que é objectivo

entregar de forma a chegarmos ao produto final.

Quem define essa lista é o Product Owner, neste caso o gestor de projecto, que prioritiza os

itens e faz a ponte entre o cliente e a equipa de desenvolvimento. No nosso caso o Product

Owner fará igualmente o papel de Scrum Master, ou seja, a pessoa que foca a equipa na

meta em cada Sprint.

Pela natureza do projecto, e face às previsíveis alterações aos requisitos deste durante a

implementação, o desafio do Product Owner vai estar no como receber, avaliar e responder

à mudança. No limite podemos entrar num loop de iterações com o cliente, o que vai atrasar

os prazos acordados e aumentar os custos de projecto.

Ao contrário do aconselhado pelo método ágil Scrum, não iremos fazer reuniões diárias

sobre o estado de cada Sprint. Todos os elementos da equipa já possuem experiência de

projecto, e têm um bom conhecimento sobre as capacidades de cada elemento. Existirá no

máximo uma reunião por semana de quinze minutos, caso o Sprint tenha a duração de mais

de uma semana. A reunião final a cada Sprint, a Sprint Review, irá sempre acontecer, sendo

nesta apresentado novo incremento ao cliente.

Aplicando esta abordagem ágil agrupámos todo o projecto, ou seja, desde a sua proposta

até à sua entrega, em três backlogs de produto. É condição os três backlogs serem

finalizados para o produto ser considerado como finalizado. São os backlogs de produto:

1. Processo de Negócio. Envolve tudo o que prepara, aprova e delimita o processo

de desenvolvimento de software;

2. Processo de Desenvolvimento de Software. Envolve a construção do software;


69

3. Processo de Operação/Manutenção. Envolve todo o pós-desenvolvimento de

software.

Processo de Negócio

Sprint Sprint Backlog Duração

Tem

po

Cronograma de Projecto - Descrever o ciclo de desenvolvimento 3 D

Estudo de Viabilidade - Designação de portal

- Logotipo

- Objectivo

- Justificação

- Entrega de Produto

- Restrições

- Alternativas

- Recursos Requeridos

- Riscos

- Modelo de Processo

4 S

Análise Custo-benefício - Análise de Custos:

- Recursos Humanos

- Recursos Infra-estruturais

- Software e arquitectura

- Formadores e material formação

- Operação e Manutenção

- Análise de Benefícios:

- Benefícios Qualitativos

- Benefícios Quantitativos

4 S

Especificação de Requisitos - Requisitos de portal e processo 2 S

Diagramas de Actividade - Definição dos processos workflow 2 S

Tab. 9 – Scrum Backlog Processo de Negócio

É de notar que as durações para cada Sprint identificadas são durações previstas. Estas

poderão ser alteradas ou mesmo repetidas. Se tomarmos como exemplo a especificação de

requisitos, estes estão sujeitos à mudança por parte do cliente. Esta mudança forçará um

novo Sprint, que como consequência forçara novos Sprints no Diagrama de Actividades e

Cronograma de Projecto.


70

Entrando num maior de detalhe de Sprint, face ao Processo de Negócio:

Cronograma de Projecto. Pretende-se descrever todo o ciclo de

desenvolvimento, enumerando as etapas de processo e dividindo-as em tarefas a

ser executadas. No nosso caso, e como já descrito, teremos três etapas de

processo: processo de negócio; processo de desenvolvimento de software;

processo de operação/manutenção.

Estudo de Viabilidade. Pretende-se avaliar se do ponto de vista tecnológico e

organizacional, o projecto é viável. Ver Capítulo III, Índice 1.

Análise Custo-benefício. Pretende-se avaliar se os benefícios da tomada de

decisão, sobre os custos desta, são positivos para a organização. Ver Capítulo III,

Índice 2.

Especificação de Requisitos. Nos Requisitos Técnicos, pretende-se dar todo o

conhecimento sobre a arquitectura montada, endereços IP reservados, endereço

SVN e instâncias de BD criadas. Ver Anexo B. Nos Requisitos Funcionais pretende-

se dar uma mockup de todas as funcionalidades de portal, tal como as suas

regras.

Diagramas de Actividade. Pretende-se mostrar o fluxo de controlo entre

actividades, decompondo assim uma funcionalidade core do portal em sub-

actividades. Ver Capítulo IV, Índice 3.

Prevê-se que o Processo de Negócio tenha a duração de 1 mês e meio no máximo.

Processo de Desenvolvimento de Software


T

emp

o

Arquit. Desenvolvimento - Instalação uma máquina

- Instalação SO, IIS, SQL Server

- Instalação Infra-estrutura Rede

- SVN Version System

2 D

Arquit. Qualidade - Instalação duas máquinas



- Comunicação entre máquinas

2 D

Estrutura de Projecto - Estruturação do código

- Criar projecto no SVN

1 D

Layout Master - CSS

- Logotipo

1 S


71

- Botões

Homepage - Interface

- Menu

- Quicklinks

- Login / Logout

2 S

Context - Centro de operação 1 S

Site Map - Informação

- Configuração QuickHomePage

- Configuração QuickLinks

2 S

Help - Manuais

- FAQ

3 D

Contact Us - Motor de Contacto/Resposta 1 S

Orders - Gestão de Ordens de Compra 2 S

Sales - Registo de Vendas Público

- Registo de Vendas Empresas

2 S

Deposits - Gestão de Depósitos Centros 2 S

Compensations - Gestão de Compensações 2 S

Cancel Gift Certificates - Cancelamento de Cheques-Prenda 1 S

Toolbox - Petty Cash Fund Restitution. Gestão de

fundos de caixa

- Reception GC Books. Registo de recepção de

blocos de cheques.

- Gift Certificates Switch. Troca de Cheques.

- Compensation Receipts. Gestão de

compensações efectuadas.

- Compensation Credit Receipts. Gestão de

Notas de Crédito após compensação.

- Search Buyer Companies. Gestão de clientes

empresa.

- Sale Receipts. Gestão de vendas efectuadas.

- Payment Confirmation. Confirmação de

pagamento sobre as vendas.

6 S

Mall Stores Participation - Lojas aderente por centro. 2 S

Order/Stock Management - Sistema para encomenda e controle de stocks

de cheques-prenda.

3 S


72

Reports - Sales by Centre/Country. Vendas por

centro/país.

- Stocks by Centre/Country. Stocks por

centro/país.

- Best Seller by Centre/Country. Melhor

vendedor por centro/país

- Best Client by Centre/Country. Melhor

cliente empresarial por centro/país.

- Certificate Type w/ Best Sales by

Centre/Country. Tipo de cheque com

melhores vendas por centro/país.

- Avg Time Between Order and Sale by

Centre/Country. Tempo médio entre a

encomenda e a venda por centro/país

- Avg Time for Stock Rotation by

Centre/Country. Tempo médio de rotação de

stocks.

- Certicates Overview. Detalhe de cheque ou

cheques por centro/país

- Others. Segunda Fase.

4 S

Configure Application - Gestão de roles segurança

- Gestão de tipos de cheques

- Gestão de parâmetros de aplicação

2 S

Tab. 10 – Scrum Backlog Processo de Desenvolvimento de Software


poderão ser alteradas ou mesmo repetidas.

Entrando num maior de detalhe de Sprint, face aos Processo de Desenvolvimento de

Software:

Arquitectura de Desenvolvimento. Instalação de uma imagem MS Windows Server

2003, numa arquitectura virtualizada. Nesta imagem fazer a instalação do IIS como

Web Server, do MS SQL Server 2005 como motor de base de dados, do MS SQL

Reports como motor de reports e do SVN Version System como motor de controle de

versões. Uma só máquina irá comportar-se como frontend e backend.

Arquitectura de Qualidade. Instalação de uma imagem MS Windows Server 2003,

numa arquitectura virtualizada. Nesta imagem fazer a instalação do IIS como Web


73

Server, indo esta comportar-se como frontend do portal. Instalação de uma outra

imagem MS Windows Server 2003, numa arquitectura virtualizada. Nesta imagem

fazer a instalação do MS SQL Server 2005 como motor de base de dados e do MS SQL

Reports como motor de reports, indo esta comportar-se como backend do portal. É

importante garantir que os dois pontos de rede são visíveis entre si. Esta arquitectura

deve espalhar ao detalhe a arquitectura em produtivo.

Estrutura de Projecto. Fazer a estruturação de todo o código a desenvolver,

conforme as regras já definidas pela área de desenvolvimento interno para

desenvolvimentos de portais. Criar o projecto no sistema de controlo de versões.

Neste projecto criar quatro branchs de desenvolvimento. Um branch corresponderá

sempre à versão “produtiva” em desenvolvimento, sendo os outros três a versões em

desenvolvimento por parte de cada um dos elementos da equipa;

Layout Master. Definir por CSS a apresentação default do portal, promovendo a

separação entre o formato e o conteúdo. Definir o logótipo do portal e formatação

dos botões de acção.

Homepage. Definir o interface de homepage. O header e footer de página, a área de

menu e a área dinâmica de aplicação, target de menu. A área de header irá conter

informação sobre o usuário de sessão, acesso à função Context, à função Site Map, à

função Help, à função Contact Us e à função QuickLinks.

Context. O portal tem implementado a feature de SingleSignOn. Dependendo do

usuário de rede no terminal, ao aceder ao portal, este reconhece o usuário, tal como

as suas permissões e a que centro ou centros está associado. No caso de poder

visualizar ou trabalhar em mais que um centro, na função Context poderemos alterar

o centro onde quero trabalhar no portal. Todas as funcionalidades do portal

dependem sempre do centro seleccionado ou herdado pelo usuário.

Site Map. Temos uma imagem de todas entradas de menu disponíveis ao usuário

conforme as suas permissões. Para cada sub-aplicação (entrada) teremos uma breve

explicação da função desta. Aqui o usuário poderá seleccionar qual ou quais entradas

que quer ter na área de QuickLinks, para acesso fácil. Também poderá seleccionar

uma sub-aplicação para entrada automática, a quando acedemos ao portal.

Help. Área de ajuda à operação: manuais de usuário; FAQ.

Contact Us. Ferramenta onde o usuário poderá tirar dúvidas, dar recomendações ou

reportar bugs do portal. Uma form irá ser usada para preenchimento. Nesta estarão

já especificados vários temas, passíveis de pedidos de informação.

Orders. Gestão de todas as ordens de compra criadas até à data. Esta ordem de

compra deverá ser usada somente para clientes empresariais e para grandes

encomendas de Cheques-Prenda. Toda a geração de facturas pró-forma, guias de

entrega, guias de envio e detalhe de ordem, é feita nesta área. Uma ordem de


74

compra pode ser cancelada ou confirmada, sendo neste caso transformada numa

venda.

Sales. Área de venda de um ou mais Cheques-Prenda ao público ou a empresas. A

uma compra poderão estar associados serviços extra, como envelopes

personificados, envio por correio, etc.

Deposits. Gestão de todos os depósitos criados até à data. Todo o dinheiro recolhido

da venda após um dia de trabalho deverá ser depositado numa conta especificada

para o efeito. O comprovativo de depósito deverá ser carregado e associado no

portal às vendas a que se refere. Os serviços centrais farão a comparação entre os

depósitos declarados e o valor disponível em conta.

Compensations. Gestão de todas as compensações criadas até à data. O lojista ao

receber um Cheque-Prenda para pagamento, deverá querer compensá-lo junto do

centro. O centro ao receber os cheques irá marcá-los como compensados nesta área.

O sistema faz o cálculo das fees a aplicar e remete para os serviços centrais o valor da

transferência a efectuar para o lojista.

Cancel Gift Certificates. Por roubo ou extravio de cheques o centro poderá querer

marcar um determinado grupo de cheques como cancelados, como forma de não

conseguirem ser compensados.

Toolbox. Área de funções úteis à operação:

o Petty Cash Fund Restitution. Gestão de fundos de caixa para venda de

Cheques-Prenda.

o Reception GC Books. Gestão de blocos de cheques recebidos.

o Gift Certificates Switch. Motor para troca de cheques. Mediante o

pagamento de uma fee, é possível a uma empresa trocar um cheque por

outro, estendendo assim o prazo de validade. O que conta na troca é valor

total monetário de cheques, sendo possível assim trocar por quantidades

diferentes.

o Compensation Receipts. Gestão dos recibos de todas as compensações até à

data. É possível a impressão de segunda via, sendo esta incrementada

conforme as impressões.

o Compensation Credit Receipts. Gestão dos recibos de notas de crédito até à

data. É possível a impressão de segunda via, sendo esta incrementada

conforme as impressões.

o Search Buyer Companies. Verificação de vendas, mínima, média e máxima

por cliente empresa, tal como o seu historial.

o Sale Receipts. Gestão de recibos de todas as vendas até à data. É possível a

impressão de segunda via, sendo esta incrementada conforme as impressões.

o Payment Confirmation. Gestão dos comprovativos de pagamento por

transferência bancária, de clientes empresa.


75

Mall Stores Participation. Listagem de lojas aderentes ao programa Cheques-Prenda

por centro dependendo do contexto.

Order/Stock Management. Gestão de todas as encomendas de Cheques-Prenda à

Casa da Moeda até à data. É gerado consoante o pedido uma form já pré-formatada

pela Casa da Moeda para encomenda de cheques. Quando a encomenda chega o

grupo de cheques a que se refere, são marcados para venda e repostos nos stocks de

cada centro.

Reports. Área de relatórios:

o Sales by Centre/Country. O valor total de vendas, para um dado período de

tempo, agrupado por cliente privado e empresarial, num dado centro ou país.

o Stocks by Centro/Country. Os stocks online, agrupados por tipo de cheque,

num dado centro ou país.

o Best Seller by Centre/Country. Vendedor com maior valor de venda, para um

dado período de tempo, agrupado por cliente privado e empresarial, num

dado centro ou país.

o Best Client by Centre/Country. Cliente empresarial com maior valor de

compra, para um dado período de tempo, num dado centro ou país.

o Certificate Type w/ Best Sales by Centre/Country. Tipo de cheque com maior

saída, para um dado período de tempo, agrupado por cliente privado e

empresarial, num dado centro ou país.

o Avg Time between Order and Sale by Centre/Country. Tempo médio para um

tipo de cheque, entre a sua encomenda e a sua venda, num dado centro ou

país.

o Avg Time for Stock Rotation. Tempo médio de rotação de stock, num dado

centro ou país.

o Certicates Overview. Detalhe e localização de um ou mais cheques.

o Others. Espaço para a introdução de mais reports, numa segunda fase de

projecto.

Configure Application. Gere as permissões de utilizador, a nível de administrador,

gestor de centro ou vendedor. Faz a gestão do tipo de cheque por país. Parametriza

alguns valores decorrentes da operação do portal, tendo como exemplo, o valor de

alguns serviços extra na venda.

Prevê-se que o Processo de Desenvolvimento de Software tenha a duração de 9 meses no

máximo.

Processo de Operação/Manutenção


76


Tem

po

Plano de Formação - Documento Apresentação Portal

- Marcação de Salas VideoConf

- Verificação Disponibilidade

1 S

Documentação Usuário - Documentação Operação 1 S

Documentação Administração - Documentação Administração

- Documentação Gestão Risco 1 S

Formação - Dias para formação 1 M

Arquitectura Produtivo - Instalação duas máquinas



- Comunicação entre máquinas

3 D

Passagem a Produtivo - Deploy

- Acompanhamento 1 S

Tab. 11 – Scrum Backlog Processo de Operação/Manutenção


poderão ser alteradas ou mesmo repetidas.

Entrando num maior de detalhe de Sprint, face ao Processo de Operação/Manutenção:

Plano de Formação. Pretende-se fabricar um documento para apresentação do

portal, que seja directo e esclarecedor. Este documento em consonância com a

formação online será apresentado por videoconferência a todos os centros.

Factor importante no planeamento das formações será a disponibilidade a

acordar com os usuários finais localizados nos vários centros.

Documentação Usuário. Pretende-se fabricar um manual de operação para o

usuário final, não administrador.

Documentação Administração. Pretende-se fabricar um manual de

administração, contendo a gestão de risco.

Formação. Tempo de formação a ser dado por centro.

Arquitectura Produtivo. Instalação de uma imagem MS Windows Server 2003,

numa arquitectura virtualizada. Nesta imagem fazer a instalação do IIS como Web

Server, indo esta comportar-se como frontend do portal. Instalação de uma outra

imagem MS Windows Server 2003, numa arquitectura virtualizada. Nesta imagem

fazer a instalação do MS SQL Server 2005 como motor de base de dados e do MS

SQL Reports como motor de reports, indo esta comportar-se como backend do


77

portal. É importante garantir que os dois pontos de rede são visíveis entre si,

tomando em conta a segurança da ligação, visto a máquina em frontend estar

exposta para a Web.

Passagem a Produtivo. Fazer o deploy da solução para a arquitectura em

produtivo e fazer o acompanhamento na primeira semana, estando atento aos

logs do IIS e SQL.

Prevê-se que o Processo de Operação/Manutenção tenha a duração de 2 meses no máximo.

Os testes de usabilidade irão ser aplicados a quando o Processo de Desenvolvimento de

Software, sendo aconselhável que estes ocorram no fim de cada Sprint para avaliação de

incremento de funcionalidade. No entanto pode acontecer que estes tenham igualmente

impacto no Processo de Negócio, visto o resultado do teste poder implicar a mudança de

requisitos.

1.3. Cronograma previsto


78

Abr.

2009

Mai.

2009

Jun.

2009

Jul.

2009

Ago.

2009

Set.

2009

Out.

2009

Nov.

2009

Dez.

2009

Relatório de projecto

Revisão da literatura

Reuniões de projecto

Implementação

Testes usabilidade

Piloto

Documentação / Formação

Tab. 12 – Cronograma previsto (a)

Jan.

2010

Fev.

2010

Mar.

2010

Abr.

2010

Mai.

2010

Jun.

2010

Jul.

2009

Ago.

2009

Set.

2009




Implementação

Testes usabilidade

Piloto


Tab. 13 – Cronograma previsto (b)


79

2. Hardware, software e arquitectura de sistema

A Sonae Sierra conta hoje com uma infra-estrutura virtual VMWare, onde os usuários vêem

os recursos como se estivessem dedicados a eles, enquanto o administrador gere e optimiza

os recursos globalmente para toda a empresa.

A arquitectura de infra-estrutura VMWare permitiu-nos reduzir custos de TI com melhorias

em termos de eficiência, flexibilidade e capacidade de resposta. A gestão de uma infra-

estrutura virtual permite que a equipa de TI tenha total controlo sobre os recursos,

estabelecendo rapidamente uma conexão entre eles e as necessidades dos negócios.

Fig. 16 – Típica infra-estrutura virtual

Atendendo a premissas como:



esperado;



Estruturas independentes para desenvolvimento, testes/qualidade e produção;


80

Sistema para controlo de versões SVN.

Foi pensada e desenhada a seguinte estrutura:

Estrutura de Desenvolvimento:

o Descrição:

Uma só máquina para frontend e backend. Na mesma máquina estará

disponível o application server, a estrutura de base de dados, arquivo

documental, sistema de reports e motor para controle de versões SVN.

o Objectivo:

Desenvolvimento de novas features;

Verificação e correcção de bugs.

o Hardware:

2 Intel(R) Xeon(R) CPU E5345 2.34GHz

2,00 GB RAM

50 GB Disco rígido

o Software:

Microsoft Windows Server 2003 R2 Enterprise SP2

Microsoft Internet Information Service

Microsoft SQL Server 2005

Microsoft SQL Reports 2005

SVN Connector Control Version

o Política de Disaster Recovery:

Backup de máquina com 48 horas de intervalo.

Estrutura de Testes/Qualidade:

o Descrição:

Duas máquinas, sendo uma para Frontend e outra para Backend. No

frontend está disponível o application server, ou seja, o interface com

o usuário. No backend estão disponíveis a estrutura de base de dados,

arquivo documental e sistema de reports.

o Objectivo:

Imagem perfeita da estrutura de produção;

Testes de novas features e correcções de bugs;

Testes de performance.

o Hardware:

Frontend:


81


2,00 GB RAM

20 GB Disco rígido

Backend:


2,00 GB RAM

30 GB Disco rígido

o Software:

Frontend:



Backend:





Backup de máquina com 24 horas de intervalo. Registos em base de

dados replicados noutra máquina com intervalos mais curtos. Ao fazer

backup, simultaneamente é feito um restore num recovery site. Em

caso de disaster o sistema automaticamente aponta para a máquina

existente no recovery site, que aponta para a base de dados replicada.

Estrutura de Produção:

o Descrição:

Duas máquinas, sendo uma para Frontend e outra para Backend. No

frontend está disponível o application server, ou seja, o interface com

o usuário. No backend estão disponíveis a estrutura de base de dados,

arquivo documental e sistema de reports.

o Objectivo:

Estrutura de produção, visível aos usuários finais;

o Hardware:

Frontend:


2,00 GB RAM

20 GB Disco rígido

Backend:



82

2,00 GB RAM

30 GB Disco rígido

o Software:

Frontend:



Backend:





Backup de máquina com 24 horas de intervalo. Registos em base de

dados replicados noutra máquina com intervalos mais curtos. Ao fazer

backup, simultaneamente é feito um restore num recovery site. Em

caso de disaster o sistema automaticamente aponta para a máquina

existente no recovery site, que aponta para a base de dados replicada.

O desenho da infra-estrutura teve como base a experiência ganha noutros portais

considerados de igual dimensão, os quais foram sendo ajustados em termos de hardware

conforme as necessidades. Todos os ajustes on the fly (número de processadores, memória

RAM e espaço em disco) que uma infra-estrutura virtual nos permite, poderão no futuro ser

aplicados conforme as necessidades e métricas de acesso e processamento tiradas.


83

3. Diagrama de actividades

3.1. Introdução

O diagrama de actividades é um diagrama definido pela Linguagem de Modelagem Unificada

(UML), e representa essencialmente um gráfico de fluxo, mostrando o fluxo de controlo de

uma actividade para outra.

Um diagrama de actividades poderá conter:

Estados de actividades. Permitem descrever um conjunto de acções que são

realizadas quando a actividade de inicia, durante o seu desenvolvimento e

imediatamente antes de terminar;

Estados de acção. São estados do sistema representando a execução de uma acção;

Transições. Quando a acção ou transição de um estado completa, o fluxo de controlo

passa imediatamente para o próximo estado de acção ou actividade;

Objectos. Pode ser de entrada (consulta) ou de saída (para criação, modificação ou

destruição) de uma acção;

Decisões (branching). Permitem especificar caminhos alternativos, ou seja, descrever

divergências e convergências;

Difusão (fork) e junção (join). Uma junção representa a sincronização de dois ou

mais fluxos de controlo. Uma difusão representa a separação de um fluxo de controlo

em dois ou mais fluxos de controlo.

Pistas ou Regiões (swimlanes). Regiões separadas por linhas contínuas. Cada região

está associada a uma unidade organizacional, entidade ou objecto responsável pelas

acções e actividades aí localizadas. Cada acção ou actividade está localizada numa só

região, podendo as transições entre estas atravessar várias regiões.

Algumas das vantagens na utilização de um diagrama de actividades prendem-se com a

compreensão que este possibilita do workflow, e o facto de suportar o comportamento

paralelo.

3.2. Actividades

Nos diagramas desenhados foram delineadas as seguintes regiões:


84

Casa da Moeda. Entidade externa à Sonae Sierra, à qual encomenda cheques;

Sistema/Portal Cheque-Prenda. Sistema objectivo deste projecto;

MKTB2B (Marketing Business to Business). Área comercial interna à Sonae Sierra,

que lida com a encomenda de cheques, reposição de stocks nos vários centros

comerciais e venda destes a grandes clientes;

Centro Comercial. Área comercial pertencente à Sonae Sierra, que vende cheques ao

público e recebe-os dos lojistas para compensação;

Cliente. Figura do cliente normal de um centro comercial, ou do grande cliente

(empresas);

Tesouraria. Área interna à Sonae Sierra, que controla as compensações de cheques,

transferências bancárias e fundos de caixa em cada centro comercial;

Lojista. Recebe um ou mais Cheques-Prenda de um cliente como forma de

pagamento e entrega-os no próprio centro comercial para compensação.


85

3.2.1. Actividade Provisionamento de cheques – Etapa Encomenda

Provisioning - Encomenda

Sistema Cheques-Prenda Casa da MoedaMKTB2B

Encomenda

Cheques-Prenda

Gera pedido de

encomenda

Tipo de Cheque

Número Cheque

Valor Cheque

Validade Cheque

Download da ordem de encomenda

Recebe pedido de

encomenda

Prazo entrega

Ordem de encomenda

Encomenda

vs. Prazo

Recebe Cheques-

Prenda

Fim Processo

Aceita Prazo OKImpressão de

Cheques-Prenda

NOK

Envio de

Cheques-Prenda

Factura

NOK

Nova ordem de

encomenda

OK

OK

NOK

Encomenda

vs. Cheques

OK

NOK

Ordem de

encomenda

Gera Ordem de

encomenda

Cancelar ordem

de encomenda

Fig. 17 – Actividade Provisionamento de cheques – Etapa Encomenda


86

3.2.2. Actividade Provisionamento de cheques – Etapa gestão

Provisioning - Gestão

ShoppingsSistema Cheques-PrendaMKTB2B

Recebi os

cheques

Check-In

Armazém

Cheque VálidoCheck-In

Inválido

Fim Processo

OK

NOK

Transferir

Cheques para

Shoppings

Relocalizar

Cheque

Enviar Cheques

Recebi

Cheques

Fim Processo

OK

NOK

Relocalizar

Cheques

Relocalizar

ChequeEnviar Cheques

Recebi

Cheques

OK

Fim Processo

NOK

Cheques

Perdidos

Pedido ChequesRegista Pedido

Transferir

Cheques para

Shoppings

Relocalizar

Cheques

Encomenda

Cheques-Prenda

OK

OK

Cheques

Perdidos

Verifica Stock

NOK

Fig. 18 – Actividade Provisionamento de cheques – Etapa gestão


87

3.2.3. Actividade Venda de cheques – Grandes clientes

Orders

ClienteShoppingSistema Cheque-PrendaMKTB2B

Pedido de

Cheques

Recebe Contacto

de Cliente

Gera Order

Order

Envia Proposta

Recebe Proposta

Aceita

Estado Pendente

Fim Processo

NOK

Nº. cliente

Nº. encomenda cliente

Quantidade de cheques

Valor cheques

Local entrega

Método de pagamento

Portes de correio

Descontos

Data de entrega

Gera Venda S

Email Reply Automático

Se Método Pagamento for

transferência bancária, fica

em estado pendente. Caso

contrário despoleta acção de

venda.

Alerta de vendaConfirmação de

venda

Fim ProcessoEmail Automático com

ID Order

Email Automático com ID Order

Alerta de venda

Se local de entrega for o

centro

Gera um ID Order

Email Reply

OKRecebe Contacto

de Cliente com

confirmação

N

Fig. 19 – Actividade Venda de cheques – Grandes clientes


88

3.2.4. Actividade Venda de cheques - Pequenos clientes

Sales

ClienteCliente ShoppingShoppingSistema Cheque-Prenda

Verificar lista de

orders

Cheque onSale

para Sold

Recibo

Existem orders

S

Fim Processo

Gera ID Venda

N

Compra de

chequesVerifica Stock

Fim Processo

NOK

Gera ID Venda

Cheque onSale

para Sold

Recibo

OK

Prepara recibo e

cheques para

entrega

Fim Processo

Levantar chequesVerifica Ordem

venda

Mostra ID Order

Já processada

Prepara recibo e

cheques para

entrega

Fim Processo

S

OK NOK

Gera ID Venda

Cheque onSale

para Sold

ReciboN

Fig. 20 – Actividade Venda de cheques - Pequenos clientes


89

3.2.5. Actividade Depósitos

Deposits

TesourariaShoppingSistema Cheque-Prenda

Depositar dinheiro

Agrega talão de

depósito a

Venda/Serviço

Talão de depósito

Valida

agregação

Depósito

confirmado

Confirma

depósito

Fim Processo

Estado Confirmado

Estado Pendente

OK

Estado Validado

OK

Envio para SAP

NOK

NOK

Email diário

Fig. 21 – Actividade Depósitos


90

3.2.6. Actividade Compensações – Centro Comercial

Compensations - Shopping

LojistaSistema Cheque-Prenda Shopping

Compensar

cheque

Verificar Cheque/

Loja

Válido Recusar Cheque Fim Processo

N

Compensação

de cheques

Recibo

Transferência

Recibo

S

Envio para SAP – ID Compensação

Fim Processo

Fim Processo

Entrega dinheiro

NOK

OK


ID Compensação

Fig. 22 – Actividade Compensações – Centro Comercial


91

3.2.7. Actividade Compensações – Central (MKB2B)

Compensations - Central

ClienteMKTB2B Sistema Cheque-Prenda

Compensar

cheques

Lista de cheques

a compensarValida lista de

cheques

Fim ProcessoCompensação

de cheques

Estado Pendente

Documento ACKRecebe ACK

Envia ChequesRecebi

Cheques

Compensação

de cheques Estado Validado

Recibo

Fim Processo


NOKOK

Email

OK

NOK

Verifica

compensação

Listagem Centro/

Loja/Data

Verica

CompensaçãoFim ProcessoNOK

OKRecibo

Verifica

Compensação

transferida

Listagem Centro/

Loja/Data

ID Compensação

Fig. 23 – Actividade Compensações – Central (MKB2B)


92

3.2.8. Actividade Reposição fundo de caixa (Petty-Cash)

Petty-Cash

TesourariaShoppingSistema Cheque-Prenda

Fechar caixa

Agrega compensações

desde o último fecho até

data x ou limite de fundo

de caixa

Estado Pendente

ID Petty-Cash

Valida Petty-

Cash

NOK

Confirma

Petty-CashOK

NOK

Petty-Cash

confirmadoOK

Envio para SAP – ID Petty-Cash

Fim Processo

Processa

pagamento /

Repõe caixa

Fim Processo

Estado Confirmado

Estado Validado

Email diário

Fig. 24 – Actividade Reposição fundo de caixa (Petty-Cash)


93

4. Desenvolvimento

4.1. Cronograma real

Abril

2009

Maio

2009

Jun.

2009

Jul.

2009

Ago.

2009

Set.

2009

Out.

2009

Nov.

2009

Dez.

2009




Implementação

Testes usabilidade

Piloto


Tab. 14 – Cronograma real (a)

Jan.

2010

Feb.

2010

Mar.

2010

Abr.

2010

Mai.

2010

Jun.

2010

Jul.

2010

Ago.

2010

Set.

2010




Implementação

Testes usabilidade

Piloto


Tab. 15 – Cronograma real (b)


94

5. Implementação

5.1. Apresentação e discussão dos resultados

5.1.1. Testes de usabilidade

Do universo Sonae Sierra foi pedido a dez colaboradores para participarem nos testes de

usabilidade de portal que, durante a sua implementação e a cada incremento de

funcionalidade, iriam ser feitos. A escolha destes e os testes afectos a cada um foram

influenciados pela área de função, representando assim os usuários finais do sistema.

Cada teste de usabilidade corresponde a um incremento de funcionalidade do sistema, ao

qual damos o nome de cenário. O usuário para percorrer todo o cenário poderá ter que

cumprir até três tarefas. Por cada tarefa o usuário deverá preencher uma ficha de avaliação,

contendo uma checklist e perguntas de texto para desenvolvimento. Ver Anexos C e D.

Pretendemos por cada cenário, dar o resultado da checklist, tal como as

respostas/indicações dos usuários mais relevantes, que despoletaram uma acção por parte

da equipa de desenvolvimento.

De forma a facilitar e melhor compreender o âmbito de cada cenário, dividimos estes por

cinco grupos de cenários:

Cenários “Apresentação”. O interface do portal é aqui testado.

Cenários “Serviços Core”. Todos os serviços core do portal são aqui testados;

Cenários “Utilitários”. Todos os serviços que apoiam os serviços core do portal são

aqui testados;

Cenários “Reports”. Todos os reports gerados pelo portal são aqui testados;

Cenários “Administração”. Toda a componente de administração do portal é aqui

testada.

5.1.1.1. Cenários “Apresentação”

Cenário “Homepage”


95

Usuários: 2

Data de realização: 09/11/2009

Tarefas por cenário: 1

Fichas de Avaliação: 2

Respostas Checklist:

a. Facilidade de utilização Difícil Fácil

NA 0 1 2 3 4 5

b. Assimilação da informação Difícil Fácil

NA 0 1 2 3 4 5

c. Organização da informação Má Boa

NA 0 1 2 3 4 5

d. Mensagens do sistema Confusas Claras

NA 0 1 2 3 4 5

e. Nomenclatura no interface (botões, títulos

janela, campos,..)

Confuso Claro

NA 0 1 2 3 4 5

f. Layout do interface Confuso Claro

NA 0 1 2 3 4 5

Respostas de Desenvolvimento:

Questão 5 – Aponte as situações onde sentiu alguma dificuldade na utilização do sistema?

Usuário: Dificuldade na percepção do nome de usuário que está em sessão e do

contexto onde está. Talvez a fonte utilizada não seja a mais correcta.

Observações Avaliador: O usuário sentiu alguma dificuldade na leitura dos textos, visto

ter-se mais do que uma vez aproximado do ecrã.

Equipa Desenvolvimento: A fonte de letra utilizada e o seu tamanho estão

institucionalizados. Foi proposto ao usuário pelo avaliador se a letra estando a bold não

iria corrigir a situação. Utilizando um addon de browser, que permite a alteração de

código HTML na página em visualização, foi aprovada a alteração pelo usuário.

Questão 7 – Durante a utilização do sistema sentiu a necessidade de aceder ao menu de

ajuda? Se sim porque?

Usuário: Não.

Questão 8 – Durante a utilização do sistema solicitou a ajuda do avaliador? Se sim porque?


96

Usuário: O logo de imagem de portal diz SierraCentres.networks, não devia dizer

Gift.Certificates.

Equipa Desenvolvimento: A imagem de portal ainda está a ser trabalhada e como tal

utilizámos uma outra imagem, que neste caso partilha as mesmas formas e como tal dá

o mesmo efeito pretendido.

Questão 9 – Acha que a funcionalidade testada atingiu o objectivo para o qual foi

desenvolvida? Explique.

Usuário: Sim, baseia-se no modelo já aplicado noutros portais, o que faz com que o

usuário já esteja familiarizado.

Questão 10 – Sugira melhorias à funcionalidade testada.

Usuário: O logo da Sonae Sierra não está bem definido. Parece que não está nítido.

Deve estar sempre indicado na página o caminho que o usuário percorreu até chegar à

funcionalidade seleccionada no momento.

Equipa Desenvolvimento: Devido à mudança de marca que ocorreu há pouco tempo,

ainda não temos os logos finais com qualidade produtivo. Como tal foi utilizado um logo

provisório. Quanto à segunda questão o usuário refere-se à funcionalidade de

breadcrumb, que será implementada.

Questão 11 – Dê-nos a sua opinião sobre o teste efectuado. Se pretender pode sugerir

melhorias a este.

Usuário: Poderão os próximos testes serem feitos por videoconferência. Podia da

mesma maneira termos o avaliador a controlar remotamente.

Equipa Desenvolvimento: Os usuários escolhidos deverão deslocar-se às instalações da

Sonae Sierra, para numa sala de reunião pré-preparada efectuarem o teste. Notas a

nível comportamental, só possíveis com a presença do factor humano, são factor

essencial.

Cenário “Context”

Usuários: 2




97




NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


janela, campos,..)

Confuso Claro

NA 0 1 2 3 4 5


NA 0 1 2 3 4 5



Usuário: Como a funcionalidade não está disponível ao nível menu, se na descrição do

cenário não houvesse indicação da sua localização, perderia algum tempo a percebê-la.

Equipa Desenvolvimento: Irá ser estudado a possibilidade da funcionalidade contexto,

estar disponível ao nível do menu. No entanto será dado um maior foco ao acesso a esta

funcionalidade na formação de portal.

Questão 6 – Aponte situações onde achou fácil utilizar o sistema.

Usuário: A alteração do contexto é bastante fácil de realizar.



Usuário: Sim, se não soubesse onde estava localizado o acesso a esta função.

Equipa Desenvolvimento: Irá ser estudado a possibilidade da funcionalidade contexto,

estar disponível ao nível do menu. No entanto será dado um maior foco ao acesso a esta

funcionalidade na formação de portal.




98

Usuário: Sim. É simples e a sua utilização é intuitiva.

Cenário “Site Map”

Usuários: 2






NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


janela, campos,..)

Confuso Claro

NA 0 1 2 3 4 5


NA 0 1 2 3 4 5



Usuário: O ecrã parece muito cheio de informação, tornando-se imperceptível qual a

próxima e possível acção sobre este. As funcionalidades de QuickHomePage e

QuickLinks, embora fáceis de entender, deviam de ter alguma ajuda a nível do próprio

campo. Ex: um icon de help ao lado, que ao passarmos em cima dava alguma explicação

do campo.

Equipa Desenvolvimento: No mesmo ecrã existia, além do mapa de menu, um quadro

do lado direito, onde ao passar com o rato sobre qualquer entrada de menu, mostrava

uma explicação da funcionalidade deste. Foi reduzido o tamanho deste quadro dando

mais espaçamento entre todos os módulos de informação, transmitindo uma melhor

percepção e organização da informação. Foi decidido que em todos os campos, que


99

traduzissem algum cuidado na inserção ou selecção de dados, iria ser acrescentando à

direita deste, um icon de help. Ao passarmos com o rato em cima, o sistema mostra uma

breve explicação da funcionalidade, ou de como a preencher.


Usuário: O aproveitamento do Site Map, para a introdução das funcionalidades de

QuickHomePage e QuickLinks, foi bem pensado.



Usuário: Não.


Usuário: Sim. Perguntei qual a razão de no Site Map ter tão poucas entradas, ao

contrário do meu colega, que está a fazer outro teste.

Observações Avaliador: Foi explicado ao usuário que as entradas que vê estão

associadas ao seu perfil. O seu perfil de usuário tem acesso a menos funcionalidades

que o do seu colega.



Usuário: Sim.

5.1.1.2. Cenários “Serviços Core”

Cenário “Help”

Usuários: 2







100

NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


janela, campos,..)

Confuso Claro

NA 0 1 2 3 4 5


NA 0 1 2 3 4 5



Usuário: Os ficheiros de manual estão bem localizados não transmitindo qualquer

dúvida.



Usuário: Não.


Usuário: Sim. Perguntei se o FAQ disponível era o final.

Observações Avaliador: Foi transmitido ao usuário que o FAQ era algo dinâmico.

Durante o ciclo de vida do portal vamos adicionando no FAQ respostas a dúvidas, que

tenham alguma periodicidade no nosso HelpDesk.



Usuário: Sim.

Cenário “Contact Us”

Usuários: 2


101






NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


janela, campos,..)

Confuso Claro

NA 0 1 2 3 4 5


NA 0 1 2 3 4 5



Usuário: O campo Subject deve estar localizado após o campo Reason e antes do campo

Description, não criando confusão no usuário, e creio que é a normal localização deste

tipo de campo. Existe o campo Phone Number, mas não existe o campo Email. Não será

este último mais usual e importante. Eu enviei uma mensagem, e o sistema retornou-

me para a mesma página mas com os dados preenchidos anteriormente a vazio, é

normal? Não deveria ter retornado antes algum tipo de mensagem a dizer que a

mensagem tinha sido posta com sucesso ou erro?

Observações Avaliador: O usuário sentiu alguma dificuldade na utilização do motor de

contacto, quer por falta de informação de como este funciona e por o sistema não

retornar qualquer mensagem de sucesso ou erro. Foi também explicado ao usuário que

o seu endereço de email já está implícito na sessão.

Equipa Desenvolvimento: Será feita a mudança de localização do campo Subject para o

sugerido pelo usuário. O campo email não existe para preencher, pois ele já esta

implícito no usuário em sessão. Irá ser implementado uma mensagem de sistema de

sucesso ou erro no envio de mensagens.


102



Usuário: Sim. Tentei ver se conseguia ver como se comportava o sistema após submeter

uma mensagem. Se retornava algum tipo de mensagem de sucesso ou erro.


Usuário: Sim. A mesma questão reportada na questão 7.



Usuário: Não, precisa de algumas melhorias a nível das mensagens de retorno.


Usuário: Além do já reportado na questão 5, proponho que após o submeter da

mensagem, seja automaticamente gerado um email para a nossa caixa de correio,

contendo uma cópia da nossa mensagem, tal como uma mensagem a dizer que o

pedido foi submetido e que se encontra estado pendente.

Equipa Desenvolvimento: Será implementado.

Cenário “Orders”

Usuários: 2






NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


103


janela, campos,..)

Confuso Claro

NA 0 1 2 3 4 5


NA 0 1 2 3 4 5



Usuário: No cenário F-02, no item 5, é indicado que temos 10 ordens pendentes de

venda. Não deveria indicar que temos 10 ordens já processadas? Podemos cancelar

ordens de venda que não sejam feitas por nós, ou doutro centro? Posso directamente

de uma ordem de compra saltar directamente para a venda dessa mesma Order?

Observação Avaliador: Foi detectado um erro no texto descritivo do cenário F-02, item

5 e foi corrigido na própria folha. Foi pedido esclarecimento sobre o workflow de uma

order para venda.

Equipa Desenvolvimento: O cancelamento de ordens obedece a duas regras: Só pode

ser cancelada uma ordem de um centro, caso o usuário tenha perfil para cancelar e o

seu contexto seja o desse mesmo centro. O usuário que cancela é indiferente. No

entanto será estudada a hipótese de sair um email automático para o criador da ordem

avisando do cancelamento. Quanto à última questão a resposta é sim. Se estiver no

contexto de centro onde foi feita a ordem, numa ordem pendente ao pressionar o botão

Details, aparecerá um botão GoToSales. Ao pressionar este botão uma nova venda será

aberta, já contendo algumas características da ordem pré-seleccionadas.


Usuário: O sistema é fácil de utilizar, embora pense que só a utilização deste poderá

provocar algum tipo de optimização no processo.



Usuário: Sim. Para perceber se posso de uma ordem de compra pendente, entrar logo

na venda correspondente, passando assim a ordem para processada.


Usuário: Sim. Para requerer alguns dados de cenário, esclarecimento sobre uma acção

descrita no cenário e para percepção do workflow de ordem para venda.


104

Equipa Desenvolvimento: Em questões de workflow, será reforçada na formação.



Usuário: Sim.


Usuário: Ao criar uma nova ordem deveria de aparecer ao lado das quantidades de

cheques encomendados o valor facial total desta mesma quantidade, ou seja, o número

de cheques vezes o tipo de cheques. Igualmente no fundo da página deveria estar

disponível o valor total da ordem incluindo cheques e serviços extra.


Questão 11 – Dê-nos a sua opinião sobre o teste efectuado. Se pretender pode sugerir

melhorias a este.

Usuário: Corrigir a descrição do cenário F-02, item 5.

Cenário “Sales”

Usuários: 2






NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


janela, campos,..)

Confuso Claro

NA 0 1 2 3 4 5



105

NA 0 1 2 3 4 5



Usuário: Quando estou a inserir intervalos de numeração, devia de automaticamente a

par do intervalo, aparecer o número de cheques associado a esse intervalo. Por default

quando faço a pesquisa aos cheques inseridos no quadro prévio devia de ser

automaticamente aplicado o filtro de cheques inválidos para ter logo conhecimento

destes. Os cheques inválidos que o sistema retornou não têm descrito qualquer

justificação do porque serem considerados inválidos para venda.

Equipa Desenvolvimento: Será implementado. Quanto à terceira questão é um erro e

será corrigido.


Usuário: A venda de um grupo de cheques e serviços extra é fácil.



Usuário: Não.


Usuário: Sim. Para questionar sobre valores requisitados pelo cenário.



Usuário: Sim.


Usuário: Como já descrito, nos intervalos de numeração inserir a quantidade de

cheques correspondente.


Cenário “Deposits”


106

Usuários: 2






NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


janela, campos,..)

Confuso Claro

NA 0 1 2 3 4 5


NA 0 1 2 3 4 5



Usuário: Na descrição de cenário era pedido para seleccionar 2 vendas ainda sem

depósito associado. Se fosse 10 vendas teríamos que ir uma a uma a seleccionar. Era

interessante existir um botão para seleccionar todas as vendas de uma vez, visto o

normal ser o depósito ser feito antes de abrir a caixa todas as manhas, e logo, todas as

vendas que existem até então deverão pertencer a este.



Usuário: Sim. Para questionar sobre os valores requeridos no cenário.



Usuário: Sim.


107


Usuário: O poder seleccionar todas as vendas de uma só vez.


Cenário “Compensations”

Usuários: 2






NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


janela, campos,..)

Confuso Claro

NA 0 1 2 3 4 5


NA 0 1 2 3 4 5



Usuário: Na área de inserção de cheques, deverá ter algum tipo de ajuda, no que diz

respeito ao formato de inserção na área e à maneira como a introdução é feita. Neste

caso após inserir um número de cheque que deverá ter 12 dígitos, é preciso pressionar a

tecla enter para passar à próxima inserção.

Equipa Desenvolvimento: Será inserido um icon de ajuda, à direita da área de texto,

explicando quer a correcta formatação, quer método de inserção para múltiplos


108

cheques. Este icon de ajuda será replicado em todas funcionalidades do portal que

possuam este componente.


Usuário: Selecção de cheques individualmente ou em grupo é bastante fácil. A

possibilidade de aplicar um filtro e só ver os cheques com erro e qual o erro é bastante

útil



Usuário: Sim. Para perceber o método de inserção de múltiplos de cheques.

Equipa Desenvolvimento: Reforçar o tópico na formação.


Usuário: Sim. Tal como indicado pela descrição de cenário, questionei sobre as

numerações de cheque para compensação e sobre a veracidade dos valores de fee

apresentados pelo motor.



Usuário: Sim.


Usuário: Em caso de existirem cheques com erro, é útil que ao resultado apresentado,

seja aplicado automaticamente o filtro de erro e só estes sejam visualizados. Poderá ser

sempre desactivado o filtro e aparecerem ou todos, ou só os válidos. Será também útil,

que apareça no fim da tabela de resultados o número de cheques já seleccionados,

independentemente do filtro que esteja a ser aplicado no momento.

Equipa Desenvolvimento: Irá ser implementado, sendo estas características replicadas

para todas as funcionalidades que partilham modo semelhante de visualização.

5.1.1.3. Cenários “Utilitários”

Cenário “Cancel Gift Certificates”


109

Usuários: 2






NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


janela, campos,..)

Confuso Claro

NA 0 1 2 3 4 5


NA 0 1 2 3 4 5



Usuário: A funcionalidade é de fácil utilização, não transmitindo qualquer dificuldade ou

dúvida.



Usuário: Não.



numerações de cheque para pesquisa e sobre a listagem apresentada pelo motor.




110

Usuário: Sim.

Cenário “Petty Cash Fund Restitution”

Usuários: 2






NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


janela, campos,..)

Confuso Claro

NA 0 1 2 3 4 5


NA 0 1 2 3 4 5



Usuário: Não é perceptível como se selecciona entre os pedidos pendentes, os

submetidos e os confirmados. O botão para inserir novas declarações de fundos deverá

ter uma aparência de botão, parecendo simplesmente uma frase perdida à direita da

form de pesquisa. Não percebi à primeira vista qual o significado do campo de pesquisa

Restitution Number e qual o tipo de valor que poderá ser inserido neste.

Equipa Desenvolvimento: Irá ser dado mais foco no quadro seleccionado, conseguindo

assim distinguir-se dos outros, fazendo com que o usuário entenda qual está

seleccionado e quais não estão. Quando ao botão para inserção, foi aplicado um estilo

diferente, que permite que este seja distinto e facilmente identificado como botão. Foi

adicionado um icon de ajuda do lado direito do campo Restitution Number, com uma


111

breve explicação deste. Cada fundo de caixa registado gera um Id único, sendo este ou

parte deste possível de inserir no campo anterior para pesquisa.



Usuário: Sim. Para saber o significado e modo de funcionamento do campo Restitution

Number.


Usuário: Sim. Tal como descrito no cenário foi pedido ajuda na confirmação dos

pedidos. Foi também pedida ajuda para esclarecimento no significado do campo

Restitution Number.



Usuário: Sim.


Usuário: Alterar o botão para inserção de fundos de caixa para uma melhor percepção

deste.

Observações Avaliador: No momento foi aplicado um estilo diferente no botão, tendo o

usuário concordado com este.

Equipa Desenvolvimento: Será implementado um estilo diferente no botão.

Cenário “Reception GC Books”

Usuários: 2







112

NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


janela, campos,..)

Confuso Claro

NA 0 1 2 3 4 5


NA 0 1 2 3 4 5



Usuário: A funcionalidade descrita mostra-se de fácil utilização.



Usuário: Não.


Usuário: Sim. Para saber o número de cheque para teste e comentar a mensagem de

erro que o cenário causou.



Usuário: Sim.

Cenário “Gift Certificates Switch”

Usuários: 2





113



NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


janela, campos,..)

Confuso Claro

NA 0 1 2 3 4 5


NA 0 1 2 3 4 5



Usuário: É intuitivo e de fácil utilização.



Usuário: Não.


Usuário: Sim. Questionei sobre os números de cheque a utilizar no cenário, sobre a

mensagem de erro que este causou e sobre a veracidade dos dados apresentados e

documentos gerados pelo sistema.



Usuário: Sim.

Cenário “Compensation Receipts”

Usuários: 2


114






NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


janela, campos,..)

Confuso Claro

NA 0 1 2 3 4 5


NA 0 1 2 3 4 5



Usuário: A utilização não é de difícil entendimento.



Usuário: Não.


Usuário: Sim. Para confirmação sobre a veracidade dos dados apresentados.



Usuário: Sim.


Usuário: Nos resultados apresentados após pesquisa, deveria de aparecer em cada linha

de compensação a quantidade de cheques e o valor total a que se refere essa

compensação. Caso contrário temos que entrar no detalhe de cada compensação para


115

detectar uma específica. Por vezes em compensações da mesma loja associamos o

recibo que queremos pelo valor.

Equipa Desenvolvimento: Será implementado. Esta funcionalidade será implementada

noutras funcionalidades que possuam o mesmo tipo de componente.

Cenário “Compensation Credit Receipts”

Usuários: 2






NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


janela, campos,..)

Confuso Claro

NA 0 1 2 3 4 5


NA 0 1 2 3 4 5



Usuário: Não houve dificuldades na utilização.



Usuário: Não.



116

Usuário: Sim. Para a confirmação sobre a veracidade dos dados apresentados e

documentos gerados.



Usuário: Sim.


Usuário: No campo de pesquisa Receipt Date, o intervalo de pesquisa deve ser da data

corrente, para dois meses atrás. Este intervalo de datas é o mais usual para consulta de

recibos.


Cenário “Search Buyer Companies”

Usuários: 2






NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


janela, campos,..)

Confuso Claro

NA 0 1 2 3 4 5


NA 0 1 2 3 4 5



117


Usuário: A informação gerada e retornada pelo sistema é exposta toda num quadro.

Devido ao espaço ocupado pelo portal a percepção da informação torna-se caótica.

Devia de haver a opção de selecção de colunas a apresentar.

Observação Avaliador: Foi pedido ao usuário que desse uma prioridade de campos que

podiam ou não aparecer. Como todos os campos são precisos, foi proposto que um ou

dois campos aparecessem por meio de popup.

Equipa Desenvolvimento: O espaço ocupado por uma página de portal é fixo, logo não

pode ser aumentado. Toda a informação retornada e exposta no portal tem o seu grau

de importância. Irá estudar-se a possibilidade de um ou mais campos (Ex: morada)

serem dados através de popup quando passamos por cima do nome do cliente.



Usuário: Não.


Usuário: Sim. Para a confirmação sobre a veracidade dos dados apresentados e

documentos gerados.



Usuário: Sim.


Usuário: Ter a possibilidade de escolher os campos a aparecer, ou esconder da

visualização directa.


Cenário “Sales Receipts”

Usuários: 2



118





NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


janela, campos,..)

Confuso Claro

NA 0 1 2 3 4 5


NA 0 1 2 3 4 5



Usuário: O sistema é fácil de utilizar.



Usuário: Não.


Usuário: Sim. Para a confirmação sobre a veracidade dos resultados obtidos e

documentos gerados.



Usuário: Sim.

Cenário “Payment Confirmation”


119

Usuários: 2






NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


janela, campos,..)

Confuso Claro

NA 0 1 2 3 4 5


NA 0 1 2 3 4 5



Usuário: Não houve qualquer problema na utilização.



Usuário: Não.


Usuário: Sim. Para confirmação da veracidade dos dados.



Usuário: Sim.

Cenário “Mall Stores Participation”


120

Usuários: 2






NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


janela, campos,..)

Confuso Claro

NA 0 1 2 3 4 5


NA 0 1 2 3 4 5



Usuário: Qual a justificação para o nome do campo de filtro para pesquisa ser Word?

Observação Avaliador: Foi explicado ao usuário o porque do campo ter o nome que

tem, e embora tenha tentado encontrar um novo nome, aceitou o inicial no fim.

Equipa Desenvolvimento: Este único campo faz a pesquisa por três campos, e como tal

a definição de campo ficou Word de pesquisa, embora estejamos abertos a outro nome.


Usuário: Não mostrou qualquer dificuldade na utilização.



Usuário: Sim. Para saber o significado e valores possíveis para o campo Word.

Equipa Desenvolvimento: Será reforçada esta questão na formação.


121


Usuário: Sim. Para a obtenção de uma data e nib para inserção de loja, tal como descrito

no cenário.



Usuário: Sim.


Usuário: Talvez um nome mais específico para o campo de pesquisa.

Equipa Desenvolvimento: Será implementado se indicado pela organização.

Cenário “Order/Stock Management”

Usuários: 2






NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


janela, campos,..)

Confuso Claro

NA 0 1 2 3 4 5


NA 0 1 2 3 4 5



122


Usuário: Na mesma encomenda para a Casa da Moeda não é possível inserir vários tipos

de cheque, ou seja, para o sistema uma encomenda tem associado só um tipo de

cheques. Isto deve ser mudado porque o próprio template gerado para a Casa da

Moeda tem essa possibilidade. A folha de template não deverá estar só disponível após

a sua geração, não tendo mais acesso a esta. Deverá estar disponível para download na

linha da encomenda associada no quadro de encomendas já feitas.

Equipa Desenvolvimento: A primeira situação tem toda a lógica e tal como a segunda

reportada será implementada.



Usuário: Sim. Só para confirmar que não era possível adicionar mais que um tipo de

cheque a uma mesma encomenda.


Usuário: Sim. Para confirmar a questão 7, e para questionar sobre a veracidade dos

dados retornados pelo sistema e documentos gerados.



Usuário: Sim, embora algumas melhorias tenham que feitas.


Usuário: Já descritas na questão 5. No entanto gostaria de propor que ao alocar um

conjunto de cheques para um dado centro, fosse gerado um email automático para o

responsável desse mesmo centro a avisar que serão entregues cheques ao centro, a sua

numeração e valor total. No campo To seria dada a hipótese de acrescentarmos mais

endereços de email. Quando estou a fazer encomenda de cheques, ao inserir uma dada

quantidade para um dado tipo de cheque, devia de aparecer ao mesmo tempo à direita

da quantidade, o valor facial total, ou seja, número de cheques vezes o tipo. Igualmente

em baixo deveria de aparecer o valor total facial de todos os cheques já seleccionados,

ou seja, um resumo da encomenda.



123

5.1.1.4. Cenários “Reports”

Cenário “Sales by Centre/Country”

Usuários: 2






NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


janela, campos,..)

Confuso Claro

NA 0 1 2 3 4 5


NA 0 1 2 3 4 5



Usuário: Demorou mais ou menos 20 segundos a ser gerado o report. Isto para o

utilizador final poderá ser factor de desmotivação. Quando após pesquisa o motor

retorna zero resultados deveria de aparecer uma mensagem com esse facto. O não

aparecer de nenhuma mensagem, poderá fazer com que o usuário pense que o motor

ainda está a retornar dados e fique à espera. Deverá de aparecer algum tipo de

“ampulheta” durante o gerar do report, para assim indicar ao usuário que o motor está

a processar.

Observação Avaliador: O usuário ao utilizar o motor de reports pela segunda vez, com

outros dados de pesquisa o motor revelou-se mais rápido, embora tenha chegado aos

10 segundos de demora.


124

Equipa Desenvolvimento: O motor de reports, à medida que é usado vai aumentando a

sua performance através da reutilização de dados em log. No entanto iremos estar

atentos a locks em SQL para possível optimização das Queries. Será implementada uma

mensagem de alerta para quando a pesquisa retornar zero valores, não gerando

qualquer tipo de report. Será igualmente implementado um género de Waiting Status

Bar, dando a indicação que o report está a ser gerado.


Usuário: Gostei da opção de exportação de report para excel, onde podemos trabalhar

os dados obtidos de uma forma mais célere.



Usuário: Não.


Usuário: Sim. Tal como indicado pela descrição de cenário, questionei sobre as datas

para pesquisa e sobre a veracidade dos dados apresentados pelo report gerado.



Usuário: Sim


Usuário: Haverá alguma forma dos campos apresentados pelo report serem dinâmicos.

Ou seja, de um conjunto de colunas possíveis para apresentar poder escolher quais a

imprimir no report.

Equipa Desenvolvimento: Será estudada essa opção, mas só para uma segunda fase de

desenvolvimento do portal.

Cenário “Stocks by Centre/Country”

Usuários: 2




125




NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


NA 0 1 2 3 4 5

e. Nomenclatura no interface ( botões, títulos

janela, campos, ..)

Confuso Claro

NA 0 1 2 3 4 5


NA 0 1 2 3 4 5




Usuário: Não.


Usuário: Sim. Tal como indicado pela descrição de cenário, questionei sobre a

veracidade dos dados apresentados pelo report gerado.



Usuário: Sim.


Usuário: Acho aconselhável que juntamente com as quantidades de stock, seja impresso

o valor a que corresponde essa mesma quantidade. É de notar que para obter este valor

bastará ao usuário multiplicar o valor do header de coluna pela quantidade, mas por

exemplo, para quantidades grandes, obter o valor a que correspondem 1243 cheques

de 5€, poderá não ser de rápida resposta.

Equipa Desenvolvimento: Irá ser implementado.


126

Cenário “Best Seller by Centre/Country”

Usuários: 2






NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


janela, campos,..)

Confuso Claro

NA 0 1 2 3 4 5


NA 0 1 2 3 4 5



Usuário: A correcta definição do campo Client. O tempo de resposta do sistema quando

inserimos o tipo de Client como Public e o centro de pesquisa o Centro Colombo, chega

a 30 segundos, para datas de 1 mês de intervalo.

Equipa Desenvolvimento: Irá ser inserido um icon de ajuda ao lado do campo Client,

com uma breve explicação deste. Esta ajuda será replicada em todos os reports que têm

este campo de selecção. Quanto ao tempo de resposta é normal, visto estarmos a pedir

que o sistema nos retorne todos os vendedores, ordenados pelo valor total de vendas

efectuadas a particulares, durante um mês e no Centro Colombo, que regista por dia

várias dezenas de compras a particulares. Será no entanto revista a query com vista a

uma possível optimização.


127



Usuário: Sim. Significado do campo Client.

Equipa Desenvolvimento: Será reforçada na formação o significado deste campo.



para pesquisa, sobre a veracidade dos dados apresentados pelo report gerado e sobre o

correcto significado do campo Client.



Usuário: Sim.


Usuário: Será que este tipo de report não faz só sentido para clientes Empresa, ou seja,

campo Client seleccionado com a opção Corporate. Pelas quantidades de vendas feitas a

estes, que são aos milhares de uma só vez, os vendedores que só vendem a particulares

ficarão sempre para último no report. Mensagem de ajuda para os campos menos

perceptíveis.

Equipa Desenvolvimento: O report irá continuar com as duas opções de Client, embora

a opção Corporate seja a seleccionada por default. Os campos de pesquisa utilizados

que se enquadrem fora dos campos de report comum irão ter uma ajuda personificada.

Cenário “Best Client by Centre/Country”

Usuários: 2






NA 0 1 2 3 4 5


128


NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


janela, campos,..)

Confuso Claro

NA 0 1 2 3 4 5


NA 0 1 2 3 4 5




Usuário: Não.



para pesquisa e sobre a veracidade dos dados apresentados pelo report.



Usuário: Sim.


Usuário: Nos resultados de pesquisa devia de haver a hipótese de ter os dados

ordenados, ou pelo NIF de empresa cliente, ou pelo seu nome. Nos dados de cliente

poderia igualmente aparecer a data da última compra, o número de compras e o valor

médio de todas até à data.

Equipa Desenvolvimento: Será implementado na form de pesquisa o campo de escolha

para ordenação por NIF ou nome de cliente. Todos os outros pedidos serão

implementados no report.

Cenário “Certificate Type w/Best Sales by Centre/Country”


129

Usuários: 2






NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


janela, campos,..)

Confuso Claro

NA 0 1 2 3 4 5


NA 0 1 2 3 4 5




Usuário: Não.



para pesquisa e sobre a veracidade dos dados apresentados pelo report.



Usuário: Sim.


Usuário: Poderá ser adicionado à linha de tipo de cheque, a quantidade deste vendido

no período de tempo seleccionado.



130

Cenário “Avg Time Between Orders and Sales by Centre/Country”

Usuários: 2






NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


janela, campos,..)

Confuso Claro

NA 0 1 2 3 4 5


NA 0 1 2 3 4 5




Usuário: Não.



veracidade dos dados apresentados pelo report.



Usuário: Sim.



131

Usuário: O tempo médio é dado no report em dias. Quando temos mais de um mês

aparece 45 dias. A partir de 1 mês deveria de aparecer x meses e y dias.

Equipa Desenvolvimento: Será implementado nas duas vertentes. Continuará a

aparecer o número de dias, seguido do correspondente em x anos, y meses e z dias.

Cenário “Avg Time for Stock Rotation by Centre/Country”

Usuários: 2






NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


janela, campos,..)

Confuso Claro

NA 0 1 2 3 4 5


NA 0 1 2 3 4 5



Usuário: Face ao report Avg Time Between Orders and Sales by Centre/Country, não vejo

a utilidade deste report. Se aplicarmos as mesmas datas que no report referido

anteriormente, os valores diferem em pouco.

Observação Avaliador: O usuário a quando a correcta explicação por parte do avaliador

da funcionalidade, cumpriu o cenário.


132

Equipa Desenvolvimento: O report refere-se ao período desde que o cheque chega ao

centro, até à sua compensação e fim de vida, ao contrário do report anterior que apenas

se refere ao período entre a sua ordem de venda e a sua venda efectiva.



Usuário: Sim. Para entendimento do cenário.



veracidade dos dados apresentados pelo report. Igualmente sobre o significado deste

report.



Usuário: Sim.


Usuário: Verificar se este tipo de report é mesmo necessário. Será que não bastava, e

em substituição deste report e do anterior fazer um único report que aceitasse

intervalos de estado do cheque, e desse simplesmente o Avg Time entre estes.

Equipa Desenvolvimento: Será implementado numa segunda fase de projecto.

Cenário “Certificates Overview”

Usuários: 2






NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


133


NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


janela, campos,..)

Confuso Claro

NA 0 1 2 3 4 5


NA 0 1 2 3 4 5



Usuário: Atendendo aos intervalos de numeração especificados pelo avaliador, o motor

revelou-se lento a construir o report. Apesar de o motor mostrar uma mensagem de

waiting, pode-se tornar desmotivante para o usuário final.

Equipa Desenvolvimento: Os intervalos de numeração retornaram os detalhes de 10 mil

cheques, o que se traduz em algum tempo de processamento. Irá ser estudada a própria

query com vista à sua optimização.


Usuário: Devido a quantidade e importância dos dados retornados pelo sistema, é de

grande utilidade a possibilidade de se poder fazer a exportação para excel.



Usuário: Não.



numerações de cheque para pesquisa e sobre a veracidade dos dados apresentados

pelo report.



Usuário: Sim.


134

5.1.1.5. Cenários “Administração”

Cenário “Configure Application”

Usuários: 2






NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


NA 0 1 2 3 4 5


janela, campos,..)

Confuso Claro

NA 0 1 2 3 4 5


NA 0 1 2 3 4 5



Usuário: Os campos de parâmetros de configuração deveriam ter algum tipo de ajuda.

Talvez o já aplicado em anteriores funcionalidades, como o icon de ajuda à direita do

campo. Na definição dos perfis, deveria ser dada a indicação de quais as funcionalidades

do portal a que cada perfil dá acesso. Em cada módulo de configuração existe um botão

Save, no qual carrego para fazer a alteração. No entanto se não carregar no botão Save,

localizado no final da página a alteração não é efectivada no portal. Qual a razão deste

comportamento? Não deveria só haver um único Save?

Equipa Desenvolvimento: Os icons de ajuda serão implementados, embora se pense

que quem tem acesso a esta página é administrador de portal. Logo tem pleno

conhecimento do significado do parâmetro e consequências de cada alteração. Irá ser


135

implementado uma caixa de informação associada ao perfil onde irá ter a indicação dos

acessos afectos a cada um. O sistema de dois Save permite fazer um duplo check da

alteração estando o primeiro também ligado à validação dos campos. Poderemos no

entanto a quando o primeiro Save dar a indicação ao usuário que deverá pressionar o

outro Save para efectivar a alteração.


Usuário: Gostei da facilidade com que alteramos tipos de cheque por país.



Usuário: Sim. Para entendimento dos parâmetros de configuração.

Equipa Desenvolvimento: Irá ser reforçada esta componente na formação de

administrador.


Usuário: Sim. Para entendimento de alguns campos, embora não estivessem definidos

no cenário.



Usuário: Sim.


Usuário: Mensagens de ajuda para entendimento de alguns campos.

5.1.2. Sumário

Durante o processo de desenvolvimento de software foram preenchidos noventa

questionários, que visavam avaliar as funcionalidades do sistema em implementação no

contexto de um cenário apresentado ao usuário.

Além de algumas perguntas de resposta rápida ou desenvolvimento, incluiu-se na avaliação,

uma checklist que o usuário teria que preencher de acordo com o seu grau de concordância.


136

O intervalo de concordância toma valores de 0 a 5, indo respectivamente do mais negativo

ao mais positivo.

Esta checklist era constituída por seis questões, das quais passamos a apresentar os

resultados.

Graf. 1 - Checklist – Variação Facilidade de utilização

0

1

2

3

4

5

6

09

-11

-09

24

-11

-09

09

-12

-09

24

-12

-09

08

-01

-10

23

-01

-10

07

-02

-10

22

-02

-10

09

-03

-10

24

-03

-10

08

-04

-10

23

-04

-10

08

-05

-10

23

-05

-10

07

-06

-10

22

-06

-10

07

-07

-10

Checklist - Variação Facilidade de utilização

0 0 0 0

11

21

58

0

10

20

30

40

50

60

70

NA 0 1 2 3 4 5

Checklist - Respostas Facilidade de utilização


137

Graf. 2 - Checklist – Respostas Facilidade de utilização

Analisando os gráficos 1 e 2, podemos tomar como facto que a cada avaliação a média de

satisfação foi sempre superior a 3, o que teve um impacto positivo no trabalho realizado

pela equipa de desenvolvimento. A facilidade de utilização do portal sempre foi um dos

principais objectivos desta equipa.

São exemplo de questões levantadas pelos usuários, que afectaram o grau de satisfação na

facilidade de utilização do portal:

Icons de ajuda. Foi implementada esta feature, com vista a dar ao usuário de portal

uma definição breve, sobre um dado campo de preenchimento ou selecção. Este icon

ficou posicionado uniformemente à direita do campo. A escolha de quais os campos

a terem esta funcionalidade extra dependeu sempre da avaliação feita pelo usuário;

Posicionamento dos campos. Alguns campos de pesquisa e de informação foram

reposicionados, como forma de não alteração de hábitos do usuário. Como exemplo

podemos referir na funcionalidade Contact Us, o campo Subject. Foi pedido que este

campo ficasse imediatamente antes do campo Description, para assim manter

alguma coerência com a caixa de novo email no Outlook;

Estilo aplicado a botões. Foi alterado o estilo aplicado a dados botões, pois para o

usuário final, um botão é um botão, e querem que este se pareça como tal;

Novas features na geração de reports. Aplicação da componente de Waiting Status

como forma de transmitir informação de estado do sistema ao usuário. Optimização

da query para um resultado mais rápido.

Todas as alterações, implicaram a introdução de novos Sprints no plano de desenvolvimento,

que não tiveram impacto no planeamento geral.

É igualmente importante referir que todas as alterações propostas e implementadas foram

replicadas nas novas funcionalidades desenvolvidas posteriormente.


138

Graf. 3 - Checklist – Variação Assimilação da informação

Graf. 4 - Checklist – Respostas Assimilação da informação

Analisando os gráficos 3 e 4, podemos tomar como facto que a média de satisfação foi quase

sempre superior a 4. A equipa de desenvolvimento encarou como bastante positivo os

resultados obtidos, pois conseguiu através do portal produzir o conhecimento correcto ao

usuário.

0

1

2

3

4

5

6

09

-11

-09

24

-11

-09

09

-12

-09

24

-12

-09

08

-01

-10

23

-01

-10

07

-02

-10

22

-02

-10

09

-03

-10

24

-03

-10

08

-04

-10

23

-04

-10

08

-05

-10

23

-05

-10

07

-06

-10

22

-06

-10

07

-07

-10

Checklist - Variação Assimilação da informação

2 0 0 0

6

19

63

0

10

20

30

40

50

60

70

NA 0 1 2 3 4 5

Checklist - Respostas Assimilação da informação


139


assimilação de informação:

Utilização de um campo de nome Restitution Number, o que provocou confusão no

usuário;

Utilização de vários componentes, que incorrectamente espaçados entre estes,

provocava confusão no interface;

Nas tabelas de resultados de pesquisa, a utilização de demasiadas colunas, poderá

implicar um maior esforço para assimilar a informação obtida.





Graf. 5 - Checklist – Variação Organização da informação

0

1

2

3

4

5

6

09

-11

-09

24

-11

-09

09

-12

-09

24

-12

-09

08

-01

-10

23

-01

-10

07

-02

-10

22

-02

-10

09

-03

-10

24

-03

-10

08

-04

-10

23

-04

-10

08

-05

-10

23

-05

-10

07

-06

-10

22

-06

-10

07

-07

-10

Checklist - Variação Organização da informação


140

Graf. 6 - Checklist – Respostas Organização da informação

Analisando os gráficos 5 e 6, podemos tomar como facto que a média de satisfação foi

superior a 3. Como a informação deverá estar organizada é uma questão importante na

construção de interfaces, com vista a acelerar a aprendizagem pelo usuário.


organização de informação:

A utilização de tamanhos de fonte pequenos em links ou textos de informação, não

promove a atenção do usuário sobre estes;

A não existência da funcionalidade breadcrumb, o que motivava que o usuário se

pudesse perder na navegação do portal;

O correcto espaçamento entre componentes, como forma de promover cada um

deles ao usuário.





2 0 0 0

4

29

55

0

10

20

30

40

50

60

NA 0 1 2 3 4 5

Checklist - Respostas Organização da informação


141

Graf. 7 - Checklist – Variação Mensagens do sistema

Graf. 8 - Checklist – Respostas Mensagens do sistema


superior a 3. É condição de boa usabilidade a resposta do sistema a uma acção por parte do

usuário.

0

1

2

3

4

5

6

09

-12

-09

21

-12

-09

02

-01

-10

14

-01

-10

26

-01

-10

07

-02

-10

19

-02

-10

03

-03

-10

15

-03

-10

27

-03

-10

08

-04

-10

20

-04

-10

02

-05

-10

14

-05

-10

26

-05

-10

07

-06

-10

19

-06

-10

01

-07

-10

Checklist - Variação Mensagens do sistema

6 2 0 0

5

13

64

0

10

20

30

40

50

60

70

NA 0 1 2 3 4 5

Checklist - Respostas Mensagens do sistema


142

São exemplo de questões levantadas pelos usuários, que afectaram o grau de satisfação nas

mensagens de sistema:

A não existência de tooltips associadas a campos de difícil entendimento ou

preenchimento;

Na geração de reports quando o sistema retorna 0 resultados, deveria dar ao usuário

a indicação que retornou 0 resultados;

Durante a geração de reports, o sistema deve dar a indicação através de um

WaitingStatus, que o motor está a processar.





Graf. 5 - Checklist – Variação Nomenclatura

0

1

2

3

4

5

6

Checklist - Variação Nomenclatura


143

Graf. 10 - Checklist – Respostas Nomenclatura


superior ou igual a 4. Este média deve-se principalmente à utilização neste portal de uma

imagem já firmada como corporativa e presente noutros portais. O estilo de frase utilizado

em mensagens de sistema, as cores usadas, a localização de componentes, já estava

intrínseco ao usuário.


nomenclatura usada:

A localização de dados botões na interface fez com que o estilo usado para estes, não

fosse benéfico para o focus deste.





0 0 0 0 0

16

74

0

10

20

30

40

50

60

70

80

NA 0 1 2 3 4 5

Checklist - Variação Nomenclatura


144

Graf. 11 - Checklist – Variação Layout do interface

Graf. 12 - Checklist – Respostas Layout do interface


superior ou igual a 3. Este média deve-se principalmente à utilização neste portal de uma

imagem já firmada como corporativa e presente noutros portais.

0

1

2

3

4

5

6

Checklist - Variação Layout do interface

0 0 0 0 4

11

75

0

10

20

30

40

50

60

70

80

NA 0 1 2 3 4 5

Checklist - Variação Layout do interface


145

São exemplo de questões levantadas pelos usuários, que afectaram o grau de satisfação do

layout de interface usado:

A utilização de um novo tipo de componente – tabelas sobrepostas – provocou

alguma confusão, visto o usuário não conseguir distinguir qual era o Tab

seleccionado no momento e correspondente a tabela visível.





Graf. 13 – Checklist – Variação All values

0

1

2

3

4

5

6

Checklist - Variação All values


146

Graf. 14 – Checklist – Variação All values

Pelo gráficos 13 e 14, e analisando todas as respostas obtidas por checklist, podemos

considerar como muito positiva a avaliação feita ao portal pelos usuários. A média de

satisfação obtida foi superior a 3, o que para a equipa de desenvolvimento foi factor de

motivação.

Ao mesmo tempo todas as respostas e sugestões obtidas pela ficha de avaliação revelaram-

se de grande utilidade. Foram estas que juntamente com as observações dadas pelo

avaliador, tiveram como consequência propostas que a equipa de desenvolvimento

converteu em Sprints, como forma de melhoria à qualidade do software.

5.2. Cronograma previsto vs. real

O cronograma real face ao previsto apresenta um atraso com desvio de cinco meses. Este

atraso deveu-se à conjuntura económica e financeira internacional vivida no ano de 2009,

que teve forte impacto no valor dos activos da Sonae Sierra em vários países.

Esta crise levou a que a empresa se resguardasse e adiasse por alguns meses o início de

alguns projectos. Entre estes encontrava-se o projecto Portal Cheques-Prenda Sonae Sierra.

Felizmente passados alguns meses e face à retoma económica do último semestre de 2009,

o projecto foi retomado no penúltimo mês deste mesmo ano.

10 2 0 0 30

109

389

0

50

100

150

200

250

300

350

400

450

NA 0 1 2 3 4 5

Checklist - Respostas All values


147

Quanto à duração temporal das várias tarefas de processo, não houve qualquer alteração

significativa, não se esperando igualmente qualquer alteração nas tarefas planeadas para o

futuro.


148

6. Desenvolvimentos futuros

Como possíveis desenvolvimentos futuros, acreditamos que estes terão como base três

áreas de intervenção:

Área de Reports. Terá a maior fatia associada a uma segunda e terceira fase de

desenvolvimentos sobre o portal. Novos Reports como forma de apoio à decisão e

ajuda à operação;

Área de Operação. Acreditamos igualmente que a utilização contínua das

funcionalidades de operação de portal (Ordens de compra, Vendas, etc.) irá provocar

recomendações à alteração e optimização do workflow de portal;

Motor de IA. Algoritmos de inteligência artificial como forma de apoiar o usuário na

tomada de decisão (encomenda de x número de cheques, etc.) irão estar associados

a uma segunda ou terceira fase de desenvolvimento.


149

Capítulo V – Conclusões

Todo o projecto Portal Cheques-Prenda Sonae Sierra foi abordado cumprindo uma

metodologia ágil de desenvolvimento, o método Scrum.

A escolha desta metodologia ágil deveu-se a:

Facilidade de reacção à mudança. O apuramento dos requisitos de sistema rodeou-

se de incertezas, notando-se que o usuário só esteve verdadeiramente ligado à

ferramenta quando a conheceu e começou a usar. Esta interacção só teve lugar a

quando dos testes de usabilidade, tendo aí surgido propostas à mudança;

Todo o processo de desenvolvimento centrado na qualidade do software. O portal

está associado a um negócio sensível para a Sonae Sierra. Este vai estar online 24

sobre 24 horas, 365 dias por ano. Foi preocupação nossa dotar o portal de

mecanismos de gestão de risco, tendo sido dedicado a este tema grande parte do

tempo, em detrimento de uma documentação completa e detalhada;

Transmissão contínua de valor do portal. Esta abordagem de desenvolvimento

incentiva ao incremento da funcionalidade. A cada incremento, ao usuário final, foi

transmitido que aquela funcionalidade tipo já se encontrava a funcionar, passando-se

assim ao desenvolvimento da próxima. O incremento de funcionalidade

correspondeu assim ao incremento de valor dado pelo usuário ao produto já

desenvolvido;

Baixo custo. O método aplicado apresenta um custo baixo, cumprindo os

pressupostos apresentados na análise Custo-benefício.

Como plano de projecto, dividimos o projecto em três processos ordenados temporalmente:

1. Processo de Negócio. Envolveu tudo o que preparou, aprovou e delimitou o processo

de desenvolvimento de software;

2. Processo de Desenvolvimento de Software. Envolveu a construção do software;

3. Processo de Operação/Manutenção. Envolveu todo o pós-desenvolvimento de

software.

É condição que os três processos sejam completos para o projecto estar finalizado. Como tal,

ainda não podemos considerar hoje o projecto finalizado. Tendo já sido concluídos os

processos de Negócio e de Desenvolvimento de Software, o processo de

Operação/Manutenção ainda está decorrer. Está dependente da disponibilidade da equipa

de formação e usuários finais para a marcação de formações e da conclusão da

documentação de apoio e manuais. É expectável que a conclusão deste processo se estenda

para Outubro, embora estejamos continuemos apontar para o fim deste mês.


150

Acreditando que a usabilidade de um sistema é condição essencial para a sua aceitação pelo

usuário, e querendo cumprir um dos requisitos base de escolha da metodologia ágil – a

interacção com o usuário final durante a implementação – implementámos testes de

usabilidade a cada incremento de funcionalidade.

Sabemos que a elaboração e realização de testes de usabilidade aplicados a um sistema são

indicador infalível para problemas que poderão ocorrer a quando a sua passagem a

produtivo, tendo sido estes considerados como parte integrante do processo de

desenvolvimento. Como tal pedimos a dez colaboradores para participarem, sendo que cada

teste foi feito somente por dois colaboradores. A escolha destes foi influenciada pela área de

função, representando assim os usuários finais do sistema.

Cada teste de usabilidade correspondeu a um incremento de funcionalidade do sistema, ao

qual demos o nome de cenário. O entendimento deste cenário e o seu correcto

cumprimento, foram avaliados quer por um avaliador pertencente à equipa de

desenvolvimento, quer pelo próprio usuário através de fichas de avaliação. Cada ficha

continha uma checklist e perguntas para desenvolvimento.

Foram estas fichas de avaliação, que pela análise da checklist e observações de usuário e

avaliador, que nos permitiram introduzir correcções, melhorias e optimizações ao sistema.

Tais indicadores permitem-nos hoje responder com satisfação ao principal objectivo deste

trabalho que era o de apresentar uma aplicação simples, intuitiva e agregadora de todos os

módulos que constituem o ciclo de vida de um Cheque-Prenda.

Respondendo às questões de investigação levantadas neste trabalho:

Qual o melhor processo de desenvolvimento de software a aplicar de forma a obter

um conjunto de resultados bem definidos garantindo a qualidade de standards e

requisitos, nos tempos previstos e dentro dos custos definidos pela organização?

Pensamos que o processo por nós utilizado, uma metodologia ágil de

desenvolvimento, mostrou-se como o mais indicado neste tipo de projecto. A

facilidade com que este se adapta à mudança, a qualidade de software que impõe e a

ligação permanente com o usuário final, foi fundamental no sucesso deste projecto.

Por outro lado a aplicação deste método não atrasou os prazos propostos no estudo

de viabilidade apresentando, e nem apresentou alterações ao custo proposto na

análise Custo-benefício.

Qual a melhor estratégia de desenho de forma a procurar a simplificação de

processos, procurando atingir o conceito de self explained?


151

Os testes de usabilidade feitos a cada incremento de funcionalidade e ligação única

com o cliente que o método de desenvolvimento aplicado propõe, foram

fundamentais na simplificação de processos, rápida aprendizagem e interface

intuitivo. Todos estes promoveram o conceito de self explained.

Poderá a IA, substituir o humano em alguns módulos deste ciclo de vida do Cheque-

Prenda? Como exemplo refiro a questão das encomendas de cheques à Casa da

Moeda conforme as necessidades e estatística do passado;

Por opção da organização este conceito de IA proposto inicialmente pela equipa de

desenvolvimento ficou adiado para uma segunda fase de desenvolvimento sobre o

portal. Contudo vários reports foram fabricados de forma a apoiar o utilizador na

decisão final. Como exemplo, temos um report que indica qual o tempo médio entre

o cheque ser posto à venda e o ser vendido. Como tal a partir destes valores

poderemos extrapolar vários elementos como por exemplo os stocks mínimos para

cada centro. Um motor que beba destes dados e promova a decisão automática, está

portanto num plano futuro de desenvolvimento.

Testes de qualidade do software e uma correcta gestão do risco, como forma de

minorar o erro e minimizar o tempo e recursos de manutenção.

A escolha de uma metodologia ágil promoveu a qualidade do software desenvolvido,

sendo a qualidade uma das bases e requisitos do sucesso deste tipo de metodologia.

Para a equipa de desenvolvimento o projecto desenvolvido satisfaz as necessidades

do nosso cliente sendo fácil de usar, rápido e fácil de modificar, tendo sido bastante

testado quer por nós, quer por usuários finais da aplicação. Todas estas

características são em nosso entender suficientes para considerarmos o trabalho

desenvolvido como software de qualidade.


152

Referências bibliográficas

ISO (1997). ISO 9241-11: Ergonomic requirements for office work with visual display terminals

(VDTs). Part 11 — Guidelines for specifying and measuring usability, Genève, International

Organization for Standardization.

Laboratório de Utilizabilidade da Informática (2008). ErgoList. Universidade Federal de Santa

Catarina, Florianópolis, SC. http://www.labiutil.inf.ufsc.br/ergolist/. Acedido a 28 Novembro de 2010.

OCDE and Eurostat (1996).

“Manual de Oslo”. Directrizes para Coleta e Interpretação de Dados sobre a Inovação.

http://www.finep.gov.br/dcom/brasil_inovador/arquivos/manual_de_oslo/prefacio.html. Acedido a

28 Novembro de 2010.

Manifesto for Agile Software Development (2004). http://www.agilemanifesto.org/.

Acedido a 28 Novembro de 2010.

Vmware Virtualization. http://www.vmware.com. Acedido a 28 Novembro de 2010.

Principles behind the Agile Manifesto (2004). http://www.agilemanifesto.org/principles.html.

Acedido a 28 Novembro de 2010.

Agile Alliance. http://www.agilealliance.org. Acedido a 28 Novembro de 2010.

Extreme Programming: A gentle introduction (2009). http://www.extremeprogramming.org. Acedido

a 28 Novembro de 2010.

Anacleto G. and Floriano P. (2008). Planejando testes de usabilidade: o que (e o que não) fazer.

http://imasters.uol.com.br/artigo/9172/usabilidade/planejando_testes_de_usabilidade_o_que_e_o

_que_nao_fazer/. Acedido a 28 Novembro de 2010.

Beck, K. (1998). Extreme Programming: A humanistic discipline of software development. Fundamental Approaches to Software Engineering. E. Astesiano. Berlin, Springer-Verlag Berlin. 1382: 1-6. Boehm, B. W. (1988). "A Spiral Model of Software-Development and Enhancement." Computer 21(5): 61-72. Budde, R. and H. Zullighoven (1990). Prototyping revisited. CompEuro '90. Proceedings of the 1990 IEEE International Conference on Computer Systems and Software Engineering. Charette, R. (2001). "Fair Fight? Agile Versus Heavy Methodologies." Cutter Consortium 19.

http://www.labiutil.inf.ufsc.br/ergolist/

http://www.finep.gov.br/dcom/brasil_inovador/arquivos/manual_de_oslo/prefacio.html

http://www.agilemanifesto.org/

http://www.vmware.com/

http://www.agilemanifesto.org/principles.html

http://www.agilealliance.org/

http://www.extremeprogramming.org/

http://imasters.uol.com.br/artigo/9172/usabilidade/planejando_testes_de_usabilidade_o_que_e_o_que_nao_fazer/

http://imasters.uol.com.br/artigo/9172/usabilidade/planejando_testes_de_usabilidade_o_que_e_o_que_nao_fazer/


153

Galler, B. A. (1969). "Nato and Software Engineering." Communications of the Acm 12(6): 301-&. Gordon, V. S. and J. M. Bieman (1995). "Rapid Prototyping - Lessons Learned." Ieee Software 12(1): 85-95. Henderson, R. M. and K. B. Clark (1990). "Architectural Innovation - the Reconfiguration of Existing Product Technologies and the Failure of Established Firms." Administrative Science Quarterly 35(1): 9-30. Highsmith, J. and A. Cockburn (2001). "Agile software development: The business of innovation." Computer 34(9): 120-122. International, S. G. (1995). CHAOS: Project Failure and Success Research Report. Dennis, Massachusetts, Standish Group International. Johannessen, J. A., B. Olsen, et al. (1999). "Aspects of innovation theory based on knowledge-management." International Journal of Information Management 19(2): 121-139. Kaufman, J. (2006). "Practical Usability Testing.". http://www.digital-web.com/articles/practical_usability_testing/. Acedido a 28 Novembro de 2010. Ken, S. (2002). Scrum and Agile 101. Proceedings of the Second XP Universe and First Agile Universe Conference on Extreme Programming and Agile Methods - XP/Agile Universe 2002, Springer-Verlag. Lester, D. H. (1998). "Critical success factors for new product development." Research-Technology Management 41(1): 36-43. Meyers, P. (2010). "25-point Website Usability Checklist.". http://www.usereffect.com/topic/25-point-website-usability-checklist. Acedido a 28 Novembro de 2010. Moe, N. B., T. Dingsoyr, et al. (2010). "A teamwork model for understanding an agile team: A case study of a Scrum project." Information and Software Technology 52(5): 480-491. Nielsen, J. (1994). Heuristic evaluation. Usability Inspection Methods. J. N. a. R. L. Mack. New York, NY, John Wiley & Sons. Nielsen, J. and T. K. Landauer (1993). A Mathematical-Model of the Finding of Usability Problems. Human Factors in Computing Systems - Interchi 93. S. Ashlund, A. Henderson, E. Hollnagel, K. Mullet and T. White. Amsterdam, I O S Press: 206-213. Nielsen, J. and R. Molich (1990). Heuristic evaluation of user interfaces. Proceedings of the SIGHI Conference on Human Factors in Computing Systems, Seattle, WA, ACM. Nielsen, J. and M. Tahir (2002). 113 Design Guidelines for Homepage Usability. Homepage usability : 50 websites deconstructed. Indianapolis, IN, New Riders. Nonaka, I. (2007). "The knowledge-creating company." Harvard Business Review 85(7-8): 162-+.

http://www.digital-web.com/articles/practical_usability_testing/

http://www.digital-web.com/articles/practical_usability_testing/

http://www.usereffect.com/topic/25-point-website-usability-checklist

http://www.usereffect.com/topic/25-point-website-usability-checklist


154

Popadiuk, S. and C. W. Choo (2006). "Innovation and knowledge creation: How are these concepts related?" International Journal of Information Management 26(4): 302-312. Prates, R. and S. Barbosa (2003). Avaliação de Interfaces de Usuário - Conceitos e Métodos. Jornadas de Atualização em Informática - XXII Congreso da SBC. Campinas. Pressman, R. S. (2001). Software Engineering: A Practitioner´s Approach, McGraw Hill. Royce, W. (1970). "Managing the development of large software systems: concepts and techniques." Proceedings, IEEE WESCON: 1-9. Sumrell, M. (2007). From waterfall to Agile - How does a QA team transition? AGILE 2007, Proceedings. F. Maurer, R. Davies, G. Melnik and G. Pollice. Los Alamitos, Ieee Computer Soc: 291-294. Takeuchi, H. and I. Nonaka (1986). "The New New Product Development Game." Harvard Business Review 64(1): 137-146.


155


Anexo A – Checklist gerado e distribuído por Meyers


Anexo B – Documento especificação técnica

Projecto Portal Gift.Certificates Sonae SierraEspecificação Técnica

Direcção Sistemas Informação

Objectivos

• Confidencialidade dos dados e arquivo electrónico;

• Rapidez de acesso e resposta do sistema, face ao

• Atomicidade, consistência e durabilidade

• Plano eficaz de Disaster Recovery;

• Estruturas independentes para desenvolvimento, testes/qualidade e produção;

• Sistema para controlo de versões SVN.

Arquitectura / Recursos requeridos

Irão ser criadas três estruturas:

• Estrutura de Desenvolvimento:

o Descrição:

� Uma só máquina para

application server

reports e motor para controle de versões

o Objectivo:

� Desenvolvimento de novas

� Verificação e correcção de

o Hardware:

� 2 Intel(R) Xeon(R) CPU E5345 2.34GHz

� 2,00 GB RAM

� 50 GB Disco rígido

o Software:

� Microsoft Windows Server 2003 R2 Enterprise SP2

� Microsoft Internet Information Service

� Microsoft SQL Server 2005

� Microsoft SQL Reports 2005

� SVN Connector Control Version

o Política de Disaster Recovery

� Backup de máquina com 48 horas de intervalo.

• Estrutura de Testes/Qualidade:

o Descrição:

� Duas máquinas, sendo uma para

disponível o application server

disponíveis a estrutura de base de dados, arquivo documental e sistema de

o Objectivo:

Projecto Portal Gift.Certificates Sonae Sierra


Rapidez de acesso e resposta do sistema, face ao elevado número de acessos esperado;




de versões SVN.

/ Recursos requeridos

Desenvolvimento:

Uma só máquina para frontend e backend. Na mesma máquina estará disponível o

application server, a estrutura de base de dados, arquivo documental, sistema de

e motor para controle de versões SVN.

to de novas features;

Verificação e correcção de bugs.


50 GB Disco rígido





SVN Connector Control Version

Disaster Recovery:

Backup de máquina com 48 horas de intervalo.

Estrutura de Testes/Qualidade:

Duas máquinas, sendo uma para Frontend e outra para Backend

application server, ou seja, o interface com o usuário. No



1/3

número de acessos esperado;


. Na mesma máquina estará disponível o

, a estrutura de base de dados, arquivo documental, sistema de

Backend. No frontend está

com o usuário. No backend estão

disponíveis a estrutura de base de dados, arquivo documental e sistema de reports.



� Imagem perfeita da estrutura de produção;

� Testes de novas features

� Testes de performance

o Hardware:

� Frontend:

• 1 Intel(R) Xeon(R) CPU E5345 2.34GHz

• 2,00 GB RAM

• 20 GB Disco rígido

� Backend:


• 2,00 GB RAM


o Software:

� Frontend:

• Microsoft Windows Server 2003

• Microsoft Internet Information Service

� Backend:

• Microsoft Windows Server 2003 R2 Enterprise SP2

• Microsoft SQL Server 2005

• Microsoft SQL Reports 2005


� Backup de máquina com 24 horas de intervalo. Registos em

noutra máquina com intervalos mais curtos. Ao fazer

um restore num

para a máquina existente no

• Estrutura de Produção:

o Descrição:

� Duas máquinas, sendo uma para

disponível o application server


o Objectivo:

� Estrutura de produção, visível aos usuários finais;

o Hardware:

� Frontend:


• 2,00 GB RAM


� Backend:



Imagem perfeita da estrutura de produção;

features e correcções de bugs;

performance.


2,00 GB RAM

20 GB Disco rígido


2,00 GB RAM

30 GB Disco rígido






Disaster Recovery:

Backup de máquina com 24 horas de intervalo. Registos em

noutra máquina com intervalos mais curtos. Ao fazer backup

num recovery site. Em caso de disaster o sistema automaticamente aponta

para a máquina existente no recovery site, que aponta para a bas

Duas máquinas, sendo uma para Frontend e outra para Backend

application server, ou seja, o interface com o usuário. No


Estrutura de produção, visível aos usuários finais;


2,00 GB RAM

20 GB Disco rígido

l(R) Xeon(R) CPU E5345 2.34GHz


2/3

Backup de máquina com 24 horas de intervalo. Registos em base de dados replicados

backup, simultaneamente é feito

o sistema automaticamente aponta

, que aponta para a base de dados replicada.

Backend. No frontend está

com o usuário. No backend estão

disponíveis a estrutura de base de dados, arquivo documental e sistema de reports.



• 2,00 GB RAM


o Software:

� Frontend:


• Microsoft Internet Information Service

� Backend:


• Microsoft SQL Server 2005

• Microsoft SQL Reports 2005


� Backup de máquina com 24 horas de intervalo. Registos em base de dados replicados

noutra máquina com intervalos mais curtos. Ao fazer

um restore num

para a máquina existente no

Riscos

O desenho da infra-estrutura teve como base a experiência ganha noutros portais considerados de igual

dimensão, os quais foram sendo ajustados em termos de

ajustes on the fly (número de processadores, memória

virtual nos permite, poderão no futuro ser aplicados conforme as n

processamento tiradas.


2,00 GB RAM

30 GB Disco rígido






Disaster Recovery:


noutra máquina com intervalos mais curtos. Ao fazer backup

num recovery site. Em caso de disaster o sistema automaticamente aponta

para a máquina existente no recovery site, que aponta para a base de dados replicada.

estrutura teve como base a experiência ganha noutros portais considerados de igual

, os quais foram sendo ajustados em termos de hardware conforme as necessidades. Todos os

(número de processadores, memória RAM e espaço em disco) que uma infra

virtual nos permite, poderão no futuro ser aplicados conforme as necessidades e métricas de acesso e


3/3


backup, simultaneamente é feito

o sistema automaticamente aponta

, que aponta para a base de dados replicada.

estrutura teve como base a experiência ganha noutros portais considerados de igual

conforme as necessidades. Todos os

e espaço em disco) que uma infra-estrutura

ecessidades e métricas de acesso e


Anexo C – Checklist para testes de usabilidade

Projecto Portal Gift.Certificates Questionário de Avaliação do Sistema


Objectivo

Este questionário tem como objectivo recolher algum feedback de utilização do Portal

Sierra.

Regras de preenchimento

Insira o seu nome no ponto 1 e a data corrente no ponto

ID de cenário sobre o qual está a avaliar (ver na folha de cenário).

No ponto 4 da avaliação deverá fazer um e só um círculo por questão, correspondente ao grau de

concordância. Se a questão não se aplicar ao cenário, faça um círculo sobre a opção NA.

Por favor, leia com atenção as questões a seguir e em caso de dúvida, solicite o esclarecimento do avaliador.

Avaliação

1. Nome de usuário _____________________________________________

2. Data (DD/MM/AAAA) ___________________

3. Cenário (ver na folha de cenários)

4. Marque o grau com que mais concorda:

a. Facilidade de utilização

b. Assimilação da informação

c. Organização da informação

d. Mensagens do sistema

e. Nomenclatura no interface (botões,

títulos de janela, campos, etc.

f. Layout do interface

Projecto Portal Gift.Certificates Sonae SierraQuestionário de Avaliação do Sistema

Este questionário tem como objectivo recolher algum feedback de utilização do Portal

a data corrente no ponto 2. No ponto 3 da avaliação deverá referir qual é o

ID de cenário sobre o qual está a avaliar (ver na folha de cenário).

da avaliação deverá fazer um e só um círculo por questão, correspondente ao grau de

a questão não se aplicar ao cenário, faça um círculo sobre a opção NA.


_____________________________________________________________

Data (DD/MM/AAAA) ___________________

Cenário (ver na folha de cenários) _____________________

Marque o grau com que mais concorda:

Difícil

NA 0 1 2

Difícil

NA 0 1 2

Má

NA 0 1 2

Confusas

NA 0 1 2

(botões,

etc.)

Confuso

NA 0 1 2

Confuso

NA 0 1 2

Sonae Sierra

1/3

Este questionário tem como objectivo recolher algum feedback de utilização do Portal Gift.Certificates Sonae

da avaliação deverá referir qual é o

da avaliação deverá fazer um e só um círculo por questão, correspondente ao grau de

a questão não se aplicar ao cenário, faça um círculo sobre a opção NA.


___________________

Fácil

3 4 5

Fácil

3 4 5

Boa

3 4 5

Claras

3 4 5

Claro

3 4 5

Claro

3 4 5



5. Aponte as situações onde sentiu alguma dificuldade na utilização do sistema?

_________________________________________________________________________________

_________________________________________________________________________________

_________________________________________________________________________________

_________________________________________________________________________________

6. Aponte situações onde achou fácil utilizar o sistema?

_________________________________________________________________________________

_________________________________________________________________________________

__________________________________________

_________________________________________________________________________________

7. Durante a utilização do sistema sentiu a necessidade de aceder ao menu de Ajuda? Se sim porque?

___________________________________

_________________________________________________________________________________

_________________________________________________________________________________

_________________________________________________________________________________

8. Durante a utilização do sistema solicitou a ajuda do avaliador? Se sim porque?

_________________________________________________________________________________

_________________________________________________________________________________

_________________________________________________________________________________

_________________________________________________________________________________

9. Acha que a funcionalidade testada atingiu o objectivo para o qual foi desenvolvida? Explique.

_________________________________________________________________________________

_________________________________________________________________________________

_________________________________________________________________________________

_________________________________________________________________________________


Aponte as situações onde sentiu alguma dificuldade na utilização do sistema?

_________________________________________________________________________________

_________________________________________________________________________________

_________________________________________________________________________________

_________________________________________________________________________________

situações onde achou fácil utilizar o sistema?

_________________________________________________________________________________

_________________________________________________________________________________

_________________________________________________________________________________

_________________________________________________________________________________

Durante a utilização do sistema sentiu a necessidade de aceder ao menu de Ajuda? Se sim porque?

_________________________________________________________________________________

_________________________________________________________________________________

_________________________________________________________________________________

_________________________________________________________________________________

Durante a utilização do sistema solicitou a ajuda do avaliador? Se sim porque?

_________________________________________________________________________________

_______________________________________________________________________

_________________________________________________________________________________

_________________________________________________________________________________

onalidade testada atingiu o objectivo para o qual foi desenvolvida? Explique.

_________________________________________________________________________________

_________________________________________________________________________________

_____________________________________________________________________

_________________________________________________________________________________

Sonae Sierra

2/3

Aponte as situações onde sentiu alguma dificuldade na utilização do sistema?

_________________________________________________________________________________

_________________________________________________________________________________

_________________________________________________________________________________

_________________________________________________________________________________

_________________________________________________________________________________

_________________________________________________________________________________

_______________________________________

_________________________________________________________________________________

Durante a utilização do sistema sentiu a necessidade de aceder ao menu de Ajuda? Se sim porque?

______________________________________________

_________________________________________________________________________________

_________________________________________________________________________________

_________________________________________________________________________________

Durante a utilização do sistema solicitou a ajuda do avaliador? Se sim porque?

_________________________________________________________________________________

_______________________________________________________________________

_________________________________________________________________________________

_________________________________________________________________________________

onalidade testada atingiu o objectivo para o qual foi desenvolvida? Explique.

_________________________________________________________________________________

_________________________________________________________________________________

_____________________________________________________________________

_________________________________________________________________________________



10. Sugira melhorias à funcionalidade testada.

_________________________________________________________________________________

_________________________________________________________________________________

_________________________________________________________________________________

_________________________________________________________________________________

_________________________________________________________________________________

_________________________________________________________________________________

_________________________________________________________________________________

_________________________________________________________________________________

_________________________________________________________________________________

_________________________________________________________________________________

_________________________________________________________________________________

_________________________________________________________________________________

11. Dê-nos a sua opinião sobre o teste efectuado. Se pretender pode sugerir melhorias a este.

_________________________________________________________________________________

_________________________________________________________________________________

_________________________________________________________________________________

_________________________________________________________________________________

_________________________________________________________________________________

____________________________

_________________________________________________________________________________

_________________________________________________________________________________


Sugira melhorias à funcionalidade testada.

_________________________________________________________________________________

_________________________________________________________________________________

_________________________________________________________________________________

_________________________________________________________________________________

_________________________________________________________________________________

_________________________________________________________________________________

_________________________________________________________________________

_________________________________________________________________________________

_________________________________________________________________________________

__________________________________________________________________

_________________________________________________________________________________

_________________________________________________________________________________

sobre o teste efectuado. Se pretender pode sugerir melhorias a este.

_________________________________________________________________________________

_________________________________________________________________________________

____________________________________________________________

_________________________________________________________________________________

_________________________________________________________________________________

_________________________________________________________________________________

_________________________________________________________________________________

_________________________________________________________________________________

Sonae Sierra

3/3

_________________________________________________________________________________

_________________________________________________________________________________

_________________________________________________________________________________

_________________________________________________________________________________

_________________________________________________________________________________

_________________________________________________________________________________

_________________________________________________________________________

_________________________________________________________________________________

_________________________________________________________________________________

__________________________________________________________________

_________________________________________________________________________________

_________________________________________________________________________________

sobre o teste efectuado. Se pretender pode sugerir melhorias a este.

_________________________________________________________________________________

_________________________________________________________________________________

____________________________________________________________

_________________________________________________________________________________

_________________________________________________________________________________

_____________________________________________________

_________________________________________________________________________________

_________________________________________________________________________________


Anexo D – Cenários para testes de usabilidade

Projecto Portal Gift.Certificates Sonae SierraTeste de Usabilidade – Cenário “


Objectivo

Identificar a performance alcançada por cada um dos usuários e o grau de entendimento da funcionalidade

em teste. Será preenchido durante ou após a tarefa um formulário de

identificar possíveis falhas ou melhorias antes da passagem do sistema a produtivo.

Regras

1. Serão distribuídas antes do início do teste, tantas folhas de avaliação quantos os cenários descritos

em baixo, podendo estas serem pre

2. O usuário deverá cumprir todos os cenários descritos;

3. O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: A

4. Caso o cenário requeira dados para preenchimento (Ex: número de c

avaliador;

5. Concentre-se na conclusão do cenário. Caso não consiga continuar peça ajuda ao avaliador,

identificando na folha de avaliação o problema que teve e se possível, a solução adoptada.

Acesso

1. No desktop existe um shortcut

aberta uma janela de browser IE7

2. Seleccione o seu nome na lista de usuários;

3. Será aberta a homepage do Portal Gift.Certificates Sonae Sierra;

4. No canto superior esquerdo verifique que no campo

aparece 8ª Avenida. Isto quererá dizer que neste momento está numa sessão sua, estando no

contexto do centro 8ª Avenida, tendo permissão para executar operações sobr

Descrição

Homepage do Portal Gift.Certicates Sonae Sierra

Cenário A-01

1. Verificar a formatação de página (imagens, sombreados, fonte, cores);

2. No canto superior direito verificar a existência e funcionamento dos

Help;

3. No menu (lado direito) verificar o correcto funcionamento deste, principalmente quando abrimos os

“ramos” ToolBox e Reports;

4. Navegue pelos links de menu

de QuickLinks o link HOMEPAGE

Projecto Portal Gift.Certificates Sonae Sierra“Homepage”


em teste. Será preenchido durante ou após a tarefa um formulário de avaliação. Pretende


Serão distribuídas antes do início do teste, tantas folhas de avaliação quantos os cenários descritos

em baixo, podendo estas serem preenchidas durante ou após o teste;

O usuário deverá cumprir todos os cenários descritos;

O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: A

Caso o cenário requeira dados para preenchimento (Ex: número de cheque), deverá pedi

se na conclusão do cenário. Caso não consiga continuar peça ajuda ao avaliador,


shortcut com a designação Portal Gift.Certificates. Faça duplo

browser IE7;

Seleccione o seu nome na lista de usuários;

do Portal Gift.Certificates Sonae Sierra;

No canto superior esquerdo verifique que no campo User aparece o seu nome, e no campo



Homepage do Portal Gift.Certicates Sonae Sierra.

Verificar a formatação de página (imagens, sombreados, fonte, cores);

No canto superior direito verificar a existência e funcionamento dos links Site Map

) verificar o correcto funcionamento deste, principalmente quando abrimos os

de menu, verificando o correcto funcionamento destes, pressionando na barra

link HOMEPAGE para voltar a esta.


1/1


avaliação. Pretende-se assim



O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: A-01);

heque), deverá pedi-los ao



. Faça duplo click neste, sendo

aparece o seu nome, e no campo Mall


contexto do centro 8ª Avenida, tendo permissão para executar operações sobre este;

links Site Map, Contact Us e

) verificar o correcto funcionamento deste, principalmente quando abrimos os

, verificando o correcto funcionamento destes, pressionando na barra



Objectivo




Regras

1. Serão distribuídas antes do início do teste, tantas folhas de avaliação

em baixo, podendo estas serem

2. O usuário deverá cumprir todos os cen

3. O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar


avaliador;



Acesso





4. No canto superior esquerdo verifique qu



5. No canto superior esquerdo pres

Descrição

O portal tem implementado a feature

aceder ao portal, este reconhece o usuário, tal como as suas permissões e a que centro ou centros está

associado. No caso de poder visualizar ou trabalhar em mais que um centro, na função

alterar o centro onde quero trabalhar no portal. Todas as funcionalidades do portal dependem sempre do

centro seleccionado ou herdado pelo usuário.

Cenário B-01

1. Verificar se está visível o campo

2. Nesta caixa de selecção escolher um novo centro;

3. Pressionar o botão Save;

4. O sistema deverá fazer um refresh

5. No canto superior esquerdo, verificar se no campo

6. Repetir a tarefa, de modo ao centro

Projecto Portal Gift.Certificates Sonae Sierra“Context”




s antes do início do teste, tantas folhas de avaliação quantos os cenários descritos

em preenchidas durante ou após o teste;


deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar





browser IE7;






No canto superior esquerdo pressione o icon à direita do campo Mall.

feature de SingleSignOn. Dependendo do usuário de rede no terminal, ao


associado. No caso de poder visualizar ou trabalhar em mais que um centro, na função

terar o centro onde quero trabalhar no portal. Todas as funcionalidades do portal dependem sempre do

centro seleccionado ou herdado pelo usuário.

o campo Mall, tendo uma caixa de selecção à esquerda;

selecção escolher um novo centro;

refresh, retornando para a Homepage;

No canto superior esquerdo, verificar se no campo Mall, o centro escolhido é o que está descrito.

Repetir a tarefa, de modo ao centro original ser novamente o seleccionado.


1/1




quantos os cenários descritos

deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: B-01);








. Dependendo do usuário de rede no terminal, ao


associado. No caso de poder visualizar ou trabalhar em mais que um centro, na função Context poderemos

terar o centro onde quero trabalhar no portal. Todas as funcionalidades do portal dependem sempre do

, tendo uma caixa de selecção à esquerda;

, o centro escolhido é o que está descrito.

seleccionado.



Objectivo




Regras




3. O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: C


avaliador;



Acesso








5. No canto superior direito pressione sobre o link

Descrição

Temos uma imagem de todas entradas de menu disponíveis ao usuário conforme as suas permissões. Para

cada sub-aplicação (entrada) teremos uma breve explicação da função desta. Aqu

seleccionar qual ou quais entradas que quer ter na área de

seleccionar uma sub-aplicação para entrada automática, a quando acedemos ao portal.

Cenário C-01

1. Verificar que as entradas de menu

2. Verificar se aparece uma breve descrição da funcionalidade, ao passar em cima d

3. Cada entrada de mapa tem associado uma

só pode estar seleccionada uma única

4. Seleccionar uma entrada pela

5. Pressionar o botão Save Favorites

6. Verificar se na barra de QuickLinks

7. Pressionar nesta mesma barra o

8. Verificar se a entrada seleccionada por

Projecto Portal Gift.Certificates Sonae Sierra“Site Map”







O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: C





browser IE7;






No canto superior direito pressione sobre o link Site Map.


aplicação (entrada) teremos uma breve explicação da função desta. Aqu

seleccionar qual ou quais entradas que quer ter na área de QuickLinks, para acesso fácil. Também poderá

aplicação para entrada automática, a quando acedemos ao portal.

Verificar que as entradas de menu (à esquerda) coincidem com as entradas existentes no mapa;

Verificar se aparece uma breve descrição da funcionalidade, ao passar em cima d

Cada entrada de mapa tem associado uma radioBox e uma selectBox. Verificar que ao mesmo tempo

estar seleccionada uma única radioBox e no máximo cinco selectBox

Seleccionar uma entrada pela radioBox e até cinco entradas pela selectBox

Save Favorites. O portal faz um refresh automático;

QuickLinks, as entradas seleccionadas por selectBox

Pressionar nesta mesma barra o link HOMEPAGE;

Verificar se a entrada seleccionada por radioBox, aparece automaticamente;


1/1





O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: C-01);









aplicação (entrada) teremos uma breve explicação da função desta. Aqui o usuário poderá

, para acesso fácil. Também poderá

aplicação para entrada automática, a quando acedemos ao portal.

coincidem com as entradas existentes no mapa;

Verificar se aparece uma breve descrição da funcionalidade, ao passar em cima de cada entrada;

. Verificar que ao mesmo tempo

selectBox;

selectBox;

selectBox encontram-se presentes;

, aparece automaticamente;



Objectivo

Identificar a performance alcançada por cada um dos usuários e o grau de entendimento da funcionalidade em teste. Será preenchido durante ou após a tarefa um formulário de identificar possíveis falhas ou melhorias antes da passagem do sistema a produtivo.

Regras

1. Serão distribuídas antes do início do teste, tantas folhas de avaliação quantos os cenários descritos em baixo, podendo estas serem pre

2. O usuário deverá cumprir todos os cenários descritos;3. O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: D4. Caso o cenário requeira dados para preenchimento (Ex: número de c

avaliador; 5. Concentre-se na conclusão do cenário. Caso não consiga continuar peça ajuda ao avaliador,


Acesso



2. Seleccione o seu nome na lista de usuários;3. Será aberta a homepage do Portal Gift.Certificates Sonae Sierra;4. No canto superior esquerdo verifique que no campo

aparece 8ª Avenida. Isto quererá dizer que neste momento está numa sessão sua, estando no contexto do centro 8ª Avenida, tendo permissão para executar operações sobr

5. No canto superior direito pressione sobre o

Descrição Área de ajuda à operação: manuais de usuário; FAQ.

Cenário D-01

1. Verificar a existência de dois links

a. (EN) User’s Manual

b. (EN) FAQ

2. Ambos os links são precedidos de um icon de documento 3. Ao pressionarmos sobre o link (EN) User’s Manual

documento PDF contendo as palavras Manual Utilização;4. Ao pressionarmos sobre o link (EN) FAQ

documento PDF contendo as palavras 5. Pressionar o QuickLink HOMEPAGE

Projecto Portal Gift.Certificates Sonae Sierra“Help”

Identificar a performance alcançada por cada um dos usuários e o grau de entendimento da funcionalidade em teste. Será preenchido durante ou após a tarefa um formulário de avaliação. Pretendeidentificar possíveis falhas ou melhorias antes da passagem do sistema a produtivo.

Serão distribuídas antes do início do teste, tantas folhas de avaliação quantos os cenários descritos em baixo, podendo estas serem preenchidas durante ou após o teste; O usuário deverá cumprir todos os cenários descritos; O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: DCaso o cenário requeira dados para preenchimento (Ex: número de cheque), deverá pedi

se na conclusão do cenário. Caso não consiga continuar peça ajuda ao avaliador, identificando na folha de avaliação o problema que teve e se possível, a solução adoptada.

shortcut com a designação Portal Gift.Certificates. Faça duplo browser IE7;

Seleccione o seu nome na lista de usuários; do Portal Gift.Certificates Sonae Sierra;

No canto superior esquerdo verifique que no campo User aparece o seu nome, e no campo aparece 8ª Avenida. Isto quererá dizer que neste momento está numa sessão sua, estando no contexto do centro 8ª Avenida, tendo permissão para executar operações sobrNo canto superior direito pressione sobre o link Help.

Área de ajuda à operação: manuais de usuário; FAQ.

links com as designações:

são precedidos de um icon de documento PDF; link (EN) User’s Manual, o sistema irá abrir uma nova janela contendo um

contendo as palavras Manual Utilização; link (EN) FAQ, o sistema irá abrir uma nova janela contendo um

contendo as palavras FAQ. HOMEPAGE (barra de QuickLinks), para voltar a esta.


1/1

Identificar a performance alcançada por cada um dos usuários e o grau de entendimento da funcionalidade avaliação. Pretende-se assim



O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: D-01); heque), deverá pedi-los ao



aparece o seu nome, e no campo Mall aparece 8ª Avenida. Isto quererá dizer que neste momento está numa sessão sua, estando no contexto do centro 8ª Avenida, tendo permissão para executar operações sobre este;

á abrir uma nova janela contendo um

uma nova janela contendo um

), para voltar a esta.



Objectivo




Regras




3. O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: E


avaliador;



Acesso








5. No canto superior direito pressione sobre o

Descrição

Ferramenta onde o usuário poderá tirar dúvidas, dar recomendações ou reportar

irá ser usada para preenchimento. Nesta estarão já especificados vários temas, passíveis de pedidos de

informação.

Cenário E-01

1. Preencher o campo Subject, com o texto assunto;

2. Seleccionar no campo Reason

3. Preencher o campo Description

4. Preencher o campo Name, com o nome de usuário;

5. Preencher o campo opcional Phone

6. Pressionar o botão Send;

7. Verificar a mensagem de retorno do sistema;

8. Verificar com o avaliador o envio correcto do

Projecto Portal Gift.Certificates Sonae Sierra“Contact Us”







O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: E





browser IE7;






No canto superior direito pressione sobre o link Contact Us.

Ferramenta onde o usuário poderá tirar dúvidas, dar recomendações ou reportar


, com o texto assunto;

a opção Suggestion;

Description, com o texto descrição;

, com o nome de usuário;

Phone, com o número 123456789;

Verificar a mensagem de retorno do sistema;

Verificar com o avaliador o envio correcto do email.


1/1





O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: E-01);








Ferramenta onde o usuário poderá tirar dúvidas, dar recomendações ou reportar bugs do portal. Uma form




Objectivo




Regras




3. O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: F


avaliador;



Acesso








5. Do lado esquerdo, na área de menu, seleccione a entrada

Descrição

Gestão de todas as ordens de compra criadas até à data. Esta ordem de compra deverá ser usada somente

para clientes empresariais e para grandes encomendas de Cheques

forma, guias de entrega, guias de envio e detalhe de ordem, é feita nesta área. Uma ordem de compra pode

ser cancelada ou confirmada, sendo neste caso transformada numa venda.

Cenário F-01

1. Seleccionar no campo Country

2. Preencha os campos Date conforme indicações do avaliador;

3. Pressione o botão Search;

4. Verifique que aparece no quadro, 8 ordens pendentes e 10 ordens processadas;

5. Seleccione a opção Pendent (8) e verifique que o quadro com as 8 ordens pendent

6. Verifique se os valores de célula no quadro estão bem formatados;

7. Ordene os campos pressionando

8. Tente cancelar uma ordem.

9. Verifique que o quadro fica com 7 ordens pendentes;

Projecto Portal Gift.Certificates Sonae Sierra“Orders”







O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: F





browser IE7;






Do lado esquerdo, na área de menu, seleccione a entrada Orders.


para clientes empresariais e para grandes encomendas de Cheques-Prenda. Toda a geração de facturas pró


ser cancelada ou confirmada, sendo neste caso transformada numa venda.

Country, a opção Portugal;

conforme indicações do avaliador;

no quadro, 8 ordens pendentes e 10 ordens processadas;

Seleccione a opção Pendent (8) e verifique que o quadro com as 8 ordens pendent

Verifique se os valores de célula no quadro estão bem formatados;

Ordene os campos pressionando cada um dos títulos de coluna no quadro;

quadro fica com 7 ordens pendentes;


1/2





O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: F-01);









Toda a geração de facturas pró-



Seleccione a opção Pendent (8) e verifique que o quadro com as 8 ordens pendentes ficam visíveis;

no quadro;



10. Verifique que ao totalizador de quadro no campo

removido;

11. Tente imprimir a pró-forma de uma ordem e o detalhe desta.

formato destes documentos, tal como a veracidade do seu conteúdo.

Cenário F-02


2. Preencha os campos Date conforme indicações do avaliador;


4. Verifique que aparece no quadro, 7 ordens pendentes e 10 ordens processadas;

5. Seleccione a opção Processed

visíveis;

6. Verifique se os valores de célula no quadro estão bem formatados;

7. Ordene os campos pressionando cada um dos títulos de coluna no quadro;

8. Verifique que já não é possível cancelar uma ordem;

9. Tente imprimir a pró-forma de uma ordem e o detalhe desta.


Cenário F-03

1. Pressionar o botão Add Order;

2. No quadro Client Information

botão Search;

3. Automaticamente todos os dados do cliente empresarial com aquele

4. No campo Payment Information

5. No quadro Products insira 10 unidades para cheques d

6. No quadro Services Extra to Declare

7. No quadro Delivery Information

morada de entrega;

8. Pressione o botão Place Order

9. O sistema retorna à página Orders

10. Verifique que a ordem adicionada existe no quadro de Ordens Pendentes, e que o valor total desta é

de 101,51 €, ou seja, 100€ de cheques + 1,51 € (valor do envelope + IVA);

11. Se quiser poderá cancelar a ordem

Projecto Portal Gift.Certificates Sonae Sierra“Orders”

izador de quadro no campo Order Value, foi descontado o valor da ordem

forma de uma ordem e o detalhe desta. Verifique com o avaliador o correcto



conforme indicações do avaliador;


Processed (10) e verifique que o quadro com as 10 ordens pendentes ficam

Verifique se os valores de célula no quadro estão bem formatados;


que já não é possível cancelar uma ordem;

forma de uma ordem e o detalhe desta. Verifique com o avaliador o correcto


;

Client Information, insira no campo Fiscal Number o número 123456789 e pressione o

Automaticamente todos os dados do cliente empresarial com aquele NIF, são mostrados;

Payment Information, seleccione o tipo de pagamento Transfer;

insira 10 unidades para cheques de 10€;

to Declare, seleccione 1 unidade de envelopes;

Delivery Information, seleccione a opção Other Address, e preencha os dados para a

Place Order;

Orders e poderá fazer a mesma pesquisa do cenário F

Verifique que a ordem adicionada existe no quadro de Ordens Pendentes, e que o valor total desta é

€, ou seja, 100€ de cheques + 1,51 € (valor do envelope + IVA);

celar a ordem.


2/2

, foi descontado o valor da ordem

Verifique com o avaliador o correcto


que o quadro com as 10 ordens pendentes ficam


Verifique com o avaliador o correcto

o número 123456789 e pressione o

, são mostrados;

;

, e preencha os dados para a

oderá fazer a mesma pesquisa do cenário F-02;

Verifique que a ordem adicionada existe no quadro de Ordens Pendentes, e que o valor total desta é



Objectivo


Regras


2. O usuário deverá cumprir todos os cenários descritos;3. O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: G4. Caso o cenário requeira dados para preenchimento (Ex: número de c



Acesso






Descrição Área de venda de um ou mais Chequesassociados serviços extra, como envelopes personificados, envio por correio, e

Cenário G-01

1. Nos campos From e To, inserir o intervalo de números de cheque dado pelo avaliador;2. Pressionar o botão Add; 3. Um quadro com os intervalos inseridos é mostrado;4. Por cada novo intervalo deverá pressionar o botão

quadro; 5. Seleccione o primeiro intervalo inserido, e pressione o botão 6. No campo Client escolha a opção 7. Pressione o botão Search; 8. Verifique os erros que irão aparecer para alguns cheques. Utilize o filtro só para mostrar cheques

válidos; 9. Seleccione todos os cheques válidos;

Projecto Portal Gift.Certificates Sonae Sierra“Sales”


Serão distribuídas antes do início do teste, tantas folhas de avaliação quantos os cenários descritos em baixo, podendo estas serem preenchidas durante ou após o teste; O usuário deverá cumprir todos os cenários descritos; O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: GCaso o cenário requeira dados para preenchimento (Ex: número de cheque), deverá pedi




No canto superior esquerdo verifique que no campo User aparece o seu nome, e no campo aparece 8ª Avenida. Isto quererá dizer que neste momento está numa sessão sua, estando no contexto do centro 8ª Avenida, tendo permissão para executar operações sobrDo lado esquerdo, na área de menu, seleccione a entrada Sales.

Área de venda de um ou mais Cheques-Prenda ao público ou a empresas. A uma compra poderão estar associados serviços extra, como envelopes personificados, envio por correio, etc.

, inserir o intervalo de números de cheque dado pelo avaliador;

Um quadro com os intervalos inseridos é mostrado; Por cada novo intervalo deverá pressionar o botão Add de seguida, para assim ser adicionado ao

Seleccione o primeiro intervalo inserido, e pressione o botão Remove, para o remover do quadro;escolha a opção Public (venda de cheques ao público);

rros que irão aparecer para alguns cheques. Utilize o filtro só para mostrar cheques

Seleccione todos os cheques válidos;


1/2




O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: G-01); heque), deverá pedi-los ao




Prenda ao público ou a empresas. A uma compra poderão estar


de seguida, para assim ser adicionado ao

, para o remover do quadro;

rros que irão aparecer para alguns cheques. Utilize o filtro só para mostrar cheques



10. No quadro Services Extra to Declare

11. Pressione o botão Preview Sale

12. Confira no ecrã de detalhe se a venda e serviços extra seleccionados, estão descritos e os valores correctos. Se quiser peça ajuda ao avaliador;

13. Pressione o botão Confirm; 14. Numa nova janela estará o recibo de compra, preparado para impressão;15. Confirma os dados deste. Se quiser peça ajuda ao avaliador.

Cenário G-02

1. Nos campos From e To, inserir o intervalo de números de cheque dado pelo avaliador;2. Pressionar o botão Add; 3. Um quadro com os intervalos inseridos é mostrado;4. Por cada novo intervalo deverá pressionar o botão

quadro; 5. Seleccione o primeiro intervalo inserido, e pressione o botão 6. No campo Client escolha a opção 7. Insira o NIF de empresa (123456789) e p8. Pressione o botão Search; 9. Verifique os erros que irão aparecer para alguns cheques. Utilize o filtro só para mostrar cheques

válidos; 10. Seleccione todos os cheques válidos;11. No quadro Services Extra to Declare

12. Pressione o botão Preview Sale

13. Confira no ecrã de detalhe se a venda e serviços extra seleccionados, estão descritos e os valores correctos. Se quiser peça ajuda ao avaliador;

14. Pressione o botão Confirm; 15. Numa nova janela estará o recibo16. Confirma os dados deste. Se quiser peça ajuda ao avaliador.

Projecto Portal Gift.Certificates Sonae Sierra“Sales”

Services Extra to Declare, seleccione 1 unidade de envelopes; Preview Sale;

de detalhe se a venda e serviços extra seleccionados, estão descritos e os valores correctos. Se quiser peça ajuda ao avaliador;

Numa nova janela estará o recibo de compra, preparado para impressão; quiser peça ajuda ao avaliador.


Um quadro com os intervalos inseridos é mostrado; Por cada novo intervalo deverá pressionar o botão Add de seguida, para assim ser adicionado ao

Seleccione o primeiro intervalo inserido, e pressione o botão Remove, para o remover do quadro;escolha a opção Company (venda de cheques a empresa);

Insira o NIF de empresa (123456789) e pressione o botão Search Company

Verifique os erros que irão aparecer para alguns cheques. Utilize o filtro só para mostrar cheques

Seleccione todos os cheques válidos; Services Extra to Declare, seleccione 1 unidade de envelopes;

Preview Sale; de detalhe se a venda e serviços extra seleccionados, estão descritos e os valores

correctos. Se quiser peça ajuda ao avaliador;

Numa nova janela estará o recibo de compra, preparado para impressão; Confirma os dados deste. Se quiser peça ajuda ao avaliador.


2/2

de detalhe se a venda e serviços extra seleccionados, estão descritos e os valores


de seguida, para assim ser adicionado ao

, para o remover do quadro; (venda de cheques a empresa);

Search Company;

Verifique os erros que irão aparecer para alguns cheques. Utilize o filtro só para mostrar cheques

de detalhe se a venda e serviços extra seleccionados, estão descritos e os valores



Objectivo




Regras




3. O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: H


avaliador;



Acesso









Descrição

Gestão de todos os depósitos criados até à data. Todo o dinheiro recolhido da venda após um dia de

trabalho deverá ser depositado numa conta especificada para o efeito. O

ser carregado e associado no portal às vendas a que se refere. Os serviços centrais farão a comparação entre

os depósitos declarados e o valor disponível em conta.

Cenário H-01

1. No campo Date preencha os campos


3. Verifique a existência de um quadro com 10 Vendas pendentes e 2 Depósitos já processados;

4. Seleccione 2 vendas pendentes e pressione o botão

5. Insira no campo Deposit, o valor 123

ao identificador único deste.

6. Insira no campo Date, uma data de depósito.

7. Pressione o botão Save.

Projecto Portal Gift.Certificates Sonae Sierra“Deposits”







O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: H





browser IE7;






Do lado esquerdo, na área de menu, seleccione a entrada Deposits.


trabalho deverá ser depositado numa conta especificada para o efeito. O comprovativo de depósito deverá


os depósitos declarados e o valor disponível em conta.

preencha os campos From e To. Questione o avaliador sobre estas datas.

Verifique a existência de um quadro com 10 Vendas pendentes e 2 Depósitos já processados;

Seleccione 2 vendas pendentes e pressione o botão Add Deposit;

, o valor 1234567. Este valor está disponível no talão de depósito

, uma data de depósito.


1/2





O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: H-01);









comprovativo de depósito deverá


Questione o avaliador sobre estas datas.

Verifique a existência de um quadro com 10 Vendas pendentes e 2 Depósitos já processados;

4567. Este valor está disponível no talão de depósito e refere-se



8. Verifique que ao fazer um novo

pendentes e 3 depósitos efectuados.

9. Confirme que no detalhe do último dep

anteriormente correctamente associadas;

10. Verifique que este depósito está em estado pendente, visto ainda não ter sido confirmado pelos

serviços centrais;

11. Verifique que um depósito em estado pendente ainda

depósito em estado confirmado;

12. Verifique que ao cancelar o depósito efectuado anteriormente os valores de quadro após a pesquisa

são os mesmos referidos no ponto 3.

Projecto Portal Gift.Certificates Sonae Sierra“Deposits”

Verifique que ao fazer um novo Search com as datas referidas no ponto 1, aparece

endentes e 3 depósitos efectuados.

Confirme que no detalhe do último depósito efectuado, este têm as vendas seleccionadas

anteriormente correctamente associadas;

que que este depósito está em estado pendente, visto ainda não ter sido confirmado pelos

que um depósito em estado pendente ainda pode ser cancelado, ao contrário de um

ósito em estado confirmado;

Verifique que ao cancelar o depósito efectuado anteriormente os valores de quadro após a pesquisa

referidos no ponto 3.


2/2

s no ponto 1, aparecem 8 vendas

este têm as vendas seleccionadas

que que este depósito está em estado pendente, visto ainda não ter sido confirmado pelos

ode ser cancelado, ao contrário de um

Verifique que ao cancelar o depósito efectuado anteriormente os valores de quadro após a pesquisa



Objectivo




Regras




3. O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: I


avaliador;



Acesso









Descrição

Gestão de todas as compensações criadas até à data. O lojista ao receber um Cheque

pagamento, deverá querer compensá

compensados nesta área. O sistema faz o cálculo das

da transferência a efectuar para o lojista.

Cenário I-01

1. Introduzir na área de texto, um conjunto de números de cheques. Questionar o avaliador sobre estes

números;

2. Pressionar o botão Search;

3. Verificar no quadro resultado, os cheques que apresentam erro e qual o erro;

4. Utilizar o filtro de resultados para melhor identificar os cheques com e

5. Seleccionar todos os cheques sem erro;

6. Pressionar o botão Preview Compensation

7. Verificar no quadro resumo, se todos os valores de

ao avaliador;

Projecto Portal Gift.Certificates Sonae Sierra“Compensations”







O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: I





browser IE7;






Do lado esquerdo, na área de menu, seleccione a entrada Compensations.

Gestão de todas as compensações criadas até à data. O lojista ao receber um Cheque

pagamento, deverá querer compensá-lo junto do centro. O centro ao receber os cheques irá marcá

compensados nesta área. O sistema faz o cálculo das fees a aplicar e remete para os serviços centrais o valor

da transferência a efectuar para o lojista.

um conjunto de números de cheques. Questionar o avaliador sobre estes

Verificar no quadro resultado, os cheques que apresentam erro e qual o erro;

Utilizar o filtro de resultados para melhor identificar os cheques com erro e sem erro;

Seleccionar todos os cheques sem erro;

Preview Compensation;

Verificar no quadro resumo, se todos os valores de fee aplicados se encontram correctos. Pedir ajuda


1/2





O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: I-01);








Gestão de todas as compensações criadas até à data. O lojista ao receber um Cheque-Prenda para

er os cheques irá marcá-los como

a aplicar e remete para os serviços centrais o valor



rro e sem erro;

aplicados se encontram correctos. Pedir ajuda



8. Pressionar o botão Compensate

9. Uma nova janela contendo o recibo de compensação será aberta, podendo ser impresso. Verificar

com o avaliador o correcto formato da factura.

Projecto Portal Gift.Certificates Sonae Sierra“Compensations”

Compensate;

a contendo o recibo de compensação será aberta, podendo ser impresso. Verificar

com o avaliador o correcto formato da factura.


2/2

a contendo o recibo de compensação será aberta, podendo ser impresso. Verificar



Objectivo




Regras




3. O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: J


avaliador;



Acesso









Descrição

Por roubo ou extravio de cheques o centro poderá querer marcar um determinado grupo de cheques como

cancelados, como forma de não conseguirem ser compensad

Cenário J-01

1. Introduzir na área de texto, um conjunto de números de cheques. Questionar o avaliador sobre estes

números;

2. No campo Status, seleccionar a opção


4. Verificar no quadro resultado, os cheques que apresentam

5. Utilizar o filtro de resultados para melhor identificar os cheques com erro e sem erro;

6. Seleccionar todos os cheques sem erro;

7. Pressionar o botão Preview Cancelation

8. Verificar no quadro resumo, se todos os cheques seleccionados estão l

avaliador;

9. Pressionar o botão Cancel Gift Certificates

Projecto Portal Gift.Certificates Sonae Sierra“Cancel Gift Certificates”







O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: J





browser IE7;






Do lado esquerdo, na área de menu, seleccione a entrada Cancel Gift Certificates


cancelados, como forma de não conseguirem ser compensados.


No campo Status, seleccionar a opção OnSale;



Seleccionar todos os cheques sem erro;

Preview Cancelation;

Verificar no quadro resumo, se todos os cheques seleccionados estão l

Cancel Gift Certificates;


1/2





O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: J-01);








Cancel Gift Certificates.



erro e qual o erro;


Verificar no quadro resumo, se todos os cheques seleccionados estão listados. Pedir ajuda ao



10. Uma mensagem de sucesso irá surgir.

Projecto Portal Gift.Certificates Sonae Sierra“Cancel Gift Certificates”

Uma mensagem de sucesso irá surgir.


2/2



Objectivo




Regras




3. O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: K


avaliador;



Acesso









Descrição

Gestão de fundos de caixa para venda de Cheques

Cenário K-01

1. No campo Country, seleccione a opção Portugal;

2. No campo Centre, seleccione a opção Centro Colombo;


4. Um quadro aparecerá com 5 pedidos de restituição de fundos pendentes,

espera de aprovação pelos serviços centrais

5. Seleccione a opção Status no p

6. Confirme os dados listados. Peça ajuda ao avaliador;

7. Insira um comentário no campo

8. Pressione o botão Save;

9. Seleccione novamente a opção

10. Verifique que o seu comentário

11. Pressione o botão Confirm Request

Projecto Portal Gift.Certificates Sonae Sierra“ToolBox – Petty Cash Fund Restitution







O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: K





browser IE7;






e menu, seleccione a entrada ToolBox – Petty Cash Fund Restitution.

Gestão de fundos de caixa para venda de Cheques-Prenda.

, seleccione a opção Portugal;

seleccione a opção Centro Colombo;

Um quadro aparecerá com 5 pedidos de restituição de fundos pendentes,

espera de aprovação pelos serviços centrais e 166 pedidos já confirmados;

no primeiro pedido, para ir ao detalhe deste;

Confirme os dados listados. Peça ajuda ao avaliador;

Insira um comentário no campo Comments;

Seleccione novamente a opção Status no primeiro pedido, para ir ao detalhe deste;

ário aparece associado ao seu autor;

Confirm Request;

Projecto Portal Gift.Certificates Sonae Sierra Petty Cash Fund Restitution”

1/2





O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: K-01);








Petty Cash Fund Restitution.

Um quadro aparecerá com 5 pedidos de restituição de fundos pendentes, 0 pedidos enviados à

já confirmados;

no primeiro pedido, para ir ao detalhe deste;



12. Verifique que ao efectuar a pesquisa anterior, já

13. Este pedido será confirmado pelos serviços centrais. Peça ao avaliador para o confirmar, para ass

ver listado nos pedidos já confirmados.

Cenário K-02

1. Pressione o botão Insert New Petty Funds Restitution

2. Seleccione as compensações diárias e outras operaç

caso seleccione todas;

3. Pressione o botão Submit;

4. Verifique a criação de um novo pedido no quadro de pendentes após pesquisa.

Projecto Portal Gift.Certificates Sonae Sierra“ToolBox – Petty Cash Fund Restitution

que ao efectuar a pesquisa anterior, já aparece 1 pedido enviado.

Este pedido será confirmado pelos serviços centrais. Peça ao avaliador para o confirmar, para ass

ver listado nos pedidos já confirmados.

Insert New Petty Funds Restitution;

Seleccione as compensações diárias e outras operações nas quais utilizou o fundo de caixa. Neste

Verifique a criação de um novo pedido no quadro de pendentes após pesquisa.

Projecto Portal Gift.Certificates Sonae Sierra Petty Cash Fund Restitution”

2/2

1 pedido enviado.

Este pedido será confirmado pelos serviços centrais. Peça ao avaliador para o confirmar, para assim o

ões nas quais utilizou o fundo de caixa. Neste

Verifique a criação de um novo pedido no quadro de pendentes após pesquisa.



Objectivo




Regras




3. O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: L


avaliador;



Acesso








5. Do lado esquerdo, na área de menu,

Descrição

Gestão de blocos de cheques recebidos.

Cenário L-01

1. Na área de texto, inserir um número de cheque. Questionar o avaliador sobre este número;


3. Verificar a mensagem de erro que irá aparecer. Confirmar esta com o avaliador;

4. Inserir um novo número de cheque dado pelo avaliador;


6. Verificar o quadro de resultado de pesquisa;

7. Pressionar o botão Confirm;

Projecto Portal Gift.Certificates Sonae Sierra“Toolbox – Reception GC Books”







O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: L





browser IE7;






e menu, seleccione a entrada Toolbox – Reception GC Books.

Gestão de blocos de cheques recebidos.

Na área de texto, inserir um número de cheque. Questionar o avaliador sobre este número;

Verificar a mensagem de erro que irá aparecer. Confirmar esta com o avaliador;

Inserir um novo número de cheque dado pelo avaliador;

Verificar o quadro de resultado de pesquisa;


1/1





O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: L-01);








Reception GC Books.

Na área de texto, inserir um número de cheque. Questionar o avaliador sobre este número;

Verificar a mensagem de erro que irá aparecer. Confirmar esta com o avaliador;



Objectivo




Regras




3. O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: M


avaliador;



Acesso







contexto do centro 8ª Avenida, tendo


Descrição

Motor para troca de cheques. Mediante o pagamento de uma

cheque por outro, estendendo assim o prazo de

cheques, sendo possível assim trocar por quantidades diferentes.

Cenário M-01

1. No quadro Gift Certificates to Cancel

a. Seleccionar a opção 5€, no campo

b. Inserir um número de cheque no campo

c. Inserir um número de cheque no campo

2. No quadro Gift Certificates to Replace

a. Seleccionar a opção 10




4. Verificar a mensagem de erro. Conversar com o avaliador sobre este.

Projecto Portal Gift.Certificates Sonae Sierra“Toolbox – Gift Certificates Switch”







O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: M





browser IE7;






Do lado esquerdo, na área de menu, seleccione a entrada Toolbox – Gift Certificates Switch.

Motor para troca de cheques. Mediante o pagamento de uma fee, é possível a uma empresa trocar um

cheque por outro, estendendo assim o prazo de validade. O que conta na troca é valor total monetário de

cheques, sendo possível assim trocar por quantidades diferentes.

Gift Certificates to Cancel:

€, no campo Type;

Inserir um número de cheque no campo From. Questionar o avaliador sobre este número;

Inserir um número de cheque no campo To. Questionar o avaliador sobre este número;

Gift Certificates to Replace:

Seleccionar a opção 10€, no campo Type;

Inserir um número de cheque no campo From. Questionar o avaliador sobre este número;

Inserir um número de cheque no campo To. Questionar o avaliador sobre este número;

Verificar a mensagem de erro. Conversar com o avaliador sobre este.


1/2





O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: M-01);







permissão para executar operações sobre este;

Gift Certificates Switch.

, é possível a uma empresa trocar um

validade. O que conta na troca é valor total monetário de

. Questionar o avaliador sobre este número;


onar o avaliador sobre este número;




5. No quadro Gift Certificates to Cancel

a. Seleccionar a opção 25


número;


número;

6. No quadro Gift Certificates to Replace

a. Seleccionar a opção 5€, no campo


número;


número;


8. Verificar a veracidade de todos os dados apresentados pelo sistema;

9. Pressionar o botão Switch;

10. Uma nova janela será apresentada, com a factura da operação em formato

empresa que tinha comprado os cheques originais.

factura e a veracidade dos dados apresentados nesta.

Projecto Portal Gift.Certificates Sonae Sierra“Toolbox – Gift Certificates Switch”

Gift Certificates to Cancel:

Seleccionar a opção 25€, no campo Type;

Inserir um número de cheque no campo From. Questionar o avaliador novamente sobre este

Inserir um número de cheque no campo To. Questionar o avaliador novamente sobre este

to Replace:

€, no campo Type;

Inserir um número de cheque no campo From. Questionar o avaliador novamente sobre este

Inserir um número de cheque no campo To. Questionar o avaliador novamente sobre este

Verificar a veracidade de todos os dados apresentados pelo sistema;

Uma nova janela será apresentada, com a factura da operação em formato

empresa que tinha comprado os cheques originais. Verificar com o avaliador o correcto formato da

factura e a veracidade dos dados apresentados nesta.


2/2

. Questionar o avaliador novamente sobre este




Uma nova janela será apresentada, com a factura da operação em formato PDF em nome da

Verificar com o avaliador o correcto formato da



Objectivo


Regras


2. O usuário deverá cumprir todos os cenários descritos;3. O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: N4. Caso o cenário requeira dados para preenchimento (Ex: número de c



Acesso






Descrição Gestão dos recibos de todas as compensações até à data. É possível a impressão de segunda via, sendo esta incrementada conforme as impressões.

Cenário N-01

1. No campo Country, seleccione a opção Portugal;2. No campo Mall, seleccione a opção Centro Colombo;3. O campo Compensated To deixe em branco;4. No campo Receipt Date, deixe os valores 5. O campo Receipt Number deixe em branco;6. Pressione o botão Search; 7. Irá aparecer um quadro, com 1 compensação original (ainda sem segundas vias), 1 compensação já

com pedido para segunda via e 2 compensações canceladas;8. Verifique que só na compensação original é possível o cancelamento desta;9. Cancele a compensação e verifique no quadro de pesquisa não tem 3 compensações anuladas;

Projecto Portal Gift.Certificates Sonae Sierra“Toolbox – Compensation Receipts”


Serão distribuídas antes do início do teste, tantas folhas de avaliação quantos os cenários descritos em baixo, podendo estas serem preenchidas durante ou após o teste; O usuário deverá cumprir todos os cenários descritos; O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: NCaso o cenário requeira dados para preenchimento (Ex: número de cheque), deverá pedi




No canto superior esquerdo verifique que no campo User aparece o seu nome, e no campo aparece 8ª Avenida. Isto quererá dizer que neste momento está numa sessão sua, estando no contexto do centro 8ª Avenida, tendo permissão para executar operações sobrDo lado esquerdo, na área de menu, seleccione a entrada Toolbox – Compensation Receipts.

Gestão dos recibos de todas as compensações até à data. É possível a impressão de segunda via, sendo esta incrementada conforme as impressões.

, seleccione a opção Portugal; , seleccione a opção Centro Colombo;

deixe em branco; , deixe os valores default;

deixe em branco;

Irá aparecer um quadro, com 1 compensação original (ainda sem segundas vias), 1 compensação já com pedido para segunda via e 2 compensações canceladas; Verifique que só na compensação original é possível o cancelamento desta;

o e verifique no quadro de pesquisa não tem 3 compensações anuladas;


1/2




O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: N-01); heque), deverá pedi-los ao




Compensation Receipts.

Gestão dos recibos de todas as compensações até à data. É possível a impressão de segunda via, sendo esta

Irá aparecer um quadro, com 1 compensação original (ainda sem segundas vias), 1 compensação já

Verifique que só na compensação original é possível o cancelamento desta; o e verifique no quadro de pesquisa não tem 3 compensações anuladas;



10. Verifique a opção Details em cada compensação. Peça ao avaliador para verificar consigo a veracidade dos dados;

11. Verifique a opção DetailsPDF, que exporta os detalhes de compensação para f12. Sabendo quer o número de recibo, quer as lojas

dados nos respectivos atributos de pesquisa.

Projecto Portal Gift.Certificates Sonae Sierra“Toolbox – Compensation Receipts”

em cada compensação. Peça ao avaliador para verificar consigo a

, que exporta os detalhes de compensação para fmero de recibo, quer as lojas que foram compensadas

dados nos respectivos atributos de pesquisa.


2/2

em cada compensação. Peça ao avaliador para verificar consigo a

, que exporta os detalhes de compensação para formato PDF; que foram compensadas, experimente inserir estes



Objectivo


Regras


2. O usuário deverá cumprir todos os cenários descritos;3. O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: O4. Caso o cenário requeira dados para preenchimento (Ex: número de c



Acesso






Descrição Gestão dos recibos de notas de crédito até à data. É possível a impressão de segunda via, sendo esta incrementada conforme as impressões.

Cenário O-01

1. No campo Country, seleccione a opção Portugal;2. No campo Mall, seleccione a opção Centro Colombo;3. O campo Store deixe em branco;4. No campo Receipt Date, deixe os valores 5. O campo Receipt Number deixe em branco;6. Pressione o botão Search; 7. Irá aparecer um quadro, com 1 nota de crédito original (ainda sem segundas vias) e 2 notas já com

segundas vias; 8. Verifique a opção Details em cada nota. Peça ao avaliador para verificar consigo a veracidade dos

dados; 9. Verifique a opção DetailsPDF, que exp

Projecto Portal Gift.Certificates Sonae Sierra“Toolbox – Compensation Credit Receipts


Serão distribuídas antes do início do teste, tantas folhas de avaliação quantos os cenários descritos em baixo, podendo estas serem preenchidas durante ou após o teste; O usuário deverá cumprir todos os cenários descritos; O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: OCaso o cenário requeira dados para preenchimento (Ex: número de cheque), deverá pedi




No canto superior esquerdo verifique que no campo User aparece o seu nome, e no campo aparece 8ª Avenida. Isto quererá dizer que neste momento está numa sessão sua, estando no contexto do centro 8ª Avenida, tendo permissão para executar operações sobr

lado esquerdo, na área de menu, seleccione a entrada Toolbox – Compensation Credit Receipts.

Gestão dos recibos de notas de crédito até à data. É possível a impressão de segunda via, sendo esta incrementada conforme as impressões.

, seleccione a opção Portugal; , seleccione a opção Centro Colombo; deixe em branco;

, deixe os valores default; deixe em branco;

Irá aparecer um quadro, com 1 nota de crédito original (ainda sem segundas vias) e 2 notas já com

em cada nota. Peça ao avaliador para verificar consigo a veracidade dos

, que exporta os detalhes de nota para formato

Projecto Portal Gift.Certificates Sonae Sierra nsation Credit Receipts”

1/2




O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: O-01); heque), deverá pedi-los ao




Compensation Credit Receipts.

Gestão dos recibos de notas de crédito até à data. É possível a impressão de segunda via, sendo esta

Irá aparecer um quadro, com 1 nota de crédito original (ainda sem segundas vias) e 2 notas já com

em cada nota. Peça ao avaliador para verificar consigo a veracidade dos

orta os detalhes de nota para formato PDF;



10. Sabendo quer número de recibo, quer as lojas a que foi dada a nota de crédito, experimente inserir estes dados nos respectivos atributos de pesquisa.

Cenário O-02

1. Pressione o botão New Credit Receipt

2. No campo Receipt insira o número de recibo, para o qual quer fazer uma nota de crédito. Questione o avaliador sobre este número;

3. Pressione o botão Search; 4. Confirme os dados apresentados pelo sistema. Converse com o avaliador sobre a veracidade dos

dados; 5. Pressione o botão Save; 6. Uma nova janela contendo um recibo da nota de crédito emitida poderá ser impressa;7. Confirme que o quadro passou a ter 2 notas de crédito originais.

Projecto Portal Gift.Certificates Sonae Sierra“Toolbox – Compensation Credit Receipts

Sabendo quer número de recibo, quer as lojas a que foi dada a nota de crédito, experimente inserir estes dados nos respectivos atributos de pesquisa.

New Credit Receipt; úmero de recibo, para o qual quer fazer uma nota de crédito. Questione

o avaliador sobre este número;

Confirme os dados apresentados pelo sistema. Converse com o avaliador sobre a veracidade dos

contendo um recibo da nota de crédito emitida poderá ser impressa;passou a ter 2 notas de crédito originais.

Projecto Portal Gift.Certificates Sonae Sierra nsation Credit Receipts”

2/2

Sabendo quer número de recibo, quer as lojas a que foi dada a nota de crédito, experimente inserir

úmero de recibo, para o qual quer fazer uma nota de crédito. Questione

Confirme os dados apresentados pelo sistema. Converse com o avaliador sobre a veracidade dos

contendo um recibo da nota de crédito emitida poderá ser impressa;



Objectivo




Regras




3. O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: P


avaliador;



Acesso









Descrição

Verificação de vendas, mínima, média e máxima por cliente empresa, tal como o seu historial.

Cenário P-01

1. Experimente pressionar o botão

2. Com os dados obtidos, experimente inserir diferentes dados no formul

3. Pressione sempre o botão Search Client Data

Projecto Portal Gift.Certificates Sonae Sierra“Toolbox – Search Buyer Companies”







O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: P





browser IE7;






lado esquerdo, na área de menu, seleccione a entrada Toolbox – Search Buyer Companies.


Experimente pressionar o botão Search Client Data;

Com os dados obtidos, experimente inserir diferentes dados no formulário de pesquisa;

Search Client Data, após alteração de formulário.


1/1





O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: P-01);








Search Buyer Companies.


ário de pesquisa;

, após alteração de formulário.



Objectivo


Regras


2. O usuário deverá cumprir todos os cenários descritos;3. O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: Q4. Caso o cenário requeira dados para preenchimento (Ex: número de c



Acesso




aparece 8ª Avenida. Isto quererá dizer que neste momento está numa sessão sua, estando no contexto do centro 8ª Avenida, tendo permissão para executar operações sobre este;


Descrição Gestão de recibos de todas as vendas até à data. É possível a impressão de segunda via, sendo esta incrementada conforme as impressões.

Cenário Q-01

1. No campo Country, seleccione a opção Portugal;2. No campo Mall, seleccione a opção Centro Colombo;3. O campo Sold To, deixe em branco;4. No campo Receipt Date, deixe os valores 5. O campo Receipt Number deixe em branco;6. Pressione o botão Search; 7. Irá aparecer um quadro, com 1 venda original (ainda sem segundas vias), 0 vendas já com pedido

para segunda via e 1 venda canceladas;8. Verifique que só na venda original é possível o cancelamento desta;9. Cancele a venda e verifique no quadro de pesquisa não tem 2 vendas anulad

Projecto Portal Gift.Certificates Sonae Sierra“Toolbox – Sale Receipts”


Serão distribuídas antes do início do teste, tantas folhas de avaliação quantos os cenários descritos em baixo, podendo estas serem preenchidas durante ou após o teste; O usuário deverá cumprir todos os cenários descritos; O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: QCaso o cenário requeira dados para preenchimento (Ex: número de cheque), deverá pedi




superior esquerdo verifique que no campo User aparece o seu nome, e no campo aparece 8ª Avenida. Isto quererá dizer que neste momento está numa sessão sua, estando no contexto do centro 8ª Avenida, tendo permissão para executar operações sobre este;

o lado esquerdo, na área de menu, seleccione a entrada Toolbox – Sale Receipts.

Gestão de recibos de todas as vendas até à data. É possível a impressão de segunda via, sendo esta incrementada conforme as impressões.

, seleccione a opção Portugal; , seleccione a opção Centro Colombo;

, deixe em branco; , deixe os valores default;

deixe em branco;

dro, com 1 venda original (ainda sem segundas vias), 0 vendas já com pedido para segunda via e 1 venda canceladas; Verifique que só na venda original é possível o cancelamento desta; Cancele a venda e verifique no quadro de pesquisa não tem 2 vendas anulad


1/2




O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: Q-01); heque), deverá pedi-los ao




Sale Receipts.

Gestão de recibos de todas as vendas até à data. É possível a impressão de segunda via, sendo esta

dro, com 1 venda original (ainda sem segundas vias), 0 vendas já com pedido

Cancele a venda e verifique no quadro de pesquisa não tem 2 vendas anuladas;



10. Verifique a opção Details em cada venda. Peça ao avaliador para verificar consigo a veracidade dos dados;

11. Verifique a opção DetailsPDF, que exporta os detalhes de venda para formato 12. Sabendo quer o número de recibo, quer a empresa ou público que

inserir estes dados nos respectivos atributos de pesquisa.

Projecto Portal Gift.Certificates Sonae Sierra“Toolbox – Sale Receipts”

em cada venda. Peça ao avaliador para verificar consigo a veracidade dos

, que exporta os detalhes de venda para formato Sabendo quer o número de recibo, quer a empresa ou público que foram compradores, experimente inserir estes dados nos respectivos atributos de pesquisa.


2/2

em cada venda. Peça ao avaliador para verificar consigo a veracidade dos

, que exporta os detalhes de venda para formato PDF; foram compradores, experimente



Objectivo




Regras




3. O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: R


avaliador;



Acesso









Descrição

Gestão dos comprovativos de pagamento por transferência bancária, de clientes empresa.

Cenário R-01

1. No campo Country, seleccione a opção Portugal;

2. No campo Mall, seleccione a opção Centro Colombo;

3. No campo Date, deixe os valores

4. O campo Search deixe em branco;


6. Irá aparecer um quadro, com 1 pagamento pendente e 2 já confirmados;

7. Poderá verificar o detalhe deste no campo

veracidade dos dados.

Projecto Portal Gift.Certificates Sonae Sierra“Toolbox – Payment Confirmation”







O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: R





browser IE7;



superior esquerdo verifique que no campo User aparece o seu nome, e no campo



o lado esquerdo, na área de menu, seleccione a entrada Toolbox – Payment Confirmation.


, seleccione a opção Portugal;

, seleccione a opção Centro Colombo;

, deixe os valores default;

deixe em branco;

Irá aparecer um quadro, com 1 pagamento pendente e 2 já confirmados;

Poderá verificar o detalhe deste no campo Status. Peça ao avaliador para verificar consigo a


1/1





O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: R-01);








Payment Confirmation.


. Peça ao avaliador para verificar consigo a



Objectivo




Regras




3. O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: S


avaliador;



Acesso









Descrição

Gestão de lojas aderentes ao programa Cheques

Cenário S-01

1. O campo Word deixe em branco;


3. Como resultado de pesquisa irá aparecer todas as lojas aderentes ao programa Cheques

4. Experimente utilizar o campo Word. O conteúdo deste campo irá ter impacto na pesquisa pelos

campos Mall e Store Name.

Cenário S-02

1. Pressione o botão Insert New Store

2. Verifique que só pode inserir lojas para o centro

3. No campo Store Name, seleccione a opção FOTO SPORT;

Projecto Portal Gift.Certificates Sonae Sierra“Mall Stores Participation”







O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: S





browser IE7;






o lado esquerdo, na área de menu, seleccione a entrada Mall Stores Participation.

de lojas aderentes ao programa Cheques-Prenda por centro dependendo do contexto.

deixe em branco;

resultado de pesquisa irá aparecer todas as lojas aderentes ao programa Cheques

Experimente utilizar o campo Word. O conteúdo deste campo irá ter impacto na pesquisa pelos

Insert New Store;

Verifique que só pode inserir lojas para o centro do seu contexto, neste caso o centro 8ª Avenida;

, seleccione a opção FOTO SPORT;


1/2





O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: S-01);








Mall Stores Participation.

Prenda por centro dependendo do contexto.

resultado de pesquisa irá aparecer todas as lojas aderentes ao programa Cheques-Prenda;

Experimente utilizar o campo Word. O conteúdo deste campo irá ter impacto na pesquisa pelos

do seu contexto, neste caso o centro 8ª Avenida;



4. No campo Date, seleccione uma data de início de participação. Questione o avaliador sobre esta

data;

5. No campo Bank Transfer seleccione a opção

bancária;

6. No campo NIB, preencher o NIB

7. Pressionar o botão Add to Program

8. Procurar a loja inserida, efectuand

9. Pressionar sobre o nome desta, para aceder ao modo de editar;

10. Alterar algum parâmetro de loja;

11. Pressionar o botão Save.

Projecto Portal Gift.Certificates Sonae Sierra“Mall Stores Participation”

e uma data de início de participação. Questione o avaliador sobre esta

seleccione a opção Yes, optando por pagamentos à loja por transferência

NIB da loja. Questionar o avaliador sobre este número;

Add to Program;

Procurar a loja inserida, efectuando nova pesquisa;

Pressionar sobre o nome desta, para aceder ao modo de editar;

Alterar algum parâmetro de loja;


2/2

e uma data de início de participação. Questione o avaliador sobre esta

, optando por pagamentos à loja por transferência

da loja. Questionar o avaliador sobre este número;



Objectivo


Regras


2. O usuário deverá cumprir todos os cenários descritos;3. O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: T4. Caso o cenário requeira dados para preenchimento (Ex: número de c



Acesso




aparece 8ª Avenida. Isto quererá dizer que neste momento está numa sessão sua, estando no contexto do centro 8ª Avenida, tendo permissão para executar operações sobre este;


Descrição Gestão de todas as encomendas de Chequespedido uma form já pré-formatada pela Casa da Moeda para encomenda de cheques. Quando a encomenda chega o grupo de cheques a que se refere, são marcados para venda e repostos nos

Cenário T-01

1. Pressionar o botão New GC Order

2. No campo Gift Certificate Value

3. No campo Total Gift Certificate

4. Pressionar o botão Preview Order

5. Um quadro resumo irá aparecer. Verifique com o avaliador a veracidade dos dados;6. Pressione o botão Order; 7. Consoante a numeração de cheque

cheques a encomendar. Ao mesmo temporequisitos da Casa da Moeda. Verificar com o avaliador a correcta formatação e a veracidade dos dados existentes na folha;

Projecto Portal Gift.Certificates Sonae Sierra“Order/Stock Management”


Serão distribuídas antes do início do teste, tantas folhas de avaliação quantos os cenários descritos em baixo, podendo estas serem preenchidas durante ou após o teste; O usuário deverá cumprir todos os cenários descritos; O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: TCaso o cenário requeira dados para preenchimento (Ex: número de cheque), deverá pedi




superior esquerdo verifique que no campo User aparece o seu nome, e no campo aparece 8ª Avenida. Isto quererá dizer que neste momento está numa sessão sua, estando no contexto do centro 8ª Avenida, tendo permissão para executar operações sobre este;

o lado esquerdo, na área de menu, seleccione a entrada Order/Stock Management.

Gestão de todas as encomendas de Cheques-Prenda à Casa da Moeda até à data. É gerado consoante o formatada pela Casa da Moeda para encomenda de cheques. Quando a encomenda

chega o grupo de cheques a que se refere, são marcados para venda e repostos nos

New GC Order; ate Value, seleccionar a opção 5 €;

Total Gift Certificate, inserir o valor 100. Iremos encomendar 100 cheques de 5 Order;

Um quadro resumo irá aparecer. Verifique com o avaliador a veracidade dos dados;

Consoante a numeração de cheque já existente em sistema, este irá apresentar os cheques a encomendar. Ao mesmo tempo é gerado uma folha Excel prérequisitos da Casa da Moeda. Verificar com o avaliador a correcta formatação e a veracidade dos


1/2




O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: T-01); heque), deverá pedi-los ao




Order/Stock Management.

Prenda à Casa da Moeda até à data. É gerado consoante o formatada pela Casa da Moeda para encomenda de cheques. Quando a encomenda

chega o grupo de cheques a que se refere, são marcados para venda e repostos nos stocks de cada centro.

, inserir o valor 100. Iremos encomendar 100 cheques de 5 €;


existente em sistema, este irá apresentar os novos números de uma folha Excel pré-formatada segundo os

requisitos da Casa da Moeda. Verificar com o avaliador a correcta formatação e a veracidade dos



Cenário T-02

1. Pressionar o botão Send GC to Mall

2. No campo Mall, seleccionar a opção Centro Colombo;3. No campo Gift Certificate Status

4. No campo Gift Certificate Value

5. No campo Gift Certificate, preencher o campo números;

6. Pressionar o botão Search; 7. Um quadro resumo irá aparecer. Verifique com o avaliador a veracidade dos dados;8. Pressione o botão Send; 9. Os cheques após chegarem da Casa da Moeda

a serem enviados para este centro.

Projecto Portal Gift.Certificates Sonae Sierra“Order/Stock Management”

Send GC to Mall; a opção Centro Colombo;

Gift Certificate Status, seleccionar a opção Ordered; Gift Certificate Value, seleccionar a opção 5 €;

, preencher o campo From e To. Questionar o avaliador sobre estes


após chegarem da Casa da Moeda ficam assim associados ao Centro Colombo, e prontos a serem enviados para este centro.


2/2

. Questionar o avaliador sobre estes


ficam assim associados ao Centro Colombo, e prontos



Objectivo




Regras




3. O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: U


avaliador;



Acesso









Descrição

O valor total de vendas, para um dado período de tempo, agrupado por cliente privado e empresarial, num

dado centro ou país.

Cenário U-01

1. Seleccionar no campo From e

avaliador sobre as datas a utilizar.


3. Seleccionar no campo Centre, a opção

4. Pressionar o botão Generate.

5. Na mesma janela, irá aparecer um

a. O intervalo de tempo de pesquisa

b. O país de pesquisa;

c. O centro de pesquisa;

d. O valor de report requerido.

6. Verificar com o avaliador se o

Projecto Portal Gift.Certificates Sonae Sierra“Reports – Sales by Centre/Country”







O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: U





browser IE7;






o lado esquerdo, na área de menu, seleccione a entrada Reports – Sales by Centre/Country


e To, as data de início e fim para intervalo de pesquisa. Questione o


Country, a opção Portugal.

, a opção All.

Na mesma janela, irá aparecer um iframe de report contendo:

O intervalo de tempo de pesquisa

requerido.

Verificar com o avaliador se o report gerado apresenta a correcta informação;


1/2





O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: U-01);








Centre/Country.


, as data de início e fim para intervalo de pesquisa. Questione o

gerado apresenta a correcta informação;



7. Será possível exportar este report

8. Poderá experimentar outras datas para intervalo de pesquisa.

Cenário U-02




3. Seleccionar no campo Centre, a opção Centro Colombo.



a. O intervalo de tempo de pesquisa







Projecto Portal Gift.Certificates Sonae Sierra“Reports – Sales by Centre/Country”

report para outros formatos, como PDF, Excel e

Poderá experimentar outras datas para intervalo de pesquisa.


iador sobre as datas a utilizar.


, a opção Centro Colombo.


O intervalo de tempo de pesquisa

requerido.



datas para intervalo de pesquisa.


2/2

e Word;



e Word;



Objectivo




Regras




3. O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: V


avaliador;



Acesso









Descrição

Os stocks online, agrupados por tipo de cheque, num dado centro ou país.

Cenário V-01



3. Seleccionar no campo Type, a opção 10



a. O país de pesquisa;

b. O centro de pesquisa;

c. O tipo de cheque




8. Poderá experimentar outros tipos

Projecto Portal Gift.Certificates Sonae Sierra“Reports – Stocks by Centre/Country”







O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: V





browser IE7;




quererá dizer que neste momento está numa sessão sua, estando no


o lado esquerdo, na área de menu, seleccione a entrada Reports – Stocks b

Os stocks online, agrupados por tipo de cheque, num dado centro ou país.


, a opção All.

Seleccionar no campo Type, a opção 10€. (Só irá dar informação de stock a cheques de 10


requerido.

Verificar com o avaliador se o report gerado apresenta a correcta informação


outros tipos de cheque.

Projecto Portal Gift.Certificates Sonae Sierra ”

1/2





O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: V-01);








Stocks by Centre/Country.

a cheques de 10€)

apresenta a correcta informação;

e Word;



Cenário V-02



3. Seleccionar no campo Type, a opção

cheque);





c. O tipo de cheque





Projecto Portal Gift.Certificates Sonae Sierra“Reports – Stocks by Centre/Country”



Seleccionar no campo Type, a opção All. (Irá dar informação de stock

janela, irá aparecer um iframe de report contendo:

requerido.




Projecto Portal Gift.Certificates Sonae Sierra ”

2/2

stock para todos os valores de


e Word;



Objectivo




Regras




3. O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: W


avaliador;



Acesso









Descrição

Vendedor com maior valor de venda, para um dado período de tempo, agrupado por cliente privado e


Cenário W-01


avaliador sobre as datas a utilizar;



4. Seleccionar no campo Client, a op

5. Pressionar o botão Generate;


a. O intervalo de tempo de pesquisa;



d. O tipo de cliente de pesquisa;

Projecto Portal Gift.Certificates Sonae Sierra“Reports – Best Seller by Centre/Country







O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: W





browser IE7;






esquerdo, na área de menu, seleccione a entrada Reports – Best Seller b






, a opção All;

Seleccionar no campo Client, a opção Public;


O intervalo de tempo de pesquisa;

O tipo de cliente de pesquisa;

Projecto Portal Gift.Certificates Sonae Sierra y Centre/Country”

1/2





O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: W-01);








Best Seller by Centre/Country.





e. O valor de report requerido.




Cenário W-02




3. Seleccionar no campo Centre, a opção Centro Colombo;

4. Seleccionar no campo Client, a opção All;











Projecto Portal Gift.Certificates Sonae Sierra“Reports – Best Seller by Centre/Country

requerido.







, a opção Centro Colombo;

Seleccionar no campo Client, a opção All;




requerido.





2/2


e Word;



e Word;



Objectivo




Regras




3. O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: X


avaliador;



Acesso









Descrição

Cliente empresarial com maior valor de compra, para um dado período de tempo, num dado centro ou país.

Cenário X-01













Projecto Portal Gift.Certificates Sonae Sierra“Reports – Best Client by Centre/Country







O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: X





browser IE7;






o lado esquerdo, na área de menu, seleccione a entrada Reports – Best Client b





, a opção All;



requerido.




1/2





O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: X-01);








Best Client by Centre/Country.


as data de início e fim para intervalo de pesquisa. Questione o


e Word;




Cenário X-02













8. Poderá experimentar outras datas para intervalo de pesquis

Projecto Portal Gift.Certificates Sonae Sierra“Reports – Best Client by Centre/Country








requerido.





2/2



e Word;


by Centre/Country”


Objectivo




Regras




3. O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: Y


avaliador;



Acesso









Centre/Country.

Descrição

Tipo de cheque com maior saída, para um dado período de tempo, agrupado por cliente privado e


Cenário Y-01





4. Seleccionar no campo Client, a opção Public;





Projecto Portal Gift.Certificates Sonae Sierra“Reports – Certificate Type w/ Best Sales







O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: Y





browser IE7;






o lado esquerdo, na área de menu, seleccione a entrada Reports – Certificate Type w/ Best Sales b


país.




, a opção All;

o campo Client, a opção Public;



Projecto Portal Gift.Certificates Sonae Sierra Certificate Type w/ Best Sales

1/2





O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: Y-01);








Certificate Type w/ Best Sales by




by Centre/Country”








Cenário Y-02





4. Seleccionar no campo Client, a opção All;











Projecto Portal Gift.Certificates Sonae Sierra“Reports – Certificate Type w/ Best Sales


requerido.








Seleccionar no campo Client, a opção All;




requerido.




Projecto Portal Gift.Certificates Sonae Sierra Certificate Type w/ Best Sales

2/2


e Word;



e Word;


Sales by Centre/Country”


Objectivo




Regras




3. O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: Z


avaliador;



Acesso









Sales by Centre/Country.

Descrição

Tempo médio para um tipo de cheque, entre a sua encomenda e a sua venda, num dado centro ou país.

Cenário Z-01








c. O tipo de cheque



Projecto Portal Gift.Certificates Sonae Sierra“Reports – Avg Time Between Order and







O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: Z





browser IE7;






o lado esquerdo, na área de menu, seleccione a entrada Reports – Avg Time Between Order and



, a opção All.

Seleccionar no campo Type, a opção 10€. (Só irá dar informação de stock a cheques de 10


requerido.


Projecto Portal Gift.Certificates Sonae Sierra Time Between Order and

1/2





O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: Z-01);








g Time Between Order and


a cheques de 10€)



Sales by Centre/Country”




Cenário Z-02




cheque);





c. O tipo de cheque





Projecto Portal Gift.Certificates Sonae Sierra“Reports – Avg Time Between Order and





Seleccionar no campo Type, a opção All. (Irá dar informação de stock


requerido.




Projecto Portal Gift.Certificates Sonae Sierra Time Between Order and

2/2

e Word;

stock para todos os valores de

nformação;

e Word;


Centre/Country”


Objectivo




Regras




3. O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: AA

4. Caso o cenário requeira dados para preenchimento (Ex: número de

avaliador;



Acesso








5. Do lado esquerdo, na área de

Centre/Country.

Descrição

Tempo médio de rotação de stock, num dado centro ou país.

Cenário AA-01







c. O valor de report requerido.




Projecto Portal Gift.Certificates Sonae Sierra“Reports – Avg Time for Stock Rotation b







O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: AA




t com a designação Portal Gift.Certificates. Faça duplo

browser IE7;






Do lado esquerdo, na área de menu, seleccione a entrada Reports – Avg Time for Stock Rotation by

, num dado centro ou país.


, a opção All.


requerido.




Projecto Portal Gift.Certificates Sonae Sierra Avg Time for Stock Rotation by

1/2





O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: AA-01);

cheque), deverá pedi-los ao







Avg Time for Stock Rotation by

a correcta informação;

e Word;


Centre/Country”


Cenário AA-02







c. O valor de report requerido.




Projecto Portal Gift.Certificates Sonae Sierra“Reports – Avg Time for Stock Rotation b




requerido.




Projecto Portal Gift.Certificates Sonae Sierra Avg Time for Stock Rotation by

2/2


e Word;



Objectivo




Regras




3. O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: AB


avaliador;



Acesso









Descrição

Detalhe e localização de um ou mais cheques

Cenário AB-01

1. Inserir no campo From e To dois



4. Seleccionar no campo Status, a opção




a. O intervalo de pesquisa de cheques



d. O estado de cheque para pesquisa;

e. O tipo de cheque para pesquisa;

Projecto Portal Gift.Certificates Sonae Sierra“Reports – Certificates Overview”







O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: AB





browser IE7;






Do lado esquerdo, na área de menu, seleccione a entrada Reports – Certificates Overview

Detalhe e localização de um ou mais cheques.

dois números de cheque. Peça ao avaliador estes números;


, a opção All.

, a opção All;

Seleccionar no campo Type, a opção 10€. (Só irá dar informação de cheques de 10

la, irá aparecer um iframe de report contendo:

intervalo de pesquisa de cheques;

O estado de cheque para pesquisa;

para pesquisa;


1/2





O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: AB-01);








Certificates Overview.

de cheque. Peça ao avaliador estes números;

cheques de 10€)



f. O valor de report requerido.




Cenário AB-02

1. Inserir no campo From e To dois números de cheque. Peça ao avaliador estes números;



4. Seleccionar no campo Status, a opção




a. O intervalo de pesquisa de cheques;



d. O estado de cheque para pesquisa;

e. O tipo de cheque para pesquisa;

f. O valor de report requerido.




Projecto Portal Gift.Certificates Sonae Sierra“Reports – Certificates Overview”

requerido.







, a opção On Sale;

Seleccionar no campo Type, a opção All.


O intervalo de pesquisa de cheques;

O estado de cheque para pesquisa;

O tipo de cheque para pesquisa;

requerido.





2/2


e Word;



e Word;



Objectivo




Regras




3. O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: AC


avaliador;



Acesso









Descrição

Gere as permissões de utilizador, a nível de administrador, gestor de centro ou vendedor. Faz a gestão do

tipo de cheque por país. Parametriza alguns valores

exemplo, o valor de alguns serviços extra na venda.

Cenário AC-01

1. No quadro Envelopes Configuration

2. Pressionar o botão Save.

3. Tentar alterar o campo para valores não

Cenário AC-02

1. No quadro Access Settings, adicionar no subquadro Master Account, um endereço de email;

2. Pressionar o botão Add;

3. Verificar que o endereço de email foi adicionado ao quadro de endereços;

4. Seleccionar o endereço adicionado;

Projecto Portal Gift.Certificates Sonae Sierra“Configure Application”







O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: AC





browser IE7;






Do lado esquerdo, na área de menu, seleccione a entrada Configure Application


tipo de cheque por país. Parametriza alguns valores decorrentes da operação do portal, tendo como

exemplo, o valor de alguns serviços extra na venda.

Envelopes Configuration, alterar o valor unitário de envelope;

Tentar alterar o campo para valores não unitários.

, adicionar no subquadro Master Account, um endereço de email;

Verificar que o endereço de email foi adicionado ao quadro de endereços;

Seleccionar o endereço adicionado;


1/2





O usuário deverá identificar em cada folha de avaliação, qual o cenário que está a avaliar (Ex: AC-01);








Configure Application.


decorrentes da operação do portal, tendo como

, adicionar no subquadro Master Account, um endereço de email;



5. Pressionar o botão Remove;

6. Verificar que o endereço de email já foi removido do quadro;

7. Tentar adicionar endereços não válidos.

Cenário AC-03

1. No quadro Gifts Values Per Country

2. No campo Gift Value, inserir o valor

3. Pressionar o botão Add;

4. Verificar que o valor de cheque

5. Mudar de país no campo Country

6. Seleccionar o país Portugal;

7. Seleccionar o valor 60 no quadro;

8. Pressionar o botão Remove;

9. Verificar que o valor já foi removido do quadro.

Projecto Portal Gift.Certificates Sonae Sierra“Configure Application”

Verificar que o endereço de email já foi removido do quadro;

Tentar adicionar endereços não válidos.

Gifts Values Per Country, seleccionar no campo Country Portugal;

, inserir o valor 60;

Verificar que o valor de cheque foi inserido no quadro e só está associado ao país Portugal;

Country, e verificar que o valor adicionado não aparece

quadro;

Verificar que o valor já foi removido do quadro.


2/2

Portugal;

foi inserido no quadro e só está associado ao país Portugal;

aparece;

projecto cheques-prenda sonae sierra - universidade nova de … · 2015-10-03 · fig. 9 - etapas...

Documents