Modéstia à parte, sua

melhor opção para

se destacar no mercado!
A Escola Superior da Tecnologia da PÓS- GRADUAÇÃO
Informação oferece as melhores Engenharia de Software:
opções em cursos, formações, Desenvolvimento Java
graduações e pós-graduações para Engenharia de Software:
Desenvolvimento .NET
profissionais de desenvolvimento
GRADUAÇÃO
e programação.
Engenharia de Computação
São programas voltados para a Análise e Desenv. de Sistemas
formação de profissionais de elite,
F ORMAÇÕES
com aulas 100% práticas, corpo
Desenvolvedor Java
docente atuante no mercado,
Desenv. Java: Sist. Distribuídos
acesso à mais atualizada biblioteca
Gestor de TI
de TI do Rio, laboratórios equipados
Desenvolvedor Web .NET 2008
com tecnologia de ponta, salas de
MCITP Server Administrator
estudo e exames.
SQL Server 2008

r/esti
Acesse nosso site e conheça todos os nossos programas: www.infnet.edu.br/esti

TURMAS
NO RIO DE
JANEIRO
www.infnet.edu.br - cursos@infnet.edu.br - Central de Atendimento: (21) 2122-8800

EDUCAÇÃO SUPERIOR ORIENTADA AO MERCADO

 EDITORIAL

H
oje no Brasil, mais de 100 empresas foram avaliadas com sucesso no modelo
MPS.BR, e estas avaliações, mesmos para os níveis menos complexos, podem
ser extremamente difíceis. Neste cenário, a Engenharia de Software Magazine
destaca nesta edição uma matéria que descreve as experiências práticas de uma insti-
tuição na implementação do modelo.
Ano 2 - 22ª Edição - 2010 Impresso no Brasil Além disso, “desde 1º de Janeiro de 2010 as avaliações MPS estão seguindo somente
o modelo de referência MR-MPS: 2009. Por este motivo, organizações que estão imple-
mentando o modelo para a futura avaliação ou reavaliação devem levar em considera-
Corpo Editorial ção as mudanças dos guias da versão 1.2 para a versão 2009, pois isto pode ser decisivo
para o sucesso de uma avaliação MPS. Além das avaliações, é importante lembrar que os
Colaboradores
Rodrigo Oliveira Spínola guias descrevem requisitos e condições para quem quer se tornar um avaliador adjunto,
rodrigo@sqlmagazine.com.br avaliador líder ou consultor de Aquisição MPS, também apresenta orientações para cria-

Marco Antônio Pereira Araújo ção de novas Instituições Implementadoras (II) e Instituições Avaliadoras (IA).”
Eduardo Oliveira Spínola Por conta disto, destacamos também nesta edição as principais mudanças ocorridas
nos guias do modelo MPS versão 2009, além de apresentarmos os novos guias que des-
Capa
Romulo Araujo - romulo@devmedia.com.br crevem orientações para organizações que realizam atividades específicas do processo
de software.
Diagramação
Por fim, apresentamos através do artigo Experiências da Domínio Informática na Im-
Janete Feitosa
plantação do MPS.BR, a experiência da Domínio Informática com a definição e imple-
Coordenação Geral mentação dos seus processos de desenvolvimento de software, aderentes ao modelo
Daniella Costa - daniella@devmedia.com.br
de maturidade MPS.BR.
Revisor e Supervisor Além destas três matérias, esta edição traz mais cinco artigos:
Thiago Vincenzo - thiago.v.ciancio@devmedia.com.br • Experiência em automação de testes
Na Web • ITIL: Por onde começar?
www.devmedia.com.br/esmag • Arquitetura Orientada a Serviços
Apoio
• Arquitetura de Software
• Gerenciamento de Defeitos em Projetos de Software

Desejamos uma ótima leitura!

Equipe Editorial Engenharia de Software Magazine

Atendimento ao Leitor
A DevMedia conta com um departamento exclusivo para o atendimento ao leitor. Rodrigo Oliveira Spínola
Se você tiver algum problema no recebimento do seu exemplar ou precisar de rodrigo@sqlmagazine.com.br
algum esclarecimento sobre assinaturas, exemplares anteriores, endereço de Doutorando em Engenharia de Sistemas e Computação (COPPE/UFRJ). Mestre em
bancas de jornal, entre outros, entre em contato com: Engenharia de Software (COPPE/UFRJ, 2004). Bacharel em Ciências da Computa-
ção (UNIFACS, 2001). Colaborador da Kali Software (www.kalisoftware.com), ten-
Cristiany Queiróz– Atendimento ao Leitor do ministrado cursos na área de Qualidade de Produtos e Processos de Software,
www.devmedia.com.br/mancad
(21) 2220-5338 Requisitos e Desenvolvimento Orientado a Objetos. Consultor para implementação
Kaline Dolabella do MPS.BR. Atua como Gerente de Projeto e Analista de Requisitos em projetos de
Gerente de Marketing e Atendimento consultoria na COPPE/UFRJ. É Colaborador da Engenharia de Software Magazine.
kalined@terra.com.br
(21) 2220-5338
Marco Antônio Pereira Araújo
(maraujo@devmedia.com.br)
Publicidade
Doutor e Mestre em Engenharia de Sistemas e Computação pela COPPE/UFRJ - Li-
Para informações sobre veiculação de anúncio na revista ou no site entre em
nha de Pesquisa em Engenharia de Software, Especialista em Métodos Estatísticos
contato com:
Computacionais e Bacharel em Matemática com Habilitação em Informática pela
Kaline Dolabella
publicidade@devmedia.com.br UFJF, Professor e Coordenador do curso de Bacharelado em Sistemas de Informação
do Centro de Ensino Superior de Juiz de Fora, Professor do curso de Bacharelado
Fale com o Editor!
em Sistemas de Informação da Faculdade Metodista Granbery, Professor e Diretor
É muito importante para a equipe saber o que você está achando da revista: que tipo de artigo
do Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas da
você gostaria de ler, que artigo você mais gostou e qual artigo você menos gostou. Fique a
Fundação Educacional D. André Arcoverde, Analista de Sistemas da Prefeitura de
vontade para entrar em contato com os editores e dar a sua sugestão!
Juiz de Fora, Colaborador da Engenharia de Software Magazine.
Se você estiver interessado em publicar um artigo na revista ou no site SQL Magazine,
entre em contato com os editores, informando o título e mini-resumo do tema que você
Eduardo Oliveira Spínola
(eduspinola@gmail.com)
gostaria de publicar:
É Colaborador das revistas Engenharia de Software Magazine, Java Magazine e
Rodrigo Oliveira Spínola - Colaborador
SQL Magazine. É bacharel em Ciências da Computação pela Universidade Salva-
editor@sqlmagazine.com.br
dor (UNIFACS) onde atualmente cursa o mestrado em Sistemas e Computação na
linha de Engenharia de Software, sendo membro do GESA (Grupo de Engenharia
de Software e Aplicações).
 Caro Leitor, ÍNDICE

Para esta edição, temos um conjunto de 4 vídeo aulas. Estas vídeo aulas
estão disponíveis para download no Portal da Engenharia de Software
Magazine e certamente trarão uma significativa contribuição para seu
aprendizado. A lista de aulas publicadas pode ser vista abaixo:
Tipo: Requisitos
Título: Diagrama de Casos de Uso na Prática – Partes 8 e 9
Autor: Rodrigo Oliveira Spínola
Mini-Resumo: Estas aulas são parte de uma série sobre a
construção de diagrama de casos de uso da UML. O objetivo do
conjunto de aulas é apresentar de forma prática como elaborar o
diagrama de casos de uso a partir de diferentes estudos de caso.
Nestas aulas, serão elaborados diversos diagramas de casos de uso.
Também será visto como especificar um caso de uso para um dos
diagramas elaborados.
Tipo: Validação, Verificação & Teste
Título: Introdução a Testes de Software – Partes 1 e 2
Autor: Arilo Cláudio Dias Neto
Mini-Resumo: Nestas aulas iremos discutir os principais conceitos
relacionados às atividades de teste, as principais técnicas e critérios
de teste que podem ser utilizados para verificação ou validação de
um produto, assim como exemplos práticos da aplicação de cada
tipo de técnica ou critério de teste.
Abordagens Ágeis de Desenvolvimento
05 - Experiência em automação de testes
Eliane Collins e Luana Lobão
Abordagens Tradicionais de Desenvolvimento
11 - Guias 2009 do MPS.BR: o que mudou?
Davi Viana dos Santos
18 - Fatores críticos de sucesso em programas de melhoria de processo
Geovane Nogueira Lima e Marcos André Gomes
23 - ITIL: Por onde começar?
Samuel Diniz Casimiro
30 - Arquitetura Orientada a Serviços
Jorge Dias Jr.
36 - Arquitetura de Software
Antonio Mendes da Silva Filho
46 - Experiências da Domínio Informática na Implantação do MPS.BR
Ticiana da Mota Gentil Parente e Adriano Bessa Albuquerque
Validação, Verificação e Teste
52 - Gerenciamento de Defeitos em Projetos de Software
Jenifer Vieira Toledo, Marcelo Santos Daibert e Marco Antônio Pereira Araújo

4 Engenharia de Software Magazine

Abordagens Ágeis de Desenvolvimento
Esta seção traz artigos que apresentam como e quando utilizar as diferentes
abordagens ágeis de apoio ao desenvolvimento de projetos de software
Experiência em Automação de Testes
Utilizando ferramentas Open Source em Ambiente Ágil de Desenvolvimento
com SCRUM
Eliane Collins
elianecollins@gmail.com
Mestranda de Engenharia elétrica pela
Universidade Federal do Amazonas, MBA
em Gerenciamento de Projetos e Bacharel
em Engenharia de Computação pela Uni-
versidade Estadual do Amazonas, 7 anos
atuando no desenvolvimento de Software,
desses 4 anos em Teste de Software. Traba-
lha atualmente no Instituto Nokia de Tec-
nologia – INdT, como Pesquisadora, onde
lidera uma equipe de teste de software e
desenvolve sistemas Web.
Luana Lobão
lulobaum@gmail.com
Atua no ramo de tecnologia e teste de
software, é formanda no curso de Proces-
samento de Dados.Trabalha atualmente no
Instituto Nokia de Tecnologia - INdT, com
automação de teste em sistemas desenvol-
vidos na plataforma WEB e Desktop.
E
ste artigo descreve de maneira
prática a experiência de se adotar
ferramentas de automação de
teste no processo de desenvolvimento
ágil Scrum. Ao se adotar um processo
de teste nota-se a melhora, estabilidade e
o amadurecimento do software. As van-
tagens de se automatizar esse processo
com ferramentas abertas vão desde o
ganho em tempo de teste e prevenção de
defeitos, até a confiabilidade do cliente
pelo produto final, sem o aumento de
custos. Mais a frente, neste artigo, ve-
remos que foi possível automatizar o
gerenciamento, a elaboração e a execução
dos casos de testes, em um Sistema Web
desenvolvido em Ruby on Rails.
As metodologias ágeis de desenvol-
vimento de software se destacam dos
Edição 22 - Engenharia de Software Magazine
De que se trata o artigo?
Neste artigo compartilhamos experiências sobre
a automação do processo de teste de um Sistema
WEB desenvolvido utilizando SCRUM. Mostramos
as vantagens e desvantagens de se adotar esta
técnica de qualidade no ambiente de trabalho.
Para que serve?
A Automação de um Processo de Teste, que tem
como objetivo garantir a qualidade de projetos de
software, oferece notáveis vantagens quando o
ambiente de desenvolvimento é executado a par-
tir de uma Metodologia Ágil de desenvolvimento
como o Scrum.
Em que situação o tema é útil?
Além de ser uma boa prática para se adotar
em processos de teste, a automação de casos
de teste garante um aumento na qualidade
do software sem elevar o custo para isso. Com
o auxílio de soluções open source é possível
chegar a um nível satisfatório de qualidade e
confiabilidade do projeto de software.
processos de desenvolvimento tradicio-
nais devido, principalmente, ao fato de
darem prioridade ao desenvolvimento
de funcionalidades através de código
5
executável ao invés da produção de extensa documentação
escrita, e ainda, respostas rápidas às mudanças e colaboração
com o cliente ao invés de seguir planos rígidos e negociações
contratuais [Leal (2009)].
Tão importante quanto o processo de desenvolvimento de um
projeto de software, o processo de qualidade envolvido requer
planejamento e atenção, visto que garantir a qualidade do sof-
tware desenvolvido é tão significante quanto a sua codificação.
Assim como a qualidade do produto deve ser alcançada em
um meio de desenvolvimento clássico, ela também precisa ser
levada em consideração nos ambientes ágeis.
Tem sido cada vez mais custoso e desafiador o processo
de qualidade nos dois modos de desenvolvimento, seja pela
complexidade do produto, por questões técnicas envolvidas,
pelo próprio planejamento equivocado do projeto, e algumas
vezes pela falta de um processo estruturado de qualidade e
de desenvolvimento.
Salvo algumas exceções, a maioria das empresas opta por
garantir um nível de qualidade através de testes manuais, após
o término de módulos específicos ou até mesmo do sistema
inteiro [Bernardo e Kon (2008)]. Isso é uma escolha que pode
acarretar sérios problemas, comprometendo o andamento dos
processos de desenvolvimento e teste.
Este artigo tem como fundamental objetivo compartilhar uma
experiência prática no uso de automação de testes funcionais
em um ambiente de desenvolvimento conduzido pelo SCRUM.
No decorrer do artigo mostraremos as notáveis vantagens e as
dolorosas desvantagens de se adotar tal prática de qualidade
no dia-a-dia de trabalho.
Automação de Testes
Automatizar testes significa fazer uso de softwares que
controlem a execução dos casos de teste. O uso desta prática
pode reduzir significativamente o esforço necessário para os
testes em um projeto de software, ou seja, executar maiores
quantidades de testes em tempo reduzido. Testes manuais que
levariam horas para serem totalmente executados poderiam
levar minutos caso fossem automatizados [Tuschling (2008)].
Apesar dos testes manuais também encontrarem erros em
uma aplicação, é um trabalho desgastante que consome muito
tempo. Automatizar seus testes significa executar mais testes,
com mais critérios, em menos tempo e sem muito esforço na
execução. Sem contar as inúmeras possibilidades que um script
automático traz, como: cobertura de requisito e profundidade
nos testes, além de ser efetivo quanto à quantidade de dados
de entrada que podem ser processadas.
As principais vantagens de transformar suas rotinas de testes
em scripts automáticos são:
• Extensibilidade: diferente de testes manuais, testes automa-
tizados podem prever inúmeros fluxos que ficariam inviáveis
de se fazer manualmente, contribuindo para maior extensibi-
lidade de testes no sistema;
• Confiabilidade: testes automáticos são mais efetivos na
procura de erros que envolvem estruturas de código, como
classes, métodos, etc.;
6 Engenharia de Software Magazine - Experiência em Automação de Testes
• Segurança: fazer testes manuais para garantir que o sistema
está seguro contra ataques de terceiros é custoso e acarreta um
esforço e tempo enorme. Testes de vulnerabilidades técnicas e
lógicas podem ser feitos com mais critérios se forem automa-
tizados com o auxílio de ferramentas;
• Reusabilidade: scripts de teste, se feitos com planejamento e
padronização, são perfeitamente reusáveis na maioria das etapas
de desenvolvimento. Portanto, o esforço necessário para a codi-
ficação de scripts de teste, não é, na sua totalidade, perdido;
• Manutenibilidade: sistemas que possuem longa vida no
mercado podem ter (em algum momento) que passar por ma-
nutenções em áreas de código e funcionalidades já testadas. Se
a lógica e o requisito não mudaram, os casos de teste que foram
automatizados anteriormente poderão testar o sistema nova-
mente. Nestes casos, é melhor fazer manutenção no caso de teste
do que escrevê-lo novamente ou executá-lo manualmente.
Testes melhores e mais elaborados contribuem para um au-
mento na qualidade do produto final. Porém, construir uma
suíte de scripts de teste automáticos requer uma padronização
de atividades e conhecimento de codificação e análise por
parte do testador. Para fazer testes automáticos eficientes, caso
o teste seja de unidade, é necessário entender a arquitetura
do software e a base do código. Caso o teste seja de sistema, é
necessário conhecer as regras de negócio, as funcionalidades
e os valores e situações permitidas como resultado.
Em todos os casos de automação, considerando testes de
unidade ou testes de sistema, o esforço necessário é maior. Isso
ocorre porque é necessário fazer um planejamento para saber
O QUÊ, COMO e POR QUE será automatizado. Só depois disso
deve-se passar para a confecção dos scripts automáticos.
Há diversas medidas que podem ser tomadas para se obter
testes melhores, mais ágeis, efetivos e baratos. Dentre estas
podemos citar: sistematizar as atividades de testes; definir
os papéis e responsabilidades vinculadas ao teste; antecipar
a preparação dos testes já durante as fases de construção; co-
nhecer as técnicas relacionadas ao tema; testar características
diferentes do software nas diferentes fases de testes; estimar
adequadamente os esforços para os testes; ter um controle
efetivo das falhas encontradas; e automatizar os processos de
testes, tanto planejamento quanto execução [Costa (2006)].
Técnicas de Automação
Existem basicamente duas abordagens para se automatizar
casos de teste, apesar de não se limitar a elas. A primeira
é utilizar Ferramentas baseadas em Interface Gráfica que
possuem capacidade de gravar e executar casos de teste. São
as ferramentas conhecidas como rec-and-play (Record and
Playback). Nessa abordagem a ferramenta interage diretamente
com a aplicação, simulando um usuário real. Na medida em
que a aplicação está sendo executada, a ferramenta oferece um
suporte de gravação: ela captura as ações e as transforma em
scripts. Estes podem ser executados posteriormente.
É bom frisar que para testes utilizando esta abordagem, o
software que será testado não precisa sofrer alteração alguma.
 Validação, Verificação e Teste
Não há necessidade de modificação, no sentido de padronizar
o código, para que a aplicação se torne fácil de testar (testa-
bilidade). Os testes nessa abordagem são baseados na mesma
interface gráfica que o usuário irá utilizar. O trabalho aqui é
encontrar uma ferramenta que ofereça o recurso necessário
para testar sua aplicação específica.
Existem ferramentas rec-and-play para aplicações Desktop e
Web. A maior desvantagem de se utilizar esta técnica de auto-
mação é que o script se torna “escravo” da interface da aplica-
ção. Para que scripts, utilizando esta abordagem, sejam criados,
as ferramentas fazem uso dos nomes e das propriedades dos
componentes que estão dispostos na interface da aplicação.
Se alguma mudança de posição, nome, tipo do componente,
ocorrer, o script “quebra”, ou seja, não funciona mais.
A segunda maneira de se automatizar os casos de teste é com
o uso de Lógica de Negócio (Script Programming). Neste caso
são observadas as funcionalidades da aplicação, sem interagir
com a interface gráfica. Com esta abordagem serão testadas das
maiores até as menores porções do código: funções, métodos,
classes, componentes, entre outros.
Geralmente é pedido que se faça uma alteração no código
para que o trabalho de automação fique fácil. Muitas vezes
o código é melhorado (Refactoring) e padronizado para que
se consiga testar mais facilmente e sem muitos problemas.
São necessários profissionais com conhecimento em código
e programação para criar os scripts automatizados. O uso
deste método traz muitos benefícios, por exemplo, testes que
necessitam de centenas de repetições, cálculos complexos e
até mesmo integração entre sistemas são feitos facilmente
utilizando esta abordagem.
Existem bibliotecas, ferramentas e frameworks que suportam
esta abordagem. Bons exemplos são: JUnit, para testar unidade
de código Java; FitNesse, que é um framework para testes de
aceitação; MbUnit, para testar a unidade em códigos .NET; Nes-
ter, para fazer testes de mutação em códigos C#; httpUnit, para
testar aplicações WEB; Cactus, para testar EJB; jfcUnit e Abbot,
para testar aplicações baseadas em interfaces gráficas.
Entre estas duas maneiras de se automatizar, o presente ar-
tigo tem como base a abordagem rec-and-play. É com ela que
compartilharemos as experiências, destacando suas vantagens
e desvantagens em um projeto web que foi desenvolvido uti-
lizando SCRUM.
Ambiente Ágil de Desenvolvimento – SCRUM
Scrum é uma metodologia extremamente ágil e flexível,
centrada na equipe, utilizada para o desenvolvimento in-
cremental e iterativo de qualquer produto, no caso do nosso
artigo, desenvolvimento de software [Bissi (2007)]. Suas
principais características são: auto-organização da equipe de
desenvolvimento, acompanhamento da evolução do produto,
desenvolvimento incremental das funcionalidades do produto
[Schwaber (2004)] e gerenciamento dos requisitos através do
documento chamado “backlog do produto”.
O esqueleto do Scrum é mostrado na Figura 1. O círculo maior
na figura representa o período em que ocorrerá a iteração de
atividades de desenvolvimento (Sprint). Geralmente é empre-
gado um período de duas semanas ou um mês para a iteração.
Ao final de cada iteração, incrementos do produto são gerados.
O círculo menor na figura representa as inspeções diárias
(daily meeting ou daily Scrum) que ocorrem durante as iterações.
Os membros da equipe se encontram para observarem o que
os outros estão fazendo, e fazer adaptações apropriadas, se
necessárias [Schwaber (2004)].
Figura 1. Esqueleto do Scrum
As histórias de usuário (requisitos de funcionalidade) que
deverão ser feitas vêm de um documento chamado Product
Backlog, que é usado pelo cliente (Product Owner) para gerir
os requisitos. No início de cada iteração é feita uma seleção
nesse documento para estabelecer quais funcionalidades (his-
tórias) serão desenvolvidas. É então gerado outro documento,
chamado Sprint Backlog, que contém apenas as histórias que
serão desenvolvidas no ciclo de iteração, ou seja, no Sprint.
Processos de teste para softwares desenvolvidos dessa maneira
usam geralmente as histórias de usuário como base para a
construção dos Casos de Teste.
A pessoa responsável por garantir que esse processo seja
cumprido corretamente é conhecida como Scrum Master. Ela
é responsável por saber todas as regras e práticas do Scrum e
passar aos demais. Ela também é responsável pela realização e
documentação das reuniões, gerenciamento dos impedimentos
e facilitação do processo de desenvolvimento.
Visão Geral sobre o Projeto Testado
O projeto que serviu de base para este estudo contava com
uma equipe formada por: dois desenvolvedores, um designer,
um testador, um Scrum Master e um Product Owner. Este
projeto tinha como objetivo ser um sistema capaz de fornecer
o resultado sobre Pesquisa de Satisfação do Cliente ao time de
desenvolvimento do projeto relacionado. Com ele era possível
o cadastro de projetos, líderes, clientes e dos times de desenvol-
vimento destes projetos. O sistema se chama On Line Customer
Satisfaction Survey – OCSS.
O OCSS basicamente fornecia informações sobre: a qualidade
dos releases (incremento de software) liberados, comunicação
com o cliente, tempo de entrega dos releases e necessidade do
cliente. O principal objetivo do OCSS em produção era mandar
um relatório de satisfação para o cliente ao final de cada entrega
(release). O cliente então recebia este relatório e o respondia. Ao
Edição 22 - Engenharia de Software Magazine 7
 Figura 2. Caso de Teste

final, o time que fazia parte do projeto recebia um e-mail com
as impressões do cliente sobre o release entregue.
A aplicação desenvolvida possui as seguintes características
técnicas:
• Plataforma Web;
• Linguagem Ruby;
• Rails como framework de desenvolvimento;
• Aptana St udio como IDE (Ambiente Integrado de
Desenvolvimento);
• MySQL como Banco de Dados.
Experiência no Processo de Automação de Teste
Como no Scrum o desenvolvimento e o teste precisam ser
ágeis, a equipe de teste do OCSS decidiu automatizar os casos
de teste sabendo que isso minimizaria custos, aumentaria a
produtividade e garantiria sua qualidade, reduzindo prin-
cipalmente, o tempo de teste. Além disso, a automação iria
ajudar a cobrir as funcionalidades verificadas adequadamente
[Pressman (1995)].
Pelo OCSS se tratar de uma aplicação Web, a ferramenta
escolhida para os testes de Sistema e Aceitação foi o Selenium
– Selenium Core e IDE [Selenium], um software open source
que utiliza a abordagem rec-and-play e oferece suporte a testes
em aplicações Web. O Selenium IDE é um plugin do Mozilla
Firefox. Com ele é possível gravar ações do usuário no browser
e executá-las posteriormente. Esta ferramenta é bastante útil e
ajuda muito na automação de Casos de Teste, trazendo agili-
dade na execução. Os scripts gerados pelo Selenium, a partir
da navegação de um usuário pelo browser, são por padrão em
HTML, porém o Selenium oferece o recurso de ter esse código
gerado em Ruby, Java, Perl, Python, Php, C#.
Porém, esta não foi a única automação feita no OCSS. Houve
também a automação no gerenciamento e elaboração dos tes-
tes, visto que os resultados obtidos precisavam também ser
reportados aos desenvolvedores de maneira rápida e prática.
Para isso foi usada outra ferramenta open source, chamada
TestLink [TestLink]. Com esta ferramenta é possível a escrita
dos Casos de Teste e a geração de relatórios com base nos
resultados obtidos a partir da execução dos testes. A ferra-
menta escolhida para o controle de bugs (bugtracking) foi o
Mantis, que também é open source e oferece bons recursos
para este controle.
Para que métricas de aceitação e qualidade das histórias
fossem geradas e tidas como base para os testes, houve a uti-
lização de uma prática chamada Desenvolvimento Dirigido
por Testes de Histórias (Story-Test Driven Development). Esta
prática diz que antes de começar a desenvolver a história, a
equipe de programadores, analistas, gerentes, testadores e
clientes devem colaborar para definir os critérios de aceitação
da história. Critérios esses que foram utilizados pela equipe
de teste do OCSS, como base para que a qualidade nos testes
e nas funcionalidades testadas fosse alcançada.
O ciclo de teste que era executado a cada Sprint se baseava
em seis práticas comuns:
1) Fazer regressão dos casos de teste relacionados a histórias
desenvolvidas na iteração anterior;
2) Escrever casos de teste (Figura 2) para as histórias (Figura 3)
do Sprint atual, se baseando nos critérios de aceitação (Figura 4)
de cada história;
Figura 3. História que descreve o Caso de Uso
Figura 4. Critério de Aceitação para o fechamento da história

8 Engenharia de Software Magazine - Experiência em Automação de Testes

 Validação, Verificação e Teste
