Revista Engenharia de Software - Nr14

Conhecimento
faz diferena!
Capa ESM - Final .pdf
19.02.08
18:15:13
magazine
Engenharia de Software
Saiba seu significado e para que serve

Edio Especial
Entenda os principais conceitos sobre

Testes e Inspeo de Software
Verificao, Validao & Teste
Ferramentas Open Source e melhores
prticas na gesto de defeitos
Requisitos
Conhea os principais conceitos envolvidos

na Engenharia de Requisitos
Especial
Projeto
Entenda o conceito de Arquitetura de Software e

como trabalhar com os Estilos Arquiteturais
Processos
Melhore seus processos atravs da

anlise de risco e conformidade
Veja como integrar conceitos de

Modelos Tradicionais e geis
Veja como integrar o Processo

Unificado ao desenvolvimento Web
Mais de 60 mil downloads

na primeira edio!
Faa j sua assinatura digital! | www.devmedia.com.br/es

Faa um up grade em sua carreira.
Em um mercado cada vez mais focado em qualidade ter conhecimentos aprofundados sobre requisitos, metodologia, anlises,
testes, entre outros, pode ser a diferena entre conquistar ou no uma boa posio profissional. Sabendo disso a DevMedia
lana para os desenvolvedores brasileiros sua primeira revista digital totalmente especializada em Engenharia de Software.
Todos os meses voc ir encontrar artigos sobre Metodologias Ageis; Metodologias tradicionais (document driven);
ALM (application lifecycle management); SOA (aplicaes orientadas a servicos); Analise de sistemas; modelagem; Mtricas;
orientao objetos; UML; testes e muito mais. Assine j!
EDITORIAL
Ano 2 - 14 Edio 2009
Impresso no Brasil
Corpo Editorial
Colaboradores
Rodrigo Oliveira Spnola
rodrigo@sqlmagazine.com.br
Marco Antnio Pereira Arajo
Eduardo Oliveira Spnola
Diagramao
Gabriela de Freitas - gabrieladefreitas@gmail.com
Capa
Romulo Araujo - romulo@devmedia.com.br
Na Web
www.devmedia.com.br/esmag
Apoio
Parceiros:
A melhoria de processos algo que sempre procuramos, afinal, clara

a necessidade de aperfeioamento constante nos diferentes projetos
em que trabalhamos. Infelizmente, no existe uma receita de bolo ou
conjunto de passos pr-definidos que precisamos seguir para ter sucesso em uma caminhada ruma melhoria da forma como desenvolvemos software.
Neste contexto, a Engenharia de Software Magazine destaca nesta edio duas matrias muito interessantes que abordam o tema sob duas
perspectivas distintas: abordagens geis e abordagens tradicionais.
Implantao de Processo - Os desafios da implantao de um processo de software: neste artigo veremos quais so os principais desafios
e benefcios da implantao de um processo de desenvolvimento de
software. Sero descritos aspectos importantes do processo que foi
definido, bem como as ferramentas que foram desenvolvidas para dar
suporte sua implantao.
Melhoria de Processo de Software no Desenvolvimento gil: a procura pelo conhecimento e aplicao de metodologias geis vem aumentando. Desta forma, este artigo tem a finalidade de prover (i) um
melhor entendimento de como e quando realizar um processo MPS; e
(ii) apresentar etapas a serem seguidas e resultados esperados tratados atravs do uso de tcnicas utilizadas nas metodologias geis para
iniciativas de MPS.
Alm destas matrias, esta edio traz mais seis artigos:
Gerncia de Configurao: Definies Iniciais;
Mudanas no PMBoK 4 Edio;
Gerenciamento de Mudanas em Projetos de TI;
Ontologias: Filosofia aplicada Engenharia de Software?;
Ciclo de Vida da Gesto em Arquitetura de Software;
Anlise da Arquitetura de Software.
Desejamos uma tima leitura!
Equipe Editorial Engenharia de Software Magazine
Rodrigo Oliveira Spnola
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:
(rodrigo@sqlmagazine.com.br)
Doutorando em Engenharia de Sistemas e Computao (COPPE/UFRJ). Mestre em
Engenharia de Software (COPPE/UFRJ, 2004). Bacharel em Cincias da Computao
(UNIFACS, 2001). Colaborador da Kali Software (www.kalisoftware.com), tendo
ministrado cursos na rea de Qualidade de Produtos e Processos de Software,
Requisitos e Desenvolvimento Orientado a Objetos. Consultor para implementao
do MPS.BR. Atua como Gerente de Projeto e Analista de Requisitos em projetos de
consultoria na COPPE/UFRJ. Colaborador da Engenharia de Software Magazine.
Deise Aleis Atendimento ao Leitor

www.devmedia.com.br/central/default.asp
(21) 2220-5375
Kaline Dolabella
Gerente de Marketing e Atendimento
kalined@terra.com.br
(21) 2220-5375
Publicidade
Para informaes sobre veiculao de anncio na revista ou no site entre em
contato com:
Kaline Dolabella
publicidade@devmedia.com.br
Fale com o Editor!

muito importante para a equipe saber o que voc est achando da revista: que tipo de artigo

