Configurao das preferncias de conduo atravs dos

dispositivos mveis
Lucas T. Turchet1, Ricardo Gamba e Silva1
1

Instituto de Pesquisas Tecnolgicas

Universidade de So Paulo (USP) So Paulo, SP Brazil
{lucasltt,ricardogamba}@gmail.com

Abstract. This paper describes a software project as a platform for a

hypothetical company called MoToRBRAS. The main objective is to analyze
the application and use of the concepts of software engineering based on the
techniques described in the SWEBOK on a project for a large automotive
company that wants to innovate in their field of software for the automobile.
The use of the smartphone to make driving preferences such as position of
mirrors, seats and radio has been proposed. A possible future extension of this
project involves the creation of applications that indicate consumption of the
vehicle and the need for maintenance of mechanical and electrical system
Resumo. Este documento descreve um projeto de software como plataforma
para uma empresa hipottica chamada MoToRBRAS. O objetivo principal
analisar a aplicao e o uso de conceitos de engenharia de software com base
nas tcnicas descritas no SWEBOK em um projeto para uma empresa
automobilstica de grande porte que deseja inovar em sua rea de software
para o automvel. Foi proposto o uso do smartphone para realizar as
preferncias de conduo como posio de espelhos, bancos e rdio. Uma
possvel futura extenso deste projeto envolve a criao de aplicativos que
indiquem o consumo do veculo e a necessidade de manuteno do sistema
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
indstria automobilstica movimentou 106,8 bilhes de dlares em 2012, participando
em 5% do PIB nacional deste ano (ANFAVEA, 2014)
Um outro bem de consumo que tem um crescimento acelerado entre a
populao mundial o telefone mvel inteligente, conhecido popularmente por seu
nome no idioma ingls: smartphone. Estes alm de realizar chamadas telefnicas
tambm contam com acesso Internet, possuem sistemas operacionais prprios e
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

smartphones atuais e um modelo de automvel fabricado pela MotorBrs. Neste
projeto, o smartphone do usurio ser usado como uma forma de identificao do
mesmo em relao ao veculo, permitindo a definio de uma srie de configuraes
pessoais como posies de bancos e espelhos, preferncias da direo eltrica, estaes
de rdio preferidas e destinos usados com maior freqncia no GPS. Tal integrao
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. Esta tecnologia ser utilizada para a leitura das informaes do smartphone
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

O sistema estar integrado a atuadores que controlaro fatores crticos
conduo de veculos automotores (como posio de bancos e espelhos), assim defeitos
de software poderiam ameaar indiretamente a vida do condutor, passageiros e outras
pessoas. Por exemplo, a movimentao indevida do banco do motorista durante uma
conduo em alta velocidade poderia causar uma distrao fatal.
A fim de se evitar possveis riscos vida humana, o sistema responsvel por
controlar estes atuadores mecnicos somente poder funcionar quando o veculo estiver
parado, com o freio de estacionamento acionado. Esta limitao, alm de aumentar a
segurana, no deve trazer qualquer incmodo ao usurio j que ajustes de banco ou
espelhos devem ser feitos apenas com o veculo parado, como determina a legislao de
trnsito brasileira. Esta uma tcnica que visa limitao de danos, citado no

(SWEBOK, 2014) como uma das tcnicas para a reduo do risco de falhas em
softwares de segurana crtica.
Este projeto visa o estudo das principais disciplinas proposta na referncia
bibliogrfica proposta (SWEBOK, 2014). Nenhum custo ou limitaes de recursos foi
levado em considerao na adoo das solues tomadas do decorrer deste projeto.

