MATHEUS NEVES DA SILVA OLIVEIRA

TCNICAS DE PROTOTIPAO GIL NO AUXLIO PRODUO DE SOFTWARES EM RGOS GOVERNAMENTAIS

BRASLIA - DF

2012

FACULDADE OMNI
Curso de Ps-Graduao Lato Sensu MBA em Gesto da Tecnologia da Informao no Servio Pblico

MATHEUS NEVES DA SILVA OLIVEIRA

TCNICAS DE PROTOTIPAO GIL NO AUXLIO PRODUO DE SOFTWARES EM RGOS GOVERNAMENTAIS

Trabalho de concluso de Curso de Especializao apresentado como requisito parcial para a obteno de titulo de Especialista em Gesto da Tecnologia da Informao do Servio Pblico pelo Curso de Especializao Lato Sensu da Faculdade OMNI. Orientador: Prof. Dr. Renato Jorge Brown Ribeiro

BRASLIA - DF

2012

MATHEUS NEVES DA SILVA OLIVEIRA

TCNICAS DE PROTOTIPAO GIL NO AUXLIO PRODUO DE SOFTWARES EM RGOS GOVERNAMENTAIS

Monografia apresentada como requisito parcial para obteno de ttulo de Especialista, pelo Programa de Ps Graduao MBA em Gesto da Tecnologia da Informao no Servio Pblico, da Faculdade OMNI.

Aprovado em: __________/____________/_____________

Banca Examinadora:

Prof. Dr. Renato Jorge Brown Ribeiro

Braslia-DF (dd/m/a)

AGRADECIMENTOS

Agradeo a todas as pessoas que me apoiaram ao longo dessa jornada, que auxiliaram na obteno de conhecimento e que permitiram a dedicao do tempo necessrio. Dedico este trabalho a minha famlia e namorada que sempre acreditaram em mim.

RESUMO

Esta pesquisa buscou estabelecer uma relao entre as tcnicas de prototipao gil existentes e o aumento do envolvimento de reas de negcio nos processos de desenvolvimento de softwares dentro de rgos governamentais. Foram apresentadas e analisadas as diversas metodologias de gerncia de projetos e gesto de ciclos de vida de softwares e como estas podem impactar o andamento e a relao entre as reas de tecnologia da informao e as reas de negcios. Foram apresentados diversos conceitos de design grfico, comunicao visual e usabilidade que podem ser empregados na criao de softwares mais amigveis. Apesar das evidncias de impactos positivos e negativos dependerem de diversos outros elementos, defendeu-se a ideia da utilizao de tcnicas de prototipao gil como ferramentas de levantamento de requisitos por fbricas de softwares ou como ferramentas de expresso para reas requisitantes. Os itens pesquisados neste trabalho revelam como tais tcnicas podem ser utilizadas como subsdios para a melhoria do dilogo entre profissionais com diferentes experincias elucidando questes complexas.

PALAVRAS-CHAVE: Prototipao gil, Usabilidade, Requisitos de Software.

ABSTRACT

The present work tries to establish a relationship between the use of agile prototyping techniques available and the increase of business areas involvement in softwares development process inside governmental organizations. A diverse of array of methodologies of project management and software lifecycle management were presented and analyzed, including how they could impact the relationship between business areas and information technology areas. A large variety of graphic design and usability concepts were presented to lay the grounds of necessary knowledge to layout elegant user interfaces. Although the positive and negative impacts are hard to measure objectively due the amount of variables involved in the software development process, its sustained here besides that, agile prototyping is a useful tool for requirement gathering inside software companies and also a useful tool for clients to express themselves about what they want. The items researched in the present work reveal how these techniques can be used to subside and better the communication between professionals with different backgrounds and expertise bring clarity to complex issues.

PALAVRAS-CHAVE: Requirements.

Agile

Prototyping,

Usability,

Software

LISTA DE ILUSTRAES

Figura 1 Modelo de desenvolvimento em Cascata ......................................... 18 Figura 2 Modelo Scrum .................................................................................. 18 Figura 3 Ciclos de Planejamento .................................................................... 19 Figura 4 Estratgia de Servios da ITIL.......................................................... 26 Figura 5 Principio de fechamento Visual ........................................................ 60 Figura 6 Crescimento do contedo na Internet ............................................... 62 Figura 7 anlise SWOT .................................................................................. 72 Figura 8 Sitemap Axure .................................................................................. 78 Figura 9 Widgets Axure .................................................................................. 79 Figura 10 Interao Axure .............................................................................. 79 Figura 11 Prottipo em Axure ......................................................................... 80 Figura 12 Modelos em Axure .......................................................................... 80 Figura 13 Comportamentos Globais do Axure ................................................ 81 Figura 14 Prottipo Axure ............................................................................... 82 Figura 15 Tela de Trabalho do Balsamiq ........................................................ 83 Figura 16 Configurao de Widgets no Balsamiq ........................................... 84 Figura 17 Prottipo Finalizado no Balsamiq ................................................... 86 Figura 18 Configurao dos widgets no Pencil............................................... 87 Figura 19Prottipo finalizado em Pencil ......................................................... 88 Figura 20 Biblioteca de Widgets do Visio ....................................................... 89 Figura 21 Prottipo Finalizado no Visio .......................................................... 89 Figura 22 Prottipo em Excel ......................................................................... 90 Figura 23 Prottipo de Relatrio em Excel ..................................................... 91 Figura 24 Exemplo de Processo de Negcio.................................................. 92 Figura 25 Exemplo de Sitemap ..................................................................... 93 Figura 26 Prottipos em Papel ....................................................................... 94 Figura 27 Prottipo em papel com elementos impresso como auxlio ............ 94

1 - INTRODUO .................................................................................................... 10 1.1 Objetivos ....................................................................................................... 10 1.1.1 Objetivo geral .................................................................................................. 10 1.1.2 Objetivos especficos ...................................................................................... 11 1.2 Mtodo ........................................................................................................... 11 1.3 Limitaes do Estudo .................................................................................. 11 1.4 Estrutura dos Captulos ............................................................................... 12 2 - PANAROMA DO DESENVOLVIMENTO DE SOFTWARE ................................ 13 2.1 Prticas e metodologias em uso ................................................................. 13 2.1.1 Rational Unified Process................................................................................. 13 2.1.2 Extreme Programming .................................................................................... 17 2.1.3 PMBoK............................................................................................................ 20 2.1.4 Scrum ............................................................................................................. 22 2.1.5 ITIL.................................................................................................................. 24 2.1.6 COBIT ............................................................................................................. 28 2.1.7 Boas Prticas em Projetos de TI .................................................................... 28 2.2 Dificuldades no desenvolvimento de software .......................................... 31 2.2.1 Governana e Segurana ............................................................................... 31 2.2.2 Planejamento de TI superficial e insuficiente .................................................. 33 2.2.3 Domnio do Escopo ........................................................................................ 38 2.2.4 Envolvimento dos Stakeholders ...................................................................... 40 2.2.5 Problemas de Comunicao ........................................................................... 42 2.2.6 No atendimento das expectativas ................................................................. 42 3 - ASPECTOS DA EXPERINCIA DO USURIO ................................................. 46 3.1 Desenvolvimento Tecnolgico .................................................................... 47 3.2 O Design centrado no usurio .................................................................... 48 3.3 Aspectos da Experincia do Usurio.......................................................... 49 3.3.1 Usabilidade ..................................................................................................... 49 3.3.2 Acessibilidade ................................................................................................. 55 3.3.3 Design de Interao e Interfaces .................................................................... 57 3.3.4 Envolvimento Emocional................................................................................. 60 3.3.5 Arquitetura de Informao .............................................................................. 61 4 - PROTOTIPAO GIL NO DESENVOLVIMENTO DE SOFTWARES............. 65 4.1 Definio do Escopo .................................................................................... 66 4.1.1 Objetivos ......................................................................................................... 66 4.1.2 Tarefas a desempenhar .................................................................................. 68 4.1.2.3 Funcionalidades .......................................................................................... 70 4.2 Definio dos Atores, Perfis e Personas .................................................... 70 4.3 Benchmarking de solues ......................................................................... 71 4.4 Mtodos de Prototipao ............................................................................. 72 4.4.1 Prottipos em Papel ....................................................................................... 74 4.4.2 Prottipos Digitais ........................................................................................... 76 4.5 Ferramentas de Prototipao ...................................................................... 77 4.5.1 Axure .............................................................................................................. 77 4.5.2 Balsamiq ......................................................................................................... 82 4.5.3 Pencil .............................................................................................................. 86 4.5.4 Visio ................................................................................................................ 88 4.5.5 Editores de Planilhas Eletrnicas ................................................................... 90 4.6 Entregveis ou Artefatos ............................................................................. 91

4.6.1 4.6.2 4.6.3 4.7

Notao de Modelagem de Processo de Negcio .......................................... 91 Sitemap ou Mapas de Site .............................................................................. 92 Prottipos e Wireframes ................................................................................. 93 Guia de Estilos .............................................................................................. 94

5 - CONCLUSO ..................................................................................................... 96 6 - REFERNCIAS .................................................................................................. 98

1-

INTRODUO
O presente trabalho analisa sob a tica de gesto de tecnologia da

informao, como as tcnicas de prototipao gil e conhecimentos de design de interao podem auxiliar na melhoria dos processos de desenvolvimento de software dentro das estruturas j presentes em rgos governamentais. Atualmente as reas de tecnologia de informao deste setor so em sua maioria ocupadas por pessoas com alto nvel de conhecimento tcnico, engenheiros de software e cientistas da computao, que por natureza da profisso possuem uma abordagem que prioriza aspectos tcnicos e colocando questes negociais e em segundo plano. O sincronismo estratgico entre as reas de negcio e os departamentos de tecnologia da informao essencial para o desenvolvimento de uma estratgia vencedora de governana institucional, como afirma Cooper:
The technology-savvy businessperson knows that his success is dependent on the quality of the information available to him and the sophistication with which he uses it. The business-savvy technologist, on the other hand, is an entrepreneurial engineer or scientist trained for technology, but possessing a keen business sense and an awareness of the power of information. Both of these new archetypes are coming to dominate contemporary business. (Cooper, 2004, p16)

Partindo desta premissa, necessrio que o espaamento entre estas duas rea seja reduzido. Este trabalho parte da premissa de que reas requisitantes que possurem um maior domnio dos processos de software podero demandar softwares que melhor atendam suas necessidades. 1.1 Objetivos 1.1.1 Objetivo geral Pretende-se com este trabalho criar um panorama de tcnicas de prototipao de software, que de alguma forma permitam a melhoria do dilogo entre reas de negcio e rea tecnolgicas. Desta forma acredita-se que ser possvel aumentar a qualidade, diminuir erros e melhor utilizar o tempo em projetos de software.

11

1.1.2 Objetivos especficos a) Apresentar um panorama dos processos de engenharia de software empregados por diversos rgos e fbricas de software; b) Identificar e apresentar aspectos de design de interao, experincia do usurio e organizao da informao; c) Apresentar ferramentas e metodologias de coleta de informao para a criao de prottipos de software que permitam uma viso melhor dos produtos de software a serem desenvolvidos; 1.2 Mtodo O presente trabalho foi desenvolvido em trs etapas distintas: A primeira etapa consiste em um levantamento bibliogrfico e pesquisa de referncias no s ligadas aos processos de engenharia de software, mas tambm buscando uma anlise do trabalho desenvolvido dentro de rgos pblicos por fbricas de software terceirizadas. Na segunda etapa deste projeto, foi realizado um levantamento dos conceitos de design, tcnicas de design de interao e organizao de elementos visuais. O objetivo desta parte apresentar questes de experincia do usurio que normalmente so colocadas em segundo plano por engenheiros de softwares e cientistas da computao. Na terceira parte so apresentadas tcnicas de prototipao gil, coleta de requisitos e conceitos de pesquisa de mercado utilizados por escritrios de design e agncias de comunicao web. 1.3 Limitaes do Estudo Este estudo foi desenvolvido coletando informaes relacionadas a reas de engenharia de software, design e psicologia. Foram estudados os principais paradigmas e catalogadas as principais tcnicas, metodologias e conceitos empregados atualmente. Com o objetivo de realizar um trabalho coeso e slido a pesquisa realizada englobou aspectos tecnolgicos, negociais e de gesto de projetos. Este trabalho se limita a descrever tais conceitos e tcnicas, assim como elencar seus possveis benefcios para o desenvolvimento de softwares junto a rgos governamentais.

12

1.4

Estrutura dos Captulos Este trabalho foi organizado visando possibilitar um entendimento gradual das

questes mais evidentes das etapas de produo de softwares e apresenta sequencialmente as estruturas organizacionais comuns, as tcnicas que podem ser empregadas e posteriormente como empregar tais tcnicas. Os captulo dois busca esclarecer estruturas contratuais comuns em rgos pblicos, assim como as metodologias mais utilizadas. Este captulo tem o objetivo de apresentar estas metodologias e analisar como elas impactam nos projetos. No captulo trs deste trabalho, so apresentados conceitos e tcnicas associados ao design de interface centrado no usurio, que leva em considerao aspectos de usabilidade, acessibilidade, arquitetura de informao e design de interao. Neste captulo so apresentados os conceitos que fundamentaro o desenvolvimento dos prottipos e entregveis propostos neste trabalho. O quarto captulo apresenta tcnicas para prototipao e criao de artefatos que auxiliaro tanto no entendimento dos requisitos negociais como tecnolgicos, trazendo maior visibilidade do comportamento do produto final.

13

2-

PANAROMA DO DESENVOLVIMENTO DE SOFTWARE

Atualmente existe uma enorme quantidade de metodologias e prticas de

gesto de projetos em TI, governana e tcnicas de desenvolvimento de software empregadas tanto no setor privado e pblico. Muitas destas prticas ainda esto estgios embrionrios e no convm mencion-las neste trabalho, porm devemos atentar para as que j so amplamente adotadas.
It's one thing to see that a problem exists, but it's quite another to devise a solution. One key part of problem solving is the language we use. Over the years, I've developed many useful terms and mental models. They have proven vital to framing the problem presented by hard-to-use software-based products. In this chapter I will introduce those terms and ideas, showing how they can help bring the benefits of interaction design to our troubled process.(Cooper, 2004, p44)

Para que seja possvel entender como a prototipao gil proposta neste trabalho pode auxiliar projetos de TI, necessrio entender o ambiente organizacional e as estruturas contratuais comuns. 2.1 Prticas e metodologias em uso comum encontra em contratos de grande rgos governamentais, tais quais ministrios, menes a metodologias consagradas no mercado, com um histrico consistente de aplicaes e reconhecidas por rgos regulamentadores. 2.1.1 Rational Unified Process O Rational Unified Process (RUP) um framework iterativo e incremental utilizado para desenvolvimento de softwares. Ele foi criado pela Rational Software Corporation (uma diviso da IBM). O RUP no um processo concreto que deve ser utilizado em sua totalidade, ele uma implementao especfica do Unified Process, e consiste em um framework de processo, destinado a ser customizado por cada organizao e/ou times de projeto conforme acharem melhor. Estas empresas ou equipes devem selecionar os elementos de processos que so mais apropriados s suas necessidades. O RUP baseado em um conjunto de bloco ou elementos de contedo, que descrevem o que ser produzido, as habilidades necessrias e a explicao passo-

14

a-passo de como as metas especficas de desenvolvimento sero atingidas. Os principais elementos so: a) Papis Um papel define um conjunto de habilidades necessrias, competncias e responsabilidades. b) Produtos de trabalho Um produto de trabalho representa algo resultante da execuo de uma tarefa, includo toda documentao e modelos produzidos durante o processo. c) Atividades Um atividade descreve uma unidade de trabalho associada a um papel que prov um resultado significativo.

2.1.1.1

Fases do RUP

Em cada iterao realizada existem quatro fases, que correspondem a uma das dimenses do framework. Uma passagem pelas quatro fases constitui um ciclo de desenvolvimento.

2.1.1.1.1

Iniciao

Esta fase tem por objetivo estabelecer o escopo dos software que ser criado ou das modificaes que sero executadas. Ela identifica os principais casos de uso assim como os principais cenrios de operao. Estima um esforo geral para execuo do trabalho abordando aspectos de arquitetura, custo, tempo e riscos.

2.1.1.1.2

Elaborao

A parte de elaborao aprofunda as questes arquiteturas de modo a garantir uma base estvel para a fase de construo. So avaliados aqui requisitos crticos do sistema.

2.1.1.1.3

Construo

Com base na arquitetura definida, esta fase tem o objetivo de concluir a definio dos requisitos e executar a construo do sistema de forma adequada, com rapidez e eficincia. Esta fase proporcionalmente a mais longa das quatro fases.

15

2.1.1.1.4

Transio

O objetivo principal da fase de transio garantir que o software esteja disponvel para seus usurios finais. Para isto n a fase de entrega que ocorrem maior parte dos testes, treinamentos, converses de bancos de dados, atividades de ajustes e correes. Essas fases so acompanhadas pela execuo de nove disciplinas que adicionam uma segunda dimenso ao framework. As disciplinas so divididas em seis de engenharia e trs de suporte.

2.1.1.2 2.1.1.2.1

Disciplinas de engenharia Modelagem de Negcio

Foca na compreenso da organizao, seus objetivos, seus problemas e possibilidades de melhoria. Busca assegurar um nivelamento do entendimento da estratgia da organizao junto aos desenvolvedores e usurios.

2.1.1.2.2

Requisitos

Busca identificar: as funcionalidades que o sistema dever possuir, manter a concordncia com as expectativas dos usurios e delimitar fronteiras do que ser ou no desenvolvido. Esta disciplina busca fornecer os insumos necessrios para definio de custo, tempo e planejamento ser executado. 2.1.1.2.3 Anlise e Design

Compreende questes arquiteturais e tecnolgicas essenciais para o desenvolvimento do projeto de software.

2.1.1.2.4

Implementao