(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.
voc gostaria de ler, que artigo voc mais gostou e qual artigo voc menos gostou. Fique a
vontade para entrar em contato com os editores e dar a sua sugesto!
Se voc estiver interessado em publicar um artigo na revista ou no site SQL Magazine,
entre em contato com os editores, informando o ttulo e mini-resumo do tema que voc
gostaria de publicar:
Rodrigo Oliveira Spnola - Colaborador
editor@sqlmagazine.com.br
Eduardo Oliveira Spnola

(eduspinola@gmail.com)
Editor das revistas Engenharia de Software Magazine, SQL Magazine, WebMobile.
bacharel em Cincias da Computao pela Universidade Salvador (UNIFACS) onde
atualmente cursa o mestrado em Sistemas e Computao na linha de Engenharia de
Software, sendo membro do GESA (Grupo de Engenharia de Software e Aplicaes).
Caro Leitor,
Para esta edio, temos um conjunto de 3 vdeo aulas. Estas vdeo aulas esto disponveis para download no
Portal da Engenharia de Software Magazine e certamente traro uma significativa contribuio para seu aprendizado. A lista de aulas publicadas pode ser vista abaixo:
Tipo: Engenharia de Requisitos

Ttulo: Concretas para Problemas Prticos da Engenharia de Requisitos Parte 4
Autor: Rodrigo Oliveira Spnola
Mini-Resumo: Existem diferentes maneiras de estruturar um processo com atividades
relacionadas engenharia de requisitos em empresas desenvolvedoras de software.
Modelos de maturidade, como o MPS, podem servir como um arcabouo para a definio deste processo. Alm disso, fundamental para um processo de engenharia de
requisitos que ele seja capaz de lidar com dificuldades e problemas relacionados a
requisitos que possam surgir durante o desenvolvimento de software na prtica. Uma
iniciativa rumo ao levantamento destas dificuldades e problemas e de maneiras de
estruturar um processo para lidar com estes problemas ser apresentada nesta srie
de vdeo aulas. Nesta quarta aula, sero apresentados dois problemas prticas e duas
solues concretas associadas atividade de anlise e negociao de requisitos.
Ttulo: Solues Concretas para Problemas Prticos da Engenharia de Requisitos Parte 5
Mini-Resumo: Existem diferentes maneiras de estruturar um processo com atividades
relacionadas engenharia de requisitos em empresas desenvolvedoras de software.
Modelos de maturidade, como o MPS, podem servir como um arcabouo para a definio
deste processo. Alm disso, fundamental para um processo de engenharia de requisitos

que ele seja capaz de lidar com dificuldades e problemas relacionados a requisitos que
possam surgir durante o desenvolvimento de software na prtica. Uma iniciativa rumo ao
levantamento destas dificuldades e problemas e de maneiras de estruturar um processo
para lidar com estes problemas ser apresentada nesta srie de vdeo aulas. Nesta quinta
aula, sero apresentados dois problemas prticas e duas solues concretas associadas
atividade de documentao de requisitos.
Ttulo: Concretas para Problemas Prticos da Engenharia de Requisitos Parte 6
Mini-Resumo: Existem diferentes maneiras de estruturar um processo com atividades relacionadas engenharia de requisitos em empresas desenvolvedoras de software. Modelos de
maturidade,como o MPS,podem servir como um arcabouo para a definio deste processo.Alm
disso, fundamental para um processo de engenharia de requisitos que ele seja capaz de lidar com
dificuldades e problemas relacionados a requisitos que possam surgir durante o desenvolvimento
de software na prtica. Uma iniciativa rumo ao levantamento destas dificuldades e problemas e
de maneiras de estruturar um processo para lidar com estes problemas ser apresentada nesta
srie de vdeo aulas. Nesta sexta aula, sero apresentados mais dois problemas prticas e duas
solues concretas associadas atividade de documentao de requisitos.
NDICE
08 - Melhoria de Processo de Software no Desenvolvimento gil
Clio Santana e Cristine Gusmo
14 - Implantao de Processo
Edite Martins
20 - Gerncia de Configurao
Thas Miranda Cia
26 - Mudanas no PMBoK 4 Edio

Paulo Augusto Oyamada Tamaki
30 - Gerenciamento de Mudanas em Projetos de TI

Felipe La Rocca Teixeira e Marco Antnio Pereira Arajo
40 - Ciclo de Vida da Gesto em Arquitetura de Software

Eros Viggiano e Marco Aurlio S. Mendes
50 - Anlise da Arquitetura de Software

Antonio Mendes da Silva Filho
58 - Ontologias
Monalessa Perini Barcellos
Engenharia de Software Magazine
6 SQL Magazine
Edio 05 - Engenharia de Software Magazine
Melhoria de Processo de Software no

Desenvolvimento gil
De que se trata o artigo?
Este artigo apresenta o conceito de melhoria de
processo de software e sua aplicao em aplicaes
que utilizam abordagens de metodologias geis.
Para que serve?

Clio Santana
Celio.santana@scrum.org.br
Professor Assistente das Faculdades Integradas

Barros Melo e do Grupo Universitrio Maurcio
de Nassau. Mestre em Engenharia da Computao pela Universidade de Pernambuco e Ps
Graduado em Melhoria de Processo de Software pela Universidade Federal de Lavras (UFLA).
Graduado em Cincia da Computao pela Universidade Federal de Pernambuco. Certified
Scrum-Master (CSM), Certified Product-Owner
(CSPO) bem como Implementador do Modelo
de Melhoria de Processos do Software Brasileiro
MPS.Br (P2 MPS.Br)
Cristine Gusmo
cristine@dsc.upe.br
Professora Assistente do Departamento de

Sistemas e Computao da Escola Politcnica
da Universidade de Pernambuco (POLI - UPE),
onde leciona vrias disciplinas na graduao e
ps-graduao (especializao e mestrado) e
das Faculdades Integradas Barros Melo. Doutora e Mestre em Cincia da Computao pela
Universidade Federal de Pernambuco. Graduada em Engenharia Eltrica - Eletrotcnica pela
Universidade Federal de Pernambuco.
surgimento das metodologias

geis foi de fato um importante
marco na indstria do desenvolvimento de software. Algumas definies, disponveis na literatura [Schuh
2004; Mnkandla & Dwolatzky 2004],
tratam o tema como algo revolucionrio,
sendo considerada uma nova disciplina
de engenharia que modificava os valores do processo de desenvolvimento
de software do mecnico (orientado a
processos e utilizando regras da cincia)
para o orgnico (dirigido por questes
sobre pessoas e suas interaes).
De uma forma geral, a apresentao
destas metodologias trouxe mudanas
culturais em vrios aspectos no desenvolvimento de software, a exemplo da
proposio de tcnicas e procedimentos,
at a contribuio na realizao da Melhoria de Processo de Software (MPS).
Engenharia de Software Magazine - Melhoria de Processo de Software no Desenvolvimento gil
Serve como fonte de exemplos de aplicaes da

utilizao de Melhoria de Processo de Software
(MPS) em ambientes geis e entender sua diferena em relao ao MPS tradicional.
Em que situao o tema til?

A procura pelo conhecimento e aplicao de metodologias geis vem aumentando. Desta forma, este
artigo tem a finalidade de prover (i) um melhor entendimento de como e quando realizar um processo MPS;
e (ii) apresentar etapas a serem seguidas e resultados
esperados tratados atravs do uso de tcnicas utilizadas nas metodologias geis para iniciativas de MPS.
Baseado nesse contexto de mudana

cultural, uma nova forma para a realizao da Melhoria de Processo de Software
era necessria sem que fosse tirado o
foco do orgnico, valorizando ainda
mais as pessoas e suas competncias.
Neste artigo ser mostrado como proposto o MPS nas metodologias geis e
sua diferena do MPS tradicional.
M etodologias geis
Histrico
Para melhor entendermos o contexto do MPS em ambientes
tradicionais, devemos entender o que aconteceu com o rumo
que a Qualidade de Software tomou a partir daquela reunio
da OTAN em 1968 onde o termo Engenharia de Software
foi utilizado pela primeira vez por F. L. Bauer.
Naquela reunio foi utilizado tambm o termo Crise do
Software para definir a situao em que a indstria do software atravessava naquele momento. E a crise foi atribuda
complexidade de desenvolver sistemas cada vez maiores, bem
como falta de gerenciamento no processo de desenvolvimento
de software.
A partir da, engenheiros de software tentaram imitar a
engenharia convencional, para resolver problemas de qualidade e falhas em sistemas de informao. Uma quantidade
significativa de experincia foi obtida atravs de processos de
garantia da qualidade praticados na indstria de manufatura
e essa adaptao para a indstria de software foi, em alguns
casos, um fracasso e, em outros, um sucesso, como, por exemplo, a utilizao de controle estatstico de processo (base do
Six Sigma) para avaliao de processos de software.
Ainda no fim da dcada de 1980, o controle de qualidade
existente na indstria de software era centrado no produto
final e com utilizao de mtodos corretivos em inspees no
fim da linha de produo, e se mostrava pouco efetivo para a
soluo de problemas gerenciais como prazos e custos.
No incio da dcada de 1990, o mercado substitua aquele
controle de qualidade pela Garantia da Qualidade com um
foco centrado no processo e que utilizava auditorias durante
todo o ciclo de vida de desenvolvimento. A partir da, foram
surgindo normas (ISO 9000-3, ISO 15504, ISO 12207), padres
(IEEE 1074, IEEE 1298) e Modelos (SW-CMM, CMMI) para
Qualidade de Software.
A partir da comearam a surgir os modelos para Melhoria
de Processos de Software. A maioria baseada no PDCA (PlanDo-Check-Action) de Eduard Deming. Os modelos para MPS
mais utilizados foram o IDEAL [Mcfeeley 1996], utilizado em
conjunto com o SW-CMM, e o Modelo DMAIC utilizado pelo
Six Sigma.
Com o advento da Garantia da Qualidade, a indstria de
software passou a ser centrada em documentao e orientada
a planejamento, e essa forma de desenvolvimento de software
ficou conhecida como modelo tradicional [Boehm 1988].
Nesse contexto, a Melhoria do Processo de Software
pode ser genericamente estereotipada com as seguintes
caractersticas:
i. Criao de grupo responsvel pelo programa de MPS, realizando atividades de levantamento de no conformidades e
avaliao de desempenho. Na viso do Modelo IDEAL tem-se
o Software Process Group Engineering (SEPG) e no DMAIC,
os Green Belts e Black Belts;
ii. Monitorao do processo atravs de indicadores, permitindo
a identificao das oportunidades de melhoria;
iii. Elaborao de projetos de melhoria com base nas oportunidades identificadas em (ii);
iv. Avaliao dos resultados dos projetos de melhoria atravs

de critrios objetivos e previamente estabelecidos;
v. Utilizao de projetos piloto para realizao dos projetos de
melhoria definidos a partir dos dados obtidos em (iv). Desta
forma, a melhoria institucionalizada para o processo da
organizao;
vi. Aplicao de aes corretivas continuamente medida que
uma no conformidade for encontrada;
Com a criao do Manifesto gil (www.agilemanifesto.org)
em 2001, so formalizadas as metodologias geis que, de certa
maneira, j existiam desde o meio da dcada de 1990, e que
surgiram de descobertas comuns entre os participantes que
aos poucos foram substituindo os processos da tradicional
documentao pesada e desenvolvimento centrado no processo
por abordagens mais centradas em pessoas e menos orientadas
a documentos [Boehm & Turner 2004].
Diante do quadro de ruptura em relao aos modelos tradicionais pelas metodologias geis, aquela forma de MPS
tradicional vinha de encontro s novas idias propostas
pelo manifesto gil, sendo esta MPS pesada demais para as
necessidades do desenvolvimento gil de software.
Manifesto gil e a Nova Cultura

O termo Metodologias geis foi formalizado em 17 de
Fevereiro de 2001, por 17 lderes de desenvolvimento que
propuseram metodologias at ento conhecidas como metodologias leves. Este encontro verificou pontos comuns dessas
metodologias e resultou em um acordo entre os participantes
que possua quatro nveis.
O primeiro nvel considera a necessidade da existncia de
mtodos construdos para responder a mudanas durante o
projeto de software. O termo gil foi adotado para esses
mtodos, pois o termo leve no era apropriado para certos
projetos que teriam restries em empregar metodologias leves
mas, que ainda assim, poderiam precisar de agilidade.
O segundo nvel do acordo foi publicao do Manifesto
gil que composto por quatro valores que continham os
valores centrais de todas as metodologias:
Indivduos e iteraes mais do que processos e ferramentas;
Software funcionando mais do que documentao extensa;
Colaborao do cliente mais do que negociao de contratos;
Responder a mudanas mais do que seguir um plano.
Ainda que haja valor nos termos direita, so valorizados
mais os termos esquerda.
O terceiro nvel composto por um conjunto de doze princpios. Os valores empregados so fornecidos com maior
detalhamento, conforme segue:
A prioridade cumprir as entregas programadas e, por vezes,
antecipadas. Desta forma, o cliente se sentir mais confiante e
seguro no produto solicitado (valor para o cliente);
Mudanas de requisitos so bem-vindas, mesmo em fases tardias do desenvolvimento. Processos geis abraam mudanas
para promover a vantagem competitiva do cliente;
Entregar software funcionando frequentemente, entre poucas semanas a poucos meses, dando preferncia escala de
tempo mais curta;
Pessoas de software e de negcios devem trabalhar juntas
diariamente atravs do projeto;
Construa projetos em torno de indivduos motivados, d-lhes
o ambiente e apoio que necessitem, e confie neles para que o
trabalho seja feito;
A forma mais eficiente e efetiva de trazer informao para o
time, e dentro do mesmo, a comunicao face a face.
Software funcionando a primeira mtrica de progresso;
Processos geis promovem um ritmo sustentvel. Patrocinadores, desenvolvedores e usurios devem estar aptos a manter
o ritmo indefinidamente;
Ateno contnua, excelncia tcnica e bons projetos ajudam
a agilidade.
Simplicidade: a arte de maximizar a quantidade de trabalho
que no deve ser realizado essencial;
As melhores arquiteturas, requisitos e projetos surgem de
times auto-organizados;
Em intervalos regulares, o time deve refletir sobre como
se tornar mais efetivo, ento ajustar seu comportamento de
acordo com a reflexo.
O quarto e ltimo nvel do acordo seriam formados com o
passar do tempo. Ento foi acordado que esse nvel seria aquele
no qual cada abordagem gil deveria definir a si mesma. Algumas destas abordagens so: Extreme Programming (XP),
Scrum, Crystal Clear e Lean.
Melhoria de Processo de Software

Um processo de software pode ser definido como uma
sequncia de passos necessrios para o desenvolvimento
ou manuteno de um software, com o objetivo de prover
um conjunto de boas prticas tcnicas e gerenciais para
a utilizao de tcnicas e ferramentas por pessoas que
iro realizar tarefas para alcanar o objetivo determinado
[Humphrey 1995].
Atualmente todos os programas que carregam a alcunha de
Melhoria de Processo que so criados dentro de uma organizao, visam o Retorno do Investimento (Return On Investment
ROI) para que mais recursos estejam disponveis para que a
mesma continue crescendo [Rico 2004].
Vimos anteriormente os seis passos comuns a todos os programas de Melhoria de Processo de Software executados nos
modelos tradicionais, contudo sero mostrados seis elementos
que so considerados em qualquer programa de MPS executado nos moldes tradicionais [Salo 2007].
1. MODELOS ORGANIZACIONAIS PARA MELHORIA DE
PROCESSO DE SOFTWARE
Nos modelos tradicionais, a melhoria de processo tem um
carter organizacional, ou seja, os processos da instituio so
mapeados, avaliados e as melhores prticas so institucionalizadas, ou se tornaro parte do processo padro da empresa.
10
Esse processo padro apresenta todos os processos de uma organizao e critrios definidos de adaptao. Ou seja, a empresa
possui algumas boas prticas internas mapeadas e, no processo,
existem indicaes de quando usar cada uma delas.
Neste ponto o mais importante entender que todos os projetos da empresa sero executados baseados nesse processo
padro e que as lies aprendidas so incorporadas ao processo
padro da organizao, o que podemos definir como aprendizado organizacional. Para ajudar uma organizao a escolher
a melhor forma de aprender sobre si mesma existem alguns
modelos organizacionais para MPS [Deming 1990; Cohn &
Ford 2003; Boehm & Turner 2005]
2. PROCESSOS PADRES E AVALIAO DOS PROCESSOS
Alguns modelos para Maturidade de Melhoria de Processo,
como o CMMI e o MPS.Br, so hoje referncias no mercado para
a avaliao de processos. Esses modelos fornecem um conjunto
de boas prticas de como o processo pode ser melhorado e
fornecem tambm um mtodo de avaliao (SCAMPI para
o CMMI e o MA.MPS para o MPS.Br) que ajuda a medir a
evoluo do programa de MPS na organizao.
entendido aqui que todo programa de melhoria de processo
deve ser avaliado de forma objetiva seguindo critrios bem
definidos e no ambguos. No existe ainda nenhum mtodo de avaliao que se mostre melhor para todos os casos,
normalmente cada modelo criado adaptado de acordo com
a situao.
3. ADAPTAO DE PROCESSOS
Abordagens de software tradicionais vm sendo criticadas por
no possuir critrios para a sua aplicabilidade, ou no se mostrarem universalmente aplicveis [Malouin & Landry 1983].
Este ponto retrata uma questo na melhoria de processo
de software sobre como uma organizao, com um processo
padro rico em boas prticas e com uma variedade grande de
projetos, pode escolher quais so as melhores prticas para
maximizar o ROI de seus projetos. Este ponto do processo
de MPS conhecido como adaptao de processos. Basili e
Rombach (1987) apresentaram uma das primeiras propostas
para adaptar processos.
4. IMPLANTAO DE PROCESSOS
A implantao do processo uma instncia da MPS nas
organizaes. Ela pode incluir atividades como realizao
de projetos pilotos, mtodos e ferramentas como potenciais
solues para metas ou problemas existentes, e a avaliao dos
efeitos daquela mudana no desenvolvimento de software.
Nas abordagens tradicionais de desenvolvimento de software, mais comum que a melhoria aborde o processo organizacional como um todo, ao invs de questes de um determinado
processo em particular.
Basicamente, uma organizao pode escolher uma estratgia
Big-Ben ou por pedaos para implantar novos processos, mtodos e ferramentas. Enquanto o Big-Ben uma forma revolucionria que acredita que cada mudana sbita resulta em uma forma
M etodologias geis
distinta de trabalho, a estratgia por pedaos uma abordagem

evolucionria que prefere um perodo longo de evoluo dentro
da organizao a partir de pequenas fases de melhoria.
5. MEDIO
Voc no pode controlar aquilo que no pode medir [De
Marco 1982]. A partir dessa premissa verificado que sem
atividades de medio e controle, fica extremamente difcil
pensar em Melhoria de Processo de Software. Na verdade, a
medio possui trs propsitos [Fenton & Pfleeger 1997]:
Entender o desenvolvimento e manuteno;
Controlar Projetos;
Melhorar Processos e Produtos.
Na melhoria de processo, a medio fundamental para a
promoo da melhoria contnua no processo. Vrios mecanismos para obteno de dados quantitativos existem hoje
para auxiliar o processo de medio. Os mais comuns em
programas de MPS so o GQM (Goal Question Metric) e o
PSM (Practical Software and Systems Measurement) [Fenton
& Pfleeger 1997].
6. EXPERINCIA, CONHECIMENTO E APRENDIZADO
O valor representado pela experincia e conhecimento no
deve ser subestimado dentro de um programa de MPS e dentro de sua expectativa de melhoria contnua. Deming (1990)
afirmava que perder conhecimento mais prejudicial do que
perder material. Em programas de MPS considerado crucial
que as lies aprendidas dentro dos projetos correntes sejam
testadas em outros projetos e, se o resultado for positivo, que
esse conhecimento seja adicionado base de conhecimento da
organizao, e isso normalmente ocorre com uma adio ao
processo padro da organizao.
Neste aspecto, podemos ressaltar o verdadeiro objetivo dos
programas de MPS dentro das organizaes, que o aprendizado daquilo que funciona ou no dentro daquela organizao,
e em que contexto este resultado pode ser reproduzido.
MPS no Desenvolvimento gil de Software

correto afirmar que tcnicas e mtodos de MPS esto limitados dentro do desenvolvimento gil de software, mesmo tendo
essa Melhoria de Processo de Software um papel fundamental
dentro de qualquer mtodo gil.
Esta importncia observada em um dos princpios presentes no 3 nvel do acordo que gerou o manifesto gil. O
ltimo princpio das metodologias geis foi definido como:
Em intervalos regulares o time deve refletir sobre como se
tornar mais efetivo e ajustar seu comportamento de acordo
com esta reflexo.
De fato, o desenvolvimento gil de software prov uma
forma no-tradicional para a realizao da MPS, pois
este considera a melhoria do processo de obteno e compartilhamento do conhecimento entre os desenvolvedores,
sendo necessrio criar uma escala para poder pontuar
a experincia desse time e maximizar o ganho dessa
experincia e sua disseminao por toda a equipe. Assim, o

desenvolvimento gil de software possibilita novas formas
para realizao desta melhoria de processo alm daquelas
apresentadas pelos modelos tradicionais.
Para o desenvolvimento gil de software, a melhoria de
processo possui as seguintes caractersticas:
i. Todo o time responsvel pela melhoria de processo;
ii. As melhorias propostas so resultados da experincia do
time sobre o que pode melhorar em seu prprio comportamento sem a necessidade de indicadores formais ou critrios
bem definidos;
iii. As mudanas propostas pelo time entram em vigor a partir
da prxima iterao, ou seja, j incorporado ao processo da
equipe no precisando de projetos pilotos;
iv. A avaliao das mudanas ocorre pelo sentimento da equipe
durante o que aconteceu durante aquela iterao, ento se a mudana funcionou, a equipe pode manter aquela mudana;
v. As mudanas so propostas em intervalos bem definidos,
esses intervalos podem de durar de uma a poucas iteraes;
vi. O time tem autonomia para se auto-organizar e determinar
como o processo ser seguido e determinar que aes realizar
quando no conformidades forem encontradas.
Avaliando os seis elementos presentes na melhoria de processo quando tratamos do desenvolvimento gil, temos os
seguintes resultados:
1. MODELOS ORGANIZACIONAIS PARA MELHORIA DE
PROCESSO DE SOFTWARE
No desenvolvimento gil de software, o time a unidade
responsvel pela execuo de um projeto. No 3 nvel do acordo
que gerou o manifesto gil observado o seguinte princpio:
As melhores arquiteturas, requisitos e projetos surgem de
times auto-organizados.
Esse princpio esclarece que, no contexto gil, as decises
do time so mais prioritrias do que aquelas vindas da organizao. A uniformidade no encorajada. Todos os times
trabalham, logo podemos considerar que nesse contexto no
h um processo padro definido. Porm, se pensarmos que os
times da organizao utilizam uma mesma abordagem, por
exemplo, XP, pode-se pensar em uma forma muita parecida
de trabalho.
Boehm & Turner (2005) afirmam que existem desafios gerenciais em implantar processos geis, pois eles no seguem
a hierarquia Topdown encontradas nas organizaes tradicionais, uma vez que o empowerment dado aos times tornam
essa mesma estrutura auto-gerencivel.
2. PROCESSOS PADRES E AVALIAO DOS PROCESSOS
A avaliao do processo, bem como de todas as melhorias
propostas pela equipe, no possuem indicadores definidos
nem critrios de aceitao formais que indiquem a aprovao
ou no do mesmo. As avaliaes so realizadas de forma
subjetiva, de acordo com a experincia que o time obteve em
experimentar aquele novo processo durante a iterao.
11
Da mesma maneira informal com a qual a avaliao realizada, de forma subjetiva e sem a utilizao de indicadores,
tambm a forma com que se escolhe aquilo que deve ser
alterado no processo. No h uma maneira sistemtica
para decidir, ou avaliar, o que deve ser modificado e no
que est baseada a escolha, a no ser pela experincia do
prprio time.
O mtodo de avaliao que vem sendo aceito comumente
pelos times Scrum o Nokia Test [Vodde 2006]. Outra iniciativa
interessante que est se definindo como um padro na rea
das metodologias geis o IEEE 1648 (http://standards.ieee.
org/board/nes/projects/1648.pdf).
3. ADAPTAO DE PROCESSOS
Nas metodologias geis, os processos so adaptados com
mais freqncia e de forma no sistematizada. Contudo, o
desenvolvimento gil considera que processos que so criados para serem repetidos so falhos e consideram que cada
situao exige um processo diferente, uma vez que processos
repetitivos s funcionam com as mesmas pessoas, nos mesmos
ambientes, com as mesmas ferramentas, para solucionar os
mesmos problemas repetidas vezes.
De fato, o desenvolvimento gil precisa de adaptaes dentro
de projetos individuais dentro de uma organizao, e esse
processo continuamente melhorado a partir de pequenas
mudanas. Afinal, o desenvolvimento de software proposto
pelas metodologias geis no est baseado em processos preditivos em ambientes estveis para o desenvolvimento, e sim,
baseado em um ambiente de mudanas frequentes, que ainda
assim necessitam de qualidade.
4. IMPLANTAO DE PROCESSOS
A maioria das implantaes de processos no desenvolvimento
gil est mais voltada para a abordagem Big-Ben, onde grandes
mudanas podem ser sugeridas, no entanto no h critrios
para essas mudanas.
O maior desafio nestes tipos de implantao a falta de
transparncia entre os diversos nveis da organizao (hierarquia) em relao ao time auto-gerencivel, o que pode
resultar em um relacionamento fracassado entre as partes
interessadas de mais alto-nvel e o time. Mais dificuldades
sobre a implantao de processos em organizaes geis so
listadas em [Cohn & Ford 2003].
5. MEDIO
Boehm & Turner (2005) afirmam que a maioria das tcnicas
de medio tradicionais podem se tornar inadequadas para o
apoio aos mtodos geis. As razes mais comuns desta falha
provm da diferente forma como as estruturas analticas de
projeto (EAP) so construdas. Enquanto nos mtodos tradicionais essas EAPs so um conjunto de atividades e tarefas
normalmente exibidas em grficos de Gantt, nos mtodos
geis temos a manipulao de cartes de estrias (XP) ou itens
de Backlog (Scrum) que so detalhados em nvel satisfatrio
apenas quando so desenvolvidos.
12
Falando em mtricas para melhoria de processos, em

particular, no vemos nenhuma indicao no manifesto
gil de que esta seja uma ferramenta para o MPS. Contudo,
XP indica que sempre que for necessria uma adaptao
ao processo, deve ser criado um mecanismo para avaliar
o resultado dessa mudana, e Scrum afirma que se as
coisas corretas forem medidas, possvel a realizao
de melhorias.
Observando o princpio: Software funcionando a primeira
mtrica de progresso pode-se considerar que as medies
so uma importante ferramenta para controle da execuo
das atividades de engenharia do produto (gerenciamento do
projeto) do que para a Melhoria de Processos no desenvolvimento gil.
6. EXPERINCIA, CONHECIMENTO E APRENDIZADO
Este um dos pontos mais valorizados no desenvolvimento gil de software, especialmente sobre os times que
desenvolvem um software especfico. A nfase dada ao
aprendizado coletivo do time observado no princpio gil:
Em intervalos regulares, o time deve refletir sobre como
se tornar mais efetivo, ento ajustar seu comportamento de
acordo com a reflexo.
Beck & Andrs (2004) afirmam que, em XP, bons times no
fazem apenas o seu trabalho, mas pensam sobre como realizar
seu trabalho e por que realiz-lo. O time analisa o porqu de
seu sucesso e sua falha, e eles no tentam esconder os seus
erros, pelo contrrio, eles so encorajados a mostr-los e
aprender com eles.
O time deve ser encorajado a aprender no s com a experincia deles, mas tambm com a experincia do cliente [Koch
2005]. No desenvolvimento gil encorajada a comunicao
face a face para que haja um entendimento melhor durante o
ciclo de vida do desenvolvimento.
Contudo, no considerado aqui o aprendizado organizacional. Os times podem adaptar tcnicas diferentes,
para atender necessidades diferentes no processo de desenvolvimento, e este tipo de experincia fica implcito, uma
vez que no existe um mecanismo definido para troca de
experincias dentro dos times geis. O que normalmente
feito, que um membro de cada time seja trocado de lugar e
este compartilhe as suas experincias com os outros times,
homogeneizando o conhecimento.
A tcnica mais utilizada para a realizao de MPS dentro
do desenvolvimento gil so as retrospectivas. Esta tcnica foi
desenvolvida originalmente para o mtodo Crystal Clear, mas
foi incorporado ao SCRUM (Sprint Retrospectives Meetings)
e ao XP (Reflexes).
Esta tcnica se resume em uma reunio que deve ocorrer
sempre no final de uma iterao. Nessa reunio o time deve
opinar sobre trs aspectos:
O que est funcionando e deve ser mantido?
O que est ruim e deve ser modificado?
O que podemos tentar fazer diferente?
M etodologias geis
Referncias
Estes trs tpicos so discutidos de acordo com a experincia de cada desenvolvedor e todos do a sua opinio sobre
cada idia surgida. Contudo, no h critrios ou indicadores
para justificar/avaliar cada uma das sugestes, ficando
apenas a critrio do time se a mudana ser incorporada
ou no ao processo.
As mudanas que forem aceitas pela equipe entram em vigor
j na iterao seguinte e, na prxima reunio de retrospectivas,
ela pode ser mantida, retirada ou at mesmo melhorada.
Consideraes Finais
sobre e
s
A Engenharia de Software Magazine tem que ser feita ao seu gosto.

Para isso, precisamos saber o que voc, leitor, acha da revista!
D seu voto sobre este artigo, atravs do link:
www.devmedia.com.br/esmag/feedback
Feedback
eu
edio
ta
D seu feedback sobre esta edio!
D
s
A execuo da Melhoria de Processo de Software dentro de

um ambiente gil muito distinta daquela vista nos modelos
tradicionais. Essa mudana no reflete apenas a mudana
cultural, mas tambm a necessidade de novas formas de
melhoria de processo que so inerentes ao desenvolvimento
gil de software.
O pouco formalismo, aliado a uma forma no sistemtica
da realizao desse tipo de MPS, o torna de difcil convivncia com estruturas tradicionais e partes interessadas
de mais alto nvel, se tornando, muitas vezes, arriscado
para o projeto. A falta de um mecanismo eficiente para
que a organizao se aproveite da experincia obtida por
cada time tambm um ponto crtico nas relaes de MPS
tradicionais versus geis.
Esta forma no-tradicional de MPS focada na melhoria do
comportamento em ambientes de mudanas constantes, aproveitando ao mximo a experincia de cada um dos indivduos e
a agilidade com que cada um dos times pode se auto-organizar
para se adaptar a uma situao.
[Basili & Rombach 1987] Basili, V. R. & Rombach, H. D (1987) Tailoring the Software Process to
Project Goals and Environments. In: The proceedings of the 9th International Conference on
Software Engineering. March 1987. Monterey, CA. Pp. 345-357.
[Beck & Andres 2004] Beck, K. & Andres, C. (2004) Extreme Programming Explained: Embrace
Change. Second Edition. Addison-Wesley. Boston. pp 29.
[Boehm 1988] Boehm, B. (1988) A Spiral Model of Software Development and Enhancement
Computer, Vol. 21, 5 (5), May 1988, pp. 61-72.
[Boehm & Turner 2004] Boehm, B.; Turner, R. (2005) Balancing agility and discipline: A guide for
the perplexed (1st ed., pp. 165-194, Appendix A). Addison Wesley.
[Boehm & Turner 2005] Boehm, B. & Turner, R. (2005) Management Challenges to
Implementing Agile Processes in Traditional Development Organizations. IEEE Software, Vol.
22(5), SeptemberOctober. pp. 30-39.
[Cohn & Ford 2003] Cohn, M. & Ford, D. (2003). Introducing an Agile Process to an Organization.
Computer, Vol. 36 (6), June, pp. 74-78.
[De Marco 1982] De Marco,T. (1982) Controlling Software Projects: Management, Measurement
and Estimation. Yourdon Press. New York. pp-296.
[Deming 1990] Deming, W. E. (1990) Out of the Crisis. 10 Printing ed. Massachussetts Institute
of Technology, Center for Advanced Engineering Study. Cambridge. pp- 507.
[Fenton & Pfleeger 1997] Fenton, N. & Pfleeger, S. L. (199). Software Metrics: A Rigorous &
Practical Approach. Second Edition ed. PWS Publishing Company. Boston. pp- 63.
[Humphrey 1995] Humphrey, W. S (1995) A Discipline for Software Engineering. Addison
Wesley, Longman. pp. 242 .
[Koch 2005] Koch, A. S. (2005) Agile Software Development: Evaluating the Methods for Your
Organization. Artech House. Boston.
[Malouin & Landry 1983] Malouin, J. L. & Landry, M. (1983) The Miracle of Universal Methods in
Systems Design. Journal of Applied Systems Analysis, Vol. 10, pp. 4762.
[McFeeley 1996] McFeeley,R.(1996)IDEAL:A Users Guide for Software Process ImprovementCMU-SEI.
[Mnkandla & Dwolatzky 2004] Mnkandla, E.; Dwolatzky, B. (2004) Balancing the human and
the engineering factors in software development. Proceedings of the IEEE AFRICON 2004
Conference (pp. 1207-1210).
[Rico 2004] Rico, D. F. (2004) ROI of Software Process Improvement: Metrics for Project Managers
and Software Engineers. J. Ross Publishing. Florida, U.S.A. pp - 218.
[Salo 2007] Salo, O. (2007) Enabling Software Process Improvement in Agile Software
Development. PHD Thesis.
[Schuh 2004] Schuh, P. (2004) Integrating agile development in the real world (pp. 1-6). MA:
Charles River Media.
[Vodde 2006] Vodde, B. (2006) Nokia Networks and Agile Development: in EuroMicro Conference.
13
Implantao de Processo
Os desafios da implantao de um processo de software
A necessidade de um processo de
software
Edite Martins
edite.martins@dextra-sw.com
Engenheira de Computao pela Unicamp, com

especializao em Administrao de Empresas
pela FGV-SP. Trabalha na rea de TI h 16 anos,
atuando como Gerente de Projetos e Gerente de
Qualidade em empresas de desenvolvimento
de software sob medida. J atuou no gerenciamento de projetos de desenvolvimento de
sistemas para grandes empresas como Natura,
BankBoston, Globosat, entre outros. Recentemente gerenciou o processo de avaliao MPS.
BR nvel F da Dextra Sistemas.
14
O processo de software uma seqncia lgica de atividades com o objetivo

final de produzir ou evoluir um produto
de software. Essas atividades englobam
a especificao dos requisitos, anlise e
design, implementao, testes e implantao, e caracterizam-se pela interao
de ferramentas, pessoas e mtodos.
Estabelecer um processo significa definir
todas as atividades a serem realizadas, bem
como a seqncia e dependncia entre
elas, como as atividades sero executadas
e quem responsvel por cada uma. A execuo bem sucedida de um processo requer
um conjunto de ferramentas de apoio e,
principalmente, a conscientizao da equipe sobre a necessidade do processo.
A implantao de um processo de software em uma empresa um investimento
custoso, porm tem se mostrado o fator
primordial para o sucesso das empresas no
alcance de seus objetivos, principalmente
Engenharia de Software Magazine - Implantao de Processo
Neste artigo veremos quais so os principais desafios e benefcios da implantao de um processo

de desenvolvimento de software. Sero descritos
aspectos importantes do processo que foi definido,
bem como as ferramentas que foram desenvolvidas para dar suporte sua implantao.
Para que serve?

A implantao de um processo de desenvolvimento tem se mostrado como um fator primordial de sucesso para as empresas de software.
Entretanto, para ser um projeto de sucesso, deve
ser planejado para refletir a realidade e dinmica
da empresa, caso contrrio pode se tornar algo
oneroso e difcil de manter.

Para as empresas que esto planejando implantar
um processo de desenvolvimento de software.
aqueles que se referem a satisfao dos

clientes e previsibilidade de custo e prazo.
O estabelecimento de um processo,
bem definido, diminui a dependncia
da empresa em relao s pessoas e
possibilita a disseminao de melhores
prticas, documentos e conhecimento.
Processo
Atualmente, existem vrios modelos de processo de software

e um dos mais conhecidos e utilizados o RUP Rational
Unifed Process, comprado pela IBM.
O RUP baseado em orientao a objetos e documentado
utilizando a linguagem UML Unified Modeling Language.
considerado um processo pesado, que preferencialmente deve ser
utilizado em grandes projetos e equipes. Porm, como fortemente customizvel, possvel adapt-lo para qualquer empresa.
Quando o RUP foi lanado, grandes empresas tentaram
aplic-lo em suas reas de desenvolvimento de software. Foram realizados grandes investimentos e nem todos obtiveram
o sucesso almejado. O principal problema foi acreditar que o
RUP poderia ser utilizado da forma como estava definido sem
que fosse gasto esforo e tempo para identificar de que forma
o RUP se encaixaria na estrutura da empresa.
O caso que iremos detalhar exatamente como a Dextra Sistemas (www.dextra.com.br) extraiu do RUP o que era realmente
aplicvel s suas necessidades e como esse esforo e investimento culminou na melhoria do resultado dos seus projetos e
na avaliao MPS.BR nvel F obtida em Maro de 2009.
Definio do processo
A Dextra teve um crescimento muito expressivo nos anos
de 2006 e 2007 e com isso surgiu a necessidade da definio e
implantao de um processo mais formal. A empresa j contava
com o ProUD (Processo Unificado Dextra) que se baseava fortemente no RUP. A verso 1.0 do ProUD era bastante enxuta e
se aplicava muito bem ao tamanho e caractersticas da empresa
e de suas equipes de trabalho at ento.
O objetivo da evoluo e melhoria do processo da Dextra era
ter um nvel maior de formalizao das atividades e papis,
bem como coletar e analisar indicadores de projeto que dessem
a visibilidade necessria em relao qualidade do produto,
pontualidade nas entregas e previsibilidade de custo.
Diante disso, a estratgia da empresa foi novamente aplicar o
RUP, utilizando o feedback j obtido no uso do ProUD 1.0 em
diversos projetos. A principal meta da Dextra era definir um
processo que representasse o que a empresa fazia de melhor nos
seus projetos e corrigisse o que ainda poderia melhorar. Com
esse foco o plano de trabalho contou com a formao de grupos
de trabalho formados por membros das equipes de projetos. Os
lderes de cada grupo eram membros do SEPG Software Engineer Process Group e davam o direcionamento necessrio s
atividades. O resultado de um ano de trabalho foi o ProUD 2.0.
O processo foi dividido em quatro grandes fases, como se v na
Figura 1. Na verso 1.0 do ProUD, os nomes das fases eram exatamente iguais s do RUP Concepo, Elaborao, Construo e
Transio. Porm, com a utilizao do processo percebeu-se que
havia atividades que no RUP eram feitas na fase de Elaborao e
que na Dextra fazia mais sentido que fossem executadas na fase
de Construo e vice-versa. Desta forma, quisemos desvincular
as fases do ProUD das fases do RUP, criando fases e atividades
dentro delas que representam a realidade da empresa e a melhor
forma de trabalho de suas equipes. Segue abaixo uma breve
descrio de cada uma das fases:
Figura 1. Fases do ProUD 2.0
Planejamento
Nesta fase ocorre a definio do escopo do projeto e de suas
fronteiras, assim como o planejamento detalhado de sua
execuo. So gerados todos os planos do projeto plano de
comunicao, riscos, infra-estrutura, recursos humanos, gesto
de configurao e etc. Todos os compromissos internos e com o
cliente so formalizados e aprovados. Esta fase recebe muitos
insumos da fase de proposta, que tambm segue um processo
bem definido e formal. Parte das atividades desta fase feita
durante a fase de Concepo do RUP.
Refinamento da Soluo
Nesta fase os requisitos levantados durante a fase de proposta
so detalhados, bem como a arquitetura final da soluo e os
aspectos de integrao com outros sistemas. Deve-se, tambm,
fazer uma extensiva anlise dos riscos do projeto associados
aos requisitos e tecnologia utilizada. O resultado desta fase
o detalhamento inicial dos requisitos, prottipos de telas e a
definio da arquitetura do sistema. As atividades desta fase
so executadas parte na fase de Concepo e parte na fase de
Elaborao do RUP.
Execuo
O foco nessa fase dado implementao das funcionalidades
do sistema. A implementao desenvolve-se de maneira iterativa
e incremental. A cada iterao implementado um conjunto de
casos de uso definidos previamente, tendo passado pelas fases
de anlise, projeto, codificao, testes e integrao.
O conceito de iteraes faz com que os riscos do projeto sejam
reduzidos, pois possvel liberar funcionalidades para os usurios antes de concluir todo o projeto, verificando a adequao
do sistema aos requisitos funcionais e tcnicos (escalabilidade,
segurana e confiabilidade).
Ainda nessa fase, os componentes de software desenvolvidos
devem ser implantados nos ambientes de homologao e de
produo do cliente. Os treinamentos planejados so preparados e aplicados aos usurios.
As atividades desta fase correspondem fase de Construo
e Transio do RUP.

Encerramento
Esta fase se inicia aps o aceite formal do cliente. So gerados
documentos de encerramento do projeto, indicadores, lies
aprendidas e reunio de fechamento com a equipe. Nesta fase
inicia-se a atividade de acompanhamento da operao (operao assistida) e o perodo de garantia do produto.
15
As atividades desta fase so realizadas na fase de Transio do RUP.

As disciplinas definidas para o ProUD so muito similares s do
RUP e largamente executadas durante os ciclos iterativos da fase
de Execuo. So nas iteraes que os requisitos so detalhados,
projetados, implementados, testados e integrados ao sistema para
homologao pelo cliente. Acreditamos que quanto antes o cliente
receber o produto, mesmo que uma verso parcial, mais chances
o produto final ter de atender as expectativas do cliente. As disciplinas implementadas no ProUD esto descritas abaixo:
Requisitos: tem como objetivo identificar os requisitos do sistema atravs do entendimento das necessidades dos stakeholders. O escopo identificado deve ser mantido e controlado no
decorrer do projeto;
Anlise e Projeto (ou Anlise e Design): tem como objetivo
elaborar a arquitetura do sistema e garantir que a soluo seja
implementada no decorrer do projeto;
Implementao: tem como objetivo implementar os requisitos
identificados, seguindo a arquitetura definida, gerando cdigo
fonte testado unitariamente;
Testes: tem como objetivo garantir que o produto que ser
entregue ao cliente implementa corretamente o que foi solicitado. Alm disso, prov a garantia de que mudanas no sistema
no introduziram defeitos ou efeitos indesejados;
Implantao/Integrao: tem como objetivo preparar o produto para ser liberado/entregue ao cliente e disponibiliz-lo
no ambiente de homologao;
Gerncia de Projetos: tem como objetivo planejar e controlar
o escopo do projeto, gerenciando as expectativas da equipe,
do cliente e da alta direo da empresa;
Gerncia de Configurao e Verso: tem como objetivo
manter um conjunto consistente de produtos de trabalho,
medida que vo sendo produzidos e alterados.
A Figura 2 mostra como as disciplinas esto relacionadas dentro de um ciclo iterativo da fase de Execuo. As disciplinas
de Gesto de Projetos e Gesto de Configurao e Verso permeiam toda a cadeia de desenvolvimento, pois so disciplinas
de suporte ao desenvolvimento de software.
Toda definio do processo foi feita utilizando a ferramenta
OpenSource EPF Composer, que possibilita diferentes vises
aos usurios, facilitando a busca e visualizao das informaes. O EPF Composer publica o processo em formato de
um website que normalmente fica disponvel na Intranet da
empresa com acesso a todos os seus colaboradores.
As fases do ciclo de vida so exibidas em forma de diagramas,
onde as atividades esto agrupadas por papel. Cada atividade
do diagrama um link para a sua descrio, onde esto detalhados os artefatos de entrada, de sada, templates dos produtos
de trabalho e papis responsveis pela atividade.
A Figura 3 mostra uma tela do ProUD 2.0 publicado atravs do EPF.
Pode-se notar que h uma barra de navegao onde o usurio pode
percorrer o processo pelo ciclo de vida, pelas disciplinas, pelos papis
e produtos de trabalho. Alm de ter um acesso direto a todos os
templates de documentos e orientaes de forma rpida e direta.
16
Figura 2. Ciclo de Vida Iterativo da fase de Execuo
Implementando o MPS.BR Nvel F

Um dos objetivos do projeto de melhoria e evoluo do
ProUD, era a de implementar tambm um modelo de qualidade reconhecido no mercado de software. A empresa
escolheu o MPS.BR por ser um programa brasileiro, voltado
para a realidade do mercado de pequenas e mdias empresas
de desenvolvimento de software. O MPS.BR baseado no
CMMI, nas normas ISO/IEC 12207 e ISO/IEC 15504 e o Nvel
F corresponde ao CMMI 2.
O trabalho de implementao do MPS.BR ocorreu em paralelo
evoluo do ProUD, e direcionou por vezes, o seu foco. O
nvel de maturidade F (Gerenciado) composto pelos processos
de Gerncia de Projeto, Gerncia de Requisitos, Aquisio,
Gerncia de Configurao, Garantia da Qualidade e Medio.
O processo de Aquisio s implementado por empresas que
terceirizam o desenvolvimento de software.
Todos os processos tm integrao entre si, por isso era necessrio pensar em uma infra-estrutura de ferramentas que
possibilitasse a agregao das informaes e, desta forma,
minimizasse o custo com replicao de dados. A soluo
escolhida foi a implementao e customizao de algumas
ferramentas que permitiram a implementao do modelo e
que hoje so a grande base dos projetos de desenvolvimento
de software da empresa.
TRAC
O TRAC uma ferramenta OpenSource, com interface web
para gerenciamento e controle de mudanas em projetos de
desenvolvimento de software. Alm de possibilitar a documentao colaborativa atravs do Wiki, tem integrao com
o subversion, permitindo o rastreamento de mudanas nos
artefatos do projeto.
O TRAC foi customizado de forma a ser o grande centralizador de informaes do projeto. As informaes esto
Processo
Figura 3. Site do ProUD 2.0 publicado pelo EPF Composer
no Trac, ou em forma de wiki, ou em forma de tickets.

Para que a documentao do projeto pudesse ser wiki,
foi feita uma customizao onde os wikis visualizados
no site so obtidos diretamente do subversion e no na
base de dados do Trac. Desta forma possvel manter
toda a documentao disponvel via web, porm com
controle formal de verso. So exemplos de documentos
que esto hoje em formato wiki: plano do projeto, atas
de reunio, documento de viso, glossrio, dicionrio
de dados, documento de arquitetura, casos de uso entre outros. O formato wiki minimiza vrios problemas
referentes a resoluo de conflitos e merge de arquivos
no subversion, devido ao fato de ser um arquivo texto.
A Figura 4 um exemplo de Documento de Arquitetura
disponvel no Trac.
Figura 4. Documento de Arquitetura em Wiki
Para que o registro das demais informaes do projeto pudesse ser realizado atravs de tickets, estes foram customizados
em vrios tipos. Como o TRAC oferece a referncia cruzada
entre seus elementos, possvel definir e manter toda a rastreabilidade necessria ao projeto e tambm ao MPS.BR. As
seguintes informaes so registradas no TRAC em forma de
tickets: requisitos, casos de uso, riscos, mudanas, defeitos,
no-conformidades, aes gerenciais e tarefas (importadas do
MSProject ou criadas manualmente).
DET
A DET Dextra Estimating Tool uma ferramenta de desenvolvimento prprio para realizar as estimativas de todos
os projetos de desenvolvimento de software da empresa. As
estimativas so baseadas em tamanho funcional e o resultado
a estimativa de esforo para todas as atividades definidas no
processo. Alm disso, possvel tambm realizar a identificao de riscos, requisitos no-funcionais e atividades suplementares. A ferramenta exporta, seguindo templates padres,
a lista de requisitos funcionais e no-funcionais do projeto,
a lista de riscos e o cronograma detalhado do projeto. Estas
informaes so importadas no TRAC, onde sero gerenciadas
ao longo do projeto.
PMA
O PMA Sistema de Gesto de Projetos tambm uma
ferramenta de desenvolvimento prprio que gerencia o
apontamento de horas das equipes do projeto e o seu custo.
O apontamento realizado de acordo com as atividades do
processo, desta forma possvel extrair informaes sobre a
17
acuracidade das estimativas e gerar dados para a reviso do

mtodo sempre que necessrio. Alm disso, a ferramenta controla o custo dos recursos, gerando as medidas necessrias para
o clculo de indicadores referentes ao ndice de performance
de custo do projeto.
A seguir vamos descrever sucintamente, como implementamos cada um dos processos tendo como base o conjunto de
ferramentas descritas acima:
Gerncia de Projetos
Propsito: estabelecer e manter planos que definem as
atividades, recursos e responsabilidades do projeto, bem
como prover informaes sobre o andamento do projeto que
permitam a realizao de correes quando houver desvios
significativos no desempenho do projeto.
Ns j praticvamos a gerncia de projetos desde o ProUD
1.0, e o trabalho de melhoria de processo foi focado na padronizao dos documentos e artefatos produzidos e a sua
disponibilizao para a equipe e o cliente. A documentao
passou a ser disponibilizada na ferramenta TRAC de cada
projeto, em formato wiki. Foram definidas formas obrigatrias de acompanhamento do projeto cujo registro so
atas de reunio e relatrios de status. O acompanhamento
do projeto tem o objetivo de controlar e monitorar todos
os itens que foram detalhados durante o planejamento e
confront-los com o realizado. Um fator essencial para a
maturidade no processo de gerncia de projetos conseguir
fazer uma anlise crtica do que est sendo executado em
relao ao planejado em termos de custo, escopo, prazo e
riscos e verificar se o projeto ainda continua vivel ou que
aes devem ser tomadas para que o projeto seja finalizado
com sucesso.
Gerncia de Requisitos
Propsito: gerenciar os requisitos dos produtos e componentes do produto do projeto e identificar inconsistncias entre
os requisitos, os planos do projeto e os produtos de trabalho
do projeto.
O processo de gerncia de requisitos era largamente praticado
na empresa desde o ProUD 1.0 e o trabalho de melhoria de
processo foi focado na padronizao dos documentos gerados
por esta disciplina. Os documentos de Viso e de Casos de Uso
so disponibilizados no TRAC do projeto, em formato wiki.
Alm disso, o uso da DET passou a ser obrigatrio para todos
os projetos de desenvolvimento de software, padronizando
as estimativas
Contudo, a maior mudana neste processo foi a definio do
mecanismo de gerenciamento de mudanas dos requisitos.
Foi redefinido um processo de anlise de solicitaes de mudanas, onde o uso dos mecanismos de rastreabilidade implementados pelo TRAC imprescindvel. Com a realizao de
uma anlise de impacto efetiva das solicitaes de mudana
possvel controlar o escopo, custo e prazos do projeto de forma
objetiva e transparente para a equipe e cliente.
18
Gerncia de Configurao
Propsito: estabelecer e manter a integridade de todos os produtos de trabalho de um processo ou projeto e disponibiliz-los
a todos os envolvidos.
Apesar da empresa j utilizar o TRAC integrado ao subversion, o que j estabelece uma base bastante slida para
o gerenciamento de configurao e verso, a evoluo deste
processo no ProUD 2.0 foi grande, e com resultados surpreendentes para os projetos. Foi criado formalmente o papel de
Analista de Configurao e foram redefinidas as estruturas
de diretrio, padro de nomenclatura, registros de baselines,
regras de integrao de arquivos ao repositrio e checklists
para auditorias do sistema de configurao. O objetivo
principal deste processo manter o repositrio ntegro e
gerar informaes para que se possa extrair a rastreabilidade entre requisitos e cdigo fonte e vice-versa. Para que a
rastreabilidade seja construda e mantida necessrio que o
sistema de configurao esteja fortemente amarrado e com
regras rgidas de integrao de modificaes ao repositrio.
As customizaes realizadas no TRAC e a integrao com
o subversion foram fatores chave para que se alcanasse a
maturidade exigida neste processo.
Garantia da Qualidade
Propsito: assegurar que os produtos de trabalho e a execuo dos processos estejam em conformidade com os planos e
recursos predefinidos.
Este processo foi criado no ProUD 2.0. A definio do processo consistiu em criar as atividades de auditoria, definir
polticas, periodicidade e checklists de avaliao. As auditorias
so realizadas no decorrer do projeto e sempre que h entregas
para o cliente. As no-conformidades so registradas como
tickets no TRAC e tem uma mquina de estados definida para
seu acompanhamento. Todas as no-conformidades tm um
prazo definido para resoluo e caso no sejam solucionadas
so escaladas para alta gerncia da empresa.
As auditorias de qualidade so uma forma da empresa
garantir que os projetos esto seguindo o processo definido,
gerando os produtos de trabalho esperados e dentro dos padres estabelecidos. As auditorias de qualidade em produtos
de trabalho que sero entregues ao cliente so de extrema
importncia para a empresa, pois garantem uma uniformidade
em termos de documentao alm de aumentar a qualidade
do produto gerado.
Medio
Propsito: coletar, analisar e relatar os dados relativos aos
produtos desenvolvidos e aos processos implementados na
organizao e em seus projetos, de forma a apoiar os objetivos
organizacionais.
Todos os indicadores da empresa foram refeitos no ProUD 2.0.
Foi utilizado o mtodo GQM Goal Question Metrics, onde
a diretoria define os objetivos a serem alcanados, perguntas
so feitas sobre como os objetivos podem ser atingidos e medidas so identificadas a partir das questes. Foi montada uma
Processo
Links
Site do Softex Brasil www.softex.br/mpsbr/
Site onde possvel obter informaes sobre o RUP www.wthreex.com/rup/
Site da ferramenta TRAC trac.edgewall.org/
Site da ferramenta EPF Composer www.eclipse.org/epf/
Publicao da avaliao MPS.BR F realizada na Dextra em Maro/2009 www.softex.br/
mpsbr/_avaliacoes/avaliacao.asp?id=2465

Feedback
eu
19
sobre e
s
O ProUD 2.0 foi lanado oficialmente na Dextra em Setembro

de 2008. Foram realizados diversos treinamentos e workshops
na empresa para divulgao e capacitao das equipes. Todos
os projetos que comearam aps o lanamento utilizaram a
nova verso do processo.
A avaliao foi marcada para Fevereiro de 2009, apenas 5
(cinco) meses aps o lanamento da nova verso do processo.
A avaliao envolveu 4 (quatro) projetos e cerca de 35 (trinta
e cinco) pessoas que estavam divididas entre os projetos que
seriam avaliados. A avaliao composta por uma fase de
anlise de documentos e uma fase posterior de entrevistas com
os membros das equipes. O resultado da avaliao foi excelente
e a empresa foi recomendada para o Nvel F de maturidade
do MPS.BR, tendo como principais pontos fortes: a) o conjunto
de ferramentas adotado, que automatiza as atividades e traz
D
s
A avaliao MPS.BR nvel F
maior controle e ganho de produtividade da equipe e b) o

