engenharia de software - pontos de função

54
magazine engenharia de software Edição 44 - Ano 04 Modelos de processo pessoal http://www.devmedia.com.br/post-23264-Modelos-de-processo-pessoal.html Desenvolvimento Desenvolvimento de aplicações de realidade aumentada Processo Uma visão geral do CMMI Requisitos Gerenciando mudanças a partir de requisitos Agilidade Requisitos para alcançar agilidade Processo Conheça os modelos de processo pessoal Desenvolvimento Conheça técnicas para manter seu código “limpo” – Parte 6 Agilidade Scrum e o gerenciamento de projetos - Parte 3 Aprimore suas estimativas de tamanho de projeto

Upload: carlos-antonio-castro-oliveira

Post on 16-Nov-2014

2.619 views

Category:

Technology


9 download

DESCRIPTION

 

TRANSCRIPT

Page 1: Engenharia de Software - Pontos de função

mag

azin

eengenhariade software

Edição 44 - Ano 04

Modelos de processo pessoalhttp://www.devmedia.com.br/post-23264-Modelos-de-processo-pessoal.html

DesenvolvimentoDesenvolvimento de aplicações de realidade aumentada

ProcessoUma visão geral

do CMMI

RequisitosGerenciando mudanças

a partir de requisitos

AgilidadeRequisitos para

alcançar agilidade

ProcessoConheça os modelos de processo pessoal

DesenvolvimentoConheça técnicas para manter seu código “limpo” – Parte 6

AgilidadeScrum e o gerenciamento

de projetos - Parte 3

Aprimore suas estimativas de tamanho de projeto

Page 2: Engenharia de Software - Pontos de função
Page 3: Engenharia de Software - Pontos de função

Corpo Editorial

EditorRodrigo Oliveira Spínola

ColaboradoresMarco Antônio Pereira Araújo Eduardo Oliveira Spínola

Jornalista ResponsávelKaline Dolabella - JP24185

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

Ano 4 - 44ª Edição - 2012

Na fase inicial de um projeto, a necessidade em obter o custo, prazo e o

esforço é observado em todas as empresas, pois as mesmas precisam

gerar um orçamento para os seus clientes e avaliar uma série de

projeções.

Inicialmente não se tem conhecimento de todas as características do produto

bem como da sua real dimensão, por esse motivo é necessário utilizar técnicas

de extração de requisitos para realizar um levantamento inicial dos mesmos e

compreender melhor o problema. Os requisitos são condições, características

ou capacidades necessárias para atingir uma finalidade, categorizados na

implementação de sistemas em funcionais e não funcionais como forma de

estabelecer critérios de qualidade.

Uma vez definidos os requisitos, pode-se então avaliar o tamanho do sistema

em termos de suas funcionalidades. Existem vários métodos de estimativa, a

APF (Análise de Ponto de Função) é uma delas. Esse método não tem como

objetivo realizar estimativas de prazo, custo e esforço para implementação

de sistema, mas sim avaliar o tamanho de um sistema em termos de suas

funcionalidades. Resulta desta avaliação o tamanho funcional do sistema

expresso em Pontos de Função (unidade de medida do método). A partir do

tamanho funcional, podem ser derivadas estimativas adicionais, como tempo

e custo.

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

como tema de capa Análise de Ponto de Função. Para isto, trazemos um artigo

cujo objetivo é apresentar de forma simples, por meio de exemplos, o uso de

um método poderoso para a solução destes problemas recorrentes, a APF

(Análise de Ponto de Função).

Além deste artigo, teremos mais sete nesta edição:

• Requisitos para agilidade no desenvolvimento de software

• Scrum e o gerenciamento de projetos – Parte 3

• Modelos de processo pessoal

• CMMI – Uma visão Geral

• Gerenciando mudanças a partir de requisitos

• Introdução ao desenvolvimento de aplicações de realidade aumentada

• Boas práticas para escrita de métodos, funções e procedimentos – Parte 6

Equipe Editorial Engenharia de Software Magazine

Rodrigo Oliveira Spínola [email protected] em Engenharia de Sistemas e Computação (COPPE/UFRJ). Mestre em Engenharia de

Software (COPPE/UFRJ, 2004). Bacharel em Ciências da Computação (UNIFACS, 2001). Colaborador

da Kali Software (www.kalisoftware.com), tendo ministrado cursos na área de Qualidade de Pro-

dutos e Processos de Software, Requisitos e Desenvolvimento Orientado a Objetos. Consultor para

implementação do MPS.BR. Atua como Gerente de Projeto e Analista de Requisitos em projetos de

consultoria na COPPE/UFRJ. É Colaborador da Engenharia de Software Magazine.

Marco Antônio Pereira Araú[email protected] 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 Ba-

charelado 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.

Eduardo Oliveira Spí[email protected]É Colaborador das revistas Engenharia de Software Magazine, Java Magazine e SQL Magazine. É ba-

charel 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).

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) 2220-5338

Publicidade

Para informações sobre veiculação de anúncio na revista ou no site entre em

contato com:

[email protected]

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.

EDITORIAL

Apoio

Page 4: Engenharia de Software - Pontos de função

ÍNDICE

Agilidade

06 - Requisitos para agilidade no desenvolvimento de software

Flavio S. Mariotti

13 - Scrum e o gerenciamento de projetos – Parte 3Fábio Cruz

Engenharia Aplicada

20 - Estimativas de tamanho em projetos de software utilizando pontos de funçãoJhoney da Silva Lopes e José Luis Braga

Engenharia Fundamentos

32 - CMMI – Uma visão GeralLenildo Morais

36 - Gerenciando mudanças a partir de requisitosJosé Alberto Zimermann, Thiago Carvalho de Sousa e Rodrigo Oliveira Spínola

Arquitetura e Desenvolvimento

42 - Introdução ao desenvolvimento de aplicações de realidade aumentadaAndré Luis Tosato, Victor Angelo Marcorin, Thiago Salhab Alves e Paulo Barreto da Silva

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

Page 5: Engenharia de Software - Pontos de função

Edição 05 - Engenharia de Software Magazine 5

Page 6: Engenharia de Software - Pontos de função

6 Engenharia de Software Magazine - Requisitos para agilidade no desenvolvimento de software

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.

De que se trata o artigo?Este artigo apresenta uma proposta sobre níveis de requisitos ágeis, práticas correspondentes aos papéis sugeridos e um modelo organizacional que proporciona um formato de empresa ágil. O objetivo é escrever os requisitos que se fazem necessários para a criação de uma equipe ágil, programas que ofereçam suporte ao primeiro nível e a fase e maturidade da empresa ágil.

Em que situação o tema é útil?Na última década, a criação de modelos de engenharia de software cada vez mais ágeis foi a mudança mais significativa que afetou as empresas de software desde o advento do modelo em cascata na década de 1970. Nos últimos cincos anos, as metodologias ágeis começaram a se espalhar nas empresas de software. As iniciativas geralmente começaram com equipes

individuais, com a adoção de alguns métodos como XP, Scrum, Lean entre outros. No entanto, esses métodos começaram a se espalhar para o nível das empresas e uma série de fatores começaram a exigir um escopo organizacional mais amplo para suportar os desafios da governança desses novos processos. Neste sentido, o objetivo do artigo é fornecer um modelo que ajude a obter uma visão elevada do conceito ágil e seus requisitos para maturidade de uma empresa ágil.

Resumo DevManEste artigo discute o tema requisitos para agilidade no desenvolvimento de software. Para isso, será apresentado, sob diferentes perspectivas, como a questão da agilidade pode ser considerada em equipes de projetos de software que trabalhem considerando os princípios da agilidade.

Requisitos para agilidade no desenvolvimento de softwareNecessidades requeridas para equipe, programas e empresa

O desenvolvimento de software se tornou um dos fatores mais importantes da tecnologia.

O software que é produzido hoje se tor-na rapidamente um item fundamental para organizações e usuários finais no intuito de acelerar e auxiliar a execução de diferentes tarefas.

Nos últimos 50 anos diferentes grupos, especialistas e pesquisadores da área de

TI, vêm disponibilizando diversas meto-dologias para apoiar essa difícil tarefa de desenvolvimento de software, tais como: modelo cascata, espiral, RAD, RUP, Crystal, Scrum (ler Nota Devman 1), XP (ler Nota Devman 2), FDD (ler Nota Devman 3), Lean, DSDM entre outros.

Com a evolução rápida dos recursos computacionais, o escopo do software se altera com a mesma velocidade, exigindo

Agilidade

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

Page 7: Engenharia de Software - Pontos de função

Edição 44 - Engenharia de Software Magazine 7

AgiLidAdE

N o t a d o D e v M a n 1

Scrum: Scrum é um framework para gerenciamento de projetos ágeis muito utilizado na área de desenvolvimento de software. Uma das principais características do Scrum é permitir o desenvolvimento de produtos complexos de uma forma incremental e iterativa, contribuindo para decompor um grande produto complexo, em pequenos subprodutos mais simples, mais rápidos e mais fáceis de serem desenvolvidos e entregues. No Scrum estas iterações são chamadas de Sprints, e uma característica marcante de sua estrutura e aplicação é o controle sobre os trabalhos realizados, e a possibilidade de correção e adaptação rápida, permitindo que a equipe altere sua forma de agir ou de pensar o mais breve possível, evitando que problemas ou erros causem danos maiores ao projeto.

N o t a d o D e v M a n 2

XP: O eXtreme Programming ou XP é um modelo ágil de desenvolvimento de software criado em 1996 por Kent Bech no Departamento de Computação da montadora de carros Daimler Chrysler. Ele possui muitas diferenças em relação a outros modelos, podendo ser aplicado a projetos de alto risco e com requisitos dinâmicos (vagos ou em constante mudança), conduzidos por equipes de tamanho médio e pequeno.

Como todo método ágil, o XP procura responder com velocidade às mudanças nas especificações do projeto, com base em princípios, valores e práticas bem definidos. Este método enfatiza o desenvolvimento rápido garantindo a satisfação do cliente e cumprindo as estimativas do projeto. O XP baseia-se em cinco valores para guiar o desenvolvimento: Comunicação, Coragem, Feedback, Respeito e Simplicidade. Segundo Beck, o método oferece ainda 12 práticas, a saber: i) Jogo do planejamento; ii) Versões pequenas; iii) Metáfora; iv) Projeto simples; v) Teste; vi) Refatoração; vii) Programação em pares; viii) Propriedade coletiva do código; ix) Integração contínua; x) 40 horas de trabalho semanal; xi) Cliente presente; e xii) Padrões de codificação.

N o t a d o D e v M a n 3

FDD: O FDD é uma metodologia que serve tanto para o gerenciamento de projetos quanto para a Engenharia de Software. Isto a torna mais complexa quando comparada com outras metodologias ágeis. Por exemplo, o RUP (Rational Unified Process) da IBM, uma metodologia considerada tradicional, trata o gerenciamento de projetos como uma disciplina dentro do seu framework, já que o seu foco está na Engenharia de Software em si. Já o SCRUM, tem no papel do Scrum Master, uma figura parecida com a de um Gerente de Projetos formal, mas que tem seu foco na facilitação dos trabalhos por parte da equipe técnica. O foco dessa metodologia está na auto-organização da equipe e, para isso, são necessários analistas seniores.

O ponto forte da metodologia FDD está na capacidade de realizar features. Para esta metodologia, uma pequena feature possui um alto valor para o cliente. O exemplo de uma feature está em um caso de uso com a função de “calcular a média de salário dos gestores”, ou de “realizar um relatório integrado de vendas” e assim por diante. Veja que não é estranha a menção do termo “caso de uso” para exemplificar uma feature, já que a ideia é similar. Essa descrição do requisito que o FDD chama de feature são os casos de uso no RUP e as estórias utilizadas no XP. O site www.agilemodeling.com/essays/fdd.htm destaca que uma lista de features é inicialmente indicada para que seja elaborado o planejamento do projeto com estimativas de esforço para sua execução. Basicamente, esta é a proposta do FDD.

como um dos principais itens do desenvolvimento de software a agilidade na produção. Porém, como criar produtos com me-nos tempo e com a mesma eficiência? São dúvidas como essas que vem transformando nossas metodologias na tentativa de alcançar o melhor e mais ágil modelo de desenvolvimento de software.

Contudo, será que somente uma boa metodologia é o sufi-ciente para apoiar essa difícil missão? A resposta certamente é NÃO. Para se obter agilidade no processo de desenvolvimento de software é preciso aplicar o conceito nos três pilares que fazem parte deste trabalho, que são: equipe, programas e em-presa. Esse é o principal objetivo deste artigo, proporcionar ao leitor uma breve abordagem do que se faz necessário para atingir a agilidade no desenvolvimento de software, quais os requisitos para criar um time ágil, quais os pilares e processos que envolvem esse trabalho, qual o papel da empresa para dar

suporte aos processos, como distribuir a responsabilidade de cada envolvido no processo e qual a importância dessa distribuição.

Requisitos ágeis para a equipeÉ importante ressaltar que o modelo de equipe que será

apresentado neste artigo tem como principal propósito au-xiliar o time de desenvolvimento a se organizar ao definir papéis, distribuir responsabilidades e criar as atividades para um projeto no modelo ágil. Sendo assim, é de total valia usar esses conceitos para modelar e adequar a sua equipe na sua realidade.

Sabemos que um dos grandes desafios é fazer com que a equipe incorpore o modelo ágil para contribuir ao máximo com o time. Recomendo aos interessados pela teoria da lide-rança de pessoas dar uma no lida modelo Tuckman’s stages of group development proposto pelo psicólogo americano Bruce Wayne Tuckman.

Funções e responsabilidades da equipeAo estudar e analisar diversos modelos organizacionais de

uma equipe ágil proposta em diferentes metodologias como XP, Scrum, Lean, entre outros, chega-se à conclusão de que a estrutura organizacional de uma equipe ágil é basicamente a mesma em todas metodologias.

O Scrum, por exemplo, propõe um modelo que se divide em três principais funções, são eles: Scrum Master (Responsável Ágil), Product Owner (Proprietário do Produto) e o resto da

Page 8: Engenharia de Software - Pontos de função

8 Engenharia de Software Magazine - Requisitos para agilidade no desenvolvimento de software

equipe que consiste principalmente de desenvolvedores e testadores de software.

Composição da equipe ágilA Figura 1 representa de forma gráfica o modelo organiza-

cional de uma equipe ágil. Na sequência conheremos cada um desses papéis.

Figura 1. Ilustração do nível de equipes

Proprietário do produtoComo já definido no Scrum, o proprietário do produto tem

como característica atuar como a única função arbitrária, ou seja, esse papel é responsável por determinar e priorizar as necessidades dos utilizadores e gerenciar os itens acumulados (product backlog). É importante lembrar que esse artigo não descreve Scrum como metodologia a ser seguida. Indepen-dente da metodologia que sua equipe adotou como ágil, é recomendada a aplicação da função proprietário do produto, já que esse papel vem mostrando verdadeiros avanços na simplificação do trabalho exercido pela equipe.

Contudo, as responsabilidades do proprietário do produ-to são ainda maiores. Segundo o princípio Agile Manisfesto #4 - “Homens de negócio e desenvolvedores devem trabalharem juntos diariamente durante o andamento do projeto”. Com base nesse princípio, o proprietário do produto é a função ideal para orientar a equipe e participar diariamente com a mesma em suas atividades no intuito de direcionar e definir suas prioridades.

Podemos dizer então que o proprietário do produto é o prin-cipal responsável pela definição e priorização de requisitos. Portanto, a função proprietário do produto é responsável pelas seguintes atribuições:• Trabalhar com todos stakeholders (gerentes, analistas, clientes e interessados) do projeto para determinar os requisitos;• Priorizar as atividades com base no valor relativo do cliente;• Definir motivos para iteração, atuar e elaborar relatórios, participar e revisar processos buscando melhoria contínua.

Responsável ÁgilO responsável ágil é geralmente o papel do líder do projeto.

Essa função tem como responsabilidade dirigir o time para alcançar suas metas e, em alguns projetos, é importante so-mente na fase de transição. Quando o modelo ágil é imposto

na equipe e se torna a metodologia do time, as regras são auto-impostas, fazendo com que a participação do Responsável Ágil se torne menos frequente e necessária. Resumidamente, as responsabilidades desta função se dividem em:• Facilitar o progresso da equipe em direção à meta;• Liderar os esforços da equipe e buscar a melhoria contínua;• Fazer cumprir as regras do processo ágil;• Eliminar obstáculos.

Desenvolvedores e TestadoresA equipe se completa com os desenvolvedores e testadores.

Geralmente o tamanho de uma equipe ágil é limitada entre 4 até 6 desenvolvedores e de 1 até 3 testadores, idealmente trabalhando juntos.

DesenvolvedoresO modelo de trabalho aplicável aos desenvolvedores pode ser

o modelo de programação em par com outro desenvolvedor, ou também emparelhado com um testador ou outro modelo ágil, de forma a operar mais independente e ter interfaces com múltiplos testadores e desenvolvedores. Contudo, a responsa-bilidade desta função é basicamente a mesma, são elas:• Codificar os requisitos;• Colaborar com os testadores e proprietários do produto garantindo a codificação do produto de forma padronizada conforme definição da equipe;• Codificar e executar as unit test;• Garantir o check-in e check-out do código feito diariamente;• Participar ativamente na melhoria do ambiente de desenvolvimento.

TestadoresOs testadores são parte fundamental e integrante da equipe

ágil. Os testadores estarão presentes logo no primeiro código a ser liberado, e se faz necessário passar pela aplicação de testes e aprovação do time de testadores. A principal responsabilida-de atribuída a essa função é a liberação do código fonte para produção ou continuidade do fluxo de trabalho. É de extrema importância o cumprimento desse requisito para se obter qualidade e agilidade no desenvolvimento de software. Outras responsabilidades atribuídas a essa função são:• Criar casos de testes e aprovação;• Interface com os desenvolvedores e proprietário do produto para garantir e certificar o entendimento das funcionalidades requeridas;• Executar os testes de aprovação;• Desenvolver teste de aprovação para a atualização de com-ponentes no ambiente de produção.

EspecialistasNão podemos deixar de ressaltar a importância de recursos

compartilhados e interfaces para outras funções. Segundo o princípio Agile Manifesto #11 - “As melhores arquiteturas, requisitos e projetos emergentes de equipe auto-organizadas.”. Assim sendo, se faz

Page 9: Engenharia de Software - Pontos de função

Edição 44 - Engenharia de Software Magazine 9

AgiLidAdE

necessário estabelecer um trabalho colaborativo com especialista que, não necessariamente fazem parte da equipe, porém contri-buem com seus conhecimentos. Alguns desses papéis são:• Arquitetos de software;• Especialistas de qualidades QA;• Especialistas de infraestrutura;• Administradores de bancos de dados;• Especialistas em gerenciamento de configuração;• Especialistas de implantação.

Conceito ágilSabendo que o intuito de desenvolver software com agilidade

não exclui a principal necessidade de criar aplicativos eficien-tes que agregue valor ao cliente, precisamos assegurar que as equipes ágeis estejam aplicando modelos simples, porém abrangendo todos os requisitos possíveis. Uma vez escutei uma frase que dizia: “O difícil é fazer o simples, o complexo todo mundo faz”. Resumindo, o significado dessa frase é: neste momento precisamos garantir que a equipe não esteja sendo sobrecar-regada com requisitos desnecessários que não agregam valor ao cliente e não geram resultado para a equipe.

Histórias de usuáriosEssa função é originada do modelo XP. Histórias de usuá-

rios (User Stories) vem com a proposta de substituir o famoso requisitos de software. Este item ágil atualmente faz parte dos modelos Scrum, XP e na maioria das outras metodologias ágeis. A responsabilidade e definição desse usuário se resume em: “Uma breve descrição dos principais objetivos que levam as necessidades dos clientes através de fluxo de valor”.

Ao contrário de requisitos que definem o que o sistema “deve” fazer na maioria das vezes como obrigação contratual, histórias de usuários são breves declarações de usuários expressando suas intenções que descrevem um recurso que o sistema “pre-cisa” fazer para alguns usuários ou departamento.

A principal proposta dessa função é transmitir à equipe de desenvolvimento o que realmente traz benefícios ao usuário agregando valor ao produto, ensinando a equipe a se concen-trar no que realmente agrega valor ao negócio do usuário.

BacklogA última função que integra uma equipe ágil é o backlog.

O produto backlog consiste em acumular todos os recursos necessários a serem implementados, identificados pela equipe ágil com base em todas as histórias de usuários.

A responsabilidade dessa função é acumular os itens a serem desenvolvidos com base nas histórias dos usuários. Embora existam diversas tarefas a serem executas como: itens de confi-guração, requisitos de infraestrutura, entre outras atividades, o principal objetivo do backlog é concentrar a atenção da equipe nas histórias de usuário.

Requisitos ágeis para o programaNo nível de equipe, foi introduzido um conceito que aborda

a criação de equipes de software preparadas para definir,

desenvolver e testar o software. Neste nível as equipes são capacitadas e trabalham a partir de um backlog local que está sob o gerenciamento do proprietário do produto. O proprie-tário do produto tem o controle para definir, construir e testar seus componentes fase a fase. Com base nos princípios do Agile Manifesto, esse é o mecanismo ideal para incentivar e motivar a equipe para produzir os resultados positivos.

No nível de programa, será apresentado um processo orga-nizacional e modelo de requisitos que fornece mecanismos para aproveitar os recursos que integram as equipes ágeis para um propósito maior, ou seja, a entrega de um sistema ou um conjunto de aplicativos para os clientes. Neste momento os problemas são outros e a empresa irá enfrentar diferentes desafios para executar com sucesso o conceito de agilidade. Resumidamente, as metas neste nível são:• Roadmap: definir e comunicar a visão do programa e manter um roteiro;• Gerenciamento de liberação: Coordenar as atividades das equi-pes para definir critérios de liberação;• Gestão da qualidade: Assegurar a qualidade do sistema, desem-penho, segurança, e quaisquer normas impostas anteriormente devem ser atendidas;• Implantação: A definição de critérios para implantação deve ser gerida no nível de programa;• Gestão de recursos: Ajustamento dos recursos conforme necessário para enfrentar as limitações e dificuldades na capacidade do programa para entregar o valor necessário em tempo hábil;• Eliminação de obstáculos: Os líderes e gestores de progra-mas são responsáveis por eliminar bloqueios que atrasem a equipe.

Equipes recursos e equipes componentesNesta parte do artigo será apresentado como funcionam as

equipes de recursos e componentes. Vamos fazer uma com-binação e comparação para demonstrar os resultados organi-zacionais à equipe de organização. Em minha opinião, essa é uma das decisões mais difíceis para serem tomadas. Perceber a necessidade e decidir a inclusão de uma dessas duas equipes para agilidade do projeto requer muito cuidado.

Equipes recursosUma equipe de recursos ou em inglês Feature Team, é basi-

camente um time com diferentes habilidades, ou seja, uma equipe composta com profissionais de diversas competências para desenvolver um recurso de ponta a ponta.

Para ilustrar a diferença entre equipes de recursos e equipes de componentes, vamos imaginar um cenário típico nos proje-tos corporativos. Em uma arquitetura como a apresentada na Figura 2 em que as equipes se organizam em torno de camadas, teríamos neste momento seis equipes, sendo uma para cada camada. O modelo organizacional por equipes de componentes dirige o time para uma variedade de problemas como:• Nível de comunicação reduzida em todas as camadas;• Trabalha com o sentimento de que o projeto apresentado no

Page 10: Engenharia de Software - Pontos de função

10 Engenharia de Software Magazine - Requisitos para agilidade no desenvolvimento de software

• contrato é o suficiente;• Finaliza o desenvolvimento da camada sem um produto potencialmente utilizável.

Figura 2. Ilustração de arquitetura de projeto

A proposta da equipe de recursos seria, em vez de ter equipes separadas por camadas da arquitetura, termos as equipes de recursos trabalhando em todas as camadas.

Algumas vantagens podem ser obtidas neste modelo orga-nizacional, são elas:• As equipes de recursos têm mais habilidades para avaliar o impacto das decisões de projetos. Essa habilidade é adquira pelo fato do time construir a funcionalidade de ponta a ponta, isso maximiza o aprendizado dos membros auxiliando nas decisões que se fazem necessárias para o projeto;• Reduz o desperdício de esforços da equipe, ou seja, o risco de criar funcionalidade demasiada é consideravelmente menor;• Garante que as pessoas certas estão falando, ou seja, uma equipe de recursos inclui todas as habilidades necessárias para ir da idéia a execução do recurso;• Diminui o risco de integração do componente com os re-cursos, ou seja, um componente desenvolvido pela equipe de componente só tem valor depois de integrado ao produto da equipe de recursos, sendo assim, o esforço para integrar o trabalho da equipe de componente ao produto precisa ser calculado.

O especialista em projetos ágeis, Mike Cohn, publicou um artigo em seu blog apresentando alguns benefícios obtidos com a equipe de recursos que pode ser encontrado no ende-reço http://blog.mountaingoatsoftware.com/the-benefits-of-feature-teams.

Equipes componentesEmbora seja fortemente recomendado o uso de equipes de

recursos, existem situações em que a equipe de componentes é apropriada. Como seu próprio nome, uma equipe de compo-nente é aquela que desenvolve um software para ser entregue a uma outra equipe do projeto, em vez de diretamente ao cliente. Um exemplo seria uma equipe de componente desen-volvendo uma camada de mapeamento entre a aplicação e o banco de dados.

O gerenciamento de equipe de componentes nem sempre é uma tarefa fácil. Geralmente as equipes de componentes trabalham paralelas às equipes de recursos. É importante garantir que a equipe de componentes tenha conhecimento

