FACULDADE DE TECNOLOGIA DE SO JOS DOS CAMPOS

FATEC PROFESSOR JESSEN VIDAL

THIAGO FEITOZA DE OLIVEIRA













DESENVOLVIMENTO DE APLICAO PARA AUDITORIA DE PROCESSOS
EMPRESARIAIS PARA DISPOSITIVOS MVEIS














So Jos dos Campos
2011
2
THIAGO FEITOZA DE OLIVEIRA













DESENVOLVIMENTO DE APLICAO PARA AUDITORIA DE PROCESSOS
EMPRESARIAIS PARA DISPOSITIVOS MVEIS





Trabalho de Graduao apresentado
Faculdade de Tecnologia So Jos dos
Campos, como parte dos requisitos necessrios
para a obteno do ttulo de Tecnlogo em
Informtica com nfase em Banco de Dados.

Orientador: Prof. Eduardo Sakaue















So Jos dos Campos
2011
3
THIAGO FEITOZA DE OLIVEIRA













DESENVOLVIMENTO DE APLICAO PARA AUDITORIA DE PROCESSOS
EMPRESARIAIS PARA DISPOSITIVOS MVEIS

Trabalho de concluso de curso apresentado
Faculdade de Tecnologia de So Jos dos
Campos, como parte dos requisitos necessrios
para a obteno do ttulo de Tecnlogo em
Informtica com nfase em Banco de Dados.



_______________________________________________________________________
Mestre Prof. Giuliano Arajo Bertoti


______________________________________________________________________
Doutora Prof. Silvia Cristina Sardela Bianchi


______________________________________________________________________
Mestre Prof. Eduardo Sakaue




_____/_____/_____
DATA DE APROVAO

4
















Ficha Catalogrfica


Oliveira, Thiago Feitoza.
Desenvolvimento de Aplicao para Auditoria de
Processos Empresariais para Dispositivos Mveis / Thiago
Feitoza de Oliveira So Jos dos Campos, 2011.
65f. : il.

Monografia (Curso Superior de Tecnologia em
Informtica) Faculdade de Tecnologia de So Jos dos
Campos

1. Desenvolvimento de Aplicao. 2. Auditoria de
Processos. 3. Dispositivos Mveis. I. Ttulo
5























Dedico este trabalho aos meus pais,
sem os quais eu no teria tido
foras para chegar onde estou.
6
AGRADECIMENTOS

Aos meus pais, irmo e namorada pelo apoio e compreenso.
A meu orientador Eduardo Sakaue por toda a ajuda e pacincia e por seus ensinamentos.
Aos meus colegas de trabalho que contriburam com idias, opinies e pela motivao.
Aos professores da Faculdade de Tecnologia de So Jos dos Campos, pois, sem os quais, no
teria o conhecimento para prosseguir com meus trabalhos.

7























"Ao dar s pessoas o poder de partilhar,
estamos tornando o mundo mais transparente."
Mark Zuckerberg
8
RESUMO



Este trabalho descreve um estudo de ambiente de desenvolvimento de software que utiliza
a metodologia SCRUM de desenvolvimento e pratica o CMMI como mtodo de melhoria de
processos, visando propor uma soluo que torna esta tarefa mais fcil, rpida e com
resultados em menor tempo.
O estudo envolve a anlise do conceito e dos objetivos de auditoria de processos e do
CMMI, mostrando o que requerido para atingir as metas, executar as prticas, e revelando
melhorias ao processo.
Em seguida, foi estudado a metodologia de desenvolvimento de software SCRUM, a fim
de elencar os papis e responsabilidades de cada membro de um projeto, seu ciclo de
desenvolvimento e suas fases.
Analisou-se, tambm, um trabalho onde um processo SCRUM j havia sido avaliado por
um questionrio CMMI. Assim, identificou-se pontos fortes e fracos do mtodo de
desenvolvimento em relao avaliao.
Assim, com o contexto do ambiente avaliado, props-se um software para simplificar esta
atividade, sendo tal software desenvolvido com base em tecnologia mvel.
Aps o desenvolvimento, o ambiente foi avaliado pelo mtodo proposto e por um mtodo
convencional, a fim de compar-los quanto suas vantagens.

Palavras-chave: dispositivos, mveis, CMMI, SCRUM, auditoria, avaliao, processos,
android.
9
Abstract

This work describes a study about software development environment that uses the
SCRUM development methodology and practices the CMMI like a process improvement
method, aiming to propose a solution which make this task easier, faster and results in a short
time.
This study involves a analysis about concept and goals of process audit and CMMI,
presenting what is required to reach the goals, to execute practices and how it brings
improvement to the process.
After this, the SCRUM development methodology was studied, in order to list the roles
and responsibilities for each member of a project, it development cycle and it steps.
A work, which has a SCRUM evaluated by CMMI evaluation test, was analyzed as well.
Then, strengths and weaknesses of the development method were identified in relation to the
evaluation.
So, having a context of evaluated environment, a software was proposed to simplify this
activity, this software being developed on a mobile technology.
After this development, the environment was evaluated by a conventional method and
proposed method, aiming to compare their advantage.

Keywords: mobile, devices, CMMI, SCRUM, audit, evaluation, process, android.
10
ndice:
1. Introduo ....................................................................................................... 11
1.1. Motivao ........................................................................................................ 11
1.2. Objetivos ......................................................................................................... 13
1.3. Metodologia ..................................................................................................... 13
1.4. Organizao .................................................................................................... 14
2. Fundamentao Terica ................................................................................. 15
2.1. Comunicao Mvel........................................................................................ 15
2.2. O Android ....................................................................................................... 18
2.3. Auditoria de Processos.................................................................................... 22
2.3.1. Conceitos de Auditoria ................................................................................... 22
2.3.2. CMMI .............................................................................................................. 23
2.4. SCRUM ........................................................................................................... 26
3. SCRUM + CMMI ........................................................................................... 31
3.1. Planejamento do Projeto ................................................................................ 33
3.2. Controle e Monitoramento do Projeto ........................................................... 33
3.3. Gerenciamento de Acordo com Fornecedores ............................................... 33
3.4. Gerenciamento Integrado de Projeto ............................................................. 33
3.5. Gerenciamento de Riscos ................................................................................ 33
3.6. Gerenciamento Quantitativo .......................................................................... 33
4. Proposta de Soluo ........................................................................................ 37
4.1. Arquitetura ..................................................................................................... 37
4.2. Modelagem do software: Cliente .................................................................... 38
4.4. Desenvolvimento ............................................................................................. 39
4.5. Ambiente Avaliado ......................................................................................... 40
4.6. Aplicao do Mtodo Desenvolvido ................................................................ 44
5. Aplicao do Conceito no Ambiente .............................................................. 48
5.1. Aplicao pelo Mtodo Proposto .................................................................... 48
5.2. Mtodo Convencional ..................................................................................... 49
6. Anlise de Resultados ..................................................................................... 56
7. Consideraes Finais ...................................................................................... 59
8. Referncias Bibliogrficas .............................................................................. 61

11
1. Introduo

1.1. Motivao

Dispositivos mveis esto cada vez mais presentes em nossas vidas, contudo, seu
objetivo de uso est sendo alterado, tendo a ateno dividida entre funcionalidades de
ligaes telefnicas, acesso internet, jogos, aplicativos auxiliares e etc. Em suma, os
mobiles esto sendo utilizados para simplificar atividades do dia-a-dia.

Conforme a International Telecommunication Union (ITU, 2011), h um crescimento
global de cerca de 650 milhes de novas assinaturas de celulares por ano, sendo em 2010,
estimados pouco mais de 5 bilhes de celulares, como mostra a Figura 1.1.

Figura 1.1 Grfico do crescimento global anual de assinaturas de celulares (ITU, 2011)

Em mbito nacional, o Brasil teve grande crescimento na rea de telefonia mvel nos
ltimos anos, tendo um crescimento mais de 50 milhes de assinaturas em dois anos (2007
a 2009) (ITU, 2011).

Segundo a empresa The Nielsen Company, a queda nos preos de tais aparelhos
proporcionou maior facilidade aquisitiva a todas as classes de consumidores (A, B, C, D)
12
terem um mobile. Assim, a Nielsen realizou um estudo, no Brasil, para saber a quantidade
de pessoas adeptas da tecnologia, como mostra a Figura 1.2 (Nielsen, 2010).

Figura 1.2 Grfico demonstrativo sobre quantidade de pessoas que possuem smartphone e suas
respectivas classes sociais.

Cada um destes aparelhos possui um sistema operacional (SO) que faz a integrao
entre as aplicaes e o hardware. Dentre estes sistemas encontra-se o Android, que possui
algumas peculiaridades que o releva em meio aos outros sistemas operacionais, que sero
discutidas brevemente.

A OHA (Open Handset Alliance), formada pela Google e outras empresas com
enfoque em tecnologia mvel, desenvolveu o Android, que um projeto de cdigo aberto
feito para suportar aparelhos com diversas especificaes. Desenvolvido com base em um
kernel Linux, contm uma mquina virtual JAVA personalizada para aperfeioar o
desempenho do aparelho. Sua principal caracterstica o fcil desenvolvimento de
aplicaes, sendo que tais aplicaes podem ter o mesmo nvel de acesso dos aplicativos
que j vm com o SO (OHA, 2011).

Visto que a aquisio e o desenvolvimento de softwares para estes aparelhos esto
cada vez mais fceis, espera-se que as empresas comecem a desenvolver / implantar
solues para dispositivos mveis, a fim de prover uma maior facilidade para seus
clientes.

Dentre muitos problemas, as empresas enfrentam a falta de gerenciamento e
organizao de seus processos internos e externos (ex.: comunicao com fornecedores).
Para minimizar este problema, recorrem implantao de metodologias de processos e
13
auditoria dos mesmos, esperando ter uma melhor visibilidade sobre seus processos e uma
evoluo dos mesmos (SORTICA, 2004).

1.2. Objetivos

Este trabalho visa propor um software que tenha o intuito de auxiliar nas auditorias de
processos de TI e que tal software fornea mobilidade ao usurio, dando-lhe condio
para acessar o software de seu dispositivo mvel. Ser desenvolvido um modelo de
software usando conceitos de auditorias. Nestes termos, h os seguintes objetivos
especficos:
a) Estudo de ambientes;
b) Anlise de processos;
c) Desenvolvimento da soluo;
d) Implantao da soluo.

1.3. Metodologia

Este trabalho ser iniciado com uma anlise de tecnologias que sero utilizadas no
decorrer do projeto, assim como tcnicas e estudos os quais iro auxiliar no
desenvolvimento da aplicao.