envolvimento das equipes dos projetos com o processo.
O que interessante ressaltar que esses dois pontos foram
justamente a maior preocupao da empresa desde o incio:
envolver a empresa na definio do processo e investir em
ferramentas que suportassem a sua implantao.
O que a experincia tem nos mostrado que a implantao
de um processo de software ser sempre custosa e representa
um investimento financeiro importante para a empresa. Por
outro lado, a empresa ter maior sucesso e retorno deste investimento se o processo for elaborado e construdo dentro da
prpria empresa. Um processo no se impe s pessoas, ele se
constri junto com elas.
edio
ta
planilha com 22 indicadores, onde so definidos os mtodos

de coleta e anlise, bem como sua periodicidade. Alguns dos
indicadores so CPI, SPI, satisfao do cliente, desvio de estimativa entre outros. A fcil extrao das medidas para o clculo
dos indicadores s possvel pelo fato destas medidas serem
registradas nas ferramentas DET, TRAC e PMA.
A coleta e anlise de indicadores dos projetos tem se mostrado como um dos principais benefcios obtidos no ProUD 2.0.
A padronizao na coleta das medidas em todos os projetos
trouxe um ganho expressivo de visibilidade em termos de
custos, prazos, qualidade, desvio de estimativas entre outros.
evidente o ganho que este processo trouxe para a alta gerncia da empresa.
Gerncia de Configurao
Definies Iniciais
Thas Miranda Cia

thaismcia@gmail.com
mestre em Cincia da Computao e Matemtica Computacional pelo ICMC-USP.
20
urante o desenvolvimento de software, uma grande quantidade

de informaes produzida, tais
como: especificaes, planos de projeto,
arquivos de cdigo fonte, casos e planos
de testes, manuais, arquivos de dados,
entre outros. Cada um desses documentos
produzidos poder ser considerado um
item de configurao de software. A configurao de software composta pelos
itens de configurao produzidos durante
o processo de engenharia de software, ou
seja, no processo de desenvolvimento disciplinado de sistemas (Pressman, 2005).
Os itens de configurao podem sofrer
alteraes ao longo do ciclo de vida do
software, gerando novas verses, e at
mesmo a criao de novos itens. Para
que exista um maior controle no processo de desenvolvimento, e no haja
inconsistncias nos itens considerados
importantes para o projeto, necessrio
que sejam estabelecidas normas para
controlar a criao e alterao dos itens
de configurao. A essas normas d-se
o nome de gerncia de configurao de
software (Tichy, 1994).
Engenharia de Software Magazine - Gerncia de Configurao
Neste artigo so apresentados os principais conceitos de gerncia de configurao de software e

onde esses se encaixam no processo de desenvolvimento de software. Tambm so apresentadas
descries das principais tarefas de gerncia de
configurao de software, tais como definio
e implementao do processo, identificao da
configurao, controle da configurao, relato da
situao da configurao, avaliao da configurao e controle de subcontratados e fornecedores.
Para que serve?

Para que exista um maior controle no processo
de desenvolvimento, e no haja inconsistncias nos itens considerados importantes para o
projeto, necessrio que sejam estabelecidas
normas para controlar a criao e alterao dos
itens de configurao.

O tema til para qualquer equipe envolvido no
desenvolvimento de software que necessite de um
controle mnimo sobre os diferentes artefatos que
so gerados ao longo do desenvolvimento.
Projeto
A gerncia de configurao vem sendo estudada desde os

anos sessenta (Berlack, 1992). Inicialmente, era aplicado da
mesma forma para software e hardware, sendo que no final
dos anos setenta j havia padres de gerncia de configurao
especficos para software.
A gerncia de configurao de software um processo
abrangente, ao mesmo tempo tcnica e gerencial, que se aplica
a todas as atividades de engenharia de software, e pode ser
visto como um dos principais elementos que compem o sistema de garantia de qualidade de uma empresa de informtica
(Leblang, 1988). O processo visa identificar e definir os itens
considerados relevantes ao projeto, controlar as modificaes
dos itens, registrar e reportar a situao dos itens e das requisies das alteraes, garantir a integridade e consistncia dos
itens e controlar o armazenamento, manipulao, liberao e
entrega dos itens (ISO/IEC 12207, 1995).
Os ganhos em tempo e qualidade pela aplicao da gerncia de configurao so comprovados e mensurveis. Esses
ganhos podem ser reconhecidos constatando-se que o uso de
gerncia de configurao de software facilita a comunicao
entre as equipes de desenvolvedores relatando a situao do
software a cada momento, assim como as alteraes que foram
efetuadas. Isso traz como conseqncia a reduo no esforo
necessrio para efetuar alteraes e a reduo no nmero de
erros. O resultado final melhor cumprimento dos cronogramas, reduo nos custos e melhora na qualidade do software
(Berlack, 1992).
Algumas normas e modelos internacionais como a ISO/IEC
12207, ISO/IEC 15504 e o CMMI citam a gerncia de configurao de software como requisito para que uma empresa inicie
a melhoria de qualidade do processo de desenvolvimento de
software. Dessa forma a gerncia de configurao de software
vem ocupando cada vez mais espao no escopo de desenvolvimento de software (Berczuk, 2003).
A implantao da Gerncia de Configurao no costuma ser
fcil (Micallef, 1996). Isso ocorre pela grande diversidade de
normas, padres e modelos que no seguem um mesmo padro
na definio das atividades. O custo de implantao tambm
costuma ser bastante alto, impossibilitando que instituies
com menos recursos realizem a gerncia de configurao de
software (Berczuk, 2003).
Alm disso, devido ao aumento de interesse pela implantao
da gerncia de configurao de software, existem atualmente
no mercado vrias ferramentas que se propem a auxiliar a
execuo de prticas e processos de gerncia de configurao
(Lampen, 1988). No entanto, a maioria dessas ferramentas cobre
apenas uma parte das atividades necessrias para implantao
da gerncia de configurao, confundindo muitas vezes o
usurio leigo que v nessas ferramentas a soluo para todos
os seus problemas de gerncia de configurao.
Neste contexto, neste artigo so apresentados os principais
conceitos de gerncia de configurao de software e onde esses
se encaixam no processo de desenvolvimento de software.
Tambm so apresentadas descries das principais tarefas
de gerncia de configurao de software, tais como definio
e implementao do processo, identificao da configurao,

controle da configurao, relato da situao da configurao,
avaliao da configurao e controle de subcontratados e
fornecedores.
Conceitos Fundamentais
O desenvolvimento de um software pode ser organizado de
vrias formas. A cada uma dessas formas de organizao d-se
o nome de um paradigma de ciclo de vida. Os paradigmas mais
estudados so o clssico, a prototipao, o modelo espiral, as
tcnicas de quarta gerao e os modelos evolutivos tais como
RUP e XP (Pressman, 2005).
Um processo de desenvolvimento de software, independente do paradigma de ciclo de vida adotado, inclui as fases
de engenharia de sistemas, anlise de requisitos, projeto
de software, codificao, testes e manuteno (Pressman,
2005). Na Tabela 1 apresentada uma breve descrio de
cada uma dessas fases.
Fases
Descrio
Engenharia de Sistemas
Coleta dos requisitos em nvel do sistema, com uma pequena

quantidade de projeto e anlise de alto nvel.
Anlise de Requisitos
Compreenso do domnio da informao atravs dos requisitos

coletados na fase anterior.
Projeto de Software
Desenvolvimento de quatro atributos distintos do software: estrutura

de dados, arquitetura de software, detalhes procedimentais e
caracterizao de interfaces.
Codificao
Traduo do projeto de software numa forma legvel para a mquina.
Testes
Realizao de testes dos programas. Esses testes concentram-se nos

aspectos lgicos internos do software e nos aspectos funcionais externos.
Manuteno
Modificaes aps o software ser liberado. Essas mudanas ocorrem

por erros, adaptaes, novos ambientes e novas funcionalidades.
Tabela 1. Fases do Desenvolvimento de Software
Durante o processo de desenvolvimento de um software, uma

grande quantidade de itens de informao produzida. Alguns
desses itens so selecionados de acordo com sua relevncia e
necessidade de controle tanto de verso quanto de mudana.
Esses itens selecionados so chamados itens de configurao
de software e o conjunto dos mesmos compe a configurao
de software (Mahler, 1994).
A criao e as alteraes de cada item de configurao de
software devem ser acompanhadas e controladas pelo gerente
do projeto. Para isso, necessrio o estabelecimento de pontos
bem definidos dentro do processo de desenvolvimento do
software: as Linhas de Referncia (baselines). Esses pontos
podem ocorrer ao final de cada uma das fases do processo
de desenvolvimento de software, ou de algum outro modo
definido pela gerncia.
Nos pontos estabelecidos pelas linhas de referncia, os itens
de configurao devem ser identificados, analisados, corrigidos, aprovados e armazenados como uma configurao de
software. Os itens aprovados so armazenados em um local
sob controle de acesso, denominado repositrio dos itens de
configurao. Esses itens s podero ser alterados aps uma
21
solicitao de mudana formalmente aprovada pelo gerente

de configurao. Essa uma forma de prover controle sobre
a situao de cada um dos itens de configurao, evitando
inconsistncias.
O mtodo utilizado para trabalhar com itens de configurao
que j esto no repositrio chamado de Check In/Check Out
(Bersoff, 1979), ou seja, conferncia na entrada e conferncia
na sada. Quando for desejada uma alterao em algum item
de configurao do repositrio, uma cpia do item colocada
numa rea de trabalho do desenvolvedor (check out). A partir
desse momento, nenhum outro desenvolvedor poder alterar o
mesmo item: a isso d-se o nome de controle de concorrncia.
Dentro de sua rea, o desenvolvedor tem total liberdade de
trabalho. Aps o final das alteraes no item de configurao,
ele ser revisado e recolocado no repositrio (check in). Nesse
momento, uma nova baseline poder ser estabelecida, de modo
que uma nova configurao, contendo o item alterado, seja
formada e armazenada no repositrio (Figura 1).
Figura 1. Controle de concorrncia (check-in / check-out)
Depois do armazenamento e da definio da baseline, o

acesso liberado, permitindo que outros desenvolvedores
possam acessar e tambm executar alteraes sobre esse item
de configurao.
Tarefas de Gerncia de Configurao de Software

As tarefas de gerncia de configurao de software, que
respondem s questes apresentadas na Tabela 2 so descritas a seguir.
Tarefa
Tarefa 1 - Definio e Implementao do Processo

O processo de gerncia de configurao de software deve ser
estabelecido de acordo com uma poltica organizacional definida. Para cada projeto de desenvolvimento de software preciso
elaborar um plano de gerncia de configurao, respeitando
o processo de gerncia de configurao da organizao (IEEE
Std 828, 1998). Quaisquer desvios do processo devem estar
documentados no plano de gerncia de configurao.
Deve ser designado um grupo para ser responsvel pelo
controle da configurao do projeto. Os membros do grupo de
gerncia de configurao devem ser treinados nos objetivos,
procedimentos, e mtodos para desenvolver as atividades de
gerncia de configurao de software.
Tambm preciso prover e adequar recursos para que seja
possvel realizar as atividades de gerncia de configurao,
tais como a disponibilizao de ferramentas para dar suporte
s atividades de gerncia de configurao. Para isso deve ser
designado um gerente com responsabilidades especficas de
gerncia de configurao de software.
Tarefa 2 - Identificao da Configurao
O primeiro passo para a identificao selecionar os itens a
serem gerenciados. Como exemplo, apresentado abaixo uma
srie de itens sugeridos por Pressman (Pressman, 2005):
1. Especificao do Sistema
2. Plano de Projeto de Software
3. Especificao de Requisitos do Software
4. Manual Preliminar do Usurio
5. Especificao do Projeto
a. Descrio do Projeto de Dados
b. Descrio do Projeto Arquitetural
c. Descries do Projeto Modular
d. Descries do Projeto de Interface
e. Descries de Objetos (se forem usadas tcnicas orientadas
a objetos)
6. Listagem do cdigo-fonte
7. Planos, Procedimentos, Casos de Testes e Resultados
Registrados
8. Manuais Operacionais e de Instalao
9. Programa Executvel e Mdulos Interligados
10. Descrio do Banco de Dados
a. Esquema e estrutura de arquivo
b. Contedo inicial
Questes
Definio e Implementao do Processo
Existe uma poltica organizacional definida? Qual o grupo responsvel pelo controle da configurao? Quem ser responsvel pela elaborao
do plano de gerncia de configurao?
Identificao da Configurao
Como uma organizao identifica quais itens entraro na configurao do software?
Controle da Configurao
Quem tem a responsabilidade pela aprovao e pela determinao de prioridades para as mudanas? Como uma organizao controla as
vrias verses geradas pelas mudanas feitas antes e depois que o software liberado?
Relato da Situao da Configurao
Qual o mecanismo usado para avisar outras pessoas sobre mudanas que so feitas?
Avaliao da Configurao
Como se pode garantir que as mudanas foram feitas adequadamente?
Controle de Subcontratados e Fornecedores
Como garantir que mdulos do sistema construdos por terceiros estejam corretos e coerentes com o restante do sistema?
Tabela 2. Tarefas de gerncia de configurao de software
22
Projeto
11. Manual do Usurio

12. Documentos de Manuteno
a. Relatrios de problemas de software
b. Solicitaes de manuteno
c. Pedidos de mudana
13. Padres e procedimentos para engenharia de software
14. Ferramentas de produo de software (editores, compiladores, CASE, etc.)
importante que seja efetuada uma seleo dos itens relevantes,
porque uma super-documentao torna a gerncia de configurao
muito onerosa (Tuscany, 1987). Geralmente, devem sofrer gerncia de
configurao os itens mais usados no ciclo de vida, os mais genricos,
os mais importantes para a segurana, os itens projetados para reuso e
os que podem ser modificados por vrios desenvolvedores ao mesmo
tempo (Bersoff, 1984). Somente os itens selecionados sero controlados,
sendo que os outros itens podero ser alterados livremente.
Aps a seleo, deve-se descrever como esses itens se relacionam. Consideram-se cinco classes de relacionamento: equivalncia (ex: BD em disco rgido e em CD), dependncia (ex: a descrio
do projeto modular dependente da especificao do projeto),
derivao (ex: cdigo objeto derivado do cdigo fonte), sucesso
(ex: a verso 1.2 sucessora da verso 1.1) e variante (ex: verso
para DOS ou para UNIX). A identificao desses relacionamentos muito importante para a manuteno, pois permite que se
localize rapidamente os itens afetados por cada alterao.
Depois de escolhidos os itens e estabelecidos os relacionamentos, deve-se criar um esquema de identificao dos itens
com a atribuio de nomes nicos a cada um dos componentes,
de forma que seja possvel reconhecer a evoluo de cada uma
das verses dos componentes e a hierarquia existente entre
componentes, a partir de seus nomes (Bersoff, 1979).
Um exemplo simples para um pequeno programa cuja sigla
PROG apresentado na Tabela 3. O esquema de identificao
utiliza a combinao de nome do projeto, tipo de item, nome
do item e verso.
Aps o estabelecimento do esquema de identificao, devem
ser planejadas as baselines dentro do ciclo de vida do projeto.
Geralmente, cria-se uma linha de referncia ao final de cada fase
do ciclo de vida do projeto e, periodicamente, depois de cada
manuteno. Deve-se especificar quais itens sero revisados e
armazenados em cada uma das linhas de referncia planejadas.
O ltimo passo da identificao descrever a maneira como os
itens sero arquivados e recuperados do repositrio.
Projeto
Tipo
Especificao do Sistema
Item
PROG
ES
Nome
1.1.0
Verso
PROG_ES_1.1.0
Nome completo
Plano de Trabalho
PROG
PT
1.1.0
PROG_PT_1.1.0
Especificao de Requisitos PROG

Alocados ao Software
ER
1.1.0
PROG_ER_1.1.0
Especificao de Projeto
PROG
EP
1.1.0
PROG_EP_1.1.0
Executvel do Sistema
PROG
PF
EXE
1.1.0
PROG_PF_EXE_1.1.0
Plano e Casos de Testes

Nova verso do Programa
PROG
PROG
TT
PF
EXE
1.1.0
1.1.1
PROG_TT_1.1.0
PROG_PF_EXE_1.1.1
Tabela 3. Identificao dos itens de configurao
Tarefa 3 - Controle da Configurao

Dois controles bsicos so institudos no processo de gerncia
de configurao de software: Controle de Mudanas e Controle
de Verses.
a) Controle de Mudanas
Durante o processo de desenvolvimento de software, mudanas descontroladas podem levar rapidamente ao caos
(Pressman, 2005). Assim, deve ser institudo na organizao
um processo que combine procedimentos humanos e ferramentas automatizadas para proporcionar um mecanismo de
controle das mudanas. Esse processo deve ser implementado
depois que uma linha de referncia for fixada - antes disso
somente um controle de mudanas informal precisa ser aplicado (Bersoff, 1979; Bersoff, 1984; Pressman, 2005). A Figura 2
(Pacheco, 1997) ilustra um processo de controle de mudanas
que pode ser implementado para os itens que j passaram por
uma linha de referncia.
De acordo com esse processo de controle de mudanas,
quando um pedido de mudana solicitado, primeiramente
ele deve ser analisado, gerando um relatrio de mudanas.
Esse relatrio encaminhado para avaliao; se aprovado, o
relatrio de mudana segue para o gerente de configurao. O
Gerente de configurao controla o acesso aos itens no repositrio, liberando-os para a equipe de desenvolvimento para
que a mudana seja efetuada, e recebendo os itens, quando
atualiza o repositrio. Caso o pedido de mudana no seja
aprovado, o relatrio e o pedido so arquivados e dado um
retorno ao solicitante.
Esse controle possibilita que as mudanas sejam efetuadas, comunicadas e incorporadas de um modo disciplinado. Entretanto,
para que esse controle ocorra de forma satisfatria, qualquer
mudana que ocorra nos itens de configurao de software,
aps o estabelecimento de uma linha de referncia, deve seguir
efetivamente sempre o mesmo caminho (Bersoff, 1979).
No processo de controle de mudanas, as alteraes aprovadas so efetuadas de maneira sincronizada. O objetivo dessa
sincronizao evitar que duas pessoas efetuem, ao mesmo
tempo, mudanas incompatveis em um mesmo item, criando
inconsistncias (Bersoff, 1984). O mtodo mais utilizado para
evitar inconsistncias controlar o acesso ao repositrio, de
forma que, quando um desenvolvedor retira um item para
alteraes, ele bloqueia o acesso de escrita no item para os
outros desenvolvedores (Mackay, 1995).
Os procedimentos de controle das mudanas asseguram que
as mudanas em um software sejam feitas de modo controlado,
permitindo-se prever o efeito das mesmas em todo o sistema
(Leblang, 1997). Procedimentos formais de organizao e de
controle das mudanas no sistema permitem que os pedidos
de alterao possam ser considerados em conjunto com outros
pedidos (Honda, 1988). Desse modo, os pedidos similares
podem ser agrupados, e os pedidos incompatveis entre si ou
com os objetivos do sistema identificados. Tambm podem
ser atribudas prioridades aos pedidos e, de acordo com essas
prioridades, pode-se gerar um cronograma (Rigby, 2003).
23
Figura 2. Processo de Controle de Mudanas (Pacheco, 1997)
Figura 3. rvore de revises em um item de configurao, usando delta
b) Controle de Verses
Um item, ao ser desenvolvido, evolui at que atinja um estado em que atenda aos propsitos para o qual foi criado. Isso
implica em diversas alteraes, gerando uma verso do item
a cada estado (Munch, 1996). Para estabelecer o controle sobre
as diversas verses, todas as verses devem ser armazenadas
e identificadas. Isso, geralmente, feito com o auxlio de uma
ferramenta.
A verso do item pode ser includa no esquema de identificao ou ser acessvel a partir de uma tabela parte.
conveniente que o esquema de identificao das verses dos
itens seja feito em forma de rvore, pois ao mesmo tempo
em que mantm um histrico das verses dos itens, permite
identificao nica e ramificaes a partir de qualquer verso
(Figura 3 (Pacheco, 1997)).
Quando um item existe simultaneamente em duas ou mais
formas diferentes que atendam a requisitos similares, temos
variantes do item, representados por ramificaes na rvore.
Um exemplo seria o de duas sub-rotinas para retornar a data do
sistema operacional: uma para Unix e outra para DOS (verses
2.1.1 e 2.2.1 na Figura 3).
Para minimizar o espao de armazenamento das verses
utiliza-se o conceito de delta, ou seja, so armazenadas uma
verso completa e as diferenas entre as verses (Brown, 1991;
Humphrey, 1989). H duas variaes desse conceito: delta
negativo e delta positivo. Com o delta negativo, armazena-se
integralmente a verso mais recente e as diferenas (deltas)
existentes at ento. Com o delta positivo, armazena-se a verso
mais antiga e, para montar as verses mais recentes, processamse as diferenas (deltas) armazenadas (Clemm, 1999)
Os sistemas atuais de gerncia de verses utilizam o conceito
de delta negativo no tronco, por ser mais comum a utilizao
de verses mais recentes do item de configurao (Berczuk,
2003). A Figura 3 representa um caso em que se utiliza delta
negativo. A nica verso armazenada integralmente a 4. As

outras verses so construdas, quando solicitadas, a partir da
4 e das diferenas armazenadas. Utilizam-se deltas negativos
no tronco da rvore, que representa o caminho principal de
evoluo do item. As ramificaes representam as variantes
dos itens e so obtidas pela utilizao de delta positivo.
24
Tarefa 4 - Relato da Situao da Configurao

O objetivo dessa tarefa de gerncia de configurao relatar a todas as pessoas envolvidas no desenvolvimento e na
manuteno do software as seguintes informaes sobre as
alteraes na configurao de software:
a) O que aconteceu?
b) Quem o fez?
c) Quando aconteceu?
d) O que mais ser afetado?
Para isso, deve ser criado um banco de dados sobre as
ocorrncias na gerncia de configurao. Esse banco de
dados deve estar disponvel aos desenvolvedores com
acesso atravs de palavras-chave. Alm disso, deve ser
gerado regularmente um relatrio de situao para informar as alteraes mais importantes. O acesso rpido s
informaes sobre a configurao agiliza o processo de
desenvolvimento e melhora a comunicao entre as pessoas, o que uma maneira de eliminar muitos problemas
relativos modificao do mesmo item de informao, com
intenes diferentes e conflitantes.
Tarefa 5 - Auditoria da Configurao
A identificao e controle das alteraes ajudam a manter
ordem, mas para assegurar que a alterao foi implementada
apropriadamente, h necessidade de auditorias na configurao do software.
Projeto
Existem dois tipos de auditoria de configurao de software que so

pr-requisitos para o estabelecimento das baselines no ciclo desenvolvimento de software: a Auditoria Funcional e a Auditoria Fsica.
A auditoria funcional preocupa-se com aspectos internos dos arquivos, compreendendo uma verificao tcnica formal na configurao
de software, que deve ser realizada ao ser fixada uma baseline. Esta
verificao uma atividade de controle de qualidade que tenta descobrir omisses ou erros na configurao, que degradam os padres
de construo do software (Capretz, 1994; Pressman, 2005).
A auditoria fsica um processo administrativo que ocorre
no final de cada fase do ciclo de vida do software e consiste
em verificar se a configurao que ser baselined, ou seja, far
parte de uma baseline, est composta da verso mais recente
dos itens de configurao, determinados para a fase do ciclo
de vida especfica (Bersoff, 1979; Bersoff, 1984) e se os procedimentos e padres foram devidamente aplicados.
Tarefa 6 - Controle de Subcontratados e Fornecedores
As atividades de controle de subcontratados e fornecedores
coordenam a forma como os itens que foram desenvolvidos por
solicitao a outras empresas ou foram adquiridos j prontos
so testados e incorporados ao repositrio do projeto.
Para itens subcontratados o plano deve descrever:
a) Os requisitos de gerncia de configurao de software a
serem satisfeitos pelo subcontratado;
b) Como ser feito o monitoramento sobre o subcontratado;
c) Como o cdigo, documentao e dados externos sero testados, aceitos e adicionados ao projeto;
d) Como sero tratadas as questes de propriedade do cdigo
produzido, como direitos autorais e royalties.
Referncias
(Pressman, 2005) PRESSMAN, R. S. Software Engineering: a practitioners approach. Mc Graw
Hill Higher Educational, 6. Edio. 2005.
(Mahler, 1994) MAHLER, A. Variants: Keeping things together and telling them apart. In
Configuration Management, Vol. 2 of Trends in Software, Wiley, New York, 1994.
(Bersoff, 1979) BERSOFF, E. H.; Henderson, V. D. e Siegel, S.G. Software Configuration
Management: A tutorial. Los Alamos, Califrnia. IEEE Computer. v.12, n.1, 1979.
(IEEE Std 828, 1998) IEEE for Software Configuration Management Plans. 1998.
(Tuscany, 1987) TUSCANY. P. A. Software development environment for large switching
projects. In Proceedings of Software Engineering for Telecommunications Switching Systems
Conference,1987.
(Bersoff, 1984) Bersoff, E. H. Elements of Software Configuration Management. IEEE Transactions
on Software Engineering, v.se-1.0, n.1, 1984.
(Pacheco, 1997) PACHECO, R. F. Uma Forma de Implantao de Gerenciamento de Configurao
de Software em Empresas de Pequeno Porte. Dissertao (Mestrado) Instituto de Cincias
Matemticas de Computao, Universidade de So Paulo, So Carlos, 1997.
(Mackay, 1995) MACKAY, S. A. The state-of-the-art in concurrent, distributed configuration
management. In Software Configuration Management: Selected Papers SCM-4 and SCM-5
(Seattle, WA, April), J. Estublier, 1995.
(Leblang, 1997) LEBLANG, D.B.: Managing the Software Development Process with
ClearGuide, in Software Configuration Management - ICSE97 SCM-7 Worhxhop, LNCS 1235,
Springer, Berlin, 1997.
(Honda, 1988) HONDA M. Support for parallel development in the Sun network software
environment. In Proc. 8nd International Workshop on Computer-Aided Software
Engineering, 1988.
(Rigby, 2003) RIGBY, K. Software Configuration Management Template. Rigby Publishing
Limited, 2003.
(Munch, 1996) MUNCH, B. HiCOV: Managing the version space. In Software Configuration
Management:ICSE96 SCM-6 Workshop (Berlin,March), Sommerville, 1996.
(Brown, 1991) BROWN, H. Like a Version. Computer Languages, v.8, n.8, 1991.
Para itens adquiridos prontos o plano deve descrever:

a) Como sero recebidos, testados e colocados sob controle de
gerncia de configurao;
b) Como as mudanas no software do fornecedor sero tratadas;
c) Se e como o fornecedor participar no processo de gerncia
de mudana do projeto.
(Humphrey, 1989) HUMPHREY, W. S. Managing the Software Process. 1. Ed. Massachusetts.

Addison-Wesley, 1989.
(Clemm, 1999) CLEMM. G. Versioning Extensions to WebDav. Rational Software, 1999. http://
www.ietf.org/internet-drafts/draft-ietlLwebdav-versioning-02.txt
(Berczuk, 2003) BERCZUK, S. P. Software Configuration Management Patterns. AddisonWesley, 2003.
(Capretz, 1994) Capretz M. A. M.; Munro M. Software Configuration Management Issues in the

Feedback
eu
25
sobre e
s
Neste artigo foram apresentados conceitos gerais e as principais

tarefas de gerncia de configurao de software. Um estudo detalhado das necessidades especficas de cada ambiente de desenvolvimento de software, no que diz respeito gerncia de configurao de software, necessrio para que seja possvel a execuo
das tarefas de forma mais adequada a cada situao.
D
s
Concluses
Maintenance of Existing Systems. Software Maintenance: Research and Practice, v.6, 1994.
edio
ta
Itens de configurao podero ser adquiridos de fornecedores,

subcontratados, clientes, outros projetos ou outras fontes.
Mudanas no PMBoK 4 Edio

Resumo das Principais Mudanas da 3 para a 4 Edio do PMBoK
Paulo Augusto Oyamada Tamaki

paulotamaki@gmail.com.br
Engenheiro de Computao formado com honra ao mrito na

Escola Politcnica da USP. Mestre em Engenharia de Software pelo
departamento de Sistemas Digitais da Escola Politcnica da USP,
cujo tema de mestrado Uma extenso do RUP com nfase no
gerenciamento de projetos do PMBoK baseada em process patterns. Escritor de artigos cientficos e palestrante de congressos e
conferncias na rea de TI. Possui 5 anos de experincia em gerenciamento de projetos de TI voltados para a rea de sade.
26
m edies anteriores da revista,

apresentamos uma viso geral do
PMBoK 3 edio. Periodicamente
o PMI atualiza o contedo deste guia.
Esta atualizao ocorre tipicamente de
quatro em quatro anos e no final de 2008
foi lanado o PMBoK 4 edio.
Este artigo apresentar uma viso geral
das principais mudanas ocorridas entre
a terceira e quarta edio.
Com relao ao contedo, no existe
nenhuma grande mudana na nova
verso. Na quarta edio houve a adio e remoo de alguns processos,
mas reas de conhecimento permanecem as mesmas e a grande maioria dos
processos, entradas e sadas permaneceram inalterados.
A maior parte do esforo foi voltada
para tornar o padro mais consistente
internamente e fazer com que os captulos ficassem mais coerentes parecendo
escritos por uma nica pessoa, em vez
de por um grupo de pessoas.
Alm disso, uma das diretrizes de trabalho na elaborao da nova edio foi
o alinhamento dos conceitos do PMBoK
Engenharia de Software Magazine - Mudanas no PMBoK 4 Edio
Este artigo apresentar uma viso geral das principais mudanas ocorridas entre a terceira e quarta
edio do PMBOK.
Para que serve?

Apresentar o conjunto de atualizaes efetuadas no PMBOK.

Para aqueles que utilizam o PMBOK como referencial para suas atividades profissionais e gostaria de conhecer as novidades de sua nova verso.
com a segunda edio do Standard for

Portfolio Management e do Standard
for Program Management, ambos tambm do PMI.
O Standard for Program Management
define o que gerenciamento de programas alm de descrever os processos
relacionados e o ciclo de vida do gerenciamento de programas dentro de uma
organizao. Um programa um grupo
de projetos relacionados gerenciados de
modo coordenado para obter benefcios e
controle que no estariam disponveis se
fossem gerenciados individualmente.
Planejamento
O Standard for Portfolio Management descreve um conjunto de processos geralmente aceitos no gerenciamento de
portflios. Portflio uma coleo de projetos e/ou programas
que possam ser agrupados para facilitar o gerenciamento do
trabalho para atingir objetivos estratgicos do negcio.
Os dois padres citados acima foram elaborados como uma
expanso da terceira edio PMBoK, por essa razo, houve a
preocupao em alinhar seus conceitos. Os primeiros captulos do PMBoK falam sobre portflio e programas, em muitos
momentos o contedo apresentado muito parecido com o
contedo presente nos padres.
Na quarta edio houve uma mudana geral no quesito
da apresentao, diversos diagramas foram atualizados. Os
diagramas dos processos foram reformulados e deixam mais
claros como funciona o fluxo de entradas e sadas entre os
processos e as dependncias ou relaes entre os processos.
A estrutura de captulos permaneceu inalterada. Os captulos
esto na mesma ordem e apresentam os mesmos objetivos. Para
facilitar a explicao das mudanas, a seguir sero detalhadas as
principais mudanas de cada um dos captulos do PMBoK.
Mudanas no Captulo 1 Introduo

O captulo 1 apresenta uma viso geral do gerenciamento de
projetos e como ele enquadrado em programas, portflios, organizaes e operaes. Como mencionado anteriormente, a principal
questo abordada foi o alinhamento de conceitos entre os padres.
Outra mudana, que na terceira edio havia uma boa discusso sobre a tripla de restries de um projeto: escopo, prazo
e custo. Na quarta edio, o enfoque foi ampliado para outras
restries. Nela existem recomendaes de como os gerentes
de projeto devem balancear as restries de qualidade, escopo,
prazo, oramento, recursos e riscos.
Mudanas no Captulo 2 Ciclo de Vida e Organizao

do Projeto
No houve muitas mudanas no captulo 2. A mais relevante
foi um aumento no contedo do captulo, abordando mais
profundamente temas como o ciclo de vida do projeto e as
fases do projeto, e dos tipos de partes interessadas.
Sobre o ciclo de vida do projeto e das fases do projeto, existem
melhores definies sobre as relaes entre as passagens das
fases. Na edio anterior, havia uma indicao que as fases do
projeto geralmente so seqenciais. Agora so abordados trs
tipos de passagens ou relacionamentos entre fases:
Seqencial: Onde uma fase s pode ser iniciada quando a
anterior for completada.
Sobreposta: Onde uma fase pode ser iniciada antes do trmino da fase anterior. Ou seja, duas fases ficam temporariamente
concorrentes.
Iterativo: Onde o planejamento existe apenas para a fase
atual. O planejamento da prxima fase elaborado durante o
trabalho da fase em andamento
Com relao aos tipos de partes interessadas, houve um detalhamento maior nas descries de cada uma delas. Na quarta
edio temos os seguintes tipos de partes interessadas:
Gerentes de Projeto: Responsvel pelo gerenciamento do

projeto. Clientes/Usurios: A pessoa ou organizao que
utilizar o produto do projeto.
Gerentes de Operao: Indivduo com papel gerencial em
alguma rea operacional chave do negcio. Diferentemente dos
gerentes funcionais, estes gerentes lidam diretamente com a produo e manuteno dos produtos principais da organizao.
Membros da Equipe do Projeto: O grupo que est executando
o trabalho do projeto.
Patrocinador: Pessoa ou grupo que fornece recursos financeiros para o projeto.
Escritrio de Projetos: Organiza e gerencia o controle sobre
todos os projetos dentro da organizao.
Fornecedores/Parceiros: Empresas terceiras que, atravs
de um acordo contratual, fornecem componentes ou servios
necessrios para o projeto.
Gerentes Funcionais: Indivduos com papel gerencial em uma
rea administrativa ou funcional. Como recursos humanos,
financeiro, comercial, etc.
Gerentes de Programas: Responsvel pelo gerenciamento
de programa.
Gerentes de Portflio: Responsvel pelo gerenciamento do
portflio.
Mudanas no Captulo 3 Processos de

Gerenciamento de Projetos de um Projeto
Este captulo introduz um resumo geral dos processos, indicando uma breve descrio do processo, suas entradas e sadas.
Neste captulo j pode ser notada a reduo no nmero total de
processos alm de modificaes nas tabelas de entradas e sadas
de diversos processos. Porm, o detalhamento efetivo das mudanas mais destacado em cada um dos captulos seguintes.
Na edio anterior, existiam 44 processos, enquanto que na edio
atual existem 42 processos. Entretanto, essa reduo no significa
que alguns processos foram considerados obsoletos e descartados.
De forma geral, o que houve foi a consolidao de dois ou mais
processos em um nico processo. Mesmo com essa reduo do total
de processos, ainda foram adicionados dois novos processos.
Uma mudana geral ocorreu nas entradas e sadas. Nenhum
processo do grupo de processos de planejamento utiliza mais o
Plano de Gerenciamento do Projeto com entrada. O entendimento
dos autores que o planejamento ocorre durante todo o projeto e
que o grupo de processos de planejamento no uma fase. Portanto, eles preferiram utilizar as sadas dos outros processos de
planejamento como entrada para o processo Desenvolver Plano
de Gerenciamento do Projeto e no o contrrio. Na edio anterior,
o Plano de Gerenciamento do Projeto era entrada de diversos
processos de planejamento, como Planejar Escopo.
Apesar desta mudana, o Plano de Gerenciamento do Projeto continua uma entrada chave nos processos de execuo e
monitoramento e controle.
Outra mudana foi a adio do conceito Documentos do
Projeto. Os Documentos do Projeto so utilizados para
simplificar diversas tabelas de entradas e sadas de processos. Em cada um dos processos esto representadas
27
as principais entradas e sadas, nos casos em que existem

diversos documentos que opcionalmente possam ser atualizados ou utilizados, o processo indica o uso de Documentos
do Projeto. Na descrio de cada um dos processos, existe
uma seo para os Documentos do Projeto especificando
em maiores detalhes quais documentos podem fazer parte
deste pacote.
Mudanas no Captulo 4 Gerenciamento de

Integrao do Projeto
O total de processos caiu de sete para seis. O processo Desenvolver a Declarao do Escopo Preliminar do Projeto foi eliminado. A razo da remoo que esse processo foi considerado
como parte do processo Definir Escopo atravs do conceito de
elaborao progressiva dos documentos.
Alm disso, houve uma fuso dos documentos: Pedido de
Mudana, Ao Corretiva, Ao Preventiva, e Reparo de Defeito. Todos ficaram agrupados no conceito Pedidos de Mudana.
Onde cada um deles um tipo de Pedido de Mudana.
Mudanas no Captulo 5 Gerenciamento do Escopo do Projeto

A principal mudana foi a adio do novo processo: Coletar
Requisitos.
Coletar Requisitos
O objetivo deste processo definir e documentar caractersticas e funcionalidades do produto necessrias para atender as
necessidades e expectativas das partes interessadas.
As entradas do processo so:
Termo de Abertura: Este documento fornece uma viso de
alto nvel dos requisitos e da descrio do produto.
Registro das Partes Interessadas: Utilizado para identificar
partes interessadas que podem oferecer informaes mais
detalhadas sobre os requisitos do produto ou projeto.
As sadas so do processo so:
Documento de Requisitos das Partes Interessadas: Este
documento descreve como requisitos individuais atendem as
necessidades do negcio.
Plano de Gerenciamento de Requisitos: Este plano define
como os requisitos sero analisados, documentados e gerenciados ao longo de todo o projeto.
Matriz de Rastreabilidade de Requisitos: Tabela que
relaciona os requisitos com sua origem e rastreia ele ao
longo do ciclo de vida do projeto. Seu propsito auxiliar
a garantir que cada requisito agrega valor ao negcio, isto
feito associando cada requisito ao objetivo de negcio ou
de projeto que o originou. Alm disso, ele oferece meios de
rastrear os requisitos, ajudando a garantir que cada requisito
aprovado foi entregue.
Mudanas no Captulo 6 Gerenciamento de Tempo

do Projeto
Nesta rea de conhecimento no houve mudana nos
processos.
28
Engenharia de Software Magazine - Mudanas no PMBoK 4 Edio
Mudanas no Captulo 7 Gerenciamento de Custos

do Projeto
Os processos desta rea de conhecimento permaneceram
inalterados. Entretanto, as entradas e sadas dos processos
Controlar Custos, Controlar Escopo e Controlar Cronograma
esto mais consistentes.
Foi adicionada uma nova ferramenta ou tcnica para o processo Controlar Custos: o ndice de Desempenho de Custo
Futuro (TCPI - To-Complete Performance Index). Este apia a
projeo de viabilidade de se cumprir o oramento.
Mudanas no Captulo 8 Gerenciamento da

Qualidade do Projeto
No houve mudanas nos processos de gerenciamento da
qualidade. Mas foi adicionada uma discusso mais aprofundada sobre os custos da qualidade, e sobre os grficos de controle
da qualidade, em particular dos conceitos de limite superior e
inferior da especificao.
O termo baseline da qualidade foi removido.
Mudanas no Captulo 9 Gerenciamento de Recursos

Humanos do Projeto
Os processos do gerenciamento de recursos permaneceram
iguais. A nica modificao que o processo Gerenciar Equipe
do Projeto foi movido do grupo de processos de monitoramento
e controle para o grupo de processos de execuo.
Uma mudana menor foi uma discusso mais abrangente
sobre habilidades interpessoais nos processos Desenvolver
Equipe do Projeto e Gerenciar Equipe do Projeto.
Por fim, foi adicionada uma discusso sobre as etapas de
montagem de equipe, gerenciamento de conflitos, liderana,
influncia e tomada de deciso.

Comunicaes do Projeto
Nesta rea de conhecimento, foi adicionado um novo processo de iniciao: Identificar as Partes Interessadas.
Identificar as Partes Interessadas
Este processo tem como objetivo identificar todas as pessoas ou
organizaes afetadas pelo projeto, alm de documentar informaes relevantes a respeito de seus interesses, envolvimento e
impacto sobre o sucesso deste projeto. A identificao das partes
interessadas essencial para aumentar a probabilidade do sucesso do projeto. De modo geral, importante analisar o nvel de
interesse, expectativas, importncia e influncia de cada parte
interessada, pois com essas informaes pode ser elaborada
uma estratgia sobre quando e como uma determinada parte
interessada pode contribuir mais positivamente no projeto.
As entradas deste processo so:
Termo de Abertura: O Termo de abertura fornece informaes sobre grupos e contatos internos e externos ao projeto que
podem afetar ou estar envolvidos com o projeto.
Documentos de Aquisio: Se o projeto tiver um contrato externo,
as partes envolvidas no contrato so partes interessadas chave.
Planejamento
O processo conhecido na terceira edio como Gerenciar as

Partes Interessadas foi renomeado para Gerenciar as Expectativas das Partes Interessadas e movido do grupo de processos de monitoramento e controle para o de execuo.
Mudanas no Captulo 11 Gerenciamento de Riscos

do Projeto
Nesta rea de conhecimento, os processos no foram alterados e no ocorreu nenhuma mudana significativa.

Aquisies do Projeto
No gerenciamento de aquisies do projeto, seis processos
foram consolidados em quatro. Os processos agora so:
Planejar Aquisies: o processo de documentar as decises
de compra no projeto, a abordagem, e a identificao de potenciais fornecedores. Ele registra as necessidades do projeto que
sero mais bem resolvidas adquirindo produtos ou servios
externos equipe do projeto.
Conduzir Aquisies: Processo de obter propostas de fornecedores, selecionar fornecedores e estabelecer o contrato.
Administrar Aquisies: Processo responsvel por gerenciar o contrato, monitorar o andamento do contrato e realizar
mudanas e correes conforme necessrias.
Encerrar Aquisies: o processo de finalizar cada um dos
contratos do projeto. Ele envolve a verificao de que todos os
servios e entregas externos foram aceitos.
Apndice
um fato que os conhecimentos e necessidades do gerenciamento de projetos evoluem com o tempo. Nesse contexto,
as atualizaes do PMBoK so necessrias e tm se mostrado
alinhadas com as novas necessidades e experincias.
O novo processo Coletar Requisitos apresenta um uso direto para
atividades de anlise de requisitos de desenvolvimento de software.
Ao observar o RUP (Rational Unified Process), este processo
alinhado com as atividades existentes na disciplina de requisitos. As sadas deste processo so anlogas a diversos artefatos
presentes no RUP tambm. Por exemplo, o plano de gerenciamento de requisitos pode incluir o processo de priorizao de
requisitos, que uma das principais atividades do RUP.
Sob a perspectiva do CMMI, diversas prticas recomendadas na terceira edio PMBoK auxiliavam na implementao
de alguns de seus processos. A adio do processo Coletar
Requisitos traz o PMBoK ainda mais prximo do CMMI, pois
auxilia na implementao do processo Desenvolvimento de
Requisitos deste modelo de qualidade.
Finalmente, a expanso dos tipos de relacionamento entre fases
do projeto alinhada com necessidades ou opes de desenvolvimento comuns no desenvolvimento de software. O modelo iterativo de relacionamento entre fases til para projetos em ambientes
volteis, com incertezas, ou muito indefinidos. Sua dificuldade o
planejamento de longo prazo ou o controle de escopo. Em muitos
casos, estes cenrios so encontrados quando empregamos em
mtodos geis de desenvolvimento, por exemplo.
Se o PMBoK j era um guia com aplicao direta ao desenvolvimento de software, as suas atualizaes tornam claro que a
quarta edio apresenta uma srie de melhorias com benefcios
diretos para o gerenciamento deste tipo de projetos. Porm, importante ter em mente que sua aplicao no precisa ser uniforme
em todos os projetos. Dependendo da organizao ou do projeto,
seus processos e documentos devem ser adaptados para serem
apropriados para a cultura ou necessidades envolvidas.
Feedback
eu
29
sobre e
s
A quarta edio apresenta um novo apndice sobre habilidades interpessoais. Nesse apndice esto informaes consideradas pelos autores como importantes para o gerenciamento de
um projeto, porm que no eram consistentes com as intenes
de um padro. As habilidades apresentadas so:
Liderana: desenvolver uma viso e uma estratgia e motivar
as pessoas para que alcancem essa viso e essa estratgia;
Montagem de Equipe: capacidade de montar a equipe considerando os perfis adequados ao trabalho do projeto;
Concluso
D
s
As sadas deste processo so:

Registro das Partes Interessadas: documenta as seguintes informaes sobre cada uma das partes interessadas: Nome, cargo,
papel no projeto, informaes de contato, principais requisitos,
principais expectativas, influncia potencial no projeto, e eventuais classificaes (ex.: interno/externo, a favor/neutro/contra).
Estratgia de Gerenciamento das Partes Interessadas: Define
uma abordagem ou estratgia para aumentar o apoio e minimizar os impactos negativos das partes interessadas ao longo
do ciclo de vida do projeto.
Motivao: estimular as pessoas para que alcancem altos nveis de

desempenho e superem as barreiras que impedem as mudanas;
Comunicao: capacidade de trocar informaes;
Influncia: a capacidade de fazer com que as coisas
aconteam;
Tomada de Deciso: capacidade em tomar deciso a partir
de um cenrio atual;
Conscincia poltica e cultural: capacidade de respeitar os
limites impostas por questes polticas e culturais;
Negociao: Conversar com outras pessoas para chegar a
um entendimento ou um acordo.
edio
ta
Ativos de Processos Organizacionais: Eventuais lies aprendidas em projetos anteriores, ou tipos de partes interessadas conhecidas, registros de partes interessadas de projetos anteriores.
Fatores Ambientais da Empresa: Cultura e estrutura organizacional, ou padres governamentais ou de indstria.
Gerenciamento de Mudanas em Projetos de TI

Gesto de mudanas utilizando o PMBoK e a ferramenta Rational ClearQuest
D
Felipe La Rocca Teixeira
felipe.lt@pjf.mg.gov.br
Ps-Graduado em Gesto de Projetos - PMI,

Bacharel em Sistemas de Informao, Analista de Sistemas da Prefeitura de Juiz de
Fora e possui certificaes MCITP Database
Administrator, MCITP Business Intelligence
Developer e OCA 10g.

maraujo@cesjf.br
Doutor e Mestre em Engenharia de Sistemas

e Computao pela COPPE/UFRJ, Especialista
em Mtodos Estatsticos Computacionais e
Bacharel em Informtica pela UFJF, Professor
e Coordenador do Curso de Bacharelado em
Sistemas de Informao do Centro de Ensino
Superior de Juiz de Fora (CES/JF), Analista de
Sistemas da Prefeitura de Juiz de Fora.
30
evido ao rpido avano da

tecnologia, o desenvolvimento
e a manuteno de projetos de
software tornou-se algo difcil e complexo. Toda essa nova tecnologia tambm
gera um aumento de novas solicitaes
e expectativas ao longo de todas as fases
de um projeto de TI. Por isso, para que
se possa elaborar um projeto e realizar
servios de qualidade, necessrio no
somente uma equipe tcnica competente, mas a utilizao de mtodos e
processos que contemplem as melhores
prticas para a gesto de TI.
Ao longo do ciclo de vida de um projeto,
modificaes so inevitveis, podendo
ocorrer desde mudanas no escopo do
projeto, alteraes dos requisitos levantados, correes de defeitos ou melhorias.
Essas modificaes podem exigir ajustes
no plano de gerenciamento do projeto, na
declarao do escopo ou em outras entregas do projeto. Seguindo as melhores
prticas do PMBoK (Project Management
Engenharia de Software Magazine - Gerenciamento de Mudanas em Projetos de TI
Este artigo procura apresentar processos que garantam um controle completo das modificaes
em todo o clico de vida de um projeto de TI, realizando-a com um risco mnimo, permitindo assim,
um aumento da qualidade e a reduo dos riscos e
custos relativos a estes projetos.
Para que serve?

Para que serve: O artigo demonstra como modificaes podem ser gerenciadas em um projeto de
TI, alm dos benefcios alcanados como a reduo do impacto de mudanas sobre a qualidade
do projeto, e isto pode ser alcanado atravs do
uso de ferramentas para a gesto de mudanas
como o Rational ClearQuest.

Gerenciamento de mudanas em projetos de TI,
como o desenvolvimento de softwares.
Body of Knowledge), o processo de Controle Integrado de Mudanas, pertencente

rea de conhecimentos de Gerenciamento da Integrao, o responsvel pela
aprovao e monitorao das mudanas
solicitadas. Esse processo ser mais bem
detalhado no decorrer deste artigo.
projeto
Gerenciamento de Projetos com o PMBoK

Gerenciar um projeto significa, resumidamente, planejar a
sua execuo antes de inici-lo e, posteriormente acompanhar
a sua execuo e controle. Algumas prticas gerenciais, quando
bem aplicadas, contribuem para a melhoria da qualidade da gerncia de um projeto. Os processos de desenvolvimento atuais
sugerem a adoo de abordagens iterativas e incrementais.
Com a utilizao do gerenciamento de projetos, alguns benefcios podem ser alcanados, dentre eles, evitar que surpresas
durante a execuo dos trabalhos aconteam, antecipar situaes
desfavorveis, desde que aes preventivas e corretivas sejam
tomadas antes que estas situaes se tornem um problema para
o projeto, disponibilizar os oramentos antes do incio dos trabalhos, gerar documentao no intuito de facilitar estimativas
para futuros projetos, bem como outros benefcios.
O PMBoK, desenvolvido pelo PMI (Project Management
Institute), um guia prtico para gesto de projetos de qualquer natureza, inclusive para projetos da rea de TI, como por
exemplo, o desenvolvimento de software. A aplicao de seus
processos, conhecimentos e tcnicas buscam atender ou superar as expectativas de todos os envolvidos em um projeto.
Criado em 1969, com sede na Filadlfia, Pensilvnia, o PMI
define um projeto como sendo um esforo temporrio empreendido para criar um produto, servio ou resultado exclusivo.
Temporrio porque todos os projetos possuem um incio e um
fim definidos, no importando o seu tamanho, podendo ser de
curta ou de longa durao. Exclusivo por tratar da singularidade destes elementos, ou seja, onde cada produto ou servio
possuem caractersticas especificas que os diferenciam.
O PMBoK analisa o gerenciamento de um projeto da seguinte
maneira:
Diviso do projeto em fases, Ciclo de Vida;
Em cada fase ocorrem processos;
Em cada processo so executadas aes gerenciais que contemplam nove reas de conhecimento.
Ciclo de Vida de um Projeto:
Um ciclo de vida caracterizado por vrias fases distintas,
certamente dependendo do tipo de projeto (construo e desenvolvimento de software, entre outros), onde suas fases possuem
particularidades prprias. Em cada fase de um projeto so
executados diversos processos com o objetivo de produzir o
resultado esperado daquela fase.
O ciclo de vida do projeto define o incio e o fim do projeto
e tambm qual trabalho tcnico deve ser realizado em cada
fase e quem deve estar envolvido nelas. A transio de uma
fase para outra ocorre normalmente atravs de alguma forma
de transferncia tcnica ou entrega. As entregas de uma fase
so revisadas para garantir que estejam completas e exatas,
e aprovadas antes que o trabalho seja iniciado na prxima
fase. Mas pode acontecer que uma fase seja iniciada antes da
aprovao das entregas da fase anterior, e isto pode ocorrer
quando os riscos envolvidos so considerados aceitveis. De
acordo com o PMBoK, os ciclos de vida de um projeto geralmente definem:
Qual trabalho tcnico deve ser realizado em cada fase,

