CENTRO TECNOLGICO UNIVERSIDADE POSITIVO

ADRIANO CHEMIN
HELTON YUJI YAMAMOTO
LAURA KEITY SHIBUKAWA
LUCIANE LAUS MOSELE
MATHEUS RORATO BAPTISTA
SERGIO COSTA

VAMOS DE BUSO

CURITIBA
2013
 1

ADRIANO CHEMIN
HELTON YUJI YAMAMOTO

LAURA KEITY SHIBUKAWA

LUCIANE LAUS MOSELE

MATHEUS RORATO BAPTISTA

SERGIO COSTA

VAMOS DE BUSO

Trabalho de Concluso de Curso apresentado ao

Programa de Aplicao Profissional como um dos
requisitos para obteno do ttulo de Tecnlogo
em Anlise e Desenvolvimento de Sistemas pelo
Centro Tecnolgico da Universidade Positivo.

Orientador: Professor Paulo Madalena.

CURITIBA

2013
 2

TERMO DE ANUNCIA

Pelo presente Termo de Anuncia, declaro estar de pleno acordo com as

informaes contidas neste projeto, o qual se apresenta apto a ser entregue banca
examinadora.

Orientador: Professor Paulo Madalena

Centro Tecnolgico da Universidade Positivo

_________________________________
Assinatura do Orientador

Curitiba, de 23 de Outubro de 2013.

 3

ADRIANO CHEMIN
HELTON YUJI YAMAMOTO
LAURA KEITY SHIBUKAWA
LUCIANE LAUS MOSELE
MATHEUS RORATO BAPTISTA
SERGIO COSTA

VAMOS DE BUSO

Projeto de Inovao Tecnolgica apresentado ao Programa de Aplicao

Profissional, do Curso de Tecnologia em Anlise e Desenvolvimento de Sistemas do
Centro Tecnolgico Universidade Positivo, pela seguinte banca examinadora:

Orientador: Prof. Paulo Antnio Madalena

Centro Tecnolgico Universidade Positivo

Curitiba, 23 de Outubro de 2013.

 4

RESUMO

O trabalho desenvolvido busca facilitar os deficientes visuais ou auditivos na

utilizao do transporte coletivo, sem a necessidade de auxlio de terceiros.
Trazendo a eles maior comodidade e quebrar assim, barreiras que eventualmente
tem, devido dificuldade de mobilidade pelo transporte coletivo. O cliente em
potencial so os deficientes visuais os auditivos que sempre encontram algum tipo
de dificuldade para usufruir o transporte coletivo, como qualquer pessoa, por isso a
necessidade de encontrar um meio de intervir nesse problema, buscando uma
soluo para que todos tenham mais acessibilidade. O aplicativo ir avisar ao
usurio quando o nibus que deseja pegar estiver prximo ao ponto/estao tubo
em que se localiza. Aps o embarque no nibus, o dispositivo ir informar ao
mesmo, que o desembarque est prximo. Para o desenvolvimento, utiliza-se da
linguagem Objective-C, para a plataforma IOS. A plataforma IOS foi escolhida
devido os programadores possurem com ela uma maior afinidade e tambm, por
ser voltada para Iphones. O projeto desenvolvido segue a metodologia do PMBOK
(Project Management Body Of Knowledge), base para a boa prtica, a qual a
metodologia define os processos para o planejamento e desenvolvimento do
mesmo. Junto com a metodologia do PMBOK, utilizado o XP (programao
extrema), um framework da Metodologia gil.

Palavras-chave: Desenvolvimento de software. Gerenciamento de Projetos.

Acessibilidade.
 5

ABSTRACT

The developed work searches to make the utilization of public transportation easier
to visually or hearing impaired, without the need of other peoples help. Bringing to
them a bigger comfort and then break eventual barriers, due to mass transportations
mobility issues. The potential client is the visually or hearing impaired who always
find some kind of difficulty when enjoying mass transportation like anyone else, thats
the need to find a way of intervene in this problem, in search of a solution so
everybody can taste accessibility. The application will warn the user when the bus
that he wishes to get is getting closer to the bus stop/tube station where the person
stands. After get on the bus, the dispositive will notify the user that the landing is
close. For the development it is used the Objective-C language for IOS platform. The
IOS platform was choice because of the fact that the programmers had a bigger
affinity with it and because of being iPhone related also. The developed project
follows the PMBOK (Project Management Body Of Knowledge) method, basis to the
good practice which defines the processes to the planning and developing. Along
with the PMBOK method the XP (Extreme Programming) is used, a framework of
Agile Method.

Keywords: Software development. Project management. Accessbility.

 6

SUMRIO

1. INTRODUO .................................................................................................... 11
2. FUNDAMENTAO TERICA .......................................................................... 12
2.1 MERCADO ATUAL ............................................................................................ 12
2.1.1 ACESSIBILIDADE ............................................................................................. 12
2.1.2 USURIOS ....................................................................................................... 14
2.1.2.1 CEGOS ....................................................................................................... 14
2.1.2.2 SURDOS ..................................................................................................... 16
2.1.3 SUSTENTABILIDADE ......................................................................................... 18
2.1.4 TRANSPORTE COLETIVO .................................................................................. 19
2.1.5 DISPOSITIVOS MVEIS E SMARTPHONES............................................................ 21
2.2 GERENCIAMENTO DE PROJETOS .......................................................................... 22
2.2.1 METODOLOGIA GIL ........................................................................................ 23
2.2.2 MODELAGEM GIL .......................................................................................... 23
2.2.3 PROGRAMAO EXTREMA (XP) ....................................................................... 24
2.2.4 LINGUAGEM DE MODELAGEM UNIFICADA (UML) ................................................ 25
2.3 MODELAGEM DE SISTEMAS DE SOFTWARE ......................................................... 26
2.3.1 ESTRUTURA ANALTICA DO PROJETO (EAP / WBS) ........................................... 26
2.3.2 CASOS DE USO ............................................................................................... 27
2.3.3 DIAGRAMA DE CASO DE USO ............................................................................ 28
2.3.4 DIAGRAMA DE CLASSE ..................................................................................... 30
2.4 TECNOLOGIAS UTILIZADAS ............................................................................... 31
2.4.1 XCODE5......................................................................................................... 31
2.4.2 PLATAFORMA IOS........................................................................................... 32
2.4.3 OBJECTIVE-C ................................................................................................. 33
3. ORGANIZAO-CLIENTE ................................................................................. 34
3.1 HISTRICO DO CENTRO DE INCLUSO ............................................................... 34
3.2 MISSO ......................................................................................................... 35
3.3 VISO ............................................................................................................ 35
3.4 VALORES ....................................................................................................... 35
4. DIAGNSTICO DO AMBIENTE ......................................................................... 36
4.1 DEPOIMENTO ADRIANO CHEMIN ....................................................................... 36
4.2 OS SURDOS E O TRANSPORTE COLETIVO ........................................................... 37
4.3 O USO DO TRANSPORTE COLETIVO PARA OS DEFICIENTES VISUAIS E AUDITIVOS .... 37
4.4 O TRANSPORTE COLETIVO EM CURITIBA............................................................ 39
4.5 OBJETIVO DO SISTEMA .................................................................................... 39
5. DESENVOLVIMENTO ........................................................................................ 41
6. CONSIDERAES FINAIS ................................................................................ 44
7. REFERNCIAS BIBLIOGRFICAS ................................................................... 45
8. APNDICES ....................................................................................................... 48
8.1 APNDICE A GERENCIAMENTO DO PROJETO ................................................... 48
 7

8.1.1 TERMO DE ABERTURA DO PROJETO .................................................................. 48

8.1.1.1 JUSTIFICATIVA ............................................................................................. 48
8.1.1.2 OBJETIVO ................................................................................................... 48
8.1.1.3 VISO GERAL DO ESCOPO ............................................................................ 49
8.1.1.4 RESTRIES ............................................................................................... 49
8.1.1.5 PREMISSAS ................................................................................................. 49
8.1.1.6 RISCOS INICIAIS ........................................................................................... 50
8.1.1.7 DESIGNAO DO GERENTE DO PROJETO ....................................................... 50
8.1.2 DOCUMENTO DE VISO ..................................................................................... 51
8.1.2.1 ORGANIZAO-CLIENTE ............................................................................... 51
8.1.2.2 OBJETIVO ................................................................................................... 52
8.1.2.3 CENRIO ATUAL .......................................................................................... 52
8.1.2.4 DESCRIO DO PROJETO ............................................................................. 53
8.1.2.5 ENVOLVIMENTO ........................................................................................... 54
8.1.2.5.1 ABRANGNCIA ......................................................................................... 54
8.1.2.5.2 PAPEL DAS PARTES INTERESSADAS ............................................................ 54
8.1.2.5.3 PAPEL DOS ATORES .................................................................................. 56
8.1.2.6 NECESSIDADES E FUNCIONALIDADES ............................................................. 56
8.1.2.6.1 MDULO PESQUISA .................................................................................. 57
8.1.2.7 RESTRIES / PREMISSAS ........................................................................... 58
8.1.2.7.1 RESTRIES ............................................................................................ 58
8.1.2.7.2 PREMISSAS.............................................................................................. 58
8.1.2.8 EXPECTATIVA DE ENTREGA DO PRODUTO ....................................................... 59
8.1.3 ESPECIFICAO DAS REGRAS DE NEGCIO ....................................................... 59
8.1.3.1 OBJETIVO ................................................................................................... 59
8.1.3.2 SELECIONAR LINHA DE NIBUS ...................................................................... 59
8.1.3.3 SELECIONAR PONTO DE DESEMBARQUE DA LINHA ESCOLHIDA ANTERIORMENTE. 59
8.1.3.4 CONFIGURAR ALERTA DO SISTEMA ................................................................ 60
8.2 APNDICE B PLANO DE GERENCIAMENTO DO ESCOPO ..................................... 60
8.2.1 DESCRIO DETALHADA DO PRODUTO .............................................................. 60
8.2.2 ESCOPO CONTEMPLADO DO PRODUTO .............................................................. 61
8.2.3 ESCOPO NO CONTEMPLADO DO PRODUTO ....................................................... 61
8.2.4 EAP/WBS ..................................................................................................... 62
8.2.5 DICIONRIO EAP ............................................................................................ 63
8.3 APNDICE C PLANO DE GERENCIAMENTO DO TEMPO ....................................... 66
8.3.1 CRONOGRAMA ................................................................................................ 67
8.3.2 DURAO DAS ATIVIDADES .............................................................................. 70
8.4 APNDICE D PLANO DE GERENCIAMENTO DA QUALIDADE ................................. 71
8.5 APNDICE E PLANO DE GERENCIAMENTO DA COMUNICAO ............................ 73
8.6 APNDICE F ESPECIFICAO DOS REQUISITOS DO PROJETO ............................ 75
8.7 APNDICE G MODELAGEM ............................................................................ 77
8.7.1 DOCUMENTO DE CASO DE USO ......................................................................... 77
8.7.1.1 OBJETIVO DO CASO DE USO ......................................................................... 77
8.7.1.2 ATORES ...................................................................................................... 77
8.7.1.3 PR-CONDIES ......................................................................................... 78
8.7.1.4 FLUXO PRINCIPAL ........................................................................................ 78
8.7.1.5 FLUXOS ALTERNATIVOS ................................................................................ 79
 8

8.7.1.6 FLUXOS DE EXCEO ................................................................................... 79

8.7.1.7 PONTOS DE EXTENSO/INCLUSO ................................................................ 80
8.7.1.8 CRITRIOS DE ACEITE .................................................................................. 80
8.7.2 DIAGRAMA DE CASO DE USO ........................................................................... 80
8.7.3 PROTTIPOS DE TELA...................................................................................... 81
8.7.4 DIAGRAMA DE CLASSE .................................................................................... 81
8.7.5 DIAGRAMA DE SEQUNCIA ............................................................................... 82
8.7.6 DIAGRAMA DE COMPONENTES ......................................................................... 82
8.7.7 DIAGRAMA DA IMPLANTAO ............................................................................ 83
8.8 APNDICE H DOCUMENTO DE ARQUITETURA .................................................. 84
8.8.1 OBJETIVO....................................................................................................... 84
8.8.2 ESCOPO......................................................................................................... 84
8.8.3 REPRESENTAO DA ARQUITETURA ................................................................. 84
8.8.4 PRINCPIOS E RESTRIES DA ARQUITETURA ..................................................... 85
8.8.5 VISO LGICA DO APLICATIVO .......................................................................... 86
8.8.6 VISO FSICA DO APLICATIVO ............................................................................ 86
8.8.7 TECNOLOGIAS UTILIZADAS ............................................................................... 87
8.8.8 ELEMENTOS DO SISTEMA ................................................................................ 87
8.8.9 PERFORMANCE ............................................................................................... 88
8.8.10 TELAS DO SISTEMA ...................................................................................... 88
8.8.11 PARTES DO CDIGO-FONTE .......................................................................... 92
8.8.11.1 LINHAS DE NIBUS. ...................................................................................... 92
8.8.11.2 PONTO DAS LINHAS DE NIBUS. .................................................................... 99
8.8.11.3 TELA DE ALERTA ........................................................................................ 105
 9

LISTA DE ILLUSTRAES

FIGURA 1 Exemplo De Estrutura Analtica De Projeto ..........................................27

FIGURA 2 Exemplo De Diagrama De Caso De Uso ..............................................31
FIGURA 3 Exemplo De Diagrama De Classe ........................................................31
FIGURA 4 Equipe De Desenvolvimento .................................................................51
FIGURA 5 Estrutura Analtica Dos Recursos .........................................................70
FIGURA 6 Diagrama De Caso De Uso ..................................................................80
FIGURA 7 Prottipos De Tela ................................................................................81
FIGURA 8 Diagrama De Classe .............................................................................81
FIGURA 9 Diagrama De Sequncia .......................................................................82
FIGURA 10 Diagrama De Componentes ...............................................................83
FIGURA 11 Diagrama De Implantao ..................................................................83
FIGURA 12 Representao Da Arquitetura ...........................................................85
FIGURA 13 Viso Lgica Da Arquitetura Do Sistema ............................................86
FIGURA 14 Viso Fsica Da Arquitetura Do Sistema .............................................86
FIGURA 15 Tela Inicial Do Sistema Operacional Ios .............................................89
FIGURA 16 Primeira Tela Do Sistema Vamos De Buso ....................................90
FIGURA 17 Segunda Tela Do Sistema Vamos De Buso ...................................91
FIGURA 18 Tela De Configurao Do Alerta .........................................................92
 10

LISTA DE TABELAS

TABELA 1 Centro De Incluso da Universidade Positivo ......................................54

TABELA 2 Universidade Positivo ...........................................................................54
TABELA 3 Deficientes Visuais E Auditivos ............................................................54
TABELA 4 Analista de Teste ..................................................................................55
TABELA 5 Desenvolvedor ......................................................................................55
TABELA 6 Documentador de Sistemas .................................................................55
TABELA 7 Analista de Requisitos ..........................................................................55
TABELA 8 Lder do Grupo .....................................................................................55
TABELA 9 Usurio .................................................................................................56
TABELA 10 Celular ................................................................................................56
TABELA 11 Mdulo Administrativo ........................................................................56
TABELA 12 Seleo ...............................................................................................57
TABELA 13 Interao Com o Gps ..........................................................................57
TABELA 14 Dicionrio Eap ....................................................................................63
TABELA 15 Lista de Atividades .............................................................................66
TABELA 16 - Lista de Atributos Das Atividades ......................................................66
TABELA 17 Lista de Marcos ..................................................................................67
TABELA 18 Recursos das Atividades ....................................................................67
TABELA 19 Requisitos e Garantia da Qualidade ..................................................71
TABELA 20 Identificao das Partes Interessadas e Estratgias da Comunicao
....................................................................................................................................73
TABELA 21 Plano de Comunicao .......................................................................74
TABELA 22 Caracterstica de Qualidade Funcionalidades .................................75
TABELA 23 Caracterstica de Qualidade Usabilidade ........................................76
TABELA 24 Caracterstica de Qualidade Confiabilidade ....................................76
TABELA 25 Caracterstica de Qualidade Eficincia ............................................76
TABELA 26 Caracterstica de Qualidade Portabilidade ......................................76
TABELA 27 Caracterstica de Qualidade Manutenibilidade ...............................76
TABELA 28 Atores .................................................................................................77
 11

1. INTRODUO

O sistema de transporte coletivo em Curitiba considerado por muitos um

exemplo a ser seguido. No site http://www.araucariatc.com.br informa que 97
cidades em torno do Mundo dispuseram a copiar o sistema, disponibilizando a todos,
um transporte coletivo de qualidade.
Apesar de Curitiba possuir uma grande infraestrutura, com canaletas
exclusivas, estaes tubo, nibus biarticulados e rede nica integrada com a regio
Metropolitana, para muitos indivduos, utilizar diariamente o transporte coletivo ainda
uma tarefa complicada. Estas pessoas, deficientes visuais e auditivas, buscam
cada vez mais espao e independncia em seu dia-a-dia, para se locomover com
mais facilidade, dentro da cidade onde vive.
A dificuldade dos deficientes visuais ou auditivos de utilizarem o transporte
coletivo grande. Para eles, as empresas de transporte coletivo buscam cada vez
mais, melhorar na questo da acessibilidade. Infelizmente, as dificuldades que ainda
sofrem como, para os deficientes visuais saberem qual nibus est se aproximando
ao ponto em que esteja aguardando ou para o deficiente auditivo saber qual o
ponto de desembarque, caso no tenha conhecimento prvio da localizao ainda
uma barreira que no foi suprida.
A tecnologia acaba sendo imprescindvel para que essas pessoas possam
trabalhar, estudar, se locomover, ter mais acessibilidade, para fazer suas tarefas
dirias sem grande dificuldade.
Dessa forma, este projeto tem como objetivo auxiliar os deficientes visuais e
auditivos atravs da tecnologia mobile, onde o usurio poder receber ajuda para
utilizar o transporte coletivo atravs de seu smartphone, com o aplicativo Vamos de
Buso.
 12

