Edição28 2010

Modstia parte, sua
melhor opo para

se destacar no mercado!
A Escola Superior da Tecnologia da
Informao oferece as melhores
opes em cursos, formaes,
graduaes e ps-graduaes para
profissionais de desenvolvimento
e programao.
So programas voltados para a
formao de profissionais de elite,
com aulas 100% prticas, corpo
docente atuante no mercado,
acesso mais atualizada biblioteca
de TI do Rio, laboratrios equipados
com tecnologia de ponta, salas de
estudo e exames.
PS- GRADUAO
Engenharia de Software:
Desenvolvimento Java
Engenharia de Software:
Desenvolvimento .NET
GRADUAO
Engenharia de Computao
Anlise e Desenv. de Sistemas
F ORMAES
Desenvolvedor Java
Desenv. Java: Sist. Distribudos
Gestor de TI
Desenvolvedor Web .NET 2008
MCITP Server Administrator
SQL Server 2008
r/esti
Acesse nosso site e conhea todos os nossos programas: www.infnet.edu.br/esti
TURMAS
NO RIO DE
JANEIRO
www.infnet.edu.br - cursos@infnet.edu.br - Central de Atendimento: (21) 2122-8800
EDUCAO SUPERIOR ORIENTADA AO MERCADO
EDITORIAL
M
Ano 3 - 28 Edio - 2010
Impresso no Brasil
Corpo Editorial
Colaboradores
Rodrigo Oliveira Spnola
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
anuteno significa um conjunto de modificaes realizadas no software

que pode ocorrer durante o desenvolvimento ou aps a sua entrega, ou
seja, durante a sua utilizao. As modificaes podem ser de vrias formas
e para atingir objetivos distintos. So utilizadas para a correo de erros, atualizao do
sistema, aperfeioamento do software ou para sua adaptao a uma nova realidade.
A manuteno de software, at pouco tempo, sempre foi considerada na etapa de desenvolvimento algo secundrio, de pouco valor. Era considerada por muitos como uma
fonte de gastos que comprometiam a criao de software.
Durante o desenvolvimento, os sistemas eram elaborados sem a preocupao de que
um dia eles precisariam sofrer alguma alterao para se adequarem s novas necessidades do usurio. Quando isso ocorria, a manuteno era feita de forma precria, pois no
existia um gerenciamento adequado para que fossem feitas as mudanas. Com isso, tais
mudanas poderiam gerar novos erros que aumentariam ainda mais o tempo necessrio
para que fossem feitas as correes desejadas pelo usurio.
Atualmente, um problema chave para as organizaes implementar e gerenciar a
manuteno em seus sistemas legados. Sistemas legados so sistemas imprescindveis
para os negcios de uma organizao. Em geral, possuem documentao precria ou
inexistente e passaram, ao longo dos anos, por manutenes realizadas por diversos profissionais, sem seguir boas prticas de engenharia de software.
Neste contexto, a Engenharia de Software Magazine destaca nesta edio a matria
O Papel Evolutivo do Software cujo objetivo apresentar conceitos bsicos de manuteno e evoluo de software, incluindo definies e processos realizados durante a
manuteno de software, bem como os tipos de manuteno e exemplos de refatorao
que podem ser realizados durante este processo. Em complemento, temos uma outra
matria cujo o ttulo Refatorao para Padres cujo objetivo mostrar como o desenvolvedor pode utilizar refatorao para padres para melhorar o cdigo-fonte de suas
aplicaes.
Alm destas matrias, esta edio traz mais cinco artigos:
H um colega chato em seu local de trabalho?;
Negociao de Contratos;
Auditoria de Sistemas;
Requisitos em SOA Parte 1;
Reuso de Software utilizando Padres de Anlise.
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:
Daniela Maciel e Flvia Aparecido Atendimento ao Leitor
www.devmedia.com.br/mancad
(21) 2220-5338
Kaline Dolabella
Gerente de Marketing e Atendimento
kalined@terra.com.br
(21) 2220-5338
Publicidade
Para informaes sobre veiculao de anncio na revista ou no site entre em
contato com:
Cristiany Queiroz
publicidade@devmedia.com.br
Fale com o Editor!

muito importante para a equipe saber o que voc est achando da revista: que tipo de artigo
voc gostaria de ler, que artigo voc mais gostou e qual artigo voc menos gostou. Fique a
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
rodrigo.devmedia@gmail.com

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.

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.
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,
NDICE
Por trs do obvio
06 H um colega chato em seu local de trabalho?
Glnio Cabral
Agilidade
07 - Negociao de Contratos
Para esta edio, temos um conjunto de 5 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:
Lenildo Morais
Engenharia
14 - Requisitos em SOA Parte 1
Joo Caldas Jnior
19 - O Papel Evolutivo do Software

Vincius Rodrigues de Souza, Ricardo Cunha Vale e Marco Antnio Pereira Arajo
Tipo: Processo
Ttulo: Atividades da Gerncia de Projetos Partes 5 a 9
Autor: Rodrigo Oliveira Spnola
Mini-Resumo: A gerncia de projetos possui um conjunto de atividades
associadas aos processos da gerncia. Nesta srie de 5 vdeo aulas conheceremos algumas dessas principais atividades destacando seus objetivos,
tarefas desempenhadas e resultados esperados. Alguns dos assuntos tratados
sero: planejamento de cronograma, planejamento de recursos humanos e
planejamento de riscos.
Planejamento e Gerncia
26 - Auditoria de Sistemas
Anderson Carlos Santos Ramires, Rodrigo Oliveira Spnola e Marcos Kalinowski
Desenvolvimento
38 - Refatorao para Padres
Jacimar Fernandes Tavares e Marco Antnio Pereira Arajo
46 - Reuso de Software utilizando Padres de Anlise

Evaldo de Oliveira da Silva e Jugurta Lisboa Filho
Existem coisas
que no conseguimos
ficar sem!
...s pra lembrar,
sua assinatura pode
estar acabando!
AMIGO
Renove J!
www.devmedia.com.br/renovacao
Para mais informaes:
www.devmedia.com.br/central
Edio 05 - Engenharia de Software Magazine
Pos trs do bvio
H um colega chato em seu

local de trabalho?
Engenharia de Software - H um colega chato em seu local de trabalho?
H algo a ser aprendido com todos esses tipos? A resposta sim.

Primeiro, os chatos nos ensinam a como no nos comportarmos.
Eles so nossos consultores involuntrios, pois nos alertam sobre
os caminhos comportamentais a no serem seguidos. Segundo,
aprendemos que todos temos momentos de chatice de vez em
quando, o que nos estimula a sermos mais pacientes com nossos
colegas inconvenientes. E terceiro, conclumos que devemos estar
sempre reavaliando nossas atitudes e comportamentos. Afinal, a
maneira como nos relacionamos com nossos colegas trar repercusses importantes na motivao e no clima do nosso ambiente
de trabalho.
Glnio Cabral
gleniocabral@yahoo.com.br
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
Administrador de Empresas, ps-graduado em Gesto de Pessoas e msico. Idealizador do site de educao infantil www.novainfancia.com.br.
Feedback
eu
sobre e
s
como um vampiro ensandecido. So pessoas frustradas, que no

suportam ver a no-frustrao dos outros.
6) O Super-bonder: costuma ser grudento, um verdadeiro chiclete. Como as pessoas se afastam dele, qualquer demonstrao de
considerao ou ateno razo para que ele grude em voc. Esse
cidado liga para sua casa quatro vezes ao dia, abraa voc com
impetuosidade e tenta expressar para as pessoas uma intimidade
com voc que na verdade no existe. E pior: cada aperto de mo
e abrao acompanhado de uma longa, prolixa e desinteressante
conversa de, no mnimo, duas horas. Ah, geralmente ele costuma
convidar a si mesmo para almoar na sua casa, leitor...
7) O leva e traz: tambm conhecido como Boca do Inferno,
numa injusta aluso ao poeta baiano Gregrio de Matos. Esse
chato entende que ganhar a confiana e a admirao do seu
superior ao levar-lhe as ms notcias do dia de trabalho. Ao fim
do expediente, apresenta ao seu gerente o relatrio de quem pisou
na bola durante o dia. Ele acha que de fofoca em fofoca estar
escalando os degraus da promoo. Mas a nica coisa que ele
consegue o desprezo e a desconfiana dos colegas.
edio
ta
o adianta mudar de departamento nem se transferir

para outra empresa. Onde quer que voc esteja, l estar
ele. Estou falando do colega de trabalho chato, aquele
sujeito inconveniente e persistente na prtica da perturbao
alheia. O problema que um chato nunca tem conscincia de sua
chatice, da a pergunta: ser que voc, caro leitor, o colega chato
e ainda no se deu conta? Na dvida, relacionamos abaixo sete
categorias de chatos largamente encontrados nos corredores das
corporaes para que voc faa uma auto-anlise.
1) O Consultor Aloprado: mestre em dar palpites em tudo. E
pior, acha sempre que est com a razo. Por isso, quando suas
opinies no so acatadas ele fica chateado e acha que est sendo
vtima de uma conspirao arquitetada pela cpula da empresa.
Ele erra na insistncia, na cobrana e na inconvenincia. Sugesto
sugesto, e no tem que ser acatada. Alm do mais, nem sempre
as pessoas querem ouvir opinies e pontos de vista. Mas o chato
em questo no entende isso e insiste em dar uma de consultor
sem ter sido consultado.
2) O Verborrgico: desconhece o significado da palavra dilogo.
Para ele, apenas o monlogo tem sentido. Por no ter a capacidade
de ouvir os outros, costuma monopolizar as reunies falando
compulsivamente, numa demonstrao trgica de verborragia.
Quando finge que est ouvindo a opinio de algum, na verdade
est apenas formulando uma resposta para contra-argumentar.
Para esse cidado, o som mais belo o som da sua prpria voz.
3) O Amplificador Vocal: tem o hbito de falar alto para compensar a falta de contedo do seu discurso. Conversar aos gritos na
verdade uma tentativa desesperada de chamar a ateno, j que
geralmente suas conversas so prolixas e desinteressantes.
4) O Venha a Ns: est sempre disposto a ser servido, mas nunca a
servir. Por isso, mestre na arte de pedir e nunca retribuir. Conheci um tipo assim que costumava entupir o seu setor de trabalho
com atestados mdicos para justificar suas constantes ausncias.
No entanto, quinze minutos antes de terminar o seu expediente
ele j estava de sada, todos os dias. Esse chato interesseiro e
timo para pedir, mas pssimo pra cumprir o seu dever. Quando
ele se aproxima, as pessoas logo pensam: L vem o golpe.
5) O Vampiro: costuma causar srios danos s organizaes.
Aprecia jogar um balde de gua fria nos xitos das pessoas por
pura inveja. Se voc recebe uma promoo, ele diz se prepare,
s vezes uma promoo no compensa o estresse. Se algum
comea a fazer algo mais que sua obrigao dentro da empresa,
ele diz o que voc vai ganhar com isso? No vale a pena. E assim
ele vai sugando a motivao e a energia das pessoas ao seu redor,
Agilidade
Nesta seo voc encontra artigos voltados para as prticas e mtodos geis.
Negociao de Contratos
Negociao de contratos em projetos utilizando desenvolvimento gil
De que se trata o artigo?

Demonstrar, atravs de uma viso geral, como os
contratos de projetos so tratados no ambiente da
metodologia gil. Voc conhecer os principais tipos
de contratos e como eles podem influenciar no seu
processo de desenvolvimento de software.
Para que serve?

Proporcionar maior controle das inovaes tecnolgicas e das mudanas constantes de requisitos do
cliente, uma vez que grande parte dos projetos de desenvolvimento de software excedem o prazo e o oramento previstos, haja vista que o desenvolvimento
N
Lenildo Morais
lenildojmorais@gmail.com
analista de sistemas e analista de testes.

Atualmente est cursando mestrado no
centro de informtica da UFPE em engenharia de software com nfase em testes
e qualidade de software.
este artigo vamos abordar como

os requisitos so tratados, no
tocante a negociao de contratos, em projetos de desenvolvimento
gil. Ser apresentada uma viso geral
sobre metodologias geis e quais as
principais vantagens e desvantagens
dos tipos de contrato utilizados nestas
metodologias.
Alm disso, algumas tcnicas utilizadas
por empresas para elaborao de contratos sero apresentadas, mostrando ainda
como isso pode influenciar e motivar os
de software uma atividade complexa, envolvendo

inmeros fatores considerados imprevisveis e de difcil acompanhamento.
Em que situao o tema til?

Nos projetos de desenvolvimento de software, que
adotam metodologias geis, sobretudo quando se
deseja gerenciar riscos, ainda que seja em um ambiente heterogneo e que apresente dificuldades
na estratgia organizacional ou nas prioridades e
restries do processo de desenvolvimento, necessitando um maior comprometimento entre os
gestores e os clientes.
gestores quanto adoo dessa cultura,

propiciando maior interao e satisfao
entre gerentes, analistas, desenvolvedores e clientes. A adoo deste tipo de
negociao deve ser considerada pelas
empresas que desejam reduzir custos e
melhorar a produtividade na construo
de seus projetos de software.
Metodologias geis
De uma maneira geral, pode-se afirmar
que os projetos de desenvolvimento
de software tm sido de preocupao
constante para clientes do sistema (stakeholders), gerentes

de projeto e para os prprios desenvolvedores. Postergaes
nos prazos de entrega do produto, longas fases de anlise
de requisitos, estouro no oramento dos projetos, fases de
testes insuficientes, cancelamento de projetos, produtos
com alta taxa de defeitos e requisitos que no satisfazem as
necessidades reais dos clientes so apenas alguns exemplos
que servem para ilustrar a gravidade dos tipos de problemas
mais comuns encontrados durante o processo de desenvolvimento de software.
Para lidar com estes desafios, os mtodos geis enfatizam
comunicaes em tempo real, preferencialmente face a face,
a documentos escritos. A maioria dos componentes de um
grupo gil devem estar agrupados em uma sala. Isto inclui
todas as pessoas envolvidas na construo do software.
Paradigmas como o ciclo de vida clssico deveriam ter
posto fim a vrios problemas de desenvolvimento de
software, j que proviam fases ordenadas e bem definidas,
como: Engenharia de Sistemas, Anlise de Requisitos,
Projeto de Software, Codificao, Testes e Manuteno.
Normalmente durante o ciclo de vida clssico, a maior parte
dos custos referente fase de desenvolvimento, sendo
que para software customizado, os custos de evoluo
excedem os de desenvolvimento, principalmente os custos
referentes s mudanas.
O desenvolvimento de software gil evoluiu como parte
de uma reao contra mtodos, caracterizados por uma
pesada regulamentao, e que utilizavam o modelo em
cascata para desenvolvimento. Inicialmente, os mtodos
geis eram conhecidos como mtodos leves. Em 2001,
membros da comunidade se reuniram em Snowbird e
adotaram o nome mtodos geis, publicando o Manifesto
gil, documento que rene os princpios e prticas desta
metodologia de desenvolvimento. Posteriormente estes
membros formaram a Agile Software Development Alliance,
tambm conhecida como Agile Alliance, e definiram um
manifesto para encorajar melhores formas de desenvolvimento de software, entre eles:
A maior prioridade a satisfao do cliente atravs da
entrega rpida e contnua de software til;
A mudana de requisitos ser bem recebida em qualquer
momento do desenvolvimento, mesmo em uma fase mais
avanada do mesmo;
A entrega de software dever ser frequente, em poucas semanas ou meses, mas sempre preferindo a menor
escala;
Pessoas que entendem o negcio e desenvolvedores
devem trabalhar juntos diariamente;
Softwares em funcionamento deve ser a mtrica de
progresso;
Em intervalos regulares, a equipe deve refletir sobre
como podem ser mais efetivos e realizar os devidos ajustes.
As Metodologias geis devem se adequar a tais princpios ou correm o risco de no pertencer a tal classificao.
Engenharia de Software Magazine - Negociao de Contratos
Entretanto, metodologias como eXtreme Programming,

Crystal, Dynamic System Development Method, Feature
Driven-Development, entre outras, surgiram antes do Manifesto gil. Alis, alguns autores destas metodologias
fizeram parte do grupo inicial que deu origem Agile
Alliance, e os princpios que norteiam as Metodologias
geis foram extrados das experincias prticas destes
autores com suas metodologias.
As prticas geis melhoram a comunicao, a produtividade e geram a documentao na medida certa. Estas
prticas so fundamentadas nos trs critrios de sucesso
de um software:
1. A soluo atende ao negcio (qualidade externa);
2. Software de fcil manuteno e evoluo (qualidade
interna);
3. Menor custo e prazo possvel (qualidade do projeto).
Os mtodos geis diferem no que diz respeito forma de
serem gerenciados. Uma das caractersticas comuns dos
processos geis a capacidade de funcionar em ambientes
muito exigentes que tm um grande numero de incertezas e
flutuaes (mudanas). Estas incertezas podem vir de vrias
fontes, como: equipe em processo de formao que ainda no
trabalhou junto em outros projetos; requisitos volteis; baixo
conhecimento do domnio de negocio pela equipe; adoo
de novas tecnologias; novas ferramentas; novos concorrentes; novos produtos; novos modelos de negocio.
A seguir apresentaremos uma viso geral das principais
metodologias geis.
Scrum
O Scrum uma metodologia cujas prticas so aplicadas
em um processo iterativo e incremental. Os projetos no
qual o Scrum se insere so complexos e imprevisveis,
onde no possvel prever tudo que ir acontecer. Por
esta razo, ele oferece um conjunto de prticas que torna
tudo isso visvel.
A estrutura de processo do Scrum inicia-se com uma
viso do produto que ser desenvolvido, contendo as caractersticas definidas pelo cliente, premissas e restries.
Em seguida, o Product Backlog criado contendo a lista de
todos os requisitos conhecidos. O Product Backlog ento
priorizado e dividido em releases, onde cada release contm
um conjunto de requisitos, denominado Sprint Backlog, que
ser desenvolvido em uma iterao, denominada de Sprint.
Na execuo da Sprint, diariamente a equipe faz reunies
de 15 minutos (Daily Scrum Meeting) para acompanhar
o andamento do projeto. Ao final da Sprint, realizado
o Sprint Review Meeting, de modo que o time apresente
o resultado alcanado ao Product Owner (representante
do cliente). Em seguida, o ScrumMaster conduz o Sprint
Retrospective Meeting, reunio de retrospectiva do Sprint
tambm realizada no final de cada iterao. Nela, a equipe
e o ScrumMaster se renem para discutir o que deu certo
e o que deve ser melhorado.
agilidade
Agile Project Management (APM)

APM um conjunto de valores, princpios e prticas que
auxiliam as equipes de projetos a entenderem os problemas envolvidos em ambientes instveis e desafiadores. Os
principais valores do APM endeream tanto a necessidade
de construir produtos de modo gil e adaptvel como
tambm a necessidade de criar equipes de desenvolvimento com as mesmas caractersticas. Ele composto por
cinco fases: Viso, Especulao, Explorao, Adaptao e
Encerramento.
Fase de Viso: Esta viso identifica aspectos como o
produto, escopo do projeto, a comunidade participante
do projeto e como o time do projeto (clientes, gerente e
equipe) ir trabalhar em conjunto;
Fase de Especulao: Os requisitos so definidos, estimativas e estratgias de mitigao de riscos so elaboradas, e um plano baseado em release, milestones e iteraes
criado visando sempre entregar algo de valor (features)
ao cliente;
Fase de Explorao: Contempla a entrega de incrementos
de funcionalidades planejadas por meio do gerenciamento
das atividades do projeto e monitoramento dos riscos;
Fase de Adaptao: Esta fase foca na reviso dos resultados alcanados considerando a anlise da situao
atual versus a planejada, incluindo a avaliao de desempenho da equipe do projeto e adaptaes do que for
necessrio;
Fase de Encerramento: Corresponde finalizao das
atividades do projeto onde so observados os aspectos
positivos e os pontos de melhoria para os prximos projetos. Nesta fase tambm realizada a transferncia das
lies aprendidas.
Aps a fase de Viso, as fases Especulao, de Explorao
e de Adaptao se alternam a cada iterao no intuito de
refinar o produto do projeto. A fase de Especulao retomada com o objetivo de planejar o novo ciclo, levando
em considerao os resultados alcanados no projeto e
as alteraes ou incrementos de escopo solicitados at o
momento. Algumas vezes, no entanto, o retorno fase
de Viso pode ser necessrio, em especial quando se tem
modificaes muito significativas no escopo do projeto.
Uma vez obtido o produto final, segue-se para o Encerramento do projeto.
eXtreme Programming (XP)

O Extreme Programming (XP) o mais popular dos
processos geis. Ele foi criado por Kent Beck durante o
desenvolvimento do projeto C3 da Chrysler, um sistema
de folha de pagamento desenvolvido basicamente em
Smalltalk, entre 1977 e 1999. O XP formado por um
conjunto de valores, princpios e prticas. Os valores
formam as crenas fundamentais das equipes que seguem o processo. As prticas so as atividades concretas
que equipes XP realizam no dia-a-dia. J os princpios
funcionam como guias que ajudam a adaptar as prticas

realidade particular de cada equipe ou projeto. Os valores
do propsito s prticas, as prticas tornam os valores
concretos e objetivos, e os princpios funcionam como
uma ponte que conecta valores e prticas.
Um projeto XP passa pelas fases de explorao, planejamento inicial, iteraes do release, produo, manuteno
e morte.
Fase de Explorao: Anterior construo do sistema.
Nesta fase so feitas investigaes de possveis solues
verificando-se a viabilidade das mesmas. Os programadores elaboram possveis arquiteturas e tentam visualizar como o sistema funcionar considerando o ambiente
tecnolgico (hardware, rede, software, performance,
trfego) onde ele ser executado. Normalmente gasto
no mximo duas semanas nessa fase;
Fase de Planejamento Inicial: Nesta fase so definidas as prioridades entre as estrias junto com o cliente.
Os programadores estimam o esforo e o cronograma
para cada uma das estrias. O planejamento funciona
da seguinte forma: os programadores, juntamente com
o cliente, definem as estrias (use case simplificados) a
serem implementadas e as descrevem em cartes. Os
programadores assinalam uma certa dificuldade para
cada estria e, baseados na sua velocidade de implementao, dizem quantas estrias podem implementar em
uma iterao. Depois, os clientes escolhem as estrias de
maior valor para serem implementadas na iterao (isso
chamado planejamento de iterao). O processo ento
se repete at terminar as iteraes do release;
Fase das Iteraes do Release: Nesta fase so escritos os
casos de teste funcionais e de unidade. Os programadores
vo seguindo mais ou menos o fluxo das atividades na
seguinte ordem (em cada iterao):
1. Escrita dos casos de testes;
2. Projeto e refatorao;
3. Codificao;
4. Realizao dos testes;
5. Integrao.
Depois de terminado o primeiro release, j se ter um
melhor domnio do problema de modo que as iteraes
podero ser mais curtas nos releases subsequentes, e j
ser possvel fazer estimativas mais confiveis com o que
se aprendeu nas iteraes passadas.
Fase de Produo: Nessa fase so feitos testes extensivos
e verificaes para validao do software a ser utilizado em ambientes de produo. Cada release colocado
para rodar em um ambiente que simula o ambiente de
produo para avaliar seu comportamento em termos de
performance. Neste momento possvel fazer testes de
aceitao adicionais para simular o funcionamento real
do sistema no ambiente alvo.
Fase de Manuteno: Aps o primeiro release para
produo, h novas edies do sistema com novas
funcionalidades. Mecanismos como refactoring, introduo de novas tecnologias e introduo de novas ideias
de arquitetura podem tambm ser utilizados em projetos
que adotam a metodologia XP. importante ressaltar
que a manuteno dada em um sistema que j est em
produo deve ser feita com muita cautela, pois uma alterao errada pode paralisar o funcionamento do sistema
resultando em prejuzos para o cliente.
Fase de Morte: Quando no h mais estrias a serem implementadas e quando o cliente est satisfeito com o cdigo.
Esta fase corresponde ao trmino de um projeto XP.
Modelagem gil
uma metodologia que no trata de prescrio de processos, ou seja, ela no define procedimentos detalhados
de como criar um dado tipo de modelo, ao invs disso,
ela prov prticas de como ser efetivo. A modelagem gil
(AM) uma coleo de prticas guiadas por princpios
e valores que podem ser aplicados por profissionais
de software no dia a dia. A Modelagem gil tem trs
objetivos:
1. Definir e mostrar como colocar em prtica uma coleo
de valores, princpios e prticas pertinentes modelagem
efetiva;
2. Mostrar como aplicar tcnicas de modelagem em
projetos de software atravs de uma abordagem gil tal
como XP ou SCRUM;
3. Melhorar a modelagem a partir de processos prescritivos como o Processo Unificado da Rational (RUP).
Feature Driven Development

Desenvolvimento guiado por funcionalidades uma
metodologia gil para gerenciamento e desenvolvimento
de software. Ela combina as melhores prticas do gerenciamento gil de projetos com uma abordagem completa para engenharia de software orientada a objetos,
conquistando os trs principais pblicos de um projeto
de software: clientes, gerentes e desenvolvedores. Seus
princpios e prticas proporcionam um equilbrio entre
as filosofias tradicionais e as mais extremas, proporcionando uma transio mais suave para organizaes mais
conservadoras, e a retomada da responsabilidade para
as organizaes que se desiludiram com as propostas
mais radicais.
A FDD possui algumas caractersticas peculiares:
Resultados teis a cada duas semanas, ou menos;
Blocos bem pequenos de funcionalidades valorizadas
pelo cliente, chamados Features;
Planejamento detalhado e guia para medio do andamento do projeto;
Rastreabilidade e relatrios com determinada preciso;
Monitoramento detalhado dentro do projeto, com
resumos de alto nvel para clientes e gerentes, tudo em
termos de negcio;
10
Fornece uma forma de saber, dentro dos primeiros 10% de

