Engenharia de Software - Edição 70

Rodrigo Oliveira Spínola [email protected] Doutor e Mestre em Engenharia de Software pela COPPE/UFRJ.Realizou seu Pós-Doutorado na University of Maryland Baltimore County e Centro Fraunhofer nos Estados Unidos.Atualmente é Professor Titular do Programa de Pós-Graduação em Sistemas e Computação da Universidade Salvador - UNIFACS.

Marco Antônio Pereira Araújo [email protected] Doutor e Mestre em Engenharia de Sistemas e Computação pela COPPE/UFRJ, Especialista em Métodos Estatísticos Computacionais e Bacharel em Matemática com Habilitação em Informática pela UFJF UFJF..

70 ª Edição Edição - 2014

Corpo Editorial Editor

Eduardo Oliveira Spínola

Rodrigo Oliveira Spínola

[email protected] É Colaborador das revistas Engenharia de Software Software Magazine, Java Magazine e SQL Magazine.É bacharel em Ciência da Computação pela Universidade Salvador (UNIFACS). (UNIFACS).

Colaboradores

Marco Antônio Pereira Araújo Eduardo Oliveira Spínola Nicolli Souza Rios Alves Consultora Técnica

Nicolli Souza Rios Alves

Daniella Costa

[email protected]

Bacharel em Ciência da Computação na Universidade Salvador (UNIFACS),Mestranda em Sistemas e Computação no Programa de Pós-Graduação em Sistemas e Computação da UNIFACS UNIFACS na linha de Engenharia de Software.É editora da Engenharia de Software Magazine.

Jornalista Responsável Responsável

Kaline Dolabella - JP24185 Na Web

http://www.devmedia.com.br/revista-engenharia-de-software-magazine

Atendimento ao Leitor

Fale com o Editor!

A DevMedia conta com um departamento exclusivo para o atendimento ao leitor. Se você tiver algum problema no recebimento do seu exemplar ou precisar de algum esclarecimento sobre assinaturas, exemplares anteriores, endereço de bancas de jornal, entre outros, entre em contato com:

É muito importante para a equipe saber o que você está achando da revista: que tipo de artigo você

www.devmedia.com.br/central (21) 3382-5038

Publicidade

Para informações sobre veiculação de anúncio na revista ou no site entre em contato com: publicidade@de publici dade@devmedia. vmedia.com.br com.br

gostaria de ler, que artigo você mais gostou e qual artigo você menos gostou. Fique a vontade para entrar em contato com os editores e dar a sua sugestão! Se você estiver interessado em publicar um artigo na revista ou no site ES Magazine, entre em contato com os editores, informando o título e mini-resumo do tema que você gostaria de publicar.

Sumário Conteúdo sobre Agilidade, Artigo no estilo Prático

06 – MPS.BR: Melhorando o nível de maturidade do processo com metodologia ágil [ Elaine G. M. de Figueiredo ]

Conteúdo sobre Agilidade, Artigo no estilo Prático

12 – Estudo de caso de uma Modelagem Ágil [ André Vidal ]

Conteúdo sobre Agilidade

23 – Desenvolvimento Ágil: O papel do PMO no mundo Ágil [ Sérgio Salles Galvão Neto ]

Conteúdo sobre Agilidade

33 – O que faz um Gerente de projetos e um Scrum Master? [ Sérgio Salles Galvão Neto ]

Conteúdo sobre Boas Práticas, Conteúdo sobre Arquitetura e Desenvolvimento

42 – Entendendo o Teste de Software por Amostragem [ Célia Negrini ] u

e s ê

F eedb ac k

D

o

s

Artigo no estilo Prático

b

r

e

48 – Como aumentar a produtividade de sua equipe de programadores [ Ivania Ramos dos Santos e Marcos Vinicius De Bortolli ]

Conteúdo sobre Boas Práticas

52 – Como detectar problemas de usabilidade e corrigi-los [ Karin R. Coelho Quandt ]

e

s

t a e d

i ç o ã

Dê seu feedback sobre esta edição! A Engenharia de Software Magazine tem que ser feita ao seu gosto. Para isso, precisamos saber o que você, leitor, acha da revista!

Conteúdo sobre Planejamento e Desenvolvimento, Artigo no estilo Prático

57 – Teste unitário com JUnit e ComplexGraph [ Felippe Moreira Faêda, Vinícius Lucena Bonoto e Marco Antônio Pereira Araújo ]

www.devmedia.com.br/esmag/feedback

Edição 05 - Engenharia de Software Magazine 5

Agilidade Nesta seção você encontra artigos voltados para as práticas e métodos ágeis.

MPS.BR: Melhorando o nível de maturidade do processo com metodologia ágil Um processo de software com práticas ágeis para atingir resultados esperados conforme o MPS.BR Fique por dentro:

O Elaine G. M. de Figueiredo [email protected]

Mestrado em Ciencias da Computanção com enfase em engenharia de software, pós graduação em gerência de projetos, oito anos de atuação na área de desenvolvimento e qualidade de software.Atualmente é gerente de projetos na multinacional espanhola Indra Company, membro colaborador do grupo de pesquisa “ASSERT – Advanced System and Software Engineering Research Technologies Lab” pela universidade federal de Pernambuco. Certificada P1 no programa MPS.BR.

MPS.BR ou Melhoria de Processos do Software Brasileiro é simultaneamente um movimento para a melhoria da qualidade (Programa MPS.BR) e um modelo de qualidade de processo (Modelo MPS), ele é baseado nas normas ISO/IEC 12207 e ISO/IEC 15504 e compatível com o CMMI. O MPS .BR sugere resultados a serem atingidos como requisitos para atender objetivos de qualidade (obtenção de qualidade). Esses resultados podem ser atingidos por meio de tarefas ou conjunto de tarefas que quando mal aplicados torna o processo mais burocrático. Em um sentido contrário tem-se as organizações que necessitam atingir objetivos de qualidade mas não podem adotar práticas burocráticas ou mesmo não ágeis. Para estes casos, é possível por meio de metodologia ágil entregar o que o MPS.BR aguarda como melhoria para os níveis de maturidade de processo de desenvolvimento.

Este artigo exibe um processo de software pautado sobre a metodologia ágil de desenvolvimento e que poderá ser adotado por aqueles que desejam ter seus processos coerentes a alguns objetivos de qualidade segundo o MPS .BR. Deste modo, ele é útil a estudantes, profissionais de desenvolvimento de software e empresas que necessitam utilizar um processo de software ágil, mas que necessitam, ou desejam, atingir requisitos que os programas de qualidade como o MPS.BR defendem.

Alguns conceitos de qualidade do MPS. BR e importantes para o entendimento desse artigo são: 1. Capacidade do processo: Uma caracterização da habilidade do processo atingir os objetivos de negócio atuais ou futuros; 2. Atributo de processo: Uma característica mensurável da capacidade do processo aplicável a qualquer processo]; 3. Nível de maturidade: Grau de melhoria de processo para um predeterminado conjunto de processos no qual todos os

6 Engenharia de Software Magazine - MPS.BR: Melhorando o nível de maturidade do processo com metodologia ágil

AGILIDADE

resultados esperados do processo e dos atributos dos processos são atendidos. A qualidade pode ser agregada a qualquer processo de software uma vez que o mesmo tenha práticas e procedimentos homologados e conceituados pela engenharia de software. Para este artigo será defendida a filosofia ágil de desenvolvimento de software como opção para o desenvolvimento de sistemas. A essência desta filosofia é a definição de desenvolvimento de software galgado na agilidade, na flexibilidade, nas ha bilidades de comunicação e na capacidade de oferecer novos produtos e serviços de valor ao mercado, em curtos períodos de tempo e a baixo valor de custo.

Descrição do Processo O processo escolhido é baseado nas principais técnicas da metodologia XP e do Scrum, enquanto a primeira é mais focada em práticas operacionais de codificação, teste e integração, a segunda é focada no gerenciamento do projeto. As práticas XP a serem utilizadas são: • Codificação em par: dois programadores utilizando o mesmo computador escrevem o código e vistoriam o mesmo; • Testes automatizados: escrita de ‘script’ ou códigos de testes para verificarem os códigos escritos para o programa e detectarem erros de forma automatizada, precisando para isso rodar rotinas de testes no próprio sistema; • Integração contínua: os programadores devem integrar os novos códigos ao software tão rapidamente e com a maior frequência possível; • Design simplificado: os programadores são estimulados a desenvolver o código do software o mais simples possível; • Reegenharia de Software: o código deve ser constantemente melhorado, sem que a funcionalidade seja alterada pela equipe do projeto o tempo todo. As práticas Scrum que serão adotadas são basicamente o fluxo de processo, ou seja, as fases e etapas cumpridas para a concepção do software devem ser as mesmas da metodologia Scrum. Tal metodologia é explicitada abaixo com o fluxo de processo a ser utilizado, assim como perfis, papéis e ar tefatos entregues.

Perfis e Papéis Os perfis de desenvolvimento necessários para execuç ão do processo são: • Scrum Master: gerencia a metodologia do Scrum, ensinando as práticas do Scrum a todos os envolvidos no projeto e implementando o Scrum de modo que esteja adequado à cultura da organização. Para tal, deve garantir que todos sigam as regras e práticas do Scrum. É responsável por remover os impedimentos do projeto, perceber e resolver problemas pessoais ou conflitos entre os integrantes da equipe de desenvolvimento . • Product Owner: é o proprietário do produto e deve representar os interesses do cliente. Deve ser a interface entre o cliente e o time de desenvolvedores, ou seja, estar sempre em contato

com o cliente e saber exatamente o que se espera do projeto, no contexto do atendimento das necessidades de negócio do cliente. Para tal, deve ter conhecimento a respeito do negócio e das práticas do Scrum. Pode ser um financiador, o próprio cliente, um experiente usuário final ou um importante interessado da equipe. • Equipe Scrum: um grupo de pessoas com diferentes ha bilidades necessárias (gerencial, técnico e operacional) para transformar requisitos em um incremento potencialmente entregável.

Artefatos e procedimentos a serem entregues Os procedimentos e os artefatos que compõem este processo devem se preocupar em cumprir algumas metas de qualidade do MPS.BR. Seguem abaixo os produtos que devem ser entregues para as demandas de desenvolvimento, seguindo os resultados propostos no MPS.BR: • Documentos de Visão: para a definição de escopo das necessidades, características e funções especificadas para o produto que será desenvolvido determinando o que fará parte ou não do projeto. Artefato ligado ao resultado esperado “GPR1 - O escopo do trabalho para o projeto é definido” do modelo MPS BR; • Contagem de Pontos por Função: fornecendo uma referência para a atribuição de tamanho e esforço. Esta prática está relacionada ao resultado esperado “GPR2 – As tarefas e os produtos de trabalho do projeto são dimensionados utilizando métodos apropriados do MPS BR; • Cronogramas/planilhas de atividades, ou quadro de tarefas. Vinculado ao “GPR5 - O orçamento e o cronograma do projeto, incluindo a definição de marcos e pontos de controle, são estabelecidos e mantidos do modelo MPS BR; • Product Backlog: possui uma lista de todas as funcionali dades desejadas no produto, descritas em forma de user stories (estórias do usuário). Cada estória do Product Backlog deve ter um valor de negócio atribuído pelo Product Owner. Produto obtido por meio de tarefa relacionada a requisitos de software; a gerência de requisitos é exigência do MPS.BR; • Documento de Arquitetura: este documento deve apresentar a estrutura fundamental do software, descrever as estruturas recorrentes da comunicação entre componentes e apresentar uma solução para um problema de projeto em um determinado contexto; • Ata da Reunião de Planejamento: deve registrar os assuntos tratados durante a reunião, a relação dos participantes bem como a assinatura destes e as decisões a serem tomadas, caso necessário. Isto provê a gestão de comunicação. As atas devem ainda registrar mudanças desejadas para posterior analise; ou seja, realização da gestão de mudança de requisitos realizada por meio de análise de impacto, principalmente dos códigos já escritos. Atividade e artefato baseado no “GRE5 - Mudanças nos requisitos são gerenciadas ao longo do projeto” do MPS BR; • Ata da Reunião de Revisão da Sprint: contém a pauta da reunião, a relação dos participantes, bem como a assinatura destes, a avaliação da execução das tarefas, registro de bug, Edição 70 - Engenharia de Software Magazine

7

mudanças e possíveis novas estórias encontradas durante a apresentação do release; trata-se de mais um artefatos originado por uma atividade voltada à análise de impacto; i mpacto; • Versões de software, seguindo gerência de configuração, com possíveis registros através da utilização da ferramenta SVN, relacionada a um dos resultados esperados do nível F do MPS BR “GCO1 “GCO1 - Um Sistema de Gerência de Configuração é estabelecido e mantido”. mantido”. Isto se faz relevante principalmente pri ncipalmente em um ambiente ágil ági l de desenvolvimento de software com a utilização da prática de integração contínua. contínua . Apresentam-se também seis procedimentos, que guiam a execução adequada das atividades do processo proposto: 1. Definição das Estórias: guiar o Product Product Owner na descrição das estórias, definição def inição de valor de negócio e conceito de pronto para cada das estórias; 2. Desenvolvimento das Estórias: apoiar o Scrum Master no cálculo da velocidade da Equipe, a própria Equipe na seleção e manipulação das estórias a serem desenvolvidas durante a Sprint e na divisão destas estórias em tarefas executáveis; 3. Estimativa por Ponto de Estória: medida do tempo em dias que um desenvolvedor desenvolvedor pode levar para entregar u ma estória. Este valor é considerado para métricas e monitoramento da velocidade e produtividade do projeto; 4. Criação/Atualização do Quadro de Trabalho: descreve como criar e atualizar o Quadro de Trabalho que permite o acompanhamento do desenvolvimento de uma estória do Product Backlog, Backlog , onde cada etapa do desenvolvimento de uma tarefa poderá ser rapidamente identificada pela equipe. Para tal, possui colunas especificando os estados das tarefas, as próprias tarefas descritas descr itas em post-its, dentre outros atributos. A adoção de uma ferramenta para a criação e manutenção ma nutenção do quadro poderá ser adotada; 5. Reuniões: descrevem como conduzir as cerimônias do Scrum, que são reuniões, formais ou não, que acontecem em momentos distintos do Processo; 6. Dados Históricos: descreve como as lições aprendidas durante a execução do projeto deverão ser coletadas e armazenadas para que o resultado desta coleta sirva de base de conhecimento para a equipe utilizar em projetos futuros.

no produto entregue para verificar se tudo realmente foi implementado. Ao final da Sprint, deve-se realizar uma Reunião Reun ião de Revisão (Sprint Review), onde a equipe demonstra o produto gerado ao Product Owner e este valida se o objetivo foi atingido. Logo em seguida, realiza-se a Reunião Reun ião de Retrospectiva (Sprint (Sprint Retrospective),), uma reunião trospective reu nião de lições aprendidas, com o objetivo objet ivo de melhorar o processo, ou a equipe (time) e/ou produto para a próxima Sprint. As práticas do Scrum são implementadas através de três papéis principais: o Product Owner que define as funcionalidades do produto (Product Backlog) através de User Stories (requisitos); o ScrumMaster que representa a gerência para o projeto, sendo o responsável pela aplicação dos valores e práticas do Scrum; e a equipe (team) que define as tarefas que irão compor o Sprint Backlog e desenvol desenvolve ve as funcionalidades f uncionalidades do produto.

Fluxo Geral de Desenvolvimento de Sistemas A partir de uma perspectiva de gerenciamento baseado no ciclo de desenvolvimento iterativo iterativo incremental para pa ra o Scrum, Scru m, e conforme recomendações e boas práticas de gerência ágil de projetos de software provenientes de organizações nacionais que fazem uso nos seus processos process os de metodologias metodologias ágeis, chegou-se a um processo composto por três fases: Planejamento ou Pré-Game, Desenvolvimento ou Game, e Finalização ou Pós-Game que são apoiadas por atividades de Monitoramento Monitoramento e Controle conforme a Figura 1.

Fluxos de Processo O ciclo ou fluxo do processo tem o seu progresso baseado em uma série de iterações bem definidas, cada uma com duração de duas a quatro semanas, chamadas Sprints. Antes de cada Sprint, realiza-se uma Reunião de Planejamento (Sprint Planning Meeting) onde o time (equipe) de desenvolvedores tem contato com o cliente (Product Owner) para priorizar o trabalho que precisa ser feito, selecionar e estimar as tarefas que o time pode realizar dentro da Sprint. A próxima fase é a Execução da Sprint onde o time controla o andamento do desenvolvimento realizando Reuniões Diárias (Daily Meeting), não mais que q ue 15 minutos de duração, e observando o seu progresso usando um gráfico chamado Sprint Burndown. Ao final de cada Sprint, é feita uma revisão

Figura 1. Fluxo Geral para Desenvolvimento de Sistemas


AGILIDADE

A seguir, este processo é apresentado através da descrição de suas fases, atividades e responsáveis por executá-las. Também serão descritos os procedimentos a serem seg uidos, que descrevem e exemplificam práticas ágeis i ncorporadas no processo, além dos artefatos a serem gerados na execução das atividades de cada fase.

Detalhamento das Fases A Figura 2 apresenta o fluxo da Fase de Planejamento ou também chamada de Pré-Game que tem como objetivo delimitar o escopo do projeto, planejar o tempo e custo e eliminar os possíveis riscos a partir da definição de uma arquitetura estável.

requisitos, estórias e demais coisas que o cliente desejar, que deve ser descrito utilizando a terminologia do cliente. A fase seguinte é a divisão do Backlog em Sprints, onde as estórias com maior valor para o cliente são selecionadas e divididas nas interações (Sprints). Neste momento deve ser aplicado o valor da estória e o tempo de desenvolvimento em dias para cada uma. Por fim, a equipe deve ser selecionada. selecionad a. O ideal é que a mesma não seja maior do que 8 pessoas e menor do que 4. Um projeto de arquitetura é elaborado por meio de um template padrão de definição arquitetural, com a elaboração dos diagramas necessários. A equipe deve discutir e apresentar a estrutura fundamental do software, descrever as estruturas estrutura s recorrentes da comunicação entre componentes e apresentar uma solução para um problema de projeto em um determinado contexto. É no projeto de arquitetura de software soft ware que os requisitos não funcionais são primeiramente considerados. A divisão das Sprints, da equipe, e a definição da arquitetura podem ser feitas simultaneamente, simulta neamente, onde cada papel desempenha uma função, f unção, interagindo um com o outro, agregando assim agilidade. Opcionalmente, a arquitetura pode ser feita para os produtos resultantes de uma Sprint, e não para o produto resultante do processo como um todo (Product Backlog). A estimativa de ponto por função fu nção é obtida por meio do documento de visão e de arquitetura. arquitetu ra. A estimativa será apresentada juntamente ao Backlog e as Sprints Sprints para todos os envo envolvid lvidos os na

Figura 2. Fluxo geral para a fase de modelagem ou pré game

A fase é iniciada quando qu ando o setor responsável pelo desenvolvimento de software recebe rec ebe uma demanda de desenvolvimento. desenvolvimento. Para isso, uma ordem de serviço é criada. A partir da ordem de serviço, o solicitante do serviço ser viço (cliente) (cliente) deve identificar o seu representante (Product Owner). Este Product Owner será responsável por definir as funcionalidades f uncionalidades do produto e aceitar ou rejeitar os resultados das Sprints. O Product Owner deve possuir o conhecimento a respeito do negócio e a respeito do Scrum. O Product Owner deve descrever um estado desejado do produto no futuro. A visão do produto deve possuir as características do produto com uma visão voltada ao negócio, algumas premissas prem issas do projeto, se necessário, a fim de garantir garanti r um entendimento comum das partes envolvidas e as restrições ou limitações aplicáveis que afetará o desempenho do projeto. O Product Owner deve definir as funcionalidades f uncionalidades desejadas para o produto e priorizar as mesmas de acordo com seu valor de negócio. O Product Backlog é basicamente uma lista de Edição 70 - Engenharia de Software Magazine

9

reunião de planejamento (a reunião visa apresentar o projeto e obter aceite sobre o mesmo), mesmo), concluindo-se assim esta fase. A fase de desenvolvimento ou Game será exibida ex ibida na Figura 3. Nesta fase, uma parte pa rte do produto é desenvolvida com base nos objetivos do Product Owner, na arquitetura definida e com ênfase no gerenciamento dos recursos disponíveis e no valor de negócio das estórias. O início da fase de desenvolvimento sempre deve ser precedida pela fase de modelagem e planejamento, explicitada anteriormente. O início do desenvolvimento se dá por meio da análise dos dados históricos de projetos semelhantes e as lições aprendidas em Sprints anteriores. Estes dados serv irão como base de conhecimento para auxiliar nas estimativas de esforço, estimativas de custo do projeto, e também para o conhecimento da situação e práticas a serem evitadas ou não; trata-se da primeira pri meira subfase do desenvolvimento.

Figura 3. Fluxo geral para a fase de desenvolvimento ou game

As tarefas devem ser devidamente divididas entre os integrantes da equipe e atribuídas a cada um deles para que tais profissionais entendam o seu papel e possam juntamente ao ScrumMaster atualizar suas tarefas no quadro. Deve-se criar e fixar um quadro de tarefas na parede, referente a Sprint, para anexar as estórias e suas tarefas através de post-its, inserir informações sobre itens não planejados e acompanhar os objetivos da Sprint através do gráfico Burndown. Uma ferramenta pode ser adotada para a inserção do quadro de tarefas dentre as atividades, pois existem várias ferramentas no mercado que são quadro informatizados, que possuem todas as funcionalidades de tal. Após os aceites dos interessados, a divisão e entendimento das tarefas e estórias; a equipe poderá iniciar o desenvolvimento que se baseia na codificação, testes automatizados e integração contínua de código no SVN. Neste contexto, os testes também podem incluir a confecção confecç ão de artefatos, como plano de teste, roteiro e casos de testes. No contexto dos testes, a opção por adotar testes manuais e a elaboração de documentações, o que é contrário às práticas ágeis, surge da necessidade que a organização ou equipe pode vir a ter da referida documentação docu mentação como registro, ou mesmo no caso de ter profissionais de teste especializados e dedicados a somente uma demanda de desenvolvimento; o que ofertaria a possibilidade da escrita de código de teste, automatizando os mesmos, e da escrita da documentação ou testes manuais para alguns tipos de testes. O Scrum Master deve realizar uma reunião diariamente com todos os membros da equipe com o objetivo objet ivo de sincronizar o progresso do trabalho e levantar impedimentos que devem ser removidos. r emovidos. A equipe deve continuar a codificar, testar e entregar código enquanto houverem estórias, deve juntamente ao Scrum Master verificar o surgimento de tarefas não planejadas, atualizar o Quadro de Trabalho, gráfico Sprint Burndown Burndown e atualizar atual izar a lista de impedimentos, impedimentos que devem ser retirados sempre pelo ScrumMaster. Três etapas devem ter atenção neste fluxo, as etapas de atualização de Sprint e Product Backlog que podem ser feitas sobre o quadro de tarefas ou no próprio artefato de Product Backlog. Estas são importantes para


AGILIDADE

atualização do que foi feito, do registro dos problemas, ou ainda das estórias não planejadas que surgiram. Tais ações são relevantes para o próprio registro e gestão de conhecimento dentro do projeto e equipe. Outra importante tarefa é o Monitoramento e Controle que o Scrum Master deve fazer ao longo do processo, sempre visualizando impedimento, ou sugerindo melhorias, registrando ocorrências e lições aprendidas. Sempre que uma Sprint for finalizada, a fase exposta na Figura 4 deve ser iniciada. Esta é a fase de finalização ou pós-game.

Tudo o que afeta a forma como a equipe desenvolve o software deve ser aberto para debate, como processos e prática s, ambiente e comunicação, e ferramentas artefatos. Por fim, os dados são atualizados e uma nova Sprint deve ser planejada, iniciando assim novamente o ciclo de desenvolvimento. É possível observar que este processo agrega as práticas ágeis à algumas práticas e procedimentos de metodologias tradicionais. Isto se deve à necessidade de obedecer alguns objetivos de qualidade que são sustentados pelos programas; os mesmos só podem ser obtidos por meio de práticas não ágeis, ou ainda por meio da adaptação destas. Por exemplo: para prover a rastreabilidade dos requisitos (resultado esperado do processo gerência de requisitos do MPS.BR) e assim prever impactos no desenvolvimento devido a uma solicitação de mudança, será inserida uma coluna a mais no documento de Product Backlog, de modo que serão traçados relacionamentos entre as estórias em que será possível notar qual estória poderá ser alterada ou impactada de alguma forma por outra. A ideia de fazer um processo ágil considera práticas de metodologias diferentes, ou seja, práticas ágeis com tradicionais não pode ser considerada errônea ou indesejada, pelo contrário, um processo escrito dessa forma possibilita a obtenção dos benefícios que ambas as metodologias podem trazer.

Links: Figura 4. Fluxo geral para a fase de finalização ou pós-game

A fase de finalização é concebida por meio de uma reunião com todos os envolvidos no projeto, onde o Product Owner oferta seu parecer sobre o produto desenvolvido, se o mesmo atende as necessidades de negócio. Se não ocorrer aprovação, o desenvolvimento é iniciado novamente sobre uma Sprint de correção que deve ser paralela à nova Sprint de desenvolvimento. Caso haja aprovação, o Product é revisado e atualizado. Ocorre então a reunião de retrospectiva que vai apoiar o Scrum Master a discutir os acontecimentos e compreender os fatos e sentimentos durante a iteração (Sprint). Ela pode ser realizada utilizando os seguintes questionamentos: • O que fizemos bem? • O que podia ter sido feito melhor? • O que pode ser melhorado?

Agile Alliance. What Is Agile Software Development? http://www.agilealliance.org/intro

Softex – Sociedade para Promoção da Excelência do Software Brasileiro (2012) “MPS.BR – Melhoria de Processo do Software Brasileiro”, Guia Geral, versão 1.2 http://www.softex.br/wp-content/uploads/2013/07/MPS.BR_Guia_Geral_ Software_2012.pdf

Você gostou deste artigo? Dê seu voto em www.devmedia.com.br/esmag/feedback Ajude-nos a manter a qualidade da revista!

Edição 70 - Engenharia de Software Magazine

11

Agilidade Nesta seção você encontra artigos voltados para as práticas e métodos ágeis.

Estudo de caso de uma Modelagem Ágil Um estudo de caso para auxiliar times de desenvolvimento na implantação Fique por dentro:

princípios e valores que podem ser aplicados por profissionais de software no dia a dia. A MA não é um processo prescritivo, pois ela não define procedimentos detalhados de como criar um dado tipo de modelo. Ao invés disso, ela provê conselhos de como ser efetivo como modelador. A MA deve ser vista como uma arte, não como uma ciência ”.

Nesse artigo veremos algumas boas práticas e técnicas empregadas na Modelagem Ágil (MA), largamente utilizada por equipes de desenvolvimento de software baseadas em AGILE, por meio de exemplos práticos. Os benefícios produzidos pela MA vão muito além do que apenas documentar os modelos de análise, mas sim, torna essas tarefas algo de interesse público do time, criando um protocolo de comunicação entre os membros da equipe. Os modelos produzidos durante a iteração da MA são vistos como um bem coletivo da equipe e deve estar aliada ao uso de uma linguagem comum entre os membros dos times, sempre amparada por um processo flexível, bem definido. Para exemplificar o uso da MA utilizaremos diagramas da UML (Unified Modeling Language) e o processo de referência adotado tem por base o UP (Unified Process). Ao longo desse artigo faremos a demonstração de um case, onde os modelos apresentados poderão auxiliá-lo quanto ao entendimento de como essa poderosa ferramenta ágil simplifica os trabalhos de análise e comunicação de sua equipe.