3) Com base neste Caso de Teste, eram criados os scripts de
teste. Para isso o sistema desenvolvido foi executado em um
browser. Neste momento o Selenium IDE trabalhava gravando
toda a ação do browser e transformando-a em scripts HTML.
Estes scripts sofriam modificações para atender a alguma outra
condição que pudesse vir a ocorrer. Os casos mais comuns em
que ocorriam alterações nos scripts gerados eram:
• Acrescentar chamadas da função ‘pause’ do próprio Selenium
entre as linhas de ação geradas automaticamente pela navega-
ção do browser. Como a execução do Selenium é muito rápida,
às vezes casos de teste que estavam certos eram tidos como
errados pelo Selenium pelo fato de algum dado do servidor
ainda não ter chegado, portanto o uso de um delay ajudava
bastante na verificação;
• Modificar chamadas de funções do Selenium quando os
campos relacionados testados eram alimentados por Ajax.
Por padrão o script automático do Selenium faz referência
a função “clickAndWait” do Selenium, esta função só retor-
na o valor atualizado, do servidor, após um refresh na tela
inteira do sistema. Em campos carregados dinamicamente
por Ajax, é necessário que seja feita uma chamada a função
“waitForValue”, esta função carrega o campo assim que ele
recebe um valor novo, sem necessariamente ter que dar
refresh na tela inteira;
4) Após a execução dos scripts, o testador cadastrava os bugs
no Mantis (Figura 5) e os direcionava ao desenvolvedor res-
ponsável pela história testada;
Figura 5. Exemplo de bugs cadastrados no Mantis
5) Em seguida o testador informava o resultado da execução
(Figura 6 e Figura 7) dos scripts no TestLink. Isso era necessário
para a prática seguinte;
6) Gerar relatórios automáticos a partir das execuções infor-
madas. O TestLink oferece diversas opções para analisar os
resultados gerados com base nas execuções de casos de Teste.
Os relatórios do TestLink mais utilizados foram: General Test
Plan Metrics, Failed Test Cases, Charts e Total Bugs For Each Test
Case. Eles podem ser acessados a partir da opção Results do
menu superior do TestLink.
Eram estas as práticas de Teste que ocorriam no Processo de
Qualidade do OCSS na medida em que os Sprints aconteciam.
Nas reuniões de Retropective e Review eram observadas as
funcionalidades desenvolvidas e as métricas de teste geradas
pelos gráficos e relatórios do TestLink.
Figura 6. Exemplo de execução de caso de teste que passou
Figura 7. Exemplo de execução de caso de teste que falhou e gerou um
bug no Mantis
Pontos Positivos
A automação trouxe inúmeros benefícios para a equipe de
teste e para a qualidade do projeto:
Quanto à equipe foi observado que:
• Aumentou a segurança da equipe quanto ao teste, já que
foram feitos testes mais elaborados e complexos utilizando
a opção de exportar para Java os scripts HTML gerados pelo
Selenium;
• Não houve sobrecarga de execução de casos de teste, pois
grande parte estava automatizada;
• Na maioria das vezes, o ciclo de teste era completamente
executado em no máximo dois dias de trabalho, levando em
consideração a execução da etapa dos testes de regressão e dos
testes das novas funcionalidades;
• Os testes de regressão foram responsáveis por identificar a
grande parte dos bugs encontrados no projeto. Estes, na sua
maioria, estavam automatizados;
• Houve uma diminuição considerável com o tempo gasto com
a identificação e correção de erros, já que os bugs de regressão
eram encontrados mais rapidamente;
• Os scripts automáticos foram na sua grande maioria atuali-
zados e modificados poucas vezes;
• Foi possível a montagem de uma Suíte de Testes onde todos
os scripts automáticos eram executados sequencialmente. Isto
economizou muito tempo.
Quanto à qualidade do projeto:
• Testes manuais, que poderiam contribuir para que erros fos-
sem encontrados tardiamente, foram evitados com o processo
de automação. Portanto, os bugs eram encontrados e resolvidos
rapidamente, evitando desperdício de tempo do projeto;
• Por ser uma aplicação WEB, era satisfatório que o Sistema
executasse perfeitamente em pelo menos dois navegadores.
Os mais utilizados pelos clientes eram o Internet Explorer 6 e
o Mozilla Firefox. Testes de regressão encontraram inúmeros
erros de cross-browser. Estes eram identificados rapidamente
Edição 22 - Engenharia de Software Magazine 9
e repassados à equipe de desenvolvimento, contribuindo lar-
gamente para a qualidade do Sistema;
• A automação serviu como base de estudo para os projetos
posteriores. A equipe se focou em conhecer mais sobre auto-
mação, no sentido de práticas, de novas ferramentas e novos
tipos de teste.
Pontos Negativos
Como toda e qualquer prática, a automação de testes através
da abordagem rec-and-play também possui pontos negativos.
Houve vários pontos negativos e desgastes quanto à adoção
desta prática, que foram:
• Como no Scrum parte de funcionalidades são feitas separa-
damente (entre Sprints), alguns scripts tiveram que ser atua-
lizados. Exemplo: pedia-se em um Sprint para desenvolver a
parte de cadastro da tela, e no Sprint seguinte a parte de edição
da mesma tela. Com as funcionalidades entregues aos pedaços,
os scripts deixavam de ser abrangentes;
• O Scrum também possibilita a mudança de requisitos no
meio do processo. Assim, houve scripts automáticos que
foram totalmente perdidos por terem ficado obsoletos após a
mudança de algum requisito;
• Aplicações Web são bastante instáveis, então a cada mudança
das propriedades de algum componente o script que testava
aquilo se tornava inválido, pois na abordagem rec-and-play o
Selenium recupera o nome e propriedades do objeto seleciona-
do para gravar o script. Se o componente mudou, naturalmente
o script automático não serve mais;
Conclusão
A demanda por soluções através de software tem crescido
progressivamente a cada ano, e softwares cada vez mais
complexos são solicitados. Com as metodologias ágeis, o
desenvolvimento destas soluções está cada vez mais rápido,
exigindo dos profissionais um considerável nível técnico além
de comportamentos e características específicos para uma
rápida tomada de decisão e adaptação caso requisitos mudem
no meio do processo.
A exigência por qualidade, em um cenário assim, natural-
mente é maior. Empresas têm investido em Testes de software
com mais frequência. Como apresentado neste artigo, testar
manualmente sistemas complexos que precisam ser desenvol-
vidos rapidamente é inviável. Dessa forma, para maximizar a
qualidade e minimizar o tempo de um ciclo de testes, é preciso
aderir às práticas de automação.
Apesar de algumas desvantagens demonstradas aqui, a
prática de automação é vantajosa em projetos que utilizam
o SCRUM, desde que se tenha um planejamento para isso. A
automação garante bons e abrangentes testes de regressão. Em
10 Engenharia de Software Magazine - Experiência em Automação de Testes
um projeto de software desenvolvido com Scrum, é de grande
importância que se faça este tipo de teste, só assim a qualidade
entre as iterações é garantida.
Links
[Bernardo e Kon (2008)] Bernardo, P. e Kon, F., A Importância dos Testes Automatizados
http://www.ime.usp.br/~kon/papers/EngSoftMagazine-IntroducaoTestes.pdf
[Bissi (2007)] Bissi, W., Scrum – Metodologia de Desenvolvimento Ágil
http://revista.grupointegrado.br/revista/index.php/campodigital/article/view/312/146
[Correia e Silva 2004] Correia, S. e Silva, A., Técnicas para Construção de Testes
Funcionais Automáticos
http://paginas.fe.up.pt/~jpf/teach/TQS0405/sc-Quatic2004.pdf
[Costa 2006] Costa, M., Estratégia de Automação em Testes: requisitos, arquitetura
e acompanhamento de sua implantação
http://libdigi.unicamp.br/document/?down=vtls000389004
[Dasso & Funes (2007)] Dasso, A. and Funes, A.,Verification, Validation and Testing in
Software Engineering. Idea Group, 2007
[Leal (2009)] Leal, I. Requisitos de Metodologias de Teste de Software para Processos Ágeis
http://homepages.dcc.ufmg.br/~rodolfo/dcc823-1-09/Entrega2Pos/igor2.pdf
[Presman (1995)] Presman, R. S. Engenharia de Software. São Paulo: Makron Books
do Brasil, 1995.
[Selenium] Selenium Documentation. Selenium HQ - Web Application Testing System
http://seleniumhq.org
[Schwaber (2004)] Schwaber, K., Agile Project Management with Scrum. Microsoft
Press, 2004
[TestLink] TestLink Documentation. TEAMST - Home of TestLink developers Community
http://www.teamst.org/
[Tuschling (2008)] Tuschling, O., Software Test Automation
http://www.stickyminds.com/getfile.asp?ot=XML&id=14908&fn=XDD14908filelistfilename1
%2Epdf
[Vercauteren (2009)] Vercauteren, T., Agile development and functional testing:
friend or foe?
http://www.stickyminds.com/getfile.asp?ot=XML&id=15206&fn=XDD15206filelistfilename1
%2Epdf
[Wilson (2009)] Wilson, G., The reality of software testing in an Agile Environment
Testing Experience - The Magazine for Professional Testers 03/2009 (pág. 94 a 96)
Feedback
Dê seu feedback sobre esta edição! eu
s
Dê
A Engenharia de Software Magazine tem que ser feita ao seu gosto.
sobre e
Para isso, precisamos saber o que você, leitor, acha da revista!
s
ta
edição
Dê seu voto sobre este artigo, através do link:
www.devmedia.com.br/esmag/feedback
Abordagens Tradicionais de Desenvolvimento
Esta seção traz artigos que apresentam como e quando utilizar as diferentes abordagens
tradicionais de apoio ao desenvolvimento de projetos de software
Guias 2009 do MPS.BR: o que mudou?
Conheça as mudanças na versão 2009 dos guias do modelo MPS
Davi Viana dos Santos
davi.viana@gmail.com
Atua no ramo de implementação de pro-
gramas de melhoria de processo de sof-
tware tendo como base o programa MPS.
BR. É Bacharel em Ciência da Computação
pela Universidade Federal do Amazonas
(UFAM) e Mestrando em Informática pelo
Programa de Pós-Graduação em Informá-
tica (PPGI) da mesma Universidade. Suas
pesquisas são focadas em Engenharia de
Software, principalmente em Qualidade de
Processo de Software.
D
esde 1º de Janeiro de 2010 as
avaliações MPS estão seguindo
somente o modelo de referência
MR-MPS: 2009. Por este motivo, orga-
nizações que estão implementando o
modelo para a futura avaliação ou rea-
valiação devem levar em consideração as
mudanças dos guias da versão 1.2 para a
versão 2009, pois isto pode ser decisivo
para o sucesso de uma avaliação MPS.
Além das avaliações, é importante lem-
brar que os guias descrevem requisitos
e condições para quem quer se tornar
um avaliador adjunto, avaliador líder
ou consultor de Aquisição MPS, tam-
bém apresenta orientações para criação
de novas Instituições Implementadoras
(II) e Instituições Avaliadoras (IA). A
Edição 22 - Engenharia de Software Magazine
De que se trata o artigo?
Neste artigo veremos as principais mudanças
ocorridas nos guias do modelo MPS versão 2009,
além de apresentarmos os novos guias que
descrevem orientações para organizações que
realizam atividades específicas do processo de
software.
Para que serve?
A nova versão dos guias oferece orientações que
passaram a ser utilizadas em avaliações e MPS
desde o dia 1º de Janeiro de 2010. Todas as provas
de habilitação para novos avaliadores também já
utilizam os novos guias.
Em que situação o tema é útil?
Além de ser um modelo atualizado que des-
creve práticas para obter maturidade em pro-
cessos de software, é utilizado quando se faz
necessário uma reavaliação dos processos já
implementados na organização.
seguir serão apresentadas as mudanças
nos guias.
Este artigo tem como base os guias do
modelo MPS versão 2009 e versão 1.2,
que estão disponibilizados no site da
SOFTEX. Inicialmente são explanadas as
11
alterações nos guias de implementação, além da apresentação
dos novos guias. Em seguida, as modificações no guia de ava-
liação são apresentadas. Por fim, são verificadas as mudanças
no guia de aquisição.
Guias de Implementação
Os guias de implementação que apresentam orientações de
como implementar o modelo de referência MR-MPS sofreram
grandes mudanças: processos foram incluídos ou alterados,
alguns resultados esperados dos processos foram modificados
em todos os níveis e aumentou-se o número de resultados de
atributos de processo (RAPs).
As alterações nos processos específicos e nos resultados de
atributos de processo são abordadas por nível de maturidade
que, por sua vez, são descritas nos guias de implementação.
Nível G – Parcialmente Gerenciado
No que diz respeito aos processos deste nível, podemos
destacar uma melhor descrição do resultado esperado para o
processo Gerência de Projetos GPR7. Algumas organizações
não possuem recursos humanos para desempenhar determi-
nadas tarefas do projeto, logo o MPS estabelece a realização de
treinamentos e mentoring para minimizar os riscos em relação
à competência do profissional alocado. Outras modificações
verificadas são referentes ao GPR10 e ao GPR13, que possuíam
outras definições a partir do nível E, agora passaram a ser
válidos para todos os níveis de maturidade.
Os resultados esperados GRE1 e GRE2 do processo Gerência
de Requisitos foram unificados no GRE1. O GRE2 estabelece a
necessidade de um comprometimento da equipe técnica com
os requisitos, ou seja, comprometimento dos colaboradores
que estão envolvidos diretamente com o desenvolvimento do
produto com os requisitos estabelecidos. Este comprometimen-
to deve ser obtido novamente quando houver mudanças nos
requisitos. Por fim, no GRE5 é apresentado que se deve haver
pelo menos um projeto evidenciando mudanças de requisitos,
para que seja avaliada a tratativa aplicada a essas mudanças.
Neste nível, as maiores mudanças ocorreram nos RAPs. Pri-
meiramente temos que o RAP 5, RAP7 e o RAP 9 passaram a
ser válidos somente até o nível F. A partir do nível E, os mesmos
recebem novas definições. Incluiu-se um novo RAP6, que trata
a respeito das responsabilidades e autoridades para executar
o processo e também recebe uma nova definição a partir do
nível E. Por fim, foi incluso um novo RAP10, que descreve
que o projeto é conduzido a partir da execução do seu processo
planejado, e a partir do nível F o mesmo recebe uma nova defi-
nição. Com a inclusão desses dois RAPs, o atributo de processo
AP2.1 passou a ter nove RAPs (RAP2 ao RAP10).
Nível F - Gerenciado
O processo de Gerência de Configuração sofreu alteração
no resultado esperado GCO5, pois além de controlar as mo-
dificações nos itens de configuração, este resultado descreve
que é necessário, também, apresentar essas modificações às
partes interessadas.
12 Engenharia de Software Magazine - Guias 2009 do MPS.BR: o que mudou?
Um novo processo foi incluído neste nível de maturidade:
Gerência de Portfólio de Projetos (GPP), cujo objetivo é ge-
renciar, de forma estratégica, os projetos que são vitais para a
organização. A diferença entre o processo Gerência de Projetos
e Gerência de Portfólio de Projetos é que o primeiro processo
gerência atividades de um projeto e o segundo gerência o
conjunto de projetos que a organização possui. Este processo
é obrigatório, exceto se a atividade da unidade organizacional
a ser avaliada for evolução de produto.
Este processo atua em duas frentes: selecionando os projetos
que devem ser executados e, depois de começar a execução,
verificar se os mesmos continuam viáveis para a organização.
O novo processo possui cinco resultados esperados, que são:
• GPP1 – As oportunidades de negócio, as necessidades e os
investimentos são identificados, qualificados, priorizados e
selecionados. Neste resultado é levado em consideração os
objetivos estratégicos da organização junto com a seleção das
oportunidades;
• GPP2 – Os recursos e orçamentos para cada projeto são
identificados e alocados. Este resultado se difere do GPR7 e
GPR8 pelo fato de haver uma análise dos possíveis conflitos
de recursos entre os projetos;
• GPP3 – A responsabilidade e autoridade pelo gerenciamento
dos projetos são estabelecidas. Neste resultado é importante
definir e comunicar ao responsável sua autoridade pelo ge-
renciamento de cada projeto;
• GPP4 – Os conflitos sobre recursos entre os projetos são
tratados e resolvidos. Esses conflitos devem ser resolvidos
no âmbito organizacional, ou seja, registrar, analisar, tratar e
resolver os conflitos referentes aos recursos utilizados pelos
projetos em execução;
• GPP5 – Projetos que atendem aos acordos e requisitos que
levaram à sua aprovação são mantidos, e os que não atendem
são redirecionados ou cancelados. Essa verificação pode ser
feita juntamente com o monitoramento ou revisão descritas
como resultado esperado do processo de Gerência de Projetos,
ou pode ser criada uma revisão específica para seleção de pro-
jetos. O ponto chave deste resultado é analisar se os projetos
continuam alinhados aos objetivos estratégicos pretendidos,
caso contrário é necessário tomar medidas em relação a sua
continuidade de execução.
No resultado esperado GQA2 do processo Garantia da Qua-
lidade, é retratado que há uma interação entre este resultado
esperado com o RAP 10 (A partir do nível F) e, consequen-
temente a esta interação, é necessário avaliar a aderência a
todos os processos descritos no MR-MPS que a organização
implementa.
O MED1 (primeiro resultado esperado do processo Medição)
deixa claro que os objetivos de medição são estabelecidos e
mantidos a partir dos objetivos de negócio da organização.
O MED4 ainda acrescenta a importância da definição de
metas no auxilio a análise das medidas. Apesar do título do
resultado esperado MED7 ter sido modificado, seu propósito
continua o mesmo.
 PROcesso

O atributo de processo 2.2 acrescenta um novo infraestrutura e do ambiente de trabalho e, por fim, produtos de trabalho
RAP cujo objetivo é garantir que os requisitos dos e lições aprendidas são gerenciados na biblioteca de ativos do processo.
produtos de trabalho tenham sido identificados.
Nível D – Largamente Definido
Nível E – Parcialmente Definido Este nível sofreu poucas modificações, em relação ao processo Projeto
Segundo o resultado esperado para o processo Ge- e Construção do Produto (PCP). Seu primeiro resultado esperado – PCP1
rência de Projetos (Evolução) GPR4, a partir do nível – destaca a importância dos requisitos definidos em relação ao produto e
E, a utilização de um método parametrizado para aos componentes do produto.
dimensionar as tarefas e os produtos de trabalho Verificando o processo Validação (VAL), constatou-se algumas informa-
do projeto é obrigatório. Exemplos de métodos são: ções que foram acrescidas nos resultados esperados deste processo, por
Análise de Pontos por Função e Análise de Pontos exemplo: no resultado esperado VAL5 o guia descreve que não é necessário
por Caso de Uso. Já o GPR18 passa a ser implemen- corrigir todos os problemas encontrados, desde que a organização tenha
tado para todos os níveis a partir do nível E. definido critérios que facilitem essa análise.
O processo Gerência de Recursos Humanos (GRH) Em relação aos atributos de processo, vale lembrar que este nível não
acrescenta mais resultados esperados: o GRH5 des- apresenta novidades em relação aos implementados no nível E. Entretanto,
creve a criação de um plano tático de treinamento é necessário a definição e implementação dos cinco processos específicos
que deve ser definido para suprir as necessidades com a mesma capacidade dos processos já implantados.
estratégicas de treinamento da organização e dos Todas as informações referentes aos resultados esperados de processos
projetos. que podem ser excluídos do escopo da avaliação são mais bem detalhadas
A mudança no resultado esperado para o processo nos novos guias da versão 2009, pois tratam de informações a cerca de
Gerência de Reutilização – GRU3 – refere-se à im- organizações que realizam atividades específicas do desenvolvimento
plementação deste resultado para todos os níveis de software.
a partir de onde é definido pela primeira vez, ou
seja, no nível E. Ainda neste resultado, é feito uma
descrição mais detalhada sobre o mesmo quando a
organização quer atingir o nível C.
Novas definições em relação ao RAP5, RAP6,
RAP7 e RAP9 são apresentadas:
• RAP5 (a partir do nível E): que trata a respeito dos
recursos e informações para executar o processo de-
finido são disponibilizados, alocados e utilizados;
• RAP6 (a partir do nível E): garante a atribuição e
a comunicação dos papéis requeridos, responsabi-
lidades e autoridades às pessoas responsáveis pela
execução do processo definido;
• RAP7 (a partir do nível E): verifica se as pessoas
alocadas para executar o processo definido possuem
o perfil adequado;
• RAP9 (a partir do nível E): estabelece que confor-
me o processo padrão é executado na organização
na forma de processo definido, dados de uso do
processo devem ser coletados para formar uma base
para acumular conhecimento sobre o comportamen-
to do processo padrão.

Ainda foram incluídos dois novos RAPs no atri-

buto de processo 3.1. Ambos tratam de elementos
(“papéis e competências requeridos” e “infraes-
trutura e ambiente de trabalho”) que precisam ser
identificados como parte do processo padrão.
Já no atributo de processo 3.2 foram acrescidos três
novos RAPs: O primeiro descreve que o processo
definido é implementado para o projeto baseado
nas diretrizes para seleção e/ou adaptação do
processo padrão; o segundo trata da gerência da

Edição 22 - Engenharia de Software Magazine 13

Nível C - Definido
Neste nível a evolução do processo Gerência de Reutilização
(GRU) foi retirada. O processo Análise de Decisão e Resolução
(ADR) foi alterado para processo Gerência de Decisões (GDE),
contudo, o propósito, a fundamentação teórica e resultados
esperados deste processo continuam os mesmos. Por fim,
no processo Gerência de Riscos (GRI), o resultado esperado
GRI8 sofreu uma pequena modificação em relação à medição
dos riscos. Assim como no nível D, os RAPs não sofreram
alterações.
Nível B – Gerenciado Quantitativamente
O guia referente ao nível B não sofreu nenhuma altera-
ção a ponto de modificar o propósito do processo Gerência
de Projetos (Evolução), logo os resultados esperados deste
processo continuam iguais. Os RAPs também não sofreram
modificações.
Nível A – Em Otimização
Na versão 2009 dos guias de implementação, este nível não
possui processos específicos. Anteriormente, o mesmo pos-
suía o processo Análise de Causas de Problemas e resolução
(ACP).
Os resultados esperados do processo ACP passaram a in-
corporar os resultados esperados do Atributo de Processo
5.1 e 5.2.
No atributo de processo 5.1 seu propósito foi modificado
a fim de tratar das melhorias e não somente das inovações,
alguns RAPs foram modificados e dois outros foram incluídos
(antigos ACP1 e ACP2).
Os RAPs modificados são:
• RAP36 – que ao invés de somente definir os objetivos de me-
lhoria, é necessário fazer o levantamento de todas as propostas
de melhoria e fazer um estudo em cima dessas propostas;
• RAP42 – este resultado de atributo de processo descreve que,
além de estabelecer uma estratégia de implementação para os
objetivos de melhoria do processo, é necessário que essa estra-
tégia também seja estabelecida para resolver problemas.
Os novos RAPS são:
• RAP37 – Refere-se ao antigo resultado de processo ACP1 que
trata sobre a identificação, classificação e seleção para análise
dos defeitos e outros problemas;
• RAP38 – Refere-se ao antigo resultado de processo ACP2
que descreve sobre a análise de identificação da causa raiz dos
defeitos e outros problemas, e análise sobre soluções aceitáveis
para evitar a ocorrência futura;
No AP 5.2 foram adicionados dois RAPs (antigos ACP4 e
ACP5) que se referem à gerência das ações implementadas,
são eles:
• RAP 45 – Incorporou o antigo RAP36 cujo objetivo é avaliar
a efetividade das mudanças, e também se refere ao antigo re-
sultado do processo ACP4 cujo objetivo é o acompanhamento
das ações implementadas para resolução de problemas para
14 Engenharia de Software Magazine - Guias 2009 do MPS.BR: o que mudou?
verificar se as mudanças no processo corrigiram o problema e
melhoraram seu desempenho. Essa verificação é feita através
de medições;
• RAP46 – Refere-se ao antigo resultado de processo ACP5,
cujo objetivo é armazenar os dados de análise de causas de
problemas e resoluções para eventuais situações similares.
Novos guias de implementação
Na versão 2009 foram criados mais três guias de implemen-
tação que possuem o objetivo de melhor orientar organizações
que possuem atividades específicas do processo de software,
detalhando quais processos, resultados esperados de pro-
cessos e de atributos de processos essas organizações devem
implementar.
Estes novos guias são apresentados visando o propósito
do mesmo, e em seguida descrevendo como os processos do
modelo de referência MR-MPS devem ser implementados ou
não em cada tipo de organização.
Organizações que adquirem software
O primeiro guia é referente às organizações que adquirem
software. Este apresenta orientações de como implementar o
processo Aquisição (AQU), explicitando quando este processo
é obrigatório ou não em uma organização e que medidas tomar
em relação aos demais processos.
Para uma organização que deseja implementar o nível G
do MPS.BR, deve deixar claro os papéis do adquirente e do
fornecedor com o objetivo de: especificar as responsabilidades
de cada um; o que cada parte tem que fazer; como criar seu
cronograma e realizar seu monitoramento; quem é responsável
pelas definições do projeto (recursos humanos, infraestrutura,
recursos financeiros, entre outros); como será realizado o aces-
so aos dados, o fluxo de dados entre todos os envolvidos; como
será realizada as revisões do projeto nas partes envolvidas; e
como será obtido o comprometimento do projeto e dos requi-
sitos com as partes envolvidas. Por fim, é importante lembrar
que nenhum resultado esperado de processo e atributo de
processo pode deixar de ser implementado.
Quando a organização deseja implementar o nível F do
MPS.BR é necessário que, além do processo Aquisição, sejam
implementados: o processo gerência de configuração (onde o
adquirente deve estabelecer e manter seu próprio sistema de
gerência de configuração); o processo Garantia da Qualidade
(onde o adquirente deve avaliar os produtos de trabalho gera-
dos pela atividade que executa, bem como analisar e aprovar
os resultados das avaliações da qualidade do produto gerados
pelo fornecedor); o processo Medição (onde são medidos tanto
os produtos de trabalho gerados pelo adquirente quanto os
gerados pelo fornecedor). Por fim, pode ser excluído do escopo
da avaliação o processo de Gerência de Portfólio de Projetos
quando a única atividade da organização adquirente seja
evolução do produto.
Se a organização quer implementar o nível E do MPS.BR é
necessário implementar: os resultados esperados da evolução
do processo Gerência de Projetos; o processo Avaliação e

Melhoria do Processo Organizacional; Definição do Processo
Organizacional; o processo Gerência de Recursos Humanos
(levando em consideração os recursos humanos da organização
adquirente); o processo Gerência de Reutilização (válidos tanto
para reutilização de ativos da organização adquirente quanto
para os ativos do fornecedor).
Para a implementação do nível D são solicitados: somente
um resultado esperado do processo Desenvolvimento de
Requisitos (DRE), trata-se do DRE1, os demais resultados
esperados podem ser excluídos, isto vai depender do tipo de
aquisição do projeto; no processo Integração do Produto (ITP)
é obrigatório somente a implementação do ITP9, os demais
também dependem do projeto; no processo Validação (VAR)
apenas os resultados esperados VAL1, VAL6 e VAL7 são obri-
gatórios. Por fim, podem ser excluídos de uma avaliação o
processo Projeto e Construção do Produto (PCP) e o processo
Verificação (VER).
A implementação do nível C requer que sejam satisfeitas
as seguintes condições: os resultados esperados do processo
Desenvolvimento para Reutilização variam conforme o tipo
de aquisição que a organização executa; todos os resultados
esperados do processo Gerência de Decisões e do processo
Gerência de Riscos são obrigatórios.
Para a implementação dos níveis B, deve-se atentar para os
resultados esperados da evolução do processo Gerência de
Projetos, cujo objetivo é estabelecer critérios para o fornecedor
visando qualidade do produto e desempenho do processo
com base nos objetivos da organização e do processo. Outro
fator relevante é a definição de um acordo a cerca dos dados
estatísticos dos processos da organização.
Como o nível A não possui processos específicos, não há
processos a serem implementados em uma organização que
adquire software. Contudo, é importante ressaltar que os re-
sultados de atributos de processo devem ser implementados
no contexto dos processos para este tipo de organização, assim
como para qualquer nível que se deseja implementar.
Organizações do tipo Fábrica de Software
O segundo guia descreve a implementação do MR-MPS
em organizações do tipo Fábrica de Software, pois algumas
atividades do processo de software são de responsabilidade
da contratante da fábrica, fazendo com que alguns processos
não se apliquem a este tipo de organização. Os processos e
resultados esperados onde não são permitidas exclusões são:
• Gerência de Projetos e suas evoluções – O gerenciamento
de projetos pode ser feito da mesma forma que nos demais
tipos de organização. A diferença geralmente está no escopo
do trabalho que prioriza a etapa de construção de código;
• Gerência de Requisitos – Envolve gerenciar as modificações
nas especificações provenientes da organização contratante;
• Gerência de Configuração, Gerência de Portfólio de Projetos,
Garantia da qualidade, Medição, Avaliação e Melhoria do Pro-
cesso Organizacional, Definição do Processo Organizacional,
Gerência de Recursos Humanos, Gerência de Reutilização, Ve-
rificação, Gerência de Decisões e Gerência de Riscos – Devem
PROcesso
ser implementados todos os resultados esperados, pois são
processos comuns a todo tipo de organização;
Já os processos que permitem a exclusão de seus resultados
esperados são:
• Aquisição – Este tipo de processo pode não se aplicar às
organizações que possuem como única atividade fabricar
código;
• Desenvolvimento de requisitos – Apenas o resultado
esperado DRE1 é obrigatório, pois auxilia a compreensão e a
aceitação das especificações;
• Integração de Produto – Poderá ser excluído caso a or-
ganização não realize atividades de integração de código
desenvolvido;
• Projeto e Construção do Produto – Somente o PCP6 é obriga-
tório. Caso a Fabrica de Software também faça a documentação,
o PCP7 e PCP8 podem ser necessários;
• Validação – Poderá ser excluído se a organização não realizar
atividades de teste de homologação/aceitação;
• Desenvolvimento para Reutilização – A exclusão dos
resultados esperados deste processo depende das atividades
executadas pela organização do tipo Fábrica de Software.
Organizações do tipo Fábrica de Teste
O último novo guia da versão 2009 apresenta orientações para
a implementação do MR-MPS em organizações do tipo Fábrica
de Teste. As fabricas de teste devem possuir independência
organizacional para testar seus produtos, ou seja, liberdade e
autoridade para realizar os testes e comunicar seus resultados
para os interessados.
Os processos que não podem ter seus resultados esperados
excluídos são:
• Gerência de Projetos e suas evoluções – As organizações
deste tipo devem definir seu projeto de acordo com as ativi-
dades para as quais foi contratada, ou seja, teste do produto
de software;
• Gerência de Requisitos – Neste tipo de organização este
processo é tratado como gerência dos requisitos de teste. A
fábrica de testes é responsável por entender, avaliar e aceitar
os requisitos com a utilização de critérios definidos, incluindo
os requisitos para teste; a rastreabilidade bidirecional é feita
levando em consideração os produtos gerados pela fabrica de
testes; quando há mudanças nos requisitos, a maneira como
os mesmos são gerenciados e/ou repassados para a Fábrica de
Testes é estabelecido e declarado pelo adquirente;
• Gerência de Configuração, Gerência de Portfólio de Projetos,
Garantia da qualidade, Medição, Avaliação e Melhoria do Pro-
cesso Organizacional, Definição do Processo Organizacional,
Gerência de Recursos Humanos, Gerência de Reutilização,
Verificação, Gerência de Decisões e Gerência de Riscos – De-
vem ser implementados todos os resultados esperados, pois
são processos comuns a todo tipo de organização.
Já os processos que permitem exclusão de seus resultados
esperados são:
Edição 22 - Engenharia de Software Magazine 15
• Aquisição – Este tipo de processo pode não se aplicar às
organizações deste tipo, pois as mesmas realizam atividades
de teste;
• Desenvolvimento de requisitos – Apenas o resultado espera-
do DRE1 é obrigatório, pois auxilia a compreensão e a aceitação
dos requisitos que serão utilizados para testes;
• Integração de Produto e Projeto e Construção do Produto
– Poderão ser excluídos totalmente do escopo da avaliação,
pois normalmente fabricas de teste não realizam atividades de
construção (desenvolvimento) e integração de código;
• Validação – Poderá ser excluído se a organização não realizar
atividades de teste de homologação/aceitação;
• Desenvolvimento para Reutilização – A exclusão dos
resultados esperados deste processo depende das atividades
executadas pela organização do tipo Fábrica de Testes.
É muito importante lembrar que a exclusão de qualquer
processo ou determinados resultados esperados deve estar
bem justificado por parte da organização. Em relação à ava-
liação MPS, a aprovação das exclusões é responsabilidade do
avaliador Líder.
Guia de Avaliação
Na versão 2009, o guia de avaliação sofreu algumas modi-
ficações no contexto do processo e regras para a execução da
avaliação. Nesta nova versão ficou estabelecido que uma Ins-
tituição Avaliadora (IA) não poderá ser contratada caso: tenha
dado consultoria na organização a ser avaliada durante os
últimos três anos, mesmo que tenha sido somente um membro
da equipe da IA; algum membro da IA tenha realizado um “gap
analysis” na unidade organizacional a ser avaliada, além das
restrições já contidas na versão anterior do modelo. A principal
diferença é na validade dessas restrições (três anos) que não
estava presente no guia de avaliação da versão anterior.
Foram adicionados passos na condução da avaliação inicial
do subprocesso de preparar a realização da avaliação, como:
apresentar os processos da unidade organizacional e confirmar
a realização da avaliação final.
Em relação à equipe de avaliação, é detalhado o perfil do
representante da organização avaliada, e a estimativa de tempo
para realização da avaliação também foi alterado: níveis A, B,
C e D passaram a ter a duração de três a quatro dias para a
avaliação inicial e de três a cinco dias para a avaliação final;
no nível E, a duração é de dois a quatro dias tanto para a ava-
liação final quanto para a avaliação final; no nível F dura de
dois a três dias para ambos, e no nível G a duração é de um
a dois dias.
Ao se tratar do número mínimo de membros da equipe
de avaliação, o guia descreve que é possível completar
a equipe com membros da organização que atendam às
condições estabelecidas ou aumentar a equipe da IA ou,
ainda, aumentar o número de dias da avaliação. Executar
uma dessas medidas é importante para manter a seriedade
da avaliação no que diz respeito à quantidade mínima de
membros da equipe.
16 Engenharia de Software Magazine - Guias 2009 do MPS.BR: o que mudou?
Quando se trata das entrevistas realizadas na avaliação
final, a nova versão dos guias deixa claro que é necessário
registrar as afirmações coletadas na Planilha de Indicadores
logo após as entrevistas, pois outras atividades da avaliação
podem comprometer o que foi dito pelos entrevistados.
As caracterizações de atributo de processo para satisfazer
os níveis do MR-MPS sofreram pequenas alterações: o AP
1.1 tem que ser, obrigatoriamente, Totalmente implemen-
tado (T) em todos os níveis, o AP 2.1 e AP 2.2 passou a ser
T a partir do nível E, os demais continuam com a mesma
caracterização.
Já para evitar o descredenciamento de uma IA, além das
condições que já existiam, passou a ser obrigatório a pre-
sença do coordenador da IA anualmente ao workshop de
avaliadores (W3-MPS.BR) e na reunião de coordenadores
de IA.
Para se tornar um avaliador líder inicial foi adicionado
mais uma condição que trata a respeito de ser aprovado na
prova para implementadores (P2-MPS.BR) e a condição que
trata a respeito do número de participações em avaliações
como avaliador adjunto foi acrescido para seis. Agora um
avaliador líder intermediário tem que possuir, como experi-
ência profissional comprovada, envolvimento significativo
de processos de software onde a organização obteve o nível
D ou C do MR-MPS ou CMMI nível 3 ou superior, e ter lide-
rado pelo menos seis avaliações de níveis G ou F. Por fim,
para se tornar um avaliador líder experiente, foram alterados
a formação acadêmica no que diz respeito ao conhecimento
do controle estatístico de processos.
Guia de Aquisição
O Guia de aquisição descreve um processo de aquisição de
Software e Serviços Correlatos (S&SC) baseado na Norma
Internacional ISO/IEC 12207:2008, complementado pela
norma IEEE STD 1062:1998. Porém, é importante ressaltar
que o processo Aquisição (AQU) a ser verificado em uma
avaliação MPS é descrito no guia de implementação refe-
rente ao nível F.
Neste guia, as mudanças são apresentadas conforme a se-
quência das atividades previstas para aquisição de S&SC.
Houve algumas mudanças nas tarefas previstas para
aquisição de software, por exemplo, na tarefa prevista
“Desenvolver uma estratégia de aquisição”, o guia apre-
senta opções viáveis para aquisição de software e serviço
correlato (S&SC).
Os relacionamentos das tarefas do processo de Aquisição
com os demais processos do MR-MPS foram retirados da
versão 2009.
Para a execução de algumas tarefas foram incluídos novos
produtos requeridos, como na tarefa prevista de monitorar
a aquisição da atividade de monitoramento do contrato, são
eles: “Resultado da análise do desempenho do fornecedor”
e “Software e Serviço Correlato”.
Como o processo de Aquisição também forma profissionais
(consultores de aquisição MPS), as condições para se tornar