das necessidades da equipe de recursos. No caso do Scrum, o proprietário do produto irá auxiliar a equipe de componente priorizando as necessidades de seu produto, porém quando a equipe de componentes está a frente da equipe de recursos, é preciso, na maioria das vezes, adivinhar quais serão as necessidades seguintes. Muitas vezes isso resulta em com-ponentes ou estruturas que não são utilizáveis pelas equipes de recursos. Esse é um claro exemplo do que chamamos de esforços desperdiçados.

Qual é o melhor cenário?Embora não exista uma regra para auxiliar a tomada de

decisão, é necessário compreender a fundo as vantagens e desvantagens das equipes descritas acima para uma escolha apropriada.

Nas grandes empresas, onde há diversas equipes, recursos e sistemas que em algumas vezes são compostos por siste-mas ou componentes, o modelo de equipes provavelmente será uma mistura entre equipes de recursos e equipes de componentes.

É recomendado uma certa inclinação para as equipes de re-cursos. Alguns especialistas acreditam que uma boa estratégia para empresa ágil é permanecer no 70%-30% ou 80%-20% de equipes de recursos para equipes de componentes. O espe-cialista em projetos ágeis, Chad Holdor, ou como ele gosta de ser chamado, o Agile Ninja, publicou um vídeo em seu blog detalhando claramente as diferenças entre equipes de recursos e equipes de componentes e no final recomenda um modelo ágil combinando membros da equipe de componentes para fazer a equipe ágil como ilustrado na Figura 3. Esse vídeo pode ser encontrado no endereço: http://www.scaledagiledelivery.com/2011/04/28/component-vs-feature-team/.

Figura 3. Combinando membros da equipe de componentes para fazer a equipe de recursos

A equipe de sistemasComo visto, as equipes ágeis são os motores de produção

de um software. Aprendemos que cada equipe precisa ter habilidades necessárias para especificar, projetar, codificar e testar os componentes e recursos de seu domínio.

Page 11: Engenharia de Software - Pontos de função

Edição 44 - Engenharia de Software Magazine 11

AgiLidAdE

No entanto, no nível de programa, essas equipes formadas por pessoas podem não ter todas as características necessárias para concluir uma solução completa. Com isso, às vezes se faz necessário adicionar uma equipe que complemente as equipes de recurso ou componentes. Essas equipes são formadas de sistemas que podem auxiliar nos testes de sistemas, sistema de garantia da qualidade, sistema de integração, suporte na infraestrutura de desenvolvimento e etc.

Equipe de gerenciamento e liberaçãoNas melhores práticas que procedem uma empresa ágil, para

cada produto existe um time de planejamento e lançamento que a empresa utiliza para alinhar as equipes técnicas com as equipes de negócios para o lançamento.

Esta equipe é necessária porque, embora as equipes ágeis sejam habilitadas, não tem necessariamente a visibilidade do negócio, ou até mesmo a autoridade para decidir quando será a entrega do produto para o usuário final. Geralmente essa equipe é formada pelos principais membros do nível de programa da empresa, tais como:• Linha de negócio;• Proprietário e gerente do produto;• Representantes de marketing;• Gerentes associados aos produtos;• Equipe de implantação do produto.

É recomendado que essa equipe faça reuniões semanalmen-te ou em um período adequado à importância do produto. A reunião tem como principal foco debater a situação do produto, tais como: status; onde estamos; se vamos cumprir a tempo nossos objetivos; mudanças necessárias; impactos, entre outros.

O principal intuito desse encontro é promover a visibilidade ampla e o gerenciamento sênior semanal para o estado de liberação do produto.

Roteiro ou RoadmapA equipe de gerenciamento e liberação no final de cada fórum

resulta nos dados do planejamento da versão que são usados para atualizar a planilha de roadmap.

O roteiro deve ser composto com as datas planejadas para os lançamentos de cada solução, cada qual com o consultor de recursos priorizando conforme a necessidade do negócio. A Figura 4 representa o modelo de um roadmap.

O roteiro está sujeito a alterações em qualquer fase do pro-duto, essas alterações podem ser causadas por questões como: prioridade de negócio, fatores técnicos entre outros fatores imprevisíveis, portanto, não se deve fazer compromissos ex-ternos com planos além do próximo lançamento.

Requisitos não-funcionaisA visão também precisa conter os requisitos não-funcionais,

tais como: confiabilidade, desempenho, qualidade, compatibili-dade e etc. Os requisitos não-funcionais devem ser descritos no

backlog do programa como recursos normais, ou seja, usando o mesmo conceito de histórias de usuários. Alguns exemplos de como esses requisitos podem ser solicitados são:• O cliente solicita que o aplicativo funcione nos principais navegadores do mercado;• O cliente exige que uma determinada funcionalidade seja executada em no máximo 30 segundos;• O cliente solicita disponibilidade de 99,99% do sistema.

Figura 4. Ilustração básica de uma planilha de roteiros

Teste de requisitos não-funcionaisRequisitos não-funcionais, como desempenho, disponibilida-

de e outros do gênero, são frequentemente descritos pelo cliente como qualidade do produto, porém devem ser aplicados no backlog como um histórico de usuário e tratado como recurso, assim aplicando os testes para sua qualidade. A Figura 5 ilustra um modelo simples para aplicação de testes de qualidade nos requisitos não-funcionais.

Figura 5. Modelo básico de teste de requisitos não-funcionais

Geralmente a maior parte dos requisitos não-funcionais (0..*) requerem um ou mais testes. Neste cenário, pode ser aplicado outro tipo de testes de aceitação. Aplica-se então os testes de qualidade de sistemas. Este termo indica que estes testes devem ser executados em intervalos periódicos no intuito de validar o sistema.

Requisitos ágeis para a empresaO terceiro e último requisito ágil que será apresentado neste

artigo é o nível empresa ou portfólio. Nesta etapa, encontramos a função de gestão de portfólio que inclui equipes e organiza-ções dedicadas à gestão dos investimentos e conformidades com a estratégia de negócio da organização.

Para muitas fábricas de software atualmente, independente do tamanho de seus projetos ou equipes, o modelo de equi-pes junto ao modelo de programas podem ser o suficiente para gerenciar seus projetos de forma ágil. No entanto, para empresas que contém muitos produtos em que a governança e o modelo de gestão para o desenvolvimento de novos ativos

Page 12: Engenharia de Software - Pontos de função

12 Engenharia de Software Magazine - Requisitos para agilidade no desenvolvimento de software

de software exige novos artefatos e níveis ainda mais altos de abstração, a inclusão do modelo de portfólio pode ajudar no gerenciamento desses novos desafios.

Requisitos de investimentoUm conjunto de temas de investimento estabelece os objetivos

de investimento em relação à empresa ou unidade de negócio. Este tema é o item que representa uma série de iniciativas que impulsionam os investimentos da empresa para determinada solução, produto ou serviço.

Equipe de gestão de portfólioA equipe de portfólio pode ser formada pelos gerentes ou

responsáveis pelo negócio. Os membros desta equipe são os indivíduos que tem a responsabilidade final com as linhas de negócio. Em algumas empresas, esse processo pode ser com-parado aos processos de elaboração orçamentária anual.

A equipe de gestão de carteira/portfólio toma suas decisões com base em uma combinação das seguintes opções:• Investimento em ofertas de produtos, melhorias, suporte e manutenção;• Investimento em novos produtos, novos serviços ou trabalho comercial para ganhar novas fatias de mercado;• Reduzir investimento para as ofertas existentes que estão chegando ao fim de sua vida útil ou lucrativa.

Para fornecer governança e visibilidade nesta fase de investi-mentos, a equipe de gerenciamento de portfólio pode ser diri-gida pelas melhores práticas de um modelo de gerenciamento de projetos como PMO.

Arquitetura: empresa, programa e equipeAo obter maturidade ágil a organização tende a continuar a

construção e conservação de uma arquitetura de responsabili-dade eficaz. Ao administrar e gerenciar esses níveis de requi-sitos que resultam em agilidade, a empresa pode evitar alguns acontecimentos ruins, porém comuns, como por exemplo:• Atrasos consideráveis para o lançamento do produto;• Redução do risco de criar uma arquitetura sem capacidade de se estender, deixando o sistema frágil e instável a mudanças, correndo o risco de ser totalmente reescrito;• Evita o desperdício de esforços no desenvolvimento e maus investimentos.

É importante que essa administração ocorra de forma contí-nua em cada um dos níveis apresentados.

ConclusãoÉ importante ressaltar que o modelo com níveis de equipes,

programas e empresas apresentados neste artigo é uma de-finição arbitrária. Portanto, o objetivo é fornecer um modelo mental que ajude a elevar o alcance de abstração e escala para se obter agilidade no desenvolvimento de software.

Em resumo, vimos um conjunto de requisitos que são otimizados para apoiar a entrega rápida das necessidades valiosas do cliente. Também vimos como as equipes ágeis podem alcançar a qualidade mais alta através de testes funcionais e automação de teste.

No nível de programa, foram apresentados requisitos, artefatos e processos que são necessários para alcançar o desenvolvimento ágil. Foi apresentado um modelo organizacional para auxiliar na montagem de equipes otimizadas para a entrega ágil de valor.

E, para concluir, introduzimos o nível de empresa. Nesta fase foi apresentada de forma resumida uma abordagem sobre os temas de investimento estratégico, gestão de portfólio e arquitetura de melhoria contínua.

Mike Cohn’s blog Succeeding with agilehttp://www.mountaingoatsoftware.com/

Chad Holdorf’s bloghttp://www.scaledagiledelivery.com/

Dean Leffingwell, Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise, Addison-Wesley Professional, 2010.

Craig Larman; Bas Vodde, Scanling Lean & Agile Development, Addison-Wesly Professional, 2008

Chris Sterling; Brent Barton, Managing Software Debt: Building for Inevitable Change, Addison-Professional, 2010.

Mike Cohn, Succeeding with Agile: Software Development Using Scrum, Addison-Wesley Professional, 2009

Links

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

seu Feedback

sob

re esta edição

Page 13: Engenharia de Software - Pontos de função

Edição 44 - Engenharia de Software Magazine 13

Fábio Cruz [email protected]

Graduado na área de TI e PMP certifica-do com mais de 17 anos de experiência profissional, atuando sempre na área de desenvolvimento de sistemas, sendo os úl-timos 10 dedicados à liderança de equipes e à coordenação de projetos. Atualmente gerente de projetos na empresa americana Ascendant Technology, voluntário no PMI Chapter de Santa Catarina e autor do blog www.fabiocruz.com especializado em ge-renciamento de projetos.

De que se trata o artigo?Demonstrar como utilizar os artefatos de um geren-ciamento ágil como o Scrum, suportando e dando apoio aos artefatos também complementares do gerenciamento tradicional, apresentando como esta união pode ser benéfica para um mesmo projeto, principalmente na área de gerenciamento das co-municações, proporcionando um acompanhamento transparente e bem próximo da execução do projeto.

Em que situação o tema é útil?Este artigo visa demonstrar como resolver problemas gerados por falhas de comunicação entre a equipe do projeto, sua gerência sênior e o cliente, apresentando formas de eliminar os buracos causados pela falta de

informação através da união de artefatos de origem ágil com outros de origem tradicional, fornecendo reflexões e provocando ações para unir as duas abor-dagens em um mesmo projeto.

ResumoPara se gerenciar projetos de desenvolvimento de softwares é preciso estar constantemente atuali-zado com as informações do projeto, e ao mesmo tempo comunicar a todos os interessados com a frequência necessária. Este artigo mostra como aliar os artefatos de uma abordagem ágil como o Scrum ao gerenciamento de projetos tradicional, gerando benefícios e melhorando a comunicação do projeto em várias direções.

Scrum e o gerenciamento de projetos – Parte 3O Scrum e a sua relação de aliança com o gerenciamento de projetos tradicional

Engenharia

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

Independente do método utilizado para executar e gerenciar projetos, a comunicação continua sendo a área

mais importante quando se fala do su-cesso em projetos. Simplesmente porque a comunicação precisa acontecer para que o projeto seja entendido, executado e entregue.

Outro objetivo fundamental da comu-nicação é manter a gerência sênior das empresas envolvidas com o projeto in-formadas sobre o andamento do mesmo.

Entende-se gerência sênior, neste caso, como o patrocinador do projeto (Sponsor) e as demais gerências compostas pelo corpo diretivo responsável pelo projeto, tanto na empresa executora quanto na empresa contratante.

Esta comunicação tem o objetivo principal de posicionar e informar. Normalmente estes posicionamentos são requisitados periodicamente e geralmente incluem análises de valor agregado, marcos principais (milestones),

Page 14: Engenharia de Software - Pontos de função

14 Engenharia de Software Magazine - Scrum e o gerenciamento de projetos – Parte 3

últimas realizações do período, principais riscos, situação fi-nanceira atual do projeto, entre outras informações relevantes que podem variar um pouco de acordo com o projeto e com a necessidade de informação das gerências.

Quando o projeto está no início, ou quando está tudo bem controlado e o cliente satisfeito, a comunicação visando po-sicionar e informar costuma ser desvalorizada, feita de uma forma resumida demais e deixando de ser um valor real para quem as recebe, ou seja, deixando de informar aos interessa-dos dados importantes sobre o projeto. Este comportamento faz parecer que a comunicação não é necessária quando tudo está indo bem.

Por outro lado, quando o projeto está com problemas, ou em fases críticas, um simples relatório de situação do projeto (Status Report) pode ser um drama para um gerente ou para uma equipe despreparada, e que principalmente não estava informando e posicionando desde o início do projeto. Sendo assim, o primeiro recado é que a comunicação deve ser reali-zada sempre, durante todo o ciclo de vida do projeto.

A tarefa de comunicar e informar sobre o andamento do projeto deve ser simples, e é obrigatória para qualquer gerente. Porém, esta atividade que deveria ser simples, pode se tornar um pesadelo pelo simples fato da equipe de gerenciamento não manter informações atualizadas e bem documentadas sobre o projeto. Esta falta de informação centralizada faz com a equipe tenha que sair correndo atrás dos dados no dia da apresentação do Status Report, ou após a ligação da gerência sênior pedindo informações atualizadas.

Buscando evitar este tipo de problema e facilitar a comuni-cação geral de um projeto, este artigo se propõe a apresentar um modelo de união de alguns artefatos de comunicação do gerenciamento tradicional, com outros existentes no geren-ciamento ágil, mais especificamente no framework do Scrum, com o objetivo de interligar todas as partes interessadas de um projeto através de informações corretas e bem distribuídas.

Conceitos de gerenciamento ágil e tradicionalAlguns conceitos importantes para o entendimento do Scrum

foram descritos nas primeiras duas partes desta série de arti-gos, que foram publicadas nas edições 41 e 43 da Engenharia de Software Magazine.

O framework do Scrum é uma das práticas ágeis mais utiliza-das atualmente, principalmente por trazer benefícios ao geren-ciamento de projetos de software. Um destes benefícios mais evidentes é a forma com que o Scrum propicia a visualização dos trabalhos do projeto de forma direta, objetiva e simples.

Apoiado na qualidade do Scrum de contribuir para uma co-municação mais eficaz e eficiente, será demonstrado aqui como comunicar as informações mais relevantes para um acompanha-mento de um projeto que está sendo executado. O acompanha-mento poderá ser realizado pelo time de execução, pela equipe de gerenciamento operacional e pela gerência sênior.

Mais uma vez, como nos artigos anteriores desta série, mostraremos como o Scrum complementa o gerenciamento tradicional, assim como o gerenciamento tradicional apóia o

Scrum. Porém, não iremos comparar o Scrum a nenhuma abor-dagem tradicional específica, mas sim tratar o gerenciamento de projetos como uma área de conhecimento geral, com seus aspectos comuns em várias abordagens de mercado.

A primeira parte tratou de papéis e responsabilidades, a segunda falou das práticas, ferramentas e técnicas. Por fim, nesta terceira parte, falaremos dos artefatos existentes nas duas abordagens, agindo de forma complementar e influenciando diretamente no resultado da comunicação do projeto.

Gerenciamento ativo e não reativoAntes de sair comunicando, a equipe de gestão precisa ter o

que comunicar e saber como fará a distribuição das informações coletadas. Este pode ser o ponto mais importante, que definirá uma boa ou uma má comunicação dentro de um projeto.

Um erro básico que parece simples de ser evitado, mas na prática a sua ocorrência ainda é alarmante, é que os gerentes de projetos, ou as equipes de gerenciamento, não acompanham o projeto de perto, e não possuem informações constantemente atualizadas. Isso gera um problema enorme, pois quando a informação é solicitada, a gerência precisa reagir ao pedido e sair correndo atrás dos dados.

Este gerenciamento reativo é ruim para todo o projeto, podendo gerar insegurança e a geração de dados falsos, além de demons-trar falta de metodologia implantada e organização definida.

O objetivo deve ser sempre um gerenciamento ativo, ou seja, não basta ter um modelo (template) de Status Report pronto para ser usado, é preciso ter sempre as informações que serão utilizadas para montar este relatório, e estas preferencialmente devem ser as mais recentes possíveis. Neste ponto é que o Scrum pode nos ajudar com seus artefatos e regras.

Artefatos do gerenciamento tradicionalO primeiro passo na direção de uma boa comunicação é

ter as definições do que, como e quando serão realizadas as comunicações do projeto.

Neste ponto, o gerenciamento tradicional é um forte aliado, pois quase todas as boas práticas e metodologias tradicionais trazem em seu conteúdo a orientação de se criar um plano de gerenciamento da comunicação.

Este plano é fundamental e deve ser construído e divulgado no início do projeto; o quanto antes melhor. Este documento não precisa ser extenso ou completo, pelo contrário, a orien-tação é que seja curto e direto.

O objetivo de um plano de gerenciamento da comunicação é determinar que tipo de informação deve ser veiculada durante o projeto, como estas devem ser divulgadas, qual deve ser a frequência de circulação de cada relatório informativo, e por fim, quem deve receber cada um deles.

Outro artefato bem relevante e que se encaixa perfeita-mente no tema comunicação, é o plano de gerenciamento do projeto. Este plano poderá conter o de comunicação, além de geralmente ser composto pelos planos de gerenciamento de requisitos, escopo, mudanças, riscos e qualidade. Todos estes sub-planos fornecem informações importantes para várias

Page 15: Engenharia de Software - Pontos de função

Edição 44 - Engenharia de Software Magazine 15

gERENCiAMENto dE PRoJEtoS

partes interessadas (stakeholders) pelo projeto, e geralmente fazem parte do que será comunicado durante o projeto.

O plano de projeto pode conter, inclusive, informações pertinentes de como as metodologias de gerenciamento de projetos serão aplicadas e como funcionarão conjuntamente ao longo do ciclo de vida do projeto. Já o plano de comu-nicação deverá informar quais artefatos serão utilizados, quais suas finalidades e origens conceituais (Scrum ou tradicional).

A partir destes documentos elaborados e divulgados corre-tamente, todos os responsáveis ou interessados ligados dire-tamente ou indiretamente ao projeto, poderão saber o que a equipe gerencial usará como artefatos de comunicação, além de como e quando cada documento será distribuído.

Note que esta preparação para se comunicar no decorrer do projeto, já é uma comunicação efetiva, e demonstra que há clareza e transparência na forma com que o projeto será conduzido e acompanhado.

Artefatos do ScrumO primeiro dos artefatos importantes do Scrum é o Backlog

do Produto, que é o conjunto de todos os requisitos e trabalhos necessários para entregar o projeto. Este artefato pode incluir regras de negócios, protótipos de tela, casos de uso, entre outros documentos relevantes.

Partindo de um Backlog do Produto completo para o projeto, ou para uma versão de entrega (release), se consegue obter os pró-ximos e mais detalhados documentos que fornecerão os dados importantes para que as comunicações do projeto aconteçam.

O Backlog do Produto se transforma no Backlog da Sprint, que deverá conter apenas os trabalhos selecionados para se entregar na próxima Sprint. A partir desta seleção de itens do Backlog, a equipe poderá ser apresentada a outro artefato do Scrum, as estórias dos usuários.

Falamos mais sobre Backlog do Produto na edição 43 da Engenharia de Software Magazine.

Estórias do usuárioUma estória do usuário (user story) é uma descrição resumida

que representa um item do Backlog, devendo ser sempre do ponto de vista do usuário final do produto. Em alguns casos um item de Backlog poderá dar origem a mais de uma estória, por questões de entendimento, ou para uma melhor visualização ou até por uma estratégia de abordagem gerencial e de execução.

Um item de Backlog pode possuir diversos documentos as-sociados a ele, além de especificações detalhadas. Entretanto, uma estória resume em poucas palavras o que a funcionalida-de deve fazer, servindo como um ótimo item para controle e acompanhamento. É aqui que começamos a ter artefatos para melhorar a comunicação, principalmente no nível gerencial.

Um exemplo para um fácil entendimento é um “cadastro de livros”, que é um item de Backlog possuindo protótipo de tela, modelo de dados, especificação de regra de negócio e caso de uso. Estes são todos os documentos que compõem o item de Backlog “cadastro de livros”, porém, para controle e

monitoramento, usaremos apenas a estória que definiremos a partir do seguinte padrão:

“Como um <tipo de usuário>, eu quero <um objetivo> para que <atenda uma necessidade>”.

Pegando o nosso item de Backlog “cadastro de livros” e criando uma estória com o padrão apresentado, teremos o seguinte:

“Como um usuário administrador, eu quero cadastrar um livro para que ele possa ser consultado por visitantes na internet”.

Como pode ser observado, é possível resumir todas as necessi-dades em poucas palavras, permitindo que seja possível colocar este texto em um post-it conforme ilustrado na Figura 1.

Figura 1. Estórias em post-its

A partir das estórias definidas, o time poderá trabalhar na reunião de planejamento da Sprint. Lembrando que esta cerimônia é parte integrante do Scrum e foi descrita em mais detalhes na Engenharia de Software Magazine 43.

TarefasNa primeira parte desta reunião de planejamento, o time

entende as estórias e determina o tamanho de cada uma. Esta estimativa servirá como artefato para medir o desempenho dos trabalhos no futuro. Já na segunda parte, o time detalha melhor as estórias, decompondo-as em tarefas menores.

Estas tarefas devem ter um tamanho apropriado para que possam ser determinadas em horas para conclusão, e devem ser independentes de outras atividades para que sejam consi-deradas finalizadas.

O resultado desta decomposição das estórias em tarefas menores será um dos mais importantes artefatos de controle que usaremos ao longo do projeto, pois estas tarefas menores serão utilizadas para que toda a equipe do projeto saiba o que precisa ser realizado, o que está sendo trabalhado e o que já foi concluído.

Uma estória é uma macro atividade, que resume um conjunto de trabalhos. Este conjunto de trabalhos poderá ser ilustrado através de várias tarefas associadas, que por sua vez vão com-por a estória, como ilustrado na Figura 2.

Figura 2. Decomposição da estória em tarefas

Page 16: Engenharia de Software - Pontos de função

16 Engenharia de Software Magazine - Scrum e o gerenciamento de projetos – Parte 3

Estamos falando destes dois artefatos porque precisamos de dados para acompanhamento e monitoramento do projeto conforme ele é executado, além de contribuir para o forne-cimento de informações consolidadas e atualizadas o mais breve possível. Com isso, começamos a colocar em prática a comunicação do projeto durante a execução.

Quadro de Tarefas (Taskboard)Este é um dos artefatos fundamentais e característicos do

Scrum, e possivelmente o que mais contribui para a comuni-cação do projeto e colaboração do time.

O quadro de tarefas nada mais é do que um espaço reserva-do para se colar ou fixar os post-its com as estórias e tarefas, separados por colunas e cores diferentes que proporcionam uma rápida identificação da atividade e sua situação, conforme ilustrada na Figura 3.

Figura 3. Quadro de tarefas do Scrum

O formato mais utilizado para montar o quadro de tarefa é:• Coluna 1: As estórias são colocadas uma embaixo da outra, na sequência da mais importante para a menos importante de cima para baixo;• Coluna 2: As tarefas “a fazer” ao lado direito da sua respec-tiva estória;• Coluna 3: As tarefas que o time “está fazendo”, também ao lado da sua respectiva estória;• Coluna 4: As tarefas já concluídas (“feito”), na última coluna à direita, também seguindo a mesma linha da sua respectiva estória;• Colunas complementares: Após a quarta coluna pode haver a coluna “não planejados”, para o agrupamento de tarefas não previstas e que surjam ao longo do desenvolvimento, e/ou colunas antes da “feito”, para separação de itens na etapa de “testes”, por exemplo.

Além das colunas distintas para cada etapa do desenvolvi-mento, também é sugerido que as tarefas sejam colocadas em post-its menores que as estórias e que seja adotada uma cor diferente para cada tipo de tarefa, por exemplo:

• Laranja: Tarefas planejadas;• Verde: Tarefas não planejadas;• Vermelho: Impedimento, ou seja, obstáculo que está impe-dindo a realização de uma tarefa. Geralmente colocado sobre a tarefa impedida;• Amarelo: Tarefas de teste.

Com este quadro montado, a comunicação do projeto começa a tomar uma forma naturalmente clara, objetiva e transparente. Note que o quadro de tarefas ilustrado na Figura 3 pode ser físico, e com isso fixado em uma parede bem visível para todos os interessados nas informações ali contidas.

Qualquer um que direcionar os olhares para o taskboard verá rapidamente um conjunto de informações condensadas em um único local, tais como:1. Quantas tarefas estão sendo realizadas simultaneamente (“fazendo”), o que fornece o número de pessoas trabalhando no desenvolvimento. O tamanho do time é representado pelo número de estórias, pois uma pessoa só pode realizar uma tarefa de cada vez;2. Quantas tarefas já foram concluídas (“feito”);3. Quantas tarefas ainda estão aguardando para serem traba-lhadas (“fazer”);4. Qual o número de tarefas não previstas, ou seja, quantas são da cor verde. Este item evidencia rapidamente qual o esforço aplicado em atividades não planejadas;5. Se alguém está parado devido a algum impedimento, ou seja, quantas tarefas estão sobrepostas com outras de cor ver-melha. Este item mostra claramente os momentos de falta de produção devido a fatores externos que não foram previstos inicialmente;6. Se a priorização dos trabalhos está sendo seguida conforme o planejado, pois de acordo com a regra do Scrum, somente depois de todas as tarefas da primeira linha estarem na coluna “feito”, é que podem ser iniciadas as tarefas da segunda linha. Neste caso, pode se tomar providências ao perceber um item sendo realizado fora de prioridade.