Esta disciplina trata da produo do software e aborda questes relacionadas organizao de cdigo, criao das classes, objetos e componentes (arquivos-fonte, binrios, executveis, etc.), realizao de testes unitrios e integrao dos resultados produzidos pelos diversos membros da equipe ao produto final.

16

2.1.1.2.5

Teste

A disciplina de teste atua fornecendo insumos s outras disciplinas e aborda principalmente a avaliao de qualidade do produto. Ela responsvel por localizar e documentar defeitos de qualidade do software, validar as suposies feitas nas especificaes de design e requisitos, validar se as funcionalidades foram construdas e se comportam conforme foram planejadas.

2.1.1.2.6

Implantao

A disciplina de implantao aborda aspectos da distribuio do software e descreve atividades que garantem que o produto de software ser disponibilizado a seus usurios finais.

2.1.1.3 2.1.1.3.1

Disciplinas de suporte Gerenciamento de Configurao e Mudana

Assim como o CMMI, esta disciplina foca no controle de atualizao e mudanas realizadas nos artefatos do projeto buscando manter a integridade destes. Esta disciplina identifica os itens de configurao, as restries de mudana, a auditoria das mudanas realizadas, alm de definir o gerenciamento das configuraes destes itens. 2.1.1.3.2 Gerenciamento de Projeto

O objetivo desta disciplina facilitar e coordenar o trabalho a ser executado. Aborda aspectos de gerenciamento de riscos, pessoas, comunicao, oramento, contrataes, treinamentos, contratos, relacionamentos com clientes e parceiros, entre muitos outros. 2.1.1.3.3 Ambiente

O objetivo desta disciplina oferecer equipe ou organizao, as ferramentas e processos necessrios para o desenvolvimento de software.

2.1.1.4

Pontos fortes do RUP

Entre os grandes motivos da larga adoo do RUP esto dois aspectos, o tempo que se encontra em utilizao, e a flexibilidade na seleo dos processos que

17

sero utilizados pelos times. Em relao s questes contratuais pblicas que demandam um controle robusto e claro das evidncias dos servios prestados, o RUP desponta por ter uma forte nfase na exatido e controle de documentao. Um ponte que favorece a sua adoo sua capacidade de solucionar problemas relacionado a mudana e evoluo de requisitos atravs das solicitaes de mudanas. amplamente aceito comercialmente que por possuir foco na reutilizao de componentes seria o tempo de desenvolvimento seria reduzido, apesar de esta caracterstica ser parcialmente aceita, existem outros aspectos relacionados aos contratos em vigor que vo de encontro com esta premissa.

2.1.1.5

Pontos Fracos do RUP

Para que o RUP tenha sucesso na sua implantao necessrio que os membros da equipe sejam muito experientes e especialistas no desempenho de suas tarefas dentro desta metodologia. Com o constante desenvolvimento de novos componentes e dinmicas de interao proporcionados pela difuso da internet e suas plataformas colaborativas, a reutilizao de componentes, que um dos pontos fortes no aumento da produtividade com o RUP, passa a sofrer um impacto grande. Em rgos governamentais, comum lidarmos com grandes projetos, e apesar do RUP contar com caminhos de integrao durante os processos de desenvolvimento de software, nestes projetos a teoria no se aplica, e a integrao se torna confusa, causando bastante repercusso nos estgios de teste.

2.1.2 Extreme Programming Extreme programming, uma metodologia que possui foco extremo na satisfao do cliente, e prioriza aspectos mais humanizados em detrimento a engenharia de software com processos rgidos e documentao. Por enfatizar o trabalho em grupo, gerentes, clientes e desenvolvedores so tratados como parceiros com o mesmo nvel hierrquico em uma equipe colaborativa. Um dos principais aspectos a questo dos times serem auto

18

gerenciveis e poderem se reorganizar de forma altamente produtiva para resoluo mais eficiente possvel dos problemas que surgem. Esta metodologia de desenvolvimento de software possui uma srie de regras que so bastante simples e autoexplicativas. Estas regras esto dividas em cinco grupos distintos: Planejamento, Gerenciamento, Design, Codificao e Testes. Em processos tradicionais, as atividades costumam ser agendadas em sequencia, uma aps a outra at que o projeto seja concludo. comum que o design, comece aps o trmino da anlise e a codificao apenas aps a concluso da anlise. Ao final deste modelo o resultado final apresentado ao cliente.

Figura 1 Modelo de desenvolvimento em Cascata

Nestes processos tradicionais (em cascata) o foco est na visualizao completa dos requisitos, e estes so uma constante do projeto como apresentado na figura acima. Desta forma possvel focar em um tipo de atividade de cada vez conforme o projeto avana de uma fase para outra. As metodologias geis, como extreme programming, trabalham pela tica de que requisitos sero modificados e oportunidades de melhoria surgiro conforme o projeto caminha. Desta forma os requisitos no podem ser vistos com uma constante do projeto. So tratadas como constantes as fases do projeto e apenas uma parte dos requisitos tratada de cada vez. Assim como RUP as metodologias geis so iterativas e incrementais, compostas de vrios ciclos de desenvolvimento conforme exemplifica a figura abaixo.

Figura 2 Modelo Scrum

Tendo em vista esta organizao, a parte mais importante da aplicao desta

19

metodologia est na correta priorizao dos requisitos. Desta forma a eficincia obtida atravs de um impacto menor no caso de alteraes. Esta metodologia precisa ser utilizada com cuidado e critrio, pois esta liberdade pode fazer com que a possibilidade de mudanas constante impacte no andamento do projeto como um todo. Conforme um projeto cresce a dificuldade e custo para realizar alteraes tambm cresce e para isto necessrio que diversas prticas de codificao sejam utilizadas. Metodologias de desenvolvimento gil se mostram mais eficientes quando as equipes empregadas, so formadas pro pessoas mais experientes, a maturidade profissional da equipe essencial para que projetos grandes possam manter a qualidade. Ciclo de vida de software na extreme programming:

Figura 3 Ciclos de Planejamento

necessrio que um cliente ou gerente de produto seja designado para incorporar a equipe composta de gerente e desenvolvedores. Esta pessoa precisa trabalhar constantemente prxima equipe, provendo informaes negociais que permitam a construo do produto desejado. Parte essencial do planejamento so as estrias de usurios, estas contm os requisitos desejado pelos clientes. Geralmente uma estria de usurio se assemelha muito a um caso de uso, onde se descreve o que ser possvel realizar no produto a ser desenvolvido. Estas estrias de usurios podem ser escritas a mo ou impressas em

20

cartes, em seguida organizadas e agrupadas. O escopo do projeto definido com o agrupamento destas estrias. Uma vez com as estrias de usurios, o planejamento segue em trs camadas com um agrupamento de estrias. A primeira camada se trata do planejamento em longo prazo, onde se busca visualizar como o projeto estar em alguns meses e quais estrias sero abordadas mais frente. A segunda camada de planejamento trata do que ser feito na prxima interao. A terceira camada trata do planejamento das atividades para a execuo das estrias de usurios da iterao atual. Existem ento picos de definies de arquitetura e produo de prottipos que auxiliam numa viso geral das solues de projeto. Projetos que utilizam XP se apoiam na premissa de que desenvolvedores so responsveis por provar para aos clientes que seus cdigos funcionam e no o contrrio onde clientes so os responsveis por achar os erros de software. Cdigo de alta qualidade essencial em projeto com XP e para isto so utilizadas diversas tcnicas como desenvolvimento guiado por teste (TDD), programao em pares, refactoring, testes unitrios e testes de aceitao.

2.1.3 PMBoK PMBoK ou Project Management Body of Knowledge um guia para gerenciamento de projetos composto por diversos processos considerados boas prticas no gerenciamento de projetos. Este guia revisado periodicamente visando estar sempre alinhado com as prticas gerenciais em vigor. Este guia foi publicado inicialmente como artigo em 1987 pelo Project Management Institute (PMI), numa tentativa de padronizar prticas de projeto geralmente aceitas e empregadas. A primeira edio foi publicada em 1996, a segunda em 2000, a terceira em 2004. A quarta edio, mais recente e em vigor, foi publicada em 2008. Este guia organizado em processos, descrevendo o trabalho executado por cada processo e suas interaes com outros processos. So descritas as entradas (documentos, planejamentos, especificaes etc.), as ferramentas e tcnicas (aplicadas as entradas) e por ltimo as sadas (documentos, produtos, etc.).

21

So ao todo quarenta e dois processos agrupados em cinco grupos de processo e nove reas de conhecimento. Os grupos de processo, muitas vezes erroneamente tratado como fases so: Iniciao, Planejamento, Execuo, Monitorao e Controle e Encerramento. As reas de conhecimento so: Gesto de Integrao do projeto, Gesto de Escopo do projeto, Gesto de Tempo do projeto, Gesto de Custos do projeto, Gesto de Qualidade do projeto, Gesto de Recursos Humanos do projeto, Gesto de Riscos do Projeto, Gesto de Aquisies do projeto. Segue a matriz de processos, reas e grupos de processo do PMBoK:
reas de Conhecimento Iniciao Planejamento Execuo Monitoramento e controle Encerramento

Integrao

1. Desenvolver o termo de abertura do projeto

2. Desenvolver o plano de gerenciamento do projeto

4. Monitorar e controlar o trabalho 3. Orientar e do projeto gerenciar a 5. Realizar o controle execuo do projeto integrado de mudanas

6. Encerrar o projeto ou fase

Escopo

1. Coletar os requisitos 2. Definir o escopo 3. Criar a EAP

4. Verificar o escopo 5. Controlar o escopo

Tempo

1. Definir as atividades 2. Sequenciar as atividades 3. Estimar os recursos das atividades 4. Estimar as duraes das atividades 5. Desenvolver o cronograma

6. Controlar o cronograma

Custos

1. Estimar os custos 2. Determinar o oramento

3. Controlar os custos

Qualidade

1. Planejar a qualidade

2. Realizar a garantia de qualidade

3. Realizar o controle da qualidade

Recursos Humanos

1. Desenvolver o plano de recursos humanos

2. Mobilizar a equipe do projeto 3. Desenvolver a equipe de projeto 4. Gerenciar a

22

equipe do projeto

Comunicao

1. Identificar as partes interessadas

2. Planejar as comunicaes

3. Distribuir as informaes 4. Gerenciar as expectativas das partes interessadas

5. Reportar o desempenho

Riscos

1. Planejar o gerenciamento dos riscos 2. Identificar os riscos 3. Realizar a anlise qualitativa dos riscos 4. Realizar a anlise quantitativa dos riscos 5. Planejar as respostas aos riscos

6. Monitorar e controlar os riscos

Aquisio

1. Planejar as aquisies

2. Conduzir as aquisies

3. Administrar as aquisies

4. Encerrar as aquisies

Estes processos focam no conhecimento necessrio para que seja possvel gerenciar todo o ciclo de vida de projetos de qualquer espcie. Por determinar as entradas e sadas especificas de cada projeto, no necessrio improvisar constantemente solues para os problemas encontrados. Porm importante mencionar que a utilizao de todos estes processos pode tornar impraticvel sua utilizao para gerenciamento de pequenos projetos.

2.1.4 Scrum O Scrum um framework para execuo de projetos complexos, originalmente formalizado para o desenvolvimento de projetos de softwares, mas que pode ser utilizado em projetos de qualquer natureza. O termo Scrum utilizado por seu criador, foi emprestado de um estudo publicado na Harvard Business Review onde seus autores comparavam equipes de alto desempenho com a formao scrum do rugby. Este processo de desenvolvimento de software est sendo amplamente adotado por empresas de diversos tamanhos, setores incluindo rgo

governamentais como foras armadas. Atualmente a Scrum Alliance mantm treinamento nesta metodologia e busca sua difuso para diversos setores da

23

indstria e servios. Assim como a Extreme Programming o Scrum tem suas origens e valores no manifesto gil e prioriza: Indivduos e interaes sobre processos e ferramentas Funcionalidade completa sobre documentao Colaborao do cliente sobre negociao contratual Resposta a mudanas sobre planejamento Trata-se de uma priorizao e no de uma substituio entre estes elementos, lembrando que todos so essenciais para execuo de um projeto. Como colocado pela Scrum Alliance, o sucesso ser alcanado atravs de equipes e organizaes que entendam estes valores e princpios que fundamentam os processos geis. No Scrum temos trs papis: Product Owner (responsvel pelo valor negocial do projeto, requisitos e priorizao de funcionalidades), Scrum Master (responsvel por garantir equipe o necessrio para esta seja funcional e produtiva) e a equipe (responsvel por se auto gerenciar e completar o trabalho a ser executado). Existem quatro cerimnias ou tipos de encontros com objetivos diferenciados que so: Planejamento do Sprint (onde a equipe se encontra com o Product Owner para definir que conjunto de funcionalidades/trabalho ser executado durante o sprint), Daily Scrum (onde a equipe se rene diariamente para informar os obstculos, dificuldades e progresso das atividades), Sprint Reviews (onde a equipe demonstra ao Product owner o que foi completado durante o Sprint) e Sprint Retrospectives (onde a equipe busca maneiras de melhorar o produto e o processo). So produzidos e atualizados no Scrum trs artefatos: Product Backlog (prioriza uma lista de funcionalidades e objetivos desejados para o projeto), Sprint Backlog (conjunto de atividades e trabalho a ser realizado que a equipe acorda em realizar durante um Sprint) e Burndown Chart (apresentao visual do trabalho a ser realizado, podendo existir um para o andamento do Sprint e um para o andamento do projeto inteiro). O Product backlog dinmico, os itens podem ser adicionados ou excludos a qualquer momento ao longo do projeto. O itens cadastrados no product backlog esto sempre priorizados fazendo com que o os principais sejam completados primeiramente e os de menor importncia sejam mais bem refinados conforme o projeto progride.

24

O Sprint backlog, como mencionado anteriormente, negociado entre as partes interessadas, e definido o conjunto de itens que sero abordados no Sprint. O Sprint time boxed, ou seja, o tempo de durao de um Sprint fixo e no se estende ou reduz aps definido. Conforme a equipe trabalha durante o Sprint, e as funcionalidades vo sendo completadas, o time reavalia se ser possvel completar todo o escopo definido inicialmente, se o escopo poder ser aumentado ou poder ser reduzido tendo em vista o tempo restante. As mudanas de escopo so negociadas, sempre sem alterar o limite para o trmino do Sprint. No trmino de um Sprint a equipe deve ter mos um produto finalizado ser repassado ao cliente que pode ou no escolher colocar em produo. Ao trmino do Sprint dever haver uma avaliao e retrospectiva. Assim como RUP e XP, Scrum tambm iterativo e admite inmero ciclos at a concluso de um projeto. Cada Sprint deve atingir novos marcos de projeto abordando os itens descritos no product backlog. 2.1.5 ITIL A Information Technology Infrastructure Library (ITIL) um conjunto de boas prticas para o gerenciamento de servios de TI que foca no alinhamento dos servios de TI com as necessidades de negcio. Este conjunto de prticas surgiu como resposta do governo britnico a crescente dependncia dos servios de tecnologia. Hoje em dia como abordado neste trabalho, as reas de tecnologias da informao no podem ser vistas como entidade externas a nenhuma organizao. Estas se tornaram parte estratgica de qualquer ambiente organizacional. Em 1980 o governo britnico j reconhecia essa necessidade e a Central Computer and Telecomunications Agency desenvolveu um conjunto de

recomendaes percebendo que sem padres estabelecidos, o setor privado e agncias governamentais j estavam independentemente criando suas prprias prticas de gerenciamento de TI. Assim como a maioria dos conjuntos de conhecimentos a ITIL descreve procedimentos, atividades e checklists que no so especficos de nenhum tipo de organizao e so representados atravs de modelos de processos. Estes processos direcionam par um cenrio onde possvel estabelecer um nvel mnimo

25

de competncia em gerenciamento de servios de TI. Permite que organizaes estabeleam uma linha base de onde possvel planejar, executar e medir seus esforos, permitindo desta forma uma facilidade em transparecer os resultados de melhorias. Este conjunto de prticas retrata tecnologia da informao como um servio que requisito bsico para operao de uma organizao e busca garantir o funcionamento dentro dos parmetros estabelecidos. Para isto se apoia em acordos de nvel de servios para garantir confiabilidade (suporte adequado) e qualidade (disponibilidade e desempenho) dentro de custos estabelecidos. Desta forma acredita-se na melhoria do relacionamento entre reas de TI e seus clientes, reas de negcio, alm d aumento geral da qualidade das operaes que suportam a organizao uma vez que a rea de negcio sabe o que fornecer a rea de TI para que esta possa apresentar as solues. Por apresentar recursos para medio das melhorias e o reflexo no trabalho, os custos e riscos do investimento em tecnologia da informao passam a ser mais bem compreendidos pelas rea gestoras, alm de permitir aumentar a visibilidade e qualidade do planejamento em TI das organizaes. Este conjunto de prtica evolui bastante desde sua criao e desde 2007 se encontra na terceira verso, ITIL v3, tambm conhecida como ITIL Refresh Project. So vinte e seis processo e funes, na verso atualizada e publicada em julho de 2011, distribudos em cinco volumes, onde cada volume descreve uma parte do ciclo de vida do gerenciamento de servios de TI.

26

Figura 4 Estratgia de Servios da ITIL

2.1.5.1 ITIL Service Strategy (Estratgia de Servio) O principal objetivo deste volume clarificar e guiar a priorizao de estratgias e modelos baseados em servios. De uma forma geral, foca no auxlio do desenvolvimento e melhoria em longo prazo. A estratgia de servios busca identificar que servios devero ser oferecidos para quais clientes criando ento valor para estes clientes. Aborda tambm como evidenciar o valor gerado e como desenvolver planos de negcios para obter as capacidades e recursos necessrios aos servios. Estratgia de servios otimizar a alocao destes recursos e a medio constantes do desempenho dos servios prestados. Para isto conta com cinco processos: Strategy management for IT services, Service Portfolio

