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

Tamanho: px
Começar a partir da página:

Download "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).

PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM CMMI E METODOLOGIAS Á G EIS

PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM CMMI E METODOLOGIAS Á G EIS PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM CMMI E METODOLOGIAS Á G EIS CMMI E METODOLOGIAS ÁGEIS Os métodos de desenvolvimento Ágeis e

Leia mais

Guia do Nexus. O Guia Definitivo para o Nexus: O exoesqueleto do desenvolvimento Scrum escalado. Desenvolvido e mantido por Ken Schwaber e Scrum.

Guia do Nexus. O Guia Definitivo para o Nexus: O exoesqueleto do desenvolvimento Scrum escalado. Desenvolvido e mantido por Ken Schwaber e Scrum. Guia do Nexus O Guia Definitivo para o Nexus: O exoesqueleto do desenvolvimento Scrum escalado Desenvolvido e mantido por Ken Schwaber e Scrum.org Tabela de Conteúdo Visão Geral do Nexus... 2 O Propósito

Leia mais

Introdução a Computação Móvel

Introdução a Computação Móvel Introdução a Computação Móvel Computação Móvel Prof. Me. Adauto Mendes adauto.inatel@gmail.com Histórico Em 1947 alguns engenheiros resolveram mudar o rumo da história da telefonia. Pensando em uma maneira

Leia mais

Definição do Framework de Execução de Processos Spider-PE

Definição do Framework de Execução de Processos Spider-PE Definição do Framework de Execução de Processos Spider-PE 1. INTRODUÇÃO 1.1 Finalidade Este documento define um framework de execução de processos de software, denominado Spider-PE (Process Enactment),

Leia mais

SCRUM. Fabrício Sousa fabbricio7@yahoo.com.br

SCRUM. Fabrício Sousa fabbricio7@yahoo.com.br SCRUM Fabrício Sousa fabbricio7@yahoo.com.br Introdução 2 2001 Encontro onde profissionais e acadêmicos da área de desenvolvimento de software de mostraram seu descontentamento com a maneira com que os

Leia mais

Introdução CMMI. Qualidade e Teste de Software CMMI 1

Introdução CMMI. Qualidade e Teste de Software CMMI 1 Introdução CMMI O propósito da qualidade é estabelecer um diferencial competitivo, através de contribuições como redução de defeitos, redução de custos, redução de retrabalho e aumento da produtividade,

Leia mais

Workshop SCRUM. Versão 5 Out 2010 RFS. rildo.santos@etecnologia.com.br

Workshop SCRUM. Versão 5 Out 2010 RFS. rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos 2006 e 2010 Objetivo: Estudo de Caso Objetivo: Apresentar um Estudo de Caso para demonstrar como aplicar as práticas do SCRUM em projeto de desenvolvimento de

Leia mais

CMMI. B) descrições das atividades consideradas importantes para o atendimento de suas respectivas metas específicas. Governo do ES (CESPE 2009)

CMMI. B) descrições das atividades consideradas importantes para o atendimento de suas respectivas metas específicas. Governo do ES (CESPE 2009) CMMI Governo do ES (CESPE 2009) Na versão 1.2 do CMMI, 111 os níveis de capacidade são definidos na abordagem de estágios. 112 os níveis de maturidade são definidos na abordagem contínua. 113 existem seis

Leia mais

SCRUM. É um processo iterativo e incremental para o desenvolvimento de qualquer produto e gerenciamento de qualquer projeto.

SCRUM. É um processo iterativo e incremental para o desenvolvimento de qualquer produto e gerenciamento de qualquer projeto. SCRUM SCRUM É um processo iterativo e incremental para o desenvolvimento de qualquer produto e gerenciamento de qualquer projeto. Ken Schwaber e Jeff Sutherland Transparência A transparência garante que

Leia mais

Scrum-Half: Uma Ferramenta Web de Apoio ao Scrum

Scrum-Half: Uma Ferramenta Web de Apoio ao Scrum Scrum-Half: Uma Ferramenta Web de Apoio ao Scrum Diego R. Marins 1,2, José A. Rodrigues Nt. 1, Geraldo B. Xexéo 2, Jano M. de Sousa 1 1 Programa de Engenharia de Sistemas e Computação - COPPE/UFRJ 2 Departamento

Leia mais

Aluna: Vanessa de Mello Orientador: Everaldo Artur Grahl

Aluna: Vanessa de Mello Orientador: Everaldo Artur Grahl Ferramenta web para gerenciamento de projetos de software baseado no Scrum Aluna: Vanessa de Mello Orientador: Everaldo Artur Grahl Introdução Roteiro da apresentação Objetivos do trabalho Fundamentação

Leia mais

Pré-Projeto do Trabalho de Conclusão de Curso Tiago Garcia Pereira 1. INTRODUÇÃO

Pré-Projeto do Trabalho de Conclusão de Curso Tiago Garcia Pereira 1. INTRODUÇÃO UM PADRÃO ABERTO DE SOFTWARE PARA COMPUTAÇÃO MÓVEL: UM ESTUDO SOBRE GOOGLE ANDROID 1. INTRODUÇÃO O aumento do número usuários de dispositivos móveis atrai cada vez os desenvolvedores a produzir aplicações

Leia mais

Políticas de Qualidade em TI

Políticas de Qualidade em TI Políticas de Qualidade em TI Prof. www.edilms.eti.br edilms@yahoo.com Aula 03 CMMI Capability Maturity Model Integration Parte II Agenda sumária dos Processos em suas categorias e níveis de maturidade

Leia mais

Professor: Disciplina:

Professor: Disciplina: Professor: Curso: Disciplina: Marcos Morais de Sousa marcosmoraisdesousa@gmail.com marcosmoraisdesousa.blogspot.com Sistemas de informação Engenharia de Software II Gerenciamento de Qualidade CMMI e MPS.BR

Leia mais

Engenharia de Software

Engenharia de Software Faculdade de Informática e Administração Paulista Curso de Sistemas de Informação 2º SI-T Engenharia de Software Modelo de Desenvolvimento Ágil SCRUM Hugo Cisneiros RM 60900 Moyses Santana Jacob RM 63484

Leia mais

FireScrum: Ferramenta de apoio à gestão de projetos utilizando Scrum

FireScrum: Ferramenta de apoio à gestão de projetos utilizando Scrum C.E.S.A.R.EDU Unidade de Educação do Centro de Estudos e Sistemas Avançados do Recife Projeto de Dissertação de Mestrado FireScrum: Ferramenta de apoio à gestão de projetos utilizando Scrum Eric de Oliveira

Leia mais

RESUMO PARA O EXAME PSM I

RESUMO PARA O EXAME PSM I RESUMO PARA O EXAME PSM I Escrito por: Larah Vidotti Blog técnico: Linkedin: http://br.linkedin.com/in/larahvidotti MSN: larah_bit@hotmail.com Referências:... 2 O Scrum... 2 Papéis... 3 Product Owner (PO)...

Leia mais

Análise comparativa entre a engenharia de requisitos e o método de desenvolvimento ágil: Scrum

Análise comparativa entre a engenharia de requisitos e o método de desenvolvimento ágil: Scrum Análise comparativa entre a engenharia de requisitos e o método de desenvolvimento ágil: Scrum Patrícia Bastos Girardi, Sulimar Prado, Andreia Sampaio Resumo Este trabalho tem como objetivo prover uma

Leia mais

Ferramenta para gestão ágil

Ferramenta para gestão ágil Ferramenta para gestão ágil de projetos de software Robson Ricardo Giacomozzi Orientador: Everaldo Artur Grahl Agenda Introdução Objetivos Fundamentação teórica Desenvolvimento Resultados e discussões

Leia mais

AVALIAÇÃO DA UTILIZAÇÃO DO SCRUM COMO MEIO PARA OBTENÇÃO DO NÍVEL G DE MATURIDADE DE ACORDO COM O MODELO MPS.br RESUMO

AVALIAÇÃO DA UTILIZAÇÃO DO SCRUM COMO MEIO PARA OBTENÇÃO DO NÍVEL G DE MATURIDADE DE ACORDO COM O MODELO MPS.br RESUMO 1 AVALIAÇÃO DA UTILIZAÇÃO DO SCRUM COMO MEIO PARA OBTENÇÃO DO NÍVEL G DE MATURIDADE DE ACORDO COM O MODELO MPS.br Autor: Julio Cesar Fausto 1 RESUMO Em um cenário cada vez mais competitivo e em franca

Leia mais

A plataforma Android: Uma Introdução

A plataforma Android: Uma Introdução A plataforma Android: Uma Introdução Android Iniciativa da Google de prover uma plataforma aberta para Web móvel Open Handset Alliance Associação de um grupo bastante heterogêneo de empresas (operadoras,

Leia mais

Dispositivos móveis e o mercado Android Open Handset Alliance Informações sobre Android Arquitetura

Dispositivos móveis e o mercado Android Open Handset Alliance Informações sobre Android Arquitetura Dispositivos móveis e o mercado Android Open Handset Alliance Informações sobre Android Arquitetura Dispositivos móveis e o mercado Mercado cresce a cada ano Muitos recursos Múltiplas plataforma Symbian

Leia mais

Capability Maturity Model Integration - CMMI

Capability Maturity Model Integration - CMMI Capability Maturity Model Integration - CMMI Para Desenvolvimento Versão 1.2 M.Sc. Roberto Couto Lima ÍNDICE 1. Definição ------------------------------------------------------------------------------------------------------------

Leia mais

LEI DE ACESSO A INFORMAÇÃO DIREITO DO CIDADÃO

LEI DE ACESSO A INFORMAÇÃO DIREITO DO CIDADÃO DESCRIÇÃO DO SIGAI O SIGAI (Sistema Integrado de Gestão do Acesso à Informação) é uma solução de software que foi desenvolvida para automatizar os processos administrativos e operacionais visando a atender

Leia mais

Sistema de Automação Comercial de Pedidos

Sistema de Automação Comercial de Pedidos Termo de Abertura Sistema de Automação Comercial de Pedidos Cabana - Versão 1.0 Iteração 1.0- Release 1.0 Versão do Documento: 1.5 Histórico de Revisão Data Versão do Documento Descrição Autor 18/03/2011

Leia mais

Scrum. Introdução UFRPE-DEINFO BSI-FÁBRICA DE SOFTWARE

Scrum. Introdução UFRPE-DEINFO BSI-FÁBRICA DE SOFTWARE Scrum Introdução UFRPE-DEINFO BSI-FÁBRICA DE SOFTWARE scrum Ken Schwaber - Jeff Sutherland http://www.scrumalliance.org/ Scrum Uma forma ágil de gerenciar projetos. Uma abordagem baseada em equipes autoorganizadas.

Leia mais

Wesley Torres Galindo. wesleygalindo@gmail.com

Wesley Torres Galindo. wesleygalindo@gmail.com Wesley Torres Galindo wesleygalindo@gmail.com Wesley Galindo Graduação em Análise e Desenvolvimento de Sistemas Mestrado em Engenharia de Software Engenheiro de Software Professor Faculdade Escritor Osman

Leia mais

C O B I T. Gerenciamento dos Riscos Mitigação. Aceitação. Transferência. Evitar/Eliminar.

C O B I T. Gerenciamento dos Riscos Mitigação. Aceitação. Transferência. Evitar/Eliminar. C O B I T Evolução Estratégica A) Provedor de Tecnologia Gerenciamento de Infra-estrutura de TI (ITIM) B) Provedor de Serviços Gerenciamento de Serviços de TI (ITSM) C) Parceiro Estratégico Governança