um consultor sofreram alterações. Foi incluída uma condição
que une as condições II, III e IV da versão 1.2 que descreve
a necessidade da elaboração de um Plano de Aquisição de
Software (PAS) de um projeto real ou teórico, com o objetivo
de mostrar sua capacidade. Esse PAS deverá ser apresentado
presencialmente ou via internet para uma banca avaliadora
constituída por membros da SOFTEX, e esta banca indicará
se o candidato foi aprovado.
Conclusão
As modificações, descritas nos guias versão 2009, represen-
tam melhorias do modelo MPS, além de ajustar a conformi-
dade com a norma internacional ISO/IEC 12207:2008 e com
a norma ISO/IEC 15504, que também tiveram atualizações.
Isto mostra a seriedade de manter no mercado um modelo
atualizado, em concordância com a realidade brasileira e,
ao mesmo tempo, compatível com o modelo mais adotado
no mundo, o CMMI.
PROcesso
É muito importante que todos estejam atentos a essas altera-
ções, pois são mudanças relevantes que podem ser fatores de-
cisivos para um bom desempenho do profissional responsável
pela implementação dos processos, um bom desempenho da
organização em uma avaliação e, por fim, pode ser decisivo
para a habilitação de um futuro avaliador do modelo MPS.
Referências/Links
Baseado nos guias, versão 2009.
Disponíveis em: http://www.softex.br/mpsbr/_guias/default.asp
Dê seu feedback sobre esta edição! Feedback
eu
s
Dê
A Engenharia de Software Magazine tem que ser feita ao seu gosto.
sobre e
Para isso, precisamos saber o que você, leitor, acha da revista!
s
ta
edição
Dê seu voto sobre este artigo, através do link:
www.devmedia.com.br/esmag/feedback
Edição 22 - Engenharia de Software Magazine 17
Abordagens Tradicionais de Desenvolvimento
Esta seção traz artigos que apresentam como e quando utilizar as diferentes abordagens
tradicionais de apoio ao desenvolvimento de projetos de software
Fatores críticos de sucesso em programas de
melhoria de processo de forma cooperada
Geovane Nogueira Lima
geovane@next.org.br
Bacharel em Ciência da Computação pela
Universidade Federal de Lavras (UFLA).
Mestre em Engenharia de Software pela
Universidade Federal de Pernambuco
(UFPE) possui pós-graduação em Melhoria
do Processo de Software, e em CMMI pela
UFLA. Profissional certificado pelo ISTQB
(International Software Testing Qualifica-
tions Board) e pelo PROQUALITY (Núcleo
de estudos em Engenharia e Qualidade de
Software). Possui 10 anos de experiência
em TI, tendo atuado em diversos projetos
de desenvolvimento de software e em pro-
jetos de pesquisa e inovação tecnológica
financiados pelo CNPQ. Há 5 anos, atua
como consultor e instrutor em Melhoria
de Processo de Software, realizando ativi-
dades de consultoria e implantação de Me-
lhoria do Processo de Desenvolvimento de
Software, com base em diversos modelos:
CMMI, ITIL, ISO/IEC 15504, ISO/IEC 12207,
MPS.BR, BPM, PMBOK, SCRUM dentre
outros. Entre suas principais atuações
como consultor em projetos de melhoria,
destacam-se empresas como ATAN/ Ac-
centure, TOTVS, FlagIntelliwan, Procenge
e MV Sistemas.
18 Engenharia de Software Magazine - Fatores críticos de sucesso em programas de melhoria de processo de forma cooperada
Marcos André Gomes
marcos@recife.softex.br
Bacharel em Administração de Empresas pela
Universidade Federal de Pernambuco. Pós-
graduado em Gestão da Tecnologia da Infor-
mação pela UPE (Universidade de Pernambu-
co). Atua a mais de 25 anos, em empresas de
grande porte no setor do comercio, indústria
e serviços na área de TI, 15 dos quais como
gerente de TI. Implantou processos e meto-
dologias de desenvolvimento de software
e gestão de equipes, em diversas empresas.
Implementou certificação ISO 9001-2000
em empresas de desenvolvimento de sof-
tware. Atualmente exerce o cargo de Diretor
de Tecnologia do SOFTEX RECIFE, onde dirige
projetos, junto a empresas e organismos
governamentais (BNDES, FINEP, MCT, SEBRAE
e outros). Gestor do projeto de melhoria da
qualidade de software em Pernambuco, atra-
vés de convênio para implementação do MPS.
BR (Melhoria do Processo de Software) junto
com a Sociedade SOFTEX,O MCT(Ministério da
Ciência e Tecnologia) e o BID(Banco Interame-
ricano de Desenvolvimento). Gestor do NEXT
(Núcleo de Excelência em Teste de Sistemas),
o laboratório de teste de software do SOFTEX
RECIFE. Diretor regional da ALATS (Associação
Latino Americana de Teste de Software).
De que se trata o artigo?
Este artigo descreve as experiências vivenciadas pelo
SOFTEXRECIFE na organização de programas de me-
lhoria de forma cooperada com base no modelo MPS.
BR. O principal objetivo do trabalho é compartilhar os
aprendizados, analisando os principais pontos que fo-
ram determinantes para o sucesso obtido.
Para que serve?
Para todos os interessados em implementar melhoria
de processo de forma colaborativa, o artigo indica os
primeiros passos e desta os principais pontos impac-
tantes no sucesso da implementação.
Em que situação o tema é útil?
Este tema é de grande utilidade para a melhoria
da qualidade e produtividade do software nacio-
nal, abordar forma de se implementar modelos
de qualidade em grupos de empresa, o que reduz
expressivamente os custos de implementação.
E
ste artigo tem por objetivo com-
partilhar a experiência bem suce-
dida vivida pelo SOFTEXRECIFE
na organização de cooperativas para
implantação do programa de melho-
ria com base no modelo MPS.BR. De
forma sucinta, esperamos repassar os

aprendizados adquiridos, apresentar e discutir os principais
pontos determinantes do sucesso da cooperativa, na ótica da
IOGE (Instituição Organizadora de Grupo de Empresas).
O SOFTEXRECIFE em parceria com a SWQuality organi-
zou em 2006 o primeiro grupo de empresas em Recife para a
implantação do programa de melhoria, com base no Modelo
de Referência do MPS.BR [MR-MPS.BR] e em 2007 o segundo
grupo de empresas, motivado pelo comunicado da Sociedade
SOFTEX Nacional para a formação de grupos de empresas
para a implantação do MR-MPS.BR no modelo cooperado. Esta
primeira cooperativa de empresas teve por objetivo apoiar a
implementação do nível G do modelo em 5 empresas de de-
senvolvimento de software da região Nordeste, e a avaliação
seguindo o Método de Avaliação do MPS.BR [MA-MPS.BR].
A primeira cooperativa MPS.BR nível G desenvolveu suas
atividades no período de abril de 2006 a junho de 2007, quando
as últimas empresas do grupo foram avaliadas obtendo o nível
G. Das 5 empresas que iniciaram o grupo, 4 empresas foram
avaliadas e todas foram bem sucedidas com as avaliações
realizadas conforme previsto no projeto. Com isto obtive-
mos uma taxa de sucesso de 80%, maior do que a prevista
inicialmente.
Em 2007 foi organizada a segunda cooperativa com 9 empre-
sas organizadas em dois grupos, um grupo com 5 empresas
objetivando o nível G e o outro com 4 empresas objetivando
o nível F. Estes grupos foram finalizados no início de 2009,
com a avaliação oficial de 3 empresas no nível F e 4 no nível
G. Com estes resultados, obtivemos um índice de 78% das
empresas que iniciaram o grupo avaliadas oficialmente, e
com 100% de aproveitamento nas avaliações, ou seja todas as
empresas que se submeteram à avaliação oficial obtiveram o
nível pretendido.
A IOGE
O SOFTEXRECIFE, criado em 1994, é o Centro de Tecnologia
de Software para Exportação do Recife. Sua missão é articular,
fomentar e apoiar ações direcionadas à excelência do setor de
software em Pernambuco.
No momento, o SOFTEXRECIFE conta com mais de 70 em-
presas a ele associadas, o que significa uma parcela importante
das empresas que formam o setor de Tecnologia da Informação
e Comunicação em Pernambuco.
A principal missão do SOFTEXRECIFE é aumentar a com-
petividade das empresas de Tecnologia da Informação e
Comunicação, buscando instrumentos para fomentar o desen-
volvimento do setor de software no Estado de Pernambuco. O
SOFTEXRECIFE tem como visão tornar-se dentro de 2 anos, um
centro difusor da cultura da qualidade e referência em teste de
software e, com isso, contribuir para a consolidação do Recife
como um pólo de excelência na produção de TI.
O SOFTEXRECIFE é na verdade uma comunidade viva de
empresas da área de Tecnologia da Informação que dispõe
de um espaço institucional para se aperfeiçoar e promover
o seu crescimento e inserção no mercado local, nacional e
internacional. Em face desse papel, o SOFTEXRECIFE é, junto
Processo
com outras instituições, elemento chave de uma estratégia,
em curso, para consolidar a cidade do Recife como um pólo
reconhecido e respeitado de geração, produção e difusão de
Tecnologia da Informação.
O SOFTEXRECIFE atuou no papel de IOGE (Instituição
Organizadora de Grupo de Empresas) na primeira e segunda
cooperativa MPS.BR Recife.
Podemos observar que a organização das cooperativas está
totalmente alinhada aos objetivos do SOFTEXRECIFE, e neste
ponto todos os esforços foram realizados para ajudar as em-
presas, na sua busca por competividade.
As cooperativas
A primeira cooperativa foi formada em abril de 2006, com o
objetivo de implantação de um programa de melhoria baseado
no nível G do MR-MPS.BR, além da avaliação oficial neste nível
do modelo de 5 empresas organizadas em grupo.
A cooperativa foi organizada em parceria com a SWQuality
Consultoria e Sistemas, a qual atuou como II (Instituição
Implementadora), ficando responsável pelas atividades de
consultoria, treinamento e comunicação do grupo.
As empresas selecionadas para compor esta primeira coope-
rativa foram: CAPITAL LOGIN, PROCENGE, PROVIDER, MV
SISTEMAS e NEUS. Todas as empresas são classificadas como
empresas de médio ou pequeno porte, e estão todas situadas
na região Nordeste do país.
A cooperativa, conforme definido no seu próprio Plano de
Projeto, teve como principais objetivos:
• Avaliar e aprovar 5 empresas de desenvolvimento no nível
G do MPS.BR;
• Promover a cultura da qualidade em desenvolvimento de
software no ecossistema de Pernambuco;
• Difundir o MPS.BR.
Sendo a principal prioridade a avaliação oficial das empresas
no nível G do MPS.BR, num prazo de doze meses.
Os resultados alcançados foram bastante expressivos, atin-
gindo todos os objetivos planejados e superando inclusive
algumas das expectativas iniciais. Das 5 empresas participan-
tes, 4 foram avaliadas e todas obtiveram resultado positivo
na avaliação, obtendo assim o nível G do modelo. A única
empresa não avaliada deveu-se à mudança no seu foco de atu-
ação, extinguindo sua área de desenvolvimento de software.
Assim, obtivemos um indicador de desempenho, com 100%
de sucesso.
Temos plena convicção que todo este sucesso se deve ao
esforço conjunto de todos os atores envolvidos na cooperati-
va: IOGE, II e empresas; e principalmente a harmonia entre
estes atores. Os fatores de sucesso da cooperativa dependem
da união, esforço e comprometimento de todos. Por parte da
IOGE, entendemos que o principal fator de sucesso foi assumir
uma postura pró-ativa, e, sobretudo, valorizar a comunicação
entre os envolvidos.
O principal desafio enfrentado logo no início dos trabalhos
foi conseguir despertar o interesse das empresas e selecionar
Edição 22 - Engenharia de Software Magazine 19
algumas delas para a formação do grupo. A princípio, pou-
cas empresas se interessaram pelo programa de melhoria de
processo com base no MR-MPS.BR, que, de certa forma, já era
de se esperar, pois o modelo MPS.BR ainda estava se desenvol-
vendo e em processo de aceitação pelo mercado. Para superar
esta dificuldade o SOFTEXRECIFE atuou fortemente junto à
gestão das empresas filiadas e várias rodadas de apresentações
sobre melhoria de processo e do modelo MPS.BR foram pro-
movidas, a fim de que os executivos das empresas tomassem
conhecimento do modelo. Esta medida surtiu o efeito desejado
e conseguimos formar o primeiro grupo de empresas.
A segunda cooperativa foi formada em agosto de 2007 e se
mostrou mais complexa do que a primeira, visto que o número
de empresas é significativamente maior, e também por ser
composta de 2 grupos, a saber: um grupo com 5 empresas
trabalhando para obter o nível G, e outro grupo de 4 empresas
trabalhando para obter o nível F. Estes fatores foram ampla-
mente compensados pela experiência adquirida com a primeira
cooperativa. De forma geral todas as ações estruturantes da
cooperativa anterior foram mantidas, sendo realizados apenas
alguns pequenos ajustes no modelo de gestão.
Algumas ações foram reforçadas por terem apresentado
resultados positivos na cooperativa anterior. Dentre elas, po-
demos destacar: o incentivo a colaboração e, o reconhecimento
das particularidades de cada empresa. Enquanto a primeira
ação aumenta o comprometimento da empresa; a segunda
diminui a resistência a mudanças, o que é muito comum em
projetos desta natureza.
Os resultados alcançados, com a aprovação de 7 empresas
(4 no nível G e 3 no nível F) vem confirmar a efetividade do
modelo implementado pelo SOFTEXRECIFE, que tem como
principio básico a integração entre os atores do projeto (IOGE,
II e empresas).
O Aprendizado
Analisamos o desempenho obtido nas cooperativas, bus-
cando identificar algumas das práticas adotadas que tenham
contribuído para o sucesso do projeto. Pudemos observar que
algumas destas práticas não têm nada de inovador, são apenas
boas práticas da Gerência de Projetos, contudo, trouxeram uma
ótima contribuição para os resultados obtidos.
Desde o início da formação da cooperativa as atividades
foram tratadas como um Projeto. Observamos que algumas
práticas são próprias do contexto da organização de trabalhos
de forma cooperada. A seguir apresentaremos e comentaremos
estas práticas.
Critério para formação do Grupo: ao selecionar os partici-
pantes que irão compor o grupo, é importante buscar empresas
que tenham uma boa afinidade entre si e que não tenha con-
flitos de interesse. Deve-se tomar o cuidado de não colocar no
mesmo grupo empresas que sejam concorrentes diretas, ou que
não tenham um bom relacionamento. Na medida do possível
é interessante selecionar empresas no mesmo nível de matu-
ridade. Para que se possa fazer uma seleção e agrupamento
adequado das empresas é fundamental conhecê-las. Para tal,
20 Engenharia de Software Magazine - Fatores críticos de sucesso em programas de melhoria de processo de forma cooperada
foram elaborados e aplicados alguns questionários às empre-
sas. O processo de seleção ocorreu junto com a participação
da II (Instituição Implementadora).
Subsídio vinculado ao cumprimento das metas: embora
as condições estabelecidas pela Sociedade SOFTEX Nacional
permitam que as empresas recebam a primeira parcela na
assinatura do convênio, o SOFTEXRECIFE achou por bem
adotar outra postura. Foi então definido que, para se obter os
subsídios, as empresas teriam que atingir primeiro as metas es-
tabelecidas (50%, 100% e a avaliação). Embora esta abordagem
possa dificultar a participação das empresas, ela serve como
incentivo e aumenta significativamente o compromisso com
o sucesso do projeto. Pudemos perceber que além do aumento
do compromisso, as empresas ficaram motivadas a atingir as
metas no menor espaço de tempo possível.
Termo de cooperação técnica: os acordos para a formação
da cooperativa foram tratados como “Termo de Cooperação
Técnica Financeira” e não simplesmente como um Contrato Co-
mercial entre as partes. Tal abordagem explicita que o sucesso
do projeto é de responsabilidade de todos, e que depende do
desempenho do grupo como um todo. Em outras palavras, o
sucesso de uma das partes está estritamente ligado ao sucesso
das outras partes, sendo o contrário também verdadeiro.
Regras claramente definidas: é de extrema importância estar
com todas as regras muito bem definidas e compreendidas por
todos, antes do início dos trabalhos. E tão importante quanto a
sua definição, é sua implementação. Para atender este item, re-
alizamos reuniões onde as regras administrativas, financeiras
e técnicas foram apresentadas aos participantes do grupo. Isto
foi feito antes mesmo da formação oficial do grupo.
Relacionamento estreito com a II: um relacionamento
estreito entre a II e a IOGE, desde o início dos trabalhos, foi
sem dúvida, um ponto fundamental para o sucesso obtido.
A relação entre IOGE e II deve ser vista como uma parceria,
e não uma simples contratação de prestação de serviço. O
alinhamento entre estratégia/metodologia de implantação e a
gestão da cooperativa é primordial para um bom andamento
dos trabalhos. Como a II está mais próxima das empresas,
participando do seu dia a dia e consegue identificar as dificul-
dades tão logo estas surjam, este relacionamento permite que
a IOGE tome medidas antecipadas e até mesmo preventivas
de solução de problemas.
Metodologia de trabalho bem definida: ter uma metodolo-
gia de trabalho clara e bem definida é importante e passa con-
fiabilidade do processo para as empresas. É recomendável que
as etapas/fases da metodologia estejam claramente divididas.
Uma divisão bem estruturada permite um acompanhamento
da evolução do projeto de forma mais precisa e menos árdua.
A SWQuality apresentou uma metodologia de trabalho divi-
dida em 8 fases bem nítidas, e com os resultados esperados
para cada uma delas claramente definidos, o que contribuiu
para o acompanhamento do projeto. Outro ponto observado,
é que a utilização de uma metodologia facilita o nivelamento
das expectativas entre as partes envolvidas, e serve como base
para o planejamento das atividades da cooperativa.

Figura 1. Organograma do projeto
Canal de comunicação: logo no início dos trabalhos foi criada
uma intranet para que todos os participantes da cooperativa
pudessem trocar informação livremente, gerando assim um
canal de comunicação. Pela intranet podemos trocar experi-
ências, divulgar notícias, compartilhar material e enviar os
comunicados das atividades do grupo. Foi de suma impor-
tância incentivar a comunicação entre as empresas sem que
a mesma dependesse do intermédio da IOGE, especialmente
para troca de experiências.
Incentivo à colaboração: observamos que no início do projeto
as empresas ficam relativamente tímidas e resistentes em com-
partilhar suas experiências, mas é função da IOGE tentar reverter
esta situação. É importante que a IOGE atue incentivando a todo o
momento a constante troca de experiência. No início as empresas
foram obrigadas a apresentar o andamento dos trabalhos para todo
o grupo periodicamente. Ocorreram reuniões técnicas para troca
de experiências, aprendizado e debate das dificuldades. Com a
evolução do projeto a colaboração tornou-se bastante natural, não
sendo mais necessária uma forte intervenção da IOGE. Esta postura
da IOGE foi bastante elogiada pelas próprias empresas.
Reconhecer a particularidade de cada empresa: embora as
atividades ocorram de forma cooperada, as particularidades
de cada empresa foram a todo o momento respeitadas. Obser-
vamos que as empresas evoluem em ritmos diferentes, seja em
função de suas características ou de uma situação específica. É
de extrema importância respeitar o ritmo de evolução individual
de cada empresa. Para tanto, cada empresa elabora seu próprio
cronograma considerando suas particularidades, mas manten-
do os pré-requisitos dos marcos definidos pelo cronograma da
cooperativa. Esta abordagem permitiu, por exemplo, que uma
das empresas evoluísse mais rápido e obtivesse o nível G em
menos de 8 meses, enquanto o planejado pela cooperativa era de
aproximadamente 12 meses.
Definição clara dos papéis e responsabilidades: um projeto
de cooperativa envolve vários atores, e cada um com interesses
particulares. Por isso a definição clara dos papéis e responsabi-
lidades, faz-se extremamente necessário. A definição dos papéis
e responsabilidades ocorreu logo no início do projeto e foi di-
vulgado e aprovado por todos os envolvidos. A Figura 1 ilustra
o organograma do projeto.
Processo
Na Tabela 1 é apresentado os papéis no projeto, e descrito quais
são as responsabilidades de cada uma das partes. Observe que
por parte da empresa foram definidos três papéis, cada um com
suas responsabilidades bem delineadas.
Grupo Executivo: foi definido um modelo de gestão da coo-
perativa que estabelece a criação do Grupo Executivo, o qual é
constituído por representantes de todas as partes envolvidas:
IOGE, II, e um representante de cada empresa. Como podemos
observar no Organograma (Figura 1), este é o topo da hierarquia,
garantindo assim um processo democrático à cooperativa. O
Grupo Executivo é responsável por aprovar requisições de mu-
danças que afetam custo, prazo e/ou escopo, bem como tratar os
problemas escalados, e principalmente acompanhar a evolução do
projeto. Esta prática foi de fundamental importância para manter
o comprometimento do grupo, a clareza dos trabalhos e garantir
certa flexibilidade ao grupo.
Reunião de acompanhamento: as reuniões de acompanha-
mento foram realizadas ao longo de todo o projeto, sendo mais
frequente nas fases iniciais. Nestas reuniões cada empresa ela-
borava e apresentava um relatório de andamento do projeto e a II
apresentava um acompanhamento de cada empresa em relação
aos marcos da cooperativa. Em todas as reuniões os principais
pontos do projeto eram monitorados, como por exemplo: crono-
grama, consumo dos recursos (horas de consultoria) e questões
financeiras. Com isto podemos observar a importância destas
reuniões na redução de conflitos, comunicação e reforço no
comprometimento do grupo.
Conclusões
A experiência da primeira cooperativa MPS.BR organizada
pelo SOFTEXRECIFE em parceria com a SWQuality foi um
projeto que conseguiu alcançar todos os seus objetivos tanto
na avaliação das empresas, quanto na divulgação do Modelo
MPS.BR. O sucesso desta iniciativa pôde ser confirmado com
a formação da segunda cooperativa. Atendendo à demanda, o
SOFTEXRECIFE em parceria com a SWQuality, formaram dois
novos grupos de empresa. Um grupo com 5 novas empresas
para a implantação do nível G, e um outro grupo, formado por
4 empresas que participaram da primeira cooperativa, agora
com o objetivo de implementar o nível F do modelo MPS.BR.
Edição 22 - Engenharia de Software Magazine 21
 Definição de Papeis e Responsabilidades
Papel Responsabilidades
Grupo Executivo • Aprovar requisições de mudanças que afetem custo, prazo ou escopo;
• Resolver conflitos e problemas escalados;
• Acompanhar situação do projeto.
Gerente do Projeto • Acompanhar atividades;
Softex • Resolver conflitos e problemas;
• Gerenciar os riscos do projeto;
• Promover reunião de acompanhamento;
• Revisar relatórios de homologação;
• Gerenciar recursos oriundos do Softex Nacional;
• Aprovar requisições de mudanças que não afetem custo, prazo ou escopo;
• Gerenciar ações corretivas e/ou preventivas;
• Gerenciar a comunicação do projeto;
• Disponibilizar recursos.
Coordenador Técnico • Apoiar Gerente do Projeto Softex nas questões técnicas do projeto
Softex • Realizar homologação de produtos técnicos da SWQuality
Coordenador Técnico • Preparar relatórios de acompanhamento;
SWQuality • Participar de reuniões de progresso;
• Reportar conflitos e riscos a qualquer momento ao Gerente do • Projeto Softex;
• Gerenciar ações corretivas e preventivas designadas a ele;
• Manter site técnico do projeto atualizado.
Equipe Consultores • Executar treinamentos e consultorias;
• Elaborar documentos técnicos;
• Reportar status ao coordenador técnico SWQuality.
Patrocinador No âmbito do projeto dentro da empresa:
• Acompanhar progresso do projeto;
• Resolver conflitos e problemas;
• Disponibilizar recursos.
Gerente do Projeto No âmbito do projeto dentro da empresa:
Melhoria • Acompanhar progresso do projeto;
• Reportar status do projeto ao Patrocinador;
• Gerenciar os riscos do projeto;
• Gerenciar ações corretivas e/ou preventivas;
• Homologar serviços e produtos prestados pelo projeto;
• Participar das reuniões de progresso agendadas pelo Softex.
Equipe Técnica No âmbito do projeto dentro da empresa:
• Participar das reuniões de consultoria e treinamentos do projeto;
• Reportar status do projeto;
• Apoiar na identificação de riscos técnicos do projeto.
Tabela 1. Definição de Papéis e Responsabilidades

Os dois novos grupos de empresas, nível G e nível F, adotaram Referências

a mesma abordagem da primeira cooperativa e os primeiros [MA-MPS] Associação para Promoção da Excelência do Software Brasileiro – SOFTEX. MPS.BR
resultados foram bastante positivos, com a aprovação de 7 das Guia de Avaliação, v 1.0 2006. Disponível em www.softex.br.
9 empresas envolvidas no modelo MR-MPS.
[MR-MPS] Associação para Promoção da Excelência do Software Brasileiro –
A experiência vivida na primeira e segunda cooperativa nos
mostra que o início das atividades é o momento crucial para SOFTEX. MPS.BR - Guia Geral, v 1.1 2006. Disponível em www.softex.br.
sucesso ou fracasso do projeto. É importante que todas as partes
Dê seu feedback sobre esta edição! Feedback
tenham conhecimento dos objetivos do trabalho, o esforço espe- eu
s
Dê

rado, e que as expectativas estejam bem alinhadas e que tenham A Engenharia de Software Magazine tem que ser feita ao seu gosto.
sobre e

conhecimento da metodologia de gestão e de execução das consul- Para isso, precisamos saber o que você, leitor, acha da revista!
s

ta
torias. Em outras palavras, é fundamental um bom planejamento, Dê seu voto sobre este artigo, através do link:
edição

e um forte comprometimento de todos os envolvidos. www.devmedia.com.br/esmag/feedback

22 Engenharia de Software Magazine - Fatores críticos de sucesso em programas de melhoria de processo de forma cooperada
Abordagens Tradicionais de Desenvolvimento
Esta seção traz artigos que apresentam como e quando utilizar as diferentes abordagens
tradicionais de apoio ao desenvolvimento de projetos de software
ITIL: Por onde começar?
Como dar os primeiros passos na implementação desse framework
Samuel Diniz Casimiro
samuel.casimiro@gmail.com
É servidor público e trabalha como analista
de sistemas em um grande órgão do gover-
no; trabalhou cerca de 10 anos na área de
desenvolvimento de sistemas de um grande
banco brasileiro; é certificado SCJP, SCWCD
e ITILF; especialista em soluções J2EE para
intranets; consultor de TI para pequenas
e médias empresas; e crítico ferrenho dos
modelos de desenvolvimento adotados
atualmente nas grandes empresas.
N
os últimos três anos, o ITIL
virou uma febre nas áreas de
TI. Em uma pesquisa realizada
em 2007 pelo ITSMF Internacional, em
parceria com o capítulo Brasil, revelou
que, no universo das empresas que in-
vestem em gerenciamento de serviços de
TI, cerca de 23% disponibiliza recursos
para ITIL – Cobit é o framework que
vem em segundo lugar, com 16%. Nesse
período, a demanda por treinamento
aumentou vertiginosamente. Os servi-
ços de consultoria para implementação
Edição 22 - Engenharia de Software Magazine
De que se trata o artigo?
Veremos como se pode dar os primeiros passos
para implementar os processos ITIL com o objetivo
de adotar o gerenciamento de serviços de TI pro-
posto por esse framework, que é um dos pilares da
Governança de TI.
Para que serve?
O propósito do ITIL é implementar o gerenciamento
de serviços de TI com o objetivo de garantir a manu-
tenção dos processos de negócio e o alinhamento en-
tre a área de TI e as demais áreas fins da empresa ou
cliente externo. Sem o ITIL fica difícil visualizar os ser-
viços providos pela área de TI e garantir o atendimen-
to dos níveis de serviço demandados pelo cliente.
Em que situação o tema é útil?
Empresas que vêm enfrentando dificuldades em
garantir a disponibilidade de seus serviços e pro-
blemas para alinhar seus esforços com as áreas
negociais devem considerar a implementação
parcial ou total desse framework.
desse framework (veja o quadro “O que é
um framework?”) também estão em alta.
Executivos, gerentes e técnicos criam
enormes expectativas após um primeiro
contato com o assunto. Áreas inteiras de
23
TI são treinadas, profissionais são certificados e todos correm
para a implementação. Projetos são iniciados, diversas reuni-
ões são realizadas, consultores preenchem relatórios e muito
dinheiro é gasto na compra de ferramentas, assessoramento e
treinamento. O tempo vai passando e os projetos de implemen-
tação, já atrasados, vão sendo prorrogados. Expectativas são
frustradas ou, na melhor das hipóteses, adiadas. Contratos de
consultoria são revistos, gerentes de projetos são substituídos
e novas reuniões são marcadas. Quando parecia que quase
tudo estava pronto, as pessoas começam a perceber que quase
nada foi feito.
Essa é a situação de várias empresas brasileiras que ten-
taram, ou ainda estão tentando, implementar os processos
ITIL nos últimos anos. Não é preciso fazer uma pesquisa
científica para perceber isso. Basta aproveitar os eventos de
TI e treinamentos para se relacionar com outros profissio-
nais e chegar a essa conclusão. Fóruns de discussão, sites
de comunidades e até o Twitter estão lotados de desabafos
e frustrações relacionadas com a implementação desse fra-
mework. Também não faltam artigos sobre isso.
Diante desses problemas, surgem algumas perguntas. Por-
que as áreas de TI estão se esforçando para implementar o
ITIL? Porque existe tanta expectativa em torno disso? Porque
muitas empresas não estão conseguindo implementar esse
framework? Quais são os principais problemas? E como
podem ser solucionados?
Este artigo vai tentar analisar essas e outras questões
com o objetivo de oferecer ao leitor um caminho prático
para começar a implementação do ITIL. A meta é ser bem
sucedido com o menor custo possível. Afinal, em tempos de
crise financeira, as empresas não podem se arriscar a gastar
milhões tentando melhorar seus processos quando não se
sabe exatamente qual o benefício financeiro que terão em
retorno. Na dúvida, portanto, ou as empresas deverão tentar
implementar os processos ITIL com o menor esforço possível
ou é melhor elas tentarem uma outra abordagem.
Antes de começar
Existe muita confusão em torno do ITIL. Já presenciei
verdadeiras discussões sobre qual framework uma empresa
deveria adotar. Alguns defendem o ITIL, outros preferem o
CMMI, Cobit, ISO, Six Sigma, etc. Esse tipo de discussão só
deixa claro que muitos ainda não sabem do quê realmente
se trata cada um desses frameworks. Por isso, a primeira
coisa a ser feita antes de se pensar em implementar o ITIL
é entender claramente o que é e o que não é.
Entenda o que é o ITIL
O ITIL é mais antigo do que muitos pensam. Surgiu na
década de 80. Diz a literatura oficial que ele foi encomen-
dado pelo governo britânico para regular os contratos de
terceirização de TI que existiam na época. Naquela época, já
existia uma forte dependência de serviços de TI e o governo
britânico estava insatisfeito com o custo e com a qualidade
desses serviços.
24 Engenharia de Software Magazine - ITIL: Por onde começar?
O que é um framework?
Essa palavra é muito comum na área de informática. Mas muita
gente a usa sem nem saber o que realmente significa. A tradução
literal de framework é armação ou estrutura. Alguns dicionários
traduzem também como esqueleto ou arcabouço. O dicionário
Cambridge traduz como “estrutura de sustentação arredor da
qual algo pode ser construído”. No caso do ITIL, é justamente isso!
O ITIL é um esqueleto, resultado da união de diversos “ossos” que
são as boas práticas. Entretanto, como é um esqueleto, se trata de
algo incompleto. Os livros dão apenas linhas gerais dos processos.
Políticas, fluxos e procedimentos devem ser construídos. Imagine
o ITIL como um grande prédio onde existe apenas a estrutura de
sustentação. É uma estrutura robusta, não se pode ter dúvida. Mas
levantar as paredes e terminar a construção fica por conta de cada
empresa que vai implementar esse framework.
Contudo, a literatura não oficial sugere que o ITIL surgiu
em decorrência da Guerra das Malvinas, quando o governo
britânico, apesar de vencedor, levou uma surra dos argen-
tinos. Como quase toda guerra, a TI foi determinante para
a vitória britânica, mais a rainha não ficou nem um pouco
satisfeita com as constantes falhas e indisponibilidades dos
diversos serviços de TI envolvidos no conflito. Foi aí que
surgiu o ITIL.
O ITIL não é uma metodologia, tão pouco uma certificação,
apesar de profissionais poderem ter o seu conhecimento
certificado naquele framework. O ITIL é um conjunto de
melhores práticas para gerenciar serviços de TI, assim como
o PMBOK é um conjunto de melhores práticas para gerenciar
projetos – mas uma coisa não tem nada a ver com a outra. O
foco é, portanto, gerenciamento de serviços de TI.
E o que é um serviço de TI? É tudo aquilo que as áreas de
TI oferecem para suportar os objetivos de negócio do cliente,
seja ele interno ou externo. Essa abordagem precisa ficar
clara. A área de TI é que provê os serviços de TI e o cliente
é quem utiliza esses serviços. Assim, note que os serviços
de TI devem estar alinhados com o negócio. O serviço é
algo que o cliente percebe como sendo importante para a
operacionalização do negócio. Isso deixa claro que o geren-
ciamento de serviços não é um objetivo por si só e sim um
meio de se atingir os objetivos de negócio do cliente. Como
essa visão de serviços de TI facilita o alinhamento da TI com
os objetivos estratégicos da empresa, o ITIL é tido como um
dos pilares da Governança de TI.
As melhores práticas estão contidas em sete livros. Basica-
mente, cada livro descreve alguns processos que podem ser
implementados para viabilizar um gerenciamento de servi-
ços de TI bastante robusto. Cada processo é descrito como
uma série de ações ou atividades executadas por papéis
específicos para obter um ou mais resultados importantes
no gerenciamento de serviços de TI. Apesar de serem sete
livros, o foco do ITIL está contido em apenas dois livros,
um que trata do Suporte aos Serviços e outro que trata da