2. FUNDAMENTAO TERICA

Atualmente, com as variedades, opes de tecnologias e recursos existentes

para desenvolver uma aplicao, escolher algumas delas uma tarefa difcil. Na
escolha da linguagem junto com as tecnologias existentes, foi necessrio uma
anlise aprofundada sobre a finalidade da aplicao. Neste captulo sero
abordadas as justificativas da aplicao, seu objetivo, seus usurios em potencial
bem como o que engloba a utilizao da aplicao e tambm as tecnologias
utilizadas ao longo do desenvolvimento do projeto.

2.1 Mercado atual

2.1.1 Acessibilidade

O inciso I do art. 8 do Decreto N 5.296/20041 explica que a acessibilidade

a condio para utilizao, com segurana e autonomia, total ou assistida, dos
espaos, mobilirios e equipamentos urbanos, das edificaes, dos servios de
transporte e dos dispositivos, sistemas e meios de comunicao e informao, por
pessoa com deficincia ou com mobilidade reduzida2.
necessrio que tenha leis e decretos que informem a populao sobre as
mnimas condies obrigatrias de acessibilidade em meios pblicos. Durante muito
tempoos deficientes visuais e auditivos viveram excludos da sociedade. Alguns,
internados em hospitais, onde recebiam tratamentos e em alguns casos, eram
abandonados. Esse fato ocorria porque, para Paz (2006, p. 27), a excluso dessas

1
Decreto n5.296 de 2 de Dezembro de 2004. CAPTULO V DA ACESSIBILIDADE AOS SERVIOS DE
TRANSPORTES COLETIVOS
2
Mobilidade reduzida aquela que, temporria ou permanente, tem limitada a sua capacidade de se
relacionar com meio e de utiliza-lo. Entende-se por pessoa com mobilidade reduzida aquela com deficincia, os
idosos, a obesa e a gestante, entre outros. (NBR 9050:2004). Dificuldade de se movimentar, gerando a efetiva
reduo da mobilidade, flexibilidade, coordenao motora e percepo.
 13

pessoas era vista como uma garantia de cuidados e educao, sem ser atingida
pela rejeio.
Com leis e projetos envolvendo a acessibilidade e os anteriormente excludos,
essas prticas deixaram de ser vistas como solues. Demonstra que a melhor
maneira de garantir os verdadeiros cuidados e a educao que precisam atravs
da incluso. Isso o oposto do que ocorria h muito tempo atrs, tendo acesso a
lugares e contatos com outras pessoas que antes no haviam noo de
conhecimento.
De acordo com orientao dada pela NBR 14022:

Os padres e critrios que visam a proporcionar pessoa portadora de

deficincia acessibilidade em nibus e trlebus, para atendimento urbano e
intermunicipal. Disciplina a acessibilidade nas diversas etapas da viagem e
compartimento do nibus e trlebus, tais como local de embarque e
desembarque, fronteira (local de transio entre as reas de embarque e
desembarque), veculo, assentos preferenciais reservados, comunicao e
sinalizao. Por fim, tambm recomenda que a operadora deve providenciar
e manter pessoal treinado para operao e atendimento aos portadores de
deficincia que utilizam seus servios, com ateno especial s diferenas
existentes entre as vrias deficincias, e que tambm deve haver forma
alternativa de acessibilidade quando os equipamentos e estes dispositivos
estiverem temporariamente inoperantes. (ABNT, 1997).

Na rea de informtica, por exemplo, programas que provm acessibilidade

so ferramentas que permitem aos deficientes utilizarem de recursos que os
computadores oferecem. Ferramentas como JAWS, constitudo de leitores de ecr,
para ajudar os deficientes visuais. Teclados virtuais para quem tem deficincia
motora ou com dificuldades de coordenao motora e sintetizadores de voz para
pessoas com deficincias auditivas. Cada vez mais se busca melhorias na
acessibilidade, para que eles possam vivenciar momentos e utilizar produtos, que
antes s eram destinados s pessoas que no haviam limitaes por parte da fala
ou da viso, ou at mesmo das atividades que exijam o mnimo coordenao
motora3.

3
Coordenao motora a capacidade de usar de forma mais eficiente os msculos esquelticos (grandes
msculos), Esse tipo de coordenao permite dominar o corpo no espao, controlando os movimentos mais
rudes. Uma boa coordenao motora perceptvel verificado pela agilidade, velocidade e a energia que se
demonstra.
 14

2.1.2 Usurios

Os usurios em potencial deste projeto so os deficientes visuais ou

auditivos. Estes usurios buscam sempre estar presentes no mercado de trabalho,
garantindo seu espao que de direito, destacando-se cada vez mais na sociedade.
Para eles, ainda h barreiras a serem quebradas devido limitao que so
impostas, pois, apesar da acessibilidade estar presentes em leis e decretos, ainda
h problemas que esses usurios enfrentam em seu cotidiano.

2.1.2.1 Cegos

Na maior parte das sociedades primitivas, os cegos, os enfermos e as

pessoas com deficincia, eram abandonados ou mortos. Infelizmente, [..] era
comum matar as crianas que nasciam cegas e abandonar os que ficaram cegos na
fase adulta (DA COSTA apud LOWENFELD et al).
Essa excluso que houve com os deficientes visuais, quanto outros indivduos
considerados invlidos, tinha como motivo no s a vida complicada pela natureza,
mas tambm por diversas crenas que se existiam na poca. Um dos relatos de
Mecloy (1974) fala sobre diversas crenas que existiam na poca, que tambm era
empecilho para prejudica-lo. Acreditavam que a pessoa cega era possuda por
espritos malignos e se algum mantivesse uma relao com esses cegos, tambm
manteriam uma relao com os espritos do mau. Tornando assim o cego em algo
temeroso religiosamente.
Outra viso sobre a cegueira naquela poca era imaginar que os cegos
recebiam essas condies devido a pecados prprios, ou dos familiares, podendo
ser tambm vistos como pecado de algum que pertencesse a mesma tribo, sendo
assim castigados por deuses.

Com o surgimento do mercantilismo e capitalismo comercial comearam a

ocorrer vrias mudanas no tratamento das pessoas com deficincia, foi
 15

nesse perodo renascentista que se comeou a se revisar os preconceitos,

as normas, os estatutos, as crenas e as prticas sociais no tocante ao
modo de se relacionar com as pessoas deficientes (AMIRALIAN, 1986;
BRUNS, 1997; DALLACQUA, 1997; apud FRANCO; DIAS, 2005).

Amiralian (1997, p.21) afirma que as pessoas cegas so portadoras de uma

limitao sensorial, a ausncia de viso que os limita em suas possibilidades de
compreenso do mundo externo, interferindo em seu desenvolvimento e
ajustamento as situaes comuns da vida.
A deficincia visual o comprometimento total ou parcial da viso. No so
consideradas deficincias visuais as pessoas com miopia, astigmatismo ou
hipermetropia, pois possvel corrigi-los com o auxlio de lentes ou cirurgias.
Segundo o ltimo censo do IBGE realizado em 2010, mais de 45,6 milhes de
pessoas possuem algum tipo de deficincia no Brasil. Entre elas, a deficincia visual
se mostra mais presente, chegando a 35,7 milhes de brasileiros. Dos indivduos
entrevistados, 6,5 milhes de pessoas que possuem deficincia visual, responderam
que tem grande dificuldade de enxergar e acima de 506 mil afirmaram serem cegas.
A principal causa de cegueira no Brasil so a catarata e o glaucoma. Porm
os danos causados pela catarata so reversveis, diferente do glaucoma. A reverso
da catarata feita atravs de cirurgia onde o cristalino removido e substitudo por
uma lente artificial. A doena requer aes imediatas, pois a incidncia da mesma
deve aumentar em virtude do aumento da expectativa de vida da populao. O
glaucoma apesar de no ter cura controlvel. De acordo com a Organizao
Mundial da Sade, 80% dos casos de cegueira no Brasil poderiam ser evitados, um
exemplo o glaucoma, o qual, muitas vezes no se sabe que tem a doena em
razo da falta de informao.
Os diferentes graus de deficincia visual podem ser classificados como baixa
viso (leve, moderada ou profunda): compensada com o uso de lentes de aumento,
lupas, telescpios, com o auxlio de bengalas e de treinamentos de orientao. O
grau prximo cegueira, quando a pessoa ainda capaz de distinguir luz e sombra,
mas j emprega o sistema braile para ler e escrever, utiliza recursos de voz para
acessar programas de computador, locomove-se com a bengala e precisa de
treinamentos de orientao e de mobilidade e por fim, a cegueira, quando no existe
 16

qualquer percepo de luz. O sistema braile, a bengala e os treinamentos de

orientao e de mobilidade, nesse caso, so fundamentais.

2.1.2.2 Surdos

A sociedade busca poucas alternativas para os surdos de se enquadrarem

num ambiente social. Por enxergarem, so tidos como uma deficincia leve,
acreditando assim, que por ter a viso, necessitam menos de tecnologias e
informaes que os deficientes visuais.
Segundo Gesueli (2003, p.89) a manifestao mais evidente da surdez a
falta da fala. Por no ter acesso linguagem oral, a maior parte dos surdos no
consegue adquirir uma lngua. A falta de domnio de uma lngua acarreta, por sua
vez, dificuldades para o convvio dos surdos numa sociedade oral como a nossa, por
exemplo, bem como para o desenvolvimento cognitivo e afetivo. Dai ser comum
afirmar-se que as pessoas surdas tm problemas nesses aspectos. Tais afirmaes
parecem fundamentar-se numa concepo logocntrica, ou seja, a de que a fala
que vai possibilitar ao homem, seja ouvinte ou surdo, o desenvolvimento cognitivo e
as relaes sociais nas quais os aspectos afetivos e emocionais vo se
estruturando.

Na histria da educao de surdos so muitas as referncias supremacia

da fala. Desde a Antiguidade a fala esteve ligada possibilidade de o surdo
pensar e, entre os argumentos utilizados pelos defensores do Oralismo, o
mais forte se referia necessidade de os surdos desenvolverem a fala o
que possibilitaria, entre outras coisas, a integrao na sociedade de
ouvintes. Apesar do grande empenho dos profissionais no desenvolvimento
da audio e da fala, poucos surdos obtinham resultados satisfatrios no
domnio da linguagem oral (GESUELI, 2003, pg. 89).

O ltimo Censo do IBGE mostra que cerca de 9,7 milhes de pessoas

possuem deficincia auditiva no Brasil. Destas, 2 milhes possuem deficincia
auditiva severa (1,7 milhes tem grande dificuldade para ouvir e 344,2 mil so
surdos) e 7,5 milhes apresentam alguma dificuldade auditiva. Em mdia, 1 milho
so crianas e jovens de at 19 anos. A maioria dessas pessoas est concentrada
em reas urbanas.
 17

Segundo pesquisas recentes, o nmero de pessoas com deficincia auditiva

aumentar em virtude do crescimento da populao de idosos. Muitas das vezes, o
diagnstico tardio ocasiona na surdez permanente. No Brasil, obrigatrio nas
crianas com at 6 meses de idade fazer o teste da orelhinha, para identificar se h
algum problema na audio, ao qual infelizmente, esse teste acaba sendo realizados
em crianas a partir de 4 anos, idade que, para os mdicos, considerada tardia.
H dois tipos principais de problemas auditivos. O primeiro afeta o ouvido
externo ou mdio, provocando dificuldades auditivas condutivas (denominada de
transmisso), com o diagnstico precoce, h tratamentos que eventualmente so
curveis. O outro problema auditivo envolve o ouvido interno ou do nervo auditivo,
chamado de surdez neurossensocial.
A deficincia auditiva pode ser classificada por deficincia de transmisso,
mista e neurossensorial.
No caso da deficincia de transmisso, o prognstico costuma ser excelente,
pois o problema localiza-se no ouvido externo ou mdio. J no caso da deficincia
mista, o problema se localiza no ouvido mdio ou interno. E por fim, na deficincia
neurossensorial, se origina no ouvido interno e nervo auditivo. Infelizmente, este tipo
de surdez irreversvel.
O Instituto Nacional de Educao para Surdos informa que a maior causa de
surdez no Brasil a meningite tanto viral quanto bacteriana, seguida por traumas na
cabea, onde ocorre a perda da conscincia, medicao txica e infeco de ouvido
que persiste por mais de 3 meses.
Na gestao, as mes devem ser orientadas nutrio e receber tratamento
mdico de eventuais doenas, a fim de evitar causas de surdez no perodo da
gestao, neonatal e parto. Um nascimento prematuro, a criana com baixo peso
pode ser associado com a surdez. A sfilis, a toxoplasmose, quando ocorrido na
gestao, so exemplos de doenas que podem causar surdez e outras anomalias
na criana, ao nascer. Alm disso, a meningite e a rubola pode provocar surdez.
A preocupao tambm se remete aos adultos. Nesta fase tambm h a
possibilidade de surdez. Alm dos fatores relacionados s crianas, o uso de
aparelhos de som com fones de ouvidos, ambiente de trabalho e residencial com
auto nvel de poluio sonora e infeco no ouvido tambm poder provocar a
surdez.
 18

2.1.3 Sustentabilidade

Atravs de discusses de padres econmicos relacionados a crescimento

produtivo e populacional, disponibilidade de recursos, escala e limites, a histria da
sustentabilidade se inicia. Goodland (apud, 1995) inicia seus estudos por meio da
relao crescimento da economia com o aumento de populao e uso de recursos,
para chegar a uma definio de sustentabilidade ambiental que distingue
crescimento dos meios de produo e desenvolvimento, ou seja, que h diferenas
entre acumulao de bens materiais, pelo aumento de seu volume, e expanso de
potencialidades at um estgio mais avanado. Adianta tambm que, nossa
economia, um subsistema numa Terra finita e estanque, pode se adaptar a um
modelo de desenvolvimento sem crescimento dos meios de produo
(GUILHERME, 2007. pg. 30).
Ao pensarmos na sociedade atual, a sustentabilidade se inclui como uma
forma de entender o que se passa no presente, criando uma oportunidade de manter
riquezas do planeta para a gerao futura.
Diz no art. 225 4 . que todos tm direito ao meio ambiente ecologicamente
equilibrado, bem de uso comum do povo e essencial sadia qualidade de vida,
impondo-se ao Poder Pblico e coletividade o dever de defende-lo e preserv-lo
para as presentes e futuras geraes.

Os problemas ambientais globais pertencem ao grupo de maior grau de

periculosidade, pois pe em risco a prpria sobrevivncia do planeta e so
constitudos pelos seguintes fenmenos: efeito estufa, depleo da camada
de oznio, acmulo de lixo txico, perda de biodiversidade e esgotamento
de recursos no renovveis (MARTINE, 1993).

Ainda segundo Martine, num patamar inferior de gravidade, periculosidade e

irreversibilidade, encontram-se problemas derivados de trs fatores isolados ou
combinados entre si: uso de tecnologias inadequadas, m administrao de

4
CONSTITUIO DA REPBLICA FEDERATIVA DO BRASIL DE 1988 - CAPTULO VI, DO MEIO AMBIENTE
 19

recursos naturais e crescimento populacional. So os fenmenos relativos a chuva

cida, desertificao, eroso, poluio do ar, enchentes e esgotamento de recursos
hbridos. A contaminao radioativa, vista como reversvel e, portanto localizada,
pode ser considerada, porm, questo de risco global, quando analisada na
perspectiva de acidente nuclear de propores no controlveis ou de guerra
atmica.
A preocupao atualmente da qualidade do ar, sendo um dos principais
componentes da qualidade de vida de todos, pode provocar danos sade, com a
emisso cada vez maior de poluentes na camada atmosfrica. Isso faz com que as
empresas de transporte coletivo busquem alternativas para a sustentabilidade.
Em Curitiba, a URBS junto s empresas operadoras, constantemente h
medies de fumaa no escapamento dos nibus, a fim de reduzir cada vez mais
emisses de poluentes pelo transporte coletivo. Alm disso, o uso de combustveis
alternativos vem sendo vistos como outra alternativa para a sustentabilidade. Hoje,
dispomos de transporte coletivo chamados Hibribus, ao qual movido
eletricidade e biodiesel, reduzindo 89% na emisso de material particulado, 80% de
xido de nitrognio (NOX) e 35% de CO2, alm da reduo de consumo de at 35%
de combustvel.
Com essas melhorias, as empresas de transporte coletivo buscam cada vez
mais incentivar a populao a utilizar o transporte coletivo. E com isso, deficientes
visuais ou auditivos busquem esse meio de transporte para se locomover. Como
disse o ex-prefeito de Bogot, Enrique Pealosa, se todos os cidados so iguais
diante da lei, um nibus com 60 passageiros tem mais direitos que um carro com
um.

2.1.4 Transporte coletivo

O art. 34 do Decreto n 5.296/20045 diz que os sistemas de transporte coletivo

so considerados acessveis quando todos os seus elementos so concebidos,

5
Decreto n5.296 de 2 de Dezembro de 2004. CAPTULO V DA ACESSIBILIDADE AOS SERVIOS DE
TRANSPORTES COLETIVOS
 20