3. Disciplinas do SWEBOK
As disciplinas do SWEBOK sero aplicadas pelos times de desenvolvimento
conforme segue:
3.1 Requisitos de Software
Como este projeto utilizar o SCRUM como seu mtodo de desenvolvimento, o
uso de entrevistas pessoais que permitem conversar com o cliente e com as partes
envolvidas o melhor mtodo de escolha para coletar as informaes necessrias e
levantar os requisitos para o desenvolvimento, evitando equvocos (PAETSCH,
EBERLEIN e MAURER, 2003)
Em todas as abordagens de desenvolvimento gil, o mtodo mais adequado para
realizar a anlise de requisitos, identificando e validando assim a sua consistncia,
plenitude, viabilidade e ambiguidade a priorizao dos requisitos, onde
implantaremos primeiramente os requisitos que so prioritrios e capazes de agregar
mais valor ao software. Como durante o desenvolvimento o entendimento do projeto
evolui e novos requerimentos so adicionados, esse processo de priorizao ser
repetido durante todo o processo de desenvolvimento. (PAETSCH, EBERLEIN e
MAURER, 2003)
Para validar os requisitos e certificar que eles esto de acordo com o sistema que
proposto, sero realizadas reunies frequentes para mostrar que o projeto est de
acordo com o cronograma e com os objetivos, aumentando assim a confiana do cliente
e indicando problemas num tempo mais curto. Tambm sero disponibilizados para o
cliente os testes de aceitao para validar se o sistema est trabalhando de maneira
esperada, e se no, indicar o problema. (PAETSCH, EBERLEIN e MAURER, 2003)
3.2 Design de Software
O Design de software uma parte importante no processo de desenvolvimento
de software, permitindo que o engenheiro de software produza vrios modelos que
criam uma espcie de blueprint da soluo a ser implementada. Ns podemos analisar
esses modelos e determinar se eles satisfazem ou no os requisitos. (SWEBOK, 2014)
Os aplicativos mveis se diferenciam dos aplicativos de desktop pelo seu
ambiente de execuo particular, limitao de recursos, requisitos de alta autonomia e
competio no mercado. Essas situaes criam uma necessidade de processos de
desenvolvimento especiais que superam estes desafios, possibilitando a criao de
produtos com alta qualidade. (CORRAL, SILLITTI e SUCCI, 2013)
Para realizar anlise e medidas do software, permitindo uma avaliao da
aplicao e prevendo um design de qualidade, ser utilizada a tcnica OOAD (Object
Oriented Analysis and Desing), que permite muitos benefcios como reuso,

decomposio do problema em pequenas partes, permitindo um fcil entendimento da

arquitetura auxiliando assim nas modificaes futuras. Essa tcnica possui
caractersticas como localizaes, encapsulamento, ocultao de informao, herana e
abstrao de objetos. (JAMALI, 2006)
Com o objetivo de minimizar a complexidade do software, as seguintes
consideraes de design sero tomadas: (HOMER et al., 2008)

Separar reas de interesse, dividindo em componentes que compartilham e

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