Ser feito um estudo sobre um ambiente onde necessria a auditoria dos processos
relacionados a um trabalho, visando analisar os problemas na agilidade no procedimento
de anlise dos processos e a necessidade de mobilidade e facilidade do auditor.

Aps a definio do ambiente, ser projetado um modelo de software para suprir as
necessidades apresentadas na pesquisa. Utilizando de metodologias de desenvolvimento
de software para dispositivos mveis, sero coletados os requisitos do sistema,
necessidades cruciais e, com base nessas informaes, ser criada uma estrutura de como
o sistema ir se comportar.

No passo seguinte, o sistema ser desenvolvido com base no projeto especificado
anteriormente e implantado no modelo de ambiente que foi definido, a fim de testar a
efetividade da soluo desenvolvida.
14

Por fim, o software ser avaliado quanto sua eficcia em relao ao seu objetivo
principal, visando especialmente mobilidade e facilidade de uso.

1.4. Organizao

No captulo 1 foi apresentada a motivao que deu origem a este estudo, mostrando o
crescimento na utilizao dos dispositivos mveis, tecnologia que utilizada nestes
aparelhos para aperfeioar o uso do equipamento e o problema que as empresas enfrentam
com seus processos para atender seus clientes.

No captulo 2 sero detalhadas as tecnologias e metodologias utilizadas nesta pesquisa,
abordando o surgimento da comunicao mvel, o ambiente do sistema operacional
Android, os conceitos da auditoria de processo, conceitos do CMMI e o funcionamento do
processo de desenvolvimento de software SCRUM.

No captulo 3 ser analisado o SCRUM com relao aos requisitos do CMMI,
visualizando pontos de coletas de informaes, pontos possveis para aplicar os
questionrios e uma constatao de quais questionrios so atendidos ou no com o
processo mais bsico do SCRUM.

O captulo 4 ir conter a definio do software que ser desenvolvido, sendo possvel
visualizar quais as ferramentas sero utilizadas para desenvolver o projeto e como ser a
arquitetura de funcionamento das aplicaes cliente e servidor.

No captulo 5 ser descrito o modo que o software ser aplicado em um dado processo.
Tal processo tambm ser definido neste captulo, assim como um meio convencional de
auditoria, que tambm se baseia em CMMI.

No captulo 6 sero analisados os resultados obtidos com este projeto.

No captulo 7 ser apresentada a concluso do trabalho.

15
2. Fundamentao Terica

Este captulo trata das tecnologias e metodologias envolvidas para elaborao do trabalho.
Estudou-se a evoluo da comunicao mvel, tendo uma anlise de como se chegou
tecnologia dos dispositivos mveis atuais e sobre sistemas operacionais que estes utilizam.

Tambm est presente um estudo sobre processos e mtodo de auditoria ao mesmo.

2.1. Comunicao Mvel

Com a necessidade de se comunicar, o ser humano desenvolveu vrias tcnicas e
equipamentos para tornar este processo mais rpido e fcil. Um exemplo claro foi o
telefone. Criado em 1876 por Alexander Graham Bell, o telefone sofreu alteraes no
decorrer dos anos, sendo aprimorados at a criao do primeiro dispositivo mvel, os
celulares, em 1947, fabricados pelas companhias Bell e AT&T (AKAIWA, 1997).

Durante a evoluo dos telefones, tambm evoluram os computadores. Seguindo a
mesma linha dos telefones, surgiu a necessidade de que os computadores tambm
pudessem ser levados a outros lugares de uma maneira mais fcil, mais mvel. Eis que
surgem os notebooks.

Os notebooks tiveram seu incio em 1980 e seus primeiros modelos pesavam
aproximadamente 12 kilos, quase seis vezes mais pesados do que os atuais. Em 1990, a
Hewlett-Packard (HP) deu incio a sua linha de computadores portteis com o HP951 X
Palmtop PC, mesmo ano da popularizao de dois outros dispositivos: o HandHeld e o
Personal Digital Assistant (PDA) (TONON, 2006).

HandHeld e PDA foram criados a fim de incorporar a facilidade de movimentao dos
celulares e as funcionalidades dos computadores. Suas funes bsicas envolvem
processamento de textos, manipulao de planilhas, acesso internet e coleta de dados. A
diferena entre os dois que o HandHeld possui um teclado para digitao e o PDA, alm
de ser um pouco menor, possui tela sensvel ao toque e teclado digital (TONON, 2006).

16
Ou seja, a evoluo destes equipamentos acarretou a integrao com a computao
com o objetivo de prover mais funcionalidades, mas ainda com foco na comunicao. Esta
evoluo chegou a tal ponto que se fez necessrio incorporar sistemas de informao em
dispositivos, como os celulares, dando origem a uma grande variedade em relao a
modelos, funcionalidades, aplicaes e sistemas operacionais.

Como explica Martins (2009), h vrios tipos de sistema operacional para dispositivos
mveis, tais como o iOS, da Apple, Microsoft Windows Mobile, Nokia Symbian e
Android, do grupo Open Handset Alliance (OHA).

Se compararmos os dados internacionais de uso de sistemas operacionais nos
dispositivos mveis (Tabela 2.1), podemos ver o crescimento no uso dos sistemas
operacionais nos anos de 2009 (ACKER, 2010) e 2010 (NIELSEN, 2010).


2009 2010
SO Porcentagem SO Porcentagem
RIM Blackberry OS 6,00% RIM Blackberry OS 26,10%
Apple iOS 51,00% Apple iOS 28,60%
OHA Android OS 16,00% OHA Android OS 25,80%
Outros 27,00% Outros 19,50%
Tabela 2.1 Porcentagem internacional de uso dos sistemas operacionais nos mobiles

17

Grfico 2.1 Grfico comparativo de uso dos sistemas operacionais internacionalmente
(Baseado nos dados da Tabela 2.1)

Como podemos ver no Grfico 2.1, h um crescimento considervel de dois sistemas
operacionais. Porm, o que se destaca dentre eles o Android, no apenas pelo
crescimento, mas tambm por sua caracterstica de sempre dar o mesmo nvel de acesso
aos programas nele instalados. Ou seja, tanto os softwares que so originrios do sistema
operacional quanto os que so criados por terceiros possuem acesso aos mesmos recursos,
podendo, assim, substituir qualquer software nativo do SO por outro com as mesmas
caractersticas (MARTINS, 2009).

J houve vrios trabalhos envolvendo aplicaes para dispositivos mveis, inclusive
estudos com base na plataforma Android, tais como:

Medic Mobile Desenvolvido por Uliton Sandro Tonon sobre a plataforma de
programao Microsoft .Net, trata-se de uma aplicao que envolve um sistema de
gerenciamento de consultas mdicas, onde o pronturio consultado por um dispositivo
mvel, tendo os dados recuperados por meio de conexo wireless.

H tambm uma aplicao embarcada em celular visando controle de rob via Wi-Fi,
a qual foi desenvolvida por CRUZ (2011) e seus colegas, onde o objetivo da aplicao foi
usar um dispositivo mvel que emitisse comandos via Wi-Fi para um rob executar.
Possibilitando que o rob fosse acionado distncia e sem a necessidade de fios.
18

Ou seja, aplicaes para dispositivos podem ser utilizadas em diversas reas, desde
que tal rea tenha a necessidade de interao do usurio por meio de um dispositivo mvel
ou queira prover esta facilidade, como no caso deste trabalho.

2.2. O Android

A OHA, liderada pela Google, constituda por mais de 40 empresas de ramos
diferentes, porm todas ligadas tecnologia de dispositivos mveis. Este grupo foi criado
com o objetivo de criar padres para a indstria de telefonia mvel, tendo como primeiro
passo para alcanar este objetivo, a criao do Android (ACKER, 2010).

O Android um sistema operacional baseado em um kernel Linux, verso 2.6, o qual
prov os mesmos servios de segurana, gerenciamento de memria e de processos e
todas outras caractersticas do kernel. Conforme a Figura 2.1, sua estrutura formada
pelas camadas: Linux Kernel; Bibliotecas; Ferramentas de Runtime do Android; Estrutura
das Aplicaes; e Aplicaes (DEV GUIDE, 2011).


Figura 2.1 Arquitetura do sistema operacional Android (DEV GUIDE, 2011)
19

Kernel Linux: responsvel pelo controle de acesso e gerenciamento dos recursos do
celular para ter um uso organizado e dar robustez na utilizao dos mesmos.

Runtime do Android: possui a maior parte das funcionalidades das principais
bibliotecas da linguagem JAVA e uma mquina virtual, nomeada de Dalvik. O Dalvik foi
projetado com foco em economia no consumo de memria e possu a caracterstica de
criar uma instncia para cada processo, assim, tornando-o mais eficiente e performtico.
Basicamente, o Dalvik uma JVM (JAVA Virtual Machine) customizada, que executa as
classes j compiladas atravs de um compilador JAVA.

Bibliotecas: est camada usada pelos componentes do sistema do Android, pois
possuem capacidades de fornecer a estrutura para as aplicaes que sero executadas no
SO. Exemplos dessas capacidades so: bibliotecas de mdia (MP3, JPG, MPEG4 e etc.);
bibliotecas 3D, que fornecem suporte a aplicaes com grficos em 2D e 3D; SQLite,
banco de dados relacional muito performtico e leve para o sistema; entre outros (DEV
GUIDE, 2011).

Estrutura de Aplicao: neste nvel encontram-se as APIs (Application Programming
Interface), que foram desenvolvidas para simplificar o reuso dos componentes contidos no
sistema operacional. Entre as APIs disponveis esto: Gerenciador de Janelas; Gerenciador
de Atividades; Provedor de Contedo; e etc.

Aplicaes: por fim, esta camada contm as aplicaes escritas em JAVA e instaladas
no celular, tais como Google Maps, browser, calendrios e etc.

Para um software ser instalado no Android, o cdigo compilado e empacotado em
um arquivo na extenso .apk. Tal arquivo, quando executado no dispositivo mvel,
descompactado e habilitado para interao com o usurio.

De acordo com a arquitetura do Android, cada aplicao executada em uma mquina
virtual Dalvik exclusiva, o Kernel Linux concede aplicao um ID e so concedidas,
tambm, as permisses aos arquivos de competncia da aplicao, os quais s ficaro
visveis para aquela aplicao durante sua execuo.
20

As aplicaes podem ser acionadas de diversas maneiras utilizando componentes que
so instanciados quando so requisitados. Tais componentes chamam-se Activitiy,
Services, Content Providers e Broadcast Receivers.

