Engenharia de Software - Edição 45

engenharia de software

e n i z a g a m

Edição 45 - Ano 04

Teste Testes funcionais de software Projeto Dando foco ao negócio com DDD

Gerenciamento Ferramentas para Gestão de Projetos

Segurança da Informação Conhecendo Conhecen do a ISO 15408

Agilidade PMI versus Scrum: O equilíbrio será possível?

Desenvolvimento Conheça técnicas para manter seu código “limpo” – Parte 7

Rodrigo Oliveira Spínola [email protected] Doutor e Mestre em Engenharia de Software pela COPPE/UFRJ.Autor de diversos artigos científicos sobre Engenharia de Software publicados em revistas e conferências renomadas,dentro e fora do país.Experiência de participação em mais de 20 projetos de consultoria para diferentes empresas tendo atuado com gerência de projetos, requisitos e testes de software.Implementador certificado do MPS.BR,tendo também experiência atuando junto a empresas certificadas CMMI.

Marco Antônio Pereira Araújo

Ano 4 - 45ª Edição - 2012

[email protected] Doutor e Mestre em Engenharia de Sistemas e Computação pela COPPE/UFRJ - Linha de Pesquisa em Engenharia de Software,Especialista em Métodos Estatísticos Computacionais e Bacharel em Matemática com Habilitação em Informática pela UFJF,Professor e Coordenador do curso de Bacharelado em Sistemas de Informação do Centro de Ensino Superior de Juiz de Fora,Professor do curso de Bacharelado em Sistemas de Informação da Faculdade Metodista Granbery,Professor e Diretor do Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas da Fundação Educacional D.André Arcoverde,Analista de Sistemas da Prefeitura de Juiz de Fora,Colaborador da Engenharia de Software Magazine.

Corpo Editorial Editor Rodrigo Oliveira Spínola Colaboradores Marco Antônio Pereira Araújo Eduardo Oliveira Spínola

Eduardo Oliveira Spínola

Jornalista Responsável Kaline Dolabella - JP24185

[email protected] É Colaborador das revistas Engenharia de Software Magazine,Java Magazine e SQL Magazine.É bacharel em Ciências da Computação pela Universidade Salvador (UNIFACS) onde atualmente cursa o mestrado em Sistemas e Computação na linha de Engenharia de Software,sendo membro do GESA (Grupo de Engenharia de Software e Aplicações).

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

Atendimento ao Leitor 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: www.devmedia.com.br/mancad (21) 3382-5038

Fale com o Editor! É muito importante para a equipe saber o que você está achando da revista: que tipo de artigo você 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 SQL Magazine, entre em contato com os editores, informando o título e mini-resumo do tema que você gostaria de publicar. Apoio

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

EDITORIAL

N

ão há mais dúvidas de que a indústria de software é uma das mais im-

Neste contexto, esta edição da Engenharia de Software Magazine destaca

portantes atualmente. O mercado brasileiro brasileiro de software e serviços de TI, segundo o último relatório da ABES, é de US$ 19 bilhões e cresce de 25% a 30% ao ano desde 2004. Porém, grande parte do software produzido

como tema de capa Kanban. Para isso, traz dois artigos muito interessantes sobre o tema: “Kanban no desenvolvimento de projetos de software” e “Kanban: o ágil adapta adaptativo” tivo”.

ainda é defeituoso, inadequado aos desejos do cliente, entregue fora do prazo e acima dos custos esperados.

Além destes dois artigos, teremos mais seis nesta edição:

Neste cenário, temos observado mais recentemente ao surgimento do Kanban. A história do Kanban para desenvolvimento de software, assim como a história da grande maioria das metodologias, modelos de maturidade, proces-

• Ferramentas para Gestão de Projetos • Conhecendo a ISO 15408 • Testes funcionais de software

sos de desenvolvimento e processos em geral, começa com um grande dese jo, muitas ideias, tes tes ( na p rática) e diver sos ajustes até atingir os pr imeiros casos de sucesso.

• Dando foco ao negócio com DDD • Boas práticas para escrita de métodos, funções e procedimentos – Parte 7

A principal diferença do Kanban para as demais metodologia metodologiass de desenvolvimento de software atuais é que ele foi um modelo adaptado de outra indús-

Desejamos uma ótima leitura!

tria, a de manufatura, mais especificamente da Toyota. Kanban (com K maiúsculo) é um método de mudança evolutivo para monitoramento e melhoria de processos de produção, que utiliza kanban (com k minúsculo) para auxiliar

Equipe Editorial Engenharia de Software Magazine

na visualização do fluxo e para permitir a criação de um sistema puxado de trabalho além de outras ferramentas para catalisar a introdução de ideias Lean nas áreas de desenvolv desenvolvimento imento de software e operações de TI.

• PMI versus Scrum: O equilíbrio será possível?

ÍNDICE Agilidade Fundamentos 06 - Kanban: o ágil adaptativo Flavio S. Mariotti

11 - Kanban no desenvolvimento de projetos de software Thiago Ghisi

17 - PMI versus Scrum: O equilíbrio será possível? Luiz Carlos Vianna

Engenharia Fundamentos 23 - Ferramentas para Gestão de Projetos Aline da Silva Tinoco Tinoco e Marco Antônio Pereira Pereira Araújo Araújo

31 - Conhecendo a ISO 15408 Dayana Fernanda Trapp Trapp e Rodrigo Oliveira Spínola

37 - Testes funcionais de software Elisângela Andrade Bruno, Paulo Paulo C. Barreto da S ilva e Thiago Salhab Alves

Arquitetura e Desenvolvimento 42 - Dando foco ao negócio com DDD Robson Castilho

49 - Boas práticas para escrita de métodos, funções e procedimentos – Parte 7 Jacimar Fernandes Tav Tavares ares e Marco Marco Antônio Pereira Pereira Araújo

Edição 05 - Engenharia de Software Magazine

5

Fundamentos da Agilidade Nesta seção você encontra artigos voltados para a prática de métodos ágeis.

Kanban: o ágil adaptativo Introduzindo Kanban na equipe ágil De que se trata o artigo? Este artigo traz uma breve abordagem do modelo Kanban. O objetivo é apresentar o sistema Kanban e explicar sua proposta. Entender o conceito de visualização e o porquê algo tão simples pode fazer uma diferença tão grande na qualidade dos resultados.

maduras e eficientes no que se propõe? Como identificar onde estão os “gargalos” que fazem as equipes falharem nos seus sprints? Podemos dizer com que o Kanban pode ajudar a identificar essas falhas e solucioná-las.

Resumo? Em que situação o tema é útil? Nos últimos anos o conceito de metodologia ágil vem movimentando o mundo de desenvolvimento de software. Metodologias mais populares como Scrum e XP, criadas nas fabricas de software, vem ganhando cada dia mais espaço nas empresas de tecnologia. Essas ferramentas surgiram com a proposta de melhorar e agilizar os processos envolvidos no desenvolvimento de software, porém no mundo real fica claro que os processos ainda não estão “perfeitos”. Mas o que fazer então, sendo que ess as ferramentas estão, teoricamente,

O método Kanban para desenvolvimento de software e processos ágeis tem como ênfase não sobrecarregar os membros que compõe a equipe de criação do produ to. Por isso, o método contem princípios básicos como: a equipe ou membro deve iniciar uma nova tarefa quando é capaz de realizá-la agora, a equipe deve aceitar mudanças incrementais e evolutivas estimuladas pelo método Kanban e respeitar os atuais processos, papéis e responsabilidades. Neste sentido, este artigo irá apresentar o siste ma Kanban e explicar sua proposta.

Flavio S. Mariotti [email protected]

Especialista em Engenharia e Arquitetura de Software. Pós Graduado pelo Instituto de Pesquisa Avançada de Tecnologia IBTA em Engenharia de Software baseado em SOA. Bacharel em Sistemas de Informação pela UNIUBE e técnico em Processamento de Dados pela FEB. Consultor independente no desenvolvimento de software em arquitetura OO, SOA, GIS e Plataforma .NET.

6

O

Kanban é baseado na ideia onde atividades em andamento devem ser limitadas. Um novo item só pode ser iniciado quando o item em andamento é finalizado ou quando uma função automática inicia o mesmo instantaneamente.

Engenharia de Software Magazine - Kanban: o ágil adaptativo

O Kanban, basicamente, tem como principal objetivo transformar o tra balho em andamento visível para toda equipe, criando um sinal visual que indica que o novo trabalho pode ou não ser iniciado e se o limite acordado para cada fase está sendo respeitado.

AGILIDADE

Neste momento, provavelmente você está se perguntando, o que isso tem de interessante? David J. Anderson teve essa mesma sensação e segundo ele “A teoria do Kanban não soa muito revolucionária nem parece afetar profundamente o desempenho, cultura, capacidade e maturidade de uma equipe e a organização na qual está inserida. Mas o impressionante é que afeta! O Kanban parece uma mudança pequena e, no entanto, muda tudo a respeito de uma empresa.” Portanto, o Kanban não é um processo e nem descreve papeis e faces para serem seguidos. Podemos dizer que o Kanban é uma abordagem para mudança gerencial do projeto, um conceito para introduzir alterações em um ciclo de desenvolvimento de software ou gerenciamento de projetos. Os métodos ágeis fornecem transparência sobre as atividades em andamento e concluídas, e reportam métricas com velocidade. O Kanban, no entanto, vai um passo além e dá transparência ao processo e seu fluxo, expondo gargalos, filas, variabilidade e desperdícios. Portanto, tudo que impacta no desempenho da equipe de produção e para entrega de valor, fica explícito no modelo Kanban.

O que é Kanban? O nome Kanban é de origem japonesa e sua tradução seria como “sinal” ou “cartão”. Portanto, vamos chamar de sinalizador ou melhor “registro visual”. O nome Kanban surgiu dos sistemas de cartão usados nas indústrias de produção, que tinham como finalidade o gerenciamento do fluxo de trabalho através da organização de desenvolvimento. O Kanban, com seu mecanismo de sinalização, tem como objetivo apresentar uma atividade de trabalho em processo, ou seja, o número de atividades ou cartões em circulação é equivalente à capacidade do sistema. Uma outra característica importante do modelo Kanban é o conceito de “puxar tarefa” quando há capacidade de processála. Esse recurso vai de encontro ao tradicional modelo de “empurrar tarefa” conforme sua demanda, mantendo assim o bom desempenho da equipe. Portanto, ao invés dos membros que produzem o produto receberem atividades conforme suas demandas, os requisitos são adicionados a lista de backlog e “puxados” pelos membros que liberam suas atividades correntes e se tornam disponíveis para iniciar uma nova tarefa. Uma boa metáfora que descreve essa regra é imaginarmos uma rodovia que suporta até 100 veículos para ma nter o fluxo de trafego com um bom desempenho, porém em todos os feriados essa rodovia recebe em torno de 200 veículos. Essa demanda não suportada pela rodovia gera um congestionamento afetando consideravelmente o desempenho do trafego. Logo, não adianta empurrar um numero de atividades não suportada pela equipe, isso irá causar um “congestionamento” e afetar o desempenho de produção. A implementação do modelo Kanban se resume em três etapas que são: • Visualizar os processos; • Limitar o trabalho em processo do inglês WIP (work in progress);

• Gerenciamento do lead-time, ou seja, tempo que a ativi dade leva para passar por todas as fases até a sua entrega.

O sistema Kanban Para entendermos a proposta desde conceito, vamos primeiro estudar o sistema Kanban. Vamos chamar as tarefas que compõe o painel Kanban de cartões. O número de cartões representa a capacidade limite acordada em cada fase de um sistema que são colocadas em circulação. Cada cartão funciona como um mecanismo de sinalização e o sistema só permite iniciar uma nova tarefa quando um cart ão está disponível. É muito importante respeitar essa regra, e fazer com que qualquer novo trabalho espere em uma fila até que um cartão se torne disponível. O sistema Kanban fornece um método simples, barato e fácil de implementar e rapidamente começa a apresentar resultados permitindo gerenciar o limite de atividades em andamento e garantindo o bom desempenho da equipe.

Afinal, por que usar um sistema Kanban? Ao entender a proposta de um sistema Kanban, se torna simples perceber que o uso de um sistema prepara e limita o trabalho em andamento para uma capacidade suportada pela equipe. Esse recurso proporciona o equilíbrio da demanda de uma equipe controlando o seu rendimento, e consequentemente, acelerando sua produção. É simples deduzir que todas as pessoas produzem mais quando conseguem equilibrar a vida pessoal e profissional. O Kanban buscar atingir um ritmo sustentável de desenvolvimento para que todos os indivíduos possam alcançar esse objetivo entre vida pessoal e profissional. Segundo David J. Anderson, “O Kanban rapidamente elimina as questões que prejudicam o desempenho, e desafia uma equipe para se concentrar em resolver essas questões a fim de manter um fluxo constante de trabalho”. O Kanban atua fornecendo visibilidade nos processos, deixando explícito os problemas e prendendo o foco da equipe em qualidade. Portanto, este comportamento reflete os defeitos, pontos de sobrecarga, custos econômicos sobre o fluxo de rendimento e a variabilidade. A simples regra de limitar os trabalhos em andamento no sistema Kanban estimula maior qualidade e maior desempenho na execução de cada tarefa. O Kanban, com a combinação de fluxo, contribui para a redução do estresse da equipe e melhora a previsibilidade e colaboração, refletindo com isso, nas datas de vencimento para entrega de tarefas. Com a equipe produzindo e cumprindo os prazos de liberação, o Kanban ajuda a fortalecer os laços de confiança dos clientes, parceiros, fornecedores e outras entidades relacionadas. Ao aplicar o Kanban, respeitando suas pequenas exigências, o sistema tende a contribuir para a maturidade da equipe, podendo até afetar a cultura organizacional da empresa. Com a identificação de falhas, a equipe consequentemente concentra-se em uma força tarefa para resolvê-las, e por contar com maior contribuição da equipe, a tendência é de prevenir problemas futuros.


7

Por conta desta “filosofia”, o Kanban vem mostrando eficiência e ganhando diariamente diversos profissionais que se renderam aos benefícios proporcionados por ele.

Aplicando o sistema Kanban no desenvolvimento de software Para o desenvolvimento de software, é comum o uso de um sistema Kanban digital. Porém, pode-se manter o conceito de painel físico e digital, isso é reconhecido como boa prática uma vez que ele mantém o princípio de sinalização visual. Algumas empresas tem implementado o Kanban físico utilizando lousas, painéis, paredes ou tabuleiros. Na verdade, não existe um objeto recomendado para usar, o importante é que este painel seja visível, atingindo o conceito de sinalizador visual. Ainda neste artigo serão apresentados alguns modelos de painel Kanban. É importante lembrar a alguns profissionais que vem usando paredes ou até mesmo portas do escritório para sinalizar as atividades em andamento que, mesmo essa técnica conseguindo servir como sinalizador visual das atividades em andamento, não podemos considerar isso um modelo Kanban. Para ser um sistema Kanban é necessário existir a ideia de puxar tarefas, conforme o limite acordado em cada fase, ou seja, para se tonar um sistema Kanban é necessário aplicar as três etapas cruciais que são: criar o painel de visualização, limitar os processos WIP e gerenciar o lead-time, aplicando o conceito de puxar uma nova tarefa quando um cartão está disponível.

Priorização Ao aplicar os três primeiros passos para a implementação do modelo Kanban, os resultados tendem a aparecer com: códigos de alta qualidade, lead-time de desenvolvimento relativamente curto, e controle do desempenho de produção. O gerenciamento do limite deve ser feito de forma rígida, evitando a priorização de exceções imprevistas no negócio, e focando no desenvolvimento dos itens conforme acordado na estratégia do projeto. É recomendado que a atenção da gest ão seja mais dedicada para melhorar a capacidade e previsibilidade de entrega.

Buscando a maturidade na produção Para alcançar o adjetivo maturidade, é fundamental que a equipe primeiro busque aprender a construir códigos de alta qualidade e equilíbrio no trabalho em andamento para cumprir suas datas de entrega. A busca pela qualidade está conectada com a velocidade no nível de produção. O desempenho da equipe de desenvolvimento pode ser fortemente beneficiada com a eliminação de retrabalhos, com isso, a equipe pode alcançar um ritmo de produção de alta performance.

Comportamento emergente com Kanban O Kanban foi implementado na Corbis em 2007 pelo seu idealizador David J. Anderson. Este trabalho resultou em uma lista de comportamentos emergentes que vem crescendo

8


rapidamente com novas implementações Kanban. É provável, e esperado, que esta lista cresça à medida que aprendemos mais sobre os efeitos do Kanban nas empresas. Os comportamentos que preenchem a lista atualmente são: 1. Processos limitados e adequados para cada fluxo do projeto; 2. Desenvolvimento sem a necessidade de iteração; 3. Gerenciamento do custo de implementação; 4. Valores otimizados para classes de serviços; 5. Gerenciamento de risco com alocação de capacidade; 6. Gestão quantitativa; 7. Tende a atingir outros departamentos; 8. Mescla pequenas equipes e proporciona um maior grupo de trabalho.

Sinalizador visual Kanban O sinalizador visual Kanban funciona como uma ferramenta de sinalização de processos, deixando explícito o fluxo de valor através do processo em andamento. Para os adeptos ao Scr um, o quadro Kanban pode ser comparado ao recurso de quadro/ placa Scrum para visualização de tarefas. Assim como a sequência de colunas que representam os diferentes estados de uma tarefa existente durante o processo de desenvolvimento, o cartão ou sinalizador Kanban é movido de uma fase ou estado para outro, até que tenha sido aprovado para entrega. Um quadro simples representando o sistema Kanban pode conter as seguintes etapas: análise, desenvolvimento, aceitação e implantação. Esse modelo, à primeira vista, pode lembrar o conceito da engenharia de cascata, porém na prática, o Kanban não atua como o cascata e evita os problemas decorrente do conceito. O Kanban tem como linha de produção a regra de limitar o processo em andamento, o WIP, essa regra evita as falhas apresentadas pela engenharia cascata. A teoria do sistema Kanban no quadro visual é aplicada com a regra em que cada coluna terá um WIP estabelecido e representados pelo número máximo de cartões em cada fase. O cartão é composto por uma breve história do usuário, descrevendo seus requisitos. Todo cartão entra na fila de backlog e aguarda a liberação de capacidade para entra r nas colunas seguintes. Quando as atividades envolvidas com o cartão na coluna em andamento são finalizadas, o mesmo é movido para a coluna seguinte, liberando espaço para entrada de um novo cartão. O procedimento aplicado acima gera o conceito de “puxar cartões” para in icialização. A prioridade dos cartões a serem iniciados deve seguir as exigências e estratégias do projeto.

Exemplos de sinalizadores visuais Kanban O quadro de sinalização visual do Kanban é uma das principais etapas propostas pela ferramenta, porém, cabe ressaltar que ao aplicar o limite de trabalho em andamento e determinar o lead-time, é importante customizar o quadro conforme suas necessidades.

AGILIDADE

Nesta etapa do artigo, será apresentado um modelo de quadro Kanban. Este exemplo será customizado conforme as necessidades da equipe. O importante é respeitar as poucas política s exigidas pelo Kanban, e depois customizar na tentativa de acelerar e aperfeiçoar o conceito de comunicador visual. A Figura 1 ilustra um modelo simples de sinalizador visual Kanban. Nesta representação, fica fácil identificar o limite de cartões estabelecidos para cada fase. Este limite está representado pelos números em vermelho no cabeçalho. Os cartões ilustrados pelos retângulos representam uma breve história dos usuários, ou seja, as demandas. As imagens com formato de rosto representam os responsáveis pelos trabalhos em andamento. Portanto, este exemplo aplica as três etapas cruciais para obter os benefícios alcançados com o sistema Kanban.

o sprint. A entrega com atraso apresenta riscos e tende a afetar o desempenho da produção, afetando significativamente o resultado de valor entregue ao cliente. O Scrum propõe aos membros da equipe a trabalharem juntos em apenas uma necessidade antes de iniciar um novo item. O Kanban aplica essa orientação de forma implícita e explícita, definindo um limite no número de itens em andamento. Ao limitar a quantidade de trabalho em andamento, a equipe é, consequentemente, forçada a colaborar na busca por solução nos itens que apresentam riscos para o desempenho do desenvolvimento. Outro benefício alcançado com a aplicação de limites de trabalho em andamento é o gan ho do conceito de puxar novos itens, o que garante que nunca a demanda excede a capacidade de produção. É recomendado que os limites sejam estabelecidos pela equipe em colaboração e a equipe de administração ou gestão do projeto. Isso contribui para otimização no fluxo de trabalho. Essa colaboração também implica na gestão alinhada com a estratégia do negócio e proteção do limite WIP.

Benefícios alcançados com o Kanban

Figura 1. Ilustração de um sinalizador visual Kanban

É importante ressaltar que o desenvolvimento de um quadro Kanban irá evoluir conforme as necessidades de cada organização. Algumas empresas vêem incluindo uma coluna chamada “Refletir”. Esta fase propõe uma reflexão por cada cartão que chega ao estado final do processo. Esta coluna é adicionada ao quadro na tentativa de aplicar melhoria continuada em todos os processos. Mattias Skarin publicou recentemente em seu blog dez diferentes quadros de visualização. Na apresentação de cada modelo proposto por Mattias Skarin, fica clara a evolução dos sinalizadores conforme a necessidade de cada equipe. Conheça mais acessando o endereço: http://blog.crisp.se/2009/11/16/ henrikkniberg/1258359420000.

Trabalhando com processos limitados O Kanban vai além de rastrear e demonstrar visualmente o progresso de uma atividade em andamento. No Kanban, o conceito de limitar o que deve ser feito é aplicado em todas as colunas do quadro. Essa é uma maneira rápida de reduzir o lead-time. Para os usuários do Scrum, essa é uma diferença fundamental entre o quadro Scrum e o quadro Kanban. Um dos desafios comuns enfrentados com o Scrum é o atraso na entrega conforme

Alguns estudos vem mostrando os diversos benefícios alcançados pelas equipes que adotaram o Kanban. Algumas vantagens observadas são: falhas tornam-se claramente visíveis em tempo real; o benefício de encontrar os “gargalos” faz com que as pessoas passem a colaborar ainda mais para a cadeia de valor em vez de apenas fazerem a sua parte. Um outro aspecto interessante do modelo Kanban é que ele fornece uma evolução gradual do processo cascata para o modelo de desenvolvimento ágil de software. Com isso, vem conquistando as empresas que ainda não tinham se rendido às metodologias ágeis. O fato de poder fazer desenvolvimento de software ágil, sem necessariamente ter que usar o t ime-box, iterações e sprints de Scrum, torna o modelo mais amigável e fácil de ser adotado. Outro benefício relevante observado com o uso do Kanban é que, naturalmente, o conceito tende a se espalhar para outros departamentos da organização, aumentando a visibilidade de tudo o que está acontecendo na empresa.

Combinando métodos ágeis Uma dúvida frequente nas discussões e fóruns sobre metodologias ágeis é: posso utilizar Kanban junto com meu processo atual? A resposta é simples e positiva, SIM. O Kanban vem com a proposta de agregar. Portanto, o primeiro passo é visualizar o processo atual adotado pela empresa, e implementar os conceitos Kanban para encontrar os gargalos existentes no processo.

Mitos e verdades do Kanban Como toda metodologia, o Kanban já vem recebendo algumas características que não condizem com a realidade. Uma delas é o mito que o Kanban não é um processo com iterações. Na verdade, a iteração Kanban pode ser usada se necessária. Esse recurso é opcional, o importante é fazê-lo somente se existe uma necessidade em seu contexto.


9

Outro mito comum sobre o Kanban é dizer que não se usa estimativas, na verdade esse também é um item opcional, e requer cuidado com o uso desse recurso. Um erro comum visto em debates sobre Kanban é dizer que esse modelo é melhor que Scrum, XP, RUP e etc. O Kanban é apenas mais uma ferramenta do processo, e não há tal comparação para determinar qual é melhor ou pior. Outro erro é dizer que o Kanban veio para substituir as tradicionais metodologias ágeis. Novamente cabe lembrar que o Kanban é apenas um recurso que interfere sobre o gerenciamento de fluxo de trabalho, portanto, sua proposta não é substituir nenhuma ferramenta, e sim, implementar os conceitos de mudança de unidade, aplicando o modelo visualização, limites de WIP e evoluir com seus resultados.

Conclusão Com este artigo podemos concluir que o Kanban permite de forma efetiva visualizar o f luxo de trabalho e dividir o trabalho em partes, escrevendo cada item em um “cartão” e incluindo ele no painel de visualização. O uso de colunas nomeadas atua como sinalizador, ilustrando onde cada item está no fluxo de trabalho. A aplicação de limite de trabalho em progresso (WIP work-in-progress) em cada coluna contribui para gestão e diminuição do lead-time. É provável que diversas equipes de software adotem o Kanban, sendo que algumas podem adotar o Kanban definitivamente, enquanto outras equipes usarão Kanban no nível de portfólio de projetos, continuando a utilizar outras metodologias no nível de equipes pequenas. Kanban ainda é uma ferramenta muito nova e vem se estendendo desde pequenas equipes para o projeto de portfólio

10


até o fluxo de valor da organização. A verdade é que várias empresas vem buscando alinhar seus esforços e ganhar vantagens competitivas em seus mercados, e o Kanban, sem dúvida, pode ser uma ferramenta de auxilio na busca de uma produção com alto desempenho. Links