por exemplo, em qual fase deve ser realizado o trabalho
de um programador em um projeto de desenvolvimento
de software;
Em que momento do projeto as entregas devem ser geradas em
cada fase e como cada entrega revisada, verificada e validada;
Quem est envolvido em cada fase. Por exemplo, no desenvolvimento de um software, exige-se que os programadores estejam envolvidos com a implementao e o teste
do software;
Como controlar e aprovar cada uma das fases;
As descries do ciclo de vida do projeto.
Processos da Gerncia de Projeto:
Em cada fase de um projeto so executados diversos processos com o objetivo de produzir o resultado esperado daquela
etapa. Conforme definido pelo PMBoK, esses processos se
enquadram nos seguintes grupos (ver Figura 1):
Processo de Inicializao: a fase inicial do projeto, onde o
objetivo do projeto definido, bem como as melhores estratgias so identificadas e selecionadas;
Processo de Planejamento: a fase responsvel em detalhar
e descrever tudo aquilo que ser realizado pelo projeto, incluindo a definio do escopo, estrutura analtica do projeto,
estimativas, anlise de custos e outros;
Processo de Execuo: a fase onde se materializa tudo o
que foi planejado na fase anterior. Qualquer erro cometido
anteriormente fica evidente durante essa fase;
Processo de Monitoramento & Controle: a fase de acompanhamento e controle de tudo o que est sendo realizado
pelo projeto. Assim, pode-se garantir que seus objetivos sejam
alcanados atravs da monitorao e da mensurao de seu
progresso, ao se tomar aes corretivas e proativas sempre
que houver necessidade;
Processo de Encerramento: a fase onde a execuo dos
trabalhos avaliada junto ao cliente ou patrocinador, e ocorre
seu encerramento de forma ordenada.
Figura 1. Grupos de processos de gerenciamento de projetos (PMBoK)
31
reas de Conhecimento:
As reas do gerenciamento de projetos descrevem o gerenciamento em termos de seus processos componentes. Esses processos
esto organizados em nove grupos integrados (ver Figura 2).
O Gerenciamento da Integrao define os processos necessrios
para assegurar a integrao de todas as demais reas de conhecimento. Seu objetivo estruturar todo o projeto de modo a garantir
que os diversos elementos do projeto sejam adequadamente coordenados. Seus processos constantes so: desenvolver o termo de
abertura do projeto, desenvolver a declarao do escopo preliminar do projeto, desenvolver o plano de gerenciamento do projeto,
orientar e gerenciar a execuo do projeto, monitorar e controlar o
trabalho do projeto, controle integrado de mudanas (esse ser mais
bem detalhado no decorrer deste artigo) e encerrar o projeto.
O Gerenciamento do Escopo responsvel pelos processos
necessrios para garantir que o projeto contemple somente
aquilo que necessrio para ser concludo com sucesso, sem
abandonar nenhuma funo estabelecida no objetivo do projeto. Seus processos so: o planejamento do escopo, definio
do escopo, criar a estrutura analtica do projeto, verificao
do escopo e controle do escopo.
O Gerenciamento do Tempo consiste em processos necessrios para garantir que o projeto termine dentro do seu prazo
estipulado. Trabalha na definio da atividade, sequenciamento de atividade, estimativa de recursos da atividade, estimativa
de durao da atividade, desenvolvimento do cronograma e
controle do cronograma.
O Gerenciamento do Custo define processos necessrios
para assegurar que o capital disponvel seja suficiente para
concluir o projeto dentro do oramento previsto. Seus principais processos so: estimativa de custos, oramento e o
controle de custos.
O Gerenciamento dos Recursos Humanos so os processos necessrios para garantir o melhor uso das pessoas envolvidas no
projeto. Os processos constantes so: planejamento de recursos
humanos, contratar ou mobilizar a equipe do projeto, desenvolver a equipe de projeto e gerenciar a equipe do projeto.
O Gerenciamento dos Riscos define os processos relacionados
identificao, anlise e resposta aos riscos do projeto. responsvel pelos processos de planejamento do gerenciamento
de riscos, identificao de riscos, anlise qualitativa de riscos,
anlise quantitativa de riscos, planejamento de respostas a
riscos e monitoramento e controle de riscos.
O Gerenciamento das Comunicaes responsvel em
assegurar que todas as informaes do projeto cheguem s
pessoas certas de forma adequada e no tempo certo. Seus
processos so: planejamento das comunicaes, distribuio
de informaes, relatrio de desempenho e gerenciamento das
partes interessadas.
O Gerenciamento das Aquisies so os processos necessrios para garantir a aquisio de bens e servios fora da
organizao. Seus processos constantes so: planejar compras
e aquisies, planejar contrataes, solicitar respostas de fornecedores, selecionar fornecedores, administrar contratos e o
encerramento do contrato.
32
Figura 2. reas de Conhecimentos (PMBoK)
Gerenciamento de Mudanas
Ao longo de todo o ciclo de vida de um projeto, diversos
desafios so encontrados. Mtodos, processos, tcnicas e
ferramentas devem ser integrados no intuito de apoiar o
desenvolvimento de um projeto de TI, como por exemplo,
o desenvolvimento de software. O processo de mudanas
algo inevitvel em um projeto, e isto deve ser gerenciado de
forma efetiva atravs de planejamento, ou seja, preciso detalhar como o processo de mudanas ir acontecer. Para que
isso ocorra da maneira correta, algumas questes devem ser
respondidas, tais como:
Como solicitar mudanas no projeto?
Para onde encaminhar as solicitaes?
Quem as analisa?
Com que freqncia?
De que forma?
Sem um gerenciamento definido de mudanas impossvel
garantir que as alteraes propostas estejam de acordo com os
objetivos do projeto. Segundo o PMBoK, o processo Controle
Integrado de Mudanas (pertencente rea de conhecimentos Gerenciamento da Integrao do Projeto) tem como seu
objetivo principal a aprovao de mudanas solicitadas, de
no-conformidades recomendadas e de reparos de defeitos
recomendados, observados nas fases de monitoramento e
controle do projeto.
Entretanto, o gerenciamento de mudanas em um ambiente
de servios TI, controlada pelo processo de Gerenciamento
de Alteraes pertencente rea de Suporte de Servios da
ITIL. Este processo trata da requisio, avaliao, autorizao e
implementao de mudanas em servios de TI, visando gerar
o menor impacto possvel para a organizao em relao a mudanas e minimizar possveis interrupes destes servios.
projeto
Controle Integrado de Mudanas - PMBoK

O processo Controle Integrado de Mudanas realizado
desde o incio do projeto at o seu trmino. Mudanas no
decorrer dos projetos so inevitveis, e raramente a sua
execuo segue com exatido o plano de gerenciamento
do projeto.
A importncia deste processo se faz necessria, uma vez
que sempre h diferena entre o planejado e o realizado,
alm do controle de mudanas atravs de um gerenciamento
contnuo, cabendo a esse processo rejeitar ou aceitar tais
mudanas. Para que isso ocorra, esse processo inclui as
seguintes atividades de gerenciamento de mudanas em
nveis diferentes de detalhes:
Identificar que uma mudana precisa ocorrer ou ocorreu;
Controlar fatores que poderiam dificultar o controle integrado de mudanas de forma que somente mudanas aprovadas
sejam implementadas;
Revisar e aprovar as mudanas solicitadas;
Gerenciar as mudanas aprovadas quando e como ocorrem,
regulando o fluxo de mudanas solicitadas;
Manter a integridade das linhas de base liberando somente
as mudanas aprovadas para serem incorporadas aos produtos
ou servios do projeto e manter sua configurao e sua documentao de planejamento relacionada;
Revisar e aprovar todas as aes preventivas e corretivas
recomendadas;
Controlar e atualizar o escopo, custo, oramento, cronograma e requisitos de qualidade, de acordo com as mudanas
aprovadas, atravs de um controle das mudanas em todo o
projeto;
Documentar o impacto total nas mudanas solicitadas;
Validar o reparo de defeito;
Controlar a qualidade do projeto de acordo com as normas,
com base nos relatrios de qualidade.
O gerenciamento de configurao com controle de mudanas
disponibiliza um processo eficaz, eficiente e padronizado para
gerenciar de maneira centralizada mudanas em um projeto.
Esse gerenciamento inclui a identificao, documentao e
controle das mudanas realizadas. O nvel aplicado de controle

de mudanas depende da rea de aplicao, da complexidade
do projeto, dos requisitos levantados e do contexto e ambiente
em que o projeto ser desenvolvido.
Segundo o PMBoK, a aplicao do gerenciamento de configurao com controle de mudanas em todo o projeto deve
realizar trs objetivos principais, que so:
Estabelecer um processo evolutivo para identificar e solicitar
mudanas de forma consistente e avaliar a importncia e a
eficcia dessas mudanas;
Oferecer oportunidades para validar e melhorar continuamente o projeto, considerando o impacto de cada mudana;
Fornecer um mecanismo para que a equipe de projeto possa
comunicar todas as mudanas de forma consistente e exata
para as partes interessadas.
Atividades relacionadas ao Controle Integrado de Mudanas
Todas as mudanas solicitadas e documentadas devem ser
aceitas ou rejeitadas por uma autoridade de dentro da equipe
do projeto ou pelo iniciador, patrocinador ou cliente. O processo de controle integrado de mudanas muitas vezes inclui
um comit de controle de mudanas, que o responsvel em
aprovar ou rejeitar as mudanas solicitadas. As responsabilidades e funes desses comits so definidas no processo de
controle de mudanas e com a participao do patrocinador,
cliente e outras partes interessadas.
As atividades realizadas pelo controle integrado de mudanas podem ser divididas em Entradas, Ferramentas e Sadas
(ver Figura 3).
Uma das principais entradas desse processo refere-se s mudanas solicitadas, e essas, por sua vez, podem ser aprovadas
ou rejeitadas. As solicitaes de mudana aprovadas referemse quelas mudanas que foram solicitadas, recomendadas e
aprovadas, como por exemplo, ampliar ou limitar o escopo do
projeto. As solicitaes de mudanas rejeitadas se referem s
mudanas solicitadas que podem gerar alteraes crticas para
o projeto, e aquelas que no so factveis de implementao por
vrios outros fatores, como por exemplo, a no-conformidade
com o escopo do projeto.
Figura 3. Entradas, ferramentas e sadas do Controle de Mudanas - PMBoK
33
Em relao s ferramentas e tcnicas utilizadas neste processo, pode-se destacar o sistema de informaes de gerenciamento de projetos. O uso de ferramentas, no intuito de automatizar
esse processo, utilizado pela equipe de gerenciamento de
projetos para auxiliar na implementao de um processo de
controle integrado de mudanas do projeto, facilitar o feedback
do projeto e controlar as mudanas em todo o projeto.
Ferramentas para a Gesto de Mudanas

No objetivo do gerenciamento de mudanas evitar modificaes, mas sim permitir que ocorram de maneira controlada. Esse controle pode acontecer atravs do uso de vrias
ferramentas existentes no mercado e, dessa forma, permitir
o rastreamento dessas mudanas e identificar o impacto no
projeto como um todo.
O uso de ferramentas conhecidas como Bug Tracking possibilita a melhoria dos processos utilizados no desenvolvimento
e manuteno de produtos de software e projetos da rea
de TI. Essas ferramentas precisam oferecer processos para
identificar, analisar, rastrear e controlar mudanas, alm de
permitir que usurios faam o acompanhamento completo
dos pedidos de alteraes sobre erros encontrados em sistemas. No mercado, existem vrias ferramentas open source
de Bug Tracking disponveis, tais como o Bugzilla e o Trac,
e em relao s ferramentas comerciais pode-se destacar o
Rational ClearQuest.
O Rational ClearQuest uma ferramenta de Bug Tracking
que busca um monitoramento flexvel de mudanas e defeitos,
automao de processo, elaborao de relatrios e rastreabilidade, visando uma melhor visibilidade e controle do ciclo
de desenvolvimento de um software. Como essa ferramenta
pode se ligar ao cdigo fonte de um projeto de TI, possvel
de maneira simples cadastrar e acompanhar defeitos e mudanas, bem como controlar qualquer outro tipo de servio
realizado pela a equipe de desenvolvimento. No intuito de
facilitar o aprendizado dessa ferramenta, a Rational ClearQuest disponibiliza um projeto completo com registros de
defeitos e usurios j pr-cadastrados, e para que se possa
utilizar este projeto de exemplo, deve-se marcar a opo
Create sample database, selecionar o valor Enterprise para
o campo Schema e informar o valor SAMPL para o campo
Database Name. Com isso, vrias informaes referentes a
pedidos de alteraes, defeitos e usurios sero gravadas no
banco de dados de exemplo.
No intuito de demonstrar na prtica a utilizao da ferramenta Rational ClearQuest em um projeto de TI, este artigo
ir apresentar todos os passos necessrios para um efetivo
controle de mudanas, demonstrando desde a criao de um
registro de defeito, suas alteraes, at a sua soluo e criao
de consultas (ler Nota 1).
Nota 1
Para a construo deste exemplo, ser necessrio a instalao do Microsoft Access e a
ferramenta Rational ClearQuest.
34
Ao utilizar o Rational ClearQuest, primeiramente devese criar um repositrio de dados comum, visando oferecer
s equipes de desenvolvimento acesso rpido e seguro s
informaes referentes ao projeto. Para este exemplo, ser
necessrio definir duas bases de dados para a gravao
das informaes, uma para a base principal e outra para
a base de exemplo, configurada pela prpria ferramenta. Para isso, deve-se ir ao menu Iniciar > IBM Rational
ClearQuest > Ferramenta de Manuteno do ClearQuest
e, na tela IBM Rational ClearQuest Maintenance Tool,
clicar no boto Create para criar um novo repositrio de
dados, nome-lo como Stage e fazer as configuraes
apresentadas na Figura 4. No campo Feature Level deve-se
informar qual verso do Rational ClearQuest est sendo
usado, nesse caso, a verso 7.1. No campo Vendor devese definir qual o tipo de banco de dados ser utilizado
para a gravao dos dados, desta forma, deve-se definir o
Microsoft Access. Por ltimo, no campo Physical Database
Name deve-se informar o nome para o banco de dados
como Master.mdb.
Figura 4. Visualizao da Janela do IBM Rational ClearQuest Maintenance Tool
Continuando com a configurao do repositrio de dados,

aps clicar em Avanar, na prxima janela deve-se definir
qual Data Code Page ser utilizado, ou seja, o conjunto de
caracteres que sero suportados pela base de dados. Para isso,
deve-se selecionar o valor 1252 (MS Windows Latin1) e clicar
em Avanar.
Por ltimo, devem-se definir as propriedades do banco de
dados de exemplo. No campo Vendor, para o tipo de banco
de dados, informar Microsoft Access e, em Physical Database
Name, informar o nome do banco como Sample.mdb. Para
finalizar, deve-se clicar em Concluir.
Agora, com o repositrio de dados criado e devidamente
configurado, para conectar-se base de dados de exemplo
utilizando a ferramenta Rational ClearQuest, deve-se clicar em
menu Iniciar > IBM Rational ClearQuest > ClearQuest Client e
em Arquivo > Banco de Dados > Conectar > Nova Conexo. Na
janela Repositrio do Esquema, deve-se selecionar o repositrio
projeto
Stage criado anteriormente e clicar em Avanar. Na prxima

janela, deve-se informar o Id de usurio, como admin, este
usurio j criado por default pela ferramenta e possui todos
os privilgios necessrios para administrar um projeto no
Rational ClearQuest. Ao continuar com a configurao, agora
na janela Conectar, deve-se deixar a senha do usurio admin
em branco, selecionar o valor SAMPL no campo Banco de
Dados e clicar em Ok para finalizar a conexo (ver Figura 5).
importante destacar que, por default, a senha do usurio admin
vem em branco, mas se for necessrio acrescentar uma senha
para este usurio, deve-se ir ao menu Iniciar > IBM Rational
ClearQuest > Administrao de Usurio ClearQuest, selecionar o usurio desejado e definir uma senha para ele.
maneira til de identificar os tipos de controles de mudanas

atravs da utilizao de palavras-chave nas definies de
consultas de modo que estas retornem registros que tenham
as palavras-chave correspondentes. J no campo Symptoms
podem-se definir sintomas que ocorrem rotineiramente, facilitando o diagnstico do problema. Para finalizar, possvel
acrescentar uma descrio para o problema, para isso, digitar
no campo Description o texto Os valores totais do relatrio
de Vendas esto sendo exibidos incorretamente. Ao clicar em
OK esse registro de defeito ser gravado no banco de dados
do projeto.
Figura 5. Criao de uma conexo com o

banco de dados no Rational ClearQuest
Figura 6. Visualizao da Janela para cadastar um defeito
As equipes de desenvolvimento utilizam controles de mudanas para registrar defeitos, pedidos de aprimoramento para
recursos existentes e pedidos de novos recursos, sendo que o
Rational ClearQuest armazena estes controles como registros
em um banco de dados. Desta forma, para que se possa registrar um defeito, deve-se selecionar Arquivo > Novo > Defect.
Nesta janela, pode-se destacar que atribudo um nmero ID
de registro para esse controle de mudana e seu estado por
default aparece como Submetido, alm dos nomes de campos
obrigatrios aparecem em vermelho.
Assim, para poder cadastrar um registro de defeito, devese digitar as informaes levantadas, conforme Figura 6. Na
aba Main, em Headline, deve-se definir o ttulo do defeito
como Valores totais incorretos no relatrio de Vendas. Nos
campos Priority e Severity sero definidas as prioridades e
severidades desse defeito, onde os valores esto ordenados
do estado mais crtico para o menos crtico, neste caso,
deve-se selecionar 2-Give High Attention e 2-Major,
pois o defeito no ir causar uma interrupo do sistema,
mas pode ocasionar problemas por disponibilizar uma
informao errada.
Tambm possvel acrescentar informaes adicionais ao
registro do defeito como no campo Keywords, que fornece uma
Se for necessrio realizar alguma alterao no registro do

defeito cadastrado pela equipe de suporte, como por exemplo, acrescentar novas informaes referentes ao problema
identificado basta selecionar Editar > Localizar Registro >
admin,Stage@SAMPL. Na janela Localizar Registro, deve-se
selecionar o tipo de registro e informar o ID do defeito que se
deseja abrir. Para este exemplo, deve-se selecionar Defect e o
valor do ID SAMPL00000051. Para facilitar, no necessrio
digitar o prefixo e os zeros esquerda do ID para localizar o
registro (ver Figura 7).
Aps localizar o defeito desejado, a janela Visualizar Defect
ser aberta, mas todos os seus campos estaro desabilitados.
Para habilitar os campos para que sofram alteraes, deve-se
clicar no boto Modify e, dessa forma, todos os campos da janela ficaro habilitados para sofrerem as alteraes necessrias.
Agora, no campo Description deve-se acrescentar a informao
Este problema acontece todas as vezes que se utiliza a opo de
desconto no filtro do relatrio de Vendas. Tambm possvel
adicionar um arquivo anexo para o registro de defeito, visando
assim, facilitar a correo do problema e, para isso, na aba Attchments pode-se incluir qualquer tipo de arquivo, tal como, um
print screen da tela com o problema citado anteriormente.
35
Figura 7. Visualizao da Janela para consultar um registro de defeito
Com isso, pode-se observar que o Rational ClearQuest

comea a realizar um controle de todas as modificaes
sofridas pelo registro do defeito. At agora, o defeito
continua com o estado de Submitted, ou seja, apenas
cadastrado, e para poder mudar esse estado inicial,
designando-o a um profissional para a soluo desse
defeito, deve-se abrir o registro de defeito novamente.
Agora, na janela Visualizar Defect deve-se clicar no boto Assign e na aba Main alterar os valores dos campos
Priority para 1-Resolve Immediately e Owner para engineer, desta forma, este defeito passa a ter a prioridade
mais alta e um profissional responsvel para a correo
deste problema, e seu estado passa a ser Assigned (ver
Figura 8). O usurio engineer, um usurio de exemplo
que j vem cadastrado no banco de dados SAMPL que
contm vrios dados de registros de defeitos e de informaes de usurios cadastrados, alm de exemplos de
consultas e relatrios, auxiliando o aprendizado nesta
ferramenta.
que as prximas alteraes deste registro s podero ser

realizadas pelo desenvolvedor responsvel pela correo
do problema. Desta forma, assim que o erro encontrado
no relatrio de Vendas for corrigido pelo profissional,
esta correo deve ser informada ao registro do defeito no
ClearQuest. Para isso, deve-se abrir o registro do defeito
no ClearQuest Client em Editar > Localizar Registro >
admin,Stage@SAMPL. Na aba Resolution, informar o valor
Fixed no campo Resolution, para definir que o problema
foi resolvido com sucesso e clicar no boto Resolved para
finalizar esse registro de defeito.
Com estes passos, pode-se demonstrar a transio do defeito de um estado para o outro ao se utilizar a ferramenta
Rational ClearQuest. Na aba History da janela Visualizar
Defect, pode-se visualizar toda a evoluo de modificaes
sofridas pelo defeito. O Rational ClearQuest salva todas
as alteraes sofridas, facilitando assim futuras consultas
e comparaes, contribuindo em muito para o controle de
modificaes (ver Figura 9).
Figura 9. Visualizao da aba History do defeito SAMPL00000051
Figura 8. Visualizao da Janela Visualizar Defect com estado Assigned
Aps ter designado um desenvolvedor ao registro do defeito, o prximo estado deste ser de Opened, isto significa,
36
Ao longo do projeto de TI pode ser altamente necessrio

criar e trabalhar com consultas no Rational ClearQuest.
Consultas o mecanismo pelo qual se procura controles
de mudanas de uma maneira fcil e rpida. Ao criar uma
consulta, devem-se especificar os critrios de seleo
dos controles de mudanas, como por exemplo, retornar
todos os controles de mudanas que estejam no estado de
Resolvido. O Rational ClearQuest ir exibir os resultados
atravs de uma Query Results View, sendo esses passos
descritos a seguir.
Para criar uma consulta utilizando o Assistente de Consulta do Rational ClearQuest, deve-se clicar em Arquivo
> Novo > Consultar. Na janela Assistente de Consulta,
definir um nome para a consulta como Defeitos Resolvidos, selecionar o valor Defect e clicar em Personal
Queries. Agora, na tela Selecionar Campos, devem-se
definir quais campos sero utilizados como filtros da
consulta. Para isso, deve-se, na rea da janela de Campos,
selecionar o campo State e, em seguida, clicar em Avanar
(ver Figura 10).
projeto
Figura 11. Visualizao da janela Definir Filtros de Consulta
Figura 10. Visualizao do Assistente de Consulta
Na janela Definir Filtros de Consulta deve-se especificar valores

para os campos de filtro, neste exemplo, o resultado da consulta
dever retornar somente os defeitos resolvidos. Para isso, com o
filtro State selecionado, deve-se no campo Operador selecionar
o valor Igual e informar o valor Resolved, desta forma, somente os registros com State igual a Resolved sero retornados
(ver Figura 11). O prximo passo ser definir quais campos sero
exibidos pela consulta. Assim, na janela Definir Campos de Exibio, deve-se selecionar os seguintes campos Headline, Owner,
Priority e State, e clicar em Concluir para criar a consulta.
Para executar a consulta, na janela principal do Rational

ClearQuest, na aba Navegador deve-se clicar no boto
Executar, os dados sero exibidos em uma Query Results
View. Pode-se visualizar que o resultado da consulta retornar somente os defeitos que possuem o estado Resolvido
(ver Figura 12).
No Rational ClearQuest, quando se utiliza uma consulta
criada por um membro da equipe de projetos ou compartilha
uma de suas consultas, fica mais fcil modificar uma consulta
existente para atender a novas necessidades do que criar uma
consulta totalmente nova. Para isso, deve-se utilizar a opo
de exportar e importar consultas.
Figura 12. Visualizao da janela principal do Rational ClearQuest
37
38
So Paulo: Novatec, 2007.

PMBOK. Um Guia do Conjunto de Conhecimentos em Gerenciamento de Projetos. 3 ed.
Newtown Square, Pennsylvania: Project Management Institute, Inc. 2004.
PRESSMAN, R. S. Engenharia de Software. So Paulo: Makron Books, 2004
VARGAS, Ricardo Viana. Manual Prtico do Plano de Projetos. 3 ed. Rio de Janeiro:
Brasport, 2007.
BRAGA, Aclair Rodrigues. Gerncia de Projetos - Preparao para a Certificao PMP. Disponvel
em: <http://www.scribd.com/doc/4905536/braga-preparacao-para-a-certificacao-pmp>.
Acesso em: 10 nov 2008.
TECHNET, Microsoft. Material do curso Academia de Gerenciamento. Disponvel em: <http://
www.microsoft.com/brasil/technet/academia/default.aspx>. Acesso em: 03 nov. 2008.
IBM. Rational ClearQuest Introduction. Disponvel em: <http://www.usd.edu/csci/docs/
rational/Rational%20ClearQuest/IntroductionClearQuest.pdf>. Acesso em: 14 mai 2009.

Feedback
eu

sobre e
s
Pode-se constatar que mudanas so inevitveis ao longo

do ciclo de vida de projetos e servios de TI. Alm do uso de
metodologias para o gerenciamento de mudanas, o uso de
ferramentas para o rastreamento e o controle dessas mudanas
um passo importante, gerando melhoria na qualidade tanto
no processo de desenvolvimento de software, quanto na melhoria dos servios prestados para a rea de TI.
Conforme visto neste artigo, o guia PMBoK apresenta as melhores prticas para gesto de projetos, e podem ser aplicadas
de maneira eficiente em projetos de software. O PMBoK est
dividido em nove reas de conhecimento, e a rea de Gerenciamento de Integrao, atravs do seu processo de Controle Integrado de Mudanas o responsvel em controlar e monitorar
mudanas ao longo de todo o ciclo de vida de um projeto.
Tambm se pode demonstrar que a ferramenta Rational ClearQuest fornece um controle flexvel de defeitos e alteraes
em todo o ciclo de vida de um projeto de TI, dando suporte
para um efetivo Gerenciamento de Mudanas.
MAGALHES, Ivan Luizio; PINHEIRO, Walfrido Brito. Gerenciamento de Servios de TI na Prtica.
D
s
Concluses
Referncias
edio
ta
Para exportar uma consulta, deve-se na aba Navegador

clicar com o boto direito do mouse na consulta Defeitos
Resolvidos e selecionar Exportar Consulta. No campo Nome
do arquivo da janela Exportar Consulta, alterar o nome da
consulta, como por exemplo, Defeitos Resolvidos 1 e, para
salvar a nova consulta, clicar em Salvar.
Para importar a consulta, deve-se clicar com o boto direito
do mouse na pasta Personal Queries e selecionar Importar.
Na janela Importar Consulta, deve-se selecionar o arquivo
Defeitos Resolvidos 1.qry, criado anteriormente, e clicar
em Abrir. Com isso, podem-se realizar alteraes nessa nova
consulta sem modificar a consulta anterior.
projeto
39
Ciclo de Vida da Gesto em

Arquitetura de Software
Maximizando a gerao de valor de projetos e produtos com arquiteturas de software
Eros Viggiano
eros.viggiano@arkhi.com.br
No ramo de TI desde 1991, trabalha com

consultoria e ensino de arquitetura de software. Atua principalmente nas reas de telecomunicaes e finanas como arquiteto de
software. coordenador e professor do curso
de Estratgias em Arquitetura de Sistemas no
IGTI e professor do IEC/PUC Minas. bacharel
em Cincia da Computao (DCC/UFMG) e especialista em Engenharia de Software (DCC/
UFMG). Algumas certificaes profissionais
relevantes: Sun Certified Enterprise Architect
(SCEA), IBM Rational Unified Process 7 (RUP).
Marco Aurlio S. Mendes

marco.mendes@arkhi.com.br
No ramo de TI desde 1990, trabalha com consultoria e ensino de engenharia de software.

Possui treze anos de experincia Java e atua
profissionalmente nas reas de melhoria
de processos de software e arquitetura de
software. coordenador e professor do curso
de Estratgias em Arquitetura de Sistemas
no IGTI e professor do IEC/PUC Minas. Possui
formao como bacharel e mestre em Cincia da Computao (DCC/UFMG). Algumas
certificaes profissionais relevantes: IBM
SOA Certified Solution Designer, IBM Rational
Unified Process 7 (RUP).
40
arquitetura de software uma

rea recente dentro da engenharia de software, tendo seus
primrdios na literatura no comeo da
dcada de 90. No obstante, ela tem
obtido cada vez mais visibilidade nos
projetos de TI no Brasil. cada vez mais
comum que empresas e projetos tenham
pessoas ou times exercendo o papel do
arquiteto de software e atividades em
cronogramas relacionadas ao desenho
de uma arquitetura de software. Mas o
que a arquitetura de software e quais
so as atividades que devem ser realizadas pelo arquiteto de software? A
arquitetura uma atividade puramente
tcnica? Criar uma arquitetura de software apenas modelar diagramas e
implementar provas de conceito? A arquitetura de software produz realmente
valor de negcio para um projeto? E
como poderamos organizar as atividades de arquitetura de software para
gerar valor concreto para um projeto,
produto ou organizao?
Este artigo enderea estas e outras
questes sobre as atividades de arquitetura de software e prope um ciclo de
Engenharia de Software Magazine - Ciclo de Vida da Gesto em Arquitetura de Software

O artigo apresenta um ciclo de vida para a gesto
das atividades de arquitetura de software em um
projeto, de forma a gerar maior valor de negcios
para um projeto, produto ou empresa.
Para que serve?

Conhecer e aplicar as atividades essenciais da arquitetura de software em um projeto, tais como: garantir o alinhamento tcnico do projeto organizao,
atender s restries de custo, tempo e qualidade
de um projeto, identificar e desenvolver requisitos
arquiteturalmente significativos, antecipar e mitigar
riscos tcnicos, realizar a anlise e desenho arquitetural, construir provas de conceito, gerar cdigo
executvel, orientar e acompanhar o time tcnico,
validar a estabilidade da arquitetura executvel e
coletar lies aprendidas para o prximo ciclo de
atividades arquiteturais.

No desenvolvimento de projetos de software
no triviais, na montagem de novos produtos, na
evoluo de tecnologias de produtos, em manutenes evolutivas complexas e, sobretudo, em
esforo de aumento de alinhamento das aes de
TI com as reas de negcio de uma organizao.
Arquitetur a de Soft ware
vida para organizao e ordenao temporal destas atividades