Management, Financial Management of IT Services, Demand Management, Business relationship management. Na estratgia de servio so identificados todos os requisites identificados e os resultados esperados so acordados em um SLP (Service Level Package).

2.1.5.2 ITIL Service Design (Projeto de Servio) O volume Service Design, disponibiliza um guia de boas prticas para o projeto de servios, processos e outros aspecto da gerncia de servios de TI. Desta

27

forma, o projeto de servios, foca em como uma soluo de servios planejada interage com o todo do ambiente organizacional e tecnolgico. Este servio envolve a transposio de objetivos estratgicos da organizao para servios e portflio de servios, alm de uma abordagem holstica de projetos para garantir a funcionalidade e qualidade de acordo com as necessidades de negcio. Desta forma so garantidos padres e convenes de projeto consistentes que devem ser seguidos em todos os servios e projetos a serem projetados. O servio de design concebido em todos os seus aspectos, que so documentados em um SDP (Service Design Package).

2.1.5.3 ITIL Service Transition (Transio de Servio) O objetivo deste servio assegurar a implantao dos servios em produo com base nas especificaes realizadas pelo servisse design, podendo tambm se encarregar da mudana do projeto de servio quando for detectada esta necessidade. Para execuo deste servio necessria a compreenso do potencial de criao de valor para o negcio, as partes interessadas (stakeholders), natureza dos servios, utilidade, garantia entre outros. A implementao do servio de transio acompanhada, testada e validada e o SKMS (Service Knowledge Management System) atualizado com as informaes do ambiente de produo.

2.1.5.4 ITIL Service Operation (Operao de Servio) neste estgio, de operao do servio, que efetivamente agregado valor ao trabalho do cliente. Os objetivos deste servio so o cumprimento dos nveis de servios acordado junto aos clientes e usurios e a gerncia das aplicaes, tecnologia e infraestrutura que suportam o funcionamento dos servios. O servio de operao mantido em funcionamento de acordo com o SLA (Service Level Agreement) estabelecido, para prover os resultados esperados.

28

2.1.5.5 ITIL Continual Service Improvement (Melhoria Contnua de Servio) Este servio visa manter o valor dos servios para o cliente por meio de avaliaes e melhoria contnua da qualidade dos servios e maturidade dos processos de gerenciamento combinando princpios, prticas e mtodos de gesto de qualidade, mudanas e melhoria da capacidade. O servio de melhoria continua identifica as oportunidades de melhoria na prestao dos servios.

2.1.6 COBIT O COBIT um framework criado pela ISACA (Information Systems Audit and Control Association) para governana em tecnologia da informao e representa Control objectives for information and related technology. um conjunto de ferramentas que permite a gerentes preencherem o vazio entre controle de requisitos, questes tcnicas e riscos de negcio. Foi inicialmente lanado em 1996, a verso atual , COBIT 4.1, foi publicada em 2007 e est sendo revisada e atualizada para verso 5.0. Sua misso Pesquisar, desenvolver, publicar e promover um conjunto atualizado, autorizado e com foco internacional, de objetivos de controle geralmente aceitos e aplicveis tecnologia da informao para serem usados por gestores de TI, usurios e auditores de sistemas. O COBIT ao invs de determinar, ele orienta como devem ser estruturados os processo e controles de TI para que os objetivos de governana sejam alcanados. Consiste atualmente em 34 processos genricos para gerenciamento de TI. Cada processo definido com entradas e sadas, atividades chaves, objetivos do processo, formas de medio e um modelo de maturidade genrico. Estes processos esto divididos em quatro categorias: Planejamento e organizao, Aquisio e Implementao, Entrega e Suporte, Monitoramento e Avaliao.

2.1.7 Boas Prticas em Projetos de TI

29

Como foi exposto, existem muitas metodologias e prticas que se sobrepe em diversos aspectos, e atravs dessas intersees, conseguimos identificar alguns valores e prticas que independente da estratgia da organizao, devem estar sempre no processo decisrio e de gesto de reas requisitantes de servios de TI.

2.1.7.1

Desenvolvimento Iterativo

Desenvolva iterativamente criando ciclos curtos, com um nmero no muito extenso de funcionalidades, permitindo que os requisitos evoluam durante o processo de desenvolvimento em afetarem demasiadamente o custo ou tempo. Gerenciar a coleta de requisitos de forma que estes estejam de acordo com as expectativas do cliente, alinhados com a estratgia da organizao e segmentados de acordo com suas prioridades. A definio da importncia e a completude destes so essenciais para que o desenvolvimento iterativo funcione como um relgio e o cliente esteja sempre satisfeito.

2.1.7.2

Uso de Componentes

O uso de componentes prontos e reutilizao de cdigos e bibliotecas essencial para a diminuio de prazo e custo, importante que estratgias de governana e design de arquitetura sejam constantemente revistas e adaptadas. Esta prtica afeta todos os aspectos do projeto, define uma linguagem comum para comunicao entre as diversas reas envolvidas e garante uma base slida para crescimento e expanso dos projetos.

2.1.7.3

Verificao da qualidade

Qualidade no um aspecto a ser verificado apenas em uma etapa do projeto, qualidade ela construda em todas as fases e parte do projeto. importante que sejam feitas verificaes constantes dos problemas encontrados, permitindo que sejam traadas as estratgias para melhoria dos processos. A qualidade est relacionada entrosamento da equipe, ferramentas disponveis, liderana e gerenciamento, disponibilidade de clientes, domnio do negcio pelas reas requisitantes. Apesar de todos os aspectos do projeto influenciarem na qualidade, ela normalmente medida apenas com dados frios como quantidade de erros, requisitos

30

inconsistentes ou extenso do prazo. preciso que os ofensores em todas as etapas sejam identificados para que os problemas possam ser corrigidos nas origens.

2.1.7.4

Controle de mudanas

muito reas requisitante no terem uma compreenso do impacto que mudanas geram no projeto, muitas vezes tem uma percepo superficial das questes envolvidas. Mudanas devem ser planejadas e ocorrer em blocos consistentes de evolues e correes permitindo um controle maior do custo e prazo. Mudanas impactam drasticamente no sincronismo quando existem diversas pessoas e atividades envolvidas. Toda equipe, empresa e organizao, vtima de diversos fatores externos, em rgos pblicos temos portarias, decretos, etc, que podem modificar completamente o comportamento de um sistema. Todos estrar preparados para lidar com essas situaes, e possuir capacidade de respostas geis nestes casos, no entanto, necessrio que o planejamento de mudanas de software no sejam resultados de requisitos mal levantados, seja por pouco da rea de TI ou de negcio.

2.1.7.5

Modelagem Visual

Esta a prtica enfatizada neste trabalho. Existem diversas representaes visuais que podem levar a um melhor entendimento dos requisitos e prioridades. A representao visual, em alguns casos tende a estar menos sujeita a interpretaes, por ser mais clara e representando o atual comportamento dos elementos. No caso deste trabalho sero abordadas tcnicas e conceitos para a criao de prottipos de telas para representar interaes e comportamentos do sistema, no entanto a representaes visuais podem ser de diferentes tipos, a utilizao de UML facilita a anlise de requisitos e ajuda a prever o comportamento dos vrios componentes. Diagramas de relacionamento de entidades, modelos de domnio e suas conexes tambm so artifcios que transmitem uma maior clareza do projeto. Estes artefatos permitem um entendimento mais rpido das questes que esto sendo levantadas e discutidas.

31

2.2

Dificuldades no desenvolvimento de software Atualmente possvel identificar uma srie de falhas nas dinmicas de

produo de software dentro de organizaes onde as boas prticas de engenharia de software so incompatveis e firmemente controladas pelos processos organizacionais. So de conhecimento comum a imensido de solues, processos, guias e metodologias disponveis para desenvolvimento de software. Neste trabalho me limito a apresentar apenas as prticas que considero mais relevantes dentro do aspecto governamental, com base em base nos contratos que tive acesso. De uma forma geral fica claro que a responsabilidade pela boa execuo de projeto de TI est na adequao das estratgias organizacionais e correta escolha das ferramentas a serem empregadas. A utilizao de todo o espectro de metodologias e ferramentas no se faz suficiente para a criao de uma estratgia de sucesso. preciso que as organizaes avaliem suas necessidades, e que escolham pontualmente dentro deste grande universo de opes como iro trabalhar. preciso que quando conflitantes ou incoerentes com a realidade, os processos e ambientes organizacionais sejam tambm repensados e reavaliados para que seja possvel a construo de uma base slida de gesto de TI.
The theme of this book is that interactive products need to be designed by interaction designers instead of by software engineers. This assertion often generates instant antagonism from programmers who have been doing design all along. Furthermore, these programmers fear that by taking design away from them, I'm taking away the best and most creative aspect of their work, leaving them condemned to coding drudgery unleavened with fun. This is absolutely untrue. Their worry stems only from the imprecise nature of the term design. (Cooper, 2004, p 48)

2.2.1 Governana e Segurana A burocracia de comunicao entre agncias governamentais e diferentes

32

rgos e entidades se torna barreira diria que impede a elevao da qualidade da produo softwares. A falta de canais de comunicao, simplificados e melhores elaborados, resulta em dificuldade para troca de informaes de interesse geral. Estes processos de integrao e troca de dados acabam sendo demorados, pouco prticos e com contratos rgidos que dificultam a acelerao do processo. Esta falta de integrao estratgica entre os diversos componentes da mquina pblica tambm resulta em desperdcio de recursos quando ministrios diferentes ou at mesmo departamentos de um mesmo rgo desenvolvem sistemas semelhantes que se pensados juntos, poderiam ser um s. Isto resultado da formao de ilhas de informao de interesses polticos onde a falta de cooperao existe at mesmo dentro de uma equipe pequena. Esses e demais aspectos so resultados de uma falta de interesse em compartilhar as informaes e permitir um livre acesso dados que hoje so como diamantes em forma bruta, prontos para serem lapidados em belas obras de arte. Muitas vezes vemos gestores e coordenadores que trabalham em silncio e evitam compartilhar a mesma oportunidade com outros de produzir tai belas obras simplesmente escondendo e dificultando o acesso s suas minas de informao. preciso mapear devidamente as estratgias negociais e tecnolgicas em todos os nveis organizacionais, pois s assim ser possvel uma horizontalizao da informao, ponto chave para melhores tomadas de deciso. Com uma poltica de informao pervasiva e distribuda um maior nmero de pessoas se beneficiar e melhores solues sero alcanadas Um dos grandes aspectos da terceirizao de reas de TI e diviso das responsabilidades em diversos contratos faz com que a gesto e a soluo de problemas seja lenta e pouco eficiente. Perde-se ainda muito tempo na busca por responsveis ao invs da soluo do problema. Este comportamento resulta em menor controle do rgo sobre os processos de engenharia de software colocando-o apenas como um espectador passivo do que se orquestra diante do seu olhar. Para que tais estratgias tenham a chance mais remota de sucesso o mnimo necessrio seria a alta qualificao tcnica dos responsveis por estes contratos de TI. Esta estrutura demasiadamente seccionada, redefine paradigmas de

comunicao com o mero objetivo de produo de evidncias documentais que justifiquem gastos realizados enquanto se distancia da real transmisso de

33

informaes relevantes para concluso das tarefas frente. Existe uma grande necessidade hoje de redefinio dos canais de integrao de informaes que deveriam ser compartilhadas entre rgos departamentos e equipes. Faz-se necessrio uma maior atribuio de responsabilidade aos gestores de contrato sobre a correta utilizao do errio atravs de medio constante e comprovao de melhoria dos processos de trabalho resultantes das estratgias de TI.

2.2.2 Planejamento de TI superficial e insuficiente A instruo normativa 04 define o plano diretor de tecnologia da informao como um instrumento de diagnstico, planejamento e gesto dos recursos e processo de tecnologia da informao que visa atender s necessidades de informao e um rgo ou entidade para um determinado perodo. Define ainda que o as contrataes devero ser precedidas de planejamento elaborado em harmonia com o PDTI. Apesar de este planejamento ser executado por quase todos os rgos pblicos e privados, possvel no ambiente governamental perceber facilmente atravs de simples investigao que muitos dos itens que o compe no refletem a realidades de atuao de tais rgos. Ainda falta muita experincia de planejamento como prtica constante no Brasil. A cultura de mudanas constantes e a inevitabilidade de surpresa faz com que as prticas de mercado foquem apenas no planejamento do que est logo frente ignorando muitas vezes a aplicabilidade da viso de longo prazo. A experincia e aprendizagem vm com a prtica, e s possvel avaliar a evoluo se medirmos o que aconteceu, porm prticas e mercado ad-hoc ainda so vils no aprendizado. necessria a definio de mtodos, objetivos e elaborao de tcnicas que auxiliem a construo de um plano direto de tecnologia da informao que seja slido que d a base necessria para o desenvolvimento do negcio. Muitas vezes as expectativas irreais do que possvel ou no executar junto vontade de inserir tudo de que se tem conhecimento versos a priorizao correta

34

de itens essenciais resulta em planos diretores muitos extensos que mais se assemelham a programas polticos do que estratgias organizacionais. Por um ouro lado existem tambm os casos em que se deixam de fora muitas questes essenciais pelo simples fato de ser entendida como conhecimento comum. Tal comportamento no compatvel com as necessidades de um planejamento e dificulta a orquestrao dos servios a serem realizados. O plano diretor de tecnologia da informao a principal ferramenta para alinhas a gesto de recursos de TI com as necessidades do negcio e por isso deve ser elaborado iterativamente em contato com todas as reas. Todo planejamento est sujeito a alteraes e imprevistos, por isso a esto de risco tambm se faz necessria neste processo, porm uma proposta bem elaborada, que considera todos os aspectos da organizao, com plano de ao consistente que busque capacitar pessoal da rea de TI e negcio e esteja compatvel com o oramento disponvel, tero maiores condies de sucesso e satisfao dos envolvidos no alcance de seus objetivos.

2.2.2.1

Modelo Cascata de desenvolvimento de software

O modelo de desenvolvimento em cascata um dos grandes viles na construo de software, apesar de termos visto o grande foco das metodologias em processos iterativos, este modelo prev o encadeamento de disciplinas tentando esgot-las por completo antes de mover o projeto adiante. Neste modelo define-se o escopo total do software a ser desenvolvido e na sequncia usurios e analista preparam toda a especificao que por sua vez inteiramente repassada aos programadores que criam o cdigo, este cdigo testado, e colocado em produo. Isto ocorre de uma forma linear. Esta forma traz uma srie de problemas conhecidos, muitas vezes os usurios s conseguem ter uma visibilidade maior de como dever ser o comportamento do sistema quando tem uma chance de interagir com estes. As documentaes tcnicas possuem um nvel de abstrao que no garantem inequivocamente o mesmo entendimento pelas partes fazendo com que

programadores que desconhecem as informaes negociais construam cdigos de acordo com suas interpretaes. Como um processo linear e uma parte do projeto s acontece aps a concluso da anterior muitas vezes fica invivel a realizao de

35

alteraes pelo impacto e custo gerado em etapas mais frente. Nestes casos, muitas vezes apenas no meio do desenvolvimento, usurios e analistas descobrem percebem que o projeto poderia ser feito inteiramente diferente. Apesar de ser um modelo tecnicamente em desuso e tendo o RUP e XP como grandes adversrios, possvel perceber que se trocam os nomes mais ainda trabalha-se da mesma forma. O modelo em cascata seria nada mais nada menos que a execuo de um projeto inteiro dentro de apenas uma iterao do RUP, e apesar de hoje em dia o RUP ser amplamente utilizado a forma de contratao de fbricas de software para rgos governamentais seguem so incrivelmente rgidos em seu controles de aprovao de mudanas e de anlise de impacto que apesar de se desenvolver o software iterativamente o impacto de custos e prazos faz com que as vantagens do desenvolvimento iterativo no possam ser percebidos. Uma forma de lidar melhor com requisitos que de software que evoluem conforme o software vai sendo construdos tirar proveito das ferramentas providas por metodologias geis e ter cuidado redobrado com o os controles de mudana e anlise de impacto para que estes permitam real liberdade e flexibilidade. indicado durante o desenvolvimento iterativo a constante construo de prottipos, reavaliao dos fluxos de processos e a priorizao levando em considerao a relao do custo benefcio presente no que pode ser entregue rpido versus o que mais significante para o cliente. Para que estas prticas produzam os frutos esperados importante que os usurios futuros sejam sempre que possvel consultados e que possam entrar em contato com o que est sendo desenvolvido, para que os feedbacks possam ser levados em considerao j nas partes iniciais do projeto.

2.2.2.2

Recursos Abundantes ou Insuficientes

Em rgos governamentais a proliferao de projetos nacionais de larga escala uma parte comum ao dia-a-dia, porm projetos grandes, possuem grandes riscos. Em tecnologia da informao temos problemas comuns como eles se tornarem obsoletos durante o processo ou at mesmo o surgimento de uma ferramenta ao longo do caminho que poderia ser aproveitada. No setor privado projetos de larga escala costuma ser meticulosamente

36

medidos e avaliados financeiramente para que possa ser possvel a rpida identificao se ele se encontra em curso ou no. No setor pblico, como os projetos de software so iniciados sabendo-se que existe oramento necessrio para a concluso, no comum um acompanhamento sobre o desempenho do projeto, permitindo que projetos que esto enfrentando problemas continuamente e fora de curso continuem sendo pagos. Projetos no setor privado costumam ter um financiamento at apenas o primeiro marco, onde este dever provar sua rentabilidade e no caso de algo errado, o projeto poder ser cancelado enquanto no se gastou muito dinheiro.
It's harder than you might think to squander millions of dollars, but a flawed software-development process is a tool well suited to the job. That's because software development lacks one key element: an understanding of what it means to be "done." Lacking this vital knowledge, we blindly bet on an arbitrary deadline. We waste millions to cross the finish line soonest, only to discover that the finish line was a mirage. (Cooper, 2004, p 73)

