Page 1


Modéstia à parte, sua melhor opção para se destacar no mercado! A Escola Superior da Tecnologia da Informação oferece as melhores opções em cursos, formações, graduações e pós-graduações para profissionais de desenvolvimento e programação. São programas voltados para a formação de profissionais de elite, com aulas 100% práticas, corpo docente atuante no mercado, acesso à mais atualizada biblioteca de TI do Rio, laboratórios equipados com tecnologia de ponta, salas de estudo e exames.

PÓS- GRADUAÇÃO

Engenharia de Software: Desenvolvimento Java Engenharia de Software: Desenvolvimento .NET GRADUAÇÃO

Engenharia de Computação Análise e Desenv. de Sistemas F ORMAÇÕES

Desenvolvedor Java Desenv. Java: Sist. Distribuídos Gestor de TI Desenvolvedor Web .NET 2008 MCITP Server Administrator SQL Server 2008

r/esti Acesse nosso site e conheça todos os nossos programas: www.infnet.edu.br/esti TURMAS NO RIO DE JANEIRO www.infnet.edu.br - cursos@infnet.edu.br - Central de Atendimento: (21) 2122-8800

EDUCAÇÃO SUPERIOR ORIENTADA AO MERCADO


EDITORIAL

O

mercado de Tecnologia da Informação está cada vez mais competitivo, onde a rapidez na entrega de sistemas com qualidade, planejamento adaptativo, flexibilidade e rápida resposta às mudanças torna-se cada

vez mais desejada. Diante desse contexto, surgiu um novo conceito de metodologia ágil na gestão de projetos de sistemas, o Scrum.

Ano 2 - 23ª Edição - 2010

Impresso no Brasil

O Scrum é uma metodologia ágil para gerência de projetos, baseado em inspeção e adaptação, iterativo e incremental, e pode ser aplicado a qualquer produto ou no gerenciamento de qualquer atividade complexa. Cada iteração de

Corpo Editorial

trinta dias conhecida como Sprint produz um conjunto de funcionalidades.

Colaboradores Rodrigo Oliveira Spínola rodrigo@sqlmagazine.com.br

Scrum na Melhoria do Gerenciamento de Projetos de Software. Neste artigo,

A Engenharia de Software Magazine traz como capa desta edição a matéria: além de estudar uma metodologia que se encaixa em uma categoria já conhecida pelo mercado de TI, chamada agile development, serão também destacadas

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

as vantagens de se utilizar tal metodologia em relação a outros processos tradicionais e avaliar a aceitação do Scrum no mercado atual, identificando algumas

Capa Romulo Araujo - romulo@devmedia.com.br

empresas que já obtiveram sucesso com o seu uso. Além desta matéria, esta edição traz mais sete artigos:

Diagramação Janete Feitosa

• Experiências Práticas na Avaliação MPS.BR; • Gestão de Projetos segundo o PMBOK;

Coordenação Geral Daniella Costa - daniella@devmedia.com.br

• Métricas e Planejamento com XPlanner;

Revisor e Supervisor Thiago Vincenzo - thiago.v.ciancio@devmedia.com.br

• Análise Orientada a Objetos;

Na Web www.devmedia.com.br/esmag

• Levantando Exceções no Desenvolvimento de Software.

• SOA e seus Atributos de Qualidade; • Catalogação de Padrões;

Apoio

Desejamos uma ótima leitura! Equipe Editorial Engenharia de Software Magazine

Atendimento ao Leitor A DevMedia conta com um departamento exclusivo para o atendimento ao leitor. Se você tiver algum problema no recebimento do seu exemplar ou precisar de algum esclarecimento sobre assinaturas, exemplares anteriores, endereço de bancas de jornal, entre outros, entre em contato com: Cristiany Queiróz– Atendimento ao Leitor www.devmedia.com.br/mancad (21) 2220-5338

Kaline Dolabella Gerente de Marketing e Atendimento kalined@terra.com.br (21) 2220-5338

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

Fale com o Editor! É muito importante para a equipe saber o que você está achando da revista: que tipo de artigo você gostaria de ler, que artigo você mais gostou e qual artigo você menos gostou. Fique a

Rodrigo Oliveira Spínola rodrigo@sqlmagazine.com.br 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 Produtos e Processos de Software, Requisitos e Desenvolvimento Orientado a Objetos. Consultor para implementação do MPS.BR. Atua como Gerente de Projeto e Analista de Requisitos em projetos de consultoria na COPPE/UFRJ. É Colaborador da Engenharia de Software Magazine.

Marco Antônio Pereira Araú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 em Matemática com Habilitação em Informática pela UFJF, Professor e Coordenador do curso de Bacharelado em Sistemas de Informação do Centro de Ensino Superior de Juiz de Fora, Professor do curso de Bacharelado em Sistemas de Informação da Faculdade Metodista Granbery, Professor e Diretor do Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas da Fundação Educacional D. André Arcoverde, Analista de Sistemas da Prefeitura de Juiz de Fora, Colaborador da Engenharia de Software Magazine.

vontade para entrar em contato com os editores e dar a sua sugestão! Se você estiver interessado em publicar um artigo na revista ou no site SQL Magazine, entre em contato com os editores, informando o título e mini-resumo do tema que você gostaria de publicar: Rodrigo Oliveira Spínola - Colaborador editor@sqlmagazine.com.br

Eduardo Oliveira Spínola (eduspinola@gmail.com) É Colaborador das revistas Engenharia de Software Magazine, Java Magazine e SQL Magazine. É bacharel em Ciências da Computação pela Universidade Salvador (UNIFACS) onde atualmente cursa o mestrado em Sistemas e Computação na linha de Engenharia de Software, sendo membro do GESA (Grupo de Engenharia de Software e Aplicações).


Caro Leitor,

Para esta edição, temos um conjunto de 5 vídeo aulas. Estas vídeo aulas estão disponíveis para download no Portal da Engenharia de Software Magazine e certamente trarão uma significativa contribuição para seu aprendizado. A lista de aulas publicadas pode ser vista abaixo:

Tipo: Validação, Verificação & Teste Título: Processo de Teste de Software: Papéis, Atividades e Artefatos Autor: Arilo Claudio Dias Neto Mini-Resumo: Nesta vídeo-aula é apresentado um possível processo de teste que pode ser aplicado em uma organização de software. São apresentados os papéis associados ao processo, suas atividades que foram subdivididas em 2 subprocessos (Subprocesso de Planejamento e Subprocesso de Execução) e os artefatos produzidos ao longo do processo, que são baseados no padrão IEEE-829, que descreve um conjunto de roteiros de documentos que podem ser utilizados para documentação das atividades de teste de software. Tipo: Validação, Verificação & Teste Título: Técnicas de Teste Funcional: Parte I – Particionamento em Classes de Equivalência Autor: Arilo Cláudio Dias Neto Mini-Resumo: Nesta vídeo-aula são discutidas as diferentes técnicas de teste de software que podem ser aplicadas (teste funcional, estrutural e baseado em erros), enfatizando as técnicas de teste funcional, seus objetivos, funcionamento e principais critérios para geração de casos de teste. A aula foca no primeiro critério, Particionamento em Classes de Equivalência, apresentando sua definição, algoritmo para geração de casos de teste a partir de exemplo prático, e ao final um exercício com sua solução. Tipo: Validação, Verificação & Teste Título: Técnicas de Teste Funcional: Parte II – Análise do Valor Limite Autor: Arilo Cláudio Dias Neto Mini-Resumo: Nesta vídeo-aula inicialmente são relembradas as diferentes técnicas de teste de software que podem ser aplicadas (teste funcional,

estrutural e baseado em erros), mas o foco continua sendo as técnicas de teste funcional e seus critérios para geração de casos de teste. Em seguida, é descrito o segundo critério para geração de casos de teste funcionais, Análise do valor Limite, apresentando sua definição, algoritmo para geração de casos de teste e um exemplo prático de geração de casos de teste. Tipo: Validação, Verificação & Teste Título: Técnicas de Teste Funcional: Parte III – Grafo de Causa-Efeito Autor: Arilo Cláudio Dias Neto Mini-Resumo: Nesta vídeo-aula inicialmente são relembradas as diferentes técnicas de teste de software que podem ser aplicadas (teste funcional, estrutural e baseado em erros), mas o foco continua sendo as técnicas de teste funcional e seus critérios para geração de casos de teste. Em seguida, é descrito o terceiro critério para geração de casos de teste funcionais, Grafo de CausaEfeito, apresentando sua definição, algoritmo para geração de casos de teste e um exemplo prático de geração de casos de teste. Tipo: Validação, Verificação & Teste Título: Outras Técnicas de Teste: Parte IV – Técnica Estrutural e Técnica Baseada em Erros Autor: Arilo Cláudio Dias Neto Mini-Resumo: Nesta vídeo-aula são apresentados 2 tipos de técnicas de teste: técnica estrutural e baseada em erros. A técnica de teste estrutural é apresentada a partir de suas definições, construção do grafo de fluxo de controle e dos critérios para geração de casos de teste baseado em fluxo de controle (todos-nós, todas-arestas, todos-caminhos). A técnica de teste baseada em erros é apresentada a partir de suas definições e de 2 critérios para geração de testes: semeadura de erros e análise de mutantes.

ÍNDICE Engenharia 05 - Experiências Práticas na Avaliação MPS.BR Sarah Kohan e David Yoshida

Agilidade 08 - Implantação do Scrum para Melhoria no Gerenciamento de Projetos de Software Renata de Souza Alves Paula

Planejamento e Gerência 18 - Gestão de Projetos segundo o PMBOK Cleyverson Pereira Costa e Alexandre Luna

24 - Métricas e Planejamento com XPlanner Lenildo Morais

Desenvolvimento 31 - SOA e seus Atributos de Qualidade Jorge Dias Jr.

36 - Análise Orientada a Objetos Antonio Mendes da Silva Filho

43 - Catalogação de Padrões Evaldo de Oliveira da Silva e Jugurta Lisboa Filho

50 - Levantando Exceções no Desenvolvimento de Software Jacimar Fernandes Tavares, Marcelo Santos Daibert e Marco Antônio Pereira Araújo

4

Engenharia de Software Magazine


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

Experiências Práticas na Avaliação MPS.BR Um relato da Fundação Vanzolini como Instituição Avaliadora De que se trata o artigo?

Sarah Kohan

David Yoshida

sarah.kohan@vanzolini.org.br

dyoshida.pro@gmail.com

Bacharel em Ciência da Computação - Instituto de Matemática e Estatística da Universidade de São Paulo. Mestre em Engenharia de Software pelo IPT - Instituto de Pesquisas Tecnológicas. Implementadora e Avaliadora Líder MPS.BR e Instrutora do curso de Introdução ao MPS.BR (C1- MPS. BR) credenciada pela SOFTEX. Possui experiência em projetos de desenvolvimento software aplicativo e software básico. Nos últimos dez anos participa de programas de Qualidade, desenvolvendo atividades de treinamento, implantação melhorias de processo com base nos modelos CMMI, MPS.BR, ISO 12207 e ISO 15504, através da Fundação Carlos Alberto Vanzolini ligada a Escola Politécnica da Universidade de São Paulo. Tem participado de equipes de avaliação CMMI V1.2 (SCAMPI A e B), MA-MPS e QuickLocus como líder. Ministra cursos nos programas de especialização da FIAP – Faculdade de Informática e Administração Paulista e na Fundação Vanzolini. Participou da coordenação do Programa ComQualidade MPS.BR - Melhoria de Processo de Software Brasileiro, parceria entre o ITS e a Fundação Vanzolini.

Bacharel em Administração de Empresas e Tecnólogo em Processamento de Dados. Pós-graduado em Análise de Sistemas. Consultor em qualidade de software e melhoria de processo de software com base no modelo CMMI. Implementador credenciado pelo Softex/MPS.BR para melhoria de processos com base no modelo MPS. BR. Avaliador credenciado para avaliações oficiais MPS.BR. Coordenou o Centro de Qualidade e Testes do Software do ITS. Foi responsável pela coordenação do Programa Cooperativo CMMI ITS implementando melhoria de processos com base no modelo CMMI, Nível 2 de maturidade. Participou da coordenação do Programa ComQualidade MPS.BR - Melhoria de Processo de Software Brasileiro, parceria entre o ITS e a Fundação Vanzolini. Certificado ITIL Foundation.

I

Este artigo apresenta experiência da Fundação Vanzolini na avaliação MPS.BR Nível G de maturidade de uma empresa na região Nordeste do Brasil. Além disso, descreve as etapas, resumo das atividades realizadas, os desafios e as lições aprendidas.

Para que serve? Este artigo serve para apresentar a experiência da IA Vanzolini em sua primeira avaliação oficial MPS. BR e pode servir como apoio ao planejamento de avaliações oficiais MPS.BR. Atualmente, a IA já possui outras avaliações realizadas e outras avaliações estão planejadas.

Em que situação o tema é útil? Este tema é útil para profissionais e organizações interessadas em avaliações oficiais MPS.BR e que desejam identificar questões importantes para um melhor planejamento e realização destas avaliações.

niciado em 1998, o relacionamento entre o ITS - Instituto de Tecnologia de Software e a Fundação Carlos Alberto Vanzolini teve como foco inicial a certificação de empresas na

ISO 9000:1994. Com o credenciamento das duas entidades em São Paulo como Implementadoras MPS.BR, a afinidade e a possibilidade de trabalharem em conjunto levaram-nas a firmarem um

Edição 23 - Engenharia de Software Magazine

5


convênio de cooperação, denominado ComQualidade Compromisso com a qualidade de software e serviços. O convênio, firmado em abril de 2006, tem como meta o desenvolvimento da qualidade em software e serviços. Para materializar esses compromissos, foi criado o Programa ComQualidade MPS.BR, com a finalidade de implementar o modelo MPS.BR em grupos de empresas e em projetos específicos para cada empresa. A motivação para a realização deste Programa veio do Comunicado SOFTEX MPS 20/2005, através do qual a SOFTEX - Associação para Promoção da Excelência do Software Brasileiro, em associação com o BID – Banco Interamericano de Desenvolvimento, apresentam regras para aporte de recursos financeiros para implementação MPS.BR em grupo de empresas. A Instituição Avaliadora Fundação Carlos Alberto Vanzolini também foi criada dentro do espírito do Convênio ComQualidade. Tem como avaliadora líder Sarah Kohan, da Fundação Vanzolini, e avaliador adjunto David Yoshida, do ITS. Foi autorizada pela Softex em 31 de agosto de 2007.

A primeira avaliação A primeira avaliação da IA Vanzolini teve início através de contato com a empresa a partir de indicação de uma Instituição Implementadora, que realizou um trabalho inicial com a organização. A partir deste contato, em março de 2008, iniciou-se o planejamento para a avaliação MPS. BR nível G de maturidade.

Visão geral da empresa A unidade organizacional que foi avaliada foi a Fábrica de Software da empresa. A organização, para reduzir seus custos, teve implementação realizada através sua própria equipe de processos, que se preparou para realizar as adaptações necessárias ao seu processo de desenvolvimento. Após a conclusão dos trabalhos, uma Instituição Implementadora foi contratada para realizar um Gap Analysis, de forma a garantir a aderência dos processos aos resultados de nível G do MPS.BR. O processo de desenvolvimento da organização é identificado com uma sigla interna neste trabalho nominada PPDS: Processo Padrão de Desenvolvimento de Software e tem suporte de uma ferramenta desenvolvida internamente para automatizar algumas tarefas do processo de gerenciamento de projetos.

O planejamento da avaliação O planejamento das avaliações inicial e da avaliação final seguiram, sem problemas, os passos previstos na Guia de Avaliação MPS.BR v1.1. A avaliação inicial foi realizada em abril e a final ocorreu em maio de 2008, conforme as datas acordadas nos contatos iniciais. Durante o planejamento não foram encontradas dificuldades no entendimento sobre a unidade organizacional a ser avaliada.

6

Em função da grande distância, organização sediada no Nordeste, em relação à localização da IA Vanzolini, São Paulo, um cuidado maior em relação às datas foi tomado, para evitar replanejamentos que implicassem em custos adicionais à empresa.

Conduzindo a avaliação As realizações das avaliações iniciais e finais na organização transcorreram dentro das expectativas dos avaliadores. A planilha de indicadores foi bem preenchida considerando que a organização preparou-se para todos os passos com pouco apoio de entidades externas. Todos os pontos levantados no Relatório da Avaliação Inicial foram atendidos, incluindo as melhorias apontadas. As solicitações da Organização para a avaliadora líder, no sentido de atender às questões colocadas no relatório foram muito pontuais. Participaram da avaliação inicial a representante da organização na equipe, o coordenador local e o patrocinador. Praticamente todas as adequações necessárias foram entendidas pelas pessoas presentes na avaliação inicial e a necessidade de suporte da avaliadora líder entre a avaliação inicial e a final foi muito pequena. A preocupação dos avaliadores foi manter um bom nível de relacionamento com os envolvidos, procurando evitar que um eventual estresse pudesse contribuir negativamente nos resultados. Durante a realização das avaliações foi possível constatar a importância das orientações passadas pelos avaliadores aos coordenadores e patrocinador da empresa, prévias à realização das avaliações. Neste aspecto, o total esclarecimento de dúvidas apresentadas foi fundamental. Detalhes sobre a disponibilidade de infra-estrutura, acesso aos documentos, ambiente nos computadores foram alguns dos esclarecimentos que tiveram grande influência sobre tranqüilidade na realização da avaliação. Na avaliação final, o planejamento das entrevistas também ocorreu sem problemas. Todos os entrevistados compareceram nos horários marcados e o coordenador local exerceu com competência e presteza. Neste aspecto, a empresa estava bem preparada. A organização preparou toda a logística necessária para a realização das atividades presenciais e atendeu prontamente a todas as solicitações da equipe avaliadora. Durante todo o processo de avaliação, desde o primeiro contato inicial por e-mail e por telefone até a apresentação dos resultados, o clima entre a equipe avaliadora e a equipe da Organização foi excelente.

Boas práticas da IA Vanzolini Para a otimização dos trabalhos da IA Vanzolini, alguns documentos foram padronizados para facilitar a realização das atividades, tais como templates de propostas de avaliação e listas de verificação.

Engenharia de Software Magazine - Experiências Práticas na Avaliação MPS.BR


processo

• [MA-MPS] Associação para Promoção da Excelência do Software Brasileiro – SOFTEX. MPS.BR Guia de Avaliação, v 1.0 2006. Disponível em www.softex.br • [MR-MPS] Associação para Promoção da Excelência do Software Brasileiro • SOFTEX. MPS.BR - Guia Geral, v 1.1 2006. Disponível em www.softex.br

Dê seu feedback sobre esta edição! A Engenharia de Software Magazine tem que ser feita ao seu gosto. Para isso, precisamos saber o que você, leitor, acha da revista! Dê seu voto sobre este artigo, através do link:

Feedback eu

www.devmedia.com.br/esmag/feedback

Lições Aprendidas Até o momento, pode-se destacar como lição aprendida da IA Vanzolini a manutenção de listas de verificação de apoio para cada etapa do processo, principalmente no que diz respeito à documentação exigida é muito importante. As listas de verificação foram fundamentais para que a documentação atendesse aos requisitos do Guia de Avaliação com rapidez, principalmente na avaliação final, onde há riscos dos patrocinadores dispersarem-se após a apresentação dos resultados da avaliação.

Conclusão Este documento apresentou a experiência da IA-Vanzolini como Instituição Avaliadora MPS.BR. O ótimo alinhamento entre o avaliador líder e o avaliador adjunto, apesar de serem de instituições diferentes, foi fundamental para o sucesso na realização da avaliação. As lições aprendidas durante a avaliação MPS.BR nesta Organização serviram como fonte para melhorias para os avaliadores da Vanzolini. Estas melhorias visam aumentar a eficiência da equipe, mantendo a qualidade do trabalho realizado.

Edição 23 - Engenharia de Software Magazine

7

sobre e s

O fato da avaliação nesta organização no Nordeste ter sido a primeira da IA Vanzolini, a principal preocupação foi em atender aos detalhes do processo de avaliação descritos no Guia de Avaliação. Apesar da experiência de seus avaliadores, houve um cuidado na elaboração de listas de verificação de apoio, para que nenhum detalhe em relação ao processo de avaliação fosse esquecido. Outra questão que levou a equipe de avaliadores a uma maior atenção é o fato da implementação na organização ter sido feita sem apoio de Instituição Implementadora. Para minimizar o risco de insucesso, o tempo planejado para a avaliação inicial foi de mais de oito horas trabalho e da avaliação final foi de quatorze horas.

Referências

Dê s

Desafios encontrados na avaliação

Como próximos passos, a equipe da IA Vanzolini irá trabalhar na incorporação das melhorias em sua estratégia de avaliação, que deve ser aplicada em novos trabalhos.

edição ta

O estabelecimento de um controle básico de gerencia de configuração destes documentos visa a utilização adequada destes documentos, principalmente pelo fato do avaliador adjunto ser de outra instituição. Com a utilização destas boas práticas, espera-se evitar equívocos e esquecimentos durante todo o processo de negociação da avaliação entre a IA e a empresa, bem como durante o processo de avaliação propriamente dito.


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

Scrum na Melhoria do Gerenciamento de Projetos de Software Um estudo sobre a implantação de Scrum para otimizar o processo de gerenciamento de projetos de software De que se trata o artigo? Neste artigo veremos os principais problemas associados ao planejamento e à gestão de projetos de software. Em seguida, mostraremos como os planos são tratados por Metodologias Ágeis de desenvolvimento de software.

Para que serve? O planejamento e o desenvolvimento de um software sob o paradigma ágil oferecem mais flexibilidade do que os modelos tradicionais para a condução de projetos de software que possuem incerteza ou instabilidade.

A Renata de Souza Alves Paula renatasapaula@gmail.com

Bacharel em Sistemas de Informação pela Universidade Estadual de Goiás, Anápolis, Goiás, e Pós-Graduada em Tecnologia da Informação e Negócios Eletrônicos pela Universidade Salgado de Oliveira, Goiânia, Goiás. Atualmente atua como analista de sistemas no Instituto Federal de Educação, Ciência e Tecnologia de Goiás.

8

tualmente, devido à alta complexidade inerente ao desenvolvimento de software, os processos definidos fornecem um nível de flexibilidade menos adequado para que se obtenha alta produtividade e qualidade no produto final com as atuais práticas de engenharia. Muitos dos processos definidos existentes e voltados para esta finalidade, como o Rational Unified Process (RUP) da IBM (Rational), nem sempre garantem o sucesso do projeto. Tais processos de desenvolvimento de software estabelecem quais as

Engenharia de Software Magazine - Scrum na Melhoria do Gerenciamento de Projetos de Software

Em que situação o tema é útil? Além de ser um modelo que permite a criação de planos flexíveis, as técnicas ágeis evitam desperdícios de tempo e esforço, pois focam em alcançar rapidamente meios de validar as características do produto em desenvolvimento e de avaliar a evolução do projeto.

atividades necessárias para que o produto seja construído de forma repetível (CRUZ, 2008). Os processos empíricos devem ser utilizados sempre que os processos definidos não forem adequados devido à complexidade do projeto. Ou seja,


metodologias ágeis

sempre que não se conheçam todas as variáveis de entrada para que possa estabelecer um processo repetível com a mesma saída (CRUZ, 2008). O mercado de Tecnologia da Informação (TI) está cada vez mais competitivo, onde a rapidez na entrega de sistemas com qualidade, planejamento adaptativo, flexibilidade e rápida resposta às mudanças torna-se cada vez mais desejada. Diante desse contexto, surgiu um novo conceito de metodologia ágil na gestão de projetos de sistemas, o Scrum. Uma alternativa possível nesta situação é a adoção de um processo que seja flexível o bastante para acomodar as alterações necessárias exigidas durante o desenvolvimento do produto, e que seja baseado em inspeção e adaptação. Quanto mais próximo do limite do caos a equipe conseguir trabalhar, porém mantendo a ordem, mais competitivo e útil será o produto resultante [CRUZ (2008), MARTINS (2007), p. 252]. O Scrum é uma metodologia ágil para gerência de projetos, baseado em inspeção e adaptação, iterativo e incremental, e pode ser aplicado a qualquer produto ou no gerenciamento de qualquer atividade complexa. Cada iteração de trinta dias conhecida como Sprint produz um conjunto de funcionalidades (BISSI, 2007).  Além de estudar uma metodologia que se encaixa em uma categoria já  conhecida pelo mercado de TI, chamada agile development, iremos também inferir sobre as vantagens de se utilizar tal metodologia em relação a outros processos tradicionais e avaliar a aceitação do Scrum no mercado atual, identificando algumas empresas que já obtiveram sucesso com o seu uso. O artigo está organizado da seguinte maneiro: primeiramente trataremos da pesquisa bibliográfica realizada sobre o tema, a discussão do histórico, ciclo de vida do processo do Scrum, seus principais artefatos, os papéis desempenhados pela equipe e a sua aceitação no mercado atual. Em seguida, apresentaremos uma avaliação da utilização do Scrum para a melhoria no gerenciamento de projetos de software, os resultados alcançados e as conclusões deste artigo.

Retrospecto do Scrum Diversas metodologias foram criadas para sistematizar o desenvolvimento de software. Tais metodologias podem ser divididas em tradicionais, que enfatizam a documentação de cada processo do desenvolvimento de software, ou ágeis, que consideram um novo paradigma de desenvolvimento de software. As metodologias tradicionais surgiram quando os mainframes ainda reinavam e não existiam ferramentas de apoio ao desenvolvimento, o custo de realizar algum tipo de alteração era altíssimo e a documentação tinha de ser muito mais forte. Elas estabelecem uma sequência de etapas, onde cada etapa tem um início e um fim definidos com documentação rígida a ser seguida entre uma etapa e outra, de forma que sem a documentação o processo não avança (FERSTE, 2009). Percebeu-se que os modelos tradicionais ocultavam uma série de problemas sérios, como:

• Problema para entrega dentro do prazo considerando o escopo de todas as funcionalidades solicitadas [Standish Group, 1995]; • Grande número de erros dado que a metodologia tradicional dificulta a execução de alterações durante o processo de desenvolvimento; • Um artigo famoso da época: “No Silver Bullet”, de Brooks [1987], demonstrou que a ideia de especificar totalmente o software antes de seu início é totalmente impossível. São considerados processos tradicionais, ou pesados, de desenvolvimento de software, aqueles que tentam prever todos os requisitos do sistema para assim ser feito um planejamento prévio de como o sistema irá atuar. Este planejamento rigoroso é representado como documentos que guiarão todo o processo de desenvolvimento (ROCHA; OLIVEIRA; VASCONSELOS, 2004). Os processos tradicionais se caracterizam por focar a análise de sistemas, investindo esforços para a obtenção de artefatos de projeto tão completos e precisos quanto possível: relatórios, documentos e diagramas. Grande parte dos processos tradicionais em uso atualmente tem como base os modelos de diagramas da Unified Modeling Language (UML), como é o caso do RUP (GALDINO, 2006). Os processos ágeis surgiram como uma alternativa aos processos tradicionais. Tais projetos partem da premissa de que se devem permitir mudanças nos requisitos a qualquer tempo. Desta forma, o planejamento é feito durante todo o processo, ao mesmo tempo em que é feita a codificação: não há um passo dedicado exclusivamente ao planejamento (ROCHA; OLIVEIRA; VASCONSELOS, 2004). Em fevereiro de 2001 Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland e Dave Thomas, reuniram-se em Wasatch Range nos Estados Unidos para discutir melhores maneiras de desenvolver software. Esse encontro deu origem ao manifesto ágil, uma declaração com princípios que regem o desenvolvimento ágil: “Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê-lo. Através desse trabalho, passamos a valorizar: • Indivíduos e interação entre eles mais que processos e ferramentas; • Software em funcionamento mais que documentação abrangente; • Colaboração com o cliente mais que negociação de contratos; • Responder a mudanças mais que seguir um plano; Ou seja, mesmo havendo valor nos itens à direita, valorizase mais os itens à esquerda.” [TELES, 2008; SANTOS, 2009; GOMES, 2009; CORDEIRO, 2006]. A metodologia ágil é muito adequada para situações em que a mudança de requisitos é frequente, ou seja, para ser ágil, a

Edição 23 - Engenharia de Software Magazine

9