em projetos de software de qualquer natureza, com o uso de
qualquer tipo de processo de software.
primeira vista, podemos imaginar que arquitetar um software
escolher que tecnologias um projeto ir adotar, como por exemplo,
Java EE ou .NET. Esta viso mope, difundida por arquitetos empilhadores de frameworks, no pode estar mais longe da realidade.
Em uma segunda anlise, podemos imaginar que a arquitetura de
software consiste de montarmos modelos em linguagens sofisticadas como UML2. Esta viso estrbica difundida por arquitetos
de papel tambm est bem longe da verdade.
Coloquemos lentes de correo na viso de arquitetura de
software, que foi inicialmente delineada no excelente livro
Software Architecture: Perspectives on an Emerging Discipline, ainda em 1996. A arquitetura de software tem por objetivo
fazer o melhor uso dos recursos tcnicos de um projeto para
garantir a maior eficincia possvel aos objetivos do projeto,
produto e mesmo viso e misso de uma empresa.
Podemos identificar, nesta viso, atividades tais como:
garantir o alinhamento tcnico do projeto s diretrizes e
estratgias tecnolgicas de uma rea ou organizao, bem
como sua cultura organizacional;
atender as restries gerenciais de um projeto tais como
custo, prazo e competncias tcnicas da equipe;
identificar e detalhar requisitos significativos para a arquitetura de software;
antecipar e mitigar os riscos tcnicos de um projeto;
realizar a anlise e desenho tcnico da arquitetura atravs
de tcnicas de modelagem arquitetural;
construir provas de conceito e gerar cdigo executvel para
os principais pontos de risco do projeto;
orientar e acompanhar o time tcnico para garantir a aderncia
do cdigo construdo s diretrizes arquiteturais do projeto;
validar a estabilidade e objetivos da arquitetura do produto;
coletar lies aprendidas e promover um novo ciclo de
melhorias.
Em verdade, o ciclo de vida da arquitetura de software deve
ser compreendido atravs de um processo mais amplo que
aspectos puramente tcnicos, que denominamos aqui como a
gesto da arquitetura de software.
Arquiteturas de software so sempre desenvolvidas dentro de um
contexto de negcios como, por exemplo, a criao ou evoluo de
um produto, a automao de processos de negcio ou a integrao
entre sistemas de fornecedores distintos. Assim como a arquitetura
de software realiza tecnicamente objetivos organizacionais, ela deve
prover feedback do mundo real conforme mostrado na Figura 1.
Figura 1. Influncias sobre a gesto da arquitetura de software
Figura 2. Fases tpicas de um projeto
No caso de projetos de desenvolvimento de software, o ciclo

de vida do projeto geralmente respeita um processo de desenvolvimento de software como o IBM Rational Unified Process
(RUP). Mais adiante, abordaremos a relao dos processos de
desenvolvimento com a gesto da arquitetura de software.
Apresentaremos o ciclo de vida da gesto da arquitetura de software alinhado ao ciclo de vida do projeto. Situaremos as principais
atividades desempenhadas pelo time de arquitetura durante toda
a execuo do projeto de desenvolvimento de software. Entretanto,
lembramos que a arquitetura de software pode abranger o escopo de
um produto, isto , alm do ciclo do projeto conforme mostrado no
quadro Ciclo de vida do produto versus ciclo de vida do projeto.
Ciclo de vida do produto versus ciclo de vida do projeto
O ciclo de vida do produto mais abrangente que o do projeto. Um produto pode ser criado e
evoludo por vrios projetos (ver Figura 3).
Figura 3. Relao entre produto e ciclo de vida de projeto (Fonte: PMBOK [1])
As atividades da gesto da arquitetura de software so um

subconjunto das atividades executadas em um projeto de software. A Figura 4 define os grupos de atividades do ciclo de
vida da gesto da arquitetura que evidenciamos como IDEA
(Iniciao-Definio-Edificao-Avaliao).
Ciclo de Vida da Gesto da Arquitetura de Software

O ciclo de vida de um projeto organiza as fases do incio ao
fim das atividades, conforme mostrado na Figura 2. Tipicamente as transies entre fases so caracterizadas por algum tipo
de entrega e sua respectiva reviso. Para cada fase, o ciclo de
vida do projeto permite definir trabalho realizado, entregas,
envolvidos e critrios de aprovao e controle [1].
Figura 4. Grupos de atividades de IDEA, ciclo

de vida da gesto da arquitetura de software
41
Em um tpico projeto de desenvolvimento de software, as atividades do grupo I (Iniciao) coincidem com as fases iniciais do projeto
e caracterizam o incio dos trabalhos arquiteturais. Os grupos D
(Definio) e E (Edificao) se intercalam nas fases intermedirias,
sendo que D visa definir e validar arquiteturas candidatas e, em E,
procura-se garantir que as arquiteturas esto sendo adequadamente
realizadas. Enfim, as atividades do grupo A (Anlise) ocorrem no fim
do projeto e tem por objetivo analisar e aprender com os resultados,
objetivando a melhoria de processos e prticas arquiteturais.
A Figura 5 representa a projeo do ciclo de vida de um projeto
tpico sobre o ciclo de vida da gesto de arquitetura de software.
Figura 6. Processo arquitetural para um

novo produto de software baseado no IDEA
Grupo
Iniciao
Atividade
Definir a viso arquitetural
Produtos de trabalho
Viso arquitetural
Formular a estratgia arquitetural
Diretrizes arquiteturais
Anlise de viabilidade tcnica
Estratgia arquitetura
Planejar a definio arquitetural
Plano arquitetural
Desenvolver requisitos arquiteturais
Requisitos arquiteturais detalhados
Modelar a arquitetura
Modelo da arquitetura
Figura 5. Projeo do ciclo de vida da gesto de

arquitetura de software sobre o ciclo de vida do projeto
De uma forma geral, a literatura especializada trata principalmente das atividades relacionadas definio da arquitetura, em especial, da modelagem e da avaliao arquiteturais.
Entretanto, na prtica, a disciplina de arquitetura de software
requer uma gesto mais complexa. As atividades do arquiteto
tendem a envolver questes mais estratgicas que merecem ser
contextualizadas no ciclo de vida do projeto.
Dentre aqueles que defendem uma participao mais estratgica do arquiteto de software, destacamos os mtodos
arquiteturais VAP [2] de Dana Bredemeyer e o CFCAR [3] de
Gerrit Muller. A iniciativa de arquitetura de software do SEI,
denominada SAT, tambm ressalta o envolvimento do arquiteto no alinhamento estratgico do produto e trata o business
case como um insumo para a arquitetura de software.
O ciclo de vida IDEA serve como uma espcie de moldura
para instanciar processos de arquitetura de software. Para
projetos que visam o desenvolvimento de um novo produto, o
escopo do nosso artigo, sugerimos o processo diagramado na
Figura 6. Repare que, em termos gerais, o processo arquitetural
segue o ciclo de PDCA (Plan, Do, Check, Act).
A Tabela 1 enumera as atividades e os produtos de trabalho
sugeridos pelo IDEA.
Na seo Atividades da gesto em arquitetura de software,
exemplificaremos as atividades e seus produtos de trabalho
com um nvel um pouco maior de detalhes.
Definio
Avaliar a arquitetura
Avaliao da arquitetura
Edificao
Realizar a arquitetura do software
Arquitetura executvel
Anlise
Avaliar e aprender com os resultados
Lies aprendidas
Sugestes de melhorias
Tabela 1. Atividades e produtos de trabalho da gesto da arquitetura de software
IDEA e Processos de Desenvolvimento de Software

O IDEA pode ser aplicado sobre qualquer processo de desenvolvimento de software e seu uso tende a ser mais natural
em processos iterativos. A seguir, apresentamos simulaes de
projetos para diferentes processos considerando o ciclo IDEA.
Projetos conduzidos pelo IBM RUP (Rational Unified Process) so
marcados pelas fases Iniciao (por vezes, denominada de Concepo), Elaborao, Construo e Transio [2]. A Figura 7 exercita uma
projeo hipottica do ciclo IDEA sobre o ciclo de vida de um projeto
dirigido pelo RUP. As atividades da gesto da arquitetura tendem a
ser organizadas da seguinte forma nas fases do RUP [3]:
Iniciao: objetiva definir o escopo e aferir a viabilidade do
projeto. Coincide com as atividades iniciais (I) da gesto de
arquitetura de software e, muitas vezes, um esforo mnimo de
definio da arquitetura candidata (D). As atividades de arquitetura devem subsidiar a anlise de viabilidade do projeto;
Figura 7. Projeo hipottica do ciclo IDEA sobre o ciclo de vida de um projeto dirigido pelo RUP
42
Mito
Quem costuma acreditar nisto
Realidade
Arquitetura de software produzmuito papel.
Alguns adeptos de mtodos geis.
O processo de software adotado determina quais documentos so realmente necessrios.

Comunica-se somente o estritamente necessrio.
Arquitetura de software implica em big design up front [4]

(inteno de criar todos os modelos no incio do projeto).
Alguns agilistas e arquitetos.
A arquitetura deve respeitar a natureza do mtodo. Em projetos geis, a arquitetura do

software deve ser evolutiva [5].
Requisitos arquiteturais no podem mudar a partir

de um certo momento.
Alguns arquitetos e engenheiros de processos.
Mtodos geis aceitam mudanas a qualquer momento, tendo impacto ou no sobre a arquitetura. O
cliente deve sempre estar ciente das consequncias de uma mudana no requisito (arquitetural ou no).
Softwares desenvolvidos com mtodos geis no

tm arquitetura.
Pessoas envolvidas no desenvolvimento do software.
Todo software tem uma arquitetura,independente se algum a projetou intencionalmente ou no [6].
Arquiteto de software somente um novo e pomposo

ttulo que programadores pedem para ter em seus
cartes. Projetos geis no precisam do arquiteto.
Alguns adeptos de mtodos geis.
Vrios mtodos geis prescindem de papis. Mesmo que ningum na equipe tenha o papel
ou cargo de arquiteto de software, convm planejar a arquitetura.
Toda a arquitetura deve ser modelada no incio do

projeto.
Alguns arquitetos de software.
O arquiteto deve respeitar a natureza do projeto. Se o mtodo prescreve prove com cdigo
sempre que possvel, interessante realizar a arquitetura em software executvel mesmo
que no esteja completamente modelada.
Tabela 2. Mitos sobre mtodos geis versus arquitetura de software
Elaborao: seu principal objetivo estabilizar a arquitetura do

sistema, conhecida, nesse ponto, como arquitetura executvel. Assim, na Elaborao, as atividades de definio da arquitetura (D)
se intensificam e h uma forte preocupao em edific-la (E);
Construo: nesta fase, o projeto est em franco carter
construtivo do software. Ocorre o predomnio de atividades
relacionadas realizao da arquitetura (E). O arquiteto deve
garantir que a arquitetura bem compreendida por desenvolvedores, engenheiros de testes, integradores, etc.;
Transio: enfoca a liberao do produto. O arquiteto apia
as aes de qualidade e implantao (E). Na transio, ocorrem
as atividades finais da arquitetura, caracterizadas pela anlise
e aprendizado dos resultados (A).
Atualmente, existe uma aparente tenso entre a comunidade de
praticantes de mtodos geis e arquitetos de software ortodoxos [3].
Os chamados agilistas entendem que os arquitetos produzem muito
papel, enquanto que mudana nos requisitos (principalmente arquiteturais) provoca incmodo em alguns arquitetos de software em
qualquer estgio do projeto. Comentaremos rapidamente alguns
mitos de agilidade versus arquitetura de software na Tabela 2.
Nossa experincia diz que a disciplina de arquitetura de software
pode contribuir para a reduo de riscos tcnicos mesmo em projetos que empreguem mtodos geis. Para tal, em primeiro lugar,
os trabalhos arquiteturais devem respeitar a natureza evolutiva
de tais projetos. Em segundo, deve se ater a comunicar modelos
arquiteturais apenas na medida exigida pelo mtodo. Por exemplo,
se a filosofia de desenvolvimento prega abandonar diagramas aps
a realizao no modelo atravs do cdigo, o arquiteto assim deve

proceder. Outra situao: caso a equipe no faa uso de ferramentas
CASE ou de modelagem avanadas, o arquiteto pode considerar a
modelagem coletiva usando um quadro branco ou flip chart.
O ciclo de vida de gesto da arquitetura que apresentamos acomoda perfeitamente os projetos geis. Na Figura 8, apresentamos
uma projeo hipottica do ciclo IDEA sobre um projeto gil dirigido pelo SCRUM ou XP. Como pode ser percebido, os grupos de
definio (D) e edificao (E) arquiteturais se revezam constantemente durante as iteraes intermedirias do projeto. E, mesmo
nas ltimas iteraes, a descoberta ou mudana de um requisito
arquitetural pode implicar em redefinio (D) na arquitetura.
As iteraes do SCRUM so denominadas sprints. As primeiras
iteraes do XP compem as fases de Explorao e Planejamento.
O ciclo de vida IDEA e o processo exposto na Figura 6 comportam
a realizao parcial da arquitetura, isto , prova-se com cdigo
mesmo que a arquitetura no esteja completamente definida. Esta
abordagem totalmente aderente filosofia dos mtodos geis.
Por fim, mesmo que todo o senso moderno da engenharia de software no recomende processos em cascata, possvel vislumbrar
uma possvel aplicao do ciclo de vida IDEA nessa situao (nossa
experincia em gesto arquitetural limitada a projetos baseados
no Processo Unificado e em mtodos geis. A aplicao descrita
para processos em cascata meramente especulativa. Ainda hoje,
existem alguns projetos - principalmente aqueles derivados de
editais pblicos que sustentam este tipo de desenvolvimento.). A
Figura 9 demonstra esta situao, apesar de um tanto inusitada.
Figura 8. Projeo hipottica do ciclo IDEA sobre o ciclo de vida de um projeto gil
Figura 9. Aplicao hipottica do IDEA em processo cascata
43
Atividades da Gesto de Arquitetura de Software

Iremos ilustrar as atividades do ciclo de vida do IDEA atravs
de um exemplo fictcio no contexto de emprstimos bancrios
na modalidade de crdito consignado, um emprstimo com
desconto em folha de pagamento do trabalhador e, portanto
um emprstimo de menor risco.
Viso Arquitetural
A viso arquitetural nasce a partir da viso do produto e dos
princpios tcnicos do projeto, isto , os objetivos primrios da
arquitetura de software. Por exemplo, no nosso contexto bancrio poderamos ter o conjunto de princpios da Figura 10.
Definio do Problema Viso do Produto

recomendvel que o produto a ser modelado tenha uma
viso definida. Uma viso um documento que fornece as
diretrizes e funcionalidades bsicas do produto que deve ser
construdo. Fornecemos aqui um extrato da viso do produto
de emprstimo bancrio, resumido na Tabela 3.
O problema de
Afeta
demora e ineficincia na anlise e concesso de crdito consignado.

trabalhadores aposentados, servidores pblicos, funcionrios da iniciativa
privada, diretoria e acionistas do banco Optimus.
Impacto
atual
pequenos volumes de emprstimos realizados,grande demora para os clientes,custos

mais altos de financiamento,perda de clientes para outras financeiras e bancos.
Uma soluo
de TI bem
sucedida
seria
a automao do processo de anlise e concesso de crdito consignado

atravs da criao de uma soluo de portal que integre os clientes de
emprstimo, as bases de dados com as informaes histricas destes
clientes e informaes de clientes disponveis em bases de dados de
terceiros tais como SERASA e Secretaria da Receita Federal
Benefcios
esperados
Figura 10. Princpios arquiteturais do sistema de crdito consignado
aumento do nmero de vendas.

reduo dos custos de suporte com TI.
evoluo facilitada.
Tabela 3. Definio do problema de crdito consignado do banco Optimus
Inclumos na Tabela 4 as principais necessidades de negcio

do produto a ser modelado, que tambm fariam parte do documento de viso do produto.
Necessidades
Prioridade
Caractersticas
Portal Web para

Automao da
Anlise e Concesso
de Emprstimos de
Crdito Consignado
Alta
Usabilidade facilitada
Solicitao de Emprstimo
Abertura de emprstimo
Acompanhamento de emprstimo
Simulaes de financiamento
Anlise de risco
Concesso de Emprstimo
Acompanhamento de Pagamentos
Eliminao de
formulrios manuais
Alta
Portal para
dispositivos mveis.
Baixa
Cadastro unificado de clientes

Formulrio unificado para
solicitao de emprstimo
Abertura e acompanhamento de
solicitaes de emprstimo
Planejamento
para Liberao
1.0
Esses princpios norteiam qualquer atividade tcnica do

projeto. Por exemplo, ao avaliar uma determinada soluo,
framework ou tcnica, os confrontamos com os princpios
arquiteturais. Solues ou tcnicas que promovam mais segurana ou eficincia operacional teriam preferncia sobre
solues menos seguras ou menos eficientes.
A viso arquitetural exprime o plano arquitetural e apresenta uma primeira visualizao arquitetural, a visualizao
de negcio. A visualizao de negcio resumida para o nosso
produto expressa na Figura 11.
1.0
2.0
2.0
Abertura e acompanhamento
de solicitaes de emprstimo
por conveniados
Tabela 4. Definio das principais necessidades de crdito consignado
do banco Optimus
Interface EDI para
conveniados
Baixa
Iniciao
As tarefas iniciais do time de arquitetura devem garantir o alinhamento tcnico da arquitetura de software com a viso do produto
e demais premissas organizacionais (restries oramentrias e
temporais, conhecimentos da equipe e cultura organizacional). Para
isso, devemos desenvolver a viso e estratgia arquiteturais.
44
Figura 11. Visualizao de negcio do sistema de crdito consignado
Estratgia Arquitetural
A formulao da estratgia arquitetural a outra atividade
do grupo de iniciao do IDEA. Em suma, o arquiteto deve
realizar uma anlise estratgica e desenvolver a estratgia da
arquitetura de software.
Um dos produtos de trabalho da formulao estratgica
a identificao das diretrizes arquiteturais. As diretrizes
arquiteturais so os requisitos em alto nvel significativos para o time de arquitetura de software e refletem
decises que so difceis de serem revertidas. Diretrizes
arquiteturais devem ser identificadas explicitamente pelo
time de arquitetura de software com apoio dos analistas
de negcio, analistas de requisitos e demais interessados
tcnicos do projeto.
Geralmente no encontramos um nmero muito grande
de diretrizes arquiteturais no incio de um projeto de
software (valores tpicos entre 5 a 20). Essas diretrizes
normalmente refletem o subconjunto de requisitos prioritrios (na tica dos interessados do produto) e de alta
complexidade tcnica. interessante notar que as diretrizes arquiteturais podem advir de requisitos funcionais,
de requisitos no-funcionais (atributos de qualidade) e de
restries tecnolgicas.
No nosso exemplo, foram identificadas as seguintes diretrizes arquiteturais (As diretrizes foram propositadamente
simplificadas e contm palavras ambguas como excelente e
alta disponibilidade. Em projetos reais, mtodos de verificao
da qualidade de escrita de requisitos como o SMART ou mtodos de desenvolvimento formais de requisitos arquiteturais
como o SEI QAW poderiam ser usados para apoio ao time de
arquitetura):
Suporte a 1000 usurios simultneos em perodos de pico;
Tempo de resposta inferior a sete segundos;
Alta disponibilidade em horrio comercial;
Solicitao de emprstimo;
Simulaes de financiamento;
Anlise de risco de emprstimo;
Portal para a hospedagem de pginas e elementos visuais;
Portal para dispositivos mveis;
Operao em plataforma .NET;
Segurana com autenticao baseada em LDAP/Kerberos e
transporte seguro para comunicao com clientes;
Suporte aos navegadores Internet Explorer 6.0/7.0 e Firefox 3.0;
Interoperabilidade com SGBD Sybase;
Interoperabilidade com plataforma alta (CICS/COBOL).
O time de arquitetura deve tambm elencar e analisar os
principais riscos tcnicos do projeto que, na nossa abordagem,
chamamos de riscos arquiteturais. Exemplos de riscos que
poderiam compor o problema:
Conhecimento da equipe na plataforma .NET no avanado;
Conhecimento da equipe na plataforma .NET para ambientes
mveis precrio;
No existe experincia prvia do Banco Optimus em integrao com plataforma alta (CICS/COBOL).
O time de arquitetura tambm pode enderear oportunidades

para a empresa com o desenvolvimento de uma arquitetura de
software robusta para o produto. Exemplos de oportunidades
poderiam incluir:
Aumento da segurana da informao com o aprendizado
do protocolo Kerberos e outros aspectos de segurana da informao, o que pode eliminar riscos de auditoria e elevar o
valor do banco para diretores e acionistas;
Capacitao do time tcnico em tecnologias mveis.
A estratgia arquitetural tambm enderea aspectos como o
estilo arquitetural e a metfora sistmica. O estilo arquitetural,
como na arquitetura da construo civil, classifica um produto
quanto ao seu estilo primrio.
A metfora sistmica, idia originria da metodologia XP,
um recurso visual e muitas vezes ldico para explicar a arquitetura a pessoas com poucos conhecimentos tcnicos. Um exemplo para metfora sistmica representado na Figura 12.
O estilo e a metfora sistmica do nosso exemplo esto representados na Tabela 5.
Estilo
Arquitetural
Metfora
Sistmica
O nosso sistema um sistema de informao com diferentes tipos de

visualizaes (portais Web e mveis) e interoperabilidade com sistemas
legados.Portanto,o estilo arquitetural associado ao nosso sistema um sistema
n-tier, ancorado no padro arquitetural MVC (Model View Controller).
O nosso sistema est desenhado conforme um bolo em camadas
(camada visual, camada de negcios e camada de interoperabilidade
com banco de dados e legados).
Tabela 5. Estilo arquitetural e metfora do sistema de crdito consignado
Figura 12. Metfora Sistmica
Definio
A definio o grupo de atividades do IDEA que lida com
anlise e desenho arquitetural dos requisitos sob anlise.
Grande parte do trabalho que arquitetos usualmente praticam,
principalmente a modelagem arquitetural, est situada neste
grupo de atividades. No artigo corrente, abordaremos a definio arquitetural com um nvel muito superficial de detalhes.
A definio no IDEA, entretanto, tende a ser mais ampla e
lida com:
O planejamento das atividades de definio da arquitetura
para a iterao ou fase atual do projeto. Arquiteturas de software so naturalmente evolucionrias (o conceito de arquiteturas
evolucionria descrito em processos como o OpenUP ou no
45
mtodo de Arquiteturas geis (Agile Architectures) de Scott

Ambler) e evolutivas e, portanto, o ciclo de definio parte
para o endereamento de um determinado subconjunto dos
requisitos arquiteturais.
O desenvolvimento dos requisitos a partir das diretrizes
arquiteturais. Tcnicas como o FURPS+ [9], a ISO SQUARE
[10] e o modelo SMART [11] podem ser usadas para apoiar
neste processo de detalhamento de requisitos tcnicos. O
uso de cenrios [12] pode ser til para representar requisitos
arquiteturais refinados. comum encontrarmos sistemas com
vrias dezenas de requisitos arquiteturais discretos.
A modelagem arquitetural atravs do uso de mltiplas visualizaes. Tcnicas como o modelo de visualizaes 4+1 [9],
de Phillipe Kruchten, ou o modelo SEI conhecido por V&B [10]
poderiam ser usados aqui.
O detalhamento das tticas arquiteturais. Uma ttica arquitetural lida com um determinado aspecto da arquitetura. Por
exemplo, poderamos enderear uma ttica para autenticao
e single sign-on com o LDAP/Kerberos.
A explorao de alternativas de anlise e desenho. A avaliao e
comparao destas alternativas e a proposta da arquitetura parcial
para o conjunto de requisitos endereados at o momento.
Exemplos de visualizaes para o modelo do nosso exemplo
so fornecidos nas Figuras 12, 13, 14 e 15. A Figura 12 apresenta
o conceito da metfora arquitetural derivada de escolas geis
como o XP. No nosso exemplo, o padro referenciado o padro camadas (Layers), que denota uma organizao em nveis
de apresentao, domnio e interoperabilidade com sistemas
legados e bancos de dados.
A Figura 13 apresenta uma visualizao lgica, que captura os grandes agrupamentos do domnio da aplicao.
Cada grande elemento capturado como um pacote UML,
que pode apresentar ou requerer dependncias de outros
pacotes. Esta viso fornece um primeiro diagrama de
contexto para iniciados no projeto e tambm permitir
expressas dependncias para a montagem de um cronograma de trabalho.
A Figura 14 apresenta uma visualizao de componentes (que
so elementos fsicos como DLLs Windows ou .JARs em Java).
Esta viso captura a gesto de configurao dos elementos
centrais a serem produzidos pelo time de projeto e dependncias para a sua operao em produo. Por exemplo, vemos
nesta figura que o domnio que cuida do processo de negcio
de consignao de crdito depende do servidor de integrao
(MS BizTalk), que por sua vez depende de um adaptador de
fila de mensagens para que as mensagens sejam enviadas ao
sistema do Banco Central do Brasil.
Finalmente, vemos uma viso de provisionamento (mquinas
e servidores de infra-estrutura) do nosso software na Figura 15.
Vemos, por exemplo, que teremos um servidor dedicado para
hospedar o banco de dados e um servidor dedicado para
hospedar o cdigo.
Estes modelos, em verdade, seriam um pequeno fragmento
de uma soluo completa para este exemplo hipottico. Um
modelo arquitetural completo no apresentado aqui, naturalmente, por questes de espao.
No mundo real, um dos trabalhos de um arquiteto de sistemas
definir que vises so ou no aplicveis conforme os riscos
tcnicos e requisitos do projeto sendo endereado.
Figura 13. Visualizao lgica do sistema de crdito consignado
46
Figura 14. Visualizao de implementao do sistema de crdito consignado
As atividades do grupo de definio arquitetural so encadeadas em um ciclo. Cada execuo do ciclo produz uma arquitetura candidata que, potencialmente, pode ser realizada em
cdigo (atividade do grupo de Edificao). O ciclo se repete at
que se considere que uma arquitetura estvel foi atingida.
Nota do DevMan
Ciclo PDCA
O ciclo PDCA, tambm conhecido por ciclo de Shewhart ou ciclo de Deming, um
processo em quatro passos para soluo de problemas. O PDCA foi criado por Walter
Shewhart e popularizado por W. Edwards Deming. Resumidamente, as fases significam:
Plan (planejamento): estabelece objetivos e processos para atingir os resultados;
Do (execuo): execuo das atividades planejadas;
Check (verificao): monitorao ou estudo peridico dos resultados, consolidando-os com o planejado;
Act (ao): agir conforme o estudo promovido pela verificao com fins de melhorar a qualidade, a eficincia e a eficcia.
Figura 15. Visualizao de implantao do sistema de crdito consignado
47
Edificao
At este momento temos normalmente uma arquitetura
candidata, i.e, uma arquitetura baseada em estudos e experincia do time e tambm na anlise de alternativas. Entretanto,
devemos provar a arquitetura com cdigo robusto.
O IDEA prope, neste particular, um conjunto de atividades
de edificao. A edificao realiza a arquitetura, isto , fornece
evidncias concretas atravs de cdigo executvel que a arquitetura acomoda os requisitos do projeto.
A edificao realizada atravs do esforo conjunto do
time de arquitetura do projeto (arquiteto e desenvolvedores
especialistas). O resultado da edificao uma arquitetural
executvel, que poderia ser gerada em pequenos incrementos
(builds) nas fases iniciais de um projeto.
No nosso exemplo, poderamos elencar um plano de builds
(cdigos com maturidade Alfa - um produto alfa um cdigo executvel, mas que ainda no possui estabilidade de
produo. Ele pode (e deve) ser usado para validar requisitos
arquiteturais com usurios chave, estabelecer nveis maiores de confiana e reduzir riscos tcnicos do projeto) a ser
construdo para provar aspectos da arquitetura com cdigo
executvel. Seis builds so mostrados para exemplificar nosso
produto bancrio:
Alfa 1 Prova de Conceito Single Sign On Kerberos;
Alfa 2 Prova de conceito com o fluxo de solicitao, abertura
e acompanhamento de emprstimos;
Alfa 3 Prova de conceito de interoperabilidade e troca de informaes (EDI) com Microsoft MQSeries para o Banco Central;
Alfa 4 Prova de conceito de escalabilidade para 1000 usurios simultneos;
Alfa 5 Implementao do conjunto de casos de uso de
solicitao e abertura de emprstimo;
Alfa 6 - Implementao do conjunto de casos de uso de
simulaes de financiamento.
Ao final do ciclo de atividades de edificao, temos uma
arquitetura provada para os mecanismos centrais elencados
na fase de definio.
O trabalho de arquitetura no se encerra ao termos uma
arquitetura executvel e estvel. muito fcil quebrar uma
arquitetura definida e, portanto, o arquiteto deve acompanhar
o time na resoluo contnua de dvidas e na verificao do
cdigo sendo construdo.
Alm do trabalho junto ao time de desenvolvimento, o arquiteto tambm apia outros profissionais como o engenheiro de testes, o analista
de integrao, gerente de configurao, etc. O objetivo garantir que
todos compreendam perfeitamente a arquitetura definida.
A arquitetura, como pea estratgica em uma empresa, deve