Limited WIP Society http://www.limitedwipsociety.org/ InfoQ - Kanban http://www.infoq.com/Kanban Kanban and Scrum making the most of both http://www.infoq.com/minibooks/kanban-scrum-minibook David J.Anderson, Kanban: Successful Evolutionary Change for Your Technology Business, 2010. Jim Benson; Tonianne DeMaria Barry, Personal Kanban, 2011. John M. Gross; Kenneth R. McInnis, Kanban Made Simple, 2008.

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! Dê seu voto sobre este artigo, através do link: www.devmedia.com.br/esmag/feedback

u

e s ê

F eedb a c k

D

o

s

b

r

e

e

s

t a e


Kanban no desenvolvimento de projetos de software Entendendo os desafios e a receita para o sucesso De que se trata o artigo?

Resumo?

Neste artigo será apresentado o método Kanban, uma interessante e simples abordagem para monitoramento e melhoria de processos de software que tem uma forte inspiração no Sistema Toyota de Produção.

O método Kanban para desenvolvimento de software a cada ano ganha mais destaque na indústria de TI, pois vem conseguindo promover a melhoria contínua no processo de tr abalho de muitas equipes de empresas das mais variadas áreas de negócio e tamanho. Nesse artigo é apresentada uma introdução ao método Kanban, destacando os seguintes tópicos: • Histórico e as motivações que levaram David Anderson a fazer a adaptação do método da indústria de manufatura (Toyota) para a indústria de software; • As cinco propriedades centrais e o funcionamen to do método; • Kanban pode ser considerado um método ágil? • Um guideline para ter sucesso com o método Kanban, focando principalmente no que deve ser priorizado para se obter as melhorias mais significativas mais cedo.

Em que situação o tema é útil?

Thiago Ghisi [email protected] / @thiagoghisi

Pós-graduando em Gestão de Negócios (UNISUL). Bacharel em Ciência da Computação (UNISUL, 2011). Técnico em Redes de Computadores (SENAI, 2005). É consultor certificado para implementação do MPS.BR e Sun Certified Programmer for the Java Platform, SE 6. Há 6 anos no ramo de tecnologia e desenvolvimento de software, já atuou como: Professor Voluntário de Informática, Técnico em Informática, Pesquisador de Iniciação Científica, Desenvolvedor, QA, Gerente de Projetos, Analista de Sistemas e de Requisitos, Auditor de Garantia da Qualidade (PPQA) e Analista de Processos. Possui experiência na definição e implantação de processos aderentes ao CMMI e ao MPS.BR e, em avaliações MA-MPS nível F e SCAMPI Classe A nível 2. É entusiasta em desenvolvimento ágil desde 2007. Atuamente, trabalha na Nexxera Techpeople, em Tubarão, SC.

Se a sua empresa ou a sua equipe está com dificuldades para melhorar a forma de trabalho, não importando se ela usa ou não métodos ágeis, o Kanban pode ser uma das melhores alternativas para fazer isso com o mínimo de resistência. Além de ser um método muito simples, comparado à maioria das metodologias/frameworks de desenvolvimento atuais, suas propriedades promovem a colaboração.

N

ão há mais dúvidas de que a indústria de software é uma das mais importantes atualmente. O mercado brasileiro de software e serviços de TI, segundo o último relatório da ABES [9], é de US$ 19 bilhões e cresce de 25% a 30% ao ano desde 2004. Porém, grande parte do software produzido

ainda é defeituoso, inadequado aos desejos do cliente, entregue fora do prazo e acima dos custos esperados. Observando esses e muitos outros problemas, há mais de 10 anos, 17 profissionais da área escreveram e assinaram um man ifesto: o manifesto para desenvolvimento ágil de software.


11

Neste, todos concordaram com alguns valores comuns, dentre eles: As metodologias ágeis concentram-se nas pessoas envolvidas na produção; Os planejamentos em longo prazo são falhos; É mais importante aceitar e adaptar-se a mudanças do que seguir planos rígidos; Software funcionando é o melhor indicador de progresso nos projetos de software. •

• •

•

Tendo como base grande parte dos princípios desse mani festo, bem como a filosofia Lean do Sistema Toyota de Produção (TPS – Toyota Production System), surgiu o Kanban para Desenvolvimento de Software. A filosofia Lean tem como objetivo a constante identificação e a eliminação de qualquer espécie de desperdício no sistema de produção. A história do Kanban para desenvolvimento de software, assim como a história da grande maioria das metodologias, modelos de maturidade, processos de desenvolvimento e processos em geral, começa com um grande desejo, muitas ideias, testes (na prática) e diversos ajustes (o método “científico”) até atingir os primeiros casos de sucesso. A principal diferença do Kanban para as demais metodologias de desenvolvimento de software atuais é que ele foi um modelo adaptado de outra indústria, a de manufatura, mais especificamente da Toyota. David Anderson [1] foi o grande responsável por essa adaptação. A história começa em 2002, quando Anderson, cansado de ver equipes de desenvolvimento e departamentos inteiros de TI à mercê de outros departamentos, decide voltar seus esforços para responder a duas perguntas [1]: 1. Como proteger a minha equipe da demanda incessante de negócio e alcançar o que a comunidade ágil chama de ritmo sustentável?

2. Como adotar uma abordagem ágil em toda a empresa e superar inevitáveis resistências à mudança? Como cita em seu último livro, Kanban: Successf ul Evolutionary Change for Your Technology Business [1], publicado em 2010, Anderson tinha um grande desejo: encontrar no setor de TI uma relação “ganha-ganha” entre o departamento de negócio e as equipes de desenvolvimento de software e TI. Na tentativa de atingir esses objetivos, David idealizou, testou e falhou muitas vezes nas diversas organizações em que trabalhou. Ele notou que implantar um processo de desenvolvimento de software total mente prescritivo, na maioria das vezes, não funcionava. Assim, chegou à conclusão que um processo precisava ser adaptado para cada situação, e que para fazer isso, era necessária uma liderança ativa em cada equipe. Porém, esta era muitas vezes inexistente. E, mesmo com uma liderança certa, ele duvidava que mudanças signifcativas acontecessem sem uma metodologia ou, no mínimo, sem orientações de como adaptar o processo para atender a diferentes situações.

12

Para David, sem um conjunto mínimo de orientações para guiar o líder, treinador ou engenheiro de processo, qualquer adaptação no processo estava susceptível a ser aplicada sub jetivamente. Novos times sempre irão resistir a mudanças se você empurrar para eles processos que foram feitos para outras realidades e que tiveram bons resu ltados lá. A conclusão que David chegou é que é preciso ter uma evolução com o novo time de uma forma incremental, partindo do processo que é atualmente seguido. Isso porque: “Cada time é diferente: diferentes conjuntos de habilidades técnicas, capacidades e experiência. Cada projeto é diferente: orçamento, cronograma, escopo e riscos diferentes. E, cada organização é diferente: o processo de produção de software é diferente em cada área de negócio.” [1]. Esse é o principal motivo pelo qual o Kanban é um framework para melhorias. Isto é, ele orienta que o processo de trabalho deve ser customizado em cada time de cada projeto de cada organização. Ou seja, um processo não deve ter suas práticas seguidas à risca da mesma forma em todos os times, de todos os projetos, de todas as organizações do mundo, como a grande maioria das metodologias do mercado prescreve. Em 2005, o método de trabalho de David Anderson era baseado principalmente na Teoria das Restrições (TOC – Theory of Constraints) e na FDD (Feature Driven Development). A Teoria das Restrições foi apresentada pela primeira vez em 1984 por Eliyahu M. Goldratt, no famoso livro A Meta. Segu n do David Anderson [1], “a habilidade de identificar gargalos em um sistema é o primeiro passo para entender a Teoria das Restrições”. O efeito dos sistemas puxados, ou, processo de produção puxado são tópicos que também ajudam a compreender melhor a teoria. Nele, a saída de produtos acabados, tal como o software pronto para ser usado, ao final do processo de desenvolvimento, dita o ritmo da introdução de novos requisitos no sistema. Isso evita acú mulos de produtos inacabados ao longo da linha de montagem, diminuindo a quantidade de trabalho em progresso. Já a FDD é uma famosa metodologia ágil que o próprio David ajudou a criar. Mais tarde, em 2007, após fazer algumas customizações na sua forma de trabalho inspiradas em práticas do Sistema Toyota de Produção, David apresentou nas conferências “Lean New Product Development” e “Agile 2007” os resultados preliminares do uso de Kanban na Corbis, uma empresa fundada por Bill Gates, da Microsoft. Durante certo período, David chegou a ter dúvidas a respeito da eficiência do Sistema Toyota de Produção, mesmo com muitas pessoas falando o contrário. Porém, após conhecer um pouco mais a respeito do pensamento de Taiichi Ohno, um dos criadores de tal sistema, e a ideia por trás da cultura Kaizen (a qual será falada no próximo tópico), David reconheceu, [1] através de experiências ao longo dos cinco anos posteriores a eficiência desse sistema que originou o Kanban. “Kanban (com K maiúsculo) é um método de mudança evolutivo para monitoramento e melhoria de processos de produção, que utiliza kanban (com k minúsculo) para auxiliar na visualização do fluxo e para permitir a criação de

Engenharia de Software Magazine - Kanban no desenvolvimento de projetos de software

AGILIDADE

um sistema puxado de trabalho além de outras ferramentas para catalisar a introdução de ideias Lean nas áreas de desenvolvimento de software e operações de TI. É um processo evolutivo e incremental. Kanban lhe permite atingir processos otimizados para contextos muito específicos, com resistência mínima e mantendo um ritmo sustentável para os trabalhadores envolvidos.” [1].

O método Kanban Como implementar mudanças continuamente no processo de trabalho da equipe com sucesso? Este é um ponto fundamental e um dos motivadores centrais das cinco propriedades do método Kanban: 1. Visualizar o fluxo de trabalho; 2. Limitar a quantidade de trabalho em andamento; 3. Medir e otimizar o fluxo de trabalho; 4. Tornar explícitas as políticas do processo; 5. Gerenciar quantitativamente. O Kanban não é uma metodologia, mas sim um framework para implementar mudanças de forma incremental. Esse é u m conceito muito importante para que se entenda o Kanban como um todo já que, quando se fala em metodologias, fala-se em conjuntos de práticas e o Kanban não tem nenhuma prática prescrita. Há, nele, somente propriedades que devem guiar a melhoria no processo atual, não importando quais práticas estejam sendo usadas. Ao usar o Kanban, como veremos mais detalhes ao decorrer do artigo, é esperado que se consiga visualizar q uais práticas estão sendo positivas e quais estão sendo negativas e isso, consequentemente, vai conduzir a mudanças, que, naturalmente adicionarão, eliminarão ou alterarão as práticas atuais de trabalho. A forma mais comum de se conseguir visualizar o fluxo de trabalho é através de um kanban. Esse é uma espécie de quadro, que pode ser físico, normalmente colocado em uma das paredes do local onde a equipe trabalha, ou virtua l. O uso do quadro virtual tem alguns prós e contras. Os pontos fortes são basicamente a facilidade de extração de métricas e o histórico. O principal ponto fraco dessa abordagem é a dificuldade que a equipe terá para analisar e evoluir conjuntamente o processo de trabalho. Nesse quadro, inicialmente devem ser modeladas cada uma das etapas necessárias para se produzir o software, isto é, todo o workflow de trabalho. E, em cada uma dessas etapas deve ser colocado e mantido um cartão, a fim de simbolizar um trabalho que está em andamento, como podemos ver na Figura 1. Cada um desses cartões deve conter informações detalhadas sobre a atividade, bem como quem está desenvolvendo o item, e quando o mesmo foi iniciado. No Kanban para desenvolvimento de software, o kanban deve ser mantido e evoluído por toda a equ ipe, o tempo todo. A proposta baseia-se em fazer a própria equipe enxergar onde está errando e deixá-la tomar decisões seguindo um framework simples, que guiará grande parte dessas melhorias.

Figura 1. Kanban systems for software development [10]

Para Alisson Vale [5], em atividades que envolvem trabalho criativo, como desenvolvimento de software, o propósito do Kanban é provocar conversações sobre o sistema de trabalho. Para limitar a quantidade de trabalho em andamento é necessário definir, monitorar e manter um limite máximo de tarefas em andamento para cada uma das etapas de trabalho mapeadas no quadro kanban, como visto na Figura 1. Ao estabelecer os limites, a equipe começa a identificar onde estão os principais gargalos do processo de produção e começa a ter que terminar todo o trabalho inacabado na linha de produção para conseguir puxar mais trabalho para o gargalo. Com isso, o trabalho tende a ser finalizado de uma forma incremental e não de uma forma cascata, tornando-se assim um sistema puxado (TOC), onde é a equipe que dita a sua capacidade de produção. O uso do sistema puxado, juntamente com a visualização de todo o processo de desenvolvimento por toda a equipe, permite implementar mudanças no processo de modo incremental. Consequentemente, há redução significativa da resistência, o que facilita o alcance do ritmo sustentável, teoria tão comentada em desenvolvimento ágil, mas para a qual poucas definições existem além das 40 horas semanais de trabalho. Uma citação de David [1] sintetiza isso: “Um interessante efeito colateral de sistemas puxados é que eles limitam o trabalho em andamento (WIP – Work In Progress) para certa quantidade acordada, evitando assim que trabalhadores fiquem sobrecarregados.”. Outro fator importante é o ganho que se tem ao praticamente impedir que uma mesma pessoa execute várias tarefas no mesmo projeto em paralelo. Vale destacar também o processo Just in time (JIT), que evita o acúmulo de estoque ao longo do processo de desenvolvimento, como se faz no ciclo de vida em cascata. Nesse caso, software em estoque são todos os requisitos que ainda não foram liberados para o cliente usar. No desenvolvimento de um software, como em qualquer outra atividade intelectual, por mais contra intuitivo que possa parecer, executa-se com mais qualidade e mais rapidamente duas tarefas fazendo-as uma de cada vez, do que as duas em paralelo o tempo todo.


13

Segundo Rodrigo Yoshima [7], um dos grandes pontos fortes desse método é o modelo embutido nele para trabalhar com a melhoria de processos, o modelo Kaizen. Além do modelo Kaizen, existe o modelo Kaikaku. Vamos às diferenças: “Kaika ku é uma palavra que define mudanças de processos classificadas como “melhoria radical”.” [7]. Implantar o Scrum, por exemplo, exige esse cenário [7], pois o Scrum requer profundas mudanças organizacionais como a gestão abdicar de muitos instru mentos de controle, quebrar com a separação entre os grupos e mudar posições hierárquicas estabelecidas. “Kaizen é a palavra Lean para indicar mudanças de melhoria menores e contínuas. Ao contrário do Kaikaku, Kaizen não é tão traumático, é melhor aceito por todos (gerentes inclusive) e mais simples de implementar. Tudo a nossa volta está suscetível a um evento Kaizen. Kaizen simplesmente significa mudança para melhor.” [7]. Na abordagem Kanban, aplicando a cultura Kaizen, antes de mudar qualquer coisa devemos entender o ambiente de trabalho. Se filas, bloqueios, gargalos ou problemas entre áreas estão nos prejudicando, primeiro, vamos visualizar isso, convencer o grupo dos problemas e usar Kaizen para a melhoria do ambiente com pequenas mudanças incrementais e constantes. Isso irá fortalecer a cultura da empresa, pois ela compreenderá suas falhas com provas palpáveis que serão a motivação para as mudanças [7]. Segundo José Papo [8], além disso, a filosofia e práticas Lean, como é o caso do Kanban, focam na auto-organização do time, na responsabilidade conjunta pelos objetivos de negócio do projeto e na produtividade com qualidade e com ritmo sustentável. Todas elas são práticas de administração consagradas e evidenciadas por Peter Drucker para liderar trabalhadores do conhecimento. As duas últimas propriedades do Kanban citadas (tornar explícitas as políticas do processo e gerenciar quantitativamente) são praticamente atendidas deixando claro para toda a equipe as três primeiras propriedades e reforçando que toda sugestão de otimização no processo deve ter como base modelos matemáticos que provem as métricas.

Kanban é uma metodologia ágil? Nos últimos tempos, acompanhamos uma briga forte entre Kanban e as demais metodologias ágeis, principalmente o Scrum. A polêmica central é: quem usa Kanban é ágil? Rodrigo Yoshima [9] explica que “o maior objetivo do Kanban é melhorar um processo existente, por pior que ele seja”. Ainda segundo Yoshima, o Kanban permite melhorar até mesmo processos que seguem o ciclo de vida em cascata, fazendo eles se tornarem ágeis e podendo melhorar continuamente, e até mesmo superarem o Agile. Isso tudo graças à cultura Kaizen que o Kanban quer trazer à tona. Outro ponto a ser destacado é que para o Kanba n, diferente da grande maioria das metodologias ágeis, não importa qua is práticas você irá aplicar para melhorar o seu processo, o importante é que você tenha argumentos, preferencialmente estatísticos, que expliquem o porquê dessas decisões.

14

Como David ressalta em seu livro [1], a abordagem evolutiva do Kanban, que promove a implementação de mudanças no processo de forma incremental, tem sido controversa na comunidade ágil de desenvolvimento de software. Isso ocorre principalmente porque se sugere que as equipes não adotem um método ou modelo de processo. Vale ressaltar que a atual indústria de serviços e ferramentas desenvolveu-se em torno de um pequeno conjunto de práticas definidas em dois populares métodos de desenvolvimento ágil: XP e Scrum. Depois, com o Kanban, os indivíduos e as equipes estão habilitados para desenvolver suas próprias soluções por meio de um processo único que evitaria a necessidade de tais serviços e ferramentas. Isso porque os mesmos requerem um novo conjunto de ferramentas e serviços muito específicos para cada realidade. Dessa forma, torna-se mais complicado para essa indústria ganhar dinheiro. Tanta discussão acerca do assunto fez o pessoal do Kanban criar um logo de manifesto chamado: Yes We Kanban, que David [1] explica: “O slogan ‘Yes We Kanban’ se destina a enfatizar que você tem permissão. Você tem permissão para tentar Kanban. Você tem permissão para modificar o seu processo. Você tem permissão para ser diferente. Sua situação é única e merece o desenvolvimento de um processo adaptado e otimizado para o seu domínio, o seu fluxo de valor, os riscos que você gerencia, as habilidades de sua equipe e as demandas de seus clientes.”. Portanto, podemos dizer que o objetivo de Kanban não é tornar a sua equipe ágil, e sim, melhorar a forma de trabal ho. Ele tanto pode melhorar processos ágeis como também pode melhorar processos tradicionais.

Qual é a receita para ter sucesso com Kanban? Para que qualquer pessoa que queira ser um agente de mudança na sua organização tenha sucesso rápido (ou, uma melhoria rápida) e com baixa resistência da equipe, com foco na melhoria de processos em algun s pontos com o uso ou até mesmo sem o uso do método Kanban, é preciso seguir algumas etapas. De acordo com David, são elas: 1. Focar na qualidade; 2. Limitar a quantidade de trabalho em progresso; 3. Entregar frequentemente; 4. Balancear demanda com a capacidade máxima; 5. Priorizar tarefas; 6. Atacar fontes de variedade. O autor orienta que essas etapas sejam seguidas na ordem em que são apresentadas. A partir de agora, passa-se a discorrer um pouco a respeito de cada uma delas.

Focando na qualidade Como os agentes de mudanças nas empresas de TI são ge ralmente pessoas com um background técnico, essa tende a ser uma das etapas mais fáceis de ser implementada, principalmente por ser um problema bem entendido por todos. As outras etapas desse guia [1] tendem a ter uma implementação mais difícil porque dependem da colaboração de outras áreas


AGILIDADE

e equipes. Com isso, exigem que o agente de mudança tenha muitas habilidades de negociação, articulação e bastante inteligência emocional [1]. Os maiores geradores de retrabalho em desenvolvimento de software são os defeitos causados principalmente pela baixa qualidade das entregas. E, além de um gerador de retrabalho, baixa qualidade faz os clientes ficarem inseguros e a equipe desmotivada. O incentivo à qualidade das entregas tem um grande impacto na produtividade das equipes com altas taxas de defeitos. Segundo David [1], em equipes verdadeiramente ruins, somente concentrando-se na qua lidade pode-se obter uma melhoria de produtividade de até dez vezes. Para David [1], tanto as técnicas de desenvolvimento ágil como as abordagens tradicionais têm seu mérito para a melhoria da qualidade. As principais práticas incentivadas por ele para a melhoria da qualidade são: 1. Escrever testes automatizados, preferencialmente antes; 2. Revisar código (Verificação); 3. Fazer atividades de análise e design do software de forma colaborativa; 4. Usar Design Patterns; 5. Usar ferramentas modernas de desenvolvimento. Parece haver uma vantagem psicológica em pedir para os desenvolvedores escreverem testes antes, porém, é importante ressaltar que também existem inúmeros casos de sucesso com a escrita dos testes após a codificação. Inspeções ou revisões de código ajudam a melhorar tanto a qualidade externa como, notadamente, a qualidade interna do software. Todas as técnicas têm o seu valor. Programação em par e revisão por pares são alguns exemplos. No entanto [1], inspeções de código são melhores quando são feitas em pequenas quantidades várias vezes. David menciona [1] que ele costuma encorajar as suas equipes a inspecionar código, todos os dias, por pelo menos 30 minutos. Sem dúvidas, quando toda a equipe trabalha em conjunto na análise dos problemas para as soluções de design, a qualidade é superior do que quando apenas uma pessoa faz isso. Assim como as inspeções de código, atividades de modelagem de software devem ser feitas em pequenas quantidades, todos os dias. Os padrões de projeto de software, mais conhecidos pelo termo original em inglês Design Patterns, descrevem soluções para problemas já conhecidos e recorrentes no desenvolvimento de software orientado a objetos. O uso de padrões de projeto garante que defeitos de design sejam eliminados já no início do projeto. O uso de ferramentas modernas de desenvolvimento melhora a qualidade porque a grande maioria dessas inclui funções de análise de código estática e dinâmica, que evitam que os desenvolvedores introduzam problemas básicos e já bem compreendidos, como falhas de segurança, no software.

Limitando a quantidade de trabalho em andamento É fácil especular porque limitar a quantidade de tarefas em andamento aumenta a qualidade. A complexidade do trabalho

do conhecimento, como em desenvolvimento de software, cresce exponencialmente com a quantidade de trabalhos em andamento. Tanto a transferência como a descoberta de informações no desenvolvimento de software é conhecimento tácito por natureza e é criado durante sessões de trabalho colaborativo, face a face. A informação é verbal e visual, mas é em um formato casual, como um esboço em um quadro branco. Nossas mentes têm uma capacidade limitada para armazenar conhecimento tácito. E, quanto mais tempo passa, há mais falhas para recordar detalhes precisos. Assim, uma série de erros é cometida. Equipes que trabalham de um modo ágil, em um mesmo espaço de trabalho, têm uma maior facilidade em reter o conhecimento tácito. Mas, independentemente da forma de trabalho da equipe, o conhecimento tácito se deprecia com o passar do tempo. Por isso, tempos de espera ( lead time) menores são essenciais para os processos que envolvem muito conhecimento tácito. O foco da redução de trabalho em andamento está direta mente relacionado com a redução dos tempos de espera ( lead time). Assim, podemos deduzir que haverá menor depreciação de conhecimento tácito quando temos menos trabalho em progresso – o que resultará em maior qualidade. Em resumo, reduzindo a quantidade de trabalho em a ndamento, melhorase a qualidade e possibilita-se entregas mais frequentes. Isso aumenta a confiança externa na equipe. Além de reduzir a quantidade de trabalho em andamento, é importante reduzir o tempo de uma iteração, pois isso também trará um impacto positivo significativo na qualidade. Segundo David [1], parece que existe uma relação entre a quantidade de trabalho em andamento e a qualidade, ou seja, defeitos vão aumentar com o aumento da quantidade de WIP. Portanto, faz sentido que iterações de duas semanas sejam melhores do que iterações de quatro semanas e que iterações de uma semana sejam melhores ainda. Iterações mais curtas irão resultar em entregas de maior qualidade. Seguindo a lógica das evidências apresentadas, se é sabido que limitar o WIP irá melhorar a qualidade, por que não intro duzir política explícita para isso, deixando assim os gerentes livres para se concentrarem em outras atividades? Essa é justamente uma das propriedades do Kanban. Entretanto David afirma [1] que ainda não existe nenhuma evidência científica desse resultado que foi observado apenas empiricamente.

Entregando frequentemente Para entendermos a importância dessa etapa, David apresenta uma excelente analogia em seu livro [1]: “Quando eu ensino isso nas aulas, eu gosto de perguntar às mulheres da classe o que elas pensam sobre duas situações depois de ter um primeiro encontro com um cara: Situação 1: Eles tiveram um bom encontro, mas depois disso ele não dá sinais de vida a ela durante duas semanas. Mas, então, ele aparece em sua porta com um ramo de flores e um pedido de desculpas; Situação 2: Eles tiveram um bom encontro e na mesma noite a caminho de casa ele envia uma mensagem de texto a ela •

•


15

dizendo: “Eu me diverti muito esta noite. Eu realmente quero me encontrar com você novamente. Posso ligar para você amanhã? E, esse mesmo cara, segue ligando e enviando mensagens dia após dia. Qual cara vocês acham que elas preferem?”. Pequenos e frequentes gestos não custam quase nada, entretanto, eles constroem mais confiança do que grandes e caros gestos ocasionalmente. Portanto, realizar frequentemente pequenas entregas de alta qualidade constrói mais confiança para as equipes parceiras do que entregas maiores, mas com menos frequência.

Balanceando a demanda com a capacidade máxima Construir um consenso em torno da necessidade de equilibrar a demanda contra a capacidade da equipe é crucial. No entanto, para isso, é preciso resolver problemas como a disfunção entre os papéis e as responsabilidades dos membros da equipe. Essa etapa implica definir a taxa em que a equipe aceita novos requisitos no processo de desenvolvimento de software pa ra corresponder com a capacidade em que a equipe pode entregar código de qualidade. Quando se faz isso, fixa-se efetivamente a quantidade de trabalho em andamento, permitindo efetivamente que seja a equipe que crie a demanda de acordo com a sua capacidade (sistema puxado).