A aplicação das práticas da MA devem auxiliar as equipes equalizarem o conhecimento sobre o projeto do software, definindo “como” será feito o desenvolvimento durante uma iteração.

Portanto, é uma exigência que os mem bros de uma equipe que pratiquem a MA conheçam pelo menos uma técnica

I

nicialmente proposta por Scott Ambler em 2004, a Modelagem Ágil (MA) surgiu como a técnica mais indicada para as práticas de análise e comunicação de equipes que utilizam XP (Extreme Programming) e o Unified Process (UP) como metodologias de referência para o desenvolvimento. Considerada muito mais prática voltada à modelagem sistemas de software, do que uma metodologia formal, Ambler estabelece que a MA deve ser vista como “uma coleção de práticas, guiadas por André Vidal [email protected]

Graduado em Ciência da Computação pela UNESP de Rio Claro, com MBA em Gestão de Projetos pela FGV. Atua nas áreas de gestão e serviços voltados à engenharia de software, com destaque à gestão de projetos ágeis, modelagem de processo e análise de negócios há quinze anos. Nesses anos teve experiência na formação de equipes de desenvolvimento e sustentação, executando a pré-venda de pro jetos, atuando no planejamento, controle e implantação de metodologias de desenvolvimento e serviços com base em processos baseados no Cobit, ITIL, PMI e Scrum.

12 Engenharia de Software Magazine - Estudo de caso de uma Modelagem Ágil

AGILIDADE

de análise, para que tenham um protocolo único de comunicação entre seus membros. Nesse artigo trabalharemos com os modelos utilizados pela Análise Orientada a Objetos e os artefatos utilizarão como base os diagramas da UML ( Unified Modeling Language).

Processo Unificado (UP) O Processo Unificado (UP) foi concebido originalmente para ser uma metodologia voltada à gestão de projetos de desenvolvimento de software. Ele é um guia composto por um conjunto de disciplinas, as quais definem tarefas e atribuições úteis para nortear as atividades que resultarão na geração do software. O processo inicia mediante as necessidades do negócio de clientes e seus usuários. A partir delas é possível que sejam estabelecidos prazos, custos e critérios de qualidade aceitáveis para o software ser entregue. O Processo Unificado define que o planejamento deve ser iterativo e incremental. Dessa forma, a arquitetura do software deve ser baseada em componentes, tornando possível fazer um mapeamento eficiente de requisitos e promovendo uma melhor organização da especificação resultante da análise. A fase de análise deve definir como o sistema funcionará internamente e de qual maneira os requisitos do cliente serão atendidos. Alguns aspectos devem ser considerados nessa fase de projeto do sistema, como: arquitetura do sistema, linguagem de programação utilizada, Banco de Dados (SGBD), padrão de interface gráfica, aplicação de frameworks, entre outros. A Modelagem Ágil (MA) ocorre durante a fase de análise, quando é feita a documentação computacional do projeto do software. Nessa fase é estabelecido como o software será construído e precisa estar coerente com a descrição realizada pelos artefatos produzidos pela definição dos requisitos. Durante a etapa de análise, duas atividades básicas devem ser cumpridas: • Projeto da arquitetura (ou projeto de alto nível): O projeto da arquitetura normalmente é realizado por um arquiteto de software, visando distribuir as classes de objetos relacionados do sistema em outros subsistemas em formato de componentes, distribuindo-os pelos recursos de hardware disponíveis para a aplicação; • Projeto detalhado (ou projeto de baixo nível): Na fase de pro jeto detalhado são modeladas as relações de cada módulo com os objetivos do negócio, realizando o projeto de interface com o usuário, o banco de dados e as demais integrações sistêmicas.

Extreme Programming (XP) O desenvolvimento com Extreme Programming (XP) foi criado no início dos anos 80 por Kent Beck e Ward Cun ningham, baseado em experiências no desenvolvimento de sistemas em Smalltalk. O trabalho de ambos definiu uma nova maneira de desenvolver software, passando a utilizar conceitos que até então nunca haviam sido explorados por grande parte das equipes. O modelo XP clássico abordava a aplicação de técnicas relacionadas à modelagem de domínios de sistemas, incluindo

a padronização do código fonte, o uso de design patterns e a declaração das necessidades dos clientes em forma de car tões CRC (Class Responsibility Card). Tais diretivas simplificavam de forma significativa a documentação do processo de desenvolvimento de software. Já em meados dos anos 90 e, envolvido diretamente com a doutrina do Movimento Ágil, Kent Beck estabelece as di retrizes daquilo que conhecemos hoje do modelo XP. Uma metodologia preparada para evidenciar de maneira formal e organizada os valores ágeis, postulando conceitos de transparência, responsabilidade, foco na prestação de contas ao cliente e efetuando entregas de software funcional ao final de cada iteração, tal como prega o Processo Unificado. Em 2002, Scott Ambler incorpora ao modelo XP os pri ncípios da Modelagem Ágil, definindo que durante o ciclo de vida da iteração (semanal), as equipes de desenvolvimento devem se preocupar em gerar modelos que auxiliem a implantação do software e não com a documentação de projeto. Ou seja, no dia a dia do desenvolvimento, é mais importante informar a todos o que deve ser feito, do que documentar algo que p ode mudar rapidamente. Dessa maneira, sendo o XP uma adaptação do Processo Unificado, foi criada uma orientação para tratar novas construções, voltada à melhoria contínua da implementação de controles e na definição arquitetura de sistemas. O método designa que problemas de projeto originados por necessidades de arquitetura ou pela troca de tecnologia devem ser tratados como “Spikes”. Dessa maneira, sessões de Modelagem Ágil são utilizadas tanto na resolução do Spike no projeto de alto nível, como também no projeto detalhado, promovendo agilidade ao ciclo de desenvolvimento.

Comunicação A comunicação interna da equipe numa iteração com Modelagem Ágil é tão ou mais importante que a externa, feita junto ao cliente. A interação entre os membros da equipe deve ter por objetivo gerar conhecimento e engajamento, auxiliando na formação de um domínio de conhecimento comum ao time. Dentre as técnicas utilizadas por times MA que promovem melhorias na comunicação, podemos citar a análise colaborativa, a proximidade na distribuição geográfica da equipe no ambiente de trabalho, o uso de sessões de brainstorming e as reuniões diárias. A forma como a equipe está distribuída no ambiente de tra balho recebe atenção e, realmente, pode fazer a diferença no desempenho do time durante o projeto. Na Figura 1 podemos ver um esboço do ambiente propício à prática da comunicação osmótica, desejável para equipes de desenvolvimento XP. A proposta da comunicação osmótica foi inicialmente esta belecida pela metodologia Crystal Clear, definida por Alistair Cockburn, tornando o formato das salas de desenvolvimento bastante conveniente às equipes que atuam com XP e demais metodologias ágeis. A disposição do layout de ambientes MA deve forçar a comunicação entre as pessoas durante os trabalhos de Edição 70 - Engenharia de Software Magazine

13

desenvolvimento. Dessa forma, as características do local devem ser formatadas para proporcionar melhorias à comunicação do time, favorecendo as práticas ágeis. Ambientes formulados para promover esse tipo de interação devem prover: • Área comum: local onde o time se reúne para o trabalho diário, de forma coletiva para trocar informações relevantes e experiências do projeto. Este local deve ser centralizado, desprovido de barreiras de comunicação (por exemplo, baias altas). A utilização de perturbadores do foco de trabalho é restrita nessa área, tal como celulares, tablets e aparelhos do gênero que dispersam a atenção do time; • Cavernas (caves): local onde as pessoas podem desenvolver o trabalho de maneira focada e concentrada, fora da área comum. Este local está montado numa das laterais da sala, e permite a execução de atividades que não façam parte do trabalho; • Paredes: as paredes devem ser utilizadas para o desenho e desenvolvimento de modelos. Precisam estar preparadas para esse tipo de interação, com lousas, dashboards e quad ros que facilitem e sejam difusores de informação para todos aqueles que atuam junto ao time de desenvolvimento. É de suma importância esse item para equipes que desejam praticar a Modelagem Ágil.

Figura 1. Modelo de layout de estúdio de software

Modelagem Ágil (MA) Por definição, a Modelagem Ágil (MA) é uma forma colaborativa de se analisar e desenvolver software, sendo vista muito mais como uma prática comum entre os integrantes do time, do que um processo altamente definido. Tecnicamente, o foco da MA está centrado na geração de um entendimento único para a equipe. A orientação é que o desenvolvimento de novos modelos seja feito de forma evolutiva, adotando a simplicidade como premissa básica e tendo sua progressão feita de forma incremental, semelhante

ao que é propagado tanto pelo Processo Unificado, quanto pelo XP. O uso da MA deve estar voltada à definição de um conjunto de artefatos voltados à formação do conhecimento comum à equipe com relação ao projeto de software, permitindo ao t ime criar um padrão simplificado de comunicação.

Como utilizar a modelagem ágil? A utilização da MA por times de desenvolvimento prevê a aceitação de novos modelos de forma pragmática, pois a inclusão de artefatos deve ocorrer desde que esses auxiliem o entendimento da equipe e facilite o trabalho como um todo, pois o produto final é mais importante que a representação do mesmo. Portanto, a criação de novos modelos depende que os mesmos sejam convencionados pela própria equipe, pois serão adotados por todos como um protocolo de comunicação, uma vez que não há uma preocupação explícita com a documentação.

Princípios Os princípios gerais da Modelagem Ágil (MA) defendem que o modelo de trabalho das equipes deve evitar a “perda de tempo”. Esse conceito vem dos processos baseados nas práticas do Lean Software Development, onde eliminar o desperdício, amplificar a aprendizagem do time, entregar o mais rápido possível e capacitar a equipe para a construção de integridade ao produto são vistos como as formas mais eficazes de exercitar a modelagem ágil com um time. A Modelagem Ágil aplicada a esse contexto deve: • Atender a um propósito: Quando existe uma necessidade que deve ser atendida, presume-se que algo de útil está sendo construído. O objetivo final da modelagem é fazer com que o código funcione ao final dos trabalhos, mesmo que para isso modelos exigidos pela metodologia não sejam produzidos, uma vez que o time chegue à conclusão que o propósito final, entregar o código funcionando, não seja atingido; • Ser preciso: A precisão está diretamente ligada à eficiência do modelo produzido. Um modelo preciso auxilia de forma significativa o entendimento da equipe para com as necessidades do projeto, logo sua utilidade é g rande; • Ser consistente: A consistência dos modelos deve sempre ser averiguada por meio dos testes aplicados pela equipe durante o desenvolvimento. Eventualmente correções devem ser aplicadas ao modelo, para que o mesmo se mantenha consistente durante os trabalhos do projeto; • Agregar valor ao produto: A relação custo/benefício da utilização do modelo deve atender às necessidades de comunicação da equipe, não sendo um trabalho descartável. Logo, agrega valor ao produto modelos cujo ciclo de vida perdura por grande parte do projeto; • Ser simples: A simplicidade é vista como a grande marca da Modelagem Ágil, pois acaba induzindo as equipes trabalharem com modelos de fácil entendimento. Para esse propósito, muitas vezes, as equipes devem seguir o acrônimo KISS (Keep It Simple, Stupid ), para que os modelos produzidos não


AGILIDADE

se percam quanto aos objetivos gerais da MA que estabelece a simplicidade como uma necessidade do trabalho.

Ciclo de Vida A criação de novos modelos em MA segue aquilo que metodologia preconiza: modelos intermediários e temporários devem ter foco na comunicação entre os membros do time, antes que sejam promovidos a permanente. Para Scott Ambler, “o uso de documentação não relacionada ao desenvolvimento de software é um dos principais causadores de atraso e desperdício de tempo nas entregas dos projetos”. Por tal motivo criou-se uma “falsa concepção” que em processos ágeis não há documentação. A documentação é feita assim que os modelos intermediários utilizados sejam homologados e promovidos à produção. Dessa maneira, dizer que não há documentação é um grande equívoco! Em XP, por exemplo, propõe-se uma inversão nas fases do desenvolvimento de software tradicional, executando as atividades de análise e testes à frente da codif icação e do design. Assim, o ciclo de vida dos artefatos criados para comunicação da equipe tende a ser mais curtos, relegando aos artefatos de arquitetura e modelos relacionais aquilo que realmente necessita ser documentado num projeto. Para isso, os critérios utilizados na criação de novos modelos durante a iteração MA seguem o workflow apresentado na Figura 2. É importante salientar que todo projeto MA prega que uma equipe deve produzir software potencialmente pronto para funcionar em produção com periodicidade curta. Dessa maneira, em MA a documentação deve ser produzida após a implantação das funcionalidades em produção. Isso justifica que um artefato, desde sua concepção até sua transformação em um modelo permanente, muitas vezes seja trabalhado de forma temporária. A garantia que código esteja pronto para ser utilizado em produção ao final de uma iteração não implica que sua documentação também seja gerada durante a mesma iteração. Dessa maneira, é comum estipular que a documentação seja produzida após a implantação das funcionalidades em produção.

Modelagem ágil na prática A Modelagem Ágil tem seus valores enraizados com a aplicação direta de seus princípios na prática. Dessa forma, a MA para ser melhor compreendida e assimilada por todos numa equipe de desenvolvimento de software, além da referência teórica em modelagem orientada a objetos, a equipe precisa por a MA em prática. Ao adotar a MA em projetos baseados no Processo Unificado (UP) e Extreme Programming (XP), os princípios da técnica tendem a ser explorados em sua plenitude. Na prática, é f undamental que a liderança técnica da equipe tenha em mente que o processo será melhorado gradativamente e, sendo esse um processo iterativo e incremental desde seu início, a tendência é que as práticas utilizadas nas primeiras iterações sejam refinadas e melhoradas a cada entrega. O resultado esperado ao final do projeto é que o processo utilizado pela equipe já esteja bem maduro e mais ajustado às necessidades do time; quando comparado com o que fora proposto inicialmente. Ou seja, existe a necessidade explícita que o processo seja rodado muitas vezes, e é prem issa básica que os timeboxes sejam definidos e respeitados pelo time. Vale frisar que somente se o processo for executado até o fim, é que se pode identificar os problemas e melhorar algo em tempo de projeto. Outro ponto importante para o ajuste do processo durante o curso do projeto diz respeito às reuniões diárias. Muito difundidas por outros métodos como o Scrum e XP, as reuniões diárias são o momento em que o time se reúne para discutir sobre aquilo que vem ocorrendo durante o projeto, entendendo os problemas e definindo como eles podem ser resolvidos durante a própria iteração. Durante as discussões diárias, possíveis soluções para os problemas apresentados são definidos pela equipe e a modelar para comunicar tem papel importante nesse contexto.

Estudo de Caso Nesse artigo, para fins didáticos, iremos apresentar os principais conceitos da Modelagem Ágil por meio da sua

Figura 2. Ciclo de Vida Modelagem Ágil (MA)


15

aplicação a um caso típico de desenvolvimento de sistema. A Figura 3 apresenta as principais características da MA que serão tratadas durante a aplicação do caso de estudo WebBank. Mostraremos a partir de exemplos, como a MA pode ser aplicada por times de desenvolvimento, sugerindo a produção de diagramas que ajudarão a assimilar os conceitos aqui tratados, sem que o leitor precise ter conhecimento de uma linguagem de programação específica.

Visão do produto O WebBank é um banco líder em seu segmento de mercado e deseja disponibilizar uma nova tecnologia para acesso a serviços bancários de conta corrente, atendendo assim uma das principais solicitações de seus clientes; obtidas na última pesquisa de satisfação feita pelo banco. O WebBank irá oferecer os principais serviços utilizados por seus clientes também por meio de aplicativo para dispositivos móveis. O App será disponibilizado para download em dois formatos, um para o sistema operacional iOS e outro para Android. De acordo com o estudo feito pelo banco, os serviços mais acessados pelos seus clientes em seu site na web farão parte da primeira versão do software. Dessa maneira, o aplicativo deverá oferecer apenas os serviços básicos de conta corrente. Pelo aplicativo será possível que o cliente obtenha o saldo e extrato de sua conta, além dos serviços de pagamento de contas e compra de recarga para celular. Cada movimentação na conta corrente feita pelo cliente via aplicativo, será tarifada de acordo com a tabela de preços vigente do banco. O App deve ser simples e interativo. Na tela inicial, o cliente poderá inserir o número da conta. Caso a conta seja válida, terá a permissão para efetuar seu login. Logo que for identificado, será apresentada ao cliente a tela principal do aplicativo, onde será apresentado o saldo atual da conta e os serviços que poderão ser utilizados. Algumas informações relacionadas ao projeto são: • Stakeholders: Cliente WebBank, Gerente de Produto WebBank; • Premissas: O App será disponibilizado no formato para iOS e outro para Android; • Restrições: Toda solicitação feita pelo cliente via aplicativo deverá ser autenticada pelo sistema de Segurança WebBank.

Características da Modelagem Ágil A Modelagem Ágil (MA) tem por característica incentivar as equipes de projeto criar modelos de análise simplificados, os quais permitam um entendimento unívoco para todos do time de “como” os requisitos definidos pelo cliente serão desenvolvidos durante a jornada de trabalho. Na prática, a execução do processo de análise é feita de forma coletiva, trazendo um entendimento comum e fazendo com que todos do time saibam realmente o que deverá ser feito durante a iteração. Atualmente, grande parte das metodologias e processos de desenvolvimento de software adotados pelo mercado utiliza o Processo Unificado (UP) como modelo de referência e, é sa bido que nem sempre todos os artefatos de análise propostos pelo UP são necessários durante a execução de um projeto. Muitos dos problemas relacionados à documentação de projeto devem-se principalmente ao fato de se confundir que com a UML (Unified Modeling Language) ou qualquer outra linguagem de modelagem, devemos documentar um projeto de desenvolvimento de software. Na verdade, a UML pode sim ser utilizada para a documentação, porém a mesma se mostra mais eficiente quando aplicada à comunicação. Dessa forma, a exclusão de modelos pouco relevantes ou com a adoção de modelos híbridos de análise, permite-se que durante uma iteração a equipe se importe com apenas aquilo que realmente é necessário para o desenvolvimento, ou seja, não se gera algo que não traga valor ao processo de desenvolvimento. Geralmente, o trabalho em equipe deve manter seu foco para que: • Os modelos sejam vistos como artefatos da equipe, onde todos tem possibilidade de alterá-los a qualquer momento, quando for preciso; • Os modelos propostos sejam de domín io público; • A participação dos stakeholders seja uma prática efetiva na modelagem coletiva; • O modelo seja algo de valor que venha da própria equipe para o entendimento da equipe. Essa prática faz com que as linguagens de modelagem, bem como os artefatos empregados, sejam a maneira formal de comunicação entre os envolvidos com o projeto de desenvolvimento. Vale ressaltar que equipes que atuam com MA, com o desenrolar do projeto, tendem a produzir uma quantidade reduzida de modelos durante o desenvolvimento, evitando assim, o desperdício de tempo.

Figura 3. Características da Modelagem Ágil


AGILIDADE

Modelagem ágil na definição da arquitetura A construção de sistemas de informação é um processo crítico, principalmente quando é iniciado um novo projeto de desenvolvimento. Inúmeros fatores podem agir de maneira ativa para o aumento ou diminuição do nível de complexidade do projeto. A definição de interfaces, padrões e a infraestrutura técnica do produto podem ser determinantes para o sucesso do empreendimento. Baseado na gestão proativa de mitigação de riscos presente no XP, o direcionamento da solução de arquitetura é tratado pelo nome de “Spike”. Um Spike pode ser visto como uma maneira de tratar a arquitetura de um projeto de forma a não impactar as entregas das histó- Figura 4. Diagrama de Implantação WebBank rias de negócio do cliente. O Processo Unificado, por sua vez, determina que a modeo direcionamento e orientação do time sobre um determ inado lagem da arquitetura deve ocorrer em duas fases distintas. tema. Essas sessões ocorrem durante todo o projeto, porém A primeira atendendo ao projeto de arquitetu ra de alto nível, são prioritariamente necessárias no início. Essa técnica prevê prevendo a construção de modelos que estabeleçam a distribui- que as perguntas levantadas pelo time potencialmente são ção dos componentes e os recursos de hardware disponíveis. resolvidas pelo próprio time! Na segunda fase o projeto detalhado, de baixo nível, as funDessa forma, o Brainstorming não exige que seja feita uma cionalidades de cada módulo sistêmico são elaboradas desde preparação prévia, com a definição de perguntas como feito suas interfaces até o banco de dados. Ambas as fases descritas em sessões JAD, por exemplo, pois faz a discussão emergir dos pelo Processo Unificado são trabalhadas no XP, porém com problemas enfrentados pela equipe e, com a possibilidade do visão e direcionamentos diferentes. grupo produzir seus próprios modelos, torna-se facilitada a A aplicação da Modelagem Ágil ao contexto de um Spike resolução do mesmo pela própria equipe durante as reuniões deve providenciar modelos simplificados, pois nessa etapa diárias. esses devem amparar o mínimo de informações para que sejam executadas as Provas de Conceito (POC), implementando os Aplicação de artefatos corretos conceitos de arquitetura e proporcionando testar a viabilidade A aplicação de artefatos corretos é determinante para o bom do modelo. desempenho da equipe, pois para cada situação e para aqu ilo Para o exemplo do case WebBank, a primeira definição para que se deseja representar existe uma demanda por conhecia estrutura necessária à arquitetura do projeto seria represen- mento específico. A aplicação do artefato correto permite um tada por um Diagrama de Implantação, conforme apresentado melhor entendimento da demanda solicitada. pela Figura 4. A simplicidade desse modelo representa aquilo Em resumo, a forma como será feita a comunicação deve ser que é necessário para implantar a solução no momento inicial. convencionada e utilizada sem restrições por todos os memÉ costumeiro dizer que devemos ter a informação necessária bros da equipe de desenvolvimento e, havendo a necessidade para que a equipe “não passe fome”! Ou seja, qualquer modelo de comunicar e analisar sistemas, tais meios devem ser plemais elaborado, empregando maior quantidade de informa- namente utilizados. Artefatos técnicos de análise de sistemas, ções, pelo o projeto estar em seu início, pode representar um tais como a Análise Essencial, Estruturada ou Orientação a desperdício de tempo. Vale lembrar que a única certeza é que Objetos devem ser o meio utilizado para esse fim. haverá uma evolução dos modelos cada iteração. Para isso, é importante que os membros do time tenham familiaridade com algum tipo de notação. UML, Diagramas A importância do brainstorming de Fluxo de Dados e Modelos Relacionais são exemplos de Durante o projeto é necessário que o facilitador e líder técartefatos que precisam ser empregados e entendidos por todos nico de MA faça sessões de Brainstorming com sua equipe, durante as sessões de Modelagem Ágil. apresentando ao time informações suficientes para que se Já é sabido que durante as sessões de Brainstorming a criação fomente um amplo entendimento das necessidades do projeto, de modelos ocorre de forma até intuitiva, pois o ambiente é instigando que todos se envolvam mais facilmente com a visão propício para tal. Logo, o cruzamento de informações para a e o contexto do produto que será desenvolvido. criação de novos modelos acaba ocorrendo de forma a aprimorar Em MA, sessões de Brainstorming são de grande importâno entendimento de todos com relação às demandas propostas. cia, pois servem para explorar as potencialidades do grupo, Imagine que estamos a postos com nossa equipe, logo no inífuncionando tanto para a resolução de problemas, como para cio das atividades do projeto, prontos para iniciar a modelagem Edição 70 - Engenharia de Software Magazine

17

do aplicativo WebBank. É muito comum explorarmos aquilo que nos parece óbvio no início do desenvolvimento do sistema, principalmente em tecnologias voltadas para web ou mobile. A cultura da interface é um ponto forte desses modelos e deve ser visto pela equipe como algo que direcione a especificação. Pelas indicações dadas no texto com a Visão do Produto WebBank, o time consegue identificar aquilo que é prioritário estar disponível para o cliente durante sua interação com o aplicativo. Para tal, a melhor saída para iniciar o entendimento é construir um protótipo de baixa fidelidade, conforme apresentado na Figura 5. Inicialmente, com as informações disponíveis do texto, ficou estabelecido que devemos apresentar ao usuário as segui ntes informações: Login/Senha, Extrato, Pagamento de contas, Recarga para celular, Número da conta e Saldo atualizado da conta.

será útil para a confecção dos testes unitários e de aceitação. A construção do modelo visual deve facilitar o entendimento do negócio por parte do time. Na primeira sessão de modelagem dos casos de uso do projeto, o resultado está representado pela Figura 7.

Figura 6. Modelo de navegação

Figura 5. Protótipo de baixa fidelidade

Dado esse primeiro passo, para que tudo fique ainda muito mais intuitivo, pode ser útil definir como será a dinâmica dos controles que estarão disponíveis para o usuário durante o uso da aplicação. Portanto, entender como as interfaces se comunicam com o cliente e tentar estabelecer um modelo passo a passo do aplicativo, simulando sua navegação pode ser uma tarefa desejável, facilitando a compreensão do comportamento do software. A equipe pode definir um Modelo de Navegação do aplicativo para esse fim, conforme apresentado pela Figura 6.

Orientação a testes

Figura 7. Modelo de caso de uso

A prática de testar todo e qualquer modelo é oriunda do Extreme Programming (XP), onde por meio da aplicação da técnica TDD (Test Driven Development) os modelos são certificados quanto à sua veracidade e utilidade, por meio de testes de aceitação do cliente e, unitários, provenientes do desenvolvimento. Com base na descrição da Visão do Produto WebBank, já podemos definir um modelo dos casos de uso envolvidos, mesmo que em alto nível. Portanto, o passo a passo da interação homem/sistema, com a dinâmica especificada por escrito

Com a construção e especificação do modelo de casos de uso, já é possível definir boa parte dos cenários de teste. Em XP, a orientação a testes além de promover qualidade aos produtos gerados, previne com relação à propagação de erros. Com o uso dessa técnica, a validação dos modelos a cada iteração reflete tanto na qualidade do produto, pois oferece maior confiabilidade ao código gerado, como também permite que aquilo que for enviado à produção é de fato, a versão mais estabilizada dos modelos de análise utilizados pela equipe.


AGILIDADE

Criação de modelos paralelos A criação de modelos paralelos serve para a elucidação e entendimento de determinados conceitos do sistema, os quais podem não ficar tão claros com o uso dos demais modelos instituídos para o projeto. Os modelos que surgem em paralelo, por natureza são temporários e devem ser vistos como uma alternativa, podendo ser descartados assim que os propósitos que determinaram sua construção forem atendidos. Dessa forma, modelos paralelos na maior parte das vezes, embora úteis, são descar táveis. Observe as perguntas a seguir: • Como que o usuário inicia o uso do aplicativo? • Qual sua primeira ação ao entrar no sistema? • O aplicativo fará a validação do usuário na aplicação? • Existirá uma interface principal? • O usuário terá uma área exclusiva para navegação com controles personalizados? Estas perguntas podem ser respondidas por meio de diagramas que indiquem o fluxo de ações. Dessa forma, até para estruturar melhor o entendimento, os modelos já desenhados, contendo o Protótipo de baixa fidelidade e o Mapa de Navegação, servem como base para o esboço dos fluxos (ou atividades), que o usuário poderá interagir pela aplicação. É comum que o time defina o entendimento do fluxo por meio de uma representação do processo. Para isso, utiliza-se o

formato de um Diagrama de Atividades, conforme apresentado pela Figura 8 para esse fim, definindo as etapas sequenciais do processo desejado.

Figura 8. Diagrama de atividades


19

a utilização de ferramentas CASE, para que seja possível municiar os membros das equipes com toda a informação necessária para dar andamento aos seus trabalhos.

Modelagem incremental

Figura 9. Diagrama de sequência