um projeto, se o plano e a estimativa so slidos.
Adaptive Software Development

O Adaptive Software Development (ASD) tem como base
principal o mtodo RAD (Rapid Application Development). Ele
prope atualizar o ciclo de desenvolvimento baseado em
planejamento, projeto e construo, trocando-o por um com
as fases de especulao, colaborao e aprendizado. Essa mudana foi necessria devido ao diferente foco dos dois ciclos:
o primeiro considera a estabilidade no ambiente de negcios,
enquanto o segundo foca em ambientes de incerteza e de
grande mudana, viso comum a todos os mtodos geis.
Com este novo ciclo de desenvolvimento mais fcil a
adequao a esse ambiente turbulento, trocando uma fase
de planejamento por algo baseado na tentativa de predio,
especulao.
A prxima fase do ciclo (colaborao) prope o trabalho
colaborativo entre as partes envolvidas, criando um fluxo de
informao suficiente para que possam ser resolvidos rapidamente os problemas tcnicos e de requisitos de negcios. Essa
forma de trabalho necessria devido grande quantidade
de informao que deve ser recolhida e trabalhada para um
sistema complexo.
Por fim (aprendizado), necessrio que haja feedback, para
que seja possvel aprender com os erros anteriores, corrigindoos para as prximas iteraes. Isso pode ser realizado atravs
de sees de retrospectivas do projeto.
Para que o desenvolvimento seja realmente adaptativo necessrio que esse novo ciclo tenha as seguintes caractersticas:
1. Foco na Misso: Fazer com que a equipe tenha um objetivo definido e permitir que sejam tomadas decises para
suport-lo;
2. Baseado em Funcionalidades: O objetivo entregar resultados mais palpveis ao cliente, atravs de funcionalidades
implementadas no sistema, ao invs de outras formas de
produtos (como por exemplo, documentao);
3. Iterativo: A construo deve focar na evoluo do produto;
4. Perodos Fechados (Time-Boxes): A equipe deve ter um
objetivo definido num determinado perodo, observando as
prioridades para que seja entregue o combinado no prazo
adequado;
5. Dirigido a Riscos: necessrio analisar e avaliar os riscos do
projeto continuamente, assim como em um desenvolvimento
em espiral;
6. Tolerante a Mudanas: Incorporar as mudanas que forem
aparecendo durante o projeto, para que o sistema agregue
maior valor ao cliente.
Viso da Metodologia gil

comum se achar que a Engenharia de Software bem
prxima da Engenharia Civil ou Engenharia Mecnica. Nas
engenharias tradicionais, existe separao entre design e
construo, na engenharia de software esta distino no
existe.
agilidade
Quando um edifcio construdo necessrio

ter uma planta detalhada para poder iniciar a
construo do produto (o prdio). Nesse projeto,
quem responsvel pela atividade de design um
arquiteto ou engenheiro que possui qualificaes
intelectuais distintas de quem ir implementar o
projeto (a construo). O trabalho de construo
ser desempenhado pelo pedreiro, que no necessita ter o conhecimento total da engenharia
para fazer o seu trabalho. Essa diviso acontece
por conta das caractersticas totalmente diferentes
entre os dois trabalhos: um altamente intelectual,
o outro mais braal. Um engenheiro pode ter um
custo alto, haja vista que um engenheiro pode gerar
subsdios para o trabalho de 100 pedreiros ou mais,
j o pedreiro tem um custo muito menor.
Devido natureza do projeto civil, notria a
existncia dessa diviso de trabalho entre design
e construo. Nesse cenrio, no faz sentido as
pessoas do projeto serem engenheiro-pedreiro,
como acontece na Engenharia de Software.
Quando se fala em software, temos basicamente
quatro atividades principais:
1. Compreender o que o usurio quer;
2. Definir como os elementos de software resolvero
as necessidades do usurio;
3. Escrever esses elementos de software e integr-los;
4. Testar os elementos e homolog-los com o usurio.
1. Qual o contexto do projeto?

2. Qual a dvida que tenho?
3. Quem poderia modelar isso junto comigo para obter as respostas?
4. Qual o modelo de arquitetura mais apropriado?
Um dos valores da modelagem gil modelar com um propsito, e
modelar com um propsito significa buscar os critrios de sucesso do
projeto. Modela-se para que o software atenda ao usurio ou para que
o software tenha qualidade interna, ou para reduzir custo ou prazo do
projeto, ou para todas estas opes. altamente questionvel quando se
modela s para cumprir etapas do processo ou modela-se porque o
processo de desenvolvimento exige modelo. O correto seria modelar o
que precisa ser modelado.
Uma das questes mais discutidas no processo de engenharia Qual o
modelo certo?. importante ressaltar que se tem uma quantidade infinita
de maneiras de modelar. Uma prova disso a prototipagem. Um esboo
feito de forma rpida e conjunta com as partes interessadas um meio
muito eficiente de capturar requisitos e descobrir como atingir o objetivo
de se fazer um software com qualidade e que atenda s expectativas dos
usurios.
A vantagem em se fazer com que os clientes e usurios participem da
modelagem do sistema utilizando artefatos e ferramentas simples, como
rascunho em papel, ou no quadro branco, promover a colaborao e
A atividade de escrever os elementos de software

no intelectualmente inferior atividade de compreender o que o usurio quer, ou definir a colaborao entre elementos de software. So atividades
diferentes, mas no to diferentes como o trabalho
do engenheiro e do pedreiro. O erro que muitas empresas cometem achar que analistas de sistemas
so como engenheiros civis e programadores so
como pedreiros, e isso no verdade.
Programar uma atividade mais intensa, a que
mais requer ateno, a mais sujeita ao estresse e
a que mais emerge riscos no desenvolvimento de
software. Processadores de texto e ferramentas
UML aceitam qualquer inconsistncia que um
analista escreve ou modela, j o compilador implacvel: ou codifica-se corretamente ou o software
simplesmente no funcionar. Ou integram-se os
componentes corretamente ou eles no funcionaro juntos.
Quando se fala em modelagem, seja de projetos
de engenharia, de uma casa ou de softwares, importante ter em mente qual seu objetivo final, haja
vista que uma das grandes dvidas das equipes
de projeto quo longe devem se aprofundar em
detalhes. Para responder a essa dvida, deve-se
refletir sobre as perguntas abaixo:
11
ganhar agilidade na captura de requisitos. Porm, algumas

pessoas ou empresas sofrem com o excesso de cerimnia,
de forma a no reconhecer artefatos em papel como vlidos no processo de desenvolvimento. Isso leva a uma
burocratizao desnecessria na captura de requisitos ou
mesmo na fase de projeto.
Muitas pessoas levantam requisitos em artefatos informais para depois transform-los em casos de uso, especificaes, prottipos, documentos de regras de negcio e
outros quando voltam para casa. Isto , preenchem esses
templates depois das reunies, formalizando o levantamento. Como houve uma transformao de artefatos, tpica
uma reviso com o cliente para obter uma aprovao.
O problema que essa aprovao dificilmente ocorre.
Ao ver os artefatos transformados, o cliente se lembra
de mais requisitos que so mais uma vez capturados em
artefatos informais e o ciclo se repete muitas vezes. Com
isso, levam-se semanas para aprovar os requisitos e um
tempo precioso perdido.
A ideia de trabalhar com rascunhos rapidamente
transform-los em software funcionado, de forma que
da prxima vez que haja o encontro do engenheiro de
requisitos com o cliente possa ser entregue o software a
ser homologado e no documentos a serem aprovados.
No se deve perder tempo aprovando documentos de
requisitos depois que foram levantados, pois eles nunca
sero aprovados, e mesmo que sejam aprovados o cliente
poder mudar de ideia quando vir realmente o que ele quer
de fato (o sistema). Deve-se lembrar que documentos de
requisitos so abstraes. Isso nos faz pensar na definio
de que software funcionando o melhor artefato para o
levantamento de requisitos.
O desenvolvimento se d de forma iterativa e com entrega
constante de software pronto para os stakeholders. Dessa forma, os usurios olham o software e solicitam alteraes no
prprio software e no nos documentos. Software a nica
coisa concreta que realmente validamos com os usurios.
Muitos artefatos podem ser usados para documentar requisitos. Os rascunhos em papel, um arquivo MP3 com o
contedo da reunio de levantamento, prottipos visuais,
casos de uso, documentos em texto, etc. Documentos de
requisitos tm como objetivo registrar o que os usurios
esperam da aplicao independente da soluo tcnica.
Isso faz com que esses documentos sejam simples e rpidos de serem elaborados. Podem ser usados vrios deles
para registrar os anseios dos usurios. Entretanto, o mais
importante que esses artefatos sejam elaborados na reunio de levantamento e no em casa. O objetivo sair da
reunio com requisitos levantados e documentados, depois
disso, fazer o software para cumprir o planejamento da
iterao.
Negociaes Contratuais
Um grupo de desenvolvedores, produtores e consultores
de software, conhecidos como Aliana gil, assinaram
12
o Manifesto de Desenvolvimento gil de Software. Este

manifesto buscava (e ainda busca) uma maior valorizao
do cliente, deixando a negociao de contratos em segundo
plano. Entretanto, muitos projetos que fazem uso de metodologias geis gastam muito tempo e esforo em negociaes
contratuais com os clientes.
Algumas das dificuldades enfrentadas durante a adoo de
metodologias geis, pela empresas, so seus prprios princpios. A negociao de contratos uma rea que ainda agrega
alguns desafios para os gestores de projetos que passam a
utilizar metodologias geis em suas equipes de desenvolvimento de software. Um dos grandes desafios para as equipes
que trabalham com metodologias geis so os contratos
estabelecidos entre o vendedor (equipe desenvolvedora) e
o cliente. Esses contratos definem o escopo, caractersticas,
plano, tempo, requisitos e preo do projeto.
Como forma de definir o escopo destes contratos os gerentes
de projetos levam em considerao aspectos como:
Clientes precisam saber o escopo, tempo e preo para escolher entre mltiplas ofertas em um processo licitatrio;
Clientes acham que eles no tero riscos em seus negcios
se a equipe no entregar o que foi acordado;
Clientes acham que no tero nenhum risco financeiro,
pois o preo j foi acordado no incio do projeto. Entretanto,
muitos gestores de projetos acabam elevando os preos na
fase de definio do projeto.
Podemos ainda identificar alguns casos em que o contrato
pode funcionar corretamente, tais como:
Quando a equipe desenvolvedora tem pleno conhecimento
do domnio da aplicao, obtendo ento uma anlise de requisitos com maior eficcia, assim como, evitando os possveis
riscos;
A equipe de desenvolvimento conhece a tecnologia utilizada
e j realizara projetos similares com a mesma;
Quando o gerente, ou Scrum Master do time, conhece sua
equipe. A performance da equipe depende bastante do talento
e experincia individual, mas acima de tudo, depende de como
os membros da equipe conseguem se relacionar entre si. A
tcnica de programao em pares uma tima alternativa para
a adaptao de novos membros equipe de desenvolvimento
de forma extremamente rpida;
Quando a equipe j trabalhou com sistemas de mesmo porte
e nvel de complexidade antes, pois o gerenciamento de vrios
times sempre mais complexo que o gerenciamento de apenas
alguns desenvolvedores.
Mudana de Comportamento dos Gerentes

H ainda uma grande dificuldade em se modificar a forma
de trabalhar dos clientes, que esto acostumados (ou acomodados) com metodologias tradicionais. No entanto, o grande
desafio a mudana de comportamento dos gerentes, que
esperam trabalhar com contratos fixos. Uma desvantagem
muito discutida, antes da adoo desse tipo de contrato, que
nele os prestadores de servio incluem acrscimos (gorduras)
agilidade
Outra opo para atrair os clientes na adoo de metodologias geis encorajando-os a comprar algumas iteraes
ao invs de assinar contratos para todo o projeto. importante observar que neste caso devero ser considerados
pequenos mdulos de sistemas que possam ser utilizados
como piloto nesta avaliao para que no haja a interrupo
do projeto.
Alm desta, existe a possibilidade de a equipe permitir ao
cliente o uso de uma verso experimental do software desenvolvido com a adoo de metodologia gil, permitindo assim
o desenvolvimento com o cliente e provendo a cobertura de
risco. Uma vez que os clientes tenham testado algumas iteraes, ento so oferecidas opes de compra de mais interaes ou novas features. Com isso o cliente ter a possibilidade
de comprovar que no ter riscos eminentes com a adoo da
nova metodologia, permitindo-lhe a possibilidade de abortar
o projeto, ou seja, se os clientes estiverem insatisfeitos com os
resultados, eles tero a liberdade de sair do projeto.
Mantendo o cliente
Atravs deste artigo, podemos ter uma viso geral sobre

negociao de contratos em projetos que utilizam as tcnicas de metodologias geis, expondo os conceitos, tipos
e comportamentos referentes s negociaes contratuais
para requisitos de softwares.
Como todo paradigma, a metodologia gil continua evoluindo e consequentemente fazendo com que os conceitos
atrelados a ela sejam repensados com o objetivo de melhorar o processo de desenvolvimento de software.
Como j mencionado, a abordagem referente s negociaes de contratos, exposta neste artigo, se aplica perfeitamente a este novo conceito de negociao com requisitos
mutveis, auxiliando e motivando as pessoas envolvidas
no processo de construo de software, alm de propiciar o
melhor aproveitamento do tempo e acompanhamento dos
custos do projeto, realizado pelos gestores e clientes.
Referncias
BECK, Kent. Manifesto for Agile Software Programming. Disponvel em: <www.agilemanifesto.org/>.
Acesso em: 20 jul. 2009.
HIGHSMITH, Jim; CONSORTIUM, Cutter; COCKBURN, Alistair. Agile Software Development: the
business of innovation. 9. ed. Humans And Technology, 2001. 120-127 p.
HODA, Rashina; NOBLE, James; MARSHALL, Stuart. Negotiating Contracts for Agile Projects: A
Practical Perspective. Sardinia: Springer Berlin Heidelberg, 2009. 186-191 p.
SUTHERLAND, Jeff.Agile Contracts: Money for Nothing and Your Change for Free.Disponvel em: <http://
jeffsutherland.com/scrum/2008/08/agile-2008-money-for-nothing.html>. Acesso em: 22 jul. 2009.

Feedback
eu
13
sobre e
s
O processo de negociao torna-se eficiente quando utilizado para manter um bom relacionamento entre o cliente e os
desenvolvedores, uma vez que ambos esto bem informados
para justificar as possveis mudanas de requisitos durante
os ciclos de desenvolvimento.
Um ltimo recurso a ser utilizado manter o cliente sempre na equipe de desenvolvimento. Com essa prtica, os
gerentes conseguem implementar rigorosamente as prticas
Concluso
D
s
Diferentes opes de trabalho
das metodologias geis em suas equipes, pois ele ter um

constante acompanhamento do cliente, tendo ento a possibilidade de realizar frequentes releases, assim como receber
constantes feedbacks.
No entanto, mesmo com todas essas alternativas e vantagens na utilizao de contratos flexveis em projetos com
metodologias geis, ainda comum encontrar alguns clientes
resistentes a esta modalidade contratual, forando as equipes
a utilizar contratos fixos.
edio
ta
no oramento, prevendo uma eventual falha no planejamento

e levantamento de horas. O cliente, como muitas das vezes s
quer um nmero, fica satisfeito.
Vejamos algumas vantagens na utilizao dos contratos
fixos:
Foco no valor de negcio: possibilidade de o cliente determinar a ordem de prioridade de acordo com as necessidades do
negcio, e no pelos interesses de implementao tcnica;
Maior controle do produto de software por parte do cliente:
possibilidade de discutir as inmeras configuraes (features)
que sero usadas durante o projeto, como por exemplo, a
compatibilidade do browser utilizado pela aplicao, caso ela
seja uma aplicao web;
Facilidade em implementao e modificao dos requisitos no decorrer do projeto: flexibilidade para incluso e/ou
alterao de novas funcionalidades do software tornando os
requisitos estveis, mas no congelados.
Engenharia
Nesta seo voc encontra artigos voltados para testes, processo,
modelos, documentao, entre outros
Requisitos em SOA Parte 1

Processo e levantamento de requisitos de negcios em SOA

Neste artigo veremos os principais aspectos dos
requisitos de negcio de projetos SOA, como definir estes requisitos e as formas mais prticas de
identificar servios e requisitos para uma gesto
orientada a servios.
O
Joo Caldas Jnior
caldasjr@gmail.com
Possui mestrado em Cincias da Computao e Matemtica Computacional pela

Universidade de So Paulo. Atualmente
trabalha como consultor de TI da empresa ADVUS Corp e professor da Fundao
Salvador Arena em So Bernardo do Campo - wSP. Tem experincia em projetos de
Engenharia de Software, Engenharia de
Requisitos e Arquitetura Orientada a Servios na rea bancria.
14
s projetos Service-Oriented
Architecture (SOA) quando
comparados a projetos de
desenvolvimento tradicionais na
rea de TI, esto expostos aos mesmos (ou at maiores) desafios no que
implica a elicitao e a modelagem
de requisitos. Para projetos ditos
tradicionais existe uma quantidade significativa de pesquisas e
estudos que identificam que a definio inadequada de requisitos
a principal responsvel por grande
parte dos erros detectados ao longo
do processo de desenvolvimento de
sistemas [4].
As atividades de elicitao e modelagem de requisitos necessitam
de um conjunto de habilidades nicas, pois estas atividades so mais
que tcnicas, envolvendo muitas
vezes exerccios de sensibilidade.
Engenharia de Software Magazine - Requisitos em SOA Parte 1
Para que serve?

Auxiliar na conduo da coleta de requisitos de
Projetos SOA e tornar claros os benefcios de se
ter uma estratgia para identificao de servios
e um inventrio de servios que reflita os processos de negcio da empresa.

Orienta a criao de um processo de elicitao,
documentao e modelagem de requisitos de
negcio voltado a projetos que abordem a estratgia SOA. Auxilia no esclarecimento de algumas
abordagens de identificao de servios e formao de processos de negcio.
Por exemplo, no se pode evitar o fator

humano as pessoas mudam de opinio
sobre o que querem. irreal pensar
que seja possvel capturar 100% das
necessidades ou exigncias, j que na
maioria das vezes elas mudaro. Um
S OA
bom analista de requisitos deve envolver os stakeholders no

processo e criar um ambiente onde fique claro o valor dos
requisitos e a importncia da sua preciso. O analista deve
ainda demonstrar a extrema importncia da participao dos
stakeholders no processo de documentao dos requisitos e
torn-los responsveis pelas alteraes ou omisses na documentao gerada.
Outros estudos mostram que a no eliminao de erros
durante a especificao torna mais difcil e dispendioso o desenvolvimento de uma aplicao, medida que o ciclo de vida
avana para etapas posteriores [2], no entanto fica a questo:
esses estudos podem servir de base para projetos SOA?
Em meio a uma estratgia SOA algumas empresas investem
muito em tecnologia, porm este est longe de ser o maior
problema neste tipo de projeto. Na verdade, um projeto SOA
corre o srio risco de se tornar um desperdcio de tempo e
dinheiro, mesmo contando com uma arquitetura eficiente e
tirando proveito das mais recentes tecnologias de mercado.
Na prtica, nota-se que o verdadeiro diferencial entre sucesso
e fracasso em uma abordagem orientada a servios est em
dar ateno especial aos requisitos das pessoas envolvidas
nessa abordagem. Os requisitos de um projeto SOA podem ser
divididos em dois grupos: requisitos de negcios e requisitos
tcnicos, e ambos devem ter uma ateno diferenciada desde
o incio do projeto.
Neste contexto, este artigo concentra-se nos aspectos dos
requisitos de negcio dos projetos SOA, em como definir estes
requisitos e as formas mais prticas de identificar servios
e capturar requisitos para uma gesto orientada a servios.
Em um prximo artigo pretende-se demonstrar como definir
os requisitos tcnicos, que so outra parte essencial de uma
Arquitetura Orientada a Servios.
Por onde comear?

Uma boa implementao SOA pode trazer um excelente
resultado para uma organizao. Um projeto implementado
de uma forma eficiente pode obter um alto nvel de reuso em
futuros projetos, podendo chegar at a 80% [5], sendo esta
uma taxa surpreendente se comparada com uma arquitetura
tradicional. No entanto, a implantao de um cenrio SOA em
uma organizao no uma tarefa fcil, alm do comprometimento dos funcionrios da organizao para que o projeto
possa ser executado com sucesso, extremante importante a
diviso do projeto por etapas.
Uma abordagem SOA traz consigo uma grande quantidade
de riscos, pois nem tudo s agilidade. Quando se fala em SOA
pensa-se em uma modelo projetado para suportar mudanas,
flexvel, rpido (time to market) e de baixo custo de implementao (considerando apenas seu reuso). Por outro lado tem-se os
riscos devido a complexidade: duplicidade de cdigo, falta de
visibilidade dos servios, dificuldade no reuso, instabilidade,
identificao dos servios e isso s o comeo. Para tornar
todos estes riscos gerenciveis preciso mitig-los.
Um erro inicial, muito comum nas organizaes, tentar
alterar todo o cenrio de desenvolvimento de software de
uma s vez. Essa uma estratgia que traz srios problemas

relacionados cultura da organizao. Outro fator importante que normalmente quando se tenta fazer uma mudana
muito brusca em grande escala, as chances de se conseguir
uma migrao tranquila so mnimas, pois passam a existir
muitos sistemas para se trabalhar ao mesmo tempo e dessa
forma no possvel concentrar os esforos em cada detalhe
necessrio.
Uma soluo que bem aceita pela a maioria dos profissionais
(e autores da rea, por mais incrvel que parea) a concepo
dos projetos em fases: primeiro se escolhe alguns sistemas
menos crticos como prova de conceito (POC), realiza-se a
migrao e observa-se o funcionamento para s depois repetir
o mesmo processo para outros sistemas mais complexos.
Definido o projeto, o primeiro passo a ser dado a identificao dos servios. Para isso, fundamental definir qual
estratgia ser utilizada para essa identificao e quais os
requisitos de negcio mais importantes para cada servio
identificado.
Identificao dos servios

Inicialmente os servios precisam ser isolados de acordo
com seu impacto para o negcio, isto , os servios devem ser
significativos o suficiente para demonstrar valor e benefcios
gerados a partir de um roteiro SOA de longo prazo. Existem
duas principais estratgias que podem ser usadas para o processo de identificao [1]:
Top-down: A estratgia Top-Down mais intuitiva, pois
realizada diretamente a partir dos requisitos de negcio. O
processo de identificao e especificao de servios se baseia
na anlise dos sistemas legados e em possveis servios j
existentes para elaborar uma soluo;
Bottom-up: a estratgia Bottom-Up no seria, na verdade,
uma estratgia real para atingir SOA. Se por um lado, lana
mo de tecnologias como Web Services para encapsular funcionalidades de legado e assim maximizar o seu reuso, por
outro, um convite ao que o autor Joe McKendrick [3] chamou
de JBOWS, (Just a Bunch of Web Services ou simplificando
S um monte de Web Services) que caracteriza projetos SOA
conduzidos sem qualquer formalismo, gerenciamento, testes
especficos e tipicamente orientados apenas a tecnologia. Na
Tabela 1 so apresentados os principais riscos na utilizao
das duas estratgias.
Em uma soluo intermediria e bem mais realista, Thomas
Erl prope uma abordagem meet-in-the-middle, com a
combinao de ambas as estratgias anteriores. Esta abordagem sugere uma anlise de prioridades durante o processo
de identificao dos servios e a definio de um modelo de
inventrio de servios. A recomendao que os servios
de alta prioridade sejam entregues com antecedncia e em
paralelo exista um monitoramento do ambiente de utilizao
dos servios, pois as informaes coletadas por essa monitoria
servem de base para criao de novos servios ou manuteno
dos existentes.
15
Top-Down
Dependncia de apoio da Alta Gerncia ao Projeto.
Bottom-Up
O projeto SOA se tornar meramente um projeto de integrao entre reas distintas.
Excesso de Reunies e Modelagens podem no produzir resultados prticos. Todos os problemas tecnolgicos so resolvidos, mas a arquitetura no atende (nem beneficia) nenhum requisito de negcio.
Tecnologia a ser utilizada pode estar alm da capacidade do grupo e da Implementao de uma Arquitetura JBOWS.
arquitetura atual, o que pode aumentar os custos de maneira significativa.
Tabela 1. Lista dos principais riscos existentes na adoo das estratgias Top-Down e Bottom-Up
Requisitos para um servio