Priorizando tarefas Priorizar é trabalho da área de negócios, e não da área de TI da organização. Assim, não deveria ser da competência de um gerente técnico fazer isso. Entretanto, infelizmente, é comum a área de negócios delegar a responsabilidade e deixar um gerente técnico priorizar o trabalho e depois culpar que o gerente fez escolhas erradas. Neste ponto, a atenção da gerência deve-se voltar para otimizar o valor entregue ao invés de meramente a quantidade de código entregue.

Atacando fontes de variedade Podemos entender como fontes de variedade tudo aquilo que de alguma forma prejudica o desempenho do processo de produção. Atacar as fontes de variedade é a última etapa da receita porque alguns tipos de variedade exigem profundas mudanças de comportamento e, consequentemente, uma alta resistênc ia da equipe. A dica para implementar essa etapa é focar nas fontes de variedade que requerem pequenas mudanças de comportamento e que podem ser aceitas facilmente pela equipe. Segundo David [1], não se deve focar nessa etapa sem antes implementar e dominar as primeiras cinco etapas da receita. Resumindo, essa receita é a forma que David [1] acredita que uma equipe de desenvolvimento de software deve amadurecer: “Em primeiro lugar, aprender a construir código de alta qualidade. Em seguida, reduzir o trabalho em andamento,

16

encurtar os lead times, e entregar (software funcionando) com frequência. Em seguida, equilibrar a demanda contra a capacidade máxima, limitar a quantidade de trabalho em andamento, e criar folga para liberar capacidade, o que permitirá a melhoria contínua. Então, com isso funcionando razoavelmente e continuamente otimizando a capacidade de desenvolvimento de software, melhore a priorização para otimizar a entrega de valor.”. O Kanban permite que você implemente todas as seis etapas dessa receita.

Conclusão É interessante conhecer as motivações que levaram David Anderson a chegar até o método Kanban para o Desenvolvimento de Software e, através da sua receita, entender o porque da maioria das propriedades por trás do Kanban. Essa metodologia tem sido um assunto recorrente e tende a continuar sendo, já que é uma forma eficiente de melhorar continuamente a área. Se a sua empresa está com dificuldades para melhorar, não importa se ela adota métodos ágeis ou não, o Kanban pode ser uma das alternativas para fazer isso com o mínimo de resistência, pois, além de toda a simplicidade do método, suas propriedades promovem a colaboração. Referências

1. Anderson, D. (2010) Kanban: Successful Evolutionary Change for Your Technology Business. Washington, Blue Hole Press. 2. Martin, R. (2011) The Clean Coder: A Code of Conduct for Professional Programmers. Indiana, Prentice Hall. 3. Anderson, D. (2003) Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results. New Jersey,Prentice Hall. 4. Bernabó, J. (2011) Mais comprometimento = menos produtividade? http://www.teamware. com.br/blog/mais-comprometimento-menos-produtividade/ 5. Vale, A. (2011) Kanban Explicado. http://www.slideshare.net/alissonvale/kanban-explicado 6.Wikipédia. TOC.http://pt.wikipedia.org/wiki/Teoria_das_restri%C3%A7%C3%B5es 7. Yoshima, R. (2011) Kaikaku – Kaizen, http://blog.aspercom.com.br/2011/09/09/kaikakukaizen/ 8.Papo,J.(2010)PorqueLean/Agile funcionam?http://josepaulopapo.blogspot.com/2010/03/ agile-lean-funciona-por-que.html 9. ABES (2011). O Mercado Brasileiro de Software em 2011. http://www.abes.org.br/UserFiles/ Image/PDFs/Mercado_BR2011.pdf 10. Corey Ladas (2007). Kanban systems for software development (Imagem) http:// leansoftwareengineering.com/wp-content/uploads/2007/08/kanban1.png




u

e s ê

F eedb a c k

D

o

s

b

r

e

o ç

e s t a e


PMI versus Scrum O equilíbrio será possível?

De que se trata o artigo? O artigo trata da utilização em conjunto do PMI e do Scrum para o controle de projetos. O artigo é voltado mais para o ambiente de empresas que não são de TI, mas que a utilizam para atingir os seus objetivos.

Q Luiz Carlos Vianna [email protected]

Atua há mais de 13 anos na área de TI, em diversas áreas - desde gestão, apoio técnico para a equipe de vendas, análise e levantamento de requisitos, consultoria de processos e metodologias, planejamento de arquitetura, desenvolvimento e testes. Engenheiro Elétrico de formação, com pósgraduação em administração e especialização em gestão de projetos. Certificado ScrumMaster, PMP, ITIL e COBIT.

uando falamos de melhoria da produtividade e qualidade na área de desenvolvimento de software, temos visto um embate entre duas grandes vertentes: defensores da gestão de projetos (com maior ênfase ao PMI ), e defensores de métodos ágeis de desenvolvimento (mais fortemente, o Scrum). Com o crescimento do número de empresas (e gerentes de projetos) utilizan do-se de metodologias de desenvolvimento ágeis para ampliar o portfólio de ferramentas de gerenciamento, alguns voluntários do PMI criaram um grupo de pesquisas a respeito da utilização dessas metodologias em projetos. Um dos subprodutos foi a criação de uma certificação voltada para os gerentes de projetos que buscavam se aproximar das práticas ágeis.

Em que situação o tema é útil? Este artigo é útil a todos que desempenham papel como líderes em projetos de TI; a todos os gerentes de projetos que precisam se relacionar com a área de TI em seus projetos; a todos aqueles responsáveis por áreas de TI que estejam buscando uma melhoria na produtividade de seus processos; e a todos que querem conhecer um pouco mais sobre metodologias ágeis em ambientes organizacionais.

Resumo? Atualmente, bastante tem se falado a respeito da utilização do PMI com metodologias ágeis – sendo inclusive tópico de discussão dentro do próprio PMI. A ideia deste artigo é dar um overview a respeito tanto do PMI quanto do Scrum, e tentar mostrar como ambas as propostas se encaixariam em um projeto que lida com TI.


17

Pode-se até questionar a criação de uma prova, mas isso demonstra o interesse que as metodologias ágeis têm despertado em toda a comunidade que lida com software. Uma boa parcela das pessoas que atuam na área de TI já deve ter ouvido comentários de pessoas que dizem que ambos são incompatíveis, e que é apenas uma jogada de marketing. Outros comentários dizem que sim, eles são totalmente compatíveis, e que quem não consegue ver isso não entendeu nada de ambas. Mas afinal, dá ou não dá para integrar PMI e metodologias ágeis? Neste artigo, iremos falar um pouco sobre PMI e Scrum , tentar encontrar semelhanças e diferenças, e verificar a possibilidade de construir um ponto de equilíbrio na busca de melhores processos de desenvolvimento.

Breve introdução ao Scrum O Scrum é um processo interativo para o desenvolvimento de aplicações. Como características, podemos destacar: Integração com o cliente – A equipe deve estar sincronizada sempre com o proprietário do produto para não perder o foco; Priorização das atividades – Fazer o que é mais importa nte para o cliente; Desenvolvimento incremental – As entregas devem ser constantes e funcionais, para que o proprietário possa avaliar o que foi feito e obter valor rapidamente; Equipes auto gerenciadas – Cabe à equipe decidir como fazer e o ritmo que deve seguir. •

•

•

•

Figura 1. Ciclo de desenvolvimento – Scrum

Breve introdução à gestão de projetos baseada no PMBOK Com o objetivo de estudar e difundir as melhores práticas de gerenciamento de projetos, o Project Management Institute (PMI ) analisou projetos de diversas áreas (engenharia, desenvolvi mento de software, manufatura, etc.) e identificou um conjunto de processos e práticas que, se bem trabalhados e monitorados, costumam levar ao sucesso dos projetos. Ele então agrupou essas informações em um livro, que ficou conhecido como Project Management Book of Knowledge (PMBOK). Antes de entendermos o que é gestão de projetos, vamos entender qual a definição de projeto. Segundo o PMBOK , projeto é um “esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo”. Daí, pode-se destacar: Esforço temporário – Entenda que temporário não significa curto. Um projeto pode levar anos para ser feito. Entretanto, ele deve ter começo, meio e fim. Algo que se repete continuamente NÃO caracteriza um projeto; Cria um produto, serviço ou resultado específico – Um projeto deve sempre gerar um resultado único, algo que não existia antes. Sendo assim, construir um sistema que integra a parte contábil da empresa é um projeto. Garantir a operação do software e responder ao chamado dos usuários não. •

No Scrum , o cliente (representado pelo papel do Product Owner) inicialmente define quais são as suas necessidades e monta uma lista chamada Product Backlog. Confira o fluxo do Scrum na Figura 1. O Product Owner reúne-se então com a equipe, e explica os itens para ela. A equipe adiciona os itens necessários do ponto de vista técnico (por exemplo, demandas de segurança obrigatórios), e determina uma estimativa de tempo para a construção de cada item. Com base nessa estimativa de tempo e na importância para o negócio, o Product Owner prioriza os itens que deverão seguir no próximo ciclo (ou Sprint). No Scrum , todos os Sprints têm a mesma quantidade de tempo pré-determinada (fixo, determinado em acordo, e em geral entre 15 a 21 dias). A equipe agora tem uma lista de itens que devem ser realizados. Ela deve então se organizar para a realização das atividades. Neste Sprint , a equipe deve se esforçar para entregar o que combinou com o Product Owner. O produto do ciclo deve ser um pedaço de software inteiramente funcional – caso contrário, o item não será considerado completo, e irá para o próximo Sprint. Por fim, após a entrega das novas funcionalidades, a equipe se reúne para analisar o que aconteceu no ciclo, e entender o que poderia ser melhorado no processo. Esta reunião é chamada de Retrospectiva.

18

Engenharia de Software Magazine - PMI versus Scrum

•

Vamos ilustrar esse conceito, dando três exemplos: 1. Construção de um módulo contábil em um ERP corporativo; 2. Criação de uma campanha de marketing, para promover a marca da empresa. Essa campanha irá envolver a criação de um portal para os clientes e uma campanha de divulgação com os fornecedores; 3. Atendimento de um chamado para a correção de um bug no ERP corporativo. No primeiro exemplo, é fácil identificar que é um projeto, cujo produto é o próprio módulo contábil. Já no segundo exemplo, a fronteira é menos definida: O produto do projeto é a campanha de marketing. Tanto o portal quanto a elaboração do material de divulgação são subprodutos do projeto (e podem, inclusive, serem separados em subprojetos). A realização da campanha em si pode se tornar uma atividade de rotina na empresa e, portanto, deixa de ser um projeto.

AGILIDADE

Por fim, o último exemplo NÃO é considerado um projeto, já que é uma atividade rotineira (entretanto, em alguns casos, a identificação de um bug pode trazer a necessidade de criação de um projeto para corrigir o problema). Agora que entendemos a definição do que seria um projeto, vamos ver qual seria a definição de gerenciamento de projetos, extraída do PMBOK : “Aplicação de conhecimento, habilidades, técnicas e ferramentas às atividades do projeto a fim de alcançar os requisitos do projeto”. Sendo assim, gerenciar um projeto compõe-se das seguintes atividades: Identificar quais são os requisitos (aonde queremos chegar?); Identificar as métricas ou indicadores de sucesso (como saber se chegamos?); Traçar planos (o que temos que fazer para c hegar lá?); Adaptar os planos às mudanças nas necessidades e corrigir os desvios (estamos na direção certa?). • •

mais fases em um projeto. Podemos notar aqui certa semelhança entre as entregas sequenciais do Scrum e as fases do PMBOK . Além disso, os processos também podem ser classificados pelas áreas de conhecimento ao qual eles se referem, que podem ser vistas na Figura 2. Cada uma dessas áreas de conhecimento se refere a algo que o gerente de projetos deve gerenciar durante o projeto. Os processos da área de integração são comuns e integram as demais áreas. Nela temos os processos ligados a organizar o planejamento, gerir mudanças, organizar indicadores de progresso e atuar sobre eles, e como encerrar um projeto. Considera-se que esta é a função primária de um gerente de projetos (i.e. ser o integrador).

• •

Neste ponto, o PMBOK é um guia para o gerente de projetos. Ele traz um conjunto de processos e práticas que são aplicáveis a projetos bem sucedidos em diversas áreas. Na versão atual (4.0), ele traz um conjunto de 32 processos reunidos em cinco grupos de processos. Cada um desses grupos está atrelado a um momento dentro da fase do projeto. Esses grupos são: Iniciação: Identifica tudo o que precisa ser feito ANTES de se iniciar o projeto. Isso compreende: obter a aprovação do cliente para o início do projeto, identificar quais são os objetivos por trás do projeto e mapear pessoas que possam impactar (positiva ou negativamente) o andamento do projeto; Planejamento: Neste ponto, devemos traçar um plano de como vamos fazer o que deve ser feito; Execução: Já temos tudo em mãos, então precisa mos colocar o que foi planejado em execução; Monitoramento e Controle: Precisamos garantir que não irá haver desvios de rumo. Caso haja necessidade de corrigir alguma coisa, precisamos fazer as mudanças de rumo apropriadas; Encerramento: Não podemos considerar que um projeto (ou fase) foi entregue se não tivermos o aceite formal do projeto. Além disso, esse é o ponto em que encerrarmos contratos (em caso de subcontratações), e fazemos uma revisão formal para que possamos aprender com os nossos erros. •

•

Figura 2. PMI – Áreas de conhecimento

•

•

•

Para quem é mais familiarizado com administração, isso nada mais é que uma versão do modelo PDCA (Plan-DoCheck-Act). Além disso, esses momentos se intercalam, de forma que cada parte do projeto pode estar em um momento diferente. Para dar um exemplo: em um projeto de um grande site podemos subcontratar uma empresa de design para fazer o layout do mesmo. Assim que ela nos entrega o layout, validamos o que foi entregue e finalizamos o contrato – processos típicos de Encerramento – mesmo quando ainda estamos no meio da Execução do desenvolvimento do código. Nem todo projeto é composto, obrigatoriamente, de uma única fase. De acordo com a nossa necessidade, podemos ter uma ou

Isso não significa que os conhecimentos, as habilidades e os processos descritos sempre devem ser aplicados de forma u niforme em todos os projetos. Para qualquer projeto específ ico, o gerente de projetos, em colaboração com a equipe do projeto, sempre é responsável por determinar quais processos são apropriados e o grau de rigor apropriado para cada um. E agora, é possível mesmo compatibilizar ambos os mundos? Afinal, dá ou não dá para integrar PMI e Scrum?

Foco no objetivo A primeira coisa que precisamos entender é que gerenciar um projeto é muito mais do que fazer software. Muitas pessoas (e, infelizmente, alguns gerentes de projeto) acreditam que o sucesso de um projeto depende apenas se ele foi entregue atendendo às restrições de tempo, prazo, custo e qualidade. Na realidade, a visão moderna de gestão nos diz que para que possamos considerar um projeto como um sucesso, temos que poder responder positivamente às duas perguntas abaixo: O produto do projeto atendeu as necessidades do cliente? O cliente está contente com o resultado – pelo menos o su ficiente para continuar pagando o seu salário ou contratando sua empresa? • •


19

Ou seja, não adianta construirmos um projeto que é um case do ponto de vista da metodologia, se o produto não agregar valor ao cliente. Trazer valor para quem paga é o que vai garantir que nos perpetuemos na empresa/mercado. Para atendermos a esses objetivos, precisamos olhar muito mais do que apenas o produto que construímos (seja uma casa, um carro, ou um software). Para termos sucesso real, precisamos olhar para os fatores externos ao projeto. Precisamos: Identificar quem será impactado pelo projeto (vulgos stakeholders); Garantir que o projeto tenha os recursos necessários para ser realizado (equipe, verba, sala, etc.); Determinar e garantir a infraestrutura necessária para sua operação (sejam, por exemplo, servidores, novos processos operacionais, treinamento interno da equipe de operação); Gerenciar as expectativas das pessoas (seja o time do projeto, áreas usuárias, cliente, associações externas como sindicatos, etc.); Identificar a quem seria interessante auxiliar/prejudicar o andamento do projeto, e atuar de forma proativa, visando ampliar/minimizar o impacto de suas ações; Entre outros fatores.

que “O time é uma estrutura auto gerenciada, auto organizada e multi funcional, responsável por descobrir como transformar o Backlog do produto em um incremento de funcionalidades dentro de uma interação. Os membros do time são responsáveis, coletivamente, pelo sucesso de cada interação e do projeto como um todo”. Destacamos o termo “auto gerenciada” porque no Scrum todos os membros da equipe são responsáveis pelas decisões e pelos planos de ação. E, assim sendo, são também corresponsáveis pelo sucesso de suas decisões. O líder (ScrumMaster) então não é visto como alguém responsável por tomar decisões, montar planos de ação ou dar ordens – todas essas são responsabilidades da equipe. O líder possui apenas um papel adicional: agir como facilitador tanto dentro do time (para que a equipe não se perca em conflitos) e entre a equipe e o ambiente externo (o ambiente externo é representado aqui pelo Product Owner). Ou seja, ele é um representante em uma equipe auto gerenciada. Olhando sob o ponto de vista tradicional, gerentes estão em outro grau hierárquico. Raramente as pessoas serão capazes de separar esse fato de suas rotinas. Sendo assim, o fato de haver dentro do time alguém em uma hierarquia diferente pode Claro que, grande parte dos projetos de TI são pequenos, atrapalhar o auto gerenciamento do time e com isso perdermos envolve um pequeno número de pessoas e recu rsos e utilizam a própria integração que torna um grupo de pessoas um time uma infraestrutura muitas vezes pré-existente. Assim sendo, de desempenho diferenciado. Isso pode se transformar em u m raramente nos preocupamos com esses fatores. desafio para o gerente de projetos, o que pode não traz er bons Mas uma análise inadequada pode virar uma bomba relógio resultados ao projeto. na empresa. Podemos ter cenários aonde, por planejamento Além disso, em projetos grandes, raramente sobrará tempo inadequado, podemos ter um problema nas mãos. ao gerente de projetos para estar constantemente com a equipe, Para citar um exemplo: por não termos realizado uma análise já que em geral eles têm outras responsabilidades como: lidar adequada de utilização, ao colocarmos o nosso projeto no ar o com fornecedores, reunir-se com os interessados, se envolver banco de dados da empresa (compartilhado com outros siste- com a política da organização, identificar e endereçar riscos mas) fica sobrecarregado e para, comprometendo o fecha mento internos/externos ao projeto, cobrar recursos que foram promensal. O problema pode até ser resolvido rapidamente, mas metidos, comunicar a diretoria sobre o andamento do projeto, o custo do impacto gerado já foi incorrido. etc. Ou seja, como ele pode não estar disponível para a equipe Nesse aspecto, podemos ver que as práticas do PMBOK sempre que necessário, ao invés de tornar-se um facilitador ampliam as ferramentas do Scrum trazendo uma visão mais ele pode acabar atuando mais como um gargalo ao desenvolampla do negócio. vimento do projeto. Seria muito bom então que o ScrumMaster fosse alguém da O gerente de projetos no Scrum própria equipe de desenvolvimento, alguém que conhece a roKen Schwaber, um dos pais do Scrum, define o Product Owner tina diária da equipe e que tem o apoio desta. E para incentivar como sendo o “responsável por representar os interesses de a auto-organização, um bom passo seria que este seja indicado todos que tenham algum interesse no projeto ou seu produto pela própria equipe a qual ele irá representar. resultante. Ele obtém os fundos para o projeto, cria a lista de Como controlar o escopo? requisitos, os objetivos de retorno do investimento (ROI) e planos de liberação.”. Um dos grandes pesadelos do gerente de projetos é a muPor aqui você já pode notar que, dependendo do projeto, o dança de escopo. Mudanças de escopo causam retrabalho, gerente de projetos tem uma grande afinidade com o papel atrasos, e aumentam o custo e os riscos do projeto. Precisamos do Product Owner. Apesar dele não ser a pessoa que melhor compreender que o antigo mantra do gerenciamento “no praconhece o negócio, é a pessoa que conhece a empresa e tem zo, no orçamento, dentro do escopo” não é realista para um o respaldo político para agir em nome do patrocinador do ambiente dinâmico. projeto (poder este declarado no termo de abertura) e poder Muito provavelmente iremos ter mudanças profundas para mobilizar a empresa em uma direção. nos requisitos durante toda a vida do projeto. Seja porque E com relação ao papel de ScrumMaster? Será que ambos o cliente ainda não tem uma ideia completamente formada podem se misturar? Novamente, citando Ken Schwaber, temos sobre o que é o produto (esse ponto é ainda mais grave no •

•

•

•

•

•

20


AGILIDADE

desenvolvimento de produtos “abstratos” como software), porque ocorrem mudanças de legislação, políticas e de mercado (cada vez mais comuns nos dias de hoje), ou o surgimento de novas tecnologias. O próprio PMBOK mostra sua preocupação com o inesperado. Em algumas situações, ele nos sugere quebrar nosso projeto em fases progressivamente mais detalhadas conforme caminhamos (o chamado Planejamento por Ondas Sucessivas). Além disso, vários processos de controle de mudanças são apresentados. Infelizmente, o PMBOK não é explícito o bastante para nos dizer COMO fazer. Sendo assim, vários gestores e/ou críticos simplesmente deixam esse ponto para segundo plano, e utilizam o PMBOK apenas como a velha cartilha do modelo waterfall. Além disso, a maioria das ferramentas auxiliares usadas para o controle do projeto (como o WBS e o gráfico de Gantt) torna-se bastante difícil de ser atualizada, dependendo do grau de detalhes que o gestor utilizar para controlar o seu projeto. Neste aspecto, o Scrum pode nos auxiliar bastante. Por sua própria natureza, é como se o Scrum nos dissesse: “Ei, como eu posso te dizer o que eu vou te entregar a daqui a seis meses se nem você sabe o que vai precisar?”. Ao invés de controlar o que precisa ser feito a partir das TAREFAS (como construir a tela XPTO), o Scrum sugere controlar o que precisa ser feito através das FUNCIONALIDADES que devem ser agregadas. Além disso, ao invés de tentar congelar o escopo do projeto por meses, o Scrum busca congelar pequenos trechos do projeto por vez e atuar neles – o chamado Sprint. O resto do projeto é ainda indefinido e, como tal, só nos preocupamos em defini-lo melhor quando nos aproximarmos deste ponto. Buscamos fazer, mais para o começo, as atividades mais prioritárias para o cliente. Para isso, o cliente ( Product Owner) é o responsável por priorizar as atividades. Para priorizar, utilizamos sistemas de pesos e faixas de corte (por exemplo, itens obrigatórios, itens que podem ser entregues em uma segunda fase e itens opcionais). Ao trabalharmos com entregas constantes e focando apenas no que é mais prioritário para o cliente naquele momento, tornamos visível o que estamos fazendo e, caso as prioridades mudem, iremos dispender menos tempo em replanejamento. Além disso, podemos reavaliar o produto de uma fase e, caso necessário, atuar em cima do nosso processo rapidamente para corrigir/evitar problemas e reavaliar o prazo ou até mesmo cancelar o projeto.

Como estimar prazos? Não devemos nos enganar: A primeira pergunta do diretor comercial da sua empresa quando pedir um projeto é quando ele estará pronto (segunda, caso seja um projeto contratado externo). Isso tem relação, muitas vezes, com a própria estrutura de planejamento da empresa. Como dito anteriormente, o software muitas vezes é apenas uma pequena parte de um projeto como um todo. A empresa precisa treinar as pessoas, preparar

material de marketing, adequar normas e procedimentos manuais, e muitas outras atividades antes que o software possa entrar no ar. Claro que, em um primeiro momento, qualquer estimativa que fizermos será sempre uma estimativa de elevada incerteza. As estimativas que temos no começo do projeto só serão refinadas durante a vida do projeto, para refletir detalhes adicionais. Entretanto, para quem é melhor perguntar quanto tempo uma tarefa irá durar? Para o gerente que tem centenas de atividades na cabeça, ou para a pessoa que irá realizar a tarefa? Sendo assim, a forma mais precisa de fazer essa estimativa é definir o que deve ser feito (definido como funcionalidades, como por exemplo “permitir ao cliente agendar um voo”) e perguntar diretamente a quem vai fazer a tarefa quanto tempo irá levar para cumprir uma atividade. No PMBOK isto está previsto, e chama-se de estimativa bottom-up , e dentre as alternativas ela é considerada a mais precisa. Já o Scrum nem leva em conta as demais alternativas, sendo papel da equipe definir estimativas para cada um dos itens do backlog necessários para o desenvolvimento do produto. De posse das estimativas de tempo de desenvolvimento e da prioridade atribuída a cada funcionalidade pelo responsável pelo produto, agrupamos as nossas atividades dentro de Sprints , e temos uma ideia de quantos ciclos (ou Sprints) o conjunto de atividades necessário irá levar para ficar pronto.