No setor pblico, como difcil recorrer a financiamento ms a ms ou ano a ano, a estratgia costumam ser conseguir a verba necessria para o projeto inteiro. Muitas vezes o projeto pode ficar muito grande e muito caro antes que algum possa ter uma chance de avalia-lo.
Badly designed business software makes people dislike their jobs. Their productivity suffers, errors creep into their work, they try to cheat the software, and they don't stay in the job very long. Losing employees is very expensive, not just in money but in disruption to the business, and the time lost can never be made up. Most people who are paid to use a tool feel constrained not to complain about that tool, but it doesn't stop them from feeling frustrated and unhappy about it. (Cooper, 2004, p87)

2.2.2.3

Experincia dos profissionais de TI

A gama de formaes acadmicas na rea de TI relativamente ampla e composta por diversas especializaes, porm a profisso ainda relativamente nova e o conhecimento est sendo construdo constantemente. Sendo uma das reas profissionais que mais cresce, fcil perceber o

37

impasse entre a grande quantidade de profissionais inexperientes e a grande demanda de servios resultando diretamente numa ascenso financeira rpida. O elevado nvel de rotatividade, aliado aos altos salrios praticados no mercado privado tornam a atuao no setor pblico pouco desafiadora para alguns, alm da oportunidade de atuar em projetos que podem no oferecer grande realizaes profissionais. Vemos junto a rgos pblicos, profissionais que buscam certa estabilidade proporcionada pelo ritmo imposto nas organizaes governamentais. A busca por ambientes de trabalhos mais desafiadores onde as horas extras so constantes e os prazos extremamente apertados se torna vantajosa quando a recompensa grande, e estes so os dois lados do espectro de motivao profissional nesta rea de TI. Seja a recompensa financeira, ou atuar em algo que envolve outros aspectos emocionais, de fato o setor pblico sofre em ambos. Quanto questo curricular dos servidores pblicos, a carncia de concursos pblicos e renovao e aumento de equipes de TI em rgos pblicos se torna mais nocivo ainda para o ambiente organizacional. O Estado tem buscado uma atualizao profissional promovendo concursos constantemente, porm as vagas ainda so poucas e se apoia fortemente na terceirizao como forma de suprir as necessidades.

2.2.2.4

Capacidade de atendimento

Influenciado por um plano diretor de tecnologia da informao que pode ou no representar corretamente as necessidades do rgo ou entidade, a capacidade de atendimento seja hardware, software ou funcionrios fica comprometida. As empresas terceirizadas em rgo governamentais utilizaro o plano diretor como fonte de insumo para o dimensionamento de suas equipes. Tal planejamento costuma funcionar como a base do planejamento destas empresas. Quando este planejamento mal executado, isto aumenta os riscos fazendo com que tais empresas dimensionem incorretamente suas equipes e prejudiquem a capacidade de atendimento. comum em tais ambientes que as pessoas envolvidas nas reas requisitantes desconheam totalmente o contrato destas empresas terceirizadas, o que me si no um problema, mas quando as diretorias de TI no dominam os

38

aspectos do contrato e no auxiliam as reas requisitante clarificando a questes de prazo e custos , o problema de comunicao cresce. Para reas requisitantes, os processos de TI devem ser transparentes, no entanto, suas demandas esto subordinadas a algumas caractersticas contratuais que devem ser sempre expostas. Muitas vezes possvel perceber uma sequncia de picos e vales nas solicitaes de demandas, e isto extremamente nocivo para uma empresa terceirizada que hora tem que inflar suas frentes de trabalho e hora deve operar com mnimo possvel de profissionais. Como apresentado anteriormente, existe uma grande carncia de

profissionais experientes, e muitas vezes a busca por um profissional adequado pode levar meses. Como nem sempre possvel esperar meses para contratar um profissional no caso de aumento repentino de demandas, opta-se por profissionais com o mnimo do conhecimento necessrio para o desempenho do trabalho. O reflexo deste tipo de atitude fica claro assim que os trabalhos comeam a ser executados e a velocidade de progresso do projeto deixa de agradar os stakeholders.

2.2.3 Domnio do Escopo A rotatividade de profissionais em rgos governamentais e a troca de gestores e consultores que costuma ocorrer dados diferentes vieses polticos que as organizaes possam sofrer acarretam em uma falta de domnio do escopo. A abertura e solicitao de software s deve ser feita aps a definio de mapeamento de processos, leis, decretos, portaria, instrues normativas, etc, sero contempladas no software. O trabalho das reas requisitantes (reas de negcio) possui um entendimento por completo do negcio. A falta de organizao prvia, faz com que processos de anlise de requisitos se tornem na verdade anlises de negcio. Os objetivos estratgicos da organizao, departamento ou equipe devem estar consonantes, e deve-se ter uma ideia clara das expectativas do que ser feito. Solicitaes de software em momentos onde o domnio dos processos ainda imaturo e insipiente resulta em muitas modificaes de anlise de requisitos ou ate

39

mesmo durante a construo. Este tipo de atitude impacta drasticamente prazos e custos dos projetos, e muitas vezes o produto final acaba no atingido as expectativas e tendo sua adoo prejudicada. necessrio o domnio do processo de trabalho para que ento seja possvel o fechamento rpido do escopo de trabalho a ser feito.

2.2.3.1

Processos de Trabalho

A origem de demanda para a criao de um determinado software geralmente nasce da necessidade de automatizao de algum processo de trabalho, porm muitas vezes a total transposio do processo empregado para uma automatizao via software pode se tornar o motivo principal do fracasso de um projeto. No mundo fsico interagimos de forma diferente com os objetos aos nosso redor e um dos grandes aspectos do dia-a-dia de trabalho que quase sempre conseguimos reordenar ou burlar processo de acordo com as necessidades especiais que surgem. Quando automatizamos um processo de trabalho em um software, muitas vezes perdemos esta flexibilidade possvel anteriormente e isto tende a frustrar usurios. Ao criar um software, preciso que o processo de trabalho seja totalmente repensado e analisado para que se tire o maior proveito da automatizao delegando ao software apenas as tarefas que sero mais bem desempenhadas dentro deste ambiente controlado digital. preciso levar em considerao que os processos de trabalho dentro de organizaes nem sempre so repensados periodicamente ou analisados e otimizados para melhor desempenho. A anlise dos processos de trabalho de uma organizao deve ocorrer periodicamente para que seja possvel avaliar questes de desempenho e adequao do trabalho realizado em relao a viso que existe sobre o processo empregado. Nos casos que estas reavaliaes so feitas obtm-se dados mais objetivos para que os processos possam ento ser mudados. importante entender que se os processos de trabalho no esto adequados ou otimizados a automatizao deles trar um retorno muito menos do que o esperado. Antes de pensarmos em software precisamos pensar nos processo de

40

trabalho, e por isso o estreitamento entre reas de TI e negcio essencial para formulao de uma estratgia de sucesso.

2.2.3.2

Escopo Extensivo

Pelas questes contratuais abordadas anteriormente e questes de financiamento a opes por incluso de tudo que se imagina possvel para o software dentro do escopo faz com que este fique muitas vezes com um tamanho extenso demais e difcil de controlar. Quando o escopo de projeto fica cada vez maior e no existe uma governana adequada para tomada de decises de corte, e definio do que poder ficar para uma release posterior, o projeto tende a caminhar a passos lentos. Uma boa forma de lidar com este problema planejar a entrada de novas funcionalidades gradualmente para que as pessoas envolvidas se sintam confortveis sabendo em qual momento a funcionalidade entrar na linha de produo e de que nada ficar de fora. O desenvolvimento iterativo e incremental a melhor forma para conduzir projetos extensos de TI. Desta forma ser possvel o constante replanejamento e aplicao de mudanas que se fizerem necessrias.

2.2.4 Envolvimento dos Stakeholders Para qualquer projeto de sucesso, o envolvimento dos stakeholders se faz essencial para o sucesso. Estes devem ter o domnio do conhecimento necessrio para alcanar os objetivos estabelecidos. Estes devem ter a capacidade de deciso sobre aspectos crticos do projeto assim como saber quando aceitar a viso das partes tcnicas quando necessrio. Projetos conduzidos dentro de ambientes organizacionais grandes podem possuir partes interessadas em diversos nveis hierrquicos e reas distintas, tornando muitas vezes difcil o consenso sobre o caminho a ser seguido. imperativo que as estruturas de controle dentro do projeto estejam devidamente evidenciadas e que as tomadas de deciso no dependam de todos os envolvidos, foras tarefas podem se torar muito extensas dificultando muitas vezes at a conciliao de horrios para reunies.

41

As pessoas envolvidas no projeto devem ter conduta colaborativa e responsabilidades, porm muitas vezes, dentro das atribuies das reas requisitantes, estas podem apresentar menor disponibilidade para lidar com o assunto. Quando isto ocorre o projeto como um todo sofre, e muitas vezes precisam ser traadas novas estratgias de comunicao. A formao de comits gestores pode ser identificada como um dos primeiros passos para o fracasso de uma estrutura de tomada de decises em projetos de software. Na formao de comits gestores, muitas vezes o interesse poltico em satisfazer todas as reas e falta de uma liderana com domnio total de assunto faz com que projetos patinem e, no entanto seja mantida a ideia de progresso. Durante qualquer projeto de software importante que os responsveis por cada parte estejam devidamente identificados permitindo uma eficincia maior na obteno de informaes e na tomada de decises.
Design, Usability, Industrial Design, Ethnography, Marketing, and so on. We do not have to start from scratch. Second, no individual will or can have equal competence in all the requisite skills. So the second thing to keep in mind is that we need coverage of the larger skill set distributed among a heterogeneous team, not the individual. But, and this is the important but, for that team to function well, the players must have at least basic literacy in each others specialties, if not a high level of competence. (Buxton, 2007, p 231)

Questes de interesse poltico permeiam todo e qualquer ambiente governamental, no desenvolvimento de sistemas importante um cuidado redobrado em ambientes instveis. A solicitao de um novo sistema por um gestor que possua uma viso, pode ser completamente esquecida no caso da troca deste gestor por outro com viso oposta. Levando em considerao o tempo para desenvolvimento de um grande sistema e pode facilmente ultrapassar um semestre, faz com que o risco de cancelamento aumente onde a troca de liderana ocorre com frequncia. A motivao para construo de um sistema, assim como uma obra pblica pode ter interesses escondidos de agradar a um determinado pblico-alvo. Neste caso fica a cargo das diretorias de TI sempre se certificarem que os projetos de novos sistemas esto de fato de acordo com o planejamento estratgico do rgo ou secretaria, impedindo assim que pessoas tirem proveito de situaes particulares.

42

Para que se tenha um ambiente produtivo importante o comprometimento de stakeholders com os objetivos da organizao e que ento apresentem a disponibilidade necessria para conduo dos projetos. O domnio tcnico e desligamento de questes polticas faz com que a tomada de decises seja mais assertiva dando uma maior liderana em qualquer situao.

2.2.5 Problemas de Comunicao Um dos maiores problemas de gesto de projeto seja em TI ou em outras reas causado por dificuldades de comunicao. O PMBoK possui uma rea de processos apenas para planejar a comunicao dentro do projeto. Independente do tamanho do projeto, sempre haver mais de uma pessoa envolvida e quanto maior o projeto, maior ser nmero de pessoas envolvidas. importante identificar as partes interessadas, planejar o que ser comunicado e como ser comunicado. A correta definio dos caminhos para distribuio da informao passo fundamental para garantir que todas as partes interessadas tero sempre em mos os insumos necessrios para a tomada de decises. Conforme o projeto progride importante que as partes envolvidas tenham total conhecimento do desempenho do trabalho. Uma boa forma de gerenciar as expectativas dos stakeholders comunicar pro ativamente os obstculos e solues empregadas na conduo do projeto. Seguindo essas prticas evita-se que responsveis e partes interessada sejam surpreendidos ou rendidos em frente a problemas de projeto.

2.2.6 No atendimento das expectativas As expectativas de reas requisitantes de software costumam apresentar grande dificuldade de gesto, pois muitas vezes estas desconhecem todo o processo de requisio de software o tempo necessrio para os trmites dentro dos modelos de contratao. Podem existir dificuldade de assimilao da documentao tcnica produzida por escritrios de projeto ou fbricas de software quando estas reas requisitante

43

possuem pouco conhecimento sobre desenvolvimento de software. O crescente nmero de ferramentas online mantidas por grandes corporaes faz com que clientes em momentos percam a referencia do que possvel ou no ser feitos dentro de prazos e cronogramas estipulados. Nas reas de negcio dentro de organizaes normal que todo o contedo destas metodologias de gesto, governana e desenvolvimento sejam totalmente desconhecidos. Domnio obre questes contratuais dentro de rgos

governamentais tambm se tornam penosos para reas que no possuem a devida orientao ao realizar suas demandas.

2.2.6.1

Tempo

Atualmente, cada vez mais reforado por rgos auditores, a anlise de ponto de funo tem se tornado uma forma amplamente utilizada para clculo de custo e prazo em rgos governamentais. Apesar desta medida de engenharia em linhas gerais permitir a identificao de aspectos simplrios de um software dificilmente conhece retratar as questes organizacionais e possveis situaes de complexidade que impactam prazos e custos. Normalmente a constante de tempo dinheiro no prevalece em projetos governamentais. claro que quanto mais longo for um projeto, teoricamente maior ser seu custo, mas a realidade de mudanas imediatas em polticas de governos, novas leis ou mudanas estratgicas requerem uma resposta rpida. comum a frustrao entre reas de negcios e demais clientes de TI, quando o assunto o tempo necessrio para o atendimento de uma demanda ou concluso de um projeto. Como apresentado possvel perceber que grande parte das metodologias que se encontram em uso dentro de grandes organizaes so repletas de processos e possuem diversos controles que tornam todo o andamento consideravelmente mais lento. O ganho de controle sobre o processo muitas vezes no agrega valor as expectativas do cliente e reas de negcio que desejam um servio funcionando sem se importar com o que suporta este servio.

44

2.2.6.2

Melhoria do Processo de Trabalho

pouco comum a medio dos processo de trabalho antes e depois de automatizao e incio da utilizao de algum produto de software. Quando se trata de hardware, muitas vezes a evoluo clara seja na reduo de custos com adoo de VOIP ou utilizao de vdeo para reunies a distncia o benefcio mais bvio. Para avaliar as melhorias no processo de trabalho ao se empregar uma nova ferramenta de software, necessrio que antes da mudana haja alguma forma de coleta de dados. Na maioria dos casos no existe o interesse em uma medio destas informaes tornando invivel a obteno de dados objetivos sobre a melhoria ou no decorrente do uso de uma nova ferramenta. A questo dos diversos processo que impactam o tempo tambm criam muitas amarras e dificuldades de mudana de escopo durante a produo, como existe uma segmentao das tarefas e foco em diferentes profissionais, o conhecimento fica distribudo. O levantamento das necessidades pode envolver diversas pessoas da rea de negcio cada uma com o domnio parcial do negcio, assim como diferentes profissionais de TI responsveis por diferentes etapas das metodologias propostas dificultando a transmisso correta do conhecimento criando o efeito de um telefone sem fio. Esta informao que se perde e se modifica conforme transita de um envolvido para outro, muitas vezes corrompe o escopo e na falta de um responsvel centralizador com o domnio total do conhecimento necessrio do negcio, que tenha condies de valida a documentao gerada na rea TI, pode resultar em software que no se adequa aos processos de negcio e no atende as necessidades. Outro aspecto de adequao e melhoria dos processos da rea de negcio que importante considerar trata da questo da otimizao dos processos antes do desenvolvimento de uma ferramenta. Muitas vezes o cliente possui um envolvimento muito grande com os processos de trabalho e por estar demasiadamente acostumando no foca na melhoria destes processos antes de iniciar o desenvolvimento de um software, automatizando e sistematizando um processo de trabalho ineficiente. No momento e iniciar um novo projeto de software essencial que os

45

processo de trabalho que sero tratado pela ferramenta sejam repensados e sempre que possveis automatizados pela nova dinmica de trabalho. comum a resistncia na mudana de processos de trabalho porm o mapeamento dos processos existentes sem a correta avaliao de seus desempenho pode ser a receita para um software que deixar de atingir todo seu potencial de melhoria.

2.2.6.3

Qualidade

Seguindo a premissa que a qualidade est diretamente envolvida com a entrega do que foi acordado, nem sempre este aspecto representa uma inadequao no atendimento das expectativas. Muitas vezes a subjetividade de assuntos abordados em engenharia de software aliados ao pouco domnio tcnico por parte de reas requisitantes dificultam a anlise do impacto e os obstculos das demandas realizadas. A qualidade na produo de softwares muito subjetiva e depende de diversos fatores como a adequao dos processos de negcio onde o cliente o maior responsvel, na correta codificao e projeto que cuja fbrica a maior responsvel e diversos outros aspectos subjetivos como usabilidade, acessibilidade, e infra estrutura disponveis.

46

3-

ASPECTOS DA EXPERINCIA DO USURIO

Neste captulo sero apresentados alguns aspectos conceituais, tcnicas e

teorias que afetam como um todo a experincia do usurio. So conhecimentos amplamente aplicados no projeto de interfaces de produtos de software ou industriais.
User interfaces originated with the very first computers in the form of cathode ray tube displays showing base 32 arithmetic for output and plug boards for input. Programming was thus like rewiring the hardware and interpreting the magic symbols that came out. The early machines also made a noise so that experienced operators could guess what sort of thing they were doing and detect abnormalities such as endless loops (a constant whirring sound). (Graham, 2003, p38)