gerar informaes para a gesto do conhecimento corporativo
e promover cada vez mais alinhamento entre as aes tcnicas
e as necessidades de negcio de uma organizao.
Concluses
A disciplina de arquitetura de software tende a ser mais
eficaz se aplicada em um contexto mais amplo e responsvel
a gesto da arquitetura de software. IDEA, o ciclo de vida
da gesto da arquitetura de software, encadeia as atividades
de arquitetura de software de uma forma compreensvel e
organizada.
O artigo corrente concentrou-se no processo de arquitetura
de software para a criao de um produto, mas, de uma forma
anloga, os conceitos podem ser aplicados para famlias de
produtos e arquiteturas de referncia.
Referncias
1. Project Management Institute. [PMBOK] A Guide to the Project Management Body of
Knowledge. s.l.: Project Management Institute, 2004.
2. Malan, Ruth and Bredemeyer, Dana. Architecture as a Business Competency. [Online] http://
www.bredemeyer.com/pdf_files/WhitePapers/ArchitectureAsBusinessCompetency.PDF.
3. Muller, Gerrit. CAFCR: A Multi-view Method for Embedded Systems Architecting; Balancing
Genericity and Specificity. [Online] http://www.gaudisite.nl/info/Thesis.info.html.
4. IBM. IBM Rational Unified Process 7.5. s.l.: IBM.
5. Rozanski, Nick and Woods, Eoin. Software Systems Architecture: Working with Stakeholders
Using Viewpoints and Perspectives. s.l.: Addison-Wesley Professional, 2005.
6. Ambler, Scott. Big Modeling Up Front (BMUF) Anti-Pattern. Agile Modeling. [Online] 2007.
[Cited: 04 02, 2009.] http://www.agilemodeling.com/essays/bmuf.htm.
7. InfoQ. Paulo Merson on Documenting Application Architectures Using UML 2.0. [Online]
InfoQ, 11 27, 2008. [Cited: 04 02, 2009.] http://www.infoq.com/news/2008/11/paulo-mersonarchitecture.
8. IBM Rational Quality Manager. Entrevista: Grady Booch e Scott W. Ambler - Architecture?
Agile Dont Need No Architecture! [Online] 2009. [Cited: 04 02, 2009.] http://www.facebook.
com/video/video.php?v=1090941519721.
9. Grady, Robert. Practical software metrics for project management and process improvement.
Upper Saddle River, NJ, USA: Prentice-Hall, Inc., 1992. ISBN:0-13-720384-5.
10. ISO. Software Engineering -- Software product Quality Requirements and Evaluation
(SQuaRE) -- Guide to SQuaRE. ISO/IEC 25000:2005. [Online] 2005. http://www.iso.org/iso/
iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=35683.
11. Mannion, Mike and Keepence, Barry. SMART requirements. ACM SIGSOFT Software
Engineering Notes. 1995, Vol. 20, 2.
12. Bass, Len, Clements, Paul and Kazman, Rick. Software Architecture in Practice. 2nd. s.l. :
Addison-Wesley, 2003.
13. Kruchten, Phillippe. The 4+1 View Model of Architecture. IEEE Software. 6, 1995, Vol. 12, 6.
14. Clements, Paul, et al. Documenting software architectures: views and beyond. ICSE 03:
Proceedings of the 25th International Conference on Software Engineering . 2003.
Avaliao
D
s

Feedback
eu
edio
ta
48
sobre e
s
O IDEA est inspirado nas idias clssicas do PDCA e como tal

possui um ciclo de atividades para anlise de lies aprendidas. A
avaliao deve ser ampla e envolver o time tcnico, time gerencial,
time de analistas e demais interessados no projeto. As aes de
arquitetura devem ser avaliadas e os erros e lies aprendidas
devem ser discutidas e comunicadas para toda a equipe.
49
Anlise da Arquitetura de Software

Essencial para Arquitetura de Software
Apresenta o uso de requisitos arquiteturais na
anlise da arquitetura de software e a destaca no
desenvolvimento de um sistema de software.
Para que serve?
Antonio Mendes da Silva Filho

antoniom.silvafilho@gmail.com
Professor e consultor em rea de tecnologia

da informao e comunicao com mais de
20 anos de experincia profissional, autor do
livros Arquitetura de Software e Programando com XML, ambos pela Editora Campus/Elsevier, tem mais de 30 artigos publicados em
eventos nacionais e internacionais, colunista
para Cincia e Tecnologia pela Revista Espao
Acadmico com mais de 80 artigos publicados,
tendo feitos palestras em eventos nacionais e
exterior. Foi Professor Visitante da University
of Texas at Dallas e da University of Ottawa.
Formado em Engenharia Eltrica pela Universidade de Pernambuco, com Mestrado em
Engenharia Eltrica pela Universidade Federal
da Paraba (Campina Grande), Mestrado em
Engenharia da Computao pela University of
Waterloo e Doutor em Cincia da Computao
pela Univesidade Federal de Pernambuco.
50
arquitetura de software de um
sistema serve para definir a
organizao das funcionalidades desse sistema e propriedades ou
requisitos no funcionais suportados
pelo mesmo. Caractersticas peculiares
da arquitetura determinaro quais
propriedades sero preponderantes. A
necessidade da arquitetura de software
prover suporte a um conjunto de requisitos, geralmente conflitantes, requer que
uma anlise arquitetural seja realizada,
tema tratado neste artigo.
Desenvolvimento de Sistemas de
Software
O processo de desenvolvimento de sistemas de software, similarmente a outros
sistemas, compreende trs fases genricas
definio, desenvolvimento e manuteno conforme ilustrado na Figura 1.
Engenharia de Software Magazine - Anlise da Arquitetura de Software
Entender o papel da anlise arquitetural dentro do

processo de desenvolvimento de software orientado
para arquitetura e definio da arquitetura de software a ser adotada.

Identificao de requisitos arquiteturais importantes a um sistema de software em desenvolvimento e
construo de cenrios para definio da arquitetura
e como esta suporta esses requisitos.
A fase de definio engloba a identificao de informaes que deveriam

ser processadas, funes e desempenho
desejados, tipo de interface a ser utilizada, tarefas que o sistema deveria prover
suporte, perfil de usurios do sistema,
dentre outras.
A fase de desenvolvimento concentra-se
no projeto de estruturas de dados e arquitetura de software do sistema, converso
do projeto para alguma linguagem de
Definio
Desenvolvimento
Manuteno
Figura 1. Fases genricas no processo de desenvolvimento de software
programao, realizao de testes e avaliao. Finalmente, a

manuteno considera modificaes e/ou correes necessrias
no sistema a fim de que este atenda aos requisitos do usurio.
Perceba que o processo de desenvolvimento de um sistema de
software tem duas grandes atividades de interesse: o desenvolvimento da poro de software que implementa as funcionalidades do sistema, e a atividade que a antecede e norteia o
desenvolvimento, que o projeto da arquitetura de software.
Essa ltima atividade resultado da anlise arquitetural que
prov informaes para decises arquiteturais, como ilustrado
na Figura 2. A anlise arquitetural e os critrios para definio de
uma arquitetura so apresentadas nas sees subsequentes.
Anlise da soluo A anlise da soluo realizada em

termos do modelo arquitetural que se tem em mos, podendo
identificar a necessidade de refinar o modelo.
Perceba que o modelo arquitetural pode ser considerado como
um esboo inicial da arquitetura de software do sistema em
desenvolvimento. importante ainda observar que a anlise
de uma arquitetura de software um processo iterativo no qual
so feitos refinamento de um modelo arquitetural inicial, derivado a partir de um conjunto de requisitos arquiteturais. Em
cada iterao, uma mini anlise ocorre, refinando a arquitetura
proposta inicialmente. Esse processo ilustrado na Figura 3.
Figura 3. Anlise arquitetural.
Entretanto, note que no tarefa fcil validar uma arquitetura de software quanto ao suporte que oferece a um
conjunto de requisitos. muitas vezes difcil associar novas
arquiteturas a atributos de qualidade. Observa-se, geralmente, que os desenvolvedores concentram-se nos aspectos
funcionais das arquiteturas. Assim, o principal propsito da
anlise arquitetural verificar se os requisitos arquiteturais
tm sido levados em conta durante o desenvolvimento de
um sistema de software.
Propriedades da Arquitetura de Software

Figura 2. Etapas no projeto da arquitetura de software.
Anlise da Arquitetura de Software

O projeto da arquitetura de software uma etapa essencial
no desenvolvimento de sistemas de software de grande porte.
Dentro deste contexto, a arquitetura de software fundamental
para o desenvolvimento de software onde se tem funcionalidades distintas, sendo concebidas a partir da mesma arquitetura
base. Entretanto, antecedendo a etapa de projeto da arquitetura
de software, h a necessidade de fazer o levantamento dos
requisitos do sistema, como mostrado na Figura 2.
De um modo geral, a anlise e projeto de um sistema geralmente engloba as atividades de:
Desenvolvimento de modelo arquitetural Os dados so
coletados durante a elicitao de requisitos a fim de serem
analisados e incorporados ao modelo arquitetural (isto , o
produto resultante). Neste caso, o modelo passa a ser o elemento central da anlise.
Melhoria e sntese de uma soluo Incrementam-se as
informaes descritas no modelo arquitetural (inicial).
A arquitetura de software uma parte essencial de um sistema de software complexo. Com a crescente complexidade de
sistemas de software, a especificao global do sistema, ou seja,
sua arquitetura passa a ser um aspecto de maior significado
quando comparado escolha de algoritmos ou estruturas de
dados. Um sistema possui um conjunto de requisitos arquiteturais, envolvendo atributos de qualidade (ou requisitos no
funcionais) e atributos de projeto. Esses requisitos constituem
propriedades desejadas ou apresentadas por uma arquitetura de software. Dentre esses requisitos, uma arquitetura de
software apresenta propriedades importantes que podem ser
vistas como intrnsecas a ela. Tais propriedades so: eficincia,
integridade e flexibilidade
A eficincia pode ser descrita como a quantidade de recursos
computacionais necessrios para que um programa realize
suas funes. Esses recursos computacionais podem ser vistos
em termos da capacidade de armazenamento e processamento.
Um dos principais requisitos associados eficincia o desempenho. O desempenho um requisito no funcional essencial
para um sistema de software e constitui num enorme desafio
51
lidar com tal requisito durante o desenvolvimento de um sistema. Por exemplo, seria possvel ter os seguintes requisitos
de desempenho quando do desenvolvimento de um sistema
de software para administrao de cartes de crdito:
Obter um bom tempo de resposta para autorizao de vendas com carto de crdito. O termo bom poderia ser traduzido
em 7 segundos.
Obter um bom uso de memria para armazenar as informaes de um cliente. Poderia ser especificado o mximo de 10
Kb para armazenar as informaes de cada cliente.
A eficincia uma propriedade de suma importncia
nas decises de projeto e tem forte influncia na anlise
arquitetural de um sistema. Perceba que a forma na qual os
componentes de uma arquitetura encontram-se distribudos,
bem como os mecanismos de comunicao entre eles, so
determinantes do desempenho e, portanto, da eficincia do
sistema. Essa propriedade, s vezes, atua em conflito com
outros requisitos do sistema, exigindo que compromissos
sejam assumidos em termos de custo e desempenho de um
sistema de software.
Outra importante propriedade a integridade. Aqui, a
noo de integridade refere-se integridade em termos da
unificao do projeto em nveis distintos. A arquitetura de
software descreve a organizao de um sistema de software
num nvel mais elevado, objetivando a unificao do projeto, ou seja, serve de referncia para o projeto, conforme
ilustrado na Figura 4.
requisitos
requisitos
arquitetura de software
Implementaes
mtodos
(a)
implementaes
(b)
Figura 4. Arquitetura de software como referncia de projeto.
Note que a arquitetura de software central e essencial

qualidade de um sistema, associados um conjunto de atributos de qualidade. Similarmente, a integridade (arquitetural)
funciona como elemento coordenador que unifica o projeto
do sistema de software em diferentes nveis.
Complementando, outra importante propriedade a flexibilidade, que diz respeito ao esforo exigido para modificar
um sistema de software. Em outras palavras, a facilidade
com a qual um sistema de software pode ser estendido
a fim de dar suporte a uma ou mais funcionalidade(s)
adicionada(s).
Por exemplo, a criao de interfaces adicionais aumenta flexibilidade, incrementando a facilidade de fazer modificaes,
uma vez que as interfaces separam partes distintas de funcionalidade em componentes de software diferentes.
52
SAAM Mtodo de Anlise de Arquitetura de Software

Um exemplo de mtodo de anlise de arquitetura de software,
denominado SAAM (Software Architecture Analysis Method),
foi inicialmente concebido com o objetivo de auxiliar arquitetos
de software a compararem solues arquiteturais, tendo sido o
precursor de outros mtodos de anlise arquitetural. O mtodo
SAAM compreende os seguintes objetivos:
Definir um conjunto de cenrios que representem usos importantes do sistema no domnio, envolvendo os pontos de vista de
todos aqueles que possuem papis influenciadores no sistema.
Utilizar cenrios para gerar uma partio funcional do domnio, uma ordenao parcial das funes e um acoplamento
dos cenrios s vrias funes existentes na partio.
Usar a partio funcional e ordenao parcial, juntamente
com cenrios de uso, a fim de realizar a anlise das arquiteturas propostas.
Assim, para cada cenrio, a anlise fornece uma pontuao
das arquiteturas que esto sendo avaliadas, denominadas de
arquiteturas candidatas. Recai, portanto, sobre o avaliador a
responsabilidade de determinar os pesos dos cenrios considerados, bem como a pontuao global das arquiteturas
candidatas.
O mtodo de anlise arquitetural SAAM baseado no uso de
cenrios. Fazendo uso de cenrios, um analista pode usar uma
descrio de arquitetura de software para avaliar o potencial
do sistema de software prover suporte a atributos de qualidade
ou requisitos no funcionais. Entretanto, importante observar
que avaliar uma arquitetura de software para determinar se ela
oferece suporte a requisitos no funcionais no tarefa fcil.
Tais requisitos tendem a serem um tanto vagos.
Objetivando realizar a anlise, portanto, torna-se necessrio
considerar o contexto no qual o sistema de software encontra-se
inserido, bem como considerar as circunstncias especficas
quele contexto. Uma forma de atingir esse objetivo fazendo
uso de cenrios a fim de entender e avaliar se uma arquitetura
oferece suporte ou no a um especfico requisito no funcional,
e sob quais circunstncias.
SAAM compreende um conjunto de cinco passos que possuem interdependncias entre si, conforme ilustra a Figura 5
e descritas a seguir.
Descrio de
arquitetura
Desenvolvimento
de cenrios
Avaliao de
cada cenrio
Av aliao de cenrios e
da interao de cenrios
Determinao da
interao de cenrios
Figura 5. Etapas de SAAM.
1. Desenvolvimento de cenrios Desenvolvimento de cenrios

de tarefas que ilustram os tipos de atividades que o sistema de
software deve prover suporte. Tambm, o analista deve considerar possveis modificaes que o sistema possa sofrer ao longo do
tempo. Ao desenvolver esses cenrios, um arquiteto deve capturar
todos os usos importantes do sistema, que iro refletir os requisitos no funcionais. Alm disso, esses cenrios devero apresentar
interaes, considerando os principais influenciadores com papis
relevantes ao sistema de software, tais como: usurio e/ou cliente,
desenvolvedor, mantenedor e administrador de sistema.
2. Descrio de arquitetura Para cada anlise, deve-se possuir uma
representao arquitetural do sistema, fazendo uso de uma notao
arquitetural definida, descrevendo componentes e conectores utilizados na especificao da arquitetura. Isto permitir que o pessoal
envolvido na anlise tenha um entendimento comum do problema.
A especificao arquitetural deve informar os componentes funcionais e de dados do sistema bem como as relaes existentes entre
eles. Desse modo, uma representao arquitetural far uma distino
entre componentes ativos (que efetuam transformaes de dados)
e componentes passivos (que armazenam dados). Adicionalmente,
devemos considerar dois tipos de conexes: (a) conexes de dados
(onde se tem passagem de dados entre componentes) e (b) conexes de controle (na qual um componente atua sobre um outro o
habilitando a executar alguma tarefa). importante observar que a
descrio grfica nos d uma representao esttica da arquitetura
do sistema, que complementada atravs de uma representao
dinmica expressa em linguagem natural que fornece uma descrio
do comportamento do sistema ao longo do tempo.
3. Avaliao de cada cenrio Para cada cenrio, deve-se determinar se a arquitetura candidata oferece suporte diretamente s tarefas associadas ao cenrio ou se alguma modificao necessria e,
portanto, a arquitetura oferece suporte ao cenrio apenas indiretamente. No primeiro caso, os cenrios representam funes que
a arquitetura j possui. O segundo caso compreende cenrios que
incluem funes alm das existentes que a arquitetura de prover
suporte. Neste caso, uma modificao deve ser feita na arquitetura
atravs da adio ou alterao de um componente ou conexo. Ao
final, deveria obter uma tabela sumarizando os cenrios onde a
arquitetura candidata prov suporte aos requisitos no funcionais
associados. Nessa tabela, pode-se adotar a seguinte conveno:
Se a arquitetura candidata suporta a(s) tarefa(s) contida(s) no
cenrio considerado, ento se pode atribuir um escore +, e no
h necessidade de fazer qualquer anlise adicional.
Se a arquitetura candidata no suporta diretamente a(s) tarefa(s)
contida(s) no cenrio, ento se precisa continuar a avaliao a fim
de determinar a extenso das modificaes que devem ser realizadas. Uma forma de determinar isso conhecendo o nmero
de componentes e conexes que precisaro ser adicionados ou
modificados. Isto requer um conhecimento profundo da arquitetura, o qual pode ser obtido junto ao desenvolvedor ou atravs
do conjunto de especificaes do sistema. Se duas arquiteturas
esto sendo comparadas, ento aquela que exigir menos modificao ou adio de componentes e conexes, receber o escore
+, enquanto aquela requerendo mais adies ou modificaes
em componentes e conexes, receber o escore -.
4. Determinao da interao de cenrios Uma interao

entre cenrios ocorre quando dois ou mais cenrios indiretos
exigem modificaes em algum componente ou conexo. A
identificao da interao de cenrios permite saber como a
funcionalidade do sistema de software alocada durante o
projeto. Em outras palavras, a interao de cenrios mostra as
tarefas s quais os componentes esto associados. Na realidade,
a determinao da interao de cenrios avalia a extenso
qual a arquitetura prov suporte a uma separao de interesses
apropriada. Por exemplo, um elevado grau de interao pode
indicar que a funcionalidade de um componente especfico
est inadequadamente isolada. Dessa forma, para cada cenrio, deve-se determinar como os componentes e conexes so
afetadas pelo cenrio considerado.
5. Avaliao de cenrios e da interao de cenrios Esta
uma etapa subjetiva do processo de anlise, envolvendo os
principais influenciadores do sistema. Nesta etapa, realiza-se
uma avaliao global atribuindo um escore a cada cenrio e
interao de cenrio. Isto baseado nas implicaes que os
cenrios tm sobre a arquitetura do sistema. Note que, anteriormente, foram desenvolvidos cenrios, fez-se o mapeamento
deles na descrio arquitetural do sistema, e determinaram-se
as interaes de cenrios existentes. Esta avaliao reflete a
influncia dos atributos de qualidade (ou requisitos no funcionais) associados aos cenrios.
Este mtodo de anlise permite um avaliador utilizar um
conjunto de mtricas associadas com os cenrios elaborados para que possa analisar qual arquitetura de software,
dentre as arquiteturas candidatas, prov melhor suporte
ao conjunto de requisitos no funcionais desejados para o
sistema de software.
importante observar que as duas primeiras etapas possuem
elevado grau de dependncia entre elas, como mostrado na
Figura 5. Os tipos de cenrios desenvolvidos tero influncia
sobre o nvel de granulosidade da arquitetura. Agora, como
se pode determinar um conjunto de cenrios? Isto depender
do tipo de tarefas que o sistema de software suportar. Dentro
deste contexto, os cenrios elaborados tm um papel de suma
importncia, uma vez que eles iro ajudar a compreender a
descrio arquitetural do sistema.
Considere, por exemplo, uma das arquiteturas de software
para interface com usurio, denominada de Serpent, ilustrada
na Figura 6.
Aplicao
Gerente de
dilogo
Apresentao
Controlador
de dilogo
Banco de
dados ativo
Figura 6. Arquitetura Serpent.
53
O componente de aplicao d suporte semntica computacional da aplicao. A apresentao um componente

que oferece suporte aos mecanismos de interao nos nveis
lgico e fsico, sendo completamente independente da semntica da aplicao. A coordenao entre estes dois primeiros
componentes feita atravs do controlador de dilogo. Esse
terceiro componente encarregado de mediar a comunicao
da interao do usurio com a aplicao. Toda a comunicao
na arquitetura Serpent mediada por meio de restries a
dados compartilhados de um banco de dados. Esta estrutura
implementada como um banco de dados ativo. Assim, quando
os valores no banco de dados so alterados, eles so automaticamente comunicados a qualquer componente registrado que
possua interesse sobre o dado modificado.
Uma partio cannica para software de interface com usurio, considerada como um meta-modelo para arquiteturas de
sistemas interativos, identifica que as cinco funes bsicas em
um software de interface compreendem:
Ncleo Funcional (NF) - realiza as manipulaes de
dados e outras funes orientadas ao domnio. tambm
chamado de componente especfico do domnio ou, simplesmente, aplicao.
Adaptador de Ncleo Funcional (ANF) agrega os dados
especficos do domnio em estruturas de alto nvel, realiza
verificaes semnticas e dispara tarefas de dilogo inicializadas no domnio. Ele um mediador entre o Dilogo e o
Ncleo Funcional.
Dilogo (D) faz a mediao entre partes especficas do
domnio e especficas da apresentao de uma interface com
usurio, realizando o mapeamento de dados quando necessrio. Assegura consistncia e o sequenciamento de tarefas.
Componente de Interao Lgica (IL) fornece um conjunto de
objetos independentes de toolkit para o componente de Dilogo.
Componente de Interao Fsica (IF) implementa a interao
fsica entre usurio e computador. Lida com dispositivos de
entrada e sada e , geralmente, conhecido como componente
de toolkit de interao.
Agora, se tentarmos fazer o mapeamento dessas cinco funes para sistemas interativos (na arquitetura de software de
interface de usurio de Serpent), obteremos uma arquitetura
conforme ilustrada na Figura 7.
ANF
D
Gerente de
dilogo
notao arquitetural
Controlador
de dilogo
Componentes
Conectores
processo
Banco de
dados ativo
componente
computacional
NF
IF
IL
Aplicao
Apresentao
(a)
fluxo de dados
(uni)bidirecional
repositrio de
dados passivo
fluxo de controle
uni/bidirecional
repositrio de
dados ativo
(b)
Figura 7. Arquitetura Serpent baseada no meta-modelo de arquitetura.
54
A arquitetura Serpent foi redesenhada fazendo uso da notao arquitetural apresentada na Figura 7b. As funes bsicas
de um software de interface com usurio foram mapeadas
na estrutura inicial da arquitetura Serpent (vide Figura 6),
resultando a arquitetura ilustrada na Figura 7a. Algumas
observaes podem ser feitas:
No h separao arquitetural entre as funes IL e IF no
processo de apresentao;
Tambm, no existe separao arquitetural entre as funes
de ANF e D no processo do controlador de dilogo;
Exceto o gerenciador de dilogo, todos os componentes de
Serpent so monolticos. Em outras palavras, eles no oferecem
suporte arquitetural para subdiviso de funcionalidade dentro
de um componente.
Considerando a arquitetura Serpent, vamos supor que se
deseja efetuar uma modificao como, por exemplo, adicionar
uma nova opo de menu. Vamos avaliar o grau no qual essa
arquitetura suporta essa modificao. Perceba que a arquitetura Serpent separou o controlador de dilogo e, portanto, fcil
verificar que a modificao proposta (adicionar uma opo de
menu) dever ser feita nesse processo. O controlador de dilogo
possui dois componentes: o gerente de dilogo, responsvel por
comandar o comportamento do dilogo, e o banco de dados
ativo, o qual mantm o estado do dilogo. Esse cenrio, no
qual se deseja fazer uma modificao (adio de nova opo
de menu), est associado mudana no comportamento do
dilogo e, portanto, est isolado no gerente de dilogo. Adicionalmente, o gerente de dilogo subdividido em componentes
menores associados a partes especficas do comportamento do
dilogo como, por exemplo, um menu. Desse modo, pode-se
concluir que a arquitetura Serpent fornece suporte apropriado
a este tipo de cenrio envolvendo modificao no aspecto de
um sistema interativo.
Uso de Atributos de Qualidade na Anlise Arquitetural