Como estimar custos? O Scrum não entra em detalhes na questão do custo do projeto, mas precisamos lidar com os custos envolvidos no desenvolvimento – principalmente quando produzimos sistemas para um cliente. Em um projeto de TI, na maior parte das vezes o principal custo está relacionado aos gastos com mão-de-obra. Para os demais custos (podemos ter gastos com servidores, contratação de funcionários, taxas, seguros e outros), podemos utilizar os conceitos identificados no PMBOK . No mundo ideal, estamos trabalhando em paralelo com a empresa cliente (ou somos funcionários do cliente) e cada funcionalidade necessária é orçada em alguma unidade de medida pela equipe, e o valor de cada ponto nesta unidade é multiplicado por um preço fixo. Caso haja alguma incoerência na estimativa, como uma estimativa incorreta, os dois lados reveem os motivos e os custos adicionais são compart ilhados por ambas as partes. Podemos discutir o quanto quisermos a respeito das virtudes dos modelos de contrato a custo reembolsável ou contrato por tempo e material (bem semelhantes ao descrito acima) para a estimativa de projetos de TI, mas muitas vezes será difícil convencer as empresas a aceitar tipos de contratos diferentes de contratos de preço fixo. Esse é o tipo de contrato mais usual no mercado, e essa será uma situação comum com a qual o gerente de projetos irá se deparar. Uma abordagem bastante comum na literatura é f ixar “pacotes de pontos”. Nesta abordagem, o comprador efetivamente está comprando uma “potencialidade” de desenvolvimento.


21

Caso sejam necessárias alterações de escopo, caso o saldo de pontos estejam dentro do defin ido em contrato, as alterações solicitadas pelo cliente podem ser feitas – desde que outras atividades sejam excluídas. Este tipo de contrato é uma abordagem interessante, e pode permitir à empresa cliente se adaptar para lidar com um fornecedor que trabalha sob este modelo de desenvolvimento.

Como gerir mudanças? Com relação à gestão de mudanças, a abordagem tradicional do PMBOK de buscar variações em cima do plano não se encaixa bem em um cenário dinâmico. Isso porque se considera que o plano está correto, e o que foge ao plano precisa ser a nalisado e compreendido e a causa raiz deve ser determinada. Em ambientes dinâmicos, o plano representa apenas a melhor previsão que pudemos realizar, dados todos os fatores desconhecidos envolvidos. Sendo assim, assumir a mudança como norma parece ser muito mais efetivo do que reagir à mudança. Entretanto, como conseguimos encaixar a adaptação à mudança ao nosso planejamento? Como saber o impacto que uma mudança vai trazer ao nosso projeto? E como eu cobro por isso? Conforme comentado anteriormente, no Scrum o único momento em que se congela as atividades é durante um Sprint. Fora deste período, o responsável pelo produto possui liberdade para repriorizar, incluir ou excluir atividades. Caso haja espaço no cronograma, as alterações são então absorvidas pelo cronograma e custos atuais. Mas na maior parte dos casos não haverá espaço disponível. Neste caso, como devemos agir? Neste caso, as atividades menos prioritárias são deslocadas para baixo na escala, e caso não haja prazo suf iciente ou outras atividades levem mais tempo do que o previsto, as atividades são canceladas de baixo para c ima (ou seja, da menos importante para a mais importante). Como a lista de prioridades está disponível para todos, o gerente deve apenas comunicar aos interessados até quais funcionalidades serão implementadas na versão, e quais ficarão de fora. Se analisarmos o PMBOK , este fluxo basicamente equivale ao Comitê de Mudanças, mas neste caso o árbitro responsável pela decisão do comitê seria o próprio Product Owner , e as mudanças solicitadas seriam consideradas pré-aprovadas se as alterações efetuadas não impactarem na quantidade total de “trabalho” do projeto. Caso haja impacto no total de “trabalho”, acordos comerciais podem ser revistos.

22


Conclusão Neste artigo, pudemos ver como o Scrum pode ser utilizado pelo gerente de projetos de forma a trazer ganhos de produtividade no desenvolvimento de software e como compatibilizar a definição e a gestão de escopo, tempo e custo, além de como enxergar a gestão de mudanças sem ferir os padrões de processo descritos no PMBOK . Além disso, vimos como a gestão de projetos acaba tendo uma preocupação mais ampla que o Scrum quando nos propõe pensar no impacto do projeto como um todo na empresa, nos usuários, clientes, fornecedores e comunidades. Sendo assim, o que TI está fazendo muitas vezes é apenas a “ponta do ice berg”, ou seja, é apenas uma fração do trabalho total que será necessário para atingir os objetivos da empresa. Como precisamos ter alguém capaz de advogar por isso no dia-a-dia do desenvolvimento, o artigo propõe que o gerente de projetos se afaste do controle das atividades, para se aproximar mais do papel do responsável pelo produto final, aproximando-o do papel de Product Owner. Referências

Project Management Institute. (2008). Um guia do conhecimento em gerenciamento de projetos (PMBOK Guide) 4a Edição Mike Cottmeyer.(2009). Agile PMP: Managing Software Projects in the Face of Uncertainty Kelley Hunsberg. (2011). Change is Good Michele Sliger. (2008). Agile Project Management and the PMBOK Guide Ken Schwaber. (2004). Agile Project Management with Scrum Mike Griffiths. (2004). Utilizing Agile Principles alongside A Gui de to the Project Management Body of Knowledge (PMBOK Guide) for better project execution and control in software development projects. Ron Armstrong Requirements of a Self-Managed Team Leader http://www.leader-values.com/Content/detail.asp?ContentDetailID=1004



u

e s ê

F eedb a c k

D

o

s

b

r

e

ç

e s t a e

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

Ferramentas para Gestão de Projetos Uma análise comparativa das principais ferramentas De que se trata o artigo?

Aline da Silva Tinoco [email protected]

Pós Graduada em Gerência de Projetos em Engenharia de Software – Centro de Ensino Superior de Juiz de Fora.Tecnóloga em Sistemas para Internet – Faculdades Integradas Vianna Júnior.Consultora de Marketing Digital - 8Ps .Atua como Gerente de Projetos na Ato.interativo – agência digital.

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 Bacharelado em Sistemas de Informação do CES/ JF, da FMG e da USS, professor do curso de Bacharelado em Ciência da Computação da FAGOC, professor do curso de Tecnologia em Análise e Desenvolvimento de Sistemas da FAA, Analista de Sistemas da Prefeitura de Juiz de Fora, Editor da Engenharia de Software Magazine.

Aborda a importância do uso de ferramentas para gestão de projetos com o objetivo de mostrar as principais funcionalidades das mais populares. Neste contexto, o artigo destaca a importância do gerenciamento de um projeto e a utilização de ferramentas que podem auxiliar nessa tarefa, além de ressaltar suas principais características.

Em que situação o tema é útil? O tema se torna fundamental para gerentes e empresas que buscam aprimorar a gestão de seus projetos levando em consideração fatores como escopo, tempo, recursos, cus tos e qualidade, entre outros.

dades, ferramentas e técnicas. Com o uso de metodologias, a implantação da cultura de projetos pode ser realizada para garantir a aplicação dos princípios de gerenciamento de projetos de forma padronizada, buscando atender da melhor forma às necessidades das organizações. Neste sentido, este artigo abordará cinco das principais ferramentas de gestão de projetos, suas vantagens e desvantagens apresentadas. Além disso, irá destacar a importância da gestão de projetos dentro das organizações, ressaltando as funções que o gerente deve e xercer, como o planejamento de ações, a definição de processos e técnicas, o uso de ferramentas adequadas ao projeto e suas principais funcionalidades.

Resumo? O gerenciamento de projetos deve ser feito com a aplicação de conhecimentos, habili-

A

cada dia cresce a necessidade de adoção do gerenciamento de projetos em pequenas, médias e grandes empresas. Sua importância está relacionada à redução de custos no desenvolvimento de projetos, cumprimento de prazos, eficácia no resultado final e mensuração de resultados.

Além disso, é importante destacar que o gerenciamento de projetos precisa evoluir e se adaptar constantemente às necessidades cada vez mais dinâmicas das organizações. O desenvolvimento de software é uma atividade complexa, envolvendo inúmeros fatores que são imprevisíveis e de


23

difícil controle, como volatilidade dos requisitos do software e prazos. Esses fatores fazem com que o produto final não atenda às expectativas ou, até mesmo, às necessidades do cliente, além de exceder o prazo e o orçamento previsto. A partir dis so, um gerenciamento eficaz tem se tornado de fundamental importância para se obter sucesso no desenvolvimento de software. Para que um projeto de software seja bem sucedido, é necessário que alguns parâmetros sejam analisados como, por exemplo, o escopo do software , os riscos, os recursos necessários às tarefas a serem realizadas, os marcos de referência a serem acompanhados, os esforços e custos aplicados, além da sistemática a ser seguida, entre outros fatores. Atualmente, a prática do gerenciamento de projetos está em crescimento, devido ao surgimento de ferramentas open source (código aberto de software). A principal função dessas ferra mentas é administrar de forma mais organizada e eficiente os processos de um projeto e sua gestão. Entretanto, nem sempre essas ferramentas possuem os recursos necessár ios para uma gestão completa, que não permitem a visualização de um pro jeto como um todo. O conhecimento e aplicação destas técnicas têm relação direta com a garantia de obtenção das metas das organizações (PRADO, 2009). Quando se aplica o gerenciamento de projetos ao desenvolvimento de um projeto de software, é importante que o gerente e a equipe visualizem todo o processo. Além disso, alguns parâmetros precisam ser corretamente analisados, como por exemplo, o escopo do projeto, riscos, recursos necessários, tarefas, indicadores para acompanhamento, esforços e custos, e a linha de raciocínio a ser seguida. Uma característica necessária nos profissionais envolvidos com gerência de projetos é o dinamismo, a sua capacidade de lidar com múltiplas tarefas e a habilidade de não perder nenhum detalhe. Muitas vezes organizar datas e conteúdo de uma única tarefa a ser realizada em longo prazo exige uma visão estratégica do profissional (CIRIACO, 2009). Para auxiliar na coordenação de todas as informações que envolvem o projeto do início ao fim, surgem diversas ferramentas, tanto desktop quanto online , que oferecem recursos para a organização de suas tarefas, estipulando metas e, em alguns casos, com suporte para trabalhos em equipe. O uso de ferramentas de gestão de projetos torna-se indispensável para garantir resultados positivos no desenvolvimento de um projeto, pois permite saber quais métodos e processos de trabalhos utilizados, e visualizar informações em tempo real ao alcance de toda a equipe envolvida. Porém, é preciso conhecer os recursos tecnológicos de cada ferramenta e analisar as reais necessidades da implantação de acordo com o projeto. Ao optar pelo uso de ferramentas de gestão de projetos, as organizações podem estar certas de que estão investindo corretamente, executando projetos com sucesso e resultando em vantagens planejadas, maximizando a utilização de recursos, fornecendo ferramentas de colaboração para conectar equipes dispersas e mantendo visibilidade e controle sobre o projeto através de relatórios e mensuração de resultados (PAUMGARTTEN, 2010).

24

O Gartner Group divulgou o resultado de uma pesquisa realizada em 2010 sobre os problemas enfrentamos pelas organizações quando não implantam ferramentas para auxiliar na gestão de projetos. Os resu ltados foram: • 51% de todos os projetos extrapolam o orçamento ou ultra passam o prazo final; • 15% dos projetos falham completamente; • 94% dos entrevistados reportaram que implementando uma metodologia de gerenciamento de projetos, adicionou valor às suas organizações; • Software de gerenciamento de portfólio de TI pode reduzir custos de 2 a 5%, melhorar produtividade entre 20 e 25%, e elevar de 10 a 15% a receita para projetos mais estratégicos. Grande parte dos problemas acima poderia ser minimizada não só com uma boa metodologia adaptada às necessidades das organizações. Além disso, é muito importante ter uma ferramenta adequada a essa metodologia. A ferramenta deve ser realmente adequada à metodologia de acordo com suas necessidades e apoiar a metodologia, e não o contrário (PAUMGARTTEN, 2010). A implementação de uma ferramenta de gestão de projetos deve ser conduzida como um projeto, com início, meio e fim. Todas as áreas do conhecimento com seus processos, entradas, ferramentas e técnicas, e saídas podem e devem ser utilizados para gerenciar um projeto dessa natureza (VIEIRA, 2008). Em 2009 foi realizado um Estudo de Benchmarking pelo PMI Brasil sobre a prática do gerenciamento de projetos e utilização de ferramentas em trezentas empresas brasileiras. As empresas participantes responderam a um questionário eletrônico na Internet com pouco mais de cem perguntas, as quais foram utilizadas como base para o desenvolvimento dessa pesquisa. O resultado mostrou que 91% dessas organizações possuem baixo nível de resistência em relação à prática da gestão de projetos, e que 80% dessas empresas utilizam ferramentas para gerenciar projetos. A Figura 1 lista as principais ferramentas utilizadas por essas empresas, de acordo com a pesquisa. Dessas ferramentas, cinco foram selecionadas para descrever seus principais recursos e funções.

Project Builder De acordo com o site dessa ferramenta, a Project Builder foi desenvolvida pela empresa homônima e é baseada nas práticas do PMI. Funciona em plataforma web e é utilizada na gestão de projetos, podendo ser acessada de qualquer lugar. Essa ferramenta se encaixa em pequenas e médias empresas de diversos setores e possui recurso como solução cloud computing (computação em nuvem). O foco principal é a integração de pessoas envolvidas (equipe, clientes e fornecedores), além da visão do plano estratégico, tático e operacional dos projetos. O software permite integração com o MS Project , podendo exportar e importar os projetos do software da Microsoft. Tam bém permite exportação de seus relatórios e EAP (estrutura analítica de projetos, Figura 2) para o Excel. A Figura 2 mostra a tela inicial da ferramenta, com projetos, responsáveis, prazo, status e prioridades.

Engenharia de Software Magazine - Ferramentas para Gestão de Projetos

GESTÃO DE PROJETOS

As principais funções de apoio ao gerente de projetos são: • Funcionalidades configuráveis de acordo com a maturidade e características dos projetos; • Estrutura Analítica do Projeto (dis ponível em formato gráfico) e detalhamento dos componentes em Subprojetos, fases, marcos, produtos, atividades; • Dependência entre projetos; • Gestão de recursos; • Pessoas envolvidas e matriz de respon sabilidades em todos os níveis da EAP; • Mapa de alocação e Histograma de pessoas; • Definição de calendários (projetos e pessoas); • Cronograma Gantt; • Controle de receitas; • Metas e avaliação de resultados do projeto e de seus componentes (metas qualitativas e quantitativas); • Tratamento de Riscos (identificação, análise e respostas); • Indicadores de desempenho; • Registro histórico do projeto e de seus componentes; • Integração com email; • Envio de relatórios de progresso e controle em diferentes formatos. Na Project Builder , os colaboradores podem visualizar os projetos em que estão alocados. Nessa área, eles podem e devem informar tudo o que está ocorrendo, como comentários sobre reuniões com o cliente, início e conclusão de atividades, esforço realizado, lições aprendidas. Com isso, o gerente consegue saber como os projetos estão se desenvolvendo dentro da organização.

Microsoft Project A ferramenta Microsoft Project (ou MS Project) foi criada pela Microsoft em 1985 (primeira versão). Veio sofrendo modificações em seu layout até as versões atuais, como mudanças funcionais, no intuito de aumentar a oferta de serviços e recursos relacionados à gestão de projetos. Os focos da MS Project são: tempo (datas, duração do projeto, calendário de trabalho), Gráfico de Gantt , modelo para cálculos relacionados a planejamento, Diagrama da Rede, Custos (fixos, não fixos, outros)

Figura 1. Softwares de apoio ao Gerenciamento de Projetos mais utilizados

Figura 2. Estrutura analítica do projeto (EAP) no Project Builder

e uma série de relatórios. Utiliza a mesma interface e uso de outros softwares Microsoft Office (screenshot na Figura 3). A MS Project pode ser utilizada para gerenciar projetos simples ou complexos, e permite planejar, organizar e gerenciar as tarefas e recursos para alcançar um objetivo final com restrições de tempo, custos e recursos. Essa ferramenta oferece recursos para auxiliar o usuário na gestão de projetos, fornecendo a possibilidade de melhor controle e suas atividades, segurança, agilidade e eficácia nos processos, além de interface simples para uso, mesmo para quem não está familiarizado com a ferramenta. É considerado por muitos profissionais um bom software para gestores, administradores e coordenadores.

Segundo o site da Microsoft , a MS Pro ject visa fornecer eficientes ferramentas de gerenciamento de projeto com a com binação certa de usabilidade, eficiência e flexibilidade, de modo que permite o gerenciamento de projetos com mais eficiência e eficácia. É possível manter o gerente sempre informado, controlar o trabalho, as agendas e as finanças do projeto, manter as equipes de projeto alinhadas e ser mais produtivo por meio da integração com programas conhecidos do Microsoft Office system , da geração avançada de relatórios, do planejamento guiado e de ferramentas flexíveis. A MS Project destaca automaticamente todos os itens que se deslocam como resultado da alteração mais recente realizada. Com a ajuda de realces de alterações,


25

é fácil de obter uma melhor compreensão dos impactos das suas escolhas. Outro recurso disponível é o desfazer e refazer alterações em modos de exibição, dados e opções com vários níveis de desfazer. É possível desfazer ações ou conjuntos de ações de iterações macros para testar vários cenários hipotéticos e compreender totalmente as implicações de cada escolha enquanto realiza alterações de escopo. As principais funcionalidades da MS Project são: • Elaborar projetos e controlá-los atra vés de agendamento das atividades tornando possível o progresso de cada uma delas;

• Acompanhar de forma gradual todo o projeto; • Elaborar relatórios com qualidade, discriminados por custo e trabalho dos recursos e tarefas, duração das atividades e sua distribuição de trabalho pelos dias do mês ou ano, na forma de calendário; • Montar rapidamente o plano do projeto (agenda) definindo e organizando a lista de tarefas, permitindo verificar detalhes e ter uma visão geral do mesmo para manter o seu controle; • Controlar quem faz as tarefas, montando seu conjunto de recursos e atribuir em suas tarefas, bem como calcular o tempo em que as tarefas precisam ser concluídas;

Figura 3. Visualização da MS Project 2010

Figura 4. Visualização dos gráficos do projeto na Primavera

26


• Ajuste rápido de sua agenda, pois havendo ajustes, interrupções no decorrer do projeto, pode-se ajustar a agenda de forma que fique organizada; • Coordenar o trabalho de pessoas em qualquer lugar compartilhando informações através de Intranet ou Internet, utilizando email, por exemplo; • Ajuda durante o projeto, através do assistente do Office; • Fácil integração com programas do pacote Office (Word, Excel, Access); • Impressão de relatórios personalizados; • Gerar Gráfico de Gantt e outros tipos como carga de trabalho e custos, seguindo a forma escolhida pelo usuário.

Primavera A Primavera é uma marca que comercializa pacotes de projetos de gerenciamento, cujo editor atual é a Oracle Corporation. O principal pacote é a Primavera P6 (Enterprise Management Project Portfolio), desenvolvido pela Primavera Systems. De acordo com o site da PMI Capítulo São Paulo (2009), a Primavera é uma das ferramentas mais completas e complexas de gerenciamento de projetos, baseada na metodologia do PMI. O software está subdividido em pacotes de trabalho e geralmente não é necessário adquirir todo o produto. A possibilidade de poder-se adquirir um determinado pacote para suprir as necessidades da empresa (por exemplo, Risk Manager), constitui uma grande vantagem, pois assim evita-se não utilizar de forma eficaz a ferramenta. Esta é adequada para ambientes de multi projetos, grandes e complexos. A Figura 4 apresenta uma tela da ferramenta. As ferramentas de aplicação da Primavera software incluem: • Primavera P3 Project Planner e SureTrak (descontinuado em 31 de dezembro de 2010, o uso continua não suportado pela Oracle); • Primavera P6 Enterprise Management Project Portfolio; • Primavera Project Management Professional P6; • Primavera P6 Analytics; • Primavera Portfolio Management; • Primavera de Gestão de Contratos; • Primavera de Análise de Risco;

GESTÃO DE PROJETOS

• Primavera Inspire for SAP; • Primavera Earned Value Management.

Dentre as principais funcionalidades da Primavera estão: • Acompanhar o desempenho de cada projeto de um mesmo cliente; • Possibilitar a colaboração com ideias e soluções dos mais diversos usuários envolvidos no projeto; • Conciliar e administrar a disponibi lidade de recursos e identificar os pro blemas de má utilização de tais recursos (Gráfico de Gantt e Diagrama de Rede); • Definir a prioridade de projetos e tarefas; • Identificar e selecionar as melhores soluções e estratégias para o sucesso de um projeto; • Transmitir informações aos gerentes dos projetos, através de recursos avançados, fazendo uso de tabelas, gráficos, diagramas e histogramas; • Disponibilizar informações em tempo real para uma rápida e eficiente tomada de decisões; • Planejar e analisar a estratégia de recursos financeiros em projetos propostos; • Fornecer dados numéricos para análise e comunicação do desempenho das diferentes fases de um mesmo projeto, baseadas em necessidades organizacionais; • Organizar e planejar portfólio para apresentações aos mais diferentes perfis de clientes e áreas de atuação; • Organizar e disponibilizar formulários para obtenção de informações necessárias para o sucesso das atividades presentes em um projeto; • Disponibilizar dados de etapas do projeto para aprovação; • Acesso via desktop, web e/ou intranet.

OpenProj Conforme o site da ferramenta, o site da OpenProj é um software de gestão de projetos de código livre, com funções similares ao MS Project , sendo capaz de abrir arquivos Project. Ela foi desenvolvida pela Projity , em plataforma Java, permitindo que seja executado em diferentes sistemas operacionais. A versão 1.0 foi liberada em janeiro de 2008. No mesmo ano, a Projity foi adquirida pela Serena Software.

Figura 5. Visualização do planejamento de projetos no OpenProj

A OpenProj tem as seguintes funções de gestão de projetos: • Gestão de recursos: cada tarefa precisa ter definido os recursos necessários para sua execução (pelo menos um). Esses recursos podem ser pessoas ou materiais; • Calendários: gerir datas das tarefas, estabelecer datas previamente; • Ambiente de trabalho: permite atri buir datas de começo e fim, horas de trabalho de um recurso de uma tarefa, planejamento; • Limitação de datas: durante o de senvolvimento de um projeto, podem ocorrer situações em que é necessário terminar tarefas em uma data exata ou aproximada. Quando se atribui uma limitação de data de começo ou fim em uma tarefa, diminui a capacidade desta para adaptar-se a mudanças na programação. • Divisão de tarefas: uma tarefa pode ser dividia ou reprogramada para interromper o trabalho e retomar o resto do projeto do mesmo ou em um ponto posterior da programação. • Filtros: ordenação de datas permi tem mostrar informações específicas da programação do projeto. Os filtros

podem ser feitos por tarefas completas, tarefas de custo excessivo, tarefas críticas, tarefas em progresso, tarefas incompletas, tarefas atrasadas, tarefas normais, resumo. • Impressão de documentos: Diagrama de Gantt , visualização de recursos, histograma, projetos e relatórios. O Gráfico de Gantt ilustra, na forma de barras, o cronograma de um projeto, com as datas de início, fim e todas as tarefas atribuídas devidamente registradas. Além disso, a OpenProj abre arquivos da Microsoft Project e da Primavera , porém possui formato de arquivo próprio. Os relatórios e gráficos podem ser exportados para xml ou pdf, facilitando assim a migração dos dados para outros programas do gênero. A Figura 5 mostra a visualização da tela do software.

dotProject Atualmente, de acordo com o site da dotProject , a ferramenta está em sua versão 2.1.5 e apresenta uma série de funcionalidades úteis para o trabalho de gerenciamento de projetos. A versão atual da dotProject foi lançada em janeiro de 2011, e houve pelo menos um lançamento


27

por ano, desde o início da série 2.x (2005), sendo que o projeto nasceu em 2000. Após a disponibilização da versão 2.1.5, muitas correções e melhorias foram disponibilizadas em uma versão beta e já podem ser utilizadas. A dotProject surgiu da necessidade de se ter um software na área de gestão de projetos que não fosse necessário o pagamento de licença e nem da utilização de um sistema operacional também licenciado. A dotProject é um sistema de gerência de projetos em software livre de fácil utilização, com um conjunto de funcionalidades e características que o tornam indicado para implementação

em ambientes corporativos, pois atende a diversas necessidades de gerentes e escritórios de projetos. A ferramenta é uma aplicação web e seu acesso é feito através de um navegador, assim sua utilização independe de sistema operacional e instalação na máquina do usuário, pois é executado em um servidor. Em termos mais técnicos, a dotProject é um sistema escrito em PHP, que utiliza banco de dados MySQL. Essa ferramenta também pode ser instalada em Windows , e utilizada em diferentes sistemas operacionais. Pelo site do dotProject Brasil é possível acessar a área de demonstração

Figura 6. Visualização do projeto do dotProject

do software , co nforme apre se nt a a Figura 6. O dotProject unifica, dentre outras funções: • Informações de empresas; • Informações de projetos de cada empresa; • Todas as tarefas necessárias à execução de cada projeto; • Saber quanto de cada tarefa já foi realizado; • Informação de usuários e colaboradores de cada tarefa; • Um modo fácil de informar usuários de suas associações a tarefas (via email); • Lembretes popup sobre prazos próximos ao fim; • Uma lista de contatos relacionados; • Calendários com visões diferentes: mensal, semanal e diária; • Fóruns relacionados a projetos; • Repositório de arquivos relacionados a projetos. Além disso, a dotProject inclui módulos para companhias, projetos, tarefas (com gráfico de Gantt), fóruns, repositório de arquivos, calendário, contatos, bug report , suporte multi-linguagem e gerenciamento de permissões de usuários. Os participantes do projeto podem utilizar a ferramenta para visualizar suas atividades, para reportar as realizações diárias, assim como cadastrar lições aprendidas nos fóruns. A limitação do dotProject está em não possuir uma comparação entre o que se estima de um projeto e o que realmente acontece.

Comparativo entre as ferramentas

