ESM24 Alta

EDITORIAL
D
Ano 2 - 24 Edio - 2010 Impresso no Brasil
Corpo Editorial
Colaboradores Rodrigo Oliveira Spnola rodrigo@sqlmagazine.com.br Marco Antnio Pereira Arajo Eduardo Oliveira Spnola Capa e Diagramao Romulo Araujo - romulo@devmedia.com.br Coordenao Geral Daniella Costa - daniella@devmedia.com.br Revisor e Supervisor Thiago Vincenzo - thiago.v.ciancio@devmedia.com.br Na Web www.devmedia.com.br/esmag
Apoio
iversas metodologias de desenvolvimento de software voltadas para o controle tm sido elaboradas uma vez que um projeto de software, ao longo do seu ciclo de vida, tem uma grande quantidade de itens de informao tais como documentos, cdigo-fonte, dados, manuais e outros, produzidos e at modificados, pelos mais diversos motivos. Para que a qualidade do software seja garantida, em funo destas modificaes, necessrio que se faa uso da Gerncia de Configurao de Software (GCS). A Gerncia de Configurao de Software tem como objetivo gerenciar e controlar a evoluo de um software atravs do controle formal de verso e solicitao de mudanas. uma forma sistemtica e organizada de controlar as modificaes de um software tornando possvel manter sua integridade ao longo do tempo. A quantidade de itens que podem estar sob controle da GCS e os nveis de controle exigidos sobre estes itens ir variar de empresa para empresa ou mesmo de projeto para projeto. Sendo assim, o uso desta prtica em conformidade com modelos de maturidade mantidos por entidades que possuam credibilidade nacional e internacional, e tambm o uso de ferramentas adequadas que garantam a qualidade deste processo, fundamental para que uma empresa obtenha xito e reconhecimento. Para empresas de grande porte, isto no chega a ser um grande problema pois normalmente se dispem de capital e pessoal qualificado para manter tais prticas. Entretanto, quando voltamos a olhar para as pequenas empresas, o cenrio exatamente o oposto. Neste contexto, a Engenharia de Software Magazine destaca nesta edio uma matria cujo objetivo mostrar uma soluo especifica, de boa qualidade e baixo custo, que atenda as exigncias dos modelos de maturidade e que possa ser utilizada para implementar a Gerncia de Configurao de Software em pequenas empresas. Uma leitura muito interessante. Alm desta matria, esta edio traz mais seis artigos: Automatizando Testes Funcionais em Aplicaes Web Testes de segurana A Comunicao no Processo de Software Testes funcionais automatizados com Hudson e Selenium RC Medio de Software Anlise Quantitativa de Riscos e suas Tcnicas Desejamos uma tima leitura! Equipe Editorial Engenharia de Software Magazine
Atendimento ao Leitor A DevMedia conta com um departamento exclusivo para o atendimento ao leitor. Se voc tiver algum problema no recebimento do seu exemplar ou precisar de algum esclarecimento sobre assinaturas, exemplares anteriores, endereo de bancas de jornal, entre outros, entre em contato com:
Cristiany Queirz Atendimento ao Leitor www.devmedia.com.br/mancad
(21) 2220-5338
Rodrigo Oliveira Spnola

rodrigo@sqlmagazine.com.br Doutorando em Engenharia de Sistemas e Computao (COPPE/UFRJ). Mestre em Engenharia de Software (COPPE/UFRJ, 2004). Bacharel em Cincias da Computao (UNIFACS, 2001). Colaborador da Kali Software (www.kalisoftware.com), tendo ministrado cursos na rea de Qualidade de Produtos e Processos de Software, Requisitos e Desenvolvimento Orientado a Objetos. Consultor para implementao do MPS.BR. Atua como Gerente de Projeto e Analista de Requisitos em projetos de consultoria na COPPE/ UFRJ. Colaborador da Engenharia de Software Magazine.
Kaline Dolabella Gerente de Marketing e Atendimento kalined@terra.com.br

(21) 2220-5338
Publicidade Para informaes sobre veiculao de anncio na revista ou no site entre em contato com:
Kaline Dolabella publicidade@devmedia.com.br
Marco Antnio Pereira Arajo - Editor

(maraujo@devmedia.com.br) Doutor e Mestre em Engenharia de Sistemas e Computao pela COPPE/UFRJ - Linha de Pesquisa em Engenharia de Software, Especialista em Mtodos Estatsticos Computacionais e Bacharel em Matemtica com Habilitao em Informtica pela UFJF, Professor e Coordenador do curso de Bacharelado em Sistemas de Informao do Centro de Ensino Superior de Juiz de Fora, Professor do curso de Bacharelado em Sistemas de Informao da Faculdade Metodista Granbery, Professor e Diretor do Curso Superior de Tecnologia em Anlise e Desenvolvimento de Sistemas da Fundao Educacional D. Andr Arcoverde, Analista de Sistemas da Prefeitura de Juiz de Fora, Colaborador da Engenharia de Software Magazine.
Fale com o Editor!

muito importante para a equipe saber o que voc est achando da revista: que tipo de artigo voc gostaria de ler, que artigo voc mais gostou e qual artigo voc menos gostou. Fique a vontade para entrar em contato com os editores e dar a sua sugesto! Se voc estiver interessado em publicar um artigo na revista ou no site SQL Magazine, entre em contato com os editores, informando o ttulo e mini-resumo do tema que voc gostaria de publicar: Rodrigo Oliveira Spnola - Colaborador editor@sqlmagazine.com.br
Eduardo Oliveira Spnola

(eduspinola@gmail.com) Colaborador das revistas Engenharia de Software Magazine, Java Magazine e SQL Magazine. bacharel em Cincias da Computao pela Universidade Salvador (UNIFACS) onde atualmente cursa o mestrado em Sistemas e Computao na linha de Engenharia de Software, sendo membro do GESA (Grupo de Engenharia de Software e Aplicaes).
Caro Leitor,
Para esta edio, temos um conjunto de 4 vdeo aulas. Estas vdeo aulas esto disponveis para download no Portal da Engenharia de Software Magazine e certamente traro uma significativa contribuio para seu aprendizado. A lista de aulas publicadas pode ser vista abaixo:
Tipo: Validao,Verificao & Teste Ttulo: Estratgia de Teste Funcional baseada em Casos de Uso Parte I Explorando Casos de Uso para apoiar Testes Autor: Arilo Claudio Dias Neto Mini-Resumo: Nesta vdeo-aula apresentado como preparar um modelo de casos de uso e suas especificaes para apoiar nas atividades de teste. So apresentadas as informaes que devem compor a especificao de um caso de uso e em seguida um template de especificao de casos de uso. Ao final, apresentado um processo para apoiar no projeto de testes de software a partir de casos de uso. Tipo: Validao,Verificao & Teste Ttulo: Estratgia de Teste Funcional baseada em Casos de Uso Parte III Projeto dos Testes a partir de Casos de Uso Autor: Arilo Claudio Dias Neto Mini-Resumo: Nesta vdeo-aula apresentado com detalhes o ltimo passo que compe o processo para apoiar no projeto de testes de software a partir de casos de uso: a alocao de casos e procedimentos de teste. Para isso, seguido um caso de uso de exemplo (REALIZAR DEPSITO) e passamos por todas as etapas para construo dos testes.Neste momento utilizamos os critrios para gerao dos testes (particionamento por equivalncia, anlise do valor limite e grafo de causa-efeito) apresentados em aulas anteriores. Tipo: Validao,Verificao & Teste Ttulo: Estratgia de Teste Funcional baseada em Casos de Uso Parte IV Exerccio Autor: Arilo Claudio Dias Neto Mini-Resumo: Nesta vdeo-aula apresentado um outro exemplo de construo de testes de software a partir de casos de uso (CADASTRAR FUNCIONRIO).Com isso,ficam disponveis 2 exemplos com caractersticas diferentes a fim de facilitar o aprendizado. Ao final,so deixados pontos em aberto para que quem estiver acompanhando as aulas possa dar continuidade ao projeto dos testes, como um exerccio.
Caro Leitor
Tipo: Validao,Verificao & Teste Ttulo: Estratgia de Teste Funcional baseada em Casos de Uso Parte II Projeto dos Testes a partir de Casos de Uso Autor: Arilo Claudio Dias Neto Mini-Resumo: Nesta vdeo-aula apresentado com detalhes o processo para apoiar no projeto de testes de software a partir de casos de uso, citado na aula anterior. Ele formado por uma sequncia de 4 passos que vo desde a identificao dos atores de um modelo de casos de uso at a construo de casos e procedimentos de testes. Nesta vdeo-aula so apresentados apenas os 3 primeiros passos deste processo.
NDICE
Engenharia 06 - Testes de segurana
Eduardo Habib
14 - Gerncia de Configurao
Alberto Boller Filho, Rodrigo Oliveira Spinola, Marcelo Nascimento Costa e Marcos Kalinowski
31 - Medio de Software
Monalessa Perini Barcellos
Agilidade 38 - A Comunicao no Processo de Software

Mrcia Regina Simm Cant
Planejamento e Gerncia 43 - Anlise Quantitativa de Riscos e suas Tcnicas

Marcio Souza, Cristine Gusmo e Hermano Perrelli
Desenvolvimento 49 - Automatizando Testes Funcionais em Aplicaes Web

Arilo Cludio Dias Neto
57 - Testes funcionais automatizados com Hudson e Selenium RC

Fabrcio Nogueira de Almeida, Victor Vidigal Ribeiro e Marco Antnio Pereira Arajo
Engenharia de Software Magazine
Edio 05 - Engenharia de Software Magazine
Engenharia
Nesta seo voc encontra artigos voltados para testes, processo, modelos, documentao, entre outros
Testes de segurana
Testes de segurana em aplicaes web
De que se trata o artigo?

Neste artigo veremos a importncia de se realizar testes de segurana em aplicaes Web. Ao desenvolver uma aplicao web, deve-se pensar na segurana dos dados durante toda a fase de desenvolvimento. Isso minimiza as falhas de segurana que chegam ao usurio final. Esse artigo tratar dos testes de segurana realizados pelo testador aps o software j estar desenvolvido. Ser demonstrada a importncia de se realizar testes em aplicaes web, as falhas de segurana mais comuns na Internet e, por fim, sero demonstradas extenses do Firefox e algumas ferramentas que auxiliam nos testes de aplicaes web.
Para que serve?

A realizao de testes de segurana em aplicaes Web diminui a probabilidade de um software ser disponibilizado para o usurio final com falhas crticas de segurana e que podem causar prejuzos ao usurio, seja ele financeiro ou a liberao de dados sigilosos.
Em que situao o tema til?

Testar a segurana de aplicaes Web importante em qualquer aplicao que contenha dados sigilosos e/ou onde ocorra, de alguma forma, transaes financeiras entre o cliente e o servidor, pois diminuem a probabilidade do software ser colocado em produo com uma falha crtica de segurana e que pode vir a ser explorada por alguma pessoa mal intencionada.
Eduardo Habib
eduardohabib@gmail.com
Possui Graduao e mestrado em Cincia da Computao na UFMG. Atua na rea de testes de software h nove anos. Nesses anos teve experincia no planejamento, especificao e execuo de testes manuais, automao de testes, testes de desempenho e testes de segurana. Possui trs anos de experincia lecionando no ensino superior. Freqentemente ministra treinamentos e/ou palestras relacionados a testes de software j tendo, inclusive, ministrado a disciplina de Testes de Software na PUC Minas. Possui as certificaes CQA Certified Quality Assurance da IBM e CTFL do BSTQB. Atualmente Gerente de testes no SYNERGIA - DCC/UFMG.
segurana dos softwares de senvolvidos atualmente est se tornando um ponto cada vez mais importante a ser testado. Entretan to, testar a segurana de um software algo muito complexo e custoso. Por tanto, os testes de segurana devem ser
focados nos pontos onde a segurana tem uma probabilidade maior de ser comprometida. Nesse artigo ser demonstrada a im portncia de se realizar testes de segu rana em aplicaes web. Sero apresen tadas quais as falhas de segurana so
Engenharia de Software Magazine - Testes de segurana
VALID Ao, VERIF IC Ao & TE S TE
mais comuns em aplicaes web e algumas ferramentas livres que auxiliam nesses testes.
Testes de segurana
No incio da internet existiam apenas sites estticos. Os sites existentes desempenhavam papel apenas de reposit rios de informaes que continham documentos estticos, e os navegadores web foram criados como uma forma de visualizao desses documentos. A maioria dos sites no autenticava usurios porque no havia necessidade j que a mesma informao era exibida para todos os usurios. Se um invasor comprometesse um servidor, ele normalmente no ganhava acesso a nenhuma informao confidencial, visto que toda a informao j estava liberada para o pblico. No mximo, o invasor poderia escrever algum contedo no site ou utilizar o servidor como repositrio de arquivos. Hoje em dia a internet completamente diferente. A maioria dos web sites so aplicaes complexas e possuem um fluxo de informaes nos dois sentidos (servidor e navegador). Elas suportam login, transaes financeiras e acesso a dados pessoais. O contedo exibido para os usu rios geralmente gerado dinamicamente e muitas vezes especfico para cada usurio. Muitos dos dados proces sados, e exibidos, so pessoais. A segurana , portanto, uma grande questo: ningum utilizar uma aplicao web caso acredite que suas informaes confidenciais sero exibidas para terceiros. Atualmente, para as aplicaes web proverem as funcio nalidades mais bsicas, muitas vezes necessrio acessar sistemas internos da empresa e esses sistemas, muitas vezes, contm dados sigilosos. Uma falha em uma dessas aplicaes web pode comprometer todo o servidor. Um invasor que conseguir comprometer a aplicao web pode roubar informaes pessoais e com isso realizar aes maliciosas contra os outros usurios. Tanto as empresas desenvolvedoras de software quanto os usurios finais tm grande interesse na segurana das aplicaes: as empresas, devido necessidade de aumentar o faturamento com comrcio na internet, os usurios por que eles tero mais segurana para utilizar aplicativos.
Gartner, em que se estima que os ataques contra os sistemas do departamento de defesa dos EUA foram 60% maiores em 2009, se comparados com o ano anterior. Alm do aumento do nmero de invases que podem ser visualizados na Figura 1, um estudo publicado pela Univer sidade de Michigan, revelou que mais de 75% dos sites de bancos, que so os que mais investem em segurana, no so inteiramente seguros como dizem ser e esto sujeitos a falhas de segurana. Outro estudo, do instituto de pesquisa WhiteHat Security, publicou dados demonstrando que cerca de 64% dos 1364 sites de companhias avaliados possuam pelo menos uma falha de segurana crtica.
Figura 1. Total de incidentes reportados ao CERT.br
Por que fazer testes de segurana?

Apesar de recentemente ter havido uma aumento da pre ocupao com segurana, notcias de invases continuam no noticirio e o nmero de incidentes de segurana tem aumentado ano a ano. Segundo dados divulgados pelo Centro de Estudos, Res posta e Tratamento de Incidentes de Segurana no Brasil (CERT.br), e que podem ser visualizados na Figura 1, em 2009 foram registradas 358.343 notificaes de incidentes de segurana. Isso representa um aumento de 61% em relao a 2008 e de 11530% em relao ao nmero de inci dentes registrados em 1999, primeiro ano da medio. Esses nmeros so coerentes com outro estudo publicado pela
Isso muito crtico para as empresas j que o aumento do faturamento das empresas que comercializam produtos na web est diretamente ligado sua reputao. Poucas pessoas gostariam de fazer negcio com um site inseguro e, devido a isso, as organizaes no costumam publicar detalhes sobre a segurana de seus dados, ataques sofridos e vulnerabili dades, com o objetivo de no adquirir uma m reputao. Por isso, os nmeros podem ser ainda mais alarmantes do que os publicados pelo CERT.br. Dentre os diversos fatores que influenciam o aumento do nmero de incidentes de segurana, como a maior popularizao da internet pelo mundo e o surgimento de ferramentas que auxiliam nesses ataques, devese destacar outro fator que contribui para o aumento dos ataques: a evoluo constante da tecnologia utilizada nas aplicaes web. Como a tecnologia utilizada no desenvolvimento de aplicaes web evolui muito rapidamente, as aplicaes web trazem consigo, a todo o momento, uma nova variedade de falhas de segurana. Novos ataques, que antes do desen volvimento da aplicao no eram conhecidos, so criados aps o desenvolvimento e podem ser exploradas at serem corrigidos. Alguns problemas, como a injeo SQL tm diminudo a frequncia de ocorrncia conforme os desenvolvedores se conscientizam deles. Entretanto, a introduo cada vez mais
frequente de novas tecnologias possibilita novas possibilidades de explorao. Existem diversas e excelentes ferramentas proprietrias que auxiliam no teste de segurana de aplicaes web. Con tudo, a maioria dessas ferramentas comerciais possui um custo bastante elevado. Esse artigo se concentrar, ento, na apresentao de extenses para navegadores e ferramentas Open Source que ajudam os testadores e especialistas em segurana nos testes de segurana de aplicaes web.
Principais falhas e a utilizao de SSL

Conforme pde ser visto na seo anterior, o nmero de incidentes de segurana vem aumentando a cada ano e a maioria dos sites possui problemas de segurana. Em con traste com esses dados, ao consultar a pgina de FAQ de uma aplicao tpica da web, o usurio ser tranquilizado que ela segura pelo fato do site utilizar a tecnologia SSL. Os usurios so frequentemente convidados a verificar o certificado do site, comprovar os avanados protocolos criptogrficos em uso, e, com isso, levado a confiar que suas informaes pessoais esto em boas mos. Indepen dentemente de estar ou no utilizando SSL, a maioria das aplicaes web ainda contm falhas de segurana, falhas essas que no tm nada a ver com a utilizao ou no de SSL. A utilizao da tecnologia SSL importante porque ela protege a integridade do dado durante a transio entre o navegador do usurio e o servidor web. Entretanto, SSL no ir impedir os ataques que comprometem diretamente os servidores ou os clientes de uma aplicao como ocorre na maioria dos ataques. Segue abaixo algumas falhas que no so resolvidas com a utilizao de SSL e na Figura 2, sua frequncia de ocorrncia segundo STUTTARD: Falha de autenticao: Essa falha ocorre quando as creden ciais de acesso ao site no so protegidas adequadamente; Falha no controle de acesso: Essa falha envolve casos onde a aplicao no consegue proteger o acesso aos seus dados e funcionalidades, permitindo que o invasor veja dados privados de outro usurio e acione comandos aos quais ele no tem acesso; Injeo SQL: Essa falha ocorre quando a aplicao permite que o invasor injete comandos no banco de dados utilizando, para isso, a aplicao; CrossSite Scripting: CrossSite Scripting (XSS) uma falha em que se permite ao atacante inserir cdigo (ex: Java Script ou tags HTML) em pginas Web, visando conseguir informaes de outros usurios ou acessos restritos; Vazamento de informaes: Essa falha ocorre quando as aplicaes divulgam, sem inteno, informaes sobre suas configuraes, processos internos ou privacidade devido a problemas na aplicao. Isso muito crtico, pois a divulgao de informaes sobre a verso do servidor de aplicao ou do banco de dados utilizado, por exemplo, pode indicar ao invasor quais as falhas s quais a aplicao est vulnervel.
O principal problema das aplicaes web que, como a aplicao no tem como garantir quais entradas os clientes iro submeter, podese submeter entradas arbitrrias, mesmo que a aplicao faa tratamento no cliente para evitar isso. Portanto, qualquer aplicao web deve considerar que todos os usurios so poten ciais invasores e devem tomar medidas para evitar que pessoas mal intencionadas utilizem essas entradas para comprometer a aplicao. Esse problema se manifesta de vrias formas: Usurios podem interferir em qualquer conjunto de dados transmitidos entre o cliente e o servidor, incluindo requisies, cookies e cabealhos HTTP. Qualquer controle implementado do lado do cliente, como validaes de entradas podem ser fa cilmente burladas; As requisies podem ser enviadas pelos usurios em qualquer sequncia. Qualquer suposio relativa ordem como as requisi es sero feitas pelos usurios pode ser burlada; No se deve supor que os usurios utilizaro o navegador para interagir com a aplicao. Existem vrias ferramentas que permi tem a interao com um servidor, sem a utilizao do navegador. Essas ferramentas permitem que se faam requisies que no seriam possveis caso fosse utilizado um navegador comum.
Figura 2. Frequncia de incidencia das principais falhas na Web
Existem ferramentas que testam automaticamente um conjunto grande de entradas visando encontrar falhas. Alguns exemplos de entradas enviadas so: Modificao de um valor transmitido em um campo escondido do HTML (hidden); Modificao de um token da sesso, para roubar a sesso de outro usurio autenticado; Remoo de certos parmetros que so normalmente submeti dos, para explorar falhas de lgica na aplicao; Alterar alguma entrada para tentar fazer um acesso ao banco de dados. Nas prximas sees sero apresentadas ferramentas livres e que podem ser utilizadas para realizar os testes de segurana em aplicaes web.
Montando seu ambiente de testes com ferramentas livres

Alguns ataques a aplicaes web podem ser executadas usan do apenas um navegador web padro. Entretanto, para que o
teste de segurana seja mais efetivo, exigese a utilizao de ferramentas adicionais para que seja possvel encontrar mais falhas de segurana. Mui tas dessas ferramentas funcionam em conjunto com o navegador, quer como extenses que modi ficam a sua funcionalidade, ou como ferramentas externas que funcionam ao lado do navegador e modificam sua interao com o aplicativo alvo. Para testar uma aplicao procurando por falhas de segurana necessrio ter domnio sobre essas ferramentas. Nas prximas sesses, sero citadas algumas extenses para o Firefox e ferramentas livres utilizadas para auxiliar o testador durante os testes de segurana.
convidado a encontrla e, caso o testador no a encontre, o WebGoat permite a solicitao de dicas para a identificao da falha. Caso no se consiga identificar a falha, aps dicas de como encontrla, possvel ainda consultar uma descrio da soluo. Se mesmo assim o testador no entender como encontrar a falha, podese consultar vdeos demonstrando passo a passo como identificla. O WebGoat uma aplicao de extrema necessidade, principalmente para iniciantes nos testes de segurana e que querem aprender a realizar alguns testes. Os exemplos de utilizao das ferramentas e extenses para navegadores apresentadas nesse artigo foram feitos utilizandose o WebGoat como aplicao alvo.
Navegadores
Um navegador web no exatamente uma ferramenta hacker. Porm, a escolha pelo navegador utilizado pode auxililo no teste a uma aplicao web. O Firefox , hoje, o segundo navegador mais utilizado do mundo compreendendo, segundo alguns estudos, cerca de 25% do mercado e possui diversas extenses que auxiliam o testador no teste de segurana de uma aplicao web. Abaixo iremos descrever algumas das extenses que podem auxiliar nessa tarefa. FoxyProxy: Permite o gerenciamento das configuraes de proxy do navegador, possibilitando a troca rpida entre os proxies utilizados, realizao de configuraes de Proxies diferentes para URLs diferentes. Como os Proxies so ferramentas essenciais em testes de aplicaes web,
Ferramentas necessrias para a realizao dos testes

A primeira ferramenta que o testador deve possuir para realizar os testes, alm do prprio navegador, um Proxy interceptador. Um Proxy interceptador permite visualizar e modificar todas as mensagens HTTP que passam entre o navegador e a aplicao. Atualmente, alm dos Proxies bsicos existem sutes que se tornaram muito poderosas por possurem, alm dos Proxies, um conjunto de outras funes projetadas para ajudlo no ataque a aplicaes web. A segunda categoria principal de ferramenta conhecida como Web Spider. Essas ferramentas agem solicitando pginas web, analisando os links para outras pginas, e em seguida, solicitando essas pginas. Eles continuam recursivamente at que todo o contedo de um site seja descoberto. A terceira categoria principal de ferramenta o Scanner de aplicao web. Essas ferramentas so concebidas para automatizar muitas das tarefas envolvidas no ataque a uma aplicao web reali zando desde o mapeamento inicial at a sondagem por vulnerabilidades. Essas ferramentas fazem uma busca automtica por toda a aplicao subme tendo dados e analisando as respostas para, com isso, tentar encontrar automaticamente falhas de segurana conhecidas. A quarta categoria principal de ferramenta ne cessria, principalmente quando o testador quer realizar alguns testes em seu ambiente, uma aplicao cheia de falhas onde ele possa fazer alguns experimentos. Essa aplicao existe. O WebGoat uma aplicao Web Open Source do projeto OWASP. Nessa aplicao as falhas foram inseridas propositalmente e seu principal objetivo ser um laboratrio onde o testador aprende, na prtica, as principais vulnerabilidades encontra das em aplicaes Web. Para cada falha, o usurio
visto que eles permitem interceptar todas as requisies e respostas e modificlas, e, alm disso, muitas vezes utiliza se mais de um Proxy durante o teste, essa extenso impor tante para agilizar esse processo de seleo e modificao do Proxy utilizado; Tamper Data: extenso do Firefox que permite interceptar e modificar as requisies HTTP enviadas e recebidas pelo navegador; LiveHTTPHeaders: uma extenso do Firefox que permite visualizar os cabealhos HTTP enviados ao servidor web ou os que so recebidos do servidor; Edit Cookies: permite adicionar e modificar valores e atributos dos cookies; CookieWatcher: permite que o valor do cookie seja moni torado na barra de status. Muitas vezes possvel modificar o seu navegador para ajudlo no ataque de uma aplicao: Se a aplicao no utilizar cookies para armazenar tokens de sesso, podese utilizar vrios processos do mesmo na vegador, cada um com uma sesso diferente sobre o pedido. Por exemplo, quando estiver testando o controle de acesso, podese utilizar uma instncia do navegador logada com um usurio com mais privilgio e outra logada com uma sesso com um usurio com poucos previlgios e assim, testar rapi damentte a aplicao com poucos pedidos de visitas; possvel limpar os dados que um navegador guarda sobre alguma aplicao (principalmente dentro de cookies e cache) de forma a iniciar novamente com o pedido como um novo usurio; Podese acionar o boto direito do mouse em um link e abrilo em uma nova janela ou guia para explorar uma fun cionalidade que chama a ateno do invasor por aparentar apresentar falhas de segurana, mantendo a sua posio anterior para continuar trabalhando de forma sistemtica atravs da aplicao. Com essas extenses, os testes de segurana podero ser realizados com muito mais facilidade. Apesar disso, para realizar testes mais completos, necessria a utilizao de mais ferramentas, que sero descritas nas prximas sesses.
Como essas ferramentas funcionam

Cada sute de testes integrados contm vrias ferramentas complementares que compartilham informaes sobre a aplicao alvo. Normalmente, o testador interage com a aplicao de uma forma normal atravs do seu navegador, e as ferramentas de acompanhamento monitoram os re sultados dos pedidos e das respostas, armazenando todas as informaes pertinentes sobre a aplicao de destino e provendo inmeras funes teis. Cada sute dispe dos seguintes componentes principais: Um Proxy Interceptador; Uma aplicao spider; Vrias funes partilhadas e utilitrias.
Proxy Interceptador
O Proxy Interceptador fica no centro da sute de ferramen tas e o nico componente realmente essencial na sute. Para utilizlo, devese configurar o navegador para usar o Proxy escolhido como servidor Proxy em uma porta local na prpria mquina. O Proxy , ento, configurado para escutar essa porta e receber todos os pedidos emitidos pelo navegador e repasslo ao destino. Como ele tem acesso aos dois sentidos da mensagem entre o navegador e o servidor web e age como um interceptador, ele consegue barrar cada mensagem para reviso e modificao pelo usurio, para s ento encaminhla ao destino.
Outras caractersticas comuns presentes nessas sutes

Alm de sua funo principal de permitir a interceptao e alterao de requisies e respostas, os Proxies possuem uma riqueza de outros recursos para ajudar nos testes de segurana de aplicaes web. Entre os recursos, incluem se os seguintes: permitida a criao de regras de interceptao, possibilitando que as mensagens sejam intercepta das para reviso ou silenciosamente retransmitidas, com base em critrios definidos pelo testador como host de destino, url, mtodo, tipo de recurso, cdigo de resposta, ou o aparecimento de determinadas ex presses, conforme pode ser visualizado na Figura 3. Em uma aplicao tpica, muitas requisies e respostas so de pouco interesse para o testador, e esta funo permite configurar o Proxy para interceptar apenas as mensagens que lhe so interessantes; Um histrico detalhado de todas as requisies e respos tas, o que permite que mensagens antigas sejam revistas e analisadas posteriormente; Regras para a modificao dinmica do contedo das requisies e respostas. Esta funo pode ser til em inmeras situaes, por exemplo, para reescrever o valor de um cookie ou outro parmetro em todos os pedidos visando remover diretivas de cache, para simular um navegador especfico modificando o cabealho e assim sucessivamente;
Outras ferramentas teis