organizados, implantados e adaptados segundo o conceito de desenho universal,

garantindo o uso pleno com segurana e autonomia por todas as pessoas.
Para entender melhor sobre o que significa desenho universal, o inciso IX do
art. 8 diz que a concepo de espaos, artefatos e produtos que visam atender
simultaneamente todas as pessoas, com diferentes caractersticas antropomtricas
e sensoriais, de forma autnoma, segura e confortvel, constituindo-se nos
elementos ou solues que compem a acessibilidade.
O transporte coletivo precisa buscar continuamente solues para atender ao
aumento crescente de passageiros e aos novos desafios do trfego das grandes
metrpoles. A busca da meta transporte bom, barato e com qualidade ainda o
maior desafio dos gestores pblicos, que operam o transporte coletivo.

O papel principal do transporte coletivo, hoje, nos pases em

desenvolvimento, servir de meio de locomoo para as pessoas que no
tem opes de outros meios de ir e vir. Essas populaes, que se situam
nas menores faixas de renda da escala social, representam a grande
maioria dos habitantes das metrpoles. Portanto, ao servi-las, o sistema de
transporte coletivo desempenha um papel muito importante para o equilbrio
social e econmico. (BERTOLDI, 2005 pg. 48).

Ao deparar com o aumento de populao mundial concentrada nas zonas

urbanas, nota-se o quo necessrio investir na sustentabilidade ambiental e
qualidade de vida, pois vo depender cada vez mais de como as reas urbanas so
planejadas, desenvolvidas e gerenciadas. Assim, haver duas alternativas no futuro,
um crescimento desorganizado ou um espao pblico formatado de forma planejada
e capaz de suportar a quantidade de pessoas vivendo no planeta. A estimativa da
Organizao das Naes Unidas (ONU) que nas prximas dcadas o crescimento
populacional do planeta se dar nas cidades, nas quais vivero sete em cada dez
pessoas em 2050.
O art. 3 6 . informa que, o planejamento do sistema de transporte ser
adequado s alternativas tecnolgicas aplicadas ao atendimento do interesse
pblico e dever obedecer as diretrizes gerais do planejamento global da cidade,
notadamente no que diz respeito ao uso e ocupao do solo e ao sistema virio
bsico.

6
Lei n 7556/90 (regulamentada pelo Decreto n 2101991) vide lei n 12597/2008) do CAPTULO II do
Planejamento e da Implantao dos servios em Curitiba
 21

E o art. 1 7 . diz que ficam isentas de pagamento da tarifa do transporte

coletivo urbano, todas as pessoas carentes, portadoras de deficincia fsica, mental,
auditiva ou visual, mediante apresentao de carteirinha de iseno fornecida pela
Prefeitura Municipal de Curitiba.
Compete assim, que os usurios foco deste projeto so isentos do pagamento
da tarifa do transporte coletivo urbano, garantindo o direito de ir e vir. Porm ainda
h paradigmas que devem ser quebrados para os mesmos usufrurem desse direito
com mais independncia.

2.1.5 Dispositivos mveis e smartphones

Os dispositivos mveis so usados corporativamente h muito tempo, mas

nos ltimos trs anos se tornaram o centro das atenes. Alis, h pouco mais de
trs anos no havia muita coisa. No existia iPhone, nem tablets, os aplicativos
mveis no eram demandados e os smartphones eram minoria nas empresas. Tudo
bem que j existiam os tablets havia muitos anos, mas o iPad veio para revolucionar
esse mercado, e os primeiros eventos de tecnologia de 2011, como Consumer
Electronic Show, em Las Vegas, e o Mobile World Congress, em Barcelona, s
falaram de tablets.

O que de fato est acontecendo uma substituio dos computadores por

esses novos dispositivos e, claro, assim como o rdio no foi totalmente
substitudo pela televiso e nem est pela internet, ambos continuaro
vivendo no mercado corporativo. Tenho minhas dvidas se os desktops
tero vida longa, porque os notebooks esto muito baratos, e a ameaa dos
dispositivos mveis tambm vai ajudar a reduzir o seu uso. E, dessa forma,
parte do foco que estava no desenvolvimento para Web e desktops passa
para os aplicativos mveis. Na verdade, a movimentao sobre os
aplicativos mveis, principalmente aqueles com foco no consumidor,
lembram muito o comeo da internet, em que todas as empresas queriam
ter um Website: hoje, todos querem ter um aplicativo mvel. (DARIVA, 2011.
p. 2)

7
Lei n 8623/1995 data de 28/04/1995 da Cmara Municipal de Curitiba.
 22

Como diz Dariva (2011, pg.2) A mobilidade pode trazer muita reduo de
custos para sua empresa, alm de ganhos de produtividade, seja com aplicativos ou
simplesmente com a entrega de softwares de colaborao nos dispositivos mveis.

2.2 Gerenciamento de Projetos

Segundo o PMBOK (2008, pg.05) projeto um esforo temporrio

empreendido para criar um produto, servio ou resultado exclusivo. A NBR ISO
1006: 2000, define um projeto como processo nico, consistindo de um grupo de
atividades coordenadas e controladas com datas para incio e trmino, empreendido
para alcance de um objetivo conforme requisitos especficos, incluindo limitaes de
tempo, custo e recursos. Estas colocaes focam a necessidade do projeto ter um
incio e um fim bem definidos.
O PMBOK (2008, pg. 06) define Gerenciamento de Projetos como a
aplicao de conhecimento, habilidades, ferramentas e tcnicas s atividades do
projeto a fim de atender aos seus requisitos. Nesta abordagem coloca a
necessidade de ter etapas de gerenciamento bem definidas e entender as
necessidades do projeto, como o escopo, cronograma, oramento, riscos e partes
interessadas. Alguns desses fatores podem sofrer alterao no decorrer do projeto.
Estando eles fortemente relacionados, qualquer alterao que ocorra em um deles,
provavelmente ir afetar os demais. Por esse motivo preciso trabalhar com
melhoria contnua, informaes bem detalhadas e alto conhecimento do ciclo de vida
do projeto.

O ciclo de vida do projeto consiste nas fases do mesmo que geralmente so

sequenciais e que s vezes se sobrepem, cujo nome e nmero so
determinados pelas necessidades de gerenciamento e controle das
organizaes envolvidas, a natureza do projeto em si e sua aplicao
(PMBOK, 2008, pg.15).
 23

A gesto de projeto uma ferramenta estratgica para o desenvolvimento do

projeto, pois proporciona diminuir riscos, reduzir custos e aumentar a qualidade de
entrega.

2.2.1 Metodologia gil

A Metodologia gil um conjunto de metodologias de desenvolvimento de

software, a qual disponibiliza uma estrutura conceitual para dirigir projetos de
engenharia de software. Os Mtodos geis procuram minimizar os riscos do
desenvolvimento de software em curto prazo, enfatizam comunicao em tempo real
entre equipe e cliente e preveem a produo de pouca documentao quando
comparada com outros mtodos.
Os Mtodos geis so mais adequados para grupos pequenos, para que a
comunicao seja facilitada. Os integrantes do grupo devem ser auto gerenciveis.
preciso que o cliente concorde com o mtodo, pois ele estar mais envolvido com
o desenvolvimento, uma vez que Mtodos geis envolvem a comunicao constante
com o cliente.
So metodologias geis: Programao Extrema, Scrum, FDD (Feature Driven
Development), TDD (Test Driven Development) entre outras.
A utilizao da Metodologia gil prev entregas menores e mais constantes, o
que facilita no tratamento de mudanas imprevisveis de requisitos.

2.2.2 Modelagem gil

A Modelagem gil (MA) uma metodologia baseada na prtica para a

modelagem e documentao eficazes de sistemas baseados em software.
A metodologia MA um conjunto de prticas guiado por princpios e valores
para profissionais de software aplicarem em seu dia a dia. A MA no um
processo prescritivo (AMBLER,2004).
 24

Essa metodologia procura minimizar riscos durante o desenvolvimento do

projeto, tendo tarefas bem definidas e entregas em curtos perodos. Tem como
princpios, garantir a satisfao do consumidor, receber bem mudanas de
requisitos, fazer entregas frequentemente, desenvolver um software funcional,
simplicidade, respostas rpidas a mudanas.
Para o desenvolvimento do projeto em questo, optou-se por essa
metodologia levando em considerao o tempo reduzido para o desenvolvimento do
mesmo. Um dos conceitos da Modelagem gil a reduo da carga de trabalho,
onde a documentao feita de maneira eficaz, sendo que o objetivo ter a
documentao suficiente e que contenha informaes necessrias para satisfazer o
seu propsito.

2.2.3 Programao Extrema (XP)

A XP uma metodologia gil baseada em prticas, assim como a Modelagem

gil.
Um dos modos para o levantamento dos requisitos a Histria do usurio,
que fornece uma viso de alto nvel dos requisitos do sistema. Para o
desenvolvimento desse projeto, foi utilizada a vivncia diria de um dos integrantes
da equipe, o qual possui deficincia visual e se depara com diversas dificuldades no
dia a dia.
Essa metodologia no especifica documentos provveis a serem criados
durante o desenvolvimento, diferenciando do processo unificado, que sugere muitos
artefatos potenciais do projeto. A sugesto da XP trabalhar junto com o cliente em
ambiente de retorno rpido e confiar neles para que determinem o que precisa.
A documentao em um projeto XP uma deciso de negcio, no tcnica
conforme define Jeffries (2001).
Se houver a necessidade de um documento, o cliente deve solicit-lo da
mesma forma que solicitaria uma caracterstica, com um carto de histria. A equipe
estimar o custo do documento e o cliente poder agend-lo em qualquer interao
que desejar.
 25

A necessidade de documentao reduzida devido a diversas prticas da

XP. Uma delas a simplicidade, focando na clareza do cdigo. Caso o cdigo no
seja claro, preciso reescrever o mesmo tornando-o mais claro e limpo.
A XP utiliza como prtica, o desenvolvimento pareado, onde dois
programadores desenvolvem o cdigo juntos, em uma nica mquina. Outra prtica
da metodologia o desenvolvimento voltado ao teste, trabalhando em ciclos curtos:
considera um teste, escreve o teste e o cdigo para ele, coloca-o para funcionar e
ento continua o desenvolvimento.
As prticas utilizadas para o desenvolvimento desse projeto foram:
Desenvolvimento Pareado, devido linguagem de programao escolhida
para o desenvolvimento do aplicativo ser voltada para Iphone e utilizar apenas
plataforma de desenvolvimento Apple, o desenvolvimento foi feito pareado, pois
apenas um dos programadores possui o equipamento adequado para o mesmo.
Levantamento de requisitos atravs da Histria do Cliente. Foram utilizadas
as histrias e dificuldades do Adriano, que apesar de fazer parte do grupo, tambm
atuou como cliente potencial.
O cdigo foi feito de maneira mais simples e fcil de ser compreendido,
utilizando a prtica da Refatorao.
Foi utilizado um Design Simples para tornar mais fcil a utilizao pelo
deficiente visual.
Foram feitas reunies em p, de at 10 minutos, nos encontros realizados na
faculdade, minutos antes do incio da aula.

2.2.4 Linguagem de Modelagem Unificada (UML)

A linguagem de modelagem unificada a notao utilizada por mtodos para

expressar projetos. O processo a sugesto de quais passos a serem seguidos na
elaborao de um projeto (FOWLER, 2000).
Surgiu no final dos anos 80 e unifica os mtodos de Booch, Rumbaugh (OMT)
e Jacobson. Passou por um processo de padronizao pela OMG (Object
Management Group) e agora um padro OMG.
 26

Booch, Rumbaugh(OMT) e Jacobson definem a UML da seguinte forma: A

UML (Unified Modeling Language) uma linguagem-padro para a elaborao da
estrutura de projetos de software. Para Larman, a Linguagem de Modelagem
Unificada(UML) uma linguagem visual para especificar, construir e documentar os
artefatos dos sistemas de software (Larman, 2007).
O vocabulrio e regras da UML tm o seu foco voltado para a representao
conceitual e fsica de um sistema, sendo uma linguagem-padro para a elaborao
da estrutura de projetos de software e indicam como criar e ler modelos bem-
formados, servindo como guia para tomada de decises importantes no projeto, tais
quais, decidir quais artefatos sero produzidos, quais atividades e trabalhadores
sero escolhidos para cri-los e gerenci-los e como os artefatos sero empregados
para medir e controlar o projeto num todo. Um projeto ter vrios modelos,
conectados entre si.
Por ser uma linguagem visual, possvel utilizar os modelos de UML em
diversas linguagens de programao. Sua estrutura expressa em diagramas, que
consistem na apresentao grfica de um conjunto de elementos.
Para o desenvolvimento deste projeto, foram utilizados os Diagramas de Caso
de Uso, Diagrama de Classe, Diagrama de Sequncia, Diagrama de Componente e
Diagrama de Implementao.

2.3 Modelagem de sistemas de software

2.3.1 Estrutura Analtica do Projeto (EAP / WBS)

Dentro do gerenciamento do projeto, podemos citar a EAP, uma ferramenta

importante a qual ajuda a colocar em evidncia os itens reais necessrios para a
realizao de um projeto.
A EAP uma decomposio hierrquica orientada entrega do trabalho a ser
executado pela equipe para atingir os objetivos do projeto. Essa decomposio
feita em componentes menores e de gerenciamento mais fcil. Nela deve conter
 27

todo o esforo do projeto, onde cada nvel mais baixo tem que escalar aos nveis
mais altos, somando 100% da entrega e do projeto.
A importncia da EAP vai alm de definir e organizar o trabalho do projeto,
pois atravs dela, pode-se ter maior controle do escopo do projeto, melhor preciso
quanto ao custo do projeto, controle do desenvolvimento dos requisitos e
acompanhamento de potenciais riscos e melhor identificao das subtarefas
impactadas por um entrega que no ocorreu ou est em atraso.

Figura 1 Exemplo de Estrutura Analtica de Projeto

2.3.2 Casos de uso

Um caso de uso uma descrio de um conjunto de sequncias de aes,

inclusive variantes, que um sistema executa para produzir um resultado de valor
observvel por um ator. (BOOCH; RUMBAUGH; JACOBSON, 2012).
Atravs do caso de uso, possvel captar o comportamento pretendido do
sistema. Todos esses comportamentos podem ser especificados
independentemente de suas realizaes. O caso de uso descreve um conjunto de
 28

sequncias representando a interao de itens externos aos sistemas, chamados de

Atores, com o prprio sistema.
Um ator representa um conjunto coerente de papis que os usurios de casos
de uso desempenham quando interagem com esses casos de uso (BOOCH;
RUMBAUGH; JACOBSON, 2012).
O ator um elemento externo ao sistema, porm se comunica com o caso de
uso na troca informaes com o sistema, onde cada um tem a possibilidade de
enviar e receber mensagens, utilizando uma funcionalidade. Ele dever estar
relacionado a pelo menos um caso de uso do sistema. Os casos de uso podem estar
relacionados entre si.
A UML define diversos tipos de relacionamentos no modelo de caso de uso:
comunicao, incluso, extenso e generalizao (Bezerra,2002).
Para especificar o comportamento de um caso de uso, pode se descrever o
fluxo de evento, incluindo como e quando o fluxo inicia e termina, quando o caso de
uso interage com os atores e quais os objetivos so transferidos. O sistema poder
ter o fluxo principal (bsico), onde descreve o que geralmente acontece quando o
caso de uso realizado, o fluxo alternativo, o qual descreve uma escolha diferente
do descrito no fluxo principal e o fluxo de exceo que descreve quando algo
inesperado ocorre na interao do sistema (ator e caso de uso).
Os casos de uso ajudam a validar a arquitetura e verificar o sistema durante a
evoluo do seu desenvolvimento. Tambm podem fazer referncia s regras de
negcio do sistema.

2.3.3 Diagrama de caso de uso

O diagrama de caso de uso um diagrama que mostra um conjunto de casos

de uso e seus relacionamentos (BOOCH; RUMBAUGH; JACOBSON, 2012).
Corresponde a uma viso externa do sistema, representando de maneira
grfica os atores, caso de uso e relacionamento entre eles. Seu objetivo mostrar
quais elementos externos interagem e com que funcionalidades do sistema.
 29

O ator representado pela figura de um boneco. No necessariamente ser

um ser humano, pode ser outro sistema. Cada caso de uso representado por uma
elipse. Os relacionamentos so representados por um segmento de reta, ligando
ator ao caso de uso. Essas 3 representaes so a base num diagrama de caso de
uso, podendo ter outras, como por exemplo, a representao da fronteira do
sistema, representada por um retngulo.
O diagrama de caso de uso utilizado para ter a viso esttica do caso de
uso, especificando e documentando o comportamento de um elemento. Dessa
maneira o sistema, subsistema e classes ficam acessveis e compreensveis,
apresentando viso externa de como os elementos podem ser utilizados no
contexto.
Um nico caso de uso no deve captar tudo a respeito da viso de caso de
uso de um sistema. Para a representao da viso esttica completa, necessrio
um conjunto de diagramas, onde individualmente cada um apresenta apenas um
aspecto do sistema. Para que um diagrama de caso de uso seja bem estruturado,
ele no deve ser to minimalista. preciso ter como foco, um aspecto da viso
esttica de caso de uso do sistema, contendo apenas os casos de usos essenciais a
compreenso desse aspecto, com detalhes consistentes ao nvel de abstrao.
Os diagramas de uso tambm so importantes para testar sistemas
executveis por meio de engenharia de produo e para compreend-los por meio
de engenharia reversa (BOOCH; RUMBAUGH; JACOBSON, 2012).