Leia mais

Programação para Dispositivos Móveis

Programação para Dispositivos Móveis Programação para Dispositivos Móveis Fatec Ipiranga Análise e Desenvolvimento de Sistemas Aula 02 História do desenvolvimento de software para dispositivos móveis Dalton Martins dmartins@gmail.com São

Leia mais

PDS - DATASUS. Processo de Desenvolvimento de Software do DATASUS

PDS - DATASUS. Processo de Desenvolvimento de Software do DATASUS PDS - DATASUS Processo de Desenvolvimento de Software do DATASUS Coordenação Geral de Arquitetura e Engenharia Tecnológica Coordenação de Padronização e Qualidade de Software Gerência de Padrões e Software

Leia mais

Wesley Torres Galindo

Wesley Torres Galindo Qualidade, Processos e Gestão de Software Professores: Alexandre Vasconcelos e Hermano Moura Wesley Torres Galindo wesleygalindo@gmail.com User Story To Do Doing Done O que é? Como Surgiu? Estrutura Apresentar

Leia mais

O Modelo Processo de Software Brasileiro MPS-Br

O Modelo Processo de Software Brasileiro MPS-Br O Modelo Processo de Software Brasileiro MPS-Br Prof. Pasteur Ottoni de Miranda Junior Disponível em www.pasteurjr.blogspot.com 1-Estrutura do MPS-Br ( Softex, 2009) O MPS.BR1 é um programa mobilizador,

Leia mais

Profa. Celia Corigliano. Unidade IV GERENCIAMENTO DE PROJETOS DE TI

Profa. Celia Corigliano. Unidade IV GERENCIAMENTO DE PROJETOS DE TI Profa. Celia Corigliano Unidade IV GERENCIAMENTO DE PROJETOS DE TI Agenda da disciplina Unidade I Gestão de Projetos Unidade II Ferramentas para Gestão de Projetos Unidade III Gestão de Riscos em TI Unidade

Leia mais

SCRUM Gerência de Projetos Ágil. Prof. Elias Ferreira

SCRUM Gerência de Projetos Ágil. Prof. Elias Ferreira SCRUM Gerência de Projetos Ágil Prof. Elias Ferreira Métodos Ágeis + SCRUM + Introdução ao extreme Programming (XP) Manifesto Ágil Estamos descobrindo maneiras melhores de desenvolver software fazendo-o

Leia mais

Workshop. Workshop SCRUM. Rildo F Santos. rildo.santos@etecnologia.com.br. Versão 1 Ago 2010 RFS. www.etcnologia.com.br (11) 9123-5358 (11) 9962-4260

Workshop. Workshop SCRUM. Rildo F Santos. rildo.santos@etecnologia.com.br. Versão 1 Ago 2010 RFS. www.etcnologia.com.br (11) 9123-5358 (11) 9962-4260 Workshop www.etcnologia.com.br (11) 9123-5358 (11) 9962-4260 Rildo F Santos twitter: @rildosan skype: rildo.f.santos http://rildosan.blogspot.com/ Todos os direitos reservados e protegidos 2006 e 2010

Leia mais

Políticas de Qualidade em TI

Políticas de Qualidade em TI Políticas de Qualidade em TI Prof. www.edilms.eti.br edilms@yahoo.com Aula 03 CMMI Capability Maturity Model Integration Parte I Agenda Processos CMMI Definição Histórico Objetivos Características Representações

Leia mais

Sistemas de Informação e Programação II Odorico Machado Mendizabal

Sistemas de Informação e Programação II Odorico Machado Mendizabal Sistemas de Informação e Programação II Odorico Machado Mendizabal Universidade Federal do Rio Grande FURG C3 Engenharia de Computação 16 e 23 de março de 2011 Processo de Desenvolvimento de Software Objetivos

Leia mais

Processo de Desenvolvimento de Software. Unidade V Modelagem de PDS. Luiz Leão luizleao@gmail.com http://www.luizleao.com

Processo de Desenvolvimento de Software. Unidade V Modelagem de PDS. Luiz Leão luizleao@gmail.com http://www.luizleao.com Processo de Desenvolvimento de Software Luiz Leão luizleao@gmail.com http://www.luizleao.com Conteúdo Programático desta aula Modelo Cascata (Waterfall) ou TOP DOWN. Modelo Iterativo. Metodologia Ágil.

Leia mais

Descrição das Áreas de Processo

Descrição das Áreas de Processo Descrição das Áreas de Processo Níveis 2 e 3 Foco em CMMI para SW INF326 - Modelos de Qualidade de SW - Mario L. Côrtes CMMI parte B 5B - 1 Convenções gráficas Repositório de Medições Repositório de Informações

Leia mais

ALESSANDRO PEREIRA DOS REIS PAULO CESAR CASTRO DE ALMEIDA ENGENHARIA DE SOFTWARE - CAPABILITY MATURITY MODEL INTEGRATION (CMMI)