metodologia deve aceitar a mudança em vez de tentar prever o futuro. O Scrum é uma das metodologias que se encaixa nestes conceitos e será explicado nos próximos parágrafos. O Scrum, assim como o Extreme Programming (XP), são classificados como métodos ágeis de desenvolvimento de software. Como colocado por TELES (2008), este novo conceito de metodologia surgiu nos Estados Unidos na década de 90, na tentativa de criar sistemas em tempo menor, de melhor qualidade e produzidos de forma mais econômica que o habitual. Esses objetivos são alcançados através de um conjunto de valores, princípios e práticas que diferem essencialmente da forma tradicional de se desenvolver software. Para CORDEIRO (2006), os métodos ágeis focam em simplicidade, software funcional no início das iterações, flexibilidade e intensa comunicação tanto internamente quanto com clientes. Além disso, aplicam desenvolvimento iterativo e incremental, planejamento adaptativo, flexibilidade e rápida resposta a mudanças. O termo Scrum foi utilizado pela primeira vez aplicado no contexto de processo de desenvolvimento por Ikujiro Nonaka e Hirotaka Takeuchi em um artigo chamado The New Product Development Game, em português, “O jogo do desenvolvimento de novos produtos” publicado em Harvard Business Review em 1986. Posteriormente foi elaborado novamente em The Knowledge Creating Company (Oxford University Press, 1995) pelos mesmos autores (SCHWABER, 2006). O artigo que sumariza as 10 melhores práticas em empresas japonesas escrito por Takeuchi e Nonata introduziu o termo Scrum para referir-se às reuniões de equipes que praticam a autodireção e a adaptabilidade. Jeff Sutherland é um dos criadores do Scrum e era vice-presidente da Easel Corporation em 1994, quando introduziu algumas das práticas do Scrum com base neste artigo. Ele também foi influenciado por um relatório de projeto com produtividade acima da média, na Borland Corporation, e esta juntamente com outras empresas introduziu a reunião diária. Em 1995 Ken Schwaber trabalhou com Sutherland na Easel e juntos formalizaram o Scrum. Este termo é o nome usado para a reunião de jogadores, no jogo do Rugby, quando eles se organizam em círculo para planejar a próxima jogada. É uma forma de mostrar que o projeto deve ser conduzido em pequenos ciclos, mas com uma visão de longo prazo, que é ganhar o jogo (MARTINS, 2007, p.252). Scrum é um processo bastante leve para gerenciar e controlar projetos de desenvolvimento de software e para criação de projetos de produtos. O Scrum segue as filosofias iterativa e incremental, ele se concentra no que é realmente importante: gerenciar o projeto e criar um produto que acrescente valor para o negócio. O valor decorre da funcionalidade propriamente dita, do prazo em que ela é necessária, do custo e da qualidade (MARTINS, 2007, p. 253). Sua abordagem é oposta a do modelo em cascata. Inicia-se a análise assim que alguns requisitos estiverem disponíveis, depois que alguma análise tiver sido feita, começam os trabalhos de projeto técnico (design), e assim por diante. Em outras palavras, o projeto trabalha em pequenos ciclos de cada vez

10

(Sprints) até a conclusão do projeto final. Esta abordagem pode ser chamada de iterativa, e cada iteração consiste na captura de requisitos, um pouco de análise, um pouco de design e mais alguma programação e testes, culminando num ciclo iterativo com várias entregas (MARTINS, 2007, p. 253).

Ciclo do Processo do Scrum Como o Scrum é uma metodologia ágil e todo o trabalho é dividido em iterações, cada uma delas é chamada de Sprint. O Sprint representa um ciclo, ele pode durar de duas a quatro semanas, mas é tipicamente mensal, pois 30 dias fornecem uma melhor visibilidade dos objetivos do projeto e comprometimento da equipe. No final de cada Sprint deve-se ter uma parte do produto concluída que possa ser apresentada ao cliente. Estas entregas parciais vão sendo implementadas até o produto final estar concluído, e à medida que forem surgindo novas funcionalidades desejadas, novos Sprints vão sendo realizados. A Figura 1 demonstra o processo completo do ciclo de uma Sprint e pode ser acompanhada para auxiliar no entendimento. Um projeto Scrum começa mesmo que ainda se tenha uma visão superficial no princípio, talvez expressa em termos de marketing ou uma visão técnica, mas que se esclarece melhor à medida que o projeto evolui. A partir dessa visão inicial se elabora uma lista enxuta dos principais itens, de tudo o que se deseja para o software, contendo funcionalidades e requisitos que precisarão ser desenvolvidos até a finalização do projeto. Esta lista de itens é conhecida como Product Backlog ou “Backlog do Produto”. Cada item tem uma prioridade de entrega que indica o quanto de valor ele gera para o negócio. Esta lista não precisa estar completa logo no começo, ela pode ganhar outros itens no decorrer do projeto.

Figura 1. Ciclo de vida de uma Sprint (Fonte: Adaptado de VICENTE, 2008)

No início de cada Sprint (iteração) a equipe seleciona os itens do Product Backlog, de acordo com as suas prioridades e o tempo que será gasto para completar as suas funcionalidades. Esta nova lista é conhecida como Sprint Backlog. É importante que a equipe identifique os itens e tamanho do Sprint Backlog, porque ela estará comprometida a finalizar tais tarefas. Os seus membros são quem deverão escolher com o que irão se comprometer. Nesse momento as tarefas maiores são subdivididas em partes menores.

Engenharia de Software Magazine - Scrum na Melhoria do Gerenciamento de Projetos de Software


metodologias ágeis

Como descrito em CISNEIROS (2009), logo após o Sprint Backlog estar concluído, o total de horas trabalhadas é comparado com o total previsto anteriormente no Product Backlog. Caso haja uma diferença significativa, a equipe Scrum deve negociar novamente com o cliente o número correto de horas, para que o Sprint seja realizado com maior probabilidade de sucesso. Em MITTELBACH; SILVA; ARAUJO (2006), os autores subdividem cada Sprint nas seguintes atividades: • Scrum Planning Meeting: É o início de uma Sprint, onde o Product Owner (representante do cliente ou o próprio cliente) tem a oportunidade de atualizar a priorização dos itens do Product Backlog e definir juntamente com a equipe um Product Increment (uma parte do produto) a ser entregue ao cliente ao final do Sprint. Esta reunião é realizada com a presença do Product Owner, Scrum Master (líder facilitador do projeto), de todo Scrum Team (equipe), e quaisquer interessados, diretores ou representantes do cliente. Durante a reunião o Product Owner explica as funcionalidades de maior prioridade para o Scrum Team, e este faz as perguntas que sejam suficientes para que eles possam, depois da reunião, definir quais atividades eles irão mover do Product Backlog para o Sprint Backlog. Depois da reunião Sprint Planning, o Scrum Team reúne-se separadamente para discutir o que foi dito e decidir o quanto eles se comprometem a fazer durante o próximo Sprint. Em alguns casos, haverá negociações com o Product Owner, mas será sempre prerrogativa do Scrum Team determinar o quanto eles podem se comprometer; • Daily Scrum Meeting: É um encontro diário realizado pela equipe e o Scrum Master onde os membros discutem aquilo em que trabalharam, no que irão trabalhar e possíveis impedimentos que estejam atrapalhando o progresso do trabalho. Esta reunião é uma maneira eficiente de manter os membros cientes dos objetivos e impedir que o projeto “saia do rumo”. São tipicamente rápidas e objetivas, realizadas em pé, preferencialmente pela manhã, duram de 15 a 30 minutos, para evitar perder o foco do que está sendo desenvolvido e possíveis divergências de assuntos. Elas não representam uma forma de cobrança vinda de um gerente de projetos, mas é uma maneira de sincronizar a equipe às tarefas e relatar os impedimentos que podem estar interferindo no bom andamento do Sprint. Nas reuniões diárias, os únicos autorizados a falar são o Scrum Master e a equipe envolvida. Os demais participantes devem apenas ouvir, se falarem algo devem ser convidados a se retirar da reunião, pois podem querer mudar o rumo do projeto, tentando priorizar itens que são importantes para eles e não para o projeto ou seu objetivo imediato. O Scrum Master é o responsável por manter a ordem nessa reunião, dar a palavra a um membro por vez, evitar desvio de foco do assunto e conversas paralelas (MARTINS, 2007, p. 274). • Criação do Product Increment: A finalização das funcionalidades definidas para um determinado Sprint marca a realização de um Product Increment. Os membros da equipe trabalham de maneira colaborativa de forma a realizar todas as metas definidas para aquele Sprint;

• Sprint Review: Ocorre no final de cada Sprint, neste momento a equipe exibe o Product Increment, potencialmente utilizável que foi construído, ao Product Owner, que é responsável por validar e/ou solicitar ajustes para que o projeto se torne adequado aos anseios do cliente. Os participantes desta reunião incluem tipicamente: o Product Owner, o Scrum Team, o Scrum Master, a diretoria, clientes e engenheiros de outros projetos. O ideal é que a equipe tenha concluído todos os itens do Product Backlog alocados para o Sprint. Segundo MARTINS (2007, p. 276) é uma reunião informal de quatro horas de duração, que ajuda a equipe de forma colaborativa, a obter um feedback e determinar quais os objetivos da próxima iteração, assim como a qualidade e as capacidades das funcionalidades produzidas. Ao final da apresentação das funcionalidades desenvolvidas, os stakeholders são questionados, um a um, quanto às suas impressões, mudanças necessárias e alterações de prioridades. Possíveis rearranjos nos itens do Product Backlog ou funcionalidades que não foram entregues como esperado podem ser incluídas no próximo Sprint; • Sprint Retrospective: Após a reunião de revisão do Sprint, o Scrum Master faz uma reunião de retrospectiva com a equipe. Esta objetiva identificar os pontos positivos e negativos do Sprint que entregou o último Product Increment e busca corrigir os problemas encontrados com o propósito de aperfeiçoa-los. Nessa reunião é debatido o que funcionou na Sprint, o que precisa ser melhorado e quais ações devem ser tomadas para colocar as melhorias em prática. Geralmente o Sprint Retrospective tem de três a quatro horas de duração (AGUIAR, 2008). • Atualização do Product Backlog: O Product Owner é responsável por re-priorizar toda lista de itens do Product Backlog para que um próximo Sprint possa ser iniciado de acordo com os itens mais prioritários. Os principais artefatos produzidos no processo do Scrum são o Product Backlog, Sprint Backlog, Burndown Chart e o TaskBoard. Eles serão exemplificados nas Tabelas 1, 2 e 3 e nas Figuras 2 e 3. Para melhor exemplificar o ciclo do processo do Scrum, consideremos o exemplo citado em CISNEIROS (2009), sobre o desenvolvimento de um sistema web de streaming de vídeo para internet. O escopo do projeto em questão é: “Um sistema Web de streaming de vídeo, que permitirá aos usuários na Internet enviar seus vídeos, que serão armazenados no sistema e poderão ser gerenciados por seus donos e vistos pelo resto do mundo através das visitas ao site. O sistema terá como funcionalidades principais a conversão dos vídeos mandados para um codec leve que permite qualidade e rapidez na visualização pela Internet; cadastro de usuários; interface de gerenciamento de vídeos; comentários para os vídeos e usuários; notas para vídeos; sistema de busca; reconhecimento de sons dos vídeos; proteção contra SPAM; sistema de legenda de vídeos feitos por usuários; canais (grupos) de vídeos e usuários”. Com as funcionalidades levantadas, o Product Owner monta o Product Backlog com as prioridades definidas de acordo com o valor de importância para o cliente. Em nosso exemplo,

Edição 23 - Engenharia de Software Magazine

11


usaremos a notação de quanto maior o número de prioridade, menor prioridade ele tem (1 - prioridade máxima, 2 - prioridade menor, e assim por diante). A Tabela 1 demonstra a primeira versão feita do Product Backlog, enquanto a Tabela 2 apresenta o mesmo Product Backlog mais detalhado, com o custo-horas que cada tarefa irá ocupar.

Tabela 3. Sprint Backlog (Fonte: Adaptado de CISNEIROS, 2009)

Tabela 1. Product Backlog (Fonte: Adaptado de CISNEIROS, 2009)

Figura 2. Burndown Chart (Fonte: Adaptado de CISNEIROS, 2009)

Tabela 2. Product Backlog mais detalhado (Fonte: Adaptado de CISNEIROS, 2009)

Com o novo Product Backlog definido na Tabela 2, define-se quais serão as metas do primeiro Sprint: • Modelagem de dados; • Cadastro e gerenciamento de usuários; • Conversão de vídeo para visualização na Internet (Codec); • Cadastro e gerenciamento de vídeos pelos usuários. Sendo assim, o Scrum Master junto à equipe de desenvolvimento define o Sprint Backlog da Tabela 3, subdividindo as tarefas maiores em menores. O Burndown Chart é o gráfico de andamento do Sprint, relacionando horas e data em relação ao restante de tempo hábil para o término do ciclo (VICENTE, 2008). Com o Burndown Chart podemos ver claramente o andamento do projeto ao longo do seu ciclo de desenvolvimento (Sprint). Também, no meio do projeto, podemos calcular facilmente a velocidade com que o projeto está andando e assim estimar uma data para que o Sprint seja concluído. Observe a Figura 2.

12

Este dado estimativo pode ser comparado com o prazo que o Scrum Master definiu para que possamos saber se o projeto vai acabar ou não no prazo. Por exemplo, calculamos que a velocidade do projeto está como 8 horas por dia em média. Isso significa que o projeto irá terminar no dia 24, como o Burndown Chart mostrou. Se o prazo fosse, por exemplo, para o dia 19, logo nos cinco primeiros dias já poderíamos ter calculado essa velocidade e ver que estava pouco, tomando providências para que essa velocidade se tornasse, por exemplo, 10 horas por dia em média, assim no dia 19 o projeto estaria pronto. Este é um dos mais importantes trabalhos que o Scrum Master terá que fazer e o Burndown Chart é o indicador perfeito para ele gerenciar o tempo de projeto e sua equipe de desenvolvimento (CISNEIROS, 2009). O taskboard (Figura 3) é um grande painel onde podem ser colocadas várias informações importantes para o acompanhamento do Sprint. O Sprint Backlog, ou seja, as atividades não iniciadas, as que estão em andamento e as concluídas ficam sempre visíveis e disponíveis para todos os interessados no projeto. Algumas características do taskboard são: • Normalmente é desenhado em uma parede e as atividades são descritas em post-its; • Apresenta uma visão geral do Sprint; • Fica acessível a todos os interessados no projeto (KNIBERG, 2007).

Engenharia de Software Magazine - Scrum na Melhoria do Gerenciamento de Projetos de Software


metodologias ágeis

Figura 3. TaskBoard (Fonte: Adaptado KNIBERG, 2007)

Papéis da equipe no Scrum O Scrum trabalha basicamente com três papéis: o Product Owner, o Scrum Master e a equipe do projeto, também chamada de Scrum Team. O Product Owner é o responsável pela visão de negócios e por representar os interesses das pessoas que apostam no projeto, provavelmente será um gerente de projeto, ou um patrocinador do projeto, um membro da equipe de marketing ou um cliente interno. É ele quem define e prioriza o Product Backlog e consegue a verba. Geralmente é o papel desempenhado pelo cliente (MARTINS, 2007, p. 255). Suas principais responsabilidades são: • Definir as funcionalidades do produto; • Concentrar as informações vindas de usuários, stakeholders ou do mercado de maneira que se obtenha uma visão única dos requisitos do sistema; • Sua maior responsabilidade é o Return on Investment (ROI) do projeto; • Priorizar o Product Backlog; • Decidir sobre a data de término; • Ajustar recursos e priorizar tarefas a cada Sprint, como necessário; • Aceitar ou rejeitar os resultados dos trabalhos. O Scrum Master é uma mistura de gerente de projeto, facilitador e mediador. Ele é um líder e não somente um gerente, está sempre em contato com o Product Owner (SANCHEZ, 2007). Entre as suas principais responsabilidades, temos: • Assegurar que a equipe de desenvolvimento funcione plenamente e seja produtiva; • Ajudar na cooperação entre todas as funções e papéis do time; • Remover obstáculos da equipe e assegurar que as práticas de Scrum estão sendo executadas com eficiência pelas pessoas envolvidas. Alguns obstáculos podem ser resolvidos pelo time, outros podem ser resolvidos através de vários times, e outros podem precisar de envolvimento da gerência, pois podem ser problemas relacionados à empresa que bloqueiam qualquer membro do time a fazer qualquer coisa.

Como exemplo deste tipo de impedimento externo, temos as questões judiciais; • Proteger a equipe de interferências externas; • Assegurar-se de que a metodologia está sendo seguida, incluindo chamadas para reuniões diárias (Daily Scrum Meeting), revisões de atividade (Sprint Reviews) e reuniões de planejamento das atividades (Sprint Planning); • Identificar quais atividades foram concluídas, quais foram iniciadas, quaisquer novas tarefas que foram descobertas e qualquer estimativa que possa ter mudado. Isto permite a ele atualizar sempre o Burndown Chart, que permite mostrar quanto trabalho falta para um Sprint acabar, dia por dia. Ele também tem que sempre olhar cuidadosamente para o número de tarefas em aberto. Estes trabalhos em aberto devem ser minimizados o máximo possível para garantir um trabalho sempre limpo e eficiente; • O Scrum Master deve perceber e resolver problemas pessoais ou conflitos entre os integrantes do time. Este tipo de problema deve ser resolvido por diálogo com o time, ou então o Scrum Master terá que ter ajuda da gerência ou do departamento de Recursos Humanos. Alguns estudos apontam que 50% dos problemas de desenvolvimento acontecem por razões pessoais. O Scrum Master precisa estar sempre atento ao time para fazer dele totalmente funcional e produtivo [LIMA, 2008; CISNEIROS, 2009; AGUIAR, 2008; VICENTE, 2008; SANTOS, 2009]. Por último, a equipe do projeto ou Scrum Team é o grupo de pessoas responsáveis por desenvolver ou construir as funcionalidades do produto. Algumas características das equipes de desenvolvimento são: • São autoger e nc i ada s, auto - orga n i z ada s e mu lt i­ funcionais; • São equipes pequenas, compostas por 5 a 10 membros (o recomendado são 7 pessoas). Podem ser compostas por desenvolvedores e participantes externos (marketing, vendas, clientes, etc.); • Demonstrar o resultado do Sprint para o Product Owner e outros Stakeholders; • Deve ter a capacidade e o conhecimento técnico sobre todo o processo de desenvolvimento do produto; • O time deve ter pessoas capazes de analisar a solução, codificá-la e testá-la sem necessitar de outros times ou outras pessoas; • Definem metas de cada Sprint, junto ao Scrum Master, e especificam seus resultados de trabalho; • Têm o direito de fazer tudo dentro dos limites das diretrizes do projeto para atingir a meta de cada Sprint; • Organizam os trabalhos para atingir os objetivos dos Sprints [LIMA, 2008; CISNEIROS, 2009; AGUIAR, 2008; VICENTE, 2008; SANTOS, 2009].

Aceitação do Scrum no mercado atual O mundo enfrenta uma das piores crises financeiras de sua história. O Fundo Monetário Internacional (FMI) divulgou

Edição 23 - Engenharia de Software Magazine

13


um relatório no ano de 2009, onde fez uma previsão de que a economia mundial encolheu 1,3%. Mesmo o Brasil, que fortaleceu sua economia e vem resistindo à recessão, também teve previsão de retração destes mesmos índices. Por consequência, os investimentos em tecnologia sofreram uma queda de 3 ou 4% em 2009, em previsões das consultorias Forrester e Gartner, respectivamente. Os gastos com programas de computador deverão permanecer praticamente estáveis, já que software é visto como algo que pode ajudar as empresas a economizarem, mas os investimentos em hardware e serviços de TI fecharão o ano em queda. O mercado de projetos vem se reconfigurando diante da crise. Os projetos de tecnologia, em particular, sofrem um forte impacto. Neste ambiente de incertezas e constantes mudanças, os atores do mercado de projetos já encontram racionalização do uso de recursos, acesso limitado a crédito, pressões por margens menores e problemas financeiros com grande parte dos clientes, tornando o processo decisório mais longo e gerando uma notável redução na demanda por projetos. Esta nova configuração exige que as organizações mudem sua forma de trabalhar para conseguirem sobreviver, se fazendo necessária uma verdadeira quebra de paradigma. Essa nova forma de trabalhar deverá: • Funcionar bem em ambientes que mudam rapidamente, permitindo replanejamento frequente; • Focar-se em maximizar o retorno do investimento (ROI) do cliente; • Ajudar a reduzir o tempo de entrada em produção ou o tempo de lançamento do produto no mercado; • Evitar desperdício de esforço e tempo com subprodutos e funcionalidades que nunca serão utilizados; • Sempre entregar valor para o cliente, mesmo que o projeto seja interrompido antes do seu final previsto; • Priorizar a comunicação e feedback entre as pessoas do projeto, para que todos saibam o que deve ser feito e o que está sendo feito. O Scrum é focado em lidar com todas estas questões, e se apresenta como uma das melhores opções para projetos em momentos de crise (SABBAGH; GARRIDO, 2009). SCHWABER (apud NETO, 2008, p. 10) afirma que apesar de o Scrum ser uma metodologia relativamente nova, a demanda por sua adoção tem crescido fortemente e o Scrum Master, por ser o responsável pelos objetivos do projeto e um dos principais atores na realização do Scrum, precisa conhecer profundamente suas técnicas e processos para que obtenha êxito em sua utilização. De acordo com a publicação de MARCH (2009), o Scrum está virando febre entre empresas brasileiras. O conceito que chegou ao Brasil há três anos e agora começa a chamar a atenção, inclusive de áreas além da computação. Algumas das empresas internacionais de grande porte que já utilizam o Scrum são: Microsoft, Yahoo, Google, Philips, Siemens, Nokia, BBC, Salesforce.com, Capital One, Oce, Sabre, John Deere, First American Real Estate, BMC Software, Oracle, Motorola, HP,

14

Coca-Cola, entre outras (COHN, 2002; BROD, 2008; FUSCO, 2008). Algumas empresas brasileiras que também já estão usando o Scrum são a Globo.com, UOL, Cemig, Tribunal de Justiça de Rondônia (TJRO), MicroPower, Crivo, Summus, Synchro, YMF, Infraero, Instituto Municipal de Tecnologia da Informação de Campo Grande e Venturus (YOSHIMA, 2009).

Uma avaliação da utilização do Scrum para a melhoria no gerenciamento de projetos de software Os processos de desenvolvimento de software definidos ou também chamados de tradicionais são às vezes fatores limitadores aos desenvolvedores. Muitas empresas não possuem recursos ou inclinação para processos pesados de produção de software, por isso muitas acabam por não usar nenhum processo, o que pode ocasionar efeitos desastrosos em termos de qualidade de software. Como alternativa a esse cenário, surgem as metodologias ágeis, que apesar de possuírem documentação, são mais flexíveis, orientadas a entregas e possuem uma maior iteratividade no processo de desenvolvimento e codificação do produto. Preocupam-se em gastar menos tempo com documentação e mais com a implementação. São adaptativas ao invés de serem preditivas, elas se adaptam a novos fatores decorrentes do desenvolvimento do projeto, ao invés de procurar analisar previamente tudo o que pode acontecer no decorrer do desenvolvimento. A maioria das metodologias ágeis nada possui de novo, o que as diferencia das metodologias tradicionais são o enfoque e os valores. A ideia das metodologias ágeis é o enfoque nas pessoas e não em processos ou algoritmos. Para ser considerada ágil a metodologia deve aceitar a mudança ao invés de tentar prever o futuro. Elas variam em termos de práticas e ênfases, mas compartilham algumas características, como desenvolvimento iterativo e incremental, comunicação e redução de produtos intermediários, como documentação extensiva. Dessa forma, existem maiores possibilidades de atender aos requisitos do cliente, que muitas vezes são mutáveis. As metodologias pesadas devem ser aplicadas apenas em situações em que os requisitos do software são estáveis e requisitos futuros são previsíveis. Estas situações são difíceis de serem atingidas, uma vez que os requisitos para o desenvolvimento de um software são mutáveis. Dentre os fatores responsáveis por alterações nos requisitos estão a dinâmica das organizações, as alterações nas leis e as mudanças pedidas pelos stakeholders, que geralmente têm dificuldades em definir o escopo do futuro software. Ao contrário do que alguns imaginam, as metodologias ágeis não rejeitam os processos e ferramentas, a documentação, a negociação de contratos ou o planejamento, mas simplesmente mostra que eles têm importância secundária quando comparado com as pessoas e interações, com o software estar executável, com a colaboração do cliente e as respostas rápidas a mudanças e alterações.

Engenharia de Software Magazine - Scrum na Melhoria do Gerenciamento de Projetos de Software


metodologias ágeis

É um equívoco entender que o Scrum não enfatiza o planejamento. O planejamento no seu contexto é dividido em vários Sprints. Se a tarefa for muito complexa, ela pode ser dividida em subtarefas que são então alocadas em dois ou mais Sprints, onde no primeiro faz-se o planejamento e no segundo acontece a execução. As características do projeto irão determinar entre o uso das abordagens tradicional ou ágil. Os projetos que têm como natureza a inovação tecnológica inviabilizam o uso da abordagem tradicional, pois o risco de ser necessário alterar um produto depois da conclusão de uma fase de seu ciclo de vida é alto. A abordagem ágil consegue uma adaptação mais fácil nesses casos de mudança. A abordagem tradicional é mais adequada para projetos que necessitam de um forte planejamento e muita disciplina no processo, mas ela não promove tão ampla comunicação entre os membros de equipes e seus gerentes. O Scrum como sendo uma das principais metodologias ágeis e foco deste artigo, tem como ideia principal que o desenvolvimento de softwares envolve muitas variáveis técnicas e do ambiente, como requisitos, recursos e tecnologia, que podem mudar durante o processo. Isto torna o processo de desenvolvimento imprevisível e complexo, requerendo flexibilidade para acompanhar as mudanças. O Scrum se encaixa muito bem principalmente para produtos com características mutáveis durante o projeto. Como existem projetos de natureza empírica que não funcionam corretamente com processos bem definidos, o Scrum entra como possível solução, sendo um processo definido para projetos empíricos com características muito dinâmicas. Um processso Scrum bem implementado poderá alcançar o efeito Toyota: quatro vezes mais produtividade e doze vezes mais qualidade. Um dos motivos principais no ganho de produtividade é que sua organização faz com que um Scrum funcional produza resultados de ótima qualidade de negócio na primeira vez, evitando que se façam componentes que nunca serão usados pelo usuário. Esse problema atinge muitas organizações que não implementam Scrum (SCHWABER, 2006). Outra vantagem de se utilizar o Scrum é a produtividade aliada ao conforto. Ele permite aos colaboradores desenvolverem software na medida em que reduzem a pressão de administração, pois oferece liberdade para que cada membro da equipe selecione seus próprios trabalhos e organizem entre si. Como toda metodologia ou processo, sempre existem vantagens e desvantagens advindas da sua adoção. Algumas das desvantagens observadas no Scrum são: • Não é fácil de ser implementada, principalmente devido a resistência de mudanças culturais; • Ausência de práticas de Engenharia de Software, pois é voltada para o gerenciamento do projeto e não para o desenvolvimento, podendo necessitar da associação de outras metodologias de Engenharia de Software simultaneamente; • Pode ser mais difícil de se aplicar em grandes equipes ou em equipes geograficamente distribuídas;

• A documentação do software pode acabar sendo desprezada, tornando insuficiente quando forem necessárias manutenções futuras; • Sensação de informalidade, pois a documentação formal do escopo do software só é criada caso os envolvidos considerem necessário. Todavia, diante de tantas vantagens já discutidas nos parágrafos anteriores, o Scrum ainda se mostra como uma opção capaz de driblar vários problemas atuais no gerenciamento de projetos de software. Os principais benefícios obtidos com a prática do Scrum na intenção de obter uma melhoria nos processos de gerenciamento de software, podem ser assim resumidos: • Melhor adaptação no gerenciamento de projetos com constantes mudanças, pois a grande maioria dos projetos se inicia sem total detalhamento e sempre existem alterações nos requisitos ao longo do desenvolvimento; • Encoraja a comunicação entre os membros da equipe e o espírito colaborativo. As chances de sucesso em projeto são muito maiores em times onde há uma boa comunicação, onde há entendimento e cooperação mútua; • Por ser iterativo e incremental, permite a entrega antecipada de uma parte funcional do software ao cliente, que já poderá validar se está conforme o esperado. Caso não esteja, a equipe não perderá o mesmo tempo que perderia se esse feedback só fosse feito após a conclusão do software. Além de impedir que se implemente funcionalides que nunca serão utilizadas pelo cliente; • A entrega do software utilizando Scrum é mais rápida do que se utilizasse alguma outra metodologia tradicional, uma vez que a codificação já se inicia logo nos primeiros Sprints, e não se espera ter antes uma extensa documentação do software; • A qualidade no software utilizando Scrum é promovida pelos seguintes fatores: as iterações, a remoção de impedimentos, inspeção e adaptação, times multifuncionais e autonomia da equipe, o que significa menos pressão sobre cada membro; • O Scrum traz um ROI mais rápido, pois minimiza a burocracia dos processos e se aproxima do cliente. Este está sempre envolvido, participando da demonstração do software ao final de cada Sprint, oferecendo feedback e atento às mudanças e suas consequências.