Figura 2 Exemplo de Diagrama de Caso de Uso

 30

2.3.4 Diagrama de classe

Um Diagrama de classe um diagrama que mostra um conjunto de classes,

interfaces e colaboraes e seus relacionamentos. Graficamente, um diagrama de
classe uma coleo de vrtices e arcos. (BOOCH; RUMBAUGH; JACOBSON,
2012).
O diagrama de classe descreve os tipos de objetos no sistema e os vrios
tipos de relacionamento esttico existente entre eles. Alm disso, mostra atributos e
operaes de uma classe e as restries maneira com que os objetos so
conectados. Ele composto de classes e relacionamentos.
A classe representa um conjunto de objetos e contm as especificaes dos
mesmos. Geralmente as classes se relacionam entre si e definem responsabilidades
tais quais: Associao, Dependncia e Herana.
De acordo com Steve Cook e John Daniels (1994) existem trs perspectivas
que podem ser usadas pra projetar diagramas de classes:
Conceitual representa os conceitos no domnio que est sendo
estudado. So relacionados s classes que vo execut-los, mas no
existe um mapeamento direto. Esse modelo deve ser projetado sem se
preocupar com o software, pois pode ser considerado independente da
linguagem.
Especificao. Nesta perspectiva a interface do software considerada,
porm no considera a implementao.
Implementao Perspectiva usada com maior frequncia, considera a
implementao.
Os diagramas de classe permitem a visualizao, a especificao, a
documentao de modelos estruturais e a construo de sistemas executveis por
intermdio de engenharia direta e reversa.
Os Diagramas de classes so importantes para a visualizao, a
especificao, a documentao de modelos estruturais e a construo de sistemas
executveis por intermdio de engenharia direta e reversa (BOOCH; RUMBAUGH;
JACOBSON, 2012).
 31

Figura 3 Exemplo de Diagrama de Classe

2.4 Tecnologias utilizadas

2.4.1 Xcode5

Criado pela Apple, o Xcode5 um ambiente de desenvolvimento integrado

com a finalidade para softwares compatveis com Mac OS X e IOS. O Xcode5
fornece ferramentas para gerenciar todo o fluxo de trabalho de desenvolvimento,
desde a criao do aplicativo, os testes, otimizao at envi-lo para a App Store.
A interface do Xcode5 integra a edio de cdigo, design da interface de
usurio, gerenciamento de ativos, testes e depurao dentro de uma nica janela do
espao de trabalho. (APPLE Store). Com o Interface Builder, editor de design visual
integrado no Xcode5, possvel criar as interfaces do usurio e o Layout
automtico, possibilitando a definio de regras para que os objetivos se ajustem
 32

automaticamente ao tamanho da tela, a orientao do dispositivo, o tamanho da

janela e a localizao.
Alm do Objective-C, o Xcode5 suporta as linguagens C, C++, Objective-C++,
Java, AppleScript, Python e o cdigo-fonte do Ruby (linguagem puramente orientada
a objeto) com uma variedade de modelos de programao, incluindo, mas no
limitado a Cocoa e Carbon, ambas interfaces de programao de aplicativo para
computadores Apple. Terceiros adicionaram suporte para GNU Pascal, Free Pascal,
Ada, C#, Perl e D.

2.4.2 Plataforma IOS

Sistema operacional mvel desenvolvido e distribudo pela Apple Inc.

Inicialmente lanado apenas para iPhone, foi estendido para suportar outros
dispositivos da Apple, como o iPod Touch, iPad, entre outros.
O IOS uma variante do OSX. Por ser baseada na arquitetura Kernel da
OSX, sofreu algumas alteraes para que pudessem suprir algumas restries
existentes como limitaes de processamento, memria, restrio no consumo de
energia, entre outros.
Essa plataforma fornece importantes grupos de servios:
Servios essenciais do SO (Core OS) uma variao do OSX, suporta
servios de segurana, gerenciamento de energia, certificados, sistema de arquivos,
processamento paralelo.
Servio em nvel de aplicao (Core Service) fornece funcionalidades
importantes aos aplicativos como colees, caderno de endereo, servios de redes,
acesso a arquivos, banco de dados, localizao, informaes sobre referencias e
utilitrios para internet.
Cocoa Touch conjunto de bibliotecas de suporte formado por diversos
frameworks determina a forma como as aplicaes so desenvolvidas. Oferece
conjunto de recursos para responder ao toque do usurio tais como componentes
grficos, multi-toque, localizao, alertas, Web View, mapas e cmera. Os principais
framewoks so, o Foundation Kit e o UIKit
 33

O IOS tambm permite que sejam utilizadas as APIs bsicas baseadas em C,

permitindo assim a reutilizao de cdigos que possam ter sido desenvolvidos para
outras plataformas mveis e tambm o uso de vrias bibliotecas de cdigo aberto.

2.4.3 Objective-C

Objective-C a linguagem de programao utilizada para desenvolvimento na

plataforma IOS.
Essa linguagem foi escolhida devido ao equipamento utilizado pelo
programador e o equipamento de teste ser plataformas que comportam esta
linguagem.
Objective-C um superconjunto da linguagem C, a qual baseada em
procedimentos, porm oferece recursos orientados a objetos. Pode ser considerada
uma linguagem dinmica, por ter o modelo de programao orientada a objetos com
base no envio de mensagens a objetos, diferente do modelo C++ e Java, aos quais
chamam mtodos diretamente em um objeto.
Sua biblioteca de suporte o SDK, tambm conhecida como Cocoa Touch e
oferece um conjunto de recursos, sendo os principais frameworks o Foundation Kit e
o UIKit.
 34

3. ORGANIZAO-CLIENTE

A organizao-cliente o Centro de Incluso da prpria Universidade

Positivo, junto ao discente Adriano Chemin, participante da equipe do PAP Vamos
de Buso.
A Universidade Positivo uma instituio de Educao Superior, pertencente
ao Grupo Positivo. Teve origem nas Faculdades Positivo, em 1988, com cursos de
Graduao, Especializao Ps Graduao Latu Senso e tambm Mestrado.
O Centro de incluso um setor dentro da Universidade Positivo responsvel
pela anlise e implementao de novos programas que possibilitem s pessoas com
deficincia, tanto alunos como colaboradores ingressos na instituio, a terem um
desenvolvimento de suas atividades acadmicas e profissionais dentro da
universidade com qualidade.
Visando atender a todos o Centro de incluso tem como premissa um
processo no qual se criam condies e possibilidades para que as pessoas com
deficincia possam ser realmente includas na sociedade, respeitando s
necessidades de cada um.

3.1 Histrico do Centro de incluso

O Centro de Incluso entrou em vigor no ano de 2009 quando houve a

chegada de um nmero realmente expressivo de alunos com deficincia, o que
exigiu medidas para que esses estudantes pudessem desempenhar, com qualidade,
suas atividades acadmicas.

A partir dessa necessidade, foi colocado em prtica o projeto do Centro de

Incluso tendo sua inaugurao realizada em 1 de abril de 2009.
 35

3.2 Misso

Produzir e disseminar, internamente, as politicas de incluso, valendo-se de

todas as instncias cabveis, em ensino, pesquisa e extenso. Contribuir para que a
UP possa formar cidados e profissionais que sejam capazes de conviver com a
diversidade e compreender a singularidade das pessoas, para que, sob esta tica,
as relaes humanas sejam harmoniosas. O Centro de Incluso insere-se na misso
da Universidade Positivo no quesito da construo de um homem e um mundo
melhor.

3.3 Viso

Contribuir para que a Universidade Positivo seja reconhecida como uma

instituio de ensino que oportuniza a todos que delas participam vivenciar a mesma
situao salvaguardando suas especificares inerentes.

3.4 Valores

- Aceitao da diferena do outro.

-Respeito pela diversidade humana.
-Conscincia das necessidades individuais das pessoas.

A organizao cliente do projeto atende atravs do telefone: (41) 3317-3000 e

tambm o contato pelo site: www.up.com.br.

O aluno Adriano Chemin, membro da equipe do PAP, deficiente visual,

participa como parte da organizao-cliente.
 36

4. DIAGNSTICO DO AMBIENTE

4.1 Depoimento Adriano Chemin

Meu nome Adriano Chemin e nasci com a deficincia visual. Sou portador
de uma doena degenerativa da retina e, neste depoimento, direi uma das minhas
dificuldades por ser cego.
Dentre as dificuldades que tenho em meu cotidiano, a mobilidade a que
mais se destaca. Ao fazer minhas atividades dirias como estudar, trabalhar, ir a
lugares a passeio, a maioria dessas atividades necessito do transporte pblico.
Resido atualmente na regio Metropolitana de Curitiba, chamada Campo
Largo, trabalho tambm na regio Metropolitana de Curitiba, porm em Pinhais e
estudo em Curitiba.
Para esse trajeto, utilizo 2 linhas de nibus diferentes todos os dias para ir ao
trabalho. Do trabalho ao Centro Tecnolgico Universidade Positivo utilizo 2 linhas.
Ao retornar da CTUP minha residncia, neste percurso utilizo 2 linhas de nibus
diferentes.
No que se refere ao transporte coletivo, a maior dificuldade dos cegos est
nas questes de saber qual nibus est se aproximando ao ponto de embarque e,
em muitas vezes, em qual ponto precisam desembarcar.
Quando estou no ponto de embarque, necessito perguntar a uma pessoa que
esteja aguardando tambm no mesmo local, qual o nibus se aproxima e, quando
no h indivduos prximos, a dificuldade aumenta, pois sempre necessito levantar
as mos quando escuto os sons parecidos com um nibus. Deixar sempre a bengala
visvel para o motorista, para que qualquer nibus que esteja se aproximando, pare
para me informar qual a linha que parou no embarque. Caso no seja a linha que
desejo, eu agradeo ao motorista e informo que aquele no o nibus que estou
aguardando. Em momentos chuvosos, a dificuldade aumenta, para o motorista me
ver aguardando no ponto de embarque.
Aps o embarque da linha que desejo, preciso informar ao cobrador ou ao
motorista, o ponto que preciso desembarcar para que, ao estar prximo ao local
indicado, os mesmos me informem o ponto que preciso descer.
 37

4.2 Os surdos e o transporte coletivo

Os surdos, tambm tem grande dificuldade para usufruir dos meios de

transporte coletivo.
Tanto para os cegos quanto para os surdos, as informaes iniciais sobre o
local de embarque, a linha de nibus que deseja e tambm o ponto de desembarque
so necessrios para utilizar os meios de transporte urbano.
Porm h o problema de que, caso o surdo no saiba exatamente quando
solicitar o ponto de desembarque, seja necessrio pedir informaes. Mas no mundo
oral que vivemos, a falta da fala traz barreiras para os mesmos, pois para pedir
auxlio a um terceiro, preciso falar e, para isso, eles precisam estar dotados de
papel e caneta ou um celular que possa escrever, informando o local que deseja.
O que muitos no sabem a limitao dos surdos na aprendizagem da
escrita. As dificuldades que sofrem desde o ensino bsico nas escolas, pois os
professores no fazem estudos sobre a lngua dos sinais para trabalhar com mais
facilidade no ensino da lngua portuguesa.
Com isso, ao escrever em um papel o que deseja, muitas vezes no
transmitido de forma clara para o indivduo que recebe a mensagem e vice-versa,
gerando mal-entendidos, consequentemente fazendo com que o surdo se isole da
sociedade para evitar esse tipo de constrangimento.

A falta de domnio de uma lngua pelo surdo dificulta a construo de sua

subjetividade e este fator, em conjunto com as prticas pedaggicas que
enfatizam a deficincia como empecilhos para o aprendizado fazem com
que o surdo no seja estimulado de maneira eficaz, que impulsione seu
desenvolvimento lingustico e cognitivo (SILVA, 2005).

4.3 O uso do transporte coletivo para os deficientes visuais e auditivos

Esses indivduos acabam sendo excludos da sociedade, devido dificuldade

para ir e vir de lugares sem a necessidade de auxlio de terceiros. Para saber qual o
nibus que realmente desejam embarcar, preciso fazer uma busca antes de se
 38

locomoverem, qual o nibus e tambm qual o ponto que deseja embarcar e

desembarcar. Os deficientes visuais precisam que os motoristas o vejam no ponto,
para que possam parar onde esto e perguntar se o nibus o desejado pelo
usurio. Em dias de chuva, h grandes chances de no serem vistos aguardando no
ponto de embarque, perdendo as linhas que esto esperando. Tambm precisam de
auxlio de pessoas que estejam nos pontos de nibus, para avis-los qual o nibus
que esteja esperando. J os deficientes auditivos apenas necessitam dessa
pesquisa e aguardam no ponto escolhido.
Ambos necessitam de auxlio para desembarcar, quando o ponto de nibus
desconhecido. Os deficientes visuais atualmente, solicitam ajuda do cobrador,
motorista ou algum passageiro para ser avisados qual o ponto escolhido. O
problema que os mesmos precisam ter certa confiana no que lhes foram
repassados, pois h certa probabilidade que a informao seja repassada
erroneamente. J os deficientes auditivos, pela dificuldade de se comunicarem,
precisam estar sempre com papis e canetas ou um celular, algo que possam
informar qual o ponto de desembarque, para que um terceiro entenda a solicitao
de informao e o avise qual o momento de descer do nibus.
Com as dificuldades que os cercam, muitos no utilizam o transporte coletivo
para irem a lugares desejados, ficando cada vez mais exclusos da sociedade.
Acredita-se em uma melhoria na convivncia entre ser humano e meio
ambiente por meio de dinmicas culturais e colaborao em massa, valendo-se da
tecnologia para tornar possvel um novo desenho de desenvolvimento urbano
sustentvel.
H conscincia de que o transporte coletivo ainda precrio para Curitiba e
em muitos lugares do Brasil. Ter a viso de que precisa ser melhorado e buscar
meios para isso, traz mudanas e alternativas para quem busca sempre estar meio
igualdade social.
Com o auxlio da tecnologia, a presena dos que antes foram excludos pela
sociedade, est cada vez mais forte.
 39

4.4 O transporte coletivo em Curitiba

Em Curitiba, a empresa responsvel pelo transporte coletivo, URBS, buscou

melhorar a acessibilidade dos cadeirantes. 94% da frota atualmente de veculos do
transporte coletivo possui acessibilidade total, ou seja, com elevadores nas linhas
alimentadoras, interbairros, troncais e convencionais, assim como embarque em
nvel nos expressos e ligeirinhos. Assim, mais de 90% das linhas da Rede Integrada
de Transporte garantem a acessibilidade de cadeirantes e pessoas com mobilidade
reduzida, com espao e equipamentos para sua segurana no interior do nibus.
Sinais luminosos indicam a abertura das portas dos nibus, beneficiando
especialmente pessoas com deficincia auditiva e, plaquetas em braile fixadas no
encosto dos bancos especiais, indicam o nmero do veculo para que a pessoa com
deficincia visual possa identific-lo.
Parece pouco, mas isso demonstra uma evoluo para o meio de transporte
urbano. Cerca de 10% do total de usurios/ms do sistema de transporte integrado
tem algum tipo de deficincia ou tem idade acima de 65 anos, estes possuem
iseno tarifria.
Outra inovao na rea do transporte urbano em Curitiba o ACESSO
transporte especial. Ainda em fase de teste na rea da Administrao Regional
Pinheiro, um servio de micro-nibus porta a porta, com elevador, cadeira de
rodas, espao para co-guia e acessrios necessrios para garantir a mobilidade de
pessoas com deficincia. Funciona da seguinte forma: o nibus apanha as pessoas
com deficincia na porta de casa, leva at a porta do servio de que ela precisa e
deixa na porta da residncia da pessoa, quando terminar o atendimento.

4.5 Objetivo do sistema

O objetivo deste projeto de inovao criar um aplicativo que d

acessibilidade aos deficientes visuais e auditivos, proporcionando mais facilidade de
ter o direito de ir e vir, utilizando o meio de transporte coletivo, pois o sistema atual
 40

de transporte pblico deficiente, dificultando os indivduos que querem ter mais

independncia em sua vida.
A aplicao deve possibilitar que o usurio saiba qual o nibus que esteja
esperando no ponto, para poder solicitar o embarque. Assim que tenha embarcado
na linha, poder saber qual o momento que desejar o desembarque, solicitando ou
aguardando como qualquer passageiro, sem a necessidade de ajuda de outros.
 41

5. DESENVOLVIMENTO

O desenvolvimento do projeto Vamos de Buso iniciou-se em maio de 2013,

