Desenvolvimento em Smartphones - Aplicativos Nativos e Web

Transcrição

1 Desenvolvimento em Smartphones - Aplicativos Nativos e Web Jan Miszura Toledo 1, Gilcimar Divino de Deus 2 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 13

2 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 Aplicativos de Software Nativos 14

3 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 ( da Apple, Java na plataforma Android ( do Google ou C# na plataforma Windows Phone ( 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 ( e do Google ( O Windows Phone, sistema operacional móvel da Microsoft ainda está no começo do seu desenvolvimento e por isso o mercado está todo voltado aos sistemas da Apple e do Google. 15

4 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 ( 16

5 Firefox 12.0 ( Opera ( Safari 5.1 ( e Internet Explorer 9.0 ( 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. 17

6 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. 18

7 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" moto8000.html (acessado em 17/04/2012) [3] "Worldmapper: The world as you've never seen it before" 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" (acessado em 17/04/2012) [5] "Global Mobile Phone & Smartphone Market ( )" / global_mobile_phone_and_smartphone_market_2010 (acessado em 15/03/2012) [6] "App Genome Report - February 2011" (acessado em 19/04/2012) [7] "Gartner Says Worldwide Smartphone Sales Soared in Fourth Quarter of 2011 With 47 Percent Growth" (acessado em 19/04/2012) [8] "The Market For Mobile Healthcare Applications Will Grow To $US 1.3 billion in 2012 research2guidance" (acessado em 19/04/2012) 19

8 [9] "RhoMobile mobilize your enterprise apps" (acessado em 01/05/2012) [10] "Titanium Developer Appcelerator Titanium Development Company" (acessado em 01/05/2012) [11] "PhoneGap" (acessado em 04/06/2012) 20

9 Desenvolvimento Orientado a Testes de Aceitação José Inácio Ferreira Filho, Olissea Artiaga da Silva 1 Pontifí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. 21

10 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: Acesso Negado 22

11 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. 23

12 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 24

13 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. 25

14 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 Senha deve ser válida Senha deve ser válida Senha deve ser válida Senha deve ser válida Senha deve ser p@wss w0rd 53nh*s!$&ab123 *1234cd senhas Senha deve ser inválida Senha deve ser inválida Senha deve ser inválida Senha deve ser inválida Senha deve ser inválida Senha deve ser inválida Senha deve ser inválida &*$@ _-/abcd 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 palavrachave 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. Os testes deverão ser reescritos no padrão do framework: 26

15 Caso de Teste Ação Argumento Argumento Verificar senhas válidas e Criar login Jose s3nh@s Inválidas Mensagem deve ser Tentativa de efetuar login Jose com os dados Mensagem deve ser CONTA CRIADA COM SUCESSO Bem-vindo s3nh@s Criar login Mensagem deve ser Tentativa de efetuar login Jose com os dados Mensagem deve ser CONTA CRIADA COM SUCESSO Bem-vindo Tabela 2. Reescrita dos Casos no 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 Tentativa de efetuar login Jose com os dados Mensagem deve ser CONTA CRIADA COM SUCESSO Bem-vindo ${senha} 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. 27

16 Tentativa de efetuar login Jose com os dados Mensagem deve ser Acesso negado Tabela 3. Criando palavras-chaves a partis de outras existentes ${senha} 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. 28

17 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. 29

18 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 Programming and Agile Methods - XP/Agile 30

19 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 (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. (Jan. 2012) 31

20 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 32

21 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; 33

22 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. 34

23 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 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 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-adia por gerentes de negócios, profissionais de TI e profissionais de avaliação. [COBIT, 2007] 35

24 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 Tabela 4. Domínio Monitorar e Avaliar 36

25 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. 37

26 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 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 atualizarse, 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 38

27 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 39

28 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 DS13 - Gerenciar as Operações 40

29 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. 41

30 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 V COBIT, 2007, Tradução COBIT, versão 4.1, 2007, DOROW, Emerson. O que é Governança de TI e para que existe? Disponível em: Acesso em: 21 de setembro de 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, [IBGC, 2012], Origem da Boa Governança. Disponível em: Acesso em: 21 de setembro de MACFARLANE, Ivor; RYDD, Colin. Guia sobre Gerenciamento de Serviços de TI. São Paulo, 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, WEILL, Peter; ROSS, Jeanne W. Governança de TI. São Paulo: Makron Books,

31 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 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 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. Existem dois tipos de entrevistas: 43

32 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 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 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. 44

33 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 participantes uma visão geral dos pontos estratégicos do produto de software a 45

34 ser construído e tomar as decisões executivas, tais como alocação de recursos, que podem afetar os requisitos e o projeto do novo produto; Representantes dos usuários: são as pessoas na empresa que irão utilizar o produto de software. Durante a extração de requisitos, os representantes são frequentemente gerentes ou pessoas chave dentro da empresa que tem uma visão melhor do todo e de como ele será usado; Representantes de produtos de software: são pessoas que estão bastante familiarizadas com as capacidades dos produtos de software. Seu papel é ajudar os usuários a entender o que é razoável ou possível que o novo produto faça; Especialista: é a pessoa que pode fornecer informações detalhadas sobre um tópico específico. Figura 1. Sessão JAD O conceito do JAD de abordagem e dinâmica de grupo poderá ser utilizado para diversas finalidades, como: planejamento de atividades técnicas para um grande projeto, discussão do escopo e objetivos de um projeto e estimativa da quantidade de horas necessárias para desenvolver sistemas grandes e complexos. A maioria das técnicas JAD funciona melhor em projetos pequenos ou médios. Para um sistema grande e complexo podem ser usadas múltiplas sessões JAD para acelerar a definição dos requisitos do sistema. 46

35 1.5. Prototipagem Um protótipo de um sistema é uma versão inicial do sistema que está disponível no início do processo de desenvolvimento. Protótipos de sistemas de software são frequentemente utilizados para ajudar a obter e validar requisitos do sistema. O protótipo é indicado para estudar as alternativas de interface do usuário; problemas de comunicação com outros produtos; e a viabilidade de atendimento dos requisitos de desempenho. As técnicas utilizadas na elaboração do protótipo são várias: interface de usuário, relatórios textuais, relatórios gráficos, entre outras. Alguns dos benefícios do protótipo são as reduções dos riscos na construção do sistema, pois o usuário chave já verificou o que o analista captou nos requisitos do produto. Para ter sucesso na elaboração dos protótipos é necessária a escolha do ambiente de prototipagem, o entendimento dos objetivos do protótipo por parte de todos os interessados no projeto, a focalização em áreas menos compreendidas e a rapidez na construção. 2. Desenvolvimento Ágil O Desenvolvimento Ágil é um conjunto de metodologias de desenvolvimento de software. É uma filosofia onde muitas metodologias se encaixam. As metodologias ágeis aplicam uma coleção de práticas guiadas por princípios e valores que podem ser aplicados por profissionais de software no decorrer do trabalho. Métodos ágeis são adaptativos ao invés de preditivos. Com os métodos tradicionais, o processo de software é planejado em detalhes por um longo período de tempo. Isso funciona bem se não houver grandes mudanças, o domínio da aplicação e as tecnologias de software sejam bem compreendidos pela equipe de desenvolvimento. Os métodos ágeis foram desenvolvidos para se adaptar as mudanças [Fowler 2000]. Métodos ágeis são orientados às pessoas ao invés de processos. Eles confiam na experiência das pessoas, na competência e na colaboração direta, do que em rigor dos processos centrados em documentos, para produzir software de alta qualidade [Fowler 2000]. A seguir, os métodos ágeis mais comuns serão brevemente discutidos Extreme Programming (XP) A metodologia Extreme Programming (XP) enfatiza o desenvolvimento rápido do projeto e visa garantir a satisfação do cliente, além de favorecer o cumprimento das estimativas. As regras, práticas e valores da XP proporcionam um agradável ambiente de desenvolvimento de software para os seus seguidores, que são conduzidos por quatro valores: comunicação, simplicidade, feedback e coragem. A finalidade do princípio de comunicação é manter o melhor relacionamento possível entre clientes e desenvolvedores, preferindo conversas pessoais a outros meios de comunicação. A comunicação entre os desenvolvedores e o gerente do projeto também é encorajada. A forma de comunicação é um fator chave na XP: procura-se o máximo possível comunicar-se pessoalmente, evitando se o uso de telefone e o envio de mensagens por correio eletrônico. 47

36 A simplicidade visa permitir a criação de código simples que não deve possuir funções desnecessárias. Por código simples entende-se implementar o software com o menor número possível de classes e métodos. Outra ideia importante da simplicidade é procurar implementar apenas requisitos atuais, evitando-se adicionar funcionalidades que podem ser importantes no futuro. A aposta da XP é que é melhor fazer algo simples hoje e pagar um pouco mais amanhã para fazer modificações necessárias do que implementar algo complicado hoje que talvez não venha a ser usado, sempre considerando que requisitos são mutáveis [Soares 2004]. Figura 2. Práticas XP Durante o planejamento, são usadas as técnicas de elicitação de requisitos, como entrevistas, brainstorming e priorização. A principal ferramenta utilizada para elicitação são os cartões de história em que os usuários escrevem suas histórias de usuário, que é uma descrição de um recurso que fornece o valor de negócio para o cliente [Carvalho Costa 2011]. Antes que as histórias possam ser escritas em cartões, os clientes têm que pensar sobre o que eles esperam do sistema e fazer com que a funcionalidade seja necessária. Este processo é uma espécie de brainstorming. Desenvolvedores pedem mais detalhes para determinar o que os clientes realmente querem que o sistema faça e estimam o esforço necessário para desenvolvê-la. Com base nestas estimativas e do tempo disponível na próxima iteração, os clientes estão, por sua vez, capazes para escolher as histórias a serem desenvolvidos. 48

37 2.1. Scrum O Scrum é um processo de desenvolvimento iterativo e incremental para gerenciamento de projetos e desenvolvimento ágil de software. Scrum não propõe qualquer técnica de desenvolvimento de software específico para a implementação. Ele se concentra em como uma equipe deve trabalhar em conjunto para produzir um trabalho de qualidade em um ambiente em mudança [Abrahamsson 2002]. As fases do Processo de Scrum são: pré-planejamento, desenvolvimento e pósplanejamento. Na fase de pré-planejamento (pre-game phase), os requisitos são descritos em um documento chamado backlog. A seguir os requisitos são classificados por prioridade, onde é estimado o esforço para o seu desenvolvimento. Nesta fase inclui a definição dos integrantes da equipe, identificação da necessidade de treinamento, as ferramentas que serão utilizadas, como também uma lista com os prováveis riscos de projeto. A fase é concluída com uma proposta de arquitetura de software. As alterações futuras devem ser descritas no backlog. Na fase de desenvolvimento (game phase), os riscos previamente identificados devem ser mapeados e acompanhados ao longo do projeto para avaliar o seu impacto. Nesta fase, o software é desenvolvido em ciclos interativos (sprints), onde são adicionadas novas funcionalidades. Cada um desses sprints com duração de 2 a 4 semanas são desenvolvidos de forma tradicional (análise, projeto, implementação e testes). Já na fase de pós-planejamento (post-game phase) é onde acontece a integração do software, os testes finais e a documentação do usuário. A equipe se reúne para analisar o estado do projeto e o software atual é apresentado ao cliente. As principais técnicas são o scrum product backlog, sprints e scrums. No que diz respeito à engenharia de requisitos, o product backlog desempenha um papel especial no scrum. Todos os requisitos considerados necessários ou úteis para o produto estão listados no product backlog. Ele contém uma lista ordenada de todas as funcionalidades, melhorias e bugs. O product backlog pode ser comparado com um documento de requisitos incompleto e em constante mudança, contendo os requisitos necessários para o desenvolvimento. Cada sprint, iteração com 30 dias de desenvolvimento, está prevista com base nas informações incluídas no product backlog. Tarefas selecionadas a partir do product backlog são movidas para o sprint backlog. Nenhuma alteração será feita para o sprint backlog durante o sprint. Ou seja, não há flexibilidade nos requisitos durante um sprint, mas há total flexibilidade para o cliente escolher os requisitos do próximo sprint. 49

38 Figura 3. Sprint Durante uma sprint a equipe de desenvolvimento passa por várias fases (reunião de planejamento da sprint, sprint, revisão da sprint). O objetivo da reunião de revisão da sprint é de que os participantes (clientes e desenvolvedores) tenham entendimento do sistema, sua arquitetura técnica e design, bem como as funcionalidades entregues. O conhecimento adquirido na reunião de revisão de sprint e o product backlog atual é a base para a próxima reunião de planejamento do sprint. Uma parte da reunião de revisão de sprint, onde os participantes adquirem conhecimentos sobre o sistema, pode ser comparado à revisão de requisitos e a uma apresentação do protótipo evolutivo para o cliente Feature Driven Development (FDD) O Desenvolvimento Orientado a Funcionalidades (FDD) é um processo de curta iteração para desenvolvimento de software com foco no projeto e na fase de desenvolvimento. FDD é composto por cinco processos sequenciais. Os três primeiros são executados no início do projeto e os dois últimos durante cada iteração [Fowler 2000]. Desenvolvimento de um modelo geral; Construção de uma lista de funcionalidades; Planejamento por funcionalidade; Projeto por funcionalidade; Desenvolvimento por funcionalidade. Os dois papéis mais importantes na FDD são o programador-chefe, um desenvolvedor experiente capaz de liderar equipes pequenas de desenvolvimento e de participar da análise de requisitos e da modelagem do projeto, e o proprietário da classe, 50

39 que trabalhará com a classe que é atribuída a ele. Na primeira fase, um modelo geral é desenvolvido por membros do domínio e pelos desenvolvedores. A lista de funcionalidades é construída na segunda fase com base no modelo global. O modelo global é composto de diagramas de classe com classes, links, métodos e atributos. As classes e links estabelecem a forma do modelo. Os métodos expressam o comportamento e é a base para a construção da lista de funcionalidades. Uma funcionalidade em FDD é uma função que agrega valor para o cliente. As funcionalidades da lista de funcionalidades são priorizadas pela própria equipe. A lista de funcionalidades é revisada pelos membros do domínio [Lefebvre 1999]. Figura 4. Processos da FDD Os requisitos em FDD são listados, definidos e documentados através de casos de uso, produzindo diagramas de classe e sequência. Em seguida, os requisitos são agrupados e priorizados conforme importância e dependência. FDD propõe um encontro semanal de 30 minutos para que a situação das funcionalidades seja discutida e um relatório sobre a reunião seja escrito [Lefebvre 1999]. Esses relatórios podem ser comparados com o monitoramento/gestão dos requisitos Adaptive Software Development (ASD) Os princípios do Desenvolvimento Adaptável de Software (ASD) são provenientes de pesquisas sobre o desenvolvimento iterativo. ASD fornece uma estrutura para o desenvolvimento de sistemas grandes e complexos com orientação suficiente para impedir os projetos de cair no caos. O método estimula o desenvolvimento iterativo e incremental com prototipagem constante. O processo ASD contém três fases que se sobrepõem: especulação, colaboração e aprendizagem. 51

40 Figura 5. Processo ASD Os nomes das fases enfatizam a diferença do desenvolvimento de software tradicional. Especulação em vez de planejamento, porque o planejamento sempre indica que não há incertezas. A importância do trabalho em equipe é destacada pela colaboração. Em um ambiente imprevisível, pessoas têm a necessidade de se comunicar para serem capazes de lidar com as incertezas [Highsmith 1996]. Aprendizagem salienta que os requisitos mudam durante o desenvolvimento e existe a necessidade de um conhecimento sobre isso. Na ASD os desvios não são uma falha do sistema, mas levarão para uma solução correta. Cada projeto começa com a definição da missão do projeto, uma breve declaração indicando o curso do projeto. Durante a fase de iniciação do projeto, o cronograma geral bem como os prazos e os objetivos para os ciclos de desenvolvimento são definidos. Um ciclo em ASD dura entre quatro e oito semanas. Como ASD é orientada a componentes em vez de orientado a tarefas, ela foca nos resultados e sua qualidade. A próxima fase é o planejamento do ciclo adaptativo que contém a fase de colaboração onde o ASD aborda a visão orientada a componentes. Ciclos do planejamento são repetidos quando ocorrem novas exigências e os componentes têm de ser refinados. Revisões com a presença do cliente demonstram a funcionalidade do software durante o ciclo. A fase de release é a última fase de um projeto ASD. Não há recomendações de como esta fase deve ser realizada, mas a ênfase está na importância de capturar as lições aprendidas. Os requisitos em ASD são definidos através de sessões de JAD com a presença de representantes do cliente. Como em outros processos ágeis, ASD é baseada em ciclos de desenvolvimento iterativo. ASD destaca que um método cascata só funciona em um ambiente bem compreendido e bem definido. Mas as mudanças são frequentes no desenvolvimento de software e é importante ser capaz de reagir às mudanças e utilizar um método de tolerância às mudanças. 52

41 3. Conclusão As metodologias de desenvolvimento ágil podem ser consideradas novas, porém vêm acompanhando as necessidades de desenvolver softwares com qualidade, no menor tempo possível e que atendam as necessidades dos clientes. Profissionais da tecnologia da informação vêm aprimorando as concepções destas metodologias para atender as necessidades do mercado e principalmente das pessoas. Os métodos ágeis são baseados em um forte envolvimento do cliente durante todo o processo de desenvolvimento. Porém, os métodos pedem vários clientes com diferentes experiências, mas às vezes apenas um cliente está disponível. Isso significa que nem todas as questões levantadas podem ser respondidas com detalhes suficientes. Isso pode resultar em atrasos no desenvolvimento ou em tomada de decisões potencialmente incorretas. Além disso, algumas áreas de negócio não podem ser suficientemente compreendidas pelo cliente, de modo que ele não pode dizer a equipe de desenvolvimento sobre os requisitos relacionados. Mesmo que os requisitos sejam levantados em sessões de grupo não é garantido que os usuários ou clientes com a base necessária estejam presentes. Contudo, o desenvolvimento ágil de software leva a uma melhor compreensão dos requisitos e do processo de desenvolvimento, pois envolve os clientes, que são capazes de tomar as decisões corretas e ter sua própria visão a respeito do sistema a ser desenvolvido. Uma empresa ao utilizar estes métodos, estará agregando valor aos seus negócios e melhorando o ambiente de seus colaboradores e clientes, tratando-os como pessoas e parceiros. Está é chave no mundo dos negócios, o bem estar de seus colaboradores e a parceria entre o fornecedor e seus clientes, criando um laço de confiança. 53

42 Referências ABRAHAMSSON, Pekka, SALO, Outi, RONKAINEN, Jussi e WARSTA, Juhani. Agile software developlment methods. Review and analysis. Espoo VTT Publications p. CARVALHO COSTA, Gustavo Henrique de. Engenharia de Requisitos no Desenvolvimento de Software Ágil. Universidade Federal de Pernambuco, Centro de Informática, FOWLER, Martin. The new methodology. articles/newmethodology.html, HIGHSMITH, James A. Adaptive Software Development. Dorset House Publishing, LEFEBVRE, Eric, COAD, Peter e DE LUCA, Jeff. Java Modeling in Color with UML. Prentice Hall PTR, POMPILHO, S. Análise Essencial Guia Prático de Análise de Sistemas. Rio de Janeiro: Ed. Ciência Moderna Ltda, PRESSMAN, Roger S. Engenharia de Software. São Paulo: Ed. Markon Books, SOMMERVILLE, Ian e KONTONYA, Gerald. Requirements Engineering. John Wiley & Sons, SOARES, Michel dos Santos. Comparação entre Metodologias Ágeis e Tradicionais para o Desenvolvimento de Software. Unipac - Universidade Presidente Antônio Carlos, Faculdade de Tecnologia e Ciências de Conselheiro Lafaiet,

43 PROPOSTA DE AVALIAÇÃO DA QUALIDADE DE REQUISITOS IDENTIFICADOS POR MEIO DA ABORDAGEM ÁGIL SCRUM Renata Dutra Braga 1 Olisséa Artiaga da Silva 1 1 Pós-Graduação Lato Sensu em Qualidade e Gestão de Software Pontifícia Universidade Católica de Goiás (PUC-GO) Goiânia Brasil Agosto de {renatadbraga, olissea}@gmail.com Olisséa Artiaga da Silva Especialista Abstract. Objective: To investigate methods adopted to achieve the quality requirements and develop a checklist that can be used in the iterations of the project using Scrum as a way to verify the quality of recorded requirements. Methods: We conducted a literature research, then the elaboration of the checklist, and finally, validation of the same between the academic community and companies in the sector of Information Technology. Results: The content of the checklist has been prepared in accordance with IEEE Standard The semantic validation of the same, as well as its use in a sprint a real design was performed. Conclusion: The use of the checklist revealed the importance to identify and verify the quality of each requirement defined in the Sprint. Resumo. Objetivo: Investigar métodos adotados para alcançar a qualidade de requisitos e desenvolver um checklist que poderá ser utilizado nas iterações do projeto que utiliza o Scrum como forma de verificar a qualidade dos requisitos registrados. Métodos: Foi realizado um estudo bibliográfico, em seguida, a elaboração do checklist e, por fim, a validação do mesmo entre a comunidade acadêmica e empresas do setor de Tecnologia da Informação. Resultados: O conteúdo do checklist foi elaborado em conformidade com a Norma IEEE A validação semântica do mesmo, assim como a sua utilização em uma Sprint de um projeto real foram realizadas. Conclusão: A utilização do checklist revelou a importância para identificar e verificar as características de qualidade de cada requisito definido na Sprint. Palavras-Chave: Qualidade de Requisitos, Metodologia Ágil, Scrum. 55

44 1. Introdução O mercado, progressivamente, vem exigindo maior qualidade nos produtos desenvolvidos por empresas em diferentes setores de atividades. No que se refere à indústria de software não poderia ser diferente. A qualidade de software destaca-se como um diferencial de mercado visto que sua importância está no fato de produzir sistemas cada vez melhores e, assim, assegurar a satisfação do cliente [MPS.BR 2009a]. O termo qualidade, dependendo do ponto de vista e contexto, possui diferentes significados em relação à construção de software. Por exemplo, a qualidade do processo de desenvolvimento [RUP (2012)a e MPS.BR (2009)b], a qualidade do produto, que por sua vez, é definida em qualidade interna, qualidade externa e qualidade em uso [ABNT 2003]. Diversas metodologias de gerência e desenvolvimento de software visando alcançar a qualidade do produto desenvolvido são encontradas na literatura. Tem-se as abordagens tradicionais, tais como: modelo cascata, evolucionário, espiral [Sommerville 2011] e Guia do Conhecimento em Gerenciamento de Projetos [PMI 2008], dentre outras; assim como, as abordagens ágeis, tais como: Extreme Programming [Beck 1999], Scrum [Schwaber 2004], Feature Driven Development [Highsmith 2002], Adaptive Software Development [Highsmith 2002] e Crystal [Cockburn 2004]. Dentre as abordagens citadas, em especial às ágeis, um destaque diferenciado deve ser dado ao Scrum que, além de ser um framework de desenvolvimento e gerência de projetos de software [Guia do Scrum 2009], ele também pode ser utilizado na implantação de processo de melhoria de software [Salgado 2010] e gerência de portfólios de projetos [Schwaber 2004]. Além disto, o Scrum destaca-se dos demais métodos ágeis pela maior ênfase dada ao gerenciamento do projeto e reúne atividades de monitoramento e feedback, em geral, reuniões rápidas e diárias com toda a equipe, visando a identificação e correção de quaisquer deficiências e/ou impedimentos no processo de desenvolvimento [Marçal 2009]. Considerando que ao utilizar a abordagem Scrum, as necessidades dos usuários quanto ao desenvolvimento do software são evoluídas e entendidas a cada iteração no decorrer da execução do projeto, torna-se fácil entender a descrição que a International Standardization Organization (ISO) menciona na norma obter um produto que satisfaça as necessidades do usuário normalmente requer uma abordagem iterativa para o 56

45 desenvolvimento de software com feedback contínuo sob a perspectiva do usuário. [ABNT 2003]. Dessa forma, manter a qualidade dos requisitos ou users histories identificados, torna-se mais complexo com o uso desta abordagem sob o ponto de vista do cliente (Product Owner). Portanto, como verificar que os requisitos, ao final de uma Sprint 1, possui qualidade? Esse trabalho propõe investigar métodos adotados para alcançar a qualidade de requisitos e desenvolver um checklist que poderá ser utilizado em cada iteração do projeto que utiliza a metodologia Scrum como forma de verificar a qualidade do conjunto de requisitos registrados para um determinado domínio de problema. É importante ressaltar que o foco do presente trabalho está na verificação da qualidade dos requisitos do produto e não na verificação da qualidade dos requisitos do processo. Adicionalmente, o mesmo está organizado nas seguintes seções: a seção 2 apresenta uma descrição sobre a qualidade de requisitos, enquanto que as características da metodologia ágil Scrum são estabelecidas na seção 3; na seção 4, os procedimentos metodológicos são detalhados; na sessão 5 os resultados encontrados são caracterizados, assim como uma discussão sobre o assunto é apresentada. Por fim, na sessão 6, as considerações finais são apresentadas. 2. Qualidade de Requisitos A qualidade de software é definida pelo Instituto de Engenheiros Eletricistas e Eletrônicos, ou em inglês Institute of Electrical and Electronics Engineers - IEEE, como "o grau com que um sistema, componente ou processo atende aos requisitos especificados e às expectativas ou necessidades de clientes ou usuários [SWEBOK 2004]. Visando atingir a qualidade de software, diversos modelos de processos foram desenvolvidos, tais como Capability Maturity Model Integration (CMMI), Modelo de Processo de Software Brasileiro (MPS.BR) e ISO 9001 [SAYÃO 2003]. Na maioria desses modelos, uma das áreas que possui maior preocupação e, por isso, é uma das primeiras a ser implementada é a área de Gerência de Requisitos [MPS.BR (2009)c], [CMMI 2006]. 1 Sprint é uma iteração de um mês ou menos, de duração consistente com o esforço de desenvolvimento [Agile Manifesto 2011]. 57

46 Dessa forma, é possível perceber que especificar requisitos com qualidade é essencial para alcançar a qualidade do software desejada, tanto na perspectiva do cliente quanto técnica. O termo requisito é definido como uma condição ou capacidade necessária para um usuário resolver um problema ou atingir um objetivo [IEEE 1998] ou ainda, é uma condição ou uma capacidade com a qual o sistema deve estar de acordo [RUP (2012)b]. Para tanto, visando garantir a qualidade dos requisitos definidos, o IEEE definiu a Norma que estabelece as características para um requisito (ou, o documento de requisito) ter uma boa qualidade, tais como, ser correto, não ambíguo, completo, consistente, classificado por importância, verificável, modificável e rastreável [IEEE 1998]. A definição de cada característica é apresentada na tabela a seguir. Tabela 1 - Características de uma boa especificação de requisitos. Fonte: Norma IEEE Características Definição Correto É correto se, e somente se, cada requisito expresso for encontrado também no software. Não ambíguo É não ambíguo se, e somente se, cada requisito declarado seja suscetível a apenas uma interpretação. Completo É completo se, e somente se, conter toda e apenas a informação necessária para que o software correspondente seja produzido. Consistente É consistente se, e somente se, nenhum dos requisitos do documento, tomado individualmente, está em conflito com qualquer outro requisito do mesmo documento. Classificado por importância Se existe indicações no documento quanto à importância ou / estabilidade estabilidade do requisito. Verificável É verificável se, e somente se, para cada um dos requisitos contidos no documento, existe um processo finito e economicamente viável através do qual uma pessoa ou máquina possa assegurar que o produto de software atende ao requisito. Modificável É modificável se, e somente se, modificações possam ser agregadas ao documento de forma fácil, completa e consistente, com relação a sua estrutura e estilo. Rastreável É rastreável se, e somente se, a origem de cada um de seus requisitos é clara e a referência a cada um deles é facilitada nos documentos 58

47 subsequentes do processo ou em uma melhoria da documentação do sistema. Assim como a Norma IEEE , existem outras abordagens que visam especificar requisitos com boa qualidade. Dentre elas, é possível mencionar a ISO e ISO 9001, bem como os modelos de processos de software que definem um padrão para a garantia da qualidade de software, como o CMMI e o MPS.BR. Portanto, verificar a qualidade de requisitos, independentemente do tipo de metodologia de desenvolvimento adotada, quer seja tradicional ou ágil, torna-se relevante, pois sabe-se que a qualidade é caracterizada como um fator crítico de sucesso para a indústria de software [MPS.BR 2009b]. 3. Métodos Ágeis: Características do Scrum Em 2001, dezessete especialistas reuniram-se e compartilharam princípios comuns entre todos os métodos ágeis existentes, criando assim o Manifesto Ágil e a Aliança Ágil [Soares 2004]. No total, doze princípios foram definidos, entre eles a satisfação do cliente, adequação a mudanças, indivíduos motivados e entrega rápida de software funcionando estão contemplados. A tabela a seguir, apresenta tais princípios. Tabela 2 - Princípios por trás do manifesto ágil. Fonte [Agile Manifesto 2011]. 1. Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor. 2. Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam a mudanças, para que o cliente possa tirar vantagens competitivas. 3. Entregar software funcionando com frequência, na escala de semanas até meses, com preferência aos períodos mais curtos. 4. Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diariamente, durante todo o curso do projeto. 5. Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho. 6. Método mais eficiente e eficaz de transmitir informações para, e por dentro de um Time de desenvolvimento, é através de uma conversa cara a cara. 7. Software funcional é a medida primária de progresso. 59

48 8. Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes. 9. Contínua atenção à excelência técnica e bom design, aumenta a agilidade. 10. Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito. 11. As melhores arquiteturas, requisitos e designs emergem de Times auto-organizáveis. 12. Em intervalos regulares, o Time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo. Tal manifesto propõe que novas maneiras para desenvolver software estão sendo descobertas, onde através deste trabalho, passam a valorizar [Agile Manifesto 2001]: Indivíduos e interação entre eles mais que processos e ferramentas Software em funcionamento mais que documentação abrangente Colaboração com o cliente mais que negociação de contratos Responder a mudanças mais que seguir um plano O framework Scrum é uma abordagem empírica baseada na flexibilidade, adaptabilidade e produtividade em que a escolha das técnicas de desenvolvimento fica a cargo do time [Marçal 2009]. Três pilares asseguram a implementação dessa abordagem empírica [Guia do Scrum 2009]: Transparência: garante que aspectos do processo que afetam o resultado devem ser visíveis para aqueles que gerenciam os resultados. Esses aspectos não apenas devem ser transparentes, mas também o que está sendo visto deve ser conhecido. Inspeção: Os diversos aspectos do processo devem ser inspecionados com uma frequência suficiente para que variações inaceitáveis no processo possam ser detectadas. Adaptação: Se o inspetor determinar, a partir da inspeção, que um ou mais aspectos do processo estão fora dos limites aceitáveis e que o produto resultante será inaceitável, ele deverá ajustar o processo ou o material sendo processado. Esse ajuste deve ser feito o mais rápido possível para minimizar desvios posteriores. A Figura 1 ilustra o processo de desenvolvimento do Scrum. 60

49 Figura 1 - Processo de Desenvolvimento do Scrum. Fonte: De acordo com a figura anterior é possível perceber que o framework Scrum sugere que as equipes sejam pequenas, entre cinco e, no máximo, sete pessoas. Quando há menos do que cinco membros em um Time, há menor interação e, como resultado, há menor ganho de produtividade [Guia do Scrum 2009]. O framework, também, sugere que os ciclos de cada Sprint sejam curtos de no máximo trinta dias. A fase de preparação, presente na Figura 1, tem por objetivo identificar os requisitos e priorizá-los (pelo menos para a próxima Sprint). Divide o Product Backlog em Sprints, de acordo com a priorização realizada, levando em consideração a produtividade do Time [Marçal 2009]. É nesta fase que o resultado do presente trabalho se propõe a avaliar e verificar a qualidade de tais requisitos identificados Papéis do Scrum A metodologia ágil Scrum estabelece um framework iterativo e incremental, onde as atividades executadas por cada Time são exercidas por três principais papéis [Schwaber 2004] [Guia do Scrum 2009]: Scrum Master: é responsável por garantir que o processo seja compreendido e seguido, em outras palavras, que o Time é adepto aos valores, às práticas e às regras do Scrum; e também é responsável por remover os impedimentos do projeto. 61

50 Product Owner: é responsável por maximizar o valor do trabalho que o Time de Scrum faz; define os fundamentos do projeto definindo requisitos iniciais e gerais (Product Backlog), retorno do investimento, objetivos e planos de entregas; prioriza o Product Backlog a cada Sprint, garantindo que as funcionalidades de maior valor sejam construídas prioritariamente. Somente o Product Owner muda a prioridade de um item. Time: é responsável por executar o trabalho propriamente dito. O Time consiste em desenvolvedores com todas as habilidades necessárias para transformar os requisitos do Product Owner em um pedaço potencialmente entregável do produto ao final da Sprint. Ele é auto-organizável Artefatos Ao longo do desenvolvimento do produto, poucos artefatos são gerados ao utilizar o Scrum, dentre eles quatro principais se destacam [Guia do Scrum 2009]: Product Backlog: é uma lista priorizada de tudo que pode ser necessário no produto. Sprint Backlog: é uma lista de tarefas para transformar o Product Backlog, por uma Sprint, em um incremento do produto potencialmente entregável. Um burndown é uma medida do backlog restante pelo tempo. Burndown de Release: mede o Product Backlog restante ao longo do tempo de um plano de release. Burndown de Sprint: mede os itens do Sprint Backlog restantes ao longo do tempo de uma Sprint. 4. Métodos Esta é uma pesquisa aplicada que utilizará estudo bibliográfico, de campo e a elaboração de um checklist que objetiva verificar a qualidade dos requisitos registrados por meio da abordagem ágil Scrum. Para o estudo bibliográfico será realizada a busca em diferentes bases de dados científicas (IEEE Xplore, ACM, Periódicos da CAPES, Google Scholar), assim como em revistas e livros. 62

51 Para a elaboração do checklist, após a análise da literatura por meio do estudo bibliográfico, a ferramenta BrOffice.org Calc será utilizada. Tal checklist será validado entre a comunidade acadêmica e empresas do setor de Tecnologia da Informação, utilizando a tecnologia Google Docs. 5. Resultados e Discussão Como resultado da análise da literatura e pesquisas para verificar a qualidade de requisitos, foi proposto um checklist, estruturado em um conjunto de perguntas em conformidade com as características de qualidade estabelecidas pela Norma IEEE [IEEE 1998]. A tabela a seguir ilustra o checklist elaborado que contém, para cada característica presente na Norma IEEE , os itens a verificar nos requisitos registrados em cada Sprint do projeto. Tabela 3 - Checklist proposto. Fonte: O autor. ID Itens a Verificar Escala C - CORRETO C.1 O requisito registrado foi implementado na Sprint? C.2 O requisito (seja funcional ou não funcional) foi registrado de forma clara e objetiva? C.3 O cliente reflete, quando aplicável, se o requisito registrado atende às suas reais necessidades? NA - NÃO AMBÍGUO NA.1 O requisito registrado na Sprint é suscetível a apenas uma interpretação? NA.2 De acordo com o requisito registrado, é possível validar seu conteúdo com o cliente? NA.3 De acordo com o requisito registrado, é possível verificar se o software correto foi produzido? CO - COMPLETO CO.1 Uma lista de requisitos que inclui os mais significantes para a Sprint é definida CO.2 O requisito registrado aborda a definição das respostas do (0- NA/Não Atende; 5- Atende Parcialmente; 10- Atende Completamente) 63

52 software a todos os tipos de dados de entrada em todas as situações possíveis, válidas ou inválidas? CO.3 Os requisitos alocados na Sprint contêm toda e apenas a informação necessária para que o software correspondente seja produzido? CT - CONSISTENTE CT.1 O requisito registrado na Sprint está em conflito com qualquer outro requisito definido na mesma Sprint ou em outra? CI - CLASSIFICADO POR IMPORTÂNCIA CI.1 Uma escala de prioridade/estabilidade para os requisitos foi definida juntamente com o cliente? CI.2 Existe indicação quanto à importância ou à estabilidade do requisito definido na Sprint? CI.3 A prioridade/estabilidade do requisito foi classificada juntamente com o cliente? V - VERIFICÁVEL V.1 É possível determinar se o requisito registrado é satisfeito pela implementação no final da Sprint? V.2 O requisito definido é passível de teste? V.3 Para cada um dos requisitos definido na Sprint, o(s) respectivo(s) caso(s) de teste(s) foi elaborado e executado? V.4 Ao final da Sprint, o cliente assegura que o produto entregue, atende ao requisito registrado? M - MODIFICÁVEL M.1 Um mecanismo que facilita a modificação de requisitos na Sprint é utilizado? M.2 Antes de realizar a modificação de requisito, os impactos são analisados? M.3 Modificações podem ser agregadas no requisito definido na Sprint de forma fácil, completa e consistente? R - RASTREÁVEL R.1 O requisito possui um identificador único? R.2 A origem do requisito registrado é clara? R.3 Existe um mecanismo que permite realizar a rastreabilidade do requisito definido na Sprint? R.4 A rastreabilidade deste requisito com os demais registrados na Sprint foi definida? 64

53 R.5 Existe rastreabilidade com todos os requisitos definidos na presente Sprint com as demais Sprint? Este checklist destina-se aos interessados que empregam a metodologia ágil Scrum. Seu objetivo é avaliar a qualidade dos requisitos registrados em cada Sprint do projeto. O formulário desenvolvido para realizar a validação do mesmo encontra-se em TA1eGc6MQ8. A validação semântica do checklist elaborado foi realizada na Fábrica de Software de uma instituição de ensino superior privada e outra pública, ambas localizadas em Anápolis-GO. A mesma validação, também, foi realizada pela comunidade acadêmica e por alguns colaboradores de empresas do setor de Tecnologia da Informação (TI) localizados em Goiânia-GO. Foram sugeridas algumas melhorias no checklist, as quais estão descritas abaixo: Acrescentar itens a verificar no checklist relacionados aos tópicos abaixo: o Analisar se o requisito registrado está dentro do escopo da Sprint; o Analisar se o requisito registrado já foi alocado em outra Sprint ou se o mesmo é duplicado / conflitante com outro; o Analisar se a causa raiz do requisito foi identificada na Sprint. Propor um processo para tratar dos requisitos levando em consideração a rastreabilidade e prevenção de mudanças. O checklist foi utilizado em uma Sprint, com duração de uma semana, em um projeto real em desenvolvimento na Fábrica de Software de uma instituição de ensino superior privada, localizada em Anápolis-GO. Na Sprint, sete requisitos foram registrados. Para cada um deles, uma verificação foi realizada tomando como base os itens a verificar presente no checklist. Dos vinte e cinco itens a verificar, somente um de cada característica foi escolhido e os respectivos resultados estão ilustrados nos gráficos a seguir. O número do ID (identificador) é o mesmo definido na Tabela 3. 65

54 Tabela 4 - Interpretação dos resultados ID Gráfico Interpretação C.1 De acordo com a verificação, 57% dos requisitos foram implementados parcialmente na Sprint, enquanto que 43% foram completamente implementados. Percebe-se que o time não teve um desempenho 100% esperado. Novas adaptações devem ser analisadas para melhorar o desempenho da equipe. NA.1 71% dos requisitos registrados na Sprint são suscetíveis a apenas uma interpretação. Somente 14% deles atende parcialmente esse item e os demais 14% são ambíguos. CO.3 Nessa verificação foi detectado que 43% dos requisitos alocados na Sprint, contêm toda e somente a informação necessária para produzir o software, enquanto que 29% dos requisitos atende parcialmente essa verificação. CT.1 43% dos requisitos registrados na Sprint não está em conflito com qualquer outro requisito definido tanto na mesma quanto em outra Sprint. Porém, uma taxa de 29% possui algum tipo de conflito e os outros 29% não atende essa verificação. 66

55 CI.3 Essa verificação demonstrou que a prioridade de 71% dos requisitos é classificada juntamente com o cliente (ou o Product Owner). 14% dos requisitos não se define a prioridade juntamente com o cliente, enquanto que 14% não define nenhum tipo de prioridade. V.1 A avaliação desse item permite constatar que 57% dos requisitos é satisfeito pela implementação ao término da Sprint de forma parcial. Um valor de 43% atende completamente essa satisfação. Um fator positivo é que 0% não é satisfeito ou não atende. M.1 O resultado desse item demonstra que um mecanismo que objetiva facilitar a modificação de requisitos registrados na Sprint é utilizado em 43% deles. 29% não adota esse mecanismo e os demais 29% utiliza apenas parcialmente esse mecanismo. R.1 71% dos requisitos registrados na Sprint possuem um identificador único, enquanto que 29% não utilizam nenhum tipo de identificador. 67