ALESSANDRO PEREIRA DOS REIS PAULO CESAR CASTRO DE ALMEIDA ENGENHARIA DE SOFTWARE - CAPABILITY MATURITY MODEL INTEGRATION (CMMI) ALESSANDRO PEREIRA DOS REIS PAULO CESAR CASTRO DE ALMEIDA ENGENHARIA DE SOFTWARE - CAPABILITY MATURITY MODEL INTEGRATION (CMMI) APARECIDA DE GOIÂNIA 2014 LISTA DE TABELAS Tabela 1 Áreas de processo por

Leia mais

Dados do Projeto. Nome do Projeto. Fingerprint Access Users. Data de Inicialização 14/04/2012

Dados do Projeto. Nome do Projeto. Fingerprint Access Users. Data de Inicialização 14/04/2012 Fábrica de Software Dados do Projeto Nome do Projeto Data de Inicialização Responsáveis Autores Fingerprint Access Users 14/04/2012 Adriana Lima de Almeida, Espedito Alves Leal, Jaciel Dias de Souza, Samuel

Leia mais

Aula 1 - Introdução e configuração de ambiente de desenvolvimento

Aula 1 - Introdução e configuração de ambiente de desenvolvimento Aula 1 - Introdução e configuração de ambiente de desenvolvimento Olá, seja bem-vindo à primeira aula do curso para desenvolvedor de Android, neste curso você irá aprender a criar aplicativos para dispositivos

Leia mais

METODOLOGIA DE GERENCIAMENTO DE PROJETOS SCRUM: ESTUDO DE REVISÃO. Bruno Edgar Fuhr 1

METODOLOGIA DE GERENCIAMENTO DE PROJETOS SCRUM: ESTUDO DE REVISÃO. Bruno Edgar Fuhr 1 METODOLOGIA DE GERENCIAMENTO DE PROJETOS SCRUM: ESTUDO DE REVISÃO Bruno Edgar Fuhr 1 Resumo: O atual mercado de sistemas informatizados exige das empresas de desenvolvimento, um produto que tenha ao mesmo

Leia mais

PONTIFÍCIA UNIVERSIDADE CATÓLICA DE GOIÁS Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas

PONTIFÍCIA UNIVERSIDADE CATÓLICA DE GOIÁS Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas PONTIFÍCIA UNIVERSIDADE CATÓLICA DE GOIÁS Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas CMP1141 Processo e qualidade de software I Prof. Me. Elias Ferreira Sala: 210 F Quarta-Feira:

Leia mais

Qualidade de Processo de Software Normas ISO 12207 e 15504

Qualidade de Processo de Software Normas ISO 12207 e 15504 Especialização em Gerência de Projetos de Software Qualidade de Processo de Software Normas ISO 12207 e 15504 Prof. Dr. Sandro Ronaldo Bezerra Oliveira srbo@ufpa.br Qualidade de Software 2009 Instituto

Leia mais

Gestão da Tecnologia da Informação

Gestão da Tecnologia da Informação TLCne-051027-P0 Gestão da Tecnologia da Informação Disciplina: Governança de TI São Paulo, Outubro de 2012 0 Sumário TLCne-051027-P1 Conteúdo desta Aula Abordar o domínio Adquirir e Implementar e todos

Leia mais

Processo de Software

Processo de Software Processo de Software Uma importante contribuição da área de pesquisa de processo de software tem sido a conscientização de que o desenvolvimento de software é um processo complexo. Pesquisadores e profissionais

Leia mais

Scrum Guia Prático. Raphael Rayro Louback Saliba Certified Scrum Master. Os papéis, eventos, artefatos e as regras do Scrum. Solutions. www.domain.

Scrum Guia Prático. Raphael Rayro Louback Saliba Certified Scrum Master. Os papéis, eventos, artefatos e as regras do Scrum. Solutions. www.domain. Scrum Guia Prático Os papéis, eventos, artefatos e as regras do Scrum Solutions www.domain.com Raphael Rayro Louback Saliba Certified Scrum Master 1 Gráfico de Utilização de Funcionalidades Utilização

Leia mais

Scrum e CMMI no C.E.S.A.R Relato de Experiência

Scrum e CMMI no C.E.S.A.R Relato de Experiência Scrum e CMMI no C.E.S.A.R Relato de Experiência Felipe Furtado Engenheiro de Qualidade Izabella Lyra Gerente de Projetos Maio/2008 Agenda Motivação Pesquisas Adaptações do Processo Projeto Piloto Considerações

Leia mais

CMMI Conceitos básicos. CMMI Representações contínua e por estágios. Professor Gledson Pompeu (gledson.pompeu@gmail.com)

CMMI Conceitos básicos. CMMI Representações contínua e por estágios. Professor Gledson Pompeu (gledson.pompeu@gmail.com) CMMI Conceitos básicos 113 CMMI integra as disciplinas de engenharia de sistemas e de engenharia de software em um único framework de melhoria de processos. 114 No tocante às disciplinas de engenharia

Leia mais

Unidade I GERENCIAMENTO DE. Profa. Celia Corigliano

Unidade I GERENCIAMENTO DE. Profa. Celia Corigliano Unidade I GERENCIAMENTO DE PROJETOS DE TI Profa. Celia Corigliano Objetivo Estimular o aluno no aprofundamento do conhecimento das técnicas de gestão profissional de projetos do PMI. Desenvolver em aula

Leia mais

Linguagem de Programação JAVA. Professora Michelle Nery Nomeclaturas