Esta seo descreve as categorias de requisitos de negcio
e o processo que se pode seguir para reunir estes requisitos
para um servio em um projeto SOA. Em um sentido amplo,
as categorias mais importantes para elicitar requisitos para
servios so listadas abaixo (lembre-se, este artigo enfoca
apenas os requisitos de negcio, os requisitos tcnicos para
um servio sero discutidos em um prximo artigo):
Visibilidade: Esta uma das categorias que compartilhada
tanto por requisitos tcnicos como por requisitos de negcio,
e responde a seguinte pergunta: Como um consumidor de
um servio consegue encontr-lo e adquire conhecimento de
como us-lo?. Em termos de negcio importantssimo que o
consumidor de um servio tenha facilidade em descobrir um
servio existente em um inventrio de servios;
Capacidades: Esta categoria deve esclarecer a granularidade usada na identificao das capacidades disponveis
em um servio (fazendo uma analogia com a Orientao a
Objetos, uma capacidade para um servio como um mtodo
para uma classe). Um servio pode oferecer vrias capacidades, servios mais granulares possuem capacidades mais
especificas, enquanto que os menos granulares possuem
capacidades mais genricas. A descrio das capacidades de
um servio deve ser clara e precisa, j que um consumidor
de um servio no deve ter dvidas sobre qual funo ir
fornecer o servio requerido, e qual problema do negcio ele
pretende resolver;
Interao: Esta categoria define requisitos sobre como
ser a interao de um servio com o aplicativo que trocar
informaes com esse servio. Uma premissa bsica que
um servio deve ser fcil de usar. Ao projetar um servio, os
desenvolvedores devem facilitar para consumidores o seu uso.
O consumidor, aps identificar um servio em um inventrio,
buscar uma forma de utilizao prtica deste servio em sua
aplicao. Quanto mais fcil e rpida for a transio entre
identificar e obter os benefcios de um servio, melhor e mais
vezes o servio tende a ser utilizado;
Informao: Esta categoria deve conter requisitos que definam quais os parmetros de entrada e sada para um servio
e o tratamento de excees. A interface de um servio deve
ser projetada como um contrato, um acordo entre consumidor e fornecedor de forma que, se o consumidor cumprir
sua parte (pr-condies), o servio garante o resultado especificado (ps-condies) com algumas excees tambm
especificadas:
Pr-condies: so os parmetros de entrada e os
estados do sistema que devem ser validados antes da
execuo do servio;
16
Ps-condies: especificao do estado do sistema

(por exemplo, elementos criados ou destrudos, atributos
e relacionamentos alterados) ou os parmetros de sadas
garantidos/vlidos aps a execuo do servio. Em
outras palavras, o resultado esperado da execuo
do servio;
Excees: todas as situaes em que a ps-condio
no pode ser garantida, mesmo com a pr-condio
atendida.
Composio: Esta categoria deve conter requisitos que definam relaes entre os servios a serem construdos e suas
capacidades. Uma das principais caractersticas de um servio,
que deve ser perseguida desde o momento da especificao,
a sua capacidade de se compor com outros servios. A atomicidade e/ou granularidade de um servio pode depender de
sua estratgia de descobrimento. Uma abordagem top-down
identificar os processos de negcios, sendo que cada atividade
pode ser desmembrada em subprocessos. Por outro lado, em
uma abordagem bottom-up, os servios vo sendo expostos
por meio das funcionalidades dos sistemas legados existentes,
onde a granularidade e a atomicidade destes servios vo
sendo refinadas at que os mesmos possam ser compostos em
processos de negcios.
Agora que j se sabe o tipo de informao necessria para
capturar, importante falar sobre o processo. Em um mundo
SOA importante identificar os provedores de servios ou
aplicativos, para se descrever em termos comerciais, qual a
utilidade real de cada servio. Infelizmente, nem sempre se
conhece todos os provedores de um servio. Neste caso,
preciso localizar os consumidores de servios (partes interessadas do negcio para quem est sendo criado esse servio)
e pedir que eles descrevam o que querem que o servio
realize. Apesar dessa descrio ser imprescindvel, no se
pode tentar chegar a todos os consumidores em potencial,
isso no vivel.
Do ponto de vista do processo, os consumidores de servios devem ser capazes de descrever o servio a partir de
requisitos funcionais e no funcionais. O primeiro passo
capturar requisitos a partir das categorias descritas anteriormente, utilizando qualquer metodologia ou ferramenta
de requisitos, no entanto, a opo por usar casos de uso
altamente recomendvel.
Em um projeto SOA, preciso envolver de forma ativa
todos os stakeholders envolvidos nos servios a serem disponibilizados, pois este um dos fatores de grande risco para
o projeto. Ao tentar vender o conceito de SOA, no se deve
procurar apenas o pessoal tcnico, procurar os executivos
S OA
corporativos dos setores de vendas e marketing, por exemplo,

torna muito mais fcil a construo de aplicaes corporativas
para o setor de tecnologia. Todas as informaes que forem
coletadas devem ser documentadas de alguma forma. Uma
dica inicial adotar um formato padro para descrever os
casos de uso e um pequeno manual de boa escrita, pois so
solues que funcionam e do menos dor de cabea.
Os gerentes precisam entender o conceito fundamental de
servios, como pensar seus negcios e processos de negcio
em termos de servios, bem como identificar quais servios
podem ser reutilizados atravs de funes de negcios. Em
um cenrio ideal, nesse ponto existiria a conjuno entre os
projetos SOA da empresa e os projetos BPM (Business Process
Management), ento o detalhamento dos casos de uso poderia
ser completado por meio de Diagramas de Atividades ou BPDs
(Business Process Diagram), como sugere a Figura 1.
Vale dizer que BPM um conceito que tem sua origem em
uma necessidade gerencial, o qual pode ser suportado por
ferramentas de TI com o intuito de tornar mais gil a gesto
dos processos. O pblico-alvo de BPM inclui desde pessoas
ligadas gesto de negcios at profissionais de TI envolvidos
na implantao de ferramentas de apoio. Um projeto SOA pode
se beneficiar desses conceitos para atender de forma muito
mais direta as necessidades do negcio.
Portanto, evidente que uma empresa conhecedora de seus processos e que preferencialmente j tenha uma iniciativa de BPM
estar bem melhor preparada para fazer uma definio mais
slida do seu inventrio de servios. No caso dela no possuir
esse mapeamento, ser necessrio fazer a definio dos servios
recuperando a documentao de sistemas ou, nos casos mais
extremos, analisando-se o prprio cdigo-fonte dos sistemas.
Tratando-se, sem dvida, de opes bastante indesejveis.
Outro benefcio que uma iniciativa BPM traz para um projeto
SOA a possibilidade de tornar mais tangveis os objetivos do
projeto. Em algumas empresas, as reas de negcio tratam os
benficos de SOA como indiretos, e impe restries no momento de aprovar investimentos nesta rea. De fato, segundo o
Gartner Group, o principal motivo de insucesso das iniciativas
de SOA a dificuldade em justificar o investimento para as
reas de negcio.
Apesar de SOA e BPM, quando combinados, serem uma
opo muito interessante e claramente vantajosa em termos
de negcio, cada uma tem sua prpria complexidade e so
solues diferentes para problemas diferentes.
Quais os requisitos de uma estratgia SOA?

Deve-se, de antemo, estar ciente que SOA envolve muito mais
do que o mero desenvolvimento de software. A criao de uma
arquitetura baseada em um inventrio de servios demanda uma
metodologia de desenvolvimento centralizada e uma equipe
organizada de gerentes de projeto, arquitetos e desenvolvedores.
Tambm requer uma equipe executiva solcita, que prepare o
ambiente para que o pessoal de TI possa esmiuar os detalhes
dos processos da empresa. A compreenso destes processos o
ncleo de uma transformao do negcio baseada em SOA.
Figura 1. O detalhamento de cada caso de uso pode ser feito por meio
de BPDs ou Diagramas de Sequncia
Para aumentar a possibilidade de reutilizao dos servios,

ideal que exista uma metodologia de desenvolvimento de
software nica, centralizada e aplicada na prtica, de modo
que reas diferentes no criem o mesmo servio (e o que
ainda pior) de maneiras diferentes. Como j foi dito, imprescindvel a existncia de um inventrio centralizado para que
os desenvolvedores saibam onde procurar servios e a rea
de TI saiba por quem eles esto sendo utilizados. Os servios
tm de ser bem documentados, para que os desenvolvedores
saibam sua utilidade, suas formas de integrao e as normas
para utilizao. Existem empresas, por exemplo, que possuem
regras tarifrias para a utilizao dos servios e criam mtricas de desempenho para garantir que os servios funcionem
bem e no sobrecarreguem a rede corporativa.
Quais os benefcios de um bom processo de requisitos

SOA?
Os artefatos de requisitos produzidos a partir de uma estratgia SOA, podem gerar benefcios em termos de documentao
no s para o projeto, mas para a empresa como um todo.
Na verdade, tais benefcios esto ligados s aes realizadas
durante o processo de elicitao, anlise e modelagem dos
requisitos, tais como:
Tornar dados acessveis por meio de uma viso unificada
dos negcios;
Minimizar custos associados migrao da infraestrutura;
Minimizar a exposio a riscos por meio de anlises da qualidade dos dados usados na parametrizao dos servios;
Aumentar a agilidade da organizao, condensando informaes estruturadas e no-estruturadas, que podem ser
conectadas por meio de aplicativos e processos de negcios.
17
18
[1] Erl, T. SOA Principles of Service Design (The Prentice Hall Service-Oriented Computing
Series from Thomas Erl), Prentice Hall PTR, Upper Saddle River, NJ, 2007
www.thomaserl.com
[2] Hofmann, H.F. e Lehner, F. Requirements engineering as a success factor in software
projects, IEEE Software, pp. 58-66 vol. 18, n. 4., 2001
www.computer.org/portal/web/csdl/abs/mags/so/2001/04/s4058abs.htm
[3] McKendrick, J. The Rise of the JBOWS Architecture (or Just a Bunch of Web Services
www.webservices.org/weblog/joe_mckendrick/the_rise_of_the_jbows_architecture_or_
just_a_bunch_of_web_services.
[4] STANDISH GROUP. Chaos: pesquisa sobre o desenvolvimento de software e o panorama
catico da indstria de software dos dias de hoje.
www.standishgroup.com/chaos.html
[5] Zaidan, P. SOA atinge at 80% do reuso com governana, diz BearingPoint. [S.l.]
www.decisionreport.com.br

Feedback
eu
sobre e
s
Neste artigo, viu-se como identificar alguns servios iniciais

como parte de um projeto de SOA, as formas de como elicitar
requisitos de negcio para estes servios e como documentar
estes requisitos utilizando tcnicas e processos atuais. No
prximo artigo, supondo que a prova de conceito (POC) foi
Referncias
D
s
Concluso
bem sucedida, chegou hora de lanar um programa SOA

generalizado. Para tanto, sero discutidas formas para coletar,
gerenciar e comunicar necessidades tcnicas, que passam a ser a
principal questo na implementao deste tipo de projeto.
edio
ta
Porm todos os benefcios de um modelo orientado a servios devem ser contextualizados. Se uma empresa no tiver
mais de dois sistemas primrios que exijam algum nvel de
integrao, improvvel que o modelo proporcione grandes
benefcios. Em meio a toda propaganda em torno da SOA,
esquece-se facilmente que a metodologia de desenvolvimento no traz em si vantagens, as vantagens so proporcionadas
pelo efeito que ela tem sobre uma infraestrutura redundante
e com pouca integrao.
A criao de um bom aplicativo orientado a servios normalmente envolve mais trabalho do que integrao de aplicativos existentes (atualmente a integrao tradicional de
aplicativos o principal projeto SOA em muitas empresas).
Assim, um projeto SOA tende a gerar um custo inicial extra
e para que este investimento produza benefcios, preciso
eliminar custos em outro ponto qualquer do processo, j
que a prpria metodologia no gerar benefcios para o
negcio. Portanto, o primeiro passo descobrir se existem
aplicativos redundantes e mal integrados que poderiam ser
consolidados ou eliminados. Se este for o caso, ento podem
existir benefcios potenciais.
Engenharia
Nesta seo voc encontra artigos voltados para testes, processo,
modelos, documentao, entre outros
O Papel Evolutivo do Software

Conceitos bsicos sobre manuteno e evoluo de software

Vincius Rodrigues de Souza
vrsouzainfo@gmail.com
Graduado em Sistemas de Informao pela

Faculdade Metodista Granbery em Juiz de Fora,
graduando em Engenharia Civil pela universidade Federal de Juiz de Fora e atuou na Prefeitura
de Juiz de Fora na rea de desenvolvimento e
testes de software.
Ricardo Cunha Vale

valericc@gmail.com
Cursa Especializao em Gerncia de Projetos em

Engenharia de Software no Centro de Ensino Superior de Juiz de Fora e Graduado em Sistemas
de Informao pela Faculdade Metodista Granbery de Juiz de Fora. Atuou na Prefeitura de Juiz
de Fora na rea de desenvolvimento e testes de
software, alm de ter atuado na rea de desenvolvimento em projeto da Fundao COPPETEC.

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 dos Cursos de
Bacharelado em Sistemas de Informao do
Centro de Ensino Superior de Juiz de Fora e
da Faculdade Metodista Granbery, Analista de
Sistemas da Prefeitura de Juiz de Fora, Editor
da Engenharia de Software Magazine.
anuteno significa um conjunto de modificaes realizadas no software que pode

ocorrer durante o desenvolvimento ou
aps a sua entrega, ou seja, durante a sua
utilizao. As modificaes podem ser
de vrias formas e para atingir objetivos
distintos. So utilizadas para a correo
de erros, atualizao do sistema, aperfeioamento do software ou para sua
adaptao a uma nova realidade.
A manuteno de software, at pouco
tempo, sempre foi considerada na etapa
de desenvolvimento algo secundrio, de
pouco valor. Era considerada por muitos
como uma fonte de gastos que comprometiam a criao de software.
Durante o desenvolvimento, os sistemas eram elaborados sem a preocupao
de que um dia eles precisariam sofrer
alguma alterao para se adequarem s
novas necessidades do usurio. Quando isso ocorria, a manuteno era feita
de forma precria, pois no existia um
gerenciamento adequado para que fossem feitas as mudanas. Com isso, tais
mudanas poderiam gerar novos erros
Esse artigo apresenta algumas definies de manuteno de software, os tipos existentes, os impactos
de sua aplicao e como utilizada durante o desenvolvimento de um sistema.
Para que serve?

A manuteno de software um processo de melhoria de um software j desenvolvido, ou que est
sendo desenvolvido. Com a manuteno tambm
possvel corrigir erros que so encontrados durante
a utilizao do sistema pelo usurio ou por testes
realizados pelos desenvolvedores.

A manuteno de software visa prever e corrigir
quaisquer problemas que possam ocorrer, ou que
venham a ocorrer, durante a utilizao de um produto de software.
que aumentariam ainda mais o tempo

necessrio para que fossem feitas as
correes desejadas pelo usurio.
Atualmente, um problema chave para
as organizaes implementar e gerenciar a manuteno em seus sistemas
legados. Sistemas legados so sistemas
imprescindveis para os negcios de uma
19
organizao. Em geral, possuem documentao precria ou

inexistente e passaram, ao longo dos anos, por manutenes
realizadas por diversos profissionais, sem seguir boas prticas
de engenharia de software.
Nesse artigo, nesse artigo sero apresentados conceitos
bsicos de manuteno e evoluo de software, incluindo
definies e processos realizados durante a manuteno
de software, bem como os tipos de manuteno e exemplos de refatorao que podem ser realizados durante este
processo.
Evoluo de Software
Os sistemas geralmente refletem situaes do mundo
real e, com isso, h uma necessidade que o software mude
acompanhando as mudanas de requisitos impostos pelo
ambiente em que est inserido. Se o sistema no sofre essas
mudanas, pode ficar obsoleto e cair em desuso.
O envelhecimento de um software um processo inevitvel, mas possvel de ser compreendido e suas causas previstas, para que sejam minimizados os impactos dos danos
causados por esse envelhecimento. Ele pode se dividir em
duas vertentes: quando as mudanas necessrias no so
implementadas e o sistema no adequado s novas regras
de negcio utilizadas, e a segunda quando as adaptaes
so feitas de maneira desordenada e acarretam problemas
para o sistema como um todo, gerando novos erros e diminuindo sua manutenibilidade.
As desvantagens causadas pelo envelhecimento de um
software so a perda de desempenho devido a modificaes
no adequadas na sua estrutura interna, gerao de novos
erros devido a alteraes indevidas no cdigo e perda de
usurios devido falta de meios para concorrer com verses
mais recentes de sistemas semelhantes, como por exemplo,
a utilizao em sistemas operacionais diferentes.
Atravs dessas caractersticas, qualquer software que
no tenha sido projetado para atuar baseado num tempo
de vida muito curto, pode vir a sofrer os efeitos nocivos do
envelhecimento. Apesar de inevitvel, estes efeitos podem
ser retardados ou consideravelmente diminudos, desde
que sejam seguidos alguns cuidados no desenvolvimento e
evoluo do software em questo. Dentre alguns cuidados
est a manuteno de software.
De acordo com Sommerville, a evoluo de software compreende as mudanas que iro ocorrer em um programa a
fim de deix-lo completo e, se possvel, livre de erros.
Para que essa evoluo acontea necessrio que sejam
considerados diversos fatores que serviro de base para
concluir se o sistema atual deve sofrer uma evoluo, ou
deve ser abandonado para que um novo sistema possa ser
construdo com base nos requisitos do software atual.
Os fatores que devem ser levados em conta so: custo
envolvido no processo, a confiabilidade do software aps
a manuteno, a capacidade que possuir de se adaptar a
mudanas futuras, seu desempenho, limitaes de suas
atuais funes, e ainda as opes existentes no mercado que
20
Engenharia de Software Magazine - O Papel Evolutivo do Software
atendam ao mesmo problema de maneira mais completa,

rpida e barata. Se o software funciona, comum que no
seja criado um novo sistema, mas apenas ajustes necessrios
que so desejados por quem o utiliza, como quando ocorrem
mudanas nas regras de negcio.
Definies
De acordo com a IEEE, a manuteno de software pode ser
considerada como a prtica da modificao de um produto
de software que j foi entregue ao cliente, que pode ser para
correo de algum defeito, melhora de seu desempenho e
ainda para adaptao a algum outro ambiente.
Esse conceito muito abrangente e serve para qualquer software, porm existem diferenas entre tipos de manuteno
de softwares distintos. Existem alguns grupos de sistemas
que diferenciam em suas funes e, por isso, diferentes
mtodos durante a manuteno devem ser aplicados.
Existem basicamente trs categorias de sistemas e mtodos diferenciados para cada um. No primeiro grupo esto
softwares cujos resultados so exatos, esperados e previsveis, e que considerando uma correta implementao dos
mtodos durante sua construo, dificilmente vo necessitar
de manuteno. Um exemplo deste tipo de software so
aqueles que realizam operaes matemticas como uma
simples calculadora.
No segundo grupo esto os sistemas que buscam simular
situaes do mundo real, sendo praticamente impossvel
prever todas as alternativas possveis de resultados. Estes
sistemas so construdos sobre uma anlise mais abstrata,
sendo passvel de uma interpretao ambgua e baseado em
possibilidades. Sistemas que fazem parte dessa categoria so
os que seguem algumas regras de negcio mais complexas,
por esse motivo necessitar de maior manuteno comparada ao grupo anterior.
O terceiro grupo engloba os sistemas que consideram
as caractersticas do ambiente em que esto funcionando,
necessitam de adaptao na medida em que o ambiente
sofre alguma alterao. Os softwares dessa categoria geralmente so das reas contbeis e econmicas e esto presentes no cotidiano das organizaes. Pelo fato das regras
mudarem constantemente, inevitvel a necessidade de
manuteno.
Devido a essa diversidade de sistemas, devem existir vrias
formas de se fazer manuteno que esto retratadas posteriormente. Devem ser realizadas com cautela, pois podem
ser includos novos defeitos no software, e dependendo do
seu tipo, podem at mesmo ser considerados como um novo
ciclo de desenvolvimento.
Processos de Manuteno de Software

A atividade de manuteno requer o cumprimento de
algumas etapas consideradas adequadas para se obter um
resultado positivo. Deve-se primeiramente avaliar a documentao e cdigo existentes, juntamente com a arquitetura,
estrutura de dados e interface. Posteriormente, identificar
M anuteno
as modificaes necessrias e avaliar seus impactos. Em seguida, realizar as modificaes e test-las atravs da aplicao de testes.
Alguns problemas podem ocorrer durante a realizao de
algum processo de manuteno. Eles devem ser na medida
do possvel previstos para poder ser evitados, tais como:
Ausncia ou deficincia na documentao;
Dificuldade na identificao de manutenes realizadas
anteriormente;
Falta de controle de verso;
Baixa manutenibilidade do software.
Alm disso, efeitos colaterais podem ocorrer com a realizao
desses processos:
Modificao da estrutura do cdigo;
Incluso de cdigos com erros;
Desatualizao da documentao.
Atravs dessas caractersticas, deve-se identificar e registrar
todas as partes que foram afetadas pela modificao.
Para a manuteno de software, os sistemas devem sofrer
mudanas de acordo com o contexto em que esto inseridos.
Para melhorar o processo de manuteno devem ser levadas
em conta as mudanas ocorridas no ambiente em que est
inserido o sistema.
Na manuteno de software existem quatro fases que so
introduo, crescimento, maturidade e declnio. Destaca-se
que durante a fase de introduo existe um grande suporte
ao usurio, perodo em que so concebidas as primeiras idias
sobre o sistema. As fases de maturidade e de crescimento do
software so de ajustes, onde o sistema j est concretizado
e muitas vezes correes aparecem naturalmente. Ainda na
fase de maturidade, podem ser realizadas melhorias no programa. Durante essas fases necessrio que sejam realizados
testes e atualizao da documentao para avaliar as partes
modificadas e acrescentadas na aplicao. Na fase de declnio
o sistema chega ao final da vida til e deve ser avaliado se o
sistema deve ser retirado de operao. A avaliao deve ser
feita com base nos aspectos econmicos como, por exemplo,
substituio de tecnologias, ou at mesmo para conseguir
independncia de fabricante.
Tipos de Manuteno
As aes ligadas atividade de manuteno de software
foram classificadas de acordo com sua natureza em quatro
categorias:
Manuteno Corretiva: trata de erros de funcionalidade
emergenciais, realizada sob demanda, em decorrncia de
falhas observadas, causadas por erros e defeitos encontrados durante a utilizao do software. Inclui tambm
a eliminao de problemas de configurao encontrados,
reinstalao de sistemas com problemas de configurao,
criao de novas verses do software, combinao de verses
diferentes de software existentes, bem como a criao de
verses paralelas de software e/ou configurao para teste
e correo de problemas ou necessidades particulares de

usurios. o tipo mais comum, j que nem sempre o sistema passa por testes eficientes, e quando so realizados,
no so capazes de encontrar determinados erros que s
vm tona atravs da utilizao do software.
Manuteno Adaptativa: modifica o software para se
adaptar a outro ambiente externo, como novas verses
de sistemas operacionais, diferentes bancos de dados,
componentes diferentes, perifricos e outros elementos
do sistema. Como exemplo, pode ser citado uma troca no
banco de dados. Por mais genrico que um sistema possa
ser, ele necessita de alteraes para que todos os mtodos
funcionem corretamente. A partir da, os desenvolvedores
executam uma manuteno nesse software a fim de adaptlo ao novo ambiente.
Manuteno Perfectiva: significa a incluso de novos
requisitos, acrescentando novos recursos de funcionalidade, modificaes de funes existentes e ampliaes.
Normalmente estas alteraes so realizadas a partir de
solicitaes de usurios, tais como a incluso de emisso
de algum tipo de relatrio no previsto durante o desenvolvimento do sistema.
Manuteno Preventiva: muitas vezes associada a reas
em que atividades crticas esto envolvidas, onde segurana
fator determinante. So realizadas alteraes no sistema
com o objetivo de aumentar a confiabilidade e manutenibilidade do software. Essas alteraes devem ser baseadas sobre
uma avaliao contnua das interfaces internas e externas,
a fim de evitar interrupes indesejadas. Normalmente so
aplicadas prticas como a refatorao que no alteram as
funcionalidades, no acrescentam requisitos, mas melhoram
o desempenho e a estrutura interna do cdigo.
Dentre essas classificaes, nas empresas de software
os tipos de manuteno mais presentes so as do tipo
corretivas e perfectivas, pois quase sempre necessria a
correo de erros que so encontrados durante o uso do
sistema, alm do acrscimo de funcionalidades adequando
as regras de negcio.
Refatorao e Manuteno
Martin Fowler afirma que a refatorao pode ser considerada uma tcnica ou ferramenta de auxilio no desenvolvimento e manuteno, contribuindo para o tempo de vida
do software. De acordo com ele, um sistema mal projetado
geralmente precisa de mais linhas de cdigo para funcionar, que quase sempre est duplicado em lugares diferentes
para realizar a mesma coisa.
A eliminao desse excesso de cdigo importante na
melhora do projeto, pois quanto mais difcil for a visualizao das regras de negcio a partir do seu cdigo, mais
difcil ser mant-lo futuramente. H mais cdigo para ser
compreendido e quando se faz uma alterao, deve ser feita
em vrios outros lugares onde o sistema faz praticamente
a mesma coisa.
21
A refatorao uma modificao no sistema que no altera seu comportamento do ponto de vista funcional, mas
melhora alguma caracterstica no funcional como simplicidade, flexibilidade, clareza e desempenho. As alteraes
que podem ser realizadas atravs da refatorao envolvem
a mudana do nome de variveis, mudana na interface dos
objetos, mudanas arquiteturais, encapsulamento de um
novo mtodo e a generalizao de mtodos. O exemplo a
seguir contm a assinatura de dois mtodos que aparentemente tem a mesma funo, porm, um deles passou por um
processo de refatorao que o deixou muito mais genrico e
eficiente. O primeiro mtodo inicialmente era capaz de elevar ao quadrado qualquer nmero passado por parmetro,
j o seguinte, eleva um nmero informado pelo usurio a
uma potncia qualquer de valor inteiro.
Figura 1. Diagrama de Classes
potenciaQuadrada(float x) => potencia(float x, int y)
Esse tipo de prtica sempre esteve presente de maneira

implcita, porm foi formalizada h pouco tempo trazendo
vrios benefcios como a criao de um vocabulrio comum,
facilitando a disseminao das informaes. Hoje uma
das bases de utilizao da XP(Extreme Programming), mas
no se limita somente a ela, sendo largamente utilizada em
qualquer contexto.
Para iniciar o processo de qualquer refatorao necessrio que se tenha um conjunto de testes que verifiquem a
funcionalidade do cdigo, pois durante o processo podem
ser gerados novos defeitos e eles ajudaro a detect-los. importante observar que quando h necessidade de adicionar
uma funcionalidade a um programa e o cdigo fonte no est
estruturado de uma forma que torne a implementao desta
funcionalidade conveniente, primeiro deve-se refator-lo de
modo a facilitar a implementao da funcionalidade e, s
depois, realizar a implementao.
Outro exemplo simples de refatorao que ocorre ainda no
mbito do projeto, quando o sistema contm classes que
possuem atributos que se repetem em classes diferentes
(Figura 1).
Neste caso, a soluo mais simples a criao de uma classe
pai para que as classes que contm os atributos em comum
entre as demais classes herdem dela, como apresentado na
Figura 2.
Com relao ao cdigo da aplicao, j existe uma lista
de refatoraes identificadas, padronizadas e nomeadas
para que possam ser utilizadas. Durante o processo de
refatorao a ser realizado num sistema importante que
se tenha um inventrio sobre todas as modificaes que
foram realizadas, contendo, se possvel, a identificao da
refatorao, um resumo da situao na qual ela necessria e o que ela desempenha, a motivao para aplic-la na
situao determinada, o mecanismo de gerao do cdigo
refatorado e, se possvel, uma cpia do cdigo antes e depois
da refatorao.
A seguir est um exemplo de coleta de dados de uma refatorao, denominada Extract Method, que tem como intuito
22
Figura 2. Diagrama de Classes refatorado
quebrar um bloco grande de cdigo em outros mtodos

menores, diminuindo o acoplamento no cdigo.
Nome: Extract Method
Resumo: voc tem um fragmento de cdigo que poderia
ser agrupado. Mude o fragmento para um novo mtodo e
escolha um nome que explique o que ele faz.
Motivao: uma das refatoraes mais comuns. Se um
mtodo longo demais ou difcil de entender e exige muitos
comentrios, extraia trechos do mtodo e crie novos mtodos para eles. Isso vai melhorar as chances de reutilizao
do cdigo e vai fazer com que os mtodos que o chamam
fiquem mais fceis de entender. O cdigo fica parecendo
comentrio.
Mecnica:
Crie um novo mtodo e escolha um nome que explicite
a sua inteno (o nome deve dizer o que ele faz, no como
ele faz).
Copie o cdigo do mtodo original para o novo.
Procure por variveis locais e parmetros utilizados pelo
cdigo extrado.
a. Se variveis locais forem usados apenas pelo cdigo
extrado, passe-as para o novo mtodo.
b. Caso contrrio, veja se o seu valor apenas atualizado pelo cdigo. Neste caso substitua o cdigo por uma
atribuio.
M anuteno
c. Se tanto lido quando atualizado, passe-a como parmetro.

Compile e teste.
O cdigo da Listagem 1 oferece algumas oportunidades
para refatorao. A primeira ao ser a extrao do mtodo para imprimir cabealho que, neste caso, no utiliza
nenhum tipo de varivel que poderia implicar numa maior
complexidade na extrao do mtodo.
O resultado da refatorao pode ser observado na Listagem 2.
Uma nova refatorao para extrao de mtodo pode ser
aplicada como, por exemplo, na extrao do clculo da dvida. Nesse caso, uma varivel local utilizada no clculo,
e precisar ser utilizada no restante do mtodo.
A Listagem 3 apresenta o resultado da refatorao. Neste
caso, o mtodo criado teve que retornar o resultado do
clculo, sendo atribudo a uma varivel que pode ser utilizada no restante do algoritmo original que, neste caso,
tambm teve o mtodo de imprimir a dvida extrado via
refatorao, recebendo o parmetro contendo o valor da
dvida calculada.
Sendo assim, a refatorao ajuda a desenvolver software
mais rapidamente porque evita que o projeto do sistema
se deteriore, melhorando o processo de manuteno e otimizao do tempo gasto no desenvolvimento.
Manuteno de cdigo sem documentao

Trata-se de cdigo que no tem documentao, ou a documentao est incompleta, ou ainda, que nenhum membro
da equipe que desenvolveu est mais no projeto. Tambm
aquele que possui comentrios no cdigo fonte que somente
quem desenvolveu quem realmente entende, ou utilizam
nomenclaturas para campos e variveis fora do contexto
do sistema, como a, x ou z.
Com esse tipo de cdigo algumas sugestes podem ser
adotadas. Primeiro deve-se estudar o programa para uma
melhor compreenso da sua finalidade. Em seguida, devem
ser identificados os fluxos das informaes. Posteriormente
a documentao do sistema deve ser avaliada e compreendida, podendo-se acrescentar comentrios que visem
auxiliar quem estiver fazendo ou far a manuteno do
cdigo. Finalmente, devem ser criados registros detalhados de quais atividades foram feitas no sistema que est
em manuteno. Tambm aconselhvel que seja mantida
guardada sempre uma verso do programa original.
Custos de Manuteno
De acordo com Pressman, a manuteno de software
pode ser responsvel por mais de 70% de todo o esforo
despendido por uma organizao. E essa porcentagem
continua aumentando medida que mais software produzido (Figura 3).
Para este autor, manuteno de software bem mais que
consertar erros. H questes que so levadas a efeito depois
que o software liberado para uso:
Listagem 1. Cdigo a ser refatorado

void imprimeDivida () {
Enumerate e = _pedidos.elementos ();
double divida = 0.0;
// imprime cabealho
System.out.println (***************************);
System.out.println (*** Dvidas do Cliente ****);
// calcula dvidas
while (e.temMaisElementos ()){
Pedido cada = (Pedido) e.proximoElemento ();
divida += cada.valor ();
}
// imprime detalhes
System.out.println (nome: + _nome);
System.out.println (divida total: + divida);
}
Listagem 2. Cdigo refatorado com a extrao do mtodo de impresso do
cabealho
imprimeCabecalho ();
// calcula dvidas
}
//imprime detalhes
System.out.println(nome: + _nome);
System.out.println(divida total: + divida);
}
void imprimeCabecalho () {
System.out.println (*** Dvidas do Cliente ****);
}
Listagem 3. Cdigo refatorado com a extrao dos mtodos de clculo e
impresso da dvida
imprimeCabecalho ();
double divida = calculaDivida ();
imprimeDetalhes (divida);
}
double calculaDivida ()
{
}
return divida;
}
void imprimeDetalhes (double divida) {
System.out.println(nome: + _nome);
System.out.println(divida total: + divida);
}
Manuteno ocorre por que preciso considerar que os