Aps o navegador web, o item mais til no seu conjunto de ferramentas ao atacar uma aplicao web um Proxy Interceptador. No comeo da Web os Proxies Interceptador eram aplicaes que proviam funcionalidades bsicas. Nos ltimos anos, os Proxies Interceptador expandiramse para um grande nmero de sutes, cada uma contendo muitas ferramentas interconectadas desenvolvidas para auxiliar em todas as tarefas envolvidas no ataque a uma aplicao web. Todas as funcionalidades referentes a Proxies Inter ceptador citadas no restante desse artigo esto presentes no WebScarab, uma ferramenta livre do projeto Owasp.
10
Existem algumas ferramentas que varrem toda a aplicao procurando por falhas conhecidas e, aps a varredura, emitem um relatrio com os pontos suspeitos de possurem falhas de segurana. Os recursos a seguir esto presentes na ferramenta Paros, que permite a execuo de uma varredura na aplicao procura de falhas de segurana: Permite varreduras automatizadas para detectar vulnerabili dades conhecidas. O Paros envia um conjunto de sequncias de ataque e analisa as respostas para identificar vulnerabilidades conhecidas. A Figura 5 mostra o resultado de uma Varredura feita utilizando esta ferramenta. Verifique na figura que possvel identificar a URL onde se suspeita que exista a falha de segurana e os parmetros utilizados pelo Paros.
Figura 3. Tela do WebScarab que permite a configurao das URLs que sero interceptadas
Acesso a funcionalidades de Proxy que permitem que se nave gue no histrico de requisies e respostas, possibilitando, com isso, que o testador identifique requisies suspeitas de possurem problemas de segurana e reemita o pedido, quantas vezes for preciso e, caso necessrio, faa modificaes que permitam iden tificar possveis falhas, conforme pode ser visto na Figura 4;
Figura 5. Resultado de um scan na aplicao WebGoat realizado pelo Paros
Figura 4. O WebScarab permite a visualizao do Histrico das requisies realizadas
Funcionalidades para o mapeamento completo de toda a apli cao, funcionalidades essas conhecidas como Web Spiders. Os Web Spiders agem solicitando pginas web, analisando os links para outras pginas, e em seguida, solicitando essas pginas. Eles continuam recursivamente at que todo o contedo de um site seja descoberto; Funes que permitem revelar campos e comandos escondidos.
Permite o controle das sequncias de ataque e formas de incorporlas s requisies. Possui ainda um histrico de todas as requisies permitindo a reviso dos resultados para a identificao de todas as respostas incomuns ou anmalas que merecem maior investigao; Funes para extrao de dados teis a partir das respostas do aplicativo por exemplo, analisando os campos de usurio e senha em uma pgina de detalhes. Isso pode ser til quando voc est explorando vulnerabilidades diversas, incluindo falhas na sesso e controles de acesso; Funes para analisar cookies e outros tokens para qualquer sequncia. Uma ressalva que, todas as possveis falhas apontadas pelo Paros devem ser investigadas, pois aps uma anlise, descobrese que muitas delas no so falhas. Esse excesso de falsos positivos acaba fazendo com que o testador perca muito tempo analisando os possveis defeitos. O autor deste artigo desconhece, at a presente data, uma ferramenta livre que faa a varredura de uma aplicao, procurando por falhas de segurana conhecidas, e que seja to boa quanto alguns scanners proprietrios disponveis no mercado. Ape sar de falsos positivos ocorrerem tambm nas ferramentas comerciais, ocorrem em uma escala bem menor do que no
Scanners de aplicao
Embora seja possvel realizar um teste bemsucedido usando apenas tcnicas manuais, para se tornar um bom testador, necessrio fazer uso de automao, para aumentar a rapidez e eficcia dos testes.
11
Paros, ocasionando uma economia de tempo do testador na anlise de falhas. Alm disso, segundo SUTO, autor do artigo Analyzing the Accuracy and Time Costs of Web Application Security Scanners, mesmo as ferramentas proprietrias chegam a no detectar, dependendo da ferramenta utilizada, 66% das falhas presentes em um site, o que faz com que no se possa confiar cegamente nessas ferra mentas e torna importante o papel do testador na identificao desses defeitos no identificados pelos Web Scanners.
Funcionalidades adicionais
Alm de suas ferramentas principais, as sutes de teste de segurana normalmente fornecem uma vasta gama de outras funcionalidades que visam atender a necessidades especficas que surgem quando se est testando a segurana de uma apli cao web, e que permitam a outras ferramentas trabalharem em situaes inusitadas. Os recursos abaixo esto disponveis no WebScarab: Anlise da estrutura de mensagens HTTP, incluindo anlise e modificao de cabealhos e parmetros do pedido, conforme pode ser visto na Figura 7;
Requisies manuais
As sutes livres, como o WebScarab, permitem ainda facilida des para que o usurio emita uma nica requisio e visualize a sua resposta. Embora simples, esta funo muitas vezes extremamente til quando se est investigando uma possvel vulnerabilidade e, para isso, pode existir a necessidade de ree ditar a mesma requisio manualmente vrias vezes, aprimo rando elementos da requisio para determinar o efeito sobre o comportamento da aplicao. Logicamente, com uma ferramenta com as funes integradas voc pode recuperar rapidamente uma requisio interessante de outro componente utilizado no teste (Proxy, spider, etc.) para investigao manual. Veja a Figura 6 para um exemplo de uma tela do WebScarab onde possvel realizar a modificao de uma requisio.
Figura 7. O WebScarab permite a interceptao e modificao de pedidos e respostas
Figura 6. Reedio manual de uma requisio
O WebScarab possui as seguintes funcionalidades relacionadas ao envio de requisies manuais: Integrao com outros componentes do conjunto, e a pos sibilidade de submeter qualquer requisio de e para outros componentes para investigao posterior; Histrico de todos os pedidos e respostas, mantendo um re gistro completo de todas as requisies manuais para reviso posterior, e possibilitando que uma requisio modificada seja recuperada para anlise posterior.
Renderizao de contedo das respostas HTML, sendo pos svel visualizar a pgina da mesma forma que ela ser exibida no navegador web (Aba HTML da Figura 7); Capacidade de exibir e editar mensagens de texto e de forma hexadecimal (Aba Hex da Figura 7); Funes de pesquisa por todas as requisies e respostas; Atualizao automtica do cabealho HTTP, para mant lo consistente com qualquer edio manual do contedo da mensagem; Codificadores e decodificadores para vrios sistemas, per mitindo a rpida anlise dos dados da aplicao em cookies e outros parmetros; O suporte para utilizao de outros Proxies, que no so os integrados na aplicao, permitindolhe encadear ferramentas diferentes ou acessar um aplicativo atravs do Proxy usado por sua organizao ou ISP; Ferramenta de apoio a mtodos de autenticao de HTTP, permitindolhe utilizar todos os recursos da sute em ambien tes onde estes so utilizados, tais como LANs corporativas; Suporte para os certificados de cliente SSL, permitindolhe testar aplicaes que utilizam essa tecnologia; Manipulao das caractersticas do HTTP, como a codificao gzip, codificao de transferncia em partes, e status 100 de respostas provisrias;
12
Extensibilidade, permitindo que a funcionalidade incorpo rada seja alterada e estendida de forma arbitrria por cdigo de terceiros; Salvamento das configuraes utilizadas na ferramenta, permitindo que uma configurao especfica seja reutilizada na prxima execuo da sute; O WebScarab independente de plataforma, permitindo que seja executado em todos os sistemas operacionais populares.
Concluso
Cada uma das ferramentas apresentadas neste artigo possui funcionalidades importantes e que, juntas, permitem ao testa dor a realizao de testes de segurana de forma satisfatria. Todas so eficazes e muito populares entre a comunidade que utiliza softwares livres para testar a segurana de aplicativos na web. Com isso, a escolha de qual sute ser utilizada uma questo de preferncia pessoal. Recomendase que seja feito o download das ferramentas descritas para que o prprio testador escolha qual ferramenta utilizar em seus testes. Entretanto, apesar das ferramentas livres terem evoludo bastante, podese perceber que em relao aos Web Scanners,
as ferramentas livres ainda esto muito distantes de serem to boas quanto as ferramentas comerciais disponveis no mercado, j que, como eles encontram muitos falsos positi vos, acabam desperdiando o tempo do testador na anlise de falhas que no existem. Por fim, pdese perceber que o bom entendimento de como utilizar as ferramentas utilizadas de extrema im portncia para a melhoria da segurana dos Web Sites, visto que mesmo os melhores Web Scanners proprietrios podem no encontrar a maioria dos defeitos de segurana presente em uma aplicao Web.
www.devmedia.com.br/esmag/feedback
Referncias e links STUTTARD, Dafydd, PINTO, Marcus. The Web Application Hackers Handbook: Discovering and Exploiting Security Flaws. Wiley Publishing, 2007. MCGRAW, Gary, Software Security: Building Security In. Addison Wesley Professional, 2006. Testing Experience: The Magazine for Professional Testers, Security Testing, Junho de 2009. SUTO, Larry. Analyzing the Accuracy and Time Costs of Web Application Security Scanners. So Francisco, Fevereiro de 2010. Widespread security flaws revealed in online banks http://www.ur.umich.edu/0708/Jul28_08/02.php WhiteHat: Web Security Vulnerabilities Found on Most Sites http://www.eweek.com/c/a/Security/WhiteHat-Web-Security-Vulnerabilites-Found-on-MostSites707138 WebGoat http://www.owasp.org/index.php/Category:OWASP_WebGoat_Project Paros - for web application security assessment http://www.parosproxy.org/index.shtml Projeto Owasp http://www.owasp.org WebScarab http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project
edio ta
A Engenharia de Software Magazine tem que ser feita ao seu gosto. Para isso, precisamos saber o que voc, leitor, acha da revista! D seu voto sobre este artigo, atravs do link:
D s
D seu feedback sobre esta edio!
Feedback eu
sobre e s
13
Engenharia
Gerncia de Configurao
Definies Iniciais, Ferramentas e Processo
De que se trata o artigo? Alberto Boller Filho
alberto.boller@gmail.com
Marcelo Nascimento Costa

mnc@kalisoftware.com
Formado em Tecnlogo Anlise de Sistemas pelo Centro Universitrio Instituto Metodista Bennet. Possui mais de 30 anos de experincia em informtica. Possui especializao em administrao de redes Linux Conectiva, segurana de redes Linux Conectiva, administrao de redes Windows NT e Windows Server 2003, programao de aplicaes cliente servidor avanada em Delphi, programao RPGII, programao COBOL, System Administrator NOTES, Application Development NOTES. Atualmente Gerente de informtica na clnica de diagnstico por imagens CEPEM Centro de Estudos e Pesquisa da Mulher .
Mestre em Engenharia de Sistemas e Computao pela COPPE/UFRJ (avaliada como a melhor psgraduao em computao do pas). Bacharel em Cincia da Computao pela UFPA. Professor dos cursos de graduao em computao e administrao do Instituto Metodista Bennett. Autor de diversos artigos cientficos sobre Engenharia de Software publicados em revistas e conferncias renomadas, dentro e fora do pas.
Neste artigo sero mostrados inicialmente aspectos relevantes da gerncia de configurao. Na segunda parte do artigo, ser apresentada a aplicao da gerncia de configurao dentro dos principais modelos de maturidade e as vantagens de se utilizar tais ferramentas, atravs de um estudo de caso de implementao em uma empresa hipottica.
Para que serve?

Este trabalho tem como intuito servir como um material de apoio para aqueles que desejam implementar gerncia de configurao em uma organizao desenvolvedora de software, usando como ferramentas de controle de mudanas e controle de verses, o Mantis e o Subversion respectivamente.
Marcos Kalinowski
mk@kalisoftware.com
Rodrigo Oliveira Spnola

rodrigo@sqlmagazine.com.br
Doutorando e Mestre em Engenharia de Software pela COPPE/UFRJ (avaliada como a melhor psgraduao em computao do pas). Criador do projeto e editor chefe da revista Engenharia de Software Magazine. Autor de diversos artigos cientficos sobre Engenharia de Software publicados em revistas e conferncias renomadas, dentro e fora do pas. Experincia de participao em diversos projetos de consultoria para diferentes empresas tendo atuado com gerncia de projetos, requisitos e testes de software. Implementador certificado do MPS.BR, tendo tambm experincia atuando junto a empresas certificadas CMMI.
Doutorando e Mestre em Engenharia de Software pela COPPE/UFRJ (avaliada como a melhor psgraduao em computao do pas), com nfase em Validao, Verificao e Testes de Software e Melhoria de Processos. Bacharel em Cincia da Computao pela UFRJ. Professor do curso de psgraduao e-IS Expert da UFRJ e Coordenador do curso de Engenharia da Computao da UVA RJ.

Para qualquer empresa de desenvolvimento de software que tenham interesse em aumentar o controle e confiabilidade nos artefatos gerados pela equipe de desenvolvimento ao longo de um processo de desenvolvimento de software.
om um mercado cada vez mais exigente, as empresas que fabri cam software tem revisto seus processos de construo com o intuito de aumentar a qualidade de seus produtos e tambm sua produtividade. Diversas metodologias de desenvolvimento de
software voltadas para o controle tem sido elaboradas uma vez que um pro jeto de software, ao longo do seu ciclo de vida, tem uma grande quantidade
14
Engenharia de Software Magazine - Gerncia de Configurao
PRojETo
de itens de informao tais como documentos, cdigofonte, dados, manuais e outros, produzidos e at modificados, pelos mais diversos motivos. Para que a qualidade do software seja garantida, em fun o destas modificaes, necessrio que se faa uso da Gerncia de Configurao de Software (GCS). A Gerncia de Configurao de Software tem como objetivo gerenciar e controlar a evoluo de um software atravs do controle formal de verso e solicitao de mudanas. uma forma sistemtica e organizada de controlar as modificaes de um software tornando possvel manter sua integridade ao longo do tempo. A quantidade de itens que podem estar sob controle da GCS e os nveis de controle exigidos sobre estes itens ir variar de empresa para empresa ou mesmo de projeto para projeto. Sendo assim, o uso desta prtica em conformidade com modelos de maturidade mantidos por en tidades que possuam credibilidade nacional e internacional, e tambm o uso de ferramentas adequadas que garantam a qualidade deste processo, fundamental para que uma empresa obtenha xito e reconhecimento. Para empresas de grande porte, isto no chega a ser um grande problema pois normalmente se dispem de capital e pessoal qualificado para manter tais prticas. Entretanto, quando voltamos a olhar para as pequenas empresas, o cenrio exatamente o oposto. As dificuldades e o custo envolvidos para se adotar um modelo de gesto, treinar pes soal, adquirir ferramentas que apiem a pratica de GCS, e ainda obter certificao em um determinado nvel de modelo de maturidade, de uma entidade reconhecida, pode levar uma pequena empresa a desistir rapidamente da adoo de um processo de GCS com qualidade, e como conseqncia, perder em competitividade para outras empresas. Este artigo foi feito com o foco voltado para estas empresas. Neste contexto, o objetivo deste artigo mostrar uma solu o especifica, de boa qualidade e baixo custo, que atenda as exigncias dos modelos de maturidade e que possa ser utilizada para implementar a Gerncia de Configurao de Software em pequenas empresas. Sob esta perspectiva, ser apresentada uma reviso bi bliogrfica sobre GCS, sua aplicao dentro dos modelos de maturidade CMMI e MPS e uma soluo especifica uti lizando as ferramentas Mantis e Subversion, atravs de um estudo de caso de uma empresa fictcia de pequeno porte que atenda as exigncias do modelo de maturidade MPS, e que possa servir como alternativa para empresas reais que estejam buscando a implementao do processo de GCS. Sero apresentados tambm os aspectos de instalao e configurao das ferramentas, a fim de facilitar queles que forem utilizlas.
A primeira lei da engenharia de sistemas diz: Independente de onde voc est no ciclo de vida de um sistema, o sistema vai se modificar e o desejo de modific-lo vai persistir ao longo de todo o ciclo de vida. Bersoff (1980 apud Pressman, 2006, p. 600) Produtos de software normalmente envolvem quantidades significativas de artefatos que so manuseados por diversas pessoas envolvidas em seu projeto. Assim sendo, a possibilidade de introduo de defeitos au menta medida que alteraes so efetuadas sem uma analise antes da sua execuo, sem o registro formal antes da sua imple mentao, sem a comunicao s pessoas que necessitam saber delas ou ainda sem um controle que vise melhorar a qualidade e reduzir os erros. Existem quatro fontes fundamentais de modificaes de software: Novas condies de negcio e/ou mercado, modificam regras de negcio; Novas necessidades do cliente exigem modificaes de funcionalidades; Reorganizao e/ou crescimento/diminuio do negcio; Restries de oramento ou cronograma, causando redefinio do sistema; Conceitos e Terminologias A Gerncia de Configurao de Software (GCS) ou Software Configuration Management (SCM) uma atividade abrangente que ocorre ao longo de todo o ciclo de vida de um software e que gerencia e controla sua evoluo, atravs do controle de verses e solicitaes de mudanas, permitindo que os diver sos envolvidos na sua criao e manuteno tenham acesso ao histrico destas modificaes, fornecendolhes subsdios para o entendimento do sistema na sua forma atual, e tambm nas suas formas anteriores. As atividades de GCS incluem: Identificar modificaes; Controlar modificaes; Garantir a implementao adequada das modificaes; Relatar as modificaes a outros que possam ter interesse. Segundo Pressman (2006, p. 599), diferentemente da ativida de de suporte de software, que ocorre depois que o software foi entregue ao cliente, a GCS um conjunto de atividades de acompanhamento e controle que comeam quando o projeto de engenharia de software tem incio e s terminam quando o software retirado de operao. A Gerncia de Configurao de Software tem especial impor tncia na garantia da qualidade do software e no apoio a gesto de projetos, sendo imprescindvel sua aplicao nas empresas que desejam obter a certificao do Capability Maturity Model Integra tion (CMMI) nvel 2 ou na obteno da certificao do modelo para Melhoria de Processo do Software Brasileiro (MPSBR) nvel F. Segundo Pressman (2006 p. 606), o processo de gesto de configurao de software define uma srie de tarefas que tm quatro objetivos principais:
Gerncia de Configurao
Ao longo do ciclo de vida de um software, diversas modifi caes podem ocorrer em seu projeto original. Os motivos e origens destas modificaes podem ser os mais variados possveis e podem ocorrer em qualquer poca.
15
Identificar todos os itens de configurao; Gerir modificaes em um ou mais destes itens; Facilitar a construo de diferentes verses de um mesmo produto; Garantir que a qualidade do software seja mantida a medida que a configurao evolui ao longo do tempo. Para podermos entender como estas tarefas so executadas, devemos conhecer alguns conceitos que so fundamentais para a aplicao de GCS. Configurao de Software Diversos elementos so gerados como produto de um pro cesso de software. Estes elementos podem ser: Programas de computador (tanto na forma de cdigo fonte como executvel); Documentos que podem descrever programas, procedi mentos regras de negcio etc. (Documentao tcnica e de usurio final); Estrutura de dados que podem estar contidos em programas ou externos a ele; A este conjunto de elementos, que compreende toda a in formao produzida no processo de software, chamamos de Configurao de Software. Itens de Configurao de Software ICS Segundo Molinari (2007 p. 44), um item de configurao o menor item de controle num processo de GCS. Um item de configurao de Software (ICS) ou Software Con figuration Item (SCI) cada elemento criado durante o processo de engenharia de software, ou que para este processo seja necessrio. Pode ser um arquivo, uma aplicao corporativa, uma parte de um documento, uma seqncia de casos de teste, um hardware ou um componente de programa. Alm dos ICSs gerados no processo de engenharia de software, tambm podero ser considerados como ICSs ferramentas de software como editores, compiladores, navegadores e outras ferramentas que forem necessrias correta gerao do software. Os ICSs so identificados de maneira nica e podem estar relacionados a outros ICSs e sua evoluo passvel de ras treamento. O controle da Gerncia de Configurao ser feito sobre estes itens e sero mantidas todas as informaes a seu respeito. Diversas verses de um mesmo ICS podem existir como produto das modificaes efetuadas no diaadia. Molinari (2007 p. 44) faz uma analogia interessante ao con ceito de classes em orientao a objetos (OO) quando diz que o item est para uma classe em OO assim como as verses deste item esto para as instncias da classe em questo conforme mostrado na Figura 1. Repositrio Segundo Forte (1989 apud Pressman, 2006, p. 604), o repo sitrio o conjunto de mecanismos e estruturas que per mite a uma equipe de software gerir modificao de modo
efetivo. Fornece as funes bvias de um sistema de gesto de banco de dados, mas, alm disso executa ou propicia as seguintes funes: Integridade de dados Valida entradas no repositrio, garante consistncia entre os ICSs relacionados, executa mo dificaes em cascata quando uma modificao em um objeto exige modificaes em objetos a ele relacionados; Compartilhamento de informaes Fornece mecanismo para compartilhar a informao entre vrios desenvolvedores e ferramentas, controla o acesso aos ICSs por diferentes usurios atravs de poltica de bloqueio e desbloqueio de modo que as modificaes no sejam sobrepostas umas as outras; Integrao de ferramenta Prov uma estrutura de dados que permite acesso vrias ferramentas de engenharia de software; Integrao de dados Fornece funes de banco de dados que permitem que vrias tarefas de GCS sejam executadas em um ou mais ICSs; Imposio de metodologia Define um modelo entidade relacionamento que implica um modelo de processo especifico de engenharia de software. O relacionamento entre objetos definem um conjunto de passos a ser seguido para construir o contedo do repositrio; Padronizao de documentao Normalizao para a criao de documentos de engenharia de software.
Figura 1. Classes e instncias de um item de configurao
Um repositrio tem que ser capaz de manter ICSs relaciona dos a diversas verses do software e ainda fornecer mecanis mos para montar esses ICSs em uma configurao especifica da verso, garantindo assim a gesto efetiva das entregas do produto e permitindo aos desenvolvedores voltar a verses anteriores. Precisa ser capaz de controlar variados tipos de ICSs incluindo textos, grficos, mapas de bits e outros mais complexos. Alm disso, o repositrio deve ser capaz de guardar informa es sobre baselines e pistas de auditoria com informaes sobre quando, por que, e por quem as modificaes foram feitas. Estas informaes so chamadas de metadados, e so definidas em um metamodelo que determina como as informaes so armazenadas no repositrio, como ter acesso a elas, como podem ser vistas pelos engenheiros de software, e como manter a sua integridade e segurana. Alm de manter as informaes sobre os ICSs, o repositrio deve ser capaz de armazenlos fisicamente em um esquema de bibliotecas.
16
PRojETo
Os ICSs so retirados e inseridos nos repositrios, atravs das seguintes operaes: LOCK: Garante que apenas um usurio detm o acesso para alterar um determinado ICS. Apesar de resolver o problema de atualizao simultnea, o lock serializa o trabalho dos desenvolvedores. CHECK-OUT: Recupera a ltima verso de um item de configurao guardado no repositrio, copiandoo para a rea de trabalho do desenvolvedor. CHECK-IN: Insere ou atualiza um item de configurao no repositrio, incrementando a verso do ICS, e fazendo o registro das informaes de mudana. Identificao de ICSs A identificao dos ICs uma rea de extrema importncia dentro da Gerncia de Configurao de Software. Sem uma identificao correta de um item, impossvel gerenciar este processo. Cada ICS deve ser identificado atravs de caractersticas distintas que o caracterizam unicamente. Estas caractersticas podem ser um nome, uma descrio, uma lista de recursos etc. necessrio que cada organizao defina suas convenes de identificao. Baseline Um baseline pode ser descrito como a situao de uma cole o de ICSs similares em um momento especifico do ciclo de vida de um software que foram aprovados e armazenados em uma biblioteca controlada. Pode ser descrito tambm como a conexo de um item de configurao com um determinado marco no projeto (milestone). Um baseline pode ser visto como um conjunto de itens de configurao identificados e liberados para uso, independente de suas verses. importante identificar e agrupar estes ICSs dentro dos baselines apropriados pois desta forma, criase uma estrutura que facilita o rastreamento de mudanas estes ICSs. Em cada fase do processo de desenvolvimento, um conjunto bem definido de itens de configurao deve ser estabelecido. Tal conjunto representa um estgio do desenvolvimento, o qual passvel de modificaes apenas mediante um mecanismo formal de alteraes. A este conjunto dado o nome de base lines, ou configuraes base do sistema. Em princpio, baselines poderiam ser estabelecidas em qual quer ponto do desenvolvimento. Entretanto, a grande vanta gem do conceito est em se fazer coincidir o estabelecimento de baselines com os finais de fase do ciclo de vida do produto. O desenvolvimento com configuraes base pode, ento, ser resumido nos seguintes pontos: Caracterizao do ciclo de vida, identificandose as fases pelas quais o desenvolvimento do software ir passar; Definio do conjunto de baselines, estabelecendose quais sero os ICSs que a iro compor; Estabelecer o marco o qual a baseline ir representar. Uma nova baseline estabelecida no final de cada fase do ciclo de vida do software;
Durante cada fase, a modificao de uma configuraobase somente pode ser feita de forma controlada, mediante um processo bem definido; Ao ser estabelecida, cada baseline incorpora integralmente a anterior. O estabelecimento de cada baseline somente realizado aps ser aprovada por procedimentos de consistncia interna, verificao e validao; Na Figura 2 vemos uma representao de baselines adaptada de Molinari (2007, p 56).
Figura 2. Entendendo um baseline
Controle de Verso Segundo Pressman (2006, p. 608), controle de verses combina procedimentos e ferramentas para gerir diferentes verses de objetos de configurao que so criados durante o processo de software. Um sistema de controle de verso implementa ou est diretamente integrado com quatro ca pacidades principais: Um banco de dados de projeto (repositrio) que guarda todos os objetos de configurao relevantes; Uma capacidade de gesto de verso que guarda todas as verses de um objeto de configurao; Uma facilidade de construir que permite ao engenheiro de software coletar todos os objetos de configurao relevantes e construir uma verso especifica do software; Capacidade de acompanhamento de tpicos (tambm cha mado de acompanhamento de bugs). Segundo Molinari (2007, p. 168), alguns colocam que a prin cipal misso de um sistema de controle de verses permitir a edio colaborativa e o compartilhamento de dados, outros dizem que o sistema de controle de verses rastreia e controla todos os artefatos do projeto e desse modo consegue coorde nar o trabalho paralelo de desenvolvedores. Ainda segundo Molinari (2007, p.168), independente do que cada um pensa sobre controle de verses, algumas das suas caractersticas perceptveis so: Mantm e disponibiliza cada verso j produzida de cada item do projeto; Possui mecanismos para gerenciar diferentes ramos de desenvolvimento possibilitando a existncia de diferentes verses de maneira simultnea; Estabelece uma poltica de sincronizao de mudanas que evita a sobreposio de mudanas; Fornece um histrico completo de alteraes sobre cada item do projeto.
17
O sistema de controle de verses o responsvel por manter as diversas verses dos ICSs e faz isso atravs de um esquema de arquivos e diretrios presentes no repositrio, registrando no s as alteraes realizadas em cada arquivo mas tambm na estrutura do diretrio em si. O repositrio evolui, junto com o projeto guardando as mlti plas verses que o compe organizadas em forma de revises. As revises so as situaes estticas de todos os arquivos do projeto em um determinado instante de tempo. Em empresas de grande porte, onde existem vrios profissio nais trabalhando concorrentemente nos mesmos arquivos, fazse necessrio uma poltica para ordenar e integrar estas alteraes, a fim de evitar a perda de um trabalho ocasionada quando uma pessoa sobrescreve o trabalho de outra. Os sistemas de controle de verso implementam esta poltica, assegurando que os desenvolvedores no trabalhem diretamen te nos arquivos do repositrio, mas sim em cpias de trabalho destes arquivos em suas prprias mquinas. Isto permite que um desenvolvedor faa seu trabalho de forma independente e sem interferir no trabalho de outro. Aps terminado o trabalho, o arquivo deve ser colocado novamente no repositrio e para que alteraes no sejam inadvertidamente sobrepostas, o sistema de controle de verses pode fazer uso das seguintes polticas de versionamento: Trava-Modifica-Destrava: Apenas uma pessoa por vez detm o direito de alterar um determinado arquivo. O sistema trava o arquivo quando uma pessoa retira uma cpia para manuteno e s libera a cpia para edio outra pessoa, quando a primeira publica sua nova verso. Esta poltica limitada e pode causar problemas administrativos e forar a serializao do trabalho, entretanto, a soluo indicada para organizaes que neces sitam de um alto grau de formalizao. Copia-Modifica-Resolve: No utiliza travamento de arquivos. Nesta poltica, cada desenvolvedor trabalha de forma indepen dente em sua cpia de trabalho, e ao final, as alteraes so mescladas no repositrio, formando a verso final. Esta poltica pode parecer catica, mas na prtica funciona bem, devido ao baixo ndice de conflitos. Os conflitos so causados na maioria das vezes, por falta de comunicao entre os desenvolvedores. Branch Branching (ou ramificao em portugus) uma parte funda mental do controle de verses. O conceito de branching reside em se iniciar uma nova linha de desenvolvimento em paralelo uma principal j existente. Esta tcnica extremamente til em situaes onde temos que fazer grandes alteraes em objetos de configurao e que provavelmente levaro muito tempo, sem contudo afetar a linha principal de manuteno do sistema. Nesta situao, criase uma segunda cpia do objeto em questo e trabalhase em paralelo linha principal. Ao longo do tempo, as manutenes feitas na linha principal podero ser incorporadas na ramificao para que defeitos encontrados na cpia original possam ser conser tados tambm na ramificao. A Figura 3 demonstra como a tcnica de branching ao longo do tempo.
Figura 3. Branch de desenvolvimento
Merge Em projetos onde existe um grande nmero de pessoas en volvidas, comum que elas possuam uma cpia de trabalho da linha principal de desenvolvimento. Neste contexto, o conceito de merge tambm uma parte fundamental do controle de verses. O Merge faz a fuso de dois arquivos que esto sendo alterados simultaneamente por desenvolvedores diferentes garantindo que a verso final contenha todas as alteraes. Quando isso no possvel, mantm apenas a ltima verso guardada e emite uma mensagem de arquivo fora de data para que as diferenas sejam resolvidas com interveno humana. Em alteraes demoradas, onde normalmente utilizada a tcnica de branch, recomendvel que se faam merges, periodicamente entre a linha principal e a ramificao, para que no final no fique invivel fazer o merge devido ao grande nmero de conflitos gerados entre as diferenas das diversas verses. Tags Um outro tipo de controle de verso so as tags. Tags so como fotografias de um projeto, em um determinado instante do tempo. So rtulos associados a um conjunto de arquivos usados para denominar um projeto ou uma nova verso, e que rotulam estes arquivos. As tags nas verses de um conjunto de itens de configurao, existente em diversos sistemas de controle de verses, pode ser utilizado para implementar o conceito de baseline.
Controle de Modificao
Mudanas so inevitveis. Todo produto de software sofre mudanas durante o seu ciclo de vida, seja por erro de cons truo, ou por necessidade de mudanas solicitadas pelos clientes. Em projetos de grande porte, fazer modificaes sem um esquema formal de controle pode levar ao caos. Alguns dos problemas que podem ser causados em projetos devido a mudanas no controladas so: Aumento do custo do projeto; Atrasos em entregas planejadas; Impacto em outros objetos de configurao; Degradao da qualidade do software; Retrabalho. Controle de modificaes podem incluir procedimentos humanos e tambm o uso de ferramentas automatizadas, e
18
PRojETo
seu objetivo controlar estas mudanas e manter informaes sobre os pedidos de mudana, nos produtos e as implementa es realizadas em funo destas mudanas. Informaes do tipo quem, quando, por que e o que foi mu dado, em um item de configurao, so guardadas para que seja possvel haver uma rastreabilidade entre suas verses anteriores e posteriores. O processo de controle de mudanas comea quando o clien te emite um pedido de comunicao. Este pedido passa pela anlise de uma Comisso de Controle de Modificaes (do ingls Change Control Board CCB), que responsvel pela sua aprovao ou no. gerada ento uma ordem de modifi cao de engenharia (Engineering Change Order ECO) pra as modificaes aprovadas. O ICS retirado do repositrio para uma rea de trabalho exclusiva do profissional, que ir executar as mudanas. As mudanas so executadas, as atividades de SQA so aplicadas, e os ICSs modificados so introduzidos no repositrio com os mecanismos adequados de controle de verso. Controles para acesso aos ICSs pelos engenheiros e controles de sincronizao de modificaes paralelas por pessoas diferentes so usados nesta etapa. A Figura 4 esboa o processo formal de controle de modifi caes segundo Pressman (2006, p 610).
Revises tcnicas formais; Auditoria de configurao de software. A reviso tcnica tem como foco a correo tcnica do ICS que foi modificado a partir de uma requisio. Revisores avaliam o ICS para determinar se o mesmo consistente. Revises tcnicas formais normalmente so feitas para todas as modificaes, exceto as mais triviais. A auditoria de configurao de software tem como objetivo complementar a reviso tcnica formal e trata dos seguintes aspectos: Verifica se a modificao tcnica especificada foi realizada e se foi incorporada alguma modificao adicional; Verifica se uma reviso tcnica formal foi feita para avaliar a correo tcnica; Verifica se o processo de software foi seguido; Verifica se constam anotados no ICS modificado, dados de rastreabilidade tais como data da modificao, autor, n de requisio etc.; Verifica se os procedimentos de GCS para registrar e relatar a modificao, foram seguidos; Verifica se todos os ICSs relacionados foram atualizados de forma adequada. Quando a GCS uma atividade formal, a auditoria de confi gurao conduzida pelo grupo responsvel pela garantia de qualidade. A auditoria tambm tem como objetivo garantir que os ICSs corretos foram incorporados em um build especfico e que sua documentao est consistente com a nova verso. Relatrios de Estado Os relatrios de estado uma tarefa de GCS que tem por objetivo responder s seguintes questes: O que aconteceu ? Quem fez ? Quando aconteceu ? O que mais ser afetado ? O relatrio de estado rene informaes de todos os estgios da GCS. Atividades como identificao de ICSs, aprovao de modificaes, resultado das auditorias de configurao so registradas no relatrio de estado. O relatrio de estado deve ser colocado em um banco de dados de maneira que todas as pessoas envolvidas na manuteno de software tenham acesso as informaes ali contidas. O principal objetivo de um relatrio de estado manter a gerncia e os profissionais informados das modificaes sofridas por um software, de vendo ser gerado regularmente.
Figura 4. Processo de controle de modificaes (Pressman, 2006)
Ferramentas de Apoio GCS