O reflexo da evoluo tecnolgica nos elementos da nossa vida diria nos coloca hoje em uma situao onde a alfabetizao tecnolgica se torna necessria e essencial para que possamos interagir com este novo mundo. Estes aspectos podem ser percebidos na utilizao de telefones celulares, terminais de autoatendimento de bancos, liquidificadores, carros e tudo mais que nos rodeia. Para que a interao seja possvel sem conflitos, existem diversos aspectos cognitivos que devem ser levados em considerao no desenvolvimento de softwares governamentais.
Sadly, our digital tools are extremely hard to learn, use, and understand, and they often cause us to fall short of our goals. This wastes money, time, and opportunity. As a business-savvy technologist / technology-savvy businessperson, you produce software-based products or consume themprobably both. Having better, easier-tolearn, easier-to-use high-tech products is in your personal and professional best interest. Better products don't take longer to create, nor do they cost more to build. The irony is that they don't have to be difficult, but are so only because our process for making them is old-fashioned and needs fixing. Only long-standing traditions rooted in misconceptions keep us from having better products today. This book will show you how you can demand and getthe better products that you deserve. (Cooper, 2004, p16)

Uma preocupao que tm crescido como um todo no projeto de novas ferramentas e produtos a da experincia do usurio como um todo. Como ele responder emocionalmente aos estmulos destas ferramentas e produtos, e

47

principalmente como ser sua interao.

3.1

Desenvolvimento Tecnolgico A tecnologia avana a passos largos, e muitas vezes se torna complicado

acompanhar todas as ramificaes desta evoluo. Para isto necessrio que de tempos em tempos realizemos uma anlise de onde nos encaixamos. A uma taxa exponencial, os produtos antes percebidos como analgicos esto sendo digitalizados, a um exemplo forte deste efeito, temos as cmeras fotogrficas, telefonia celular, e at mesmo chaves de nossos carros j recebem componentes eletrnicos. A forma como esta digitalizao realizada, muitas vezes ignora comportamentos a muitas geraes estabelecidos, redefinindo nossa forma de acessar informao e interagir com ambiente ao nosso redor. H alguns anos atrs as formas mais comuns de interagir com um computador envolvia apenas um teclado e mouse, no entanto hoje em dia nossa temperatura, gestos e nosso simples olhar j fornece informaes para controlar os objetos ao nosso redor. Hoje temos mquinas fotogrficas que detectam sorrisos, softwares que identificam amigos automaticamente e j possvel controlar programas de computador apenas com o pensamento. Para que possamos projetar softwares que interagem com seres humanos, precisamos ter sempre em mente a necessidade de definir com cuidado como sero estas interaes.
In December 1995, American Airlines Flight 965 departed from Miami on a regularly scheduled trip to Cali, Columbia. On the landing approach, the pilot of the 757 needed to select the next radio-navigation fix, named "ROZO." He entered an "R" into his navigation computer. The computer returned a list of nearby navigation fixes starting with "R," and the pilot selected the first of these, whose latitude and longitude appeared to be correct. Unfortunately, instead of "ROZO," the pilot selected "ROMEO," 132 miles to the northeast. The jet was southbound, descending into a valley that runs north south, and any lateral deviation was dangerous. Following indications on the flight computer, the pilot began an easterly turn and slammed into a granite peak at 10,000 feet. One hundred and fifty-two passengers and all eight crewmembers aboard perished. Four passengers survived with serious injuries. The National

48

Transportation Safety Board investigated, andas usualdeclared the problem human error. The navigational aid the pilot was following was valid, but not for the landing procedure at Cali. In the literal definition of the phrase, this was indeed human error, because the pilot selected the wrong fix. However, in the larger picture, it wasn't the pilot's fault at all. (Cooper, 2004, p24)

Quando se trata do desenvolvimento de software para rgos governamentais importante que as interaes induzam ao uso correto, minimizando erros de utilizao, facilitando treinamento principalmente evitar desgastes gerados por interaes mal projetadas.

3.2

O Design centrado no usurio O design centrado no usurio um processo onde as expectativas,

necessidades e limitaes do usurio final de um produto so amplamente analisadas e recebem uma ateno especial durante as fases de projeto. Esta prtica caracterizada por diferentes estgios na soluo de problemas onde designers trabalham tanto na anlise buscando perceber a real necessidade do usurio, mas tambm testando a validade destas suposies considerando comportamentos e testes realizados com os usurios finais. A grande diferena nesta prtica, est no fato de se apoiar no desenvolvimento de produtos que se adaptam as necessidades dos usurio ao contrrio do desenvolvimento de produtos que foram com que os usurios se adaptem. Esta segunda prtica bastante comum em organizaes com problemas de comunicao, onde as solues adotadas pelas diretorias no reflete as reais necessidades do trabalho realizado pelos usurios na base da pirmide. Esta prtica fica mais evidente quando tratamos de rgos governamentais que tendem a ter vises discrepantes entre a matriz central localizada na capital e os demais postos localizados espalhados no territrio nacional. Na prtica de projetos centrados no usurio comum que sejam identificados os requisitos inicias junto aos clientes (reas requisitantes) e estes sejam posteriormente refinados atravs de uma anlise investigativa utilizando tcnicas como: pesquisa etnogrfica, questionamentos contextuais, validao de prottipos, testes de usabilidade, entre outros.

49

comum a utilizao de outros mtodos que sero abordados neste trabalho tais como: card sorting, mapas conceituais, diagramas de afinidade, e sesses de brainstorming. uma prtica muito comum tambm a anlise de ferramentas existentes como pontos de partida. A realizao de benchmarks costuma auxiliar consideravelmente o processo de investigao por permitir a medio de solues em uso.
Card sorting studies can provide insight into users' mental models, illuminating the ways they often tacitly group, sort, and label tasks and content within their own heads. The simplicity of this method confers tremendous flexibility. In the earliest phases of research, you can employ exploratory, open-ended card sorting methods like the one we just described. Later on, you can use closed card sorts in which users rely on your predefined labels to question or validate a prototype information architecture. You can also instruct users to sort the cards according to what's most important to them; they can even have a pile for "things I don't care about." The permutations are infinite. (Rosenfeld, 2002, p261)

Estas prticas de projeto, com foco no usurio, seu meio, seu ambiente, suas necessidades, suas expectativas e objetivos, seus desejos, e demais aspectos relacionados ao usurio, so os elementos base do design centrado no usurio.

3.3

Aspectos da Experincia do Usurio Existem inmeros fatores que influenciam a experincia do usurio ao

interagir com um produto, seja de software ou fsico. O objetivo desta seo apresentar superficialmente alguns destes fatores, permitindo assim a criao de uma base conceitual para a prototipao gil.
There are many different ways of interacting with a computer system. These include menus, forms, command languages, natural language and GUIs. As with input and output devices, the best style of interaction depends mainly on the task being undertaken. There is no generic best style. (Graham, 2003, p43)

3.3.1 Usabilidade

50

A usabilidade esta relacionada facilidade de uso e aprendizado de um produto de software. Este aspecto deve ser constantemente avaliado tanto em projetos novos como em projetos existentes. Uma viso geral que produtos projetados considerando questes psicolgicas e fisiolgicas dos usurios sero mais eficientes, necessitaro de menos tempo para atingir seus objetivos, sero de fcil aprendizado e ser mais agradvel de utilizar.
In order to design a good user interface, it is necessary to know a little about the way the human mind and body work. In particular it is useful to know how memory storage and retrieval works, how the eye responds to colors, what positions lead to fatigue, and so on. The bodily aspects of humancomputer interaction are often referred to as ergonomics, though strictly this subject encompasses the mental aspects as well. (Graham, 2003, p44)

No dia-a-dia de nossas vidas modernas, precisamos lidar com produtos de software o tempo todo, e normalmente recorremos aos que nos adaptamos melhor, porm nem sempre temos escolha. Quando tratamos de editores de texto e imagens, ferramentas de e-mails, entre outros, as opes so inmeras. Porm quando tratamos do website do banco, ou na compra de passagens areas, somo obrigados a lidar com o que oferecido. Usabilidade bastante explorada em sites que envolvem compras como sites de leiles e lojas virtuais, pois impactam drasticamente na capacidade do usurio de realizar ou no uma compra. Muitas vezes ferramentas mal desenvolvidas nestes mercados podem resultar na perda de milhes. Quando tratamos da produo de softwares para rgos governamentais, sabemos que os usurios usaro o que for designado a eles, e por isso muitas vezes a usabilidade deixada de lado. Muitas vezes pelo pouco interesse das fbricas de software ou a falta de maior conhecimento das reas requisitantes, os benefcios da boa usabilidade no so considerados. A usabilidade de um software impacta muitos fatores da experincia do usurio tais como: aprendizado, eficincia do trabalho, memorizao, erro e satisfao.
It is crucial that the interface designer, like the software

51

engineer, does not stop at analyzing and automating existing manual practices. Computers can change the tasks they were designed to assist with, and this is often their largest contribution. Word processing has largely changed the nature of work in many offices and the impact of the web continues the trend. (Graham, 2003, p46)

Quando o software possui boa usabilidade, muitas vezes o usurio consegue perceber qual caminho seguir para atingir seus objetivos. Desta forma possvel minimizar custos de treinamento. Se um software fcil de entender, tambm ser mais fcil de ser utilizado. Muitas vezes questes de usabilidade so responsveis por aumento da produtividade de funcionrios simplesmente por permitir que o trabalho seja realizado de forma mais rpida e fcil. A consistncia de um software em seus comportamentos, e a clareza que a boa usabilidade pode ocasionar faz com que o usurio final no se esquea completamente aps longo tempo sem utiliz-lo. A usabilidade pode ser questo fundamental na ocorrncia de erros humanos, como preenchimentos indevidos ou incorretos. Quando a usabilidade levada em considerao possvel identificar e minimizar os erros gerados pelos usurios. A usabilidade de um software pode ser medida com seu uso, atravs de testes de usabilidade que avaliam estes aspectos apontados. Aps anos avaliando a usabilidade de software foi identificado que muitos dos erros podem ser agrupados em categorias comuns.
Evaluation of the user interface is very important. HCI reviews and expert walkthroughs are usually enormously useful. Other valuable evaluation techniques include questionnaires, observational studies and test script reports. Useful GUI metrics include the time it takes to learn an operation or to use a whole system, the time it takes to carry out a particular task, the average users error rate, satisfaction indices and the skill retention over time. These metrics imply that a budget for experimentation and data collection should be created. Also, it should be noted that the existing system should be measured with respect to these metrics during requirements capture if the metrics are to be of use in assessing benefits. (Graham, 2003, p53)

52

3.3.1.1 Heursticas de Usabilidade O processo de avaliao heurstica de Jakob Nielsen se utiliza de 10 categorias, ou heursticas que auxiliam na identificao de problemas de usabilidade. importante entender que heursticas no so regras objetivas e se comportam mais como aspectos subjetivos.

3.3.1.1.1

Visibilidade do Status do Sistema

preciso que o usurio possa a qualquer momento saber o que est fazendo, onde se encontra e qual o status de sua tarefa. O sistema precisa prover opinio constante das aes do usurio. Se este solicita um relatrio o sistema deve avisar que o relatrio est sendo processado. Se for importante saber dia e horrio corrente, esta informao deve estar sempre apresentada ao usurio. As informaes que o usurio mais necessita sobre o comportamento do sistema e para atingir as suas metas devem estar sempre facilmente acessveis.
One of the best ways to make a page easy to grasp in a hurry is to make sure that the appearance of the things on the pageall of the visual cuesclearly and accurately portray the relationships between the things on the page: which things are related, and which things are part of other things. In other words, each page should have a clear visual hierarchy. (Krug, 2006, p31)

3.3.1.1.2

Compatibilidade entre a interface do sistema e o mundo real

importante que o sistema sempre utilize as mesmas metforas, taxonomias e comportamentos existentes no mundo real. Caso estejamos aperfeioando um processo de trabalho o sistema deve emular o mesmo processo de trabalho, facilitando assim o reconhecimento do usurio.
All conventions start life as somebodys bright idea. If the idea works well enough, other sites imitate it and eventually enough people have seen it in enough places that it needs no explanation. This adoption process takes time, but it happens pretty quickly on the Internet, like everything else. For instance, enough people are now familiar with the convention of using a metaphorical shopping cart on e-commerce sites that its safe for designers to use a shopping cart icon without labeling it Shopping cart. (Krug, 2006, p34)

53

Esta tcnica amplamente utilizada por lojas virtuais onde vemos as metforas de carrinho de compras, este um exemplo clssico da vida cotidiana, onde selecionamos diversos itens e depois procedemos ao caixa para finalizar uma compra.

3.3.1.1.3

Controle do usurio e liberdade

importante para o usurio que este tenha facilidade em controlar aes como desfazer ou refazer tarefas. Em todos os casos o usurio deve ter sadas fceis para cancelar qualquer ao que esteja realizando. Deve ser possvel que o usurio, por exemplo, possa selecionar outro assento no nibus ou avio antes de confirmar, e que no seja seu primeiro clique que defina essa interao. Um exemplo mais comum seria a facilidade em adicionar ou remover unidades de um determinado item em um carrinho de compra. Sempre que possvel o usurio deve ter o maior controle possvel sobre o sistema, e quando aplicvel no ser limitado a uma sequncia nica para correta execuo de uma tarefa.

3.3.1.1.4

Consistncia e Padres

Deve-se certificar que por todo o sistema coisas semelhantes se comportem de maneira semelhante. Este aspecto bastante perceptvel quando utilizamos muitos elementos visuais para auxiliar os usurios pelo sistema. importante que os elementos sejam consistentes, se for decidido que na interao de excluso de itens o sistema dever solicitar a confirmao, este comportamento dever estar presente no sistema inteiro.
The Home page has to give an overview of what the site has to offerboth content (What can I find here?) and features (What can I do here?)and how its all organized. This is usually handled by the persistent navigation. (Krug, 2006, p95)

Quanto maior for o nmero de excees presentes no sistema, mais difcil ser o aprendizado, e maiores sero as chances de erros. Muitas excees tambm dificultam o processo de memorizao do sistema.

54

3.3.1.1.5

Preveno de erros

O sistema deve buscar auxiliar o usurio na preveno de erros. Quanto mais comum for a probabilidade de ocorrncia de um erro por parte do usurio, mais preparado o sistema dever estar para evitar tal erro.
Testing always works, and even the worst test with the wrong user will show you important things you can do to improve your site. I make a point of always doing a live user test at my workshops so that people can see that its very easy to do and it always produces an abundance of valuable insights. I ask for a volunteer and have him try to perform a task on a site belonging to one of the other attendees. These tests last less than ten minutes, but the person whose site is being tested usually scribbles several pages of notes. And they always ask if they can have the recording of the test to show to their team back home. (One person told me that after his team saw the recording, they made one change to their site which they

later calculated had resulted in $100,000 in savings.) (Krug, 2006, p134)

Um forte exemplo est na utilizao de mscaras para preenchimento de dados como telefones, CPF, e-mails alm de campos obrigatrios. Podemos ver dois grandes exemplos desta heurstica em ferramentas de e-mail, a maioria delas pergunta ao usurio se este deseja realmente enviar uma mensagem sem assunto ou sem contedo quando estes dados no se encontram preenchidos. O GMAIL vai alm e caso detecte palavras indiquem a presena de um possvel anexo, ele avisa ao usurio caso nenhum arquivo tenha sido anexado.

3.3.1.1.6

Reconhecimento ao invs de lembrana

mais eficiente contar com a capacidade dos usurios de reconhecer um determinado item ou comportamento ao invs de contar com que estes relembrem de algo especfico. Uma forma interessante de auxiliar utilizar elementos visuais, dicas e ajuda. Outra forma interessante de trabalhar esta heurstica permitir que o usurio consiga visualizar facilmente suas opes e informaes necessrias para concluso da atividade que est desempenhando.

55

3.3.1.1.7

Flexibilidade e eficincia de uso

Um sistema bem projetado deve sempre permitir uma operao mais gil por usurios mais experientes, seja atravs de teclas de atalho ou customizao de interfaces. Um bom exemplo desta liberdade o software igoogle, que em sua forma simples permite que o usurio crie o ambiente da forma que melhor lhe agrada. Muitas vezes no atentamos ao fato que a prpria ordenao de itens em um menu de navegao pode agilizar a operao de um software. O agrupamento de itens semelhantes, a ordenao de acordo com sequncia de uso e posicionamento de itens mais utilizados em lugar privilegiado pode acelerar consideravelmente a utilizao de uma ferramenta no dia-a-dia.

3.3.1.1.8

Esttica e design minimalista

O contedo disponibilizado para o usurio deve refletir suas necessidades e servir para que este alcance seus objetivos. Devem-se reduzir ao mximo as informaes desnecessrias e a redundncia de itens que no sejam realmente importantes.

3.3.1.1.9

Ajuda na identificao, diagnstico e recuperao de erros.

Os erros do sistema devem ser facilmente reconhecidos pelos usurios, o usurio precisa ser alertado se possvel e sempre poder perceber quando algo no ocorreu como esperado. importante que os erros sejam de fcil diagnstico e que o sistema e/ou usurio possam se recuperar dos erros retornando a um estado anterior.

3.3.1.1.10

Boa ajuda e documentao

Todo produto de software deve contar uma documentao amigvel e explicativa que permita ao usurio entender o funcionamento da tarefa a ser executado, como execut-la e como os controles a sua disposio funcionam.

3.3.2 Acessibilidade Acessibilidade se refere as prticas inclusivas e visa prover um auxlio aos

56

usurios que apresentam algum tipo de dificuldade. Normalmente vemos no mundo fsico prticas de acessibilidade como rampas para pessoas em cadeiras de rodas, banheiros especialmente projetados, caladas com piso diferenciado para que deficientes visuais possam ir e vir com maior segurana, etc. Quando abordamos questes de acessibilidade no desenvolvimento de softwares e portais do setor pblico, estas prticas inclusivas so mandatrias. A Austrlia se tornou pioneira no reforo e cobrana deste acesso universal a sites de internet quando em 2000 um deficiente visual ganhou uma causa judicial contra a organizao dos jogos olmpicos de Sydney por no ter disponibilizado um site acessvel aos usurios cegos. Sites acessveis devem permitir a correta interpretao por navegadores que realizao a leitura de telas e utilizar padres de cores que permita a utilizao por daltnicos.
Given everything the Home page has to accomplish, if a site is at all complex even the best Home page design cant do it all. Designing a Home page inevitably involves compromise. And as the compromises are worked out and the pressure mounts to squeeze in just one more thing, some things inevitably get lost in the shuffle. (Krug, 2006, p98)

