• Nenhum resultado encontrado

ESTUDO DE CASO: ROCK IN RIO APP

No documento WWW/INTERNET 2012 (páginas 113-116)

APLICATIVOS MÓVEIS – UM ESTUDO DE CASO

3. ESTUDO DE CASO: ROCK IN RIO APP

O Instituto Nokia de Tecnologia (INdT) é um Instituto de Pesquisa sem fins lucrativos focado no desenvolvimento de serviços e soluções em software e hardware para dispositivos móveis. Diante desse cenário, o Apps Framework se mostrou útil para aprimorar o desenvolvimento de novas tecnologias de software. Um exemplo disso foi o aplicativo Rock in Rio App1. Este aplicativo, mostrado na Figura 3, surgiu diante da possibilidade de tornar a experiência dos participantes do Rock in Rio mais atrativa, uma vez que grande parte dos participantes não morava na cidade do evento. Dessa forma o aplicativo possuia características como: descrições das atrações, horários de shows, ver vídeos das atrações, locais, como chegar a cidade do rock, dentre outras.

Figura 3. Visão geral do aplicativo Rock in Rio.

Além do desafio tecnológico envolvendo o desenvolvimento deste aplicativo, a ideia seria desenvolver um aplicativo que fosse atrativo a um maior número de usuários. Dessa forma, foi feito um estudo para identificar o perfil dos usuários de web móvel. O propósito foi identificar quais os dispositivos que os usuários de celulares Nokia mais utilizavam para acessar a Web. Dessa forma, foram escolhidos os dispositivos das seguintes plataformas: Nokia S40, Nokia Belle e Windows Phone. Nas próximas seções são apresentadas cada uma das etapas do processo no desenvolvimento do Rock in Rio App.

3.1 Conceito

A fase de conceito consiste na definição do problema pelos clientes e a formulação de uma solução a ser apresentada ao cliente. Seu escopo se concentra em concretizar uma solução através da necessidade do cliente. Esta fase envolve dois passos:

Entender os anseios do cliente ou de uma oportunidade de inovação: neste passo foi realizada a coleta de informações para identificação dos requisitos e funcionalidades desejáveis entre os membros do evento e do INdT para iniciar o desenvolvimento do aplicativo. Para identificar oportunidades e requisitos, foram realizadas reuniões, com entrevista semi-estrutrada. Nessas entrevistas foram definidas questões abertas, para que o entrevistador pudesse coletar informações visando auxiliar no desenvolvimento de uma solução. Essas informações foram úteis também para geração das ideias, criação das interfaces e definição do cronograma de desenvolvimento do aplicativo. Todas as informações posteriormente armazenadas em um repositório.

A partir das entrevistas os dados foram organizados em briefings, que são documentos contendo requisitos e informações coletadas das entrevistas com o cliente (e.g. dispositivo para os quais os aplicativos serão desenvolvidos, interface, aplicativos concorrentes, público–alvo dentre outros), conforme a Figura 4.

As informações coletadas no briefing, durante as reuniões, são convertidas em rascunhos da solução, inicialmente estrutural, chamados drafts. Os drafts, Figura 4, são rascunhos do aplicativo que contêm informações como: navegação, um conjunto de telas, conteúdo das telas e comportamentos de uso. Este artefato é útil para que o cliente possa visualizar as telas que irão compor o aplicativo. Como o Rock in Rio é um evento de entretenimento, a necessidade do público-alvo estava apenas em saber informações sobre as atrações e palcos do evento, a modelagem do aplicativo consistiu em integrar redes sociais (e.g. Twitter e Facebook) para alimentar a fonte e compartilhamento de informações sobre o evento.

1

Figura 4. Modelo do briefing utilizado e o draft gerado na fase de Conceito.

Após esse passo, foi iniciada a prototipação do aplicativo. Nesse passo foram feitos protótipos digitais com base nos drafts, chamados wireframes. Enquanto os drafts focam na estrutura do aplicativo, os wireframes focam nas funcionalidades do aplicativos, pois demonstram de forma direta como será o aplicativo e se está de acordo com as especificações. A ideia é auxiliar o cliente no entendimento dos requisitos sem se preocupar com a interface, conforme a Figura 5.