A modelagem incremental é baseada no conceito de iteração, uma vez que os times estão trabalhando em regime de ciclos de desenvolvimento com tempo fixo. Dessa forma, todo e qualquer modelo tra balhado pela equipe deve crescer, ao passo que o projeto avança. O incremento dos modelos é inerente à necessidade da equipe que deve sempre gerar apenas aquilo que é necessário para dar prosseguimento aos trabalhos durante a iteração do desenvolvimento. Para exemplificar a modelagem incremental, um dos melhores modelos para essa representação é o Diagrama de Sequência, apresentado na Figura 9. Esse modelo tende a ser construído agregando novas informações no decorrer do desenvolvimento do sistema, sempre que necessário.

Modelagem coletiva

Figura 10. Modelo relacional

Apresentação de modelos públicos Os modelos utilizados pelo time durante a modelagem e análise do projeto devem estar disponíveis para todos os membros da equipe. Preferencialmente esses modelos devem ficar num local público e de amplo acesso ao time de projeto. Para que haja essa exposição, é necessário que quadros seja m disponibilizados, onde a equipe possa escrever e desenhar, entre outras atividades pertinentes à análise. A distribuição geográfica dos quadros deve ser feita no local de trabalho da equipe, uma vez que a comunicação visual desses modelos providencia um maior interesse do time para com o problema a ser resolvido. Em casos de equipes com dispersas em locais geograficamente distintos, os modelos devem ser publicados em local comum na rede, se possível, com

A modelagem coletiva é uma forma eficiente de equalizar o conhecimento da equipe junto aos principais modelos utilizados pela equipe durante o projeto. Vale lembrar que a modelagem é um trabalho de abstração e, nem sempre, os modelos desenhados pela equipe contemplam todas as necessidades do projeto ou mesmo estão validados. As sessões de modelagem devem ter por objetivo promover a comunicação entre os participantes do time, com o intuito de abordar apenas o domínio da solução a ser dada para um conju nto restrito de requisitos. Por tal motivo, a modelagem coletiva deve ser prevista como prática diária da equipe, antes mesmo do início do desenvolvimento dos testes e do código, pois a partir dela que os mem bros do time estarão aptos para implementar as orientações definidas pelos modelos analisados pelo time. A Modelagem de Dados apresentada pela Figura 10 é um modelo altamente coletivo, pois em sua definição contém os conceitos que serão trabalhados em conjunto pela equipe durante as iterações. No mesmo contexto do MER, se aplica também ao diagrama de classes, representado pela Figura 11.

Modelar para comunicar Sobre o aspecto da comunicação em Modelagem Ágil, Alistair Cockburn por meio da sua metodologia Crystal, estabelece


AGILIDADE

que a escolha por modelos menos formais e mais interativos auxiliam o processo de entendimento das equipes e influenciam diretamente na performance dos times durante a execução de um projeto de desenvolvimento de software. Cockburn propõe que a eficácia na comunicação está diretamente ligada à proximidade entre os interlocutores, sendo que a comunicação cara a cara é mais efetiva, além de propiciar um melhor entendimento aos envolvidos no projeto, que dialogam entre si e resolvem os problemas de forma direta e conjunta. Para isso ele propõe um gráfico para definir a eficácia dos meios de comunicação disponíveis para as equipes durante um projeto, o que pode ser visto pela Figura 12. Claramente, modelos voltados para comuFigura 11. Diagrama de classes nicar tendem a ser temporários. Por esse modelo fica fácil perceber a importância da comunicação interativa entre os membros de uma equipe, nos ambientes de trabalho ágeis serem disponibilizados um uma vez que a utilização de difusores de informação impri- quadro do tipo Kanban e lousas para que a equipe possa me uma maior disponibilidade naquilo que realmente se faz “rabiscar” seu entendimento e ajustar de forma visual a coimportante durante o curso do projeto. Dessa forma é comum municação entre si.


21

a Demonstração em Código! Por mais que os modelos gerados durante a análise sejam úteis para o entendimento do que deve ser feito, um objetivo fim deve ser cumprido: a geração do código. Dessa maneira, todo e qualquer modelo só poderá ser homologado uma vez que o código gerado passe pelos testes de aceitação e funcionais, garantindo que o modelo atende às necessidades do negócio, funcionais, do produto e principalmente, esteja aderente às expectativas do cliente. Sem isso, nada feito! Referências: Agile Software Requirements, Lean Requirements Practices for Teams Programs and the Enterprise (2011): Addison-Wesley. Ambler, S. (2002). Agile Modeling, Effective Practices for eXtreme Programming and the Unified Process: Wiley. Beck, K. (2000). Extreme programming explained. Reading: AddisonWesley. Figura 12. Diagrama de comunicação (Robustez)

Cockburn, A. (2002), Agile Software Development: Addison-Wesley.

Outros meios de comunicação, tal como e-mail, wiki, telefone, conferência podem ser utilizados, porém se mostram menos efetivos quando se há a necessidade de centralizar as ações que o time deve tomar durante a jornada de desenvolvimento. Ou seja, a comunicação para que se torne fluída, deve estar disponível e acessível no ambiente em que o time se reúne para o trabalho e isso é parte fundamental para que seja c riado um ambiente com sinergia e orientado a resultados. Os conceitos aqui apresentados mostraram uma nova forma de aplicar as práticas definidas pelo Processo Unif icado. Vimos neste artigo que a abordagem Ágil é válida desde que ao fi nal exista um produto que possa ser utilizado. Por tal motivo, de todos os itens relacionados às características da Modelagem Ágil, o último sintetiza esse artigo:

Crispin, L., Gregory, J., Agile Testing, A Practical Guide for Testers and Agile Teams (2009): Addison-Wesley. Kroll, P., MacIsaac, B., Agility and Discipline made Easy, Pratices from OpenUp and RUP (2006): Addison-Wesley. Poppendieck, M., Poppendieck, T, Lean Software Development: An Agile Toolkit (2003), Addison-Wesley Professional.



Planejamento e Gerência Nesta seção você encontra artigos voltados para o planejamento e gerência de seus projetos de software.

Desenvolvimento Ágil: O papel do PMO no mundo Ágil Qual o papel do PMO no mundo Ágil Fique por dentro:

D

Sérgio Salles Galvão Neto [email protected]

Gerente de Projetos certificado PMP, ITIL, Microsoft entre outras.Atuando na área de informática desde 1992 e, a mais de 10 anos liderando equipes em projetos de desenvolvimento e implantação de softwares.Nos últimos cinco anos, atuando como Scrum Master em projetos em diversas tecnologias e ramos de negócio.

e acordo com os princípios do PMI (Project Management Institute), entidade responsável pela divulgação e padronização de boas práticas em Gerenc iamento de Projetos, através da publicação do guia PMBOK (Project Management Body of Knowledge), o corpo de conhecimentos em Gestão de Projetos, recomenda-se a existência do chamado Escritório de Projetos (PMO). Nas empresas de maior porte pertencentes ao seguimento de desenvolvimento de software, é mais comum encontrarmos uma estrutura mais voltada a projetos, são as chamadas estruturas projetizadas. Geralmente, estas empresas projetizadas possuem um escritório de projetos onde são estabelecidos os padrões relacionados ao gerenciamento de projetos tais como metodologias, ferramentas, modelos, entre outros.

A crescente adoção dos métodos ágeis por empresas do seguimento de desenvolvimento de software, independentemente de seu porte, já começa a afetar as estruturas tradicionais de gerenciamento de projetos. Trata-se de uma mudança na cultura nestas organizações. O escritório de projetos e o executivo de projetos passaram a ter outras e novas preocupações e responsabilidades para ajudar a garantir o sucesso dos projetos. Neste artigo iremos descrever como os executivos de projeto devem se adequar a esta realidade do mundo ágil.

Iremos explorar, neste artigo, uma visão geral sobre o papel dos escritórios de projetos, dos responsáveis pelos escritórios de projetos, conhecidos como executivos de projeto ou PMOs, suas funções, seus papéis frente às organizações. Faremos também a análise de alguns importantes relatórios emitidos por instituições muito bem reconhecidas no mercado como a ESI International e a Version One. A ESI Internationl elaborou um est udo sobre a situação geral dos escritórios e


23

executivos de projetos (PMOs) ao redor do mundo, demonstrando o que mudou no ano de 2013 em relação ao ano de 2012. Em linhas gerais, o estudo da ESI representa o que os PMOs vem enfrentado e seus principais desafios em termos de futuro. A Version One emite um relatório anual sobre um estudo a respeito da situação da adoção das metodologias ágeis por empresas de diversos tamanhos ao redor do mundo. Este estudo busca responder questões tais como o aumento ou a redução de eficiência percebida nos projetos, através da compilação e apresentação de quadros explicativos expondo os números percentuais das opiniões das pessoas pesquisadas neste estudo. Outros e relevantes assuntos são tratados de forma objetiva apontados neste estudo o qual o torna uma fonte de informação muito rica para apoiar a tomada de decisão, principalmente para aquelas empresa que ainda não optaram ou ainda não se decidiram por adotarem uma metodologia ágil. Com o advento da popularização das metodologias ágeis e uma crescente demanda em sua adoção, as empresas do ramo de desenvolvimento de software precisam adequar-se a esta nova realidade. Em empresas de menor porte, a adoção por um novo método é, sem dúvida, mais rápido e fácil do que em uma empresa de maior porte. Uma empresa de maior porte precisa de maiores e mais precisos controles sobre o andamento de seus projetos. Em empresas deste tipo, geralmente optaram por criar uma estrutura projetizada, a área de projetos é vista com grande relevância e deve estar alinhada com as estratégias da empresa. É de responsabilidade do executivo de projetos tornar esse alinhamento possível e garantir que os projetos sejam concluídos conforme tais expectativas. Os executivos de projetos, dentro dos escritórios de projetos, também são responsáveis pela criação e manutenção da metodologia de projetos da empresa, eles devem promover uma melhoria contínua nos processos que compõem a metodologia de projetos da empresa. Optar por adotar uma metodologia ágil requer uma importante e decisiva participação dele. Neste artigo veremos quais são as principais barreiras e preocupações encontradas as quais impedem ou dificultam a adoção dos métodos ágeis. Por outro lado, este artigo também abordará os ganhos percebidos pelas empresas que optaram em adotá-los.

Escritório de Projetos (PMO) Em organizações focadas em projeto, também conhecidas por possuírem uma estrutura organizacional projetizada, entendese que o corpo diretor adotou e compreende a necessidade de criar, planejar, executar, monitorar e concluir projetos os quais, geram resultados tangíveis, estratégicos e que agr egam valor ao negócio ou atividade fim da empresa. Desta forma, existe um compromisso entre todos da empresa em garantir que estes projetos sejam concluídos e de forma satisfatória. Satisfatório é, tão somente, classificado aquele projeto o qual c umpriu seu escopo, dentro de um prazo e custo planejado, com a qualidade esperada pelo solicitante.

A profissionalização das equipes de projeto é, certamente, o meio mais seguro de garantir que as equipes obtenham sucesso em seus projetos. O PMI oferece diversas certificações conforme o nível de escolaridade e de experiência do profissional de projetos. Citaremos algumas das mais conhecidas e, lembrando que não se limitam a apenas estas: • Certificação PMP – Profissional de Gerenciamento de Pro jetos (PMP); • Certificação CAPM – Profissional Técnico Certificado em Gerenciamento de Projetos; • Certificação PgMP – Profissional de Gerenciamento de Programas; • Certificação PMI-SP – Profissional em Gerenciamento de Cronograma do PMI; • Certificação PMI-RMP – Profissional em Gerenciamento de Riscos do PMI; • Certificação PMI-ACP – Profissional Certificado em Métodos Ágeis do PMI. Ter bons profissionais, com conhecimento (habilidades e técnicas), experiência e certificações, aliado ao apoio da direção da empresa pode ainda não ser suficiente. Empresas voltadas a projetos, por necessidade, precisam ser eficientes em diversos aspectos e, a racionalização de recursos (sejam materiais ou humanos) é uma das formas mais eficazes para controle dos custos de um projeto, afinal de contas, um projeto é conduzido por pessoas (recursos) e, na maioria das vezes, representam o maior custo e risco de um projeto. Neste sentido de racionalizar os recursos humanos, é comum existirem equipes ou células de trabalho que trabalham de forma a serem compartilhadas entre os projetos. Quando se trata de desenvolvimento de software, temos bons exemplos destas células ou equipes: • Análise de Requisitos; • Testes; • Infraestrutura; • Arquitetura de Soluções; • Controle de Qualidade. Mas é importante lembrarmos o fato de estarmos falando de uma empresa a qual, mesmo com objetivo fim sendo a produção de software, também possui unidades de cunho administrativo e, consequentemente, estas unidades também recebem demandas dos projetos. Podemos citar como exemplo: • Recursos Humanos (RH): contratar e manter os recursos humanos dos projetos; • Compras: Aquisição de bens e serviços para os projetos; • Tecnologia de Informação: especificar novos itens (hardware e/ou software) que serão usados como ferramentas de trabalho para os projetos. Não obstante, a manutenção e evolução dos ambientes de TI para suportarem as demandas crescentes dos projetos. Podemos perceber a grande e certa possibilidade de haverem conflitos de prioridades entre as demandas dos projetos.

24 Engenharia de Software Magazine - Desenvolvimento Ágil: O papel do PMO no mundo Ágil

PLANEJAMENTO

Iremos expor uma situação real para auxiliar no entendimento destes conflitos ou concorrências entre projetos. A empresa produz software sob demanda a partir de projetos contratados por seus clientes. Existem equipes ag rupadas por tecnologias Java, .Net e PHP. Estas equipes são compostas por pessoas altamente capacitadas e comprometidas. Após uma negociação, a empresa vendeu um projeto o qual precisará ser desenvolvido por duas das equipes, usando as tecnologias Java e PHP, chamaremos este projeto de “A”. Ao mesmo tempo, um segundo projeto é fechado com outro cliente o qual precisará das equipes de .Net e PHP, chamaremos este projeto de “B”. É neste momento que começam os conf litos, tais como: • Projeto A: precisará contratar mais desenvolvedores Java; • Projeto B: precisará contratar mais desenvolvedores .Net; • Projeto A e Projeto B: precisarão dos mesmos recursos de PHP; • Projeto A: precisará que a empresa adquira impressoras fiscais de um novo modelo; • Projeto B: precisará de monitores maiores e que possuam maior resolução; • Projeto A e projeto B: precisarão de mais servidores para hospedarem as versões de testes e homologação; • Projeto A e Projeto B: possuem prazos semelhantes onde os testes ocorrerão nos mesmos períodos de tempo. Estas são apenas algumas situações, digamos que até normais de acontecerem em empresas de desenvolvimento e, não importa o tamanho que a empresa possua, o diferencial competitivo de cada uma está em sua maturidade e estratégia em lidar com situações como esta. Conforme dissemos anteriormente, esta empresa possui uma estrutura projetizada e sabe como gerenciar projetos mas, de acordo com o cenário de concorrência entre os projetos, quem poderá ajudar a definir as prioridades? O departamento de Recursos Humanos irá priorizar as contratações do Projeto A ou do Projeto B? O departamento de compras deverá priorizar a compra dos Monitores para o projeto B ou a aquisição das impressoras fiscais do projeto A? A equipe de testes terá condições de atender ambos projetos com a equipe atual e, ao mesmo tempo? Estas e outras perguntas inevitavelmente necessitarão da intervenção de alguém mas, quem teria condições de decidir? Podemos dizer o presidente ou o diretor mas, se analisarmos friamente a situação, não seria papel de um presidente ou de um diretor interceder em uma questão puramente operacional. Neste momento, não estamos avaliando a capacidade ou disponibilidade, apenas observando a questão do ponto de vista prático, um presidente ou um diretor possuem funções e responsabilidades muito maiores. Neste caso, seria necessário alguém com um papel intermediário, que entendesse a visão dos projetos e como conciliar os conflitos. O papel mais indicado seria do executivo de projetos ou PMO (Project Management Officer). Este papel, para poder ser devidamente executado, necessita de uma estrutura adequada, um lugar onde o gerenciamento de projetos seja pensado, planejado, construído para abrigar os itens necessários para

a execução dos projetos (ferramentas, softwares, etc.), onde os projetos sejam executados e gerem resultados em sintonia com a estratégia da empresa. Esta estrutura dedicada a pro jetos tem o nome de escritório de projetos, ou PMO (Project Management Office). Possuir uma estrutura projetizada remete-nos a uma maneira formal e/ou tradicional de condução de projetos. Algumas empresas, normalmente aquelas de maior porte, entenderam a necessidade em criar um escritório de projetos. Para criar um escritório de projetos, são necessários investimentos significativos. Mas isso deve ser entendido não apenas como investimento financeiro mas também, investimento de tempo, em treinamentos, em confiança depositada em seus colaboradores e, na quebra de paradigmas, promovendo uma mudança profunda na cultura da empresa. Tais investimentos são quase impossíveis de serem mensurados em termos financeiros. Por outro lado, existe a confiança em se obter ganhos em diversos aspectos, principalmente no que se refere a melhoria de controles e geração de indicadores. A empresa passa a entender que, para atingir seus objetivos comerciais, a melhor opção é criar projetos que a levem a atingir estes objetivos. Os projetos devem resultar em novos produtos e/ou serviços ou na evolução destes produtos/ serviços. Tais projetos irão manter a empresa competitiva e atualizada frente ao mercado, um mercado cada vez mais rápido e exigente.

Visão geral sobre o Escritório de Projetos (PMO) O escritório de projetos possui a responsabil idade de estabelecer, de forma padronizada, os processos de governança dos projetos, ou seja, dar transparência e visibilidade de como os processos de gerenciamento de projeto são criados, executados, monitorados e auditados. A partir do estabelecimento dos processos, cria-se a metodologia de projetos da empresa a qual pode adotar integralmente ou as partes das boas práticas sugeridas no PMBOK (o que é extremamente recomendável) desde que estejam em conformidade com a estratégia e cultura da empresa. A adoção de mais de um conjunto de boas práticas também é muito comum no ramo da engenharia de software. Podemos citar o Prince2 como exemplo de framework de gestão de projetos. A metodologia, além dos processos, também define as ferramentas (geralmente os softwares) e as técnicas (modelos matemáticos ou conjunto de procedimentos) as quais serão utilizadas nos projetos. O local e o tratamento das informações históricas dos projetos também deverão ser estabelecidos no escritório de projetos, ou seja, todas as informações geradas pelos projetos devem estar em repositórios (sistemas de gestão de arquivos) que além de armazenar, devem cuidar do acesso e versionamento destes arquivos. As informações históricas devem ser monitoradas e revisadas a fim de gerar indicadores dos projetos. Estes indicadores deverão ser criados para demonstrar a saúde dos projetos e, serem utilizados na tomada de decisões no que se refere, essencialmente, à melhoria contínua dos processos e projetos. Edição 70 - Engenharia de Software Magazine

25

Projetos podem ser organizados através de programas de pro jetos e, o conjunto de programas de projeto pode ser organizado em portfólio de projetos. Esta abordagem de organização de pro jetos é melhor executada e controlada no escritório de projetos pois, também é função dele prover a situação dos projetos. A categorização dos projetos em programas ou portfólios é uma forma de demonstrar o alinhamento dos projetos à estratégia da empresa. Projetos de pesquisa, por exemplo, podem não estar na estratégia da empresa até que surjam oportunidades (riscos positivos) onde um ou mais projetos de pesquisa podem se tornar estratégicos. Desta maneira, através do uso da avaliação dos programas e/ou portfólios de projetos, torna-se mais clara a decisão em se executar ou não um determinado programa ou projeto. O executivo de projetos deverá garantir que estes projetos estejam alinhados com a estratégia comercial da empresa. É o mesmo que dizer: – “O sucesso da empresa depende do sucesso dos projetos e do Executivo de Projetos respectivamente”.

Executivo de Projetos (PMO) Os escritórios de projetos podem ser estruturados de diversas maneiras de forma a oferecer diferentes níveis de controle e influência dentro de cada organização. No PMBOK, eles podem servir para Suportar, Controlar ou Dirigir os projetos. Para cada um, o nível de controle e responsabilidade do executivo de projetos também será diferente. Suportar significa que o escritório de projetos irá disponibilizar uma estrutura mínima a f im de garantir o registro das atividades, resultados obtidos e das lições aprendidas de cada projeto. Em linhas gerais, o escritório de projetos funcionará como um repositório de informações garantindo que o passado esteja registrado. O nível de controle sobre os projetos será pequeno, bem como a influência do executivo de projetos sobre os projetos também será modesto. Quando o assunto é controlar, quer dizer que o escritório de projetos possuirá uma estrutura suficiente para estabelecer padrões e exigir o cumprimento destes padrões. Para controlar será necessário que os projetos sigam uma metodologia, um conjunto de boas práticas, modelos, formulários, ferramentas, ou seja, tudo que esteja de acordo com a governança para que o controle demonstre os resultados obtidos a partir da análise de indicadores definidos. Dirigir é assumir o controle dos projetos em si, ou seja, o executivo de projetos passa a administrar e gerenciar os gerentes e os projetos durante todo seu ciclo de vida. Além de suportar e controlar, os resultados obtidos de cada projeto também passam a ser de integral responsabilidade do escritório de projetos e do executivo de projetos. Independentemente do nível de controle esperado pela organização, dentro de um escritório de projetos, o PMO precisará, além de profundos conhecimentos sobre todos os aspectos que envolvem a gestão de projetos, possuir certas habilidades tais como: negociação, conciliação, e ser um mentor nato. E, não menos importante, um executivo de projetos deverá ter a capacidade de traduzir a estratégia da empresa em forma de projetos (ou programas e portfólios). O objetivo desta tradução

é poder estabelecer métricas (indicadores) e, por conseguinte, os parâmetros para monitorar, controlar e ajustar os projetos de forma que atinjam seus objetivos e que estes objetivos estejam em conformidade com a estratégia da empresa. Podemos perceber que as figuras do escritório de projetos e do executivo de projetos passam a ter um papel crucial para que a empresa, a partir da estratégia comercial estabelecida, atinja o sucesso através do resultado positivo dos projetos, ainda mais quando o ramo da empresa é o desenvolvimento de software. Uma empresa atuante neste segmento precisará acompanhar as mudanças tecnológicas para manter-se competitiva no mercado. Além da evolução da tecnologia, das linguagens de desenvolvimento, dos equipamentos, as metodologias também devem evoluir. O bordão de que o departamento de tecnologia da informação (TI) deve fazer mais (produzir mais) com menos (custos menores) é uma constante no cotidiano destas empresas e, neste sentido, adotar uma metodologia ágil é uma maneira de melhorar a eficiência e eficácia dos projetos.

Um retrato dos escritórios de projeto pelo Mundo Em sua 3ª Edição, a empresa ESI International emitiu um relatório chamado “The Global State of the PMO”. O estudo fez uma análise sobre a situação dos escritórios de projeto ao redor do mundo em 2013. Neste estudo podemos encontrar diversas informações úteis sobre o desafio dos escritórios de projeto bem como a situação atual e um cenário de tendências para eles. Enfatiza-se, neste estudo, como sendo vital a existência dos escritórios de projetos para contribuir na orientação tática, estratégica ou operacional no dia a dia dos negócios através do envolvimento nas entregas de resultados dos projetos e programas de projetos das empresas. Alguns resultados interessantes foram: • 68% dos PMOs foram questionados sobre sua própria eficácia em 2013 (54% em 2012); Significa o aumento da importância do papel dos PMOs. • 75% dos PMOs “ativos” estão empenhados em gerar sustentação de aprendizado e também criar um plano de carreira para gerentes de projeto; A grande preocupação na capacitação contínua e retenção dos talentos nas empresas.

• 22% de todos os PMOs pesquisados operam no nível estra tégico das empresas; Ou seja, a importância do papel dos PMOs vem assumindo maior relevância tática e estratégica para as empresas.

• 56% PMOs ativos informaram que mais de 75% dos projetos foram entregues dentro do prazo/custo. Com a adoção dos PMOs, a eficiência e eficácia dos projetos é notoriamente maior.

Em complemento, o estudo demonstra em alguns pontos chave a visão geral e o valor atribuído aos PMOs, tanto no que se refere ao escritório de projetos, propriamente dito, bem como aos executivos de projetos. A seguir a relação destes pontos chaves demonstrados no estudo:


PLANEJAMENTO

• Menor envolvimento em Treinamento: Com o aumento da profissionalização dos gerentes e das equipes de projetos, a necessidade do PMO se envolver em treinamentos de capacitação tem sido cada vez menor; • Aumento da visibilidade sobre a eficiência dos PMOs: Houve aumento de 15% no número de PMOs que passaram a observar e medir sua própria eficiência. Em outras palavras, os PMOs tem tido a necessidade, cada vez maior, de demonstrar seu valor através de métricas tais como sucesso nos projetos e retorno do investimento (ROI), completude de projetos dentro dos prazos e custos; • Menos desafios: Em contrapartida sobre o aumento da visibilidade de sua eficiência, os PMOs considerados ativos e engajados em sua função tem sido menos desafiados pelas partes interessadas. O fato de serem menos desafiados pode ser visto como uma melhora pois não se precisa desafiar aquele que já possui um histórico de eficiência e eficácia; • Planos de Carreira: 75% dos PMOs considerados ativos e engajados, estão empenhados em criar planos de carreira para os gerentes e equipes de projeto. Um número bastante expressivo quando comparado aos 41% obtidos no estudo no ano de 2012; • Aumento na satisfação com os PMOs – 42% dos entrevistados consideraram como “Excelentes” ou “Muito Bons” os PMOs de suas empresas; • Para medir a eficiência os PMOs adotaram métricas tais como: - Aumento na satisfação de seus clientes – 64%. Em 2012 este número era de 45%; - Retorno do Investimento (ROI) – 43%. Em 2012 este número era de 24%. Na Figura 1 podemos verificar o percentual de empresas que responderam se tem, não tem ou se pretendem ter um PMO.

72% pode ser encarado como um excelente índice demons trando a preocupação das empresas em investir na criação e manutenção dos escritórios de projetos. As empresas demonstram também o quanto valorizam e entendem a importância na adoção dos escritórios de projetos e a consciência da necessidade do alinhamento das estratégias junto a área de projetos. Em termos globais, 46% das empresas possui um escritório de projetos. Neste estudo, é mencionado que o grande desafio dos PMOs é lidar com o ambiente dos clientes em constante mudança e a crise financeira global.

A adoção dos métodos Ágeis pelo Escritório de Projetos Apesar de notória a eficiência obtida a partir da adoção dos métodos ágeis, o PMO deverá estudá-la de forma a verificar a melhor maneira de adotá-la. Adotar um conjunto de métodos ágeis significa alterar os processos atuais, gerar mecanismos para medir sua eficiência e sua eficácia. Também representa ceder de certos formalismos para dar espaço à agilidade. Mas, na prática, quais são os impactos reais em adotar os métodos ágeis? Para responder a esta questão, podemos citar o 8º Relatório Anual Sobre a Situação do Método Ágil nas empresas (State of Agile), patrocinado pela empresa Version One, o qual apresenta uma visão geração quanto a adoção dos métodos ágeis pelas empresas. Para garantir a integr idade das informações, as pesquisas foram respondidas por 3501 pessoas no ano de 2013 as quais trabalham em empresas do ramo de desenvolvimento de software e TI ao redor do Mundo onde 66% são oriundas da América do Norte e 22% da Europa. Segundo este 8º Relatório Anual, existem diversos fatores que impedem a adoção dos métodos ágeis, entre eles foram destacados três como sendo os principais: a incapacidade de mudar a cultura organizacional, resistência a mudanças e tentar encaixar os elementos ágeis em métodos tradicionais (Não Ágeis).

80% 72% 70%

60%

50%

40%

30%

20% 13% 10%

7% 4%

4%

0% Yes

No

Don't Know

No

No

We have an existing PMO in place

We have never had a PMO