Existem diversas ferramentas disponveis no mercado para apoiar a Gerncia de Configurao de Sistemas. As funciona lidades, documentao, o suporte disponvel e popularidade variam bastante. As ferramentas comerciais apresentam maior nmero de funcionalidades mas tem um alto custo. As
Auditoria de Configurao Alm dos controles de identificao, verso e modificao vistos anteriormente, precisamos implementar algum mecanis mo que nos garanta que as modificaes foram feitas de forma adequada. Este mecanismo envolve dois aspectos:
19
ferramentas open source alm de baixo custo, tambm apre sentam vantagens como qualidade e segurana. A Tabela 1 apresenta algumas ferramentas e suas aplicaes.
Tipo de ferramenta Controle de Verso Controle de mudana Integrao (Build) Tabela 1. Ferramentas para GCS CVS SubVersion Mantis Bugzilla Scons Nome
CVS O CVS, ou Concurrent Version System (Sistema de Verses Concorrentes), um sistema de controle de verso open source, que permite que se trabalhe com diversas verses de arquivos organizados em um diretrio e localizados local ou remota mente, mantendose suas verses antigas e os logs de quem e quando manipulou os arquivos. especialmente til para se controlar verses de um software durante seu desenvolvimento, ou para composio colaborativa de um documento. O CVS utiliza uma arquitetura clienteservidor: um servidor armazena as verses atuais do projeto e seu histrico, e os clien tes se conectam a esse servidor para obter uma cpia completa do projeto, trabalhar nessa cpia e ento devolver suas modifica es. Tipicamente, cliente e servidor devem estar conectados por uma rede local de computadores, ou pela internet, mas o cliente e o servidor podem estar na mesma mquina se a configurao do CVS for feita de maneira a dar acesso a verses e histrico do projeto apenas a usurios locais. O CVS possui limitaes tais como: Os arquivos em um repositrio CVS no podem ser re nomeados, eles devem ser explicitamente removidos e re adicionados; O protocolo do CVS no permite que os diretrios sejam mo vidos ou renomeados. Cada arquivo do subdiretrio em questo deve ser individualmente removido e readicionado; No permite lock (permite que dois usurios alterem o mesmo arquivo ao mesmo tempo) e em alguns casos pode ser mais custoso resolver o conflito do que evitar que ele ocorra. Subversion Subversion (tambm conhecido por SVN, o nome da sua ferra menta de linha de comando) um sistema de controle de verso open source projetado especificamente para ser um substituto moderno do CVS, que se considera ter algumas limitaes. O Subversion bem conhecido na comunidade que utiliza cdigo aberto e utilizado em diversos projetos incluindo Apache Software Foundation, KDE, Free Pascal, FreeBSD, GCC Python, Django, Ruby, Mono, SourceForge.net, ExtJS e Tigris.org. O Google Code tambm faz a hospedagem de seus projetos de cdigo aberto utilizando o Subversion. O Subversion tambm adotado no mundo corporativo. Em 2007, a Forrest Research reportou que o Subversion foi
reconhecido como sendo lder isolado na categoria Standalone Software Configuration Manager (SSCM) tendo uma forte atuao na categoria Software Configuration and Change Management (SCCM). O Subversion comeou a ser escrito no ano 2000 como um esforo para criar um sistema de controle de verso o qual operasse de forma parecida com o CVS porm sem os seus problemas, e suprindo as facilidades no existentes no CVS. No ano de 2001, o Subversion j estava suficientemente desenvol vido para ser capaz de hospedar seu prprio cdigo fonte. Algumas de suas facilidades so: Operaes de Commit so atmicas. Interrupes nestas operaes no causam inconsistncias no repositrio; Mudanas de nomes, cpias, e movimentaes de arquivos so guardadas como histrico de revises; Mudanas de nomes em diretrios so guardados tambm como verses. rvores de diretrios inteiras podem ser movi das ou copiadas com rapidez e tem estas operaes guardadas no histrico de revises; Servidor Apache HTTP como servidor de rede; Operaes de Branch e Tag so menos custosas, independente do tamanho do arquivo. O Subversion no faz distino entre Tag, Branch e um diretrio; Permite operaes de lock para arquivos que no podem ser fundidos (sofrer operao de merge). Mantis Mantis um sistema de controle de mudana open source, baseado em Web, bastante popular. Foi escrito em linguagem PHP e trabalha com banco de dados MySQL, MS SQL e Pos tgreSQL e um webserver. Pode ser instalado em Windows, Linux, Mac OS, OS/2 e outros e funciona na maioria dos web browsers como um cliente. Algumas de suas caractersticas so: um software livre (licena GPL); Fcil de instalar; Fcil de avaliar; baseado em Web; Suporta qualquer plataforma que roda PHP; Suporta mltiplos projetos por instancia; Suporte para Projetos, Subprojetos e categorias; Suporte a diferentes nveis de acesso de usurio por projetos; Suporta log de mudanas; Possui diversos relatrios e grficos; Usurios podem monitorar as solicitaes; Envio de notificaes por email; Permite histrico de mudanas; Integrao com SVN e CVS. Bugzzila Bugzilla uma ferramenta baseada em Web e email, que d suporte ao desenvolvimento do projeto Mozilla, rastreando defeitos de software, e servindo tambm como plataforma para solicitaes e controle de mudanas. Como projeto de software livre, mantido por voluntrios, sendo utilizado
20
PRojETo
por diversos outros projetos e empresas. Algumas de suas caractersticas so: Capacidade de pesquisa avanada; Notificaes por email controladas pelas preferncias de usurios; Lista de defeitos em diversos formatos; Relatrios peridicos (dirios, semanais etc.) enviados por email; Controle de tempo de execuo de uma solicitao; Sistema de atribuio de tarefas; Diversas verses de localizao (incluindo Portugus Brasil). SCons SCons uma ferramenta de construo de software open source escrita em Python. O SCons prov uma ponte entre plataformas e o substituto para o utilitrio clssico Make com funcionalidades similares ao autoconf/automake, e possui com piladores integrados. Algumas de suas caractersticas so: Seus arquivos de configurao so scripts Python; Analise automtica de dependncias, nativa para C, C++ e Fortran, extensvel para outras linguagens; Suporte nativo para adquirir arquivos fonte do CVS; Suporte nativo ao MS Visual Studio .NET Deteco de mudanas de construo usando assinaturas baseadas em MD5.
Institute) na Carnegie Mellon University a pedido do Depar tamento de defesa dos EUA que necessitava de um modelo para avaliar os seus fornecedores de software. A verso 1.1 foi publicada em 2002 e a atual, verso 1.2 , foi publicada em agosto de 2006. A misso inicial da equipe que produziu o CMMI era com binar trs modelos: Capability Maturity Model for Software (SWCMM) v. 2.0 draft C Systems Engineering Capability Model (SECM) Integrated Product Development Capability Maturity Model (IPDCMM) v. 0.98 O CMMI permite abordar a avaliao e o melhoramento de processos utilizando dois tipos de representao: contnua e por estgio. A representao contnua permite a uma organizao sele cionar reas de processo e melhorar os processos relacionados a ela. Nesta representao, so utilizados nveis de capacidade para caracterizar os melhoramentos relativos a uma rea de processo individual. A representao por estgios usa um conjunto prdefinido de reas de processo para definir uma via de melhoramento para uma organizao. Esta via de melhoramento carac terizada por nveis de maturidade. Cada nvel fornece um conjunto de reas de processo que caracterizam diferentes comportamentos organizacionais. A Figura 5 mostra uma viso geral por estgio dos nveis de maturidade e as reas de processo envolvidas. Podemos notar na figura que a Gesto de Configurao de Software uma rea de processo do nvel 2 do modelo de maturidade. Segundo o CMMIDEV (2006, p.114), o propsito da Gesto de Configurao de software (GCS) estabelecer e manter a integridade dos produtos de trabalho, usando identificao da configurao, controle de configurao, status da configurao contbil e auditoria de configurao. As metas e prticas especificas da gesto de configurao definidas na CMMI so: SG 1. Estabelecer baselines. SP 1.1 Identificar itens de configurao SP 1.2 Estabelecer um Sistema de Gesto de Configurao SP 1.3 Criar ou liberar baselines SG 2. Rastrear e controlar mudanas SP 2.1 Rastrear requisio de mudanas SP 2.2 Controlar itens de configurao SG 3. Estabelecer integridade SP 3.1 Estabelecer registros de Gerencia da Configurao SP 3.2 Realizar auditorias de configurao
Gerncia de configurao nos modelos de maturidade

A partir dos anos 90, iniciouse um movimento no sentido de solucionar problemas que afetavam a industria de software. Problemas como descumprimento de prazos, estouro de or amentos, falta de funcionalidades requeridas pelos clientes e outros, afetavam de maneira drstica a qualidade dos produtos de software produzidos nesta poca. A maioria destes problemas originavamse do fato da cons truo de software ser conduzida utilizandose processos improvisados e pouco ou nada controlados. Sendo assim, vrios rgos e associaes comearam a criar modelos que orientassem o desenvolvimento destes produtos. Embora hoje existam diversos modelos de maturidade voltados para o desenvolvimento de software objetivando aumentar a produtividade da construo e a sua qualidade, todos incluem a utilizao de prticas de GCS que variam de acordo com cada modelo. Neste artigo ser apresentado os pontos em comum da apli cao da GCS nos modelos CMMI, e MPS.BR.
GCS aplicada no CMMI