Figura 7. Funcionalidades fundamentais em um software de gerenciamento de projetos

28


A partir da apresentação das ferramentas de gestão de projetos e dos recursos disponíveis em cada uma delas, foi realizada uma análise comparativa com os principais recursos para um gerenciamento eficaz de um projeto com o objetivo de focar nos recursos técnicos. O critério seguido para montar a tabela comparativa foi o resultado do Estudo de Benchmarking 2009 feito pela PMI Brasil, que apresenta as funcionalidades mais importantes para ferramentas de gestão de projetos (ver Figura 7). As funcionalidades citadas na tabela foram tomadas como referência para

GESTÃO DE PROJETOS

estabelecer uma comparação entre todas as ferramentas citadas neste artigo. A Tabela 1 apresenta o resultado. Em relação às ferramentas citadas, percebe-se que a Project Builder e a MS Project são ferramentas mais completas de acordo com as funcionalidades disponíveis. Apesar disso, a Primavera , OpenProj e dotProjet dispõem de funções que atendem às necessidades de um gerente de projetos, como dependência entre tarefas, relatórios e histogramas. Enquanto a Project Builder e a MS Project possuem tipo de licença paga, as outras três possuem licença gratuita. O cronograma, importante para o controle de prazos e planejamento de um projeto, foi a função mais importante considerada pelas organizações, e só não está presente na dotProject. Depois dessa função, o painel com indicadores de desempenho também foi citado no resultado da pesquisa, mas apenas as ferramentas com licença paga o disponibilizam.

Os relatórios, que são necessários para a avaliação dos pro jetos, é exibido na tabela com 56% de importância nas ferramentas de gestão de projetos. Analisando todas as funcionalidades e ferramentas, a MS Project e a Project Builder disponibilizam 16 itens da tabela, a Primavera atende em 12 itens, a OpenProj em 10, a dotProject 8.

Conclusão Desenvolver habilidades e alcançar o nível de profissionalismo compatível com a função de gerente de projetos neces sita não apenas aprendizado de conceitos básicos e técnicas, mas também o aprendizado na utilização de ferramentas de gerenciamento bem como sua prática. Logo, com o uso dessas ferramentas e implantação, a gestão pode ser realizada para garantir a aplicação dos princípios de gerenciamento de projetos de forma padronizada buscando Ferramenta

Recursos

Project Builder

MS Project

Primavera

OpenProj

Cronograma

x

x

x

x

Painel com indicadores de desempenho

x

x

Relatórios

x

x

x

x

x

x

x

Estrutura analítica de dados (WBS) Gerenciamento da documentação

x

Acesso via web

x

Orçamento

x

Pool de recursos

x

Monitoramento do portifólio de projetos

dotProject

x

x x

x

x

x

x

x

x

Acesso remoto

x

x

x

x

x

Milestones

x

x

x

x

x

Timesheet

x

x

x

x

x

Gerência de riscos

x

x

x

x

x

Envio automático de mensagem

x

x

Gestão do portfólio

x

x

x

x

x

Ajuda para a metodologia (web)

x

x

x

x

x

Análise de valor agregado (EVA)

x

x

x

Integração com financeiro

x

Integração com suprimentos

x

Tabela 1. Quadro comparativo de Ferramentas x Funcionalidades


29

atender da melhor forma às necessidades das organi zações. O contexto histórico da prática de gestão de projetos e as principais metodologias, como o PMBOK, são conhecimentos que um gestor precisa ter para avaliar qual o melhor processo a ser adotado no desenvolvimento de um projeto. Foram citadas neste artigo cinco das principais ferramentas, suas vantagens e desvantagens apresentadas, além disso, outra contribuição do artigo foi destacar a importâ ncia da gestão de projetos dentro das organizações, ressaltando as funções que o gerente deve exercer, como o planejamento de ações, a definição de processos e técnicas, o uso de ferramentas adequadas ao projeto e suas principais funcionalidades. O gerenciamento de projetos deve ser feito com a aplicação de conhecimentos, habilidades, ferramentas e técnicas. Com o uso de metodologias, a implantação da cultura de projetos pode ser realizada para garantir a aplicação dos princípios de gerenciamento de projetos de forma padronizada, buscando atender da melhor forma às necessidades das organi zações.



u

e s ê

Referências CIRIACO, Douglas. Ferramentas para gerenciar projetos. 2009. . PAUMGARTTEN, André. Porque investir numa ferramenta para gestão de projetos e portfolios. 2010. . PRADO, Darci. Gerenciamento de Portfólios, Programas e Projetos nas Organizações. São Paulo: INDG, 2009. ROCHA, P. C. e BELCHIOR, A. D. (2004) “Mapeamento do Gerenciamento de Riscos no PMBOK, CMMI-SW e RUP”, In: VI Simpósio Internacional de Melhoria de Processos de Software – SIMPROS, São Paulo, Brasil. SISK, T.History of Project Management. 1998. PEREIRA, Paulo; TORREÃO, Paula; MARÇAL, Ana Sofia. Entendendo Scrum para Gerenciar Projetos de Forma Ágil. Revista Mundo PM, n. 14. Abril/Maio 2007. . VAZQUEZ,C.E. , SIMÕES,G.S. , ALBERT,R.M. Análise de ponto de função medição, estimativa e gerenciamento de projetos de software. São Paulo, Editora Érica, 2009

F eedb a c k

D

o

Softex. MPS.BR - Melhoria de processo do software brasileiro - Guia geral, 2009

s

b r e e s t a

o ç

IFPUG(International Function Point Users Group). .

e

BFPUG(Brazilian Function Point Users Group). Disponível em: . PMI (Project Management Institute). Um Guia do Conjunto de Conhecimentos em Gerenciamentos de Projetos (PMBOK). Estados Unidos: PMI Publications, 2004 DEKKERS, C.Pontos de Função e Medidas - O Que é um Ponto de Função?.QAI Journal, dez.1998 DEKKERS, C. Desmistificando Pontos de Função: Entendendo a Terminologia. IT Metrics Strategies, out. 1998 HAZAN, Cláudia – Análise de Pontos por Função – agosto , 2001 . http://www.inf.ufes. br/~falbo/download/aulas/es-g/2005-1/APF.pdf. ACINE. Anexo XVIII – Tabelas de produtividade mínima, 2008. Philippe Kruchten. The Rational Unified Process: An Introduction. Boston, Editora Pearson Education, 2003

30



Conhecendo a ISO 15408 Trabalhando com segurança da informação De que se trata o artigo? Este artigo apresenta um estudo sobre o assunto segurança no desenvolvimento de software. Para isso, os seguintes tópicos serão abordados: conceitos de segurança, importância de se desenvolver um software seguro, norma de segurança ISO/IEC 15408 para o desenvolvimento de software e, por fim, auditoria de software.

Em que situação o tema é útil?

O

Dayana Fernanda Trapp [email protected]

Rodrigo Oliveira Spínola [email protected]

Editor Chefe – SQL Magazine | WebMobile | Engenharia de Software Magazine

desenvolvimento de sistemas é uma das áreas mais afetadas pelos aspectos da segurança. Muitos dos problemas de segurança existentes hoje não são, nem físicos e nem de procedimento, mas sim, devidos a erros de programação ou de arquitetura. Muitas vezes, para não “perder” muito tempo e entregar a solução o quanto antes para o cliente, os requisitos de segurança são deixados de lado. Os clientes por sua vez não possuem noção sobre segurança de um sistema e só sa berão mais tarde quando é encontrada uma vulnerabilidade. Isso acontece porque poucos analistas preocupamse em especificar bem os requisitos de segurança.

O entendimento deste assunto é importante para aqueles que trabalham com desenvolvimento de software e, em particular, para aqueles que trabalham no sentido de aprimorar iniciativas de segurança da informação.

Resumo? A segurança da informação tem como objetivo a proteção da informação para reduzir a probabilidade e o impacto de incidentes de segurança. Para saber se o sistema é seguro, na década de 80 surgiu o primeiro padrão para avaliação de segurança em softwares que ficou conhecido como Orange Book. Mais tarde este padrão foi homologado pela International Standartization Organization (ISO) como ISO/IEC 15408. Neste contexto, este artigo apresenta um estudo sobre o assunto segurança no desenvolvimento de software.


31

A segurança em sistemas sempre foi importante e com a internet a segurança torna-se o foco, uma vez que os sistemas tendem a ficar mais interconectados, facilitando acessos indevidos. Dessa forma, temos que a segurança será cada vez mais uma preocupação no desenvolvimento de sistemas. Tem-se como premissa que nenhum software é seguro [19]. A segurança de um software é afetada porque ele pode executar outros procedimentos os quais não foram propostos. Se ele fizesse exatamente o que foi destinado a fazer, a segurança não seria uma preocupação [10]. Portanto, existe uma facilidade para invasores investigarem vulnerabilidades desconhecidas e dificuldade dos desenvolvedores em garantir que todos os pontos de entrada do sistema estejam protegidos. Para saber se um sistema é seguro, na década de 80 surgiu o primeiro padrão para avaliação de segurança em softwares que ficou conhecido como Orange Book. Mais tarde este padrão foi homologado pela International Standartization Organization (ISO) como ISO/IEC 15408, que muitas vezes é chamada apenas de Common Criteria (CC). De acordo com Albuquerque e Ribeiro [1], a norma ISO/IEC 15408 é o melhor ponto de partida para o desenvolvimento de software seguro, pois ela descreve conceitos necessários para a segurança em sistemas. A ISO/IEC 15408 determina que um sistema deva ter seu Security Target (ST) (objetivo ou alvo de segurança) definido para ser considerado seguro. “O ST é a especificação de segurança, ou seja, indica quais aspectos de segurança foram considerados importantes e porque o foram para aquele sistema em particular”. Neste contexto, este artigo apresenta um estudo sobre o assunto segurança no desenvolvimento de software. Para isso, a partir de agora apresentaremos os conceitos de segurança. Em seguida abordaremos a importância de se desenvolver um software seguro. Posteriormente apresentaremos a norma de segurança ISO/IEC 15408 para o desenvolvimento de software. E, por fim, descreveremos os conceitos de uma auditoria de software.

Segurança da informação A segurança da informação tem como objetivo a proteção da informação para reduzir a probabilidade e o impacto de incidentes de segurança. Segundo Lyra [17], um incidente de segurança ocorre quando um evento pode causar interrupções nos processos de negócio em decorrência da v iolação de alguma propriedade de segurança. Neste contexto, temos as três propriedades básicas da segurança: confidencialidade: capacidade de um sistema permitir que alguns usuários acessem determinadas informações ao mesmo tempo e impedir que outros, não autorizados, a vejam; integridade: a informação deve estar correta, ser verdadeira e não estar corrompida; disponibilidade: a informação deve estar disponível para todos que precisarem dela para a realização dos objetivos empresariais. •

•

•

autenticação: capacidade de garantir que um usuário, sistema

ou informação é mesmo quem alega ser; não repúdio: capacidade do sistema de provar que um usuário executou determinada ação no sistema; legalidade: aderência de um sistema a legislação; privacidade: capacidade que um sistema tem em manter incógnito um usuário, impossibilitado a ligação direta da identidade do usuário com as ações por este realizadas; auditoria: capacidade do sistema em verificar tudo o que foi realizado pelos usuários, detectando fraudes ou tentativas de ataque. Note que este é um aspecto difícil de ser totalmente conciliado com a privacidade. •

• •

•

Quando se tem a perda de qualquer propriedade da segurança importante para o sistema, tem-se um problema de segurança. Assim, trabalha-se na prevenção para manter as propriedades de segurança dentro das necessidades do cliente e evitar falhas. Por exemplo, um sistema que deve estar disponível 24 horas, deve ter alta disponibilidade e não necessita tanto tratar confidencialidade e privacidade dos dados. Nos sistemas militares ou de segurança nacional, o ponto critico é a privacidade. Já em sistemas bancários, a integridade e a auditoria são os pontos mais relevantes. Para cada tipo de sistema a necessidade de segurança é diferente, por isso, deve ser tratada de forma distinta para cada caso. As falhas de segurança em software podem ser consideradas as grandes responsáveis pelos ataques em sistemas. A exposição que vem com a conectividade global torna a in formação sensível e o sistema mais vulnerável para o uso não autorizado e intencional [2]. O crescimento da conectividade da internet pelos computadores e a dependência dos usuários de serv iços on-line tem proporcionado um grande número de ataques. O ataque ao sistema é um problema de segurança grave, pois o agente que está realizando o ataque visa obter alguma vantagem, podendo com isso, provocar grandes prejuí zos. Há sempre quatro elementos no ataque: ataque: é um tipo de problema de segurança caracterizado pela existência de um agente que busca obter algum tipo de retorno, atingindo um ativo de valor, por exemplo, dinheiro; ativo: algo de valor protegido pelo sistema. Geralmente está aliado com uma propriedade de segurança, por exemplo, a confidencialidade dos dados do orçamento; vulnerabilidade: uma falha no sistema que é explorada em todo o ataque. O ataque pode ser intencional ou pode ocorrer por erros de operação e que permita que o ativo seja atingido; ameaça: é um ataque a um ativo da informação. É um agente externo que, aproveitando-se da vulnerabilidade, poderá que brar um ou mais dos três princípios de segurança. •

•

•

•

•

Além destas três propriedades principais, têm-se também as seguintes propriedades conceituadas em [3]:

32

Engenharia de Software Magazine - Conhecendo a ISO 15408

O sistema está em risco quando apresenta vulnerabilidades que podem ser exploradas produzindo algum impacto negativo. Neste contexto, pode-se ter um ativo com várias vulnerabilidades, mas sem ameaças de ataque, o que se leva a ter uma probabilidade próxima de zero. Neste contexto, a

SEGURANÇA DA INFORMAÇÃO

probabilidade significa a chance de uma falha de segurança ocorrer, levando-se em conta as vulnerabilidades do ativo e as ameaças que venham a explorar esta vulnerabilidade A Figura 1 mostra um exemplo da probabilidade de ocorrência dos ataques e qual é o dano esperado. Perceba que no exemplo deve-se priorizar a correção da ameaça 3 que é a que possui maior probabilidade de ocorrência e impacto.

Howard e Leblanc [15] listam algumas razões para as pessoas não se preocuparem com a segurança: a segurança é entediante; a segurança costuma ser vista como um desativador de funcionalidade, como algo que atrapalha; a segurança é difícil de medir; normalmente, a segurança não é a principal habilidade ou interesse dos projetistas e desenvolvedores que criam o produto; a segurança não significa criar algo novo e animador. • •

• •

•

Processos de desenvolvimento

Figura 1. Priorização de ameaças

Por fim, é importante termos em mente que o defensor pode se defender somente de ataques conhecidos, já o invasor pode investigar as vulnerabilidades desconhecidas.

Desenvolvimento de Software Seguro A autenticidade, integridade, sigilo e aceitação, consistem nos principais fundamentos para que os objetivos de segurança possam ser inteiramente aplicados. Neste contexto, ao se trabalhar com o desenvolvimento de sistemas seguros, as seguintes questões devem ser consideradas: segura nça do ambiente de desenvolvimento: ter o comprometimento da equipe e evitar roubo do código-fonte; segurança da aplicação desenvolvida: seguir a especificação de segurança, evitar acessos ocultos (backdoor) e falhas que comprometam a segurança; garantia de segurança da aplicação desenvolvida: garantir para o cliente que a aplicação em desenvolvimento é segura. •

•

O risco de problemas com segurança sempre vai existir. O dilema é trazer o “grau de risco” a um nível aceitável, de modo que se possa evoluir na utilização da tecnologia até um patamar mais confiável e eficaz. De acordo com Oliveira [19], é impossível ter um sistema totalmente seguro. Os riscos podem ser amenizados quando são identificados, mas nunca totalmente eliminados. O sistema seguro é aquele que concentra suas defesas nos ataques mais prováveis e com maior perda esperada [1]. Para Lyra [17], as funcionalidades de segurança devem ser representadas nos vários níveis de abstração, desde o projeto lógico, até a implementação de seus produtos finais. Assim, se uma empresa deseja começar a implementar segurança, ela deverá primeiro fazer o planejamento de segurança, e este planejamento precisa contemplar as seguintes atividades: definir planejamento de segurança e identificar seus mecanismos; atribuir responsabilidades de segurança no projeto; implementar ambientes de processa mento; planejar o gerenciamento de incidentes de segurança. •

• • •

Para as empresas que seguem algum tipo de processo de desenvolvimento de software, Howard e Leblanc [15] sugerem a atualização do processo, incluindo aprimoramentos de segurança em cada etapa do ciclo de vida. Na Figura 2 é exibido um modelo em cascata acrescentando as questões de segurança em cada etapa do processo.

•

Essas questões estão sempre interligadas uma com a outra, não há como se conseguir uma aplicação segura sem um am biente de desenvolvimento seguro. Conforme Conallen [10], o maior responsável por ataques são as falhas de segurança contidas nos softwares. É tarefa dos arquitetos entenderem e administrarem as falhas, já que possuem um bom conhecimento do sistema. Algumas empresas não se preocupam com os profissionais que irão desenvolver os sistemas colocando, por exemplo, func ionários não especializados em programação, como web designers, para programar. Pela falta de conhecimento, acabam gerando falhas no código e deixando o sistema vulnerável [22].

Figura 2. Melhorias incrementais da segurança no processo de desenvolvimento


33

Howard e Leblanc [15] afirmam que a preocupação já deve vir na contratação do profissional que irá trabalhar no projeto, verificar se ele possui habilidades de segurança. Treinar os profissionais em segurança também é uma boa prática. De acordo com Albuquerque e Ribeiro [1], existem ame aças ao negócio ou ao objeto da aplicação que precisam ser eliminadas ou, ao menos, mitigadas. Neste sentido, é necessário determinar quem é o público-alvo e quais serão os requisitos de segurança que o sistema conterá e coloca as seguintes questões: quem é o público do aplicat ivo? o que a segurança significa para o público? Há alguma distinção entre diferentes membros do público? Os requisitos de segurança são diferentes para diferentes clientes? onde o aplicativo será executado? Na internet? Por trás de um firewall? Em um telefone celular? o que você está tentando proteger? quais são as implicações para os usuários, se os objetos que você está protegendo forem comprometidos? quem vai gerenciar o aplicativo? O usuário ou um administrador de Tecnologia da Informação (TI) corporativo? quais são as necessidades de comunicação do produto? O produto é interno ou externo à organização, ou ambos? quais serviços da infra-estrutura de segurança que o sistema operacional e o ambiente já fornecem e de que você pode tira r proveito? como o usuário precisa ser protegido de suas próprias ações?

funções intrinseca mente seguras: tratar todas as variáveis de entrada como não-confiáveis, verificando sua validade antes de usá-las; sempre verificar os códigos de erro retornados por uma função, principalmente nas chamadas a Application Programming Interface (API) do sistema operacional; atentar sempre para o tamanho dos buffers e arrays do sistema; documentar o código: se for trabalho em equipe, é indispensável para que não ocorra falha de comunicação entre a equipe. •

•

•

•

• •

•

• •

•

•

•

•

Tendo feito o levantamento de ameaças, tem-se o objet ivo de segurança. Cada ameaça está relacionada com um objetivo de segurança. Porém, deve-se cuidar para não gerar um plano muito caro, corrigindo todas as ameaças, mas sim, tratar somente as ameaças significat ivas, ou com maior probabilidade de impacto. Proteger o sistema das principais ameaças dificulta os ataques. Desta forma, são levantadas as métricas para o desenvolvimento de software, medição de riscos, e quanto a empresa deverá investir em segurança. Levantadas as métricas, pode-se verificar qual o nível de segurança q ue o sistema deve atingir.

Boas práticas de programação Os padrões de desenvolvimento visam melhorar a estrutura interna de um programa, gara ntir maior legibilidade do código, padronização da codificação, facilidade na manutenção, maior produtividade, rapidez no desenvolvimento, redução da quantidade de códigos e facilidade da detecção de erros. Ao seguir as normas da boa programação, automaticamente são eliminados muitos dos erros e falhas de segurança em uma aplicação. Algumas normas de boa programação são [1]:

34


Além das boas práticas de programação, existem também legislações ou políticas de segurança que é preciso obedecer. Para isso, foi criada a norma ISO/IEC 15408, que dita um processo de desenvolvimento de software seguro, com a realização de testes e acompanhamento do projeto. Ela também fornece base para certif icar os produtos, avaliando a sua segurança.

Norma ISO/IEC 15408 A norma ISO/IEC 15408 surgiu para unificar padrões de segurança e eliminar as diferenças de critérios. O primeiro padrão para avaliação da segurança surgiu nos EUA na década 1980. Foi nomeado de Trusted Computer System Evaluation Criteria (TCSEC), mais conhecido como Orange Book devido a sua capa laranja. Em 1991 foi criada a norma para certificaç ão de segurança chamada de Information Technology Security Evaluation Criteria (ITSEC) por uma comissão européia envolvendo os países Alemanha, França. Holanda e Reino Unido. O ITSEC se tornou um padrão europeu voltado tanto para a avaliação de produtos, como de sistemas. Outros padrões surgiram na década de 1990, como Canadian Trusted Computer Product Evaluation (CTCPEC) que é a junção das normas TCSEC e ITSEC e o Federal Criteria (FC) desenvolvida pelos EUA. Com o grande número de normas, as empresas internacionais começaram a ter problemas para certificarem seus produtos. Assim, foi sugerida à ISO a criação de um cr itério único de avaliação de segurança, surgindo assim a norma ISO 15408:1999, dando-lhe o nome de Common Criteria (CC). Na Figura 3 é representada a evolução do critério de segurança mencionado acima. A ISO 15408 é um padrão internacional de desenvolvimento de produtos seguros, o qual descreve uma lista de critérios de segurança que um produto deve ter. Assim, a norma desenvolve um critério de avaliação de segurança da informação, dando segurança aos clientes, testando e certificando seus produtos e serviços. A ISO 15408 está dividida em três partes: Define o conceito e os princípios gerais da avaliação da segurança da informação em TI e apresenta a lista de requi sitos de segurança, que estão divididos em classe, família e requisito; •

SEGURANÇA DA INFORMAÇÃO

Cataloga uma série de requisitos func ionais e organizados em famílias e classe para a avaliação do Target Of Evaluation (TOE – sistema que está sendo avaliado). Os requisitos para a classe Auditoria da Segurança estão apresentados na Tabela 1. Define o critério de avaliação para o Protection Profile (PP) e Security Target (ST) e apresenta sete pacotes de segurança pré-definidos que são chamados de Evaluation Assurance Level (EAL). •

•

de testes e, portanto, uma maior garantia de que o sistema atende aos requisitos de segurança. Os níveis da norma ISO/ IEC 15408 são: EAL1: certifica que o TOE teve seu funcionamento testado; EAL2: estabelece que o sistema teve sua estrutura testada. Envolve a cooperação do fabricante; EAL3: certifica que o TOE foi metodicamente testado e checado; EAL4: define que o sistema foi metodicamente projetado, testado e checado; EAL5: prevê que o sistema sej a implementado e testado de maneira não formal; EAL6: certifica que o TOE foi projetado, verificado e testado de maneira não formal; EAL7: define que o sistema foi projetado, verificado e testado de maneira formal. •

•

•

•

•

•

•

Figura 3. Evolução do critério de segurança

AUDITORIA DE SEGURANÇA

FAU_ARP - Resposta automática a auditoria FAU_ARP.1 - Alarmes de segurança FAU_GEN - Geração de dados para auditoria FAU_GEN.1 - Geração de dados para auditoria FAU_GEN.2 - Associação do usuário ao evento de auditoria FAU_SAA - Análise da auditoria de segurança FAU_SAA.1 - Análise de violação potencial FAU_SAR - Revisão de dados da auditoria FAU_SAR.1 - Revisão de auditoria FAU_SEL - Auditoria seletiva FAU_SEL.1 - Auditoria seletiva FAU_STG - Armazenamento da trilha de auditoria FAU_STG.1 - Armazenamento protegido da trilha de auditoria FAU_STG.2 - Garantia da disponibilidade dos dados para auditoria Tabela 1. Classe auditoria de segurança

É fácil ver que atingir o nível EAL7 de segurança leva tempo e dinheiro. Para os sistemas comerciais, o nível EAL3 traz uma segurança significativa a um custo menor. Ao seguir os padrões e a ideia da ISO 15408 já se pode obter um nível elevado de segura nça no desenvolvimento dos sistemas, pois aplicar a norma em sua totalidade exige muitos detalhes, avaliações por laboratórios internacionais e o custo pode se tornar alto.

Auditoria de software A auditoria é uma atividade que engloba o exame das operações, processos, sistemas e responsabilidades gerenciais de uma determinada entidade, com intuito de verificar sua conformidade com certos objetivos e políticas institucionais, orçamentos, regras, normas ou padrões. Dias [12] relata a existência de três modelos de auditoria da segurança: Auditoria da segurança de informações: determina a postura da organização com relação à segurança, que geralmente envolve itens como controle de acesso lóg ico, físicos e ambientais; Auditoria da tecnologia da informação: abrange toda a segurança da informação, como também os controles organizacionais, de operação de sistemas e sobre o banco de dados; Auditoria de aplicativos: determina a segurança em aplicativos específicos tendo, como controles o desenvolvimento de sistemas aplicativos, de entrada processa mento de entrada e saída de dados, sobre o conteúdo e funciona mento do aplicativo. •

•

•

A ISO 15408 estabelece que qualquer sistema, para ser considerado seguro, deve ter seu ST elaborado. O ST é a especificação de segurança, ou seja, indica quais aspectos de segurança foram considerados importantes e por que o foram para aquele sistema em particular. Existe também o PP, que é um documento semelhante ao ST, com a diferença que não especifica uma única aplicação, podendo ser aplicação a toda uma classe de sistema. A ISO 15408 define sete níveis para garantir segurança, de nominados de EAL. Para cada nível, tem-se um maior número