Do not know if we have a PMO

Do not know if we have a PMO

We used to have a PMO but it was disbanded

Figura 1. Percentual de empresas que possuem PMO


27

O estudo elencou outros itens classificados como barreiras os quais podem ser observados na Figura 2. Ainda observando o 8º relatório anual, são citadas como as maiores preocupações em adotar os métodos ágeis: Perda do Controle de Gestão e a Falta de visibilidade de planejamento. Na Figura 3 , podemos observar as demais preocupações expressas pelas pessoas entrevistadas pelo estudo. As barreiras e as preocupações citadas no 8º Relatório Anual representam a incerteza por parte das empresas em adotar os métodos ágeis. Porém, para estes que foram considerados como principais, cabe uma ponderação do ponto de vista prático uma vez que não se pode avaliar um argumento apenas por um único ponto de vista.

Avaliação sobre as barreiras e preocupações na adoção dos métodos ágeis Em continuidade aos pontos mencionados no 8º Relatório Anual, sobre as barreiras “A incapacidade de mudar a cultura

Figura 2. Barreiras para adoção dos métodos Ágeis

organizacional” e “Resistência a Mudanças”: para se manter em um mercado cada vez mais competitivo e exigente, adaptar-se é uma questão crucial. A empresa que apostar em estratégias e em processos imutáveis, principalmente no ramo de desenvolvimento de software pode inviabilizar sua existência. A constante e rápida evolução da tecnologia irão pressionar estas empresas por mudanças. Empresas que se adaptam de forma ágil possuem mais chances de se manterem competitivas e até tornarem-se líderes graças à inovação. Outro forte argumento é o simples fato dos processos de melhoria contínua serem o alvo de modelos de maturidade tais como CMMi, MPS .Br, ISO, entre outros. Quanto a outra barreira mencionada “Tentar encaixar os elementos Ágeis em métodos tradicionais (Não Ágeis)”, para analisar esta tentativa em tentar encaixar itens de um modelo em outro, de naturezas diferentes é preciso rec orrer à Relação Custo versus Benefício, esta é a maneira mais coerente em se verificar se é viável trocar uma coisa por outra coisa. Em atenção às principais preocupações em adotar os métodos Ágeis: Perda do Controle de Gestão e a Falta de visi bilidade de planejamento são fundamentais para entender o que exatamente está sendo perdido. Perda de Controle de Gestão só ocorre quando se deixa de gerenciar algo e, no caso dos métodos ágeis parte da Gestão e Controle passam a ser responsabilidade da equipe e do Scrum Master. Dizer que haverá falta de visibilidade de planejamento também precisa ser reavaliado pois, nos métodos ágeis, passamos a ter a visão do Backlog do Produto. Nos modelos de maturidade, tanto no CMMi qua nto no MPS .Br, ambos são unânimes na utilização dos métodos ágeis desde que alguns controles sejam estabelecidos. Troca-se a visibilidade do planejamento pelo backlog, estimula-se a geração de histórico de unidades de medida de performance

Greatest Concerns About Adopting Agile Loss of management control

30%

Lack of up-front planning

30% 28%

Management opposition 24%

Lack of documentation 23%

Lack of predictability 20%

Lack of engineering discipline 19%

No concerns 18%

Inability to scale 17%

Dev team opposed to change 15%

Regulatory compliance 13%

Quality of engineering talent Reduce software quality

9%

Figura 3. Maiores preocupações em adotar Métodos Ágeis


PLANEJAMENTO

Reasons for Adopting Agile Not important at all

Somewaht important

Accelerate time to market

3%

Manage changing priorities

3%

Better align IT/business Increase productivity Enhance software quality Project visibility Reduce Risk Simplify development process

Very Important

21%

43%

17% 27%

28%

9%

30%

6%

12% 45%

40%

Improve tem morale

14%

41%

Enhance software maintainability/extensibility

13%

8%

35%

10%

38%

40%

7%

40%

45% 34%

15%

47% 36%

15%

18%

47%

35%

11%

19%

48%

15%

Manage distributed teams

23%

55%

Reduce Cost

Improve/increase engineering discipline

27% 42%

24%

6%

32%

54%

9% 3%

Highest importance

7%

36% 37%

5% 25%

4%

Figura 4. Razões para adotar Metodologias Ágeis

para estórias. A complexa gestão de riscos é substituída pela tratativa de impedimentos da Sprint onde o Scrum Master é responsável por remover estes impedimentos. Existem algumas orientações, nos modelos tradicionais de gestão de projeto, quanto a não tentar gerenciar pacotes de trabalhos cujo esforço seja inferior a X horas onde, o número X é estabelecido pela cultura da empresa. Esta regra é conhecida como a regra das 80 horas onde, não há vantagens em decompor atividades cujo esforço somando seja inferior a 80 horas. Neste caso, para pacotes de trabalho que possuam menos de 80 horas de esforço, deve-se apenas informar a sua completude ou não. Ao observarmos a execução de um projeto usando metodologia ágil, durante o planejamento de uma Sprint (Sprint Plan), promete-se uma entrega de algo de valor em um determinado tempo, a meta da Sprint é software funcionando. Se analisarmos friamente, é algo muito parecido com a regra das 80 horas. Se existe a possibilidade de abrir mão de certos níveis de detalhamentos sem que haja perda de controle, igualmente, pode-se abrir mão de um detalhamento em prol de ser mais ágil. Nos métodos ágeis, como o Scrum, a equipe da sprint é a responsável pela sue completude conforme a meta estabelecida. O cumprimento da meta planejada passa a ser a nova unidade de medida. O objetivo dos métodos ágeis é que as equipes se jam auto gerenciadas, onde existe o fator motivador chamado comprometimento. Ou seja, é questão de honra cumprir a meta dentro do prazo e isso transcende a qualquer indicador ou processo, pois traz à tona questões como responsabil idade, auto realização, satisfação profissional, entre outros.

A evolução é necessária, adotar métodos ágeis trazem comprovados ganhos mas, é preciso que alguém na empresa observe, estude e pontue os impac tos de forma coerente e embasada. Recomenda-se experimentos de adoção em uma equipe, cujo escopo de trabalho seja menos crítico frente às demais equipes da empresa. Medir o desempenho e os resultados obtidos servirá de base na tomada de decisão. O executivo de projetos deverá estimular iniciativas como esta.

Vantagens comprovadas na adoção dos métodos Ágeis Continuaremos a analisar os resultados apresentados no 8º relatório anual onde são demonstrados números interessantes sobre as vantagens na adoção dos métodos ágeis. As três razões mais votadas foram: • 23% - Acelera o tempo de resposta em atender ao mercado (Accelerate time to Market); • 16% - Melhora a gestão de Mudanças de Prioridades (Manage changing priorities); • 15% - Propicia melhor Alinhamento entre TI/Negócios (Better align IT/business). A maioria das respostas da pesquisa constante no 8º Relatório Anual foram centradas no maior e melhor foco no cliente e em uma maior previsibilidade dos projetos. Maiores detalhes podem ser observados na Figura 4. Neste 8º Relatório Anual, no que tange à rapidez em concluir os projetos, houve um consenso onde 73% das pessoas Edição 70 - Engenharia de Software Magazine

29

pesquisadas concluíram que os métodos ágeis reduziram o tempo gasto nos projetos. Segundo o estudo deste indicador, em menos de dois anos, a quantidade de pessoas que consideraram os métodos ágeis como redutores de prazos dos projetos mais que dobrou e, consonantemente, o número de pessoas que achavam que os métodos ágeis ou não reduziam ou eram mais lentos, caiu significativamente. Observe a Figura 5 para o quadro completo. Na opinião da maioria das pessoas pesquisadas, houveram melhorias significativas, que foram percebidas ano após ano, em todas as áreas medidas. Com as pessoas mais exp erientes na adoção e uso das metodologias ágeis, os maiores benefícios para as empresas foram: • Melhor gerenciamento das mudanças de prioridade (92%); • Produtividade Maior (87%); • Melhor Visibilidade do Projeto (82%). Does Agile is faster? 73%

12%

9%

6%

Slower time to complete

Not yet completed an agile project

Same time to complete

Faster time to complete

Figura 5. Ágil é mais rápido?

Para visualizar melhor as áreas metidas, observe a Figura 6 a qual demonstra os percentuais percebidos como: Melhorou (got better), Não houve Melhora (No Benefit) ou Piorou (Got Worst) e, em complementação, a Figura 7 , representa o chamado Quadrante Mágico onde é demonstrado o alinhamento entre as áreas que foram percebidas como mais importantes (Most Important) e aquelas onde foram percebidas mais nitidamente as melhoras a partir da adoção das metodologias ágeis.

O papel dos Escritórios e Executivos de Projetos na adoção dos métodos Ágeis Incorporar métodos ágeis na metodologia atual de gerenciamento de projetos de uma empresa em seu escritório de projetos dependerá de uma correta visão sobre o tema pelo executivo de projetos. No relatório anual da empresa ESI International (The Global State of the PMO – 2013) existe uma seção dedicada ao tema ágil. A referida sessão, em seu i nício, apresenta a frase de um gestor a qual diz, em linhas gerais, que o aumento das equipes ágeis e seu respectivo aumento de poder irá diminuir o valor de um PMO centralizado. Diminuir o valor pode ser interpretado, de forma mais coloquial, que o escritório de projetos não precisará mais envolverse ou despender tantos esforços em conduzir projetos ágeis. As atenções de um PMO deverão estar mais voltadas a questões como treinamento e suporte às equipes ágeis. Isso é possível uma vez que as equipes de projetos ágeis partem do princ ípio de serem auto gerenciáveis, ou seja, atividades que a ntes eram de responsabilidade do gerente de projeto agora são divididas entre os membros da equipe. Como exemplo, podemos citar como atividades agora de responsabilidade da equipe, do Scrum Master e do Product Owner: a organização e distribuição do trabalho a ser executada, a resolução de problemas mais

Actual improvement from adopting agile methodologies got Better

No Benefit

Got Worse

92%

Ability to manage changing priorities

7% 1%

Increased productivity

87%

11%

2%

Improved project visibility

86%

12%

2%

Improved team morale

86%

11%

Enhanced sotware quality

82%

Reduce risk

82%

17%

1%

Faster time-to-market

83%

16%

1%

Better alignment between IT & buseness objectives

82%

16%

78%

Simplify development process Improved/increased engineering discipline

74%

Enhance software maintainability/extensibility

75%

Manage distribute teams

15%

4%

67%

Figura 6. Melhorias observadas ao adotar Agile


18% 22% 23% 29%

3%

2% 4% 4% 2% 4%

PLANEJAMENTO

Figura 7. Quadrante Mágico – Melhorias na Adoção de Agile

corriqueiros, a comunicação direta com o cliente, entre outras. Este comportamento é nativo dos métodos ágeis. Em projetos tradicionais, o encerramento das fases e do projeto como um todo, passam pela atividade de Lições Aprendidas. Basicamente as Lições Aprendidas são registradas em um documento, onde os participantes do projeto (equipe, cliente, gerente do projeto, patrocinador e partes interessadas) expressam o que foi bom, o que foi ruim ou o que poderia ter sido melhor e as sugestões de melhoria (para corrigir em o que foi apontado como ruim) durante a fase ou projeto concluído. É responsabilidade do gerente de projeto providenciar este encontro e o registro das lições aprendidas. O registro das lições aprendidas deve ser encaminhado ao executivo de projetos e este deverá analisá-lo e compor ações para que as sugestões de melhoria sejam avaliadas e providenciadas a fim de que, numa próxima fase ou projeto o problema não se repita. Em projetos ágeis, no Scrum principalmente, o processo de lições aprendidas é executado a partir das Sprint Reviews ou Sprint Retrospective. A principal diferença entre as Lições Aprendidas e as Revisões ou Retrospectivas das Sprints está no curto espaço de tempo em que estas ocorrem. O intervalo entre uma Sprint Review e outra ocorrer é de, em geral, de três a quatro semanas, dependendo do formato de Sprints estabelecido pela equipe. Eis que surge o primeiro ponto de atenção aos PMOs – a necessidade de se criar um canal de comunicação aberto entre o Scrum Master e o Escritório de Projetos pois, aquilo que for apontado como item necessário de melhoria, deverá ser analisado e viabilizado de uma forma muito mais rápida de forma a não impactar significativamente as próximas Sprints. Lembrando que as Sprints são como fases do projeto, porém

com um objetivo claro (meta da Sprint) o qual se refere a entrega de software funcionando. O PMO deverá reservar um tempo maior em atenção aos pedidos das equipes ágeis. Uma necessidade apontada durante a Revisão da Sprint, caso não seja resolvida até o final do planejamento da próxima Sprint (Sprint Plan), pode ser encarado como um impedimento o qual poderá gerar entre atrasos ou até o cancelamento da Sprint. Percebemos agora o quão importante será a atitude do PMO frente a este novo cenário. Outro ponto muito importante é que o escritório de projetos deverá auxiliar os gerentes de projetos e as equipe ágeis no que se refere ao treinamento e capacitação das equipes. As necessidades por treinamentos e o ritmo acelerado de trabalhos irão impor grandes restrições de tempo para que as equipes possam enviar as pessoas para serem treinadas. Tomando como base o Scrum, como metodologia ágil, um papel indispensável é o chamado Product Owner, ou Dono do Produto. Este papel impõe um conhecimento muito profundo sobre o que é o produto (a ser criado e entregue pela equipe Scrum) bem como o senso de prioridade. No Scrum, os requisitos são tratados como estórias e, cada estória seria um conjunto de requisitos funcionais e/ou não funcionais os quais são esperados como funcionalidades palpáveis, parte do que se chama de software funcionando. Uma Sprint precisa ser planejada e, este planejamento passa pela análise de um conjunto de estórias priorizado pelo Product Owner. A equipe Scrum se reúne e, analisa o conjunto de estórias e emite um orçamento. O resultado deste planejamento (Sprint Plan) é a meta da Sprint, em outras palavras, a quantidade de estórias cujo esforço orçado é possível de ser entregue dentro do prazo de execução de uma Sprint (geralmente de três a quatro semanas). Edição 70 - Engenharia de Software Magazine

31

O dono do produto e o Scrum Master, bem como a equipe e o cliente, irão interagir intensamente para viabilizar a entrega do produto que foi prometido. Para garantir o cumprimento da meta da Sprint, como prática do Scrum, a equipe se compromete a entregar a meta dentro do prazo. O responsável por considerar entregue e verificar os próximos itens (estórias) a serem produzidos é o Product Owner. As preocupações de capacitação, de um escritório de projetos, não se limitam mais a capacitações em gestão de projetos, mas também, capacitações em áreas de negócio e tecnológicas. No presente artigo acabamos por utilizar a metodologia ágil Scrum como referência. Isto ocorre pelo fato de que a metodologia ágil mais adotada pelas empresas. A metodologia Scrum, somando-se com algumas variâncias conjuntas de Scru m com outras metodologias, somam 73% de adoção por parte das empresas. Na Figura 8 podemos verificar a distribuição na adoção das demais metodologias ágeis pelas empresas. Agile Methodology Used 60% 55% 50%

40%

Podemos concluir, a partir do conteúdo apresentado neste artigo que as empresas de maior porte, uma vez que possuam uma estrutura voltada a projetos, necessitam de uma unidade organizacional a qual suporte os projetos. A esta unidade organizacional se dá o nome de escritório de projetos e, o papel responsável pela criação, manutenção e evolução desta unidade organizacional é o Executivo de Projetos. A adoção dos escritórios de projetos bem como dos métodos ágeis foram amplamente discutidas e tiveram comprovada a sua necessidade e importância. Os métodos Ágeis contribuem de forma significativa para que aumente o alinhamento dos resultados dos projetos às expectativas comerciais das empresas (time to Market) e ainda, tornando mais fáceis as mudanças nas prioridades. O PMO deverá incluir em seu planejamento estratégico a adoção destes métodos ágeis demonstrando, principalmente, os significativos ganhos por elas oferecido. Elaborar um plano de adoção dos métodos ágeis a partir da identificação dos pontos de impacto na metodologia de projetos atual da empresa. O PMO deverá ainda, dentro de um contexto agora ágil, organizar-se para receber as solicitações de melhoria originadas nas Revisões e Retrospectivas das Sprints e providenciar o devido suporte e treinamento para as equipes ágeis, não somente sobre as questões ágeis, mas ainda sobre tecnologias relacionadas à produtividade e capacitação em negócio para Product Owners.

30%

Links e Referências: 20% 10%

1%

1%

1%

1%

2%

2%

3%

5%

7%

11% 10%

ESI International - The Softer Side of Agile: Leading Collaborative Teams to Success http://www.esi-intl.co.uk/resource_centre/white_papers/agile/softerside.asp

0%

Version One – 8th Annual State of Agile Survey http://stateofagile.versionone.com/?utm_campaign=2014%20State%20of%20 Agile%20Auto%20Responder&utm_medium=email&utm_source=Eloqua

Prince2 – Gestão de Projetos de TI http://www.prince-officialsite.com/ Figura 8. Uso dos Métodos Ágeis

De forma resumida, o papel do PMO será o de patrocinar e apoiar a adoção das metodologias ágeis e tornar o escritório de projetos um lugar para abrigar, além dos gerentes de projetos, os Scrum Masters. Para tanto, o PMO deverá dedicar mais atenção ao tema metodologias ágeis e verificar os ga nhos e os impactos na metodologia de gerenciamento de projetos atual adotada na empresa. Da mesma forma que houve um investimento na empresa em tornar sua estrutura voltada a projetos (projetizada), é chegado o momento de uma evolução para a adoção de métodos ágeis dentro da cultura da empresa. Diversos fatores foram colocados neste artigo de forma a auxiliar o PMO de empresas do segmento de desenvolvimento de software em sua tomada de decisão. São fatores tanto positivos como também negativos, ou na verdade os desafios a serem enf rentados por estes profissionais de projetos.

“PMO Maturity Cube”, um modelo de avaliação de maturidade exclusivo para Escritórios de Projetos. Autores: Américo Pinto, Doutorando, Skema Business School/ESC-Lille, França; Marcelo F. de Matheus Cota, Doutorando, Universidade de São Paulo; Dr. Ginger Levin, University of WisconsinParkside, EUA. http://pmotools.org/arquivos/PMOMaturityCube.pdf

Gerenciamento de Projetos – Uma abordagem sistêmica para planejamento, programação e controle – 10ª edição. Autor: Harold Kerzner. ISBN 978-85212-0603-3. The Implementation of Project Management: The Professional’s Handbook. Autor: Linn C., Stuckenbruck. ISBN: 0201072602. ISBN-13: 9780201072600.



Planejamento e Gerência Nesta seção você encontra artigos voltados para o planejamento e gerência de seus projetos de software.

O que faz um Gerente de projetos e um Scrum Master? Qual profissional sua organização precisa? Fique por dentro:

D

Sérgio Salles Galvão Neto [email protected]

Gerente de Projetos certificado PMP, ITIL, Microsoft entre outras.Atuando na área de informática desde 1992 e, a mais de 10 anos liderando equipes em projetos de desenvolvimento e implantação de softwares.Nos últimos cinco anos, atuando como ScrumMaster em projetos em diversas tecnologias e ramos de negócio.

efinir escopo, estabelecer planos para o projeto, criar a lista de atividades e subatividades, estabelecer cronograma, identificar riscos, avaliar e orçar o impacto dos riscos no projeto, calcular os custos humanos e materiais, estabelecer os marcos do projeto, estabelecer os indicadores de acompanhamento do projeto, compor o plano de faturamento ao cliente ou ao patrocinador, administrar o orçamento, criar e manter um plano de comunicação, obter os aceites e interagir com o departamento financeiro da empresa para gerar as faturas e acompanhar a liberação dos pagamentos junto ao cliente, entre outras responsabilidades. Estes são alguns exemplos das atribuições de um Gerente de Projetos segundo o PMI (Project Management Institute). Se ao ler estes pontos descritos anteriormente e não pode reconhecer ou não entender o significado deles é porque talvez não esteja familiarizado com os processos de

Tem sido uma prática constante a publicação de vagas e oportunidades de trabalho para Gerentes de Projeto requerendo conhecimentos em metodologias ágeis e, da mesma forma, os anúncios solicitando profissionais ScrumMaster os quais possuam conhecimentos sobre a metodologia PMI. Estamos abordando dois papéis fundamentais no processo de desenvolvimento de software, porém, as organizações que estão à procura de um profissional devem saber qual papel e quais são os requisitos de conhecimento mais adequados às necessidades da organização. Este artigo visa esclarecer as diferenças entre estes papeis e auxiliar na escolha do papel mais adequado para a organização.

gerenciamento de projetos. Este desconhecimento por parte dos executivos é muito maior do que se imagina. Segundo o relatório anual do Standish Group, o Chaos Manifesto do ano de 2012, o papel do Patrocinador foi questionado, pois caso o Executivo não possua determinadas características, ele não terá condições de atuar em plenitude e poderá colocar em risco ou até condenar


33

os projetos da empresa ao fracasso. No relatório emitido pelo Standish Group, foi dedicado um bom espaço para abordar os principais aspectos dos quais um Executivo deva possuir para poder desempenhar plenamente suas fu nções e elevar o nível de sucesso dos projetos de sistemas como um todo. Em dois tópicos, o relatório do Standish Group abordou a personalidade e a conduta dos patrocinadores e/ou executivos. Dentre todos os tópicos, um dos que chamam à atenção foi o dedicado à avaliação da conduta dos Executivos. Nesta avaliação foram considerados itens como: a personalidade do executivo (uma espécie de DNA de sua maneira de comandar), as experiências do executivo (os diferentes tipos e condições de projetos em que o executivo participou) e, o que é necessário saber para ser tornar um bom executivo (conhecimentos e habilidades). O resultado deste estudo demonstrou 50 pontos, chamados de segredos, que um executivo deve possuir para ser considerado como ótimo. Dentre estes 50 segredos, um dos que mais chama a atenção foi o segredo de número 3 – intitulado como Entendimento dos Processos de Gerenciamento de Projetos. Neste tópico, a avaliação realizada demonstrou o nível de dificuldade de entendimento por parte dos executivos quanto aos processos de gestão de projetos. Apenas 17% dos executivos avaliados consideraram não ter dificuldades em entender os processos de gerenciamento dos projetos ( Figura 1), ou seja, 83% dos executivos não entendem o que está sendo discutido em termos dos processos e respectivas atividades envolvidas. Diante deste cenário, é quase impossível a interação em plenitude de alguém a qual possua a responsabilidade de decidir e ordenar sobre um assunto do qual falta o devido conhecimento. Chaos Manifesto 2012 - The Standish Group % Dificuldade no Entendimento sobre Processos de Gerenciamento de Projetos

17% 11% Muito Difícil Difícil

46%

26%

Pouco Difícil Sem Dificuldade

Figura 1. Percentual de Dificuldade de Entendimento sobre os Processos

Dentro de um projeto, existem papéis e responsabilidades e estes, são a base para a execução do processo. Estamos falando das pessoas, dos membros da equipe os quais serão responsáveis por diferentes partes e em diferentes momentos no decorrer do projeto. Depois de entendermos as metodologias, os papéis de cada um, iremos contextualizar a aplicação do papel do Gerente de Projetos e do ScrumMaster em um projeto de desenvolvimento de software. Desta maneira, os executivos de sua organização terão uma ideia clara do perfil mais adequado a ser contratado de acordo com as suas necessidades, sua realidade operacional. O papel do gerente de projeto, qual o objetivo das metodologias ágeis, o papel do ScrumMaster e, em uma abordagem prática, verificar onde os papéis são corretamente aplicados para a execução de projetos de engenharia de software.

Definição de Projeto Segundo o PMBOK (Project Management Body of Knowledge – livro reconhecido como o Corpo de Conhecimentos sobre Gestão de Projetos), publicado e mantido pela instituição americana PMI (Project Management Institute), em linhas gerais, projeto é um esforço temporário empreendido para alcançar um objetivo específico. Projetos são executados por pessoas, geralmente têm limitações de recursos e são planejados, executados e controlados. Um projeto cria um produto, serviço ou resultado específico. Construir uma nova estrada, uma praça de pedágios, um novo sistema de gestão de recursos, uma escola, um novo serviço de atendimento, são bons exemplos de projetos. Neste momento, é importante ressaltar a diferença entre Projeto e Operação. Operação é uma ação em si, o ato de fazer alguma coisa de forma padronizada e repetitiva, são as ações que sustentam as atividades comerciais. Outro exemplo de projeto, aquele que objetiva alcançar um resultado específico pode ser considerado como um projeto de melhoria. Um projeto sobre algo que já existe e que pode ser modificado de forma a gerar melhores resu ltados ou atender a mudanças de necessidades (requisitos). Agora que o termo projeto está definido, precisamos entender como os projetos são executados / conduzidos. Para tanto, é preciso entender as metodologias voltadas para este tema. Metodologias são conjuntos de processos (ações) e ferramentas que auxiliam na execução de uma determinada atividade.

de Gestão de Projetos

Visão geral sobre Gerenciamento de Projetos Desta forma, se faz necessário entender o propósito dos processos de gestão de projetos, firmando o conhecimento da definição de projeto e as abordagens das metodologias que surgiram com objetivo principal de aumentar as chances de sucesso dos projetos. Em se tratando de Engenharia de Software, de desenvolvimento de sistemas, a adoção destas metodologias vem se tornando cada vez mais indispensável para que se alcancem melhores resultados.

De acordo com o PMBOK , Gerenciar Projetos é a aplicação de um conjunto de conhecimentos, habilidades, ferramentas e técnicas de forma que as atividades do projeto alcancem seus requisitos. Significam os itens imprescindíveis os quais aumentam as chances de sucesso dos projetos de atingirem os objetivos estabelecidos. O PMBOK estabelece que o Gerenciamento de Projetos deve ser realizado através da correta aplicação e integração de

34 Engenharia de Software Magazine - O que faz um Gerente de projetos e um Scrum Master?

PLANEJAMENTO

47 processos organizados e agrupados em cinco grupos de processos. Os cinco grupos de processos são: • Iniciação; • Planejamento; • Execução; • Monitoramento e Controle; • Encerramento. Gerenciar projetos comumente inclui (mas não se lim itam) a: • Identificar requisitos; • Endereçar as diversas necessidades, preocupações e expectativas das Partes Interessadas (Stakeholders) durante o planejamento e execução do projeto; • Estabelecer, manter e distribuir a comunicação entre as partes interessadas, de forma colaborativa e eficaz; • Gerenciar as Partes Interessadas (Stakeholders) no sentido de cumprir os requisitos do projeto e criar os entregáveis (as entregas) do projeto; • Balancear as limitações concorrentes do projeto, que incluem (mas não se limitam) a: - Escopo; - Qualidade; - Prazo; - Orçamento; - Recursos; - Riscos. Nota As limitações do projeto (constraints) estão completamente interligadas e devem estar totalmente balanceadas. Caso uma destas l imitações seja afetada, automaticamente as demais também serão. Por exemplo, se o Escopo for ampliado, consequentemente, será necessário mais tempo (prazo), aumento nos processos de qualidade, aumento no custo (orçamento), aumento do uso dos recursos e, aumentam-se os riscos.

Contexto do Gerenciamento de Projetos De acordo com o PMBOK, podemos ampliar a visão da Gestão de projetos agrupando os projetos através de Programas, Portfólios e o Escritório de Projetos, mais conhecido como PMO (Project Management Office). Programas é uma forma de agrupar projetos relacionados gerenciados de uma maneira coordenada, com objetivo de obter benefícios e controles que não seriam possíveis caso fossem gerenciados individualmente. Para gerir os Programas, existe o conceito de Gerenciamento de Programas. Um bom exemplo de programa seria o desenvolvimento de um novo modelo de carro, onde podem ser criados projetos independentes para seus componentes como motor, cambio, freios, etc. Os programas ainda podem ser decompostos em subprogramas. Os subprogramas geram projetos mais especializados de forma que possam ser mais bem gerenciados. Portfólios são conjuntos de projetos ou de programas os quais são agrupados para facilitar o gerenciamento eficaz do trabalho para alcançar os objetivos estratégicos da organização. Voltando ao exemplo do programa de um novo modelo