O CMMI (Capability Maturity Model Integration) tem como objetivo prover um modelo de maturidade para desenvolvi mento de produtos e servios de uma maneira geral. Ele aponta prticas que cobrem o ciclo de vida dos produtos desde a sua concepo at a entrega e manuteno. A verso 1.0 foi publi cado em 2000 em substituio ao CMM (Capability Maturity Model) Verso 1.1, criado pela SEI (Software Engineering
GCS aplicada no MPS

O programa MPS.BR (Melhoria de Processo do Software Brasileiro) foi criado em 2003 pela SOFTEX (Associao para Promoo da Excelncia do Software Brasileiro). O MPS.BR tem o apoio do Ministrio de Cincia e Tecnologia (MCT) da Financiadora de Estudos e Projetos (FINEP) e do Banco
21
Figura 5. Viso por nvel de maturidade X reas de processo
Interamericano de Desenvolvimento (BID). Sua estrutura est dividida em duas reas de apoio: Frum de Credenciamento Controle (FCC) cujas atribui es so: I. Emitir parecer que subsidie deciso da SOFTEX sobre o credenciamento de Instituies Implementadoras (II) e Ins tituies Avaliadoras (IA); II. Monitorar os resultados das Instituies Implementa doras (II) e Instituies Avaliadoras (IA), emitindo parecer propondo SOFTEX o seu descredenciamento no caso de comprometimento da credibilidade do modelo MPS. Equipe Tcnica do Modelo (ETM) cuja atribuio apoiar a SOFTEX sobre os aspectos tcnicos relacionados ao Modelo de Referncia (MRMPS) e Mtodos de Avaliao (MAMPS) para: I. Criao e aprimoramento contnuo do MRMPS, MAMPS e seus guias especficos; II. Capacitao de pessoas por meio de cursos, provas e workshops.
Este modelo surgiu pelo fato de muitas empresas ao busca rem certificao CMM/CMMI se depararem com os custos elevados de implementao/avaliao, inviabilizando as certificaes para pequenas empresas. Uma das metas do programa MPS.BR definir e aprimorar um modelo de melhoria e avaliao de processo de software visando preferencialmente s micro, pequenas e mdias em presas, de forma a atender as suas necessidades de negcio e ser reconhecido nacional e internacionalmente como um modelo aplicvel indstria de software. A base tcnica para a construo e aprimoramento deste modelo de melhoria e avaliao de processo de software composta pelas normas ISO/IEC 12207:2008 [ISO/IEC, 2008a] e ISO/IEC 155042 [ISO/IEC, 2003]. O MPR.BR se prope ser compatvel com o modelo CMM/CMMI para software. Na Figura 6 temos uma viso geral dos principais compo nentes MPS.BR. O Modelo de Referncia, MRMPS, define nveis de ma turidade que so uma combinao entre processos e sua
22
PRojETo
capacidade. Para cada nvel de maturidade so estabelecidos processos que caracterizam estgios de melhoria da imple mentao de processos na organizao. O MRMPS define sete nveis de maturidade: A (Em Otimizao); B (Gerenciado Quantitativamente); C (Definido); D (Largamente Definido); E (Parcialmente Definido); F (Gerenciado); G (Parcialmente Gerenciado).
software utilizandose das ferramentas Mantis para controle de modificaes e Subversion para controle de verses.
Nivel A B C Gerncia de Projetos GPR (evoluo) Gerncia de Riscos GRI Desenvolvimento para Reutilizao DRU Gerncia de Decises GDE Verificao VER Validao VAL Projeto e Construo do Produto PCP Integrao do Produto ITP Desenvolvimento de Requisitos DRE Gerncia de Projetos GPR (evoluo) Gerncia de Reutilizao GRU Gerncia de Recursos Humanos GRH Definio do Processo Organizacional DFP Avaliao e Melhoria do Processo Organizacional AMP Medio MED Garantia da Qualidade GQA Gerncia de Portflio de Projetos GPP Gerncia de Configurao GCO Aquisio AQU Gerncia de Requisitos GRE Gerncia de Projetos GPR Processos
Figura 6. Viso geral dos componentes do MPS.BR
O primeiro nvel da escala o G e o ltimo o A. A Tabela 2 mostra os processos exigidos para cada nvel de maturidade. Segundo definio do MPS.BR Guia de Implementao (2009, p. 16), o propsito do processo de Gerncia de Configurao estabelecer e manter a integridade de todos os produtos de trabalho de um processo ou projeto e disponibilizlos a todos os envolvidos. A GCS encarada pelo MPS.BR como sendo um processo do nvel de maturidade F e portanto deve ter resultados esperados. Os resultados esperados da GCS so: GCO1 Um Sistema de Gerncia de Configurao esta belecido e Mantido; GCO2 Os itens de configurao so identificados com base em critrios estabelecidos; GCO3 Os itens de configurao sujeitos a um controle formal so colocados sob baseline; GCO4 A situao dos itens de configurao e das baselines registrada ao longo do tempo e disponibilizada; GCO5 Modificaes em itens de configurao so controladas; GCO 6 O armazenamento, o manuseio e a liberao de itens de configurao e baselines so controlados consistentes; GCO7 Auditorias de configurao so realizadas objeti vamente para assegurar que as baselines e os itens de confi gurao estejam ntegros, completos e consistentes. Nesta parte do artigo foi mostrado onde a Gerncia de confi gurao de Software se encaixa nos dois dos principais modelos de maturidade de software usados por em presas brasileiras. Na prxima seo do artigo ser apresentado um estudo de caso de aplicao de GCS em uma empresa de desenvolvimento de
Tabela 2. Nveis de Maturidade do MR-MPS
Estudo de caso de uma implementao de GCS com Mantis e Subversion

A partir de agora ser apresentado um estudo de caso de implementao de prticas de GCS com as ferramentas Mantis e Subversion em uma empresa de construo de software de pequeno porte. A esta empresa, daremos o nome fictcio de Casa do Software.
Cenrio
A empresa Casa do Software uma empresa de pequeno porte e conta com trinta e cinco colaboradores. A empresa desenvolve softwares voltados para reas comerciais de outras empresas utilizados por vendedores em seus notebooks nas visitas a seus clientes. A empresa no possui uma poltica de GCS implementa da. Existe apenas uma rotina peridica de backups que fica sob responsabilidade do pessoal de suporte de infraestrutura. As solicitaes de modificaes so feitas pelos clientes atravs de reunies realizadas com o gerente de projetos e desenvolvedores. A nica documentao existente sobre as solicitaes so as atas das reunies, no havendo documen tao de acompanhamento da manuteno e aprovao formal das mesmas por parte da gerncia de projetos. Existe mais de uma verso do mesmo sistema, como conseqncia de alteraes feitas especificamente para determinados clientes, o que complica ainda mais a manuteno dos produtos de software. Como a empresa est em franca expanso, fica clara a necessidade de se implementar prticas de GCS que possam
23
contribuir para melhorar a qualidade de software da mesma, alm disso, as prticas de GCS adotadas devero estar em conformidade com o MPSBR. Como nesta empresa no existe a prtica de GCS, ser ne cessrio a realizao de treinamentos para que os diversos colaboradores envolvidos no processo de implementao de tais prticas e tambm aqueles que iro fazer uso dela possam compreender o novo processo e utilizlo conforme definido no Plano de Gerncia de Configurao. Como projeto piloto, foi selecionado o SISVEN (Sistema de Vendas). O SISVEN um sistema feito em Java destinado a tirar pedidos de vendas, fazer prospeco de clientes e roda em notebooks utilizados por vendedores que visitam clientes em todo o pas.
Nas sees seguintes mostraremos um PGC para esta em presa com base em pesquisa nos trabalhos de Borges (2006), Barbosa (2007), Neto(2005).
Plano para implementao da GCS na empresa

Devido ao tamanho da empresa e da pouca experincia do pessoal envolvido, ser implantada a GCS sob a perspectiva de desenvolvimento, a qual abrange os sistemas de Controle de Modificaes, Controle de Verses e Gerenciamento da Construo. Embora a implementao seja feita sob esta perspectiva, as funes da perspectiva gerencial podem ser implementadas por estes trs sistemas acrescendose procedimentos manuais. Neste artigo apresentaremos uma soluo baseada em Mantis para o Controle de modificaes, e Subversion para o Con trole de Verses. O Gerenciamento de construo feito por um sistema automatizado no ser tratado neste trabalho. Na Figura 7 podemos ver o fluxo do Plano para implementao da GCS na empresa. Criao da Equipe de Gerncia de Configurao (EGC) A Equipe de Gerncia de Configurao (EGC) ser composta por um gerente de configurao, um gerente de projetos e por uma pessoa de infraestrutura. A responsabilidade deste grupo procurar melhorar de for ma constante as atividades de GCS definidas para a empresa, seja mudando processos ou incluindo novas ferramentas. Criao do Comit de Controle de Configurao (CCC) O Comit de Controle de Configurao (CCC) ser com posto pelo gerente de projetos e o Gerente de Qualidade. A responsabilidade do CCC ser avaliar se uma determinada modificao deve ser implementada, rejeitada ou posterga da, baseandose em anlises de impacto que tal modificao ir causar. Criao do Plano de Gerncia de Configurao (PGC) O Plano de Gerncia de Configurao (PGC) define formal mente os padres e prticas adotadas pela empresa no que tange GCS. Neste documento esto descritos os procedi mentos a serem seguidos, as ferramentas a serem utilizadas, os ICSs que devero estar sob controle da GCS, sua forma de identificao e todas as diretrizes que qualquer sistema dever seguir dentro da empresa.
Figura 7. Fluxo do Plano de Implementao da GCS na empresa
Histrico das Revises As tabelas apresentadas nas Tabelas 3 e 4 devero ser altera das sempre que alguma modificao for feita no PGC.
Data 05/07/2009 Verso 1.0 Descrio Criao da primeira verso Autor Alberto Boller
Tabela 3. Histrico das Revises Data 05/07/2009 Verso 1.0 Nome Alberto Boller Filho Cargo Gerente de Projetos
Tabela 4 . Aprovaes
Histrico das Revises Aprovaes
Identificao dos ICSs

Os itens de configurao, os nveis de controle exigidos e os identificadores para cada um encontramse descritos na Tabela 5. Outros itens tambm poderiam ser controlados mas para exemplificar este estudo de caso, os itens constan tes nesta tabela so suficientes.
Regras para nomeao dos itens de configurao

Com exceo do Plano de Gerencia de Configurao, Fontes e Executveis, o nome dos artefatos dever seguir a seguinte regra:
24
PRojETo
<SISVEN><identificador_do_artefato><xxx> Onde <xxx> um nmero sequencial comeando em 001.

Descrio Casos de uso Diagrama de Classes Documento de Requisitos Plano de Testes Plano de Gerencia de Configurao Cdigo Fonte Release Tabela 5. Itens de Configurao Identificador UC DC DR PTES Nvel de Controle Verso e mudana Verso e Mudana Verso e Mudana Verso e Mudana Verso e Mudana Verso e Mudana Verso e Mudana
Armazenamento dos ICSs

Todos os ICSs especificados na Tabela 5 sero armaze nados em um repositrio do Subvesion em um servidor de arquivos que poder ser acessado via Internet ou atravs da rede local. A estrutura do diretrio do repositrio para armazenamento do sistema SISVEN pode ser visto na Figura 8.
Regras para versionamento

As regras de versionamento sero aplicadas apenas nas identificaes de tags e branches, uma vez que o Subver sion controla as verses de itens de configurao a cada operao de commit. O padro de versionamento utilizar a regra descrita a seguir: <XX>.<YY> onde: XX um nmero decimal que representa a verso; YY um nmero decimal que representa a modificao. O primeiro numero de verso dever ser 01.00. A cada mo dificao, o valor YY deve ser incrementado de uma unidade e retorna para 00 assim que uma nova verso gerada.
Figura 8. Estrutura de diretrio do repositrio
Gerenciamento de Baselines
Sempre que uma modificao for concluda, seja em algum documento ou cdigo fonte e o gerente de projetos tiver inspecionado os testes e aprovado, o desenvolvedor poder solicitar ao gerente de configurao a criao de uma base line. As baselines ficaro armazenadas na subpasta tag da estrutura de diretrio do repositrio. Os branches devero ser criados pelo gerente de configu rao apenas quando a modificao exigida pela solicitao de mudana levar um tempo para sua concluso superior a trs semanas, caso contrrio ser feita na mainline cuja subpasta da estrutura de diretrio chamase trunk (ver Figura 8). Apenas o gerente de configurao ter autoridade para criar branches e tags e dever fazlo mediante a solicitao formal do gerente de projeto que dever enviar um email especificando o que e para quem deve ser criado.
Identificao de Tags
Sempre que uma nova baseline for criada, esta dever ser identificada por uma tag seguindo as seguintes regras: Baseline de Documentos DOCV<verso> Baseline de Cdigo Fonte FONTEV<verso> Baseline de Releases RELEASEV<verso> Onde <verso> segue as regras descritas no item anterior.
Identificao de Branches
Sempre que houver necessidade de criao de um branch, sua identificao dever obedecer aos seguintes padres: Branch de Documentos DOCMANUT<nmero_da_solicitao_de_modificao> Branch de Cdigo Fonte FONTEMANUT< nmero_da_solicitao_de_modificao> Branch de Releases RELEASEMANUT< nmero_da_solicitao_de_modificao> O <nmero_da_solicitao_de_modificao> ser aquele atri budo pelo campo ticket do Mantis conforme veremos adiante.
Estabelecimento de um sistema de GCS

Conforme descrito no MPS.BR Guia de Implementao (SOFTEX, 2009, p. 20), para que a Gerncia de Configu rao ocorra de forma sistemtica, necessrio que seja estabelecido um sistema de Gerncia de Configurao. Esse sistema pode ser decomposto em trs subsistemas: sistema de controle de verses, sistema de controle de modificaes e sistema de gerenciamento de construo. Para o subsistema de controle de modificaes, utiliza remos a ferramenta Mantis. A escolha desta ferramenta est apoiada no fato de ser open source (o que diminui os custos), por ter integrao direta com o Subversion (o que permite dar visibilidade ao processo), e ser uma aplicao.
25
A Figura 9 ilustra o fluxo bsico de controle de modificaes que ser seguido quando uma solicitao de modificao for feita pelo usurio.
produto TortoiseSVN que faz a mesma coisa s que de forma interativa e visual facilitando o trabalho.
Figura 10. Tela de login do Mantis
Figura 9. Fluxo do Controle de modificaes da empresa Casa do Software
Figura 11. Viso inicial dos status de solicitaes de mudanas
Nas Figuras 10 a 14 podemos visualizar como o Mantis trata o controle de uma solicitao de modificaes. Na Figura 10 observamos que existe um controle de acesso s solicitaes a nvel de tipo de usurio que pode ser um relator, desenvolvedor, gerente administrador etc, cada qual com suas restries de acesso. Na Figura 11 temos uma viso (a nvel de usurio) das diver sas solicitaes e seus status. Nas Figuras 12 a 14 aparece em detalhes todos os tramites pelos quais passou uma solicitao de mudanas, permitindo manter informado o usurio solici tante e todos os outros envolvidos no processo de GCS. Para o subsistema de controle de verses, ser utilizado o Subversion. A escolha desta ferramenta tambm est baseada no fato de ser open source, ter integrao com o Mantis e com o Eclipse. O Subversion possui uma parte server que roda em um servidor e que fica responsvel por fazer as operaes de checkin, checkout, controle de lock, merge, controle de acesso e outras. O Subversion possui tambm uma parte client, que roda na mquina do desenvolvedor e que tem a funo de solicitar parte server as funes necessrias. Como a parte client do Subversion executada em linha de comando, e por esta razo ser pouco amigvel, iremos utilizar como client o
Figura 12. Viso detalhada de uma solicitao de mudana (Informaes gerais)
Na Figura 15 apresentado um fluxo bsico de utilizao do Subversion. Nas Figuras 16 a 23 so apresentados exemplos das funes descritas na Figura 15 usandose o TortoiseSVN. As Figuras 16 e 17 mostram que o desenvolvedor deve fazer uma cpia dos ICSs do repositrio para seu disco local a fim
26
PRojETo
de poder fazer as modificaes necessrias utilizandose da operao de checkout. A Figura 18 mostra que novos itens de configurao so adicionados cpia local do repositrio atra vs de operao de add. A Figura 19 mostra uma operao de update para atualizar a cpia local do repositrio. As Figuras 20 22 mostram uma atualizao da mainline atravs de uma operao de commit. Vale observar neste ultimo caso que esta operao controlada com autenticao de usurio e senha. Por fim, a Figura 23 mostra um log com todas as operaes executadas neste repositrio ao longo do tempo. Atravs das figuras vistas podese concluir que o Subversion controla de forma adequada o armazenamento e manuseio de ICSs, fornecendo dados para sua auditoria.
Figura 16. Fazendo check-out
Figura 17. Resultado da operao de check-out Figura 13. Viso detalhada de uma solicitao de mudanas (Anotaes)
Figura 18. Adicionando novos programas ao repositrio local Figura 14. Viso detalhada de uma solicitao de mudana (Histrico do caso)
Figura 15. Fluxo bsico de utilizao do subversion
Figura 19. Fazendo uma operao de update para atualizar a cpia local
27
Figura 20. Iniciando uma operao de commit
Figura 23. Log das operaes realizadas no repositrio
Instalao do Mantis
A verso do Mantis para Windows pode ser baixada a partir do site http://www.mantisbt.org/download.php. A sua verso estvel mais recente a MantisBT 1.1.8. Os se guintes softwares so requeridos e devem ser instalados: PHP 4.3.0 and higher MySQL database 4.1.1 and higher (MS SQL and DB2 are also supported). Web server (Apache, IIS, etc.) Como forma de facilitar a instalao dos softwares acima, pode ser instalado a ltima verso do XAMPP que traz todos os requisitos para rodar o Mantis. O XAMPP pode ser baixado a partir do site www.baixaki.com.br. Caso seja instalado o XAMPP, o diretrio de instalao do Mantis deve estar localizado na pasta htdocs existente no diretrio de instalao do XAMPP. O Mantis simples de instalar. Basicamente s seguir as instrues de instalao que iro surgir na tela.
Figura 21. Operao de commit (autenticao de usurio autorizado)
Configurao do Mantis
Aps instalado o Mantis necessrio configurar o arquivo config.inc.php com os parmetros corretos para emisso de emails. A configurao utilizada neste trabalho est apresentada na Figura 24. Os campos user, domnio e password que aparecem no texto devem ser substitudos pelos correspondentes de cada caso. A configurao listada na Figura 24 j inclui os par metros necessrios para integrao com o Subversion. O significado de cada parmetro pode ser obtido no manual do Mantis no endereo http://manual.mantisbt.org/ index.php. Vale observar que para que o envio de emails a cada novo status de uma solicitao de modificao ocorra, neces srio a instalao do PHPMailer, que pode ser encontrado no site http://phpmailer.sourceforge.net. A instalao do PHPMailer simples, bastando para tanto copiar os arqui vos class.smtp.php e class.phpmailer.php para o diret rio destinado aos arquivos de include. No caso do XAMPP o diretrio <diretrio_de_instalao_do_XAMPP>\ php\
Figura 22. Resultado da operao de commit
Resultados esperados do MPS.BR alcanados na soluo adotada

Conforme descrito anteriormente, a soluo adotada deve r estar em conformidade com o modelo MPSBR. Segundo o MPS.BR Guia Geral (SOFTEX, 2009, p.23) o processo de Gerencia de Configurao encontrase no nvel F do MRMPS e deve atingir sete resultados esperados. A Tabela 6 mostra os resultados esperados e os itens deste trabalho onde esto contemplados.
28
PRojETo
Resultado esperado GCO 1. Um Sistema de Gerncia de Configurao estabelecido e mantido GCO 2. Os itens de configurao so identificados com base em critrios estabelecidos Estabelecimento de um sistema de GCS
Seo
Identificao dos ICSs Regras para nomeao dos itens de configurao Regras para versionamento Identificao de Tags Identificao de Branches GCO 3. Os itens de configurao sujeitos a um controle formal so colocados sob baseline Armazenamento dos ICSs Gerenciamento de Baselines Estabelecimento de um sistema de GCS GCO 4. A situao dos itens de configurao e das baselines registrada ao longo do tempo e Gerenciamento de Baselines disponibilizada; Estabelecimento de um sistema de GCS GCO 5. Modificaes em itens de configurao so controladas; Estabelecimento de um sistema de GCS
GCO 6. O armazenamento, o manuseio e a liberao de itens de configurao e baselines so Estabelecimento de um sistema de GCS controlados GCO 7. Auditorias de configurao so realizadas objetivamente para assegurar que as baselines e os Estabelecimento de um sistema de GCS itens de configurao estejam ntegros, completos e consistentes Tabela 6. Resultados esperados no nvel F do MPS.BR
PEAR. A instalao est descrita no arquivo readme que traz tambm um exemplo simples.
Instalao do Subversion
A instalao do Subversion mais simples do que a do Mantis. O arquivo de instalao pode ser obtido no ende reo http://www.collab.net/downloads/subversion/. O nico software requerido o Apache version: 2.2.11 que j estar instalado caso o XAMPP tenha sido instalado primeiro. Vale ressaltar que neste endereo existem dois arquivos de instalao que devem ser baixados: CollabNet Subversion Server and Client v1.6.3 (for Windows) CollabNet Subversion CommandLine Client v1.6.3 (for Windows) O primeiro obrigatrio para o funcionamento das ope raes. Para o segundo arquivo, poder ser usada a alter nativa do software TortoiseSVN que mais amigvel e tem integrao direta com o Windows Explorer. O arquivo para instalao do TortoiseSVN pode ser encontrado no site www.baixaki.com.br. No necessrio configurao adicional no software para o seu funcionamento, porm, para cada repositrio dever ser configurado os perfis de acesso no arquivo svnserve.conf. Para detalhes de integrao do Subversion com o Mantis, consulte o site http://alttag.com/blog/archives/2006/11/integrating mantisandsubversion/.
Figura 24. Arquivo config.inc.php
Consideras Finais
Neste artigo, vimos inicialmente os conceitos gerais de Gerencia de Configurao de software, suas principais
terminologias e algumas ferramentas voltadas para dar apoio GCS. Na sequencia, mostramos uma soluo de boa qualidade e baixo custo que atende as exigncias dos modelos de maturi dade e que pode ser facilmente implementada em empresas de pequeno porte a fim de instalar as prticas de Gerncia de Configurao de Software. A soluo foi mostrada atravs de
29
Referncias Barbosa, Valeria Plano de Gerncia de Configurao de Software: Sistema de Controle de Custos 11/09/2007 disponvel em http://conexao.googlecode.com/files/ SYSCOPlanoGerenciaConfiguracao.pdf Ben Collins-Sussman, de et al Version Control with Subversion: for Subversion 1.6 (Compiled from r3445) 2008 disponvel em <http:subversion.tigris.org/> Borges, Vanessa R. Implantao de Prticas de Gerncia de Configurao em uma Fbrica de Software: Um estudo de caso (Graduao em Cincia da Computao) Universidade Federal de Lavras, Minas Gerais, 2006 Forte, G.,Rally Round the Repository CASE Outlook, Dez 1989, p. 5-27 , MOLINARI, Leonardo. Gerncia de configurao: Tcnicas e prticas no desenvolvimento do software. Florianpolis : Visual Books, 2007. 208p. Neto, Euclides Plano de Gerncia de configurao de software: Projeto VENSSO Venda de Servios de Software 27/05/2005 disponvel em <http://vensso.sourceforge.net/doc/ VENSSO_SCM_20050527.pdf> PRESSMAN, Roger S. Engenharia de software. 6. ed. So Paulo : McGraw-Hill, 2006. xxxi, 720p. SEI, Software Engineering Institute. CMMI for Development, Version 1.2: CMMI DEV V 1.2. Carnegie Mellon University, EUA, 2006 573p. SOFTEX MPS.BR - Melhoria de Processo do Software Brasileiro, Guia de Implementao Parte 2: Nvel F, Rio de Janeiro, 2009 53p SOFTEX, MPS.BR - Melhoria de Processo do Software Brasileiro, Guia Geral Rio de Janeiro, 2009 57p
Links Collabnet CollabNet Subversion Downloads http://www.collab.net/downloads/subversion/ Comunidade de Software & Inovao Empresarial As Ferramentas de SCM e o Suporte do CMM http://paginas.ispgaya.pt/~msantos/es_artigos_tecnicos_1/60_FerramentasSCM_e_ suporteCMM.pdf DevMedia Gerncia de Configurao Parte 1 http://www.devmedia.com.br/articles/viewcomp.asp?comp=9378 EAI Community Establishing a Configuration Management Baseline http://it.toolbox.com/blogs/enterprise-solutions/establishing-a-configuration-managementbaseline-13910 Enciclopdia Livre, (2007) Gerncia de Configurao de Software http://pt.wikipedia.org/wiki/Ger%C3%AAncia_de_Configura%C3%A7%C3%A3o_de_Software Gerncia de Configurao Gerncia de Configurao http://www.cin.ufpe.br/~gfn/qualidade/gc.html Mantis Mantis Bug Tracker http://www.mantisbt.org/ Pronus Engenharia de Software O que Gerncia de Configurao http://www.pronus.eng.br/artigos_tutoriais/gerencia_configuracao/gerencia_configuracao.php Regularize Gerncia de Configurao de Software http://cartilha.regularize.com.br/list/18/cartilha/post/80/gerencia-de-configuracao-de-software.html Tigris.org Subversion http://subversion.tigris.org/
30
edio ta
um estudo de caso em uma empresa fictcia, e fez uso das fer ramentas Mantis e Subversion para o controle de solicitao de modificaes e controle de verses respectivamente. Foram apresentados ainda aspectos de instalao das ferra mentas e sua customizao.
A Engenharia de Software Magazine tem que ser feita ao seu gosto. Para isso, precisamos saber o que voc, leitor, acha da revista! D seu voto sobre este artigo, atravs do link:
D s
D seu feedback sobre esta edio!
Feedback eu
sobre e s
Engenharia
PRoC E S S o
Medio de Software
Um importante pilar da melhoria de processos de software

Este artigo discute algumas questes relacionadas Medio de Software, principalmente no contexto da melhoria de processos de software.
Para que serve?
O
Monalessa Perini Barcellos
monalessa@inf.ufes.br
Doutora em Cincias em Engenharia de Sistemas e Computao (COPPE/UFRJ), Mestre em Cincias em Engenharia de Sistemas e Computao (COPPE/UFRJ), Bacharel em Cincia da Computao (UFES). Professora do Departamento de Informtica, rea Engenharia de Software, da Universidade Federal do Esprito Santo (UFES). Atuante desde 1999 em projetos, consultorias, treinamentos e pesquisas da rea de Engenharia de Software.
s avanos tecnolgicos e a alta competitividade do mercado esto continuamente aumen tando a demanda por softwares cada vez melhores e que sejam produzidos em projetos aderentes aos custos e prazos planejados. Mesmo diante de todos os avanos tecnolgicos, realizar projetos aderentes aos seus planos ain da um desafio para grande parte das organizaes de software. Buscando aprimorar suas prticas de Engenharia de Software e, consequentemente, desen volver produtos de melhor qualidade em projetos conduzidos de acordo com seus planos, as organizaes tm mostrado um crescente interesse por programas de melhoria de processos, contexto no qual a medio de software tem papel fundamental.
Fornecer conhecimento sobre Medio de Software para organizaes, pesquisadores, estudantes e profissionais de software.

Organizaes de software que tm (ou planejam ter) a Medio de Software como uma de suas prticas. Estudantes e profissionais de software que buscam entendimento sobre o tema.
A medio de software considerada uma das atividades mais importantes para a gerncia e melhoria de processos e produtos de software, uma vez que fornece subsdios para a elaborao de planos realistas para os projetos e possi bilita o monitoramento da aderncia da execuo dos projetos em relao a seus planos (ISO/IEC, 2007). Isso possvel, pois as medidas, ao serem coletadas e armazenadas, podem ser analisadas
31
atravs de mtodos e fornecem informaes importantes para a tomada de deciso, envolvendo a identificao e realizao de aes corretivas e preventivas que orientem os projetos e processos a alcanarem os objetivos para eles estabelecidos. Resumindo: organizaes de software que buscam a melhoria de seus processos precisam realizar medio de software. Considerando essa afirmao, neste artigo so discutidas algumas questes relacionadas medio de software e so apresentadas algumas propostas que apiam a definio do processo de medio de software e sua realizao nas organizaes. importante destacar que o objetivo aqui no ensinar como realizar a medio, e sim discutir questes relacionadas a esse contexto. Para isso, inicialmente so apresentados o conceito e um breve histrico da medio de software. Em seguida, a utilizao da medio de software nas organizaes discu tida e, por fim, algumas propostas que apiam a definio do processo de medio e sua execuo so descritas.
nos requisitos dos nveis iniciais dos modelos que tratam da melhoria de processos em nveis. No CMMI (Capability Ma turity Model Integration), a medio encontrase no nvel 2 (rea de processo Medio e Anlise) e no MR MPS (Modelo de Referncia para Melhoria de Processo de Software Brasileiro) encontrase no nvel F (processo Medio).
Medio de Software nas Organizaes

Para que a medio de software seja eficientemente reali zada em uma organizao, e d o retorno necessrio para ser percebida como prtica fundamental sobrevivncia e ao crescimento organizacional, sua implementao deve ser orientada para apoiar a tomada de deciso nos mbitos tcnico e de negcios. Esse o principal diferencial entre as organi zaes que se beneficiam com os resultados de seu programa de medio e as organizaes que simplesmente despendem tempo e esforo para acumular dados inteis. Organizaes de software bem sucedidas geralmente imple mentam a medio como parte de suas atividades, englobando os nveis tcnico, gerencial e estratgico. Nessas organizaes, a medio prov a informao necessria s tomadas de deciso que impactam no desempenho tcnico e de negcio, sendo essa informao disponibilizada para os tomadores de deciso em todos os nveis da organizao, de acordo com seus objetivos. Um gerente de projetos pode, por exemplo, utilizar as informa es providas pela medio para realizar uma comunicao mais eficiente, traar os objetivos especficos dos projetos, identificar e corrigir problemas antecipadamente, tomar decises chave e justificar tais decises. Mas importante ressaltar que, assim como qualquer outra ferramenta gerencial ou tcnica, a medio no capaz de garantir o alcance dos objetivos. Entretanto, ela capaz de auxiliar os tomadores de deciso a terem uma aborda gem prativa s questes crticas inerentes aos projetos, o que contribui para que os objetivos sejam alcanados. Alm de apoiar fortemente a tomada de deciso, a medio auxilia e acelera o aprendizado organizacional, uma vez que a anlise dos dados coletados nos projetos prov a funda o necessria para o aprendizado atravs de cada projeto e, consequentemente, para o aprendizado organizacional. Tambm auxilia a organizao a perceber e entender as diferenas entre o seu desempenho e o desempenho exigido pelo mercado, permitindo que ela otimize seus processos tcnicos e de negcio, quando necessrio. Isso possvel, pois as medidas coletadas nos projetos da organizao podem ser combinadas e, atravs da utilizao de diferentes tcnicas, analisadas para satisfazer as diferentes necessidades de in formao organizacionais. As organizaes podem, ainda, utilizar as informaes providas pela medio para elaborar planos realistas para os projetos, comparar o desempenho dos projetos correntes com seus planos, orientar os investimentos e decises de melhoria de processos e auxiliar a prever se os projetos em andamento iro alcanar os objetivos inicialmente estabelecidos. Essas so aes comuns em organizaes de software maduras, onde h utilizao da medio em todo o ciclo de vida do software
Conceito e Histrico
Medio de software uma avaliao quantitativa de qual quer aspecto dos processos e produtos da Engenharia de Software, que permite seu melhor entendimento e, com isso, auxilia o planejamento, controle e melhoria do que se produz e de como produzido (BASS et al., 1999). O elemento bsico da medio, que propicia a anlise quantitativa, so as medi das, as quais caracterizam, em termos quantitativos, alguma propriedade de um objeto da Engenharia de Software. O objetivo mais importante da aplicao da medio de sof tware prover informao quantitativa para apoiar a tomada de decises. Em outras palavras, as organizaes de software definem medidas e coletam dados que, ao serem analisados, possam fornecer informaes que sejam teis tomada de decises, que envolve a anlise do alcance aos objetivos esta belecidos e identificao de aes corretivas e de melhoria. A medio de software comeou a ser praticada na dcada de 70, inicialmente apenas para medir o nmero de linhas de cdigo dos programas produzidos. Na dcada de 80, outras medidas relacionadas s fases finais do desenvolvimento comearam a ser utilizadas, porm os objetivos da realizao da medio nas organizaes no eram explcitos ou, se eram, no eram compreensveis aos seus membros, resultando em medies inteis no alinhadas s necessidades das organizaes ou dos projetos. Nos anos 90, impulsionados por algumas aplicaes bem sucedidas, foram desenvolvidos modelos para o processo de medio baseados na melhoria de processos e nos princpios da qualidade total, fornecendo as diretrizes e a infraestrutura bsicas para definir, coletar, validar e analisar medidas. Atualmente, a medio de software considerada um dos temas mais importantes na Engenharia de Software quando se fala em melhoria de processos. Enquanto, no passado, muitas organizaes de software no reconheciam a importncia das atividades de medio e as tratavam apenas como mais uma coisa a ser feita, hoje ela considerada uma prtica bsica da Engenharia de Software, sendo evidenciada por sua incluso
32
Engenharia de Software Magazine - Medio de Software
PRoC E S S o
e as informaes obtidas so consideradas e utilizadas como recurso estratgico na conduo desse ciclo. Somente quando as informaes obtidas na anlise dos dados coletados so utilizadas para direcionar as aes necessrias s organizaes e seus projetos, que o objetivo fundamental da medio alcanado e percebido pelas organizaes, fator que contribui para a real institucionalizao de um programa de medio eficiente. Uma vez que a medio de software implantada e executada corretamente em uma organizao, tornase possvel passar melhoria de processos. Melhoria de processos de software uma abordagem para de finio, organizao e implementao de processos de software que sejam eficientes para uma organizao (KILPI, 2001). Implantar melhoria de processos em uma organizao baseiase fundamentalmente na identificao e realizao das mudanas que levam melhoria dos processos. Para isso, inicialmente a medio utilizada para identificar as necessidades de mudanas. Posteriormente, quando as mudanas so realizadas, a medio utilizada para avaliar os resultados das alteraes. Em outras palavras, a melhoria de processos um ciclo contnuo no qual a medio um dos principais pilares.
que identifica as atividades do processo de medio que so requeridas para especificar que informaes de medio so necessrias, como as medidas sero definidas, como os dados sero coletados, como os resultados sero analisados e como avaliar se os resultados so vlidos. O processo de medio definido na ISO/IEC 15939 consiste de quatro atividades que so sequenciadas em um ciclo iterativo, per mitindo feedback e melhoria contnua do processo. Ele uma adaptao do ciclo PDCA (Plan-Do-Check-Act), comumente utilizado como base para a melhoria da qualidade. Suas ati vidades so: (i) estabelecer e manter comprometimento com a medio; (ii) planejar o processo de medio; (iii) executar o processo de medio; e, (iv) avaliar a medio. O processo de medio proposto pela ISO/IEC 15939 orientado s necessidades de informao da organizao. Para cada necessidade de informao, o processo gera um produto de informao, a fim de satisfazer a necessidade de informao identificada. Para isso, o processo considera um Modelo de Informao de Medio, que estabelece a ligao entre as medidas definidas e as necessidades de informao identificadas. A Figura 1 apresenta o Modelo de Informao de Medio definido na ISO/IEC 15939.
Abordagens para Medio de Software

Existem na literatura tcnica algumas abordagens que tratam a medio de software e apiam a definio do processo de medio, bem como sua execuo. Algumas dessas abordagens propem processos para a realizao da medio, outras definem modelos de informao que estabelecem a estrutura de informao considerada pela medio e outras incluem propostas tanto para o processo de medio quanto para o modelo de informao. O processo de medio pode ser definido como um conjun to de passos que deve orientar a realizao da medio em uma organizao. Um processo de medio eficiente fator crtico ao sucesso da medio na organizao, pois ele que direciona as atividades a serem realizadas para que, com os resultados da anlise dos dados coletados, seja possvel a identificao de tendncias e antecipao aos problemas, a fim de prover melhor controle dos custos, reduo dos riscos, melhoria da qualidade e, consequentemente, alcance dos objetivos tcnicos e de negcio (WANG e LI, 2005). Apesar das propostas existentes possurem diferenas entre si, percebese que, no mbito do processo de medio, as definies propostas consistem basicamente de quatro etapas: (i) definio das medidas; (ii) coleta das medidas; (iii) anlise das medidas coletadas; e, (iv) utilizao dos resultados da anlise em aes. A seguir so apresentadas as principais abordagens de medio de software. ISO/IEC 15939 - Software Engineering Software Measurement Process A norma ISO/IEC 15939 define uma das abordagens mais conhecidas para o processo de medio. Segundo essa nor ma, um processo de medio descrito como um modelo
Figura 1. Modelo de Informao de Medio da ISO/IEC 15939
De acordo com o Modelo de Informao de Medio, as ne cessidades de informao so atendidas por conceitos men surveis definidos em relao s entidades que podem ser medidas. Essas entidades possuem atributos aos quais so aplicados mtodos de medio para obter medidas base que so associadas atravs de funes de medio para compor medidas derivadas1. Medidas so analisadas por modelos de anlise e fornecem indicadores cuja interpretao representa
1 Medidas base so funcionalmente independentes de outras medidas, enquanto que medidas derivadas so definidas como funo de duas ou mais medidas (ISO/IEC, 2002)
33
produtos de informao que atendem as necessidades de informao inicialmente identificadas. IEEE Std 1061-1998 IEEE Standard for a Software Quality Metrics Methodology O IEEE Std 10611998 prov um framework para medidas de qualidade de software e um processo de medio de qualidade de software para estabelecer requisitos de qualidade e iden tificar, implementar, analisar e validar medidas de qualidade de processo e de produto. Na Figura 2 apresentado o framework para medidas de qua lidade de software definido no IEEE Std 10611998. No primeiro nvel so estabelecidos os requisitos de qua lidade do sistema (representado na Figura 2 pelo item Qua lidade de Software do Sistema) atravs da identificao de atributos de qualidade (por exemplo, Confiabilidade). Fatores de qualidade so, ento, definidos para representar a viso dos atributos de qualidade segundo a gerncia e o usurio. Para cada fator de qualidade identificada uma medida para representlo quantitativamente. Por exemplo: o atributo de qualidade Confiabilidade pode ser representado pelo fator de qualidade Tolerncia a falhas, quantificado pela medida Tempo mdio entre falhas. Se necessrio, os fatores podem
ser decompostos em subfatores que, por sua vez so, tambm, quantificados por medidas. Baseandose no framework definido, o IEEE Std 10611998 prope um processo de medio composto por cinco ativida des: (i) estabelecer os requisitos da qualidade de software; (ii) identificar as medidas de qualidade de software; (iii) imple mentar as medidas; (iv) analisar os resultados das medidas; e (v) validar as medidas. Practical Software Measurement PSM PSM uma abordagem para medio de software orientada s necessidades de informao organizacionais aderente ISO/IEC 15939 e, como ela, possui dois componentes: um Modelo de Informao de Medio e um Processo de Medio. O Modelo de Informao de Medio, assim como na ISO/ IEC 15939, tem como objetivo estabelecer a ligao entre as medidas definidas e as necessidades de informao iden tificadas. Para isso, como mostra a Figura 3, o modelo de informao representa a evoluo de uma necessidade de informao at o Plano de Medio. A partir das necessidades de informao, conceitos mensu rveis, que indicam o que deve ser medido para atendlas, devem ser identificados e modelados em um construtor de
Figura 2. Framework para medidas de qualidade do IEEE Std 1061-1998
Figura 3. Modelo de Informao de Medio
34
PRoC E S S o
medio para estabelecer exatamente que medidas de que atributos so necessrias. A partir da, o mecanismo de coleta e organizao dos dados de uma ou vrias instn cias do construtor de medio deve ser definido. O Plano de Medio o resultado formal que agrupa todos os itens anteriores. Sendo aderente ISO/IEC 15939, a relao entre neces sidades de informao e conceito mensurvel do Modelo de Informao do PSM equivale relao entre esses itens presente no Modelo de Informao de Medio da ISO/ IEC 15939 (representado no lado esquerdo da Figura 1). O construtor de medio, por sua vez, inclui os demais itens presentes no Modelo de Informao da ISO/IEC 15939 (de mais itens representados na Figura 1). Considerando o modelo de informao definido, o PSM prope um processo de medio composto por quatro fases: (i) planejamento; (ii) execuo; (iii) avaliao; e (iv) comprometimento. Observandose as primeiras etapas dos processos de medio propostos nas abordagens apresentadas, notase que elas so responsveis pela identificao e definio das medidas, bem como pela associao destas aos objetivos organizacionais. Essas etapas so de grande importncia para a medio, pois so elas que definem que informaes sero fornecidas para apoiar as tomadas de deciso. Essa tarefa pode parecer simples, mas no , principalmente em organizaes de software. Para que as atividades de me dio estejam alinhadas aos objetivos de negcio, preciso identificar os fatores crticos que so capazes de determinar se os objetivos de negcio sero ou no alcanados. Consi derando essa questo, h algumas abordagens que apiam a identificao e seleo de medidas adequadas avaliao do
alcance dos objetivos organizacionais. Uma das abordagens mais conhecidas o Goal Question Metric GQM que consi dera que, para cada objetivo estabelecido, possvel determi nar questes cujas respostas esto associadas a medidas. A Figura 4 apresenta um exemplo para a relao de um obje tivo de negcio, suas questes e medidas associadas. Aps serem definidas, as medidas devem ser coletadas e analisadas. O objetivo de analisar os dados das medidas tornar qualquer padro, tendncia ou relacionamento mais visvel, a fim de que estes possam auxiliar nos julgamen tos necessrios s tomadas de deciso. Durante a anlise, medidas que fornecem informaes sobre o alcance dos objetivos so transformadas em indicadores. Os indicadores so medidas base ou medidas derivadas que, associadas a critrios de avaliao ou deciso prdefinidos, so capazes de fornecer informaes que descrevem o alcance dos obje tivos estabelecidos. So inicialmente definidos no Plano de Medio, mas medida que novas necessidades so identi ficadas, novos indicadores devem ser definidos. Em relao anlise dos dados coletados para as medidas, importante observar que, ao longo da execuo de um processo de medio, o foco da anlise muda de acordo com a fase do ciclo de vida dos projetos nos quais a medio aplicada. Tipicamente so considerados trs tipos de anlise: (i) anlise de estimativas, utilizada principalmente no incio do projeto, para apoiar o planejamento ou replanejamentos; (ii) anlise de viabilidade, utilizada quando o Plano do Projeto est prximo de ser concludo, para determinar se os planos e metas nele estabelecidos so realsticos e al canveis; e (iii) anlise de desempenho, utilizada durante a execuo do projeto para determinar se ele est indo ao encontro dos planos e metas definidos. A Figura 5 ilustra os trs tipos de anlise.
Figura 4. Exemplo de aplicao do GQM
35
projetos. Tambm apia a melhoria de processos no nvel or ganizacional, fornecendo informaes resultantes da anlise dos dados coletados ao longo dos projetos, que podem ser utilizadas para orientar aes de melhoria nos processos. Neste artigo foram discutidos alguns aspectos relevantes aplicao da medio de software em organizaes que buscam a melhoria de processos, tendo sido enfatizada a necessidade do alinhamento entre a medio e os objetivos organizacionais. D seu feedback sobre esta edio! A Engenharia de Software Magazine tem que ser feita ao seu gosto. Para isso, precisamos saber o que voc, leitor, acha da revista! D seu voto sobre este artigo, atravs do link: www.devmedia.com.br/esmag/feedback
Referncias Figura 5. Tipos de anlise BASILI, V. R., ROMBACH, H. D., CALDIERA, G., 1994, Goal Question Metric Paradigm, Encyclopedia of Software Engineering, 2 Volume Set, John Wiley & Sons, Inc. BASS, L., BELADY, L., BROWN, A., FREEMAN, P., ISENSEE, S., KAZMAN, R., KRASNER, H., MUSA, J., PFLEEGER, S., VREDENBURG, K., WASSERMAN, T., 1999, Constructing Superior Software, Software Quality Institute Series, Macmillan Technical Publishing. BRIMSON, J. A., 2004, Stop Cane Dancing and Integrate Statistical Process Control (SPC) into your Process Based Management System, Measurement Business Excellence, v. 8, n. 2, p. 15-22. CHRISSIS, M. B., KONRAD, M., SHRUM, S., 2006, CMMI (Second Edition): Guidelines for Process Integration and Product Improvement, Addison-Wesley. DEMING, W. E., 1986, Out of Crises, Massachusetts Institute of Technology, Center of Advanced Engineering, Cambridge. ISO/IEC, 2007, ISO/IEC 15939 (E) Software Engineering - Software Measurement Process, International Organization for Standardization and the International Electrotechnical Commission, Geneva, Switzerland. KILPI, T., 2001, Implementing a Software Metrics Program at Nokia, IEEE Software, v. 18, n. 6, p. 72-77. McGARRY, J., CARD, D., JONES, C., LAYMAN, B., CLARK, E., DEAN, J., HALL, F., 2002, Pratical Software Measurement: Objetive Information for Decision Makers, Addison Wesley, Boston, USA. NIESSINK, F., VLIET, H., 2001, Measurement Program Success Factors Revisited, Information and Software technology, v. 43, n. 10, p. 617-628. SOFTEX, 2009, MPS.BR: Melhoria de Processo do Software Brasileiro - Guia Geral : 2009, Disponvel em: http://www.softex.br/mpsbr. WANG, Q., LI, M., 2005, Measuring and Improving Software Process in China, In Proceedings of International Symposium on Empirical Software Engineering - ISESE 2005, Hoosa Head, Australia, p. 183-192.
Feedback eu
sobre e s
D s
No incio de um projeto, necessrio estabelecer as es timativas para sua realizao, principalmente as relacio nadas a tempo, custo e esforo. Dados do projeto corrente e de projetos anteriores so utilizados para calcular essas estimativas. O Plano do Projeto ento elaborado. Quando sua elaborao est em fase conclusiva, dados das medidas coletadas orientam a anlise de viabilidade dos planos estabelecidos, indicando os riscos envolvidos e fornecendo diretrizes para que sejam traadas outras alternativas, caso necessrio. Quando o projeto executado, importante que seu status seja conhecido, bem como seu desempenho em relao aos planos estabelecidos e possveis problemas re lacionados. A anlise de desempenho quem fornece essas informaes, atravs da anlise dos valores das medidas coletadas ao longo do projeto, e relacionamento destas com os objetivos estabelecidos nos planos.
Consideraes Finais
Atualmente as organizaes de software tm reconhecido a necessidade de possurem processos de software que sejam capazes de atender s demandas de qualidade e produti vidade do mercado. Processos com essa caracterstica so resultado da gerncia eficiente dos processos e projetos, que leva sua melhoria, contexto no qual a medio de software atividade primria. A medio apia a melhoria no nvel dos projetos, uma vez que fornece a base necessria para a realizao de planos realsticos e controle destes ao longo de sua execuo nos
36
edio ta
PRoC E S S o
37
Agilidade
Nesta seo voc encontra artigos voltados para as prticas e mtodos geis.
A Comunicao no Processo de Software

O papel cada vez mais decisivo da comunicao no processo de software
Neste artigo veremos o quanto o processo de software permeado pelo processo de comunicao interpessoal. No se trata de um processo apenas tcnico, mas tambm social. Com o advento do paradigma de desenvolvimento rpido de software, destacamos o papel cada vez mais decisivo da comunicao interpessoal com a utilizao de mtodos geis no desenvolvimento de software.
Mrcia Regina Simm Cant

macantu@bewnet.com.br
Bacharel em Cincia da Computao; atua como analista de sistemas desde 2001.
s avanos na rea da tecnologia tm permitido ao longo dos ltimos anos grande informa tizao nos processos das organizaes. No entanto, dispor de um sistema de software que atenda as diversas neces sidades da gesto organizacional pode se tornar um processo complexo. Isso implica, muitas vezes, em desenvolver ou customizar um sistema. Mas no s isso: os sistemas de software precisam evoluir para acompanhar os modelos de gesto e, neste contexto passam obriga toriamente por manutenes que podem ser melhorias, otimizaes e at mesmo reparos. Segundo Pfleeger (2004), estas manutenes abrangem qualquer alte rao ou correo efetuada num sistema que j est sendo utilizado, uma vez que sua vida til no acaba com a entrega. A grande maioria dos sistemas de softwa re deve ser construda para incorporar
Para que serve?

O artigo busca identificar meios de amenizar as barreiras de comunicao na gesto de processos de software. No se tem a pretenso de esgotar o assunto, mas propor uma reflexo acerca do tema, levantado por diversos autores no campo da engenharia de software.

Na gesto e execuo de processos de software que necessitam de constantes adaptaes e integraes. Neste contexto, a comunicao entre usurio e analista costuma ser muito intensa, o que exige uma grande habilidade de comunicao interpessoal, principalmente por parte do analista de sistemas.
38
Engenharia de Software Magazine - A Comunicao no Processo de Software
PRoC E S S o
mudanas: seja porque o usurio decidiu realizar seu processo de maneira diferente, seja porque houve alguma alterao de leis ou normativas municipais, estaduais ou mesmo federais que regulamentam os requisitos do sistema. Num processo de software, tanto no desenvolvimento de um sistema novo quanto na manuteno de um sistema existente, as atividades relacionadas etapa de levantamento de requisitos representam um papel fundamental exatamente por constitu rem o alicerce para as fases subsequentes de desenvolvimento. O levantamento de requisitos, de acordo com Sommerville (2007), reflete as necessidades de um usurio e descrevem os servios que o sistema deve fornecer. Sendo assim, este no um pro cesso apenas tcnico, mas tambm social, uma vez que depende fortemente de um entendimento entre os atores envolvidos, no caso, o analista de sistemas e o usurio. Para Pressman (2006), o levantamento de requisitos uma atividade com comunicao intensiva. O autor refora a tese de que o rudo na comunicao entre usurio e analista pode acarretar muitas dificuldades para o desenvolvimento e/ou manuteno do sistema. Nesse sentido, necessrio estudar e compreender como ocorre o processo de comunicao a fim de buscar maneiras de minimizar as barrei ras da comunicao na gesto do processo de software.
O Processo de Comunicao
De acordo com Reti (2008), vivese em um mundo de lingua gens prprias. Podese falar o mesmo idioma, mas usamse diferentes linguagens. Por isso, s vezes, no h um entendimen to adequado. Em funo de cada indivduo ter caractersticas intrnsecas, grande parte das dificuldades de entendimento vem da forma como cada um interpreta os fatos e a comunicao. At as prprias palavras podem ter significado nico para cada uma das pessoas do processo de comunicao. A expresso no stress para o surfista um tipo de onda ruim porque no tem altura; para outros, significa estar numa boa. O processo de comunicao composto por cinco etapas, de acordo com Chiavenato (1994): Emissor ou fonte: a pessoa, coisa ou processo que emite a mensagem; Transmissor ou codificador: elo que liga a fonte ao canal, equipamento que transporta a mensagem codificada; Canal: espao entre transmissor e receptor por onde a men sagem trafega; Receptor ou decodificador: equipamento que recebe a mensagem e a decodifica. Se a comunicao oral, a recepo garantida por meio de uma boa audio; Destino: a pessoa, coisa ou processo para o qual a men sagem enviada. Existe ainda um elemento que deve ser acrescentado ao Processo de Comunicao: o rudo. O rudo uma interfern cia, um aspecto que prejudica a transmisso da mensagem e distorce o seu significado. Estimase que em todo o processo de comunicao exista rudo, em maior ou menor grau. Embora Chiavenato (1994) afirme que a comunicao um processo bidirecional e que necessita de um sinal de retroao ou
confirmao de recebimento, Griffin (2006) quem destaca a etapa de feedback no processo de comunicao. Tratase de um retorno com relao ao recebimento da mensagem: a certeza de que o receptor recebeu a mensagem e a compreendeu. Isso eliminaria a ocorrncia do rudo, tornando a comunicao eficaz. Apesar de parecer um processo simples, nem sempre, no en tanto, a mensagem enviada igual mensagem recebida. Isso s ocorre porque o processo de comunicao permeado ainda pelas caractersticas das pessoas envolvidas. De acordo com Chiavenato (1994), a comunicao uma troca composta por palavras, letras ou smbolos e engloba pensamentos, opinies ou informaes. Neste sentido, o processo de comunicao influenciado forte mente pela subjetividade humana, independente do ambiente em que ocorre ou da forma como se d. Do ponto de vista organizacional, segundo Griffin (2006), a comunicao tem o propsito de coordenar e orientar as metas propostas. Isso s possvel com a troca de informaes. Essa troca permite o entendimento do que deve ser feito e como. Griffin (2006, p.188) afirma ainda que: A comunicao organizacional expressa sentimentos e emoes. Por isso est longe de ser uma coleo de fatos e nmeros. Os funcionrios, como acontece em qualquer lugar do mundo, precisam comunicar emoes como felicidade, raiva, desprazer, confiana e medo. Para Chiavenato (1994), a comunicao nas organizaes difi cilmente ocorre sem problemas. O autor chama a ateno para o fenmeno da transformao que ocorre no decorrer desse proces so, que faz com que o receptor receba uma mensagem diferente daquela enviada pelo emissor. Essa transformao provocada por trs problemas principais, no entender do autor: Omisso: supresso de contedo da mensagem; Distoro: alterao do contedo da mensagem; Sobrecarga: incapacidade de processar o volume de informa es da mensagem, seja para o envio, seja para o recebimento provoca omisso e contribui para a distoro. Mas, alm desses problemas que transformam o processo de comunicao, Chiavenato (1994) destaca ainda as barreiras da comunicao, fatores que podem interferir nas etapas da comu nicao comprometendo o resultado final da mensagem enviada. So exemplos de barreiras da comunicao: ideias preconcebidas, significados pessoais, emoes, estado de nimo, entre outras. A especializao das pessoas nas organizaes , todavia, o fator que mais influencia a comunicao no tocante ao processo de software. Apontada como uma barreira da comunicao por Megginson (1998), a especializao pode formar grupos com interesses, comportamentos e at mesmo vocabulrio prprios. Tomese, por exemplo, uma das etapas mais crticas do Processo de software: o levantamento de requisitos. Imagine o analista de sistemas interagindo com o usurio, cada qual sintonizado nos seus conhecimentos tcnicos. No vai haver entendimento, no vai haver comunicao. Na concepo de Griffin (2006, p.192), a comunicao um processo social em que duas ou mais partes trocam informaes ou compartilham significados. Tratase de um processo de mo dupla e que acontece durante um certo tempo.
39
Sendo assim, para que ocorra comunicao e se alcancem os objetivos desta fase do processo de software, o usurio deve ser capaz de expressar suas necessidades numa linguagem que o analista de sistemas entenda e o analista de sistemas deve ser capaz de externar para o usurio o que entendeu.
O Processo de Software
Para Sommerville (2007, p. 42), um processo de software um conjunto de atividades que leva produo de um produto de software, no entanto, cada vez mais se aplica o desenvolvimento de software para customizar sistemas existentes. A Figura 1 ilustra o paradigma do ciclo de vida clssico da Engenharia de Software, conhecido tambm por modelo em cascata.
Anlise Requisitos Projeto Codificao Teste Manuteno
Projeto: definio da estrutura de dados do sistema, sua arqui tetura, detalhes procedimentais e caracterizao da interface; Codificao: implementao do sistema em linguagem de mquina; Teste: validao dos aspectos lgicos internos do software, bem como dos aspectos funcionais externos, a fim de garantir que o sistema atenda as especificidades; Manuteno: tratamento de erros encontrados e adaptao para novas funcionalidades. importante salientar que a ma nuteno de um sistema de informao reaplica cada uma das etapas precedentes do ciclo de vida ao sistema existente. De acordo com Pressman (2006), uma compreenso completa dos requisitos do sistema de informao fundamental para um bemsucedido desenvolvimento de sistema. No importa quo bem projetado ou quo bem codificado seja, o sistema mal especificado no atender as necessidades do usurio e trar aborrecimentos e retrabalho ao desenvolvedor. Essa constatao torna a etapa de levantamento de requisitos ex tremamente crtica para o sucesso do processo de software. Como o levantamento de requisitos est relacionado com a definio do que o sistema deve fazer, para Sommerville (2007), esta etapa pode ser descrita como o processo de comunicao entre usurio e analista e, nesse sentido, os requisitos podem ser influenciados pelas preferncias, recu sas e preconceitos dos usurios, alm de questes polticas e organizacionais. Essas diferenas de entendimento esto intimamente ligadas ao processo de comunicao, uma vez que a etapa de levantamento de requisitos decorre, basica mente, da interao entre analista de sistemas e usurio. importante salientar que essas preferncias, recusas e pre conceitos podem surgir tambm por intermdio do prprio analista de sistemas. Se, de um lado, o usurio afirma: No era bem isto que eu queria!, em contrapartida, muito co mum ouvir um analista de sistemas se queixar: O usurio no sabe o que quer!. A Tabela 1 lista alguns destes esteretipos mais comuns observados no relacionamento entre desenvolvedores de sistemas e usurios.
Como os usurios vem os desenvolvedores
Figura 1. Ciclo de vida clssico - Fonte: Pressman (2006, p. 33)
Nessa viso clssica, o desenvolvimento de software se d seguindo etapas predefinidas que no iniciam antes do tr mino da etapa anterior, muito embora, na prtica, observese que essas etapas se sobrepem e trocam informaes entre si. Pressman (2006) conceitua as etapas do ciclo da vida como: Anlise: definio dos servios e objetivos do sistema; Requisitos: descrio detalhada em linguagem natural do que o sistema deve fazer. Definem as funes, servios e restries operacionais do sistema (deve definir exatamente o que ser implementado);
Como os desenvolvedores vem os usurios Os usurios no sabem o que querem. Os usurios no conseguem articular o que querem. Os usurios tm muitas necessidades puramente polticas. Os usurios querem tudo imediatamente. Os usurios no sabem priorizar as necessidades. Os usurios se recusam a se responsabilizar pelo sistema. Os usurios so incapazes de fornecer uma declarao aproveitvel sobre suas necessidades. Os usurios no esto comprometidos com os projetos de desenvolvimento de sistemas. Os usurios no querem se comprometer. Os usurios no conseguem seguir o cronograma.
Os desenvolvedores no entendem as necessidades operacionais. Os desenvolvedores do muita nfase ao aspecto tcnico. Os desenvolvedores tentam nos dizer como fazer nosso trabalho. Os desenvolvedores no conseguem transformar as necessidades em um sistema bem-sucedido. Os desenvolvedores dizem no o tempo todo. Os desenvolvedores esto sempre ultrapassando o oramento. Os desenvolvedores esto sempre atrasados. Os desenvolvedores pedem aos usurios que dediquem seu tempo e esforo, mesmo que em detrimento de suas responsabilidades principais. Os desenvolvedores definem padres no-realistas para a definio de requisitos. Os desenvolvedores so incapazes de responder rapidamente a legtimas necessidades de mudana.
Tabela 1. Como usurios e desenvolvedores vem uns aos outros - Fonte: Pfleeger (2004, p. 142)
40
PRoC E S S o
A comunicao, neste contexto, fica bastante comprometida, uma vez que esta relao social s pode se concretizar se hou ver respeito mtuo, que surge da aceitao do outro. De acordo com Maturana (2001), sem a aceitao do outro na convivncia, no h fenmeno social. O usurio no pode ser um problema para o analista de sistemas: o usurio a sua razo de ser. Koscianski (2007) aponta ainda um dos problemas mais co nhecidos no processo de software: a negociao de requisitos entre usurio e analistas. Como a entrevista , provavelmente, a tcnica mais comum de levantamento de requisitos de siste mas, as dificuldades de comunicao durante a especificao de requisitos devem merecer ateno especial. A entrevista composta por questes sobre o sistema for muladas pelo analista de sistemas, derivando os requisitos das respostas dadas pelos usurios a essas questes. Essas entrevistas podem ser fechadas, respondendo os usurios a perguntas predefinidas; ou abertas, que no seguem um roteiro. As entrevistas abertas permitem uma compreenso maior acerca das necessidades do usurio, uma vez que o usurio pode discorrer livremente sobre as suas atividades de trabalho. Mas isso pode tornar o processo mais trabalhoso para o analista, que necessita de um grande poder de sntese para organizar essas informaes de forma estruturada. Alm disso, conforme Pressman (2006), frequentemente as informa es fornecidas por um usurio se confundem ou entram em conflito com outras informaes fornecidas por outros usurios envolvidos. Isso exige, em muitos casos, a utilizao de tcnicas adicionais nesta fase de levantamento de requisitos. Sommerville (2007) sugere as tcnicas de Cenrios e Casos de Uso. A tcnica de Cenrios caracterizase por uma descrio de exemplos de interao do mundo real que o sistema deve atender. A tcnica de Casos de Uso baseiase em cenrios e identifica o tipo de interao e quais agentes (sistema, usu rio, etc.) esto envolvidos. Usualmente essas tcnicas so utilizadas em conjunto e podem fazer toda a diferena para tornar a etapa de levantamento de requisitos mais eficaz. No obstante, todas as tcnicas resultam de alguma interao com o usurio. Assim, a comunicao algo inerente etapa de levantamento de requisitos e precisa ser bem resolvida, a fim de que o produto final de software atenda s necessidades do usurio no prazo estipulado. Como o desenvolvimento do software decorre principalmen te da etapa de levantamento de requisitos, importante que este mapeamento seja bem construdo. Dentre as vantagens da utilizao do modelo de desenvolvimento de software baseado no ciclo de vida clssico citase a documentao das etapas, o que gera maior consistncia para as fases subsequentes. No entanto, Sommerville (2007) aponta a diviso inflexvel de etapas como uma grande desvantagem, tendo em vista a dificuldade de reagir s mudanas inerentes do projeto. De terminadas diferenas de entendimento sobre o que o sistema deve contemplar podem ser descobertas apenas na etapa final de teste, o que obriga o retorno s fases iniciais de anlise e levantamento de requisitos para readequaes, alerta o autor. Verdadeiramente, podem ocorrer mudanas antes mesmo de
terminada a fase de levantamento de requisitos, o que pode comprometer todo o cronograma de um projeto. Num ambiente em que o desenvolvimento e a pronta entrega so as principais premissas para um sistema, o ciclo de vida clssico talvez no seja a metodologia mais adequada, sendo considerada um tanto burocrtica e pesada. Especialmente na dcada de 90, com a expanso da tecnologia nas pequenas e mdias empresas, essa situao comeou a se tornar invivel, o que levou alguns desenvolvedores de sistema a estudarem mtodos mais leves e rpidos. Mas foi em 2001 que alguns desenvolvedores, produtores e consultores de software assina ram o Manifesto para o Desenvolvimento gil de Software. Este manifesto declarava a descoberta por melhores modos de desenvolvimento de software, baseados em indivduos e suas interaes, softwares funcionais, colaborao do cliente e resposta a modificaes.
Desenvolvimento rpido de software, uma possvel soluo?

Os mtodos geis de software enfocam principalmente a especificao, o projeto e a implementao de software. So metodologias que envolvem o usurio em praticamente todas as fases do processo, garantindo assim que possveis mudanas nos requisitos possam ser corrigidas em tempo real. O foco nessas metodologias a comunicao interativa, pois no existe uma nica etapa em que usurio e analista interagem, mas vrias. Nesse contexto os usurios podem vir a comunicarse com toda a equipe de desenvolvimento, e no apenas com o analista, o que valoriza a cooperao entre usurios e desenvolvedores em detrimento do forte planejamento proposto pelo ciclo de vida clssico do processo de software. Sommerville (2007) aponta a Extreme Programming como o mtodo gil mais conhecido, citando ainda o Scrum, Crystal, entre outros. Todos esses mtodos possuem como caracterstica comum o desenvolvimento iterativo, propondo, no entanto, maneiras diferentes para o conseguir. Num desenvolvimento iterativo, cada iterao uma etapa do projeto de software. Assim, com o foco na comunicao entre usurios e analista/ desenvolvedores, o projeto vai sendo validado e incrementado a cada etapa. isso que garante que as mudanas no projeto sejam bemvindas e que o sistema seja entregue num prazo mais curto, de acordo com as necessidades do usurio. Um envolvimento maior entre usurio e analista de sistemas pode gerar maior compreenso acerca dos requisitos do sistema e desfazer possveis erros de interpretao. Alm disso, a con vivncia, por promover o companheirismo e a cooperao, pode diminuir a distncia tcnica entre esses profissionais, quebrando barreiras e preconceitos, resultando num produto que atende s necessidades do usurio e que proporcione maiores resultados empresa. O que fica evidente, no tocante comunicao, que o grande trunfo dos mtodos geis se d pelo envolvimento do usurio em todo o processo de software, e no apenas numa fase ini cial, a exemplo da metodologia do ciclo de vida clssico. No
41
Concluses
Para Pressman (2006), cabe ao analista de sistemas o papel de facilitador no processo de software, quando elenca algu mas capacidades bsicas que este deve possuir e que podem se resumir na habilidade de comunicarse, de entender e se fazer entender. Griffin (2006), no entanto, enxerga cada ele mento do processo de comunicao como parte fundamental: se um deles falhar, a mensagem pode no ser transmitida adequadamente. Por isso, para viabilizar a comunicao organizacional, importante que todas as pessoas envolvidas no processo de software, desde usurios at analistas e desenvolvedores, conheam o processo de comunicao, seu funcionamento e suas tcnicas. Habilidades de ouvir, falar e valorizar a pessoa com quem se comunica so importantes e devem ser promo vidas. Alm disso, devese procurar evitar os prjulgamentos decorrentes de mitos e preconceitos. Eles podem interferir fortemente nos relacionamentos interpessoais, causando os indesejveis rudos na comunicao. Outro aspecto do processo de comunicao que deve ser amplamente encorajado o feedback, por constituirse numa maneira de checar a compreenso das mensagens. Esse talvez
Referncias Bibliogrficas CHIAVENATO, Idalberto. Gerenciando pessoas: o passo decisivo para a administrao participativa. So Paulo: Makron Books, 1994. GRIFFIN, Ricky W.; MOORHEAD, Gregory. Fundamentos do comportamento organizacional. So Paulo: tica, 2006. KOSCIANSKI, Andr; SOARES, Michel dos Santos. Qualidade de software. So Paulo: Novatec, 2007. MATURANA, Humberto. Emoes e linguagem na educao e na poltica. Belo Horizonte: UFMG, 2001. MEGGINSON, Leon C.; MOSLEY, Donald C.; PIETRI Jr., Paul H. Administrao: conceito e aplicao. So Paulo: Harbra, 1998. PFLEEGER, Shari Lawrence. Engenharia de Software. So Paulo: Prentice Hall, 2004. PRESSMAN, Roger S. Engenharia de software. So Paulo: McGraw-Hill, 2006. RETI, Andra Huggard-Caine. O segredo de cuidar das pessoas: experincias do cotidiano para gerenciar melhor e aumentar o desempenho das equipes. Rio de janeiro: Elsevier, 2008. SOMMERVILLE, Ian. Engenharia de software. So Paulo: Pearson Addison-Wesley, 2007.
42
edio ta
entanto, importante ressaltar que essa interao maior com o usurio no garante a superao das barreiras de comuni cao, podendo at mesmo agravlas. Falhas e barreiras na comunicao podem fazerse presentes em qualquer momento de interao. Alm disso, caso o escopo no tenha sido bem especificado, correse o risco de no ter um sistema pronto nunca, uma vez que a cada iterao o usurio pode rever os requisitos e propor mudanas. Mas no necessrio escolher entre os mtodos geis e o ciclo de vida clssico. A agilidade no abstrai disciplina e processo no desenvolvimento de software. Sendo assim, uma alternativa considerar um modelo hbrido de processo de software que contemple certo planejamento, de acordo com o modelo de ciclo de vida clssico, aliado intensificao do envolvimento do usurio, proposto pelos mtodos geis. importante ainda salientar que a escolha do mtodo a ser utilizado no processo de software vai depender do tipo de sistema a ser desenvolvido. Os mtodos geis so perfeitos para pequenos sistemas ou pequenas adaptaes e integraes entre diferentes sistemas, no entanto, no se aplicam a siste mas complexos e crticos, nos quais so necessrias anlises detalhadas de requisitos e maior planejamento.
seja o maior aliado no processo de software, uma vez que permite que tanto o usurio quanto o analista de sistemas saiba se o que disseram um ao outro foi compreendido. Todas essas premissas no se constituem numa lista de pr requisitos bsicos para garantir a eficcia da comunicao num processo de software, mas podem servir como base na busca da superao das suas barreiras. E para isso no faz diferena a utilizao de mtodos geis ou a metodologia de ciclo de vida clssico: aumentar a interao com usurios pode significar aumentar as barreiras de comunicao, caso o processo de comunicao entre usurio e analistas de sis temas no seja eficaz. Nesse sentido, imprescindvel que toda e qualquer inte rao entre usurio e analista de sistemas prime pela clareza na comunicao, focada no respeito mtuo e aliada, princi palmente, prtica do feedback, independente do modelo de desenvolvimento de software adotado. D seu feedback sobre esta edio! A Engenharia de Software Magazine tem que ser feita ao seu gosto. Para isso, precisamos saber o que voc, leitor, acha da revista! D seu voto sobre este artigo, atravs do link:
Feedback eu
sobre e s
D s
Planejamento e Gerncia
Nesta seo voc encontra artigos voltados para o planejamento e gerncia de seus projetos de software
Anlise Quantitativa de Riscos e suas Tcnicas

Marcio Souza
mms3@cin.ufpe.br
Hermano Perrelli
hermano@cin.ufpe.br

Este artigo traz o aprofundamento na Gerncia de Riscos, detalhando a Anlise Quantitativa de Riscos e suas principais tcnicas, de acordo com a recomendao do Guia PMBOK, e mostra o resultado de um estudo comparativo destas tcnicas.
Lder de Equipes de desenvolvimento de software no Centro de Estudos e Sistemas Avanados do Recife (C.E.S.A.R). Mestre em Cincia da Computao pela Universidade Federal de Pernambuco e Graduado em Informtica pela Universidade Catlica do Salvador. membro dos grupos de pesquisa na rea de gerenciamento de projetos e engenharia de software, GP2 Project Management Research Group e PROMISE (Project Management Improvements in Software Engineering).
Atualmente professor Adjunto e Vice-Diretor do Centro de Informtica da Universidade Federal de Pernambuco. Consultor e instrutor da Qualiti Software Processes. Certificado PMP (Project Management Professional) pelo PMI. PhD In Computing Science pela University of Glasgow, Mestre em Informtica pela Universidade Federal de Pernambuco e graduado em Engenharia Eletrnica pela Universidade Federal de Pernambuco.
Para que serve?

Analisar as decises chaves na presena de incertezas; alertar, principalmente, os envolvidos de um projeto sobre riscos importantes antes de suas ocorrncias; e, traduzir os riscos em nmeros.
Cristine Gusmo
cristine.gusmao@nutes.ufpe.br
Graduada em Engenharia Eltrica (1993), mestrado (2001) e doutorado (2007) em Cincia da Computao pela Universidade Federal de Pernambuco. Professora adjunta da Universidade Federal de Pernambuco, com atividades na graduao e ps-graduao, lotada no Ncleo de Telessade, pesquisadora colaboradora do Grupo GP2 do Centro de Informtica (CIn - UFPE), coordenadora e pesquisadora do PROMISE (Project Management Improvements in Software Engineering) e colaboradora do Programa de Mestrado em Engenharia de Computao da Escola Politcnica de Pernambuco - Universidade de Pernambuco (POLI - UPE). membro da SBC. Tem experincia na rea de Cincia da Computao, com nfase em Engenharia de Software, atuando principalmente nos seguintes temas: Gerncia de Riscos de Projetos, Qualidade de Software, Gerncia de Projetos, Gesto de Sistemas de Sade, e-Health e Consultoria em Processos de Negcio.
Anlise Quantitativa de Riscos (AQR) um campo relativa mente novo, o qual tem cres cido rapidamente em diversas reas do conhecimento [Vose 2002]. Uma dessas reas tem sido o gerenciamento de projetos, cujas diversas abordagens dis ponveis consideram a anlise de riscos como um dos seus principais processos no contexto da gerncia de riscos de um projeto [Matias Jnior 2006]. A discusso sobre a anlise quanti tativa de riscos presume que etapas anteriores, tais como planejamento e identificao de riscos, tenham sido cumpridas. Desta forma, melhor

Auxiliar os envolvidos em um projeto, mais especificamente, o gestor de projetos, no processo de tomada de deciso.
conduzila aps a avaliao dos riscos, incluindo a priorizao dos mesmos, e garantir que todos os principais riscos podero ser considerados. Segundo David Hulett [Hulett 2004], a anlise quantitativa de riscos sempre recomendada para projetos grandes, complexos ou visveis, podendo ser
43
adaptada para projetos menores sempre que necessrio. Desta forma, ela tipicamente executada para examinar a viabilidade de custos e de prazo de um projeto, ou seja, analisar as decises chaves na presena de incertezas. Neste cenrio, a AQR prov respostas a trs questes que no podem ser respondidas atravs de metodologias de gerencia mento de projetos determinsticas, tais como estimativa de custo tradicional ou planejamento de projeto: Qual a probabilidade de alcanar o objetivo do projeto, dados todos os riscos conhecidos e quantificados? De quanto pode ser o atraso e quo necessria a contingn cia para o nvel de certeza desejado pela organizao? Onde est o maior risco, considerando o modelo do projeto e a totalidade de todos os riscos identificados e quantificados? A anlise qualitativa de riscos, uma das principais partes da avaliao de riscos, responde ltima pergunta, mas no pode estimar o total de risco do projeto, haja vista que cada risco examinado por vez [Hullet 2004]. Ento, a contribuio da Anlise Quantitativa de Riscos avaliar, simultaneamente, todos os riscos do projeto em relao ao seu custo total, ou a sua data final, bem como aos seus principais marcos. A AQR tem como objetivo global alertar ao gerente, cliente ou patrocinador do projeto a respeito de dois pontos princi pais: (1) se os objetivos gerais do projeto esto suficientemente em perigo para justificar o tratamento dos riscos, e (2) sobre riscos importantes antes das suas ocorrncias, o que lhes per mite desenvolver aes de mitigao de risco ou captura de oportunidades para tornar o projeto melhor. Uma dificuldade na concretizao deste objetivo ocorre porque, no incio do projeto, quando se pode tirar vantagem do tratamento dos riscos, os dados sobre o risco e, em particular, os modelos necessrios para a anlise quantitativa dos riscos no esto disponveis. Quando as estimativas de custos e prazos esto mais amadurecidas, e os dados mais conhecidos, a flexibili dade e o poder de afetar o projeto com alternativas tornamse restritos, pois mais decises tm de ser tomadas. Em algum ponto, durante a execuo do projeto, o objetivo principal da anlise quantitativa dos riscos fornecer estimativas precisas de onde o projeto resultar. Ainda de acordo com David Hulett [Hulett 2004], as principais entradas para a AQR so as distribuies de probabilidade dos custos ou das duraes da atividade (prazo). As distribuies da probabilidade so usualmente distribuies contnuas de valores possveis do elemento custo ou do prazo, desenvolvida atravs de entrevistas intensivas e anlise de desempenhos passados. A entrada tpica resultado do uso da estimativa de 3pontos, no qual o custo ou a durao representado pelo valor mais otimista (mais baixo, melhor), o valor mais prov vel para este projeto, e o valor pessimista (mais alto, pior). As distribuies mais comumente usadas so a: triangular, beta, uniforme, normal ou outros tipos de distribuies. O mtodo mais frequentemente usado na Anlise Quanti tativa de Riscos a simulao de Monte Carlo do modelo de custo ou prazo [Hulett 2004; Matias Jnior 2006]. A simulao
de Monte Carlo um mtodo antigo, com mais de cinquenta (50) anos, que combina as distribuies baseadas nos relacio namentos dos modelos, armazenando os resultados para serem mostrados posteriormente. As sadas so sempre mostradas graficamente, porm outras formas incluem listas de elemen tos de custos, que contm o maior risco (maior contribuio para a contingncia em relao ao custo total), ou atividades de tempo (atividades nos caminhos crticos, considerando o maior nmero de iteraes durante a simulao). Adicionalmente, a AQR inclui a Anlise por rvore de Deciso, a qual melhora a capacidade da organizao de to mar a deciso correta quando as implicaes das diferentes decises no podem ser preditas com certeza. A anlise por rvore de deciso envolve: especificao de todos os fatores e as implicaes de uma deciso, os custos e benefcios de to mar determinada deciso e as probabilidades associadas com cenrios incertos ou resultados que tenham um impacto na deciso e os seus resultados. A anlise por rvore de deciso, ento, computa o valor monetrio esperado (custo ou lucro) ou a utilidade esperada para a organizao das alternativas disponveis. A parte interessada utiliza os resultados para tomar decises quando a incerteza est presente. A Anlise Quantitativa de Riscos, atravs de suas tcnicas, avalia numericamente o efeito dos riscos identificados nos objetivos gerais do projeto [PMI 2004]. Ento, na prxima seo sero discutidas as principais tcnicas utilizadas no tratamento dos riscos.
As Tcnicas
As tcnicas quantitativas de anlise de riscos traduzem, ma tematicamente ou computacionalmente, o risco em nmeros. Essas tcnicas sempre provem probabilidades numricas ou as consequncias e o comportamento dos riscos identificados. Os valores utilizados nessas tcnicas so obtidos de bases de dados histricas ou so estimativas de esforo. No ltimo caso, contm um nvel de incerteza devido ao possvel uso de subjetividade relacionado aos valores [Baker et al. 1998; Padayachee 2001]. Nesse cenrio, as tcnicas mais comumente empregadas para a AQR e destacadas na literatura so: Entrevistas, Anlise de Sensibilidade, Anlise do Valor Monetrio Esperado, Anlise da rvore de Deciso e Simulao de Monte Carlo [Hulett 2004; PMI 2004; Almeida e Ferreira 2008].
Entrevistas
As entrevistas so realizadas, conforme Newton Nbrega [Nbrega 2007], de maneira anloga quelas que compem os mtodos de identificao de riscos, tendo como principal diferena a recomendao de se buscar, na fase de identifica o, dados qualitativos e quantitativos para os riscos. J na quantificao dos riscos, as entrevistas so realizadas com o objetivo de se quantificar a probabilidade e as conseqncias dos riscos sobre os resultados do projeto. O Project Management Institute [PMI 2004] destaca que a informao necessria vai depender do tipo de distribuio
44
Engenharia de Software Magazine - Anlise Quantitativa de Riscos e suas Tcnicas
PL ANEjAM ENTo
de probabilidades que usado. Se for utilizada a distribuio uniforme, devem ser colhidas informaes sobre o valor m ximo e mnimo para uma consequncia de um evento de risco, tal como citado anteriormente. No caso de uma distribuio triangular, seriam necessrias informaes sobre o cenrio otimista, pessimista e aquele mais provvel. As distribuies representam as probabilidades e as consequncias do compo nente do projeto. Por fim, a documentao do raciocnio (da anlise lgica) por detrs das extenses dos riscos um componente importante da entrevista sobre riscos, uma vez que pode gerar estratgias eficazes de respostas aos riscos.
detalhes, da seguinte maneira: impacto em relao ao cus to (Ic), impacto em relao ao empenho (Ie) e impacto em relao ao cronograma (Icr). Usando esta tcnica para todos os riscos, terse uma anlise para apresentar aos stakeholders do projeto e, consequentemen te, poder ser requerida uma reserva de contingncia para cobrir o impacto dos riscos, caso algum destes acontea. John Grass [Grass 2007] exemplifica essa situao (vide Tabela 1), conforme explanado posteriormente.
Risco A B C D E F Total Probabilidade de Impacto em termos de Reserva de Contingncia Ocorrncia (Pr) custo (Ic) para o Risco 80% R$ 10.000,00 R$ 8.000,00 30% 50% 10% 30% 25% R$ 30.000,00 R$ 8.000,00 R$ 40.000,00 R$ 20.000,00 R$ 10.000,00 R$ 118.000,00 R$ 9.000,00 R$ 4.000,00 R$ 4.000,00 R$ 6.000,00 R$ 2.500,00 R$ 33.500,00
Anlise de Sensibilidade
A Anlise de Sensibilidade uma tcnica utilizada para tomada de deciso que avalia a mudana de uma varivel dentro do projeto, analisando o resultado dessa variao sobre o seu planejamento inicial, e de grande importncia para a anlise de novos cenrios [Silva e Belderrain 2004; Almeida e Ferreira 2008]. Esta tcnica ajuda a determinar quais riscos apresentam maior impacto potencial no projeto, examinando a extenso com que a incerteza de cada elemento do projeto afeta o objetivo que est sendo examinado quando todos os outros elementos incertos so mantidos em seus valores de linha de base, impactando em prazos e custos [PMI 2004; Almeida e Ferreira 2008]. Desta forma, a aplicabilidade da anlise de sensibilidade caracterizada tanto na gesto de prazos quanto no retorno sobre o investimento. De uma maneira geral, utilizase a anlise de sensibilidade para tomar melhores decises, decidir quais dados estimados devem ser refinados antes de iniciar o processo de tomada de deciso e concentrarse nos elementos crticos durante a sua implantao. Por outro lado, o principal obstculo a no indicao da possvel ocorrncia de variao dos parmetros escolhidos na modificao da varivel em anlise, bem como considerar cada varivel como sendo independente.
Tabela 1. Representao da tcnica VME [Grass 2007]
Anlise do Valor Monetrio Esperado

O Valor Monetrio Esperado (VME) uma prtica de gern cia de riscos utilizada para ajudar a quantificar e comparar os riscos em vrios aspectos de um projeto. Tal como outras tcnicas de anlise quantitativa de riscos, o VME se baseia em nmeros especficos e quantificveis para a realizao de clculos ao invs de aproximaes e subjetivaes, tais como: alto, mdio e baixo. Nessa linha, o VME fundamentado em trs nmeros bsicos. So eles: probabilidade do risco ocorrer (Pr), pro babilidade do risco impactar o projeto se o mesmo ocorrer (PI) e impacto no projeto se o risco ocorrer (I). Em relao varivel PI, normalmente a maioria dos projetos no utilizam este componente de clculo, pois se supe que os riscos identificados tero a probabilidade de 100%, ou um valor bem perto de impactar o projeto. Quanto ao elemento impacto (I), o mesmo pode ser reclassificado, em maiores
Supondo a identificao de seis riscos no projeto, o impacto potencial de cento e dezoito mil reais (R$ 118.000,00). Entre tanto, no se pode solicitar toda essa quantia como reserva de contingncia, pois este nvel de reserva seria considerado para o caso de todos os riscos ocorrerem. Por isso, a reserva de contingncia respeitada avaliando o potencial do impacto dos riscos no projeto e a probabilidade dos mesmos acontecerem, sendo evidenciada na ltima coluna da Tabela 1. Percebese que a solicitao total da reserva de contingncia de trinta e trs mil e quinhentos reais (R$ 33.500,00), podendo ser adicionada ao oramento do projeto como uma poupana referente aos riscos. Se o risco C e o F ocorrerem, parte dessa reserva poder ser usada para cobrir o impacto. Porm, a ocorrncia do risco D impactar na reserva de contingncia, podendo no ser o suficiente para proteger o projeto e cobrir o impacto. Mesmo o risco D tendo apenas 10% de chance de incidncia, a equipe do projeto tem a obrigao de focar nesse risco para assegurar que o mesmo seja gerenciado com sucesso, ou seja, a equipe deve procurar minimizar o impacto atravs de um gerenciamento prativo do risco. No caso do gerenciamento de projetos mdios e grandes, faz sentido incluir algum tempo e oramento para riscos desco nhecidos. De acordo com John Grass [Grass 2007], existe uma comprovao na indstria de que uma reserva de contingncia de 5% pode ser adicionada ao projeto para tratar dos riscos que so desconhecidos no incio do projeto.
Anlise da rvore de Deciso

A rvore de Deciso consiste na determinao e visualizao grfica de caminhos que podero ser seguidos em um pro cesso de tomada de deciso [Pedro e Guerreiro 2004; Almeida e Ferreira 2008]. Essa tcnica estudada em vrios campos de pesquisa como cincias sociais, estatstica, engenharia e
45
inteligncia artificial, e aplicada desde o diagnstico de casos mdicos at avaliao de riscos na rea financeira. Segundo Raphael DCastro [DCastro 2009], como tcnica de computao inteligente e apresentando resultados extra ordinrios na tarefa de classificao, a anlise da rvore de deciso um candidato natural para auxiliar nos obstculos encontrados na gerncia de riscos. Na sua forma estrutural, Cliff Ragsdale diz que a rvore de deciso compese de ns (concebidos por crculos e quadrados representando, respectivamente, eventos aleatrios e decises) interconectados por ramos (representados por linhas), sendo que os ramos originados do n de deciso mostram as diferen tes alternativas para uma deciso particular [Ragsdale 2001], conforme ilustrado na Figura 1.
combinao escolha/probabilidade, representando os nveis ao extremo de cada n. Na construo de uma rvore de deciso, considerando os principais elementos defendidos por David Hillson, plausvel fazer uma avaliao para determinar a escolha mais adequada, ponderando custos, probabilidades e consequncias associa dos, baseandose na seguinte lgica: caminhase pela rvore de deciso, analisando cada percurso lgico alternativo; calcula se seu valor acumulando custos e benefcios do incio ao fim; utilizase este conjunto de valores e verificase o retorno de cada caminho lgico alternativo, obtendo o valor esperado de cada escolha (sempre ponderando as consequncias quando as probabilidades ocorrerem); por fim, o n possuidor do valor esperado mais alto, ser a opo de deciso recomendada. A existncia de alguns obstculos na utilizao das rvores de deciso merece ser citada. So eles: limitao prtica da tcnica (anlise de um baixo nmero de opes de deciso e riscos possveis); amplo modelo sem grande utilidade (tentativa de demonstrar em uma nica rvore, um projeto que envolve muitas decises em distintos nveis, associados a uma infini dade de riscos); e, necessidade de imparcialidade da pessoa responsvel por tomar a deciso fundamentada no valor espe rado mais alto [Gama 2002; Hillson 2005; DCastro 2009]. Apesar das limitaes citadas anteriormente, as principais vantagens da tcnica de rvore de deciso so a simplicidade, facilidade de interpretao, flexibilidade e ser um mtodo noparamtrico (no assume nenhuma distribuio parti cular para os dados e pode construir modelos para qualquer funo, desde que o nmero de exemplos de treino seja sufi ciente) [Gama 2002; Clarke e Bittencourt 2003; Hillson 2005; Almeida e Ferreira 2008].
Figura 1. Exemplificao de uma rvore de deciso [Ragsdale 2001]
De uma maneira geral, os ramos da rvore correspondem a cada possibilidade lgica que leva prxima possibilidade ou ao a ser tomada. Nem sempre a combinao das condies descritas leva a uma ao definitiva. Quando isto ocorre, o decisor tem o papel de optar pela melhor ao a ser tomada. As folhas, situadas no final dos ramos, exibem os caminhos aos quais uma deciso pode levar. Essas folhas terminais so representadas, normalmente, por traos verticais, indicando ponto final, ou por tringulos. Neste panorama, David Hillson afirma que a anlise da rvore de deciso baseiase em quatro elementos fundamentais: esco lha, probabilidade, custos e consequncias [Hillson 2005]: Escolha: primeiro passo na construo da rvore de deci so. Identifica as opes a serem escolhidas para alcanar os objetivos, sendo que essas escolhas definem os ns de deciso da rvore. Probabilidade: na existncia de incerteza, devese identificar e avaliar a probabilidade estimada de cada resultado, por ser uma importante varivel associada com os diversos caminhos de decises diferentes. Custos: fator mais simples associado s escolhas alternativas. Ao se fazer uma escolha, sempre existe um custo relacionado e uma estimativa deve ser includa em cada n da rvore de deciso. Consequncias: resultado da implementao de uma deciso, considerando seus custos e riscos. Desta forma, a estrutura da rvore de deciso apresenta o resultado presumido de cada
Simulao de Monte Carlo

O mtodo de Monte Carlo uma das tcnicas do processo de Anlise Quantitativa de Riscos, sendo recomendado para a anlise de riscos de cronograma e de custos [Galvo 2005]. Seu algoritmo um processo de simulao que repetido vrias vezes, sendo gerados, em cada iterao, possveis valores para as duraes das atividades [Lima et al. 2008]. Desta forma, a rede do projeto montada baseada nesses valores, obtendo uma aceitvel data final do projeto. Adicionase a isto que, na anlise de cronograma utilizado o Mtodo de Diagrama de Precedncia (PDM) e, na anlise de custos, empregase a Estrutura Analtica de Trabalho (EAP) [Nbrega 2007]. A EAP uma maneira de decompor o projeto em componentes facilmente gerenciveis. Desta forma, o proje to acaba transformado em grupos principais de trabalho, onde esses so reduzidos a tarefas, subtarefas, e assim sucessivamen te, at que se chegue num nvel de granularidade necessria e entendvel para finalizar um projeto especfico. O nome Monte Carlo surgiu no decorrer do projeto Manhat tan, na Segunda Guerra Mundial, devido ao fato da cidade de Monte Carlo, capital de Mnaco, local de famosos cassi nos, ser uma importante referncia em jogos de azar e cujo
46
PL ANEjAM ENTo
funcionamento possuir certa similaridade com o processo de simulao estatstica [Gujarati 2002; Galvo 2005; Matias Jnior 2006]. O mtodo de Monte Carlo um procedimento indutivo que permite tomada de decises de forma mais consistente, ou seja, as respostas obtidas da sua aplicao no so binrias, mas sim estabelecidas em termos probabilsticos [Smith 1973]. Ento, essa tcnica admite determinar uma gama de cenrios possveis para a concluso do projeto, expondo, desta forma, a probabilidade de ocorrncia de cada cenrio. Para a determinao destes cenrios e considerando a inci dncia de riscos, utilizamse distribuies de probabilidades ao invs do uso de estimativas nicas, sendo as distribuies a base para o processo de simulao. Uma distribuio de probabilidades representada matemati camente por uma funo f, chamada funo densidade de pro babilidade, cujo grfico mostra as possibilidades de ocorrncia dos resultados possveis de um evento. Existem diversos tipos de distribuies de probabilidades que so oferecidas por software especializado para anlise de riscos e que podem ser utilizadas para representar as incertezas nos valores das duraes das atividades ou outros parmetros do projeto. So elas as distribuies Beta, Binomial, Exponencial, Gamma, Lognormal, Normal, PERT, Poisson, Student, Trian gular e Uniforme. Vale destacar que, por no existir, normalmente, uma base real para a escolha das distribuies, elas so selecionadas arbitra riamente [Conrow 1998]. Porm, motivos histricos e entrevistas com especialistas podem ser artifcios para determinar a distri buio de probabilidade especfica para o projeto.
Concluso
A Entrevista, mesmo no contexto da anlise quantita tiva, uma tcnica bastante subjetiva, pois se baseia, na maioria das vezes, nas experincias vivenciadas pelos entrevistados. Em alguns poucos casos, os entrevista dos fundamentam suas opinies em dados histricos de projetos, quando guardados. Como ponto relevante desse processo, a possibilidade de determinar, quan titativamente, a probabilidade e as consequncias dos riscos sobre os resultados do projeto atravs de diferentes pontos de vistas. A tcnica de Anlise de Sensibilidade, mesmo aplicada em uma variedade de contextos [Aggarwal et al. 2005; Do e Rothermel 2008; Harman et al. 2009], ainda precisa de uma pesquisa mais minuciosa na gesto de prazos [Almeida e Ferreira 2008]. De qualquer sorte, a anlise de sensibilidade avalia, independentemente, a mudana de uma varivel, comparandoa com o seu planejamento inicial, haja vista que as variveis so isoladas. Desta forma, permite decidir quais dados precisam de refina mento antes de iniciar o processo de tomada de deciso, concentrandose nos elementos crticos durante a sua implantao. J a anlise do Valor Monetrio Esperado consegue estabelecer uma reserva de contingncia para cobrir o impacto dos riscos que possam ocorrer, pois considera todos os possveis resultados, evitando assim, a simples combinao de todos os melhores e piores casos. A limi tao da tcnica que a mesma proporciona melhores resultados quando utilizada ao longo de muitos projetos de porte semelhante, com um nmero de riscos conside rvel [Loosemore et al. 2006]. Ou seja, quanto mais riscos forem identificados, maior ser a distribuio da reserva de contingncia entre os riscos envolvidos. Entre as tcnicas de anlise quantitativa de riscos, a anlise da rvore de Deciso apresenta diversas vanta gens, conforme mostrado na Tabela 2. A simplicidade, facilidade de interpretao e a visualizao grfica das alternativas a serem seguidas, capacitam os envolvi dos no processo de tomada de deciso, a entender o
Desvantagem Dependncia da informao obtida com o entrevistado.
Anlise Comparativa das Tcnicas

Na Tabela 2 so tratadas as vantagens e desvantagens das principais tcnicas de anlise quantitativa de riscos mostradas na seo anterior de forma sinttica. Todas as tcnicas estudadas pregam o auxlio em processos de tomada de deciso, oferecendo resultados numricos mais reais sobre os resultados do projeto. Acrescentese a isso o fato de elas serem aplicadas, principalmente, na gesto de prazos (cronograma) ou na de custos, ou em ambas.
Tcnica Entrevistas Anlise de Sensibilidade Vantagem Tm diversas vises de profissionais com experincias distintas.
No indicao da variao de parmetros que se relacionam com uma determinada varivel analisada e ausncia de estudo mais detalhado da aplicao da tcnica junto gesto de prazos. Anlise do VME Consegue estabelecer uma reserva de contingncia para cobrir o impacto dos riscos, caso ocorram. Apresenta melhores resultados quando utilizada com muitos projetos de porte semelhante e com um nmero de riscos suficientes [Loosermore et al. 2006]. Anlise da rvore de Deciso Visualizao grfica dos caminhos a serem seguidos, simplicidade, facilidade de interpretao, flexibilidade, Dificuldade na apresentao dos resultados quando se tem um mtodo no-paramtrico, utilizao numa gama de reas de pesquisa e combinao com outras tcnicas cenrio de possibilidades muito pequeno ou muito amplo. de tomada de deciso. Simulao de Monte Carlo Processo de simulao repetido inmeras vezes durante uma iterao, obteno de respostas no binrias e Aleatoriedade na escolha das distribuies de probabilidade e possibilidade de estudar as consequncias da tomada de deciso sem executar o projeto [Nbrega 2007]. demanda de tempo para sua aplicao. Tabela 2. Vantagens e Desvantagens das principais tcnicas da AQR
Avalia, independentemente, a mudana de uma varivel, comparando-a com o seu planejamento inicial.
47
Referncias [Aggarwal et al. 2005] Aggarwal, K. K., Singh, Y., Chandra, P. e Puri, M. (2005) Sensitivity analysis of fuzzy and neural network models SIGSOFT Softw. Eng. Notes, ACM, 30, 1-4. , [Almeida e Ferreira 2008] Almeida, E. P. e Ferreira, M. L. R. (2008) Tcnicas de Anlise de Risco Aplicadas Planejamento e Programao de Projetos da Construo Civil IV Congresso Nacional , de Excelncia em Gesto: Responsabilidade Socioambiental das Organizaes Brasileiras, Niteri, RJ, Brasil, 31 de julho, 01 e 02 de Agosto. [Baker et al. 1998] Baker, S., Ponniah, D. e Smith, S. (1998) Techniques for analysis of risks in major projects Journal of the Operations Research Society, 49, pp567-572. , [Clarke e Bittencourt 2003] Clarke, Robin T. e Bittencourt, Hlio R. (2003) Uso de rvores de Deciso na Classificao de Imagens DigitaisXI SBSR, Belo Horizonte, Brasil, 05-10 de Abril, INPE, p. 2043 - 2045. , [Conrow 1998] Conrow, Edmund H.(1998)Some Limitations of Quantitative Risk Analysis Approaches Used in Project ManagementInvited paper by the Office of the Secretary of Defense, April. , [DCastro 2009] DCastro, Raphael J. (2009) Avaliao de Riscos em Projetos de Software a partir do Uso de Tcnicas de Inteligncia ComputacionalTrabalho de Concluso de Curso, Departamento de , Sistemas e Computao, Engenharia da Computao, Universidade de Pernambuco, Junho. [Do e Rothermel 2008] Do, H. e Rothermel, G. (2008) Using sensitivity analysis to create simplified economic models for regression testing ISSTA 08: Proceedings of the 2008 international , symposium on Software testing and analysis, ACM, 2008, 51-62. [Galvo 2005] Galvo, Mrcio (2005) Anlise Quantitativa de Riscos com Simulao de Monte Carlo Revista Mundo PM, Project Management, Nmero 05, Out./Nov., Ano 1. , [Gama 2002] Gama, Joo (2002) rvores de Deciso Laboratory of Artificial Intelligence and , Decision Support, University of Porto, Portugal, Disponvel em: http://www.liaad.up.pt/~jgama/ Aulas_ECD/arv.pdf, Acesso em: 9 ago. 2009. [Grass 2007] Grass, John (2007)Valor Monetrio Esperado (VME)The ICPM Project Management , Community, Disponvel em: http://www.theicpm.com/index.php?option=com_content&view=art icle&id=2772:valor-monetario-esperado-vme&catid=82, Acesso em: 08 ago. 2009. [Gujarati 2002] Gujarati, D. N. (2002) Econometria bsica 3 edio, Makron Books, So Paulo. , [Harman et al. 2009] Harman, M., Krinke, J., Ren, J. e Yoo, S. (2009) Search based data sensitivity analysis applied to requirement engineering GECCO 09: Proceedings of the 11th Annual , conference on Genetic and evolutionary computation, ACM, 1681-1688. [Hillson 2005] Hillson, David (2005)Using Decision TreesRisk Doctor Briefing,The Risk Doctor, Disponvel , em: http://www.risk-doctor.com/pdf-briefings/risk-doctor18e.pdf, Acesso em: 10 abr. 2009. [Hullet 2004] Hulett, David (2004) Quantitative Risk Analysis Fundamentals Defense Acquisition , University, Disponvel em: https://acc.dau.mil/CommunityBrowser.aspx?id=19270, Acesso em: 25 abr. 2009. [Lima et al. 2008] Lima, E. C. P., Viana, J. C., Levino, N. A. e Mota, C. M. M. (2008) Simulao de Monte Carlo Auxiliando a Anlise de Viabilidade Econmica de Projetos IV Congresso Nacional de , Excelncia em Gesto: Responsabilidade Socioambiental das Organizaes Brasileiras, Niteri, RJ, Brasil, 31 de julho, 01 e 02 de Agosto. [Loosermore et al. 2006] Loosemore, Martin, Raftery, John, Reilly, Charlie e Higgon, Dave (2006) Risk Management in Projects 2nd Edition, Taylor & Francis, New York, USA. , [Matias Jnior 2006] Matias Jnior, R. (2006) Anlise Quantitativa de Risco Baseada no Mtodo de Monte Carlo: Abordagem PMBOK Congresso Brasileiro de Gerenciamento de Projetos, 29 a 31 , de Maro, Florianpolis. [Nbrega 2007] Nbrega, Newton C. M. (2007) Um Estudo Terico da Avaliao de Riscos em Projetos de Investimento em Organizaes Monografia para a graduao em Engenharia de , Produo, Universidade Federal de Juiz de Fora, Novembro. [Padayachee 2001] Padayachee, Keshnee (2001) Techniques Used in Risk Analysis of Software Development University of South Africa. , [Pedro e Guerreiro 2004] Pedro, Lucilene M. e Guerreiro, Reinaldo (2004)Aplicao de rvores de Deciso na Anlise FinanceiraIn: 4 Congresso USP de Controladoria e Contabilidade, So Paulo, v.1, p.0-0. , [PMI 2004] PMI, Project Management Institute. (2004) A Guide to the Project Management Body of Knowledge ANSI/PMI 99-01-2004, Four Campus Boulevard, Newtown Square, USA. , [Ragsdale 2001] Ragsdale, Cliff T. (2001) Spreadsheet modeling and decision analysis: a practical introduction to management science 3rd, Cincinnati, Ohio, South-Western College Pub. , [Silva e Belderrain 2004] Silva, Roterdan M. e Belderrain, Mischel C. N. (2004) Consideraes sobre Anlise de Sensibilidade em Anlise de Deciso Instituto Tecnolgico de Aeronutica, Diviso de , Engenharia Mecnica-Aeronutica, Relatrio de Iniciao Cientfica, 44p, CNPq. [Smith 1973] Smith, Kerry (1973) Monte Carlo Methods,Their Role for EconometricsLexinton Books. , [Vose 2002] Vose, David (2002) Risk Analysis: a quantitative guide 2nd Edition, UK, John Wiley , & Sons, 418 p.
48
edio ta
procedimento aps uma breve explanao. Tambm, no assume nenhuma distribuio especial e capaz de esta belecer modelos para qualquer finalidade, desde que tenha informao necessria de treino. Como obstculo, oferece dificuldades na apresentao dos resultados quando as possibilidades so extremas, em termos de quantidade. Por ltimo, a Simulao de Monte Carlo, prtica comum e difundida no Project Management Body of Knowledge [PMI 2004], quando se usa simulao. Esta tcnica gera cenrios presumveis, sem que exista a necessidade de executar o projeto. Como barreira, demanda tempo, pois precisa ser
executada mais de uma vez. Ademais, no existe uma lgica ou regra para a determinao das distribuies utilizadas, consistindo estas em escolhas aleatrias do responsvel pela execuo e anlise do mtodo. D seu feedback sobre esta edio! A Engenharia de Software Magazine tem que ser feita ao seu gosto. Para isso, precisamos saber o que voc, leitor, acha da revista! D seu voto sobre este artigo, atravs do link: www.devmedia.com.br/esmag/feedback
D s
Feedback eu
sobre e s
Desenvolvimento
Nesta seo voc eNcoNtra artigos voltados para difereNtes
abordageNs de apoio ao deseNvolvimeNto de projetos de software
Automatizando Testes Funcionais em Aplicaes Web

Utilizando a Ferramenta Selenium para execuo de Testes Funcionais
Neste artigo iremos apresentar a implementao de uma estratgia de teste funcional utilizando uma ferramenta, Selenium IDE, para automao da execuo e re-execuo dos testes.
Para que serve?

O artigo demonstra na prtica a ferramenta Selenium IDE para automao de teste funcional usando uma estratgia de teste do tipo capture-replay, contextualizada ao domnio de aplicaes web.

O tema til para os desenvolvedores e engenheiros de software que planejam aplicar a automao de testes no desenvolvimento de aplicaes web.
Arilo Cludio Dias Neto

ariloclaudio@gmail.com
Doutor em Engenharia de Sistemas e Computao formado na COPPE/UFRJ e possui o certificado de Implementador do modelo MPS. Possui 7 anos de experincia em anlise, desenvolvimento e teste de software. editor tcnico da Revista SQL Magazine, gerenciada pelo Grupo DevMedia.
os artigos anteriores escri tos para a ES Magazine, nos preocupamos em discutir os conceitos bsicos sobre Teste de Sof tware e apresentar uma estratgia que possibilita a gerao de casos de teste de software a partir de casos de uso j especificados. Tal estratgia seria apli cada no nvel de teste de software, re presentando um tipo de tcnica de teste
funcional, onde o sistema tratado em uma viso macroscpica e sua avaliao feita sem considerar detalhes internos de implementao. No entanto, apesar de ser totalmente vivel, a aplicao desta estratgia de teste quando realizada manualmente representa um grande esforo para um projeto de software. Com isso, pensar em mecanismos para automao dos testes
49
consiste em pensar em mecanismo para reduzir o esforo desta atividade no contexto geral de um projeto de software. importante termos em mente que automao por si s no resulta em reduo de esforo nos testes ou aumento da qualidade desta atividade. A automao simplesmente torna automtica algumas tarefas do processo de testes, mas ela no faz milagres. Como assim? Uma ferramenta de testes apenas automatiza o nosso conhecimento tcnico sobre teste de sof tware. Sendo assim, se no tivermos conhecimento tcnico adequado sobre teste de software, o conjunto de casos de teste gerado para avaliar nosso sistema no ter cobertura ou qualidade suficiente, de forma que a ferramenta ir apenas automatizar a execuo do conjunto de testes inadequados, ou seja, no termos qualquer ganho com isso. Se tivermos um processo de teste bem definido e um bom co nhecimento sobre estratgias de teste, a automao pode trazer grandes benefcios a um projeto de software. Nesse contexto, neste artigo iremos apresentar a implementao de uma estra tgia de teste funcional apresentada no artigo Planejamento de Testes a partir de Casos de Uso publicado na edio 6 da ES Magazine utilizando uma ferramenta, Selenium IDE, para automao da execuo e reexecuo dos testes.
Teste funcional representa uma categoria de tcnicas de teste em que o componente de software a ser testado abor dado como se fosse uma caixapreta, ou seja, no se consi dera o comportamento interno do mesmo (Figura 1). Dados de entrada so fornecidos, o teste executado e o resultado obtido comparado a um resultado esperado previamente conhecido. Haver sucesso no teste se o resultado obtido for igual ao resultado esperado. O componente de software a ser testado pode ser um mtodo, uma funo interna, um programa, um componente, um conjunto de programas e/ ou componentes ou mesmo uma funcionalidade. A tcnica de teste funcional aplicvel a todos os nveis de teste, seja teste de sistema, aceitao, integrao ou unidade.
Figura 1. Tcnica de Teste Funcional (caixa-preta)
Estratgias de Teste de Software

Durante o desenvolvimento de um software, diversas estratgias para teste podem ser aplicadas. De acordo com PRESSMAN (2005), essas estratgias podem ser categorizadas da seguinte forma: Baseadas em implementao: utiliza o cdigo como elemento para a gerao dos testes. uma atividade cara, sob o ponto de vista de recursos necessrios para a sua realizao, e bastante complexa quando o tamanho do cdigo se torna bastante gran de. totalmente dependente de apoio ferramental; Baseadas em especificao: utiliza um documento de espe cificao como base para gerao dos testes. Assim, tentase cobrir as imposies e restries descritas nos requisitos esta belecidos para o sistema. A automao da gerao dos testes nesse caso mais complicada, caso no se tenha um formalis mo para a elaborao da especificao do sistema; Baseadas em modelos: uma subcategoria de estratgias baseada em especificao. Utiliza modelos desenvolvidos ao longo do processo de desenvolvimento que representam o com portamento ou estrutura do software como base para a gerao dos testes. Facilita a gerao automtica dos testes, porem completamente dependente da facilidade para a construo do modelo adotado e de sua qualidade (corretude). Cada estratgia apresentada possui sua aplicabilidade, van tagens e desvantagens. No propsito deste artigo discutir qual seria a estratgia mais adequada. Ao longo deste artigo iremos adotar uma estratgia de gerao de testes baseada em especificao, representada pelos casos de uso de um sistema. Assim, partiremos desta informao para a gerao de casos e procedimentos (roteiros) de teste, seguindo uma estratgia de teste funcional.
Um dos mecanismos para facilitar a realizao de testes funcionais pensar na automao de algumas tarefas que compem o processo de testes. Esse o assunto da prxima seo.
Automao dos Testes

Automao dos testes consiste no uso de algum apoio com putacional, ferramentas, para controlar a execuo dos testes, a comparao dos resultados e comportamentos obtidos com a execuo dos testes em relao aos resultados e compor tamentos esperados, a configurao das prcondies dos testes e outras atividades do controle dos testes e relato de seus resultados (KALOWA e HUIZINGA, 2007). Comumente, a au tomao dos testes envolve automatizar um processo manual j estabelecido em uma organizao que utiliza um processo de testes formalizado. Apesar de os testes manuais poderem encontrar muitos de feitos em um software, essa tarefa complexa, desgastante e consome muito tempo. Alm disso, ela pode no ser to efetiva em revelar alguns tipos de falhas em um software. A automao dos testes um processo de escrever um pro grama computacional para realizar testes que, caso contrrio, seriam feitos manualmente. Uma vez que os testes foram automatizados, eles podem ser executados rapidamente, logicamente que proporcionalmente quantidade de casos de teste a serem executados. Este representa, na maioria dos casos, o mtodo de teste com custo mais efetivo para produtos que possuem uma longa vida, com muitas manutenes, pois pequenas modificaes em certas partes do software ao longo de sua vida podem fazer com que outras partes do software que estariam funcionando anteriormente deixem de funcionar. Existem duas abordagens gerais para automao dos testes: Testes dirigidos a cdigo: as interfaces para classes, mdu los ou bibliotecas so testadas com uma larga variedade de argumentos de entrada para validar se os resultados que esto sendo retornados esto corretos;
50
Engenharia de Software Magazine - Automatizando Testes Funcionais em Aplicaes Web
Teste de Interface (em ingls, Graphical User Interface, ou simplesmente GUI): um framework de teste gera eventos de interface do usurio tais como digitao de teclas ou cliques do mouse, e observa as mudanas que ocorrem na interface do usurio. Assim, podemos validar se o comportamento obser vado do software aps tais eventos esto corretos. Uma forma de gerar casos de teste automaticamente utili zando a estratgia de Teste Baseado em Modelos (ver Nota DevMan), que adota modelos representando o sistema para gerao de casos de teste, porm existem outras estratgias interessantes. O qu automatizar, quando automatizar ou at mesmo se necessrio de fato automatizar so decises cruciais que a equi pe de teste deve tomar. Selecionar as funcionalidades corretas do software para automao um fator essencial para deter minar o sucesso da automao. Automatizar funcionalidades instveis ou funcionalidades que esto sofrendo alteraes constantes deve ser evitado (MARICK, 2010). Neste artigo, iremos focar apenas em teste de interface, como veremos com mais detalhe na continuidade deste artigo.
Nota do DevMan
Teste Baseado em Modelos Teste Baseado em Modelos (TBM) consiste em uma estratgia de teste na qual casos de teste so derivados totalmente ou parcialmente de um modelo que descreve algum aspecto (ex: funcionalidade, segurana, desempenho, etc.) de um software (UTTING e LEGEARD, 2007). Para sua utilizao, necessrio que o comportamento ou estrutura do software (ou parte deles) tenha sido formalizado atravs de modelos com regras bem definidas (ex: mtodos formais, mquinas de estado finito, diagramas UML, dentre outros). A estratgia de TBM normalmente inclui diferentes nveis de abstrao, um modelo comportamental/estrutural do software, o relacionamento entre modelos e cdigo, uma tecnologia para gerao dos casos de teste, a importncia dos critrios de seleo dos testes (algoritmos para gerao dos casos de teste) e uma discusso do que pode ou no ser automatizado durante os testes (PRETSCHNER, 2005).
Importncia da Automao dos Testes

Uma das principais caractersticas das atividades de teste de software, assim como a atividade de desenvolvimento de software em geral, o fato de ser realizada por pessoas, e consequentemente passvel de erros. A famosa frase errar humano o fato que nos leva a desejar testes automatizados. Diversos problemas relacionados aos testes a serem aplicados em um software podem ser evitados a partir da automao desta atividade, dentre os quais: Dados de entrada de teste incorretos, informando valores ou tipos de dados invlidos; No perceber um comportamento incorreto do software a um certo evento; Reportar os resultados dos testes incorretamente; Esquecer de executar alguns casos de teste; Esquecer de executar alguma prcondio para execuo dos testes; Alterao na execuo da sequncia de casos de teste, o que poderia levar a execuo dos testes a um fracasso. Alm de evitar os problemas causados por eventuais falhas humanas, a automao dos testes pode ainda nos proporcionar: Uma forma de armazenar conhecimento sobre o domnio do projeto ou sobre as funcionalidades que compem o sistema, minimizando a dependncia pelas pessoas que compem o projeto; Garantir a acurcia dos relatrios de teste, pois so ge rados de forma automtica e sempre seguindo um mesmo padro; Velocidade na execuo dos testes, pois uma vez projetado, sua execuo automtica e pode no depender de interven o humana;
Realizar teste em momentos especficos e sempre que necessrio, por exemplo, podemos optar por sempre exe cutar os testes a cada modificao no sistema com um esforo baixo, pois os testes j estariam prontos para serem executados; Simplificao nos testes de regresso, pois os testes podem ser repetidos sempre que a equipe de teste julgar necessrio com pouco esforo; Possibilidade de testar o sistema com diferentes conjuntos de dados, pois o processo de gerao e/ou execuo reali zado por um computador, de forma que mais simples gerar e utilizar nos testes diferentes combinaes de dados. Na seo seguinte iremos focar no tipo de automao de teste que iremos seguir neste artigo: teste de interface.
Teste de Interface (Graphical User Interface [GUI] Testing)

Muitas ferramentas de automao provm funcionalidades de gravar a execuo de um software e rodar esta gravao que permitem aos usurios interativamente filmar as aes do usu rio e repetila quantas vezes quiser, comparando os resultados e comportamentos obtidos com aqueles esperados. A vantagem desta abordagem, chamada capture-replay, que ela requer pouco ou nenhum desenvolvimento de software. Nesta abordagem, uma ferramenta de teste grava as entradas de teste como se estivesse sendo submetido ao software que est sendo testado. Os casos de entrada armazenados podem ento ser usados para reproduzir os testes posteriormente. Esta abordagem pode ser aplicada a qualquer aplicao que possua uma interface de usurio grfica. No entanto, a dependncia dessas funcionalidades representa mais problemas de confiabilidade e manutenibilidade. Alterar o nome de um boto ou movlo para outra parte da tela pode requerer que os testes tenham que ser regravados. A abordagem capture-replay tambm muitas vezes acrescenta atividades irrele vantes ou registra incorretamente algumas atividades. Isso so limitaes reais desta abordagem, mas ainda assim ela possui bastante aplicabilidade em projetos de software.
51
Nome HP QuickTest Professional IBM Rational Functional Tester Rational robot Selenium SilkTest TestComplete TestPartner Watir HP
Empresa IBM Rational IBM Rational Ferramenta opensource Borland AutomatedQA Micro Focus Ferramenta opensource
URL https://h10078.www1.hp.com/cda/hpms/display/main/hpms_content.jsp?zn=bto&cp=1-11-127-24^1352_4000_100__ http://www-01.ibm.com/software/awdtools/tester/functional/index.html http://www-142.ibm.com/software/products/br/pt/robot/ http://seleniumhq.org/ http://www.borland.com/br/products/silk/silktest/index.html http://www.automatedqa.com/products/testcomplete/ http://www.microfocus.com/products/TestPartner/index.asp http://watir.com/ http://www.opensourcetesting.org/
Site com diversas outras ferramentas Ferramenta opensource
Tabela 1. Ferramentas de Automao de Testes de Software mais populares
Uma variao deste tipo de ferramenta seriam as ferra mentas para teste de aplicaes web. Neste caso, a inter face so as pginas web. Este tipo de ferramenta tambm requer pouco ou nenhum desenvolvimento de software. No entanto, o framework para testes pode utilizar diferen tes tcnicas pois ele est lendo HTML em vez de eventos de janela de aplicaes. Por fim, outra variao de automao de testes sem scripts que no usa a ideia de capturereplay, em vez disso constri um modelo da aplicao a ser testada e ento permite ao testador criar casos de teste simples mente editando os parmetros e condies de teste. Esta abordagem pode ser aplicada a qualquer software baseado em interfaces. As ferramentas de automao de teste mais conhecidas podem ser caras, apesar de j existirem diversas ferramen tas gratuitas e com um bom conjunto de funcionalidades de apoio automao dos testes. Por isso, importante realizar uma anlise de custobenefcio no momento de escolher as ferramentas a serem aplicadas em um projeto. A Tabela 1 apresenta uma lista com algumas das ferra mentas de automao mais utilizadas. Neste artigo, utilizaremos a ferramenta Selenium IDE para automao de teste funcional usando uma estratgia de teste do tipo capturereplay, porm contextualizada ao domnio de aplicaes web.
5. Possibilita configurar depurao e pontos de paradas para verificao durante os testes; 6. Permite salvar os testes como HTML, scripts em Ruby ou outro formato. A partir da prxima seo passaremos a usar Selenium em um estudo de caso real.
Estudo de Caso: Americanas.com

Neste artigo, realizaremos um teste para uma das opes disponveis no site amerianas.com, o cadastro de um novo cliente realizado no endereo https://carrinho.americanas.com.br/portal/ meuCadastro.portal. O cadastro de um novo cliente deve seguir alguns passos: 1. Indicao de que ainda no um cliente (Figura 2). Neste momento, podemos seguir pelas opes J sou cliente login e senha, J sou cliente esqueci minha senha, J sou cliente meu email mudou, No sou cliente informe CEP, No sou cliente no sei meu CEP e No sou cliente estou fora do Brasil. No nosso estudo de caso, consideraremos apenas a opo No sou cliente informe CEP;
Ferramenta Selenium IDE

Selenium IDE um ambiente de desenvolvimento in tegrado para os testes com Selenium. Foi desenvolvido como uma extenso do Firefox e permite gravar, editar e depurar os testes. O Selenium IDE inclui o Selenium Core, permitindo gravar e reproduzir os testes no ambiente que eles sero executados, de maneira fcil e rpida. Entre suas funcionalidades, podemos citar: 1. Gravao e reproduo dos testes de forma simples; 2. Seleo de campo inteligente, que captura as informa es sobre os campos a partir da pgina; 3. Funcionalidade autocompletar para todos os comandos de Selenium; 4. Possibilita navegar entre os testes;
Figura 2. Tela Inicial do Cadastro de Clientes
2. A partir da opo anterior, ser exibido um formul rio de cadastro de cliente contendo uma srie de campos (Figura 3); 3. Preenchido o formulrio de cadastro, ser realizada a vali dao dos dados e confirmao da operao, onde indicado que o cliente foi de fato cadastrado (Figura 4).
Projetando Testes para nosso Estudo de Caso

Primeiramente, precisamos projetar os testes deste estudo de caso passoapasso, campoacampo utilizando algum critrio
52
para gerao de testes funcionais que foi apresentado no artigo Planejamento de Testes a partir de Casos de Uso publicado na edio 6 da ES Magazine. isso que faremos.
Campo CEP
Categoria Teste Vlido Teste Invlido
Valor 69046-610 06543-232
Resultado Esperado Passar para o PASSO 2 Mensagem de erro:CEP Invlido.
Tabela 2. Casos de Teste para o PASSO 1
Dessa forma, podemos criar um nico procedimento de teste responsvel pela execuo dos dois casos de teste, onde primeiramente seria executado o caso de teste invlido e em seguida o caso de teste vlido. Projetando os testes do PASSO 2: Neste passo, existem ao total 22 campos, sendo que 14 so de preenchimento obrigatrio, 5 so opcionais (em cinza na Figura 3) e 3 so somente leitura (gerados a partir de outros campos cidade, estado e pas). A Tabela 3 apresenta os casos de teste gerados para cada campo do formulrio utilizando o critrio de gerao particionamento em classes de equivalncia. Observe que cada campo possui no mximo dois casos de teste, de forma que podemos combinar todos os casos de teste invlidos em um mesmo procedimento de teste (obviamente alguns casos de teste vlidos tambm iro compor este pro cedimento de teste procedimento de teste 01 na Tabela 3) e criar um segundo procedimento de teste apenas com casos de teste vlidos, confirmando o cadastro do cliente (proce dimento de teste 02). A partir de agora, iremos usar a ferramenta Selenium para gra var e executar os testes projetados para nosso estudo de caso.
Figura 3. Formulrio de Cadastro de Clientes
Projetando os testes do PASSO 1: Como foi dito na seo anterior, neste passo iremos considerar apenas a opo Ainda no sou cliente Informe seu CEP. Esta opo possui apenas um campo, CEP, e o boto Prosseguir. Neste caso, usaremos o critrio particionamento em classes de equivalncia para gerar testes vlidos e testes invlidos, conforme a Tabela 2.
Utilizando Selenium para Gravao dos Testes

Como foi dito na Seo Ferramenta Selenium IDE, esta ferra menta funciona como um plugin do Firefox, de forma que necessrio este browser para gravar e reproduzir os testes. Ento vamos comear? Primeiramente, abra o Firefox e acesse o endereo de cadas tro de um novo cliente (https://carrinho.americanas.com.br/ portal/meuCadastro.portal). Em seguida, abra a ferramenta
Figura 4. Confirmao do Cadastro de Clientes
53
Campo Nome CPF Sexo Data de Nascimento Telefone Residencial Telefone Celular Telefone Comercial E-mail Senha Confirme a Senha Como gostaria de ser chamado? Deseja receber e-mail de ofertas? Descrio do Endereo Endereo Nmero Complemento CEP Bairro
Categoria Teste Vlido Teste Invlido Teste Vlido Teste Invlido Masculino Feminino Teste Vlido Teste Invlido Teste Vlido Teste Invlido Teste Vlido Teste Vlido Teste Vlido Teste Invlido Teste Vlido Teste Invlido Teste Vlido Teste Invlido Teste Vlido Teste Invlido SIM NO Teste Vlido Teste Vlido Teste Invlido Teste Vlido Teste Invlido Teste Vlido Teste Vlido Teste Invlido Teste Vlido Teste Invlido
Valor Arilo Claudio Em branco 14005039731 14005039710 Masculino Feminino 13/09/1982 31/02/1982 92 2345-6789 Em branco 92 8181-8181 92 3456-7890 ariloclaudio@gmail.com Em branco arilo abc Igual ao campo Senha Diferente do campo Senha Arilo Claudio Em branco SIM NO Residencial Rua B29 Em branco 120 Em branco Apt 123 69046-610 06543-232 Alvorada Em branco
Resultado Esperado Dados vlidos, verifica os demais campos Mensagem de erro:Nome Invlido. Dados vlidos, verifica os demais campos Mensagem de erro:CPF Invlido. Dados vlidos, verifica os demais campos Dados vlidos, verifica os demais campos Dados vlidos, verifica os demais campos Mensagem de erro:Data de nascimento Invlida. Dados vlidos, verifica os demais campos Mensagem de erro:Telefone residencial invlido. Dados vlidos, verifica os demais campos Dados vlidos, verifica os demais campos Dados vlidos, verifica os demais campos Mensagem de erro:E-mail invlido. Dados vlidos, verifica os demais campos Mensagem de erro:Senha invlida. Dados vlidos, verifica os demais campos Mensagem de erro:A senha e confirmao de senha no conferem. Dados vlidos, verifica os demais campos Mensagem de erro:A senha e confirmao de senha no conferem. Dados vlidos, verifica os demais campos Dados vlidos, verifica os demais campos Dados vlidos, verifica os demais campos Dados vlidos, verifica os demais campos Mensagem de erro:Endereo invlido. Dados vlidos, verifica os demais campos Mensagem de erro:Nmero do endereo invlido. Dados vlidos, verifica os demais campos Dados vlidos, verifica os demais campos Mensagem de erro:CEP invlido. Dados vlidos, verifica os demais campos Mensagem de erro:Bairro invlido.
Procedimento de Teste 02 01 02 01 02 01 02 01 02 01 01 e 02 01 e 02 02 01 02 01 02 01 02 01 02 01 01 e 02 02 01 02 01 01 e 02 02 01 02 01
Tabela 3. Casos de Teste para o PASSO 2
Selenium, que j deve estar instalada em seu Firefox. Ao abrir esta ferramenta, ser visualizada sua tela responsvel pela gravao dos testes, na qual por padro ela j est ativada para gravao, como pode ser visualizado no cone com uma bola vermelha localizado no canto superior direito da tela. Em seguida, sem fazer nada em Selenium, devemos re tornar tela de cadastro de clientes e preencher seguindo primeiramente o procedimento de teste referente ao passo 1. O resultado disto em Selenium deve ser uma tela similar tela apresentada na Figura 5. Neste momento, podemos interromper a gravao dos testes. Para isso, basta clicar no cone citado anteriormente de forma que este no aparea como pressionado na tela. Com isso, temos o primeiro roteiro de teste gravado em Selenium. A partir disso podemos salv lo ou at mesmo reproduzilo, repetindo os testes. Iremos falar mais sobre sua reproduo na prxima seo. Neste roteiro, foi adicionado um comando verifyTextPresent (em destaque na Figura 5) que verifica se aps digitar um CEP inexistente, a tela retornada contm a mensagem CEP invlido. que deveria ser retornada por este caso de teste. Finalizado o passo 1, passaremos gravao do passo 2.
Figura 5. Roteiro de Teste do PASSO 1
Para isso, primeiramente temos que nos certificar que a tela do Firefox est no passo 2 do processo de cadastro de clientes e precisamos limpar a ferramenta Selenium para que ela inicie uma nova gravao. Depois de veri ficado, devemos iniciar uma nova gravao e preencher o formulrio de cadastro de clientes primeiramente de
54
acordo com o procedimento de teste 01 (dados invlidos), conforme visualizado na Figura 6. Observe que ao final do roteiro de testes foram adicionados comandos para verificar se cada campo que recebeu um valor invlido reportou este problema durante a execuo dos testes. Depois, devemos repetir o processo (limpar os dados em Selenium e iniciar nova gravao) com os dados do proce dimento de teste 02 (dados vlidos), conforme a Figura 7. Observe que ao final do roteiro de testes foi adicionado um comando para verificar se a tela resultante aps esse proce dimento foi a tela de cadastro com sucesso (Figura 4). Isso foi feito analisando se existia o texto Ol, Arilo Claudio, que deveria ser exibido aps o cadastro do usurio que optou por ser chamado de Arilo Claudio.
obter exatamente os resultados obtidos na primeira execuo.
Utilizando Selenium para Reproduo dos Testes

A reproduo dos testes bastante simples. Para cada passo, basta abrir o arquivo com o roteiro de teste que foi salvo durante a gravao, e ento clicar no cone com uma seta verde e trs barras verdes sua direita. Neste momento, a ferramenta Selenium ir reproduzir todos os passos feitos no momento da gravao dos testes. Caso cada comando seja executado com sucesso, a linha pintada na cor verde. Caso uma falha tenha ocorrido, a linha pintada com a cor vermelha, indicando que houve problemas que precisam ser analisados. A Figura 8 exibe uma falha ocorrida no primeiro co mando ao tentar reproduzir o procedimento de teste 02 do PASSO 2 (sua linha est em vermelho).
Figura 6. Roteiro de Teste do PASSO 2 (Procedimento de Teste 01 Dados Invlidos)
Figura 8. Reproduo do Procedimento de Teste 02 do PASSO 2 com uma falha
OBS: at o dia 11/03/2010, se voc no preenchesse o CEP no formulrio de cadastro, o sistema apresentava uma falha (Figura 9). Neste caso, no teramos como gravar testes com esta condio, pois eles falhariam e no teramos como reproduzilos em um segundo momento. Em situaes como essa, a equipe de desenvolvimento deve primeiramente corrigir o problema, e ento os testes devem ser gravados.
Figura 7. Roteiro de Teste do PASSO 2 (Procedimento de Teste 02 Dados Vlidos)
Concluses
Este artigo apresentou um possvel mecanismo para automao de teste funcional para aplicaes web a partir do uso da ferramenta Selenium. Tal mecanismo adotou a estratgia de gerao de casos de testes a partir de casos de uso apresentada em outro artigo publicado na edio 6 da ES magazine. O objetivo foi apresentar uma soluo de automao dos testes, deixando destacado que a automao s faz
Feito isso, temos nossos roteiros de teste gravados e sal vos (devemos salvlos a cada gravao), e a partir de ento poderemos reproduzilos sempre que necessrio. Observe que a gravao s pode ser reproduzida caso a execuo inicial dos testes (realizada durante a gravao) tenha sido bem sucedida, ou seja, os testes no falha ram, pois o objetivo durante as reprodues dos testes
55
Figura 9. Falha real ao tentar cadastrar um cliente sem informar seu CEP
sentido a partir do bom conhecimento tcnico sobre testes de software pela equipe de testes, caso contrrio h grande chance de os testes serem malsucedidos. Ferramentas auto matizam o conhecimento tcnico da equipe de teste, mas no conseguem passar sobre este conhecimento para aumentar a qualidade dos testes. Uma vez que este conhecimento provido pela equipe de teste, ferramentas contribuem significativamente para a reduo do esforo dos testes e aumento de sua qualidade. D seu feedback sobre esta edio! A Engenharia de Software Magazine tem que ser feita ao seu gosto. Para isso, precisamos saber o que voc, leitor, acha da revista! D seu voto sobre este artigo, atravs do link: www.devmedia.com.br/esmag/feedback
Feedback eu
sobre e s
Referncias KOLAWA, A.; HUIZINGA, D. (2007). Automated Defect Prevention: Best Practices in Software Management.Wiley-IEEE Computer Society Press. p. 74. ISBN 0470042125. MARICK, B.When Should a Test Be Automated?StickyMinds.com. Acessado em 10/03/2010. . PRETSCHNER, A. (2005), Model-based testing Proceedings of 27th International Conference on , Software Engineering, (ICSE05), pp. 722-723. UTTING, M.; LEGEARD, B.; (2007),Practical Model-Based Testing: A Tools Approach ISBN-13: 978-0, 12-372501-1, Morgan-Kaufmann. CRAIG, R.D., JASKIEL, S. P.,Systematic Software TestingArtech House Publishers, Boston, 2002. , PRESSMAN, R. S., Software Engineering: A Practitioners Approach McGraw-Hill, 6th ed, Nova York, , NY, 2005. ROCHA, A. R. C., MALDONADO, J. C., WEBER, K. C. et al., Qualidade de software Teoria e prtica , Prentice Hall, So Paulo, 2001.
D s
56
edio ta
Desenvolvimento
Nesta seo voc eNcoNtra artigos voltados para difereNtes
abordageNs de apoio ao deseNvolvimeNto de projetos de software
Testes funcionais automatizados com Hudson e Selenium RC

Fabrcio Nogueira de Almeida
fnalmeida@gmail.com
ps-graduando do Curso de Gerncia de projetos em engenharia de software pelo centro de Ensino Superior de Juiz de Fora - CES, Bacharel em Sistemas de informao pela Faculdade Metodista Granbery de Juiz de Fora e Analista de Sistemas da Uptodate Consulting.
Definir uma abordagem para criao e execuo de testes funcionais automatizados.
Victor Vidigal Ribeiro

victorvidigal@gmail.com
mestrando em Engenharia de Sistemas e Computao pela COPPE/UFRJ e ps-graduando do Curso de Gerncia de projetos em engenharia de software pelo Centro de Ensino Superior de Juiz de Fora - CES.
Marco Antnio Pereira Arajo

maraujo@devmedia.com.br
Doutor e Mestre em Engenharia de Sistemas e Computao pela COPPE/UFRJ, Especialista em Mtodos Estatsticos Computacionais e Bacharel em Matemtica com Habilitao em Informtica pela UFJF, Professor e Coordenador do Curso de Bacharelado em Sistemas de Informao do Centro de Ensino Superior de Juiz de Fora, Professor do Curso de Bacharelado em Sistemas de Informao da Faculdade Metodista Granbery, Professor e Diretor do Curso Superior de Tecnologia em Anlise e Desenvolvimento de Sistemas da Fundao Educacional D. Andr Arcoverde, Professor do Curso de Bacharelado em Cincia da Computao da Faculdade Governador Ozanam Coelho, Analista de Sistemas da Prefeitura de Juiz de Fora, Editor da Engenharia de Software Magazine.
bastante aceita pela comunidade de desenvolvedores o uso de tes tes para auxiliar na qualidade dos softwares desenvolvidos. Dentre os tipos de testes utilizados existe o teste funcional, que verifica se o sistema est cumprindo com seus requisitos utilizando a perspec tiva do usurio. Na prtica, rodar testes funcionais significa executar o sistema e verificar seu comportamento atravs dos retornos fornecidos por este sistema. Para que no haja a necessidade de exe cutar esses testes manualmente existem ferramentas que, depois de programa das, executam o sistema automaticamen te e verificam seus retornos. Uma dessas ferramentas a Selenium IDE, utilizada neste artigo. Uma tcnica que pode ser utilizada em conjunto com os testes funcionais a tcnica de integrao contnua. Com esta tcnica possvel uma maior confiabili dade no sistema que est no repositrio, pois possibilita que os testes definidos sejam executados periodicamente.
Para que serve?

O modelo proposto automatiza a execuo de testes funcionais criados atravs da ferramenta Selenium IDE, o que proporciona menor dependncia de recursos humanos nessa tarefa e auxilia a gerenciamento da execuo dos testes.

Em ambientes onde preciso testar constantemente os artefatos gerados, e em projetos onde os testes so complexos e demandam muitos recursos humanos.
Este artigo prope a construo de um ambiente de integrao contnua onde testes funcionais so executados periodi camente sobre um sistema, disponvel em um repositrio Subversion (SVN) neste caso. O artigo mostra o funcionamento de uma pequena aplicao que calcula se um aluno foi ou no aprovado, que utilizada como exemplo. Depois disso, explica como gerar testes funcionais com a ferramenta
57
Selenium IDE e como importar esses testes para o framework de testes JUnit. Depois disso, demonstrado como os testes que foram exportados podem ser executados atravs da ferramenta Selenium RC e, posteriormente, como executar esses testes em um servidor de integrao contnua chamado Hudson. Para criar o projeto que ser testado foi utilizado o Maven, uma ferramenta de gerenciamento e automao de projetos em Java que permite uma maior integrao entre o projeto a ser testado e o Hudson.
Instalando o selenium IDE

Podemos ento iniciar a construo dos testes funcionais utilizando o Selenium IDE, um plugin para o navegador Firefox que permite gravar, editar, depurar e reproduzir testes funcionais para pginas web. Para instalar o Selenium IDE, acesse o endereo https:// addons.mozilla.org/ptBR/firefox/ usando o navegador Firefox, e informe no campo de busca o termo selenium ide. Aps isto, clique no link Selenium IDE que aparece na lista e, em seguida, no boto Add to Firefox, como mostra a Figura 3.
Aplicao a ser testada

Para a execuo dos testes a serem demonstrados neste artigo foi criada uma aplicao que calcula a aprovao de um aluno. importante conhecer o funcionamento da aplicao para que se possa entender os testes elaborados. Esta aplicao funciona atravs de um browser e recebe o nome, frequncia, nota 1, nota 2 e nota final do aluno como parmetros de entrada. Alm desses parmetros, o sistema possui ainda um boto Calcular Aprovao, como pode ser visto na Figura 1.
Figura 3. Instalao do Selenium IDE
Aps a instalao, o plugin estar disponvel atravs do menu Ferramentas do navegador.
Criando os casos de teste com Selenium IDE

Figura 1. Tela do sistema
Aps inserir os dados e clicar no boto Calcular Aprovao, o sistema emite uma mensagem para o usurio informando se o aluno foi ou no aprovado seguindo as seguintes regras: caso a frequncia do aluno for menor que 75, ele reprovado. Caso contrrio, a mdia entre a nota 1 e a nota 2 calculada. Se esta mdia for menor que 30, o aluno reprovado, caso seja maior ou igual a 70, o aluno aprovado. Se a mdia entre as duas notas for maior ou igual a 30 e menor que 70, ento calculado a mdia entre a mdia anterior e a nota final. Se esta nova mdia for maior ou igual a 50, o aluno aprovado. Caso contrrio, ele reprovado. A Figura 2 mostra a mensagem que o sistema exibe ao usurio aps clicar no boto Calcular Aprovao, em um caso que o aluno aprovado. bastante importante observar que este tipo de resposta do sistema que possibilita a execuo dos testes funcionais, pois atravs dessas mensagens que os testes vo verificar se o sistema agiu como esperado ou no.
Para criar os casos de testes funcionais, primeiro pre ciso acessar a aplicao de exemplo, criada anteriormente, com o navegador Firefox. Depois, no menu Ferramentas, selecione a opo Selenium IDE. Uma nova janela, como mostra a Figura 4, se abrir permitindo iniciar a gravao dos testes. Observe no canto superior direito dessa janela se o boto que indica o status da gravao est pressionado. Caso este boto esteja pressionado, cada ao do usurio no browser ser gravada pelo Selenium IDE. Por ao podese entender, por exemplo, o preenchimento de um campo ou um clique em um boto. Para iniciar gravao dos testes basta preencher os cam pos da aplicao com os valores descritos na Tabela 1, referentes ao primeiro caso de teste a ser realizado, consi derando um aluno sendo reprovado por infrequncia.
Campo Nome Frequncia Nota 1 Nota 2 Nota Final Joo 74 0 0 0 Valor
Figura 2. Mensagem de resposta
Tabela 1. Reprovao por infrequncia
58
Engenharia de Software Magazine - Testes funcionais automatizados com Hudson e Selenium RC
VALID Ao, VERIF IC Ao E TES TE
Seguindo os procedimentos acima, podem ser gerados mais 4 casos de testes com os dados apresentados nas Tabelas 2, 3, 4 e 5.
Campo Nome Frequncia Nota 1 Nota 2 Nota Final Tabela 2. Aprovao por nota Campo Nome Frequncia Nota 1 Nota 2 Nota Final Tabela 3. Reprovao por nota Campo Nome Figura 4. Janela do Selenium IDE Frequncia Nota 1 Nota 2 Nota Final Tabela 4. Reprovao por nota final Campo Nome Frequncia Nota 1 Nota 2 Nota Final Tabela 5. Aprovao por nota final Joo 75 30 30 70 Valor Joo 75 30 30 69 Valor Joo 75 29 30 0 Valor Joo 75 70 70 0 Valor
Aps o preenchimento dos campos, clique no boto Calcular Aprovao. O sistema retornar a mensagem dizendo que o aluno foi reprovado. Neste momento, preciso informar ao Selenium IDE o que era esperado caso o valor 74 fosse digitado para a frequncia e todas as notas fossem preenchidas com zero. Neste caso, ob servando as regras descritas no incio do artigo, o aluno seria reprovado por infrequncia. Logo, esperase que o sistema emi ta uma mensagem informando que o aluno foi reprovado. Para passar esta informao ao Selenium IDE, selecione o texto da mensagem, clique com o boto direito do mouse e escolha a opo verifyTextPresent, como mostra a Figura 5. Em seguida, devese terminar a gravao do teste, clicando no boto do canto superior direito da ferramenta. Por fim, devese gravar o caso de teste, a partir do menu Arquivo.
Figura 5. Gravando resultado do caso de teste
Depois de criar os casos de testes necessrios eles devem ser exportados como um arquivo de teste do framework JUnit para que possam ser executados com o Hudson e o Selenium RC. Essas duas ferramentas so necessrias para a execuo automtica dos testes funcionais e sero vistas posteriormente neste artigo. Para exportar os testes gravados, acesse a opo Arquivo / Exportar Teste Como / Java (JUnit) Selenium RC, informe um nome para o arquivo precedido pela extenso .java e clique sobre o boto Salvar. Com isto, ser gerado um arquivo de teste do JUnit baseado no teste que acabou de ser gravado. preciso exportar cada caso de teste gravado com o Selenium IDE. Depois de exportar cada arquivo, preciso editlos e alterar a URL que indica a pgina inicial do teste. Para isso, altere o primeiro parmetro do mtodo SetUp, de
59
http:/ /changethistothesiteyouaretesting/ para o endereo do servidor da aplicao. Neste exemplo, a URL inicial http:/ / localhost:8000/.
para programar a execuo dos testes e criar um ambiente de testes automatizado.

Listagem 1. Arquivo pom.xml
Criando o projeto de testes

Neste ponto do artigo, j temos os casos de testes exportados como um arquivo executvel pelo JUnit. Precisamos agora criar um projeto onde esses testes estaro contidos. Para criar este projeto ser utilizado o IDE Eclipse com o plug in m2eclipse que permite a integrao entre o IDE e o Maven. Este plugin pode ser instalado atravs da URL http:/ /m2eclipse. sonatype.org/sites/m2e. A criao de um projeto utilizando o Maven no foi por acaso. Esse gerenciador de projetos trabalha muito bem com o servidor de integrao contnua Hudson, que ser utilizado posteriormente. Para criar o projeto, abra o Eclipse e acesse o menu File / New / Other, e escolha a opo Maven / Maven Project. Depois disso, preciso dar um nome ao projeto criado. No artigo o projeto recebeu o nome de CalcularAprovacaoSelenium. Depois de criado, devese alterar o arquivo pom.xml, gerado pelo Maven, para que fique semelhante Listagem 1. Com essas alteraes no arquivo, as dependncias do JUnit e SeleniumJava Client, necessrias para a execuo dos testes, so adicionadas no projeto. Aps criar o projeto e definir suas dependncias, devemse co piar os testes gerados atravs da ferramenta Selenium IDE para o pacote test. A Figura 6 mostra a estrutura do projeto criado.
<project xmlns=http://maven.apache.org/POM/4.0.0 xmlns:xsi= http://www.w3.org/2001/XMLSchema-instance xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd> <modelVersion>4.0.0</modelVersion> <groupId>CalcularAprovacaoSelenium</groupId> <artifactId>CalcularAprovacaoSelenium</artifactId> <packaging>jar</packaging> <version>0.0.1-SNAPSHOT</version> <name>CalcularAprovacaoSelenium</name> <url>http://maven.apache.org</url> <dependencies> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>3.8.2</version> <scope>test</scope> </dependency> <dependency> <groupId>org.seleniumhq.selenium.client-drivers</groupId> <artifactId>selenium-java-client-driver</artifactId> <version>1.0.1</version> </dependency> </dependencies> </project>
O Selenium RC pode ser baixado no endereo http:/ /seleniu mhq.org/download/. Depois de baixlo, extraia seu contedo em algum diretrio do computador. No exemplo demonstrado no artigo, utilizado o diretrio C:. Para executar o Selenium RC, devese abrir o prompt de co mando e digitar os comandos demonstrados na Listagem 2. O primeiro comando acessa o diretrio onde o JRE (Java Run time Environment) est instalado e a linha seguinte executa o Selenium RC.
Listagem 2. Execuo do Selenium RC
cd C:\Program Files (x86)\Java\jre6\bin java -jar C:\selenium-remote-control-1.0.1\selenium-server-1.0.1\ selenium-server.jar Figura 6. Estrutura do projeto de testes
Tanto o projeto de teste quanto o projeto a ser testado devem ser enviados para um repositrio de dados. Neste artigo, ser utilizado o SVN. Como o uso de repositrios j bastante comum, isso no ser abordado nesse artigo.
Selenium Remote-Control
O Selenium RemoteControl, ou simplesmente Selenium RC, permite a execuo automatizada de testes criados no Selenium IDE. No ambiente proposto, ser utilizado o Sele nium RC juntamente com o servidor de integrao Hudson
Uma dica para agilizar este processo criar um arquivo com extenso .bat com o contedo da Listagem 2. Aps executar o Selenium RC, uma janela como a ilustrada na Figura 7 exibida. Essa janela deve ser mantida sempre aberta para que o Selenium RC fique ativo possibilitando a execuo dos testes. Neste ponto ser possvel testar a execuo dos testes dire tamente pelo Eclipse. Para isso, devemos clicar com o boto direito sobre o projeto, acessar a opo Run As e depois Ma ven Test, como mostra a Figura 8. Com esse procedimento, o projeto ser executado chamando o Maven2 e atribuindo ao
60
parmetro Goal o valor test, indicando que os testes do projeto devem ser rodados.
endereo http://localhost:8080/hudson. A Figura 9 mostra a tela inicial do servidor de integrao Hudson.
Figura 9. Tela inicial do Hudson Figura 7. Prompt Selenium RC
Instalao e configurao do servidor de integrao hudson

Para garantir mais produtividade e melhor controle sobre a execuo dos testes, vamos utilizar o Servidor de Integrao Hudson, que permite a execuo dos testes funcionais de for ma automatizada e contnua. O Hudson ser responsvel por baixar o projeto de testes direto do repositrio SVN e executar os testes no Selenium RC atravs das configuraes feitas com o Maven2, e conforme agendado no aplicativo. O Hudson um projeto web desenvolvido em Java e dispo nibilizado para download atravs do link https:/ /hudson.dev. java.net/ e pode ser executado atravs de um servidor web. Neste exemplo, ser utilizado o Apache Tomcat, disponvel para download em http://tomcat.apache.org/.
O prximo passo ser configurar o Hudson. Para isso, de vemos acessar no menu lateral a opo Gerenciar Hudson e depois Configure System. Entre as principais configuraes do Hudson, deve ser habilitada a instalao do Maven atravs da sua opo Install automatically. Marcando essa opo, o Hudson se encarregar de baixar as bibliotecas necessrias para construo de projetos do tipo Maven2. preciso tambm incluir a instalao do JDK desmarcando sua opo Install automatically e informando o caminho onde o JDK foi ins talado no campo JAVA_HOME. A Figura 10 ilustra como feita essa configurao.
Figura 10. Configurao Hudson
Para mais detalhes sobre as opes de configurao dis ponvel pelo Hudson, veja o artigo Integrao contnua com Hudson, Maven2, TestNG e Subversion publicado na edio 21 da Engenharia de Software Magazine.
Criando tarefas do hudson

Concluda a etapa de configurao, possvel criar uma tare fa e agendar a execuo dos testes. Para isso, devese acessar o menu lateral Nova Tarefa e, na tela seguinte, devese informar o nome da tarefa a ser criada. Nesse exemplo, chamada de TesteSeleniumCalcularAprovacao. Em seguida, selecione a opo Construir um projeto maven2 e clique em OK. Aps isto, uma nova janela ser exibida, sendo possvel configurar como ser a construo dessa tarefa. Em Geren ciamento de cdigo fonte, devese marcar a opo Subversion, e depois informar o caminho do projeto no repositrio SVN no campo URL do Repositrio. Essa configurao indicar ao Hudson o caminho que ele utilizar para baixar os arquivos do projeto.
Figura 8. Executando os testes no eclipse
Depois de instalado o Tomcat, devese copiar o arquivo hud son.war para a pasta webapps e reiniciar o servidor para fazer o deploy da aplicao. Feito isso, acesse o Hudson atravs do
61
A seguir possvel configurar a periodicidade de execuo dos testes. Para isso, a opo Construir periodicamente em Disparadores de construo deve ser marcada. Na caixa de texto deve ser inserido o seguinte valor: * * * 5. Essa configurao indica ao Hudson que esta tarefa deve ser executada no minuto cinco de cada hora. Clicando sobre o cone localizado ao lado direito da caixa de texto, o Hu dson fornece um tpico de ajuda que explica com detalhes as opes de agendamento. A prxima configurao a ser feita indicar no campo POM Raiz o caminho para o arquivo pom.xml, que mantm as configuraes do Maven2 no projeto. Neste exemplo, o cami nho do arquivo de configurao <NOME DO PROJETO>/ pom.xml. A opo Goals and options deve ser preenchida com o valor test. Esse parmetro indica ao Hudson que deve executar o Maven para rodar os testes do projeto. Por fim, possvel configurar o Hudson para enviar noti ficaes de email a cada construo executada com falhas. Para isso, a opo Notificao de email deve ser marcada e devese ainda informar os emails para os quais desejamos que sejam enviadas notificaes. Depois de realizadas as devidas configuraes, as altera es devem ser salvas atravs do boto Salvar. Aps isto, uma tela como a mostrada na Figura 11 ser exibida. Neste ponto possvel construir uma tarefa manualmente clicando no link Construir Agora.
Figura 12. Console Output
Concluso
Esse artigo procurou mostrar como montar um ambiente de testes funcionais automatizados utilizando ferramentas Open Source. Esse ambiente foi construdo com o servidor de integrao Hudson, o gerenciador de projetos Maven2, repositrio de dados SVN, framework de testes JUnit e um aplicativo responsvel por executar os testes gerados atravs do Selenium IDE, o Selenium RC. Executar testes muitas vezes pode se tornar uma tarefa que demanda tempo e consome muito recursos em um projeto. Mas devido a sua importncia dentro da Engenharia de Software, deixla de lado pode significar entregar um produto com alto ndice de falhas para o cliente. Com a alternativa proposta neste artigo, ganhamos um alto ndice de produtividade na execuo dos testes funcionais garantindo mais qualidade ao produto final que ser entregue ao cliente. D seu feedback sobre esta edio! A Engenharia de Software Magazine tem que ser feita ao seu gosto. Para isso, precisamos saber o que voc, leitor, acha da revista! D seu voto sobre este artigo, atravs do link: www.devmedia.com.br/esmag/feedback
Links Hudson http://hudson-ci.org/ Maven http://maven.apache.org/ Tomcat http://tomcat.apache.org/ SeleniumRC http://seleniumhq.org/projects/remote-control/ Subversion http://subversion.tigris.org/
Feedback eu
sobre e s
D s
Figura 11. Tela principal da tarefa
O Hudson exibe em Histrico de construes o status das construes j realizadas e tambm aquelas que esto em execuo. Clicando sobre uma construo e acessando a op o Console Output possvel visualizar o log de execuo da construo, como mostra a Figura 12. Depois de fazer essas configuraes, o Hudson ir baixar o sistema periodicamente do repositrio e ir executar os testes funcionais criados no Selenium IDE. Com isso, pode se economizar bastante esforo da equipe de testes que no precisar executar todos os testes do sistema a cada alterao realizada pelos programadores. Alm disso, o sistema que est no repositrio pode ser considerado mais confivel, pois ele est sempre sendo testado.
62
edio ta
63
AMIGO
Existem coisas que no conseguimos ficar sem!
...s pra lembrar, sua assinatura pode estar acabando!
Renove J!
www.devmedia.com.br/renovacao
Para mais informaes: www.devmedia.com.br/central
64

ESM24 Alta

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

ESM24 Alta

Enviado por

Direitos autorais:

Formatos disponíveis

EDITORIAL

Rodrigo Oliveira Spnola

Kaline Dolabella Gerente de Marketing e Atendimento kalined@terra.com.br

Marco Antnio Pereira Arajo - Editor

Fale com o Editor!

Eduardo Oliveira Spnola

Agilidade 38 - A Comunicao no Processo de Software

Planejamento e Gerncia 43 - Anlise Quantitativa de Riscos e suas Tcnicas

Desenvolvimento 49 - Automatizando Testes Funcionais em Aplicaes Web

57 - Testes funcionais automatizados com Hudson e Selenium RC

Engenharia de Software Magazine

Edio 05 - Engenharia de Software Magazine

De que se trata o artigo?

Para que serve?

Em que situao o tema til?

Engenharia de Software Magazine - Testes de segurana

VALID Ao, VERIF IC Ao & TE S TE

Figura 1. Total de incidentes reportados ao CERT.br

Por que fazer testes de segurana?

Edio 24 - Engenharia de Software Magazine

Principais falhas e a utilizao de SSL

Figura 2. Frequncia de incidencia das principais falhas na Web

Montando seu ambiente de testes com ferramentas livres

Engenharia de Software Magazine - Testes de segurana

VALID Ao, VERIF IC Ao & TE S TE

Ferramentas necessrias para a realizao dos testes

Edio 24 - Engenharia de Software Magazine

Como essas ferramentas funcionam

Outras caractersticas comuns presentes nessas sutes

Outras ferramentas teis

Engenharia de Software Magazine - Testes de segurana

VALID Ao, VERIF IC Ao & TE S TE

Figura 5. Resultado de um scan na aplicao WebGoat realizado pelo Paros

Figura 4. O WebScarab permite a visualizao do Histrico das requisies realizadas

Edio 24 - Engenharia de Software Magazine

Figura 7. O WebScarab permite a interceptao e modificao de pedidos e respostas

Figura 6. Reedio manual de uma requisio

Engenharia de Software Magazine - Testes de segurana

VALID Ao, VERIF IC Ao & TE S TE

Edio 24 - Engenharia de Software Magazine

D seu feedback sobre esta edio!

Marcelo Nascimento Costa

Para que serve?

Rodrigo Oliveira Spnola

Em que situao o tema til?

Engenharia de Software Magazine - Gerncia de Configurao

Edio 24 - Engenharia de Software Magazine

Figura 1. Classes e instncias de um item de configurao

Engenharia de Software Magazine - Gerncia de Configurao

Figura 2. Entendendo um baseline

Edio 24 - Engenharia de Software Magazine

Figura 3. Branch de desenvolvimento

Engenharia de Software Magazine - Gerncia de Configurao

Figura 4. Processo de controle de modificaes (Pressman, 2006)

Ferramentas de Apoio GCS

Edio 24 - Engenharia de Software Magazine

Engenharia de Software Magazine - Gerncia de Configurao

Gerncia de configurao nos modelos de maturidade

GCS aplicada no CMMI

GCS aplicada no MPS

Edio 24 - Engenharia de Software Magazine

Figura 5. Viso por nvel de maturidade X reas de processo

Engenharia de Software Magazine - Gerncia de Configurao