Para ser um auditor na área da tecnologia de informação, deve-se ter um bom conhecimento na área de sistemas computacionais, de preferência já ter trabalhado nela. O nível de conhecimento varia de acordo com os requisitos que o auditor irá avaliar.


35

Segundo Lyra [17], primeiro inicia-se o processo de levantamento das informações relevantes sobre o sistema. Esse levantamento deve ser feito de modo abrangente, de forma que seja possível o entendimento macro das características do sistema.

Conclusões A segurança hoje é fundamental no desenvolvimento dos sistemas. Neste sentido, vimos neste artigo que a norma ISO/IEC 15408 surgiu com intuito de fornecer uma série de requisitos de

segurança a serem seguidos. Com isso, pode-se medir o nível de segurança em que o sistema encontra-se, fornecendo-se alguma garantia para o cliente. 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! Dê seu voto sobre este artigo, através do link:

u

e s ê

F eedb a c k

D

o

s

b

r

e

o ç

www.devmedia.com.br/esmag/feedback

Referências

1. ALBUQUERQUE, Ricardo; RIBEIRO, Bruno. Segurança no desenvolvimento de software. Rio de Janeiro: Campus, 2002. 310 p.

12. DIAS, Claudia. Segurança e auditoria da tecnologia da informação. Rio de Janeiro: Axcel B ooks, 2000. 218 p.

2. ALLEN, Julia H. et al. Software security engineering: a guide for project managers. Upper Saddle River, NJ: Addison-Wesley, 2008. 334 p.

13. FRANZINI, Fernando. Java para web: autenticação e autorização em aplicativos web 2. [S.I.] 2009. Disponível em: . Acesso em: 04 maio. 2010.

3. AZEVEDO, Denny. Metodologias de segurança de sistemas. São Paulo: IFSP, 2008. Disponível em: . Acesso em: 19 mar. 2009. 4. BATISTA, Carlos F. A. Métricas de segurança de software. 2007. 103 f. Dissertação (Mestrado em Informática) - Programa de Pós-Graduação em Informática, Pontifícia Universidade Católica do Rio de Janeiro, Rio de Janeiro. Disponível em: . Acesso em: 20 mar. 2009. 5. BRANDÃO, José E. M.S.; FRAGA, Joni da S. Gestão de riscos. In: SIMPÓSIO BRASILEIRO EM SEGURANÇA DA INFORMAÇÃO E DE SISTEMAS COMPUTACIONAIS, 8., 2008, Porto Alegre. Anais... Porto Alegre; SBC, 2008. p. 1-43. 6. BRAZ, Fabricio. Software seguro: O que esperar Fortify Souce Code Analyzer? Brasilia, 2008. Disponível em: . Acesso em: 03 mar. 2010. 7. BURNETT, Steve; PAINE, Stephen. Criptografia e segurança: o guia oficial RSA. Rio de Janeiro: Elsevier: Campus, 2002. 367 p. 8. CODEHOUSE. QDox. [S.l.]: 2010. Disponível em: . 9. COMMON CRITERIA. The Common Criteria portal. [S.l.][2009?]. Disponível em: . Acesso em: 21 mar. 2009. 10. CONALLEN, Jim. Desenvolvendo aplicações WEB com UML. Rio de Janeiro: Campus, 2003. 476 p. 11. CUGIK, Fernando L. Software livre para verificação de adequação de servidores Gnu/Linux à norma de segurança NBR ISO/IEC 27002. 2007. 74 f. Trabalho de Conclusão de Curso - (Bacharelado em Ciências da Computação) - Centro de Ciências Exatas e Naturais, Universidade Regional de Blumenau,Blumenau.

36


14. GUERRA, Eduardo. Os sete pecados do controle de acesso em aplicações Java EE. Mundojava, Curitiba, n. 28, p. 26-36, abr. 2008. 15.HOWARD, Michael; LEBLANC, David.Escrevendo código seguro: estratégias e técnicas práticas para codificação segura de aplicativos em um mundo de rede.Porto Alegre: Bookman, 2005.701 p. 16. ITEXTPDF. your Java-PDF library. [S.l.], 2010. Disponível em: . Acesso em: 04 abr. 2010. 17. LYRA, Maurício R. Segurança e auditoria em sistemas de informação. Rio de Janeiro: Ciência Moderna, 2008. 253 p. 18. NUNES, Francisco J.; BELCHIOR, Arnaldo D. Processo seguro de desenvolvimento de software. Ceará, 2006. Disponível em: . Acesso em: 20 mar. 2009. 19. OLIVEIRA, Wilson J. Segurança da in formação: técnicas e soluções. Florianópolis: Visual Books, 2001. 182 p. 20. ROSEMANN, Douglas. Software para avaliação da segurança da informação de uma empresa conforme a norma NBR ISO-IEC 17799. 2002. 93 f. Trabalho de Conclusão de Curso (Bacharelado em Ciências da Computação) - Centro de Ciências Exatas e Naturais, Universidade Regional de Blumenau,Blumenau. 21. SOURCEFORGE.NET. Welcome to dom4j 2.0. [S.l.], 2007. Disponível em: . Acesso em: 21 mar. 2010. 22. THOMPSON, Marco A. Proteção e segurança na internet. São Paulo: Érica, 2002. 244 p.

e s t a e


Testes funcionais de software

Elisângela Andrade Bruno

De que se trata o artigo?

[email protected]

Este artigo apresenta uma introdução aos conceitos de Testes Funcionais de Software durante o processo de validação e medição da qualidade do produto desenvolvido. Sendo assim, o artigo serve para apresentar o conceito de qualidade e demonstrar como métodos de Testes de software, utilizados no processo de desenvolvimento, podem auxiliar na validação e medição da qualidade do produto.

Graduada em Ciência da Computação pela Faculdade Anhanguera de Santa Bárbara (2009). Programadora na IST Sistemas Ltda. Possui experiência de 4 anos na área de Ciência da Computação,com ênfase em Sistemas de Informação, atuando como desenvolvimento de sistemas,programação orientada a objetos e linguagem de programação .net.

Paulo C. Barreto da Silva [email protected]

Graduado em Análise de Sistemas pelo Centro Universitário Salesiano de São Paulo (2003) e Pós-graduado pela UNICAMP - na área de Orientação a Objetos (2005). Professor da Anhanguera Educacional SA e Analista de Sistemas na Papirus Indústria de Papel SA.

Thiago Salhab Alves [email protected]

Graduado em Ciência da Computação pela Universidade Metodista de Piracicaba UNIMEP (2004) e Mestre em Ciência da Computação pela Universidade Metodista de Piracicaba - UNIMEP (2008). Professor e Coordenador do curso de Ciência da Computação da Faculdade Anhanguera de Santa Bárbara. Possui seis anos de experiência na área de Ciência da Computação com ênfase em Engenharia de Software.

A

tualmente os softwares são empregados em todos os seguimentos da sociedade, tanto para sistemas cujos requisitos sejam simples quanto para aplicações sofisticadas e de grande complexidade. Um exemplo de sistema complexo são os softwares de uso exclusivo para a área de medicina. Com a ampla utilização das tecnologias da informação, a qualidade do produto tem se tornado imprescindível nos processos de desenvolvimento de aplicações e no momento de avaliação do projeto. O teste de software, cujo objetivo é revelar a presença de defeitos e aumentar a confiança sobre o software, é considerado um elemento crítico para a garantia da qualidade do produto. As atividades de testes podem muitas vezes se tornar exaustivas e trabalhosas, dificultando assim a execução dos testes de forma adequada para a análise de qualidade. Com o objetivo de melhorar a qualidade da análise e o tempo de execução dos testes, foram criados os testes

Em que situação o tema é útil? Na elaboração de um padrão de validação onde constantemente seja necessária a validação do desenvolvimento realizado, e testes complexos que exigem grande esforço da equipe de desenvolvimento.

Resumo? Os testes funcionais permitem que os testes ocorram de uma forma mais eficiente e rápida, possibilitando encontrar as não conformidades do software em relação aos requisitos do sistema. O presente artigo cita os principais conceitos dos Testes Funcionais de Software e apresenta alguns detalhes extraídos de sua forma de implementação.


37

automatizados, que proporcionam a execução dos testes mais rapidamente, e com maior cobertura do software. De acordo com Pressman, autor do livro Engenharia de Software, o principal objetivo dos testes de software é a localização de erros, falhas, defeitos (ler Nota do DevMan 1) e a verificação das funcionalidades do software em desenvolvimento ou finalizado.

Nota do DevMan 1 Defeito, Erro e Falha: Defeito é uma deficiência mecânica ou algorítmica (deficiência no código) que se ativada pode levar a uma falha.

Erro é um estado de execução que impede o software de continuar, pode ser causado por algo externo ao software ou falhas na grafia do código fontes, tais como ausência de ponto-e-virgula e parâmetros. Uma Falha é um evento notável onde o sistema viola suas especificações, é a existência aparente de um defeito.

Através do processo de testes, busca-se avaliar se estas funcionalidades estão aparentemente trabalhando de acordo com as especificações e requisitos do projeto, garantindo que o software atinja o nível de qualidade esperada pelos interessados no produto.

Principios dos Testes Segundo Brunelli, os componentes essenciais para o teste de software de um programa podem ser divididos em: Executável do programa (código do programa compilado); Relação dos comportamentos esperados; Apresentação do mecanismo de avaliação dos comportamentos esperados; Descrição das funções; Descrição de como observar se uma ação resultou na execução esperada. • • •

• •

O levantamento dos comportamentos esperados é considerado uma das maiores dificuldades na elaboração dos testes, portando sua elaboração deve ser feito de forma cautelosa e de acordo com os requisitos do sistema. Isso se deve ao fato de que os comportamentos do software nem sempre são previstos na etapa de levantamento de requisitos, sendo necessária a posterior elaboração da lista de comportamentos esperados versus funções requeridas. Segundo Sommerville, um caso de teste bem elaborado possibilita a identificação e solução de erros inéditos, tornando seu processo muito mais eficiente. Enfim, os testes de software visam mostrar aos clientes, através da exibição de erros detectados, que o software está funcional de acordo com as especificações propostas e requisitos desejados.

38

Engenharia de Software Magazine - Testes funcionais de software

O processo de testes O Processo de Teste, como qualquer outro processo, necessita ser refinado continuamente, permitindo seu amadurecimento, de maneira a ampliar sua atuação e permitir aos envolvidos no projeto uma maior visibilidade e organização dos seus trabalhos. O que se deseja nesta etapa é uma maior agilidade e controle operacional dos projetos de testes. Realizar testes de software é uma tarefa bastante complexa quando se desconhece o que é qualidade. Nas indústrias automobilísticas, como é o caso da maioria das grandes indústr ias, qualidade está intimamente associada a custo de retrabalho. No início da década de 60, por volta do ano de 1962, foi criado no Brasil um comitê específico para trabalhar a normalização destas regras visando sua implantação nas empresas. A qualidade, muitas vezes associada a certificações como ISO 9001, CMMI e tantas outras que existem por aí, não passam de for malizações de boas práticas que com o passar do tempo foram aperfeiçoadas e implementadas de forma comum. O processo de Testes de Software deve contemplar, além de um roteiro com objetivos bastante claros, a declaração dos itens a serem avaliados e quais são os índices esperados, como por exemplo, defeitos por número de f unções. Na área de Engenharia de Software, desde Roger Pressman e seu livro Engenharia de Software, que inclusive é uma das referências deste artigo, muitas companhias passaram a compreender que qualidade apenas pode ser obtida com auditoria do processo e certificação dos itens que possuem maior impacto no resultado do produto. Falando especificamente de Testes, podemos citar como principais técnicas: • Teste Funcional; • Teste Estrutural; • Teste Baseado em Falha ou Erro; • Teste de Caixa Branca; • Teste de Regressão. Veremos agora cada uma destas técnicas e quais as suas particularidades.

Teste funcional O teste funcional, que também é conhecido como teste “caixa - preta”, são os testes definidos de acordo com os requisitos funcionais do software. Como não há conhecimento sobre a operação interna do programa, o analista concentra-se nas funções que o software contemplará. Baseado na especificação determina-se as saídas que são esperadas para um determinado conjunto de dados. Esse tipo de teste reflete a ótica do usuário, o stakeholder (ler Nota do DevMan 2) interessado em utilizar o programa, sem levar em conta os detalhes de sua construção. Comparado a outros modelos, sua concepção é relativamente simples. Segundo Koscianski, o teste é particularmente útil para revelar problemas como: • Funções incorretas ou omitidas; • Erros de interface;

TESTE DE SOFTWARE

• Erros de comportamento ou desempenho; • Erros de iniciação e término.

teste completo, dado o grande numero de possibilidades existentes.

Nota do DevMan 2

Nota do DevMan 3

Stakeholder: Os interessados em um projeto (stakeholders) são todas as pessoas da organização que têm algum tipo de envolvimento direto ou indireto com o sistema, como usuários, gerentes, clientes, patronos e financia dores.

A principal técnica utilizada nos testes funcionais é a de particionamento de equivalência, que visa uma divisão em subconjuntos das entradas de valores de acordo com as funcionalidades do software, por exemplo, a inserção de uma massa dados para validar o processo de inserção. Seu principio é a escolha da melhor abordagem a ser utilizada e a melhor maneira de se obter a validação dos erros e aumento da confiabilidade (BRUNELI, 2006). Uma maneira muito eficaz é analisar os dados resultantes e melhorar validações e verificações de entrada. Além da técnica de particionamento de equivalência, existem diversas outras técnicas que podem ser adotadas como a de Análise do valor limite, Grafo Causa-Efeito e Error-Guessing.

Teste estrutural O Teste estrutural, também conhecido como teste “caixa – branca” ou teste “caixa–de–vidro” ou ainda teste “caixa– clara”, são os projetos de casos de testes onde seus testes são desenvolvidos a partir dos conceitos de implementação do software e da estrutura desenvolvida. Os testes caixa–branca possibilitam avaliar a estr utura interna do programa, sua codificação, módulos, implementação e execução particionada do software, sendo que as informações obtidas deste processo de validação também são utilizadas para a criação dos casos de testes. Em geral, existem diversos critérios para a elaboração dos testes estruturais, representados com o apoio dos Grafos de Fluxo de Controle ou Grafos de Programa (ver Figura 1), demonstrando de maneira clara o fluxo lógico da execução do programa. Os critérios dos testes estruturais podem ser destacados como: Critérios Baseados em Fluxo de Controle, Critérios Baseados na Complexidade e Critérios Baseados no Fluxo de Controle. Critérios Baseados em Fluxo de Controle: Segue de acordo com as características de execução do programa (comandos e desvios). Para elaboração da lista de verificação são utilizados critérios como: - Todos – Nós, método que exige que cada comando da aplicação seja executado pelo menos uma vez, passando por cada vértice do grafo (ler Nota do DevMan 3); - Todos – Arcos (ler Nota do DevMan 4), método que requer que cada aresta do grafo seja executada pelo menos uma vez; e - Todos – Caminhos, que requer que todos os caminhos possíveis do programa sejam executados, criando assim um •

Nós: É construído através do código-fonte, onde os seus comandos são os nós do Grafo, ou seja, são os pontos do grafo, seguindo a sequência dos comandos (VILELA c, 2005).

Nota do DevMan 4 Arcos: São os desvios que ocorrem no código-fonte do programa, as linhas que ligam os nós, ou seja, a transferência de controle entre os blocos ( VILELA c, 2005).

•

Critérios Baseados na Complexidade: São criados a partir

dos requisitos de testes e classificados de acordo com o seu grau de complexidade. Um dos critérios que são utilizados é o Critério de McCabe, que visa a execução do programa através de conjuntos lineares independentes, estabelecendo um número de caminhos linearmente independentes do programa. Ou seja, caminhos que introduzam pelo menos um novo conjunto de instruções de processamento ou uma nova condição, utilizando o conceito da complexidade ciclomática (ler Nota do DevMan 5) para os requisitos de teste;

Nota do DevMan 5 Complexidade Ciclomática: Técnica utilizada para avaliação da complexidade de altorítmos. A fórmula utilizada no cálculo da Complexidade Ciclomática é CC = Número de arcos – Número de nós + 2, e Server para determinar a quantidade de casos de teste mínima para testar os caminhos independentes do programa.

•

Critérios Baseados no Fluxo de dados: Utiliza informações do

fluxo de dados do programa para a criação dos requisitos dos testes. Incluem critérios de adequação de controle de fluxo, que analisam o grafo de execução de um programa; critérios de adequação baseados no fluxo de dados, que analisam os caminhos que o código percorre entre a inicialização dos dados e os pontos onde são alterados e lidos; e critérios de adequação baseados em uma combinação dos dois tipos, que usam relações de dependência entre os comandos e os seus dados operandos. Como foi dito, na identificação dos caminhos que devem ser testados pode-se utilizar a técnica Complexidade Ciclomática. Através dela é possível fazer a identificação da quantidade de testes necessários (ver Figura 1) garantindo que todas as instruções sejam executadas ao menos uma vez.


39

Firme são realizadas alterações no programa para a criação do programa mutante, sendo que as comparações acontecem desde o início até o término da execução.

Testes de regressão

Figura 1. Exemplo de Grafo de Fluxo (VILELA C,2005)

A Figura 1 apresenta um exemplo de Grafo de Fluxo demons trando, com a ajuda da complexidade ciclomática, o código implementado, onde são separados os estados de acordo com as decisões do programa e obedecendo a sua ordem no decorrer da execução do software. A utilização destes Grafos auxilia na criação dos casos de testes.

Testes baseados em falha ou erro Os Testes Baseados em Erros e Falhas são criados a partir das informações dos erros mais comuns que os desenvolvedores cometem no processo de desenvolvimento, formando uma base de conhecimento que auxilia na criação dos novos casos de testes. Para o desenvolvimento dos casos de testes, existem algumas técnicas que podem ser empregadas, como: Semeadura de Erros e Análise de Mutantes. No critério de Semeadura de Erros são inseridos artificialmente no programa alguns erros. Após estas inserções são analisados os erros encontrados e verificados quais são erros prováveis e improváveis, descartando apenas aqueles que foram propositalmente inseridos para avaliarmos o comportamento da execução. Através do conceito de probabilidade pode se chegar à quantidade provável de erros naturais que podem conter no software. No critério de Análise de Mutantes são criados programas com pequenas alterações em cima daquele software que será testado. O objetivo é avaliar a quantidade de testes necessários para o software em questão Na Análise de Mutantes o foco é encontrar casos de testes capazes de revelar diferenças de comportamentos entre o software original e os softwares cujos trechos foram modificados, ou seja, nos softwares mutantes. Ao final, os resultados obtidos da versão original são comparados com a versão modificada. Os tipos de critérios existentes na Análise de Mutantes são a Mutação Fraca e a Mutação Firme. Na Mutação Fraca cr ia-se o mutante inicialmente, antes do início da execução e após seu término quando os dados são comparados. Na Mutação

40

Engenharia de Software Magazine - Testes funcionais de software

Essa é uma técnica de teste aplicável a uma nova versão de software ou a uma versão em desenvolvimento. Ela consiste em aplicar, a cada nova versão do software ou a cada ciclo, todos os testes que já foram aplicados nas versões ou ciclos de teste anteriores do sistema. Inclui-se nesse contexto a ob servação de fases e técnicas de teste de acordo com o impacto de alterações provocado pela nova versão ou ciclo de teste. Para efeito de aumento de produtividade e de viabilidade dos testes, é recomendada a utilização de ferramentas de automação, de forma que, sobre a nova versão ou ciclo de teste, todos os testes anteriores possam ser executados novamente com maior agilidade.

Projeto de casos de testes O projeto de casos de testes define as situações que serão utilizadas como base tanto para validar os requisitos funcionais quanto para avaliar a eficácia dos componentes. No projeto de casos de testes são descritas suas entradas e saídas (ver Nota do DevMan 6), de acordo com cada característica do software, visando os requisitos e especificações do projeto. Os casos de testes são elaborados para exercitar adequadamente as estruturas do programa.

Nota do DevMan 6 Entradas e Saídas: Dado de Entrada – Conjunto de todos os valores que podem ser usados como entrada para um programa. Dado de Saída – Conjunto de valores que podem ser obtidos como saídas do programa.

Os casos de teste podem ser utilizados em diversos seguimentos. Segundo Sommerville, os principais são: Na criação e implementação de esquemas de scripts de testes, fornecendo os pontos–chaves de acordo com as implementações dos requisitos no momento da codificação do software; Utilização de scripts para identificação dos melhores testes, tanto para testes manuais quanto para testes automáticos; Um controle dos números de teste específicos para abranger todo o software. •

•

•

Fases de teste Os testes de software possuem estratégias que são utilizadas na execução dos testes, e podem ser divididos em etapas como: Teste de Unidade, Teste de Integração, Teste de Componentes, Teste de Validação e Teste de Sistema. As estratégias de testes permitem a verificação dos erros nos diversos tipos de software, possibilitando uma maior cobertura do software de acordo com o nível do teste, podendo ocorrer

TESTE DE SOFTWARE

em baixo nível ou em alto nível. Os testes de baixo nível focam uma funcionalidade específica que se deseja testar, enquanto os testes de alto nível têm o objetivo de verificar as f unções do software de acordo com os requisitos do sistema.

Teste de unidade O teste de unidade é a fase de teste que tem como finalidade testar individualmente as funcionalidades do software em questão, garantindo que todas as funcionalidades do software sejam testadas pelo menos uma vez. Uma das desvantagens do teste de unidade é que sua implementação é exaustiva e necessita de prazos maiores para realização, sendo que para a realização dos testes deve-se con hecer os objetivos e especificações dos requisitos de cada uma das funcionalidades do software. Por outro lado, sua vantagem é a localização e prevenção de falhas por estar testando cada uma das funcionalidades individualmente.

Teste de integração O teste de integração é a fase que testa a integração dos componentes do sistema, se estão de acordo com os requisitos do software, levando em consideração a sua funcionalidade em conjunto e não as suas regras de negócios, procurando assim erros associados a interfaces. O teste de integração pode ser dividido em dois tipos: Não Incremental: Os módulos do sistema são interligados e combinados, e o software é testado como um todo, dificultando a localização dos erros e a correção dos erros encontrados; Incremental: O software é testado em partes, possibilitando que as interfaces sejam testadas de forma incremental, facilitando encontrar erros e isolá-los para correção. O teste incremental possui duas estratégias: - Integração descendente (top-down), onde os módulos do sistema são integrados de cima para baixo de acordo com a hierarquia de controle do software; e - Integração ascendente (bottom-up), onde a construção e os testes dos módulos são iniciados da parte mais baixa da estrutura do software. •

•

Teste de componentes No teste de componentes os componentes do software são testados separadamente de acordo com a especificação e estrutura das funcionalidades. Estes componentes são as integrações de interface e unidades do software, com diversas classes no seu desenvolvimento.

Teste de validação O teste de validação tem como objetivo avaliar se o sistema desenvolvido funciona de maneira que atenda a todas as especificações dos requisitos do software e o processo de regras de negócios estabelecidas na sua elaboração.

Teste de sistema

O objetivo do teste de sistema é exercitar todo o software, assegurando que todos os elementos que compõem o sistema estão de acordo com as especificações dos requisitos, incluindo todos os itens de hardware e software que compõem a regra de negócio. Existem vários tipos de teste de sistema, tais como: Teste de Desempenho (agilidade), Teste de Segurança (confia bilidade), Teste de Recuperação (recuperação de dados) e Teste de Inicialização (inserção).

Testes automatizados Os testes automatizados são desenvolvidos como programas ou scripts que têm como principal objetivo exercitar o sistema, testando as funcionalidades e verificando se estão de acordo com as especificações dos requisitos do sistema e os objetivos esperados. Existem diversas vantagens para a utilização dos testes automatizados, dentre elas destacam-se: • Menor tempo na execução dos testes; • Verificação do sistema durante o processo de desenvolvimento; • Alcançar melhor qualidade do software; • Casos de testes mais elaborados. A grande vantagem dos testes automatizados é que podem ser repetidos a qualquer momento, seja em uma nova funcionalidade ou alguma modificação em uma funcionalidade específica. Sua implementação reduz os esforços e o tempo gasto, reduzindo as chances de que ocorram falhas humanas na execução dos testes. Os testes automatizados reduzem o tempo no processo de testes, porém, precisa ser complementado por outros tipos de testes.

Conclusão A utilização de testes ao longo do projeto de desenvolvimento e implementação do software permite que tenhamos uma ampla visão sobre o comportamento do mesmo, eliminando falhas e erros que poderiam causar divergência em seu funcionamento. Como foi apresentado, um plano de testes possibilita encontrarmos as não conformidades do software em relação aos requisitos do sistema e resolve-las de uma forma rápida e eficaz. Vimos que existem várias maneiras de se aplicar Testes em um projeto de desenvolvimento, e que todas possuem o mesmo objetivo: reduzir a chance de entregarmos software contendo defeitos para o cliente. Dê seu feedback sobre esta edição!


u

e s ê

F eedb a c k

D

o

s

b

r

e

o ç

e s t a e


O teste de sistema é realizado após o sistema estar pronto, sendo avaliados todos os componentes e funcionalidades.


41

Arquitetura e Desenvolvimento Nesta seção você encontra artigos voltados para diferentes abordagens de apoio ao desenvolvimento de projetos de software

Dando foco ao negócio com DDD Entendendo o domínio do software De que se trata o artigo? Este artigo apresenta o Domain-Driven Design (DDD), abordagem de desenvolvimento de software que mostra uma série de práticas e padrões para se construir um software dando foco principal ao domínio.