Resultados As metodologias ágeis mesmo não tendo muito tempo de existência, já apresentam resultados efetivos. CHARETTE (apud SOARES, p.6) cita um exemplo interessante comparando as metodologias ágeis e tradicionais: um estudo mostrou que os projetos usando os métodos ágeis obtiveram melhores resultados em termos de cumprimento de prazos, de custos e padrões de qualidade. Além disso, o mesmo estudo mostra que o tamanho dos projetos e das equipes que utilizam as metodologias ágeis têm crescido. Apesar

Edição 23 - Engenharia de Software Magazine

15


16

Dê seu feedback sobre esta edição! A Engenharia de Software Magazine tem que ser feita ao seu gosto. Para isso, precisamos saber o que você, leitor, acha da revista! Dê seu voto sobre este artigo, através do link: www.devmedia.com.br/esmag/feedback

Engenharia de Software Magazine - Scrum na Melhoria do Gerenciamento de Projetos de Software

Feedback eu sobre e s

O mercado de software tem crescido a cada dia e junto com ele crescem também as exigências quanto à complexidade, custos, prazos e qualidade dos sistemas, sendo todas estas questões cruciais e de difícil gerenciamento. No contexto da Tecnologia da Informação, principalmente quando se trata de processos de desenvolvimento de sistemas, a dinamicidade sempre se faz presente, o que explica o surgimento de metodologias de desenvolvimento ágil com a finalidade de atender as necessidades atuais do mercado de software e proporcionar maiores vantagens em relações às metodologias tradicionais. O Scrum é uma metodologia ágil para gerência de projetos baseado em inspeção e adaptação, iterativo e incremental, e

Dê s

Conclusão

pode ser aplicado a qualquer produto ou no gerenciamento de qualquer atividade complexa. O processo do Scrum como uma metodologia ágil e ciente das questões críticas relativas a software estabelece algumas alternativas na tentativa de driblar os problemas existentes no desenvolvimento de software. As metodologias ágeis têm ganhado espaço ultimamente, e várias empresas já estão experimentando ou se mostrando interessadas em experimentar esta mais recente abordagem de desenvolvimento de software. Esse interesse nasce da tentativa de aperfeiçoar os processos, aumentar a qualidade dos produtos finais e a satisfação dos clientes. A aceitação do Scrum no mercado de software tende a crescer, pois além de ser uma metodologia recente, ela está inserida no contexto atual de crise mundial que afeta também o mercado do software. Em tempos de crise, o Scrum desponta como uma boa alternativa para reduzir gastos, enfrentar as exigências e complexidade dos softwares e a competitividade das empresas. Uma vez superado estes tempos de crise mundial, as organizações que tiverem adotado Scrum estarão mais próximas do cliente, enxutas, focadas em resultado, objetivas e transparentes. Assim, no momento da recuperação do mercado, estas organizações largarão à frente de sua concorrência. Várias empresas de grande porte, tanto internacionais como nacionais obtiveram sucesso com o uso do Scrum. Um dos casos de sucesso mais conhecido por esta implantação no Brasil é o da Globo.com. O processo que compreende as fases do ciclo de vida do Scrum mostrou que a metodologia consegue ser iterativa, incremental, adaptativa a mudanças e ao mesmo tempo completa em cada uma das suas fases. Ele abrange todas as atividades que se fazem necessárias para um bom gerenciamento de projetos de software, enfatizando sempre as frequentes reuniões que ajudam a alinhar os objetivos entre todos os envolvidos, inclusive o cliente. Portanto, o Scrum serve como um guia de boas práticas para o alcance do sucesso. O conhecimento das suas práticas permite uma aplicação de forma variada, e este é um dos seus aspectos positivos – a adaptabilidade. Vale ressaltar que suas práticas podem ser aplicadas em qualquer contexto, no qual pessoas precisem trabalhar juntas para atingir um objetivo comum. O Scrum torna-se ideal para projetos dinâmicos e suscetíveis a mudanças de requisitos, sejam eles novos ou apenas modificados, e para isso é necessário entender bem seus papéis, suas responsabilidades, seus conceitos e cada fase do seu ciclo.

edição ta

de serem propostas idealmente para serem utilizadas por equipes pequenas e médias (até 12 desenvolvedores), aproximadamente 15% dos projetos que usam metodologias ágeis estão sendo desenvolvidos por equipes de 21 a 50 pessoas, e 10% dos projetos são desenvolvidos por equipes com mais de 50 pessoas, considerando um universo de 200 empresas usado no estudo. O estudo acima demonstra que é possível obter sucesso com o Scrum mesmo em equipes maiores, mas para isso é necessário empenho e motivação das pessoas envolvidas, treinamentos e disciplina para adotar os processos desta metodologia. Os benefícios são claros e são muitos, porém, não sem muito esforço, recursos e uma completa reformulação na cultura da organização. Vale ressaltar que as práticas do Scrum podem ser aplicadas em qualquer contexto, no qual pessoas precisem trabalhar juntas para atingir um objetivo comum. Ele é recomendado para projetos nas áreas de software, automotiva, telecom e, principalmente, de pesquisa e inovação. Apresenta-se ideal para projetos dinâmicos e suscetíveis a mudanças de requisitos, sejam eles novos ou apenas modificados. No entanto, para aplicá-lo, é preciso entender antes seus papéis, suas responsabilidades, seus conceitos e os artefatos das fases do ciclo. A abordagem ágil assim como a abordagem tradicional possui características positivas e negativas, sendo que a principal diferença entre as duas está no conjunto de pressupostos de cada uma. É possível afirmar, ainda, que existe uma sinergia muito grande entre as duas metodologias, ou seja, uma pode complementar a outra. Observa-se que não existe uma metodologia perfeita, assim como não há uma solução única para todos os casos. O projeto de software tem muito a ganhar com metodologias ágeis e suas práticas, assim como quaisquer projetos de inovação, com alto grau de mudanças, escopo não muito bem definido ou que precisam de resultados no curto prazo. Por outro lado, as situações em que existem fortes requisitos contratuais, amarrando fortemente prazos e escopo, ou quando a organização já possui maturidade e experiência com projetos semelhantes, podem ser candidatos para uma abordagem mais tradicional.


metodologias ágeis

Referências AGUIAR, Luiz. Introdução ao Scrum. 2008. Disponível em: <http://www.gonow.com.br/blog/ introducao-ao-scrum> Acesso em: 09 ago 2009. BISSI, Wilson. SCRUM – Metodologia de Desenvolvimento Ágil. 2007. 6 p. Centro Universitário de Maringá, Maringá. Disponível em: < http://docs.google.com/gview?a=v&q=cache%3AmoxlrND QQGsJ%3Arevista.grupointegrado.br%2Frevista%2Findex.php%2Fcampodigital%2Farticle%2F view%2F312%2F146+iterativo+e+incremental+e+pode+ser+aplicado+a+qualquer+produ to+ou+no+gerenciamento+de+qualquer+atividade+complexa&hl=pt-BR&gl=br&pli=1 > Acesso em: 13 ago 2009. BROD, Cesar. As raízes do Scrum. 2008. Disponível em: <http://www.brod.com.br/?q=node/366> Acesso em: 08 jul 2009. Brooks F. No Silver Bullet: Essence and Accidents of Software Engineering. Computer 20(4):10-19, 1987.

MARCH, Rodrigo. Método que prega metas de curto prazo e interação de equipe ganha mercado. 2009. Disponível em: http://oglobo.globo.com/economia/seubolso/mat/2009/02/14/metodoque-prega-metas-de-curto-prazo-integracao-de-equipe-ganha-mercado-754418293.asp> Acesso em: 16 ago 2009. MARTINS, José Carlos Cordeiro. Técnicas para gerenciamento de projetos de software. Rio de Janeiro, Editora Brasport, 1ª Edição, 2007. MITTELBACH, Artur F; SILVA, Juliana M.; ARAUJO, Allan R. S. Scrum: Novas Regras do Jogo. 2006. Disponível em: <http://www.cin.ufpe.br/~sbgames/proceedings/files/Scrum.pdf> Acesso em: 10 ago 2009.

CISNEIROS, Hugo. Modelo de Desenvolvimento Ágil. 2009. Disponível em: <http://www.devin.

NETO, Erasmo Isotton. Scrumming: Ferramenta Educacional para Ensino de Práticas do SCRUM. 2008. 80p. Monografia (Bacharelado em Sistemas de Informação). Pontifícia Universidade Católica do Rio Grande do Sul, Porto Alegre.Disponível em: <http://64.233.163.132/search?q=cache:fJ7X_ ZmpYFYJ:www.inf.pucrs.br/~rafael/Scrumming/Scrumming.pdf+uso+scrum+tem+crescido&

com.br/modelo-scrum/> Acesso em: 09 ago 2009.

cd=6&hl=pt-BR&ct=clnk&gl=br&lr=lang_pt&client=firefox-a> Acesso em: 17 ago 2009.

COHN,Mike.Uma introdução ao SCRUM.2002.Disponível em:< http://www.mountaingoatsoftware. com/system/asset/file/44/PortugueseScrum.ppt> Acesso em: 30 jun 2009.

ROCHA, Thayssa Águila da; OLIVEIRA, Sandro Ronaldo Bezerra; VASCONCELOS, Alexandre Marcos Lins de. Adequação de Processos para Fábricas de Software. 2004. Disponível em: < http://www. simpros.com.br/Apresentacoes_PDF/Artigos/Art_12_Simpros2004.pdf > Acesso em: 13 ago 2009.

CORDEIRO, Lucas. Metodologia de Desenvolvimento Ágil Scrum: O caso XMPM. Manaus; 2006. Disponível em: <http://users.ecs.soton.ac.uk/lcc08r/artigos/metodologia-agil-scrum-XMPM. ppt > Acesso em: 26 jun 2009. CRUZ, Leandro Rodrigo Saad. Desenvolvimento de Software com Scrum. 2008. Disponível em: <http://www.assembla.com/spaces/projeto_ambap_ufal/documents/csaP3ANYqr3A1_ ab7jnrAJ/download/DesenvolvimentodeSoftwarecomScrum.pdf > Acesso em: 12 ago 2009. FERSTE, Maurício Antônio. Metodologias Ágeis. 2009. Disponível em: < http://waltercunha.com/ blog/index.php/2009/06/29/metodologias-ageis/> Acesso em: 07 jul 2009. FUSCO, Camila. Scrum: a nova gestão de projetos. 2008. Disponível em: < http://governanca. wordpress.com/2008/03/18/scrum-a-nova-gestao-de-projetos/> Acesso em: 07 jul 2009. GALDINO, Cárlisson Borges Tenório. AWA - Um Processo Ágil para Desenvolvimento de Aplicações Web Atômicas. 2006. 37 p. Monografia (Pós-Graduação Latu Sensu em Produção de Software). Universidade Federal de Lavras. Lavras. Disponível em: <http://64.233.163.132/ search?q=cache:RXu31pB_sr4J:repositorio.viadigital.org.br/frs/download.php/7/awa.pdf+Gran de+parte+dos+processos+tradicionais+em+uso+atualmente+tem+como+base+os+mode los+de+diagramas+da+[[http://www.uml.org/+|+UML]],+como+%C3%A9+o+caso+do+ RUP&cd=8&hl=pt-BR&ct=clnk&gl=br&client=firefox-a> Acesso em: 12 ago 2009. GOMES, André Faria, Desenvolvendo com Agilidade. 2009. Revista Java Magazine, Edição 68. Disponível em: < http://www.devmedia.com.br/space.asp?id=217030 > Acesso em: 12 ago 2009. KNIBERG, Henrik. Scrum e XP direto das Trincheiras : como nós fazemos Scrum. 2007. Disponível em:<http://www.infoq.com/resource/minibooks/scrum-xp-from-the-trenches/pt/pdf/ ScrumeXPDiretodasTrincheiras.pdf>. Acesso em: 24 jun 2009. LIMA, Lucimara Benigno de. Papéis no Scrum. 2008. Disponível em: <http://lucimarabenigno. wordpress.com/2008/07/31/papeis-no-scrum/> Acesso em: 14 ago 2009.

SABBAGH, Rafael; GARRIDO, Marcos. Scrum e a Crise Mundial – Por que Scrum é melhor opção para projetos em tempos de crise. 2009. Disponível em: <http://www.infoq.com/br/articles/scrumcrise-mundial> Acesso em: 16 ago 2009. SANCHEZ, Ivan. Scrum em 2 minutos. 2007. Disponível em: < http://dojofloripa.wordpress. com/2007/02/07/scrum-em-2-minutos/> Acesso em: 06 jul 2009. SANTOS, Rildo F. SCRUM Experience. 2009. Disponível em: < http://www.etecnologia.com.br/ scrum/Tutorial%20SCRUM%20v14.pdf> Acesso em: 12 ago 2009. SCHWABER, Ken. Scrum Et Al. 2006. Disponível em:<http://engenharia.criarumblog.com/ Primeiro-blog-b1/Srum-b1-p5.htm> Acesso em: 26 jun 2009. SOARES, Michel dos Santos. Comparação entre Metodologias Ágeis e Tradicionais para o Desenvolvimento de Software. 2009. Disponível em: <http://wiki.dcc.ufba.br/pub/Aside/ ProjetoBitecIsaac/Met._Ageis.pdf > Acesso em: 20 ago 2009. Standish Group, CHAOS Report. Dennis, MA 02638, USA, 1995. TELES, Vinícius Manhães. Extreme Programming. 2008. Disponível em: < http://improveit.com.br/ xp> Acesso em: 23 jun 2009. TELES, Vinícius Manhães. SCRUM. 2008. Disponível em: <http://improveit.com.br/scrum > Acesso em: 30 jun 2009. VICENTE, Dinei. O que é SCRUM?. 2008. Disponível em: <http://www.tuister.com.br/scrum/> Acesso em: 10 ago 2009. YOSHIMA, Rodrigo. Valores do Desenvolvimento de Software. 2009. Disponível em: http://www. aspercom.com.br/ead/mod/resource/view.php?id=272 Acesso em: 14 ago 2009.

Edição 23 - Engenharia de Software Magazine

17


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

Gestão de Projetos segundo o PMBOK Uma Visão Geral De que se trata o artigo?

Cleyverson Pereira Costa cleyversoncosta@gmail.com

Mestre em Ciência da Computação pelo Centro de Informática da Universidade Federal de Pernambuco (CIn-UFPE) (2010). Especialista em Engenharia de Software com Ênfase em Teste de Software pelo (CIn-UFPE) (2007). Graduado em Ciência da Computação (2005). Possui experiência na área de testes, tendo atuado como Engenheiro de Testes pelo Motorola Brazil Test Center.

Alexandre Luna ajhol@cin.ufpe.br

Doutorando em Ciência da Computação pelo CIn-UFPE em Governança em TIC (em andamento). Mestre em Ciência da Computação pelo CIn-UFPE em Gerenciamento de Projetos (2009). MBA em Gestão Estratégica de TIC, FACIPE (2003). Engenheiro Químico pela UFPE (2001). É Analista Consultor da ATI-PE, Gestor de Infraestrutura de TIC da Secretaria Estadual de Educação e Pesquisador do NUTES-HC-UFPE e GP2CIn-UFPE.

18

A

tualmente, mudanças em diversos aspectos da vida humana (culturais, tecnológicos, políticos, econômicos, sociais, etc.) estão ocorrendo em velocidade cada vez maior. De uma maneira geral, é comum associarmos as mudanças significativas ao resultado de projetos (Vieira, 2002). Como consequência, gerenciar projetos de forma eficiente em um contexto de constantes mudanças é um dos grandes desafios do executivo dos tempos modernos (Kerzner, 2001). Superar este desafio é estar preparado para gerenciar projetos de forma planejada e profissional. Assim, o gerenciamento de projetos é citado por alguns autores como uma profissão relativamente nova e emergente. Isto se deve ao fato de várias organizações, públicas e privadas, instituições de pesquisa e ensino, entre outras, estarem buscando cada vez mais

Engenharia de Software Magazine - Gestão de Projetos segundo o PMBOK

Este artigo tem por objetivo apresentar a necessidade de pensar em cada iniciativa organizacional como um projeto e salientar os benefícios de sua efetiva gestão. Também será discorrido sobre algumas definições de gestão de projetos, providas por profissionais de renome. Por fim, é apresentada uma visão geral do PMBOK (Project Management Body of Knowledge), abordando as nove áreas do conhecimento, os cinco grupos de processo e seus quarenta e quatro processos.

Para que serve? Uma gestão de projetos utilizando o PMBOK (Project Management Body of Knowledge) do PMI (Project Management Institute) prevê um arcabouço para efetivo controle dos diversos aspectos dinâmicos de um projeto, tornando resultados mais previsíveis e agregando valor à organização.

Em que situação o tema é útil? As organizações que desejam sobreviver no mercado precisam inovar, criar novos produtos, lançar campanhas de marketing inteligentes, construir fábricas mais modernas, atualizar processos internos, relacionar-se melhor com seus clientes. Mas, para fazer tudo isso, precisam de projetos. São eles que viabilizam as mudanças e projetos mal geridos são um convite ao fracasso.


Planejamento e Gerência

estudar, conhecer, difundir, capacitar, implementar e evoluir o conhecimento, as metodologias, as práticas e as ferramentas empregadas nesta área (Neto, Bocoli 2003; Martins, 2003; PMI 2004; Sandeep, 2002). As organizações, para colherem os benefícios esperados, devem ter a conscientização em adotar o gerenciamento de projetos não somente como uma profissão, mas como uma metodologia na qual os seus gerentes devam ser devidamente treinados, de forma a agregar valor às experiências individuais de cada um deles. O gerenciamento de projetos deve ser feito de forma profissional e conduzido por pessoal qualificado. Desta forma, a cultura de projetos nas organizações deve ser criada, a sua implantação deve ser realizada de forma sistemática e os seus princípios colocados em prática da maneira mais adequada. Niskier e Blois (2003) citam ainda que o profissional de hoje, para ter sucesso no trabalho, precisa estar apto para reciclar e acrescentar conceitos, posturas e atitudes. Eles ressaltam que a educação continuada vem obtendo destaque, como indicativo de que o aprendizado precisa ser um processo de caráter dinâmico e permanente na vida dos profissionais de qualquer setor produtivo. Os gerentes de projetos devem ser profissionais preparados para poder praticar e desempenhar bem o seu papel trazendo os benefícios que as organizações desejam. Segundo Prado (Prado, 2000), a boa prática de gerenciamento de projetos produz resultados expressivos para as organizações como: (1) redução no custo e prazo de desenvolvimento de novos produtos; (2) aumento no tempo de vida dos novos produtos; (3) aumento de vendas e receita; (4) aumento do número de clientes e de sua satisfação; e (5) aumento da chance de sucesso nos projetos.

Definições de Gestão de Projetos Segundo o PMBOK (PMI, 2004), Gerência de Projetos é a aplicação de conhecimentos, habilidades, ferramentas e técnicas em atividades do projeto, a fim de satisfazer ou exceder as necessidades e expectativas dos stakeholders. Isso envolve, invariavelmente, equilibrar demandas concorrentes em relação a: a) escopo, prazo, custo e qualidade; b) stakeholders com necessidades e expectativas diferenciadas; e c) requisitos identificados (necessidades) e não identificados (expectativas). Vargas (2000, p. 8), por sua vez, define projeto como um empreendimento não repetitivo, caracterizado por uma sequência clara e lógica de eventos, com início, meio e fim, que se destina a atingir um objetivo claro e definido, sendo conduzido por pessoas dentro de parâmetros pré-definidos de tempo, custo, recursos envolvidos e qualidade. Vargas (2000), apud Wideman (1992), assume que outras características devem ser consideradas com atenção especial, como raridade, restrições (como limitadores vinculados aos fatores tempo, capital e/ou recursos), multidisciplinaridade (requerendo integração entre atores e áreas diversas) e complexidade (principalmente no que tange aos aspectos de divergência de objetivos e da constante mudança tecnológica).

Segundo Kerzner (2003), as empresas que adotam uma filosofia e práticas maduras de gerenciamento de projetos estão mais capacitadas ao sucesso na corrida pelo mercado do que aquelas que continuam com as velhas práticas. Segundo o autor, o mundo está finalmente reconhecendo a importância da gerência de projetos e seu impacto na lucratividade da organização.

Project Management Body of Knowledge (PMBOK) O PMBOK é um guia de referência que descreve o conjunto de conhecimento dentro da profissão de gerência de projetos, apresentando as melhores práticas existentes. É um material genérico que serve para todas as áreas, ou seja, tanto para construção de um edifício como para a produção de software. Este guia é desenvolvido e publicado pelo PMI (Project Management Institute), uma organização sem fins lucrativos, fundada nos Estados Unidos em 1969 e que se dedica ao fomento da gestão de projetos no mundo (Sato, 2004; Rouiller, 2004). O PMI (2004) considera que um projeto, ao longo de seu ciclo de vida, é composto por processos, que nada mais são do que um conjunto de ações realizadas por pessoas e que se destina à obtenção de resultados. Os processos de projeto podem ser classificados em duas categorias: 1. Processos de gerenciamento de projetos: descrevem, organizam e completam o trabalho envolvido no projeto. Os processos de gerenciamento de projetos normalmente são aplicáveis a todos os tipos de projetos. Os grupos de processo desta categoria são os contemplados pelo PMBOK; 2. Processos orientados ao produto: especificam e criam o produto do projeto. Estes tipos de projetos estão diretamente vinculados ao ciclo de vida específico de cada projeto, variando de acordo com a área de aplicação e as características particulares de cada projeto. As duas categorias de processos de projeto sobrepõem-se e integram-se ao longo de toda a existência do projeto. O PMBOK 2004 é composto por 44 processos de gerenciamento de projetos que são organizados em cinco grupos (PMI, 2004): 1. Processos de Iniciação: reconhecer que um projeto ou fase deve começar e se comprometer para executá-lo(a); 2. Processos de Planejamento: planejar e manter um esquema de trabalho viável para se atingir os objetivos de negócios que determinaram a existência do projeto; 3. Processos de Execução: coordenar pessoas e outros recursos na realização do projeto; 4. Processos de Controle: assegurar que os objetivos do projeto estão sendo atingidos por meio do monitoramento e avaliação do seu progresso, tomando ações corretivas quando necessário; 5. Processos de Encerramento: formalizar a aceitação do projeto ou fase e encerrá-lo(a) de forma organizada. Esses cinco grupos de processos possuem dependências claras e são executados na mesma sequência em todos os projetos (PMI, 2004). A Figura 1 apresenta as conexões entre os grupos de processos.

Edição 23 - Engenharia de Software Magazine

19


Figura 1. Ligações entre os grupos de processo (PMI, 2004)

Com o objetivo de organizar o conhecimento sobre gerenciamento de projetos o PMI definiu nove áreas de conhecimento em gerência de projetos, como apresentado na Figura 2.

Figura 2. Áreas do Conhecimento do PMBOK (PMI, 2004)

Conforme mencionado, o conhecimento em gerenciamento de projetos, de acordo com o PMBOK, é organizado em nove áreas do conhecimento e cinco grupos de processos (PMI, 2004). Com o objetivo de salientar a relação entre as nove áreas do conhecimento, os cinco grupos de processo e os 44 processos, apresenta-se a Tabela 1. A seguir são descritos os processos de cada área de conhecimento do PMBOK. Todos os processos descritos, das áreas abaixo, interagem uns com os outros e também com os processos das demais áreas de conhecimento. Cada processo pode envolver esforço de um ou mais indivíduos ou grupos de indivíduos, dependendo das necessidades do projeto. Cada processo, geralmente, ocorre pelo menos uma vez em cada fase do projeto.

Gerência de Integração de Projetos A gerência de integração engloba os processos necessários para garantir que os vários elementos de um projeto sejam propriamente coordenados. Objetiva realizar as negociações dos conflitos entre objetivos e alternativas do projeto, com a finalidade de atingir ou exceder as necessidades

20

e expectativas de todas as partes interessadas (Rouiller, 2004). Essa área de conhecimento inclui os seguintes processos (PMI, 2004): 1. Desenvolver o termo de abertura do projeto – desenvolvimento do termo de abertura do projeto que autoriza formalmente um projeto ou uma fase do projeto; 2. Desenvolver a declaração do escopo preliminar do projeto – desenvolvimento da declaração do escopo preliminar do projeto que fornece uma descrição de alto nível do escopo; 3. Desenvolver o plano de gerenciamento do projeto – documentação das ações necessárias para definir, preparar, integrar e coordenar todos os planos auxiliares em um plano de gerenciamento de projeto; 4. Orientar e gerenciar a execução do projeto – execução do trabalho definido no plano de gerenciamento do projeto para atingir os requisitos do projeto definidos na declaração do escopo do projeto; 5. Monitorar e controlar o trabalho do projeto – monitoramento e controle dos processos usados para iniciar, planejar, executar e encerrar um projeto para atender aos objetivos de desempenho definidos no plano de gerenciamento do projeto; 6. Controle integrado de mudanças – revisão de todas as solicitações de mudança, aprovação de mudanças e controle de mudanças nas entregas e nos ativos de processos organizacionais; 7. Encerrar o projeto – finalização de todas as atividades em todos os grupos de processos de gerenciamento de projetos para encerrar formalmente o projeto ou uma de suas fases.

Gerência de Escopo de Projetos A gerência do escopo do projeto descreve os processos requeridos para assegurar que o projeto inclua todo o trabalho necessário, e tão somente o trabalho necessário, para complementar de forma bem sucedida o projeto. A preocupação fundamental compreende definir e controlar o que está ou não incluído no projeto (Rouiller, 2004). Essa área de conhecimento inclui os seguintes processos (PMI, 2004): 1. Planejamento do escopo – criação de um plano de gerenciamento do escopo do projeto que documenta como o escopo do mesmo será definido, verificado e controlado e como a estrutura analítica do projeto (EAP1) será criada e definida; 2. Definição do escopo – desenvolvimento de uma declaração do escopo detalhada do projeto como a base para futuras decisões do projeto; 3. Criar EAP – subdivisão das principais entregas do projeto e do trabalho do projeto em componentes menores e mais facilmente gerenciáveis; 4. Verificação do escopo – formalização da aceitação das entregas do projeto terminadas; 5. Controle do escopo – controle das mudanças no escopo do projeto.

Engenharia de Software Magazine - Gestão de Projetos segundo o PMBOK


Planejamento e Gerência

Áreas do Conhecimento

Integração

Escopo

Tempo

Custos Qualidade Recursos Humanos

Iniciação Planejamento - Desenvolver Termo de - Desenvolver o Plano de Gerenciamento Abertura - Desenvolver a Declaração do Escopo Preliminar - Planejamento do Escopo - Definição do Escopo - Criar EAP - Definição de Atividades - Sequenciamento de Atividades - Estimativa de Recurso das Atividades - Estimativa de Duração das Atividades - Desenvolvimento do Cronograma - Estimativa de Custos - Orçamentação - Planejamento da Qualidade - Planejamento de Recursos Humanos

Grupos de Processos Execução - Orientar e Gerenciar a Execução do Projeto

Aquisições

Encerramento - Encerrar o Projeto

- Controle do Cronograma

- Controle de Custos

- Planejamento das Comunicações

- Garantia da Qualidade - Montagem da Equipe - Desenvolvimento do Time - Distribuição das Informações

- Planejamento do Gerenciamento de Riscos - Identificação dos Riscos - Análise Qualitativa dos Riscos - Análise Quantitativa dos Riscos - Planejamento de Respostas a Riscos - Planejar Compras e Aquisições - Planejar Contratações

- Solicitar Respostas de Fornecedores - Administração de Contrato - Selecionar Fornecedores

Comunicação

Riscos

Controle - Monitorar e Controlar o Trabalho do Projeto - Controle Integrado de Mudanças - Verificação do Escopo - Controle do Escopo

- Controle da Qualidade - Gerenciar a Equipe do Projeto - Relatório de Desempenho - Gerenciamento das Partes Interessadas - Monitoramento e Controle de Riscos

