Desenvolvimento em Smartphones - Aplicativos Nativos e Web
Jan Miszura Toledo1, Gilcimar Divino de Deus2
1 Departamento de Computação - Pontifícia Universidade Católica de Goiás - GO - Brasil
janmiszura@gmail.com
2 Departamento de Computação - Pontifícia Universidade Católica de Goiás - GO - Brasil
gyngil@gmail.com
Abstract. With the popularity of so-called smartphones, new opportunities arise to people who work in software development. This paper presents two possibilities in the development of software aimed at smartphones, which are the native applications and web applications. Both are described in order to highlight their characteristics to enable an understanding of the differences with these platforms. It also presents some examples of market demands that will arise with the popularity of smartphones, and finally are describes future works for who interested in continuing their studies targeting this area of knowledge.
Keywords: Smartphones, Native applications, Web applications and Mobile Devices
Resumo. Com a popularização dos chamados smartphones, novas oportunidades em desenvolvimento de software surgem aos profissionais de tecnologia da informação. Este artigo visa apresentar duas possibilidades no desenvolvimento de software voltados a smartphones, sendo estes os aplicativos nativos e os aplicativos web. Ambos são descritos de forma a evidenciar suas características de modo a permitir um entendimento das diferenças presentes nestas plataformas. São apresentados também alguns exemplos de demandas de mercado que surgem com a popularização dos smartphones, e por fim são citados possíveis trabalhos futuros aos interessados em continuar direcionando seus estudos nesta área de conhecimento.
Palavras-chave: Smartphones, Aplicativos Nativos, Aplicativos Web e Dispositivos Móveis
1. Introdução
Nos últimos anos temos presenciado um crescimento de vendas dos chamados smartphones, ou dispositivos móveis capacitados a realizar ligações telefônicas, instalar e executar aplicativos disponibilizados na internet. Rapidamente os smartphones estão substituindo os telefones celulares convencionais por oferecerem, entre outros recursos, uma grande variedade de aplicativos que atendem diversas necessidades do público em geral.
Dentre os aplicativos voltados a smartphones, podemos enumerar principalmente dois tipos de plataformas, os aplicativos chamados nativos e os web. Aplicações nativas são aquelas suportadas de acordo com o sistema operacional presente nos aparelhos móveis, enquanto que
aplicações web necessitam de navegadores de internet, tais como os presentes nos computadores pessoais, para serem utilizadas.
O objetivo deste artigo é apresentar dois tipos de aplicativos voltados para smartphones, nativos e web, de forma a diferenciar as duas plataformas e explorar a visão de mercado e tendências futuras nesta área.
2. Smartphones
São chamados smartphones os telefones celulares que oferecem alta capacidade de processamento, uma grande variedade de aplicativos e conexão com a internet. Smartphones modernos são capazes de se conectar na internet, possuem telas sensíveis ao toque, câmeras digitais compactas, sistemas de localização por satélite GPS (Global Positioning System), entre outros recursos.
Em 1983, o Motorola DynaTAC 8000X recebeu aprovação da Federal Communications
Commission, órgão regulador da área de telecomunicações e radiodifusão dos Estados Unidos,
para se tornar o primeiro telefone portátil celular comercial. [2]. Em 1990 havia 12 milhões de assinantes de telefones móveis [3] e no final de 2011 o número alcançaria 5,6 bilhões [4].
Smartphones estão se tornando rapidamente uma alternativa viável a telefones celulares, PDAs (Personal Digital Assistent), Tablets e laptops por oferecerem recursos de telefonia,
como voz e SMS (Short Message Service) em conjunto com aplicativos conectados na internet, funcionalidades multimídia, capacidade de alto processamento de dados e funcionalidades de GPS embutidos. [5] Outro ponto interessante que contribui para a adoção dos smartphones modernos é a possibilidade de interação com as diversas redes sociais, como youtube, facebook,
twitter etc.
3. Aplicativos de Software
De acordo com Brookshear [1997], "aplicativo de software consiste de programas que executam tarefas específicas para utilização em máquinas. Exemplos de aplicativos de software incluem planilha eletrônica, sistemas de banco de dados, sistemas de editoração eletrônica, programas de desenvolvimento de software e jogos."
Como dito por Brookshear, aplicativos de software são construídos com um objetivo específico, ou seja, podemos dizer que estes se destinam a auxiliar o usuário naquilo a que se propõe. Nos smartphones há uma gama crescente de aplicativos de software, entre eles os nativos e web, com as mais diversas finalidades.
Aplicação nativa/embarcada é um software desenvolvido para executar em uma plataforma específica. Os arquivos resultantes da compilação do aplicativo devem ser instalados diretamente no sistema operacional, tais como apresentação, processamento e armazenamento de dados.
É possível a manipulação de dados off-line, ou seja, armazenados em um banco de dados no próprio aparelho, o que permite ao software nativo continuar funcionando mesmo em localidades onde não há acesso a internet. O hardware presente no dispositivo pode ser melhor utilizado, como o telefone, câmera, microfone, bluetooth e acelerômetro, pode tornar-se mais útil, fácil e interativo com esses tipos de aplicativos. Outro ponto positivo é a melhor experiência com o usuário, ao se desenvolver nativamente pode-se explorar recursos mais avançados aos usuários, como a tela sensível ao multi-toque e efeitos visuais dos componentes da aplicação. Em geral os jogos para smartphones são desenvolvidos com esta finalidade.
Na maioria das vezes o poder de processamento dos aparelhos móveis são bem utilizados em aplicações específicas para a plataforma, permitindo assim a um rápido tempo de resposta levando a mais agilidade no uso destes aplicativos. Também é possível o acesso aos dados presentes no aparelho, como por exemplo: a agenda telefônica, câmera e outros aplicativos, possibilitando a integração entre as aplicações existentes no aparelho.
Desenvolver software específico requer linguagem de programação específica como
Objective-C na plataforma iOS (http://www.apple.com/ios) da Apple, Java na plataforma Android (http://www.android.com) do Google ou C# na plataforma Windows Phone (http://
www.microsoft.com/windowsphone) da Microsoft, o que pode tornar o investimento mais alto no início do projeto por exigir treinamento para as plataformas selecionadas e a consequente duplicação da mesma aplicação em ambas plataformas. Outro exemplo de dificuldade em se desenvolver este tipo de aplicativo está relacionada com a distribuição entre os usuários e as atualizações de versões. Torna-se necessário uma interação do usuário para manualmente receber o mesmo aplicativo com novos recursos ou permitir que isto seja feito de maneira automática.
Nas lojas de aplicativos on-line dos sistemas operacionais iOS e Android há milhares de aplicativos que atendem a objetivos variados, desde jogos até aplicativos de escritório. O gráfico abaixo apresenta o crescimento estimado em um período de 6 meses de aplicativos nas lojas virtuais da Apple (http://store.apple.com) e do Google (https://play.google.com). O Windows
Phone, sistema operacional móvel da Microsoft ainda está no começo do seu desenvolvimento e
Figura 1 - Quantidade de aplicativos em Android e iOS [6]
3.2. Aplicativos de Software Web
Acessado geralmente por meio da rede mundial de computadores (internet) e desenvolvido com linguagens suportadas por navegadores, tais como, HTML, CSS, JavaScript, Flash, este tipo de
software é denominado aplicativo web.
No processo de produção desses aplicativos web, voltados para smartphones, deve-se levar em consideração sua alta popularidade, que permite uma proliferação maior de usuários em comparação com os aplicativos nativos. Isto é devido aos smartphones modernos possuírem navegadores de internet, não sendo necessário nenhuma instalação adicional de aplicativo, o que facilita também a atualizações dos aplicativos web de maneira automática.
Para permitir a execução satisfatória dos aplicativos web nos diversos smartphones presentes no mercado faz-se necessário que o aparelho sempre esteja conectado à internet, de preferência deve-se ter uma velocidade de conexão satisfatória para permitir a rápida troca de dados com os servidores de páginas para não prejudicar a experiência do usuário.
Apesar dos aplicativos web executarem em navegadores de internet, há pontos que exigem a atenção dos desenvolvedores, como por exemplo o tamanho da tela dos dispositivos móveis exigindo testes e adequações para o bom funcionamento nos diversos smartphones do mercado. Outro ponto se refere as diferentes versões de navegadores, seja de diferentes fabricantes ou mesmo por versões distintas do mesmo navegador, as aplicações web podem apresentar aspectos indesejáveis devido ao difícil controle quanto as diferenças dos navegadores.
Atualmente uma nova versão da linguagem HTML (Hyper Text Markup Language) , chamada HTML5, está começando a ser utilizada e seus novos recursos estão sendo implementados nos principais navegadores do mercado, tais como, Chrome 19.0 (https://
www.google.com/chrome), Firefox 12.0 (http://www.mozilla.org/pt-BR/firefox/fx/), Opera 11.64 (http://www.opera.com/), Safari 5.1 (http://www.apple.com/safari/) e Internet Explorer 9.0 (http://windows.microsoft.com/ie9). Uma interessante característica presente na nova versão da HTML é a capacidade armazenar em cache parte ou toda uma aplicação web. Com este recurso será possível continuar acessando uma aplicação web mesmo quando não há disponibilidade de conexão com a internet e permitirá um ganho no desempenho das aplicações web pois haverá necessidade de efetuar o download somente das páginas que tiveram seus conteúdos modificados.
4. Demandas do Mercado
Conexões móveis em todo o mundo experimentará um crescimento constante até 2015, quando deverão chegar a 7,4 bilhões. [4], resultando em um grande interesse nesta área por parte de empresas em diversos setores, levando-as a buscarem sua participação neste mercado. Como alguns exemplos podemos citar: a) varejistas exporem suas lojas nos dispositivos móveis; b) empresas com vendas externas se beneficiarem dos recursos dos smartphones e integrarem seus
software corporativo aos aplicativos; c) instituições bancárias oferecem aplicativos que acessem
os dados de contas bancárias de clientes pelo smartphone; d) empresas investirem em jogos nos aparelhos móveis e podem ser bem aceitos mundialmente; e) empresas de comunicação disponibilizarem conteúdos em plataformas móveis etc
De acordo com o Gartner [7], as vendas de smartphones a consumidores finais dispararam no quarto trimestre de 2011 alcançando 47,3% de crescimento em comparação com o mesmo período de 2010, o que resulta em novas oportunidades aos profissionais e empresas do ramo da tecnologia da informação, seja com a necessidade de aplicativos nativos ou web, as empresas querem operar seus negócios também nos dispositivos móveis permitindo uma maior abrangência de clientes e consequente aumento de lucros. Aplicativos para saúde, são um exemplo de mercado em expansão nos Estados Unidos, é previsto que seu crescimento seja de quase 100% em 2012, alcançando US$ 1,3 bilhões, comparados com US$ 718 milhões em 2011 [8].
5. Resultados Obtidos
Ao se apresentar as características e diferenças, notamos um maior custo inicial no desenvolvimento nativo em comparação ao web, visto que são necessários conhecimentos específicos para os diversos sistemas operacionais dos smartphones, para se desenvolver nativamente, mas nas aplicações web basta se desenvolver com as já conhecidas linguagens HTML, CSS e Javascript.
Atualmente existem frameworks que facilitam no desenvolvimento nativo em
smartphones, por exemplo, a framework Rhodes [9] permite o desenvolvimento em uma única
linguagem de programação e a compilação em código nativo para iOS, Android, Windows
Phone, entre outros. Outro exemplo Titanium [10] se utiliza das linguagens HTML, CSS e
Javascript para a construção de aplicativos e disponibiliza ferramentas para a conversão em código nativo para os smartphones. Com a framework PhoneGap [11] também é possível o uso da linguagem HTML, CSS e Javascript para a criação de aplicações nativas permitindo inclusive o acesso a recursos específicos dos sistemas operacionais móveis. Assim é possível agilizar o aprendizado dos desenvolvedores diminuindo o custo da criação de aplicações nativas devido ao uso de linguagens populares. Outro ponto favorável com o uso das frameworks citadas acima é a construção automática de código nativo em diversas plataformas mesmo quando o desenvolvedor não possui os conhecimentos específicos necessários.
6. Conclusão
Com o crescimento mundial das vendas de smartphones, observamos uma tendência de mercado a ser explorada pelos profissionais e empresas de tecnologia da informação no desenvolvimento de software para estes dispositivos.
Ao longo do trabalho foi apresentado duas possibilidades de aplicações, as nativas e web. Nativas são aquelas aplicações construídas para executarem diretamente no sistema operacional dos aparelhos tais como iOS da Apple, Android do Google e Windows Phone da
Microsoft. Aplicações web são desenvolvidas para serem interpretadas pelos navegadores. Cada
tipo pode ser utilizada dependendo da necessidade, há casos em que as aplicações nativas são mais recomendadas como em jogos por exemplo devido ao melhor tempo de resposta das ações do usuário, já em lojas virtuais as aplicações web são mais recomendadas, pois exigem uma atualização constante do conteúdo online.
7. Estudos Futuros
Como trabalhos futuros se aplicam alguns tópicos, tais como, um estudo do custo de desenvolvimento entre aplicativos nativos e web, um estudo das frameworks para facilitar a criação de aplicações nativas em smartphones e um comparativo de usabilidade entre estes dois tipos de aplicativos.
Uma análise mais aprofundada pode ser feita quanto ao investimento na criação de
software para smartphone. Ter experiência de desenvolvimento nas já consolidadas linguagens
interpretadas pelos navegadores populares (HTML, CSS, Javascript) facilita a criação de aplicativos web, mas é necessário investir em qualificação profissional ao optar aplicações nativas/embarcadas pois se trata de tecnologia com poucos anos de mercado.
Algumas frameworks propoem a criação de aplicativos em uma linguagem única e permitem a tradução em código nativo para a maioria dos sistemas operacionais móveis do mercado. Utilizando deste argumento é possível analisar o impacto do uso deste tipo de arquitetura na produção de software para smartphones em comparação com o desenvolvimento tradicional.
Outro tema que pode ser explorado é a comparação aprofundada de usabilidade entre as aplicações nativas e web. Visto que as aplicações nativas oferecem alguns pontos exclusivos, como o uso do hardware local como câmera, acelerômetro, banco de dados, entre outros. Enquanto que nas aplicações web exploram menos desses recursos nos dispositivos.
8. Referências
[1] Brookshear, J. G. (1997), Computer Science: An Overview, Fifth Edition, Addison-Wesley, Reading, MA.
[2] "RETROBRICK - the home of vintage and rare mobile phones" http://www.retrobrick.com/ moto8000.html (acessado em 17/04/2012)
[3] "Worldmapper: The world as you've never seen it before" http://www.worldmapper.org/ display.php?selected=333 (acessado em 17/04/2012)
[4] "Gartner Says Worldwide Mobile Connections Will Reach 5.6 Billion in 2011 as Mobile Data Services Revenue Totals $314.7 Billion" http://www.gartner.com/it/page.jsp?id=1759714 (acessado em 17/04/2012)
[5] "Global Mobile Phone & Smartphone Market (2010 - 2015)" http:/ /www.researchandmarkets.com/reports/1545615/
global_mobile_phone_and_smartphone_market_2010 (acessado em 15/03/2012)
[6] "App Genome Report - February 2011" https://www.mylookout.com/appgenome (acessado em 19/04/2012)
[7] "Gartner Says Worldwide Smartphone Sales Soared in Fourth Quarter of 2011 With 47 Percent Growth" http://www.gartner.com/it/page.jsp?id=1924314 (acessado em 19/04/2012)
[8] "The Market For Mobile Healthcare Applications Will Grow To $US 1.3 billion in 2012 | research2guidance" http://www.research2guidance.com/us-1.3-billion-the-market-for-mhealth-applications-in-2012/ (acessado em 19/04/2012)
[9] "RhoMobile mobilize your enterprise apps" http://www.rhomobile.com/products/rhodes/ (acessado em 01/05/2012)
[10] "Titanium Developer | Appcelerator Titanium Development Company" http:// www.anubavam.com/titanium-developer (acessado em 01/05/2012)
Desenvolvimento Orientado a Testes de Aceitação
José Inácio Ferreira Filho, Olissea Artiaga da Silva1Pontifícia Universidade Católica de Goiás (PUC - Goiás)
Av. Universitária, nº 1.069, Setor Leste Universitário (Área 4, Blc A, Campus I) – Goiânia – GO – Brasil
joseinacio@msn.com, olissea@gmail.com
Abstract. In an increasingly competitive market, organizations are seeking means to improve the quality of its products, reducing cost, time spent on rework and production thereof, and to achieve this goal are adopting methods of developing a vision code high quality, sustainable and above all customers want reliable software that will help them be more productive, thus make more money, a software that maintain or improve the operational capacity, to undertake a market, and so on. The Driven Development Acceptance Testing (TDD acceptance) helps developers create a high quality software that meets business needs in a reliable way TDD helps ensure the technical quality of software being developed.
Resumo. Em um mercado cada vez mais competitivo, as organizações estão buscando meios que permitam aumentar a qualidade dos seus produtos, reduzindo o custo, o tempo e o retrabalho na produção dos mesmos. Para atingir este objetivo, as empresas estão adotando métodos de desenvolvimento que visam um código de alta qualidade, sustentável e acima de tudo confiável. Os clientes querem softwares que os ajudem a ser mais produtivos, conseqüentemente, que sejam mais rentáveis e mantenham ou melhorem a capacidade operacional. O Desenvolvimento Orientado a Testes de Aceitação (TDD aceitação) ajuda os desenvolvedores a criar um software de alta qualidade que atenda às necessidades do negócio de uma forma confiável. O TDD ajuda a garantir a qualidade técnica do software a ser desenvolvido. 1. Informações Gerais
A qualidade do software está diretamente ligada à existência de defeitos. O teste de software consiste na busca desses defeitos que podem ser inseridos por diversos motivos como, por exemplo, a especificação incompleta ou incorreta dos requisitos, ou requisitos não passíveis de implementação, ou durante a manutenção de um sistema já existente.
Segundo Myers, autor do livro The Art of Software Testing, o principal objetivo do teste é revelar a presença de erros no produto. Existem duas abordagens de testes, testes caixa branca, no qual através do código fonte avalia-se o comportamento interno do software (parte estrutural) e os testes caixa preta, que avaliam o comportamento externo do software (parte funcional), ou seja, os testes podem ser feitos através da verificação do código ou através da utilização do produto para a busca dos ―bugs‖.
Este artigo tem como objetivo abordar os testes caixa branca, demonstrando a técnica de desenvolvimento orientado a testes de aceitação (ATDD). A técnica direciona o comportamento interno do sistema com a criação de testes em linguagem comum que, interpretados por um framework, colaboram para o desenvolvimento bem estruturado.
O ATDD assim como o Desenvolvimento Orientado a Testes (TDD) baseia-se na criação de testes antes do código, sendo que no ATDD os testes representam as expectativas acerca do comportamento desejado para o sistema. São criados um ou mais testes de aceitação para a funcionalidade a ser desenvolvida, estes testes são discutidos e levantados juntamente com os responsáveis pelo negócio, ou seja, aqueles que são responsáveis por definir e especificar os requisitos desejados no sistema.
Considerando que o backlog é uma lista de itens que formam uma história, e que existe uma priorização desses itens a serem desenvolvidos para um sistema, o responsável pelo negócio é aquele capaz de definir o backlog, termo também utilizado em Extreme Programming (XP), metodologia ágil de desenvolvimento.
Na aplicação dessas técnicas consideradas análogas, inicia-se escrevendo um teste que deverá falhar. Isso demonstra que a base do código escrito ainda não possui um recurso totalmente implementado. Após o teste de unidade falhar, o código de produção é então escrito para fazer com que o teste passe.
A parte do código que passa no teste é refatorada, eliminando duplicações para deixar o código-fonte mais limpo, legível e com melhor design. O Test Driven Development (TDD), ou Desenvolvimento Orientado a Teste, tem fases curtas, é executado um teste por vez para cada unidade implementada. O TDD não é uma técnica de teste e sim uma prática de programação. Esta prática leva à automação dos testes unitários. Este tipo de desenvolvimento está ligado à definição das expectativas quanto à funcionalidade, fazendo que estas expectativas em relação ao comportamento do código guiem a implementação que está sob teste.
Definindo os testes em formato suportado por um framework de automação de testes funcionais, como, por exemplo, o SpeckFlow, é possível que os desenvolvedores escrevam o código de suporte (―fixtures‖) da forma em que será implementada a funcionalidade.
O artigo irá explicar o ciclo de ATDD com mais detalhes, mostrando exemplos de testes utilizando ATDD e TDD durante o processo de desenvolvimento de software.
2. Entendendo o ATDD
Para o entendimento do Desenvolvimento Orientado a Testes de Aceitação será utilizado um exemplo básico de um sistema login em que a aplicação realiza três ações básicas, verifica se existe o cadastro do usuário e senha informados, permite criar um usuário com nome e senha válidos e efetua login com nome de usuário e senha válidos. Iniciamos definindo as ações e as respostas esperadas do sistema.
A tentativa de efetuar login com uma conta de usuário ou senha inexistente irá resultar na mensagem de erro:
Ao criar uma conta de usuário com nome de usuário e senha valida é exibida a mensagem:
Conta Criada com Sucesso
E quando for efetuando o login com uma ―Conta Criada com Sucesso‖ obteremos a mensagem:
Bem-vindo!
Definido o esboço inicial das ações e respostas do sistema a ser desenvolvido, temos um ponto de partida para entendermos a utilização do ATDD.
Figura 1. Ações e Respostas do Sistema.
Inicialmente temos um sistema que realiza ações básicas para login de usuário e no próximo item priorizado no backlog aplicaremos o Desenvolvimento Orientado a Testes de Aceitação.
Para um sistema se login mais seguro criamos o nosso próximo item a ser priorizado no backlog:
Figura 2. Próximo Item de priorização no Backlog.
3. O Ciclo do Desenvolvimento Orientado a Testes de Aceitação
Todas as funcionalidades e melhorias do código iniciam-se com um teste. Adicionamos um teste e compilamos observado-o falhar intencionalmente para que ele aponte exatamente o que não está funcionando, logo será desenvolvido o código da forma mais simples para que o teste passe. Ao passar a primeira vez a parte do código que passou e verificada e refatorada. Após refatorado, o trecho do código é executado novamente e ao passar seguimos com a implementação de um novo teste para a realização de uma nova parte de código e assim por diante.
O desenvolvedor deve conhecer cada item e cada história discutida nos requisitos e entender também as exceções do sistema. Essa técnica força o desenvolvedor a escrever testes focados nos requisitos discutidos.
Cada teste elaborado deve cobrir uma funcionalidade ou melhoria que ainda não foi implementada, então esse teste deverá falhar na primeira execução, garantindo que não passará sem a necessidade de alteração do código. A falha no teste faz com que o desenvolvedor aplique o código necessário e suficiente para passar no novo teste, sem se preocupar com a elegância do código que depois será refatorado. Veremos com mais detalhes cada parte deste ciclo.
Figura 3. Ciclos TDD por Kent Beck e ATDD por James Shore
4. Discutir os Requisitos
Na Reunião de Planejamento (Planning Meeting) acontece a discussão da história acerca do tratamento para utilização de senhas seguras. Nesta reunião os
responsáveis pelo negócio são indagados para que sejam levantados os critérios de aceitação para implementação desse sistema.
Considerando o item priorizado no backlog veja exemplos de questionamentos que podem ser feitos no momento da reunião:
”Caso o usuário informe uma senha insegura como o sistema deve reagir?”
“Que estrutura de senha você considera segura? Os símbolos seriam aceitos no cadastro da senha?”
“Quantos caracteres serão permitidos no cadastro da senha?”
“Deve ser sugerido um dicionário de substituições óbvias que atendam aos critérios e que ainda possam ser segura, como 's3nh@s'?”
“Como o sistema irá se comportar com as contas já existentes?”
“O que será necessário para considerar que a funcionalidade está 'funcionando' adequadamente?”
A discussão mostra que por mais simples que pareça, existem muitos detalhes importantes para a implementação de um sistema e que essa discussão faz o responsável pelo negócio pensar melhor sobre suas expectativas e consiga definir critérios de aceitação para este sistema.
Novas necessidades podem surgir na Reunião de Planejamento como, por exemplo, forçar os usuários com contas existentes a atualizarem sua senha. A definição dos critérios de aceitação colabora para que fique bem definido que a atualização da senha para contas já existentes será uma nova história que será consolidada em outro momento.
A compreensão do que os interessados no negócio esperam que o sistema deva ou não fazer fica mais clara. Assim fica definido um esboço dos testes de aceitação juntamente com os interessados no negócio.
Os testes são escritos em linguagem comum, veja:
Figura 4. Senhas válidas que resultam em CONTA CRIADA COM SUCESSO
Figura 5. Senhas inválidas que resultam em ERRO
Figura 6. Mensagem de erro caso informado Senha inválida
5. Elaborar os Testes no Formato Interpretado pelo Framework
Elaborado o esboço dos testes é necessário reescrevê-los no formato interpretado pelo framework de automação de testes. Atualmente existem vários frameworks que suportam especificação de testes a priori. Será utilizado o formato do Specflow nos exemplos a seguir.
Os testes no Framework SpeckFlow podem ser escritos num arquivo TXT da seguinte forma:
Caso de Teste Ação Argumento
Verificar senhas válidas e inválidas Senha deve ser válida s3nh@s Senha deve ser válida @0101ab Senha deve ser válida p@wss w0rd Senha deve ser válida 53nh*s Senha deve ser válida !$&ab123 Senha deve ser válida *1234cd Senha deve ser inválida senhas Senha deve ser inválida 123456 Senha deve ser inválida &*$@ Senha deve ser inválida _-/abcd Senha deve ser inválida Senha Senha deve ser inválida @c3ss0 Senha deve ser inválida s3nhas Senha deve ser inválida @@@101
Tabela 1. Padrão de Escrita dos Casos de Teste no SpeckFlow
No momento da especificação dos testes o foco deve ser os testes para validação do que é desejado pelo cliente e não os detalhes da implementação. Na próxima parte do ciclo serão associados os testes ao código.
6. Desenvolver o Código e Associar aos Testes
Utilizando a abordagem de desenvolvimento orientado a testes, aqueles de aceitação são executados e irão falhar. Utilizando o Speckflow os testes irão falhar com mensagens de erro apresentada pelo Framework. Veja:
Figura 7. Mensagem de Erro apresentada pelo Framework
A falha é perfeitamente normal, ainda não existe implementação para a palavra-chave no framework. Os testes inicialmente foram escritos sem a pretensão de automação e agora é necessário pensar na automação desses testes criando e escrevendo palavras-chaves que conectem os testes ao código. Semelhante em todos os Frameworks, adicionamos o código a um Fixture, elemento o qual associa os testes ao código.
Caso de Teste Ação Argumento Argumento
Verificar senhas válidas e Criar login Jose s3nh@s
Inválidas
Mensagem deve ser
CONTA CRIADA
COM SUCESSO
Tentativa de efetuar login Jose s3nh@s
com os dados
Mensagem deve ser Bem-vindo
Criar login Jose @@@101d
Mensagem deve ser
CONTA CRIADA
COM SUCESSO
Tentativa de efetuar login Jose @@@101d
com os dados
Mensagem deve ser Bem-vindo
Tabela 2. Reescrita dos Casos no SpeckFlow
O SpeckFlow permite criar palavras-chaves a partir de outras palavras-chaves já existentes, veja:
Caso de Teste Ação Argumento Argumento
Senhas devem ser válidas [Arguments] ${senha}
Criar login Jose ${senha]
Mensagem deve ser
CONTA CRIADA COM SUCESSO
Tentativa de efetuar login Jose ${senha}
com os dados
Mensagem deve ser Bem-vindo
Senhas devem ser inválidas [Arguments] ${senha}
Criar login Jose ${senha}
Mensagem deve ser A senha deve ter pelo menos 6 caracteres e conter pelo menos uma letra, um número e um símbolo.
Tentativa de efetuar login Jose ${senha} com os dados
Mensagem deve ser Acesso negado
Tabela 3. Criando palavras-chaves a partis de outras existentes
Não existe um sintaxe específica para o Framework SpeckFlow, mas é necessário uma associação das palavras-chaves usadas no testes ao código executável.
Implementadas as palavras-chaves, os testes são executados novamente para a obtenção de resultados mais significativos. Esses novos resultados não trarão somente mensagem de erro dizendo que as palavras-chaves não foram implementadas, o resultado neste momento são mensagens como:
Figura 8. Mensagem para Palavras-Chaves não Implementadas
O teste falha agora, pois a funcionalidade ainda não está implementada no sistema. As senhas ainda podem ser inseguras. Sabendo que os testes falhariam, pois nada foi feito para que os mesmos passassem, existe a possibilidade de que tenha sido implementado este teste incorretamente. Dessa forma, é possível que ele passe mesmo que nenhum código tenha sido escrito.
Ver o teste falhar e certificar que ele está falhando pelo motivo correto é a forma de verificar o teste.
7. Implementando Código com TDD
Inicialmente são executados os testes unitários para garantir que o código corresponde às expectativas atuais.
Observando o conteúdo dos testes unitários relacionados à criação de uma nova senha encontramos testes unitários com os seguintes nomes:
Figura 9. Testes Unitários
A impressão é a de que já existe código para manipular senhas inseguras. Os testes unitários cumprem uma de suas tarefas documentando o comportamento da base de código existente.
Analisando melhor o código verifica-se a existência de código escrito para determinar se a senha é valida ou não, porém este não está sendo usado no momento. O método que certifica se a senha é valida ou não é chamado por nenhum componente do código, um trecho de código morto.
Analisando os demais testes unitários identificamos os relacionados à criação de novas contas de usuários com senha, observe:
Figura 10. Teste Unitário para Verificar Criação de Novas Contas
O teste cria uma nova conta com nome de usuário ―novaconta‖ e senha ―s3cr3t!@‖ verificando então se o método retorna ―success‖.
Quando criado um assert para criação de conta com senha inválida esse teste irá falhar, veja:
Figura 11. Teste Unitário para Verificar Criação de Contas com senha inválida
No design do projeto assumi-se que o método ―create‖ será retornado quando solicitada a criação de uma conta com senha inválida. Essa implementação ocorreu enquanto eram escritos os testes unitários. Percebemos que a técnica de Desenvolvimento Orientado a Testes está mais ligada à arquitetura do que ao teste de software em si.
Quando os testes unitários forem chamados com os parâmetros ―novaconta‖ e ―a‖ o método ―create‖ retornará ―sucess‖. Quando todos os testes unitários são executados com Conta Criada com SUCESSO as alterações são salvas no repositório.
8. Demonstrando os Testes Exploratórios
Ao tentarmos criar uma nova conta com a senha que possui o caractere ―&‖ ―&>_/ab0123‖ vejamos o que acontece:
Figura 12. Teste Cria Nova Conta com senha “&>_/ab0123”
A resposta do sistema é a seguinte:
Figura 13. Resposta ao tentar usar a senha &>_/ab0123
O Shell tenta interpretar alguns caracteres especiais como, por exemplo, ―&‖. Isto ocorre sempre, não somente para a aplicação em questão. Temos esta reação porque o caractere tem significado para o Shell. O tratamento para este problema tem de ser feito por meio da aplicação. O sistema cuida para que o usuário não possa usar tais caracteres.
Repetindo a ação, mas inserindo aspas simples, vejamos o que acontece:
Figura 14. Resposta ao tentar a senha entre aspas simples
O sistema retorna:
Figura 15. Resposta do sistema ao inserir senha com aspas simples
Ao se inserir aspas simples, o Shell não tenta interpretar o caractere ―&‖.
Com isto, é observado que os testes de aceitação permitem identificar brechas que não foram pensadas inicialmente. Assim que a equipe concorde que o sistema corresponde às expectativas, ele é apresentado aos interessados no negócio.
Os riscos em potencial, identificados ao longo da implementação e exploração do sistema são apresentados como, por exemplo, a questão do caractere ―&‖.
10. Conclusão
A discussão do requisito no ciclo ATDD proporciona melhor entendimento das necessidades do cliente, além de uma antecipação em relação às suas expectativas, evitando assim que ao final do projeto seja entregue um software que fuja do que foi solicitado pelo cliente. O TDD e o ATDD são formas de conhecer melhor essas necessidades e de se antecipar a essas expectativas, com a diferença de que o TDD antecipa o comportamento do código (parte interna do código) e o ATDD se antecipa ao comportamento do software (verifica se aquilo que é desenvolvido atende a uma particularidade do software).
O Desenvolvimento Orientado por Testes de Aceitação envolve a escrita de testes a partir das indagações feitas aos interessados no negócio. Os testes são escritos em uma linguagem comum, podendo ser facilmente interpretados sem a necessidade de conhecimento avançado, esses testes também podem ser utilizados como documentação, garantindo que o solicitado foi implementado. A especificação de testes de aceitação dá mais segurança no requisito que se espera do sistema a ser desenvolvido e também cria um escopo de desenvolvimento bem definido.
Este tipo de desenvolvimento faz com que seja desenvolvido o código fonte da forma mais simples possível. O design é evolutivo, o desenvolvimento é feito em partes, para cada problema novo são adicionadas novas características ao design. O código desenvolvido fica limpo e conciso. Dificilmente existirão quebras pois os testes mostram caso uma falha seja inserida. O tempo de implementação pode aumentar, mas em contrapartida a manutenção ou evolução do sistema é facilitada.
11. Referências
Beck, Kent (2003). Test-Driven Development: By Example. Addison-Wesley. Carmen Zannier , Hakan Erdogmus, Lowell Lindstrom(2004). Extreme
Glenford J. Myers(2008), The Art of Software Testing.
Lean-Agile Acceptance Test-Driven Development: Better Software Through Collaboration (Net Objectives Lean-Agile Series) by Ken Pugh (Jan 1, 2011)
Watt, Richard J. and Leigh-Fellows, David. ―Acceptance Test Driven Planning‖ http://testing.thoughtworks.com (Jan 2012)
Paul Gerrard, Neil Thompson (2008). Risk-Based E-Business Testing.
PRESSMAN, Roger S(2002). Engenharia de Software. Makron Booksdo Brasil Editora Ltda.
SOMMERVILLE, Ian(2007). Engenharia de Software, 8ª edição / Ian Sommerville São Paulo: PearsonAddison ± Wesley.
Test-Driven Development in Microsoft .NET (Microsoft Professional) by James W. Newkirk and Alexei A. Vorontsov (Abr 14, 2004)
Test-Driven Development no Rails Unit Tests — Simples Ideias. Por Nando Vieira. http://simplesideias.com.br/tdd-no-rails-unit-tests/ (Jan. 2012)
Estudo sobre a Implantação de um Modelo de Governança de
Tecnologia da Informação com COBIT e ITIL
Ana Clara Peixoto de Castro
Pontifícia Universidade Católica de Goiás (PUC-GO) Goiânia – GO - Brasil
ac.anaclara@gmail.com
Abstract. This paper is about IT Governance and has its focus over the best practices for IT Services Management and the best practices for ITIL and COBIT Information Technology Governance, respectively. Over this article it's possible to notice the similarity between these practices, what provides a better vision about the IT Governance e it's value in organizations. This review will show several aspects that induce the implementation of IT Governance in organizations.
Resumo. Este artigo versa sobre a Governança de TI tendo como foco as melhores práticas para Gerenciamento de Serviços de TI e as melhores práticas para a Governança de Tecnologia da Informação ITIL e COBIT, respectivamente. Através deste, é possível notar a semelhança entre essas práticas, que proporciona uma melhor visão sobre a Governança de TI e sua importância nas organizações. Este estudo abordará os vários aspectos que influenciam para que a Governança de TI seja implementada nas organizações.
1. Informações Gerais
Com o passar dos anos, os processos e serviços internos tornaram-se cada vez mais complexos e a execução destes demandava maiores esforços de todos na organização. Neste contexto, surge a Tecnologia da Informação com o objetivo de apoiar a execução dos processos e serviços e, atualmente, contribui também para a tomada de decisões em todas as áreas da organização.
Para que fosse possível a gestão estratégica de todas as áreas da organização de forma que todos os proprietários fizessem parte desta, surgiu a Governança Corporativa. Segundo o IBGC (Instituto Brasileiro de Governança Corporativa), “Governança Corporativa é o sistema pelo qual as organizações são dirigidas, monitoradas e
incentivadas, envolvendo os relacionamentos entre proprietários, conselho de administração, diretoria e órgãos de controle. As boas práticas de governança corporativa convertem princípios em recomendações objetivas, alinhando interesses com a finalidade de preservar e otimizar o valor da organização, facilitando seu acesso ao capital e contribuindo para a sua longevidade.”. Em poucas palavras, a
Governança Corporativa objetiva alinhar os interesses dos acionistas e executivos da organização [IBGC, 2012].
Diante destes fatos, notou-se que a Tecnologia da Informação é fonte de investimentos e quando alinhada aos objetivos estratégicos da organização, agrega valor
ao negócio. Surgiu então a necessidade de todos os líderes desenvolverem a competência de extrair valor da TI para que esta seja utilizada de forma eficaz dentro da organização.
Implementações de TI requerem investimentos contínuos em busca de resultados imprevisíveis. A especificação das decisões e responsabilidades pelos investimentos e utilização efetiva da TI define a Governança de Tecnologia da Informação.
2. Governança de TI
A grande competitividade do mercado tem impulsionado as organizações a realizarem grandes investimentos em TI, tornando o sucesso dos seus negócios cada vez mais dependentes do sucesso da TI.
Neste contexto surge a Governança de TI, que visa à utilização e gestão da TI alinhada aos objetivos estratégicos da organização de forma a garantir que a TI seja capaz de apoiar seus objetivos estratégicos, através do gerenciamento de serviços e produtos de Tecnologia da Informação de forma competitiva [DOROW, 2011].
As principais partes interessadas na Governança de TI são: - Conselho e executivo;
- Gerências de Negócio; - Gerência de TI;
- Auditores.
Os principais focos da Governança de TI são [COBIT, 2007]:
Figura 1. Focos da Governança de TI
Alinhamento estratégico: Integração da TI aos negócios da organização, agregando valor aos produtos e serviços auxiliando no posicionamento competitivo da empresa;
Entrega de Valor: Foco na entrega de qualidade dentro do prazo e custo acordados;
Gestão de Riscos: Busca incorporar à TI análise e resposta aos riscos, bem como conformidade de processos [Barcellos e Rodrigues, 2009];
Gestão de Recursos: Foco no investimento otimizado, ou seja, o uso e a alocação de recursos de TI que atendam as necessidades da empresa;
Mensuração de Desempenho: busca avaliar e divulgar o desempenho dos aspectos tratados pela TI [Barcellos e Rodrigues, 2009].
A figura abaixo representa a Estrutura da Governança de TI:
Figura 2. Estrutura da Governança de TI
Cobrindo toda a estrutura da Governança de TI, encontram-se as práticas, processos e diretrizes específicos da Governança de TI, ou seja, tudo o que é necessário para que sejam mantidos os principais focos desta Governança.
A sustentabilidade da Governança de TI na organização são todos os conjuntos de processos que estão relacionados à TI:
- Gestão de Serviços; - Desenvolvimento de Aplicações; - Segurança da Informação; - Gerenciamento de Projetos; - Planejamento de TI; - Sistema de Qualidade.
Por fim, na base estão as operações de TI que auxiliam para que os processos de TI sejam implementados segundo os conceitos da Governança de TI.
Para se implantar a Governança de TI não é necessário que sejam implementados todos componentes dela. Cada organização deve buscar aqueles que se adaptem à suas necessidades e, conforme a Governança de TI evolua na organização, outros componentes podem ser inclusos [FERNANDES, 2006].
Devido ao alto poder decisório da Governança de TI, esta deve ser de responsabilidade da alta administração (incluindo diretores e executivos) que a utilizará para assegurar que os recursos de TI contribuam para gerar competitividade e agregar valor à organização.
Várias empresas julgam os investimentos de TI como sendo de alto valor financeiro e utilizam este argumento como justificativa à baixa aquisição de serviços e produtos voltados à Tecnologia da Informação. Uma eficiente Governança de TI é capaz de direcionar os gastos com TI de forma estratégica, visando o aumento da qualidade dos produtos e dos processos garantindo maior competitividade no mercado e maiores lucros para a organização [WEILL, 2006].
Para implementação da Governança de TI, existem no mercado vários frameworks, modelos, normas e práticas para auxiliarem. O modelo mais abrangente é o COBIT (Control Objectives for Information and related Technology), que é baseado em boas práticas fortemente focadas nos controles e auxiliam a otimização dos investimentos em Tecnologia da Informação. Como apoio à Governança de TI, destacam-se a ITIL (Information Technology Infrastructure Library), CMMI (Capability Maturity Model Intregation), ISO/IEC 20000 e o PMBOK (Project
Management Body of Knowledge).
É possível criar um framework próprio utilizando estes modelos, normas e práticas em conjunto, levando sempre em conta os aspectos estruturais e culturais da organização.
2.1. COBIT
O COBIT surgiu em 1996 como um guia de melhores práticas de auditoria e Governança de TI e em 1998 foi estabelecido o IT Governance Institute (ITGI) - Instituto de Governança de TI para padronizar os pensamentos a respeito da Governança da Tecnologia da Informação nas organizações.
O COBIT (Control Objectives for Information and related Technology), como uma base de conhecimento para os processos de TI, está focado basicamente nos controles e auxilia a otimização dos investimentos em Tecnologia da Informação, assegurando que os recursos de TI estejam alinhados aos objetivos da organização. Desta maneira, faz com que a TI seja mais alinhada ao negócio, provendo um elo entre as expectativas com as responsabilidades de gerenciamento de TI.
De acordo com o próprio COBIT, sua missão é “pesquisar, desenvolver, publicar e promover um modelo de controle para governança de TI atualizado e internacionalmente reconhecido para ser adotado por organizações e utilizado no dia-a-dia por gerentes de negócios, profissionais de TI e profissionais de avaliação.” [COBIT, 2007]
O COBIT é focado em negócios, orientado a processos, baseado em controles e orientado por medições e composto por quatro domínios, trinta e quatro processos e estes possuem trezentos e dezoito objetivos de controle:
Tabela 1. Domínio Planejar e Executar
Processos Objetivos de
Controle
PO1 Definir um Plano Estratégico de TI 6
PO2 Definir a Arquitetura da Informação 4
PO3 Determinar as Diretrizes da Tecnologia 5
PO4 Definir os Processos, a Organização e Relacionamentos de TI 15
PO5 Gerenciar o Investimento de TI 5
PO6 Comunicar Metas e Diretrizes Gerenciais 5
PO7 Gerenciar os Recursos Humanos de TI 8
PO8 Gerenciar a Qualidade 6
PO9 Avaliar e Gerenciar os Riscos de TI 6
PO10 Gerenciar Projetos 14
Tabela 2. Domínio Adquirir e Implementar
Processos Objetivos de
Controle
AI1 Identificar Soluções Automatizadas 4
AI2 Adquirir e Manter Software Aplicativo 10
AI3 Adquirir e Manter Infraestrutura de Tecnologia 4
AI4 Habilitar Operação e Uso 4
AI5 Adquirir Recursos de TI 4
AI6 Gerenciar Mudanças 5
AI7 Instalar e Homologar Soluções e Mudanças 9
Tabela 3. Domínio Entregar e Suportar
Processos Objetivos de Controle
DS1 Definir e Gerenciar Níveis de Serviço 6
DS2 Gerenciar Serviços Terceirizados 4
DS3 Gerenciar o Desempenho e a Capacidade 5
DS4 Assegurar a Continuidade dos Serviços 10
DS5 Garantir a Segurança dos Sistemas 11
DS6 Identificar e Alocar Custos 4
DS7 Educar e Treinar os Usuários 3
DS8 Gerenciar a Central de Serviço e os Incidentes 5
DS9 Gerenciar a Configuração 3
DS10 Gerenciar os Problemas 4
DS11 Gerenciar os Dados 6
DS12 Gerenciar o Ambiente Físico 5
DS13 Gerenciar as Operações 5
Processos Objetivos de Controle
ME1 Monitorar e Avaliar o Desempenho de TI 6
ME2 Monitorar e Avaliar os Controles Internos 7 ME3 Assegurar a Conformidade com Requisitos Externos 5
ME4 Prover a Governança de TI 7
Os domínios do COBIT são definidos da seguinte forma:
“Planejar e Organizar (PO) - Provê direção para entrega de soluções (AI) e entrega de serviços (DS);
Adquirir e Implementar (AI) - Provê as soluções e as transfere para tornarem-se serviços;
Entregar e Suportar (DS) - Recebe as soluções e as torna passíveis de uso pelos usuários finais;
Monitorar e Avaliar (ME) - Monitora todos os processos para garantir que a direção definida seja seguida.” [COBIT, 2007]
Figura 3. Domínios do COBIT
O princípio básico do COBIT é fornecer um elo entre as expectativas dos Stakeholders com as responsabilidades relacionadas ao gerenciamento de TI, de maneira que facilite a Governança de Tecnologia de Informação agregando valor à TI e ao mesmo tempo, gerenciando os riscos em TI.
Figura 4. Princípios da Governança de TI
Tendo como base que o COBIT está focado no sucesso da entrega de produtos e serviços de TI, através do ponto de vista das necessidades do negócio e com o foco mais acentuado no controle que na execução, nota-se que sua preocupação é com o “que deve
ser feito” e não em como “deve-se fazer”. 2.2. ITIL
As melhores práticas do gerenciamento de serviços de TI evoluíram desde 1989, época da publicação dos primeiros elementos da ITIL (Information Technology Infrastructure
Library – Biblioteca de Infraestrutura de TI) pela CCTA (Central Computer
Telecomunications Agency), Agência de Processamento de Dados e Telecomunicações do Governo Britânico (atualmente o OGC – Office of Government Commerce) [MAGALHAES, 2005].
Tanto organizações públicas quanto privadas contribuíram com conhecimentos e experiências para o desenvolvimento da ITIL, o qual tem vindo a evoluir e a atualizar-se, primeiro pelo proprietário OGC, sendo atualmente e na maior parte pelo itSMF (IT Service Management Forum) a nível internacional. O itSMF é um fórum independente e sem fins lucrativos presente em muitos países, sendo globalmente relacionado e gerido com o propósito de divulgar, recolher e publicar as melhores práticas para a Gestão de Serviços TI, para estarem disponíveis em domínio público [MACFARLANE, 2005].
A versão inicial da ITIL constituiu-se de uma biblioteca de 31 livros, abrangendo todos os aspectos de gerenciamento de serviços de TI associados. Esta versão foi então revisada e substituída por 7 livros mais estreitamente ligados e consistentes. Esta segunda versão foi universalmente aceita e utilizada em vários países e por muitas organizações como base para o fornecimento de serviços efetivos de TI. Em 2007, a ITIL V2 (segunda versão) foi substituída por uma terceira versão (V3) melhorada e consolidada, constituída por cinco livros abrangendo o serviço de ciclo de vida.
Para se entender melhor o que vem a ser a ITIL (Information Technology
Infrastructure Library) ou Biblioteca de Infraestrutura de TI, é interessante ressaltar o
que ela não é. Ela não é uma metodologia, e sim um conjunto de melhores práticas para a gestão do ciclo de vida dos serviços em TI, com foco no negócio, que pode ser
adaptada às necessidades de cada organização. A ITIL também não é um manual de instruções a ser seguido, mas fornece os fundamentos e informações necessárias para criar e melhorar processos de TI.
Figura 5. Ciclo de Vida da ITIL
SegundoAs publicações da ITIL estão organizadas da seguinte maneira [CARTLIDGE, 2007]:
1. Service Strategy (Estratégia de Serviços) a. Gerenciamento Financeiro
b. Gerência de Demanda
c. Gerência de Serviços de Portifólio 2. Service Design (Projeto de Serviço)
a. Gerenciamento de Nível de Serviços b. Catálogo de Serviços c. Gerenciamento de Disponibilidade d. Gerenciamento da Segurança e. Gerenciamento da Capacidade f. Gerenciamento de Continuidade g. Gerenciamento de Fornecedores 3. Service Transition (Transição de Serviço)
a. Gerenciamento de Mudança b. Gerenciamento de Configuração
c. Gerenciamento de Liberação
4. Service Operation (operação de Serviço) a. Gerenciamento de Eventos
b. Gerenciamento de Incidentes c. Gerenciamento de Acesso
d. Gerenciamento de Requisição de Serviços e. Gerenciamento de Problemas
5. Continual Service Improvement (Melhoria Contínua de Serviço) a. Melhoria Contínua de Serviços de TI
Nota-se que adotar a ITIL significa melhorar a qualidade dos serviços prestados pela TI, assegurando que estes atendam as necessidades dos usuários e objetivos do negócio diminuindo os custos operacionais e garantindo a satisfação dos clientes. A ITIL possui regras e normas implícitas que enfatizam a capacidade de uma empresa criar maturidade, sendo aplicáveis somente no âmbito da TI e seus serviços.
3. Comparativo entre COBIT e ITIL
Tanto o COBIT quanto a ITIL definem-se como boas práticas que se preocupam com o que deve ser feito e não como deve ser feito para aperfeiçoar a Gestão de TI das organizações, tendo sempre como foco os objetivos de negócio das organizações.
A ITIL gerencia, de forma efetiva, os serviços de TI e o desempenho de sua infraestrutura para que a organização possa administrar suas operações de TI. Estabelece uma ponte entre o negócio e a TI pela melhoria contínua dos processos. O COBIT auxilia na otimização dos investimentos de TI e proveem métricas para avaliação dos resultados. Fornece informações para gerenciar processos baseados nos objetivos de negócio da organização.
Os processos do COBIT que estão ligados à ITIL pertencem ao Domínio Entregar e Suportar:
DS1 - Definir e Gerenciar Níveis de Serviço
DS2 - Gerenciar Serviços Terceirizados
DS3 - Gerenciar o Desempenho e a Capacidade
DS4 - Assegurar a Continuidade dos Serviços
DS5 - Garantir a Segurança dos Sistemas
DS8 - Gerenciar a Central de Serviço e os Incidentes
DS9 - Gerenciar a Configuração
DS10 - Gerenciar os Problemas
DS12 - Gerenciar o Ambiente Físico
Podemos notar que o escopo do COBIT é mais amplo que o da ITIL, pois o Gerenciamento de Serviços de TI está contido no COBIT. Portanto, para se ter Governança de Tecnologia de Informação é necessário que se tenha um bom gerenciamento de serviços.
As práticas citadas buscam uma melhor gestão da Tecnologia da Informação na empresa, porém cada uma focaliza suas qualidades em objetivos específicos. A ITIL se aplica melhor em organizações que estão à procura de estruturação da área de TI, já o COBIT é melhor aplicado quando há uma maior estruturação do setor de TI.
4. Benefícios da Governança de TI
De certa forma, todas as empresas possuem uma Governança de TI. Aquelas com uma governança eficaz concebem um conjunto de mecanismos de Governança de TI que estimulam comportamentos consistentes com a missão, estratégia, valores e cultura da organização. Nessas organizações, a TI se destaca por possibilitar maior competitividade e alinhamento das iniciativas de TI com a estratégia do negócio.
Pesquisas revelam que as organizações de melhor desempenho com a Governança de TI tem retornos sobre os investimentos em TI até 40% maiores que suas concorrentes. Isto ocorre porque estas empresas mensuram e gerenciam o que se gasta e o que se ganha com a TI, atribuem responsabilidades pelas mudanças organizacionais necessárias para tirar proveito dos novos recursos de TI e aprendem com cada implementação, tornando-se mais hábeis em compartilhar e reutilizar seus ativos de TI.
Uma boa Governança de TI deve assegurar que a organização possa identificar de forma mais objetiva os melhores investimentos, prever os custos e riscos em investimentos nos projetos de TI, reagir prontamente quando os riscos acontecerem e executar de forma mais eficiente o aumento do valor que pode ser entregue com os atuais recursos de TI. Deve também, propiciar a transparência das atividades da TI de forma a identificar oportunidades para readequar tanto os processos organizacionais como os processos de TI que geram valor ao negócio.
O Conselho e os Executivos receberão o benefício de ter uma estrutura com responsabilidades e decisões definidas para alcançar os objetivos do negócio. Além desta estrutura, com a Governança de TI será possível obter informações mais fáceis sobre o andamento dos processos e projetos, possibilitando a tomada de decisão correta pelos responsáveis.
5. Conclusão
Para que seja possível a implantação da Governança de Tecnologia da Informação em uma organização, é necessário que seja avaliado o nível de maturidade desta com relação aos domínios do COBIT. Após esta avaliação, devem ser identificados os processos mais críticos para que as melhorias sejam efetivadas.
Uma boa Governança de TI deve ser trabalhada aos poucos, implementando alguns componentes, de um ou mais práticas, e conforme a organização for amadurecendo sua Governança, outros componentes poderão ser acrescentados, de forma que a organização cresça junto com a Governança de Tecnologia da Informação.
Cada organização deve definir o caminho a seguir para iniciar os trabalhos para estabelecer a Governança de TI. Vários modelos e práticas podem ser utilizados em conjunto, tendo sempre como foco o alinhamento da TI com o negócio da empresa.
4. Referências
BARCELLOS, Monalessa Perine; RODRIGUES, Alex Sandro Barreto. Artigo “Governança de Tecnologia de Informação. Uma Visão Integrada à Engenharia de Software”, Páginas 55 a 60 da Revista Engenharia de Software Magazine. Edição 15. Rio de Janeiro.
CARTLIDGE, Alison. et al. An Introductory Overview of ITIL V3. 2007.
COBIT, 2007, Tradução COBIT, versão 4.1, 2007, http://www.isaca.org/
DOROW, Emerson. O que é Governança de TI e para que existe? Disponível em: http://www.profissionaisti.com.br/2010/08/o-que-e-governanca-de-ti-e-para-que-existe/. Acesso em: 21 de setembro de 2011.
FERNANDES, Aguinaldo Aragon; ABREU, Vladimir Ferraz. Implantando a Governança de TI. Da Estratégia à Gestão dos Processos e Serviços. 1. ed. Rio de Janeiro: Brasport, 2006.
[IBGC, 2012], Origem da Boa Governança. Disponível em: http://www.ibgc.org.br. Acesso em: 21 de setembro de 2011.
MACFARLANE, Ivor; RYDD, Colin. Guia sobre Gerenciamento de Serviços de TI. São Paulo, 2005.
MAGALHAES, Ivan Luizio; PINHEIRO, Walfrido Brito. Gerenciamento de Serviços de TI na Prática. 5ª ed. São Paulo: New Millenium Editora e Serviços Gráficos Ltda, 2005.
Levantamento de requisitos no desenvolvimento ágil de
software
Ricardo Augusto Ribeiro de Mendonça
Coordenação de Pós-Graduação Lato Sensu Pontifícia Universidade Católica de Goiás (PUC Goiás)
Goiânia – GO – Brasil
ricardoaugusto@gmail.com
Abstract. This paper presents a study of techniques for requirements gathering and demonstrates how to use them in agile software development methodologies. First, some techniques will be presented to raise requirements, then the key will be known agile methodologies and how the requirements are raised in each.
Resumo. Este artigo apresenta um estudo de técnicas de levantamento de requisitos e demonstra como utilizá-las em metodologias de desenvolvimento ágil de software. Primeiro, será apresentado algumas técnicas para levantar requisitos, em seguida, será conhecido as principais metodologias ágeis e a forma como os requisitos são levantados em cada uma delas.
1. Levantamento de requisitos
O levantamento de requisitos desempenha um papel importante na construção de um sistema de informação, pois é o início para toda a atividade de desenvolvimento de software. É onde o analista faz as primeiras reuniões com os clientes e/ou usuários para conhecer as funcionalidades do sistema que será desenvolvido.
Algumas das razões para o baixo grau de satisfação dos usuários estão na fase de levantamento de requisitos do projeto, onde não é utilizada uma técnica adequada para extrair os requisitos do sistema, além disso, a falha do analista em não descrever os requisitos de modo claro, sem ambiguidades, conciso e consistente com todos os aspectos significativos do sistema proposto [Pompilho 1995].
As técnicas de levantamento de requisitos possuem um conceito próprio e podem ser utilizadas em conjunto pelo analista. A seguir serão apresentadas de forma resumida algumas dessas técnicas.
1.1. Entrevistas
A entrevista é uma das técnicas tradicionais mais simples de utilizar e que produz bons resultados na fase inicial de obtenção de dados. Convém que o entrevistador dê margem ao entrevistado para expor as suas ideias. É necessário ter um plano de entrevista para que não haja dispersão do assunto principal e a entrevista fique longa, deixando o entrevistado cansado e não produzindo bons resultados.
• Entrevista fechada, onde o engenheiro de requisitos tem um conjunto
pré-definido de perguntas e está à procura de respostas.
• Entrevista aberta, sem perguntas pré-definidas do engenheiro de requisitos,
onde há uma discussão de forma aberta com os interessados sobre o que eles esperam do sistema.
Na verdade, muitas vezes não há limite claro entre os dois tipos de entrevistas. Você começa com algumas questões que são discutidas e isso leva a novas questões [Sommerville 1997]. A vantagem de entrevistas é que elas ajudam o desenvolvedor a obter uma rica coleção de informações. Sua desvantagem é que esta quantidade de dados qualitativos pode ser difícil de analisar e poderá haver informações conflitantes das diferentes partes interessadas.
1.2. Questionários
Os questionários são indicados, por exemplo, quando há diversos grupos de usuários que podem estar em diversos locais diferentes. Neste caso, elaboram-se pesquisas específicas de acompanhamento com usuários selecionados, pois não seria prático entrevistar todas as pessoas em todos os locais.
Existem vários tipos de questionários que podem ser utilizados. Entre estes podemos listar: múltipla escolha, lista de verificação e questões com espaços em branco. O questionário deve ser desenvolvido de forma a minimizar o tempo gasto em sua resposta.
Na fase de preparação do questionário deve ser indicado o tipo de informação que se deseja obter. Assim que os requisitos forem definidos o analista deve elaborar o questionário com questões de forma simples, clara e concisa, deixar espaço suficiente para as repostas que forem descritivas e agrupar as questões de tópicos específicos em um conjunto com um título especial. O questionário deve ser acompanhado por uma carta explicativa, redigida por um alto executivo, para enfatizar a importância dessa pesquisa para a organização.
Deve ser desenvolvido um controle que identifique todas as pessoas que receberão os questionários. A distribuição deve ocorrer junto com instruções detalhadas sobre como preenchê-lo e ser indicado claramente o prazo para devolução do questionário. Ao analisar as respostas dos participantes é feito uma consolidação das informações fornecidas no questionário, documentando as principais descobertas e enviando uma cópia com estas informações para o participante como forma de consideração pelo tempo dedicado a pesquisa.
1.3. Brainstorming
Brainstorming é uma técnica para geração de ideias. Ela consiste em uma ou várias reuniões que permitem que as pessoas sugiram e explorem ideias.
Brainstorming contém duas fases - a fase de geração, onde as ideias são coletadas, e a fase de avaliação, onde as ideias coletadas são discutidas. Na fase de geração, as ideias não devem ser criticadas nem avaliadas. Cada ideia pode levar a novas ideias. A técnica de brainstorming leva a uma melhor compreensão do problema para todos e um sentimento de que todos cooperaram para atingir o objetivo.
1.4. Joint Application Design (JAD)
A metodologia JAD foi desenvolvida pela IBM para acelerar o desenvolvimento de sistemas de informação e está embasada em dinâmicas de grupo acompanhadas de planejamento, estruturação e sistematização de reuniões.
O JAD facilita a criação de uma visão compartilhada do que o produto de software deve ser. Através da sua utilização os desenvolvedores ajudam os usuários a formular problemas e explorar soluções. Dessa forma, os usuários ganham um sentimento de envolvimento, posse e responsabilidade com o sucesso do produto.
A técnica JAD tem quatro princípios básicos:
• Dinâmica de grupo: são realizadas reuniões com um líder experiente, analista,
usuários e gerentes, para despertar a força e criatividade dos participantes. O resultado final será a determinação dos objetivos e requisitos do sistema;
• Uso de técnicas visuais: para aumentar a comunicação e o entendimento;
• Manutenção do processo organizado e racional: o JAD emprega a análise top
down e atividades bem definidas. Possibilita assim, a garantia de uma análise completa reduzindo as chances de falhas ou lacunas no projeto e cada nível de detalhe recebe a devida atenção;
• Utilização de documentação padrão: preenchida e assinada por todos os
participantes. Este documento garante a qualidade esperada do projeto e promove a confiança dos participantes.
A técnica JAD é composta de duas etapas principais: planejamento, que tem por objetivo elicitar e especificar os requisitos; e projeto, em que se lida com o projeto de software.
Cada etapa consiste em três fases: adaptação, sessão e finalização. A fase de adaptação consiste na preparação para a sessão, ou seja, organizar a equipe, adaptar o processo JAD ao produto a ser construído e preparar o material. Na fase de sessão é realizado um ou mais encontros estruturados, envolvendo desenvolvedores e usuários onde os requisitos são desenvolvidos e documentados. A fase de finalização tem por objetivo converter a informação da fase de sessão em sua forma final (um documento de especificação de requisitos).
Há seis tipos de participantes, embora nem todos participem de todas as fases:
• Líder da sessão: é responsável pelo sucesso do esforço, sendo o facilitador dos
encontros. Deve ser competente, com bom relacionamento pessoal e qualidades gerenciais de liderança;
• Engenheiro de requisitos: é o participante diretamente responsável pela
produção dos documentos de saída das sessões JAD. Deve ser um desenvolvedor experiente para entender as questões técnicas e detalhes que são discutidos durante as sessões e ter habilidade de organizar ideias e expressá-las com clareza;
• Executor: é o responsável pelo produto sendo construído. Tem que fornecer aos