testes que possivelmente sero realizados no sistema no
cobriro todos os erros latentes num grande sistema de
software. E durante o uso de qualquer programa, erros
ocorrero e sero relatados ao desenvolvedor;
23
Situaes que aparecem e podem ser resolvidas de maneira imediata e que envolvem aspectos computacionais,
como a utilizao de um novo sistema operacional ou
mudana no hardware;
medida que o software usado, novas recomendaes de
modificaes em funes existentes e de ampliaes gerais
so recebidas dos usurios;
Manuteno ocorre quando o software modificado para
melhorar a confiabilidade ou a manuteno futura, ou para
oferecer uma base melhor para futuras ampliaes.
O custo da manuteno de software tem aumentado
consideravelmente durante os ltimos anos. Dentre vrios
fatores que contribuem para esse aumento esto:
Instabilidade da equipe: h um aumento de custo em
razo de equipes de desenvolvimento estarem sujeitas a mudanas. Sendo que muitas vezes a equipe que
desenvolveu o sistema no a mesma que equipe que
realiza a manuteno, ou seja, no compreendem o sistema, sendo necessrio um maior esforo no processo de
manuteno.
A responsabilidade contratual: pode ocorrer dos desenvolvedores no terem registrado em contrato a responsabilidade de manuteno e, portanto, no h incentivo para
projetar o sistema de forma que esteja preparado para
mudanas futuras. O contrato de manuteno separado
do contrato de desenvolvimento, sendo que a empresa que
desenvolveu no necessariamente a mesma que realiza
a manuteno. No desenvolvimento, a equipe pode optar
em economizar esforos, o que pode aumentar os custos
na manuteno.
Habilidade da equipe: geralmente as pessoas responsveis pela parte de manuteno possuem pouco conhecimento e experincia com aquele domnio de aplicao.
A idade e estrutura do sistema: o sistema quando envelhece se torna difcil de ser entendido e alterado como, por
exemplo, ter sido desenvolvido em uma linguagem antiga,
ou sem uso de tcnicas de engenharia de software.
Durante a dcada de 1970, a manuteno era responsvel
por um ndice entre 35% e 40% do oramento do software
para uma organizao de sistemas de informao. Na
dcada de 1980 esse valor chegou a 60%. Muitos estudos
realizados apontaram para um custo crescente da evoluo de software no ciclo de vida dos sistemas. A Figura 4
resume os resultados de que a manuteno de software
comparada ao custo total de um sistema vai sempre
crescendo, tendo provavelmente passado agora da casa
dos 90%. Atravs desses valores, pode-se concluir que o
custo de desenvolvimento de um novo sistema passou a
ser insignificante perto do recurso que ser consumido
durante sua vida.
Estes dados podem ser perfeitamente compreendidos,
pois muitos sistemas que foram desenvolvidos nos anos
70 ou 80 continuam sendo utilizados e mantidos. Portanto,
24
Figura 3. Custos proporcionais de manuteno de software
Figura 4. Parte da manuteno no custo total de um software
nesses casos, o custo do seu desenvolvimento representa

uma parte cada vez menor do custo total.
A engenharia de software busca utilizar melhores mtodos de planejamento e desenvolvimento e um objetivo
implcito desta busca parece ser que, com um melhor
desenvolvimento, muitos dos problemas da evoluo
de software podem ser minimizados, especialmente a
manuteno.
Ferramentas de apoio manuteno de

software
Hoje no mercado existem ferramentas que foram desenvolvidas para auxiliar os desenvolvedores a realizarem
a manuteno de software. No ser demonstrado nesse
artigo uma ferramenta especfica para gerenciar a manuteno de software. Ao invs disso, iremos explicar de
forma geral como podem auxiliar a equipe de desenvolvimento e gerncia durante a tomada de decises.
Atualmente existem ferramentas que possuem recursos direcionados ao gerenciamento de equipamentos e
auxlio mo-de-obra, por exemplo, tentando maximizar tempo e produtividade. Podem tambm direcionar
recursos para correo e preveno de falhas nos produtos, alm de gerar relatrios, grficos e indicadores
gerenciais. Esses relatrios e indicadores permitem que
a gerncia tenha um domnio maior sobre os processos
de desenvolvimento e sobre os produtos construdos.
M anuteno
Muitas dessas ferramentas permitem que o gerente do

projeto receba notificaes sobre algum ocorrido, como
alarmes e anomalias.
Existem ainda outras ferramentas que podem ser usadas
para auxiliar a equipe que ir realizar a manuteno do
sistema. So ferramentas que realizam controle de verso
das aplicaes. O controle de verso permite o gerenciamento de diferentes verses do cdigo fonte da aplicao
ou da documentao do sistema. Com o versionamento, a
manuteno de software pode se beneficiar de algumas
funcionalidades que so muito teis para implantao
da manuteno no projeto, como o registro de todas as
modificaes realizadas ou a recuperao de uma verso
especfica de um produto.
Outra vantagem que mais de um desenvolvedor pode realizar a manuteno em determinada parte do programa ao mesmo tempo. Ao alterar alguma parte do cdigo,
possvel unir diferentes modificaes, e se o cdigo realiza a
mesma rotina, pode-se escolher a melhor implementao.
O que pode ser feito no cdigo fonte pode ser feito nos
documentos relacionados ao sistema. primordial que a
documentao esteja sincronizada e condizente com o que
est sendo feito na aplicao. As ferramentas de controle de
verso realizam o gerenciamento do cdigo da aplicao,
podendo, tambm, realizar o gerenciamento da documentao usada no sistema.
Outras ferramentas apiam o relato de defeitos e solicitaes de mudanas, fazendo o controle do ciclo de vida
de uma solicitao de mudana.
Referncias
Bennett, K. H.; Rajlich, V. T. (2000) Software maintenance and evolution: a roadmap, In:
Conference on The Future of Software Engineering, Limerick, Ireland, June.
Bhatt, P.; Shroff, G.; Misra, A. K. (2004) Dynamics of software maintenance, ACM SIGSOFT
Software Engineering Notes, v. 29, n. 5, p. 1-5.
Basili, V. (1990) Viewing Maintenance as Reuse-Oriented Software Development, IEEE
Software, v. 7, n. 1, p. 19-25.
Chapin, N. (1986) Software maintenance: A different view, In: Conference on Software
Maintenance, Orlando, FL, USA, November.
Dart, S.; Christie, A. M.; Brown, A. W. (2001) A Case Study in Software Maintenance, Technical
Report, Carnegie Mellon University.
Dekleva, S. M. (1990) Annual Software Maintenance Survey: Survey Results, Software
Maintenance Association, Vallejo, California, USA.
________. (1992) Delphi study of software maintenance problems, In: Conference on
Software Maintenance, Orlando, FL, USA, November.
De Lucia, A., Pompella, E., Stefanucci, S. (2004) Effort estimation for corrective software
maintenance. In: 14th International Conference on Software Engineering and Knowledge
Engineering, Ischia, Italy, July.
IEEE (1998) Std 1219 IEEE Standard for Software Maintenance, Institute of Electrical and
Eletronic Engineers, New York, NY, USA.
ISO/IEC 12207 (1998) Standard for Information Technology - Software Lifecycle Processes,
International Standard Organization, New York, NY, USA.
ISO/IEC 15504 (2003) Software Process Assessment, International Standard Organization,
New York, NY, USA.
Koskinen, J.; Salminen, A.; Paakki, J. (2004) Hypertext support for the information needs of
software maintainers, Journal of Software Maintenance and Evolution: Research and Practice,
v. 16, n. 3 , p. 187-215.
Concluso
Kung, H.; Hsu, C. (1998) Software Maintenance Life Cycle Model, In: International Conference
on Software Maintenance, Bethesda, Maryland, USA.
A manuteno de software uma atividade muito importante na prtica das empresas de desenvolvimento de
software. Apesar de sua importncia, ainda uma prtica
mal vista pela maioria dos profissionais, pouco estudada
e entendida.
Nesse artigo foi possvel conhecer um pouco sobre o que
a manuteno de software e suas principais caractersticas
e os tipos existentes, alm de conhecer algumas prticas
e ferramentas de manuteno que auxiliam no desenvolvimento do projeto, e que devem ser consideradas para
que as manutenes necessrias em um software sejam
realizadas com o maior sucesso possvel.
Lientz, B. P.; Swanson, E. B. (1980) Software Maintenance Management, Reading, MA, AddisonWesley.
Niessink, F. (1999) Software Maintenance Research in the Mire?, In: Annual Workshop on
Empirical Studies of Software Maintenance (WESS99), Oxford, United Kingdom, September.
Pigoski, T. M. (1996) Practical Software Maintenance: Best Practices for Managing Your
Software Investment,Willey Computer Publishing.
Polo, M.; Piattini, M.; Ruiz, F.; Calero, C. (1999) Roles in the maintenance process, ACM SIGSOFT
Software Engineering Notes, v. 24, n. 4, p. 84-86.
Pressman, R. S. (2005) Software Engineering: a practitioners approach, 6.ed., McGrawHill
Higher Education.
Singh, R. (1996).International Standard ISO/IEC 12207 Software Life Cycle Processes, Software
Process Improvement and Practice, vol. 2, p. 3550.
Sommerville, I. (2003) Engenharia de Software, 6.ed., So Paulo, Addison Wesley.

sobre e
s

Feedback
eu
edio
ta
D
s
Sneed, H. M. (2003) Critical Success Factors in Software Maintenance, In: International

Conference on Software Maintenance, Amsterdam, The Netherlands, September.
Ulrich, W. M. (1990) The evolutionary growth of software reengineering and the decade
ahead. American Programmer, v. 3, n. 10, p. 14-20.
Visaggio, G. (2001) Assessing the Maintenance Process Through Replicated, Controlled
Experiment. Journal of Systems and Software, v. 44, n. 3, p. 187-197.
25
Planejamento e Gerncia
Nesta seo voc encontra artigos voltados para o planejamento
e gerncia de seus projetos de software.
Auditoria de sistemas
Anderson Carlos Santos Ramires
Marcos Kalinowski
anderson.ramires@br.pwc.com
mk@kalisoftware.com
Diretor da prtica de Advisory responsvel no

Brasil e Amrica Latina pelo grupo InfoComm
Regulatory Services (IRS). Possui grande experincia em consultoria regulatria e de anlise
e gesto de riscos de negcios na indstria de
telecomunicaes. Participou como Advisor no
processo de privatizao do Sistema TELEBRS e
nos ltimos 7 anos, tm dedicado-se exclusivamente projetos em operadoras do STFC e SMP,
principalmente,na Brasil Telecom,Telefnica (fixa
e empresas),Telemar,Vivo e Claro.Recentemente,
liderou o grupo de trabalho da PwC para a elaborao das Contribuies Consulta Pblica 544
(atual Resoluo 396) da ANATEL.
Diretor Executivo Kali Software

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
ps-graduao e-IS Expert da UFRJ e Coordenador do curso de Engenharia da Computao da
UVA RJ. 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. Membro
da equipe tcnica responsvel pelo modelo MPS.
BR (modelo nacional de qualidade de software).
Instrutor, Implementador e Avaliador certificado
do MPS.BR, tendo avaliado processos de software
de empresas de diferentes estados do pas. Credenciado a participar de avaliaes CMMI.

Diretor de Operaes - Kali Software

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.
26
atividade de auditoria independente de demonstraes

contbeis tem como principal
produto formal um parecer, expressando
a opinio do auditor sobre a adequao,
ou no, com que as demonstraes contbeis representam a posio patrimonial
e financeira da entidade auditada, o
Engenharia de Software Magazine - Auditoria de sistemas

O objetivo principal deste artigo identificar e comparar
o conjunto de normas e padres CobiT, ITIL e norma ISO
17799, emitidos por organismos internacionais, de natureza compulsria ou no, dos quais os auditores de se
utilizam, para estudar e avaliar os sistemas, infraestrutura e controles internos automatizados no processo de
auditoria dos sistemas que suportam as demonstraes
contbeis das entidades contratantes de tais servios.
Para que serve?

A Governana da Tecnologia da Informao, do termo
ingls IT Governance, se procura o alinhamento da TI
com os objetivos da organizao. Governana da Tecnologia da Informao define que a TI um fator essencial para a gesto financeira e estratgica de uma
organizao e no apenas um suporte aos mesmos.

Um grande desafio atual das instituies a busca
da soluo ideal para o processo de gesto de riscos e
gesto operacional, cada organizao dever definir
como ir tratar a questo de TI, Segurana e, principalmente, Auditoria e balancear como dever usar cada
uma delas, de forma que esta soluo seja um pilar
valioso para o processo maior de Governana Corporativa. Essa nova necessidade de gesto tem impacto
direto no trabalho do auditor de sistemas.
gest o de ti
resultado de suas operaes, as movimentaes ocorridas

no seu patrimnio lquido e as origens e aplicaes dos seus
recursos, tomando como base de comparao os princpios
fundamentais, ou geralmente aceitos, de contabilidade. Para
suportar sua opinio, o auditor independente deve coletar
evidncias suficientes e apropriadas de auditoria, atravs de
um conjunto de procedimentos tcnicos.
Assim, considerando o alto grau de automao das organizaes, o estudo e o processo de avaliao dos sistemas
informatizados e controles internos automatizados da entidade
auditada so fatores relevantes no planejamento dos trabalhos
desse tipo de auditoria e, principalmente, na anlise do risco
de emisso de opinio tecnicamente incorreta sobre demonstraes contbeis elaboradas e processos de gesto.
Consequentemente, deveriam ser objeto de uma gama de
normas formais que possam oferecer ao auditor de sistemas
as ferramentas necessrias para executar a contento suas
atividades, bem como para consubstanciar adequadamente
seu processo de julgamento e expresso de opinio sobre os
sistemas e controles internos automatizados que suportam as
demonstraes contbeis.
Algumas inquietaes surgem diante da magnitude da responsabilidade e da complexidade das tarefas que a atividade do
auditor de sistemas assume cada vez mais, quando se prope
a opinar sobre os sistemas que suportam as demonstraes
contbeis de uma entidade. Principalmente, considerando que
cada vez mais importante para o sucesso e sobrevivncia de
uma organizao, o gerenciamento efetivo da informao e da
respectiva Tecnologia de Informao (TI), considerando:
A crescente dependncia de informaes e dos sistemas que
proveem essas informaes;
As crescentes vulnerabilidades e um amplo espectro
de ameaas segurana da informao e dos sistemas de
informao;
A escala e o custo dos investimentos atuais e futuros em
informaes e sistemas de informao;
O potencial das tecnologias em mudar dramaticamente as
organizaes e as prticas de negcios, criando novos riscos e
ameaas aos controles internos.
Para muitas organizaes, a informao e a tecnologia que
suportam o negcio representa o seu mais valioso recurso.
Alm disso, num ambiente de negcio altamente competitivo
e dinmico requerida uma excelente habilidade gerencial,
onde a TI deve suportar as tomadas de decises de forma
rpida, constante e com custos cada vez mais baixos. Muitas
organizaes reconhecem os benefcios potenciais que a tecnologia pode propiciar. Entretanto, somente as organizaes
de sucesso compreendem e administram os riscos associados
implementao de novas tecnologias.
A Tecnologia da Informao tambm est ganhando uma
importncia cada vez maior para as instituies financeiras do
mundo todo. Com o desenvolvimento dos negcios globalizados, a informao tornou-se cada vez mais disponvel a partir
de novos pontos de acesso em qualquer parte do planeta, ao
preo de ficar mais exposta, trazendo assim novos riscos a

essas instituies.
Essa globalizao favoreceu a ocorrncia de diversos problemas de segurana, que contriburam para essa crescente
preocupao com o controle efetivo de suas operaes e com
o acesso a essas informaes, tais como:
Aumento do nmero de fraudes;
Aumento de operaes de lavagem de dinheiro;
Aumento de erros nessas instituies;
Perda ou roubo de informaes financeiras.
Paralelamente, com o aumento destes problemas resultantes
da ineficincia dos sistemas de qualidade e segurana alm da
possibilidade de descontinuidade das operaes com impactos
alarmantes que afetam toda uma cadeia de fornecimento de
bens e servios, muitas corporaes passaram a ser fortemente
regulamentadas por leis e regulamentaes cada vez mais
rigorosas. As recentes mudanas no ambiente regulamentar,
como o surgimento da Lei Sarbanes-Oxley, lei federal americana
editada em 2002 pelo Congresso e Governo dos EUA, entre outros, afetaro todos os segmentos do mercado por exigirem que
as organizaes que participam do sistema financeiro adotem
melhores prticas de gesto de riscos e gesto operacional.
A gesto de riscos proporciona as condies necessrias para
a instituio identificar os fatores de risco inerentes s suas
posies e seu respectivo dimensionamento, de modo a estimar
o tamanho das perdas potenciais e determinar a necessidade
de capital econmico para sua cobertura. O processo de gesto
operacional consiste na identificao dos riscos de segurana a
que o negcio est exposto. Atravs de uma avaliao sistemtica que visa o mapeamento das ameaas e vulnerabilidades
operacionais, a empresa conhece os riscos a que est exposta
e pode preparar-se para evit-los.
O mundo corporativo tem visto que estas mudanas no
impactam somente as reas de contabilidade e finanas das instituies, mas na empresa como um todo. A alta administrao
dessas organizaes est continuamente em busca de modelos
mais eficientes e na eficcia de sua Governana Corporativa. A
expresso Governana Corporativa definida pelo Instituto
Brasileiro de Governana Corporativa (IBGC) como um sistema
pelo qual as empresas so dirigidas e monitoradas, envolvendo
os relacionamentos entre acionistas e cotistas, conselho de
administrao, diretoria, auditoria independente e conselho
fiscal. Uma boa Governana Corporativa deve se basear numa
anlise criteriosa da adequao dos processos, da cultura e da
disciplina organizacional, recursos humanos e tecnologia, e
na aplicao de controles rigorosos, preventivos e detectivos
no gerenciamento dos riscos.
Porm, para uma Governana Corporativa adequada, a rea
de TI da empresa deve estar com os processos de TI devidamente alinhados aos negcios da corporao, para garantir o
retorno de investimentos e adio de melhorias nos processos
empresariais. A Governana de TI tem a mesma filosofia da
Governana Corporativa, no entanto, voltada exclusivamente
rea de tecnologia. Conforme destacado no documento Board
27
Briefing on IT Governance, publicado pelo IT Governance Institute