atravs de conversas entre a equipe, principalmente por um dos membros
considerados como uma das organizaes cliente, Adriano Chemin.
Atravs do discente, Adriano, temos uma noo da dificuldade imposta pela
deficincia visual, para que o mesmo utilize o transporte coletivo de Curitiba e regio
metropolitana.
Como o Adriano mesmo informa em seu testemunho, ainda uma barreira
para todos os deficientes visuais, principalmente a falta de informao das pessoas,
pois no conhecem suas limitaes e o que fazem em sua rotina diria.
A dificuldade imposta ainda pela estrutura de meios de transporte de Curitiba
e regio metropolitana, faz com que indivduos como o Adriano, deficientes visuais,
acabam desistindo de utilizar as linhas disponveis para todos.
Vendo a real necessidade dos deficientes visuais e auditivos, elaboramos o
projeto Vamos de Buso.
Com o aplicativo, o indivduo precisar saber o ponto de embarque, qual a
linha que deseja e tambm o ponto de desembarque. Quando o usurio estiver em
seu ponto escolhido, marcar o nibus que embarcar e tambm o ponto ou
estao-tubo que deseja desembarcar. O nibus ser localizado atravs do GPS,
avisando o usurio quando estiver prximo do mesmo, para que d um sinal ao
motorista, caso esteja em um ponto ou aguarde o embarque, caso esteja em uma
estao-tubo. Em sua rota, o usurio ser avisado, atravs de um sinal, que o
desembarque est prximo, para que o indivduo aguarde a descida na estao-tubo
ou avise que far a descida, caso esteja prximo do ponto escolhido.
Para definir o escopo do projeto, foi analisada a Estrutura Analtica do Projeto
(Apndice B item 8.2.3. p.61), que busca mostrar a viso macro do projeto.
O gerenciamento do projeto foi realizado com base nos conhecimentos
provenientes do PMBOK, o qual possui processos bem definidos e a Metodologia
gil XP, uma metodologia eficaz, com um conjunto de prticas guiadas por
princpios aplicados no dia-a-dia. As prticas adotadas durante o desenvolvimento
foram o desenvolvimento pareado, a refatorao do cdigo, design do sistema
simplificado, levantamento dos requisitos baseado na histria do cliente e as
 42

reunies rpidas de at 15 minutos. Com elas, buscamos minimizar riscos durante o

desenvolvimento do projeto, com as tarefas bem definidas e entregas dos mesmos
no prazo. Essa metodologia foi escolhida pelo tempo reduzido que o
desenvolvimento do Projeto de Aplicao Profissional nos designa.
Foram considerados teis para o trabalho os documentos apresentados para
o gerenciamento do projeto (Apndice A p.48), o Termo de abertura do projeto
(Apndice A item 8.1.1. p.48), o Plano de gerenciamento do escopo (Apndice B
item 8.2.1. p.60), Plano de gerenciamento do escopo (Apndice B p.60), o Plano de
gerenciamento do tempo (Apndice C. p.66), o Plano de gerenciamento da
qualidade (Apndice D p.71) e o Plano de gerenciamento da comunicao
(Apndice E p.73).
O Centro de Incluso da Universidade Positivo participa neste projeto como
parte interessada (Stakeholder), tanto como instituio de Ensino Superior, estrutura
acadmica da formao dos membros deste projeto, como organizao-cliente.
Outra parte interessada um dos autores deste trabalho, Adriano Chemin,
participante tambm como organizao-cliente.
Atravs dos Stakeholdes est a Especificao dos requisitos do projeto
(Apndice F p.75) necessrios e levantados a Especificao das regras de negcio
(Apndice A item 8.1.3. p.59), necessidades e funcionalidades que o sistema
precisa atender, presentes no Documento de viso (Apndice A item 8.1.2. p.51).
Para o desenvolvimento, ser utilizada a linguagem Objective-C para a
plataforma IOS. Escolhido pelo fato do cliente em potencial e tambm membro da
equipe, Adriano, possuir dispositivo compatvel com a plataforma optada.
Essa linguagem possui caractersticas similares a sintaxe de codificao
linguagem C, porm com seu objetivo maior estar voltado ao paradigma de
programao orientada a objetos.
O desenvolvimento est presente na Modelagem do sistema (Apndice G
p.77), onde est definido o Documento de Caso de Uso (Apndice G item 8.7.1.
p.77), o Diagrama de Caso de Uso (Apndice G item 8.7.2 p.80.), o Diagrama de
Classe (Apndice G item 8.7.4. p.81), o Diagrama de Sequncia (Apndice G
item 8.7.5. p.82), Diagrama de Componentes (Apndice G item 8.7.6. p.82) e o
Diagrama de Implantao (Apndice G item 8.7.7. p.83).
A arquitetura do software explica o funcionamento do sistema atravs de seu
desempenho, performance e outros elementos do sistema, como a viso lgica do
 43

aplicativo, a viso fsica e outras tecnologias utilizadas, presentes no Documento de

Arquitetura (Apndice H p.84).
 44

6. CONSIDERAES FINAIS

O projeto Vamos de Buso foi concludo graas ao desempenho de toda a

equipe. O objetivo proposto entregar um projeto que venha a ser utilizado por
muitos hoje excludos da sociedade, pela falta de entendimento sobre suas reais
necessidades.
A dificuldade gerada por todos, porm, se ns contribuirmos ao menos um
pouco para que esses indivduos possam se sentir mais prximos da sociedade e
tambm usufruir dos meios que o governo nos dispe, a tarefa que buscamos est
completa.
Houve vrios desafios pessoais que foram enfrentados para o
desenvolvimento do projeto. Apesar da ferramenta e a linguagem que utilizamos no
sistema no terem sido aprendidos durante o decorrer do curso, a base para
entender todo o processo para o desenvolvimento do mesmo esteve presente nas
aulas.
O desenvolvimento da documentao tambm foi baseado nos princpios
impostos pelo comprometimento de ensino dos professores das disciplinas voltadas
ao Gerenciamento e desenvolvimento de projetos.
Assim sendo, o aplicativo Vamos de Buso disponvel para IOS, produto
voltado a inovao tecnolgica, possibilita que qualquer usurio de transporte
coletivo em Curitiba e regio Metropolitana, no somente os deficientes visuais e
auditivos utilizem o transporte coletivo independente de auxlio de terceiros para
embarcar nos nibus e tambm solicitar o desembarque.
 45

7. REFERNCIAS BIBLIOGRFICAS

ABNT. Associao Brasileira de Normas Tcnicas - ABNT, 2008. Disponvel em:

<www.abnt.org.br>. Acesso em: 20. out. 2013.
AMBLER, S.W. Modelagem gil: Prticas eficazes para a Programao eXtrema
e o Processo Unificado. Traduo de Acauan Fernandes. Porto Alegre: Bookman,
2004.
BERTOLDI, O. Ideias para uma metrpole sustentvel. Disponvel em : <
http://books.google.com.br/books?id=sXWjiexcK0UC&pg=PA47&dq=transporte+cole
tivo+sustent%C3%A1vel&hl=pt-
BR&sa=X&ei=DiRjUvnrIZOo9gSky4BQ&ved=0CDgQ6AEwAA#v=onepage&q=transp
orte%20coletivo%20sustent%C3%A1vel&f=false> Acesso em: 18 ago. 2013.
BRASIL. Constituio da Repblica Federativa do Brasil de 1988. Disponvel em:
<http://www.planalto.gov.br/ccivil_03/constituicao/constituicaocompilado.htm >
Acesso em: 31 ago. 2013.
BRASIL. Decreto N 5.296 de 2 de dezembro de 2004. Disponvel em:
<http://www.planalto.gov.br/ccivil_03/_ato2004-2006/2004/decreto/d5296.htm>
Acesso em: 20 out. 2013.
D'VILA, M. H. C. PMBOK e Gerenciamento de Projetos. Minas Gerais: Belo
Horizonte, 2006. Disponvel em:
<http://www.mhavila.com.br/topicos/gestao/pmbok.html> Acesso em: 16 out. 2013.
DARIVA, R. Gerenciamento de dispositivos mveis e servios de telecom.
Disponvel em:
<http://books.google.com.br/books?id=juPhudC5UX4C&printsec=frontcover&dq=apli
cativos+m%C3%B3veis&hl=pt-
BR&sa=X&ei=jM1jUtipF4zO9ATwgIFY&ved=0CDoQ6AEwAA#v=onepage&q=aplicati
vos%20m%C3%B3veis&f=false> Acesso em: 14 set. 2013.
FAIRBAIRN,C.KP.;FAHRENKRUG, J. ;RUFFENACH,C. Objective-C Fundamental.
Traduo de Rafael Zanolli. So Paulo: Novatec, 2012.
FOWLER,M. UML Essencial: um breve guia para a linguagem-padro de
modelagem de objetos. Traduo de Vera Pezerico e Christian Thomas Price. 2
Edio. Porto Alegre: Bookman, 2000.
FRONTEIRAS, Equipe. A boa cidade: entrevista com Enrique Pealosa.
Disponvel em: <http://www.fronteiras.com/canalfronteiras/entrevistas/?16,11>.
Acesso em: 20 out. 2013.
FUNDAO DA UNIVERSIDADE FEDERAL DO PARAN. Diretrizes: Documento
de arquitetura de software. Disponvel em:
<http://www.funpar.ufpr.br:8080/rup/process/modguide/md_sad.htm#Contents>.
Acesso em: 05 out. 2013.
GESUELI, Z. M. Cidadania, surdez e linguagem: desafios e realidades.
Disponvel em:
 46

<http://books.google.com.br/books?id=aW1eGAAlDM0C&pg=PA89&dq=surdos&hl=p
t-
BR&sa=X&ei=ohVjUqKWCZP08ATBzoFY&ved=0CE4Q6AEwBDgK#v=onepage&q=
surdos&f=false. Acesso em: 15 set. 2013.
GOODLAN, Robert. The concept of environmental sustainability. Disponvel em:
<http://are.berkeley.edu/courses/ARE298/Readings/goodland.pdf>. Acesso em: 05
out. 2013.
GUILHERME, M. L. Sustentabilidade sob a tica. Disponvel
em:<http://books.google.com.br/books?id=OoutZXD5ZnkC&printsec=frontcover&dq=
sustentabilidade&hl=pt-
BR&sa=X&ei=JiBjUrmBO6Lc4AOnpICwDA&ved=0CEcQ6AEwADgK#v=onepage&q
=sustentabilidade&f=false> Acesso em: 05 out. 2013.
APPLE DEVELOPER. IOS 7 Design Resources. Learn how to transition your
apps. User Interface. Apple Developer. Disponvel em:
<https://developer.apple.com/library/ios/navigation/index.html> Acesso em: 27 jul.
2013.
LARMAN, C. Utilizando UML e padres: uma introduo a anlise e ao projeto
orientados a objetos e ao desenvolvimento iterativo. 3 Edio. ed. Porto Alegre:
Bookman , 2007.
MAC Developer Library. Buil.Test. Ship. Apple Developer. Disponvel em:
<https://developer.apple.com/library/mac/navigation/> Acesso em: 27 jul. 2013.
MARZULLO,F. Iphone na prtica: aprenda passo a passo a desenvolver
solues para IOS. So Paulo: Novatec Editora, 2012.
MORAES, W.W.N. Introduo ao Objective C. Dev Media. Disponvel em:
<http://www.devmedia.com.br/introducao-ao-objective-c/23061> Acesso em: 10 ago.
2013.
OURES, R. C. R. Sustentabilidade XXI. Disponvel em: <
http://books.google.com.br/books?id=3AuVirAJayMC&printsec=frontcover&dq=suste
ntabilidade&hl=pt-
BR&sa=X&ei=IPJaUsrTGYq8kQeJpoCYCQ&ved=0CEIQ6AEwAg#v=snippet&q=tran
sporte%20urbano&f=false> Acesso em: 22 set. 2013.
PARAN ONLINE. Diagnstico da surdez no Brasil ainda tardio. Atualizado em
19 janeiro 2013. Disponvel em: <http://www.parana-
online.com.br/editoria/cidades/news/79833/> Acesso em 18 set. 2013.
PAZ, Ronilson Jos da. As pessoas portadoras de deficincia no Brasil:
Incluso social. Disponvel em:
<http://books.google.com.br/books?id=DQLiziFAxW4C&pg=PA27&dq=acessibilidade
&hl=pt-BR&sa=X&ei=3ApjUtK-
F6_K4AOu_IHgCQ&ved=0CEEQ6AEwAw#v=onepage&q=acessibilidade&f=false >.
Acesso em: 14 set. 2013.
PMI. Um guia do conhecimento em gerenciamento de projetos: Guia PMBOK.
4 Edio. Pensilvnia: Project Management Institute, 2008.
DA COSTA, Raquel Veloso. Recomendaes de Acessibilidade da Ifla/unesco
para deficientes visuais: O caso da biblioteca pblica Juarez da Gama Batista.
Disponvel em:
 47

<http://books.google.com.br/books?id=9FMJULRqYUAC&printsec=frontcover&dq=ac
essibilidade+para+deficientes+visuais&hl=pt-
BR&sa=X&ei=jQ1jUtH7CYqM9AS4hoD4Dg&ved=0CEgQ6AEwAA#v=onepage&q=a
cessibilidade%20para%20deficientes%20visuais&f=false>. Acesso em: 14 set. 2013.
SILVA, Marlia da Piedade Marinho. A construo do sentido da escrita do
sujeito surdo. 1999. Dissertao (Mestrado em psicologia educacional)
Universidade Estadual de Campinas, Campinas, 1999. Disponvel em:
<http://www.unicamp.br>. Acesso em: 25 mai. 2005.
TAVARES, A.P. Modelagem arquitetural e viso 4+1. Circuito IGTO de palestras
corporativas. 2009. Disponvel em:
http://www.slideshare.net/adrianotavares/modelagem-arquitetural-e-viso-41-
presentation. Acesso em: 21 set. 2013.
URBS. Acessibilidade. Acessibilidade no transporte coletivo. Disponvel em:
<http://www.urbs.curitiba.pr.gov.br/acessibilidade> Acesso em: 12 ago. 2013.
URBS. Sustentabilidade. Comunidade. Disponvel em: <
http://www.urbs.curitiba.pr.gov.br/comunidade/sustentabilidade> Acesso em: 12 ago.
2013.
VASCONCELLOS, E. A. Transporte urbano nos pases em desenvolvimento:
reflexes e propostas. Disponvel em: http://books.google.com.br/books?id=rkb-
RA72qD8C&pg=PA207&dq=sustentabilidade+transporte+coletivo&hl=pt-
BR&sa=X&ei=PfJaUqHuMonokAelz4H4Ag&ved=0CGUQ6AEwBw#v=onepage&q=su
stentabilidade%20transporte%20coletivo&f=false. Acesso em 31 ago. 2013.
YOUTUBE. Tutoriais Apple. Disponvel em:
<http://www.youtube.com/user/TutoriaisApple> Acesso: 12 agosto 2013.
YOUTUBE. Vdeo explicativo de causas de surdez no Brasil. Disponvel em:
<http://www.youtube.com/watch?v=QQeEc_3rmME> Acesso: 12 ago. 2013.
FERNANDES, E.L. Surdez versus aprendizado da lngua portuguesa escrita.
Porsinal. Revista CES/JF, Juiz de Fora, 2008. Disponvel em: <
http://www.porsinal.pt/index.php?ps=artigos&idt=artc&cat=23&idart=180> Acesso
em: 03 ago. 2013.
 48

8. APNDICES

8.1 Apndice A Gerenciamento do projeto

8.1.1 Termo de abertura do projeto

8.1.1.1 Justificativa

O projeto Vamos de Buso focado aos deficientes visuais ou auditivos que

queiram/usam o transporte coletivo de Curitiba e regio Metropolitana. O aplicativo,
desenvolvido de maneira de auxiliar o embarque e desembarque da linha de nibus.
Nele, o usurio selecionar a linha que deseja, assim ser informado os pontos
presentes para embarque/desembarque desta linha. Aps selecionar o ponto de
desembarque que necessita, o usurio poder configurar o modo como receber o
aviso de que a linha estar prxima do ponto de embarque que esteja presente e
tambm o desembarque que gostaria de descer. As linhas de nibus que estaro
disponveis so as mesmas cobertas pela empresa de transporte coletivo
gerenciado pela URBS (Urbanizao de Curitiba S/A).

8.1.1.2 Objetivo

A inteno do sistema atender a todos os deficientes visuais ou auditivos,

acrescentando tambm qualquer usurio de transporte coletivo de Curitiba e regio
Metropolitana que queiram informaes sobre as linhas de nibus. Com a facilidade
que as informaes estaro disponveis, o usurio poder saber quando a linha
desejada estar prxima do ponto de embarque que esteja aguardando e tambm
 49

quando necessitar solicitar o desembarque. O objetivo dar maior autonomia a

qualquer usurio, especialmente para os deficientes visuais e auditivos.

8.1.1.3 Viso geral do Escopo

O projeto desenvolvido tem caractersticas especficas de produto, entre elas:

Plataforma IOS (Objective-C);
Auxlio do GPS presente no smartphone;
Escopo contemplado:
Selecionar a linha de nibus;
Selecionar o ponto de nibus da linha escolhida anteriormente;
Configurar o alerta para ser avisado quando a linha escolhida estar prxima do
local de embarque e tambm a proximidade do local de desembarque;
Configurar a distncia do nibus e consequentemente do ponto de desembarque.

8.1.1.4 Restries

Prazo para a entrega do PAP;

Recursos tcnicos e humanos limitados equipe do PAP;
Prazo para a apresentao da banca.

8.1.1.5 Premissas

Comprometimento do nvel estratgico da instituio;

Disponibilidade da equipe para o desenvolvimento do projeto, de acordo com os
perfis e cronogramas apresentados no projeto;
Participao focada de todos da equipe.
 50

Participao do orientador, comprometido a auxiliar e aconselhar as melhores

formas de desenvolver o projeto;
Aprovao de todos os integrantes da equipe no PAP.

8.1.1.6 Riscos iniciais

O projeto Vamos de Buso apresenta o risco baixo, devido falta de

interao do cliente Centro de Incluso da Universidade Positivo. Por ser um projeto
independente, possibilita maior liberdade para o desenvolvimento do sistema.

8.1.1.7 Designao do Gerente do projeto

Gerente do projeto: Laura Keity Shibukawa.