Os componentes Activity, Services e Broadcast Receivers so acionados por
mensagens assncronas, ou seja, que pode no ocorrer num tempo previsto. Estas
mensagens so enviadas por meio de um objeto chamado Intent, enviando uma inteno
de ao (DEV GUIDE, 2011).

As Intents podem ser classificadas em duas categorias, os implcitos e os explcitos.
Nas Intents implcitas, o prprio sistema operacional escolhe qual dos componentes
responder melhor quela chamada da Intent, baseando em alguns critrios do prprio
Android. J nas explcitas, o componente que ir ser ativado indicado com antecedncia.
As atividades que so executadas no Android tm um ciclo de vida rigorosamente
definido. Comeando quando a atividade requisitada, a atividade criada, executada e
destruda, assim como exemplificado na Figura 2.2.

21

Figura 2.2 Ciclo de vida de uma atividade no Android ((DEV GUIDE, 2011)

22
2.3. Auditoria de Processos

2.3.1. Conceitos de Auditoria

A palavra auditar derivada do verbo ingls "to audit", que significa
examinar, corrigir, certificar, e / ou ajustar (ATTIE, 2010).

Portanto, auditar pode ser definido como um processo de avaliao de uma
situao diante de critrios previamente determinados, ou seja, comparando fatos
reais com metas pr-estabelecidas (FILHO, 2011).

No Brasil, a auditoria foi reconhecida apenas aps um ato do Banco Central
do Brasil, em 1968, e teve seu fortalecimento em 1972 pela mesma entidade em
conjunto com o Conselho Federal de Contabilidade e IBRACON, rgo criado
para congregao e auto-disciplinao de profissionais de auditoria
(POMPONET, 2009).

A princpio, cabia ao auditor emitir relatrios do setor contbil das empresas,
porm, a necessidade fez com que o mesmo auditor, alm da atividade j dita,
tambm emitisse relatrios com sugestes sobre problemas operacionais.

Com o aumento no investimento em recursos de TI, surgiu a
necessidade de gerenciar melhor os recursos e os investimentos em TI tambm,
buscando a excelncia e evitando desperdcios (POMPONET, 2009).

Para atingir este objetivo, h a necessidade da implantao de uma
Governana de TI, a qual ir planejar e direcionar cada recurso e processo a
objetivos organizacionais (HANASHIRO, 2007).

Para isto, deve-se definir um framework de auditoria, adaptando as
melhores prticas das metodologias disponveis aos requisitos da empresa e do
cliente (HANASHIRO, 2007).

Dentre as metodologias disponveis, h o CMMI.
23

2.3.2. CMMI

Conforme o Instituto de Engenharia de Software (CMU, 2011), o CMMI
(Capability Maturity Model Integration) visa melhorar os processos reunindo
prticas usadas na concepo do produto e na manuteno do mesmo, cobrindo
todo o ciclo de vida entre estas etapas. Resumindo, se posta como um guia para
melhorar os processos da organizao e sua capacidade para gerenciar o
desenvolvimento, aquisio e manuteno de produtos e servios.

Estas prticas abrangem tpicos como incitao e gerenciamento de
requisitos, tomada de deciso, plano de trabalho, tratamento de riscos e
medio de desempenho (CMU, 2011).

Conforme MARAL (2007a), os componentes do CMMI esto agrupados
em trs categorias, as quais so descritas como:
Requeridos componentes que devem ser implementados
visivelmente nos processos da organizao com o objetivo de atender
uma rea do processo (atendimento de metas especficas);
Esperados componentes que a empresa deve desenvolver para atingir
um componente requerido (atendimento de prticas genricas e
especficas);
Informativos componentes que auxiliam a empresa em o que fazer
para atingir os componentes esperados, assim, atingindo tambm, os
componentes requeridos.

Uma rea de processo (PA, do ingls Process Area) um conjunto
interligado de aes que, quando realizados simultaneamente, atendem ao
conjunto de objetivos relevantes para melhoria da rea em questo. A rea de
processo pode ser incrementada com objetivos complementares a fim de
melhor descrev-la, como propsito, notas introdutrias e lista de reas
relacionadas (MARAL, 2009).

24
Meta especfica (SG, do ingls Specific Goal) constituda de vrias
prticas especficas que devem ser executadas para atingir tal meta. Esta meta
descreve as funes que devem estar presentes no processo para atender
adequadamente a PA.

Prticas especficas (SP, do ingls Specific Pratices) descrevem atividades
que devero ser executadas objetivando o cumprimento de metas especficas.
Assim, realizando estas prticas, alcana-se uma meta especfica.

Meta genrica (GG, Generic Goal) so caractersticas que esto presentes
em vrias reas do processo. Tanto estas metas quanto as metas especficas so
usadas para medir o nvel de satisfao de uma PA.

No CMMI existem duas representaes grficas para determinar o nvel de
capacidade e o nvel de maturidade das reas de processo. So definidos
objetivos alcanveis e relacionados ao contexto da rea especfica para cada
processo, assim, permitindo a analise do cumprimento destes objetivos.

Na representao contnua possvel escolher entre melhorar o
desempenho de um nico processo ou diversos processos, desde que estes
estejam alinhados aos objetivos organizacionais. Nesta representao, a
avaliao ocorre em nveis enumerados de 0 a 5. Esta representao tem foco
nos processos como Gerncia de Projeto, Suporte e etc. Assim, h os nveis:

a) Nvel 0 (Incompleto) - o processo no executado ou executado
parcialmente.

b) Nvel 1 (Executado) - o processo executa as prticas especficas da rea
de processo em questo.

c) Nvel 2 (Gerenciado) - o processo planejado e gerenciado. Caso haja
pontos falhos no plano, so feitas aes corretivas.

25
d) Nvel 3 (Definido) - o processo documentado e executado por toda a
organizao nos projetos, podendo ser adaptado aos s caractersticas
do projeto.

e) Nvel 4 (Gerenciado Quantitativamente) - o processo analisado
estatisticamente e pode-se ter uma previsibilidade de como o processo
ir se comportar.

f) Nvel 5 (Otimizado) - o processo melhorado continuamente,
identificando os problemas comuns causados pelas variaes no
processo avaliado (ANACLETO, 2004).

Na representao por estgios j h nveis pr-estabelecidos (de 1 5),
visando melhorar todos os processos da organizao baseando-se em estgios
que no podem ser desconsiderados, pois cada estgio serve de base para o
prximo estgio. Assim, temos:

a) Nvel 1 (Inicial) imaturidade organizacional; os processos ainda so
improvisados e dificilmente seguidos; muitas vezes no se cumpre os
prazos e custos acordados; o planejamento feito sem baseamento em
estimativas; no h disseminao de conhecimento adquirido no
projeto; o sucesso do projeto depende totalmente das habilidades dos
gerentes e desenvolvedores.

b) Nvel 2 (Gerenciado) os processos de desenvolvimento de software e
as polticas envolvidas esto definidos e so seguidos; as estimativas se
baseiam em conhecimento adquirido em projetos anteriores; so
utilizados processos definidos, disseminados, documentados, medidos e
auditados com rotinas de melhoria; os processos so puramente
gerenciais e pertencentes aos projetos.

c) Nvel 3 (Definido) os processos usados esto definidos e so
conhecidos por toda a organizao; neste nvel, consideram-se tambm
os processos tcnicos junto aos gerenciais; ambos os processos so
26
usados repetidamente; os processos so transferidos dos projetos para a
organizao.

d) Nvel 4 (Quantitativamente Gerenciado) define metas quantitativas
para os processos e produtos, coletando, em todos os projetos, medidas
de produtividade e qualidade; estabelecido um controle estatstico de
processos; a gesto feita com base nos dados quantitativos.

e) Nvel 5 (Otimizao) a organizao est focada na melhoria contnua
de seus processos; identificao de melhorias e defeitos; aes
preventivas sobre possveis problemas; anlise de custo / benefcio, com
base nos dados coletados, para mudar significativamente processos e /
ou tecnologias.

Graficamente, temos as representaes dispostas como na Figura 2.3
(MARAL, 2009).


Figura 2.3 Representaes do CMMI (MARAL, 2009).

2.4. SCRUM

O SCRUM uma prtica de desenvolvimento gil de softwares que est em grande
uso atualmente. Envolve um processo de desenvolvimento inovador, rpido e controlado,
o qual permite que, enquanto os desenvolvedores criam partes do software, outras partes
j desenvolvidas estejam disponveis para teste, aumentando assim a agilidade na deteco
e soluo de erros ou problemas nas regras de negcio.
27

Conforme explica MARAL (2011), o SCRUM segue a premissa de que um projeto
de desenvolvimento de software muito complexo para que seja mensurado logo no
inicio. Assim, feita uma previso de custo / prazo bsica em cima dos requisitos que o
cliente deseja e dividido o projeto em pequenas tarefas, assim podendo dar uma
previsibilidade mais confivel.

Neste processo, temos definidos alguns papis para as pessoas envolvidas com o
produto, as quais so:
O Product Owner (PO) representa os interesses das pessoas envolvidas no projeto,
fornecendo os requisitos gerais do sistema, os objetivos, planos de entrega, retorno
do investimento e garantindo que as funcionalidades de maior impacto sejam
prioritariamente desenvolvidas;
Scrum Master (SM), este deve garantir a progresso do projeto e que cada
membro do time tenha as ferramentas necessrias para realizar seus trabalhos,
organiza reunies e monitora o progresso do projeto;
Desenvolvedores (Developers) e Avaliadores (Testers), ambos trabalham em
paralelo. Enquanto o primeiro desenvolve a aplicao, o outro testa o software
desenvolvido para certificar-se que est funcionando conforme previsto;
Clientes (Customers) e Executivos (Executives), so as pessoas que financiam o
projeto, esperando ter o produto conforme especificado, pois tambm o utilizam.

Tendo os papis definidos, pode-se definir, ento, o produto, ou, comumente chamado
de artefatos.

Schwaber (2004) diz que o SCRUM composto, principalmente, pelos artefatos
Product Backlog, Sprint Backlog e agregao das funcionalidades desenvolvidas. Mas
Shojaee (2011) mostra, tambm, que h outros artefatos importantes como o Release
Backlog e Defect Backlog.

Seguindo o processo de desenvolvimento de software SCRUM, so realizados os
seguintes passos:

28
Primeiro, levantada uma lista de requisitos sobre o produto que ser desenvolvido.
Esta lista tambm chamada de lista de desejos, ou Wish List (WL), onde constam todas
as funcionalidades e regras solicitadas pelos Customers e Executives.

Tendo definida a lista de requisitos, o Product Owner ajudar a validar os requisitos,
podendo ser retirados ou includos mais requisitos, conforme a necessidade do produto.
Assim, dando incio ao Product Backlog selecionado, ou seja, filtrado pelo Product
Owner.