- Encerramento do Contrato

Tabela 1. Mapeamento dos processos nos grupos de processos e áreas de conhecimento

Gerência de Tempo de Projetos A gerência de tempo do projeto objetiva garantir o término do projeto no tempo certo, ou seja, realizar o término do projeto no prazo previsto (Rouiller, 2004; PMI, 2004). Neste aspecto, a gerência de tempo consiste da definição, ordenação e estimativa de duração das atividades e de elaboração e controle de cronogramas. Essa área de conhecimento inclui os seguintes processos (PMI, 2004): 1. Definição da atividade – identificação das atividades específicas do cronograma que precisam ser realizadas para produzir as várias entregas do projeto; 2. Sequenciamento de atividades – identificação e documentação das dependências entre as atividades do cronograma; 3. Estimativa de recursos da atividade – estimativa do tipo e das quantidades de recursos necessários para realizar cada atividade do cronograma; 4. Estimativa de duração da atividade – estimativa do número de períodos de trabalho que serão necessários para terminar as atividades individuais do cronograma; 5. Desenvolvimento do cronograma – análise dos recursos necessários, restrições do cronograma, durações e sequências de atividades para criar o cronograma do projeto;

6. Controle do cronograma – controle das mudanças no cronograma do projeto.

Gerência de Custo de Projetos A gerência de custos do projeto inclui os processos envolvidos em planejamento, estimativa, orçamentação e controle de custos, de modo que seja possível terminar o projeto dentro do orçamento aprovado (PMI, 2004). Essa área de conhecimento inclui os seguintes processos (PMI, 2004): 1. Estimativa de custos – desenvolvimento de uma estimativa dos custos dos recursos necessários para terminar as atividades do projeto; 2. Orçamentação – agregação dos custos estimados de atividades individuais ou pacotes de trabalho para estabelecer uma linha de base dos custos; 3. Controle de Custos – Controle dos fatores que criam as variações de custos e controle das mudanças no orçamento do projeto.

Gerência da Qualidade de Projetos A gerência da qualidade possui por objetivo garantir que o projeto satisfará as exigências para as quais foi contratado (Rouiller, 2004). O projeto tem qualidade quando é concluído

Edição 23 - Engenharia de Software Magazine

21


em conformidade aos requisitos, especificações (o projeto deve produzir o que foi definido) e adequação ao uso (deve satisfazer às reais necessidades do cliente) (Dinsmore e Cavalieri, 2003). Essa área de conhecimento inclui os seguintes processos (PMI, 2004): 1. Planejamento da qualidade – identificação dos padrões de qualidade relevantes para o projeto e determinação de como satisfazê-los; 2. Realizar a garantia da qualidade – aplicação das atividades de qualidade planejadas e sistemáticas para garantir que o projeto emprega todos os processos necessários para atender aos requisitos; 3. Realizar o controle da qualidade – monitoramento de resultados específicos do projeto a fim de determinar se eles estão de acordo com os padrões relevantes de qualidade e identificação de maneiras de eliminar as causas de um desempenho insatisfatório.

Gerência de Recursos Humanos de Projetos A gerência de recursos humanos objetiva garantir o melhor aproveitamento das pessoas envolvidas no projeto (Rouiller, 2004). De acordo com Dinsmore & Cavalieri (2003), é uma área muitas vezes complexa e subjetiva, exigindo constante pesquisa, sensibilidade e muita vivência do dia-a-dia para saber lidar com o ser humano. Essa área de conhecimento inclui os seguintes processos (PMI, 2004): 1. Planejamento de recursos humanos – identificação e documentação de funções, responsabilidades e relações hierárquicas do projeto, além da criação do plano de gerenciamento de pessoal; 2. Contratar ou mobilizar a equipe do projeto – obtenção dos recursos humanos necessários para terminar o projeto; 3. Desenvolver a equipe do projeto – melhoria de competências e interação de membros da equipe para aprimorar o desempenho do projeto; 4. Gerenciar a equipe do projeto – acompanhamento do desempenho de membros da equipe, fornecimento de feedback, resolução de problemas e coordenação de mudanças para melhorar o desempenho do projeto.

Gerência de Comunicação de Projetos A gerência de comunicação descreve os processos necessários para assegurar a geração, captura, distribuição, armazenamento e pronta apresentação das informações do projeto para que sejam feitas de forma adequada e no tempo certo (Dinsmore & Cavalieri, 2003). Essa área de conhecimento inclui os seguintes processos (PMI, 2004): 1. Planejamento das comunicações – determinação das necessidades de informações e comunicações das partes interessadas no projeto; 2. Distribuição das informações – colocação das informações necessárias à disposição das partes interessadas no projeto no momento adequado;

22

3. Relatório de desempenho – coleta e distribuição das informações sobre o desempenho. Isso inclui o relatório de andamento, medição do progresso e previsão; 4. Gerenciar as partes interessadas – gerenciamento das comunicações para satisfazer os requisitos das partes interessadas no projeto e resolver problemas com elas.

Gerência de Risco de Projetos Os objetivos do gerenciamento de riscos do projeto são aumentar a probabilidade e o impacto dos eventos positivos e diminuir a probabilidade e o impacto dos eventos adversos ao projeto (PMI, 2004). Descreve os processos que dizem respeito à identificação, análise e resposta aos riscos do projeto. Essa área de conhecimento inclui os seguintes processos (PMI, 2004): 1. Planejamento do gerenciamento de riscos – decisão de como abordar, planejar e executar as atividades de gerenciamento de riscos de um projeto; 2. Identificação de riscos – determinação dos riscos que podem afetar o projeto e documentação de suas características; 3. Análise qualitativa de riscos – priorização dos riscos para análise ou ação adicional subsequente através de avaliação e combinação de sua probabilidade de ocorrência e impacto; 4. Análise quantitativa de riscos – análise numérica do efeito dos riscos identificados nos objetivos gerais do projeto; 5. Planejamento de respostas a riscos – desenvolvimento de opções e ações para aumentar as oportunidades e reduzir as ameaças aos objetivos do projeto; 6. Monitoramento e controle de riscos – acompanhamento dos riscos identificados, monitoramento dos riscos residuais, identificação de novos riscos, execução de planos de respostas a riscos e avaliação da eficácia de resposta aos riscos durante todo o ciclo de vida do projeto.

Gerência de Aquisições de Projetos A gerência de aquisição tem por objetivo principal obter bens e serviços externos à organização executora (Rouiller, 2004). Essa área de conhecimento inclui os seguintes processos (PMI, 2004): 1. Planejar compras e aquisições – determinação do que comprar ou adquirir e de quando e como proceder; 2. Planejar contratações – documentação dos requisitos de produtos, serviços e resultados e identificação de possíveis fornecedores; 3. Solicitar respostas de fornecedores – obtenção de informações, cotações preços, ofertas ou propostas, conforme adequado; 4. Selecionar fornecedores – análise de ofertas, escolha entre possíveis fornecedores e negociação de um contrato por escrito com cada fornecedor; 5. Administração de contrato – gerenciamento do contrato e da relação entre o comprador e o fornecedor, análise e documentação do desempenho atual ou passado de um fornecedor, a fim de estabelecer ações corretivas necessárias e fornecer uma base para futuras relações com o fornecedor; gerenciamento de mudanças

Engenharia de Software Magazine - Gestão de Projetos segundo o PMBOK


Planejamento e Gerência

Dê seu feedback sobre esta edição! A Engenharia de Software Magazine tem que ser feita ao seu gosto. Para isso, precisamos saber o que você, leitor, acha da revista! Dê seu voto sobre este artigo, através do link:

Feedback eu

www.devmedia.com.br/esmag/feedback

Referências DINSMORE, Paul C.; CAVALIREI, Adriane. Como se tornar um profissional em gerenciamento de projetos:.livro-base de “preparação para certificação PMP – Project Management Professional”. Rio de Janeiro: Qualitymark, 2003. Kerzner, H.; (2001). Project Management – A Systems Approach to Planning, Scheduling, and Controlling, New York NY, John Willey & Sons Kerzner, H. (2003), Project Management: A Systems Approach to Planning, Scheduling, and Controlling, Wiley, New Jersey, NJ, USA. Martins, L.; (2003) Gestão Profissional de Projetos. Disponível em http://www.ietec.com.br/ietec/ techoje/techoje/gestaodeprojetos/2003/10/10/2003_10_10_0003.2xt/-template_interna. Neto, J. e Bocoli, F.; (2003). SUCESSOSW = CMM2 + PMBOK. PMI Journal, Publicação da Seção do PMI-RS. Número 5, Maio 2003. pág: 2-11. Disponível em http://www.pmirs.org/PMI20_Frame. htm. Niskier, C. e Blois, M;. (2003). A UNIVIR: Três Anos Consolidando o e-Learning nas Empresas em: Maia, C. Ead.Br Experiências Inovadoras em Educação a Distância no Brasil Reflexões Atuais, em Tempo Real. Anhembi Morumbi

PMI (2004), Project Management Body of Knowledge (PMBOK Guide - 3rd Edition), Project Management Institute, Pennsylvania, PA, USA. Prado, D.; (2000). Gerenciamento de projetos nas Organizações, Vol-I, Belo Horizonte, FDG Rouiller, A. C. (2004), ‘Gerência de Projetos de Software’, Master’s thesis, Universidade Federal de Lavras - UFLA. Sandeep, M.; (2002). The Accidental Profession Comes of Age. Disponível em: http://www. standards.org.au/STANDARDS/NEWSROOM/TAS/2002-06/PROJECT/PROJECT.HTM. Sato, C. E. Y. (2004), ‘Gestão Corporativa de Projetos para Instituições de Pesquisa Tecnológica: Caso LACTEC’, Master’s thesis, Centro Federal de Educação Tecnológica do Paraná. Vargas, R. V. (2000), Gerenciamento de projetos: estabelecendo diferenciais competitivos, Brasport, Rio de Janeiro. Vieira, E. (2002). Gerenciando Projetos na Era de Grandes Mudanças - Uma breve abordagem do panorama atual. PMI Journal – PMI-RS 3, pp. 7-16 Wideman, R. M. (1991), A framework for project and program management integration.

Edição 23 - Engenharia de Software Magazine

23

sobre e s

Iniciamos este artigo apresentando a importância da gestão de projetos diante do contexto dinâmico que as organizações estão inseridas. Posteriormente foram providas diversas definições sobre gestão de projetos. De forma geral, viu-se que um projeto pode ser entendido como uma empreitada sujeita a riscos, devido à natureza única de suas atividades, de seus produtos e de seus objetivos. Para minimizar os riscos, é importante executar um projeto por meio de métodos eficazes e conceitualmente sólidos, como os contidos no PMBOK.

Dê s

Conclusões

Abordou-se também que o sucesso de um projeto não é medido apenas quando os resultados técnicos são atingidos, mas numa visão mais ampla e atual, deve ser medido face ao atendimento às diferentes necessidades e expectativas dos stakeholders envolvidos no projeto. Neste sentido, mostra-se necessário um grande esforço por parte do gerente de projeto, sendo ele o principal responsável por alinhar o trabalho da equipe e superar dificuldades ao longo da execução do projeto. Por fim, foi apresentada uma visão geral do PMBOK (Project Management Body of Knowledge), abordando as nove áreas do conhecimento, os cinco grupos de processo e seus quarenta e quatro processos.

edição ta

relacionadas ao contrato e, quando adequado, gerenciamento da relação contratual com o comprador externo do projeto; 6. Encerramento do Contrato – dá suporte ao processo Encerrar o Projeto, pois envolve a confirmação de que todo o trabalho e as entregas foram aceitáveis. Também envolve atividades administrativas, como a atualização de registros para refletir resultados finais e o arquivamento dessas informações para uso futuro.


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

Métricas e Planejamento com XPlanner Melhore o planejamento e acompanhamento das atividades com a ferramenta XPlanner De que se trata o artigo? Instalação e utilização da ferramenta XPlanner. Você conhecerá como esta ferramenta open source pode colaborar no processo de planejamento e acompanhamento das atividades de desenvolvimento de software.

Para que serve? Proporcionar o planejamento e acompanhamento das atividades inerentes à Engenharia de Software. Além disso, a ferramenta fornece suporte ao desenvolvimento tradicional e às metodologias ágeis, onde

O Lenildo Morais lenildojmorais@gmail.com

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

24

XPlanner é uma ferramenta de código livre utilizada para auxiliar no planejamento e acompanhamento de projetos de software, podendo ser utilizada em processos de desenvolvimento tradicionais e ágeis. Ela fornece aos desenvolvedores uma forma mais fácil de acompanhar o andamento do projeto, possibilitando a comunicação de toda a equipe, mesmo sendo em diferentes tarefas, para todos terem controle do que está sendo feito dentro do projeto. Neste artigo vamos abordar, de forma prática, os procedimentos de instalação

Engenharia de Software Magazine - Métricas e Planejamento com XPlanner

todas as informações adquiridas no desenvolvimento das tarefas podem ser armazenadas e utilizadas como base histórica.

Em que situação o tema é útil? Nos projetos de desenvolvimento de software, sobretudo quando se deseja otimizar os recursos humanos existentes para o desenvolvimento das tarefas. Se você trabalha em uma fábrica de software e precisa planejar, acompanhar e extrair métricas inerentes às atividades que sua equipe está realizando, a ferramenta XPlanner apresenta-se como uma ótima alternativa para este propósito.

da ferramenta XPlanner. Em seguida iremos explorar suas principais funcionalidades, que permitem que as equipes tenham uma melhor visão do desenvolvimento das diversas tarefas que estão sendo desenvolvidas. Tal visibilidade proporciona, através dos dados históricos fornecidos pela ferramenta, planejamentos futuros mais precisos.

O que é o XPlanner? Ferramenta open source implementada em Java para auxiliar o planejamento de projetos de desenvolvimento tradicionais ou ágeis, onde todas as tarefas


Planejamento e Gerência

executadas durante o projeto são armazenadas. O XPlanner tem como principal objetivo fornecer aos times uma forma mais fácil de controlar o andamento do projeto. Suas principais características são as iterações, “users stories” e as tarefas, referentes ao projeto de software, que podem ser planejadas e posteriormente acompanhadas, dando maior visibilidade à equipe quanto a evolução das atividades. No XPlanner há apenas dois níveis de usuários: o System Administrator e o usuário comum. O primeiro nível tem a responsabilidade de criar os demais usuários que utilizarão a ferramenta, sendo recomendado, por medida de segurança, que este nível esteja centralizado em uma ou duas pessoas no máximo.

Instalando o XPlanner Antes de apresentarmos o processo de instalação, vamos conhecer os pré-requisitos necessários para a instalação do XPlanner: • Banco de dados MySQL 5.0; • Tomcat – O XPlanner precisa de um servidor para que seja executado, e o Tomcat é um servidor web que atende a este propósito. Até o momento da escrita deste artigo a versão atual era a 6.0.20. • Para instalar o Tomcat tudo que você precisa é fazer o download e executar o arquivo .exe. O XPlanner é distribuído através de um único arquivo compactado chamado xplanner_0.6.1. Após baixar este arquivo, descompacte-o em um diretório qualquer e copie o arquivo xplanner.war para o diretório /webapps do Tomcat (ex.: C:\ Arquivos de programas\Apache Software Foundation\Tomcat 5.5\ webapps). Em seguida, inicie o Tomcat. Isso fará com que seja gerado o deploy automático do XPlanner, descompactando o arquivo .war e criando a estrutura de diretórios dentro do servidor. Será preciso também executar o MySQL para que seja criada uma base de dados com o nome “xplanner”. Neste primeiro momento a base ficará vazia. A carga do script responsável pela criação das tabelas utilizadas pelo XPlanner pode ser dada executando o MySQL Query Browser e depois Arquivo>Open Script. Agora basta selecionarmos o arquivo xplanner.sql (que está presente no arquivo do Xplanner que foi baixado e descompactado) e executarmos o script. Neste momento todas as tabelas necessárias serão criadas, faltando apenas configurar o banco de dados para que o XPlanner funcione corretamente. A configuração será feita através do arquivo xplanner.properties. Nele poderão ser informados os dados para que a ferramenta possa se comunicar com o banco de dados. Para realizar esta configuração devemos abrir o arquivo xplanner.properties, que está no diretório classes (por exemplo: C:\Arquivos de programas\Apache Software Foundation\Tomcat 5.5\webapps\xplanner\WEB-INF\classes) e localizar a linha “Hibernate MySQL Configuration”. Neste trecho constam

os parâmetros para a conexão com o banco de dados, sendo necessário configurar a url, o usuário e a senha. A Listagem 1 mostra as linhas com as configurações que devem ser feitas para a conexão ser realizada com sucesso. Listagem 1. Arquivo xplanner.properties com os parâmetros de conexão. ################################### ### XPlanner Configuration ### ################################### # # Hibernate JDBC Configuration # # Hibernate MySQL Configuration hibernate.dialect=com.technoetic.xplanner.db.hibernate.XPlannerMySQLDialect hibernate.connection.driver_class=com.mysql.jdbc.Driver hibernate.connection.url=jdbc:mysql://localhost/xplanner?autoReconnect=true hibernate.connection.username=root hibernate.connection.password=root # Hibernate HSQLDB Configuration - external HSQLDB #hibernate.dialect=net.sf.hibernate.dialect.HSQLDialect #hibernate.connection.url=jdbc:hsqldb:/some/directory/xplanner #hibernate.connection.driver_class=org.hsqldb.jdbcDriver #hibernate.connection.username=sa #hibernate.connection.password=Krufeib4

Após informar os dados para a conexão entre o XPlanner e o banco de dados, o arquivo pode ser salvo e fechado. Agora vamos testar a ferramenta. Assim, abra o navegador e acesse o endereço http://localhost:8080/xplanner. A tela de login será apresentada. Entre com o usuário sysadmin, senha admin e clique em login. Se tudo estiver correto, você será autenticado e a tela inicial do XPlanner será exibida, conforme a Figura 1.

Figura 1. Tela de inicial do XPlanner

Primeiros passos na utilização do XPlanner A partir de agora iremos preparar o XPlanner para que seja possível realizar o acompanhamento de atividades. Primeiramente devemos criar um projeto, haja vista que as iterações e atividades que serão acompanhadas deverão estar sempre relacionadas a um projeto. Na tela inicial, são disponibilizados quatro links que atendem a objetivos distintos. A Tabela 1 mostra um quadro com as descrições de cada um deles. Para que possamos criar nosso primeiro projeto devemos clicar no link Adicionar Projeto. A Figura 2 ilustra a tela que será apresentada.

Edição 23 - Engenharia de Software Magazine

25


Links

Objetivo

Adicionar Projeto Permite que um novo projeto seja criado e a ele sejam associadas as tarefas que serão desenvolvidas. Meus Lista todas as atividades que foram planejadas para o usuário que está logado. Pessoas Team Timesheet

Permite adicionar usuários, além de exibir os demais que estão cadastrados na ferramenta. Mostra o tempo de cada iteração separadamente.

Tabela 1. Descrições dos links da tela inicial do XPlanner

no link Pessoas e posteriormente em Adicionar Pessoa. Neste momento será exibida uma tela para que sejam preenchidas as informações do novo usuário. Vamos então preenchê-las conforme abaixo: • Nome: Colaborador; • User Id: 01; • Iniciais: abc; • Email: colaborador@engenhariadesoftware.com.br; • Fone: 9999-9999; • Oculto?: Não; • Senha: 12345; • Confirme Senha: 12345; • Role: Editor.

Figura 2. Tela do XPlanner para criação de um novo projeto

Abaixo temos as descrições dos campos necessários para a criação do projeto, assim como os valores que utilizaremos para preenchê-los: • Nome – nome do projeto onde serão atribuídas as iterações e atividades. O XPlanner pode suportar um ou mais projetos distintos, isto é, a ferramenta é capaz de trabalhar com diversos projetos que, por sua vez, possuem suas próprias tarefas e usuários associados. Vamos preencher este campo com “Engenharia de Software”; • Descrição – neste campo podemos adicionar uma breve descrição do projeto, por exemplo: “Projeto desenvolvido para atender a demanda da funcionalidade de cadastro de clientes do módulo Engenharia de Software”; • Ocultar – esta opção torna o projeto visível ou não aos usuários que já estejam cadastrados e associados a ele. A opção é selecionada como “Sim” quando, por algum motivo, o projeto ainda não esteja totalmente definido pelo administrador da ferramenta ou falte ajustar algum detalhe. Entretanto, para o nosso exemplo selecionaremos a opção “Não”. Informados os campos acima, clique no botão Criar. Será exibida a tela apresentada na Figura 3. A criação do projeto é considerada o ponto fundamental para a utilização do XPlanner, pois as atividades só poderão ser definidas e utilizadas após a criação do mesmo.

Criando um novo usuário Os novos usuários podem ser adicionados através do link Pessoas, disponível na tela inicial da ferramenta. No nosso exemplo iremos criar apenas um usuário. Para isso, clique

26

Figura 3. Tela do XPlanner exibindo o projeto criado

Não marque a opção “System Administrator?”. Esta opção já foi selecionada para o perfil de administrador, no processo de instalação da ferramenta, e não é recomendado, por motivos de segurança, que haja mais de um usuário com este perfil. Portanto, após os campos serem devidamente preenchidos, basta clicar no botão Criar. Pronto, já temos nosso primeiro usuário criado e estamos aptos a incluir uma ou mais atividades para ele.

Criando uma iteração no projeto Uma iteração (ler Nota DevMan 1) pode ter vários significados dentro de um projeto. Porém, o mais usual entre as equipes é associá-la a um release ou entrega de determinado artefato, até porque dentro de uma mesma iteração pode haver uma ou mais estórias (ler Nota DevMan 2) com suas respectivas tarefas. Por isso, é importante perceber que o XPlanner obedece a uma estrutura hierárquica, ou seja, primeiro cria-se os projetos, depois as iterações, dentro das iterações as estórias e nas estórias as atividades. Isso facilita o acompanhamento das atividades além de dar maior visibilidade quanto à coleta de métricas e ao planejamento de novas atividades. Para criarmos uma iteração vamos clicar no link do nosso projeto “Engenharia de Software” e na tela apresentada clicar em Criar Iteração. Neste momento será exibida uma tela para

Engenharia de Software Magazine - Métricas e Planejamento com XPlanner


Planejamento e Gerência

que seja preenchida com as informações da iteração. Preencha os campos conforme abaixo: • Nome: Modulo 1; • Data Início: 16-01-10; • Data Fim: 25-01-10; • Descrição: Este módulo faz parte do projeto Engenharia de Software. Após o devido preenchimento dos campos, é só clicar no botão Criar. Neste momento veremos uma tela exibindo as estruturas que definimos até aqui, ou seja, projeto e iteração, de acordo com a Figura 4.

Nota do DevMan 1 Iteração Período onde um ou mais artefatos serão implementados.Dentro de uma iteração pode haver artefatos do mesmo tipo ou de natureza distintas, como por exemplo: documentos de requisitos, casos de uso e estratégias de testes.

Nota do DevMan 2 Estória É uma nomenclatura utilizada no XPlanner onde estão definidas as tarefas que serão implementadas. Ela pode ser vista como qualquer atividade que possa ser quebrada em tarefas, por exemplo, uma estratégia de testes, que pode ser quebrada em pelo menos três tarefas: elaborar casos de testes, executar casos de testes e avaliar execução de testes.

• Descrição: Este caso de uso faz parte do projeto Engenharia de Software. Depois de preenchidos todos os campos, devemos clicar no botão Criar. Neste momento encontraremos uma tela exibindo a estória que acabamos de criar, como apresenta a Figura 5. Figura 4. Tela com o projeto e iteração criados

Criando uma estória Como informado anteriormente, o XPlanner segue uma estrutura bem definida. Embora em um primeiro momento possa parecer enfadonho a criação de cada uma destas estruturas, ao final do processo as atividades ficarão bem mais fáceis de controlar. Uma estória pode ser vista, no XPlanner, como um caso de uso, um artefato de teste, ou qualquer outra macro atividade que possa ser “quebrada” em tarefas e que poderão ser acompanhadas pela equipe a qualquer momento. Para criarmos uma estória vamos clicar no link da iteração Modulo 1, que acabamos de criar e posteriormente em Criar Estória do Usuário. Será então exibida uma tela para que sejam informados os dados da nossa estória. Preencha os campos conforme abaixo: • Nome: Caso de Uso_UC01; • Cliente: Colaborador (este campo pode ficar sem preenchimento, mas para o nosso exemplo ele será preenchido com o usuário que cadastramos); • Track: Colaborador (este campo não é obrigatório e deve ser informado no caso de uma mesma pessoa assumir todas as tarefas que constarão na estória. Como em nosso exemplo estamos considerando apenas um usuário vamos preenchê-lo com ele); • Prioridade: 1 (este campo serve como uma forma de ordenação, caso haja outras estórias na mesma iteração, onde 0 é a prioridade mais alta); • Horas Estimadas: 3.0;

Figura 5. Tela apresentando a estória criada

Criando uma tarefa Estamos chegando à reta final de criação da estrutura requerida pelo XPlanner. Já temos projeto, iteração e estória criados, vamos então criar as tarefas que poderão ter seu andamento acompanhado pela equipe. Para definir uma tarefa será necessário informar as horas estimadas para sua conclusão e também quem será o responsável por ela. Para criarmos uma tarefa é preciso clicar no link da estória Caso de Uso_UC01 e posteriormente em Criar Tarefa. Será então

Edição 23 - Engenharia de Software Magazine

27


mostrada uma tela para informarmos os dados referentes à tarefa. Preencha os campos conforme abaixo: • Nome: Criar caso de uso; • Tipo: FTest (o preenchimento deste campo não exerce nenhuma influência sobre a ferramenta ou nas informações geradas por ela. Até o momento da escrita deste artigo não havia nenhum comentário na documentação do XPlanner que justificasse seu preenchimento. Entretanto, em nosso exemplo, optamos por preenchê-lo com a opção FTest). • Disposição: Planejada (esta opção indica que a tarefa que está sendo criada já havia sido planejada com antecedência para esta estória. Caso contrário, este campo deve ser preenchido com a opção Adicionada); • Responsável: Colaborador (indica quem realizará a tarefa, podendo ser alterado a qualquer momento); • Horas Estimadas: 3; • Descrição: Tarefa responsável pela elaboração do caso de uso 01. Depois de informados os dados da tarefa, clicamos no botão Criar. Neste momento será mostrada uma tela exibindo a tarefa com todas as informações cadastradas e pronta para ser iniciada (Figura 6).

Figura 7. Tela para informar o tempo de início da tarefa

Para que as informações extraídas do XPlanner sejam confiáveis, é importante que o usuário responsável pela tarefa tenha atenção durante a reportagem do tempo gasto para o desenvolvimento da mesma. Isto é, depois de iniciado o desenvolvimento da tarefa pelo usuário, toda vez que ele precisar fazer qualquer outra atividade, o tempo de desenvolvimento da tarefa deve ser parado. Para isso, é preciso clicar no link da tarefa Criar caso de uso e posteriormente no link Edit (logo abaixo do campo “Data/Hora Início”). Executadas estas duas ações, basta selecionarmos o botão Inserir Data/Hora e depois o link Atualizar para que o tempo decorrido para a tarefa seja parado. A Figura 8 mostra a tela com o tempo gasto no desenvolvimento da tarefa até então.

Figura 6. Tela exibindo toda estrutura do XPlanner

Utilizando o XPlanner Até o momento realizamos a instalação e configurações iniciais do XPlanner. A partir de agora focaremos no seu real objetivo: acompanhar as atividades que estão sendo desenvolvidas e proporcionar melhor planejamento. Assim, vamos começar clicando no link da tarefa Criar caso de uso e depois no link Editar Tempo. Neste momento será carregada uma tela para que seja informado o tempo inicial da atividade. Esta tela pode ser vista na Figura 7. Para que a tarefa seja iniciada é necessário clicar no botão Inserir Data/Hora. Com isso, o campo referente a data/hora iniciais será preenchido automaticamente. Em seguida basta clicar no botão Atualizar para que a data e a hora informadas sejam computadas.

28

Figura 8. Tela com o tempo gasto na tarefa até o momento que a mesma foi parada

Através da Figura 8 podemos perceber que há uma barra de progresso que mede o andamento da tarefa. Também é mostrado o tempo estimado para finalização da tarefa, o tempo gasto e o quanto falta para seu término. Para retornar à atividade devemos proceder exatamente da mesma forma que fizemos para interromper o andamento da mesma.

Engenharia de Software Magazine - Métricas e Planejamento com XPlanner


Planejamento e Gerência