Entrega dos Serviços. O conteúdo desses livros será tratado
em futuros artigos.
Não é gerenciamento de projetos
Como já foi dito, o ITIL é um conjunto de boas práticas
para gerenciar serviços de TI assim como o PMBOK o é
para gerenciar projetos. Mas entenda que uma coisa não
tem nada a ver com a outra. De um lado estamos falando de
serviços de TI, geralmente prestados de forma continuada,
em que os objetivos estão relacionados com a manutenção
de um ou mais processos de negócio. De outro lado esta-
mos falando de projetos, que têm início e fim determina-
dos, em que os objetivos são produzir algo de novo. Para
exemplificar isso, imaginemos um banco. Para suportar o
processo de abertura de conta-corrente, a área de TI desse
banco poderá prover um serviço de TI, composto de um ou
mais sistemas, para informatizar os trabalhos. Mas perceba
que um serviço pode muito bem nascer de um projeto.
Quando esse banco trabalha para criar um novo tipo de
conta-corrente e os serviços de TI relacionados, estamos
falando de projeto. Após a conclusão do projeto, quando
a área de TI começar a prover os serviços, os processos
ITIL entram em ação. Dessa forma, perceba que esses
frameworks, apesar de serem completamente distintos e
utilizados em situações e momentos diferentes do negócio,
eles são, ao mesmo tempo, complementares.
Mesmo assim, muito provavelmente sua empresa iniciará
um projeto para implementar o ITIL. Nesse contexto, os
processos e técnicas propostos pelo PMBOK serão úteis
para auxiliar a gestão do projeto de implementação do
ITIL. Fora isso, esses livros, apesar de falarem de gestão
de forma geral, tratam de temas bem distintos.
Não é MPS.BR
Qual é o melhor framework a se implementar, o ITIL
ou o MPS.BR? Resposta: os dois. Apesar de terem alguns
processos em comum, esses frameworks são complemen-
tares. No ITIL, o foco é gerenciar serviços de TI que este-
jam alinhados ao negócio. No MPS.BR, que é baseado no
CMMI, o foco é produzir um software de qualidade que
suportará, depois de pronto, um ou mais serviços de TI.
No primeiro, o objetivo é suportar os processos de negócio
e garantir que o cliente esteja satisfeito com o serviço. No
segundo, o objetivo é melhorar o processo de desenvolvi-
mento de software para que se possa produzir de forma
mais eficiente e eficaz.
Algumas empresas preferem começar pela implantação
do MPS.BR, alegando que precisam primeiro por ordem
na casa para depois poderem se preocupar com os serviços
de TI que são oferecidos aos seus clientes. Mas muito vai
depender do nível de maturidade que o seu processo de
desenvolvimento de software já apresenta. Na dúvida, tal-
vez seja interessante intercalar a implementação de alguns
processos do MPS.BR com alguns processos de ITIL. Por
exemplo, Gerência de Projeto e Garantia da Qualidade, do
Processo
MPS.BR, têm tudo a ver com Gerenciamento de Mudanças
e Gerenciamento de Liberações, do ITIL.
Não é uma ferramenta
Já vi empresas comprando uma ferramenta e dizendo
que estão adotando o ITIL na empresa. Mesmo aquelas
empresas que entendem que a implementação do ITIL
vai muito além da utilização de uma ferramenta acabam
focando demais nela. Precisamos entender uma coisa de
uma vez por todas: Ferramenta é a última coisa com a qual
você vai ter que se preocupar. ITIL é sobre implementar
processos e, antes de mais nada, isso envolve definição
de atividades e papéis, pessoas, normas e treinamento.
A ferramenta só deve ser escolhida quando tudo o mais
estiver pronto, ou seja, quando os fluxos dos processos
estiverem bem definidos e os papéis bem acordados.
Além do mais, existem diversas ferramentas disponíveis
no mercado. E se a sua estratégia de implementação for de
implementar um processo de cada vez, talvez seja interes-
sante adquirir apenas os módulos da ferramenta referentes
aos processos que estão sendo implementados naquele
momento. Assim, você dilui o custo de implementação e
obtém retorno financeiro mais cedo. Se a sua empresa já
possui um ambiente de desenvolvimento e uma intranet,
considere desenvolver a sua própria ferramenta. Utilizar
uma ferramenta que tenha a cara da empresa ajudará a
reduzir a resistência das pessoas bem como a diminuir os
custos de integração de uma ferramenta de mercado ao
legado que porventura já exista.
Não é uma abordagem tudo ou nada
Como já foi dito, o ITIL é um conjunto de boas práticas.
Infelizmente, assim como ocorre com o PMBOK, alguns
pensam que precisam implementar tudo. E isso não verdade
por vários motivos! Primeiro, mesmo que você implemente
tudo, entidade alguma vai certificar que a sua empresa é
100% ITIL. Isso porque não existe certificação de empresas,
tal como ocorre com o MPS.BR ou ISO, apenas certificação
de profissionais como já foi dito. Em segundo lugar, não
existe nenhuma garantia que, caso você implemente todos
os processos e funções do ITIL, todos os resultados espera-
dos serão obtidos. Em terceiro lugar, o ITIL é um conjunto
de boas práticas coletadas em diversos setores da indústria
de serviços de TI. Então nem tudo se aplicará a sua empresa
ou, mesmo que se aplique, os custos dos controles podem
superar os benefícios.
Portanto, tenha muita cautela ao escolher os processos que
serão implementados na sua empresa. Vá devagar e, após
cada passo, reavalie os resultados obtidos. Talvez com alguns
poucos processos você consiga resolver os problemas que
motivaram a implementação desse framework.
Levante os problemas a resolver
Como foi dito no último parágrafo, é importante monitorar
se a implementação do ITIL está resolvendo os problemas
Edição 22 - Engenharia de Software Magazine 25
da empresa e melhorando o provimento dos serviços de TI.
O problema é que muitas empresas nem sequer sabem quais
problemas se espera resolver com a implementação desse fra-
mework. Sem conhecer esses problemas fica difícil avaliar a
implementação e saber exatamente qual foi o retorno obtido.
Para evitar isso, é importante levantar todos os problemas que
se espera serem sanados com a implementação do ITIL. Reúna
todas as áreas interessadas, faça uma lista de problemas, des-
creva em detalhe cada um deles, suas causas e consequências e
verifique quais deles podem ser resolvidos e quais os processos
envolvidos em cada um deles. Essa análise servirá, inclusive,
para que se possa decidir sobre quais processos serão imple-
mentados primeiro, pois em geral são priorizados aqueles que
resolverão o maior número de problemas.
Suas políticas estão definidas?
Certos frameworks, como a ISO, deixam bem claro que me-
lhorar a qualidade de produtos ou serviços envolve considerar
melhorias em três camadas ou podemos dizer dimensões:
Políticas, processos e procedimentos. Isso é algo básico em
qualquer framework de melhoria de processos. O MPS.BR, por
exemplo, força a definição das políticas por meio do primeiro
resultado esperado para cada processo. No ITIL, a necessidade
de definir políticas nem sempre é muito clara. A descrição de
alguns processos nem sequer menciona uma política.
Apesar disso, a definição das políticas deve anteceder a
implementação de cada processo. Mesmo sendo o ITIL um
framework focado no nível operacional da empresa, ficará
muito difícil para o grupo responsável pela implementação
tomar decisões sem uma política clara do que a administra-
ção da empresa deseja. A não ser que os executivos estejam
diretamente envolvidos no projeto, participando de todas as
reuniões, o que raramente ocorre. Começar com a definição das
políticas permitirá também que as ideias sejam amadurecidas
com antecedência. Isso evitará muita discussão desnecessária,
retrabalho, reduzirá os custos de implementação – especial-
mente se uma consultoria for contratada – e contribuirá para
uma visão do ITIL mais alinhada com os objetivos estratégicos
da administração. Na prática, a definição das políticas vai
representar a materialização do compromisso da administra-
ção com a implementação do framework – algo vital para o
sucesso do projeto.
Vale ressaltar que o ITIL, apesar de muito popular, não tem
muito conteúdo. Os livros contêm apenas linhas gerais para
guiar a implementação dos processos. Como não se trata de
uma metodologia, faltam alguns detalhes de implementa-
ção. Além das políticas, os procedimentos de cada processo
precisarão ser construídos inteiramente pela empresa. Outra
coisa que falta no ITIL é um ordem lógica para implementar
os processos, coisa que o MPS.BR oferece por meio dos níveis
de maturidade.
Começando
Considerando o conteúdo apresentado acima, vamos supor
que a empresa obteve o entendimento correto do ITIL, levantou
26 Engenharia de Software Magazine - ITIL: Por onde começar?
os problemas a serem resolvidos, escolheu os processos que
serão adotados e definiu políticas para cada um deles. Não
foi dito, mas vale a pena ressaltar, que todos os envolvidos
nesse trabalho que antecede o início do projeto precisaram
ser treinados no ITIL, de outra forma não teriam o correto
entendimento do assunto e não saberiam decidir sobre quais
processos seriam adotados. É interessante que alguns, em
especial os gerentes que vão assumir a responsabilidade pelos
processos, recebam um treinamento mais avançado tal como
o fornecido para obter a certificação de Practioner. Parece
pouco, mas esse início talvez leve um ou dois anos. O marco
dessa fase inicial é a conclusão das políticas e o compromisso
formal dos patrocinadores. O projeto de implementação já
pode ser iniciado.
Iniciando um projeto
Dependendo da estratégia que será adotada, pode-se tratar
a implementação de todos os processos que foram escolhidos
em um único projeto ou dividir esses processos em vários
projetos debaixo de um mesmo programa. Alguns preferem
criar um projeto por processo ou reunir um grupo de proces-
sos afins em um mesmo projeto. Dividir o trabalho em vários
projetos ajuda a diminuir a complexidade, a obter resultados
mais cedo e contribui para evitar a recorrência de problemas
na implementação dos processos seguintes graças às lições
aprendidas ao final de cada projeto ou processo.
Nesse momento os gerentes de projeto são designados e
as equipes que trabalharão nos primeiros projetos são alo-
cadas. Mais uma vez, vale ressaltar que, apesar de ser bom
ter uma equipe multidisciplinar, é importante que todos que
trabalharão diretamente no projeto recebam um treinamento
mais profundo sobre os conceitos e práticas ITIL. Se a equipe
do projeto envolver representantes de várias áreas, o que é
ótimo, sugere-se que eles estejam dedicados integralmente
ao projeto. Sugere-se também que se envolva a auditoria de
TI, caso exista uma.
Defina uma estrutura
Se o ITIL for o primeiro framework que a empresa estiver
implementando, é bem provável que ainda não exista uma
estrutura no organograma da área de TI que seja responsável
pela gestão de processos e qualidade da TI como um todo.
Empresas que já implementaram o MPS.BR, por exemplo,
geralmente já terão um departamento responsável pela gestão
dos processos, qualidade e melhoria contínua. Caso já exista
uma área assim, ela é uma ótima candidata a assumir a gestão
de alguns dos processos do ITIL que serão implementados.
Diz-se de alguns, e não de todos, porque alguns processos
são tipicamente geridos por áreas específicas. O processo de
incidentes é um deles, sendo tipicamente gerido e executado
pela central de serviços.
De qualquer forma, para garantir que a implementação de um
processo não se deteriore com o tempo, é importante que exista
uma área responsável pelo monitoramento e qualidade dos
processos ITIL. Quando uma área assim não existe, é comum

os membros da equipe do projeto assumirem essas funções
após a conclusão da implementação. Como essa é uma área
tipicamente de controle, é interessante que ela esteja ligada
diretamente à alta administração ou tenha pelo menos um
executivo responsável por ela.
Deixar de criar uma estrutura organizacional para cuidar dos
processos e da qualidade é um erro comum nas empresas que
implementam ITIL. Nesses casos, os gerentes dos processos
implementados acabam sendo funcionários de outras áreas
que precisarão dividir o tempo deles entre as atividades que já
vinham desempenhando e a gestão dos processos envolvendo
o gerenciamento de serviços de TI. O problema é que esses
funcionários acabam por priorizar suas atividades corriqueiras
em detrimento dos processos e muito do que foi implementado
acaba ficando apenas no papel.
Portanto, a criação de uma estrutura responsável pela gestão
dos processos é vital para garantir a institucionalização deles
e promover a melhoria contínua. A definição de indicadores, o
monitoramento e controle já é muito trabalho para ser dividido
com outras funções.
Traga as pessoas para o seu lado
Preste atenção na Figura 1. A engrenagem “people”, pessoas,
não é a maior por mero acaso. As pessoas são a parte mais
importante em qualquer framework de melhoria de processos.
Não adianta desenhar processos perfeitos se as pessoas não
souberem ou não estiverem a fim de executá-los.
Já falamos aqui sobre treinamento de executivos, gerentes
e da equipe do projeto de implementação. Mas serão outras
pessoas que vão executar as atividades de cada processo, que
vão exercer papéis nesses processos. Por isso, é importante con-
vencer também esses de que o ITIL vai trazer melhorias e não
simplesmente ordenar-lhes que executem os procedimentos. E,
para isso, nada melhor do que uma boa dose de catequização
Figura 1. Aspectos vitais do ITIL
Processo
ITIL. Os treinamentos para a certificação ITIL Foundation são
ótimos para esse fim, pois são curtos e relativamente baratos.
Se não for possível promover esse curso para todos, tente rea-
lizar palestras e workshops sobre o assunto. Promova debates
sobre o tema. Crie fóruns de discussão. Incentive a colaboração
por meio de artigos para resolver determinados problemas le-
vantados pelas equipes dos projetos durante a implementação
e premie as melhores contribuições. Isso vai criar um clima de
compromisso e expectativa vitais para o sucesso.
Defina a estratégia
Com base nas políticas que foram definidas e nos proble-
mas que foram levantados, pode-se agora definir qual será a
estratégia de implementação. Já se falou sobre a possibilida-
de de criar projetos para cada processo ou um projeto para
todos. Mais ainda restam duas perguntas: Quais processos
implementar? E em qual ordem os processos devem ser
implementados?
Vamos tentar responder à primeira pergunta. Como já foi
mencionado, o ITIL não utiliza uma abordagem tudo ou
nada. Trata-se de um repositório de boas práticas, de onde
se pode selecionar aquelas que melhor se adéquam à reali-
dade da empresa. Um bom ponto de partida é a análise dos
problemas que foram levantados antes do projeto. Quais
os principais problemas que a área de TI vem enfrentan-
do? Como a abordagem de gestão de serviços de TI pode
contribuir para resolver esses problemas? Quais processos
sugeridos pelo ITIL estão diretamente relacionados com
esses problemas? As respostas dessas perguntas devem
indicar os processos mais importantes. Contudo, aqui vai
uma palavra de cautela. Apesar de não ser obrigatória a
adoção de todos os processos, é importante verificar que
existe uma certa dependência entre alguns deles. Talvez a
sua análise de problemas aponte apenas alguns processos.
Mas às vezes não se pode obter todos os resultados espera-
dos implementando apenas um processo isoladamente. É
claro que os processos definidos como prioritários podem
e devem ser focados. Os processos dependentes podem
ficar para depois. Como já foi considerado, processos afins
podem ser agrupados em um mesmo projeto.
Sabendo quais os processos que serão implementados,
agora é o momento de decidir a ordem de implementação
deles. Em geral, não é viável implementar todos de uma
vez só, mesmo que sejam apenas aqueles priorizados pela
análise acima. Implementar muitos processos de uma
vez só requer muitas pessoas e é pouco provável que elas
possam interromper suas atividades corriqueiras para se
dedicarem ao projeto. Tenha em mente que implementar o
ITIL geralmente leva de um a dois anos. Portanto, não crie
falsas expectativas. Dê um passo de cada vez, ou seja, cada
processo a seu tempo.
Independentemente da sua análise, é bem provável que
sua empresa implementará os processos de gerenciamento
de incidentes e o de mudanças. Esses são processos chaves
que não podem ser desconsiderados por nenhuma empresa.
Edição 22 - Engenharia de Software Magazine 27
As características desses dois processos e os ótimos resul-
tados que podem ser obtidos com a implementação deles os
tornam bons candidatos para começar a implementação. É
o que será analisado no tópico a seguir.
Incidentes x mudanças
Historicamente, a grande maioria das áreas de TI tem co-
meçado a implementação pelo gerenciamento de incidentes.
Parece uma boa opção, mas em geral ela é tomada com base
em palpites. O gerenciamento de incidentes permite que os
serviços de TI de uma empresa sejam rapidamente restabele-
cidos em caso de indisponibilidades. Assim, por meio desses
processos, é possível garantir a satisfação dos clientes com os
serviços prestados. Esse é um dos principais motivos pelo qual
empresas no mundo inteiro começam com o gerenciamento
de incidentes.
Entretanto, recentemente algumas empresas têm deixado
essa abordagem de lado e passaram a iniciar suas imple-
mentações pelo gerenciamento de mudanças. Isso tem
ocorrido porque boa parte dos problemas que afetam a
disponibilidade dos serviços de TI tem sua origem em um
gerenciamento de mudanças mal feito e precário. De fato,
com um gerenciamento de mudanças ruim, a área de TI
vai ficar constantemente apagando incêndios, ou seja, re-
solvendo indisponibilidades. E isso acaba sobrecarregando
pessoas que, de outra forma, poderiam estar produzindo
novas soluções e viabilizando mais serviços de TI. Por
essas e outras, o gerenciamento de mudanças parece ser a
escolha mais natural para começar, pois dele dependem o
gerenciamento de incidentes, de problemas e de liberação,
só para citar alguns.
CMDB
Mas daí alguns talvez possam dizer: Ah, mas o gerencia-
mento de mudanças depende do gerenciamento de configu-
ração, então é melhor começar por ele. Resposta: sim e não.
Sim, considerando que o gerenciamento de mudanças só
alcançará sua plenitude se trabalhar em cima de uma base de
dados de configuração (CMDB) 100% confiável. E não porque
não precisamos ter o gerenciamento de configuração para
ter uma CMDB. Agora, uma coisa é certa, nenhum processo
funcionará sem uma CMDB. É essa base que apontará os
ativos de TI do qual dependem cada serviço de TI e isso é
o que viabilizará vários outros processos como o gerencia-
mento de mudanças, de liberação, de disponibilidade, etc.
Portanto, se a empresa ainda não tiver uma CMDB, fazer
o inventário dos ativos de TI e mapear os relacionamentos
entre eles é um ótimo ponto de partida, algo a se fazer antes
de implementar qualquer processo.
Catálogo de serviços
Do catálogo de serviços também dependem todos os de-
mais processos do ITIL, afinal estamos falando em gerencia-
mento de serviços. Contudo, tal como ocorre com o CMDB,
não é necessário implementar o gerenciamento de nível de
28 Engenharia de Software Magazine - ITIL: Por onde começar?
serviço para poder ter um catálogo de serviços. A definição
do catálogo de serviços é, portanto, prioridade também.
Providenciar uma ferramenta
A pergunta que precisa ser respondida é: De que ferramen-
tas precisamos para começar a implementação do ITIL?
Já foi mencionado que a construção de uma CMDB é pré-
requisito para vários processos ITIL. Assim, a primeira
ferramenta de que precisamos é uma solução para criar e
manter uma base de todos os ativos de TI de uma organiza-
ção e os relacionamentos entre eles. É uma base de metada-
dos e não dos ativos propriamente ditos. Essa base precisa
basicamente guardar quatro tipos de informação: descrição
do ativo, área técnica responsável, relacionamentos com
outros ativos e relacionamentos com os serviços. Estruturar
uma base assim é bem simples. O difícil é alimentar os da-
dos. Existem algumas ferramentas disponíveis no mercado,
comerciais ou open-source, que varrem a estrutura de TI via
rede e catalogam automaticamente os ativos encontrados.
Outra opção é catalogar os ativos de TI à medida que inci-
dentes são encontrados ou mudanças são solicitadas.
Dado esse primeiro passo, o próximo vai depender da estra-
tégia de implementação. Se uma empresa resolveu começar
pelo gerenciamento de incidentes e central de serviços, ela vai
precisar basicamente de uma ferramenta típica de help-desk
com funções de workflow para repassar as solicitações. Por
outro lado, se a estratégia adotada foi começar pelo geren-
ciamento de mudanças, é de uma ferramenta de controle de
mudanças que a empresa vai precisar. E é importantíssimo
que essa ferramenta esteja integrada à CMDB.
A escolha de uma ferramenta vai depender muito do ta-
manho da área de TI. Ao passo que microempresas podem
implementar diversos controles em uma simples planilha,
empresas maiores acharão por bem adquirir ferramentas
comerciais mais robustas. Nesse sentido, os fornecedores
mais comuns são a BMC, com a sua suíte Remedy, a CA, com
o Unicenter, a HP, com o Openview, e finalmente a IBM, com
o Tivoli. Mas vale ressaltar a que implementação do ITIL
pode envolver diversas outras ferramentas, dependendo dos
fluxos que foram definidos para cada processo.
Passo-a-passo resumido
Considerando o que foi apresentado acima, chegamos ao
seguinte passo-a-passo resumido para começar a imple-
mentação dos processos ITIL:
• Obter a correta compreensão do framework, treinando
executivos e gerentes;
• Levantar os problemas da área de TI que poderiam ser
resolvidos com a implementação;
• Escolher os processos que serão implementados;
• Definir políticas para cada processo;
• Escolher a estratégia de gerenciamento de projetos que
será utilizada na implementação;
• Definir a equipe do projeto de implementação e fornecer
treinamento avançado;

• Trazer as demais pessoas para o seu lado por meio de
treinamento, oficinas e promoções;
• Escolher a ordem de implementação dos processos;
• Montar o CMDB;
• Publicar o catálogo de serviços;
• Implementar os processos na ordem definida;
• Rever lições aprendidas ao final de cada projeto ou marco;
• Providenciar uma ferramenta.
Conclusão
Este artigo mostrou a importância de se obter um correto
entendimento do ITIL antes de iniciar a implementação desse
framework. Para reduzir o tempo e o custo de implementação,
as empresas fazem bem em levantar seus problemas e definir
suas políticas antes mesmo de contratar uma consultoria e/ou
iniciar um projeto para a implementação de processos ITIL.
Outra coisa que vale a pena ser destacada é a necessidade de
deixar a ferramenta por último, de forma que seja possível
obter uma que se adéque a tudo o mais que tenha sido defini-
do. Por fim, mostrou-se que praticamente todos os processos
ITIL dependem do CMDB e do catálogo de serviços. Por isso, é
vital que estes sejam providenciados antes da implementação
de qualquer processo.
AMIGO
Processo
Links
10 things you should know about ITIL
http://articles.techrepublic.com.com/5100-10878_11-6134345.html
Change management: A better starting point for ITIL
http://searchcio.techtarget.com/news/column/0,294698,sid182_gci1242026,00.html
ITIL and Configuration Management: Where to begin
http://articles.techrepublic.com.com/5100-22_11-6177192.html
ITIL® Implementation: Where to Start and Pitfalls to Avoid!
http://www.kpeak.com/ITIL%20Implementation%20-%20Sept%20%2706%20SIG.pdf
ITIL process success: Get people on your side
http://searchcio.techtarget.com/news/column/0,294698,sid182_gci1249840,00.html
ITIL: Top five tips to kick-start your strategy
h t t p : / / s e a rc h c i o. t e c h t a rg e t . c o m / t i p / 0 , 2 8 9 4 8 3 , s i d 1 8 2 _ g c i 1 3 1 5 2 9 8 , 0 0 .
html?mboxConv=searchSecurity_RegActivate_Submit&
Where to begin implementing service management
http://articles.techrepublic.com.com/5100-10878_11-1058518.html
Dê seu feedback sobre esta edição! Feedback
eu
s
Dê
A Engenharia de Software Magazine tem que ser feita ao seu gosto.
sobre e
Para isso, precisamos saber o que você, leitor, acha da revista!
s
ta
edição
Dê seu voto sobre este artigo, através do link:
www.devmedia.com.br/esmag/feedback
Existem coisas
que não conseguimos
ficar sem!
...só pra lembrar,
sua assinatura pode Renove Já!
estar acabando!
www.devmedia.com.br/renovacao
Para mais informações:
www.devmedia.com.br/central
Edição 22 - Engenharia de Software Magazine 29
Abordagens Tradicionais de Desenvolvimento
Esta seção traz artigos que apresentam como e quando utilizar as diferentes abordagens
tradicionais de apoio ao desenvolvimento de projetos de software
Arquitetura Orientada a Serviços
Sobre o que você precisa refletir para adotá-la em um contexto empresarial
Jorge Dias Jr.
josejorgejr@gmail.com
www.jorgediasjr.com
Doutorando em Ciência da Computação
(UFPE). Mestre em Ciência da Computação
(UFPE). Graduado em Ciência da Computa-
ção (UFPB). Desenvolve pesquisas na área
de SOA desde 2005. Possui vários artigos
publicados em conferências nacionais e
internacionais. Tem experiência como ana-
lista de TI na indústria, onde desenvolveu
sistemas no âmbito do governo federal,
além de ter atuado em vários projetos da
iniciativa privada. Atualmente, é professor
e pesquisador no Departamento de Ciên-
cias Exatas da UFPB, Campus IV.
30 Engenharia de Software Magazine - Arquitetura Orientada a Serviços
E
m seu livro, Josuttis faz a seguin-
te afirmação sobre Arquitetura
Orientada a Serviço (SOA): “O
problema é que você não pode simplesmente
comprar SOA, você tem que entendê-la e
vivê-la. SOA é um paradigma. SOA é uma
maneira de pensar. SOA é um sistema de va-
lores para a arquitetura e design” [Josuttis,
2007]. Isso quer dizer que, assim como
o paradigma de Orientação a Objetos, o
paradigma Orientado a Serviços requer
aspectos tecnológicos e não tecnológicos
para ser bem sucedido. Ou seja, além do
amparo ferramental, é necessário um
conjunto de métodos, técnicas, processos
e boas práticas para adotar uma SOA
com sucesso. fícios em mente, é importante considerar os aspectos
Este artigo não tem o objetivo de
apresentar um passo a passo de como
adotar uma SOA em uma empresa, mas
de mostrar alguns dos desafios e ingre-
dientes que devemos ter em mente e que
precisamos definir para implantarmos
uma SOA, minimizando os riscos e as
chances de fracasso.
De que se trata o artigo?
SOA traz diversos benefícios em um contexto empre-
sarial. Porém não podemos simplesmente comprar
uma SOA em uma prateleira. Neste intuito, este arti-
go discute alguns desafios e ingredientes que devem
ser considerados e pensados na adoção de uma SOA.
Para que serve?
Mostrar alguns dos desafios e ingredientes que deve-
mos ter em mente e que precisamos definir para im-
plantarmos uma SOA em um contexto empresarial,
minimizando os riscos e as chances de fracasso.
Em que situação o tema é útil?
Em um contexto empresarial, SOA permite que or-
ganizações com infra-estrutura de aplicações frag-
mentadas, sob a administração de diferentes áreas
de negócio, possam integrar estas aplicações no
nível de serviço. Além disso, SOA permite um maior
alinhamento da TI com o negócio. Tendo estes bene-
tecnológicos e não tecnológicos que podem influen-
ciar o sucesso de sua adoção.
Conceitos iniciais
Existem diversas definições sobre SOA
e serviço, porém nenhuma delas é tida
como a oficial. Muitas destas definições

