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 [email protected]2 Departamento de Computação - Pontifícia Universidade Católica de Goiás - GO - Brasil [email protected]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
Transcript
Desenvolvimento em Smartphones - Aplicativos Nativos e Web
Jan Miszura Toledo1, Gilcimar Divino de Deus2
1 Departamento de Computação - Pontifícia Universidade Católica de Goiás - GO - Brasil
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
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. 3.1. Aplicativos de Software Nativos
14
Aplicação nativa/embarcada é um software desenvolvido para executar em uma plataforma específica. Os arquivos resultantes da compilação do aplicativo devem ser instalados diretamente no sistema operacional, tais como apresentação, processamento e armazenamento de dados.
É possível a manipulação de dados off-line, ou seja, armazenados em um banco de dados no próprio aparelho, o que permite ao software nativo continuar funcionando mesmo em localidades onde não há acesso a internet. O hardware presente no dispositivo pode ser melhor utilizado, como o telefone, câmera, microfone, bluetooth e acelerômetro, pode tornar-se mais útil, fácil e interativo com esses tipos de aplicativos. Outro ponto positivo é a melhor experiência com o usuário, ao se desenvolver nativamente pode-se explorar recursos mais avançados aos usuários, como a tela sensível ao multi-toque e efeitos visuais dos componentes da aplicação. Em geral os jogos para smartphones são desenvolvidos com esta finalidade.
Na maioria das vezes o poder de processamento dos aparelhos móveis são bem utilizados em aplicações específicas para a plataforma, permitindo assim a um rápido tempo de resposta levando a mais agilidade no uso destes aplicativos. Também é possível o acesso aos dados presentes no aparelho, como por exemplo: a agenda telefônica, câmera e outros aplicativos, possibilitando a integração entre as aplicações existentes no aparelho.
Desenvolver software específico requer linguagem de programação específica como Objective-C na plataforma iOS (http://www.apple.com/ios) da Apple, Java na plataforma Android (http://www.android.com) do Google ou C# na plataforma Windows Phone (http://www.microsoft.com/windowsphone) da Microsoft, o que pode tornar o investimento mais alto no início do projeto por exigir treinamento para as plataformas selecionadas e a consequente duplicação da mesma aplicação em ambas plataformas. Outro exemplo de dificuldade em se desenvolver este tipo de aplicativo está relacionada com a distribuição entre os usuários e as atualizações de versões. Torna-se necessário uma interação do usuário para manualmente receber o mesmo aplicativo com novos recursos ou permitir que isto seja feito de maneira automática.
Nas lojas de aplicativos on-line dos sistemas operacionais iOS e Android há milhares de aplicativos que atendem a objetivos variados, desde jogos até aplicativos de escritório. O gráfico abaixo apresenta o crescimento estimado em um período de 6 meses de aplicativos nas lojas virtuais da Apple (http://store.apple.com) e do Google (https://play.google.com). O Windows Phone, sistema operacional móvel da Microsoft ainda está no começo do seu desenvolvimento e por isso o mercado está todo voltado aos sistemas da Apple e do Google.
15
Figura 1 - Quantidade de aplicativos em Android e iOS [6] 3.2. Aplicativos de Software Web Acessado geralmente por meio da rede mundial de computadores (internet) e desenvolvido com linguagens suportadas por navegadores, tais como, HTML, CSS, JavaScript, Flash, este tipo de software é denominado aplicativo web.
No processo de produção desses aplicativos web, voltados para smartphones, deve-se levar em consideração sua alta popularidade, que permite uma proliferação maior de usuários em comparação com os aplicativos nativos. Isto é devido aos smartphones modernos possuírem navegadores de internet, não sendo necessário nenhuma instalação adicional de aplicativo, o que facilita também a atualizações dos aplicativos web de maneira automática.
Para permitir a execução satisfatória dos aplicativos web nos diversos smartphones presentes no mercado faz-se necessário que o aparelho sempre esteja conectado à internet, de preferência deve-se ter uma velocidade de conexão satisfatória para permitir a rápida troca de dados com os servidores de páginas para não prejudicar a experiência do usuário.
Apesar dos aplicativos web executarem em navegadores de internet, há pontos que exigem a atenção dos desenvolvedores, como por exemplo o tamanho da tela dos dispositivos móveis exigindo testes e adequações para o bom funcionamento nos diversos smartphones do mercado. Outro ponto se refere as diferentes versões de navegadores, seja de diferentes fabricantes ou mesmo por versões distintas do mesmo navegador, as aplicações web podem apresentar aspectos indesejáveis devido ao difícil controle quanto as diferenças dos navegadores.
Atualmente uma nova versão da linguagem HTML (Hyper Text Markup Language), chamada HTML5, está começando a ser utilizada e seus novos recursos estão sendo implementados nos principais navegadores do mercado, tais como, Chrome 19.0 (https://
16
www.google.com/chrome), Firefox 12.0 (http://www.mozilla.org/pt-BR/firefox/fx/), Opera 11.64 (http://www.opera.com/), Safari 5.1 (http://www.apple.com/safari/) e Internet Explorer 9.0 (http://windows.microsoft.com/ie9). Uma interessante característica presente na nova versão da HTML é a capacidade armazenar em cache parte ou toda uma aplicação web. Com este recurso será possível continuar acessando uma aplicação web mesmo quando não há disponibilidade de conexão com a internet e permitirá um ganho no desempenho das aplicações web pois haverá necessidade de efetuar o download somente das páginas que tiveram seus conteúdos modificados. 4. Demandas do Mercado Conexões móveis em todo o mundo experimentará um crescimento constante até 2015, quando deverão chegar a 7,4 bilhões. [4], resultando em um grande interesse nesta área por parte de empresas em diversos setores, levando-as a buscarem sua participação neste mercado. Como alguns exemplos podemos citar: a) varejistas exporem suas lojas nos dispositivos móveis; b) empresas com vendas externas se beneficiarem dos recursos dos smartphones e integrarem seus software corporativo aos aplicativos; c) instituições bancárias oferecem aplicativos que acessem os dados de contas bancárias de clientes pelo smartphone; d) empresas investirem em jogos nos aparelhos móveis e podem ser bem aceitos mundialmente; e) empresas de comunicação disponibilizarem conteúdos em plataformas móveis etc
De acordo com o Gartner [7], as vendas de smartphones a consumidores finais dispararam no quarto trimestre de 2011 alcançando 47,3% de crescimento em comparação com o mesmo período de 2010, o que resulta em novas oportunidades aos profissionais e empresas do ramo da tecnologia da informação, seja com a necessidade de aplicativos nativos ou web, as empresas querem operar seus negócios também nos dispositivos móveis permitindo uma maior abrangência de clientes e consequente aumento de lucros. Aplicativos para saúde, são um exemplo de mercado em expansão nos Estados Unidos, é previsto que seu crescimento seja de quase 100% em 2012, alcançando US$ 1,3 bilhões, comparados com US$ 718 milhões em 2011 [8]. 5. Resultados Obtidos Ao se apresentar as características e diferenças, notamos um maior custo inicial no desenvolvimento nativo em comparação ao web, visto que são necessários conhecimentos específicos para os diversos sistemas operacionais dos smartphones, para se desenvolver nativamente, mas nas aplicações web basta se desenvolver com as já conhecidas linguagens HTML, CSS e Javascript.
17
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
Algumas frameworks propoem a criação de aplicativos em uma linguagem única e permitem a tradução em código nativo para a maioria dos sistemas operacionais móveis do mercado. Utilizando deste argumento é possível analisar o impacto do uso deste tipo de arquitetura na produção de software para smartphones em comparação com o desenvolvimento tradicional.
Outro tema que pode ser explorado é a comparação aprofundada de usabilidade entre as aplicações nativas e web. Visto que as aplicações nativas oferecem alguns pontos exclusivos, como o uso do hardware local como câmera, acelerômetro, banco de dados, entre outros. Enquanto que nas aplicações web exploram menos desses recursos nos dispositivos. 8. Referências [1] Brookshear, J. G. (1997), Computer Science: An Overview, Fifth Edition, Addison-Wesley, Reading, MA. [2] "RETROBRICK - the home of vintage and rare mobile phones" http://www.retrobrick.com/moto8000.html (acessado em 17/04/2012) [3] "Worldmapper: The world as you've never seen it before" http://www.worldmapper.org/display.php?selected=333 (acessado em 17/04/2012) [4] "Gartner Says Worldwide Mobile Connections Will Reach 5.6 Billion in 2011 as Mobile Data Services Revenue Totals $314.7 Billion" http://www.gartner.com/it/page.jsp?id=1759714 (acessado em 17/04/2012) [5] "Global Mobile Phone & Smartphone Market (2010 - 2015)" http://www.researchandmarkets.com/reports/1545615/global_mobile_phone_and_smartphone_market_2010 (acessado em 15/03/2012) [6] "App Genome Report - February 2011" https://www.mylookout.com/appgenome (acessado em 19/04/2012) [7] "Gartner Says Worldwide Smartphone Sales Soared in Fourth Quarter of 2011 With 47 Percent Growth" http://www.gartner.com/it/page.jsp?id=1924314 (acessado em 19/04/2012) [8] "The Market For Mobile Healthcare Applications Will Grow To $US 1.3 billion in 2012 | research2guidance" http://www.research2guidance.com/us-1.3-billion-the-market-for-mhealth-applications-in-2012/ (acessado em 19/04/2012)
19
[9] "RhoMobile mobilize your enterprise apps" http://www.rhomobile.com/products/rhodes/ (acessado em 01/05/2012) [10] "Titanium Developer | Appcelerator Titanium Development Company" http://www.anubavam.com/titanium-developer (acessado em 01/05/2012) [11] "PhoneGap" http://phonegap.com (acessado em 04/06/2012)
20
Desenvolvimento Orientado a Testes de Aceitação
José Inácio Ferreira Filho, Olissea Artiaga da Silva
1Pontifí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) –
Abstract. This paper presents a study of techniques for requirements gathering and demonstrates how to use them in agile software development methodologies. First, some techniques will be presented to raise requirements, then the key will be known agile methodologies and how the requirements are raised in each.
Resumo. Este artigo apresenta um estudo de técnicas de levantamento de requisitos e demonstra como utilizá-las em metodologias de desenvolvimento ágil de software. Primeiro, será apresentado algumas técnicas para levantar requisitos, em seguida, será conhecido as principais metodologias ágeis e a forma como os requisitos são levantados em cada uma delas.
1. Levantamento de requisitos
O levantamento de requisitos desempenha um papel importante na construção de um sistema de informação, pois é o início para toda a atividade de desenvolvimento de software. É onde o analista faz as primeiras reuniões com os clientes e/ou usuários para conhecer as funcionalidades do sistema que será desenvolvido.
Algumas das razões para o baixo grau de satisfação dos usuários estão na fase de levantamento de requisitos do projeto, onde não é utilizada uma técnica adequada para extrair os requisitos do sistema, além disso, a falha do analista em não descrever os requisitos de modo claro, sem ambiguidades, conciso e consistente com todos os aspectos significativos do sistema proposto [Pompilho 1995].
As técnicas de levantamento de requisitos possuem um conceito próprio e podem ser utilizadas em conjunto pelo analista. A seguir serão apresentadas de forma resumida algumas dessas técnicas.
1.1. Entrevistas
A entrevista é uma das técnicas tradicionais mais simples de utilizar e que produz bons resultados na fase inicial de obtenção de dados. Convém que o entrevistador dê margem ao entrevistado para expor as suas ideias. É necessário ter um plano de entrevista para que não haja dispersão do assunto principal e a entrevista fique longa, deixando o entrevistado cansado e não produzindo bons resultados.
Existem dois tipos de entrevistas:
43
• Entrevista fechada, onde o engenheiro de requisitos tem um conjunto pré-definido de perguntas e está à procura de respostas.
• Entrevista aberta, sem perguntas pré-definidas do engenheiro de requisitos, onde há uma discussão de forma aberta com os interessados sobre o que eles esperam do sistema.
Na verdade, muitas vezes não há limite claro entre os dois tipos de entrevistas. Você começa com algumas questões que são discutidas e isso leva a novas questões [Sommerville 1997]. A vantagem de entrevistas é que elas ajudam o desenvolvedor a obter uma rica coleção de informações. Sua desvantagem é que esta quantidade de dados qualitativos pode ser difícil de analisar e poderá haver informações conflitantes das diferentes partes interessadas.
1.2. Questionários
Os questionários são indicados, por exemplo, quando há diversos grupos de usuários que podem estar em diversos locais diferentes. Neste caso, elaboram-se pesquisas específicas de acompanhamento com usuários selecionados, pois não seria prático entrevistar todas as pessoas em todos os locais.
Existem vários tipos de questionários que podem ser utilizados. Entre estes podemos listar: múltipla escolha, lista de verificação e questões com espaços em branco. O questionário deve ser desenvolvido de forma a minimizar o tempo gasto em sua resposta.
Na fase de preparação do questionário deve ser indicado o tipo de informação que se deseja obter. Assim que os requisitos forem definidos o analista deve elaborar o questionário com questões de forma simples, clara e concisa, deixar espaço suficiente para as repostas que forem descritivas e agrupar as questões de tópicos específicos em um conjunto com um título especial. O questionário deve ser acompanhado por uma carta explicativa, redigida por um alto executivo, para enfatizar a importância dessa pesquisa para a organização.
Deve ser desenvolvido um controle que identifique todas as pessoas que receberão os questionários. A distribuição deve ocorrer junto com instruções detalhadas sobre como preenchê-lo e ser indicado claramente o prazo para devolução do questionário. Ao analisar as respostas dos participantes é feito uma consolidação das informações fornecidas no questionário, documentando as principais descobertas e enviando uma cópia com estas informações para o participante como forma de consideração pelo tempo dedicado a pesquisa.
1.3. Brainstorming
Brainstorming é uma técnica para geração de ideias. Ela consiste em uma ou várias reuniões que permitem que as pessoas sugiram e explorem ideias.
Brainstorming contém duas fases - a fase de geração, onde as ideias são coletadas, e a fase de avaliação, onde as ideias coletadas são discutidas. Na fase de geração, as ideias não devem ser criticadas nem avaliadas. Cada ideia pode levar a novas ideias. A técnica de brainstorming leva a uma melhor compreensão do problema para todos e um sentimento de que todos cooperaram para atingir o objetivo.
44
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
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
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.
2.1. 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
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
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ós-planejamento.
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
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.
2.3. 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
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.
2.4. 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
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
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
Referências
ABRAHAMSSON, Pekka, SALO, Outi, RONKAINEN, Jussi e WARSTA, Juhani. Agile software developlment methods. Review and analysis. Espoo 2002. VTT Publications 478. 107 p.
CARVALHO COSTA, Gustavo Henrique de. Engenharia de Requisitos no Desenvolvimento de Software Ágil. Universidade Federal de Pernambuco, Centro de Informática, 2011.
FOWLER, Martin. The new methodology. http://www.martinfowler.com/ articles/newMethodology.html, 2000.
HIGHSMITH, James A. Adaptive Software Development. Dorset House Publishing, 1996.
LEFEBVRE, Eric, COAD, Peter e DE LUCA, Jeff. Java Modeling in Color with UML. Prentice Hall PTR, 1999.
POMPILHO, S. Análise Essencial Guia Prático de Análise de Sistemas. Rio de Janeiro: Ed. Ciência Moderna Ltda, 1995.
PRESSMAN, Roger S. Engenharia de Software. São Paulo: Ed. Markon Books, 1995.
SOMMERVILLE, Ian e KONTONYA, Gerald. Requirements Engineering. John Wiley & Sons, 1997.
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, 2004.
54
PROPOSTA DE AVALIAÇÃO DA QUALIDADE DE
REQUISITOS IDENTIFICADOS POR MEIO DA
ABORDAGEM ÁGIL SCRUM
Renata Dutra Braga1
Olisséa Artiaga da Silva1
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 2012.
{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 830-
1998. 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 830-1998. 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
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 9126-1 “obter um produto que
satisfaça as necessidades do usuário normalmente requer uma abordagem iterativa para o
56
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 Sprint1,
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
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 830-1998 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 830-1998.
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
/ estabilidade
Se existe indicações no documento quanto à importância ou
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
subsequentes do processo ou em uma melhoria da documentação do
sistema.
Assim como a Norma IEEE 830-1998, existem outras abordagens que visam
especificar requisitos com boa qualidade. Dentre elas, é possível mencionar a ISO 12207-
2008 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
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
Figura 1 - Processo de Desenvolvimento do Scrum. Fonte: http://scrumforteamsystem.com
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.
3.1. 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
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.
3.2. 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
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 830-1998 [IEEE 1998].
A tabela a seguir ilustra o checklist elaborado que contém, para cada característica
presente na Norma IEEE 830-1998, os itens a verificar nos requisitos registrados em cada
Sprint do projeto.
Tabela 3 - Checklist proposto. Fonte: O autor.
ID Itens a Verificar Escala
(0- NA/Não Atende; 5- Atende
Parcialmente; 10- Atende
Completamente)
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
63
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
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
Por Dundes, Leopoldo Wilson Malacrida . (2010, p.16) - ALINHAMENTO ESTRATÉGICO E
TI for Governança de TI e Governança Corporativa na Administração Pública:
De acordo com Fernandes e Abreu (2008, p.14), a Governança de TI estabelece as
regras, a estratégia e os processos que guiarão a utilização de tecnologia da informação
por todos os envolvidos, determinando como a TI deve prover esses serviços à
organização. Os autores ainda complementam que a Governança de TI compreende
vários mecanismos e componentes que, se corretamente integrados, permitem o
desenvolvimento desde a estratégia de TI até a operação de produtos e serviços
correlatos.
Para Weil e Ross (2006, p.8) Governança de TI é “a especificação dos direitos
decisórios e do framework de responsabilidades para estimular comportamentos
desejáveis na utilização de TI”. E que, ainda segundo os mesmos autores, a Governança
é a especificação de melhores práticas para a tomada de decisões fundamentadas por
ações mais conscientes e responsáveis, resultando em uma eficiente postura de controle e
gerenciamento de TI.
Em complementação às definições anteriores, e de acordo com o ITGI –
Information Technology Governance Institute (2009), a Governança de TI é
responsabilidade da alta administração (Administradores e Executivos) e busca o
compartilhamento das decisões de TI com os demais dirigentes da organização,
determinando como a TI deve sustentar e estender as estratégias e objetivos da
organização.
72
A Governança de TI é um conjunto de processos que direciona a estratégia de
Tecnologia da Informação, garantindo que a TI possa suportar os requisitos do negócio,
estabelecidos a toda a organização por intermédio da Governança Corporativa.
Ao longo da última década, a TI ultrapassou o campo das abordagens puramente
técnicas e se tornou um dos principais recursos para o sucesso, ou até fracasso,
organizacional. É fundamental, pois, que a Governança de TI deva garantir a integração
de forma alinhada ao negócio, sempre tendo como base a garantia de continuidade do
negócio e o atendimento às estratégias estabelecidas.
O alinhamento entre negócio e TI é alcançado quando um conjunto de estratégias
definidas para a TI é derivado do conjunto estratégico organizacional, definido pela
Governança Corporativa. Essa política permite a TI ter uma posição mais clara e
consistente em relação aos outros setores da organização, indicando a importância que a
TI apresenta na relação entre investimentos e desempenho organizacional.
Entretanto, além da necessidade imposta pela estratégia organizacional, diversos
outros fatores motivam a política de implantação da Governança em TI, conforme a
figura 1 (FERNANDES; ABREU, 2008, p.9). Com isso, espera-se que a organização
direcione seus recursos de forma específica a cada fator motivador, sempre objetivando
realizar o planejamento da forma mais eficiente e eficaz possíveis.
Figura 1: Motivação para a Governança de TI - Fonte: Fernandes e Abreu (2008, p.9)
73
1.1 Alinhamento Estratégico e TI
Por Dundes, Leopoldo Wilson Malacrida . (2010, p.20) - ALINHAMENTO ESTRATÉGICO E
TI for Governança de TI e Governança Corporativa na Administração Pública:
Sabe-se que a área de TI sozinha, não possui supremacia suficiente para tomar decisões
de direcionamentos estratégicos organizacionais. Logo, seus direcionamentos devem
estar alinhados com os direcionamentos estabelecidos a toda organização. Para
Henderson e Venkatraman (1993) esse alinhamento é considerado um fator essencial
para o retorno de investimento e para a efetiva agregação de valor ao negócio.
Alinhamento estratégico é o processo de transformar as estratégias organizacionais
em estratégias e ações de TI que garantam que os objetivos estabelecidos ao negócio
sejam apoiados (FERNANDES; ABREU, 2008).
No alinhamento procura-se determinar qual a necessidade em termos de
arquitetura, infra-estrutura, aplicação, processos e organização entre a TI e os requisitos
do negócio.
Segundo Duffy (apud CARVALHO, 2006), o alinhamento entre TI e o negócio é
o processo de se obter vantagem competitiva por meio do desenvolvimento e
sustentação de uma relação de benefícios mútuos entre o negócio e a TI.
A vantagem competitiva refere-se a TI como um processo estratégico contínuo,
essencial para o negócio organizacional. Além, é preciso que a TI suporte as operações e
necessidades atuais e esteja preparada para as necessidades futuras, necessitando,
portanto, ser gerenciada por intermédio de processos contínuos e otimizados.
Nesse contexto, a TI atua como forma de alinhamento, alocando recursos, e
provendo às empresas as informações necessárias para a sustentação do negócio.
Logo, seu uso torna-se extremamente importante e fundamental para a eficácia e
eficiência da estratégica organizacional.
Assim, é extremamente importante o estabelecimento de boas políticas de gestão e
estratégia em TI, para que seus benefícios sejam percebidos e agregados rapidamente ao
resultado organizacional.
Nessa perspectiva, para o correto planejamento estratégico em uma organização
pública, é necessário conhecer todas as normas, regulamentos e legislações a que estão
74
subordinadas. Porém, a grande quantidade de requisitos legais impostos a este tipo de
organização impede a explicitação e análise de todos eles.
Como a Governança de TI é um conjunto de processos que direciona a estratégia
de Tecnologia da Informação, garantindo que a TI possa suportar os requisitos do
negócio, estabelecidos a toda a organização por intermédio da Governança Corporativa,
assim concluímos que a ausência de um Escritório de Processos de TI compromete toda
a administração de TI e, também, corporativa.
2. Escritório de Projetos da DI
Nos anos de 2007, 2008 e 2009, o TJGO publicou e executou o seu o primeiro Plano
Estratégico corporativo. De 2009 a 2011 tivemos o segundo e recentemente, de 2011 a
2013, estamos em plena execução do terceiro Plano Estratégico. Hoje, são 72 projetos
dos quais 12 (alguns desmembrados que totalizam em 20) estão diretamente sob a gestão
da Diretoria de Informática a sua execução, sendo que um desses projetos é a
implantação da Governança de TI. No ano de 2010 também foi elaborado o
Planejamento Estratégico de TIC – PETIC, que se estenderá até 2014 a sua execução.
Nele estão previstas 13 metas estratégicas a serem alcançadas, que estão desmembrados
em muitos projetos que necessitam de uma eficaz Gestão de Projetos. Em todos esses
anos, o Tribunal de Justiça tem buscado e implantado nas suas áreas a Gestão de
Projetos.
Com a criação do Escritório de Projetos da DI, a estrutura organizacional
hierárquica, ainda inerente, começa, pouco a pouco, a dar lugar a uma estrutura
projetizada. A realidade é que o “bonde hierárquico” começa a dar lugar a um “trem bala
projetizado” de altíssima tecnologia administrativa embarcada e de uma velocidade
impressionantes, que ora vai deslizando suavemente nos trilhos da competência
implementada deixando a era dos solavancos e descarrilhamentos para trás. Ainda
podemos constatar que aqueles que estão viajando de bondinho ainda não sentiram o
agradável vento forte da Gestão de Projetos em suas atividades. A brisa veloz e o mais
agradável sentimento de sucesso corporativo são tudo aquilo que obtemos com os
projetos hoje sendo iniciados, executados e finalizados com tecnologia e práticas ágeis,
tudo isso registrado em um banco de dados (a informação agora disponível para todos)
como “lições aprendidas”.
75
Podemos somar à Gestão de Projetos as diretrizes da Gestão do Conhecimento:
uma instituição de porte do Poder Judiciário Goiano que almeja “ser referência no
cenário nacional como padrão de excelência nos serviços prestados à sociedade para
realização da justiça”, não pode se dar ao luxo de repetir os erros do passado por falta
de registro e acesso rápido a informações; deve evitar a repetição (prevenir esforço
redundante) e nunca pode deixar de aproveitar o que os outros já sabem. A Gestão de
Projetos e o registro do conhecimento vão levar o judiciário goiano a: – redução dos
custos e tempo de produção e desenvolvimento de produtos – maximização do capital
intelectual/ativos intelectuais – melhoria dos processos internos e maior fluidez nas
operações – processos de tomada de decisões mais eficientes e melhoria de resultados –
melhoria na coordenação de esforços entre as unidades administrativas e judiciais –
melhoria na prestação de serviços (agilidade), da qualidade dos produtos e da qualidade
do serviço prestado aos seus clientes.
Nesse tempo, a Diretoria de Informática trabalhou, mas isso somente até o final
do ano de 2010, com vários projetos nunca antes devidamente alinhados
estrategicamente e nunca aplicando as técnicas ágeis de gestão de projetos. Durante o
ciclo de vida desses projetos, passados e também os atuais, vários problemas foram e são
enfrentados, como falta de estimativas, imprecisão quanto a prazo e custo, dificuldade na
seleção de pessoas apropriadas, ausência de um histórico de projetos para melhor
planejar os novos (também chamado de “lições aprendidas”), expansão do número de
projetos desenvolvidos, falta de alinhamento estratégico, ou seja, um alto custo para as
organizações que buscam a Tecnologia da Informação e Comunicação (TIC) como
parceiros e até executores de seus projetos alinhados estrategicamente.
A implantação de um Escritório de Projetos da DI foi uma solução para enfrentar
esses problemas já relacionados. Assim, o Escritório de Projetos simplifica, facilita e
aperfeiçoa o gerenciamento de projetos, que tem se mostrado útil nas áreas que
desenvolvem muitos projetos simultaneamente evitando o retrabalho; alivia o trabalho
dos gerentes de projetos ao compartilhar a execução das tarefas de planejamento e
acompanhamento, sobrando tempo para esses gerentes “fazerem as coisas acontecerem”,
ou seja, para executarem mais tranquilamente o seu trabalho. Acrescentamos aqui, a
76
tempo, que a busca da prosperidade e da própria sobrevivência dependem do portfólio
de projetos priorizado e gerenciado.
O Escritório de Projetos da DI está alinhado aos objetivos estratégicos do TJGO
por meio do Plano Estratégico de Tecnologia da Informação e Comunicação que possui
os seus objetivos alinhados aos estratégicos e define os projetos e ações prioritárias a
serem executados pela Diretoria.
O propósito da implantação do Escritório de Projetos da DI é a verificação dos
benefícios efetivos que surgem como resultado de adoção, implantação e
operacionalização de um PMO, tais como: redução de prazo nos projetos, melhores
estimativas e cumprimento de custos, redução nas alterações de escopo, melhoria de
qualidade, históricos de projetos antigos para melhor aperfeiçoamento futuro (“lições
aprendidas”), melhor gerenciamento de competências e outros ganhos.
O Escritório de Projetos da DI é uma unidade organizacional dentro da Diretoria
de Informática que centraliza e coordena o gerenciamento de projetos sob seu domínio.
Concentra-se no planejamento, priorização e execução de projetos e subprojetos
vinculados aos objetivos de negócio de TI e também da organização. Pode operar desde
o fornecimento de funções de apoio até o gerenciamento direto real.
3. Escritório de Processos
Rui Lima Godinho, analista de processos de negócio, define abaixo algumas
características principais do Escritório de Processos:
Autonomia: O escritório deve estar diretamente ligado à DI e à alta direção da organização e quanto menos ligado a uma outra área melhor. Sendo uma disciplina ligada à gestão e com foco na melhoria, otimização e controle de processos de TI, deve ter autonomia de decisão e funcionamento para conseguir atingir estes objetivos;
Alinhamento funcional e estratégico: Apesar de manter a sua autonomia, o escritório deve manter um alinhamento com todas as outras áreas complementares internas do negócio e com a direção de forma a obter um padrão, coerência e seguindo uma mesma metodologia de funcionamento da instituição;
Visão além: Uma vez que o escritório não fornece resultados de imediato, tanto os integrantes do escritório, os atores dos processos e a direção devem ter uma visão além no tempo, apostando com a certeza de que os resultados aparecerão e que sem dúvida serão benéficos;
Estrutura multidisciplinar: Não só o CPO e analistas fazem parte desta estrutura. Também a direção faz parte, uma vez que deverá ser ela a aprovar e analisar os resultados dos indicadores fornecidos pelo escritório;
77
Gestão de processos: Possuindo o Escritório de Processos um processo, também, este precisa ser mapeado e modelado, definindo os papéis de cada um dos atores envolvidos, as metodologias aplicadas e ferramentas de implementação, conseguindo assim um correto funcionamento do mesmo.
A criação de um Escritório de Processos pode gerar “custos”, como
disponibilização de um espaço físico, criação de novos cargos, treinamento de pessoal,
compra de novos equipamentos e softwares; mas desde que bem implementado, em
médio/longo prazo é um investimento com retorno garantido e que apresentará
resultados em nível de redução de custos, eliminação de gargalos em processos, melhor
funcionamento entre os setores internos e geração de informações estratégicas no plano
organizacional.
Segundo Paim (2002), a gestão funcional das organizações, geralmente
verticalizada, departamentalizada e, por vezes e não raro desintegrada, precisa ser
modificada e até complementada para uma gestão orientada no sentido da agregação de
valor que ocorre horizontalmente nas organizações através de seus processos. Este
entendimento leva à definição de processo enquanto um conjunto de atividades
dinâmicas, necessárias para obter algo que adicionará valor ao negócio. Davenport
(1994) define que processo é um conjunto estruturado e mensurável de atividades
designadas para produzir um resultado específico para um cliente ou mercado particular.
O gerenciamento dos processos permite às organizações aumentarem significativamente
a produtividade e ao mesmo tempo diminuírem os ciclos de tempo para a criação e
adaptação de um processo, mas precisa de mudanças significativas nas práticas
gerenciais e, principalmente, culturais das organizações (PAIM, 2002; DAVENPORT,
1994).
Segundo a lógica da teoria de sistemas, qualquer organização precisa trocar
informações com o seu entorno de forma a absorver as mudanças que forem requeridas
pelo mercado, pelo governo ou por qualquer outro ator do meio no qual está inserida.
Ainda segundo esta teoria, para existir capacidade de efetiva comunicação, as partes do
sistema necessitam compreender as informações trazidas pelos seus predecessores, seja
diretamente ou através de mecanismos de decodificação e, desta forma, aprender
(STERMAN, 2000). Assim, existe um nível de aprendizado que precisa ser alcançado a
fim de atuar otimamente junto aos processos, sejam eles da demanda à oferta ou do
cliente ao cliente. Os ciclos de processo precisam ser reduzidos e a simples implantação
78
de filosofia enxuta do Sistema Toyota de Produção - STP (SHINGO, 1996) ou a adoção
de tecnologias de workflow.
A mudança de visão de uma estrutura funcional para uma visão por processos é
cultural, e o êxito da utilização requer atitude de mudança e quebra de paradigmas.
Conscientização e comprometimento do gerente e de sua equipe são fundamentais para o
atendimento do macroprocesso. Isso aumenta o compromisso de manter as informações
atualizadas e a sinergia da equipe, ponto forte para a confiabilidade das informações.
De acordo com Saulo Barbará (2006), a visão por processos privilegia a análise
das atividades transversais à organização, permitindo o entendimento e a melhoria da
organização como um todo.
A necessidade de gestão por processos surge, dentre outros fatores, da
preocupação com a imagem da organização perante o mercado e a sociedade cada vez
mais exigentes.
As atividades bem definidas permitem acompanhar com transparência as etapas de
um processo aumentando a credibilidade. Ainda mais numa sequência de atividades
importantes que demandam tempo, dificilmente são percebidas pelo cliente, isso aumenta
a percepção de qualidade em relação ao produto.
O ambiente interno das organizações vem passando por mudanças estruturais do
ponto de vista comportamental, tecnológico e, principalmente, mercadológico. A
revolução ocorrida nos anos 90, que direcionou os esforços para a percepção do cliente,
provocou a necessidade de uma guinada na forma de pensar a estrutura interna de
funcionamento dos negócios. O foco no cliente faz com que cada pessoa que atua na
organização deixe de pensar de forma funcional (o que eu faço?) e passe a se ver como o
elo de uma cadeia que liga o fornecedor ao cliente (como e para quem eu faço?). O
problema é que a organização montada pela ótica tradicional não se percebe desta
maneira e continua orientada para um modelo hierárquico, desenvolvido sob a ótica dos
“departamentos”.
Outro aspecto importante a ser ressaltado é que o aprimoramento da tecnologia
possibilitou a utilização das máquinas nos processos produtivos de maneira cada vez
mais inteligente. O conceito processual chegou também à forma de desenvolver os
programas de computador, que estão sendo criados para permitir o fluxo de processos e
79
não mais a abordagem meramente funcional estática, que impedia a sua utilização em
modelos de fluxos de atividades em sequência, potencializando, desta forma, o uso das
máquinas nas relações de produção. (BARBARÁ, 2006)
3.1 Escopo de Atuação do Escritório de Processos
Dentre as responsabilidades de um Escritório de Processos estão incluídas o
estabelecimento de padrões, métodos, ferramentas, treinamento, governança e
integração dos processos, além disso, tem o papel relevante na priorização e alocação de
recursos em melhorias de processos, dentre outras.
Atribuições Gerais: Coordenar a implantação da cultura de processos; Promover a melhoria contínua dos processos; Normatizar os esforços de melhoria dos processos.
Atribuições Específicas: Metodizar e padronizar a documentação de processos; Melhorar a gestão dos projetos de redesenho de processos; Controlar a produtividade e os riscos dos processos; Suportar a cultura interna para o tratamento dos processos; Suportar as iniciativas do uso de tecnologia para processos; Desenvolver e difundir internamente a metodologia e as melhores práticas de
gestão por processos; Orientar na formulação dos indicadores de desempenho dos processos; Promover a auto-avaliação dos processos, explicitando a contribuição dos
mesmos para o alcance dos objetivos estratégicos da Informática e da corporação;
Subsidiar o planejamento estratégico de TIC no que diz respeito à otimização da utilização dos recursos;
Proporcionar e fomentar a integração entre os processos; Identificar oportunidades de melhorias nos sistemas de informação existentes,
buscando a integração dos mesmos; Suportar a geração de conteúdo referente à capacitação dos envolvidos nos
processos; Alinhar os processos de negócio da informática com a estratégia corporativa; Formalizar os processos de negócios de forma unificada e padronizada.
Diante das propostas de estruturas e características predominantes nas
organizações, este artigo sugere como as principais características e atribuições para o
Escritório de Processos da Diretoria de Informática do TJGO, as seguintes:
O Escritório de Processos deve ter como foco o serviço que visa à melhoria de
processos da DI, assim não tem a responsabilidade de direção do processo de negócio da
mesma, mas esta para apoiar os gestores de processos, isto é, as responsabilidades das
80
áreas (divisões) da DI continuam sob a direção das mesmas e deve ser uma unidade
normativa e coordenadora na qual:
Prescrever métodos e ferramentas que orientem o gerenciamento dos processos-chave de TI;
Possuir o papel de facilitador, atuando como elo de comunicação e negociação entre as diferentes áreas (divisões) envolvidas nos processos gerenciados;
Possuir uma visão sistêmica do negócio, pois desta forma permite que a Diretoria de Informática passe a ter uma análise mais eficaz e integrada de suas atividades;
Receber e gerenciar as sugestões de melhoria que beneficiam o processo como um todo;
Promover a auto-avaliação dos processos, explicitando a contribuição dos mesmos, para o alcance dos objetivos estratégicos de DI e da corporação;
Subsidiar o planejamento estratégico de TIC no que diz respeito à otimização da utilização dos recursos;
Assessorar a Diretoria de Informática e ser a unidade responsável por inserir e gerir a prática de gestão por processos.
3.2 Perfil e Atribuições do Gestor de Processos e Gestor do Escritório de Processos
Em conjunto com a implantação de um Escritório de Projetos, é necessário que duas
novas funções sejam criadas na DI: a função do gestor do processo e a do gestor do
escritório de processo.
O gestor do Escritório de Processos será o responsável pela gestão do
macroprocesso e deverá ser capaz de planejar e coordenar a implantação de todas as
disciplinas referentes à gestão de processos na DI do TJGO.
O gestor de processo poderá ser responsável por um ou mais processos da DI.
Quantos processos serão atribuídos a um gestor dependerá da complexidade dos
processos.
O perfil do gestor do Escritório de Processos e do gestor de processo é o
mesmo, com a diferença que o gestor do Escritório de Processos deve ter um
conhecimento mais amplo do negócio da DI.
Perfil do Gestor de Processos: a) Formação técnica em informática ou administração; b) Boa comunicação; c) Conhecimento do Negócio (ter conhecimento amplo do processo sob sua
gestão); d) Conhecer a influência e uso da Tecnologia da Informação no suporte à
execução dos processos; e) Amplo conhecimento em Governança de TI; f) Alta capacidade na integração de recursos;
81
g) Visão de corporação orientada por processos; h) Conhecer metodologias, ferramentas e técnicas de melhoria de processos; i) Conhecimentos práticos em gestão de conflitos e gestão de projetos; j) Experiência anterior comprovada em funções de gestão.
Dentre as atribuições do gestor de processo e do Escritório de Processos
disponíveis no mercado, relacionaremos abaixo as que mais se adaptam à cultura do
TJGO e à metodologia proposta:
Atribuições do Gestor de Processos: a) Modelar, detalhar, validar o seu processo com todos os envolvidos; b) Treinar os envolvidos no processo; c) Implantar e monitorar constantemente e execução do seu processo; d) Ser o elo de ligação entre a equipe que executa o processo e o Escritório de
Processos da DI (BPMO-DI); e) Participar da definição, revisar e monitorar os indicadores de desempenho
(Painel de Bordo) e planos de ação correspondentes, adotando medidas corretivas, sempre que desvios se fizerem presentes;
f) Manter a equipe informada que tem envolvimento com o processo sobre os desempenhos e resultados dos indicadores;
g) Manter-se informado sobre referências de desempenho no mercado e desenvolver atividades de benchmarking regulares;
h) Criar condições (facilidades) para fomentar e implementar rotinas de melhoria continua, explorando oportunidades de melhoria;
i) Cuidar do relacionamento nas interfaces do seu processo com outros processos;
j) Medir e monitorar constantemente o desempenho do processo sob a sua responsabilidade.
Atribuições do Gestor do Escritório de Processos: a) Ser o elo de ligação entre todos os processos que são monitorados pelo
Escritório de Processos da DI (BPMO-DI) e a Alta Direção; b) Monitorar a definição, revisão e monitoramento dos indicadores de
desempenho (Painel de Bordo) e planos de ação correspondentes, desenvolvidos pelos gestores de processo;
c) Criar condições (facilidades) para fomentar e implementar rotinas de melhoria continua em todos os processos da DI;
d) Monitorar constantemente o desempenho dos processos da DI; e) Manter a Alta Direção envolvida e com conhecimento necessário sobre o
desempenho e resultado dos indicadores dos processos. 4. O Escritório de Projetos X Escritório Processos
O Escritório de Projetos é uma unidade responsável por monitorar os projetos com
início, meio e fim bem definidos. Sabemos que normalmente, após a implantação do
projeto este vem a se tornar uma rotina organizacional, portanto ele se transforma num
“processo” organizacional e daí surge então a necessidade de implantação de um
Escritório de Processos.
82
O Escritório de Processos é o responsável por manter o repositório de modelos de
processos, também identificar oportunidades de melhorias nos processos e acompanhar o
trabalho dos gestores de processos por meio da avaliação dos resultados dos indicadores
dos processos.
Dentre as responsabilidades do Escritório de Processos estão incluídas o
estabelecimento de padrões, métodos, ferramentas, treinamento, governança e integração
dos processos, além disso, tem o papel relevante na priorização e alocação de recursos
em melhorias de processos.
Um Escritório de Projetos que implementa na prática a gestão por processos
possibilita à organização atuar com eficiência nos recursos e com eficácia nos resultados,
otimizando também:
Foco concentrado em função do produto fim da organização; Gestão dos processos críticos através de indicadores de desempenho; Implementação de estratégias organizacionais; Tornar claro a contribuição e responsabilidade dos colaboradores; Aumentar a sinergia existente entre os processos; Auxiliar na gestão de mudanças; Uniformização do entendimento da forma de trabalho.
Concluímos, então, que ambos os escritórios possuem funções diferentes e que
de certa forma se complementam e promovem mudanças e melhorias para a geração de
excelência operacional e inovação e tem conexão com a estratégia da organização,
conforme demonstrado na figura 2 abaixo:
Figura 2 – Processos e Projetos contribuindo com a Estratégia da Organização.
5. Gestão por Processos
E S T R A T É G I A
PROCESSOS PROJETOS
83
De Sordi define que para uma organização implantar o modelo de gestão por
processos, se faz necessária a utilização de uma estrutura para montar um sistema de
controle capaz de assegurar os resultados pretendidos, conforme a seguir:
Definição de posicionamento estratégico que possa deixar bem claro para a organização qual é o seu negócio e o horizonte pretendido em relação a ele, e os parâmetros para o monitoramento da eficácia e eficiência do modelo.
Definição dos processos de negócio e o seu vínculo à estrutura de tecnologia da informação, para que os processos possam ser automatizados diminuindo a dependência do erro humano.
Definição da competência das pessoas envolvidas na realização de cada regra de negócio, mapeada a partir do gerenciamento por processos. A alocação de recursos humanos deve ser feita rigorosamente com base no perfil de competência.
Definição de modelo de responsabilidade e autoridade focado nas atividades previstas nos modelos de negócio e não mais em unidades gerenciais focadas em autoridade e localização geográfica.
Definição de um modelo de documentos para servir de estrutura normativa de institucionalização das regras e servir à gestão do conhecimento.
Definição do modelo de monitoramento dos resultados a partir da estrutura de negócios e não mais focada em unidades gerenciais.
A implementação da gestão por processo deverá provocar um desconforto muito
grande nos gerentes tradicionais, focados inteiramente no modelo departamental, uma
vez que pode parecer que a visão por processos retira a autoridade dos “chefes”. Ao
contrário do que foi pregado inicialmente na reengenharia, o modelo de gestão do
processo valoriza intensamente o líder, pois é ele quem monitora o desempenho do
processo e atua na correção em relação ao que foi planejado. Ou seja, coloca o gerente
na posição realmente de gestor de estratégias e recursos.
As dificuldades na implantação deste novo modelo de gestão devem ser vistas não
como intransponíveis para o sucesso do empreendimento, mas com a ótica de que a
mudança pretendida prepara as pessoas e as organizações para competir em um mundo
onde as regras estão diferentes, onde sobreviver dependerá da competência de atingir
resultados focados no atendimento de necessidades de outros. Este talvez seja o maior
legado da gestão por processos; “o aprimoramento das formas de melhor atender ao
próximo”. (DE SORDI, 2008).
6. A Estrutura Hierárquica Atual da DI
A estrutura atual da Diretoria de Informática do TJGO é caracterizada como hierárquica
e departamentalizada. Todas as decisões são tomadas pelos diretores das Divisões e não
84
existe uma gestão integrada e orientada no sentido da agregação de valor ao cliente.
Nesta estrutura, muitas vezes as demandas dos clientes podem ficar esquecidas, pois não
se consegue ter uma visão clara sobre o impacto do resultado final do trabalho que está
sendo executado e será entregue ao cliente.
No mês de julho de 2011 implantamos, na DI, o Escritório de Projetos com o
objetivo de efetuar a gestão do portfólio de projetos desenvolvidos na área, conforme
figura 3 abaixo:
Figura 3 – Organograma da Estrutura Hierárquica da Diretoria de Informática do
TJGO
7. A Governança de TI no Judiciário Brasileiro
No Judiciário brasileiro o tema tem sido amplamente discutido como fator chave de
sucesso para a melhoria dos resultados alcançados pelos Tribunais.
O termo “Governança de TI” tem suas origens no conceito de “Governança
Corporativa”, mas não devemos confundir esses conceitos. Além disso, a "Governança
de TI" relaciona-se com a "gestão/gerenciamento de TI", porém não são a mesma coisa.
Para entendermos melhor as semelhanças, as diferenças e o inter-relacionamento do
significado desses, quando, no item 2, afirmei que a “estrutura organizacional
hierárquica, ainda inerente na DI, começa, pouco a pouco, a dar lugar a uma estrutura
projetizada e que o “bonde hierárquico” começa a dar lugar a um “trem bala projetizado”
de altíssima tecnologia administrativa embarcada e de uma velocidade impressionantes,
que ora vai deslizando suavemente nos trilhos da competência implementada, vai
deixando a era dos solavancos e descarrilhamentos para trás”; tudo isso afirmado tem
uma relação direta com a implantação do Escritório de Processos, pois indago: o
85
processo não é a forma e/ou não é um conjunto sequencial e particular de ações com o
objetivo comum de se executar um serviço ou produzir algum bem ou produto?
Assim o “trem bala” somente vai poder deslizar veloz e suavemente se os trilhos que o
guiarem não forem também de altíssima qualidade e que o itinerário, o mais racional
possível, vai eliminar as curvas perigosas que provocam atrasos, sucateamento e o mau
uso da máquina, desperdícios financeiros, queima desnecessária de energia,
desfocamento (miopia administrativa), alinhamento, aderência, etc. Não poderia deixar
de ressaltar aqui que sem um bom motor (o desejo) e o combustível de qualidade
(capacidade) não sairemos do lugar onde estamos. Vejamos abaixo algumas definições.
7.1 Governança Corporativa
Segundo o Instituto Brasileiro de Governança Corporativa (IBGC): "Governança
Corporativa é um sistema por onde 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 a
recursos e contribuindo para sua longevidade".
7.2 Governança de TI
Para o Ministro Aroldo Cedraz, “Governança de TI é o conjunto estruturado de
políticas, normas, métodos e procedimentos destinados a permitir à alta administração e
aos executivos o planejamento, a direção e o controle da utilização atual e futura de
tecnologia da informação, de modo a assegurar, a um nível aceitável de risco, eficiente
utilização de recursos, apoio aos processos da organização e alinhamento estratégico
com objetivos desta última. Seu objetivo, pois, é garantir que o uso da TI agregue valor
ao negócio da organização”. (TCU 2010).
Para o Information Technology Governance Institute (ITGI), “Governança de
TI é de responsabilidade dos executivos e da alta direção, consistindo em aspectos de
liderança, estrutura organizacional e processos que garantam que a área de TI da
organização suporte e aprimore os objetivos e as estratégias da organização”.
Observa-se, portanto, que a “Governança Corporativa” tem foco no
direcionamento e monitoramento da gestão da instituição, e busca permitir a intervenção
86
dos responsáveis finais sempre que houver desvio em relação ao esperado. Em última
instância, esses responsáveis são os detentores da propriedade: sócios e acionistas, no
caso das organizações privadas, e a sociedade, no caso das organizações públicas
federais, estaduais e municipais.
Já a “Governança de TI” tem foco no direcionamento e monitoramento das
práticas de gestão e uso da TI de uma organização, tendo como indutor e principal
beneficiário a alta administração da instituição.
Um exemplo prático de mecanismo de Governança de TI é o estabelecimento de
um processo transparente de tomada de decisão sobre a priorização de grandes
demandas de TI. Tal processo é necessário para garantir que as ações de TI estejam
alinhadas com os objetivos institucionais e para garantir que as demandas que tenham
maior impacto nesses objetivos tenham atendimento prioritário. Esta é uma decisão que
não cabe às unidades de TI (embora devam sempre opinar). Portanto, com o
estabelecimento desse processo, afirmamos que os seus participantes e suas
competências são iniciativas de Governança de TI a ser liderada pela alta administração.
8. A Nova Estrutura Hierárquica Proposta para a DI
Diante de diversas vantagens e da necessidade de implantação de um Escritório de
Processos e da Governança de TI, na figura 4 abaixo propomos o novo organograma
com a adesão do Escritório de Processos como núcleo de assessoramento da Diretoria
de Informática:
87
Figura 4 – Organograma da Proposta de Estrutura Hierárquica para a Diretoria de Informática do TJGO
9. A Implantação do Escritório de Processos na DI
Uma vez contextualizado e definido o escopo de atuação do Escritório de Processos, o
perfil do gestor de processo e gestor do Escritório de Processos, podem-se delinear os
objetivos que visam ser alcançados e que justificam a implantação do Escritório de
Processos na DI.
9.1 Um Modelo para Implantação do Escritório de Processos
Para o alcance de tais objetivos, muitas atividades específicas e consistentes devem ser
desdobradas. Novamente, os detalhamentos de tais atividades estão diretamente
relacionados ao escopo da organização da DI cujos processos em questão estão sendo
gerenciados. No entanto, devem-se listar algumas ações que, quando aplicadas nos casos
específicos, contribuem para a realização dos objetivos enunciados.
Conforme consta no estudo de caso (CANDIDO; SILVA; ZUHLKE, 2008) foi
utilizada a lógica ilustrada na figura 5 abaixo, sendo que esta também poderia ser
utilizada para implantação da metodologia de gestão por processos:
Figura 5 – Etapas de Implantação da Gestão por Processos – Fonte: (CANDIDO; SILVA; ZUHLKE, 2008)
9.1.1 Mapeamentos dos Processos
Esta etapa preconiza o entendimento da organização ou parte dela onde será a
implantação.
Serão realizados estudos aprofundados sobre todo material disponível pela
organização (impresso e digital) que poderão dar informações sobre a estrutura da
gerência, características dos seus negócios, características dos clientes, procedimentos
existentes, e as orientações coorporativas.
Mapear um processo é fazer um desenho inicial, uma fotografia do momento. É
a observação de como uma sucessão de atividades são executadas e inter-relacionadas.
88
9.1.2 Modelagem dos Processos
A modelagem dos processos consiste em redesenhar os processos, com a finalidade de
colocar o processo mapeado em um molde ideal, atingindo dessa forma os resultados
esperados. Esse molde ideal é formatado com base nas orientações corporativas e nas
propostas de melhorias dos envolvidos nos processos.
Com base apenas no mapeamento, à primeira discrepância corrigida, será feito a
otimização de recursos e distribuição da mão de obra, que agora distribuída em função
dos processos.
9.1.3 Divulgação da Modelagem
Quando todos os modelos forem validados, será realizado um workshop para que cada
grupo apresente os processos de sua responsabilidade. O objetivo é que os grupos
defendam as melhorias em seus processos e os disseminem, para que a gerência possa
compreender suas interações e tenham visão integrada de todas as atividades através dos
processos, e não mais por funções.
9.1.4 Implantação da Modelagem
A implantação dos modelos será realizada de forma gradativa e controlada através de
um cronograma. A elaboração de priorização das ações a serem implantadas será
apontada pelo gerente, e o critério adotado para formação da lista serão os processos de
maior criticidade. Essas criticidades estão baseadas nos impactos estratégicos e nas
orientações coorporativas.
9.1.5 Gestão por Processos
Nesta etapa, a gestão por processos passará a ser reconhecida e executada de forma
contínua. Devido à transparência de todos os processos, responsáveis e interfaces, nesta
etapa é possível administrar com eficiência tudo que foi observado.
A mudança de visão de uma estrutura funcional para uma visão por processos é
cultural, e o êxito da utilização requer atitude de mudança e quebra de paradigmas.
Conscientização e o comprometimento do gerente e de sua equipe são fundamentais
para o atendimento do macroprocesso. Isso aumenta o compromisso de manter as
informações atualizadas e a sinergia da equipe, ponto forte para a confiabilidade das
informações.
89
9.2 Fator de Sucesso na Implantação do Escritório de Processos na DI
Dentre as melhores práticas e premissas para implantação de um Escritório de Processos,
relacionamos algumas que consideramos serem as mais adequadas e são fator de
sucesso, considerando o cenário atual existente na DI do TJGO:
A alta direção (Presidência, Comissão de Informatização, Secretaria de Gestão Estratégica e Diretoria Geral) deve participar de uma palestra na qual deverão ser apresentados os objetivos práticos da nova gestão proposta para a DI e os benefícios a serem alcançados a longo prazo;
O papel do Escritório de Processos deve ser comunicado a toda organização; É fator de sucesso que os profissionais selecionados tenham perfil alinhado ao
papel desejado; O Escritório de Processos deve ser inserido em uma posição de
assessoramento permitindo um bom trânsito com todas as áreas da DI e da alta direção da Instituição;
Desenvolver a competência dos integrantes da área em gestão por processos. 10. Conclusão
A efetiva implantação de um Escritório de Processos na DI possibilitará um melhor
controle dos processos realizados por esta Diretoria dentre vários benefícios citados
abaixo:
Visão sistêmica dos serviços prestados pela DI; Otimização dos serviços de TIC; Entrega de mais valor aos clientes da TIC por meio do monitoramento
constante de seus processos de negócio que também são constantemente otimizados e racionalizados;
Contribuição efetiva aos projetos do PE do TJGO e do PETIC da DI; Melhoria contínua dos processos de TIC; Implantação na Divisão de Sistemas de Informação de um eficiente processo
definido e documentado de desenvolvimento e testes de software; Implantação na Divisão de Atendimento ao Usuário de um eficiente processo
de atendimento ao usuário (service desk). Para a efetiva implantação do Escritório de Processos sugere-se a definição de
um projeto. Após esta definição, deve ser estabelecido um gestor para o projeto e uma
equipe que deverá ser nomeada pelo Diretor de Informática e que irá elaborar todos os
artefatos necessários para a execução e gestão do projeto. É imprescindível que a Alta
Direção do TJGO participe efetivamente como patrocinadora do projeto, conhecendo
todos os benefícios de tal implantação e oferecendo os recursos necessários para que o
Davenport, T. (1994). Reengenharia de processos: como inovar na empresa através da tecnologia de informação. Rio de Janeiro: Campus.
Paim, R. (2002). Engenharia de Processos: análise do referencial teórico-conceitual, instrumentos, aplicações e casos. Rio de Janeiro: Dissertação de Mestrado. COPPE/UFRJ.
Sterman, J.D. (2000). Business Dynamics: systems thinking and modeling for a complex world. Ney York: McGraw-Hill.
Shingo, S. (1996). O Sistema Toyota de Produção, Porto Alegre: Bookman.
Candido, Rafael M. (2008); Silva, Michele T.F.M.; Zuhlke, Rodrigo F. Implantação da Gestão por processos: estudo de caso numa gerência de um centro de pesquisas. XXVIII Encontro Nacional de Engenharia de Produção.
De Sordi, Jose Osvaldo (2008). Gestão por processos. 2. ed. rev. São Paulo: Saraiva.
TCU – Tribunal de Contas da União - Voto do Ministro Relator Aroldo Cedraz – Acórdão 2.308/2010 – Plenário. (2010). Disponível em: http://portal2.tcu.gov.br/portal/page/portal/TCU/comunidades/governanca_ti/ entendendo_governanca_ti - Acesso em: 4 abr. 2012.