Softwares acessveis devem contar com controles que permitam uma grande abrangncia de usurios com os diversos tipos de deficincias, pessoas que no podem digitar ou utilizar mouse, pessoas com dificuldade de leitura, etc. Muitas dos softwares de computador foram projetadas sobre as premissas de que as pessoas poderiam ler e reagir a textos e imagens apresentadas na tela do computador, que conseguiriam digitar em um teclado padro, selecionar textos e imagens, e qualquer informao com auxlio do mouse, reagir a sons tocados. Se uma pessoa no fosse capaz de realizar alguma dessas aes, ela correria grandes riscos de no conseguir operar a maioria dos softwares de computador. Entre os grupos de pessoas que tm dificuldade em realizar tais tarefas esto as pessoas com limitaes visuais, deficientes fsicos (paralisados, amputados, atrofia muscular, Parkinson, entre outros) e pessoas com dificuldades auditivas. Existem hoje algumas formas para permitir o uso de softwares de computador por pessoas com certas limitaes como a converso text-to-speech (texto para fala)

57

onde o computador reconhece o texto e emite o som das palavras. Estes programas so utilizados tanto para auxiliar pessoas com problemas de leitura como pessoas com dificuldade de fala, onde estes digitam o texto e o computador emite os sons. Entre outras formas est a tcnica de aumentar o tamanho do contedo exibido na tela do computador de forma a facilitar a leitura por pessoas que possuem uma limitao moderada de viso, sticky keys, single switch, teclados especiais, reconhecimento de fala, atalhos de teclado e hot keys.

3.3.3 Design de Interao e Interfaces No projeto de softwares e sites um dos pontos chaves de engajamento do usurio, e tambm um fator que contribuir significativamente para sua experincia aparncia visual. Softwares que so agradveis visualmente apresentam padres de cores consistentes, diagramao apropriada respeitando os diferentes nveis de

importncia da informao e principalmente a hierarquia das prioridades sob as aes que devero ser desempenhadas, costuma gerar uma satisfao maior do usurio. Projetar como o usurio ir interagir com o sistema fator fundamental para eficincia de uso e impacta diretamente nas questes de usabilidade apresentadas anteriormente. Existem princpios simples de Gestalt que podem ser facilmente assimilados por qualquer pessoa que tenha o interesse em projetar interfaces. Por mais que a simples aplicao destes princpios no garanta unicamente o resultado de uma boa interface, as chances disso acontecer so aumentadas consideravelmente.

3.3.3.1

Princpios bsicos de organizao visual e Gestalt

O estudo da Gestalt se originou na Alemanha por volta de 1920. Trata-se de uma forma de psicologia focada nos processos cognitivos. Muito utilizada na arquitetura, design, fotografia e pintura, a Gestalt explora como funciona a percepo visual.

58

3.3.3.1.1

Contraste

Contraste um princpio utilizado para demonstrar separao e destacar itens. Costuma evidenciar onde acaba uma informao e comea outra. A utilizao do contraste comum quando queremos focar a ateno do usurio em algum ponto especfico, quanto mais diferente for, mais a informao se sobressair. Como esta tcnica utilizada para atrair a ateno do usurio importante que seja utilizada com cuidado, pois se todas as informaes apresentarem caractersticas muito contrastantes o usurio no ter um s ponto de ateno e sim vrios, perdendo assim sua eficincia. Muito importante ter em mente que se dois itens no possuem um mesmo significado, no representam a mesma coisa, estes itens devem ser diferenciados. Um erro comum muitas vezes acidental a criao de diferenas sutis entre elementos visuais, diferenas sutis no geram contraste e sim continuidade, muitas vezes essas diferenas sutis geram desconforto no usurio, pois a sensao predominante ser de so elementos iguais, porm existe algo errado. necessrio tomar cuidado redobrado para evitar este desconforto.

3.3.3.1.2

Repetio

Repetio uma tcnica que permite uma fcil assimilao da linguagem empregada. Inserir elementos de repetio faz com que o usurio se sinta confortvel em uma tela ou sistema diferente, mesmo que esta seja completamente desconhecida. Um exemplo comum de tcnicas de repetio, por exemplo, a utilizao de nmero de pginas em publicaes. Podemos escolher se o nmero fica no canto superior direito, ou inferior direito, ou ambos, porm uma vez decidido isto, eles estaro presentes nos mesmos lugares em todas as pginas. Desta forma ensinamos ao usurio onde ele poder localizar esta informao sempre que precisar. Elementos de repetio se misturam ao contedo das pginas sem que os percebamos sempre, mas passamos, a saber, que eles esto l e quando preciso sabemos onde localiz-los. A repetio de elementos e comportamentos influencia diretamente na consistncia de uma ferramenta.

59

3.3.3.1.3

Semelhana e Proximidade

A proximidade entre elementos comunica afinidade entre eles, isto passa a ser um grande artifcio na organizao da informao. importante buscar agrupar e aproximar elementos que possuem um significado semelhante ou so utilizados em conjunto. Agrupamentos de elementos tendem a ser vistos como um elemento s, e esta forma de guiar o olhar do usurio importante, quanto menos blocos de informao ele localizar, mais fcil ser definir a prioridade de cada um atravs da utilizao de contraste. Isto ocorre porque temos um limite na quantidade de elementos que a mente consegue manter um relacionamento, desta forma temos a tendncia de agrupar itens que se parecem para ficar mais fcil memoriza-los. um recurso poderoso, pois ajuda a atingir um grande nvel de unicidade.

3.3.3.1.4

Alinhamento

Alinhamento talvez seja o princpio de design mais absorvido pelas pessoas, existem diversas formas que podemos alinhar elementos seja verticalmente ou horizontalmente. comum e mais fcil passar a correta sensao de alinhamento quando utilizamos objetos com cantos definidos ou que formas linhas mais facilmente identificveis. Alinhamentos diferenciados podem ser combinados para auxiliar na criao de contraste ou aumentar a semelhana entre blocos de informao. Tambm utilizado com o alinhamento est a questo de distribuio e proximidade de informaes.

3.3.3.1.5

Fechamento

Este princpio se baseia na premissa de que um objeto complexo no nada mais do que a combinao de diversos objetos mais simples. A mente humana tende a reconhecer um objeto elemento visual conhecido mesmo que partes deste no estejam sendo apresentadas. Esta tcnica funciona em grande parte com formas geomtricas, pois necessitamos apenas de algumas pistas visuais para que possamos preencher com

60

os elementos que no so apresentados. A figura abaixo ilustra bem esta questo.

Figura 5 Principio de fechamento Visual

O primeiro crculo da esquerda para direita facilmente identificvel, pois est completo, porm mesmo quando olhamos para as outras imagens conseguimos ver o mesmo crculo por mais que este no seja uma linha completa. O nosso crebro preenche o ltimo crculo com o que falta e se algum apresentasse apenas a ltima imagem e perguntasse a uma pessoa o que figura geomtrica ela v, provavelmente a resposta seria um crculo.

3.3.3.1.6

Continuidade

Continuidade o princpio cuja premissa de que quando passamos a olha algo em uma direo continuaremos seguindo a mesma direo de leitura at que algo mude. Esta tcnica utilizada para criar um caminho guiando olhar do usurio na direo em que ele deve realizar a leitura do contedo apresentado. Se a composio parece estar apontando para uma determinada direo o olhar do usurio seguir para tal direo.

3.3.4 Envolvimento Emocional Mesmo quando consideramos todas as necessidades dos usurios, a usabilidade, acessibilidade, aspectos visuais, adequao ao negcio, funcionalidade e tecnologia, muitas vezes, no temos sucesso na aceitao total do produto. Para isto necessrio entender um pouco como as pessoas se relacionam emocionalmente com as coisas, para que ento seja possvel melhorar as ferramentas em uso. Na percepo dos produtos pelos usurios, Don Norman aponta trs caractersticas desta. A primeira a visceral, que diz respeito ao impacto inicial da aparncia do produto e como nos sentimos em relao a isso. A segunda

61

comportamental, que diz respeito ao como nos sentimos ao utilizar o produto. Por ltimo, a reflexo, o que este produto nos faz pensar, o que diz sobre o usurio dele. Para Noriaki Kano, existem elementos objetivos e subjetivos que afetam nossa percepo de qualidade dos produtos que utilizamos. Ele alega que discusses acerca destes dois aspectos ocorrem desde os tempos de Aristteles. A percepo objetiva de qualidade est associada na adequao do produto aos seus requisitos, e as qualidades subjetivas estariam associadas a satisfao dos usurios. Para projetar algo que dever ser utilizado por seres humano, sejam produtos ou softwares, deve-se ter claramente identificados os requisitos e expectativas dos usurios. necessrio saber o que absolutamente essencial para o produto, o que se for adicionado ser timo, e por ltimo os itens que quanto mais tiverem melhor ser o produto. Estas divises de caractersticas podem ser exemplificadas em um simples de exemplo de software. Em uma loja virtual essencial que eu tenha um catlogo de produtos e emita uma nota fiscal, estes so requisitos essenciais. Seria muito bom que as compras pudessem ser pagas com cartes de crditos ao invs de boletos, isto seria algo muito bom. Um exemplo de itens que quanto mais eu tiver melhor, por exemplo, seriam relatrios, existe os mais essenciais, os que ajudam no entendimento das vendas e os que poderiam servir de alertas de algo que est errado. Para lidar com as expectativas dos usurios importante entender suas prioridades e objetivos. S desta maneira ser possvel produzir produtos de software que de fato complementem seu modelo de trabalho e tragam vantagens competitivas.

3.3.5 Arquitetura de Informao Arquitetura de Informao uma nova rea de estudos que se especializa na organizao de grande quantidade de informaes. Esta rea de estudos tem ganhado destaque com a evoluo da internet e o aumento exponencial de informao disponvel.
Some web sites provide logical structures that help us find answers and complete tasks. Others lack any

62

intelligible organization and frustrate our attempts to navigate through them. We can't find the product we need; we can't locate the report we found last week; we're lost inside an online shopping cart. These websites may remind us of buildings that fail: houses with flat roofs that leak, kitchens with no counter space, office towers with windows you can't open, and maze-like airports with misleading signs. (Rosenfeld, 2002, p 18)

Esta disciplina foca na catalogao e organizao, nomenclatura, e criao de esquemas de navegao em sistemas de informao. Busca-se com esta organizao facilitar o acesso e localizao da informao necessria para que uma tarefa possa ser concluda. Existem diversas tcnicas que podem ser utilizadas para se atingir estes objetivos, e os princpios de arquitetura de informao podem ser percebidos por trs de qualquer grande portal de internet disponvel hoje em dia.

Figura 6 Crescimento do contedo na Internet

Para muitos, ainda difcil reconhecer a aplicabilidade destas tcnicas e sua aceitao s ocorre quando se apresenta os produtos do trabalho. Muitas vezes a aplicao da arquitetura de informao em contextos corporativos s pode ser percebida mostrando o antes, o depois e os motivos da transio.

63

Compare the chaos of this bookstore to the order of a library. Even on the surface, the contrast is like night and day. But look deeper and you'll see that a library is more than a warehouse for books, magazines, and music. There are complex systems and well-trained professionals operating behind the scenes to select, evaluate, label, describe, structure, and organize the collection so that users of the library can find what they need. And though the library's information environment is highly structured, the subject-oriented approaches of the Dewey Decimal and Library of Congress classification schemes also support exploratory browsing and serendipity. (Rosenfeld, 2002, p 22)

Grande parte do processo de trabalho de arquitetura da informao est na coleta e identificao da informao e na sua categorizao.

3.3.5.1

Organizao da informao

Existem muitos desafios e dificuldades na organizao de catalogao de contedo. So visveis problemas gerados por ambiguidade das informaes, a heterogeneidade, diferenas de perspectivas ao observar uma informao, polticas internas de organizaes quanto a distribuio e compartilhamento, entre outros. Ao projetar um software ou sistema normalmente so conduzidas pesquisas para identificar seus requisitos e que tarefas sero executadas. Nesta anlise de processo de negcio comeam a surgir os primeiros dados sobre o tipo de informao que ser armazenada e tratada pelo sistema assim como seus relacionamentos com outras informaes. 3.3.5.2 Taxonomia

Trata-se aqui da taxonomia como ramo da cincia que engloba a descrio, identificao, nomenclatura e classificao. No projeto das funcionalidades e casos de uso de um software importante que a nomenclatura dos casos de uso e suas funcionalidades sejam consistentes, alm de refletir a realidade de trabalho do usurio final. Para isto necessrio que se tenha o conhecimento bsico dos termos utilizados no trabalho do dia-a-dia, seus significados e suas relaes. comum em softwares que o usurio no consiga localizar uma determinada informao ou funcionalidade pelo simples fato desta no estar nomeada de acordo com suas expectativas. Todo projeto deve conter um thesaurus que permita um entendimento do

64

vocabulrio utilizado. Tal informao se torna essencial em sistemas que possuem caractersticas muitos distintas do mundo real.

65

4-

PROTOTIPAO

GIL

NO

DESENVOLVIMENTO

DE

SOFTWARES
A prototipao parte essencial no processo de desenvolvimento de software, por ser a primeira materializao visual dos requisitos definidos pelos usurios. A criao de prottipos costuma ocorrer no final da fase de levantamentos de requisitos, aps boa parte dos requisitos j terem sido identificados. Muitas vezes durante a criao dos prottipos muitos requisitos, problemas e solues ficam mais aparentes.
I draw a simple dividing line through this sea of design. I put the part of the design that will directly affect the ultimate end user of the product on one side. On the other side is all other design. In this book, when I speak of "interaction design," I am referring only to the former. I call the remaining design that doesn't affect the end user program design. (Cooper, 2004, p48)

Este trabalho prope uma abordagem diferente, uma metodologia onde a prototipao ocorra em paralelo com o levantamento de requisitos. Esta ideia pode ser vista com certo olhar de inviabilidade por gestores e empresas, quanto as questes financeiras. A princpio o custo do desenvolvimento de software seria elevados substancialmente, porm para garantir a viabilidade, so propostas aqui tcnicas rpidas de criao de prottipos simples, rpidos e pouco formais que podero trazer uma maior visibilidade do escopo do projeto.
The objective is not to make the actual system, but to mock up something that users can actually experience, thereby enabling us to explore design concepts in action and as experienced far earlier in the process than would otherwise be possible. Such a system should be cheap, quick to realize, disposable, not the real thing, and only have sufficient fidelity to serve its intended purpose. That is, it should have all the attributes that characterize a sketch. (Buxton, 2007, p 240)

Para fins de entendimento deste trabalho, no sero questionados a quais partes caberiam a tarefa de prototipao. Pela simplicidade das tcnicas e softwares apresentados neste trabalho no se limitam a utilizao por pessoas especializadas. As tcnicas aqui apresentadas poderiam ser facilmente empregadas por reas de negcio que tenham o interesse em ter mais controle durante a parte de

66

levantamentos de requisitos. Parte-se da premissa que qualquer pessoa que tenha um conhecimento mnimo sobre o que deseja, e com interesse de ir alm, ter a capacidade de absorver o conhecimento necessrio para realizao das atividades propostas aqui.
In a technical world dominated by engineers, internal program design has held sway, and interaction design for the end user's benefit has been incorporated only on an after-the-fact, spare-time basis. One of the goals of this book is to reveal the benefits of inverting this priority and making interaction design the first consideration in the creation of software-based products. (Cooper, 2004, p49)

4.1

Definio do Escopo Parte inicial de qualquer projeto requer uma definio de escopo,

necessria a definio das fronteiras do que ser e no ser contemplado pelo projeto. Sabemos que a definio de escopo em projetos de software junto rgos governamentais bastante voltil, tendo em vista que muitos fluxos de trabalhos podem ser alterados por leis, decreto, portarias, etc a qualquer momento. Para a definio do escopo de qualquer software necessrio a coleta de informaes que podem ser caracterizadas em trs grupos distintos: Objetivos, Tarefas, Funcionalidade.

4.1.1 Objetivos Para a definio dos objetivos necessrio uma coleta de informao com as partes envolvidas. Devem ser realizadas reunies iniciais para que seja possvel ter uma viso completa das expectativas. 4.1.1.1 Objetivos Estratgicos

Os objetivos estratgicos so objetivos macro, sob a ptica de uma organizao, ou departamento e servem como guia geral para o que ser desenvolvido. Toda organizao ou departamento atualmente possui uma misso e viso, a

67

periodicidade de suas atualizaes pode ser questionvel, mas toda a demanda de software deve estar de alguma forma alinhada com os objetivos estratgicos e viso de longo prazo da rea requisitante. importante que as demandas sejam planejadas e incorporem um portflio de projetos maiores. Demandar software sem saber onde eles est inserido no todo pode ser o primeiro passo para o fracasso e falta de comprometimento de stakeholders. O benefcio provido pela ferramenta que ser desenvolvida dever estar claro para todas as partes que detm poder de deciso dentro do projeto. 4.1.1.2 Objetivos dos Usurios

A definio dos objetivos dos usurios uma especializao dos objetivos estratgicos que so mais palpveis e particulares do projeto em questo. Muitas vezes quando so identificadas demandas de software, os usurios dirios no so levados em considerao e o processo passa a ser regido apenas por consultores e comits gestores. Com esse distanciamento comum que os objetivos dos usurios sejam colocados em segundo plano. importante conduzir pesquisas com os usurios, buscando identificar seus objetivos e como estes se alinham com os objetivos estratgicos para conseguir corretamente definir e priorizar os aspectos mais relevantes.