Em seguida, a partir do Product Backlog, podemos definir Release Backlogs, que so
partes do produto final, ou seja, o produto dividido em entregas menores, podendo ter
uma estimativa de horas gastas para concluso do Release, que resultaro na concluso do
projeto. Estes backlogs so priorizados pelo Product Owner, levando em considerao seu
peso em relao ao produto final.

Tendo os Release Backlogs, defini-se os Sprints Backlogs, que tambm se resumem
em uma diviso de tarefas do Release, tendo um tempo de durao entre 3 e 30 dias no
mximo dependendo do ciclo do Release (quantidade de iteraes do Release).

Conforme diz Maral (2007b), geralmente as primeiras Sprints tratam a arquitetura e a
infra-estrutura do software.

Espera-se, seguindo estes conceitos, que ao final de cada Sprint obtenha-se aquela
parte do produto a um estado pronto, ou seja, com todas as funcionalidades desenvolvidas
e testadas, prontas para serem agregadas ao produto total e a equipe pode dar incio a uma
nova Sprint (SHOJAEE, 2011).

Durante a realizao de uma Sprint ocorrem os chamados Daily SCRUM Meetings,
que so reunies dirias com um tempo mximo de 15 minutos. Estas reunies viso
reunir a equipe de desenvolvimento para compartilhar seu progresso, suas dificuldades e
seu plano de trabalho at o prximo SCRUM Meeting (MARAL, 2007b). As perguntas a
serem respondidas nesta reunio so:
O que fiz no projeto desde a ltima reunio?;
Que impedimentos estou tendo para realizao da tarefa?;
29
O que irei fazer at a prxima reunio?.

Alm desta reunio, ainda h a Sprint Review e a Sprint Retrospective Meeting. A
primeira objetiva permitir que o time de desenvolvedores mostre as funcionalidades feitas
ao Product Owner e este inspecione o que foi desenvolvido, podendo solicitar algumas
adaptaes no projeto. A segunda visa debater o que pode ser feito para melhorar o time, o
processo e / ou o produto para melhor executar a prxima Sprint (Maral, 2007b).

Ao final de cada Sprint possvel saber qual o tempo decorrido do projeto e seu tempo
restante previsto para trmino. Ento, se uma Sprint no finalizada no prazo, pode ser
um grande indicador informando que o projeto inteiro est atrasado (SHOJAEE, 2011).

Em relao aos defeitos, h duas prticas possveis na metodologia SCRUM.

A primeira , assim que detectados os bugs da Sprint em questo, solucion-los
imediatamente e, aps a correo destes, pode-se tomar a Sprint como finalizada.

A segunda opo mapear todos os bugs encontrados ao longo das Sprint do release e
formar um Defect Backlog. Podem ser criados um ou dois Sprint de defeito para soluo
de todos os bugs encontrados.

Portanto, seguindo este processo de desenvolvimento, temos:


Figura 2.3 Ciclo de vida de um projeto SCRUM (SANTANDER, 2009)
30

Para analisar os indicadores de tempo total e restante do release, pode-se usar uma
ferramenta chamada Burndown Chart, que fornece um grfico de trabalho restante do que
se est avaliando. Este um recurso muito popular no SCRUM, pois fornece um
gerenciamento muito eficaz do trabalho remanescente do release (SCHWABER, 2011).
O Burndown Chart prove valores dirios da quantidade do trabalho restante, podendo
ver se a equipe est no caminho certo ou est tendo dificuldades no desenvolvimento. No
grfico pode ser taxada uma linha de previso de trmino, qual comumente chamada de
Burndown Velocity, referente ao tempo acordado para concluso da tarefa. No grfico
possvel ter uma mdia de velocidade de desenvolvimento do projeto, ento se pode,
tambm, calcular a velocidade de desenvolvimento por dia que se deve ter para terminar a
entrega a tempo.

Para ter essa viso grfica do andamento do projeto, ao final de cada dia os
desenvolvedores atualizam o trabalho restante. Isto importante para se ter um
acompanhamento de progresso dia-a-dia do trabalho realizado (SCHWABER, 2011).

Abaixo, na figura tal, mostra-se um exemplo de grfico Burndown, feito numa
mquina virtual Android verso 2.1, com valores fictcios.


Figura 2.4 Mquina virtual Android mostrando um grfico Burndown

31
3. SCRUM + CMMI

Neste captulo analisado o Scrum, visando aderi-lo ao CMMI, mapeando os pontos
de seus processos que so passveis de auditoria.

Santander (2009) mostra em seu trabalho um mapeamento das reas do SCRUM em
relao ao CMMI nveis 2 e 3. Mostra tambm que, aps a avaliao feita, o SCRUM no
atende a alguns requisitos do CMMI por no ter documentao, controle e registros
suficientes para atender aos nveis indicados. Assim, fica a critrio da organizao
implantar uma metodologia complementar para o SCRUM conter tais requisitos.

Visando o gerenciamento e desenvolvimento de requisitos, Zanatta (2005) avaliou o
SCRUM de acordo com o CMMI e tambm levantou problemas de adequao entre as
tecnologias. Porm, no s identificou pontos fracos do SCRUM, como tambm sugeriu
possveis solues para os problemas citados.

Em uma anlise mais profunda, Maral (2009) apresenta uma verificao do
atendimento do SCRUM ao CMMI at o nvel 4. No trabalho, foi desenvolvido um
projeto denominado SCRUMMI, que tem o objetivo de facilitar o gerenciamento do
SCRUM atravs do CMMI.

Os resultados obtidos foram de grande relevncia, tendo um ganho de produtividade
de 80% (4 vezes maior que o previsto no incio do projeto) e possibilitando uma maior
previsibilidade de prazo e custo do projeto e aumentando a possibilidade de sucesso do
projeto por ter maior envolvimento do cliente e escopo mais flexvel.

Definiu-se, neste trabalho, que as prticas do SCRUM sero analisadas e mapeadas
conforme as reas de processo da categoria Gesto de Projetos.

Assim, conforme informaes de SEI (2006), a Tabela 3.1 mostra a categoria de
Gesto de Projetos e suas reas de processo separadas por nvel de maturidade do CMMI
(representao por estgios).

32
Nvel de
Maturidade
rea de Processo
Sigla
(SEI)
2
Planejamento do Projeto PP
Controle e Monitoramento do Projeto PMC
Gerenciamento de Acordos com Fornecedores SAM
3
Gerenciamento Integrado de Projetos IPM
Gerenciamento de Riscos RSK
4 Gerenciamento Quantitativo QPM
Tabela 3.1 Gesto de Projeto - reas de processo por nvel de maturidade

Na Tabela 3.1 so mostradas as reas de processo at o nvel 4, pois no h reas de
processo do nvel 5 para a categoria Gesto de Projetos.

Em seu trabalho, Maral (2009) compara as reas de processo citadas na Tabela 3.1 de
acordo com sua aderncia com os processos do SCRUM. Sero utilizados os critrios
mostrados na Tabela 3.2 para avaliar se o SCRUM possui evidncias em relao s reas
de processo.

importante ressaltar que os critrios aqui adotados foram definidos pela autora e
podem no ser iguais aos mesmos critrios usados em uma auditoria oficial do CMMI.

Classificao Critrio Sigla
Satisfeita
O SCRUM atende completamente a
prtica
S
No Satisfeita O SCRUM no atende a prtica NS
Parcialmente
Satisfeita
O SCRUM atende parcialmente a
prtica
PS
Tabela 3.2 Critrios para avaliao segundo Maral (2009)

Definidos os critrios, so avaliadas as reas de processo, utilizando-se dos critrios de
avaliao, para medir o nvel de atendimento que o SCRUM tem em relao ao CMMI.

Conforme SEI (2006), os objetivos das reas de Processo so:
33
Planejamento do Projeto - O objetivo desta rea de processo definir e garantir que
sejam seguidos planos de projeto, onde so definidas as atividades do mesmo.

Controle e Monitoramento do Projeto - O objetivo desta rea de processo dar uma
visibilidade do progresso do projeto, sendo possvel a tomada de aes corretivas quando
constatado que o desempenho do projeto est significativamente fora do plano.

Gerenciamento de Acordo com Fornecedores - Esta rea de processo visa fornecer
informaes para gerenciar a aquisio de produtos de fornecedores.

Gerenciamento Integrado de Projeto - O objetivo desta rea de processo definir e
gerenciar o processo e garantir o envolvimento das reas interessadas por meio de um
processo definido e integrado, o qual se adapta aos processos padres da organizao.

Gerenciamento de Riscos - Esta rea de processo visa identificar possveis problemas
que o projeto est suscetvel a ter, podendo estes ser tratados com um planejamento
prvio, reduzindo as chances de defeitos com alto grau de impacto no projeto.

Gerenciamento Quantitativo - O objetivo desta rea de processo fornecer mtricas
quantitativas sobre o processo definido, visando o cumprimento de metas de desempenho
e qualidade.

Assim, tendo como referncias as avaliaes de Maral (2009), gerou-se a Tabela 3.3,
a qual mostra se o grau de atendimento do SCRUM em relao s prticas das reas de
processo.

34
rea de Processo
Meta
Especfica
Prtica Especfica Classificao
Planejamento do
Projeto (PP)
SG 1 Estabelecer
Estimativas
SP 1.1 Estimar Escopo do Projeto S
SP 1.2 Estabelecer Estimativas de Atributos de Produtos de Trabalho e Tarefas NS
SP 1.3 Definir Ciclo de Vida do Projeto S
SP 1.4 Determinar Estimativas de Esforo e Custo PS
SG 2 Desenvolver
um Plano de
Projeto
SP 2.1 Estabelecer o Oramento e o Cronograma PS
SP 2.2 Identificar Riscos do Projeto PS
SP 2.3 Planejar Gerenciamento de Dados NS
SP 2.4 Planejar Recursos do Projeto S
SP 2.5 Planejar Conhecimentos e Habilidades Necessrios S
SP 2.6 Planejar Envolvimento dos Stakeholders S
SP 2.7 Estabelecer Plano do Projeto S
SG 3 Obter
Compromisssos
com o Plano
SP 3.1 Revisar Planos que Afetam o Projeto S
SP 3.2 Equilibrar Nveis de Trabalho e Recurso S
SP 3.3 Obter Comprometimento com o Plano S
Controle e
Monitoramento do
Projeto (PMC)
SG1 Monitorar o
Projeto em
Relao ao Plano
SP 1.1 Monitorar os Parmetros de Planejamento do Projeto PS
SP 1.2 Monitorar os Compromissos S
SP 1.3 Monitorar os Riscos do Projeto PS
SP 1.4 Monitorar os Gerenciamento de Dados NS
SP 1.5 Monitorar o Envolvimento dos Stakeholders S
SP 1.6 Conduzir Revises em Progresso S
SP 1.7 Conduzir Revises em Marcos S
SG 2 Gerenciar
Aes Corretivas
at o
Encerramento
SP 2.1 Analisar Problemas S
SP 2.2 Tomar Aes Corretivas PS
SP 2.3 Gerenciar Aes Corretivas PS
Gerenciamento de
Acordos com
Fornecedores (SAM)
SG 1 Estabelecer
Acordo com
Fornecedores
SP 1.1 Determinar Tipo de Aquisio NS
SP 1.2 Escolher Fornecedores NS
SP 1.3 Estabelecer Acordos com Fornecedores NS
SG 2 Satisfazer
Acordos com
Fornecedores
SP 2.1 Executar o Acordo com o Fornecedor NS
SP 2.2 Monitorar os Processos Selecionados do Fornecedor NS
SP 2.3 Avaliar os Produtos de Trabalho Selecionados do Fornecedor NS
SP 2.4 Aceitar o Produto Adquirido NS
SP 2.5 Executar a Transio de Produtos NS
Gerenciamento
Integrado de
Projetos
(IPM+IPPD)
I
P
M