Linguagem de Programação JAVA. Professora Michelle Nery Nomeclaturas Linguagem de Programação JAVA Professora Michelle Nery Nomeclaturas Conteúdo Programático Nomeclaturas JDK JRE JEE JSE JME JVM Toolkits Swing AWT/SWT JDBC EJB JNI JSP Conteúdo Programático Nomenclatures

Leia mais

Plano de Trabalho Docente 2014. Ensino Técnico

Plano de Trabalho Docente 2014. Ensino Técnico Plano de Trabalho Docente 2014 Ensino Técnico ETEC MONSENHOR ANTONIO MAGLIANO Código: 088 Município: Garça Eixo Tecnológico: Informação e Comunicação Habilitação Profissional: Técnica de Nível Médio de

Leia mais

Políticas de Qualidade em TI

Políticas de Qualidade em TI Políticas de Qualidade em TI Aula 05 MPS.BR (ago/12) Melhoria de Processo do Software Brasileiro Prof. www.edilms.eti.br edilms@yahoo.com Agenda Descrição sumária do MPS.BR - Melhoria de Processo do Software

Leia mais

Android. Marcelo Quinta @mrquinta

Android. Marcelo Quinta @mrquinta Android Marcelo Quinta @mrquinta Oi, eu sou o Marcelo Quinta Pública Público-privada Privada Próprio negócio Voluntariado Parabéns à organização do GO-GTUG Tablets 160% de aumento em 2011 Smartphones

Leia mais

Após completar este módulo você deverá ter absorvido o seguinte conhecimento: Uma ampla visão do framework Scrum e suas peculiaridades

Após completar este módulo você deverá ter absorvido o seguinte conhecimento: Uma ampla visão do framework Scrum e suas peculiaridades Objetivos da Aula 1 Após completar este módulo você deverá ter absorvido o seguinte conhecimento: Uma ampla visão do framework Scrum e suas peculiaridades Entendimento sobre os processos essenciais do

Leia mais

COBIT (CONTROL OBJECTIVES FOR INFORMATION AND RELATED TECHNOLOGY)

COBIT (CONTROL OBJECTIVES FOR INFORMATION AND RELATED TECHNOLOGY) Universidade Federal de Santa Catarina Departamento de Informática e Estatística INE Curso: Sistemas de Informação Disciplina: Projetos I Professor: Renato Cislaghi Aluno: Fausto Vetter Orientadora: Maria

Leia mais

Exercícios: Governança de TI Prof. Walter Cunha http://www.waltercunha.com PRIMEIRA BATERIA. PMBoK

Exercícios: Governança de TI Prof. Walter Cunha http://www.waltercunha.com PRIMEIRA BATERIA. PMBoK Exercícios: Governança de TI Prof. Walter Cunha http://www.waltercunha.com PRIMEIRA BATERIA PMBoK 1. (FCC/ANALISTA-MPU 2007) De acordo com o corpo de conhecimento da gerência de projetos, as simulações

Leia mais

fagury.com.br. PMBoK 2004

fagury.com.br. PMBoK 2004 Este material é distribuído por Thiago Fagury através de uma licença Creative Commons 2.5. É permitido o uso e atribuição para fim nãocomercial. É vedada a criação de obras derivadas sem comunicação prévia

Leia mais

Por que o Scrum? o Foco na Gerência de Projetos; o Participação efetiva do Cliente.

Por que o Scrum? o Foco na Gerência de Projetos; o Participação efetiva do Cliente. Por que o Scrum? o Foco na Gerência de Projetos; o Participação efetiva do Cliente. Desenvolvido por Jeff SUTHERLAND e Ken SCHWABER ; Bastante objetivo, com papéis bem definidos; Curva de Aprendizado é

Leia mais

UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ. Campus Ponta Grossa ANDRÉ LUIS CORDEIRO DE FARIA RELATÓRIO DE ESTÁGIO

UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ. Campus Ponta Grossa ANDRÉ LUIS CORDEIRO DE FARIA RELATÓRIO DE ESTÁGIO UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ Campus Ponta Grossa ANDRÉ LUIS CORDEIRO DE FARIA RELATÓRIO DE ESTÁGIO Ponta Grossa 2012 ANDRÉ LUIS CORDEIRO DE FARIA RELATÓRIO DE ESTÁGIO Trabalho elaborado pelo

Leia mais

definido por um documento de padronização. A Fig. 1 representa a organização dos Grupos de Processos juntamente com os documentos exigidos.

definido por um documento de padronização. A Fig. 1 representa a organização dos Grupos de Processos juntamente com os documentos exigidos. A GESTÃO DE PROJETOS EXISTENTE NA NORMA DO-178B Matheus da Silva Souza, matheusdasilvasouza@gmail.com Prof. Dr. Luiz Alberto Vieira Dias, vdias@ita.br Instituto Tecnológico de Aeronáutica Praça Marechal

Leia mais

(C) A-C-E-F-H (D) A-G-F-H (E) A-G-I. Exercícios: Governança de TI Walter Cunha PRIMEIRA BATERIA. PMBoK COBIT

(C) A-C-E-F-H (D) A-G-F-H (E) A-G-I. Exercícios: Governança de TI Walter Cunha PRIMEIRA BATERIA. PMBoK COBIT Exercícios: Governança de TI Walter Cunha PRIMEIRA ATERIA (C) A-C-E-F-H (D) A-G-F-H (E) A-G-I PMoK 1. (FCC/ANALISTA-MPU 2007) De acordo com o corpo de conhecimento da gerência de projetos, as simulações

Leia mais

UMA ABORDAGEM PARA VIABILIZAR A ADERÊNCIA DA METODOLOGIA SCRUM AO MODELO MPS.BR NÍVEL G.