Figura 5. Wireframe do Rock In Rio e o Mockup gerado com especificações do dispositivo.

Através dos wireframes, o cliente pode ter uma visão geral das alternativas de interação que o público-alvo pode ter antes da implementação da interface. Após a aprovação das funcionalidades com o cliente foram gerados os mockups.

Os mockups possuem uma breve descrição do conteúdo e comportamento de cada tela. Essas informações são importantes para que o cliente possa analisar o comportamento e o visual de todas as telas antes do desenvovimento. Além disso, os mockups são importantes para analisar as características das interfaces focando na usabilidade do aplicativo, pois se aproxima das dimensões da tela do dispositivo.

Tendo o aplicativo sido conceitualmente aprovado pelo cliente através da validação do mockup e wireframe, a próxima fase foi a geração de artefatos finais para o time de desenvolvimento (imagens recortadas, fluxo de navegação, especificações de design). Esta fase consiste em repassar as equipes de desenvolvedores todas as decisões tomadas com o cliente, o escopo do aplicativo e os artefatos finais.

3.2 Desenvolvimento

A fase de Desenvolvimento consiste na codificação e validação das funcionalidades, com base nos artefatos gerados na etapa de Conceito. Para facilitar o desenvolvimento, as funcionalidades foram divididas em times de desenvolvimento e organizadas por um fluxo de telas, chamado workflow. Essa organização é útil para

gerenciamento de projetos muito complexos, que precisem ter equipes de desenvolvimento distribuído de software. Dessa forma, o aplicativo foi dividido em módulos de desenvolvimento, considerando o fluxo de navegação para melhor visualização e entendimento do aplicativo por parte da equipe de desenvolvimento, conforme a Figura 6.

Para o desenvolvimento do Rock in Rio App, o workflow foi dividido entre quatro desenvolvedores.

Como todos os requisitos foram validados com o cliente, através de reuniões, o processo de codificação tornou-se menos trabalhoso. Um cronograma foi elaborado estipulando um prazo de um mês, devido a metodologia adotada, conseguiu-se diminuir esse prazo em duas semanas, gerando nesse período duas releases, que são versões do aplicativos estáveis e prontas para entrega.

Além disso, a divisão do desenvolvimento por workflow permite que a interface de usuário seja feita de maneira independente da infra-estrutura de execução que controla o fluxo e o processamento dos dados da aplicativo. Para melhor gerenciar o tempo de desenvolvimento, cada equipe utilizou a metodologia de desenvolvimento iterativo e incremental Scrum, cada estória estava relacionada a uma tela a ser implementada, por exemplo, para a tela inicial do aplicativo: “Eu como usuário quero poder escolher inicialmente que seção desejo visitar no aplicativo Rock In Rio: Notícias, Fotos, Vídeos ou Programação”. O propósito com isso foi validar o aplicativo com o cliente e com isso diminuir os defeitos e maximizar o tempo de entrega do produto final.

Outro ponto importante na utilização dessa metodologia é a utilização de diversos ciclos de validação pelos stakeholders, tanto dos testadores quanto do cliente e os responsáveis pelo gerenciamento do projeto.

Figura 6. Workflow de tarefas do Rock in Rio App.

Após o desenvolvimento dos módulos é feita a integração entre as telas criadas por um grupo e o código gerado pelo outro grupo. Ao término dessa etapa, um pacote foi gerado e liberado para equipe de Qualidade (QA), esta etapa de QA se baseia tanto em testes funcionais quanto não-funcionais e, também, utiliza guias específicos da Loja de Aplicativos da Nokia para validação de apps. Essa equipe é responsável por realizar testes para validar o comportamento da aplicação.

Ao fim dos testes funcionais foram feitos testes de usabilidade com possíveis usuários do aplicativo, onde foram analisados itens como: usabilidade do aplicativo, familiaridade com o dispositivo, eficiência na utilização. O propósito com isso foi tornar a experiência dos usuários mais agradável possível, de forma a atender todas suas necessidades.