SG 1 Utilizar o
Processo Definido
do Projeto
SP 1.1 Estabelecer o Processo Definido do Projeto NS
SP 1.2 Utilizar Ativos de Processos Organizacionais para o Planejamento das Atividades do Projeto NS
SP 1.3 Estabelecer o Ambiente de Trabalho do Projeto NS
SP 1.4 Integrar os Planos NS
SP 1.5 Gerenciar o Projeto Utilizando os Planos Integrados NS
SP 1.6 Contribuir para os Ativos de Processos Organizacionais NS
SG 2 Coordenar e
Colaborar com os
Stakeholders
Relevantes
SP 2.1 Gerenciar Envolvimento dos Stakeholders S
SP 2.2 Gerenciar Dependncias PS
SP 2.3 Resolver Questes de Coordenao PS
I
P
P
D

SG 3 Aplicar os
Princpios do
Desenvolvimento
Integrado do
Produto e do
Processo
SP 3.1 Estabelecer Viso Compartilhada do Projeto S
SP 3.2 Estabelecer uma Estrutura Integrada para o Time S
SP 3.3 Alocar Requisitos para Times Integrados S
SP 3.4 Estabelecer Times Integrados S
SP 3.5 Garantir Colaborao entre as Interfaces dos Times S
Gerenciamento de
Riscos (RSK)
SG 1 Preparar o
Gerenciamento
de Riscos
SP 1.1 Determinar as Fontes e Categorias do Risco NS
SP 1.2 Determinar os Parmetros do Risco NS
SP 1.3 Estabelecer a Estratgia de Gerenciamento dos Riscos NS
SG 2 Identificar e SP 2.1 Identificar os Riscos PS
35
Analisar Riscos
SP 2.2 Avaliar, Categorizar e Priorizar Riscos NS
SG 3 Mitigar
Riscos
SP 3.1 Desenvolver Plano de Mitigao de Riscos NS
SP 3.2 Implementar Planos de Mitigao de Riscos NS
Gerenciamento
Quantitativo (QPM)
SG 1 Gerenciar
Quantitativamente
o Projeto
SP 1.1 Estabelecer Objetivos do Projeto NS
SP 1.2 Compor Processo Definido NS
SP 1.3 Escolher SubProcessos que sero Gerenciados Estatisticamente NS
SP 1.4 Gerenciar a Performance do Projeto NS
SG 2 Gerenciar
Estatisticamente
a Performance
dos
SubProcessos
SP 2.1 Selecionar as Medidas e Tcnicas Analticas NS
SP 2.2 Aplicar Mtodos Estatsticos para Entender Variao NS
SP 2.3 Monitorar Performance de SubProcessos NS
SP 2.4 Gravar Gerenciamento Estatstico dos Dados NS
Tabela 3.3 Avaliao reas de processo em relao ao Scrum (MARAL, 2009)

Em resumo, pode-se ver que h prticas da rea de Gesto de Projetos que o Scrum
no atende. Assim, sero analisadas as reas que possuem maior possibilidade de
auditoria.

Analisando este cenrio, tem-se uma base de como feita uma auditoria de processos,
o que no caso do CMMI feita respondendo as perguntas de cada rea de processo,
visando saber o nvel de conformidade com aquele tipo de auditoria e o que deve ser
melhorado.

Para realizao da auditoria de um processo Scrum com o software proposto, o auditor
ir usar o software proposto em determinadas fases do projeto, entrevistando determinadas
pessoas que fazem parte do projeto.

A avaliao pode ocorrer no momento que o auditor achar necessrio ou quando
houver evidncias suficientes para responder as questes e as pessoas so escolhidas de
acordo com o seu perfil de trabalho, visando fazer as perguntas certas s pessoas certas.

Como, por exemplo, logo na definio do Product Backlog, j possvel a avaliao
referente rea de processo Planejamento do Projeto, sendo o Scrum Master e o Time os
entrevistados.

O auditor ir usar seu dispositivo mvel para avaliar o processo, entrevistando pessoas
ligadas ao projeto em questo. Assim que completado com sucesso, estes relatrios sero
enviados ao servidor para serem processados e armazenados.

36
Ainda pelo dispositivo mvel, ser possvel recuperar algumas vises das auditorias
realizadas, tais como resultados do relatrio de Planejamento do Projeto de um projeto em
especfico.

No servidor, sero armazenados os dados no banco de dados e feito o processamento
destas informaes. Neste recurso, estar disponvel o servio de entrada de dados, para
que o dispositivo mvel os envie, e o servio de sada, para que o auditor consiga
recuperar informaes dos relatrios realizados.

Com este tipo de arquitetura pode-se prover a centralizao dos dados, facilidade na
recuperao de tais dados e da lgica usada para receber e enviar os dados, retirando do
dispositivo mvel a responsabilidade de processar os dados, uma vez que o servidor tem
uma capacidade muito superior para executar este tipo de tarefa.

Assim, conforme visto neste captulo, a ferramenta desenvolvida neste trabalho deve
ter esta caracterstica. Tal ferramenta ser melhor detalhada no captulo 4.


37
4. Proposta de Soluo

Neste captulo definida a arquitetura do software e mostrado o seu
desenvolvimento. Assim, inicia-se com a definio da arquitetura do software:

4.1. Arquitetura

O software foi desenvolvido com base em um sistema cliente/servidor, possui um
servidor que armazena e centraliza os dados, disponibilizando-os e recebendo-os dos
clientes, que no caso so os dispositivos mveis.

O servidor um Web Server Apache Tomcat v6.0, desenvolvido em JAVA, o qual
permite o envio e recebimento de mensagens dos clientes. Sua escolha se deu por ser
um projeto de cdigo aberto, que d suporte Java Servlets e Java Server Pages
(TOMCAT, 2011).

Este servidor usa o framework Hibernate (2011), da JBoss, para fazer a
persistncia e a consulta no banco de dados, o qual foi determinado o MySQL (2011)
v5. Ambas as ferramentas tambm so open source.

O cliente foi desenvolvido focando o sistema operacional Android, portanto, seu
desenvolvimento tambm foi feito na linguagem JAVA. A aplicao responsvel por
fornecer formulrios com os questionrios a serem feitos, coletar os dados da auditoria
e enviar para o servidor armazenar. Tambm possvel consultar o resultado das
auditorias feitas, em forma de grficos.

A comunicao entre o cliente e o servidor feita com o auxilio do framework
JSON (JavaScript Object Notation), o qual prover este servio via chamadas HTTP.
Este componente foi escolhido como meio de comunicao porque gera chamadas que
so facilmente interpretadas e escritas por humanos, e analisadas e geradas por
mquinas (JSON, 2011).


38
4.2. Modelagem do software: Cliente

O funcionamento da aplicao dos dispositivos clientes funciona da seguinte
maneira. As aes so iniciadas a partir de uma interao do usurio com a tela de
visualizao do dispositivo mvel. Ao requerer uma informao, a solicitao
processada na camada de processamento e enviada ao servidor na internet por uma
requisio REST ou HTTP.

Aps o envio da requisio, retornada uma mensagem, a qual pode conter dados,
mensagem de confirmao ou erro. Tais mensagens podem ter tratamentos diferentes,
porm todas sero processadas, a fim de adequ-las quela tela de visualizao
especfica e invocar aes especficas. Aps o processamento, as telas so mostradas
ao usurio em seu dispositivo mvel.

4.3. Modelagem do software: Servidor

Na aplicao servidora, as aes so realizadas a partir de uma requisio (Rest ou
HTTP) dos dispositivos clientes.
Aps o recebimento da requisio, o software vai atend-la como for necessrio,
tendo sua lgica em arquivos Java. Caso seja necessrio, a aplicao ir acessar, por
meio do framework Hibernate, o banco de dados e atender requisio da forma
necessria. Retornando ao cliente as informaes requeridas. Estas chamadas ao
servidor resultaro em objetos do tipo JSON (Javascript) e o cliente deve ter suporte a
este tipo de tecnologia, tanto para enviar requisies ao servidor quanto receber
informaes.

Assim, obtida a arquitetura mostrada na Figura 4.1.

39

Figura 4.1 Funcionamento da aplicao Servidor x Cliente

4.4. Desenvolvimento

Para o ambiente desenvolvimento de ambos os softwares, foram utilizadas as
ferramenta de desenvolvimento Eclipse (ECLIPSE, 2011) e Java Development Kit
(JDK) verso 7 (JDK, 2011), a primeira por ser uma ferramenta livre e utilizada por
diversos desenvolvedores, a segunda por fazer parte da arquitetura do Android.
Como web server foi utilizado o software Apache Tomcat verso 6.0 (APACHE,
2011), pois um software de uso gratuito, um projeto de cdigo aberto e possu todas
as funcionalidades requeridas no projeto deste trabalho.

Como plataforma do dispositivo cliente foi utilizado o Android SDK verso 2.2
(ANDROID, 2011), pois a verso do dispositivo disponvel para testes.

Foi utilizado, tambm, o padro de projeto Model-View-Controller (FREEMAN,
2007) para obter maior facilidade na manuteno dos softwares e para seguir o padro
de desenvolvimento de software usado no Android.

40

4.5. Ambiente Avaliado