4.1.1.3

Contexto de Uso

Todo software ser utilizado dentro de um contexto de armazenamento de informao para realizao de uma tarefa. importante ter um domnio sobre o contexto em que este software ser utilizado. preciso levar em conta aspectos tecnolgicos e scio culturais dos usurios finais, fazendo-se necessrio saber a experincia dos usurios finais com as informaes negociais, seus conhecimentos tcnicos e de uma forma geral como eles se adaptariam a nova ferramenta proposta. Contexto de uso est associado as questes organizacionais e diretrizes de privilgios de acesso a informaes restritas, qualidade dos computadores e servidores disponibilizados, adequao a linguagem. Hoje em dia muitos softwares esto em plataforma web com acesso a servidores atravs da internet, no entanto, preciso se certificar que os usurios que

68

se encontram nas extremidades do pas tero acesso aos requisitos mnimos de banda para poder tirar proveito desta forma de comunicao. Muitas vezes estados mais afastados como Roraima, ou mais amplos como o Par, possvel encontrar grande dificuldade no interior para acesso aos meios de comunicao.

4.1.2 Tarefas a desempenhar Normalmente a necessidade do desenvolvimento de um software ou atualizao de um antigo se d pela identificao da possibilidade de automatizao de algum processo de negcio. Todo trabalho realizado em rgos governamentais possuem processos a serem seguidos, algumas vezes estes processos possuem um fluxo mais direto e seguem em apenas um sentido, s vezes se ramificam e passam a ter um carter mais iterativo. De qualquer forma, existem sempre processos de trabalho, compostos de tarefas e orquestrao entre essas tarefas.
Practical goals bridge the gap between the objectives of the company and the objectives of the individual user. The corporation wants everyone working hard to maximize the corporate bottom line. The practical goal of handling the client's demands connects the corporate goal of higher profits with the user's personal goal of being productive. (Cooper, 2004, p193)

essencial que o incio do processo de desenvolvimento se d pela correta identificao das tarefas que compes os processos de trabalho. A partir deste momento passamos a ter uma visibilidade de como o software vai se comportar. Tendo em mos as tarefas de trabalho que so executadas no dia-a-dia devidamente catalogadas, cabe a rea requisitante definir quais tarefas sero tratadas pelo software e como estas se integraro, com as que no sero tratadas.
There is an easy way to tell the difference between tasks and goals. Tasks change as technology changes, but goals have the pleasant property of remaining very stable. For example, to travel from St. Louis to San Francisco, my goals are speed, comfort, and safety. Heading for the California gold fields in 1850, I would have made the journey in my new, high-tech Conestoga wagon. In the interest of safety, I would have brought my

69

Winchester rifle. Heading from St. Louis to the Silicon Valley in 1999, I would make the journey in a new, hightech Boeing 777. In the interest of safety, I would leave my Winchester rifle at home. My goals remain unchanged, but the tasks have so changed with the technology that they are in direct opposition. (Cooper, 2004, p183)

A modelagem de processos de negcio ou BPMN uma forte aliada nesta etapa. Uma vez que as perguntas corretas sejam feitas, a notao de processos pode ser utilizada para orquestrar visualmente o encadeamento ou orquestrao das atividades e trazer maior visibilidade ao projeto.

4.1.2.1

Tarefas e Atividades dos Usurios

A correta definio das tarefas s pode ser realizada com a ajuda dos usurios finais. Para sua correta identificao pode-se realizar a aplicao de questionrios, marcao de reunies, acompanhamento dos usurios e entrevistas. Entre os diversos mtodos de investigao do processo de trabalho do usurio, importante identificar como este realiza suas atividades diariamente. Algumas vezes atravs da simples observao possvel identificar gargalos de trabalho que poderiam ser otimizados atravs de um produto de software.

4.1.2.2

Casos de Uso e Estrias de Usurio

Os casos de uso e estrias de usurios so produtos tangveis dentro das diversas metodologias de desenvolvimento software como apresentando

anteriormente. importante conhecer estes artefatos e entender como as tarefas e atividades que foram identificadas sero traduzidas aqui. Casos de uso e estrias do usurio so artefatos que buscam conter uma linguagem comum entre reas tcnicas e reas de negcios e so os principais resultados da parte de anlise de requisitos. Um modelo de caso de uso bastante utilizado o de CRUD que contempla as funcionalidades de Incluir, Recuperar, Atualizar e Excluir. Este caso de uso muito utilizado quando existe a necessidade de administrar dados de entidades de negcios como vendas, pessoas, produtos, etc. Este caso de uso pode ser facilmente exemplificado atravs do exemplo manter usurios. Partindo desta premissa, provvel que exista a necessidade de

70

cadastrar novos usurios, assim como alterar os dados de um usurios j cadastrado, excluir usurios que no fazem mais parte do sistema e recuperar (exibir) os dados de um determinado usurio. Este um exemplo consagrado de caso de uso, mas que sofre sempre alteraes de acordo com as necessidades individuais de cada sistema. comum no querer que usurios sejam excludos do sistema e sim apenas desativados.

4.1.2.3

Funcionalidades

As funcionalidades dos softwares so entendidas como interface pontual que permitir a realizao do trabalho proposto pelo usurio final. Funcionalidades compem os requisitos necessrios para se alcanar o resultado esperado retratados nos casos de uso e estrias de usurios.

4.2

Definio dos Atores, Perfis e Personas importante que ao pensarmos em um sistema, desde o momento inicial,

tenhamos em mente quem ir utiliz-lo. Quando conhecimentos bem os usurios, suas expectativas, suas rotinas de trabalho, seus comportamentos, conseguimos prever com mais exatido o conjunto de funcionalidades. Os atores sempre podero fazer escolhas e tomar decises, no entanto os atores de um sistema no sero necessariamente pessoas, podendo ser tambm outros sistemas. Estes atores podem assumir diferente perfis, que limitam ou estendem funcionalidades do tipo de papel. Podemos pensar em um exemplo de ator sendo o funcionrio do banco, que pode ter diferentes perfis que garantem a ele ou no a permisso necessria para retirada de dinheiro. A definio de personas busca uma humanizao destes atores e perfis, no exemplo menciona acima poderamos descrever a persona sendo: Joo, um funcionrio do banco que trabalha de sete da manh as quatro da tarde, que fala ingls, que utiliza o sistema do banco para controlar depsitos e retiradas de dinheiro e necessita sempre da aprovao das operaes de seu chefe. Com isto, passamos a entender melhor como o usurio. A prtica de

71

definio de personas nos ajuda a perceber questes que podem ser cruciais para a operao do sistema em estgios bem iniciais do projeto.
If you want to create a product that satisfies a broad audience of users, logic will tell you to make it as broad in its functionality as possible to accommodate the most people. Logic is wrong. You will have far greater success by designing for a single person.

4.3

Benchmarking de solues Uma prtica comum na produo de websites a realizao de benchmark,

onde se pesquisam os diversos concorrentes do setor e verifica-se como estes esto se comportando. Na engenharia de software esta prtica tambm muito utilizada, tiramos muitas ideias para um sistema novo, de sistemas que j entramos em contato no passado. Utilizar a experincia obtida ao longo de uma vida em novos projetos bastante vlido, pois se evita cometer os mesmos erros do passado, no entanto, estamos fadados a utilizar solues que j foram utilizadas. A busca por iniciativas semelhantes ao que ser projetado pode trazer inmeras solues e aprendizado. Em ambientes governamentais, o aprendizado pode vir tanto de acordos de cooperao entre diferentes rgos como tambm de solues de mercado. Uma forma interessante de realizar este trabalho atravs de uma anlise SWOT onde se verificam os pontos fortes, fracos, as ameaas e as oportunidades. Uma interpretao comum desta anlise ficou popularizada pelo Gartner Group e os diversos quadrantes mgicos produzidos.

72

Figura 7 anlise SWOT

4.4

Mtodos de Prototipao A prototipao de softwares se refere atividade de criao de prottipos de

aplicativos

de

software.

uma

atividade

que

pode

ocorrer

durante

desenvolvimento de softwares e comparvel com a prototipao que ocorre nas diversas reas de engenharia e design. Um prottipo deve simular, com diferentes nveis de abstrao, aspectos do comportamento e formato do software que ser desenvolvido. O propsito original da criao de prottipos garantir as partes interessadas (clientes, desenvolvedores) um melhor entendimento e viso do que ser criado ao invs de criar primeiro e avaliar depois. Esta forma de pr-projeto auxilia a identificao de inconsistncias e falhas de projeto antes do produto ser concludo, minimizando custos e possivelmente prazos. Os nveis de detalhamentos e tcnicas utilizadas na prototipao podem variar bastante, principalmente de acordo com as metodologias, prazos e custos determinados. Neste trabalho visamos explorar de maneira objetiva as tcnicas que poderiam auxiliar reas de negcio a demandar melhores softwares sem que sejam oneradas com os percalos desta prtica. Para o incio do processo de prototipao necessrio uma definio dos requisitos bsicos, modelos de entrada e sadas, formulrios que sero utilizados, dados a serem cadastrados e processados. Posteriormente segue-se com a criao dos prottipos iniciais com apenas interfaces humano-computador, deixando de lado aspectos tcnicos e focando na interao. Estes prottipos so ento revisados junto aos clientes, ou at mesmo produzidos por estes, so ento includos itens que possam estar faltando,

73

mudanas so realizadas e o prottipo melhorado. Este processo pode ser realizado iterativamente at que se alcance o nvel de detalhamento necessrio para a tarefa a ser desempenhada, podendo ser essa o desenvolvimento da funcionalidade ou a criao de documentao auxiliar. Duas dimenses comuns de prottipos amplamente reconhecidas so: Horizontal e Vertical. Prottipos horizontais so os prottipos de interface do usurio que visam prover uma viso geral do sistema focando na interao com o usurio ao invs de questes tcnicas. Estes prottipos so muito teis para confirmao do escopo do sistema e dos requisitos de interface, uma demonstrao do sistema e desenvolver estimativas iniciais de prazo, custo e esforo. Os prottipos verticais tratam de um modelo mais elabora da funcionalidade, analisando a fundo suas questes tcnicas sendo assim muito uteis para: melhoria do projeto de banco de dados, obteno de informaes sobre volume de dados, necessidades das interfaces de redes e dos componentes, alm de clarificar requisitos complexos. Existem tambm diversas variaes de prottipos sendo as duas mais comuns: Throwaway prototyping (Prototipao gil), Evolutionary prototyping, e Extreme prototyping.
You can write a prototype much faster than a real program. This makes it attractive because it seems so inexpensive, but real programming gives you a reliable program, and prototyping gives you a shaky foundation. Prototypes are experiments made to be thrown out, but few of them ever are. Managers look at the running prototype and ask, "Why can't we just use this?" The answer is too technically complex and too fraught with uncertainty to have sufficient force to dissuade the manager who sees what looks like a way to avoid months of expensive effort. (Cooper, 2004, p 90)

A prototipao gil ou Throwaway prototyping se refere a criao de ummodelo que ser posteriormente descartado e no far parte do produto final de software entregue ao cliente. Aps a elaborao e levantamento dos requisitos iniciais, e antes de qualquer aprofundamento, este processo j pode se iniciar. A ideia por trs deste prtica a criao de um modelo inicial e simples, que pode ou no ser funcional. Sua funo principal oferecer uma representao visual do software e servir como partida para o aprofundamento dos requisitos.

74

Rapid Prototyping involved creating a working model of various parts of the system at a very early stage, after a relatively short investigation. The method used in building it is usually quite informal, the most important factor being the speed with which the model is provided. The model then becomes the starting point from which users can reexamine their expectations and clarify their requirements. When this has been achieved, the prototype model is 'thrown away', and the system is formally developed based on the identified requirements. (John Crinnion, 1991,p18)

A razo mais evidente para utilizao desta tcnica que ela pode ser feita rapidamente, e se o feedback for rpido, pode-se refinar os requisitos em um estado bem inicial do desenvolvimento. As mudanas no incio do ciclo de vida de projetos costuma gerar um impacto menor nos custos do que mudanas em estgios posteriores.
It is asserted that revolutionary rapid prototyping is a more effective manner in which to deal with user requirements-related issues, and therefore a greater enhancement to software productivity overall. Requirements can be identified, simulated, and tested far more quickly and cheaply when issues of evolvability, maintainability, and software structure are ignored. This, in turn, leads to the accurate specification of requirements, and the subsequent construction of a valid and usable system from the user's perspective via conventional software development models. (S.P. Overmeyer, 1990)

Os prottipos podem ser classificados de acordo com a fidelidade com que eles parecem com o produto final em termos de aparncia, interao e contedo. Uma forma de criao de prottipos de baixa fidelidade e muita agilidade eh a prototipao em papel. As tcnicas mencionada acima sero mais bem detalhadas na seo de prototipao digital.

4.4.1 Prottipos em Papel A criao de prottipos em papel uma prtica muito saudvel para o inicio de trabalhos de levantamento de requisitos. Ele apresenta uma imensa facilidade e agilidade em relao aos prottipos digitais, principalmente por dispensar o uso de um computador.

75

A beleza desta tcnica est na sua simplicidade permitindo que em uma conversa de bar, com apenas guardanapo e caneta, seja possvel demonstrar uma ideia de forma clara e concisa. De uma forma geral esta tcnica no vista com tanta seriedade e muitas vezes o trabalho produzido no considerado um entregvel ou documento formal de projeto, no entanto, a rapidez de criao e a liberdade que o papel proporciona so fundamentais para sua aplicao.
The basis of the technique is very simple. If the user interacts with something on the sketch, that should cause a change in what is seen. For example, if the user pushes a button, the facilitator makes the appropriate change happen. This might be accomplished by something as simple as replacing one sketch with another. A simple two-minute exercise. (Buxton, 2007, p 373).

A prototipao em papel ajuda a melhorar o produto final, no s por poder ser utilizada nos estgios iniciais, mas tambm por ser barata e no apresentar custos elevados para o trabalho, mesmo apresentando a maioria dos benefcios da prototipao digital. Desta forma ajuda na identificao de problemas de projeto e questes de usabilidade, e quando tratado com ateno prottipos em papel podem se tornar bem sofisticados demonstrando interaes complexas. Dependendo do nvel de detalhamento que se espera chegar, pode-se usar desde folhas A4 normais at papis milimetrados ou cartes. A ideia por trs desenhar as telas com certo nvel de abstrao e colocar os elementos que se pretende ter. Neste estgio possvel ver quais interfaces sero necessrias para o usurio conseguir realizar uma tarefa ou acessar uma informao importante. No necessrio um artista grfico ou um engenheiro de software para se criar um prottipo em papel, apesar de essas habilidades servirem como grande auxlio elas no so pr-requisitos para execuo deste trabalho. Basta que se tenha uma ideia do que se quer fazer e rascunh-la ento em alguma superfcie. Esta tcnica apesar de no ser adequada para testes de usabilidade ela pode ser muito eficaz na gerao de ideias e revises de layouts de interfaces de um software.
This was, I believe, my first exposure to what some people call paper prototyping, but which I simply refer to as paper interfaces (more on why, later). What they did was have one of the designers make a quick

76

drawing of the proposed front panel, and then bring in expert users to test them. The tests were videotaped for later analysis and comparison. What the sessions consisted of was a member of the design team explaining a particular scenario to the user, and then having the user perform the appropriate task using the sketch as a proxy for the planned product, all the while talking aloud explaining their actions and intentions, as well as asking any questions. (Buxton, 2007, p371)

O mais importante que praticamente qualquer interface humanocomputador, pode ser representada facilmente e proporcionar um feedback gil. possvel localizar na internet diversos elementos para a facilitao da prototipao em papel como itens de interface, botes e pginas contendo grids com espaamentos simulando a rea disponvel em um monitor. Qualquer pessoa interessada pode fazer uma busca por estes recursos e ser rapidamente bombardeada com opes.

4.4.2 Prottipos Digitais Prottipos digitais muitas vezes buscam representar com maior fidelidade o funcionamento do software e sua aparncia, servindo assim como uma forma de documentao amis robusta e confivel que evoluda ao longo do projeto. Na criao atravs da prototipao evolutiva, ou Evolutionary Prototyping, busca-se criar um prottipo robusto e estruturado de forma a ser constantemente refinado. A ideia por trs destes prottipos que eles sero mantidos e alterados conforme o sistema sofra alteraes ao longo dos seus diversos ciclos de vida. Desta forma estes prottipos se tornam o corao do desenvolvimento de software e possuem um alto nvel de fidelidade, representando ao mximo o comportamento das interaes com os usurios. Com a prototipao extrema ou Extreme Prototyping o processo de desenvolvimento realizado em camadas, e esta tcnica mais comum na criao de websites. O processo de desenvolvimento separado em fases, cada uma baseada na fase anterior. A primeira etapa a construo do prottipo realizada em pginas HTML que posteriormente recebem os cdigos de programao para torna-las funcionais em uma camada de simulao. Quando esta fase est concluda, o projeto progride com a implementao dos servios. Este processo

77

chama ateno para parte extrema onde elementos de interface com o usurio so completamente desenvolvidos em cima de camadas abstratas na segunda fase sem grandes preocupaes em como o cdigo final ser incorporado.

4.5

Ferramentas de Prototipao Existem muitas divergncias sobre quando usar ou no a prototipao, mas

de uma forma geral, acredita-se que o bom uso das inmeras ferramentas disponveis no mercado podem viabilizar o uso em qualquer situao de projeto. O importante saber qual ferramenta e que nvel de detalhamento abordar em cada projeto ou fase de projeto, e principalmente ter em mente as dificuldades existentes nas mudanas de processos de trabalho. A common problem with adopting prototyping technology is high expectations for productivity with insufficient effort behind the learning curve. In addition to training for the use of a prototyping technique, there is an often overlooked need for developing corporate and project specific underlying structure to support the technology. When this underlying structure is omitted, lower productivity can often result.( Joseph E. Urban: Software Prototyping and Requirements Engineering. Rome Laboratory, Rome, NY) Dentre as inmeras ferramentas que existem disponveis no mercado, algumas despontam em aceitao e j so consideradas bem estabelecidas e sero descritas em maiores detalhes a seguir.