O pacote final foi liberado para o cliente, para aprovação do cliente. Após a aprovação, o time de Publicação e Marketing disponibilizou uma release inicial. Esses pacotes contém informações contendo todas as funcionalidades esperadas para o aplicativo. Estes pacotes são de responsabilidade da equipe de Publicação e Marketing, descritas na Seção 3.3.

3.3 Publicação e Marketing

O escopo da fase de Publicação e Marketing está na comunicação entre os envolvidos no desenvolvimento do aplicativo, o cliente e o usuário final. Além da interação entre a equipe de desenvolvimento e cliente, esta fase é responsável pela definição do escopo das atividades desenvolvidas, bem como a entrega das releases ao cliente antes da publicação final. A publicação depende da interação com as outras fases do Apps Framework. Porém, suas fases não são interdependentes, ou seja, não precisam acontecer sempre na mesma ordem ou ao mesmo tempo, mas são todas obrigatórias.

A etapa de Publicação e Marketing envolve dois passos, primeiramente um de publicação e promoção de um aplicativo, e posteriormente manutenção e monitoramento. O passo de publicação e promoção compreende a publicação do vídeo e o lançamento do pré-release. Com esses recursos a equipe gera os roteiros para a criação do banner promocional (briefing spotlight) e para a produção do vídeo (briefing para o vídeo promocional). O passo de monitoramento e manutenção ocorre após a publicação e promoção do aplicativo. Após o desenvolvimento e validação com os clientes, o Rock in Rio App foi disponilizado na loja da Nokia, Nokia Store2, para monitoramento sobre a satisfação dos usuários e manutenção do aplicativo.

A manutenção é semelhante a uma etapa de pós-venda, são recebidos feedbacks diretos dos usuários para a solução de seus problemas através das redes sociais. Uma importante estratégia adotada para o monitoramento do Rock in Rio App foi utilizar os feedbacks dos usuários na Nokia Store. Através desse monitoramento foi possível identificar e relatar aos clientes e stakeholders a repercussão ou performance do Rock in Rio App. Além disso, o usuário utiliza escalas para o grau de satisfação ao utilizar o aplicativo com comentários que são utilizados para melhoria em novas versões ou em outros aplicativos.

3.4 Pesquisa e Cooperação

A fase de Pesquisa e Cooperação consiste na identificação de oportunidades de pesquisa através de dificuldades no desenvolvimento dos projetos de Apps do INdT. Essas oportunidades tem como escopo:

Prospecção Tecnológica; Identificação, Estudo e a avaliação de oportunidades em novas plataformas de desenvolvimento de aplicativos. Estas oportunidades são identificadas durante a coleta de dados nas fases de Conceito e Desenvolvimento e armazenadas no repositório de ideias.

Além do próposito de utilizar as oportunidades identificadas, esta etapa procura realizar cooperação com universidades tanto para aprimoramento das equipes envolvidas quanto para formação de uma base de conhecimento dentro da universidade permitindo o contato de alunos de graduação e pós-graduação com o cotidiano do desenvolvimento profissional de apps, possibilitando uma experiência desde a ideia (conceito do aplicativo) até o acompanhamento (marketing & publicação) não deixando de lado a pesquisa, permitindo a contribuição dos aspectos práticos com a comunidade científica. Além disso, essa fase consiste na análise do impacto do mercado de aplicativos que possam ser desenvolvidos.

Uma das oportunidades de pesquisa identificada no desenvolvimento do Rock in Rio App, foi a criação de um novo tocador de vídeo integrado ao aplicativo para melhor performance. Esse tocador é utilizado no desenvolvimento de outros aplicativos que utilizam dados multimídia. Além disso, uma importante contribuição, adquirida com o Rock in Rio, foi a diminuição do consumo de dados da Web, visando melhorar a atualização dos dados no lado do dispositivo. Isso é importante para melhorar a experiência do usuário ao utilizar o aplicativo, uma vez que grande quantidade de informações pode gerar grande consumo de dados.

No documento WWW/INTERNET 2012 (páginas 113-116)