vêm de fornecedores que as definem de acordo com as soluções
que eles fornecem. Alguns exemplos de grandes fornecedores
são a IBM, Microsoft e Oracle.
Iremos definir SOA de uma maneira bem simples: SOA é uma
forma de se projetar uma arquitetura baseada na composição
de serviços interoperáveis e reutilizáveis. A Figura 1 mostra os
principais elementos de uma SOA: o fornecedor do serviço é
aquele que implementa e tem domínio sobre um serviço; o re-
gistro de serviço é um repositório onde fornecedores de serviço
podem registrar seus serviços para que eles sejam localizados
pelos consumidores; e o consumidor do serviço é aquele que
localiza um serviço e o executa. O contrato é a especificação
do serviço que possui as informações necessárias para que o
consumidor possa localizá-lo e invocá-lo.
Figura 1. Principais elementos de uma SOA
Esta é a idéia simplista que temos sobre SOA. A seguir vamos
analisar SOA em um contexto empresarial e quais os benefícios
que este tipo de arquitetura traz para as organizações.
SOA em um contexto empresarial
Atualmente, muitas organizações possuem um conjunto de
diferentes sistemas, aplicações e arquiteturas com diferentes
idades, tecnologias e plataformas. Além disso, os processos de
negócio destas organizações estão sujeitos a mudanças, ou devido
a alguma reestruturação de negócio, ou talvez devido à abertura
para novos parceiros de negócio. Neste contexto, como os sistemas
da organização conseguirão acompanhar estas mudanças? Este é
um cenário ideal para se pensar em adotar uma SOA.
Neste contexto empresarial, SOA permite que organizações
com infra-estrutura de aplicações fragmentadas, sob a admi-
nistração de diferentes áreas de negócio ou departamentos,
possam integrar estas aplicações no nível de serviço. Portanto,
as aplicações destes departamentos se tornam fornecedores e
consumidores de serviços de outros departamentos.
Além disso, serviços representam bem funções de negócio e,
portanto, são considerados uma boa maneira para desenvolver
aplicações que suportam processos de negócio, permitindo
assim, alinhar TI às necessidades organizacionais. Cada
serviço representa uma determinada funcionalidade que é
mapeada para um passo, ou vários passos, em um processo
de negócio.
PROJETO
A Figura 2 ilustra esta idéia. Perceba que os diferentes de-
partamentos de uma empresa possuem diferentes sistemas
de software que podem ser um CRM, um ERP, ou qualquer
outro sistema que automatize processos de negócio do seu
departamento. A idéia é disponibilizar a lógica desses sistemas
em forma de serviços interoperáveis e reutilizáveis. Acima
desses serviços, existe uma camada onde estão os processos de
negócio que são executados através da invocação dos serviços,
ou seja, os serviços são chamados em uma seqüência lógica de
acordo com os processos organizacionais. Neste cenário, novas
aplicações clientes, com pouca ou nenhuma lógica de negócio,
podem ser desenvolvidas em cima destes processos de negócio.
Neste caso, estas aplicações clientes funcionam simplesmente
como entrada e apresentação dos dados.
Figura 2. SOA em um contexto empresarial
O cenário ideal é que analistas de negócio da organização
possam fazer alterações nos processos e que isso seja refletido
automaticamente no sistema empresarial como um todo, sem
precisar alterar nenhuma linha de código. Esta é a idéia “Run
what I just drew”, ou seja, “execute o que eu acabei de dese-
nhar”. Este é um dos focos da área de BPM (Business Process
Management). Atualmente, os conceitos de SOA e BPM estão
bem relacionados e, por este motivo, as pessoas os confundem,
achando que estas idéias de gerenciamento de processos per-
tencem a SOA. SOA dá o suporte tecnológico e metodológico
para expor serviços de negócio. Já BPM tem como objetivo
capturar, projetar, executar, gerenciar e monitorar processos,
geralmente através de ferramentas visuais. Como estes temas
estão bem interligados, ao longo deste artigo, iremos nos referir
apenas ao termo SOA, sabendo que as idéias de BPM estão
incorporadas a ela.
É importante dizer que este é o cenário que SOA, juntamente
com BPM, pode alcançar. Porém, SOA também pode ser utili-
zado em outros cenários mais simples que não envolva BPM.
Benefícios na adoção de SOA
A adoção de SOA traz alguns benefícios devido às suas
características. Esta lista de benefícios não está completa, e
Edição 22 - Engenharia de Software Magazine 31
é apenas uma indicação do potencial que essa plataforma
arquitetural pode oferecer.
Flexibilidade
Como foi dito, todo sistema empresarial está sujeito a mu-
danças. Ele precisa continuamente ser adaptado para suportar
novos requisitos devido às necessidades que envolvem o mer-
cado, mudanças na lei, ou mesmo reorganizações de negócio.
Portanto, a arquitetura empresarial deve ser configurada de
maneira flexível. As características de SOA possibilitam o
desenvolvimento de novos serviços de negócio e permitem
que uma organização reuse estes serviços a fim de responder
a estas mudanças.
Manutenabilidade
A comunicação entre o consumidor e o fornecedor é baseada
em interfaces bem definidas e padronizadas. Esta caracte-
rística aumenta o poder de manutenabilidade dos sistemas
empresariais porque os detalhes de implementação ficam
escondidos.
Reusabilidade
Reusabilidade tem sido um dos maiores objetivos da enge-
nharia de software nos últimos anos, com diferentes graus
de sucesso. Na SOA, a habilidade de compor novos serviços a
partir de serviços existentes fornece uma maior possibilidade
para o reuso e uma vantagem distinta para uma organização
que tem que ser ágil para responder às necessidades de negócio.
Desta maneira, o desenvolvimento das aplicações através do
reuso de serviços torna mais rápido, aumenta a qualidade e
diminui os custos de desenvolvimento e tempo de entrega.
Integração
Como já foi dito, muitas organizações possuem uma infra-
estrutura de aplicações fragmentadas na qual uma variedade
de aplicações clientes têm que ser criadas utilizando múltiplas
plataformas de programação e comunicação. Neste contexto,
SOA pode facilitar a integração de sistemas heterogêneos já
que a idéia é disponibilizar a lógica desses sistemas em forma
de serviços interoperáveis.
Ingredientes para adoção
Como foi dito anteriormente, SOA não é só tecnologia. SOA
é um conceito amplo, que envolve outros aspectos para que
sua adoção tenha sucesso em um contexto empresarial. Neste
sentido, podemos citar quatro ingredientes fundamentais para
o sucesso de uma SOA: organização, processo, tecnologia e
governança.
Organização
Não adianta tentar implantar uma SOA sem alinhar a TI
com o negócio. Para tanto, é necessário entender a estru-
tura organizacional, suas áreas e unidades, assim como os
processos de negócio de cada uma delas. Neste sentido, é
necessário revisar, caso existam, ou criar, caso não existam,
32 Engenharia de Software Magazine - Arquitetura Orientada a Serviços
os modelos de processos de negócio destas áreas organi-
zacionais. Além disso, é importante que estejam claras
as expectativas e necessidades de cada área em relação à
implantação da SOA.
Como foi explicado, SOA é uma boa solução para integra-
ção. Mas não adianta tentar integrar sistemas de diferentes
unidades organizacionais se estas não estão integradas no
nível de negócio. Portanto é importante, primeiramente,
integrar as áreas de negócio e seus processos.
Processo
Para desenvolver serviços que atendam os princípios da
abordagem orientada a serviços, são necessários técnicas,
métodos e boas práticas de design específicas.
O processo de desenvolvimento de serviços envolve duas
etapas: desenvolvimento para reuso e desenvolvimento
com reuso. O primeiro se preocupa em desenvolver servi-
ços para que eles se tornem os mais reutilizáveis possíveis.
O segundo é criar aplicações reutilizando os serviços
existentes.
Existem algumas metodologias encontradas na literatura.
Algumas delas tentam dar suporte a todo o ciclo de vida
de SOA, incluindo atividades de planejamento, análise e
projeto, construção, teste, implantação e governança, en-
quanto outras limitam seu escopo a um subconjunto destas
atividades. Entretanto, este artigo não tem o objetivo de
detalhar nenhuma dessas metodologias, mas de apenas
dar uma noção geral de atividades que podem fazer parte
de uma metodologia orientada a serviços.
É comum, em um contexto empresarial, existirem dife-
rentes áreas de negócio onde cada uma possui seu próprio
time de desenvolvimento. Neste contexto, sob a perspectiva
de processo de desenvolvimento, um dos principais bene-
fícios de usar SOA, é que ela possibilita um alto grau de
modularização. Esta característica permite que os serviços
possam ser implementados por diversos times. Evidente-
mente, estes times devem respeitar os contratos de serviços.
A Figura 3 ilustra um processo de desenvolvimento para
SOA. O processo possui duas fases. A primeira fase objetiva
especificar a SOA empresarial como um todo, definindo,
entre outras coisas, os serviços que irão compor a SOA.
Uma vez definidos os serviços, estes são alocados para os
diferentes times de desenvolvimento que tem a responsa-
bilidade de construir os serviços sob sua responsabilidade
[Dias, 2009].
Figura 3. Processo de desenvolvimento de uma SOA em um contexto
empresarial

As próximas subseções discutem algumas atividades que
devemos considerar ao projetar uma arquitetura de sistema
baseado em SOA. Porém, não significa que estas atividades
são o suficiente para projetar uma SOA com sucesso, mas
apenas um indicativo para mostrar que, para termos uma
SOA de sucesso, não precisamos apenas de tecnologia, mas
também de uma arquitetura bem projetada. • mensagens do serviço: as mensagens que o consumidor
Identificação de serviços
Esta é uma das mais importantes atividades do projeto orien-
tado a serviços. O objetivo é descobrir os serviços que compõe
a SOA. Em um contexto empresarial onde existem diversas
áreas de negócio, é importante a participação de todos os
interessados, não só dos que fazem parte da área tecnológica,
mas também daqueles que são especialistas nos processos de
negócio de sua área. Isto porque os serviços precisam repre-
sentar bem as funções de negócio destes processos.
A maioria das técnicas para identificar serviços é baseada
nos modelos de processos de negócio. Por isso é importante
ter estes modelos bem especificados.
Aplicação dos princípios da orientação a serviços
Da mesma forma que o paradigma orientado a objetos
possui um conjunto de princípios que devem ser satisfeitos,
o paradigma orientado a serviços também possui princípios
específicos que devem ser seguidos. Depois que os serviços
são identificados, é importante garantir que eles atendam
a estes princípios da orientação a serviço. Entretanto, não
existe uma lista oficial destes princípios. Thomas Erl, em
seu livro “SOA – Princípios de design de serviços”, lista
um conjunto de princípios que devem ser atendidos, tais
como: contratos, acoplamento, abstração, capacidade de
reuso, autonomia, independência de estado, visibilidade e
composição de serviços.
Especificação dos atributos de qualidade
Escolher uma arquitetura que satisfaça aos requisitos
funcionais e aos requisitos não funcionais (atributos de
qualidade) é vital para o sucesso de qualquer sistema. Para
SOA não é diferente. É importante entender como uma SOA
suporta os diferentes atributos de qualidade e quais são
suas implicações para criar um projeto com sucesso. Neste
sentido, as pessoas interessadas e envolvidas na definição
da SOA precisam definir e priorizar os atributos de quali-
dade que irão ser satisfeitos pela SOA. Alguns atributos de
qualidade são: interoperabilidade, performance, segurança,
confiabilidade, disponibilidade, escalabilidade, testabili-
dade, adaptabilidade e reusabilidade. Para cada atributo
definido, é necessário especificar como ele será garantido,
seja através de aplicação de boas práticas de projeto, seja
através de tecnologias.
Especificação dos contratos de serviços
Uma vez conhecidas as interfaces dos serviços e seus
respectivos fornecedores e consumidores em potencial, é
PROJETO
importante definir os contratos destes serviços. Um contrato
de serviço contém os termos acordados pelo fornecedor e
consumidor do serviço.
Algumas informações importantes que o contrato deve
abranger são as seguintes:
• interface do serviço: o nome e as operações do serviço;
e o fornecedor irão trocar para executar o serviço; os tipos
de dados também deverão ser especificados;
• pré e pós condições: as pré e pós condições de cada ope-
ração do serviço;
• atributos de qualidade: os atributos de qualidade que o
serviço deverá satisfazer;
• consumidores potenciais: a lista dos consumidores
conhecidos;
• fornecedor: a entidade, a área, o sistema que irá fornecer
o serviço;
• SLA: se houver um Service-Level Agreement envolvido no
contrato, ele deverá ser especificado.
Projetar e construir serviços
Depois de projetar a arquitetura baseada em SOA, os ser-
viços identificados serão alocados para os times de desen-
volvimento. Cada time de desenvolvimento deve analisar,
projetar, construir e testar os seus serviços. Para tanto, é
importante observar os atributos de qualidade especifica-
dos na fase de definição da SOA. Além disso, o contrato de
serviço deve ser respeitado. A equipe deverá tomar decisões
de como expor as funcionalidades dos seus sistemas (caso
existam) em forma de serviço.
Tecnologia
Atualmente, existe uma variedade de tecnologias rela-
cionadas à SOA. Porém, não é necessário utilizar todas as
tecnologias para dizer que está implementando uma SOA.
Por outro lado, o fato de apenas utilizar uma das tecnologias
não quer dizer necessariamente que está usando SOA. Outra
questão importante é que SOA não está presa a nenhuma
tecnologia. Porém, é evidente que algumas tecnologias já co-
nhecidas são ditas como a melhor forma de se implementar
uma SOA, como por exemplo Web Services.
Abaixo seguem algumas das tecnologias relacionadas à
SOA [Davis, 2009]:
Web Services
Para descrever Web Services, podemos seguir as definições
de alguns fornecedores e institutos de pesquisa, como o
Gartner: “são componentes de software com baixo fator de
acoplamento, utilizados por meio de padrões de tecnologia
Internet. Um Web Service representa uma função de negócio
ou um serviço que pode ser acessado por uma outra aplica-
ção, sobre redes públicas e, geralmente, disponibilizado por
protocolos conhecidos”. Web Service pode ser visto como um
framework de tecnologias que permite a comunicação entre
aplicações heterogêneas através de serviços interoperáveis,
Edição 22 - Engenharia de Software Magazine 33
onde estes serviços podem ser localizados e executados
através de protocolos padronizados. As três especificações
conhecidas do Web Services são o SOAP como protocolo de
comunicação, o WSDL como padrão de descrição de serviços
e o UDDI como padrão de registro de serviço.
Enterprise Service Bus (ESB)
Um ESB pode ser visto como um middleware que tem o
objetivo de facilitar a integração de sistemas. Geralmente
um ESB possui as seguintes funcionalidades: prover se-
gurança, prover transparência de localização, transformar
mensagens, rotear e monitorar as mensagens, gerenciar os
serviços, entre outros.
Existem muitos produtos de ESB disponíveis no mercado
atualmente de fornecedores como IBM, TIBCO, Microsoft e
Oracle. A maioria desses produtos tem um background do
mercado de EAI (Enterprise Application Integration). Porém
também existem soluções open source tais como Mule, Servi-
ceMix, OpenESB e JBossESB. Para quem quer se especializar
mais nestes ESBs open source recomendo o livro Open Source
ESBs in Action [Rademakers, 2009].
Business Process Management System (BPMS)
Esta ferramenta permite a gestão automatizada dos pro-
cessos de negócio da organização. Como foi dito, os serviços
representam funções de negócio na organização. Neste
sentido, os serviços podem ser orquestrados representan-
do fluxos de execução dos processos de negócio. O BPMS
fornece estes recursos, permitindo a execução, controle e
monitoração desses fluxos. Geralmente uma ferramenta de
BPMS possui as seguintes características: ferramenta para
modelagem e desenho do processo; engenho de execução
do processo; orquestração de Web Services e interface de
workflow para usuários.
Enterprise Decision Management (EDM)
Um sistema EDM incorpora uma máquina de regra de
negócio para execução de regras de negócio definidas e um
sistema para gerenciar estas regras. Uma regra de negócio é
uma instrução bem definida relacionada ao negócio, que faz
alguma afirmação sobre algum aspecto de como o negócio
deve funcionar.
A idéia de um sistema baseado em regras, ou EDM, é
separar as regras do código do programa, deixando estas
regras centralizadas, permitindo que as aplicações ou ser-
viços utilizem-nas.
Repositório
Os artefatos gerados em uma SOA devem ser registra-
dos dentro de um repositório para proporcionar o reuso
e fornecer infra-estrutura para gerenciamento dos ativos.
Estes ativos podem incluir serviços, processos de negócio,
orquestrações, regras de negócio, entre outros.
Para pequenas organizações, repositórios informais podem
ser utilizados, como por exemplo um wiki ou uma base de
34 Engenharia de Software Magazine - Arquitetura Orientada a Serviços
dados simples que descrevem os diversos ativos. Porém,
para grandes organizações, é interessante ter um repositório
mais profissional e focado nos ativos da SOA.
Governança
A Gartner declarou que a carência de planejamento rela-
cionado à governança será o principal motivo dos fracassos
em SOA. Um estudo realizado pelo SOA Forum mostra que
as políticas de governança são insuficientes em 88% das
organizações, o que pode comprometer o projeto. Ainda
segundo a Gartner, Governança SOA está relacionada à
garantia de que os ativos de software e artefatos da sua
arquitetura estão operando como esperado e dentro de um
certo nível de qualidade.
Na SOA, consumidores de serviço e fornecedores de serviço
são executados em diferentes processos, são desenvolvidos
e gerenciados por diferentes departamentos e exigem um
grande esforço de coordenação para trabalharem juntos com
sucesso. Para SOA ter êxito, múltiplas aplicações precisam
compartilhar serviços, o que significa que eles precisam ser
coordenados para se tornarem comuns e reutilizáveis. Estes são
os problemas de governança e eles são muito mais complexos
do que nos dias de aplicações monolíticas ou mesmo nos dias
de componentes e códigos reutilizáveis [InfoQ, 2009].
Para o sucesso da governança numa organização é impor-
tante a combinação de pessoas, processos e tecnologias. Além
disso, estando presente essa preocupação desde o início da
implantação da SOA, a transição é mais confortável para a
empresa, além de ajudar no estabelecimento do alinhamento
necessário entre as áreas de negócio e a área de TI, tão im-
portante para pontos como a redução de custos e retorno de
investimento.
Desafios
De acordo com um estudo feito pela InformationWeek [Infor-
mationWeek, 2008], 32% dos projetos SOA não atenderam às
expectativas.
Como qualquer mudança de paradigma, a adoção de SOA
envolve muitos riscos e desafios. Além do desafio de se defi-
nir os aspectos discutidos anteriormente como organização,
processos, tecnologias e governança, existem alguns outros
que devem ser considerados.
Abaixo segue alguns dos limitadores para se adotar SOA.
Cultura
Todas as empresas possuem sua própria cultura, suas crenças
e suas formas de executar suas atividades. A implantação de
uma SOA em uma organização fará com que algumas pessoas
tenham que mudar um pouco sua forma de pensar em relação
a algumas atividades que elas executam. Qualquer mudança de
paradigma é passível a resistência. Neste sentido, é importante
primeiro convencer as pessoas envolvidas e interessadas no
projeto SOA sobre seus benefícios. É importante que todas
as pessoas envolvidas estejam motivadas e interessadas na
transição para SOA.
 PROJETO

Falta de conhecimento Links

Muitas pessoas acham que para adotar uma SOA é necessário
comprar uma caixa com uma solução SOA pronta. Mas como
vimos ao longo deste artigo, a adoção de SOA exige outros
conhecimentos para ter sucesso. Neste sentido, é importante
que a empresa que queira adotar uma SOA busque estes co-
nhecimentos necessários ou então contrate uma consultoria
externa.
Falta de um projeto piloto
Como diz o ditado popular: “a pressa é inimiga da perfei-
ção”. Quando queremos realizar grandes mudanças em uma
empresa, é importante que elas sejam feitas de maneira plane-
jada e que primeiro se realize um projeto piloto, diminuindo
assim os riscos. Com SOA não é diferente. Deve-se escolher
um projeto piloto e executá-lo de maneira controlada para
analisar os riscos.
Falta de comprometimento
Como foi dito, a adoção de SOA envolve muitas mudanças em
uma organização. Por esta razão é importante ter uma equipe
ou uma pessoa totalmente envolvida nestas questões.
Site do DCE/UFPB
http://www.ccae.ufpb.br/dce
SOA Forum
http://www.soaforum.org
Referências
[InformationWeek, 2008] Smith Roger. A simpler approach to SOA (2008).
Disponível em http://www.informationweek.com/news/software/soa/showArticle.
jhtml?articleID=209904293
[Josuttis, 2007] Josuttis, N. SOA in Practice – The Art of Distributed System Design.
O’Reilly, 2007.
[Erl, 2008] Erl, Thomas. SOA – Princípios de design de serviços. Prentice Hall, 2008.
[Davis, 2009] Davis, Jeff. Open Source SOA. Manning, 2009.
[Rademakers, 2009] Rademakers, T., Dirksen, J. Open Source ESBs in Action.
Manning, 2009.
[Dias, 2009] Dias, J. J.; Almeida, E. S.; Meira, S. R. L. A Systematic SOA-based
Architecture Process, 21st International Conference on Software Engineering and
Knowledge Engineering (SEKE), Service Oriented Architecture Track, Boston, U.S.,
2009.

Considerações Finais
Vimos neste artigo que a adoção de SOA em um contexto
empresarial pode trazer vários benefícios, porém envolve tam-
bém muitos desafios, sendo necessário um bom conhecimento
não só das tecnologias que dão suporte a SOA, mas também
[InfoQ, 2009] Artigo da InfoQ. Como Alinhar Processos de TI e Governança SOA
para suportar Iniciativas BPM? (2009) Disponível em http://www.infoq.com/br/
news/2009/02/process-it-soa-governance.
Dê seu feedback sobre esta edição! Feedback
eu

s
Dê
de todo o ciclo de desenvolvimento de uma SOA. A Engenharia de Software Magazine tem que ser feita ao seu gosto.

sobre e
Entretanto, SOA não é a solução para todos os problemas. Para isso, precisamos saber o que você, leitor, acha da revista!

s
ta
Cada caso deve ser analisado de forma apropriada para que
edição
Dê seu voto sobre este artigo, através do link:
seja avaliado o seu custo e se o retorno do investimento é
www.devmedia.com.br/esmag/feedback
interessante.

Edição 22 - Engenharia de Software Magazine 35

Abordagens Tradicionais de Desenvolvimento
Esta seção traz artigos que apresentam como e quando utilizar as diferentes abordagens
tradicionais de apoio ao desenvolvimento de projetos de software
Arquitetura de Software
Atributos para decisões do projeto arquitetural
Antonio Mendes da Silva Filho
antoniom.silvafilho@gmail.com
Professor e consultor em área de tecnologia
da informação e comunicação com mais
de 20 anos de experiência profissional, é
autor do livros Arquitetura de Software
e Programando com XML, ambos pela
Editora Campus/Elsevier, tem mais de 30
artigos publicados em eventos nacionais
e internacionais, colunista para Ciência e
Tecnologia pela Revista Espaço Acadêmico
com mais de 80 artigos publicados, tendo
feitos palestras em eventos nacionais e ex-
terior. Foi Professor Visitante da University
of Texas at Dallas e da University of Ottawa.
Formado em Engenharia Elétrica pela Uni-
versidade de Pernambuco, com Mestrado
em Engenharia Elétrica pela Universidade
Federal da Paraíba (Campina Grande),
Mestrado em Engenharia da Computação
pela University of Waterloo e Doutor em
Ciência da Computação pela Univesidade
Federal de Pernambuco.
36 Engenharia de Software Magazine - Arquitetura de Software
S
oftware é uma entidade que se
encontra quase permanentemente
sendo modificado. Tais mudanças
ocorrem devido à necessidade de corrigir
erros existentes no software ou de adi-
cionar novos recursos e funcionalidades.
Igualmente, os sistemas computacionais
(isto é, aqueles que têm software como
um de seus elementos) também estão
sujeito a mudanças frequentes. Isso
pode motivar um sistema de software a
se tornar ‘não confiável’ e predisposto a
defeitos, bem como ocasionar atraso na
entrega e elevação de custos acima do
estimado. Concomitante com esses fatos,
o crescimento em tamanho e complexi-
dade dos sistemas de software exige que
De que se trata o artigo?
Apresenta um conjunto de informações que po-
dem subsidiar decisões de projeto arquitetural de
sistemas de software.
Para que serve?
Entender o papel do projeto arquitetural dentro do
processo de desenvolvimento de software orienta-
do para arquitetura e identificação de informações
necessárias às decisões de projeto.
Em que situação o tema é útil?
Identificação de informações e critérios que
apóiam as atividades de análise e projeto de
arquitetura de software.
os profissionais da área raciocinem, pro-
jetem, codifiquem e se comuniquem por
meio de componentes de software. Como
resultado, qualquer projeto ou solução de
sistema requer decisões arquiteturais (de
projeto) que podem impactar o produto
final. A necessidade da arquitetura de
software prover suporte a um conjunto
de requisitos, geralmente conflitantes,
exige que decisões arquiteturais sejam
tomadas ainda durante o projeto, tema
esse tratado neste artigo.

Projeto da Arquitetura de Software
Um projetista desenvolve um projeto considerando um con-
junto de decisões de projeto. Para tomar decisões, ele leva em
conta os requisitos arquiteturais que motivam e justificam suas
decisões. Por trás disto, também estão metas de qualidade de-
sejadas para o sistema a ser desenvolvido, bem como cenários
de uso, estilos arquiteturais existentes e padrões de projeto. A
Figura 1 ilustra essa visão do projeto arquitetural.
estilos arquiteturais
cenários de uso
Projeto Documentação
arquitetural da
padrões de projeto arquitetura
requisitos arquiteturais
Figura 1. Elementos de decisão do projeto arquitetural
Perceba que o projeto arquitetural é uma fase iterativa do
processo de desenvolvimento de sistema software sobre a
qual o projetista ou arquiteto de software precisa raciocinar
a fim de tomar decisões, levando em consideração os requisi-
tos arquiteturais e cenários de uso, por exemplo. O arquiteto
pode ainda fazer uso de técnicas de análise arquitetural para
apoiar seu raciocínio sobre o comportamento de atributos
de qualidade. Tais técnicas podem acrescentar informações
aos estilos arquiteturais de modo a possibilitar o raciocínio
qualitativo e quantitativo.
Perceba que há uma interação entre as fases de análise e
projeto de arquitetura de software. Tal interação surge da
necessidade de refinar os requisitos arquiteturais elicitados
na fase anterior do processo de desenvolvimento orientado
para arquitetura, como ilustrado na Figura 2.
Elicitação de
requisitos arquiteturais
Projeto Documentação
arquitetural da arquitetura
Análise
arquitetural
Implementação
da arquitetura
Figura 2. Desenvolvimento orientado para arquitetura de software
PROJETO
A interação existente entre as fases de projeto e análise
arquitetural permite o refinamento da documentação da ar-
quitetura do sistema que culminará com sua implementação.
É importante observar ainda que, durante a implementação,
pode haver necessidade de reconsiderar decisões de projeto
tomadas anteriormente.
Uma vez que a arquitetura de software tenha sido obtida,
essa pode evoluir e, portanto, requer que novos requisitos
arquiteturais sejam elicitados a fim de satisfazer às mudanças
desejadas. Deste modo, características são adicionadas e/ou
modificadas.
Dimensões e Regras de Projeto
Projetos inovadores são, geralmente, desenvolvidos para
resolver novos tipos de problemas ou até mesmo prover
solução a algum problema com requisitos bem específicos.
Entretanto, os custos associados podem ser elevados. Nesse
sentido, a comunidade de engenharia de software e, mais
especificamente, de arquitetura de software, tem procurado
organizar o conhecimento de projeto de sistemas de software.
Uma forma de fazer isto é desenvolvendo um vocabulário,
englobando conceitos e padrões de projetos que possam ser
facilmente compreendidos e reutilizáveis. Como resultado
deste esforço, tem-se:
1. A possibilidade de desenvolver um projeto de sistema a
partir de blocos estruturais.
2. Entendimento e antecipação das propriedades de um projeto.
3. Redução do esforço necessário para compreender o projeto
de outra pessoa.
Um exemplo de organização de conhecimento através de
um vocabulário é a codificação de estruturas de controle do
fluxo de instruções em um algoritmo, onde dispomos de es-
truturas sequenciais, de decisão e repetição. Isto oferece um
entendimento sobre os padrões de fluxo de controle no qual é
feito uso desses blocos estruturais. Uma forma de organizar o
conhecimento a ser utilizado no projeto arquitetural é obtendo
um conjunto de soluções de projeto em termos de dimensões
de projeto. Cada dimensão nesse conjunto solução descreve
uma característica do sistema ou decisão de projeto.
Considere, por exemplo, que o tempo de resposta de um sistema
seja uma dimensão no conjunto solução. Similarmente, o meca-
nismo de sincronização entre processos também pode ser visto
como outra dimensão. A Figura 3 ilustra essas duas dimensões
envolvendo dois sistemas exemplo quaisquer. A figura sugere
que o mecanismo de mensagens oferece um tempo de resposta
melhor quando comparado a semáforos.
A existência de diferentes dimensões não implica que elas
sejam independentes. Na realidade, é de suma importância
identificar correlações entre as dimensões. Como resultado,
isto permite a criação de regras de projeto que especificam
quão adequada é a combinação de opções. Uma forma empírica
de determinar a existência de correlações é checando se há
agrupamento de soluções de projeto em uma região do conjun-
to solução e sua ausência é verificada em outras regiões.
Edição 22 - Engenharia de Software Magazine 37
 tempo de
resposta
rápido sistema X
médio sistema Y
lento
mensagens semáforos monitores rendezvous outro
Figura 3. Exemplo simples de conjunto solução de projeto
Um aspecto essencial no conjunto solução é escolher algumas
dimensões que reflitam requisitos não funcionais (desempe-
nho, confiabilidade), ao passo que outras dimensões reflitam
a organização do sistema. A existência de correlações entre
essas dimensões servirá à orientação do projeto, ou seja, elas
mostrarão como opções de projeto podem satisfazer aos re-
quisitos de um sistema.
O conjunto solução, juntamente com as regras de projeto
(derivadas das correlações existentes entre as dimensões do
sistema), compreende alternativas de projeto arquitetural para
o sistema a ser desenvolvido. Nas seções subsequentes, toma-se
um sistema interativo como exemplo para ilustrar dimensões
e regras de projeto. Antes, contudo, um modelo arquitetural
e estruturas associadas a ele é discutido.
Modelo Arquitetural
Conforme ilustrado na Figura 2, o projeto arquitetural é uma
atividade iterativa onde decisões de projeto importantes são
tomadas. Os requisitos arquiteturais, juntamente com cenários
de uso, são utilizados na tomada dessas decisões. Um modelo
arquitetural é utilizado para descrever um sistema decomposto
em um conjunto de módulos ou componentes conectados por
meio de conectores. Tanto os componentes quanto os conecto-
res possuem propriedades que são utilizadas para diferenciar
tipos de componentes e tipos de conectores, bem como oferecer
informações úteis às diversas análises realizadas. Exemplos
incluem as análises de confiabilidade e desempenho.
O modelo arquitetural pode ainda ser descrito em termos
de estruturas básicas. Essas estruturas são consideradas como
representações fundamentais da informação arquitetural,
ou seja, elas representam os artefatos resultantes de projeto
e implementação. Exemplos compreendem classes, objetos,
funções, arquivos, bibliotecas, e assim por diante. Abaixo,
apresentamos um conjunto de cinco estruturas que podem ser
utilizadas para descrever um modelo arquitetural.
• Estrutura funcional – refere-se à decomposição de funcio-
nalidade que o sistema precisa suportar. Os componentes são
entidades funcionais enquanto que os conectores servem à
passagem de dados entre os componentes. Essa estrutura é útil
para entender as interações existentes entre os componentes e
para planejar a funcionalidade do sistema.
• Estrutura de código – está relacionada com as abstrações de
código usadas no desenvolvimento do sistema. Componentes
são entidades que empacotam funcionalidades do sistema em
vários níveis de abstração, tais como: classes, objetos, funções,
38 Engenharia de Software Magazine - Arquitetura de Software
procedimentos e métodos. Os tipos de conexão envolvem pas-
sagem de controle, passagem de dados, compartilhamento de
dados, dentre outras.
• Estrutura de concorrência – refere-se à concorrência lógica. Os
componentes dessa estrutura compreendem entidades de con-
corrência que são refinadas em processos e threads (ou processos
sincronização leves). Alguns tipos de conexões incluem: enviar dados para,
entre processos
ter prioridade maior do que, sincronizar com, dentre outras.
Adicionalmente, as propriedades associadas a essa estrutura
envolvem, por exemplo, tempo de execução e prioridade. Essa
estrutura é de suma importância para entender desempenho.
Também, ela é considerada essencial para confiabilidade e
segurança. Informações relevantes associadas a essa estrutura
compreendem o número de processos e threads, o tempo de
execução, bem como prioridades dos processos e threads.
• Estrutura física – está intimamente associada ao hardware
do sistema. Inclui a unidade central de processamento (CPU),
barramentos, memória, dispositivos de entrada e saída (E/S).
Propriedades relevantes à estrutura compreendem capacidade
e disponibilidade.
• Estrutura de desenvolvimento – refere-se aos arquivos e
diretórios. As metas dessa estrutura incluem gerenciar e as-
segurar o controle administrativo do sistema à medida que ele
evolui. Isso envolve gerenciamento de configuração e divisão
de tarefas entre membros da equipe.
Perceba que, durante o desenvolvimento de um sistema ou,
mais especificamente, durante o projeto da arquitetura de um
sistema, um projetista ou arquiteto de software pode recorrer
a uma ou mais estruturas, podendo expor as informações
necessárias e ocultar as desnecessárias. Assim, se ele analisa,
por exemplo, a funcionalidade e facilidade de modificações de
um sistema, a distribuição não constituirá um fator relevante.
Note que a estrutura de código abstrai questões associadas à
distribuição. Todavia, se o arquiteto está raciocinando sobre
o desempenho, então a distribuição passa a ser fator relevan-
te, enquanto que a parte funcional passa a ter importância
secundária. Nesse caso, considera-se a estrutura de concor-
rência como sendo a mais adequada. A Tabela 1 ilustra um
conjunto de requisitos não funcionais e estruturas relevantes
associadas a eles.
Requisito não funcional Estruturas relevantes
Desempenho concorrência, física
Manutenibilidade funcional, código, desenvolvimento
Confiabilidade física, concorrência
Disponibilidade física, concorrência
Tabela 1. Requisitos não funcionais e estruturas relevantes
Dimensões Funcionais e Arquiteturais
As dimensões funcionais e arquiteturais de um sistema
descrevem requisitos associados à funcionalidade e organi-
zação do sistema que compreende o conjunto solução de um
projeto. Uma dimensão pode ser vista como uma alternativa

