Configurao das preferncias de conduo atravs dos dispositivos mveis Lucas T. Turchet1, Ricardo Gamba e Silva1 1Instituto de Pesquisas TecnolgicasUniversidade de So Paulo (USP) So Paulo, SP Brazil {lucasltt,ricardogamba}@gmail.comAbstract.Thispaperdescribesasoftwareprojectasaplatformfora hypotheticalcompanycalledMoToRBRAS.Themainobjectiveistoanalyze theapplicationanduse of the concepts of software engineering based on the techniquesdescribedintheSWEBOKonaprojectforalargeautomotive companythatwantstoinnovateintheirfieldofsoftwareforthe automobile. Theuseofthesmartphonetomakedrivingpreferencessuchaspositionof mirrors, seats and radio has been proposed. A possible future extension of this projectinvolvesthe creation of applications that indicate consumption of the vehicle and the need for maintenance of mechanical and electrical system Resumo.Estedocumentodescreveumprojetodesoftwarecomoplataforma paraumaempresahipotticachamadaMoToRBRAS.Oobjetivoprincipal analisar a aplicao e o uso de conceitos de engenharia de software com base nastcnicasdescritasnoSWEBOKemumprojetoparaumaempresa automobilsticadegrandeportequedesejainovaremsuareadesoftware paraoautomvel.Foipropostoousodosmartphonepararealizaras prefernciasdeconduocomoposiodeespelhos,bancoserdio.Uma possvelfuturaextensodesteprojetoenvolveacriaodeaplicativosque indiquemoconsumodoveculoeanecessidadedemanutenodosistema mecnico e eltrico. 1. Introduo ao Projeto Atualmente o automvel tido como bem de consumo de grande relevncia no mundo, sendo que em 2013 82.8 milhes de unidades foram vendidas no mundo, 4.2% a mais do que em 2012 (CNBC, 2014). O mesmo tambm se reflete no Brasil, j que a indstriaautomobilsticamovimentou106,8bilhesdedlaresem2012,participando em 5% do PIB nacional deste ano (ANFAVEA, 2014) Umoutrobemdeconsumoquetemumcrescimentoaceleradoentrea populaomundialotelefonemvelinteligente,conhecidopopularmenteporseu nomenoidiomaingls:smartphone.Estesalmderealizarchamadastelefnicas tambmcontamcomacessoInternet,possuemsistemasoperacionaisprpriose permitem ao usurio a instalao de aplicativos. Segundo a empresa ERICSSON (2013) o nmero de assinaturas de servios de telecomunicaes para estes dispositivos era de 1.2 bilhes em 2012 e dever atingir 4.5 bilhes at 2018. Alm disso, o uso de dados por estes dispositivos dobrou entre 2012 e 2013 e esperado que aumente em 12 vezes at 2018 (ERICSSON, 2013) A aplicao inicial a ser desenvolvida ser basicamente uma integrao entre os smartphonesatuaiseummodelodeautomvelfabricadopelaMotorBrs.Neste projeto,osmartphonedousurioserusadocomoumaformadeidentificaodo mesmoemrelaoaoveculo,permitindoadefiniodeumasriedeconfiguraes pessoais como posies de bancos e espelhos, preferncias da direo eltrica, estaes derdiopreferidasedestinosusadoscommaiorfreqncianoGPS.Talintegrao dever ser feita atravs da tecnologia NFC (do ingls,Near Field Communication) que permite a comunicao sem fio entre dispositivos compatveis, a poucos centmetros de distncia.Estatecnologiaserutilizadaparaaleituradasinformaesdosmartphone do usurio, permitindo que o sistema do veculo identifique seu usurio e carregue suas preferncias de uso do automvel. A figura a seguir descreve de forma sucinta a arquitetura do sistema proposto: Figura1: Esquema bsico de arquitetura da aplicao proposta. 2. Condies e Caractersticas Importantes Osistemaestarintegradoaatuadoresquecontrolarofatorescrticos conduo de veculos automotores (como posio de bancos e espelhos), assim defeitos desoftwarepoderiamameaarindiretamenteavidadocondutor,passageiroseoutras pessoas.Porexemplo,amovimentaoindevidadobancodomotoristaduranteuma conduo em alta velocidade poderia causar uma distrao fatal.Afimdeseevitarpossveisriscosvidahumana,osistemaresponsvelpor controlar estes atuadores mecnicos somente poder funcionar quando o veculo estiver parado,comofreiodeestacionamentoacionado.Estalimitao,almdeaumentara segurana,nodevetrazerqualquerincmodoaousuriojqueajustesdebancoou espelhos devem ser feitos apenas com o veculo parado, como determina a legislao de trnsitobrasileira.Estaumatcnicaquevisalimitaodedanos,citadono (SWEBOK,2014)comoumadastcnicasparaareduodoriscodefalhasem softwares de segurana crtica.Esteprojetovisaoestudodasprincipaisdisciplinaspropostanareferncia bibliogrficaproposta(SWEBOK,2014).Nenhumcustooulimitaesderecursosfoi levado em considerao na adoo das solues tomadas do decorrer deste projeto. 3. Disciplinas do SWEBOK AsdisciplinasdoSWEBOKseroaplicadaspelostimesdedesenvolvimento conforme segue:3.1 Requisitos de Software Como este projeto utilizar o SCRUM como seu mtodo de desenvolvimento,o usodeentrevistaspessoaisquepermitemconversarcomoclienteecomaspartes envolvidasomelhormtododeescolhaparacoletarasinformaesnecessriase levantarosrequisitosparaodesenvolvimento,evitandoequvocos(PAETSCH, EBERLEIN e MAURER, 2003) Em todas as abordagens de desenvolvimento gil, o mtodo mais adequado para realizaraanlisederequisitos,identificandoevalidandoassimasuaconsistncia, plenitude,viabilidadeeambiguidadeapriorizaodosrequisitos,onde implantaremosprimeiramenteosrequisitosquesoprioritriosecapazesdeagregar maisvaloraosoftware.Comoduranteodesenvolvimentooentendimentodoprojeto evoluienovosrequerimentossoadicionados,esseprocessodepriorizaoser repetidodurantetodooprocessodedesenvolvimento.(PAETSCH,EBERLEINe MAURER, 2003) Para validar os requisitos e certificar que eles esto de acordo com o sistema que proposto,serorealizadasreuniesfrequentesparamostrarqueoprojetoestde acordo com o cronograma e com os objetivos, aumentando assim a confiana do cliente eindicandoproblemasnumtempomaiscurto.Tambmserodisponibilizadosparao clienteostestesdeaceitaoparavalidarseosistemaesttrabalhandodemaneira esperada, e se no, indicar o problema. (PAETSCH, EBERLEIN e MAURER, 2003) 3.2 Design de Software ODesigndesoftwareumaparteimportantenoprocessode desenvolvimento desoftware,permitindoqueoengenheirodesoftwareproduzavriosmodelosque criamumaespciedeblueprint da soluo a ser implementada. Ns podemos analisar esses modelos e determinar se eles satisfazem ou no os requisitos. (SWEBOK, 2014) Osaplicativosmveissediferenciamdosaplicativosdedesktoppeloseu ambientedeexecuoparticular,limitaoderecursos,requisitos de alta autonomia e competionomercado.Essassituaescriamumanecessidadedeprocessosde desenvolvimentoespeciaisquesuperamestesdesafios,possibilitandoacriaode produtos com alta qualidade. (CORRAL, SILLITTI e SUCCI, 2013) Pararealizaranliseemedidasdosoftware,permitindoumaavaliaoda aplicaoeprevendoumdesigndequalidade,serutilizadaatcnicaOOAD(Object OrientedAnalysisandDesing),quepermitemuitosbenefcioscomoreuso, decomposiodoproblemaempequenaspartes,permitindoumfcilentendimentoda arquiteturaauxiliandoassimnasmodificaesfuturas.Essatcnicapossui caractersticas como localizaes, encapsulamento, ocultao de informao, herana e abstrao de objetos. (JAMALI, 2006) Comoobjetivodeminimizaracomplexidadedosoftware,asseguintes consideraes de design sero tomadas: (HOMER et al., 2008) Separarreasdeinteresse,dividindoemcomponentesquecompartilhame menor nmero de funcionalidades. Certificar que cada mdulo tenha uma nica responsabilidade Certificar que um objeto no dependa de detalhes internos de outros objetos No duplicar funcionalidades Identificar os componentes necessrios na aplicao Agrupar componentes distintos em camadas lgicas No sobrecarregar a funo de cada componente 3.3 Construo de Software AconstruodeverseguirasdiretivasdoSCRUM.Funcionalidadesdevemser implementadasorientadasauserstories e subdivididas emsprints de no mximo 30 diascorridos.(SCHWABEReSUTHERLAND,2011).Inicialmente,ossprintsdevem durar uma semana, seguindo as recomendaes de (ROTHMAN e HASTIE, 2013), que citaofatodemuitostimesnovosaosmtodosgeisteremdificuldadeemrelaoa estriasmuitograndes.Assim,recomenda-seousodeiteraesdeumasemana (ROTHMAN e HASTIE, 2013) O uso de mtodos geis, entre eles o SCRUM, oferecem uma srie de vantagens emrelaoaomodelocascatatradicional,segundo(TRIMBLEeWEBSTER,2012) mtodosgeisencurtamociclodedesenvolvimentoquebrandograndesprojetosde software em pedaos pequenos e mais fceis de gerenciar. Alm de facilitar interaes entredesenvolvedoreseclientes,gerandosoluesmaisefetivas.Narefernciaacima osautores,membrosdoNASAAmesResearchCenter,apresentamosresultadosda adoodemtodosgeisnodesenvolvimentodesoftwaresdecontroledemisso (conhecidoscomoMCTMissionControlTechnologies)emparceriacomoJohnson Space Center e o Jet Propulsion Laboratory. Entre suas concluses destacam-se que o desenvolvimento gil produz solues melhores para os clientes, cria um time cliente-desenvolvedor mais efetivo e unificado e produz melhores resultados a custos menores queosdeumdesenvolvimentotradicional(TRIMBLEeWEBSTER,2012).Porfim, (TRIMBLEeWEBSTER,2012)destacaqueotimedesenvolvedor-clientepode reagireseadaptarmaisrapidamentecomosmtodosgeise,porserummtodo iterativo, contnuo e integrado, o resultado um time mais produtivo e um produto mais efetivo.3.3.1 Plataformas mveis escolhidas Paraesteprojetoforamescolhidasasduasprincipaisplataformasmveis disponveisnomercadoatualmente,quesooAndroid,desenvolvidopelaempresa Google e o IOS, desenvolvido pela Apple. Entende-se aqui por Plataformas mveis os sistemas operacionais instalados nos smartphones, ou telefones mveis inteligentes. FORBES (2013) apresenta um comparativo sobre o posicionamento de ambas as plataformas no mercado de dispositivos mveis em 2013: AndroidPlataformamaispresentenossmartphonesfabricadosatualmente, instaladoem81%dosaparelhosproduzidosnoterceiroquadrimestrede2013.Apesar disso,66%destesdispositivossodemenorvalorfinanceiro,deat215dlares (FORBES, 2013). IOS Embora presente em apenas 12,9% dos dispositivos produzidos, o IOS da Apple corresponde a 56% dos lucros da indstria de dispositivos mveis. Alm disso, a Applepossuiumasignificativamaioriaemvendasdeaplicativosparasmartphonese tablets, uso de navegadores de Internet e visitas de anncios na rede. A Apple tambm lidera o Android na adoo para uso corporativo (FORBES, 2013). Resumidamente,foiescolhidooAndroidporsuaexpressivapresenanosdispositivos produzidos e o IOS por sua tambm expressiva liderana no mercado financeiro. 3.3.2 Equipe de desenvolvimento Adivisodeequipesdeverserfeitadeacordocomosdiferentescontextosdo projeto.Nestecaso,foramidentificadosquatrodomniosdistintos,queso:clulade desenvolvimentomvelparaiOS,outranosmesmosmoldesparadesenvolvimento Android.E,paraaparteembarcada,sero:Umaequiperesponsvelpelohardwarede leitura das informaes no dispositivo mvel, bem como controladores dos motores que irofazerosajustesergonmicosnoveculo.Acomunicaocomocomputadorde bordotambmficasobresponsabilidadedestaequipe.Porfim,altimaequipe responsvelpelodesenvolvimentodocomputadordebordo,instalaodosistema operacional e desenvolvimento dos softwares de controle.Otamanhodestasequipestambmserdefinidodeacordocomasdiretivasdo SCRUM,emqueserecomendamequipesdedesenvolvimentomaioresdetrspara haver maior interao e ganhos em produtividade e menores que dez membros para se evitarmaioresesforosdecoordenao,umavezqueequipesmaioresquenove membros geram muita complexidade para se gerenciar em um processo emprico. No entramnestacontagemoscrummastereoproductowner,amenosqueeles desempenhemalgumtrabalhodiretamenterelacionadoaodesenvolvimento (SCHWABER e SUTHERLAND, 2011) A disposio inicial das equipes ser a seguinte: Equipe mvel (iOS): 1 Scrum Master, 2 Desenvolvedores, 1 Tester, 1 Analista de Requisitos; Equipemvel(Android):1ScrumMaster,2Desenvolvedores,1Tester,1 Analista de requisitos; Em comum s equipes mveis: 1 Product Owner; Equipe Embarcada (hardware): 1 Scrum master, 3 Desenvolvedores, 1 Tester, 1 Analista de requisitos; EquipeEmbarcada(computadordebordo):1Scrummaster,2 Desenvolvedores, 1 Tester, 1 Analista de requisitos. 3.3.3 Processo dirio de desenvolvimento daily meetingOsmembrosdecadaequipedevemsereunirdiariamenteparadiscutiro andamento de suas atividades e possveis impedimentos, seguindo as diretivas do scrum guide.Possibilidadesdeatrasotambmdevemsersemprediscutidas.Estasreunies devemdurarnomximo15minutos,sendoo scrum master o responsvel por garantir que a reunio no exceda este tempo. Caso reunies mais duradouras sejam necessrias, estas devem ser arranjadas pelos membros da equipe (SCHWABER e SUTHERLAND, 2011).Ainda seguindo recomendaes de ROTHMAN (2013), essas reunies contaro comumquadroKanban,ondeastarefaspendentespodemservisualizadaspelos membros.Dessaforma,otimepodeveresentirotrabalhoemprogressoeento elimin-lo (ROTHMAN e HASTIE, 2013). 3.4 Teste de Software AfasedetestesdegrandeimportnciaparaaMotorBras,umavezqueo produtofinaldodesenvolvimentoirinteragirdiretamenteosseusclientesfinais.Os sistemas desenvolvidos devero ser altamente estveis e contar com boa usabilidade, de formaatransmitiraosusuriosumapercepodequalidadecondizentecomoquese espera de uma grande montadora nacional. Alm disso, deve-se ressaltar que, pelo fato deossistemasdesenvolvidosporestedepartamentofuncionaremnoconsolede veculos automotores, aqueles devero evitar quaisquer distraes ao condutor. Portanto o produto final precisar ser avaliado quanto a fatores de segurana. O processo de teste atcnicaEstadodaartenaindstriaautomotiva,sobretudodevidoafatoresde segurana (BOTASCHANJAN et al., 2005).Os testes devero ser feitos durante ossprints no processo de desenvolvimento. Testes unitrios devem ser realizados pelos prprios desenvolvedores e com auxlio de ferramentasdedebug,quandonecessrio (SWEBOK, 2014). Este teste normalmente feitoporumprogramadorepreparadoapsacodificao.Opropsitodomesmo encontrareremoveromximodeerrosnosoftware(SELVAMeKARTHIKEYANI, 2011) Apsostestesunitriosdeveroserfeitostestesdeintegraoentreos diferentes componentes desenvolvidos, estes testes podero envolver diferentes equipes edevergarantirqueasinterfaceseacomunicaoentreosmdulosestocorretos.Nestes testes recomendvel a participao dos product owners, pois neste momento j possvel uma visualizao satisfatria do comportamento do sistema, o que possibilita aos mesmos uma avaliao preliminar de aceitao do produto. Eventuais defeitos aqui encontrados devem ser direcionados equipe responsvel para avaliao e correo. Por fim, os artefatos desenvolvidos devem ser instalados em dispositivos reais e no hardware do automvel para avaliao final. Estes testes podem envolver pessoas de outrasreasdaempresacomoespecialistasemergonomia,marketingeosproduct owners. Estes testes devem envolver trs escopos principais: Aceitao,quedeveravaliarseosistemaatendeaoseucritriodeaceitao, determinandoseoseucomportamentoatendeaosrequisitosestabelecidospela organizao (SWEBOK, 2014). Segurana,quedever avaliar se o sistema est protegido de ataques externos. Emparticular,estestestesdevemavaliaraconfidencialidade,integridadee disponibilidadedossistemasesuasinformaes(SWEBOK,2014);Aqui,entende-se porseguranaquaisqueraspectosdosoftwarequepossaminfluenciarna segurana de seuusuriofinal,taiscomodistraesoudefeitosquepossamdealgumaforma interferir na conduo do veculo.Usabilidade,quedeveravaliaroquofciloaprendizadonousodosistema pelos seus usurios (SWEBOK, 2014). Este escopo tambm dever abranger a avaliao sobre possveis distraes que o sistema pode vir a causar ao condutor. 3.5 Manuteno de Software Aspectos como correes no software e melhorias de qualquer finalidade aps a entrega sero tratados como Manuteno do Software. (SWEBOK, 2014) Umapesquisafeitamostrouadistribuiodanecessidadedemanuteno baseadaemquatrocategoriasdemudana.Foiconcludoque75%doesforoda manutenoestodistribudosnasduasprimeirascategorias(BENNETTeRAJLICH, 2000). Adaptativas: Alteraes no ambiente de execuo do software Perfectivas: Novos requerimentos do usurio Corretivas: Correo de Erros Preventivas: Alteraes para corrigir problemas futuros Destamaneira,comoofococentraldesseprojetoestnodesenvolvimentode aplicativosmveis,asprincipaiscaractersticasdemanutenoquesoesperadasse distribuememmelhoriasdeusabilidade,novasfuncionalidadeeampliaoda compatibilidade com outros dispositivos. Umaextensodomodelodeestgiosparamanutenopropostapara softwaresquesoutilizadosporumnmeroaltodeusurios,comoocasode aplicativosmveis.Estemodelolevaemconsideraooversionamentodesoftware apsmudanassignificativasnamudanadosoftware,enquantocorreese manutenesnecessriassodesenvolvidasnamesmafase:(BENNETTeRAJLICH, 2000) Figura 2. Diagrama de versionamento 3.6 Gerenciamento da Configurao de Software Anecessidadedagernciadeconfiguraodesoftwaresautomotivosest crescendosignificativamentecomoconsequnciadeumcontnuoaumentonovolume desoftwareemveculosetambm graas possibilidade de se atualizar este software duranteociclodevidadoautomvel(HEINISCH,FEILeSIMONS,2004).Assim, essencialaintroduodeummodeloeficienteparaagernciadeconfiguraodos softwares e mesmo hardwares desenvolvidos ou homologados neste departamento. Para este projeto sero selecionados os seguintes itens de configurao (ICs): Cdigos fontes; Cdigos de configurao (ligam e desligam funcionalidades do software); Hardwares (controladores, leitores de NFC, computador de bordo); Documentao; EstesitensserogerenciadosatravsdocontroladordeversesGitHubEnterprise, detalhado no item 3.3.9 (Ferramentas e Mtodos). Paraaseleodeconfigurao,foiescolhidoomodeloexplcito(HEINISCH, FEILeSIMONS,2004),ondereleasesvlidasdesoftwaredevemserexplicitamente definidas.Nestemodeloonmerodeconfiguraes vlidas limitado, o que segundo os autores oferece uma srie de vantagens como a reduo de possveisfontes de erros, almdeservantajosoparafuturasatualizaesdesoftwarequepodemserfeitas dispensando-se a verificao de configurao. Por exemplo, liberada uma nova verso para um controlador de ABS (Antilock Brake System), denominada A1.1.9 (fictcia). No modeloexplcitodefine-sequeestaversodesoftwaresomentepodeserinstaladano controlador C, nas verses entre 2.0.1 2.0.9 (tambm fictcios). Nenhuma outra opo de configurao (ainda que compatvel) permitida pelo fabricante.O volume continuamente crescente de software em veculos e a possibilidade de atualizaesnosmesmosduranteociclodevidadoveculoexigeumaseleode configuraoexplcitaeadefiniodedependnciasbaseadasemcontratosou interfaces (HEINISCH, FEIL e SIMONS, 2004). (HEINISCH, FEIL e SIMONS, 2004) ainda prope um modelo de configurao dereleasesdehardwareesoftwareusandoummodelodeentidaderelacionamento (MER): Figura 3. MER para a definio de releases automotivas de hardware e software. Verses especficas de hardware podem ter seu software em sua memria ROM (Read-Only Memory), o que torna o software inseparavelmente conectado ao hardware. OqueexplicaoporqudeumaECUpossuirde0anmdulosflashware,0ocorre quandoosoftwareestlocalizadonaROMdocontrolador,enquantoquede1an ocorrequandoosoftwareestlocalizadonamemriaflash.Paraomduloflasheste pode ser executado em 1 ou mais ECUs. Valores codificados (na figura: coding values) podem ser utilizados para ligar oudesligarcertasfuncionalidadesnohardware,etambmdevemfazerparteda gerncia de configurao.Assim, uma release de hardware consiste den ECUs e uma release de software consistedemdulosflashwareeseusvalorescodificados.Esterelacionamentodefine quais releases de software so compatveis com cada release de hardware. 3.7 Gerenciamento da Engenharia de Software OGerenciamentodaEngenhariadeSoftwarepodeserdefinidocomoa aplicaodeatividadesdegerenciamentocomoplanejamento,coordenao,medio, controle e gerao de relatrios. (IEEE610.12-90, 1990) Apesardeserpossveldizerqueoumprojetodeengenhariadesoftwarepode sergerenciadocomoqualqueroutroprojetocomplexo,existemalgunsaspectosdo produtosoftwareedeseuciclodevidaquedificultamumgerenciamentoefetivo (SWEBOK, 2014): A falta de percepo do cliente da complexidade de um software. Por existir a necessidade de mudanas no software, o processo acaba sendo mais iterativo que sequencial. Rpida mudana na tecnologia envolvida. Umfatorchavequecontribuiparaosucessooufalhadeumprojetooseu gerenciamento.Estudosnaindstriadesoftwaremostramfrequentementequems prticasdegerenciamentosoatribudasaumacrisedequalidade.Estesestudos mostramquesomente20%dosprojetossoimplementadosdeacordocomo planejamento e que cerca de 66% apresentam altos prejuzos (JAVED, 2007) Evidncias deboas e ms prticas de gerenciamento da engenharia de software so descritas na literatura (JAVED, 2007):

