2 projetando interaÇÕes

Upload: fernando383

Post on 30-Oct-2015

71 views

Category:

Documents


0 download

TRANSCRIPT

  • 2 PROJETANDO INTERAES

    Este captulo apresenta as definies sobre o projeto de interao com o usurio (PIU), o que e para que servem os

    processos de interao e as atividades do projeto de interao. Apresenta ainda as questes prticas do PIU que inclui necessidades e

    requisitos, projetos alternativos, verses interativas, avaliao e as diversa condies envolvidas no processo de documentao dos

    artefatos nas etapa de desenvolvimento do projeto de interao com o usurio. So tratadas ainda consideraes emergenciais para o

    projeto de interao e modelos de ciclo de vida na rea de IHC e uma forma de projetar a interao por meio da engenharia semitica.

    1. Contextualizao

    comum encontrar o termo Design de Interao, mas prefiro no entrar em detalhes sobre o significado de termo

    Design[1] e utilizar uma traduo mais objetiva para o termo: Projeto. Sendo assim, quando falarmos de Projeto de Interao

    estaremos falando de Design de Interao.

    Na interao homem computador os processos que caracterizam dilogos so formados por aes empregadas por uma

    entidade comunicativa na qualidade de usurio ou computador. O objetivo provocar uma troca de informaes: respostas s reaes

    geradas por estmulo. A isto se denomina interao. Dentro deste escopo, garantir um processo efetivo e com sucesso para o

    dilogo passa pelo Projeto de Interao com o Usurio, o PIU.

    O que e de onde vem o projeto de interao?

    Segundo Saffer (2007) esta disciplina proveniente de razes do design industrial, fatores humanos, interao homem

    computador, experincia do usurio dentre outras reas que ainda ajudam a definir os limites desta nova disciplina. Mas independente

    de suas razes o projeto de interao possui um carter essencialmente comportamental. Este comportamento est associado com

    algo praticamente intangvel e invisvel, algo difcil de ser definido como ideal. Diferente da aparncia, por exemplo, que pode causar

    reaes imediatas. O comportamento est associado a reao onde, por exemplo, dois produtos diferentes que fazem a mesma coisa

    causam impactos diferentes no uso, mas isso s pode ser reconhecido somente depois da experincia de manipulao ou uso.

    Qual o objetivo do projeto de interao?

    De forma simples tornar simples a vida de quem usa alguma coisa. definir processos para comunicao e interao

    humana com os artefatos ou produtos interativos, o que inclui decises sobre detalhes dos procedimentos da comunicao de ordem

    lgica ou fsica e comportamental. Mas ainda se discute sobre os objetivos desta disciplina. Dentro deste escopo so definidos os

    processos de um produto interativo que fornecem suporte s atividades cotidianas das pessoas, seja no lar, no trabalho ou no

    entretenimento. Os produtos mais associados ao projeto de interao, no entanto, so produtos tecnolgicos como softwares e

    equipamentos que favoream a utilizao de um sistema lgico.

    O que se pode projetar com interao?

    O projeto de interao oferece a um determinado produto todo um sistema de uso para usas funcionalidades. Em resumo o

    projeto de interao se aplica a QUALQUER COISA USVEL! Mais especificamente, possvel projetar uma variedade de

    equipamentos e produtos que permitam a troca de informaes entre as partes.

    Para entender melhor o objeto do projeto de interao preciso entender que podem ser utilizadas uma srie de elementos

    nas interaes que oferecem sada e entrada de dados para a gerao de estmulos permitindo, assim, um dilogo fluido. Sadas e

    entradas de dados acontecem por meio de INTERFACES que so compostas por artefatos como grficos, sons, superfcies que

    estimulam o tato, sinestesia[1], cheiros (Figura 5), os prprios equipamentos que recebem respostas do ambiente ou de

    humanos, entre outros.

  • Figura 5 - Interfaces em realidade virtual, com estmulo sinestsico e olfativo, apresentadas no Laval Virtual em 2004 na Frana. O sistema

    sinestsico oferece manipulao de objetos virtuais com retorno fsico que permite identificar dimenses e peso dos objetos virtuais. O estmulo

    olfativo do jogo Fragra (Visual-Olfactory VR Game) permite explorar relaes interativas entre viso e olfato. um jogo de erro e acerto onde

    os cheiros podem no corresponder a fruta fazendo o jogador dizer qual o cheiro da vez. O sistema pede que uma fruta seja selecionada utilizando

    a luva com sensores, levando-a prximo ao nariz o usurios revelado em voz alta o nome da fruta correspondente ao cheiro que exalado pela

    luva. Ao pronunciar o nome da fruta o usurio pode acertar ou errar. O terceiro equipamento um Phantom, dispositivo que permite usar a fora

    para esculpir objetos virtuais.

    Os estmulos computacionais esto associado s entradas dos dados que podem acontecer via voz (ou sons), via apontadores

    sensveis movimentao e controlados por dispositivos variados (mouse, olho, caneta, etc) aes de seleo (clique por exemplo) em

    formato mecnico (mouse) ou manual (touch screen), dentre outros que envolvem tecnologias ainda em pesquisa como o

    aproveitamento de impulsos neurais.

    No importa a quantidade de elementos de interface de entrada ou sada utilizados embora quanto maior o nmero de

    elementos mais complicado e complexo pode ser o processo de interao. O importante projetar os processos de troca de informao

    com o usurio de forma a usvel. A facilidade de uso a base do princpio de usabilidade. Mas s a base. Ser agradvel

    tambm algo que determinar a satisfao do usurio.

    Esta condio bsica nos leva a entender o termo USABILIDADE. Os vrios conceitos da usabilidade, no entanto, esto

    associados a diversos fragmentos que permitem a condio de COISA USVEL. Estes conceitos sero vistos mais a frente em

    forma de metas e princpios de um projeto de interao.

    Nos concentraremos agora em entender melhor o que o projeto de interao, quais so seus processo e as questes prticas

    do projeto de interao, para, ento, entender como acontece o ciclo de vida de desenvolvimento do projeto de interao.

    2. O que projeto de interao?

    O projeto de interao uma atividade prtica e criativa que tem por objetivo final o desenvolvimento de um produto que

    ajude os usurios a atingirem suas metas.

    Segundo Verplank (2003) o projeto de interao deve responder sobre como o usurio far alguma coisa, como ele se sente e

    como ele sabe fazer esta coisa. Verplank ilustra este cenrio descrevendo que at o mais simples dispositivo requer manipulao,

    conhecimento e sentimento como acontece com o apertar de um boto luminoso e ver (ou sentir) a luz acender. Mas, mas para isso

    preciso entender como funciona o mapeamento deste controle. Quanto mais afastados estiverem controles de entrada (boto) e sada

    (luz), mais complexo e demorado ser o modelo de compreenso do usurio sobre o fazer e sentir.

    Faz parte deste processo compreender aspectos relacionados interao em tarefas que do suporte s atividades

    cotidianas. O envolvimento do usurio no processo interativo por meio de mtodos centrado no usurio , tambm, de igual

    importncia. Outros modelos de projeto com outros centros tambm podem ser considerados, mas o usurio nosso cliente e como

    cliente, quase sempre tem razo. Para que tudo isso seja possvel importante iniciar bem, e para isso temos as conhecida tcnica

    de levantamento de necessidades e requisitos.

    MAS ser que os usurios sabem o querem?

    Bom, as estratgias para a criao de um projeto de interao envolvem procedimentos que ajudam a responder questes

    deste tipo. Mas, to importante quanto isso entender se existe uma forma eficiente de comunicar um projeto ao usurio e faz-lo

    integrar-se equipe de desenvolvimento transformando-o num colaborador durante o desenvolvimento do produto. Isso se aplica de

    forma diferente para produtos novos ou atualizao tecnolgica.

  • Um produto novo ou um novo modelo conceitual pode realmente ser visualizado e compreendido pelo usurio?

    O projeto de interao trata da construo de um conhecimento lgico apresentado e comunicado de formas diversas tanto

    equipe de desenvolvimento quanto ao usurio final. Solues triviais popularizadas so mais fceis de serem absorvidas e entendidas

    pelos usurios. O que talvez d mais trabalho so modelos conceituais inovadores que exigem mais esforo do usurio para aprender o

    processo de interao. O sucesso desses produtos inovadores depender de aspectos como necessidade de mercado, grau de desafio de

    uso e satisfao proporcionado ao usurio. Ah! Inclua nesta frmula estratgia de marketing. Voc tem acompanhado as crticas do

    iPhone da Apple?

    iPhone se comporta muita mais como um computador do que qualquer outro tipo de gadget com exceo do celular Pocket

    PC/Windows. Ele compete com o PPC, mas mantm a vista somente o que necessrio para se tornar uma dispositivo amigvel.

    Lembrando minha experincia com o PPC, quem na terra deveria ver DLL ou EXE no seu celular?! Resposta: ningum, com

    exceo dos desenvolvedores. A Apple entende o que a Microsoft no entende.

    A ausncia de teclado no a melhor coisa do iPhone, mas ao mesmo tempo, como voc poderia ter um dispositivo to

    pequeno que permitisse assistir filmes e que inclui um teclado Tivemos que ceder em algumas coisas. Brinquei um pouco com o

    teclado e achei mais ou menos. Ouvi falar que leva horas para deslig-lo. Gostei quando tive que escrever what the heck (que

    diabos) e ele pensou que eu escrevi what the jedi. Isso bom. Ficou contente que algum na Apple colocou Jedi no dicionrio do

    iPhone, pro caso de eu ter uma emergncia no SMS durante uma conversa sobre Star Wars.Talvez o pessoal da Apple saiba mais

    sobre meus dados demogrficos do que eu mesmo.

    Trimb. Disponvel na URL: http://trimbo.blogspot.com/2007/06/apple-critic-iphone-review.html

    3. Processos do projeto de interao

    Projetar a interao to importante quanto realizar os casos de uso, os diagramas de seqncia e todos os outros elementos

    relacionados documentao tradicional de sistema. O PIU, Projeto de Interao com o Usurio, envolve uma srie de processos

    e instrumentos relacionados a forma como o usurio ir se comportar quando estiver utilizando o sistema . Por isso envolve

    uma srie de artefatos e procedimentos.

    No existe um processo ou modelo mais correto, existem, sim, aqueles mais adequados levando-se em conta os fatores

    decisivos para o desenvolvimento do produto, tais como dimenso do projeto, cronograma, oramento, equipe, etc.

    O projeto de interao, no entanto, no visto como uma tcnica isolada e diferente dos processos conhecidos na engenharia

    de software e outras reas comuns.

    Uma forma de estabelecer uma relao detalhada do processo de interao descrever o processo rico em detalhes com

    descrio de objetivo, ao, resultado e detalhes (Quadro 1). Os resultados levam ao desenvolvimento de prottipos de telas

    (wireframes ou templates) que esclarecem o procedimento passo a passo de forma visual, minimizando as barreiras que possam gerar

    dvidas aos desenvolvedores e aos usurios.

    Quadro 1 Exemplo simplificado que detalha a atividade de fechar um programa

    Objetivo Ao esperada Resultado Detalhes

    Fechar o programa Localizar elemento visual e levar

    o cursor do mouse at o smbolo,

    boto, rtulo e clicar.

    Se houver arquivo aberto com alteraes a

    serem salvas oferecer mensagem

    permitindo a ao de salvar ou fechar sem

    salvar.

    Deve existir mensagem

    especfica para quando houver

    mais de um arquivo aberto.

    Uma soluo agregada ao UML

    Conhecida e utilizada por profissionais da rea de computao, a Unified Modeling Language (UML) baseada num processo

    unificado de desenvolvimento de software oferece condies de detalhamento das atividades de interao de um sistema. O problema

    que, quando utilizada para a documentao de projeto, dificilmente entra em detalhes to importantes da interao.

    Como o prprio modelo evidencia, no se observa a natureza iterativa e incremental do processo de desenvolvimento para

    manuteno e ajustes de problemas. Alm disso no oferece destaque para a interface com o usurio. Diante disto Hudson (2000)

  • prope uma extenso do processo unificado que incorpora as 10 tcnicas mais populares em projeto de interfaces (Figura 6). O

    objetivo centrar o processo ainda mais no usurio para obter sistemas mais usveis.

    Figura 6 - Processo UML alterado para suportar as atividades do projeto de interao. Em vermelho as etapas inseridas que

    auxiliam no projeto de interao. (Hudson, 2000)

    Na Figura 6, em vermelho, observam-se os pontos em que este processo sofreu alteraes destacando a adio das atividades de:

    Identificao e desenvolvimento de cenrios de uso: Tcnicas relevantes: cenrios de uso (com base em dados colhidos em

    observaes de potenciais usurios na realizao de trabalho, por exemplo) e avaliao de sistemas existentes.

    Anlise de contexto: Tcnicas relevantes: anlise de usurio/identificao de perfis, identificao de tarefas e

    estabelecimento de requisitos de usabilidade.

    Projeto da interface: Tcnicas relevantes: projeto de navegao, projeto visual da interface e prottipos de baixa fidelidade.

    Avaliao de usabilidade: Tcnicas relevantes: avaliao de usabilidade por especialistas e teste informal de usabilidade.

    4. Atividades do projeto de interao

    De forma geral podem ser observadas quatro atividades bsicas que definem o processo do projeto de interao (Preece et

    al, 2005):

    1. IDENTIFICAR NECESSIDADES E ESTABELECER REQUISITOS: Trata-se da base dos requisitos do produto. Esta

    atividade sustenta o design e o desenvolvimento. O objetivo desta etapa conhecer o usurio alvo e o tipo de suporte til que o

    produto deve oferecer. Para isso fundamental iniciar uma abordagem centrada no usurio.

    2. DESENVOLVER PROJETOS ALTERNATIVOS QUE VO DE ENCONTRO AOS REQUISITOS: Atividade central

    do projeto de interao. quando surgem as idias que devem atender aos requisitos, as quais devem ser geradas com base em

    algum tipo de suporte. So as sub-atividades da gerao de idias. O projeto conceitual ou o modelo conceitual do produto ganha

    forma juntamente com a descrio sobre o que o produto far, como se comportar e parecer. O projeto fsico pode, ento, ser

  • iniciado com detalhes de interao e de interfaces, o que pode incluir o estudo de cores, sons, imagens, menus, animaes, cones,

    etc.

    3. CONSTRUIR VERSES INTERATIVAS DE MANEIRA QUE POSSAM SER COMUNICADAS E ANALISADAS:

    Fornecer meios de simular o processo de interao. Afinal, como os usurios sabero e verificaro se as necessidades esto sendo

    atendidas? As verses prototipadas so os meios mais conhecidos para mostrar ao usurio como um produto est sendo modelado

    e verificar a primeira reao de aceite. Mas isso no significa que deva ser uma verso funcional. Prottipos em papel podem ser

    desenvolvidos e aplicados com rapidez, so baratos e eficazes na busca de problemas nas primeiras fases do projeto. O usurio tem

    uma noo real de como ser a interao.

    4. AVALIAR O QUE EST SENDO CONSTRUDO E MEDIR SUA ACEITABILIDADE: So formas de determinar a

    usabilidade e aceitabilidade do produto utilizando vrios critrios, tais como nmero de erros cometidos pelo usurio, atratividade,

    preenchimento dos requisitos, etc. No substitui testes de qualidade que certificam o produto final. Mas ajudam a verificar se todo

    ou parte do produto encontra-se em condio de uso.

    Estas 4 atividades (Figura 7), que ainda veremos com mais detalhes, podem se repetir em etapas diferentes do

    desenvolvimento do projeto. Prototipagem, por exemplo, pode acontecer tanto na fase inicial de documentao como no decorrer da

    programao. A exemplo do UML proposto para o projeto de interao, pode-se identificar que as atividades de interao precisam

    ser reconsideradas em diferentes etapas do processo. Mas a etapa crtica, a que precisa de muita ateno, o levantamento ou

    elicitao de requisitos.

    Figura 7 - Atividades bsicas do PIU

    Independente do momento do projeto devem ser consideradas algumas caractersticas-chave no PIU: usurios envolvidos no

    desenvolvimento do projeto, identificao ou especificao de metas de usabilidade no incio do projeto e complementao e

    iterao (repetio) nas atividades bsicas com nfase nos processos de avaliao. Considere, portanto:

    1. Foco no usurio: Se no for possvel garantir seu envolvimento considere o desenvolvimento de solues voltadas para o

    usurio e contexto de uso especfico. Em outras palavras, projetar e avaliar pensando como o usurio, focar nas tarefas como se

    estivessem sendo realizadas para o usurio e dar ateno aos processos e mensagens de retorno.

    2. Critrios especficos de usabilidade: Os objetivos especficos devem ser claramente documentados, pois isso ajuda na

    idealizao de diferentes alternativas de projeto. Desta forma fica mais fcil identificar metas de usabilidade e, posteriormente,

    verificar o atendimento dos princpios de usabilidade.

    3. Iterao: Significa repetio, que neste caso, se refere aos processos de testes e avaliaes para o refinamento do projeto,

    ainda com base no retorno do usurio.

    O envolvimento do projetista e do usurio ajuda a definir uma srie de critrios para o desenvolvimento do projeto (domnio,

    requisitos, necessidades, desejos, aspiraes e muitos outros direcionadores). Este processo conduz ao entendimento da necessidade

    da interao, muito importante quando se trata de um produto inovador onde as idias precisam ser revisadas luz do retorno do

    usurio.

    _____________________

    ALGUMAS QUESTES PRTICAS DO PIU

    possvel encontrar diferentes listas de atividades para o processo de interao. Tambm fcil encontrar uma srie de propostas e

    modelos de como atuar em cada fase ou etapa proposta para o projeto. Mas em linhas gerais devemos entender que o projeto de

    interao com o usurio baseado em duas abordagem:

    1. FERRAMENTAS DE NEGOCIAO: elas propiciam a comunicao de idias por meio de reunies, discusso em

    grupos, servios de fruns, entrevistas participativas. O importante desta abordagem gerar resultados de forma

    documentada.

  • 2. PRODUO DE ARTEFATOS: so passos mais objetivos para o desenvolvimento do projeto de interao que inclui

    atividades de:

    Conceitualizao: produzido com o auxlio das primeiras atividade de levantamento de requisitos e resulta na produo

    de:

    o mapa mental dos conceitos para o usurio;

    o lista dos aspectos de requisitos eleitos como importantes de forma a adequ-los curva de aprendizado do usurio;

    e

    o definio dos contextos de uso para condies culturais, sociais, simblicas e tecnolgicas;

    o Estruturao: Diagrama de interao social, fluxograma de interao, wireframes, prottipos de baixa fidelidade;

    o Apresentao: Detalhes estticos, definio de aspectos visuais como a identidade visual do produto, leiaute e

    prottipos de alta fidelidade.

    Perceba a conexo entre as atividades da produo de artefatos e 3 das 4 atividades que estabelecem o processo do projeto de

    interao:

    CONCEITUALIZAO: Est associada ao levantamento de requisitos

    ESTRUTURAO: Est associada aos projetos alternativos. Embora possa gerar discusses interminveis, oferecer mais

    de uma soluo de interface, quando o cronograma permite, permite visualizar tarefas, elementos de interface e processos

    de diferentes pontos de vista.

    APRESENTAO: So as verses interativas que permitem iniciar avaliao mais detalhadas.

    _____________________

    (1) Necessidades e requisitos

    Para entender as questes prticas envolvidas no projeto de interao no precisa ir muito longe. Estas atividades tambm

    acontecem em outras reas. Por exemplo, na arquitetura necessrio conhecer o cliente, futuro utilizador do espao construdo.

    Para isso necessrio definir uma lista de necessidades (o que o cliente quer, quantos filhos tem, se gosta de receber visitas, parentes

    para ficar por mais tempo, etc) alm de viabilidades legais que ajudaro, por exemplo, a identificar o zoneamento possvel

    (organizao dos espaos para alocao da edificao no terreno), dando incio ao partido do projeto (primeiro prottipo visual dos

    espaos a serem edificados) e prosseguindo com os detalhamentos do projeto. As atividades iniciais esto baseadas no estudo e

    envolvimento do usurio e legislao. Em projetos urbanos, por exemplo, estes usurios so em maior nmero e to diversificado

    quanto na utilizao de sistemas computacionais, e por isso devem ser consideradas questes sociais e costumes e rotinas da

    populao para o projeto de espaos urbanos. Tudo isso s possvel com a realizao de etapas de entrevistas envolvendo, dentro das

    possibilidades, aqueles que faro uso do espao.

    Na engenharia de produto so feitas pesquisas de satisfao com relao a produtos no mercado. Clientes potenciais

    tambm so chamados para oferecer sugestes sobre novos propostas de produtos. Os profissionais envolvidos so de reas como

    design grfico, arquitetura, urbanismo, engenharias (industriais de produo, de software) entre muitos outras.

    Cada disciplina apresenta sua prpria interpretao e processos para desenvolvimento do projeto. Mas podemos entender a

    tarefa de projetar a interao como sendo um (1) plano ou esquema concebido na mente de alguns, (2) idealizado por uma equipe

    de profissionais especializados que desenvolvem artefatos que permitam a (3) execuo prtica do produto.

    De qualquer forma, no importa a rea. Cada uma delas trata, do seu jeito, questes similares, tais como:

    conhecimento sobre o uso e domnio-alvo do produto;

    investigao sobre o uso de artefatos;

    entender as restries prticas quanto ao material, custo e viabilidade; e

    soluo do problema antes da execuo levando em conta os usurios.

    Diante de uma srie de consideraes importante notar, ainda, possveis compensaes em que devem ser pesadas a

    habilidade do usurio e o equilbrio de necessidades conflitantes.

    As necessidades e requisitos para o projeto de interao no so diferentes daqueles conhecidos pelo analista de sistema

    definidos para realizar o documento tcnico de sistemas computacionais. Mas no projeto de interao comum encontrar o usurio

  • como foco de qualquer atividade. Embora outros[1] modelos de centros de projeto possam ser encontrados na literatura, o

    centro no usurio o mais explorado. Os processos mais comuns para o desenvolvimento de projeto so baseados no USURIO,

    na ATIVIDADE e na AO.

    Esta atividade deve ser realizada em parceira direta com usurios e clientes. As atividades definidas por processos como

    RUP (Rational Unified Process) e UML (Unified Model Language) so os procedimentos conhecidos e comumente adotados. Eles

    oferecem muitos recursos para a tarefa de documentao das necessidades e estabelecimento dos requisitos.

    Qual a diferena entre Necessidade e Requisito? Primeiro, requisito um derivado de necessidade. Veja o exemplo para as

    diferenas para um produto do tipo telefone:

    Engenharia de requisitos

    A engenharia de requisitos um processo criterioso de identificao do que deve ou pode ser desenvolvido e das tecnologias e

    insumos envolvidos. objetivo da engenharia de requisitos evitar problemas de desenvolvimento de sistemas que levem ao no

    atendimento das expectativas do usurio. Para isso necessrio realizar uma exaustiva e criteriosa fase de definio de requisito. Os

    nveis de abstrao dos requisitos so (Figura 8):

    de negcios (objetivos do usurio): documento de escopo ou de viso;

    de usurios (descreve as atividades que os usurios devero desempenhar); e

    funcionais (o que o sistema deve possuir para que os usurios possam executar suas atividades para alcanar os objetivos de

    negcio).

    Figura 8 - Nveis de abstrao dos requisitos

    Outros requisitos necessrios sugeridos por Blaschek (2002):

    requisitos no funcionais (padres e regulamentos com os quais o sistema precisa ter conformidades, como por exemplo,

    descrio de interfaces externas e requisitos de desempenho);

    restries (limites de recursos e infra estrutura); e

    atributos de qualidade de software (ISO 9126).

    A maioria dos processos de Engenharia de Requisitos pode ser descrita por meio de um macro-modelo de atividades (Figura

    9) composto de atividades como elicitao, anlise e negociao, documentao, validao e gerncia de requisitos, conforme

    mostrado na Figura 9. Mas muitas outras atividades podem ser encontradas na literatura com o objetivo de identificar requisitos.

  • Ribeiro (sem data) realizou uma pesquisa onde apresenta uma lista de processos sugeridas por quatro diferentes autores. Algumas das

    atividades encontradas so repetidas, a exemplo dos requisitos apresentados por Blaschek (2002), que determinam apenas quatro

    etapas incluindo elicitar os requisitos, analis-los, gerar a documentao e a realizar a validao. As outras atividades so:

    Anlise de domnio (considerada apenas por 1 autor)

    Elicitao de requisitos (considerada por 4 autores)

    Modelagem (considerada por 1 autor)

    Anlise de requisitos (considerada por 3 autores)

    Negociao (considerada por 2 autores)

    Documentao (considerada por 1 autor)

    Especificao de requisitos (considerada por 2 autores)

    Anlise da Especificao (considerada por 1 autor)

    Verificao (considerada por 1 autor)

    Comunicao (considerada por 1 autor)

    Concordncia (considerada 2 autores)

    Validao (considerada por 1 autor)

    Documentao do processo, das decises e das fontes dos requisitos (considerada por 1 autor)

    Gerncia de requisitos (considerada 2 autores)

    Evoluo de requisitos (considerada 2 autores)

    Macro-modelo de atividades do processo de engenharia de requisitos

    Como no existe um processo nico que contemple todas estas fases tambm no existem limites definidos entre as

    atividades. Mas cada uma delas pode ser utilizada na prtica com interpolaes entre elas. A idia que o processo seja realizado

    at que o grau de satisfao de todos os usurios seja alcanado ou at que a presso do cronograma precipite o incio da fase

    de projeto do software (indesejvel). As atividades mais importantes, no entanto elicitao, anlise de requisitos, documentao,

    validao e gerncia de requisitos - so aquelas destacadas em negrito e sero discutidas a seguir com mais detalhes.

  • 40% a 60% de todos os problemas encontrados em um projeto de software so causados por falhas na fase de levantamento de

    requisitos (Leffingell, 1997).

    Perguntar s pessoas o que elas precisam, pode no ser suficiente. Muitas vezes elas no sabem necessariamente o que possvel e,

    at mesmo, o que realmente querem. necessrio, portanto, chegar no usurio compreendendo:

    suas caractersticas *;

    suas capacidades *;

    o que esto tentando alcanar;

    como fazem isso atualmente; e

    questionar se elas atingiro o objetivo com mais eficincia com outro tipo de suporte.

    * As caractersticas e capacidades podem variar e, neste caso, temos os grupos de usurios por perfil.

    Exemplo que influencia nas decises e que nem sempre so pensadas para os usurios tpico:

    tamanho das mos podem afetar no tamanho e posio dos botes;

    capacidades motoras podem afetar a adequao de certos dispositivos de entrada e sada;

    o uso da fora deve ser considerada em um equipamentos para crianas (tipo de usurio criana/adulto tempo de vida do

    equipamento); e

    nervosismo, questes culturais, outros.

    Antes de continuar reforcemos o entendimento sobre Engenharia de Requisito e Elicitao de Requisito.

    Engenharia de Requisito: Macromodelo composto de uma srie de atividades para tratamento de requisitos.

    Elicitao de Requisito: Uma das atividades da Engenharia de Requisitos.

    Elicitao de Requisitos

    Elicitar requisitos a tarefa de descobrir, identificar, deduzir, extrair, evocar ou obter dados que contribuam com uma

    anlise de qualidade (Blaschek, 2002).

    importante ter boa redao, declarao de viso e escopo do sistema.

    Usurios, clientes e especialistas de domnio so identificados e trabalham junto com os engenheiros de requisitos para

    descobrir, articular e entender a organizao como um todo. So consideradas atividades para entender o domnio da aplicao, os

    processos de negcio especficos, as necessidades que o software deve atender, os problemas e deficincias dos softwares atuais, os

    diferentes pontos de vista dos participantes do processo, bem como as oportunidades e restries existentes, os problemas a serem

    resolvidos, os servios e o desempenho requeridos, as restries de hardware, dentre outros.

    A atividade no se resume a perguntar s pessoas o que desejam. Tambm no uma simples transferncia de

    conhecimento. Existem vrias tcnicas de elicitao, sendo que a escolha depende do tempo e dos recursos disponveis alm do tipo

    de informao que necessita ser elicitada. As tcnicas de elicitao de requisitos podem ser classificadas em (Batista, 2003):

    tcnicas tradicionais: englobam tcnicas genricas, tais como o uso de questionrios e pesquisas, investigao de

    documentos e entrevistas;

    tcnicas de elicitao em grupo: exploram as dinmicas de grupo, tais como tcnicas de grupos focados focus groups,

    workshops RAD Rapid Application Development e JAD Joint Application Development;

    prototipao: tem sido usada quando existe incerteza sobre os requisitos ou quando se torna necessrio ter um retorno inicial

    dos usurios, podendo ser combinada com outras tcnicas;

    tcnicas dirigidas a modelos: fornece um modelo especfico para o tipo de informao a ser obtido e conduz o processo de

    elicitao englobando os mtodos baseados em objetivos e mtodos baseados em cenrios;

    tcnicas cognitivas: incluem tcnicas desenvolvidas originalmente para aquisio de conhecimento em sistemas baseados

    em conhecimento. Dentre elas, pode-se citar anlise de protocolo e classificao de cartes (card sorting).

    tcnicas contextuais: surgiram nos anos 90 como uma alternativa s tcnicas tradicionais e cognitivas e incluem o uso de

    tcnicas de etnografia, tais como observao dos participantes e anlise de conversao.

  • A escolha da tcnica depender do foco que se quer dar ao processo. As abordagens tradicionais e cognitivas baseiam-se no

    uso de modelos abstratos independentes do contexto. Por outro lado as abordagens contextuais levam o contexto local como premissa

    bsica para o entendimento do comportamento organizacional e social. Embora exista incompatibilidade entre estes formatos as

    abordagens podem ser complementares.

    As tcnicas mais prticas baseiam-se em entrevistas, brasinstorms, prototipao, JAD e mtodo JK.

    1. Entrevistas: Dificilmente deixam de ser utilizadas, pois trata-se da forma mais natural de comunicao entre as pessoas. Mas

    embora paream simples elas exigem procedimentos mais especficos do que apenas perguntar. A tcnica se torna mais eficaz quando

    estruturada e quando a equipe passa a dominar o processo. Ajuda descobrir como o processo atual acontece e entender quais so as

    expectativas para o novo processo ou sistema. As perguntas podem ser feitas por um ou mais entrevistadores e podem ser divididas

    em 3 tipos:

    estruturadas segue uma estrutura rgida e seqencial.

    semi estruturadas utiliza uma lista estruturada mas permite a ocorrncias de questes extra ou so anotadas observaes

    extra mencionadas pelo entrevista.

    no estruturadas parte de um ponto estabelecido (ou no) e anda de acordo com a motivao do entrevistado.

    2. Brainstorm: bastante utilizada e conhecida, mas no envolve, necessariamente, o usurio. Ela serve para gerar idias a partir de

    discusses realizadas por um conjunto de especialistas onde todos colaboram com as idias de todos, com a liberdade que s a

    criatividade pode fornecer. Neste processo so feitas crticas e julgamentos. Esta tcnica pode ser aplicada no incio da fase do

    desenvolvimento quando pouco do projeto conhecido e so necessrias idias novas. Os resultados de uma sesso bem estabelecida

    contribuem com boas solues para todas as questes exploradas.

    3. Prototipao: Este processo utilizado para detalhar requisitos de software definidos pelo cliente. Este tcnica pode ser utilizada

    para avaliao ou verificao dos possveis procedimentos de interao entre o homem e a mquina. O modelo permite ainda refinar

    os requisitos identificados na fase de concepo, sejam eles funcionais ou no.

    4. Joint Application Design JAD: Desenvolvida pela IBM no fim dos anos 70 esta tcnica tem base na criao de sesses de

    trabalho estruturadas utilizando dinmica de grupo e recursos visuais. Participam analistas e usurios para, juntos, projetarem um

    sistema com a compreenso adequada dos requisitos bsicos e podendo chegar, inclusive, no desenvolvimento de leiaute de telas e

    relatrios. A idia manter a cooperao e o entendimento entre os participantes. O papel dos desenvolvedores ajudar os usurios a

    formular problemas e explor-los com o objetivo de indicar possveis solues. Os usurios se sentem parte integrante da equipe de

    desenvolvimento. O JAD baseado em quatro princpios bsicos:

    dinmica de grupo com tcnicas que possam aumentar a capacidade dos indivduos;

    uso de tcnicas audiovisuais para aumentar a comunicao e o entendimento;

    manuteno do processo organizado e racional; e

    utilizao de documentao-padro, que preenchida e assinada por todos os participantes.

    A tcnica JAD tem duas grandes etapas: PLANEJAMENTO, cujo objetivo elicitar e especificar requisitos; e PROJETO,

    em que se lida com o projeto do software. Os participantes de uma sesso de JAD desempenham seis diferentes papis:

    lder da sesso;

    representantes do usurio;

    especialista;

    analista;

    representantes dos sistemas de informao; e

    patrocinador executivo.

  • A tcnica ajuda a identificar os assuntos que podem necessitar de rastreamento e fornece uma perspectiva multifacetada dos

    requisitos. Sesses JAD permitem aos analistas coletar simultnea e eficientemente uma grande quantidade de requisitos do sistema

    junto a uma gama de usurios-chave. So teis por considerar necessidades especficas dos usurios.

    O JAD tambm pode ser usado em conjunto com outra tcnica de elicitao como, por exemplo, a prototipao. medida

    que os requisitos so obtidos nas sesses pode-se construir prottipos que demonstrem alguma funcionalidade destes requisitos.

    5. Mtodo KJ (Kawakita Jiro)

    uma atividade que ajuda a realizar uma lista de requisitos por investigao contextual ou de afinidades onde a observao

    dos envolvidos ajuda a estabelecer e reunir prioridades para se chegar em um consenso de grupo. O mtodo KJ foi desenvolvido pelo

    japons Kawakita Jiro que buscava reduzir o tempo da realizao da tarefa de elicitao de requisitos. Para elaborar o processo deve-

    se ter o foco claro em cada uma das rodada que estabelece o processo que se utiliza de uma pergunta. Os principais focos para o

    levantamento de necessidades costumam ser:

    quem o seu pblico-alvo;

    quais tarefas ele deve estar apto a realizar ao final do programa de formao;

    o que este pblico j sabe;

    em quanto tempo estas pessoas devem formar o conhecimento; e

    quais sos os recursos disponveis para realizar este programa.

    Uma equipe experiente consegue realizar duas rodadas por hora da dinmica. Isso significa que em at 3 horas seria possvel

    realizar a anlise. um processo de anlise de necessidades com consenso em tempo recorde. Veja um exemplo do processo em

    Iderios.com (Lopez, 2006) para a elaborao de um programa de formao com KJ-Method.

    Anlise e negociao de requisitos

    onde os requisitos elicitados so compreendidos e detalhadamente analisados por todos os interessados no sistema

    (Blaschek, 2002). Esta atividade auxilia na descoberta de problemas nos requisitos levantados e na obteno de concordncia sobre as

    alteraes. Como resultado a satisfao de todos os envolvidos deve ser atingida. Se na etapa anterior houve uma elicitao dos

    requisitos mais importante, nesta fase necessrio estabelecer um conjunto acordado de requisitos completos, consistentes e sem

    ambigidades, que possa ser usado como base para o desenvolvimento do software.

    Como resultado deve ser gerado um documento rascunho que ser levado aos engenheiros e arquitetos de informao. Eles

    manipularo os requisitos de forma que possam agrup-los de acordo com regras estabelecidas (funcionalidade, por exemplo), faro

    exploraes e classificaes que estabelecero prioridades. Assim os requisitos so examinados em relao sua necessidade,

    completeza, consistncia, riscos, viabilidade tcnica, operacional e econmica, bem como em busca de omisses, ambigidades,

    sobreposies e conflitos.

    Problemas e conflitos encontrados nos requisitos so ressaltados. Todos os indivduos (stakeholders) classificam os

    requisitos com problemas e negociam at chegarem a um acordo sobre as modificaes a serem feitas. Esta atividade pode ser

    direcionada por necessidades pr-estabelecidas, por requisitos especficos para os diferentes usurios, por restries de projeto e de

    implementao e pelo oramento e cronograma disponveis.

    Documentao de Requisitos

    Requisitos compreendidos, analisados e aceitos. Agora s documentar. A proposta de integrao do processo associado ao

    projeto de interao ao UML ajuda a identificar o momento em que o projeto de interao deve ser realizado (Blaschek, 2002). a

    representao dos resultados obtidos at agora, em um documento oficial e formal que contm os requisitos do software com

    descries detalhadas sobre o que ele far, mas ainda sem descrever como fazer o software em termos de tecnologia ou linguagem de

    programao a ser adotada, por exemplo. Esse documento deve estar correto, sem ambigidades, completo, consistente, classificado

    por importncia e/ou estabilidade dos requisitos, verificvel, modificvel e rastrevel, alm de ser entendvel pelos usurios,

    organizado e conciso. No h um nome padro para esse documento, podendo ser adotado, dentre outros, Especificao de

    Requisitos de Software (ERS), Documento de Requisitos ou Especificao Funcional.

  • Este documento descreve:

    o escopo e os objetivos do software;

    os servios e as funes que o software deve fornecer;

    as informaes sobre o domnio de aplicao do software;

    as restries sob as quais o software deve operar;

    as propriedades gerais do software, tais como atributos de qualidade e desempenho;

    as definies de outros softwares com os quais deve interagir; e

    as restries ao processo de desenvolvimento adotado.

    Uma informaes importante neste documento indicar a fonte dos requisitos, seja uma pessoa, um grupo ou documento.

    Outras informaes importantes so os problemas que se pretende resolver, alm das razes e justificativas da escolha de cada soluo

    ou deciso tomada, as demais alternativas consideradas, os fatores avaliados e as argumentaes que guiaram cada deciso ou

    soluo. Estes dados adicionais enriquecem a viso do software.

    O documento pode ser descrito em linguagem natural, em notaes e linguagens semi-formais ou formais. Combinaes

    tambm so possveis.

    A linguagem natural facilita a comunicao, pois expressiva e flexvel, mas pobre para capturar as semnticas do

    modelo, possibilita ambigidades. Permite um fcil entendimento pelos usurios, mas a ausncia de semntica possibilita a

    livre interpretao.

    Uma notao semi-formal reflete a estrutura e utiliza semntica com alguma verificao de consistncia o caso da UML

    (Unified Modeling Language) com diagramas e relacionamentos.

    Os mtodos formais descrevem artefatos de software de forma difcil de compreenso e, por isso, requerem maior tempo de

    aprendizado, pois no so legveis para usurios no tcnicos.

    No existe um limite claro entre a engenharia de requisitos e o incio da fase de projeto do software dando margem ao

    dilema o que versus como. Os requisitos so obtidos na engenharia de requisitos (o que) ao passo em que so organizados,

    agrupados e documentados na hierarquia proposta para o projeto de arquitetura (como), de forma a organizar uma estrutura de sub-

    sistemas para o projeto.

    Algumas diretrizes propostas ajudam a melhorar a estrutura e organizao do documento:

    definir uma estrutura padro para o documento, contendo, em geral, uma parte comum, mas permitindo algumas variantes e

    sees opcionais;

    explicar como cada classe de leitores deve usar o documento;

    incluir um sumrio de requisitos;

    incluir uma seo explicando por que o software necessrio e como ir contribuir para os objetivos gerais de negcio da

    organizao;

    definir termos especializados em um glossrio;

    organizar o leiaute do documento para facilitar a leitura;

    auxiliar os leitores a encontrar a informao, incluindo recursos tais como listas de contedo e ndices e organizando os

    requisitos em captulos, sees e sub-sees identificadas; e

    tornar o documento fcil de alterar.

    Validao de Requisitos

    Depois de documentados os requisitos devem ser validados quanto consistncia e completude. Fase ideal para a correo

    de erros antes do desenvolvimento (Blaschek, 2002). Validar significa avaliar o software durante ou ao final do processo de

    desenvolvimento. O objetivo verificar se o resultado satisfaz o usurio, se foram solucionadas todas as demandas e se existem

    falhas. A validao se cumpre quando os requisitos e modelos documentados atendem s reais necessidades e requisitos dos usurios.

    A meta garantir que este documento possa ser aprovado antes de ser usado como base para o desenvolvimento do software.

  • A verificao ou validao executada por clientes, usurios, especialistas de domnio, engenheiros de requisitos, gerentes

    do projeto, projetistas do software e pelos gerentes de testes. Processos como o modelo CMM Capability Maturity Model e o padro

    ISO/IEC TR 15504 podem ajudar na verificao e a validao contribuindo inclusive com a garantia de qualidade do software.

    Vrias tcnicas complementares de verificao e validao dos requisitos tm sido propostas, tais como anlise dos requisitos,

    reviso tcnica formal, anlise de rastreabilidade, prototipao, validao, ou no, de modelos automtica, inspeo, testes de

    requisitos e planejamento inicial do teste do software.

    Apesar das atividades de anlise de requisitos e validao de requisitos serem abordadas em separado, elas tm muito em

    comum, pois envolvem julgar se as necessidades dos usurios esto descritas de forma apropriada e se esto sendo verificados os

    problemas nos requisitos. Ambas podem ser executadas em paralelo, mas existem diferenas importantes entre elas. A anlise de

    requisitos preocupa-se em investigar os requisitos elicitados junto aos usurios e ainda no discutidos com eles, que muitas vezes

    esto incompletos e expressos de forma no estruturada e informal. A validao de requisitos deve ter, idealmente, um conjunto

    completo e acordado de requisitos como ponto de partida.

    Na Engenharia de Requisitos, a validao leva a uma reviso e aprovao da documentao por todos os envolvidos no

    processo, que se torna um contrato de desenvolvimento de software. Mudanas de requisitos solicitadas depois que a documentao

    estiver aprovada podero ser consideradas. No entanto, o cliente deve estar ciente de que cada mudana posterior pode ser uma

    extenso do escopo do software e, por conseguinte, pode aumentar o custo e/ou alongar o prazo de entrega.

    Gerncia de Requisitos

    Frequentemente usurios e especialistas propem mudanas nos requisitos, resultantes de fatores como a descoberta de erros,

    omisses, conflitos e inconsistncias nos requisitos, melhor entendimento por parte dos usurios de suas necessidades, entre outros.

    Isso pode originar novos requisitos, problemas tcnicos, de cronograma ou de custo, mudana nas prioridades do cliente devido a

    mudanas no ambiente de negcios, o aparecimento de novos competidores, mudanas econmicas, mudanas na equipe, mudanas

    no ambiente onde o software ser instalado e, ainda, mudanas organizacionais ou legais.

    Essas solicitaes de mudanas podem surgir durante o processo de engenharia de requisitos, ao longo do processo de

    software ou, ainda, aps a implantao do produto de software. Diante deste cenrio destaca-se a atividade de gerncia de requisitos.

    A gerncia de requisitos apia as demais atividades abordadas e se preocupa em gerenciar as mudanas nos requisitos j acordados.

    Outra atividade associada a manuteno de uma trilha de mudanas identificando o gerenciamento dos relacionamentos entre os

    requisitos e as dependncias entre o documento de requisitos e demais artefatos produzidos.

    Existe uma preocupao com os procedimentos, processos e padres a serem usados para gerenciar as mudanas. Ela deve

    permitir o registro das solicitaes de mudana e a identificao dos requisitos afetados pela mudana solicitada, alm de avaliar o

    impacto das mudanas, os riscos, os custos e benefcios, os recursos e alteraes no cronograma, obter a aprovao dos clientes e,

    ento, documentar, projetar e implementar a mudana.

    Se as mudanas no forem controladas, alteraes com baixa prioridade podem ser implementadas antes de outras de

    alta prioridade e modificaes com custo alto, que no so realmente necessrias, podem ser aprovadas. A rastreabilidade

    tambm importante, pois garante descries da vida de um requisito por todo o ciclo de vida de desenvolvimento do software.

    (2) Projetos alternativos

    Projetistas de interao no costumam ser treinados para criar projetos alternativos. O resultado que poucas solues

    alternativas so geradas. Ter muitas idias e gerar opes diversas para poder ento extrair uma boa idia uma prtica que deveria

    ser mais comum dentro das equipes de desenvolvimento. Isto pode ser feito em diferentes etapas do processo de criao ou gerao de

    solues.

    Reunies de Brainstorms, por exemplo, contribuem para o levantamento de requisitos, mas tambm oferecem idias

    alternativas de interao no incio do projeto. Existem outras forma de manter esta prtica em outros pontos do desenvolvimento do

    projeto. Tcnicas emprestadas de outras reas podem ajudar, como por exemplo, os aspectos do design tradicional que ajudam em

    situaes j estabelecidas de compreenso e entendimento do produto.

  • Mas tudo isso precisa ser comunicado, afinal foi gerado um plano que dever ser expresso de forma que permita ser

    revisto, revisado e melhorado. Este plano utilizar formas diversas de apresentao, tais como esboos preliminares, diagramas,

    prottipos, entre outros. A combinao de tcnicas ser mais efetiva na comunicao. Outros dois aspectos importantes na

    comunicao do plano o cuidado no uso de jarges e notaes tcnicas e a qualidade da redao dos documentos.

    Escolher um design alternativo implica tomar decises acerca dos procedimentos de interao pensados e dos dispositivos

    para entrada e sada de dados, alm do formato da informao. Alm disso devem ser considerados o fcil acesso, a eficincia no uso,

    o retorno adequado, o tempo de resposta, a qualidade e quantidade de informao. Qualidade pode ser a chave para a escolha do

    melhor prottipo, mas isso depende da definio do critrio de qualidade que precisa ser estabelecido.

    Produzir projetos alternativos depende do pr-requisito sobre a compreenso das necessidades, dos usurios e das

    tecnologias disponveis para elaborar solues e determinar as melhores solues dentre as diversas alternativas. Os prottipos de

    projetos alternativos podem ser no funcionais ou funcionais, mais ou menos elaborados e devem ser desenvolvidos por meio de

    wireframes, mockups de telas e prottipos de papel para testes iniciais com o usurio.

    (3) Verses interativas

    Embora prottipos no funcionais ofeream uma boa idia do comportamento dos procedimentos de interao, so as verses

    interativas que fornecero uma sensao mais realstica do processo. A escolha do prottipo depender do tempo e oramento

    destinado ao projeto. O importante que existam formas de comunicar os processos e condies para poder analis-los como se

    fossem o produto final.

    O prottipo de papel uma soluo de baixa fidelidade, mas barata e simples de ser realizada tambm nesta etapa.

    Ela ajuda a verificar as condies de interao do sistema com desenhos simples das telas e dos processos.

    (4) Avaliao

    No processo de avaliao centrada no usurio dito que o usurio se torna o co-designer do projeto. Sua participao

    normalmente aponta alteraes de melhoria nos sistemas, mas este envolvimento pode acontecer ao longo de todo o desenvolvimento

    do projeto com participaes do usurio. Ele envolvido em processos de observao, conversas, entrevistas, mas o objetivo sempre

    testar o sistema e seus processos de interao e no o usurio. Falaremos mais sobre isso nos ltimos captulos onde veremos

    tcnicas e procedimentos adequados esta atividade. Projetos alternativos so utilizados nas primeiras avaliaes e tambm podem

    utilizar usurios. Independente do formato da avaliao a qualidade do prottipo direciona os objetivos da avaliao conforme

    abordagens de baixa, mdia e alta fidelidade (Reis, 2004).

    MAS NO TEMOS TEMPO DE DOCUMENTAR!

    Em projetos em que o cronograma definido com data de entrega para ontem, qualquer atividade de projeto e

    documentao acaba sendo prejudicada. Os procedimentos mnimos para a elaborao de documentos exigem tempo, principalmente

    as atividades de entrevistas e ajustes. Mas pelo menos a regra de negcio precisa estar claramente estabelecida.

    Bom! A frmula da soluo rpida NO EXISTE! A entrevista e/ou outra abordagem de reconhecimento do processo do

    negcio e das condies de envolvimento dos usurios so de extrema necessidade. Se isso no puder ser feito por uma equipe

    alocada par este fim, utilize qualquer outro recurso para entender a atividade, o processo e seus usurios. A resoluo do problema

    poder no ser a ideal, mas os problemas decorrentes podero ser minimizados para o usurio e cliente do produto.

    Como fazer isso ento? Tente criar estratgias rpida de definio de processos de interao por meio de entrevistas

    rpidas com o cliente e, se possvel, com algum usurio representativo. A documentao pode acontecer de forma no estruturada

    durante as entrevistas. Uma dica fazer o maior nmero de questionamentos possvel para no errar na hora do desenvolvimento.

    DOCUMENTE O MXIMO QUE PUDER, mas OBJETIVE O MNIMO para viabilizar a CONSTRUO DE TELAS.

    Uma boa opo para um projeto com prazo apertado tocar as atividades de projetos alternativos em paralelo.

    Assim, alguns wireframes, ou mesmo telas, podem ser iniciadas para colaborar na construo de uma documentao. As telas podero

    apresentar o produto na forma de um prottipo no funcional antes da implementao e das decises tomadas por programadores

  • (preservadas as excees, programadores costumam tomar decises voltadas estrutura da programao e seus bancos de dados,

    desconsiderando usurios e processos de interao usveis). Prottipos s so possveis aps o levantamento de requisitos. Mas se o

    cenrio exigir, tente viabilizar os passos 1 (Necessidades) e 2 (projetos alternativos) em paralelo.

    Considere o uso de diagramas estruturais para entender o escopo geral e, se houver tempo, explorar tarefas crticas. Muitas

    ferramentas ajudam na criao de diagramas para estruturar uma seqncia lgica de atividades em diferentes nveis de abstrao

    (caneta e papel, MS-Visio, Axure, Morae, PowerMapper, Word, Open Office, etc). Detalhamentos podem ser gerados de acordo com

    o tempo disponvel. Quanto mais detalhado mais claro se torna o processo que dever ser desempenhado pelos diferentes atores do

    sistema.

    Uma soluo descomplicada de documentao

    Pagani (2008) oferece uma forma de documentao rpida, prtica e de fcil entendimento pelo desenvolvedor e cliente. Elabore uma

    macro-arquitetura de informao do sistema ou website com um diagrama da estrutura de navegao, faa os wireframes das telas e os

    diagramas estruturais. Naturalmente isso no pode ser feito sem uma conversa para entendimento das necessidades, mas acelera e

    simplifica o processo de documentao. Saiba mais em http://blog.talitapagani.com.

    Figura 10 Diagramas propostos por Pagani (2008) em modelo de documentao descomplicada

    5. Modelagem do desempenho das tarefas

    A engenharia semitica oferece uma viso mais detalhada do processo de design de forma que o designer tenha uma

    variedade maior de vises do usurios na utilizao de algo. Ela difere do IHC pois abrange um enfoque maior da comunicao

    designersistema- usurio. Segundo Prates (2006) a modelagem de interao em engenharia semitica permite prever a interao

    entre usurio e sistema a partir do que seria uma conversa predefinida pelo designer. Esta conversa representa os possveis passos

    do usurios e as possveis respostas e processamentos do sistema. A modelagem da interao a especificao de todas as

    possveis conversas que os usurios podero travar com o sistema. Dentre deste contexto deve ser modelado:

    O contedo de uma conversa; e

    A forma como acontece esta conversa.

    A modelagem do desempenho da tarefa a traduo das interaes de um produto. Isto pode ser apresentado formalmente,

    com uso de mtodos tradicionais (TAG task-action grammars ou UAN user action notation) utilizando ou no dicionrio de

    termos ou pode ser feito informalmente. As tarefas devem ser consideradas sem a influncia de elementos de interface, mas devem

    levar em conta o comportamento do usurio e do sistema ao longo do processo de utilizao do produto. Isso pode ser feito por meio

    de qualquer esquema que permita o reconhecimento do fluxo de tarefa como mostra a Figura 11, e pode ser utilizada qualquer

    ferramenta que permita o desenho deste esquema. Existem, no entanto, algumas ferramentas que se prope a facilitar este processo.

  • Figura 11 - Exemplo de um projeto de interao na forma de mapa conceitual de sistema com relaes das tarefas associadas trs perfis de

    usurios desenvolvido em Visio.

    Na engenharia semitica existem tcnicas que permite a modelagem do desempenho das tarefas realizadas pelos usurios.

    Uma delas o modelo de interao MoLIC proposto na PUC-Rio (BARBOSA; PAULA, 2003). Este processo muito prtico de ser

    utilizado em sistemas com funcionalidades limitadas. Pode ser utilizado em avaliaes preditiva (feitas por especialistas que

    observam, por meio da modelagem de interao, se o projeto adequado e vivel) ou para, somente modelar com clareza e detalhes as

    tarefas do usurio. O resultado obtido por esta modelagem grfico e podem ser obtidos com o uso software desenvolvido

    especificamente para este fim (SANGIORGI; BARBOSA, 2009 e SILVA, 2004).

    MoLIC linguagem para modelagem da interao com o usurio que permite construir diagramas que simulam uma

    conversa entre os usurios e o projetista do software. A linguagem baseada na engenharia semitica e utiliza diagramas para a

    construo destes dilogos. Para suportar o desenvolvimento destes projetos foi desenvolvido o MoLIC Designer, uma ferramenta

    que ajuda na construo destes diagramas. A pessoa que o utiliza precisa, apenas, ter o mnimo de conhecimento sobre a engenharia

    semitica. Assim como a linguagem MoLIC ajuda a pensar a interao a ferramenta ajuda a estruturar e organizar o projeto como um

    todo. O MoLIC ajuda a modelar os cenrios de interao baseado na engenharia semitica com recursos grficos similares ao UML.

    O funcionamento da linguagem MoLIC utiliza padres grficos de representao dos acontecimentos[1]. O projeto dos caminhos de

    interao (caminhos que o usurio pode percorrer: fluxo normal, caminhos alternativos, de exceo ou erro) consiste da definio da

    cena (cenrio de determinado assunto composto por cada passo da interao na qual so definidos os dilogos entre usurio e sistema)

    (Quadro 2 Exemplo de cena (Prates, 2006)Quadro 2), do tpico do dilogo (tema central) e do foco do dilogo (trecho de conversa

    sobre algum aspecto especfico do tpico).

    Quadro 2 Exemplo de cena (Prates, 2006) Os Termos U: e S: referem-se a usurio e sistema.

    Tpico: marcar uma reunio Em um sistema de agenda, marcar reunio pode constituir uma cena contendo o

    seguinte dilogo:

    Foco: compromissos desta semana

    U: Preciso examinar a semana atual.

    S: Ei-la.

    Foco: compromissos da prxima semana U: No h horrio disponvel para marcar minha reunio de 3 horas. Deixe-me ver a

    prxima semana.

    S: Aqui est.

    Foco: horrios disponveis U: Tem horrio disponvel na 3 feira, a partir das 14h.

    Foco: novo compromisso U: Vou marcar um compromisso.

  • Foco: dados do novo compromisso S: Que tipo de compromisso? Com quem e onde?

    U: Reunio com meu chefe. Ainda no sei onde ser.

    Foco: verificao do novo compromisso S: OK, marcado

    A modelagem na prtica deve conter incio e fim (Figura 12Erro! Fonte de referncia no encontrada.), mas a extenso do

    grfico depender da complexidade do dilogo. Este processo interno do dilogo o mais importante, pois depender de como o

    dilogo poder ser conduzido. So as transies que representam a mudana de rumo na conversa causada por uma fala do usurio (a

    partir de uma cena) ou por uma fala do preposto (a partir de um processamento). A transio, que pode acontecer a partir de uma cena

    ou a partir de um processo, representada por uma seta preta que indica a direo da transio e por um rtulo que pode ser (Figura

    13):

    uma pr-condio: condies que devem ser satisfeitas para que o usurio ou preposto possa enunciar a fala correspondente.

    uma ou mais falas do usurio ou do preposto do designer. No caso do usurio, trata-se de enunciados do usurio que

    causam a transio. No caso do preposto, trata-se de falas que revelam resultados de algum processamento do sistema que

    causam a transio.

    uma ps-condio: condies que passam a ser verdadeiras durante a transio.

    Figura 12 - Exemplo de modelagem MoLic com incio e fim

    Figura 13 - Modelos de interao: transies (Prates, 2006) e definio de elementos do dilogo

  • Figura 14 - Detalhes do dilogo no MoLic (Modelagem da tarefa utilizando MoLic (Prates, 2006))

    A fala de recuperao de breakdonw apontada na Figura 14serve para prevenir o erro. A preveno pode acontecer de trs

    formas: passivas, ativa ou apoiada (Figura 15).

    Figura 15 - Preveno de erro (na ordem: passiva, ativa, apoiada) (Serg, 2008)

    O tempo de resposta do processamento e, desta forma, da resposta ao usurio deve ser tratado conforme Figura 16 com uma

    instruo anexada ao dilogo de processamento. Outra condio so as formas como so tratados os fluxos de interao (Figura 17).

    Segundo Serg (2008) para cada meta ou fragmento de conversa na interao necessrio considerar a sequencia de atividades, os

    resultados possveis, os problemas e dificuldades e as alternativas. Por fim, para entender como a interao vira interface, acompanhe

    as sugestes de Serg na Figura 18.

    Figura 16 Representao do tempo de resposta (Serg, 2008)

  • Figura 17 - Diferentes fluxos para o mesmo processo (Serg, 2008). Estes exemplo mostram acessos ubquos, onde mais de uma atividade

    encontrada em uma cena.

    Figura 18 - Da interao para a interface

    6. Consideraes emergenciais para o projeto de interao

    Tem-se por princpio que todo produto possui um objetivo de uso. Ao se adquirir o produto entende-se que ele atender

    sua funo. Isso leva a crer que o objeto deva ser eficaz, pois atender ao seu propsito.

    difcil que algum compre algo que no atenda ao seu objetivo. Mas se por algum motivo um produto mau projetado cair

    nas mos de um usurio, ele ainda tentar utiliz-lo. Mesmo havendo uma frustrao inicial poder haver, ainda, um voto de

    confiana e a continuidade de tentativas na esperana de obter sucesso. Mas se o usurio no obtiver xito haver frustrao,

    xingamento, abandono, crticas, etc. Mas o que ser que este projetista imaginava durante o desenvolvimento deste produto? Bom,

    pode no ser culpa do projetista, afinal maus resultados de projetos de interao podem ocorrer por corte, no previso oramentria

    ou falta de tempo destinado s avaliaes.

  • Considerando, portanto, que o projeto de interao leva em conta a manipulao de elementos por um determinado

    USURIO, este indivduo naturalmente visto como o elemento importante do projeto de interao. Ao considerar o usurio

    imagina-se que a interao projetada depender de suas capacidades e habilidades em compreender e manipular os elementos de

    interface. Pensar o usurio durante o desenvolvimento do projeto, ento, evitar o sacrifcio do mesmo e uma possvel

    degradao do produto e da marca.

    SACRIFICAR O USURIO NO UMA OPO NO PROJETO DE INTERAO.

    E no deveria ser tambm uma opo da empresa. Afinal desconsider-los pode gerar resultados catastrficos. Quando o

    usurio no pode ser utilizado durante o desenvolvimento do projeto esta preocupao deve ser redirecionada. Algumas solues de

    projeto podem ser tomadas por meio de parmetros de comparao entre bons e maus exemplos.

    BOM x RUIM

    Solues baseadas no mundo real podem caracterizar uma boa opo de projeto. Mas nem sempre a melhor sada.

    Exemplo disso quando o modelo coloca em risco a segurana do usurio ou do equipamento. A tecnologia de realidade virtual, por

    exemplo, oferece opes de simulao de atividades impossveis ou difceis de serem executadas na vida real. As atividades so

    projetadas para parecerem o mais real possvel, mas sem causar prejuzo ao usurio. Do que adiantaria, por exemplo, replicar as

    condies reais de uso de um laboratrio de qumica ou fsica se o sistema oferecesse ao usurio exatamente as mesmas condies de

    perigo do ambiente real. Alguns comportamentos precisam ser reinterpretados para fornecer a informao de perigo ao usurio.

    Falaremos mais sobre isso quando discutirmos metforas e modelos conceituais.

    Como descobrir se um projeto bom ou ruim?

    A diferena entre projeto de interao Bom e Ruim o resultado sobre ser fcil de aprender, ser eficaz, atender ao objetivo

    e ser agradvel. Estes parmetros podem ser compreendidos como um resumo da usabilidade, e isso pode ajudar a comparar o Bom

    e o Ruim, identificando pontos fracos e pontos fortes. O projeto RUIM normalmente identificado por pontos fracos que causam

    irritabilidade, confuso, incapacidade (pela ineficincia do sistema ou dificuldade de uso), desistncia, entre outros. MAS ISSO

    FCIL DE DESCOBRIR. DIFCIL :

    descobrir por que difcil de ser utilizado?

    descobrir como seria possvel melhor-lo?

    Os meios mais eficazes de descobrir isso permitindo que usurios reais utilizem o produto enquanto so observados.

    7. Ciclo de vida do projeto de interao

    Modelos de ciclo de vida sugerem processos que representam conjuntos de atividades e suas relaes para o projeto,

    desenvolvimento e distribuio do produto. As muitas atividades envolvidas no processo do projeto de interao so similares e os

    modelos tradicionais de ciclo de vida da engenharia de software podem ser aplicados no projeto de interao (cascata, RAD, espiral,

    tec). A forma como as tarefas so tratadas pode diferenciar no resultado desses projetos. Mas percebe-se que modelos simplificados

    so os mais praticados na rea de IHC, embora projetos de grande escala necessitem de modelos de ciclo de vida mais elaborados.

    Na rea de IHC poucos modelos de ciclo de vida foram propostos, mas os que merecem destaque so: o modelo simplificado

    proposto por Preece et. Al (2005), o modelo estrela sugerido por Hartson e Hix em 1989 e o modelo da engenharia de usabilidade

    proposto por Mayhew em 1999.

    O CICLO DE VIDA SIMPLIFICADO do projeto de interao possibilita um nmero ilimitado de repetio do ciclo,

    desde que a ltima atividade sempre seja um teste. Este modelo foi proposto por Preece et. Al aps observaes sobre como a

    prtica do projeto de interao acontece na vida real. Ele possui o foco no usurios e determina e possibilita que um produto evolua da

    forma que for compreendida como melhor pela equipe, havendo uma nica limitao de repeties: o oramento. Perceba que este

    modelo contempla as 4 etapas bsicas do PIU: 1) Identificar necessidade e estabelecer requisitos, 2) Construir verses alternativas, 3)

    Projeto/re-projeto (prottipos) e avaliao. A sequncia das atividades nos ciclos iterativos (nas repeties) depende da dinmica

    estabelecida pela equipe e dos problemas encontrados nas avaliaes (Figura 19).

  • Figura 19 - Modelo de ciclo de vida Simples para projeto de interao

    O CICLO DE VIDA ESTRELA uma proposta que no especifica um ordenamento das atividades, mas sua flexibilidade

    exige que uma avaliao sempre seja feita antes de iniciar uma nova atividade. Este modelo surgiu das observaes de Hartson e Hix

    que verificaram que dois processos eram utilizados por designers de interface como modelos de ciclo de vida. O ANALTICO com

    caracterstica de organizao, formalidade e com uma viso que partia do sistema para a viso do usurio e o SINTTICO

    caracterizado pela criatividade, livre pensamento e improviso com a viso que partia do usurio para a do sistema. Este modelo inclui

    a implementao e a anlise de tarefas. As outras atividades vo de encontro com as atividades bsicas dos projeto de interao: 1)

    necessidade e requisitos, 2) verses alternativas (projeto conceitual), 3) prottipos e avaliao (Figura 20).

    Figura 20 - Modelo de ciclo de vida Estrela

    O modelo de CICLO DE VIDA da engenharia de usabilidade envolve detalhes complexos sobre o desenvolvimento do

    produto, mas permite que pessoas com pouco conhecimento de usabilidade trilhem este caminho com mais facilidade. O modelo que

    apoiado na engenharia de software baseado em trs tarefas essenciais: 1) Anlise de requisitos, 2) Projeto/teste/desenvolvimento e 3)

    Instalao. Fica claro neste modelo a necessidade de identificao das metas de usabilidade na tarefa 1 (Figura 21).

  • Figura 21 - Modelo de ciclo de vida da Engenharia de Usabilidade

    8. Atividades

    Crie um celular de tamanho pequeno (mximo de 3 x 3 centmetros) com opes de realizar ligaes e incluir nmeros na

    agenda do telefone. Realize as seguintes atividades:

    Qual modelo de ciclo de vida sua equipe usaria?

    Quais so as necessidades e requisitos e como foram realizadas estas atividades?

    Esboce a idia de um modelo interativo e pelo menos um projeto alternativo?

    Que tipo de verso interativa foi produzida?

    Como a equipe avaliaria o seu produto?

    1. Do que trata o PIU, para que serve e como funciona?

    2. Qual a relao entre o PIU e a usabilidade?

    3. Quais so as 4 atividades do PIU?

    4. Identificar necessidades e requisitos uma das atividades do PIU. Esta j uma atividade tradicionalmente realizada no

    desenvolvimento de sistemas. Mas existe uma considerao que d a esta atividade um enfoque mais especfico e cuidadoso,

    e que nem sempre considerado pelos analistas tradicionais. Qual ?

    5. Qual a frmula rpida para o levantamento de necessidades e definio de requisitos? Como isso deve ser feito?

    6. Na engenharia de requisitos so citados 3 nveis de abstrao dos requisitos. Quais so?

  • 7. Engenharia de requisitos um macromodelo de atividades. Destaque 5 destas atividades discutidas na apostila.

    8. Qual a diferena entre Engenharia de Requisitos e Elicitao de Requisitos?

    9. Cite algumas tcnicas de elicitao de requisitos foque naquelas que possuem aplicao mais objetiva.

    10. Qual a diferena entre Elicitao de Requisito e Anlise de requisitos?

    11. A documentao de requisitos, uma das atividades da engenharia de requisitos, pode ser entendida como Especificao de

    requisitos, Documento de Requisitos ou Especificao de Requisitos. Isto est correto?

    12. A documentao de requisitos, uma das atividades da engenharia de requisitos, pode ser descrita, apenas, em um modelo

    formal de linguagem. Isto est correto?

    13. Em que momento da engenharia de requisitos a documentao que detalha os requisitos se torna um objeto que poderia ser

    usado como contrato de desenvolvimento de softwares?

    14. Para que servem wireframes ou mockups?

    15. Como funcionam os prottipos de papel?

    16. Qual a caracterstica que torna o modelo de ciclo de vida ESTRELA apropriado para projetos de interao?

    17. Cite trs modelos de ciclo de vida sugeridos para uso em projetos de interao.

    18. Desenvolva o modelo de tarefa para o seguinte cenrio: Seu Eustquio precisa de dinheiro e vai at o banco. Ele entra em

    sua conta e percebe que houve um crdito esperado h dias, mas resolve verificar o extrato da sua conta. Ele verifica que

    houve o dbito automtico de sua conta de luz de R$100,00. Verifica que h saldo suficiente e ento prossegue com a

    retirada do dinheiro. Ele digita o valor referente quantia desejada e confirma a operao com sua senha. Ele obtm uma

    confirmao impressa da transao e verifica o seu saldo mais uma vez. Ao final sai do sistema.