ou opção de projeto. Assim, cada dimensão descreve uma
alternativa na caracterização ou decisão de projeto de um
sistema.
Objetivando caracterizar essas dimensões, tomaremos
como exemplo um sistema interativo. Um sistema interativo,
como o próprio nome indica, oferece suporte à comunicação
bidirecional entre usuário e computador. O sistema reage às
ações de usuários, exibindo alguma informação, ou ativando
algum dispositivo para execução de um serviço. Tudo isto
ocorre através da interface com usuário que fornece acesso às
funcionalidades e recursos do sistema.
O modelo arquitetural de um sistema interativo, no qual
a interface com usuário é o principal componente, pode ser
decomposto em três componentes, conforme mostrado na
Figura 4.
Componente Componente
dependente compartilhado
de dispositivo de interface
com usuário
interface com interface com
dispositivo aplicação
Figura 4. Modelo arquitetural de um sistema interativo
O componente específico da aplicação compreende o código
que é específico ao programa de uma aplicação, não sendo
reutilizado em qualquer outra aplicação. Especificamente,
este componente incorpora o núcleo funcional da aplicação.
Ele pode ainda incluir o código da interface de usuário que
é específica da aplicação. O componente compartilhado de
interface com usuário engloba o código que provê suporte à
interface com usuário de múltiplos programas de aplicação.
Se o sistema de software pode acomodar diferentes tipos
de dispositivos de entrada e saída (E/S), então apenas a
parte do código que é associado aos tipos de dispositivos
é incorporada aqui. O componente dependente de dispositivos
compreende o código que é pertinente a uma classe espe-
cífica de dispositivos de entrada e saída (E/S), não sendo
específico da aplicação.
Dimensões Funcionais em Sistemas Interativos
As dimensões funcionais identificam os requisitos de um
sistema interativo que mais afetam a organização do sistema,
ou seja, elas identificam as especificações que precedem o
projeto arquitetural do sistema. Estas dimensões podem ser
divididas em três categorias:
1. Requisitos externos – engloba requisitos de aplicações,
usuários, dispositivos de entrada e saída, bem como restrições
impostas ao sistema.
2. Comportamento da interface – inclui decisões sobre o
comportamento da interface com usuário que afetam a orga-
nização do sistema.
3. Considerações práticas – considerações de custo de desen-
volvimento bem como nível de adaptabilidade do sistema são
enquadradas aqui.
PROJETO
Requisitos Externos
Um exemplo de requisito externo é o tratamento de even-
tos externos. Em outras palavras, essa dimensão indica se a
aplicação necessita responder a eventos externos (definidos
como eventos que não se originam na interface com usu-
ário). Desse modo, no conjunto solução de projeto, há três
alternativas:
• Sem eventos externos – a aplicação não é afetada por eventos
externos ou então em função da execução de comandos específi-
cos dos usuários. Um exemplo disso ocorre no programa de cor-
reio eletrônico que apenas checa se há mensagens novas quando
recebe comando específico para realizar esta tarefa. Assim, não
há necessidade de prover suporte a eventos externos.
• Processar eventos enquanto aguarda entrada – a aplicação deve
tratar os eventos externos. Todavia, os requisitos de tempo de
resposta não são tão severos de modo a interromper a execução
Componente de comandos de usuários. Nesse caso, o sistema responde a
específico da eventos externos enquanto aguarda por algum comando.
aplicação
• Eventos externos interrompem comandos de usuários – o aten-
dimento a eventos externos tem prioridade maior do que a
execução de comandos de usuários, a qual é interrompida
quando algum evento externo ocorre. Esse requisito é comum
de ser encontrado em sistemas de tempo real.
Um segundo exemplo de requisito externo é a customização
de usuário. O conjunto solução de projeto pode decompor a
customização de usuário de uma interface em três níveis:
• Alta – o usuário pode adicionar novos comandos ou redefinir
os existentes. Além disso, ele poderia modificar detalhes da
interface com usuário.
• Média – o usuário pode alterar detalhes da interface com
usuário que não afetem a semântica como, por exemplo, mo-
dificar o tamanho de janelas, cores, dentre outros.
• Baixa – nesse caso, pouca ou nenhuma customização é
exigida do usuário.
Outro exemplo de dimensão é a adaptabilidade da in-
terface com usuário a dispositivos, a qual depende da
quantidade esperada de dispositivos de entrada e saída
que a interface com usuário precisa oferecer suporte. Essa
dimensão indica o grau de mudança no comportamento
da interface com usuário em função da modificação no
dispositivo de entrada e saída.
• Nenhuma – todos os aspectos de comportamento perma-
necem os mesmos em todos os dispositivos de entrada e
saída. Isso pode ocorrer quando apenas um único conjunto
de dispositivos de entrada e saída é suportado.
• Modificações locais no comportamento – aqui, há apenas alte-
rações de poucos detalhes no comportamento da interface
com usuário. Um exemplo disso é a alteração da aparência
de menus.
• Modificações globais no comportamento – há mudanças
maiores no comportamento da interface com usuário. Uma
modificação de interface baseada em menus para interface
baseada em linguagem de comando é um exemplo.
Edição 22 - Engenharia de Software Magazine 39
• Modificações na semântica da aplicação – nesse caso, há mudança
na semântica de comandos. Um exemplo ocorre numa alteração
de exibição contínua de um estado e exibição sob comando.
Um quarto exemplo de dimensão é organização do sistema
de software. Essa dimensão categoriza a natureza básica da
organização global do sistema em:
• Uniprocessamento – apenas uma aplicação é executada de
cada vez.
• Multiprocessamento – múltiplas aplicações podem ser execu-
tadas concorrentemente.
• Processamento distribuído – aqui o ambiente envolve uma rede
de computadores com múltiplas CPUs e custos de comunicação
associados.
Outra dimensão compreende os mecanismos existentes para
múltiplas threads de controle. Essa dimensão depende do
sistema operacional o qual pode oferecer suporte aos seguintes
mecanismos para múltiplas threads de controle:
• Processos – estes são processos padrões com proteção entre
processos (tipicamente, espaço de endereçamento distintos).
• Processos leves – estes constituem processos que podem
ser executados de forma independente, sem proteção entre
processos.
• Processos não preemptivos – são processo que não são inter-
rompidos durante sua execução.
• Rotinas de serviços de interrupção – refere-se ao tratamento de even-
tos a nível de hardware. Nesse caso, execuções de rotinas de serviço
de interrupção podem ser vistas como threads de controle.
• Nenhum – ocorre quando o sistema não oferece suporte a
múltiplas threads de controle.
Comportamento da Interface
Esta categoria de dimensão funcional identifica o tipo de inte-
ração que sistema interativo suporta. O conjunto solução, nesse
caso, pode englobar os seguintes mecanismos de interação:
• Seleção de menu – este tipo de interação é baseado na seleção
repetida de um conjunto de opções. Em caso passo, as opções
são mostradas.
• Manipulação direta – faz uso de representação gráfica e ma-
nipulação de dados do programa.
• Formulários – nesse tipo de interação o usuário entra com da-
dos (geralmente na forma textual) em um conjunto de campos
associados a variáveis.
• Linguagem de comando – esse tipo de interação é baseado em
linguagem simbólica. Normalmente, pode-se ter uma extensão
de definições de procedimentos similares àqueles encontrados
em linguagens de programação.
• Linguagem natural – faz uso de um subconjunto de alguma
língua como, por exemplo, o Inglês.
Considerações Práticas
Outra categoria da dimensão funcional especifica o nível de
adaptabilidade exigido pelo sistema. Geralmente, um sistema
que oferece um maior nível de adaptabilidade suporta uma
40 Engenharia de Software Magazine - Arquitetura de Software
quantidade maior de aplicações, embora ele possa ter um
custo mais elevado. Os termos adaptabilidade e portabilidade
são utilizados algumas vezes indistintamente. Aqui, fazemos
opção pelo segundo.
Um exemplo de dimensão é a portabilidade da aplicação
junto a estilos de interação. Nesse caso, estamos interessados
em saber o nível de portabilidade de aplicações que utilizarão
os estilos de interação. Assim, pode-se ter:
• Alta – as aplicações deveriam ser portáveis em estilos de
interação distintos como, por exemplo, seleção de menus ou
linguagem de comandos.
• Média – as aplicações não deveriam ser dependentes de
pequenas variações no estilo. Um exemplo é a aparência de
menus.
• Baixa – variações na interface com usuário não é um fator
preponderante, implicando que uma aplicação pode sofrer
mudanças desde que a interface com usuário possa ser mo-
dificada, também.
Outra dimensão nessa categoria é a portabilidade da apli-
cação junto a sistemas operacionais. Aqui, o interesse recai
em saber o nível de portabilidade exigido pelas aplicações
que usarão o software de interface junto a vários sistemas
operacionais. O nível de portabilidade pode ser:
• Alta – as aplicações deveriam ser portáveis em diferentes
sistemas operacionais e hardware distintos.
• Média – nesse caso, as aplicações deveriam ser portáveis
em variantes de um sistema operacional como, por exemplo,
diferentes versões do Unix.
• Baixa – aqui, a portabilidade não constitui um fator
relevante.
Dimensões Arquiteturais em Sistemas Interativos
As dimensões estruturais representam as decisões que de-
terminam a organização global de um sistema computacional.
As dimensões estruturais podem ser enquadradas em três
classes:
1. Divisão de funções e conhecimento entre componentes
– aqui, o interesse maior encontra-se em saber como a funcio-
nalidade é dividida e associada a componentes, bem como se
dá a interação entre componentes.
2. Comunicação, sincronização e fluxo de controle – refere-
se ao comportamento dinâmico do software da interface com
usuário.
3. Representação de informação – refere-se à representação
de dados utilizados pelo sistema. Esses dados compreendem
tanto os dados passados à interface com usuário bem como
os dados que especificam a aparência e comportamento da
interface.
Divisão de funções e conhecimento entre componentes
A Figura 4 ilustra as principais divisões encontradas num
sistema interativo. Aqui, o principal interesse recai em saber
como as funções são associadas a componentes e como estes
componentes interagem uns com os outros. Perceba que há

duas divisões importantes no sistema interativo mostrado na fi-
gura: a interface com aplicação e a interface com dispositivo.
O conjunto solução engloba alguns tipos de interface com
aplicação. Essa dimensão é baseada no nível de abstração da
comunicação, dentre os quais destacamos:
• Programa monolítico – nesse caso, não há separação entre
o código específico da aplicação e o código compartilhado.
Portanto, não existe qualquer interfaceamento entre eles. Este
pode ser adequado em programas menores.
• Toolkit – a parte do código que é compartilha fornece uma
biblioteca de mecanismos de interação, tais como menus e
barras deslizantes. Desse modo, a aplicação é encarregada de
escolher os elementos adequados do toolkit (ou kit de ferramen-
tas) a fim de compor a interface com usuário. Sendo assim, a
parte do código que é compartilhada pode controlar apenas
aspectos locais do estilo da interface com usuário, ficando o
comportamento global sob o controle da aplicação.
• Gerente de interação – se existe a necessidade de prover suporte
à portabilidade da aplicação junto a dispositivos e estilos de in-
teração, então dispor de um gerente de interação constitui uma
boa opção. O gerente de interação permite fazer a separação
entre o comportamento da interface com usuário e a aplicação.
Além disso, o gerente de interação faz com que a aplicação
tenha menos controle sobre a interface com usuário.
Comunicação, Sincronização e Fluxo de Controle
Similarmente às classes de dimensões anteriormente vistas,
aqui o interesse está sobre a comunicação entre componentes.
Também, o comportamento da interface com usuário é consi-
derado. Essa classe pode englobar as dimensões abaixo.
O fluxo de controle da aplicação refere-se à forma na qual
se dá o processamento de entrada no fluxo de controle da
aplicação. Pode ser:
• Ponto de entrada único – o sistema possui um laço de eventos
que constitui o único ponto no qual qualquer entrada do
usuário é aceito. Dessa forma, quando um evento de entrada
é recebido, ele é processado e depois o controle é devolvido ao
laço de evento que aguardará o próximo evento.
• Múltiplos pontos de entrada – a entrada é aceita em múltiplos
pontos do fluxo de controle da aplicação. Geralmente, cada
um desses pontos pode tratar apenas um subconjunto de
entradas.
Outra dimensão é o tratamento de entradas assíncronas.
Está relacionada com a forma na qual eventos ou ações de
usuários são tratados quando as aplicações estão ocupadas.
Nesse caso, elas podem ser:
• Ignoradas – a entrada assíncrona é, simplesmente, ignorada.
• Enfileirada antes do processamento – os eventos de entrada são
colocados numa fila sem que haja processamento. Com isso,
não há resposta imediata (ou feedback) até que a aplicação esteja
habilitada.
• Ter um processamento parcial e serem enfileiradas – algum proces-
samento é realizado para fornecer feedback. Depois, os eventos
são colocados numa fila do tipo FIFO (First-In, First-Out).
PROJETO
A terceira dimensão é a granulosidade de comunicação da
aplicação. Essa dimensão refere-se à frequência na qual se dá
a comunicação entre a aplicação e componente da interface
com usuário. A granulosidade pode ser:
• Fina – uma vez para cada evento de entrada. Nesse caso, a
aplicação é fortemente acoplada às ações de usuários e, tam-
bém, participa na geração de resposta ou feedback.
• Grossa – ocorre uma vez a cada comando completo, sendo
a aplicação desacoplada de ações de usuários e geração de
feedback.
Outra dimensão importante é o mecanismo de comunica-
ção por eventos. Esse mecanismo deveria ser oferecido para
suportar a comunicação através da passagem de eventos entre
componentes. Podem-se ter os seguintes mecanismos de co-
municação por eventos:
• Nenhum – quando eventos não são utilizados. Se isso ocorre,
tem-se a comunicação baseada simplesmente em estados.
• Chamada direta de procedimentos – trata-se do mecanismo
padrão de chamada de procedimentos. Isso inclui chamada
de procedimentos remoto, contanto que a parte chamada do
código seja diretamente informada.
• Chamada indireta de procedimentos – refere-se à chamada de
procedimentos na qual a parte do código chamado não é total-
mente especificada. Ao invés, é determinada dinamicamente
como ocorre numa chamada de um método em orientação a
objetos.
• Mensagem assíncrona – ocorre quando um evento é passado de
uma thread de controle para outra sem que a origem do evento
aguarde o recebimento do evento.
• Mensagem síncrona – diferentemente de uma mensagem as-
síncrona, aqui o evento é passado de uma thread de controle
para outra e a thread que originou a mensagem fica bloqueada
até que a thread de destino tenha recebido e respondido a
mensagem.
Note que, embora o mecanismo de comunicação utilizando
mensagem síncrona tenha menor custo de implementação,
quando comparado ao uso de mensagem assíncrona, pode se
deparar com problemas de sincronização devido às dependên-
cias de tempo entre as threads de controle.
Representação da Informação
Como o foco principal dá-se na organização global do
sistema, o interesse maior recai sobre as representações que
são compartilhadas entre os componentes do sistema. Desse
modo, as representações utilizadas para dados da interface
com usuário são consideradas. Pode-se então vislumbrar duas
dimensões associadas a tipos de representação:
• Representação para definição da interface com usuário - é
uma dimensão que permite classificar as técnicas utilizadas
a fim de definir tanto o comportamento quanto a aparência
da interface com usuário.
• Representação de informação semântica - classifica as téc-
nicas usadas para definir a informação semântica da aplicação
Edição 22 - Engenharia de Software Magazine 41
necessária à interface com usuário. Esse tipo representação
inclui notações declarativa e procedimental.
Regras de Projetos para Sistemas Interativos
Esta seção discute um conjunto de regras de projeto para
sistemas interativos que relacionam as dimensões funcionais
e arquiteturais do conjunto solução. As regras apresentadas a
seguir não constituem um conjunto completo. A intenção é de
ilustrá-las, tomando como exemplo os sistemas interativos. São
descritas em forma de narrativa de uma maneira informal, po-
dendo serem vistas como um conjunto de diretrizes de projeto.
Abaixo, apresenta-se o conjunto dessas diretrizes.
• Requisitos mais restritos para a portabilidade da interface
com usuário junto a dispositivos favorecem a níveis mais
elevados da abstração da interface de aplicação de modo a
desacoplar o componente de aplicação do componente de
interface com usuário, uma vez que este último pode sofrer
modificações em função da necessidade de conectar com dis-
positivos. Note que, se existe um requisito de comportamento
global ou se a semântica da aplicação muda, então dispositivos
abstratos parametrizados são favorecidos. Isto decorre do fato
de que tais mudanças precisam ser implementadas numa parte
do código compartilhado da interface com usuário ou no có-
digo da aplicação, ao invés de ser implementado no driver do
dispositivo. É importante observar que a informação sobre o
dispositivo em consideração não pode ser ocultada em níveis
mais elevados de abstração (da forma como outras classes de
dispositivos abstratos tentam fazer).
• Um requisito de portabilidade da aplicação junto a estilos de
interface com usuário favorece a opção por níveis mais eleva-
dos da abstração da interface de aplicação. Também favorece
a mecanismos de comunicação baseado em eventos. Por outro
lado, um mecanismo de comunicação híbrido não seria o mais
adequado desde que ele atenda a padrões de comunicação que
podem sofrer alteração quando o estilo de interface muda.
• Se existe a necessidade de tratar eventos externos, então
devem-se fornecer threads de controle separadas, objetivando
desacoplar a lógica de tratamento de eventos da lógica de
interface com usuário.
• Os mecanismos de threads de controle mais comuns são pro-
cessos, processos leves e tratadores de eventos. Para suportar
as atividades das interfaces com usuário, o uso de processos
leves é mais apropriado.
• Se o tempo máximo de execução de comando é curto, então a
alternativa mais simples é utilizar uma única thread de controle.
Todavia, para comandos com tempos maiores, há a necessidade
de usar múltiplas threads de controle a fim de possibilitar que
o processamento de solicitações de usuário continue.
Acima, algumas diretrizes a serem seguidas no projeto
arquitetural de um sistema interativo foram discutidas. A
seguir, apresenta-se um conjunto de regras de projeto base-
adas na correlação das dimensões discutidas anteriormente.
Note que essas regras constituem recomendações e o conjunto
apresentado não é completo. Entretanto, serve como uma
42 Engenharia de Software Magazine - Arquitetura de Software
contribuição no esforço de codificar o conhecimento sobre
projeto de sistemas interativos.
Adicionalmente, as regras de projeto apresentadas abaixo
se encontram expressas na forma narrativa. Uma alternativa
a esta apresentação seria colocá-las numa descrição mais for-
mal com pesos associados de modo a combinar as diferentes
dimensões, identificando as correlações existentes e atribuindo
escores a elas. Assim, por exemplo, uma combinação envol-
vendo o uso de uma única thread de controle e a inexistência
de eventos externos receberia um escore positivo. Esse escore
positivo indicaria que utilizar uma única thread de controle é
uma boa solução para o requisito dado (ou seja, a inexistência
de eventos externos).
Perceba que, uma vez um escore seja obtido em cada de-
cisão arquitetural, então a combinação de regras de projeto
utilizadas com os respectivos escores resultam no escore
geral que reflete o escore obtido para o projeto do sistema em
desenvolvimento.
Se um conjunto de regras for desenvolvido para uma classe
de aplicações, então se torna possível automatizar o processo
de determinar as decisões de um projeto arquitetural. Neste
caso, o sistema automatizado iria apresentar um conjunto de
recomendações de projeto que poderiam ser comparadas com
as decisões que o projetista ou arquiteto de software tenha
tomado.
Divisão de Funcionalidade
A Figura 4 ilustra um modelo arquitetural de um sistema
interativo composto de três componentes: componente de
aplicação, componente de interface com usuário e componente
específico de dispositivos. Esses componentes são agrupados
através de duas interfaces: interface de aplicação e interface
de dispositivos.
Interface de Aplicação
• Programa monolítico – essa é uma solução adequada em sis-
temas pequenos onde a aplicação tem maior controle sobre
o componente de interface com usuário e dispõe de pouca
capacidade de processamento. Essa opção não deveria ser
selecionada se há estrito requisito de flexibilidade, tais como:
flexibilidade de estilos de interação da interface com usuário,
variabilidade de dispositivos de entrada e saída ou customi-
zação pelo usuário. Essa opção pode atender aos requisitos
de interfaces de manipulação direta, embora o esforço de
desenvolvimento seja maior.
• Toolkit – essa alternativa é recomendada quando um nível
moderado de flexibilidade é desejado. Além disso, essa solução
oferece economia significativa de esforço de desenvolvimento,
bem como suporta flexibilidade ao sistema. O toolkit pode ser
desconsiderado quando necessário. Também, se existe a meta
de que um estilo de interação de interface com usuário padro-
nizado seja implementado, então constitui um boa opção uma
vez que alguns componentes padrões como menus podem ser
mais facilmente suportados pelo toolkit, tornando desnecessá-
rio qualquer esforço adicional de implementação.

• Gerente de interação – se existe um requisito de que o sistema
deve prover portabilidade junto a estilos de interação e dispo-
sitivos, então uma solução é dispor de um gerente de interação
que permite a separação entre o componente da aplicação e
comportamento de interface com usuário. Adicionalmente,
o gerente de interação faz com que a aplicação tenha menos
controle sobre a interface com usuário.
• Dispositivo abstrato – se existe um requisito de que o sistema
deve prover portabilidade junto a estilos de interação da inter-
face com usuário, então essa solução não é uma boa opção. Essa
solução é recomendada quando a portabilidade da aplicação
é desejada junto a uma pequena quantidade de dispositivos.
Note, contudo, que a maior parte do controle da interface com
usuário fica sob responsabilidade do componente de aplicação.
Essa solução não deveria ser utilizada quando se deseja supor-
tar uma quantidade maior de dispositivos de entrada e saída,
pois isto exigirá um esforço muito maior de desenvolvimento,
devido à necessidade de tratar uma quantidade maior de casos,
bem como pode se perder o controle sobre aspectos da interface
com usuário, caso o driver oculte muitos detalhes).
Interface de Dispositivos
• Dispositivo ideal – nessa opção, todas as questões da varia-
bilidade de dispositivos são ocultadas do software no nível
acima do driver de dispositivo. Dessa forma, há suporte à
portabilidade da aplicação. Essa alternativa não é adequada se
existe a necessidade de grandes mudanças no comportamento
da interface com usuário para atender as diferenças entre os
dispositivos. Em outras palavras, essa opção satisfaz apenas
a um pequeno número de dispositivos.
• Dispositivo parametrizado – essa solução acomoda uma quan-
tidade maior de dispositivos de entrada e saída e possibilita
modificações no comportamento da interface com usuário
junto a dispositivos. Uma desvantagem é que a parte do código
independente de dispositivo pode precisar fazer análises com-
plexas a fim de atender a um espectro maior de dispositivos.
Essas análises podem requerer uma significativa capacidade
de processamento. Se isso tiver de ser feito em cada aplicação,
então seu custo será elevado. Assim, uma alternativa é reduzir
a quantidade de casos a serem suportados nessa abordagem.
• Dispositivo com operações variáveis – se as operações de dispo-
sitivos são selecionadas num nível elevado de abstração para
permitir que o driver de dispositivo tenha liberdade de escolha,
então esta é uma boa solução. Nesse caso, apenas mudanças
locais no comportamento da interface com usuário podem ser
suportados a nível do driver de dispositivo. Entretanto, mu-
danças na semântica da aplicação não podem ser suportadas.
Se essas condições casam com as metas do sistema, então essa
solução pode oferecer suporte a uma quantidade maior de
dispositivos. Além disso, os custos na capacidade de proces-
samento dessa alternativa são relativamente baixos.
Comunicação, Sincronização e Fluxo de Controle
O foco dessa seção está em questões que englobam meca-
nismos de comunicação e fluxo de controle. Dessa forma, o
PROJETO
interesse está sobre as relações de controle existentes entre os
componentes do sistema e a maneira como ocorre a sincroni-
zação da sequência de eventos. Além disso, há ainda interesse
na maneira como ocorre a comunicação entre os diversos
componentes do sistema.
Uma forma conveniente de analisar isso é visualizar o fluxo
de controle em termos de threads de controle. Uma thread de
controle é um entidade capaz de realizar, de modo independen-
te, computações e esperar pela ocorrência de eventos. Assim,
thread de controle é um termo mais genérico que pode ser usado
para designar, por exemplo, processos e processos leves.
Comunicação
• Comunicação através de estado compartilhado – a comunicação
entre componentes pode depender do estado compartilhado
ou evento (uma transferência de informação que ocorre num
tempo discreto através, por exemplo, de uma mensagem ou
chamada de procedimento). A comunicação através de vari-
áveis de estado compartilhadas é muito diferente porque o
recebedor do evento não precisa usar a informação na mesma
ordem na qual ela foi enviada. Essa solução é apropriada para
guiar os dispositivos que exibem estados persistentes. Por
outro lado, se não há uma caracterização de estados, então a
comunicação baseada em eventos é mais adequada. Entretanto,
deve-se observar que os sistemas baseados em estado são mais
simples do que os sistemas baseados em eventos, embora sejam
menos eficientes. Já um sistema híbrido, combinando eventos
com estados compartilhados, oferece um desempenho melhor
ao custo de complexidade maior. Uma grande desvantagem da
comunicação baseada em estado é que ela exige acesso eficiente
à memória compartilhada (o qual pode não ser disponível em
sistemas de multiprocessamento).
• Comunicação baseada em eventos – esse mecanismo de comu-
nicação requer a passagem de eventos entre componentes. Na
comunicação com uma única thread de controle, há duas alter-
nativas: chamada direta de procedimento e chamada indireta
de procedimento. As chamadas indiretas de procedimento
oferecem separação desejável entre os componentes. Além
disso, caso a linguagem de programação suporte chamadas
indiretas, então essa solução é mais apropriada visto que ela
possui menor tempo de execução. Por outro lado, se a comu-
nicação ocorrer entre threads de controle, então existem duas
alternativas: mensagens assíncronas e mensagens síncronas.
Mensagens assíncronas têm a vantagem de reduzir problemas
de sincronização. Já as mensagens síncronas possuem semân-
tica mais simples e podem ser implementadas mais facilmente.
Para os propósitos de sistemas interativos, a solução mais
adequada é utilizar mensagens assíncronas.
• Mecanismo de fluxo de controle – refere-se à thread de controle.
Dentre as formas de oferecem a noção de thread de controle,
tem-se: processos, processos leves, tratadores de eventos e ro-
tinas de serviço de interrupções. As três primeiras formas são
mais comumente usadas. Os processos podem ser utilizados
em ambientes de rede onde pode ser útil colocar processos em
máquinas distintas. Entretanto, especificamente para sistemas
Edição 22 - Engenharia de Software Magazine 43
interativos, o uso de processos leves é a solução mais apropria-
da. Agora, se nenhuma dessas situações ocorre e as limitações
de tempo de resposta são aceitáveis, então os tratadores de
eventos podem ser uma opção.
Fluxo de Controle e Sincronização
• Fluxo de controle da aplicação – refere-se à forma na qual se dá
o processamento de entrada no fluxo de controle da aplicação.
Existem dois tipos: (i) ponto de entrada único, onde o sistema
possui um laço de eventos que constitui o único ponto no qual
qualquer entrada do usuário é aceito, e (ii) múltiplos pontos de
entrada, onde a entrada é aceita em múltiplos pontos do fluxo
de controle da aplicação. O primeiro tipo é a solução mais
apropriada uma vez que permite desacoplar o componente
de aplicação de detalhes do sequenciamento da interface com
usuário. Além disso, suporta requisito de portabilidade da
aplicação.
• Número de threads de controle – como o próprio nome designa,
está relacionado à quantidade de threads de controle. Uma so-
lução adequada em sistemas simples, onde há um único ponto
de entrada, é utilizar apenas uma única thread. Entretanto, se
há o requisito de desacoplar o fluxo de controle da interface
com usuário da aplicação, então a alternativa mais apropriada
é utilizar uma thread para interface com usuário e uma thread para
aplicação. Duas threads são suficientes para permitir que as
operações da interface com usuário possam ser executadas
concorrentemente com a aplicação. Isso permite que ações
do usuário sejam processadas e telas com resposta sejam
atualizadas enquanto comandos estão sendo processados.
Além disso, eventos externos podem ser tratados sem que
haja interrupção na resposta da interface. O resultado é que o
componente de aplicação fica mais independente do sequen-
ciamento de eventos da interface com usuário. Uma outra
alternativa é dispor de múltiplas threads de interface com usuário,
pois isto simplificaria o tratamento de interações paralelas
logicamente independentes, quando múltiplos dispositivos
de entrada são utilizados. Uma quarta solução é usar múltiplas
threads de aplicação. Esse tipo de solução seria apropriado para
tratar múltiplos eventos externos.
• Tratamento de entradas assíncronas – a interface com usuário
deve dispor de algum mecanismo para tratar eventos de en-
trada assíncronos, ou seja, eventos que ocorrem enquanto a
aplicação está fazendo alguma computação. Se os eventos não
permanecerem numa fila longa, a solução mais adequada é
enfileirar os eventos antes de efetuar o processamento. Entretanto,
se a execução de comandos tomam um longo período, então
essa solução não seria apropriada, pois a falta de resposta do
sistema compromete sua usabilidade. Outra solução que ofe-
rece mais flexibilidade é fazer o processamento parcial junto com
enfileiramento. Essa solução, contudo, requer múltiplas threads
de controle e preocupações com a sincronização.
• Granulosidade de comunicação da aplicação - refere-se à fre-
quência na qual se dá a comunicação entre a aplicação e
componente da interface com usuário. Se a frequência de
comunicação é de uma vez a cada comando completo, sendo
44 Engenharia de Software Magazine - Arquitetura de Software
a aplicação desacoplada de ações de usuários e geração de fee-
dback, então se tem que a granulosidade é grossa. Essa solução
é apropriada se a aplicação possui comandos com longo tempo
de execução ou precisa lidar com eventos externos. Agora,
se a aplicação é fortemente acoplada às ações de usuários e,
também, participa na geração de resposta ou feedback, tem-se
que a granulosidade é fina. Essa segunda solução é adequada
em interfaces de manipulação direta. Note que nessa opção
os custos de comunicação e portabilidade da aplicação ficam
comprometidos. Assim, essa solução não deveria ser adotada
a menos que estritamente necessária.
Desenvolvimento do Projeto Arquitetural
A Figura 2 ilustra o contexto no qual se dá o desenvolvimento
do projeto arquitetural. Um conjunto de elementos, tais como
requisitos arquiteturais, cenários de uso e estilos arquiteturais,
fornecem informações que objetivam subsidiar o projeto arqui-
tetural de um sistema. Isso é mostrado na Figura 1.
Inicialmente, é feita a suposição que dispomos de uma lista
de requisitos arquiteturais e um conjunto de funcionalidades
derivadas dos requisitos funcionais. Note que as dimensões
de projeto (ou características do sistema) servem de suporte
à identificação desses requisitos. A meta desse passo inicial
é identificar um conjunto de subsistema e/ou componentes
candidatos a serem usados na arquitetura do sistema. Todas
as funcionalidades derivadas dos requisitos funcionais são
vislumbrados como subsistemas. Outros possíveis subsistemas
são derivados dos requisitos arquiteturais.
Para cada requisito arquitetural, enumeram-se as possíveis
alternativas arquiteturais que satisfazem àquele requisito. Para
tanto, o arquiteto pode desenvolver regras de projeto para a
classe de sistemas que pretende desenvolver. Considere, por
exemplo, que um requisito arquitetural seja possibilitar a mu-
dança de sistema operacional. Uma solução para atender esse
requisito é dispor de um adaptador de sistema operacional. É
importante observar que os requisitos arquiteturais podem ter,
possivelmente, múltiplas soluções, ao passo que outros podem
possuir apenas uma. Essa enumeração é fruto de considerar os
estilos arquiteturais existentes, padrões de projeto bem, como
a experiência do arquiteto.
Com a lista de alternativas de solução em mãos, o arquiteto
de software pode minimizar a lista de soluções existentes,
selecionando aquelas que satisfazem os requisitos de forma
consistente. Essa seleção pode fazer uso de regras de projeto.
Perceba que, uma vez o arquiteto disponha de um conjunto
de regras de projeto para uma categoria de sistema, essas
podem ser reutilizadas em novos desenvolvimentos. Deve-se
procurar reduzir o número de opções de modo a resultar num
número menor de componentes, o que exigirá menor esforço
de implementação e manutenção. Cada opção selecionada é
adicionada à lista de subsistemas candidatos.
O passo seguinte é escolher os subsistemas. Cada candidato a
subsistema será classificado como um subsistema real podendo
aglutinar componentes e sendo incorporado à arquitetura do
sistema.