Concluindo uma tarefa A qualquer momento uma tarefa pode ser concluída. Devemos observar que quando a tarefa é finalizada dentro do prazo estimado, a barra de progresso assume a cor verde. Da mesma forma, quando o tempo necessário para a finalização de uma tarefa se excede, a barra de progresso também assume a cor verde, contudo o tempo excedente é sinalizado com a cor vermelha. Para finalizar a tarefa utilizada no nosso exemplo, devemos clicar no link da tarefa Criar caso de uso e posteriormente no botão Concluir Tarefa. Perceba que a barra de progresso da tarefa assume a cor verde indicando que a tarefa foi finalizada, de acordo com a Figura 9. Figura 10. Tela mostrando tarefa com o tempo gasto maior que o estimado

Consultando Métricas

Figura 9. Tela com a tarefa concluída dentro do prazo estimado

Reativando uma tarefa Mesmo quando uma tarefa está concluída é possível reativá-la para dar continuidade à sua implementação. Para isso, basta clicar no link da tarefa Criar caso de uso e depois no botão Reativar Tarefa. Isto fará com que o responsável pela tarefa possa continuar registrando o tempo gasto para a conclusão da mesma.

No nosso exemplo temos apenas um projeto, uma iteração, uma estória, uma tarefa e um usuário. Entretanto, no mundo real existem vários projetos com muitos usuários, iterações e estórias distintas, onde cada estória possui uma ou mais tarefas. Tudo isso gera uma grande quantidade de informações, como: tempo gasto para executar determinada tarefa; comparação entre o tempo estimado e o tempo gasto para a conclusão da atividade; e tempo gasto por cada membro da equipe na realização das tarefas. O XPlanner consegue disponibilizar estas informações não só aos gestores dos projetos, mas também para toda a equipe, proporcionando planejamentos futuros mais precisos. A ferramenta permite também acompanhar o desenvolvimento das atividades identificando qual colaborador está próximo de finalizar uma tarefa e assim poder realocá-lo para outra atividade ou projeto. O acesso a estas informações é feito clicando-se no link da iteração Modulo 1 e em seguida no link Métricas. A tela com as métricas é exibida na Figura 11.

Tarefa excedendo o tempo estimado Muitas vezes, pode acontecer de uma determinada tarefa não ter sido corretamente planejada quanto ao seu tempo de conclusão. Caso isso aconteça, após a sua conclusão, a barra de progresso, que teve o tempo excedido, assumirá a cor vermelha para a fração de tempo excedida. Para que possamos visualizar esta situação, vamos, através do nosso exemplo, fazer com que a tarefa tenha seu tempo estimado excedido. Para isso, clicamos na tarefa Criar caso de uso e depois no link Edit. Neste momento serão mostradas as horas que já foram reportadas anteriormente. Vamos então, alterar a hora final de forma que o tempo extrapole o tempo estimado para a tarefa. Após realizar a alteração, basta clicar no botão Atualizar para que a tarefa seja exibida com o tempo gasto maior que o estimado, como apresenta a Figura 10.

Figura 11. Tela com as métricas da iteração

Edição 23 - Engenharia de Software Magazine

29


Links

O gerenciamento das atividades em uma fábrica de software é de fundamental importância. Muitas empresas públicas e privadas estão buscando alternativas eficazes e preferencialmente open source que atendam a este propósito. Este artigo apresentou uma introdução sobre o conceito de gerenciamento de atividades para o desenvolvimento de software, mas que também pode ser aplicado a qualquer natureza de projeto. Além disso, apresentamos como instalar o XPlanner assim como suas principais funcionalidades. Como já mencionado, qualquer ferramenta de acompanhamento das atividades de desenvolvimento de software pode auxiliar na organização e planejamento das tarefas, proporcionando maior visibilidade às pessoas que estão envolvidas. O XPlanner se mostra muito eficiente para este fim, e por isso deve ser considerado no momento de escolher ferramentas de gerenciamento com este propósito.

Tomcat - Servidor apache para páginas Web http://tomcat.apache.org/download-60.cgi

www.devmedia.com.br/esmag/feedback

30

sobre e s

A Engenharia de Software Magazine tem que ser feita ao seu gosto. Para isso, precisamos saber o que você, leitor, acha da revista! Dê seu voto sobre este artigo, através do link:

XPlanner - Ferramenta para planejamento e acompanhamento de tarefas http://sourceforge.net/projects/xplanner/files/xplanner/Version%200.6.1/xplanner_0.6.1.zip/ download MySQL – Banco de dados utilizado na instalação http://dev.mysql.com/downloads/mysql/5.0.html#win32. Interface gráfica do MySQL http://dev.mysql.com/get/Downloads/MySQLGUITools/mysql-gui-tools-5.0-r17-win32.msi/ from/pick#mirrors Referências [Codas 1987] CODAS, M.M.B. Gerência de Projetos - Uma reflexão histórica. Revista de Administração de Empresas, v. 27 (1). p. 33-37, jan/mar 1987. [Crawford 2000] CRAWFORD, J.K. Improving organizational productivity with a project office. PM Solutions, Jun. 2000 (Expert Series).

Feedback eu

edição ta

Dê seu feedback sobre esta edição!

Dê s

Conclusões

[Crawford 2001] CRAWFORD, J.K.The strategic project office. PM Solutions, 2001 (White Paper). [Dai & Weels 2004] DAI, C. X.,WELLS,W. G. An exploration of project management office features and their relationship to project performance. International Journal of Project Management Volume 22, Issue 7, October 2004, Pages 523-532.

Engenharia de Software Magazine - Métricas e Planejamento com XPlanner


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

SOA e seus Atributos de Qualidade Entenda os atributos de qualidade em uma Arquitetura Orientada a Serviços De que se trata o artigo? SOA é um tipo de arquitetura de software que possui características especiais. Neste intuito, este artigo apresenta uma discussão de alguns atributos de qualidade tais como desempenho, disponibilidade, interoperabilidade, confiabilidade, segurança, reusabilidade, entre outros, em um contexto de SOA.

Para que serve? Discutir alguns atributos de qualidade em um contexto de SOA, possibilitando aos arquitetos um melhor entendimento destes atributos para projetar uma SOA.

Em que situação o tema é útil? Jorge Dias Jr. josejorgejr@gmail.com www.jorgediasjr.com

Doutorando em Ciência da Computação (UFPE). Mestre em Ciência da Computação (UFPE). Graduado em Ciência da Computação (UFPB). Desenvolve pesquisas na área de SOA desde 2005. Possui vários artigos publicados em conferências nacionais e internacionais. Tem experiência como analista de TI na indústria, onde desenvolveu sistemas no âmbito do governo federal, além de ter atuado em vários projetos da iniciativa privada. Atualmente, é professor e pesquisador no Departamento de Ciências Exatas da UFPB, Campus IV.

E

scolher uma arquitetura que satisfaça os requisitos funcionais e os atributos de qualidade (requisitos não funcionais) é vital para o sucesso de um sistema. Além do mais, os requisitos que norteiam o projeto arquitetural são os não funcionais. Como foi visto no artigo, da edição 22, “Arquitetura Orientada a Serviços - Arquitetura Orientada a Serviços - Sobre o que você precisa refletir para adotá-la em um contexto empresarial”, uma das

Ao projetar uma SOA, é importante entender como seus atributos de qualidade impactam na arquitetura. Neste sentido, este artigo é útil para arquitetos que querem projetar uma SOA de sucesso.

atividades para se definir uma SOA é a identificação dos atributos de qualidade. Depois que os identificamos, precisamos criar uma arquitetura que atenda a estes atributos. Porém, para projetar uma arquitetura adequada, precisamos entender como estes atributos de qualidade se comportam em um contexto SOA.

Edição 23 - Engenharia de Software Magazine

31


Neste intuito, este artigo traz uma discussão sobre alguns atributos de qualidade no contexto de SOA, analisando quais suas implicações para criar projetos arquiteturais de sucesso. Este é um dos tópicos discutidos no livro “A Software Architecture Process for SOA Definition - Designing Service-Oriented Architectures in an Enterprise Context” [Dias, 2010].

A Figura 1 mostra os dois pontos de vistas arquiteturais dos Web Services ao mesmo tempo.

SOA e Web Services SOA é um tipo especial de arquitetura de software que pode ser implementada através de diferentes tecnologias, tais como Web Services, CORBA e Jini. Porém, atualmente, Web Services é a tecnologia preferida, pois ela é a que melhor atende aos objetivos de uma SOA. De acordo com a W3C, um Web Service é um sistema de software projetado para suportar interações máquina a máquina de maneira interoperável através de uma rede. Ela tem uma interface descrita em um formato processável por máquina (WSDL). Outros sistemas interagem com o Web Service através de uma especificação usando mensagens SOAP, geralmente através do protocolo HTTP. Em outras palavras, um Web Service é simplesmente uma aplicação que expõe uma funcionalidade acessível através de protocolos padronizados baseados em tecnologia Web que são aderentes aos padrões de Web Services. Arquitetura do Web Service Existem duas maneiras de visualizar a arquitetura Web Services [W3C, 2004]. A primeira é examinar os papéis de cada ator em um Web Service; e a segunda maneira é verificar a pilha de protocolos do Web Service. Web Service é uma tecnologia baseada em SOA. Por esta razão, os papéis são os mesmos de uma SOA: Fornecedor do serviço, consumidor do serviço e o registro de serviço. Primeiramente, o fornecedor desenvolve o serviço e o publica no registro de serviço. A partir de então, o consumidor é capaz de localizar o serviço no registro e invocar diretamente no fornecedor. Em relação à pilha de protocolo do Web Service, podemos dividi-la em quatro camadas distintas: • Transporte: é responsável por transportar mensagens entre as aplicações; • Mensagem XML: é responsável por codificar as mensagens em um formato que possa ser entendido pelas partes; • Descrição do serviço: é responsável por descrever as interfaces públicas para um Web Service específico; • Descobrimento do serviço: é responsável por centralizar os serviços em um registro comum e fornecer funcionalidades de publicação e busca. Cada camada compreende algumas tecnologias padrões. Na camada de descobrimento é utilizado UDDI; na camada de descrição é usado o WSDL; na camada de mensagem XML é usado o SOAP; e na camada de transporte é utilizado algum protocolo de transporte tal como HTTP, SMTP, FTP, entre outros.

32

Figura 1. Papéis e protocolos em Web Services

SOAP SOAP é um protocolo baseado em XML para troca de informações através de um ambiente computacional distribuído. Este protocolo define um modelo simples para empacotar mensagens codificadas em XML. O objetivo deste protocolo é resolver problemas de interoperabilidade de linguagem e plataforma. WSDL WSDL (Web Services Description Language) é uma especificação baseada em XML para descrever um Web Service. Assim como IDL de CORBA, WSDL foi criada para definir interfaces (assinaturas de métodos) e tipos de dados para serviços. Em outras palavras, WSDL representa um contrato entre o fornecedor e o consumidor do serviço. UDDI O projeto UDDI (Universal Description, Discovery and Integration) fornece um método padronizado para publicação e descobrimento de informações sobre Web Services. O UDDI possui informações dos fornecedores, dos serviços (através do WSDL). Estes fornecedores e serviços também podem ser categorizados para uma melhor organização.

SOA e seus atributos de qualidade Antes de projetarmos uma SOA, precisamos conhecer como os atributos de qualidade são afetados por este tipo de arquitetura. Neste intuito, este artigo discute alguns dos principais atributos de qualidade considerando as características de uma SOA. Interoperabilidade Interoperabilidade refere-se à habilidade que uma coleção de entidades comunicantes tem de compartilhar e operar de acordo com uma semântica operacional acordada. Este atributo de qualidade está relacionado às plataformas, linguagens e protocolos que o serviço pode suportar. Sistemas distribuídos tem usado diferentes tecnologias com o objetivo de fornecer esta característica, como por exemplo RMI e sockets para comunicação. Entretanto, estas tecnologias não

Engenharia de Software Magazine - SOA e seus Atributos de Qualidade


ARQUITETU R A

fornecem uma interoperabilidade efetiva em um contexto de larga escala uma vez que eles não utilizam protocolos universais. Por outro lado, a tecnologia Web Services fornece o SOAP, que permite a comunicação em ambientes heterogêneos. Desta maneira, qualquer sistema que necessita desenvolver uma camada de comunicação interoperável, em qualquer linguagem de programação, precisa apenas implementar a especificação SOAP. Entretanto, as plataformas de desenvolvimento em Web Services não implementam os mesmos padrões e as mesmas versões, então interoperabilidade pode não ser uma realidade na prática como é na teoria [O’Brien et al., 2005]. Neste sentido, a Web Services Interoperability Organization (WS-I) foi criada em 2002 para promover a interoperabilidade entre a pilha de especificações de Web Services. Desempenho Desempenho pode ter diferentes significados em diferentes contextos. Em geral, ela está relacionada com tempo de reposta (quanto tempo o sistema leva para processar uma requisição), throughput (quantas requisições ao todo pode ser processada por unidade de tempo), ou oportunidade (habilidade de conhecer deadlines, isto é, processar uma requisição em um tempo aceitável e determinístico). Este atributo de qualidade é um dos maiores problemas em SOA por algumas razões. Primeiro, SOA envolve computação distribuída, isto é, serviços estão distribuídos em diferentes máquinas. Além disso, os serviços geralmente estão na Internet, onde não há garantia determinística de latência. Segundo, é normal ter muitos níveis intermediários na arquitetura. Um exemplo disso é o diretório de serviço em que o consumidor primeiramente precisa achar o serviço e depois invocá-lo no fornecedor. Este processo aumenta o tempo total necessário para executar a transação. Terceiro, o uso de formato de mensagens padronizadas, como XML, aumenta o tempo necessário para processar uma requisição. Apesar de possibilitar a interoperabilidade, mensagens XML podem levar 10 a 20 vezes mais tempo para serem processadas do que representações binárias. O processamento de um XML requer pelo menos três atividades: parsing, validação e transformação. Estas atividades produzem um maior overhead no desempenho. Algumas técnicas e boas práticas podem ser aplicadas a fim de aumentar o desempenho em um contexto SOA. O principal deles é escolher o melhor nível de granularidade dos serviços. Mensagens com granularidade fina resultam no aumento do tráfico na rede e tornam o tratamento de erros mais difícil. Neste sentido, o arquiteto deve projetar interfaces com granularidade grossa a fim de minimizar o tráfico de mensagens na rede. Outro princípio da orientação a serviço é o fato dos serviços serem stateless, ou seja, não armazenar o estado deles. Isto pode reduzir a quantidade de informação transferida entre os componentes na rede. Replicação é um outro mecanismo para aumentar o desempenho. Replicação é importante quando o sistema precisa de escala em número. Neste caso, o desempenho pode ser melhorado replicando o servidor, dividindo o processamento

das requisições dos clientes em vários servidores, realizando balanceamento de carga. Segurança Por diversas vezes é necessário garantir a segurança dos dados que são transmitidos na rede. Diferentes mecanismos e políticas de segurança podem ser definidos para fornecer esta segurança. Soluções de segurança em Web Services podem ser implementadas em vários níveis, incluindo a camada de transporte e a camada de mensagem. A escolha destas soluções depende do nível de interoperabilidade que você quer prover na sua SOA. No contexto de Web Services, em que o protocolo HTTP é largamente utilizado, é necessário garantir um canal seguro entre o consumidor e o fornecedor do serviço. Neste caso, pode ser utilizado o protocolo seguro HTTPS, que é uma extensão do http que usa segurança no nível de transporte colocando no seu topo o SSL. Porém, esta abordagem possui duas limitações. A primeira é que apenas a conexão é segura, e não o dado em si. Isto significa que enquanto os dados são transmitidos, eles estarão seguros, mas no ponto que ele chega ao destino ou a um intermediário, a informação não está protegida. Para SOA, proteção no destino é vital porque os dados podem ser processados por muitos intermediários. Outra limitação é que é impossível controlar seletivamente qual parte da informação deve ser criptografada e quem deve ser autorizado a vê-la. Uma outra abordagem de segurança em Web Services é no nível de mensagem. Nesta abordagem, mensagens trocadas entre consumidor e fornecedor podem ser criptografadas para preservar confidencialidade. Por exemplo, a mensagem SOAP, seu cabeçalho, ou corpo, ou algum outro elemento pode ser criptografado. Comparado com a segurança no nível de transporte, incorporar segurança em mensagens SOAP fornece importantes vantagens na arquitetura Web Services. Primeiro, a natureza interoperável do SOAP de poder usar diferentes protocolos de transporte, incluindo HTTP, SMTP, entre outros. Segundo, a mensagem estará segura mesmo se ela passar por vários pontos intermediários. Em 2002, grandes empresas como IBM, Microsoft e Verisign, propuseram o Web Services Security (WS-Security) [OASIS, 2004] como um modelo de segurança para Web Services. O WSSecurity define um conjunto de extensões padronizadas para SOAP que pode ser usada para fornecer mensagens contendo integridade e confidencialidade. Ele acomoda uma variedade de modelos de segurança e tecnologias de criptografia e também é extensível para suportar diferentes formatos de token de segurança. O WS-Security inclui alguns padrões disponíveis pela W3C: XML-Signature [XMLSig, 2005] e XML-Encryption [XMLEnc, 2005], a fim de fornecer, respectivamente, integridade e autenticação, e criptografia dos dados. Confiabilidade Em um contexto de sistemas distribuídos, é necessário tentar garantir que um serviço específico será executado pelo fornecedor. Na pior das hipóteses, o consumidor deverá ser notificado se um serviço não for executado com sucesso. Em

Edição 23 - Engenharia de Software Magazine

33


outras palavras, confiabilidade é a habilidade de um sistema se manter operando todo o tempo que for necessário. Na literatura, existem os seguintes tipos de confiabilidade: • Best effort (melhor esforço): é uma tentativa de melhor esforço. O consumidor do serviço não tem nenhuma garantia da execução de uma requisição; • At-most-one (no máximo uma vez): os consumidores têm a garantia que o serviço será executado no máximo uma vez, mas pode acontecer de não ser executado. Porém, caso não seja, o consumidor é notificado; • Least-once (pelo menos uma vez): são garantidas que as requisições são executadas, possivelmente mais do que uma vez; • Exactly-once (exatamente uma vez): é o maior grau de confiabilidade que existe, onde são garantidas que as requisições serão executadas uma vez e apenas uma vez. Vários aspectos de confiabilidade são importantes em SOA, particularmente a confiabilidade de mensagens que são trocadas entre a aplicação e os serviços, e a confiabilidade dos próprios serviços. Aplicações desenvolvidas por diferentes organizações podem ter diferentes requisitos de confiabilidade para o mesmo conjunto de serviços. A confiabilidade em Web Services pode ser relacionada ao protocolo de transporte que está sendo utilizado na comunicação. Por exemplo, um Web Service que usa o protocolo HTTP terá um mecanismo de entrega baseado em “melhor esforço”, pois essa é uma característica do protocolo. Uma outra abordagem é tentar garantir uma maior confiabilidade usando mensagens assíncronas ou usar protocolos de transportes confiáveis como, por exemplo, REST e HTTPR. Existem duas especificações – WS-Reliability e WS-ReliableMessaging – que possibilitam a tentativa de garantir troca de mensagens confiáveis e de maneira interoperável. WS-ReliableMessaging fornece um framework capaz de garantir que fornecedores de serviço sejam notificados com sucesso ou falha sobre as transmissões de mensagens. Transparência de Localização Um objetivo importante de um sistema distribuído é esconder o fato de que seus processos e recursos estão fisicamente distribuídos em diversos computadores. Então, dizemos que um sistema distribuído é transparente quando ele consegue apresentar aos seus usuários a idéia de ser um único computador. Em um contexto de SOA, os serviços devem ser transparentes de localização. Em outras palavras, eles devem ser localizados em qualquer lugar e então ser usados por outros serviços ou aplicações dinamicamente. Transparência de localização é uma característica chave em SOA. SOA fornece um mecanismo para transparência de localização utilizando o registro de serviço. Esta transparência de localização é possível devido à separação entre a interface e a implementação do serviço. Em Web Services, como já foi explicado, o UDDI faz este papel de registro de serviço. Então, consumidores de serviço não precisam conhecer a localização física do serviço até o localizarem no registro.

34

Esta característica afeta de maneira positiva e negativa o atributo de desempenho. Negativamente porque aumenta o tempo total para um serviço ser executado, uma vez que ele precisa primeiramente ser localizado antes de ser executado. Positivamente porque um consumidor pode escolher um fornecedor que tenha um histórico de tempo de resposta melhor. Disponibilidade Disponibilidade de um sistema é a probabilidade que ele tem de estar operacional sempre que necessário. Em outras palavras, disponibilidade indica o período de tempo que um serviço está disponível para ser usado. Disponibilidade de serviços é uma preocupação constante em ambientes SOA, tanto do ponto de vista do consumidor como do fornecedor. Se alguns serviços se tornarem indisponíveis para o consumidor, ele poderá ter prejuízos na execução dos seus processos. Além disso, a reputação do fornecedor também será afetada negativamente, considerando fornecedores externos. Fornecedores de serviço geralmente concordam em fornecer aos consumidores um conjunto de serviços com um SLA (Service-Level Agreement), que especifica as obrigações das partes envolvidas. Um SLA também especifica as medidas a serem consideradas em caso de desvio ou falha, tal como disponibilidade e tempo de resposta. Em Web Services, por exemplo, existe uma especificação chamada WSLA [IBM, 2003] que contém três seções: uma seção descrevendo as partes, uma seção contendo um ou mais definições de serviço e uma seção definindo as obrigações das partes. Outra maneira de melhorar a disponibilidade é implementar um mecanismo de replicação. A replicação oferece maior disponibilidade porque os serviços podem ser executados por outro servidor quando o primeiro ficar indisponível. Escalabilidade Um dos maiores problemas de escalabilidade em SOA é a habilidade de um servidor conseguir se acomodar com o aumento do número de consumidores sem degradar o desempenho. Porém, são poucos os trabalhos encontrados na literatura para resolver este problema relacionado a SOA. Alguns mecanismos para aumentar a escalabilidade de um fornecedor inclui: • Escala horizontal: adicionar novo hardware, fazendo balanceamento de carga; • Escala vertical: atualizar o hardware, aumentando a capacidade de recursos dele. Um problema de escalabilidade em Web Services é o fato do UDDI ser centralizado. Esta característica diminui a escalabilidade já que o único servidor pode ter problemas para processar todas as requisições. Por este motivo, pesquisadores investigam maneiras de utilizar registros distribuídos. Um destes esforços é o uso de Grid computing e P2P como registro de serviços. Estas tecnologias permitem a descentralização do sistema de registro, permitindo a escalabilidade na busca de serviços.

Engenharia de Software Magazine - SOA e seus Atributos de Qualidade


ARQUITETU R A

Considerações Finais

Dê seu feedback sobre esta edição! A Engenharia de Software Magazine tem que ser feita ao seu gosto. Para isso, precisamos saber o que você, leitor, acha da revista! Dê seu voto sobre este artigo, através do link:

Dê s

SOA é um tipo diferenciado de arquitetura de software que possui características especiais. Neste sentido, este artigo discutiu alguns atributos de qualidade em um contexto de SOA que devem ser considerados e pensados na hora de projetá-la. Esta análise sobre os atributos de qualidade pode ajudar os arquitetos na escolha de soluções para projetar descrições arquiteturais SOA. Feedback eu

www.devmedia.com.br/esmag/feedback

Referências [Dias, 2010] Dias, Jorge. A Software Architecture Process for SOA Definition - Designing ServiceOriented Architectures in an Enterprise Context. LAP Lambert Academic Publishing. Fevereiro, 2010.

[IBM, 2003] IBM Corporation. Web Service Level Agreement (WSLA) Language Specification, Available in http://www.research.ibm.com/wsla/WSLASpecV1-20030128.pdf, 2003.

[Ambrosi et al., 2005] Ambrosi, E., Bianchi, M., Gaibisso, C., Gam-Bosi, G. And Lombardi, F. Extending the UDDI API for service instance ranking, In proceedings of the International Symposium on Web Services (ISWS). Las Vegas, Nevada, USA, 2005, pp. 104-110.

[InformationWeek, 2008] Smith Roger. A simpler approach to SOA (2008). Disponível em http:// www.informationweek.com/news/software/soa/showArticle.jhtml?articleID=209904293 [Josuttis, 2007] Josuttis, N. SOA in Practice – The Art of Distributed System Design. O’Reilly, 2007.

[OASIS, 2004] OASIS. Web Services Security: SOAP Message Security 1.0, Available in http://docs. oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf, 2004.

[Erl, 2008] Erl, Thomas. SOA – Princípios de design de serviços. Prentice Hall, 2008.

[O’Brien et al.,2007] O’Brien,L.,Bass,L.,Merson,P.Quality Attributes for Service-Oriented Architectures, Proceedings of the International Workshop on Systems Development in the SOA Environments. IEEE International Conference on Software Engineering. Washington, DC, USA, 2007.

[Davis, 2009] Davis, Jeff. Open Source SOA. Manning, 2009.

[XMLEnc, 2005] W3C World Wide Web Consortium. XML Encryption WG, Available in http://www. w3.org/Encryption/2001/, Consulted in Jun 2005.

[Dias, 2009] Dias, J. J.; Almeida, E. S.; Meira, S. R. L. A Systematic SOA-based Architecture Process, 21st International Conference on Software Engineering and Knowledge Engineering (SEKE), Service Oriented Architecture Track, Boston, U.S., 2009.

[XMLSig, 2005] W3C World Wide Web Consortium. XML Signature WG, http://www.w3.org/ Signature/, Consulted in Jun 2005. [W3C, 2004] W3C World Wide Web Consortium. Web Services Architecture, Available in http:// www.w3.org/TR/ws-arch/, 2004.

[Rademakers, 2009] Rademakers, T., Dirksen, J. Open Source ESBs in Action. Manning, 2009.

[InfoQ, 2009] Artigo da InfoQ. Como Alinhar Processos de TI e Governança SOA para suportar Iniciativas BPM? (2009) Disponível em http://www.infoq.com/br/news/2009/02/process-it-soagovernance.

Edição 23 - Engenharia de Software Magazine

35

sobre e s

Testabilidade O termo testabilidade refere-se ao grau de facilidade que um sistema pode ser testado. O teste de serviços pelos desenvolvedores tem similaridades com o os testes de componentes de software. Porém, alguns aspectos podem dificultar o teste de um sistema SOA: • O testador pode não ter acesso ao código fonte dos serviços, uma vez que o serviço pode estar rodando em entidades externas. Ele tem apenas a descrição da interface do serviço. Neste caso, apenas teste de caixa preta pode ser realizado; • Serviços podem ser compostos por outros serviços, rodando em várias máquinas com diferentes contextos. Além disso, estas máquinas podem estar na Internet; • Geralmente, em soluções Web Services, as ferramentas de desenvolvimento tentam proteger os desenvolvedores da tarefa de lidar com os padrões baseados em XML do Web Services (WSDL e SOAP). Porém, os desenvolvedores precisam entender a estrutura do XML que é usada para realizar alguns testes e resolver alguns problemas.

Reusabilidade Serviços podem significar um importante papel no aumento da reusabilidade de software dentro das organizações. Serviços podem envolver aplicações legadas, banco de dados, objetos, componentes e expor estes como serviços reutilizáveis. O sucesso da reusabilidade depende de vários fatores: interoperabilidade, modularização, registro de serviços, entre outros. Para reutilizar serviços, devem existir maneiras eficientes de buscar e recuperá-los. Portanto, é importante ter um repositório de serviços bem organizado contendo os serviços. Em Web Services, o UDDI pode ser este registro, porém extensões podem ser adicionadas a fim de melhorar a reusabilidade, por exemplo, um esquema de ranking de reuso dos serviços [Ambrosi et al., 2005]. Entretanto, facilitar o acesso a serviços existentes não garantem o sucesso da reusabilidade. Serviços reutilizáveis devem ser cuidadosamente especificados, projetados, implementados e documentados [Dias, 2010].

edição ta

Manutenibilidade Manutenibilidade é a habilidade de realizar mudanças em um sistema de maneira mais rápida e com menor custo. O grau de acoplamento de um sistema afeta diretamente sua manutenibilidade. Se o sistema SOA tiver um alto acoplamento, uma mudança em um serviço irá requerer também mudanças nos consumidores. Portanto, é importante que os serviços sejam bem projetados de maneira que sejam fracamente acoplados, aumentando sua independência. A idéia é que os serviços devam ser dependentes apenas das interfaces de outros serviços e não de suas implementações.


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