de carro, o portfólio pode ser criado para novos modelos de carro do tipo utilitários, ou novos motores, etc. Os Portfólios também podem ser organizados e subdivididos em sub portfólios, de maneira a facilitar a gestão e aumentar a eficiência de seus resultados. O escritório de Projetos, o PMO, é uma estrutura gerencial cuja função é a de padronizar os processos de governança relacionados a projetos. Esta estrutura facilita o compartilhamento de recursos, metodologias, ferramentas e técnicas. Dentre as responsabilidades do PMO estão, desde o suporte aos gerentes de projeto, fornecer treinamento e capacitação, gerir conflitos e até mesmo, responder pela gestão de projetos, portfólios ou programas.

Vantagens em se trabalhar com Projetos A pressão comercial para que as empresas tenham mais lucratividade, reduzindo custos e aumentando a eficiência, potencializado pelos fatores da globalização remetem a necessidade das empresas serem mais ágeis. A estrutura t radicional é altamente burocrática e a experiência tem mostrado que essa estrutura não pode responder de modo suficientemente rápido a um ambiente em constante mudança. Por isso, a estrutura tradicional deve ser substituída pelo gerenciamento de projetos, ou outra estrutura temporária de gestão que seja altamente orgânica e que possa responder muito rapidamente conforme as situações se apresentarem internamente e externamente à empresa. O gerenciamento de projetos tem sido amplamente discutido por executivos e acadêmicos como uma das possibilidades exequíveis para modelos organizacionais futuros que poderiam integrar esforços complexos e reduzir a burocracia. Uma empresa tem como opção trabalhar de forma projetizada (orientada a projetos). Originalmente, as empresas trabalhavam de forma funcional. Uma vez que definimos o conceito de projetos e a maneira com que eles devem ser tratados pelas organizações, cabe o entendimento de como as organizações estão estruturadas e qual deve ser a abordagem para a adoção de uma estrutura orientada a projetos.

Saiba identificar o tipo da Organização onde você trabalha As organizações estabelecem suas estruturas de forma a obterem uma melhor maneira de administrar seus recursos humanos, materiais e financeiros possibilitando atingir de forma mais eficiente seus objetivos comerciais. Basicamente, existem três estruturas organizacionais: funcional, projetizada e a matricial. A estrutura organizacional funcional prega que cada funcionário possui um superior e que as equipes estão organizadas por função exercida (por exemplo: finanças, produção, jurídico). Empresas de menor porte estão mais suscetíveis a adotarem esta estrutura fu ncional como um posto de gasolina, borracharia ou um pequeno comércio. Na estrutura organizacional projetizada, existem os departamentos e cada um deles possui um gestor de projetos para Edição 70 - Engenharia de Software Magazine

35

conduzir seus próprios projetos contando com o apoio de outros departamentos. Esta abordagem traz à tona a questão da concorrência dos recursos dos departamentos de apoio, sendo requisitados simultaneamente pelos gerentes de projetos dos demais departamentos da empresa. Por exemplo, a pessoa responsável pelas aquisições de uma empresa, inevitavelmente, receberá solicitações de compra de diversos gerentes de projetos. Por vezes, receberá solicitações de compras de um mesmo material porém com dias de diferença, fazendo com que o comprador repita, desnecessariamente, todo o processo de compra. Já a estrutura organizacional matricial propõe a mistura entre as estruturas funcional e projetizada. Desta forma, o projeto será conduzido conforme seu grau de relevância, aloca ndo os recursos funcionais necessários. A estrutura matricial pode ainda ter três aspectos: matricial fraca, matricial forte e a matricial balanceada. Para entender melhor cada uma delas, vamos explicar como estão organizadas cada uma delas a seguir. A estrutura matricial fraca mantém o Gerente Funcional (responsável por um setor, unidade organizacional ou grupo de pessoas) com o maior nível de autoridade. O gerente de projetos está subordinado ao gerente funcional e depende dele e dos demais gerentes funcionais para disponibilizarem os recursos humanos e materiais para a execução dos projetos. Já na estrutura matricial forte, o Gerente de Projetos é que tem maior nível de autoridade, alocando os recursos humanos e materiais necessários ou até contratá-los externamente a fim de garantir a execução e entrega dos resultados dos projetos. A estrutura matricial balanceada busca, como o próprio nome diz, balancear as necessidades funcionais e dos projetos dentro da empresa, ou seja, o Gerente Funcional e o Gerente de Projetos possuem o mesmo grau de autoridade. Esta estrutura é pouco utilizada dada a complexidade em sua gestão.

O contexto dos projetos O PMBOK não é considerado como uma metodologia. Apesar do mercado já ter se habituado a chamar de Metodologia de Gestão de Projetos PMI, o foco do PMBOK é concentrar um conjunto de boas práticas e processos, de forma genérica. Fica sob responsabilidade de cada empresa construir sua própria metodologia a qual pode ou não seguir as recomendações que constam no PMBOK. Para ser considerada uma metodologia, a abordagem do PMBOK deveria estabelecer princípios e regras, estabelecendo como exatamente os processos deveriam ser executados quando na verdade, o PMBOK sugere processos, ferramentas e técnicas de forma que a empresa estabeleça as suas próprias regras para executá-los. Considerando o exposto, passamos a estabelecer como premissa que as empresas, aquelas que optaram em trabalhar por projetos, devam manter uma estrutura Matricial Forte. Geralmente, a alta direção da empresa determina uma necessidade interna ou de um cliente, algo precisa ser criado objetivando um resultado específico. Pode ser construir uma nova loja, ampliar instalações, criar uma nova área, implantar

um sistema de gestão (ERP), construir um novo sistema, ela borar um novo site ou uma grande mudança visando atender a objetivos estratégicos da empresa. Ao solicitante ou cliente do projeto dá-se o nome de patrocinador. É o patrocinador que irá usufruir dos resultados alcançados no projeto e, aquele que paga pelo projeto. Mas, não basta saber o que se quer, ter em mente o objetivo esperado é apenas parte do projeto. A partir deste momento, existe uma pessoa a qual deverá transformar este objetivo em um projeto e o profissional mais indicado é o gerente de projetos. Como nosso enfoque é a área de desenvolvimento de software, iremos assumir que trataremos de um projeto de um novo sistema (software). Desta forma, do ponto de vista prático, a alta direção da empresa precisará saber, basicamente, para entrega deste novo sistema a ser desenvolvido, quanto tempo irá levar, quanto custará, como saberá se o novo sistema atenderá às expectativas, quantas etapas ou fases, como e quando serão informados do avanço do projeto, quais e quantas pessoas serão envolvidas, como os problemas serão encaminhados e resolvidos, enfim, serão necessários documentos que definirão todos estes pontos, um informe executivo periódico entre outros documentos. Digamos que este é o modo formal, ou melhor, profissional de se gerenciar projetos conforme consta no PMBOK. O patrocinador e todas as partes interessadas (pessoas afetadas direta ou indiretamente pelo projeto) saberão de todo o andamento, das suas atividades e responsabilidades, a partir das informações, documentos e relatórios emitidos pelo Gerente de Projetos. Percebam que esta forma de condução de projetos é generalista ao ponto de poder ser adotada em projetos de qualquer natureza, desde a construção de uma ponte, de criar uma nova linha de montagem em uma indústria automotiva e, é neste ponto que se destacam as boas práticas sugeridas no PMBOK (PMI) e a necessidade de se criar uma metodologia dentro da empresa a qual estabeleça esta cultura de projetos para que todos os envolvidos estejam integrados em todos os momentos do projeto, entendendo o que está sendo, o que será feito e, principalmente, o que está sendo dito e informado sobre o projeto. Este é o contexto de um projeto.

Entendendo os conceitos de Engenharia de Software Bom, já sabemos o que é um projeto e como ele será conduzido, mas em se tratando de desenvolvimento de software, existe ainda a necessidade de se saber construir software e esta, é uma área bastante abrangente, pois existem diversas maneiras de se fazer software. Digamos que no início da informática, a construção de software estava focada em resolver questões muito científicas e específicas tais como cálculos balísticos, para fins militares. Os computadores não estavam acessíveis ao público em geral, apenas em centros governamentais e científicos como universidades. Com a popularização da informática, o mundo percebeu a capacidade em utilizá-la de forma a reduzir as atividades repetitivas e, nesta ocasião, surgiram os chamados programadores,


PLANEJAMENTO

pessoas as quais detinham o conhecimento para instruir (programar) um computador, através de uma linguagem específica para executar as tarefas determinadas. Nesta ocasião, não existiam métodos ou normas as quais orientasse a construção destes programas. Dada a falta de métodos e de profissionais frente a crescente demanda, no final da década de 1960, instaurou-se a chamada Crise do Software. Para normalizar a prática de desenvolvimento de sistemas, surge a Engenharia de Software trazendo consigo os princípios da engenharia tais como: criação, construção, análise, desenvolvimento e manutenção, com um tratamento mais sistemático e controlado. Com a engenharia de software torna-se possível especificar, projetar, planejar, construir, aferir e garantir a qualidade dos resultados. Com a evolução da engenharia de software, foram criados os chamados modelos de processo de software. Estes modelos visam a melhor representação do gerenciamento do processo de software, trazendo maior visibilidade. Os modelos basicamente determinam o ciclo de vida. Ciclo de vida, como o próprio nome indica, significa a representação de todas as fases desde a concepção até a finalização do software entregue, quando este passa a ser tratado como um produto e será mantido em um regime de operação de manutenção. São exemplos de modelos de processo: • Sequencial ou cascata; • Desenvolvimento iterativo e incremental; • Evolucional ou prototipação; • Modelo em “V”; • Espiral; • Componentizado; • Formal; • Ágil; • RAD.

Podemos verificar que os modelos foram evoluindo na medida em que o tempo e a maturidade foram passando. Conforme foi dito anteriormente, estes modelos foram cr iados para melhorar a visibilidade do gerenciamento do processo de software bem como do gerenciamento do projeto. Esta trajetória de evolução dos modelos passa por diversos níveis de exigência, como geração de documentos, processos de aprovação e validações entre fases. O melhor exemplo é o modelo sequencial (ou cascata) onde uma fase do processo de desenvolvimento de software, só pode ser iniciada após a conclusão e aceite da fase anterior. Este modelo sequencial (cascata) está representado na Figura 2. Já nos modelo iterativo e incremental a proposta é a de que as fases que não possuam dependências diretas podem ser iniciadas em paralelo desde que as aprovações (aceites) ocorram formalmente. A melhor representação deste modelo é demonstrada através do Processo Unif icado (Unified Process). O Processo Unificado propõe a construção do software em partes menores que, ao final, serão integrados para formar um grande sistema. Este padrão de desenvolvimento permite possuir mais equipes trabalhando em diferentes partes do software e de forma integrada. A Figura 3 representa o processo unificado (PU). O PU foi evoluído e popularizado através da empresa Rational (agora pertencente à empresa IBM) através da criação do chamado Rational Unified Process (RUP). A Rational desenvolveu um conjunto de ferramentas as quais representavam todas as fases de forma iterativa com a equipe de desenvolvimento de software onde, além de visualizar os processos era possível armazenar os artefatos gerados como um repositório e ainda navegar por todo seu conteúdo tal qua l um website. Este padrão adota o processo de levant amento e gestão de requisitos (as necessidades do solicitante), ou as fu ncionalidades que serão promovidas pelo software na forma

Figura 2. Modelo Sequencial (Cascata)


37

de casos de uso. Casos de uso são documentos criados para descrever estes requisitos e todas as suas validações como regras de negócio, atores (pessoas envolvidas na utilização do software), cenários (como a funcionalidade deverá ser tratada), fluxos, prototipação, relacionamento com casos de uso, entre outros assuntos que auxil iem no entendimento do que está sendo solicitado. Sendo assim, o ponto central do modelo PU está justamente na correta descrição das funcionalidades através dos requisitos e casos de uso gerados. São documentos que precisam de levantamentos realizados por um analista o qual irá traduzir as necessidades dos solicitantes em um formato adequado para a equipe de desenvolvimento do software. Outro fator interessante foi que o Rational Unified Process (RUP) inseriu a abordagem de gerenciamento de projetos conforme estabelecida pelo Project Management Institute (PMI). É neste momento que a gestão de projetos e a área de Engenharia de Software se unem para oferecer, cada vez mais, visibilidade para as partes interessadas e os patrocinadores do projeto. Em resumo, tornou-se claro que o desenvolvimento do software fazia parte de um projeto. Os modelos de processos e os padrões associados aos modelos de desenvolvimento de software estavam concentrados em guiar as atividades e normatizar o desenvolvimento em si. Por outro lado, um projeto pode possuir mais de um software a desenvolver e ainda cuidar de outras atividades relacionadas ao projeto como a aquisição de um imóvel, mobiliário e infraestrutura para receber a nova equipe que irá operar o novo software que está sendo desenvolvido no projeto. Ainda em se tratando de Modelos Iterativos, existem também os modelos Ágeis (Agile) nos quais são oferecidos um conjunto de práticas que permitem a produção de software de maneira mais rápida e eficaz. A base do desenvolvimento ágil consiste em um manifesto, chamado de Manifesto Ágil. A partir deste

Figura 3. Modelo Iterativo (Unified Process)

manifesto ágil surgiram várias metodologias tais como Scrum, Extreme Programming (XP), entre outras. O conteúdo deste Manifesto diz: “Manifesto para Desenvolvimento Ágil de Software Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros a fazerem o mesmo. Através deste trabalho, passamos a valorizar: • Indivíduos e interações 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 Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.” Tomando como base o que descrevemos anteriormente sobre o PU, percebemos a ruptura na necessidade de tantos processos e iterações, documentos e aprovações quando na realidade o objetivo é a entrega de um software funcionando. Construir um software o qual atenda às expectativas deve ser feito através do contato direto entre a equipe de desenvolvimento e o próprio solicitante (cliente). É importante lembrar que esta forma de construir software só é possível graças à evolução e maturidade das tec nologias e da cultura das pessoas envolvidas. Nas décadas de 90 e início dos anos 2000, podemos dizer que a tecnologia até via bilizaria a adoção de uma metodologia ágil mas a cultura das pessoas, principalmente daquelas pessoas que contratavam a construção de um software, estava muito longe. Tomemos como exemplo a compra de um carro. Seria ótimo poder chegar numa concessionária e dizer todos os requisitos desejados em um novo carro e, numa linha de montagem, estes requisitos iriam sendo adicionados como rádio, bancos de couro, ar condicionado, entre outros mas, e quando chegasse ao ponto da escolha do motor? Câmbio? Sistema de Freios? Tração? Suspensão? Neste ponto seriam exigidos conhecimentos muito mais profundos e técnicos os quais, nem todas as pessoas possuem. Em se tratando de software, seria a mesma situação onde o solicitante poderia ser questionado sobre temas que ele não conhece e nem pretende conhecer devido a sua própria formação ou profissão. Retornando ao ponto sobre os processos e modelos, quando abordamos o tema dos processos


PLANEJAMENTO

ágeis, mais uma vez, temos a clara visão de que a construção do software possui necessidades específicas para garantir mais flexibilidade e qualidade na entrega do software funcionando, que o software funcione conforme as expectativas de quem o solicitou. E o projeto? Qual seria o papel do projeto sendo que na verdade o item desejado é o software entreg ue e funcionando. O papel do projeto é de disponibilizar controles e envolvimento das partes interessadas a fim de garantir que todo o processo de desenvolvimento de software, seja ele ágil ou não, funcione perfeitamente.

Um projeto formal pode ser ágil? A resposta é sim, definitivamente. A base de um método ágil é o de abolir burocracias que dificultam atingir um determinado objetivo. Em nosso caso, estamos falando de construir software e é totalmente possível entregar software, de qualidade, funcionando conforme as expectativas de forma ágil e documentada de maneira mínima e necessária. A Engenharia de Software, com seus processos e modelos permitiu o surgimento dos chamados modelos de maturidade. Maturidade se resume na adoção das reconhecidas boas práticas da engenharia de soft ware (metodologias, processos, ferramentas e técnicas) aplicadas pelas empresas que produzem software. O modelo de maturidade mais reconhecido mundialmente é o CMMI (Capability Maturity Model Integration) criado pelo Software Engineering Institute – SEI.

Como referência em termos da maturidade no desenvolvimento de software, o modelo CMMI aceita plenamente a adoção de metodologias ágeis desde que estas não interfiram ou deixem de lado o cumprimento das boas práticas como registros e controles. O modelo CMMI fornece um conjunto de boas práticas geralmente aplicáveis em grandes projetos que possuam altos níveis de risco e ainda, oferece um conjunto de práticas de gestão e suporte para implantação dos métodos ágeis nas empresas, independentemente do tamanho dos projetos. Não cabe neste artigo o detalhamento sobre o Modelo CMMI. Recomendamos o artigo “CMMI: Uma visão Geral” publicado na edição número 44. O importante é ter em mente o fato de que a matu ridade pode e deve andar em conjunto com a agilidade. Da mesma forma que o modelo CMMI prevê e apoia a adoção das metodologias ágeis, o PMI (Project Management Institute) também as reconhece. Em 2011 o PMI lançou uma nova certificação voltada aos praticantes dos métodos ágeis chamada de PMI-ACP ( Agile Certified Practitioner ou Praticante de Agile Certificado). Esta certificação visa demonstrar ao mercado (empregadores) o nível de profissionalismo em práticas Ágeis na gestão de projetos pelo praticante (profissional), aumentar a versatilidade do profissional em ferramentas e técnicas de gestão de projetos, aliada com a capacidade de liderança de equipes ágeis e a disponibilização de uma estrutura voltada à treinamentos e iniciativas de desenvolvimento profissional.


39

Em resumo, as práticas ágeis podem e devem ser ass ociadas a processos formais de gestão de projetos. Isto não significa abrir mão da rapidez que as práticas ágeis oferecem sem perder o controle, qualidade e visibilidade oferecidas pela gestão de projetos formal. Porém, tanto as práticas ágeis bem como o gerenciamento de projetos formal, por si só, não garantem a eficiência e eficácia do resultado. Precisamos separar as áreas e demonstrar o funcionamento destas práticas para elucidar o contexto de desenvolvimento de software na vida real.

Gestão de Projetos e Métodos Ágeis na prática Falamos anteriormente da existência das empresas e como estas estão normalmente estruturadas. Agora é necessário que o leitor identifique se a empresa em que está trabalhando é do tipo funcional, projetizada ou matricial para enxergar os paralelos e comparações a seguir. Vamos estabelecer um cenário onde apresentaremos a aplicação dos conceitos de gestão de projetos e práticas ágeis. Você trabalha numa empresa voltada ao desenvolvimento de software, é do tipo matricial forte onde o gerente de pro jetos possui a autoridade necessária para acionar os demais gerentes funcionais e garantir que os projetos sejam executados seguindo a metodologia definida pela empresa. Esta metodologia inclui a gestão de projetos formal (seguindo as recomendações do PMBOK do PMI) bem como as boas práticas da área de engenharia de software, entre elas o uso das práticas ágeis do Scrum conforme sugeridas pelo modelo CMMI. Não entraremos no mérito da empresa estar ou não certif icada em um dos níveis de maturidade do CMMI. Sua empresa venceu uma concorrência para desenvolver um software de gestão para um cliente do ramo de mineração. Este projeto foi concebido a partir da apresentação de uma solicitação de proposta (RFP – Request For Proposal) onde foram recebidas as informações como escopo, prazo, qualidade. Esta solicitação foi recebida pela área comercial da s ua empresa e, foi encaminhada ao time de orçamento. Este time de orçamento é composto por membros da equipe comercial, do gerente de projetos e até da alta direção da sua empresa. O Gerente de Projetos em conjunto com as equipes funcionais fizeram a análise das solicitações da empresa de mineração, definiram um plano de projeto contendo: escopo, premissas, restrições, custos, riscos, controle e garantia da qualidade, controle de solicitações de mudanças, plano de comunicação, gestão das partes interessadas, controle dos contratos de terceirizadas, gestão dos recursos, enf im, todos os tópicos descritos na metodologia da empresa que tomaram como base o PMBOK. E além disso, irão adotar a metodologia ágil Scrum. Neste documento de plano de projeto, já se sabe, em linhas gerais, o que precisa ser feito e como, quando será feito e por quem. De posse destas informações, a equipe comercial pode gerar uma proposta contendo valores e condições. Chega a notícia de que a sua empresa foi escolhida pela empresa de mineração para desenvolver o sistema de gestão solicitado por ela. Neste momento, o Gerente de Projetos entra em cena para alocação dos recursos e dar início ao projeto.

Faz-se uma revisão do plano do projeto para garantir que tudo o que estava na proposta comercial está contemplado no plano e então é feita a reunião de início (Kick-off). As providencias administrativas são iniciadas, os recursos alocados e, o time de desenvolvimento faz a revisão das estórias liderados pelo ScrumMaster, organizam o backlog de estórias e planejam as Sprints. Para iniciar o desenvolvimento do sistema, a primeira coisa que o time de desenvolvimento precisará é do envolvimento do cliente (as pessoas elencadas pela empresa de mineração) para refinar e desenvolver as estórias. Neste meio tempo, o gerente do projeto está providenciando contratos, contratações de pessoas e materiais necessários para a execução do projeto. Durante o planejamento da Sprint, o ScrumMaster e a equipe de desenvolvimento não conseguem total disponibilidade do cliente. Um impedimento é registrado na reunião e o ScrumMaster aciona o Gerente do Projeto por telefone. O Gerente de Projeto, verifica no plano do projeto e identifica no plano de comunicação e na matriz de responsabilidades quem é a pessoa responsável do lado do cliente em resolver este problema. O Gerente de Projeto entra em contato com esta pessoa, explica a situação e solicita um encaminhamento. Passado um breve período, o cliente assume que não havia entendido corretamente e que os recursos estarão disponíveis no próximo dia. Conforme o entendimento telefônico, o gerente de projetos registra a ocorrência no formato previsto da metodologia da empresa e acompanha a solução do impedimento junto ao ScrumMaster. No dia seguinte as pessoas definidas pelo cliente chegam à empresa e desempenham o papel necessár io para iniciar as atividades de desenvolvimento junto ao ScrumMaster e a equipe. O impedimento é removido, registrado na reunião diária e o processo de desenvolvimento segue, sem maiores problemas. De acordo com a evolução das sprints, o ScrumMaster envolve e reporta o Gerente de Projetos quanto ao andamento e, o Gerente de Projetos por sua vez emite os relatórios e os documentos de aceite obrigatórios na liberação dos pagamentos e início das próximas fases. O ScrumMaster e a equipe de desenvolvimento também registram as mudanças no backlog, as reuniões de retrospectiva, planejamento das sprints seguintes. Ao final do prazo acordado, a equipe de desenvolvimento da sua empresa entrega o sistema de gestão em funcionamento, conforme as expectativas definidas pela empresa de mineração e o projeto é dado como finalizado com sucesso, entrando em produção e em operação gerando os benefícios esperados. Enfim, temos um caso de projeto bem sucedido utilizando o processo formal e o ágil de desenvolvimento de software em harmonia.

Entendendo os Papéis do Gerente de Projetos e do ScrumMaster Com o sucesso comprovado de resultados ao se adotar as metodologias ágeis, algumas empresas passaram a entender que o papel do ScrumMaster seria suficiente para executar os projetos. Da mesma forma que outras empresas também


PLANEJAMENTO

passaram a entender que um Gerente de Projetos também poderia assumir a função de ScrumMaster. Diante da novidade e, por vezes, da falta de informações podemos considerar natural que esta confusão entre papéis ocorram. Segundo o PMBOK (PMI), o papel do gerente de projetos é a pessoa definida por uma organização responsável por garantir que os resultados (objetivos) do projeto sejam alcançados. Diferentemente dos gerentes funcionais (responsáveis por equipes funcionais ou unidades de negócio específicas) ou dos gerentes operacionais (responsáveis por garantir a eficiência das operações comerciais). Um Gerente de Projetos possui responsabilidades e competências próprias. Destacamos entre as responsabilidades do Gerente de Projetos a responsabilidade de atender às necessidades das tarefas, das equipes e dos indivíduos, funcionando como um elo entre a equipe e a estratégia pois, é através dos projetos que as empresa s podem crescer e se manterem atendendo as crescentes e variadas demandas do mercado. Um Gerente de Projeto precisa deter muito mais do que conhecimentos sobre ferramentas e técnicas, deve aliar a prática e ainda possuir habilidades gerenciais (soft skills) tais como: liderança, motivação, possuir boa comunicação, influenciador, tomada de decisão, confiabilidade, gestão de conflitos, orientação, entre outros. O papel do ScrumMaster, diferentemente do Gerente de Pro jeto, é o de facilitar o caminho da equipe para que esta possa concluir os objetivos da Sprint, removendo impedimentos, impedindo que influencias externas atrapalhem o andamento das atividades, mantendo o foco da equipe. Além disso, o ScrumMaster é o responsável pela aplicação correta das práticas do Scrum, capacitando e motivando a equipe, promovendo as adaptações necessárias ao processo de desenvolvimento de software. Não precisa necessariamente ser um Líder da equipe de desenvolvimento, mas por outro lado, assume para si o papel de ponto focal entre a equipe e os demais envolvidos no projeto como o Gerente de Projetos e o Cliente. Percebemos que algumas empresas, ao publicarem vagas e oportunidades de emprego vem exigindo, cada vez mais, que tanto o Gerente de Projetos possua conhecimento e experiência com Scrum e práticas ágeis bem como, exigindo do

ScrumMaster que possua conhecimentos e experiência sobre gestão de projetos. Entretanto, é importante deixar claro que os papeis do Gerente de Projetos e do ScrumMaster são bem distintos e não deveriam ser confundidos. Do ponto de vista prático, conforme expusemos neste artigo, um Gerente de Projetos possui muitas responsabilidades as quais, vão muito além de cuidar e garantir que o software seja entregue conforme o combinado e, não pode ficar junto da equipe aguardando que impedimentos ocorram para poder resolvê-los. Da mesma forma, não seria justo que um ScrumMaster deixasse de resolver os impedimentos apresentados pela equipe enquanto produz relatórios ou está em reunião junto ao cliente para aprovação de pagamentos. Links: The Standish Group – responsável pela emissão do relatório anual “Chaos Manifesto” http://blog.standishgroup.com/

Relatório Chaos Manifesto 2011 http://versionone.com/assets/img/files/ChaosManifest_2011.pdf

Relatório Chaos Manifesto 2012 http://versionone.com/assets/img/files/CHAOSManifesto2012.pdf

Relatório Chaos Manifesto 2013 http://versionone.com/assets/img/files/ChaosManifesto2013.pdf

Project Management Institute (PMI) www.pmi.org

Sobre a Certificação PMI-ACP (Agile Certified Practitioner) http://www.pmi.org/Certification/~/media/Files/PDF/Agile/PMI_Agile_Certification_Content_Outline.ashx



41

Engenharia Nesta seção você encontra artigos voltados para testes, processo, modelos, documentação, entre outros

Entendendo o Teste de Software por Amostragem Como utilizar amostragem em teste de software Fique por dentro:

A

Célia Negrini [email protected]

Graduada em Análise de Sistemas, cursando MBA de Engenharia de Software na FIAP, certificada pela ISTQB (Certified Tester Foundation Level) e pela Scrum Alliance (CSM- Certified Scrum Master), com 13 anos de atuação na área de tecnologia, sendo os últimos 8 anos dedicados a Qualidade de Software. Atualmente coordenadora de testes e qualidade na empresa VALID Certificadora Digital.