[7], a Governana de TI trata basicamente de:
Alinhamento e entrega de valor por parte da rea de TI para
o negcio;
Correta alocao e medio dos recursos envolvidos;
A mitigao dos riscos em TI.
De forma cada vez mais crescente, torna-se necessrio definir, para a TI, objetivos para atender aos requisitos prprios
do negcio e tambm aos da segurana das informaes
processadas, armazenadas e transmitidas. A rea de TI das
instituies dever aumentar a necessidade de foco no planejamento estratgico, garantindo que os processos de TI estejam
devidamente alinhados s estratgias de negcios, fornecendo
desempenho, disponibilidade, integridade e segurana da
informao organizao.
Assim, seja para identificar e gerenciar os riscos operacionais,
coibindo aes que causem prejuzos, seja para adequar polticas e procedimentos internos para atender os aspectos regulamentares de gesto de riscos e da segurana da informao, as
instituies devero rever todos os processos internos cobrindo
desde as metodologias de desenvolvimento de sistemas at as
reas de operaes de computadores, buscando a melhoria na
eficincia de processos, na comunicao e transparncia de
informaes e consequentemente na melhoria da governana
corporativa.
A governana de TI, por sua vez, emprega ferramentas e
aplicaes de TI para aumentar a vantagem competitiva das
organizaes. Para tanto, foram desenvolvidos nos ltimos
anos, por iniciativa de vrios institutos internacionais, uma
srie de modelos de gesto que se aplicados asseguram a
conformidade com as melhores prticas de processos, de
segurana da informao e gerenciamento dos riscos corporativos. Esses modelos (framework) de controle formam a base
do desenvolvimento de controles internos para as instituies.
Estes compreendem polticas, procedimentos e prticas que
giram em torno do gerenciamento dos riscos, processo que
deve estar sempre alinhado aos objetivos do negcio ou de
TI, conforme o propsito original do framework (sistemas de
controle estruturado com elementos de gesto). Cada framework
possui uma metodologia prpria desenvolvida pelo instituto
responsvel. A metodologia corresponde ao processo de
introduo e integrao dessa nova estrutura no escopo das
atividades organizacionais enquanto que o framework representa o arcabouo do sistema.
A adoo de um modelo de gesto depende, fundamentalmente, de quais tipos de objetivos a instituio visa alcanar
de forma gerenciada. Pode-se listar as seguintes referncias
para a rea de governana de TI: (i) CobiT para a governana
de TI; (ii) ITIL para a gesto de servios de TI; (iii) DRI para a
especificao e operao de planos de continuidade de negcios; (iv) ISO 17799 (ou BS-7799) para a gesto de Segurana
de Informao; (v) CMMI que define um modelo de gesto
para o desenvolvimento de software; (vi) COSO para definir
processos para o controle interno das empresas.
28
Um grande desafio atual das instituies a busca da soluo

ideal para o processo de gesto de riscos e gesto operacional,
cada organizao dever definir como ir tratar a questo de
TI, Segurana e, principalmente, Auditoria e balancear como
dever usar cada uma delas, de forma que esta soluo seja
um pilar valioso para o processo maior de Governana Corporativa. Essa nova necessidade de gesto tem impacto direto
no trabalho do auditor de sistemas e, consequentemente, nas
opinies sobre as demonstraes financeiras.
Neste contexto, o objetivo principal deste artigo identificar e comparar o conjunto de normas e padres CobiT, ITIL
e norma ISO 17799, emitidos por organismos internacionais,
de natureza compulsria ou no, dos quais os auditores de se
utilizam, para estudar e avaliar os sistemas, infraestrutura e
controles internos automatizados no processo de auditoria
dos sistemas que suportam as demonstraes contbeis das
entidades contratantes de tais servios.
Governana da Tecnologia da Informao

A informao reconhecida pelas organizaes nos ltimos
anos como sendo um dos mais importantes recursos estratgicos que necessitam gerenciamento. Atualmente, os sistemas
e os servios de Tecnologia da Informao (TI) desempenham
um papel vital na coleta, anlise, produo e distribuio da
informao indispensvel execuo do negcio das organizaes. Dessa forma, tornou-se essencial o reconhecimento
de que a TI crucial, estratgica e um importante recurso que
precisa de investimento e gerenciamento apropriados.
Esse cenrio motivou o surgimento do conceito de Governana da Tecnologia da Informao, do termo ingls IT Governance, atravs da qual se procura o alinhamento da TI com
os objetivos da organizao. Governana da Tecnologia da
Informao define que a TI um fator essencial para a gesto
financeira e estratgica de uma organizao e no apenas um
suporte aos mesmos.
Governana da Tecnologia da Informao pode ser definida
como:
1. Uma estrutura de relacionamentos entre processos para
direcionar e controlar uma empresa de modo a atingir seus
objetivos corporativos, atravs da agregao de valor e controle
dos riscos pelo uso da TI e seus processos;
2. Capacidade organizacional exercida pelo conselho diretor,
gerente executivo e gerente de TI de controlar o planejamento
e implementao das estratgias de TI e dessa forma, permitir
a fuso de TI ao negcio;
3. Especificao das decises corretas em um modelo que
encoraje o comportamento desejvel no uso de TI nas
organizaes.
Para alcanar a Governana da Tecnologia da Informao
tanto as organizaes quanto seus auditores se utilizam de
modelos de gesto que, se aplicados, asseguram a conformidade com as melhores prticas de processos e segurana da
informao. Entre esses modelos, pode-se citar CobiT para a
Governana de TI e ITIL para a gesto dos servios de TI.
gest o de ti
A Lei Sarbanes-Oxley
A Lei americana Sarbanes-Oxley foi originada em 2002,
aps escndalos corporativos de manipulao de dados
contbeis ocorridos em grandes empresas norte-americanas
como a empresa de energia Enron, Tyco e a WorldCom na
rea de telecomunicaes. O escopo desta legislao federal
se insere no mbito da governana corporativa, e na tica
nos negcios de companhias que possuem capital na Bolsa
de Nova York.
Rgidos parmetros legais foram impostos a estas empresas,
aumentando desde o grau de responsabilidade dos executivos da empresa, at as auditorias e advogados contratados
que atestarem balanos. As principais exigncias incluem
clareza na apresentao das informaes financeiras, nfase
em assuntos de governana corporativa; processos rigorosos
de controle interno; informaes financeiras confiveis e
compreensveis e independncia das firmas de auditoria
externa encarregada de valid-las.
Embora restrita ao governo norte-americano, a SarbanesOxley uma legislao que funciona como uma espcie de
bola de neve no mercado de tecnologia do mundo todo. No
Brasil, essa lei se aplica s empresas com aes negociadas
nos mercados de capitais dos Estados Unidos, subsidirias
de empresas multinacionais de capital americano e empresas
brasileiras com aes naquele pas.
Em suas 1.107 sees, a maior ateno, discusso e trabalho
a respeito da Sarbanes-Oxley est sendo focado nas sees 302
e 404 da Lei. A Seo 302 requer que o principal executivo
(CEO) e o principal executivo de finanas (CFO) assumam a
responsabilidade por definir, avaliar e monitorar a eficcia
dos controles internos sobre relatrios financeiros e divulgaes da empresa. Estes controles devem ser suficientes
e capazes de livrar a instituio dos riscos que possam
ameaar suas principais funes e, com isso, prejudicar
respectivas entidades e partes interessadas, como clientes
e acionistas.
Na seo 404 da Lei tratada a validao dos controles e
procedimentos internos sobre os relatrios financeiros, esta
avaliao deve ser formal e realizada anualmente por auditores externos. E a seo 409 trata da divulgao imediata, em
tempo real e em base rpida e corrente, dados que possam
impactar a performance financeira da empresa; informaes
com respeito a mudanas materiais na condio financeira
ou operacional da organizao.
Uma outra seo que tambm se destaca a Seo 906, que
exige que uma certificao do CFO ou CEO acompanhe cada
relatrio que contenha dados financeiros, garantindo que
os dados representam fielmente as condies financeiras e
os resultados operacionais da empresa. Esta seo atribui
penalidades criminais a certificaes falsas (que vo desde
o pagamento de multas ao cumprimento de penas).
Ao regular a atividade de contabilidade e auditoria das empresas de capital aberto, a Sarbanes-Oxley reflete diretamente
seus dispositivos nos sistemas de Tecnologia da Informao.
Prticas de segurana de redes e dos sistemas passam a ter
obrigatoriedade; invases, ataques, vrus e roubo de dados, fraudes de senhas e demais ameaas segurana das
informaes da companhia podem, se no houver provas
suficientes de adoo de medidas preventivas, implicar em
responsabilidade direta dos administradores.
Revises de processos, reestruturao de conselhos e adoo de polticas que disseminem o conceito de governana
corporativa tambm devem ser consideradas como medidas
obrigatrias e urgentes.
O Basilia II
Com a criao pelo Bank for International Settlements (BIS),
o Banco Central dos Bancos Centrais que regula o setor no
mundo inteiro, de um Novo Acordo de Capitais, o Basilia
II, as instituies financeiras comearam a se preocupar
com a eficincia de seus controles internos e da gesto de
riscos operacionais.
As recomendaes do Comit de Superviso da Basilia,
que criou o Novo Acordo da Basilia, publicado em Junho
de 2004 pelo documento Convergncia Internacional de
Mensurao e Padres de Capital: Uma estrutura Revisada
(Basilia II), tratam do estabelecimento de critrios mais adequados ao nvel de riscos associados s operaes conduzidas
pelas instituies financeiras para fins de requerimento de
capital regulamentar, exigindo que as perdas operacionais
previstas sejam deduzidas da base de capital, impondo que as
instituies tenham a mensurao, gesto e controle do Risco
Operacional. Este ltimo, conforme descrito pelo Comit
da Basilia em 2001, o risco de perdas diretas e indiretas,
resultante de falhas em processos internos ou de eventos
externos, tais como fraudes, relaes trabalhistas, danos a
ativos, interrupo do negcio e falhas de sistemas, execuo e
gesto de processo. Na prtica, o novo acordo atinge os bancos
da seguinte maneira: a instituio que no possuir controles
internos eficientes e uma metodologia de avaliao de riscos
implementada ser obrigada a manter uma quantidade maior
de recursos prprios em sua estrutura patrimonial, enquanto
que, instituies que investirem nesses itens tero que reter
menor volume de recursos, o que tem um impacto determinante na competitividade dos bancos.
Do ponto de vista da rea de TI, ser necessria a adoo
de uma gesto de riscos operacionais para garantir total
segurana e confidencialidade dos dados dos clientes, sem
o comprometimento da instituio. Alm de oferecer uma
infraestrutura de sistemas que assegure a integridade da
base de dados e dos relatrios gerenciais, sendo preciso
adaptar sistemas e procedimentos dos bancos relacionados
anlise e medio do risco operacional.
Para permitir uma estratgia de gerenciamento do risco
o Basilia II exige a captao, arquivamento e estruturao
de dados histricos relacionados com a instituio nos ltimos cinco anos, consolidando na base de dados todas as
informaes sobre fraudes, lavagem de dinheiro, padres
de operaes e comportamentos suspeitos, garantindo a
existncia de um ambiente adequado de controles.
29
A necessidade de um framework para o

gerenciamento de riscos
Para atender aos novos desafios das exigncias legais e regulamentaes, as instituies esto priorizando investimentos
na rea de Segurana da Informao e no prprio departamento de TI. Isso engloba tanto os esquemas de tolerncia
falha a infraestrutura de TI quanto proteo contra aes
hostis e garantia do uso responsvel dos recursos, buscando
maior nfase em Governana de TI e melhores e mais efetivos
controles internos para garantir a gesto de riscos em seus
processos e no relacionamento com a sociedade.
Esses controles so definidos como polticas, procedimentos,
prticas e estruturas organizacionais projetados para prover
razovel segurana de que os objetivos de negcio sero
atingidos e que eventos indesejveis sero prevenidos ou
detectados e corrigidos. A governana do sistema financeiro
depende da governana da TI e esta das ferramentas baseadas
em TI como suporte para uma gesto efetiva da informao
e da tecnologia.
A dificuldade em se criar um sistema de controles internos,
estruturado e adequado a essas regulamentaes, ensejou
a busca por parte das instituies por estruturas prontas e
flexveis (frameworks), cuja funcionalidade deveria englobar,
minimamente, os aspectos a seguir:
Foco nos objetivos de negcio e misso da instituio;
Gesto de riscos corporativos, notadamente os de natureza
operacional;
Conformidade com as normas oficiais aplicveis.
Neste ponto, faz-se necessrio procurar uma soluo que possibilite efetuar avaliaes sistemticas e profundas, de pontos
nevrlgicos cujo comprometimento da segurana respectiva
pode causar consequncias indesejveis a diferentes partes da
instituio. Essa avaliao deve ainda contemplar elementos
que interligam as funes de negcio aos pontos verificveis
causadores dos riscos.
Para tal, o framework e a metodologia a serem empregados
devem ser cuidadosamente avaliados para a correta adequao
aos objetivos da instituio. essencial que os vrios aspectos
caractersticos sejam conhecidos previamente, para que haja
sucesso no efetivo gerenciamento de riscos, atendimento s
regulamentaes oficiais e capacidade de verificao da eficcia dos controles de TI.
Diante deste cenrio, um modelo de gesto disponvel que
tem muito a contribuir com isto e que tem sido sugerido para
adoo por importantes instituies financeiras mundiais e
slidos grupos internacionais a metodologia CobiT para a
governana de TI, um conjunto de melhores prticas de controle de objetivos, otimizao dos investimentos, mapas de
auditoria e tcnicas de gerenciamento que voltado para todas
as companhias, independente das plataformas tecnolgicas
adotadas, que buscam alinhar as prticas de TI ao seu modelo
de negcio visando regulamentar o processo. No Brasil, esta
metodologia vem sendo amplamente utilizada por empresas de
diversos setores e segmentos, alm de ser a base de avaliao
30
de prticas de controle de TI para rgos Reguladores como

o Banco Central do Brasil e a Superintendncia de Seguros
Privados (SUSEP).
A metodologia CobiT
Desenvolvido pelo IT Governance Institute, o CobiT Control
Objectives for Information and Related Technology (Objetivos de
Controle sobre Informaes e Tecnologia Relacionada) -
considerada a metodologia base para a governana de TI,
projetado para ser uma ferramenta de gesto da rea de
Tecnologia da Informao que ajuda a compreender e gerenciar os riscos e benefcios associados com a informao
e relacionados com TI.
Conceito
O CobiT, agora na sua 3 edio, auxilia a associao entre
os riscos de negcio, as necessidades de controle e os aspectos tecnolgicos. Propicia boas prticas atravs de uma
matriz de domnios e processos (framework) estruturados de
forma lgica e gerencivel. Tais boas prticas representam
o consenso de especialistas, tendo sido pesquisadas e consolidadas pela ISACF (Information Systems Audit and Control
Foundation), com o intuito principal de constituir-se em
uma fonte educacional para profissionais de controle. Foi
desenvolvido como um padro geralmente aceito e aplicvel
para boas prticas de controle e segurana de Tecnologia de
Informao, objetivando ser seu equivalente dos Princpios
Contbeis Geralmente Aceitos.
A metodologia CobiT tem como misso: Pesquisar, desenvolver, publicar e promover um conjunto atualizado,
autorizado e com foco internacional, de objetivos de controle
geralmente aceitos e aplicveis Tecnologia da Informao
para o uso por gestores de TI, CIOs - Chief Information Officers
-, usurios e auditores de sistemas.
Aplicao do CobiT
O CobiT foi projetado para utilizao por trs distintos
pblicos:
Administradores: para auxili-los na ponderao entre
risco e investimento em controles num ambiente muitas
vezes imprevisvel como o de TI.
Usurios: para garantir segurana e controle dos servios
de TI fornecidos internamente ou por terceiros e;
Auditores: para subsidiar suas opinies e/ou prover aconselhamento aos administradores sobre controles internos.
Estrutura do CobiT
A metodologia CobiT possui trs nveis. No nvel mais
elevado esto os Domnios, que so agrupamentos de processos conforme a natureza destes. O CobiT est dividido
em quatro domnios:
I. Planejamento e organizao: Este domnio abrange estratgias e tticas, dando enfoque na identificao dos
caminhos que a TI pode melhor contribuir para a obteno
dos objetivos de negcio.
gest o de ti
II. Aquisio e implementao: Este domnio visa realizar a

estratgia de TI, atravs da identificao de solues necessrias, utilizando o desenvolvimento ou aquisio e t-las
implementadas e integradas aos processos de negcio.
III. Entrega e suporte: Este domnio d enfoque aos
produtos reais dos servios requeridos, desde operaes
tradicionais de segurana e aspectos de continuidade.
IV. Monitorao: Este o domnio que controla os processos de TI que devem ser avaliados regularmente nos
aspectos de sua qualidade e conformidade s necessidades
de controle.
No prximo nvel esto os Processos. Estes so formados por conjuntos de atividades e/ou tarefas onde cada
conjunto (ou processo) possui caractersticas prprias
associadas a controle. No total a metodologia possui 34
processos de TI, e cada um destes processos possui um
objetivo de controle de alto nvel.
O nvel mais baixo da estrutura so as Atividades e Tarefas. As atividades possuem um ciclo de vida, enquanto
as tarefas so como pontos no tempo. As duas formam o
grupo mais numeroso, existindo 318 objetivos de controle
detalhados a elas relacionados. Os objetivos de controle
de TI so definidos como uma declarao do resultado
desejado ou propsito a ser atingido pela implementao
de procedimentos de controle numa atividade de TI em
particular.
Tal estrutura cobre todos os aspectos da informao e
da tecnologia que a suporta. Outrossim, a cada um dos
34 objetivos de controle de alto nvel esto associadas Diretrizes de Auditoria (Audit Guideline) para possibilitar
a reviso dos processos de TI contra os 318 objetivos de
controle detalhados recomendados pelo CobiT.
Cada um destes diferentes nveis avaliado segundo
sete Critrios de Informao, para avaliao dos diversos
processos ligados TI, de acordo com os Recursos da TI
que estes utilizam:
Eficcia: A informao deve ser relevante e pertinente
aos objetivos do negcio, sendo disponibilizada s pessoas
adequadas no tempo e contedo corretos;
Eficincia: A informao deve ser disponibilizada
utilizando-se os diversos recursos da forma mais eficiente
e econmica possvel;
Confidencialidade: Assegura que as informaes no
sero utilizadas por pessoas no autorizadas;
Integridade: A informao deve ser completa, atual e
precisa, atendendo s necessidades do negcio;
Disponibilidade: A informao, assim como todos os
recursos necessrios para sua gerao e utilizao, deve
estar disponvel sempre que necessrio;
Conformidade: A informao deve estar em conformidade com leis, regulamentos e arranjos contratuais os quais
os processos de negcios esto sujeitos;
Confiabilidade das Informaes: Fornecimento das informaes adequadas aos administradores para que estes
possam cumprir adequadamente suas responsabilidades

gerenciais, financeiras e de conformidade.
E os principais recursos de TI so:
Dados: So objetos no sentido amplo, estruturados ou
no, tais como textos, grficos, sons, etc.;
Sistemas Aplicativos: So tanto sistemas manuais como
procedimentos automatizados;
Tecnologia: Hardware, sistemas operacionais, sistemas
para gerenciamento de bases de dados, redes, multimdia, etc.;
Instalaes: So os recursos utilizados para abrigar e
dar suporte aos sistemas de informao;
Pessoas: So as habilidades e conhecimentos para planejamento, organizao, aquisio, entrega, suporte e monitoramento de sistemas de informao e seus servios.
Em resumo, com a finalidade de prover informao que
a organizao necessita para atingir seus objetivos, os
recursos de TI devem ser gerenciados por um conjunto
de processos naturalmente agrupados. Este conceito
ilustrado na Figura 1, que apresenta o CobiT Framework,
o qual relaciona os 34 objetivos de controle de alto nvel e
seus respectivos domnios, as sete categorias de critrios
para a avaliao dos processos e os recursos de TI. O ciclo
natural dos processos respeitado levando-se em conta,
na avaliao dos controles, os objetivos do negcio, os sete
critrios de avaliao e os recursos de TI (ver Figura 1).
Tabela Resumo do CobiT

Os objetivos de controle do CobiT procuram atestar como
cada processo faz uso dos recursos de TI para atender
de forma primria ou secundria cada requerimento do
negcio em termos de informao, cobrindo todos os
seus aspectos. A forma utilizada na metodologia para
demonstrar como cada critrio de informao e recurso
de TI impacta os diferentes processos analisados utiliza
os seguintes critrios de preenchimento:
Primrio (P) Indica o nvel no qual o objetivo de controle
definido tem impacto direto no critrio de informao;
Secundrio (S) Indica o nvel no qual o objetivo de controle definido apenas satisfaz o critrio de informao, podendo
ser em pouca extenso ou inclusive indiretamente;
No Preenchimento Poderia ser aplicvel, todavia outro
critrio de avaliao mais adequado a este processo.
Similarmente, uma medida de controle particular no
impacta necessariamente os diferentes recursos de TI
no mesmo nvel. Consequentemente, o CobiT framework
indica especificamente a aplicabilidade do recurso de TI
que so gerenciados especificamente pelo processo em
considerao e no apenas aqueles que meramente fazem
parte do processo.
A Tabela 1 demonstra a Planilha Resumo do CobiT
utilizando os critrios de preenchimento anteriormente
31
Figura 1. COBIT
mencionados para indicar quais critrios de informao so impactados

pelos objetivos de controle de alto nvel
quais recursos de TI so aplicveis nos
34 processos analisados.
Componentes do CobiT
Os componentes do CobiT so utilizados para fazer com que a TI seja orientada aos objetivos do negcio e cumpra
seu papel na instituio. Para tanto, as
boas prticas do CobiT so organizadas
em processos, cada qual visando a um
Objetivo de Controle. Cada processo do
CobiT possui os seguintes componentes
(ver Figura 2):
Objetivos de controle: alinham o framework geral com objetivos de controle
detalhados de 41 fontes primrias que
compreendem padres e regulamentos
internacionais de fato e de direito que se
32
Figura 2. CobiT Components Linked
gest o de ti
ferramentas de avaliao e medio do ambiente de TI da

organizao, permitindo uma abordagem ampla sobre o
que se espera do processo, como se medem os resultados e
como se mede a performance:
Prticas de controle: fornecem mais detalhadamente o
como e o porque necessrios para implementar os controles altamente especficos baseados em uma anlise de riscos
operacionais e de TI;
Aquisio e
implementao
Definir nveis de servios

Gerenciar servios de terceiros
Gerenciar performance e capacidade
Garantir continuidade dos servios
Garantir segurana dos sistemas
Identificar e alocar custos
Educar e treinar usurios
Auxiliar e aconselhar usurios de TI
Gerenciamento da configurao
Gerenciamento de problemas e incidentes
Gerenciamento de dados
Gerenciamento de instalaes
Gerenciamento de operao
P
P
P
P
P
P
P
S
Monitorar os Processos
Avaliar a adequao do controle interno
Obter certificao independente
Auditoria
P
P
P
P
P
P
P
P
M1
M2
M3
M4
P
P
P
P
P
P
P
S
S
S
S
S
P
P
S
S
S
S
S
S
S
S
P
S
S
S
S
S
S
S
S
S
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
S
S
S
S
V
V
S
P
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
S
S
P
P
S
V
V
V
S
P
S
S
S
P
S
V
V
V
V
V
P
S
P
P
S
S
Tecnologia
S
P
P
P
V
V
V
V
V
V
V
V
Aplicativos
P
P
P
P
P
P
S
P
P
Pessoas
Identificar Solues
Adquirir e manter software aplicativo
Adquirir e manter arquitetura tecnolgica
Desenvolver e manter procedimentos de TI
Instalar e certificar sistemas
Gerenciar mudanas
Confiabilidade
AI1
AI2
AI3
AI4
AI5
AI6
Recursos de TI
Conformidade
S
S
S
S
P
Disponibilidade
P
P
P
P
P
P
P
P
P
P
P
Integridade
Definir um plano estratgico de TI

Definir a arquitetura da informao
Determinar a direo tecnolgica
Definir a organizao e relacionamentos da TI
Gerenciar o investimento em TI
Comunicar objetivos e diretrizes da Administrao
Gerenciar recursos humanos
Garantia do cumprimento de exigncias externas
Avaliao de riscos
Gerenciar Projetos
Gerenciar Qualidade
Confiabilidade
PO1
PO2
PO3
PO4
PO5
PO6
PO7
PO8
PO9
PO10
PO11
DS1
DS2
DS3
DS4
DS5
DS6
Fornecimento e Suporte DS7
DS8
DS9
DS10
DS11
DS12
DS13
Monitorao
Critrios de Informao
Eficincia
Planejamento e
Organizao
Processo
Eficcia
Domnio
Dados
Para atender as necessidades gerenciais de controle e medio de TI, o CobiT fornece para cada um dos 34 processos
de TI, alm dos objetivos de controles, diretrizes contendo
Instalaes
relacionam a TI. Eles contm declaraes dos resultados desejados