UMA ABORDAGEM PARA VIABILIZAR A ADERÊNCIA DA METODOLOGIA SCRUM AO MODELO MPS.BR NÍVEL G. UMA ABORDAGEM PARA VIABILIZAR A ADERÊNCIA DA METODOLOGIA SCRUM AO MODELO MPS.BR NÍVEL G. Magda A. Silvério Miyashiro 1, Maurício G. V. Ferreira 2, Bruna S. P. Martins 3, Fabio Nascimento 4, Rodrigo Dias

Leia mais

www.asrconsultoria.com.br

www.asrconsultoria.com.br www.asrconsultoria.com.br Garantia da Qualidade de Processo e Produto Direitos de Uso do Material Material desenvolvido pela ASR Consultoria e Assessoria em Qualidade Ltda. É permitido o uso deste material

Leia mais

SCRUM como metodologia de gestão de projetos da área administrativa Venturus: um case de sucesso RESUMO

SCRUM como metodologia de gestão de projetos da área administrativa Venturus: um case de sucesso RESUMO SCRUM como metodologia de gestão de projetos da área administrativa Venturus: um case de sucesso RESUMO Este artigo tem por objetivo apresentar a experiência do uso da metodologia Scrum para o gerenciamento

Leia mais

Plano de Trabalho Docente 2014. Ensino Técnico

Plano de Trabalho Docente 2014. Ensino Técnico Plano de Trabalho Docente 2014 Ensino Técnico Etec: ETEC PROF MASSUYUKI KAWANO Código: 136 Município: TUPÃ Eixo Tecnológico: INFORMAÇÃO E COMUNICAÇÃO Habilitação Profissional: Habilitação Profissional

Leia mais

GESTÃO DA QUALIDADE DE SOFTWARE

GESTÃO DA QUALIDADE DE SOFTWARE GESTÃO DA QUALIDADE DE SOFTWARE Fernando L. F. Almeida falmeida@ispgaya.pt Principais Modelos Capability Maturity Model Integration (CMMI) Team Software Process and Personal Software Process (TSP/PSP)

Leia mais

Glossário Apresenta a definição dos termos, siglas e abreviações utilizadas no contexto do projeto Citsmart.

Glossário Apresenta a definição dos termos, siglas e abreviações utilizadas no contexto do projeto Citsmart. Apresenta a definição dos termos, siglas e abreviações utilizadas no contexto do projeto Citsmart. Versão 1.6 15/08/2013 Visão Resumida Data Criação 15/08/2013 Versão Documento 1.6 Projeto Responsáveis

Leia mais

ScRUM na prática. Scrum no dia-a-dia. V Semana de Tecnologia da Informação

ScRUM na prática. Scrum no dia-a-dia. V Semana de Tecnologia da Informação ScRUM na prática Scrum no dia-a-dia V Semana de Tecnologia da Informação Agenda Manifesto Ágil; O Scrum; Os papéis do Scrum; Quem usa Scrum; O Scrum na Tray; Cerimônias; Artefatos. Qualidade. era uma vez

Leia mais

FERRAMENTAS PARA DESENVOLVIMENTO EM C#

FERRAMENTAS PARA DESENVOLVIMENTO EM C# FERRAMENTAS PARA DESENVOLVIMENTO EM C# Camila Sanches Navarro 1,2, Wyllian Fressatti 2 ¹Universidade paranaense (Unipar) Paranavaí PR Brasil sanchesnavarro@gmail.com wyllian@unipar.br Resumo. Este artigo

Leia mais

2 Jogos Educacionais. 2.1.Visão Geral de Jogos Educacionais

2 Jogos Educacionais. 2.1.Visão Geral de Jogos Educacionais 2 Jogos Educacionais Jogos estão presentes como uma prática habitual, eles tem sido concebidos como uma atividade lúdica que é bastante motivadora no processo de ensinoaprendizado. É assim que jogos educacionais

Leia mais

Modelo de Qualidade CMMI

Modelo de Qualidade CMMI Modelo de Qualidade CMMI João Machado Tarcísio de Paula UFF - Campus Rio das Ostras Resumo Este trabalho tem como objetivo explicar de forma simples o que é e como funciona o modelo de qualidade CMMI,

Leia mais

UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ - UTFPR DIRETORIA DE PESQUISA E PÓS-GRADUAÇÃO ESPECIALIZAÇÃO EM ENGENHARIA DE SOFTWARE

UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ - UTFPR DIRETORIA DE PESQUISA E PÓS-GRADUAÇÃO ESPECIALIZAÇÃO EM ENGENHARIA DE SOFTWARE UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ - UTFPR DIRETORIA DE PESQUISA E PÓS-GRADUAÇÃO ESPECIALIZAÇÃO EM ENGENHARIA DE SOFTWARE VINICIOS DORNELLES OLIVA ADAPTAÇÃO DO SCRUM PARA ADERIR A ÁREA DE PROCESSO

Leia mais

CobiT: Visão Geral e domínio Monitorar e Avaliar. Daniel Baptista Dias Ernando Eduardo da Silva Leandro Kaoru Sakamoto Paolo Victor Leite e Posso

CobiT: Visão Geral e domínio Monitorar e Avaliar. Daniel Baptista Dias Ernando Eduardo da Silva Leandro Kaoru Sakamoto Paolo Victor Leite e Posso CobiT: Visão Geral e domínio Monitorar e Avaliar Daniel Baptista Dias Ernando Eduardo da Silva Leandro Kaoru Sakamoto Paolo Victor Leite e Posso CobiT O que é? Um framework contendo boas práticas para