Análise Orientada a Objetos Essencial para Entendimento e Modelagem de Sistemas De que se trata o artigo? Apresenta um conjunto de princípios de análise e projeto que podem subsidiar decisões de modelagem e projeto de sistemas de software.

Para que serve?

Antonio Mendes da Silva Filho antoniom.silvafilho@gmail.com

Professor e consultor em área de tecnologia da informação e comunicação com mais de 20 anos de experiência profissional, é autor do livros Arquitetura de Software e Programando com XML, ambos pela Editora Campus/Elsevier, tem mais de 30 artigos publicados em eventos nacionais e internacionais, colunista para Ciência e Tecnologia pela Revista Espaço Acadêmico com mais de 80 artigos publicados, tendo feitos palestras em eventos nacionais e exterior. Foi Professor Visitante da University of Texas at Dallas e da University of Ottawa. Formado em Engenharia Elétrica pela Universidade de Pernambuco, com Mestrado em Engenharia Elétrica pela Universidade Federal da Paraíba (Campina Grande), Mestrado em Engenharia da Computação pela University of Waterloo e Doutor em Ciência da Computação pela Univesidade Federal de Pernambuco.

36

S

e você é um engenheiro de software cujo papel é entender, analisar e desenvolver sistemas, você precisa participar de algumas decisões de projeto como selecionar a técnica de análise e modelagem, linguagem de programação e ambiente de desenvolvimento adequados. Neste cenário, é importante refletir sobre a ordem em que suas atividades são executadas. Por exemplo, antes de escolher uma linguagem de programação e ambiente de desenvolvimento, você deve definir a estratégia de análise e modelagem de sistemas. Além disso, observa-se que os sistemas de software encontram-se, quase permanentemente, sendo modificados. Essas mudanças ocorrem devido à necessidade de corrigir erros existentes no

Engenharia de Software Magazine - Análise Orientada a Objetos

Entender o papel da análise orientada a objetos dentro do processo de desenvolvimento de software, visando a identificação de informações necessárias às decisões de projeto e modelagem de um sistema.

Em que situação o tema é útil? Identificação de informações que apóiam as atividades de modelagem, análise e projeto de sistemas de software.

software ou de adicionar novos recursos e funcionalidades. Em razão disto, você pode questionar: Por que modelar um sistema? Porque à medida que o sistema cresce, também cresce o código, tornando mais difícil seu desenvolvimento e mais ainda sua manutenção. É mais fácil raciocinar e fazer a manutenção em um sistema para o qual você tem um modelo. Para tanto, a modelagem é essencial no


PROJETO

desenvolvimento de qualquer sistema. A análise orientada a objetos serve para ajudar no entendimento e decisões de projeto, tema esse tratado neste artigo.

Análise Orientada a Objetos

A análise orientada a objetos é uma atividade essencial num processo de desenvolvimento de software. Seu objetivo principal é identificar objetos, atributos desses objetos e as operações que atuam sobre eles. Os atributos são características ou propriedades dos objetos, enquanto que as operações são métodos ou funções que atuam sobre os objetos e afetam o comportamento dos mesmos. Todavia, antes de iniciar a modelagem com uma linguagem como a UML, você deve proceder a análise orientada a objetos, que compreende os seguintes passos: 1. Entender o problema do cliente e identificar e documentar os requisitos; 2. Descrever os requisitos funcionais usando diagramas de casos de uso da UML; 3. Identificar objetos e classes a partir das informações no documento de requisitos, descrição do sistema e especificação de casos de uso; 4. Identificar relacionamentos entre as classes do item 3; 5. Identificar atributos e operações (para as classes identificadas no item 3); 6. Elaborar e analisar os diagramas de classes de sistema, adicionando e/ou corrigindo atributos e operações, bem como revisando os relacionamentos identificados. O primeiro passo, a partir do momento em que você já fez o levantamento de requisitos junto ao cliente, é identificar objetos e classes. Nesse momento, você é o projetista e, portanto, deve examinar a declaração do problema procurando identificar objetos, os quais podem ser: • Entidades externas como, por exemplo, outros sistemas (subsistema de controle de estoque); • Coisas (livros, cadeiras, mesas, canetas); • Ocorrências ou eventos (transação bancária, compra com cartão de crédito, requisição de serviços); • Papéis (funções) desempenhados por alguém num sistema (professor, médico); • Unidades de uma instituição (departamento, divisão, diretoria); • Lugares (laboratório, salas de aula, estantes, blocos). De um modo geral, você deve procurar pelos elementos acima. Outra dica é procurar identificar substantivos na descrição do sistema e/ou documentos de requisitos. No momento de buscar identificar candidatos a classes, você pode responder a questões como: • Para as classes identificadas, existem operações que possam mudar o valor dos atributos? • O objeto pode ser representado como atributo de outro objeto? • É possível definir um conjunto de atributos que se aplica a todas as ocorrências do objeto?

Cabe ressaltar que os objetos identificados não devem ser confundidos ou tratados como operações. Note que pode tanto existir um objeto que representa uma transação quanto pode haver as operações transferir, sacar e consultar. Note que a análise é essencial para criação de um modelo de classes do sistema a partir dos casos de uso (da etapa de levantamento de requisitos). O objetivo da análise é identificar as classes necessárias para implementar os casos de uso do sistema, como discutido adiante. Um processo de desenvolvimento de software compreende um conjunto de atividades, dentre elas, levantamento de requisitos, análise e projeto como etapas iniciais do processo de desenvolvimento de software. Inicialmente, você deve entender o problema do cliente para documentar o conjunto de requisitos. Após isso, você começa a etapa de análise de requisitos fazendo uso das informações do documento de requisitos e especificação de casos de uso. Com isso, você deverá gerar um primeiro modelo do sistema a partir dessas informações. Este modelo é chamado de modelo de análise. A análise orientada a objetos utiliza as informações dos casos de uso. Em outras palavras, os casos de uso servem de guia para a etapa de análise. É importante você observar que a análise produz uma visão estática do sistema, que é o diagrama de classes. Além disso, cada caso de uso deve ser analisado isoladamente, identificando-se as classes que implementam aquela funcionalidade. Nesse sentido, a análise orientada a objetos ajuda você a encontrar as classes iniciais do sistema e distribuir o comportamento dos casos de uso entre elas. Vale lembrar que cada classe tem suas responsabilidades, atributos e associações. Adicionalmente, você precisará identificar persistências e classes para cada caso de uso, bem como distribuir comportamento entre elas, descrever responsabilidades e descrever atributos e associações, como apresentado adiante. Entretanto, identificar os elementos da UML e conhecer os diagramas não é tudo. Você também precisa saber como identificar os componentes essenciais desses diagramas e saber como relacionar uns aos outros. Nesse sentido, é de suma importância conhecer os passos do processo de análise para que você possa adequadamente explorar as informações do sistema (sob análise) e identificar os componentes da UML que melhor representam eles. É importante você observar que conhecer uma linguagem (como a UML) não implica na habilidade de saber usá-la para produzir artefatos úteis. Mas, por quê? Porque você precisa se preocupar com a estrutura do software. A estrutura do software deve ser intrinsecamente mais fácil de compreender, além de ser bem documentado, permitindo ser compreendido em nível global ou em detalhes. Pensar e projetar um software dessa forma é torná-lo mais fácil de ser modificado e, portanto, quando alguma de suas características é mudada, ele continua funcionando. Perceba que seu papel como projetista vai muito além do de apenas conhecer a UML, você também precisa saber fazer a

Edição 23 - Engenharia de Software Magazine

37


análise orientada a objetos e utilizar ambos os conhecimentos para fazer a modelagem de um sistema. Dentro desse contexto, o objetivo principal deste artigo é tratar essas questões. A próxima seção dá continuidade no estudo da análise orientada a objetos.

Importância da Análise Orientada a Objetos O que é a análise? A análise visa investigar e resolver um problema. O objetivo da análise é levar o analista ou projetista a investigar e a descobrir como tratar o problema que ele tem em mãos. Perceba que quando você finalizar a análise, você terá uma compreensão completa do problema (muitas vezes denominado de ‘enunciado do problema’) e, portanto, o projeto será a sua solução. Note que a qualidade do processo de análise é de suma importância porque um erro de concepção (durante o levantamento de requisitos) resolvido na fase de análise tem um custo. Entretanto, a descoberta de erros na fase de projeto tem um custo maior, sendo maior ainda na fase de implementação. E se você o descobre apenas na fase de implantação do sistema, esse custo será bastante elevado. Dessa forma, você deve considerar o conjunto de princípios de análise e projeto abaixo: 1. Usar abstração no processo de levantamento e análise – Você deve identificar os aspectos importantes do problema sob análise (ou sistema a ser desenvolvido) e ignorar os detalhes. Por exemplo, engenheiros usam equações e modelos como recursos para abstrair-se da complexidade de problemas. Isto torna mais fácil o raciocínio. 2. Antecipar modificações no sistema (a ser desenvolvido) – Você precisa considerar que um sistema de software evolui, ou seja, novas funcionalidades serão adicionadas e outras modificadas. Portanto, você deve levar em conta essa necessidade antecipando futuras mudanças. 3. Generalizar o modelo proposto – Seu modelo deve resolver o problema que você tem em mãos, mas um bom projetista não pensa em encontrar uma solução única para um problema. Você deve considerar uma solução mais geral que permita a você reutilizar seu modelo (ou solução) em outros problemas. 4. Considerar o processo de análise incremental – O processo de desenvolvimento, e também de análise, é incremental, evoluindo aos passos. Dessa forma, você deve, no início da análise, investigar as principais funcionalidades e à medida que você tem maior compreensão do problema (ou sistema a ser desenvolvido), você enriquece o modelo (da análise) adicionando detalhes e tornando o modelo mais completo. A análise é uma etapa essencial para criação de um modelo de classes do sistema a partir da especificação de casos de uso. O principal objetivo da análise é identificar as classes necessárias para implementar os casos de uso (ou funcionalidades) do sistema. Você deve ter em mente que essa sequência de passos não é uma regra, mas sim uma orientação para você (projetista). A apresentação de um exemplo englobando diagramas da UML

38

Engenharia de Software Magazine - Análise Orientada a Objetos

é feita na seção seguinte. Antes disso, contudo, é importante você observar que, para cada caso de uso, você deve identificar a classe (ou classes) que implementa aquele caso de uso (isto é, funcionalidade). Dentro desse contexto, no terceiro passo da análise, você precisa dos tipos (ou estereótipos) de classes: fronteira, entidade e controle. Esses tipos ou estereótipos de classes são identificadas separadamente para cada um dos casos de uso que você tenha no seu sistema. A classe de fronteira é uma classe que fornece uma área intermediária para comunicação entre um sistema e atores externos (usuário ou qualquer outro subsistema). Note que esse tipo de classe serve para modelar a interação entre um ator e o sistema. Neste caso, você deve criar uma classe de fronteira (a qual possui o estereótipo boundary) que suporte cada interação entre um ator e um caso de uso. A classe de entidade é identificada a partir da sequência de eventos do caso de uso, servindo para modelar a informação manipulada pelo sistema. Pode ser persistente ou não. Quando você identifica uma classe de entidade, esta classe possui o estereótipo entity. A classe de controle serve para controlar a sequência de execução do caso de uso. Geralmente, você deve criar uma classe de controle para cada caso de uso, e esta classe terá o estereótipo control. Serve de interface entre uma classe de fronteira e uma classe de entidade, além de controlar o comportamento do caso de uso. Observe que a análise ajuda você a obter a visão ‘estática’ do sistema, onde cada caso de uso deve ser analisado isoladamente. Seu papel como projetista (ou analista) é de encontrar as classes iniciais do sistema e distribuir o comportamento dos casos de uso entre elas. Cabe destacar ainda que, para cada caso de uso, você deve encontrar classes de análise e identificar persistências. Juntamente com isso, para cada classe, você precisa distribuir o comportamento entre elas, bem como descrever atributos e associações dessas classes. Para entender melhor, vamos analisar um exemplo.

Exemplo de Modelagem A modelagem com a UML deve ser feita por um analista de sistemas ou engenheiro de software. Um engenheiro de software é um profissional que deve ter a habilidade de antecipar e gerenciar mudanças de requisitos de um produto. Além disso, ele precisa saber se expressar e comunicar bem a fim de capturar e registrar adequadamente o documento de requisitos. Os principais problemas num desenvolvimento de um sistema de software decorrem do entendimento errado entre engenheiro de software (produtor) e usuário (consumidor), onde o primeiro é responsável em apresentar o documento de requisitos e projeto (modelagem) do sistema. A modelagem e o documento de requisitos de um sistema de software devem ser claros, consistentes e completos, porque esses documentos servirão de referência aos desenvolvedores, gerente de projeto, engenheiros de software (responsáveis pelos testes e manutenção do sistema), além de servir de base


PROJETO

para definir o escopo das funcionalidades a serem registradas num contrato. Perceba que os requisitos compreendem o cerne de qualquer produto e mudanças sobre eles podem ocorrer ao longo do ciclo de vida de um software. É importante ressaltar que desenvolver um sistema de software requer um processo (como o RUP), o qual informa um conjunto de atividades a serem realizadas, quem as executam, quais artefatos de entrada são necessários e quais artefatos de saída são produzidos. Nesse sentido, detectar erros ou quaisquer outros problemas como, por exemplo, inconsistência e falta de clareza, é de suma importância de modo a tornar o processo mais efetivo sob ponto de vista de custo. Você também deve perceber que envolver o usuário no processo é determinante para o sucesso do produto e do processo. Dentro deste contexto, entender adequadamente o requisito é essencial e essa é tarefa do engenheiro de software. Um requisito compreende uma característica ou funcionalidade que o sistema deve possuir ou uma restrição que ele (sistema) deve satisfazer para atender uma necessidade do usuário. Dessa forma, você, ao desempenhar o papel de engenheiro de requisitos (ou analista), deve executar duas atividades essenciais para a elaboração do documento de requisitos e modelagem de um sistema: • Elicitação de requisitos – atividade na qual os requisitos do sistema a ser desenvolvido são levantados; • Análise de requisitos – atividade na qual os requisitos são analisados e confirmados pelos principais interessados do projeto (isto é, os stakeholders) que incluem cliente, usuário final, gerente de projetos, dentre outros. Considera-se ainda que a elicitação de requisitos objetiva definir características do sistema sob a perspectiva do cliente, enquanto que a análise de requisitos visa obter a especificação de requisitos, do ponto de vista técnico, conforme entendimento dos desenvolvedores. Durante a realização dessas atividades, você (como engenheiro de software) deve estar preocupado em levantar, entender, analisar, documentar os requisitos e fazer a modelagem do sistema. Para tanto, deve se concentrar nas características do sistema e atributos de qualidade, e não em como obtê-los. Aqui, é preciso identificar quais requisitos fazem parte ou não do escopo do sistema a ser desenvolvido, ou em outras palavras, entender a interface do sistema considerado e o ambiente externo. É importante ressaltar a necessidade de definir o ‘limite’, ou também denominado escopo, do sistema a fim de tratar os requisitos funcionais e não funcionais do sistema. Entretanto, quando você estiver fazendo levantamento e análise de requisitos, você deve levar em consideração os diferentes pontos de vistas dos stakeholders de modo que os documentos resultantes (especificação de requisitos e modelagem) possam comunicar adequadamente o conjunto de requisitos do sistema a ser construído. Para iniciar a modelagem, precisamos da descrição do sistema a ser desenvolvido. Essa descrição informa a você, analista ou

engenheiro de software, os principais elementos do sistema e que tipo de problema você deve solucionar. O que você deve fazer agora? A primeira coisa é obter a descrição do sistema. Para entender, considere o seguinte exemplo: Uma escola está interessada em automatizar o processo de cadastro e empréstimo de livros da biblioteca. O processo que hoje é feito manualmente exige que os funcionários do atendimento façam o cadastro de usuários em fichas de papel, similarmente ao que é feito no cadastro do acervo de livros. Também, toda vez que o aluno necessita fazer uma consulta de livro, dos livros que esse usuário possui emprestado, empréstimo de livros, devolução de livros ou renovação, então, em todas essas ocasiões o usuário deve se dirigir ao balcão de atendimento, procurando pelo funcionário da biblioteca, no qual tudo é registrado em fichas de papel (para usuários e livros). Após automatizar esse sistema, além de todas as funcionalidades descritas acima, o sistema deverá também possibilitar que os usuários renovem empréstimos de livros via Internet. Tudo isso visa prover melhor atendimento e agilidade, resultando em maior satisfação para os usuários. Com essa descrição de um sistema exemplo, seu papel e primeira atividade é identificar atores e casos de uso. Lembre-se de que os casos de uso especificam o comportamento de um sistema, ou parte de um sistema. Trata-se de uma sequência de ações que geram algum resultado. Além disso, o ator é a entidade que interage com o caso de uso. Neste caso, o ator pode ser um ser humano, um subsistema ou algum dispositivo. Cabe ainda destacar a necessidade de você também identificar as associações com atores que se comunicam com o caso de uso (enviando e recebendo mensagens). Para a descrição do sistema acima, você deve buscar inicialmente por possíveis atores como aluno e funcionário. Já os casos de uso se referem a funcionalidades do sistema como cadastro de usuários, consulta de livros, empréstimo de livros, dentre outros requisitos funcionais. Isso é capturado no diagrama mostrado na Figura 1.

Figura 1. Exemplo de diagrama de caso de uso

Agora, para cada caso de uso, você deve fazer a especificação dos fluxos principal (FP) e fluxo excepcional (FE), além de descrever as pré-condições, pós-condições, e ponto de extensão (se houver). De um modo geral, a especificação de casos de uso compreende a descrição dos casos de uso seguindo

Edição 23 - Engenharia de Software Magazine

39


a um template, ou modelo, que contém um conjunto de itens como descrito abaixo. Note que essa relação de itens não tem o objetivo de ser completa. 1. Nome do caso de uso 2. Descrição ou sumário do caso de uso 3. Fluxo principal (ou básico) de eventos 4. Fluxo excepcional (ou alternativo) 5. Pré-condição 6. Pós-condição 7. Ponto de extensão 8. Autor 9. Data Considerando o diagrama de caso de uso da Figura 1, se você precisa fazer a descrição de um caso de uso (ou use case UC001, ou seja, o primeiro caso de uso) como ValidarUsuário, então você deve seguir ao modelo apresentado abaixo: Nome: [UC001] ValidarUsuário Pré-condição: o usuário deve ter sido cadastrado na biblioteca Fluxo de eventos principal (FP): 1. O sistema espera pela entrada de dados do usuário 2. O usuário fornece login e respectiva senha para acesso ao sistema 3. O sistema autentica dados do usuário 4. Se os dados do usuário forem válidos, o sistema valida o usuário 5. O caso de uso termina Fluxo excepcional (FE): 1. O usuário pode cancelar a operação a qualquer momento 2. Se o usuário entrar com dados inválidos, o sistema notifica o usuário com uma mensagem na tela informando que os dados digitados são inválidos. Pós-condição: o usuário é validado ou a operação é cancelada. Observe que o foi feito para o caso de uso ValidarUsuário deve ser feito para os demais casos de uso. Com as especificações de casos de uso, bem como a descrição do sistema, você fica numa condição melhor para derivar as classes que implementam essas funcionalidades. Esse processo de modelagem desse sistema exemplo é continuado na seção seguinte. Modelagem de Sistema usando UML Na Figura 1 você tem uma generalização de atores, onde o ator Aluno e o ator Funcionário são especializações do ator Usuário. Note que você pode precisar identificar associações entre atores e entre casos de uso. Por exemplo, você poderia ter dois outros casos de uso (ValidarSenha e ValidarDigital) como especializações do caso de uso ValidarUsuário. Isso é ilustrado na Figura 2. É importante você observar que herança entre casos de uso serve para adicionar, redefinir ou especializar comportamento. Outro tipo de associação é include, onde você tem o reuso de um caso de uso, evitando repetir a descrição de um mesmo

40

Engenharia de Software Magazine - Análise Orientada a Objetos

fluxo de eventos. Assim, você deve identificar comportamentos comuns. Isso ocorre com o caso de uso CadastrarLivro que requer e, portanto, reutiliza o caso de uso ValidarUsuário. A especificação do caso de uso CadastrarLivro é apresentada abaixo. Nome: CadastrarLivro Pré-condição: o usuário deve ser cadastrado na escola Fluxo de eventos principal (FP): 1. Include (ValidarUsuário) 2. O usuário fornece os dados do livro para cadastro no sistema 3. O sistema verifica se existe algum livro com dados similares 4. Se não há dados similares, o sistema cadastra o novo livro 5. O caso de uso termina Fluxo excepcional (FE): 1. O usuário pode cancelar a operação a qualquer momento 2. Se o funcionário entrar com dados de livro já cadastrado, então o sistema notifica o funcionário com uma mensagem informando que os dados digitados estão vinculados a um livro já cadastrado e pergunta se deseja consultar livro. Pós-condição: o usuário é cadastrado no sistema ou a operação é cancelada

Figura 2. Exemplo de herança num diagrama de caso de uso

Outro tipo de associação é extend, que incorpora condicionalmente o comportamento de outro caso de uso em um determinado ponto do modelo. Em tal situação, o caso de uso pode ser usado para especificar um comportamento opcional existente. Isto ocorre com o caso de uso ConsultarEmpréstimo, que pode ser utilizado opcionalmente como ilustrado na Figura 1. E, agora, depois que você obtiver o diagrama de casos de uso e respectivas descrições de cada caso de uso, o que fazer? Você deve obter as classes. Mas, quais classes preciso obter? Você precisará de, pelo menos, uma classe para cada caso de uso. Em tal situação, você precisa de uma classe de fronteira para lidar com a interação dos atores com o sistema, uma classe de entidade para representar as informações relevantes do aluno e de uma classe de controle para gerenciar o fluxo de execução do caso de uso. Para o caso de uso ValidarUsuário, as classes obtidas são mostradas na Figura 3.


PROJETO

No entanto, se alguma classe de entidade precisa ser persistente, então você necessitará de uma classe para realizar as tarefas de persistência de dados. Dessa forma, para cada classe de entidade que precise ser persistente, é criada uma nova classe com o estereótipo entity collection, como mostra a Figura 3.

Note que o propósito do diagrama de sequência é representar aspectos dinâmicos do sistema através da troca de mensagens entre objetos das classes identificadas. Dessa forma, você deve construir um diagrama de sequência para cada caso de uso, utilizando seu respectivo fluxo de eventos (capturando fluxo principal e depois fluxos excepcionais), além das informações das classes daquele caso de uso. Perceba ainda que os objetos comunicam-se uns com os outros por meio de mensagens para realizar a funcionalidade associada àquele caso de uso. Agora, se você proceder de forma similar ao diagrama anterior, isto é, você deve analisar o fluxo de eventos que há para o caso de uso [UC002] CadastrarLivro, bem como observar as informações das classes que implementam esse caso de uso, então você deve obter um diagrama de sequência como mostrado na Figura 6.

Figura 3. Classes identificadas do caso de uso ValidarUsuário

Agora, o que foi feito para o caso de uso [UC001] ValidarUsuário deve também ser feito para os demais casos de uso. A Figura 4 ilustra as classes identificadas para o caso de uso [UC002] CadastrarLivro.

Figura 6. Diagrama de seqüência do caso de uso CadastrarLivro

Figura 4. Classes identificadas do caso de uso CadastrarLivro

Perceba que foi adotado procedimento similar ao caso de uso anterior. Nesse momento, é importante você observar que as funcionalidades de um sistema não são isoladas como ‘ilhas de funcionalidades’, mas elas interagem umas com as outras. Para identificar como a interação ocorre, você (no papel de analista de sistemas ou projetista) deve entender como, por exemplo, o usuário (funcionário) interage com o sistema. Analisando a descrição do caso de uso [UC001] ValidarUsuário você obtém a interação capturada pelo diagrama de sequência mostrado na Figura 5.

Figura 5. Diagrama de sequência do caso de uso ValidarUsuário

Na linguagem UML, há dois tipos de diagramas que são essenciais para capturar os requisitos e a modelagem do sistema: diagrama de caso de uso e diagrama de classes. O diagrama de caso de uso é composto de atores e casos de uso. Estes últimos servem para descrever os requisitos funcionais ou funcionalidades de um sistema. No entanto, é a partir deles que identificamos as classes. Uma vez que você tenha obtido os casos de uso, identificado as classes para cada caso de uso e analisado a interação entre os objetos dessas classes usando diagramas de sequência, então você já pode identificar os relacionamentos entre as classes, os métodos e os atributos das classes. Cada iteração no diagrama de sequência corresponde a um relacionamento no diagrama de classe. As Figuras 7a e 7b ilustram os diagramas de classes dos casos de uso ValidarUsuário e CadastrarLivro, respectivamente. Note que o seu trabalho ainda não acabou. Você ainda precisa adicionar modificadores de visibilidade aos métodos e atributos, definir os tipos dos atributos, definir o tipo do retorno e dos parâmetros dos métodos, além de analisar a possibilidade de utilizar herança. Trata-se de um refinamento do modelo de classes visando aperfeiçoar o projeto. Com isso, você necessitará juntar as classes em um só diagrama para obter o diagrama do projeto do sistema. Fazendo isso, você irá obter um diagrama similar ao mostrado na Figura 8. Perceba que o objetivo é refinar o modelo anterior, que possui classes que implementam casos de usos (isto é, funcionalidades), mas que estavam separados. Aqui, uma

Edição 23 - Engenharia de Software Magazine

41


e refinamento desses modelos com a UML é feito com o auxílio de ferramentas de modelagem.

Conclusão

Dê seu feedback sobre esta edição!

www.devmedia.com.br/esmag/feedback Links História da Indústria de Software www.softwarehistory.org Recursos da UML http://www.rational.com/uml/resources/documentation/ Figura 8. Refinamento do diagrama de classes do sistema de biblioteca

de suas tarefas é juntar as partes num único modelo e outra tarefa é detalhar adicionando métodos (ou funções) e atributos. Além disso, uma nova classe denominada de fachada foi usada para agregar as funcionalidades. Essa classe é encarregada de disponibilizar serviços do sistema. Adicionalmente, a classe fachada serve como um ‘elo’ entre a chamada de serviços (ou funcionalidades) e suas respectivas implementações. Observe que a construção, revisão

42

Engenharia de Software Magazine - Análise Orientada a Objetos

Lista de ferramentas UML http://en.wikipedia.org/wiki/List_of_UML_tools JUDE – Ferramenta de modelagem UML http://jude.change-vision.com/jude-web/index.html Processo de Desenvolvimento de Software http://pt.wikipedia.org/wiki/Processo_de_desenvolvimento_de_software Curso Online sobre Modelagem OO e UML http://gentleware.com/fileadmin/media/synergy/Course/index.htm

sobre e s

A Engenharia de Software Magazine tem que ser feita ao seu gosto. Para isso, precisamos saber o que você, leitor, acha da revista! Dê seu voto sobre este artigo, através do link:

Feedback eu

edição ta

Figura 7. Diagramas de classes dos de usos ValidarUsuario e CadastrarLivro

Dê s

Este artigo tratou da análise e modelagem de sistema. Aqui, o foco recai em entender e explorar os princípios de análise e projeto e aplicá-los em conjunto com uma linguagem de modelagem como a UML. Além disso, tivemos a oportunidade de explorar mais o uso da UML e conhecer situações onde você pode empregar seus diagramas que servem de apoio na especificação de sistemas de software. Para ilustrar os conceitos apresentados, exemplos foram utilizados para ilustrar os passos da análise e uso da UML.


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

Catalogação de Padrões Reutilização de Padrões de Análise por meio de catálogo de padrões usando a ferramenta ArgoCASEGeo De que se trata o artigo?

Evaldo de Oliveira da Silva evaldo@cesjf.br

Possui mestrado e especialização em Ciência da Computação pela Universidade Federal de Viçosa. Atualmente é Coordenador do Setor de Tecnologia da Informação da Academia Colégio Cristo Redentor e Centro de Ensino Superior de Juiz de Fora (CES/JF). Atua também como professor dos Cursos de Graduação e Pós-Graduação em Informática no CES/JF e graduação da Fundação Educacional D. André Arcoverde (FAA).

Jugurta Lisboa Filho jugurta@dpi.ufv.br

É Doutor em Ciência da Computação pela UFRGS. Atualmente é Professor Associado no Departamento de Informática da Universidade Federal de Viçosa. Professor orientador no Programa de Pós-Graduação em Ciência da Computação da UFV. Tem como áreas de interesse Modelagem de Banco de Dados e Sistemas de Informação Geográfica. Sua pesquisa é financiada parcialmente pela Fapemig e CNPq/MCT/CT-Info.