N Robson Castilho [email protected]

Trabalha com desenvolvimento de software há 12 anos, tendo desenvolvido sistemas desktop e web para empresas de diversos ramos de atividade. É Bacharel em Ciência da Computação, pela UFMS, e possui as certificações MCTS (Windows/Web), PSD (Professional Scrum Developer) e PSM I (Professional Scrum Master Nível I). Mantém o blog técnico http://robsoncastilho. wordpress.com.

42

o processo waterfall tradicional, toda a fase de desenvolvimento do software é guiada pela parte tecnológica, com pouco ou nenhum foco no negócio. Isto porque toda a análise é feita previamente por um analista de sistemas e passada, em forma de muita documentação, para o time de desenvolvedores, cabendo a eles simplesmente implementar com base nos requisitos recebidos. Já nas metodologias ágeis, embasadas no Manifesto Ágil e seus princípios, a presença constante dos especialistas de negócio junto dos desenvolvedores é algo essencial. O software é entregue aos poucos, sendo assim, análise, implementação e testes são realizados iterativamente, de forma a entregar “pedaços” de software o mais cedo possível. Neste contexto de agilidade, Eric Evans, especialista em modelagem de

Engenharia de Software Magazine - Dando foco ao negócio com DDD

Em que situação o tema é útil? As práticas do DDD auxiliam no desenvolvimento de um software mais coerente com a área de negócio à qual é voltado e, portanto, um software de mais valor para o cliente, fácil de ser mantido e estendido. As técnicas de Design Estratégico facilitam no relacionamento entre diversos times de desenvolvedores, trabalhando em módulos diferentes de um sistema complexo (que podem inclusive terem sido desenvolvidos em diferentes tecnologias).

Resumo? Este artigo introduz o Domain-Driven Design e suas premissas (domínio e modelo), dando bastante enfoque à comunicação com os especialistas de negócio e à modelagem do domínio. São explicados conceitos-chave como a Linguagem Ubíqua e o Model-Driven Design, com seus prin cipais padrões para expressar o modelo no código. Por m, são mostrados os padrões do Design Estratégico, como formas de comunicação entre times/sistemas diferentes.

DDD

domínios complexos, escreveu o livro “Domain-Driven Design – Tackling Complexity in the Heart of Software” (lançado em 2003), com uma série de conceitos e práticas dando foco ao domínio do software. Evans percebeu, ao longo de anos de experiência trabalha ndo em projetos complexos, que os projetos bem-sucedidos tinham em comum um modelo rico do domínio, que evoluía incrementalmente iteração após iteração. Seguindo este pensamento, seu livro deu ênfase justamente na modelagem do domínio – enquanto a maioria dos livros dava ênfase na resolução de problemas tecnológicos, como redes e bancos de dados – tornando-se assim um clássico do gênero. Neste contexto, neste artigo abordaremos alguns dos principais conceitos e práticas do Domain-Driven Design, como a linguagem ubíqua e a comunicação constante com os especialistas de negócio, a modelagem e a implementação como uma única atividade, e as práticas do Design Estratégico.

DDD e suas premissas O Domain-Driven Design (DDD) é uma abordagem de desenvolvimento de software fundamentada em duas premissas: O foco principal deve ser o domínio; Domínios complexos devem estar baseados em um modelo. • •

O domínio de um software é “a área de ação, conhecimento e influência do software”. Sendo assim, focar no domínio é dar mais atenção à área de negócio que o soft ware pretende cobrir do que a detalhes sobre tecnologias a serem empregadas em seu desenvolvimento. Quando estamos trabalhando em domínios complexos – e normalmente estamos – é bastante útil trabalharmos em cima de um modelo. Ao falarmos de modelo, geralmente associamos o termo a algum tipo de diagrama, como um diagrama de classes UML. No entanto, um modelo é mais do que um diagrama, ele é uma tradução do conhecimento dos especialistas de negócio para algo mais padronizado, uma espécie de “molde” do domínio. Para a construção deste modelo, são aplicados padrões do MDD ( Model-Driven Design) que serão vistos na seção correspondente ao mesmo. Um diagrama, seja ele UML ou seguindo qualquer notação que você achar útil, pode ser uma ótima ferramenta para comunicar e registrar alguns aspectos do modelo, enquanto outros aspectos são transmitidos de forma mais clara diretamente pelo código.

Modelagem efetiva Projetar um software orientado ao domínio é uma tarefa muito mais difícil do que simplesmente “ir fazendo”, uma vez que trazer o conhecimento da cabeça de um especialista de negócio para um software, de forma organizada, é algo complexo. A tentativa de se colocar todo o “mundo real” dentro do software acaba gerando um software confuso, de difícil extensão e com recursos que não agregam valor ao usuário final.

Para nos ajudar a organizar um domínio complexo, DDD apresenta uma série de práticas, sendo a modelagem do domínio um conceito-chave para essa tarefa. Deste modo, com o intuito de obtermos sucesso n a modelagem, devemos: Ligar diretamente o modelo à implementação; Estabelecer uma linguagem baseada no modelo, que propicie a comunicação entre desenvolvedores e especialistas de negócio; Desenvolver um modelo rico, onde os objetos tenham comportamento, resolvam problemas complexos e deixem explícitos conceitos importantes do domínio; Destilar o modelo, de forma que somente o que importa permaneça no mesmo; Realizar brainstorming e experimentar diferentes alternativas para o modelo. • •

•

•

•

Falaremos mais sobre modelagem nos tópicos seguintes, entrando em mais detalhes sobre alguns dos itens acima.

Linguagem Ubíqua Todos nós sabemos que especialistas de negócio não entendem linguagem técnica, no entanto, é comum presenciarmos desenvolvedores conversando com eles justamente em termos técnicos, ou seja, falando sobre tabelas, índices, servidores, etc. Isto faz com que acabemos por acostumar os especialistas com essa linguagem e, como consequência, eles acabam tentando definir como fazer tecnicamente ao invés de focarem em explicar o domínio , o que pode ser trágico para um projeto de software.

O ideal, portanto, é que nós desenvolvedores cultivemos uma linguagem comum junto aos especialistas de negócio, totalmente focada no domínio, afinal, a parte técnica é conosco! Surge então um dos conceitos mais importantes em DDD: a “linguagem ubíqua” (Ubiquitous Language), que é a linguagem presente em todas as etapas do processo de desenvolvimento do software, por exemplo: na conversa com os especialistas, na documentação, nos diagramas e no código. A linguagem ubíqua é, portanto, parte integral do processo de desenvolvimento do software, sendo essencial para uma melhor comunicação entre desenvolvedores e especialistas de negócio. Como consequência do uso da linguagem ubíqua, quaisquer alterações na linguagem implicarão em mudanças no modelo e no código. Além disso, desenvolvedores serão capazes de identificar com mais facilidade pontos contraditórios no modelo.

Obtenção de conhecimento No início de um projeto de software, nós desenvolvedores nunca temos total conhecimento sobre o domínio. Por mais que já tenhamos lidado com situações semelhantes em outros projetos, é preciso conhecer as peculiaridades de cada cliente, mantendo contato direto com os especialistas de negócio. À medida que o projeto avança, uma série de fatores pode prejudicar o conhecimento do domínio, tais como troca de membros do time, terceirização de partes do sistema e mudanças de escopo.


43

Sendo assim, é necessário que os desenvolvedores estejam empenhados em manter o conhecimento, praticando o aprendizado contínuo. Para os desenvolvedores, “aprendizado contínuo” significa evoluir constantemente tanto o conhecimento técnico quanto o conhecimento sobre o domínio no qual eles estão trabalhando. O processo de aprendizado pode ser resumido em uma palavra: EXPLORAÇÃO. Esse processo se dá por meio de conversas constantes com os especialistas de negócio, que são fundamentais para se trabalhar com DDD. É preciso ter cuidado com os especialistas que entram em um nível muito profundo de detalhamento, perdendo o foco da conversa, e também com aqueles que omitem muitos detalhes, por acharem que já estão subentendidos ou que os desenvolvedores não irão entendê-los. Cabe aos desenvolvedores conduzir os especialistas, de modo que estes forneçam os detalhes necessários para o entendimento de certa funcionalidade, sem, é claro, tirar-lhes a liberdade para que apontem algo de importante.

Documentação DDD não prescreve nenhuma forma específica de documentação do software. Quanto aos diagramas, DDD sugere a utilização deles para auxiliar na comunicação e facilitar brainstormings com os especialistas. Algumas pessoas são totalmente visuais e desenhar é uma forma de transmitir uma ideia de modo mais objetivo. Para que os diagramas sirvam aos propósitos mencionados acima, eles devem ser enxutos, focados em um determinado assunto. Entretanto, muitos desenvolvedores tentam transmitir todo o modelo em apenas um diagrama, normalmente UML, o que sobrecarrega de informações o leitor, além de não conseguirem mostrar facilmente o comportamento dos objetos. Além da UML, DDD sugere outros tipos de diagramas (mais simples e muitas vezes feitos à mão), como o apresentado na Figura 1.

Figura 1. Diagrama simples para comunicação

Quanto à documentação escrita, deve-se notar quando os termos usados começam a desaparecer das conversas e do código, deixando de fazer parte da linguagem ubíqua. A documentação passa, então, a ser ignorada e mantê-la torna-se um verdadeiro desperdício de esforço (restando ao time arquivá-la como histórico ou excluí-la). Portanto, DDD fornece algumas diretrizes para avaliar a necessidade de se documentar: Documentos devem complementar a fala e o código. Todos os detalhes essenciais do design devem estar presentes no código , por meio de práticas do MDD (Model-Driven Design), que veremos mais adiante; Documentos devem estar envolvidos nas atividades do pro jeto, estando sincronizados com a linguagem ubíqua. •

•

44


Sinergia com Agile Embora DDD não esteja vinculado a nenhum processo ou framework específico, é notório que seus ideais vão ao encontro do manifesto ágil. Maior interação entre as pessoas, menos documentação e modelagem evolutiva são alguns pontos a mencionar. Vejamos a proximidade entre desenvolvedores e especia listas de negócio. No processo waterfall tradicional, não há colaboração entre eles. Fica a cargo do analista de sistema conversar com o especialista, abstrair e passar as in formações aos desenvolvedores, que simplesmente codif icam. Sobre a modelagem evolutiva: iteração após iteração, o modelo é constantemente refinado, uma vez que o aprendizado sobre o domínio vai progredindo. Em uma abordagem waterfall, toda a modelagem é feita antes da codificação, sendo assim, o analista perde a oportunidade de obter feedback dos desenvolvedores. Porém, vale alertar que, mesmo trabalha ndo com uma metodologia ágil, pode haver falha na obtenção de conhecimento se os desenvolvedores não tiverem interesse em discutir sobre o domínio. Desenvolvedores alheios ao domínio simplesmente obtêm dos especialistas o que o software deve fazer e implementam a funcionalidade sem saber os motivos por trás daquilo. Assim, perde-se a oportunidade de se criar um soft ware mais atrativo e que agregue mais valor para o cliente.

Model-Driven Design Um dos pontos mencionados no início deste artigo sobre modelagem efetiva foi: “ligar o modelo diretamente à implementação”. Em outras palavras, o código deve expressar os detalhes do domínio de forma clara. Isto é impraticável se estivermos utilizando um “modelo de análise” previamente definido e passado aos desenvolvedores. Tal modelo é criado com o propósito de “entendimento do domínio”, sem considerar detalhes de design. E é neste ponto que ele é falho, pois várias descobertas sobre o domínio surgem exatamente no momento do design/implementação. Na prática, se o modelo não expressa conceitos-chave do domínio e se implementá-lo é complicado, ou simplesmente, impossível, os desenvolvedores acabam abandonando o mesmo e criando um modelo próprio. É neste contexto que surge o Model-Driven Design (MDD), uma abordagem de modelagem com o propósito de unir o modelo de análise e o design em um único modelo. Para que seja possível uma correspondência entre o modelo e o design, é necessária a utilização de um paradigma de programação que tenha um bom suporte de ferramentas. Neste ponto, a OOP mostra-se um paradigma maduro, bem con hecido entre a comunidade de desenvolvedores, e que permite a construção de um modelo rico, com objetos representando conceitos do domínio. Outro fator importante para a prática do MDD é que os desenvolvedores devem ser responsáveis pela modelagem do software. Por mais que algumas pessoas do time tenham mais habilidades de codificação e outras de modelagem, é preciso

DDD

que os desenvolvedores estejam envolvidos em algum nível de discussão sobre o modelo e em contato com os especialistas de negócio. Assim como pessoas mais aptas à modelagem devem passar algum tempo codificando. Em outras palavras, modelagem e codificação não devem ser separadas em tarefas distintas. Trabalhando desta forma, é possível transferir conhecimento do domínio e habilidades técnicas dos desenvolvedores mais experientes para outros desenvolvedores, facilitando na criação de softwares coerentes com o domínio, de fácil compreensão e extensão.

Blocos de construção do MDD O MDD é composto por um conjunto de padrões, com o propósito de auxiliar na representação do domínio através do código. Esses padrões formam o alicerce, ou “blocos de construção” do MDD, uma vez que dão sustentação para organ izar o design e melhorar a compreensão do código. O primeiro padrão é a arquitetura em camadas , que é proposta pelo MDD conforme a Figura 2.

Figura 2. Camadas propostas pelo MDD

Cada camada tem uma responsabilidade específica: Interface com Usuário (UI) – responsável por mostrar informações ao usuário, bem como interpretar comandos do usuário. Algumas vezes, o usuário pode ser um sistema externo; Aplicação – responsável por coordenar tarefas, utilizando objetos das camadas inferiores. Trata da conversão de dados, segurança e controle de transações. E serve como uma fachada, expondo dados do domínio para diversos tipos de UI; Domínio – contém todas as informações do domínio. DDD está totalmente focado nesta camada. Como diz Eric Evans, esta camada é o coração do software; Infraestrutura – fornece suporte técnico às camadas superiores, como: log, persistência de dados, autenticação/ autorização, etc. •

•

•

•

De acordo com o tipo e complexidade do projeto, pode haver variações de camadas, como por exemplo, a existência de uma

camada de serviços distribuídos e várias camadas de inf raestrutura. Por outro lado, projetos que possuam apenas u m tipo de UI podem abrir mão da camada de aplicação. No entanto, para permitir a aplicação do MDD, é crucial a existência da camada de domínio. Isolar o domínio traz cla reza sobre o que faz parte dele e o que não faz, e o deixa livre de outras responsabilidades (como exibição e persistência), permitindo que o modelo evolua de forma que capture o conhecimento essencial do negócio. Para expressarmos o modelo no código, o MDD sugere três padrões: Entidades, Objetos de Valor e Serviços. Entidades (Entities) são objetos que possuem uma identidade conceitual dentro da aplicação. Por exemplo, duas transações bancárias de mesmo valor, feitas no mesmo dia, ainda são duas transações distintas, logo possuem identidade e são Entidades. No entanto, para distinguirmos essas duas transações, é necessário que cada uma delas possua um atributo único (ou conjunto de atributos únicos). Este atributo pode surgir do domínio ou ainda ser um ID gerado pela aplicação. Entidades também possuem um ciclo de vida na aplicação. Por exemplo, em um software para uma clínica médica, desejamos acompanhar cada paciente da clínica: cadastrá-lo, atualizar seus dados, registrar as consultas, inativá-lo ou excluí-lo. Objetos de Valor (Value Objects) são objetos que representam algum aspecto do domínio sem nenhuma identidade conceitual. Normalmente, são objetos que dão característica a alguma entidade. Por exemplo, para uma entidade “Carro”, o pneu poderia ser um objeto de valor, caso não houvesse o menor interesse para o domínio em diferenciarmos um pneu de outro. Um objeto de valor normalmente é imutável, ou seja, criamos um objeto de valor com certos atributos e nunca mais alteramos. No exemplo do pneu, caso quiséssemos trocar o pneu do carro, simplesmente criaríamos um pneu novo e colocaríamos no lugar do velho. Serviços (Serv ices) são objetos que realizam alguma operação do domínio que não se aplica a nenhuma entidade ou objeto de valor. Muitas vezes, podem aparecer conceitos do domín io que são meramente ações e não dados. Essas ações utilizam outros objetos do domínio para executar alguma operação de negócio. Tomemos, como exemplo, uma transferência bancária. Ela é uma operação do domínio que utiliza duas contas bancárias e gera duas movimentações (crédito e débito). Um bom serviço não deve possuir estado (ou seja, toda cha mada ao mesmo, dadas as mesmas entradas, deve retornar o mesmo resultado), deve fazer sentido para o domínio (seu nome faz parte da linguagem ubíqua) e seus parâmetros e resultados devem ser objetos do domínio. Outros três padrões sugeridos pelo MDD estão diretamente relacionados ao ciclo de vida dos objetos do domínio. São eles: Agregados, Fábricas e Repositórios. Agregados (Aggregates) são grupos de objetos associados (entidades e objetos de valor), tratados como uma u nidade do ponto de vista de alteração dos dados. Todo agregado possui


45

um limite e uma raiz. O limite define quais objetos estão dentro do agregado. E a raiz é uma entidade que constitui o único ponto de acesso de objetos fora do agregado. Um exemplo de agregado é ilustrado na Figura 3.

de armazenamento (normalmente, um banco de dados). Em se tratando de um agregado, só haverá um repositório para a raiz do mesmo, uma vez que os demais objetos serão obtidos via associação. Repositórios e fábricas se relacionam ao modelo de forma similar, cuidando do ciclo de vida dos objetos. Enquanto uma fábrica cuida da criação de objetos, um repositório cuida de objetos já existentes.

Em busca de um modelo profundo

Figura 3. Exemplo de agregado Carro

Como visto no exemplo, o agregado Carro é composto de duas entidades: Carro e Pneu. Objetos fora do agregado (no exemplo, Cliente) só podem fazer referência à raiz. Além disso, é permitido que objetos dentro do agregado façam referênc ias uns aos outros e também às raízes de outros agregados. Um agregado tem o propósito de garantir a integridade dos dados, por meio de um conjunto de regras – como as ilustra das no exemplo anterior - que simplificam a associação entre objetos. Outras regras importantes de consistência dos dados dizem respeito a operações de exclusão e invariantes. Em uma operação de exclusão, todos os objetos do agregado devem ser excluídos de uma só vez. Quanto às invariantes (regras de consistência que devem ser mantidas sempre que os dados são alterados), ao salvarmos uma alteração em qualquer objeto do agregado, todas as invariantes do agregado devem permanecer atendidas. Para facilitar no entendimento das invariantes, tomemos, por exemplo, um agregado Pedido que contenha duas entidades: Pedido (raiz) e ItemDoPedido. Uma invariante poderia dizer que “a soma de todos os itens do pedido não deve ultrapassar um limite máximo aprovado para o pedido”. Assim, devemos garantir que, sempre que formos salvar o pedido, esta invariante permaneça atendida, mesmo que tenhamos alterado o limite aprovado do pedido ou qualquer um dos itens do pedido. Se o agregado tivesse outros objetos com outras invariantes, todas deveriam estar satisfeitas ao salvar o pedido. Fábricas (Factories) são objetos responsáveis pela criação de objetos. Devem ser utilizadas quando a criação de um objeto de domínio for muito complexa, envolvendo, por exemplo, a criação de um agregado com vários objetos. Repositórios (Repositories) são responsáveis por abstrair o local onde são armazenados os objetos de domínio. Eles apresentam uma forma simples de obter objetos e salvá-los, além de desacoplar o domínio da tecnologia de persistência. Um repositório de clientes, por exemplo, funciona como uma coleção de clientes e permite salvar e recuperar clientes do local

46


Desenvolvedores devem estar constantemente em busca de aprendizado sobre conceitos do domínio, expondo conceitos antes implícitos. Um conceito pode estar implícito na forma de um conjunto de informações vindas de diversos objetos e que aparecem com frequência no software. Deste modo, pode-se concluir, após várias conversas, que essas informações são um conceito importante, transformando-as em um objeto e agregando este conceito à linguagem ubíqua. A busca por um modelo profundo (“deep model”, como de nominado pelo Eric Evans) se dá por meio de muita conversa com os especialistas de negócio, esclarecendo e validando determinados pontos. Pode ser válido também que os desenvolvedores leiam algum livro sobre o negócio em questão, com a finalidade de ganharem maior conhecimento e dialogarem em um nível melhor com os especialistas. Esta evolução para um modelo mais profundo ocorre normalmente após um evento descrito por Evans como breakthrough (o que em uma tradução livre seria algo como uma “impor tante descoberta”). É um momento durante o processo onde os desenvolvedores finalmente percebem ou entendem algum conceito importante, o que leva a uma série de mudanças no design. No entanto, um breakthrough não deve ser algo forçado. Para que surja uma oportunidade para um breakthrough, é preciso focar na exploração do domínio, fazer refinamentos constantes no design e cultivar uma linguagem ubíqua robusta.

Design Estratégico (Strategic Design) É comum que sistemas muito grandes e complexos tentem ser desenvolvidos como um único projeto, utilizando um único modelo. Esse tipo de estratégia é muito arriscado e pode ser totalmente impraticável. Imagine uma classe “Cliente” do modelo. Em determinado contexto, por exemplo no módulo de Cobrança, “Cliente” poderia precisar de certas informações que em outro(s) contexto(s) não fazem sentido. Situações como esta contribuiriam para tornar o modelo muito difícil de entender, uma vez que terí amos desenvolvedores “brigando” para satisfazer as necessidades do contexto em que estão trabalhando, e, em consequência, causando bugs em outras partes do sistema, gerando código duplicado, etc. Dentro deste cenário, o Design Estratégico apresenta uma série de práticas voltadas à modularidade de sistemas gra ndes e à integração entre os módulos (e entre os respectivos times trabalhando neles).

DDD

No Design Estratégico, o conceito de Contexto Delimitado (Bounded Context) é o mais importante. Um contexto define uma fronteira clara de um modelo. Ao explicitarmos todos os contextos, cada time pode trabalhar em seu modelo de forma isolada, mantendo sua própria linguagem ubíqua, sem se preocupar com o que está fora de seu contexto. Em um sistema muito grande, certamente teremos mais de um contexto compondo o mesmo, com um time de desenvolvedores responsável por cada contexto. Para facilitar a visualização do sistema como um todo, podemos fazer uso de um Mapa de Contextos (Context Map) , como o apresentado na Figura 4.

Figura 4. Mapa de Contextos

Por meio do mapa de contextos, temos uma visão dos vários contextos do sistema e quais são os pontos de acesso de cada um deles. Para que todos os contextos sejam integrados com eficiência, ou seja, preservando a integridade de seus respectivos modelos, o Design Estratégico apresenta alguns padrões, descritos a seguir. O Núcleo Compartilhado (Shared Kernel) é uma forma de relacionamento entre contextos onde dois ou mais times definem um subconjunto do modelo onde irão trabalhar juntos. É mais aplicável quando há muita necessidade de comunicação entre os times, pois seus contextos possuem muitas similaridades. Com isso, reduz-se muito a duplicação de código. O núcleo compartilhado não deve ser alterado sem comum acordo entre os times. Técnicas como integração contínua e testes automatizados garantem a integr idade do núcleo. O padrão Cliente/Fornecedor (Customer/Supplier) se aplica quando claramente temos um contexto que “alimenta” outro. Um time faz o papel de cliente, solicitando tarefas para o time fornecedor. É comum que nesta situação tenhamos contextos implementados com diferentes tecnologias, tornando inviável o uso de um núcleo compartilhado. A necessidade de comunicação entre os times, assim como no núcleo compartilhado, é grande, com reuniões constantes para se definir o que poderá ser entregue pelo fornecedor e quando. Em alguns casos, a comunicação entre dois times pode ser muito difícil, mesmo que façam parte da mesma empresa. Isso

pode ocorrer por vários fatores: mudança de foco de mercado por parte de um dos times, times pertencentes a hierarquias diferentes dentro da empresa, etc. Quando não há motivação para um time atender as necessidades do outro, este fica de “mãos atadas”. Neste caso, há três caminhos a seguir. Um deles é adotar o padrão Conformista (Conformist). Ele é seguido quando o modelo do time upstream é de qualidade razoável e o time downstream ainda consegue algum tipo de ajuda, por menor que seja. O padrão Conformista assemelha-se ao Núcleo Compartilhado, uma vez que há uma área compartilhada entre ambos os times. Porém as semelhanças param por aí. No Núcleo Compartilhado, há muita colaboração entre os times, enquanto no Conformista, um dos times apenas aceita o modelo vindo do outro time, que não possui muito interesse em colaborar. Outro caminho a ser seguido é a adoção do padrão Camada Anti-Corrupção (Anti-corruption Layer). Neste cenário, ainda há o interesse de se utilizar o contexto do outro time, porém a qualidade do código é muito ruim e fora dos padrões do time downstream. Sendo assim, para não contaminar o contexto do mesmo, é criada uma camada intermediária, responsável pela tradução das informações de um contexto para outro. Há ocasiões mais extremas onde integrar simplesmente é inviável. Sendo assim, adota-se o padrão Caminhos Separados (Separated Ways). Nele, um time trabalha isoladamente em seu contexto, sem integração qualquer com outros contextos. Retornando aos relacionamentos mais cooperativos, imagine um contexto que precise se integrar a diversos outros sistemas. Tais sistemas precisam consumir informações do contexto e podem estar dentro do próprio time, com outro time da empresa ou até mesmo fora da empresa. Neste caso, adota-se o padrão Serviço de Host Aberto (Open Host Service) , expondo um conjunto de serviços que podem ser consumidos por vários clientes. Por fim, pode ser útil publicar, ou seja, formalizar um Open Host Service por meio de uma Linguagem Publicada (Published Language) , para que os consumidores do serviço conheçam todas as suas operações e saibam como executá-las (como feito hoje em dia por vários fornecedores, como Google, Twitter e Amazon).