A construo dever seguir as diretivas do SCRUM. Funcionalidades devem ser
implementadas orientadas a user stories e subdivididas em sprints de no mximo 30
dias corridos. (SCHWABER e SUTHERLAND, 2011). Inicialmente, os sprints devem
durar uma semana, seguindo as recomendaes de (ROTHMAN e HASTIE, 2013), que
cita o fato de muitos times novos aos mtodos geis terem dificuldade em relao a
estrias muito grandes. Assim, recomenda-se o uso de iteraes de uma semana
(ROTHMAN e HASTIE, 2013)
O uso de mtodos geis, entre eles o SCRUM, oferecem uma srie de vantagens
em relao ao modelo cascata tradicional, segundo (TRIMBLE e WEBSTER, 2012)
mtodos geis encurtam o ciclo de desenvolvimento quebrando grandes projetos de
software em pedaos pequenos e mais fceis de gerenciar. Alm de facilitar interaes
entre desenvolvedores e clientes, gerando solues mais efetivas. Na referncia acima
os autores, membros do NASA Ames Research Center, apresentam os resultados da
adoo de mtodos geis no desenvolvimento de softwares de controle de misso
(conhecidos como MCT Mission Control Technologies) em parceria com o Johnson
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 clientedesenvolvedor mais efetivo e unificado e produz melhores resultados a custos menores
que os de um desenvolvimento tradicional (TRIMBLE e WEBSTER, 2012). Por fim,
(TRIMBLE e WEBSTER, 2012) destaca que o time desenvolvedor-cliente pode
reagir e se adaptar mais rapidamente com os mtodos geis e, por ser um mtodo
iterativo, contnuo e integrado, o resultado um time mais produtivo e um produto mais
efetivo.
3.3.1 Plataformas mveis escolhidas
Para este projeto foram escolhidas as duas principais plataformas mveis
disponveis no mercado atualmente, que so o Android, desenvolvido pela empresa

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:
Android Plataforma mais presente nos smartphones fabricados atualmente,
instalado em 81% dos aparelhos produzidos no terceiro quadrimestre de 2013. Apesar
disso, 66% destes dispositivos so de menor valor financeiro, de at 215 dlares
(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
Apple possui uma significativa maioria em vendas de aplicativos para smartphones e
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, foi escolhido o Android por sua expressiva presena nos dispositivos
produzidos e o IOS por sua tambm expressiva liderana no mercado financeiro.
3.3.2 Equipe de desenvolvimento
A diviso de equipes dever ser feita de acordo com os diferentes contextos do
projeto. Neste caso, foram identificados quatro domnios distintos, que so: clula de
desenvolvimento mvel para iOS, outra nos mesmos moldes para desenvolvimento
Android. E, para a parte embarcada, sero: Uma equipe responsvel pelo hardware de
leitura das informaes no dispositivo mvel, bem como controladores dos motores que
iro fazer os ajustes ergonmicos no veculo. A comunicao com o computador de
bordo tambm fica sob responsabilidade desta equipe. Por fim, a ltima equipe
responsvel pelo desenvolvimento do computador de bordo, instalao do sistema
operacional e desenvolvimento dos softwares de controle.
O tamanho destas equipes tambm ser definido de acordo com as diretivas do
SCRUM, em que se recomendam equipes de desenvolvimento maiores de trs para
haver maior interao e ganhos em produtividade e menores que dez membros para se
evitar maiores esforos de coordenao, uma vez que equipes maiores que nove
membros geram muita complexidade para se gerenciar em um processo emprico. No
entram nesta contagem o scrum master e o product owner, a menos que eles
desempenhem algum trabalho diretamente relacionado ao desenvolvimento
(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;
Equipe mvel (Android): 1 Scrum Master, 2 Desenvolvedores, 1 Tester, 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;
Equipe Embarcada (computador de bordo):
Desenvolvedores, 1 Tester, 1 Analista de requisitos.

Scrum

master,

3.3.3 Processo dirio de desenvolvimento daily meeting

Os membros de cada equipe devem se reunir diariamente para discutir o
andamento de suas atividades e possveis impedimentos, seguindo as diretivas do scrum
guide.
Possibilidades de atraso tambm devem ser sempre discutidas. Estas reunies
devem durar no mximo 15 minutos, sendo o 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
com um quadro Kanban, onde as tarefas pendentes podem ser visualizadas pelos
membros. Dessa forma, o time pode ver e sentir o trabalho em progresso e ento
elimin-lo (ROTHMAN e HASTIE, 2013).
3.4 Teste de Software
A fase de testes de grande importncia para a MotorBras, uma vez que o
produto final do desenvolvimento ir interagir diretamente os seus clientes finais. Os
sistemas desenvolvidos devero ser altamente estveis e contar com boa usabilidade, de
forma a transmitir aos usurios uma percepo de qualidade condizente com o que se
espera de uma grande montadora nacional. Alm disso, deve-se ressaltar que, pelo fato
de os sistemas desenvolvidos por este departamento funcionarem no console de
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
a tcnica Estado da arte na indstria automotiva, sobretudo devido a fatores de
segurana (BOTASCHANJAN et al., 2005).
Os testes devero ser feitos durante os sprints no processo de desenvolvimento.
Testes unitrios devem ser realizados pelos prprios desenvolvedores e com auxlio de
ferramentas de debug, quando necessrio (SWEBOK, 2014). Este teste normalmente
feito por um programador e preparado aps a codificao. O propsito do mesmo
encontrar e remover o mximo de erros no software (SELVAM e KARTHIKEYANI,
2011)
Aps os testes unitrios devero ser feitos testes de integrao entre os
diferentes componentes desenvolvidos, estes testes podero envolver diferentes equipes
e dever garantir que as interfaces e a comunicao entre os mdulos esto corretos.
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
outras reas da empresa como especialistas em ergonomia, marketing e os product
owners. Estes testes devem envolver trs escopos principais:
Aceitao, que dever avaliar se o sistema atende ao seu critrio de aceitao,
determinando se o seu comportamento atende aos requisitos estabelecidos pela
organizao (SWEBOK, 2014).
Segurana, que dever avaliar se o sistema est protegido de ataques externos.
Em particular, estes testes devem avaliar a confidencialidade, integridade e
disponibilidade dos sistemas e suas informaes (SWEBOK, 2014); Aqui, entende-se
por segurana quaisquer aspectos do software que possam influenciar na segurana de
seu usurio final, tais como distraes ou defeitos que possam de alguma forma
interferir na conduo do veculo.
Usabilidade, que dever avaliar o quo fcil o aprendizado no uso do sistema
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)
Uma pesquisa feita mostrou a distribuio da necessidade de manuteno
baseada em quatro categorias de mudana. Foi concludo que 75% do esforo da
manuteno esto distribudos nas duas primeiras categorias (BENNETT e RAJLICH,
2000).

Adaptativas: Alteraes no ambiente de execuo do software

Perfectivas: Novos requerimentos do usurio

Corretivas: Correo de Erros

Preventivas: Alteraes para corrigir problemas futuros

Desta maneira, como o foco central desse projeto est no desenvolvimento de

aplicativos mveis, as principais caractersticas de manuteno que so esperadas se
distribuem em melhorias de usabilidade, novas funcionalidade e ampliao da
compatibilidade com outros dispositivos.
Uma extenso do modelo de estgios para manuteno proposta para
softwares que so utilizados por um nmero alto de usurios, como o caso de
aplicativos mveis. Este modelo leva em considerao o versionamento de software
aps mudanas significativas na mudana do software, enquanto correes e
manutenes necessrias so desenvolvidas na mesma fase: (BENNETT e RAJLICH,
2000)

Figura 2. Diagrama de versionamento

3.6 Gerenciamento da Configurao de Software

A necessidade da gerncia de configurao de softwares automotivos est
crescendo significativamente como consequncia de um contnuo aumento no volume
de software em veculos e tambm graas possibilidade de se atualizar este software
durante o ciclo de vida do automvel (HEINISCH, FEIL e SIMONS, 2004). Assim,
essencial a introduo de um modelo eficiente para a gerncia de configurao dos
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;

Estes itens sero gerenciados atravs do controlador de verses GitHub Enterprise,

detalhado no item 3.3.9 (Ferramentas e Mtodos).
Para a seleo de configurao, foi escolhido o modelo explcito (HEINISCH,
FEIL e SIMONS, 2004), onde releases vlidas de software devem ser explicitamente
definidas. Neste modelo o nmero de configuraes vlidas limitado, o que segundo
os autores oferece uma srie de vantagens como a reduo de possveis fontes de erros,
alm de ser vantajoso para futuras atualizaes de software que podem ser feitas
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
modelo explcito define-se que esta verso de software somente pode ser instalada no

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
atualizaes nos mesmos durante o ciclo de vida do veculo exige uma seleo de
configurao explcita e a definio de dependncias baseadas em contratos ou
interfaces (HEINISCH, FEIL e SIMONS, 2004).
(HEINISCH, FEIL e SIMONS, 2004) ainda prope um modelo de configurao
de releases de hardware e software usando um modelo de entidade relacionamento
(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.
O que explica o porqu de uma ECU possuir de 0 a n mdulos flashware, 0 ocorre
quando o software est localizado na ROM do controlador, enquanto que de 1 a n
ocorre quando o software est localizado na memria flash. Para o mdulo flash este
pode ser executado em 1 ou mais ECUs.
Valores codificados (na figura: coding values) podem ser utilizados para ligar
ou desligar certas funcionalidades no hardware, e tambm devem fazer parte da
gerncia de configurao.
Assim, uma release de hardware consiste de n ECUs e uma release de software
consiste de mdulos flashware e seus valores codificados. Este relacionamento define
quais releases de software so compatveis com cada release de hardware.
3.7 Gerenciamento da Engenharia de Software
O Gerenciamento da Engenharia de Software pode ser definido como a
aplicao de atividades de gerenciamento como planejamento, coordenao, medio,
controle e gerao de relatrios. (IEEE610.12-90, 1990)
Apesar de ser possvel dizer que o um projeto de engenharia de software pode
ser gerenciado como qualquer outro projeto complexo, existem alguns aspectos do

produto software e de seu ciclo de vida que dificultam um gerenciamento efetivo

(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.

Um fator chave que contribui para o sucesso ou falha de um projeto o seu

gerenciamento. Estudos na indstria de software mostram frequentemente que ms
prticas de gerenciamento so atribudas a uma crise de qualidade. Estes estudos
mostram que somente 20% dos projetos so implementados de acordo com o
planejamento e que cerca de 66% apresentam altos prejuzos (JAVED, 2007)
Evidncias de boas e ms prticas de gerenciamento da engenharia de software
so descritas na literatura (JAVED, 2007):
Boas Prticas

Ms Prticas

Estimar o projeto de forma realista

Cobrana de cronograma excessiva

Entender o problema do cliente

Mudar as necessidades do usurio

Especificaes de Requisitos Clara

Falta de especificaes tcnicas

Controle e Gerenciamento do Escopo

Falta de um plano de projeto

Reconhecimento de desempenho

Estimar custos sem preciso

Gerenciamento de risco contnuo

Falta de pessoas experientes

Controle de Mudanas

Falta do envolvimento do usurio

Aplicao de Mtricas

Falta de comunicao

Uso de Tecnologia madura

Especificao
documentada

de

requisito

mal

3.8 Processos de Engenharia de Software

Como mencionado anteriormente no tpico 3.3 sobre construo, o processo de
desenvolvimento dever seguir as diretivas do Scrum Guide, proposto por
(SCHWABER e SUTHERLAND, 2011). Ao final de cada ciclo, ou sprint, as equipes
devero realizar uma reunio denominada Sprint Retrospective (SCHWABER e
SUTHERLAND, 2011)em que os membros discutem sobre o que foi feito no sprint e
prope melhorias ao processo. Estas reunies devero durar no mximo 3 horas para
cada ms de sprint, segundo (SCHWABER e SUTHERLAND, 2011) e sero de
extrema importncia para o amadurecimento do processo de desenvolvimento da
MotorBrs.

Para se medir o sucesso do processo sero adotadas algumas medidas de carter

quantitativo que tero dois focos distintos: Produtividade e Qualidade, que sero
medidos por equipe da seguinte forma:
Produtividade: Quantidade total de horas gastas pela equipe no projeto dividido
pelo nmero de user stories implementados;
Qualidade: Quantidade total de defeitos corrigidos dividido pelo nmero total de
horas de desenvolvimento.
Os valores de ambas as medidas acima devero diminuir com o tempo medida
que as equipes adquirirem maior nvel de maturidade e integrao. Estes valores
devero ser continuamente acompanhados pela gerncia, que poder estipular metas
para as equipes com base neles.
3.9 Ferramentas e Mtodos
Para suporte atividade de construo do software ser usada a soluo do
GitHub Enterprise para o controle de verses. 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)
Segundo o fornecedor do GITHUB ENTERPRISE (2014), sua soluo ainda
oferece controle de acesso ao repositrio, que pode ser integrado com sistemas de
autenticao como LDAP e CAS, e permite que o sistema todo funcione nos servidores
da empresa dentro do domnio de seu firewall. Este ltimo fator decisivo para a
escolha do GitHub, uma vez que oferece maior segurana propriedade intelectual que
ser desenvolvida.
O GitHub ainda integrvel com a maioria das ferramentas de mercado
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
com uma funcionalidade denominada issue tracking (acompanhamento de defeitos),
que permite documentar defeitos encontrados, chamados issues, e classific-los em
categorias, chamadas labels (etiquetas). Isto permitir a implantao da
Classificao Ortogonal de Defeitos, mencionada no (SWEBOK, 2014) como uma
tcnica que permite classificar os defeitos de acordo com a etapa de desenvolvimento
em que surgiram. Por exemplo, defeitos relacionados interface do software podem ter
sido originados em um processo de design inadequado Assim, melhorando-se o
processo de design deve reduzir o nmero de defeitos de interface (SWEBOK, 2014).A
figura a seguir ilustra um exemplo da interface de Issue Tracking do GitHub
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
ser associados aos issues, permitindo classific-los de acordo com critrios prestabelecidos. Mltiplas labels podem ser associadas a cada issue.
3.10 Qualidade de Software
Dadas as diversas definies para qualidade de software existentes na
bibliografia, este trabalho a adotar como sendo Alcanar nveis excelentes de
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.
Para a garantia da qualidade, todos os sistemas embarcados desenvolvidos
devero seguir dois padres da indstria automotiva, que so:
Padres de cdigo MISRA
Originalmente criado para facilitar prticas de codificao seguras e confiveis
para a indstria automotiva, a Motor Industry Software Reliability Association
(MISRA) criou padres de codificao que tm sido adotados at mesmo por outros
setores da indstria, como Telecomunicaes, Aeroespacial, Defesa, etc.
MISRA C um padro de desenvolvimento de software para a linguagem C que facilita
a segurana, portabilidade e confiabilidade de sistemas embarcados. (KLOCKWORK,
2012)

ISO-26262
um padro de segurana funcional, publicado pela Organizao Internacional
de Padronizao (do ingls International Organization for Standardization, ISO), que
visa a segurana de veculos automotores. um padro amplo que cobre muitos
aspectos do ciclo de vida do software, suas diretivas de modelagem e codificao
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;

Para a adequao do cdigo aos padres acima ser usada uma ferramenta de
anlise esttica de cdigo denominada Klocwork Insight, da empresa Klockwork. A
ferramenta pode ser integrada a aplicaes de desenvolvimento como Eclipse e
Microsoft Visual Studio e analisa o cdigo durante o desenvolvimento, fornecendo
alertas ao desenvolvedor sobre possveis vulnerabilidades de segurana e outras falhas
como variveis no inicializadas ou cdigos no atingveis (KLOCWORK, 2014)

7. Consideraes Gerais
Apesar deste projeto no ter considerado nenhuma espcie de custo ou
limitaes de recursos, possvel dizer que todo custo envolvido em um projeto deve
ser estudado com o objetivo de estabelecer melhor o oramento de um projeto e no
causar distrbios financeiros para nenhuma das partes.
Neste projeto, possvel considerar custos de mobilizao de equipes,
infraestrutura, ferramentas de trabalho, deslocamentos para reunies com o cliente,
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
profissionais envolvidos podem ter contato com diversas informaes confidenciais
como caractersticas de funcionamento interno do automvel e da linha de montagem,
bem como acesso ao cdigo envolvido. Questes ticas sero adotadas com o objetivo
de manter toda informao em sigilo, privando assim as duas partes de futuros
problemas.

8. Concluso
Para a realizao deste projeto, um estudo extenso do material bibliogrfico da
aula (SWEBOK, 2014) associado a realizao de pesquisas por referncias adicionais
com o objetivo de complementar os temas e ampliar o estudo sobre cada rea de
conhecimento foi feito.

Foi possvel praticar a capacidade de abstrao, selecionando referncias

apropriadas e extraindo os trechos que descrevam e justifiquem as decises realizadas
neste trabalho. Com isso, verifica-se ainda a dificuldade e a importncia de encontrar
material de apoio que possa ser utilizado como referncia para este projeto e os
assuntos por ele descritos e estudados.
A criao deste projeto um timo exemplo para entendermos as principais
caractersticas, importncias, dificuldades, processos mtodos que teremos que adotar
para a elaborao do nosso trabalho de concluso do curso de Engenharia de Software.
Com todo o estudo realizado, foi possvel a compreenso dos principais pontos
de cada rea de conhecimento proposta. A Engenharia de Software no limitada
apenas a criao do produto, envolve disciplinas que cobrem desde o incio de um
projeto, at disciplinas que estudam o seu gerenciamento e sua manuteno,
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
uma representao das preferncias do usurio. O projeto abre possibilidades para
expanso, onde os smartphones podem possuir aplicativos que analisem consumo de
gasolina e indiquem a necessidade de manuteno do sistema mecnico e eltrico do
automvel.

9. Referncias
ANFAVEA. Anurio da Indstria Automobilstica Brasileira. Disponvel em:
<http://www.anfavea.com.br/anuario2014/Anuario2014.zip>.
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. Global auto sales hit record high of 82.8 million. Disponvel em:
<http://www.cnbc.com/id/101321938>.
CORRAL, L.;; SILLITTI, A. e SUCCI, G. Software development processes for mobile
systems: Is agile really taking over the business? 2013 1st International Workshop on
the
Engineering of Mobile-Enabled Systems (MOBS), p. 1924,
doi:10.1109/MOBS.2013.6614218, 2013.
ERICSSON. Ericsson Mobility Report: LTE and smartphone uptake drives video
traffic growthitle. Disponvel em: <http://www.ericsson.com/news/1706363>.
FORBES. Android Dominates Market Share, But Apple Makes All The Money.
Disponvel
em:
<http://www.forbes.com/sites/tonybradley/2013/11/15/androiddominates-market-share-but-apple-makes-all-the-money>.
GITHUB. The Best Wat to Build and Ship Software. Disponvel em:
<https://www.scrum.org/Scrum-Guide>.

HEINISCH, C.;; FEIL, V. e SIMONS, M. Efficient configuration management of

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. Practicum in software project management: an endeavor to effective and
pragmatic software project management education. of the European software
engineering conference and , p. 471479, 2007.
KLOCKWORK. Software on Wheels: Addressing the Challenges of Embedded
Automotive Software. . [S.l: s.n.], 2012.
KLOCWORK. Because you want to write code youll be proud of. Disponvel em:
<http://www.klocwork.com/products/insight/>.
PAETSCH, F.;; EBERLEIN, a. e MAURER, F. Requirements engineering and agile
software development. WET ICE 2003. Proceedings. Twelfth IEEE International
Workshops on Enabling Technologies: Infrastructure for Collaborative
Enterprises, 2003., p. 308313, doi:10.1109/ENABL.2003.1231428, 2003.
ROTHMAN, J. e HASTIE, S. Lessons Learned from Leading Workshops about
Geographically Distributed Agile Teams. IEEE Software, 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. e KARTHIKEYANI, V. Mobile Software Testing-Automated Test Case
Design Strategies. International Journal on , 2011.
SPOLSKY,
J.
Town
Car
Version
Control.
Disponvel
<http://queue.acm.org/blogposting.cfm?searchterm=github&id=58633>.

em:

SWEBOK. Guide to the Software Engineering Body of Knowledge Version 3.0

(SWEKBOK). [S.l: s.n.], 2014.
TRIMBLE, J. e WEBSTER, C. Agile Development Methods for Space Operations.
International Conference on Space Operations, 2012.