SlideShare uma empresa Scribd logo
1 de 50
Baixar para ler offline
Universidade Federal de Campina Grande
Centro de Engenharia Elétrica e Informática
Curso de Ciência da Computação




                       Dalton Cézane Gomes Valadares
                           Diego Renato dos Santos
                           Thiago Gondim Ribeiro
              WUT2S (Web Usability Test Task Scheduler)
            Ferramenta web para realização de testes de usabilidade




                               Campina Grande
                                   2007
Dalton Cézane Gomes Valadares
               Diego Renato dos Santos
               Thiago Gondim Ribeiro


  WUT2S (Web Usability Test Task Scheduler)
Ferramenta web para realização de testes de usabilidade



                                Monografia apresentada ao Curso de
                                Ciência da Computação da UFCG, como
                                requisito para a obtenção parcial do grau
                                de    BACHAREL       em     Ciência   da
                                Computação.


                                     Orientador: Jacques Philippe Sauvé
                Doutor em Engenharia Elétrica - University of Waterloo




                    Campina Grande
                         2007
Introdução


      O WUT2S (Web Usability Test Task Scheduler) surgiu da necessidade de
informatização do processo de realização de testes de usabilidade do Laboratório
de Interface Homem-Máquina (LIHM) do Parque Tecnológico da Paraíba
(PaqTc-Pb).
      Um teste de usabilidade, no contexto da computação, é um método para
verificar a facilidade de uso de uma interface para os seus usuários finais.
Possíveis usuários do produto a ser testado devem utilizar o mesmo em um
ambiente monitorado. As ações desses usuários, ao utilizarem o produto, são
gravadas e anotadas para depois serem analisadas por um avaliador. Os testes
seguem um roteiro que possuem várias tarefas a serem executadas no produto
(através das interfaces do mesmo). Os usuários são instruídos para se sentirem à
vontade em relação ao produto testado: devem falar ou expressar qualquer
desconforto que venham a sentir. Após a análise dos resultados obtidos durante
o teste, algumas recomendações são geradas em relação a possíveis problemas
encontrados nas interfaces do produto.
      O Laboratório de Interface Homem-Máquina, do PaqTc-Pb, presta
serviços de projeto e avaliação caracterizados por uma série de atividades
voltadas para uma integração mais efetiva da Universidade com o setor
empresarial, em especial com a indústria. Dessa forma, tem oferecido às
organizações interessadas uma gama de serviços de consultoria a projetos,
iniciativas de implantação de tecnologias e/ou recomendações relativas a
tomadas de decisões quanto à estruturação/aperfeiçoamento de ambientes e
contextos de trabalho. Nesses serviços estão incluídos os testes de usabilidade
para avaliação de produtos (sistemas desktop, sistemas web ou aplicações
móveis).
      O projeto é um sistema web para informatizar o trabalho de obtenção de
informação a respeito de testes relacionados com a área de Interface Homem-
Máquina. Os testes de usabilidade são realizados para se ter uma idéia do grau
de satisfação do usuário ao utilizar o produto (software) testado.
      Todos os testes, atualmente, são realizados de forma manual, o que faz
com que o processo de colheita de dados, resultantes da observação dos testes, e
a análise dos mesmos demandem um pouco mais de trabalho e de tempo, se
comparado ao mesmo processo estando informatizado, já que grande parte da
informação fica armazenada no computador, ao invés de vários papéis com
formulários preenchidos, observações e outros dados relevantes à análise da
ferramenta testada.
      Os testes de usabilidade são realizados por pessoas que provavelmente
utilizarão o produto em questão, ou que apresentam um perfil semelhante, e são
observados por alguns avaliadores. Os avaliadores observam todo o
comportamento do usuário que está testando o produto e registram tudo o que
acontece durante o teste, como: número de erros do usuário para executar
determinada tarefa com o produto, tempo que o usuário leva para realizar todo o
roteiro de teste, etc. Toda a informação obtida dos testes fica registrada em
papéis que contêm formulários. Ao término de várias sessões de testes, cada
avaliador tem uma grande quantidade de formulários que devem ser
armazenados para depois serem analisados.
      Pode-se entender como problema a grande quantidade de informação a ser
tratada “manualmente” e armazenada em vários arquivos físicos (vários
formulários - como já citados -, notas de observação, etc.). Esse problema vem a
ser solucionado com a construção do sistema web, pois este passa a armazenar
toda a informação no computador, automatizando grande parte do processo de
acompanhamento de testes de usabilidade realizados no LIHM do PacTc.
      O sistema permite cadastrar e consultar usuários, produtos, tarefas e
outras “entidades” envolvidas em um teste de usabilidade, bem como
acompanhar todo o teste, registrando as informações de maior relevância
observadas durante a execução deste.
Para construção do sistema foi utilizada a linguagem ASP .NET que faz
parte do framework .NET 2.0 da Microsoft. A parte lógica foi desenvolvida na
linguagem C#, também utilizando o .NET 2.0. Para o desenvolvimento o
ambiente utilizado foi o Visual Studio 2005, também da Microsoft, e a
persistência de dados é feita através do sistema de banco de dados MySQL.
Algumas funcionalidades apresentadas na interface web foram desenvolvidas
em JavaScript utilizando AJAX.
      O documento se encontra divido em cinco seções: na primeira é
apresentado o contexto do projeto, citando, por exemplo, o perfil dos usuários e
o ambiente de execução; na segunda seção, a fundamentação teórica é abordada,
mostrando os principais conceitos e métodos utilizados no desenvolvimento do
projeto; a terceira seção descreve a metodologia aplicada durante todo o projeto,
com os processos e as ferramentas utilizadas; a penúltima seção apresenta os
resultados obtidos com o projeto, desde o início do desenvolvimento até a
conclusão do mesmo; e, por fim, a última seção é uma conclusão sobre tudo que
foi obtido, envolvendo nível de satisfação do cliente, possíveis dificuldades
encontradas, etc.
Contexto do Projeto


Eustáquio Rangel, doutor em Engenharia Elétrica pela Universidade Federal da
Paraíba – UFPB, é avaliador no Laboratório de Interface Homem-Máquina –
LIHM, localizado no Parque Tecnológico da Paraíba. Entre as atividades
comuns, está a realização de baterias de testes (convencionais) de usabilidade.
         Nesses testes de usabilidade, indivíduos que representam uma classe de
usuários em potencial de um determinado produto (comumente software)
possam experimentar a sua utilização. O grau de facilidade com que esses
usuários de teste conseguem lidar com o produto é um indicativo da qualidade
de sua interface. Para que os resultados possam ser representativos para a
precisão da avaliação, é necessária a realização do mesmo teste com uma
quantidade mínima de usuários, e em cada teste é necessária a coleta de
informações relacionadas ao tempo (duração, freqüência de determinados
eventos, etc.), assim como em relação ao “espaço”, por exemplo a posição da
tela onde o usuário tem maior dificuldade de encontrar algum controle, etc.
         Esses testes comumente geram um volume elevado de dados coletados,
inclusive para uma quantidade pequena de testes. O modo tradicional de coleta
desses dados é através de filmagem, mas também através de forma manuscrita.
Não é incomum situações em que o mesmo avaliador era responsável por
manusear mais de um cronômetro convencional, formulário em papel, e ainda
ter necessidade de utilizar o microfone para se comunicar com o usuário de
teste.
         Para diminuir os riscos de perda de informação, há a necessidade de uma
ferramenta integrada para aumentar a produtividade do avaliador em sua
operação de coleta de dados. A forma mais desejável era através de um sistema
computacional.
         De preferência, o sistema deveria ser executado através do browser,
através da web, devido a diversos motivos:
• possibilidade de essa aplicação poder ser utilizada em ambientes
               distintos do LIHM;
          • não haver necessidade de instalação em diversas máquinas,
               bastando ser instalado em uma quantidade inferior de servidores;
          • possibilidade do compartilhamento de informações em localidades
               distantes geograficamente.
      Apesar de o sistema desejado ter de ser via web, ele não poderia ser
significativamente lento, pois quanto maior a diferença de tempo entre um
evento observado e seu registro, menos precisos são os resultados que serão
avaliados após o teste. O cliente, em experiências semelhantes com equipes
anteriores, recomendou fortemente evitar a utilização de JSP (Java Server
Pages), se essa tecnologia causasse perda de desempenho em relação ao termpo
de resposta.
      Uma restrição inerente de o sistema executar através da web é a
impossiblidade da garantia de interação do sistema de coleta através de
processos em execução na máquina do usuário de teste, como por exemplo aviso
de que o tempo previsto para uma tarefa foi encerrado.
      Além disso, também há o interesse de essa ferramenta servir como uma
agenda de atividades, para uso no LIHM e em outras instituições que não
necessariamente realizem testes de usabilidade.
      Outra característica dispensável, porém atrativa era o desenvolvimento da
ferramenta por alunos da Universidade Federal de Campina Grande, devido ao
histórico de cooperação entre essa instituição e o Parque Tecnológico,
fomentando a atuação de alunos em diversos problemas, incentivando o
desenvolvimento do seu conhecimento na realização de sistemas utilizáveis em
situações reais.
      Por essas características, o problema de construir a ferramenta de
execução de testes de usabilidade foi disponibilizada no rol de alternativas para
a disciplina de Projeto 1 e, por conseguinte, Projeto 2, sendo conduzida por:
• Eustáquio Rangel, como cliente;
   • Dalton Cézane Gomes Valadares, Diego Renato dos Santos e Thiago
      Gondim Ribeiro, como desenvolvedores;
   • Francilene Garcia, como professora da disciplina Projeto 1;
   • Jacques Sauvé, como professor da disciplina Projeto 2.


Ferramentas semelhantes


      Existem outras ferramentas de software que serve para acompanhar a
realização de testes de usabilidade. O Usability Test Data Logger é um software
baseado em macros do Microsoft Excel que permite a execução de todo o cliclo
dos testes de usabilidade, desde o planejamento e a realização, até a síntese de
dados. É inegável que ele possui características úteis para a os testes do LIHM,
porém não é adaptável a um sistema distribuído através da rede, além de não é
bastante flexível para se adaptar ao processo de realização de testes adotado pelo
LIHM.
Uma das telas do Usability Datalogger


      A empresa TechSmith também desenvolve ferramentas para a realização
de testes de usabilidade, chamadas de Morae (modo standalone) e UserVue
(web). Porém, ambas não são gratuitas, contrariando a prioridade por
ferramentas não-proprietárias no LIHM. O mesmo vale para a UTE, um sistema
para o mesmo fim, produzida pela MindDesign Systems.
      Em relação às operações de cadastro de atividades, estilo agenda, foi
utilizada como referência a ferramenta TaskTimer. Ela permite o gerenciamento
de atividades por categoria, relevância, além de ter um banco de dados integrado
para o intercâmbio de informações entre os diversos usuários do sistema.
Adicionalmente, ainda há a funcionalidade de integrar essas informações na
forma de projeto, e assim avaliar o desempenho de funcionários através do
cumprimento de metas. Infelizmente, a ferramenta também é proprietária,
permitindo seu uso gratuito apenas para uma quantidade finita de vezes.
      Atuando em campos semelhantes na área de avaliação de interface
homem-máquina, há outras ferramentas desenvolvidas por alunos da
Universidade Federal de Campina Grande,:
      O WebQuest, que também é uma ferramenta acessível pela web
responsável pela obtenção de dados subjetivos sobre a percepção de um usuário
de teste sobre o produto a ser testado. Com o auxílio do WebQuest, é possível se
traçar um perfil de usuário e na sondagem da satisfação subjetiva de usuários de
sistemas interativos.
      O Fermint também é outra ferramenta que facilita é útil como um aliado
da realização de testes de usabilidade. O Fermint permite se avaliar diretamente
as possíveis falhas existentes em interfaces do produto-alvo, tal como um
software. Associada ao WUT2S, pode auxiliar o planejamento do roteiro de teste.
Fundamentação Teórica


Plataforma .NET


Utilizamos a plataforma .NET, a qual oferece uma alternativa de ambiente para
produzir aplicações Windows e Web, executando-as nos mais diversos
dispositivos (PCs, Palms, telefones celulares, etc). A Microsoft torna a infra-
estrutura de suporte ao .NET amplamente disponível. O framework de suporte
pode ser baixado e instalado livremente.



O framework .NET



O framework .NET, base da plataforma .NET, é uma plataforma de programação
para desenvolvimento de aplicações essencialmente composto de duas partes:

· Uma engine de execução chamada CLR;


· Uma biblioteca de classes que disponibiliza as principais funções de
programação.



O código das aplicações .NET é compilado para MSIL (Microsoft Intermediate
Language) e é armazenado em um arquivo chamado assembly. Em tempo de
execução, o assembly é compilado para o seu estado final pela CLR. Enquanto
está ativa, a CLR proporciona checagem de tipo (type-safety checks) e outras
tarefas de run-time.

Aplicações que rodam sob o CLR são chamadas aplicações de código
gerenciado porque o CLR responsabiliza-se por tarefas que normalmente seriam
de responsabilidade da aplicação. O assembly possui todas as informações de
que o CLR precisa para rodar a aplicação. O CLR cuida dinamicamente do
registro de componentes



Introdução ao ASP.NET

O ASP.NET é uma parte importante do framework .NET, mas trata-se
simplesmente de uma parte. Faz-se necessário entender o restante do framework.

Usa-se o ASP.NET para criar aplicações Web e Web Services que rodam sob o
IIS (Internet Information Services). O que torna o ASP.NET especial é o fato
dele ser fortemente integrado com ferramentas de programação, acesso à dados e
segurança.

O ASP.NET proporciona um alto nível de consistência no desenvolvimento de
aplicações. Como já ressaltado, O ASP.NET, como já dito, é parte do framework
.NET e composto de diferentes componentes:

· Visual Studio .NET Web Development tools. Inclui ferramentas visuais para
desenvolvimento de páginas Web, templates de aplicação e ferramentas de
deployment;

Oferece tudo o que é preciso para qualquer tipo de aplicação para Web, seja
Design, código, componente, Web Service, camada de aplicação ou negócio;


Incorpora nativamente diversas linguagens de programação, tais como: Visual
Basic, Visual C++, J#, Cobol (inclusive) e C# (a qual usamos ao longo do
desenvolvimento deste projeto).


· System.Web namespaces. Fazem parte do frameWork .NET e incluem classes
que tratam ítens específicos do mundo Web, tais como requisições HTTP,
respostas (responses), browsers e e-mail;
Organizada em namespaces, sua biblioteca de classes fornece acesso a todas as
funcionalidades da CLR . Cada namespace contém um grupo de classes
relacionadas. A tabela abaixo sintetiza os namespaces de maior interesse aos
programadores Web.

Categori
           Namespaces               Utilização
a

                                    Todos os tipos
                                    comuns de
                                    dados,
                                    incluindo
                                    strings, arrays
                                    e tipos
                                    númericos.
                                    Estas classes
                                    incluem
Tipos                               métodos para
           System
Comuns                              conversão de
                                    tipos,
                                    manipulação
                                    de strings e
                                    arrays,
                                    funções
                                    matemáticas e
                                    geração
                                    aleatória de
                                    números.