técnica de teste por amostragem tem como principal objetivo permitir a inferência estatística em atividades de teste. Devido à impossibilidade de considerar todos os dados de um sistema, é retirado um dado amostral que será utilizado como base e a partir dele serão realizadas conclusões prováveis em maior ou menor grau, dependendo do número de dados considerados e como essa seleção foi feita, gerando assim conclusões incertas. Entretanto, quando essas informações são avaliadas seguindo certos princípios que regem uma pesquisa, o grau de incerteza da inferência estatística pode ser mensurado. Para realizar a mensuração do grau de incerteza envolvido é utilizada a teoria da Probabilidade, que é uma importante área da matemática que tem por finalidade modelar a ocorrência de eventos potenciais de um experimento aleatório (resultados que não seguem um modelo

42 Engenharia de Software Magazine - Entendendo o Teste de Software por Amostragem

A amostragem é geralmente utilizada quando um conjunto de dados é muito grande para ser avaliado em sua totalidade, com isso espera-se chegar a conclusões válidas sobre um conjunto de dados grande quando utilizado apenas um dado amostral. Para que isso aconteça, a amostra deve ser representativa, ou seja, ao utilizar um pequeno número de elementos, deve ser possível a partir das informações obtidas chegar a conclusões sobre o conjunto de dados maior. A amostragem é utilizada em diversos segmentos, mas quando pensamos em teste de software, qual seria a melhor maneira de utilizá-la? Entender e distinguir os métodos de amostragem é o desafio que iremos explorar com esse artigo. Sendo assim, este artigo é útil para quem quer ter uma visão geral de como a amostragem estatística pode ser aplicada à qualidade de software.

padrão, mas estão todos presentes no espaço amostral). Podemos utilizar a técnica de teste amostral de diversas formas, uma delas é se baseando nos casos de testes existentes, porém é preciso tomar cuidado, pois para atingir a expectativa é necessário que esses casos de testes sejam

ENGENHARIA

criados de forma eficiente e objetiva, senão a amostra não será representativa o suficiente. As técnicas de amostragem são utilizadas geralmente por motivo de auditoria ou teste de regressão, mas nada impede que seja implementada nas atividades diárias de um testador. Pode ser utilizada para testar um caso de teste específico como, por exemplo, um caso de teste que avalia u m determinado campo e este possui muitas var iações. Nessa situação, as técnicas de amostragem auxiliam a determinar quais informações serão inseridas para que não seja necessár io inserir todos os dados possíveis para realizar o teste. Para utilizarmos de forma coerente a técnica de testes por amostragem é preciso ter certa experiência no software que será testado, ou seja, ao menos uma navegação deve ter sido feita na aplicação. Esse teste preliminar precisa acontecer para que tenhamos conhecimento das áreas mais críticas do sistema e então saibamos dividir nossa amostra de forma proporcional a atingir os pontos desejados tentando ser o menos incerto possível. Desta forma seremos capazes de saber como e onde tirar boas amostras do que é preciso testar. Se tomarmos como base o que é feito em outras áreas de conhecimento, antes de investirem tempo e dinheiro em um determinado solo, água, etc., primeiramente é retirada uma pequena amostra do que precisa ser avaliado e a partir dessa informação analisa-se se o solo é fértil, se a água é impura e assim por diante, concentrando então seus esforços nos pontos avaliados, conforme o resultado obtido. Com os analistas de testes funciona da mesma forma; ao utilizar técnicas de amostragem tomando como base o risco, concentram o tempo de teste nesses pontos, otimizando assim seus testes. Isso é muito utilizado quando o tempo disponível é pequeno e a quantidade a ser testada é grande e com muitas variações gerando assim muitas combinações. Com base nos resultados da amostragem podem ser realizados testes adicionais para encontrar mais defeitos nos pontos mais críticos. Avaliar ou estimar atributos ou características de todo o sistema através de uma amostra representativa pode ser mai s eficiente enquanto continua a fornecer as informações necessárias. Mas para que isso seja possível, é preciso primeira mente entender o que é e como utilizar cada técnica de amostragem. Desta forma, exploraremos a seguir quatro métodos de amostragem estatística e dois não estatísticos.

Amostragem aleatória simples A amostragem aleatória simples é o tipo de amostragem mais utilizada. Neste método, cada item de um grupo de dados tem a mesma probabilidade de ser selecionado como parte da amostra, assim como qualquer outro item. Com isso é possível determinar que realizando verificações aleatoriamente é possível chegar a diferentes combinações. Trazendo essa técnica para a área de qualidade de software, podemos dizer que essa amostragem auxilia e até agiliza na detecção de defeitos. Geralmente utilizada quando os dados que precisam ser testados são volumosos e o tempo disponível é pequeno, isso não significa que o analista de teste não estava

igualmente interessado em todos os dados possíveis de s erem inseridos ou casos de testes existentes, pelo contrário, o desejo sempre é executar cada um deles, mas a escolha pela amostra acontece por razões práticas, ou seja, é utilizada quando um dado a ser testado tem tantas variações (em algun s casos pode chegar a milhões) que seria impossível checar até mesmo a maior parte deles. Mas podem acontecer situações em que a quantidade não chegue na casa dos milhões, nem dos mil, mas mesmo assim possui uma quantidade de variações considerável, com isso a escolha pela a mostragem pode ser uma decisão prudente, considerando o cenário existente na organização e o prazo estipulado para entrega do teste. Uma das vantagens de se utilizar a abordagem de teste aleatório ocorre quando um programa já foi testado diversas vezes com base em um mesmo conju nto de entradas de teste. Em situações como essa ele se torna mais preparado apenas para o conjunto testado e não com outras possíveis variações, com isso, quando utilizamos a abordagem da amostragem aleatória, onde a cada momento podemos ter dados diferentes, a probabilidade de encontrar erros e de se ter um sistema mais estável é maior. Outra vantagem está na facilidade de se gerar conjuntos de teste do tamanho desejado por meio de amostragem aleatória. Esta flexibilidade permite que a quantidade de teste a ser executada possa ser adaptada para o tempo e para o orçamento disponível. No entanto, a amostragem aleatória quando utilizada para um tipo de entrada específica, pode não ser tão eficiente quanto a um teste estrutural. O teste estrutural utiliza o código fonte do software para orientar a seleção dos dados de teste, as entradas de teste são escolhidas de modo que cada membro de um conjunto escolhido de elementos, por exemplo, a cobertura do conjunto de declarações, desvios condicionais, ou caminho é exercido por pelo menos um caso de teste no conjunto de teste. É projetado de forma a distribuir eficientemente o esforço de teste em todo o código do software com uma abordagem que a técnica de testes aleatórios não possui. Por esse motivo, deve-se tomar cuidado e realizar uma análise prévia para avaliar se a fase que o software se encontra é a adequada para se aplicar uma das técnicas de amostragem. Seguem alguns exemplos que poderão auxiliar na hora de realizar esse tipo de análise. Exemplo1: Um testador poderia sortear 10 entradas para um caso de teste a partir de todas as possíveis entradas válidas de um intervalo de 1-500 que tem por objetivo avaliar o comportamento de um campo numérico. Para fazer a escolha dos 10 números que serão testados, o testador poderá utilizar um software que faz a geração de números aleatórios, ou então escrever os 500 números em um pedaço de papel e realizar o sorteio de 10, ou quem sabe pedir para algum colega falar 10 números no intervalo de 1-500, ou até utilizar-se do Excel. Tudo vai depender da quantidade de números que se tem para esse teste amostral, para então descobrir qual será a melhor maneira de tirar essa amostra. O importante aqui é ressaltar que dos 500 números possíveis, todos têm a mesma chance de ser escolhido. Mesmo que as pessoas tendem a evitar combinações Edição 70 - Engenharia de Software Magazine

43

como 1-2-3-4-5-6-7-8-9-10, ela tem a mesma chance de ser um conjunto vencedor de números como a combinação de 8-1522-29-69-97-103-301-303-402. A amostragem aleatória simples é um método, como o próprio nome diz, simples e a teoria por trás está bem estabelecida. Existem fórmulas padrão para determinar o tamanho da amostra, as estimativas e assim por diante, e estas fórmulas são fáceis de utilizar. Exemplo2: Agora vamos imaginar um software que precisa

sofrer regressão e que possui um milhão de casos de testes para serem executados, ou seja, se forem executados 1000 testes seria possível ter apenas 0,001% de cobertura da aplicação. Para casos como esse é preciso determinar qual o nível de segurança que é desejado para essa execução e a partir daí deter minar o tamanho da amostra que será utilizada para então garantir a qualidade da aplicação. Para isso, é preciso primeiro definir uma meta de qualidade que queremos garantir, vamos supor que a meta de qualidade seja 99% livre de bugs, isso signif ica que teremos 1% de chance das funcionalidades da aplicação falharem. Para determinar nossa amostra, vamos utilizar do mesmo trabalho matemático que é utilizado em pesquisas em modo geral. A primeira pergunta que precisa de resposta é: Quantas amostras precisamos para 1 milhão de casos de testes se queremos ter uma margem de apenas 1% de falha? Existem muitas calculadoras disponíveis online e gratuitas que auxiliam a determinar o tamanho da amostra. Utilizando dessa abordagem, foi possível chegar no número 16.317 de casos de testes que precisam ser executados para garantir 99% de confiança. Se no final da execução dos 16.317 casos de testes for obtido 100% de sucesso, é possível então estabelecer uma confiança de 99% para uma margem de 1% de erro. Mas se ao final não for obtido uma margem de sucesso de 100% na execução é preciso então avaliar os pontos mais críticos e realizar uma nova amostragem com base nesses pontos e avaliar se outra técnica se faz necessária. Voltando a considerar que 100% dos 16.317 casos de testes executados obtiveram sucesso, vamos utilizar dessa mesma abordagem para realizar comparações da quantidade de testes X Número de amostras necessárias. Observe a Tabela 1 , onde o objetivo é o mesmo, estabelecer 99% de confiança para 1% de erro. 99% de Confiança para 1% de falha Casos de Testes a serem executados

Número de amostras necessárias

100

99

1.000

944

10.000

6239

100.000

14.228

1.000.000

16.317

Tabela 1. Número de amostras conforme a quantidade de testes que

precisam ser executados

Com a comparação da tabela é possível identificar que aos poucos testes adicionais são necessários para alcançar o mesmo nível de qualidade para um software cada vez mais complexo. Existe também a possibilidade de se calcular a probabilidade de um certo dado ser selecionado com base na amostra total que possui. Supondo que existam 1000 casos de testes criados para determinado projeto e com base na técnica anterior foi estabelecido que 944 precisam ser executados, qual a proba bilidade de um caso de teste ser executado? O cálculo nesse caso é bem simples, uma vez que o tamanho da amostra (n) e a população total (N), o cálculo da probabilidade de um caso de teste ser incluído na amostra torna-se uma simples questão de divisão. Probabilidade de ser selecionado: = (n ÷ N) x 100% = (944 ÷ 1000) x 100% = 94,4% Isto indica que cada caso de teste tem 94,4% de chances de ser selecionado. Uma desvantagem da amostragem aleatória ocorre qua ndo mesmo você sabendo que seus casos de testes são divididos por casos de uso, onde você pode ter uma variação de quantidade conforme o caso de uso, onde um caso de uso pode ter 20 casos de testes e outro 200 casos de testes, não utilizamos essas informações no momento de determinar a amostra. Com isso, pode acontecer de não termos uma amostra tão representativa quanto a desejada. Nesses casos, vale a pena avaliar se outra técnica por amostragem não seria mais adequada.

Amostragem estratificada A amostragem estratificada tem sido amplamente estudada e utilizada desde a década de 1950. Há muitos livros a respeito da amostragem estratificada. No entanto, tanto qua nto é sabido, a amostragem estratificada não tem sido aplicada no campo da engenharia de confiabilidade de software. A amostragem estratificada foi conhecida como um método de amostragem complexa, diferentemente do que vimos no tópico anterior, o que poderia tornar os resultados de amostragem mais precisa. Ela funciona da seguinte forma, ao menos um representante de cada subgrupo dentro do contexto do sistema precisa ser representado na amostra. Com isso é determinado que o primeiro passo para utilizar essa técnica de amostragem é dividi-la em subgrupos, como podemos observar na Figura1 , em seguida são retiradas amostras aleatórias de cada subgrupo criado. O percentual de amostragem para cada subgrupo pode ser definido da mesma forma que o subgrupo tem de proporção dentro do sistema. Exemplo 1: Vamos supor que o teste que precisa ser feito é referente a uma base de clientes, onde conforme o perfil do cliente uma variação acontece na aplicação e ela precisa ser testada. Após realizar um levantamento é identificado que: 70% dos clientes são caracterizados como público em geral,


ENGENHARIA

30% possuem investimentos financeiros acima de 100mil e 10% possuem investimentos financeiros acima de 1 milhão. A partir das informações obtidas, iremos utilizar uma quantidade de cada grupo de clientes conforme sua proporção dentro da aplicação. Com isso poderíamos considerar nos testes 50 cadastros de clientes do público em geral, 20 cadastros de clientes com investimentos financeiros acima de 100 mil e cinco cadastros de clientes que possuem investimentos financeiros acima de 1 milhão. A amostragem estratificada também pode provar igual número de itens de cada subgrupo. Com isso, teremos uma amostra aleatória dentro de um mesmo sistema, mas de um público diferente, o que aumenta a probabilidade de se ter uma amostra mais eficiente.

Figura 1. Divisão da amostragem em subgrupos – Crédito: Anderson

Vieira

Porém, existem desvantagens em se utilizar a amostragem estratificada, uma delas é o fato de ter que separar em gr upos cada item de interesse antes de se tirar a amostra requerida. O outro ponto de atenção é o cuidado que é preci so ter no momento de separar os grupos da amostra, pois algumas variáveis podem estar relacionadas com alguns pontos, mas não para os outros, o que complica e potencialmente reduz a utilidade dos estratos. Outro cuidado que é preciso ter é que em alguns casos (como projetos com um g rande número de estratos, ou aqueles com um tamanho de amostra mínima especificada por grupo), amostragem estratificada pode requerer uma amostra maior do que outros métodos. Exemplo2: Uma base de clientes de aproximadamente 100.000 registros possui aproximadamente 500 clientes com um perfil de “Cliente preferencial”, desta forma dependendo da estratificação que for feita, se essa informação sequer for considerada é provável que esses clientes não estejam presentes em nenhum dos estratos. Com isso, é válido ressaltar que a amostragem estratificada procura assegurar que a amostra terá a proporção equivalente do que é desejado para a análise ou teste que precisa ser feito, então é preciso tomar o cuidado de no momento de separar os estratos considerar para ao menos um deles os clientes com o perfil “Cliente Preferencial”.

Com isso poderíamos determinar por exemplo que a amostra deverá conter cerca de três clientes preferenciais em uma amostra de 1000 registros (300: 100000 = 3:1000).

Amostragem sistemática Amostragem sistemática é outro método de amostragem estatística. Um tipo de método de amostragem probabilística em que os membros da amostra de uma população maior são selecionados de acordo com um ponto de partida aleatório e um intervalo fixo, porém periódico. Este intervalo de tempo define o intervalo de amostragem que é calculada dividindo-se o tamanho da população pelo tamanho da amostra desejada. Apesar da população da amostra ser selecionada com antecedência, a amostragem sistemática é considerada aleatória, pois apesar do intervalo ser periódico, o ponto de partida é aleatório. Para iniciar uma amostra sistemática é preciso seguir os passos: 1. É preciso saber qual a quantidade de amostra que deseja avaliar, por exemplo de 1 a N (onde N é o tamanho total); 2. Determinar o intervalo de amostragem (K), para isso basta dividir o número de unidades na população pelo taman ho da amostra desejada. Por exemplo, para selecionar uma amostra de 100 a partir de uma população de 500, você precisaria de um intervalo de amostragem de 500 ÷ 100 = 5. Portanto, K = 5. Com isso a seleção deverá ser feita a cada cinco un idades para acabar com um total de 100 unidades em sua amostra; 3. Escolha um número entre 1 e K aleatoriamente. Este número é chamado de início aleatório e seria o primeiro número incluído na sua amostra. Usando o exemplo acima, você deve selecionar um número entre 1 e 5 a partir de uma tabela de números aleatórios. Se você escolher 3, a terceira unidade em seu quadro seria a primeira unidade incluído na sua amostra; se você escolher 2, a sua amostra começaria com a segunda unidade em seu quadro; 4. Selecionar a cada K a próxima unidade da série. Com base nos exemplos acima, poderíamos formar a amostra de 100 com início aleatório escolhido em 3. Então teríamos: 3, 8, 13, 18, 23... 495, 500. Usando o exemplo acima, é possível identificar que podemos ter apenas 5 possíveis amostras que podem ser selecionadas com as cinco correspondentes partidas aleatórias possíveis: 1, 6, 11, 16... 491, 496 2, 7, 12, 17... 492, 497 3, 8, 13, 18... 493, 498 4, 9, 14, 19... 494, 499 5,10,15,20.....495, 500 Com isso é possível identificar que cada membro da população pertence a apenas uma das cinco amostras e cada amostra tem a mesma chance de ser selecionada, com isso cada unidade da amostra tem apenas uma chance em cinco. Essa é a mesma probabilidade de uma amostra aleatória simples, com a diferença que na amostragem aleatória simples, qualquer combinação de 100 unidades teria uma chance de fazer parte Edição 70 - Engenharia de Software Magazine

45

da amostra, enquanto que com amostragem sistemática, há apenas cinco possíveis amostras. Em teste de software essa técnica também pode ser muito aproveitada, conforme temos nos exemplos apresentados a seguir. Exemplo 1: Você precisa selecionar ao menos 1000 casos de testes aleatórios, considerando um total de 50.000 casos de testes existentes, utilizando a amostragem sistemática, seria simplesmente selecionar 50 casos de testes em cada g rupo de 1000 casos, já que 50.000 / 1000 = 50. Cuidados devem ser tomados quando se utiliza amostragem sistemática para garantir que a lista da população original não tenha sido ordenada de uma forma que apresenta quaisquer fatores não aleatórios na amostragem. Após isso determinaríamos um início aleatório em 5, por exemplo, então teríamos que executar os casos de testes 5, 55, 105, ... Exemplo 2: Em uma auditoria é solicitado realizar um teste de aceitação na aplicação com base nos casos de testes existentes, o auditor define que deseja executar os c asos de testes um intervalo de 15 casos de testes e deseja iniciar do caso de teste 5 de uma lista aleatória de todos os casos de testes existentes. Desta forma, o auditor então iniciaria do caso de teste 5, em seguida 20, 35, 50 e assim por diante até realizar o ciclo completo. A vantagem da amostragem sistemática é que a seleção da amostra é fácil (é preciso apenas selecionar um número aleatório no início, o resto da amostra segue automaticamente) e a amostra é distribuída uniformemente sobre a população desejada. A maior desvantagem do método de amostragem sistemática é que se existe algum ciclo na população e esse ciclo coincide de alguma forma com o intervalo de amostragem, os possíveis exemplos podem não ser representativos. Isto pode ser visto no exemplo a seguir. Exemplo 3: Vamos supor que é necessário executar uma grande quantidade de testes em uma aplicação que possui diversos módulos, entre eles: Administrativo, Operacional e Gerencial. Cada módulo tem aproximadamente 1000 casos de testes, incluindo testes vitais na aplicação (totalizando 3000 casos de testes). Ao ordenar a lista por módulo, considerando um teste vital como início da sua amostragem, em seguida os outros casos de testes, utilizando-se da abordagem de amostragem sistemática tendo um intervalo de 50, pode acontecer de executar apenas os casos de testes vitais de um módulo, ou então apenas os casos de testes não vitais de cada módulo. Com isso, esse tipo de amostra não iria fornecer a visão completa ou adequada da condição de cada módulo.

em critérios de seleção como na amostragem estratificada, a amostragem por cluster é o mais heterogênea possível, ou seja, uma amostra aleatória precisa ser feita dentro de um ou mais grupos selecionados. Esse tipo de amostragem é utilizada em teste de software como uma técnica de seleção que tem por objetivo poupar esforços, melhorar a visualização dos resultados, reduzir o tamanho dos testes e otimizar a detecção de falhas. A amostragem por conglomerado é dividida em duas fases, na primeira é necessário escolher as áreas que serão avaliadas, na segunda é feita uma seleção aleatória dentro de cada área escolhida. Exemplo 1: A organização tem mais de 20 projetos em fase de testes, um novo gestor de Qualidade procura saber qual a conformidade dos testes que são aplicados utilizando-se de amostragem por conglomerado, com isso ele seleciona aleatoriamente cinco projetos como representantes em sua análise, a partir desses cinco projetos ele determina quais serão os pontos que ele deseja visualizar, que podem ser desde o grau de cobertura (baseando-se em casos de testes ou não), percentual de testes automatizados e demais itens de interesse da organização

Amostragem por conglomerado ou cluster

Amostragem de julgamento

O quarto método de amostragem estatística é chamado de amostragem por conglomerados, também conhecida como amostragem por bloco ou Cluster. Nesse tipo de amost ragem a população que está sendo amostrada é dividida em grupos chamados clusters. Nesse tipo de amostragem, ao invés dos subgrupos serem gerados de forma homogênea baseando-se

Outro método de amostragem não estatística é a a mostragem de julgamento. Na amostragem de julgamento, o responsável pelo levantamento utiliza-se de seu conhecimento ou experiência para selecionar os itens que serão amostrados. Um testador mais antigo de profissão ou na empresa pode utilizar sua experiência de mercado ou na área de testes para identificar mais

Amostragem casual Existem outros tipos de amostragem que mesmo não sendo estatísticos, podem fornecer informações úteis no momento do levantamento de um dado de teste ou de realizar o teste, um deles é a amostragem casual. A amostragem casual leva em consideração a conveniência. A amostragem casual é normalmente mais rápida e usa taman hos de amostra menores do que outras técnicas de amostragem, sua principal desvantagem é que uma vez que não tem base estatística, generalizações sobre o item que será avaliado devem ser feitas com ext rema cautela. Exemplo1: Um gestor de testes pode pegar todos os casos de uso de uma aplicação que já foi testada e aleatoriamente escolher 1 para avaliar se os testes aplicados atenderam às expectativas, se foi feito o planejamento completo desse caso de uso e assim por diante, dependendo do objetivo da averiguação que deseja realizar. Exemplo 2: Um campo que aceita até cinco caracteres numéricos e o analista de teste escolhe um número aleatório para inserir no campo e iniciar o teste. Simplificando, o teste casual é feito rotineiramente na maioria das empresas, às vezes, sem que as pessoas que estão realizando tenham ciência que estão utilizando de uma técnica de amostragem não estrutural.


ENGENHARIA

rapidamente quais serão os pontos dentro de uma determinada aplicação que apresentarão problemas. Exemplo1: Uma nova versão da aplicação foi liberada no ambiente de Homologação e a área de Qualidade de Software precisa garantir que a versão está funcionando corretamente, assim como funciona no ambiente de Qualidade. Com base na experiência, o testador pode executar os testes nos pontos mais críticos da aplicação (que geralmente apresentam problemas, ou que são vitais para a existência da aplicação), para depois realizar um teste exploratório em toda aplicação e realizar a liberação com a garantia solicitada. Exemplo2: Em uma aplicação Web, o analista de teste pode es colher por iniciar os testes pelo Internet Explorer, pois pela sua experiência é o navegador que mais apresenta problemas. Exemplo3: Em um sistema de geração de relatórios, onde é possível inserir filtro de data, o testador pode optar por tentar filtrar informação referente a um único dia como, por exemplo: De 06/05/2014 a 06/05/2014. Isto porque conforme sua experiência, a maioria das aplicações não trata o filtro quando a data não tem um intervalo que não seja de ao menos um dia, nessas situações, embora haja informações os relatórios costumam não listar os dados. Da mesma forma como o teste de amostra casual, o teste por julgamento também é muito utilizado sem que as pessoas sai bam que estão utilizando uma técnica. É importante ressaltar

o valor dessa técnica, pois ela enfatiza o quão importante é a experiência das pessoas e quão valiosas são as perspectivas que cada um tem de uma mesma aplicação, quando utilizado de uma experiência anterior, seja de outra empresa, ou apenas de outro projeto. As técnicas de amostragem estatística podem ser aplicadas com sucesso na área de qualidade de software. Entretanto, assim como qualquer técnica, é preciso primeiro avaliar o cenário da organização para identificar se a técnica escolhida atende as necessidades e realiza a cobertura desejada. Existem diversas técnicas em teste de software que são mais eficientes que a técnica de amostragem, contudo é importante esclarecer que essa técnica é utilizada em situações onde o tempo disponível é curto e uma análise precisa ser feita de imediato, geralmente mais aplicada em testes de regressão ou para situações de auditoria.



47


Como aumentar a produtividade de sua equipe de programadores Veja como avaliá-los e estimular a produtividade Fique por dentro:

A Ivania Ramos dos Santos [email protected]

Bacharel em Sistemas de Informação pela Faculdade Mater Dei (2008), especialista em Engenharia de Software pela Faculdade Mater Dei (2011). Atualmente é Gerente de Serviços de TI da empresa AInova., professora na Faculdade Mater Dei, FESC e Sesi/Senai. Experiência gestão de processos de qualidade utilizando metodologia MPS.BR.

Marcos Vinicius De Bortolli [email protected]

Especialista em Gestão da Informática pela FAE/ CDE(1998) e Mestre em Inteligência Computacional pela UFPR (2001).Foi gerente regional da CPM - Filial Pato Branco. Atualmente é Diretor de Sistemas junto à Secretaria de Ciência, Tecnologia e Inovação de Pato Branco, professor e coordenador da pós-graduação em Engenharia de Software na Faculdade Mater Dei, além de empresário e escritor.

qualidade é a totalidade das características de um produto ou serviço que se baseia na sua habilidade de satisfazer uma dada necessidade. Outra definição de qualidade seria: software de qualidade é aquele que faz o que se espera que ele faça. A falta de qualidade mais fácil de definir é falta de satisfação do usuário e a medida usual da falta de qualidade é o relatório de erros. A garantia da qualidade de software compreende uma variedade de tarefas associadas a sete atividades: (1) aplicação de métodos técnicos; (2) realização de revisões técnicas formais; (3) atividades de testes de software; (4) aplicação de padrões; (5) controle de mudanças; (6) medição e (7) manutenção de registros e reportagem. A garantia estatística da qualidade reflete uma crescente tendência de toda a indústria para se tornar mais quantitativa em relação à qualidade.

O objetivo deste artigo é demonstrar o processo de avaliações profissionais periódicas sujeitas à premiação de programadores. Na primeira parte serão descritos os procedimentos que conduziram a avaliação, como classificação, tabulação e apresentação dos dados. Posteriormente, serão descritos os procedimentos que conduziram a premiação e finalmente os resultados obtidos com a experiência realizada na empresa CPM S.A. de Pato Branco. A discussão desse assunto é útil para organizações e equipes que buscam exemplos de métricas de produtividade.

Assim, a garantia estatística de qualidade de software apoia-se na questão quantitativa a respeito da frequência de ocorrência de erros e inconsistências nos softwares rastreados ao longo de um período específico de tempo. Para o software, a garantia estatística da qualidade (SQA - Software Quality Assurance) implica em um primeiro passo no qual as informações sobre os defeitos de software são coletadas e dispostas por categorias. A partir daí, outros passos necessários para realizar a SQA e criar um processo de revisão

48 Engenharia de Software Magazine - Como aumentar a produtividade de sua equipe de programadores

ENGENHARIA