Inicialmente descreve-se o projeto que ser avaliado, informando suas
caractersticas principais. Em seguida, mostra-se uma forma de avaliar o processo,
apontando cada momento onde determinado relatrio deve ser aplicado.

Define-se o ambiente avaliado com as seguintes caractersticas:
A avaliao ter o objetivo de atacar apenas o processo de Gerncia de
Projetos, visando melhoria deste processo em especfico;
ser avaliado seguindo a Representao Contnua do CMMI (WEBER,
2004);
estar em transio do nvel 1 de capacidade (Executado) para o nvel 2
de capacidade (Gerenciado);
ser utilizada a metodologia de desenvolvimento de software SCRUM no
processo avaliado.

Deseja-se alcanar um nvel de capacidade melhor no processo de Gerncia de
Projetos, sendo este processo considerado o ponto "problemtico" da organizao.
Portanto, a estratgia adotada pela empresa para diminuir as perdas com o processo
audit-lo e melhorar seus pontos falhos atravs das prticas do CMMI.

Estando o ambiente no nvel 1 de capacidade do CMMI, ele pode ser
caracterizado como um processo executado. Ou seja, o processo executa as metas
especficas da rea de processo.

Para que o processo alcance o nvel 2 de capacidade do CMMI, deve-se atender,
tambm, s metas genricas dos nveis anteriores ao que se deseja, que so
compostas pelas prticas genricas, como mostra a Figura 4.2.


41

Figura 4.2 Metas necessrias para atingir o nvel de capacidade 2

Portanto, como se espera atingir o nvel 2 de capacidade, o ambiente possui as
caractersticas para atender as metas especficas e meta genrica 1 das reas de
Processo referentes Gesto de Projeto.

Neste estudo ser adotada a rea de Processo Planejamento de Projeto.

O ambiente dever executar as metas a seguir.

A meta Estabelecer Estimativas do projeto define parmetros de planejamento do
projeto a fim de se obter maior previsibilidade do projeto. Meta a qual atingida:
Executando a prtica Estimar o Escopo do Projeto, a qual consiste em estimar
esforo e prazo e distribuir as responsabilidades do projeto;
outra prtica executada Estabelecer Estimativas para Atributos de Trabalho e
de Tarefas, sendo que para ser executada deve estabelecer estimativas, como
por exemplo, nmero de funes ou de classes e objetos, para produtos de
trabalho como itens entregveis e no entregveis;
h, tambm, a prtica Definir Ciclo de Vida do Projeto, consiste em determinar
o ciclo de vida do projeto onde, normalmente, so definidos para apoiar pontos
de deciso;
42
por ltimo, deve ser executada a prtica Determinar Estimativas de Esforo e
Custo, consistindo em calcular tais estimativas com base histrica associando,
tambm, o tamanho do projeto.

Executando as atividades estipuladas acima, pode-se considerar que esta meta
esta sendo atingida pelo processo.

A meta especfica Elaborar um Plano de Projeto consiste na elaborao de um
plano de projeto que dever ser seguido por todos os envolvidos no projeto. Tal meta
atendida:
Ao estabelecer e manter um cronograma do projeto e o oramento,
identificando e analisando os riscos do projeto, planejando a gesto dos dados
referente aos projetos executados;
esta meta ainda requer a execuo da prtica planejar recursos do projeto como
mo-de-obra, maquinrio, materiais e etc. Assim como deve se planejar as
habilidades e conhecimentos necessrios para a execuo do projeto a fim de
tornar as pessoas envolvidas hbeis para executar as tarefas designadas a elas;
por ltimo, esta meta requer planejar o envolvimento das partes interessadas
durante o ciclo de vida do projeto e estabelecer o plano do projeto
documentando-o de forma a ser seguido por todos os projetos.

Assim, atende-se a meta especfica Elaborar um Plano de Projeto.

A ltima meta especfica, Obter Comprometimento com o Plano definido tendo
esta o objetivo de obter entendimento e comprometimento de todos os envolvidos. A
meta consiste em:
Revisar os planos que afetam o projeto, com o objetivo de assegurar um
entendimento comum do escopo, objetivos, papis e responsabilidades
importantes para sucesso do projeto;
Conciliar carga de trabalho e recursos, obtido por meio de estratgia para
atender os requisitos do projeto;
E obter o comprometimento com o plano estipulado, obtendo a interao entre
as partes interessadas relevantes internas e externas.
43

Executando, assim, a meta especfica Obter Comprometimento com o Plano.

Em seguida, deve-se atender a meta genrica 1 para obter o nvel 1 de capacidade.
Tendo, esta, o objetivo de Satisfazer as Metas Especficas da rea de processo. E
nesta meta genrica, faz-se necessria a execuo da prtica Executar Prticas
Especficas.

Tais atividades j foram previamente executadas, podendo considerar que a rea
de processo est sendo atendida em nvel 1 de capacidade no processo.

O nvel 2 de capacidade possui como meta Institucionalizar um Processo
Gerenciado, o qual possui as prticas:
Estabelecer uma Poltica Organizacional estabelecendo uma expectativa da
organizao em relao aos parmetros estimados para o planejamento do
projeto;
Planejar o Processo estabelecendo um mtodo planejado para que seja
executado o planejamento do projeto estipulado;
Fornecer Recursos provendo os recursos necessrios para que o processo de
planejamento do projeto possa ser executado, os quais podem ser pessoas
especializadas ou recurso eletrnico para executar alguma tarefa;
Atribuir Responsabilidades definindo que so os responsveis por cada
atividade do planejamento do projeto e autoridade suficiente para que as
atividades sejam executadas sem problemas;
Treinar Pessoas treinamento de pessoas para que possam executar as
atividades do planejamento do projeto. Exemplos de treinamento so
elaborao de estimativas, gesto de dados e etc;
Gerenciar Configuraes controlando, conforme sua criticidade, os produtos
do trabalho de planejamento do projeto;
Identificar e Envolver as Partes Interessadas Relevantes identificando e
envolvendo todas as partes relacionadas as atividades de planejamento do
projeto. Exemplos de atividade so estabelecimento do plano de projeto,
44
reviso dos planos envolvidos com o projeto, planejamento de carga de
trabalho e recursos utilizados no projeto e etc.;
Monitorar e Controlar o Processo monitorando e controlando o processo de
planejamento do projeto em relao ao plano estabelecido para execuo do
processo, identificando pontos problemticos para posteriores melhorias no
processo;
Avaliar Objetivamente a Aderncia de acordo com os objetivos definidos,
avaliar a aderncia do processo, identificando pontos falhos e tratando-os;
Revisar Status com a Gerncia de Nvel Superior junto gerncia de nvel
superior, revisar as atividades e os resultados coletados no planejamento do
projeto, a fim de tratar situaes crticas ou problemas no processo.

Nos captulos a seguir sero mostradas duas avaliaes, com o objetivo de atingir
o nvel 2 de capacidade CMMI, sendo uma por um mtodo convencional e a outra
pelo mtodo desenvolvido neste trabalho.

4.6. Aplicao do Mtodo Desenvolvido

A avaliao por este mtodo possui as caractersticas desenvolvidas e j citadas
neste trabalho.

Algumas telas podem ser vistas na Figura 4.3 que mostra a interface inicial do
software, Figura 4.4 que mostra a escolha do formulrio que ser aplicado e Figura
4.5 que mostra o formulrio para preenchimento e envio dos dados coletados.
45

Figura 4.3 Tela inicial do software


Figura 4.4 Tela para escolha de formulrio de auditoria

46

Figura 4.5 Tela do formlrio de auditoria escolhido

Tendo todos os formulrios no dispositivo mvel, o auditor pode acompanhar o
processo SCRUM para coletar as informaes sobre o processo. Porm, como foi
visto, os formulrios so separados por metas, conforme Figura 4.4.

Assim, cada formulrio deve ser aplicado um momento especfico no processo
SCRUM. Momentos os quais so mostrados na Figura 4.6, tendo como exemplo o
formulrio Estabelecer Estimativas (Figura 4.5) sendo aplicado no momento do
Backlog do Produto (Figura 4.6).

47

Figura 4.6 Processo Scrum com reas onde cada um dos formulrios aplicado

Como se pode ver, cada meta estipulada para um momento, porm algumas
informaes podem ser coletadas antes, e outras, depois.

Com os definidos momentos, o auditor pode acompanhar o processo de execuo
do projeto, audit-lo mais que uma vez em determinada meta, podendo obter mais
dados sobre o processo avaliado.

48
5. Aplicao do Conceito no Ambiente

Este captulo apresenta uma aplicao prtica dos conceitos citados no captulo 4.
Tambm mostrar um ambiente convencional baseado no ambiente escolhido no captulo
4.


5.1. Aplicao pelo Mtodo Proposto

O projeto avaliado teve seus requisitos divididos em 3 Sprints, as quais tm
durao de duas semanas, pois o menor tempo de Sprint recomendvel ao processo
SCRUM e, assim, pode-se rapidamente gerar valor ao produto final. Alm disto, foi
definido que o time ser composto por dois Product Owners, um Scrum Master,
quatro desenvolvedores, trs testadores e um analista de sistemas.

Como o ambiente avaliado um ambiente terico, o mtodo proposto foi aplicado
apenas conceitualmente, pois no h como se ter um ambiente propcio aplicar o
mtodo na prtica, baseando-se em experincias e opinies dos auditores
entrevistados.

O relatrio escolhido para avaliao foi o Estabelecer Estimativas. Onde, para
cada prtica, foram elencadas algumas pessoas para responder sobre a prtica.

A prtica Estimar Escopo do Projeto dever ser respondida pelo Product Owner,
pois esta a pessoa que ir definir e manter os requisitos do produto e suas
prioridades. Alm dele, o prprio time de desenvolvimento pode responder esta
prtica, pois tm contato direto com os requisitos e a conexo entre os entregveis.

A prtica Estabelecer Estimativas de Atributos de Produtos de Trabalhos e
Tarefas consegue ser respondida pelo time desenvolvedor (com ajuda do Product
Owner em alguns casos). Pois, o time que estimar os atributos do produto
desenvolvido, como complexidade, nmero de funes, complexidade e quantidade
de interfaces e etc.
49

O ScrumMaster pode responder sobre a prtica Definir Ciclo de Vida do Projeto.
Pois, junto ao time de desenvolvedores, ir definir as fases do projeto e dever
garantir que o ciclo de vida de uma processo Scrum esteja sendo executado.

Finalmente, Determinar Estimativas de Esforo e Custo de responsabilidade do
time desenvolvedor, pois os prprios iro determinar as estimativas para cada um dos
Sprints, com base em conhecimentos adquiridos em trabalhos anteriores.