Este quadro de tarefas também pode ser virtual, a partir da utilização de softwares de gerenciamento ágil de projetos que permitem o cadastramento, acompanhamento e divulgação completa do taskboard. Um exemplo de uma ferramenta com estas funções é o Rational Team Concert (RTC), que permite o cadastro de projetos, de times, de Backlogs, de estórias e de tarefas, além do acompanhamento da taskboard e do gráfico de Burndown.

Outro detalhe importante sobre o taskboard é que os próprios integrantes do time mantêm as tarefas atualizadas no quadro pelo menos uma vez por dia, com influência principalmente da cerimônia conhecida como reunião diária, que pode ser vista em maiores detalhes na segunda parte desta série de artigos.

Gráfico de BurndownA Sprint é a principal iteração no Scrum, e ela nos ajuda a di-

mensionar os trabalhos e controlar o projeto em ciclos menores

Page 17: Engenharia de Software - Pontos de função

Edição 44 - Engenharia de Software Magazine 17

gERENCiAMENto dE PRoJEtoS

de até um mês. Maiores detalhes sobre as Sprints podem ser en-contrados na Edição 42 da Engenharia de Software Magazine.

A Sprint contém um conjunto de trabalhos a ser realizado em um determinado espaço de tempo, por isso ela é muito útil para acompanhar a evolução do projeto. Porém, como fazer este acom-panhamento e saber se o projeto está atrasado ou adiantado?

A resposta não é tão difícil quanto parece, principalmente depois de termos falado sobre o Backlog da Sprint, estórias e tarefas.

Todas as tarefas que precisam ser realizadas dentro da Sprint estão no taskboard, no entanto apenas olhar para o quadro de tare-fas não diz a equipe de gerenciamento se o projeto está em dia ou não. Para resolver este problema entra em ação o último artefato do Scrum que nos interessa aqui, o gráfico de Burndown.

O Scrum como abordagem ágil se preocupa com o esforço restante para se terminar o trabalho, e não com o que já foi concluído. Em outras palavras, o que importa no controle do Scrum é a quantidade de tarefas que ainda precisam ser completadas até o final da Sprint.

O gráfico de Burndown representa visualmente a soma das estimativas dos esforços restantes para se terminar os trabalhos contidos no Backlog da Sprint. Por isso, olhando o gráfico ilustrado na Figura 4, temos à esquerda uma coluna com a quantidade de trabalho que precisa ser completada, sendo que no primeiro dia da Sprint o trabalho restante será igual ao trabalho total.

Figura 4. Gráfico de Burndown.

Os dias estão na linha inferior do gráfico, e o acompanhamen-to é simples. Em resumo, o dia atual deve ter menos trabalho restante do que o dia anterior. Visualmente podemos fazer uma comparação fácil que nos ajudará muito na identificação da evolução dos trabalhos, permitindo saber se estão adiantados ou atrasados, da seguinte forma:1. No primeiro dia da Sprint, monte o gráfico colocando na coluna da esquerda a quantidade de trabalho necessário para completar a Sprint;2. Na linha inferior coloque os dias em que a Sprint ocorrerá;3. Por fim, trace uma linha ligando o total de trabalhos que precisam ser completados (coluna à esquerda) ao último dia da Sprint (à direita). Esta linha representará a velocidade média do time para atingir a meta da Sprint;

4. Ao final de cada dia da Sprint, ou no máximo no início de cada dia, marque no quadro a quantidade de trabalho restante na coluna referente ao dia específico;5. Trace uma nova reta ligando os pontos marcados com o total de trabalho restante a cada dia. Pronto, você terá a velocidade real do time.

Na ilustração da Figura 4, a linha vermelha representa a estimativa dos trabalhos a serem completados por dia, ou seja, a velocidade esperada marcada no início da Sprint.

A linha azul mostra a velocidade real do time de acordo com os trabalhos que estão sendo completados a cada dia. Caso a linha azul (real) esteja acima da linha vermelha (estimada), a Sprint está atrasada, caso contrário, está adiantada.

Para a opção do quadro físico fixado em uma parede, o time do projeto pode atualizar as tarefas antes ou durante as reu-niões diárias, que é a melhor opção.

Para a opção de taskboards virtuais através de softwares, opte por ferramentas que se integrem com os ambientes de desenvol-vimento e já atualizem automaticamente as tarefas em tempo real. Por exemplo, quando um desenvolvedor encerra uma tarefa pela ferramenta de desenvolvimento, esta por sua vez atualiza o software que mantém a taskboard também atualizada.

Comunicação visualSeguindo as etapas descritas, e principalmente usando os

artefatos sugeridos pelo Scrum, teremos uma comunicação visual muito eficiente. A equipe de execução e gerência do projeto, bem como a gerência sênior que tenha acesso ao qua-dro de tarefas e ao gráfico de Burndown, terá total acesso ao andamento do projeto.

Informações como quantidade de trabalho estimado e reali-zado, equipe alocada, planejamento, imprevistos, velocidade, riscos e atrasos poderão ser visualizados por todos, mantendo todas as informações relevantes claras e transparentes.

O impacto visual tem ainda uma característica importantís-sima. Provavelmente muitas pessoas olham para estas evidên-cias destacadas e pensam: “Mas com isso os meus erros e os da minha equipe ficarão a mostra!”. Exatamente! E é por isso que este modelo de trabalho se torna tão interessante.

Os problemas e falhas realmente ficarão evidenciados, se tornando um problema para os times que não buscam melhorar e corrigir seus defeitos. Para os demais, os resultados serão os melhores possíveis, porque a própria equipe buscará a cada iteração (Sprint) melhorar os seus resultados.

Os bons times buscarão transformar o taskboard em uma evidência de seu bom trabalho, e não em um problema que mostra para todos os seus erros. Esta qualidade que o Scrum proporciona pode ser entendida como um processo de me-lhoria contínua.

Comunicação formalCom os trabalhos sendo realizados conforme as definições

do tradicional plano de gerenciamento do projeto e seguindo as cerimônias, regras e artefatos do Scrum descritos até agora,

Page 18: Engenharia de Software - Pontos de função

18 Engenharia de Software Magazine - Scrum e o gerenciamento de projetos – Parte 3

não vão faltar dados para se montar relatórios de situação e informações relevantes para reuniões de acompanhamento.

Mesmo com metodologias ágeis de gerenciamento de pro-jetos, como Scrum, haverá momentos em que será preciso gerar documentos formais para divulgação às gerências, pa-trocinadores, clientes, parceiros, e outros. Além de que estes relatórios podem ser oficiais para aceite e/ou recebimento de parcelas financeiras de trabalho completado ou simplesmente para acompanhamento gerencial.

A partir do plano de comunicação realizado no início do pro-jeto, a equipe gerencial terá no planejamento oficial do projeto alguns documentos conhecidos como meios de comunicação, podendo ser, por exemplo:1.Cronograma de tarefas atualizado, principalmente eviden-ciando milestones, disponibilizado na internet em sites seguros com acesso restrito;2. Relatórios de situação divulgados semanalmente por e-mail;3. Apresentações executivas para o comitê gestor, realizadas mensalmente.

Cronograma Macro (milestones)O cronograma é uma ferramenta muito importante e in-

teressante para apoiar os trabalhos do gerente de projetos, porém pode ser extremamente penosa e atrapalhar quando mal utilizada.

O detalhamento excessivo é um problema comumente en-contrado nos cronogramas, e que dificulta muito o seu uso. Se este documento fosse criado apenas uma vez e nunca mais alterado, tudo bem, mas na vida real dos projetos isso é quase impossível. Quanto mais detalhado o cronograma, mais ma-nutenção ele terá.

Para evitar este problema, uma sugestão é utilizar este docu-mento de apoio sem grande detalhamento de itens, tarefas ou níveis. Monte um cronograma mais macro e apenas com fases, milestones e iterações (Sprints), como ilustrado na Figura 5.

Perceba que o cronograma fica mais enxuto, mas sem deixar de fornecer as informações importantes sobre datas e etapas concluídas. Claro que ele só funcionará corretamente se no

início do projeto for divulgado o conteúdo previsto dentro de cada fase e etapa ilustrada no cronograma.

A boa comunicação fica evidente quando há eliminação de duplicidades e de excesso de dados em relatórios de acompanha-mento periódicos. Se você precisar colocar todas as informações do seu projeto, detalhadas ao máximo, em todos os seus relató-rios de situação semanal ou mensal, com certeza houve falhas graves de comunicação inicial, e estas continuam ocorrendo.

Relatórios de situação (Status Report)Dependendo do tamanho, complexidade, valor ou impor-

tância de um projeto, os interessados nele podem querer informações resumidas sobre a sua situação semanalmente, quinzenalmente, mensalmente ou em outra frequência pré-definida. Por isso é de suma importância que a equipe de gerenciamento do projeto esteja preparada para fornecer as informações relevantes sempre que necessário.

O Status Report é um documento geralmente muito requi-sitado e utilizado por gerentes do mundo inteiro. O formato ideal é aquele que consegue condensar todas as informações importantes em uma única página. Principalmente porque o objetivo deste relatório é informar rapidamente qual a situação do projeto, e para isso ele precisa ser objetivo para que quem o receba o leia na íntegra.

A equipe gerencial precisa ser clara e direta com problemas, soluções, dificuldades, fracassos e até mesmo com os sucessos e resultados obtidos. Então não é preciso fazer documentos ex-tensos e cansativos. Informe o que é preciso, e se for necessário, o interessado solicitará uma reunião ou documentos auxiliares para esclarecimentos e maiores detalhes.

Um conteúdo interessante para um Status Report objetivo é apontar a situação geral dos trabalhos completados, podendo ser atrasado, em dia ou adiantado, e a situação financeira do projeto, apontando se os gastos estão dentro do previsto, abaixo ou acima do orçamento.

Como complemento, a equipe gerencial pode colocar a fase em que o projeto se encontra e as últimas realizações. Além do apontamento de riscos para os próximos períodos e eventuais obstáculos que estejam impedindo os trabalhos.

Figura 5. Cronograma com milestones

Page 19: Engenharia de Software - Pontos de função

Edição 44 - Engenharia de Software Magazine 19

gERENCiAMENto dE PRoJEtoS

Todas estas informações são encontradas facilmente com o resultado da aplicação das cerimônias do Scrum como a reu-nião diária, review e retrospectiva. Outra fonte de informação é a análise das tarefas controladas pelo taskboard, e pela situação do projeto mostrado no gráfico Burndown.

Por isso é tão importante seguir as boas práticas de um modelo ou metodologia. Não é só burocracia, são passos na direção de solucionar problemas rotineiros e que podem ser evitados. Seguindo as cerimônias, regras e artefatos do Scrum, naturalmente será gerado insumo para realizar a comunicação do projeto de forma rápida, segura e eficiente.

Reuniões de comitê executivoAlém dos cronogramas e relatórios divulgados para os

stakeholders do projeto, frequentemente há necessidade de apre-sentações executivas para um comitê gestor, como presidentes, diretores e conselheiros.

Mais uma vez os materiais já gerados e utilizados para execu-ção, acompanhamento e comunicação do projeto serão úteis.

Geralmente os gerentes montam apresentações em ferra-mentas como o Microsoft PowerPoint, e resumem os dados do último cronograma atualizado e do último Status Report para compor a apresentação.

Dependendo do projeto a apresentação é focada mais na parte financeira, ou mais na parte de valor agregado e tarefas completadas, não costumando fugir muito disso. Mais uma vez as informações necessárias para a montagem de uma apresentação como esta podem ser coletadas, acompanhadas e resumidas através dos processos descritos neste artigo, ficando mais fácil e rápido resgatá-las no momento oportuno.

ConclusãoTendo a comunicação como principal ferramenta de trabalho

para se atingir o objetivo do projeto, é possível se alcançar excelentes resultados. Principalmente quando se segue boas práticas e teorias reconhecidas pelo mercado, tais como o Scrum, combinando-as com experiências reais em projetos que foram bem sucedidos com a ajuda de uma boa comunicação.

Como foi demonstrado, o Scrum é uma ótima abordagem para melhorar a comunicação de todo o time do projeto durante a execução do mesmo, mostrando claramente quais trabalhos devem ser feitos, ou estão sendo realizados, ou já foram completados.

Os artefatos deste gerenciamento ágil também fornecem informações sobre velocidade e tamanho da equipe, riscos evidentes através de impedimentos ou obstáculos aos traba-lhos do time, além da situação atual do projeto, mostrando a evolução de tarefas completadas.

O Scrum ainda fornece informações para as comunicações mais formais e que precisam seguir linhas mais oficiais de divul-gação, aprovação e registro, tais como cronogramas, relatórios de situação e apresentações executivas para comitês gestores.

Esta união de modelos tradicionais com o ágil mais uma vez se mostra positiva, e quando bem aplicada e complementada, apóia de forma bem dinâmica e objetiva as equipes de geren-ciamento de projetos.

Conforme o uso em conjunto destes dois modelos for cada vez mais aplicado, e os resultados forem expressivamente positivos, mais ficará evidente que não podemos considerar o tradicional melhor que o ágil, e nem tão pouco o ágil melhor que o tradicional.

As equipes de gerenciamento de projetos modernas e que querem sobreviver neste mercado rápido, furioso e muitas vezes cruel, não podem se apegar a apenas um conjunto de conceitos, e precisam se adaptar, observar e acompanhar as mudanças do mercado, das tecnologias e das metodologias.

Nada é perfeito, nem os seres humanos, nem as máquinas e nem tão pouco os processos ou modelos, portanto, quando se tem em mente que se pode unir os melhores pontos positivos de cada abordagem, buscando uma melhor metodologia de aplicação, as chances de sucesso são bem maiores do que apostar todas as fichas em apenas uma delas.

Lembre-se sempre que o objetivo principal do gerenciamento de projetos, independente da abordagem, se resume a entregar um projeto com sucesso. Por isso pense sobre a possibilidade de união de um modelo ágil como o Scrum a um modelo tra-dicional, somando os pontos positivos, subtraindo os pontos negativos, e obtendo como resultado final o sucesso de forma mais controlada, fácil e segura.

Introdução ao Scrum, blog FabioCruz.comwww.fabiorcruz.wordpress.com/outros/introducao

Introdução ao PMBOK®, blog FabioCruz.comwww.fabiorcruz.wordpress.com/pmbok%c2%ae/introducao

Scrum Guide 2011, escrito por Ken Schwaber e Jeff Sutherlandwww.scrum.org/scrumguides

Links

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

seu Feedback

sob

re esta edição

Page 20: Engenharia de Software - Pontos de função

20 Engenharia de Software Magazine - Estimativas de tamanho em projetos de software utilizando pontos de função

Jhoney da Silva [email protected]

Graduando em Ciência da Computação pela Universidade Federal de Viçosa (UFV). Atualmente é Diretor Presidente da em-presa júnior No Bugs (www.nobugs.com.br), Assessor da presidência da Skep Design (www.skepdesign.com) e Diretor Vice-Presidente de O Primeiro Plano. Áreas de interesse: Engenharia de Software, Empre-endedorismo, Gerenciamento de Projetos e Business Intelligence.

José Luis [email protected]

Pós-doutoramento em Tecnologias da In-formação na University of Florida. Doutor em Informática pelo Departamento de In-formática da PUC-Rio. Mestre em Ciências da Computação pelo Departamento de Ci-ência da Computação da UFMG. Atualmen-te é Professor Titular do Departamento de Informática do Centro de Ciências Exatas e Tecnológicas da Universidade Federal de Viçosa-MG. Atua na área de Ciência da Computação, com ênfase em Engenharia de Software e Sistemas de Informação. Áreas de Interesse: Qualidade de Software com Foco em Processos, Engenharia de Software Experimental, Engenharia de Software Apoiada por Ontologias, Enge-nharia de Software Baseada em Agentes, Sistemas de Apoio à Decisão.

De que se trata o artigo?Estimativa de software com derivações em custo, pra-zo e esforço é uma necessidade comum entre as em-presas de TI. Nesse contexto, o objetivo deste artigo é apresentar de forma simples, por meio de exemplos, o uso de um método poderoso para a solução destes problemas recorrentes, a APF (Análise de Ponto de Função).Análise de Ponto de Função é um método de medição do tamanho funcional de um software, com base em operações extraídas dos requisitos funcionais. A partir dessa medição inicial de tamanho, derivam-se outras medidas como, por exemplo, o tempo necessário para desenvolvimento, e uma estimativa inicial de custos. APF tem por definição medir o que o software deve fazer, e não como ele deve ser construído, portanto o processo de medição é fundamentado em uma ava-liação padronizada dos requisitos lógicos do usuário.

Em que situação o tema é útil?Na fase inicial de um projeto, existe a necessida-de de obter o custo, prazo e o esforço de imple-mentação para estabelecimento de contratos de desenvolvimento. Análise de Ponto de Função é um método de medição do tamanho funcional de software que permite fazer essas avaliações com base em informações disponíveis nas fases iniciais dos projetos. O uso do método profissionaliza a avaliação inicial de tamanho, permitindo repeti-ção do processo e aumento do nível de maturidade no gerenciamento de projetos.

ResumoNa fase inicial de um projeto, a necessidade em ob-ter o custo, prazo e o esforço é observado em todas as empresas, pois as mesmas precisam gerar um orçamento para os seus clientes e avaliar uma série de projeções. Este artigo organiza de forma sim-ples e introdutória conhecimentos sobre a Análise de Ponto de Função.Inicialmente não se tem conhecimento de todas as características do produto bem como da sua real dimensão, por esse motivo é necessário utilizar técnicas de extração de requisitos para realizar um levantamento inicial dos mesmos e compreender melhor o problema. Os requisitos são condições, ca-racterísticas ou capacidades necessárias para atingir uma finalidade, categorizados na implementação de sistemas em funcionais e não funcionais como forma de estabelecer critérios de qualidade. Uma vez definidos os requisitos, pode-se então avaliar o tamanho do sistema em termos de suas funcionalidades. Existem vários métodos de esti-mativa, a APF (Análise de Ponto de Função) é uma delas. Esse método não tem como objetivo realizar estimativas de prazo, custo e esforço para imple-mentação de sistema, mas sim avaliar o tamanho de um sistema em termos de suas funcionalidades. Resulta desta avaliação o tamanho funcional do sistema expresso em Pontos de Função (unidade de medida do método). A partir do tamanho fun-cional, podem ser derivadas estimativas adicio-nais, como tempo e custo.

Estimativas de tamanho em projetos de software utilizando pontos de funçãoUm tutorial voltado para micro e pequenas empresas

Engenharia

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

Page 21: Engenharia de Software - Pontos de função

Edição 44 - Engenharia de Software Magazine 21

gERENCiAMENto dE PRoJEtoS

Este artigo apresentará uma visão geral sobre todos os passos necessários para utilização da análise de ponto de função, para a realização de estimativas na fase

inicial de um projeto de desenvolvimento, proporcionando ao leitor uma visão restrita do método, mas suficiente para estimar um projeto em sua fase inicial e, com isso, realizar derivações de acordo com suas necessidades.

A análise por pontos de função surgiu em 1979 na IBM (International Business Machines) e foi desenvolvida por Alan Albrecht. A aceitação foi muito grande, e uma quantidade cada vez maior de pessoas começaram a utilizar o método, resultando na criação do IFPUG (International Function Point Users Group). Hoje o método é mantido e evoluído pelo IFPUG e fundamenta-se em seis passos: 1. Determinar o tipo de contagem;2. Identificar o escopo da contagem e a fronteira da aplicação;3. Contar funções:

a. Tipo dados;b. Tipo transação;

4. Determinar a contagem de pontos de função não ajustados;5. Determinar o valor do fator de ajuste;6. Calcular o número dos pontos de função ajustados.

Como foi dito, a APF é um método que visa medir o tama-nho funcional de um software do ponto de vista do usuário e possui como unidade de medida o ponto de função (PF) (ler Nota do DevMan 1).

N o t a d o D e v M a n 1

Usuário: Em Análise de Ponto de Função, usuário possui um conceito mais amplo: qualquer entidade que se relacione com o sistema ou que produza um ônus ao mes-mo. Ex: Pessoa, aplicação, leis, restrições, etc.

É importante perceber que para a APF o usuário não é somente a pessoa que inte-rage com o sistema.

Possui como base os seguintes objetivos: • Medir as funcionalidades (ler Nota do DevMan 2) imple-mentadas no sistema;• Medir esforço de implementação e de manutenção do softwa-re, independente de tecnologia, ou seja, a APF leva em consi-deração o que o software faz e não como ele é construído;• Simplicidade, o trabalho para aplicar a APF deve ser o mí-nimo possível, ele não deve ser um ônus no desenvolvimento do software.

É importante ter em mente, durante todo o processo da utilização do método de análise de pontos de função, que o usuário é quem define o que faz parte ou não do projeto, di-ferentemente de alguns métodos que levam em consideração

a visão do desenvolvedor, ou seja, uma visão técnica. Na APF o que importa é a visão do negócio e quem possui essa visão é o usuário, lembrando que usuário na APF possui um con-ceito amplo e não é somente a pessoa que irá interagir com o software final.

N o t a d o D e v M a n 2

Funcionalidade: Funcionalidade é o conjunto de tarefas fornecidas pelo sistema para poder realizar transação, processamento e armazenamento dos dados dos usuários.

Determinar o tipo de contagemO primeiro passo para a contagem será determinar qual o tipo

de contagem a ser realizada, como pode ser visto na Figura 1. Na APF existem três tipos de contagem:• Projeto de desenvolvimento; • Projeto de melhoria; • Aplicação.

Figura 1. Passos para a contagem dos pontos de função (VAZQUEZ, 2009)

Este artigo tem por objetivo apresentar a solução de contagem para projeto de desenvolvimento, mas serão apresentadas as diferenças entre elas.

Projeto de desenvolvimentoÉ caracterizado como projeto de desenvolvimento, um novo pro-

jeto desde a fase de extração de requisitos (ler Nota do DevMan 3) até a instalação do mesmo. Neste tipo de projeto são contadas na APF todas as funcionalidades fornecidas aos usuários até a instalação do sistema, ou seja, funcionalidades de conversão (ler Nota do DevMan 4) também são contadas. Só se pode saber todos os requisitos de um sistema após o término do projeto, sendo assim, toda a contagem de um projeto de desenvolvimento pode ser entendida como estimativa e não medição.

Projeto de melhoriaO projeto de melhoria mede todas as funcionalidades no-

vas, modificadas e excluídas de um determinado sistema. Ao término de um projeto de melhoria a aplicação deverá ser contada com o intuito de atualizar o valor em pontos de função da mesma.

Page 22: Engenharia de Software - Pontos de função

22 Engenharia de Software Magazine - Estimativas de tamanho em projetos de software utilizando pontos de função

AplicaçãoEntende-se por contagem do tipo aplicação um software

instalado, ou seja, a contagem após o término de um projeto de desenvolvimento. Neste caso, não se leva em consideração as funções do tipo conversão.

Aplicando o conhecimento – Determinar o tipo de contagem

Neste artigo será realizada a contagem de um projeto simples, extraído da base de projetos da No Bugs - Empresa Júnior do Bacharelado em Ciência da Computação da Uni-versidade Federal de Viçosa.

O foco deste artigo são as derivações dos pontos de função para auxiliar na elaboração da proposta do projeto para o cliente. A sua contagem será de um projeto de desenvolvi-mento, um sistema simples de locação de veículos.

Identificar o escopo da contagemO segundo passo para a contagem é identificar o escopo

da contagem e a fronteira da aplicação, como pode ser visto na Figura 1. Muitas vezes a identificação do escopo e da fronteira da aplicação não são levados tão a sério, principalmente por empresas que não utilizam gerência de projetos no gerenciamento do desenvolvimento de software.

Esta é uma etapa crucial para o andamento do projeto, a definição de um escopo (ler Nota do DevMan 5) errado pode acarretar em prejuízos para o projeto ou até a perda total dele. O escopo define quais funções serão incluídas na contagem, ele pode abranger todas as funcionalidades, apenas as funções utilizadas ou funções específicas.

A fronteira da aplicação é a linha que separa uma apli-cação de outra. Dentro de um escopo de contagem pode existir mais de uma aplicação a ser contada, por isso é importante definir qual é a sua fronteira.

N o t a d o D e v M a n 3

Requisitos: São as necessidades e características que o sistema deve ter para atin-gir as expectativas do cliente. A extração dos requisitos consiste em uma parte crítica na elaboração de uma proposta, ela é parte determinante do sucesso ou fracasso de um projeto.

N o t a d o D e v M a n 5

Escopo do Projeto: Escopo do projeto é o trabalho que precisa ser realizado para entregar um produto, serviço ou resultado com as características e funções especifica-das (PMBOK, 2004), o escopo da contagem é tudo aquilo que deve ser contado.

N o t a d o D e v M a n 4

Funções de Conversão: Para um entendimento considere o exemplo: um sistema A possui uma lista de funcionários cadastrados, o sistema B sendo contado deverá incluir todos esses funcionários em sua base de dados, essa funcionalidade será dispa-rada uma única vez que é durante a instalação do sistema, sendo caracterizada como função de conversão.

Uma sugestão simples para não errar nesta etapa é seguir a regra do IFPUG que é determinar a fronteira da aplicação baseado no Ponto de Vista do Usuário. O usuário define o que ele entende sobre as atribuições do sistema e de cada aplicação.

