Engenharia de Software - Pontos de função

  • 2,124 views
Uploaded on

 

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
2,124
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
163
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Processo engenharia magazine Conheça os modelos de processo pessoal de software Processo Edição 44 - Ano 04 Uma visão geral do CMMIAprimore suas estimativas de tamanho de projeto Agilidade Agilidade Requisitos Requisitos para Scrum e o gerenciamento Gerenciando mudançasalcançar agilidade de projetos - Parte 3 a partir de requisitos Modelos de processo pessoal http://www.devmedia.com.br/post-23264-Modelos-de-processo-pessoal.htmlDesenvolvimento DesenvolvimentoDesenvolvimento de aplicações de Conheça técnicas para manterrealidade aumentada seu código “limpo” – Parte 6
  • 2. Rodrigo Oliveira Spínola rodrigo.devmedia@gmail.com Doutorando 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.Ano 4 - 44ª Edição - 2012 Marco Antônio Pereira Araújo maraujo@devmedia.com.br Doutor e Mestre em Engenharia de Sistemas e Computação pela COPPE/UFRJ - Linha de Pesquisa em Engenharia de Software, Especialista em Métodos Estatísticos Computacionais e Bacharel emCorpo Editorial 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 doEditorRodrigo Oliveira Spínola 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çãoColaboradores Educacional D. André Arcoverde, Analista de Sistemas da Prefeitura de Juiz de Fora, ColaboradorMarco Antônio Pereira Araújo da Engenharia de Software Magazine.Eduardo Oliveira SpínolaJornalista Responsável Eduardo Oliveira SpínolaKaline Dolabella - JP24185 eduspinola@gmail.com É Colaborador das revistas Engenharia de Software Magazine, Java Magazine e SQL Magazine. É ba-Na Web charel em Ciências da Computação pela Universidade Salvador (UNIFACS) onde atualmente cursa owww.devmedia.com.br/central(21) 3382-5038 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 Fale com o Editor!A DevMedia conta com um departamento exclusivo para o atendimento ao leitor. Se É muito importante para a equipe saber o que você está achando da revista: que tipo de artigo vocêvocê tiver algum problema no recebimento do seu exemplar ou precisar de algum gostaria de ler, que artigo você mais gostou e qual artigo você menos gostou. Fique a vontade paraesclarecimento sobre assinaturas, exemplares anteriores, endereço de bancas de entrar em contato com os editores e dar a sua sugestão!jornal, entre outros, entre em contato com: 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ê gostariawww.devmedia.com.br/mancad(21) 2220-5338 de publicar. ApoioPublicidadePara informações sobre veiculação de anúncio na revista ou no site entre emcontato com:publicidade@devmedia.com.brEDITORIAL N a fase inicial de um projeto, a necessidade em obter o custo, prazo e o Neste contexto, esta edição da Engenharia de Software Magazine destaca esforço é observado em todas as empresas, pois as mesmas precisam como tema de capa Análise de Ponto de Função. Para isto, trazemos um artigo gerar um orçamento para os seus clientes e avaliar uma série de cujo objetivo é apresentar de forma simples, por meio de exemplos, o uso de projeções. um método poderoso para a solução destes problemas recorrentes, a APF Inicialmente não se tem conhecimento de todas as características do produto (Análise de Ponto de Função). bem como da sua real dimensão, por esse motivo é necessário utilizar técnicas Além deste artigo, teremos mais sete nesta edição: de extração de requisitos para realizar um levantamento inicial dos mesmos e • Requisitos para agilidade no desenvolvimento de software compreender melhor o problema. Os requisitos são condições, características • Scrum e o gerenciamento de projetos – Parte 3 ou capacidades necessárias para atingir uma finalidade, categorizados na • Modelos de processo pessoal implementação de sistemas em funcionais e não funcionais como forma de • CMMI – Uma visão Geral estabelecer critérios de qualidade. • Gerenciando mudanças a partir de requisitos Uma vez definidos os requisitos, pode-se então avaliar o tamanho do sistema • Introdução ao desenvolvimento de aplicações de realidade aumentada em termos de suas funcionalidades. Existem vários métodos de estimativa, a • Boas práticas para escrita de métodos, funções e procedimentos – Parte 6 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 Equipe Editorial Engenharia de Software Magazine 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.
  • 3. ÍNDICEAgilidade06 - Requisitos para agilidade no desenvolvimento de software Flavio S. Mariotti13 - Scrum e o gerenciamento de projetos – Parte 3 Fábio CruzEngenharia Aplicada20 - Estimativas de tamanho em projetos de software utilizando pontos de função Jhoney da Silva Lopes e José Luis BragaEngenharia Fundamentos32 - CMMI – Uma visão Geral Lenildo Morais36 - Gerenciando mudanças a partir de requisitos José Alberto Zimermann, Thiago Carvalho de Sousa e Rodrigo Oliveira SpínolaArquitetura e Desenvolvimento42 - Introdução ao desenvolvimento de aplicações de realidade aumentada André Luis Tosato, Victor Angelo Marcorin, Thiago Salhab Alves e Paulo Barreto da Silva47 - Boas práticas para escrita de métodos, funções e procedimentos – Parte 6 Jacimar Fernandes Tavares e Marco Antônio Pereira Araújo
  • 4. Edição 05 - Engenharia de Software Magazine 5
  • 5. Agilidade Nesta seção você encontra artigos voltados para as práticas e métodos ágeis. Requisitos para agilidade no desenvolvimento de software Necessidades requeridas para equipe, programas e empresa individuais, com a adoção de alguns métodos como De que se trata o artigo? XP, Scrum, Lean entre outros. No entanto, esses Este artigo apresenta uma proposta sobre níveis métodos começaram a se espalhar para o nível das de requisitos ágeis, práticas correspondentes aos empresas e uma série de fatores começaram a exigir papéis sugeridos e um modelo organizacional que um escopo organizacional mais amplo para suportar proporciona um formato de empresa ágil. O objetivo os desafios da governança desses novos processos. é escrever os requisitos que se fazem necessários para Neste sentido, o objetivo do artigo é fornecer um a criação de uma equipe ágil, programas que ofereçam modelo que ajude a obter uma visão elevada do suporte ao primeiro nível e a fase e maturidade da conceito ágil e seus requisitos para maturidade de empresa ágil. uma empresa ágil. Em que situação o tema é útil? Na última década, a criação de modelos de engenharia Resumo DevMan de software cada vez mais ágeis foi a mudança mais Este artigo discute o tema requisitos para agilidade significativa que afetou as empresas de software no desenvolvimento de software. Para isso, será desde o advento do modelo em cascata na década de apresentado, sob diferentes perspectivas, como 1970. Nos últimos cincos anos, as metodologias ágeis a questão da agilidade pode ser considerada em começaram a se espalhar nas empresas de software. equipes de projetos de software que trabalhem As iniciativas geralmente começaram com equipes considerando os princípios da agilidade. O desenvolvimento de software TI, vêm disponibilizando diversas meto- Flavio S. Mariotti se tornou um dos fatores mais dologias para apoiar essa difícil tarefa de flaviomariotti@gmail.com importantes da tecnologia. desenvolvimento de software, tais como: Especialista em Engenharia e Arquitetura de Software. Pós Graduado pelo Instituto O software que é produzido hoje se tor- modelo cascata, espiral, RAD, RUP, de Pesquisa Avançada de Tecnologia IBTA na rapidamente um item fundamental Crystal, Scrum (ler Nota Devman 1), em Engenharia de Software baseado em para organizações e usuários finais no XP (ler Nota Devman 2), FDD (ler Nota SOA. Bacharel em Sistemas de Informação intuito de acelerar e auxiliar a execução Devman 3), Lean, DSDM entre outros. pela UNIUBE e técnico em Processamento de diferentes tarefas. Com a evolução rápida dos recursos de Dados pela FEB. Consultor independente no desenvolvimento de software em Nos últimos 50 anos diferentes grupos, computacionais, o escopo do software se arquitetura OO, SOA, GIS e Plataforma .NET. especialistas e pesquisadores da área de altera com a mesma velocidade, exigindo6 Engenharia de Software Magazine - Requisitos para agilidade no desenvolvimento de software
  • 6. agilidadecomo um dos principais itens do desenvolvimento de software suporte aos processos, como distribuir a responsabilidadea agilidade na produção. Porém, como criar produtos com me- de cada envolvido no processo e qual a importância dessanos tempo e com a mesma eficiência? São dúvidas como essas distribuição.que vem transformando nossas metodologias na tentativa dealcançar o melhor e mais ágil modelo de desenvolvimento de Requisitos ágeis para a equipesoftware. É importante ressaltar que o modelo de equipe que será Contudo, será que somente uma boa metodologia é o sufi- apresentado neste artigo tem como principal propósito au-ciente para apoiar essa difícil missão? A resposta certamente é xiliar o time de desenvolvimento a se organizar ao definirNÃO. Para se obter agilidade no processo de desenvolvimento papéis, distribuir responsabilidades e criar as atividades parade software é preciso aplicar o conceito nos três pilares que um projeto no modelo ágil. Sendo assim, é de total valia usarfazem parte deste trabalho, que são: equipe, programas e em- esses conceitos para modelar e adequar a sua equipe na suapresa. Esse é o principal objetivo deste artigo, proporcionar realidade.ao leitor uma breve abordagem do que se faz necessário para Sabemos que um dos grandes desafios é fazer com que aatingir a agilidade no desenvolvimento de software, quais os equipe incorpore o modelo ágil para contribuir ao máximorequisitos para criar um time ágil, quais os pilares e processos com o time. Recomendo aos interessados pela teoria da lide-que envolvem esse trabalho, qual o papel da empresa para dar rança de pessoas dar uma no lida modelo Tuckman’s stages of group development proposto pelo psicólogo americano Bruce Wayne Tuckman. Nota do DevMan 1 Funções e responsabilidades da equipe Ao estudar e analisar diversos modelos organizacionais de Scrum: Scrum é um framework para gerenciamento de projetos ágeis muito uma equipe ágil proposta em diferentes metodologias como utilizado na área de desenvolvimento de software. Uma das principais características XP, Scrum, Lean, entre outros, chega-se à conclusão de que a do Scrum é permitir o desenvolvimento de produtos complexos de uma forma estrutura organizacional de uma equipe ágil é basicamente a incremental e iterativa, contribuindo para decompor um grande produto complexo, mesma em todas metodologias. em pequenos subprodutos mais simples, mais rápidos e mais fáceis de serem O Scrum, por exemplo, propõe um modelo que se divide em desenvolvidos e entregues. No Scrum estas iterações são chamadas de Sprints, e uma três principais funções, são eles: Scrum Master (Responsável característica marcante de sua estrutura e aplicação é o controle sobre os trabalhos Ágil), Product Owner (Proprietário do Produto) e o resto da 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. Nota do DevMan 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 Nota do DevMan 2 com outras metodologias ágeis. Por exemplo, o RUP (Rational Unified Process) da IBM, uma metodologia considerada tradicional, trata o gerenciamento de projetos como XP: O eXtreme Programming ou XP é um modelo ágil de desenvolvimento de uma disciplina dentro do seu framework, já que o seu foco está na Engenharia de software criado em 1996 por Kent Bech no Departamento de Computação da Software em si. Já o SCRUM, tem no papel do Scrum Master, uma figura parecida com montadora de carros Daimler Chrysler. Ele possui muitas diferenças em relação a de um Gerente de Projetos formal, mas que tem seu foco na facilitação dos trabalhos a outros modelos, podendo ser aplicado a projetos de alto risco e com requisitos por parte da equipe técnica. O foco dessa metodologia está na auto-organização da dinâmicos (vagos ou em constante mudança), conduzidos por equipes de tamanho equipe e, para isso, são necessários analistas seniores. médio e pequeno. O ponto forte da metodologia FDD está na capacidade de realizar features. Para esta Como todo método ágil, o XP procura responder com velocidade às mudanças nas metodologia, uma pequena feature possui um alto valor para o cliente. O exemplo de especificações do projeto, com base em princípios, valores e práticas bem definidos. uma feature está em um caso de uso com a função de “calcular a média de salário dos Este método enfatiza o desenvolvimento rápido garantindo a satisfação do cliente gestores” ou de “realizar um relatório integrado de vendas” e assim por diante. Veja , e cumprindo as estimativas do projeto. O XP baseia-se em cinco valores para guiar que não é estranha a menção do termo “caso de uso” para exemplificar uma feature, o desenvolvimento: Comunicação, Coragem, Feedback, Respeito e Simplicidade. já que a ideia é similar. Essa descrição do requisito que o FDD chama de feature são Segundo Beck, o método oferece ainda 12 práticas, a saber: i) Jogo do planejamento; os casos de uso no RUP e as estórias utilizadas no XP. O site www.agilemodeling. ii) Versões pequenas; iii) Metáfora; iv) Projeto simples; v) Teste; vi) Refatoração; vii) com/essays/fdd.htm destaca que uma lista de features é inicialmente indicada para Programação em pares; viii) Propriedade coletiva do código; ix) Integração contínua; que seja elaborado o planejamento do projeto com estimativas de esforço para sua x) 40 horas de trabalho semanal; xi) Cliente presente; e xii) Padrões de codificação. execução. Basicamente, esta é a proposta do FDD. Edição 44 - Engenharia de Software Magazine 7
  • 7. equipe que consiste principalmente de desenvolvedores e na equipe e se torna a metodologia do time, as regras sãotestadores de software. auto-impostas, fazendo com que a participação do Responsável Ágil se torne menos frequente e necessária. Resumidamente,Composição da equipe ágil as responsabilidades desta função se dividem em: A Figura 1 representa de forma gráfica o modelo organiza- • Facilitar o progresso da equipe em direção à meta;cional de uma equipe ágil. Na sequência conheremos cada • Liderar os esforços da equipe e buscar a melhoriaum desses papéis. contínua; • Fazer cumprir as regras do processo ágil; • Eliminar obstáculos. Desenvolvedores e Testadores A 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. Desenvolvedores O modelo de trabalho aplicável aos desenvolvedores pode serFigura 1. Ilustração do nível de equipes o modelo de programação em par com outro desenvolvedor, ou também emparelhado com um testador ou outro modeloProprietário do produto ágil, de forma a operar mais independente e ter interfaces com Como já definido no Scrum, o proprietário do produto tem múltiplos testadores e desenvolvedores. Contudo, a responsa-como característica atuar como a única função arbitrária, ou bilidade desta função é basicamente a mesma, são elas:seja, esse papel é responsável por determinar e priorizar as • Codificar os requisitos;necessidades dos utilizadores e gerenciar os itens acumulados • Colaborar com os testadores e proprietários do produto(product backlog). É importante lembrar que esse artigo não garantindo a codificação do produto de forma padronizadadescreve Scrum como metodologia a ser seguida. Indepen- conforme definição da equipe;dente da metodologia que sua equipe adotou como ágil, é • Codificar e executar as unit test;recomendada a aplicação da função proprietário do produto, • Garantir o check-in e check-out do código feito diariamente;já que esse papel vem mostrando verdadeiros avanços na • Participar ativamente na melhoria do ambiente desimplificação do trabalho exercido pela equipe. desenvolvimento. Contudo, as responsabilidades do proprietário do produ-to são ainda maiores. Segundo o princípio Agile Manisfesto Testadores#4 - “Homens de negócio e desenvolvedores devem trabalharem Os testadores são parte fundamental e integrante da equipejuntos diariamente durante o andamento do projeto”. Com base ágil. Os testadores estarão presentes logo no primeiro código anesse princípio, o proprietário do produto é a função ideal ser liberado, e se faz necessário passar pela aplicação de testespara orientar a equipe e participar diariamente com a mesma e aprovação do time de testadores. A principal responsabilida-em suas atividades no intuito de direcionar e definir suas de atribuída a essa função é a liberação do código fonte paraprioridades. produção ou continuidade do fluxo de trabalho. É de extrema Podemos dizer então que o proprietário do produto é o prin- importância o cumprimento desse requisito para se obtercipal responsável pela definição e priorização de requisitos. qualidade e agilidade no desenvolvimento de software. OutrasPortanto, a função proprietário do produto é responsável pelas responsabilidades atribuídas a essa função são:seguintes atribuições: • Criar casos de testes e aprovação;• Trabalhar com todos stakeholders (gerentes, analistas, clientes • Interface com os desenvolvedores e proprietário do produtoe interessados) do projeto para determinar os requisitos; para garantir e certificar o entendimento das funcionalidades• Priorizar as atividades com base no valor relativo do requeridas;cliente; • Executar os testes de aprovação;• Definir motivos para iteração, atuar e elaborar relatórios, • Desenvolver teste de aprovação para a atualização de com-participar e revisar processos buscando melhoria contínua. ponentes no ambiente de produção.Responsável Ágil Especialistas O responsável ágil é geralmente o papel do líder do projeto. Não podemos deixar de ressaltar a importância de recursosEssa função tem como responsabilidade dirigir o time para compartilhados e interfaces para outras funções. Segundo oalcançar suas metas e, em alguns projetos, é importante so- princípio Agile Manifesto #11 - “As melhores arquiteturas, requisitos emente na fase de transição. Quando o modelo ágil é imposto projetos emergentes de equipe auto-organizadas.”. Assim sendo, se faz8 Engenharia de Software Magazine - Requisitos para agilidade no desenvolvimento de software
  • 8. agilidadenecessário estabelecer um trabalho colaborativo com especialista desenvolver e testar o software. Neste nível as equipes sãoque, não necessariamente fazem parte da equipe, porém contri- capacitadas e trabalham a partir de um backlog local que estábuem com seus conhecimentos. Alguns desses papéis são: sob o gerenciamento do proprietário do produto. O proprie-• Arquitetos de software; tário do produto tem o controle para definir, construir e testar• Especialistas de qualidades QA; seus componentes fase a fase. Com base nos princípios do Agile• Especialistas de infraestrutura; Manifesto, esse é o mecanismo ideal para incentivar e motivar• Administradores de bancos de dados; a equipe para produzir os resultados positivos.• Especialistas em gerenciamento de configuração; No nível de programa, será apresentado um processo orga-• Especialistas de implantação. nizacional e modelo de requisitos que fornece mecanismos para aproveitar os recursos que integram as equipes ágeisConceito ágil para um propósito maior, ou seja, a entrega de um sistema ou Sabendo que o intuito de desenvolver software com agilidade um conjunto de aplicativos para os clientes. Neste momentonão exclui a principal necessidade de criar aplicativos eficien- os problemas são outros e a empresa irá enfrentar diferentestes que agregue valor ao cliente, precisamos assegurar que desafios para executar com sucesso o conceito de agilidade.as equipes ágeis estejam aplicando modelos simples, porém Resumidamente, as metas neste nível são:abrangendo todos os requisitos possíveis. Uma vez escutei uma • Roadmap: definir e comunicar a visão do programa e manterfrase que dizia: “O difícil é fazer o simples, o complexo todo mundo um roteiro;faz”. Resumindo, o significado dessa frase é: neste momento • Gerenciamento de liberação: Coordenar as atividades das equi-precisamos garantir que a equipe não esteja sendo sobrecar- pes para definir critérios de liberação;regada com requisitos desnecessários que não agregam valor • Gestão da qualidade: Assegurar a qualidade do sistema, desem-ao cliente e não geram resultado para a equipe. penho, segurança, e quaisquer normas impostas anteriormente devem ser atendidas;Histórias de usuários • Implantação: A definição de critérios para implantação deve Essa função é originada do modelo XP. Histórias de usuá- ser gerida no nível de programa;rios (User Stories) vem com a proposta de substituir o famoso • Gestão de recursos: Ajustamento dos recursos conformerequisitos de software. Este item ágil atualmente faz parte necessário para enfrentar as limitações e dificuldades nados modelos Scrum, XP e na maioria das outras metodologias capacidade do programa para entregar o valor necessário emágeis. A responsabilidade e definição desse usuário se resume tempo hábil;em: “Uma breve descrição dos principais objetivos que levam as • Eliminação de obstáculos: Os líderes e gestores de progra-necessidades dos clientes através de fluxo de valor”. mas são responsáveis por eliminar bloqueios que atrasem a Ao contrário de requisitos que definem o que o sistema “deve” equipe.fazer na maioria das vezes como obrigação contratual, históriasde usuários são breves declarações de usuários expressando Equipes recursos e equipes componentessuas intenções que descrevem um recurso que o sistema “pre- Nesta parte do artigo será apresentado como funcionam ascisa” fazer para alguns usuários ou departamento. equipes de recursos e componentes. Vamos fazer uma com- A principal proposta dessa função é transmitir à equipe de binação e comparação para demonstrar os resultados organi-desenvolvimento o que realmente traz benefícios ao usuário zacionais à equipe de organização. Em minha opinião, essa éagregando valor ao produto, ensinando a equipe a se concen- uma das decisões mais difíceis para serem tomadas. Percebertrar no que realmente agrega valor ao negócio do usuário. a necessidade e decidir a inclusão de uma dessas duas equipes para agilidade do projeto requer muito cuidado.Backlog A última função que integra uma equipe ágil é o backlog. Equipes recursosO produto backlog consiste em acumular todos os recursos Uma equipe de recursos ou em inglês Feature Team, é basi-necessários a serem implementados, identificados pela equipe camente um time com diferentes habilidades, ou seja, umaágil com base em todas as histórias de usuários. equipe composta com profissionais de diversas competências A responsabilidade dessa função é acumular os itens a serem para desenvolver um recurso de ponta a ponta.desenvolvidos com base nas histórias dos usuários. Embora Para ilustrar a diferença entre equipes de recursos e equipesexistam diversas tarefas a serem executas como: itens de confi- de componentes, vamos imaginar um cenário típico nos proje-guração, requisitos de infraestrutura, entre outras atividades, tos corporativos. Em uma arquitetura como a apresentada nao principal objetivo do backlog é concentrar a atenção da equipe Figura 2 em que as equipes se organizam em torno de camadas,nas histórias de usuário. teríamos neste momento seis equipes, sendo uma para cada camada. O modelo organizacional por equipes de componentesRequisitos ágeis para o programa dirige o time para uma variedade de problemas como: No nível de equipe, foi introduzido um conceito que aborda • Nível de comunicação reduzida em todas as camadas;a criação de equipes de software preparadas para definir, • Trabalha com o sentimento de que o projeto apresentado no Edição 44 - Engenharia de Software Magazine 9
  • 9. • contrato é o suficiente; das necessidades da equipe de recursos. No caso do Scrum, o• Finaliza o desenvolvimento da camada sem um produto proprietário do produto irá auxiliar a equipe de componentepotencialmente utilizável. 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 deFigura 2. Ilustração de arquitetura de projeto decisão, é necessário compreender a fundo as vantagens e desvantagens das equipes descritas acima para uma escolha A proposta da equipe de recursos seria, em vez de ter equipes apropriada.separadas por camadas da arquitetura, termos as equipes de Nas grandes empresas, onde há diversas equipes, recursosrecursos trabalhando em todas as camadas. e sistemas que em algumas vezes são compostos por siste- Algumas vantagens podem ser obtidas neste modelo orga- mas ou componentes, o modelo de equipes provavelmentenizacional, são elas: será uma mistura entre equipes de recursos e equipes de• As equipes de recursos têm mais habilidades para avaliar componentes.o impacto das decisões de projetos. Essa habilidade é adquira É recomendado uma certa inclinação para as equipes de re-pelo fato do time construir a funcionalidade de ponta a ponta, cursos. Alguns especialistas acreditam que uma boa estratégiaisso maximiza o aprendizado dos membros auxiliando nas para empresa ágil é permanecer no 70%-30% ou 80%-20% dedecisões que se fazem necessárias para o projeto; equipes de recursos para equipes de componentes. O espe-• Reduz o desperdício de esforços da equipe, ou seja, o risco de cialista em projetos ágeis, Chad Holdor, ou como ele gosta decriar funcionalidade demasiada é consideravelmente menor; ser chamado, o Agile Ninja, publicou um vídeo em seu blog• Garante que as pessoas certas estão falando, ou seja, uma detalhando claramente as diferenças entre equipes de recursosequipe de recursos inclui todas as habilidades necessárias para e equipes de componentes e no final recomenda um modeloir da idéia a execução do recurso; ágil combinando membros da equipe de componentes para• Diminui o risco de integração do componente com os re- fazer a equipe ágil como ilustrado na Figura 3. Esse vídeo podecursos, ou seja, um componente desenvolvido pela equipe ser encontrado no endereço: http://www.scaledagiledelivery.de componente só tem valor depois de integrado ao produto com/2011/04/28/component-vs-feature-team/.da equipe de recursos, sendo assim, o esforço para integraro trabalho da equipe de componente ao produto precisa sercalculado. O especialista em projetos ágeis, Mike Cohn, publicou umartigo em seu blog apresentando alguns benefícios obtidoscom a equipe de recursos que pode ser encontrado no ende-reço http://blog.mountaingoatsoftware.com/the-benefits-of-feature-teams.Equipes componentes Embora seja fortemente recomendado o uso de equipes derecursos, 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 entreguea uma outra equipe do projeto, em vez de diretamente ao Figura 3. Combinando membros da equipe de componentes para fazer acliente. Um exemplo seria uma equipe de componente desen- equipe de recursosvolvendo uma camada de mapeamento entre a aplicação e obanco de dados. A equipe de sistemas O gerenciamento de equipe de componentes nem sempre Como visto, as equipes ágeis são os motores de produçãoé uma tarefa fácil. Geralmente as equipes de componentes de um software. Aprendemos que cada equipe precisa tertrabalham paralelas às equipes de recursos. É importante habilidades necessárias para especificar, projetar, codificar egarantir que a equipe de componentes tenha conhecimento testar os componentes e recursos de seu domínio.10 Engenharia de Software Magazine - Requisitos para agilidade no desenvolvimento de software
  • 10. agilidade No entanto, no nível de programa, essas equipes formadas backlog do programa como recursos normais, ou seja, usandopor pessoas podem não ter todas as características necessárias o mesmo conceito de histórias de usuários. Alguns exemplospara concluir uma solução completa. Com isso, às vezes se faz de como esses requisitos podem ser solicitados são:necessário adicionar uma equipe que complemente as equipes • O cliente solicita que o aplicativo funcione nos principaisde recurso ou componentes. Essas equipes são formadas de navegadores do mercado;sistemas que podem auxiliar nos testes de sistemas, sistema • O cliente exige que uma determinada funcionalidade sejade garantia da qualidade, sistema de integração, suporte na executada em no máximo 30 segundos;infraestrutura de desenvolvimento e etc. • O cliente solicita disponibilidade de 99,99% do sistema.Equipe de gerenciamento e liberação Nas melhores práticas que procedem uma empresa ágil, paracada produto existe um time de planejamento e lançamentoque a empresa utiliza para alinhar as equipes técnicas com asequipes de negócios para o lançamento. Esta equipe é necessária porque, embora as equipes ágeissejam habilitadas, não tem necessariamente a visibilidadedo negócio, ou até mesmo a autoridade para decidir quandoserá a entrega do produto para o usuário final. Geralmenteessa equipe é formada pelos principais membros do nível deprograma da empresa, tais como:• Linha de negócio; Figura 4. Ilustração básica de uma planilha de roteiros• Proprietário e gerente do produto;• Representantes de marketing; Teste de requisitos não-funcionais• Gerentes associados aos produtos; Requisitos não-funcionais, como desempenho, disponibilida-• Equipe de implantação do produto. de e outros do gênero, são frequentemente descritos pelo cliente como qualidade do produto, porém devem ser aplicados no É recomendado que essa equipe faça reuniões semanalmen- backlog como um histórico de usuário e tratado como recurso,te ou em um período adequado à importância do produto. assim aplicando os testes para sua qualidade. A Figura 5 ilustraA reunião tem como principal foco debater a situação do um modelo simples para aplicação de testes de qualidade nosproduto, tais como: status; onde estamos; se vamos cumprir requisitos não-funcionais.a tempo nossos objetivos; mudanças necessárias; impactos,entre outros. O principal intuito desse encontro é promover a visibilidadeampla e o gerenciamento sênior semanal para o estado de Figura 5. Modelo básico de teste de requisitos não-funcionaisliberação do produto. Geralmente a maior parte dos requisitos não-funcionais (0..*)Roteiro ou Roadmap requerem um ou mais testes. Neste cenário, pode ser aplicado A equipe de gerenciamento e liberação no final de cada fórum outro tipo de testes de aceitação. Aplica-se então os testesresulta nos dados do planejamento da versão que são usados de qualidade de sistemas. Este termo indica que estes testespara atualizar a planilha de roadmap. devem ser executados em intervalos periódicos no intuito de O roteiro deve ser composto com as datas planejadas para validar o sistema.os lançamentos de cada solução, cada qual com o consultor derecursos priorizando conforme a necessidade do negócio. A Requisitos ágeis para a empresaFigura 4 representa o modelo de um roadmap. O terceiro e último requisito ágil que será apresentado neste O roteiro está sujeito a alterações em qualquer fase do pro- artigo é o nível empresa ou portfólio. Nesta etapa, encontramosduto, essas alterações podem ser causadas por questões como: a função de gestão de portfólio que inclui equipes e organiza-prioridade de negócio, fatores técnicos entre outros fatores ções dedicadas à gestão dos investimentos e conformidadesimprevisíveis, portanto, não se deve fazer compromissos ex- com a estratégia de negócio da organização.ternos com planos além do próximo lançamento. Para muitas fábricas de software atualmente, independente do tamanho de seus projetos ou equipes, o modelo de equi-Requisitos não-funcionais pes junto ao modelo de programas podem ser o suficiente A visão também precisa conter os requisitos não-funcionais, para gerenciar seus projetos de forma ágil. No entanto, paratais como: confiabilidade, desempenho, qualidade, compatibili- empresas que contém muitos produtos em que a governançadade e etc. Os requisitos não-funcionais devem ser descritos no e o modelo de gestão para o desenvolvimento de novos ativos Edição 44 - Engenharia de Software Magazine 11
  • 11. de software exige novos artefatos e níveis ainda mais altos de É importante que essa administração ocorra de forma contí-abstração, a inclusão do modelo de portfólio pode ajudar no nua em cada um dos níveis apresentados.gerenciamento desses novos desafios. ConclusãoRequisitos de investimento É importante ressaltar que o modelo com níveis de equipes, Um conjunto de temas de investimento estabelece os objetivos programas e empresas apresentados neste artigo é uma de-de investimento em relação à empresa ou unidade de negócio. finição arbitrária. Portanto, o objetivo é fornecer um modeloEste tema é o item que representa uma série de iniciativas que mental que ajude a elevar o alcance de abstração e escala paraimpulsionam os investimentos da empresa para determinada se obter agilidade no desenvolvimento de software.solução, produto ou serviço. Em resumo, vimos um conjunto de requisitos que são otimizados para apoiar a entrega rápida das necessidades valiosas do cliente.Equipe de gestão de portfólio Também vimos como as equipes ágeis podem alcançar a qualidade A equipe de portfólio pode ser formada pelos gerentes ou mais alta através de testes funcionais e automação de teste.responsáveis pelo negócio. Os membros desta equipe são os No nível de programa, foram apresentados requisitos, artefatosindivíduos que tem a responsabilidade final com as linhas de e processos que são necessários para alcançar o desenvolvimentonegócio. Em algumas empresas, esse processo pode ser com- ágil. Foi apresentado um modelo organizacional para auxiliar naparado aos processos de elaboração orçamentária anual. montagem de equipes otimizadas para a entrega ágil de valor. A equipe de gestão de carteira/portfólio toma suas decisões E, para concluir, introduzimos o nível de empresa. Nestacom base em uma combinação das seguintes opções: fase foi apresentada de forma resumida uma abordagem sobre• Investimento em ofertas de produtos, melhorias, suporte e os temas de investimento estratégico, gestão de portfólio emanutenção; arquitetura de melhoria contínua.• Investimento em novos produtos, novos serviços ou trabalho Linkscomercial para ganhar novas fatias de mercado;• Reduzir investimento para as ofertas existentes que estão Mike Cohn’s blog Succeeding with agile http://www.mountaingoatsoftware.com/chegando ao fim de sua vida útil ou lucrativa. Chad Holdorf’s blog Para fornecer governança e visibilidade nesta fase de investi- http://www.scaledagiledelivery.com/mentos, a equipe de gerenciamento de portfólio pode ser diri- Dean Leffingwell, Agile Software Requirements: Lean Requirements Practices for Teams,gida pelas melhores práticas de um modelo de gerenciamento Programs, and the Enterprise, Addison-Wesley Professional, 2010.de projetos como PMO. Craig Larman; Bas Vodde, Scanling Lean & Agile Development, Addison-Wesly Professional, 2008Arquitetura: empresa, programa e equipe Chris Sterling; Brent Barton, Managing Software Debt: Building for Inevitable Change, Addison- Ao obter maturidade ágil a organização tende a continuar a Professional, 2010.construção e conservação de uma arquitetura de responsabili-dade eficaz. Ao administrar e gerenciar esses níveis de requi- Mike Cohn, Succeeding with Agile: Software Development Using Scrum, Addison-Wesleysitos que resultam em agilidade, a empresa pode evitar alguns Professional, 2009acontecimentos ruins, porém comuns, como por exemplo: Dê seu feedback sobre esta edição! Feedback• Atrasos consideráveis para o lançamento do produto; eu s Dê• Redução do risco de criar uma arquitetura sem capacidade A Engenharia de Software Magazine tem que ser feita ao seu gosto. sobre ede se estender, deixando o sistema frágil e instável a mudanças, Para isso, precisamos saber o que você, leitor, acha da revista!correndo o risco de ser totalmente reescrito; s ta edição Dê seu voto sobre este artigo, através do link:• Evita o desperdício de esforços no desenvolvimento e mausinvestimentos. www.devmedia.com.br/esmag/feedback12 Engenharia de Software Magazine - Requisitos para agilidade no desenvolvimento de software
  • 12. Engenharia Nesta seção você encontra artigos voltados para testes, processo, modelos, documentação, entre outros Scrum e o gerenciamento de projetos – Parte 3 O Scrum e a sua relação de aliança com o gerenciamento de projetos tradicional De que se trata o artigo? informação através da união de artefatos de origem Demonstrar como utilizar os artefatos de um geren- ágil com outros de origem tradicional, fornecendo ciamento ágil como o Scrum, suportando e dando reflexões e provocando ações para unir as duas abor- apoio aos artefatos também complementares do dagens em um mesmo projeto. gerenciamento tradicional, apresentando como esta união pode ser benéfica para um mesmo projeto, Resumo principalmente na área de gerenciamento das co- Para se gerenciar projetos de desenvolvimento de municações, proporcionando um acompanhamento softwares é preciso estar constantemente atuali- transparente e bem próximo da execução do projeto. zado com as informações do projeto, e ao mesmo tempo comunicar a todos os interessados com a Em que situação o tema é útil? frequência necessária. Este artigo mostra como Este artigo visa demonstrar como resolver problemas aliar os artefatos de uma abordagem ágil como o gerados por falhas de comunicação entre a equipe do Scrum ao gerenciamento de projetos tradicional, projeto, sua gerência sênior e o cliente, apresentando gerando benefícios e melhorando a comunicação formas de eliminar os buracos causados pela falta de do projeto em várias direções. I ndependente do método utilizado Entende-se gerência sênior, neste caso, Fábio Cruz para executar e gerenciar projetos, a como o patrocinador do projeto (Sponsor) fabiorcruz@gmail.com comunicação continua sendo a área e as demais gerências compostas pelo Graduado na área de TI e PMP certifica- mais importante quando se fala do su- corpo diretivo responsável pelo projeto, do com mais de 17 anos de experiência profissional, atuando sempre na área de cesso em projetos. Simplesmente porque tanto na empresa executora quanto na desenvolvimento de sistemas, sendo os úl- a comunicação precisa acontecer para empresa contratante. timos 10 dedicados à liderança de equipes que o projeto seja entendido, executado Esta comunicação tem o objetivo e à coordenação de projetos. Atualmente e entregue. principal de posicionar e informar. gerente de projetos na empresa americana Outro objetivo fundamental da comu- Normalmente estes posicionamentos Ascendant Technology, voluntário no PMI Chapter de Santa Catarina e autor do blog nicação é manter a gerência sênior das são requisitados periodicamente e www.fabiocruz.com especializado em ge- empresas envolvidas com o projeto in- geralmente incluem análises de valor renciamento de projetos. formadas sobre o andamento do mesmo. agregado, marcos principais (milestones), Edição 44 - Engenharia de Software Magazine 13
  • 13. últimas realizações do período, principais riscos, situação fi- Scrum. Porém, não iremos comparar o Scrum a nenhuma abor-nanceira atual do projeto, entre outras informações relevantes dagem tradicional específica, mas sim tratar o gerenciamentoque podem variar um pouco de acordo com o projeto e com a de projetos como uma área de conhecimento geral, com seusnecessidade de informação das gerências. aspectos comuns em várias abordagens de mercado. Quando o projeto está no início, ou quando está tudo bem A primeira parte tratou de papéis e responsabilidades, acontrolado e o cliente satisfeito, a comunicação visando po- segunda falou das práticas, ferramentas e técnicas. Por fim,sicionar e informar costuma ser desvalorizada, feita de uma nesta terceira parte, falaremos dos artefatos existentes nas duasforma resumida demais e deixando de ser um valor real para abordagens, agindo de forma complementar e influenciandoquem as recebe, ou seja, deixando de informar aos interessa- diretamente no resultado da comunicação do projeto.dos dados importantes sobre o projeto. Este comportamentofaz parecer que a comunicação não é necessária quando tudo Gerenciamento ativo e não reativoestá indo bem. Antes de sair comunicando, a equipe de gestão precisa ter o Por outro lado, quando o projeto está com problemas, ou que comunicar e saber como fará a distribuição das informaçõesem fases críticas, um simples relatório de situação do projeto coletadas. Este pode ser o ponto mais importante, que definirá(Status Report) pode ser um drama para um gerente ou para uma boa ou uma má comunicação dentro de um projeto.uma equipe despreparada, e que principalmente não estava Um erro básico que parece simples de ser evitado, mas nainformando e posicionando desde o início do projeto. Sendo prática a sua ocorrência ainda é alarmante, é que os gerentesassim, o primeiro recado é que a comunicação deve ser reali- de projetos, ou as equipes de gerenciamento, não acompanhamzada sempre, durante todo o ciclo de vida do projeto. o projeto de perto, e não possuem informações constantemente A tarefa de comunicar e informar sobre o andamento do atualizadas. Isso gera um problema enorme, pois quando aprojeto deve ser simples, e é obrigatória para qualquer gerente. informação é solicitada, a gerência precisa reagir ao pedido ePorém, esta atividade que deveria ser simples, pode se tornar sair correndo atrás dos dados.um pesadelo pelo simples fato da equipe de gerenciamento Este gerenciamento reativo é ruim para todo o projeto, podendonão manter informações atualizadas e bem documentadas gerar insegurança e a geração de dados falsos, além de demons-sobre o projeto. Esta falta de informação centralizada faz com trar falta de metodologia implantada e organização definida.a equipe tenha que sair correndo atrás dos dados no dia da O objetivo deve ser sempre um gerenciamento ativo, ou seja,apresentação do Status Report, ou após a ligação da gerência não basta ter um modelo (template) de Status Report prontosênior pedindo informações atualizadas. para ser usado, é preciso ter sempre as informações que serão Buscando evitar este tipo de problema e facilitar a comuni- utilizadas para montar este relatório, e estas preferencialmentecação geral de um projeto, este artigo se propõe a apresentar devem ser as mais recentes possíveis. Neste ponto é que oum modelo de união de alguns artefatos de comunicação do Scrum pode nos ajudar com seus artefatos e regras.gerenciamento tradicional, com outros existentes no geren-ciamento ágil, mais especificamente no framework do Scrum, Artefatos do gerenciamento tradicionalcom o objetivo de interligar todas as partes interessadas de um O primeiro passo na direção de uma boa comunicação éprojeto através de informações corretas e bem distribuídas. ter as definições do que, como e quando serão realizadas as comunicações do projeto.Conceitos de gerenciamento ágil e tradicional Neste ponto, o gerenciamento tradicional é um forte aliado, Alguns conceitos importantes para o entendimento do Scrum pois quase todas as boas práticas e metodologias tradicionaisforam descritos nas primeiras duas partes desta série de arti- trazem em seu conteúdo a orientação de se criar um plano degos, que foram publicadas nas edições 41 e 43 da Engenharia gerenciamento da comunicação.de Software Magazine. Este plano é fundamental e deve ser construído e divulgado O framework do Scrum é uma das práticas ágeis mais utiliza- no início do projeto; o quanto antes melhor. Este documentodas atualmente, principalmente por trazer benefícios ao geren- não precisa ser extenso ou completo, pelo contrário, a orien-ciamento de projetos de software. Um destes benefícios mais tação é que seja curto e direto.evidentes é a forma com que o Scrum propicia a visualização O objetivo de um plano de gerenciamento da comunicação édos trabalhos do projeto de forma direta, objetiva e simples. determinar que tipo de informação deve ser veiculada durante Apoiado na qualidade do Scrum de contribuir para uma co- o projeto, como estas devem ser divulgadas, qual deve ser amunicação mais eficaz e eficiente, será demonstrado aqui como frequência de circulação de cada relatório informativo, e porcomunicar as informações mais relevantes para um acompanha- fim, quem deve receber cada um deles.mento de um projeto que está sendo executado. O acompanha- Outro artefato bem relevante e que se encaixa perfeita-mento poderá ser realizado pelo time de execução, pela equipe mente no tema comunicação, é o plano de gerenciamento dode gerenciamento operacional e pela gerência sênior. projeto. Este plano poderá conter o de comunicação, além de Mais uma vez, como nos artigos anteriores desta série, geralmente ser composto pelos planos de gerenciamento demostraremos como o Scrum complementa o gerenciamento requisitos, escopo, mudanças, riscos e qualidade. Todos estestradicional, assim como o gerenciamento tradicional apóia o sub-planos fornecem informações importantes para várias14 Engenharia de Software Magazine - Scrum e o gerenciamento de projetos – Parte 3
  • 14. Gerenciamento d e Projetospartes interessadas (stakeholders) pelo projeto, e geralmente monitoramento, usaremos apenas a estória que definiremosfazem parte do que será comunicado durante o projeto. a partir do seguinte padrão: O plano de projeto pode conter, inclusive, informações “Como um <tipo de usuário>, eu quero <um objetivo> parapertinentes de como as metodologias de gerenciamento de que <atenda uma necessidade>”.projetos serão aplicadas e como funcionarão conjuntamente Pegando o nosso item de Backlog “cadastro de livros” e criandoao longo do ciclo de vida do projeto. Já o plano de comu- uma estória com o padrão apresentado, teremos o seguinte:nicação deverá informar quais artefatos serão utilizados, “Como um usuário administrador, eu quero cadastrar um livroquais suas finalidades e origens conceituais (Scrum ou para que ele possa ser consultado por visitantes na internet”.tradicional). Como pode ser observado, é possível resumir todas as necessi- A partir destes documentos elaborados e divulgados corre- dades em poucas palavras, permitindo que seja possível colocartamente, todos os responsáveis ou interessados ligados dire- este texto em um post-it conforme ilustrado na Figura 1.tamente ou indiretamente ao projeto, poderão saber o que aequipe gerencial usará como artefatos de comunicação, alémde como e quando cada documento será distribuído. Note que esta preparação para se comunicar no decorrerdo projeto, já é uma comunicação efetiva, e demonstra quehá clareza e transparência na forma com que o projeto seráconduzido e acompanhado. Figura 1. Estórias em post-itsArtefatos do Scrum A partir das estórias definidas, o time poderá trabalhar O primeiro dos artefatos importantes do Scrum é o Backlog na reunião de planejamento da Sprint. Lembrando que estado Produto, que é o conjunto de todos os requisitos e trabalhos cerimônia é parte integrante do Scrum e foi descrita em maisnecessários para entregar o projeto. Este artefato pode incluir detalhes na Engenharia de Software Magazine 43.regras de negócios, protótipos de tela, casos de uso, entreoutros documentos relevantes. Tarefas Partindo de um Backlog do Produto completo para o projeto, Na primeira parte desta reunião de planejamento, o timeou para uma versão de entrega (release), se consegue obter os pró- entende as estórias e determina o tamanho de cada uma. Estaximos e mais detalhados documentos que fornecerão os dados estimativa servirá como artefato para medir o desempenhoimportantes para que as comunicações do projeto aconteçam. dos trabalhos no futuro. Já na segunda parte, o time detalha O Backlog do Produto se transforma no Backlog da Sprint, melhor as estórias, decompondo-as em tarefas menores.que deverá conter apenas os trabalhos selecionados para se Estas tarefas devem ter um tamanho apropriado para queentregar na próxima Sprint. A partir desta seleção de itens do possam ser determinadas em horas para conclusão, e devemBacklog, a equipe poderá ser apresentada a outro artefato do ser independentes de outras atividades para que sejam consi-Scrum, as estórias dos usuários. deradas finalizadas. Falamos mais sobre Backlog do Produto na edição 43 da O resultado desta decomposição das estórias em tarefasEngenharia de Software Magazine. menores será um dos mais importantes artefatos de controle que usaremos ao longo do projeto, pois estas tarefas menoresEstórias do usuário serão utilizadas para que toda a equipe do projeto saiba o que Uma estória do usuário (user story) é uma descrição resumida precisa ser realizado, o que está sendo trabalhado e o que jáque representa um item do Backlog, devendo ser sempre do foi concluído.ponto de vista do usuário final do produto. Em alguns casos um Uma estória é uma macro atividade, que resume um conjuntoitem de Backlog poderá dar origem a mais de uma estória, por de trabalhos. Este conjunto de trabalhos poderá ser ilustradoquestões de entendimento, ou para uma melhor visualização ou através de várias tarefas associadas, que por sua vez vão com-até por uma estratégia de abordagem gerencial e de execução. por a estória, como ilustrado na Figura 2. 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 eacompanhamento. É aqui que começamos a ter artefatos paramelhorar a comunicação, principalmente no nível gerencial. Um exemplo para um fácil entendimento é um “cadastrode livros”, que é um item de Backlog possuindo protótipo detela, modelo de dados, especificação de regra de negócio ecaso de uso. Estes são todos os documentos que compõem oitem de Backlog “cadastro de livros”, porém, para controle e Figura 2. Decomposição da estória em tarefas Edição 44 - Engenharia de Software Magazine 15
  • 15. Estamos falando destes dois artefatos porque precisamos • Laranja: Tarefas planejadas;de dados para acompanhamento e monitoramento do projeto • Verde: Tarefas não planejadas;conforme ele é executado, além de contribuir para o forne- • Vermelho: Impedimento, ou seja, obstáculo que está impe-cimento de informações consolidadas e atualizadas o mais dindo a realização de uma tarefa. Geralmente colocado sobrebreve possível. Com isso, começamos a colocar em prática a a tarefa impedida;comunicação do projeto durante a execução. • Amarelo: Tarefas de teste.Quadro de Tarefas (Taskboard) Com este quadro montado, a comunicação do projeto começa Este é um dos artefatos fundamentais e característicos do a tomar uma forma naturalmente clara, objetiva e transparente.Scrum, e possivelmente o que mais contribui para a comuni- Note que o quadro de tarefas ilustrado na Figura 3 pode sercação do projeto e colaboração do time. físico, e com isso fixado em uma parede bem visível para todos O quadro de tarefas nada mais é do que um espaço reserva- os interessados nas informações ali contidas.do para se colar ou fixar os post-its com as estórias e tarefas, Qualquer um que direcionar os olhares para o taskboard veráseparados por colunas e cores diferentes que proporcionam rapidamente um conjunto de informações condensadas em umuma rápida identificação da atividade e sua situação, conforme único local, tais como:ilustrada na Figura 3. 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 Figura 3. Quadro de tarefas do Scrum o planejado, pois de acordo com a regra do Scrum, somente depois de todas as tarefas da primeira linha estarem na coluna O formato mais utilizado para montar o quadro de tarefa é: “feito”, é que podem ser iniciadas as tarefas da segunda linha.• Coluna 1: As estórias são colocadas uma embaixo da outra, Neste caso, pode se tomar providências ao perceber um itemna sequência da mais importante para a menos importante sendo realizado fora de prioridade.de cima para baixo;• Coluna 2: As tarefas “a fazer” ao lado direito da sua respec- Este quadro de tarefas também pode ser virtual, a partir dativa estória; utilização de softwares de gerenciamento ágil de projetos que• Coluna 3: As tarefas que o time “está fazendo”, também ao permitem o cadastramento, acompanhamento e divulgaçãolado da sua respectiva estória; completa do taskboard. Um exemplo de uma ferramenta com• Coluna 4: As tarefas já concluídas (“feito”), na última coluna estas funções é o Rational Team Concert (RTC), que permiteà direita, também seguindo a mesma linha da sua respectiva o cadastro de projetos, de times, de Backlogs, de estórias e deestória; tarefas, além do acompanhamento da taskboard e do gráfico• Colunas complementares: Após a quarta coluna pode haver de Burndown.a coluna “não planejados”, para o agrupamento de tarefas não Outro detalhe importante sobre o taskboard é que os própriosprevistas e que surjam ao longo do desenvolvimento, e/ou integrantes do time mantêm as tarefas atualizadas no quadrocolunas antes da “feito”, para separação de itens na etapa de pelo menos uma vez por dia, com influência principalmente da“testes”, por exemplo. cerimônia conhecida como reunião diária, que pode ser vista em maiores detalhes na segunda parte desta série de artigos. Além das colunas distintas para cada etapa do desenvolvi-mento, também é sugerido que as tarefas sejam colocadas em Gráfico de Burndownpost-its menores que as estórias e que seja adotada uma cor A Sprint é a principal iteração no Scrum, e ela nos ajuda a di-diferente para cada tipo de tarefa, por exemplo: mensionar os trabalhos e controlar o projeto em ciclos menores16 Engenharia de Software Magazine - Scrum e o gerenciamento de projetos – Parte 3
  • 16. Gerenciamento d e Projetosde até um mês. Maiores detalhes sobre as Sprints podem ser en- 4. Ao final de cada dia da Sprint, ou no máximo no início decontrados na Edição 42 da Engenharia de Software Magazine. cada dia, marque no quadro a quantidade de trabalho restante A Sprint contém um conjunto de trabalhos a ser realizado em na coluna referente ao dia específico;um determinado espaço de tempo, por isso ela é muito útil para 5. Trace uma nova reta ligando os pontos marcados com o totalacompanhar a evolução do projeto. Porém, como fazer este acom- de trabalho restante a cada dia. Pronto, você terá a velocidadepanhamento e saber se o projeto está atrasado ou adiantado? real do time. A resposta não é tão difícil quanto parece, principalmentedepois de termos falado sobre o Backlog da Sprint, estórias Na ilustração da Figura 4, a linha vermelha representa ae tarefas. estimativa dos trabalhos a serem completados por dia, ou seja, Todas as tarefas que precisam ser realizadas dentro da Sprint a velocidade esperada marcada no início da Sprint.estão no taskboard, no entanto apenas olhar para o quadro de tare- A linha azul mostra a velocidade real do time de acordo comfas não diz a equipe de gerenciamento se o projeto está em dia ou os trabalhos que estão sendo completados a cada dia. Caso anão. Para resolver este problema entra em ação o último artefato linha azul (real) esteja acima da linha vermelha (estimada), ado Scrum que nos interessa aqui, o gráfico de Burndown. Sprint está atrasada, caso contrário, está adiantada. O Scrum como abordagem ágil se preocupa com o esforço Para a opção do quadro físico fixado em uma parede, o timerestante para se terminar o trabalho, e não com o que já foi do projeto pode atualizar as tarefas antes ou durante as reu-concluído. Em outras palavras, o que importa no controle niões diárias, que é a melhor opção.do Scrum é a quantidade de tarefas que ainda precisam ser Para a opção de taskboards virtuais através de softwares, optecompletadas até o final da Sprint. por ferramentas que se integrem com os ambientes de desenvol- O gráfico de Burndown representa visualmente a soma vimento e já atualizem automaticamente as tarefas em tempodas estimativas dos esforços restantes para se terminar os real. Por exemplo, quando um desenvolvedor encerra uma tarefatrabalhos contidos no Backlog da Sprint. Por isso, olhando o pela ferramenta de desenvolvimento, esta por sua vez atualizagráfico ilustrado na Figura 4, temos à esquerda uma coluna o software que mantém a taskboard também atualizada.com a quantidade de trabalho que precisa ser completada,sendo que no primeiro dia da Sprint o trabalho restante será Comunicação visualigual ao trabalho total. Seguindo 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 queFigura 4. Gráfico de Burndown. este modelo de trabalho se torna tão interessante. Os problemas e falhas realmente ficarão evidenciados, se Os dias estão na linha inferior do gráfico, e o acompanhamen- tornando um problema para os times que não buscam melhorarto é simples. Em resumo, o dia atual deve ter menos trabalho e corrigir seus defeitos. Para os demais, os resultados serão osrestante do que o dia anterior. Visualmente podemos fazer uma melhores possíveis, porque a própria equipe buscará a cadacomparação fácil que nos ajudará muito na identificação da iteração (Sprint) melhorar os seus resultados.evolução dos trabalhos, permitindo saber se estão adiantados Os bons times buscarão transformar o taskboard em umaou atrasados, da seguinte forma: evidência de seu bom trabalho, e não em um problema que1. No primeiro dia da Sprint, monte o gráfico colocando na mostra para todos os seus erros. Esta qualidade que o Scrumcoluna da esquerda a quantidade de trabalho necessário para proporciona pode ser entendida como um processo de me-completar a Sprint; lhoria contínua.2. Na linha inferior coloque os dias em que a Sprint ocorrerá;3. Por fim, trace uma linha ligando o total de trabalhos que Comunicação formalprecisam ser completados (coluna à esquerda) ao último dia da Com os trabalhos sendo realizados conforme as definiçõesSprint (à direita). Esta linha representará a velocidade média do tradicional plano de gerenciamento do projeto e seguindodo time para atingir a meta da Sprint; as cerimônias, regras e artefatos do Scrum descritos até agora, Edição 44 - Engenharia de Software Magazine 17
  • 17. Figura 5. Cronograma com milestonesnão vão faltar dados para se montar relatórios de situação e início do projeto for divulgado o conteúdo previsto dentro deinformações relevantes para reuniões de acompanhamento. cada fase e etapa ilustrada no cronograma. Mesmo com metodologias ágeis de gerenciamento de pro- A boa comunicação fica evidente quando há eliminação dejetos, como Scrum, haverá momentos em que será preciso duplicidades e de excesso de dados em relatórios de acompanha-gerar documentos formais para divulgação às gerências, pa- mento periódicos. Se você precisar colocar todas as informaçõestrocinadores, clientes, parceiros, e outros. Além de que estes do seu projeto, detalhadas ao máximo, em todos os seus relató-relatórios podem ser oficiais para aceite e/ou recebimento de rios de situação semanal ou mensal, com certeza houve falhasparcelas financeiras de trabalho completado ou simplesmente graves de comunicação inicial, e estas continuam ocorrendo.para acompanhamento gerencial. A partir do plano de comunicação realizado no início do pro- Relatórios de situação (Status Report)jeto, a equipe gerencial terá no planejamento oficial do projeto Dependendo do tamanho, complexidade, valor ou impor-alguns documentos conhecidos como meios de comunicação, tância de um projeto, os interessados nele podem quererpodendo ser, por exemplo: informações resumidas sobre a sua situação semanalmente,1.Cronograma de tarefas atualizado, principalmente eviden- quinzenalmente, mensalmente ou em outra frequência pré-ciando milestones, disponibilizado na internet em sites seguros definida. Por isso é de suma importância que a equipe decom acesso restrito; gerenciamento do projeto esteja preparada para fornecer as2. Relatórios de situação divulgados semanalmente por informações relevantes sempre que necessário.e-mail; O Status Report é um documento geralmente muito requi-3. Apresentações executivas para o comitê gestor, realizadas sitado e utilizado por gerentes do mundo inteiro. O formatomensalmente. ideal é aquele que consegue condensar todas as informações importantes em uma única página. Principalmente porque oCronograma Macro (milestones) objetivo deste relatório é informar rapidamente qual a situação O cronograma é uma ferramenta muito importante e in- do projeto, e para isso ele precisa ser objetivo para que quemteressante para apoiar os trabalhos do gerente de projetos, o receba o leia na íntegra.porém pode ser extremamente penosa e atrapalhar quando A equipe gerencial precisa ser clara e direta com problemas,mal utilizada. soluções, dificuldades, fracassos e até mesmo com os sucessos O detalhamento excessivo é um problema comumente en- e resultados obtidos. Então não é preciso fazer documentos ex-contrado nos cronogramas, e que dificulta muito o seu uso. tensos e cansativos. Informe o que é preciso, e se for necessário,Se este documento fosse criado apenas uma vez e nunca mais o interessado solicitará uma reunião ou documentos auxiliaresalterado, tudo bem, mas na vida real dos projetos isso é quase para esclarecimentos e maiores detalhes.impossível. Quanto mais detalhado o cronograma, mais ma- Um conteúdo interessante para um Status Report objetivo énutenção ele terá. apontar a situação geral dos trabalhos completados, podendo Para evitar este problema, uma sugestão é utilizar este docu- ser atrasado, em dia ou adiantado, e a situação financeira domento de apoio sem grande detalhamento de itens, tarefas ou projeto, apontando se os gastos estão dentro do previsto, abaixoníveis. Monte um cronograma mais macro e apenas com fases, ou acima do orçamento.milestones e iterações (Sprints), como ilustrado na Figura 5. Como complemento, a equipe gerencial pode colocar a fase Perceba que o cronograma fica mais enxuto, mas sem deixar em que o projeto se encontra e as últimas realizações. Além dode fornecer as informações importantes sobre datas e etapas apontamento de riscos para os próximos períodos e eventuaisconcluídas. Claro que ele só funcionará corretamente se no obstáculos que estejam impedindo os trabalhos.18 Engenharia de Software Magazine - Scrum e o gerenciamento de projetos – Parte 3
  • 18. Gerenciamento d e Projetos Todas estas informações são encontradas facilmente com o O Scrum ainda fornece informações para as comunicaçõesresultado da aplicação das cerimônias do Scrum como a reu- mais formais e que precisam seguir linhas mais oficiais de divul-nião diária, review e retrospectiva. Outra fonte de informação é gação, aprovação e registro, tais como cronogramas, relatóriosa análise das tarefas controladas pelo taskboard, e pela situação de situação e apresentações executivas para comitês gestores.do projeto mostrado no gráfico Burndown. Esta união de modelos tradicionais com o ágil mais uma vez Por isso é tão importante seguir as boas práticas de um se mostra positiva, e quando bem aplicada e complementada,modelo ou metodologia. Não é só burocracia, são passos na apóia de forma bem dinâmica e objetiva as equipes de geren-direção de solucionar problemas rotineiros e que podem ser ciamento de projetos.evitados. Seguindo as cerimônias, regras e artefatos do Scrum, Conforme o uso em conjunto destes dois modelos for cadanaturalmente será gerado insumo para realizar a comunicação vez mais aplicado, e os resultados forem expressivamentedo projeto de forma rápida, segura e eficiente. positivos, mais ficará evidente que não podemos considerar o tradicional melhor que o ágil, e nem tão pouco o ágil melhorReuniões de comitê executivo que o tradicional. Além dos cronogramas e relatórios divulgados para os As equipes de gerenciamento de projetos modernas e questakeholders do projeto, frequentemente há necessidade de apre- querem sobreviver neste mercado rápido, furioso e muitassentações executivas para um comitê gestor, como presidentes, vezes cruel, não podem se apegar a apenas um conjunto dediretores e conselheiros. conceitos, e precisam se adaptar, observar e acompanhar as Mais uma vez os materiais já gerados e utilizados para execu- mudanças do mercado, das tecnologias e das metodologias.ção, acompanhamento e comunicação do projeto serão úteis. Nada é perfeito, nem os seres humanos, nem as máquinas e Geralmente os gerentes montam apresentações em ferra- nem tão pouco os processos ou modelos, portanto, quando sementas como o Microsoft PowerPoint, e resumem os dados do tem em mente que se pode unir os melhores pontos positivosúltimo cronograma atualizado e do último Status Report para de cada abordagem, buscando uma melhor metodologia decompor a apresentação. aplicação, as chances de sucesso são bem maiores do que Dependendo do projeto a apresentação é focada mais na apostar todas as fichas em apenas uma delas.parte financeira, ou mais na parte de valor agregado e tarefas Lembre-se sempre que o objetivo principal do gerenciamentocompletadas, não costumando fugir muito disso. Mais uma de projetos, independente da abordagem, se resume a entregarvez as informações necessárias para a montagem de uma um projeto com sucesso. Por isso pense sobre a possibilidadeapresentação como esta podem ser coletadas, acompanhadas e de união de um modelo ágil como o Scrum a um modelo tra-resumidas através dos processos descritos neste artigo, ficando dicional, somando os pontos positivos, subtraindo os pontosmais fácil e rápido resgatá-las no momento oportuno. negativos, e obtendo como resultado final o sucesso de forma mais controlada, fácil e segura.Conclusão Tendo a comunicação como principal ferramenta de trabalho Linkspara se atingir o objetivo do projeto, é possível se alcançar Introdução ao Scrum, blog FabioCruz.comexcelentes resultados. Principalmente quando se segue boas www.fabiorcruz.wordpress.com/outros/introducaopráticas e teorias reconhecidas pelo mercado, tais como oScrum, combinando-as com experiências reais em projetos que Introdução ao PMBOK®, blog FabioCruz.comforam bem sucedidos com a ajuda de uma boa comunicação. www.fabiorcruz.wordpress.com/pmbok%c2%ae/introducao Como foi demonstrado, o Scrum é uma ótima abordagem Scrum Guide 2011, escrito por Ken Schwaber e Jeff Sutherlandpara melhorar a comunicação de todo o time do projeto www.scrum.org/scrumguidesdurante a execução do mesmo, mostrando claramente quaistrabalhos devem ser feitos, ou estão sendo realizados, ou já Dê seu feedback sobre esta edição! Feedbackforam completados. eu s Dê Os artefatos deste gerenciamento ágil também fornecem A Engenharia de Software Magazine tem que ser feita ao seu gosto. sobre einformações sobre velocidade e tamanho da equipe, riscos Para isso, precisamos saber o que você, leitor, acha da revista! s taevidentes através de impedimentos ou obstáculos aos traba- Dê seu voto sobre este artigo, através do link: ediçãolhos do time, além da situação atual do projeto, mostrando aevolução de tarefas completadas. www.devmedia.com.br/esmag/feedback Edição 44 - Engenharia de Software Magazine 19
  • 19. Engenharia Nesta seção você encontra artigos voltados para testes, processo, modelos, documentação, entre outros Estimativas de tamanho em projetos de software utilizando pontos de função Um tutorial voltado para micro e pequenas empresas De que se trata o artigo? Resumo Estimativa de software com derivações em custo, pra- Na fase inicial de um projeto, a necessidade em ob- zo e esforço é uma necessidade comum entre as em- ter o custo, prazo e o esforço é observado em todas presas de TI. Nesse contexto, o objetivo deste artigo é as empresas, pois as mesmas precisam gerar um Jhoney da Silva Lopes apresentar de forma simples, por meio de exemplos, orçamento para os seus clientes e avaliar uma série jhoney.lopes@gmail.com o uso de um método poderoso para a solução destes de projeções. Este artigo organiza de forma sim- Graduando em Ciência da Computação pela Universidade Federal de Viçosa (UFV). problemas recorrentes, a APF (Análise de Ponto de ples e introdutória conhecimentos sobre a Análise Atualmente é Diretor Presidente da em- Função). de Ponto de Função. presa júnior No Bugs (www.nobugs.com. Análise de Ponto de Função é um método de medição Inicialmente não se tem conhecimento de todas as br), Assessor da presidência da Skep Design do tamanho funcional de um software, com base em características do produto bem como da sua real (www.skepdesign.com) e Diretor Vice- operações extraídas dos requisitos funcionais. A partir dimensão, por esse motivo é necessário utilizar Presidente de O Primeiro Plano. Áreas de interesse: Engenharia de Software, Empre- dessa medição inicial de tamanho, derivam-se outras técnicas de extração de requisitos para realizar um endedorismo, Gerenciamento de Projetos e medidas como, por exemplo, o tempo necessário para levantamento inicial dos mesmos e compreender Business Intelligence. desenvolvimento, e uma estimativa inicial de custos. melhor o problema. Os requisitos são condições, ca- APF tem por definição medir o que o software deve racterísticas ou capacidades necessárias para atingir José Luis Braga fazer, e não como ele deve ser construído, portanto o uma finalidade, categorizados na implementação zeluis@dpi.ufv.br processo de medição é fundamentado em uma ava- de sistemas em funcionais e não funcionais como Pós-doutoramento em Tecnologias da In- liação padronizada dos requisitos lógicos do usuário. forma de estabelecer critérios de qualidade. formação na University of Florida. Doutor Uma vez definidos os requisitos, pode-se então em Informática pelo Departamento de In- Em que situação o tema é útil? avaliar o tamanho do sistema em termos de suas formática da PUC-Rio. Mestre em Ciências da Computação pelo Departamento de Ci- Na fase inicial de um projeto, existe a necessida- funcionalidades. Existem vários métodos de esti- ência da Computação da UFMG. Atualmen- de de obter o custo, prazo e o esforço de imple- mativa, a APF (Análise de Ponto de Função) é uma te é Professor Titular do Departamento de mentação para estabelecimento de contratos de delas. Esse método não tem como objetivo realizar Informática do Centro de Ciências Exatas desenvolvimento. Análise de Ponto de Função é estimativas de prazo, custo e esforço para imple- e Tecnológicas da Universidade Federal um método de medição do tamanho funcional de mentação de sistema, mas sim avaliar o tamanho de Viçosa-MG. Atua na área de Ciência da Computação, com ênfase em Engenharia software que permite fazer essas avaliações com de um sistema em termos de suas funcionalidades. de Software e Sistemas de Informação. base em informações disponíveis nas fases iniciais Resulta desta avaliação o tamanho funcional do Áreas de Interesse: Qualidade de Software dos projetos. O uso do método profissionaliza a sistema expresso em Pontos de Função (unidade com Foco em Processos, Engenharia de avaliação inicial de tamanho, permitindo repeti- de medida do método). A partir do tamanho fun- Software Experimental, Engenharia de ção do processo e aumento do nível de maturidade cional, podem ser derivadas estimativas adicio- Software Apoiada por Ontologias, Enge- nharia de Software Baseada em Agentes, no gerenciamento de projetos. nais, como tempo e custo. Sistemas de Apoio à Decisão.20 Engenharia de Software Magazine - Estimativas de tamanho em projetos de software utilizando pontos de função
  • 20. Gerenciamento d e ProjetosE ste artigo apresentará uma visão geral sobre todos os a visão do desenvolvedor, ou seja, uma visão técnica. Na APF passos necessários para utilização da análise de ponto o que importa é a visão do negócio e quem possui essa visão de função, para a realização de estimativas na fase é o usuário, lembrando que usuário na APF possui um con-inicial de um projeto de desenvolvimento, proporcionando ceito amplo e não é somente a pessoa que irá interagir com oao leitor uma visão restrita do método, mas suficiente para software final.estimar um projeto em sua fase inicial e, com isso, realizarderivaçõ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 Nota do DevMan 2Albrecht. A aceitação foi muito grande, e uma quantidadecada vez maior de pessoas começaram a utilizar o método, Funcionalidade: Funcionalidade é o conjunto de tarefas fornecidas pelo sistema pararesultando na criação do IFPUG (International Function Point poder realizar transação, processamento e armazenamento dos dados dos usuários.Users Group). Hoje o método é mantido e evoluído pelo IFPUGe fundamenta-se em seis passos:1. Determinar o tipo de contagem; Determinar o tipo de contagem2. Identificar o escopo da contagem e a fronteira da O primeiro passo para a contagem será determinar qual o tipoaplicação; de contagem a ser realizada, como pode ser visto na Figura 1.3. Contar funções: Na APF existem três tipos de contagem: a. Tipo dados; • Projeto de desenvolvimento; b. Tipo transação; • Projeto de melhoria;4. Determinar a contagem de pontos de f unção não • Aplicaçã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 epossui como unidade de medida o ponto de função (PF) (lerNota do DevMan 1). Nota do DevMan 1 Figura 1. Passos para a contagem dos pontos de função (VAZQUEZ, 2009) Usuário: Em Análise de Ponto de Função, usuário possui um conceito mais amplo: Este artigo tem por objetivo apresentar a solução de contagem qualquer entidade que se relacione com o sistema ou que produza um ônus ao mes- para projeto de desenvolvimento, mas serão apresentadas as mo. Ex: Pessoa, aplicação, leis, restrições, etc. diferenças entre elas. É importante perceber que para a APF o usuário não é somente a pessoa que inte- rage com o sistema. 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) Possui como base os seguintes objetivos: até a instalação do mesmo. Neste tipo de projeto são contadas• Medir as funcionalidades (ler Nota do DevMan 2) imple- na APF todas as funcionalidades fornecidas aos usuários até amentadas no sistema; instalação do sistema, ou seja, funcionalidades de conversão (ler• Medir esforço de implementação e de manutenção do softwa- Nota do DevMan 4) também são contadas. Só se pode saber todosre, independente de tecnologia, ou seja, a APF leva em consi- os requisitos de um sistema após o término do projeto, sendoderação o que o software faz e não como ele é construído; assim, toda a contagem de um projeto de desenvolvimento pode• Simplicidade, o trabalho para aplicar a APF deve ser o mí- ser entendida como estimativa e não medição.nimo possível, ele não deve ser um ônus no desenvolvimentodo software. Projeto de melhoria O projeto de melhoria mede todas as funcionalidades no- É importante ter em mente, durante todo o processo da vas, modificadas e excluídas de um determinado sistema.utilização do método de análise de pontos de função, que o Ao término de um projeto de melhoria a aplicação deveráusuário é quem define o que faz parte ou não do projeto, di- ser contada com o intuito de atualizar o valor em pontos deferentemente de alguns métodos que levam em consideração função da mesma. Edição 44 - Engenharia de Software Magazine 21
  • 21. Nota do DevMan 3 Nota do DevMan 5 Requisitos: São as necessidades e características que o sistema deve ter para atin- Escopo do Projeto: Escopo do projeto é o trabalho que precisa ser realizado para gir as expectativas do cliente. A extração dos requisitos consiste em uma parte crítica entregar um produto, serviço ou resultado com as características e funções especifica- na elaboração de uma proposta, ela é parte determinante do sucesso ou fracasso de das (PMBOK, 2004), o escopo da contagem é tudo aquilo que deve ser contado. um projeto. Uma sugestão simples para não errar nesta etapa é seguir a regra do IFPUG que é determinar a fronteira da aplicação Nota do DevMan 4 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. Funções de Conversão: Para um entendimento considere o exemplo: um sistema Considera-se o exemplo apresentado na Figura 2, que mostra A possui uma lista de funcionários cadastrados, o sistema B sendo contado deverá três aplicações, AP01, AP02 e AP03, separadas por fronteiras incluir todos esses funcionários em sua base de dados, essa funcionalidade será dispa- (círculos tracejados) e cada uma dessas aplicações interagem rada uma única vez que é durante a instalação do sistema, sendo caracterizada como umas com as outras, esta interação é feita a partir do que é função de conversão. chamado de arquivos lógicos, que aparecem na figura como quadrados preenchidos de preto. Aplicação Entende-se por contagem do tipo aplicação um softwareinstalado, ou seja, a contagem após o término de um projetode desenvolvimento. Neste caso, não se leva em consideraçãoas funções do tipo conversão.Aplicando o conhecimento – Determinar o tipo decontagem Neste artigo será realizada a contagem de um projetosimples, extraído da base de projetos da No Bugs - EmpresaJú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çãopara auxiliar na elaboração da proposta do projeto para ocliente. A sua contagem será de um projeto de desenvolvi- Figura 2. Arquivos lógicos e fronteiras das aplicaçõesmento, um sistema simples de locação de veículos. Aplicando o conhecimento – Identificar o escopo daIdentificar o escopo da contagem contagem O segundo passo para a contagem é identificar o escopo Como foi visto, nesta etapa devemos definir o escopo dada contagem e a fronteira da aplicação, como pode ser contagem e a fronteira da aplicação. No exemplo deste artigo,visto na Figura 1. Muitas vezes a identificação do escopo trata-se de software destinado a uma empresa que realizae da fronteira da aplicação não são levados tão a sério, locação de automóveis, o sistema é simples e composto porprincipalmente por empresas que não utilizam gerência uma única aplicação.de projetos no gerenciamento do desenvolvimento desoftware. Contar funções do tipo dados Esta é uma etapa crucial para o andamento do projeto, O terceiro passo para a contagem é dividido em duas par-a definição de um escopo (ler Nota do DevMan 5) errado tes, contar funções do tipo dados e contar funções do tipopode acarretar em prejuízos para o projeto ou até a perda transação, como pode ser visto na Figura 1. Funções do tipototal dele. O escopo define quais funções serão incluídas dados é o nome designado às funcionalidades fornecidas parana contagem, ele pode abranger todas as funcionalidades, o armazenamento de dados na aplicação sendo contada (lerapenas as funções utilizadas ou funções específicas. Nota do DevMan 6), são caracterizados como arquivos lógicos e A fronteira da aplicação é a linha que separa uma apli- eles podem ser mantidos pela aplicação ou lida de outra, comocação de outra. Dentro de um escopo de contagem pode pode ser visto na Figura 2.existir mais de uma aplicação a ser contada, por isso é Arquivos lógicos que estão dentro da fronteira da aplicaçãoimportante definir qual é a sua fronteira. e mantidos pela mesma são chamados de Arquivos Lógicos22 Engenharia de Software Magazine - Estimativas de tamanho em projetos de software utilizando pontos de função
  • 22. Gerenciamento d e ProjetosInternos (ALI), já os arquivos lógicos lidos de outra aplicação Não é exemplo:são chamados de Arquivos de Interface Externa (AIE). • 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 Nota do DevMan 6 um AIE. Determinação da complexidade e da contribuição Aplicação Contada: Como visto, um projeto pode ser composto por várias aplica- Complexidade é o grau de influência que um arquivo lógico ções internas que interagem umas com as outras, conforme a Figura 2. Quando um tem para o tamanho funcional do sistema. A contribuição é projeto possui mais de uma aplicação, diz-se da aplicação sendo contada a que no a conversão do grau de complexidade em pontos de função. momento está sendo analisada, já projetos que possuem apenas uma aplicação, o A complexidade é calculada a partir da contagem dos tipos de termo aplicação sendo contada refere-se a todo o projeto. dados e dos tipos de registro. Tipos de dados (TD) Arquivo Lógico Interno É um campo não recursivo de dado, único e reconhecido pelo Grupo lógico de dados persistentes e que são mantidos dentro usuário, em uma visão geral e limitada. Por exemplo, poderiamda fronteira da aplicação e alterados por meio de processos ser os atributos de uma tabela.elementares. Um processo elementar é a menor unidade deatividade significativa para o usuário final (VAZQUEZ,2009). Tipos de Registro (TR)É a menor funcionalidade disponibilizada ao usuário. É caracterizado por ser um subgrupo de dados. Considerando a Figura 2, a AP01 possui três arquivos lógicos Em uma análise míope, quando um agrupamento de tabelasinternos (ALI). À primeira vista, parecerá que cada tabela do é reconhecido pelo usuário como um único arquivo lógico,banco de dados da aplicação será um ALI. Essa é uma maneira ALI ou AIE, a tabela reconhecida pelo usuário é contada e assimples de entender o que seria um arquivo lógico, mas serão demais se tornam simplesmente tipos de registro, ou seja, essasmostrados alguns exemplos de que é um erro pensar dessa tabelas extras não pertencem à visão do negócio, pois o usuárioforma, pois um grupo de tabelas pode ser considerado como não as reconhece. Mas seus atributos são reconhecidos e, porum único arquivo lógico, dependendo da forma como é utili- este motivo, devem gerar um impacto na contagem, sendozado pela aplicação. denominado subgrupo de dados. Esses campos pertencentes à visão do negócio e reconhecidos pelo usuário são atribuídos Exemplos de ALI: aos demais arquivos lógicos que estão relacionados com esses• Arquivo de configuração, conexão, segurança (senhas) man- tipos de registro.tidos pela aplicação; Considera-se como exemplo uma especialização, onde a• Tabelas ou grupos de tabelas do banco de dados mantidas Figura 3 representa essa especialização na visão do usuário,pela aplicação. com os seguintes campos: id_func (código de identificação do funcionário), salário, cro (número do registro para dentistas), Não são exemplos: bolsa (bonificação no salário dos auxiliares).• 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 pelaaplicação que está sendo contada, ou seja, a aplicação sendocontada acessa os dados presentes neste arquivo lógico, maso mesmo não está dentro da aplicação que está sendo contadae sim em outra. Nesse caso denomina-se esse arquivo lógico Figura 3. Especialização na visão do usuáriode arquivo de interface externa (AIE). Considerando a Figura 2, a AP01 referencia arquivos lógicos Na modelagem, foram separados os diferentes tipos de fun-da AP02 e AP03, estes são os arquivos denominados de AIE. cionários, como pode ser visto na Figura 4. Neste exemplo contam-se os funcionários como uma ALI ou Exemplos de AIE: AIE, pois como foi apresentado, o usuário não reconhece fun-• Dados de segurança armazenados em arquivos lógicos e cionários como entidades diferentes, mas para a modelagem omantidos por aplicações específicas a este fim; desenvolvedor optou por separar estes funcionários devido aos• Dados salariais armazenados na aplicação financeira, mas atributos que os especializam. Como estas entidades criadas nautilizados pela aplicação contada. visão do desenvolvedor possuem atributos reconhecidos pelo Edição 44 - Engenharia de Software Magazine 23
  • 23. usuário, esse grupo de tabelas se constitui em uma ALI ou AIE Tabela de contribuiçãocom três tipos de registro e esses atributos reconhecidos devem A tabela de contribuição é padronizada pelo IFPUG, e todosser contados como atributo de funcionários. São contados três os usuários do método de análise de pontos de função utilizamtipos de registro, pois todo arquivo lógico é um tipo de registro os mesmos valores.dele mesmo e os atributos são somados a funcionários, pois Após identificar a complexidade de cada ALI e AIE dosomente ele é reconhecido pelo usuário. sistema, é possível determinar a contribuição desses para a É importante perceber que esta solução é adotada uma vez que contagem dos pontos de função.o usuário enxerga Auxiliar e Dentista como Funcionário, e não Após verificar na Tabela 1 a complexidade do ALI ou AIE, acomo entidades separadas, como pode ser visto na Figura 5. É tarefa para estabelecer a contribuição é muito simples, bastaimprescindível entender que um mesmo problema pode ter uma saber a complexidade do seu arquivo lógico e se o mesmo écontagem diferente com visões de negócios diferentes, ou seja, um ALI ou AIE e verificar o valor na Tabela 2.o importante é o ponto de vista do usuário para a APF. 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 Figura 4. Especialização é um tipo de registro 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 5. Visão do Negócio Tabela de complexidade A tabela de complexidade é padronizada pelo IFPUG, todosos usuários do método de análise de pontos de função utilizamos mesmos valores. Após o entendimento sobre tipo de dados e tipo de registro,os mesmos serão utilizados para definir a complexidade doarquivo lógico. Realiza-se a contagem dos tipos de registro etipos de dados de cada arquivo lógico, depois se verifica naTabela 1 o valor de cada um e o intervalo que pertence. Comisso, define-se a ALI ou AIE como sendo de complexidade Figura 6. Fluxo para classificação do tipo lógicobaixa, média ou alta. Passos para uma estimativa da contagem desta etapa Tipos de Dados a) Elabora-se um modelo lógico seu projeto, como exempli- < 20 20 – 50 > 50 Tipos de Registro ficado na Figura 7. 1 Baixa Baixa Média 2–5 Baixa Média Alta Identificam-se todas as tabelas reconhecidas pelo usuário, ou >5 Média Alta Alta seja, as que fazem parte da visão do negócio, classificando-as Tabela 1. Complexidade ALI e AIE como ALI ou AIE (vide Tabela 3).24 Engenharia de Software Magazine - Estimativas de tamanho em projetos de software utilizando pontos de função
  • 24. Gerenciamento d e Projetos 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 d) Determinação da contribuição de cada arquivo lógico e realização a soma de todos.Figura 7. Modelo lógico Para determinar a contribuição basta verificar na Tabela 2 o Descrição Tipo ponto de função referente a cada complexidade, o resultado é apresentado na Tabela 6. Usuário ALI Cliente ALI Descrição Tipo Qtd. TDs Qtd. TRs Complexidade Contribuição Carro ALI Usuário ALI 4 1 Baixa 7 Tabela 3. Classificação dos arquivos lógicos Cliente ALI 7 2 Baixa 7 Carro ALI 8 2 Baixa 7 Na Figura 7 as tabelas Usuário, Cliente e Carro foram carac-terizadas como arquivo lógico interno e Aluga foi definida Total de Pontos de Função = 21como tipo de registro de Cliente e Carro, pois a mesma não é Tabela 6. Contagem das funções do tipo dadosreconhecida pelo usuário, mas os seus atributos são. Contar funções do tipo transação b) Faz-se uma análise da todas as tabelas que não estão na O terceiro passo para a contagem é dividido em duas partes,visão do negócio: contar funções do tipo dados e contar funções do tipo transa-• Se a tabela não pertence à visão do negócio, mas os seus ção, como pode ser visto na Figura 1. Agora que foi aprendidotipos de dados pertencem, deve-se contá-la como um tipo de como contar funções do tipo dados, pode-se dar continuidaderegistro para cada arquivo lógico relacionado a ela, e atribuir à contagem da aplicação. As funções do tipo transação são asos seus tipos de dados a cada um deles; funcionalidades base para o funcionamento do sistema, essas• Se nem a tabela nem os seus tipos de dados pertencem à visão funções são chamadas de processos elementares e são classi-do negócio, deve ser descartada da contagem. ficadas em Entradas Externas, Saídas Externas e Consultas Externas. A tabela Aluga foi considerada um tipo de registro, pois na Um processo elementar é a menor unidade de uma funçãovisão do negócio, os campos hora_aluguel e data_aluguel são disponível ao usuário. Por exemplo, consultar clientes pode serreconhecidos pelo usuário e por este motivo eles foram somados entendido como uma função, mas o mesmo não pode ser en-aos tipos de dados de Cliente e Carro, conforme a Tabela 4. tendido como um processo elementar, uma vez que podem ser realizadas inúmeras consultas diferentes aos clientes: consultar Descrição Tipo Qtd. TDs Qtd. TRs clientes pelo nome, consultar clientes em débito, consultarUsuário ALI 4 1 registro de clientes, e outras mais. Pode-se perceber que cada consulta é uma funcionalidade única e independente. DestaCliente ALI 7 2 forma, para determinar um processo elementar é necessárioCarro ALI 8 2 identificar todas as funcionalidades únicas e independentesTabela 4. Tipo de Dado (TD) e Tipo de Registro (TR) de uma função. Uma observação importante é que um processo elementar Quando se tem uma relação entre mais de um arquivo lógico deve ser único. Por exemplo, consultas que diferem umas dascom uma entidade definida como tipo de registro, devem-se outras pela organização dos dados gerados, não podem seridentificar todos os atributos reconhecidos pelo usuário pre- consideradas diferentes.sentes nesta entidade tipo de registro e somá-los a todos osarquivos lógicos que se relacionam com esta entidade. Isso é Entrada Externa (EE)necessário, pois estes atributos influenciam aos demais arqui- Uma entrada externa é um processo de controle, ela tambémvos lógicos e geram impacto no desenvolvimento do projeto. realiza o processamento de dados do sistema e direciona o mesmo para atender os requisitos da aplicação. A principal c) Determinação da complexidade de cada arquivo lógico. intenção da EE é realizar operações que visam manter (incluir, Para definir a complexidade basta analisar a quantidade de alterar ou excluir) dados de um ou mais arquivos lógicos inter-tipos de dados mais as quantidades de tipos de registro e con- nos, realizando processamento, transação e armazenamentoferir na Tabela 1. O resultado é apresentado na Tabela 5. de dados dos usuários do software. Edição 44 - Engenharia de Software Magazine 25
  • 25. Uma EE deve ser única e não necessitar de ações anteriores e de uma ALI e/ou AIE. Esse processamento não deve possuirnem sucessores. Por exemplo, no envio de um e-mail, escrever lógica matemática, nem qualquer tipo de cálculo, não deveo destinatário, o assunto e o corpo do e-mail não podem ser gerar dados derivados e nem alterar o comportamento doentendidos como EE, pois não se constituem uma operação sistema. A CE é uma consulta simples e direta, com o retornocompleta, mas o conjunto de todas estas, e clicar no botão de da informação requisitada pelo usuário.envio é que se caracteriza como uma EE. Exemplos de Consulta Externa: Exemplos de Entrada Externa: • Consultar clientes pelo nome;• Transações destinadas a manter ALI, incluir funcionário, • Apresentar dados em formato gráfico a partir de recuperaçãoexcluir funcionário, alterar funcionário e etc.; simples.• Operações;• Processos destinados a realizar registros, por exemplo, em Não são exemplos de Consulta Externa:um sistema de ponto eletrônico o usuário registra entrada e • Relatórios financeiros, gerados a partir de cálculos;saída. • Telas de filtro. Não são exemplos de Entrada Externa: Determinação da complexidade e da contribuição• Telas de filtro; Complexidade é o grau de influência que um processo elemen-• Preenchimento de campos de dados; tar tem para o tamanho funcional do sistema. A contribuição é• Telas de login; a conversão do grau de complexidade em pontos de função.• Gerar relatórios. Essa complexidade é calculada a partir da contagem dos tipos de dados e dos arquivos referenciados. De modo geral, EEs possuem nomes característicos, comoincluir, alterar, salvar, excluir, editar, encaminhar, submeter Tipos de dados (TD)e registrar, dentre outros. É um campo não recursivo de dado, único e reconhecido pelo usuário, ou seja, é cada campo preenchido ou apresentado ao Saída Externa (SE) usuário. Por exemplo, em um formulário os campos nome, CPF, Processo elementar destinado à apresentação de informação endereço, o botão de confirmação, uma janela de mensagemao usuário ou a outra aplicação externa que utilize cálculos de erro, dentre outros, são tipos de dados. Já em um relatório,para processar essas informações. o código do produto, o nome, a descrição, o valor, são tipos de A principal intenção de uma SE é apresentar informação para dados. Em um gráfico, o raciocínio é o mesmo, conta-se umo usuário a partir de lógica de processamento, ou seja, as in- tipo de dado para o nome do produto, um para a quantidadeformações apresentadas devem passar por um processamento, e um para o valor, no total tem-se três tipos de dados nesteelas não devem ser simplesmente uma consulta simples. Este relatório, como pode ser visto na Figura 8.processamento pode ter como objetivo manter ALIs ou alteraro comportamento do sistema. Exemplos de Saída Externa:• Tela para liberar acesso (tela de login), sendo os dados datransação criptografados;• Relatórios financeiros, supondo esses gerados por cálculos;• Consultas complexas com processamento de dados a partirde cálculos;• Apresentação de gráficos com dados processados a partirde cálculos. Não são exemplos de Saída Externa:• Telas de filtro; Figura 8. Apresentação de relatório gráfico• Consultas simples, sem processamento de dados utilizando cálculos. Arquivo Referenciado (AR) Um arquivo referenciado é todo arquivo lógico lido, pode ser Consulta Externa (CE) um ALI ou AIE, ou todo arquivo lógico mantido, nesse caso Processo elementar que apresenta informação ao usuário ou só pode ser um ALI. Um tipo de registro não é um arquivoa outra aplicação externa por meio de recuperação simples. lógico, ele pertence a um arquivo lógico. Não se deve contarUma CE tem como principal intenção apresentar informações tipos de registro e arquivos lógicos lidos várias vezes. Essesao usuário por meio de uma simples recuperação de dados são contados apenas uma única vez.26 Engenharia de Software Magazine - Estimativas de tamanho em projetos de software utilizando pontos de função
  • 26. Gerenciamento d e Projetos Tabela de complexidade A tabela de complexidade é padronizada pelo IFPUG, todosos usuários do método de análise de pontos de função utilizamos mesmos valores. Após o entendimento sobre tipo de dado e arquivo referencia-do, pode-se utilizá-lo para definir a complexidade do processoelementar. Realiza-se a contagem dos tipos de dados e dosarquivos referenciados de cada processo elementar, depoisverifica-se na Tabela 7 ou na Tabela 8 o valor de cada um e ointervalo a que ele pertence, com isso definindo a EE, SE ouCE como sendo de complexidade baixa, média ou alta. Tipos de Dados Arquivos Referenciados <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) Tipos de Dados <6 6 – 19 > 19 Referenciados <2 Baixa Baixa Média Arquivos 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 Figura 9. Fluxo para classificação do processo elementar8 a SE e CE. Essa diferença é importante uma vez que processoselementares destinados a apresentar informação, possuem nor- O fluxo da Figura 9 foi idealizado para facilitar o entendimentomalmente mais tipos de dados e referenciam mais arquivos. do processo de determinação dos tipos de processo elementar. Esta é uma visão geral, o importante é saber qual a finalidade Tabela de contribuição do seu processo elementar. Por exemplo, um cadastro é uma EE A tabela de contribuição é padronizada pelo IFPUG, todos os que pode apresentar informações ao final do processamentousuários do método de análise de pontos de função utilizam que não o torna uma CE ou SE, pois sua finalidade poderiaos mesmos valores. ser cadastrar. Após identificar a complexidade de cada processo elementar Outra dica, quando não se reconhece a classificação de umado sistema, é possível determinar a contribuição desses para função de transação, pode ser que esta ainda não seja uma contagem dos pontos de função. processo elementar, cabe então reconhecer todos os proces- Após a definição da complexidade do seu processo elementar, sos elementares no interior desta função antes de verificar adefinir a sua contribuição é muito simples, basta saber a com- classificação em Entrada Externa (EE), Consulta Externa (CE)plexidade do seu processo elementar e se o mesmo é uma EE, ou Saída Externa (SE).SE ou CE e utilizar o valor correspondente na Tabela 9. Como primeiro passo para a contagem, deve-se identificar todos os processos elementares e classificá-los quanto ao seu Tipo de Função Baixa Média Alta tipo, conforme a Tabela 10. Entrada Externa 3 PF 4 PF 6 PF Determinam-se então os tipos de dados e os arquivos refe- Saída Externa 4 PF 5 PF 7 PF renciados (vide Tabela 11). Neste passo é necessário analisar cada processo elementar e definir seus tipos de dados e os Consulta Externa 3 PF 4 PF 6 PF arquivos que referencia.Tabela 9. Tabela de Contribuição Este passo é mais relevante quando os tipos de dados ou os arquivos referenciados estão na fronteira da mudança daAplicando o conhecimento – Contar funções do tipo complexidade. Longe da fronteira, erros neste ponto não irãotransação influenciar na contagem. Para finalizar o terceiro passo, deve-se determinar a conta- Verifica-se a complexidade, após definir os tipos de dados egem das funções do tipo transação. os arquivos referenciados, determinando a complexidade de Edição 44 - Engenharia de Software Magazine 27
  • 27. Descrição Tipo Descrição Tipo Qtd. TDs Qtd. ARs ComplexidadeIncluir Cliente EE Incluir Cliente EE 6 1 BaixaExcluir Cliente EE Excluir Cliente EE 3 1 BaixaAlterar Cliente EE Alterar Cliente EE 6 1 BaixaIncluir Usuário EE Incluir Usuário EE 3 2 BaixaExcluir Usuário EE Excluir Usuário EE 3 2 BaixaAlterar Usuário EE Alterar Usuário EE 3 1 BaixaIncluir Automóveis EE Incluir Automóveis EE 7 2 MédiaExcluir Automóveis EE Excluir Automóveis EE 3 2 BaixaAlterar Automóveis EE Alterar Automóveis EE 7 1 BaixaRegistrar Locação EE Registrar Locação EE 3 2 BaixaFinalizar Locação EE Finalizar Locação EE 4 2 BaixaLogin (com criptografia) SE Login (com criptografia) SE 4 1 BaixaConsulta clientes por nome CE Consulta clientes por nome CE 3 2 BaixaConsulta carros alugados CE Consulta carros alugados CE 3 2 BaixaConsulta data do aluguel CE Consulta data do aluguel CE 3 2 BaixaConsulta clientes com carro alugado CE Consulta clientes com carro alugado CE 6 3 MédiaConsulta carro mais alugado CE Consulta carro mais alugado CE 3 3 BaixaConsulta cliente que mais aluga CE Consulta cliente que mais aluga CE 3 2 BaixaTabela 10. Tipos dos processos elementares Tabela 12. Complexidade Descrição Tipo Qtd. TDs Qtd. ARs Descrição Tipo Qtd. TDs Qtd. ARs Complexidade ContribuiçãoIncluir Cliente EE 6 1 Incluir Cliente EE 6 1 Baixa 3Excluir Cliente EE 3 1 Excluir Cliente EE 3 1 Baixa 3Alterar Cliente EE 6 1 Alterar Cliente EE 6 1 Baixa 3Incluir Usuário EE 3 2 Incluir Usuário EE 3 2 Baixa 3Excluir Usuário EE 3 2 Excluir Usuário EE 3 2 Baixa 3Alterar Usuário EE 3 1 Alterar Usuário EE 3 1 Baixa 3Incluir Automóveis EE 7 2 Incluir Automóveis EE 7 2 Média 4Excluir Automóveis EE 3 2Alterar Automóveis EE 7 1 Excluir Automóveis EE 3 2 Baixa 3Registrar Locação EE 3 2 Alterar Automóveis EE 7 1 Baixa 3Finalizar Locação EE 4 2 Registrar Locação EE 3 2 Baixa 3Login (com criptografia) SE 4 1 Finalizar Locação EE 4 2 Baixa 3Consulta clientes por nome CE 3 2 Login (com criptografia) SE 4 1 Baixa 4Consulta carros alugados CE 3 2 Consulta clientes porConsulta data do aluguel CE 3 2 CE 3 2 Baixa 3 nomeConsulta clientes com carro alugado CE 3 3 Consulta carros CE 3 2 Baixa 3Consulta carro mais alugado CE 3 3 alugadosConsulta cliente que mais aluga CE 3 2 Consulta data do aluguel CE 3 2 Baixa 3Tabela 11. Tipos de Dados (TD) e Arquivos Referenciados (AR) Consulta clientes com CE 6 3 Média 4 carro alugadocada processo elementar consultando a Tabela 7 ou Tabela 8. Consulta carro mais CE 3 3 Baixa 3O resultado pode ser visto na Tabela 12. alugado Consulta cliente que A seguir, determina-se a contribuição de cada processo ele- CE 3 2 Baixa 3 mais alugamentar e realiza-se a soma de todos, conforme Tabela 13. Para determinar a contribuição basta verificar na Tabela 9 o Total de Pontos de Função = 57ponto de função referente a cada complexidade. Tabela 13. Contagem das funções do tipo transação28 Engenharia de Software Magazine - Estimativas de tamanho em projetos de software utilizando pontos de função
  • 28. Gerenciamento d e ProjetosPontos de função não ajustados Aplicando o conhecimento – Fator de ajuste O quarto passo para a contagem é determinar a contagem dos Não será feita análise para esta etapa, uma vez que a mesmapontos de função não ajustados, como pode ser visto na Figura 1. é instituída opcional pelo IFPUG e pode aumentar o erro naNeste ponto entende-se a relação de um arquivo lógico com estimativa.um processo elementar. Para o nosso exemplo, deve-se considerar: Na Figura 10 tem-se um exemplo de uma aplicação AP01 com • Valor de ponto de função não ajustado (VAF) = 1;um ALI e uma série de processos elementares. Ela realiza umaleitura de um arquivo lógico da aplicação AP02. Esse arquivo Realizar o cálculo dos pontos de função ajustadoslógico localiza-se fora da fronteira da aplicação AP01 e deve O sexto e último passo para a contagem é calcular os pontosser classificado como um AIE. 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 Figura 10. Relação arquivo lógico e processo elementar instalação; CFP: Número de pontos de função não ajustados das funções de conversão, ou seja, as funções Agora se deve realizar a contagem dos pontos de função não transitórias que são inutilizadas após a instalação;ajustados. Esta análise é simples. Deve-se apenas somar as VAF: Valor do fator de ajuste.contribuições das funções do tipo dado com as contribuições Tabela 15. Tabela da fórmula dos pontos de função de projeto dedas funções do tipo transação. desenvolvimentoAplicando o conhecimento – Pontos de função não Aplicando o conhecimento – Pontos de função ajustadosajustados Todos os valores estimados até este ponto serão utilizados para Para realizar a determinação dos pontos de função não ajus- determinar os pontos de função ajustados. Para terminar a conta-tados, deve-se somar as contribuições de todas as funções do gem do projeto de desenvolvimento, deve-se substituir os valorestipo dado e do tipo transação (ver Tabela 14). estimados até aqui na fórmula apresentada na Tabela 16. A aplicação contada não possui funções de conversão, por este Descrição Contribuição motivo foi somado zero às funções disponíveis após a instalação.Funções do tipo dado 21 PF Assim, a aplicação contada possui um tamanho funcionalFunções do tipo transação 57 PF estimado em 78 pontos de função.Total de Pontos de Função Não Ajustados = 78 PF DFP = (UFP + CFP) x VAFTabela 14. Pontos de função não ajustados Onde: DFP: Número de pontos de função do projeto de desenvolvimento;Determinar o fator de ajuste UFP: Número de pontos de função não ajustados das funções disponíveis após a instalação; O quinto passo para a contagem é determinar o valor do fator CFP: Número de pontos de função não ajustados das funções de conversão;de ajuste, como pode ser visto na Figura 1. VAF: Valor do fator de ajuste. Para o quinto passo deve-se determinar o fator de ajuste, mas Resultado:essa análise não será feita e será atribuído o valor do fator de DFP = (78 + 0) x 1ajuste como um. A adoção desse valor será melhor compreen- DFP = 78 Pontos de Funçãodida no exemplo apresentado. Tabela 16. Valor total dos Pontos de Função ajustados 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 Derivaçõesvários utilizadores do método de análise de ponto de função Neste ponto já se possui o tamanho funcional da aplicação,ignorassem essa etapa antes mesmo do IFPUG classificá-la agora serão apresentadas as derivações que podem ser reali-como opcional em 2002. zadas com ele. Edição 44 - Engenharia de Software Magazine 29
  • 29. Até aqui se utilizou a APF na perspectiva de produto, agora às expectativas do cliente e nem ter um valor inferior ao ne-pode-se fazer uma análise na perspectiva de processo (esforço, cessário para o funcionamento da empresa.custo e prazo). Independente da derivação, o importante é possuir Como na determinação do esforço, o custo também é estima-um histórico de projeto, só assim será possível estimar esforço, do a partir de dados da empresa, neste caso é necessário ter ocusto e prazo de forma satisfatória. Na primeira vez que aplicar conhecimento do custo da hora da equipe de desenvolvimentoestas estimativas o erro será grande, mas conforme for ampliando ou o valor de um ponto de função para sua empresa.a base de históricos de projetos, o erro tenderá a diminuir. O custo de um Ponto de Função é dado por: • Custo por hora vezes a quantidade de horas necessárias para Esforço produzir um Ponto de Função (C/H x H/PF). Para calcular o esforço é necessário conhecer quantos pontosde função são produzidos em uma hora e saber quantas horas Prazode trabalho são consideradas em um mês na empresa. O prazo é um fator crítico a ser determinado pois, para A estimativa de esforço pode ser: estimativas, pode-se supor que o prazo é uma função linear• Pontos de Função por Homem Mês (PF/HM); com o recurso, o que é uma suposição falha. Por exemplo, se• Pontos de Função por Hora (PF/H). um projeto desenvolvido por dois desenvolvedores gasta um prazo de dois meses, alocar mais dois desenvolvedores para Tem-se por base que a taxa de produtividade é medida em o projeto não necessariamente implica que o mesmo irá durarhora por ponto de função (H/PF). Cada linguagem ou tecno- apenas um mês.logia demandam um esforço diferente, essas características A análise empírica mostra que essa linearidade não existe,não influenciam nos pontos de função, mas sim no esforço uma mulher demora nove meses para gerar um bebê, nove mu-que demanda produzir cada ponto de função. lheres não geram um bebê em um mês (VAZQUEZ, 2009). Existem vários editais para licitação de desenvolvimento de Quanto maior o tamanho funcional de um projeto, maior serásistemas, que incluem tabelas de produtividade mínima no o prazo e maior será o erro. Para projetos pequenos o erro édesenvolvimento de projetos. aceitável, mas novamente volta-se ao ponto de que a melhor A Tabela 17 foi retirada do edital da ACINE (Agência Nacio- maneira de evitar esses erros é possuir uma base histórica dosnal do Cinema), que define a produtividade mínima de PF que projetos desenvolvidos.a empresa deverá produzir por linguagem no tempo definido. O prazo é derivado da seguinte forma:Por exemplo, uma empresa que concorrer a esse edital, deverá • Prazo é a relação de esforço por recurso (Prazo= Esforço/ter competência de produzir no mínimo um PF a cada quinze Recurso).horas na linguagem Java. Aplicando o conhecimento – Derivações Desenvolvimento e manutenção de sistemas Até aqui definiu-se o tamanho funcional do sistema exemplo, Tecnologia Produtividade Mínima 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 daJava 15 h/PF quantidade de pontos de função estimados, serão realizadasASP (Vbscript e Javascript) 10 h/PF derivações quanto ao esforço, custo e prazo necessários paraPHP 11 h/PF o desenvolvimento do software.JSP 13 h/PFHTML 7 h/PF EsforçoCold Fusion 11 h/PF A aplicação de exemplo foi estimada em 78 pontos de fun- ção. Será considerada uma empresa que possui uma taxa deDelphi 9 h/PF produtividade mínima em Java de 5 H/PF e com uma carga deCrystal reports 9 h/PF trabalho de 130 horas por homem-mês. Essa empresa gastariaPL/SQL 9 h/PF 390 horas para produzir o sistema, ou três meses, conformeVisual Basic 9 h/PF a Tabela 18.Tabela 17. Tabela de produtividade mínima ACINE Custo Utilizar bases de editais (sem o conhecimento sobre o pro- Suponha que a hora de trabalho custe R$ 20,00 e, como éjeto) ou de outras empresas, constitui um risco muito grande, produzido um ponto de função a cada cinco horas, o valor dopois a produtividade é intrínseca de cada empresa, pois essas ponto de função é de R$ 100,00.possuem funcionários e processos diferenciados. 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 Custo função. A estimativa do custo de um projeto é a informação primor- Pode-se assim inferir que a aplicação tem um custo de apro-dial na hora de elaborar uma proposta, este não pode exceder ximadamente R$ 7.800,00, conforme a Tabela 19.30 Engenharia de Software Magazine - Estimativas de tamanho em projetos de software utilizando pontos de função
  • 30. Gerenciamento d e ProjetosEsforço = H/PF x Tamanho do projeto em PF fase de construção é de 65% e você possui o esforço e custo paraOnde: o desenvolvimento desta fase, pode-se extrapolar um de cadaH: Hora; vez para todas as fases, depois são feitos ajustes necessáriosPF: Pontos de função. de acordo com cada empresa.Resultado: Utilizando dos valores obtidos neste artigo, segue o exem-Esforço = 5 x 78 plo para extrapolar o esforço para a construção do sistema,Esforço = 390 horas no esforço para a realização da fase de concepção do projeto,Tabela 18. Valor total em horas do esforço para desenvolver o projeto conforme a Tabela 22. Extrapolando Esforço Construção em Esforço Iniciação Custo = Tamanho do projeto em PF x Custo do Ponto de Função 65% - 390 (horas)Resultado: 05% - X (horas)Custo = 78 x R$ 100,00 X = 30 horasCusto = R$ 7.800,00 Tabela 22. Esforço total extrapolado para realização da fase de concepçãoTabela 19. Custo total para elaboração do projeto O prazo pode ser obtido a partir do esforço necessário para Prazo produzir e dos recursos disponíveis. Foi definido que o esforço necessário para produzir a aplica- Assim, deve-se realizar análise histórica dos projetos e cons-ção é de 390 horas ou três meses. Suponha que esta empresa truir uma tabela específica para cada organização, mas obser-possua dois funcionários habilitados a desenvolver o projeto vando cada projeto, pois ajustes serão sempre necessários.na tecnologia estabelecida. Utilizando dessas informações conclui-se que o prazopara a entrega do sistema será de um mês e meio, conformea Tabela 20. Referências 1. VAZQUEZ,C.E. , SIMÕES,G.S. , ALBERT,R.M. Análise de ponto de função medição, estimativa e Prazo = Esforço / Recurso gerenciamento de projetos de software. São Paulo, Editora Érica, 2009Prazo = 3 / 2Prazo = 1 mês e 15 dias 2. Softex. MPS.BR - Melhoria de processo do software brasileiro - Guia geral, 2009Tabela 20. Prazo total para elaboração do projeto 3. IFPUG(International Function Point Users Group). Disponível em: <http://www.ifpug.org>.Considerações finais 4. BFPUG(Brazilian Function Point Users Group). Disponível em: <http://www.bfpug.com.br>. A APF pode ser usada para estimar desenvolvimento, melho- 5. PMI (Project Management Institute). Um Guia do Conjunto de Conhecimentos emria e aplicação. Todas as formas de estimativa e derivações são Gerenciamentos de Projetos (PMBOK). Estados Unidos: PMI Publications, 2004referentes à fase de construção, mas é de conhecimento que naprodução de um sistema, têm-se ainda as fases de concepção, 6. DEKKERS, C. Pontos de Função e Medidas - O Que é um Ponto de Função?. QAI Journal, dez. 1998elaboração e transição. É importante dizer que as dicas que 7. DEKKERS, C. Desmistificando Pontos de Função: Entendendo a Terminologia. IT Metricsserão passadas não possuem nenhuma ligação com o método Strategies, out. 1998de APF, mas sim uma observação de como extrapolar os va-lores derivados de esforço, prazo e custo em todo o processo 8. HAZAN, Cláudia – Análise de Pontos por Função – agosto , 2001 . disponível em http://www.de produção do sistema. inf.ufes.br/~falbo/download/aulas/es-g/2005-1/APF.pdf. Embora o ciclo de vida varie muito por empresas e projetos 9. ACINE. Anexo XVIII – Tabelas de produtividade mínima, 2008. Disponível em: <http://www.diferentes, um projeto médio, possui a distribuição de esforço ancine.gov.br/media/concorrencia0012008/AnexoXVIII.pdf>.e programação como apresentado na Tabela 21. 10. Philippe Kruchten. The Rational Unified Process: An Introduction. Boston, Editora Pearson Concepção Elaboração Construção Transição Education, 2003Esforço 5% 20% 65% 10%Programação 10% 30% 50% 10% Dê seu feedback sobre esta edição! Feedback eu s DêTabela 21. Distribuição de esforço e programação em projetos de médio A Engenharia de Software Magazine tem que ser feita ao seu gosto. sobre eporte (Philippe Kruchten, 2003) Para isso, precisamos saber o que você, leitor, acha da revista! s ta edição Dê seu voto sobre este artigo, através do link: Para extrapolar os resultados obtidos nas derivações da APF,basta fazer uma regra de três simples. Se o esforço destinado à www.devmedia.com.br/esmag/feedback Edição 44 - Engenharia de Software Magazine 31
  • 31. Engenharia Nesta seção você encontra artigos voltados para testes, processo, modelos, documentação, entre outros CMMI – Uma visão Geral Um modelo de maturidade para o processo de construção 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? A o longo dos últimos anos, tanto Nos projetos de desenvolvimento de software, as empresas de desenvolvi- que adotam políticas de qualidade, sobretudo mento de soft ware quanto quando se deseja buscar mercados externos ou seus clientes têm se preocupado com expandir seus clientes internos aumentando a problemas que são comumente identifi- satisfação dos mesmos. cados durante a execução dos projetos, tais como: prazos e orçamentos não Resumo cumpridos, insatisfação de ambos os Este artigo tem como propósito apresentar lados, produtos com erros, entre outros. uma visão geral sobre maturidade dos proces- No entanto, há algum tempo, existe um sos de desenvolvimento de software, visando a consenso na Engenharia de Software de qualidade do produto gerado e a consequente que estes problemas estão, em grande satisfação dos seus clientes, através do mode- parte, relacionados ao fato de que o lo de referência CMMI. Trata-se de um modelo desenvolvimento de sistemas é muitas internacional, desenvolvido pelo Software En- Lenildo Morais vezes realizado de forma “artesanal”, gineering Institute – SEI, que pode dar suporte lenildojmorais@gmail.com É analista de sistemas e analista de testes. ou através de métodos improvisados às organizações que procuram aprimorar seus Atualmente está cursando mestrado no pelos desenvolvedores. Tais métodos processos de desenvolvimento de software, centro de informática da UFPE em enge- dependem mais do talento individual tornando-se assim mais competitivas. nharia de software com ênfase em testes do desenvolvedor que de uma sólida e qualidade de software. formação que oriente suas atividades.32 Engenharia de Software Magazine - CMMI – Uma visão Geral
  • 32. processo Um processo definido e controlado pode garantir um produto relacionados principalmente à qualidade, custos e prazos. Comde qualidade, sobretudo do ponto de vista do desenvolvi- isso, o CMMI pode ser aplicado em uma organização em etapasmento de software. O Capability Maturity Model Integration, consecutivas, representando a ideia de maturidade (avaliadaou CMMI, como é chamado, é um modelo de referência que por estágios) da organização, ou de maneira contínua, ondeprovê uma orientação para o desenvolvimento de processos é medida a capacidade em processos individuais, conformede software, procurando nortear a organização no sentido de ilustrado na Figura 1.implementar a melhoria contínua do processo de software (lerNota do DevMan 1). Nota do DevMan 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 Figura 1. Capacidade e Maturidade Organizacional 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 CMMI possui cinco níveis de maturidade, onde no primeiro a empresa desenvolve sistemas baseando-se apenas na expe- O MPS.BR define um modelo de melhoria e avaliação de processos de software riência dos recursos humanos da organização; e no último, há com o foco nas pequenas e médias empresas brasileiras, de modo a atender as suas um processo organizado e flexível, com um planejamento efi- necessidades de negócio e ser reconhecido nacional e internacionalmente como um ciente e continuamente aprimorado. Este modelo define áreas modelo aplicável à indústria de software. Ele estabelece um modelo de processos de de processo, sendo cada uma com suas metas e práticas, e para software e um método de avaliação de processos de modo a garantir que o MPS.BR que uma empresa alcance níveis de maturidade superiores, está sendo empregado de forma coerente com as suas definições. 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. Para isso, o modelo contempla duas representações quepermitem à empresa desenvolvedora do software utilizar o Representações do CMMIcaminho de melhoria mais adequado. Estas representações O CMMI possui duas representações: a estagiada e a contí-estão divididas em níveis de maturidade, priorizando de forma nua. A representação estagiada permite que as organizaçõeslógica as ações a serem realizadas. Assim, quanto maior o nível, melhorem um conjunto de processos inter-relacionados e, demaior a maturidade da organização, o que pode se traduzir em forma incremental, tratem sucessivos conjuntos de PAs. A re-maior qualidade do produto final, com maior previsibilidade presentação contínua, por sua vez, permite que as organizaçõesem cronogramas e orçamentos. melhorem de forma incremental os processos correspondentes O objetivo do CMMI é servir de guia para a melhoria de pro- a uma ou mais PAs, sendo a empresa responsável por selecio-cessos na organização, assim como auxiliar a habilidade dos nar em que áreas de processo ela será avaliada.profissionais em gerenciar o desenvolvimento e manutenção A seg ui r apresenta mos u ma descr ição para estasde produtos ou serviços de software, além de proporcionar a representações:visibilidade apropriada do processo de desenvolvimento para • Representação por Estágios: Esta representação preocupa-setodos os envolvidos no projeto. Isto é particularmente impor- com os processos da organização como um todo, oferecendotante em grandes projetos que possuem equipes envolvendo uma abordagem estruturada e sistemática para a melhoriadezenas de pessoas, pois, sem o apoio desses modelos de de um estágio por vez. Atingir um estágio significa que umamaturidade de processos de software como o CMMI, torna-se estrutura de processo adequada foi estabelecida como baseainda mais difícil manter o controle do projeto. para o próximo estágio. Com a utilização de níveis, o CMMI descreve um caminho As áreas de processo (PAs) são organizadas por níveis deevolutivo recomendado para uma organização que deseja maturidade. Elas vão do nível “inicial” (nível 1) ao nível “emmelhorar os processos utilizados para a construção de seus otimização” (nível 5), e sugerem uma ordem para a implemen-produtos e serviços. Quando uma organização atinge um nível tação das áreas de processo. Cada nível possui várias PAs,de maturidade, considera-se que seus processos alcançaram e cada PA possui objetivos, práticas genéricas e específicas,uma determinada capacidade, ou seja, tem mecanismos que assegurando assim uma base de melhoria adequada para ogarantem a repetição sucessiva de bons resultados futuros próximo nível de maturidade. Edição 44 - Engenharia de Software Magazine 33
  • 33. Na representação por estágios, quando uma organização atin- a) Nível 0 – Incompleto. Um processo é parcialmente realizadoge as práticas necessárias para estar em um nível, subentende- ou não, onde um ou mais objetivos específicos do processose que ela atingiu todos os requisitos necessários dos níveis não são satisfeitos [3];imediatamente anteriores. b) Nível 1 – Realizado. Um processo realizado satisfaz todos Os níveis estão descritos da seguinte forma: os objetivos específicos da área de processo e produz algum a) Nível 1 – Inicial. É o nível de maturidade CMMI mais baixo. trabalho [3];Em geral, as organizações desse nível têm processos imprevi- c) Nível 2 – Gerenciado. Um processo de capacidade nível 2síveis que são pobremente controlados e reativos. Neste nível é um processo realizado (nível 1) que também é planejado ede maturidade não há PAs, os processos são normalmente im- executado de acordo com políticas pré-definidas. Emprega pes-previsíveis e caóticos, e a organização geralmente não fornece soas hábeis com os recursos adequados para produzir saídasum ambiente estável; adequadas, envolve os stakeholders principais e é monitorado, b) Nível 2 – Gerenciado. Neste nível, os projetos da organi- controlado, revisto e avaliado quanto à aderência à sua des-zação têm a garantia de que os requisitos são gerenciados, crição. A gerência do processo é relacionada com a realizaçãoplanejados, executados, medidos e controlados. Quando essas de objetivos específicos estabelecidos para o processo, comopráticas são adequadas, os projetos são executados e controla- custo, cronograma e qualidade [3];dos de acordo com o planejado. O gerenciamento de projetos d) Nível 3 – Definido: Um processo definido é um processoé o foco principal deste nível; gerenciado e ajustado para o conjunto padrão de processos da c) Nível 3 – Definido. Nível em que todos os objetivos especí- organização de acordo com as suas políticas de conduta. Esseficos e genéricos atribuídos para os níveis de maturidade 2 e 3 conjunto é estabelecido e melhorado com o tempo e descreveforam alcançados, e os processos são mais bem caracterizados, os elementos fundamentais de processos que são esperadosalcançando melhor entendimento, sendo descritos em padrões, nos processos definidos [3];procedimentos, ferramentas e métodos. O foco neste nível é a e) Nível 4 - Gerenciado quantitativamente: Um processopadronização do processo; neste nível é definido e controlado com a ajuda de técnicas d) Nível 4 - Quantitativamente Gerenciado. Neste nível, os quantitativas e estatísticas. A qualidade e o desempenho doobjetivos específicos e genéricos atribuídos para os níveis processo são compreendidos em termos estatísticos e são geri-de maturidade 2, 3 e 4 foram alcançados e os processos são dos durante sua vida. Objetivos quantitativos para qualidademedidos e controlados. O foco neste nível é o gerenciamento e desempenho de processos são estabelecidos e usados comoquantitativo; critério na gerência do processo [3]; e) Nível 5 – Em Otimização. É o nível mais alto de maturidade f) Nível 5 – Em otimização: Um processo em otimização éCMMI, onde uma organização atinge todos os objetivos específi- gerenciado quantitativamente, alterado e adaptado para aten-cos atribuídos para os níveis de maturidade 2, 3, 4 e 5. Neste nível der aos objetivos de negócio atuais e projetados. Tal processoos processos têm como foco principal a melhoria contínua. enfatiza a melhoria contínua através de aprimoramentos tecno- lógicos inovadores e incrementais, selecionados com base em • Representação Contínua: Na representação contínua, o foco uma compreensão quantitativa de sua contribuição esperadaou componentes principais são as áreas de processo. Existem à obtenção da melhoria de processos [3].metas e práticas de dois tipos: específicas a uma determinadaárea de processo, e genéricas, aplicáveis indistintamente a Representação por Estágios X Contínuatodas as áreas de processo. A representação contínua usa níveis de capacidade para Nesta representação, as áreas de processo são agrupadas por medir a melhoria de processos, enquanto a representação porcategorias afins que reúnem caminhos de melhoria indicando estágios utiliza níveis de maturidade para medir a melhoriaa evolução para cada uma destas áreas. de capacidade da organização. A principal diferença é a forma A representação contínua contempla quatro disciplinas: Ge- como cada representação é aplicada. Os níveis de capacidaderência de Processos, Gerência de Projeto, Engenharia e Suporte. são aplicados na melhoria de processos de cada área de umaAs áreas de processo relativas à disciplina de Gerência de Pro- organização. Eles estão dispostos em seis níveis de capacidade,cessos contêm atividades relacionadas para definir, planejar, numerados de 0 a 5, onde cada nível possui um conjunto deimplantar, monitorar, controlar, medir e melhorar processos. práticas gerais e específicas.As áreas de processo relativas à categoria de Gerência de Pro- Na representação por estágios, os níveis de maturidade nãojeto contêm as atividades de planejar, monitorar e controlar o servem para analisar áreas do processo, mas sim para indicarprojeto. A categoria de Engenharia refere-se às atividades de melhorias na organização como um todo. Ao fazer a avaliaçãodesenvolvimento de sistemas de software. Por fim, as atribui- de uma organização, é possível mapear os valores de capaci-ções de fornecer suporte ao desenvolvimento e à manutenção dade do processo para a maturidade organizacional. Se não háde produtos são relativas à categoria de Suporte. certeza sobre quais processos escolher para serem melhorados, A partir da avaliação e do atendimento dessas práticas e me- a representação por estágios é uma boa opção. Ela fornecetas, é possível classificar o nível de capacidade de cada área de um conjunto específico de processos para melhorar em cadaprocesso em uma escala de 0 a 5 do seguinte modo [3]: estágio, determinado por mais de uma década de experiência34 Engenharia de Software Magazine - CMMI – Uma visão Geral
  • 34. processo Representação Contínua Representação por EstágiosPermite livre escolha da sequência de melhorias, de forma a melhor satisfazer aos Permite que as organizações tenham um caminho de melhoria pré-definido e testado.objetivos estratégicos e mitigar as áreas de risco da organização.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 Baseia-se em uma história relativamente longa de utilização, com estudos de casos e dados que demonstram oseu retorno do investimento. retorno do investimento.Tabela 1. Comparação entre as representações contínua e por estágiose pesquisas em melhoria de processo. Todavia, existem três e o cumprimento dos prazos, tão importantes nos ambientescategorias de fatores que podem influenciar na decisão de qual competitivos do presente momento.representação será a mais adequada: Dessa forma, o objetivo de muitas empresas tem sido obtera) Estratégico: Se uma organização com foco em linha de pro- qualificações CMMI para atender as exigências explícitas doduto decidir melhorar seus processos na organização como mercado. O CMMI (Capability Maturity Model Integration)um todo, pode ser mais bem atendida pela representação por descreve princípios e práticas relacionadas ao processo de de-estágios, uma vez que a representação por estágios auxilia na senvolvimento de produtos e serviços tecnológicos. O modeloescolha dos conjuntos de processos onde focar a melhoria. A visa ajudar organizações envolvidas com o desenvolvimentoconsideração mais importante a ser feita é a identificação dos de software a melhorar a capacidade de seus processos, porobjetivos estratégicos a serem apoiados pelo programa de me- meio de um caminho evolucionário que considera desde pro-lhoria de processo e a forma como esses objetivos estratégicos cessos com resultados imprevisíveis, e até mesmo caóticos, ase alinham às duas representações; processos disciplinados e definidos, com resultados previsíveisb) Culturais: Estão relacionados com a capacidade da organi- e com possibilidade de melhoria contínua.zação em implantar um programa de melhoria de processo.Por exemplo, uma organização pode escolher a representaçãocontínua se sua cultura corporativa basear-se em processos efor experiente em melhoria de processo. Já uma organização Linkspouco experiente em melhoria de processo pode escolher a [1] Uma visão geral do CMMIrepresentação por estágios, uma vez que essa representação http://www.dromostg.com.br/CMMI.PDFfornece orientações adicionais sobre a sequência em que asmudanças devem ocorrer; [2] Análise de uma Organização de Software utilizando o Modelo CMMI/SEIc) Legado: Caso uma organização tenha experiência com outro http://www2.dem.inpe.br/ijar/Qualidade%20de%20Software/PDFs/CMMI-Artigo.pdfmodelo que utiliza uma representação por estágios, pode ser [3] Modelo de Qualidade – CMMImais prudente continuar utilizando essa representação no Rosângela PenteadoCMMI, principalmente se já investiu e implantou processosassociados à representação por estágios. O mesmo raciocínio [4] CMMI - Uma Visão Geralpode ser aplicado para a representação contínua. Carlos José Locoselli e João Carlos Neto A Tabela 1 compara cada representação e pode auxiliarna determinação da representação mais adequada para a Dê seu feedback sobre esta edição! eu Feedbackorganização. s Dê A Engenharia de Software Magazine tem que ser feita ao seu gosto. sobre eConclusões Para isso, precisamos saber o que você, leitor, acha da revista! s ta edição A utilização de metodologias em desenvolvimento de sof- Dê seu voto sobre este artigo, através do link:tware, mais do que uma ferramenta, é condição obrigatória www.devmedia.com.br/esmag/feedbackpara se obter a melhoria nos processos, a qualidade necessária Edição 44 - Engenharia de Software Magazine 35
  • 35. Engenharia Nesta seção você encontra artigos voltados para testes, processo, modelos, documentação, entre outros Gerenciando mudanças a partir de requisitos Uma das aplicações da matriz de rastreabilidade 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? José Alberto Zimermann Rodrigo Oliveira Spínola jazimermann@gmail.com Rodrigo.devmedia@gmail.com Gerir mudanças é uma atividade fundamental Bacharel em Ciência da Computação pela Editor Chefe – SQL Magazine | WebMobile | em projetos de desenvolvimento de software. Universidade Regional de Blumenau Engenharia de Software Magazine É natural que os requisitos mudem e evoluam (FURB). Atua como Analista de Sistemas ao longo do tempo. Cabe à equipe de desenvol- na empresa Dynamix Software, situada vimento gerenciar isto da melhor forma com em Blumenau, SC e também como desen- volvedor Java para o ambiente Web. Pos- intuito de minimizar impactos negativos no sui conhecimento nos frameworks  JBoss andamento do projeto. A Seam, Struts, Hibernate, entre outros. crescente busca pela qualidade de um produto exige cada vez Resumo Thiago Carvalho de Sousa mais que as empresas fabrican- Este artigo trata do assunto gestão de mudanças. thiagocsousa@gmail.com tes de software busquem um processo Este assunto será analisado sob a perspectiva da Doutorando em Engenharia de Computa- ou um modelo no qual se siga uma me- engenharia de requisitos. Assim, inicialmente ção e Sistemas Digitais (EP-USP). Mestre e todologia de trabalho de conhecimento são apresentados conceitos importantes para Bacharel em Ciência da Computação (IME- de todos os envolvidos. Neste contexto, o entendimento do assunto como: engenharia USP). Trabalha há mais de 10 anos com de- senvolvimento de software, atuando como diversas empresas optam por processos de requisitos, gerência de requisitos, matriz de gerente de projetos, analista de negócios que contribuam no gerenciamento de rastreabilidade e gestão de mudanças. Ao final, e requisitos em grandes multinacionais, mudanças. O objetivo do controle de é apresentada uma abordagem que pode ser incluindo a Oracle, Johnson & Johnson mudanças é assegurar que as alterações utilizada nas atividades de gestão de mudanças e Goodyear, bem como ministrando a feitas em um projeto sejam consistentes com o objetivo de priorizar e avaliar as mudan- disciplina de engenharia de software em diversas faculdades, tais como a Unifieo, e passíveis de mensurar o impacto que ças solicitadas por clientes nos requisitos. CEUT e Faete. irão gerar.36 Engenharia de Software Magazine - Gerenciando mudanças a partir de requisitos
  • 36. requisitos No mercado, existem diversas ferramentas que contemplam • especificação: é onde ocorre a definição das funcionalidadesas fases de elaboração e desenvolvimento de um sistema, auxi- do software, indicando inclusive, as suas restrições;liando inclusive a implantação e uso de processos de software • projeto e implementação de software: nesta etapa é ondebem definidos. ocorre o desenvolvimento do software, atendendo a especifi- Comumente percebe-se que dentro da área de informática cação anteriormente descrita;as empresas encontram dificuldades em gerir o processo de • validação do software: o software necessita ser validado,mudança em virtude de fatores como a velocidade e dinâmica garantindo que ele atenda as necessidades do cliente;com que elas ocorrem. As mudanças no software são feitas • evolução do software: o software pode evoluir para atenderem resposta a solicitações de modificação de requisitos de as necessidades mutáveis do cliente.um projeto e isso deve ser feito de maneira que a estruturafundamental já existente permaneça estável. Engenharia de requisitos Sommerville afirma que 65% da manutenção de um sistema Existem diferentes definições encontradas na literatura téc-está relacionada à implementação de novos requisitos, 18% na nica para engenharia de requisitos:modificação de requisitos já existentes e 17% na correção de • Termo usado para descrever as atividades relacionadas à in-defeitos de um sistema. Desta maneira, a manutenção pode vestigação e definição de escopo de um sistema de software;ser considerada como uma extensão do processo de desen- • Processo sistemático de desenvolvimento de requisitos atravésvolvimento de software, com atividades associadas às de de um processo cooperativo de análise onde os resultados dasespecificação, projeto, implementação e testes. observações são codificados em uma variedade de formatos e a Neste sentido, dentro do processo de manutenção, Press- acurácia das observações é constantemente verificada;man afirma que um dos problemas clássicos associados à • Processo de descobrir, analisar, documentar e verificar asmanutenção é a dificuldade em se rastrear a evolução do funções e restrições do sistema.software, uma vez que as mudanças não estão devidamentedocumentadas. Já Borges defende que para se obter o controle Embora coerentes, estas definições podem ser melhoradas.e estabilidade de requisitos, durante o projeto de desenvol- Perceba que elas referem-se apenas às atividades relacionadasvimento, é necessário acompanhar quantitativamente as à produção de requisitos. Entretanto, nada é dito a respeito daalterações em requisitos. Isto permite mensurar o tamanho gerência destas atividades, também conhecida como gerênciadas alterações, em termos de esforço empregado na manu- de requisitos. Com isto em mente, podemos evoluir a definiçãotenção dos artefatos. de engenharia de requisitos para: termo usado para descrever Considerando este contexto, este artigo apresenta alguns as atividades relacionadas à produção (levantamento, registro,aspectos teóricos associados à engenharia de requisitos, e em validação e verificação) e gerência (controle de mudanças, ge-particular, à manipulação da matriz de rastreabilidade. Além rência de configuração, rastreabilidade, gerência de qualidadedisso, também serão discutidos alguns aspectos associados à dos requisitos) de requisitos.gestão de mudanças. Neste ponto podemos citar alguns dos principais objetivos da engenharia de requisitos:Alguns fundamentos • estabelecer uma visão comum entre o cliente e a equipe de Nesta seção discutiremos alguns fundamentos teóricos im- projeto em relação aos requisitos que serão atendidos peloportantes ao estudarmos o assunto gestão de mudanças no projeto de software;contexto da engenharia de requisitos. Para isso, descreveremos • registrar e acompanhar requisitos ao longo de todo o processoinicialmente as fases de um processo de desenvolvimento de de desenvolvimento;software e a gerência de requisitos. Em seguida, são expli- • documentar e controlar os requisitos alocados para esta-cados os benefícios da gestão de mudanças em um projeto, belecer uma baseline para uso gerencial e da engenharia demostrando os estágios em que ela deve ser executada. Feito software;isto, apresentaremos o conceito e as funcionalidades da ras- • manter planos, artefatos e atividades de software consistentestreabilidade de requisitos e artefatos. Por fim, apresentamos com os requisitos alocados.a metodologia AHP, enfatizando o seu funcionamento e comopode ser aplicada. Gerência de requisitos Requisitos são por natureza voláteis. Diversos fatores con- Processos de desenvolvimento de software tribuem para sua instabilidade ao longo do tempo. Mudanças Um processo de software pode ser definido como sendo uma externas no ambiente (mudanças de legislação, mudanças nosérie de atividades e resultados que possui como finalidade mercado, mudança no posicionamento estratégico da empre-gerar um produto de software. Os processos de softwares são sa), erros incorridos no processo de requisitos, entre outros.complexos e devem seguir uma série de procedimentos a fim Todos esses fatores fazem com que seja necessário alterar osde garantir um produto que atenda as diversas necessidades requisitos. Tais alterações precisam ser conduzidas de formado cliente. Neste sentido, existem diversos processos que têm ordenada para que não se perca controle sobre o prazo e ocomo características comuns as seguintes fases: custo do desenvolvimento. Edição 44 - Engenharia de Software Magazine 37
  • 37. Denominamos a atividade de administrar os requisitos ao mudança é estimado em termos das modificações no docu-longo do tempo de gerenciamento de requisitos. mento de requisitos e, se apropriado, no projeto de sistemas Ao se colocar um software em uso, novos requisitos são e na implementação. Desta maneira, entende-se que é muitodetectados como necessários e os já existentes são alterados à importante possuir o documento de requisitos e o projeto demedida que o sistema é utilizado. Partes dos requisitos podem software constantemente atualizados.ser modificadas para corrigir erros encontrados na operação ouaté mesmo para melhorar o desempenho da aplicação. Rastreabilidade de requisitos É importante que o projeto de software seja atualizado com a A rastreabilidade é uma técnica que provê o relacionamentoevolução do sistema a partir da inclusão, alteração ou exclusão entre diversos requisitos, projeto e a sua implementação. É elade requisitos, a fim de se identificar de maneira clara quais quem auxilia no entendimento dos relacionamentos que exis-são os componentes envolvidos nas alterações de um sistema. tem entre os requisitos e o projeto de software desenvolvido.É justamente neste contexto que se destaca a área de gerência Em resumo, podemos dizer que a rastreabilidade é a habilidadede requisitos. de descobrir o histórico de cada funcionalidade do sistema. Sommerville afirma que os requisitos nos grandes sistemas Neste sentido, a rastreabilidade permite garantir como eestão em constante modificação. porque os artefatos atendem os requisitos dos clientes, sendo A gerência de requisitos está associada ao processo de con- uma forma fundamental para entender os relacionamentostrole do processo de desenvolvimento tendo como referência a existentes entre requisitos e outros artefatos que fazem partebase de requisitos. Segundo Tocchetto, o principal objetivo do do processo de software. Desta maneira, a elaboração degerenciamento de requisitos é “descobrir, organizar, comunicar um projeto de software deve produzir requisitos que sejame administrar o impacto das mudanças de requisitos de um rastreáveis, ou seja, que sejam capazes de serem rastreados asoftware”. Desta maneira, tem-se que os principais benefícios partir da sua origem.do gerenciamento de requisitos são: Por outro lado, temos também que um dos maiores desafios• maior controle em projetos de grande porte; da engenharia de requisitos é criar um mecanismo que possi-• aumento da qualidade de software e maior satisfação do bilite a criação de links entre os requisitos e os códigos fontes.cliente; Desta maneira, um dos benefícios que a rastreabilidade oferece• diminuição dos custos de projeto e atrasos. é a possibilidade de se cruzar as informações especificadas na fase de projeto (requisitos) e os itens desenvolvidos na fase de Gestão de mudanças implementação, que são os códigos fontes. O processo de manutenção é explicado por Sommerville ao se A rastreabilidade permite que as estimativas de custos dasiniciar um conjunto de pedidos de mudança por parte dos usuá- alterações em requisitos de um projeto possam ser mais pre-rios, gerentes ou clientes. Custo e impacto devem ser analisados cisas. Também permite que as mudanças possam ocorrer sempara se verificar quanto do sistema será afetado pela alteração e a dependência do engenheiro ou programador de conheceremquanto poderá custar para desenvolver esta mudança. as áreas afetadas por tais mudanças. Assim sendo, em uma situação ideal, o estágio de desenvol- É possível afirmar que a manutenção da rastreabilidadevimento de alterações deverá modificar especificação, projeto pode ser um trabalho penoso, extenso e até mesmo inviável,e implementação do sistema, com o objetivo de refletir no quando não auxiliado por uma ferramenta especializada. Issosoftware. Desta maneira, os novos requisitos que refletem as é explicado por Richardson e Green que afirmam que progra-mudanças no sistema são propostos, analisados e validados, madores são relutantes em manter os documentos do projetopara que a mudança seja consistente e não impacte de maneira atualizados, quebrando assim, o mecanismo que possibilitanegativa no restante do sistema. ocorrer a rastreabilidade. Neste contexto, a gerência de mudança tem o objetivo de garantirque as mudanças sejam realizadas com sucesso, sem que haja Classificação da rastreabilidadeperda da qualidade do software. Para que isso ocorra, é necessário Segundo Genvigir, existem duas maneiras de se efetuar aque esta fase da manutenção do software controle as solicitações rastreabilidade:de manutenção, aprove as solicitações e a partir daí, estabeleça • forward: rastreabilidade efetuada em um requisito até seuscomo a modificação será implementada e quais restrições que refinamentos;deverão ser respeitadas, definindo de maneira clara qual o escopo • backward: rastreabilidade efetuada de um refinamento atéda alteração. Ainda segundo Sommerville, existem três estágios sua origem.em um processo de gerenciamento de mudanças:• análise do problema e especificação da mudança; Ainda de acordo com Genvigir, um processo de rastreabi-• análise e custo da mudança; lidade é falho caso não seja possível realizar um destes dois• implementação de mudanças. tipos de rastreabilidade. Isto está ligado ao fato de que estas capacidades são propriedades básicas para a realização da Nestes estágios são utilizadas informações de rastreabilidade atividade de rastreabilidade. É possível classificar ainda apara se estimar o tamanho e o custo da mudança. O custo da rastreabilidade quanto aos seus tipos:38 Engenharia de Software Magazine - Gerenciando mudanças a partir de requisitos
  • 38. requisitos• horizontal: rastreabilidade efetuada entre versões ou varia- sendo possível assim mapear os valores das fases do projeto,ções de uma base de artefatos. Ocorre em uma determinada tendo-se desta forma o real custo de cada um deles a partir dafase do ciclo de vida do projeto; aplicação de uma métrica.• vertical: rastreabilidade que ocorre entre requisitos e artefatos Este método baseia-se no método newtoniano e cartesianoproduzidos pelo processo de desenvolvimento do projeto. de pensar, que busca tratar a complexidade com a decompo- sição e divisão do problema em fatores, que podem ainda ser Uma visão sobre os tipos de rastreabilidade é apresentada na decompostos em novos fatores até o nível mais baixo, claros eFigura 1. Perceba que ao trabalharmos com a rastreabilidade dimensionáveis e estabelecendo relações para sintetizar.vertical estamos lidando com artefatos presentes em diferentesatividades do desenvolvimento. Por outro lado, ao trabalhar- Etapas para a construção de um pensamento analíticomos com a rastreabilidade horizontal, estamos mapeando Segundo Costa, é possível definir duas etapas de pensamentoconceitos dentro de uma mesma atividade ou artefato base. 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árioFigura 1. Rastreabilidade horizontal e vertical que o julgamento ocorra entre um par de elementos, aplicando a escala definida na Tabela 1. Esta comparação se dá através da Agora que conhecemos alguns dos fundamentos da engenha- montagem de uma matriz entre os elementos, onde i representaria de requisitos relacionados à gestão de mudanças, vamos o elemento de uma linha e j um elemento da coluna.apresentar uma abordagem que pode ser utilizada na tarefa Segundo Marins, Souza e Barros, a quantidade de julgamen-de definição de prioridades a partir das informações contidas tos para a construção de uma matriz de julgamentos genéricana matriz de rastreabilidade. 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 Conhecendo a metodologia AHP apresentadas na Figura 3. A metodologia AHP foi criada por Saaty com o objetivo deponderar as características qualitativas, permitindo assim, aponderação e priorização de cada um dos requisitos de umprojeto que estão inseridos no projeto. O funcionamento desteprocesso se dá pela atribuição de pesos a fatores individuais,do menos influente ao mais influente. AHP utiliza-se de umamatriz quadrada que permite avaliar a importância de umacaracterística sobre a outra. A partir disso, o processo permite Figura 3. Condições para a definição de uma matriz de julgamentoobter o valor percentual de cada um dos requisitos e assim,mapear o valor das fases do projeto. O processo de aplicação da metodologia AHP Segundo Tocchetto, o processo AHP permite obter o valor Para se entender o funcionamento do processo de cálculoem percentual de cada requisito que faz parte do projeto, do AHP, pode-se considerar o exemplo descrito a seguir. Edição 44 - Engenharia de Software Magazine 39
  • 39. Escala Definição Descrição1 Menos importante Duas atividades contribuem igualmente para o objetivo3 Importância pequena A experiência e o julgamento favorecem levemente uma atividade em relação à outra5 Importância grande ou essencial A experiência e o julgamento favorecem fortemente uma atividade em relação à outra7 Importância muito grande Uma atividade é fortemente favorecida. Sua dominação de importância é demonstrada na prática9 Importância absoluta A evidência favorece uma atividade em relação à outra com o mais alto grau de certeza2, 4, 6, 8 Valores intermediários. Se na atividade “j” (coluna) recebe um dos Quando se deseja maior compromisso. É uma designação razoável valores acima, quando comparada com a atividade “j” (coluna), então “j” (coluna) tem o mesmo valor recíproco de “i” (linha)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 AHPPara tal, será considerado um projeto que contém três requi- no processo. O cálculo do auto-vetor se dá através da expressãositos, os quais são: definida na Figura 4.• requisito 1;• requisito 2;• requisito 3. O relacionamento realizado entre os requisitos do projeto éapresentado através da Tabela 2. Figura 4. Expressão para a obtenção do auto-vetor Requisito Requisito 1 Requisito 2 Requisito 3 Já a normalização do auto-vetor se dá com base na expressãoRequisito 1 apresentada na Figura 5. 1 a12 a13Requisito 2 a21 = 1/a12 1 a23 = 1/a32Requisito 3 a31 = 1/a13 a32 1Tabela 2. Matriz de importância entre os requisitos Figura 5. Expressão para a normalização do auto-vetor Conforme observado por Tocchetto, as premissas que devemser seguidas para a inserção de valores são: A partir da definição e conhecimento das fórmulas apresen-• Se aij = α, então aji = 1/ α, α é diferente de 0; tadas nas Figuras 4 e 5, pode-se exemplificá-las, aplicando as• Se o requisito i é julgado com igual importância ao requisito fórmulas para o Requisito 1, que é:j, então aij = 1, aji = 1 e aii = 1. • somatório da coluna do Requisito 1: T = 1 + 3 + 0,5 = 4,5; • primeira linha da primeira coluna normalizada: (1 * 100) / A partir da definição desta matriz, deve-se incluir os valores 4,5 = 22,22 / 100 = 0,22;para cada par de requisitos, de acordo com a escala proposta • segunda linha da primeira coluna normalizada: (3 * 100) /pelo autor do processo e apresentada na Tabela 1. 4,5 = 66,66 / 100 = 0,66; Deve-se observar que a inserção de valores para a definição • terceira linha da primeira coluna normalizada: (0,5 * 100) /da matriz de importância é feita a partir de definição de um 4,5 = 11,11 / 100 = 0,11.critério ou julgamento. Assim, os valores são inseridos namatriz de acordo com a escala de importância estabelecida Este processo de normalização deve ser feito com todospelo julgamento. Na Tabela 3 é possível verificar a formação os requisitos envolvidos no processo. Segundo Tocchetto, ada matriz. utilização do vetor T normalizado serve para quantificar e ponderar a importância de várias características de um re- Requisito Requisito 1 Requisito 2 Requisito 3 quisito. Você pode acompanhar o resultado da normalização do vetor na Tabela 4. Requisito 1 1 1/3 2 Requisito 2 3 1 5 Requisito Requisito 1 Requisito 2 Requisito 3 Resultado Requisito 3 ½ 1/5 1 Requisito 1 0,22 0,21 0,25 0,68Tabela 3. Matriz de importância Requisito 2 0,67 0,65 0,63 1,95 Após a definição, é necessário efetuar o cálculo do auto-vetor Requisito 3 0,11 0,13 0,12 0,36e a sua normalização, para cada um dos requisitos envolvidos Tabela 4. Matriz com os valores normalizados40 Engenharia de Software Magazine - Gerenciando mudanças a partir de requisitos
  • 40. requisitos Desta maneira, o percentual de importância de cada requisito projetos de desenvolvimento de software. Neste contexto,é apresentado através da Tabela 5. Assim, tem-se que: vimos neste artigo que gerir mudanças é uma atividade• o requisito 1 equivale aproximadamente a 22,44% do projeto; fundamental em projetos de desenvolvimento de software.• o requisito 2 equivale aproximadamente a 64,35% do projeto; É natural que os requisitos mudem e evoluam ao longo do• o requisito 3 equivale aproximadamente a 11,88% do projeto. tempo. Cabe à equipe de desenvolvimento gerenciar isto da melhor forma com intuito de minimizar impactos negativos Fator 1/n Requisito normalizado Importância (%) no andamento do projeto.1/3 0,68 22,441/3 1,95 64,35 Dê seu feedback sobre esta edição! Feedback1/3 0,36 11,88 eu s DêTabela 5. Importância de cada requisito A Engenharia de Software Magazine tem que ser feita ao seu gosto. sobre e Para isso, precisamos saber o que você, leitor, acha da revista! s taConclusão edição Dê seu voto sobre este artigo, através do link: A engenharia de requisitos define, sem dúvida, um dos mais www.devmedia.com.br/esmag/feedbackimportantes conjuntos de atividades a serem realizadas em Referências APACHE SOFTWARE FOUNDATION.Apache log4j 1.2.[S.l.], 2011.<http://logging.apache.org/log4j/1.2//>. 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>. 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) HAMILTON,Vivien L.;BEEBY,Martin.Issues of traceability in integration tools.In:IEE COLLOQUIUM ON TOOLS – Centro de Ciências Exatas e Naturais, Universidade Regional de Blumenau, Blumenau. <http:// ANDTECHNIQUES FOR MAINTAININGTRACEABILITY DURING DESIGN,1.,1991,Londres.Procedings. Londres: campeche.inf.furb.br/tccs/2007-I/2007-1raphaelmarcosbatistavf.pdf>. IEEE, 1991. p. 4/1-4/2. <http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=182212>. BELTRÃO FILHO, Mauro F. de H. Gingway – uma ferramenta para criação de aplicações Ginga- HAROLD, Elliotte R. Processing XML with Java. [S.l.], 2001. <http://www.cafeconleche.org/books/xmljava/>. 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. HAZAN, Claudia; LEITE, Julio C. S. P. Indicadores para a gerência de requisitos. In: WORKSHOP EM br/~tg/2008-2/mfhbf.pdf>. 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>. 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 HENKELS, André. Drawcode: um plugin do eclipse para geração de código a partir de diagramas de Computação, Universidade Federal de Minas Gerais, Belo Horizonte. <http://homepages.dcc.ufmg. classe e diagramas N-S. 2007. 101 f. Trabalho de Conclusão de Curso (Bacharelado em Ciências da br/~wilson/pesquisa/DissertacaoEduardo.pdf>. Computação) - Centro de Ciências Exatas e Naturais, Universidade Regional de Blumenau, Blumenau. BON, Jonas; VASSEUR, Alexandre. AspectWerkz: plain Java AOP 2.0 API. [S.l.], 2005. <http:// HUNTER, Jason; MCLAUGHLIN, Brett. JDOM: FAQ. [S.l.], 2007. <http://www.jdom.org/docs/faq. aspectwerkz.codehaus.org>. html#a0000>. BURNETTE, Ed. Eclipse IDE – guia de bolso. Tradução João Torello. Porto Alegre: Bookman, 2006. JASPERFORGE. IReport: JasperForge. [S.l.], 2011. <http://jasperforge.org/projects/ireport>. COSTA, Helder G. Introdução ao método de análise hierárquica: análise multicritério no auxílio à LOPES, Luiz H. C. Sistema web para gestão de pautas e atas de reuniões. 2008. 55 f. Monografia (Curso decisão. Niterói: Universidade Federal Fluminense, 2002. de Especialização em Informática Empresarial) – Universidade Estadual Paulista, Guaratinguetá. <http://www.feg.unesp.br/ceie/Monografias-Texto/CEIE0805.pdf>. ECLIPSE FOUNDATION. About the eclipse foundation. [S.l.], 2011. <http://www.eclipse.org/org/> MARINS, Cristiano S.; SOUZA, Daniela de O.; BARROS, Magno da S. O uso do método de análise FEIGENBAUM, Barry. SWT, Swing or AWT: which is right for you? [S.l.], 2006. <http://www.ibm. hierárquica (AHP) na tomada de decisões gerenciais: um estudo de caso. In: SIMPÓSIO BRASILEIRO com/developerworks/grid/library/os-swingswt/> 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- FERREIRA, Felype S. Implementação e análise de uma linha de produtos de software. 2009. 67 1788. <http://www.ic.uff.br/~emitacc/AMD/Artigo%204.pdf>. 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>. 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 GENVIGIR, Elias C. Um modelo para rastreabilidade de requisitos de software baseado em Naturais, Universidade Regional de Blumenau, Blumenau. generalização de elos e atributos. 2009. 200 f. Teste de Doutorado do Curso de Pós Graduação em Edição 44 - Engenharia de Software Magazine 41
  • 41. Arquitetura e Desenvolvimento Nesta seção você encontra artigos voltados para diferentes abordagens de apoio ao desenvolvimento de projetos de software Introdução ao desenvolvimento de aplicações de realidade aumentada 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 André Luis Tosato da Cruz Paulo C. Barreto da Silva estudantes e profissionais da área de computação andreluistosatoo@gmail.com paulo.b@aedu.com Graduando em Ciência da Computação pela Graduado em Análise de Sistemas pelo que estejam interessados em conhecer os aspectos Faculdade Anhanguera de Santa Barbara Centro Universitário Salesiano de São Paulo fundamentais da Realidade Aumentada como ferra- (2011), atualmente trabalhando como As- (2003) e Pós-graduado pela Universidade menta de apoio. sistente de Desenvolvimento(Delphi e c#) e Estadual de Campinas - UNICAMP – na área possui interesse por programação. de Orientação a Objetos (2005). Professor Em que situação o tema é útil? da Anhanguera Educacional SA e Analista de Sistemas na Papirus Indústria de Papel Como embasamento para projetos que desejem Victor Angelo Marcorin SA. Possui experiência de 12 anos na área adotar ferramentas gráficas de simulação. Projetos victor.am.ccomp@gmail.com de Ciência da Computação, com ênfase em que utilizem a inclusão de objetos virtuais intera- Graduando em Ciência da Computação pela Sistemas de Informação, atuando princi- tivos com o objetivo de demonstrar um ambiente Faculdade Anhanguera de Santa Barbara palmente nos seguintes temas: análise de virtual próximo da experiência real. (2011). Estagiário na área da computação sistemas, programação orientada a obje- recém-contratado pela ItalyTex. Possui co- tos, programação estruturada, desenvolvi- nhecimentos na área de desenvolvimento de mento de sistemas, UML (Linguagem de Resumo softwares e manutenção de computadores. Modelagem Unificada), gestão de projetos, A Realidade Aumentada pode ser definida como uma linguagem de programação C e Java. combinação do ambiente real com o ambiente virtual. Thiago Salhab Alves Neste contexto, este artigo apresenta conceitualmen- A thiago.alves@aedu.com Realidade Virtual vem revolu- te o tema e, na sequência, faz uma introdução ao de- Graduado em Ciência da Computação pela cionando a área da educação senvolvimento de aplicações desta natureza. Universidade Metodista de Piracicaba – UNIMEP (2004) e Mestre em Ciência da com suas características que Computação pela Universidade Metodista de permitem ao usuário vivenciar situações Piracicaba - UNIMEP (2008). Professor e Coor- através de navegação e interação em Atualmente, ela é o tipo de interface com denador do curso de Ciência da Computação mundos virtuais. o usuário que tem chamado mais a aten- da Faculdade Anhanguera de Santa Bárbara. A Realidade Aumentada pode ser ção pelo fato de permitir aos usuários Possui seis anos de experiência na área de Ciência da Computação com ênfase em Enge- definida como uma combinação do executar tarefas de forma mais intuitiva nharia de Software. ambiente real com o ambiente virtual. e eficiente. As interfaces de Realidade42 Engenharia de Software Magazine - Introdução ao desenvolvimento de aplicações de realidade aumentada
  • 42. Arquitetura e DesenvolvimentoAumentada devem aumentar a percepção do usuário sobre o utilizando dispositivos tecnológicos como webcams, câmerasmundo real adicionando informações virtuais nele. digitais, óculos digitais, entre outros. Um dos problemas na área da educação é manter a motivação Pelo fato de utilizar os movimentos do corpo como umados alunos no aprendizado de um determinado conteúdo. forma de interação com o computador através de dispositivosMuitas vezes faltam recursos para os professores de anatomia característicos da tecnologia, a Realidade Virtual é consideradaauxiliar a formação dos educandos e também motivação por como a forma mais avançada de comunicação entre pessoasparte deles, principalmente na área médica, em função da e computadores.complexidade do corpo humano. Segundo Kirner e Zorzal [4], a Realidade Aumentada pode Neste contexto, este artigo apresenta uma introdução ao ser definida como uma tecnologia através da qual se incre-desenvolvimento de aplicações em realidade aumentada, en- menta ou aumenta a visão que um utilizador tem do mundofatizando as possibilidades existentes para a área da educação real com a adição de imagens virtuais, usando técnicas dee médica (ler Nota do DevMan 1). visão por computador e de Computação Gráfica/Realidade Virtual, resultando na sobreposição de objetos virtuais com o mundo real. Nota do DevMan 1 Esta tecnologia possibilita que o usuário tenha uma interação atrativa e motivadora com o ambiente, propiciando então o de- Aprendizagem de Anatomia Humana senvolvimento de habilidades e construção do conhecimento. Segundo 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- Aplicações de Realidade Aumentada do a vários motivos: a dificuldade do aluno com a terminologia anatômica, o pequeno É cada vez mais comum nos depararmos com várias aplicações tamanho das estruturas, o preparo inadequado das peças e vários fatores individuais da Realidade Aumentada atualmente, já é utilizada na Educação, como falta de motivação, atenção e o medo ou receio existente quando o aluno se Medicina, Jogos, Design, Engenharia e dentre outros. depara com os cadáveres humanos. Uma de suas aplicações mais recentes foi a campanha da Em uma experiência de aula, uma professora dividiu 132 alunos do Curso de Farmá- nova fragrância da Empresa AXE, que tinha como slogan da cia em duas turmas, onde em uma, ela aplicou os métodos de ensino tradicionais e na campanha “Even Angels will fall...” (“Até os Anjos cairão...”), outra, foram utilizados os mesmos métodos, só que após a aula, os alunos permane- onde colocaram um marcador no meio de uma estação de ciam no laboratório para interagir com as estruturas estudadas em sala, e após essa metrô, e quando a pessoa passava e olhava para cima, aparecia interação foi proposto para os alunos que explicassem as estruturas para o professor um anjo no telão da estação (ver Figura 1). 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.Contextualizando Realidade Aumentada é mais um das vertentes da RealidadeVirtual, porém enquanto a Realidade Virtual tem como prin-cípio a inserção do usuário em um ambiente fictício geradopor computador, isentando este de todo ou quase todos ossentidos reais, a Realidade Aumentada insere objetos virtuaisem um ambiente real sem ocultar do usuário o que está a sua Figura 1. Campanha Publicitária da empresa AXE com RAvolta. Como o próprio nome diz, seu objetivo é aumentar acomplexidade do mundo real inserindo objetos virtuais e tudo Medicinaisto em tempo de execução real. A Realidade Aumentada já está ajudando pessoas que sofrem Esta tecnologia está cada vez mais inserida em nosso cotidia- de varizes. Dr. KasuoMiyake (Especialista no tratamento deno, pois já existem aplicações em celulares, jogos, simuladores, varizes) ajustou o equipamento VeinViewer, uma espécie deinclusive aplicações na área médica e artística. visão de raios X, que auxilia na coleta de sangue e na medica- Realidade aumentada é uma especialização da realidade vir- ção intravenosa, e o adaptou utilizando RA para auxiliar notual, baseada na inserção de objetos virtuais em uma cena real, tratamento de varizes, dispensando cirurgia. Segundo Miyake,podendo o usuário interagir com o objeto em tempo real. esta técnica já evitou cirurgias em 86% dos casos desde 2007 (ver Figura 2).Realidade Aumentada Após analisar a aplicabilidade da realidade aumentada no A Realidade Aumentada é uma tecnologia que possibilita a cotidiano das pessoas, Sabbatini [6] concluiu que já existeinclusão de objetos virtuais interativos em um ambiente real, disponível no mercado uma vasta gama de equipamentos Edição 44 - Engenharia de Software Magazine 43
  • 43. baseados em realidade aumentada, sendo a área médica a mais Os passos apresentados na Figura 5 são descritos da seguinteavançada no assunto. maneira: O uso de equipamentos baseados em realidade aumentada • Captura da cena com o marcador;tem permitido o amplo treinamento de suturas como mostrado • Identificado o símbolo encontrado, o software busca pelanas Figuras 3 e 4, inserção de cateter na veia subclávia, disco- imagem 3D referente ao código do marcador;tomia vertebral laparoscópica, dentre muitas outras coisas. • 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 2. Aplicando RA para o Tratamento de Varizes Figura 5. Funcionamento de RA pela posição do MarcadorFigura 3. Exemplo de uma aplicação da realidade virtual na medicina A disposição do objeto pode ser interferida de várias manei-“Simulação de micro suturas” 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 4. Treinamento de Suturas Figura 6. Amostra da RAFuncionamento da Realidade Aumentada A realidade aumentada possui seu funcionamento baseado Ferramentas para Desenvolvimentona captura de uma imagem codificada e devolvendo sobre Atualmente temos várias ferramentas disponíveis para oesta uma figura em 3D com total mobilidade e execução em desenvolvimento de realidade aumentada. Um das ferramentastempo real, pois de acordo com a posição do marcador a figura é o FLARToolKit. Segundo Tomohiko Koyama, um de seusprojetada é ajustada. desenvolvedores, é uma versão baseada no NyARToolKit44 Engenharia de Software Magazine - Introdução ao desenvolvimento de aplicações de realidade aumentada
  • 44. Arquitetura e Desenvolvimento(ARToolKit para Java), adaptada para o Flash, que é possível ARToolKitde ser incorporado em páginas Web. Para o desenvolvimento O ARToolKit é uma biblioteca Open Source desenvolvido emde aplicações com o FLARToolkit é necessário ter objetos 3D linguagem C e C++ para o desenvolvimento de aplicações emdesenvolvidos nas principais engines 3D do Flash como o Pa- realidade aumentada. No site http://www.hitl.washington.pervision 3D, Away 3D, entre outros e utilizar programação edu/artoolkit/download/ pode ser feito o download do pacoteem ActionScript, além de ter um ambiente de desenvolvimento de desenvolvimento.para Flash (ver Figura 7). 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 ARToolKit Na Figura 9, a área em vermelho corresponde às aplicaçõesFigura 7. Aplicação usando FLARToolkit em realidade aumentada. Em seguida vem o ARToolkit que O funcionamento desta tecnologia se dá basicamente da interage com as bibliotecas OpenGL, a GLUT, a Standard Li-seguinte forma: brary e Video Library. O OpenGL é a biblioteca que cuida da• A câmera captura imagens do mundo real e as envia ao parte gráfica da aplicação.computador;• O software procura em frames do filme todas as formasquadradas;• Se entre estes quadrados ele detectar um marcador, atravésde algoritmos matemáticos é calculada a posição da câmeraem 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 porposiçã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, ondeo objeto virtual é inserido em cima do marcador. 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 Artoolkit O 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 Figura 8. Imagem inserida sobre o marcador funções do ARToolKit juntamente com seus significados. Edição 44 - Engenharia de Software Magazine 45
  • 45. Função DescriçãoARMarkerInfo 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 ARToolKitA relação entre a câmera e os marcadores Conclusão O ARToolKit calcula a posição do marcador e da câmera Neste artigo foram apresentados os conceitos básicos daatravés do sistema de coordenadas, com o uso do sistema Realidade Aumentada. Foi possível identificar os benefíciosde matriz, possibilitando calcular a posição na qual o objeto que a Realidade Aumentada tem proporcionado para as di-virtual vai ser inserido (ver Figura 10). 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. Referências 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 Figura 10. Exemplo de marcador Depois que a imagem é capturada ela é transformada em 1. BRAZ, Paula Regina Pereira. Método Didático Aplicado ao Ensino da Anatomia Humana.uma imagem binária e através de algoritmos computacionais, Anuário da Produção Acadêmica Docente, Valinhos, n. , p.303-310, 19 mar. 2010.onde são reconhecidos os padrões quadrados e recuperada a 2. FAZOLLI, Fernando Yuki. Realidade Aumenta: Monografia do Bacharelado em Ciência daposição de cada um dos quatros vértices com estes valores, é Computação. Santa Bárbara D’ Oeste: Faculdade Anhanguera de Santa Barbara, 2009.calculada a posição do objeto que vai ser sobreposto na imagemanalisada conforme a Figura 10. 3. GOMES, Wneiton Luiz; KIRNER, Cláudio. Desenvolvimento de Aplicações Educacionais na Neste sistema, cada quadro de imagem do ambiente captura- Medicina Com Realidade Aumentada. Bazar: Software e Conhecimento Livres, 2006.do é transformado para binário para facilitar o reconhecimento 4. KIRNER, Claudio; ZORZAL, Ezequiel. Jogos Educacionais em Ambiente de Realidadee a posição espacial do marcador a ser localizado. Feito isto, Aumentada. Workshop de Realidade Aumentada, Piracicaba, 2005. Disponível em: <http://para cada imagem de vídeo, o desenho interior do marcador www.realidadeaumentada.com.br/artigos/14534.pdf> Acesso em 27 de Junho de 2011.reconhecido é comparado com os gabaritos de marcadorespré-definidos (ver Figura 11). 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. Dê seu feedback sobre esta edição! Feedback eu s Dê A Engenharia de Software Magazine tem que ser feita ao seu gosto. sobre e Para isso, precisamos saber o que você, leitor, acha da revista! s ta edição Dê seu voto sobre este artigo, através do link:Figura 11. Sequência do reconhecimento do marcador (HITLab, www.devmedia.com.br/esmag/feedbackUniversity of Washington)46 Engenharia de Software Magazine - Introdução ao desenvolvimento de aplicações de realidade aumentada
  • 46. Arquitetura e Desenvolvimento Nesta seção você encontra artigos voltados para diferentes abordagens de apoio ao desenvolvimento de projetos de software Boas práticas para escrita de métodos, funções e procedimentos – Parte 6 Mantendo Limites e Casos de Teste Unitários Limpos De que se trata o artigo? Resumo Aborda o tema Código Limpo com o objetivo de mos- Esta série de artigos tem discutido os aspectos trar como o desenvolvedor pode usá-lo para melhorar que permeiam o assunto Código Limpo, seguindo a qualidade do código-fonte de suas aplicações. Neste a linha de raciocínio que propõe um aumento na sentido, este artigo provê conhecimento ao desenvol- qualidade do código das aplicações existentes ou vedor sobre como transformar códigos considerados proporcionar conhecimento de como criar projetos ruins em bons códigos demonstrando através de de código melhores quando se está iniciando um exemplos práticos as teorias aqui abordadas. novo projeto. Neste contexto, código limpo se re- Jacimar Fernandes Tavares fere a um conjunto de características desejáveis de jacimar.tavares@hotmail.com Em que situação o tema é útil? serem encontradas no código de nossa aplicação. Pós Graduando em Gestão de Projetos de O tema se torna fundamental para desenvolve- Algumas dessas características são: ter um código TI – Universidade Federal de Juiz de Fora dores que buscam cada vez mais melhorar suas que atenda os requisitos de eficiência, lógica do UFJF Bacharel em Ciência da Computação FAGOC aplicações ao focar em qualidade de código. Essa negócio bem modelada e definida em forma de - Faculdade Governador Ozanam Coelho, tarefa será possível graças ao conhecimento ad- código fonte, mecanismos de tratamento de erro Atua como administrador financeiro na quirido sobre limpeza de código. bem definidos e código que não dê margem à ne- empresa Transporte JR. cessidade da realização de novas otimizações. Marco Antônio Pereira Araújo A maraujo@devmedia.com.br relação existente entre um sof- Uma dessas verificações consiste em É Doutor e Mestre em Engenharia de Sis- tware desenvolvido por uma conhecer as funcionalidades que pode- temas e Computação pela COPPE/UFRJ, equipe, e que faz uso de código rão ser utilizadas e as funcionalidades Especialista em Métodos Estatísticos Com- de terceiros, requer alguns cuidados, que não poderão ser utilizadas, por putacionais e Bacharel em Informática pela UFJF, professor do curso de Bacharelado em como conhecer bem o código a ser uti- exemplo, uma funcionalidade na qual Ciência da Computação da FAGOC, professor lizado ou conhecer o que ele é capaz de um dos usuários do sistema não deve dos Cursos de Bacharelado em Sistemas de fornecer em termos de funcionalidades. ter acesso. Conhecidas as funciona- Informação do Centro de Ensino Superior Estabelecer a forma como o software lidades que se pode acessar e as que de Juiz de Fora e da Faculdade Metodista em desenvolvimento e o código de não se pode, devem-se estabelecer os Granbery, Analista de Sistemas da Prefeitu- ra de Juiz de Fora, Editor da Engenharia de terceiros devem se comunicar é uma limites, isto é, criar mecanismos para Software Magazine. tarefa que envolve algumas verificações. controlar o acesso a tais funcionalidades. Edição 44 - Engenharia de Software Magazine 47
  • 47. A forma como esses mecanismos são construídos, em alguns código de terceiros muitas das vezes tenha mais funciona-casos, leva a escrita de código que não é considerado limpo. lidades do que normalmente se precisa quando se opta porUm dos objetivos deste artigo é falar sobre esses mecanismos utilizá-lo.que estabelecem limites e como mantê-los limpos. A seção Caso seja possível refatorá-lo, isto é, modificá-lo a fim deLimites é a responsável por abordar este tema. remover códigos que não serão utilizados no instante em que Em outro cenário, agora abordando o tema teste unitário de se deseja apenas uma funcionalidade, é aconselhável que osoftware, é necessário entender alguns conceitos seguindo as faça, mas nem sempre se pode alterar tais códigos.recomendações de código limpo. Existem diversos tipos de código de terceiros, dentre eles os Escrever casos de teste unitário é uma tarefa que envolve o co- que são oferecidos em forma de componentes e classes, entrenhecimento sobre as teorias envolvidas no processo de definição outras formas.de casos de teste e também consiste em saber como escrever casos Partindo do princípio de que não se pode alterar o código dede teste de acordo com o que é necessário para um método poder terceiros que se está utilizando, será definido um exemplo deser considerado devidamente testado. Caso ainda não se tenha como utilizar o código de terceiros sem expor mais funciona-esse conhecimento, o artigo sobre Teste unitário com NUnit (ler lidades do que o necessário.edição 43 da Engenharia de Software Magazine) poderá ajudar Considerando uma classe de uma biblioteca de classes que éneste sentido. disponibilizada juntamente com um ambiente de desenvolvi- O que alguns desenvolvedores não se preocupam está relacio- mento Java ou .Net, pode-se ter vários métodos de diferentesnado à qualidade do código de teste que estão implementando. funções, das quais apenas algumas precisam ser utilizadas.Qualidade de código, referentes a código de teste, passa pelas Como exemplo, considere o código da Listagem 1.teorias sobre código limpo. Um dos objetivos da seção Testede Unidade é mostrar como devem ser mantidos os códigos de Listagem 1. Código da classe Aluno.teste criados para testar os métodos das aplicações. 1. ublic class Aluno p 2. {Limites 3. ... Nesta seção abordaremos a importância de estabelecer limites 4. public ArrayList listaAlunos = new ArrayList(); 5. ...para testar aplicações. Esta seção dá ênfase a código de terceirosque muita das vezes são inseridos em algumas aplicações devi- 6. public void adicionarAlunoLista(Aluno aluno)do, entre outras coisas, a necessidade de adquirir, por exemplo, 7. { 8. listaAlunos.Add(aluno);um componente de terceiros. Ao se conhecer os limites que o 9. }código ou componente de terceiros possuem, torna-se possívelconhecer seu funcionamento e suas limitações. Com base nes- 10. public ArrayList recuperarListaAlunos() 11. {tas informações fica mais fácil saber quando uma nova versão 12. return listaAlunos;do código ou componente de terceiros é mais recomendada 13. }ao projeto atual do que a versão antiga dos mesmos que está 14. ... 15. }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 A Listagem 1 possui o código da classe Aluno, que utilizasatisfazer alguma das necessidades do projeto é uma prática código de terceiros, isto é, código da biblioteca de classes doque contribui para se ter um código limpo. Dentre todos os .Net Framework, mais precisamente da classe ArrayList, queobjetivos desta seção, manter o código limpo, incluindo o fornece objetos que atuam como lista de dados. Ao disponi-limite entre a aplicação e os códigos de terceiros, é o objetivo bilizar essa classe, o .Net Framework disponibiliza tambémprincipal. 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 Estabelecendo os limites entre o código criado e o código método .Add e retorna uma lista com os alunos existentes.de terceiros A Listagem 2 mostra o código cliente da classe Aluno. Conceitua-se código criado como o código que está sen- No código cliente da Listagem 2 é possível verificar que, parado implementado ou foi implementado em uma aplicação. adicionar um objeto aluno à lista de alunos da classe Aluno, éConceitua-se código de terceiros como qualquer código que foi invocado o método adicionarAlunoLista, linha 2 da Listagem 2.implementado por outra empresa, equipe ou desenvolvedor, Para recuperar a lista de alunos é invocado o método recupe-cujo propósito satisfaz a alguma necessidade que se tem no rarListaAlunos, linha 4, também da Listagem 2.momento, e é a razão pela qual o código está sendo comprado/ Não se deve permitir que outras operações sejam realizadas comobtido para ser utilizado. a lista de alunos da classe Aluno da Listagem 1 além das operações Códigos de terceiros geralmente são genéricos, isto é, tendem que são realizadas pelo código cliente da Listagem 2. Também nãoa abranger grande quantidade de necessidades, podendo ser se deve permitir outra forma de acesso à lista de alunos da classeutilizado em muitos cenários diferentes. Isso faz com que o Aluno, como por exemplo, acessar seu método .Add.48 Engenharia de Software Magazine - Boas práticas para escrita de métodos, funções e procedimentos – Parte 6
  • 48. Arquitetura e Desenvolvimento Aluno que não sejam os declarados na interface. O código da Listagem 2. Código cliente da classe Aluno. Listagem 5 mostra o código cliente da classe Aluno depois 1. ... das modificações geradas a partir da criação da interface da 2. aluno.adicionarAlunoLista(aluno); classe Aluno. 3. ... 4. ArrayList lista = aluno.recuperarListaAlunos(); 5. ... Listagem 5. Código cliente da interface de Aluno. 1. ... 2. alunoJose.adicionarAlunoLista(aluno); O código, da forma como está escrito, permite que as operações 3. ...que não podem ser realizadas aconteçam, caso um desenvolvedor 4. ArrayList lista = aluno.recuperarListaAlunos(); 5. ...escreva código cliente de forma que as utilize. Nesse caso, estariaviolando o princípio estabelecido de que só se pode recuperar eadicionar utilizando os métodos definidos na Listagem 1. O fato Outro ponto importante sobre código de terceiros gira emde um desenvolvedor poder burlar facilmente essa regra fere os torno do tempo que é gasto para entender o que eles realmenteprincípios de limite estabelecidos para o acesso a lista de alunos fazem. Código limpo (MARTIN, 2009) sugere que, ao invés dada classe Aluno. Para que se respeitem os limites impostos, deve- leitura da documentação sobre o que o código a ser utilizadose criar, portanto, uma estratégia que iniba a quebra da regra e pode proporcionar em termos de funcionalidades, é melhortambém que estabeleça um limite para o acesso ao código de criar casos de teste para testar se as funcionalidades que seterceiros, isto é, ao código da classe ArrayList, do .Net Framework. espera encontrar realmente existem no código de terceiros e seA estratégia definida é a criação de uma interface para a classe realmente funcionam como espera-se que funcione. Os testesAluno, com pode ser visto nas Listagens 3 e 4. criados são chamados de testes de aprendizagem, pois permi- tem que ao testar o código de terceiros, também seja obtido Listagem 3. Classe Aluno modificada. certo conhecimento acerca do que o código é capaz de fazer. Sendo assim, proporciona aprendizado sobre o código a ser 1. public class Aluno: IAluno utilizado, além de se ter a certeza de que ele não contêm erros, 2. { 3. private ArrayList listaAlunos = new ArrayList(); 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 4. public void adicionarAlunoLista(Aluno aluno) terceiros gira em torno da disponibilização de novas versões do 5. { 6. listaAlunos.Add(aluno); código. Sempre que um terceiro lançar novas versões do código, 7. } 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 8. public ArrayList recuperarListaAlunos() 9. { as mesmas funcionalidades que a anterior, e se a nova versão vai 10. return listaAlunos; servir no lugar da versão antiga que está sendo utilizada em al- 11. } guma aplicação. Caso os testes detectem que, por exemplo, uma 12. } saída não é mais formatada como na versão antiga, rapidamente Listagem 4. Interface da classe Aluno. 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. 1. public interface IAluno 2. { 3. void adicionarAlunoLista(Aluno aluno); Concluindo limites Como visto nos exemplos das listagens apresentadas até 4. ArrayList recuperarListaAlunos(); o momento, é possível perceber que há pontos importantes 5. } 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é Na Listagem 4 está definida a interface com a classe Aluno, aonde começa o código de terceiros. Controlar estes limites, eisto é, o novo meio de acesso à classe Aluno, que o código clien- fazer com que o código de terceiros não prejudique o códigote passará a utilizar. Os métodos da classe Aluno que podem da aplicação que o invoca, é a tarefa do desenvolvedor. Comoser manipulados estão devidamente declarados na interface. geralmente códigos de terceiros possuem vários recursos,No entanto, para evitar que um desenvolvedor acesse outro muitas vezes mais do que é necessário para a finalidade quemétodo que manipula a lista de alunos da classe Aluno, foi se aplica, é interessante que o desenvolvedor saiba prepararalterado o modificador de acesso da lista de alunos de público sua aplicação para se relacionar bem com o código de terceiros.para privado (linha 3, Listagem 3). A partir deste momento, Isso deve ser feito através do estabelecimento de limites queo acesso à classe Aluno deve ser feito pela sua interface e não possuem código que pode ser considerado limpo.mais diretamente aos métodos da classe Aluno. Os limites As mesmas regras que valem para a utilização de uma simplesestão estabelecidos, uma vez que não é mais possível acessar classe de uma biblioteca de classes valem para o relacionamentooutros métodos que manipulam a lista de alunos da classe com outras aplicações. Estabelecer os limites entre o código Edição 44 - Engenharia de Software Magazine 49
  • 49. desenvolvido e o código de uma aplicação que se está integrando da falha ao comparar as saídas. Caso o teste falho necessite deé essencial. Nesse sentido, é importante saber que as aplicações uma análise de saída mais profunda, pode ser sintoma de queque estão sendo integradas ao sistema podem possuir muitas o método de teste não foi tão bem escrito como deveria.funcionalidades que podem não ser acessadas, ou as que serão Já a última recomendação revela a importância do momentoacessadas fornecem dados formatados diferentemente do espera- certo para se definir o caso de teste, que deve ser no mesmodo. Sabendo dessas particularidades, é importante que o desen- instante em que o código de produção for concebido. Códigovolvedor implemente mecanismos que permitam a comunicação Limpo (MARTIN, 2009) sugere que o método de teste sejade forma simples e limpa com a aplicação que se está integrando escrito antes mesmo do método a ser testado. Posteriormente,e que também controle os limites entre as aplicações. deve-se atentar para que o método da aplicação seja escrito de forma simples, de forma que possa ser testado.Testes de unidade Esta seção se faz necessária devido a um problema encontra- Limpando casos de testedo em casos de testes escritos para testes de unidade: código Considere a Listagem 6 de código. Ela possui uma classeilegível. Manter um código limpo inclui manter o código dos chamada OperacoesMatematicas.casos de testes limpos também. De certa forma, manter ape-nas o código do sistema limpo não é garantia de facilidade Listagem 6. Classe OperacoesMatematicasde interpretação. O tempo gasto para entender e manter o 1. public class OperacoesMatematicascódigo fonte de um sistema pode ser maior se o cuidado que 2. {o desenvolvedor teve em mantê-lo limpo não for o mesmo 3. private String mensagem;como o código utilizado para testes unitários. Assim, escrever 4. public void setMensagem(String texto)casos de testes limpos é o objetivo desta seção. Caso o leitor 5. {não esteja familiarizado com testes unitários utilizando NUnit, 6. mensagem = texto;é recomendada a leitura do artigo sobre testes unitários com 7. } 8. public String obterMensagem()NUnit na prática (ver Nota do DevMan 1). 9. { 10. return mensagem; Recomendações para se obter bons casos de testes 11. } 12. public String dividirDoisNumeros(String primeiroValor, String segundoValor) A tarefa de definir código de teste unitário deve seguir algu- 13. {mas recomendações, segundo (MARTIN, 2009). A primeira das 14. tryrecomendações gira em torno da velocidade com que um teste é 15. { 16. UInt32 numero1 = Convert.ToUInt32(primeiroValor);executado. Um teste não deve ser lento para executar, isto é, deve 17. UInt32 numero2 = Convert.ToUInt32(segundoValor);ser escrito de tal forma que possa ser executado de forma rápida. 18. UInt32 resultado = numero1 / numero2;Caso um teste não execute de forma rápida, possivelmente será 19. mensagem = “ Resultado: “ + resultado; 20. return mensagem;necessária a limpeza do código de teste rapidamente. 21. } A segunda recomendação revela que o acoplamento entre 22. catch (DivideByZeroException)códigos de teste deve ser reduzido, de preferência eliminado. 23. { 24. mensagem = “ Impossivel fazer divisão com 0”;Um trecho de código de teste não deve estar contido no corpo 25. return mensagem;de outro código de teste. Cada método de teste deve testar 26. }um método da aplicação, e não pode ser utilizado no todo ou 27. catch (FormatException) 28. {em partes para testar outros métodos que não seja o que por 29. mensagem = “ Não foi possivel a divisão. Entrada Inválida”;natureza foi definido para ser testado por ele. 30. return mensagem; A terceira recomendação é acerca da portabilidade dos casos 31. } 32. catch (OverflowException)de teste. Um teste deve poder ser executado sobre o projeto 33. {desenvolvido, em qualquer lugar onde o projeto esteja, não 34. mensagem = “ Não foi possivel a divisão com números Negativos”;somente em um local específico, como a máquina do desenvol- 35. return mensagem; 36. }vedor. É importante se ter uma estratégia que permita que os 37. }testes sejam executados em um sistema mesmo que o sistema 38. }não esteja na máquina na qual foi concebido. Outras duas recomendações sobre como os casos de teste de- OperacoesMatematicas possui um método chamado divi-vem ser concebidos e mantidos giram em torno da capacidade dirDoisNumeros. Esse método é simples, consiste em apenasde validação de um caso de teste e sobre o momento ideal para efetuar uma operação de divisão entre dois números. Esse é ose definir um caso de teste. cenário inicial para aplicação de um caso de teste, no qual pos- Sobre a capacidade de validação de um caso de teste, deve-se teriormente será possível ver a aplicação de algumas técnicasatentar para o tipo de saída que o teste fornece. A comparação de código limpo. O método OperacoesMatematicas possui umdeve ser bem clara, bem como a saída que o teste fornece. Deve fluxo normal, caso os dados inseridos sejam corretos no senti-ser possível identificar rapidamente, caso o teste falhe, o motivo do de permitir a divisão de forma natural, e outros fluxos de50 Engenharia de Software Magazine - Boas práticas para escrita de métodos, funções e procedimentos – Parte 6
  • 50. Arquitetura e Desenvolvimentoexceção, que permitem que, caso alguma exceção seja levanta- Todos os casos de teste escritos para o método dividirDoisNu-da, a mesma seja capturada e envie uma mensagem ao usuário meros (Listagem 6) passam no teste, o que indica que o métodosobre o ocorrido. Testes neste sentido devem ser capazes de escrito funciona como o esperado. Os casos de teste escritosidentificar se o método funciona com o esperado. cumpriram seus objetivos. Muitas equipes de desenvolvimento A Listagem 7 possui uma classe chamada TOperacoesMa- os descartariam neste momento, mas o melhor a fazer é mantê-tematicas, que possui os casos de teste escritos para testar o los guardados para futuros testes neste mesmo método.método dividirDoisNumeros da Listagem 6. Código Limpo (MARTIN, 2009) sugere que os casos de teste Na Listagem 7, linha 3, tem-se a instanciação de um objeto sejam mantidos, isto é, sejam armazenados, mas que, alémda classe OperacoesMatematicas, classe que possui o método disso, também possam evoluir assim como o código dos mé-dividirDoisNumeros, método que será testado. A instanciação todos da aplicação. Essa evolução diz respeito à limpeza dodesse objeto permitirá a comunicação com a classe Operacoes- código dos casos de teste. Deve-se atentar para que as técnicasMatematicas. A classe da Listagem 7 recebeu o mesmo nome de limpeza de código sejam sempre aplicadas não só ao códigoda classe da Listagem 6, a diferença está na primeira letra, ‘T’, da aplicação, mas também ao código de teste.que será utilizado para deixar claro que a classe é uma classe Além da aplicação das técnicas de código limpo, os casos deque possui código de teste. teste também devem estar de acordo com as recomendações Na classe da Listagem 7 existem quatro métodos de teste. O descritas nesta seção, em “Recomendações para se obter bonsprimeiro deles, linhas 5 a 11, permite descobrir se o cálculo de casos de testes”. Analisando os casos de teste apresentados nadivisão será feito de forma correta. Para isso, espera-se que o Listagem 7, pode-se perceber que a primeira recomendaçãoresultado seja 5, em relação ao resultado da divisão do numero se encaixa nestes testes. Os testes da Listagem 7 executam10 por 2 (linha 9). O segundo método, linhas 13 a 26, permiti- rapidamente.rá descobrir se será levantada uma exceção, caso o segundo Sobre a segunda recomendação, pode ser visto que osnúmero da divisão for zero. O método de teste das linhas 28 casos de teste executam de forma independente, isto é, nãoa 41 permitirá o teste do cenário onde uma exceção será lan- precisam do resultado um do outro para executar. A terceiraçada caso seja inserido algum valor que não é um número. Já recomendação revela que os casos de teste devem permitiro último caso de teste, linhas 43 a 56, permite descobrir se o a execução em outros locais e não somente a máquina emmétodo a ser testado realmente emite mensagem de tentativa que foi concebido. Essa recomendação se aplica a esses casosde divisão com números negativos. de teste, pois é possível rodar esses testes em outro local. Listagem 7. Código da classe TOperacoesMatematicas. 1. public class TOperacoesMatematicas 31. { 2. { 32. UInt32 n1 = Convert.ToUInt32(“sdsd”); 3. private OperacoesMatematicas operacao = new OperacoesMatematicas(); 33. UInt32 n2 = 2; 34. UInt32 result = n1 / n2; 4. [Test] 35. } 5. public void test1() 36. catch (FormatException) 6. { 37. { 7. UInt32 n1 = 10; 38. operacao.setMensagem(“ Não foi possivel a divisão. Entrada 8. UInt32 n2 = 2; Inválida”); 9. UInt32 result = n1 / n2; 39. } 10. Assert.AreEqual(5, result); 40. Assert.AreEqual(“ Não foi possivel a divisão. Entrada Inválida”, 11. } operacao.obterMensagem()); 12. [Test] 41. } 13. public void test2() 42. [Test] 14. { 43. public void test4() 15. try 44. { 16. { 45. try 17. UInt32 n1 = 10; 46. { 18. UInt32 n2 = 0; 47. UInt32 n1 = Convert.ToUInt32(-10); 19. UInt32 result = n1 / n2; 48. UInt32 n2 = 2; 20. } 49. UInt32 result = n1 / n2; 21. catch (DivideByZeroException) 50. } 22. { 51. catch (OverflowException) 23. operacao.setMensagem(“ Impossivel fazer divisão com 0”); 52. { 24. } 53. operacao.setMensagem(“ Não foi possivel a divisão com 25. Assert.AreEqual(“ Impossivel fazer divisão com 0”, operacao. números Negativos”); obterMensagem()); 54. } 26. } 55. Assert.AreEqual(“ Não foi possivel a divisão com números 27. [Test] Negativos”, operacao.obterMensagem()); 28. public void test3() 56. } 29. { 57. } 30. try Edição 44 - Engenharia de Software Magazine 51
  • 51. Basta levar o projeto para ser executado em outra máquina. Listagem 8. Código da Listagem 7 modificado.Ela deve apenas possuir a instalação do NUnit. A recomendação de número quatro mostra que os casos 1. public class TOperacoesMatematicas 2. {de teste devem ser facilmente verificados, no que se refere 3. private OperacoesMatematicas operacao = new OperacoesMatematicas();às saídas por eles produzidas. As saídas produzidas pelos 4. [Test] 5. public void testarDividirDoisNumeros1()métodos das linhas 13 a 56 mostram que, caso um teste falhe, 6. {é possível identificar facilmente o motivo, pois os retornos 7. UInt32 numero1 = 10; 8. UInt32 numero2 = 2;mostrarão duas mensagens, em cada método de teste, sendo 9. UInt32 resultado = numero1 / numero2;uma mensagem esperada e outra mensagem encontrada. 10. Assert.AreEqual(5, resultado);Caso sejam diferentes, é possível identificar a diferença no 11. } 12. [Test]mesmo instante. O método de teste das linhas 5 a 11 mostrará, 13. public void testarDividirDoisNumeros2()em caso de falha, dois números, um número esperado e o 14. { 15. tryoutro encontrado, o que permite facilmente a comparação. A 16. {ultima recomendação é acerca do momento em que o caso de 17. UInt32 numero1 = 10;teste foi definido, no caso da Listagem 7, definido no mesmo 18. UInt32 numero2 = 0; 19. UInt32 resultado = numero1 / numero2;instante em que o método dividirDoisNumeros, Listagem 6, 20. }foi definido. 21. catch (DivideByZeroException) 22. { Os casos de teste da Listagem 7 foram definidos de acordo 23. operacao.setMensagem(“ Impossivel fazer divisão com 0”);com as recomendações desta seção. Resta neste instante ve- 24. }rificar se eles foram implementados seguindo os princípios 25. Assert.AreEqual(“ Impossivel fazer divisão com 0”, operacao. obterMensagem());de código limpo, que diz respeito à aplicação das técnicas de 26. }limpeza de código. 27. [Test] 28. public void testarDividirDoisNumeros3() Em primeira análise, é possível perceber que os casos de 29. {teste da Listagem 7 não possuem nomes significativos, o que 30. try 31. {dificulta o entendimento, apensar de serem simples, sobre o 32. UInt32 numero1 = Convert.ToUInt32(“sdsd”);funcionamento do caso de teste. Nesse sentido, os casos de 33. UInt32 numero2 = 2;teste evidenciam a necessidade de uma evolução, ou seja, 34. UInt32 resultado = numero1 / numero2; 35. }aplicação de técnicas de código limpo referente à mudança 36. catch (FormatException)para nomes significativos. A Listagem 8 mostra o resultado 37. { 38. operacao.setMensagem(“ Não foi possivel a divisão.destas mudanças. Entrada Inválida”); A utilização de nomes significativos permitiu que os casos 39. }de testes se tornassem mais condizentes com seus propósitos. 40. Assert.AreEqual(“ Não foi possivel a divisão. Entrada Inválida”, operacao.obterMensagem());Os casos de teste da Listagem 7 apresentavam nomes que 41. }permitiam apenas saber, em primeira análise, que se referiam 42. [Test] 43. public void testarDividirDoisNumeros4()a um conjunto de quatro métodos de teste, mas seus nomes 44. {não demonstravam a relação existente com o método dividir- 45. tryDoisNumeros, da classe OperacoesMatematicas. 46. { 47. UInt32 numero1 = Convert.ToUInt32(-10); A partir das modificações da Listagem 8, é possível perceber 48. UInt32 numero2 = 2;facilmente que os quatro casos de teste existentes referem-se 49. UInt32 resultado = numero1 / numero2; 50. }ao método dividirDoisNumeros. Cada um dos casos de teste 51. catch (OverflowException)refere-se a uma parte do método que está sendo testada. O 52. { 53. operacao.setMensagem(“ Não foi possivel a divisão comnome testarDividirDoisNumeros, juntamente com o número números Negativos”);do caso de teste, no caso de um a quatro, permite visualizar 54. }que existem quatro diferentes testes para o método dividir- 55. Assert.AreEqual(“ Não foi possivel a divisão com números Negativos”, operacao.obterMensagem());DoisNumeros. Além da mudança do nome dos casos de teste, 56. }foram alterados os nomes das variáveis de todos os métodos 57. }de teste. Os antigos nomes não revelavam a real intenção dasvariáveis. Com estas mudanças, os casos de testes agora refle- casos de teste, como pode ser visto nas linhas 7 a 9, 17 a 19, 32 atem melhor seus propósitos. 34 e 47 a 49 (Listagem 8), além de outros trechos de código que Os casos de teste da Listagem 8 executam perfeitamente não deveriam estar no corpo do método. Sendo assim, torna-sesobre os métodos que testam. A Figura 1 mostra os casos de necessária a modificação dos casos de teste para eliminar oteste ao serem executados. código duplicado. O objetivo da remoção do código duplicado Os casos de teste possuem nomes significativos, mas ainda é também eliminar código que foi copiado do método a serpossuem outros problemas. Se analisados, os casos de teste testado. A Listagem 9 apresenta os casos de teste da Listagem 8mostram uma grande quantidade de código similar entre os depois da remoção da duplicação.52 Engenharia de Software Magazine - Boas práticas para escrita de métodos, funções e procedimentos – Parte 6
  • 52. Arquitetura e Desenvolvimento 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 1. Casos de teste sendo executados Listagem 9. Código da Listagem 8 modificado. 1. public class TOperacoesMatematicas 2. { 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] Figura 2. Métodos de teste executados com sucesso 11. public void testarDividirDoisNumeros2() 12. { 13. String resultado = operacao.dividirDoisNumeros(“10”, “0”); Conclusão 14. Assert.AreEqual(“ Impossivel fazer divisão com 0”, resultado); 15. } A série sobre Código Limpo vem cumprindo seu objetivo 16. [Test] que é o de prover conhecimento sobre como melhorar a quali- 17. public void testarDividirDoisNumeros3() dade de código das aplicações. A cada novo artigo, diferentes 18. { 19. String resultado = operacao.dividirDoisNumeros(“sdsd”, “0”); seções vêm sendo apresentadas, cada uma com um propósito 20. Assert.AreEqual(“ Não foi possivel a divisão. Entrada Inválida”, específico, mas todas contribuindo para a obtenção de código resultado); 21. } considerado limpo. 22. [Test] Neste artigo foram apresentadas as seções Limites e Teste de 23. public void testarDividirDoisNumeros4() 24. { Unidade. A seção Limites contribui para a melhoria do código 25. String resultado = operacao.dividirDoisNumeros(“-10”, “2”); que estabelece os limites existentes entre a aplicação e o código 26. Assert.AreEqual(“ Não foi possivel a divisão com números de terceiros, e a seção Teste de Unidade destaca a importância Negativos”, resultado); 27. } de manter guardados os casos de teste escritos, mas mais impor- 28. } tante do que isto, mantê-los sempre limpos, fazendo com que a qualidade do código de teste evolua sempre juntamente com a Os métodos de teste da Listagem 9, em relação aos mesmos qualidade do código da aplicação que ele testa.métodos da Listagem 8, possuem diferenças significativas. Aprimeira delas é a remoção de código duplicado. A segunda Referênciarefere-se ao fato de que as alterações que os métodos de testesofreram melhoraram a qualidade do código de teste ao fazer • MARTIN, Robert C, 2009. Código Limpo: Habilidades Práticas do Agile Software, 1ed. Rio dechamada ao método a ser testado ao invés de carregar o código Janeiro: Alta Books, 2009.semelhante ao do método testado. Em detalhes, as mudanças ocorridas nos métodos da Listagem 9 Dê seu feedback sobre esta edição! Feedback eufazem o método das linhas 4 a 9 receber o resultado do método s Dêque está sendo testado, ao passar para ele duas strings com A Engenharia de Software Magazine tem que ser feita ao seu gosto. sobre evalores 10 e 2. O resultado recebido é comparado ao resultado Para isso, precisamos saber o que você, leitor, acha da revista! s taesperado, como pode ser visto na linha 8. O mesmo ocorre com edição Dê seu voto sobre este artigo, através do link:os demais métodos. No segundo método, são testados os valores, www.devmedia.com.br/esmag/feedbackpassados como strings 10 e 2 (linha 13). No terceiro método são Edição 44 - Engenharia de Software Magazine 53
  • 53. Assista ao vídeo e descubra mais sobre a Campus Party Brasil54 Engenharia de Software Magazine - Boas práticas para escrita de métodos, funções e procedimentos – Parte 6