ou metas a serem alcanadas na implementao de procedimentos
de controle especficos dentro de uma atividade de TI e fornecem
uma poltica clara para o controle de TI na empresa;
V
V
V
V
V
S
P
S
P
P
P
S
S
S
S
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
Tabela 1. CobiT Summary Table
33
diretrizes de gerenciamento, que incluem:

- FCSs Fatores Crticos de Sucesso: Os fatores crticos de
sucesso definem os desafios mais importantes ou aes de
gerenciamento que devem ser adotadas para colocar sobre
controle a gesto de TI. So definidas as aes mais importantes do ponto de vista do que fazer a nvel estratgico, tcnico,
organizacional e de processo (ITGI, 2004);
- KGIs Indicadores chaves de objetivos: Os indicadores
de objetivos definem como sero mensurados os progressos
das aes para atingir os objetivos da organizao, usualmente
expressos nos seguintes termos:
Disponibilidade das informaes necessrias para suportar as necessidades de negcios;
Riscos de falta de integridade e confidencialidade das
informaes;
Eficincia nos custos dos processos e operaes;
Confirmao de confiabilidade, efetividade e conformidade das informaes.
- KPIs Indicadores chaves de desempenho: Indicadores
de desempenho definem medidas para determinar como os
processos de TI esto sendo executados e se eles permitem
atingir os objetivos planejados; so os indicadores que definem
se os objetivos sero atingidos ou no; so os indicadores que
avaliam as boas prticas e habilidades de TI;
- Modelos de maturidade: Os modelos de maturidade de
governana so usados para o controle dos processos de TI e
fornecem um mtodo eficiente de auditoria que permite classificar o nvel de maturidade dos processos da organizao. A
governana de TI e seus processos com o objetivo de adicionar
valor ao negcio atravs do balanceamento do risco e retorno
do investimento podem ser classificados, seguindo o modelo
do CMM (Capability Maturity Model), da seguinte forma:
(0) Inexistente: significa que o processo de gerenciamento no foi implantado. No existe a conscincia da
necessidade de controles;
(1) Inicial ou Sob Demanda (ad hoc): existe o reconhecimento da necessidade de governana de TI, entretanto, no
existem padres, o processo realizado sem organizao, de
modo no planejado. O monitoramento de TI implementado de forma reativa devido a algum incidente que tenha
causado perda ou dificuldade para a organizao;
(2) Repetvel mas Intuitivo: existe uma conscincia
global das questes de governana de TI. Atividades de
governana de TI e indicadores de performance esto em
desenvolvimento. A gerncia identificou medidas bsicas
de governana de TI, entretanto, o processo no est sendo
implementado em toda a organizao, so iniciativas isoladas, o processo repetido de modo intuitivo, isto , depende mais das pessoas do que de um mtodo estabelecido;
(3) Definido: neste nvel os procedimentos foram padronizados, documentados e implementados. Existe um
conjunto de indicadores definidos, ligando os resultados
medidos com os direcionadores de performance. Os procedimentos so medidos, porm simples, sendo a formalizao do que j existe;
34
(4) Gerenciado: neste nvel existe o entendimento em

todos os nveis da organizao sobre a necessidade da
governana de TI, suportada atravs de nveis de servio.
So institudos, de forma padronizada, procedimentos
de anlise de causa de problemas. Existem mtricas de
desempenho das atividades, o processo monitorado e
constantemente avaliado. Incio do processo de melhoria
contnua;
(5) Otimizado: neste nvel, os riscos e retornos de TI so
identificados e devidamente gerenciados. Os processos so
constantemente refinados ao nvel das melhores prticas
de mercado e automao para a melhoria contnua dos
processos. A organizao, pessoas e processos so rapidamente adaptveis.
Cada processo tem no CobiT o detalhamento do que significa
estar em cada um dos estgios.
Com a utilizao dos componentes das diretrizes de gerenciamento (Management Guidelines) do CobiT, tais como fatores
crticos de sucesso, indicadores chaves de metas, indicadores
chaves de desempenho, e os modelos de maturidade, possvel
graduar a maturidade de uma organizao para um determinado processo, de no-existente (0) at otimizado (5) e assim
avaliar-se quanto as melhores prticas e padres de mercado, e
identificar as deficincias e definir aes especficas para se alcanar um certo nvel de maturidade desejada. Pode-se mover
para um nvel mais alto quando todas as condies descritas
em um determinado nvel de maturidade so cumpridas.
- Diretrizes de auditoria: descreve e sugere atividades de
anlise, avaliao e interpretao para auditar os processos;
O CobiT procura ocupar o espao entre a Gesto de Riscos
voltada para o Negcio (atendida, por exemplo, pelo COSO Comittee of Sponsoring Organizations), a Gesto de Servios em
TI (por exemplo, por meio do ITIL) e a Gesto da Segurana da
Informao (por exemplo, tratada pela ISO 27001).
Esses modelos de gesto consistem de boas prticas especficas segundo sua rea foco, e possuem funes complementares. Dessa forma, o CobiT permite alinhar os objetivos
dessas reas de conhecimento s estratgias e princpios de
governana corporativa, garantindo, assim, que os processos
e atividades desempenhadas pelas respectivas reas e funes
corporativas concorram de forma sistemtica para o alcance
os objetivos do negcio e para a reduo dos riscos operacionais. O CobiT assegura aos usurios a existncia de controles,
inclusive tornando-os responsveis por parte desses controles,
e auxilia o trabalho dos auditores de sistemas e de segurana
da informao.
ITIL
Cada vez mais as organizaes sero pressionadas a
mostrar que possuem um rgido controle de todos os seus
processos de negcios. Como a Tecnologia da Informao
gest o de ti
parte integral de praticamente todos estes processos,

fundamental que as empresas alinhem fortemente suas
atividades de TI aos seus objetivos de negcios. Projetos de
TI no entregues dentro dos prazos estabelecidos podem
acarretar srios riscos e afetar o planejamento da organizao como um todo.
Por esta razo, o controle do ambiente de TI tem se tornado
um item de extrema importncia e de alta complexidade. O
Gerenciamento dos Servios de TI (Information Technology
Service Management - ITSM) vem ganhando grande destaque,
permitindo s empresas contar com um controle da qualidade dos seus processos de TI, mensurando resultados dentro
de padres de eficincia e performance.
Um modelo de excelncia em TI compe-se da integrao
de diversas prticas de gesto, como por exemplo, as de
Gerenciamento de Servios de TI definidas pelo modelo de
referncia ITIL (Information Technology Infrastructure Library).
A ITIL foi desenvolvida pela CCTA (Central Computer and
Telecommunication Agency), atualmente chamada OGC (Office
of Government Commerce), do Reino Unido, no final dos anos
80, sendo documentada em um conjunto de livros que descrevem um modelo de referncia com as melhores prticas
para um efetivo gerenciamento dos Servios de TI.
Embora concebida originalmente para o setor pblico
do Reino Unido, se expandiu rapidamente para as demais
organizaes dos setores pblicos e privados, gerando uma
indstria composta por treinamentos, certificaes, consultorias, ferramentas de software e um Frum especfico, o
ITSMF (Information Technology Service Management Forum).
Hoje em dia, o ITIL um padro adotado globalmente.
O uso efetivo das melhores prticas definidas no ITIL traz
inmeros benefcios s organizaes, como:
Melhoria na utilizao dos recursos;
Maior competitividade; reduo de retrabalhos;
Eliminao de trabalhos redundantes;
Melhoria da disponibilidade, confiabilidade e segurana
dos servios de TI;
Qualidade dos servios com custos justificveis;
Fornecimento de servios alinhados aos negcios, aos
clientes e s demandas dos usurios;
Processos integrados;
Responsabilidades documentadas e comunicadas amplamente, e registro e;
Controle de lies aprendidas.
A estrutura das publicaes do ITIL composta pelos
livros descritos a seguir:
1. Service Support - descreve a funo de Service Desk e os
processos de Incident Management, Problem Management,
Configuration Management, Change Management e Release
Management.
2. Service Delivery descreve os processos de Capacity
Management, Financial Management for IT Services, Availability Management, Service Level Management e IT Service
Continuity Management.
3. Planning to Implement Service Management - explica os

passos necessrios para identificar como uma organizao
pode alcanar e usufruir os benefcios da ITIL.
4. ICT Infrastructure Management - este livro aborda os
processos, organizao e ferramentas necessrias para prover uma infraestrutura estvel de TI e de Comunicaes.
5. Application Management um guia para os usurios
de negcios, desenvolvedores e gerentes de servios que
descreve como as aplicaes podem ser gerenciadas sob a
perspectiva de Gerenciamento de Servios.
6. Security Management - este livro tem conexes com
vrios outros domnios da ITIL, explicando como gerenciar
melhor os nveis de segurana da infraestrutura de TI.
7. Business Perspective - este livro ajuda os Gerentes de
Negcios a compreenderem a proviso dos servios de TI.
As disciplinas de gerenciamento de servios que esto no
centro da biblioteca do ITIL esto divididas em dois grupos
distintos: Servios de Suporte e Servios de Entrega. Os servios de entrega esto focados na operao do dia a dia e no
suporte aos servios de TI enquanto os servios de entrega
consideram processos de planejamento de longo prazo.
A Teoria dos Processos do ITIL

A base do modelo de processos do ITIL fundamentada
na teoria de processos proposta pela Office for Government
Commerce OGC. Segundo este princpio, a qualidade de
um processo vem do modelo de processo que define os
fluxos de trabalho e prove um guia para percorr-lo. Um
modelo de processo permite entender e ajudar a enunciar
as caractersticas distintas de um processo.
Um processo pode ser definido como: uma srie conectada
de aes, atividades, mudanas, etc., executadas por agentes
dentro do objetivo de satisfazer um propsito ou alcanar
um objetivo. Definidos os processos, estes devem estar sob
controle e uma vez sob controle, estes podem ser repetidos
e gerenciados. Desta forma, a partir da definio do grau
de controle sobre os processos possvel construir mtricas
para controlar estes processos. A sada produzida por um
processo deve estar de acordo com as normas operacionais
que foram derivadas dos objetivos do negcio. Se o produto
est de acordo com as definies das normas, o processo
pode ser considerado efetivo (porque pode ser repetido,
medido e gerenciado). Se as atividades so executadas com o
mnimo esforo, o processo pode ser considerado efetivo.
A Estrutura da Bibilioteca ITIL

A biblioteca ITIL tem como foco principal a operao e a gesto da infraestrutura de tecnologia na organizao, incluindo
todos os assuntos que so importantes no fornecimento dos
servios de TI. Nesse contexto, o ITIL considera que um servio de TI a descrio de um conjunto de recursos de TI. Os
servios de suporte do ITIL auxiliam no atendimento de uma
ou mais necessidades do cliente, apoiando, desta forma, aos
seus objetivos de negcios.
35
O princpio bsico da biblioteca ITIL o objeto de seu

gerenciamento: a infraestrutura de TI. O ITIL descreve os
processos que so necessrios para dar suporte utilizao
e ao gerenciamento da infraestrutura de TI. Outro princpio
fundamental do ITIL o fornecimento de qualidade de servio
aos clientes de TI com custos justificveis, isto , relacionar os
custos dos servios de tecnologia e como estes trazem valor
estratgico ao negcio.
O interesse nesta rea deve-se ao fato de que, atravs de
metodologias (processos) padronizadas de Gerenciamento do
Ambiente de TI, possvel obter uma relao adequada entre
custos e nveis de servios prestados pela rea de TI.
Ao usar o ITIL, a organizao se torna capaz de melhorar
a qualidade, eficincia e eficcia na prestao de servios,
alm de diminuir a exposio ao risco. Os processos ITIL
precisam ser implementados para cada organizao, pois
correspondem a um modelo (apresentado na Figura 3) e no
uma regra rgida a ser seguida.
Segurana da Informao
A informao um conjunto de dados que, como qualquer
outro ativo importante, essencial para os negcios de uma
organizao e consequentemente necessita de cuidado e
proteo. Como a interconectividade tem crescido, a informao vem sendo cada vez mais exposta a pessoas, ameaas
e riscos.
Independente de qual seja a forma que a informao est representada sempre recomendado que ela seja protegida adequadamente. Com isso, segurana da informao a proteo
da informao das ameaas na busca de manter a continuidade
do negcio, diminuir os riscos e maximizar retornos.
A segurana da informao obtida atravs da implementao de um conjunto de controles e tcnicas adequadas,
para a proteo da informao. Estas tcnicas precisam ser
trabalhadas para que sejam atendidas as necessidades de
segurana.
Histrico da NORMA NBR ISO/IEC 17799:2005

O DTI (Departamento de Comrcio e Indstria do Reino
Unido), com a necessidade de criar uma estratgia de segurana para as informaes do Reino Unido, criou em 1987 o
CCSC (Comercial Computer Security Center), que tinha como
objetivo criar uma norma de segurana que os atendesse.
Como a necessidade era alta, vrias empresas e instituies
internacionais buscaram estabelecer metodologias e padres
que melhor ajudasse o mercado em suas pendncias relativas
Segurana da Informao.
Em 1989 depois de ter criado vrios documentos preliminares o CCSC criou a BS 7799 (British Standard 7799), essa
foi uma norma de segurana da informao destinada a
empresas, criada na Inglaterra em 1995 e disponibilizada
para consulta pblica dividida em duas partes: a primeira
(BS 7799-1) em 1995, a segunda (BS 7799-2) em 1998.
A (BS 7799-1) a parte da norma que planejada como
um documento de referncia para por em execuo boas
36
Figura 3. Modelo do ITIL
prticas de segurana na empresa. A (BS 7799-2) a parte

da norma que tem o objetivo de proporcionar uma base
para gerenciar a segurana da informao dos sistemas da
empresa. Aps um trabalho rduo de internacionalizao
e consultas pblicas, foi aceita em dezembro de 2000, a BS
7799 como padro internacional pelos pases membros as
ISO. Isto implica na juno de duas organizaes ISO (International Standardization Organization) e IEC (International
Engineering Consortium), sendo assim denominada ISO /
IEC 17799:2000.
A ISO uma organizao internacional formada por um
conselho e comits com membros oriundos de vrios pases.
Seu objetivo criar normas e padres universalmente aceitos sobre a realizao de atividades comerciais, industriais,
cientficas e tecnolgicas. A IEC uma organizao voltada
ao aprimoramento da indstria da informao. Com isso em
dezembro de 2000 a ABNT (Associao Brasileira de Normas
Tcnicas) tambm resolveu acatar a norma ISO como padro
brasileiro sendo publicada em 2001 como: NBR 17799 Cdigo de Prtica para a Gesto da Segurana da Informao.
O importante que a partir dessa publicao passamos a
ter um referencial de aceitao internacional.
No segundo semestre de 2005 foi lanada nova verso
da norma, a norma ISO / IEC 17799:2005, que cancela e
substitui a edio anterior.
Governana de Segurana da Informao

Ao descrever o cenrio atual para o gerenciamento de Segurana da Informao, cria-se a necessidade e justifica-se
a importncia de se alcanar um Modelo de Governana da
Segurana da Informao. Esse modelo dever ser utilizado
pelas organizaes para que a Segurana da Informao
no seja tratada apenas no mbito tecnolgico, mas reconhecida como parte integrante do planejamento estratgico
das organizaes no processo de tomada de deciso. O IIA
(The Institute of Internal Auditors) publicou um trabalho onde
destaca que, uma vez que os diretores das organizaes so
responsveis pelos bons resultados e pela continuidade da
organizao que eles governam, eles precisam aprender a
identificar atualmente as questes corretas sobre segurana
gest o de ti
1. CAMARGO, Francisco. Inimigo digital agita o setor financeiro. Mdulo Security Magazine,
2003.
2. DAMIANIDES, Mario. Sarbanes-Oxley and IT Governance: New Guidance on IT Control
and Compliance. ABI/INFORM Global, 2004.
3. FAGUNDES, Carlos. Introduo ao Risco Operacional. Disponvel on-line em: http://
www.clm.com.br/abbc/docs/RiscoOperacional-Palestra.pdf.
4. GHERMAN, Marcelo. Principais caractersticas do framework COBIT. So Paulo: Sicurezza, 2005.
5. ISO-International Organization for Standardization/ International Electrotechnical
Committee. Information technology- Code of practice for information security
management. Reference number ISO/IEC 17799:2000(E).
6. ITGI - THE IT GOVERNANCE INSTITUTE.COBIT: Control Objectives for information and
related Technology, 2000.
7. ITGI, IT Governance Institute. Board Briefing on IT Governance. ISACF, Information
Systems Audit and Control Foundation, 2003.
8. ITGI, IT Governance Institute. Executive Summary. ISACF, Information Systems Audit and
Control Foundation. CobiT 3rd Edition, 2000.
9. ITGI, IT Governance Institute. Student Book. ISACF, Information Systems Audit and
Control Foundation. CobiT 3rd Edition, 2004.
10. KFOURI, Eduardo. Alinhamento Estratgico, Mobilidade e Segurana: A viso do
mercado. Plano Editorial Ltda, 2004.
11. OGC Office of Government Commerce. ITIL: The Key to Managing IT Services Best
Practice for Service Support, 2001.
12. PAULK, M.C.; CURTIS, B; CHRISSIS, M.B.;WEBER, C.V. Capability Maturity Model for
Software, version 1.1. Technical Report, Carnegie Mellon Software Engineering Institute,
CMU/SEI-93-TR-024, 1993.
13. PEIXOTO, Rodney de Castro. Implicaes da Lei Sarbanes-Oxley na Tecnologia da
Informao. Mdulo Security Magazine, 2004.
14. ROCHA, Lus Fernando. Governana em TI e Segurana: COBIT e ISO 17799 no mercado
financeiro. Mdulo Security Magazine, 2003.
15. VAN GREMBERGEN, Wim. Strategies for Information Technology Governance. Idea
Group Publishing, 2003.
16. WEILL, Peter; ROSS, Jeanne W. Governana de TI: como as empresas com melhor
desempenho administram os direitos decisrios de TI na busca por resultados superiores.
M. Books do Brasil Editora Ltda., 2006.

Feedback
eu
37
sobre e
s
Concluindo, este artigo reitera a dependncia que a governana do sistema financeiro possui com a governana de TI
das instituies que participam desse setor. Na medida em
que a gesto da informao e da TI responde aos objetivos e
estratgias das organizaes, as relaes e interaes entre as
organizaes tendem a ser mais efetivas.
Por este motivo, estruturar os processos de TI, tendo por
referncia a combinao dos frameworks do CobiT e ITIL,
uma forma dessas empresas se prepararem para as exigncias
Referncias
D
s
Concluso
dos acionistas, do mercado e da legislao em termos de boas

prticas de governana em TI, assegurando que a rea de TI
esteja alinhada aos objetivos de negcio, de maneira que os
servios sejam entregues na qualidade e segurana necessrias, mantendo-se os prazos e custos planejados e mitigando
os riscos de auditoria e de negcio associados.
edio
ta
computacional e ainda, consider-las como parte de sua

responsabilidade.
Atualmente as responsabilidades acerca da segurana
computacional so frequentemente delegadas ao gerente de
segurana (Chief Security Officer) das organizaes, gerando
conflitos em relao ao oramento destinado a essa rea e a
necessidade de impor medidas que vo alm de seu escopo
de atuao. Dessa forma, muito comum encontrar um cenrio onde as questes de segurana computacional no so
tratadas em um nvel de gesto da organizao, tendo como
consequncia a falta de recursos para minimizar os riscos
existentes ao nvel exigido pela estratgia organizacional e
definido pela anlise de risco.
A responsabilidade pelo nvel correto de segurana da
informao deve ser uma deciso estratgica de negcios,
tendo como base um modelo de Governana da Segurana
da Informao que contemple uma anlise de risco.
Em um relatrio do Corporate Governance Task Force proposto que, para proteger melhor a infraestrutura de TI, as
organizaes deveriam incorporar as questes de segurana
computacional em suas aes de governana.
Em um trabalho publicado em 2003, o BSA (Business Software
Alliance) chama a ateno para a necessidade de desenvolver
um Modelo de Governana da Segurana da Informao que
possa ser adotado imediatamente pelas organizaes. Nesse
trabalho sugerido que os objetivos de controle contidos
na ISO 17799 devam ser considerados e ampliados para o
desenvolvimento de um modelo onde segurana da informao no seja considerada apenas no plano tecnolgico,
mas parte integrante das melhores prticas corporativas,
no deixando de cobrir aspectos relacionados a pessoas,
processos e tecnologia.
Para que as organizaes obtenham sucesso no processo de
segurana de sua informao, os gestores precisam tornar a
segurana computacional uma parte integrante da operao
do negcio da organizao. A forma proposta para se conseguir isso a estruturao de um Modelo de Governana
da Segurana da Informao como parte do controle interno
e polticas que faam parte da Governana Corporativa.
Considerando-se esse modelo, a segurana da informao
deixaria de ser tratada apenas como uma questo tcnica,
passando a ser um desafio administrativo e estratgico.
Desenvolvimento
Nesta seo voc encontra artigos voltados para diferentes
abordagens de apoio ao desenvolvimento de projetos de software
Refatorao para Padres

Aplicando refatoraes para apoiar a utilizao de padres de projeto

Aborda o tema refatorao para padres com o objetivo de mostrar como o desenvolvedor pode uslo para melhorar o cdigo-fonte de suas aplicaes.
Para que serve?
Jacimar Fernandes Tavares

jacimar.tavares@studentpartners.com.br
Aluno do Curso de Bacharelado em Cincia da Computao da FAGOC - Faculdade

Governador Ozanam Coelho, Microsoft
Student Partners.

Doutor e Mestre em Engenharia de Sistemas e Computao pela COPPE/UFRJ,

Especialista em Mtodos Estatsticos Computacionais e Bacharel em Informtica pela
UFJF, professor do curso de Bacharelado em
Cincia da Computao da FAGOC, professor
dos Cursos de Bacharelado em Sistemas de
Informao do Centro de Ensino Superior
de Juiz de Fora e da Faculdade Metodista
Granbery, Analista de Sistemas da Prefeitura de Juiz de Fora, Editor da Engenharia de
Software Magazine.
38
idia de projetar software reutilizvel vem de que toda boa

experincia deva ser reutilizada
aliada ao fato de que nem sempre interessante projetar algo do zero, ou seja,
aconselhvel reutilizar as boas prticas e
idias que deram certo em outros projetos. Nesse sentido, um dos objetivos da literatura tcnica sobre padres de projeto
registrar o conjunto de boas prticas em
projetos orientados a objetos que deram
certo atravs de padres de projeto.
A catalogao dos padres de projeto
apresenta suas caractersticas (elementos) como:
nome do padro de projeto que a
forma de identificao do padro;
o problema a que o padro de projeto se
refere e onde interessante aplic-lo, ou
Engenharia de Software Magazine - Refatorao para Padres
Para prover conhecimento ao desenvolvedor sobre

refatorao para padres e demonstrar atravs de
um exemplo prtico a aplicao de uma tcnica de
refatorao para padres: Substituir construtores
por mtodos de criao.

O tema se torna fundamental para desenvolvedores que j esto familiarizados com padres
de projeto e j os implementam em seus softwares e que querem saber mais sobre refatorao
para padres, conhecendo os benefcios que sua
utilizao traz.
seja, qual melhor contexto ele se encaixa

no projeto;
a soluo que uma forma de resolver
um problema com a aplicao deste padro, mas no sendo a nica forma para
resolver o problema;
e as conseqncias que o resultado
da anlise do uso do padro em um
desenvolvimento
determinado ponto, bem como os prs e contra da sua utilizao naquele contexto.
Um formato especfico foi criado para descrever cada padro
de uma forma que se torne mais fcil entend-lo e aplic-lo,
como uma espcie de gabarito para o padro de projeto. Este
gabarito formado por:
Nome do padro e sua classificao;
Inteno e objetivo do padro: que mostra qual a funo do
padro;
Tambm conhecido como: que a descrio dos outros possveis nomes que o padro pode ser conhecido;
Motivao para o uso do padro: que a definio de um
problema de projeto no qual o padro pode ser aplicado;
Estrutura do padro: que sua representao grfica atravs
de diagramas;
Participantes: que a definio de quais objetos e classes pertencem ao projeto e a responsabilidade que cada um assume,
entre outras caractersticas dos padres de projeto.
Outra importante referncia sobre padres de projeto, encontrada em [1], se destaca pela abordagem diferenciada, onde
possvel aprender, atravs de estudos de casos, um pouco da
experincia que alguns desenvolvedores adquiriram ao decorrer dos anos na utilizao das tcnicas de padres de projeto. A
apresentao dos benefcios que o uso dos padres de projeto
traz se torna evidente nesse tipo de abordagem.
Adquirir conhecimento sobre os padres de projeto fundamental, pois munido disso, o desenvolvedor ser capaz de
identificar situaes no sistema que esteja desenvolvendo,
e assim saber escolher qual padro melhor se encaixa neste
contexto.
Refatorao para padres um tema que est totalmente
relacionado a padres de projeto, portanto ser abordada a
importncia de se conhecer essas tcnicas e como us-las no
dia a dia do desenvolvimento de software em paralelo com o
conhecimento sobre padres (ler Nota do DevMan 1). Neste
sentido, neste artigo ser apresentada a primeira tcnica de
refatorao para padres que Substituir construtores por
mtodos de criao, bem como um exemplo prtico para
ilustrar sua aplicao em um cenrio real.
Refatorao para Padres