Leia mais

MAPEAMENTO E LOCALIZAÇÃO DE REGIÕES DE INTERESSE UTILIZANDO REALIDADE AUMENTADA EM DISPOSITIVOS MÓVEIS COM PLATAFORMA ANDROID

MAPEAMENTO E LOCALIZAÇÃO DE REGIÕES DE INTERESSE UTILIZANDO REALIDADE AUMENTADA EM DISPOSITIVOS MÓVEIS COM PLATAFORMA ANDROID MAPEAMENTO E LOCALIZAÇÃO DE REGIÕES DE INTERESSE UTILIZANDO REALIDADE AUMENTADA EM DISPOSITIVOS MÓVEIS COM PLATAFORMA ANDROID Alessandro Teixeira de Andrade¹; Geazy Menezes² UFGD/FACET Caixa Postal 533,

Leia mais

ESTUDO DE CASO: SCRUM E PMBOK UNIDOS NO GERENCIAMENTO DE PROJETOS. contato@alinebrake.com.br. fs_moreira@yahoo.com.br. contato@marcelobrake.com.

ESTUDO DE CASO: SCRUM E PMBOK UNIDOS NO GERENCIAMENTO DE PROJETOS. contato@alinebrake.com.br. fs_moreira@yahoo.com.br. contato@marcelobrake.com. ESTUDO DE CASO: SCRUM E PMBOK UNIDOS NO GERENCIAMENTO DE PROJETOS (CASE STUDY: SCRUM AND PMBOK - STATES IN PROJECT MANAGEMENT) Aline Maria Sabião Brake 1, Fabrício Moreira 2, Marcelo Divaldo Brake 3, João

Leia mais

Especificação Suplementar

Especificação Suplementar Especificação Suplementar Versão Histórico de Revisões Data Versão Descrição Autor 29/10/2014 2.0 2.1 funcionalidade e segurança de M. Vinícius acesso 30/10/2014

Leia mais

Estudo de Caso da Implantação do Nível G do MPS.BR em Uma Empresa

Estudo de Caso da Implantação do Nível G do MPS.BR em Uma Empresa Estudo de Caso da Implantação do Nível G do MPS.BR em Uma Empresa Dayana Henriques Fonseca 1, Frederico Miranda Coelho 1 1 Departamento de Ciência da Computação Universidade Presidente Antônio Carlos (UNIPAC)

Leia mais

COBIT. Governança de TI. Juvenal Santana, PMP tecproit.com.br

COBIT. Governança de TI. Juvenal Santana, PMP tecproit.com.br COBIT Governança de TI Juvenal Santana, PMP tecproit.com.br Sobre mim Juvenal Santana Gerente de Projetos PMP; Cobit Certified; ITIL Certified; OOAD Certified; 9+ anos de experiência em TI; Especialista

Leia mais

Gerenciamento de Serviços em TI com ITIL. Gerenciamento de Serviços de TI com ITIL