Uma das razes de concentrar ateno sobre a arquitetura para
identificar e analisar as decises iniciais de projeto. Transformar
estas decises de projeto em uma estrutura que oferea suporte a
um raciocnio que permita antecipar tendncias a nvel arquitetural essencial para obter os benefcios do foco na arquitetura.
Embora possamos apontar indicativos de qualidade, seria
praticamente impossvel fazer previso de qualidade num
estgio inicial de projeto. Note que, por exemplo, o mtodo de
anlise arquitetural SAAM no objetiva precisamente prever o
comportamento de atributos de qualidade. A meta desse mtodo de anlise d-se em entender o papel e as conseqncias de
decises arquiteturais em relao aos atributos de qualidade
de algum sistema que esteja sendo analisado.
Dessa forma, o mtodo SAAM apresentado serve de ferramenta ao arquiteto ou engenheiro de software para prever
suporte a atributos de qualidade. Note que isto baseado em
decises de projeto que ocorrem no nvel arquitetural.
Sabemos que a arquitetura um elemento essencial para a
obteno de sucesso, em termos tecnolgicos e de mercado de
qualquer empresa. Geralmente, as metas de qualidade e conjunto de funcionalidades constituem os principais motivadores de
um sistema. Considere, por exemplo, um fabricante de centrais
telefnicas que esteja desenvolvendo um projeto de uma nova
central. Assim, pode ser especificado que a central deve ser
capaz de rotear ligaes telefnicas, prover suporte a diversos
tipos de tons, redirecionar ligaes, gerar contas telefnicas de
usurios com discriminao de ligaes efetuadas, dentre outras
funcionalidades. Entretanto, para que o sistema alcance sucesso
na prestao de servios para seus assinantes, ele deve tambm
operar com elevado nvel de desempenho, facilitar quaisquer
modificaes (em termos de adio ou alterao de caractersticas), possuir bom nvel de disponibilidade e ter baixo custo.
Como essas metas de qualidade podem ser alcanadas?
A arquitetura do sistema um meio pelo qual podemos determinar se essas metas de qualidade podem ser realizveis ou
no. SAAM e outros mtodos constituem respostas a essa questo. Perceba que essa necessidade de prever o comportamento
de atributos de qualidade num sistema requer conhecimento
de estilos arquiteturais provveis de serem empregados no
sistema. Um estilo arquitetural inclui:
Descrio de tipos de componentes e sua topologia;
Descrio de padro de interao (no nvel de dados e controle) entre os componentes;
Descrio informal das vantagens e desvantagens na adoo
do estilo.
Estilos arquiteturais permitem ao arquiteto de software
distinguir classes de projeto atravs de evidncias existentes
de como cada classe tem sido utilizada juntamente com o
raciocnio qualitativo para explicar porque certas classes tm
determinadas propriedades. Assim, por exemplo, pode-se
adotar o estilo arquitetural de pipes e filtros quando se deseja
obter reuso e no h restrio quanto ao desempenho.
Agora, pode ser feito um mapeamento de um estilo arquitetural em um conjunto de modelos de atributos de qualidade.
Estes modelos de atributos de qualidade ajudam a prever o
comportamento desses atributos. Esta noo de mapeamento
de decises e propriedades arquiteturais em modelos de atributos de qualidade ilustrada na Figura 8.
decises
arquiteturais
propriedades
arquiteturais
parmetros de modelos
de atributo de qualidade
estmulos
comportamento
exibido
modelos de atributo
de qualidade
comportamento
desejado
comportamento
previsto
Figura 8. Mapeamento de modelos arquiteturais em modelos de atributos.
importante observar que decises arquiteturais influenciam direta e indiretamente no comportamento apresentado
pela arquitetura. Como poderamos caracterizar esse comportamento? Considere, por exemplo, a alocao de funcionalidade
a um conjunto de processos. Isto requer que o arquiteto ou
engenheiro de software tome decises arquiteturais. Disto
resulta que tais processos precisam ser alocados a processadores, requerendo ainda mais decises arquiteturais. Note que,
associado a eles, temos um conjunto de tempos de execuo
de processo, os quais constituem propriedades arquiteturais.
Dessa forma, as propriedades arquiteturais, em conjunto com
estmulos (tais como taxa de chegada de mensagens), nos leva
a um comportamento de desempenho exibido pelo sistema.
importante observar que, para avaliar uma arquitetura em
funo de requisitos no funcionais, necessrio expressar esses
requisitos ou atributos de qualidade em termos mensurveis, denominado de medidas de atributos de qualidade. Tais medidas
dependem de propriedades da arquitetura ou parmetros de
atributos de qualidade e dos estmulos. Considere como atributo
de qualidade o desempenho. Esse requisito pode ser expresso
em termos das seguintes medidas de atributo de qualidade:
Latncia - tempo da ocorrncia de um evento at a resposta
quele evento, dado em unidades de tempo;
Throughput taxa na qual o sistema pode responder a eventos, dada em transaes por unidades de tempo.
Os estmulos podem ser vistos como mudanas de estado ao
qual a arquitetura deve responder. Se, novamente, considerarmos o desempenho, temos o padro de chegada de um evento
que pode ser peridico, espordico ou probabilstico. Se um
estmulo ocorre, ento o sistema deve responder fazendo uso
de seus recursos para realizar alguma computao.
Note que analisar uma arquitetura uma atividade investigativa
na qual o avaliador busca saber quo bem uma arquitetura tem
sido projetada em relao aos requisitos no funcionais desejados
para o sistema. Tais requisitos esto intrinsecamente associados
qualidade do sistema. Um arquiteto de software, ao tomar decises
de projeto, busca maximizar os benefcios obtidos com o sistema
e, ao mesmo tempo, minimizar os custos de implementao do
projeto. Note que as metas de negcios de uma empresa tambm
tm influncia sobre decises arquiteturais tomadas pelo projetista.
Essas decises tm implicaes tcnicas e econmicas.
As implicaes tcnicas compreendem as caractersticas do
sistema de software e os atributos de qualidade desejados. As
implicaes econmicas referem-se ao custo de implementar o
sistema. A Figura 9 ilustra o contexto das decises arquiteturais
e implicaes associadas.
Considerando a Figura 9, tem-se que a determinao dos
custos e benefcios associados s decises arquiteturais pode
ser obtida atravs de:
Avaliao da importncia dos requisitos no funcionais;
Quantificao dos escores de benefcios dos requisitos no
funcionais;
Quantificao dos custos dos requisitos no funcionais;
Escolha de cenrios e estratgias de projeto arquitetural.
55
influenciadores
metas de
negcios
cenrios
desempenho
Decises
arquiteturais
confiabilidade
benefcios
segurana
custos
...
Figura 9. Contexto de decises arquiteturais e implicaes associadas.
O mtodo de anlise arquitetural SAAM foi apresentado,

ilustrando-se os passos de como fazer a anlise. Adicionalmente, foi discutido o papel dos requisitos no funcionais, ou
atributos de qualidade, como mecanismo para auxiliar nas
decises arquiteturais. Cabe destacar que a anlise arquitetural
realizada sob a ptica de minimizar custos e agregar benefcios, isto , prover suporte aos requisitos no funcionais.
Links
56
SEIs Software Architecture Technology Initiative

www.sei.cmu.edu/architecture/sat_init.html
The Serpent Runtime Architecture and Dialogue Model
http://www.sei.cmu.edu/pub/documents/88.reports/pdf/tr06.88.pdf
The Software Architecture Portal
http://www.softwarearchitectureportal.org/

Feedback
eu
sobre e
s
Neste artigo, um conjunto de propriedades de arquitetura de software consideradas intrnsecas estrutura do

sistema foi apresentado. Estas propriedades, juntamente
com os requisitos arquiteturais, envolvendo requisitos no
funcionais e atributos de projeto, servem de base para a
anlise arquitetural.
SAAM: A Method for Analyzing the Properties of Software Architectures

http://www.sei.cmu.edu/publications/articles/saam-metho-propert-sas.html
D
s
Concluso
Scenario-Based Analysis of Software Architecture

http://www.sei.cmu.edu/architecture/scenario_paper/
edio
ta
importante observar que, para quantificar e compreender de uma forma consistente o impacto que as estratgias
de projeto arquitetural tm sobre os atributos de qualidade, os influenciadores necessitam de uma representao
mais concreta dos atributos de qualidade. Para este propsito, cenrios devem ser utilizados. Durante a anlise
arquitetural, a elicitao e anlise de cenrios permitem
a caracterizao de atributos de qualidade. Esses cenrios especificam caractersticas envolvendo estmulos e
respostas concretizando os atributos de qualidade. Isto
permite que os influenciadores possam avaliar os efeitos
desses atributos. Esta avaliao centrada na premissa de
maximizar os benefcios obtidos com a arquitetura de um
sistema e, ao mesmo tempo, minimizar os custos associados
com sua implementao.
AMIGO
Existem coisas
que no
conseguimos
ficar sem!
...s pra lembrar,

sua assinatura pode
estar acabando!
Renove J!
www.devmedia.com.br/renovacao
Para mais informaes:
www.devmedia.com.br/central
57
Ontologias
Filosofia aplicada Engenharia de Software?
Este artigo apresenta uma introduo ao tema
Ontologias, destacando seus principais conceitos e
aplicaes na Engenharia de Software.
N
Monalessa Perini Barcellos
monalessa@inf.ufes.br
Doutoranda em Engenharia de Sistemas

e Computao (COPPE/UFRJ), Mestre em
Engenharia de Sistemas e Computao (COPPE/UFRJ), Bacharel em Cincia da Computao (UFES). Professora do Departamento
de Informtica, rea Engenharia de Software, da Universidade Federal do Esprito Santo
(UFES). Atuante, desde 1999, em projetos,
consultorias, treinamentos e pesquisas da
rea de Engenharia de Software.
58
a ltima dcada, a utilizao

do termo ontologia tem sido
relativamente comum em Cincia da Computao, especialmente em
Engenharia de Software. Esse termo, com
origem na Filosofia, inicialmente soou de
forma cacofnica aos ouvidos dos estereotipados como exatos profissionais da
computao. No entanto, aos poucos foi
possvel perceber que, ao contrrio do que
muitos pensavam, aspectos filosficos
esto presentes em praticamente todas
as atividades relacionadas ao desenvolvimento de software. Essa percepo
abriu espao para que os princpios das
ontologias fossem eficientemente aplicados na Engenharia de Software.
Filosoficamente falando, uma ontologia pode ser definida como um sistema
particular de categorizao para uma
certa viso do mundo, independente da
linguagem. Nossa... parece complicado?
Mas, de fato, no .
Engenharia de Software Magazine - Ontologias
Para que serve?

Fornecer conhecimento essencial sobre ontologias
para organizaes, pesquisadores, estudantes e profissionais de software.

Definio de vocabulrio comum, claro e sem ambiguidades, seja visando a representao, compartilhamento e reuso de conhecimento, seja a interoperabilidade semntica entre sistemas.
Veja bem, trazendo esse conceito para a

computao (Inteligncia Artificial, Engenharia de Software e Web Semntica),
uma ontologia pode ser definida como um
artefato de engenharia. Ento, voc deve
estar pensando: - Agora sim! Artefato e
engenharia eu sei bem o que so!.
Continuando: esse artefato de engenharia formado por um vocabulrio
usado para descrever certa realidade
e por um conjunto de conjecturas
explcitas relacionadas ao significado
Engen haria de Soft ware
pretendido das palavras do vocabulrio. Complicou de novo?

Nada disso... Vamos continuar.
Esse conjunto de conjecturas tem, geralmente, a forma
da teoria de lgica de primeira ordem (opa! Essa familiar no?), onde as palavras do vocabulrio aparecem
como nomes de predicados unrios ou binrios, respectivamente chamados conceitos e relaes. No caso mais
simples, uma ontologia descreve uma hierarquia de conceitos relacionados. Em casos mais sofisticados, axiomas
apropriados devem ser adicionados a fim de expressar
outros relacionamentos entre conceitos e restringir a
interpretao pretendida.
Pronto! Se voc analisar o pargrafo anterior vai concluir que,
na prtica, para a Engenharia de Software, uma ontologia pode
ser vista como um modelo que representa conceitos e relaes,
bem como suas restries. Isso no lhe parece familiar? No
remete a um modelo conceitual produzido na fase de Anlise
no desenvolvimento de sistemas? No lembra um diagrama
de classes UML, por exemplo?
Essa similaridade to grande que muito comum a utilizao de perfis UML na definio das ontologias. Por exemplo,
uma ontologia que descreve o vocabulrio relacionado oferta
e matrcula em disciplinas em uma instituio acadmica
poderia incluir o fragmento ilustrado na Figura 1.
importante perceber que, uma mesma ontologia pode,

por exemplo, apoiar a definio de vrios modelos de classes
diferentes, uma vez que sua principal preocupao com o
contedo e no com a forma. Ou seja, apesar de comumente uma ontologia ser definida com um vocabulrio que
representa elementos conceituais e suas relaes, de fato
ela no o vocabulrio propriamente dito, e sim o que ele
representa, uma vez que traduzir esse vocabulrio para uma
outra linguagem no muda a ontologia. A ontologia define os
conceitos, relaes e interpretaes pertinentes a uma parte
do mundo que ela representa. A forma como seu contedo,
ou seja, seu vocabulrio, utilizado, pode variar de acordo
com o contexto de aplicao.
Isso quer dizer que, como dito anteriormente, uma mesma
ontologia pode ser utilizada como fonte de informao para a
construo de modelos diferentes de sistemas diferentes. Mas,
se esses modelos forem corretamente elaborados levando-se
em considerao o vocabulrio representado pela ontologia,
eles sero semanticamente equivalentes e a comunicao
entre os sistemas ser possvel, ou seja, eles podero ser mais
facilmente integrados.
Para conhecer um pouco mais sobre ontologias, nas sees
seguintes so apresentados seu histrico, destacando-se
sua aplicao em Engenharia de Software, seus principais
tipos e alguns dos benefcios de sua utilizao em Engenharia de Software.
Histrico
Figura 1. Fragmento hipottico de uma ontologia

que inclui oferta e matrcula em disciplinas.
Ao diagrama seriam acrescentados axiomas para formalizar

algumas restries no capturadas explicitamente como, por
exemplo, um axioma para restringir que um aluno s deve
cumprir disciplinas do seu curso (lembrando que essa apenas
uma situao hipottica para efeito de exemplo). Esse axioma
poderia ser assim representado:
( a Aluno, d Disciplina, c Curso) cumpre(a,d) (possui (c, d) cursa(a, d))
Indiscutivelmente, o fragmento apresentado na Figura 1

tambm poderia ser utilizado no modelo de classes de um
sistema de apoio realizao da oferta e matrcula, bem como
o axioma poderia ser transformado em uma regra de negcio.
Ento, uma ontologia um modelo de classes? No. Essa
apenas uma analogia til ao entendimento de ontologias
Engenharia de Software. De uma maneira geral, ambos so
modelos conceituais.
Ontologias tm sido reconhecidas como um instrumento

conceitual bastante til na Cincia da Computao desde a
dcada de 60, tendo havido nos ltimos oito anos uma exploso
de trabalhos relacionados a ontologias em diferentes reas da
Cincia da Computao.
A origem das ontologias se deu na Filosofia, sendo Aristteles
o primeiro filsofo ocidental a criar uma definio rigorosa
para ontologia, descrevendo-a como a cincia do ser enquanto
ser. Segundo Aristteles, o objetivo de uma ontologia estudar
as caractersticas mais gerais da realidade e dos objetos reais,
ou seja, estudar as caractersticas de todos os tipos de seres.
Somente no sculo XVII o termo ontologia foi formalmente
utilizado, sendo citado paralelamente pelos filsofos Rudolf
Gckele e Jacob Lorhard, e sendo popularizado em 1730 com
a publicao do livro Philosophia Prima Sive Ontologia, de
Christian Wolff.
No sculo XX, o filsofo alemo Edmund Husserl, fazendo
analogia Lgica Formal, criou o termo Ontologia Formal.
A Lgica Formal lida com estruturas lgicas formais (por
exemplo: verdade, validade e consistncia) independente de
suas veracidades. A Ontologia Formal, por sua vez, lida com
estruturas ontolgicas formais (por exemplo: teoria das partes,
teoria do todo, tipos e instanciaes, identidade, dependncia
e unidade). Em outras palavras, Ontologia Formal lida com
aspectos formais de objetos, desprezando suas naturezas
particulares. A partir de ento, uma srie de teorias sobre
ontologias foram desenvolvidas ao longo do sculo XX.
59
A utilizao do termo ontologia em Computao se deu pela

primeira vez em 1967 por G. Mealy. Na dcada de 90, comunidades de Inteligncia Artificial mostraram intenso interesse
na utilizao de ontologias para criar representaes formais
de conhecimento sobre domnios especficos. Nesse momento, percebeu-se que ontologias poderiam ser utilizadas em
Computao para a obteno de uma uniformidade de vocabulrio (conceitos e relaes entre conceitos), de forma a evitar
ambiguidades e inconsistncias, propiciando, entre outros, o
compartilhamento e a reutilizao de conhecimento.
Somente nos primeiros anos do sculo XXI houve realmente
uma intensificao de trabalhos relacionados s ontologias
em reas como Sistemas de Informao, Bancos de Dados,
Engenharia de Software e Inteligncia Artificial, tendo sido
impulsionados, sobretudo, pelo crescente interesse em Web
Semntica e no papel desempenhado pelas ontologias nesse
contexto.
Em Engenharia de Software, a primeira proposta conhecida
para aplicao de ontologias foi apresentada por T. Gruber em
1993. Nessa rea, ontologias tm sido tipicamente utilizadas
para reduzir ambiguidades conceituais, tornar transparentes
as estruturas de conhecimento, apoiar o compartilhamento de
conhecimento e apoiar interoperabilidade entre sistemas, tendo
destaque sua utilizao no ramo da Engenharia de Domnio.
O propsito Engenharia de Domnio identificar, modelar,
construir, catalogar e disseminar um conjunto de artefatos
de software que possam ser utilizados e compartilhados por
engenheiros de software durante o desenvolvimento ou manuteno de software em um domnio particular de aplicao.
Um dos principais produtos da Engenharia de Domnio o
Modelo de Domnio, que descreve os objetos e suas relaes
em um determinado domnio de discusso. Um modelo de
domnio deve ser uma fonte unificada de referncia quando
surgem ambiguidades na anlise de problemas ou durante a
implementao de componentes reutilizveis. Alm disso, deve
ser um repositrio de conhecimento e uma especificao para
o desenvolvedor de componentes reutilizveis.
Analisando-se o conceito de Modelo de Domnio possvel
identificar sua relao com ontologias, uma vez que ambos
buscam fornecer um entendimento uniforme e no ambguo de
objetos e suas relaes, provendo uma conceituao acerca de
um determinado domnio. Ou seja, na prtica, uma ontologia
de domnio pode ser utilizada como um modelo de domnio.
Sob o ponto de vista da Engenharia de Software, a que

reside a grande diferena entre um modelo de anlise e uma
ontologia. Ou seja, existem aspectos que so considerados em
uma ontologia e que, normalmente so ignorados em modelos
baseados estritamente em uma viso mais tcnica (que busca
uma soluo especfica), o que pode, em uma situao futura,
representar problemas.
A Figura 2 mostra os quatro tipos de ontologias e seus relacionamentos. Suas definies so descritas em seguida.
Ontologia de
Fundamentao
Ontologia de
Domnio
Ontologia de
Tarefa
Ontologia de
Aplicao
Figura 2. Relacionamentos entre os tipos de ontologias segundo Guarino.
Conforme ilustrado na Figura 2, ontologias de Fundamentao devem ser utilizadas como base para a construo de
ontologias de Domnio e de Tarefa e essas, por sua vez, devem
ser utilizadas como base para construo de ontologias que
tratam de aplicaes especficas.
Ontologia de Fundamentao
Uma ontologia de fundamentao (tambm chamada ontologia genrica ou ontologia de nvel superior) , teoricamente,
uma conceituao abstrata sobre elementos genricos demais
para fazer parte de um domnio especfico, como espao, tempo, matria, objeto, evento e ao. Essas ontologias podem ser
utilizadas como meta-modelo para ontologias de domnio e
tarefa, visto que cada conceito ou propriedade de uma dessas
ontologias pode ser mapeado em um conceito de uma ontologia
de fundamentao. Na Figura 3 apresentado um fragmento
hipottico de uma ontologia de fundamentao.
Tipos de Ontologias
Vrias so as classificaes de ontologias encontradas na
literatura. Aqui apresentada a classificao definida por
Nicola Guarino (1998).
Nicola Guarino um dos pesquisadores de ontologias que,
ao analisarem a aplicao das ontologias em Computao,
ressaltam que alm dos aspetos tcnicos inerentes a essa rea,
h tambm aspectos filosficos, cognitivos e lingusticos envolvidos. Esses aspectos devem ser levados em considerao
no momento de construir as ontologias, caso contrrio sua
utilizao ser limitada.
60
Figura 3. Fragmento hipottico de uma ontologia de fundamentao.
Considerando os conceitos da Figura 3, uma ontologia de

fundamentao poderia definir que um Agente uma entidade
capaz de realizar aes, podendo ser Fsico (por exemplo, uma
pessoa) ou Social (por exemplo, uma organizao); e que um
Objeto uma entidade que no capaz de realizar aes, mas

pode participar delas, podendo ser Fsico (por exemplo, um
livro) ou Social (por exemplo, uma linguagem). A cada um
desses conceitos, a ontologia de fundamentao proveria um
conjunto de caractersticas e regras prprias.
Quando uma ontologia de fundamentao tomada como
base para a construo de ontologias de domnio ou de tarefa,
todo conceito dessas ontologias pode ser classificado em um
conceito da ontologia de fundamentao, herdando assim suas
caractersticas e regras.
No exemplo ilustrado na Figura 1, o conceito Aluno poderia
ser classificado como Agente segundo a definio hipottica da
Figura 3 e, como tal, teria todas as suas caractersticas filosficas, que dificilmente seriam capturadas se fosse considerada
apenas a viso tcnica necessria para elaborar um modelo de
classes de um software para solucionar a oferta e matrcula
em disciplinas de uma instituio especfica.
Ontologia de Domnio
Uma ontologia de domnio um artefato de Engenharia de
Software que expressa conceituaes de domnios particulares
(por exemplo: medicina, turismo e petrleo). Uma ontologia
de domnio deve especificar formalmente as relaes, regras
e excees de todos os elementos presentes na conceituao
da parte da realidade por ela mapeada.
Conforme mencionado anteriormente, ontologias de domnio
constituem a maior parte das aplicaes das ontologias na Engenharia de Software. Exemplos de ontologias definidas nesse
contexto so: ontologias de processo de software, ontologias
relacionadas manuteno de software, ontologias relacionadas qualidade de software, ontologias para requisitos de
software e ontologias relacionadas ao desenvolvimento de
software baseado em componentes.
O exemplo ilustrado na Figura 1 pode ser considerado um substrato
hipottico de uma ontologia para o domnio Ensino Universitrio.
Ontologia de Tarefa
Uma ontologia de tarefa similar a uma ontologia de domnio, porm, ao invs de mapear os conceitos de um domnio
particular, mapeia conceitos de uma tarefa ou atividade especficos (por exemplo: diagnstico, venda e matrcula).
Ontologia de Aplicao
Uma ontologia de aplicao descreve conceitos que so dependentes de um domnio e de uma tarefa particulares e, assim,
combina especializaes de conceitos presentes nas ontologias
de domnio e de tarefa.
Benefcios da Utilizao das Ontologias em

Engenharia de Software
Conforme dito antes, ontologias podem ser utilizadas para descrever o vocabulrio comum de um determinado domnio. Na
Engenharia de Software, a definio de vocabulrios comuns, cobrindo todos os aspectos do mundo real (ou a maior parte possvel)
importante, pois propicia, entre outros, os seguintes benefcios:
Apia a captura, representao, pesquisa, armazenamento

e reutilizao do conhecimento referente Engenharia de
Software: sendo a Engenharia de Software uma rea composta
de muitas atividades cognitivas, a representao adequada do
conhecimento a ela relacionado, descrevendo um vocabulrio
consistente, completo e no ambguo, facilita a recuperao e
(re)utilizao desse conhecimento.
Apia a padronizao: em Engenharia de Software a padronizao desempenha um papel muito importante. A utilizao de
padres auxilia as organizaes a realizarem suas atividades
apoiadas por mtodos que reforam a Engenharia de Software como uma engenharia propriamente dita. Uma vez que o
conhecimento de Engenharia de Software adequadamente
representado e reutilizado, possvel deixar prticas ad-hoc
e adotar prticas padro e repetveis.
Apia reuso: alm de apoiar a reutilizao do conhecimento,
ontologias apiam o reuso de outros artefatos produzidos em
todas as etapas do processo de desenvolvimento de software. Isso
possvel, pois uma vez que todo o processo guiado por um vocabulrio comum, os artefatos produzidos so consistentes entre
si, podendo ser melhor reutilizados ao longo desse processo.
Apia a interoperabilidade: a utilizao da mesma semntica
permite que sistemas sejam integrados, mesmo que suas formas de representar a semntica sejam diferentes.
Apia a componentizao: uma vez que apiam o reuso e a
interoperabilidade, como consequncia, as ontologias apiam
a componentizao.
Facilita a comunicao: a utilizao de um vocabulrio comum
facilita a comunicao entre os envolvidos no desenvolvimento
de software, bem como entre os sistemas propriamente ditos.
Apia a captura, representao, pesquisa, armazenamento e
reutilizao do conhecimento referente aos diversos domnios
dos produtos e servios de software: da mesma maneira que
ontologias relacionadas Engenharia de Software so teis
aos engenheiros de software e desenvolvedores, ontologias
dos domnios especficos dos produtos e servios tambm
so importantes. Por exemplo, o desenvolvimento de um software para uma empresa do segmento de petrleo pode ser
mais eficiente se apoiado por uma ontologia que descreve o
vocabulrio do domnio petrolfero.
Concluso
Apesar de ter uma abordagem predominantemente filosfica,
as ontologias tm sido eficientemente utilizadas em Engenharia de Software, principalmente quando se busca reutilizao
e interoperabilidade.
Muitas vezes, a integrao ou reutilizao de sistemas e/ou
componentes no possvel devido a problemas relacionados
semntica (e no tcnica) de alguns dos conceitos envolvidos.
Alm disso, limitaes em relao semntica do mundo real
tambm dificultam a integrao.
Algumas das caractersticas diretamente responsveis pela
reutilizao e interoperabilidade semntica entre sistemas so
a fidedignidade realidade e a clareza conceitual dos modelos
conceituais utilizados.
61
62
sobre e
s

Feedback
eu
edio
ta
D
s
Em resumo, quanto mais completos e claros forem os modelos conceituais utilizados, maiores sero as possibilidades
de reutilizao e interoperabilidade em sistemas. Sendo as
ontologias de domnio modelos conceituais, quando definidas
adequadamente, servem como arcabouos de referncia para o
alcance da reutilizao e interoperabilidade semntica.
Tendo em vista os benefcios da aplicao de princpios filosficos aos modelos conceituais da Computao, mais uma vez
temos que dar o brao a torcer e concordar que nossa cincia
exata, na verdade, no to exata assim.
Referncias
FALBO, R. A., GUIZZARDI, G., DUARTE, K. C., 2002, An Ontological Approach to Domain
Engineering, In Proceedings of the 14th International Conference on Software Engineering
and Knowledge Engineering, Ischia, Italy, pp. 351 358.
GRUBER, T. R., 1993, A Translation Approach to Portable Ontologies, Knowledge Acquisition,
Volume 5 (2), pp. 199-220.
GUARINO, N., 1998,Formal Ontology and Information Systems, In Proceedings of International
Conference in Formal Ontology and Information Systems - FOIS98, Trento, Italy, pp. 3-15.
GUIZZARDI, G., 2005, Ontological Foundations for Structural Conceptual Models, Universal
Press, The Netherlands, ISBN 90-75176-81-3.
GUIZZARDI, G., FALBO, R. A., GUIZZARD, R. S. S., 2008, Grounding Software Domain Ontologies
in the Unified Foundational Ontology (UFO): The case of the ODE Software Process Ontology,
In Proceedings of the XI Iberoamerican Workshop on Requirements Engineering and Software
Environments, Recife Brasil.
MEALY, G., 1967, Another Look at Data, In American Federation of Information Processing
Societies, Fall Joint Computer Conference, Volume 31.
PRESSMAN, R. S., 2004,Software Engineering: A Practitioners Approach, McGraw-Hill Science/
Engineering/Math, 6th edition.
63
64

Revista Engenharia de Software - Nr14

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Revista Engenharia de Software - Nr14

Enviado por

Direitos autorais:

Formatos disponíveis

Conhecimento

Capa ESM - Final .pdf

Entenda os principais conceitos sobre

Conhea os principais conceitos envolvidos

Entenda o conceito de Arquitetura de Software e

Melhore seus processos atravs da

Veja como integrar conceitos de

Veja como integrar o Processo

Mais de 60 mil downloads

Faa j sua assinatura digital! | www.devmedia.com.br/es

Ano 2 - 14 Edio 2009

A melhoria de processos algo que sempre procuramos, afinal, clara

Rodrigo Oliveira Spnola

Deise Aleis Atendimento ao Leitor

Fale com o Editor!

Marco Antnio Pereira Arajo

Eduardo Oliveira Spnola

Tipo: Engenharia de Requisitos

deste processo. Alm disso, fundamental para um processo de engenharia de requisitos

26 - Mudanas no PMBoK 4 Edio

30 - Gerenciamento de Mudanas em Projetos de TI

40 - Ciclo de Vida da Gesto em Arquitetura de Software

50 - Anlise da Arquitetura de Software

Engenharia de Software Magazine

Edio 05 - Engenharia de Software Magazine

Melhoria de Processo de Software no

Para que serve?

Professor Assistente das Faculdades Integradas

Professora Assistente do Departamento de

surgimento das metodologias

Engenharia de Software Magazine - Melhoria de Processo de Software no Desenvolvimento gil

Serve como fonte de exemplos de aplicaes da

Em que situao o tema til?

Baseado nesse contexto de mudana

iv. Avaliao dos resultados dos projetos de melhoria atravs

Manifesto gil e a Nova Cultura

Edio 14 - Engenharia de Software Magazine

Melhoria de Processo de Software

Engenharia de Software Magazine - Melhoria de Processo de Software no Desenvolvimento gil

distinta de trabalho, a estratgia por pedaos uma abordagem

MPS no Desenvolvimento gil de Software

experincia e sua disseminao por toda a equipe. Assim, o

Edio 14 - Engenharia de Software Magazine

Falando em mtricas para melhoria de processos, em

Engenharia de Software Magazine - Melhoria de Processo de Software no Desenvolvimento gil

A Engenharia de Software Magazine tem que ser feita ao seu gosto.

D seu feedback sobre esta edio!

A execuo da Melhoria de Processo de Software dentro de

Edio 14 - Engenharia de Software Magazine

De que se trata o artigo?

Engenheira de Computao pela Unicamp, com

O processo de software uma seqncia lgica de atividades com o objetivo

Engenharia de Software Magazine - Implantao de Processo

Neste artigo veremos quais so os principais desafios e benefcios da implantao de um processo

Para que serve?

Em que situao o tema til?

aqueles que se referem a satisfao dos

Atualmente, existem vrios modelos de processo de software

Figura 1. Fases do ProUD 2.0

Edio 14 - Engenharia de Software Magazine

As atividades desta fase so realizadas na fase de Transio do RUP.

Engenharia de Software Magazine - Implantao de Processo