Considera-se o exemplo apresentado na Figura 2, que mostra três aplicações, AP01, AP02 e AP03, separadas por fronteiras (círculos tracejados) e cada uma dessas aplicações interagem umas com as outras, esta interação é feita a partir do que é chamado de arquivos lógicos, que aparecem na figura como quadrados preenchidos de preto.

Figura 2. Arquivos lógicos e fronteiras das aplicações

Aplicando o conhecimento – Identificar o escopo da contagem

Como foi visto, nesta etapa devemos definir o escopo da contagem e a fronteira da aplicação. No exemplo deste artigo, trata-se de software destinado a uma empresa que realiza locação de automóveis, o sistema é simples e composto por uma única aplicação.

Contar funções do tipo dadosO terceiro passo para a contagem é dividido em duas par-

tes, contar funções do tipo dados e contar funções do tipo transação, como pode ser visto na Figura 1. Funções do tipo dados é o nome designado às funcionalidades fornecidas para o armazenamento de dados na aplicação sendo contada (ler Nota do DevMan 6), são caracterizados como arquivos lógicos e eles podem ser mantidos pela aplicação ou lida de outra, como pode ser visto na Figura 2.

Arquivos lógicos que estão dentro da fronteira da aplicação e mantidos pela mesma são chamados de Arquivos Lógicos

Page 23: Engenharia de Software - Pontos de função

Edição 44 - Engenharia de Software Magazine 23

gERENCiAMENto dE PRoJEtoS

Internos (ALI), já os arquivos lógicos lidos de outra aplicação são chamados de Arquivos de Interface Externa (AIE).

N o t a d o D e v M a n 6

Aplicação Contada: Como visto, um projeto pode ser composto por várias aplica-ções internas que interagem umas com as outras, conforme a Figura 2. Quando um projeto possui mais de uma aplicação, diz-se da aplicação sendo contada a que no momento está sendo analisada, já projetos que possuem apenas uma aplicação, o termo aplicação sendo contada refere-se a todo o projeto.

Arquivo Lógico Interno Grupo lógico de dados persistentes e que são mantidos dentro

da fronteira da aplicação e alterados por meio de processos elementares. Um processo elementar é a menor unidade de atividade significativa para o usuário final (VAZQUEZ,2009). É a menor funcionalidade disponibilizada ao usuário.

Considerando a Figura 2, a AP01 possui três arquivos lógicos internos (ALI). À primeira vista, parecerá que cada tabela do banco de dados da aplicação será um ALI. Essa é uma maneira simples de entender o que seria um arquivo lógico, mas serão mostrados alguns exemplos de que é um erro pensar dessa forma, pois um grupo de tabelas pode ser considerado como um único arquivo lógico, dependendo da forma como é utili-zado pela aplicação.

Exemplos de ALI: • Arquivo de configuração, conexão, segurança (senhas) man-tidos pela aplicação;• Tabelas ou grupos de tabelas do banco de dados mantidas pela aplicação.

Não são exemplos: • Arquivos temporários ou de backup;• Tabelas temporárias ou views.

Arquivo de Interface Externa Grupo lógico de dados persistentes mantidos dentro da fron-

teira de outra aplicação, mas requerido ou referenciado pela aplicação que está sendo contada, ou seja, a aplicação sendo contada acessa os dados presentes neste arquivo lógico, mas o mesmo não está dentro da aplicação que está sendo contada e sim em outra. Nesse caso denomina-se esse arquivo lógico de arquivo de interface externa (AIE).

Considerando a Figura 2, a AP01 referencia arquivos lógicos da AP02 e AP03, estes são os arquivos denominados de AIE.

Exemplos de AIE:• Dados de segurança armazenados em arquivos lógicos e mantidos por aplicações específicas a este fim;• Dados salariais armazenados na aplicação financeira, mas utilizados pela aplicação contada.

Não é exemplo: • Dados armazenados na aplicação sendo contada e utilizados por uma aplicação externa. Nesse caso a sua aplicação possui um ALI e outra aplicação reconhece esses dados vindos de um AIE.

Determinação da complexidade e da contribuição Complexidade é o grau de influência que um arquivo lógico

tem para o tamanho funcional do sistema. A contribuição é a conversão do grau de complexidade em pontos de função. A complexidade é calculada a partir da contagem dos tipos de dados e dos tipos de registro.

Tipos de dados (TD)É um campo não recursivo de dado, único e reconhecido pelo

usuário, em uma visão geral e limitada. Por exemplo, poderiam ser os atributos de uma tabela.

Tipos de Registro (TR)É caracterizado por ser um subgrupo de dados. Em uma análise míope, quando um agrupamento de tabelas

é reconhecido pelo usuário como um único arquivo lógico, ALI ou AIE, a tabela reconhecida pelo usuário é contada e as demais se tornam simplesmente tipos de registro, ou seja, essas tabelas extras não pertencem à visão do negócio, pois o usuário não as reconhece. Mas seus atributos são reconhecidos e, por este motivo, devem gerar um impacto na contagem, sendo denominado subgrupo de dados. Esses campos pertencentes à visão do negócio e reconhecidos pelo usuário são atribuídos aos demais arquivos lógicos que estão relacionados com esses tipos de registro.

Considera-se como exemplo uma especialização, onde a Figura 3 representa essa especialização na visão do usuário, com os seguintes campos: id_func (código de identificação do funcionário), salário, cro (número do registro para dentistas), bolsa (bonificação no salário dos auxiliares).

Figura 3. Especialização na visão do usuário

Na modelagem, foram separados os diferentes tipos de fun-

cionários, como pode ser visto na Figura 4.Neste exemplo contam-se os funcionários como uma ALI ou

AIE, pois como foi apresentado, o usuário não reconhece fun-cionários como entidades diferentes, mas para a modelagem o desenvolvedor optou por separar estes funcionários devido aos atributos que os especializam. Como estas entidades criadas na visão do desenvolvedor possuem atributos reconhecidos pelo

Page 24: Engenharia de Software - Pontos de função

24 Engenharia de Software Magazine - Estimativas de tamanho em projetos de software utilizando pontos de função

usuário, esse grupo de tabelas se constitui em uma ALI ou AIE com três tipos de registro e esses atributos reconhecidos devem ser contados como atributo de funcionários. São contados três tipos de registro, pois todo arquivo lógico é um tipo de registro dele mesmo e os atributos são somados a funcionários, pois somente ele é reconhecido pelo usuário.

É importante perceber que esta solução é adotada uma vez que o usuário enxerga Auxiliar e Dentista como Funcionário, e não como entidades separadas, como pode ser visto na Figura 5. É imprescindível entender que um mesmo problema pode ter uma contagem diferente com visões de negócios diferentes, ou seja, o importante é o ponto de vista do usuário para a APF.

Figura 4. Especialização é um tipo de registro

Figura 5. Visão do Negócio

Tabela de complexidadeA tabela de complexidade é padronizada pelo IFPUG, todos

os usuários do método de análise de pontos de função utilizam os mesmos valores.

Após o entendimento sobre tipo de dados e tipo de registro, os mesmos serão utilizados para definir a complexidade do arquivo lógico. Realiza-se a contagem dos tipos de registro e tipos de dados de cada arquivo lógico, depois se verifica na Tabela 1 o valor de cada um e o intervalo que pertence. Com isso, define-se a ALI ou AIE como sendo de complexidade baixa, média ou alta.

Tipos

de R

egist

ro

Tipos de Dados

< 20 20 – 50 > 50

1 Baixa Baixa Média

2 – 5 Baixa Média Alta

> 5 Média Alta Alta

tabela 1. Complexidade ALI e AIE

Tabela de contribuiçãoA tabela de contribuição é padronizada pelo IFPUG, e todos

os usuários do método de análise de pontos de função utilizam os mesmos valores.

Após identificar a complexidade de cada ALI e AIE do sistema, é possível determinar a contribuição desses para a contagem dos pontos de função.

Após verificar na Tabela 1 a complexidade do ALI ou AIE, a tarefa para estabelecer a contribuição é muito simples, basta saber a complexidade do seu arquivo lógico e se o mesmo é um ALI ou AIE e verificar o valor na Tabela 2.

Tipo de Função Baixa Média Alta

Arquivo Lógico Interno 7 PF 10 PF 15 PF

Arquivo de Interface Externa 5 PF 7 PF 10 PF

tabela 2. Tabela de contribuição

Aplicando o conhecimento – Contar Funções do tipo dados

Para facilitar a identificação dos tipos de arquivos, deve-se elaborar um modelo lógico. Uma dica geral e objetiva é contar um arquivo lógico ALI ou AIE para cada tabela reconhecida pelo usuário, ou seja, se a tabela existe no ponto de vista do usuário ela deve ser contada, caso contrário não deve ser con-tada. Se o usuário não reconhece a tabela, mas reconhece os tipos de dados presentes na mesma, provavelmente essa tabela será um tipo de registro.

A Figura 6 apresenta um esquema para classificar um ar-quivo lógico.

Figura 6. Fluxo para classificação do tipo lógico

Passos para uma estimativa da contagem desta etapaa) Elabora-se um modelo lógico seu projeto, como exempli-

ficado na Figura 7.

Identificam-se todas as tabelas reconhecidas pelo usuário, ou seja, as que fazem parte da visão do negócio, classificando-as como ALI ou AIE (vide Tabela 3).

Page 25: Engenharia de Software - Pontos de função

Edição 44 - Engenharia de Software Magazine 25

gERENCiAMENto dE PRoJEtoS

Figura 7. Modelo lógico

Na Figura 7 as tabelas Usuário, Cliente e Carro foram carac-terizadas como arquivo lógico interno e Aluga foi definida como tipo de registro de Cliente e Carro, pois a mesma não é reconhecida pelo usuário, mas os seus atributos são.

b) Faz-se uma análise da todas as tabelas que não estão na visão do negócio:• Se a tabela não pertence à visão do negócio, mas os seus tipos de dados pertencem, deve-se contá-la como um tipo de registro para cada arquivo lógico relacionado a ela, e atribuir os seus tipos de dados a cada um deles;• Se nem a tabela nem os seus tipos de dados pertencem à visão do negócio, deve ser descartada da contagem.

A tabela Aluga foi considerada um tipo de registro, pois na visão do negócio, os campos hora_aluguel e data_aluguel são reconhecidos pelo usuário e por este motivo eles foram somados aos tipos de dados de Cliente e Carro, conforme a Tabela 4.

Descrição Tipo Qtd. TDs Qtd. TRs

Usuário ALI 4 1

Cliente ALI 7 2

Carro ALI 8 2

tabela 4. Tipo de Dado (TD) e Tipo de Registro (TR)

Quando se tem uma relação entre mais de um arquivo lógico com uma entidade definida como tipo de registro, devem-se identificar todos os atributos reconhecidos pelo usuário pre-sentes nesta entidade tipo de registro e somá-los a todos os arquivos lógicos que se relacionam com esta entidade. Isso é necessário, pois estes atributos influenciam aos demais arqui-vos lógicos e geram impacto no desenvolvimento do projeto.

c) Determinação da complexidade de cada arquivo lógico.Para definir a complexidade basta analisar a quantidade de

tipos de dados mais as quantidades de tipos de registro e con-ferir na Tabela 1. O resultado é apresentado na Tabela 5.

Descrição Tipo

Usuário ALI

Cliente ALI

Carro ALI

tabela 3. Classificação dos arquivos lógicos

d) Determinação da contribuição de cada arquivo lógico e realização a soma de todos.

Para determinar a contribuição basta verificar na Tabela 2 o ponto de função referente a cada complexidade, o resultado é apresentado na Tabela 6.

Descrição Tipo Qtd. TDs Qtd. TRs Complexidade Contribuição

Usuário ALI 4 1 Baixa 7

Cliente ALI 7 2 Baixa 7

Carro ALI 8 2 Baixa 7

Total de Pontos de Função = 21

tabela 6. Contagem das funções do tipo dados

Contar funções do tipo transaçãoO terceiro passo para a contagem é dividido em duas partes,

contar funções do tipo dados e contar funções do tipo transa-ção, como pode ser visto na Figura 1. Agora que foi aprendido como contar funções do tipo dados, pode-se dar continuidade à contagem da aplicação. As funções do tipo transação são as funcionalidades base para o funcionamento do sistema, essas funções são chamadas de processos elementares e são classi-ficadas em Entradas Externas, Saídas Externas e Consultas Externas.

Um processo elementar é a menor unidade de uma função disponível ao usuário. Por exemplo, consultar clientes pode ser entendido como uma função, mas o mesmo não pode ser en-tendido como um processo elementar, uma vez que podem ser realizadas inúmeras consultas diferentes aos clientes: consultar clientes pelo nome, consultar clientes em débito, consultar registro de clientes, e outras mais. Pode-se perceber que cada consulta é uma funcionalidade única e independente. Desta forma, para determinar um processo elementar é necessário identificar todas as funcionalidades únicas e independentes de uma função.

Uma observação importante é que um processo elementar deve ser único. Por exemplo, consultas que diferem umas das outras pela organização dos dados gerados, não podem ser consideradas diferentes.

Entrada Externa (EE)Uma entrada externa é um processo de controle, ela também

realiza o processamento de dados do sistema e direciona o mesmo para atender os requisitos da aplicação. A principal intenção da EE é realizar operações que visam manter (incluir, alterar ou excluir) dados de um ou mais arquivos lógicos inter-nos, realizando processamento, transação e armazenamento de dados dos usuários do software.

Descrição Tipo Qtd. TDs Qtd. TRs Complexidade

Usuário ALI 4 1 Baixa

Cliente ALI 7 2 Baixa

Carro ALI 8 2 Baixa

tabela 5. Complexidade

Page 26: Engenharia de Software - Pontos de função

26 Engenharia de Software Magazine - Estimativas de tamanho em projetos de software utilizando pontos de função

Uma EE deve ser única e não necessitar de ações anteriores e nem sucessores. Por exemplo, no envio de um e-mail, escrever o destinatário, o assunto e o corpo do e-mail não podem ser entendidos como EE, pois não se constituem uma operação completa, mas o conjunto de todas estas, e clicar no botão de envio é que se caracteriza como uma EE.

Exemplos de Entrada Externa: • Transações destinadas a manter ALI, incluir funcionário, excluir funcionário, alterar funcionário e etc.;• Operações;• Processos destinados a realizar registros, por exemplo, em um sistema de ponto eletrônico o usuário registra entrada e saída.

Não são exemplos de Entrada Externa:• Telas de filtro;• Preenchimento de campos de dados;• Telas de login;• Gerar relatórios.

De modo geral, EEs possuem nomes característicos, como incluir, alterar, salvar, excluir, editar, encaminhar, submeter e registrar, dentre outros.

Saída Externa (SE)Processo elementar destinado à apresentação de informação

ao usuário ou a outra aplicação externa que utilize cálculos para processar essas informações.

A principal intenção de uma SE é apresentar informação para o usuário a partir de lógica de processamento, ou seja, as in-formações apresentadas devem passar por um processamento, elas não devem ser simplesmente uma consulta simples. Este processamento pode ter como objetivo manter ALIs ou alterar o comportamento do sistema.

Exemplos de Saída Externa: • Tela para liberar acesso (tela de login), sendo os dados da transação criptografados;• Relatórios financeiros, supondo esses gerados por cálculos;• Consultas complexas com processamento de dados a partir de cálculos; • Apresentação de gráficos com dados processados a partir de cálculos.

Não são exemplos de Saída Externa: • Telas de filtro;• Consultas simples, sem processamento de dados utilizando cálculos.

Consulta Externa (CE)Processo elementar que apresenta informação ao usuário ou

a outra aplicação externa por meio de recuperação simples. Uma CE tem como principal intenção apresentar informações ao usuário por meio de uma simples recuperação de dados

de uma ALI e/ou AIE. Esse processamento não deve possuir lógica matemática, nem qualquer tipo de cálculo, não deve gerar dados derivados e nem alterar o comportamento do sistema. A CE é uma consulta simples e direta, com o retorno da informação requisitada pelo usuário.

Exemplos de Consulta Externa: • Consultar clientes pelo nome;• Apresentar dados em formato gráfico a partir de recuperação simples.

Não são exemplos de Consulta Externa: • Relatórios financeiros, gerados a partir de cálculos;• Telas de filtro.

Determinação da complexidade e da contribuiçãoComplexidade é o grau de influência que um processo elemen-

tar tem para o tamanho funcional do sistema. A contribuição é a conversão do grau de complexidade em pontos de função.

Essa complexidade é calculada a partir da contagem dos tipos de dados e dos arquivos referenciados.

Tipos de dados (TD)É um campo não recursivo de dado, único e reconhecido pelo

usuário, ou seja, é cada campo preenchido ou apresentado ao usuário. Por exemplo, em um formulário os campos nome, CPF, endereço, o botão de confirmação, uma janela de mensagem de erro, dentre outros, são tipos de dados. Já em um relatório, o código do produto, o nome, a descrição, o valor, são tipos de dados. Em um gráfico, o raciocínio é o mesmo, conta-se um tipo de dado para o nome do produto, um para a quantidade e um para o valor, no total tem-se três tipos de dados neste relatório, como pode ser visto na Figura 8.

Figura 8. Apresentação de relatório gráfico

Arquivo Referenciado (AR)Um arquivo referenciado é todo arquivo lógico lido, pode ser

um ALI ou AIE, ou todo arquivo lógico mantido, nesse caso só pode ser um ALI. Um tipo de registro não é um arquivo lógico, ele pertence a um arquivo lógico. Não se deve contar tipos de registro e arquivos lógicos lidos várias vezes. Esses são contados apenas uma única vez.

Page 27: Engenharia de Software - Pontos de função

Edição 44 - Engenharia de Software Magazine 27

gERENCiAMENto dE PRoJEtoS

Tabela de complexidadeA tabela de complexidade é padronizada pelo IFPUG, todos

os usuários do método de análise de pontos de função utilizam os mesmos valores.

Após o entendimento sobre tipo de dado e arquivo referencia-do, pode-se utilizá-lo para definir a complexidade do processo elementar. Realiza-se a contagem dos tipos de dados e dos arquivos referenciados de cada processo elementar, depois verifica-se na Tabela 7 ou na Tabela 8 o valor de cada um e o intervalo a que ele pertence, com isso definindo a EE, SE ou CE como sendo de complexidade baixa, média ou alta.

Arqu

ivos R

efer

encia

dos Tipos de Dados

< 5 5 – 15 > 15

< 2 Baixa Baixa Média

2 Baixa Média Alta

> 2 Média Alta Alta

tabela 7. Complexidade Entrada Externa (EE)

Arqu

ivos

Refe

renc

iado

s

Tipos de Dados

< 6 6 – 19 > 19

< 2 Baixa Baixa Média

2 – 3 Baixa Média Alta

> 3 Média Alta Alta

tabela 8. Complexidade Saída Externa (SE) e Consulta Externa (CE)

É importante perceber que a Tabela 7 é destinada a EE e a Tabela 8 a SE e CE. Essa diferença é importante uma vez que processos elementares destinados a apresentar informação, possuem nor-malmente mais tipos de dados e referenciam mais arquivos.

Tabela de contribuiçãoA tabela de contribuição é padronizada pelo IFPUG, todos os

usuários do método de análise de pontos de função utilizam os mesmos valores.

Após identificar a complexidade de cada processo elementar do sistema, é possível determinar a contribuição desses para a contagem dos pontos de função.

Após a definição da complexidade do seu processo elementar, definir a sua contribuição é muito simples, basta saber a com-plexidade do seu processo elementar e se o mesmo é uma EE, SE ou CE e utilizar o valor correspondente na Tabela 9.

Tipo de Função Baixa Média Alta

Entrada Externa 3 PF 4 PF 6 PF

Saída Externa 4 PF 5 PF 7 PF

Consulta Externa 3 PF 4 PF 6 PF

tabela 9. Tabela de Contribuição

Aplicando o conhecimento – Contar funções do tipo transação

Para finalizar o terceiro passo, deve-se determinar a conta-gem das funções do tipo transação.

O fluxo da Figura 9 foi idealizado para facilitar o entendimento do processo de determinação dos tipos de processo elementar.

Esta é uma visão geral, o importante é saber qual a finalidade do seu processo elementar. Por exemplo, um cadastro é uma EE que pode apresentar informações ao final do processamento que não o torna uma CE ou SE, pois sua finalidade poderia ser cadastrar.

Outra dica, quando não se reconhece a classificação de uma função de transação, pode ser que esta ainda não seja um processo elementar, cabe então reconhecer todos os proces-sos elementares no interior desta função antes de verificar a classificação em Entrada Externa (EE), Consulta Externa (CE) ou Saída Externa (SE).

Como primeiro passo para a contagem, deve-se identificar todos os processos elementares e classificá-los quanto ao seu tipo, conforme a Tabela 10.

Determinam-se então os tipos de dados e os arquivos refe-renciados (vide Tabela 11). Neste passo é necessário analisar cada processo elementar e definir seus tipos de dados e os arquivos que referencia.

Este passo é mais relevante quando os tipos de dados ou os arquivos referenciados estão na fronteira da mudança da complexidade. Longe da fronteira, erros neste ponto não irão influenciar na contagem.

Verifica-se a complexidade, após definir os tipos de dados e os arquivos referenciados, determinando a complexidade de

Figura 9. Fluxo para classificação do processo elementar

Page 28: Engenharia de Software - Pontos de função

28 Engenharia de Software Magazine - Estimativas de tamanho em projetos de software utilizando pontos de função

Descrição Tipo

Incluir Cliente EE

Excluir Cliente EE

Alterar Cliente EE

Incluir Usuário EE

Excluir Usuário EE

Alterar Usuário EE

Incluir Automóveis EE

Excluir Automóveis EE

Alterar Automóveis EE

Registrar Locação EE

Finalizar Locação EE

Login (com criptografia) SE

Consulta clientes por nome CE

Consulta carros alugados CE

Consulta data do aluguel CE

Consulta clientes com carro alugado CE

Consulta carro mais alugado CE

Consulta cliente que mais aluga CE

tabela 10. Tipos dos processos elementares

cada processo elementar consultando a Tabela 7 ou Tabela 8. O resultado pode ser visto na Tabela 12.

A seguir, determina-se a contribuição de cada processo ele-mentar e realiza-se a soma de todos, conforme Tabela 13.

Para determinar a contribuição basta verificar na Tabela 9 o ponto de função referente a cada complexidade.

Descrição Tipo Qtd. TDs Qtd. ARs

Incluir Cliente EE 6 1

Excluir Cliente EE 3 1

Alterar Cliente EE 6 1

Incluir Usuário EE 3 2

Excluir Usuário EE 3 2

Alterar Usuário EE 3 1

Incluir Automóveis EE 7 2

Excluir Automóveis EE 3 2

Alterar Automóveis EE 7 1

Registrar Locação EE 3 2

Finalizar Locação EE 4 2

Login (com criptografia) SE 4 1

Consulta clientes por nome CE 3 2

Consulta carros alugados CE 3 2

Consulta data do aluguel CE 3 2

Consulta clientes com carro alugado CE 3 3

Consulta carro mais alugado CE 3 3

Consulta cliente que mais aluga CE 3 2

tabela 11. Tipos de Dados (TD) e Arquivos Referenciados (AR)

Descrição Tipo Qtd. TDs Qtd. ARs Complexidade

Incluir Cliente EE 6 1 Baixa

Excluir Cliente EE 3 1 Baixa

Alterar Cliente EE 6 1 Baixa

Incluir Usuário EE 3 2 Baixa

Excluir Usuário EE 3 2 Baixa

Alterar Usuário EE 3 1 Baixa

Incluir Automóveis EE 7 2 Média

Excluir Automóveis EE 3 2 Baixa

Alterar Automóveis EE 7 1 Baixa

Registrar Locação EE 3 2 Baixa

Finalizar Locação EE 4 2 Baixa

Login (com criptografia) SE 4 1 Baixa

Consulta clientes por nome CE 3 2 Baixa

Consulta carros alugados CE 3 2 Baixa

Consulta data do aluguel CE 3 2 Baixa

Consulta clientes com carro alugado CE 6 3 Média

Consulta carro mais alugado CE 3 3 Baixa

Consulta cliente que mais aluga CE 3 2 Baixa

tabela 12. Complexidade

Descrição Tipo Qtd. TDs Qtd. ARs Complexidade Contribuição

Incluir Cliente EE 6 1 Baixa 3

Excluir Cliente EE 3 1 Baixa 3

Alterar Cliente EE 6 1 Baixa 3

Incluir Usuário EE 3 2 Baixa 3

Excluir Usuário EE 3 2 Baixa 3

Alterar Usuário EE 3 1 Baixa 3

Incluir Automóveis EE 7 2 Média 4

Excluir Automóveis EE 3 2 Baixa 3

Alterar Automóveis EE 7 1 Baixa 3

Registrar Locação EE 3 2 Baixa 3

Finalizar Locação EE 4 2 Baixa 3

Login (com criptografia) SE 4 1 Baixa 4

Consulta clientes por

nomeCE 3 2 Baixa 3

Consulta carros

alugadosCE 3 2 Baixa 3

Consulta data do aluguel CE 3 2 Baixa 3

Consulta clientes com

carro alugadoCE 6 3 Média 4

Consulta carro mais

alugado CE 3 3 Baixa 3

Consulta cliente que

mais alugaCE 3 2 Baixa 3

Total de Pontos de Função = 57

tabela 13. Contagem das funções do tipo transação

Page 29: Engenharia de Software - Pontos de função

Edição 44 - Engenharia de Software Magazine 29

gERENCiAMENto dE PRoJEtoS

Pontos de função não ajustadosO quarto passo para a contagem é determinar a contagem dos

pontos de função não ajustados, como pode ser visto na Figura 1. Neste ponto entende-se a relação de um arquivo lógico com um processo elementar.

Na Figura 10 tem-se um exemplo de uma aplicação AP01 com um ALI e uma série de processos elementares. Ela realiza uma leitura de um arquivo lógico da aplicação AP02. Esse arquivo lógico localiza-se fora da fronteira da aplicação AP01 e deve ser classificado como um AIE.