Autoridade:
Entrar em contato constante com a equipe, bem como buscar auxlio para o
desenvolvimento do projeto.
Responsabilidades:
Reportar mudanas e problemas ocorridos em tempo de desenvolvimento do projeto
ao Orientador;
Analisar a viabilidade do projeto em relao ao cliente e/ou usurio;
Desenvolver junto equipe a documentao necessria do PAP;
Planejar o desenvolvimento do projeto visando cumprir o prazo da entrega do
sistema;
Adotar medidas corretivas;
Manter a equipe em foco ao desenvolvimento e concluso do projeto.
 51

8.1.2 Documento de viso

VAMOS DE BUSO

Partes Interessadas

8.1.2.1 Organizao-cliente

O Centro de Incluso da Universidade Positivo, instituio de ensino Superior

responsvel pela formao acadmica dos autores deste projeto, qualificado como
pessoa jurdica de direito privado. Responsvel neste projeto pela UP Isabelle
Moletta, que desenvolve as atividades referentes aos Projetos de Aplicao
Profissional do Centro Tecnolgico da Universidade Positivo e Izabella Romanetto
do Centro de Incluso.
Adriano Chemin, membro da equipe do projeto Vamos de Buso.

Figura 4 Equipe de desenvolvimento

 52

Gerente de Projetos: Laura Keity Shibukawa.

Documentador: Luciane Laus Mosele.
Arquiteto de Software: Helton Yuji Yamamoto.
Analista de Sistemas: Matheus Rorato Baptista.
Desenvolvedor: Sergio Costa.
Tester: Adriano Chemin.

8.1.2.2 Objetivo

A finalidade deste documento coletar e definir as necessidades de alto-nvel

e caractersticas do projeto de software Vamos de Buso, focando nas
funcionalidades requeridas pelas partes interessadas e usurios bem em como
estes requisitos sero abordados no projeto de software.
A viso do projeto documenta o ambiente geral de processos a ser
desenvolvido para o sistema durante o projeto, fornecendo a todos os envolvidos
uma descrio compreensvel deste e de suas funcionalidades.
Este Documento de Viso apresenta apenas as necessidades e
funcionalidades do sistema que estaro sendo atendidas no projeto de software.

8.1.2.3 Cenrio atual

No Brasil, a deficincia visual est presente em torno de 35,7 milhes de

pessoas. Desse total, 528.624 pessoas so incapazes de enxergar (cegos) e
6.056.654 pessoas possuem grande dificuldade permanente de enxergar (baixa
viso ou viso subnormal). No censo, nota-se que do total da populao brasileira,
23,9% (45,6 milhes de pessoas) declararam ter algum tipo de deficincia. Entre as
deficincias declaradas, a mais comum foi a visual, atingindo 3,5% da populao.
Em seguida, ficaram problemas motores (2,3%), intelectuais (1,4%) e auditivos
(1,1%).
 53

Deficientes visuais por regio Total % populao local

Norte 574.823 3,6

Nordeste 2.192.455 4,1

Sudeste 2.058.587 3,1

Sul 866.086 3,2

Centro-oeste 433.357 3,2

Ainda falando em dados do Brasil, o censo do IBGE de 2010 aponta que 9,7
milhes de brasileiros possuem deficincia auditiva, o que representa cerca de 5,1%
da populao do pas.
Porm, de acordo com a Organizao Mundial da Sade, em 2011 cerca de
28 milhes de brasileiros possuem algum tipo de problema auditivo, demonstrando
um quadro grave, no qual 14,8% do total de 190 milhes de brasileiros possuem
problemas ligados audio.
O trabalho desenvolvido busca auxiliar o deficiente visual e auditivo a ter
locomoo mais independente, sem precisar de ajuda de terceiros. Buscando trazer
a eles, maior comodidade e quebrando as barreiras que eventualmente tem, devido
dificuldade de poder utilizar o transporte coletivo.

8.1.2.4 Descrio do projeto

Com a proposta de inovao, o projeto desenvolvido permite ao deficiente

visual ou auditivo a embarcar no nibus de linha de maneira independente,
aumentando a mobilidade dos mesmos. O aplicativo ir avisar ao deficiente visual ou
auditivo quando o nibus que deseja embarcar estiver prximo ao ponto de nibus
em que est aguardando. Aps embarcar no nibus, o dispositivo ir informar ao
mesmo, o momento em que ir descer do nibus.
 54

8.1.2.5 Envolvimento

8.1.2.5.1 Abrangncia

Este projeto abrange qualquer tipo de usurio interessado na utilizao do

aplicativo, contudo, focando no deficiente visual e auditivo. Abrange tambm a
Universidade Positivo, instituio de ensino responsvel pela formao acadmica e
a equipe de desenvolvimento, que adquirir experincia com o software.

8.1.2.5.2 Papel das partes interessadas

Tabela 1 - Centro de incluso da Universidade Positivo

Descrio Parte interessada no aplicativo
Papel no desenvolvimento Cliente
Insumos ao projeto Homologar o projeto
Representante Isabelle Moletta e Izabella Romanetto

Tabela 2 - Universidade Positivo

Descrio Instituio de Ensino
Papel no desenvolvimento Orientao
Insumos ao projeto Conhecimento

Representante Paulo Antnio Madalena

Tabela 3 - Deficientes visuais e auditivos

Descrio Usurio do aplicativo
Papel no desenvolvimento Usurio
Insumos ao projeto Avaliar a qualidade e aplicabilidade do sistema
Representante Adriano Chemin
 55

Tabela 4 - Analista de Teste

Descrio Fazer o teste da funcionalidade do aplicativo
Papel no Verificar se o sistema est funcionando de forma
desenvolvimento correta
Insumos ao projeto Checar eficincia e verificar os possveis erros,
reportando-os.
Representante Adriano Chemin

Tabela 5 - Desenvolvedor
Descrio Desenvolve o sistema
Papel no Avaliar a melhor forma de desenvolver o aplicativo
desenvolvimento
Insumos ao projeto Cria o sistema de forma eficiente
Representante Matheus Rorato Baptista, Sergio Costa

Tabela 6 - Documentador de sistemas

Descrio Desenvolve a documentao do projeto
Papel no Compilar as informaes, armazenando-as em
desenvolvimento forma de documento.
Insumos ao projeto Descrio das fases, atividades e cronograma.
Representante Laura Keity Shibukawa, Luciane Laus Mosele e
Helton Yuji Yamamoto

Tabela 7 - Analista de requisitos

Descrio Analisar os requisitos do projeto
Papel no desenvolvimento Levantar os requisitos do projeto
Insumos ao projeto Descrever os requisitos.
Representante Laura Keity Shibukawa

Tabela 8 - Lder do grupo

Descrio Gerencia a equipe
Papel no Gerenciar a equipe e o desenvolvimento do projeto
desenvolvimento seguindo o cronograma.
 56

Insumos ao projeto Concluir o projeto de acordo com os requisitos

levantados e prazos estabelecidos.
Representante Laura Keity Shibukawa

8.1.2.5.3 Papel dos atores

Tabela 9 - Usurio
Descrio Parte interessada na utilizao do aplicativo
Papel Manusear o aplicativo
Insumos ao sistema Selecionar a linha de nibus e o ponto de embarque
e desembarque
Representante Usurios do transporte coletivo em Curitiba e regio
metropolitana.

Tabela 10 - Celular
Descrio Parte necessria para o desenvolvimento do
aplicativo
Papel Localizar as linhas e pontos de nibus
Insumos ao sistema Interagir com o sistema
Representante Celular

8.1.2.6 Necessidades e funcionalidades

Tabela 11 - Mdulo administrativo

Cadastro de nibus (linha) Prioridade
Cadastro de rotas para cada linha
Cadastro de pontos/estaes tubo
Cadastro das linhas de nibus, disponveis para o transporte Crtico
 57

coletivo.
Cadastro das rotas de nibus, de acordo com a regulamentao
da URBS.
Cadastro de pontos/estaes tubo, tambm regulamentados pela
URBS.
Id Func. Descrio das Funcionalidades/Atores Envolvidos
F1.1 Cadastrar as linhas de nibus
Ator: Programador
F1.2 Cadastrar as rotas de todos os nibus
Ator: Programador
F1.3 Cadastrar os pontos/estaes tubo de cada linha de nibus
Ator: Programador
F1.4 Sincronizar o GPS
Ator: Programador

8.1.2.6.1 Mdulo pesquisa

Tabela 12 - Seleo
Selecionar a linha de embarque Prioridade
Selecionar o ponto/estao tubo de desembarque
Embarque e desembarque do nibus Crtico
Id Func. Descrio das Funcionalidades/Atores Envolvidos
F2.1 Selecionar a linha de nibus desejada
Ator: Usurio
F2.2 Selecionar o ponto de nibus desejado
Ator: Usurio

Tabela 13- Interao com o GPS

Interao com o GPS Prioridade
Interao sistema e GPS Crtico
Id Func. Descrio das Funcionalidades/Atores Envolvidos
F3.1 Localizar o nibus selecionado
Ator: GPS

F3.2 Localizar o usurio

 58

Ator: GPS

F3.3 Emitir um sinal quando o nibus da linha selecionada estiver prximo

Ator: GPS / Sistema Integrado
ao ponto
F3.4 Localizar o ponto de nibus selecionado
Ator: GPS
F3.5 Emitir um sinal quando o ponto de nibus selecionado estiver prximo
Ator: GPS / Sistema Integrado

8.1.2.7 Restries / Premissas

8.1.2.7.1 Restries

A linha de nibus precisa ser selecionada previamente;

Usurio necessariamente precisa saber o ponto de embarque e desembarque;
O dispositivo mvel deve possuir conexo de Internet;
Usurio deve possuir dispositivo mvel com verso do IOS 6 ou mais atual;
Cumprimento de entrega nos prazos pr-estabelecidos pela Universidade Positivo;
Por ter um delay de, no mnio 2 minutos do GPS proposto pela URBS, foi utilizado
um aplicativo que faz o mesmo trabalho que o GPS buscado pelo banco de dados
da URBS.

8.1.2.7.2 Premissas

O nibus estar sempre com o GPS funcionando;

As rotas de nibus no sero alteradas;
O usurio ter acesso Internet.
 59

8.1.2.8 Expectativa de entrega do produto

Esperamos que o produto auxilie os usurios de maneira que os mesmos

passem a ter maior mobilidade e autonomia.

8.1.3 Especificao das regras de negcio

8.1.3.1 Objetivo

O objetivo da Especificao de Regras de Negcio documentar as regras

aplicveis ao negcio. Essas regras, em geral, constituem declaraes de polticas
ou condies que devem ser satisfeitas pelo processamento da aplicao.

8.1.3.2 Selecionar linha de nibus

As linhas de nibus sero selecionadas dentro das opes j inseridas no

sistema.
- Lista Linha de nibus;
- Cdigo da linha;
- Nome da linha.

8.1.3.3 Selecionar ponto de desembarque da linha escolhida anteriormente

O ponto de desembarque ser selecionado dentro das opes j inseridas no

sistema.
- Lista ponto de desembarque
 60

- Cdigo do ponto / Nome da estao tubo

- Sentido da linha

8.1.3.4 Configurar alerta do sistema

O usurio ir selecionar a forma que ser o alerta do embarque e

desembarque.
Possui os campos:
- Alerta sonoro;
- Distncia para o aviso.

8.2 Apndice B Plano de gerenciamento do escopo

8.2.1 Descrio detalhada do produto

O software a ser desenvolvido tem caractersticas especficas do produto,

entre elas:
Aplicativo exclusivo para sistemas mobile (IOS);
Plataforma Objective-C;
Xcode5;
Aplicativo rastreador para localizar nibus e aplicativo atravs do GPS;
Acesso web service do banco de dados da URBS.
 61

8.2.2 Escopo contemplado do produto

O produto estar disponvel para auxiliar o deficiente visual ou auditivo a

utilizar o transporte urbano de Curitiba e regio Metropolitana. Desse modo, o
usurio no precisar solicitar o ajuda de terceiros para embarcar na linha de nibus
desejada, bem como desembarcar em seu destino. Com isso, o usurio saber
exatamente qual linha de nibus estar embarcando, bem como onde dever avisar
que necessitar desembarcar, no ocorrendo erros de trajeto devido a ter
independncia em sua locomoo.
Para isso o usurio selecionar a linha de embarque que esteja aguardando,
estando em um dos pontos de nibus em seu caminho. O usurio precisa estar em
seu ponto de embarque correto, para no haver falhas de clculos de rotas dos
nibus. Aps selecionar a linha desejada, o usurio selecionar o ponto que tambm
faz parte da rota, para saber onde desembarcar.
Poder tambm escolher se gostaria de ser avisado atravs de um alerta
sonoro ou simplesmente deixar desligado essa opo, recebendo um aviso atravs
da vibrao, quando o nibus estiver prximo e o ponto desta linha que deseja
desembarcar.
Alm disso, poder configurar a distncia, tanto da linha que esteja se
aproximando, quanto do ponto de desembarque. Assim receber o aviso de acordo
com sua configurao anterior.

8.2.3 Escopo no contemplado do produto

No ser cedido o cdigo-fonte do aplicativo ao cliente;

No sero cedidos aparelhos compatveis com a plataforma IOS ao cliente;
No ser cedido manual ou dado treinamento ao cliente;
No ser prestada assistncia ao cliente sobre a utilizao do aparelho;
Aps a entrega do aplicativo, cessar o vnculo entre os integrantes do projeto com
o cliente, no sendo prestada qualquer assistncia de suporte/ajuda ao cliente;
Resposta automtica do GPS sobre a informao do local de nibus em tempo real
haver delay;
 62

Informaes sobre a rota das linhas de nibus;

Outra plataforma disponibilizada que no seja IOS;
No so responsabilidades dos integrantes do projeto:
Disponibilidade de conexo com a Web;
Disponibilidade do aplicativo;
Atualizaes e manutenes preventivas e/ou recorrentes de correo do aplicativo.

8.2.4 EAP/WBS

1 Projeto Vamos de Buso

1.2 Gerenciamento do Projeto
1.2.1 Requisitos
1.2.1.1 O usurio
1.2.1.2 Definir o sistema para usurios de necessidades especiais
1.2.1.3 Termo de Abertura do Projeto
1.2.2 Plano do Projeto
1.2.2.1 Plano de Gerenciamento do Escopo
1.2.2.2 EAP
1.2.2.3 Dicionrio da EAP
1.2.2.4 Cronograma
1.2.3 Anlise dos Requisitos
1.2.3.1 Caso de Uso Selecionar linha de nibus
1.2.3.2 Caso de Uso selecionar ponto de desembarque da linha desejada
1.2.3.3 Caso de Uso configurar alerta
1.2.3.4 Criao de Prottipos de tela
1.2.4 Gerenciamento de Custo do Projeto
1.2.5 Plano de Gerenciamento do Tempo
1.2.6 Plano de Gerenciamento da Qualidade
1.2.7 Plano de Gerenciamento das Comunicaes
1.2.8 Plano de Gerenciamento das Aquisies
1.2.9 Especificaes das Regras de Negcio
 63

1.2.10 Arquitetura
1.2.10.1 Objetivo
1.2.10.2 Diagrama de Casos de Uso
1.2.10.3 Diagrama de Classe
1.2.10.4 Especificao dos Requisitos do Projeto
1.2.10.5 Viso Lgica do Aplicativo
1.2.10.6 Viso Fsica do Aplicativo
1.2.10.7 Tecnologias Utilizadas
1.2.10.8 Elementos do Sistema
1.2.10.9 Relatrio de desempenho do sistema
1.2.10.10 Diagrama de Sequncia
1.2.10.11 Diagrama de Componentes
1.2.11 Testes
1.2.11.1 Definir Testes
1.2.11.2 Casos de testes
1.2.12 Codificao
1.2.12.1 Ambientao Com o Projeto Codificao
1.2.12.2 Criar Ambiente
1.2.13 Elaborao do PAP
1.2.13.1 Fundamentao Terica
1.2.13.2 Formatao do Trabalho
1.2.13.3 Testes Integrados
1.2.13.4 Testes Assistidos (Banca)

8.2.5 Dicionrio EAP

Tabela 14 - Dicionrio EAP / WBS

ID Pacote de Trabalho Descrio Critrio de

Aceitao
 64

1.2 Gerenciamento do Projeto Informaes e Aprovao

conhecimentos do
necessrios para o Orientador.
gerenciamento do
Projeto.

1.2.1 Requisitos Documentos que Aceite do

constam os requisitos Cliente.
para desenvolver o
Projeto visando o
cliente.

1.2.1.1 O Usurio Informaes sobre o Aceite do

usurio em potencial. cliente.

1.2.1.2 Definir o sistema para Documento que traz Aceite do

usurios de necessidades informaes sobre os cliente.
especiais usurios em potencial.

1.2.1.3 Termo de Abertura do Documento que Aceite do

Projeto contempla escopo cliente.
macro, restries e
premissas do projeto.

1.2.2 Plano do Projeto Documentos que Aprovao

contemplam o escopo do
e informaes sobre Orientador.
planejamento do
projeto.

1.2.2.1 Plano de Gerenciamento Descreve em detalhes Aceite do

do Escopo os pacotes de trabalho cliente.
que devem ser
entregues.

1.2.2.2 EAP Documento que consta Aprovao

em detalhes a do
 65

estrutura do projeto. Orientador.

1.2.2.3 Dicionrio da EAP Definio sobre cada Aprovao

camada da EAP. do
Orientador.

1.2.4 Gerenciamento de Custo Documento que Aprovao

do Projeto descrevem quais do
foram os custos para Orientador.
desenvolver o projeto.

1.2.5 Plano de Gerenciamento Documento que Aprovao

do Tempo descreve o tempo do
gasto para Orientador.
desenvolver o projeto.