são: (1) rastrear o defeito até sua causa; (2) considerar que 20% do código têm 80% dos defeitos; (3) corrigir os problemas que causaram os defeitos. As revisões de software são um filtro para o processo de engenharia de software. Ou seja, as revisões são aplicadas em vários pontos durante o desenvolvimento de software e servem para descobrir defeitos que possam ser eliminados. As revisões de software têm como objetivo “purificar” as atividades da engenharia de software. Assim, a atividade de teste de software é um elemento crítico da garantia da qualidade de software e representa a ultima revisão de especificação, projeto e codificação. Com o advento das novas tecnologias e métodos de trabalho, e em face da diversidade de mão de obra, de clientes, fornecedores e parceiros, bem como da globalização, muitos procedimentos e paradigmas estão sendo redefin idos. Isto objetiva abrir espaço para novas ideias, formas estratégicas e ma neiras de administrar as pessoas nas empresas, observando-se assim um aumento na demanda por profissionais qualificados. As mudanças são percebidas pelas organizações e influenciam a atividade da direção, que muitas vezes, procura empregar ferramentas de gestão mais adequadas para a obtenção dos resultados organizacionais desejados. O caso da CPM S.A era ajustado a esta realidade. Havia uma urgente necessidade de aumentar a qualidade do serviço desenvolvido na fábrica de Pato Branco, especialmente qualidade do software. Como era de se esperar, houveram várias propostas relacionadas à mudança de procedimentos internos, principalmente referentes à análise estática e teste dinâmico de software. Entende-se aqui como análise estática a análise do código fonte para identificar problemas e o teste de software é a execução do software com dados de teste atuais. Houve então uma série de reuniões que acabaram por resultar no seguinte trabalho de avaliação e premiação de desempenho.

Classificação de programas Os programas foram classificados por: • Nível de complexidade, como Fácil, Médio e Difícil; • Forma de processamento, como On-Line e Batch; • Tipo de solicitação, como Desenvolvimento (de programas novos), Alteração (de programas existentes), Complemento (de programas ainda não entregues) e Desenvolvimento com Base (em outros programas); • Prazo de entrega (Normal e Urgente). Foram atribuídos bônus (pontos positivos) com pesos di ferentes para cada categoria ( Tabela 1). Estes bônus podem ser cumulativos, ou seja, um programa padrão pode valer até 9 pontos, desde que seja uma s olicitação de Desenvolvimento (3), com complexidade Difícil (3) e de processamento On-line (3) = 9 pontos. Como erros (pontos negativos), foram atribuídos diferentes pesos a partir de uma tabela elaborada em conjunto com todos os envolvidos, tendo como base os procedimentos e padrões da

própria empresa. Estes erros dividem-se em categorias como: (1) Erros de padronização, que se referem a diferenças encontradas no programa com relação ao padrão de programação estabelecido pela fábrica; (2) Erros de lógica, que se referem a problemas encontrados na lógica de funcionamento do programa e (3) Erros de procedimento, que se referem a problemas de comportamento que prejudicam a equipe e os trabalhos (Tabela 2). Todos estes erros também podem ser cumulativos por programa. Descrição

Valor

Solicitação de desenvolvimento

3,00

Solicitação de alteração

1,00

Solicitação de complemento

1,00

Solicitação de desenvolvimento com base em outro programa

2,00

Programa nível fácil

1,00

Programa nível médio

3,00

Programa nível difícil

6,00

Programa de processamento on-line

3,00

Programa de processamento batch

1,00

Programas com entrega urgente

3,00

Tabela 1. Bônus atribuídos aos programas

Erros de padronização conforme manual interno Descrição

Valor

Erro classe 100

0,50

Erro classe 200

0,50

Erro classe 300

0,50

Erro classe 500

0,50 Erros de lógica conforme manual interno

Descrição

Valor

Erro classe 400 – grave

3,00

Erro classe 400 – médio

2,00

Erro classe 400 – simples

1,00 Erros de procedimento

Descrição

Valor

Entrega atrasada

1,00

Falta de bilhete

0,50

Descuido no pedido de fontes

0,50

Falta de esclarecimento de dúvidas técnicas

0,50

Falta de massa de dados

1,00

Mau levantamento de dúvidas

1,00

Falta de testes

2,50

Faltar ou sair sem avisar

2,50

Faltar ou sair sem deixar responsável

2,50

Preenchimento indevido de checklist

2,50

Falta de preenchimento relatório de ocorrências

2,50

Descuido no envio de fontes

2,50

Tabela 2. Erros atribuídos aos programas


49

Tabulação e apresentação dos dados Após os testes realizados em cada programa por Analistas de Controle de Qualidade (ACQ) da própria fábrica, foram lançados os bônus (pontos positivos) e diminuídos os erros (pontos negativos) de cada programador. A diferença entre os bônus e os erros gera uma pontuação. Esta pontuação dividida pelo número de programas desenvolvidos pelo programador resultou em uma média. Para verificar o aproveitamento do programador, calculou-se o percentual de erros frente ao total de bônus, variando de 0 a 100 %. Finalmente, para fins de classificação final das posições, foi estabelecida uma nota para cada programador, calculada com base na soma ponderada da média e do aproveitamento. Em todo o processo de tabulação e apresentação dos dados foi utilizado um sistema informatizado desenvolvido especialmente para este fim, denominado Águia.

Premiações Para que se possa realizar adequadamente a garantia de qualidade de software, dados sobre o processo de engenharia de software devem ser compilados, avaliados e divulgados. Então, de posse do relatório mensal de classificação dos programadores, uma comissão composta pelos Analistas de Controle de Qualidade (ACQs), pelo Planejamento e Distribuição de programas (PLD), pelo Controle de Tarefas (CTF), pelo Apoio a Linguagens (APL) e pela gerência local da fábrica, analisou os resultados objetivamente de acordo com critérios estabelecidos. Os programadores também foram analisados subjetivamente, utilizando-se critérios como comportamento de equipe, proatividade e relacionamento interpessoal. Esta comissão então definia via votação aberta pelos três melhores programadores. A seguir, eram divulgados os resultados dos primeiros colocados a serem premiados, bem como relatórios estatíst icos de qualidade. Estas premiações eram determinadas no início do mês seguinte aos testes. O prêmio estabelecido foi o pagamento

de valor equivalente a 50 horas de salário divididos entre os três primeiros colocados do mês.

Apresentação dos resultados Durante um determinado mês, todos os resultados mensais foram compilados e analisados, resultando em uma tabela final com o desempenho da fábrica ( Tabela 3). Nesta tabela foi acrescentada uma coluna denominada Complexidade, que determina a complexidade média dos programas desenvolvidos na fábrica. Esta Complexidade é obtida pela divisão do total de Bônus pelo número de Programas (Pgms). Observa-se que a complexidade média dos programas aumentou em média 7% do 2º semestre para o 1º semestre, enquanto que o número médio de programas desenvolvidos diminuiu apenas 2% no 2º semestre. Ou seja, os programadores fizeram mais programas de Complexidade Difícil em menos tempo. Outro dado importante é a redução drástica do número de erros internos cometidos pelos programadores. O nú mero de erros total caiu de 1151 erros em março, quando uma nova turma de programadores iniciou no processo, para menos de 23 erros em dezembro. Isto configura uma redução de 98% no número de erros por mês (ver Figura 1) considerando os dois limites, 1151 e 23. No segundo semestre, a redução é da ordem de 86,7% frente ao primeiro semestre. Da mesma forma, o aproveitamento total dos programadores aumentou muito de um semestre para outro. Passou de 52,4 % em janeiro para 98,4 % em dezembro, com um cresc imento de quase 46% de um semestre para outro (ver Figura 2). Em perguntas informais dirigidas aos programadores e analistas de controle de qualidade envolvidos no processo avaliativo, descobriu-se que os principais fatores que motivaram a alta qualidade podem estar nas segui ntes hipóteses: (1) a clareza dos objetivos de qualidade, (2) a premiação financeira dos melhores resultados do mês, (3) a responsabilidade diante do controle sobre os procedimentos efetuados,

Resumo do desempenho dos PRG Mês

Bônus

Erros

Pontuação

Pgms

Complexidade

Média

Aproveitamento

Nota

01

1684

801,0

883,0

312

5,4

2,8

52,4

41,94

02

1023

163,5

859,5

198

5,2

4,3

84,0

66,12

03

1461

1151,0

310,0

242

6,0

1,3

21,2

17,73

04

1385

501,5

883,5

282

4,9

3,1

63,8

49,30

05

950

202,5

747,5

185

5,1

4,0

78,7

61,79

06

1060

92,5

967,5

225

4,7

4,3

91,3

69,53

07

1287

80,5

1206,5

244

5,3

4,9

93,7

74,34

08

1223

80,0

1143,0

214

5,7

5,3

93,5

76,40

09

1796

97,0

1699,0

357

5,0

4,8

94,6

73,74

10

1281

75,5

1205,5

216

5,9

5,6

94,1

78,06

11

854

30,0

824,0

151

5,7

5,5

96,5

78,56

12

1411

23,0

1388,0

239

5,9

5,8

98,4

81,45

Tabela 3. Resumo do desempenho dos programadores

50 Engenharia de Software Magazine - Como aumentar a produtividade de sua equipe de programadores

ENGENHARIA

(4) a competição entre o programador e os demais colegas de trabalho, (5) soma de todas as alternativas anteriores, porém com pesos diferentes. Além disso, ainda em perguntas informais somente com os analistas de controle de qualidade responsáveis pelas avaliações, a relação de desempenho dos programadores praticamente espelhava a realidade da fábrica, inclusive em comportamento. Segundo relato informal destes analistas, os programadores com melhor desempenho da lista eram também os de melhor comportamento e relacionamento dentro da fábrica.

relacionamento podem ser preponderantes para um ambiente de programação adequado e de alta produtividade. A avaliação profissional periódica sujeita à premiação aumentou em 98% o aproveitamento dos programadores após o anúncio da primeira premiação. Esta avaliação também criou uma cultura de qualidade na empresa que se estendeu por todo o período de aplicação do processo avaliativo. Nestes tempos de busca contínua pela qualidade, o processo de avaliação aliado a uma política de recompensas demonstrou ser eficaz e eficiente no objetivo de aumentar constantemente o ritmo e a qualidade da programação na empresa. Quanto aos fatores que motivaram realmente o resultado, cabe um estudo futuro que delineie claramente o peso de cada hipótese no conjunto. Outro resultado que merece um aprofundamento é a relação do comportamento e relacionamento do programador com seu desempenho de programação. Links: [BATCH] Plano Básico de Ensaios – Mainframe – Batch, IT-07-ACQ-002, revisão 2, CPM S.A.,2001 [FAE] Capital Humano, FAE Business School, Curitiba: Associação Franciscana de Ensino Senhor Bom Jesus, 2002.

Figura 1. Total de erros dos programadores

[GRAUCPM] Tabela de Determinação de Grau de Complexidade e Prazos, MP-07-CPM-020, revisão 3, CPM S.A., 2001 [GUSTAFSON] Gustafson, David A.. Teoria e problemas de Engenharia de Software, Bookman, Porto Alegre, 2003. [PADRCPM] Manual de Padronização, Treinamento e Apoio à Programação, CPM S.A.,1997 [PESSOA] Pessoa, André. Projetos de Sistemas de Informação. Book Express, Rio de Janeiro, 2000. [PLDCPM] Planejamento e Distribuição, 07-PLD-001, revisão 10, CPM S.A., 2001 [QUALICPM] Manual da Qualidade – Fábrica de Software, 07-CPM-001, revisão 4, CPM S.A.,2001 [SHIGUNOV] Shigunov Neto, Alexandre. Avaliação de Desempenho, Book Express, Rio de Janeiro, 2000.

Figura 2. Percentual de aproveitamento dos programadores

Isto supõe que o desempenho comportamental e relacional dos programadores influi diretamente no resultado do processo avaliativo. Esta é uma hipótese que merece maior estudo, pois em caso afirmativo, prova que comportamento e



51


Como detectar problemas de usabilidade e corrigi-los - Parte 1 Solucione os problemas de usabilidade em sistemas interativos Fique por dentro: Atualmente, a quantidade de usuários de computadores vem aumentando consideravelmente, e como consequência, uma parcela destes usuários enfrentam uma maior dificuldade em interagir com os sistemas. Isso se dá principalmente porque alguns programas não possuem uma interface com facilidade de uso. A ergonomia e a área de usabilidade apresentam pesquisas e técnicas que permitem aos projetistas de sistemas computacionais interativos melhorar a usabilidade destes sistemas. Este artigo tem como propósito apresentar os conceitos de usabilidade, e avaliação de usabilidade, descrevendo sua importância nos sistemas de hoje. Apresenta também os tipos de avaliação de usabilidade e como podem ser aplicados.

ESTE ARTIGO FAZ PARTE DE UM CURSO

C

Karin R. Coelho Quandt [email protected]

Analista de testes, Bacharel em Ciência da Computação, Especialista em Engenharia de Projeto de Software.

om o advento da tecnologia, as pessoas precisam mudar consideravelmente seus hábitos. Muitas delas estão sendo obrigadas a interagir com máquinas e equipamentos que nem sempre são de fácil manuseio. Para facilitar essa interação dos usuários com as máquinas, os projetistas estão empreendendo esforços para tornar esses equipamentos mais simples de utilizar. A usabilidade não diz respeito somente à facilidade de uso, mas sim, de que forma o trabalho é feito: “o sistema não só deve ser amigável, mas também eficiente, seguro e sensível a variações das condições de uso”. A usabilidade promove a melhoria do processo de interação, o uso e a popularidade dos diferentes equipamentos presentes no nosso dia a dia, fez com que o conceito

de facilidade de manuseio se tornasse senso comum entre usuários. A usabilidade é um conceito que vem sendo adotado pelas empresas, pois o interesse em desenvolver softwares amigáveis e de fácil interação está em evidência devido aos diversificados perfis de usuários que atualmente têm que interagir com os sistemas.

52 Engenharia de Software Magazine - Como detectar problemas de usabilidade e corrigi-los - Parte 1

ENGENHARIA

A usabilidade é um conceito que pode ser aplicado em qualquer objeto que pode proporcionar satisfação de uso para seus usuários. A usabilidade mede a experiência de um usuár io ao interagir com um sistema web, um software desktop, tecno logia móvel ou um outro dispositivo que possa ser operado pelo usuário. A usabilidade consiste em uma combinação de diversos fatores: facilidade de aprendizagem, eficiência no uso, facilidade de lembrar, frequência e severidade de erros e satisfação subjetiva. Todos esses conceitos podem s er observados nos diversos contextos de avaliação. A usabilidade é uma qualidade do uso do sistema, o desempenho do usuário depende da obtenção de seus objetivos, se são atingidos com eficiência e eficácia. Para melhor representar essas definições, a norma ISO 9241-11 esquematiza o conceito de usabilidade que pode ser visto na Figura 1.

Figura 1. Esquema do conceito de usabilidade. Fonte: ISO 9241-11

Uma das maiores dificuldades encontradas está em avaliar o quanto uma interface é adequada ao uso. A “usabilidade é uma metodologia científica aplicada na criação e remodelação de interfaces de sites, intranets, aplicativos, jogos e produtos de modo a torná-las fáceis de aprender e de usar”. A usabilidade desenvolve conhecimentos sobre os limites e características referentes ao desempenho do homem que estão relacionadas às interfaces e componentes do sistema. É recomendável que o ergonomista tenha como enfoque o desenvolvimento de soluções para assegurar que a qualidade da interação seja adequada às condições dos usuários e ao motivo pelo qual ele irá fazer uso delas. A usabilidade é um conceito que está evoluindo, pois não tem um significado concreto; ela considera o contexto de uso de acordo com o ponto de vista do usuário. A usabilidade é um dos fatores do sucesso de um produto, dirigindo-se ao usuário e condicionando a produtividade e eficiência ao conforto e satisfação do usuário. A web fornece um exemplo acessível da importância da usabilidade, pois os usuários procuram páginas fáceis de usar, sites sem falhas, com informações claras e com boa

localização para que eles não se percam nas páginas e sites. As informações devem ser apresentadas de forma que seja de fácil entendimento, caso contrário, os usuários desistem da pesquisa pois se cansam antes mesmo de ter acesso ao que realmente desejam. A usabilidade tem múltiplos componentes e está associada a cinco atributos: • Fácil de aprender: o sistema deve ser de fácil aprendizado para que o usuário obtenha resultados a curto tempo; • Eficiente: o usuário deve ter um alto nível de produtividade com o sistema; • Fácil de lembrar: o sistema deve ser fácil de ser lembrado mes mo que o usuário tenha ficado algum tempo sem utilizá-lo; • Minimização de Erros: o sistema deve possuir baixas taxas de erros, de forma que usuários cometam poucos erros durante o uso do sistema, e mesmo que eles cometam, esses erros devem ser de fácil recuperação. • Satisfação: o sistema deve ser agradável de se utilizar e c on sequentemente deve dar satisfação para seus usuários. A usabilidade é uma combinação de fatores que atingem as habilidades do usuário diante do sistema. Por isso, ela trata da interação humano-computador, que é observada desde o desenvolvimento de software por meio de testes de usabilidade com o usuário. Assim, pode-se afirmar que a usabilidade é uma qualidade do uso do sistema, que difere pelas operações realizadas pelos usuários. O desempenho do usuá rio depende da obtenção de seus objetivos (eficácia) bem como os recursos que são gastos para que eles possam ser atingidos (eficiência). Todos esses conceitos estão relacionados e podem ser observados nos diferentes contextos em que se pode avaliar a usabilidade. Eles também influenciam na produtividade e na eficiência aumentando a qualidade e a usabilidade dos sistemas oferecidos para os usuários obrigando a intensificação de testes de usabilidade para avaliação dos softwares usados ou os que já estão sendo produzidos.

Avaliação de Usabilidade A avaliação da usabilidade de um software é um fator a ser considerado para o seu aprimoramento, pois é a partir dela que se descobrem os principais problemas de usabilidade que podem gerar dificuldades para os usuários. Para avaliar uma interface, vêm sendo desenvolvidos métodos e ferramentas para melhor detectar as reais necessidades dos usuários. A competitividade que existe no mercado faz as empresas buscarem produzir interfaces bem desenvolvidas. Estudos na área de avaliação de software indicam que os usuários estão cada vez mais exigentes quanto às funcionalidades do sistema. A qualidade de uma interface é decidida pelos seguintes fatores: • Funcionalidade: a interface ajuda no acesso eficiente e efeti vo? A interface faz o que o usuário quer e deseja? • Consistência: os padrões dos comandos e mensagens de ajuda estão sendo seguidos? Edição 70 - Engenharia de Software Magazine

53

• Clareza: o projeto das telas e o uso das cores são familiares para o usuário? • Segurança: os usuários são capazes de identificar e corrigir erros? Os usuários podem corrigi-los de forma simples? • Ajuda, explanação e mensagens de erro: as mensagens são oferecidas de forma clara e detalhadas para que os usuários possam entender? • Padronização: os cenários são apresentados de forma padronizada? A interface e a forma como a informação é apresentada são elementos básicos para um bom sistema. Aquelas que não exigem muito esforço dos usuários para realizar suas tarefas são consideradas boas e fáceis de usar. Heemann diz que, “os estudos e pesquisas sobre interfaces mostram que as que permitem a ‘lei do menor esforço’, estão associadas aos sistemas mais fáceis de usar e aos sistemas considerados de maior valor para os usuários”. Se o desejo é fazer com que o programa seja fácil de usar e se tornar um sistema de grande valor, é recomendável que se adotem métodos adequados de avaliação de usabilidade. A escolha do método apropriado depende de diversos fatores, tais como: • Fase em que está o projeto; • Inovações no projeto; • Quantidade de usuários esperados; • Criticidade da interface; • Custo do produto e recursos alocados para testes; • Disponibilidade de tempo; • Experiência da equipe do projeto e da equipe de avaliação. Outros fatores que devem ser considerados para a escolha de um método de avaliação de usabilidade são: • Propósito da avaliação; • As restrições de tempo, custo e disponibilidade de equipamentos; • Quanto à avaliação afeta a situação que está sendo avaliada, bem como a confiabilidade dos métodos; • Algumas questões práticas do tipo: Os dados são fáceis de associar? Quanto vai demorar? Quanto vai custar? Os recursos apropriados estão disponíveis? Técnicas de avaliação Avaliação Heurística

• Determinismo dos métodos no que diz respeito à assimilação às práticas comerciais. A Tabela 1 resume algumas das técnicas para avaliação de usabilidade existentes. Posteriormente elas serão tratadas com mais detalhes.

Técnicas de Avaliação de Usabilidade – Técnicas Prospectivas O uso da técnica prospectiva consiste basicamente em avaliar o sistema e as operações dos usuários por meio da aplicação de questionários/entrevistas (ler BOX 1). Esta técnica tem sido comumente utilizada, pois o usuário é a pessoa que melhor conhece o sistema com relação ao uso e melhor pode dizer se está adequado para a realização de suas tarefas. Esses questionários têm devolução reduzida, prova de que deve ser elaborado com o mínimo de questões possíveis. Em contrapartida, empregando essa técnica, combinada com outra técnica pode-se ter um aumento na efetividade de avaliações analíticas, que são realizadas por especialistas para identificar e solucionar problemas de usabilidade. Os questionários e as entrevistas são métodos similares, já que ambos dizem respeito à coleta de dados sobre a satisfação do usuário com a interface. A diferença é que o questionár io é respondido pelo próprio usuário em papel, ou no computador, tendo a presença física de uma pessoa para auxiliá-lo ou não. Já as entrevistas envolvem a gravação das respostas às perguntas que o entrevistador realiza. Há dois tipos de estrutura de perguntas de questionários diferentes: • Perguntas abertas onde o questionado é livre para fornecer suas próprias respostas. Elas podem fornecer muitos dados, mas podem ser difíceis de analisar; • Perguntas fechadas onde o questionado escolhe a resposta dentre algumas alternativas. São mais fáceis de analisar do que as perguntas abertas, pois há formas de classificação para seguir. Shneiderman sugere um questionário de avaliação da satisfação do usuário com o sistema. Esse questionário pode auxiliar na avaliação de alguns itens como:

Vantagens • Detecta maior quantidade de problemas. • Detecta maior quantidade de problemas de maior gravidade.

Desvantagens • Não detecta problemas relacionados às expectativas em usabilidade. • Requer especialista em usabilidade. • Requer vários avaliadores. • Requer planejamento preciso para os testes (tarefas, usuários).

Testes de usabilidade com usuários

• Detecta problemas recorrentes e de maior gravidade.

• Requer muitos recursos (tempo, pessoal, equipamentos de gravação). • Alto custo. • Não detecta problemas de consistência.

Inspeção baseada em recomendações Exploração cognitiva

• Detecta problemas gerais e recorrentes. • Pode ser usada por projetistas.

• Deixa de detectar vários problemas de alta gravidade.

• Ajuda a definir os objetivos e expectativas dos usuários.

• Necessita de metodologia de definição de tarefas.

• Pode ser usada por projetistas.

• Deixa de detectar problemas gerais e recorrentes.

Tabela 1. Técnicas de avaliação de usabilidade


ENGENHARIA

• Tempo do usuário para aprender funções específicas de um sistema; • Velocidade de desempenho para realizar uma tarefa; • Taxa de erros cometida pelos usuários; • Retenção de usuário de comandos com o passar do tempo. Além das técnicas com participação dos usuários – as entrevistas e os questionários – há também as que os usuários não participam diretamente da interação, essas técnicas são chamadas de técnicas analíticas. BOX 1. Posso avaliar sistema novo? O sistema que está sendo desenvolvido pode consistir em algo totalmente novo ou em uma atualização de algo já existente. Em se tratando de um sistema novo, geralmente um tempo considerável é investido em pesquisa de mercado. Os designers geralmente desenvolvem esboço de telas a fim de extrair as reações dos usuários, pode ser aplicada a técnica de card sorting para a organização de menus. No caso de uma atualização, a atenção é voltada para a melhoria do produto, as avaliações são comparadas com o desempenho e as atitudes dos usuários com as versões anteriores.

Técnicas de Avaliação de Usabilidade – Técnicas Analíticas As técnicas analíticas são caracterizadas pelo fato do usuário não participar diretamente do sistema durante a avaliação. Normalmente, são os especialistas em usabilidade que utilizam essas técnicas. Os avaliadores se baseiam em regras, recomendações, princípios e/ou conceitos previamente estabelecidos para identificar os problemas de usabilidade que provavelmente afetam (ou afetarão) a interação dos usuários reais com o sistema. A avaliação analítica pode começar em u m estágio inicial do ciclo de design quando uma interface é representada apenas por uma especificação formal ou semiformal. Para fazer esse tipo de avaliação, é necessário um detalhamento das operações de interfaces no que diz respeito às interações do usuário com o sistema. Existem três tipos de técnicas analíticas para avaliação de interfaces de software: Avaliação Heurística, Conformidade com Recomendações e Exploração Cognitiva.

Avaliação heurística A avaliação heurística é realizada por especialistas em usa bilidade que percorrem a interface baseados em seus conhecimentos. A avaliação heurística é uma técnica de avaliação baseada em incertezas provisórias, que utiliza um conceito semelhante ao raciocínio do jogo de xadrez. A avaliação não segue uma sequência lógica de passos, ela é realizada através de aproximações progressivas, onde cada estágio do caminho percorrido é avaliado e, então, especula-se sobre a natureza dos caminhos a seguir para se aproximar do objetivo de encontrar o maior número possível de problemas de usabilidade. Por esse tipo de avaliação ser baseado em seleção de objetos de interface, telas, situações de interação e incertezas provisórias, é fundamental para seu sucesso que o avaliador tenha experiência e capacidade de interpretação.

Os resultados dessa técnica são bons, pois são julgadas as interfaces baseadas nas competências e conhecimentos dos especialistas. Pelo mesmo motivo, é uma técnica barata, com resultados rápidos e satisfatórios. Em contrapartida, para fazer uso dela, deve-se ter o cuidado de procurar pessoas capacitadas e com competências necessárias para a realiz ação dessa avaliação. Os avaliadores tomam por base padrões de usabilidade gerais ou desenvolvidos por especialistas como, por exemplo, os critérios ergonômicos, as heurísticas e a Norma ISO 9241:10 (Princípios de diálogos). Ainda assim, a avaliação acaba sendo subjetiva visto que envolve a identificação da maior parte dos problemas de ergonomia.

Conformidade com Recomendações Nesse tipo de avaliação é verificada a conformidade da interface em relação às necessidades dos usuários junta mente com outras técnicas de avaliação. As conformidades de recomendações são realizadas por meio de guias, que são publicações de caráter genérico e são agrupadas de modo empírico ou validadas. A conformidade com recomendações é realizada com guias de recomendações, que fornecem aos avaliadores recomendações específicas sobre o projeto de uma interface, tais como: como o conteúdo de uma tela deveria ser organizado ou como as opções deveriam estar arranjadas em um menu. Essa técnica, além de ser utilizada como recomendação na forma afirmativa, pode também ser aplicada com questões interrogativas – Checklist organizado.

Exploração cognitiva Na avaliação cognitiva os especialistas assumem o papel de usuários procurando simular a interação do usuário com o sistema. Nessa avaliação são enfocados principalmente os processos estabelecidos quando a tarefa interativa é realizada pela primeira vez pelo usuário. A exploração cognitiva auxilia a avaliar as condições do software no que diz respeito ao rápido aprendizado e ao diálogo do usuário com o sistema. A validade desta técnica está justamente em seu enfoque nos processos cognitivos. Para realizá-la, o avaliador tem que prestar atenção no que é conhecido, pelo usuário, da tarefa e da operação dos sistemas informatizados. Uma vez que o avaliador tenha todas essas informações, ele passa a percorrer os caminhos previstos e para cada ação ele aplica o seguinte checklist: • O usuário tenta realizar a tarefa certa? Ao encontrar-se no passo inicial de determinada tarefa, o usuário, baseado no que lhe é apresentado, se proporá a realizar o objetivo previsto pelo projetista? • Ele verá o objeto associado a esta tarefa? Este objeto está suficientemente à vista do usuário? • Ele reconhecerá o objeto como associado à tarefa? As deno minações ou representações gráficas são representativas da tarefa e significativas para o usuário? Edição 70 - Engenharia de Software Magazine