Boas PrticasMs Prticas Estimar o projeto de forma realistaCobrana de cronograma excessiva Entender o problema do clienteMudar as necessidades do usurio Especificaes de Requisitos ClaraFalta de especificaes tcnicas Controle e Gerenciamento do EscopoFalta de um plano de projeto Reconhecimento de desempenhoEstimar custos sem preciso Gerenciamento de risco contnuoFalta de pessoas experientes Controle de MudanasFalta do envolvimento do usurio Aplicao de MtricasFalta de comunicao Uso de Tecnologia maduraEspecificaoderequisitomal documentada 3.8 Processos de Engenharia de Software Como mencionado anteriormente no tpico 3.3 sobre construo, o processo de desenvolvimentodeverseguirasdiretivasdoScrumGuide,propostopor (SCHWABEReSUTHERLAND,2011).Aofinaldecadaciclo,ousprint,asequipes deverorealizarumareuniodenominadaSprintRetrospective(SCHWABERe SUTHERLAND,2011)emqueosmembrosdiscutemsobreoquefoifeitonosprinte propemelhoriasaoprocesso.Estasreuniesdeverodurarnomximo3horaspara cadamsdesprint,segundo(SCHWABEReSUTHERLAND,2011)eserode extremaimportnciaparaoamadurecimentodoprocessodedesenvolvimentoda MotorBrs. Para se medir o sucesso do processo sero adotadas algumas medidas de carter quantitativoqueterodoisfocosdistintos:ProdutividadeeQualidade,quesero medidos por equipe da seguinte forma: Produtividade:Quantidadetotaldehorasgastaspelaequipenoprojetodividido pelo nmero de user stories implementados; Qualidade:Quantidadetotaldedefeitoscorrigidosdivididopelonmerototalde horas de desenvolvimento. Os valores de ambas as medidas acima devero diminuir com o tempo medida queasequipesadquiriremmaiornveldematuridadeeintegrao.Estesvalores deverosercontinuamenteacompanhadospelagerncia,quepoderestipularmetas para as equipes com base neles. 3.9 Ferramentas e Mtodos Parasuporteatividadedeconstruodosoftwareserusadaasoluodo GitHubEnterpriseparaocontroledeverses.A ferramenta uma das mais populares no mercado, prov uma srie de funcionalidades que fazem do gerenciamento de cdigo uma experincia mais fcil e til, alm de oferecer uma interface web de gerenciamento e algum para ligar caso se precise de ajuda (SPOLSKY, 2013) SegundoofornecedordoGITHUBENTERPRISE(2014),suasoluoainda oferececontroledeacessoaorepositrio,quepodeserintegradocomsistemasde autenticao como LDAP e CAS, e permite que o sistema todo funcione nos servidores daempresadentrododomniodeseufirewall.Esteltimofatordecisivoparaa escolha do GitHub, uma vez que oferece maior segurana propriedade intelectual que ser desenvolvida. OGitHubaindaintegrvelcomamaioriadasferramentasdemercado existentes como Eclipse, Xcode e Visual Studio, alm de ser escalvel, atendendo desde pequenas startups at empresas de nvel global (GITHUB, 2014) 3.9.1 Issue Tracking Esta ferramenta, alm dos benefcios j citados no tpico anterior tambm conta comumafuncionalidade denominada issue tracking (acompanhamento de defeitos), quepermitedocumentardefeitosencontrados,chamadosissues,eclassific-losem categorias,chamadaslabels(etiquetas).Istopermitiraimplantaoda ClassificaoOrtogonaldeDefeitos,mencionadano(SWEBOK,2014)comouma tcnicaquepermiteclassificarosdefeitosdeacordocomaetapadedesenvolvimento em que surgiram. Por exemplo, defeitos relacionados interface do software podem ter sidooriginadosemumprocessodedesigninadequadoAssim,melhorando-seo processo de design deve reduzir o nmero de defeitos de interface (SWEBOK, 2014).A figuraaseguirilustraumexemplodainterfacedeIssueTrackingdoGitHub Enterprise: Figura 4. Interface do GitHub Enterprise para a funcionalidade de Issue Tracking. Na figura, possvel observar o uso dos labels na ferramenta. Os labels podem serassociadosaosissues,permitindoclassific-losdeacordocomcritriospr-estabelecidos. Mltiplas labels podem ser associadas a cada issue. 3.10 Qualidade de Software Dadasasdiversasdefiniesparaqualidadedesoftwareexistentesna bibliografia,estetrabalhoaadotarcomosendoAlcanarnveisexcelentesde adequao ao uso (SWEBOK, 2014). Esta definio a que os autores julgaram mais adequada ao contexto a que se prope o projeto da Motorbrs, que priorizar sobretudo a usabilidade e segurana dos sistemas desenvolvidos. Paraagarantiadaqualidade,todosossistemasembarcadosdesenvolvidos devero seguir dois padres da indstria automotiva, que so: Padres de cdigo MISRA Originalmentecriadoparafacilitarprticasdecodificaoseguraseconfiveis paraaindstriaautomotiva,aMotorIndustrySoftwareReliabilityAssociation (MISRA)crioupadresdecodificaoquetmsidoadotadosatmesmoporoutros setoresdaindstria,comoTelecomunicaes,Aeroespacial,Defesa,etc.MISRA C um padro de desenvolvimento de software para a linguagem C que facilita asegurana,portabilidadeeconfiabilidadedesistemasembarcados.(KLOCKWORK, 2012) ISO-26262 um padro de segurana funcional, publicado pela Organizao Internacional dePadronizao(doingls InternationalOrganizationforStandardization,ISO),que visaaseguranadeveculosautomotores.umpadroamploquecobremuitos aspectosdociclodevidadosoftware,suasdiretivasdemodelagemecodificao cobrem uma grande variedade de atributos importantes como (KLOCKWORK, 2012) Baixa complexidade; Uso de convenes de nomenclatura; Tamanho restrito de interfaces; Alta coeso dentro dos componentes de software; Uso restrito de interrupes; Paraaadequaodocdigoaospadresacimaserusadaumaferramentade anliseestticadecdigodenominadaKlocworkInsight,daempresaKlockwork.A ferramentapodeserintegradaaaplicaesdedesenvolvimentocomoEclipsee MicrosoftVisualStudioeanalisaocdigoduranteodesenvolvimento,fornecendo alertasaodesenvolvedorsobrepossveisvulnerabilidadesdeseguranaeoutrasfalhas como variveis no inicializadas ou cdigos no atingveis (KLOCWORK, 2014) 7. Consideraes Gerais Apesardesteprojetonoterconsideradonenhumaespciedecustoou limitaesderecursos,possveldizerquetodocustoenvolvidoemumprojetodeve serestudadocomoobjetivodeestabelecermelhorooramentodeumprojetoeno causar distrbios financeiros para nenhuma das partes. Nesteprojeto,possvelconsiderarcustosdemobilizaodeequipes, infraestrutura,ferramentasdetrabalho,deslocamentosparareuniescomocliente, treinamento da equipe de desenvolvimento para estudar o funcionamento do mdulo do automvel e custos por parte da MotorBras, que tambm ter que disponibilizar equipes para realizar a integrao do automvel com o celular. Por ser um projeto envolvendo uma empresa automobilstica de grande porte, os profissionaisenvolvidospodemtercontatocomdiversasinformaesconfidenciais comocaractersticasdefuncionamentointernodo automvel e da linha de montagem, bemcomoacesso ao cdigo envolvido. Questes ticas sero adotadas com o objetivo demantertodainformaoemsigilo,privandoassimasduaspartesdefuturos problemas. 8. Concluso Paraarealizaodeste projeto, um estudo extenso do material bibliogrfico da aula(SWEBOK,2014)associadoarealizaodepesquisasporrefernciasadicionais comoobjetivodecomplementarostemaseampliaroestudosobrecadareade conhecimento foi feito. Foipossvelpraticaracapacidadedeabstrao,selecionandoreferncias apropriadaseextraindoostrechosquedescrevamejustifiquemasdecisesrealizadas nestetrabalho.Comisso,verifica-seaindaadificuldadeeaimportnciadeencontrar materialdeapoioquepossaserutilizadocomorefernciaparaesteprojetoeos assuntos por ele descritos e estudados. Acriaodesteprojetoumtimoexemploparaentendermosasprincipais caractersticas, importncias, dificuldades, processos mtodos que teremos que adotar para a elaborao do nosso trabalho de concluso do curso de Engenharia de Software. Comtodo o estudo realizado, foi possvel a compreenso dos principais pontos decadareadeconhecimentoproposta.AEngenhariadeSoftwarenolimitada apenasacriaodoproduto,envolvedisciplinasquecobremdesdeoinciodeum projeto,atdisciplinasqueestudamoseugerenciamentoesuamanuteno, contemplando todo o ciclo de vida de um projeto de Engenharia de Software. Foi observada a importncia da indstria automobilstica e a necessidade de uma inovao no mercado, onde foi proposta uma integrao com o smartphone, sendo este umarepresentaodasprefernciasdousurio.Oprojetoabrepossibilidadespara expanso,ondeossmartphonespodempossuiraplicativosqueanalisemconsumode gasolinaeindiquemanecessidadedemanutenodosistemamecnicoeeltricodo automvel.9. Referncias ANFAVEA.AnuriodaIndstriaAutomobilsticaBrasileira.Disponvelem: .BENNETT, K. e RAJLICH, V. Software maintenance and evolution: a roadmap. of the Conference on the Future of Software , 2000.BOTASCHANJAN, J. et al. Towards Verified Automotive Software. p. 16, 2005.CNBC.Globalautosaleshitrecordhighof82.8million.Disponvelem: .CORRAL,L.;;SILLITTI,A.eSUCCI,G. Software development processes for mobile systems: Is agile really taking over the business? 2013 1st International Workshop on theEngineeringofMobile-EnabledSystems(MOBS),p.1924, doi:10.1109/MOBS.2013.6614218, 2013.ERICSSON.EricssonMobilityReport:LTEandsmartphoneuptakedrivesvideo traffic growthitle. Disponvel em: .FORBES.AndroidDominatesMarketShare,ButAppleMakesAllTheMoney. Disponvelem:.GITHUB.TheBestWattoBuildandShipSoftware.Disponvelem: . HEINISCH,C.;;FEIL,V.eSIMONS,M.Efficientconfigurationmanagementof automotive software. Real Time Software, 2004.HOMER, A. et al. Mobile Application Architecture Guide. 2008.IEEE610.12-90.Ieee standard glossary of software engineering terminology.Office, v. 121990, 1990.JAMALI, S. M. Object Oriented Metrics (A Survey Approach). 2006.JAVED,T.Practicuminsoftwareprojectmanagement:anendeavortoeffectiveand pragmaticsoftwareprojectmanagementeducation.oftheEuropeansoftware engineering conference and , p. 471479, 2007.KLOCKWORK.SoftwareonWheels:AddressingtheChallengesofEmbedded Automotive Software. . [S.l: s.n.], 2012. KLOCWORK.Becauseyouwanttowritecodeyoullbeproudof.Disponvelem: .PAETSCH,F.;;EBERLEIN,a.eMAURER,F.Requirementsengineeringandagile softwaredevelopment.WETICE2003.Proceedings.TwelfthIEEEInternational WorkshopsonEnablingTechnologies:InfrastructureforCollaborative Enterprises, 2003., p. 308313, doi:10.1109/ENABL.2003.1231428, 2003.ROTHMAN,J.eHASTIE,S.LessonsLearnedfromLeadingWorkshopsabout GeographicallyDistributedAgileTeams.IEEESoftware,v.30,n.2,p.710, doi:10.1109/MS.2013.33, 2013.SCHWABER, K. e SUTHERLAND, J. The scrum guide. Scrum. org, October, n. July, 2011.SELVAM,R.eKARTHIKEYANI,V.MobileSoftwareTesting-AutomatedTestCase Design Strategies. International Journal on , 2011.SPOLSKY,J.TownCarVersionControl.Disponvelem: .SWEBOK.GuidetotheSoftwareEngineeringBodyofKnowledgeVersion3.0 (SWEKBOK). [S.l: s.n.], 2014.TRIMBLE,J.eWEBSTER,C.AgileDevelopmentMethodsforSpace Operations. International Conference on Space Operations, 2012.