Acesso à   System.Data,             Estas classes
Dados       System.Data.Common, incluem
            System.Data.OleDb,       métodos de
            System.Data.SqlClient, conxão à
            System.Data.SqlTypes     bancos de
                                     dados,
                                     execução de
                                     comandos,
                                     recuperação e
                                     modificação
                                     de dados.

                                     Classe para
Debuggin
            System.Diagnostics       Debugging e
g
                                     tracing.

                                     Métodos para
                                     acesso so
                                     sistema de
                                     arquivos.
                                     Incluem
            System.IO,
Acesso ao                            métodos de
            System.IO.IsolatedStor
Sistema                              leitura e
            age,
de                                   escrita de
            System.DirectoryServic
Arquivos                             arquivos e
            es
                                     outras
                                     operações
                                     sobre o
                                     sistema de
                                     arquivos.
Comunicação
                                    através da
                                    internet
                                    utilizando
                                    protocolos de
                                    baixo nível,
            System.Net,             tais como
Rede
            System.Net.Sockets      TCP/IP. Estas
                                    classes são
                                    utilizadas para
                                    criação de
                                    aplicações
                                    ponto-a-ponto
                                    (peer-to-peer).

            System.Security,
            System.Security.Crypto Autenticação e
            graphy,                 autorização de
Seguranç
            System.Security.Permis usuários além
a
            sions,                  de encriptação
            System.Security.Policy, de dados.
            System.Web.Security

            System.Web,             Classes para
            System.Web.Caching,     criação e
            System.Web.Configurat publicação de
Aplicaçõe
            ion,                    componentes
s WEB
            System.Web.Hosting,     que podem ser
            System.Web.Mail,        acessados
            System.Web.SessionSta através da
te, System.Web.UI,       internet. São
              System.Web.UI.Design, as principais
              System.Web.UI.WebCo classes
              ntrols,                  utilizadas para
              System.Web.UI.HtmlC a criação de
              ontrols                  Web Services
                                       ASP.NET.

              System.Windows.Form Classes para
Aplicaçõe
              s,                       criação de
s
              System.Windows.Form aplicações
Windows
              s.Design                 Windows.

              System.Xml,
                                       Criação e
              System.Xml.Schema,
                                       acesso a
XML           System.Xml.Serializati
                                       arquivos
              on, System.Xml.Xpath,
                                       XML.
              System.Xml.Xsl




· Server Controls e HTML Controls . São componentes visuais utilizados para
obter informações e proporcionar respostas aos usuários da aplicação.

Adicionalmente, O ASP.NET também utiliza componentes de programação mais
gerais. Eles não fazem parte do ASP.NET mas são ítens chave para a sua
utilização:

· Microsoft Internet Information Services (IIS). Hospeda as aplicações Web.
Todo o processamento é feito no servidor, onde encontra-se o Internet
Information Server (IIS)
· Visual Basic.NET, linguagens de programação Jscript e C# (a qual usamos
ao longo do desenvolvimento do projeto). Estas três linguagens têm suporte
integrado no Visual Studio.NET.


· FrameWork .NET. É um conjunto completo de classes. Elas incluem classes
ASP.NET, propriamente ditas, bem como outras classes de acesso a arquivos,
conversão de tipos, manipulação de arrays e strings e assim por diante


· ADO.NET. Este componente fornece acesso ao Microsoft SQL Server e outros
bancos de dados acessados via ODBC.


· Microsoft Application Center Test (ACT) . Este componente do Visual
Studio.NET fornece um meio automatizado para fazer testes de stress com a
aplicação.



Ferramentas adicionais


      No ASP .NET, mais especificamente no Visual Studio .NET, contamos
com o Server Explorer e com o Solution Explorer.


      - Server Explorer: excelente recurso, com o qual pode-se verificar todos
os recursos existentes no computador. Com ele, pode-se, inclusive, criar banco
de dados, tabelas, consultas, funções e Stored Procedures, e até, fazer a
nanutenção de todos os registros de uma tabela. Utilizando-se de qualquer BD
disponível.


      - Solution Explorer: ferramenta que permite administrar todos os arquivos
contidos na solução.
OOP


       A programação Orientada a Objetos (OOP) é padrão em todas as
linguagens .NET e permite desenvolvimento estruturado, reaproveitamento de
códigos, rotinas, classes e objetos.


Deployment


       O processo de distribuição (Deploy) de uma aplicação ASP .NET é
simples: copia-se os arquivos necessários para o servidor e cria-se o diretório
virtual.


Provedores


Faz-se necessário ter Windows 2000 ou superior e, o Framework instalado.


Onde rodar


Em qualquer navegador, independentemente de fabricante ou versão


Principais pontos envolvidos no processo de compilação de uma aplicação
ASP.NET 2.0:

Modelo de Código no ASP.NET 2.0

O ASP.NET 2.0 suporta dois modelos de código, code-inline e code-behind.