Gerenciamento de Serviços em TI com ITIL. Gerenciamento de Serviços de TI com ITIL Gerenciamento de Serviços de TI com ITIL A Filosofia do Gerenciamento de Serviços em TI Avanços tecnológicos; Negócios totalmente dependentes da TI; Qualidade, quantidade e a disponibilidade (infra-estrutura

Leia mais

Desafios no Uso do Scrum em Ambientes CMMI

Desafios no Uso do Scrum em Ambientes CMMI Desafios no Uso do Scrum em Ambientes CMMI Teresa Maria de Medeiros Maciel UFRPE/INES/UFPE tmmaciel@gmail.com Base de conhecimento disponível Maior controle ISO9001 MPS BR Padronização processual

Leia mais

Implantando um Programa de Melhoria de Processo: Uma Experiência Prática

Implantando um Programa de Melhoria de Processo: Uma Experiência Prática Implantando um Programa de Melhoria de Processo: Uma Experiência Prática Evandro Polese Alves Ricardo de Almeida Falbo Departamento de Informática - UFES Av. Fernando Ferrari, s/n, Vitória - ES - Brasil

Leia mais

Proposta de Implementação de Qualidade de Software na Organização

Proposta de Implementação de Qualidade de Software na Organização Proposta de Implementação de Qualidade de Software na Organização Daniel Gonçalves Jacobsen 1 Faculdade Dom Bosco de Porto Alegre Porto Alegre RS Brasil daniel@flete.com.br Abstract. This article describes

Leia mais

MODELO DE DESENVOLVIMENTO ÁGIL SCRUM

MODELO DE DESENVOLVIMENTO ÁGIL SCRUM MODELO DE DESENVOLVIMENTO ÁGIL SCRUM CEETEPS CENTRO ESTADUAL DE EDUCAÇÃO TECNOLÓGICA PAULA SOUZA FATEC DE TAUBATÉ HABILITAÇÃO: ANÁLISE E DESENVOLVIMENTO DE SISTEMAS TEMA MODELO DE DESENVOLVIMENTO ÁGIL:

Leia mais

UM FRAMEWORK PARA DESENVOLVIMENTO DE

UM FRAMEWORK PARA DESENVOLVIMENTO DE UNIVERSIDADE FEDERAL DE PERNAMBUCO GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO CENTRO DE INFORMÁTICA UM FRAMEWORK PARA DESENVOLVIMENTO DE APLICATIVOS EM WINDOWS MOBILE. PROPOSTA DE TRABALHO DE GRADUAÇÃO Aluno:

Leia mais

Desenvolvimento de um aplicativo básico usando o Google Android

Desenvolvimento de um aplicativo básico usando o Google Android Desenvolvimento de um aplicativo básico usando o Google Android (Organização do Ambiente) Programação de Dispositivos Móveis Mauro Lopes Carvalho Silva Professor EBTT DAI Departamento de Informática Campus

Leia mais

Estudo sobre Desenvolvimento de Software Utilizando o Framework Ágil Scrum

Estudo sobre Desenvolvimento de Software Utilizando o Framework Ágil Scrum Estudo sobre Desenvolvimento de Software Utilizando o Framework Ágil Scrum Andre Scarmagnani 1, Fabricio C. Mota 1, Isaac da Silva 1, Matheus de C. Madalozzo 1, Regis S. Onishi 1, Luciano S. Cardoso 1

Leia mais

Como posso gerenciar melhor os meus ativos de software e reduzir o risco de auditorias de conformidade?

Como posso gerenciar melhor os meus ativos de software e reduzir o risco de auditorias de conformidade? RESUMO DA SOLUÇÃO CA SERVICE MANAGEMENT - GERENCIAMENTO DE ATIVOS DE SOFTWARE Como posso gerenciar melhor os meus ativos de software e reduzir o risco de auditorias de conformidade? O CA Service Management

Leia mais

Gerência de Projetos de Software CMM & PMBOK

Gerência de Projetos de Software CMM & PMBOK Gerência de Projetos de Software CMM & PMBOK http://www.sei.cmu.edu/ Prefácio do CMM Após várias décadas de promessas não cumpridas sobre ganhos de produtividade e qualidade na aplicação de novas metodologias

Leia mais

Demais Áreas de Conhecimento do PMBOK

Demais Áreas de Conhecimento do PMBOK Residência em Arquitetura de Software Demais Áreas de Conhecimento do PMBOK Prof. Dr. Sandro Ronaldo Bezerra Oliveira srbo@ufpa.br www.ufpa.br/srbo Gerência de Desenvolvimento 2008.2 Faculdade de Computação

Leia mais

O que é o Android? O que é o Android

O que é o Android? O que é o Android O que é o Android? O Android é um sistema operacional para dispositivos móveis, baseado em uma plataforma de código aberta sob a licença apache, permitindo que os fabricantes possam modificar seu código

Leia mais

A IMPORTÂNCIA DO TESTE DE SOFTWARE PARA A QUALIDADE DO PROJETO

A IMPORTÂNCIA DO TESTE DE SOFTWARE PARA A QUALIDADE DO PROJETO A IMPORTÂNCIA DO TESTE DE SOFTWARE PARA A QUALIDADE DO PROJETO Autora: LUCIANA DE BARROS ARAÚJO 1 Professor Orientador: LUIZ CLAUDIO DE F. PIMENTA 2 RESUMO O mercado atual está cada vez mais exigente com

Leia mais

Estratégias para o Desenvolvimento de Aplicações Móveis HP Enterprise Services CMT - Cloud, Mobility and Transformation Março, 2013

Estratégias para o Desenvolvimento de Aplicações Móveis HP Enterprise Services CMT - Cloud, Mobility and Transformation Março, 2013 Estratégias para o Desenvolvimento de Aplicações Móveis HP Enterprise Services CMT - Cloud, Mobility and Transformation Março, 2013 Copyright 2012 Hewlett-Packard Development Company, L.P. The information

Leia mais

Análise da aplicação da metodologia SCRUM em uma empresa de Desenvolvimento de Software

Análise da aplicação da metodologia SCRUM em uma empresa de Desenvolvimento de Software Análise da aplicação da metodologia SCRUM em uma empresa de Desenvolvimento de Software Carolina Luiza Chamas Faculdade de Tecnologia da Zona Leste SP Brasil carolchamas@hotmail.com Leandro Colevati dos

Leia mais

Engenharia de Software Qualidade de Software

Engenharia de Software Qualidade de Software Engenharia de Software Qualidade de Software O termo qualidade assumiu diferentes significados, em engenharia de software, tem o significado de está em conformidade com os requisitos explícitos e implícitos

Leia mais

ITIL na Prática. Quais são os fatores críticos de sucesso para obter valor a partir de um Service Desk? Conhecimento em Tecnologia da Informação

ITIL na Prática. Quais são os fatores críticos de sucesso para obter valor a partir de um Service Desk? Conhecimento em Tecnologia da Informação Conhecimento em Tecnologia da Informação ITIL na Prática Quais são os fatores críticos de sucesso para obter valor a partir de um Service Desk? Conhecimento em Tecnologia da Informação 2010 Bridge Consulting

Leia mais

Melhores Práticas em TI

Melhores Práticas em TI Melhores Práticas em TI Referências Implantando a Governança de TI - Da Estratégia à Gestão de Processos e Serviços - 2ª Edição Edição - AGUINALDO ARAGON FERNANDES, VLADIMIR FERRAZ DE ABREU. An Introductory

Leia mais

Plano de Projeto G Stock. G Stock. Plano de Projeto. Versão 1.0

Plano de Projeto G Stock. G Stock. Plano de Projeto. Versão 1.0 Plano de Projeto G Stock Plano de Projeto G Stock Versão 1.0 Histórico das Revisões Data Versão Descrição Autores 10/09/2010 1.0 Descrição inicial do plano de projeto Denyson José Ellís Carvalho Isadora

Leia mais

Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Programa de Pós-Graduação em Informática

Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Programa de Pós-Graduação em Informática Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Programa de Pós-Graduação em Informática Disciplina: INF5008 Prof.: (monalessa@inf.ufes.br) Conteúdo 8. Metodologias

Leia mais