Figura 10. Relação arquivo lógico e processo elementar

Agora se deve realizar a contagem dos pontos de função não ajustados. Esta análise é simples. Deve-se apenas somar as contribuições das funções do tipo dado com as contribuições das funções do tipo transação.

Aplicando o conhecimento – Pontos de função não ajustados

Para realizar a determinação dos pontos de função não ajus-tados, deve-se somar as contribuições de todas as funções do tipo dado e do tipo transação (ver Tabela 14).

Descrição Contribuição

Funções do tipo dado 21 PF

Funções do tipo transação 57 PF

Total de Pontos de Função Não Ajustados = 78 PF

tabela 14. Pontos de função não ajustados

Determinar o fator de ajusteO quinto passo para a contagem é determinar o valor do fator

de ajuste, como pode ser visto na Figura 1.Para o quinto passo deve-se determinar o fator de ajuste, mas

essa análise não será feita e será atribuído o valor do fator de ajuste como um. A adoção desse valor será melhor compreen-dida no exemplo apresentado.

O fator de ajuste, pelo seu caráter subjetivo e o impacto ge-rado na contagem, podendo ser de +35% a -35%, fez com que vários utilizadores do método de análise de ponto de função ignorassem essa etapa antes mesmo do IFPUG classificá-la como opcional em 2002.

Aplicando o conhecimento – Fator de ajusteNão será feita análise para esta etapa, uma vez que a mesma

é instituída opcional pelo IFPUG e pode aumentar o erro na estimativa.

Para o nosso exemplo, deve-se considerar:• Valor de ponto de função não ajustado (VAF) = 1;

Realizar o cálculo dos pontos de função ajustadosO sexto e último passo para a contagem é calcular os pontos

de função ajustados, como pode ser visto na Figura 1.Esta é a etapa final para obter o tamanho funcional do seu

projeto. Existem três tipos de contagem, como já foi dito: Projeto de Desenvolvimento, Projeto de Melhoria e Aplicação.

Como este artigo visa à contagem de projeto de desenvolvimen-to, não serão tecidos detalhes dos demais tipos de contagem.

Para determinar os pontos de função ajustados para projeto de desenvolvimento é necessário aplicar a seguinte fórmula apresentada na Tabela 15.

DFP = (UFP + CFP) x VAF

Onde:

DFP: Número de pontos de função do projeto de desenvolvimento;

UFP: Número de pontos de função não ajustados das funções disponíveis aos usuários após a

instalação;

CFP: Número de pontos de função não ajustados das funções de conversão, ou seja, as funções

transitórias que são inutilizadas após a instalação;

VAF: Valor do fator de ajuste.

tabela 15. Tabela da fórmula dos pontos de função de projeto de desenvolvimento

Aplicando o conhecimento – Pontos de função ajustadosTodos os valores estimados até este ponto serão utilizados para

determinar os pontos de função ajustados. Para terminar a conta-gem do projeto de desenvolvimento, deve-se substituir os valores estimados até aqui na fórmula apresentada na Tabela 16.

A aplicação contada não possui funções de conversão, por este motivo foi somado zero às funções disponíveis após a instalação.

Assim, a aplicação contada possui um tamanho funcional estimado em 78 pontos de função.

DFP = (UFP + CFP) x VAF

Onde:

DFP: Número de pontos de função do projeto de desenvolvimento;

UFP: Número de pontos de função não ajustados das funções disponíveis após a instalação;

CFP: Número de pontos de função não ajustados das funções de conversão;

VAF: Valor do fator de ajuste.

Resultado:

DFP = (78 + 0) x 1

DFP = 78 Pontos de Função

tabela 16. Valor total dos Pontos de Função ajustados

DerivaçõesNeste ponto já se possui o tamanho funcional da aplicação,

agora serão apresentadas as derivações que podem ser reali-zadas com ele.

Page 30: Engenharia de Software - Pontos de função

30 Engenharia de Software Magazine - Estimativas de tamanho em projetos de software utilizando pontos de função

Até aqui se utilizou a APF na perspectiva de produto, agora pode-se fazer uma análise na perspectiva de processo (esforço, custo e prazo). Independente da derivação, o importante é possuir um histórico de projeto, só assim será possível estimar esforço, custo e prazo de forma satisfatória. Na primeira vez que aplicar estas estimativas o erro será grande, mas conforme for ampliando a base de históricos de projetos, o erro tenderá a diminuir.

Esforço Para calcular o esforço é necessário conhecer quantos pontos

de função são produzidos em uma hora e saber quantas horas de trabalho são consideradas em um mês na empresa.

A estimativa de esforço pode ser: • Pontos de Função por Homem Mês (PF/HM);• Pontos de Função por Hora (PF/H).

Tem-se por base que a taxa de produtividade é medida em hora por ponto de função (H/PF). Cada linguagem ou tecno-logia demandam um esforço diferente, essas características não influenciam nos pontos de função, mas sim no esforço que demanda produzir cada ponto de função.

Existem vários editais para licitação de desenvolvimento de sistemas, que incluem tabelas de produtividade mínima no desenvolvimento de projetos.

A Tabela 17 foi retirada do edital da ACINE (Agência Nacio-nal do Cinema), que define a produtividade mínima de PF que a empresa deverá produzir por linguagem no tempo definido. Por exemplo, uma empresa que concorrer a esse edital, deverá ter competência de produzir no mínimo um PF a cada quinze horas na linguagem Java.

Desenvolvimento e manutenção de sistemas

Tecnologia Produtividade Mínima

Java 15 h/PF

ASP (Vbscript e Javascript) 10 h/PF

PHP 11 h/PF

JSP 13 h/PF

HTML 7 h/PF

Cold Fusion 11 h/PF

Delphi 9 h/PF

Crystal reports 9 h/PF

PL/SQL 9 h/PF

Visual Basic 9 h/PF

tabela 17. Tabela de produtividade mínima ACINE

Utilizar bases de editais (sem o conhecimento sobre o pro-jeto) ou de outras empresas, constitui um risco muito grande, pois a produtividade é intrínseca de cada empresa, pois essas possuem funcionários e processos diferenciados.

CustoA estimativa do custo de um projeto é a informação primor-

dial na hora de elaborar uma proposta, este não pode exceder

às expectativas do cliente e nem ter um valor inferior ao ne-cessário para o funcionamento da empresa.

Como na determinação do esforço, o custo também é estima-do a partir de dados da empresa, neste caso é necessário ter o conhecimento do custo da hora da equipe de desenvolvimento ou o valor de um ponto de função para sua empresa.

O custo de um Ponto de Função é dado por: • Custo por hora vezes a quantidade de horas necessárias para produzir um Ponto de Função (C/H x H/PF).

Prazo O prazo é um fator crítico a ser determinado pois, para

estimativas, pode-se supor que o prazo é uma função linear com o recurso, o que é uma suposição falha. Por exemplo, se um projeto desenvolvido por dois desenvolvedores gasta um prazo de dois meses, alocar mais dois desenvolvedores para o projeto não necessariamente implica que o mesmo irá durar apenas um mês.

A análise empírica mostra que essa linearidade não existe, uma mulher demora nove meses para gerar um bebê, nove mu-lheres não geram um bebê em um mês (VAZQUEZ, 2009).

Quanto maior o tamanho funcional de um projeto, maior será o prazo e maior será o erro. Para projetos pequenos o erro é aceitável, mas novamente volta-se ao ponto de que a melhor maneira de evitar esses erros é possuir uma base histórica dos projetos desenvolvidos.

O prazo é derivado da seguinte forma:• Prazo é a relação de esforço por recurso (Prazo= Esforço/Recurso).

Aplicando o conhecimento – Derivações Até aqui definiu-se o tamanho funcional do sistema exemplo,

agora utilizando de um dos benefícios do método de análise de ponto de função que é a realização de derivações a partir da quantidade de pontos de função estimados, serão realizadas derivações quanto ao esforço, custo e prazo necessários para o desenvolvimento do software.

Esforço A aplicação de exemplo foi estimada em 78 pontos de fun-

ção. Será considerada uma empresa que possui uma taxa de produtividade mínima em Java de 5 H/PF e com uma carga de trabalho de 130 horas por homem-mês. Essa empresa gastaria 390 horas para produzir o sistema, ou três meses, conforme a Tabela 18.

CustoSuponha que a hora de trabalho custe R$ 20,00 e, como é

produzido um ponto de função a cada cinco horas, o valor do ponto de função é de R$ 100,00.

Estima-se que o esforço necessário para produzir a aplicação de exemplo é de 390 horas, e a mesma possui 78 pontos de função.

Pode-se assim inferir que a aplicação tem um custo de apro-ximadamente R$ 7.800,00, conforme a Tabela 19.

Page 31: Engenharia de Software - Pontos de função

Edição 44 - Engenharia de Software Magazine 31

gERENCiAMENto dE PRoJEtoS

Esforço = H/PF x Tamanho do projeto em PF

Onde:

H: Hora;

PF: Pontos de função.

Resultado:

Esforço = 5 x 78

Esforço = 390 horas

tabela 18. Valor total em horas do esforço para desenvolver o projeto

Custo = Tamanho do projeto em PF x Custo do Ponto de Função

Resultado:

Custo = 78 x R$ 100,00

Custo = R$ 7.800,00

tabela 19. Custo total para elaboração do projeto

PrazoFoi definido que o esforço necessário para produzir a aplica-

ção é de 390 horas ou três meses. Suponha que esta empresa possua dois funcionários habilitados a desenvolver o projeto na tecnologia estabelecida.

Utilizando dessas informações conclui-se que o prazo para a entrega do sistema será de um mês e meio, conforme a Tabela 20.

Prazo = Esforço / Recurso

Prazo = 3 / 2

Prazo = 1 mês e 15 dias

tabela 20. Prazo total para elaboração do projeto

Considerações finaisA APF pode ser usada para estimar desenvolvimento, melho-

ria e aplicação. Todas as formas de estimativa e derivações são referentes à fase de construção, mas é de conhecimento que na produção de um sistema, têm-se ainda as fases de concepção, elaboração e transição. É importante dizer que as dicas que serão passadas não possuem nenhuma ligação com o método de APF, mas sim uma observação de como extrapolar os va-lores derivados de esforço, prazo e custo em todo o processo de produção do sistema.

Embora o ciclo de vida varie muito por empresas e projetos diferentes, um projeto médio, possui a distribuição de esforço e programação como apresentado na Tabela 21.

Concepção Elaboração Construção Transição

Esforço 5% 20% 65% 10%

Programação 10% 30% 50% 10%

tabela 21. Distribuição de esforço e programação em projetos de médio porte (Philippe Kruchten, 2003)

Para extrapolar os resultados obtidos nas derivações da APF, basta fazer uma regra de três simples. Se o esforço destinado à

fase de construção é de 65% e você possui o esforço e custo para o desenvolvimento desta fase, pode-se extrapolar um de cada vez para todas as fases, depois são feitos ajustes necessários de acordo com cada empresa.

Utilizando dos valores obtidos neste artigo, segue o exem-plo para extrapolar o esforço para a construção do sistema, no esforço para a realização da fase de concepção do projeto, conforme a Tabela 22.

Extrapolando Esforço Construção em Esforço Iniciação

65% - 390 (horas)

05% - X (horas)

X = 30 horas

tabela 22. Esforço total extrapolado para realização da fase de concepção

O prazo pode ser obtido a partir do esforço necessário para produzir e dos recursos disponíveis.

Assim, deve-se realizar análise histórica dos projetos e cons-truir uma tabela específica para cada organização, mas obser-vando cada projeto, pois ajustes serão sempre necessários.

1. 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

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

3. IFPUG(International Function Point Users Group). Disponível em: <http://www.ifpug.org>.

4. BFPUG(Brazilian Function Point Users Group). Disponível em: <http://www.bfpug.com.br>.

5. PMI (Project Management Institute). Um Guia do Conjunto de Conhecimentos em Gerenciamentos de Projetos (PMBOK). Estados Unidos: PMI Publications, 2004

6. DEKKERS, C. Pontos de Função e Medidas - O Que é um Ponto de Função?. QAI Journal, dez. 1998

7. DEKKERS, C. Desmistificando Pontos de Função: Entendendo a Terminologia. IT Metrics Strategies, out. 1998

8. HAZAN, Cláudia – Análise de Pontos por Função – agosto , 2001 . disponível em http://www.inf.ufes.br/~falbo/download/aulas/es-g/2005-1/APF.pdf.

9. ACINE. Anexo XVIII – Tabelas de produtividade mínima, 2008. Disponível em: <http://www.ancine.gov.br/media/concorrencia0012008/AnexoXVIII.pdf>.

10. Philippe Kruchten. The Rational Unified Process: An Introduction. Boston, Editora Pearson Education, 2003

Referências

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

seu Feedback

sob

re esta edição

Page 32: Engenharia de Software - Pontos de função

32 Engenharia de Software Magazine - CMMI – Uma visão Geral

Lenildo [email protected]

É analista de sistemas e analista de testes. Atualmente está cursando mestrado no centro de informática da UFPE em enge-nharia de software com ênfase em testes e qualidade de software.

De que se trata o artigo?Demonstrar, através de uma visão geral, como o mo-delo de qualidade CMMI pode contribuir no processo de desenvolvimento de software. Você conhecerá os conceitos, características, objetivos e representações referentes a este modelo de qualidade.

Em que situação o tema é útil?Nos projetos de desenvolvimento de software, que adotam políticas de qualidade, sobretudo quando se deseja buscar mercados externos ou expandir seus clientes internos aumentando a satisfação dos mesmos.

ResumoEste artigo tem como propósito apresentar uma visão geral sobre maturidade dos proces-sos de desenvolvimento de software, visando a qualidade do produto gerado e a consequente satisfação dos seus clientes, através do mode-lo de referência CMMI. Trata-se de um modelo internacional, desenvolvido pelo Software En-gineering Institute – SEI, que pode dar suporte às organizações que procuram aprimorar seus processos de desenvolvimento de software, tornando-se assim mais competitivas.

CMMI – Uma visão GeralUm modelo de maturidade para o processo de construção de software

Engenharia

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

Ao longo dos últimos anos, tanto as empresas de desenvolvi-mento de software quanto

seus clientes têm se preocupado com problemas que são comumente identifi-cados durante a execução dos projetos, tais como: prazos e orçamentos não cumpridos, insatisfação de ambos os lados, produtos com erros, entre outros. No entanto, há algum tempo, existe um consenso na Engenharia de Software de que estes problemas estão, em grande parte, relacionados ao fato de que o desenvolvimento de sistemas é muitas vezes realizado de forma “artesanal”, ou através de métodos improvisados pelos desenvolvedores. Tais métodos dependem mais do talento individual do desenvolvedor que de uma sólida formação que oriente suas atividades.

Page 33: Engenharia de Software - Pontos de função

Edição 44 - Engenharia de Software Magazine 33

PRoCESSo

Um processo definido e controlado pode garantir um produto de qualidade, sobretudo do ponto de vista do desenvolvi-mento de software. O Capability Maturity Model Integration, ou CMMI, como é chamado, é um modelo de referência que provê uma orientação para o desenvolvimento de processos de software, procurando nortear a organização no sentido de implementar a melhoria contínua do processo de software (ler Nota do DevMan 1).

N o t a d o D e v M a n

CMMI e MPS.BR: Desde a década de 1990, vários modelos de maturidade de processos vêm sendo propostos com o objetivo de auxiliar na melhoria da qualidade dos processos de software adotados pelas organizações. Entre eles podemos citar os modelos CMM, Spice – ISO/IEC 15504, CMMI e mais recentemente, no Brasil, o MPS-BR. Atualmente as organizações que desenvolvem software estão atentas às neces-sidades da adoção de processos de desenvolvimento de software melhor definidos, e observam-se movimentos dessas organizações em busca de certificações de qualida-de de processos de software, notadamente as certificações CMMI e/ou MPS.BR.

O MPS.BR define um modelo de melhoria e avaliação de processos de software com o foco nas pequenas e médias empresas brasileiras, de modo a atender as suas necessidades de negócio e ser reconhecido nacional e internacionalmente como um modelo aplicável à indústria de software. Ele estabelece um modelo de processos de software e um método de avaliação de processos de modo a garantir que o MPS.BR está sendo empregado de forma coerente com as suas definições.

Para isso, o modelo contempla duas representações que permitem à empresa desenvolvedora do software utilizar o caminho de melhoria mais adequado. Estas representações estão divididas em níveis de maturidade, priorizando de forma lógica as ações a serem realizadas. Assim, quanto maior o nível, maior a maturidade da organização, o que pode se traduzir em maior qualidade do produto final, com maior previsibilidade em cronogramas e orçamentos.

O objetivo do CMMI é servir de guia para a melhoria de pro-cessos na organização, assim como auxiliar a habilidade dos profissionais em gerenciar o desenvolvimento e manutenção de produtos ou serviços de software, além de proporcionar a visibilidade apropriada do processo de desenvolvimento para todos os envolvidos no projeto. Isto é particularmente impor-tante em grandes projetos que possuem equipes envolvendo dezenas de pessoas, pois, sem o apoio desses modelos de maturidade de processos de software como o CMMI, torna-se ainda mais difícil manter o controle do projeto.

Com a utilização de níveis, o CMMI descreve um caminho evolutivo recomendado para uma organização que deseja melhorar os processos utilizados para a construção de seus produtos e serviços. Quando uma organização atinge um nível de maturidade, considera-se que seus processos alcançaram uma determinada capacidade, ou seja, tem mecanismos que garantem a repetição sucessiva de bons resultados futuros

relacionados principalmente à qualidade, custos e prazos. Com isso, o CMMI pode ser aplicado em uma organização em etapas consecutivas, representando a ideia de maturidade (avaliada por estágios) da organização, ou de maneira contínua, onde é medida a capacidade em processos individuais, conforme ilustrado na Figura 1.

Figura 1. Capacidade e Maturidade Organizacional

O CMMI possui cinco níveis de maturidade, onde no primeiro a empresa desenvolve sistemas baseando-se apenas na expe-riência dos recursos humanos da organização; e no último, há um processo organizado e flexível, com um planejamento efi-ciente e continuamente aprimorado. Este modelo define áreas de processo, sendo cada uma com suas metas e práticas, e para que uma empresa alcance níveis de maturidade superiores, deverá cumprir estas metas, compreendidas em cada área de processo (Process Area – PA). As PAs funcionam como uma coleção de práticas que representam o nível de maturidade.

Representações do CMMIO CMMI possui duas representações: a estagiada e a contí-

nua. A representação estagiada permite que as organizações melhorem um conjunto de processos inter-relacionados e, de forma incremental, tratem sucessivos conjuntos de PAs. A re-presentação contínua, por sua vez, permite que as organizações melhorem de forma incremental os processos correspondentes a uma ou mais PAs, sendo a empresa responsável por selecio-nar em que áreas de processo ela será avaliada.

A seguir apresentamos uma descrição para estas representações:• Representação por Estágios: Esta representação preocupa-se com os processos da organização como um todo, oferecendo uma abordagem estruturada e sistemática para a melhoria de um estágio por vez. Atingir um estágio significa que uma estrutura de processo adequada foi estabelecida como base para o próximo estágio.

As áreas de processo (PAs) são organizadas por níveis de maturidade. Elas vão do nível “inicial” (nível 1) ao nível “em otimização” (nível 5), e sugerem uma ordem para a implemen-tação das áreas de processo. Cada nível possui várias PAs, e cada PA possui objetivos, práticas genéricas e específicas, assegurando assim uma base de melhoria adequada para o próximo nível de maturidade.

Page 34: Engenharia de Software - Pontos de função

34 Engenharia de Software Magazine - CMMI – Uma visão Geral

Na representação por estágios, quando uma organização atin-ge as práticas necessárias para estar em um nível, subentende-se que ela atingiu todos os requisitos necessários dos níveis imediatamente anteriores.

Os níveis estão descritos da seguinte forma:a) Nível 1 – Inicial. É o nível de maturidade CMMI mais baixo.

Em geral, as organizações desse nível têm processos imprevi-síveis que são pobremente controlados e reativos. Neste nível de maturidade não há PAs, os processos são normalmente im-previsíveis e caóticos, e a organização geralmente não fornece um ambiente estável;

b) Nível 2 – Gerenciado. Neste nível, os projetos da organi-zação têm a garantia de que os requisitos são gerenciados, planejados, executados, medidos e controlados. Quando essas práticas são adequadas, os projetos são executados e controla-dos de acordo com o planejado. O gerenciamento de projetos é o foco principal deste nível;

c) Nível 3 – Definido. Nível em que todos os objetivos especí-ficos e genéricos atribuídos para os níveis de maturidade 2 e 3 foram alcançados, e os processos são mais bem caracterizados, alcançando melhor entendimento, sendo descritos em padrões, procedimentos, ferramentas e métodos. O foco neste nível é a padronização do processo;

d) Nível 4 - Quantitativamente Gerenciado. Neste nível, os objetivos específicos e genéricos atribuídos para os níveis de maturidade 2, 3 e 4 foram alcançados e os processos são medidos e controlados. O foco neste nível é o gerenciamento quantitativo;

e) Nível 5 – Em Otimização. É o nível mais alto de maturidade CMMI, onde uma organização atinge todos os objetivos específi-cos atribuídos para os níveis de maturidade 2, 3, 4 e 5. Neste nível os processos têm como foco principal a melhoria contínua.

• Representação Contínua: Na representação contínua, o foco ou componentes principais são as áreas de processo. Existem metas e práticas de dois tipos: específicas a uma determinada área de processo, e genéricas, aplicáveis indistintamente a todas as áreas de processo.

Nesta representação, as áreas de processo são agrupadas por categorias afins que reúnem caminhos de melhoria indicando a evolução para cada uma destas áreas.

A representação contínua contempla quatro disciplinas: Ge-rência de Processos, Gerência de Projeto, Engenharia e Suporte. As áreas de processo relativas à disciplina de Gerência de Pro-cessos contêm atividades relacionadas para definir, planejar, implantar, monitorar, controlar, medir e melhorar processos. As áreas de processo relativas à categoria de Gerência de Pro-jeto contêm as atividades de planejar, monitorar e controlar o projeto. A categoria de Engenharia refere-se às atividades de desenvolvimento de sistemas de software. Por fim, as atribui-ções de fornecer suporte ao desenvolvimento e à manutenção de produtos são relativas à categoria de Suporte.

A partir da avaliação e do atendimento dessas práticas e me-tas, é possível classificar o nível de capacidade de cada área de processo em uma escala de 0 a 5 do seguinte modo [3]:

a) Nível 0 – Incompleto. Um processo é parcialmente realizado ou não, onde um ou mais objetivos específicos do processo não são satisfeitos [3];

b) Nível 1 – Realizado. Um processo realizado satisfaz todos os objetivos específicos da área de processo e produz algum trabalho [3];

c) Nível 2 – Gerenciado. Um processo de capacidade nível 2 é um processo realizado (nível 1) que também é planejado e executado de acordo com políticas pré-definidas. Emprega pes-soas hábeis com os recursos adequados para produzir saídas adequadas, envolve os stakeholders principais e é monitorado, controlado, revisto e avaliado quanto à aderência à sua des-crição. A gerência do processo é relacionada com a realização de objetivos específicos estabelecidos para o processo, como custo, cronograma e qualidade [3];

d) Nível 3 – Definido: Um processo definido é um processo gerenciado e ajustado para o conjunto padrão de processos da organização de acordo com as suas políticas de conduta. Esse conjunto é estabelecido e melhorado com o tempo e descreve os elementos fundamentais de processos que são esperados nos processos definidos [3];

e) Nível 4 - Gerenciado quantitativamente: Um processo neste nível é definido e controlado com a ajuda de técnicas quantitativas e estatísticas. A qualidade e o desempenho do processo são compreendidos em termos estatísticos e são geri-dos durante sua vida. Objetivos quantitativos para qualidade e desempenho de processos são estabelecidos e usados como critério na gerência do processo [3];

f) Nível 5 – Em otimização: Um processo em otimização é gerenciado quantitativamente, alterado e adaptado para aten-der aos objetivos de negócio atuais e projetados. Tal processo enfatiza a melhoria contínua através de aprimoramentos tecno-lógicos inovadores e incrementais, selecionados com base em uma compreensão quantitativa de sua contribuição esperada à obtenção da melhoria de processos [3].

Representação por Estágios X ContínuaA representação contínua usa níveis de capacidade para

medir a melhoria de processos, enquanto a representação por estágios utiliza níveis de maturidade para medir a melhoria de capacidade da organização. A principal diferença é a forma como cada representação é aplicada. Os níveis de capacidade são aplicados na melhoria de processos de cada área de uma organização. Eles estão dispostos em seis níveis de capacidade, numerados de 0 a 5, onde cada nível possui um conjunto de práticas gerais e específicas.

Na representação por estágios, os níveis de maturidade não servem para analisar áreas do processo, mas sim para indicar melhorias na organização como um todo. Ao fazer a avaliação de uma organização, é possível mapear os valores de capaci-dade do processo para a maturidade organizacional. Se não há certeza sobre quais processos escolher para serem melhorados, a representação por estágios é uma boa opção. Ela fornece um conjunto específico de processos para melhorar em cada estágio, determinado por mais de uma década de experiência

Page 35: Engenharia de Software - Pontos de função

Edição 44 - Engenharia de Software Magazine 35

PRoCESSo

