FACULDADE DE TECNOLOGIA DE SÃO JOSÉ DOS CAMPOS FATEC PROFESSOR JESSEN VIDAL

Transcrição

1 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 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 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 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, f. : 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 5 Dedico este trabalho aos meus pais, sem os quais eu não teria tido forças para chegar onde estou.

6 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 7 "Ao dar às pessoas o poder de partilhar, estamos tornando o mundo mais transparente." Mark Zuckerberg

8 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 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 10 Índice: 1. Introdução Motivação Objetivos Metodologia Organização Fundamentação Teórica Comunicação Móvel O Android Auditoria de Processos Conceitos de Auditoria CMMI SCRUM SCRUM + CMMI Planejamento do Projeto Controle e Monitoramento do Projeto Gerenciamento de Acordo com Fornecedores Gerenciamento Integrado de Projeto Gerenciamento de Riscos Gerenciamento Quantitativo Proposta de Solução Arquitetura Modelagem do software: Cliente Desenvolvimento Ambiente Avaliado Aplicação do Método Desenvolvido Aplicação do Conceito no Ambiente Aplicação pelo Método Proposto Método Convencional Análise de Resultados Considerações Finais Referências Bibliográficas... 61

11 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 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 13 auditoria dos mesmos, esperando ter uma melhor visibilidade sobre seus processos e uma evolução dos mesmos (SORTICA, 2004) 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 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 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 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 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 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 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) 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 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 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 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 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 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) 21

22 Auditoria de Processos 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 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 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 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 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) 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 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 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 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 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 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 32 Nível de Sigla Área de Processo Maturidade (SEI) Planejamento do Projeto PP 2 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 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 Critério Sigla Satisfeita O SCRUM atende completamente a prática S Não Satisfeita O SCRUM não atende a prática NS Parcialmente Satisfeita O SCRUM atende parcialmente a prática 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 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 IPPD IPM 34 Área de Processo Meta Específica Prática Específica 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 Planejamento do Projeto (PP) SG 2 Desenvolver um Plano de SP 2.3 Planejar Gerenciamento de Dados SP 2.4 Planejar Recursos do Projeto NS 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 SG 3 Obter 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 Controle e Monitoramento do Projeto (PMC) Relação ao Plano SP 1.5 Monitorar o Envolvimento dos Stakeholders SP 1.6 Conduzir Revisões em Progresso SP 1.7 Conduzir Revisões em Marcos S S S SG 2 Gerenciar Ações Corretivas até o Encerramento SP 2.1 Analisar Problemas SP 2.2 Tomar Ações Corretivas SP 2.3 Gerenciar Ações Corretivas S PS PS SG 1 Estabelecer SP 1.1 Determinar Tipo de Aquisição NS Acordo com SP 1.2 Escolher Fornecedores NS Gerenciamento de Acordos com Fornecedores (SAM) Fornecedores SG 2 Satisfazer Acordos com SP 1.3 Estabelecer Acordos com Fornecedores SP 2.1 Executar o Acordo com o Fornecedor SP 2.2 Monitorar os Processos Selecionados do Fornecedor SP 2.3 Avaliar os Produtos de Trabalho Selecionados do Fornecedor NS NS NS 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 SG 1 Utilizar o Processo Definido do Projeto SP 1.2 Utilizar Ativos de Processos Organizacionais para o Planejamento das Atividades do Projeto SP 1.3 Estabelecer o Ambiente de Trabalho do Projeto SP 1.4 Integrar os Planos SP 1.5 Gerenciar o Projeto Utilizando os Planos Integrados NS NS NS NS Gerenciamento Integrado de Projetos (IPM+IPPD) SG 2 Coordenar e Colaborar com os Stakeholders Relevantes SP 1.6 Contribuir para os Ativos de Processos Organizacionais SP 2.1 Gerenciar Envolvimento dos Stakeholders SP 2.2 Gerenciar Dependências SP 2.3 Resolver Questões de Coordenação NS S PS PS SG 3 Aplicar os SP 3.1 Estabelecer Visão Compartilhada do Projeto S Princípios do Desenvolvimento Integrado do Produto e do SP 3.2 Estabelecer uma Estrutura Integrada para o Time SP 3.3 Alocar Requisitos para Times Integrados SP 3.4 Estabelecer Times Integrados S S 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 de Riscos (RSK) Gerenciamento de Riscos SP 1.2 Determinar os Parâmetros do Risco SP 1.3 Estabelecer a Estratégia de Gerenciamento dos Riscos NS NS SG 2 Identificar e SP 2.1 Identificar os Riscos PS

35 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 Gerenciamento SG 1 Gerenciar Quantitativamente o Projeto SP 1.1 Estabelecer Objetivos do Projeto SP 1.2 Compor Processo Definido SP 1.3 Escolher SubProcessos que serão Gerenciados Estatisticamente SP 1.4 Gerenciar a Performance do Projeto NS NS NS NS Quantitativo (QPM) SG 2 Gerenciar Estatisticamente a Performance dos SubProcessos SP 2.1 Selecionar as Medidas e Técnicas Analíticas SP 2.2 Aplicar Métodos Estatísticos para Entender Variação SP 2.3 Monitorar Performance de SubProcessos SP 2.4 Gravar Gerenciamento Estatístico dos Dados NS NS NS NS 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 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 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 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 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 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 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 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 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 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 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 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 45 Figura 4.3 Tela inicial do software Figura 4.4 Tela para escolha de formulário de auditoria

46 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).