Conclusão Domain-Driven Design apresenta uma série de conceitos e padrões com o intuito de direcionar o desenvolvimento do software para o que há de mais importante nele: o domínio. Seguindo essa abordagem, somos capazes de desenvolver software mais coerente com a área de negócio em questão, software de mais valor para o cliente e que possa ser expandido com maior facilidade. DDD apresenta vários outros conceitos não contidos neste artigo. Para um melhor entendimento e maior aprofundamento no assunto, é altamente recomendada a leitura do livro de Eric Evans, “Domain-Driven Design – Tackling Complexity in the Heart of Software”, que deu origem ao DDD. Para que o DDD seja utilizado de forma efetiva, não basta a aplicação de um ou outro padrão. São obrigatórios: a


47

comunicação constante entre desenvolvedores e especialistas de negócio, cultivando uma linguagem ubíqua; e o desenvolvimento iterativo, para que o modelo possa ir evoluindo ao longo do projeto.

Links

Evans,E.Domain-Driven Design:Tackling Complexity in the Heart of Software.Addison Wesley,2004. Domain Language – Empresa de Eric Evans. www.domainlanguage.com



u

e s ê

Domain-Driven Design Community.

F eedb a c k

www.domaindrivendesign.org

D

o

s

b

r

e

e

s

o ç

t a e


48


Domain-DrivenDesign Quickly(mini-bookInfoQ). www.infoq.com/minibooks/domain-driven-design-quickly

Artigos, Palestras e Entrevistas com Eric Evans (InfoQ). www.infoq.com/author/Eric-Evans

Arquitetura e Desenvolvimento Nesta seção você encontra artigos voltados para diferentes abordagens de apoio ao desenvolvimento de projetos de software

Boas práticas para escrita de métodos, funções e procedimentos – Parte 7 Tornando limpa a visão macro do sistema

Jacimar Fernandes Tavares

De que se trata o artigo?

Resumo?

Aborda o tema Código Limpo com o objetivo de mostrar como o desenvolvedor pode usá-lo para melhorar a qualidade do código-fonte de suas aplicações. Neste sentido, este artigo provê conhecimento ao desenvolvedor sobre como transformar códigos considerados ruins em bons códigos demonstrando, através de exemplos práticos, as teorias abordadas.

Esta série de artigos tem discutido os aspectos que permeiam o assunto Código Limpo, seguindo a linha de raciocínio que propõe um aumento na qualidade do código das aplicações existentes ou proporcionar conhecimento de como criar projetos de código melhores quando se está iniciando um novo projeto. Neste contexto, código limpo se refere a um conjunto de características desejáveis de serem encontradas no código de nossa aplicação. Algumas dessas características são: ter um código que atenda os requisitos de eficiência, lógica do negócio bem modelada e definida em forma de código fonte, mecanismos de tratamento de erro bem definidos e código que não dê margem à necessidade da realização de novas otimizações.

[email protected]

Pós Graduando em Gestão de Projetos de TI – Universidade Federal de Juiz de Fora UFJF Bacharel em Ciência da Computação FAGOC - Faculdade Governador Ozanam Coelho, Atua como administrador financeiro na empresa Transporte JR.

Em que situação o tema é útil? O tema se torna fundamental para desenvolvedores que buscam cada vez mais melhorar suas aplicações ao focar em qualidade de código. Essa tarefa será possível graças ao conhecimento adquirido sobre limpeza de código.

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 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 e da Faculdade Metodista Granbery, Analista de Sistemas da Prefeitura de Juiz de Fora, Editor da Engenharia de Software Magazine.

A

té este momento, a série de artigos sobre código limpo abordou importantes teorias que envolvem a construção ou modificação do projeto de código existente com o objetivo de ter estruturas de código cada vez mais limpas. No primeiro artigo da série foi abordado o tema nomes significativos, com ob jetivo de auxiliar e expor as teorias que serão úteis para a concepção de nomes

que refletem o objetivo de variáveis e objetos. No segundo artigo, o tema funções foi abordado, provendo ao desenvolvedor importantes informações sobre como definir métodos, procedimentos e funções limpos. Além disso, também foi abordado como o desenvolvedor pode implementar tais estruturas seguindo alguns parâmetros que permitirão que suas estruturas reflitam melhor seus propósitos.


49

No terceiro artigo da série foi tratado o assu nto comentários em código fonte. O que acontece é que alguns desenvolvedores desconhecem as boas praticas que devem ser seguidas pa ra a concepção de um comentário, o que leva a criação desses de forma descontrolada, fazendo com que ao invés de se obter benefícios, os comentários agreguem valor negativo ao código. Quando o assunto foi formatação de código, o quarto artigo da série mostrou como essa tarefa pode ser realizada seguindo as recomendações de Código Limpo. Já no quinto artigo da série passou-se a se preocupar com estruturas de dados e objetos. Nesse momento foram abordadas as técnicas para se construir estruturas de dados e instanciar objetos que podem ser considerados limpos. O sexto artigo expôs o tema limites da aplicação, isto é, como manter limpo o código que está nos limites da aplicação, seja de componentes de terceiros ou sobre a comunicação com um recurso externo à aplicação. Nesse mesmo artigo, outro ponto muito interessante foi considerado: como manter o código de teste da aplicação limpo? Além de abordar a importância do código de teste, foi mostrado como mantê-lo em algum repositório sem que esse código perca sua legibilidade. Para isso, técnicas de limpeza de código de teste unitário foram mostradas. É chegado o momento de conhecer o conteúdo do último artigo desta série, que irá tratar da visão macro da aplicação. Primeiramente serão apresentadas técnicas e teorias fundamentais para a concepção de classes limpas. Isso envolve conhecer o tamanho que as classes devem possuir, responsabilidades, como é a relação dela com a aplicação, dentre outras coisas. Na continuação deste artigo será discutido como implementar sistemas que podem ser mais facilmente entendidos se analisados em uma visão macro. Esta seção apresentará formas de se dividir o sistema em partes que, se analisadas, revelam a organização do sistema e de que partes ele é constituído. Finalizando, tem-se a seção Emergência que tratará de teorias acerca da concepção de projetos de código considerados simples. Muitos desenvolvedores implementam alguns projetos, mas não sabem classificar se o projeto implementado é simples ou complexo, analisando sob ponto de vista das manutenções futuras. Sistemas com projeto de código mais simples tendem a ser mais fáceis de manter, enquanto sistemas com estruturas de código com muita duplicação, por exemplo, tendem a dificultar o processo de manutenção. Todos estes pontos serão discutidos nas seções deste artigo.

Classes Esta seção aborda as características fundamentais para que uma classe possa ser considerada limpa. Implementar classes limpas é um processo que passa por conceitos importantes que vão desde a necessidade de se definir nomes que condizem com o que elas representam até definições do posicionamento dos atributos na classe relacionados por seus tipos. Definindo a estrutura de uma classe

Segundo Código Limpo (MARTIN, 2009), uma classe deve ser organizada de forma que, após a declaração da classe, venham os

50

atributos, nesta ordem: públicos, estáticos, constantes, privados e, por último, os atributos privados que são instâncias de outras classes, criados para permitir a associação entre classes. Código Limpo sugere que não sejam criados métodos de acesso, os gets e sets por entender que não são a melhor opção para acessar atributos de uma classe. Sendo assim, outros mecanismos devem ser criados para substituir os métodos de acesso (ver Nota do DevMan 1).

Nota do DevMan 1 Como definir objetos, estruturas de dados e mecanismos de tratamento de erros segundo código limpo O artigo Como definir objetos, estruturas de dados e mecanismos de tratamento de erros segundo código limpo, foi apresentado na edição de número 43 da Engenharia de Software Magazine. Nele é possível aprender como são implementados mecanismos que substituem os métodos de acesso.

Quando surgir a necessidade de se testar um método que é privado, deve-se fazer com que a classe de teste herde da classe que possui o método a ser testado. O método a ser testado deve ter seu atributo modificado, de privado para protegido. Sendo assim, o método ainda continuará invisível fora da classe, mas com a diferença de poder ser acessado pela classe de testes. Alguns desenvolvedores, ao implementarem casos de teste, para acessarem um método, alteram seus modificadores de acesso para públicos, o que não é recomendado. Um exemplo de mudança de modificador de acesso para público foi utilizado no artigo sobre Testes Unitários com NUnit (ver Nota do DevMan 2), mas deve-se considerar as recomendações de Código Limpo (MARTIN, 2009).

Nota do DevMan 2 Artigo sobre Teste Unitário com NUnit. Artigo Teste Unitário com NUnit: uma abordagem prática, foi apresentado na ediçã o de número 43 da Engenharia de Software Magazine.

Definindo o tamanho de uma classe

A sugestão é que uma classe deva ser o menor possível, no sentido da quantidade de responsabilidades que possui. Classes devem ser bem definidas, com propósito único. Não se deve criar uma classe que resolva todos os problemas da aplicação. Um exemplo é a criação de uma classe que funciona como um arquivo de código fonte, criada para receber todos os métodos que a aplicação deve possuir. Estratégias semelhantes eram muito utilizadas por desenvolvedores no paradigma estruturado. No paradigma orientado a objetos, deve-se ter classes com nomes precisos, isto é, que revelem claramente a intenção da classe. Definido um nome, a classe deve se limitar a possuir apenas código que seja do mesmo

Engenharia de Software Magazine - Boas práticas para escrita de métodos, funções e procedimentos – Parte 7

ESCRITA DE CÓDIGOS

contexto que o nome definido para a classe. Isso, na prática, quer dizer que uma classe com nome Aluno não poderá ter métodos referentes a professores. Tais métodos devem estar em uma classe com nome Professor. A distribuição correta das responsabilidades é o primeiro passo para se obter uma c lasse de tamanho considerado bom. Um importante conceito e que deve sempre ser lembrado e aplicado refere-se à coesão e ao acoplamento. Para cada classe desenvolvida em um sistema deve-se c uidar para que não desempenhe mais funções do que naturalmente deve desempenhar. É interessante que cada classe desempenhe apenas suas funções e não carregue funcionalidades que deveriam ser atribuídas a outros módulos ou classes do software. A esse problema dá-se o nome de baixa coesão, que indica que algo deveria ser feito para melhorar o projeto de código existente. A alta coesão é uma meta a ser alcançada em todos os softwares, pois indica que os módulos ou classes do sistema estão desempenhando apenas as suas respectivas funcionalidades. Portanto, conhecer os tipos de coesão existentes se torna fundamental. Os tipos de coesão conhecidos são: • Coesão funcional: o mais alto nível de coesão. Neste ponto o software realiza apenas a função que é de sua responsabilidade; • Coesão em camadas: encontrada nas camadas do sistema, onde as camadas mais altas se comunicam com as mais baixas, e nunca o contrário; • Coesão comunicacional: onde a comunicação do sistema ocorre quando várias partes do código manipulam os mesmos dados; • Coesão sequencial: ocorre quando há uma sequência de operações, onde uma invoca e passa dados para a outra. A saída de uma operação é a entrada de outra; • Coesão procedural: ocorre quando há uma sequência de operações onde, por exemplo, um método chama outro, mas não há passagem de dados; • Coesão temporal: está presente em código que executa em determinadas situações atípicas. Como exemplo, podese destacar código criado para levantamento de exceções e detecção de erros; • Coesão de utilidade: presente em classes, componentes ou operações que contêm mais responsabilidades que normalmente deveriam ter. Como exemplo, pode-se destacar uma classe que carrega código que deveria estar presente em outra classe. A criação de classes em um sistema que reflitam a necessidade do negócio do cliente é um dos recursos que o desenvolvedor pode utilizar ao projetar um sistema. Quando se escreve uma classe, possivelmente essa se comunicará com outra classe do software. A comunicação entre módulos, classes, métodos ou componentes é comum em um projeto orientado a objetos mas, se esta comunicação for complicada demais, ao ponto de que mudanças em uma classe gerem diversos impactos em outras, possivelmente o desenvolvedor terá problemas em manter esse código, pois o acoplamento entre essas classes, ou seja, a ligação entre elas, pode comprometer o sucesso das mudanças.

O alto acoplamento refere-se à intensidade da comunicação entre classes, métodos ou componentes do sistema. Alto acoplamento pode indicar que a comunicação pode ser um pouco complexa, e que possivelmente o desenvolvedor terá que ter cuidados extras na hora de manter o código, levando em conta o fato de que as alterações feitas em um determinado ponto podem impactar outros pontos do software. É inevitável que haja algum tipo de acoplamento em um software, mas o desenvolvedor deve estar ciente da importância de manter o acoplamento o mais baixo que puder, pois assim os impactos ocasionados pelas mudanças no software poderão ser minimizados. Alguns tipos de acoplamento foram definidos, para que o desenvolvedor possa identificar quais tipos estão presentes no software, e assim possa minimizar o acoplamento (PRESSMAN, 2006). Entre eles tem-se: • Acoplamento por conteúdo: é encontrado em código que modifica os dados de outra parte do código. Como exemplo, tem-se um componente que modifica os dados internos de outro componente em tempo de execução; • Acoplamento comum: encontra-se em código onde há variáveis globais sendo usadas por todo o sistema. Nesse caso, a modificação dessa variável pode afetar várias partes da aplicação; • Acoplamento por controle: esse tipo de acoplamento pode ser encontrado em métodos. Quando o corpo de um método é modificado, pode haver a necessidade de alterar o corpo de outro método que tem a responsabilidade de trocar informações com ele; • Acoplamento carimbado: nesse caso, quando há uma dependência entre classes, do tipo que as informações necessárias a uma classe dependem das informações vindas de outra classe, o sistema torna-se mais difícil manter dado que alterações na classe fornecedora de dados deverá ser planejada para que não afete a classe que irá receber os dados. • Acoplamento por dados: encontrado em código que manipula vários parâmetros de uma só vez. Nesse caso, a complexidade do código aumenta consideravelmente devido à manipulação de grandes quantidades de dados; • Acoplamento por chamada de rotinas: tipo de acoplamento normalmente encontrado em métodos que chamam outros métodos; • Acoplamento por uso de tipo: um tipo de dados definido por uma classe pode ser usado por outras, mas se esse modificar-se, as classes que o usam possivelmente deverão ser modificadas; • Acoplamento por inclusão: encontrado em código que faz importação de conteúdo de outras partes do sistema; • Acoplamento externo: tipo de acoplamento encontrado quando o sistema estabelece um tipo de comunicação com o ambiente externo à aplicação, como comunicação com sistema operacional, banco de dados, entre outros. É responsabilidade do desenvolvedor manter a qualidade do código que cria, e esta tarefa necessita do entendimento sobre as teorias de coesão e acoplamento. Para reduzir o tamanho de uma classe, o ideal é dividi-la em outras classes, por quantidade


51

de responsabilidades, e então mover da classe grande o código que deverá pertencer às classes recém-criadas. É fato que a maioria dos sistemas tende a ter seu código modificado e aumentado ao longo do ciclo de vida da aplicação. Isso, na prática, quer dizer que as classes serão afetadas, e manter uma única responsabilidade por classe é uma tarefa contínua.

Sistemas As seções anteriores visam manter limpas partes de um sistema, mas ter o sistema limpo como um todo, numa visão geral, também é importante, pois as partes devem coexistir em harmonia no sistema. Esta seção visa abordar as teorias que possibilitarão que um sistema como um todo se torne limpo, ao passo que suas divisões estiverem claras, como por exemplo, a conexão com o banco não deve estar misturada ao código responsável por instanciar os objetos das classes de negócio, nem o código de tratamento de erros misturado ao código de persistência de objetos. Um sistema considerado limpo pode ser visto como um todo, mas tendo suas partes bem defi nidas e visíveis em suas divisões. Visão geral sobre a estrutura de um sistema

Nesse ponto do aperfeiçoamento do código de um sistema, além das boas práticas descritas para se obter código limpo, deve-se se preocupar também com uma visão do sistema que vai além da qualidade das linhas de código escritas. Deve-se se preocupar também com a forma com que o sistema está organizado e como suas partes estão dispostas a fim de se relacionar. Nesse sentido, a preocupação deve girar em torno da separação de trechos de código de construção de objetos, trechos de código responsável pelas regras de negócio, trechos de código relativo a configurações do próprio sistema, entre outros pontos. Uma analogia que se pode fazer nesse momento é referente a uma linha de produção de uma fábrica. Nela pode-se observar claramente que no início da produção tem-se a matéria prima, como madeira por exemplo. Nesse ponto existe o setor de corte, responsável por criar as partes necessárias para a concepção de um produto. Essas partes criadas vão para outro setor que é o responsável pela pintura das peças. Ao sair do setor de pintura, as peças vão para o setor de embalagem, que pega um conjunto de peças específicas e as embala, constituindo um produto. O setor de carregamento é responsável por despachar estes produtos para seus respectivos destinos. Neste cenário é fácil perceber que a fábrica é o todo, assim como o software e os setores são partes do sistema, como módulos ou conjunto de classes de objetivos específicos. Cada setor da indústria é responsável por uma parte da geração do produto desejado, assim como no software também deve ocorrer. Para que essa divisão clara e objetiva, assim como na indústria, também ocorra no software, é necessário seguir alguns princípios. O ponto de partida usado para iniciar operações em um software é o método main. Através dele alguns procedimentos são invocados e tais procedimentos podem encadear a execução de vários outros procedimentos. É interessante que a ordem de chamada dos procedimentos pelo método main seja feita de

52

uma forma que apresente uma sequência de leitura, onde quem for ler o código posteriormente saiba simplesmente identificar qual o ponto de partida da inicialização do software bem como os caminhos por onde ele passa. Se após a inicialização do método main houver a necessidade de executar métodos que são responsáveis por construir algum objeto ou formar algum tipo de informação referente ao negócio modelado pela aplicação, é fundamental que esse código não esteja misturado a códigos que são responsáveis por prover algum tipo de serviço para o software, como abrir conexões com bancos de dados ou testar se algum dispositivo está conectado ao computador, por exemplo. Prevendo o futuro do software

Alguns desenvolvedores insistem em criar grandes arquiteturas para um sistema que é pequeno, mas o fazem com o intuito de preparar o projeto para futuras funcionalidades que ele acredita que podem um dia vir fazer parte do sistema, mas que não se tem certeza ainda. Esse é um problema que atinge alguns projetos de software e que não devia acontecer. Quando se implementa algo pensando em funcionalidades que não se tem certeza que um dia existirão, se gasta muito tempo, e com isso dinheiro, aumentando o custo do projeto. Em contrapart ida, se uma nova funcionalidade será em breve inserida e se faz um projeto que, para acomodar a nova funcionalidade, deverá sofrer grandes modificações, também se corre o risco de ter um aumento no custo do projeto. Mas então o que fazer? Implementar pensan do no futuro ou desconsiderar o que está por vir. A resposta está no meio termo. É importante que o desenvolvedor escreva código sempre visando a qualidade da escrita, seguindo os princípios de Código Limpo. Nesse sentido, ele deverá trabalhar com as informações que tem em mãos e criar a arquitetura com base no que se tem de concreto no que diz respeito à especificação dos requisitos. Uma vez implementada a arquitetura do sistema visando sempre aplicar as boas práticas de código limpo, quando houver a necessidade de implementar novas funcionalidades o sistema tenderá a ser mais fácil de modificar, visto que o código estará mais legível. Visão macro do sistema

É importante que quem estiver analisando um software implementado por outro desenvolvedor consiga facilmente ter uma visão macro sobre como é a divisão do sistema (lembrando-se da analogia com a indústria, onde as seções são facilmente identificadas, cada uma com propósito específico). Nesse sentido, deve-se fornecer uma visão macro sobre as classes que implementam persistência de objetos (mapeamento objeto-relacional), o mecanismo que trata os erros da aplicação, o mecanismo que abre as conexões com o banco de dados, as classes que instanciam objetos para o negócio modelado na aplicação, os mecanismos que configuram os formulários da aplicação como, por exemplo, determinar quando um botão deve estar habilitado ou não, cores de algum componente devem ser alteradas, entre outras coisas. Fornecer essa visão faz

Engenharia de Software Magazine - Boas práticas para escrita de métodos, funções e procedimentos – Parte 7

ESCRITA DE CÓDIGOS

com que o sistema na visão macro seja limpo. Não adianta somente se preocupar com a qualidade do código implementado, isto é, implementar todas as teorias descritas nos artigos passados desta série, se a visão macro do sistema ainda estiver confusa. Um ponto importante ao se limpar o código para se ter uma visão macro do sistema bem definida está no quesito reaproveitamento de código. Quando se tem uma divisão dos mecanismos que compõem uma aplicação, como os descritos anteriormente, pode-se ter um reaproveitamento de partes do sistema de modo mais simples. Pode-se, por exemplo, usar o mesmo mecanismo de conexão ao banco de dados em diversas aplicações que se está desenvolvendo. Isso reduziria o custo de ter que implementar o mesmo mecanismo todas as vezes que um novo software for concebido. Outro recurso importante que pode ser usado para contribuir na formação da visão macro é a utilização de padrões de projeto, que permitem uma visualização rápida do que se trata um trecho de código caso a pessoa que o esteja analisando entenda de padrões de projeto também.

Emergência Esta seção visa abordar teorias e regras que podem ser utilizadas no processo de tornar o código fonte existente limpo ou conceber novos projetos cujo código fonte possa ser considerado limpo. As teorias e regras desta seção mostrarão informações de como o desenvolvedor poderá conciliar as teorias abordadas nas seções anteriores com o objetivo de facilitar a concepção de novos projetos. Considerando as regras básicas desta seção, pode-se obter um software limpo desde a sua criação. Características de um projeto simples

Código Limpo (MARTIN, 2009) se baseia nas teorias de outros autores para afirmar que um projeto é considerado simples quando baseado em quatro pilares, que são: está totalmente testado, não possui duplicação de código, reflete o objetivo do programador ao escrever aquele código, e possui um número mínimo quanto possível de classes e métodos, seguindo essa ordem. A primeira dessas características leva a crer que um software que não foi testado devidamente não pode ser considerado simples, visto que se não se testou, não se sabe bem os efeitos da execução daquele código em todos os seus pontos e caminhos. Implementar uma solução já pensando que o método deverá ser passível de teste é uma boa prática. Outra abordagem sugere até que o teste seja escrito antes do método a ser testado. A segunda característica leva a uma reflexão. O que pode ser considerado código duplicado? Código duplicado é somente o código copiado e colado em outro ponto do software? Como identificar um código duplicado? Como eliminar um código duplicado sem afetar as outras partes do sistema? A resposta para todas estas perguntas está nos demais artigos que foram escritos sobre código limpo e nos artigos escritos sobre refatoração de código. O objetivo aqui é frisar a importância de se ter um código sem duplicações: é torná-lo simples. Caso o projeto tenha código duplicado, ele não pode ser considerado simples, visto que uma alteração em um ponto poderá causar efeitos colaterais em outro ponto duplicado, ou até mesmo a manutenção

programada ser efetuada em um trecho de código que não é o que se deve manter, dada a semelhança que possui. A terceira característica gira em torno de outro ponto conhecido pela maioria dos desenvolvedores, mas que às vezes não é colocado em prática, a questão da escrita do código e sua análise posterior. Quando se está escrevendo um código, se possui conhecimento sobre o que se quer expressar em forma de código, mas nem sempre quem está analisando o código pela primeira vez saberá distinguir do que se trata. Isso ocorre porque, com o tempo, tende-se a esquecer do que se trata o trecho de código implementado. Portanto, escrevê-lo o mais legível possível, em sequência de leitura, é o indicado. O último ponto, porém importante, deve ser analisado atentamente. Ter um sistema com muitas classes não é sinal de que o projeto está simples. Pode ser que o desenvolvedor quebrou demais o problema e acabou dividindo responsabilidades que deveriam estar em uma única classe. Porém, existe outro cenário onde existem poucas classes, mas as que existem são grandes e complexas de se entender e manter. Isso ocorre por que alguns desenvolvedores atribuem mais responsabilidades a uma classe do que deveria. Sendo assim, um sistema só poderá ser considerado limpo se as classes e métodos tiverem o tamanho necessário. Nem maiores nem menores do que devem ser. Seguir estas recomendações garantirá a concepção de um projeto considerado simples.

Conclusão Até este ponto, a série sobre código limpo preocupou-s e em tornar limpas pequenas partes da aplicação, como nomes, métodos, objetos, estruturas de dados, limites e os métodos de teste. Este artigo trouxe a mesma forma de se limpar códigos, que vinha sendo utilizada nos artigos anteriores, mas desta vez em partes maiores do sistema, com uma visão macro. Com a teoria e prática sobre como limpar código abordadas em outros artigos, o desenvolvedor se torna capaz de manter limpo pequenos trechos de código, e com o conhecimento adquirido neste artigo, o desenvolvedor teve contato com uma forma de considerar em conjunto todo conhecimento sobre limpeza de código e utilizá-lo numa visão maior. Esta série de artigos sobre código limpo finaliza aqui. Quem leu todos os artigos percebeu que há uma forma de se esc rever código com qualidade, evitando problemas futuros. Assim, apresentamos uma base de referência para melhorar o projeto de código de suas aplicações e cada vez mais levar produtos de qualidade ao mercado. Provavelmente seu cliente não verá a qualidade do seu código, mas certamente ela trará outros tipos de benefícios para ele. Dê seu feedback sobre esta edição!


u

e s ê

F eedb a c k

D

o

s

b

r

e

o ç

e s t a e



53

Engenharia de Software - Edição 45

Recommend Documents