4.5.1 Axure O Axure um software dedicado a prototipao de websites e aplicaes web. Ele baseado em alguns conceitos presentes em ferramentas de design e apresenta uma interface amigvel ao uso. Na sua grande maioria as ferramentas de prototipao geralmente permitem um desenho da tela, mas no possuem muitos recursos para demonstrar as interaes dos usurios, o Axure se destaca com inmeras funcionalidades que permitem a criao de interaes complexas e uma simulao bem prxima do produto final.

78

Entre os pontos fortes do axure esto a facilidade das funcionalidade de arrastar e soltar widgets dentro da grid de trabalho, como no Visio, a gerao de prottipos HTML que podem se comportar como o produto final, a personalizao de widgets e modelos que so comuns ao uso e a gerao automtica de documentao tcnicas como tipos de campos, tamanhos e opes. A interface visual bem semelhante a sute Microsoft Office 2003, e qualquer usurio habituado a utilizao destes programas deve facilmente entender os elementos apresentados em tela. Logo na esquerda apresentado o mapa do site da aplicao, contendo todas as pginas de acordo com a hierarquia definida pelo usurio.

Figura 8 Sitemap Axure

A personalizao de widgets ou elementos de interface faz com que a utilizao de um guia de estilos pr-definido torne a construo dos prottipos incrivelmente gil. Inicialmente ele apresenta uma sries de elementos HTML comuns que podem posteriormente ser modificados.

79

Figura 9 Widgets Axure

A construo de prottipos bastante direta e consiste em arrastar os widgets, para a rea de trabalha (pgina em exibio) e posicion-lo como desejar. O usurio tem acesso a um painel de configuraes de todos os elementos selecionado com opes de comportamento que podem ser configurados um a um para um maior realismo do prottipo.

Figura 10 Interao Axure

80

Sempre que desejar o usurio pode facilmente requisitar a gerao de um prottipo HTML ou da documentao tcnica com base nas configuraes dos elementos. Segue imagem de prottipo gerado.

Figura 11 Prottipo em Axure

Existe grande facilidade na definio de elementos de configurao real, criao de modelos que podem ser aplicados a pginas facilitando a mudana em lote de elementos visuais comuns em todas as pginas.

Figura 12 Modelos em Axure

81

Figura 13 Comportamentos Globais do Axure

Em resumo o Axure uma ferramenta robusta para criao de prottipos web, e tem capacidade para as mais diversas situaes. A criao de prottipos detalhados pode ser altamente produtiva no caso da produo de documentao tcnicas pois ele pode exportar todas as configuraes em um documento de Word descrevendo todo o prottipo. Por se tratar de um software pago, a maior dificuldade de sua utilizao est em sua adoo por reas requisitantes em rgos governamentais. A aquisio de software costuma ser um processo longo e complicado e seu custo pode no ser justificado se a utilizao for apenas espordica.

82

Figura 14 Prottipo Axure

4.5.2 Balsamiq O Balsamiq tambm uma ferramenta paga, porm de mais fcil utilizao. Diferente de Axure ele no se prope a ser uma ferramenta para prototipao de interaes complexas, nem fidelidade dos elementos visuais. Esta ferramenta pode ser utilizada no prprio navegador do usurio, neste caso no existe custo ou pode ser comprada em sua verso desktop. Apresenta uma srie de widgets e elementos pr-configurados, porm todos possuem uma aparncia semelhantes a desenhos a lpis feitos em papel.

83

Figura 15 Tela de Trabalho do Balsamiq

A grande vantagem da utilizao do balsamiq est na sua extensa galeria de elementos visuais disponveis. Inspirados por diversos tipos de interface que so comuns na internet como abas, e acordees, ele poupa trabalho no estando preso apenas aos elementos HTML comuns. Assim como Axure este software tambm permite um fcil controle sobre os aspectos dos elementos que esto sendo posicionados apresentando controles fceis de configurao.

84

Figura 16 Configurao de Widgets no Balsamiq

Muito indicado para prototipao gil, diferente do Axure, esta ferramenta no apresenta ampla gama de recursos para exportao de elementos como criao de prottipos navegveis e interativos. A opo de salvar arquivos limitada tendo apenas as opes de PNG, PDF e XML, dificultando a manuteno evolutiva e atualizao posterior dos prottipos. Para iniciar uma cultura de prototipao gil tanto por parte das reas requisitantes como pelas fbricas de software dentro de rgos governamentais o Balsamiq um software altamente recomendado principalmente por poder ser utilizado em carter bastante informal, auxiliando reunies e servindo apenas para ir aos pouso registrando a informaes que surgem. Sua aparncia informal e sua agilidade de uso para representar interfaces mais complexas de forma amigvel so suas maiores foras, qualquer pessoas com proficincia em informtica pode em pouco tempo estar operando este software como um profissional e melhorando a forma de expressar suas ideias.

85

Seu principal ponto fraco no entanto para uma empresa de software reside na falta de liberdade para criao de novos elementos de interface do usurio, dificultando assim a utilizao de um guia de estilos existente. A no existncia do conceito de modelos e pginas mestras como no Axure ou no Visio pode ser um fator altamente limitador para projetos de grande escala, sendo assim indicado apenas para estgios iniciais de provas de conceito provendo uma visualizao inicial dos componentes de uma pgina. O fato de no apresentar mltiplas telas ou reas de trabalho pode tambm representar uma grande perda de produtividade dentro de ambientes de trabalho que so focados na criao de prottipos. De fato a melhor utilizao desta ferramenta seria na substituio do papel e caneta nos dilogos entre reas requisitantes e TI.

86

Figura 17 Prottipo Finalizado no Balsamiq

4.5.3 Pencil O Pencil uma ferramenta de prototipao inicialmente concebida como plugin para o navegador de internet Firefox e posteriormente tambm disponibilizada tambm em verso desktop. Apresenta uma interface grfica de fcil entendimento, e assim como Axure permite uma personalizao dos elementos visuais. Por ser uma ferramenta gratuita e relativamente nova, ainda sofre com algumas limitaes e no pode ser comparada com lderes de mercado, porm sua facilidade e sua licena gratuita a

87

torna uma das favoritas a ser adotada por rgos governamentais. A biblioteca de elementos pode ser configurada, porm inicialmente j possui alguns elementos HTML padro de fcil utilizao e elementos visuais que lembram o traado a lpis semelhante ao estilo do Balsamiq.

Figura 18 Configurao dos widgets no Pencil

Apesar de possui o recurso de criao de diversas abas, no uma ferramenta indicada para grandes projetos por no apresentar recursos de pginas mestras e criao de modelos. As interaes entre abas/pginas pode ser dar atravs de links aplicados aos diferentes objetos, no entanto interaes mais complexas no so possveis como no Axure. Por se tratar de um plug-in de navegador e no possuir muito controle sobre recursos de hardware, prottipos muito elaborados podem rapidamente

sobrecarregar computadores com menos recursos.

88

Figura 19Prottipo finalizado em Pencil

Esta ferramenta peca um pouco na usabilidade quando se trabalha com um nmero elevado de elementos e pginas, porm a agilidade em relao as outras ferramentas apresentadas no prejudicada. uma tima ferramenta de iniciao na rea de prototipao que tambm se mostra slida e confivel para utilizao profissional no ciclo de desenvolvimento de softwares.

4.5.4 Visio O Microsoft Visio um programa com inmeras aplicaes e funciona muito bem para o processo de produo de entregveis de arquitetura de informao. Nele possvel projetar interfaces, wireframes, sitemaps, processo de negcio, organogramas, etc. Ele conta com uma grande coleo de cones, e permite exportao dos arquivos em diversos formatos, o que facilitar bastante a troca de informaes.

89

Figura 20 Biblioteca de Widgets do Visio

possvel a criao e modificao de widgets assim como sua configurao quando instanciado na rea de trabalho. O Visio possui uma robustez prxima do Axure em relao as outras ferramentas e grande vantagem de conhec-lo bem que apesar de ser pago, muitas vezes j est disponvel nos computadores dos usurios. comum a instalao completa dos pacotes Microsoft dentro dos ambientes corporativos.

Figura 21 Prottipo Finalizado no Visio

90

O fato de este software estar disponvel ao usurio, contar com uma linguagem grfica conhecida e possuir lgica de operao muito semelhante aos demais programas do pacote office facilita a familiarizao do usurio. Possui recursos de criao de pginas mestras e modelos semelhantes ao Axure, porm muito inferiores em praticidade e usabilidade.

4.5.5 Editores de Planilhas Eletrnicas Existem diversos editores de planilhas eletrnicas no mercado e entre eles destaca-se o Microsoft Excel, bastante robusto em estilizao visual das planilhas. Estes controles de fontes (tamanhos, tipos e cores) assim como controle sobre diversas caractersticas de apresentao grfica das clulas pode ser uma das ferramentas mais amigveis a iniciantes.

Figura 22 Prottipo em Excel

Esta ferramenta tima parara auxiliar na formatao de relatrios trazendo visibilidade sobre colunas, atributos e frmulas. A representao ou prototipao de um relatrio em Excel serve como grande auxilio na hora da construo.

91

Figura 23 Prottipo de Relatrio em Excel

Fatores como largura e ttulos das colunas, tamanhos dos dados que sero apresentados quando primeiramente desenhados em uma planilha, conseguimos prever problemas que podem acontecer como dimenses no compatveis com os formatos de impresso, difcil leitura dos dados, entre outros.

4.6

Entregveis ou Artefatos Existem alguns artefatos que podem ser utilizados para representar

visualmente as discusses que ocorrem ao longo do processo de levantamento de requisitos. A grande vantagem da representao visual reside na facilidade de transmitir uma grande quantidade de informaes de uma forma mais amigvel.

4.6.1 Notao de Modelagem de Processo de Negcio A notao de modelagem de processo de negcio (BPMN) um padro criado que fornece uma anotao grfica para representao de processo de negcios. Esta linguagem similar ao diagramas de atividades da UML. Seu principal objetivo servir de supor para gerncia de processos tanto para usurios tcnicos como de reas de negcios. Esta linguagem busca estabelecer uma forma padronizada de comunicao e

92

de fcil entendimento entre stakeholders como usurios, analistas de negcios e analistas de requisitos. A BPMN busca dar suporte para representao de estruturas organizaes, fluxos de trabalho e modelos de dados e consistem em diagramas simples construdos com os elementos grficos disponveis. Existem quatro grandes grupos de elementos: Objetos de Fluxo (eventos, atividades, gateways), Objetos de conexo (Associao, fluxo de sequncia e fluxo de mensagem), Raias (piscinas e raias) e Artefatos (Objeto de dados, grupo e associao).

Figura 24 Exemplo de Processo de Negcio

4.6.2 Sitemap ou Mapas de Site Mapas do site so diagramas que buscam exemplificar as pginas ou telas de um software. Estes diagramas podem ser relativamente simples apenas conectando pginas mostrando os principais caminho de encadeamento entre elas ou pode ser bastante complexo contendo especificaes sobre o tipo de informao que ser apresentado em cada pgina. A principal funo deste artefato definir a hierarquia existente entre as pginas que sero apresentadas e fornecer um esboo de agrupamento das informaes levantadas em um projeto. muito utilizado para definir a hierarquia de sees e contedos de portais e programas e em uma relao bem prxima com os menus que sero criados.

93

Figura 25 Exemplo de Sitemap

4.6.3 Prottipos e Wireframes Prottipos de software como vimos neste trabalho, podem ser funcionais ou feitos em papel, os wireframes so prottipos visuais. Sua principal funo trazer uma visibilidade quanto a disposio visual das informaes de uma pgina. um entregvel bem importante do ponto de vista do usurio, pois apresenta um esboo visual do software.

94

Figura 26 Prottipos em Papel

Figura 27 Prottipo em papel com elementos impresso como auxlio

4.7

Guia de Estilos A criao de um guia de estilos pode trazer grande agilidade na criao de

softwares dentro de um rgo governamental. A funo principal de um guia de estilos permitir o reaproveitamento de componentes visuais e de interao no desenvolvimento de novos softwares. Guias de estilo podem variar na quantidade de informaes e regras que

95

possuem para a criao de telas de sistemas, mas de uma forma geral, quanto mais definies ele possuir, mais rpido ser a produo de telas e menos informaes precisaro ser contempladas em documentaes tcnicas como casos de uso, e de telas. Guias de estilo podem definir desde tipologia e padres de cores at como devero ser as confirmaes ao se clicar em botes. Geralmente oferecem um modelo de menu, de cabealho, definies para criao de formulrios e uma galeria de cones a serem utilizadas.

96

5-

CONCLUSO
O uso da prototipao gil pode trazer inmeras vantagens para o processo

de desenvolvimento de software dentro de rgos governamentais, porm seu uso ou mau uso que ditaro os benefcios e malefcios. Como toda ferramenta, s possvel alcanar um bom nvel de produtividade quando aprendemos a utiliz-la corretamente. Algumas das desvantagens da utilizao circundam os pilares que sustentam a agilidade destas tcnicas. Muitas vezes a anlise pode ser insuficiente, e a ateno do cliente em um prottipo pode fazer com que este perca o foco do objetivo final do trabalho. Quando se inicia rapidamente o processo de desenho de telas, pode-se acabar no dedicando um tempo suficiente para elaborao de ideias e solues que poderiam ser mais eficientes. O usurios podem passar a ver um prottipo de que deveria ser descartado e que no passa de uma base para o incio dos trabalhos como na verdade um reflexo do produto final, desta forma, comum que as demandas detalhes fidedignos do prottipo faam com que toda a agilidade se perca neste processo. Muitas vezes prottipos podem ser mal interpretados por desenvolvedores, porm a clareza desta representao faz com que os mesmos no sintam a necessidade de solicitar mais informaes. Este tipo de comportamento aliado com pouco domnio do negcio por parte dos desenvolvedores pode se tornar catastrfico em um longo projeto. Prottipos podem apresentar um canal de comunicao mais tranquilo entra as reas, mas no totalmente livre de rudos e interferncias como as experincias de cada uma e predisposio a entender as coisas de certo jeito. Por outro lado existem muitas questes de desempenho de sistemas e padres arquiteturais que no podem ser relatadas em um prottipo e inicialmente estas passam despercebidas pelos desenvolvedores, sendo codificadas como exemplificado no prottipo. Quando problemas de desempenho surgem muitas, clientes podem se defender atravs de prottipos e a culpa cai sobre desenvolvedores que inicialmente no teriam como prever a complexidade de certos processamentos ou massas de dados. O desenvolvimento de prottipos funcionais e evolutivos pode muitas vezes pode incorrer em bastante tempo de projeto, um fator importante para criao de

97

prottipos que estes devem ser feitos de forma gil, no sendo assim, deve-se procurar identificar outras estratgias. O destino final da maioria dos prottipos o descarte, portanto, analistas, clientes e desenvolvedores precisam ter sempre em mente que este trabalho no agregar valor ao produto final e se trata apena de uma ferramenta de produtividade. necessrio que tanto fbricas como cliente e reas de negcio que pretendem trabalhar com prottipos entendam que existe uma curva de aprendizado destas tcnicas e ferramentas. A expectativa de aumento de produtividade imediato pode ser altamente nociva para solidificao da prtica dentro de uma organizao. As metodologias de trabalho a muito estabelecidas, quando alteradas podem ter um impacto negativo de produtividade incialmente at que o sincronismo dos processos retorne a prevalecer. Apesar dos perigos presentes na utilizao de prottipos de forma equivocada acredita-se, que na maioria dos casos, o benefcio para relao entre as reas de tecnologia da informao e negcios indiscutvel. Existem inmeras vantagens na utilizao de prottipos no desenvolvimento de software, algumas so tangveis outras abstratas. Em rgos governamentais a criao de prottipos simples e despretensiosos pode acelerar o andamento de projetos, minimizando o nmero de reunies e facilitando a transmisso de informao entre os stakeholders dos projetos. Desta forma os prottipos no s servem de suporte para o desenvolvimento como tambm ferramenta de comunicao e gerenciando as expectativas de todas as partes interessadas. Em grandes projetos, quando a validao e o envolvimento das diversas partes interessadas pode ser um desafio prottipos podem resultar em um maior envolvimento dos usurios, pois permite que eles interajam e tenham maior visibilidade do sistema. Como usurios possuem maior conhecimento sobre os problemas de domnio, quanto maior for o seu envolvimento com o projeto menos res sero as chances de erros no produto final. De uma forma geral, a criao de prottipos geis pode impactar todas as etapas do desenvolvimento de solues aumentando a qualidade do processo de produo e por consequncia a satisfao dos usurios finais.

98

6-

REFERNCIAS

Concept Maps: Theory, Methodology, Technology. (2004). COGNITIVE MAPS: NEW PARADIGMS IN INFORMATION ARCHITECTURE AND INTERFACE, (p. 4). Pamplona.

Buxton, B. (2007). Sketching user experience : getting the design right and the right design. Morgan Kaufmann.

Cooper, A. (2004). The Inmates Are Running the Asylum: Why High-Tech Products. Sams Publising.

Graham, I. (2003). A pattern language of Web usability. Pearson Education Limited.

Krug, S. (2006). Don't Make Me Think! A Common Sense Approach to Web Usability. Berkley, CA: New Riders.

Morville, P., & Rosenfeld, L. (2002). Information Architecture for the World Wide Web. Sebastopol, CA: O'Reilly Media.

van der Geest, T. M. (2001). Web Site Design is Communication Design. LE TILBURG: Tilburg University.

Wroblewski, L. (2002). Site-SeeingA Visual Approach To Web. New York, NY: Hungry Minds, Inc.