• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Es06   teste de software
 

Es06 teste de software

on

  • 984 views

 

Statistics

Views

Total Views
984
Views on SlideShare
984
Embed Views
0

Actions

Likes
1
Downloads
49
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Es06   teste de software Es06 teste de software Document Transcript

    • ISSN 1983127-79 771983 127008 00006
    • EDITORIAL “Se observarmos nos diferentes livros tradicionais de Enge- nharia de Software, veremos que sempre existe um capítulo ou seção destinado a Teste de software. Porém, eles normalmente apresentam apenas informações básicas sobre esta atividade,Ano 1 - 6ª Edição 2008 - Impresso no Brasil como por exemplo, os diferentes níveis de teste que podemCorpo Editorial ser aplicado, as técnicas de teste que podem ser aplicadas e osColaboradores critérios para seleção dos testes associados a estas técnicas. PorRodrigo Oliveira Spínola exemplo, no artigo “Introdução a Teste de Software” publicadorodrigo@sqlmagazine.com.br na edição 01 da Engenharia de Software Magazine discutimosMarco Antônio Pereira Araújo sobre alguns desses critérios: Particionamento em classes deEduardo Oliveira Spínola equivalência, Análise do Valor Limite e Grafo de Causa-Efeito.Editor de ArteVinicius O. Andrade Para cada critério, vimos como aplicá-los e um exemplo da suaviniciusoandrade@gmail.com aplicação para a geração de casos de teste.”Diagramação “No entanto, no desenvolvimento de um software real nor-Roberta F. Leal Armanroberta.arman@gmail.com malmente os problemas são bem mais complexos do queRevisão aqueles tradicionalmente usados quando estamos conhe-Gregory Monteiro cendo esses critérios para seleção dos testes (ex: indicar qualgregory@clubedelphi.net o maior valor em um conjunto, indicar se um campo númeroNa Webwww.devmedia.com.br/esmag só contém caracteres válidos, dentre outros). Normalmente Apoio os problemas a serem resolvidos são representados através de cenários, que podem ser facilmente representados por Diagramas de Casos de Uso da UML (www.uml.org) aliada a uma descrição do que cada caso de uso deve fazer.” Neste contexto, a Engenharia de Software Magazine des-PARCEIROS: taca nesta edição uma matéria muito interessante sobre a elaboração de casos de teste. Será apresentada uma possível estratégia indicando como testes podem ser obtidos a partir dos casos de uso especificados para um projeto. Além destas duas matérias, esta sexta edição traz mais seis artigos: Rodrigo Oliveira Spínola • Testes com Objetos Mock: Utilizando o framework Easy- rodrigo@sqlmagazine.com.br Mock para teste unitário de aplicações Java; 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 • Utilizando Visualização de Informação para Compreen- (UNIFACS, 2001). Colaborador da Kali Software (www.kalisoftware.com), tendo mi- são de Software; nistrado cursos na área de Qualidade de Produtos e Processos de Software, Requisi- • Conceitos Introdutórios sobre Melhoria e Avaliação de tos e Desenvolvimento Orientado a Objetos. Consultor para implementação do MPS. Processos de Software; BR. Atua como Gerente de Projeto e Analista de Requisitos em projetos de consultoria na COPPE/UFRJ. É Colaborador da Engenharia de Software Magazine. • Fundamentos de Arquitetura de Software; • Inspecionando a Usabilidade de Produtos; Marco Antônio Pereira Araújo • Gerenciamento de Projetos: Entenda alguns dos princi- (maraujo@devmedia.com.br) pais conceitos; É Doutorando e Mestre em Engenharia de Sistemas e Computação pela COPPE/ UFRJ – Linha de Pesquisa em Engenharia de Software, Especialista em Métodos • Soluções para Gerenciamento de Riscos de Projetos. Estatísticos Computacionais e Bacharel em Matemática com Habilitação em Desejamos uma ótima leitura! Informática pela UFJF, Professor dos Cursos de Bacharelado em Sistemas de Informação do Centro de Ensino Superior de Juiz de Fora e da Faculdade Meto- Equipe Editorial Engenharia de Software Magazine dista Granbery, Analista de Sistemas da Prefeitura de Juiz de Fora. É editor da Engenharia de Software Magazine. Eduardo Oliveira Spínola Dê seu feedback sobre esta edição! (eduspinola@gmail.com) A Engenharia de Software Magazine tem que ser feita ao seu gosto. eu Feedback É Colaborador das revistas Engenharia de Software Magazine, Java Magazine e s Para isso, precisamos saber o que você, leitor, acha da revista! Dê SQL Magazine. É bacharel em Ciências da Computação pela Universidade Salva- sobre e dor (UNIFACS) onde atualmente cursa o mestrado em Sistemas e Computação Dê seu voto sobre este artigo, através do link: na linha de Engenharia de Software, sendo membro do GESA (Grupo de Enge- s ta www.devmedia.com.br/esmag/feedback d i çã o e nharia de Software e Aplicações).
    • Caro Leitor,Para esta sexta edição, temos um conjunto de 8 vídeo aulas. Estas vídeo aulas estão disponíveis para download no Portal da Engenharia deSoftware Magazine e certamente trarão uma significativa contribuição para seu aprendizado. A lista de aulas publicadas pode ser vista abaixo:01 – Engenharia de Requisitos 05 – ProjetoTítulo: Introdução à Engenharia de Requisitos - Parte 19 Título: Introdução à Construção de Diagrama de Classes da UML – Parte 2Autor: Rodrigo Oliveira Spínola Autor: Rodrigo Oliveira SpínolaMini-Resumo: Esta vídeo aula é parte do curso de introdução à engenharia de requisitos. Mini-Resumo: Esta vídeo aula apresenta a notação da UML para elaboração deNesta décima nona parte apresentaremos passo a passo a especificação de um caso de uso diagramas de classes considerando os conceitos de classe, atributo e operação.considerando o cenário de consulta por clientes cadastrados de uma organização fictícia. 06 – Projeto02 – Engenharia de Requisitos Título: Introdução à Construção de Diagrama de Classes da UML – Parte 3Título: Introdução à Engenharia de Requisitos - Parte 20 Autor: Rodrigo Oliveira SpínolaAutor: Rodrigo Oliveira Spínola Mini-Resumo: Esta vídeo aula apresenta a notação da UML para elaboraçãoMini-Resumo: Esta vídeo aula é parte do curso de introdução à engenharia de requisitos. de diagramas de classes considerando os relacionamentos de herança eNesta vigésima parte finalizaremos a especificação do caso de uso iniciada na aula anterior. associação.03 – Engenharia de Requisitos 07 – ProjetoTítulo: Introdução à Engenharia de Requisitos - Parte 21 Título: Introdução à Construção de Diagrama de Classes da UML – Parte 4Autor: Rodrigo Oliveira Spínola Autor: Rodrigo Oliveira SpínolaMini-Resumo: Esta vídeo aula é parte do curso de introdução à engenharia de requisitos. Mini-Resumo: Esta vídeo aula apresenta a notação da UML para elaboraçãoNesta vigésima primeira parte apresentaremos passo a passo a especificação de um caso de diagramas de classes considerando os relacionamentos de agregação ede uso considerando o cenário de inclusão de cliente para uma organização fictícia. composição.04 – Engenharia de Requisitos 08 – ProjetoTítulo: Introdução à Engenharia de Requisitos - Parte 22 Título: Introdução à Construção de Diagrama de Classes da UML – Parte 5Autor: Rodrigo Oliveira Spínola Autor: Rodrigo Oliveira SpínolaMini-Resumo: Esta vídeo aula é parte do curso de introdução à engenharia de Mini-Resumo: Esta vídeo aula apresenta uma heurística para elaboração derequisitos. Nesta vigésima segunda parte finalizaremos a especificação do caso de uso diagramas de classes. Para isto, são apresentados alguns passos que podem seriniciada na aula anterior. seguidos para a apoiar a construção passo a passos destes diagramas.Atendimento ao LeitorA DevMedia conta com um departamento exclusivo para o atendi- ÍNDICEmento ao leitor. Se você tiver algum problema no recebimento do 06 - Conceitos Introdutórios sobre Melhoria e Avaliação de Processos de Softwareseu exemplar ou precisar de algum esclarecimento sobre assinaturas, Rodrigo Oliveira Spínolaexemplares anteriores, endereço de bancas de jornal, entre outros,entre em contato com: 14 - Gerenciamento de ProjetosCarmelita Mulin – Atendimento ao Leitorwww.devmedia.com.br/central/default.asp Andrey Abreu(21) 2220-5375Kaline Dolabella 20 - Utilizando Visualização de Informação para Compreensão de SoftwareGerente de Marketing e Atendimentokalined@terra.com.br Eduardo Oliveira Spínola(21) 2220-5375 28 - Fundamentos de Arquitetura de Software Rodrigo Oliveira Spínola e Rafael Ferreira BarcelosPublicidadePara informações sobre veiculação de anúncio na revista ou no site entre 36 - Planejamento de Testes a partir de Casos de Usoem contato com: Arilo Cláudio Dias NetoKaline Dolabellapublicidade@devmedia.com.br 42 - Testes com Objetos Mock Marco Antônio Pereira AraújoFale com o Editor!É muito importante para a equipe saber o que você está achando da revista: que 48 - Inspecionando a Usuabilidade de Produtostipo de artigo você gostaria de ler, que artigo você mais gostou e qual artigo Antônio Mendes da Silva Filhovocê menos gostou. Fique a vontade para entrar em contato com os editores edar a sua sugestão! 54 - Soluções para Gerenciamento de Riscos de ProjetosSe você estiver interessado em publicar um artigo na revista ou no site SQL Ma-gazine, entre em contato com os editores, informando o título e mini-resumo Cristine Gusmãodo tema que você gostaria de publicar: 60 - Introdução à Gestão de ConhecimentoRodrigo Oliveira Spínola - Colaboradoreditor@sqlmagazine.com.br Rodrigo Oliveira Spínola
    • Conceitos Introdutórios sobre Melhoria e Avaliação de Processos de Software De que se trata o artigo: trado. É necessário corrigir o processo que Apesar da crescente demanda por sof- permitiu que este fosse inserido, pois, des- tware em praticamente todas as áreas do ta forma, não será necessário corrigir os conhecimento, o processo de produção mesmos problemas em trabalhos futuros. continua sendo um esforço coletivo, criati- Com isto em mente, este artigo apresenta vo e complexo, por isso, precisa ser discipli- de forma abrangente o assunto melhoria nado, acompanhado e controlado de forma de processo de software. a se tornar efetivo e eficiente para a orga- Para que serve: nização. O foco no processo permite que Estabelecer boas práticas para facilitar um grupo de indivíduos alinhe o compor- os trabalhos envolvidos na melhoria de tamento e as atividades de cada membro processos de software. no sentido de alcançar o objetivo comum. Assim, acredita-se que a qualidade do pro- Em que situação o tema é útil: duto final está fortemente relacionada à Empresas que estão em busca de exce- qualidade do processo utilizado para o seu lência no desenvolvimento de software desenvolvimento e manutenção. Quando possuem como uma de suas alternativas um produto possui algum problema, não o trabalho fundamento em processos e se deve corrigir somente o defeito encon- sua melhoria contínua. Rodrigo Oliveira Spínola rodrigo@sqlmagazine.com.br Doutorando em Engenharia de Sistemas e Com- putação (COPPE/UFRJ). Mestre em Engenharia de Software (COPPE/UFRJ, 2004). Bacharel em Ciências da Computação (UNIFACS, 2001). Co- laborador da Kali Software (www.kalisoftware. com), tendo ministrado cursos na área de Qua- lidade de Produtos e Processos de Software, Re- quisitos e Desenvolvimento Orientado a Objetos. Consultor para implementação do MPS.BR. Atua como Gerente de Projeto e Analista de Requisi- tos em projetos de consultoria na COPPE/UFRJ. É Colaborador Engenharia de Software Magazine.6 Engenharia de Software Magazine – Conceitos Introdutórios sobre Melhoria e Avaliação de Processos
    • PROCESSO A melhoria do processo de sof- dimentos empregados na execução de Avaliação de Processo de Software tware pode ser considerada hoje atividades projetadas para produzir um As avaliações de processo de software uma das grandes prioridades resultado específico; são realizadas para atender a diferentespara as organizações que trabalham com • Para FUGGETTA (2000), um processo objetivos, geralmente estão delimitadassoftware. Isto se deve à exigência do mer- de software é definido como um conjunto a diferentes escopos e, a depender dascado por produtos com maior qualidade, coerente de políticas, estruturas organi- características dos modelos e métodosque sejam entregues mais rapidamente e zacionais, tecnologias, procedimentos e aplicados, ainda são classificadas comocom menor custo de desenvolvimento. artefatos que são necessários para conce- pertencendo a diferentes paradigmas. Estudos apontam que ao tentarem me- ber, desenvolver, disponibilizar e manter Uma vez que este conjunto de carac-lhorar seus processos, as empresas estão um produto de software; terísticas podem afetar de forma dife-em busca de: • E, finalmente, a ISO/IEC 12207 (1995) renciada uma avaliação de processo, • entender as características dos pro- define como um conjunto de atividades existem também na literatura diferentescessos existentes e os fatores que afetam inter-relacionadas, que transforma en- definições para avaliação de processo:a sua capacidade; tradas em saídas. • Para ZAHRAN (1997), uma avalia- • planejar, justificar e implementar Neste sentido, é importante destacar ção de processo de software é um exameações que modificarão os processos, tor- o trabalho da International Standard disciplinado do processo de softwarenando-os mais coerentes com as necessi- Organization (ISO) que estabeleceu utilizado pela organização, baseado emdades de negócios e; uma norma padrão para processo de um modelo de processo. O objetivo é de- • avaliar os impactos e benefícios ga- software ISO/IEC 12207 (1995) propon- terminar o nível de maturidade dessesnhos, comparando-os com os custos ad- do um framework com terminologia processos. O resultado deve identificarvindos das mudanças realizadas. bem definida e contendo processos, e caracterizar as práticas correntes, iden- Neste contexto de melhoria de proces- atividades e tarefas que devem ser tificando áreas de força e fraqueza e aso, é importante destacar uma das ativi- aplicados durante a aquisição, o for- eficácia das práticas atuais em controlardades de maior importância: a avaliação necimento, o desenvolvimento, a ope- ou evitar as principais causas de baixados processos utilizados durante a exe- ração e a manutenção de software. A qualidade, custo e cronograma ultrapas-cução dos projetos. norma descreve a arquitetura de um sados. Os resultados de uma avaliação Com o objetivo de apoiar a melhoria de processo de forma geral, mas não es- também podem ser usados como um in-processo, diversos métodos surgiram ao pecifica em detalhes como implemen- dicador da capacidade desses processoslongo dos últimos anos. Alguns méto- tar ou desempenhar estas atividades, em alcançar os objetivos do desenvolvi-dos avaliam os processos da organiza- nem descreve formato ou conteúdo da mento de software em relação à quali-ção tomando como base algum modelo documentação a ser gerada, o que deve dade, custo e cronograma com um altode referência, que descreve um conjunto ser definido pela organização que pre- grau de predição.de princípios e práticas e assume que, tende utilizá-lo de acordo com suas • Segundo HUMPHREY (1989), umase devidamente seguidas, irão levar a necessidades e as características parti- avaliação do processo de software émelhores produtos de soft ware. Outros culares de cada projeto. um exame aplicado a uma organizaçãométodos utilizam as medições para en- Outro conceito muito importante para que desenvolve software com o objeti-tender e avaliar os processos em uso e, conhecermos neste momento é o de vo de advertir seus gerentes e profis-somente então, tomar ações que levem à Maturidade do Processo de Soft ware. sionais a respeito de como melhorar asmelhoria do processo. Este teve sua origem em esforços do suas operações. Neste artigo apresentaremos alguns Soft ware Engineering Institute (SEI) ao • De acordo com a definição da ISO/IECconceitos relacionados a processos de atender uma solicitação da Força Aé- 12207 (1995), uma avaliação é uma deter-software e alguns dos principais mé- rea Americana que necessitava de um minação sistemática do grau de atendi-todos de avaliação de processo atual- método para avaliar a capacidade em mento de uma entidade em relação aosmente utilizados para apoiar a melho- desenvolver soft ware das organizações critérios para ela estabelecidos.ria do processo. que lhe prestavam serviços terceiriza- Neste cenário, KAN (2003) considerou dos. PAULK et al. (1995) defi niram capa- alguns aspectos importantes para asProcesso de Software cidade como o intervalo de resultados avaliações de processos: Podemos encontrar na literatura téc- esperados que podem ser alcançadosnica diversas definições para processo com o uso de um processo, e maturida- Contexto da avaliaçãode software: de como a amplitude na qual um pro- Uma avaliação de processo pode ser • HUMPHREY (1989) define processo cesso específico é defi nido, gerenciado, realizada em diferentes contextos,como um conjunto de atividades, méto- medido, controlado e executado. dependendo de quem irá desempe-dos e práticas utilizadas na produção e O resultado do trabalho do SEI (HUM- nhar os papeis essenciais durante ano desenvolvimento de software; PHREY, 1989) representa a base de di- avaliação. Dessa forma, uma avalia- • FLORAC et al. (1997) definem como versos outros modelos e normas com o ção pode ocorrer:uma organização lógica de pessoas, ma- objetivo de aumentar a maturidade dos • internamente, quando é realizadateriais, energia, equipamentos e proce- processos de software. uma auto-avaliação onde os principais Edição 06 – Engenharia de Software Magazine 7
    • sos da organização, um subconjunto se- lecionado dos processos ou um projeto específico (KAN , 2003). Para a maioria das avaliações de processo baseadas nos conceitos de maturidade ou capacidade (por exemplo, CMMI, Bootstrap, ISSO/ IEC 15504, MR MPS), a unidade de análi- se é normalmente o nível organizacional. Quando o alvo da avaliação é a orga- nização, os resultados de uma avaliação de processo podem ser diferentes, mes- mo com sucessivas aplicações do mesmo método. Isso acontece pelo fato que, em grandes empresas, varias definições de organização são possíveis e o escopo da avaliação pode ser diferente em avalia- ções sucessivas. Outra fonte de variação éFigura 1. Melhoria de processo com a norma ISO/IEC 15504 (ISO 1998) 1 (ISO, 1998). a amostragem de projetos escolhida para representar a organização; isso pode afe- tar o escopo e os resultados. Quando a unidade de avaliação é apenas um projeto, os problemas associados com a avaliação a nível organizacional dei- xam de ser relevantes. Uma avaliação de projeto de software deve incluir todos os fatores significativos que contribuem para o sucesso ou falha de um projeto. As ava- liações de projeto tratam, em profundida- de, não somente “quais” atividades foram realizadas, mas também do “como” e “por que” foram realizadas. Dessa forma, a in- vestigação exaustiva é uma característica chave de avaliação de projeto de software. A avaliação de processo baseada em maturidade de processo torna-se rele-Figura 2. Determinando a capacidade através do uso da ISO 15504 (ISO, 1998). vante quando uma organização tem a intenção de embarcar em uma estratégiapapéis são desempenhados por uma processo. De acordo com a norma, a orga- geral de melhoria a longo prazo. Porém,equipe que pertence à própria organiza- nização deve definir os objetivos e o con- os dois tipos de avaliação podem serção sendo avaliada; texto, escolher o modelo e o método para a complementares: a avaliação da matu- • externamente, sendo realizada avaliação e definir os objetivos de melhoria ridade do processo para uma estratégiapor uma equipe de avaliação externa (ROCHA et al., 2001). geral de melhoria para a organização eà organização; No segundo caso, determinar a capaci- avaliações de projeto para direcionar • ou ainda pode ser realizada por tercei- dade dos processos de uma organização, ações de melhoria imediatas e específi-ros, quando um fornecedor é avaliado por o objetivo é avaliar um fornecedor em cas no nível de projeto.uma equipe externa para que seja averi- potencial para obter seu perfil de capaci-guada a sua capacidade em atender aos dade. A Figura 2 mostra como a ISO/IEC Abordagens de avaliaçãorequisitos da organização contratante. 15504 (1998) é utilizada para determinar Vários modelos, métodos e técnicas de a capacidade de processos. De acordo melhoria estão disponíveis e podem serObjetivo da Avaliação com a norma, a organização deve definir divididos em duas grandes vertentes: Geralmente, uma avaliação de proces- os objetivos e o contexto da avaliação, os • A abordagem top-down, que é forte-so é realizada para atender a dois objeti- modelos e métodos de avaliação e os re- mente baseada em avaliações e benchma-vos: a melhoria dos processos e a deter- quisitos esperados (ROCHA et al., 2001). rking. São os casos do CMM (PAULK etminação da capacidade dos processos al., 1993), ISO/IEC 15504 (2003), o BOOTS-de uma organização. Escopo da Avaliação TRAP (KUVAJA, 1994), CMMI (CMU/SEI, A Figura 1 mostra como a norma ISO/IEC O escopo de uma avaliação do processo 2002) e do MR mpb (Sociedade SOFTEX,15504 (1998) é utilizada para a melhoria de de software pode cobrir todos os proces- 2004a) (Sociedade SOFTEX, 2004b).8 Engenharia de Software Magazine – Conceitos Introdutórios sobre Melhoria e Avaliação de Processos
    • PROCESSO • A abordagem bottom-up, que utiliza Apesar dos modelos serem úteis para e o “modelo em estágios”. A representaçãoprincipalmente a medição como o guia muitas organizações, o uso de múltiplos em estágios define um conjunto de áreaspara a melhoria de processo. Por exem- modelos gerou alguns problemas devido de processo para definir um caminho deplo, o GQM (BASILI et al., 1994). às diferenças de arquitetura, conteúdo melhoria para a organização, descrito em Na abordagem top-down, normalmen- e abordagem. Além disso, a aplicação termos de níveis de maturidade (melhoriate se aplica um modelo normativo que é de diversos modelos não integrados em vertical). A representação contínua per-assumido como a melhor maneira de se uma organização aumenta os custos de mite que uma organização selecione umadesenvolver software. Avaliando uma treinamento, das avaliações e das ativi- área de processo específica e melhore comorganização utilizando-se este modelo, dades de melhoria. relação a esta área. A representação contí-torna-se possível identificar a maturida- Por estas razões, o SEI iniciou o projeto do nua usa níveis de capacidade para carac-de desta organização e propor melhorias CMMI (CMM Integration), com o objetivo terizar a melhoria relacionada a uma árearelevantes. Já a abordagem bottom-up é de integrar as práticas de forma que orga- de processo específica.baseada na análise cuidadosa das práti- nizações que almejem melhorar seus pro- Ambas as representações contêm es-cas de processo aplicadas, na seleção de cessos nas diferentes disciplinas tenham a sencialmente as mesmas informações e aobjetivos de melhoria derivados dessa disposição um único modelo consistente. opção pelo modelo contínuo ou em está-análise e na gerência de atividades de Sendo assim, o CMMI integra os diver- gios depende de cada organização. Cadamelhoria apoiadas por medições. sos CMMs numa estrutura única, todos modelo possui características que o tor- com a mesma terminologia, processos de nam mais apropriado em uma situaçãoModelos de Avaliação de Processo avaliação e estrutura. O projeto também ou outra (CMU/SEI, 2002).de Software se preocupou em tornar o CMM com- O modelo em estágios oferece um A partir de agora serão apresentados patível com a norma ISO/IEC 15504, de caminho para melhoria de processos,alguns modelos de apoio à melhoria de modo que avaliações em um modelo se- indicando a ordem de implementaçãoprocesso e como é realizada a avaliação jam reconhecidas como equivalentes aos para cada área de processo de acor-em cada um deles. do outro (CMU/SEI, 2002). do com os níveis de maturidade. Essa Para permitir esta compatibilidade, o abordagem minimiza os riscos da me-CMMI CMMI oferece duas representações dife- lhoria de processos. A representação é Desde a década de 90, baseado no su- rentes para a sua abordagem de melhoria indicada para organizações realmentecesso alcançado pelo SW-CMM (CMM de processos. Estas duas representações comprometidas com a implantação dopara software), um número significativo são conhecidas como o “modelo contínuo” CMMI em escala geral.de modelos de maturidade de processofoi desenvolvido para diferentes discipli- Nível de Maturidade Foco Áreas de Processonas. Assim surgiram os seguintes mode- Inicial Sem foco, processos são ad hoc e caóticos. Não há áreas de processo neste nível.los (CMU/SEI, 2002): Gerencial O foco está na gerência de projeto. • Gerência de requisitos • Software Acquisition CMM (AS- • Planejamento de projetosCMM) – usado para avaliar a maturida- • Monitoração e controle de projetosde de uma organização em seus proces- • Gerência de acordos com fornecedoressos de seleção, compra e instalação de • Medição e análisesoftware desenvolvido por terceiros; • Garantia da qualidade do processo e do produto • Systems Enginnering CMM (SE-CMM) • Gerência de configuração– usado para avaliar a maturidade da or-ganização em seus processos de engenha- Definido O foco está na institucionalização do pro- • Desenvolvimento de requisitosria de sistemas, incluindo o hardware, o cesso. • Solução técnicasoftware e quaisquer outros elementos • Integração do produtoque participam do produto completo; • Verificação • Integrated Product Development • ValidaçãoCMM (IPD-CMM) – ainda mais abran- • Foco no processo organizacionalgente que o SE-CMM, inclui também ou- • Definição do processo organizacionaltros processos necessários à produção e • Gerência integrada do produtosuporte ao produto, tais como suporte ao • Gerência de riscosusuário, processos de fabricação, etc; • Análise de decisão e resolução • People CMM (P-CMM) – usado para • Ambiente organizacional para integração (IPPD)avaliar a maturidade da organização • Equipe integrada (IPPD)em seus processos de administração de Gerência Quantitativa O foco está na gerência quantitativa. • Desempenho do processo organizacionalrecursos humanos no que se refere a • Gerência quantitativa de projetosoftware: recrutamento e seleção de de- Otimizado O foco está na melhoria contínua do pro- • Inovação e disseminação organizacionalsenvolvedores, treinamento e desenvol- cesso. • Análise e resolução de causasvimento, remuneração, etc. Tabela 1. Níveis de maturidade do CMMI. Edição 06 – Engenharia de Software Magazine 9
    • O modelo em estágios avalia uma or- • No nível 4 de capacidade (Gerenciado Para conduzir uma avaliação no localganização como estando nos níveis de quantitativamente), a área de processo é de trabalho, as seguintes atividades de-maturidade de processo apresentados gerenciada quantitativamente utilizan- vem ser realizadas:na Tabela 1. do-se de técnicas estatísticas e outras • Examinar as evidências – que com- O modelo contínuo oferece uma aborda- técnicas quantitativas; preende coletar as informações a respei-gem mais flexível para a melhoria de pro- • Ao atingir o nível 5 de capacidade (Oti- to das práticas implementadas na unida-cessos, embora mais complexo de admi- mizado), a área de processo é gerenciada de organizacional e relacionar os dadosnistrar. É indicado para organizações que quantitativamente (capacidade nível 4) e coletados ao modelo de referência;desejam dar prioridade à melhoria de uma alterada e adaptada para adequar-se aos • Verificar e validar as evidências –área de processo ou conjunto de processos, objetivos de negócio da empresa. consiste em verificar a implementaçãode acordo com seus objetivos de negócio. das práticas nas unidades organizacio-Este modelo permite fácil comparação à Avaliação CMMI nais para cada instanciação e validar osISO/IEC 15504, porque a organização das O método de avaliação CMMI padrão para resultados da implementação descre-áreas de processo é derivada desta norma. melhoria de processo chama-se SCAMPI. vendo as falhas na implementação das Quando a representação contínua é uti- Ele foi desenvolvido para satisfazer os re- práticas do modelo;lizada numa avaliação, uma área de pro- quisitos do modelo CMMI (CMU/SEI, 2002). • Documentar as evidências – registracesso é avaliada como estando em um de- A avaliação segundo o SCAMPI consiste de as informações obtidas identificando eterminado nível de capacidade. Existem três fases: planejamento e preparação, con- consolidando os dados e transformado-seis níveis de capacidade, numerados de dução de uma avaliação no local de trabalho os em registros que documentem a im-zero a cinco. Para uma área de processo e a apresentação dos resultados. plementação das práticas, assim comoatingir determinado nível de capacidade, Para o planejamento e preparação, as se- suas forças e fraquezas;os objetivos específicos e, conseqüente- guintes atividades devem ser realizadas: • Gerar os resultados da apresentação -mente, as práticas específicas destes ob- • Identificar o escopo da avaliação – Mede a satisfação dos objetivos baseadojetivos devem ser satisfeitas: onde ocorre o levantamento das necessi- na extensão da implementação da práti- • No nível de capacidade 0 (Incomple- dades de negócio da unidade organiza- ca através da unidade organizacional. Ato), a área de processo não é realizada ou cional sendo avaliada; extensão da implementação da prática éé parcialmente realizada; • Desenvolver o plano da avaliação – determinada baseada nos dados valida- • Uma área de processo alcança o nível onde ficam registrados os requisitos do dos, coletados de toda a amostra das uni-1 de capacidade (Realizado) quando está plano de avaliação, acordos, estimativas, dades organizacionais.sendo realizada, ou mais precisamente, riscos, métodos de adaptação e conside- Quanto à apresentação dos resultados,quando os objetivos específicos da área rações práticas associadas à avaliação; as seguintes atividades são realizadas:de processo são alcançados; • Selecionar e preparar a equipe de ava- • Apresentar os resultados da avalia- • Alcançando o nível 2 de capacidade liação – uma equipe treinada, experiente e ção – Provê resultados da avaliação que(Gerenciado), a área de processo neces- apropriadamente qualificada é seleciona- podem ser usados para guiar ações desita que seu desempenho esteja sendo da para conduzir o processo de avaliação; melhoria. As forças e as fraquezas dosgerenciado. Diferente do nível 1, uma • Obter e analisar as evidências iniciais processos em uso também são apre-área de processo no nível 2 dispõe de um - obtém informações que identifiquem sentadas. Além disso, determina, seplano para a sua realização, assim como áreas potencialmente problemáticas ou planejado, qual o nível de capacidadeum processo concebido para cobrir esta falhas na implementação das práticas; ou o nível de maturidade dos proces-área de processo; • Preparar para a coleta de evidências sos em uso. • No nível 3 de capacidade (Definido), – consiste em planejar e documentar a • Empacotar e arquivar os resultadosa área de processo está sob o controle de coleta de dados incluindo as fontes de da avaliação – guarda registros e da-um processo padrão organizacional para dados, ferramentas e técnicas a serem dos importantes da avaliação e dispo-a área de processo e este pode ser adap- usadas e contingências para gerenciar o nibiliza o material selecionado de ma-tado para necessidades específicas; risco da falta de dados. neira apropriada.10 Engenharia de Software Magazine – Conceitos Introdutórios sobre Melhoria e Avaliação de Processos
    • PROCESSOISO/IEC 15504 demonstram se determinado processo é Essa norma define um conjunto de re- A ISO iniciou, em janeiro de 1993, o adequadamente praticado em um deter- quisitos para um Modelo de Avaliaçãoprojeto SPICE (Software Process Im- minado nível de capacidade. Há seis ní- e para um Método de Avaliação. Umaprovement and Capability dEtermi- veis de capacidade em que um processo avaliação que esteja de acordo com estesnation) com o objetivo de produzir pode ser avaliado: requisitos é referenciada como uma ava-inicialmente um Relatório Técnico que • Nível 0 - Processo incompleto: O pro- liação em conformidade com a avaliaçãofosse mais geral e abrangente que os cesso não é implementado ou falha na ISO/IEC 15504 (2003).modelos existentes e mais específico consecução de seu propósito. Não existe Ela não define um método de avaliaçãoque a norma ISO 9001. Uma versão do evidência de que os produtos de trabalho explícito, definindo apenas os requisitosSPICE foi aprovada em 1998 como Rela- sejam adequadamente produzidos ou necessários. Isto significa que as empre-tório Técnico (ISO/IEC TR 15504, 1998) e, que os resultados sejam alcançados; sas podem desenvolver os seus própriosapenas em 2003, a Norma ISO/IEC 15504 • Nível 1 - Processo executado: O pro- métodos de avaliação em conformidade(ISO/IEC 15504, 2003) foi publicada. cesso implementado alcança seu propó- com a ISO/IEC 15504 (2003). A ISO/IEC 15504 pode ser utilizada sito, mas sua execução talvez não seja ri-para a melhoria de processos e para a de- gorosamente planejada e acompanhada; GQMterminação da capacidade de processos • Nível 2 - Processo gerenciado: O O GQM representa uma abordagemde uma organização. Quando o objetivo processo executado anteriormente é sistemática para adaptar e integrar obje-da organização for a melhoria de pro- agora implementado de forma geren- tivos de negócio aos modelos de processocessos, pode-se avaliá-los, gerando um ciada (planejado, monitorado e ajus- de software baseando-se em necessida-perfil dos processos a ser utilizado na tado) e seus produtos de trabalho são des específicas de um projeto ou de umaelaboração de um plano de melhorias. A apropriadamente estabelecidos, con- organização (BASILI et al., 1994).análise dos resultados identifica os pon- trolados e mantidos; O resultado da aplicação do método dotos fortes e fracos e os riscos inerentes • Nível 3 - Processo estabelecido: O GQM é a especificação de um programaaos processos. Já quando o objetivo da processo gerenciado anteriormente é de medição que tem como objetivo in-empresa for avaliar fornecedores para agora implementado utilizando um pro- vestigar determinados assuntos, e umcontratação, esta pode obter seus perfis cesso definido e é capaz de alcançar seus conjunto de regras para interpretar asde capacidade. resultados de processo; medidas coletadas. O modelo de referência da ISO/IEC • Nível 4 - Processo previsível: O pro- Dentro de um contexto de avaliação do15504 (2003) define a dimensão de pro- cesso estabelecido anteriormente opera processo de software, o GQM pode sercesso, que corresponde à definição de agora dentro de limites para alcançar os utilizado para estabelecer um programaum conjunto de processos considerados resultados de processo; de medição que possibilite investigar ouniversais e fundamentais para a boa • Nível 5 - Processo otimizado: O pro- desempenho de determinados proces-prática da engenharia de software e a di- cesso previsível anteriormente é melho- sos, tornando-se uma abordagem bas-mensão de capacidade, que corresponde rado continuamente para satisfazer os tante eficaz para a monitoração e o con-à definição de um modelo de medição objetivos de negócio atuais e projetados trole dos processos.com base na identificação de um conjun- mais relevantes. O princípio por trás do método GQMto de atributos que permite determinar a é que as medições sejam orientadas porcapacidade de um processo para atingir Avaliação ISO/IEC 15504 objetivos. Dessa forma, tanto para ava-seus propósitos, gerando os produtos de Uma avaliação segundo a norma ISO/ liar quanto para melhorar seus proces-trabalho e os resultados estabelecidos. IEC 15504 (2003) considera três tipos de sos, as organizações devem definir seus Na dimensão de capacidade, as tare- elementos como importantes para sua objetivos de medição, baseados nos seusfas, atividades e práticas, bem como as realização: um modelo de avaliação; um objetivos de negócio e transformar essescaracterísticas dos produtos de traba- método de avaliação; um ou mais avalia- objetivos em atividades que podem serlho, são defi nidas como indicadores que dores competentes. medidas durante a execução do projeto. Edição 06 – Engenharia de Software Magazine 11
    • O GQM define um determinado objeti- vo, refina este objetivo em questões e de- fine métricas que devem propiciar infor- mações que respondam a estas questões. Respondendo às questões, os dados medidos defi nem o objetivo operacio- nalmente e podem ser analisados para identificar se os objetivos foram ou não alcançados. O GQM defi ne as métricas em uma perspectiva top-down e anali- sa e interpreta os dados medidos numaFigura 3. O paradigma GQM (BASILI e WEISS 1984) 3 WEISS, 1984). perspectiva bottom-up, como mostrado na Figura 3. O método GQM é composto de quatro fases (SOLINGEN e BERGHOUT, 1999). Na fase de planejamento, os requisitos bá- sicos para tornar o programa de medição viável são executados, incluindo treina- mento, envolvimento da gerência e pla- nejamento do projeto. A fase de definição identifica os objetivos e as questões e mé- tricas associadas a cada objetivo. Durante a fase de coleta de dados os formulários de coleta são definidos, preenchidos e armazenados na base de medições. Du-Figura 4. As quatro fases do método GQM (SOLINGER e BERGHOUT, 1999). rante a fase de interpretação as medidas são utilizadas para responder as questões Referências formuladas, e essas questões são, então, utilizadas novamente para verificar se os BASILI, V. R., WEISS, D., 1984, “A Methodology for Collecting Valid Software Engineering Data”, IEEE Transactions on Software Engineer- ing, Vol. 10, No. 3, Nov, pp. 728-738. objetivos declarados foram atingidos. BASILI, V. R., CALDIERA, G., ROMBACH, H.D., 1994, Goal Question Metric Paradigm, Encyclopedia of Software Engineering, 2 Volume Set, As quatro fases do método GQM são John Wiley & Sons, Inc.w CMU/SEI, 2001, Standard CMMI Appraisal Method for Process Improvement (SCAMPI), Version1.1: Method Definition Document, CMU/SEI- mostradas na Figura 4. 2001-HB-001, Pittsburgh, Software Engineering Institute, Carnegie Mellon University. URL: http://www.sei.cmu.edu CMU/SEI, 2002, Capability Maturity Model Integration (CMMI), Version 1.1 CMMI for Software Engineering (CMMI-SW, V1.1), Pittsburgh, Software Engineering Institute, Carnegie Mellon University. URL: http://www.sei.cmu.edu Considerações Finais FLORAC, W.A., PARK, R.E., CARLETON, A.D., 1997, Practical Software Measurement: Measuring for Process Management and Improvement, Várias abordagens associadas à me- CMU/SEI-97-HB-003, Pittsburgh, Software Engineering Institute, Carnegie Mellon University. HUMPHREY, W.S. 1989, Managing the Software Process, Addison-Wesley. lhoria de processo têm ganhado impor- ISO/IEC 12207, 1995, Information Technology – Software Life-Cycle Processes. tância na comunidade de soft ware. Os ISO/IEC PDAM 12207, 2002, “ISO/IEC 12207 Information Technology – Amendment to ISO/IEC 12207”, Montreal: ISO/IEC JTC1 SC7. ISO/IEC TR 15504, 1998, Information technology – Software Process Assessment. conceitos, métodos, e práticas englobam ISO/IEC 15504, 2003, Information Technology – Software Process Assessment, International Standard Organization. uma maneira de pensar, de agir e de en- KAN, S. H., 2003, “Metrics and Models in Software Quality Engineering”, Second Edition, Addison-Wesley. KUVAJA, P. et al., 1994, Software Process Assessment and Improvement: The BOOTSTRAP Approach, Oxford, Blackwell Publishers. tender os dados gerados pelos processos PAULK, M. C., WEBER, C. V., CURTIS, B., CHRISSIS, M. B. (eds), 1995, The Capability Maturity Model: Guidelines for Improving the Software que, coletivamente, resultam em melho- Process, Addison-Wesley. ROCHA, A.R., MALDONADO, J.C., WEBER, K.C., 2001, Qualidade de Software – Teoria e Prática, 1a ed., Prentice Hall, São Paulo. ria da qualidade, aumento da produti- Sociedade SOFTEX, 2004a, “Uma Estratégia para Melhoria de Processo de Software nas Empresas Brasileiras”, http://www.softex.br/media/ vidade e competitividade dos produtos QuaTIC.zip. Sociedade SOFTEX, 2004b, “Modelo de Referência para Melhoria de Processo de Software: uma abordagem brasileira.”, http://www.softex. de soft ware. br/media/artigoCLEI_versao_final.pdf. Acessado em 02/2005. Vimos neste artigo alguns dos concei- SOLINGEN, R., BERGHOUT, E., 1999, The Goal/Question/Metric Method: A Practical Guide for Quality Improvement of Software Develop- ment, McGrawHill, 1999. tos que norteiam a área assim como uma breve descrição de algumas abordagens para avaliação de processos. Dê seu feedback sobre esta edição! Feedback eu s Dê A Engenharia de Software Magazine sobre e tem que ser feita ao seu gosto. Para isso, precisamos saber o que você, s ta edição leitor, acha da revista! Dê seu voto sobre este artigo, através do link: www.devmedia.com.br/esmag/feedback12 Engenharia de Software Magazine – Conceitos Introdutórios sobre Melhoria e Avaliação de Processos
    • Gerenciamento de Projetos Entenda alguns dos principais conceitos De que se trata o artigo: Nesse artigo foram tratados os con- ceitos do Gerenciamento de Projetos, a fim de desmistificar o assunto e dar N este artigo falaremos um sustentação à decisão de aplicação pouco sobre Gerência de dos seus conceitos. Projetos “GP”, um assunto Para que serve: que pode parecer novo para alguns por Esclarece a base do Gerenciamento estar sendo foco de muitas discussões de Projetos e suas ramificações, ser- atualmente, principalmente dentro das vindo como ponto de partida para a organizações, que têm buscado nas sensibilização das organizações e pro- técnicas e conceitos da GP uma forma fissionais para a aplicação dos concei- de reduzir as falhas em seus projetos. tos em seu dia a dia. Entretanto, como ciência formal, a GP já tem quase meio século e se formos Em que situação o tema é útil: pensar como conceito são alguns mi- A aplicação dos conceitos de Ge- lhares de anos, é só lembrarmos da renciamento de Projetos auxilia na perfeita construção das pirâmides do gestão de projetos de qualquer tipo Egito, da muralha da china e outros e tamanho, aumentando os níveis de grandes projetos que envolveram um qualidade dos produtos ou serviços número grande de trabalhadores e ti- produzidos e ajudando a atingir os Andrey Abreu veram êxito. objetivos do projeto. andreyabreu@gmail.com Pós graduando em engenharia de software pela universidade GAMA FILHO, graduado em gestão estratégica de organizações pela UNISUL, Gerente de TI da empresa NEXXERA TECNOLOGIA S/A, gerencia atualmente área de Desenvolvimento de Sistemas, composta por 33 profissionais divididos em equi- pes de desenvolvimento Java e c, que trabalham local e remotamente em 15 linhas de projetos.14 Engenharia de Software Magazine – Gerenciamento de Projeto
    • P L A N E J A M E N TO Até hoje engenheiros renomados ain- O que é Gerência de Projetos? A História da Gerência de Projetosda se perguntam como foi possível a Segundo o PMBOK (2004, p.6), “Gerên- Como ciência foi formalizada na déca-construção, por exemplo, das pirâmi- cia de Projetos é a aplicação de conheci- da de 60, quando os negócios e organiza-des, um grande projeto com tamanha mentos, habilidades, ferramentas e téc- ções começaram a enxergar o benefícioprecisão e perfeição sem utilização das nicas, a fim de satisfazer ou exceder as do trabalho organizado em torno de pro-modernas técnicas de planejamento, necessidades e expectativas dos stakehol- jetos e a entender a necessidade críticaconstrução e controle. Esses fatos nos ders (interessados e envolvidos)”. para integrar o trabalho através de múl-mostram que muito do que precisamos Satisfazer as necessidades e expecta- tiplos departamentos e profissões.para ter êxito em nossos projetos já tivas dos stakeholders envolve além de Em 1969, no auge dos projetos espaciaisestá pronto, já foi testado e funciona, tudo equilibrar demandas concorrentes da NASA, um grupo de 5 profissionaisnão precisamos recriar novas técnicas em relação a: de gestão de projetos reuniu-se para dis-ou conceitos, apenas entender e utili- • Escopo, prazo, custo e qualidade; cutir melhores práticas e técnicas, e foizar os conceitos e técnicas existentes • Stakeholders com necessidades e ex- fundado o Project Management Institu-da melhor forma possível e com certe- pectativas diferenciadas; te, PMI (EUA) por Jim Snyder.za os resultados serão melhores. • Requisitos identificados (necessidades) e O PMI é atualmente a maior institui- requisitos não identificados (expectativas). ção internacional dedicada à dissemina-Mas o que realmente é um projeto? E esse é o desafio da gerência de proje- ção do conhecimento e aprimoramento Todos nós de forma intrínseca faze- tos, alinhar as expectativas e necessida- das atividades de gestão profissional demos projetos no decorrer de nossas des dos clientes com a realidade do pro- projetos e está espalhado por diversosvidas, seja uma viajem planejada, a jeto, gerando resultado sem prejudicar países através de seus grupos dissemi-manutenção preventiva do carro, um a qualidade e mantendo todos os atores nadores. Pelos números do PMI (posiçãoroteiro de férias, tudo isso são peque- envolvidos informados. jan/2006), passam de 212 mil os membrosnos projetos que planejamos e execu- Para isso, a Gerência de Projetos utiliza- e são mais de 176 mil profissionais cer-tamos sozinhos. Porém, quando esses se de seus processos componentes que tificados (PMP’s, “Project Managementprojetos começam a envolver mais podem ser classificados em cinco grupos Professional”) em 160 países.pessoas é necessária uma organiza- de processos (iniciação, planejamento,ção maior para que o objetivo de todo execução, controle e encerramento) e Áreas de Conhecimento da Gerênciao grupo seja atingido, e é nesse ponto de suas áreas de conhecimento, ao todo de Projetosque entra a Gerência de Projetos. nove (gerência de integração, gerência de Como já comentado no anteriormente, Segundo o PMBOK (Project Manage- escopo, gerência de tempo, gerência de a gerência de projetos é composta porment Body of Knowledge) (2004, p.21), custo, gerência de qualidade, gerência de nove áreas de conhecimento, que são aGuia do conjunto de conhecimentos RH, gerência de comunicação, gerência base para estruturação de um projeto deem Gerência de Projetos definido pelo de riscos e gerência de aquisições). sucesso. A Figura 1 ilustra a interaçãoPMI (Project Management Institute), Em resumo, a Gerência de Projetos visa entre essas áreas.“Um projeto é um esforço temporário, manter os riscos de fracasso em um ní- Falaremos a partir de agora um poucoexecutado por pessoas, restringido por vel tão baixo quanto necessário durante sobre cada uma dessas áreas, mas não en-recursos limitados, planejado, execu- todo o ciclo de vida do projeto. traremos nesse artigo no detalhamentotado e controlado, e empreendido paracriar um produto, serviço ou resultadoexclusivo”. Temporário por que cadaprojeto tem seu início e fim muito bemdefinidos, chegando-se ao fim quan-do os objetivos foram alcançados ouquando está claro que não serão ounão poderão mais ser alcançados. Percebemos então que é necessáriodefi nir objetivos, realizar um planeja-mento de execução, especificar custos,estipular a quantidade de pessoas en-volvidas e elaborar um cronograma,delimitando assim a previsão de inícioe término para produzir o resultado de-sejado no projeto. Agora que sabemos o que é um projetodentro do contexto apresentado, vamosentrar na conceituação do Gerenciamen-to de Projetos. Figura 1. Áreas de conhecimento da gerência de projetos. Edição 06 – Engenharia de Software Magazine 15
    • de cada uma. O PMBOK (2004, p.71-295) exigido e somente o trabalho exigido, quantidades) requeridos para a execuçãotraz com detalhes cada uma das áreas, controlando o que está ou não incluído de cada atividade do cronograma.seus procedimentos, artefatos, entradas no projeto, a fim de que o mesmo seja • Estimativa de duração das ativida-e saídas. completado com sucesso. des: Estimativa individual do período Processos envolvidos: de trabalho necessário para conclusão deGerenciamento de Integração • Planejamento do Escopo: Documen- cada atividade do cronograma. Inclui os processos necessários para tação de como o escopo do projeto será • Criação do Cronograma: Análise dagarantir que os elementos do projeto definido, verificado e controlado. seqüência de atividades, dependências,estão coordenados de maneira apro- • Definição do Escopo: Declaração duração e recursos requeridos para apriada, principalmente no que tange a detalhada do escopo do projeto, que confecção do cronograma.harmonização das disciplinas centrais servirá como base para futuras deci- • Controle do cronograma: Controle(escopo, qualidade, tempo e custo) fa- sões de projeto. das possíveis mudanças do cronograma.zendo compensações entre objetivos e • Criação da estrutura analítica doalternativas concorrentes, a fim de atin- projeto (EAP): Divisão das entregas Gerenciamento de Custosgir ou superar as necessidades e expec- em partes menores a fim de facilitar Descreve os processos necessários paratativas dos Stakeholders. o gerenciamento. garantir que o projeto será concluído Processos envolvidos: • Verificação do Escopo: Formali- dentro do orçamento previamente apro- • Termo de abertura do projeto: zação das entregas do projeto finali- vado. Custos e escopo estão fortementeAutorização formal DE um projeto zadas, no final do projeto, no final da relacionados, uma vez que um escopoou uma fase. fase do projeto, ou na liberação das mal definido implicará diretamente nas • Declaração do escopo preliminar: Des- principais entregas. estimativas de custos do projeto.crição em alto nível o escopo do projeto. • Controle do Escopo: Garante que Processos envolvidos: • Plano de gerenciamento do projeto: mudanças sejam acordadas com todos, • Estimativa: Descrição da estimativaListagem das ações de definição, prepa- determina e gerencia quando uma mu- de custos relativa à alocação de recursosração, integração e coordenação, agrega- dança ocorre e com que freqüência o es- para execução do projeto.das aos resultados de todos os demais copo pode mudar. • Orçamentação: Agregação dos cus-processos, compondo um plano de ge- tos estimados para estabelecer umarenciamento do projeto. Gerenciamento do Tempo linha base dos custos totais, a fim de • Execução do plano de projeto: Exe- Contém os processos relativos ao servir para a medição de desempenhocução das ações definidas no plano de controle do término do projeto dentro do projeto.gerenciamento do projeto a fim de aten- do prazo previsto, garantindo o cum- • Controle de custos: Controle dasder aos requisitos definidos na declara- primento dos prazos definidos em um variações e mudanças no orçamento eção do escopo. cronograma de atividades. É conside- identificação das causas dessas varia- • Monitorar e controlar o trabalho do rada a área de maior exigência dentro ções seja positiva ou negativa, sendoprojeto: Monitoramento e verificação do do projeto por ser a que é mais visível que a gestão inapropriada pode causarandamento da execução das ações do em sua gestão. problemas de qualidade e cronograma,plano de gerenciamento do projeto. Processos envolvidos: e elevar o nível de risco. • Controle integrado de mudanças: • Defi nição das atividades: Identifica-Coordenação das mudanças de projeto e ção das atividades dentro do cronogra- Gerenciamento da Qualidadeacompanhamento da aprovação e entrega. ma que precisam ser realizadas para ge- Objetiva garantir a conclusão do proje- • Encerrar projeto: Encerramento for- rar as entregas. to dentro dos níveis desejados de quali-mal do projeto ou de uma fase. • Seqüenciamento das atividades: dade, garantindo a satisfação de todos os Identificação das dependências entre ati- envolvidos no projeto.Gerenciamento do Escopo vidades no cronograma. Principais Dimensões: Composto por processos que garantem • Estimativa de recursos das ativi- • Satisfação do cliente: O projeto deveque o projeto contemple todo o trabalho dades: Estimativa de recursos (tipos e produzir o que se propôs a produzir e o16 Engenharia de Software Magazine – Gerenciamento de Projeto
    • P L A N E J A M E N TOproduto satisfazer as necessidades re- como resultado o plano de gerenciamen- lidade de eventos negativos no projeto,ais do cliente. to de pessoal. tratando os processos de identificação, • Prevenção de erros: O cliente • Contratar / Mobilizar a equipe do análise, resposta, monitoramento, con-sempre é o próximo elemento no pro- projeto: Efetiva obtenção dos recursos trole e planejamento de riscos.cesso, o custo da prevenção é menor humanos necessários para conclusão Processos envolvidos:que o da correção. do projeto. • Planejamento do gerenciamento • Responsabilidades: Todos são res- • Desenvolvimento da equipe: Traba- de riscos: Definição de como tratar,ponsáveis pelo sucesso do projeto, po- lhar a melhoria de competências e inte- planejar e executar as atividades derém a gerência deve fornecer os recursos ração entre membros, a fim de melhorar risco do projeto.necessários para que exista o sucesso. continuamente o desempenho do projeto. • Identificação de riscos: Identificação • Melhoria contínua: O mundo está • Gerenciamento da equipe do pro- / Documentação dos riscos que podemem constante mudança, exigindo o apri- jeto: Trabalhar / Acompanhar o de- afetar o projeto.moramento constante dos mecanismos sempenho individual dos membros da • Análise qualitativa de riscos: Priori-de controle de projetos a fim de garantir equipe, dar e obter feedbacks, tratar zação dos riscos do projeto, levando ema qualidade do produto ou serviço. problemas rotineiros e coordenar mu- consideração a probabilidade dos mes- Processos envolvidos: danças, objetivando aumentar o de- mos ocorrerem e sua freqüência. • Planejamento da qualidade: Identi- sempenho do projeto. • Análise quantitativa de riscos: Aná-ficação/definição dos padrões de quali- lise do efeito dos eventos de risco e atri-dade para o projeto e descrição de como Gerenciamento das Comunicações buição de classificação numérica a essessatisfazê-los. Visa gerar, coletar, distribuir, armaze- riscos, realizada sobre os riscos levanta- • Garantia da qualidade: Aplicação nar e recuperar as informações sobre o dos na análise qualitativa.das atividades de qualidade a fim de projeto de forma oportuna e adequada. • Planejamento de resposta de ris-garantir que serão empregados todos Toda a equipe do projeto deve entender co: Criação de opções e ações com oos processos necessários para atender que as comunicações afetam o projeto intuito de aumentar as oportunidadesaos requisitos dentro dos níveis exigi- como um todo. e reduzir as vulnerabilidades dos obje-dos de qualidade. Processos envolvidos: tivos do projeto. • Controle da qualidade: Monitora- • Planejamento das comunicações: • Monitoramento e controle de riscos:mento / Acompanhamento dos resulta- Determina as necessidades de informa- Acompanhamento dos riscos identifica-dos do projeto, baseando-se nos padrões ções e comunicações às partes interessa- dos, monitoramento dos riscos restantes,estabelecidos de qualidade, garantindo das no projeto. identificação de novos riscos, execução /que os mesmos estão sendo satisfeitos e • Distribuição das informações: Di- avaliação do plano de resposta de riscos.identificando formas de eliminar possí- vulgar às partes interessadas as infor- Este processo é efetuado durante todo oveis resultados insatisfatórios. mações necessárias. ciclo de vida do projeto. • Relatório de desempenho: Confec-Gerenciamento de Recursos ção / Divulgação de relatório de desem- Gerenciamento de AquisiçõesHumanos penho (andamento do projeto, progres- Trata do processo de aquisição de bens, Compreende organizar e gerenciar a so, previsão). produtos e serviços de fornecedores ex-equipe do projeto, essa composta por • Gerenciamento das partes interes- ternos à organização, visando dar condi-pessoas com funções e responsabilida- sadas: Gerenciamento junto às partes ções de realização do projeto.des atribuídas e claramente definidas, interessadas quanto à satisfação de seus Processos envolvidos:possibilitando o uso mais efetivo das requisitos, bem como o gerenciamento • Planejamento de compras e aqui-pessoas envolvidas no projeto. de problemas do projeto. sições: Definição do que, como e Processos envolvidos: quando comprar. • Planejamento de recursos humanos: Gerenciamento de Riscos • Plano de contratações: LevantamentoIdentificação / definição das pessoas e Objetiva aumentar a probabilidade de e discriminação dos produtos, serviços esuas atribuições dentro do projeto, tendo eventos positivos e diminuir a probabi- identificação de possíveis fornecedores. Edição 06 – Engenharia de Software Magazine 17
    • Figura 2. Atividades dos processos da gerência de projetos. • Solicitação de resposta dos fornece- • Iniciação: Define e autoriza for- dores: Obter informações gerais, cota- malmente o início de um projeto ou ções, preços e ofertas. fase, delimitando o escopo e objeti- • Seleção dos fornecedores: Análise e vos preliminares; escolha de possíveis fornecedores, nego- • Planejamento: Define de forma ciação e confecção de um contrato com detalhada os objetivos e propicia o cada fornecedor individualmente. planejamento das ações necessárias • Manutenção do contrato: Geren- para que o projeto seja realizado com ciamento das relações entre comprador sucesso; e fornecedor, bem como das cláusulas • Execução: Integra recursos e pessoas constantes no contrato entre as partes e a fim de realizar o planejamento do pro- análise de desempenho do fornecedor jeto com sucesso;Figura 3. Triângulo do Gerenciamento de Projetos. para contratações futuras e manutenção • Monitoramento / Controle: Moni- das contratações atuais. tora / Mede os resultados do projeto a • Encerramento do contrato: Fina- fim de identificar problemas e solucio- lizar cada contrato, liquidando todos ná-los gerando o mínimo de impacto os itens pendentes. no resultado; • Encerramento: Finaliza formalmente Grupo de Processos da Gerência o projeto ou fase, englobando a aceitação de Projetos do produto / serviço e encerramento for- Como falamos anteriormente, a gerên- mal das atividades. cia de projetos possui cinco grupos de Para esclarecer melhor, a Figura 2 apre- processos que agrupam as atividades das senta o diagrama da interação das ativi- áreas de conhecimento vistas acima em dades apresentadas neste artigo no con- fases bem definidas e complementares: texto destes processos.18 Engenharia de Software Magazine – Gerenciamento de Projeto
    • P L A N E J A M E N TO Os processos interagem entre si atra- em hipótese alguma, um prazo pré-de- e de conhecimentos técnicos da área emvés de seus artefatos de entrada, que são finido pelo stakeholder por conta de uma questão, uma vez que cada área tem suasprocessados com o uso de ferramentas particularidade do seu negócio, um or- particularidades específicas, necessitan-e técnicas; e que geram os artefatos de çamento limitado para atendimento da do assim de uma estruturação diferentesaída que normalmente serão entradas demanda ou um escopo fixo e acordado para cada situação.para outros processos, transformando que não mudará até a entrega. Seja qual Gerenciar um projeto não é simples-decisões, planos e reações em condições for o fator, é importante definir o que não mente controlar cronogramas e ativida-de progresso. pode mudar e isso o ajudará a identificar des para que as mesmas não atrasem, no momento de um problema se o lado é um pouco mais complexo que isso,Variáveis do Gerenciamento definido como fixo está em risco, e dessa passa por identificar claramente as ne-de Projetos forma, o que deverá ser feito para que o cessidades do cliente, estabelecer obje- Principalmente no que se refere a sof- projeto volte à linha natural e atinja os tivos claros e com possibilidade de se-tware, as execuções e entregas devem resultados esperados. rem alcançados e balancear os confl itoslevar em conta algumas variáveis que Com essa premissa podemos assumir o entre custo, prazo e escopo que afetampodem impactar diretamente sobre o re- controle sobre os impactos do projeto e diretamente na qualidade, além de ge-sultado final do projeto. Em gerência de tomar decisões mais consistentes e em- renciar as incertezas do projeto, prin-projetos temos o que chamamos de Tri- basadas tendo sempre como objetivo a cipalmente no que tange a ocorrênciaângulo do Gerenciamento de Projetos, satisfação das expectativas do cliente e o de riscos que precisarão ser avaliadoscomposto pelas variáveis, escopo, tempo sucesso do projeto. e tratados. Um projeto é considerado dee custo, onde cada lado é representado alta qualidade quando é entregue den-por uma dessas variáveis, sendo que a O Gerente de Projetos tro do escopo, no prazo e dentro do or-mudança de um dos lados impacta dire- Agora que já temos uma noção do que çamento estabelecidos e esse é o desafiotamente nos demais (ver Figura 3). Na vi- é gerenciamento de projetos e como po- do Gerente de Projetos.são de alguns profissionais, a qualidade demos usá-lo em nossos projetos e obteré externa ao escopo, logo poderia ser o resultados, vamos focar um pouco no pa- Conclusãoquarto lado, porém a qualidade não é um pel que garante que todos esses proces- O objetivo desse artigo foi desmistificarfator e sim o centro do triângulo, ou seja, sos aconteçam e toma as decisões para o assunto Gerência de Projetos sobre oo resultado do que você faz com o custo, que o mesmo atinja seus objetivos. ponto de vista de que essa é uma área detempo e escopo, e é diretamente afetada Estamos falando do Gerente de Proje- grande importância para todo e qualquerpelas decisões tomadas. to. Esse profissional é responsável por negócio. Para isso, apresentamos alguns Esse triângulo está freqüentemente em gerenciar o progresso do projeto, utili- dos conceitos básicos da área.conflito, pois a mudança em um de seus zando como linha base as variáveis ci-fatores impactará diretamente nos de- tadas anteriormente (qualidade, custo, Referênciasmais. Dessa forma, o objetivo é conciliá- prazo e escopo) através da verificação PMBOK 2004: Um Guia do Conjunto de Conhecimentoslos para obter o resultado esperado. de seus desvios, tendo como principal em Gerenciamento de Projetos – terceira edição - ISBN: Tendo em vista que se o escopo muda, o objetivo a minimização das possibilida- 1-930699-74-3 PMI: www.pmi.orgtempo e custo são diretamente impacta- des de falha do projeto. PMI Brasil: www.pmi.org.brdos, se o tempo é reduzido por conta de A profissão de Gerente de Projetosuma expectativa do stakeholder, os custos pode existir em qualquer ramo de ativi-aumentam e o escopo será reduzido, e dade, podendo-se alocar um Gerente de Dê seu feedback sobre esta edição! Feedbackse o custo está restrito a um orçamento Projetos para gerenciar projetos de todas eu s Dê A Engenharia de Software Magazineprévio e reduzido, o tempo será maior e as espécies, sejam esses, na área de TI, sobre e tem que ser feita ao seu gosto.o escopo menor. Como fazer para conci- construção civil, montagem de automó- Para isso, precisamos saber o que você, s ta ediçãoliar esses fatores? veis, ou qualquer outra. As habilidades leitor, acha da revista! O caminho está em escolher qual lado e experiência necessárias para desempe- Dê seu voto sobre este artigo, através do link:do triângulo é fixo no projeto, ou seja, nhar esse papel dependem diretamente www.devmedia.com.br/esmag/feedbackaquele lado que não poderá ser alterado do tamanho, da complexidade do projeto Edição 06 – Engenharia de Software Magazine 19
    • Utilizando Visualização de Informação para Compreensão de Software De que se trata o artigo: Este artigo apresenta como a visualiza- ção de informação em conjunto com as métricas de código fonte podem ajudar no É cada vez mais evidente a impor- processo de compreensão do software. tância de se ter controle sobre Para que serve: o modo como um software está A cada dia, com o contínuo aumento na sendo desenvolvido. Quando as primei- complexidade dos sistemas de software, ras linguagens de programação foram o processo para análise e compreensão criadas, considerando aspectos como ta- do código visando evolução e manuten- manho e complexidade dos sistemas de- ção do sistema se torna mais complexo e senvolvidos e o conhecimento sobre téc- demorado. Aplicando os conceitos discu- nicas de programação, percebeu-se que tidos neste artigo, podemos tornar estas os desenvolvedores não possuíam uma etapas menos difíceis e trabalhosas. metodologia para estruturação de seu Em que situação o tema é útil: código. Possivelmente, os desenvolve- Atualmente, existem diversas ferramentas dores não imaginavam uma forma bem que auxiliam a modelagem de sistemas, o definida na qual fosse possível analisar controle de versões, testes, que possibilitam os códigos escritos sem ter que, necessa- o desenvolvimento em grupo, mas ainda não riamente, olhar as centenas, ou até mes- é comum o uso de ferramentas que facilitem mo milhares de linhas de código (uma o processo de compreensão do software. Tal- tarefa difícil e custosa). Além disso, re- Eduardo Oliveira Spínola vez por isso, ainda seja comum a existência tirar informações úteis e precisas dessas eduspinola@gmail.com de código duplicado, com alta complexida- É colaborador das revistas Engenharia de Software linhas com objetivo de dar continuidade de, entre outros pontos negativos que redu- Magazine, Java Magazine e SQL Magazine. É bacha- ou manutenção ao sistema não era uma rel em Ciências da Computação pela Universidade zem a qualidade do sistema desenvolvido. A atividade trivial. Salvador (UNIFACS) onde atualmente cursa o mes- partir deste ponto, percebemos a importân- Embora muito tempo tenha se passado trado em Sistemas e Computação na linha de Enge- cia da compreensão do software nas etapas nharia de Software, sendo membro do GESA (Grupo e muita evolução tenha ocorrido no de- de desenvolvimento e manutenção. de Engenharia de Software e Aplicações). senvolvimento de técnicas para apoiar o20 Engenharia de Software Magazine – Utilizando Visualização de Informação
    • P R O J E TOdesenvolvimento de sistemas, a tarefa de do ao exemplo do mapa, é possível que cor está relacionada com o gênero (co-análise de código ainda é um campo com você “descubra” rapidamente, através do média-verde; drama-vermelho; ação-tópicos a serem explorados. Neste con- mapa que utiliza cores, que a região com azul; e suspense-preto), o tamanhotexto, apresentaremos neste artigo o que maior concentração populacional esteja relacionado com a duração e o forma-se tem estudado sobre compreensão de no continente asiático. to indicando se é um dvd ou uma fita.código utilizando técnicas de visualiza- Como o número de habitantes é um Agora imagine que você deseja alugarção de informação, métricas e mineração dado comum e bastante discutido, talvez uma comédia, de longa duração e quevisual de dados e ao final comentaremos este não seja o melhor exemplo. Agora, esteja disponível em DVD. Fácil, não?sobre um plug-in de visualização desen- como você analisaria o código do seu E se quiséssemos apresentar tambémvolvido para o Eclipse. sistema com milhares de linhas para en- o dado que indica o número de vezes contrar os pontos mais complexos, com que o filme foi locado? Seria necessárioVisualização de Informação alto índice de acoplamento e que a refa- relacionar este dado com algum atri- Os seres humanos possuem dificulda- toração se torna indicada para facilitar a buto visual existente ou escolher outrades em processar dados no formato de evolução e manutenção do software? técnica de visualização para a apresen-textos e tabelas; por isso, freqüentemen- Muitas maneiras podem ser utilizadas tação dos dados.te, recorremos a meios visuais para inter- para apresentar dados, dentre elas, o for- Por isso, é importante ressaltar quepretar o mundo a nossa volta [1]. Imagi- mato, cores, movimentos, posicionamen- o formato visual da apresentação dosne por exemplo, dois mapas geográficos to na tela e tamanho. Um exemplo dessa dados pode não somente facilitar, masapresentando o número de habitantes abordagem pode ser visto na Figura 1. também dificultar a análise que se dese-(dado em análise) de cada país. No mapa Através dela, conseguimos notar como a ja fazer. Neste sentido, a escolha correta1, apresentamos sobre cada país o núme- forma, o tamanho e a cor podem ser usa- do paradigma visual e os atributos visu-ro de habitantes. No mapa 2, utilizamos dos para diferenciar os dados. ais que serão usados para representar oscores com tonalidades diferentes para in- Hoje em dia é comum encontrarmos dados tornam-se uma escolha crucial àdicar o dado em análise, onde, a cor mais técnicas de visualização de informação atividade de visualização.escura representa o país com maior po- até mesmo em players de música para O paradigma visual utilizado devepulação. Considerando que seu interes- dispositivos móveis, onde cada música se adaptar à natureza dos dados re-se seja estudar os países com população é representada por um ponto e este pon- presentados. Por exemplo, grafos sãoentre 50 e 100 milhões, qual mapa você to é inserido em um plano. Os pontos adequados para representar dados queutilizaria para obter esta informação de mais a esquerda indicam que aquelas descrevem relacionamentos (por exem-maneira mais rápida e segura? músicas possuem um ritmo mais rápi- plo, sites de relacionamento podem ser O objetivo da visualização de infor- do, pontos localizados a direita, músicas representados através de grafos). Ár-mação é possibilitar que dados sejam lentas e assim por diante. Com isso, para vores são adequadas para representarapresentados através de formas simples escolher as músicas que você deseja ou- dados hierárquicos (por exemplo, es-e intuitivas [2]. vir basta marcar o plano com o ponto, trutura de diretórios). A grande preocupação da visualização então o programa defi nirá um raio e Uma vez defi nido o paradigma visu-de informação é como os dados serão tocará apenas as músicas que estiverem al, vários atributos visuais podem serapresentados, pois uma boa escolha da dentro da região especificada. associados aos dados a serem represen-forma de apresentação resulta na facili- Imaginemos que cada símbolo geo- tados. A adequação de um atributo vi-dade do entendimento e possibilita a des- métrico da Figura 1 representa um fil- sual ao dado depende da escala e tipocoberta de (novas) informações. Voltan- me de uma pequena locadora, onde a desse último atributo. Para exemplificarFigura 1. Dados representados através da cor, tamanho e forma. Edição 06 – Engenharia de Software Magazine 21
    • esta situação, imagine representar todos o mapeamento mais indicado para a sua Para uma boa escolha da forma de apre-os países participantes de uma copa do representação visual. Voltando ao exem- sentação, é preciso conhecer a respeito domundo utilizando apenas duas cores. plo da copa do mundo onde desejamos domínio no qual os dados serão utiliza- Os dados podem ser do tipo categóri- representar visualmente o registro dos dos, como esses dados serão utilizados,co ou numérico. Enquanto os dados ca- países participantes. Caso se decida re- as informações que serão apresentadas etegóricos não possuem um sentido de presentar o país por cores, espera-se que o objetivo da apresentação dos dados.ordem ou unidade, os dados numéricos a cor usada para representar cada país Após escolher a forma de apresentação,possuem. Considere o caso da análise de esteja relacionada com a nossa percep- o projetista deve levar em consideraçãosistema de softwares que queremos vi- ção natural. Por exemplo, o registro do alguns dos fatores como: o tipo dos da-sualizar; neste caso, o nome dos pacotes, Brasil poderia estar representado com dos, se estes são textuais e/ou numéricos;classes e métodos são dados categóricos, a cor verde ou amarela e o registro dos se existe a necessidade de interação entreenquanto o tamanho e a complexidade Estados Unidos representado pela cor o usuário e os dados; com que freqüênciados métodos são dados numéricos. vermelha ou azul. os dados apresentados devem ser atuali- Atributos numéricos podem ser mape- Dado o cenário acima descrito e a ta- zados; e se o usuário está interessado emados naturalmente para atributos visuais refa que temos em mão – representar informações precisas ou na relação entrecomo tons de cores, tamanho e posicio- visualmente atributos do código fonte o conjunto de dados.namento na tela. Atributos categóricos do software – temos que escolher que Analisaremos agora como acontece opodem ser mapeados naturalmente para paradigma e atributos visuais melhor se processo de visualização, discutindoformas e conjuntos diferentes de cores. É adaptam para representar a estrutura e todas as etapas existentes, partindo dosimportante ressaltar que o tipo e a natu- as métricas dos sistemas de software que dados brutos até a interação do usuárioreza do dado pode também sugerir qual queremos analisar. com as visões. Processo de Visualização Para que os dados possam ser apresen- tados visualmente, eles devem passar por um processo de mapeamento, como pode ser visto na Figura 2 [1]. A Figura 2 mostra o processo de visu- alização de informação, contendo três fases: (1) Preparação dos dados, onde os dados são organizados e formatados para que a aplicação possa entendê-los; (2) Mapeamento, etapa em que os dadosFigura 2. Mapeamento de dados para formas visuais 2 Figura 4 Mapeamento visual 4.Figura 3 Transformação dos dados 3.22 Engenharia de Software Magazine – Utilizando Visualização de Informação
    • P R O J E TOsão relacionados com as formas que serão A partir das estruturas visuais monta- iconográficas usam símbolos ou íconesutilizadas para a visualização; (3) Rende- das, o usuário poderá interagir com as para representar os dados. Um exemplorização, momento em que a imagem é informações, obtendo diferentes visões de utilização desta técnica são os íconesapresentada na tela. As setas que saem dos dados apresentados. utilizados na janela de exploração deda direita para a esquerda representam projeto dos IDEs modernos. Pequenosa realimentação feita pelo ser humano Interação Humana ícones são utilizados para representarpara explorar os dados que são apresen- O processo de exploração visual envol- pacotes, serviços, classes, interfaces etados de forma visual. A partir de agora ve não apenas a construção de estruturas outros componentes do soft ware.analisaremos cada uma das etapas apre- visuais, mas também a interação huma- Abordagens baseadas em projeções ge-sentadas na Figura 2. na sobre esta estrutura. O processo de ométricas são as mais comuns no dia a interação ocorre conforme mostrado na dia das pessoas. Elas utilizam projeçõesDados Brutos e Tabela de Dados Figura 2, sendo realizado em três mo- cartesianas ou polares para apresentar Os dados brutos são os dados que que- mentos. O primeiro momento é na sele- gráficos e diagramas aos usuários.remos analisar ainda no formato de ção do conjunto de dados que será apre- Abordagens baseadas em grafos sãoorigem. Ele pode estar no formato de sentada visualmente. O segundo ocorre utilizadas para apresentar relaciona-tabelas, textos ou formulários. No nos- no mapeamento dos atributos dos dados mento entre registros de dados, taisso caso, os dados brutos é o código fon- selecionados com atributos visuais que como o acoplamento entre módulos dete. A partir do processo de preparação serão apresentados na tela. O terceiro software ou relacionamento social entreou transformação, os dados são adap- momento acontece na interação do usu- dois programadores. Os registros são re-tados para uma forma estruturada, e ário com a visão formada, criando novos presentados por nós e o relacionamentoque permitirá a sua utilização pela fer- cenários visuais. por arestas de um grafo.ramenta de visualização. É importante mencionar que boas fer- Como o nome indica, as abordagens Normalmente, o resultado do pro- ramentas de visualização permitem a hierárquicas são utilizadas para organi-cessamento dos dados brutos são re- execução de qualquer uma dessas três zar dados de forma hierárquica. Este épresentados no formato tabular, onde formas de interação (seleção de dados, o caso de um sistema de arquivos ou acada linha representa um registro de o mapeamento visual e a modificação estrutura de pacotes, classes e métodosdados e cada coluna representa um da visão), através de mecanismos fáceis de um sistema de software.atributo, ou campo do registro de da- de manusear. Para garantir máxima Poderíamos enumerar várias aborda-dos. Seguindo nosso objetivo, o resul- interatividade, este tipo de ferramenta gens para cada uma destas famílias detado do processamento do código fonte atualiza o cenário visual no menor tem- representação visual. No restante deste(veja a Figura 3) será um arquivo com po possível em resposta a uma ação do artigo utilizaremos mapas em árvore paraos dados extraídos das classes (pacote, usuário. Boas ferramentas oferecem um exemplificar a utilização de uma abor-classe, método, tamanho e complexida- tempo de resposta praticamente instan- dagem hierárquica de representação dede). Estes dados são extraídos utilizan- tâneo para o usuário, garantindo uma código fonte.do métricas de software, que veremos interatividade que por vezes lembra amais adiante neste artigo. de um vídeo game. Mapas em árvore Uma boa forma de representar dadosEstruturas Visuais e Visões Abordagens para Visualização organizados de forma hierárquica é uti- Na visualização, tabelas de dados de Dados lizando estruturas visuais conhecidassão mapeadas em estruturas visuais. Existem várias abordagens para se como mapas em árvore [3].É neste momento que os dados são re- criar cenas visuais. As famílias de abor- A técnica de mapas em árvore, propos-lacionados com as formas utilizadas dagens mais comuns são as baseadas ta originalmente por Johnson e Shneider-para apresentação da informação (ob- em iconografia, projeções geométricas, mann [4], consiste em representar o nívelserve a Figura 4). grafos e hierarquias. As abordagens mais alto da hierarquia como uma regiãoFigura 5 Uma árvore hierárquica e sua representação em um mapa em árvore 5. Edição 06 – Engenharia de Software Magazine 23
    • retangular que preenche todo o espaço to ou da estrutura do mesmo por um cilitado se a abordagem possibilita quedisponível na área de desenho. Os níveis programador. Como temos memória o usuário interaja com as informaçõesmais baixos são representados por retân- de curto prazo pequena, não somos através de mecanismos de análise, ex-gulos recursivamente aninhados dentro capazes de armazenar muitos itens ploração e visualização em diferentesda região maior, conforme ilustrado na de informação durante o processo de níveis de abstração.Figura 5. O tamanho de cada retângulo é compreensão de um sistema [5]. Por Note ainda que abordagens baseadasproporcional ao atributo que dimensiona essa razão, é normal que os desenvol- em relacionamentos (grafos), iconogra-os itens nos níveis imediatamente abaixo vedores sintam dificuldade em anali- fia e projeções geométricas também têmna hierarquia. sar muitas informações diferentes, e muito a oferecer para a área. Esta técnica de visualização permite que interagem entre si. A solução para A partir do momento em que as dificul-que todo o espaço disponível na tela este problema está numa frase bastan- dades são eliminadas, pode-se esperarde desenho seja utilizado, limitando- te conhecida em nossa área: “Dividir vários benefícios com o uso de técnicasse somente à área de exibição das in- para conquistar!”. Então, organizamos de visualização de software. Dentre eles,formações dentro de cada grupo (re- a informação em níveis diferentes de podemos citar: entendimento do softwa-tângulo). Essa abordagem permite que abstração, onde grandes sistemas são re de forma mais rápida, aumento dehierarquias com dezenas de milhares inicialmente percebidos como pou- produtividade, e melhoria na manuten-de itens possam ser desenhados em cos módulos de grande porte que in- ção, análise, e evolução do software [6].uma única cena visual. teragem entre si. Por sua vez, esses módulos podem ser analisados como Tipos de visualização de softwareUtilizando visualização para conjuntos de sub-módulos que intera- Voltado para a área de software, te-compreensão de software gem entre si, e assim por diante. Dessa mos dois tipos de visualização: estáti- Quando uma pessoa aprende sobre al- forma, a compreensão de um grande ca e dinâmica.gum assunto, ela se torna capaz de dis- sistema pode ser dividida na compre- A visualização estática é a visualizaçãocutir e explicar sobre aquilo que apren- ensão de seus sub-módulos. feita das estruturas estáticas do softwa-deu. Um processo similar ocorre com os Esse processo prossegue recursiva- re. Por exemplo, os dados extraídos dadesenvolvedores de software. Quando mente até o nível de detalhe desejado estrutura de um código fonte qualquer.estes entendem o funcionamento do pelo analista. Dessa forma, utilizamos A partir desses dados é montada umaprograma, é normal que saibam explicar um processo hierárquico, onde um forma visual que representa informaçõescomo o sistema funciona, qual a estrutu- grande problema é recursivamente di- sobre o código a ser analisado.ra utilizada, e também como modificá-lo vidido em problemas menores em um Neste tipo de visualização, não é apre-para se enquadrar a novos objetivos. nível de abstração que permite que um sentado o comportamento de execução Porém, entender o funcionamento do ser humano, com limitações que lhe são do sistema sendo analisado.soft ware não é uma atividade trivial. naturais, possa compreender e analisar A visualização dinâmica tem o objetivoDentre os problemas que dificultam o grandes sistemas. de apresentar estruturas visuais que des-entendimento de um sistema, podemos Dado esse cenário, pode-se notar a uti- crevem o comportamento ou funciona-destacar: o tamanho da aplicação, a sua lidade de uma abordagem hierárquica mento do sistema em tempo de execução.complexidade, as práticas de programa- de visualização soft ware. Tal aborda- Um exemplo desse tipo de visualizaçãoção e as características da linguagem de gem permite que o programador en- são os sistemas de animação de algorit-programação usadas na sua construção. tenda o funcionamento e a organização mos computacionais [7]. Outro exemplo O processo de compreensão do códi- do sistema de uma forma mais rápida, são as visualizações de execução cons-go é caracterizado pela construção de eliminando a maioria das dificuldades truídas pelos sistemas modernos de de-um modelo mental do funcionamen- citadas no parágrafo anterior. Isto é fa- puração de código.24 Engenharia de Software Magazine – Utilizando Visualização de Informação
    • P R O J E TOUtilizando Métricas na Visualização de desenvolvimento de software. Muitas A importância em se conhecer o ta-de Software destas estão diretamente relacionadas ao manho do código está na provável re- Métricas de software têm sido aponta- paradigma da linguagem de programa- lação que indica: quanto maior for odas como um dos principais mecanis- ção, como é o caso das métricas orienta- número de linhas, maior será a dificul-mos para tornar o desenvolvimento e das a objeto. Entretanto, existem aquelas dade para entender o sistema, quantomanutenção de soft ware uma disciplina que independem do paradigma de desen- maior for o número de linhas de có-mais previsível e controlável [8]. Medir volvimento adotado. A Tabela 1 apresen- digo, mais difícil será para encontraré uma prática básica em qualquer tipo ta algumas métricas de código fonte [8]. as linhas que precisam ser alteradasde engenharia, e na “engenharia de sof- A visualização estática de software é a durante atividades de evolução, e maistware” não é diferente. Várias métricas mais atrativa e comum nos dias de hoje. difícil será para entender a implemen-têm sido propostas para se medir atri- Ela é construída através da análise está- tação das funcionalidades que se dese-butos como tamanho, complexidade, tica de artefatos de software. Métricas de ja reutilizar.coesão e acoplamento dos mais variados código fonte podem ser facilmente com-artefatos de soft ware. binadas a estes paradigmas, pois elas são Métrica de complexidade As métricas estão relacionadas tan- extraídas diretamente do artefato estático A medição da complexidade de sof-to com o produto, como com processos mais completo de um software, o seu có- tware foi proposta por Thomas McCabede desenvolvimento e manutenção do digo fonte. Estas métricas podem ser usa- e baseia-se na representação do fluxo desoftware. A partir delas, conseguem-se das para enriquecer as estruturas visuais controle de um programa. A complexi-dados quantitativos que oferecem uma extraídas da análise estática do software. dade pode ser alta ou baixa, a dependerboa informação sobre o andamento do Em seguida, descrevemos três métricas do número de estruturas de decisão den-projeto. Com essas informações, é possí- bastante utilizadas na visualização de sof- tro do código.vel fazer a estimativa de custos, prazos tware: tamanho, complexidade e coesão. Quanto maior a complexidade de umde entrega e até mesmo ter noção sobre a módulo do sistema, mais difícil é suaqualidade do sistema [8]. Métrica de tamanho compreensão e manutenção. As métricas de produto são de especial Uma das métricas de código fonteinteresse na visualização do software. bastante conhecida é a métrica res- Métrica de coesãoElas descrevem características como ta- ponsável pela extração do tamanho Esta métrica mede a falta de coesão demanho, complexidade, características de de código. Apesar de ser uma métrica uma estrutura do código, por exemplo,design e níveis de qualidade do software. bastante simples, ela pode ser feita de a falta de coesão de uma classe. Sua Entre as muitas métricas de produto, as várias formas. Uma delas é contar as importância está no fato de que classesmétricas de código fonte estão entre as linhas por statements. Dessa forma, (componentes) com baixa coesão suge-mais importantes. Elas estão associadas cada statement representará uma linha rem um projeto inadequado, significandoao produto de mais baixo nível de abstra- de código, com isso, pode-se evitar a o encapsulamento de entidades de pro-ção e maior nível de detalhe que é mani- contagem a mais de linhas, devido a grama não relacionadas entre si e quepulado por um ser humano no processo diferentes estilos de programação. não deveriam estar juntas. Métrica Aplicada em Atributo O que medem Cyclomatic complexity – CC (McCabe, 1976) Classes e métodos Complexidade Complexidade e alternativas possíveis no controle de fluxo Lines of Code – LOC (Lorenz e outros, 1994) Classes e métodos Tamanho Obter o tamanho das classes e métodos Depth of Inheritance Tree – DIT (Chidamber e outros, 1994) Classes e interfaces Herança Reuso, compreensão e teste Number of Children – NOC (Chidamber e outros, 1994) Classes e interfaces Herança Reuso Response for Classe – RFC (Chidamber e outros, 1994) Classes Comunicação Acoplamento, complexidade e pré-requisitos para teste Coupling between object classes – CBO (Chidamber e outros, 1994) Classes Comunicação Coesão e reuso Lack of Cohesion in Methods – LCOM (Chidamber e outros, 1994) Classes Comunicação Coesão, complexidade, encapsulamento e uso de variáveis Weighted Methods per Class – WMC (Chidamber e Kemerer, 1994) Classes Complexidade Complexidade, tamanho, esforço para manutenção e reuso Number of Methods – NOM (Lorenz e outros, 1994) Métodos Tamanho Corresponde a WMC onde o peso de cada método é 1 Number of Statements – NOS (Lorenz e outros, 1994) Métodos Tamanho Obter o número de sentenças em um método Number of Instance Variables – NIV (Lorenz e outros, 1994) Classes Tamanho Obter o número de variáveis de instância Number of Class Variables - NCV (Lorenz e outros, 1994) Classes Tamanho Obter o número de variáveis de classe Number of Inherited Methods – NMI (Lorenz e outros, 1994) Métodos Herança Obter o número de métodos herdados e definidos em uma superclasse Number of Overriden Methods – NMO (Lorenz e outros, 1994) Métodos Herança Obter o número de métodos definidos em uma superclasse e rede- finidos na subclasseTabela 1. Exemplo de métricas de código fonte [8] Edição 06 – Engenharia de Software Magazine 25
    • Figura 6. SourceMiner Plugin Quanto maior for o grau de coesão en- consulta. Através deles o usuário pode in- ses normais de um pacote; a relação entre ostre diferentes ações executadas por um teragir com o cenário padrão criando dife- pacotes, contabilizando a quantidade de mé-componente que contribui para dife- rentes cenários, possibilitando a análise do todos existentes dentro deles; entre outros.rentes funcionalidades, mais difícil será sistema em diferentes níveis de abstração. Para obter mais informações sobre opara manter ou reutilizar o componente Há pouco perguntei como analisar o SourceMiner e baixá-lo para teste, acesse oou uma de suas funcionalidades. código de um sistema contendo milhares endereço http://www.nuperc.unifacs.br/tools. de linha? Como verificar quais os trechosUma Ferramenta de Compreensão mais indicados para refatoração? Conclusãode Software Agora, observe novamente a Figura 6. Apresentamos neste artigo como a vi- Com a fundamentação dos principais Neste cenário, o tamanho dos retângulos sualização de informação pode ser uti-conceitos, apresentaremos um plug-in representa o tamanho dos métodos e a lizada para facilitar a compreensão dechamado SourceMiner, que está sendo cor representa a complexidade. Conside- software e tornar menos difícil a tarefadesenvolvido pelo GESA, Grupo de En- rando que métodos muito grandes e com de manutenção de sistemas de software.genharia de Software e Aplicações da alta complexidade são um importante Para isso, foi discutido sobre o processoUniversidade Salvador [9]. indicativo da necessidade de refatoração, de visualização, técnicas de visualiza- O funcionamento do plug-in está dividido fica fácil verificar em apenas uma tela ção, e métricas de software, mais especi-basicamente em três etapas, extração das todo o projeto, ao invés de abrir centenas ficamente, métricas de código fonte.informações e métricas do código fonte, de arquivos para obter tais informações. No final do artigo, exibimos a junçãocriação das estruturas visuais, e criação dos Observe também a aba View Chart, nela destes conceitos em um plug-in que utilizacontroles de consulta. A Figura 6 apresenta várias informações sobre o projeto são apre- diversos paradigmas de visualização como plug-in em execução, utilizando como ce- sentadas através de gráficos em pizza e em o intuito de fornecer ao engenheiro de sof-nário a técnica de mapas em árvore. Na aba barras, por exemplo: a relação entre interfa- tware e/ou desenvolvedor, diversas pers-localizada à direita, estão os controles de ces, classes internas, classes abstratas e clas- pectivas sobre a estrutura do código fonte de um sistema de software. Espera-se, com Referências isso, que o processo de desenvolvimento, manutenção e evolução de sistemas se torne Almeida, Márcio Oliveira. Uma Ferramenta para Mineração Visual de Dados Usando Mapas em Árvore e Suas Aplicações. Dissertação de Mestrado. Universidade Salvador. Salvador. Abril, 2003. uma tarefa menos trabalhosa e cansativa. Gershon, N; Elick, S.G. Information Visualization. IEEE Computer Graphics and Applications. Los Alamitos, p.29-31, 52-59, 1997. Shneiderman, B. Tree visualization with tree-maps: 2-d space-filling approach. ACM Transactions on Graphics, v. 11 , n. 1, p. 92-99, Jan. 1992. Johnson, Brian; Shneiderman, Ben. Tree-Maps: A space-filling approach to the visualization of hierarchical information structures. In: IEEE VISUALIZA- Dê seu feedback sobre esta edição! Feedback eu TION, 1991, San Diego. Proceedings… Los Alamitos: IEEE Computer Society Press, 1991. p.284-291. s Dê Campos, Marcelo Ricardo. Compreensão Visual de Frameworks através da Introspecção de Exemplos. Tese de Doutorado. UFRGS. Porto Alegre. 1997. A Engenharia de Software Magazine sobre e Fyock, Daniel E. Using Visualization to Maintain Large Computer Systems. IEEE Computer Graphics and Applications. Los Alamitos, p.73-75, 1997. tem que ser feita ao seu gosto. Hamilton, Ashley - Washington University at St. Louis; Kraemer, Eileen; Tudoreanu, Mihail; Wu, Rong - University of Georgia. Empirical Evidence that Para isso, precisamos saber o que você, s ta Algorithm Animation Promotes Understanding of Distributed Algorithms. IEEE Symposia on Human Centric Computing Languages and Environments edição (HCC’02) p. 236, 2002. leitor, acha da revista! Carneiro, Glauco de Figueiredo. Usando Medição de Código Fonte para Refactoring. Dissertação de Mestrado. Universidade Salvador. Salvador. Abril, 2003. Dê seu voto sobre este artigo, através do link: Carneiro, Glauco de Figueiredo; Magnavita, Rodrigo; Spínola, Eduardo Oliveira; Spínola, Fábio Oliveira; Mendonça, Manoel Gomes. An Eclipse-Based Visualization Tool for Software Comprehension. Publicado no SBES 2008 – Sessão de Ferramentas – Campinas, Brasil. www.devmedia.com.br/esmag/feedback26 Engenharia de Software Magazine – Utilizando Visualização de Informação
    • AMIGO calhau ...só pra lembrar,Existem coisas sua assinatura pode estar acabando!que nãoconseguimosficar sem! Renove Já! www.devmedia.com.br/renovacao Para mais informações: www.devmedia.com.br/central
    • Fundamentos de Arquitetura de Software De que se trata o artigo: senvolvimento de software, o mesmo pode Este artigo apresenta os fundamentos ser observado ao se analisar os requisitos da arquitetura de software. São descritos visando a construção de um software: várias a importância e o papel da arquitetura de soluções computacionais podem ser defi- software no processo de desenvolvimen- nidas para atender a esses requisitos, mas to. Também são identificadas as principais uma análise deve ser feita para definir a mais atividades realizadas durante o processo adequada ao contexto de desenvolvimento de especificação arquitetural. da aplicação. Para se representar essas solu- Para que serve: ções, a arquitetura de software é uma das Rodrigo Oliveira Spínola Quando tentamos solucionar um pro- abordagens que podem ser usadas. rodrigo@sqlmagazine.com.br blema, é possível identificar diversas solu- Em que situação o tema é útil: Doutorando em Engenharia de Sistemas e Com- putação (COPPE/UFRJ). Mestre em Engenharia ções que poderiam ser utilizadas visando No entendimento dos fundamentos da ar- de Software (COPPE/UFRJ, 2004). Bacharel em resolvê-lo. Contudo, outros fatores como quitetura de software. Conhecimento este Ciências da Computação (UNIFACS, 2001). Co- custo e eficiência influenciam na escolha da fundamental na elaboração da arquitetura laborador da Kali Software (www.kalisoftware. solução a ser adotada. No contexto do de- de aplicações em projetos reais. com), tendo ministrado cursos na área de Qua- lidade de Produtos e Processos de Software, Re- quisitos e Desenvolvimento Orientado a Objetos. Q uando tentamos solucionar um feita para definir a mais adequada ao con- Consultor para implementação do MPS.BR. Atua problema, é possível identificar di- texto de desenvolvimento da aplicação. como Gerente de Projeto e Analista de Requisitos em projetos de consultoria na COPPE/UFRJ. É versas soluções que poderiam ser Para se representar essas soluções, a Colaborador Engenharia de Software Magazine. utilizadas visando resolvê-lo. Contudo, ou- arquitetura de software é uma das abor- tros fatores como custo e eficiência influen- dagens que podem ser usadas. Com isso, Rafael Ferreira Barcelos ciam na escolha da solução a ser adotada. para se obter a arquitetura (solução) mais rbarcelos@gmail.com No contexto do desenvolvimento de sof- adequada para atender aos requisitos do É Mestre na área de Engenharia de Software tware, o mesmo pode ser observado ao se software (problema), uma avaliação des- da COPPE/UFRJ, atualmente trabalha como Software Development Engineer in Test na analisar os requisitos visando a construção sa estrutura deve ser realizada. Microsoft em Redmond/USA. Possui 5 anos de de um software: várias soluções computa- A arquitetura consiste em um modelo de experiência em desenvolvimento de software cionais podem ser definidas para atender a alto nível que possibilita um entendimen- tanto para sistemas de informação quanto para esses requisitos, mas uma análise deve ser to e uma análise mais fácil do software a sistemas específicos, como por exemplo celular.28 Engenharia de Software Magazine – Fundamentos de Arquitetura de Software
    • P R O J E TOser desenvolvido. O uso de arquiteturapara representar soluções de soft warefoi incentivada principalmente por duastendências (GARLAN e PERRY, 1995;KAZMAN, 2001): (1) o reconhecimentopor parte dos projetistas que o uso deabstrações facilita a visualização e oentendimento de certas propriedadesdo soft ware, e (2) a exploração cada vezmaior de frameworks visando diminuiro esforço de construção de produtosatravés da integração de partes previa-mente desenvolvidas. Outra propriedade da arquitetura é apossibilidade de usá-la como ferramenta Figura 1. Elementos usados na construção de uma arquitetura.para comunicar a solução projetada aosdiversos stakeholders que participam doprocesso de desenvolvimento do softwa- consistentes sobre estes termos podem Contudo, mesmo existindo padrõesre (GARLAN, 2000). Contudo, para que ser encontradas na literatura. que indicam o tipo de informação queessa comunicação seja possível, a arqui- Arquitetura de software representa deve ser descrito em um documento ar-tetura deve ser representada através de a estrutura, ou conjunto de estrutu- quitetural, não é definido exatamente oum documento, conhecido como docu- ras, que compreende os elementos de nível de abstração que deve ser usado namento arquitetural. software, suas propriedades externa- descrição dessas informações. Para se construir a arquitetura de um mente visíveis e seus relacionamentos A arquitetura de um software começa asoftware, e por conseqüência o docu- (BASS et al., 2003). ser construída nos estágios iniciais de ummento arquitetural que a representa, os Para criar essa estrutura, grande par- processo de desenvolvimento de softwa-requisitos são as principais informações te dos autores concorda que três tipos re com o objetivo de definir e visualizarusadas. Durante o processo de especifi- de elementos básicos podem ser usados a solução computacional que será imple-cação arquitetural (Figura 1), além dos (DIAS e VIEIRA, 2000): mentada. Neste momento, esse artefato érequisitos, outras fontes de conhecimen- • Elementos de software, podendo tam- conhecido como arquitetura inicial, per-to podem ser utilizadas para definir os bém ser chamados de módulos ou com- tence ao escopo do problema, tem comoelementos arquiteturais e a forma como ponentes, são as abstrações responsáveis principal característica descrever a solu-eles devem estar organizados. Entre es- por representar as entidades que imple- ção em um elevado nível de abstração esas fontes de conhecimento se destacam mentam funcionalidades especificadas; é utilizado por vários stakeholders comoprincipalmente a experiência do arquite- • Conectores, podendo ser chamados base para tomada de decisões.to, o raciocínio sobre os requisitos, e os de relacionamentos ou interfaces, são as Contudo, ao longo do desenvolvimen-estilos e as táticas arquiteturais. abstrações responsáveis por representar to do software, a arquitetura sofre re- Contudo, existe uma falta de consen- as entidades que facilitam a comunica- finamentos que diminuem o nível deso na comunidade em relação tanto aos ção entre os elementos de software; abstração e permitem, por exemplo, aconceitos e definições básicas quanto à • Organização ou configuração que representação dos relacionamentos en-forma de representar uma arquitetura consiste na forma como os elementos de tre os elementos arquiteturais e os ar-de software (BUSCHMANN et al., 1996; software e conectores estão organizados. quivos de código fonte responsáveis porCLEMENTS et al., 2004). Portanto, na Além disso, essa estrutura e as enti- implementá-los (CLEMENTS et al., 2004).próxima seção são descritos os termos dades que a compõem devem ser re- Neste momento, a arquitetura passa aaqui adotados e seus respectivos concei- presentadas de uma forma que permi- pertencer ao escopo da solução e incor-tos associados. Além disso, são descritos ta utilizar a arquitetura projetada para pora também informações relacionadasa importância e o papel da arquitetura seus devidos fins, a essa representação às decisões de projeto, como elementosde software no processo de desenvolvi- é dado o nome de documento arquite- específicos à tecnologia que será usadamento, e, por fim, são identificadas as tural. Esse documento é composto por para implementar a solução.principais atividades realizadas durante um conjunto de modelos e informações O fato da arquitetura representar in-o processo de especificação arquitetural. que descrevem principalmente a es- formações em diferentes níveis de abs- trutura do software especificado para tração ao longo do processo de desen-Definição dos conceitos relacionados atender aos requisitos. Para compor volvimento é um dos motivos que levaà arquitetura de software um documento arquitetural, podemos à falta de consenso na comunidade, pois Nessa seção, são definidos os termos nos basear, por exemplo, nas recomen- ainda não se padronizou a granularida-utilizados neste trabalho, evitando am- dações descritas no padrão IEEE-1471 de que deve ser usada para descreverbigüidades, visto que terminologias in- (IEEE, 2000). esse artefato. Edição 06 – Engenharia de Software Magazine 29
    • No contexto desse artigo, iremos A principal motivação para avaliar a das diversas características do sistema.trabalhar somente com a arquitetura arquitetura de um software está relacio- Um gerente pode, por exemplo, usar ainicial, ou seja, a que representa a es- nada ao seu papel dentro do processo de arquitetura como base para definir astrutura em um elevado nível de abs- desenvolvimento. equipes de desenvolvimento de acordotração. Acreditamos que o uso de ar- Possuindo o documento arquitetu- com os elementos arquiteturais que estãoquitetura para representar a solução ral do sistema, os stakeholders podem identificados na arquitetura e que devemem um baixo nível de abstração não utilizá-lo como artefato de entrada na ser construídos.é adequado devido à existência de di- realização de algumas atividades do • Desenvolvedor. Da arquitetura deversos tipos de representação de pro- processo ou então como base para toma- um soft ware, o desenvolvedor buscajeto de baixo nível, como diagramas da de decisões no contexto do projeto. uma especificação que descreva a solu-de classe e de seqüências, que permi- Para cada stakeholder, a arquitetura do ção com detalhes suficientes e que sa-tem uma representação mais comple- soft ware é utilizada com diferentes pro- tisfaça os requisitos do cliente, mas queta desse tipo de informação. pósitos (GACEK, 1995; XAVIER, 2001; não seja tão restritiva a ponto de limitar A partir de agora, identificaremos os CLEMENTS et al., 2004): a escolha das abordagens para a sua im-papéis que a arquitetura possui no pro- • Cliente. O cliente é a pessoa ou em- plementação. Os desenvolvedores usamcesso de desenvolvimento de software presa que contrata uma equipe de de- a arquitetura como uma referência parae os benefícios que podem ser obtidos senvolvimento para a construção de um a composição e o desenvolvimento dosao avaliá-la. sistema de sua necessidade. Na fase ini- elementos do sistema, e para a identifi- cial do projeto, esse stakeholder necessi- cação e reutilização de elementos arqui-Papel da arquitetura em um proces- ta de uma estimativa de certos fatores, teturais já construídos.so de desenvolvimento de software normalmente econômicos, que podem • Testadores. A arquitetura fornece,e os benefícios de sua avaliação ser obtidos após a definição da estrutu- numa visão de caixa preta, informa- Ao revisar um artefato de software vá- ra principal do software. O cliente, por ções aos testadores relacionadas aorios benefícios para o projeto e para a exemplo, tem interesse em estimativas correto comportamento dos elementosmelhoria da qualidade do software po- de custo, confiabilidade e manutenibili- arquiteturais que se integram. Sendodem ser obtidos. Contudo, para que essa dade do software que podem ser obtidos assim, este artefato pode ser um dosatividade seja realizada, recursos devem principalmente através de uma análise artefatos bases utilizados durante oser alocados, o que pode aumentar o cus- da arquitetura. Portanto, é de extrema planejamento e execução de testes deto final do projeto. importância para o cliente que a arquite- integração e de sistema. Portanto, antes de realizar a revisão de tura atenda os requisitos do software de • Mantenedor. A descrição arqui-um artefato, é imprescindível que a im- forma a representar suas reais expectati- tetural do software fornece aos man-portância desse artefato dentro do pro- vas em relação ao que foi especificado. tenedores uma estrutura central dacesso de desenvolvimento seja identifica- • Gerentes. A arquitetura permite aos aplicação que idealmente não deve serda, permitindo definir o custo/benefício gerentes tomarem certas decisões de violada. Qualquer mudança deve pre-de sua revisão. projeto por possibilitar a sumarização servá-la, buscando, se possível, uma Figura 2. Processo genérico de especificação arquitetural30 Engenharia de Software Magazine – Fundamentos de Arquitetura de Software
    • P R O J E TOmodificação puramente dos elementos durante a macro-atividade de projeto ar- Os requisitos funcionais são responsá-arquiteturais e não da forma como es- quitetural e é responsável por registrar as veis por descreverem as funcionalidadestão organizados. decisões e os elementos arquiteturais. que o software deve apresentar. Já os Visto como os principais stakeholders Após identificarem que a solução des- não-funcionais descrevem característi-podem utilizar a arquitetura de um sof- crita na arquitetura atende a todos os re- cas que o software deve apresentar, mui-tware, percebemos que o principal papel quisitos especificados, os arquitetos dão tas vezes podem ser enxergadas comodesse artefato é servir como instrumen- início à atividade de avaliação arquitetu- restrições ou especialidades do produtoto para comunicar a solução proposta ral que utiliza como principal artefato de final. Os requisitos podem ter várias sub-(GARLAN, 2000). entrada o documento arquitetural. categorias como requisitos de qualidade, Sendo assim, o principal benefício em se Após a avaliação, dependendo da qua- requisitos legais e etc.avaliar um documento arquitetural está na lidade do documento arquitetural e por Dentre os diferentes tipos de requisitos,diminuição das chances de um stakehol- conseqüência da arquitetura projetada, o tanto funcionais quanto não-funcionais,der utilizar um documento defeituoso nas arquiteto decide se o artefato será reava- os requisitos de qualidade são os queatividades subseqüentes do processo de liado visando atingir a qualidade deseja- mais influenciam na construção da ar-desenvolvimento de software. da ou então se o processo de especifica- quitetura. Isso ocorre visto que, diferente Contudo, para permitir uma melhor ção arquitetural será finalizado. dos requisitos funcionais onde na maio-compreensão sobre como e o que deve A seguir, é mostrado para cada um ria dos casos uma modificação ocasionaser avaliado em um documento arquite- dos elementos do processo de especi- alterações em um conjunto específico detural, devemos primeiro entender como ficação arquitetural que tipo de infor- elementos arquiteturais, alterações emesse artefato é criado. mações e abordagens podem ser utili- um requisito de qualidade podem impli- zadas para realizá-los. car na total reestruturação da arquitetu-Processo de especificação arquitetural ra (BASS et al., 2003). Existem na literatura diversas abor- Projeto Arquitetural Contudo, nem todos os requisitos dedagens que objetivam a especificação O projeto arquitetural consiste na ativida- qualidade são relevantes a nível arqui-de arquiteturas de software. Após ava- de em que a solução computacional e, por tetural, pois determinados tipos de re-liar algumas das principais abordagens conseqüência, a arquitetura do software quisitos podem ser atendidos somente(GACEK, 1995; SHAW e GARLAN, 1996; são definidas. Durante essa atividade, o durante a etapa de codificação ou dis-BOSCH e MOLIN, 1999; BACHMANN et raciocínio sobre os requisitos é realizado ponibilização (XAVIER, 2001). Um re-al., 2000; BASS et al., 2003) pode-se per- e decisões arquiteturais são tomadas, vi- quisito de inteligibilidade, por exemplo,ceber um processo genérico de especifi- sando identificar e organizar os elementos só poderá ser implementado no momen-cação arquitetural. arquiteturais para que os requisitos especi- to da defi nição da interface do sistema Esse processo é composto principalmente ficados possam ser atendidos. com o usuário.pelos seguintes elementos (Figura 2): duas Ao se analisar como essa atividade é Existem diferentes taxonomias para semacro-atividades (projeto e avaliação ar- realizada nas principais abordagens de classificar requisitos de qualidade (ISO/quitetural) e a tarefa de documentação da especificação arquitetural, observamos a IEC, 1998; BASS et al., 2003). No contextoarquitetura. O que diferencia essas aborda- importância dos requisitos de qualidade desse artigo, adotamos a taxonomia des-gens é principalmente a forma como cada no projeto de uma arquitetura e a exis- crita por BASS et al. (2003) visto que elaum desses elementos são realizados. tência de várias abordagens que podem identifica os tipos de requisitos de quali- Nesse processo, a característica comum ser utilizadas para atendê-los. dade que são relevantes a nível arquite-às duas macro-atividades identificadas é a tural, ou seja, quais os tipos de requisitospresença da tarefa de documentação res- Requisitos de Qualidade de qualidade que influenciam na cons-ponsável por criar e atualizar o documen- Os requisitos de um software podem trução da arquitetura de um software.to que representa a arquitetura de softwa- ser classificados, de forma geral, como re- Portanto, de acordo com BASS et al.re. Esse documento arquitetural é criado quisitos funcionais e os não-funcionais. (2003), esses tipos de requisitos são: Edição 06 – Engenharia de Software Magazine 31
    • • Desempenho: Descrevem o comporta- diversas fontes de conhecimento, tan- pos de componentes e de conectores quemento do sistema em relação a restrições to tácito quanto explícito para defi nir serão usados na composição do softwarede tempo e de recurso computacional; quais serão os elementos arquiteturais e levando em conta as restrições impostas • Disponibilidade: Descrevem o com- com estarão organizados. Um exemplo (SHAW e GARLAN, 1996).portamento de determinada parte do de conhecimento tácito seria a experi- Na literatura, existe um outro conceito,sistema em caso de falha; ência do arquiteto, e em relação ao co- chamado de padrões de projeto, que é mui- • Modificabilidade: Descrevem quais nhecimento explícito teríamos os estilos to semelhante ao conceito de estilos arqui-as prováveis modificações que podem e as táticas arquiteturais. teturais. Em BUSCHMANN et al. (1996), éacontecer no sistema e as flexibilida- A experiência de um arquiteto é uma feita a diferenciação entre padrões arqui-des que devem estar nele presentes característica importante para o suces- teturais e padrões de projeto. Essa diferen-para que essas modificações sejam fa- so do projeto de uma arquitetura, pois ça encontra-se principalmente no nível decilmente realizadas; a partir de suas lições aprendidas, o ar- abstração onde cada um desses padrões • Segurança: Descrevem o comporta- quiteto consegue facilmente identificar atua. Os padrões de projeto são utilizadosmento de determinada parte do sistema que elementos arquiteturais devem ser somente durante a fase de definição doem relação ao acesso de seus dados ou criados e como eles devem ser organi- projeto de baixo-nível, onde refinamentosfuncionalidades; zados. Mas, por ser um conhecimento são feitos nos elementos arquiteturais que • Testabilidade: Descrevem o compor- tácito, é difícil de ser externalizado e formam a arquitetura, e que foram defini-tamento de determinada parte do siste- utilizado por terceiros. dos com base nos padrões arquiteturais.ma em relação às facilidades que elas de- Por outro lado, estilos e táticas arqui- Contudo, muitos dos conceitos presentesvem fornecer para a realização de testes; teturais são conhecimentos explícitos em padrões arquiteturais e padrões de • Usabilidade: Requisitos desse tipo, amplamente difundidos na literatura projeto são semelhantes, mas o que os di-em um contexto arquitetural, descrevem e bastante utilizados por arquitetos de ferencia é o fato de serem utilizados emfacilidades que o sistema deve possuir, software (SHAW, 1995; BUSCHMANN et níveis de abstração diferentes.mas que não são consideradas funciona- al., 1996; BASS et al., 2003). No contexto desse artigo abordaremoslidades do sistema. Exemplo dessas faci- Um estilo arquitetural, ou padrão ar- somente padrões arquiteturais pois sãolidades são operações de undo e redo. quitetural, consiste em um conhecimen- eles que possuem os principais concei- to que pode ser diretamente aplicado tos relevantes a nível arquitetural. ParaAtendendo os requisitos de qualidade pelo arquiteto na identificação dos ele- evitar confusões, utilizaremos a deno- Durante o projeto de uma arquitetura, mentos arquiteturais. Isso é possível por minação de estilos arquiteturais quandopara atender aos requisitos de qualida- ele ser composto por um conjunto de re- abordarmos esses conceitos.de, as principais abordagens utilizam gras que permitem a identificação dos ti- Com isso, uma característica particu- lar aos estilos arquiteturais é que o uso de um único estilo possibilita o aten- dimento a vários tipos de requisitos de qualidade. XAVIER (2001), por exemplo, descreve uma abordagem que, a partir dos tipos de requisitos de qualidade que devem ser atendidos pelo software, per- mite identificar os estilos arquiteturais mais adequados que devem ser usados na construção desse software. Além dos estilos, outro tipo de conhe- cimento explícito que pode ser utilizado no projeto arquitetural são as táticas ar- quiteturais. Uma tática arquitetural con- siste em um conhecimento mais abstrato, utilizado principalmente para auxiliar o atendimento a um tipo de requisito de qualidade. Portanto, por serem mais abs- tratas, essas táticas descrevem principal- mente possíveis características que uma arquitetura deve apresentar para atender a um determinado tipo de requisito. Em BASS et al. (2003), essas táticas são identificadas e categorizadas em grupos, de acordo com os atributos de qualidadeFigura 3. Exemplo de visões arquiteturais que elas influenciam.32 Engenharia de Software Magazine – Fundamentos de Arquitetura de Software
    • P R O J E TO Uma característica particular a essas nado momento. Portanto, essas visões No contexto desse artigo, é importantetáticas é que quando agrupadas e es- representam um aspecto parcial da ar- ressaltar algumas das recomendações de-pecializadas, podem ser usadas como quitetura que mostram propriedades finidas pelo padrão IEEE-1471, que abor-base para a criação de estilos arquite- específicas do software. dam a descrição arquitetural de sistemasturais. ZHU (2004), por exemplo, rea- Na Figura 3, podemos identificar três de software, para definir as principaislizou uma análise dos principais esti- visões arquiteturais usadas para des- informações que devem ser descritas emlos arquiteturais por eles utilizados e crever um conjunto de elementos ar- um documento arquitetural. Sendo as-identificou as táticas arquiteturais que quiteturais. Independente da notação sim, um documento arquitetural deve:os compõem. gráfica utilizada, é possível notar as • Identificar os elementos arquiteturais Sendo assim, a partir do uso desse tipo diferentes propriedades que cada vi- que compõem a solução a ser construída,de conhecimento, o arquiteto consegue são permite identificar. assim como a forma que esses elementosdefinir a estrutura principal da arquite- Existe um grande número de visões estão organizados;tura. Essa estrutura é em seguida povoa- arquiteturais propostas na literatura • Descrever o papel de cada elementoda com elementos arquiteturais identifi- que propõem soluções similares para dentro da arquitetura;cados principalmente a partir da análise a representação de uma arquitetura • Identificar como cada requisito re-dos requisitos funcionais. (KRUCHTEN, 1995; HOFMEISTER et levante a nível arquitetural está sendo al., 2000; CLEMENTS et al., 2004). As atendido através da arquitetura docu-Documentação Arquitetural principais visões são: mentada. Essa identificação pode ser fei- Uma característica única em Engenha- • Visão Modular: Esta perspectiva re- ta principalmente através do rastreamen-ria de Software em relação às outras áre- presenta os elementos que compõem a to de que requisito está sendo atendido eas de engenharia é que os produtos por arquitetura, responsáveis por realizar quais requisitos justificam a criação deela construídos não são completamente um conjunto de funcionalidades, e as de- determinado elemento arquitetural.materializáveis. Diferente de um enge- pendências entre eles. Para isso, um con- • Representar o software através de di-nheiro civil que pode inspecionar, por junto de diagramas pode ser criado para ferentes perspectivas, por exemplo, atra-exemplo, as partes de um prédio, um representar através de diferentes níveis vés do uso de visões arquiteturais.engenheiro de software não consegue de abstração, os elementos, seus elemen-inspecionar um pedaço do software em tos internos (caso haja) e como eles se re- Avaliação Arquiteturalsi. Para isso ele deve utilizar representa- lacionam entre si. A avaliação arquitetural consiste emções desse software (LAITENBERGER e • Visão Dinâmica: Esta perspectiva caracterizar e avaliar os documentosATKINSON, 1999). procura descrever o comportamento dos arquiteturais através de métodos ou A arquitetura é um exemplo da parte elementos arquiteturais durante a reali- procedimentos sistemáticos (BAHSO-de um software que não é materializá- zação dos diferentes fluxos de execução ON e EMMERICH, 2003). Essa avalia-vel. Durante uma inspeção, por exem- que pertencem ao sistema. ção verifica principalmente se as infor-plo, é o documento arquitetural que • Visão de Alocação: Esta perspectiva mações descritas no documento estãodeve ser revisado, por impossibilidade busca representar o mapeamento das consistentes e se a arquitetura nelede se inspecionar diretamente a arqui- unidades de software para elementos representada atende aos requisitos es-tetura projetada. Sendo assim, durante físicos do ambiente (hardware, arquivos pecificados para o produto.o seu projeto, a arquitetura tem que ser do sistema, equipe de desenvolvimento). Visto que são os requisitos de qualida-documentada para que ela possa ser • Visão de contexto geral: Essa perspec- de os que mais influenciam a construçãousada para os seus devidos fins. tiva tem como objetivo representar uma de uma arquitetura, portanto, é princi- A arquitetura é uma entidade complexa visão geral dos principais componentes palmente sob a perspectiva desse tipoque não pode ser descrita de uma forma que formam a arquitetura do software e de requisitos que a avaliação deve serunidimensional (CLEMENTS et al., 2004). de como ele se relaciona com os elemen- realizada (DOBRICA e NIEMELA, 2002;Uma forma efetiva de lidar com essa tos externos ao seu contexto (atores e sis- BABAR et al., 2004).complexidade é descrevendo-a a partir temas externos). A realização da atividade de avalia-de diferentes perspectivas, também co- A escolha das visões a serem documen- ção é de extrema importância para anhecidas como visões arquiteturais. tadas deve ser feita com base nas carac- melhoria da qualidade do produto de Em cada visão, a forma como os ele- terísticas de qualidade que se deseja por software e para o sucesso do proje-mentos arquiteturais e seus relacio- em evidência, uma vez que diferentes to. Esta afirmação é fortalecida se fornamentos são documentados coloca visões expõem características de quali- considerado que (1) a avaliação da ar-em evidência propriedades distintas dade distintas. quitetura impede que seus defeitos sedo software que eles representam. De Para CLEMENTS et al. (2004), docu- propaguem para os demais artefatos,acordo com EGYED e MEDVIDOVIC mentar uma arquitetura consiste em como diagramas de projeto e código(1999), ao criar uma visão arquitetural, documentar as visões arquiteturais re- fonte, e (2) o custo de correção dessesos desenvolvedores conseguem redu- levantes, explicar como essas visões se defeitos é bem menor se for realizadazir a quantidade de informação que relacionam e como um stakeholder deve durante os primeiros estágios do pro-são obrigados a lidar em um determi- utilizar esse material. jeto (BOEHM, 1981). Edição 06 – Engenharia de Software Magazine 33
    • Além dos benefícios listados ante- fase principalmente nas atividadesriormente, MARANZANO et al. (2005) que estão relacionadas ao seu proces-identificaram os seguintes benefícios, so de especificação.após aplicar a avaliação arquitetural Através da análise desses conceitos eem diversos projetos no contexto da processos, foi possível identificar (1) a im-empresa em que trabalha, que podem portância da arquitetura dentro do pro- Dê seu feedback sobre esta edição! Feedbackser obtidos através dessa prática: cesso de desenvolvimento de software, eu s Dê A Engenharia de Software Magazine • Permite um melhor aproveitamento (2) como esse artefato é construído e prin- sobre e tem que ser feita ao seu gosto.do conhecimento de seus especialistas, cipalmente (3) que informações devem Para isso, precisamos saber o que você, s ta ediçãopois são alocados em avaliações arqui- estar representadas nesse artefato e que leitor, acha da revista!teturais que analisam arquiteturas de devem ser analisadas durante o processo Dê seu voto sobre este artigo, através do link:projetos em que não tiveram participa- de avaliação para que se determine a cor- www.devmedia.com.br/esmag/feedbackção, utilizando assim suas experiências e retude do documento arquitetural.conhecimentos para auxiliá-los; • Permite um melhor gerenciamento Referênciasdos fornecedores de componentes de sof- BABAR, M.A., ZHU, L., JEFFERY, R., 2004, “A framework for classifying and comparing software architecture evaluation methods”. In: Proceedings of thetware da empresa; Australian Software Engineering Conference, pp. 309-318, Melbourne, Australia, April. • Permite que a alta gerência tenha BACHMANN, F., BASS, L., CHASTEK, G., DONOHOE, P., PERUZZI, F., 2000, The Architecture Based Design Method, CMU/SEI, Relatório Técnico, CMU/SEI- 2000-TR-001.uma maior compreensão de problemas, BAHSOON, R., EMMERICH, W., 2003, “Evaluating software architectures: development, stability, and evolution”. In: Book of Abstracts of the ACS/IEEEprincipalmente de ordem técnica, que International Conference on Computer Systems and Applications, pp. 47, Tunis, Tunisia, July. BASS, L., CLEMENTS, P., KAZMAN, R., 2003, Software Architecture in Practice, Second Edition, Addison Wesley.ocorrem durante a gerência dos projetos BOEHM, B.W., 1981, Software Engineering Economics, Prentice-Hall.da empresa; BOSCH, J., MOLIN, P., 1999, “Software Architecture Design: Evaluation and Transformation”. In: Proceedings of the IEEE Engineering of Computer Based Systems Symposium (ECBS´99), pp. 4, Nashville, TN, USA, March. • Possibilita a identificação de neces- BUSCHMANN, F., MEUNIER, R., ROHNERT, H., SOMMERLAD, P., STAL, M., 1996, Pattern-Oriented Software Architecture: A System of Patterns, Jon Wileysidades de treinamentos ao nível de and Sons. CLEMENTS, P., BACHMANN, F., BASS, L., GARLAN, D., IVERS, J., LITTLE, R., NORD, R., STAFFORD, J., 2004, Documenting Software Architectures, Addison-projeto ou organizacional com base Wesley.em tipos de problema freqüentemen- DIAS, M.S., VIEIRA, M.E.R., 2000, “Software architecture analysis based on statechart semantics”. In: International Workshop on Software Specification and Design, pp. 133-137, Washington, DC, USA.te identificados durante as avaliações. DOBRICA, L., NIEMELA, E., 2002, “A survey on software architecture analysis methods”, IEEE Transactions on Software Engineering, v. 28, n. 7, pp. 638-Por exemplo, fornecer cursos em oti- 653.. EGYED, A., MEDVIDOVIC, N., 1999, “Extending Architectural Representation in UML with View Integration”. In: Proceedings of the 2nd International Con-mização de sistemas quando as ava- ference on the Unified Modeling Language. Beyond the Standard (UML’99), v. 1723, pp. 2-16, Fort Collins, USA, October.liações identificarem principalmente GACEK, C., 1995, On the Definition of Software System Architecture, University of Southern California, Relatório Técnico, USC/CSE-95-TR-500. GARLAN, D., 2000, “Software architecture: a roadmap”. In: Proceedings of The Conference on The Future of Software Engineering, pp. 91-101.problemas arquiteturais relacionados GARLAN, D., PERRY, D., 1995, “Introduction to the Special Issue on Software Architecture”. In: IEEE Transactions on Software Engineering, v. 21, April.à característica de desempenho. HOFMEISTER, C., NORD, R.L., SONI, D., 2000, A study on agreement between participants in an architecture assessment, Addison-Wesley. IEEE, 2000, “IEEE Recommended Practice For Architectural Description Of Software-Intensive Systems - IEEE Standard 1471-2000”, Institute of Electrical A avaliação de documentos arqui- and Electronics Engineers.teturais é um tema que tem sido bas- ISO/IEC, 1998, “International Technology - Software Product Evaluation - ISO/IEC 9126 Part 1: Quality Model”. KAZMAN, R., 2001, “Handbook of Software Engineering and Knowledge Engineering”. In: CHANG, S.K. (eds), World Scientific Publishing.tante discutido no contexto de vários KAZMAN, R., BASS, L., ABOWD, G., WEBB, M., 1994, “SAAM: a method for analyzing the properties of software architectures”. In: Proceedings of thegrupos de pesquisa, como no grupo do International conference on Software Engineering (ICSE), pp. 81-90. KRUCHTEN, P., 1995, “Architectural Blueprints - The “4+1” View Model of Software Architecture”. In: IEEE Software, v. 12, pp. 42-50, November.Software Engineering Institute (SEI) LAITENBERGER, O., ATKINSON, C., 1999, “Generalizing Perspective-based Inspection to handle Object-Oriented Development Artifacts”. In: Proceedings of(KAZMAN et al., 1994; CLEMENTS et the International conference on Software Engineering (ICSE). MARANZANO, J.F., ROZSYPAL, S.A., ZIMMERMAN, G.H., WARNKEN, G.W., WIRTH, P.E., WEISS, D.M., 2005, “Architecture reviews: practice and experience”,al., 2002), por exemplo. IEEE Software, v. 22, n. 2, pp. 34-43. SHAW, M., 1995, “Some Patterns for Software Architectures”. SHAW, M., GARLAN, D., 1996, Software Architecture - Perspectives on an Emerging Discipline, Prentice Hall.Conclusão XAVIER, J.R., 2001, Criação e Instanciação de Arquiteturas de Software Específicas de Domínio no Contexto de uma Infra-estrutura de Reutilização, Dis- Ao longo deste artigo foram descri- sertação de Mestrado, Programa de Engenharia de Sistemas e Computação - COPPE/UFRJ. ZHU, L., BABAR, M.A., JEFFERY, R., 2004, “Mining patterns to support software architecture evaluation”. In: Proceedings of the 4th Working IEEE/IFIPtos os principais conceitos em relação Conference on Software Architecture, pp. 25 - 34, June.à arquitetura de software, dando ên-34 Engenharia de Software Magazine – Fundamentos de Arquitetura de Software
    • Planejamento de Testes a partir de Casos de Uso De que se trata o artigo: O artigo apresenta uma estratégia indicando como testes podem ser ob- tidos a partir dos casos de uso especi- S e observarmos nos diferentes li- ficados para um projeto. vros tradicionais de Engenharia de Software, veremos que sempre Para que serve: existe um capítulo ou seção destinado a Durante o desenvolvimento de um Teste de software. Porém, eles normal- software, diversas estratégias para mente apresentam apenas informações teste podem ser aplicadas. Ao longo básicas sobre esta atividade, como por deste artigo iremos adotar uma es- exemplo, os diferentes níveis de teste tratégia de geração de testes base- que podem ser aplicado (ex: unidade, ada em especificação, representada integração ou sistema), as técnicas de pelos casos de uso de um sistema. teste que podem ser aplicadas (ex: técni- Assim, partiremos desta informação ca funcional ou estrutural) e os critérios para a geração de casos e procedi- para seleção dos testes associados a estas mentos (roteiros) de teste. Desta for- técnicas. Por exemplo, no artigo “Intro- ma, este artigo apresenta de forma dução a Teste de Software” publicado prática como efetuar a geração de na edição 01 da Engenharia de Software casos de teste. Arilo Cláudio Dias Neto Magazine discutimos sobre alguns des- Em que situação o tema é útil: ariloclaudio@gmail.com ses critérios: Particionamento em classes A cada dia as atividades de teste de É Bacharel em Ciência da Computação formado de equivalência, Análise do Valor Limite software vêm tendo sua importância na Universidade Federal do Amazonas, Mestre em Engenharia de Sistemas e Computação for- e Grafo de Causa-Efeito. Para cada crité- aumentada dentro das organizações mado na COPPE/UFRJ, e atualmente está cursan- rio, vimos como aplicá-los e um exemplo de desenvolvimento de software. O do doutorado na área de Engenharia de Software da sua aplicação para a geração de casos tema deste artigo agrega conheci- da COPPE/UFRJ. Possui 5 anos de experiência em de teste. Mais informações sobre esses mento a este cenário através do apoio análise, desenvolvimento e teste de software. É editor técnico das Revistas SQL Magazine e critérios de seleção dos testes podem ser às atividades do analista de testes. WebMobile, gerenciadas pelo Grupo DevMedia. obtidas em ROCHA (2001).36 Engenharia de Software Magazine – Planejamento de Testes a partir de Casos de Uso
    • VA L I D AÇ ÃO, V E R I F I C AÇ ÃO E T E S T E No entanto, no desenvolvimento de para a sua realização, e bastante comple- artigo “Introdução a Teste de Software”um software real normalmente os pro- xa quando o tamanho do código se torna publicado na edição 01 da Engenharia deblemas são bem mais complexos do que bastante grande. É totalmente dependen- Software Magazine, temos:aqueles tradicionalmente usados quan- te de apoio ferramental. • Caso de Teste. Descreve uma con-do estamos conhecendo esses critérios • Baseadas em especificação: utiliza dição particular a ser testada e é com-para seleção dos testes (ex: indicar qual um documento de especificação como posto por valores de entrada, restriçõeso maior valor em um conjunto, indicar se base para geração dos testes. Assim, para a sua execução e um resultado ouum campo número só contém caracteres tenta-se cobrir as imposições e restri- comportamento esperado (CRAIG eválidos, dentre outros). Normalmente os ções descritas nos requisitos estabele- JASKIEL, 2002).problemas a serem resolvidos são repre- cidos para o sistema. A automação da • Procedimento (Roteiro) de Teste. Ésentados através de cenários, que podem geração dos testes nesse caso é mais uma descrição dos passos necessáriosser facilmente representados por Dia- complicada, caso não se tenha um for- para executar um caso (ou um grupo degramas de Casos de Uso da UML (www. malismo para a elaboração da especifi- casos) de teste (CRAIG e JASKIEL, 2002).uml.org) aliada a uma descrição do que cação do sistema. Porém, antes de descrevermos comocada caso de uso deve fazer. • Baseadas em modelos: é uma sub-ca- obter testes a partir da especificação Ao longo deste artigo iremos discu- tegoria de estratégias baseada em espe- de casos de uso, precisamos primei-tir uma possível estratégia indicando cificação. Utiliza modelos desenvolvidos ramente entender melhor este docu-como testes podem ser obtidos a par- ao longo do processo de desenvolvimen- mento que servirá como entrada paratir dos casos de uso especificados para to que representam o comportamento ou a geração dos testes: a Especificação deum projeto. Entendemos que podem estrutura do software como base para Casos de Uso. Este artefato do processoexistir diferentes estratégias para isso, a geração dos testes. Facilita a geração de desenvolvimento servirá como orá-então iremos apresentar apenas uma automática dos testes, porem é comple- culo para os testes, ou seja, os resulta-possibilidade que pode ser facilmente tamente dependente da facilidade para a dos obtidos pelo sistema devem sem-aplicada para o teste de formulários de construção do modelo adotado e de sua pre estar de acordo com os resultadoscadastro, normalmente existentes em qualidade (corretude). previstos neste documento. A próximasistemas de informação. Cada estratégia apresentada possui sua seção irá discutir sobre a estrutura e aplicabilidade, vantagens e desvanta- conteúdo deste artefato.Estratégias de Teste de Software gens. Não é propósito deste artigo discu- Durante o desenvolvimento de um sof- tir qual seria a estratégia mais adequada. Especificação de Casos de Usotware, diversas estratégias para teste po- Ao longo deste artigo iremos adotar uma Um Caso de Uso representa uma uni-dem ser aplicadas. De acordo com PRES- estratégia de geração de testes baseada dade discreta da interação entre umSMAN (2005), essas estratégias podem em especificação, representada pelos ca- usuário (humano ou máquina) e o sis-ser categorizadas da seguinte forma: sos de uso de um sistema. Assim, partire- tema. Ele representa as funcionalidades • Baseadas em implementação: utiliza mos desta informação para a geração de que um sistema deve prover e uma in-o código como elemento para a geração casos e procedimentos (roteiros) de teste. dicação que qual elemento, denominadodos testes. É uma atividade cara, sob o Relembrando os conceitos associados a de ator, pode acessar uma determinadaponto de vista de recursos necessários esses elementos, conforme descrito no funcionalidade. Um ator é um humanoFigura 1. Template para especificação de caso de uso Edição 06 – Engenharia de Software Magazine 37
    • Figura 2. Processo de Geracao de Testes a partir de Casos de Uso Quadro 1. Descrição do Caso de Uso ou entidade máquina que interage com o sistema para executar um trabalho no Caso de Uso: Cadastrar Funcionário contexto do sistema. Ator: Administrador do Sistema Este modelo foi incluído entre os dia- Pré-Condições: O administrador deve estar autenticado no sistema e deve ter acesso a gramas disponíveis na UML. No entanto, este caso de uso o diagrama sozinho é totalmente limita- Fluxo: do e não apresenta qualquer informação 1. Ator escolhe a opção Cadastrar Funcionário sobre o significado de tal funcionalidade. 2. Sistema abre um formulário a ser preenchido. Sendo assim, cada Caso de Uso deve pos- 3. Ator preenche o formulário com os dados do funcionário a ser cadastrado. suir uma descrição que deve descrever a 4. Sistema valida os dados do funcionário e solicita confirmação. funcionalidade que irá ser construída no 5. Ator confirma o cadastro. sistema proposto. 6. Sistema armazena os dados do novo funcionário. É importante notar que o caso de uso Pós-Condições: O funcionário deve estar cadastrado no sistema. não descreve como o software deverá Fluxos Alternativos: ser construído, mas sim como ele deve- 5.1 Ator não confirma o cadastro. rá se comportar quando estiver pronto. 5.2 Sistema volta ao passo 3. Um software freqüentemente é um pro- Regra de Negócio: duto complexo, e sua descrição envolve (1) os campos a serem preenchidos para um formulário são: nome, data de nascimento, a identificação e documentação de vários cargo (motorista, médico ou técnico em informática), CNH (caso seja motorista), CRM (caso casos de uso, cada um deles descrevendo seja médico), naturalidade (brasileira ou estrangeira), CPF (caso seja brasileiro), Passaporte uma “fatia” do que o software ou uma de (caso seja estrangeiro) e salário. suas partes deverá oferecer. (2) os campos nome, data de nascimento, cargo, naturalidade e salário são obrigatórios. Uma descrição de um caso de uso deve (3) o campo CNH é obrigatório caso o cargo do funcionário seja “motorista” e o campo ser formada pelos seguintes elementos: CREA é obrigatório caso o cargo seja “engenheiro”. – Nome: Identificador inequívoco do (4) o campo CPF é obrigatório caso o funcionário seja “brasileiro” e o campo Passaporte é caso de uso, deve ser escrito em forma- obrigatório caso seja “estrangeiro”. to de verbo/substantivo e ser suficiente (5) cada tipo cargo possui uma faixa de salário possível que deve ser respeitada. As faixas para o utilizador perceber a que se refere são: o caso de uso. - Motorista: entre R$ 1000 e R$ 3000; – Atores: perfis de usuários que execu- - Médico: entre R$ 3000 e R$ 10000; tam o caso de uso. - Técnico em Informática: entre R$ 1500 e R$ 7000; – Pré-condições: restrições para iniciar a execução de um caso de uso. Exceções: Dados não preenchidos corretamente ou salário fora da faixa de valores do – Seqüência de Ações (Fluxo princi- cargo correspondente. pal): passos ordenados para execução de um caso de uso.38 Engenharia de Software Magazine – Planejamento de Testes a partir de Casos de Uso
    • VA L I D AÇ ÃO, V E R I F I C AÇ ÃO E T E S T E – Pós-condições: condição final a ser a) Na interface do sistema, o preen- FUNCIONÁRIO no menu principal daestabelecida ao final da execução do caso chimento incorreto de um campo será aplicação. Assim, os elementos de inter-de uso. mostrado item a item, ou seja, se todos face que fazem parte dessa interface são: – Fluxos Alternativos: fluxos de ações os campos forem preenchidos incorreta- • Nome (String);que ocorrem paralelamente ao fluxo mente, o sistema apresentará mensagem • Data de Nascimento (tipo Data);principal, dada uma ação específica. de dados inválidos para todos eles. • Cargo (lista de opções); Regras de negócio: restrições (regras) b) Existem campos que são obrigatórios • CNH (String);para execução de um ou mais passos do a partir de certas condições (ex: CNH • CRM (String);fluxo principal ou alternativo. para motoristas), mas o sistema não im- • Salário (Numérico); – Exceções: estados inválidos para o pede que esse campo seja preenchido em • Nacionalidade (lista de opções);sistema. outras situações. • CPF (String); A Figura 1 descreve um exemplo de c) Iremos assumir que os campos CNH • Passaporte (String).template para a especificação de um caso e CRM não possuem regra de formação,de uso. como sabemos que existe para CPF. As- Passo 2: Análise da Dependência sim, se qualquer valor for preenchido, entre os ElementosGerando Testes a partir de Casos ele será considerado válido. Em seguida, precisamos observar asde Uso d) Os campos numéricos só aceitarão dependências entre os elementos de in- Uma vez garantida a qualidade da Es- valores numéricos (não preciso testar o terface, como por exemplo, uma regrapecificação de Casos de Uso, artefato de contrário) e o campo data só aceitará da- indicando que um campo só pode serentrada para a geração dos testes, deve- tas (válidas ou inválidas). preenchido caso um outro campo tenhamos seguir alguns passos visando a ob- e) Os campos cargo e naturalidade serão sido preenchido previamente.tenção de casos e procedimentos de teste opções a serem escolhidas (com alguma No nosso estudo de caso, olhando aspara avaliação de cada funcionalidade das opções já selecionada previamente). regras de negócio observamos as se-do sistema, representada pelos casos de Assim, estes campos nunca serão deixa- guintes dependências:uso. A Figura 2 representa os passos que dos em branco. • Os campos CNH, CRM e Salário de-compõem esta estratégia. A seguir iremos passo a passo gerar os pendem do Cargo selecionado. Para entendermos melhor esses passos, testes para este formulário. • Os campos CPF e Passaporte depen-seguiremos um estudo de caso referen- dem da Naturalidade selecionada.te a um caso de uso bastante comum no Passo 1: Identificação do Elementos Assim, este caso de uso possui 4 gru-nosso dia-a-dia de desenvolvedores: um de Interface pos de elementos independentes:formulário de cadastro. Os elementos de interface que com- • Nome; põem um caso de uso são, por exemplo, • Data de Nascimento;Estudo de Caso para Geração de campos, menus, links ou botões. Precisa- • Cargo, CNH, CRM e Salário;Testes: Cadastrar Funcionário mos identificá-los para podermos iniciar • Naturalidade, CPF e Passaporte. O caso de uso a ser testado está descrito o processo de geração dos testes para ono Quadro 1. caso de uso. Passo 3: Geração dos Casos de Teste Além dessas informações, algumas su- No nosso estudo de caso, partiremos da para cada Grupo de Elementosposições devem ser feitas para viabilizar idéia de que o caso de uso só é executado Identificados os grupos de elementos,o planejamento dos testes: após escolhermos a opção CADASTRAR devemos aplicar algum dos critérios deFigura 3. Grafo de Causa Efeito para o Grupo (Naturalidade CPF Passaporte) 3 Causa-Efeito (Naturalidade, CPF, Edição 06 – Engenharia de Software Magazine 39
    • seleção de testes funcionais que vimos • (Data de Nascimento): aplicamos o o caso da nacionalidade brasileira (umno artigo “Introdução a Teste de Softwa- critério de Particionamento em Classes com CPF não preenchido, um com CPFre” para a geração de casos de teste para de Equivalência e obtivemos três casos inválido [dígito verificador incorreto] ecada grupo. Essa seria uma forma de de teste, uma para a classe válida, ou- outro com CPF preenchido e válido), dedividir o problema em partes menores tro para data inválida (classe inválida) acordo com a Figura 3.para simplificar o processo de geração e outro para data não preenchida (clas- Tnacionalidade = {(“Brasileira”, “”, --, [INVÁ-dos testes. se inválida). LIDO]); (“Brasileira”, “782622652-97”, --; Os casos de teste gerados para cada Tdata = {(“ ”, Inválido); (“30/02/1982”,Inválido); [INVÁLIDO]); (“Brasileira”, “636.112.337-grupo são os seguintes: (“13/09/1982”,Válido)} 57”, “”; [VÁLIDO]), (“Estrangeira”, --, “”, • (Nome): aplicamos o critério de Par- [INVÁLIDO]); (“Estrangeira”, “”, “23243”;ticionamento em Classes de Equivalên- • (Nacionalidade,CPF,Passaporte): apli- [VÁLIDO])}cia e obtivemos dois casos de teste, uma camos o critério de Grafo de Causa-Efei-para a classe válida e outro para classe to e obtivemos cinco casos de teste, dois • (Cargo,CNH,CRM,Salário): aplica-inválida (não preenchido). para o caso de nacionalidade estrangeira mos o critério de Grafo de Causa-Efeito, Tnome = {(“ ”, INVÁLIDO); (um com passaporte preenchido e um sendo que para o campo Salário aplica-(“Arilo”,VÁLIDO)} com passaporte em branco) e três para mos ainda o critério de Análise do Valor # Caso de Teste (N) Caso de Teste (D) Caso de Teste (C) Caso de Teste (N) Resultado Esperado 1 “” “” (“Motorista”, “”, --, --) (“Brasileira”, “”, --) DADOS INVÁLIDOS 2 “Arilo” 30/02/1980 (“Motorista”,“123456334”, --, 999.99) (“Brasileira”, “782622652-97”, --) DADOS INVÁLIDOS 3 “” 14/05/2007 (“Motorista”,“123456334”, --, 3000.01) (“Brasileira”, “636.112.337-57”,””) DADOS INVÁLIDOS 4 “Arilo” “” (“Médico”, “”, --, --) (“Estrangeira”, --, “”) DADOS INVÁLIDOS 5 “” 30/02/1980 (“Médico”, --, “7625-2”, 2999.99) (“Estrangeira”, “”, “23243”) DADOS INVÁLIDOS 6 “Arilo” 14/05/2007 (“Médico”, --,“7625-2”; 10000.01) (“Brasileira”, --, “”) DADOS INVÁLIDOS 7 “” “” (“Técnico”, “”, “”, 1499.99) (“Brasileira”, “782622652-97”, --) DADOS INVÁLIDOS 8 “Arilo” 30/02/1980 (“Técnico”, “”, “”, 7000.01) (“Estrangeira”, --, “”) DADOS INVÁLIDOS 9 “Arilo” 14/05/2007 (“Motorista”,“123456334”,--, 1000) (“Brasileira”, “636.112.337-57”,””) CADASTRO REALIZADO 10 “Arilo” 14/05/2007 (“Motorista”,“123456334”, --, 3000) (“Estrangeira”, “”, “23243”) CADASTRO REALIZADO 11 “Arilo” 14/05/2007 (“Médico”, --, “7625-2”, 3000) (“Brasileira”, “636.112.337-57”,””) CADASTRO REALIZADO 12 “Arilo” 14/05/2007 (“Médico”, --,“7625-2”; 10000) (“Estrangeira”, “”, “23243”) CADASTRO REALIZADO 13 “Arilo” 14/05/2007 (“Técnico”, “”, “”, 1500) (“Brasileira”, “636.112.337-57”,””) CADASTRO REALIZADO 14 “Arilo” 14/05/2007 (“Técnico”, “”, “”, 7000) (“Estrangeira”, “”, “23243”) CADASTRO REALIZADOTabela 1. Conjunto final de casos de teste para o caso de uso CADASTRAR FUNCIONÁRIO Figura 4. Grafo de Causa-Efeito para o Grupo (Cargo,CNH,CRM,Salário)40 Engenharia de Software Magazine – Planejamento de Testes a partir de Casos de Uso
    • VA L I D AÇ ÃO, V E R I F I C AÇ ÃO E T E S T ELimite. Com isso, obtivemos catorze ca- funcionários são apenas dois: CADAS- Ao longo das nossas atividades do dia-sos de teste, cinco para o caso de cargo ser TRO REALIZADO COM SUCESSO ou a-dia, podemos nos deparar com situ-motorista, cinco para o caso do cargo ser DADOS INVÁLIDOS NO FORMULÁ- ações que requeiram uma estratégiamédico e quatro para o cargo técnico em RIO a partir da violação de alguma regra diferente da estratégia aqui apresen-informática (de acordo com a Figura 4). de negócio. tada. Cabe ao responsável pelos testes Tcargo = {(“Motorista”, “”, --, --; [INVÁLI- tomar a decisão de quais passos iráDO]); (“Motorista”, “123456334”, --, 999.99; Passo 5: Agrupamento dos Casos de adotar para a geração dos testes, desde[INVÁLIDO]); (“Motorista”, “123456334”, Teste Gerados que mantenha em mente o objetivo de--, 1000; [VÁLIDO]); (“Motorista”, O último passo é o agrupamento dos gerar testes de qualidade e que real-“123456334”, --, 3000; [VÁLIDO]) ; (“Mo- casos de teste gerados no passo 3. O agru- mente possibilitam a avaliação de umatorista”, “123456334”; --, 3000.01; [INVÁ- pamento entre os casos de teste não pre- funcionalidade de um software.LIDO]); (“Médico”, “”, --, --; [INVÁLIDO]); cisa seguir uma regra, desde que atenda Como passo seguinte do processo de(“Médico”, --, “7625-2”, 2999.99; [INVÁLI- às duas anteriores descritas no passo 4. teste, devem ser gerados os procedi-DO]); (“Médico”, --,“7625-2”; 3000; [VÁLI- No entanto, precisamos considerar o se- mentos de teste a fim de defi nir o rotei-DO]); (“Médico”, --,“7625-2”; 10000; [VÁ- guinte cenário: ro/ordem de execução dos casos de testeLIDO]) ; (“Médico”, --,“7625-2”; 10000.01; • Integrar dois casos de teste de resul- gerados. As diretrizes para defi nição[INVÁLIDO]); (“Técnico”, “”, “”, 1499.99; tados inválidos irá gerar um novo caso dos procedimentos de teste podem ser[INVÁLIDO]); (“Técnico”, “”, “”, 1500; [VÁ- de teste também de resultado inválido. tema de um próximo artigo em umaLIDO]); (“Técnico”, “”, “”, 7000; [VÁLIDO]); • Integrar dois casos de teste de resul- edição futura.(“Técnico”, “”, “”, 7000.01; [INVÁLIDO])} tados válidos irá gerar um novo caso de teste também de resultado válido. ReferênciasPasso 4: Análise dos resultados • Integrar um caso de teste de resulta- CRAIG, R.D., JASKIEL, S. P., “Systematic Software Testing”, Artechpossíveis do caso de uso do inválido com um de resultado válido House Publishers, Boston, 2002. Gerados os casos de teste para cada gru- irá gerar um novo caso de teste de resul- PRESSMAN, R. S., “Software Engineering: A Practitioner’s Approach”, McGraw-Hill, 6th ed, Nova York, NY, 2005.po de elementos, o passo seguinte consis- tado inválido. ROCHA, A. R. C., MALDONADO, J. C., WEBER, K. C. et al., “Qualidade dete na análise dos possíveis resultados pro- Sendo assim, o conjunto completo e software – Teoria e prática”, Prentice Hall, São Paulo, 2001.vidos pelo caso de uso. Para a geração dos mínimo de casos de teste para avalia-casos de teste para um caso de uso, deve- ção deste caso de uso está descrito namos atender às duas regras seguintes: Tabela 1. Dê seu feedback sobre esta edição! Feedback eu 1. Deve cobrir todos os casos de teste s Dê A Engenharia de Software Magazinegerados para cada grupo de elemento. Conclusões sobre e tem que ser feita ao seu gosto. 2. Deve existir ao menos 1 caso de teste Este artigo apresentou uma possí- Para isso, precisamos saber o que você, s ta ediçãopara cada resultado possível gerado pelo vel estratégia para geração de casos leitor, acha da revista!caso de uso. de teste a partir de casos de uso, mas Dê seu voto sobre este artigo, através do link: No nosso estudo de caso, os resultados é preciso destacar mais uma vez que www.devmedia.com.br/esmag/feedbackpossíveis da execução do cadastro de outras estratégias podem ser adotadas. Edição 06 – Engenharia de Software Magazine 41
    • Testes com Objetos Mock Utilizando o framework EasyMock para teste unitário de aplicações Java De que se trata o artigo: Uso do framework EasyMock para teste unitário de software Java, utilizando ob- jetos mock. Neste artigo foi realizado o teste unitário de um servlet, sem precisar Resumo DevMan executar a aplicação web, utilizando ob- jetos mock através do framework Easy- Os testes unitários são essenciais para ga- Mock para simular a requisição. rantir que menores unidades do software sejam Para que serve: testadas, mas essas unidades podem depender Fornecer um meio para construir casos de outras partes do código que ainda não estão de teste utilizando objetos mock de for- prontas. Outra situação refere-se à propagação ma ágil, permitindo que partes críticas da Bárbara de Melo Quintela aplicação possam ser testadas de forma bmquintela@yahoo.com.br do erro, onde é importante conseguir isolar uma determinada classe a ser testada, independente automatizada. Mostrar uma solução de É Mestranda em Modelagem Computacional na UFJF, cursando especialização em Engenharia de daquelas que são chamadas por ela, eliminando- teste para casos naturalmente difíceis de Software e Bacharel em Sistemas de Informação se dúvidas sobre a origem do erro. Uma solução serem testados como, por exemplo, par- pelo CES/JF - Centro de Ensino Superior de Juiz tes de código que dependem de outras de Fora, Analista de Sistemas e Programadora da para esses casos é apresentada através da utiliza- ção de objetos mock, com o framework EasyMock. partes que ainda não estão prontas. CPM Braxis. Neste artigo simulamos uma requisição web uti- Em que situação o tema é útil: lizando um objeto mock nos casos de teste para Em testes unitários de software Java Marco Antônio Pereira Araújo para melhoria da qualidade do produto maraujo@cesjf.br testar um método de um servlet. de software final, permitindo que partes É Doutorando e Mestre em Engenharia de Siste- mas e Computação pela COPPE/UFRJ, Especia- críticas possam ser testadas desde o iní- lista em Métodos Estatísticos Computacionais cio do desenvolvimento. e Bacharel em Matemática com Habilitação em Informática pela UFJF, Professor do Curso de Ba- charelado em Sistemas de Informação do Centro de Ensino Superior de Juiz de Fora, Analista de Sistemas da Prefeitura de Juiz de Fora e Editor da Engenharia de Software Magazine.42 Engenharia de Software Magazine – Testes com Objetos Mock
    • VA L I D AÇ ÃO, V E R I F I C AÇ ÃO E T E S T ET odo processo de software deve Listagem 1. Implementação do método processRequest do Servlet envolver em algum momento a protected void processRequest(HttpServletRequest request, HttpServletResponse response) fase de testes. O ideal seria que throws ServletException, IOException { response.setContentType(“text/html;charset=UTF-8”);simplesmente todo o código pudesse String mensagem = “”;ser testado exaustivamente para garan- if (verificarAprovacao(request)){ mensagem = “Aluno foi Aprovado!”;tir que um soft ware sem nenhum de- }else{ mensagem = “Aluno foi Reprovado!”;feito fosse entregue ao cliente. Mas sa- } request.setAttribute(“mensagem”,mensagem);bemos que mesmo com uma aplicação getServletContext().getRequestDispatcher(“/index.jsp”).forward(request,response);pequena, um teste completo, executado }de forma exaustiva, seria inviável. En- Listagem 2. Implementação do método verificarAprovação do Servlettão, a forma que os analistas de teste, public boolean verificarAprovacao(HttpServletRequest request) {e outros profissionais que tenham que String vBuffer_notafinal = “”; String nome = request.getParameter(“vNome”);desempenhar este papel no processo de float nota1 = Float.parseFloat(request.getParameter(“vNota1”));soft ware, encontram para identificar os float nota2 = Float.parseFloat(request.getParameter(“vNota2”)); vBuffer_notafinal = request.getParameter(“vNotaFinal”);defeitos no soft ware é concentrar os tes- int frequencia = Integer.parseInt(request.getParameter(“vFrequencia”)); float notafinal;tes nas áreas mais críticas, como partes if (vBuffer_notafinal == “”){que serão mais utilizadas pelo usuário notafinal = 0; }else{e partes que contenham um processa- notafinal = Float.parseFloat(vBuffer_notafinal); }mento mais complexo. Existem vários Aluno objAluno = new Aluno(nome, nota1, nota2, notafinal, frequencia); return objAluno.calcularAprovacao();tipos de testes que podem ser utilizados }de acordo com a necessidade. Os testes unitários são essenciais para Listagem 3. Classe Alunoque seja possível testar a menor unidade public class Aluno { private String nome;do software como um método, uma clas- private float nota1; private float nota2;se ou mesmo um objeto. Mas essas uni- private float notaFinal;dades a serem testadas, principalmente private int frequencia;as mais complexas, podem depender de public Aluno(String nome, float nota1, float nota2, float notaFinal, int frequencia){ this.nome = nome;outras partes do código que não que- this.nota1 = nota1; this.nota2 = nota2;remos testar no momento, por que não this.notaFinal = notaFinal;estão prontas ou por que podem com- this.frequencia = frequencia; }prometer os resultados do teste gerando public boolean calcularAprovacao() {dúvidas sobre qual é a origem do erro. float media; if (this.frequencia < 75) {Uma solução para estes casos é a utiliza- return false;ção de objetos mock. } else { media = (this.nota1 + this.nota2) / 2; Este artigo mostra um exemplo passo if (media < 30) { return false;a passo da implementação de um teste } else { if (media >= 70) {unitário que utiliza objetos mock. return true; } else { if (((media + this.notaFinal) / 2) >= 50) {Objetos Mock e o Framework return true;EasyMock } else { return false; Os objetos mock são objetos “falsos” } }que simulam o comportamento de uma } }classe ou objeto “real” para que possa- }mos focar o teste na unidade a ser tes-tada. Os objetos mock podem ser ex-tremamente úteis nas situações acimacitadas onde é necessário criar um casode teste e existem dependências entreos objetos. Como mostraremos a seguir,sua utilização é bastante simples e agili-za bastante o processo de construção detestes unitários. Antes dos objetos mock, uma alterna-tiva eram os stubs, objetos criados parasubstituir aqueles que seriam chamadosnuma troca de mensagem. Estes tipos deobjeto, por um lado, facilitavam os testes, Edição 06 – Engenharia de Software Magazine 43
    • Figura 1. Interação entre os objetos envolvidos, sendo o formulário web, o servlet e classe Aluno Figura 2. Representação do objeto mock no teste da aplicação dados que foram inseridos no formu- se fosse a requisição do formulário da Listagem 4. Criação da classe de teste lário da página. aplicação Web, conforme esquema da import junit.framework.TestCase; import static org.easymock.EasyMock.*; O método verificarAprovacao() é o Figura 2. public class TestesAprovacao extends TestCase{ alvo dos nossos casos de teste. Este Para quem conhece o JUnit, a estrutu- método recebe o objeto request e ob- ra do teste é semelhante e, para quem } tém, a partir dele, os dados inseridos está começando nos testes unitários,mas ao mesmo tempo podiam demandar no formulário através da chamada ao não tem grande mistério. Será criadageração de muito código extra, já que em getParameter(), passando o nome do uma classe de teste que herda da clas-alguns casos era necessário gerar cópias respectivo parâmetro do formulário. se TestCase do JUnit. Esta classe serádas classes reais para realizar os testes. Então é criado o objeto aluno chamado chamada de TestesAprovacao.Os objetos mock não são stubs, mas po- “objAluno”, passando a freqüência e as É necessário incluir um import estáticoderíamos dizer que são tipos de stubs notas informadas para o construtor do na biblioteca do EasyMock para criar osque requerem muito menos código. A objeto e é feita uma chamada ao méto- objetos mock, como mostrado na Lista-principal exigência na utilização de ob- do calcularAprovacao() da classe Alu- gem 4. Lembrando que os arquivos dojetos mock é a implementação de inter- no (ver Listagem 3) que retorna true se framework EasyMock devem ter sidofaces, que já são utilizadas em várias o aluno foi aprovado ou false caso não adicionados ao projeto anteriormente.situações, por serem uma boa prática de tenha sido aprovado. Casos de Testeprogramação orientada a objetos, e a suainclusão no modelo de classes não requer Teste Unitário utilizando Objetos Mock Para identificar quais casos de testes O nosso objetivo é implementar os ca- serão necessários para cobrir o métodomuitas alterações. sos de testes para o método verificarA- verificarAprovacao(), pode-se calcular Para criarmos os objetos mock utiliza- provacao() do servlet. Mas para isso, sua Complexidade Ciclomática (CC) uti-remos o framework EasyMock, gratuito e seria necessário passar uma requisição lizando alguma ferramenta de métricas,de código aberto, que está disponível em Htt pServletRequest no momento do tes- ou então pode-se descobrir quais são ashttp://sourceforge.net/projects/easymock. te, como o request passado pela página possibilidades de retorno de valor para Basta realizar o download, extrair os web na aplicação. Para isso, num primei- este método, de acordo com os dadosarquivos e adicionar os arquivos com ro momento, seria necessário executar a informados. Observando atentamenteextensão “.jar” ao projeto para começar a aplicação a partir do browser, uma vez o método calcularAprovacao() da classecriar os objetos mock. É necessário tam- que este objeto é passado pela página Aluno, verifica-se que se tem cinco pos-bém ter uma versão atualizada do JUnit web para o servlet (Figura 1). Entretan- sibilidades de retorno:instalada, uma vez que o EasyMock uti- to, para a construção de testes automa- 1. Freqüência inferior a 75, a função re-liza-se deste outro framework. tizados para o servlet, será necessário torna false; substituir o objeto criado pelo browser 2. Freqüência igual ou superior a 75 eEstudo de Caso por um objeto mock. média inferior a 30, a função retorna false; Tomemos como exemplo uma aplica- O objetivo é realizar testes no método 3. Freqüência igual ou superior a 75 eção web composta por uma página com verificarAprovacao() do servlet e, para média igual ou superior a 70, a funçãoum formulário de dados de alunos que isso, podemos criar uma requisição retorna true;chama um servlet ao clique de um botão. mock. Será criada uma requisição falsa 4. Freqüência igual ou superior a 75 eA página chama o servlet passando a re- simulando uma requisição do tipo Http- média final igual ou superior a 50, re-quisição contendo os dados do formulá- ServletRequest que é, na verdade, uma torna true;rio. O método que recebe esta requisição Interface, o que facilita a criação do obje- 5. Freqüência igual ou superior a 75 eé o processRequest() do servlet, mostra- to mock a partir dela. média final inferior a 50, a função re-do na Listagem 1. Durante os testes, o formulário que torna false. O método processRequest() do serv- envia os dados para o servlet não será Com base nessas informações, conclui-selet chama um outro método do servlet, executado em nenhum momento e o que, para este exemplo, tem-se cinco possi-verificarAprovacao() (ver Listagem browser sequer será aberto. O objeto bilidades de retorno da função verificarA-2), passando o objeto request que foi mock que será criado enviará a requi- provacao() e serão implementados casos deenviado pela página web. O objeto sição diretamente para o servlet como teste para cada uma destas possibilidades.request contém os parâmetros com os44 Engenharia de Software Magazine – Testes com Objetos Mock
    • VA L I D AÇ ÃO, V E R I F I C AÇ ÃO E T E S T EReprovação por Freqüência Insuficiente Listagem 5. Implementação do Caso de Teste testAlunoReprovadoInfrequencia() O primeiro caso de teste que será cria- public void testAlunoReprovadoInfrequencia() { HttpServletRequest requestMock = createMock(HttpServletRequest.class);do é o que testa a reprovação por freqü- expect(requestMock.getParameter(“vNome”)).andReturn(“Marco”); expect(requestMock.getParameter(“vNota1”)).andReturn(“0”);ência insuficiente. Para isso, a Listagem expect(requestMock.getParameter(“vNota2”)).andReturn(“0”); expect(requestMock.getParameter(“vNotaFinal”)).andReturn(“0”);5 apresenta o método, na classe de testes expect(requestMock.getParameter(“vFrequencia”)).andReturn(“74”);TestesAprovacao, chamado testAluno- replay(requestMock); ServletControllerWeb servletControllerWeb = new ServletControllerWeb();ReprovadoInfrequencia(). assertFalse(servletControllerWeb.verificarAprovacao(requestMock)); } O método inicia com a criação do ob-jeto requestMock. A sua criação é bemsimples, a única diferença da criaçãode um objeto comum está no fato deque, ao invés de chamar o construtor,chama-se o método createMock() pas-sando como parâmetro a Inteface Ht-tpServletRequest, ou seja, de onde serácriado o objeto falso. Entretanto, o objeto falso, como não foiinstanciado a partir da classe original, Figura 3. Resultado da execução de testAlunoReprovadoInfrequencia()não sabe como responder às chamadasde métodos. Então, as linhas seguintes,através do método expect, instruem oobjeto mock como ele deve se comportarquando forem feitas requisições a ele,retornando o especificado no métodoandReturn(). Trata-se do treinamento doobjeto mock e deve-se fazer isso por queestamos utilizando um objeto falso, quenão veio de uma página web. Este trei-namento termina com o método replay,estando o mock pronto para ser utilizadono teste. Desta forma, o mock foi instruí-do para retornar valores específicos paraos métodos que deve responder. Deve-se Figura 4. Resultado da execução de testAlunoReprovadoInfrequencia() com o teste modificadoperceber que é necessário fazer o treina-mento para cada método chamado con- O framework EasyMock permite ain- ser feito uma vez que o parâmetrotendo a assinatura completa do mesmo, da a criação de objetos mock que não nome não era mais necessário no res-incluindo os parâmetros, caso existam. retornem uma exceção caso ele não te- tante do teste. Para que se possa então testar a repro- nha sido treinado para uma determi-vação por freqüência insuficiente, preci- nada situação prevista na sua classe Reprovação por Notasa-se apenas retornar um valor inferior original. Para visualizar esta situação, O segundo caso de testes é bem seme-a 75, no caso foi utilizado o valor ime- pode-se comentar a primeira linha de lhante ao primeiro. Será criado um novodiatamente inferior. treinamento do mock que contém o co- método na classe de testes TestesApro- Finalmente, nas duas últimas linhas mando expect, fazendo o treinamento vacao chamado testAlunoReprovadoNo-estão respectivamente a criação do ser- para o retorno do parâmetro que con- ta(). Sua implementação é apresentadavlet servletControllerWeb e a execução tém o nome do aluno. na Listagem 6.do teste com a chamada ao verifica- Ao executar novamente o conjunto Agora será necessário passar os parâ-rAprovação() deste servlet, passando de testes, gera-se uma exceção por não metros vNota1 e vNota2. O método deveo objeto mock que foi criado no teste. estar preparado para responder quan- retornar false se a freqüência for maior ouComo na reprovação por freqüência in- do é feita a requisição ao objeto com o igual a 75 e a média dos parâmetros No-suficiente sabe-se que o verificarApro- parâmetro vNome (Figura 4). ta1 e Nota2 for inferior a 30. Para a notavacao() deve retornar false, utilizou-se Substituindo o construtor do mock 2, está sendo passado o valor “29”, paraa função assertFalse() para fazer esta de createMock para createNiceMock, testarmos o valor limite. A utilizaçãoverificação. Ao clicar com o botão di- pode-se perceber que o teste voltará a de testes exercitando os valores limitereito na classe de teste e executá-la, passar, mesmo com a linha comenta- das condições é muito importante, pois,no NetBeans o resultado deve ser algo da do treinamento para o parâmetro caso contrário, os testes podem estar re-como exibido na Figura 3. nome. Claro que este teste só pode tornando um resultado não verdadeiro. Edição 06 – Engenharia de Software Magazine 45
    • Para exemplificar isso, basta substituir Listagem 6. Implementação do Caso de Teste testAlunoReprovadoNota() no código fonte um sinal de “<” por um public void testAlunoReprovadoNota() { HttpServletRequest requestMock = createMock(HttpServletRequest.class); de “<=”, situação não muito difícil de expect(requestMock.getParameter(“vNome”)).andReturn(“Marco”); expect(requestMock.getParameter(“vNota1”)).andReturn(“30”); ser confundida quando da implemen- expect(requestMock.getParameter(“vNota2”)).andReturn(“29”); tação de um algoritmo. Executando os expect(requestMock.getParameter(“vNotaFinal”)).andReturn(“0”); expect(requestMock.getParameter(“vFrequencia”)).andReturn(“75”); casos de teste novamente, tem-se o re- replay(requestMock); ServletControllerWeb servletControllerWeb = new ServletControllerWeb(); sultado dos dois casos de teste imple- assertFalse(servletControllerWeb.verificarAprovacao(requestMock)); } mentados até agora. Listagem 7. Implementação do Caso de Teste testAlunoAprovadoNota() Aprovação por Nota public void testAlunoAprovadoNota() { A terceira situação refere-se à aprovação HttpServletRequest requestMock = createMock(HttpServletRequest.class); de alunos por nota. Assim, será criado expect(requestMock.getParameter(“vNome”)).andReturn(“Marco”); expect(requestMock.getParameter(“vNota1”)).andReturn(“70”); mais um método na classe TestesApro- expect(requestMock.getParameter(“vNota2”)).andReturn(“70”); expect(requestMock.getParameter(“vNotaFinal”)).andReturn(“0”); vacao chamado testAlunoAprovadoNo- expect(requestMock.getParameter(“vFrequencia”)).andReturn(“75”); replay(requestMock); ta(). A diferença deste para o anterior ServletControllerWeb servletControllerWeb = new ServletControllerWeb(); está nos parâmetros vNota1 e vNota2, assertTrue(servletControllerWeb.verificarAprovacao(requestMock)); } que agora devem retornar média igual ou superior a 70 e, no retorno do método Listagem 8. Implementação do Caso de Teste testAlunoReprovadoFinal () verificarAprovacao() que agora deverá public void testAlunoReprovadoFinal() { HttpServletRequest requestMock = createMock(HttpServletRequest.class); ser verdadeiro, sendo verificado pelo co- expect(requestMock.getParameter(“vNome”)).andReturn(“Marco”); mando assertTrue(). Serão considerados expect(requestMock.getParameter(“vNota1”)).andReturn(“30”); expect(requestMock.getParameter(“vNota2”)).andReturn(“30”); os valores “70” para ambas as notas, para expect(requestMock.getParameter(“vNotaFinal”)).andReturn(“69”); expect(requestMock.getParameter(“vFrequencia”)).andReturn(“75”); testar o valor limite. O código deste caso replay(requestMock); ServletControllerWeb servletControllerWeb = new ServletControllerWeb(); de teste é apresentado na Listagem 7. assertFalse(servletControllerWeb.verificarAprovacao(requestMock)); } Reprovação por Nota Final Listagem 9. Implementação do Caso de Teste testAlunoAprovadoFinal () Para ser reprovado por nota fi nal, a public void testAlunoAprovadoFinal() { média fi nal ((média anterior + nota fi- HttpServletRequest requestMock = createMock(HttpServletRequest.class); expect(requestMock.getParameter(“vNome”)).andReturn(“Marco”); nal) / 2) deve ser inferior a “50”. Para expect(requestMock.getParameter(“vNota1”)).andReturn(“30”); criar o caso de teste que represente esta expect(requestMock.getParameter(“vNota2”)).andReturn(“30”); expect(requestMock.getParameter(“vNotaFinal”)).andReturn(“70”); situação, vamos seguir o modelo na Lis- expect(requestMock.getParameter(“vFrequencia”)).andReturn(“75”); replay(requestMock); tagem 8. O método se chamará testAlu- ServletControllerWeb servletControllerWeb = new ServletControllerWeb(); noReprovadoFinal(). assertTrue(servletControllerWeb.verificarAprovacao(requestMock)); } Aprovação por Nota Final Finalmente, para a implementação do último caso de testes do estudo de caso, seguiremos a implementação descrita na Listagem 9. Para nos certificarmos que será execu- tado o trecho do método verificarApro- vacao() que verifica se o aluno passou com a nota da final (e não somente com as duas primeiras notas), foram utiliza- dos valores para vNota1 e vNota2 que retornariam que o aluno foi reprovado por nota. Ao informar o valor “70” no parâmetro vNotaFinal, verifica-se que o aluno foi aprovado. Com isso, a classe que testa o método verificarAprovacao() do servlet está con- cluída, e com testes unitários automati- zados, sem a necessidade de execução da aplicação via browser. Perceba que o intuito desde o início era testar o servlet, não a classe de domínio. Apenas para testar a classe de domínio, o framework46 Engenharia de Software Magazine – Testes com Objetos Mock
    • VA L I D AÇ ÃO, V E R I F I C AÇ ÃO E T E S T EJUnit seria suficiente. Para finalizar, aFigura 5 mostra a execução de todos oscasos de teste implementados.Verificando se todos os métodostreinados foram executados Uma situação que ainda vale ser ex-plorada é se todos os métodos treina-dos foram realmente executados emum teste. A Listagem 10 apresenta umamodificação feita no método testAluno- Figura 5. Resultado Final da Execução do Arquivo TestesAprovacaoReprovadoFinal. Perceba que foi inseri-da uma linha antes do comando replay,treinando o mock para retornar a ma- Listagem 10. Caso de Teste testAlunoReprovadoFinal () modificadotrícula de um aluno. public void testAlunoReprovadoFinal() { HttpServletRequest requestMock = createMock(HttpServletRequest.class); Neste caso, o teste continuará execu- expect(requestMock.getParameter(“vNome”)).andReturn(“Marco”); expect(requestMock.getParameter(“vNota1”)).andReturn(“30”);tando normalmente, pois a nova linha expect(requestMock.getParameter(“vNota2”)).andReturn(“30”);inserida não será chamada em nenhum expect(requestMock.getParameter(“vNotaFinal”)).andReturn(“69”); expect(requestMock.getParameter(“vFrequencia”)).andReturn(“75”);momento pelo servlet, quando o teste expect(requestMock.getParameter(“vMatricula”)).andReturn(“200821010”); replay(requestMock);for executado. Entretanto, poderíamos ServletControllerWeb servletControllerWeb = new ServletControllerWeb(); assertFalse(servletControllerWeb.verificarAprovacao(requestMock));querer saber se todos os métodos trei- }nados foram executados ao menos umavez. Para isso, pode-se utilizar o coman- Listagem 11. Caso de Teste testAlunoReprovadoFinal () com o comando verify()do verify(), conforme a última linha da public void testAlunoReprovadoFinal() { HttpServletRequest requestMock = createMock(HttpServletRequest.class);Listagem 11. expect(requestMock.getParameter(“vNome”)).andReturn(“Marco”); expect(requestMock.getParameter(“vNota1”)).andReturn(“30”); Executando os testes desta forma, po- expect(requestMock.getParameter(“vNota2”)).andReturn(“30”);de-se verificar que o EasyMock irá apre- expect(requestMock.getParameter(“vNotaFinal”)).andReturn(“69”); expect(requestMock.getParameter(“vFrequencia”)).andReturn(“75”);sentar uma falha, uma vez que um de- expect(requestMock.getParameter(“vMatricula”)).andReturn(“200821010”); replay(requestMock);terminado método que foi treinado não ServletControllerWeb servletControllerWeb = new ServletControllerWeb(); assertFalse(servletControllerWeb.verificarAprovacao(requestMock));foi executado. verify(requestMock); }Conclusão O objetivo deste artigo foi demonstrar aimportância dos testes unitários automa-tizados no processo de desenvolvimentode software e como sua utilização podeser implementada. Foi mostrada umasolução eficaz para situações onde é ne-cessário testar objetos que necessitam deoutros que ainda não foram implementa-dos, ou simplesmente quando se desejaisolar determinados objetos a serem tes-tados, eliminando a dependência delescom outros existentes. Esta solução ba-seia-se na utilização de objetos mock, ouobjetos “falsos”, através de frameworksespecíficos para este fim, como o Easy-Mock, apresentado neste artigo. Dê seu feedback sobre esta edição! Feedback eu s Dê A Engenharia de Software Magazine sobre e tem que ser feita ao seu gosto. Para isso, precisamos saber o que você, s ta edição leitor, acha da revista! Dê seu voto sobre este artigo, através do link: www.devmedia.com.br/esmag/feedback Edição 06 – Engenharia de Software Magazine 47
    • Inspecionando a Usabilidade de Produtos Avaliação Heurística De que se trata o artigo: Uso do método de avaliação heurística para inspecionar a usabilidade de sof- tware. Neste artigo, um conjunto de heu- S implicidade é um desejo de todo rísticas de projeto de interface de usuário ser humano quando utiliza um é apresentado e vinculado ao método de produto. Simplicidade é um ob- avaliação para mostrar como a usabilida- jetivo de projeto que todo engenheiro de de software pode ser avaliada. de software deve ter em mente quando Para que serve: projeta um novo produto. O engenhei- Prover um método através do qual ro deve se colocar no lugar do usuário um engenheiro de software ou ava- final do produto, buscando entender se liador pode avaliar a usabilidade de as funcionalidades implementadas pelo um produto de software. Este método Antonio Mendes da Silva Filho sistema e a maneira pela qual elas podem pode ser empregado para identificar a antoniom.silvafilho@gmail.com ser acessadas são facilmente assimiladas Professor e consultor em área de tecnologia da maioria dos problemas de usabilidade informação e comunicação com mais de 20 anos pelos usuários. Ter essa preocupação é de um produto. de experiência profissional, é autor do livros Ar- considerar a usabilidade como determi- Em que situação o tema é útil: quitetura de Software e Programando com XML, nante no processo de desenvolvimento Pode ser empregado ao longo do ambos pela Editora Campus/Elsevier, tem mais de um produto e, especificamente, de um desenvolvimento de um sistema de de 30 artigos publicados em eventos nacionais e internacionais, colunista para Ciência e Tecnolo- sistema de software. Essa atitude impacta software, bem como após se obter o gia pela Revista Espaço Acadêmico com mais de diretamente sobre a aceitabilidade e su- primeiro protótipo da interface de usu- 60 artigos publicados, tendo feitos palestras em cesso do produto. A edição anterior dessa ário do software, objetivando identificar eventos nacionais e exterior. Foi Professor Visi- revista tratou do processo de desenvolvi- problemas de usabilidade. tante da University of Texas at Dallas e da Univer- sity of Ottawa. Formado em Engenharia Elétrica mento de sistemas interativos e discutiu pela Universidade de Pernambuco, com Mes- trado 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.48 Engenharia de Software Magazine – Inspecionando a Usabilidade de Produtos
    • P R O J E TOum conjunto de métodos de avaliação um site de uma instituição, um celu- exatamente o tempo e o lugar. Em outrasda usabilidade. Este artigo apresenta um lar, um painel de carro ou um software palavras, o design, similarmente à arte,método de avaliação da usabilidade, de- instalado na sua máquina. Usabilidade acompanha as necessidades de sua épo-nominado avaliação heurística. resulta em simplicidade e agilidade. A ca. Antoine de Saint-Exupéry expressa simplicidade agrada os usuários e agi- isso bem quando diz:Usabilidade lidade (leia-se e entenda produtivida- “You know you’ve achieved perfection in design, Usabilidade é definida como a facilida- de) agrada as organizações. Not when you have nothing more to add,de de aprender e usar um produto, que Cabe aqui destacar que a usabilida- But when you have nothing more to take away.”pode ser, por exemplo, um painel de um de, um dos atributos da qualidade de [A perfeição no design não é alcançadacarro ou um sistema de software. Sua im- um produto, está inserida no campo Quando você percebe que não tem mais nada a adi- cionar,portância nos produtos tem sido explora- de projeto, de um sistema ou produto. Mas quando você não tem mais nada a remover.]da ao longo das últimas duas décadas e Profissionais da área também costu-tem se tornado cada vez mais um deter- mam denominar de design. O design Segundo esse pensamento, é difícilminante no sucesso dos produtos. Usa- é um campo interdisciplinar que com- saber quando se alcançou a perfeiçãobilidade conquista usuários e abre novos preende atividades de concepção e pro- no design. Entretanto, ele apontou quemercados. O que dizer do site de buscas jeto de um novo produto que pode, por ela pode ser alcançada tornando-o maisdo Google? Há tarefa mais simples do exemplo, ser um veículo ou apenas seu simples, que podemos interpretar comoque fazer uma busca no Google? Consi- painel, um novo modelo de telefone ce- facilitar a vida do usuário. Simplicidade nodere o caso mais recente da Apple ao lan- lular, uma interface gráfica de usuário design é essencial para a satisfação doçar o iPhone, como ilustrado na Figura 1. de alguma loja virtual ou de um siste- usuário e sucesso de um produto.Ele possui um conjunto de funcionalida- ma de software (que você usa em seu Uma questão que costumo fazer em di-des que podem ser acessadas através do computador pessoal ou notebook). versas ocasiões é: Por que o Google se tor-toque. O usuário seleciona as aplicações Design é, na realidade, uma atividade nou no site de buscas mais usado? A respos-(como, por exemplo, ouvir música, enviar que abrange uma ampla gama de apli- ta é: a necessidade humana por acesso amensagem e visualizar fotos) que deseja cações e, ao mesmo tempo, requer do informação e simplicidade. O segundoutilizar apenas tocando e manipulando designer projetista uma atenção espe- motivo é, na realidade, o principal. Nãoa tela. Ele pode ainda fazer zoom, am- cial com os aspectos funcionais e esté- há nada mais fácil do que fazer uma bus-pliando ou reduzindo imagens, e tudo ticos do produto. Isso também requer ca no Google. Você tem uma tela quasede forma intuitiva. muita imaginação e habilidade para toda branca e apenas uma janela na qual Perceba que a usabilidade é uma ca- criar modelos e fazer ajustes iterativos e você digita as palavras referentes ao con-racterística através da qual o usuário re-design. Os designers, assim como os teúdo de seu interesse, como ilustra a Fi-expressa sua satisfação em utilizar um artistas, têm sempre sido influenciados gura 2. Você, nem qualquer outra pessoa,produto ou serviço como, por exemplo, pelo ambiente onde vivem, e isto reflete precisa de treinamento ou auxílio para Figura 2. Simplicidade no site de buscas do Google.Figura 1. iPhone da Apple. Edição 06 – Engenharia de Software Magazine 49
    • Figura 3. Uso de barra de progresso na checagem de novo software. Figura 4. Uso de barra de progresso na checagem de novo software.fazer isso. Por quê? Trata-se de um único uma das heurísticas de um conjunto a terminada já que depende da conexãoserviço que é disponibilizado ao usuário ser apresentado no artigo. Isto visa tor- de Internet para verificação da existên-e da forma mais simples possível. nar a interface mais fácil de usar ao dar cia de disponibilidade de novas atuali- Perceba que usabilidade é o que os ao usuário a sensação de que ele está no zações, bem como do download da res-usuários desejam, isto é, facilidade de controle do sistema e de que ele pode se pectiva atualização.uso e facilidade de aprender a usar, recuperar de uma situação de erro, ou Os objetivos dessas guidelines são deque se traduz em simplicidade. Para desfazer uma ação que ele fez de modo munir o projetista de recomendaçõesproduzir interfaces de usuário que desatento e/ou indesejável. que pode orientá-lo durante o projeto daofereçam suporte à usabilidade, reco- Desde os primeiros esforços dos proje- interface de usuário de um produto. Es-mendações e heurísticas de usabili- tistas de interface de usuário para desen- ses documentos contêm informações quedade são usadas pelos projetistas. As volver produtos e sistemas de fácil uso, orientam o projetista quanto a:heurísticas compreendem conjunto de sempre houve a preocupação em prover 1. Organização (ou layout) da teladiretrizes, geralmente, que formam o suporte à usabilidade. Exemplo disso como, por exemplo, no uso de forma-conhecimento sobre para o tratamento compreende as diretrizes de projeto, co- tação e cores;de determinado problema. Esse pro- nhecidas como heurísticas ou guidelines, 2. Navegação na interface, padronizan-blema poderia ser o projeto de uma que contêm recomendações de projeto. do seqüência de realização de tarefas emrede neural, o projeto de uma casa ou Um exemplo de heurística é: situações semelhantes;projeto de uma interface de usuário de 3. Facilitando acesso a funcionalidadesum sistema de software. Essas mesmas Prover os usuários com informações do estado através da flexibilidade de controle doheurísticas servem de critério na ava- do sistema. usuário para entrada de dados ou execu-liação heurística da usabilidade de um Esta recomendação deve ser considera- ção de tarefas;produto, como discutido a seguir. da, principalmente, em situações onde se 4. Mantendo a atenção do usuário com têm operações de duração longa. Trata- uso de diferentes fontes, cores e sons, vi-Heurísticas de Usabilidade se de um feedback que a aplicação (isto é, sando alertar e dar feedback ao usuário. Heurísticas de usabilidade são princí- o sistema de software) provê ao usuário Objetivando compilar essas reco-pios resultantes da experiência e, geral- enquanto ele realiza uma tarefa no sis- mendações, Jakob Nielsen apresentoumente, aceitos que são aplicados no de- tema. Isto é ilustrado na Figura 3, que um conjunto de 10 (dez) heurísticassenvolvimento de sistemas interativos. mostra uma barra de status, comunican- para o projeto de interface de usuário,Elas também são empregadas durante do ao usuário o quanto da tarefa (de che- as quais estão disponíveis em http://a avaliação de produtos. Um exemplo car pela disponibilidade de novo softwa- www.useit.com/papers/heuristic/heu-é oferecer recursos para desfazer ações re) já foi realizada. ristic_list.html. As dez heurísticas dequando usando um software, comumen- Outro exemplo é apresentado na Fi- usabilidade, consideradas princípioste conhecido como Undo, que permite gura 4 quando o usuário tem o feedback para o projeto de interface de usuáriovocê navegar até a revisão anterior de da tarefa de atualização de um soft ware são apresentadas na Figura 5.um documento (ou arquivo) de modo antivírus. Neste caso, trata-se de uma As heurísticas mostradas no quadroque você possa aceitá-la ou rejeitá-la. barra de progresso indeterminado que acima servem a uma ampla variedadePortanto, prover mecanismo que permi- informa o usuário que a aplicação (isto de sistemas de soft ware e é um dos in-te ao usuário desfazer uma ação recen- é, soft ware antivírus) está realizando a gredientes do método de avaliação heu-te, como o exemplo do Undo, constitui tarefa. Todavia, ela tem duração inde- rística apresentado a seguir. Exemplos50 Engenharia de Software Magazine – Inspecionando a Usabilidade de Produtos
    • P R O J E TOidentificando problemas relacionados a te a avaliação. Essas heurísticas compre- 1. O problema é irrelevante e, portanto,essas heurísticas são mostrados e discu- endem heurísticas gerais, como as apre- desconsiderado.tidos na seção final do artigo. sentadas na Figura 5 e recomendações 2. Problema estético, o qual será apenas ou guidelines referenciados no quadro de corrigido se o prazo permitir.Avaliação Heurística links no final do artigo. 3. Problema simples (que tem baixa A avaliação heurística é um método de prioridade para correção).avaliação de usabilidade de sistemas e Procedimento de Avaliação 4. Problema difícil (que tem alta priori-produtos que permite ao avaliador de- • Reunião e estudo inicial do material dade para correção).tectar problemas de usabilidade. Esses disponibilizado durante a preparação 5. Problema danoso que requer corre-problemas, em geral, estão relacionados para a avaliação. ção imediata.com alguma das dez heurísticas de usa- • Cada avaliador deve realizar sua ava- • Após serem encerradas as avalia-bilidade apresentadas anteriormente. O liação de maneira independente e sem ções individuais de todos os avaliado-processo da avaliação heurística é apre- qualquer participação dos demais. Isto res, estes se reúnem com os projetistassentado a seguir. visa evitar que haja qualquer avaliação e eventuais observadores (especialistas ‘viciada’ em observações de problemas do domínio), quando se tem início umaCaracterísticas apontados por outros avaliadores. reunião que visa compilar as avaliações • Para aplicar o método de avaliação • A avaliação é realizada em duas feitas pelos avaliadores e consolidar aheurística, recomenda-se trabalhar com etapas: na primeira, o avaliador per- avaliação fi nal. Nesse momento, suges-3 a 5 avaliadores. Esses avaliadores são corre a interface explorando as prin- tões de como corrigir os problemas deespecialistas em usabilidade, como um cipais tarefas, objetivando ter uma usabilidade detectados são discutidas eengenheiro de usabilidade, ou enge- visão geral da interface; na segunda apresentadas para que as correções pos-nheiro de soft ware ou profissional si- etapa, percorre cenários de tarefas es- pecíficas, checando se esses cenários sam ser implementadas.milar que possua competência na área consideram os critérios (heurísticas Note que a avaliação heurística não de-de usabilidade. de usabilidade) considerados. veria ser empregada isoladamente. Ge- • A avaliação é feita individualmente • O avaliador faz anotações de pro- ralmente, ela é usada antes de se realizarpor cada um dos avaliadores envolvidos blemas de usabilidade observados e testes com usuário. Isso objetiva identifi-e eles não mantêm qualquer contato ou atribui grau de severidade a esses pro- car problemas grosseiros ou outros difí-colaboração antes da realização da ava- blemas. A atribuição do grau de seve- ceis de serem detectados em testes comliação. A comunicação entre os avalia- ridade do problema leva em conta a usuário como, por exemplo, aqueles quedores é apenas permitida após o térmi-no da avaliação. freqüência de ocorrência do problema, ocorrem em intervalos curtos de tempo e • Durante a avaliação, um especialista o nível de insatisfação do usuário (cau- outros que acontecem de modo não fre-de domínio pode também ser consultado sado pelo problema) e a dificuldade do qüente. Além disso, evita-se um custopelo avaliador a fim de esclarecer even- usuário em contornar o problema. Há maior com testes com usuários que po-tuais dúvidas sobre o sistema que está cinco graus de severidade: dem exigir mais tempo.sendo avaliado. • Cada avaliação individual pode durarde uma a duas horas, período no qual oavaliador obtém informações do sistemaa ser avaliado e realiza a avaliação. • Estudos (realizados por Jakob Niel-sen) indicam que cerca de 75% dosproblemas de usabilidade são detecta-dos quando se tem a participação decinco avaliadores.Preparação para Avaliação • Obter e ler a descrição do sistema afim de entender seu propósito e conjuntode funcionalidades oferecidas. • Conhecer os perfis de usuários e con-juntos de tarefas típicas realizadas poreles. Essas tarefas podem ser ilustradasatravés de cenários de interação que ca-racterize o uso do sistema. • Selecionar o conjunto de heurísticasde usabilidade a serem utilizadas duran- Figura 5. Heurísticas de Usabilidade propostas por Jakob Nielsen. Nielsen Edição 06 – Engenharia de Software Magazine 51
    • Identificação de Problemas de Usa- bilidade com Heurísticas Considere a Figura 6 que ilustra parte de um site de Buffet. Note que o layout do espaço tem as principais informações distribuídas na tela e uso de cores é ade- quado. O projetista fez uso de pequena quantidade de cores que não excede a quatro que é quantidade recomendada. Além disso, ele utiliza figuras, relacio- nadas às informações que são disponi- bilizadas para os usuários, que estão distribuídas de modo adequado na pá- gina principal. Entretanto, perceba na Figura 6 que há o uso das palavras “Clique aqui” que não deveriam ser utilizadas como elementos do design. Evitar o uso do “Clique aqui”, como texto âncora para um link de hi- pertexto, é uma das recomendações mais conhecidas do design. Note que esse problema está vinculado à quarta heu-Figura 6. Exemplo de site de um Buffet. rística (vide Figura 5), que recomenda a aderência a padrões (isto é, conjunto de recomendações ou guidelines de projeto). Numa situação como essa, o projetista poderia, por exemplo, ter usado: Conheça o nosso variado número de cardápios para todas as ocasiões. Na sugestão acima, é feito o uso de um texto âncora, servindo de link de um hi- pertexto que o usuário pode ter acesso. Note que fica mais intuitivo essa forma de acesso para o usuário. Outro exemplo ilustrado na Figura 7 mostra parte do site de uma instituição de ensino superior. Alguns problemas de usabilidade estão indicados na pró- pria figura. Primeiramente, o site contém um exces- so de informações na página principal. Muitas informações irrelevantes estãoFigura 7. Exemplo de site de instituição de ensino superior.52 Engenharia de Software Magazine – Inspecionando a Usabilidade de Produtos
    • P R O J E TOapresentadas logo na página principal. A Comentários Finais ações que um usuário (mais experien-oitava regra diz que devemos considerar Considerar as dez heurísticas de usa- te) não dispõe de teclas de atalho quea estética e fazer um projeto minimalista, bilidade apresentadas anteriormente e otimizariam seu tempo, em situaçõesou seja, informações desnecessárias ou outras recomendações é dever do proje- onde um ícone da barra de ferramentasde menor relevância deveriam ser trata- tista e estas são consideradas pelo ava- não tem sua funcionalidade reconheci-da em segundo plano e não serem exibi- liador quando avalia a interface de um da pelo usuário, ou ainda quando eledas na página principal. Isto porque es- soft ware ou outro produto. O usuário acha difícil localizar um funcionali-sas informações competem pela atenção também percebe isso quando manifes- dade num soft ware. Neste contexto, asdo usuário com informações relevantes. ta sua insatisfação no uso do soft ware heurísticas e outras diretrizes (ou guide- Note que o projeto deste site reserva es- ou quando comete erros em situações lines) de usabilidade servem para guiarpaço no lado inferior direito para cursos nas quais ele não pode desfazer alguma tanto projetistas quanto avaliadores emespecíficos de Fisioterapia e Direito. E ação realizada anteriormente, em situ- suas atividades.quanto aos demais cursos? Além disso,no lado esquerdo há dois locais atravésdos quais usuários podem acessar o cor-reio eletrônico da instituição (webmail)e um clube (específico) da instituição.O que isso tem de relevante para outrosusuários interessados em obter informa-ções da instituição. Perceba que o layout,embora exibido apenas parcialmente,precisa ser repensado e re-projetado, ob-jetivando atender a heurística de estéticae projeto minimalista. Um bom exemplo de um projeto desite de instituição de ensino é o da Uni-versity of Stanford disponível em htt p://www.stanford.edu, cuja página é re-produzida na Figura 8. Perceba o layout Figura 8. Exemplo de site de instituição de ensino superior.da página que faz distribuição do con-teúdo, há preocupação com a estética e Linkso projeto também é minimalista, pois Apple Computer, Inc., Introduction to Apple Human Interface Guidelinesapenas informações consideradas mais http://developer.apple.com/documentation/UserExperience/Conceptual/AppleHIGuidelines/XHIGIntro/chapter_1_section_1.htmlimportantes são colocadas em primeiro Fundamentals of Designing User Interaction do livro Microsoft Windows User Experienceplano, isto é, na página principal. Além http://www.microsoft.com/mspress/books/toc/2466.aspxdisso, a página tem um recurso de mapa Microsoft, Windows Vista User Experience Guidelinesdo site no canto superior direito, que http://msdn.microsoft.com/en-us/library/aa511258.aspxpermite ao usuário visualizar mais in-formações e, eventualmente buscar por NASA Goddard Space Flight Center - Usability Engineering Center – Handbook for Designing a Usable Web Site http://software.gsfc.nasa.gov/AssetsApproved/PA2.3.1.2.pdfinformações mais detalhadas. Recursoadicional que oferece mais detalhes ao Sun Microsystems, Inc., Java Look and Feel Design Guidelines http://java.sun.com/products/jlf/ed1/dg/higtoc.nf.htmusuário encontra-se no canto superioresquerdo que permite ao usuário ter Bad Human Factors Design http://www.baddesigns.com/uma visão expandida do menu. Estaadequação do site ocorre porque o pro- Heuristics for User Interface Design http://www.useit.com/papers/heuristic/heuristic_list.htmljetista considerou a terceira heurísticaque recomenda prover o usuário de con- Design Guidelines for the Web http://www.usabilitynet.org/tools/webdesign.htmtrole e liberdade escolha. The Usability Methods Toolbox http://jthom.best.vwh.net/usability/ Dê seu feedback sobre esta edição! Feedback eu Usability.gov s http://www.usability.gov/ Dê A Engenharia de Software Magazine sobre e tem que ser feita ao seu gosto. Para isso, precisamos saber o que você, s ta edição leitor, acha da revista! Dê seu voto sobre este artigo, através do link: www.devmedia.com.br/esmag/feedback Edição 06 – Engenharia de Software Magazine 53
    • Soluções para Gerenciamento de Riscos de Projetos De que se trata o artigo: Apresentação de uma ferramenta para apoiar o gerenciamento de riscos. Para que serve: A Gerência de Riscos é uma dis- Fornecer exemplo de aplicativo para ciplina bastante importante em suporte às atividades de gerenciamento ambientes de desenvolvimento de riscos em projetos. de software, permitido aos gerentes e Em que situação o tema é útil: membros de equipes o alcance de seus Em uma organização um programa de objetivos na execução de um projeto, gerenciamento de riscos tem o objetivo contribuindo para um melhor tratamen- de avaliar e controlar os riscos existen- to das ameaças e das oportunidades. Ao tes e assim decidir como serão tratados. disponibilizar visões de suporte e favo- Desta forma, o uso de ferramental de recer o compartilhamento das informa- apoio favorece o acúmulo de experiên- ções geradas, o gerenciamento dos riscos cias, ajuste da organização no nível de permite uma melhor tomada de decisão. maturidade próprio e, por conseguinte, Com base nessas premissas, foi ideali- adequação do respectivo processo de zada a ferramenta mPRIME Tool (www. Gerência de Riscos, de acordo com as li- cin.ufpe.br/~suppera) que através de suas mitações organizacionais. Cristine Gusmão funcionalidades dá suporte à avaliação, cristine@dsc.upe.br tratamento e controle dos riscos em um Professora Assistente do Departamento de ambiente organizacional. A problemá- tiplos projetos de desenvolvimento de Sistemas e Computação da Escola Politécnica tica tratada inclui o gerenciamento dos software, desenvolvida como add-in para da Universidade de Pernambuco (POLI – UPE), onde leciona várias disciplinas na graduação e riscos nas atividades organizacionais nos o Microsoft® Project, uma ferramenta pós-graduação (especialização e mestrado) e níveis operacional, tático e estratégico. já bastante difundida no ambiente de das Faculdades Integradas Barros Melo. Doutora Gestão de Projetos. Sua definição teve e Mestre em Ciência da Computação pela Uni- Visão Geral por base estudos acadêmicos dentro do versidade Federal de Pernambuco. Graduada em A mPRIME Tool é uma ferramenta de Centro de Informática da Universidade Engenharia Elétrica – Eletrotécnica pela Univer- sidade Federal de Pernambuco. gestão de riscos para ambientes de múl- Federal de Pernambuco (CIn –UFPE).54 Engenharia de Software Magazine – Soluções para Gerenciamento de Riscos de Projetos
    • F E R R A M E N TA C A S E Utilizando componentes de inteligên-cia artificial – ontologia (uma ontologiaé uma visão simplificada de um domí-nio de conhecimento [Gruber 1995]) deriscos fundamentada na Taxonomia deRiscos (Taxonomy Risk-based) do Soft wareEngineering Institute (SEI) – a mPRIMETool auxilia na execução das atividadesde identificação, monitoração e controledos riscos. O principal diferencial está na dis-ponibilidade de funções que levantamsituações de riscos, através de listas deverificação, facilitando a identificação deriscos de projetos e riscos entre projetos.Além disso, a mPRIME Tool é aderenteao Capability Maturity Model Integration(CMMI) [SEI 2001], pois suporta as fa-ses definidas por este modelo através defuncionalidades para a área de processode gerenciamento de riscos, contribuin-do na qualidade do processo utilizado. O conjunto das principais caracterís- Figura 1. Atividades comuns de um processo de Gerenciamento de Riscosticas da mPRIME Tool foi definido parasuportar os níveis de uma hierarquiaorganizacional e suas respectivas fon-tes de riscos.Principais Funcionalidades A mPRIME Tool foi desenvolvida parasuportar um processo integrado de Ge-rência de Riscos Organizacional. Dentrode uma organização podem-se ter váriostipos de riscos associados aos níveis es-tratégico, tático e operacional. Devidoà complexidade na construção dessasfuncionalidades, os requisitos essenciaisforam divididos entre os níveis organi-zacionais, facilitando a construção deversões diferenciadas e evolutivas damPRIME Tool. Para cada uma das versõesdefinidas, foram modeladas as funciona-lidades requeridas da ferramenta. A versão que trata das questões as-sociadas às necessidades do nível ope-racional foi desenvolvida e avaliada.As principais funcionalidades estãoassociadas à disponibilização das ati-vidades necessárias a um processo degerenciamento de riscos. Figura 2. mPRIME Tool: Tela de Identificação de Riscos Edição 06 – Engenharia de Software Magazine 55
    • Vários processos/abordagens de apoio ao gerenciamento de riscos de projetos podem ser encontrados na literatura [SEI 2001, PMI 2004, Gusmão 2007]. A seguir será apresentado conjunto de atividades que são comuns nesses pro- cessos/abordagens, como pode ser visu- alizado na Figura 1. 1. Planejar a Gerência de Riscos A mPRIME Tool, por ser integrada ao MS Project, suporta o planejamento dos recursos de hardware, software e pesso- al necessário à realização da Gerência deFigura 3. Modelo de uso da mPRIME Ontology Riscos, auxiliando o gerente do projeto a definir um plano estratégico para tratar cada um dos riscos. 2. Identificar Riscos Para auxiliar o gerente no momento da identificação dos riscos, a mPRIME Tool oferece uma série de possibilidades, ten- do como forma mais elementar a inserção manual de riscos que o próprio gerente tenha identificado. Porém, a forma mais relevante de identificação é através do uso de uma ontologia de riscos (mPRIME Ontology [Gusmão 2007; Costa e Gusmão 2008]), onde são sugeridos riscos referen- tes ao projeto. Essa sugestão pode ser fei- ta através de uma análise inteligente da lista de tarefas do projeto (WBS – Work Breakdown Structure) ou através das listas de verificação (checklists) contidas na fer- ramenta, como mostra a Figura 2. Através da visualização da Figura 2 é possível identificar três partes: (i) à es- querda (ressaltada) está a lista de verifi- cação apresentando o conjunto de situa- ções que associam riscos a questões de requisitos de um produto; (ii) na parte central é visualizada a lista dos quatroFigura 4. Tela para análise qualitativa do risco. riscos analisados até o momento para o projeto, e; (iii) à direita é apresentada a árvore de relacionamento entre os riscos identificados/analisados até o momento para o projeto. O processo é composto por um conjun- to de atividades que permitem identifi- car, analisar, documentar, acompanhar e monitorar os riscos. A mPRIME On- tology é usada principalmente na fase de identificação de riscos, permitindo à mPRIME Tool sugerir riscos para o pro- jeto que podem ser aceitos pelo gerente ou não. Estas sugestões podem ser feitas através do uso de seis funcionalidades56 Engenharia de Software Magazine – Soluções para Gerenciamento de Riscos de Projetos
    • F E R R A M E N TA C A S EFigura 5. Matriz e Árvore de Riscosdiferentes, apoiadas por três componen-tes dentro do sistema, como representa-do na Figura 3. Os três componentes centrais são: Questionário SEI: perguntas relacio-nadas aos riscos presentes na taxonomiado SEI, onde as questões são divididas deacordo com sub-ontologias. Relacionamentos Risco – Riscos: Sãoligações, definidas na mPRIME Ontology,que relacionam um risco a um conjuntode outros riscos. Ou seja, caso um projetotenha um risco X, haverá a possibilidadedo mesmo também ter um risco Y, sem-pre lembrando que um risco pode gerarou não outro risco. Relacionamentos “palavra-chave” –Riscos: São ligações, também definidasna mPRIME Ontology, que relacionamcertas palavras-chaves, que podem es-tar contidas nas tarefas do projeto, comum conjunto de riscos. Ou seja, caso esse Figura 6. Visão em detalhe da Árvore de Riscosprojeto tenha um risco X associado a umapalavra-chave, haverá a possibilidade do dos irão passar pelo componente de Re- lacionamentos Risco – Riscos, podendomesmo também ter um risco Y, sempre lacionamentos Risco – Riscos, podendo gerar uma quantidade maior de riscos.lembrando que uma palavra pode gerar gerar uma quantidade maior de riscos. • Sugestão de riscos pela lista de ris-ou não outro risco. • Sugestão de riscos pelas tarefas do cos do projeto: quando o usuário sele- Com o uso desses três componentes foi projeto: o usuário pode selecionar esta ciona esta opção, o sistema buscará a lis-possível gerar seis formas diferentes de opção, e o sistema fará uma varredura ta atual de riscos do projeto, e as passaráidentificação de riscos no projeto: em todas as palavras presentes na lista pelo componente de Relacionamentos • Sugestão de riscos pelo uso do de tarefas do projeto, procurando rela- Risco – Riscos, gerando assim uma novaquestionário SEI: o usuário pode res- cioná-las através do componente de Re- lista de riscos sugeridos.ponder o questionário fornecido (com- lacionamento “palavra-chave” – Risco, e • Sugestão de riscos pela lista de ris-pleta e/ou parcialmente) e, a partir sugerir os riscos encontrados. cos do projeto, com recursão: após gerardessas respostas, a mPRIME Tool irá • Sugestão de riscos pelas tarefas do riscos pela lista de riscos, o sistema irásugerir os riscos relacionados. projeto, com recursão: com esta opção repassar a lista resultante novamente • Sugestão de riscos pelo questionário selecionada, ao solicitar a sugestão de ris- pelo componente de RelacionamentosSEI, com recursão: com esta opção, ao se cos pelas tarefas do projeto, os riscos ge- Risco – Riscos, podendo gerar um núme-responder o questionário, os riscos gera- rados passarão pelo componente de Re- ro maior de riscos. Edição 06 – Engenharia de Software Magazine 57
    • presenta o relacionamento horizontal entre as várias classes de riscos, seus elementos e tipos. Cada risco pode ter associada uma cor para representar sua potencialidade. Como exemplo, temos na Figura 5 as co- res vermelho e azul representando graus extremos de severidade, muito alto e muito baixo, respectivamente. 4. Resolver Riscos Esta atividade também é conhecida pelo planejamento dos tratamentos para contingência (eliminação e mini- mização) dos riscos do projeto. O ge- rente terá a possibilidade de, para cada risco, criar um plano de contingência, cada um com uma lista de ações a seremFigura 7. Identificação de Riscos com a mPRIME Tool seguidas caso a probabilidade daquele risco esteja alta, e um responsável por É importante lembrar que esta funcio- to – relaciona as partes integrantes da aquele plano – caso ele precise ser postonalidade sugere os riscos ao usuário em Classe como, por exemplo, Requisitos; em prática, conforme Figura 4. O Pla-forma de lista, ou seja, o usuário pode- (iii) Tipo (origem) – indica a possível no de contingência é um arquivo textorá selecionar aqueles que ele achar mais origem do risco dentro do elemento anexado, uma vez que as organizaçõesconvenientes e adequados ao contexto do como, por exemplo, Estabilidade. Logo, possuem padrões de informações parti-projeto em análise, e descartar os demais. a instabilidade de requisitos em um cularizadas para seus ambientes.A Figura 2 apresenta, do lado direito, a projeto de desenvolvimento representa, Desenvolvendo um plano de contin-árvore de riscos gerada pela seleção dos dentro desta categorização – Engenha- gência antecipadamente pode-se reduzirrespectivos eventos de riscos para o pro- ria de Produto/Requisitos/Estabilidade, enormemente o custo de uma ação quan-jeto em análise. um risco de requisitos instáveis. A par- do o risco se concretizar. tir destas informações sobre possíveis3. Analisar e Priorizar Riscos origens de riscos é construída a árvore 5. Monitorar Riscos Dando suporte à atividade Análise de de riscos (Figura 2 – lado direito). Todos As atividades de monitoramento in-Riscos, a mPRIME Tool permite a análise os relacionamentos utilizados foram de- cluem o controle das informações levan-qualitativa e a priorização dos riscos de fi nidos na ontologia mPRIME Ontology tadas sobre os riscos do projeto, comoacordo com a probabilidade e o impacto (para conhecer um pouco mais sobre também a comunicação destas para osde ocorrência do evento, gerando o grau esta funcionalidade acesse o mPRIME membros da equipe do projeto.de exposição ao risco do projeto. Essas Risk Inferrer, disponível em htt p://www. A ferramenta disponibiliza através dainformações são configuráveis, pois as dsc.upe.br/~tspc). árvore de riscos uma visão gráfica davariáveis devem ser calibradas ao longo Em seguida, informações sobre a pro- situação de cada risco do projeto, comodo gerenciamento de projetos do am- babilidade e impacto do risco para o pro- pode ser visto na Figura 6. Desta forma,biente organizacional. jeto devem ser avaliadas. A exposição conjunto de riscos são comunicados para Para cada risco inserido ou sugerido ao risco (grau do risco para o projeto) é as partes interessadas no projeto.pela mPRIME Tool, o usuário poderá fa- gerada a partir das informações da pro- A definição desta lista de riscos e ati-zer uma análise inicial e atualizar esta babilidade e impacto. A tolerância está vidades associadas possibilita o registroanálise de acordo com as mudanças relacionada aos meios de tratamento do de critérios subjetivos baseados na expe-ocorridas no projeto. A ferramenta traz risco. Quanto menor a tolerância, maior riência da gerência e equipe de projeto,uma série de variáveis que devem ser é o potencial do risco para a organização. aumentando a memória organizacionalpreenchidas pelo gerente, como pode ser Ao final da análise, com as informações de projetos e, conseqüente, conhecimen-visto na Figura 4. Algumas dessas variá- relativas ao grau de exposição do proje- to sobre riscos. O gerente de projeto po-veis são: probabilidade de ocorrência do to ao risco, o registro é realizado através derá visualizar e atualizar a matriz derisco, nível de tolerância, impacto e tare- da atualização dos relacionamentos na riscos constantemente.fas relacionadas ao risco. árvore de riscos e da geração da matriz, O plano de contingência, elaborado A categorização dos riscos é segmenta- conforme visualizado na Figura 5. na atividade de resolver riscos, é usadoda em três partes: (i) Classe – relaciona A matriz do risco é o registro das como forma de controle dos riscos. O res-a categoria do risco como, por exemplo, informações importantes para repre- ponsável pelo plano de contingência temEngenharia do Produto; (ii) Elemen- sentar o risco, já a árvore de riscos re- a tarefa de executar as ações definidas no58 Engenharia de Software Magazine – Soluções para Gerenciamento de Riscos de Projetos
    • F E R R A M E N TA C A S Eplano. Riscos que atingem alta probabili- identificação de riscos, foram realiza- Depois da inclusão dos riscos inicial-dade de ocorrência são destacados atra- dos estudos de caso. Os estudos foram mente percebidos para o projeto ABP,vés de alertas que sugerem ao gerente a divididos em duas categorias: acadê- foram utilizadas as técnicas de questio-consulta de seus planos de contingência. micos e indústria. nário e mPRIME Ontology, disponibili- Através de relatórios com a matriz de Para a realização destes estudos de zadas na mPRIME Tool, para avaliaçãoriscos, a ferramenta facilita a atividade caso acadêmicos, foi definido conteúdo dos riscos ora inseridos (disponibiliza-de Comunicação dos Riscos dentro da programático aliando teoria e prática dos) e identificação de outros, até entãoorganização. É possível a geração de três para gerenciamento de riscos. O foco das não percebidos.tipos de relatórios sobre os riscos: Risk atividades práticas foi definido com base A lista inicial de riscos era compostaRanking, Risk Tree e Risk Planning. Estes nas funcionalidades disponibilizadas por 7 fatores de riscos (riscos em poten-relatórios apresentam de formas distin- pela mPRIME Tool. cial para o projeto), após a utilização dastas as informações dos riscos avaliados. A mPRIME Tool é uma ferramen- técnicas disponibilizadas na mPRIME A mPRIME Tool também permite que ta em evolução sendo utilizada em Tool, mencionadas anteriormente, a listao usuário defina novos tipos de riscos, projetos acadêmicos e como apoio ao foi avaliada e passou a conter 15 fatoresalém dos definidos na mPRIME Ontology. aprendizado da disciplina de Geren- de risco, conforme Figura 7.Como cada empresa possui uma políti- ciamento e Planejamento de Projetos,ca interna e um processo de desenvolvi- especialmente para a fundamentação Considerações Finaismento, muitas vezes exclusivo, a mPRI- dos conceitos de riscos, no Centro de A execução eficiente do gerenciamentoME Tool possibilita que o usuário defina Informática da Universidade Federal de riscos de projetos é muitas vezes difi-novas classes e atributos de riscos de de Pernambuco (CIn – UFPE) e no De- cultada pela falta de percepção dos ges-forma a adequar a lista inicial de riscos partamento de Sistemas e Computação tores - dificuldade na avaliação e contro-disponibilizada a estas particularidades. da Escola Politécnica de Pernambuco le dos riscos. Para apoiar esse processo, (DSC – POLI). foi desenvolvida uma ferramenta paraSituação Atual Com relação à utilização da mPRIME gestão de riscos em ambientes de múlti- A mPRIME Tool recentemente teve mais Tool, em casos práticos da indústria, a plos projetos, a mPRIME Tool, tendo poruma forma de identificação de riscos in- seguir será apresentado um conjunto de base estudo de doutorado do Centro decorporada ao seu portfólio de funciona- informações coletadas durante a identifi- Informática da UFPE.lidades. Nessa nova funcionalidade foi cação de riscos. Conforme mencionado, a mPRIME Toolenfatizada a importância do registro e está em constante evolução - sendo umarmazenamento das ocorrências de ris- Identificando Riscos no Projeto ABP projeto da academia onde novos estudoscos para futuras situações semelhantes. A mPRIME Tool foi utilizada para são realizados com a finalidade de com- A experiência do gerente com projetos apoiar a identificação dos riscos do pro- partilhar informações e garantir a quali-passados é muito importante para evitar jeto ABP, em análise em ambiente orga- dade do processo de desenvolvimento deque erros se repitam e tomar decisões nizacional de desenvolvimento de pro- software, subsidiando gestores na toma-corretas frente a um risco recorrente. As- dutos de soft ware. da de decisão.sim, é importante conhecer bem projetos Inicialmente foram transportadas aspassados, seus riscos e ações, para que, listas dos riscos já identificados para o Dê seu feedback sobre esta edição! Feedback euao deparar-se com um cenário similar, os projeto ABP (através das listas de verifi- s A Engenharia de Software Magazine Dê cação). A identificação foi feita de forma sobre emesmos possam ser considerados e miti- tem que ser feita ao seu gosto.gados ou evitados de forma mais eficaz. manual e pela experiência apresenta- Para isso, precisamos saber o que você, s ta edição O método CBR Risk (www.dsc.upe. da pelo gerente de projeto e sua equipe leitor, acha da revista!br/~pma/cbrrisk) possui como premissa (mais de 5 anos no domínio da aplica- Dê seu voto sobre este artigo, através do link:fundamental “projetos de software seme- ção). Os riscos foram digitalizados na www.devmedia.com.br/esmag/feedbacklhantes têm riscos semelhantes” [Trigo et mPRIME Tool.al 2007]. Dado um novo projeto, o CBR Risktenta identificar projetos anteriores similares Referênciasnuma base de dados. Uma vez identificados, [Costa e Gusmão 2008] Costa, T. S. P.; Gusmão, C. M. G. (2008) Definição de Ontologia para Identificação de Riscos de Projetos de Software. In: Ios riscos associados a estes projetos podem Seminário de Pesquisa de Ontologia no Brasil. Universidade Federal Fluminense. Niterói – RJ. [Gruber 1995] Gruber, T. R. (1995) Toward principles for the design of ontologies used for knowledge sharing. In: Formal Ontology in Conceptual Analysisser também associados ao projeto atual. A and Knowledge Representation. Kluwer Academic Publishers.busca por projetos semelhantes é feita atra- [Gusmão 2007] Gusmão, C. M. G. (2007) Um Modelo de Processo de Gestão de Riscos para Ambientes de Múltiplos Projetos de Desenvolvimento devés da técnica Raciocínio Baseado em Casos Software. Tese de Doutorado. Universidade Federal de Pernambuco – Recife/PE – Brasil. [PMI 2004] PMI - Project Management Institute. (2004) A Guide to the Project Management Body of Knowledge – ANSI/PMI 99-01-2004. Project Man-[Wangenheim e Wangenheim 2003]. agement Institute. Four Campus Boulevard. Newtown Square. USA. [SEI 2001] SEI - Software Engineering Institute. (2001) CMMI - Capability Maturity Model Integration version 1.1 Pittsburgh, PA. Software EngineeringEstudos de Caso Institute, Carnegie Mellon University. USA. [Trigo et al 2007] Trigo, T. R.; Lins, A. V.; Gusmão, C. M. G. (2007). Como forma de avaliar as funcionali- CBR Risk: Método para Identificação de Riscos em Projetos de Software In: Conferência Ibero-Americana InterTIC 2007, 2007, Porto – Portugal.dades da mPRIME Tool, em especial as International Association for The Scientific Knowledge – IASK. 355p. [Wangenheim e Wangenheim 2003] Wangenheim, C. G e Wangenheim, A. Raciocínio Baseado em Casos. Ed. Manole Ltda, São Paulo, Brasil. 2003relacionadas a técnicas e métodos de Edição 06 – Engenharia de Software Magazine 59
    • Introdução à Gestão de Conhecimento De que se trata o artigo: Nos últimos anos, a gestão de conhe- cimento surgiu como um dos principais focos de preocupação em grandes orga- N os últimos anos, a gestão de co- nizações. Mais do que a tecnologia, o co- nhecimento surgiu como um nhecimento é chave para companhias que dos principais focos de pre- pretendem agregar valor a seus produtos e ocupação em grandes organizações. serviços. Neste contexto, este artigo apre- Mais do que a tecnologia, o conheci- sentará algumas definições introdutórias à mento é chave para companhias que área de gestão de conhecimento. pretendem agregar valor a seus produ- Para que serve: tos e serviços (SVEIBY, 2000). Compa- A gestão de conhecimento apóia o nhias de sucesso são hoje caracteriza- compartilhamento do conhecimento nas das por possuírem a capacidade de gerir organizações. Esta é uma realidade que seu capital intelectual, consistentemente também pode estar presente em empre- produzindo conhecimento, rapidamente sas desenvolvedoras de software. disseminando-o através da organização, Em que situação o tema é útil: e transformando-o em novos produtos e Gestão de conhecimento é um assun- Rodrigo Oliveira Spínola serviços. Existem muitas histórias de to amplamente estudado atualmente e rodrigo@sqlmagazine.com.br Doutorando em Engenharia de Sistemas e Com- sucesso reportadas na literatura, toda- utilizado no apoio à disseminação do co- putação (COPPE/UFRJ). Mestre em Engenharia via devido ao valor intrínseco associado nhecimento nas organizações. de Software (COPPE/UFRJ, 2004). Bacharel em aos programas de sucesso em gestão de Ciências da Computação (UNIFACS, 2001). Co- laborador da Kali Software (www.kalisoftware. com), tendo ministrado cursos na área de Qua- lidade de Produtos e Processos de Software, Re- quisitos 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 Engenharia de Software Magazine.60 Engenharia de Software Magazine – Introdução à Gestão de Conhecimento
    • G E S TÃO D E CO N H E C I M E N TOconhecimento, pouco material técnico Como estes dados, a priori, não nos re- vo: (1) auxiliar as pessoas a externalizarestá disponível sobre o assunto. Neste velam muita coisa, há a necessidade de seu conhecimento de forma explícita emcontexto, este artigo apresentará algu- transformá-los em informação. Para que documentos ou sistemas; (2) auxiliar asmas defi nições introdutórias à área de isto ocorra, estes dados têm que passar pessoas a internalizar o conhecimentogestão de conhecimento. por um processo de: explícito produzido por outras pessoas; • Contextualização: identificar a finali- e (3) criar ambientes virtuais (ex. chatsDados, Informação, Conhecimento dade dos dados; e grupos de discussão) onde pessoas A sociedade em que vivemos vem • Condensação: resumir os dados em possam se socializar e compartilhar co-passando por várias transformações uma forma mais concisa; nhecimento sobre um determinado do-tecnológicas. Uma delas é a enorme • Categorização: identificar os compo- mínio de aplicação.facilidade de acúmulo de dados em nentes chave para a análise dos dados; Segundo DAVENPORT (1998), tam-repositórios automatizados. Dados • Cálculo: analisar os dados matemati- bém existe um processo de transfor-são coletados, por exemplo, ao fazer- camente ou estatisticamente; mação da informação em conhecimen-mos compras em um supermercado, ao • Correção: remover os erros dos dados. to. Este processo consiste de quatroirmos ao médico, ou ao votarmos em Depois destas etapas, os dados pos- etapas executadas implicitamente euma pesquisa interativa pelo telefone. suem uma utilidade bem definida. Com estão descritas a seguir:Acontece que estes dados não têm ne- a informação pronta para ser utilizada, • Comparação: ato de comparar as in-nhuma utilidade se não puderem ser outros dois problemas surgem: (1) como formações referentes a um acontecimen-efetivamente transformados em conhe- organizar e distribuir esta informação de to com situações diferentes;cimento utilizável por pessoas e insti- tal forma que ela gere conhecimento; e, • Conseqüências: que implicaçõestuições. Nesta seção, serão abordados (2) como gerenciar este conhecimento de a informação pode trazer na tomadaos conceitos de dados, informação e tal forma que este seja sempre incremen- de decisões;conhecimento e, a importância destes tado e compartilhado. • Conexões: relacionamento com ou-na transformação do conhecimento. Conhecimento pode ser definido como tros conhecimentos; Dado pode ser entendido como um informação útil e não trivial sobre um • Diálogo: pensamento de outras pes-conjunto de determinados fatos ou certo domínio de aplicação. Este conhe- soas sobre esta informação;um registro de uma transação. Algum cimento pode ser codificado de forma Com estas etapas concluídas, podemostempo atrás, tinha-se a ilusão de que explícita em documentos ou sistemas de dizer que existe um processo através doquanto mais dados fossem coletados, informação. Muitas vezes, todavia, ele qual o dado pode gerar conhecimento.mais “sábia” seria uma instituição. existe de forma tácita, residindo apenas Este está demonstrado na Figura 1.Porém, a experiência tem-nos mostra- na cabeça de pessoas. Além das funcio- Nesta seção, verificamos as diferen-do que o trabalho para contextualizar nalidades de um sistema típico de pro- ças existentes entre dados, informaçãoestes dados, ou seja, atribuir um signi- cessamento de informações, sistemas e conhecimento e, também, a impor-ficado a ele, é tão ou mais importante computacionais de auxílio à gestão de tância de cada um para as organizaçõesque coletá-los. conhecimento também têm por objeti- atuais levando em conta o processo deFigura 1. Dados, Informação e Conhecimento. Adaptado do modelo proposto por DAVENPORT (1998). Edição 06 – Engenharia de Software Magazine 61
    • criação do conhecimento. Tendo enten- dido o processo de transformação dos dados em informação e desta em co- nhecimento, será discutido na próxima seção diversos processos de transferên- cia do conhecimento. Transferência de Conhecimento O conhecimento como bem não tan- gível, é altamente mutável e possui características peculiares em seus di- versos tipos de ocorrência. Segundo DIXON (2000), existem formas diferen- tes de transferência do conhecimento para diferentes tipos de conhecimento a serem socializados. Segundo DIXON (2000), as cinco ma-Figura 2 Etapas da Transferência do Conhecimento Adaptado do modelo proposto por DIXON (2000: 23) 2. Conhecimento. 23). neiras de transferência do conhecimento são: (1) Transferência em Série; (2) Trans- ferência Próxima; (3) Transferência Dis- tante; (4) Transferência Estratégica e; (5) Transferência Técnica. Cada um desses tipos possui suas características próprias que tornam o processo de socializar o conhecimento complexo. Para distinguir essas categorias, existem três pontos a serem discutidos: • O grau de similaridade das tare- fas e contexto do conhecimento para o receptor; • A freqüência na qual a tarefa ocorre; • O tipo de conhecimento a ser transferido. Estes três pontos influenciam direta- mente o processo de transferência doFigura 3 Modelo Centralizado (DIXON: 150) 3. Figura 4. Modelo Distribuído (DIXON: 151) 462 Engenharia de Software Magazine – Introdução à Gestão de Conhecimento
    • G E S TÃO D E CO N H E C I M E N TOconhecimento. De acordo com DIXON ção não havendo um grupo de peritos. • A equipe destino deve possuir capa-(2000), esta atividade possui algumas Com isso, o fluxo de compartilhamen- cidade de absorver o conhecimento pro-etapas que se repetem continuamente. to do conhecimento aumenta conside- duzido por outro grupo de pessoas;(1) Uma equipe realiza uma tarefa (2) ravelmente e contribui com uma gran- • O processo deve ser executadoatingindo um objetivo. (3) Outra equipe de vantagem competitiva. Este modelo freqüentemente;analisa o relacionamento entre as ações pode ser visualizado na Figura 4. • O tipo de conhecimento transferidotomadas e os objetivos atingidos. Desta Com este último modelo em mente, pode ser tanto tácito como explícito.forma, (4) o conhecimento é adquirido analisaremos agora cinco tipos de trans- Neste tipo de sistema, existem algunspela equipe. Depois que (5) o sistema ferência do conhecimento. Cada um procedimentos que devem ser tomadospara transferência do conhecimento é destes possui sua particularidade, mas a para o sucesso da transferência. O prin-selecionado, o mesmo (6) é externalizado presença de um não impede a utilização cipal deles é as reuniões regulares e rá-de forma útil para outras equipes. Estas de um outro qualquer. pidas com participação das pessoas en-(7) recebem o conhecimento e adaptam volvidas na criação do conhecimento. Aàs suas necessidades. A partir daí, o ciclo Transferência em Série razão pela qual os encontros devem serrecomeça. Essas etapas podem ser visu- Muitas vezes, tarefas são concluídas curtos é a indisposição que, geralmente,alizadas na Figura 2. repetidamente sem que haja um ganho os participantes têm em dispor seu tem- A evolução destas etapas envolvidas de eficiência durante as inúmeras ve- po para reuniões.no processo de compartilhamento do zes em que elas se repetem. Para que oconhecimento foi bastante influencia- processo envolvido na execução destas Transferência Próximada pelo novo entendimento de como a tarefas se desenvolva, é necessária a Bastante semelhante ao tipo de trans-experiência estava distribuída nas or- análise das ações envolvidas e resul- ferência analisado anteriormente ondeganizações. Há um tempo atrás, as em- tados obtidos para que estes possam constatamos a necessidade de haver tarefaspresas definiam as pessoas que seriam auxiliar o desenvolvimento de melho- similares a serem efetuadas pelas equipesas possíveis detentoras da informação. rias. Entretanto, para que isto ocorra, é geradoras e receptoras do conhecimento, aCom isso, o processo decisório e de necessário que todos os integrantes da transferência próxima é fundamentada nosocialização do conhecimento estava equipe em questão estejam dispostos a fato de que novas formas mais eficientes deamarrado a um selecionado grupo de contribuir com sua experiência. Desta executar determinadas rotinas são desco-peritos em determinado assunto. Esta forma, podemos definir a transferência bertas e devem ser compartilhadas.abordagem, conhecida como modelo em série como um processo que move Apesar do nome insinuar a necessidadecentralizado (DIXON, 2000), mesmo o conhecimento adquirido individual- de que fonte e destino do conhecimento de-que ultrapassada ainda está presente mente, de forma que este conhecimen- vem estar localizados próximos um ao ou-em diversas instituições. A Figura 3 to possa ser integrado e aprovado pela tro, seu verdadeiro significado não é este.demonstra o fluxo do conhecimento equipe como um todo. Neste contexto, a palavra próximo significaneste domínio. Sistemas que auxiliam a transferência semelhança entre as atividades exercidas. Por outro lado, análises recentes de conhecimento em série possuem as Sistemas que auxiliam a transferênciacomprovaram que uma abordagem seguintes características: próxima de conhecimento possuem asdistribuída (DIXON, 2000) seria mais • A equipe à qual o conhecimento se seguintes características:adequada ao contexto socioeconômico destina deve trabalhar com tarefas simi- • A equipe à qual o conhecimento seatual. Neste modelo, o conhecimento lares porém, não há a necessidade de que destina deve trabalhar com tarefas bas-está distribuído por toda a organiza- o contexto seja o mesmo; tante parecidas; Edição 06 – Engenharia de Software Magazine 63
    • Figura 5. Camadas de um Sistema de Auxílio à Gestão de Conhecimento. • A equipe destino deve possuir capa- ajude no desenvolvimento da instituição lares, porém o contexto varia bastantecidade de absorver o conhecimento pro- é constante. Daí, novos métodos em di- causando a necessidade de adaptação doduzido por outro grupo de pessoas; ferentes contextos são criados constante- conhecimento adquirido; • O processo deve ser executado mente. Estes são um grande diferencial • A equipe destino deve possuir capa-freqüentemente; competitivo que cada empresa possui cidade de absorver o conhecimento pro- • O tipo de conhecimento transferido é em relação às suas concorrentes. Porém, duzido por outro grupo de pessoas, masprincipalmente o explícito sendo a parti- o processo de disseminar este conheci- essa capacidade pode variar bastante;cipação do tácito limitada. mento contextual pela instituição como • O processo é executado freqüentemente; Existem algumas linhas mestras que um todo ou ao menos aos interessados • O tipo de conhecimento transferido épodem auxiliar neste modelo de sociali- é uma tarefa difícil. Um exemplo que se em sua maior parte implícito. Contudo,zação. A principal delas é a utilização de encaixa perfeitamente neste caso é a ex- pode ser que haja uma pequena quanti-meios eletrônicos para difusão do conhe- ploração petrolífera. Para esta, existem dade de forma explícita.cimento. Por ser este em sua grande par- alguns procedimentos a serem seguidos,te explícito, a utilização de servidores de entretanto a forma como são utilizados Transferência Estratégicainformação ganha importância. Assim, depende muito das condições ambien- Em muitas organizações, a velocidadeos usuários do sistema podem especificar tais e também intelectuais dos técnicos com que o mercado vem estabelecendoem qual tipo de conteúdo estão interessa- envolvidos. Tendo analisado este exem- novos paradigmas e provocando rees-dos assim como contribuir externalizan- plo, podemos conceituar transferência truturações internas nas empresas fazdo sua experiência. Os problemas que po- distante como aquela em que o tipo de com que haja a necessidade de açõesdem surgir deste modelo baseiam-se no tarefa executada pela equipe fonte e des- pouco freqüentes que muitas vezesfato de que pode haver quantidade muito tino do conhecimento são as mesmas, fogem ao domínio de conhecimentogrande de informação dificultando a re- porém com características peculiares dos envolvidos. Para que não ocorramcuperação destas e aumentando também que exigem adaptação do conhecimento esforços desnecessários, caso algumquantidade de tempo necessária no pro- adquirido a cada realidade. outro grupo já tenha desempenhadocesso de internalização do conhecimento. Sistemas que auxiliam a transferência atividade semelhante, esta experi- distante do conhecimento possuem as ência deve ser compartilhada. NesteTransferência Distante seguintes características: contexto se enquadra a transferência Em diversas organizações, a pesquisa • A equipe à qual o conhecimento se estratégica. Este tipo de transferênciapor novas metodologias cujo resultado destina deve trabalhar com tarefas simi- se aplica quando:64 Engenharia de Software Magazine – Introdução à Gestão de Conhecimento
    • G E S TÃO D E CO N H E C I M E N TO A equipe à qual o conhecimento se de peritos em determinadas áreas cujos Antes de discutirmos as sete camadasdestina deve trabalhar com tarefas simi- problemas incomuns possam acontecer. que compõem um sistema de auxílio àlares, porém o contexto varia bastante Esse tipo de transferência se aplica quando: GC, é importante entender os dois im-causando a necessidade de adaptação do • A equipe à qual o conhecimento se portantes recursos que tornam possívelconhecimento adquirido; destina trabalha com tarefas diferentes seu desenvolvimento: comunicação e o • A equipe destino possui baixa ca- das desenvolvidas pelo grupo de origem armazenamento de dados.pacidade de absorver o conhecimento sendo, porém, o contexto igual; A comunicação de dados tem grandeproduzido por outro grupo de pesso- • A equipe destino deve possuir alta importância no contexto da gestão deas uma vez que nunca havia participa- capacidade de absorver o conhecimen- conhecimento uma vez que a mesmado anteriormente de um processo de to produzido pelo outro grupo uma permite que o conhecimento implícitoreestruturação; vez que a linguagem técnica utilizada e explícito seja compartilhado de várias • O processo não é executado fre- é a mesma; maneiras. As redes de computadoresqüentemente; • O processo é executado freqüentemente; permitem a transferência de conheci- • O tipo de conhecimento transferido • O tipo de conhecimento transferido é mento e a colaboração entre integran-pode ser tanto tácito como explícito, sen- extremamente explícito. tes das organizações que desejam gerirdo os dois de grande importância para o Como citado anteriormente, nesta ca- seu conhecimento. Utilização de vídeosucesso da socialização. tegoria de transferência a utilização de conferência e e-mails são alguns exem- Como este processo de transferência meios eletrônicos é bastante tendencio- plos que já estão muito difundidos naestá diretamente envolvido com toma- sa. Aplicações como fóruns de discus- sociedade atual.das de decisão da instituição, a defi ni- são, chats, repositórios estruturados de O armazenamento de dados é o outroção do conhecimento a ser internaliza- documentos e ferramentas de busca es- mecanismo de grande importância parado parte da gerência da empresa. Tendo tão presentes. a gestão de conhecimento. É o armaze-esta defi nição, outro passo importante é namento que permite a criação de umaa seleção de uma equipe de especialis- Sistemas de Auxílio à Gestão de memória organizacional onde o que étas que possam coletar e interpretar o Conhecimento produzido é guardado em memória per-conhecimento colocando-o numa forma Conceitualmente, um sistema compu- sistente e facilmente recuperável. Parautilizável. Mas, o fato de ter que dispo- tacional de auxílio à gestão de conheci- isso, sistemas modernos de armazena-nibilizar uma equipe de peritos em um mento pode ser dividido em sete cama- mento possuem mecanismos para a qua-determinado assunto encarece bastante das (TIWANA, 2000): interface, acesso e lificação da informação, armazenagemesta forma de compartilhamento. autenticação, inteligência colaborativa distribuída de dados, acesso remoto, e filtragem, camada de aplicação, trans- controle de acesso, e segurança.Transferência Técnica porte, integração e por fim, os repositó- Como mencionamos anteriormente, De todos os tipos de transferência estu- rios de dados. Esta estrutura em cama- nosso modelo conceitual definido paradados até agora, este é o mais simples de das está mostrada na Figura 5. os sistemas de auxílio à gestão do conhe-ser implementado eletronicamente. As Como podemos perceber, cada camada cimento é dividido em sete camadas:informações aqui compartilhadas são de possui seu próprio aparato tecnológico 1. Interface: Esta camada é a única ca-natureza técnica e podem ser facilmen- para realizar suas funções e que alguns mada com a qual o usuário interage dire-te explicitadas. Este tipo de socialização destes meios já estão bastante dissemi- tamente. É de fundamental importânciaganha importância em organizações nados entre empresas e instituições em uma boa concepção da mesma, caso con-onde ocorra a utilização de equipamen- geral. O que se necessita é uma efetiva trário o sistema como um todo poderátos tecnológicos e outros processos téc- integração destas tecnologias e a adição fracassar. Além de estar comprometidanicos. Isso não significa que o conheci- de alguns outros componentes para o com o usuário, a plataforma a qual estamento esteja concentrado em manuais e/ desenvolvimento de um bom sistema de camada esta associada deve tambémou relatórios. Sabemos das necessidades gestão de conhecimento. suprir os seguintes requisitos básicos: Edição 06 – Engenharia de Software Magazine 65
    • protocolos eficientes, portabilidade, es- Neste caso, os ponteiros criados para de repositórios que possam ser integra-calabilidade, segurança, integração com outros documentos não se perdem tor- dos de forma a prover uma estrutura co-sistemas existentes e flexibilidade. nado a navegação pela informação me- esa de acesso à informação. 2. Acesso e autenticação: Esta camada nos incômoda e menos frustrante.tem como principal função autenticar 4. Aplicação: Esta camada engloba as Considerações Finaisusuários válidos, restringir e prover ferramentas de integração usuário/má- Este artigo apresentou alguns conceitossegurança para o acesso às outras ca- quina que provêem boa parte da fun- básicos relacionados à gestão de conhe-madas. Como as redes de comunicação cionalidade de um sistema de gestão cimento. Esta é uma importante área dopara o compartilhamento do conheci- de conhecimento. conhecimento e tem sido estudada emmento não têm sido limitadas apenas 5. Transporte: Tendo decidido a pla- diferentes contextos. Um exemplo é suaàs intranets, a importância dada à se- taforma a ser utilizada, é preciso co- aplicação em ambientes de desenvolvi-gurança está em crescimento. nhecer a maneira como os dados serão mento de software e na captura de deci- 3. Inteligência colaborativa e fi ltra- transportados pelas redes de comu- sões arquiteturais durante a fase de pro-gem: A idéia básica desta camada é nicação. A forma como os dados são jeto. É um assunto que está longe de serprover a estrutura funcional para que transportados depende de quem soli- esgotado e que certamente voltaremos ase consiga fazer pesquisas, resumos, in- cita o envio dos mesmos e das necessi- ter outras matérias mais específicas emterpretações e a análise de grandes vo- dades de serviço que cada tipo de dado edições futuras.lumes de dados habilitando os usuários tem na sua transferência.do sistema de gestão de conhecimento 6. Camada de integração de siste- Dê seu feedback sobre esta edição! Feedbacka contextualizá-los de forma efetiva e mas legados: Esta camada é necessária eu s Dêeficiente. Para este fim, existe um gama quando se quer integrar plataformas A Engenharia de Software Magazine sobre e tem que ser feita ao seu gosto.de possibilidades de combinação de tec- diferentes de um ambiente heterogêneo Para isso, precisamos saber o que você, s tanologias: ferramentas de inteligência ar- em uma determinada empresa. É co- leitor, acha da revista! ediçãotificial, redes neurais, agentes inteligen- mum ver companhias reestruturando Dê seu voto sobre este artigo, através do link:tes, pesquisa por conteúdo e pesquisa sua infra-estrutura e “empacotando”por atributo, dentre outros. Por ser um seus sistemas legados com camadas de www.devmedia.com.br/esmag/feedbacksistema que sofre constantes interações soft ware que permitem a adoção de pa-por parte dos usuários e por se tratar de drões mais modernos de comunicação Referênciasum sistema com a infra-estrutura lógica e acesso a dados.(protocolos de comunicação) e física da 7. Armazenamento: Nesta camada os TIWANA, Amrit. The Knowledge Management Toolkit: Practical Techniques for Buildings a Knowledge Management System.Internet, é importante também que sua dados, informação e “conhecimento” são Prentice Hall, 2000.estrutura de funcionamento interno não armazenados para posterior consulta, al- SVEIBY, Karl; STORK, John; HILL, Patricia, et al. Gestão do Conhecimen-tenha como base estruturas estáticas já teração, e deleção. A forma como a infor- to: Um Novo Caminho. HSM Management, setembro-outubro, 2000. DAVENPORT, Thomas; PRUSAK, Laurence. Working Knowledge: Howbastante difundidas com o conceito de mação é armazenada difere a depender Organizations Manage what They Know. Harvard Business Schoolapontadores, mas sim, dinâmicas que do tipo da mesma (imagem, som, anima- Press, 1998. DIXON, Nancy M. Common Knowledge: How Companies Thrive byautomaticamente se adaptem a modifi- ções, documentos). Existe neste nível a Sharing what They Know. Harvard Business School Press, 2000.cações na localização das informações. necessidade de se utilizar diversos tipos66 Engenharia de Software Magazine – Introdução à Gestão de Conhecimento