Assim, uma vez que o conjunto de subsistemas seja obtido,
o próximo passo é verificar a estrutura de concorrência. Essa
estrutura pode ser obtida analisando a necessidade de distri-
buição e paralelismo. Cada subsistema pode ser distribuído
em vários nós físicos. Nesse caso, uma unidade de distribuição
pode acomodar os componentes pertencentes a um subsistema.
Além disso, unidades de paralelismo podem ser identificadas
analisando as threads existentes, bem como a necessidade de
sincronização dessas threads.
Ao final do projeto, os subsistemas e os relacionamentos
existentes terão sido identificados. Há então um passo de vali-
dação, bem como refinamento dos subsistemas. A estrutura de
concorrência é novamente analisada. Esse passo de validação
pode requerer que as etapas iniciais sejam repetidas. Note
que o projeto arquitetural é altamente interativo, conforme
ilustra Figura 1.
Durante a validação da arquitetura do sistema de software,
cenários de qualidade são utilizados como mecanismo de va-
lidação. A arquitetura proposta é examinada, buscando checar
se os cenários de uso são realizáveis a nível de projeto. Se a
arquitetura atende aos cenários, o processo de refinamento
prossegue. Caso contrário, a arquitetura proposta é reconsi-
derada a fim de checar em qual subsistema e/ou conexão entre
subsistemas os cenários de qualidade não são alcançados.
É importante observar que durante a atividade de projeto,
são feitas várias análises arquiteturais a fim de validar a ar-
quitetura proposta. Nesse contexto, os cenários servem para
estruturar o processo de análise. Uma vez que a arquitetura
tenha sido obtida, é importante que avaliadores externos fa-
çam uma avaliação a fim de confirmar os resultados obtidos
durante o projeto arquitetural.
Conclusão
Arquitetura de software e, mais especificamente, decisões
de projeto arquitetural, têm grande importância no contexto
atual para desenvolvimento de sistemas de software. Essa
importância vem em parte da necessidade de prover suporte
PROJETO
a reuso, considerando tanto o aspecto econômico quanto a
produtividade, além de sua incorporação nos processos de
desenvolvimento de software. Neste artigo, foi visto que a es-
trutura global ou modelo arquitetural de sistemas de software
pode ser estudada através do uso de dimensões de projeto.
Uma dimensão de projeto identifica as opções funcionais
e arquiteturais feitas durante o projeto de um sistema e
classifica as alternativas existentes para cada escolha. Além
disso, regras podem ser formuladas, objetivando correlacio-
nar as opções existentes a uma dimensão de projeto. Esse
conjunto de regras constitui ferramenta de projeto e pode
ser empregada como orientação do projeto arquitetural.
Exemplos de regras de projeto para sistemas interativos
foram apresentados.
Links
História da Indústria de Software
www.softwarehistory.org
An introduction to software architecture
http://www.cs.cmu.edu/afs/cs/project/able/www/paper_abstracts/intro_softarch.html
SEI’s Software Architecture Technology Initiative
www.sei.cmu.edu/architecture/sat_init.html
Worldwide Institute of Software Architects
www.wwisa.org/wwisamain/index.htm
The Software Architecture Portal
http://www.softwarearchitectureportal.org/
SEI’s Software Architecture Technology Initiative
www.sei.cmu.edu/architecture/sat_init.html
Dê seu feedback sobre esta edição! Feedback
eu
s
Dê
A Engenharia de Software Magazine tem que ser feita ao seu gosto.
sobre e
Para isso, precisamos saber o que você, leitor, acha da revista!
s
ta
Dê seu voto sobre este artigo, através do link:
edição
www.devmedia.com.br/esmag/feedback
Edição 22 - Engenharia de Software Magazine 45
Abordagens Tradicionais de Desenvolvimento
Esta seção traz artigos que apresentam como e quando utilizar as diferentes abordagens
tradicionais de apoio ao desenvolvimento de projetos de software
Experiências da Domínio Informática na
Implantação do MPS.BR
Ticiana da Mota Gentil Parente
ticianagentil@yahoo.com.br
Bacharel em Economia pela Universidade Federal
do Ceará, pós-graduada em Processamento de
Dados pela Universidade de Fortaleza - UNI-
FOR, participou dos seguintes cursos: Curso de
Gerenciamento de Projetos baseado no PMBOK,
Curso Oficial de Introdução ao MPS.BR e Curso de
Auditoria da Qualidade ISO 9001:2000. Foi coor-
denadora do projeto de implantação do MPS.BR
na Domínio Informática, bem como, responsável
pela implantação da fábrica de software e res-
ponsável pela inclusão no escopo da ISO do item
referente a desenvolvimento de sistemas e fábrica
de software na Domínio Informática. Atualmente
trabalha na Secretaria do Planejamento e Gestão
do Governo do Estado do Ceará na Coordenadoria
de Gestão Estratégica de TIC.
Adriano Bessa Albuquerque
adriano.ba@terra.com.br
Doutor em Engenharia de Sistemas e Computa-
ção pela Universidade Federal do Rio de Janeiro
(2008). Atualmente é professor do Mestrado em
Informática Aplicada da Universidade de Forta-
leza, estando envolvido com a linha de pesquisa
de Engenharia de Software. Atua principalmente
nos seguintes temas: qualidade de software,
avaliação e melhoria de processos de software,
métricas, normas iso e modelos de maturidade
de software, sendo, também, implementador e
avaliador oficial dos modelos de maturidade de
software: CMMI e MPS.BR.
46 Engenharia de Software Magazine - Experiências da Domínio Informática na Implantação do MPS.BR
A
Domínio Informática é uma
empresa especializada em Ter-
ceirização de Tecnologia da In-
formação e Comunicação e mão-de-obra
especializada para todos os segmentos
de informática como: Desenvolvimento
de Sistemas, Suporte Técnico, Consul-
toria e Treinamento. É uma empresa
full service, ou seja, fornece aos seus
clientes infra-estrutura completa de su-
porte, manutenção e acompanhamento
de serviços e produtos.
Em 1998, a Domínio iniciou o de-
senvolvimento de uma metodologia
de trabalho própria, tendo sempre a
preocupação de adequar seus serviços
às reais demandas dos clientes. Em
1999, obteve a certificação ISO 9001 em
De que se trata o artigo?
Este artigo relata a experiência da Domínio In-
formática com a definição e implementação dos
seus processos de desenvolvimento de software,
aderentes ao modelo de maturidade MPS.BR.
Para tanto, discorre sobre a estratégia usada, as
ações necessárias para se alcançar estes objeti-
vos, os aprendizados obtidos, suas dificuldades,
fatores de sucesso e os benefícios iniciais a partir
desta experiência.
Para que serve?
Este artigo é importante para que outras empresas
possam conhecer as dificuldades enfrentadas pela
Domínio Informática para conseguir dois níveis de
maturidade do MPS.BR, bem como os fatores de su-
cesso de tal empreitada.
Em que situação o tema é útil?
O tema é útil, tendo em vista estar crescendo
a procura das empresas brasileiras pelas ava-
liações MPS.BR.
desenvolvimento de sistemas, recruta-
mento e seleção de pessoal especiali-
zado, e projetos de comércio eletrônico

na Internet. A certificação foi feita pelo BVQI (Bureau Veritas
Quality International), que tem reconhecimento do INMETRO
(Instituto Nacional de Metrologia, Normalização e Qualidade
Industrial) e ANSI/RAB (American National Standards Ins-
titute/Registrar Accreditation Board). A partir de 2006, as re-
certificações passaram a ser realizadas pelo BRTÜV, organismo
certificador, credenciado também pelo INMETRO.
No final do primeiro semestre de 2007, a empresa contratou
a Universidade de Fortaleza - UNIFOR como instituição im-
plementadora, no intuito de orientá-la e ajudá-la na definição
e implementação dos processos do nível G e F do MPS.BR -
Melhoria de Processo do Software Brasileiro (SOFTEX, 2007).
Como resultado inicial deste trabalho, em fevereiro de 2008, a
empresa foi avaliada com sucesso no nível G, tendo como uni-
dades organizacionais avaliadas o setor de desenvolvimento
da própria Domínio Informática e o site do Departamento de
Edificações e Rodovias do Estado do Ceará (DER-CE), cliente
da empresa. Em relação ao nível F, em setembro de 2008, houve
a avaliação inicial da Fábrica de Software da Domínio, tendo
sua avaliação final prevista para Outubro de 2008.
O fato de a empresa ter optado por obter as avaliações do
nível G e do nível F no mesmo ano, com um intervalo de apenas
seis meses, exigiu um alto investimento, além de uma grande
dedicação e tempo dos profissionais.
A Fábrica de Software, que é um conjunto de recursos hu-
manos e materiais, processos e metodologias estruturadas,
de forma semelhante às indústrias tradicionais, utiliza-se
das melhores práticas para o processo de desenvolvimento,
teste e manutenção dos softwares. Além disso, utiliza em sua
operação, indicadores de qualidade e produtividade em cada
etapa do ciclo de desenvolvimento de software, bem como
busca maximizar a reutilização de componentes anteriormente
desenvolvidos.
A qualidade dos produtos e serviços da Fábrica de Soluções de
Software da Domínio Informática é baseada no modelo MPS.
BR (SOFTEX, 2007), no processo interno de desenvolvimento
de sistemas certificado pela ISO desde 1999, bem como no
PMBOK (PMI, 2004).
Estratégia Utilizada
Como diferencial competitivo, a Domínio procurou iden-
tificar uma metodologia que otimizasse seus processos de
trabalho, objetivando melhorar a qualidade de seus produtos
e serviços, aumentar a competitividade e reduzir custo. Desta
forma, identificou no MPS.BR (SOFTEX, 2007) a melhor opção,
visto o atual reconhecimento nacional deste modelo de matu-
ridade, a possibilidade de um menor investimento e a empresa
ter sua atuação ainda restrita ao mercado interno.
Assim, contratou uma instituição implementadora que
pudesse auxiliá-la nesta mudança e iniciou o processo de
capacitação do seu quadro técnico.
Inicialmente, a Universidade de Fortaleza (UNIFOR) realizou
um diagnóstico da situação atual da empresa, para que pudesse
definir de uma forma mais rápida e eficaz o quanto os processos
da Domínio estavam aderentes ao MPS.BR (SOFTEX, 2007).
processo
Como a empresa também faz terceirização, decidiu-se imple-
mentar os processos também em um cliente, o Departamento
de Edificações e Rodovias do Estado do Ceará (DER-CE). Lá, a
empresa é responsável por todo o desenvolvimento e manutenção
de sistemas, possibilitando grande autonomia nos processos da
área terceirizada. Esta decisão teve como objetivo disseminar o
conhecimento e buscar uma maior qualidade em seus serviços.
Ações Necessárias
Outros fatores que também motivaram a empresa a imple-
mentar o MPS.BR (SOFTEX, 2007) foram: a expectativa de redu-
ção do retrabalho, o aumento da produtividade, a redução do
tempo de entrega do produto, a otimização da previsibilidade
e o aumento da satisfação do cliente (VARKOI, 2002).
Para o que a empresa se propunha em termos da melhoria
continua dos seus processos foi necessário:
• Disponibilizar recursos suficientes (HEFNER e TAUSER,
2001, DYBA, 2003), visto que o sucesso de um Programa de
Melhoria depende do investimento em pessoal, em ferramentas
de apoio e do apoio de consultorias especializadas.
• Analisar freqüentemente, o retorno do investimento (ROI)
com as melhorias dos processos de software e torná-las visíveis
(ERDOGMUS et al., 2004). Com isto, a organização se motiva
e diminui o risco de parar o processo de melhoria contínua,
visto que percebe os ganhos obtidos e que estão influenciando
positivamente os seus negócios.
• Adaptar o Programa de Melhoria às características da organiza-
ção (HEFNER e TAUSER, 2001, DYBA, 2003), visto que a eficiência
e aderência aos processos dependem do quão os processos estão
em sintonia com a cultura organizacional da empresa.
• Existir, por parte da empresa, uma visão e compromisso de
longo prazo com o investimento em melhoria (VARKOI, 2002),
de forma que as dificuldades enfrentadas e os prazos de cada
passo rumo à melhoria contínua dos processos, que nem sem-
pre são curtos, não venham desmotivar a organização.
• Existir uma alta gerência comprometida e que forneça o
devido suporte (DYBA, 2003, BASILI et al., 2002), visto que o
início e continuidade do Programa de Melhoria depende dos
recursos disponibilizados pelos dirigentes da organização.
• Definir uma baseline dos resultados do Programa de Melho-
ria desde o seu início (BASILI et al., 2002), para que a empresa
não perca a noção do quanto a melhoria dos processos está
sendo benéfica para a organização e seus negócios.
• Ajustar os objetivos de melhoria aos objetivos de negócio da
organização (HEFNER e TAUSER, 2001). Com isto, espera-se
que o foco do Programa de Melhoria seja o crescimento dos
negócios da empresa e que a melhoria dos processos não se
torne uma iniciativa à parte e desvinculada das outras áreas
da organização.
• Considerar não apenas os fatores técnicos da organização
(HEFNER e TAUSER, 2001, DYBA, 2003). É importante ana-
lisar fatores relacionados à cultura da empresa, bem como
à sua estrutura organizacional, pois alguns destes fatores
podem inviabilizar o início e a continuidade do Programa de
Melhoria.
Edição 22 - Engenharia de Software Magazine 47
• Ter o envolvimento de todos os colaboradores (DYBA,
2003), já que são eles que irão executar os processos
implementados.
• Investir em melhoria de pessoal (contratação, melhoria de
habilidades, ambientes de trabalho, entre outras) em para-
lelo ao Programa de Melhoria (BASILI et al., 2002). Talvez,
este deve ser o maior orientador de qualquer Programa de
Melhoria, visto que a qualidade do pessoal da empresa é
o principal diferencial na definição e execução dos proces-
sos, ou seja, a maturidade dos processos da empresa está
diretamente relacionada à maturidade dos colaboradores
da organização.
• Aproveitar conhecimentos já existentes na organização
(DYBA, 2003), para que a empresa não parta da estaca zero e
os processos definidos sejam mais adequados à organização
e possam ser executados de maneira mais aderente.
• Ser apoiado por um ambiente ou abordagens de gestão de
conhecimento (SCHNEIDER e VON HUNNIUS, 2003). Dessa
forma a organização poderá implementar melhorias mais
úteis às necessidades dos processos e além disso, a partir
do reuso de conhecimentos, agilizar a implementação e
execução dos processos.

Além destes fatores de sucesso, a empresa, juntamente

com a consultoria, buscou definir claramente as responsa-
bilidades dos envolvidos no processo, bem como garantir
um bom nível de usabilidade da definição dos processos,
selecionando o tipo de representação mais adequada
(MENDONÇA, 2006). Para isto, utilizou a ferramenta
EPF Composer, que permite uma eficaz representação
gráfica dos processos, descrição das atividades, tarefas
e passos, bem como a definição dos papéis responsá-
veis por cada tarefa, conforme apresentado na Figura 1.
Esta ferramenta é também um repositório dos templates que
devem ser utilizados durante a execução dos processos.
Além disso, foram definidos os artefatos de entrada e saída
para cada tarefa, os quais fossem de fácil utilização (com
informações claras, com diretrizes de preenchimento, com
seções bem distribuídas) e ao mesmo tempo aderentes ao
MPS.BR (SOFTEX, 2007).
A organização e a consultoria definiram os métodos e técnicas
que poderiam apoiar de maneira mais adequada os processos,
como por exemplo, a utilização de Pontos de Casos de Uso para
estimar o esforço dos projetos. Foram definidas também as ferra-
mentas que melhor poderiam apoiar a execução dos processos.
Finalmente, no início da implantação do Programa de Me-
lhoria na empresa, foram realizados treinamentos e principal-
mente reuniões com os colaboradores, para sensibilizá-los em
relação: (i) à importância de iniciativas de melhoria contínua de
processos para uma organização, (ii) à relevância de executar
os processos de forma aderente e (iii) à importância para a
vida profissional de cada um dos colaboradores, por estarem
participando de um Programa de Melhoria, tendo em vista
que aumentaria seu nível de conhecimento em Engenharia
de Software e sua empregabilidade.
Figura 1. Processo representado no EPF Composer
Aprendizados e Ajustes
Na fase de implementação dos processos, o aprendizado teó-
rico unido à prática, quando do início do desenvolvimento dos
projetos, propiciou um maior grau de maturidade, não apenas
da equipe, mas de toda a empresa, uma vez que efetivamente
houve uma maior e melhor gestão nos seus projetos.
Inicialmente, foram realizados treinamentos para que hou-
vesse um “nivelamento” do conhecimento entre a equipe
de trabalho e possibilitasse um maior senso crítico durante
a etapa de definição dos processos de Gerência de Projetos
e Gerência de Requisitos (nível G do MPS.BR). Em seguida,
após várias reuniões para definir os processos e os respecti-
vos templates, estes foram divulgados e institucionalizados
na organização.
Em paralelo a isso, para facilitar a implementação dos pro-
cessos, a Domínio deu início ao desenvolvimento de uma
ferramenta que pudesse apoiar o processo de Gerência de
Projetos e de Requisitos, funcionando como um workflow.
Porém, com a implementação dos novos processos do nível F,
mais especificamente, da Gerência de Configuração, em que
passou a utilizar a ferramenta Team Foundation, esta idéia foi
abandonada, visto que esta ferramenta permite que o método
de trabalho fique mais claro, permitindo, assim, um maior e
melhor entendimento do processo, bem como um repositório
único de dados. Além disso, a ferramenta veio apoiar de forma

48 Engenharia de Software Magazine - Experiências da Domínio Informática na Implantação do MPS.BR


significativa também a Gerência de Projetos e Garantia da Qua-
lidade, uma vez que se instituiu na empresa a cultura do uso
de tarefas (tasks), em que se identifica o responsável, projeto e
situação da mesma, permitindo um maior controle destas.
Principais Dificuldades
No início, até por falta de um maior grau de maturidade,
a empresa passou por um momento de adequação, havendo
“certa” resistência, por considerar algumas etapas muito
burocráticas.
No decorrer dos trabalhos, percebeu-se que se poderia ter um
maior controle e conseqüentemente uma melhor gestão dos
projetos. Porém, era necessário um trabalho em conjunto em
que ocorressem reuniões de analises críticas que permitissem
revisões e identificação de melhorias.
Atrelado a isso, como o ser humano tem uma resistência
natural à mudança, o que dificulta a implantação de um novo
processo de trabalho, uma vez que isso implica na saída de
uma zona de conforto, já totalmente conhecida, para uma
nova, as quais muitas vezes expõem as pessoas a um desafio,
que nem sempre elas estão preparadas, alguns colaboradores
se colocaram, muitas vezes, contra a execução de algumas
tarefas e utilização de alguns métodos e técnicas.
Uma outra dificuldade enfrentada foi com a implantação do
novo processo de trabalho, o qual gera novas atribuições para
do dia a dia, sem que as tarefas em andamento possam ser
colocadas em stand by. Desta forma, conciliar o que deveria
ser feito na rotina diária e ao mesmo tempo executar novas
tarefas dos processos implementados foi um esforço árduo,
que exigiu uma determinação muito grande dos colaboradores
para mudar.
Em relação a esta dificuldade, as iniciativas para motivar
os envolvidos de forma que conseguíssemos torná-los uma
verdadeira equipe de trabalho foi fundamental.
Assim, viabilizar treinamentos, analisar casos de sucesso,
realizar reuniões de analises críticas, ver as tendências merca-
dológicas, identificar oportunidades de negócio para empresa,
foram algumas das ações que motivaram a equipe.
Outra grande dificuldade enfrentada pela empresa foi definir
os processos de forma que, quando executados, preservassem a
agilidade das entregas aos clientes e, ao mesmo tempo, atendes-
sem aos resultados esperados do MPS.BR (SOFTEX, 2007).
Nesse momento, ficou clara a importância de uma consulto-
ria, onde os implementadores já tivessem tido oportunidades
de participar de avaliações MPS.BR e conhecessem a realidade
e os processos de outras empresas (Benchmark). Percebeu-se
que uma orientação bem qualificada facilita a definição de
processos mais adequados aos objetivos de negócio da empresa
e mais aderentes ao modelo de maturidade.
Fatores de Sucesso
No caso da Domínio Informática, podemos definir os se-
guintes fatores de sucesso: (i) ter contratado uma consultoria,
(ii) tratar o Programa de Melhoria como um projeto, onde as
fases são bem definidas e é realizado um acompanhamento
processo
rigoroso, (iii) sensibilizar os envolvidos em relação aos bene-
fícios do Programa de Melhoria, (iv) disseminar a cultura de
processos na empresa, (v) existir um colaborador dedicado
para desenvolver as iniciativas de melhoria de processos na
organização e, principalmente, (vi) contar com um forte apoio
da alta direção (patrocinador do Programa de Melhoria).
Como o custo de implementação e avaliação de processos é
alto e o prazo para se enxergar os benefícios obtidos é longo, se
a alta direção não der o devido respaldo, e se não existir uma
boa coordenação do projeto de implementação dos processos
aderentes ao modelo MPS.BR (SOFTEX, 2007), poderá ocasionar
um aumento do custo de implementação e até mesmo compro-
meter o sucesso e a continuidade do Programa de Melhoria.
Como fator de sucesso, vale ressaltar ainda, a estratégia de
realizar uma avaliação informal na Domínio Informática,
antes da avaliação inicial do MPS.BR em todos os seus níveis,
de forma que a empresa pudesse conhecer a atual realidade
dos seus processos em relação aos resultados esperados e
atributos de processos definidos pelo modelo. Esta avaliação
foi realizada por uma avaliadora adjunta oficial do MPS.BR e
que não tinha participado da implementação dos processos
na empresa.
Benefícios Alcançados
Vários foram os benefícios obtidos com a implantação dos
processos, porém, vale destacar o aumento do grau de matu-
ridade dos profissionais da empresa, bem como o rigor com
que os projetos passaram a ser gerenciados. Atualmente, não
há dúvidas do que deve ser feito, quando e por quem. Isso
por si só, já representa uma grande vantagem competitiva da
organização.
Além disso, podemos citar a institucionalização dos proces-
sos, deixando-os cada vez menos pessoais, uma vez que todos
sabem que passos devem ser seguidos. A visão de começo,
meio e fim de um processo é facilmente entendida e visualizada
através do que foi definido.
Como os softwares passaram a ser extremamente bem docu-
mentados, isto propiciou uma maior e melhor continuidade dos
serviços, visto que mesmo com a mudança de um profissional
no projeto, outro que entenda a forma de trabalho e que tenha
acesso à documentação poderá dar continuidade ao mesmo
com maior facilidade, permitindo assim um aumento da pro-
dutividade e segurança do projeto.
Outro beneficio advindo da implementação do processo de
Gerência de Projetos foi a utilização de Pontos de Casos de
Uso para estimar o esforço necessário dos projetos. Com isto, a
empresa vem melhorando o nível de previsibilidade do esforço
dos seus projetos e conseqüentemente, dos custos envolvidos,
embora ainda não considere que tenha uma calibração ade-
quada, visto o número de projetos, os quais utilizaram esta
técnica. Porém, considerando ser um método universal, e com
a nova prática que será adotada na conclusão dos projetos em
andamento, em que será feita uma comparação do que foi esti-
mado, com o efetivamente realizado, a empresa espera colher
ainda mais frutos. A comparação entre os resultados obtidos
Edição 22 - Engenharia de Software Magazine 49
com Pontos de Caso de Uso e com o método utilizado ante-
riormente não foi realizada, uma vez que não tínhamos uma
base histórica confiável. Além disso, com esta nova forma de
estimar, de planejar e de monitorar seus projetos, a organização
passou a ter uma maior visão da sua lucratividade.
Outro ponto importante a se destacar com a implantação
dos processos foi a utilização de abordagens de captura de
conhecimentos a fim de que pudessem ser reutilizados, au-
mentando, assim, a produtividade dos projetos da organização.
Um exemplo disto foi a realização das avaliações post-mortem
no final dos projetos, que permitiram identificar pontos fortes
e fracos e, a partir de sua análise, propor melhorias para os
processos.
Conclusão
A empresa entende a melhoria contínua dos processos
como uma iniciativa sem volta e de grande valor agregado
ao negócio.
Dando continuidade ao Programa de Melhoria, a empresa
tem a intenção de ser avaliada no nível E. Indo mais além ainda,
neste período, a organização entende que pode adquirir mais
maturidade, bem como explorar um nicho de mercado interna-
cional, que irá exigir uma certificação CMMI. Assim, somente
após galgar para o nível E, a empresa tem como estratégia se
capacitar e solicitar uma avaliação CMMI nível 3.
Adicionalmente, com a implementação dos processos, os
projetos passaram a ser melhor gerenciados, permitindo uma
maior qualidade dos produtos e serviços. Com isso, a empresa
pôde se destacar diante de outras empresas ao implementar
processos também no seu cliente, DER-CE, propiciando, desta
forma, um grande diferencial, visto que a terceirização passou
a não ser uma mera mobilização de mão-de-obra. A Domínio
Informática passou a oferecer aos seus clientes um processo de
desenvolvimento aderente ao MPS.BR e disponibilizar profis-
sionais capacitados em engenharia de software, sem nenhum
custo adicional aos seus contratos, possibilitando, dessa forma,
o desenvolvimento de um produto e uma prestação de serviço
com melhor qualidade.
Assim, não é apenas a empresa que se beneficia quando
implementa a metodologia e obtém sucesso em uma avalia-
ção que comprove o uso efetivo da mesma, mas também seus
clientes, profissionais e o próprio mercado. A empresa, pelo
50 Engenharia de Software Magazine - Experiências da Domínio Informática na Implantação do MPS.BR
conhecimento e pela maior e melhor gestão de seus negócios.
O cliente, por ter uma ferramenta de trabalho implantada em
sua organização sem custo adicional ao seu contrato. O pro-
fissional, por conseguir um maior grau de maturidade e em-
pregabilidade. E o mercado, por dispor de empresas com uma
maior capacitação em gestão e qualidade de software.
Referências
BASILI, V. et al., 2002,“Lessons learned from 25 years of process improvement: The Rise and Fall
of the NASA Software Engineering Laboratory”, In: Proceedings of International Conference on
Software Engineering (ICSE 2002), pp. 69-79, Orlando.
DYBA, T., 2003, “Factors of Software Process Improvement Success in Small Organizations: An
Empirical Study in the Scandinavian Context”, In: Proceedings of the Software Engineering
Conference and ACM SIGSOFT Symposium on the Foundations of Software Engineering (ESEC/
FSE’03), pp. 148-157, Helsinki.
ERDOGMUS, H. et al., 2004,“Return on Investment”, IEEE Software, pp. 18-22, May/June 2004.
HEFNER, R., TAUSER, J., 2001,“Things They Never Taught You in CMM School”, In: Proceedings of
the 26th Annual NASA Goddard Software Engineering Workshop, pp. 27-29, November.
MENDONÇA, R. M. L. O., 2006, “Usabilidade de Processos”, In: Anais do II Workshop “Um Olhar
Sociotécnico sobre a Engenharia de Software” (WOSES), pp. 13-26, Vila Velha, Junho.
PMI - Project Management Institute, 2004, “PMBOK A guide to Project Management Body of
Knowledge”. 3ª ed. Pennsylvania: PMI – Project Management Institute Inc.
SCHNEIDER, K., VON HUNNIUS, J-P., 2003, “Effective Experience Repositories for Software
Engineering”, In: Proceedings of the International Conference on Software Engineering
(ICSE’03), pp. 534-539, Portland, May.
SOFTEX, 2007, Melhoria de Processo de Software Brasileiro - Guia Geral versão 1.2, disponível
em: http://www.softex.br/mpsbr, acessado em: 08/10/2007.
VARKOI,T., 2002,“Management of Continuous Software Process Improvement”,In: Proceedings of the
International Engineering Management Conference (IEMC ‘02), pp. 334-337, Cambridge, August.
Dê seu feedback sobre esta edição! Feedback
s eu
Dê
A Engenharia de Software Magazine tem que ser feita ao seu gosto.
sobre e
Para isso, precisamos saber o que você, leitor, acha da revista! ta s
edição
Dê seu voto sobre este artigo, através do link:
www.devmedia.com.br/esmag/feedback
 processo

Edição 22 - Engenharia de Software Magazine 51

Validação, Verificação e Teste
Esta seção traz artigos que apresentam como e quando utilizar as diferentes abordagens
de VV&T no apoio ao desenvolvimento de projetos de software

Gerenciamento de Defeitos em Projetos de