e pesquisas em melhoria de processo. Todavia, existem três categorias de fatores que podem influenciar na decisão de qual representação será a mais adequada:a) Estratégico: Se uma organização com foco em linha de pro-duto decidir melhorar seus processos na organização como um todo, pode ser mais bem atendida pela representação por estágios, uma vez que a representação por estágios auxilia na escolha dos conjuntos de processos onde focar a melhoria. A consideração mais importante a ser feita é a identificação dos objetivos estratégicos a serem apoiados pelo programa de me-lhoria de processo e a forma como esses objetivos estratégicos se alinham às duas representações;b) Culturais: Estão relacionados com a capacidade da organi-zação em implantar um programa de melhoria de processo. Por exemplo, uma organização pode escolher a representação contínua se sua cultura corporativa basear-se em processos e for experiente em melhoria de processo. Já uma organização pouco experiente em melhoria de processo pode escolher a representação por estágios, uma vez que essa representação fornece orientações adicionais sobre a sequência em que as mudanças devem ocorrer;c) Legado: Caso uma organização tenha experiência com outro modelo que utiliza uma representação por estágios, pode ser mais prudente continuar utilizando essa representação no CMMI, principalmente se já investiu e implantou processos associados à representação por estágios. O mesmo raciocínio pode ser aplicado para a representação contínua.

A Tabela 1 compara cada representação e pode auxiliar na determinação da representação mais adequada para a organização.

ConclusõesA utilização de metodologias em desenvolvimento de sof-

tware, mais do que uma ferramenta, é condição obrigatória para se obter a melhoria nos processos, a qualidade necessária

e o cumprimento dos prazos, tão importantes nos ambientes competitivos do presente momento.

Dessa forma, o objetivo de muitas empresas tem sido obter qualificações CMMI para atender as exigências explícitas do mercado. O CMMI (Capability Maturity Model Integration) descreve princípios e práticas relacionadas ao processo de de-senvolvimento de produtos e serviços tecnológicos. O modelo visa ajudar organizações envolvidas com o desenvolvimento de software a melhorar a capacidade de seus processos, por meio de um caminho evolucionário que considera desde pro-cessos com resultados imprevisíveis, e até mesmo caóticos, a processos disciplinados e definidos, com resultados previsíveis e com possibilidade de melhoria contínua.

Representação Contínua Representação por Estágios

Permite livre escolha da sequência de melhorias, de forma a melhor satisfazer aos

objetivos estratégicos e mitigar as áreas de risco da organização.

Permite que as organizações tenham um caminho de melhoria pré-definido e testado.

Permite visibilidade crescente da capacidade alcançada em cada área de processo. Foca em um conjunto de processos que fornece à organização uma capacidade específica caracterizada por cada

nível de maturidade.

Permite que melhorias em diferentes processos sejam realizadas em diferentes níveis. Resume os resultados de melhoria de processo em uma forma simples: um único número que representa o nível

de maturidade.

Reflete uma abordagem mais recente que ainda não dispõe de dados para demonstrar

seu retorno do investimento.

Baseia-se em uma história relativamente longa de utilização, com estudos de casos e dados que demonstram o

retorno do investimento.

tabela 1. Comparação entre as representações contínua e por estágios

[1] Uma visão geral do CMMI

http://www.dromostg.com.br/CMMI.PDF

[2] Análise de uma Organização de Software utilizando o Modelo CMMI/SEI

http://www2.dem.inpe.br/ijar/Qualidade%20de%20Software/PDFs/CMMI-Artigo.pdf

[3] Modelo de Qualidade – CMMI

Rosângela Penteado

[4] CMMI - Uma Visão Geral

Carlos José Locoselli e João Carlos Neto

Links

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

seu Feedback

sob

re esta edição

Page 36: Engenharia de Software - Pontos de função

36 Engenharia de Software Magazine - Gerenciando mudanças a partir de requisitos

José Alberto Zimermann [email protected]

Bacharel em Ciência da Computação pela Universidade Regional de Blumenau (FURB). Atua como Analista de Sistemas na empresa Dynamix Software, situada em Blumenau, SC e também como desen-volvedor Java para o ambiente Web. Pos-sui conhecimento nos frameworks JBoss Seam, Struts, Hibernate, entre outros.

Rodrigo Oliveira Spí[email protected]

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

Thiago Carvalho de [email protected]

Doutorando em Engenharia de Computa-ção e Sistemas Digitais (EP-USP). Mestre e Bacharel em Ciência da Computação (IME-USP). Trabalha há mais de 10 anos com de-senvolvimento de software, atuando como gerente de projetos, analista de negócios e requisitos em grandes multinacionais, incluindo a Oracle, Johnson & Johnson e Goodyear, bem como ministrando a disciplina de engenharia de software em diversas faculdades, tais como a Unifieo, CEUT e Faete.

De que se trata o artigo?Este artigo apresenta alguns aspectos teóricos associados à engenharia de requisitos, e em parti-cular, à manipulação da matriz de rastreabilidade. Além disso, também serão discutidos alguns as-pectos associados à gestão de mudanças.

Em que situação o tema é útil?Gerir mudanças é uma atividade fundamental em projetos de desenvolvimento de software. É natural que os requisitos mudem e evoluam ao longo do tempo. Cabe à equipe de desenvol-vimento gerenciar isto da melhor forma com intuito de minimizar impactos negativos no andamento do projeto.

ResumoEste artigo trata do assunto gestão de mudanças. Este assunto será analisado sob a perspectiva da engenharia de requisitos. Assim, inicialmente são apresentados conceitos importantes para o entendimento do assunto como: engenharia de requisitos, gerência de requisitos, matriz de rastreabilidade e gestão de mudanças. Ao final, é apresentada uma abordagem que pode ser utilizada nas atividades de gestão de mudanças com o objetivo de priorizar e avaliar as mudan-ças solicitadas por clientes nos requisitos.

Gerenciando mudanças a partir de requisitosUma das aplicações da matriz de rastreabilidade

Engenharia

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

A crescente busca pela qualidade de um produto exige cada vez mais que as empresas fabrican-

tes de software busquem um processo ou um modelo no qual se siga uma me-todologia de trabalho de conhecimento de todos os envolvidos. Neste contexto, diversas empresas optam por processos que contribuam no gerenciamento de mudanças. O objetivo do controle de mudanças é assegurar que as alterações feitas em um projeto sejam consistentes e passíveis de mensurar o impacto que irão gerar.

Page 37: Engenharia de Software - Pontos de função

Edição 44 - Engenharia de Software Magazine 37

REquiSitoS

No mercado, existem diversas ferramentas que contemplam as fases de elaboração e desenvolvimento de um sistema, auxi-liando inclusive a implantação e uso de processos de software bem definidos.

Comumente percebe-se que dentro da área de informática as empresas encontram dificuldades em gerir o processo de mudança em virtude de fatores como a velocidade e dinâmica com que elas ocorrem. As mudanças no software são feitas em resposta a solicitações de modificação de requisitos de um projeto e isso deve ser feito de maneira que a estrutura fundamental já existente permaneça estável.

Sommerville afirma que 65% da manutenção de um sistema está relacionada à implementação de novos requisitos, 18% na modificação de requisitos já existentes e 17% na correção de defeitos de um sistema. Desta maneira, a manutenção pode ser considerada como uma extensão do processo de desen-volvimento de software, com atividades associadas às de especificação, projeto, implementação e testes.

Neste sentido, dentro do processo de manutenção, Press-man afirma que um dos problemas clássicos associados à manutenção é a dificuldade em se rastrear a evolução do software, uma vez que as mudanças não estão devidamente documentadas. Já Borges defende que para se obter o controle e estabilidade de requisitos, durante o projeto de desenvol-vimento, é necessário acompanhar quantitativamente as alterações em requisitos. Isto permite mensurar o tamanho das alterações, em termos de esforço empregado na manu-tenção dos artefatos.

Considerando este contexto, este artigo apresenta alguns aspectos teóricos associados à engenharia de requisitos, e em particular, à manipulação da matriz de rastreabilidade. Além disso, também serão discutidos alguns aspectos associados à gestão de mudanças.

Alguns fundamentosNesta seção discutiremos alguns fundamentos teóricos im-

portantes ao estudarmos o assunto gestão de mudanças no contexto da engenharia de requisitos. Para isso, descreveremos inicialmente as fases de um processo de desenvolvimento de software e a gerência de requisitos. Em seguida, são expli-cados os benefícios da gestão de mudanças em um projeto, mostrando os estágios em que ela deve ser executada. Feito isto, apresentaremos o conceito e as funcionalidades da ras-treabilidade de requisitos e artefatos. Por fim, apresentamos a metodologia AHP, enfatizando o seu funcionamento e como pode ser aplicada.

Processos de desenvolvimento de softwareUm processo de software pode ser definido como sendo uma

série de atividades e resultados que possui como finalidade gerar um produto de software. Os processos de softwares são complexos e devem seguir uma série de procedimentos a fim de garantir um produto que atenda as diversas necessidades do cliente. Neste sentido, existem diversos processos que têm como características comuns as seguintes fases:

• especificação: é onde ocorre a definição das funcionalidades do software, indicando inclusive, as suas restrições;• projeto e implementação de software: nesta etapa é onde ocorre o desenvolvimento do software, atendendo a especifi-cação anteriormente descrita;• validação do software: o software necessita ser validado, garantindo que ele atenda as necessidades do cliente;• evolução do software: o software pode evoluir para atender as necessidades mutáveis do cliente.

Engenharia de requisitosExistem diferentes definições encontradas na literatura téc-

nica para engenharia de requisitos:• Termo usado para descrever as atividades relacionadas à in-vestigação e definição de escopo de um sistema de software;• Processo sistemático de desenvolvimento de requisitos através de um processo cooperativo de análise onde os resultados das observações são codificados em uma variedade de formatos e a acurácia das observações é constantemente verificada;• Processo de descobrir, analisar, documentar e verificar as funções e restrições do sistema.

Embora coerentes, estas definições podem ser melhoradas. Perceba que elas referem-se apenas às atividades relacionadas à produção de requisitos. Entretanto, nada é dito a respeito da gerência destas atividades, também conhecida como gerência de requisitos. Com isto em mente, podemos evoluir a definição de engenharia de requisitos para: termo usado para descrever as atividades relacionadas à produção (levantamento, registro, validação e verificação) e gerência (controle de mudanças, ge-rência de configuração, rastreabilidade, gerência de qualidade dos requisitos) de requisitos.

Neste ponto podemos citar alguns dos principais objetivos da engenharia de requisitos:• estabelecer uma visão comum entre o cliente e a equipe de projeto em relação aos requisitos que serão atendidos pelo projeto de software; • registrar e acompanhar requisitos ao longo de todo o processo de desenvolvimento;• documentar e controlar os requisitos alocados para esta-belecer uma baseline para uso gerencial e da engenharia de software; • manter planos, artefatos e atividades de software consistentes com os requisitos alocados.

Gerência de requisitosRequisitos são por natureza voláteis. Diversos fatores con-

tribuem para sua instabilidade ao longo do tempo. Mudanças externas no ambiente (mudanças de legislação, mudanças no mercado, mudança no posicionamento estratégico da empre-sa), erros incorridos no processo de requisitos, entre outros. Todos esses fatores fazem com que seja necessário alterar os requisitos. Tais alterações precisam ser conduzidas de forma ordenada para que não se perca controle sobre o prazo e o custo do desenvolvimento.

Page 38: Engenharia de Software - Pontos de função

38 Engenharia de Software Magazine - Gerenciando mudanças a partir de requisitos

Denominamos a atividade de administrar os requisitos ao longo do tempo de gerenciamento de requisitos.

Ao se colocar um software em uso, novos requisitos são detectados como necessários e os já existentes são alterados à medida que o sistema é utilizado. Partes dos requisitos podem ser modificadas para corrigir erros encontrados na operação ou até mesmo para melhorar o desempenho da aplicação.

É importante que o projeto de software seja atualizado com a evolução do sistema a partir da inclusão, alteração ou exclusão de requisitos, a fim de se identificar de maneira clara quais são os componentes envolvidos nas alterações de um sistema. É justamente neste contexto que se destaca a área de gerência de requisitos.

Sommerville afirma que os requisitos nos grandes sistemas estão em constante modificação.

A gerência de requisitos está associada ao processo de con-trole do processo de desenvolvimento tendo como referência a base de requisitos. Segundo Tocchetto, o principal objetivo do gerenciamento de requisitos é “descobrir, organizar, comunicar e administrar o impacto das mudanças de requisitos de um software”. Desta maneira, tem-se que os principais benefícios do gerenciamento de requisitos são:• maior controle em projetos de grande porte;• aumento da qualidade de software e maior satisfação do cliente;• diminuição dos custos de projeto e atrasos.

Gestão de mudançasO processo de manutenção é explicado por Sommerville ao se

iniciar um conjunto de pedidos de mudança por parte dos usuá-rios, gerentes ou clientes. Custo e impacto devem ser analisados para se verificar quanto do sistema será afetado pela alteração e quanto poderá custar para desenvolver esta mudança.

Assim sendo, em uma situação ideal, o estágio de desenvol-vimento de alterações deverá modificar especificação, projeto e implementação do sistema, com o objetivo de refletir no software. Desta maneira, os novos requisitos que refletem as mudanças no sistema são propostos, analisados e validados, para que a mudança seja consistente e não impacte de maneira negativa no restante do sistema.

Neste contexto, a gerência de mudança tem o objetivo de garantir que as mudanças sejam realizadas com sucesso, sem que haja perda da qualidade do software. Para que isso ocorra, é necessário que esta fase da manutenção do software controle as solicitações de manutenção, aprove as solicitações e a partir daí, estabeleça como a modificação será implementada e quais restrições que deverão ser respeitadas, definindo de maneira clara qual o escopo da alteração. Ainda segundo Sommerville, existem três estágios em um processo de gerenciamento de mudanças:• análise do problema e especificação da mudança;• análise e custo da mudança;• implementação de mudanças.

Nestes estágios são utilizadas informações de rastreabilidade para se estimar o tamanho e o custo da mudança. O custo da

mudança é estimado em termos das modificações no docu-mento de requisitos e, se apropriado, no projeto de sistemas e na implementação. Desta maneira, entende-se que é muito importante possuir o documento de requisitos e o projeto de software constantemente atualizados.

Rastreabilidade de requisitosA rastreabilidade é uma técnica que provê o relacionamento

entre diversos requisitos, projeto e a sua implementação. É ela quem auxilia no entendimento dos relacionamentos que exis-tem entre os requisitos e o projeto de software desenvolvido. Em resumo, podemos dizer que a rastreabilidade é a habilidade de descobrir o histórico de cada funcionalidade do sistema.

Neste sentido, a rastreabilidade permite garantir como e porque os artefatos atendem os requisitos dos clientes, sendo uma forma fundamental para entender os relacionamentos existentes entre requisitos e outros artefatos que fazem parte do processo de software. Desta maneira, a elaboração de um projeto de software deve produzir requisitos que sejam rastreáveis, ou seja, que sejam capazes de serem rastreados a partir da sua origem.

Por outro lado, temos também que um dos maiores desafios da engenharia de requisitos é criar um mecanismo que possi-bilite a criação de links entre os requisitos e os códigos fontes. Desta maneira, um dos benefícios que a rastreabilidade oferece é a possibilidade de se cruzar as informações especificadas na fase de projeto (requisitos) e os itens desenvolvidos na fase de implementação, que são os códigos fontes.

A rastreabilidade permite que as estimativas de custos das alterações em requisitos de um projeto possam ser mais pre-cisas. Também permite que as mudanças possam ocorrer sem a dependência do engenheiro ou programador de conhecerem as áreas afetadas por tais mudanças.

É possível afirmar que a manutenção da rastreabilidade pode ser um trabalho penoso, extenso e até mesmo inviável, quando não auxiliado por uma ferramenta especializada. Isso é explicado por Richardson e Green que afirmam que progra-madores são relutantes em manter os documentos do projeto atualizados, quebrando assim, o mecanismo que possibilita ocorrer a rastreabilidade.

Classificação da rastreabilidadeSegundo Genvigir, existem duas maneiras de se efetuar a

rastreabilidade:• forward: rastreabilidade efetuada em um requisito até seus refinamentos;• backward: rastreabilidade efetuada de um refinamento até sua origem.

Ainda de acordo com Genvigir, um processo de rastreabi-lidade é falho caso não seja possível realizar um destes dois tipos de rastreabilidade. Isto está ligado ao fato de que estas capacidades são propriedades básicas para a realização da atividade de rastreabilidade. É possível classificar ainda a rastreabilidade quanto aos seus tipos:

Page 39: Engenharia de Software - Pontos de função

Edição 44 - Engenharia de Software Magazine 39

REquiSitoS

• horizontal: rastreabilidade efetuada entre versões ou varia-ções de uma base de artefatos. Ocorre em uma determinada fase do ciclo de vida do projeto;• vertical: rastreabilidade que ocorre entre requisitos e artefatos produzidos pelo processo de desenvolvimento do projeto.

Uma visão sobre os tipos de rastreabilidade é apresentada na Figura 1. Perceba que ao trabalharmos com a rastreabilidade vertical estamos lidando com artefatos presentes em diferentes atividades do desenvolvimento. Por outro lado, ao trabalhar-mos com a rastreabilidade horizontal, estamos mapeando conceitos dentro de uma mesma atividade ou artefato base.

Figura 1. Rastreabilidade horizontal e vertical

Agora que conhecemos alguns dos fundamentos da engenha-ria de requisitos relacionados à gestão de mudanças, vamos apresentar uma abordagem que pode ser utilizada na tarefa de definição de prioridades a partir das informações contidas na matriz de rastreabilidade.

Conhecendo a metodologia AHPA metodologia AHP foi criada por Saaty com o objetivo de

ponderar as características qualitativas, permitindo assim, a ponderação e priorização de cada um dos requisitos de um projeto que estão inseridos no projeto. O funcionamento deste processo se dá pela atribuição de pesos a fatores individuais, do menos influente ao mais influente. AHP utiliza-se de uma matriz quadrada que permite avaliar a importância de uma característica sobre a outra. A partir disso, o processo permite obter o valor percentual de cada um dos requisitos e assim, mapear o valor das fases do projeto.

Segundo Tocchetto, o processo AHP permite obter o valor em percentual de cada requisito que faz parte do projeto,

sendo possível assim mapear os valores das fases do projeto, tendo-se desta forma o real custo de cada um deles a partir da aplicação de uma métrica.

Este método baseia-se no método newtoniano e cartesiano de pensar, que busca tratar a complexidade com a decompo-sição e divisão do problema em fatores, que podem ainda ser decompostos em novos fatores até o nível mais baixo, claros e dimensionáveis e estabelecendo relações para sintetizar.

Etapas para a construção de um pensamento analíticoSegundo Costa, é possível definir duas etapas de pensamento

analítico:• construção de hierarquias: no método AHP o problema é estruturado em níveis, facilitando desta forma, a melhor compreensão e avaliação deste. A Figura 2 apresenta esta estrutura do pensamento analítico. Para aplicar o AHP é ne-cessário que tanto os critérios quanto as alternativas possam ser estruturadas de forma hierárquica, sendo que no primeiro nível a hierarquia corresponde ao propósito geral do problema, o segundo e o terceiro às alternativas do problema;

Figura 2. Representação de uma estrutura hierárquica

• definição de prioridades: fundamenta-se na habilidade do ser humano de perceber o relacionamento entre objetos e situações observadas, comparando pares, sob um mesmo foco, critério ou mesmo julgamento. Para se cumprir este princípio, é necessário que o julgamento ocorra entre um par de elementos, aplicando a escala definida na Tabela 1. Esta comparação se dá através da montagem de uma matriz entre os elementos, onde i representa o elemento de uma linha e j um elemento da coluna.

Segundo Marins, Souza e Barros, a quantidade de julgamen-tos para a construção de uma matriz de julgamentos genérica A é n (n-1)/2, onde n é o número de elementos pertencentes a esta matriz. Os elementos de A são definidos pelas condições apresentadas na Figura 3.

Figura 3. Condições para a definição de uma matriz de julgamento

O processo de aplicação da metodologia AHPPara se entender o funcionamento do processo de cálculo

do AHP, pode-se considerar o exemplo descrito a seguir.

Page 40: Engenharia de Software - Pontos de função

40 Engenharia de Software Magazine - Gerenciando mudanças a partir de requisitos

Escala Definição Descrição

1 Menos importante Duas atividades contribuem igualmente para o objetivo

3 Importância pequena A experiência e o julgamento favorecem levemente uma atividade em relação à outra

5 Importância grande ou essencial A experiência e o julgamento favorecem fortemente uma atividade em relação à outra

7 Importância muito grande Uma atividade é fortemente favorecida. Sua dominação de importância é demonstrada na prática

9 Importância absoluta A evidência favorece uma atividade em relação à outra com o mais alto grau de certeza

2, 4, 6, 8 Valores intermediários. Se na atividade “j” (coluna) recebe um dos

valores acima, quando comparada com a atividade “j” (coluna),

então “j” (coluna) tem o mesmo valor recíproco de “i” (linha)

Quando se deseja maior compromisso. É uma designação razoável

Racionais Razão da escala Se a consistência tiver de ser forçada para obter “n” valores numéricos para completar a matriz.

tabela 1. Escala numérica da metodologia AHP

Para tal, será considerado um projeto que contém três requi-sitos, os quais são: • requisito 1;• requisito 2;• requisito 3.

O relacionamento realizado entre os requisitos do projeto é apresentado através da Tabela 2.

Requisito Requisito 1 Requisito 2 Requisito 3

Requisito 1 1 a12 a13

Requisito 2 a21 = 1/a12 1 a23 = 1/a32

Requisito 3 a31 = 1/a13 a32 1

tabela 2. Matriz de importância entre os requisitos

Conforme observado por Tocchetto, as premissas que devem ser seguidas para a inserção de valores são: • Se aij = α, então aji = 1/ α, α é diferente de 0;• Se o requisito i é julgado com igual importância ao requisito j, então aij = 1, aji = 1 e aii = 1.

A partir da definição desta matriz, deve-se incluir os valores para cada par de requisitos, de acordo com a escala proposta pelo autor do processo e apresentada na Tabela 1.

Deve-se observar que a inserção de valores para a definição da matriz de importância é feita a partir de definição de um critério ou julgamento. Assim, os valores são inseridos na matriz de acordo com a escala de importância estabelecida pelo julgamento. Na Tabela 3 é possível verificar a formação da matriz.

Requisito Requisito 1 Requisito 2 Requisito 3

Requisito 1 1 1/3 2

Requisito 2 3 1 5

Requisito 3 ½ 1/5 1

tabela 3. Matriz de importância

Após a definição, é necessário efetuar o cálculo do auto-vetor e a sua normalização, para cada um dos requisitos envolvidos

no processo. O cálculo do auto-vetor se dá através da expressão definida na Figura 4.

Figura 4. Expressão para a obtenção do auto-vetor

Já a normalização do auto-vetor se dá com base na expressão apresentada na Figura 5.

Figura 5. Expressão para a normalização do auto-vetor

A partir da definição e conhecimento das fórmulas apresen-tadas nas Figuras 4 e 5, pode-se exemplificá-las, aplicando as fórmulas para o Requisito 1, que é:• somatório da coluna do Requisito 1: T = 1 + 3 + 0,5 = 4,5;• primeira linha da primeira coluna normalizada: (1 * 100) / 4,5 = 22,22 / 100 = 0,22;• segunda linha da primeira coluna normalizada: (3 * 100) / 4,5 = 66,66 / 100 = 0,66;• terceira linha da primeira coluna normalizada: (0,5 * 100) / 4,5 = 11,11 / 100 = 0,11.

Este processo de normalização deve ser feito com todos os requisitos envolvidos no processo. Segundo Tocchetto, a utilização do vetor T normalizado serve para quantificar e ponderar a importância de várias características de um re-quisito. Você pode acompanhar o resultado da normalização do vetor na Tabela 4.

Requisito Requisito 1 Requisito 2 Requisito 3 Resultado

Requisito 1 0,22 0,21 0,25 0,68

Requisito 2 0,67 0,65 0,63 1,95

Requisito 3 0,11 0,13 0,12 0,36

tabela 4. Matriz com os valores normalizados

Page 41: Engenharia de Software - Pontos de função

Edição 44 - Engenharia de Software Magazine 41

REquiSitoS

Desta maneira, o percentual de importância de cada requisito é apresentado através da Tabela 5. Assim, tem-se que:• o requisito 1 equivale aproximadamente a 22,44% do projeto;• o requisito 2 equivale aproximadamente a 64,35% do projeto;• o requisito 3 equivale aproximadamente a 11,88% do projeto.

Fator 1/n Requisito normalizado Importância (%)

1/3 0,68 22,44

1/3 1,95 64,35

1/3 0,36 11,88

tabela 5. Importância de cada requisito

ConclusãoA engenharia de requisitos define, sem dúvida, um dos mais

importantes conjuntos de atividades a serem realizadas em

APACHE SOFTWARE FOUNDATION. Apache log4j 1.2. [S.l.], 2011. <http://logging.apache.org/log4j/1.2//>.

BATISTA, Raphael M. Ferramenta de gerência de requisitos de software integrada com Enterprise

Architect. 2007. 67 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. <http://

campeche.inf.furb.br/tccs/2007-I/2007-1raphaelmarcosbatistavf.pdf>.

BELTRÃO FILHO, Mauro F. de H. Gingway – uma ferramenta para criação de aplicações Ginga-

NCL interativas para TV digital. 2008. 59 f. Monografia (Bacharelado em Ciência da Computação)

– Centro de Informática, Universidade Federal de Pernambuco, Recife. <http://www.cin.ufpe.

br/~tg/2008-2/mfhbf.pdf>.

BORGES, Eduardo P. Um modelo de medição para processos de desenvolvimento de software.

2003. 154 f. Dissertação (Mestrado em Ciência da Computação) – Departamento de Ciência da

Computação, Universidade Federal de Minas Gerais, Belo Horizonte. <http://homepages.dcc.ufmg.

br/~wilson/pesquisa/DissertacaoEduardo.pdf>.

BON, Jonas; VASSEUR, Alexandre. AspectWerkz: plain Java AOP 2.0 API. [S.l.], 2005. <http://

aspectwerkz.codehaus.org>.