Com relação ao modelo code-behind, no ASP.NET 2.0 o arquivo de código é
uma implementação “parcial”. O arquivo code-behind segue o novo modelo de
Partial Class. As classes parciais contém todo código implementado pelo
desenvolvedor e omite o código gerado automaticamente pelo Visual Studio.
Quando uma página ASPX com o novo modelo de code-behind é chamada, o
ASP.NET 2.0 combina o arquivo ASPX (a qual contém a interface gráfica) e a
classe parcial numa única classe ao invés de duas classes separadas.
As classes parciais usam uma palavra-chave (Partial no C#) para indicar que o
código nesta classe deve ser mesclado com outra classe quando em modo
runtime. De maneira semelhante o arquivo ASPX utiliza uma diretiva
CompileWith para indicar o arquivo de código associado.


O modelo de herança é simplificado porque o arquivo de código (code-behind)
não precisa conter as definições dos controles da página ASPX. Desta forma, o
arquivo de código pode acessar automaticamente qualquer controle na página
sem a necessidade de código declarativo. Isto é possível porque o Runtime do
ASP.NET 2.0 insere automaticamente as declarações exigidas para os controles
e eventos no arquivo compilado ao final do processo, desta forma o
desenvolvedor não precisa preocupar-se com isso.


Com esse novo modelo, o arquivo de código e a página ASPX são mesclados e
compilados numa única e completa classe em runtime eliminando a
complexidade do processo de compilação. A sincronização entre o arquivo de
código e o arquivo ASPX é automática, mas ainda assim é possível que o código
seja alterado no arquivo ASPX e não atualizado no arquivo de código, contudo o
desenvolvedor poderá localizar o problema de forma muito mais rápida uma vez
que o ASP.NET 2.0 gerará uma Exception muito mais detalhada.




Modelos de compilação no ASP.NET 2.0
O ASP.NET 2.0 suporta diferentes modelos de compilação para uma aplicação
Web, apresentados abaixo:


Default: (ASP.NET 1.x)
Neste modelo de compilação, os arquivos de código são compilados num
assembly e armazenados na pasta /bin da aplicação. As páginas ASPX são
compiladas por demanda. Este modelo funciona bem para a maioria dos
websites. Contudo, este processo de compilação torna a primeira requisição de
qualquer página da aplicação mais lenta do que as requisições subsequentes.


Não existe nenhum procedimento manual para realizar a compilação default. O
Runtime do ASP.NET 2.0 se encarregará de realizar a compilação quando
receber a primeira requisição para a aplicação. Se alguma alteração for feita, no
próximo request da página alterada, o Runtime do ASP.NET 2.0 determinará as
dependências do arquivo alterado e realizará a compilação apenas para os
arquivos envolvidos na alteração.


Vantagens:
   ·      Simples, pois o Runtime do ASP.NET faz todo o trabalho para você.
   ·      É a melhor opção para a fase de desenvolvimento da sua aplicação
       Web, pois evita as etapas necessárias para realizar pré-compilações.




In-Place Compilation (Pré-Compilação no Servidor de Produção)
Pode-se usar a ferramenta ASP.NET Compilation Tool (Aspnet_compiler.exe),
localizada na pasta C:WINDOWSMicrosoft.NETFrameworkv2.0.50727,
para pré-compilar aplicação. O processo é semelhante ao que ocorre em tempo
de execução. A ferramenta provoca vários requests para o website provocando a
compilação do mesmo. Se altera-se a página da aplicação, deve-se repetir o
processo de pré-compilação, caso contrário o Runtime do ASP.NET 2.0 terá que
fazer a compilação em tempo de execução na próxima requisição do arquivo
alterado.


Vantagens:
   ·        Tmpo de resposta para o primeiro request da aplicação é reduzido.
   ·        Não é necessário executar nenhum procedimento especial para o
       deployment após a compilação.


Deve-se usar esse modelo quando houver necessidade de frequentes alterações
nas páginas e/ou quando quiser reduzir o tempo de resposta do primeiro request,
mas deve-se lembrar que os arquivos de código estarão disponíveis para todos
que tiverem acesso à pasta da aplicação.




Deployment Pre-Compilation
Este modelo inserido no ASP.NET 2.0 permite ao desenvolvedor fazer a
compilação completa da sua solução antes de fazer o deployment. Com a
compilação completa, todos os arquivos code-behind, páginas ASPX, HTML,
recursos gráficos, são compilados em um ou mais assemblies, dependendo do
tamanho da aplicação e da configuração da compilação. Os assemblies contém o
Website completo, com exceção do arquivo Web.config. Este modelo de
compilação oferece a melhor performance e segurança se comparado com os
outros modelos, porém remove a capacidade de qualquer alteração no Website
após feito o deployment. Se trabalha-se em um website altamente visado, ou que
exige alto nível de segurança, este modelo é a melhor opção para o deployment
final. Contudo, se desenvolve-se um pequeno website, trabalhando numa
intranet local, e o projeto requer frequentes mudanças, este modelo de
compilação porde tornar-se inviável.
Pre-Compilation com camada de apresentação atualizável
Com a utilização do parâmetro –u da ferramenta ASP.NET Compilation, o
desenvolvedor pode pré-compilar os arquivos de código (*.vb ou *.cs) e os
arquivos de recursos (*.resource), deixando o código da camada de
apresentação (HTML) disponível para atualizações. Depois de realizar o
deployment do website no servidor de produção, os arquivos ASPX podem ser
modificados sem a necessidade de recompilar a aplicação.


Vantagens:
   ·       Tempo de resposta para o primeiro request da aplicação é reduzido.
   ·       Os designers podem modificar a aparência do Website sem
       necessidade de recompilar a aplicação.
   ·      A propriedade intelectual é protegida pois os arquivos de código ficam
       disponíveis neste modelo de compilação.




Pre-Compilation com camada de apresentação não atualizável
A ferramenta ASP.NET Compilation pode compilar todo código-fonte de uma
aplicação, incluindo os arquivos de interface (ASPX, ASCX), encapsulando-os
em assemblies que são publicados na pasta /bin da aplicação.


Vantagens:
   ·       Tempo de resposta para o primeiro request da aplicação é reduzido.
   ·      A propriedade intelectual é completamente protegida pois todos os
       arquivos de   código-fonte e arquivos de apresentação são compilados em
       *.dlls.
Metodologia


      Este capítulo visa apresentar a metodologia usada. Como a equipe de
desenvolvimento trabalhou para o desenvolvimento do projeto, quais e como foi
o processo de desenvolvimento, como foram feitos o controle de versão, o
ambiente de desenvolvimento, a comunicação com o cliente e entre os membros
desenvolvedores, etc. E por fim, é apresentado comentários relevantes.


      Durante o desenvolvimento do projeto, correspondente à disciplina
Projeto1 e Projeto2, o processo de desenvolvimento utilizado foi o XP1. A
seguir, uma descrição do processo seguido:




Definições


- Iteração


      É a unidade de planejamento detalhado, durando, em XP1, duas semanas.
O
      escopo é variável, sendo definido na fase de planejamento.
- Release


      É a liberação e instalação de uma versão do software para avaliação do
cliente.
      Um release em XP1 é composto de iterações, preferencialmente poucas,
entre 2
      e 5.


Atividades
As atividades realizadas em XP1 podem ser brevemente descritas da
seguinte maneira:


- Planejamento: abrange a escrita de User Stories (funcionalidades),
levantamento de requisitos não funcionais, planejamento de releases e de
iteração;


- Projeto: se divide em projeto arquitetural e refatoramento constante;


- Testes: inclui a elaboração de testes de aceitação e de unidade, assegurando
que o software se comporta de maneira desejada a cada situação testada;


- Integração: quando se utiliza o controle de versão, garantindo que o software
com o qual o programador vai trabalhar está em sua versão mais atualizada.
Assegura-se isto fazendo check-out (adquirir a versão mais atualizada do projeto
para desenvolver uma tarefa) antes de iniciar o desenvolvimento e fazendo
check-in (atualizar o projeto, acoplando a tarefa que acabou de ser desenvolvida)
ao finalizar o desenvolvimento;


- Acompanhamento: atividade que assegura a manutenção do progresso do
projeto,
sendo desempenhada pelo gerente.




Gestão do Código


      Durante todo o período de desenvolvimento do projeto, o código foi
compartilhado entre seus desenvolvedores. No planejamento, cada
funcionalidade tornava-se responsabilidade

de um desenvolvedor especíco, porém com o compartilhamento do código
incentivado, de forma que todos os desenvolvedores poderiam ajudar em
qualquer parte implementada, mesmo que não fosse, à priori, de sua
responsabilidade.


      Para tanto, manteve-se o código atualizado em uma base de dados segura,
um repositório de código-fonte de fácil acesso. No nosso caso, à princípio,
tentamos o Concurrent Versions System (CVS) do www.cvsdude.com, porém
obtivemos problemas de configuração e migramos para o “Subversion” (sistema
de controle de versão, também conhecido svn ou SVN, desenhado
especificamente para ser um substituto moderno do CVS, que se considera ter
alguns defeitos) do GoogleCode.




Ambiente de Desenvolvimento


      O ambiente de desenvolvimento escolhido foi o VisualStudio.NET. Os
desenvolvedores do projeto o escolheram, pois além de sua familiaridade, o
VisualStudio .NET também é uma ferramenta poderosa, de fácil utilização, alta
portabilidade, muito flexível para utilização de plugins e uma das mais
completas IDE´s da atualidade. Possui integração com o banco de dados
escolhidos (MySQL), Nunit e todas as demais ferramentas por nós utilizadas.


      Para testes, usamos o NUnit e o EasyAcceptToNUnit. O primeiro como
um framework para confecção de testes automáticos de software e, o segundo,
como uma ferramenta para automatizar testas de aceitação para projetos em
.NET. Ambos de fundamental importância para o êxito do projeto por facilitar a
implementação e execução dos testes de software, tornando um processo leve e
de fácil aceitação.




Comunicação


      A comunicação, como em todas as áreas, é parte vital para o sucesso de
um projeto.
Na primeira metade do projeto, não havia reuniões presenciais mas, virtuais.
Estas se davam através de correio eletrônico e mensageiros instantâneos.
Pessoalmente, discutíamos antes e após as reuniões semanais com o cliente.


      Porém, percebeu-se a importância e necessidade de reuniões presenciais e,
semanalmente, aos sábados, passamos a nos reunir, durante praticamente toda a
tarde. Na reunião discutíamos questões pendentes e trabalhávamos
conjuntamente no código propriamente dito.


      É importante ressaltar que a comunicação virtual continuou existindo ao
longo de todo o processo e que dávamos continuidade ao código
individualmente, em nossos domicílios.


      Todos estavam livres para tirar qualquer dúvida sobre a implementação
com os outros integrantes e/ou com o próprio cliente. O qual demonstrou grande
disponibilidade e prestatividade para esclarecer eventuais questões. Muitas
dúvidas, quanto ao projeto como um todo, foram clarificadas durante as reuniões
semanais com o mesmo. Reuniões tais que foram de indubitável importância,
chegando a durar aproximadamente 1 hora, se necessário.
Desta maneira, o cliente estava sempre como um membro da equipe de
desenvolvimento, acompanhando de perto cada passo e validando as
funcionalidades recém-implementadas por meio de demonstrações por parte dos
desenvolvedores. Com isto, a qualquer momento da implementação do projeto,
o cliente tinha noção do nível de progresso que estava havendo.


      Outro fator positivo quanto ao cliente foi que este era da área de
computação e,
conseqüentemente, sabia explicar (inclusive com termos técnicos) o que
desejava.
Portanto, suas especificações tinham maior chance de serem corretamente
interpretadas e executadas pelos desenvolvedores.




Responsabilidades


      Os integrantes da equipe puderam desempenhar três papéis: cliente,
desenvolvedor ou gerente.


      O cliente foi responsável por descrever as user stories (US), ou seja,
funcionalidades, os requisitos não-funcionais, os testes de aceitação, o plano de
releases e a distribuição das user stories por cada iteração, não podendo estimar
o tempo em que as user stories deveriam ser concluídas. O cliente também se
dispôs a tirar dúvidas dos desenvolvedores quando/se surgissem.


      Os desenvolvedores, por sua vez, apoiaram o cliente na definição de user
stories e requisitos não-funcionais, elaboraram o projeto arquitetural e
estimaram o tempo de desenvolvimento das user stories durante o planejamento
de releases. Durante a fase do planejamento de iteração, dividiram as user stories
daquela iteração em tarefas, escolheram quais tarefas iriam desenvolver e
estimaram precisamente o tempo de desenvolvimento de cada tarefa. Também
desenvolveram o esquema lógico e testes de unidade para cada tarefa, sempre
fazendo integração.


        Já o gerente foi responsável por cobrar o andamento do projeto, conduzir
as atividades de planejamento, descobrir riscos e traçar estratégias para lidar
com os mesmos.Cada um dos alunos foi gerente durante uma release e o gerente
acumulava também as responsabilidades de desenvolvedor.




Prazos de entrega


        Em datas definidas pelas ministrantes das disciplinas, as equipes entregam
algum
resultado de seu trabalho. Existem três tipos de entrega:


- Apresentação de planejamento: devem-se entregar artefatos resultantes da
análise do sistema, ou seja, requisitos funcionais e não-funcionais, projeto
arquitetural e o planejamento de releases e iterações, distibuindo as
funcionalidades nas mesmas.


- Apresentação de iteração: artefatos de acompanhamento devem ser
apresentados, como big charts, tabela de cumprimento de atividades, etc;


- Apresentação de release: além dos artefatos mencionados acima, deve-se ter
uma versão do sistema disponível para apresentação à ministrante e ao cliente.




Demonstrações das Funcionalidades
Sempre que funcionalidades significativas eram implementadas, nós as
mostravam ao cliente durante as reuniões semanais.

Comentários


- A ferramenta EasyAcceptToNUnit foi uma adaptacao implementada
exclusivamente para este projeto. Já existia o EasyAccept, a qual tem a mesma
funcionalidade mas trabalha com a linguagem Java;


- Um dos integrantes (Thiago Gondim) não possuía familiaridade com a
linguagem e plataforma utilizadas, pois este projeto é uma continuidade do
projeto da disciplina LES (Laboratório de Engenharia de Software), do qual ele
não fazia parte. Este membro fazia parte de outro projeto porém decidiu mudar
para este por ter achado a proposta interessante e por desejar ampliar seus
horizontes, aprendendo algo como .NET
Resultados


       O WUT2S é um sistema web que apresenta toda sua interface desenvolvida
em ASP .NET. Toda a lógica do sistema foi implementada na linguagem C#,
utilizando o Visual Studio como ambiente de desenvolvimento. Algumas
funcionalidades da interface foram desenvolvidas com JavaScript, utilizando a
biblioteca ASP .NET AJAX (antigo ATLAS).
       A interface do sistema apresenta abas com o intuito de aproximar o uso
deste com o uso de determinados sistemas desktop. Menus são utilizados em
cada aba, seguindo um padrão para facilitar a utilização das funcionalidades do
sistema.
       A escolha das linguagens se deu após se ter tomado conhecimento dos
servidores Windows que se encontram no LIHM e baseado em certa
familiaridade dos integrantes do projeto com as mesmas. Além disso, a escolha
dessa tecnologia de geração de páginas com conteúdo dinâmico (ASP .NET/C#)
se deve ao fato da mesma ser mais veloz que outras tecnologias (por exemplo,
JSP, ASP).


Por que ASP .NET?
Benefícios do ASP .NET:
   •   Código compilado não interpretado, com isso são evitados erros em
       design-time e as aplicações rodam mais rápido.
   •   Melhor tratamento de erro através de controles de validação e blocos try-
       catch.
   •   Controles desenvolvidos pelo usuário permitem maior reuso de código.
   •   Controles muito similares aos controles de Windows permitindo uma
       maior facilidade do usuário.
   •   Habilidade de fazer cache de toda a página ou só de algumas partes dela
       para aumentar o desempenho.
•   Usa o conceito de code-behind que separa o código da lógica com a
       apresentação.
   •   Recupera-se de memory leak e crashs.
   •   Uso de master pages que permitem definir um modelo de página
       principal, onde todas as outras páginas podem seguir esse modelo.
   •   Uso de temas (pode-se usar também CSS) para definir o look-and-feel de
       toda a página Web.
   •   Código totalmente OO sem preocupações com Scripts.
   •   Event-driven model em desenvolvimento Web.
   •   Suporte total aos padrões HTML 4.0, XHTML 1.0 e 1.1 e suporte
       extensivo a CSS.
   •   Modelo de adaptive render onde os componentes detectam a cultura do
       seu browser e a partir de então usam o padrão correto para seu browser,
       suportando inclusive padrões HTML, WML, XHTML, e CHMTL; alguns
       desses padrões para dispositivos móveis.
   •   Todos os controles possuem grande customização.


Benefícios para o usuário:
   •   A aplicação vai funcionar corretamente no seu browser.
   •   Experiência semelhante à de usar uma aplicação desktop graças aos
       controles do ASP .NET.
   •   Maior velocidade de resposta graças à pré-compilação feita no servidor e
       ao sistema de caching (podendo ser automático ou manual).
   •   Alguns controles:
          o   Controle de Log In:
          o   Facilita ao usuário a operação de Login; outros controles associados
              a Login, como criação de novo usuário e recuperação de senha,
              também estão presentes.
•   File Upload: permite ao usuário fazer o upload de um arquivo.




•   DataGridView: ideal para visualização de dados de um BD, operações de
    CRUD como editar e remover podem ser realizadas no próprio controle.




•   Menu semelhante ao menu principal de vários aplicativos desktop.


•   Calendário




•   Vale sempre lembrar que esses e os demais controles são customizáveis
    permitindo mudança de cores de texto, de plano de fundo, entre outros.
•   Existe também a possibilidade de se combinar vários controles para se
      criar um novo controle, como, por exemplo, um controle de
      preenchimento de data de nascimento.
  •   Controles    totalmente    novos     também      podem   ser    criados.


Desvantagens do ASP.NET:
  •   Portabilidade: Só roda em algumas versões do Windows.
  •   Algumas exceções globais não tratadas podem gerar falhas muito
      dificilmente detectadas.
  •   O modelo de adaptive render nem sempre funciona corretamente, algumas
      vezes é necessário “estender” Browser capabilities para que os controles
      gerem o padrão HTML correto.
  •   O primeiro acesso à aplicação pode ser mais lento devido à compilação
      ser executada no mesmo, outros modelos de compilação podem resolver o
      problema.
  •   Apesar de o seu uso ser gratuito, não é open source.
  •   Nem todos os SGBDs fornecem um conector .NET, no entanto é possível
      se conectar via ODBC.
  •   Estudos comparativos e links:
         o   http://www.brillianceweb.com/betterwebdesign/tips_52.aspx
         o   http://www.gotdotnet.com/team/compare/
         o   http://p2p.wrox.com/topic.asp?TOPIC_ID=47496 desvantagens do
             .NET e do ASP .NET.
         o   http://www.linhadecodigo.com.br/artigos.asp?id_ac=957 mostra os
             vários modelos de compilação do ASP .NET.


Requisitos
      Os principais requisitos da aplicação foram:
• Funcionais
         o Permitir autenticação de usuários e o controle de seu acesso.
         o Permitir o agendamento de tarefas e eventos, e o registro de sua
            execução.
         o Consultar dados de testes anteriores, inclusive a observação de
            estatísticas sobre os dados de testes, como tempo, número de erros,
            reincidência de erros, perfil dos usuários e comentários adicionais.
   • Não-funcionais
         o Ser disponível para se usar via web, em servidor Windows.
         o Usar ferramentas livres.
         o Tempo de resposta não pode ser demorado.


Projeto Arquitetural
     A arquitetura do sistema é baseada no padrão MVC (Model-View-
Controller), a diferença é que a mesma apresenta um Web Service atuando como
façade permitindo uma maior flexibilidade caso seja necessário realizar
mudanças.
     A figura abaixo apresenta um modelo da arquitetura utilizada:
Uma vantagem dessa arquitetura é que ela pode ser facilmente adaptada
para aplicações desktop ou mesmo para dispositivos móveis.
      Para dispositivos móveis, a arquitetura é apresentada a seguir:
É interessante observar que o esforço de migração é mínimo, uma vez que
toda a lógica de negócio se mantém e o acesso via Web Service pode ser feito da
mesma maneira.
      Para aplicações desktop, a figura abaixo apresenta uma arquitetura
possível:




      E ainda, caso seja necessário se optar por outra tecnologia ao invés do
.NET, o modelo e o acesso a ele se mantêm:
É válido observar, também, que a única mudança se dá na camada de
aplicação, pois com essa arquitetura são mantidas a lógica e o acesso à mesma.
      A persistência dos dados é realizada com o sistema de banco de dados
MySQL,     por      ser     gratuito   e   por   apresentar   eficiência   satisfatória.
Há a possibilidade (interesse do cliente) de integrar, no futuro, a ferramenta
WUT2S ao Fermint e ao WebQuest (já mencionados anteriormente na
contextualização do projeto), mas não se tem tanta certeza, pois seus códigos
nem foram vistos ainda. Uma possibilidade de integração pode se dar através do
web service (diagrama acima) ou pelo compartilhamento da base de dados.


User stories
      As user stories desenvolvidas durante o período de curso da disciplina
Projeto I foram as seguintes:
   • Login de usuários:
         o Entrar com login e senha válidos, e o sistema levar o usuário à tela
               principal.
o Entrar com login e senha inválidos, e o sistema mostrar mensagem
          de erro.
• Cadastro de tarefas:
      o Criar, alterar, remover e consultar tarefas
• Cadastro de usuários participantes de testes:
      o Criar, alterar, remover e consultar usuários participantes
• Cadastro de usuários avaliadores:
      o Criar, alterar, remover e consultar usuários avaliadores
• Cadastro de eventos (posteriormente alterados para indicadores de
   usabilidade):
      o Criar, alterar, remover e consultar eventos (indicadores de
          usabilidade)
• Cadastro de projetos:
      o Criar, alterar, remover e consultar projetos
• Cadastro de produtos:
      o Criar, alterar, remover e consultar produtos
• Cadastro de sessões de teste:
      o Criar, alterar, remover e consultar sessões de teste
• Cadastro de roteiros de teste:
      o Criar, alterar, remover e consultar roteiros de teste


   Durante a disciplina Projeto II, foram implemantadas a seguintes user
   stories:
• Alteração do roteiro de teste:
      o Configuração de ordem de tarefas e indicadores de usabilidade
      o Visualização, remoção de tarefas e indicadores de usabilidade
• Alteração de sessões de teste:
         o Vinculação entre usuários e sessões de teste
   • Execução de testes de usabilidade:
         o Inicialmente com cronômetro síncrono e apenas uma quantidade
             fixa de indicadores de usabilidade
   • Criação da apresentação de resultados:
         o Por sessão
         o Por projeto
         o Por usuário em cada sessão
   • Reformulação do código:
         o Interface
         o Código da lógica de negócio
   • Implementação de políticas de visualização por tipo de usuário
   • Criação do help on line e manual


   Além dessas user stories, no início do projeto e no decorrer do mesmo
também foram criadas outras, porém com uma “menor” relevância para o
escopo do sistema, levando em consideração o tempo para finalização deste. Por
isso, estas user stories não foram implementadas, mas ficaram guardadas para
que, com uma possível solicitação do cliente, as mesmas incorporem mais
funcionalidades e características ao sistema.
Big chart



            Data    Módulos Classes Classes Classes   Classes   Páginas Páginas
                                    de      de lógica de        ASP     ASP
                                    lógica  alteradas interface .NET    .NET
                                                                        alteradas
LES                 8       24      8       0         20        20      0
Iteração 12/03/2007 8       35      8       0         26        26      8
01 - P1
Iteração 26/03/2007 10      40      10      0         28        28      8
02 - P1
Iteração 09/04/2007 11      48      14      3         31        31      15
03 - P1
Iteração 23/04/2007 11      50      15      5         35        35      18
04 - P1
Iteração 14/05/2007 12      56      18      6         38        38      20
05 - P1
Iteração 25/06/2007 12      66      21      10        45        45      24
01 - P2
Iteração 09/07/2007 13      75      24      12        51        51      26
02 - P2
Iteração 22/07/2007 13      78      28      15        57        57      29
03 - P2
Iteração 05/08/2007 13      81      29      17        59        59      34
04 - P2
Iteração 19/08/2007 15      95      32      21        63        63      38
05 - P2
Iteração 03/09/2007 15      98      33      25        64        64      47
06 - P2
Data      Java     Testes de   Testes de aceitação
                          Script   Unidade     (linhas)
                                   (métodos)
LES                        4       18          56
Iteração 01 -   12/03/2007 4       22          68
P1
Iteração 02 -   26/03/2007 4       25          82
P1
Iteração 03 -   09/04/2007 4       29          87
P1
Iteração 04 -   23/04/2007 4       33          97
P1
Iteração 05 -   14/05/2007 4       38          122
P1
Iteração 01 -   25/06/2007 4       44          165
P2
Iteração 02 -   09/07/2007 15      51          227
P2
Iteração 03 –   22/07/2007 15      53          254
P2
Iteração 04 -   05/08/2007 16      58          303
P2
Iteração 05 -   19/08/2007 17      69          341
P2
Iteração 06 -   03/09/2007 17      75          425
P2
Interface
      O sistema apresenta uma tela de login como tela inicial. Nesta tela o
usuário deve entrar com seu login e sua senha válidos, a fim de obter acesso às
funcionalidades da ferramenta. A tela inicial é mostrada na figura abaixo:
É válido mencionar que a figura ainda está com o antigo logotipo do
sistema, o Platinum Test.
      Após o usuário ser validado (login e senha corretos), a tela principal do
sistema aparece. Esta tela apresenta abas para facilitar a navegação do usuário
pelo sistema. Dependendo do que se quer fazer, três abas podem ser
selecionadas (além de apresentar a aba inicial que mostra a saudação ao
usuário): Cadastro, Consulta ou Execução de teste. Cada uma apresenta um
menu contendo opções referentes ao que se quer cadastrar, consultar ou
executar.
      Na aba Cadastro e na aba Consulta, o menu contém as seguintes opções:
Usuário (na aba Consulta, a opção Usuário apresenta, ainda, duas opções:
Avaliador e Participante de teste), Projeto, Produto, Tarefa, Indicador de
usabilidade, Roteiro de teste e Sessão de teste. A aba Execução de teste
apresenta informações relacionadas aos roteiros de teste cadastrados.
      As duas figuras abaixo apresentam, respectivamente, a tela principal na
aba Início e na aba Cadastro:
Conclusões


      Ao término dessa disciplina, o sistema pode ser considerado pronto para
ser utilizado no LIHM do PaqTc-Pb. Durante o período de dois semestres letivos
foram desenvolvidas as funcionalidades da ferramenta citada neste documento.
      Seguindo    a   metodologia      mencionada   anteriormente,    a   equipe
desenvolvedora dividiu todas as tarefas a serem executadas, em cada user storie,
e, em alguns momentos, também fez prática de pair programming, ficando dois
desenvolvedores resolvendo um mesmo problema.
      Alguns desafios apareceram e foram superados, como, por exemplo: a
falta de conhecimento em AJAX, já que algumas funcionalidades na interface
precisaram ser desenvolvidas em JavaScript (com o uso de AJAX os resultados
obtidos foram satisfatórios). Além disso, houve um rigor maior relacionado à
interface do sistema, já que o cliente trabalha diretamente na área de “Interface
Homem-Máquina” e o sistema é voltado para um público que também trabalha
nessa área. Como ninguém da equipe que desenvolveu o projeto tinha formação
(bons conhecimentos) nesta, foi gasto um tempo maior do que o esperado com
problemas relacionados à interface.
      No decorrer do desenvolvimento, também foram sugeridas modificações
em alguns pontos que já haviam sido discutidos, o que impôs certo atraso
também no andamento do projeto. Mas tudo isso serviu de aprendizado e
mostrou que, com um bom planejamento e uma boa organização de tarefas, os
problemas quando aparecem são mais fáceis de tratar e não atrasam tanto quanto
se não houvesse um bom planejamento anteriormente.
      Cada integrante da equipe passou por um período de gerência do projeto,
o que fez com que cada um ganhasse certa experiência, também, em relação ao
conhecimento de gerenciamento de projetos, já que todos não ficaram apenas na
visão de desenvolvedores do sistema.
Pode-se dizer que o cliente está de acordo com tudo o que foi feito, pois
todas as funcionalidades que tinham prioridade foram implementadas de acordo
com o que foi pedido. Funcionalidades extras podem ser desenvolvidas, segundo
a vontade do cliente, desde que haja mais tempo para tal.
      Trabalhos futuros podem fazer a integração entre este sistema e outros já
citados ao longo deste documento, sem grandes complicações, acredita-se.
Referências Bibliográficas


LOBO, R. C. L. & QUEIROZ, J. E. R. & TURNELL, M. F. Q. V. WebQuest: Uma
  ferramenta Web configurável para o delineamento do perfil e a sondagem da satisfação
  subjetiva do usuário. Disponível em:
  http://grise.upm.es/rearviewmirror/conferencias/jiisic04/Papers/11.pdf.


MOBRIPRO. Tasktimer. Disponível em:
   http://www.mobipro.com/products.asp?pID=1.
TECHSMITH. Morae. Disponível em: http://www.techsmith.com/morae.asp.
_______. UserVue. Disponível em: http://www.techsmith.com/uservue.asp.

USERFOCUS. Usability Test Data Logger tool v4.2. Disponível em:

  http://www.userfocus.co.uk/resources/datalogger.html.

WEBQUEST. Disponível em: http://www.lihm.paqtc.org.br/webquest/.
Apêndice 1 – Glossário de termos mais utilizados na plataforma .NET
Como toda nova tecnologia, a plataforma .NET inclui uma série de novos termos. Os mais
comuns estão listados abaixo:
CLR – Sigla de Common Language Runtime. Base comum a todas as linguagens escritas
para a plataforma. O CLR é o ambiente que gerencia a execução de código escrito em
qualquer linguagem. O CLR faz parte do framework .NET.

FRAMEWORK .NET – É a estrutura da plataforma .NET para construir, instalar e rodar
qualquer aplicação, seja ela desenvolvida para desktop ou internet. Para executar qualquer
programa .NET é preciso ter o framework instalado.

IDE – Ambiente integrado de desenvolvimento (Integrated Development Environment) do
Visual Studio .NET. Diferentes linguagens usam o mesmo ambiente para desenvolvimento
(editor de código, depurador) e compilam executáveis na linguagem MSIL. Além das
linguagens nativas suportadas existem pelo menos outras vinte que foram portadas para este
ambiente (Perl, Cobol, Pascal, etc).

MSIL – Microsoft Intermediate Language. Toda aplicação .NET compilada é convertida para
uma linguagem intermediária, a MSIL. Ela é um conjunto de instruções independentes de
CPU. Na hora da execução do programa, um novo compilador chamado Just-in-time
Compiler (JIT), converte o MSIL para código nativo, específico para o processador da
máquina.

MANAGED CODE - Código gerenciado pelo framework .NET. Tarefas como alocação de
memória e garbage collector são gerenciadas automaticamente pelo ambiente. Das linguagens
nativas apenas o C++ produz código não gerenciado (Unmanaged Code).

SOAP – Sigla de Simple Object Access Protocol. O SOAP é um padrão aberto baseado em
XML e gerenciado pelo W3C para a transferência de dados entre aplicações. Pode ser usado
em conjunto com vários outros protocolos comuns da internet.

UDDI – Sigla de Universal Description, Discovery and Integration. Funciona como uma
espécie de páginas amarelas para Web Services. Na UDDI, empresas podem expor seus
serviços para que outras pessoas possam utilizá-lo.

XML – Sigla de Extensible Markup Language. O XML é uma linguagem baseada em tags,
semelhante ao HTML. Sua principal característica é a extensibilidade. Quem cria um
documento XML pode introduzir tags personalizadas, que podem ser explicadas em um
documento XSD anexo.

XSD – Sigla de Schema Definition. Documento associado a um documento XML utilizado
para descrever e validar os dados do documento XML. Documentos XSDs aceitam dados de
diferentes tipos, como números, data e moeda.

XML Web Service – Blocos fundamentais para a criação do modelo de computação
distribuída na internet. Um Web Service é uma porção de código localizada num servidor web
e pode ser utilizada por uma aplicação qualquer.

WSDL – Sigla de Web Service Description Language. A Linguagem WSDL define regras
baseadas em XML para descrever os Web Services. A WSDL é padroniza da pelo órgão gestor
W3C.

Mais conteúdo relacionado

Semelhante a Monografia - Ciência da Computação - UFCG

Teste de Performance - 3º Encontro da ALATS
Teste de Performance - 3º Encontro da ALATSTeste de Performance - 3º Encontro da ALATS
Teste de Performance - 3º Encontro da ALATSFabrício Campos
 
Webcast WebSphere Portal Performance
Webcast WebSphere Portal PerformanceWebcast WebSphere Portal Performance
Webcast WebSphere Portal PerformanceAlex Barbosa Coqueiro
 
Apresentação Artigo SBQS 2015 - Um Comparativo na Execução de Testes Manuais ...
Apresentação Artigo SBQS 2015 - Um Comparativo na Execução de Testes Manuais ...Apresentação Artigo SBQS 2015 - Um Comparativo na Execução de Testes Manuais ...
Apresentação Artigo SBQS 2015 - Um Comparativo na Execução de Testes Manuais ...Vanilton Pinheiro
 
BDD (Behavior-Driven Development) - Setembro/2015
BDD (Behavior-Driven Development) - Setembro/2015BDD (Behavior-Driven Development) - Setembro/2015
BDD (Behavior-Driven Development) - Setembro/2015Renato Groff
 
BDD (Behavior-Driven Development)
BDD (Behavior-Driven Development)BDD (Behavior-Driven Development)
BDD (Behavior-Driven Development)Renato Groff
 
Processos de software
Processos de softwareProcessos de software
Processos de softwareDann Volpato
 
Testes de usabilidade
Testes de usabilidade Testes de usabilidade
Testes de usabilidade Laís Berlatto
 
Teste Contínuo de Integração e Virtualização de Serviços
Teste Contínuo de Integração e Virtualização de ServiçosTeste Contínuo de Integração e Virtualização de Serviços
Teste Contínuo de Integração e Virtualização de ServiçosRationalBrasil
 
Ferramentas Case de Teste
Ferramentas Case de TesteFerramentas Case de Teste
Ferramentas Case de TesteBeatriz Marques
 
Falando de Testes de Desempenho - por Evandro Grezeli
Falando de Testes de Desempenho - por Evandro GrezeliFalando de Testes de Desempenho - por Evandro Grezeli
Falando de Testes de Desempenho - por Evandro GrezeliJoao Galdino Mello de Souza
 
plano_de_projeto_controlart_final
plano_de_projeto_controlart_finalplano_de_projeto_controlart_final
plano_de_projeto_controlart_finaluserrx
 
Test-Driven Development (TDD) utilizando o framework xUnit.net
Test-Driven Development (TDD) utilizando o framework xUnit.netTest-Driven Development (TDD) utilizando o framework xUnit.net
Test-Driven Development (TDD) utilizando o framework xUnit.netRenato Groff
 
Cmg falando de testes de desempenho
Cmg falando de testes de desempenhoCmg falando de testes de desempenho
Cmg falando de testes de desempenhoEvandro Grezeli
 
Plano do projeto de software
Plano do projeto de softwarePlano do projeto de software
Plano do projeto de softwareDanilo Gois
 
[GUTS-RS] Evento julho 2017 - Como iniciar os testes de performance em uma a...
[GUTS-RS] Evento julho 2017 -  Como iniciar os testes de performance em uma a...[GUTS-RS] Evento julho 2017 -  Como iniciar os testes de performance em uma a...
[GUTS-RS] Evento julho 2017 - Como iniciar os testes de performance em uma a...GUTS-RS
 
Projeto de sw revisado
Projeto de sw revisadoProjeto de sw revisado
Projeto de sw revisadoJorge Barreto
 

Semelhante a Monografia - Ciência da Computação - UFCG (20)

Teste de Performance - 3º Encontro da ALATS
Teste de Performance - 3º Encontro da ALATSTeste de Performance - 3º Encontro da ALATS
Teste de Performance - 3º Encontro da ALATS
 
Webcast WebSphere Portal Performance
Webcast WebSphere Portal PerformanceWebcast WebSphere Portal Performance
Webcast WebSphere Portal Performance
 
Apresentação Artigo SBQS 2015 - Um Comparativo na Execução de Testes Manuais ...
Apresentação Artigo SBQS 2015 - Um Comparativo na Execução de Testes Manuais ...Apresentação Artigo SBQS 2015 - Um Comparativo na Execução de Testes Manuais ...
Apresentação Artigo SBQS 2015 - Um Comparativo na Execução de Testes Manuais ...
 
BDD (Behavior-Driven Development) - Setembro/2015
BDD (Behavior-Driven Development) - Setembro/2015BDD (Behavior-Driven Development) - Setembro/2015
BDD (Behavior-Driven Development) - Setembro/2015
 
BDD (Behavior-Driven Development)
BDD (Behavior-Driven Development)BDD (Behavior-Driven Development)
BDD (Behavior-Driven Development)
 
Processos de software
Processos de softwareProcessos de software
Processos de software
 
Testes de usabilidade
Testes de usabilidade Testes de usabilidade
Testes de usabilidade
 
Teste Contínuo de Integração e Virtualização de Serviços
Teste Contínuo de Integração e Virtualização de ServiçosTeste Contínuo de Integração e Virtualização de Serviços
Teste Contínuo de Integração e Virtualização de Serviços
 
Ferramentas Case de Teste
Ferramentas Case de TesteFerramentas Case de Teste
Ferramentas Case de Teste
 
Falando de Testes de Desempenho - por Evandro Grezeli
Falando de Testes de Desempenho - por Evandro GrezeliFalando de Testes de Desempenho - por Evandro Grezeli
Falando de Testes de Desempenho - por Evandro Grezeli
 
Guday2015 - GUTS-RS
Guday2015 - GUTS-RSGuday2015 - GUTS-RS
Guday2015 - GUTS-RS
 
Trabalho es prototipagem
Trabalho es   prototipagemTrabalho es   prototipagem
Trabalho es prototipagem
 
plano_de_projeto_controlart_final
plano_de_projeto_controlart_finalplano_de_projeto_controlart_final
plano_de_projeto_controlart_final
 
Brisa - Cases Qualidade Sofware
Brisa -  Cases Qualidade SofwareBrisa -  Cases Qualidade Sofware
Brisa - Cases Qualidade Sofware
 
Test-Driven Development (TDD) utilizando o framework xUnit.net
Test-Driven Development (TDD) utilizando o framework xUnit.netTest-Driven Development (TDD) utilizando o framework xUnit.net
Test-Driven Development (TDD) utilizando o framework xUnit.net
 
Cmg falando de testes de desempenho
Cmg falando de testes de desempenhoCmg falando de testes de desempenho
Cmg falando de testes de desempenho
 
Projeto de SW
Projeto de SWProjeto de SW
Projeto de SW
 
Plano do projeto de software
Plano do projeto de softwarePlano do projeto de software
Plano do projeto de software
 
[GUTS-RS] Evento julho 2017 - Como iniciar os testes de performance em uma a...
[GUTS-RS] Evento julho 2017 -  Como iniciar os testes de performance em uma a...[GUTS-RS] Evento julho 2017 -  Como iniciar os testes de performance em uma a...
[GUTS-RS] Evento julho 2017 - Como iniciar os testes de performance em uma a...
 
Projeto de sw revisado
Projeto de sw revisadoProjeto de sw revisado
Projeto de sw revisado
 

Mais de Dalton Valadares

Primeiros passos com Openstack
Primeiros passos com OpenstackPrimeiros passos com Openstack
Primeiros passos com OpenstackDalton Valadares
 
Performance Evaluation of an IEEE 802.11g Network in an Industrial Environment
Performance Evaluation of an IEEE 802.11g Network in an Industrial EnvironmentPerformance Evaluation of an IEEE 802.11g Network in an Industrial Environment
Performance Evaluation of an IEEE 802.11g Network in an Industrial EnvironmentDalton Valadares
 
802.11g Signal Strength Evaluation in an Industrial Environment (Elsevier Int...
802.11g Signal Strength Evaluation in an Industrial Environment (Elsevier Int...802.11g Signal Strength Evaluation in an Industrial Environment (Elsevier Int...
802.11g Signal Strength Evaluation in an Industrial Environment (Elsevier Int...Dalton Valadares
 
Towards 802.11g Signal Strength Estimation in an Industrial Environment: a Pr...
Towards 802.11g Signal Strength Estimation in an Industrial Environment: a Pr...Towards 802.11g Signal Strength Estimation in an Industrial Environment: a Pr...
Towards 802.11g Signal Strength Estimation in an Industrial Environment: a Pr...Dalton Valadares
 
Towards 802.11g Signal Strength Estimation in an Industrial Environment: a Pr...
Towards 802.11g Signal Strength Estimation in an Industrial Environment: a Pr...Towards 802.11g Signal Strength Estimation in an Industrial Environment: a Pr...
Towards 802.11g Signal Strength Estimation in an Industrial Environment: a Pr...Dalton Valadares
 
Internet das Coisas e a Indústria 4.0
Internet das Coisas e a Indústria 4.0Internet das Coisas e a Indústria 4.0
Internet das Coisas e a Indústria 4.0Dalton Valadares
 
Achieving Data Dissemination with Security using FIWARE and Intel Software Gu...
Achieving Data Dissemination with Security using FIWARE and Intel Software Gu...Achieving Data Dissemination with Security using FIWARE and Intel Software Gu...
Achieving Data Dissemination with Security using FIWARE and Intel Software Gu...Dalton Valadares
 
Internet das Coisas com Edgex Foundry
Internet das Coisas com Edgex FoundryInternet das Coisas com Edgex Foundry
Internet das Coisas com Edgex FoundryDalton Valadares
 
OPTEE on QEMU - Build Tutorial
OPTEE on QEMU - Build TutorialOPTEE on QEMU - Build Tutorial
OPTEE on QEMU - Build TutorialDalton Valadares
 
Presentation of my paper in the IEEE Symposium on Computer and Communications...
Presentation of my paper in the IEEE Symposium on Computer and Communications...Presentation of my paper in the IEEE Symposium on Computer and Communications...
Presentation of my paper in the IEEE Symposium on Computer and Communications...Dalton Valadares
 
Avaliação de Desempenho de uma Rede 802.11g em uma Usina Termoelétrica
Avaliação de Desempenho de uma Rede 802.11g em uma Usina TermoelétricaAvaliação de Desempenho de uma Rede 802.11g em uma Usina Termoelétrica
Avaliação de Desempenho de uma Rede 802.11g em uma Usina TermoelétricaDalton Valadares
 
Apresentação sobre o modelo de segurança OPC UA
Apresentação sobre o modelo de segurança OPC UAApresentação sobre o modelo de segurança OPC UA
Apresentação sobre o modelo de segurança OPC UADalton Valadares
 
Modelo de segurança OPC UA
Modelo de segurança OPC UAModelo de segurança OPC UA
Modelo de segurança OPC UADalton Valadares
 
Introdução à Gestão de projetos
Introdução à Gestão de projetosIntrodução à Gestão de projetos
Introdução à Gestão de projetosDalton Valadares
 
Integrating Fiware Orion, Keyrock and Wilma
Integrating Fiware Orion, Keyrock and WilmaIntegrating Fiware Orion, Keyrock and Wilma
Integrating Fiware Orion, Keyrock and WilmaDalton Valadares
 
Desenvolvimento Web com JSF
Desenvolvimento Web com JSFDesenvolvimento Web com JSF
Desenvolvimento Web com JSFDalton Valadares
 

Mais de Dalton Valadares (20)

Primeiros passos com Openstack
Primeiros passos com OpenstackPrimeiros passos com Openstack
Primeiros passos com Openstack
 
Performance Evaluation of an IEEE 802.11g Network in an Industrial Environment
Performance Evaluation of an IEEE 802.11g Network in an Industrial EnvironmentPerformance Evaluation of an IEEE 802.11g Network in an Industrial Environment
Performance Evaluation of an IEEE 802.11g Network in an Industrial Environment
 
802.11g Signal Strength Evaluation in an Industrial Environment (Elsevier Int...
802.11g Signal Strength Evaluation in an Industrial Environment (Elsevier Int...802.11g Signal Strength Evaluation in an Industrial Environment (Elsevier Int...
802.11g Signal Strength Evaluation in an Industrial Environment (Elsevier Int...
 
Towards 802.11g Signal Strength Estimation in an Industrial Environment: a Pr...
Towards 802.11g Signal Strength Estimation in an Industrial Environment: a Pr...Towards 802.11g Signal Strength Estimation in an Industrial Environment: a Pr...
Towards 802.11g Signal Strength Estimation in an Industrial Environment: a Pr...
 
Towards 802.11g Signal Strength Estimation in an Industrial Environment: a Pr...
Towards 802.11g Signal Strength Estimation in an Industrial Environment: a Pr...Towards 802.11g Signal Strength Estimation in an Industrial Environment: a Pr...
Towards 802.11g Signal Strength Estimation in an Industrial Environment: a Pr...
 
Internet das Coisas e a Indústria 4.0
Internet das Coisas e a Indústria 4.0Internet das Coisas e a Indústria 4.0
Internet das Coisas e a Indústria 4.0
 
Achieving Data Dissemination with Security using FIWARE and Intel Software Gu...
Achieving Data Dissemination with Security using FIWARE and Intel Software Gu...Achieving Data Dissemination with Security using FIWARE and Intel Software Gu...
Achieving Data Dissemination with Security using FIWARE and Intel Software Gu...
 
Internet das Coisas com Edgex Foundry
Internet das Coisas com Edgex FoundryInternet das Coisas com Edgex Foundry
Internet das Coisas com Edgex Foundry
 
OPTEE on QEMU - Build Tutorial
OPTEE on QEMU - Build TutorialOPTEE on QEMU - Build Tutorial
OPTEE on QEMU - Build Tutorial
 
Presentation of my paper in the IEEE Symposium on Computer and Communications...
Presentation of my paper in the IEEE Symposium on Computer and Communications...Presentation of my paper in the IEEE Symposium on Computer and Communications...
Presentation of my paper in the IEEE Symposium on Computer and Communications...
 
Avaliação de Desempenho de uma Rede 802.11g em uma Usina Termoelétrica
Avaliação de Desempenho de uma Rede 802.11g em uma Usina TermoelétricaAvaliação de Desempenho de uma Rede 802.11g em uma Usina Termoelétrica
Avaliação de Desempenho de uma Rede 802.11g em uma Usina Termoelétrica
 
Apresentação sobre o modelo de segurança OPC UA
Apresentação sobre o modelo de segurança OPC UAApresentação sobre o modelo de segurança OPC UA
Apresentação sobre o modelo de segurança OPC UA
 
Modelo de segurança OPC UA
Modelo de segurança OPC UAModelo de segurança OPC UA
Modelo de segurança OPC UA
 
Introdução à Gestão de projetos
Introdução à Gestão de projetosIntrodução à Gestão de projetos
Introdução à Gestão de projetos
 
Integrating Fiware Orion, Keyrock and Wilma
Integrating Fiware Orion, Keyrock and WilmaIntegrating Fiware Orion, Keyrock and Wilma
Integrating Fiware Orion, Keyrock and Wilma
 
Programação C - Aula 1
Programação C - Aula 1Programação C - Aula 1
Programação C - Aula 1
 
Programação C - Aula 2
Programação C - Aula 2Programação C - Aula 2
Programação C - Aula 2
 
Programação C - Aula 3
Programação C - Aula 3Programação C - Aula 3
Programação C - Aula 3
 
Programação C - Aula 4
Programação C - Aula 4Programação C - Aula 4
Programação C - Aula 4
 
Desenvolvimento Web com JSF
Desenvolvimento Web com JSFDesenvolvimento Web com JSF
Desenvolvimento Web com JSF
 

Último

Certificado - Data Analytics - CoderHouse.pdf
Certificado - Data Analytics - CoderHouse.pdfCertificado - Data Analytics - CoderHouse.pdf
Certificado - Data Analytics - CoderHouse.pdfLarissa Souza
 
Apresentação Comercial VITAL DATA 2024.pdf
Apresentação Comercial VITAL DATA 2024.pdfApresentação Comercial VITAL DATA 2024.pdf
Apresentação Comercial VITAL DATA 2024.pdfCarlos Gomes
 
Apresentação Power Embedded - Descubra uma nova forma de compartilhar relatór...
Apresentação Power Embedded - Descubra uma nova forma de compartilhar relatór...Apresentação Power Embedded - Descubra uma nova forma de compartilhar relatór...
Apresentação Power Embedded - Descubra uma nova forma de compartilhar relatór...Dirceu Resende
 
From_SEH_Overwrite_with_Egg_Hunter_to_Get_a_Shell_PT-BR.pdf
From_SEH_Overwrite_with_Egg_Hunter_to_Get_a_Shell_PT-BR.pdfFrom_SEH_Overwrite_with_Egg_Hunter_to_Get_a_Shell_PT-BR.pdf
From_SEH_Overwrite_with_Egg_Hunter_to_Get_a_Shell_PT-BR.pdfRodolpho Concurde
 
Concurso Caixa TI - Imersão Final - Rogério Araújo.pdf
Concurso Caixa TI - Imersão Final - Rogério Araújo.pdfConcurso Caixa TI - Imersão Final - Rogério Araújo.pdf
Concurso Caixa TI - Imersão Final - Rogério Araújo.pdfGuilhermeRodrigues896381
 
[ServiceNow] Upgrade de versão - 2ª edição (Revisada, atualizada e ampliada)
[ServiceNow] Upgrade de versão - 2ª edição (Revisada, atualizada e ampliada)[ServiceNow] Upgrade de versão - 2ª edição (Revisada, atualizada e ampliada)
[ServiceNow] Upgrade de versão - 2ª edição (Revisada, atualizada e ampliada)Alessandro Almeida
 

Último (6)

Certificado - Data Analytics - CoderHouse.pdf
Certificado - Data Analytics - CoderHouse.pdfCertificado - Data Analytics - CoderHouse.pdf
Certificado - Data Analytics - CoderHouse.pdf
 
Apresentação Comercial VITAL DATA 2024.pdf
Apresentação Comercial VITAL DATA 2024.pdfApresentação Comercial VITAL DATA 2024.pdf
Apresentação Comercial VITAL DATA 2024.pdf
 
Apresentação Power Embedded - Descubra uma nova forma de compartilhar relatór...
Apresentação Power Embedded - Descubra uma nova forma de compartilhar relatór...Apresentação Power Embedded - Descubra uma nova forma de compartilhar relatór...
Apresentação Power Embedded - Descubra uma nova forma de compartilhar relatór...
 
From_SEH_Overwrite_with_Egg_Hunter_to_Get_a_Shell_PT-BR.pdf
From_SEH_Overwrite_with_Egg_Hunter_to_Get_a_Shell_PT-BR.pdfFrom_SEH_Overwrite_with_Egg_Hunter_to_Get_a_Shell_PT-BR.pdf
From_SEH_Overwrite_with_Egg_Hunter_to_Get_a_Shell_PT-BR.pdf
 
Concurso Caixa TI - Imersão Final - Rogério Araújo.pdf
Concurso Caixa TI - Imersão Final - Rogério Araújo.pdfConcurso Caixa TI - Imersão Final - Rogério Araújo.pdf
Concurso Caixa TI - Imersão Final - Rogério Araújo.pdf
 
[ServiceNow] Upgrade de versão - 2ª edição (Revisada, atualizada e ampliada)
[ServiceNow] Upgrade de versão - 2ª edição (Revisada, atualizada e ampliada)[ServiceNow] Upgrade de versão - 2ª edição (Revisada, atualizada e ampliada)
[ServiceNow] Upgrade de versão - 2ª edição (Revisada, atualizada e ampliada)
 

Monografia - Ciência da Computação - UFCG

  • 1. Universidade Federal de Campina Grande Centro de Engenharia Elétrica e Informática Curso de Ciência da Computação Dalton Cézane Gomes Valadares Diego Renato dos Santos Thiago Gondim Ribeiro WUT2S (Web Usability Test Task Scheduler) Ferramenta web para realização de testes de usabilidade Campina Grande 2007
  • 2. Dalton Cézane Gomes Valadares Diego Renato dos Santos Thiago Gondim Ribeiro WUT2S (Web Usability Test Task Scheduler) Ferramenta web para realização de testes de usabilidade Monografia apresentada ao Curso de Ciência da Computação da UFCG, como requisito para a obtenção parcial do grau de BACHAREL em Ciência da Computação. Orientador: Jacques Philippe Sauvé Doutor em Engenharia Elétrica - University of Waterloo Campina Grande 2007
  • 3. Introdução O WUT2S (Web Usability Test Task Scheduler) surgiu da necessidade de informatização do processo de realização de testes de usabilidade do Laboratório de Interface Homem-Máquina (LIHM) do Parque Tecnológico da Paraíba (PaqTc-Pb). Um teste de usabilidade, no contexto da computação, é um método para verificar a facilidade de uso de uma interface para os seus usuários finais. Possíveis usuários do produto a ser testado devem utilizar o mesmo em um ambiente monitorado. As ações desses usuários, ao utilizarem o produto, são gravadas e anotadas para depois serem analisadas por um avaliador. Os testes seguem um roteiro que possuem várias tarefas a serem executadas no produto (através das interfaces do mesmo). Os usuários são instruídos para se sentirem à vontade em relação ao produto testado: devem falar ou expressar qualquer desconforto que venham a sentir. Após a análise dos resultados obtidos durante o teste, algumas recomendações são geradas em relação a possíveis problemas encontrados nas interfaces do produto. O Laboratório de Interface Homem-Máquina, do PaqTc-Pb, presta serviços de projeto e avaliação caracterizados por uma série de atividades voltadas para uma integração mais efetiva da Universidade com o setor empresarial, em especial com a indústria. Dessa forma, tem oferecido às organizações interessadas uma gama de serviços de consultoria a projetos, iniciativas de implantação de tecnologias e/ou recomendações relativas a tomadas de decisões quanto à estruturação/aperfeiçoamento de ambientes e contextos de trabalho. Nesses serviços estão incluídos os testes de usabilidade para avaliação de produtos (sistemas desktop, sistemas web ou aplicações móveis). O projeto é um sistema web para informatizar o trabalho de obtenção de informação a respeito de testes relacionados com a área de Interface Homem-
  • 4. Máquina. Os testes de usabilidade são realizados para se ter uma idéia do grau de satisfação do usuário ao utilizar o produto (software) testado. Todos os testes, atualmente, são realizados de forma manual, o que faz com que o processo de colheita de dados, resultantes da observação dos testes, e a análise dos mesmos demandem um pouco mais de trabalho e de tempo, se comparado ao mesmo processo estando informatizado, já que grande parte da informação fica armazenada no computador, ao invés de vários papéis com formulários preenchidos, observações e outros dados relevantes à análise da ferramenta testada. Os testes de usabilidade são realizados por pessoas que provavelmente utilizarão o produto em questão, ou que apresentam um perfil semelhante, e são observados por alguns avaliadores. Os avaliadores observam todo o comportamento do usuário que está testando o produto e registram tudo o que acontece durante o teste, como: número de erros do usuário para executar determinada tarefa com o produto, tempo que o usuário leva para realizar todo o roteiro de teste, etc. Toda a informação obtida dos testes fica registrada em papéis que contêm formulários. Ao término de várias sessões de testes, cada avaliador tem uma grande quantidade de formulários que devem ser armazenados para depois serem analisados. Pode-se entender como problema a grande quantidade de informação a ser tratada “manualmente” e armazenada em vários arquivos físicos (vários formulários - como já citados -, notas de observação, etc.). Esse problema vem a ser solucionado com a construção do sistema web, pois este passa a armazenar toda a informação no computador, automatizando grande parte do processo de acompanhamento de testes de usabilidade realizados no LIHM do PacTc. O sistema permite cadastrar e consultar usuários, produtos, tarefas e outras “entidades” envolvidas em um teste de usabilidade, bem como acompanhar todo o teste, registrando as informações de maior relevância observadas durante a execução deste.
  • 5. Para construção do sistema foi utilizada a linguagem ASP .NET que faz parte do framework .NET 2.0 da Microsoft. A parte lógica foi desenvolvida na linguagem C#, também utilizando o .NET 2.0. Para o desenvolvimento o ambiente utilizado foi o Visual Studio 2005, também da Microsoft, e a persistência de dados é feita através do sistema de banco de dados MySQL. Algumas funcionalidades apresentadas na interface web foram desenvolvidas em JavaScript utilizando AJAX. O documento se encontra divido em cinco seções: na primeira é apresentado o contexto do projeto, citando, por exemplo, o perfil dos usuários e o ambiente de execução; na segunda seção, a fundamentação teórica é abordada, mostrando os principais conceitos e métodos utilizados no desenvolvimento do projeto; a terceira seção descreve a metodologia aplicada durante todo o projeto, com os processos e as ferramentas utilizadas; a penúltima seção apresenta os resultados obtidos com o projeto, desde o início do desenvolvimento até a conclusão do mesmo; e, por fim, a última seção é uma conclusão sobre tudo que foi obtido, envolvendo nível de satisfação do cliente, possíveis dificuldades encontradas, etc.
  • 6. Contexto do Projeto Eustáquio Rangel, doutor em Engenharia Elétrica pela Universidade Federal da Paraíba – UFPB, é avaliador no Laboratório de Interface Homem-Máquina – LIHM, localizado no Parque Tecnológico da Paraíba. Entre as atividades comuns, está a realização de baterias de testes (convencionais) de usabilidade. Nesses testes de usabilidade, indivíduos que representam uma classe de usuários em potencial de um determinado produto (comumente software) possam experimentar a sua utilização. O grau de facilidade com que esses usuários de teste conseguem lidar com o produto é um indicativo da qualidade de sua interface. Para que os resultados possam ser representativos para a precisão da avaliação, é necessária a realização do mesmo teste com uma quantidade mínima de usuários, e em cada teste é necessária a coleta de informações relacionadas ao tempo (duração, freqüência de determinados eventos, etc.), assim como em relação ao “espaço”, por exemplo a posição da tela onde o usuário tem maior dificuldade de encontrar algum controle, etc. Esses testes comumente geram um volume elevado de dados coletados, inclusive para uma quantidade pequena de testes. O modo tradicional de coleta desses dados é através de filmagem, mas também através de forma manuscrita. Não é incomum situações em que o mesmo avaliador era responsável por manusear mais de um cronômetro convencional, formulário em papel, e ainda ter necessidade de utilizar o microfone para se comunicar com o usuário de teste. Para diminuir os riscos de perda de informação, há a necessidade de uma ferramenta integrada para aumentar a produtividade do avaliador em sua operação de coleta de dados. A forma mais desejável era através de um sistema computacional. De preferência, o sistema deveria ser executado através do browser, através da web, devido a diversos motivos:
  • 7. • possibilidade de essa aplicação poder ser utilizada em ambientes distintos do LIHM; • não haver necessidade de instalação em diversas máquinas, bastando ser instalado em uma quantidade inferior de servidores; • possibilidade do compartilhamento de informações em localidades distantes geograficamente. Apesar de o sistema desejado ter de ser via web, ele não poderia ser significativamente lento, pois quanto maior a diferença de tempo entre um evento observado e seu registro, menos precisos são os resultados que serão avaliados após o teste. O cliente, em experiências semelhantes com equipes anteriores, recomendou fortemente evitar a utilização de JSP (Java Server Pages), se essa tecnologia causasse perda de desempenho em relação ao termpo de resposta. Uma restrição inerente de o sistema executar através da web é a impossiblidade da garantia de interação do sistema de coleta através de processos em execução na máquina do usuário de teste, como por exemplo aviso de que o tempo previsto para uma tarefa foi encerrado. Além disso, também há o interesse de essa ferramenta servir como uma agenda de atividades, para uso no LIHM e em outras instituições que não necessariamente realizem testes de usabilidade. Outra característica dispensável, porém atrativa era o desenvolvimento da ferramenta por alunos da Universidade Federal de Campina Grande, devido ao histórico de cooperação entre essa instituição e o Parque Tecnológico, fomentando a atuação de alunos em diversos problemas, incentivando o desenvolvimento do seu conhecimento na realização de sistemas utilizáveis em situações reais. Por essas características, o problema de construir a ferramenta de execução de testes de usabilidade foi disponibilizada no rol de alternativas para a disciplina de Projeto 1 e, por conseguinte, Projeto 2, sendo conduzida por:
  • 8. • Eustáquio Rangel, como cliente; • Dalton Cézane Gomes Valadares, Diego Renato dos Santos e Thiago Gondim Ribeiro, como desenvolvedores; • Francilene Garcia, como professora da disciplina Projeto 1; • Jacques Sauvé, como professor da disciplina Projeto 2. Ferramentas semelhantes Existem outras ferramentas de software que serve para acompanhar a realização de testes de usabilidade. O Usability Test Data Logger é um software baseado em macros do Microsoft Excel que permite a execução de todo o cliclo dos testes de usabilidade, desde o planejamento e a realização, até a síntese de dados. É inegável que ele possui características úteis para a os testes do LIHM, porém não é adaptável a um sistema distribuído através da rede, além de não é bastante flexível para se adaptar ao processo de realização de testes adotado pelo LIHM.
  • 9. Uma das telas do Usability Datalogger A empresa TechSmith também desenvolve ferramentas para a realização de testes de usabilidade, chamadas de Morae (modo standalone) e UserVue (web). Porém, ambas não são gratuitas, contrariando a prioridade por ferramentas não-proprietárias no LIHM. O mesmo vale para a UTE, um sistema para o mesmo fim, produzida pela MindDesign Systems. Em relação às operações de cadastro de atividades, estilo agenda, foi utilizada como referência a ferramenta TaskTimer. Ela permite o gerenciamento de atividades por categoria, relevância, além de ter um banco de dados integrado para o intercâmbio de informações entre os diversos usuários do sistema. Adicionalmente, ainda há a funcionalidade de integrar essas informações na forma de projeto, e assim avaliar o desempenho de funcionários através do
  • 10. cumprimento de metas. Infelizmente, a ferramenta também é proprietária, permitindo seu uso gratuito apenas para uma quantidade finita de vezes. Atuando em campos semelhantes na área de avaliação de interface homem-máquina, há outras ferramentas desenvolvidas por alunos da Universidade Federal de Campina Grande,: O WebQuest, que também é uma ferramenta acessível pela web responsável pela obtenção de dados subjetivos sobre a percepção de um usuário de teste sobre o produto a ser testado. Com o auxílio do WebQuest, é possível se traçar um perfil de usuário e na sondagem da satisfação subjetiva de usuários de sistemas interativos. O Fermint também é outra ferramenta que facilita é útil como um aliado da realização de testes de usabilidade. O Fermint permite se avaliar diretamente as possíveis falhas existentes em interfaces do produto-alvo, tal como um software. Associada ao WUT2S, pode auxiliar o planejamento do roteiro de teste.
  • 11. Fundamentação Teórica Plataforma .NET Utilizamos a plataforma .NET, a qual oferece uma alternativa de ambiente para produzir aplicações Windows e Web, executando-as nos mais diversos dispositivos (PCs, Palms, telefones celulares, etc). A Microsoft torna a infra- estrutura de suporte ao .NET amplamente disponível. O framework de suporte pode ser baixado e instalado livremente. O framework .NET O framework .NET, base da plataforma .NET, é uma plataforma de programação para desenvolvimento de aplicações essencialmente composto de duas partes: · Uma engine de execução chamada CLR; · Uma biblioteca de classes que disponibiliza as principais funções de programação. O código das aplicações .NET é compilado para MSIL (Microsoft Intermediate Language) e é armazenado em um arquivo chamado assembly. Em tempo de execução, o assembly é compilado para o seu estado final pela CLR. Enquanto está ativa, a CLR proporciona checagem de tipo (type-safety checks) e outras tarefas de run-time. Aplicações que rodam sob o CLR são chamadas aplicações de código gerenciado porque o CLR responsabiliza-se por tarefas que normalmente seriam de responsabilidade da aplicação. O assembly possui todas as informações de
  • 12. que o CLR precisa para rodar a aplicação. O CLR cuida dinamicamente do registro de componentes Introdução ao ASP.NET O ASP.NET é uma parte importante do framework .NET, mas trata-se simplesmente de uma parte. Faz-se necessário entender o restante do framework. Usa-se o ASP.NET para criar aplicações Web e Web Services que rodam sob o IIS (Internet Information Services). O que torna o ASP.NET especial é o fato dele ser fortemente integrado com ferramentas de programação, acesso à dados e segurança. O ASP.NET proporciona um alto nível de consistência no desenvolvimento de aplicações. Como já ressaltado, O ASP.NET, como já dito, é parte do framework .NET e composto de diferentes componentes: · Visual Studio .NET Web Development tools. Inclui ferramentas visuais para desenvolvimento de páginas Web, templates de aplicação e ferramentas de deployment; Oferece tudo o que é preciso para qualquer tipo de aplicação para Web, seja Design, código, componente, Web Service, camada de aplicação ou negócio; Incorpora nativamente diversas linguagens de programação, tais como: Visual Basic, Visual C++, J#, Cobol (inclusive) e C# (a qual usamos ao longo do desenvolvimento deste projeto). · System.Web namespaces. Fazem parte do frameWork .NET e incluem classes que tratam ítens específicos do mundo Web, tais como requisições HTTP, respostas (responses), browsers e e-mail;
  • 13. Organizada em namespaces, sua biblioteca de classes fornece acesso a todas as funcionalidades da CLR . Cada namespace contém um grupo de classes relacionadas. A tabela abaixo sintetiza os namespaces de maior interesse aos programadores Web. Categori Namespaces Utilização a Todos os tipos comuns de dados, incluindo strings, arrays e tipos númericos. Estas classes incluem Tipos métodos para System Comuns conversão de tipos, manipulação de strings e arrays, funções matemáticas e geração aleatória de números. Acesso à System.Data, Estas classes
  • 14. Dados System.Data.Common, incluem System.Data.OleDb, métodos de System.Data.SqlClient, conxão à System.Data.SqlTypes bancos de dados, execução de comandos, recuperação e modificação de dados. Classe para Debuggin System.Diagnostics Debugging e g tracing. Métodos para acesso so sistema de arquivos. Incluem System.IO, Acesso ao métodos de System.IO.IsolatedStor Sistema leitura e age, de escrita de System.DirectoryServic Arquivos arquivos e es outras operações sobre o sistema de arquivos.
  • 15. Comunicação através da internet utilizando protocolos de baixo nível, System.Net, tais como Rede System.Net.Sockets TCP/IP. Estas classes são utilizadas para criação de aplicações ponto-a-ponto (peer-to-peer). System.Security, System.Security.Crypto Autenticação e graphy, autorização de Seguranç System.Security.Permis usuários além a sions, de encriptação System.Security.Policy, de dados. System.Web.Security System.Web, Classes para System.Web.Caching, criação e System.Web.Configurat publicação de Aplicaçõe ion, componentes s WEB System.Web.Hosting, que podem ser System.Web.Mail, acessados System.Web.SessionSta através da
  • 16. te, System.Web.UI, internet. São System.Web.UI.Design, as principais System.Web.UI.WebCo classes ntrols, utilizadas para System.Web.UI.HtmlC a criação de ontrols Web Services ASP.NET. System.Windows.Form Classes para Aplicaçõe s, criação de s System.Windows.Form aplicações Windows s.Design Windows. System.Xml, Criação e System.Xml.Schema, acesso a XML System.Xml.Serializati arquivos on, System.Xml.Xpath, XML. System.Xml.Xsl · Server Controls e HTML Controls . São componentes visuais utilizados para obter informações e proporcionar respostas aos usuários da aplicação. Adicionalmente, O ASP.NET também utiliza componentes de programação mais gerais. Eles não fazem parte do ASP.NET mas são ítens chave para a sua utilização: · Microsoft Internet Information Services (IIS). Hospeda as aplicações Web. Todo o processamento é feito no servidor, onde encontra-se o Internet Information Server (IIS)
  • 17. · Visual Basic.NET, linguagens de programação Jscript e C# (a qual usamos ao longo do desenvolvimento do projeto). Estas três linguagens têm suporte integrado no Visual Studio.NET. · FrameWork .NET. É um conjunto completo de classes. Elas incluem classes ASP.NET, propriamente ditas, bem como outras classes de acesso a arquivos, conversão de tipos, manipulação de arrays e strings e assim por diante · ADO.NET. Este componente fornece acesso ao Microsoft SQL Server e outros bancos de dados acessados via ODBC. · Microsoft Application Center Test (ACT) . Este componente do Visual Studio.NET fornece um meio automatizado para fazer testes de stress com a aplicação. Ferramentas adicionais No ASP .NET, mais especificamente no Visual Studio .NET, contamos com o Server Explorer e com o Solution Explorer. - Server Explorer: excelente recurso, com o qual pode-se verificar todos os recursos existentes no computador. Com ele, pode-se, inclusive, criar banco de dados, tabelas, consultas, funções e Stored Procedures, e até, fazer a nanutenção de todos os registros de uma tabela. Utilizando-se de qualquer BD disponível. - Solution Explorer: ferramenta que permite administrar todos os arquivos contidos na solução.
  • 18. OOP A programação Orientada a Objetos (OOP) é padrão em todas as linguagens .NET e permite desenvolvimento estruturado, reaproveitamento de códigos, rotinas, classes e objetos. Deployment O processo de distribuição (Deploy) de uma aplicação ASP .NET é simples: copia-se os arquivos necessários para o servidor e cria-se o diretório virtual. Provedores Faz-se necessário ter Windows 2000 ou superior e, o Framework instalado. Onde rodar Em qualquer navegador, independentemente de fabricante ou versão Principais pontos envolvidos no processo de compilação de uma aplicação ASP.NET 2.0: Modelo de Código no ASP.NET 2.0 O ASP.NET 2.0 suporta dois modelos de código, code-inline e code-behind. Com relação ao modelo code-behind, no ASP.NET 2.0 o arquivo de código é uma implementação “parcial”. O arquivo code-behind segue o novo modelo de
  • 19. Partial Class. As classes parciais contém todo código implementado pelo desenvolvedor e omite o código gerado automaticamente pelo Visual Studio. Quando uma página ASPX com o novo modelo de code-behind é chamada, o ASP.NET 2.0 combina o arquivo ASPX (a qual contém a interface gráfica) e a classe parcial numa única classe ao invés de duas classes separadas. As classes parciais usam uma palavra-chave (Partial no C#) para indicar que o código nesta classe deve ser mesclado com outra classe quando em modo runtime. De maneira semelhante o arquivo ASPX utiliza uma diretiva CompileWith para indicar o arquivo de código associado. O modelo de herança é simplificado porque o arquivo de código (code-behind) não precisa conter as definições dos controles da página ASPX. Desta forma, o arquivo de código pode acessar automaticamente qualquer controle na página sem a necessidade de código declarativo. Isto é possível porque o Runtime do ASP.NET 2.0 insere automaticamente as declarações exigidas para os controles e eventos no arquivo compilado ao final do processo, desta forma o desenvolvedor não precisa preocupar-se com isso. Com esse novo modelo, o arquivo de código e a página ASPX são mesclados e compilados numa única e completa classe em runtime eliminando a complexidade do processo de compilação. A sincronização entre o arquivo de código e o arquivo ASPX é automática, mas ainda assim é possível que o código seja alterado no arquivo ASPX e não atualizado no arquivo de código, contudo o desenvolvedor poderá localizar o problema de forma muito mais rápida uma vez que o ASP.NET 2.0 gerará uma Exception muito mais detalhada. Modelos de compilação no ASP.NET 2.0 O ASP.NET 2.0 suporta diferentes modelos de compilação para uma aplicação
  • 20. Web, apresentados abaixo: Default: (ASP.NET 1.x) Neste modelo de compilação, os arquivos de código são compilados num assembly e armazenados na pasta /bin da aplicação. As páginas ASPX são compiladas por demanda. Este modelo funciona bem para a maioria dos websites. Contudo, este processo de compilação torna a primeira requisição de qualquer página da aplicação mais lenta do que as requisições subsequentes. Não existe nenhum procedimento manual para realizar a compilação default. O Runtime do ASP.NET 2.0 se encarregará de realizar a compilação quando receber a primeira requisição para a aplicação. Se alguma alteração for feita, no próximo request da página alterada, o Runtime do ASP.NET 2.0 determinará as dependências do arquivo alterado e realizará a compilação apenas para os arquivos envolvidos na alteração. Vantagens: · Simples, pois o Runtime do ASP.NET faz todo o trabalho para você. · É a melhor opção para a fase de desenvolvimento da sua aplicação Web, pois evita as etapas necessárias para realizar pré-compilações. In-Place Compilation (Pré-Compilação no Servidor de Produção) Pode-se usar a ferramenta ASP.NET Compilation Tool (Aspnet_compiler.exe), localizada na pasta C:WINDOWSMicrosoft.NETFrameworkv2.0.50727, para pré-compilar aplicação. O processo é semelhante ao que ocorre em tempo de execução. A ferramenta provoca vários requests para o website provocando a compilação do mesmo. Se altera-se a página da aplicação, deve-se repetir o processo de pré-compilação, caso contrário o Runtime do ASP.NET 2.0 terá que
  • 21. fazer a compilação em tempo de execução na próxima requisição do arquivo alterado. Vantagens: · Tmpo de resposta para o primeiro request da aplicação é reduzido. · Não é necessário executar nenhum procedimento especial para o deployment após a compilação. Deve-se usar esse modelo quando houver necessidade de frequentes alterações nas páginas e/ou quando quiser reduzir o tempo de resposta do primeiro request, mas deve-se lembrar que os arquivos de código estarão disponíveis para todos que tiverem acesso à pasta da aplicação. Deployment Pre-Compilation Este modelo inserido no ASP.NET 2.0 permite ao desenvolvedor fazer a compilação completa da sua solução antes de fazer o deployment. Com a compilação completa, todos os arquivos code-behind, páginas ASPX, HTML, recursos gráficos, são compilados em um ou mais assemblies, dependendo do tamanho da aplicação e da configuração da compilação. Os assemblies contém o Website completo, com exceção do arquivo Web.config. Este modelo de compilação oferece a melhor performance e segurança se comparado com os outros modelos, porém remove a capacidade de qualquer alteração no Website após feito o deployment. Se trabalha-se em um website altamente visado, ou que exige alto nível de segurança, este modelo é a melhor opção para o deployment final. Contudo, se desenvolve-se um pequeno website, trabalhando numa intranet local, e o projeto requer frequentes mudanças, este modelo de compilação porde tornar-se inviável.
  • 22. Pre-Compilation com camada de apresentação atualizável Com a utilização do parâmetro –u da ferramenta ASP.NET Compilation, o desenvolvedor pode pré-compilar os arquivos de código (*.vb ou *.cs) e os arquivos de recursos (*.resource), deixando o código da camada de apresentação (HTML) disponível para atualizações. Depois de realizar o deployment do website no servidor de produção, os arquivos ASPX podem ser modificados sem a necessidade de recompilar a aplicação. Vantagens: · Tempo de resposta para o primeiro request da aplicação é reduzido. · Os designers podem modificar a aparência do Website sem necessidade de recompilar a aplicação. · A propriedade intelectual é protegida pois os arquivos de código ficam disponíveis neste modelo de compilação. Pre-Compilation com camada de apresentação não atualizável A ferramenta ASP.NET Compilation pode compilar todo código-fonte de uma aplicação, incluindo os arquivos de interface (ASPX, ASCX), encapsulando-os em assemblies que são publicados na pasta /bin da aplicação. Vantagens: · Tempo de resposta para o primeiro request da aplicação é reduzido. · A propriedade intelectual é completamente protegida pois todos os arquivos de código-fonte e arquivos de apresentação são compilados em *.dlls.
  • 23. Metodologia Este capítulo visa apresentar a metodologia usada. Como a equipe de desenvolvimento trabalhou para o desenvolvimento do projeto, quais e como foi o processo de desenvolvimento, como foram feitos o controle de versão, o ambiente de desenvolvimento, a comunicação com o cliente e entre os membros desenvolvedores, etc. E por fim, é apresentado comentários relevantes. Durante o desenvolvimento do projeto, correspondente à disciplina Projeto1 e Projeto2, o processo de desenvolvimento utilizado foi o XP1. A seguir, uma descrição do processo seguido: Definições - Iteração É a unidade de planejamento detalhado, durando, em XP1, duas semanas. O escopo é variável, sendo definido na fase de planejamento. - Release É a liberação e instalação de uma versão do software para avaliação do cliente. Um release em XP1 é composto de iterações, preferencialmente poucas, entre 2 e 5. Atividades
  • 24. As atividades realizadas em XP1 podem ser brevemente descritas da seguinte maneira: - Planejamento: abrange a escrita de User Stories (funcionalidades), levantamento de requisitos não funcionais, planejamento de releases e de iteração; - Projeto: se divide em projeto arquitetural e refatoramento constante; - Testes: inclui a elaboração de testes de aceitação e de unidade, assegurando que o software se comporta de maneira desejada a cada situação testada; - Integração: quando se utiliza o controle de versão, garantindo que o software com o qual o programador vai trabalhar está em sua versão mais atualizada. Assegura-se isto fazendo check-out (adquirir a versão mais atualizada do projeto para desenvolver uma tarefa) antes de iniciar o desenvolvimento e fazendo check-in (atualizar o projeto, acoplando a tarefa que acabou de ser desenvolvida) ao finalizar o desenvolvimento; - Acompanhamento: atividade que assegura a manutenção do progresso do projeto, sendo desempenhada pelo gerente. Gestão do Código Durante todo o período de desenvolvimento do projeto, o código foi compartilhado entre seus desenvolvedores. No planejamento, cada
  • 25. funcionalidade tornava-se responsabilidade de um desenvolvedor especíco, porém com o compartilhamento do código incentivado, de forma que todos os desenvolvedores poderiam ajudar em qualquer parte implementada, mesmo que não fosse, à priori, de sua responsabilidade. Para tanto, manteve-se o código atualizado em uma base de dados segura, um repositório de código-fonte de fácil acesso. No nosso caso, à princípio, tentamos o Concurrent Versions System (CVS) do www.cvsdude.com, porém obtivemos problemas de configuração e migramos para o “Subversion” (sistema de controle de versão, também conhecido svn ou SVN, desenhado especificamente para ser um substituto moderno do CVS, que se considera ter alguns defeitos) do GoogleCode. Ambiente de Desenvolvimento O ambiente de desenvolvimento escolhido foi o VisualStudio.NET. Os desenvolvedores do projeto o escolheram, pois além de sua familiaridade, o VisualStudio .NET também é uma ferramenta poderosa, de fácil utilização, alta portabilidade, muito flexível para utilização de plugins e uma das mais completas IDE´s da atualidade. Possui integração com o banco de dados escolhidos (MySQL), Nunit e todas as demais ferramentas por nós utilizadas. Para testes, usamos o NUnit e o EasyAcceptToNUnit. O primeiro como um framework para confecção de testes automáticos de software e, o segundo, como uma ferramenta para automatizar testas de aceitação para projetos em .NET. Ambos de fundamental importância para o êxito do projeto por facilitar a
  • 26. implementação e execução dos testes de software, tornando um processo leve e de fácil aceitação. Comunicação A comunicação, como em todas as áreas, é parte vital para o sucesso de um projeto. Na primeira metade do projeto, não havia reuniões presenciais mas, virtuais. Estas se davam através de correio eletrônico e mensageiros instantâneos. Pessoalmente, discutíamos antes e após as reuniões semanais com o cliente. Porém, percebeu-se a importância e necessidade de reuniões presenciais e, semanalmente, aos sábados, passamos a nos reunir, durante praticamente toda a tarde. Na reunião discutíamos questões pendentes e trabalhávamos conjuntamente no código propriamente dito. É importante ressaltar que a comunicação virtual continuou existindo ao longo de todo o processo e que dávamos continuidade ao código individualmente, em nossos domicílios. Todos estavam livres para tirar qualquer dúvida sobre a implementação com os outros integrantes e/ou com o próprio cliente. O qual demonstrou grande disponibilidade e prestatividade para esclarecer eventuais questões. Muitas dúvidas, quanto ao projeto como um todo, foram clarificadas durante as reuniões semanais com o mesmo. Reuniões tais que foram de indubitável importância, chegando a durar aproximadamente 1 hora, se necessário. Desta maneira, o cliente estava sempre como um membro da equipe de desenvolvimento, acompanhando de perto cada passo e validando as
  • 27. funcionalidades recém-implementadas por meio de demonstrações por parte dos desenvolvedores. Com isto, a qualquer momento da implementação do projeto, o cliente tinha noção do nível de progresso que estava havendo. Outro fator positivo quanto ao cliente foi que este era da área de computação e, conseqüentemente, sabia explicar (inclusive com termos técnicos) o que desejava. Portanto, suas especificações tinham maior chance de serem corretamente interpretadas e executadas pelos desenvolvedores. Responsabilidades Os integrantes da equipe puderam desempenhar três papéis: cliente, desenvolvedor ou gerente. O cliente foi responsável por descrever as user stories (US), ou seja, funcionalidades, os requisitos não-funcionais, os testes de aceitação, o plano de releases e a distribuição das user stories por cada iteração, não podendo estimar o tempo em que as user stories deveriam ser concluídas. O cliente também se dispôs a tirar dúvidas dos desenvolvedores quando/se surgissem. Os desenvolvedores, por sua vez, apoiaram o cliente na definição de user stories e requisitos não-funcionais, elaboraram o projeto arquitetural e estimaram o tempo de desenvolvimento das user stories durante o planejamento de releases. Durante a fase do planejamento de iteração, dividiram as user stories daquela iteração em tarefas, escolheram quais tarefas iriam desenvolver e estimaram precisamente o tempo de desenvolvimento de cada tarefa. Também
  • 28. desenvolveram o esquema lógico e testes de unidade para cada tarefa, sempre fazendo integração. Já o gerente foi responsável por cobrar o andamento do projeto, conduzir as atividades de planejamento, descobrir riscos e traçar estratégias para lidar com os mesmos.Cada um dos alunos foi gerente durante uma release e o gerente acumulava também as responsabilidades de desenvolvedor. Prazos de entrega Em datas definidas pelas ministrantes das disciplinas, as equipes entregam algum resultado de seu trabalho. Existem três tipos de entrega: - Apresentação de planejamento: devem-se entregar artefatos resultantes da análise do sistema, ou seja, requisitos funcionais e não-funcionais, projeto arquitetural e o planejamento de releases e iterações, distibuindo as funcionalidades nas mesmas. - Apresentação de iteração: artefatos de acompanhamento devem ser apresentados, como big charts, tabela de cumprimento de atividades, etc; - Apresentação de release: além dos artefatos mencionados acima, deve-se ter uma versão do sistema disponível para apresentação à ministrante e ao cliente. Demonstrações das Funcionalidades
  • 29. Sempre que funcionalidades significativas eram implementadas, nós as mostravam ao cliente durante as reuniões semanais. Comentários - A ferramenta EasyAcceptToNUnit foi uma adaptacao implementada exclusivamente para este projeto. Já existia o EasyAccept, a qual tem a mesma funcionalidade mas trabalha com a linguagem Java; - Um dos integrantes (Thiago Gondim) não possuía familiaridade com a linguagem e plataforma utilizadas, pois este projeto é uma continuidade do projeto da disciplina LES (Laboratório de Engenharia de Software), do qual ele não fazia parte. Este membro fazia parte de outro projeto porém decidiu mudar para este por ter achado a proposta interessante e por desejar ampliar seus horizontes, aprendendo algo como .NET
  • 30. Resultados O WUT2S é um sistema web que apresenta toda sua interface desenvolvida em ASP .NET. Toda a lógica do sistema foi implementada na linguagem C#, utilizando o Visual Studio como ambiente de desenvolvimento. Algumas funcionalidades da interface foram desenvolvidas com JavaScript, utilizando a biblioteca ASP .NET AJAX (antigo ATLAS). A interface do sistema apresenta abas com o intuito de aproximar o uso deste com o uso de determinados sistemas desktop. Menus são utilizados em cada aba, seguindo um padrão para facilitar a utilização das funcionalidades do sistema. A escolha das linguagens se deu após se ter tomado conhecimento dos servidores Windows que se encontram no LIHM e baseado em certa familiaridade dos integrantes do projeto com as mesmas. Além disso, a escolha dessa tecnologia de geração de páginas com conteúdo dinâmico (ASP .NET/C#) se deve ao fato da mesma ser mais veloz que outras tecnologias (por exemplo, JSP, ASP). Por que ASP .NET? Benefícios do ASP .NET: • Código compilado não interpretado, com isso são evitados erros em design-time e as aplicações rodam mais rápido. • Melhor tratamento de erro através de controles de validação e blocos try- catch. • Controles desenvolvidos pelo usuário permitem maior reuso de código. • Controles muito similares aos controles de Windows permitindo uma maior facilidade do usuário. • Habilidade de fazer cache de toda a página ou só de algumas partes dela para aumentar o desempenho.
  • 31. Usa o conceito de code-behind que separa o código da lógica com a apresentação. • Recupera-se de memory leak e crashs. • Uso de master pages que permitem definir um modelo de página principal, onde todas as outras páginas podem seguir esse modelo. • Uso de temas (pode-se usar também CSS) para definir o look-and-feel de toda a página Web. • Código totalmente OO sem preocupações com Scripts. • Event-driven model em desenvolvimento Web. • Suporte total aos padrões HTML 4.0, XHTML 1.0 e 1.1 e suporte extensivo a CSS. • Modelo de adaptive render onde os componentes detectam a cultura do seu browser e a partir de então usam o padrão correto para seu browser, suportando inclusive padrões HTML, WML, XHTML, e CHMTL; alguns desses padrões para dispositivos móveis. • Todos os controles possuem grande customização. Benefícios para o usuário: • A aplicação vai funcionar corretamente no seu browser. • Experiência semelhante à de usar uma aplicação desktop graças aos controles do ASP .NET. • Maior velocidade de resposta graças à pré-compilação feita no servidor e ao sistema de caching (podendo ser automático ou manual). • Alguns controles: o Controle de Log In: o Facilita ao usuário a operação de Login; outros controles associados a Login, como criação de novo usuário e recuperação de senha, também estão presentes.
  • 32. File Upload: permite ao usuário fazer o upload de um arquivo. • DataGridView: ideal para visualização de dados de um BD, operações de CRUD como editar e remover podem ser realizadas no próprio controle. • Menu semelhante ao menu principal de vários aplicativos desktop. • Calendário • Vale sempre lembrar que esses e os demais controles são customizáveis permitindo mudança de cores de texto, de plano de fundo, entre outros.
  • 33. Existe também a possibilidade de se combinar vários controles para se criar um novo controle, como, por exemplo, um controle de preenchimento de data de nascimento. • Controles totalmente novos também podem ser criados. Desvantagens do ASP.NET: • Portabilidade: Só roda em algumas versões do Windows. • Algumas exceções globais não tratadas podem gerar falhas muito dificilmente detectadas. • O modelo de adaptive render nem sempre funciona corretamente, algumas vezes é necessário “estender” Browser capabilities para que os controles gerem o padrão HTML correto. • O primeiro acesso à aplicação pode ser mais lento devido à compilação ser executada no mesmo, outros modelos de compilação podem resolver o problema. • Apesar de o seu uso ser gratuito, não é open source. • Nem todos os SGBDs fornecem um conector .NET, no entanto é possível se conectar via ODBC. • Estudos comparativos e links: o http://www.brillianceweb.com/betterwebdesign/tips_52.aspx o http://www.gotdotnet.com/team/compare/ o http://p2p.wrox.com/topic.asp?TOPIC_ID=47496 desvantagens do .NET e do ASP .NET. o http://www.linhadecodigo.com.br/artigos.asp?id_ac=957 mostra os vários modelos de compilação do ASP .NET. Requisitos Os principais requisitos da aplicação foram:
  • 34. • Funcionais o Permitir autenticação de usuários e o controle de seu acesso. o Permitir o agendamento de tarefas e eventos, e o registro de sua execução. o Consultar dados de testes anteriores, inclusive a observação de estatísticas sobre os dados de testes, como tempo, número de erros, reincidência de erros, perfil dos usuários e comentários adicionais. • Não-funcionais o Ser disponível para se usar via web, em servidor Windows. o Usar ferramentas livres. o Tempo de resposta não pode ser demorado. Projeto Arquitetural A arquitetura do sistema é baseada no padrão MVC (Model-View- Controller), a diferença é que a mesma apresenta um Web Service atuando como façade permitindo uma maior flexibilidade caso seja necessário realizar mudanças. A figura abaixo apresenta um modelo da arquitetura utilizada:
  • 35. Uma vantagem dessa arquitetura é que ela pode ser facilmente adaptada para aplicações desktop ou mesmo para dispositivos móveis. Para dispositivos móveis, a arquitetura é apresentada a seguir:
  • 36. É interessante observar que o esforço de migração é mínimo, uma vez que toda a lógica de negócio se mantém e o acesso via Web Service pode ser feito da mesma maneira. Para aplicações desktop, a figura abaixo apresenta uma arquitetura possível: E ainda, caso seja necessário se optar por outra tecnologia ao invés do .NET, o modelo e o acesso a ele se mantêm:
  • 37. É válido observar, também, que a única mudança se dá na camada de aplicação, pois com essa arquitetura são mantidas a lógica e o acesso à mesma. A persistência dos dados é realizada com o sistema de banco de dados MySQL, por ser gratuito e por apresentar eficiência satisfatória. Há a possibilidade (interesse do cliente) de integrar, no futuro, a ferramenta WUT2S ao Fermint e ao WebQuest (já mencionados anteriormente na contextualização do projeto), mas não se tem tanta certeza, pois seus códigos nem foram vistos ainda. Uma possibilidade de integração pode se dar através do web service (diagrama acima) ou pelo compartilhamento da base de dados. User stories As user stories desenvolvidas durante o período de curso da disciplina Projeto I foram as seguintes: • Login de usuários: o Entrar com login e senha válidos, e o sistema levar o usuário à tela principal.
  • 38. o Entrar com login e senha inválidos, e o sistema mostrar mensagem de erro. • Cadastro de tarefas: o Criar, alterar, remover e consultar tarefas • Cadastro de usuários participantes de testes: o Criar, alterar, remover e consultar usuários participantes • Cadastro de usuários avaliadores: o Criar, alterar, remover e consultar usuários avaliadores • Cadastro de eventos (posteriormente alterados para indicadores de usabilidade): o Criar, alterar, remover e consultar eventos (indicadores de usabilidade) • Cadastro de projetos: o Criar, alterar, remover e consultar projetos • Cadastro de produtos: o Criar, alterar, remover e consultar produtos • Cadastro de sessões de teste: o Criar, alterar, remover e consultar sessões de teste • Cadastro de roteiros de teste: o Criar, alterar, remover e consultar roteiros de teste Durante a disciplina Projeto II, foram implemantadas a seguintes user stories: • Alteração do roteiro de teste: o Configuração de ordem de tarefas e indicadores de usabilidade o Visualização, remoção de tarefas e indicadores de usabilidade
  • 39. • Alteração de sessões de teste: o Vinculação entre usuários e sessões de teste • Execução de testes de usabilidade: o Inicialmente com cronômetro síncrono e apenas uma quantidade fixa de indicadores de usabilidade • Criação da apresentação de resultados: o Por sessão o Por projeto o Por usuário em cada sessão • Reformulação do código: o Interface o Código da lógica de negócio • Implementação de políticas de visualização por tipo de usuário • Criação do help on line e manual Além dessas user stories, no início do projeto e no decorrer do mesmo também foram criadas outras, porém com uma “menor” relevância para o escopo do sistema, levando em consideração o tempo para finalização deste. Por isso, estas user stories não foram implementadas, mas ficaram guardadas para que, com uma possível solicitação do cliente, as mesmas incorporem mais funcionalidades e características ao sistema.
  • 40. Big chart Data Módulos Classes Classes Classes Classes Páginas Páginas de de lógica de ASP ASP lógica alteradas interface .NET .NET alteradas LES 8 24 8 0 20 20 0 Iteração 12/03/2007 8 35 8 0 26 26 8 01 - P1 Iteração 26/03/2007 10 40 10 0 28 28 8 02 - P1 Iteração 09/04/2007 11 48 14 3 31 31 15 03 - P1 Iteração 23/04/2007 11 50 15 5 35 35 18 04 - P1 Iteração 14/05/2007 12 56 18 6 38 38 20 05 - P1 Iteração 25/06/2007 12 66 21 10 45 45 24 01 - P2 Iteração 09/07/2007 13 75 24 12 51 51 26 02 - P2 Iteração 22/07/2007 13 78 28 15 57 57 29 03 - P2 Iteração 05/08/2007 13 81 29 17 59 59 34 04 - P2 Iteração 19/08/2007 15 95 32 21 63 63 38 05 - P2 Iteração 03/09/2007 15 98 33 25 64 64 47 06 - P2
  • 41. Data Java Testes de Testes de aceitação Script Unidade (linhas) (métodos) LES 4 18 56 Iteração 01 - 12/03/2007 4 22 68 P1 Iteração 02 - 26/03/2007 4 25 82 P1 Iteração 03 - 09/04/2007 4 29 87 P1 Iteração 04 - 23/04/2007 4 33 97 P1 Iteração 05 - 14/05/2007 4 38 122 P1 Iteração 01 - 25/06/2007 4 44 165 P2 Iteração 02 - 09/07/2007 15 51 227 P2 Iteração 03 – 22/07/2007 15 53 254 P2 Iteração 04 - 05/08/2007 16 58 303 P2 Iteração 05 - 19/08/2007 17 69 341 P2 Iteração 06 - 03/09/2007 17 75 425 P2
  • 42. Interface O sistema apresenta uma tela de login como tela inicial. Nesta tela o usuário deve entrar com seu login e sua senha válidos, a fim de obter acesso às funcionalidades da ferramenta. A tela inicial é mostrada na figura abaixo:
  • 43. É válido mencionar que a figura ainda está com o antigo logotipo do sistema, o Platinum Test. Após o usuário ser validado (login e senha corretos), a tela principal do sistema aparece. Esta tela apresenta abas para facilitar a navegação do usuário pelo sistema. Dependendo do que se quer fazer, três abas podem ser selecionadas (além de apresentar a aba inicial que mostra a saudação ao usuário): Cadastro, Consulta ou Execução de teste. Cada uma apresenta um menu contendo opções referentes ao que se quer cadastrar, consultar ou executar. Na aba Cadastro e na aba Consulta, o menu contém as seguintes opções: Usuário (na aba Consulta, a opção Usuário apresenta, ainda, duas opções: Avaliador e Participante de teste), Projeto, Produto, Tarefa, Indicador de
  • 44. usabilidade, Roteiro de teste e Sessão de teste. A aba Execução de teste apresenta informações relacionadas aos roteiros de teste cadastrados. As duas figuras abaixo apresentam, respectivamente, a tela principal na aba Início e na aba Cadastro:
  • 45.
  • 46. Conclusões Ao término dessa disciplina, o sistema pode ser considerado pronto para ser utilizado no LIHM do PaqTc-Pb. Durante o período de dois semestres letivos foram desenvolvidas as funcionalidades da ferramenta citada neste documento. Seguindo a metodologia mencionada anteriormente, a equipe desenvolvedora dividiu todas as tarefas a serem executadas, em cada user storie, e, em alguns momentos, também fez prática de pair programming, ficando dois desenvolvedores resolvendo um mesmo problema. Alguns desafios apareceram e foram superados, como, por exemplo: a falta de conhecimento em AJAX, já que algumas funcionalidades na interface precisaram ser desenvolvidas em JavaScript (com o uso de AJAX os resultados obtidos foram satisfatórios). Além disso, houve um rigor maior relacionado à interface do sistema, já que o cliente trabalha diretamente na área de “Interface Homem-Máquina” e o sistema é voltado para um público que também trabalha nessa área. Como ninguém da equipe que desenvolveu o projeto tinha formação (bons conhecimentos) nesta, foi gasto um tempo maior do que o esperado com problemas relacionados à interface. No decorrer do desenvolvimento, também foram sugeridas modificações em alguns pontos que já haviam sido discutidos, o que impôs certo atraso também no andamento do projeto. Mas tudo isso serviu de aprendizado e mostrou que, com um bom planejamento e uma boa organização de tarefas, os problemas quando aparecem são mais fáceis de tratar e não atrasam tanto quanto se não houvesse um bom planejamento anteriormente. Cada integrante da equipe passou por um período de gerência do projeto, o que fez com que cada um ganhasse certa experiência, também, em relação ao conhecimento de gerenciamento de projetos, já que todos não ficaram apenas na visão de desenvolvedores do sistema.
  • 47. Pode-se dizer que o cliente está de acordo com tudo o que foi feito, pois todas as funcionalidades que tinham prioridade foram implementadas de acordo com o que foi pedido. Funcionalidades extras podem ser desenvolvidas, segundo a vontade do cliente, desde que haja mais tempo para tal. Trabalhos futuros podem fazer a integração entre este sistema e outros já citados ao longo deste documento, sem grandes complicações, acredita-se.
  • 48. Referências Bibliográficas LOBO, R. C. L. & QUEIROZ, J. E. R. & TURNELL, M. F. Q. V. WebQuest: Uma ferramenta Web configurável para o delineamento do perfil e a sondagem da satisfação subjetiva do usuário. Disponível em: http://grise.upm.es/rearviewmirror/conferencias/jiisic04/Papers/11.pdf. MOBRIPRO. Tasktimer. Disponível em: http://www.mobipro.com/products.asp?pID=1. TECHSMITH. Morae. Disponível em: http://www.techsmith.com/morae.asp. _______. UserVue. Disponível em: http://www.techsmith.com/uservue.asp. USERFOCUS. Usability Test Data Logger tool v4.2. Disponível em: http://www.userfocus.co.uk/resources/datalogger.html. WEBQUEST. Disponível em: http://www.lihm.paqtc.org.br/webquest/.
  • 49. Apêndice 1 – Glossário de termos mais utilizados na plataforma .NET Como toda nova tecnologia, a plataforma .NET inclui uma série de novos termos. Os mais comuns estão listados abaixo: CLR – Sigla de Common Language Runtime. Base comum a todas as linguagens escritas para a plataforma. O CLR é o ambiente que gerencia a execução de código escrito em qualquer linguagem. O CLR faz parte do framework .NET. FRAMEWORK .NET – É a estrutura da plataforma .NET para construir, instalar e rodar qualquer aplicação, seja ela desenvolvida para desktop ou internet. Para executar qualquer programa .NET é preciso ter o framework instalado. IDE – Ambiente integrado de desenvolvimento (Integrated Development Environment) do Visual Studio .NET. Diferentes linguagens usam o mesmo ambiente para desenvolvimento (editor de código, depurador) e compilam executáveis na linguagem MSIL. Além das linguagens nativas suportadas existem pelo menos outras vinte que foram portadas para este ambiente (Perl, Cobol, Pascal, etc). MSIL – Microsoft Intermediate Language. Toda aplicação .NET compilada é convertida para uma linguagem intermediária, a MSIL. Ela é um conjunto de instruções independentes de CPU. Na hora da execução do programa, um novo compilador chamado Just-in-time Compiler (JIT), converte o MSIL para código nativo, específico para o processador da máquina. MANAGED CODE - Código gerenciado pelo framework .NET. Tarefas como alocação de memória e garbage collector são gerenciadas automaticamente pelo ambiente. Das linguagens nativas apenas o C++ produz código não gerenciado (Unmanaged Code). SOAP – Sigla de Simple Object Access Protocol. O SOAP é um padrão aberto baseado em XML e gerenciado pelo W3C para a transferência de dados entre aplicações. Pode ser usado em conjunto com vários outros protocolos comuns da internet. UDDI – Sigla de Universal Description, Discovery and Integration. Funciona como uma espécie de páginas amarelas para Web Services. Na UDDI, empresas podem expor seus serviços para que outras pessoas possam utilizá-lo. XML – Sigla de Extensible Markup Language. O XML é uma linguagem baseada em tags, semelhante ao HTML. Sua principal característica é a extensibilidade. Quem cria um documento XML pode introduzir tags personalizadas, que podem ser explicadas em um documento XSD anexo. XSD – Sigla de Schema Definition. Documento associado a um documento XML utilizado para descrever e validar os dados do documento XML. Documentos XSDs aceitam dados de diferentes tipos, como números, data e moeda. XML Web Service – Blocos fundamentais para a criação do modelo de computação distribuída na internet. Um Web Service é uma porção de código localizada num servidor web e pode ser utilizada por uma aplicação qualquer. WSDL – Sigla de Web Service Description Language. A Linguagem WSDL define regras
  • 50. baseadas em XML para descrever os Web Services. A WSDL é padroniza da pelo órgão gestor W3C.