1.2.6 Plano de Gerenciamento Documento que Aprovao

da Qualidade descreve a qualidade do
do projeto, aprovaes Orientador.
e cincias de cada
camada do projeto.

1.2.7 Plano de Gerenciamento Informaes sobre os Aprovao

das Comunicaes Stakeholders do do
projeto. Orientador.

1.2.8 Plano de Gerenciamento

das Aquisies

1.2.9 Especificaes das Regras Documento que Aprovao

de Negcio especifica o do
funcionamento do Orientador.
sistema.

1.2.10 Arquitetura Definio dos Aprovao

componentes do do
software Orientador.
 66

1.2.11 Testes Definio da estratgia Aceite do

da implementao dos Cliente.
testes.

1.2.12 Codificao Desenvolvimento e Aceite do

testes dos casos de Cliente.
uso.

1.2.13 Elaborao do PAP Documentos Aprovao

necessrios para a do orientador
defesa do projeto. e da banca.

8.3 Apndice C Plano de gerenciamento do tempo

Tabela 15 - Lista de Atividades

Id EAP Descrio Atividades
1.2.3.1 Entrega caso de uso selecionar1. Listar as linhas de nibus na tela.
a linha de nibus
1.2.3.2 Entrega caso de uso selecionar1. Listar na tela os pontos de nibus da
o ponto de desembarque da linha linha anteriormente selecionada.
selecionada
1.2.3.3 Entrega caso de uso configurar 1. Criar a tela de configurao de alerta
alerta do aplicativo.

Tabela 16 - Lista de atributos das atividades

Id EAP Descrio Atividade Restrio Premissas Responsvel
Atividade Predecessora

1.2.3.1 Selecionar a n/c Conexo Conexo Matheus

linha de nibus 3G 3G Rorato
Baptista
GPS GPS ativo
ativo no
 67

nibus no nibus

1.2.3.2 Selecionar o1.1.3.1. Conexo Conexo Matheus

ponto de 3G 3G Rorato
Selecionar a
desembarque Baptista
linha de
da linha
nibus
selecionada

1.2.3.3 Configurar n/c n/c n/c Matheus

alerta Rorato
Baptista

Tabela 17 - Lista de Marcos

Id EAP Descrio Obrigatrio Origem

1.2.1.3 Termo de Abertura do Projeto Sim Previsto em acordo

1.2.3 Anlise dos requisitos Sim Previsto em acordo

1.2.11 Testes Sim Previsto em acordo

8.3.1 Cronograma

Cronograma de acordo com a realidade de cada desenvolvedor do projeto

Vamos De Buso, ao quais as horas foram includas somando as mesmas de toda
a equipe do projeto.

Tabela 18 - Recursos das Atividades

Nome da Tarefa Durao

1.2 Gerenciamento do Projeto 496 horas

 68

1.2.1 Requisitos 135 horas

1.2.1.1 O usurio 16 horas

1.2.1.2 Definir o sistema para usurios de necessidades especiais 4 horas

1.2.1.3 Termo de Abertura do Projeto 16 horas

1.2.2 Plano do Projeto 28 horas

1.2.2.1 Plano de Gerenciamento do Escopo 9 horas

1.2.2.2 EAP 9 horas

1.2.2.3 Dicionrio da EAP 3 horas

1.2.2.4 Cronograma 8 horas

1.2.3 Anlise dos Requisitos 12 horas

1.2.3.1 Caso de Uso selecionar a linha de nibus 2 horas

1.2.3.2 Caso de Uso selecionar o ponto de desembarque da linha 4 horas

desejada

1.2.3.3 Caso de Uso configurar alerta 2 horas

1.2.3.4 Criao de Prottipos de tela 2 horas

1.2.4 Gerenciamento de Custo do Projeto 2 horas

1.2.5 Plano de Gerenciamento do Tempo 2 horas

1.2.6 Plano de Gerenciamento da Qualidade 2 horas

1.2.7 Plano de Gerenciamento das Comunicaes 2 horas

1.2.8 Plano de Gerenciamento das Aquisies 2 horas

1.2.9 Especificaes das Regras de Negcio 8 horas

1.2.10 Arquitetura 64 horas

 69

1.2.10.1 Objetivo 2 horas

1.2.10.2 Diagrama de Casos de Uso 2 horas

1.2.10.3 Diagrama de Classe 2 horas

1.2.10.4 Especificao dos Requisitos do Projeto 2 horas

1.2.10.5 Viso Lgica do Aplicativo 2 horas

1.2.10.6 Viso Fsica do Aplicativo 2 horas

1.2.10.7 Tecnologias Utilizadas 2 horas

1.2.10.8 Elementos do Sistema 2 horas

1.2.10.9 Relatrio de desempenho do sistema 2 horas

1.2.10.10Diagrama de Sequncia 2 horas

1.2.10.11 Diagrama de Componentes 2 horas

1.2.11 Testes 60 horas

1.2.11.1 Definir Testes 2 horas

1.2.11.2 Casos de testes alerta embarque 28 horas

1.2.11.3 Casos de testes alerta desembarque 28 horas

1.2.12 Codificao 45 horas

1.2.12.1 Ambientao Com o Projeto Codificao 35 horas

1.2.12.2 Criar Ambiente 2 horas

1.2.13 Elaborao do PAP 124 horas

1.2.13.1 Fundamentao Terica 100 horas

1.2.13.2 Formatao do Trabalho 16 horas

1.2.13.3 Testes Integrados 2 horas

 70

1.2.13.4 Testes Assistidos (Banca) 2 horas

Figura 5 Estrutura analtica dos recursos

8.3.2 Durao das atividades

As duraes das atividades sero estimadas atravs dos casos de uso

respeitando as datas definidas no cronograma do PAP.
 71

8.4 Apndice D Plano de gerenciamento da qualidade

Tabela 19 Requisitos e garantia da qualidade

Item
Forma de Periodi
da Indicadores Definio Meta Responsvel
Medio cidade
EAP
No incio
Verificar
do
se o
desenvo
cliente Aprovao ou
Anlis Status de lvimento
est de no do
e dos aprovao Laura K do
acordo cliente em 100%
Requis do cliente Shibukawa. projeto,
com os relao aos
itos Adriano. conform
requisitos requisitos.
e
apresenta
cronogra
dos.
ma.
Verificar
se a
document A cada
Status de
ao est desenvo
aprovao Aprovao ou
Elabor de acordo lvimento
do no do
ao com a de
orientador. cliente em 100% Equipe toda.
do norma da acordo
relao
PAP ABNT e com o
plataforma.
tambm cronogra
pelas ma.
normas do
CTUP.
Definir Status de Verificar Aprovao ou Matheus
Arquit aprovao se o no do 100% Rorato nica
etura do cliente cliente cliente em Baptista
 72

Adriano. est de relao

acordo plataforma.
com a
plataforma
solicitada.
Verificar
se a
arquitetur Realizar
Status de a testes para
Matheus
implementa planejada aferir a
100% Rorato nica
o da est de adequao
Baptista
arquitetura. acordo da
com os arquitetura.
casos de
uso.
Verificar a
quantidad A cada
e total de finaliza
erros o do
Relao
encontrad pacote
entre erros
os durante de
encontrados % = Erros / Matheus
Definir os testes entrega
pelo casos de 50% Rorato
Testes e dividir do
nmero de teste. Baptista
pelo cdigo,
casos de
nmero estipula
teste
total de do no
casos de cronogra
testes ma.
criados.
 73

8.5 Apndice E Plano de gerenciamento da comunicao

Tabela 20 - Identificao das partes interessadas e estratgia de comunicao

Stakeholde Contato Identificao da Anlise dos Estratgia
r Categoria constituintes
Orientador pauloam@up. Entrega de Poder: potencial Recebimento
Paulo A com.br resultados, impacto da da
Madalena reviso e avaliao do documenta
auditoria. projeto; o do projeto,
Influncia: anlise dos
positiva, mesmos,
motivador da orientando
equipe; sempre da
Envolvimento: melhor forma
apoio; os
Prioridade: prazo procedimento
e qualidade do s.
produto.
Equipe adriano.chemi Desenvolvimento Poder: alto Troca de
Adriano n@insitu.com. do projeto, tanto a impacto no experincias
Chemin, br documentao desenvolvimento e dificuldades
Helton Y heltonyy@hot quanto o sistema. do projeto; enfrentadas
Yamamoto mail.com Influncia: pela equipe.
, laurakeity@ho positiva;
Laura K tmail.com Envolvimento:
Shibukawa lumosele@hot comprometimento
, mail.com o
Luciane L matheusrorato desenvolvimento
Mosele, @gmail.com do projeto;
Matheus R kkosta@ibest. Prioridade: prazo
Baptista, com.br e qualidade do
Sergio produto.
 74

Costa
Coordenad kristian.capeli Auditoria, Poder: potencial Recebimento
or ne@up.com.br homologao. impacto da do projeto
Kristian avaliao do final.
Capeline projeto;
Influncia: no
relevante;

Cliente Isabelle.molett Homologao. Poder: alto Aprovao do

a@up.com.br impacto da produto final.
Centro de adriano.chemi avaliao e
Incluso n@insitu.com. homologao do
da br produto;
Universida Influncia: pouco
de relevante;
Positivo, Envolvimento:
Adriano pouco relevante;
Chemin Prioridade:
qualidade do
produto.

Tabela 21 - Plano de comunicao

Stakeholders Propsito das Ferramentas / Responsvel Quando
mensagens / Aes Mdias de
da Comunicao comunicao

Orientador Informaes, Formalmente Laura Quase

orientaes e por e-mails e todas as
questionamentos reunies, semanas e
sobre o cronograma informalmente sempre que
do projeto por telefone e necessrio.
whatsapp.

Equipe Desenvolvimento do Formalmente Orientador Sempre que

 75

projeto e dificuldades por e-mails e necessrio.

enfrentadas durante reunies,
o projeto. informalmente
por telefone.

Coordenador Protocolar o projeto Sempre Equipe Sempre que

e solicitaes. formalmente, solicitado
Apresentar e atravs do entrega.
entregar as partes Portal
solicitadas. acadmico,
protocolo,
apresentaes.

Cliente Apresentar ao final Formalmente Laura Ao final do

do projeto. por e-mail. projeto.

8.6 Apndice F Especificao dos requisitos do projeto

Legendas

1. Prioridade
a) P Pouca importncia
b) ME Mdia para baixa importncia
c) MU Muita importncia
d) E Essencial importncia
2. Fonte de Idenficao de Requisitos
a) C Cliente
b) A Analista

Tabela 22 - Caracterstica de Qualidade - Funcionalidades

Nro. Descrio do Requisito Prioridade Fonte
F-1 Utilizao do Web Service da URBS. E A
F-2 Garantir que o acesso seja interrupto. E A
 76

F-3 Capacidade de apresentar os dados de forma E A

automtica, buscando os dados da URBS.
F-4 Acesso rede GPS. E A

Tabela 23 - Caracterstica de Qualidade Usabilidade

Nro. Descrio do Requisito Prioridade Fonte

U-1 Interface amigvel voltado aos deficientes visuais. ME C

U-2 Fcil aprendizado ME C

Tabela 24 - Caracterstica de Qualidade Confiabilidade

Nro. Descrio Prioridade Fonte

C-1 Cuidados no desenvolvimento a fim de evitar E A

problemas.

C-2 Teste frequentes para evitar falhas. MU A

C-3 Tempo de resposta. MU A

C-4 Garantir que os dados buscados sejam originrios E A

da URBS.

Tabela 25 - Caracterstica de Qualidade Eficincia

Nro. Descrio do Requisito Prioridade Fonte

E-1 Compatibilidade com verses de smartphones. ME A

Tabela 26 - Caracterstica de Qualidade Portabilidade

Nro. Descrio do Requisito Prioridade Fonte

P-1 Organizao do sistema em camadas. ME A

Tabela 27 - Caractersticas de Qualidade Manutenibilidade

Nro. Descrio do Requisito Prioridade Fonte
 77

M-1 Estimar custo e tempo para implantao. ME A

M-2 Atualizar a documentao. ME A

M-3 Desenvolvimento do projeto. MU A

M-4 Padronizao de cdigo. ME A

8.7 Apndice G Modelagem

8.7.1 Documento de caso de uso

8.7.1.1 Objetivo do Caso de Uso

O objetivo do caso de uso deste documento descrever uma sequncia de

eventos do usurio que utiliza o sistema Vamos de Buso, informando os requisitos
funcionais do sistema, interagindo o usurio final com o aplicativo.

8.7.1.2 Atores

Tabela 28 - Atores

Ator Primrio Secundrio

Usurio (deficiente visual ou auditivo) X

GPS X
 78

8.7.1.3 Pr-condies

Usurio precisa ter sinal de internet;

Sistema operacional compatvel com IOS.

8.7.1.4 Fluxo principal

P1 - Selecionar a linha de nibus

Sistema apresenta a lista de linhas de nibus conforme regra de

apresentao de campos de linha de nibus.
Cdigo da linha e nome da linha.

P2. Selecionar o ponto de desembarque

Usurio seleciona o ponto de desembarque da linha previamente selecionada.

Cdigo do ponto e/ou nome da estao tubo. Sentido da linha.

P3. Receber sinal de alerta para embarque

Usurio recebe sinal de alerta avisando que o nibus selecionado est

prximo. Vibra ou toca.

P4. Receber o sinal de alerta para o desembarque

Usurio recebe sinal de alerta avisando que o ponto de desembarque

 79

selecionado est prximo. Vibra ou toca.

P5. Configurar distncia

Usurio configura a distncia que gostaria do nibus com a posio que

esteja e a mesma configurao ficar para a distncia que o nibus que embarcou
esteja prximo ao desembarque selecionado.

8.7.1.5 Fluxos alternativos

No se aplica.

8.7.1.6 Fluxos de exceo

E1 Queda na conexo de internet

Este fluxo pode ocorrer quando h queda de sinal de internet. Pode ocorrer a
qualquer momento.

1. Envia mensagem Falha de sinal

E2 Queda no sistema da URBS

Este fluxo pode ocorrer quando h queda de sinal de internet. Pode ocorrer a
qualquer momento.

1. Envia mensagem Falha de sinal

 80

8.7.1.7 Pontos de Extenso/Incluso

Necessrio utilizar o aplicativo rastreador de GPS.

8.7.1.8 Critrios de aceite

O usurio, conseguindo embarcar no nibus selecionado e desembarcar no

ponto de nibus selecionado conclui o caso de uso.

8.7.2 Diagrama de Caso de Uso

O Diagrama de Caso de Uso representa o comportamento do sistema de

maneira grfica atravs do relacionamento entre atores e casos de uso.

Figura 6 Diagrama de Caso de Uso.

 81

8.7.3 Prottipos de tela

FIGURA 7 Prottipos de tela.

8.7.4 Diagrama de Classe

Atravs do Diagrama de Classe possvel visualizar a interao das classes

e os relacionamentos estticos existentes.
Figura 8 Diagrama de Classe.
 82

8.7.5 Diagrama de sequncia

O Diagrama abaixo nos mostra os eventos de entradas e sadas relacionados

ao sistema e como o ator interage.

Figura 9 Diagrama de Sequncia.

8.7.6 Diagrama de Componentes

O Diagrama de Componentes captura a estrutura fsica da implementao,

enfatizando as interfaces e mostrando as dependncias de cada componente.
 83

Figura 10 - Diagrama de Componentes.

8.7.7 Diagrama da implantao

Atravs dele podemos visualizar a atribuio de artefatos concretos do

software e os servios de processamentos.

Figura 11 Diagrama da Implantao.

 84

8.8 Apndice H Documento de arquitetura

8.8.1 Objetivo
O objetivo deste documento oferecer uma viso geral de arquitetura de
software, evidenciando as diversas vises arquiteturais que possam representar os
diferentes aspectos mais importantes do sistema, demonstrando as decises mais
significativas que foram definidas na construo do sistema.

8.8.2 Escopo

Com a finalidade demonstrar a arquitetura contida neste projeto sero

abordados os requisitos funcionais, capturados no modelo de caso de uso, e
tambm os requisitos no funcionais, derivado de especificaes suplementares
tendo em vista a importncia e a influencias dos mesmos dentro do projeto.

8.8.3 Representao da arquitetura

A arquitetura do projeto dividida em trs camadas: Model, Proxy

(Comunicao com o Webservice) e View Controller.
Na camada Model configurado o nome dos campos do banco de dados. A
camada responsvel pela comunicao com o webservice da URBS, onde retornam
as linhas, pontos e posio do nibus a camada Proxy.
A View Controller a camada responsvel para controlar a tela, onde o
usurio interage.
 85

Figura 12 Representao da Arquitetura

8.8.4 Princpios e restries da arquitetura

Arquitetura incorporada no projeto visa atender s seguintes caractersticas:

Manuteno: A arquitetura tem como objetivo tornar a manuteno do sistema

mais rpido e de forma mais prtica.
Extenso: A arquitetura do projeto visa possibilidade de uma futura
extenso do software.
Modularizao: Permite que partes do sistema possam ser trocadas sem
comprometer o projeto evitando grandes mudanas por limitao de componentes.
Restries de Memria: Existe um cuidado devido restrio e uso memria
por se tratar de um aplicativo para smartphones.
 86

8.8.5 Viso lgica do aplicativo

Figura 13 Viso lgica da arquitetura do sistema.

8.8.6 Viso fsica do aplicativo

Figura 14 Viso fsica da arquitetura do sistema.

 87

8.8.7 Tecnologias utilizadas

Os mecanismos utilizados essenciais so o webservice da URBS para

