FACULDADE DE TECNOLOGIA DE SÃO JOSÉ DOS CAMPOS
FATEC PROFESSOR JESSEN VIDAL
THIAGO FEITOZA DE OLIVEIRA
DESENVOLVIMENTO DE APLICAÇÃO PARA AUDITORIA DE PROCESSOS
EMPRESARIAIS PARA DISPOSITIVOS MÓVEIS
São José dos Campos
2011
2
THIAGO FEITOZA DE OLIVEIRA
DESENVOLVIMENTO DE APLICAÇÃO PARA AUDITORIA DE PROCESSOS
EMPRESARIAIS PARA DISPOSITIVOS MÓVEIS
Trabalho
de
Graduação
apresentado
à
Faculdade de Tecnologia São José dos
Campos, como parte dos requisitos necessários
para a obtenção do título de Tecnólogo em
Informática com Ênfase em Banco de Dados.
Orientador: Prof. Eduardo Sakaue
São José dos Campos
2011
3
THIAGO FEITOZA DE OLIVEIRA
DESENVOLVIMENTO DE APLICAÇÃO PARA AUDITORIA DE PROCESSOS
EMPRESARIAIS PARA DISPOSITIVOS MÓVEIS
Trabalho de conclusão de curso apresentado à
Faculdade de Tecnologia
de São José dos
Campos, como parte dos requisitos necessários
para a obtenção do título de Tecnólogo em
Informática com Ênfase em Banco de Dados.
_______________________________________________________________________
Mestre Prof. Giuliano Araújo Bertoti
______________________________________________________________________
Doutora Prof. Silvia Cristina Sardela Bianchi
______________________________________________________________________
Mestre Prof. Eduardo Sakaue
_____/_____/_____
DATA DE APROVAÇÃO
4
Ficha Catalográfica
Oliveira, Thiago Feitoza.
Desenvolvimento de Aplicação para Auditoria de
Processos Empresariais para Dispositivos Móveis / Thiago
Feitoza de Oliveira – São José dos Campos, 2011.
65f. : il.
Monografia (Curso Superior de Tecnologia em
Informática) – Faculdade de Tecnologia de São José dos
Campos
1. Desenvolvimento de Aplicação. 2. Auditoria de
Processos. 3. Dispositivos Móveis. I. Título
5
Dedico este trabalho aos meus pais,
sem os quais eu não teria tido
forças para chegar onde estou.
6
AGRADECIMENTOS
Aos meus pais, irmão e namorada pelo apoio e compreensão.
A meu orientador Eduardo Sakaue por toda a ajuda e paciência e por seus ensinamentos.
Aos meus colegas de trabalho que contribuíram com idéias, opiniões e pela motivação.
Aos professores da Faculdade de Tecnologia de São José dos Campos, pois, sem os quais, não
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 método de melhoria de
processos, visando propor uma solução que torna esta tarefa mais fácil, rápida e com
resultados em menor tempo.
O estudo envolve a análise do conceito e dos objetivos de auditoria de processos e do
CMMI, mostrando o que é requerido para atingir as metas, executar as práticas, e revelando
melhorias ao processo.
Em seguida, foi estudado a metodologia de desenvolvimento de software SCRUM, a fim
de elencar os papéis e responsabilidades de cada membro de um projeto, seu ciclo de
desenvolvimento e suas fases.
Analisou-se, também, um trabalho onde um processo SCRUM já havia sido avaliado por
um questionário CMMI. Assim, identificou-se pontos fortes e fracos do método de
desenvolvimento em relação à avaliação.
Assim, com o contexto do ambiente avaliado, propôs-se um software para simplificar esta
atividade, sendo tal software desenvolvido com base em tecnologia móvel.
Após o desenvolvimento, o ambiente foi avaliado pelo método proposto e por um método
convencional, a fim de compará-los quanto à suas vantagens.
Palavras-chave: dispositivos, móveis, CMMI, SCRUM, auditoria, avaliação, 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.
Introdução ....................................................................................................... 11
1.1.
1.2.
1.3.
1.4.
2.
Motivação ........................................................................................................ 11
Objetivos ......................................................................................................... 13
Metodologia..................................................................................................... 13
Organização .................................................................................................... 14
Fundamentação Teórica ................................................................................. 15
2.1.
2.2.
2.3.
2.3.1.
2.3.2.
2.4.
3.
Comunicação Móvel........................................................................................ 15
O Android ....................................................................................................... 18
Auditoria de Processos.................................................................................... 22
Conceitos de Auditoria ................................................................................... 22
CMMI.............................................................................................................. 23
SCRUM ........................................................................................................... 26
SCRUM + CMMI ........................................................................................... 31
3.1.
3.2.
3.3.
3.4.
3.5.
3.6.
4.
Planejamento do Projeto ................................................................................ 33
Controle e Monitoramento do Projeto ........................................................... 33
Gerenciamento de Acordo com Fornecedores ............................................... 33
Gerenciamento Integrado de Projeto ............................................................. 33
Gerenciamento de Riscos ................................................................................ 33
Gerenciamento Quantitativo .......................................................................... 33
Proposta de Solução ........................................................................................ 37
4.1.
4.2.
4.4.
4.5.
Arquitetura ..................................................................................................... 37
Modelagem do software: Cliente .................................................................... 38
Desenvolvimento ............................................................................................. 39
Ambiente Avaliado ......................................................................................... 40
4.6.
Aplicação do Método Desenvolvido ................................................................ 44
5.
Aplicação do Conceito no Ambiente .............................................................. 48
5.1.
5.2.
6.
Aplicação pelo Método Proposto .................................................................... 48
Método Convencional ..................................................................................... 49
Análise de Resultados ..................................................................................... 56
7.
Considerações Finais ...................................................................................... 59
8.
Referências Bibliográficas .............................................................................. 61
11
1. Introdução
1.1. Motivação
Dispositivos móveis estão cada vez mais presentes em nossas vidas, contudo, seu
objetivo de uso está sendo alterado, tendo a atenção dividida entre funcionalidades de
ligações telefônicas, acesso à internet, jogos, aplicativos auxiliares e etc. Em suma, os
mobiles estão sendo utilizados para simplificar atividades do dia-a-dia.
Conforme a International Telecommunication Union (ITU, 2011), há um crescimento
global de cerca de 650 milhões de novas assinaturas de celulares por ano, sendo em 2010,
estimados pouco mais de 5 bilhões de celulares, como mostra a Figura 1.1.
Figura 1.1 Gráfico do crescimento global anual de assinaturas de celulares (ITU, 2011)
Em âmbito nacional, o Brasil teve grande crescimento na área de telefonia móvel nos
últimos anos, tendo um crescimento mais de 50 milhões de assinaturas em dois anos (2007
a 2009) (ITU, 2011).
Segundo a empresa The Nielsen Company, a queda nos preços 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 Gráfico 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 integração
entre as aplicações e o hardware. Dentre estes sistemas encontra-se o Android, que possui
algumas peculiaridades que o releva em meio aos outros sistemas operacionais, que serão
discutidas brevemente.
A OHA (Open Handset Alliance), formada pela Google e outras empresas com
enfoque em tecnologia móvel, desenvolveu o Android, que é um projeto de código aberto
feito para suportar aparelhos com diversas especificações. Desenvolvido com base em um
kernel Linux, contém uma máquina virtual JAVA personalizada para aperfeiçoar o
desempenho do aparelho. Sua principal característica é o fácil desenvolvimento de
aplicações, sendo que tais aplicações podem ter o mesmo nível de acesso dos aplicativos
que já vêm com o SO (OHA, 2011).
Visto que a aquisição e o desenvolvimento de softwares para estes aparelhos estão
cada vez mais fáceis, espera-se que as empresas comecem a desenvolver / implantar
soluções para dispositivos móveis, a fim de prover uma maior facilidade para seus
clientes.
Dentre muitos problemas, as empresas enfrentam a falta de gerenciamento e
organização de seus processos internos e externos (ex.: comunicação com fornecedores).
Para minimizar este problema, recorrem à implantação de metodologias de processos e
13
auditoria dos mesmos, esperando ter uma melhor visibilidade sobre seus processos e uma
evolução 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 forneça mobilidade ao usuário, dando-lhe condição
para acessar o software de seu dispositivo móvel. Será desenvolvido um modelo de
software usando conceitos de auditorias. Nestes termos, há os seguintes objetivos
específicos:
a) Estudo de ambientes;
b) Análise de processos;
c) Desenvolvimento da solução;
d) Implantação da solução.
1.3. Metodologia
Este trabalho será iniciado com uma análise de tecnologias que serão utilizadas no
decorrer do projeto, assim como técnicas e estudos os quais irão auxiliar no
desenvolvimento da aplicação.
Será feito um estudo sobre um ambiente onde é necessária a auditoria dos processos
relacionados a um trabalho, visando analisar os problemas na agilidade no procedimento
de análise dos processos e a necessidade de mobilidade e facilidade do auditor.
Após a definição do ambiente, será projetado um modelo de software para suprir as
necessidades apresentadas na pesquisa. Utilizando de metodologias de desenvolvimento
de software para dispositivos móveis, serão coletados os requisitos do sistema,
necessidades cruciais e, com base nessas informações, 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 solução desenvolvida.
14
Por fim, o software será avaliado quanto à sua eficácia em relação ao seu objetivo
principal, visando especialmente à mobilidade e facilidade de uso.
1.4. Organização
No capítulo 1 foi apresentada a motivação que deu origem a este estudo, mostrando o
crescimento na utilização dos dispositivos móveis, tecnologia que é utilizada nestes
aparelhos para aperfeiçoar o uso do equipamento e o problema que as empresas enfrentam
com seus processos para atender seus clientes.
No capítulo 2 serão detalhadas as tecnologias e metodologias utilizadas nesta pesquisa,
abordando o surgimento da comunicação móvel, 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 capítulo 3 será analisado o SCRUM com relação aos requisitos do CMMI,
visualizando pontos de coletas de informações, pontos possíveis para aplicar os
questionários e uma constatação de quais questionários são atendidos ou não com o
processo mais básico do SCRUM.
O capítulo 4 irá conter a definição do software que será desenvolvido, sendo possível
visualizar quais as ferramentas serão utilizadas para desenvolver o projeto e como será a
arquitetura de funcionamento das aplicações cliente e servidor.
No capítulo 5 será descrito o modo que o software será aplicado em um dado processo.
Tal processo também será definido neste capítulo, assim como um meio convencional de
auditoria, que também se baseia em CMMI.
No capítulo 6 serão analisados os resultados obtidos com este projeto.
No capítulo 7 será apresentada a conclusão do trabalho.
15
2. Fundamentação Teórica
Este capítulo trata das tecnologias e metodologias envolvidas para elaboração do trabalho.
Estudou-se a evolução da comunicação móvel, tendo uma análise de como se chegou à
tecnologia dos dispositivos móveis atuais e sobre sistemas operacionais que estes utilizam.
Também está presente um estudo sobre processos e método de auditoria ao mesmo.
2.1. Comunicação Móvel
Com a necessidade de se comunicar, o ser humano desenvolveu várias técnicas e
equipamentos para tornar este processo mais rápido e fácil. Um exemplo claro foi o
telefone. Criado em 1876 por Alexander Graham Bell, o telefone sofreu alterações no
decorrer dos anos, sendo aprimorados até a criação do primeiro dispositivo móvel, os
celulares, em 1947, fabricados pelas companhias Bell e AT&T (AKAIWA, 1997).
Durante a evolução dos telefones, também evoluíram os computadores. Seguindo a
mesma linha dos telefones, surgiu a necessidade de que os computadores também
pudessem ser levados a outros lugares de uma maneira mais fácil, mais móvel. Eis que
surgem os notebooks.
Os notebooks tiveram seu início 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 início a sua linha de computadores portáteis com o HP951 X
Palmtop PC, mesmo ano da popularização 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 movimentação dos
celulares e as funcionalidades dos computadores. Suas funções básicas envolvem
processamento de textos, manipulação de planilhas, acesso à internet e coleta de dados. A
diferença entre os dois é que o HandHeld possui um teclado para digitação e o PDA, além
de ser um pouco menor, possui tela sensível ao toque e teclado digital (TONON, 2006).
16
Ou seja, a evolução destes equipamentos acarretou a integração com a computação
com o objetivo de prover mais funcionalidades, mas ainda com foco na comunicação. Esta
evolução chegou a tal ponto que se fez necessário incorporar sistemas de informação em
dispositivos, como os celulares, dando origem a uma grande variedade em relação a
modelos, funcionalidades, aplicações e sistemas operacionais.
Como explica Martins (2009), há vários tipos de sistema operacional para dispositivos
móveis, 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 móveis (Tabela 2.1), podemos ver o crescimento no uso dos sistemas
operacionais nos anos de 2009 (ACKER, 2010) e 2010 (NIELSEN, 2010).
2009
SO
RIM Blackberry OS
2010
Porcentagem
6,00%
SO
Porcentagem
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
Gráfico 2.1 Gráfico comparativo de uso dos sistemas operacionais internacionalmente
(Baseado nos dados da Tabela 2.1)
Como podemos ver no Gráfico 2.1, há um crescimento considerável de dois sistemas
operacionais. Porém, o que se destaca dentre eles é o Android, não apenas pelo
crescimento, mas também por sua característica de sempre dar o mesmo nível de acesso
aos programas nele instalados. Ou seja, tanto os softwares que são originários do sistema
operacional quanto os que são criados por terceiros possuem acesso aos mesmos recursos,
podendo, assim, substituir qualquer software nativo do SO por outro com as mesmas
características (MARTINS, 2009).
Já houve vários trabalhos envolvendo aplicações para dispositivos móveis, inclusive
estudos com base na plataforma Android, tais como:
Medic Mobile – Desenvolvido por Uéliton Sandro Tonon sobre a plataforma de
programação Microsoft .Net, trata-se de uma aplicação que envolve um sistema de
gerenciamento de consultas médicas, onde o prontuário é consultado por um dispositivo
móvel, tendo os dados recuperados por meio de conexão wireless.
Há também uma aplicação embarcada em celular visando controle de robô via Wi-Fi,
a qual foi desenvolvida por CRUZ (2011) e seus colegas, onde o objetivo da aplicação foi
usar um dispositivo móvel que emitisse comandos via Wi-Fi para um robô executar.
Possibilitando que o robô fosse acionado à distância e sem a necessidade de fios.
18
Ou seja, aplicações para dispositivos podem ser utilizadas em diversas áreas, desde
que tal área tenha a necessidade de interação do usuário por meio de um dispositivo móvel
ou queira prover esta facilidade, como no caso deste trabalho.
2.2. O Android
A OHA, liderada pela Google, é constituída por mais de 40 empresas de ramos
diferentes, porém todas ligadas à tecnologia de dispositivos móveis. Este grupo foi criado
com o objetivo de criar padrões para a indústria de telefonia móvel, tendo como primeiro
passo para alcançar este objetivo, a criação do Android (ACKER, 2010).
O Android é um sistema operacional baseado em um kernel Linux, versão 2.6, o qual
provê os mesmos serviços de segurança, gerenciamento de memória e de processos e
todas outras características do kernel. Conforme a Figura 2.1, sua estrutura é formada
pelas camadas: Linux Kernel; Bibliotecas; Ferramentas de Runtime do Android; Estrutura
das Aplicações; e Aplicações (DEV GUIDE, 2011).
Figura 2.1 Arquitetura do sistema operacional Android (DEV GUIDE, 2011)
19
Kernel Linux: é responsável pelo controle de acesso e gerenciamento dos recursos do
celular para ter um uso organizado e dar robustez na utilização dos mesmos.
Runtime do Android: possui a maior parte das funcionalidades das principais
bibliotecas da linguagem JAVA e uma máquina virtual, nomeada de Dalvik. O Dalvik foi
projetado com foco em economia no consumo de memória e possuí a característica de
criar uma instância para cada processo, assim, tornando-o mais eficiente e performático.
Basicamente, o Dalvik é uma JVM (JAVA Virtual Machine) customizada, que executa as
classes já compiladas através de um compilador JAVA.
Bibliotecas: está camada é usada pelos componentes do sistema do Android, pois
possuem capacidades de fornecer a estrutura para as aplicações que serão executadas no
SO. Exemplos dessas capacidades são: bibliotecas de mídia (MP3, JPG, MPEG4 e etc.);
bibliotecas 3D, que fornecem suporte a aplicações com gráficos em 2D e 3D; SQLite,
banco de dados relacional muito performático e leve para o sistema; entre outros (DEV
GUIDE, 2011).
Estrutura de Aplicação: neste nível encontram-se as APIs (Application Programming
Interface), que foram desenvolvidas para simplificar o reuso dos componentes contidos no
sistema operacional. Entre as APIs disponíveis estão: Gerenciador de Janelas; Gerenciador
de Atividades; Provedor de Conteúdo; e etc.
Aplicações: por fim, esta camada contém as aplicações escritas em JAVA e instaladas
no celular, tais como Google Maps, browser, calendários e etc.
Para um software ser instalado no Android, o código é compilado e empacotado em
um arquivo na extensão .apk. Tal arquivo, quando executado no dispositivo móvel, é
descompactado e habilitado para interação com o usuário.
De acordo com a arquitetura do Android, cada aplicação é executada em uma máquina
virtual Dalvik exclusiva, o Kernel Linux concede à aplicação um ID e são concedidas,
também, as permissões aos arquivos de competência da aplicação, os quais só ficarão
visíveis para aquela aplicação durante sua execução.
20
As aplicações podem ser acionadas de diversas maneiras utilizando componentes que
são instanciados quando são requisitados. Tais componentes chamam-se Activitiy,
Services, Content Providers e Broadcast Receivers.
Os componentes Activity, Services e Broadcast Receivers são acionados por
mensagens assíncronas, ou seja, que pode não ocorrer num tempo previsto. Estas
mensagens são enviadas por meio de um objeto chamado Intent, enviando uma intenção
de ação (DEV GUIDE, 2011).
As Intents podem ser classificadas em duas categorias, os implícitos e os explícitos.
Nas Intents implícitas, o próprio sistema operacional escolhe qual dos componentes
responderá melhor àquela chamada da Intent, baseando em alguns critérios do próprio
Android. Já nas explícitas, o componente que irá ser ativado é indicado com antecedência.
As atividades que são executadas no Android têm um ciclo de vida rigorosamente
definido. Começando quando a atividade é requisitada, a atividade é criada, executada e
destruída, 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 inglês "to audit", que significa
examinar, corrigir, certificar, e / ou ajustar (ATTIE, 2010).
Portanto, auditar pode ser definido como um processo de avaliação de uma
situação diante de critérios previamente determinados, ou seja, comparando fatos
reais com metas pré-estabelecidas (FILHO, 2011).
No Brasil, a auditoria foi reconhecida apenas após 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, órgão criado
para
congregação
e
auto-disciplinação
de
profissionais
de
auditoria
(POMPONET, 2009).
A princípio, cabia ao auditor emitir relatórios do setor contábil das empresas,
porém, a necessidade fez com que o mesmo auditor, além da atividade já dita,
também emitisse relatórios com sugestões 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 também,
buscando a excelência e evitando desperdícios (POMPONET, 2009).
Para atingir este objetivo, há a necessidade da implantação de uma
Governança 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 práticas das metodologias disponíveis aos requisitos da empresa e do
cliente (HANASHIRO, 2007).
Dentre as metodologias disponíveis, 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
práticas usadas na concepção do produto e na manutenção do mesmo, cobrindo
todo o ciclo de vida entre estas etapas. Resumindo, se posta como um guia para
melhorar os processos da organização e sua capacidade para gerenciar o
desenvolvimento, aquisição e manutenção de produtos e serviços.
Estas práticas abrangem tópicos como incitação e gerenciamento de
requisitos, tomada de decisão, plano de trabalho, tratamento de riscos e
medição de desempenho (CMU, 2011).
Conforme MARÇAL (2007a), os componentes do CMMI estão agrupados
em três categorias, as quais são descritas como:

Requeridos
–
componentes
que
devem
ser
implementados
visivelmente nos processos da organização com o objetivo de atender
uma área do processo (atendimento de metas específicas);

Esperados – componentes que a empresa deve desenvolver para atingir
um componente requerido (atendimento de práticas genéricas e
específicas);

Informativos – componentes que auxiliam a empresa em o que fazer
para atingir os componentes esperados, assim, atingindo também, os
componentes requeridos.
Uma área de processo (PA, do inglês Process Area) é um conjunto
interligado de ações que, quando realizados simultaneamente, atendem ao
conjunto de objetivos relevantes para melhoria da área em questão. A área de
processo pode ser incrementada com objetivos complementares a fim de
melhor descrevê-la, como propósito, notas introdutórias e lista de áreas
relacionadas (MARÇAL, 2009).
24
Meta específica (SG, do inglês Specific Goal) é constituída de várias
práticas específicas que devem ser executadas para atingir tal meta. Esta meta
descreve as funções que devem estar presentes no processo para atender
adequadamente a PA.
Práticas específicas (SP, do inglês Specific Pratices) descrevem atividades
que deverão ser executadas objetivando o cumprimento de metas específicas.
Assim, realizando estas práticas, alcança-se uma meta específica.
Meta genérica (GG, Generic Goal) são características que estão presentes
em várias áreas do processo. Tanto estas metas quanto as metas específicas são
usadas para medir o nível de satisfação de uma PA.
No CMMI existem duas representações gráficas para determinar o nível de
capacidade e o nível de maturidade das áreas de processo. São definidos
objetivos alcançáveis e relacionados ao contexto da área específica para cada
processo, assim, permitindo a analise do cumprimento destes objetivos.
Na representação contínua é possível escolher entre melhorar o
desempenho de um único processo ou diversos processos, desde que estes
estejam alinhados aos objetivos organizacionais. Nesta representação, a
avaliação ocorre em níveis enumerados de 0 a 5. Esta representação tem foco
nos processos como Gerência de Projeto, Suporte e etc. Assim, há os níveis:
a) Nível 0 (Incompleto) - o processo não é executado ou é executado
parcialmente.
b) Nível 1 (Executado) - o processo executa as práticas específicas da área
de processo em questão.
c) Nível 2 (Gerenciado) - o processo é planejado e gerenciado. Caso haja
pontos falhos no plano, são feitas ações corretivas.
25
d) Nível 3 (Definido) - o processo é documentado e executado por toda a
organização nos projetos, podendo ser adaptado aos às características
do projeto.
e) Nível 4 (Gerenciado Quantitativamente) - o processo é analisado
estatisticamente e pode-se ter uma previsibilidade de como o processo
irá se comportar.
f) Nível 5 (Otimizado) - o processo é melhorado continuamente,
identificando os problemas comuns causados pelas variações no
processo avaliado (ANACLETO, 2004).
Na representação por estágios já há níveis pré-estabelecidos (de 1 à 5),
visando melhorar todos os processos da organização baseando-se em estágios
que não podem ser desconsiderados, pois cada estágio serve de base para o
próximo estágio. Assim, temos:
a) Nível 1 (Inicial) – imaturidade organizacional; os processos ainda são
improvisados e dificilmente seguidos; muitas vezes não se cumpre os
prazos e custos acordados; o planejamento é feito sem baseamento em
estimativas; não há disseminação de conhecimento adquirido no
projeto; o sucesso do projeto depende totalmente das habilidades dos
gerentes e desenvolvedores.
b) Nível 2 (Gerenciado) – os processos de desenvolvimento de software e
as políticas envolvidas estão definidos e são seguidos; as estimativas se
baseiam em conhecimento adquirido em projetos anteriores; são
utilizados processos definidos, disseminados, documentados, medidos e
auditados com rotinas de melhoria; os processos são puramente
gerenciais e pertencentes aos projetos.
c) Nível 3 (Definido) – os processos usados estão definidos e são
conhecidos por toda a organização; neste nível, consideram-se também
os processos técnicos junto aos gerenciais; ambos os processos são
26
usados repetidamente; os processos são transferidos dos projetos para a
organização.
d) Nível 4 (Quantitativamente Gerenciado) – define metas quantitativas
para os processos e produtos, coletando, em todos os projetos, medidas
de produtividade e qualidade; é estabelecido um controle estatístico de
processos; a gestão é feita com base nos dados quantitativos.
e) Nível 5 (Otimização) – a organização está focada na melhoria contínua
de seus processos; identificação de melhorias e defeitos; ações
preventivas sobre possíveis problemas; análise de custo / benefício, com
base nos dados coletados, para mudar significativamente processos e /
ou tecnologias.
Graficamente, temos as representações dispostas como na Figura 2.3
(MARÇAL, 2009).
Figura 2.3 Representações do CMMI (MARÇAL, 2009).
2.4. SCRUM
O SCRUM é uma prática de desenvolvimento ágil de softwares que está em grande
uso atualmente. Envolve um processo de desenvolvimento inovador, rápido e controlado,
o qual permite que, enquanto os desenvolvedores criam partes do software, outras partes
já desenvolvidas estejam disponíveis para teste, aumentando assim a agilidade na detecção
e solução de erros ou problemas nas regras de negócio.
27
Conforme explica MARÇAL (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 previsão de custo / prazo básica em cima dos requisitos que o
cliente deseja e dividido o projeto em pequenas tarefas, assim podendo dar uma
previsibilidade mais confiável.
Neste processo, temos definidos alguns papéis para as pessoas envolvidas com o
produto, as quais são:

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 progressão do projeto e que cada
membro do time tenha as ferramentas necessárias para realizar seus trabalhos,
organiza reuniões e monitora o progresso do projeto;

Desenvolvedores (Developers) e Avaliadores (Testers), ambos trabalham em
paralelo. Enquanto o primeiro desenvolve a aplicação, o outro testa o software
desenvolvido para certificar-se que está funcionando conforme previsto;

Clientes (Customers) e Executivos (Executives), são as pessoas que financiam o
projeto, esperando ter o produto conforme especificado, pois também o utilizam.
Tendo os papéis definidos, pode-se definir, então, o produto, ou, comumente chamado
de artefatos.
Schwaber (2004) diz que o SCRUM é composto, principalmente, pelos artefatos
Product Backlog, Sprint Backlog e agregação das funcionalidades desenvolvidas. Mas
Shojaee (2011) mostra, também, que há outros artefatos importantes como o Release
Backlog e Defect Backlog.
Seguindo o processo de desenvolvimento de software SCRUM, são realizados os
seguintes passos:
28
Primeiro, é levantada uma lista de requisitos sobre o produto que será desenvolvido.
Esta lista também é 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 incluídos mais requisitos, conforme a necessidade do produto.
Assim, dando início ao Product Backlog selecionado, ou seja, filtrado pelo Product
Owner.
Em seguida, a partir do Product Backlog, podemos definir Release Backlogs, que são
partes do produto final, ou seja, o produto é dividido em entregas menores, podendo ter
uma estimativa de horas gastas para conclusão do Release, que resultarão na conclusão do
projeto. Estes backlogs são priorizados pelo Product Owner, levando em consideração seu
peso em relação ao produto final.
Tendo os Release Backlogs, defini-se os Sprints Backlogs, que também se resumem
em uma divisão de tarefas do Release, tendo um tempo de duração entre 3 e 30 dias no
máximo dependendo do ciclo do Release (quantidade de iterações do Release).
Conforme diz Marçal (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 início a uma
nova Sprint (SHOJAEE, 2011).
Durante a realização de uma Sprint ocorrem os chamados Daily SCRUM Meetings,
que são reuniões diárias com um tempo máximo de 15 minutos. Estas reuniões visão
reunir a equipe de desenvolvimento para compartilhar seu progresso, suas dificuldades e
seu plano de trabalho até o próximo SCRUM Meeting (MARÇAL, 2007b). As perguntas a
serem respondidas nesta reunião são:

“O que fiz no projeto desde a última reunião?”;

“Que impedimentos estou tendo para realização da tarefa?”;
29

“O que irei fazer até a próxima reunião?”.
Além desta reunião, 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
adaptações 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 próxima Sprint (Marçal, 2007b).
Ao final de cada Sprint é possível saber qual o tempo decorrido do projeto e seu tempo
restante previsto para término. Então, se uma Sprint não é finalizada no prazo, pode ser
um grande indicador informando que o projeto inteiro está atrasado (SHOJAEE, 2011).
Em relação aos defeitos, há duas práticas possíveis na metodologia SCRUM.
A primeira é, assim que detectados os bugs da Sprint em questão, solucioná-los
imediatamente e, após a correção destes, pode-se tomar a Sprint como finalizada.
A segunda opção é 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 solução
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 gráfico 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 diários da quantidade do trabalho restante, podendo
ver se a equipe está no caminho certo ou está tendo dificuldades no desenvolvimento. No
gráfico pode ser taxada uma linha de previsão de término, qual é comumente chamada de
Burndown Velocity, referente ao tempo acordado para conclusão da tarefa. No gráfico é
possível ter uma média de velocidade de desenvolvimento do projeto, então se pode,
também, calcular a velocidade de desenvolvimento por dia que se deve ter para terminar a
entrega a tempo.
Para ter essa visão gráfica do andamento do projeto, ao final de cada dia os
desenvolvedores atualizam o trabalho restante. Isto é importante para se ter um
acompanhamento de progressão dia-a-dia do trabalho realizado (SCHWABER, 2011).
Abaixo, na figura tal, mostra-se um exemplo de gráfico Burndown, feito numa
máquina virtual Android versão 2.1, com valores fictícios.
Figura 2.4 Máquina virtual Android mostrando um gráfico Burndown
31
3. SCRUM + CMMI
Neste capítulo é analisado o Scrum, visando aderi-lo ao CMMI, mapeando os pontos
de seus processos que são passíveis de auditoria.
Santander (2009) mostra em seu trabalho um mapeamento das áreas do SCRUM em
relação ao CMMI níveis 2 e 3. Mostra também que, após a avaliação feita, o SCRUM não
atende a alguns requisitos do CMMI por não ter documentação, controle e registros
suficientes para atender aos níveis indicados. Assim, fica a critério da organização
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 também levantou problemas de adequação entre as
tecnologias. Porém, não só identificou pontos fracos do SCRUM, como também sugeriu
possíveis soluções para os problemas citados.
Em uma análise mais profunda, Marçal (2009) apresenta uma verificação do
atendimento do SCRUM ao CMMI até o nível 4. No trabalho, foi desenvolvido um
projeto denominado SCRUMMI, que tem o objetivo de facilitar o gerenciamento do
SCRUM através do CMMI.
Os resultados obtidos foram de grande relevância, tendo um ganho de produtividade
de 80% (4 vezes maior que o previsto no início 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 flexível.
Definiu-se, neste trabalho, que as práticas do SCRUM serão analisadas e mapeadas
conforme as áreas de processo da categoria Gestão de Projetos.
Assim, conforme informações de SEI (2006), a Tabela 3.1 mostra a categoria de
Gestão de Projetos e suas áreas de processo separadas por nível de maturidade do CMMI
(representação por estágios).
32
Nível de
Maturidade
2
3
4
Sigla
Área de Processo
(SEI)
Planejamento do Projeto
PP
Controle e Monitoramento do Projeto
PMC
Gerenciamento de Acordos com Fornecedores
SAM
Gerenciamento Integrado de Projetos
IPM
Gerenciamento de Riscos
RSK
Gerenciamento Quantitativo
QPM
Tabela 3.1 Gestão de Projeto - Áreas de processo por nível de maturidade
Na Tabela 3.1 são mostradas as áreas de processo até o nível 4, pois não há áreas de
processo do nível 5 para a categoria Gestão de Projetos.
Em seu trabalho, Marçal (2009) compara as áreas de processo citadas na Tabela 3.1 de
acordo com sua aderência com os processos do SCRUM. Serão utilizados os critérios
mostrados na Tabela 3.2 para avaliar se o SCRUM possui evidências em relação às áreas
de processo.
É importante ressaltar que os critérios aqui adotados foram definidos pela autora e
podem não ser iguais aos mesmos critérios usados em uma auditoria oficial do CMMI.
Classificação
Satisfeita
Critério
O SCRUM atende completamente a
Sigla
S
prática
Não Satisfeita
O SCRUM não atende a prática
Parcialmente
O SCRUM atende parcialmente a
Satisfeita
prática
NS
PS
Tabela 3.2 Critérios para avaliação segundo Marçal (2009)
Definidos os critérios, são avaliadas as áreas de processo, utilizando-se dos critérios de
avaliação, para medir o nível de atendimento que o SCRUM tem em relação ao CMMI.
Conforme SEI (2006), os objetivos das Áreas de Processo são:
33
Planejamento do Projeto - O objetivo desta área de processo é definir e garantir que
sejam seguidos planos de projeto, onde são definidas as atividades do mesmo.
Controle e Monitoramento do Projeto - O objetivo desta área de processo é dar uma
visibilidade do progresso do projeto, sendo possível a tomada de ações corretivas quando
constatado que o desempenho do projeto está significativamente fora do plano.
Gerenciamento de Acordo com Fornecedores - Esta área de processo visa fornecer
informações para gerenciar a aquisição 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 padrões da organização.
Gerenciamento de Riscos - Esta área de processo visa identificar possíveis problemas
que o projeto está suscetível a ter, podendo estes ser tratados com um planejamento
prévio, reduzindo as chances de defeitos com alto grau de impacto no projeto.
Gerenciamento Quantitativo - O objetivo desta área de processo é fornecer métricas
quantitativas sobre o processo definido, visando o cumprimento de metas de desempenho
e qualidade.
Assim, tendo como referências as avaliações de Marçal (2009), gerou-se a Tabela 3.3,
a qual mostra se o grau de atendimento do SCRUM em relação às práticas das áreas de
processo.
34
Área de Processo
Planejamento do
Projeto (PP)
Meta
Classificação
SP 1.1 Estimar Escopo do Projeto
S
SG 1 Estabelecer
SP 1.2 Estabelecer Estimativas de Atributos de Produtos de Trabalho e Tarefas
NS
Estimativas
SP 1.3 Definir Ciclo de Vida do Projeto
S
SP 1.4 Determinar Estimativas de Esforço e Custo
PS
SP 2.1 Estabelecer o Orçamento e o Cronograma
PS
SP 2.2 Identificar Riscos do Projeto
PS
SG 2 Desenvolver
SP 2.3 Planejar Gerenciamento de Dados
NS
um Plano de
SP 2.4 Planejar Recursos do Projeto
S
Projeto
SP 2.5 Planejar Conhecimentos e Habilidades Necessários
S
SP 2.6 Planejar Envolvimento dos Stakeholders
S
SP 2.7 Estabelecer Plano do Projeto
S
SP 3.1 Revisar Planos que Afetam o Projeto
S
Compromisssos
SP 3.2 Equilibrar Níveis de Trabalho e Recurso
S
com o Plano
SP 3.3 Obter Comprometimento com o Plano
S
SP 1.1 Monitorar os Parâmetros de Planejamento do Projeto
PS
SP 1.2 Monitorar os Compromissos
S
SG1 Monitorar o
SP 1.3 Monitorar os Riscos do Projeto
PS
Projeto em
SP 1.4 Monitorar os Gerenciamento de Dados
NS
Relação ao Plano
SP 1.5 Monitorar o Envolvimento dos Stakeholders
S
SP 1.6 Conduzir Revisões em Progresso
S
SP 1.7 Conduzir Revisões em Marcos
S
SP 2.1 Analisar Problemas
S
SP 2.2 Tomar Ações Corretivas
PS
Encerramento
SP 2.3 Gerenciar Ações Corretivas
PS
SG 1 Estabelecer
SP 1.1 Determinar Tipo de Aquisição
NS
Acordo com
SP 1.2 Escolher Fornecedores
NS
Fornecedores
SP 1.3 Estabelecer Acordos com Fornecedores
NS
SP 2.1 Executar o Acordo com o Fornecedor
NS
SG 2 Satisfazer
SP 2.2 Monitorar os Processos Selecionados do Fornecedor
NS
Acordos com
SP 2.3 Avaliar os Produtos de Trabalho Selecionados do Fornecedor
NS
Fornecedores
SP 2.4 Aceitar o Produto Adquirido
NS
SP 2.5 Executar a Transição de Produtos
NS
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
SP 2.1 Gerenciar Envolvimento dos Stakeholders
S
SP 2.2 Gerenciar Dependências
PS
Relevantes
SP 2.3 Resolver Questões de Coordenação
PS
SG 3 Aplicar os
SP 3.1 Estabelecer Visão Compartilhada do Projeto
S
Princípios do
SP 3.2 Estabelecer uma Estrutura Integrada para o Time
S
SP 3.3 Alocar Requisitos para Times Integrados
S
Produto e do
SP 3.4 Estabelecer Times Integrados
S
Processo
SP 3.5 Garantir Colaboração entre as Interfaces dos Times
S
SG 1 Preparar o
SP 1.1 Determinar as Fontes e Categorias do Risco
NS
Gerenciamento
SP 1.2 Determinar os Parâmetros do Risco
NS
de Riscos
SP 1.3 Estabelecer a Estratégia de Gerenciamento dos Riscos
NS
SG 2 Identificar e
SP 2.1 Identificar os Riscos
PS
SG 3 Obter
Controle e
Prática Específica
Específica
Monitoramento do
Projeto (PMC)
SG 2 Gerenciar
Ações Corretivas
até o
Gerenciamento de
Acordos com
Fornecedores (SAM)
SG 1 Utilizar o
Processo Definido
IPM
do Projeto
Gerenciamento
SG 2 Coordenar e
Integrado de
Colaborar com os
Projetos
Stakeholders
IPPD
(IPM+IPPD)
Gerenciamento de
Riscos (RSK)
Desenvolvimento
Integrado do
35
Analisar Riscos
SP 2.2 Avaliar, Categorizar e Priorizar Riscos
NS
SG 3 Mitigar
SP 3.1 Desenvolver Plano de Mitigação de Riscos
NS
Riscos
SP 3.2 Implementar Planos de Mitigação de Riscos
NS
SP 1.1 Estabelecer Objetivos do Projeto
NS
SP 1.2 Compor Processo Definido
NS
SP 1.3 Escolher SubProcessos que serão Gerenciados Estatisticamente
NS
SP 1.4 Gerenciar a Performance do Projeto
NS
SP 2.1 Selecionar as Medidas e Técnicas Analíticas
NS
SP 2.2 Aplicar Métodos Estatísticos para Entender Variação
NS
SP 2.3 Monitorar Performance de SubProcessos
NS
SP 2.4 Gravar Gerenciamento Estatístico dos Dados
NS
SG 1 Gerenciar
Quantitativamente
o Projeto
Gerenciamento
Quantitativo (QPM)
SG 2 Gerenciar
Estatisticamente
a Performance
dos
SubProcessos
Tabela 3.3 Avaliação áreas de processo em relação ao Scrum (MARÇAL, 2009)
Em resumo, pode-se ver que há práticas da área de Gestão de Projetos que o Scrum
não atende. Assim, serão analisadas as áreas que possuem maior possibilidade de
auditoria.
Analisando este cenário, 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 nível de conformidade com aquele tipo de auditoria e o que deve ser
melhorado.
Para realização 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 avaliação pode ocorrer no momento que o auditor achar necessário ou quando
houver evidências suficientes para responder as questões e as pessoas são escolhidas de
acordo com o seu perfil de trabalho, visando fazer as perguntas certas às pessoas certas.
Como, por exemplo, logo na definição do Product Backlog, já é possível a avaliação
referente à área de processo Planejamento do Projeto, sendo o Scrum Master e o Time os
entrevistados.
O auditor irá usar seu dispositivo móvel para avaliar o processo, entrevistando pessoas
ligadas ao projeto em questão. Assim que completado com sucesso, estes relatórios serão
enviados ao servidor para serem processados e armazenados.
36
Ainda pelo dispositivo móvel, será possível recuperar algumas visões das auditorias
realizadas, tais como resultados do relatório de Planejamento do Projeto de um projeto em
específico.
No servidor, serão armazenados os dados no banco de dados e feito o processamento
destas informações. Neste recurso, estará disponível o serviço de entrada de dados, para
que o dispositivo móvel os envie, e o serviço de saída, para que o auditor consiga
recuperar informações dos relatórios realizados.
Com este tipo de arquitetura pode-se prover a centralização dos dados, facilidade na
recuperação de tais dados e da lógica usada para receber e enviar os dados, retirando do
dispositivo móvel 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 capítulo, a ferramenta desenvolvida neste trabalho deve
ter esta característica. Tal ferramenta será melhor detalhada no capítulo 4.
37
4. Proposta de Solução
Neste capítulo é definida a arquitetura do software e é mostrado o seu
desenvolvimento. Assim, inicia-se com a definição 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 são os dispositivos móveis.
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 código aberto, que dá suporte à Java Servlets e Java Server Pages
(TOMCAT, 2011).
Este servidor usa o framework Hibernate (2011), da JBoss, para fazer a
persistência e a consulta no banco de dados, o qual foi determinado o MySQL (2011)
v5. Ambas as ferramentas também são open source.
O cliente foi desenvolvido focando o sistema operacional Android, portanto, seu
desenvolvimento também foi feito na linguagem JAVA. A aplicação é responsável por
fornecer formulários com os questionários a serem feitos, coletar os dados da auditoria
e enviar para o servidor armazenar. Também é possível consultar o resultado das
auditorias feitas, em forma de gráficos.
A comunicação entre o cliente e o servidor é feita com o auxilio do framework
JSON (JavaScript Object Notation), o qual proverá este serviço via chamadas HTTP.
Este componente foi escolhido como meio de comunicação porque gera chamadas que
são facilmente interpretadas e escritas por humanos, e analisadas e geradas por
máquinas (JSON, 2011).
38
4.2. Modelagem do software: Cliente
O funcionamento da aplicação dos dispositivos clientes funciona da seguinte
maneira. As ações são iniciadas a partir de uma interação do usuário com a tela de
visualização do dispositivo móvel. Ao requerer uma informação, a solicitação é
processada na camada de processamento e enviada ao servidor na internet por uma
requisição REST ou HTTP.
Após o envio da requisição, é retornada uma mensagem, a qual pode conter dados,
mensagem de confirmação ou erro. Tais mensagens podem ter tratamentos diferentes,
porém todas serão processadas, a fim de adequá-las àquela tela de visualização
específica e invocar ações específicas. Após o processamento, as telas são mostradas
ao usuário em seu dispositivo móvel.
4.3. Modelagem do software: Servidor
Na aplicação servidora, as ações são realizadas a partir de uma requisição (Rest ou
HTTP) dos dispositivos clientes.
Após o recebimento da requisição, o software vai atendê-la como for necessário,
tendo sua lógica em arquivos Java. Caso seja necessário, a aplicação irá acessar, por
meio do framework Hibernate, o banco de dados e atender à requisição da forma
necessária. Retornando ao cliente as informações requeridas. Estas chamadas ao
servidor resultarão em objetos do tipo JSON (Javascript) e o cliente deve ter suporte a
este tipo de tecnologia, tanto para enviar requisições ao servidor quanto receber
informações.
Assim, é obtida a arquitetura mostrada na Figura 4.1.
39
Figura 4.1 Funcionamento da aplicação 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) versão 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 versão 6.0 (APACHE,
2011), pois é um software de uso gratuito, um projeto de código aberto e possuí todas
as funcionalidades requeridas no projeto deste trabalho.
Como plataforma do dispositivo cliente foi utilizado o Android SDK versão 2.2
(ANDROID, 2011), pois é a versão do dispositivo disponível para testes.
Foi utilizado, também, o padrão de projeto Model-View-Controller (FREEMAN,
2007) para obter maior facilidade na manutenção dos softwares e para seguir o padrão
de desenvolvimento de software usado no Android.
40
4.5. Ambiente Avaliado
Inicialmente descreve-se o projeto que será avaliado, informando suas
características principais. Em seguida, mostra-se uma forma de avaliar o processo,
apontando cada momento onde determinado relatório deve ser aplicado.
Define-se o ambiente avaliado com as seguintes características:

A avaliação terá o objetivo de atacar apenas o processo de Gerência de
Projetos, visando à melhoria deste processo em específico;

será avaliado seguindo a Representação Contínua do CMMI (WEBER,
2004);

estará em transição do nível 1 de capacidade (Executado) para o nível 2
de capacidade (Gerenciado);

será utilizada a metodologia de desenvolvimento de software SCRUM no
processo avaliado.
Deseja-se alcançar um nível de capacidade melhor no processo de Gerência de
Projetos, sendo este processo considerado o ponto "problemático" da organização.
Portanto, a estratégia adotada pela empresa para diminuir as perdas com o processo é
auditá-lo e melhorar seus pontos falhos através das práticas do CMMI.
Estando o ambiente no nível 1 de capacidade do CMMI, ele pode ser
caracterizado como um processo executado. Ou seja, o processo executa as metas
específicas da área de processo.
Para que o processo alcance o nível 2 de capacidade do CMMI, deve-se atender,
também, às metas genéricas dos níveis anteriores ao que se deseja, que são
compostas pelas práticas genéricas, como mostra a Figura 4.2.
41
Figura 4.2 Metas necessárias para atingir o nível de capacidade 2
Portanto, como se espera atingir o nível 2 de capacidade, o ambiente possui as
características para atender as metas específicas e meta genérica 1 das Áreas de
Processo referentes à Gestão 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 parâmetros de planejamento do
projeto a fim de se obter maior previsibilidade do projeto. Meta a qual é atingida:

Executando a prática Estimar o Escopo do Projeto, a qual consiste em estimar
esforço e prazo e distribuir as responsabilidades do projeto;

outra prática executada é Estabelecer Estimativas para Atributos de Trabalho e
de Tarefas, sendo que para ser executada deve estabelecer estimativas, como
por exemplo, número de funções ou de classes e objetos, para produtos de
trabalho como itens entregáveis e não entregáveis;

há, também, a prática Definir Ciclo de Vida do Projeto, consiste em determinar
o ciclo de vida do projeto onde, normalmente, são definidos para apoiar pontos
de decisão;
42

por último, deve ser executada a prática Determinar Estimativas de Esforço e
Custo, consistindo em calcular tais estimativas com base histórica associando,
também, o tamanho do projeto.
Executando as atividades estipuladas acima, pode-se considerar que esta meta
esta sendo atingida pelo processo.
A meta específica Elaborar um Plano de Projeto consiste na elaboração 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 orçamento,
identificando e analisando os riscos do projeto, planejando a gestão dos dados
referente aos projetos executados;

esta meta ainda requer a execução da prática planejar recursos do projeto como
mão-de-obra, maquinário, materiais e etc. Assim como deve se planejar as
habilidades e conhecimentos necessários para a execução do projeto a fim de
tornar as pessoas envolvidas hábeis 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 específica Elaborar um Plano de Projeto.
A última meta específica, 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, papéis e responsabilidades
importantes para sucesso do projeto;

Conciliar carga de trabalho e recursos, obtido por meio de estratégia para
atender os requisitos do projeto;

E obter o comprometimento com o plano estipulado, obtendo a interação entre
as partes interessadas relevantes internas e externas.
43
Executando, assim, a meta específica Obter Comprometimento com o Plano.
Em seguida, deve-se atender a meta genérica 1 para obter o nível 1 de capacidade.
Tendo, esta, o objetivo de Satisfazer as Metas Específicas da área de processo. E
nesta meta genérica, faz-se necessária a execução da prática Executar Práticas
Específicas.
Tais atividades já foram previamente executadas, podendo considerar que a área
de processo está sendo atendida em nível 1 de capacidade no processo.
O nível 2 de capacidade possui como meta Institucionalizar um Processo
Gerenciado, o qual possui as práticas:

Estabelecer uma Política Organizacional – estabelecendo uma expectativa da
organização em relação aos parâmetros estimados para o planejamento do
projeto;

Planejar o Processo – estabelecendo um método planejado para que seja
executado o planejamento do projeto estipulado;

Fornecer Recursos – provendo os recursos necessários para que o processo de
planejamento do projeto possa ser executado, os quais podem ser pessoas
especializadas ou recurso eletrônico para executar alguma tarefa;

Atribuir Responsabilidades – definindo que são os responsáveis 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 são
elaboração de estimativas, gestão de dados e etc;

Gerenciar Configurações – 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 são estabelecimento do plano de projeto,
44
revisão 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 relação ao plano estabelecido para execução do
processo, identificando pontos problemáticos para posteriores melhorias no
processo;

Avaliar Objetivamente a Aderência – de acordo com os objetivos definidos,
avaliar a aderência do processo, identificando pontos falhos e tratando-os;

Revisar Status com a Gerência de Nível Superior – junto à gerência de nível
superior, revisar as atividades e os resultados coletados no planejamento do
projeto, a fim de tratar situações críticas ou problemas no processo.
Nos capítulos a seguir serão mostradas duas avaliações, com o objetivo de atingir
o nível 2 de capacidade CMMI, sendo uma por um método convencional e a outra
pelo método desenvolvido neste trabalho.
4.6. Aplicação do Método Desenvolvido
A avaliação por este método possui as características 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 formulário que será aplicado e Figura
4.5 que mostra o formulário para preenchimento e envio dos dados coletados.
45
Figura 4.3 Tela inicial do software
Figura 4.4 Tela para escolha de formulário de auditoria
46
Figura 4.5 Tela do formlário de auditoria escolhido
Tendo todos os formulários no dispositivo móvel, o auditor pode acompanhar o
processo SCRUM para coletar as informações sobre o processo. Porém, como foi
visto, os formulários são separados por metas, conforme Figura 4.4.
Assim, cada formulário deve ser aplicado à um momento específico no processo
SCRUM. Momentos os quais são mostrados na Figura 4.6, tendo como exemplo o
formulário 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 formulários é aplicado
Como se pode ver, cada meta é estipulada para um momento, porém algumas
informações podem ser coletadas antes, e outras, depois.
Com os definidos momentos, o auditor pode acompanhar o processo de execução
do projeto, auditá-lo mais que uma vez em determinada meta, podendo obter mais
dados sobre o processo avaliado.
48
5. Aplicação do Conceito no Ambiente
Este capítulo apresenta uma aplicação prática dos conceitos citados no capítulo 4.
Também mostrará um ambiente convencional baseado no ambiente escolhido no capítulo
4.
5.1.
Aplicação pelo Método Proposto
O projeto avaliado teve seus requisitos divididos em 3 Sprints, as quais têm
duração de duas semanas, pois é o menor tempo de Sprint recomendável ao processo
SCRUM e, assim, pode-se rapidamente gerar valor ao produto final. Além disto, foi
definido que o time será composto por dois Product Owners, um Scrum Master,
quatro desenvolvedores, três testadores e um analista de sistemas.
Como o ambiente avaliado é um ambiente teórico, o método proposto foi aplicado
apenas conceitualmente, pois não há como se ter um ambiente propício à aplicar o
método na prática, baseando-se em experiências e opiniões dos auditores
entrevistados.
O relatório escolhido para avaliação foi o Estabelecer Estimativas. Onde, para
cada prática, foram elencadas algumas pessoas para responder sobre a prática.
A prática 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. Além dele, o próprio time de desenvolvimento pode responder à esta
prática, pois têm contato direto com os requisitos e a conexão entre os entregáveis.
A prática 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, número de funções, complexidade e quantidade
de interfaces e etc.
49
O ScrumMaster pode responder sobre a prática 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 Esforço e Custo é de responsabilidade do
time desenvolvedor, pois os próprios irão determinar as estimativas para cada um dos
Sprints, com base em conhecimentos adquiridos em trabalhos anteriores.
Portanto, aplicando o relatório para as pessoas corretas, espera-se que atinja a
margem de 20 minutos para realização da avaliação, contendo desde a entrevista até
a demonstração das evidências.
5.2. Método Convencional
Neste trabalho, entende-se por método convencional como um processo de
auditoria feito, em maior parte, manualmente. Assim, tanto a coleta dos dados quanto
os relatórios e gráficos devem ser feitos por pessoas sem quase nenhuma automação
no processo.
Este processo servirá de comparação para o método proposto.
A avaliação por este método é definido pelas características:

É realizado por formulários impressos;

Os formulários são preenchidos à caneta, a fim de evitar alterações
posteriores;

Os dados são transferidos dos formulários para planilhas digitais em um
diretório de armazenamento;

Tais
planilhas
seguem
o
padrão
<projeto>_<área
de
processo>_<aaaammdd>.<extensão>. Ex.: Projeto1_PlanejamentoProjeto
_20111201.xlsx.
50
Assim, para que o processo de Gestão de Projeto seja avaliado, conforme este
método, são necessários os formulários tanto das metas já cumpridas quanto das
metas objetivas.
Tais formulários podem são vistos nas Figuras 5.2 e foram avaliados por um
auditor com 6 anos de experiência em auditoria de processos, sendo considerados
efetivos para o objetivo proposto.
51
52
Figura 5.2 Formulários de auditoria impressas
Uma vez tendo os formulários em mãos, o auditor pode acompanhar o processo
Scrum e auditá-lo em pontos previamente definidos para obter um padrão nas
auditorias realizadas. Tais formulário são distribuídos em quatro momentos, sendo
eles A, B, C e D.
No ponto A, executam-se as práticas:

Estimar Escopo do Projeto.

Estabelecer Orçamento e Cronograma.

Planejar Recursos do Projeto.

Planejar Conhecimentos e Habilidades Necessários.

Estabelecer uma Política Organizacional.

Planejar o Processo.
53

Atribuir Responsabilidades.

Treinar Pessoas.
No ponto B, indica-se executar as práticas:

Estabelecer Estimativas de Atributos de Produtos de Trabalho e Tarefas.

Definir Ciclo de Vida do Projeto.

Determinar Estimativas de Esforço e Custo.

Planejar Gerenciamento de Dados.

Planejar Envolvimento dos Stakeholders.

Estabelecer Plano do Projeto.

Equilibrar Níveis de Trabalho e Recurso.

Obter Comprometimento com o Plano.

Fornecer Recursos.

Gerenciar Configurações.

Identificar e Envolver as Partes Interessadas Relevantes.
No ponto C, define-se a execução das práticas:

Revisar Planos que Afetam o Projeto.

Monitorar e Controlar o Processo.

Avaliar Objetivamente a Aderência.

Revisar Status com a Gerência de Nível Superior.
No ponto D, executa-se a prática:

Identificar Riscos do Projeto.
Assim, os pontos são distribuídos, 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 práticas 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 necessários para a execução.
No Sprint Backlog é realizado o ponto B, pois é o momento onde são atendidas
algumas práticas como o estabelecimento das tarefas, estimativas de custo e
previsões de esforço que será realizado. Neste momento também são definidos os
momentos de interação entre a equipe desenvolvedora e os stakeholders.
Realiza-se o ponto C após o Sprint terminar, momento o qual é feito uma revisão
da Sprint, visando avaliar possíveis problemas ocorridos durante a Sprint, revisar
práticas 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
formulários 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 decisão e planos de ações.
56
6. Análise de Resultados
O principal objetivo deste trabalho é desenvolver um software para dispositivo móvel
que permita realizar auditoria de processo. A disponibilidade deste software facilitará o
processo de realizar auditoria, centralizando e garantindo a integridade dos dados.
Em relação ao método convencional, se obtém os resultados a seguir.
Por ser realizado com formulários impressos, qualquer alteração deve ser reportada a
todos os auditores da organização na tentativa de não haver divergências entre as versões
que cada um dos auditores estão usando para realizar as auditorias. Caso haja uma
mudança muito significativa em algum dos formulários e um auditor use um formulário
depreciado, pode haver um problema de entendimento ou coleta errônea de dados. Porém,
pode-se facilmente alterar um formulário para se adequar ao processo ou incrementá-lo
com novas perguntas. O auditor deverá ter uma lista completa dos funcionários
relacionados ao projeto auditado e seus cargos.
Por se tratar de formulário impresso, o auditor deverá escrever as observações,
portanto a escrita deve ser clara, para que não haja entendimento ruim no momento em
que os resultados forem passados para a planilha de digital. Isto pode ocasionar um
aumento no tempo de realização da auditoria tanto por conta de ser escrito quanto por ter
que repassar todas as informações coletadas para a planilha digital.
Conforme o padrão de controle das planilhas digitais, deve–se ter todos os dados para
que se possa analisar o processo com mais precisão. Sendo, então, que se faz necessária a
execução completa do processo do projeto para que se tenha dados para avaliação e
tomada de ação.
Os formulários podem ser facilmente adaptados ao processo da organização, tendo a
disposição das perguntas da forma que o auditor achar melhor para realizar sua tarefa.
As informações estarão separas em planilhas diferentes, o que dificulta o controle das
informações e a centralização dos dados. Para obtenção de relatórios, gráficos ou escritos,
57
deverá coletar os dados das planilhas de acordo com o tipo e os filtros requeridos no
relatório.
Foi realizado um teste prático da aplicação dos relatórios no ponto C do processo de
desenvolvimento, desconsiderando o tempo de entrevista, pois este tempo é o mesmo para
qualquer método. Então, identificou-se que:

Para execução do formulário no momento do processo levou-se cerca de 28
minutos para escrever as informações no formulário, tomando-se cuidado para
não rasurar a folha;

Se a observação requerer muitas palavras, e isto não foi previsto, haverá um
problema de tamanho da linha para escrever a observação;

Demandaram-se aproximadamente 14 minutos para criação da planilha digital
(para o formulário usado anteriormente) e inserção dos dados na planilha.
Apenas após a execução das atividades citadas acima, os dados foram disponibilizados
para avaliação.
Em relação ao software desenvolvido neste trabalho, pode-se obter os seguintes
resultados.
Os formulários digitais recuperam informações dos projetos disponíveis para auditoria,
uma lista de auditores para escolha e uma lista de usuários para que se escolha a pessoa
que será auditada, assim, não tendo a necessidade de se ter uma lista dos funcionários da
organização.
É possível adequar os relatórios ao processo da empresa tanto quanto necessário,
baseando-se nas perguntas relevantes no momento escolhido. Porém, caso haja a
necessidade de alteração de algum dos formulários, haverá a necessidade de realizar as
modificações significativas de programação e visualização dos formulários no software.
Esta modificação, apesar de simples, necessita de horas de trabalho para pequenas
alterações.
O preenchimento do formulário é bem simples e o tempo de digitação varia de acordo
com a habilidade do auditor e a afinidade com teclado utilizado (físico ou digital). No
58
formulário digital não há como rasurar o relatório e não haveria problema se ocorrer um
erro na digitação, pois pode excluída antes do envio para o repositório de respostas no
servidor.
As informações das auditorias estarão armazenadas em um repositório digital único, o
que facilitará a realização de cópias de segurança dos dados e haverá menos dificuldades
em controlá-los.
Para a criação de gráficos e relatórios das auditorias há a necessidade de programação
de acordo com a necessidade do solicitante. Porém, com a centralização dos dados, uma
vez o relatório pronto, basta alterar os filtros e obterá os relatórios ou gráficos necessários.
A análise e tomada de decisão baseada nos dados torna-se mais rápida, pois, a os
dados estarão disponíveis assim que as informações forem enviadas ao servidor pelo
dispositivo móvel do auditor, possibilitando que se faça corretivas no processo.
Foi realizado um teste prático da aplicação dos relatórios Estabelecer Estimativas do
processo de desenvolvimento, também desconsiderando o tempo de entrevista, pois este
tempo é o mesmo para qualquer método. Então, identificou-se que:

Para execução do formulário no momento do processo levou-se cerca de 20
minutos para digitar as informações no formulário;

Apesar de poder limitar a quantia de caracteres no campo de observação, este não
tem um máximo no software desenvolvido.
Após enviado o relatório, os dados já estarão disponíveis para avaliação.
Assim, foram apresentados os resultados coletados dos dois métodos de auditoria
descritos neste trabalho.
59
7. Considerações 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 relatórios e gráficos sobre o processo. Foram descritas as
principais características da plataforma Android e ferramentas e métodos de programação
para dispositivos móveis para que fosse criada uma aplicação real. Portanto, este
documento será útil a quem se interesse por desenvolvimento de aplicações móveis e à
quem se interesse em auditoria de processos de TI.
Pode-se concluir que, de acordo com os resultados obtidos neste trabalho, com o
método desenvolvido:

Foi concebido utilizando dispositivos móveis;

foi desenvolvido um software cliente/servidor que propicia a utilização dos
dispositivos móveis para a aplicação da avaliação;

é possível coletar mais informações do processo pelo método desenvolvido, pois,
pode-se aplicar os formulários da avaliação tanto quanto possível, de acordo com o
formulário em questão;

provê maior facilidade ao auditor, em relação ao método convencional, pois há a
recuperação automática de informações necessárias na auditoria, além de um
formulário utilizado por todos os outros auditores da empresa;

os dados coletados na auditoria estão, no momento que enviados ao servidor,
disponíveis para avaliação tanto gráfica quanto por relatórios, o que permite tomar
decisões mais rapidamente;

com o maior número de coleta de informações, pode-se avaliar se a ação tomada
foi efetiva, mesmo durante a execução de um projeto.

demanda-se mais tempo para realizar a auditoria pelo método convencional do que
pelo método desenvolvido neste trabalho;

a criação de relatórios pelo método proposto, apesar de mais lento e complicado
em relação ao convencional, permite reuso com aplicação de filtros.
Dois possíveis usuários foram entrevistados sobre a utilidade e interesse da aplicação.
O retorno obtido foi que, apesar da ferramenta não ter sido implantada em nenhum
60
ambiente real de produção de projetos de TI, pode ser bem útil para empresas que buscam
a certificação CMMI, tendo uma boa avaliação sobre a utilidade do software. Em
contrapartida, pode ser algo dispensável a empresas pequenas.
É importante salientar que, mesmo obtendo-se dados métricos sobre o tempo de
realização da auditoria, pode haver pessoas que não se adaptem a este tipo de método
proposto. Assim, o tempo de execução pode aumentar.
A realização deste trabalho possibilitou o aprendizado na plataforma Android, na
arquitetura de dispositivos móveis e auditoria de processos. Além disto, foram assimilados
conceitos importantes como sistema orientado a serviços, web services REST e arquitetura
de sistemas cliente/servidor.
Finalizando, sugerem-se como trabalhos futuros:

A implantação deste método em uma grande empresa e em uma pequena empresa,
a fim de comparar o tempo de execução, o custo desta implantação e o impacto
gerado;

aplicação em outro ambiente que não utilize SCRUM;

adaptação para outros tipos de auditoria;

desenvolver o software para outras plataformas móveis;

desenvolver o sistema com sincronismo com o servidor, podendo realizar as
auditorias off-line.
61
8. Referências Bibliográficas
ACKER, Eduardo, V.; Weber, Taisy, S.; Cechin, Sérgio, L. Injeção de Falhas para Validar
Aplicações em Ambientes Móveis. Universidade Federal do Rio Grande do Sul, 11, 2010,
Porto Alegre, Rio Grande do Sul. XI Workshop de Testes e Tolerância 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. Método e Modelo de Avaliação para Melhoria de Processos de
Software em Micro e Pequenas Empresas. 2004. 174f. Mestre em Ciência da Computação
- Universidade Federal de Santa Catarina, Florianópolis, 2004.
ANDROID. Android 2.2 Plataform. Disponível em:
<http://developer.android.com/sdk/android-2.2.html>. Acesso em 24 de outubro de 2011.
APACHE. Apache Tomcat. Disponível em: <http://tomcat.apache.org/>. Acesso em 24 de
outubro de 2011.
ATTIE, William. Auditoria: conceitos e aplicações. 5th. ed. São 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 aplicação embarcada em
celular visando controle de robô via Wi-Fi. In: Revista Brasileira de Computação
Aplicada. ISSN 2176-6649. Passo Fundo, p. 43-52, 2011.
DEV GUIDE: What is Android?. 2011. Disponível em:
<http://developer.android.com/guide/basics/what-is-android.html>. Acesso em: 28 de
março de 2011.
62
ECLIPSE. About the Eclipse Foundation. Disponível em : <http://www.eclipse.org/org/>.
Acesso de 24 de outubro de 2011.
FILHO, Humberto Ferreira Oriá. As fraudes contra as organizações e o papel da auditoria
interna. 1st. ed. São Paulo: Sicurezza, 2011. ISBN 9788587297433.
FREEMAN, Eric. Freeman, Elisabeth. Use a Cabeça: Padrões de Projeto segunda edição.
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, Maíra. Metodologia para Desenvolvimento de Procedimentos e
Planejamento de Auditorias de TI Aplicada à Administração Pública Federal. 2007. 168f.
Universidade de Brasília, Brasília, 2007.
HIBERNATE. Overview. Disponível em: <http://www.hibernate.org>. Acesso em 06 de
setembro de 2011.
ITGI, IT Governance Institute. COBIT 4.1. 2007. Disponível em < www.itgi.org >.
Acesso em 12 de abril de 2011.
ITU - Internation Telecommunication Union < http://www.itu.int >. Acesso em 02 de
março 2011.
JDK. Read Me. Disponível em: <http://www.oracle.com/technetwork/java/javase/jdk-7readme-429198.html>. Acesso em 24 de outubro de 2011.
JSON, Introducing JSON. Disponível 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; Governança de TI um estudo sobre ITIL e COBIT. In: Simpósio de Excelência em Gestão e Tecnologia (VII
SEGeT), 7, 2010, São Paulo.
MARÇAL, 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 Informática, San Jose, Costa Rica, 2007b.
MARÇAL, 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.
MARÇAL, Ana S. C. SCRUMMI: Um processo de gestão ágil baseado no SCRUM e
aderente ao CMMI. 2009. 205 f. Mestrado em Informática Aplicada - Universidade
Fundação Edson Queiroz, Fortaleza, 2009.
MARTINS, Rafael J. W. de A. Desenvolvimento de Aplicativo para Smartphone com a
Plataforma Android. 2009. 50 f. Graduação em Engenharia de Computação - Pontifica
Universidade Católica do Rio de Janeiro, Rio de Janeiro. 2009.
MYSQL. Why MySQL? Disponível em: <http://www.mysql.com/why-mysql>. Acesso
em 06 de setembro de 2011.
NIELSEN: Vendas de smartphones crescem 128% no país, aponta estudo da Nielsen.
2010. <http://br.nielsen.com/news/vendas_smartphones.shtml>. Acesso em 02 de março
2011.
OHA, Open Handset Alliance. Disponível em <http://www.openhandsetalliance.com>.
Acesso em: 03 de março de 2011.
PAMPONET, Arnaud Velloso. Auditoria Interna de Processos. 2009. Disponível em:
<www.portaldeauditoria.com.br>. Acesso em 09 de novembro de 2011.
64
SANTANDER, Alexandre S.; Krüger, Gustavo R.; Guimarães, Yuri R. Mapeando o
Scrum em Relação ao CMMI - Níveis 2 e 3. III EPAC - Encontro Paranaense de
Computação, 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 março de 2011.
SEI. Software Engineering Institute. CMMI-DEV: CMMI for Development. V1.2 model,
CMU/SEL-2006-TR-008. Disponível 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, Sérgio.; CARVALHO, Tereza C. M. B. Governança de
TI: uma empresa virtual analisada sob a ótica do COBIT e do ITIL. In: Congresso Anual
de Tecnologia da Informação (CATI), 2004, São Paulo. 2004.
TOMCAT, Apache. Apache Tomcat. Disponível em: <http://tomcat.apache.org>. Acesso
em 06 de setembro de 2011.
TONON, Uéliton S. "Medic Mobile" Aplicação Móvel para Acesso Remoto de Dados
Clínicos de Pacientes Hospitalizados. 2006. 62 f. Graduação de Engenharia Elétrica Universidade Federal do Espírito Santo, Vitória. 2006.
65
WEBER, Kival C.; Rocha, Ana R.; Alves, Ângela; Ayala, Arnaldo M.; Gonçalves,
Austregésilo; Paret, Benito; Salviano, Clênio; Machado, Cristina F.; Scalet, Danilo; Petit,
Djalma; Araújo, Eratóstenes; Barroso, Márcio G.; Oliveira, Kathia; Oliveira, Luiz Carlos
A.; Amaral, Márcio P.; Campelo, Renata Endriss C.; Maciel, Teresa. Modelo de
Referência para Melhoria de Processo de Software: uma abordagem brasileira. In: XXX
Conferencia Latinoamericana de Informatica (CLEI2004), Arequipa Peru, 30., 2004.
ZANATTA, Alexandre L. Vilain, Patrícia. Uma análise do método á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.