55

• Ele saberá operar o objeto? O nível de competência na ope ração de sistemas informatizados é compatível com a forma de interação proposta? • Ele compreenderá o feedback fornecido pelo sistema como um progresso na tarefa? A exploração cognitiva tem como objetivo básico a avaliação de interfaces de software nas condições e facilidades oferecidas ao usuário.

Técnicas de Avaliação de Usabilidade - Técnicas Empíricas Técnicas empíricas são as técnicas em que há a participação direta dos usuários na avaliação do sistema. Elas consistem em realizar testes de usabilidade com os usuários. Aplicação das técnicas requer atenção e cuidados, é importante realizar estudos sobre as características e pecu liaridades de cada técnica a ser utilizada, pois algumas delas são vantajosas aplicadas ao desenvolvimento de interfaces com a participação do usuário. Avaliar a usabilidade não é uma tarefa simples, pois vai muito além de saber se o sistema está atendendo as expectativas dos usuários. A detecção de problemas de usabilidade viabiliza a correção destes problemas e, consequentemente, contribui para a melhoria da qualidade da interface de sistemas interativos, isto é, auxilia projetistas de software e ergonomistas a obter uma maior usabilidade nas interfaces humano-computador.

Links e Referências: [1] ARTIS FACTA. De la conception au succès: La facilité d’usage ou utilisalilité. Paris. 2002. http://www.artis-facta.com/USAB/USAB03.HTML

[2] BÉNARD, Vincent. Utilisabilité: que se cachê-t-il derrière ce terme barbare?: Une définition de I’ utilisabilité. Paris. 2001. http://www.veblog.com/fr/2001/1021-usability-indepth.html

[3] CYBIS, Walter de Abreu. Engenharia de usabilidade: Uma abordagem ergonômica. Florianópolis: LabIUtil, .2003. [4] DIAS, Cláudia. Usabilidade na Web: Criando portais mais acessíveis. Rio de Janeiro: Alta Books, 2003. [5] HEEMANN, Vivian. Avaliação ergonômica de interfaces de base de dados por meio de checklist especializado.1997. 96 f. Dissertação (Mestrado em Engenharia de Produção). Departamento de Engenharia de Produção, Universidade Federal de Santa Catarina, Florianópolis, 1997. [6] PREECE, Jenny. A guide to usability: Human factors in computing. Reading- Harlow-Menlo Park-Berkeley-Don Mills-Sydney-Bonn-AmsterdamTokyo-Mexico city: Addison-wesley, 1993. [7] SHNEIDERMAN, Ben. Designing the user interface: Strategies for effective. 3 ed. Reading- Harlow-Menlo Park-Berkeley-Don Mills-Sydney-BonnAmsterdam-Tokyo-Mexico city: Addison-wesley, 1998.




Teste unitário com JUnit e ComplexGraph Como aplicar teste unitário com auxílio de uma ferramenta de medição de complexidade

Felippe Moreira Faêda [email protected]

É aluno de mestrado em Ciência da Computação pela Universidade Federal de Viçosa, pós-graduando em Gerência de Projetos em Engenharia de Software pela Faculdade Governador Ozanam Coelho (FAGOC). Graduado em Ciência da Computação pela FAGOC e técnico em informática pelo Centro Federal de Ensino Tecnológico de Minas Gerais (CEFET-MG).

Vinícius Lucena Bonoto [email protected]

É consultor na empresa de desenvolvimento de software Tek-System Informática. Pós-Graduando em Gerência de Projetos em Engenharia de Software pela Faculdade Governador Ozanam Coelho (FAGOC). Graduado em Ciência da Computação pela FAGOC.

Marco Antônio Pereira Araújo [email protected]

É Doutor e Mestre em Engenharia de Sistemas e Computação pela COPPE/UFRJ, Especialista em Métodos Estatísticos Computacionais e Bacharel em Informática pela UFJF, professor dos cursos de Computação do Instituto Federal de Educação, Ciência e Tecnologia do Sudeste de Minas Gerais – Campus Juiz de Fora,professor do curso de Bacharelado em Ciência da Computação da FAGOC, professor dos Cursos de Bacharelado em Sistemas de Informação do Centro de Ensino Superior de Juiz de Fora, da Faculdade Metodista Granbery e da Universidade Severino Sombra, Analista de Sistemas da Prefeitura de Juiz de Fora,Editor da Engenharia de Software Magazine.

Fique por dentro:

A

competitividade no mercado de desenvolvimento de software vem aumentando nos últimos anos e manter-se competitivo nesse mercado vem exigindo das empresas maior qualidade nos produtos e serviços oferecidos. Uma etapa fundamental no desenvolvimento de software que ajuda a detectar defeitos ainda não percebidos pelos programadores, e que verifica sua conformidade aos requisitos, é a etapa de teste de software. Essa etapa está se consolidando cada vez mais através de sofisticadas técnicas automatizadas de teste. Naturalmente, quando se termina de escrever um código-fonte começa o processo de revisão à procura de algum defeito no algoritmo. Em alguns casos, compara-se o código com a especificação e com o projeto a fim de garantir se todas as funcionalidades foram devidamente implementadas. Depois, o código é compilado e são corrigidos problemas

Os testes unitários são uma importante prática de teste que analisa em nível de código-fonte o funcionamento de um determinado algoritmo. Porém, identificar os casos de teste necessários para o teste unitário não é uma tarefa simples. Os casos de teste precisam ter valores apropriados para uma maior eficiência ao encontrar defeitos no código, e também garantir uma cobertura aceitável para o código-fonte em questão. Com o objetivo de auxiliar e agilizar a identificação dos casos de teste é que a ferramenta ComplexGraph será utilizada e demonstrada neste artigo em um estudo de caso. Depois de identificados os casos de teste, a ferramenta JUnit será utilizada para executá-los. Por fim, será utilizada uma ferramenta de teste de cobertura para verificar o grau de cobertura que os casos de teste geraram.

de sintaxe. Por fim, são criados casos de teste para mostrar que a entrada submetida ao algoritmo retorna a saída esperada. O teste unitário segue essas etapas com o objetivo de identificar os defeitos antes que os mesmos se transformem em falhas durante a utilização pelos usuários.


57

O teste unitário, também conhecido como teste caixa-branca ou estrutural, é um processo de teste onde o conhecimento da estrutura interna do sistema deve ser bem conhecido. Seu principal objetivo é testar as unidades de codificação de um software. Em sistemas orientados a objetos representam os métodos de cada classe, podendo ser até parte do método, dependendo de sua complexidade. Mas, para que o teste unitário tenha um bom desempenho, é necessário um bom planejamento dos testes, no qual leva-se em consideração a criação de uma quantidade razoavelmente boa de casos de teste que atinjam uma cobertura de código-fonte desejável. No entanto, identificar esses casos de teste não é uma tarefa simples e, caso seja feita de maneira errada, podem comprometer a qualidade do teste.

na Figura 1 por R1, R2, R3 e R4), totalizando quatro regiões. Portanto, o número da complexidade ciclomática é quatro. Outro método também utilizado é aplicando a fórmula: C=AV+2, onde A é o número de arestas e V o número de nós do grafo. Aplicando a fórmula na Figura 1 , tem-se: C=10-8+2, totalizando 4, que é o valor da complexidade ciclomática. Por fim, tem-se outra fórmula: C=P+1, onde P é o número de com ponentes conexos ou comandos de desvio, ou seja, o número de nós que geram duas saídas (as condições). Aplicando essa fórmula ao exemplo tem-se: C=3+1, totalizando 4.

Complexidade Ciclomática Uma maneira de identificar os casos de teste é utilizando uma métrica conhecida como complexidade ciclomática. Essa métrica foi desenvolvida por Thomas McCabe em 1976 e tem como finalidade medir a complexidade lógica de uma aplicação baseando-se em uma representação do fluxo de controle, também chamado de grafo da complexidade ciclomática. Através desse grafo é possível visualmente identificar os caminhos de execução do código e que vão se tornar casos de teste. A métrica da complexidade ciclomática, além de classificar o código-fonte quanto ao seu nível de complexidade, também pode ser utilizada no processo de elaboração dos casos de teste utilizados na técnica de teste unitário. O número da complexidade ciclomática também corresponde ao total de caminhos independentes do código-fonte e representa o total de casos de testes que devem ser realizados para cobrir totalmente o código, garantindo que todas as instruções sejam executadas pelo menos uma vez durante o teste unitário. Outro benefício ligado a essa métrica está na etapa de manutenção, pois com ela é possível quantif icar o quanto a complexidade de um código foi alterada durante o processo de mudança. Muitos desenvolvedores analisam o impacto de alguma mudança sobre o número ciclomático, pois se alguma manutenção é feita e isso eleva muito esse número, talvez seja necessário rever toda a manutenção realizada. O grafo da complexidade ciclomática descreve o fluxo de controle do programa, onde cada nó do grafo corresponde a um trecho de código e as arestas representam os fluxos de controle. Os f luxos podem variar dependendo da estrutura de código-fonte analisado, por exemplo, quando o nó corresponde a um comando if abrem-se duas arestas, ou seja, dois caminhos diferentes que possibilitam execuções diferentes durante a execução do código-fonte. A Figura 1 ilustra um exemplo de grafo da complexidade ciclomática. O grafo da complexidade ciclomática tem suas bases na teoria dos grafos e oferece uma métrica de software extremamente útil. Existem três métodos para se achar o número da complexidade ciclomática do grafo da Figura 1. O primeiro método é contar a quantidade de regiões do grafo (representadas

Figura 1. Exemplo de Grafo da Complexidade Ciclomática

Pode-se observar, comparando o grafo e código, que torna muito mais fácil encontrar no código os pontos onde se encontram seus caminhos de execução, facilitando a identificação dos casos de testes a serem feitos. Os casos de teste agora são construídos com o objetivo de passar por todas as arestas do grafo, garantindo assim uma cobertura maior dos testes. Após ser aplicado o teste unitário, é essencial que seja utilizada uma ferramenta para aferir o grau de cobertura dos testes unitários. Esse processo é chamado de teste de cobertura. Esse teste verifica, no código-fonte, os caminhos percorridos pelos testes unitários e, assim, ajuda a identificar as áreas que não estão sendo cobertas pelos testes. Ao final, o teste informa o grau de cobertura dos testes unitários e cabe ao responsável pelo teste avaliar esse grau segundo as necessidades de qualidade que necessitam ser alcançadas. O objetivo deste artigo é demonstrar como se pode facilitar a obtenção dos casos de teste e garantir um maior grau de cobertura do teste unitário utilizando uma ferramenta de apoio. Essa ferramenta é chamada de ComplexGraph. Com ela será possível, a partir de um código-fonte, gerar automaticamente o grafo e o número da complexidade ciclomática. Neste artigo demonstraremos como usufruir dos benefícios dessa ferramenta e realizar o teste unitário utilizando a ferramenta JUnit a partir do estudo de caso. Por fim, será executado o teste de cobertura utilizando a ferramenta Eclemma para conferir o grau de cobertura gerado pelo uso da ComplexGraph com JUnit.

58 Engenharia de Software Magazine - Teste unitário com JUnit e ComplexGraph

ENGENHARIA

Estudo de Caso Para exemplificar o uso das ferramentas propostas neste artigo, será utilizado um estudo de caso simples e de fácil entendimento, que consiste em calcular a aprovação de um aluno de graduação. O código-fonte foi escrito em Java utilizando a IDE Eclipse. O estudo de caso consiste em uma classe chamada AplicAprovacao cujo principal método explorado é o calcularAprovacao apresentado na Listagem 1. Serão passados como parâmetro para esse método a nota1, nota2, nota fina l e frequência do aluno e, ao final, o método retornará se o aluno foi aprovado ou não. O método funciona da seguinte maneira: primeiramente ele verifica se o aluno possui frequência maior que 75%, caso não tenha, ele já é reprovado direto. Se o aluno tiver frequência maior ou igual a 75, serão analisadas suas notas. Caso o alu no tenha média menor que 30 pontos, ele também é reprovado. Se a média for maior ou igual a 70 pontos, ele é aprovado. Se o aluno obtiver média maior ou igual a 30 e menor que 70 pontos, ele terá que fazer uma prova final. Portanto, será analisada sua média considerando a média anterior e a nota da prova fina l. Se esse novo resultado for maior ou igual a 50 pontos, o aluno está aprovado, caso contrário estará reprovado. Listagem 1. Método calcularAprovacao. 01 public boolean calcularAprovacao(float nota1, float nota2, 02 float notafinal, int frequencia){ 03 float media; 04 05 if (frequencia < 75){ 06 resultado = false; 07 } 08 else{ 09 media = (nota1 + nota2) / 2; 10 if (media < 30){ 11 resultado = false; 12 } 13 else if (media >= 70){ 14 resultado = true; 15 } 16 else if ((media + notafinal)/2 >= 50){ 17 resultado = true; 18 }else{ 19 resultado = false; 20 } 21 } 22 23 return resultado; 24 }

Obtendo a Complexidade Ciclomática Apresentado o estudo de caso, o objetivo agora é obter o número e grafo da complexidade ciclomática antes de iniciar o teste unitário. A ferramenta utilizada neste processo chama-se ComplexGraph, versão 1.0 (veja seção Link s). Após executar a ferramenta, deve ser criada uma nova análise através do menu de opções. O sistema irá permitir inserir o código manualmente em uma tela conforme mostrada Figura 2 , ou também permite localizar o arquivo da classe onde o método está contido. Após confirmada a inserção do código-fonte, deve-se dar início à análise clicando no botão “Iniciar Análise”. A ferramenta irá fazer a leitura do código-fonte fornecido e irá retornar o

grafo da complexidade ciclomática em uma nova tela conforme ilustrado na Figura 3.

Figura 2. Inserção do código-fonte na ferramenta ComplexGraph

Podem ser observadas no grafo da complexidade ciclomática da Figura 3 cinco regiões. O que corresponde a uma complexidade ciclomática igual a 5. Isso significa que o algoritmo possui 5 caminhos de execução diferentes e, portanto, necessita para ser testado com 100% de cobertura, 5 casos de testes que façam o teste percorrer todos esses caminhos. Pode ser observado que cada nó do grafo corresponde a u m comando de desvio que pode ser if, else, case, for, while, entre outros. Além disso, cada aresta possui um intervalo de números que correspondem às linhas de código-fonte referente àquele fluxo, o que pode facilitar na localização no código-fonte. Na tela principal da ferramenta, conforme mostra a Figura 4 , pode ser observado o código-fonte e o resultado da métrica da complexidade ciclomática. Agora pode-se iniciar o processo de criação dos casos de teste. Para o primeiro caminho, tem-se um if que corresponde à verificação de frequência. Essa situação se refere ao caso de teste 1, onde tem-se como entrada o valor da frequência valendo 74, o que fará que o teste retorne como saída reprovado. Para o segundo caminho, tem-se um outro if correspondente à verificação da média menor que 30 e com frequência maior ou igual a 75. Esse será o caso de teste 2, que terá como entrada Nota1 igual a 29 e Nota2 igual a 30, sendo o valor limite para a obtenção de média menor que 30 e, além disso, terá como entrada frequência igual a 75. Com esses dados, espera-se uma saída igual a reprovado. O caso de teste 3 refere-se à verificação da média maior ou igual a 70, com frequência maior ou igual a 75. O caso de teste terá as variáveis Nota1 e Nota2 valendo 70, resultando numa média igual a 70. Além disso, a frequência será igual a 75. O próximo caminho representa quando o aluno não conseguiu média para passar e está de final. O caso de teste 4 deverá Edição 70 - Engenharia de Software Magazine

59

considerar como entrada Nota1 e Nota2 iguais a 30 e notafinal igual a 70. Calculando os resultados, a média final resultará em 50, que faz com que o método retorne aprovado. Por fim, o último caminho representa o aluno sendo reprovado com média final menor que 50. Para isso, o caso de teste 5 Casos de Teste Caso de Teste 1 Caso de Teste 2

Entradas Frequência = 74 Frequência = 75 Nota1 = 29 Nota2 = 30 Frequência = 75 Nota1 = 70 Nota2 = 70 Frequência = 75 Nota1 = 30 Nota2 = 30 NotaFinal = 70 Frequência = 75 Nota1 = 30 Nota2 = 30 NotaFinal = 69

Saída Reprovado Reprovado

terá como entrada Nota1 e Nota2 iguais a 30 e notafinal igual a 69, sendo suficiente para ter média final menor que 50, retornando assim o aluno sendo reprovado. Resumindo, a Tabela 1 apresenta a configuração dos casos de teste. Nesta seção pode-se observar que o cálculo da complexidade ciclomática e o grafo podem auxiliar mais rapidamente a identificação dos casos de teste dentro do código-fonte, percorrendo todos os caminhos de execução do código, garantindo um grau de cobertura maior para o teste unitário.

Executando o Teste Unitário

Com os casos de teste definidos é possível dar in ício ao teste unitário. Para realizar o teste unitário em Java foi aqui utilizada a plataforma Eclipse com o JUnit 4.0 (ver seção Links). Depois, será criado dentro do projeto um diretório com descrição test. Dentro desse diretório será criado um pacote com Caso de Teste 4 Aprovado nome academico.test. Dentro desse pacote pode-se clicar em File >> New >> JUnit Test Case . Nesse momento, foi criado o arquivo que irá armazenar e executar os casos de teste cujo nome será AplicAprovacaoTest e que é apresentado na Listagem 2 . Caso de Teste 5 Reprovado Após criar a classe AplicAprovacaoTest , automaticamente será registrada a importação dos pacotes da ferramenta. Além Tabela 1. Casos de Teste disso, é necessário que seja inserida a importação da classe a ser testada para que possa ser criado o objeto. Analisando o código gerado pela criação da classe de teste, tem-se um método chamado setUp. Ele é responsável pela inicialização do teste, como a instanciação do objeto, por exemplo. Pode ser observado que acima do método existe a anotação @ BeforeTest , significando que esse método deve ser executado pelo JUnit antes de cada método de teste. Já o método tearDown é responsável por finalizar o teste podendo ser usado para liberar memória Figura 3. Grafo da complexidade ciclomática gerado pela ferramenta ComplexGraph ocupada pelo objeto instanciado, por exemplo. Nesse método tem-se a anotação @AfterTest, que indica ao JUnit que o método deve ser executado logo após cada teste ser concluído. Os demais métodos apresentados no código são os casos de teste. Para os métodos de caso de teste foi utilizada a anotação @Test que indica ao JUnit que o método a seguir é um caso de teste. O método possui a seguinte estrutura: primeiro criam-se os atributos correspondentes aos parâmetros do método calcularAprovacao que será testado, depois será instanciado o objeto do tipo AplicAprovacao , logo após será invocado o método calcularAprovacao passando todos os atributos como parâmetros, por fim, será chamado o método Figura 4. Resultados da métrica calculada pela ferramenta ComplexGraph Caso de Teste 3

Aprovado


ENGENHARIA

Listagem 2. Casos de Teste 01 public class AplicAprovacaoTest { 02 03 public AplicAprovacaoTest() { 04 } 05 06 @BeforeClass 07 public static void setUpClass() throws Exception { 08 } 09 10 @AfterClass 11 public static void tearDownClass() throws Exception { 12 } 13 14 @Before 15 public void setUp() { 16 } 17 18 @After 19 public void tearDown() { 20 } 21 22 /** 23 * Test of calcularAprovacao method, of class EstudoCaso1. 24 */ 25 @Test 26 public void testFrequenciaMenor75() { 27 // Frequencia < 75 28 int frequencia = 74; 29 int nota1 = 0; 30 int nota2 = 0; 31 int notafinal = 0; 32 EstudoCaso1 instance = new EstudoCaso1(); 33 boolean expResult = false; 34 boolean result = instance.calcularAprovacao(nota1, nota2, 35 notafinal, frequencia); 36 assertEquals(expResult, result); 37 } 38 39 @Test 40 public void testMediaMenor30() { 41 // Media < 30 42 int frequencia = 75; 43 int nota1 = 29; 44 int nota2 = 30; 45 int notafinal = 0; 46 EstudoCaso1 instance = new EstudoCaso1(); 47 boolean expResult = false;

assertEquals do JUnit que vai comparar o resultado do método

com o resultado esperado. No primeiro caso de teste, na linha 26, é definido um aluno que foi reprovado por insuficiência de frequência, tendo somente o atributo frequência igual a 74. Já na linha 36, é invocado o método assertEquals que foi configurado com o resultado esperado e o resultado obtido pelo método. Caso esse método encontre divergência, o teste unitário acusará um defeito. Para o primeiro caso de teste, o resultado esperado é false. O segundo caso de teste apresenta um aluno sendo reprovado por ter tido média menor que 30 pontos. Para isso, são definidos frequência igual a 75, nota1 igual a 29 e nota2 igual a 30. O valor esperado para esse teste é false. O terceiro caso de teste cobrirá a opção do aluno ser aprovado por possuir média maior ou igual a 70. Para isso, é definida a variável frequência igual a 75, a nota1 e nota2 iguais a 70. O valor esperado para esse teste é true.

48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 }

boolean result = instance.calcularAprovacao(nota1, nota2, notafinal, frequencia); assertEquals(expResult, result); } @Test public void testMediaMaior70() { // Media >= 70 int frequencia = 75; int nota1 = 70; int nota2 = 70; int notafinal = 0; EstudoCaso1 instance = new EstudoCaso1(); boolean expResult = true; boolean result = instance.calcularAprovacao(nota1, nota2, notafinal, frequencia); assertEquals(expResult, result); } @Test public void testMediaFinalMaior50() { // (Nota Final + Média)/ 2 >= 50 int frequencia = 75; int nota1 = 30; int nota2 = 30; int notafinal = 70; EstudoCaso1 instance = new EstudoCaso1(); boolean expResult = true; boolean result = instance.calcularAprovacao(nota1, nota2, notafinal, frequencia); assertEquals(expResult, result); } @Test public void testMediaEntre30e70eMediaFinalMenor50() { // Media entre 30 e 70 e Média na Prova Final < 50 int frequencia = 75; int nota1 = 30; int nota2 = 30; int notafinal = 69; EstudoCaso1 instance = new EstudoCaso1(); boolean expResult = false; boolean result = instance.calcularAprovacao(nota1, nota2, notafinal, frequencia); assertEquals(expResult, result); }

Para o quarto caso de teste é configurado um aluno que está de final e que foi aprovado por ter média de final maior ou igual a 50. A frequênc ia é mantida igual a 75, as notas 1 e 2 iguais a 30 e a notafinal igual a 70. Espera-se que o aluno seja aprovado. Logo, o método assertEquals é configurado para comparar o resultado com true. Por fim, tem-se o caso de t este 5, que representa o a luno que não conseguiu média e não conseguiu nota suficiente na prova final. Com isso, sua f requência é 75, as notas 1 e 2 iguais a 30 e a nota final igual a 69, resultando false . A classe Assert apresenta também outros métodos para definição de valores esperados além do assertEqual. Os principais são: assertFalse , se o parâmetro definido é false; assertTrue , se o parâmetro definido é verdadeiro; assertSame, se os parâmetros são iguais; assertNotNull , se o parâmetro definido não é nulo; e assertNull, se o parâmetro é nulo. Edição 70 - Engenharia de Software Magazine

61

Para executar o teste unitário, basta executar a classe Aplic AcademicoTest. Logo em seguida, irá aparecer uma interface da ferramenta JUnit contendo o resultado do teste. Na Figura 5 , pode-se observar o resultado do teste unitário aplicado para os casos de teste criados. Segundo o resultado apresentado, todos os casos de teste foram executados com sucesso, ou seja, para os valores de entrada fornecidos, o método de aferição de aprovação do aluno reagiu como o esperado.

Figura 6. Resultado da JUnit com um defeito detectado

Figura 5. Resultado do Teste Unitário

Entretanto, deve-se prestar bastante atenção ao elaborar casos de teste, pois se forem estipulados valores de entrada incorretos, pode-se comprometer a validade do teste. Além disso, se forem configuradas as saídas esperadas do teste de maneira errada, a qualidade do teste também estará comprometida. Por isso, os testes devem ser bem planejados. Por exemplo, suponha que na linha 13 da Listagem 1 a média, em vez de ser >= 70, tenha sido codificada de forma errada, somente > 70. Ao execute o teste novamente, o teste unitário irá acusar um erro no caso de teste 3, pois quando a média valer 70, o método irá retornar false e o esperado seria true. Esse caso representa um defeito por um descuido na comparação da média, que não seria identificado se os casos de teste não tivessem sido bem definidos, utilizando os valores corretos através da comparação dos limites das condições. A Figura 6 apresenta o resultado da ferramenta com esse defeito inserido no código-fonte.

Aplicando o Teste de Cobertura Após aplicado o teste de unidade, é importante que se ja executado o teste de cobertura para avaliar o grau de cobertura dos casos de teste executados pelo teste de u nidade.

O principal objetivo desse teste é ajudar a identificar áreas que não estão sendo cobertas pelos casos de teste e, assim, alertar ao desenvolvedor que faltam áreas no código a serem testadas. Para efetuar o teste de cobertura será utilizada a ferramenta Eclemma (ver seção Link), que é fornecida como plugin para o Eclipse. Após a instalação do plugin deve-se habilitá-lo no teste acessando o menu “Run >> Covarage...”, depois clica-se em “Coverage” e observa-se os resultados. O teste irá sinalizar no código-fonte a área que foi coberta pelo teste unitário e, neste caso, o trecho irá ficar verde. A área que ficar vermelha representa que o teste não executou aquele caminho do códigofonte, podendo o desenvolvedor identificar, criar o caso de teste que faltou, ou corrigir o código-fonte e executar o teste unitário novamente. Esse processo pode repetir-se até que o desenvolvedor atinja uma cobertura desejável. Na Figura 7 pode ser observado o resultado do teste de cobertura para o estudo de caso proposto. Todo o trecho do código ficou verde, ou seja, os casos de teste elaborados cobriram 100% o código-fonte, garantindo assim um teste de unidade mais eficiente e de qualidade. Na Figura 8 é exibida a porcentagem de cobertura de cada método da classe. Este artigo apresentou a aplicação do teste unitário utilizando a ferramenta JUnit com o apoio das ferramentas ComplexGraph e Eclemma. Foi possível perceber que a ComplexGraph fornece para o teste unitário o número e o grafo da complexidade ciclomática de um código-fonte favorecendo na identificação dos casos de teste necessários para executar o teste unitário.


ENGENHARIA

Ao final, foi executado o teste de cobertu ra com a ferramenta Eclemma para verificar o grau de cobertu ra do teste unitário. Ao final do estudo de caso, o teste de cobertura resultou em um grau de cobertura de 100% devido a todos os casos de testes terem sidos rodados corretamente em todos os caminhos de execução do código-fonte. A ferramenta ComplexGraph ainda possui algumas limitações, mas pode ser observado seu benefício para o estudo de caso aplicado. Ter uma ferramenta que informe o número de casos de teste que devem ser construídos e gerar um grafo para que o desenvolvedor localize no código-fonte os caminhos de execução, pode ajudar e facilitar na criação dos casos de teste. Figura 7. Resultado do Teste de Cobertura

Links: Ferramenta ComplexGraph http://code.google.com/p/complexgraph

Ferramenta JUnit http://junit.org/

Ferramenta Eclemma http://www.eclemma.org/ Figura 8. Resultado do Teste de Cobertura com o percentual de cada

classe



63

Engenharia de Software - Edição 70

Recommend Documents