Software
Introdução à Ferramenta BugZilla
De que se trata o artigo? com qualidade e a relação do controle e identificação
Jenifer Vieira Toledo de bugs na busca por qualidade.
Gestão de bugs de software com a utilização da
jenifer@jenifer.eti.br
É graduada em Ciência da Computação pela ferramenta BugZilla. O artigo apresenta a utilização
Faculdade Governador Ozanam Coelho (FAGOC), da ferramenta para rastrear defeitos, desde a sua Em que situação o tema é útil?
pós-graduanda em Gerência de Projetos em identificação feita pelo usuário até a sua correção. O rastreio de defeitos fornece à equipe de desenvolvi-
Engenharia de Software pelo Centro de Ensino Aspectos gerenciais da ferramenta também são mento um importante diferencial para buscar qualidade
Superior de Juiz de Fora (CES/JF) e Técnica de
apresentados, desde a instalação, configuração de em seus produtos. Esta técnica permite que os defeitos
Hosting da Optical Soluções em Informática Ltda.
um novo produto de software e a evolução do defei- sejam catalogados, desde sua identificação até sua re-
to observada pela equipe de desenvolvimento. solução. Para este fim, a ferramenta BugZilla é utilizada
Marcelo Santos Daibert para controlar e automatizar o processo de rastreio dos
marcelo@daibert.pro
Twitter: @MSDaibert Para que serve? defeitos, o que diminui o tempo de resposta para a cor-
É professor e coordenador do Curso de Ba- Fornecer conhecimentos para verificar, na prática e reção, deixando o processo de verificação de bugs mais
charelado em Ciência da Computação da FA- de forma organizada, bugs de software rastreados organizado, aumentando assim a qualidade do produto
GOC - Faculdade Governador Ozanam Coelho, pela ferramenta BugZilla. Estabelecer uma visão crí- de software e satisfação dos usuários, auxiliando a orga-
Mestrando e Especialista em Ciência da Com-
tica sobre a necessidade de se desenvolver software nizar a fase de manutenção de software.
putação pela Universidade Federal de Viçosa,
Bacharel em Sistemas de Informação pela Fa-
culdade Metodista Granbery e Gerente Técnico
da Optical Soluções em Informática Ltda.

Marco Antônio Pereira Araújo
maraujo@acessa.com
Doutor e Mestre em Engenharia de Sistemas
e Computação pela COPPE/UFRJ, Especialista
em Métodos Estatísticos Computacionais e
Bacharel em Matemática com Habilitação em
Informática pela UFJF, Professor dos cursos de
Bacharelado em Sistemas de Informação do
Centro de Ensino Superior de Juiz de Fora e
da Faculdade Metodista Granbery, Analista de
Sistemas da Prefeitura de Juiz de Fora e Editor
da Engenharia de Software Magazine.
U
m dos primeiros grandes mar-
cos da história da qualidade foi
a revolução industrial, iniciada
em meados do século XVIII, quando
houve um grande crescimento no núme-
ro de indústrias substituindo o processo
de fabricação manual pelo industrial.
Esse processo permitiu a criação de
produtos iguais, já que no processo ma-
nual manter este padrão nem sempre era
possível. Com os avanços tecnológicos
e culturais, motivados pelo fenômeno
da revolução industrial, houve a ne-
cessidade da criação de produtos com
algum diferencial, já que nascia ali a
concorrência entre empresas, serviços
e produtos. Muitas empresas buscaram
então aprimorar seus métodos de produ-
ção, para que minimizassem as despesas
e maximizassem os lucros. Nascia ali
um conceito hoje chamado de processo
de melhoria contínua de produtos. Mais

52 Engenharia de Software Magazine - Gerenciamento de Defeitos em Projetos de Software

 Validação, Verificação & Teste
tarde, a partir da década de 20, a produção industrial passou
a se preocupar mais ainda com a qualidade dos produtos,
com a finalidade de impedir que produtos com qualquer tipo
de defeito chegassem às mãos dos clientes. Nos dias atuais,
a qualidade é o grande diferencial para qualquer produto ou
serviço que uma empresa possa produzir ou oferecer.
No atual contexto de desenvolvimento de software a qua-
lidade já não é mais um fator de diferenciação no mercado,
mas sim, uma condição essencial para que as empresas e
profissionais sejam bem-sucedidos. As empresas de software
vêm buscando certificações ISO (International Organization
for Standardization) e certificações dos modelos de maturi-
dade CMMI (Capability Maturity Model Integration) e MPS.
BR (Melhoria de Processos do Software Brasileiro) como meio
de comprovar sua qualidade no processo de desenvolvimento
de software (ler Nota 1). Assim, torna-se importante a utiliza-
ção de métodos e técnicas que permitam avaliar de maneira
abrangente a qualidade dos processos e dos produtos de sof-
tware, garantindo que o usuário receba produtos dentro das
especificações definidas e esperadas por ele.
Desde o surgimento da tarefa de desenvolvimento de sof-
tware, grande parte dos recursos, seja financeiro ou esforço,
são gastos na fase de manutenção do software. Segundo
Roger Pressman, autor de um dos livros mais famosos de
Engenharia de Software, a fase de manutenção pode ser
responsável por mais de 70% de todo o esforço despendido
para a produção do software. Outros autores, e a experi-
ência de algumas empresas, taxam números semelhantes,
o que nos fazem refletir sobre a importância de padrões e
processos nas fases anteriores para minimizar esses gastos
e esforço com manutenção.
Na fase de manutenção é onde são feitas melhorias e otimi-
zação de um software já finalizado. Nessa fase são feitos os
reparos de defeitos / bugs encontrados. Segundo Pressman,
o custo da manutenção de software tem aumentado firme-
mente durante os últimos 20 anos. Durante a década de 1970,
a manutenção era responsável por um índice entre 35% e 40%
do orçamento de Software para uma organização de sistemas
de informação. Esse valor pulou para aproximadamente 60%
durante a década de 1980. O autor ainda estima que, se nada for
feito para minimizar os problemas nos software e conseqüen-
temente minimizar os custos na fase de manutenção, muitas
empresas gastarão 80% de seus orçamentos de software em
manutenção. Quanto mais eficiente for a fase de manutenção
do software, mais fácil é de mantê-lo, e por conseqüência mais
barato (seja mais barato financeiramente ou de esforço).
Estes dados não levam em consideração uma importante
parte envolvida no processo: o usuário e sua satisfação. A sa-
tisfação do usuário está diretamente ligada à funcionalidade
correta da aplicação. Um software com muitos defeitos, além
de causar prejuízos financeiros, gera insatisfação, mitigando a
possibilidade de sucesso do processo de desenvolvimento de
software. Ou seja, os custos de manutenção não se resumem
ao gasto de dinheiro e esforço, mas também em atrasos no
desenvolvimento, quebra de cronograma, insatisfação dos
clientes, redução da qualidade global do software e também
insatisfação dos funcionários / desenvolvedores (envolvidos
na tarefa de desenvolvimento).
Diante dos fatos apresentados e da dificuldade em identificar
e manter o controle sob os bugs / defeitos de um software (seja
durante o desenvolvimento do software ou após a finalização
do desenvolvimento, especialmente na fase de manutenção),
este artigo tem como objetivo apresentar conceitos relacionados
ao tema e introduzir a utilização da ferramenta BugZilla para
auxiliar nessa tarefa.
Essa ferramenta é utilizada para o controle e manutenção de
bugs em projetos de software, e permite acompanhar / ras-
trear o bug desde a sua identificação, reporte e correção. São
apresentados, durante o artigo, quais os requisitos necessários
para instalação da ferramenta, bem como o seu funcionamento
como um sistema Web. Também são apresentadas as principais
configurações e as visões de utilização do sistema sob a ótica
do administrador, usuário do software (software este cadas-
trado no sistema para receber os bugs relatados) e a equipe de
desenvolvimento.
Bugs
O primeiro bug foi citado por Thomas Edison em 1878, quan-
do um pequeno inseto identificado em seu fonógrafo causou
problemas de leitura. Nos Estados Unidos, em 1957, encon-
traram uma traça entre os circuitos do primeiro computador
digital automático de larga escala, o que causou um erro nos
cálculos da máquina. Este foi considerado o “primeiro bug”
de um computador.
Nota do DevMan 1
ISSO, CMMI, MPS.BR
ISO significa International Organization for Standardization (Organização In-
ternacional de Normalização) e seu objetivo é promover o desenvolvimento de
normas, testes e certificação, com o objetivo de padronizar e encorajar o desen-
volvimento de comércio de bens e serviços. É uma organização formada por mais
de 90 países e as normas da série ISO 9000 são as principais normas internacionais
sobre o gerenciamento e a garantia da qualidade.
O CMMI é um modelo de referência que apresenta boas práticas necessárias à
maturidade em áreas de conhecimento específicas, como, por exemplo, a enge-
nharia de software. É uma evolução do CMM (Capability Maturity Model) e procura
integrar os processos de melhoria corporativo em um único modelo, integrando
diferentes modelos e disciplinas. É dividido, de acordo com a representação contí-
nua, em níveis crescentes de maturidade, até o 5, sendo o nível 5 o mais elevado
da escala. Esses níveis de maturidade definem o grau de melhoria de processo para
um pré-determinado conjunto de processos no qual todos os resultados esperados
do processo e dos atributos dos processos são atendidos.
Assim como o CMMI, O MPS.BR é um modelo para melhoria de processo do sof-
tware brasileiro e está em desenvolvimento desde 2003. É dividido em sete níveis
de maturidade: A (em otimização), B (gerenciado quantitativamente), C (definido),
D (largamente definido), E (parcialmente definido), F (gerenciado) e G (parcialmen-
te gerenciado). A escala de maturidade se inicia no nível G e evolui até o nível A.
Edição 22 - Engenharia de Software Magazine 53
 Por conta destes episódios, até hoje, ainda são chamados de
bugs os defeitos de um software. Um defeito é considerado
um erro no funcionamento comum do programa ou uma
falha na lógica da aplicação que causa impossibilidade de
realização de uma determinada ação ou tarefa.
Um modelo de bug conhecido e que ficou muito famoso,
especialmente pelo potencial dos problemas que causaria, é
o “Bug do Milênio”, onde na virada do ano de 1999 para 2000,
devido ao armazenamento de datas com apenas 2 dígitos
para o ano, fez com que o computador entendesse que estava
no ano de “19″ + “00”, ou seja, 1900 e não no ano 2000.
Vários são os exemplos de defeitos em software que causa-
ram prejuízos. Em 4 de junho de 1996, foi lançado o primeiro
foguete Ariane e, após decorrer 40 segundos da sequência
de lançamento e a uma altitude de 3700 metros, o foguete
se desviou de sua trajetória e se autodestruiu com uma ex-
plosão. O custo desse desastre foi avaliado em mais de 300
milhões de dólares, quantia suficiente para pagar um salário
de 2,5 mil dólares a 100 programadores que trabalhassem
durante um século. As investigações sobre o acidente apon-
taram falhas no software de navegação, que causou um erro
no cálculo da velocidade horizontal do foguete.
A gravidade de uma falha de software é relativa. Existem
falhas com as quais usuários podem conviver, a tal ponto
que o sucesso de aplicação de um produto não seja afeta-
do. Entretanto há outros casos, onde a falha do programa
representa um completo fracasso comercial. Há ainda os
casos em que os bugs podem colocar em risco inclusive a
segurança física de pessoas. Um exemplo são os softwares
que controlam aviões, tão questionados nos últimos anos
por conta dos últimos acidentes / incidentes noticiados
pela mídia.
Nota-se que, apesar do relato de um defeito ser um dos prin-
cipais passos do processo de gestão de defeitos, normalmente
ele é relegado para segundo plano. O mito de software perfei-
to, sem defeitos, está longe de ser uma realidade. Se nenhum
defeito foi encontrado em um software, certamente os defeitos
não foram procurados de forma correta. Para encontrá-los e
identificá-los é preciso um método e adoção de processos
para este suporte, já que, são diversos os profissionais que
dedicam seu tempo na tarefa de encontrar defeitos em aplica-
ções dos mais diferentes portes. Neste sentido, a ferramenta
BugZilla atua como suporte a estas operações, provendo um
mecanismo eficiente de se reportar os bugs.
Bugzilla
O Bugzilla é uma ferramenta de apoio à tarefa de manu-
tenção de software, sendo utilizada principalmente como
centralizador para reporte de defeitos em software. É um
ambiente onde o desenvolvedor pode avaliar os bugs desco-
bertos e traçar metas para corrigi-los, registrando as soluções
de forma a possibilitar o acompanhamento do status do
sistema e seus problemas.
Foi desenvolvido inicialmente em TCL (Tool Command
Language) por Terry Weissmam. Hoje a ferramenta é
54 Engenharia de Software Magazine - Gerenciamento de Defeitos em Projetos de Software
distribuída gratuita e com código fonte aberto (freeware e
opensource) e foi portada para a linguagem PERL. O seu
código fonte é licenciado através do NPL (Netscape Public
License) ou MPL (Mozilla Public License), junto com GNU
ou GPL (Gnu Public License).
Por ser uma ferramenta Web, o Bugzilla deve rodar em um
servidor Web, configurado com suporte ao PERL em modo
CGI. O desenvolvedor sugere (fortemente) a utilização do
APACHE (http://httpd.apache.org) como servidor Web.
Há uma série de requisitos relacionados a módulos PERL
que devem ser instalados, como o CGI, DATA::FORMAT,
EMAIL::SEND, EMAIL::MIME::MODIFIER, GD, entre ou-
tros. Há uma relação completa destes módulos requeridos e
opcionais no manual de instalação da ferramenta, que pode
ser encontrado na própria página do Bugzilla.
A ferramenta suporta o MySQL, PostgreSQL e Oracle como
banco de dados. No contexto deste artigo foi utilizado o
MySQL, entretanto o processo de instalação é similar para
qualquer dos bancos.
O processo de instalação é um pouco complexo, uma vez
que os requisitos da ferramenta são vastos, especialmente
com relação aos módulos PERL. Entretanto, o desenvolvedor
disponibilizou um script que busca automatizar este pro-
cesso, mas para executá-lo é necessário ter acesso ao shell
do servidor (SSH no Linux ou prompt do MS-DOS / telnet
/ terminal service no Windows), seja o servidor Windows
ou Linux, uma vez que a ferramenta é compatível com
qualquer um desses ambientes. Infelizmente nem todos os
provedores de hospedagem comercial disponibilizam acesso
shell ao servidor, o que dificultará a configuração. Mas, para
os casos onde há esta possibilidade, ou até mesmo quando
se for instalar a ferramenta na máquina local, a utilização
deste script facilitará o processo.
O script se chama checksetup.pl e automatiza o processo de
configuração inicial do Bugzilla. Para rodá-lo, é necessário
já ter configurado o servidor web para hospedar os scripts
do Bugzilla, o PERL, os módulos PERL, e ter criado uma
base de dados no servidor de banco de dados escolhido. É
necessário também já ter associado um usuário ao banco de
dados criado com as devidas permissões na base. Com isso,
o script, ao rodar, irá verificar se todos os módulos Perl estão
de fato configurados e caso falte algum, o script irá emitir
um alerta e impedir a instalação. Caso todos os módulos
estejam instalados corretamente, o script irá perguntar o
nome do banco de dados criado, o usuário associado ao
banco e irá criar as tabelas necessárias para que o BugZilla
rode. Neste processo, pelo script, é possível criar um usuário
no sistema, que será o usuário administrador do BugZilla,
onde terá acesso à interface administrativa da ferramenta.
Feito isso, basta rodar a ferramenta via navegador no link
que foi configurado no servidor web. Caso tudo tenha sido
feito com sucesso, a tela que será visualizada é a apresentada
na Figura 1. Esta interface representa a interface inicial da
ferramenta na sua versão 3.4.4, última versão estável libe-
rada quando este artigo foi escrito.
 Validação, Verificação & Teste
Figura 1. Interface Inicial do BugZilla
Nas próximas seções deste artigo são apresentadas três
óticas diferentes de utilização do sistema. Inicialmente é
apresentada a ótica de configuração do sistema, através
do Administrador do BugZilla. Após isso, é apresentada a
visão do usuário comum, responsável por reportar defeitos,
pesquisar defeitos já reportados, entre outros. Por fim, é
apresentada a visão do desenvolvedor, onde pode visualizar
os bugs já reportados, classificar estes defeitos e então traçar
metas para corrigi-los.
No artigo é apresentado o BugZilla na sua interface oficial e
em inglês. No site do desenvolvedor há uma série de pacotes
de tradução, inclusive Português-BR. Entretanto, a última
versão do pacote de tradução BR é somente compatível com
a versão 3.0 da ferramenta.
Figura 2. Interface Administrativa do BugZilla
Visão Administrador
O usuário administrador possui todas as permissões no
sistema e é quem tem acesso à interface de configuração do
BugZilla. Nela são definidas todas as configurações e perso-
nalizações da ferramenta. Este usuário é criado no processo
de configuração para utilização da ferramenta. Para se logar
na ferramenta, basta clicar em Log in na interface inicial.
Assim que estiver autenticado, o administrador é levado para
a interface centralizadora de configurações, que é exibida na
Figura 2.
Sempre que qualquer usuário está logado, inclusive o Admi-
nistrador, é exibido no topo da página uma série de links para
ações genéricas no sistema. As opções são:
• Home (Principal) – Volta para a interface principal da
ferramenta;
• New (Novo) – Reporta um novo defeito;
• Search (Busca) – Exibe uma interface de busca para defeitos
reportados;
• Reports (Reportes) – Exibe os defeitos já reportados, inclusive
com a opção de visualização gráfica dos defeitos;
• My Votes (Meus Votos) – Apresenta os votos feitos pelo usu-
ário em algum defeito com o objetivo de confirmá-lo como
um defeito;
• Preferences (Preferências) – Disponibiliza uma interface
para configuração personalizada específica para o usuário
autenticado;
• Administration (Administração) – Somente o usuário Ad-
ministrador tem acesso a esta interface, que disponibiliza um
centralizador de todas as configurações e personalizações da
ferramenta. Ao clicar nesta opção, é exibida a interface exibida
na Figura 2;
Edição 22 - Engenharia de Software Magazine 55
• Log out (Sair) – Encerra a sessão do usuário autenticado na
ferramenta.
Na interface de Administração (Administration), onde
somente o usuário administrador tem acesso, são disponi-
bilizadas as seguintes opções:
• Parameters (Parâmetros) – Viabiliza a configuração das
principais propriedades e parâmetros da ferramenta.
• Default Preferences (Preferências Padrão) – Altera as pre-
ferências padrão dos usuários. Os valores definidos nesta
interface são utilizados por todos os usuários da ferramenta.
Entretanto, o usuário após se autenticar, pode acessar a inter-
face Preferences (Preferências) para personalizar essas variá-
veis conforme seu gosto, e não ao gosto do Administrador.
• Sanity Check (Checagem de Sanidade) – Executa um teste
de sanidade no sistema, especialmente na base de dados,
verificando se tudo está funcional.
• Users (Usuários) – Possibilita a administração dos usuários
no sistema. Criação de novos usuários, edição, exclusão e
visualização dos já cadastrados. Ainda é possível manipular
as permissões dos usuários cadastrados.
• Products (Produtos) – Onde são definidos os produtos
que poderão receber reportes de defeitos. Geralmente um
software.
• Flags (Bandeiras) - Flags são marcadores que identificam se
um defeito ou anexo tenha sido autorizado ou negado algum
status da ferramenta.
• Custom Fields (Campos Personalizados) – Permite a con-
figuração de campos personalizados para o cadastro de
produtos (software) e defeitos.
Figura 3. Interface Administrativa de Parâmetros de Sistema
56 Engenharia de Software Magazine - Gerenciamento de Defeitos em Projetos de Software
• Field Value (Valor dos Campos) – Define um valor padrão
para os campos padrão do sistema ou campos personalizados
definidos pelo administrador na opção Custom Fields (Campos
Personalizados).
• Bug Status Workflow (Fluxo de Trabalho dos status dos
bugs) – Cada bug reportado no sistema irá ter um status que
será apresentado ainda neste artigo. Esta opção permite es-
tabelecer um fluxo de trabalho entre esses status, inclusive a
ordem que eles podem ser alterados, desde a sua criação até
seu fechamento.
• Groups (Grupos) – Permite a definição de grupos para
usuários que estabelecem permissões de acesso ao sistema.
A própria ferramenta já define um padrão, mas que pode ser
personalizado conforme a preferência do administrador.
• Keywords (Palavras Chaves) – Define palavras chaves para se-
rem usadas com os bugs. É usada para estabelecer uma TAG para
os bugs, facilitando a sua manipulação e classificação futura.
• Whining (Uma espécie de tarefas agendadas) – Permite
definir operações para serem executadas em dia e hora
programados.
Ao selecionar a opção Parameters (Parâmetros) é apresen-
tada a interface exibida pela Figura 3. Como já apresentado,
essa opção permite a edição das preferências e propriedades
da ferramenta, como o email do administrador do sistema,
qual é a URL que o sistema está configurado, como é feita a
autenticação dos usuários, como os emails são enviados pela
ferramenta (sendmail, smtp, entre outros), onde e como são
armazenados os anexos que os usuários podem enviar quando
reportam um bug, entre outros.
 Validação, Verificação & Teste
A Figura 4 apresenta a interface de Usuários, onde é pos-
sível configurar os usuários da ferramenta. Nessa interface,
o Administrador pode editar os usuários já cadastrados, al-
terando inclusive suas permissões de acesso, e incluir novos
usuários. Entretanto, qualquer usuário pode se cadastrar no
sistema pela interface inicial (Principal) do Bugzilla, sem a
necessidade que o Administrador o cadastre.
Mas caso seja da vontade do Administrador, é possível
restringir os cadastros, sendo necessária a aprovação do
Administrador para que o usuário cadastrado tenha per-
missão de reportar bugs.
Já a Figura 5 apresenta a interface de edição de um usuário
cadastrado, onde é possível alterar seus dados, e especial-
mente seus Grupos, onde são definidas suas permissões
de acesso ao sistema. Esses grupos são definidos na opção
Groups (Grupos) na interface de Administração do Admi-
nistrador. No exemplo apresentado, observe que o usuário
está no grupo admin: Administrators, que possui permissão
de acesso total no sistema.
Na opção Products (Produtos) é onde são definidos os produtos
(geralmente softwares) que o Bugzilla irá rastrear os defeitos. As-
sim que selecionada, é exibida a interface onde são visualizados os
Figura 4. Interface Administrativa de Visualização de Usuários
Figura 5. Interface Administrativa de Edição de Usuários
produtos cadastrados, como na Figura 6. Nessa mesma interface
é disponibilizada uma opção para cadastrar um novo produto,
editar um produto existente ou excluí-lo. Veja que, no exemplo, há
um produto cadastrado com o nome Software Teste Bugzilla. Este
produto está aberto para recepcionar novos bugs dos usuários.
Foi ainda configurado um limite de 10000 votos para cada bug
reportado, e um mínimo de 3 votos para confirmar um bug.
Essa opção de confirmar um determinado bug é especialmen-
te importante, pois permite alterar automaticamente o status de
um bug de Novo para Confirmado de acordo com os votos dos
usuários. Ou seja, se mais de 3 usuários estiverem reportando o
mesmo bug, este está confirmado e merece uma atenção maior
da equipe de desenvolvimento e correção de defeitos.
Figura 6. Interface Administrativa de Visualização dos Produtos
Ao selecionar um bug cadastrado, ou então clicar em adicio-
nar um novo produto (Add a product), é exibida a interface
apresentada na Figura 7. Nela é possível configurar os parâ-
metros do produto, como nome do produto, uma descrição,
se ele está aberto ou fechado para recepcionar novos reportes,
qual o máximo de votos que um usuário pode dar no produto,
globalmente, e em um defeito específico, o mínimo de votos
para confirmar o defeito, o componente do produto (pode haver
vários componentes, como por exemplo, interface do sistema,
módulo de pagamento em um sistema de vendas, entre outros),
a versão do sistema (define a baseline do software) e o grupo
que este produto está inserido.
Já na opção Bug Status Workflow (Figura 8) é onde são defi-
nidos os status dos defeitos no sistema. Especificamente nessa
interface é configurado o fluxo de trabalho entre os status. Os
principais status são definidos abaixo:
• Unconfirmed: não confirmado, geralmente o estado inicial
de todo bug. Significa que ninguém ainda verificou a validade
do bug (confirmação). Usuários com permissão podem passar
um bug de Unconfirmed para New. Geralmente o responsá-
vel pelo bug ou outra pessoa tenta reproduzir o bug e, se ele
realmente ocorrer, é marcado como New. O bug nesse estado
pode passar por votação para mudar para New (quantidade
mínima de votos), e ser um novo bug. O bug nesse estado pode
ser diretamente resolvido e marcado Resolved. Para todos os
estados existe possibilidade de loop;
Edição 22 - Engenharia de Software Magazine 57
 pela Figura 10. Nessa figura, é possível identificar o grupo
admin, que possui todas as permissões de acesso. Entre
as principais permissões destacam-se a possibilidade de
editar um bug, editar uma classificação de um bug, poder
confirmar um bug (geralmente atribuída a um membro da
equipe de desenvolvedores, por exemplo), editar usuários,
editar componentes dos produtos, entre outros.

Figura 7. Interface Administrativa de Configuração dos Produtos

• New: o bug é novo, pertence à lista de bugs pessoais do

responsável pelo bug, e deve ser processado. O responsável
(desenvolvedor), em conjunto com outras pessoas ou não,
analisa o bug e decide se o aceita. Se for aceito, o bug deve ser
passado para o status Assigned. Se não for aceito, a responsa-
bilidade pelo bug pode ser atribuída à outra pessoa e ele será
Figura 8. Interface Administrativa de Fluxo de Trabalho dos Status de
mantido como New. Bugs nesse estado podem ser diretamente Defeitos
solucionados e marcados como Resolved;
• Assigned: nesse estado, o bug foi aceito por alguma pessoa,
que é responsável por ele. Essa pessoa pode resolvê-lo sozinha
ou com participação de mais pessoas, e então o bug é passado
para Resolved. Esse estado é o principal e, geralmente, o bug
encontra-se nesse estado quando alguém está trabalhando em
uma solução para ele. Se necessário, a responsabilidade pelo
bug pode ser atribuída (Reassigned) para outra pessoa, e então
ele passa para estado New;
• Resolved: uma solução foi dada ao bug, para algum dos tipos
de solução. A partida desse estado pode acontecer da solução
dada ser incorreta ou conter falhas e o bug precisar ser rea-
berto (passar para Reopened). Se a solução estiver correta, ele
pode ser fechado e passar para Closed. Se for necessário esse Figura 9. Interface Administrativa de Visualização de Grupos
bug ser verificado por alguém ou por um grupo de pessoas
antes de ser fechado, isso deve ser feito e ele pode passar para
Verified ou ser reaberto.

Nesta opção de workflow, são definidos os estados em que

são permitidos a transição. Com isso o Administrador pode
proibir, por exemplo, que um bug não confirmado (Unconfir-
med) passe diretamente para o estado Assigned. Ou seja, é
definido um workflow para estes estados.
Por fim, temos a interface de administração (Figura 9)
responsável por gerir os grupos de usuários e suas permis-
sões. Nesta interface são apresentados os grupos existentes
e suas descrições, além de uma opção de adicionar um novo
grupo. Ao clicar em um grupo existente é exibida a interface
de edição de grupo (mesma quando se clica ao cadastrar
um novo). Nela é permitido configurar o grupo e atribuir
permissões a usuários deste grupo, como é apresentado Figura 10. Interface Administrativa de Configuração de Grupos

58 Engenharia de Software Magazine - Gerenciamento de Defeitos em Projetos de Software

 Validação, Verificação & Teste

Visão Usuário acompanhar a evolução do defeito reportado por ele através da

Esta seção tem como objetivo apresentar a visão de um opção de busca. Ao encontrar o seu bug reportado, é exibida
usuário comum que se registra na ferramenta para reportar uma interface com todos os detalhes do bug e a possibilidade
algum bug em algum produto já previamente cadastrado pelo de adicionar comentários. Qualquer usuário pode adicionar
administrador. qualquer comentário ao bug, mesmo que seja um bug que ele
Ao entrar na URL da ferramenta que foi configurada, o usu- não tenha reportado.
ário irá visualizar exatamente a mesma página apresentada na
Figura 1. Nesta interface o usuário possui a possibilidade de Visão Desenvolvedor
procurar algum bug já reportado em Search (Busca), reportar O desenvolvedor, ao se autenticar no sistema, tem a opção de
um novo defeito (New / File a Bug), se autenticar no sistema pesquisar por bugs de um determinado produto e ver todos
(Log In) ou criar uma nova conta (New Account / Open a os bugs reportados, como visualizado na Figura 12. Ao clicar
New Account). no bug escolhido, ele irá visualizar os detalhes daquele bug,
Para criar uma nova conta, o processo é bem simples. Basta poderá interagir com o usuário que reportou e com os demais
acessar a opção correta que na interface seguinte será solici- usuários que estão acompanhando o reporte. Lá é possível
tado o seu email. O Bugzilla então irá enviar um email para o também evoluir o status do bug até corrigi-lo ou então não o
que foi digitado como forma de verificar se o email é válido. confirmar, como podemos ver na Figura 13.
Neste email enviado haverá um link com informações para
finalizar o cadastro.
Com seu cadastro ativo, o usuário pode se autenticar no sis-
tema para reportar algum bug. Assim que solicita esta opção,
o usuário é levado para a interface apresentada na Figura 11.
Nela é possível escolher o produto a qual se refere o reporte,
o componente do produto, sua versão, a severidade do defeito
encontrado, qual hardware foi utilizado ao encontrar o defeito
e o sistema operacional. Abaixo é solicitado um breve sumário
do defeito bem como sua descrição. Há ainda a opção de anexar
algum arquivo como, por exemplo, algum log do sistema ou
um screenshot da tela, como forma a auxiliar o desenvolvedor
a identificar o bug.
Figura 12. Visualização dos Defeitos Reportados

Figura 11. Interface de Reporte de Defeito

Assim que é cadastrado o defeito, é mantido sob o status
New (novo). Este poderá ser alterado automaticamente para
confirmado se alcançar o número mínimo de votos ou então
manualmente pela equipe de desenvolvimento responsável por
analisar os reportes enviados pela ferramenta. O usuário pode
Figura 13. Visualização dos Detalhes de um Defeito
Considerações Finais
O Bugzilla é uma ferramenta de apoio à tarefa de manu-
tenção de software. Por ser em ambiente Web, permite que
qualquer usuário facilmente reporte um defeito encontrado

Edição 22 - Engenharia de Software Magazine 59

em qualquer tipo de aplicação. Apesar da instalação ser um funcionalidade de gerenciador de casos de teste no Bugzilla,
pouco complicada, a ferramenta é amplamente utilizada permitindo ao desenvolvedor cadastrar seus casos de teste
pelas empresas de desenvolvimento de software como pla- na ferramenta e associar estes a defeitos reportados por
taforma de registro de defeitos. usuários. Esse é em especial importante para empresas de
Existem uma série de ferramentas de bug tracking, como desenvolvimento que mantém práticas de teste de software
o Bugzilla. Destacamos: Eventum (http://dev.mysql.com/do- no seu processo de desenvolvimento.
wnloads/other/eventum/), FogBugz (http://www.fogcreek.com/
FogBUGZ/), Jira (http://www.atlassian.com/software/jira/), Man-
tis (http://www.mantisbt.org/), Trac (http://trac.edgewall.org/),
Zephyr (http://www.getzephyr.com/), entre outras. Mesmo com Links
tantas outras opções, o Bugzilla é a ferramenta mais famosa Site Oficial da Ferramenta Bugzilla
e amplamente usada, especialmente por está presente no http://www.bugzilla.org
sistema de rastreio de defeitos de gigantes como Mozilla,
Gnome, Nasa, Wikipedia, entre outros. Dê seu feedback sobre esta edição! Feedback
eu
A Ferramenta Bugzilla foi construída com suporte a adi-

s
Dê
ções, chamadas de Bugzilla Additions. Esses additions são A Engenharia de Software Magazine tem que ser feita ao seu gosto.

sobre e
realmente adições na ferramenta que permitem que qual- Para isso, precisamos saber o que você, leitor, acha da revista!

s
ta
edição
quer desenvolvedor possa desenvolver uma nova funcio- Dê seu voto sobre este artigo, através do link:
nalidade a ser agregada. Um que merece especial destaque www.devmedia.com.br/esmag/feedback
é o Addition chamado Bugzilla Test Runner. Ele adiciona a

60 Engenharia de Software Magazine - Gerenciamento de Defeitos em Projetos de Software

62 Engenharia de Software Magazine - Gerenciamento de Defeitos em Projetos de Software