Entre os desenvolvedores, torna-se cada vez mais comum
identificar adeptos de diferentes formas de se utilizar padres
de projeto em uma soluo. Alguns optam por, no momento
em que esto planejando a soluo, j definirem quais padres
de projeto vo utilizar, fazendo com que o produto final j
possua a implementao dos padres de projeto escolhidos.
Outra forma comum de se utilizar padres de projeto seria a
de desenvolver livremente o software, e aps concluda a etapa
de desenvolvimento, acrescentar os padres que fazem mais
sentido no contexto do projeto.
A segunda alternativa permite trabalhar com padres de
projeto atravs da aplicao de tcnicas de refatorao para
padres, onde o produto seria modificado, a fim de acrescentar padres de projetos importantes no contexto do projeto,
sem criar alteraes externas ao software, no permitindo
que novas caractersticas sejam adicionadas, o que no caso
caracterizaria alteraes de comportamento no software (ler
Nota do DevMan 2).
O uso desta tcnica aprimora a concepo (design) de um
software e evita a deteriorao to comum durante o ciclo de
vida de um cdigo. Esta deteriorao geralmente causada por
mudanas com objetivos de curto prazo ou por alteraes realizadas sem a clara compreenso da concepo do sistema.
Outra consequncia a melhora no entendimento do cdigo, o que facilita a manuteno e evita a incluso de defeitos.
Esta melhora no entendimento vem da constante alterao do
cdigo com objetivo de facilitar a comunicao de motivaes,
intenes e objetivos por parte do programador.
Porque refatorar para padres?

Para que o desenvolvedor faa uso das tcnicas de refatorao para padres, necessrio que ele entenda os motivos
nos quais ele deve se basear antes de considerar o uso de uma
tcnica em um ponto do seu software. Assim, importante
ter em mente que refatorao para padres pode ser utilizada
para, por exemplo:
Permitir que o software se torne manutenvel, possibilitando assim que novas funcionalidades ou novo cdigo seja
inserido com mais facilidade. Quando se insere uma nova
funcionalidade, devem-se considerar duas formas de faz-la:
inserir sem se preocupar com o projeto do sistema (indicado
para situaes em que h urgncia na entrega da nova funcionalidade), ou analisar o projeto do software e modific-lo,
se necessrio, para receber a nova funcionalidade (indicado
para situaes onde o desenvolvedor tem mais tempo para
planejar a mudana).
Nota do DevMan 1
Refatorao para padres
As tcnicas de refatorao para padres no contemplam apenas os padres de
projeto mais conhecidos como os do livro Padres de Projeto: solues reutilizveis
de software orientado a objetos. Algumas tcnicas permitem a insero de padres
de projeto que contribuem apenas para uma melhoria do cdigo fonte, como o caso
da refatorao apresentada neste artigo.
Nota do DevMan 2
Refatorao
Refatorao (do ingls Refactoring) o processo de modificar um sistema de software
para melhorar a estrutura interna do cdigo sem alterar seu comportamento externo.
39
Contribuir para uma melhoria na aplicao, com relao

ao cdigo fonte. Quando se refatora para padres, consequentemente comeam a surgir mudanas no cdigo fonte que o
tornam mais simples de entender e rastrear.
Aumentar a legibilidade do cdigo. Considerando o fato
de que alguns desenvolvedores usam a criatividade para escrever novas funcionalidades, corre-se o risco de se ter uma
aplicao onde o cdigo no transparea sua real inteno
logo que analisado por outra pessoa. Neste caso, a utilizao das tcnicas de refatorao para padres permitir que
o cdigo seja modificado e se torne mais legvel a qualquer
pessoa.
Permitir que o desenvolvimento da aplicao se torne
mais prazeroso. Quando se refatora, algumas caractersticas
indesejveis em um cdigo podem ser removidas, como por
exemplo, diversas responsabilidades atribudas a uma nica
classe. Problemas deste tipo acabam dificultando o processo de
mudanas neste cdigo e toda ao deve ser cuidadosamente
efetuada, causando um desgaste no desenvolvedor ao trabalhar
neste cdigo fonte.
Classificao e composio de uma refatorao para

padres
Joshua Kerievsky, em seu livro sobre refatorao para
padres, descreve 27 tcnicas que auxiliam no processo de
insero de padres de projeto em uma aplicao, cada uma
com um objetivo especfico. As tcnicas apresentadas so:
Substituir construtores por mtodos de criao. Refatorao
para o padro Mtodo de Criao, com objetivo de remover
construtores, substituindo-os por mtodos responsveis pela
criao de objetos, uma vez que construtores no deixam claro,
se analisados apenas seus nomes, como se d a instanciao dos
objetos. Com um mtodo de criao, o desenvolvedor poder
deixar clara a inteno do mtodo ao definir um nome que
reflita a sua funo.
Mover Conhecimento de Criao para Factory. Permite a
insero do padro Factory. Esta refatorao para padres
mostra ao desenvolvedor como identificar cdigo e informaes usadas para instanciar objetos de uma classe que esto
divididas por diversas outras classes, permitindo mov-los
para uma Factory.
Encapsular Classes com Factory. Refatorao para padres
tambm voltada para o padro Factory. Uma Factory criada
para permitir que clientes criem instncias de determinadas
classes que foram encapsuladas para evitar a instanciao direta de objetos das classes contidas em um pacote ou que so
responsveis pela implementao de uma interface.
Introduzir criao polimrfica com Factory Method. Com
o objetivo de implementar o padro Factory Method, esta
refatorao atua em classes pertencentes a uma hierarquia
de classes, onde implementam alguns mtodos de forma
semelhante, mas que diferem em apenas alguns passos da
implementao. Nesse contexto, o mtodo ter uma verso
nica na classe pai, e uma Factory Method ser responsvel
por sua manipulao.
40
Encapsular Composite com Builder. Refatorao voltada para

os padres Builder e Composite, permitindo que o cdigo que
cria objetos complexos sejam simplificados de tal forma que o
trabalho de instanciar esses objetos se torne mais simples.
Internalizar Singleton. Tcnica de refatorao para padres
que contraria o padro Singleton. Ela atua em sistemas removendo Singletons que foram criados em excesso. Isto acontece
porque alguns desenvolvedores fazem uso excessivo deste
padro.
Compor Mtodo. Atua em mtodos onde a lgica complicada de entender. Esta refatorao fornece subsdios para que
o desenvolvedor identifique esse problema e refatore o mtodo
em uma sequncia de passos que demonstre seu objetivo de
forma mais clara.
Substituir Lgica Condicional por Strategy. Refatorao
para o padro Strategy. Alguns trechos de cdigo apresentam uma complexa lgica condicional para definir que tipo
de objeto ou mtodo ser criado ou executado. Com esta
tcnica, cria-se um Strategy para cada possibilidade da lgica
condicional.
Mover embelezamento para Decorator. Cria-se um Decorator para receber cdigos que esto presentes em algumas
classes, que acabam tirando a responsabilidade bsica dela.
Isso acontece porque, ao inserir novas funcionalidades no sistema, acaba-se inserindo novas responsabilidades nas classes
que fazem com que, ao longo do tempo, detectar o objetivo da
classe se torne uma tarefa mais complexa.
Substituir condicionais que alteram estados por State.
Tcnica voltada para a insero do padro State. Atua em
expresses condicionais responsveis pelo controle de mudanas de estado de um objeto, que naturalmente tendem a ser
complexas, substituindo-as por classes State que manipularo
essas mudanas.
Substituir rvore implcita por Composite. Algumas estruturas de cdigo, se analisadas com ateno, parecem ser uma
rvore, mas de forma implcita, ou seja, possuem caractersticas
de uma rvore, mas no caracterizam um tipo de estrutura de
dados de uma rvore. O problema com essas estruturas que
elas complicam o cdigo, tornando-o mais difcil de rastrear.
Usa-se essa refatorao para remover essa rvore implcita,
levando consigo a sua complexidade e substituindo-a por um
Composite.
Substituir envio condicional por Command. Esta refatorao para padres permite ao desenvolvedor melhorar o projeto
de cdigo existente ao identificar e remover lgica condicional
responsvel por permitir a escolha de quais aes devem ser
executadas. Isto possvel graas ao padro Command, que
utilizado para criar um comando que substitua cada ao a
ser executada pela lgica condicional, levando para si o cdigo
que executa a ao escolhida.
Formar Template Method. Alguns mtodos em uma hierarquia de classes possuem implementaes semelhantes, com pequenas variaes. Com esta refatorao para o padro Template
Method se torna possvel criar um mtodo generalizado com os
passos comuns aos mtodos e mov-lo para a classe pai.
desenvolvimento
Extrair Composite. Extrair Composite permite ao desenvolvedor extrair uma classe pai, partindo do princpio que
existem classes filhas que esto implementando o mesmo
Composite. Neste contexto, move-se o Composite para a classe
pai recm criada.
Substituir distino um/muitos por Composite. Permite a
remoo de cdigo duplicado, pois alguns desenvolvedores
criam mtodos semelhantes mas que se diferem por um manipular apenas um objeto de uma classe e outro manipular
uma lista desses objetos.
Substituir notificaes hard-coded por Observer. Alguns
desenvolvedores implementam classes filhas com a nica
responsabilidade de avisar quando um objeto de uma determinada classe foi criado. Com essa refatorao torna-se possvel
remover esta classe e permitir que sua classe pai faa esse
trabalho ao implementar uma interface do tipo Observer.
Unificar Interfaces com Adapter. Esta tcnica permite a
implementao do padro Adapter quando identificado o
uso excessivo de uma interface em relao a outra interface de
uma classe. Assim, torna-se possvel juntar interfaces criando
um adaptador.
Extrair Adapter. Outra forma de se inserir o padro Adapter
quando o desenvolvedor tem classes que carregam consigo cdigo referente a vrias verses de, por exemplo, um
componente. Como cada verso pode resultar em mudanas,
alguns desenvolvedores acabam sobrecarregando a classe
ao permitir que ela possua cdigo para vrias verses. Com
esta refatorao para padres, pode-se criar um Adapter para
resolver o problema.
Substituir linguagem implcita por Interpreter. Permite a
criao de interpretadores para linguagens implcitas, onde diversas classes so criadas para os elementos dessa linguagem,
substituindo um conjunto de mtodos de uma nica classe que
continham os elementos da linguagem implcita.
Substituir cdigo de tipo por Classe. Tcnica de refatorao
para padres que permite a remoo de cdigo que faz muito
uso de tipos primitivos de dados substituindo-os por tipos de
atributos de uma classe. Esta ao proporciona mais segurana
ao cdigo contra atribuies ou comparaes inseguras ou
invlidas de dados que podem ocorrer com tipos primitivos.
Limitar instanciao com Singleton. Ao contrrio da refatorao para padres Internalizar Singleton, esta tcnica
auxilia na implementao de Singletons quando h vrias
instncias de um mesmo objeto, quando na verdade deveria
haver apenas uma.
Introduzir objeto nulo. Realizar operaes com atributos
ou variveis que possuem valor nulo pode ocasionar falhas no
sistema. Para isso, alguns desenvolvedores escrevem cdigo
para verificar se esses atributos ou variveis no so nulos
antes de continuar, o que acaba se repetindo por vrios pontos
no sistema inserindo muito cdigo duplicado. Com o padro
Objeto Nulo, possvel reter esse cdigo em um nico lugar e
referenci-lo sempre que preciso, evitando duplicaes.
Mover acumulao para parmetro coletor. O padro de
projeto Parmetro Coletor permite a criao de um objeto que
passado para alguns mtodos com a responsabilidade de

colher informaes. Ele til, pois h mtodos que acabam
acumulando muita informao em uma varivel local, o que
dificulta o entendimento do mtodo, pois ao longo dele vrias
modificaes so feitas no valor contido nessa varivel. Esta
tcnica de refatorao para padres demonstra como implementar tal padro.
Mover Acumulao para Visitor. Implementa uma classe
Visitor responsvel por visitar determinadas classes onde colhe
informaes. Esta refatorao para padres permite remover
mtodos que antes desempenhavam a funo de colher essas
informaes.
Encadear Construtores. Tcnica de refatorao para padres
que permite a remoo de cdigo duplicado em mtodos construtores. Esta ao torna a classe mais manutenvel, uma vez
que o custo de uma mudana se tornar menor, dado que, por
exemplo, ao se introduzir novos atributos, o desenvolvedor
ter que alterar menos cdigo.
Unificar Interfaces. Essa refatorao para padres permite
unificar interfaces de classes pai e classes filhas, quando h
necessidade de que ambas faam uso da mesma interface para
manipular objetos polimorficamente.
Extrair Parmetro. Tcnica indicada para momentos em que
se precisa alterar algum valor de um atributo de um objeto
recm instanciado por um mtodo de criao ou construtor.
Estas 27 refatoraes para padres so divididas em categorias e classificadas de acordo com a sua natureza, que so:
Criao: abrange as tcnicas que lidam com problemas no
projeto de cdigo de uma soluo, na criao de objetos de
uma classe, por exemplo.
Simplificao: contm o conjunto das tcnicas que podem
ser aplicadas para simplificar o cdigo fonte da aplicao,
removendo cdigo desnecessrio.
Generalizao: conjunto das tcnicas que transformam o
cdigo especfico em cdigo mais generalizado, permitindo
assim que muitas duplicaes no cdigo sejam removidas.
Proteo: contempla as refatoraes para padres que,
quando aplicadas, proporcionam maior proteo ao cdigo,
como proteger atributos de classes contra atribuies de dados
inseguros ou incorretos.
Acumulao: trata-se da utilizao das tcnicas que manipulam cdigo que retm muitas das informaes da aplicao.
Utilitrias: refatoraes para padres consideradas de baixo
nvel, ou seja, que so apenas os primeiros passos para refatoraes maiores, como as das categorias anteriores.
Alm disso, as refatoraes para padres existentes seguem
um template que servem para auxiliar o desenvolvedor na tarefa de compreender as particularidades e os pontos importantes
de cada tcnica que descrita em partes como:
Nome da refatorao para padres: fundamental para que
as refatoraes se tornem fceis de serem identificadas, permitindo assim que haja uma comunicao mais eficiente entre
membros de equipe de desenvolvimento, por exemplo.
41
Resumo da refatorao para padres: apresenta um breve

resumo sobre o que a refatorao para padres e quais as
mudanas que ela pode proporcionar. Podem ser usados
tambm diagramas UML (Unified Modeling Language
Linguagem de Modelagem Unificada). Uma representao
em forma de seta utilizada para apontar o diagrama depois
da refatorao aplicada.
Motivao para usar a refatorao para padres: neste
ponto o desenvolvedor ser motivado a usar ou no a refatorao, dependendo do seu contexto. Uma breve introduo
sobre o padro de projeto que a refatorao trata tambm
descrito, alm das vantagens e desvantagens do uso da
refatorao para padres em questo.
Mecnica da refatorao para padres: descreve uma
sequncia de passos para o desenvolvedor efetuar a refatorao para padres no seu software. Esse passo a passo
no implica em uma obrigatoriedade. Devem ser utilizados
dependendo do contexto do projeto, no permitindo que eles
venham a complicar o cdigo ao invs de simplificar.
Exemplo do uso da refatorao para padres: aqui apresentado um exemplo de cdigo que necessita ser refatorado
utilizando a tcnica de refatorao para padres em questo,
seguindo uma sequncia de passos at a obteno do resultado. Nos cdigos de exemplo, comum que apenas a parte
importante para o processo de refatorao para padres seja
mostrada, omitindo-se a parte que pode vir a atrapalhar o
entendimento do usurio sobre o que est sendo feito.
Variaes nas refatoraes para padres: esta no
uma parte comum a todas as refatoraes para padres,
pois descreve algumas variaes que ocorrem em apenas
algumas delas.
A seguir ser apresentada a refatorao para padres
Substituir construtores por mtodos de criao, que pertence ao conjunto das refatoraes de Criao.
Figura 1. Diagrama da classe Alunos, antes e depois da Refatorao
chamados em nenhum ponto da aplicao, portanto eles

acabam permitindo que a classe contenha mais cdigo do
que normalmente ela teria que possuir.
Essa refatorao para padres sugere que o desenvolvedor
identifique classes que se encaixam neste contexto e as refatore, trocando esses construtores por mtodos de criao que
indicaro com mais preciso o objetivo do cdigo. Um mtodo
de criao um mtodo que cria instncias daquela classe.
Vantagens: deixa mais clara a inteno do mtodo em
questo, acaba com o problema de se ter que criar um novo
construtor com os mesmos argumentos que um outro construtor existente e permite que o desenvolvedor identifique
mais facilmente cdigo que no est sendo usado.
Substituir construtores por mtodos de criao
Desvantagem: quando utilizada, essa refatorao acaba

permitindo que a criao de alguns objetos seja feita usando
o operador new e outras usando mtodos de criao.
Resumo: Classes com diversos construtores, onde cada

um desempenha diferentes funes so difceis de serem
identificados e invocados pelo desenvolvedor no processo
de desenvolvimento. Esta refatorao prope a troca desses
construtores por mtodos de criao (Figura 1).
Motivao: Uma prtica comum a alguns desenvolvedores
a de criar classes com vrios construtores, que permitem
assim que objetos sejam instanciados de diversas formas.
Isto no errado, mas se considerada uma classe com
vrios construtores, a tarefa de identificar qual deles deve
ser chamado para criar um objeto se torna mais arriscada,
pois o desenvolvedor corre o risco de escolher um que
aparentemente o que se busca. Para garantir que o construtor que est sendo chamado o correto, algumas vezes
o desenvolvedor verifica seu cdigo para se certificar da
sua escolha.
Outro problema est ligado ao fato de que em uma classe pode haver construtores que j no esto mais sendo
Mecnica: Os passos desta seo descrevem em forma de

tpicos os passos usados nesta refatorao.
1. Inicia-se o processo com a localizao de um construtor
carregado com todos os atributos da classe. Caso este construtor no exista, ele deve ser criado, pois ser necessrio em
um dos passos seguintes. Localize um ponto no sistema que
esteja fazendo chamada a um dos construtores da sua classe
e faa uma extrao de mtodo, para se obter um mtodo de
criao. Mova o mtodo extrado para a sua classe.
2. Localize todas as chamadas ao construtor que est sendo
refatorado e faa com que, a partir deste momento, passe a
chamar o mtodo recm-criado.
3. Verifique se o construtor escolhido est sendo chamado
por outro construtor. Se sim, modifique para que o mtodo
de criao chame o construtor que est sendo chamado.
4. Agora se deve repetir os passos 1 e 3 em todos os construtores que quiser refatorar.
42
desenvolvimento
5. Altere os moderadores de acesso dos construtores que no

so chamados de fora da classe em que se est trabalhando
para privado.
Aps a execuo de cada passo desses, recomendado que se
compile a aplicao e execute testes para verificar que no houve
mudanas de comportamento no cdigo fonte.
Exemplo: O cdigo que ser refatorado neste exemplo pertence
a uma classe chamada Alunos, que possui quatro construtores,
dos quais sero refatorados dois: o segundo e o terceiro, como
pode ser visto na Listagem 1. O primeiro e o ltimo construtor
no sero refatorados, pois o primeiro vazio e o ltimo o
construtor que contm todos os parmetros, como mencionado
no primeiro passo da seo Mecnica.
A Listagem 1 mostra o cdigo contendo os mtodos construtores
da classe Alunos. Nas linhas 7 a 17 temos os construtores que sero refatorados. A refatorao comear pelo segundo construtor,
linhas 7 a 12, por uma questo de sequncia apenas.
Primeiro passo: encontrar uma chamada para o primeiro construtor que vamos refatorar. A Listagem 2 mostra um exemplo de
uma chamada encontrada.
Extrai-se o mtodo desta chamada, como mostra a Listagem 3,
atribuindo a ele o nome que o mtodo de criao dever possuir.
Neste caso est sendo usado o nome CriarAluno.
O mtodo extrado deve passar a ser pblico, e o tipo de retorno
como o tipo da classe, no caso Alunos. Por fim, deve-se retornar
uma chamada ao mtodo construtor que se est refatorando. O
mtodo extrado deve ficar como mostra a Listagem 4.
Aps concludas as mudanas, deve-se mover o mtodo Criar
Aluno para a classe Alunos, como mostra a Listagem 5.
Nas linhas 7 a 12 encontra-se o mtodo construtor que est sendo
refatorado. Nas linhas 13 a 16 est o mtodo de criao criado para
substituir o construtor. A chamada ao mtodo construtor, que
agora chama o mtodo de criao movido para a classe Alunos,
deve ser modificada, como mostra a Listagem 6.
Neste momento, o cdigo compilado e testado. Assim pode-se
comprovar que o primeiro passo da refatorao foi concludo, e
que no houve mudanas no comportamento do software.
Segundo passo: percorre-se o cdigo em busca de novos pontos
onde h chamadas para o mtodo construtor que est sendo refatorado. Atualiza-se todas as chamadas como feito na Listagem 6,
para que, ao invs de chamar o construtor, passem a chamar o
mtodo de criao recm-criado.
Terceiro passo: como o mtodo construtor agora chamado pelo
mtodo de criao, deve-se permitir que o mtodo de criao agora desempenhe a funo que o mtodo construtor desempenha,
para que se torne possvel a sua remoo e somente o mtodo
de criao permanea na classe Alunos. A Listagem 7 mostra o
resultado dessas alteraes.
Nas linhas 7 a 12 da Listagem 5 est o mtodo construtor que est
sendo trabalhado e que foi removido, como mostra a Listagem 7.
Agora a funo que o mtodo construtor desempenhava foi movida para o mtodo de criao (linhas 9 a 11 da Listagem 7) e na
linha 11 retornado o objeto construdo atravs da chamada ao
mtodo construtor mais completo (linhas 18 a 24, Listagem 7).
Listagem 1. Mtodos construtores da classe Alunos.

1. public class Alunos
2. {
3. ...
4. public Alunos()
5. {
6. }
7. public Alunos(String nome)
8.
{
9.
Random matricula = new Random();
10.
this.Nome = nome;
11.
this.Matricula = Convert.ToUInt16(matricula.Next(0, UInt16.MaxValue));
12. }
13. public Alunos(String nome, DateTime dataNascimento)
14. {
15.
this.Nome = nome;
16.
this.Idade = Convert.ToUInt32(DateTime.Today.Year) Convert.ToUInt32(dataNascimento.Year);
17. }
18.
19.
20.
21.
22.
23.
24.
25. }
public Alunos(String nome, UInt32 matricula,

DateTime dataNascimento, UInt32 idade)
{
this.Nome = nome;
this.Matricula = matricula;
this.DataNascimento = dataNascimento;
this.Idade = idade;
}
Listagem 2. Chamada ao construtor

1. String nome = Joo;
2. Alunos objAluno2 = new Alunos(nome);
Listagem 3. Extrao de mtodo.
1. public static void CriarAluno(String nome)
2. {
3. Alunos objAluno2 = new Alunos(nome);
4. }
Listagem 4. Mtodo extrado depois de modificado.
1. public static Alunos CriarAluno(String nome)
2. {
3. return new Alunos(nome);
4. }
A importncia da existncia deste construtor mais completo

foi destacada no incio do tpico Mecnica. Nota-se que alguns
parmetros que antes no estavam presentes no construtor removido agora esto presentes na chamada ao construtor completo
no mtodo de criao, como data de nascimento e idade.
Quarto passo: este passo a repetio dos passos 1 e 3, onde
se devem criar mtodos de criao para todos os construtores
que ainda faltam ser refatorados, como mostra a Listagem 7, nas
linhas 13 a 17.
Aplicado o passo 4, a classe Alunos que antes continha quatro
mtodos construtores que no deixavam clara suas intenes,
agora possui apenas o construtor vazio e o principal, como
mostra a Listagem 8, e os mtodos de criao que substituram
os construtores.
Variao: a aplicao desta refatorao no necessariamente
deve ser feita em todos os mtodos construtores. Caso haja uma
classe com dezenas de construtores, o processo de refator-la
43
Listagem 5. Mtodos da classe Alunos.
Listagem 8. Classe Alunos refatorada