BURNETTE, Ed. Eclipse IDE – guia de bolso. Tradução João Torello. Porto Alegre: Bookman, 2006.

COSTA, Helder G. Introdução ao método de análise hierárquica: análise multicritério no auxílio à

decisão. Niterói: Universidade Federal Fluminense, 2002.

ECLIPSE FOUNDATION. About the eclipse foundation. [S.l.], 2011. <http://www.eclipse.org/org/>

FEIGENBAUM, Barry. SWT, Swing or AWT: which is right for you? [S.l.], 2006. <http://www.ibm.

com/developerworks/grid/library/os-swingswt/>

FERREIRA, Felype S. Implementação e análise de uma linha de produtos de software. 2009. 67

f. Projeto de Graduação (Bacharelado em Ciência da Computação) – Centro de Informática,

Universidade Federal de Pernambuco, Recife. <http://www.cin.ufpe.br/~tg/2009-2/fsf2.pdf>.

GENVIGIR, Elias C. Um modelo para rastreabilidade de requisitos de software baseado em

generalização de elos e atributos. 2009. 200 f. Teste de Doutorado do Curso de Pós Graduação em

Computação Aplicada – Instituto Nacional de Pesquisas Espaciais, São José dos Campos. <http://

mtc-m18.sid.inpe.br/col/sid.inpe.br/mtc-m18%4080/2009/03.02.14.17/doc/publicacao.pdf>.

HAMILTON, Vivien L.; BEEBY, Martin. Issues of traceability in integration tools. In: IEE COLLOQUIUM ON TOOLS

AND TECHNIQUES FOR MAINTAINING TRACEABILITY DURING DESIGN, 1., 1991, Londres. Procedings. Londres:

IEEE, 1991. p. 4/1-4/2. <http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=182212>.

HAROLD, Elliotte R. Processing XML with Java. [S.l.], 2001. <http://www.cafeconleche.org/books/xmljava/>.

HAZAN, Claudia; LEITE, Julio C. S. P. Indicadores para a gerência de requisitos. In: WORKSHOP EM

ENGENHARIA DE REQUISITOS, 6., 2003, Piracicaba. Anais eletrônicos... Rio de Janeiro: PUC-RIO, 2003. Não

paginado. <http://wer.inf.puc-rio.br/WERpapers/artigos/artigos_WER03/claudia_hazan.pdf>.

HENKELS, André. Drawcode: um plugin do eclipse para geração de código a partir de diagramas de

classe e diagramas N-S. 2007. 101 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.

HUNTER, Jason; MCLAUGHLIN, Brett. JDOM: FAQ. [S.l.], 2007. <http://www.jdom.org/docs/faq.

html#a0000>.

JASPERFORGE. IReport: JasperForge. [S.l.], 2011. <http://jasperforge.org/projects/ireport>.

LOPES, Luiz H. C. Sistema web para gestão de pautas e atas de reuniões. 2008. 55 f. Monografia (Curso

de Especialização em Informática Empresarial) – Universidade Estadual Paulista, Guaratinguetá.

<http://www.feg.unesp.br/ceie/Monografias-Texto/CEIE0805.pdf>.

MARINS, Cristiano S.; SOUZA, Daniela de O.; BARROS, Magno da S. O uso do método de análise

hierárquica (AHP) na tomada de decisões gerenciais: um estudo de caso. In: SIMPÓSIO BRASILEIRO

DE PESQUISA OPERACIONAL - PESQUISA OPERACIONAL NA GESTÃO DO CONHECIMENTO, 41., 2009,

Porto Seguro. Anais eletrônico... Rio de Janeiro: Universidade Federal Fluminense, 2009. p. 1778-

1788. <http://www.ic.uff.br/~emitacc/AMD/Artigo%204.pdf>.

OLIVEIRA, Fabricio. Software de apoio à gerência de solicitação de mudanças. 2006. 72 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.

Referências

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

seu Feedback

sob

re esta edição

projetos de desenvolvimento de software. Neste contexto, vimos neste artigo que gerir mudanças é uma atividade fundamental em projetos de desenvolvimento de software. É natural que os requisitos mudem e evoluam ao longo do tempo. Cabe à equipe de desenvolvimento gerenciar isto da melhor forma com intuito de minimizar impactos negativos no andamento do projeto.

Page 42: Engenharia de Software - Pontos de função

42 Engenharia de Software Magazine - Introdução ao desenvolvimento de aplicações de realidade aumentada

André Luis Tosato da [email protected]