Este artigo aborda a importância da reutilização de software por meio de padrões de software. O artigo apresenta conceitos sobre padrões de software, padrões de projeto, e, principalmente, padrões de análise. Mostra ainda como os padrões de análise podem ser catalogados seguindo um template amplamente divulgado pela literatura. Finalmente, exemplifica a catalogação de padrões usando a ferramenta ArgoCASEGeo, usada na modelagem conceitual de banco de dados geográficos.

Para que serve? O artigo demonstra como padrões de softwa-

D

esde o surgimento das linguagens de programação de alto nível, a idéia de reutilização tem sido constantemente usada com o objetivo de ter mais qualidade e produtividade durante a construção de software. Existem alguns exemplos de reutilização, como o uso de padrões, tipos abstratos ou funções e procedimentos previamente construídos e validados, para serem reutilizados por meio de bibliotecas de códigos compartilhados.

re podem ser catalogados e armazenados. O catálogo de padrões é considerado um mecanismo importante para melhorar a reutilização de software tanto na fase de modelagem conceitual quanto na etapa de codificação. Os padrões podem estar organizados por meio de repositórios, onde estes últimos são construídos a partir de ferramentas para modelagem e desenvolvimento de software.

Em que situação o tema é útil? Reutilização de software por meio do catálogo de padrões de software usando ferramentas de modelagem e desenvolvimento de software.

Durante a fase de implementação de um software, muitas rotinas e métodos podem ser copiados de um módulo e reutilizados em outras rotinas que executam tarefas semelhantes. Outras formas de reutilização permitem o compartilhamento de código de forma mais ampla como, por exemplo, a construção de bibliotecas chamadas DLL (Dynamic-link library) e o desenvolvimento baseado em componentes (DBC).

Edição 23 - Engenharia de Software Magazine

43


Por meio de uma DLL é possível o acesso a funções ou métodos reutilizáveis. Ou seja, sistemas de informação desenvolvidos com arquiteturas e plataformas diferentes podem instanciar a DLL, permitindo ao desenvolvedor reutilizar o código de forma mais rápida e integrada. O paradigma de DBC é largamente utilizado na construção de software, visando à redução de tempo e custo de desenvolvimento por meio da reutilização em larga escala (WERNER et al., 2000). Segundo Werner et al. (2000), o DBC tem como objetivo a definição de componentes com interfaces bem definidas e interoperáveis, evidenciando os relacionamentos permitidos por componentes. Desta forma, a complexidade do desenvolvimento de software tornar-se menor, permitindo a diminuição dos custos por meio da reutilização de componentes. Para que a reutilização de componentes seja eficaz no desenvolvimento de novas aplicações, é necessário prover uma infraestrutura de apoio à reutilização que privilegie o DBC em todos os seus aspectos. A reutilização de código também é considerada como um benefício no desenvolvimento de serviços Web (ou Web Services) para promover a integração de sistemas e bases de dados heterogêneas. Uma arquitetura orientada a serviços, mais comumente referenciada pela sigla SOA (Service Oriented Architecture), consiste em um projeto de software cujo objetivo maior é obter interoperabilidade entre componentes de software utilizando acoplamentos fracos (loose-coupling) (NUNES, 2005). Em uma arquitetura SOA, uma camada de serviços agrega componentes e funcionalidades relacionadas a um ou mais processos. A composição dos serviços oferecidos caracteriza uma aplicação SOA. Segundo Nunes (2005), um dos principais benefícios de uma arquitetura orientada a serviços implementada por meio de serviços Web é a reusabilidade. Isso permite que os serviços e funcionalidades oferecidos por uma aplicação SOA sejam altamente reutilizáveis com pouco esforço, pois suas interfaces discretas podem ser invocadas de forma independente. Observa-se, com base nas formas de reutilização citadas anteriormente, que o reuso de software não é apenas de códigos e bibliotecas previamente testados, mas de técnicas e idéias que se mostram eficientes na solução de um determinado problema. O surgimento da orientação a objetos na década de 60, e sua crescente popularidade no início da década de 90, também veio facilitar a reutilização. Com a adoção desse paradigma nas diferentes fases do desenvolvimento de software, em especial, nas fases de análise e projeto, o conceito de reutilização vem sendo mais explorada. Por meio de técnicas de especificação e modelagem, é possível definir uma linguagem comum para a troca do conhecimento sobre o domínio modelado e para entender a estrutura que define o funcionamento do software. A UML (Unified Modelling Language) é um exemplo de linguagem que permite documentar modelos de software obedecendo a uma notação padronizada.

44

Engenharia de Software Magazine - Catalogação de Padrões

Segundo Booch, Rumbaugh e Jacobson (2006), a UML é uma linguagem gráfica para visualização, especificação, construção e documentação de artefatos de sistemas complexos de software, que proporciona uma forma padrão para modelar processos de negócios e funções de um software. A UML também permite modelar classes escritas em uma determinada linguagem de programação, esquemas de banco de dados e componentes de software reutilizáveis. De acordo com David Hooker (apud Pressman, 2006), uma das técnicas mais utilizadas no desenvolvimento de software orientado a objetos, tanto na implementação quanto na modelagem de sistemas, é a reutilização por meio de padrões de software. Nas seções seguintes são explorados os conceitos de padrões de software, padrões de projeto e de análise, bem como as definições sobre especificação e catalogação de padrões.

Padrões de Software Padrões de software são usados na área de Ciência da Computação, principalmente pela Engenharia de Software, para facilitar o reuso de artefatos durante as fases do desenvolvimento de sistemas. De acordo com Fowler (1997), um padrão é definido como: “uma idéia que tem sido utilizada em um contexto prático e provavelmente será útil em outros contextos”. O reuso por meio de padrões teve origem nos estudos de Christopher Alexander, professor da Universidade da Califórnia, localizada em Berkeley nos Estados Unidos. Christopher Alexander desenvolveu várias teorias sobre padrões de projeto em arquitetura que foram publicados e catalogados (FOWLER, 1997). As publicações e especificações elaboradas pelo professor Alexander serviram como referência para os pesquisadores e profissionais da Ciência da Computação no desenvolvimento de métodos e técnicas sobre a reutilização de padrões de software (software patterns). Segundo Corfman (1998), padrões facilitam a comunicação entre projetistas por meio de um vocabulário, permitindo que as equipes de desenvolvimento compartilhem modelos, interfaces e códigos. Possibilitam ainda que a documentação do software seja mais simplificada, pois os projetistas podem levar menos tempo modelando ou escrevendo códigos. A motivação para o reuso é a necessidade de aumento de produtividade, qualidade e manutenibilidade tanto do software, quanto de seu processo de desenvolvimento (PRESSMAN, 2006). A produtividade se deve, por exemplo, ao fato de que o reuso reduz a quantidade de código a ser programado, testado e documentado, diminuindo também o custo final do produto de software. Deste modo, melhora-se a manutenção do software, pois o entendimento do sistema como um todo fica mais fácil, já que os modelos e componentes projetados para o reuso possuem funcionalidades bem definidas. Tais funcionalidades permitem que os membros da equipe de desenvolvimento fiquem mais familiarizados com a reutilização.


reuso

A qualidade de um software projetado para reuso, em geral, é maior do que a de um software desenvolvido sem esta preocupação, pois normalmente há um investimento maior no projeto, documentação e testes (COPLIEN, 1996; GAMMA et al., 2000). Os padrões de software abrangem diferentes níveis de abstração, sendo classificados em diversas classes de modo a facilitar sua recuperação e uso. Dependendo da fase ou nível da construção de um sistema de informação, os padrões de software podem ser classificados como (DEVEDZIC, 2002): Padrões de processo: definem soluções para os problemas encontrados nos processos envolvidos na Engenharia de Software: desenvolvimento, controle de configuração e testes; Padrões arquiteturais: expressam o esquema ou organização estrutural fundamental de sistemas de software ou hardware; Padrões de análise: descrevem soluções para problemas de análise de sistemas, embutindo conhecimento sobre o domínio de aplicação específico; Padrões de projeto: definem soluções para problemas de projeto de software; Padrões de interface: definem soluções para problemas comuns no projeto da interface de sistemas; Padrões de programação: descrevem soluções de programação particulares de uma determinada linguagem ou regras gerais de estilo de programação; Padrões de Persistência: descrevem soluções para problemas de armazenamento em arquivos ou bancos de dados; Anti-Padrões: descrevem uma solução ruim para um problema que resultou em uma situação ruim. Além disso, descrevem como escapar de uma situação ruim e como proceder para, a partir dela, atingir uma boa solução. Entre as classes de padrões citadas acima, este artigo aborda os padrões de análise, utilizados como técnica de reuso na modelagem conceitual de sistemas. As próximas seções apresentam os conceitos de padrões de projeto, padrões de análise e a importância da catalogação de padrões de software.

Padrões de Projeto Os padrões de projeto descrevem soluções para problemas específicos no projeto de software orientado a objetos. Essas soluções são desenvolvidas e aperfeiçoadas ao longo do tempo e refletem a modelagem e a recodificação, que é o resultado do esforço de desenvolvedores para obter maior reutilização e flexibilidade em seus sistemas de software (GAMMA et al., 2000). Segundo Pressman (2006), um padrão de projeto é caracterizado por classes, responsabilidades e colaborações, que indicam como o padrão pode ser ajustado para apoiar a solução de um problema durante fase de implementação do software. A Figura 1 mostra o padrão de projeto Composite que compõe objetos em uma estrutura de árvore para representar hierarquias todo-parte. O padrão Composite permite o tratamento de objetos individuais e composições de objetos de maneira uniforme.

Figura 1. Padrão de Projeto Composite

Os digramas de classes da UML descrevem os padrões de projeto, permitindo modelar o projeto como, por exemplo, os relacionamentos entre classes e objetos. Porém, apenas as notações gráficas não são suficientes para permitir o reuso mais amplo do padrão. Gamma et al. (2000) descreve os padrões de projeto por meio de um formato mais consistente, onde cada padrão é documentado em seções de acordo com um gabarito, fornecendo uma estrutura uniforme, tornando os padrões de projeto mais fáceis de aprender, comparar e usar. As definições sobre documentação e especificação de padrões serão vistas mais adiante neste artigo.

Padrões de Análise De acordo com Fowler (1997), um padrão de análise é definido como um esquema que é reutilizado em um domínio específico para modelagem conceitual de sistemas de informação, sendo uma combinação recorrente de conceitos que ocorre em um mesmo contexto. Fernandez (1998) aborda o reuso de padrões de análise, podendo os mesmos serem aplicados em domínios e sistemas de informação diferentes. Além disso, utiliza analogia como técnica para reutilizar padrões de análise entre as aplicações. Esta abordagem produz uma arquitetura de software que é mais flexível e reutilizável, comparada a outras abordagens que tratam da descoberta e reuso de padrões de análise. Fernandez (1998) ainda apresenta um exemplo da reutilização de padrões a partir de uma loja de reparos de computadores. A loja é considerada como parte de uma cadeia de lojas similares, onde os computadores são levados para a loja por algum cliente. O cliente é recepcionado por um técnico que faz a estimativa de custo do reparo no computador. Se o cliente concordar, o computador é colocado para reparo pelo técnico. O técnico então registra um documento de reparo. Todos os documentos de evento de reparo por computador

Edição 23 - Engenharia de Software Magazine

45


são coletados em um log de reparos e um evento de reparos pode ser suspenso por falta de peças ou por outras razões. Por analogia, o padrão de análise para loja de reparos de computador pode ser reutilizado para a modelagem conceitual de registros de pacientes em um hospital. O sistema de registro de pacientes, ao invés de registrar computadores quebrados, deve registrar pessoas doentes que precisam de cuidados dos médicos, enfermeiros e equipamentos para os exames. Cada classe é analisada e interpretada para a realidade de um hospital. Por exemplo, o computador torna-se paciente contendo propriedades que coincidem, o orçamento tornase um diagnóstico e um evento de reparo é uma estadia no hospital (Figura 2). O reuso de padrões de análise é proposto em outros domínios de aplicação como, por exemplo, na modelagem conceitual de sistemas de informação para comércio eletrônico e para gestão empresarial (FOWLER, 1997; MONTEIRO, 2002). Monteiro (2002) apresenta a reutilização de padrões de análise no desenvolvimento de aplicações para Web, apresentando a definição de padrões identificados a partir da análise de domínio de diversas aplicações de comércio eletrônico disponibilizados na Internet. Os padrões identificados podem ser úteis no desenvolvimento de novas aplicações, permitindo maior produtividade e qualidade, diminuindo o custo e o tempo dos projetistas na fase de levantamento de requisitos de aplicações de comércio eletrônico.

Padrões de Planejamento; Padrões para o Comércio; Padrões de Contratos de Derivativos. A abordagem do reuso de padrões de análise também pode ser vista na modelagem conceitual de aplicações de Sistemas de Informação Geográfica (SIG) para gestão urbana (LISBOA FILHO; IOCHPE e BORGES, 2002). Segundo Santos e Pires (1996), a gestão urbana necessita de informações sobre regiões municipais e intraurbanas para atender as demandas da sociedade, permitindo realizar ações públicas com base em um planejamento urbano. Tais informações devem fornecer dados sobre o ambiente natural existente nos centros urbanos como, por exemplo, as áreas livres, vegetação, clima e relevo. Além do ambiente natural, existem as ações antrópicas, que podem influenciar no planejamento urbano e na implantação de políticas públicas. Os SIGs são sistemas que permitem a extração de informações fundamentais para gestão urbana. Este tipo de aplicação visa facilitar o trabalho de análise geográfica, automatizando o processamento de dados geográficos. Além disso, a manipulação integrada de dados gráficos e não gráficos, juntamente com análise espaciais, pode orientar as tomadas de decisões e o planejamento, auxiliando na eficácia das políticas públicas (BORGES, 2002). O uso de SIGs pela administração pública deve permitir a manipulação e extração de dados georreferenciados, conciliando dados geográficos e alfanuméricos, a fim de permitir uma ampla visão do território. Lisboa Filho, Iochpe e Borges (2002) propõem três padrões de análise que ilustram a possibilidade de reutilização de esquemas de banco de dados em aplicações da área de gestão urbana, desenvolvidos com o uso de SIG. São eles: Parcelamento do Solo Urbano; Malha Viária; Rede de Circulação Viária. Os padrões citados acima foram modelados com base no modelo UML-GeoFrame, que serve para a modelagem de SIG (LISBOA FILHO; IOCHPE e BORGES, 2002). O UML-GeoFrame fornece um conjunto de estereótipos, ilustrado na Figura 3.

Figura 2. Esquema Conceitual para loja de reparos de computadores

Fowler (1997) apresenta vários padrões de análise para a modelagem conceitual no domínio de negócios. Esses padrões são classificados como:  Pad rõ es pa ra Á rea Cont ábi l (orga n i zação e res ­ ponsabilidade); Padrões de Observações e Medições; Padrões de Observações para a Finança Corporativa; Padrões de Inventário e Contabilidade;

46

Engenharia de Software Magazine - Catalogação de Padrões

Figura 3. Estereótipos do framework UML-GeoFrame

Catalogação de Padrões Um catálogo de padrões é uma coleção de padrões relacionados. É considerado como um mecanismo importante para melhorar a reutilização e a organização de padrões por meio de


reuso

repositórios, podendo ser construídos a partir de ferramentas para modelagem e desenvolvimento de software. Segundo Appleton (2000), por meio de catálogos é possível adicionar a estrutura para a organização da coleção de padrões, onde são documentados. Um padrão de análise é integrado à modelagem conceitual de um sistema sendo referenciado pelo seu nome. Porém, além do nome do padrão, outras informações também são necessárias para a documentação e a organização de padrões por meio de catálogos. Geyer-Schulz e Hasler (2001) apresentam um template para documentação de padrões de análise usados na Engenharia de Software, sendo constituído por uma estrutura de tópicos que especifica as características de um padrão. O template apresentado por Geyer-Schulz e Hasler possui a seguinte estrutura: intenção; motivação; solução; consequências; projeto; usos conhecidos e padrões relacionados. Meszaros e Doble (1998) abordam uma estrutura semelhante à apresentada por Geyer-Schulz e Hasler, porém com uma quantidade menor de tópicos, descrevendo o problema que o padrão se propõe em resolver e as restrições para resolução do problema. Tal estrutura contempla os seguintes tópicos: Nome: usado para identificar o padrão; Problema: fornece uma declaração sucinta do problema a ser resolvido; Contexto: descreve o contexto ao qual o padrão de análise se aplica; Solução: descreve a solução proposta para o problema. Uma solução pode ser dada de forma narrativa ou por um diagrama de classes que compõe a solução; Discussão: descreve as forças ou requisitos atendidos pelo padrão, as restrições de uso, consequências do uso do padrão, outros padrões e objetos relacionados, comentários sobre a implementação, entre outras discussões;  Exemplos: exemplif icam como o padrão pode ser reutilizado. Gamma et al. (2000) também propõem a documentação e catalogação de padrões de projeto. Sugerem a documentação a partir de um gabarito dividido em seções, tornando os padrões mais fáceis de aprender, comparar e usar. Além das abordagens para documentação de padrões, algumas ferramentas foram implementadas para apoiar a reutilização de padrões de análise. Marinho e Andrade (2003) implementaram a integração de padrões de software armazenados em um repositório com um modelo de processo de desenvolvimento, facilitando a busca e a reutilização dos mesmos por meio da ferramenta CASE Rational Rose. Gazola, Lisboa Filho e Andrade (2006) apresentam um catálogo de padrões de análise em uma ferramenta CASE de modelagem de dados geográficos, chamada ArgoCASEGeo. Essa ferramenta tem como objetivo dar suporte ao projeto conceitual de bancos de dados geográficos, tendo por base o modelo UML-GeoFrame. Além disso, disponibiliza um Módulo de Gerenciamento do Catálogo de Padrões de Análise.

A próxima seção descreve a ferramenta ArgoCASEGeo, especificando os recursos que oferece para armazenamento de padrões.

A ferramenta ArgoCASEGeo ArgoCASEGeo é uma ferramenta CASE que tem como objetivo dar suporte à modelagem de BDG (Banco de Dados Geográficos) com base no modelo UML-GeoFrame, e foi desenvolvida como uma extensão do software ArgoUML (TIGRIS, 2006). É uma ferramenta de código-aberto desenvolvida por meio da linguagem Java (LISBOA FILHO et al., 2004). A ArgoCASEGeo está disponível para download por meio do seguinte link: http://www.dpi.ufv.br/ projetos/argocasegeo. O ambiente da ferramenta ArgoCASEGeo está dividido em três painéis: o painel de navegação, usado para acessar os diagramas criados no projeto; o painel de diagramação, usado para visualizar e editar diagramas UML-GeoFrame; e o painel de propriedades, que permite a visualização e edição dos detalhes de algum elemento selecionado no painel de diagramação (Figura 4).

Figura 4. O ambiente da ferramenta ArgoCASEGeo

Os esquemas de dados criados usando a ferramenta ArgoCASEGeo são armazenados em formato XMI, que é uma sintaxe para armazenamento de esquemas conceituais de dados em documentos XML. A arquitetura da ArgoCASEGeo dispõe de cinco módulos, os quais são apresentados na Figura 5. Um dos módulos da ArgoCASEGeo é responsável por controlar e armazenar padrões de análise por meio de um catálogo de padrões. Tais padrões podem representar conceitualmente fenômenos com base na modelagem de banco de dados geográficos, ou armazenar esquemas conceituais de outros domínios de aplicação. Como mencionado anteriormente, os esquemas criados na ferramenta são armazenados em formato XMI. Este mesmo mecanismo de armazenamento também é usado para registrar e consultar os padrões de análise modelados na ferramenta. Para catalogar um novo padrão de análise por meio da ferramenta ArgoCASEGeo, o engenheiro de software deve inicialmente modelar o padrão usando o painel de diagramação. Em seguida, deve acessar o menu Analysis Patterns e o comando de menu New Analysis Pattern. A ArgoCASEGeo abrirá uma

Edição 23 - Engenharia de Software Magazine

47


janela para preenchimento do catálogo de padrões (Figura 6). Para finalizar a catalogação do padrão, deve-se clicar no botão Finish.

Figura 7. Tela para consulta dos padrões de análise armazenados na ferramenta ArgoCASEGeo

Considerações Finais

48

Engenharia de Software Magazine - Catalogação de Padrões

Dê seu feedback sobre esta edição! A Engenharia de Software Magazine tem que ser feita ao seu gosto. Para isso, precisamos saber o que você, leitor, acha da revista! Dê seu voto sobre este artigo, através do link: www.devmedia.com.br/esmag/feedback

Feedback eu sobre e s

Outra funcionalidade importante oferecida pela ArgoCASEGeo é a consulta aos padrões catalogados e armazenados. A Figura 7 mostra a tela que oferece esta funcionalidade. Nessa tela também é possível localizar um determinado padrão por meio do campo Search By Keyword, o resultado da pesquisa aparece na caixa de listagem Number of Patterns found. É possível observar também que a ferramenta mostra a solução consultada por meio de uma figura apresentada no campo Solution. Além disso, a documentação do padrão é mostrada logo acima da solução.

Dê s

Figura 6. Tela para criação e catalogação de um novo padrão de análise usando a ferramenta ArgoCASEGeo

Este artigo abordou a importância da reutilização de software por meio de padrões de software. Os conceitos apresentados sobre padrões de software, padrões de projeto e, principalmente, padrões de análise, contribuíram para esclarecer a reutilização em diversas etapas do desenvolvimento de software. A catalogação e o armazenamento de padrões de software por meio dos templates apresentados podem contribuir para o compartilhamento do conhecimento sobre a reutilização de esquemas conceituais para várias aplicações. Como consequência, pode aumentar a produtividade e a qualidade do desenvolvimento de software em diversos domínios de aplicação. O artigo também abordou o uso da ferramenta ArgoCASEGeo para a catalogação e armazenamento de padrões de análise para modelagem conceitual de banco de dados geográficos. Porém, essa ferramenta pode ser estendida e usada em outros domínios de aplicação, tendo o mesmo propósito para reutilização de padrões de análise.

edição ta

Figura 5. Arquitetura da ferramenta ArgoCASEGeo


reuso

Referências APPLETON, B. Patterns and Software: Essential Concepts and Terminology, 2000. Disponível em <http://www.cmcrossroads.com/ bradapp/docs/patterns-intro.html > Acesso em: 20 de janeiro de 2008.

LISBOA FILHO, J.; IOCHPE, C. Specifying analysis patterns for geographic databases on the basis of a conceptual framework. In: 7th ACM Symposium on Advances in Geographic Information Systems, 1999. Proceedings. Kansas City : ACM, 1999.

BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML Guia do Usuário. 2ª Ed. Rio de Janeiro: Campus, 2006.

LISBOA FILHO, J. ; IOCHPE, C. ; BORGES, Karla A V . Analysis patterns for GIS data schema reuse on urban management applications. Clei Eletronic Journal, on-line, 2002. v. 5, no 2. p. 1-15.

BORGES, K. A. V. A Gestão Urbana e as Tecnologias de Informação e Comunicação. Informática Pública, v. 2, p. 17-24, 2002.

LISBOA FILHO, J.; SODRÉ, V. F.; DALTIO, J.; RODRIGUES JÚNIOR, M. F.; VILELA, V. M. A CASE tool for geographic database design supporting analysis patterns. In: ER2004/CoMoGIS - Workshop on Conceptual Modeling for GIS. CONCEPTUAL MODELING FOR ADVANCED APPLICATION DOMAINS. Berlin : Springer LNCS, 2004. v. 3289. p. 43-54.

COPLIEN, J. O.. Software Patterns, SIGS Books & Multimedia, USA, 1996. CORFMAN, R. An Overview of Patterns. In: Rising L. (Org.). The Patterns Handbook: Techniques, Strategies, and Applications. UK: Cambridge University Press, 1998.

MARINHO, F. G.; ANDRADE, R. M. C. Uma Proposta de um Repositório de Padrões de Software Integrado ao RUP. In: SugarloafPLoP. Recife : CiN - UFPE, 2003. v. 3. p. 277-290.

DEVEDZIC, V. Software Patterns, In: CHANG, S.K. (Org.), Handbook of Software Engineering and Knowledge Engineering. v. 2. Singapore: World Scientific Publishing Co, 2002. p. 645-671.

MESZAROS, G., DOBLE, J., A Pattern Language for Pattern Writing, in R. Martin, et al., Pattern Languages of Program Design 3, Addison Wesley, 1998.

FERNANDEZ, E.B. Building systems using analysis patterns. In: International Software Architecture Workshop (ISAW3), 1998. Orlando, Proceedings Orlando: ACM Press, 1998. FOWLER M.. Analysis Patterns: Reusable Object Patterns, Addison-Wesley, 1997.

MONTEIRO, A. J. B. Padrões de Análise em Aplicações de Comércio Eletrônico na Web. 2002. 145 f.. Dissertação de Mestrado em Ciência da Computação, Universidade Federal de Minas Gerais, 2002.

GAMMA, E.; HELM, R.; JOHNSON, R.; VLISSIDES, J.. Padrões de Projeto: Soluções Reutilizáveis de Software Orientado a Objetos. Tradução de Luiz A. Meirelles Salgado. Porto Alegre: Bookman, 2000.

PRESSMAN, R.S. Engenharia de software. Tradução: Rosângela Delloso Penteado. 6.ed. São Paulo: McGraw-Hill, 2006.

GAZOLA, A.; LISBOA FILHO, J. ; ANDRADE, M.V.A. O Catálogo de Padrões de Análise da Ferramenta ArgoCASEGEO. In: Congreso Latinoamericano de Informática, 2006. Anais. Santiago : CLEI, 2006. p. 1-10. GEYER-SCHULZ, A.; HASLER, M. Software Engineering with Analysis Patterns. Technical Report 01/2001, Institut für Informationsverabeitung und Informationswirtschaft Wirtschaftsuniversität Wien · Augasse 2-6 · 1090 Wien. Disponível em < wwwai.wu-wien.ac.at/~hahsler/research/ virlib_working2001 /virlib/ > Acesso em: 01 de março de 2007.

TIGRIS. ArgoUML Project Home, 2006. Disponível em <http://argouml. tigris.org/> Acesso em : 04 de janeiro de 2008. WERNER, C. M. L. ; BRAGA, R. M. M. ; ROSETTI, M. Z. ; BARROS, M. O. ; MURTA, L. G. P. . Odyssey-LE: Uma Infra-Estrutura de Reutilização para o Domínio do Processamento Legislativo. In: Encontro Nacional de Informática Aplicada ao Legislativo (ENIAL), Vitória, 2000.

Existem coisas que não conseguimos ficar sem! ...só pra lembrar, sua assinatura pode estar acabando!

AMIGO

Renove Já!

www.devmedia.com.br/renovacao Para mais informações: www.devmedia.com.br/central Edição 23 - Engenharia de Software Magazine

49


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

Levantando Exceções no Desenvolvimento de Software Uma Abordagem Prática De que se trata o artigo?

Jacimar Fernandes Tavares

Utilização da FCL – Framework Class Library, para tratar exceções levantadas durante o desenvolvimento de aplicações com C#. Uma abordagem prática será utilizada para ilustrar essa abordagem.

jacimar.tavares@studentpartners.com.br

É Aluno do Curso de Bacharelado em Ciência da Computação da FAGOC - Faculdade Governador Ozanam Coelho, Microsoft Student Partners.

Marcelo Santos Daibert marcelo@daibert.pro Twitter: @MSDaibert

É professor e coordenador do Curso de Bacharelado em Ciência da Computação da FAGOC - Faculdade Governador Ozanam Coelho na graduação e pós-graduação (especialização), Mestrando e Especialista em Ciência da Computação pela Universidade Federal de Viçosa e Bacharel em Sistemas de Informação pela Faculdade Metodista Granbery. Gerente técnico da Optical Soluções em Informática Ltda.

Marco Antônio Pereira Araújo maraujo@devmedia.com.br

É professor dos Cursos de Bacharelado em Sistemas de Informação do Centro de Ensino Superior de Juiz de Fora e da Faculdade Metodista Granbery, Professor do Curso de Bacharelado em Ciência da Computação da FAGOC, Doutor e Mestre em Engenharia de Sistemas e Computação pela COPPE/ UFRJ, Especialista em Métodos Estatísticos Computacionais e Bacharel em Informática pela UFJF, Analista de Sistemas da Prefeitura de Juiz de Fora, Editor da Engenharia de Software Magazine.

50

É