Portanto, aplicando o relatrio para as pessoas corretas, espera-se que atinja a
margem de 20 minutos para realizao da avaliao, contendo desde a entrevista at
a demonstrao das evidncias.

5.2. Mtodo Convencional

Neste trabalho, entende-se por mtodo convencional como um processo de
auditoria feito, em maior parte, manualmente. Assim, tanto a coleta dos dados quanto
os relatrios e grficos devem ser feitos por pessoas sem quase nenhuma automao
no processo.

Este processo servir de comparao para o mtodo proposto.

A avaliao por este mtodo definido pelas caractersticas:
realizado por formulrios impressos;
Os formulrios so preenchidos caneta, a fim de evitar alteraes
posteriores;
Os dados so transferidos dos formulrios para planilhas digitais em um
diretrio de armazenamento;
Tais planilhas seguem o padro <projeto>_<rea de
processo>_<aaaammdd>.<extenso>. Ex.: Projeto1_PlanejamentoProjeto
_20111201.xlsx.

50
Assim, para que o processo de Gesto de Projeto seja avaliado, conforme este
mtodo, so necessrios os formulrios tanto das metas j cumpridas quanto das
metas objetivas.

Tais formulrios podem so vistos nas Figuras 5.2 e foram avaliados por um
auditor com 6 anos de experincia em auditoria de processos, sendo considerados
efetivos para o objetivo proposto.
51

52

Figura 5.2 Formulrios de auditoria impressas

Uma vez tendo os formulrios em mos, o auditor pode acompanhar o processo
Scrum e audit-lo em pontos previamente definidos para obter um padro nas
auditorias realizadas. Tais formulrio so distribudos em quatro momentos, sendo
eles A, B, C e D.

No ponto A, executam-se as prticas:
Estimar Escopo do Projeto.
Estabelecer Oramento e Cronograma.
Planejar Recursos do Projeto.
Planejar Conhecimentos e Habilidades Necessrios.
Estabelecer uma Poltica Organizacional.
Planejar o Processo.
53
Atribuir Responsabilidades.
Treinar Pessoas.

No ponto B, indica-se executar as prticas:
Estabelecer Estimativas de Atributos de Produtos de Trabalho e Tarefas.
Definir Ciclo de Vida do Projeto.
Determinar Estimativas de Esforo e Custo.
Planejar Gerenciamento de Dados.
Planejar Envolvimento dos Stakeholders.
Estabelecer Plano do Projeto.
Equilibrar Nveis de Trabalho e Recurso.
Obter Comprometimento com o Plano.
Fornecer Recursos.
Gerenciar Configuraes.
Identificar e Envolver as Partes Interessadas Relevantes.

No ponto C, define-se a execuo das prticas:
Revisar Planos que Afetam o Projeto.
Monitorar e Controlar o Processo.
Avaliar Objetivamente a Aderncia.
Revisar Status com a Gerncia de Nvel Superior.

No ponto D, executa-se a prtica:
Identificar Riscos do Projeto.

Assim, os pontos so distribudos, no processo SCRUM, da maneira mostrada na
Figura 5.3.
54

Figura 5.3 Processo SCRUM com os pontos de coleta de dados indicados

O ponto A realizado no momento do Product Backlog, pois as perguntas feitas
nas prticas deste ponto podem ser respondidas com bons fundamentos neste
momento. Neste ponto pode-se encontrar boa parte dos planejamentos sendo
executados no projeto, como determinar o escopo do projeto e, com base no escopo,
definir os recursos necessrios para a execuo.

No Sprint Backlog realizado o ponto B, pois o momento onde so atendidas
algumas prticas como o estabelecimento das tarefas, estimativas de custo e
previses de esforo que ser realizado. Neste momento tambm so definidos os
momentos de interao entre a equipe desenvolvedora e os stakeholders.

Realiza-se o ponto C aps o Sprint terminar, momento o qual feito uma reviso
da Sprint, visando avaliar possveis problemas ocorridos durante a Sprint, revisar
prticas que podem impactar no processo e etc.

O ponto D realizado durante o Daily Meeting, pois os riscos do projeto podem
ser identificados durante o Sprint e reportados durante o Daily Meeting.
55

Assim, nos momentos da Figura 5.3, a auditoria pode ser realizada com o uso dos
formulrios da Figura 5.2, coletando os dados do processo para inserir nas planilhas
digitais. Os dados coletados podem ser, posteriormente, analisados para apoiar
tomadas de deciso e planos de aes.

56
6. Anlise de Resultados

O principal objetivo deste trabalho desenvolver um software para dispositivo mvel
que permita realizar auditoria de processo. A disponibilidade deste software facilitar o
processo de realizar auditoria, centralizando e garantindo a integridade dos dados.

Em relao ao mtodo convencional, se obtm os resultados a seguir.

Por ser realizado com formulrios impressos, qualquer alterao deve ser reportada a
todos os auditores da organizao na tentativa de no haver divergncias entre as verses
que cada um dos auditores esto usando para realizar as auditorias. Caso haja uma
mudana muito significativa em algum dos formulrios e um auditor use um formulrio
depreciado, pode haver um problema de entendimento ou coleta errnea de dados. Porm,
pode-se facilmente alterar um formulrio para se adequar ao processo ou increment-lo
com novas perguntas. O auditor dever ter uma lista completa dos funcionrios
relacionados ao projeto auditado e seus cargos.

Por se tratar de formulrio impresso, o auditor dever escrever as observaes,
portanto a escrita deve ser clara, para que no haja entendimento ruim no momento em
que os resultados forem passados para a planilha de digital. Isto pode ocasionar um
aumento no tempo de realizao da auditoria tanto por conta de ser escrito quanto por ter
que repassar todas as informaes coletadas para a planilha digital.

Conforme o padro de controle das planilhas digitais, devese ter todos os dados para
que se possa analisar o processo com mais preciso. Sendo, ento, que se faz necessria a
execuo completa do processo do projeto para que se tenha dados para avaliao e
tomada de ao.

Os formulrios podem ser facilmente adaptados ao processo da organizao, tendo a
disposio das perguntas da forma que o auditor achar melhor para realizar sua tarefa.

As informaes estaro separas em planilhas diferentes, o que dificulta o controle das
informaes e a centralizao dos dados. Para obteno de relatrios, grficos ou escritos,
57
dever coletar os dados das planilhas de acordo com o tipo e os filtros requeridos no
relatrio.

Foi realizado um teste prtico da aplicao dos relatrios no ponto C do processo de
desenvolvimento, desconsiderando o tempo de entrevista, pois este tempo o mesmo para
qualquer mtodo. Ento, identificou-se que:
Para execuo do formulrio no momento do processo levou-se cerca de 28
minutos para escrever as informaes no formulrio, tomando-se cuidado para
no rasurar a folha;
Se a observao requerer muitas palavras, e isto no foi previsto, haver um
problema de tamanho da linha para escrever a observao;
Demandaram-se aproximadamente 14 minutos para criao da planilha digital
(para o formulrio usado anteriormente) e insero dos dados na planilha.

Apenas aps a execuo das atividades citadas acima, os dados foram disponibilizados
para avaliao.

Em relao ao software desenvolvido neste trabalho, pode-se obter os seguintes
resultados.

Os formulrios digitais recuperam informaes dos projetos disponveis para auditoria,
uma lista de auditores para escolha e uma lista de usurios para que se escolha a pessoa
que ser auditada, assim, no tendo a necessidade de se ter uma lista dos funcionrios da
organizao.

possvel adequar os relatrios ao processo da empresa tanto quanto necessrio,
baseando-se nas perguntas relevantes no momento escolhido. Porm, caso haja a
necessidade de alterao de algum dos formulrios, haver a necessidade de realizar as
modificaes significativas de programao e visualizao dos formulrios no software.
Esta modificao, apesar de simples, necessita de horas de trabalho para pequenas
alteraes.

O preenchimento do formulrio bem simples e o tempo de digitao varia de acordo
com a habilidade do auditor e a afinidade com teclado utilizado (fsico ou digital). No
58
formulrio digital no h como rasurar o relatrio e no haveria problema se ocorrer um
erro na digitao, pois pode excluda antes do envio para o repositrio de respostas no
servidor.

As informaes das auditorias estaro armazenadas em um repositrio digital nico, o
que facilitar a realizao de cpias de segurana dos dados e haver menos dificuldades
em control-los.

Para a criao de grficos e relatrios das auditorias h a necessidade de programao
de acordo com a necessidade do solicitante. Porm, com a centralizao dos dados, uma
vez o relatrio pronto, basta alterar os filtros e obter os relatrios ou grficos necessrios.

A anlise e tomada de deciso baseada nos dados torna-se mais rpida, pois, a os
dados estaro disponveis assim que as informaes forem enviadas ao servidor pelo
dispositivo mvel do auditor, possibilitando que se faa corretivas no processo.

Foi realizado um teste prtico da aplicao dos relatrios Estabelecer Estimativas do
processo de desenvolvimento, tambm desconsiderando o tempo de entrevista, pois este
tempo o mesmo para qualquer mtodo. Ento, identificou-se que:
Para execuo do formulrio no momento do processo levou-se cerca de 20
minutos para digitar as informaes no formulrio;
Apesar de poder limitar a quantia de caracteres no campo de observao, este no
tem um mximo no software desenvolvido.

Aps enviado o relatrio, os dados j estaro disponveis para avaliao.

Assim, foram apresentados os resultados coletados dos dois mtodos de auditoria
descritos neste trabalho.

59
7. Consideraes Finais

O presente trabalho procurou desenvolver um software que auxilie nas auditorias de
processo de TI, oferecendo maior mobilidade e facilidades tanto ao auditor quanto s
pessoas que necessitam dos relatrios e grficos sobre o processo. Foram descritas as
principais caractersticas da plataforma Android e ferramentas e mtodos de programao
para dispositivos mveis para que fosse criada uma aplicao real. Portanto, este
documento ser til a quem se interesse por desenvolvimento de aplicaes mveis e
quem se interesse em auditoria de processos de TI.