Graduando em Ciência da Computação pela Faculdade Anhanguera de Santa Barbara (2011), atualmente trabalhando como As-sistente de Desenvolvimento(Delphi e c#) e possui interesse por programação.

Paulo C. Barreto da [email protected]

Graduado em Análise de Sistemas pelo Centro Universitário Salesiano de São Paulo (2003) e Pós-graduado pela Universidade Estadual de Campinas - 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. Possui experiência de 12 anos na área de Ciência da Computação, com ênfase em Sistemas de Informação, atuando princi-palmente nos seguintes temas: análise de sistemas, programação orientada a obje-tos, programação estruturada, desenvolvi-mento de sistemas, UML (Linguagem de Modelagem Unificada), gestão de projetos, linguagem de programação C e Java.

Victor Angelo [email protected]

Graduando em Ciência da Computação pela Faculdade Anhanguera de Santa Barbara (2011). Estagiário na área da computação recém-contratado pela ItalyTex. Possui co-nhecimentos na área de desenvolvimento de softwares e manutenção de computadores.

Thiago Salhab [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 Coor-denador 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 Enge-nharia de Software.

De que se trata o artigo?Este artigo apresenta os conceitos de desenvolvi-mento de sistemas que adotam o conceito de Reali-dade Aumentada. Este artigo serve como base para estudantes e profissionais da área de computação que estejam interessados em conhecer os aspectos fundamentais da Realidade Aumentada como ferra-menta de apoio.

Em que situação o tema é útil?Como embasamento para projetos que desejem adotar ferramentas gráficas de simulação. Projetos que utilizem a inclusão de objetos virtuais intera-tivos com o objetivo de demonstrar um ambiente virtual próximo da experiência real.

ResumoA Realidade Aumentada pode ser definida como uma combinação do ambiente real com o ambiente virtual. Neste contexto, este artigo apresenta conceitualmen-te o tema e, na sequência, faz uma introdução ao de-senvolvimento de aplicações desta natureza.

Introdução ao desenvolvimento de aplicações de realidade aumentada

A Realidade Virtual vem revolu-cionando a área da educação com suas características que

permitem ao usuário vivenciar situações através de navegação e interação em mundos virtuais.

A Realidade Aumentada pode ser definida como uma combinação do ambiente real com o ambiente virtual.

Atualmente, ela é o tipo de interface com o usuário que tem chamado mais a aten-ção pelo fato de permitir aos usuários executar tarefas de forma mais intuitiva e eficiente. As interfaces de Realidade

Arquitetura e Desenvolvimento

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

Page 43: Engenharia de Software - Pontos de função

Edição 44 - Engenharia de Software Magazine 43

ARquitEtuR A E dESENvoLviMENto

Aumentada devem aumentar a percepção do usuário sobre o mundo real adicionando informações virtuais nele.

Um dos problemas na área da educação é manter a motivação dos alunos no aprendizado de um determinado conteúdo. Muitas vezes faltam recursos para os professores de anatomia auxiliar a formação dos educandos e também motivação por parte deles, principalmente na área médica, em função da complexidade do corpo humano.

Neste contexto, este artigo apresenta uma introdução ao desenvolvimento de aplicações em realidade aumentada, en-fatizando as possibilidades existentes para a área da educação e médica (ler Nota do DevMan 1).

N o t a d o D e v M a n 1

Aprendizagem de Anatomia HumanaSegundo Braz [1], vários alunos ingressantes em cursos que possuem a matéria de

Anatomia Humana passam por várias dificuldades no entendimento da matéria devi-do a vários motivos: a dificuldade do aluno com a terminologia anatômica, o pequeno tamanho das estruturas, o preparo inadequado das peças e vários fatores individuais como falta de motivação, atenção e o medo ou receio existente quando o aluno se depara com os cadáveres humanos.

Em uma experiência de aula, uma professora dividiu 132 alunos do Curso de Farmá-cia em duas turmas, onde em uma, ela aplicou os métodos de ensino tradicionais e na outra, foram utilizados os mesmos métodos, só que após a aula, os alunos permane-ciam no laboratório para interagir com as estruturas estudadas em sala, e após essa interação foi proposto para os alunos que explicassem as estruturas para o professor e colegas.

Ao final do estudo, a primeira turma teve uma média de 35,17% e a segunda turma obteve uma média de 56,67%, então chegou-se à conclusão que tendo-se mais con-tato e mais facilidade para ver as estruturas a serem estudadas, o aluno tem um maior aproveitamento do curso.

ContextualizandoRealidade Aumentada é mais um das vertentes da Realidade

Virtual, porém enquanto a Realidade Virtual tem como prin-cípio a inserção do usuário em um ambiente fictício gerado por computador, isentando este de todo ou quase todos os sentidos reais, a Realidade Aumentada insere objetos virtuais em um ambiente real sem ocultar do usuário o que está a sua volta. Como o próprio nome diz, seu objetivo é aumentar a complexidade do mundo real inserindo objetos virtuais e tudo isto em tempo de execução real.

Esta tecnologia está cada vez mais inserida em nosso cotidia-no, pois já existem aplicações em celulares, jogos, simuladores, inclusive aplicações na área médica e artística.

Realidade aumentada é uma especialização da realidade vir-tual, baseada na inserção de objetos virtuais em uma cena real, podendo o usuário interagir com o objeto em tempo real.

Realidade AumentadaA Realidade Aumentada é uma tecnologia que possibilita a

inclusão de objetos virtuais interativos em um ambiente real,

utilizando dispositivos tecnológicos como webcams, câmeras digitais, óculos digitais, entre outros.

Pelo fato de utilizar os movimentos do corpo como uma forma de interação com o computador através de dispositivos característicos da tecnologia, a Realidade Virtual é considerada como a forma mais avançada de comunicação entre pessoas e computadores.

Segundo Kirner e Zorzal [4], a Realidade Aumentada pode ser definida como uma tecnologia através da qual se incre-menta ou aumenta a visão que um utilizador tem do mundo real com a adição de imagens virtuais, usando técnicas de visão por computador e de Computação Gráfica/Realidade Virtual, resultando na sobreposição de objetos virtuais com o mundo real.

Esta tecnologia possibilita que o usuário tenha uma interação atrativa e motivadora com o ambiente, propiciando então o de-senvolvimento de habilidades e construção do conhecimento.

Aplicações de Realidade AumentadaÉ cada vez mais comum nos depararmos com várias aplicações

da Realidade Aumentada atualmente, já é utilizada na Educação, Medicina, Jogos, Design, Engenharia e dentre outros.

Uma de suas aplicações mais recentes foi a campanha da nova fragrância da Empresa AXE, que tinha como slogan da campanha “Even Angels will fall...” (“Até os Anjos cairão...”), onde colocaram um marcador no meio de uma estação de metrô, e quando a pessoa passava e olhava para cima, aparecia um anjo no telão da estação (ver Figura 1).

Figura 1. Campanha Publicitária da empresa AXE com RA

MedicinaA Realidade Aumentada já está ajudando pessoas que sofrem

de varizes. Dr. KasuoMiyake (Especialista no tratamento de varizes) ajustou o equipamento VeinViewer, uma espécie de visão de raios X, que auxilia na coleta de sangue e na medica-ção intravenosa, e o adaptou utilizando RA para auxiliar no tratamento de varizes, dispensando cirurgia. Segundo Miyake, esta técnica já evitou cirurgias em 86% dos casos desde 2007 (ver Figura 2).

Após analisar a aplicabilidade da realidade aumentada no cotidiano das pessoas, Sabbatini [6] concluiu que já existe disponível no mercado uma vasta gama de equipamentos

Page 44: Engenharia de Software - Pontos de função

44 Engenharia de Software Magazine - Introdução ao desenvolvimento de aplicações de realidade aumentada

baseados em realidade aumentada, sendo a área médica a mais avançada no assunto.

O uso de equipamentos baseados em realidade aumentada tem permitido o amplo treinamento de suturas como mostrado nas Figuras 3 e 4, inserção de cateter na veia subclávia, disco-tomia vertebral laparoscópica, dentre muitas outras coisas.

Figura 2. Aplicando RA para o Tratamento de Varizes

Figura 3. Exemplo de uma aplicação da realidade virtual na medicina “Simulação de micro suturas”

Figura 4. Treinamento de Suturas

Funcionamento da Realidade AumentadaA realidade aumentada possui seu funcionamento baseado

na captura de uma imagem codificada e devolvendo sobre esta uma figura em 3D com total mobilidade e execução em tempo real, pois de acordo com a posição do marcador a figura projetada é ajustada.

Os passos apresentados na Figura 5 são descritos da seguinte maneira:• Captura da cena com o marcador;• Identificado o símbolo encontrado, o software busca pela imagem 3D referente ao código do marcador;• Procura a posição da imagem 3D de acordo com a posição do marcador;• Volta a identificar o marcador para calcular o posiciona-mento do objeto 3D;• Por fim, insere o objeto virtual no meio real de acordo com os dados encontrados;• O resultado final é exibido ao final desses passos.

Figura 5. Funcionamento de RA pela posição do Marcador

A disposição do objeto pode ser interferida de várias manei-ras, como brilho de luz sobre a parte escura do marcador, colo-car qualquer objeto que esconda esta mesma parte do marcador também ocasiona a perda da imagem, e para movimentos mais rápidos é necessário o uso de um objeto de captura de grande precisão (ver Figura 6).

Figura 6. Amostra da RA

Ferramentas para DesenvolvimentoAtualmente temos várias ferramentas disponíveis para o

desenvolvimento de realidade aumentada. Um das ferramentas é o FLARToolKit. Segundo Tomohiko Koyama, um de seus desenvolvedores, é uma versão baseada no NyARToolKit

Page 45: Engenharia de Software - Pontos de função

Edição 44 - Engenharia de Software Magazine 45

ARquitEtuR A E dESENvoLviMENto

(ARToolKit para Java), adaptada para o Flash, que é possível de ser incorporado em páginas Web. Para o desenvolvimento de aplicações com o FLARToolkit é necessário ter objetos 3D desenvolvidos nas principais engines 3D do Flash como o Pa-pervision 3D, Away 3D, entre outros e utilizar programação em ActionScript, além de ter um ambiente de desenvolvimento para Flash (ver Figura 7).

Figura 7. Aplicação usando FLARToolkit

O funcionamento desta tecnologia se dá basicamente da seguinte forma:• A câmera captura imagens do mundo real e as envia ao computador;• O software procura em frames do filme todas as formas quadradas;• Se entre estes quadrados ele detectar um marcador, através de algoritmos matemáticos é calculada a posição da câmera em relação ao marcador;• Depois de calculada a posição da câmera, o modelo gráfico é inserido na mesma posição da cena;• Sendo o modelo inserido na cena do mundo real, ele tem por posição relativa o marcador;• A saída final é exibida, dando ao usuário a ilusão de sobre-posição do objeto à cena real;• Um exemplo de saída pode ser observado na Figura 8, onde o objeto virtual é inserido em cima do marcador.

ARToolKitO ARToolKit é uma biblioteca Open Source desenvolvido em

linguagem C e C++ para o desenvolvimento de aplicações em realidade aumentada. No site http://www.hitl.washington.edu/artoolkit/download/ pode ser feito o download do pacote de desenvolvimento.

Segundo o site oficial do ARToolKit escrito por Phillip Lamb, o desenvolvimento do ARToolKit começou em 1999 quando Hirokazo Kato chegou ao instituto HITLab (Human Interface Tecnology Laboratory) da Universidade de Washington.

O ARToolKit foi apresentado pela primeira vez no SIGGRA-PH “Special Interest Group on GRAPHics and Interactive Techniques” (conferência de profissionais em computação gráfica iniciada em 1974), uma versão para Windows usando o directshow (uma biblioteca de rotinas prontas, uma API, de-senvolvida pela Microsoft).

Hirokazo Kato e M. Billinghurst, os dois principais criadores do ARToolKit, ainda trabalham no projeto.

Arquitetura do ARToolKitNa Figura 9, a área em vermelho corresponde às aplicações

em realidade aumentada. Em seguida vem o ARToolkit que interage com as bibliotecas OpenGL, a GLUT, a Standard Li-brary e Video Library. O OpenGL é a biblioteca que cuida da parte gráfica da aplicação.

Figura 9. Arquitetura do ArtoolKit (HITLab, University of Washington)

A GLUT (OpenGL Utility Toolkit) é uma biblioteca que faz a comunicação e o suporte do OpenGL com o hardware e que proporciona ainda o uso de uma API (Application Program-ming Interface), com menus, botões e suporte a joystick. Mesmo não sendo um aplicativo de código aberto, a GLUT pode ser usada livremente.

A Standard API e a Video Library são API’s padrão do sistema operacional utilizado.

Principais estruturas do ArtoolkitO ARToolKit utiliza algumas estruturas para que se guarde as

informações necessárias para a manipulação das cenas. Tomando como base a documentação desta biblioteca vamos descrever as principais estruturas. Para isso, a Tabela 1 mostra as principais funções do ARToolKit juntamente com seus significados.Figura 8. Imagem inserida sobre o marcador

Page 46: Engenharia de Software - Pontos de função

46 Engenharia de Software Magazine - Introdução ao desenvolvimento de aplicações de realidade aumentada

A relação entre a câmera e os marcadoresO ARToolKit calcula a posição do marcador e da câmera

através do sistema de coordenadas, com o uso do sistema de matriz, possibilitando calcular a posição na qual o objeto virtual vai ser inserido (ver Figura 10).

Figura 10. Exemplo de marcador

Depois que a imagem é capturada ela é transformada em uma imagem binária e através de algoritmos computacionais, onde são reconhecidos os padrões quadrados e recuperada a posição de cada um dos quatros vértices com estes valores, é calculada a posição do objeto que vai ser sobreposto na imagem analisada conforme a Figura 10.

Neste sistema, cada quadro de imagem do ambiente captura-do é transformado para binário para facilitar o reconhecimento e a posição espacial do marcador a ser localizado. Feito isto, para cada imagem de vídeo, o desenho interior do marcador reconhecido é comparado com os gabaritos de marcadores pré-definidos (ver Figura 11).

Função Descrição

ARMarkerInfo Principal estrutura utilizada em marcadores para guardar as informações do contorno do marcador depois que este foi detectado.

ARMarkerInfo2 Estrutura interna usada para a detecção dos marcadores: armazena as informações do contorno dos marcadores.

ARMat É a estrutura que guarda a matriz baseada em alocações dinâmica.

ARMultiEachMakerInfoT Estrutura para vários marcadores. Possui estrutura similar ao ARMakerInfo porém para múltiplos marcadores.

ARMultiMarkerinfoT Estrutura utilizada para monitorar múltiplos marcadores.

ARParam Estrutura que contem os principais parâmetros para a representação da câmera.

ArPrevinfo Estrutura que guarda o histórico de detecção de marcadores e transformações de matriz.

ARVec Estrutura de vetores com alocação dinâmica.

tabela 1. Principais funções do ARToolKit

ConclusãoNeste artigo foram apresentados os conceitos básicos da

Realidade Aumentada. Foi possível identificar os benefícios que a Realidade Aumentada tem proporcionado para as di-versas áreas de conhecimento, notadamente para a área da saúde e educação.

Assim, espera-se ter contribuído para o entendimento da realidade aumentada, assim como as possibilidades que esta tecnologia pode alcançar.

Figura 11. Sequência do reconhecimento do marcador (HITLab, University of Washington)

Augmented Reality Page: http://www.se.rit.edu/~jrv/research/ar/

HITLab - Human Interface Technology Laboratory: http://www.hitl.washington.edu/home/

Realidade Aumentada - Home: www.realidadeaumentada.com.br

1. BRAZ, Paula Regina Pereira. Método Didático Aplicado ao Ensino da Anatomia Humana.

Anuário da Produção Acadêmica Docente, Valinhos, n. , p.303-310, 19 mar. 2010.

2. FAZOLLI, Fernando Yuki. Realidade Aumenta: Monografia do Bacharelado em Ciência da

Computação. Santa Bárbara D’ Oeste: Faculdade Anhanguera de Santa Barbara, 2009.

3. GOMES, Wneiton Luiz; KIRNER, Cláudio. Desenvolvimento de Aplicações Educacionais na

Medicina Com Realidade Aumentada. Bazar: Software e Conhecimento Livres, 2006.

4. KIRNER, Claudio; ZORZAL, Ezequiel. Jogos Educacionais em Ambiente de Realidade

Aumentada. Workshop de Realidade Aumentada, Piracicaba, 2005. Disponível em: <http://

www.realidadeaumentada.com.br/artigos/14534.pdf> Acesso em 27 de Junho de 2011.

5. MILGRAM, P. et al. Augmented Reality: A Class of Displays on the Reality-Virtuality Continuum,

Telemanipulador and Telepresence Technologies, SPIE, V. 2351, p. 282-292, 1994.

6. SABBATINI, R. M. E. O diagnóstico médico por computador. Informédica, 1(1): 5-10, março/

abril de 1993.

7. TORI, Romero; KIRNER, Claudio; SISCOUTO, Robson. Fundamentos e Tecnologia de Realidade

Virtual e Aumentada. Belém: VIII Symposium On Virtual Reality, 2006.

Referências

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

seu Feedback

sob

re esta edição

Page 47: Engenharia de Software - Pontos de função

Edição 44 - Engenharia de Software Magazine 47

Jacimar Fernandes Tavares [email protected]

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

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

É Doutor e Mestre em Engenharia de Sis-temas e Computação pela COPPE/UFRJ, Especialista em Métodos Estatísticos Com-putacionais 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 Prefeitu-ra de Juiz de Fora, Editor da Engenharia de Software Magazine.

De que se trata o artigo?Aborda o tema Código Limpo com o objetivo de mos-trar 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 desenvol-vedor sobre como transformar códigos considerados ruins em bons códigos demonstrando através de exemplos práticos as teorias aqui abordadas.

Em que situação o tema é útil?O tema se torna fundamental para desenvolve-dores 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 ad-quirido sobre limpeza de código.

ResumoEsta 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 re-fere 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 à ne-cessidade da realização de novas otimizações.

Boas práticas para escrita de métodos, funções e procedimentos – Parte 6Mantendo Limites e Casos de Teste Unitários Limpos

A relação existente entre um sof-tware desenvolvido por uma equipe, e que faz uso de código

de terceiros, requer alguns cuidados, como conhecer bem o código a ser uti-lizado ou conhecer o que ele é capaz de fornecer em termos de funcionalidades.

Estabelecer a forma como o software em desenvolvimento e o código de terceiros devem se comunicar é uma tarefa que envolve algumas verificações.

Uma dessas verificações consiste em conhecer as funcionalidades que pode-rão ser utilizadas e as funcionalidades que não poderão ser utilizadas, por exemplo, uma funcionalidade na qual um dos usuários do sistema não deve ter acesso. Conhecidas as funciona-lidades que se pode acessar e as que não se pode, devem-se estabelecer os limites, isto é, criar mecanismos para controlar o acesso a tais funcionalidades.

Arquitetura e Desenvolvimento

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

Page 48: Engenharia de Software - Pontos de função

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

A forma como esses mecanismos são construídos, em alguns casos, leva a escrita de código que não é considerado limpo. Um dos objetivos deste artigo é falar sobre esses mecanismos que estabelecem limites e como mantê-los limpos. A seção Limites é a responsável por abordar este tema.

Em outro cenário, agora abordando o tema teste unitário de software, é necessário entender alguns conceitos seguindo as recomendações de código limpo.

Escrever casos de teste unitário é uma tarefa que envolve o co-nhecimento sobre as teorias envolvidas no processo de definição de casos de teste e também consiste em saber como escrever casos de teste de acordo com o que é necessário para um método poder ser considerado devidamente testado. Caso ainda não se tenha esse conhecimento, o artigo sobre Teste unitário com NUnit (ler edição 43 da Engenharia de Software Magazine) poderá ajudar neste sentido.

O que alguns desenvolvedores não se preocupam está relacio-nado à qualidade do código de teste que estão implementando. Qualidade de código, referentes a código de teste, passa pelas teorias sobre código limpo. Um dos objetivos da seção Teste de Unidade é mostrar como devem ser mantidos os códigos de teste criados para testar os métodos das aplicações.

LimitesNesta seção abordaremos a importância de estabelecer limites

para testar aplicações. Esta seção dá ênfase a código de terceiros que muita das vezes são inseridos em algumas aplicações devi-do, entre outras coisas, a necessidade de adquirir, por exemplo, um componente de terceiros. Ao se conhecer os limites que o código ou componente de terceiros possuem, torna-se possível conhecer seu funcionamento e suas limitações. Com base nes-tas informações fica mais fácil saber quando uma nova versão do código ou componente de terceiros é mais recomendada ao projeto atual do que a versão antiga dos mesmos que está sendo mantida no projeto.

Evitar que uma versão do código ou componente perma-neça no projeto sem se ter a certeza que realmente é útil por satisfazer alguma das necessidades do projeto é uma prática que contribui para se ter um código limpo. Dentre todos os objetivos desta seção, manter o código limpo, incluindo o limite entre a aplicação e os códigos de terceiros, é o objetivo principal.

Estabelecendo os limites entre o código criado e o código de terceiros

Conceitua-se código criado como o código que está sen-do implementado ou foi implementado em uma aplicação. Conceitua-se código de terceiros como qualquer código que foi implementado por outra empresa, equipe ou desenvolvedor, cujo propósito satisfaz a alguma necessidade que se tem no momento, e é a razão pela qual o código está sendo comprado/obtido para ser utilizado.

Códigos de terceiros geralmente são genéricos, isto é, tendem a abranger grande quantidade de necessidades, podendo ser utilizado em muitos cenários diferentes. Isso faz com que o

código de terceiros muitas das vezes tenha mais funciona-lidades do que normalmente se precisa quando se opta por utilizá-lo.

Caso seja possível refatorá-lo, isto é, modificá-lo a fim de remover códigos que não serão utilizados no instante em que se deseja apenas uma funcionalidade, é aconselhável que o faça, mas nem sempre se pode alterar tais códigos.

Existem diversos tipos de código de terceiros, dentre eles os que são oferecidos em forma de componentes e classes, entre outras formas.

Partindo do princípio de que não se pode alterar o código de terceiros que se está utilizando, será definido um exemplo de como utilizar o código de terceiros sem expor mais funciona-lidades do que o necessário.

Considerando uma classe de uma biblioteca de classes que é disponibilizada juntamente com um ambiente de desenvolvi-mento Java ou .Net, pode-se ter vários métodos de diferentes funções, das quais apenas algumas precisam ser utilizadas. Como exemplo, considere o código da Listagem 1.

Listagem 1. Código da classe Aluno.

1. public class Aluno2. {3. ...4. public ArrayList listaAlunos = new ArrayList();5. ...

6. public void adicionarAlunoLista(Aluno aluno)7. {8. listaAlunos.Add(aluno);9. }

10. public ArrayList recuperarListaAlunos()11. {12. return listaAlunos;13. }14. ...15. }

A Listagem 1 possui o código da classe Aluno, que utiliza código de terceiros, isto é, código da biblioteca de classes do .Net Framework, mais precisamente da classe ArrayList, que fornece objetos que atuam como lista de dados. Ao disponi-bilizar essa classe, o .Net Framework disponibiliza também uma série de métodos que permitem a manipulação dos objetos da classe ArrayList. O código da Listagem 1 utiliza apenas o método .Add e retorna uma lista com os alunos existentes. A Listagem 2 mostra o código cliente da classe Aluno.

No código cliente da Listagem 2 é possível verificar que, para adicionar um objeto aluno à lista de alunos da classe Aluno, é invocado o método adicionarAlunoLista, linha 2 da Listagem 2. Para recuperar a lista de alunos é invocado o método recupe-rarListaAlunos, linha 4, também da Listagem 2.

Não se deve permitir que outras operações sejam realizadas com a lista de alunos da classe Aluno da Listagem 1 além das operações que são realizadas pelo código cliente da Listagem 2. Também não se deve permitir outra forma de acesso à lista de alunos da classe Aluno, como por exemplo, acessar seu método .Add.

Page 49: Engenharia de Software - Pontos de função

Edição 44 - Engenharia de Software Magazine 49

ARquitEtuR A E dESENvoLviMENto

Listagem 2. Código cliente da classe Aluno.

1. ...2. aluno.adicionarAlunoLista(aluno);3. ...4. ArrayList lista = aluno.recuperarListaAlunos();5. ...

O código, da forma como está escrito, permite que as operações que não podem ser realizadas aconteçam, caso um desenvolvedor escreva código cliente de forma que as utilize. Nesse caso, estaria violando o princípio estabelecido de que só se pode recuperar e adicionar utilizando os métodos definidos na Listagem 1. O fato de um desenvolvedor poder burlar facilmente essa regra fere os princípios de limite estabelecidos para o acesso a lista de alunos da classe Aluno. Para que se respeitem os limites impostos, deve-se criar, portanto, uma estratégia que iniba a quebra da regra e também que estabeleça um limite para o acesso ao código de terceiros, isto é, ao código da classe ArrayList, do .Net Framework. A estratégia definida é a criação de uma interface para a classe Aluno, com pode ser visto nas Listagens 3 e 4.

Listagem 3. Classe Aluno modificada.

1. public class Aluno: IAluno2. {3. private ArrayList listaAlunos = new ArrayList();

4. public void adicionarAlunoLista(Aluno aluno)5. {6. listaAlunos.Add(aluno);7. }

8. public ArrayList recuperarListaAlunos()9. {10. return listaAlunos;11. }12. }

Listagem 4. Interface da classe Aluno.

1. public interface IAluno2. {3. void adicionarAlunoLista(Aluno aluno);

4. ArrayList recuperarListaAlunos();5. }

Na Listagem 4 está definida a interface com a classe Aluno, isto é, o novo meio de acesso à classe Aluno, que o código clien-te passará a utilizar. Os métodos da classe Aluno que podem ser manipulados estão devidamente declarados na interface. No entanto, para evitar que um desenvolvedor acesse outro método que manipula a lista de alunos da classe Aluno, foi alterado o modificador de acesso da lista de alunos de público para privado (linha 3, Listagem 3). A partir deste momento, o acesso à classe Aluno deve ser feito pela sua interface e não mais diretamente aos métodos da classe Aluno. Os limites estão estabelecidos, uma vez que não é mais possível acessar outros métodos que manipulam a lista de alunos da classe

Aluno que não sejam os declarados na interface. O código da Listagem 5 mostra o código cliente da classe Aluno depois das modificações geradas a partir da criação da interface da classe Aluno.

Listagem 5. Código cliente da interface de Aluno.

1. ...2. alunoJose.adicionarAlunoLista(aluno);3. ...4. ArrayList lista = aluno.recuperarListaAlunos();5. ...

Outro ponto importante sobre código de terceiros gira em torno do tempo que é gasto para entender o que eles realmente fazem. Código limpo (MARTIN, 2009) sugere que, ao invés da leitura da documentação sobre o que o código a ser utilizado pode proporcionar em termos de funcionalidades, é melhor criar casos de teste para testar se as funcionalidades que se espera encontrar realmente existem no código de terceiros e se realmente funcionam como espera-se que funcione. Os testes criados são chamados de testes de aprendizagem, pois permi-tem que ao testar o código de terceiros, também seja obtido certo conhecimento acerca do que o código é capaz de fazer. Sendo assim, proporciona aprendizado sobre o código a ser utilizado, além de se ter a certeza de que ele não contêm erros, uma vez que foi testado por quem vai usá-lo também.

Outro benefício da criação de casos de testes para códigos de terceiros gira em torno da disponibilização de novas versões do código. Sempre que um terceiro lançar novas versões do código, será possível, através de um novo teste com os casos de testes escritos para a versão antiga, saber se a versão nova ainda possui as mesmas funcionalidades que a anterior, e se a nova versão vai servir no lugar da versão antiga que está sendo utilizada em al-guma aplicação. Caso os testes detectem que, por exemplo, uma saída não é mais formatada como na versão antiga, rapidamente poderá ser feita uma análise acerca da utilização ou não da nova versão, analisando os prós e contras da adesão.

Concluindo limitesComo visto nos exemplos das listagens apresentadas até

o momento, é possível perceber que há pontos importantes a se considerar quando se está lidando com limites que vão até o ponto que se pode modificar, isto é, limites que vão até aonde começa o código de terceiros. Controlar estes limites, e fazer com que o código de terceiros não prejudique o código da aplicação que o invoca, é a tarefa do desenvolvedor. Como geralmente códigos de terceiros possuem vários recursos, muitas vezes mais do que é necessário para a finalidade que se aplica, é interessante que o desenvolvedor saiba preparar sua aplicação para se relacionar bem com o código de terceiros. Isso deve ser feito através do estabelecimento de limites que possuem código que pode ser considerado limpo.

As mesmas regras que valem para a utilização de uma simples classe de uma biblioteca de classes valem para o relacionamento com outras aplicações. Estabelecer os limites entre o código

Page 50: Engenharia de Software - Pontos de função

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

desenvolvido e o código de uma aplicação que se está integrando é essencial. Nesse sentido, é importante saber que as aplicações que estão sendo integradas ao sistema podem possuir muitas funcionalidades que podem não ser acessadas, ou as que serão acessadas fornecem dados formatados diferentemente do espera-do. Sabendo dessas particularidades, é importante que o desen-volvedor implemente mecanismos que permitam a comunicação de forma simples e limpa com a aplicação que se está integrando e que também controle os limites entre as aplicações.

Testes de unidadeEsta seção se faz necessária devido a um problema encontra-

do em casos de testes escritos para testes de unidade: código ilegível. Manter um código limpo inclui manter o código dos casos de testes limpos também. De certa forma, manter ape-nas o código do sistema limpo não é garantia de facilidade de interpretação. O tempo gasto para entender e manter o código fonte de um sistema pode ser maior se o cuidado que o desenvolvedor teve em mantê-lo limpo não for o mesmo como o código utilizado para testes unitários. Assim, escrever casos de testes limpos é o objetivo desta seção. Caso o leitor não esteja familiarizado com testes unitários utilizando NUnit, é recomendada a leitura do artigo sobre testes unitários com NUnit na prática (ver Nota do DevMan 1).

Recomendações para se obter bons casos de testesA tarefa de definir código de teste unitário deve seguir algu-

mas recomendações, segundo (MARTIN, 2009). A primeira das recomendações gira em torno da velocidade com que um teste é executado. Um teste não deve ser lento para executar, isto é, deve ser escrito de tal forma que possa ser executado de forma rápida. Caso um teste não execute de forma rápida, possivelmente será necessária a limpeza do código de teste rapidamente.

A segunda recomendação revela que o acoplamento entre códigos de teste deve ser reduzido, de preferência eliminado. Um trecho de código de teste não deve estar contido no corpo de outro código de teste. Cada método de teste deve testar um método da aplicação, e não pode ser utilizado no todo ou em partes para testar outros métodos que não seja o que por natureza foi definido para ser testado por ele.

A terceira recomendação é acerca da portabilidade dos casos de teste. Um teste deve poder ser executado sobre o projeto desenvolvido, em qualquer lugar onde o projeto esteja, não somente em um local específico, como a máquina do desenvol-vedor. É importante se ter uma estratégia que permita que os testes sejam executados em um sistema mesmo que o sistema não esteja na máquina na qual foi concebido.

Outras duas recomendações sobre como os casos de teste de-vem ser concebidos e mantidos giram em torno da capacidade de validação de um caso de teste e sobre o momento ideal para se definir um caso de teste.

Sobre a capacidade de validação de um caso de teste, deve-se atentar para o tipo de saída que o teste fornece. A comparação deve ser bem clara, bem como a saída que o teste fornece. Deve ser possível identificar rapidamente, caso o teste falhe, o motivo

da falha ao comparar as saídas. Caso o teste falho necessite de uma análise de saída mais profunda, pode ser sintoma de que o método de teste não foi tão bem escrito como deveria.

Já a última recomendação revela a importância do momento certo para se definir o caso de teste, que deve ser no mesmo instante em que o código de produção for concebido. Código Limpo (MARTIN, 2009) sugere que o método de teste seja escrito antes mesmo do método a ser testado. Posteriormente, deve-se atentar para que o método da aplicação seja escrito de forma simples, de forma que possa ser testado.

Limpando casos de testeConsidere a Listagem 6 de código. Ela possui uma classe

chamada OperacoesMatematicas.

Listagem 6. Classe OperacoesMatematicas

1. public class OperacoesMatematicas2. {3. private String mensagem;

4. public void setMensagem(String texto)5. {6. mensagem = texto;7. }8. public String obterMensagem()9. {10. return mensagem;11. }12. public String dividirDoisNumeros(String primeiroValor, String segundoValor)13. {14. try15. {16. UInt32 numero1 = Convert.ToUInt32(primeiroValor);17. UInt32 numero2 = Convert.ToUInt32(segundoValor);18. UInt32 resultado = numero1 / numero2;19. mensagem = “ Resultado: “ + resultado;20. return mensagem;21. }22. catch (DivideByZeroException)23. {24. mensagem = “ Impossivel fazer divisão com 0”;25. return mensagem;26. }27. catch (FormatException)28. {29. mensagem = “ Não foi possivel a divisão. Entrada Inválida”;30. return mensagem;31. }32. catch (OverflowException)33. {34. mensagem = “ Não foi possivel a divisão com números Negativos”;35. return mensagem;36. }37. }38. }

OperacoesMatematicas possui um método chamado divi-dirDoisNumeros. Esse método é simples, consiste em apenas efetuar uma operação de divisão entre dois números. Esse é o cenário inicial para aplicação de um caso de teste, no qual pos-teriormente será possível ver a aplicação de algumas técnicas de código limpo. O método OperacoesMatematicas possui um fluxo normal, caso os dados inseridos sejam corretos no senti-do de permitir a divisão de forma natural, e outros fluxos de

Page 51: Engenharia de Software - Pontos de função

Edição 44 - Engenharia de Software Magazine 51

ARquitEtuR A E dESENvoLviMENto

exceção, que permitem que, caso alguma exceção seja levanta-da, a mesma seja capturada e envie uma mensagem ao usuário sobre o ocorrido. Testes neste sentido devem ser capazes de identificar se o método funciona com o esperado.

A Listagem 7 possui uma classe chamada TOperacoesMa-tematicas, que possui os casos de teste escritos para testar o método dividirDoisNumeros da Listagem 6.

Na Listagem 7, linha 3, tem-se a instanciação de um objeto da classe OperacoesMatematicas, classe que possui o método dividirDoisNumeros, método que será testado. A instanciação desse objeto permitirá a comunicação com a classe Operacoes-Matematicas. A classe da Listagem 7 recebeu o mesmo nome da classe da Listagem 6, a diferença está na primeira letra, ‘T’, que será utilizado para deixar claro que a classe é uma classe que possui código de teste.

Na classe da Listagem 7 existem quatro métodos de teste. O primeiro deles, linhas 5 a 11, permite descobrir se o cálculo de divisão será feito de forma correta. Para isso, espera-se que o resultado seja 5, em relação ao resultado da divisão do numero 10 por 2 (linha 9). O segundo método, linhas 13 a 26, permiti-rá descobrir se será levantada uma exceção, caso o segundo número da divisão for zero. O método de teste das linhas 28 a 41 permitirá o teste do cenário onde uma exceção será lan-çada caso seja inserido algum valor que não é um número. Já o último caso de teste, linhas 43 a 56, permite descobrir se o método a ser testado realmente emite mensagem de tentativa de divisão com números negativos.

Todos os casos de teste escritos para o método dividirDoisNu-meros (Listagem 6) passam no teste, o que indica que o método escrito funciona como o esperado. Os casos de teste escritos cumpriram seus objetivos. Muitas equipes de desenvolvimento os descartariam neste momento, mas o melhor a fazer é mantê-los guardados para futuros testes neste mesmo método.

Código Limpo (MARTIN, 2009) sugere que os casos de teste sejam mantidos, isto é, sejam armazenados, mas que, além disso, também possam evoluir assim como o código dos mé-todos da aplicação. Essa evolução diz respeito à limpeza do código dos casos de teste. Deve-se atentar para que as técnicas de limpeza de código sejam sempre aplicadas não só ao código da aplicação, mas também ao código de teste.

Além da aplicação das técnicas de código limpo, os casos de teste também devem estar de acordo com as recomendações descritas nesta seção, em “Recomendações para se obter bons casos de testes”. Analisando os casos de teste apresentados na Listagem 7, pode-se perceber que a primeira recomendação se encaixa nestes testes. Os testes da Listagem 7 executam rapidamente.

Sobre a segunda recomendação, pode ser visto que os casos de teste executam de forma independente, isto é, não precisam do resultado um do outro para executar. A terceira recomendação revela que os casos de teste devem permitir a execução em outros locais e não somente a máquina em que foi concebido. Essa recomendação se aplica a esses casos de teste, pois é possível rodar esses testes em outro local.

1. public class TOperacoesMatematicas2. {3. private OperacoesMatematicas operacao = new OperacoesMatematicas();

4. [Test]5. public void test1()6. {7. UInt32 n1 = 10;8. UInt32 n2 = 2;9. UInt32 result = n1 / n2;10. Assert.AreEqual(5, result);11. }12. [Test]13. public void test2()14. {15. try16. {17. UInt32 n1 = 10;18. UInt32 n2 = 0;19. UInt32 result = n1 / n2;20. }21. catch (DivideByZeroException)22. {23. operacao.setMensagem(“ Impossivel fazer divisão com 0”);24. }25. Assert.AreEqual(“ Impossivel fazer divisão com 0”, operacao. obterMensagem());26. }27. [Test]28. public void test3()29. {30. try

31. {32. UInt32 n1 = Convert.ToUInt32(“sdsd”);33. UInt32 n2 = 2;34. UInt32 result = n1 / n2;35. }36. catch (FormatException)37. {38. operacao.setMensagem(“ Não foi possivel a divisão. Entrada Inválida”);39. }40. Assert.AreEqual(“ Não foi possivel a divisão. Entrada Inválida”, operacao.obterMensagem());41. }42. [Test]43. public void test4()44. {45. try46. {47. UInt32 n1 = Convert.ToUInt32(-10);48. UInt32 n2 = 2;49. UInt32 result = n1 / n2;50. }51. catch (OverflowException)52. {53. operacao.setMensagem(“ Não foi possivel a divisão com números Negativos”);54. }55. Assert.AreEqual(“ Não foi possivel a divisão com números Negativos”, operacao.obterMensagem());56. }57. }

Listagem 7. Código da classe TOperacoesMatematicas.

Page 52: Engenharia de Software - Pontos de função

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

Basta levar o projeto para ser executado em outra máquina. Ela deve apenas possuir a instalação do NUnit.

A recomendação de número quatro mostra que os casos de teste devem ser facilmente verificados, no que se refere às saídas por eles produzidas. As saídas produzidas pelos métodos das linhas 13 a 56 mostram que, caso um teste falhe, é possível identificar facilmente o motivo, pois os retornos mostrarão duas mensagens, em cada método de teste, sendo uma mensagem esperada e outra mensagem encontrada. Caso sejam diferentes, é possível identificar a diferença no mesmo instante. O método de teste das linhas 5 a 11 mostrará, em caso de falha, dois números, um número esperado e o outro encontrado, o que permite facilmente a comparação. A ultima recomendação é acerca do momento em que o caso de teste foi definido, no caso da Listagem 7, definido no mesmo instante em que o método dividirDoisNumeros, Listagem 6, foi definido.

Os casos de teste da Listagem 7 foram definidos de acordo com as recomendações desta seção. Resta neste instante ve-rificar se eles foram implementados seguindo os princípios de código limpo, que diz respeito à aplicação das técnicas de limpeza de código.

Em primeira análise, é possível perceber que os casos de teste da Listagem 7 não possuem nomes significativos, o que dificulta o entendimento, apensar de serem simples, sobre o funcionamento do caso de teste. Nesse sentido, os casos de teste evidenciam a necessidade de uma evolução, ou seja, aplicação de técnicas de código limpo referente à mudança para nomes significativos. A Listagem 8 mostra o resultado destas mudanças.

A utilização de nomes significativos permitiu que os casos de testes se tornassem mais condizentes com seus propósitos. Os casos de teste da Listagem 7 apresentavam nomes que permitiam apenas saber, em primeira análise, que se referiam a um conjunto de quatro métodos de teste, mas seus nomes não demonstravam a relação existente com o método dividir-DoisNumeros, da classe OperacoesMatematicas.

A partir das modificações da Listagem 8, é possível perceber facilmente que os quatro casos de teste existentes referem-se ao método dividirDoisNumeros. Cada um dos casos de teste refere-se a uma parte do método que está sendo testada. O nome testarDividirDoisNumeros, juntamente com o número do caso de teste, no caso de um a quatro, permite visualizar que existem quatro diferentes testes para o método dividir-DoisNumeros. Além da mudança do nome dos casos de teste, foram alterados os nomes das variáveis de todos os métodos de teste. Os antigos nomes não revelavam a real intenção das variáveis. Com estas mudanças, os casos de testes agora refle-tem melhor seus propósitos.

Os casos de teste da Listagem 8 executam perfeitamente sobre os métodos que testam. A Figura 1 mostra os casos de teste ao serem executados.

Os casos de teste possuem nomes significativos, mas ainda possuem outros problemas. Se analisados, os casos de teste mostram uma grande quantidade de código similar entre os

Listagem 8. Código da Listagem 7 modificado.

1. public class TOperacoesMatematicas2. {3. private OperacoesMatematicas operacao = new OperacoesMatematicas();4. [Test]5. public void testarDividirDoisNumeros1()6. {7. UInt32 numero1 = 10;8. UInt32 numero2 = 2;9. UInt32 resultado = numero1 / numero2;10. Assert.AreEqual(5, resultado);11. }12. [Test]13. public void testarDividirDoisNumeros2()14. {15. try16. {17. UInt32 numero1 = 10;18. UInt32 numero2 = 0;19. UInt32 resultado = numero1 / numero2;20. }21. catch (DivideByZeroException)22. {23. operacao.setMensagem(“ Impossivel fazer divisão com 0”);24. }25. Assert.AreEqual(“ Impossivel fazer divisão com 0”, operacao. obterMensagem());26. }27. [Test]28. public void testarDividirDoisNumeros3()29. {30. try31. {32. UInt32 numero1 = Convert.ToUInt32(“sdsd”);33. UInt32 numero2 = 2;34. UInt32 resultado = numero1 / numero2;35. }36. catch (FormatException)37. {38. operacao.setMensagem(“ Não foi possivel a divisão. Entrada Inválida”);39. }40. Assert.AreEqual(“ Não foi possivel a divisão. Entrada Inválida”, operacao.obterMensagem());41. }42. [Test]43. public void testarDividirDoisNumeros4()44. {45. try46. {47. UInt32 numero1 = Convert.ToUInt32(-10);48. UInt32 numero2 = 2;49. UInt32 resultado = numero1 / numero2;50. }51. catch (OverflowException)52. {53. operacao.setMensagem(“ Não foi possivel a divisão com números Negativos”);54. }55. Assert.AreEqual(“ Não foi possivel a divisão com números Negativos”, operacao.obterMensagem());56. }57. }

casos de teste, como pode ser visto nas linhas 7 a 9, 17 a 19, 32 a 34 e 47 a 49 (Listagem 8), além de outros trechos de código que não deveriam estar no corpo do método. Sendo assim, torna-se necessária a modificação dos casos de teste para eliminar o código duplicado. O objetivo da remoção do código duplicado é também eliminar código que foi copiado do método a ser testado. A Listagem 9 apresenta os casos de teste da Listagem 8 depois da remoção da duplicação.

Page 53: Engenharia de Software - Pontos de função

Edição 44 - Engenharia de Software Magazine 53

ARquitEtuR A E dESENvoLviMENto

Figura 1. Casos de teste sendo executados

Listagem 9. Código da Listagem 8 modificado.

1. public class TOperacoesMatematicas2. {3. private OperacoesMatematicas operacao = new OperacoesMatematicas();4. [Test]5. public void testarDividirDoisNumeros1()6. {7. String resultado = operacao.dividirDoisNumeros(“10”, “2”);8. Assert.AreEqual(“ Resultado: 5”, resultado);9. }10. [Test]11. public void testarDividirDoisNumeros2()12. {13. String resultado = operacao.dividirDoisNumeros(“10”, “0”);14. Assert.AreEqual(“ Impossivel fazer divisão com 0”, resultado);15. }16. [Test]17. public void testarDividirDoisNumeros3()18. {19. String resultado = operacao.dividirDoisNumeros(“sdsd”, “0”);20. Assert.AreEqual(“ Não foi possivel a divisão. Entrada Inválida”, resultado);21. }22. [Test]23. public void testarDividirDoisNumeros4()24. {25. String resultado = operacao.dividirDoisNumeros(“-10”, “2”);26. Assert.AreEqual(“ Não foi possivel a divisão com números Negativos”, resultado);27. }28. }

Os métodos de teste da Listagem 9, em relação aos mesmos métodos da Listagem 8, possuem diferenças significativas. A primeira delas é a remoção de código duplicado. A segunda refere-se ao fato de que as alterações que os métodos de teste sofreram melhoraram a qualidade do código de teste ao fazer chamada ao método a ser testado ao invés de carregar o código semelhante ao do método testado.

Em detalhes, as mudanças ocorridas nos métodos da Listagem 9 fazem o método das linhas 4 a 9 receber o resultado do método que está sendo testado, ao passar para ele duas strings com valores 10 e 2. O resultado recebido é comparado ao resultado esperado, como pode ser visto na linha 8. O mesmo ocorre com os demais métodos. No segundo método, são testados os valores, passados como strings 10 e 2 (linha 13). No terceiro método são

passados os valores, em strings “sdsd” e 0 e, por último, o quarto método, que realiza os testes com os valores -10 e 2, em forma de strings, como pode ser visto na linha 26.

Os métodos de teste foram alterados e, portanto devem ser tes-tados novamente, para certificar que as mudanças ocorridas nos métodos não afetaram seus funcionamentos. O resultado dos testes pode ser visto na Figura 2, que deixa claro que os testes foram executados com sucesso, o que indica que a remoção de código duplicado e fora de contexto ocorreu como planejado.

Figura 2. Métodos de teste executados com sucesso

ConclusãoA série sobre Código Limpo vem cumprindo seu objetivo

que é o de prover conhecimento sobre como melhorar a quali-dade de código das aplicações. A cada novo artigo, diferentes seções vêm sendo apresentadas, cada uma com um propósito específico, mas todas contribuindo para a obtenção de código considerado limpo.

Neste artigo foram apresentadas as seções Limites e Teste de Unidade. A seção Limites contribui para a melhoria do código que estabelece os limites existentes entre a aplicação e o código de terceiros, e a seção Teste de Unidade destaca a importância de manter guardados os casos de teste escritos, mas mais impor-tante do que isto, mantê-los sempre limpos, fazendo com que a qualidade do código de teste evolua sempre juntamente com a qualidade do código da aplicação que ele testa.

• MARTIN, Robert C, 2009. Código Limpo: Habilidades Práticas do Agile Software, 1ed. Rio de

Janeiro: Alta Books, 2009.

Referência

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

seu Feedback

sob

re esta edição

Page 54: Engenharia de Software - Pontos de função

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

Assista ao vídeo e descubra maissobre a Campus Party Brasil