aplicativo poder oferecer os pontos de nibus atualizados.
A linguagem utilizada no desenvolvimento do projeto a Objective-C, dentro
do ambiente de desenvolvimento XCode 5, estas implementaes foram utilizadas
devido ao fato de oferecerem todos os recursos necessrios para construo de
aplicativos de smartphones da linha do Iphone da Apple.
Os requisitos do sistema necessrios para poder executar o ambiente de
desenvolvimento prprio para o sistema operacional Iphone, o Mac OS X, so:
Um computador da arquitetura nativa da famlia Objective-C da Apple, no
caso de desenvolvimento deste projeto ser utilizado o notebook MacBook Air, com
processador Intel 1,7 Ghz Intel Core i5 e 4GB de memria RAM 1333 MHz com o
sistema operacional OSX 10.8.5 (12F45), tecnologia extremamente eficiente para
execuo da ferramenta XCode 5.
O Banco de dados, por ser uma aplicao que opera em conjunto com o
banco de dados da URBS, no h necessidade da implantao do banco de dados,
pois as linhas e cadastros de nibus so de responsabilidade e gentilmente
concedidas para o acesso com web service via internet pela empresa de transporte
pblico.

8.8.8 Elementos do Sistema

Os elementos do aplicativo no projeto so implementados em classes

construdas em XCode 5, nas quais so representadas pelas entidades funcionais
do sistema, e distribudas em pacotes para melhorar a organizao e manuteno
do sistema.
 88

8.8.9 Performance

Embora a tecnologia atual caminhe para aumento da potncia de

processadores para smartphones ainda temos uma restrio limitada para
performance de aplicativos.
O aplicativo depende da conexo com a internet seja ela: Wi-Fi, 3G e 4G,
lembrando que sem conexo com a internet no h como usar o aplicativo.
A performance tambm depende das condies do smartphone usado, de
memria e espao livre para o aplicativo.
Outra questo que pode comprometer o uso do aplicativo a manuteno e
disposio dos servidores da URBS de onde so armazenadas as informaes
necessrias para o uso do aplicativo.
Foram realizados testes quanto ao uso do aplicativo no iphone, e com sinal de
internet adequado as respostas foram geradas quase em tempo de execuo, no
havendo necessidade quanto a melhoria na eficcia no aplicativo.

8.8.10 Telas do sistema

Neste tpico sero abordadas as telas desenvolvidas do sistema, com suas

devidas funcionalidades.
A figura 15 Representa a tela inicial, na qual o usurio inicia o uso do sistema,
tocando no cone, com um pequeno desenho do nibus, lembrando que como o
objetivo principal do aplicativo e atender os deficientes visuais, na verdade o prprio
smartphone j possui uma funo nativa na qual so narradas todas as funes que
esto na tela.
 89

Figura 15 Tela inicial do sistema operacional IOS.

A figura 16 representa a primeira tela do sistema em uso, na qual o usurio

faz a escolha da linha do nibus que ser usado de acordo com o destino
pretendido, lembrando que nesta tela de opo o usurio j est devidamente
localizado via GPS, e as linhas que esto na tela so todas disponveis pela URBS.
 90

Figura 16 - Primeira tela do sistema Vamos de Buso.

Na figura 17 representa a tela de escolha do ponto de nibus da linha

previamente selecionada pelo usurio, disponvel para que seja escolhido o ponto de
desembarque.
 91

Figura 17 Segunda tela do sistema Vamos de Buso.

A figura 18 representa a tela onde o usurio escolhe como ser notificado

antecipadamente do destino de desembarque.
Dentre as opes esto disponveis:
A escolha do aparelho celular tocar como se fosse uma ligao, juntamente
com uma vibrao. O toque sonoro emitido um diferencial para que o usurio no
confunda com uma ligao.
A escolha da distncia do nibus ao aproximar, bem como o ponto de
desembarque poder ser feito pelo prprio usurio. Para que ele receba a
notificao.
 92

Figura 18 Tela de configurao do alerta.

8.8.11 Partes do cdigo-fonte

8.8.11.1 Linhas de nibus.

// LinhasViewController.m
VamosDeBuso
//
// Created by Matheus Rorato Baptista on 29/09/13.
// Copyright (c) 2013 Matheus Rorato Baptista. All rights reserved.
//
 93

#import "LinhasViewController.h"
#import "Proxy.h"
#import "Linha.h"
#import "Onibus.h"
#import "PontosViewController.h"
#import "AjustesViewController.h"

@interface LinhasViewController ()

@end

@implementation LinhasViewController

- (id)initWithStyle:(UITableViewStyle)style
{
self = [super initWithStyle:style];
if (self) {
// Custom initialization
}
return self;
}

- (void)viewDidLoad
{
[super viewDidLoad];
linhas = [[Proxy alloc] getLinhas];

// Uncomment the following line to preserve selection between presentations.

// self.clearsSelectionOnViewWillAppear = NO;
// Uncomment the following line to display an Edit button in the navigation bar for
this view controller.
// self.navigationItem.rightBarButtonItem = self.editButtonItem;
}
 94

- (void)didReceiveMemoryWarning
{
[super didReceiveMemoryWarning];
// Dispose of any resources that can be recreated.
}

#pragma mark - Table view data source

- (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView
{
// Return the number of sections.
return 1;
}

- (NSInteger)tableView:(UITableView *)tableView
numberOfRowsInSection:(NSInteger)section
{
// Return the number of rows in the section.
return [linhas count];
}

- (UITableViewCell *)tableView:(UITableView *)tableView

cellForRowAtIndexPath:(NSIndexPath *)indexPath
{
static NSString *CellIdentifier = @"CellLinhas";
UITableViewCell *cell = [tableView
dequeueReusableCellWithIdentifier:CellIdentifier forIndexPath:indexPath];

// Configure the cell...

NSDictionary *linhasDIC = [linhas objectAtIndex:indexPath.row];

cell.textLabel.text = [linhasDIC objectForKey:LINHA_NOME];

 95

cell.detailTextLabel.text = [linhasDIC objectForKey:LINHA_CODIGO];

return cell;
}

/*
// Override to support conditional editing of the table view.
- (BOOL)tableView:(UITableView *)tableView
canEditRowAtIndexPath:(NSIndexPath *)indexPath
{
// Return NO if you do not want the specified item to be editable.
return YES;
}
*/

/*
// Override to support editing the table view.
- (void)tableView:(UITableView *)tableView
commitEditingStyle:(UITableViewCellEditingStyle)editingStyle
forRowAtIndexPath:(NSIndexPath *)indexPath
{
if (editingStyle == UITableViewCellEditingStyleDelete) {
// Delete the row from the data source
[tableView deleteRowsAtIndexPaths:@[indexPath]
withRowAnimation:UITableViewRowAnimationFade];
}
else if (editingStyle == UITableViewCellEditingStyleInsert) {
// Create a new instance of the appropriate class, insert it into the array, and add a
new row to the table view
}
}
*/

/*
 96

// Override to support rearranging the table view.

- (void)tableView:(UITableView *)tableView moveRowAtIndexPath:(NSIndexPath
*)fromIndexPath toIndexPath:(NSIndexPath *)toIndexPath
{
}
*/

/*
// Override to support conditional rearranging of the table view.
- (BOOL)tableView:(UITableView *)tableView
canMoveRowAtIndexPath:(NSIndexPath *)indexPath
{
// Return NO if you do not want the item to be re-orderable.
return YES;
}
*/

/*
#pragma mark - Navigation

// In a story board-based application, you will often want to do a little preparation

before navigation
- (void)prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender
{
// Get the new view controller using [segue destinationViewController].
// Pass the selected object to the new view controller.
}

*/

- (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath

*)indexPath
{
 97

PontosViewController *detail = [self.storyboard

instantiateViewControllerWithIdentifier:@"view_pontos"];
NSMutableDictionary *linha=[linhas objectAtIndex:indexPath.row];
detail.codigoLinha=[linha objectForKey:LINHA_CODIGO];
detail.nomeLinha=[linha objectForKey:LINHA_NOME];

[self.navigationController pushViewController:detail animated:YES];

NSMutableArray *coordenada = [[Proxy alloc] getCoordenadaOnibus];

NSDictionary *coordenadaDIC = [coordenada objectAtIndex:indexPath.section];

NSString *lat = [coordenadaDIC objectForKey:ONIBUS_LATITUDE];

NSString *lon = [coordenadaDIC objectForKey:ONIBUS_LONGITUDE];

coordenadaOnibus = [[CLLocation alloc] initWithLatitude:lat.doubleValue

longitude:lon.doubleValue];

locationManager = [[CLLocationManager alloc] init];

locationManager.delegate = self;
locationManager.desiredAccuracy = kCLLocationAccuracyBest;
[locationManager startUpdatingLocation];
}

- (void) locationManager:(CLLocationManager *)manager didFailWithError:(NSError

*)error {
NSLog(@"didFailWithError: %@", error);
UIAlertView *errorAlert = [[UIAlertView alloc]
initWithTitle:@"Error" message:@"Failed to Get Your Location"
delegate:nil cancelButtonTitle:@"OK" otherButtonTitles:nil];
[errorAlert show];
}
 98

- (void)locationManager:(CLLocationManager *)manager
didUpdateToLocation:(CLLocation *)newLocation fromLocation:(CLLocation
*)oldLocation {
CLLocation *minhaCoordenada = newLocation;

float distanciaEmMetros = [minhaCoordenada

distanceFromLocation:coordenadaOnibus];

if (distanciaEmMetros <= [[AjustesViewController alloc] getMetros]) {

[locationManager stopUpdatingLocation];

Boolean audio = [[AjustesViewController alloc] getTocar];

if (audio == true) {
[self playSound];
} else {
[self vibrate];
}
}

NSLog(@"\nDistncia nibus: %f", distanciaEmMetros);

}

- (void) vibrate {
NSLog(@"\nVibrando");
AudioServicesPlaySystemSound(kSystemSoundID_Vibrate);
}

- (void) playSound {
NSLog(@"\nTocando e Vibrando");
AudioServicesPlaySystemSound(1005);
}
@end
 99

8.8.11.2 Ponto das linhas de nibus.

//
// PontosViewController.m
// VamosDeBuso
//
// Created by Matheus Rorato Baptista on 29/09/13.
// Copyright (c) 2013 Matheus Rorato Baptista. All rights reserved.
//

#import "PontosViewController.h"
#import "Proxy.h"
#import "Ponto.h"
#import "AjustesViewController.h"
#import "DeveloperViewController.h"

@interface PontosViewController ()

@end

@implementation PontosViewController

- (id)initWithStyle:(UITableViewStyle)style
{
self = [super initWithStyle:style];
if (self) {
// Custom initialization
}
return self;
}

- (void)viewDidLoad
{
 100

[super viewDidLoad];
self.title = self.nomeLinha;
pontos = [[Proxy alloc] getPontos: self.codigoLinha];

// Uncomment the following line to preserve selection between presentations.

// self.clearsSelectionOnViewWillAppear = NO;

// Uncomment the following line to display an Edit button in the navigation bar for
this view controller.
// self.navigationItem.rightBarButtonItem = self.editButtonItem;
}

- (void)didReceiveMemoryWarning
{
[super didReceiveMemoryWarning];
// Dispose of any resources that can be recreated.
}

#pragma mark - Table view data source

- (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView
{
// Return the number of sections.
return 1;
}

- (NSInteger)tableView:(UITableView *)tableView
numberOfRowsInSection:(NSInteger)section
{
// Return the number of rows in the section.
return [pontos count];
}
 101

- (UITableViewCell *)tableView:(UITableView *)tableView

cellForRowAtIndexPath:(NSIndexPath *)indexPath
{
static NSString *CellIdentifier = @"CellPontos";
UITableViewCell *cell = [tableView
dequeueReusableCellWithIdentifier:CellIdentifier forIndexPath:indexPath];

// Configure the cell...

NSDictionary *pontosDIC = [pontos objectAtIndex:indexPath.row];

cell.textLabel.text = [pontosDIC objectForKey:PONTO_NOME];

NSString *detalhe = [[NSString alloc] initWithFormat:@"Nmero: %@, Sentido:

%@",[pontosDIC objectForKey:PONTO_NUMERO], [pontosDIC
objectForKey:PONTO_SENTIDO]];

cell.detailTextLabel.text = detalhe;

return cell;
}

/*
// Override to support conditional editing of the table view.
- (BOOL)tableView:(UITableView *)tableView canEditRowAtIndexPath:(NSIndexPath
*)indexPath
{
// Return NO if you do not want the specified item to be editable.
return YES;
}
*/

/*
// Override to support editing the table view.
 102

- (void)tableView:(UITableView *)tableView
commitEditingStyle:(UITableViewCellEditingStyle)editingStyle
forRowAtIndexPath:(NSIndexPath *)indexPath
{
if (editingStyle == UITableViewCellEditingStyleDelete) {
// Delete the row from the data source
[tableView deleteRowsAtIndexPaths:@[indexPath]
withRowAnimation:UITableViewRowAnimationFade];
}
else if (editingStyle == UITableViewCellEditingStyleInsert) {
// Create a new instance of the appropriate class, insert it into the array, and add
a new row to the table view
}
}
*/

/*
// Override to support rearranging the table view.
- (void)tableView:(UITableView *)tableView moveRowAtIndexPath:(NSIndexPath
*)fromIndexPath toIndexPath:(NSIndexPath *)toIndexPath
{
}
*/

/*
// Override to support conditional rearranging of the table view.
- (BOOL)tableView:(UITableView *)tableView
canMoveRowAtIndexPath:(NSIndexPath *)indexPath
{
// Return NO if you do not want the item to be re-orderable.
return YES;
}
*/
 103

/*
#pragma mark - Navigation

// In a story board-based application, you will often want to do a little preparation

before navigation
- (void)prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender
{
// Get the new view controller using [segue destinationViewController].
// Pass the selected object to the new view controller.
}

*/

- (void) tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath

*)indexPath{
NSDictionary *pontoSelecionado = [pontos objectAtIndex:indexPath.row];

NSString *lat = [[pontoSelecionado objectForKey:PONTO_LATITUDE]

stringByReplacingOccurrencesOfString:@"," withString:@"."];
NSString *lon = [[pontoSelecionado objectForKey:PONTO_LONGITUDE]
stringByReplacingOccurrencesOfString:@"," withString:@"."];

coordenadaPonto = [[CLLocation alloc] initWithLatitude:lat.doubleValue

longitude:lon.doubleValue];

locationManager = [[CLLocationManager alloc] init];

locationManager.delegate = self;
locationManager.desiredAccuracy = kCLLocationAccuracyBest;
[locationManager startUpdatingLocation];
}

- (void) locationManager:(CLLocationManager *)manager didFailWithError:(NSError

*)error {
NSLog(@"didFailWithError: %@", error);
 104

UIAlertView *errorAlert = [[UIAlertView alloc]

initWithTitle:@"Error" message:@"Failed to Get Your Location"
delegate:nil cancelButtonTitle:@"OK" otherButtonTitles:nil];
[errorAlert show];
}

- (void)locationManager:(CLLocationManager *)manager
didUpdateToLocation:(CLLocation *)newLocation fromLocation:(CLLocation
*)oldLocation {
CLLocation *minhaCoordenada = newLocation;

float distanciaEmMetros = [minhaCoordenada

distanceFromLocation:coordenadaPonto];

if (distanciaEmMetros <= [[AjustesViewController alloc] getMetros]) {

[locationManager stopUpdatingLocation];

Boolean audio = [[AjustesViewController alloc] getTocar];

if (audio == true) {
[self playSound];
} else {
[self vibrate];
}
}

NSLog(@"\nDistncia Ponto: %f", distanciaEmMetros);

// [[DeveloperViewController alloc] setLabelDistanciaPonto:];

- (void) vibrate {
 105

NSLog(@"\nVibrando");
AudioServicesPlaySystemSound(kSystemSoundID_Vibrate);
}

- (void) playSound {
NSLog(@"\nTocando e Vibrando");
AudioServicesPlaySystemSound(1005);
}

@end

8.8.11.3 Tela de alerta

//
// AjustesViewController.m
VamosDeBuso
//
// Created by Matheus Rorato Baptista on 29/09/13.
// Copyright (c) 2013 Matheus Rorato Baptista. All rights reserved.
//

#import "AjustesViewController.h"

@interface AjustesViewController ()

@end

static Boolean alertaTocar=false;

static double metros = 100;

@implementation AjustesViewController
 106

@synthesize metroLabel;

//

- (IBAction)tocar:(id)sender {
UISwitch *swith = (UISwitch *) sender;
if (swith.isOn) {
alertaTocar=true;
}else{
alertaTocar=false;
}
}

- (IBAction)metros:(UIStepper *)sender {
[metroLabel setText:[NSString stringWithFormat:@"%dm", (int)sender.value]];
metros = sender.value;
}

- (Boolean) getTocar {
return alertaTocar;
}

- (double) getMetros {
return metros;
}

//

- (id)initWithStyle:(UITableViewStyle)style
{
self = [super initWithStyle:style];
if (self) {
// Custom initialization
 107

}
return self;
}

- (void)viewDidLoad
{
[super viewDidLoad];

[metroLabel setText:@"100m"];

// Uncomment the following line to preserve selection between presentations.

// self.clearsSelectionOnViewWillAppear = NO;

// Uncomment the following line to display an Edit button in the navigation bar for
this view controller.
// self.navigationItem.rightBarButtonItem = self.editButtonItem;
}

- (void)didReceiveMemoryWarning
{
[super didReceiveMemoryWarning];
// Dispose of any resources that can be recreated.
}

@end