Pode-se concluir que, de acordo com os resultados obtidos neste trabalho, com o
mtodo desenvolvido:
Foi concebido utilizando dispositivos mveis;
foi desenvolvido um software cliente/servidor que propicia a utilizao dos
dispositivos mveis para a aplicao da avaliao;
possvel coletar mais informaes do processo pelo mtodo desenvolvido, pois,
pode-se aplicar os formulrios da avaliao tanto quanto possvel, de acordo com o
formulrio em questo;
prov maior facilidade ao auditor, em relao ao mtodo convencional, pois h a
recuperao automtica de informaes necessrias na auditoria, alm de um
formulrio utilizado por todos os outros auditores da empresa;
os dados coletados na auditoria esto, no momento que enviados ao servidor,
disponveis para avaliao tanto grfica quanto por relatrios, o que permite tomar
decises mais rapidamente;
com o maior nmero de coleta de informaes, pode-se avaliar se a ao tomada
foi efetiva, mesmo durante a execuo de um projeto.
demanda-se mais tempo para realizar a auditoria pelo mtodo convencional do que
pelo mtodo desenvolvido neste trabalho;
a criao de relatrios pelo mtodo proposto, apesar de mais lento e complicado
em relao ao convencional, permite reuso com aplicao de filtros.

Dois possveis usurios foram entrevistados sobre a utilidade e interesse da aplicao.
O retorno obtido foi que, apesar da ferramenta no ter sido implantada em nenhum
60
ambiente real de produo de projetos de TI, pode ser bem til para empresas que buscam
a certificao CMMI, tendo uma boa avaliao sobre a utilidade do software. Em
contrapartida, pode ser algo dispensvel a empresas pequenas.

importante salientar que, mesmo obtendo-se dados mtricos sobre o tempo de
realizao da auditoria, pode haver pessoas que no se adaptem a este tipo de mtodo
proposto. Assim, o tempo de execuo pode aumentar.

A realizao deste trabalho possibilitou o aprendizado na plataforma Android, na
arquitetura de dispositivos mveis e auditoria de processos. Alm disto, foram assimilados
conceitos importantes como sistema orientado a servios, web services REST e arquitetura
de sistemas cliente/servidor.

Finalizando, sugerem-se como trabalhos futuros:
A implantao deste mtodo em uma grande empresa e em uma pequena empresa,
a fim de comparar o tempo de execuo, o custo desta implantao e o impacto
gerado;
aplicao em outro ambiente que no utilize SCRUM;
adaptao para outros tipos de auditoria;
desenvolver o software para outras plataformas mveis;
desenvolver o sistema com sincronismo com o servidor, podendo realizar as
auditorias off-line.
61
8. Referncias Bibliogrficas

ACKER, Eduardo, V.; Weber, Taisy, S.; Cechin, Srgio, L. Injeo de Falhas para Validar
Aplicaes em Ambientes Mveis. Universidade Federal do Rio Grande do Sul, 11, 2010,
Porto Alegre, Rio Grande do Sul. XI Workshop de Testes e Tolerncia a Falhas. Porto
Alegre: Universidade Federal do Rio Grande do Sul, 2010. p. 61 - 74.

AKAIWA, Yoshihiko. Introduction to Digital Mobile Communication. 1st. ed. Canada:
Wiley-Interscience, 1997. ISBN 0471175455.

ANACLETO, Alessandra. Mtodo e Modelo de Avaliao para Melhoria de Processos de
Software em Micro e Pequenas Empresas. 2004. 174f. Mestre em Cincia da Computao
- Universidade Federal de Santa Catarina, Florianpolis, 2004.

ANDROID. Android 2.2 Plataform. Disponvel em:
<http://developer.android.com/sdk/android-2.2.html>. Acesso em 24 de outubro de 2011.

APACHE. Apache Tomcat. Disponvel em: <http://tomcat.apache.org/>. Acesso em 24 de
outubro de 2011.

ATTIE, William. Auditoria: conceitos e aplicaes. 5th. ed. So Paulo: Atlas, 2010. ISBN
9788522458868.

CRUZ, Bruno H. A.; Agnese, Josu F. D.; Fagundes, Bruno J.; Bastos, Marcelo T.; Molz,
Rolf F.; Schreiber, Jacques N. C. Desenvolvimento de uma aplicao embarcada em
celular visando controle de rob via Wi-Fi. In: Revista Brasileira de Computao
Aplicada. ISSN 2176-6649. Passo Fundo, p. 43-52, 2011.

DEV GUIDE: What is Android?. 2011. Disponvel em:
<http://developer.android.com/guide/basics/what-is-android.html>. Acesso em: 28 de
maro de 2011.

62
ECLIPSE. About the Eclipse Foundation. Disponvel em : <http://www.eclipse.org/org/>.
Acesso de 24 de outubro de 2011.

FILHO, Humberto Ferreira Ori. As fraudes contra as organizaes e o papel da auditoria
interna. 1st. ed. So Paulo: Sicurezza, 2011. ISBN 9788587297433.

FREEMAN, Eric. Freeman, Elisabeth. Use a Cabea: Padres de Projeto segunda edio.
Alta Books, 2007. ISBN 9788576081746.

FROLIK, Jeff; Zurn, J. Brooks; Evaluation of Tablet PCs for Engineering Content
Development and Instruction. In: UNIVERSITY OF VERMONT, 2004, Proceedings of
the 2004 American Society for Engineering Education Annual Conference & Exposition.
Vermont.

HANASHIRO, Mara. Metodologia para Desenvolvimento de Procedimentos e
Planejamento de Auditorias de TI Aplicada Administrao Pblica Federal. 2007. 168f.
Universidade de Braslia, Braslia, 2007.

HIBERNATE. Overview. Disponvel em: <http://www.hibernate.org>. Acesso em 06 de
setembro de 2011.

ITGI, IT Governance Institute. COBIT 4.1. 2007. Disponvel em < www.itgi.org >.
Acesso em 12 de abril de 2011.

ITU - Internation Telecommunication Union < http://www.itu.int >. Acesso em 02 de
maro 2011.

JDK. Read Me. Disponvel em: <http://www.oracle.com/technetwork/java/javase/jdk-7-
readme-429198.html>. Acesso em 24 de outubro de 2011.

JSON, Introducing JSON. Disponvel em: <http://www.json.org>. Acesso em 04 de
agosto de 2011.

63
LOPES, Sheron M. de C.; Andr, Valesca G.; Neves, Jos M. S. das; Governana de TI -
um estudo sobre ITIL e COBIT. In: Simpsio de Excelncia em Gesto e Tecnologia (VII
SEGeT), 7, 2010, So Paulo.

MARAL, Ana S. C. et al. Estendendo o SCRUM segundo as reas de Processo de
Gerenciamento de Projetos do CMMI. CLEI 2007: XXXIII Conferencia Latinoamericana
de Informtica, San Jose, Costa Rica, 2007b.

MARAL, Ana S. C. et al. Mapping CMMI Project Management Process Areas to
SCRUM Practices. 31st Annual Software Engineering Workshop, Loyola College,
Baltimore, MD, USA, 2007a.

MARAL, Ana S. C. SCRUMMI: Um processo de gesto gil baseado no SCRUM e
aderente ao CMMI. 2009. 205 f. Mestrado em Informtica Aplicada - Universidade
Fundao Edson Queiroz, Fortaleza, 2009.

MARTINS, Rafael J. W. de A. Desenvolvimento de Aplicativo para Smartphone com a
Plataforma Android. 2009. 50 f. Graduao em Engenharia de Computao - Pontifica
Universidade Catlica do Rio de Janeiro, Rio de Janeiro. 2009.

MYSQL. Why MySQL? Disponvel em: <http://www.mysql.com/why-mysql>. Acesso
em 06 de setembro de 2011.

NIELSEN: Vendas de smartphones crescem 128% no pas, aponta estudo da Nielsen.
2010. <http://br.nielsen.com/news/vendas_smartphones.shtml>. Acesso em 02 de maro
2011.

OHA, Open Handset Alliance. Disponvel em <http://www.openhandsetalliance.com>.
Acesso em: 03 de maro de 2011.

PAMPONET, Arnaud Velloso. Auditoria Interna de Processos. 2009. Disponvel em:
<www.portaldeauditoria.com.br>. Acesso em 09 de novembro de 2011.

64
SANTANDER, Alexandre S.; Krger, Gustavo R.; Guimares, Yuri R. Mapeando o
Scrum em Relao ao CMMI - Nveis 2 e 3. III EPAC - Encontro Paranaense de
Computao, Cascavel , Paran, 2009.

SCHWABER, K. Agile Project Management with Scrum, Microsoft, 2004.
SCHWABER, Ken; Sutherland, Jeff. Scrum.
<http://www.scrum.org/storage/scrumguides/Scrum%20Guide.pdf>, 2010. Acesso em 11
de junho de 2011.

CMU, Software Enginering Institute: CMMI. <http://www.sei.cmu.edu/cmmi> Acesso em
29 de maro de 2011.

SEI. Software Engineering Institute. CMMI-DEV: CMMI for Development. V1.2 model,
CMU/SEL-2006-TR-008. Disponvel em: <http://www.sei.cmu.edu/cmmi/general>.
Acesso em 20 de julho de 2011.

SHOJAEE, Hamid. Scrum Master in Under 10 Minutes
<http://www.youtube.com/watch?v=Q5k7a9YEoUI>. Acesso em 21 de maio de 2011.

SORTICA, Eduardo A.; Clementi, Srgio.; CARVALHO, Tereza C. M. B. Governana de
TI: uma empresa virtual analisada sob a tica do COBIT e do ITIL. In: Congresso Anual
de Tecnologia da Informao (CATI), 2004, So Paulo. 2004.

TOMCAT, Apache. Apache Tomcat. Disponvel em: <http://tomcat.apache.org>. Acesso
em 06 de setembro de 2011.

TONON, Uliton S. "Medic Mobile" Aplicao Mvel para Acesso Remoto de Dados
Clnicos de Pacientes Hospitalizados. 2006. 62 f. Graduao de Engenharia Eltrica -
Universidade Federal do Esprito Santo, Vitria. 2006.


65
WEBER, Kival C.; Rocha, Ana R.; Alves, ngela; Ayala, Arnaldo M.; Gonalves,
Austregsilo; Paret, Benito; Salviano, Clnio; Machado, Cristina F.; Scalet, Danilo; Petit,
Djalma; Arajo, Eratstenes; Barroso, Mrcio G.; Oliveira, Kathia; Oliveira, Luiz Carlos
A.; Amaral, Mrcio P.; Campelo, Renata Endriss C.; Maciel, Teresa. Modelo de
Referncia para Melhoria de Processo de Software: uma abordagem brasileira. In: XXX
Conferencia Latinoamericana de Informatica (CLEI2004), Arequipa Peru, 30., 2004.

ZANATTA, Alexandre L. Vilain, Patrcia. Uma anlise do mtodo gil Scrum conforme
abordagem nas reas de processo Gerenciamento e Desenvolvimento de Requisitos do
CMMI. In: VII Workshop em Engenharia de Requisitos, 2005, Porto. Procedings of
WER05. Porto - Portugal, 2005. p. 209-220.