fato que todo desenvolvedor, independente da plataforma, também é usuário de várias aplicações, muitas das vezes desenvolvidas por outras pessoas. No nosso dia a dia, como usuários de sistemas, nos deparamos com vários softwares de diversos fabricantes, e por sermos desenvolvedores logo pensamos: eu teria desenvolvido isso de outra forma. A análise crítica está presente em todos os seres humanos, e não seria diferente com os desenvolvedores de software. Quando você se depara com um software que foi modelado de uma forma diferente da que você faria apenas, tudo bem. O problema é quando você vai usá-lo e percebe que o desenvolvedor não fez uma validação dos campos de forma correta, e na mesma hora você repara que determinados dados inválidos levantam exceções que não foram tratadas, logo o sistema falha. Mesmo estando na posição

Engenharia de Software Magazine - Levantando Exceções no Desenvolvimento de Software

Para que serve? Para apresentar os tipos de erros que podem surgir na execução de um programa, e auxiliar os desenvolvedores na tarefa de tratá-los, evitando problemas na entrega da aplicação aos seus clientes.

Em que situação o tema é útil? O tema se torna fundamental, no ponto de vista de uma empresa com uma política de testes, a partir do momento que ela esteja tendo altos gastos com testes de software, para identificar potenciais problemas não previstos pelos desenvolvedores. Em empresas sem uma política de testes, este artigo pode ajudar desenvolvedores a identificar e prevenir possíveis falhas no produto final, evitando gastos com manutenção.

de usuário, é frustrante. Nesse momento, a vontade é de entrar no código fonte e resolver o problema mas, rapidamente percebe que não tem acesso a ele. Não foi você quem o fez. Sensação semelhante acontece com


desenvolvimento

os outros usuários, que não possuem conhecimentos sobre desenvolvimento, aliás, sequer sabem o que é código fonte. Neste momento, as intenções são diferentes. Ao invés de quererem entrar no código fonte e resolver o problema, eles apenas desistem de usar o software, ou perdem a confiança no produto. É hora da empresa que desenvolveu a solução começar a jogar dinheiro pelo ralo com manutenção para resolver esse problema. A criação de uma solução modelada de acordo com as necessidades do cliente possui várias etapas, entre levantamento de requisitos, análise, desenvolvimento e testes. Por exemplo, no momento que estamos criando um método que receba dados por parâmetro fornecidos pelo usuário na interface, e retorne um valor, devemos ter em mente que o método aceitará apenas determinados tipos de dados, os que forem necessários para ele realizar a sua função e retornar o resultado. Se o desenvolvedor não ficar atento a esses detalhes, ele corre o risco de permitir que o usuário forneça dados que não são os esperados pelo método. Nesta situação, o software que está sendo desenvolvido vai para a equipe de testes da empresa, onde estas falhas são identificadas, fazendo com que o software volte para o desenvolvedor, gerando um atraso significativo no cronograma do projeto. Todo esse processo de desenvolvimento de uma aplicação deve ser bem monitorado, para evitar que o produto final esteja sujeito a falhas. Cabe ao desenvolvedor conhecer os tipos de erros e a forma de solucioná-los para evitar problemas com manutenção e testes desnecessários. Neste artigo vamos analisar os tipos de erros e como evitá-los. Vamos falar também sobre exceções que podem ser levantadas em tempo de execução e mostrar como o desenvolvedor pode identificá-las e se prevenir contra falhas futuras. Para isso, falaremos sobre as estruturas que auxiliam neste processo, como os manipuladores try/catch e finally, além da utilização da FCL – Framework Class Library que, através de exceptions, formam um conjunto moderno e rico de recursos para aumentar a produtividade do desenvolvedor. Todos os recursos que serão apresentados servirão para que a etapa de desenvolvimento seja concluída com êxito, reduzindo o gasto com a etapa de testes ou diminuindo gastos com manutenção do produto. Cada uma das técnicas que serão abordadas fazem parte de um conjunto de boas práticas no desenvolvimento de aplicações. Através dos exemplos práticos, o desenvolvedor será capaz de entender o que é uma exceção, como são levantadas e porque elas ocorrem. Identificará possíveis pontos de ocorrência e como tratá-las da melhor forma, proporcionando conforto e segurança para os usuários, permitindo que os mesmos tenham informações corretas do que aconteceu e, sendo assim, possam prosseguir na tarefa, sem perder a confiança no software e no resultado obtido.

Conhecendo os tipos de erros Os Erros de Sintaxe são os causados por alguma declaração inválida, bem como erros na declaração de algumas estruturas,

variáveis e até mesmo pela falta de um simples, mas importante, ponto e vírgula. A Figura 1 mostra um erro simples de sintaxe, causado por não haver no laço for a declaração de uma variável contadora, mas existe o incremento da variável. É comum, no momento que estamos criando um código, esquecermos de detalhes simples. No caso da Figura 1, ocorre um erro de sintaxe ao compilar, como é demonstrado.

Figura 1. Erro de sintaxe

Os Erros de Runtime são os que ocorrem durante a execução da aplicação, devido a algum dado de entrada inválido, ou um comportamento inesperado qualquer. Tudo que foge ao fluxo principal da aplicação, e que não há tratamento previsto, gera erros em tempo de execução. Na Figura 2 temos a representação de um fluxo principal, onde temos início e fim. O início representa o começo da ação como, por exemplo, o momento que o usuário vai se cadastrar em um sistema. O final do fluxo principal é o cadastro efetuado com sucesso (Programa termina com êxito). Já o fluxo alternativo é um caminho diferente que se pode tomar, mas que o resultado é o mesmo do fluxo principal. O Fluxo de Exceção Não Tratado representa, por exemplo, a tentativa do usuário de colocar um dado inválido no seu cadastro, como idade negativa, data de nascimento no formato errado, etc. No caso representado pela Figura 2, o sistema levantará uma exceção que o desenvolvedor esqueceu de tratar. Isso fará com que o programa termine com erro. O cadastro não chega a ser concluído e o programa falha.

Figura 2. Representação do Fluxo Principal, com possibilidade de ocorrência de Fluxos Alternativos e de Exceção

Já os Erros de Lógica são os que passam pela compilação e não são detectados em Runtime, mas o resultado esperado não é o obtido. Como exemplo, pode-se ter um método que deveria dar uma saída para uma determinada entrada, mas o que se obtém é um resultado totalmente diferente. Neste caso, uma boa política de testes com implementação de casos de testes

Edição 23 - Engenharia de Software Magazine

51


poderia resolver o problema. É fundamental que o desenvolvedor esteja ciente da possibilidade de ocorrência destes três tipos de erros, mas apenas os erros de runtime serão abordados dentro do contexto deste artigo.

Como usar Try / Catch e Finally Os blocos try/catch permitem ao desenvolvedor criar fluxos principais com a garantia de que, se o bloco try não for executado, uma possível solução exista. O bloco try permite que o desenvolvedor insira código para que, durante a execução do programa, haja uma tentativa de executar aquela ação. A Listagem 1 representa o bloco try. Na Listagem 1, linha 1, podemos ver o comando try seguido de duas chaves nas linhas 2 e 4. Se esta tentativa for bem sucedida, o programa terminará com sucesso a ação iniciada. Caso não consiga executar o corpo do bloco try, o compilador levantará uma exceção. Essa exceção deve ser capturada por um bloco catch, que permitirá o tratamento desse erro de runtime, permitindo assim que a execução do programa continue, sem que seja abortado, como mostra a Listagem 2. Assim como na Listagem 1, a linha 1 da Listagem 2 mostra o comando try, seguido das chaves nas linhas 2 e 4. Um bloco try deve vir seguido por um manipulador catch, como podemos ver na linha 5. Este mesmo bloco try pode ser seguido por vários blocos catch, como veremos nos exemplos seguintes. Quando se insere código no corpo do bloco try, automaticamente estão sendo alocados recursos da máquina (seja de memória, como a criação de variáveis, ou de periféricos, como unidades de disco e leitores de CD). De uma forma ou de outra, estão se manipulando recursos. No caso da alocação de memória, o programador .Net não precisa se preocupar com a deslocação desses recursos, mas para os outros casos, ele tem em mãos a utilização do finally. Este bloco permite que, após a execução do try, ou de algum bloco catch, um trecho de código seja usado para finalizar a ação iniciada, independente dela ter sido concluída com êxito, assim como mostra a Listagem 3. A utilização do bloco finally é opcional, devendo ser utilizada em casos onde realmente se fizer necessário. Toda plataforma de desenvolvimento deve ter sua estratégia de tratamento de exceções bem definida para que o desenvolvedor tenha seu esforço de tratar erros amenizado. A Microsoft criou para a plataforma .Net os exceptions, que são a forma mais simples e robusta de se tratar erros, que nada mais são do que um conjunto de recursos oferecidos pelo .Net. O desenvolvedor tem então em suas mãos uma série de classes que tornam o seu trabalho de tratar os erros da aplicação bem mais simples, auxiliados pelos manipuladores try/catch e finally, como vimos. Com esses recursos, podemos separar o código de tratamento de exceções da lógica do código do negócio.

Como lidar com esses recursos? A partir de agora utilizaremos os conceitos vistos na prática, criando códigos que estarão sujeitos a erros em runtime. Sendo

52

Listagem 1. Sintaxe do bloco try. 1. 2. 3 4.

try { //A execução do programa tentará executar o corpo do bloco try(tudo entre chaves). }

Listagem 2. Sintaxe do bloco try, seguido do manipulador catch. 1. 2. 3. 4. 5. 6. 7.

try { //A execução do programa tentará executar o corpo a. do bloco try(tudo entre chaves). } catch { /* Se a tentativa de execução do bloco try não pôde ser realizada, uma exceção é levantada pelo compilador, mas neste caso é capturada pelo bloco catch. 8. */ 9. }

Listagem 3. Sintaxe do bloco try, seguido do manipulador catch e finally. 1. 2. 3. 4. 5. 6. 7.

try { //A execução do programa tentará executar o corpo a. do bloco try(entre chaves). } catch { /* Se a tentativa de execução do bloco try não pôde ser realizada, uma exceção é levantada pelo compilador, mas neste caso é capturada pelo bloco catch. 8. */ 9. } 10. finally 11. { 12. /* Aqui fica o código que finaliza a ação iniciada pelo try, que pode ser a liberação dos recursos nele alocados. a. */ 13. }

Listagem 4. Código exemplo. 1. 2. 3. 4.

Console.Write(“ Digite um número:”); Int32 numero1 = Convert.ToInt32(Console.ReadLine()); Console.Write(“ Digite outro numero:”); Int32 numero2 = Convert.ToInt32(Console.ReadLine());

5. Int32 resultado = numero1 / numero2; 6. Console.WriteLine(“ Resultado: “ + resultado); 7. Console.Read();

assim, será tratado em detalhes como usar os exceptions de forma simples. Abra o Visual Studio e crie um projeto do tipo Console Application, com o nome de TratamentodeExcecao. No método Main do projeto, digite o código da Listagem 4. As linhas 1 e 3 da Listagem 4 permitem a interação com o usuário. As variáveis numero1 e numero2 das linhas 2 e 4 armazenam o resultado do Type Cast dos valores que o usuário digitou. O código é muito simples. Ele pega dois números, divide o primeiro pelo segundo (linha 5) e imprime o resultado obtido (linha 6). Rode o programa e insira as entradas 5 e depois 1. O resultado obtido é 5, pois 5 dividido por 1 é 5. Até então, tudo normal. O fluxo principal foi executado. Rode o programa novamente e dê as entradas 5 e depois 0. O programa levantará uma exceção, já que a divisão por 0 não está tratada em nosso código, como podemos ver na Figura 3. Quando se está programando, tem-se que levar em conta o fato de que não se terá controle sobre o que o usuário digitará, apenas sabe-se dos tipos de dados que serão necessários que ele informe, mas nada pode garantir que ele assim o fará.

Engenharia de Software Magazine - Levantando Exceções no Desenvolvimento de Software


desenvolvimento

Neste caso, tem-se que criar o fluxo principal (caso as entradas sejam válidas, ele é executado) e tambem fluxos de exceção. Como fazer isso? A biblioteca de classes do .Net Framework oferece uma gama de classes para tratamento de exceções que podemos utilizar. As classes de exceção estendem do Namespace System. Exceptions. A classe IndexOutOfRangeException permite que o CLR (Common Language Runtime) levante uma exceção caso o desenvolvedor esteja tentando acessar uma posição inexistente de um Array, por exemplo. A classe SqlException foi criada para o tratamento de exceções com o servidor SQL. Quando se tenta comunicar com o Servidor do SQL Server e ele retorna um erro ou aviso, o CLR levanta uma exceção que poderá ser tratada com o uso desta classe. A classe ArgumentException permite o tratamento de exceções levantadas quando algum argumento passado a um método não é esperado. Com a classe ArgumentNullException podese tratar exceções levantadas em métodos que não permitem valores nulos como parâmetro. A classe TimeoutException permite o tratamento de exceções levantadas quando o tempo limite para a execução de determinado processo for atingido. Já com a classe FileNotFoundException podemos tratar exceções que são levantadas caso a tentativa de acessar um arquivo não ocorra. Uma documentação completa sobre cada uma delas pode ser encontrada na sessão de links, onde será possivel compreender a utilização de cada uma delas.

Figura 3. Exceção lançada em Runtime pelo compilador

Tratamento da exceção O tratamento de exceções é uma técnica que deve ser considerada em qualquer plataforma. A maioria dos conceitos vistos neste artigo podem ser utilizados independente da linguagem que esteja trabalhando, e é altamente recomendado que os desenvolvedores estejam conscientes disso para que as empresas tenham processos eficientes com baixo custo de teste e manutenções corretivas. A exceção que foi lançada em tempo de execução ocorreu porque houve a tentativa de dividir um número por zero, ou seja, dividir um número por nada. É fato que toda divisão deve ser feita com um denominador diferente de 0. Portanto, para auxiliar o programador na tarefa de evitar que o usuário insista em tentar uma divisão por 0, a criou-se a classe DivideByZeroException, que permite o tratamento da exceção, quando isso ocorrer.

Encapsule o código da Listagem 4 no corpo do bloco try, seguido do manipulador catch responsável, tratando a divisão por zero usando a classe DivideByZeroException, como mostra a Listagem 5. Listagem 5. Encapsulando o código sujeito a lançamento de exceções. 1. 2. 3. 4. 5. 6.

try { Console.Write(“ Digite um número:”); Int32 numero1 = Convert.ToInt32(Console.ReadLine()); Console.Write(“ Digite outro numero:”); Int32 numero2 = Convert.ToInt32(Console.ReadLine());

7. Int32 resultado = numero1 / numero2; 8. Console.WriteLine(“ Resultado: “ + resultado); 9. } 10. catch (DivideByZeroException) 11. { 12. Console.WriteLine(“ Impossivel fazer divisão com 0”); 13. } 14. Console.Read();

O código da Listagem 4 é um código que pode lançar uma exceção, portanto encapsule-o num bloco try (conforme Listagem 5, linhas 3 a 8) que, durante a execução do programa, tentará efetuar a divisão. Caso o usuário digite um demoninador 0, o CLR lançará a exceção mas, diferentemente da Listagem 4, o programa não falhará. A exceção será capturada, e então a mensagem “Impossível fazer divisão com 0” será exibida, como mostra a linha 12 da Listagem 5. Rode novamente o programa da Listagem 5 e digite as entradas 5 e depois 0. A mensagem exibida será ”Impossível fazer divisão com 0”. Teste agora as entradas 5 e depois 1.0. Note, pela Figura 4, que outra exceção será lançada, pois as variáveis numero1 e numero2 são inteiras. Esta é outra exceção que deverá ser tratada no nosso código. A Figura 4 mostra o lançamento de uma exceção do tipo FormatException, pois a entrada 1.0 é tida como formato não aceito. A mesma exceção ocorreria se digitássemos texto como entrada. Qualquer entrada no código da Listagem 5 que não possa ser convertida para inteiro levantará exceções Format Exception. Para capturar esse tipo de exceção, acrescente um manipulador catch, conforme a Listagem 6. Na Listagem 6, incluímos o manipulador catch (linha 14) para capturar exceções do tipo FormatException e imprimir a mensagem“ Não foi possível a divisão“, como mostra a linha 16. Rode o programa, teste novamente as entradas 5 e 1.0. O resultado é a impressão da string da linha 16. Como podemos notar, os tipos de dados usados nas listagens até agora são Int32 (inteiros de 32 bits), que permitem que esses inteiros variem de números negativos e positivos. Troque os tipos de dados para UInt32. Compile o código e dê as entradas 5 e -5. Perceba que outra exceção foi levantada em Runtime, agora porque o valor era muito grande ou muito pequeno para UInt32, ou seja, a mensagem mostra que uma exceção do tipo OverflowException ocorreu. Isto se deu porque tentamos atribuir valores negativos a variáveis do tipo UInt. Para tratar exceções do tipo OverflowException, crie outro manipulador catch. O seu código deverá ficar como o da Listagem 7.

Edição 23 - Engenharia de Software Magazine

53


Figura 4. Exceção do tipo FormatException lançada Listagem 6. Capturando a exceção FormatException lançada 1. 2. 3. 4. 5. 6.

try { Console.Write(“ Digite um número:”); Int32 numero1 = Convert.ToInt32(Console.ReadLine()); Console.Write(“ Digite outro numero:”); Int32 numero2 = Convert.ToInt32(Console.ReadLine());

7. Int32 resultado = numero1 / numero2; 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18.

Console.WriteLine(“ Resultado: “ + resultado); } catch (DivideByZeroException) { Console.WriteLine(“ Impossivel fazer divisão com 0”); } catch (FormatException) { Console.WriteLine(“ Não foi possivel a divisão.”); } Console.Read();

Listagem 7. Criando manipulador catch para exceções do tipo OverflowException. 1. 2. 3. 4. 5. 6.

try { Console.Write(“ Digite um número:”); UInt32 numero1 = Convert.ToUInt32(Console.ReadLine()); Console.Write(“ Digite outro numero:”); UInt32 numero2 = Convert.ToUInt32(Console.ReadLine());

7. UInt32 resultado = numero1 / numero2; 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22.

Console.WriteLine(“ Resultado: “ + resultado); } catch (DivideByZeroException) { Console.WriteLine(“ Impossivel fazer divisão com 0”); } catch (FormatException) { Console.WriteLine(“ Não foi possivel a divisão. Entrada Inválida”); } catch (OverflowException) { Console.WriteLine(“ Não foi possivel a divisão com númerosNegativos”); } Console.Read();

Nas linhas 18, 19 e 21 da Listagem 7 criamos o manipulador de exceções OverflowException. Caso ela seja capturada, executa o comando da linha 20. Usando a classe OverflowException, podemos tratar os limites permitidos pelas variáveis do tipo UInt32, que vão de 0 até 4.294.967.295. Todo valor fora desses limites lançará uma exceção. Até agora foram vistas algumas das exceções que podem ocorrer na execução de um programa, entre várias existentes. Foi visto também a importância de tratar as exceções para que o programa continue executando independente da entrada fornecida pelo

54

usuário. Teste outras entradas no código da Listagem 7 e veja qual bloco catch é executado caso o bloco try não funcione. Nos nossos exemplos, um bloco finally não se fez necessário, já que no bloco try estamos apenas alocando recursos de memória que o compilador se encarregará de liberar. Também, se o bloco try não executar, é porque alguma exceção foi levantada. Mesmo assim não precisaríamos finalizar. Analise bem o contexto do seu problema e veja se o bloco finally será necessário.

Interação com o usuário usando exceções Exceptions não são apenas mecanismos para capturar erros e permitir que o programa continue funcionando. Sua missão vai muito além, chegando até o nosso personagem mais importante: o usuário. De pouco vale um software bem modelado, com tratamento para as entradas mais improváveis (mas se tratando de utilização de um sistema, nada é tão pouco provável) se esses tratamentos não colocarem o usuário realmente a par do que ocorreu, porque ocorreu e que decisões tomar naquele momento. Pensando nisso, os desenvolvedores, além de estarem munidos de todos os conceitos e práticas vistas até o momento, devem ainda saber como e onde alertar o usuário sobre o ocorrido. Para essa tarefa, abandone o projeto anterior e crie um novo projeto, agora do tipo WindowsFormsApplication com o nome DivideDoisNumeros onde, a partir de agora, será visto como personalizar esse processo. No Form1, criado com o projeto, arraste dois TextBoxs para a tela e um Button. Arraste também três Labels. Altere a propriedade color dos labels 1 e 2 para vermelho e, do label 3, para azul. Selecione o Form1 e altere a propriedade font, de bold false para true, fazendo com que todo texto do Form esteja em negrito. Altere o texto do botão para Calcular. Seu Form1 deve ficar como o da Figura 5.

Figura 5. Formulário do projeto DivideDoisNumeros

Engenharia de Software Magazine - Levantando Exceções no Desenvolvimento de Software


desenvolvimento

Listagem 8. Criando programa DivideDoisNumeros. 1. 2. 3. 4. 5. 6. 7. 8.

using System; using System.Collections.Generic; using System.ComponentModel; using System.Data; using System.Drawing; using System.Linq; using System.Text; using System.Windows.Forms;

9. 10. 11. 12. 13. 14. 15. 16. 17. 18.

namespace DivideDoisNumeros { public partial class Form1 : Form { public Form1() { InitializeComponent(); } UInt32 numero1 = 0; UInt32 numero2 = 0;

19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32.

void testeCampoNumero1() { try { numero1 = Convert.ToUInt32(this.textBox1.Text); } catch (FormatException) { this.label1.Text = “Entrada Inválida. Digite numero “; } catch (OverflowException) { this.label1.Text = “Não foi possivel a divisão com números Negativos”; }

33. } 34. void testeCampoNumero2()

Agora altere as propriedades text de todos os labels deixandoos em branco. Os tipos de exceções que foram lançadas até agora são fruto da tentativa de execução de um programa dada uma determinada entrada. Se uma exceção ocorresse em qualquer ponto da execução, apenas uma mensagem era exibida de acordo com o tipo da exceção capturada, mas o programa não informava exatamente em que ponto do código a exceção foi lançada, nem qual parte do programa não pôde ser executada. Sendo assim, o usuário não saberia exatamente em que ponto da execução o erro ocorreu, o que pode atrapalhar sua tomada de decisões. Dê um duplo clique no botão Calcular para gerar o método do evento click. Este programa é bem semelhante ao anterior. O usuário informará dois números e então, como resultado, teremos a divisão do numerador pelo denominador. No evento click do botão Calcular ficarão as chamadas para os métodos que serão criados. O código do seu Form1 deverá ficar como o da Listagem 8. Nas linhas 17 e 18 da Listagem 8 temos a declaração das variáveis do tipo UInt32 numero1 e UInt32 numero2. Estas serão as variáveis que receberão os valores digitados pelo usuário nos TextBoxs. Tudo que é digitado nos textboxs são strings, logo, para as variáveis receberem esses dados eles devem ser convertidos para UInt32. Como já falamos anteriormente, não podemos controlar o que o usuário digitará nos textboxs, então para cada TypeCast pode-se levantar uma exceção na tentativa de atribuição. Para que o usuário saiba onde ele inseriu entradas inválidas, criamos um método que tentará a atribuição dos valores às variáveis. Caso falhe, uma exceção

35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47.

{ try { numero2 = Convert.ToUInt32(this.textBox2.Text); } catch (FormatException) { this.label2.Text = “Entrada Inválida. Digite numero “; } catch (OverflowException) { this.label2.Text = “Não foi possivel a divisão com números Negativos”; }

48. } 49. 50. 51. 52. 53. 54. 55. 56. 57. 58.

void divideDoisNumeros() { try { this.label3.Text = (Convert.ToString(numero1 / numero2)); } catch (DivideByZeroException) { this.label2.Text = “Impossivel fazer divisão com 0”; }

59. } 60. 61. 62. 63. 64. 65. 66. 67.

private void button1_Click(object sender, EventArgs e) { testeCampoNumero1(); testeCampoNumero2(); divideDoisNumeros(); } } }

será capturada. As linhas 19 a 33 mostram o código do método do tipo void, chamado testeCampoNumero1. O mesmo deverá ser feito com os dados do textbox2, conforme o método testeCampoNumero2, nas linhas 34 a 48. Dentro do corpo desses dois métodos deve haver um bloco try e manipuladores catch conforme as necessidades identificadas para os tipos de dado UInt32. Repare também que não há o manipulador para exceções DivideByZeroException no corpo dos dois métodos. Falaremos sobre este detalhe mais adiante. Então, das linhas 19 a 48, temos a criação de dois métodos que pegarão os valores dos textboxs (linhas 23 e 38) e atribuirão às variáveis numero1 e numero2 o resultado do TypeCast. Nas linhas 49 a 59 temos o método divideDoisNumeros que tentará fazer a divisão dos valores das variáveis numero1 e numero2, e atribuirá o resultado a propriedade Text do Label3, conforme a linha 53. Esta operação é outro ponto do nosso programa sujeito a exceções se, por exemplo, o valor da variável numero2 for 0. O método divideDoisNumeros contém um manipulador catch para esta situação. Até agora foram identificados 3 pontos onde podem ocorrer exceções, que são as linhas 23, 38 e 53. Portanto, o usuário deverá ser informado se alguma exceção ocorrer, e em qual desses pontos ela ocorreu. Caso o usuário insira dados inválidos no texbox1, ele receberá uma mensagem informando a situação. Desta forma ele saberá exatamente qual dado inválido foi inserido. As linhas 27 e 31 permitem que o label1 exiba a mensagem. Se o dado inválido por sua vez for inserido no textbox2, ele verá uma mensagem atribuída à propriedade text do Label2 como mostram as linhas 42 e 46, dependendo

Edição 23 - Engenharia de Software Magazine

55


Neste artigo foram abordados vários conceitos e técnicas que devem fazer parte do dia a dia de todos os desenvolvedores. Uma empresa consciente da necessidade de ter profissionais munidos desses conceitos e totalmente interados desses processos pode alcançar um maior rendimento. Todas as técnicas e recursos aqui abordados podem contribuir para o sucesso de vários projetos que a empresa esteja trabalhando. Cada vez mais o mercado exige softwares com qualidade e que sejam capazes de se recuperar de falhas e, ao mesmo tempo, interagir com o usuário, possibilitando um sincronismo perfeito entre ambas as partes.

Links

Dê seu feedback sobre esta edição! A Engenharia de Software Magazine tem que ser feita ao seu gosto. Para isso, precisamos saber o que você, leitor, acha da revista! Dê seu voto sobre este artigo, através do link: www.devmedia.com.br/esmag/feedback

Engenharia de Software Magazine - Levantando Exceções no Desenvolvimento de Software

Dê s

Site Biblioteca do MSDN http://msdn.microsoft.com/pt-br/library/system.aspx Feedback eu

edição ta

56

Conclusão

sobre e s

da exceção capturada. Caso os dados sejam válidos nos dois texboxs, o Label3 exibirá o resultado, conforme linha 53, mas se o valor da variável numero2 for 0, então o Label2 exibirá a mensagem da exceção capturada, como mostra a linha 57. Para que todas essas operações sejam realizadas, insira a chamada aos métodos criados dentro do evento click do Button1, como mostram as linhas 62, 63 e 64. Rode o programa e teste as entradas 5 e 5. O Label3 exibirá o resultado, que é 1, pois as entradas são válidas. Teste agora as entradas C# e 5. O label1 exibirá a mensagem “Entrada inválida. Digite números”. Teste as entradas 5 e C#, e veja que a mesma mensagem foi exibida, agora no Label2. Faça ainda o teste com as entradas -5 e 5 e depois 5 e -5 e veja a exceção do tipo OverflowException sendo capturada. Em outro teste, insira ainda entradas inválidas nos dois textboxs ao mesmo tempo. Um último teste seria com as entradas 5 e 0. O Label2 exibirá a mensagem de “Impossível fazer divisão com 0” no lugar exato onde o usuário digitou a entrada 0. Com este exemplo, o usuário será capaz de compreender realmente o que aconteceu durante a execução, sendo uma boa forma de haver interação usando as exceções capturadas. Parece simples, mas os benefícios deste feedback do sistema para o usuário pode representar, em grande escala, uma maior satisfação em relação ao produto, considerando que as exceções, além de se prestarem ao seu papel, ainda permitem que a usabilidade do sistema aumente.


desenvolvimento

Edição 23 - Engenharia de Software Magazine

57


58

Engenharia de Software Magazine - Levantando Exceçþes no Desenvolvimento de Software

Engenharia de software edição 23  
Engenharia de software edição 23  
Advertisement