Be My Chef: simulação de criação de startup e aprendizados
Bruno Nascimento1
, Caio McIntyre1
, Camila Sá da Fonseca1 1
Centro de Informática – Universidade Federal de Pernambuco (UFPE) Av. Jornalista Aníbal Fernandes, s/n - Cidade Universitária (Campus Recife)
50.740-560 - Recife - PE
{bnf, cfmi, csf}@cin.ufpe.br
Abstract: In order to begin a startup it is frequently necessary to have an
innovative idea and an engaged team. There are many cases in which ideas can’t leave the drawing board because of the lack either of investors or of people to support the project development. On the other hand, if a startup succeeds on obtaining those resources, it shall meet some challenges to make an innovative business from the idea. This paper shows the simulated creation of a startup in the Software Engineering discipline at CIn-UFPE. More than an academic project, teachers and our own requirements ended up arousing a collection of learnings and experiences that were reported. Thus, a study case is going to be presented describing a mobile application implementation, exposing the challenges such as team composition, engineering software techniques and other procedures related to a startup foundation.
Resumo: Para iniciar uma startup geralmente é necessário ter uma ideia
inovadora e uma equipe engajada. Existem muitos casos de ideias que não conseguem sair do papel por falta de investidores ou de pessoas que possam auxiliar no desenvolvimento do projeto. Para os demais casos, se uma startup conseguir esses recursos ela passa a enfrentar os desafios para transformar a ideia em um negócio inovador. Este artigo retrata a simulação da criação de uma startup para a disciplina de Engenharia de Software do CIn-UFPE. Mais do que um projeto acadêmico, as exigências dos professores e a própria cobrança interna acabou gerando uma série de aprendizados e experiências que serão relatados. Assim, será apresentado um estudo de caso descrevendo a criação de um aplicativo móvel por uma equipe de desenvolvimento, apresentando os desafios como montagem de equipe, definição de processos, técnicas de engenharia de software e outros processos que envolvem a criação de uma startup.
1. Motivação
Uma startup, segundo [1], é uma instituição humana desenhada para criar um novo produto ou serviço em condições de extrema incerteza. Dependendo do sucesso da startup e dos seus produtos esse “negócio inovador de crescimento empreendedor” [9] pode evoluir para grandes empresas (ex.: Google, Apple). Um dos principais objetivos de qualquer empresa, se não o principal, é atingir lucro. Para as startups não é diferente. Entretanto, para alcançar esses objetivos não existe uma regra exata ou uma receita. Primeiro por conta do ambiente nebuloso no qual as potenciais empresas estão inseridas
e segundo pela própria composição do time: muitas vezes além da falta de experiência, há carência de empreendedores (segundo [9], aqueles que vivem para a criação do negócio). Neste contexto de mercado, as chances de fracasso das empreitadas já seriam grandes e, para agravar esses fatores de risco, além de muito trabalho e estratégias bem definidas, muitas vezes é preciso de sorte.
Como mencionado, as condições de incerteza são inerentes ao mercado, esse ambiente junto à alta velocidade que os interesses e práticas evoluem exigem que uma startup entenda profundamente a necessidade que ela visa suprir. É fundamental que o produto/serviço a ser disponibilizado vá ao encontro dos desejos dos potenciais clientes – melhor ainda se surpreender as expectativas – e, para isso, muitas vezes a solução original precisa sofrer ajustes e mudanças até que se encontre uma solução que resolva os problemas dos usuários. Na realidade, hoje se tem a ideia que boa parte dos produtos/serviços deve estar em constante atualização para poder continuar no mercado, é o beta perpétuo. Isso só prova que para satisfazer o cliente (e assim possibilitar lucro) é preciso se adaptar – melhor ainda se a empresa previr essa futura necessidade e sair na frente – ou chega outro e toma o seu lugar.
Em alguns casos, as startups percebem que acabariam concorrendo com grandes do mercado ou que não possuem uma vantagem competitiva (isso acontece principalmente se a sua inovação for algo simples de se copiar) e a atitude certa muitas vezes é procurar um novo problema. Segundo [2], isso nos leva à conclusão que uma startup é um experimento e nela deve experimentar-se para encontrar soluções. O objetivo dos experimentos será sempre resolver os problemas dos clientes para garantir que eles vão lhe gerar retorno financeiro suficiente para que a empresa possa continuar existindo e ofertando esta solução. Em [9] ainda há um incremento de que para fazer os clientes satisfeitos é indispensável que os colaboradores estejam satisfeitos e isso provoque uma excelência no atendimento.
Analisando as pesquisas [3] e [4], logo percebemos duas tendências que estão acontecendo na internet. A primeira delas é que cada vez mais as pessoas estão acessando a internet e aplicações web por meio de aparelhos móveis tais como celulares e tablets. A segunda é que cada vez mais as pessoas gastam seu tempo online em redes sociais. E essas tendências foram responsáveis pela motivação da equipe para criar uma startup visando desenvolver uma aplicação móvel que seja integrada dentro das redes sociais. Porém, como o objetivo é criar um aplicativo inovador e que forneça a empresa um crescimento empreendedor, optou-se por olhar também outras tendências, tais como gamification [5] que serve para captar o interesse do público e auxilia na divulgação da marca e na captação de novos clientes.
Com a definição do escopo do projeto e da equipe foi necessário eleger as melhores práticas de engenharia de software para o projeto [2]. Uma das primeiras boas práticas definidas no projeto foi a escolha pelo desenvolvimento iterativo de software, essa forma de desenvolvimento se contrapõe ao modelo de desenvolvimento de software conhecido como Waterfall. No desenvolvimento Waterfall as fases de desenvolvimento de software são claramente definidas: uma vez terminada uma fase e iniciada a outra, não se pode voltar atrás. No desenvolvimento iterativo de software, esse mesmo ciclo é reduzido ao seu menor tamanho possível e repetido várias vezes usando o feedback do ciclo anterior para melhorar o próximo ciclo. Esse processo de desenvolvimento iterativo de software acabou sendo uma das bases do Manifesto [6]
para Desenvolvimento Ágil de software escrito há mais de 10 anos, que acabou se tornando uma revolução na forma de se fazer software.
Diante dessa escolha vimos a necessidade de definir uma metodologia, ou framework que auxiliasse no desenvolvimento iterativo incremental. Nossa opção foi um modelo misto que tinha práticas do RUP e de metodologias ágeis (como XP e Scrum), assunto detalhado na seção 2.3. O Scrum é um framework que vem sendo adotado com sucesso por organizações de diversos tamanhos e tipos [7]. Ele segue o manifesto ágil e segundo [8] é uma das metodologias mais utilizadas nas startups.
Elegendo essa metodologia para o nosso projeto e com um pilar de desenvolver algo que tivesse os conceitos de mobilidade, crowdfeeding e gamification decidimos seguir com o projeto. No decorrer deste artigo, será mostrado os detalhes do projeto: o
Be My Chef, o jogo, os processos e os detalhes do desenvolvimento (tecnologias). No
meio dessas subdivisões apresentamos os aprendizados que tivemos. Por fim, apresentamos as conclusões e os anexos.
2. O Projeto
2.1.Be My Chef
A proposta do aplicativo Be My Chef é inovadora em diversos aspectos. Primeiramente o sistema explora o universo de games (jogos sociais1
) em um ambiente pouco usual que é o de receitas de alimentos, além disso, através de interação social por meio mobile procura despertar o desejo por compartilhar e aprender receitas.
Sintetizando, a proposta do Be My Chef é ser um aplicativo móvel para ajudar os usuários a compartilhar/avaliar – crowdfeeding2
– e encontrar receitas para o seu dia, estimulando o uso do sistema por meio de competições e bonificações – gamification3
. Conforme mencionado anteriormente, a disciplina requisitava o desenvolvimento de um sistema intensivo em software em forma de Startup. Inicialmente propusemos o desenvolvimento de um avaliador de emoções para posts no
twitter. Entretanto, não houve boa aceitação por parte dos professores e, na realidade, já
não havia uma boa aceitação para parte dos integrantes da equipe. Essa foi a primeira grande mudança que passamos ao longo da disciplina: mudar completamente o paradigma, aprender com o que já tinha sido feito, olhar para frente, buscar um novo projeto e correr atrás do tempo perdido. Além disso, ganhamos a consciência que para uma equipe, especialmente pequena e no contexto de startups, da seguinte afirmação:
Aprendizado 1: Se os jogadores (players) não acreditarem no sistema, há uma enorme chance de o negócio não andar para frente e morrer antes mesmo de nascer.
1 Segundo o dicionário Oxford em tradução livre: a atividade ou prática de jogar um jogo on-line
em uma plataforma social.
2 Segundo crowdsorcing.org em tradução livre: a necessidade das pessoas de compartilhar
informações com as outras pessoas numa comunicação horizontal. Para esse sistema é a ideia dos próprios usuários gerarem a informação (receitas) e compartilhá-la.
3 Segundo o dicionário Oxford em tradução livre: a aplicação de elementos típicos de jogos
(pontuação, competições, regras) para outras áreas de atividade, tipicamente como uma técnica de marketing on-line para estimular o comprometimento com um produto ou serviço.
Com esse aprendizado, buscamos novas opções por meio de discussões, troca de ideias e brainstorming, retornamos à fase de Esclarecimento e Idealização. Tendo em mente a crescente busca por alimentação saudável, a busca por praticidade e os crescentes interesses em mobilidade e jogos sociais, concebemos a ideia do Be My Chef. O aplicativo é dividido da seguinte maneira: usuários (chamado de chef), empresas e administrador:
- Chef: são os usuários comuns do sistema, qualquer pessoa com um celular (inicialmente um dispositivo Android) - que se cadastram no sistema. Os usuários podem postar, buscar, avaliar, comentar e marcar (feita ou a fazer) receitas. Como diferencial o sistema propõe uma busca diversificada de receitas, ou seja, o chef pode procurar com diversos filtros e especificações restritivas ou não-restritivas. Também houve a ideia de incluir na especificação do produto um "Surpreenda-me", um motor de sugestão de receitas, algo também não encontrado em outros aplicativos de receitas. Um chef pode escolher os chefs que ele deseja seguir, acompanhando todas as atualizações deles. Todas as atividades do chef contribuem de alguma forma para sua pontuação, principal medição do desempenho no jogo. As regras do jogo e das pontuações serão brevemente explicadas no tópico sobre o jogo.
- Empresa: uma companhia existente no mundo "real" que deseje de alguma forma divulgar suas marcas dentro do Be My Chef. Em geral, as empresas que buscarão o nosso sistema serão indústrias de alimentos. O cadastro poderá ser feito por qualquer empresa, e, a princípio, todas as cadastradas poderão buscar receitas que citem os seus produtos. Para ganhar um destaque no programa a empresa poderá sugerir um desafio; para que o administrador analise a proposta e o sistema rode esse desafio alguma taxa será cobrada. Mais informações sobre os desafios (principal forma de pontuação para o jogo) e informações sobre o relacionamento entre as empresas e o administrador se encontram nos tópicos jogo e modelo de negócio respectivamente.
- Administrador: o sistema exigirá no início um administrador, que tenha as funções de usuário, porque será necessário iniciar o sistema com, no mínimo, 50 receitas de cada categoria. Havíamos pensado em criar um motor de busca para receitas públicas disponíveis na internet para que o administrador pudesse publicar, entretanto como o essa base só será necessária quando o Be My Chef estiver para funcionar, decidimos focar os esforços no sistema em si. O administrador será fundamental durante toda a existência do aplicativo (pelo menos na concepção atual), porque ele quem autoriza ou não um desafio de acordo com uma avaliação de benefício para o sistema.
2.2.O Jogo
O jogo gira em torno de níveis que o chef pode atingir. Para isso cada chef tem uma pontuação que vai sendo aumentada à medida que exerce atividades no sistema: Upload de receita: 100 pontos; Receber avaliação em receita publicada: 50 pontos; Marcar receita como feita: 15 pontos; Marcar receita como deseja fazer: 10 pontos; Ter receita publicada marcada como feita por outro chef: 10 pontos; Ter receita publicada marcada como deseja fazer por outro chef: 5 pontos; Receber comentário em sua receita: 30 pontos; Avaliar outra receita: 5 pontos; Fazer uma comentário em outra receita: 10 pts; Seguir um chef: 5 pts; Participar de desafio: 100 pontos; Ganhar desafio: a pontuação depende do desafio.
Os níveis que os chefs podem atingir são: Aprendiz (Colher) (até 1000 pontos); Cozinheiro (Colher e Garfo) (entre 1001 e 3000); Expert (Toque) (entre 3001 e 6000); Chef (Toque e Bigode) (mais de 6000).
Além disso, cada usuário tem um mural de conquistas, com os prêmios que ele já ganhou, esse mural pode ser acessado por meio do perfil do chef.
2.3.Processo
Estabelecemos um processo iterativo e incremental que na verdade é a combinação de métodos de processos bem definidos (RUP) e boas práticas de alguns métodos ágeis (XP e Scrum).
A figura a seguir sintetiza o processo que pretendíamos seguir ao longo do desenvolvimento.
Figura 1: Processso Inicial de desenvolvimento do Be My Chef
Fonte: Próprio autor
Para seguir esse processo, iniciamos listando os casos de uso e fizemos a distribuição nas iterações. Ao início de cada iteração, detalharíamos mais os casos de uso e os integrantes iriam atribuindo para si os casos de uso a serem implementados.
Entretanto, nesse ponto surgiram algumas dificuldades. A formação e a interação da equipe passaram por diversas mudanças e necessidade de adaptações. Dois principais pontos afetaram a concretização do time e, juntamente às dificuldades com as tecnologias a serem citadas no próximo tópico, dificultaram a concretização do processo e do sistema como planejado:
-"Turnover": primeiramente a equipe era formada por 4 pessoas, depois de um mês um dos integrantes precisou sair. Duas semanas depois a equipe "adquiriu" mais um integrante, o que contribui para concepção do Be My Chef como um aplicativo mobile pela experiência prévia no novo integrante. Entretanto, por motivo de força maior, o integrante teve que sair, voltamos a ser três e sem experiência nas tecnologias que iríamos utilizar.
Aprendizado 2: O conhecimento da equipe não deve estar centralizado em uma única pessoa, especialmente se houver uma restrição forte de tempo.
-Interação: o que aconteceu é que os integrantes do grupo nunca tinham trabalhado junto, então foi complicado criar um método que se adequasse aos perfis sem haver familiaridade entre os integrantes. Houve a necessidade de adequação tanto dos processos como do escopo a ser implementado.
Aprendizado 3: A definição de um processo ou métodos de processos que serão usados no desenvolvimento de um sistema intensivo em software é muito mais acertada se houver um conhecimento mútuo entre os integrantes da equipe, inclusive, e especialmente, no que diz respeito a capacidades técnicas e perfil de ação.
Diante disso, o processo que acabamos usando na prática pode ser resumido como é demonstrado na figura a seguir:
Figura 2: Processo de desenvolvimento By My Chef adaptado
Fonte: Próprio autor
Houve a necessidade de incluir as etapas de Aprendizado de Tecnologia (mais detalhes na próxima seção) e de priorização, essa etapa de priorização aconteceu porque primeiro tentamos desenvolver as telas e acabamos perdendo muito tempo com isso, principalmente pela falta de experiência. Percebendo essa dificuldade, optamos por implementar pelo menos um caso de uso que passasse por todas as etapas do sistema (da iteração com usuário; passando por, troca de informações no celular; comunicação com o servidor (webservice); armazenamento/busca no servidor; ao retorno ao usuário) porque se conseguíssemos implementar uma, significaria que poderíamos estender para os outros. E conseguimos desenvolver os UC's de criar usuário, autenticar no sistema, cadastrar receita e visualizar receita.
2.4. Tecnologias utilizadas
A arquitetura do projeto foi dividida em Cliente, Servidor Web e Banco de dados, assim como mostrado na Figura 3. Porém antes de chegarmos na arquitetura elaboramos um protótipo, feito no programa Axure [12] que está disponível nos anexos do site.
Figura 3: Arquitetura do sistema
Fonte: Próprio autor
Na parte do Cliente, desenvolvida em Android [12], está a parte de interface com o usuário, assim como algumas regras de negócio, como verificar digitação correta de E-mail na autenticação e número mínimo de caracteres na senha, que podem ser tratados localmente sem a necessidade de conectar ao servidor web para validação. Em seguida temos a parte do servidor web que foi hospedado na Amazon Web Services [10] que faz a parte da comunicação tanto com o banco de dados, este utilizando a tecnologia Hibernate, Apache/Tomcat, [15] também hospedado no mesmo local quanto com a comunicação com o aplicativo, este usando o Jersey uma tecnologia que auxilia na criação e manutenção de um Servidor Web usando a o Padrão Rest.
O desenvolvimento foi distribuído, cada integrante colaborando com sua parte e sincronizando em um repositório Git [14]. Para isso nós precisamos de uma tecnologia que nos auxiliassem nesse processo e a escolhida foi o Bitbucket [13]. O que não era esperado eram as dificuldades que iriamos enfrentar para sincronizar os códigos entre os membros, seja por desconhecimento da tecnologia ou porque ela não atendeu as nossas expectativas, que seria de sincronizar os códigos em um tempo hábil e sem conflitos.
Assim, ao longo do projeto tivemos que aprender todas as tecnologias que utilizamos. Além disso, nenhum dos integrantes (que permaneceram na equipe) trabalha com desenvolvimento, por isso houve uma dificuldade para que o projeto começasse a andar. Ficou o sentimento de que depois de termos conseguido um conjunto básico de funcionalidades e de termos enfrentado erros após erros, conseguiríamos desenvolver mais rapidamente a partir disso. Com certeza é a questão da curva de aprendizado que para as tecnologias utilizadas foi bastante alta. Tivemos, inclusive, que incluir a aprendizagem das tecnologias (além de avaliação para definir qual usar e em alguns casos de troca de tecnologia) no nosso processo.
Aprendizado 4: Ao estimar tempo e recursos é necessário contar com a curva de aprendizado de novas tecnologias e com a experiência dos integrantes.
2.5.O Projeto como Negócio
Como já mencionado o modelo de negócios do Be My Chef é através de desafios que empresas do ramo de alimentos podem propor e, com isso, divulgar os seus produtos para o seu público alvo. Além disso, as empresas podem conhecer as características e comportamento desse público-alvo a respeito dos seus produtos: o que falam e como usam.
Por exemplo, a empresa Lacta poderia se cadastrar no sistema e propor o seguinte desafio:
–Chef Sonho de Valsa da Semana
Os usuários que decidissem participar do desafio teriam que postar uma receita com o produto "Sonho de Valsa" e de acordo com algum critério pré-definido (número de curtidas, nota de avaliação, número de marcada como feita… ou uma combinação desses diversos fatores) haveria uma distribuição de pontos para o primeiro, segundo e terceiro colocado, digamos 500, 300 e 200 pontos. Além de o usuário ganhar um Títulos e por isso ficar como destaque: "Chef Sonho de Valsa da Semana" na tela principal do sistema.
Essa proposta de modelo de negócios exige uma maturação, principalmente no que diz respeito a valores. Entretanto, se mostrou como uma alternativa muito viável para os dois lados: divulga a marca e premeia o Chef.
3. Conclusões
No geral, ficamos satisfeitos com o resultado do projeto. Não concluímos todo o planejado, mas conseguimos implementar casos suficientes para validarmos a arquitetura, o desenvolvimento e a ideia. Extraímos dessa simulação de uma startup muito aprendizado e com certeza podemos afirmar agora que estamos muito mais preparados para empreender e inovar.
Nesse projeto houve lições para a equipe tanto no que se refere ao empreendedorismo, quanto à engenharia de software e até um grande aprendizado técnico de desenvolvimento para a plataforma Android.
Cometemos diversos erros que numa startup real não seriam perdoados e certamente levariam a falência da empresa, tais como não avaliar a compatibilidade entre os integrantes da equipe. Avaliações como ver se as pessoas tinham horários compatíveis, se todos tinham motivação para trabalhar no mesmo tipo de projeto e até uma análise de se teríamos integrantes de perfis diferentes para garantir que todos os conhecimentos necessários estariam dentro do próprio grupo não foram feitos.
Outro erro que poderia ser fatal numa startup, foi não aproveitar o tempo da melhor maneira. O tempo é um recurso escasso, talvez o mais escasso de todos, e o fato de termos demorado admitir o fracasso do primeiro tema e para nos reorganizar depois disso, levou a um problema de falta de tempo na execução do segundo tema, o Be My
Chef. Ou seja, o quão rápido você admite e se recupera de um fracasso anunciado pode
ser determinante no sucesso ou não do seu próximo empreendimento.
Em relação ao ponto de vista de engenharia de software cometemos um erro no dimensionamento do tamanho do projeto. Isso ocorreu em grande parte porque não previmos corretamente o quão alta seria a curva de aprendizado para programar na
plataforma Android. Usamos uma tecnologia sobre a qual nenhum integrante do grupo tinha domínio e isso custou no planejamento do projeto.
Se por um lado a escolha da plataforma Android, gerou atrasos no cronograma, por outro permitiu que todos os integrantes do grupo adquirissem conhecimento de programação dessa ambiente em constante crescimento. Isso foi um aprendizado que todos apreciaram e que veio junto aos novos conhecimentos adquiridos de empreendedorismo e engenharia de software.
Numa eventual continuação do projeto, teríamos que planejar diversos ajustes. Alguns casos de uso inicialmente previstos para serem concluídos no período desta disciplina, teriam que ser finalizados. A interface também precisaria sofrer alguns ajustes. Por conta da necessidade de priorizar certas ações, em um dado momento o design das telas foi despriorizado, e apesar de termos modelos prontos [Anexo 3] algumas telas do aplicativo ficaram deixando a desejar.
Outra melhoria que teria que certamente teria que ser feita seria na infraestrutura do aplicativo. Uma modificação muito importante seria ajustar o banco de dados e o servidor para que tenham uma estrutura que seja escalável. No modelo atual, o nosso sistema não poderia suportar muitos usuários simultâneos.
Outro grande benefício da disciplina foi a troca de experiência com as outras equipes. Ao exigir acompanhamento semanal pudemos identificar problemas comuns – e suas possíveis soluções – e aprender com a experiência dos outros.
Aprendizado 5: Nada resiste à dedicação e ao trabalho duro.
Apesar das dificuldades, não deixamos de tentar e nos esforçamos de tal forma que conseguimos superar o que – depois de começarmos a tentar – achamos que seria impossível de realizarmos.
Anexos
Os do trabalho estão no site para acompanhamento da equipe (https://sites.google.com/site/engsw20141/):
[1] Diagrama de UC's
[2] Documento de detalhamento de UC's
[3] Documento de passo-a-passo para teste do aplicativo [4] APK
Referências Bibliográficas
[1] Eric Ries. e Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. Crown Business 2011
[2] Torres, J. Guia da Startup: Como startups e empresas estabelecidas podem criar produtos web rentáveis. Casa do Código.2014
[3] Comunicações, T. -I. Brasil com 128,5 milhões de acessos BL Móvel em
Jun/14. Retidado de Teleco: http://www.teleco.com.br/3g_brasil.asp (Acessado em 28
[4] Time, M. Classe C representa 35% da base de usuários de smartphone no
Brasil. Retidado de Mobile Time:
http://www.mobiletime.com.br/12/12/2013/classe-c-representa-35-da-base-de-usuarios-de-smartphone-no-brasil/364079/news.aspx (Acessado em 28 de Julho de 2014)
[5] Exame. O que é “gamification”? Retidado de Exame.com: http://exame.abril.com.br/pme/noticias/o-que-e-gamification/ (Acessado em 28 de Julho de 2014)
[6] Agile Manifesto web site. http://agilemanifesto.org (Acessado em 28 de Julho de 2014)
[7] Sabbagh, R. Scrum: Gestão ágil para projetos de sucesso. Casa do Código. 2013
[8] A. M. M. Hamed e H. Abushama. Popular Agile Approaches in Software Development: Review and Analysis. International conference on Computing, electrical and Electronic Engineering (ICCEEE). 2013
[9] Meira, Silvio Lemos. Negócios inovadores de crescimento empreendedor no Brasil – 1. Ed. – Rio de janeiro: Casa da Palavra, 2013. 416p: il.; 23cm. ISBN: 978-85-7734-412-3
[10] Amazon. Amazon Web Services . Retidado de http://aws.amazon.com/pt/products/?sc_ichannel=ha&sc_ipage=homepage&sc_icountry =pt&sc_isegment=nc&sc_iplace=hero2&sc_icampaigntype=general_info&sc_icampaig n=ha_pt_WhatlsAWS&sc_icategory=none&sc_iproduct=none&sc_idetail=none&sc_ic ontent=default/ (Acessado em 28 de Julho de 2014)
[11] Android. Building Your First App. Retidado de http://developer.android.com/training/basics/firstapp/index.html (Acessado em 27 de Julho de 2014)
[12] Axure. Wikipédia. Retidado de Axure RP:
http://en.wikipedia.org/wiki/Axure_RP (Acessado em 28 de Julho de 2014)
[13] Bitbucket. Wikipédia. Retidado de http://pt.wikipedia.org/wiki/Bitbucket (Acessado em 27 de Julho de 2014)
[14] Git. Wikipédia. Retidado de http://pt.wikipedia.org/wiki/Git (Acessado em 27 de Julho de 2014)
[15] Hibernate. Wikipédia. Retidado de http://pt.wikipedia.org/wiki/Hibernate (Acessado em 27 de Julho de 2014)
[16] http://www.crowdsourcing.org/ [17] http://www.oxforddictionaries.com/