2. {
3. ...
4. public Alunos()
5. {

2. {
3.
...
4.
public Alunos()
5.
{
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
6.
7.
8.
9.
10.
public static Alunos CriarAluno(String nome)

{
UInt16 Matricula = Convert.ToUInt16(matricula.
Next(0, UInt16.MaxValue));
return new Alunos(nome, Matricula, DateTime.Today,0);
}
public static Alunos DescobrirDataNascimento(String nome,
DateTime dataNascimento)
{
UInt32 idade = Convert.ToUInt32(DateTime.Today.Year) Convert.ToUInt32(dataNascimento.Year);
return new Alunos(nome, 0, dataNascimento,idade);
}
{
this.Nome = nome;
this.Idade = idade;
}
23. public Alunos(String nome, UInt32 matricula, DateTime dataNascimento,

UInt32 idade)
24. {
25.
this.Nome = nome;
26.
27.
28.
this.Idade = idade;
29. }
30. }
Listagem 6. Nova chamada ao mtodo de criao criado.
1. String nome = Joo;
2. Alunos objAluno2 = Alunos.CriarAluno(nome);
Listagem 7. Mtodo construtor removido.
2. {
3. ...
4.
5.
public Alunos()
{
6.
7. public static Alunos CriarAluno(String nome)

8. {
9.
10.
UInt16 Matricula = Convert.ToUInt16(matricula.
Next(0, UInt16.MaxValue));
11.
return new Alunos(nome, Matricula, DateTime.Today,0);
12. }
13.
14.
15.
16.
17.
18.
44

{
this.Nome = nome;
this.Idade = idade;
}
...
16.
17.
18.
19.
20.
21.
22.
23.
24.
25. }
pode ser muito custoso. Uma variao desta refatorao permite que apenas alguns construtores sejam removidos, dando
lugar a novos mtodos de criao.
Concluso
Fica evidente os benefcios que a utilizao das tcnicas de
refatorao para padres proporcionam. O cdigo fonte da
aplicao passa a ter padres de projetos implementados, sendo
inseridos de forma controlada, pois as refatoraes para padres
mostram como o processo deve ser feito com vrios pequenos
passos sequenciais. Cabe ao desenvolvedor ter o conhecimento
sobre as tcnicas de refatorao para padres e sobre os padres
que elas contemplam, alm do conhecimento sobre o funcionamento do cdigo que est sendo refatorado.
Referncias Bibliogrficas
1. FREEMAN, Eric e Elisabeth, 2007. Use a Cabea! Padres de Projeto, 2ed. Rio de Janeiro: Alta
Books, 2007.
2. GAMMA, Erich, 2000. Padres de Projeto: solues reutilizveis de software orientado a
objetos, 1ed. Porto Alegre: Bookman, 2000.
3. KERIEVSKY, Joshua. Refatorao para Padres, 1ed. Porto Alegre: Bookman, 2008.

Feedback
eu
sobre e
s
19.
20.
21.
22.
23.
24.
public Alunos(String nome, DateTime dataNascimento)

{
this.Nome = nome;
this.Idade = Convert.ToUInt32(DateTime.Today.Year) Convert.ToUInt32(dataNascimento.Year);
}
14.
15.
D
s
public Alunos(String nome, DateTime dataNascimento)

{
this.Nome = nome;
this.Idade = Convert.ToUInt32(DateTime.Today.Year) - Convert.
ToUInt32(dataNascimento.Year);
}
11.
12.
13.
edio
ta
22.
}
public Alunos(String nome)
{
this.Nome = nome;
this.Matricula = Convert.ToUInt16(matricula.Next(0, UInt16.MaxValue));
}
public static Alunos CriarAluno(String nome)
{
return new Alunos(nome);
}
desenvolvimento
45
Desenvolvimento
Nesta seo voc encontra artigos voltados para diferentes
abordagens de apoio ao desenvolvimento de projetos de software
Reuso de Software utilizando Padres de

Anlise
O uso de padres de anlise na modelagem de sistemas de informao
Este artigo aborda a importncia da reutilizao
de software por meio de padres de software,
especificamente, padres de anlise. O artigo
apresenta conceitos e a relevncia da reutilizao de software, descrevendo vantagens e
desvantagens sobre o tema.
Evaldo de Oliveira da Silva

evaldo@cesjf.br
Possui mestrado e especializao em Cincia da Computao pela Universidade Federal de Viosa. Atualmente professor do
curso de Bacharelado em Sistemas de Informao do Centro de Ensino Superior de
Juiz de Fora (CES/JF) e do Curso Superior de
Tecnologia em Anlise e Desenvolvimento
de Sistemas da Fundao Educacional D.
Andr Arcoverde (FAA).
Jugurta Lisboa Filho

jugurta@dpi.ufv.br
Doutor em Cincia da Computao pela

UFRGS. Atualmente Professor Associado
no Departamento de Informtica da Universidade Federal de Viosa. Professor orientador no Programa de Ps-Graduao em
Cincia da Computao da UFV. Tem como
reas de interesse Modelagem de Banco de
Dados e Sistemas de Informao Geogrfica.
Sua pesquisa financiada parcialmente pela
FAPEMIG e CNPq/MCT/CT-Info.
46
reuso de software visa reaproveitar grande parte do software

produzido e informaes associadas em novos projetos, diminuindo
o custo, aumentando a produtividade
no desenvolvimento e proporcionando
o compartilhamento do conhecimento
durante as fases de desenvolvimento.
A ideia bsica que componentes de
software sejam especificados e projetados de forma que possam ser reusados
em aplicaes diferentes. Antigamente, a
idia era construir bibliotecas de cdigos
com o objetivo de serem reutilizados em
aplicaes cientficas e de reengenharia
sendo, portanto, de um domnio de
aplicao limitado. Os geradores de aplicao ou geradores de cdigo tambm
surgiram com o objetivo de facilitar a
criao de aplicaes a partir de sua
Engenharia de Software Magazine - Reuso de Software utilizando Padres de Anlise
Para que serve?

Os padres de anlise so teis para reutilizao
do conhecimento durante a modelagem conceitual de sistemas de informao.

Reutilizao de software por meio de padres
de software. Especificamente, discute a reutilizao na modelagem conceitual de sistemas de
informao.
especificao em uma linguagem de alto

nvel. Tais geradores representavam a
preocupao com o reuso nos diferentes
nveis do processo de desenvolvimento
de software, apesar de ficarem limitados
a poucos domnios de aplicao.
Existem vrios motivos para adotar
mecanismos para reutilizao de software. Uma das grandes motivaes
pro jeto
est na necessidade de aumento de produtividade, manutenibilidade e qualidade tanto do software quanto de seu
processo de desenvolvimento. O ganho na produtividade se
relaciona reduo da quantidade de cdigo a ser programada, testada e documentada, diminuindo tambm o custo do
produto. A capacidade de manter a aplicao melhorada,
pois o entendimento do sistema como um todo fica mais fcil,
j que componentes projetados para reuso tambm possuem
funes bem definidas e os desenvolvedores tornam-se mais
familiarizados com os cdigos reutilizados. A qualidade de
um software projetado para reuso, em geral, tambm maior
do que a de um software desenvolvido sem este propsito,
pois normalmente h um investimento maior no projeto,
documentao e testes.
Neste contexto, o cdigo ou qualquer outro artefato de
software reusvel deve ser catalogado para que possa ser
facilmente consultado, padronizado a fim de facilitar sua
implementao, e a integrao nova aplicao seja facilitada. Assim, o processo de identificao do componente a ser
reutilizado deve ser conhecido por meio de repositrio que
permita catalog-los. Alm disso, a gerncia de configurao
dos componentes armazenados deve permitir que as mudanas
e a evoluo destes componentes sejam controladas.
Porm, existem fatores que desmotivam o reuso. O custo
para construo de componentes de software maior, pois
necessrio investir mais no planejamento, documentao e
testes. Outro problema a ineficincia dos componentes, que
ocorre quando se tenta fazer componentes mais genricos para
servir a uma gama maior de reutilizadores.
Para conseguir sucesso na utilizao de componentes reusveis de software, a equipe de desenvolvimento deve ter atitude,
ferramentas e tcnicas apropriadas. A atitude envolve a conscientizao da equipe da necessidade de reuso. Muitas vezes,
por falta de padronizao ou comodidade, os desenvolvedores
preferem desenvolver um componente novamente. Ferramentas de auxlio ao reuso so fundamentais, pois podem auxiliar
na busca, armazenagem e recuperao dos componentes.
Como foi mencionado anteriormente, a reutilizao de software tambm pesquisada e incentivada em diversas etapas
do desenvolvimento e manuteno de software. Portanto, no
existe somente o reuso de software por meio de cdigo ou componentes gerados na fase de projeto da aplicao. possvel
citar outras classes de padres de software que abrangem diferentes nveis de abstrao, a fim de facilitar sua reutilizao.
Dependendo da fase ou nvel da construo de um sistema de
informao, os padres de software podem ser classificados
como padres de processo, padres arquiteturais, padres de
anlise, padres de projeto, padres de interface, padres de
programao, padres de persistncia, anti-padres. A descrio de cada classe de padro de software melhor detalhada
no artigo Catalogao de Padres publicado na edio 23 da
Engenharia de Software Magazine.
O desenvolvimento de software orientado a objetos traz
consigo grande motivao e foco no reuso de software. A
maioria das classes de padres mencionadas so especificadas
com base na orientao a objetos. Os padres de software tm

sido estudados h vrios anos como uma forma promissora de
reuso, no somente de cdigo mas tambm de projeto, anlise,
arquitetura e processo de desenvolvimento. A reutilizao por
meio de padres pode documentar solues para diferentes
tipos de problemas que ocorrem ao longo do processo de desenvolvimento de software. Tais solues podem ser reusadas por
outros desenvolvedores quando se depararem com problemas
similares em quaisquer que sejam seus nveis de abstrao.
De acordo com Fowler (1997), um padro definido como:
uma ideia que tem sido utilizada em um contexto prtico e
provavelmente ser til em outros contextos.
Assim, padres de software podem ser reutilizados em diferentes nveis de abstrao no desenvolvimento de sistemas
orientados a objetos. O uso de padres proporciona um vocabulrio comum para a comunicao entre projetistas, criando
abstraes num nvel superior ao de classes e garantindo
uniformidade na estrutura do software. Outro mecanismo
amplamente aplicado na reutilizao de software so os frameworks, que sero abordados posteriormente.
Nesse contexto, este artigo aborda especificamente o uso de
padres de anlise na reutilizao de esquemas conceituais
durante a modelagem conceitual de sistemas de informao.
Frameworks
Framework definido como um arcabouo contendo classes,
objetos e relacionamentos agrupados para construir aplicaes
especficas. Um framework pode ser reutilizado por meio de
suas classes e relacionamentos, as quais possibilitam adaptarse a um domnio especfico de aplicao.
Assim, um framework um conjunto de classes abstratas e
concretas que prov uma infra-estrutura genrica de solues
para um conjunto de problemas. Tais classes fazem parte de
uma biblioteca de classes ou podem ser especficas da aplicao. Alm disso, frameworks possibilitam reutilizar no s
componentes isolados, mas tambm toda a arquitetura de um
domnio especfico. Ou seja, um framework serve como instrumento de reutilizao e no precisa ser implementado em uma
linguagem de programao para solucionar o problema.
Existem tambm frameworks conceituais, os quais permitem
especificar classes de um determinado domnio de aplicao,
que podem ser reutilizadas na fase de anlise de sistemas.
Como exemplo de framework conceitual, temos o UML-GeoFrame, utilizado na modelagem conceitual de Sistemas de
Informaes Geogrficas (SIG). O UML-GeoFrame um framework conceitual que fornece um diagrama de classes bsicas
para auxiliar o projetista nos primeiros passos da modelagem
conceitual de dados de uma nova aplicao de SIG.
O UML-GeoFrame foi desenvolvido para ser genrico o
bastante para expressar a ideia de um projeto conceitual para
vrias aplicaes geogrficas. Ele foi definido de acordo com
as regras do formalismo de orientao a objetos, utilizando
a notao grfica do diagrama de classes da linguagem
UML. Alm disso, este framework representa suas classes e
relacionamentos de objetos espaciais atravs de esteretipos
47
(Figura 1). Esteretipos permitem estender o uso

de um diagrama de classes baseado em notaes
j existentes, a fim de resolver alguma deficincia
no modelo de classes. Os tipos de esteretipos
existentes no GeoFrame so de generalizao e
associao. O esteretipo de generalizao serve
para representar objetos das trs principais classes do GeoFrame, que so OBJETOS_NO_GEOGRFICOS, CAMPOS_GEOGRFICOS e
OBJETOS_GEOGRFICOS, consideradas classes
de domnio no diagrama. O esteretipo de associao serve para substituir relacionamentos de
objetos representados como fenmenos geogrficos, objetos que tenham representao espacial
e forma geomtrica.
Figura 1. Esteretipos do UML-GeoFrame
Padres de Anlise
Um padro de anlise definido como um esquema que reutilizado em um domnio especfico para modelagem conceitual de sistemas de
informao, sendo uma combinao recorrente
Figura 2. Padro Contrato
de conceitos que ocorre em um mesmo contexto.
Esta abordagem produz uma arquitetura de software que
mais flexvel e reutilizvel, comparada a outras abordagens
que tratam da descoberta e reuso de padres de anlise.
O reuso de padres de anlise proposto em outros domnios
de aplicao como, por exemplo, na modelagem conceitual
de sistemas de informao para comrcio eletrnico e para
gesto empresarial.
Monteiro (2002) apresenta a reutilizao de padres de anlise
no desenvolvimento de aplicaes para Web, apresentando
a definio de padres identificados a partir da anlise de
domnio de diversas aplicaes de comrcio eletrnico disponibilizados na Internet. Os padres identificados podem ser
teis no desenvolvimento de novas aplicaes, permitindo
maior produtividade e qualidade, diminuindo o custo e o
tempo dos projetistas na fase de levantamento de requisitos
de aplicaes de comrcio eletrnico.
As prximas sees discutem padres de anlise que podem
Figura 3. Padro Parte
ser reutilizados no contexto de aplicaes comerciais e aplicaes de comrcio eletrnico.
por exemplo, ao projetista de sistemas modelar endereos e
nmeros de telefones de departamentos de suas filiais e at
Padro Contrato
mesmo reutilizar esse mesmo esquema para os membros das
O padro Contrato (Figura 2) representa um contrato que
equipes de trabalhos (ver Figura 3).
feito entre Partes (contratante e contratada). A classe Contrato
representa uma negociao que pode ser uma compra ou venPadro para Aplicaes de Comrcio Eletrnico na Web
da de algum instrumento, que neste caso pode ser entendido
Monteiro (2002) prope um conjunto de padres de anlise
como um bem ou servio.
identificados em diversas aplicaes de comrcio eletrnico
Esse padro pode ser reutilizado em diversos domnios de
disponibilizadas na Internet. O autor realizou a anlise de doaplicao, como por exemplo, aluguel de veculos, imobilirias
mnio de diversos sites de comrcio eletrnico e apresentou os
ou terceirizao de servios diversos.
padres citados neste artigo. Tais padres podem ser teis no
desenvolvimento de novas aplicaes, uma vez que, iniciando
Padro Parte
a anlise de requisitos de um sistema com um conjunto bsico
O padro parte foi apresentado por Fowler (1997), que define
de requisitos j bem definidos e modelados, pode-se ganhar
a parte sendo uma pessoa ou organizao. Isto possibilita,
em produtividade e qualidade, diminuindo custos.
48
pro jeto
Figura 4. Padro Lista de Presentes
Ainda de acordo com o autor, apesar dos padres de anlise terem sido propostos para modelagem de aplicaes
de comrcio eletrnico na Web, alguns deles podem ser
aplicados a outros domnios. Os padres propostos por
Monteiro so: Dados de Clientes; Endereos de Clientes;
Perfil de Clientes; Lista de Presentes; Dados de Produtos;
Especializaes de Produtos; Pedidos; Pagamentos de
Pedidos.
Este artigo descreve o padro Lista de Presentes, sendo
uma caracterstica encontrada em diversas lojas, como na
Submarino, Amazon.com, Livraria Cultura e Ponto Frio.
A proposta para a modelagem dessa caracterstica dada
na Figura 4.
Apesar de possuir nomes diferentes, a estrutura dessas
listas praticamente a mesma. Por exemplo, no Amazon.
com chamada de Wish List, cuja traduo poderia ser
Lista de Desejos. J o Ponto Frio possui a possibilidade de
criar listas de presentes, no entanto com o nome de Lista
de Casamento, devido ao objetivo proposto pela loja para
o cadastro dessa lista. O esquema da Figura 4 abrange essa
possibilidade, uma vez que uma lista de casamentos um
caso particular de uma lista de presentes.
Diante do padro de anlise apresentado acima, uma
lista de presentes pode ser pblica ou privada. Uma lista
pblica aquela que visvel por qualquer usurio do site

e no apenas pelo proprietrio da lista, em contraposio a
uma lista privada que visvel apenas para o proprietrio
da lista. Esse requisito expresso pelo atributo IndicativoPublicoPrivado da classe Lista de Presentes.
O atributo IndicativoListaPadro define a lista corrente
para receber os itens que o cliente pede para incluir na lista
de presentes enquanto continua efetuando a compra. Esse
requisito foi analisado a partir da loja virtual Submarino,
que permite a criao de mais de uma lista de presentes
associada a um cliente, da mesma forma como foi modelado
neste artigo.
A quantidade desejada de um determinado item na lista
expressa o desejo ou a necessidade do cliente de possuir
aquela quantidade de unidades daquele item. Essa uma
caracterstica contida no Submarino e no Amazon.com e
expressa pelo atributo Quantidade desejada da classe
Item de Lista de Presentes. Os atributos Quantidade j
adquirida e Comentrio foram extrados do Amazon.com
e permitem informar ao usurio que est consultando a lista,
respectivamente, a quantidade de um determinado item que
j foi adquirida para o cliente proprietrio daquela lista e o
motivo ou qualquer observao feita pelo cliente a respeito
do item includo na lista. O atributo Status, por sua vez,
49

Feedback
eu
Referncias
1.APPLETON, B.Patterns and Software: Essential Concepts and Terminology, 2000.Disponvel em <http://
www.cmcrossroads.com/ bradapp/docs/patterns-intro.html > Acesso em: 20 de janeiro de 2008.
2. BORGES, K. A. V. A Gesto Urbana e as Tecnologias de Informao e Comunicao. Informtica
Pblica, v. 2, p. 17-24, 2002.
3. BRAGA, R., T., V., GERMANO, F., S., R., MASIERO, P., C., MALDONADO, J., C.
4. Introduo aos Padres de Software. Disponvel em : www.icmc.usp.br/~rtvb/apostila.pdf.
Acesso em 30 de setembro de 2009.
5. COPLIEN, J. O.. Software Patterns, SIGS Books & Multimedia, USA, 1996.
6. CORFMAN, R. An Overview of Patterns. In: Rising L. (Org.). The Patterns Handbook: Techniques,
Strategies, and Applications. UK: Cambridge University Press, 1998.
7. DEVEDZIC, V. Software Patterns, In: CHANG, S.K. (Org.), Handbook of Software Engineering and
Knowledge Engineering. v. 2. Singapore: World Scientific Publishing Co, 2002. p. 645-671.
8. FERNANDEZ, E.B. Building systems using analysis patterns. In: International Software Architecture
Workshop (ISAW3), 1998. Orlando, Proceedings Orlando: ACM Press, 1998.
13. LISBOA FILHO, J.; IOCHPE, C. Specifying analysis patterns for geographic databases on the basis
of a conceptual framework. In: 7th ACM Symposium on Advances in Geographic Information
Systems, 1999. Proceedings. Kansas City : ACM, 1999.
14. LISBOA FILHO, J. ; IOCHPE, C. ; BORGES, Karla A V . Analysis patterns for GIS data schema reuse on
urban management applications. Clei Eletronic Journal, on-line, 2002. v. 5, no 2. p. 1-15.
15. LISBOA FILHO, J.; SODR, V. F.; DALTIO, J.; RODRIGUES JNIOR, M. F.; VILELA, V. M. A CASE tool
for geographic database design supporting analysis patterns. In: ER2004/CoMoGIS - Workshop on
Conceptual Modeling for GIS. CONCEPTUAL MODELING FOR ADVANCED APPLICATION DOMAINS.
Berlin : Springer LNCS, 2004. v. 3289. p. 43-54.
16. MARINHO, F. G.; ANDRADE, R. M. C. Uma Proposta de um Repositrio de Padres de Software
Integrado ao RUP. In: SugarloafPLoP. Recife : CiN - UFPE, 2003. v. 3. p. 277-290.
17. MESZAROS, G., DOBLE, J., A Pattern Language for Pattern Writing, in R. Martin, et al., Pattern
Languages of Program Design 3, Addison Wesley, 1998.
18. MONTEIRO, A. J. B. Padres de Anlise em Aplicaes de Comrcio Eletrnico na Web. 2002. 145 f..
Dissertao de Mestrado em Cincia da Computao, Universidade Federal de Minas Gerais, 2002.
9. FOWLER M.. Analysis Patterns: Reusable Object Patterns, Addison-Wesley, 1997
19. PRESSMAN, R.S. Engenharia de software. Traduo: Rosngela Delloso Penteado. 6.ed. So
Paulo: McGraw-Hill, 2006.
10. GAMMA, E.; HELM, R.; JOHNSON, R.; VLISSIDES, J.. Padres de Projeto: Solues Reutilizveis de
Software Orientado a Objetos.Traduo de Luiz A. Meirelles Salgado. Porto Alegre: Bookman, 2000.
20. SILVA, E. O., LISBOA FILHO, J. Catalogao de Padres. Revista Engenharia de Software, ed 23,
Editora DevMedia: Rio de Janeiro, 2010.
11. GAZOLA, A.; LISBOA FILHO, J. ; ANDRADE, M.V.A. O Catlogo de Padres de Anlise da Ferramenta
ArgoCASEGEO. In: Congreso Latinoamericano de Informtica, 2006. Anais. Santiago : CLEI, 2006. p. 1-10.
21. WERNER, C. M. L. ; BRAGA, R. M. M. ; ROSETTI, M. Z. ; BARROS, M. O. ; MURTA, L. G. P. . Odyssey-LE:

Uma Infra-Estrutura de Reutilizao para o Domnio do Processamento Legislativo. In: Encontro
Nacional de Informtica Aplicada ao Legislativo (ENIAL), Vitria, 2000.
12. GEYER-SCHULZ, A.; HASLER, M. Software Engineering with Analysis Patterns. Technical Report
01/2001, Institut fr Informationsverabeitung und Informationswirtschaft Wirtschaftsuniversitt
Wien Augasse 2-6 1090 Wien. Disponvel em <http://michael.hahsler.net/research/virlib_
working2001/virlib/> Acesso em: 01 de maro de 2007.
50
sobre e
s
Este artigo abordou a importncia da reutilizao de software

por meio de padres de software, especificamente, padres de
anlise. Discutiu tambm a importncia de se adotar padres
durante as fases de desenvolvimento de software visando contribuir para o compartilhamento do conhecimento, aumento de
produtividade e diminuio do custo de produtos de software.
Descreveu ainda alguns padres de anlise que modelam
conceitos de domnios de aplicaes diferentes.
D
s
Concluso
importante ressaltar que um padro de anlise modela

parte de um domnio de aplicao, permitindo ser um mecanismo que descreve de forma genrica esquemas conceituais
que podem auxiliar projetistas reutilizarem o conhecimento
embutido no padro.
edio
ta
permite informar a situao do item contido na lista como, por

exemplo, se o mesmo j foi recebido ou no pelo cliente, ou se
j foi comprado e est ainda no processo de liberao.
pro jeto
51
52

Edição28 2010

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Edição28 2010

Diunggah oleh

Hak Cipta:

Format Tersedia

Modstia parte, sua

melhor opo para

EDUCAO SUPERIOR ORIENTADA AO MERCADO

anuteno significa um conjunto de modificaes realizadas no software

Fale com o Editor!

Rodrigo Oliveira Spnola

Marco Antnio Pereira Arajo

Eduardo Oliveira Spnola

19 - O Papel Evolutivo do Software

46 - Reuso de Software utilizando Padres de Anlise

Edio 05 - Engenharia de Software Magazine

Pos trs do bvio

H um colega chato em seu

Engenharia de Software - H um colega chato em seu local de trabalho?

H algo a ser aprendido com todos esses tipos? A resposta sim.

D seu feedback sobre esta edio!

como um vampiro ensandecido. So pessoas frustradas, que no

o adianta mudar de departamento nem se transferir

De que se trata o artigo?

Para que serve?

analista de sistemas e analista de testes.

este artigo vamos abordar como

de software uma atividade complexa, envolvendo

Em que situao o tema til?

gestores quanto adoo dessa cultura,

Edio 28 - Engenharia de Software Magazine

constante para clientes do sistema (stakeholders), gerentes

Engenharia de Software Magazine - Negociao de Contratos

Entretanto, metodologias como eXtreme Programming,

Agile Project Management (APM)

eXtreme Programming (XP)

funcionam como guias que ajudam a adaptar as prticas

Edio 28 - Engenharia de Software Magazine

Feature Driven Development

Engenharia de Software Magazine - Negociao de Contratos

Fornece uma forma de saber, dentro dos primeiros 10% de

Adaptive Software Development

Viso da Metodologia gil

Quando um edifcio construdo necessrio

1. Qual o contexto do projeto?

A atividade de escrever os elementos de software

Edio 28 - Engenharia de Software Magazine

ganhar agilidade na captura de requisitos. Porm, algumas

Engenharia de Software Magazine - Negociao de Contratos

o Manifesto de Desenvolvimento gil de Software. Este

Mudana de Comportamento dos Gerentes

Atravs deste artigo, podemos ter uma viso geral sobre

D seu feedback sobre esta edio!

Edio 28 - Engenharia de Software Magazine

Diferentes opes de trabalho

das metodologias geis em suas equipes, pois ele ter um

no oramento, prevendo uma eventual falha no planejamento

Requisitos em SOA Parte 1

De que se trata o artigo?

Possui mestrado em Cincias da Computao e Matemtica Computacional pela

Engenharia de Software Magazine - Requisitos em SOA Parte 1

Para que serve?

Em que situao o tema til?

Por exemplo, no se pode evitar o fator

bom analista de requisitos deve envolver os stakeholders no

Por onde comear?

uma s vez. Essa uma estratgia que traz srios problemas

Identificao dos servios