Edição56 2013

Rodrigo Oliveira Spnola
rodrigo.devmedia@gmail.com
Doutor e Mestre em Engenharia de Software pela COPPE/UFRJ. Realizou seu Ps-Doutorado na
University of Maryland Baltimore County e Centro Fraunhofer nos Estados Unidos. Atualmente
Professor Titular do Programa de Ps-Graduao em Sistemas e Computao da Universidade
Salvador - UNIFACS.
Marco Antnio Pereira Arajo

maraujo@devmedia.com.br
Ano 5 - 56 Edio - 2012
Colaboradores
Marco Antnio Pereira Arajo
Eduardo Oliveira Spnola
Doutor e Mestre em Engenharia de Sistemas e Computao pela COPPE/UFRJ - Linha de Pesquisa

em Engenharia de Software, Especialista em Mtodos Estatsticos Computacionais e Bacharel em
Matemtica com Habilitao em Informtica pela UFJF, Professor e Coordenador do curso de Bacharelado em Sistemas de Informao do Centro de Ensino Superior de Juiz de Fora, Professor do
curso de Bacharelado em Sistemas de Informao da Faculdade Metodista Granbery, Professor e
Diretor do Curso Superior de Tecnologia em Anlise e Desenvolvimento de Sistemas da Fundao
Educacional D. Andr Arcoverde, Analista de Sistemas da Prefeitura de Juiz de Fora, Colaborador
da Engenharia de Software Magazine.
Jornalista Responsvel
Kaline Dolabella - JP24185
Eduardo Oliveira Spnola
Na Web
http://www.devmedia.com.br/revista-engenharia-de-software-magazine
Colaborador das revistas Engenharia de Software Magazine, Java Magazine e SQL Magazine. bacharel em Cincias da Computao pela Universidade Salvador (UNIFACS) onde atualmente cursa o
mestrado em Sistemas e Computao na linha de Engenharia de Software, sendo membro do GESA
(Grupo de Engenharia de Software e Aplicaes).
Corpo Editorial
Editor
Rodrigo Oliveira Spnola
Atendimento ao Leitor
A DevMedia conta com um departamento exclusivo para o atendimento ao leitor.
Se voc tiver algum problema no recebimento do seu exemplar ou precisar de algum
esclarecimento sobre assinaturas, exemplares anteriores, endereo de bancas de
jornal, entre outros, entre em contato com:
www.devmedia.com.br/central
(21) 3382-5038
eduspinola@gmail.com
Fale com o Editor!

muito importante para a equipe saber o que voc est achando da revista: que tipo de artigo voc
gostaria de ler, que artigo voc mais gostou e qual artigo voc menos gostou. Fique a vontade para
entrar em contato com os editores e dar a sua sugesto!
Se voc estiver interessado em publicar um artigo na revista ou no site SQL Magazine,
entre em contato com os editores, informando o ttulo e mini-resumo do tema que voc gostaria
de publicar.
Publicidade
Para informaes sobre veiculao de anncio na revista ou no site entre em
contato com:
publicidade@devmedia.com.br
EDITORIAL
definio e o gerenciamento de processos envolve uma srie de preo-
de um modelo de qualidade, a alcanar resultados esperados pelo modelo
cupaes que precisam ser consideradas em conjunto para o sucesso de
MPS.BR (Modelo de melhoria de software brasileiro) no processo de gerencia-
uma iniciativa de implantao de processos na organizao. Este cenrio
mento de projetos no seu primeiro nvel, G.
um tanto quanto complexo o tema de capa desta edio da Engenharia de Soft-
Alm destes artigos, teremos mais seis artigos nesta edio:
ware Magazine que destaca trs artigos que apresentam perspectivas diferentes
Gerenciamento de requisitos com Kanban
e complementares sobre iniciativas de definio e gerenciamento de processos.
Trabalhando com Scrum e UML
No artigo Modelagem de processos de software com SPEM ser visto como
Tcnicas de testes exploratrios
possvel especificar processos de desenvolvimento de software utilizando a
VSS x SVN
linguagem SPEM mantida pela OMG. Como forma de demonstrar os principais
Modelagem OO na prtica
conceitos do SPEM ser utilizado o Processo Unificado (PU) para representar um
Arquitetura orientada a servios
processo de software usual.

J no artigo Aplicando BPM na engenharia de software, apresentado como
Desejamos uma tima leitura!
o gerenciamento de processos de negcio (BPM) pode ser utilizado na rea de

engenharia de software, identificando e sugerindo a utilizao das melhores prticas que a disciplina prope.
Por fim, no artigo Gerenciamento de Projetos, so apresentadas sugestes
que facilitem empresas de pequeno e mdio porte, que iniciam a implementao
Equipe Editorial Engenharia de Software Magazine
NDICE
Agilidade
05 - Gerenciando requisitos com Kanban
Paulo Victor Gama Gross de Souza
11 - Trabalhando com Scrum e UML

Bruno Carreira Coutinho Silva
Planejamento
17 - Gerenciamento de Projetos
Ivnia Ramos dos Santos
Engenharia
26 - Aplicando BPM na engenharia de software
Mircia Vinter Freire
31 - Tcnicas de testes exploratrios

Clia Negrini
37 - Modelagem de processos de software com SPEM

Edson A. Oliveira Junior e Maicon Giovane Pazin
Arquitetura e Desenvolvimento
43 - VSS x SVN
Alan Antunes, Daniel Carlos Dvila, Ivnia Ramos dos Santos e Robson Da Motta
49 - Projeto de sistema para armazenamento de interfaces

Beatriz T. Borsoi, Franciele de Lima, Gssica de Wallau, Ivnia Ramos dos Santos e Poliane de Souza
54 - Arquitetura orientada a servios

Bento Rafael Siqueira
Agilidade
Nesta seo voc encontra artigos voltados para as prticas e mtodos geis.
Gerenciando requisitos com Kanban

Adequao dos processos de gerenciamento de requisitos utilizando Kanban
De que se trata o artigo:

Este artigo apresenta a utilizao de cinco prticas e
dezenove subprticas de Gerncia de Requisitos baseada em CMMI (Capability Maturity Mode Integration), nvel 2 de maturidade. A empresa de TI, foco
dos estudos, utilizou uma metodologia baseada nos
princpios do modelo de produo da Toyota, utilizando Kanban para aderir aos itens propostos pelo
CMMI na rea de gesto de requisitos.
Em que situao o tema til:

Os mtodos geis visam aumentar a interao
entre cliente e equipe de desenvolvimento de
software, de forma a antecipar possveis problemas no decorrer do projeto.
A ideia de unir Kanban ao processo de gerencia-
C
Paulo Victor G. Gross de Souza
pvggds@gmail.com
Graduado na rea de TI e MBA em Gesto da Qualidade de Software pela FIAP.

Ps-graduado em gesto de projetos
pelo IBTA com 8 anos de experincia profissional, atuando sempre nas reas de
TI e P&D em sistemas Web. Atualmente
coordenador de projetos na empresa UOL
- Universo Online.
om o surgimento das consultorias em desenvolvimento de

software e processos, cada vez
mais prezada a comunicao com o
cliente e a agilidade no levantamento
e desenvolvimento de requisitos de
software.
Hoje empresas adotam prticas geis
(modelo Lean Six Sigma), oriundas do
modelo Toyota de produo, a fim de
obter um diferencial em competitividade
e agilidade. Para isso, o artigo apresenta
a utilizao de cinco prticas e dezenove
subprticas de gerncia de requisitos
mento de requisitos visa melhorar a interao e

iterao entre clientes e equipes de desenvolvimento antecipando defeitos que tem o custo
elevado em dez vezes a cada fase em que deixam
de ser corrigidos.
Kanban tambm permite diminuir o excesso de
mudanas de requisitos, processo crtico e de risco no gerenciamento de projetos segundo prticas descritas pelo guia do Project Management
Institute (PMI), o Project Management Body of
Knowledge (PMBOK).
Gerenciamento de Requisitos com Kanban:

Este artigo traa paralelos entre as prticas
propostas pelo CMMI e a pratica Kanban para
gerenciamento de requisitos.
que buscam atender de forma eficiente o

nvel 2 de maturidade do CMMI atravs
do modelo gil Kanban.
O artigo apresenta os benefcios trazidos pela juno de prticas do CMMI
ao modelo Lean Six Sigma, derivado do
Kanban, que foi adotado pela empresa
analisada e expandido para aderir aos
processos da rea de conhecimento de
gerncia de requisitos.
Este trabalho se organizou em torno
de quatro pilares. O primeiro descreve
um pouco sobre a metodologia Kanban.
O segundo trata das prticas e subprticas
Edio 56 - Engenharia de Software Magazine
da rea de processo de gerncia de requisitos do CMMI.

Em sequncia, como terceiro pilar, temos uma breve descrio do modelo Lean Six Sigma da empresa. Para efeito de
anlise, foi utilizada uma consultoria em desenvolvimento
de software de So Paulo, especializada em desenvolvimento de sistemas financeiros para o mercado de telefonia,
denominada Black Belts Company. Por fim, como ltimo pilar,
foi realizada uma anlise de toda a pesquisa, traando um
paralelo entre os modelos CMMI e Kanban Lean Six Sigma e
onde as prticas do CMMI podem ajudar no modelo adotado
pela empresa.
Kanban
Kanban uma palavra de origem japonesa que significa registro ou placa visvel. Na engenharia de produo, significa
um carto de sinalizao que controla os fluxos da produo.
Largamente utilizado em linhas de produo, na fabricao de
peas ou componentes, para indicar a entrega de lotes ou peas
produzidas. Um exemplo quando se esgotam todas as peas
em estoque, um aviso sinalizado para que a matria prima
seja preparada para um novo pedido de produo.
O Kanban permite agilizar a entrega e a produo, por
fornecer um modelo de gesto visual, de forma que o gerente da fbrica possa acompanhar o andamento da linha
a qualquer momento. Com prazos cada vez mais curtos o
mercado de software comeou a necessitar de desenvolvimento gil de tal forma que as empresas aderem prticas
como Scrum e Kanban.
Para melhorar a qualidade de softwares entregues, desdobrando requisitos macros em requisitos menores, com entregas
iterativas e com valor agregado para o cliente, as prticas de
Kanban comearam a ser inseridas na linha de produo do
desenvolvimento de software.
Para um desmembramento dos requisitos em partes menores, necessrio separ-los em peas que compe um fluxo
de trabalho, ou seja, uma sequncia de passos e atividades
desenvolvidas por um time para atingir um objetivo especfico.
Estas peas que compe o fluxo de trabalho so representadas
por User Stories (requisito capturado normalmente em um
pargrafo que descreve a necessidade de um usurio de forma
breve utilizando uma linguagem comum ao negcio).
Cada requisito do sistema pode ser representado por uma
ou mais User Stories que so representadas por um carto
Kanban a ser colocado na linha de produo de software.
Na medida em que o trabalho de desenvolvimento da User
Story incrementado, a mesma passa de fase dentro da linha,
destacando que o desenvolvimento gil de software pode
ser separado em fases como, de anlise, design, codificao,
testes e entrega, por exemplo, ou apenas em fila ou Back Log
(lista de atividades a serem realizadas), User Story, TO DO
(tarefas a fazer), DOING (tarefas em execuo), DONE (tarefas
finalizadas) e QA (atividades de garantia de qualidade), como
ilustra a Figura 1.
Para que as peas andem como uma esteira em uma linha
de produo, o objetivo um fluxo de trabalho contnuo.
O sistema Kanban deve ser nivelado entre as fases e profissionais alocados por fase, onde as fases de maior complexidade
podem requerer um nmero maior de profissionais atuando,
por exemplo.
Se um item de Back Log consumir 8 horas de um analista de
mesmo nvel de experincia na fase de garantia de qualidade e
16 horas na fase de desenvolvimento isso quer dizer que a fase
de desenvolvimento (in Dev) trar um gargalo na produo e a
fase garantia de qualidade (in QC) ficar ociosa (uma vez que
ela somente poder ser executada depois que as atividades de
desenvolvimento forem finalizadas). Para que isso no acontea, necessrio nivelar o trabalho, colocando dois profissionais
para atuar em um item na fas e de desenvolvimento e um para
atuar no item que est na fase de garantia de qualidade como
ilustra a Figura 2.
Figura 1. Exemplo de quadro Kanban
Figura 2. Exemplo de quadro Kanban
Para este nivelamento possvel limitar a quantidade de itens

em cada fase. Em vez de alocar dois profissionais para a fase In
Dev e um profissional para a fase In QC, pode-se determinar
um tamanho mximo de dois itens na fase In Dev e quatro na
fase In QC. Esta prtica denominada WIP Limit ou limite de
trabalho em progresso, como ilustra a Figura 3.
Engenharia de Software Magazine - Gerenciando requisitos com Kanban
agilidade
Estabelecer critrios para distinguir os fornecedores apropriados de requisitos;

Estabelecer critrios objetivos para aceitao de requisitos;
Analisar os requisitos para assegurar que os critrios estabelecidos esto sendo atendidos;
Chegar a um entendimento dos requisitos com o fornecedor
dos requisitos, de forma que os participantes do projeto possam
estabelecer compromissos com relao a eles.
SP2 Obter Compromissos com os Requisitos

Figura 3. Exemplo de quadro Kanban com WIP Limit
A prtica explicada no pargrafo anterior torna a linha

de produo um sistema puxado ( medida que um item
finalizado, outro iniciado), onde as demandas chegam
pela necessidade de mais trabalho na linha de produo e
no mais empurrado (independente dos itens terem sido
finalizados, outros itens so adicionados linha de trabalho
criando um gargalo), onde o trabalho colocado sem nveis
de alinhamento entre as fases. Assim, possvel ter apenas o
necessrio para o trabalho de um determinado perodo, just
in time, ou seja, os itens entram na linha de trabalho apenas
na quantidade necessria para que nenhum recurso fique
ocioso ou vire um gargalo. O sistema Kanban uma das
variantes mais conhecidas domtodo just in time (JIT).
Com o sistema JIT possvel medir o tempo de ciclo de cada
User Story, dada sua complexidade, isto , medir o tempo
em que um item fica em desenvolvimento em cada fase at
passar para a seguinte. possvel medir tambm o Lead Time,
que indica o tempo total que o item permaneceu na linha de
produo. Este tempo representa o tempo desde a entrada
do item na primeira fase at a sada da ltima fase.
Essa prtica especfica prope obter compromissos com os

requisitos. Para isso, conta com duas subprticas:
Analisar o impacto dos requisitos nos compromissos existentes;
Negociar e registrar compromissos.
SP3 Gerenciar as Mudanas de Requisitos

Prtica que busca gerenciar as mudanas de requisitos, contando com cinco subprticas:
Capturar todos os requisitos e mudanas de requisitos que
foram recebidas ou geradas pelo projeto;
Manter o histrico das mudanas nos requisitos juntamente
com a justificativa para as mudanas;
Manter o histrico de mudanas para auxiliar a rastrear
a volatilidade dos requisitos, ou seja, o quanto os requisitos
mudam durante o desenvolvimento do projeto;
Avaliar o impacto das mudanas nos requisitos a partir do
ponto de vista de stakeholders relevantes;
Tornar disponveis para o projeto os dados de requisitos e
de mudanas.
rea de processo de Gerncia de Requisitos do

CMMI nvel 2
O CMMI 1.2, publicado em 2006, prope cinco nveis de
maturidade. Neste artigo, ser abordado a rea de gerncia
de requisitos, do nvel 2. Segundo o SEI (Software Engineering Institute), cada nvel possui um objetivo genrico,
que representa o que deve ser alcanado para a certificao
do nvel correspondente, onde cada rea, possui prticas
genricas, especficas e subprticas.
No nvel 2 do CMMI, o objetivo Institucionalizar um
Processo Gerenciado, ou seja, estabelecer padres para
gerenciar tarefas. Para o gerenciamento de requisitos eficaz
de requisitos, o SEI defende prticas e subprticas que foram
empregadas na empresa Black Belts Company, utilizando
Kanban.
SP1 Obter Entendimento dos Requisitos

Prtica que prope desenvolver um entendimento, atravs de
tcnicas de levantamento de necessidades, com os fornecedores
dos requisitos. Para isso, conta com quatro subprticas:
SP4 Manter a Rastreabilidade Bidirecional de

Requisitos
Essa prtica mantm uma rastreabilidade bidirecional entre
os requisitos e os planos do projeto e produtos de trabalho,
auxiliado por quatro subprticas:
Manter a rastreabilidade dos requisitos para assegurar que a
fonte dos requisitos de mais baixo nvel est documentada;
Manter a rastreabilidade dos requisitos, bem como a sua
alocao de funes, objetos, pessoas, processos e produtos
de trabalho;
Manter a rastreabilidade horizontal de funo para funo
e entre interfaces;
Gerar a matriz de rastreabilidade de requisitos.
SP5 Identificar Inconsistncias entre o Trabalho do

Projeto e os Requisitos
Prtica especfica que prope identificar inconsistncias
entre os planos de projeto e produtos de trabalho do projeto e
os requisitos, atravs de quatro subprticas:
Revisar os planos do projeto, atividades e produtos de trabalho com relao consistncia com os requisitos e com as
mudanas que forem feitas;
Identificar a fonte da inconsistncia e sua justificativa;
Identificar as mudanas que precisam ser feitas nos planos
e produtos de trabalho resultantes das mudanas na baseline
de requisitos;
Iniciar as aes corretivas.
Durante essa pesquisa se notou a utilizao de um mtodo

customizado denominado Lean Six Sigma, composto pelas
prticas de engenharia de produo e o modelo Toyota de produo, com o intuito de adapt-las ao ciclo de desenvolvimento
de software, como pode ser notado na Figura 4.
Conforme Figura 4, os Engenheiros do Conhecimento, representados pela figura do Knowledge Engineer so responsveis
por levantar os requisitos com o cliente atravs de reunies e
prototipagem, utilizando as prticas denominadas pela empresa como: elicitar, escavar e explorar conhecimento.
Aps o levantamento dos requisitos temos as atividades de
estimativas e aceite formal do projeto pelo cliente. A criao
do documento de entendimento de negcio feita seguindo a
linha de um project charter (ler Nota do DevMan 1), segundo
PMI. Nesse momento, o projeto entra na linha de produo.
Os Engenheiros do Conhecimento tambm so responsveis
por montar o plano do projeto, acompanhar os riscos e efetuar
a gesto dos requisitos e ao final do projeto executar a homologao e testes de aceitao junto ao cliente.
Nota do DevMan 1
Project Charter: Tambm conhecido como termo de abertura do projeto, o project
charter o documento que autoriza formalmente o projeto.
Modelo Lean Six Sigma da empresa Black Belts

Company
Aderncia da rea de Gerncia de Requisitos ao

modelo de gesto dos requisitos utilizado
Utilizamos neste artigo uma empresa de TI para realizao

do estudo. A anlise foi feita atravs de entrevistas e observao durante cerca de seis meses.
Ao mapear todo o processo de trabalho dos Engenheiros do

Conhecimento, foi possvel analisar em quais pontos do processo so executadas as prticas propostas pelo CMMI.
Figura 4. Unidade de produo da empresa Black Belts Company
agilidade
Para aderir prtica especfica SP1, os

Engenheiros do Conhecimento montam
um plano de entendimento de negcios,
como um project charter, descrevendo a
necessidade do projeto, os requisitos macro, as premissas e restries. Tambm
contando com prottipos e desenhos
tcnicos apresentados para aprovao
final de clientes.
Os critrios de aceite dos requisitos so
elaborados com base em uma hierarquia
de necessidade, conforme Figura 5, Figura 5. Hierarquia de necessidades do cliente
desenhada para cada projeto e publicada
em uma base de conhecimento, onde o
cliente pode acompanhar, assim como a
evoluo do projeto e fases.
Nessa hierarquia os Engenheiros do
Conhecimento identificam o desejo do
cliente, tais necessidades so desmembrados em problemas e causas razes,
como no modelo Ishikawa (ler Nota do
DevMan 2).
Os problemas so neutralizados/
resolvidos com requisitos do cliente,
os quais so lapidados e prototipados Figura 6. Quadro Kanban da Black Belts Company
para desenvolvimento, como podemos
visualizar na Figura 5.
Uma vez levantadas as necessidades e listados os requisitos
do cliente, os mesmos so transformados em requisitos funcionais ou no funcionais para desenvolvimento. Aps o processo
Ishikawa: Tambm conhecido como diagrama de causa e efeito ou diagrama espinha de peixe, o diagrama de Ishikawa apoia o gerenciamento e o controle da quade levantamento dos requisitos, para aderir prtica especfica
SP2, o aceite do cliente formalizado via e-mail e todos os
lidade em processos. Ele tem sido bastante utilizado pela indstria de software em
atividades de anlise de causa e efeito.
artefatos so disponibilizados em um portal do conhecimento, onde so armazenadas todas as informaes inerentes ao
projeto, assim como seu andamento, tendo o cliente acesso
remoto est pgina.
Para aderir s prticas SP3 e SP4 do CMMI, aps o aceite
O quadro Kanban da Black Belts Company foi montado para
facilitar a aceitao do time de desenvolvimento, sendo que os
formal do cliente, todas as mudanas que vierem a ser necessrias durante o projeto e que no foram previstas previamente
nomes de todos os artefatos seguem o nome dos requisitos com
as iniciais CAU, no caso de casos de uso, A&D, no caso de espepelo cliente so tratadas como solicitaes de mudanas, assim
como descrevem as boas prticas do PMBOK, sendo essas
cificao tcnica e CT, no caso de casos de teste. Dessa forma,
a gesto visual fica mais evidente, assim como a facilidade de
solicitaes tratadas a parte, no que tange a escopo, custo e
prazo do projeto.
manter a matriz de rastreabilidade sempre atualizada.
Para garantir a rastreabilidade bidirecional, todos os requisiA Figura 6 ilustra um exemplo do quadro kanban da empresa
tos levantados so traduzidos em casos de uso ou User Stories
analisada.
que sero entradas para a linha de produo e acompanhados
O fluxo de trabalho na linha de desenvolvimento apresenta
a rea de Aquisition, de responsabilidade dos engenheiros do
pelo quadro Kanban.
O quadro Kanban contm as fases de escrita dos casos de uso/
conhecimento, onde se desenvolve os casos de uso com base
nos requisitos e coloca um carto na coluna P de produo,
User Stories, especificao tcnica, onde so criados diagramas
de acordo com a UML, rea de criao dos roteiros de testes,
marcando assim o tempo inicial. Sendo assim, todo caso de
uso / User Story ir gerar um carto na coluna P e aps o
de desenvolvimento e de homologao.
trmino da atividade, o carto vai para a coluna S, marcando
Caso ocorra alguma solicitao de mudana que seja aprovaassim o tempo final. Uma vez nesta coluna, a prxima rea j
da e afete algum requisito j desenvolvido, todo o trabalho j
pode iniciar sua atividade, colocando o carto na coluna P
produzido para atender este requisito, mapeado pela matriz
de rastreabilidade, deve ser revisto.
da sua respectiva rea.
Nota do DevMan 2
Prtica
Aderncia
SP1 - Obter Entendimento dos Requisitos.
Sim
SP2 - Obter Compromissos com os Requisitos.
Sim
SP3 - Gerenciar as Mudanas de Requisitos.
Sim
SP4 - Manter a Rastreabilidade Bidireconal de Requisitos.

SP5 - Identificar Inconsistncias entre o Trabalho do Projeto e os Requisitos.
Parcial At o final do estudo, a empresa no possua rastreabilidade ao nvel do cdigo, apenas dos requisitos
at os casos de teste, passando pelos Casos de Uso / User Stories e A&D.
Parcial As reunies de reviso dos requisitos nem sempre ocorrem e quando ocorrem nem todas so
documentadas por quem efetuou a reviso, ou seja, o aceite formal.
Tabela 1. Soluo s prticas de gerncia de requisitos do CMMI aderidas pela organizao utilizando Kanban
Este artigo apresentou a utilizao das prticas de gerncia

de requisitos do CMMI na empresa Black Belts Company e como
foi possvel aderir tais prticas utilizando tcnicas geis e o
modelo Kanban.
Do ponto de vista crtico, essa anlise apresenta o quanto
um modelo baseado na engenharia de produo e no Lean Six
Sigma ajudou a empresa a ter processos de gerenciamento de
requisitos bem definidos.
Referncias
Software Engineering Institute (2006) CMMIDEV: CMMI for development, V1.2
model, CMU/SEI-2006-TR-008
http://www.sei.cmu.edu/cmmi/general/
Scrum with Kanban - Small Adjustments, Big Improvements - Paulo Caroli and
Gilherme Motta - Abril 2012.
D seu feedback sobre esta edio!

A Engenharia de Software Magazine tem que ser feita ao seu gosto.
Para isso, precisamos saber o que voc, leitor, acha da revista!
D seu voto sobre este artigo, atravs do link:
www.devmedia.com.br/esmag/feedback
D
s
Kanbanand Beyond Paulo Caroli Outubro 2011.
Feedback
eu
edio
ta
10
Concluso
sobre e
s
Na rea A&D (Anlise e Design) responsvel por desenvolver diagramas UML, a sequencia das colunas a mesma,
seguindo para a fase da rea VV (Verificao e Validao)
onde se desenvolve roteiros de teste, j na rea Implementation
(Desenvolvimento) desenvolvido o cdigo do produto de
acordo com o requisitado pelo cliente. Aps est fase, existe
uma nova fase VV que nesse momento executa os testes de
sistema, testes funcionais, de regresso, unitrios e outros para
garantir a qualidade do produto.
A fase I&D (Implantao e Design) a ultima fase, sendo
onde se executa os testes de aceitao descritos pelo cliente junto com os requisitos, ou seja, verificado se o critrio esperado
foi atendido. Esses testes so denominados, testes alpha.
Para aderir quinta prtica da gerncia de requisitos (SP5),
todos os artefatos gerados so revisados pelos engenheiros do
conhecimento em um processo denominado pela empresa como
motherboard. Procedimento semelhante as reunies de reviso
do Scrum, onde o trabalho produzido validado pelos gestores
de produtos (Product Owners) e apresentado ao cliente.
Apresentado o produto final para o cliente e tambm o aceite
formalizado, o projeto entra na fase de encerramento, onde
uma reunio de lies aprendidas realizada com todo o time.
Esta reunio se assemelha s cerimnias de retrospectiva do
Scrum, onde so expostos pontos positivos, de inconsistncia
e a melhorar e suas possveis melhorias.
O que for levantado na reunio armazenado em um
banco de lies aprendidas da companhia para consulta em
projetos futuros.
A Tabela 1 apresenta uma viso consolidada das prticas de
gerncia de requisitos e quais delas foram aderidas pela Black
Belts Company e seus processos.
Agilidade
Nesta seo voc encontra artigos voltados para as prticas e mtodos geis.
Trabalhando com Scrum e UML

Benefcios da utilizao de UML em um projeto Scrum
Bruno Carreira Coutinho Silva

brunocarreira@gmail.com
Possui graduao em Cincia da Computao e mestrado na rea de Qualidade de

Software pela UFES. Tem mais de 12 anos
de experincia profissional na rea de engenharia de software, atuando principalmente como arquiteto de software J2EE.
Utiliza o framework Scrum h trs anos e
atualmente engenheiro de software no
servio pblico federal.
utilizao da metodologia gil

em projetos de desenvolvimento de software crescente nos
ltimos anos, principalmente em projetos com equipes pequenas e empresas
que esto iniciando suas atividades.
Uma das maiores motivaes para a adoo desta metodologia so as entregas
rpidas (em mdia a cada duas ou trs
semanas) proporcionadas pelo desenvolvimento iterativo de cdigo e pela falta
de documentao abrangente, o que,
teoricamente, poderia burocratizar o
ciclo de produo de software.
Com o intuito de gerenciar projetos,
um dos frameworks mais utilizados
o Scrum, que permite coordenar pequenas equipes em ciclos iterativos de
construo de um produto, disponibilizando ferramentas simples e objetivas
para isso.
Alguns dos modelos mais tradicionais de desenvolvimento de software,
como o RUP (Rational Unified Process),
prezam pela documentao de sistemas com o objetivo de tornar o processo de desenvolvimento e manuteno
de software mais organizado, repetvel
e gerencivel.
Discutir a viabilidade de integrao de artefatos

UML ao processo de desenvolvimento de software
gerenciado pelo framework gil Scrum, indicando
formas de utilizao, benefcios e malefcios.

Este artigo apresenta caractersticas da
notao UML e do framework gil SCRUM,
apontando antagonismos conceituais e mostrando sugestes prticas do trabalho de
ambos em conjunto.
Scrum e UML juntos. possvel?:

A princpio, a notao UML e o framework
Scrum andam em lados opostos, visto que o
objetivo do primeiro documentar, de forma visual, as fases de desenvolvimento de
software, e o segundo prega o mnimo de
documentao possvel, com foco total no
desenvolvimento de cdigo. Aps conceituar
cada um deles, este artigo mostra, atravs de
um exemplo de processo padro, que possvel haver integrao entre os dois.
A forma mais usual e difundida de se

documentar um projeto de sistemas
atravs da UML, uma notao padro
aceita mundialmente para produzir modelos e diagramas visuais de software.
11
Com o objetivo de aproveitar os benefcios do desenvolvimento gil com Scrum e da modelagem UML, seria possvel
definir um processo de desenvolvimento de software gil com
o auxlio de documentao baseada em UML? Este artigo tem o
propsito de explorar os dois conceitos e sugerir casos prticos
em que os mesmos podem ser integrados, permitindo que esta
pergunta possa ser respondida.
Scrum
O desenvolvimento gil de software, abordado originalmente
no Manifesto gil, tem crescido em funo da necessidade de
prover aos clientes respostas rpidas e efetivas.
Existem vrios mtodos de agilidade que podem ser utilizados, dentre eles o Scrum, que pode ser considerado um
framework para gerncia de projetos geis e complexos, permitindo a colaborao entre equipes. O Scrum tambm pode
ser considerado um modo de desenvolver um produto iterativamente, onde o trabalho de equipes diferentes integrado
continuamente at a concepo do produto final, permitindo
que o cliente se envolva mais a cada iterao, propiciando a
criao do produto de qualidade e fornecendo respostas rpidas a desvios de escopo.
As equipes Scrum so compostas por colaboradores separados em trs papis diferentes:
Product Owner representa o cliente dentro da equipe.
responsvel por definir a viso do produto final, elaborar,
Figura 1. Estrutura bsica do Scrum
Figura 2. Exemplo de Burndown Chart
12
Engenharia de Software Magazine - Trabalhando com Scrum e UML
manter e priorizar o Product Backlog (lista de requisitos que

compem o produto final) e aceitar ou no as entregas de cada
ciclo iterativo de desenvolvimento;
ScrumMaster o lder e facilitador da equipe. responsvel
por remover eventuais impedimentos que possam atrapalhar
a equipe, ajudar o Product Owner na elaborao do Product
Backlog e garantir as prticas do Scrum;
Equipe Scrum so colaboradores multifuncionais e autogerenciveis responsveis pela construo do produto. Devem definir e estimar as tarefas a serem feitas a cada ciclo de
desenvolvimento.
O Sprint o ciclo de desenvolvimento de software, que dura
de duas a quatro semanas, onde, ao seu final, uma verso
potencialmente utilizvel do produto criada. No incio da
Sprint realizada uma reunio de planejamento, onde se
define o conjunto de requisitos que devem ser construdos
com base em estimativa feita pela equipe. Na verdade, esses
requisitos so descritos atravs de Stories, que so sentenas
que indicam a funcionalidade que um determinado ator pode
executar atravs de uma ao. E ao conjunto total de Stories de
um produto, damos o nome de Product Backlog, um artefato
produzido pelo Scrum.
Durante a reunio de planejamento da Sprint, as Stories
so divididas em tarefas, que so sentenas mais objetivas,
indicando aes mais granulares para implementao de um
requisito. Ao conjunto de tarefas selecionadas
para execuo em uma Sprint dado o nome de
Sprint Backlog, outro artefato do Scrum.
Uma reunio diria com toda a equipe para
acompanhamento das tarefas e resoluo de
impedimentos realizada. Ao final da Sprint,
apresentada uma verso do produto que corresponde contribuio incremental dada pelo
ciclo (Figura 1). Isso ocorre at que o produto
final seja construdo completamente.
Aps a apresentao da verso do produto
ao Product Owner (representante do cliente),
sugestes de melhorias e correes podem ser
feitas, gerando bugs para serem solucionados na
Sprint seguinte, junto s Stories acrescentadas na
reunio de planejamento da Sprint.
Com o objetivo de auxiliar no controle de
tarefas durante a execuo da Sprint, uma das
ferramentas mais utilizadas o Burndown Chart
(Figura 2).
O grfico exibe a evoluo das tarefas durante
a vigncia de uma Sprint, mostrando para toda a
equipe e, principalmente para o ScrumMaster, o
quantitativo de trabalho que precisa ser feito at
o fim do ciclo. Observe no grfico que a linha
azul representa as tarefas planejadas para a iterao enquanto que a linha vermelha representa
as tarefas que ainda esto pendentes de serem
finalizadas. Note que o ideal que estas linhas
agilidade
caminhem juntas ou a linha

vermelha esteja sempre abaixo
da azul.
Outra ferramenta que pode
auxiliar o Scrum o mtodo gil
denominado Kanban, que pode
ser usado como uma espcie de
quadro de acompanhamento da
Sprint, onde a coluna esquerda
apresenta o conjunto de tarefas
selecionadas e as colunas restantes indicam as fases de desenvolvimento em que as mesmas
tarefas iro passar durante o
perodo da Sprint (Figura 3).
UML
Figura 3. Exemplo de Kanban
A Unified Modeling Language

(UML) uma linguagem de
modelagem de sistemas que se
tornou um padro para documentao, principalmente para
o paradigma orientado a objetos,
sendo responsvel por especificar uma semntica comum, que
pode ser visualizada atravs de
diagramas.
Os diagramas da UML podem ser divididos em duas
categorias:
1. Diagramas Estruturais: so
diagramas que representam a
estrutura esttica do sistema,
a saber:
Diagrama de Classes: representa a estrutura e relaes Figura 4. Exemplo de Diagrama de Classes
das diversas classes do sistema
(Figura 4);
Diagrama de Objetos: o perfil do sistema em certo mo Diagrama de Caso de Uso: descreve a funcionalidade de
mento da execuo, exibido atravs dos objetos;
um sistema;
Diagrama de Pacotes: representa o agrupamento lgico de
Diagrama de Fluxo de Informao: representa o fluxo de
classes, mostrando dependncias;
informaes dentro de um contexto;
Diagrama de Estrutura Composta: descreve a colaborao
Diagrama de Atividades: representa o fluxo de atividades
entre elementos para especificao de uma funcionalidade;
em um nico processo;
Diagrama de Componentes: representa um componente de
Diagrama de Estados: indica a situao que um objeto pode
trabalho formado por um conjunto de classes relacionadas;
se encontrar durante a execuo de processos do sistema;
Diagrama de Implantao: exibe a configurao de
Diagramas de Iterao: so modelos que descrevem a colacomponentes de hardware e software para suporte ao
borao de objetos para um determinado comportamento;
processamento;
Diagrama de Sequncia: mostra a sequncia de mensagens
Diagrama de Perfil: um diagrama auxiliar que permite
ordenadas pelo tempo repassadas entre objetos definida para
definir esteretipos personalizados, valores etiquetados e
uma determinada funcionalidade do sistema;
restries.
Diagrama de Comunicao: similar ao diagrama de
sequncia, porm sem a nfase no tempo;
2. Diagramas Comportamentais: so diagramas que repre Diagrama Temporal: apresenta o comportamento dos objetos
sentam o aspecto dinmico do sistema, a saber:
e sua interao em uma escala de tempo;
13
Diagrama de Interatividade: pode ser visto como um diagrama de atividades onde as atividades so substitudas por
diagramas de sequncia.
Apesar de disponibilizar todos esses diagramas para o processo de documentao de sistemas, alguns destes so utilizados com mais frequncia no processo de desenvolvimento
do que outros.
Durante a fase de Anlise de Requisitos, os diagramas de
Casos de Uso so extremamente importantes para a melhor
visualizao das funcionalidades e atores do sistema que
acessam as mesmas. Ainda nesta fase, diagramas de classes
so fundamentais por representarem as entidades de negcio
e suas relaes. Alm disso, a partir desse diagrama que o
modelo relacional de banco de dados pode ser obtido.
Na fase de Projeto, onde o objetivo da documentao ser
um insumo para a codificao do software propriamente dita,
novos diagramas de classes so produzidos com o intuito de
abordar questes da arquitetura de software a serem implementadas. Com o objetivo de mostrar as diferentes camadas
de software a serem produzidas, os diagramas de pacotes
facilitam a organizao.
Durante a fase de desenvolvimento, a funcionalidade de
alguns mtodos de classe projetados na fase anterior pode ser
complexa o suficiente para demandar a criao de diagramas
de sequncia, com o objetivo de facilitar o seu entendimento.
Estes diagramas no precisam ser gerados para todos os mtodos, sendo muito teis para as funcionalidades de negcio
importantes e complexas, pois representam visualmente a
iterao entre os objetos com base numa linha de tempo. Os
diagramas de estados tambm so importantes para facilitar
o entendimento do comportamento dos objetos de classes que
possuem vrios estados durante seu ciclo de vida.
Na fase de testes, um dos diagramas mais utilizados o
diagrama de atividades, artefato til para a criao de casos
de testes baseados em fluxogramas.
Documentos que podem servir de alicerce para a implantao
do software criado so os diagramas de implantao e componentes. Sendo este ltimo muito utilizado para apresentar
uma viso geral do software implantado.
MDA (Model-Driven Architecture)

A UML fornece modelos/diagramas para as etapas de desenvolvimento, levando em conta essa abrangncia e a facilidade representacional fornecida pelos modelos UML para o
desenho de solues de software, o conceito de MDA (ModelDriven Architecture) pode ser usado para automatizarmos o
desenvolvimento.
O foco do MDA abstrair a arquitetura utilizada para a
construo de um software com apenas modelos, ou seja, aps
a gerao dos modelos que espelham o que o software dever representar, os engenheiros no precisam gerar cdigo fonte para
chegar ao resultado final, deixando isso a cargo de ferramentas aderentes a este conceito. Na verdade, essas ferramentas
produzem uma arquitetura padro e cdigo executvel (para
14
diferentes linguagens de programao) a partir de artefatos,

como o diagrama de classes, por exemplo.
Uma das vantagens do desenvolvimento baseado em modelos
a simplicidade proporcionada pela manipulao de modelos
e no linguagens de programao, necessitando menor especializao e dependncia da equipe. Porm, uma de suas desvantagens o engessamento causado pela gerao de cdigo
padro, fazendo com que a customizao seja dificultada.
Por que no usar UML em projetos Scrum?

Apesar de parecerem notrios os benefcios de se documentar um software durante o seu processo de desenvolvimento
ou manuteno, muitos seguidores de metodologias geis,
defendem que a documentao prejudica o andamento desses projetos.
Um dos argumentos usados pelos defensores dessa teoria
que o projeto gil tem uma caracterstica muito dinmica, onde
a cada iterao novas tarefas so priorizadas e alteraes so
propostas, o que permite que os modelos UML tenham chances
de se tornarem obsoletos a cada Sprint, indicando a necessidade
de alteraes frequentes, o que pode acarretar na perca de foco
no desenvolvimento pela equipe, por isso a desconfiana dos
desenvolvedores em documentos, principalmente quando o
processo manual, sem o auxlio de ferramentas que automatizem as alteraes nos modelos.
Na fase de arquitetura do software, que poderia ser documentada com o auxlio de diagramas de classes, por exemplo,
muitos adeptos do desenvolvimento gil afirmam que a mesma
emerge do cdigo, ou seja, a cada ciclo feita uma reengenharia
do cdigo at que se chegue a um resultado satisfatrio para
o projeto.
Muitos podem questionar esta metodologia com relao
qualidade, visto que a documentao com excelncia representa registros que podem ser medidos e comparados, o que
permite a visualizao e medio da estrutura e funcionalidade
de um sistema, evitando o acesso ao cdigo fonte para isso.
Projetos Scrum, possuem tendncia a descartar a sobrecarga
na criao de diagramas UML e ter como principal ferramenta
de qualidade os testes automatizados, oriundos de casos de
testes, caracterizando o TDD (Test Driven Development), que
pode ser feito em vrios nveis do processo de desenvolvimento
resultando na baixa da taxa de defeitos consideravelmente.
Scrum com UML

Apesar de haver uma corrente que prega a utilizao mais
restrita de documentao (incluindo artefatos UML) para projetos regidos pela metodologia Scrum, h outra corrente que
acredita ser pertinente e fundamental, a utilizao de artefatos
UML num processo de desenvolvimento gil.
No mercado brasileiro de desenvolvimento de software, a
utilizao de modelagem UML comum, principalmente em
grandes e mdias organizaes. No se trata somente de cultura, mas de um padro incentivado pelas melhores prticas
de desenvolvimento, provenientes de normas e modelos de
maturidade, como, CMMI e MPS.BR.
agilidade
Fica difcil imaginar um bom projeto de software que no produza,

no mnimo, diagramas de casos de
uso e de classes durante o ciclo de
desenvolvimento. Estes artefatos,
por serem extremamente difundidos e utilizados na comunidade
de TI, tornaram-se at mesmo uma
ferramenta de comunicao entre
engenheiros de software.
Sugestes de como usar UML

para auxiliar o Scrum
Uma das formas de melhor visualizar funcionalidades de um sistema
durante o levantamento de requisitos
atravs de diagramas de casos de
uso. Num projeto Scrum, diagramas
de casos de uso podem servir de Figura 5. Exemplo de Diagrama de Atividades
insumo para a gerao de Stories
para a formao do Product Backlog.
Relacionamento entre Stories e casos de uso podem auxiliar
produtos para o carrinho de compras. Depois disso, iniciado
a equipe no mapeamento visual em caso de alteraes nos
a efetivao da compra. Caso o usurio no seja cadastrado, ele
requisitos. Uma maneira eficiente e mais produtiva de impleinforma seu endereo. Na sequncia, feito o login, escolhido
mentao disto seria atravs do uso de uma ferramenta CASE
o mtodo de envio do produto, conferncia das informaes
para manipulao de diagramas, onde durante as reunies
da compra e, por fim, tem-se a confirmao.
de planejamento da Sprint, todos os requisitos possam ser
Outros diagramas comportamentais da UML so: diagrama
registrados.
de sequncia, diagrama de objetos e diagrama de estados. Estes
Com o objetivo de tambm automatizar estas atividades, popodem ser explorados ainda na fase de anlise de requisitos
dem ser utilizada tcnicas de MDA, gerando cdigo dos casos
para facilitar a criao de casos de testes e, melhorar a qualide uso levantados, mesmo que o cdigo servir simplesmente
dade e comunicao entre a equipe.
de template para o desenvolvimento customizado.
Baseado nas sugestes apresentadas foi definido um exemplo
A modelagem conceitual de entidades se inicia durante a fase
de processo padro para o desenvolvimento gil de software,
de anlise de requisitos e representada principalmente pelo
utilizando Scrum e UML.
diagrama de classes, pois dele pode se originar a modelagem
No processo exemplificado uma instncia poderia ter o
para construo do banco de dados a ser utilizado. A utilizao
seguinte fluxo:
deste diagrama no se restringe apenas fase de anlise ou
1. Planejamento e levantamento de requisitos macro do proao relacionamento entre entidades, sendo til tambm para
jeto, realiado pelo ScrumMaster, Product Owner e Stakeholders,
ilustrar classes da arquitetura de projeto implementada.
definindo assim o Product Backlog priorizado. Nesta fase, o
Um exemplo a dificuldade em imaginar o treinamento de
levantamento de requisitos pode ocorrer com o auxlio de
um novo engenheiro na equipe de um projeto sem a apresentadiagramas de casos de uso, criado com ferramenta CASE, onde
o de um diagrama de classes para contextualizao, porque
possam ser mapeados em uma ou mais Stories.
o modo visual facilita o aprendizado.
No exemplo do caso de uso Manter Empregados, pode ser
As tcnicas de MDA so sugeridas tambm para a modelagem
mapeado nas Stories Como Administrador, preciso inserir
de classes, com o objetivo de dinamizar um projeto Scrum.
Empregados para que possam trabalhar na empresa e Como
Dada a importncia atribuda fase de testes pela metoAdministrador, preciso alterar dados de Empregados para que
dologia gil, a UML tambm pode fornecer ferramentas que
tenham seus dados corretamente atualizados;
auxiliem essa etapa, como, casos de testes, que so roteiros de
2. Planejamento da Sprint feito pelo ScrumMaster, Product Owexecuo de determinada funcionalidade buscando abranger
ner e toda a equipe com o objetivo de selecionar as Stories que
todos os caminhos possveis, destacando que casos de uso pooriginaro tarefas para a criao do Sprint Backlog. Nesta fase,
dem ser usados como base para a criao de casos de testes.
os diagramas de casos de uso elaborados na ferramenta CASE
Os diagramas de atividades podem utilizados para desenhar
so melhor visualizados pela equipe, sendo possvel, separar
casos de testes, como representado na Figura 5.
funcionalidades em subsistemas.
No diagrama exibido um processo de compra. As trs priOs casos de uso referentes s Stories selecionadas devem ser
meiras atividades representam o acesso ao portal e seleo dos
detalhados em passos, para que possa se estimar o esforo
15
No existe uma nica frmula para o desenvolvimento e

manuteno de software. O modelo a ser seguido vai depender
de inmeras variveis, sendo as mais relevantes:
Prazo;
Experincia e tamanho da equipe;
Oramento;
Negcio;
Tecnologia de desenvolvimento.
16
Hazrati, Vikas. Deciphering Burndown Charts: InfoQ Enterprise Software

Development, 2010.
http://www.infoq.com/news/2010/02/deciphering-burndown-charts
Binder, J. C. (2007). Global Project Management: Communication, Collaboration and
Management Across Borders. Gower Publishing.
Kniberg, Henrik; Skarin Mattias. Kanban and Scrum - making the most of both.
InfoQ.com, 2010.
http://www.infoq.com/minibooks/kanban-scrum-minibook
Zanoni, R. (2002). Modelo de Gerncia de Projeto Baseado no PMI para ambientes
de Desenvolvimento de Software Fisicamente Distribudo. Dissertao de Mestrado,
PUC/RS, Porto Alegre, RS, Brasil.
Takeuchi, H.; Nonaka I. (1986). The New New Product Development Game. Havard
Business Review, Boston, MA, USA.
Costa C.; Rocha R.; Brito R.; Silva F. Q. B.; Prikladnicki R.; Meira S. (2010). Gerenciando
um Projeto Distribudo: Lies Aprendidas. PUC/RS, Porto Alegre, RS, Brasil.
Sutherland, Jeff. Agile Development: Lessons learned from the first Scrum, 2004.
http://www.scrumalliance.org/resources/35
Schwaber, Ken. Scrum and The Perfect Storm, 2003.
http://www.controlchaos.com/my-articles/

Feedback
eu
sobre e
s
Essas variveis devem ser criteriosamente avaliadas para

se escolher a metodologia de desenvolvimento a se aplicar
em um projeto, baseado no processo padro definido para a
organizao, mesmo que este seja informal.
A no ser que a organizao siga normas para certificao
e tenha que respeitar padres muito rgidos de qualidade, o
que pode dificultar ou inviabilizar uma maior flexibilizao,
qualquer projeto pode seguir prticas geis e utilizar artefatos
UML que se encaixem no seu processo de desenvolvimento.
Seguindo esse pensamento, a metodologia Scrum no impe restries para utilizao de UML em seu ciclo de vida,
mesmo porque se trata de um framework para suporte
gerncia de projetos.
A UML por ter se tornado um padro de documentao de
software, difundido no meio acadmico e organizacional,
sua utilizao em projetos Scrum indicada para vrias
Referncias
D
s
Concluso
organizaes. A utilizao da UML no deve se restringir comunicao entre membros de uma equipe de projeto, mas para
auxiliar e melhorar o processo de desenvolvimento. Para que
isso se torne vivel, evitando o overhead gerado pela alterao
manual de artefatos, necessrio a utilizao de ferramentas
para automatizar o processo de modelagem com UML.
edio
ta
necessrio para sua construo e para a gerao de casos de

testes, com o auxlio de diagramas de atividades. Ao modelos
de casos de uso e classes atualizados durante a execuo da
Sprint devem ser validados com toda a equipe;
3. Execuo da Sprint feita pela equipe de desenvolvimento
com o objetivo de construir o produto iterativamente. Esta
fase inclui a breve reunio diria denominada Daily Scrum que
tem como objetivo retirar os impedimentos (responsabilidade
do ScrumMaster) e manter a equipe atualizada, inclusive em
relao aos modelos alterados durante cada dia de trabalho.
importante ressaltar que, para o uso eficiente dos modelos
UML, imprescindvel que estejam localizados em ferramenta
de fcil acesso e em compartilhamento com os envolvidos;
4. Reviso da Sprint contendo a participao de todos os
stakeholders com o objetivo de apresentar a verso do produto
feita na Sprint e avaliar as pendncias residuais.
Planejamento e Gerncia
Nesta seo voc encontra artigos voltados para o planejamento
e gerncia de seus projetos de software.
Gerenciamento de Projetos
Mtodos de gerenciamento de projetos baseado no modelo MPS.BR

ivania.ramos.santos@gmail.com
Bacharel em Sistemas de Informao pela

Faculdade Mater Dei (2008), especialista
em Engenharia de Software pela Faculdade Mater Dei (2011). Atualmente analista
de controle de qualidade de processos e
consultora em solues em processos em
empresa privada, professora na Universidade Tecnolgica Federal do Paran e revisora da revista Engenharia de Software.
Experincia gesto de processos de qualidade utilizando metodologia MPS.BR.
necessidade de criao de software competitivo e de qualidade acaba exigindo das empresas

a organizao das atividades de projeto,
adotando um modelo que apresente
resultados a serem alcanados para
auxiliar na criao de produtos com
reconhecimento no mercado. O MPS.
BR (Melhoria de processo de software
brasileiro), como os demais modelos,
apresenta resultados serem alcanados
e permite que a prpria equipe organizacional realize tarefas para se chegar
a tais resultados, baseada em suas prprias caractersticas.
Em empresas de pequeno e mdio
porte, comum a necessidade de realizar atividades sem a presena de dados
histricos ou onde falta experincia de
envolvidos como estimativa de prazo e
custo, o que dificulta a implementao
e a execuo de mtodos e tcnicas de
gesto de projetos.
Neste contexto, este artigo ir apresentar sugestes que facilitem empresas de
pequeno e mdio porte, que iniciam a
implementao de um modelo de qualidade, a alcanar resultados esperados
Nesse artigo so apresentadas sugestes que facilitem empresas de pequeno e mdio porte, que
iniciam a implementao de um modelo de qualidade, a alcanar resultados esperados pelo modelo
MPS.BR (Modelo de melhoria de software brasileiro) no processo de gerenciamento de projetos no
seu primeiro nvel, G.

Para organizaes de pequeno e mdio porte
que no possuem histrico de gesto de projeto e para gerentes de projetos inexperientes, apresentando alternativas para alcanar
os resultados esperados em gerenciamento de
projetos pela metodologia MPS.BR.
Gerenciamento de Projetos:
Este artigo tem como propsito apresentar
sugestes evidenciadas atravs de planilhas
e ferramentas que auxiliem a organizao a
realizar tarefas, sendo os materiais apresentados desenvolvidos conforme necessidades
identificadas em estudo de caso na empresa
fictcia Special Software. Os resultados procuram mostrar alternativas compatveis com a
realidade de organizaes.
pelo modelo MPS.BR. O estudo realizado

foi baseado em caractersticas e atividades de uma empresa de TI (Tecnologia
de Informao), que identificada nesse
17
artigo como Special Software, caracterizada como de mdio

porte. Atravs do mapeamento de seu processo informal, se
identificou seu perfil organizacional, suas carncias e o ciclo
de vida de projetos utilizado, tambm tarefas e recursos necessrios, para ento ser adaptada ao MPS.BR, buscando alcanar
os resultados esperados em gesto de projetos (GPR).
Nas prximas sees sero descritos os resultados esperados
pela metodologia em gerncia de projetos e detalhadas aes
para alcan-los, a fim de servir como base para organizaes
que pretendem implementar a metodologia.
Gerenciamento de Projetos
O gerenciamento de projeto importante por no restringir
a organizao apenas no desenvolvimento de um produto,
mas em produzi-lo com excelncia, com atividades planejadas
e monitoradas.
Antes de gerenciar projetos, a organizao deve definir o
projeto conforme sua realidade, ou seja, no h como gerenciar
algo que no se conhece. Para o PMBOK, projeto entendido
como um esforo temporrio empreendido para criar um
produto, servio ou resultado exclusivo.
Para Pressman, gerenciar projetos consiste em combinar
mtodos abrangentes para todas as fases de desenvolvimento
do software e melhores ferramentas para automatizar esses
mtodos. Porm, mtodos tornam-se difceis de implementar
se a organizao no tiver o auxlio de um modelo que traga
resultados esperados na gerncia de projeto.
MPS.BR Melhoria de Processo do Software Brasileiro
Nota do DevMan 1
Normas ISO 12207 e 15504.
ISO/IEC 12207 - Norma que alm de se basear ao ciclo de vida do software tambm
composta por trs processos:
Primrio Onde cada envolvido deve ter seu papel definido;
De suporte Para que sejam criadas definies como base para outros processos
mesmo tendo objetivos diferenciados (documentao, configurao, garantia de qualidade, auditorias e templates);
Organizacional Necessidade de definio de um processo organizacional e sua
implementao, envolvendo todos os recursos da instituio (gesto de portflio, infraestrutura, melhorias, formao de colaboradores).
ISO/IEC 15504 Referncia para o gerenciamento de avaliaes de melhoria e
capacidade de processos, buscando identificar o perfil existente e criar um plano
de melhorias.
Nota do DevMan 2
CMMI (Capability Maturity Model Integration)
Mtodo de qualidade evolutivo, tendo cinco nveis de maturidade:
Inicial Mapeamento do processo existente, mesmo que informal;
Repetvel A organizao torna-se capaz de iniciar o gerenciamento de projetos,
repetindo tarefas padres identificadas no mapeamento;
Definido Os processos so definidos e padronizados, focando na organizao;
Gerenciado Os processos de apoio passam a ser gerenciados, a fim de medir o
desempenho do processo;
De otimizao Fase em que a organizao j dever ter implementado todos os
processos e inicia-se o processo de otimizao que garante que os problemas identificados sejam corrigidos e melhorados conforme a evoluo organizacional.
O MPS.BR pode ser considerado mais que uma metodologia

de processo, por ser um movimento iniciado por organizaes
responsveis pela rea de tecnologia da informao brasileira
na busca de sanar a necessidade de mtodos compatveis com
a realidade de empresas nacionais.
O MPS.BR composto por metodologias j existentes, sendo
seu modelo de referncia formado por um guia geral, um guia
de aquisio e um de implementao, baseados nas normas
O CMMI tem seus objetivos baseados nos processos de gerenciamento de requisitos,
ISO/IEC 12207 e 15504 (ler Nota do DevMan 1) e tambm ao
planejamento, monitoramento e controle do projeto, garantia de qualidade, desenmodelo CMMI-DEV (ler Nota do DevMan 2), que juntos facilivolvimento de requisitos, integrao de produto, verificao, validao, definio do
tam a adequao empresas brasileiras focando em pequenas
processo organizacional; treinamento organizacional, gerenciamento integrado do
e mdias empresas.
projeto, gerenciamento de riscos, anlises de decises e resolues.
A associao desses modelos do origem ao MPS.BR, o qual
busca possibilitar a organizaes, indiferente
do tamanho, a implementao de um processo
A
Anlise de Causas de Problemas e Resoluo ACP
de qualidade conceituado que permita sua
B
Gerncia de Projetos GPR (evoluo)
melhoria e evoluo.
Nveis do Modelo MPS.BR

O modelo MPS.BR composto por sete nveis
que possuem atributos, que so passos que
mostram o foco da organizao para alcanar
o objetivo esperado, conforme Tabela 1.
A Tabela 2 apresenta um resumo do que
esperado que a organizao atenda nas fases
de evoluo, iniciada no nvel G.
18
C
D
E
Gerncia de Riscos GRI; Desenvolvimento para Reutilizao DRU; Anlise de Deciso e Resoluo ADR;
Gerncia de Reutilizao GRU (evoluo)
Verificao VER; Validao VAL; Projeto e Construo do Produto PCP; Integrao do Produto ITP;
Desenvolvimento de Requisitos DRE
Gerncia de Projetos GPR (evoluo); Gerncia de Reutilizao GRU; Gerncia de Recursos Humanos GRH;
Definio do Processo Organizacional DFP; Avaliao e Melhoria do Processo Organizacional AMP
Medio MED; Garantia da Qualidade GQA; Gerncia de Configurao GCO; Aquisio AQU
Gerncia de Requisitos GRE; Gerncia de Projetos GPR
Tabela 1. Nveis de maturidade do MR-MPS
Engenharia de Software Magazine - Gerenciamento de Projetos
planejamento
G
F
E
So definidos processos de gerncia de requisitos e projetos.

Nessa fase so implementados processos de apoio aos definidos na fase anterior, onde inicia-se a medio da qualidade dos processos, a aplicao de processo de garantia da qualidade, tambm
so definidos e controlados artefatos pela gerencia de configurao. Quando h aquisio esse processo tambm gerenciado, como nos casos de compra de software.
Conforme o processo melhora a gerncia de Projetos evolui. Nessa fase implementada a gerncia de Reutilizao, onde se passa formalmente a controlar a reutilizao, tambm so gerenciados os
Recursos Humanos (contratao, treinamentos e outros). So formalizadas as definies do Processo Organizacional, sendo tambm aplicada avaliaes de Melhoria do Processo Organizacional.
Nessa fase o foco esta na verificao e validao; tambm em projeto, construo e integrao de produtos, tambm no desenvolvimento de requisitos.
Nesse nvel a gerncia de riscos realizada, assim como o desenvolvimento baseado na reutilizao, sendo a gesto de reutilizao evoluda. A anlise de deciso e resoluo deve ser formalizada.
O nvel B marcado pela evoluo do processo de gerncia de projetos.
Nessa fase realizada a anlise de causas de problemas e resoluo, onde preza-se pela melhoria constante do processo definido
Tabela 2. Nveis de maturidade do MR-MPS
As organizaes que adotam o modelo MPS.BR iniciam

a implementao pelo nvel G e evoluem at ao A. Vale
destacar que os nveis so somticos, ou seja, a cada nvel
que se alcana, os processos definidos no nvel anterior
continuam sendo respeitados.
No nvel G a organizao deve adotar o gerenciamento de
projetos e realizar atividades que busquem os resultados
esperados apresentados pelo modelo, os quais devem ser
respeitados e melhorados constantemente.
Na seo seguinte sero apresentadas solues adotadas
para se alcanar os resultados esperados em GPR pelo
modelo, conforme guia de implementao do nvel G do
modelo.
Alcanando resultados esperados de gerncia de

projeto nvel G
No nvel G existem dezoito resultados esperados. Nessa
seo sero detalhadas formas de alcan-los, baseado
em necessidades identificadas na organizao Special
Software.
Mapear o processo antes da implementao

Para empresas de software comum iniciar o processo
de implementao baseado em um modelo, acreditando
que o mesmo solucionar problemas de gerncia por si s.
Esta uma soluo frustrada uma vez que imprescindvel que modelo seja adaptado realidade organizacional,
associado ferramentas e tcnicas condizentes com tarefas
realizadas.
O modelo apresenta resultados esperados, porm a forma
de chegar a esses resultados devem ser escolhidas pela organizao e seus colaboradores, por isso a necessidade de
identificar as atividades atuais para ento identificar as tarefas de projeto, desde sua concepo at sua liberao.
Esse mapeamento pode ser realizado com avaliao
de consultores, ou pela equipe interna. Entrevistas com
envolvidos auxiliam a conhecer os processos organizacionais e suas deficincias. Existem tambm ferramentas
que auxiliam na criao de fluxogramas, mapas mentais e
diagramas, que facilitem o entendimento de colaboradores,
detalhando e separando fases e tarefas. Um exemplo a
ferramenta Bizagi (ferramenta BPM (Business Process Management) que permite automatizar processos de negcio
Figura 1. Exemplo de atividade
de forma gil e simples em um ambiente grfico intuitivo),

utilizada na Figura 1.
A atividade mapeada permite identificar o nome da mesma, responsvel, os artefatos de entrada, necessrios para
a execuo da tarefa e os artefatos de sadas, gerados pela
tarefa.
No exemplo apresentada a tarefa de Desenvolvimento de
requisitos, onde para execut-la necessria a especificao
de requisitos, que descreve o requisito a ser desenvolvido, o
guia de configurao que norteia o usurio quanto documentao (nome, local disponvel e padres organizacionais),
a documentao UML e tambm a existncia de uma tarefa
alocada no cronograma ao responsvel.
No processo exemplificado deve ser gerada pela tarefa, a
codificao na ferramenta correspondente, a tarefa comentada no cronograma com status Em Testes e o tempo gasto na
atividade deve ser registrado.
Vale destacar que o software Bizagi apresenta mais recursos
para seus usurios em relao BPM.
Planejamento do Projeto
Pelo processo mapeado possvel identificar o ciclo de vida
utilizado na gerncia de projeto, destacando que as fases devem
ser identificadas e definidas desde a concepo do projeto at
sua liberao e seus marcos - onde se realiza verificaes da
19
execuo do planejado; o que corresponde ao GPR3 O modelo

e as fases do ciclo de vida do projeto so definidos. A definio
do ciclo de vida auxilia stakeholders (todos os envolvidos no
projeto como clientes, analistas, usurios, desenvolvedores,
testadores...) a se situarem no estgio que o projeto se encontra
e a identificar a necessidade de melhoria. A inexistncia de
um ciclo definido resulta em atividades Constri e Conserta,
tornando impossvel o gerenciamento.
As tarefas a serem executadas devem ser organizadas em
um escopo, como pode ser observado na Figura 2, sendo esse
o ponto de partida para o planejamento do projeto a fim de
satisfazer o resultado esperado correspondente ao GPR1
O escopo do trabalho para o projeto definido.
As etapas do projeto so detalhadas no escopo, onde o
primeiro nvel tem o nome do projeto e o segundo as fases
do ciclo escolhido. Cada tarefa detalhada em sua fase correspondente, resultando no que se chama EAP (estrutura
analtica de projeto).
Atravs de uma lista de requisitos, conforme Tabela 3, pode
ser definido o escopo de produto, destacando que ambos devem estar evidenciados no plano de projeto.
No exemplo acima, as solicitaes de fornecedores de requisitos possuem numerao nica e descrio do objetivo. Caso
existam alteraes do escopo do produto, que resultem em
alterao do escopo do projeto como incluses ou excluses
de requisitos, essas devem ser gerenciadas, sendo na coluna
Status identificadas as solicitaes que foram retiradas do
projeto durante o seu andamento.
Tamanho, esforo e custo do projeto

O dimensionamento do projeto, o clculo do custo e esforo
so uma das dificuldades em empresas de TI, tendo em vista
que a maioria no realiza esse tipo de gerenciamento antes da
implementao de um modelo de qualidade.
Para facilitar a tarefa, pode ser adotada uma tcnica, destacando que a tcnica somente exigida a partir do nvel F, porm
o dimensionamento deve ser realizado no nvel G, conforme
GPR2 As tarefas e os produtos de trabalho do projeto so dimensionados utilizando mtodos apropriados. Uma sugesto
seria utilizar UCP (Pontos por casos de uso), onde:
UCP = UUCP (peso total no ajustado) x TCF (fator de complexidade tcnica do sistema) x EF (fator ambiental)
Onde UUCP o peso do projeto sem ajustes (UUCP = UAW

(peso total dos atores) + UUCW (peso bruto dos casos de uso),
sendo UAW a soma do peso dos atores e UUCW a soma do
peso dos casos de uso (ver Tabela 4).
Os fatores de ajustes TCF (Ajustes tcnicos) e EF (Ajustes
ambientais) devem ser determinados tambm, sendo a TCF
= 0.6 + (0.01 x TFactor (fator tcnico) soma dos fatores tcnicos), e EF = 1.4 + (-0.03 x EFactor (fator ambiental) soma
dos fatores ambientais).
Existem vrios softwares que permitem automatizar esse
clculo, um desses o EA (Enterprise Architect), o qual associa
a UML a interface intuitiva com recursos para anlise, testes,
gerncia de projetos, controle de qualidade e implementao,
onde o analista pode alimentar o software com os pesos adotados. O clculo realizado automaticamente dependendo
do valor de fatores alimentados no sistema.
Cd. Requisito
Descrio requisito
Status
Segundo Gustav Karner, podemos estimar o tempo ne123
Cadastrar cliente pela tela de vendas
Escolher um item.
cessrio para o desenvolvimento do projeto calculando
124
Inserir rotina de creditar
Retirado - Reavaliao do Projeto
uma mdia de 20 horas de trabalho por Ponto de Caso de
125
Permitir insero de vale clientes
Retirado - Reavaliao do Projeto
Uso (UCP). Essa mdia de horas pode ser determinada
para ser informado como valor padro no EA a fim de
126
Possibilitar a emisso de nota fiscal eletrnica Escolher um item.
serem utilizadas para o clculo de dimensionamento
Tabela 3. Escopo de projeto
do projeto.
Figura 2. Escopo do projeto
20
planejamento
Figura 3. Planilha de estimativa
Recursos
Estrutura
Custo/hora (Y$)
Ger. de Projetos
60
Analista de requisitos
40
Analista de sistemas
30
Desen. Iniciante
10
Anal. Testes Snior
40
Infraestrutura sala de reunio
10
OBS:
Nas estruturas esto
includos todos os recursos
correspondentes, desde
infra-estrutura recursos
humanos, ou seja, o custo/
hora refere-se custo geral.
Tabela 5. Tabela de custo de recursos
Esforo e custo de projetos associados
Figura 4. Tela de clculo de casos de uso, ferramenta EA

TCF - Fator, Requisito, Peso
T1
Sistema Distribudo
T2
Tempo de Resposta
Eficincia
T3
EF - Fator, Descrio, Peso

E1
Familiaridade com RUP ou outro processo formal
1.5
E2
Experincia com a Aplicao em desenvolvimento
0.5
E3
Experincia em Orientao a Objetos
Tabela 4. Exemplo de fatores tcnicos e ambientais
A mdia de 20 horas de trabalho por Ponto de Caso de Uso

(UCP) pode ser incompatvel com a realidade dos projetos
desenvolvidos pela organizao, mas outro fator que dificulta
o dimensionamento a falta de experincia de gerentes de
projetos e a falta de um histrico organizacional de projetos
dimensionado. Dessa forma, necessrio utilizar um valor
aproximado e criar uma estimativa que seja utilizada para
projetos futuros.
A estimativa utilizada para histrico a fim de estabelecer
uma mdia de UCP/HR.
No exemplo da Figura 3 a base de UCP/HR atualizada a
cada 3 projetos. O valor total do projeto mostrado em uma
tela da ferramenta EA, conforme apresentado na Figura 4.
Os campos alimentados aplicam clculos da tcnica de UCP,
trazendo o total de UCP, de horas e o custo.
As empresas de software podem trabalhar como base de custo

o esforo, o que comum nas empresas que no trabalham com
implementaes de evoluo de produtos, onde o pagamento
realizado mensalmente pelos clientes. Nesse caso, projetos no
costumam ser um novo produto e sim pacotes de solicitaes
(requisitos) de melhoria. Essa abordagem se refere ao GPR4 (At
o nvel F) O esforo e o custo para a execuo das tarefas e
dos produtos de trabalho so estimados com base em dados
histricos ou referncias tcnicas.
Para realizar o clculo de custo deve ser levantado o custo
de cada hora de todos os recursos utilizados, destacando que
a moeda utilizada pode ser fictcia.
Na Tabela 5 considerado o papel de cada colaborador para
calcular o custo de mo de obra, estando adicionada j a infraestrutura utilizada por esses. Cabe a cada organizao adotar a
considerao de clculo de recursos; podendo serem inseridos
recursos adicionais como sala de reunio e multimdia.
Como sugesto para clculo pode-se criar uma planilha
onde todas as tarefas a serem executadas sejam informadas,
compatveis com EAP e ciclo de vida, onde para cada tarefa
o gerente de projeto informa o recurso necessrio e o tempo
a ser gasto, lembrando que o custo apresentado no exemplo
por hora.
Ao informar o recurso e o esforo em horas planejadas,
conforme Tabela 6, na coluna custo ser calculado o custo
conforme valor e tempo estimado, como descrito no GPR8
(At o nvel F) Os recursos e o ambiente de trabalho
necessrio para executar o projeto so planejados. O guia
de implementao do MPS.BR ainda refora que todos os
recursos precisam ser explicitamente planejados, mesmo os
j considerados como existentes e disponveis ou que sero
compartilhados com outros projetos, uma vez que se trata da
sua alocao para uso.
21
Pode ser observado que existe um campo que estima o

nmero de UCP planejado para o projeto, onde o mesmo
convertido para horas que devem ser distribudas entre as
atividades e sendo subtradas das horas totais.
Conforme valor estipulado por hora a cada recurso e tempo a ser gasto na execuo de determinadas tarefas, deve
Nmero de UCP
173
N de Horas estipulada
N de Horas restante
Pacote de Trabalho Atividade

1. CONCEPO
Recursos
Atividades realizadas e monitoradas pelo GPP
4%
Ger. de Portflio
ser totalizado o valor previsto como custo. Nesse pode ser

inserido percentual lucrativo.
Como o esforo calculado por papel executado, o colaborador a ser alocado deve ter o perfil do papel a ser exercido pelo
mesmo, ou seja, deve existir uma base de dados onde o gerente
de projeto consulte currculos de colaborador e possa planejar
treinamentos necessrios, conforme GPR7
519
Os recursos humanos para o projeto so
planejados considerando o perfil e o co93,96
nhecimento necessrios para execut-lo.
Esforo/Hrs
Custo/Unidade
Na base de dados tambm deve existir o
0,48
que cada colaborador necessita para exer20,28

1216,8
cer determinado papel.
Total
20,28
1216,8
2. PLANEJAMENTO
1%
3,73
Cronograma
Define Ciclo de Vida
Ger. de Projetos
0,37
22,2
Define EAP
Ger. de Projetos
0,39
23,4
0,7
42
Total
1,46
87,6
25%
50,95
O MPS.BR refora a importncia de se ter

o cuidado de manter a coerncia entre ciclo
de vida, EAP, estimativas e cronogramas.
Existem vrias ferramentas que permitem criar um cronograma para o projeto,
com as atividades e responsvel, tambm
informando o tempo previsto para concluso. Lembrando que as atividades
devem ser organizadas na ordem de
execuo, ou seja, conforme fases de ciclo
de vida definido, sendo identificado no
cronograma marcos do projeto.
No exemplo apresentado na Figura 5,
so mostradas tarefas registradas pela
ferramenta DotProject, indicando o criador,
usurios vinculados tarefa, tambm o
percentual executado da tarefa, data de
incio, encerramento e durao, permitindo
ao usurio acessar as tarefas e informar
andamento da tarefa.
Os marcos devem ser definidos no planejamento do projeto (ver Figura 6). No
cronograma o marco deve aparecer com
durao de 0 hora, por no tratar de uma
atividade, mas de um ponto no cronograma. Uma alternativa ao gerente de projeto
Atualizao de cronograma e tarefas iniciais de anlise Ger. de Projetos

3. ANLISE
Anlise de requisitos para implementao
Analisar Requisitos para Implementao
req 1- PEDIDO DE VENDA PY
Ger. de requisitos
0,35
14
req 2- COMPRAS COM PAGAMENTO EM ABERTO
Ger. de requisitos
1,45
58
Esclarecer dvidas com o Fornecedor de Requisitos

req 1 - PEDIDO DE VENDA PY
0
Ger. de requisitos
0,5
Analisar se solicitao implementvel

0
Ger. de requisitos
0,3
Valida Requisitos
Ger. de requisitos
0,5
20
0
Ger. de requisitos
0,5
....
Atualizao de escopo
... (todas as atividades seguem sendo distribudas...)
Tabela 6. Planilha de clculo
Figura 5. Cronograma do projeto
Figura 6. Marco do projeto.
22
12
0
Aceitao
20
20
planejamento
no planejamento criar um check-list com atividades que devem

estar concludas em cada marco para ento estar conferindo,
validando o planejado.
Para auxiliar na reviso dos marcos, conforme GPR17
Revises so realizadas em marcos do Projeto e conforme
estabelecido no planejamento, o gerente de projeto pode utilizar uma planilha que permita o planejamento do que deve
ser revisado e a execuo da reviso dos critrios planejados,
conforme Figura 7.
O cronograma do projeto, exemplificado na Figura 5, deve estar
coerente com o oramento, apresentado na Tabela 5. Dessa forma,
imprescindvel que no oramento seja incluso esforos adicionais e margem para imprevistos como registrado no GPR5 O
oramento e o cronograma do projeto, incluindo a definio de
marcos e pontos de controle, so estabelecidos e mantidos.
Processos de apoio
Existem processos que apoiam a gerncia de projetos, como
medio, qualidade, configurao, os quais devem ter
suas atividades planejadas
junto com a gerncia de
projetos, tendo o gerente
de projeto conhecimento
de todas as atividades a
serem executadas durante
o projeto como auditorias
e coletas de dados, armazenamento, privacidade de
dados e distribuio de informaes, conforme GPR9
Os dados relevantes do
projeto so identificados e
planejados quanto forma Figura 7. Planilha de reviso de marcos
Objetivo
Pblico Alvo
Canal/Evento
-Acompanhar as atividades
em progresso e prximos
passos
Equipe do Projeto
Reunio
Acompanhar os riscos
Equipe do Projeto
Reunio
Fornecer orientaes sobre

o projeto
Equipe Projeto
Reunio
Comunicar a Situao do
Projeto
Alta Gerncia
Documento
Email(disparado atravs da
ferramenta DotProject)
Gerente Projeto
Distribuidores
Escalar e/ou resolver

assuntos;
Receber novos
direcionamentos, decises,
etc.
Apresentao dos
Resultados
de coleta, armazenamento e distribuio. Um mecanismo

estabelecido para acess-los, incluindo, se pertinente, questes
de privacidade e segurana. Esse planejamento acontece junto
com o responsvel por cada processo e as atividades devem
estar registradas e previstas no cronograma, como apresentado na Figura 6, onde tarefas so alocadas e disponibilizadas
a responsveis.
Alm dos recursos serem identificados no projeto, tambm os
envolvidos devem ser gerenciados junto com suas atividades,
onde se destaca a necessidade de gerenciar a comunicao
de todos os interessados no projeto, atravs de reunies ou
comunicados, podendo ser criada uma matriz de comunicao, conforme Tabela 7, que identifica toda a comunicao
planejada dentro do projeto.
A matriz de comunicao permite o planejamento de
aes de comunicao de envolvidos, descrito pelo GPR16
O envolvimento das partes interessadas do projeto planejado, monitorado e mantido, salientando que o monitoramento
Data
Clique aqui para inserir
uma data.
Responsabilidade
Materiais Relacionados
Gerente Projeto
Registro dos tpicos da reunio na

ferramenta DotProject.
Gerente Projeto
Plano de Gerenciamento de Riscos
Gerente Projeto
Plano Projeto

uma data.
Gerente Projeto
Relatrio de Acompanhamento
Reunio

uma data.
Alta Gerncia
Email com assuntos da reunio
Email

uma data.
Gerente Projeto
Relatrio dos resultados do Projeto

uma data.
uma data.
Tabela 7. Matriz de Comunicao
23
dessas tarefas e o alinhamento ao planejamento do projeto

realizado pelo gerente de projeto.
Todos os recursos definidos devem ser monitorados, como
determinado pela GPR14 Os recursos materiais e humanos
bem como os dados relevantes do projeto so monitorados
em relao ao planejado, onde a cada desvio do projeto ou
replanejamento, os recursos tambm devem sofrer alteraes
correspondentes ao novo planejamento.
O projeto deve possuir um plano geral, o qual deve ter todo
o planejamento realizado no projeto e referenciando nesse
plano o planejado pelos processos de apoio - GPR10 Um
plano geral para a execuo do projeto estabelecido com a
integrao de planos especficos. Vale destacar que todos os
envolvidos devem estar cientes e comprometidos com o projeto,
conforme resultado GPR12 O Plano do Projeto revisado
com todos os interessados e o compromisso com ele obtido.
Esse comprometimento pode ser obtido atravs de assinatura
em ata de reunio ou o prprio plano impresso e assinado por
todos os envolvidos, ou por e-mail. O registro deve existir, cabe
organizao decidir a forma mais vivel.
Monitoramento do projeto
No planejamento do projeto devem ser registrados os riscos
potenciais do projeto, podendo ser considerado prioridade,
magnitude e probabilidade para os mesmos, tambm sendo
determinado um perodo para anlise durante o projeto.
Figura 8. Riscos possveis no projeto
Figura 9. Planilha de monitoramento de projeto.
24
Na Figura 8 exemplificada uma planilha de planejamento

de riscos, onde a organizao possui uma definio de impacto,
que o grau de gravidade a ser associado a cada risco e de
probabilidade, que o grau de ocorrncia do risco. Destacando
que o grau de Prioridade a ser tratado o risco o resultado
entre a relao entre Impacto e Probabilidade (Prioridade =
Impacto x Probabilidade).
Os riscos podem ser previamente registrados em histrico
organizacional. Na rea de planejamento de riscos, Figura 8,
o gerente de projeto registra o risco de Gerente ausente, onde
se associa um impacto de grau alto (5), e um probabilidade de
acontecer tambm alta (4). Isto resulta em uma prioridade de
tratamento 20. Alm disso, tem-se que a organizao define que
os riscos devem ser verificados pelo gerente de projeto a cada
10% do tempo previsto, ou seja, no exemplo, se o projeto estiver
planejado para concluso em 100 dias, a cada 10 dias deve ser
registrada a anlise desse risco, conforme definido no GPR15
Os riscos so monitorados em relao ao planejado.
A estratgia Mitigao deve ser planejada, a fim de que
durante o projeto o gerente de projeto saiba a estratgia planejada ao risco constatado, conforme GPR6 Os riscos do
projeto so identificados e o seu impacto, probabilidade de
ocorrncia e prioridade de tratamento so determinados e
documentados.
No andamento do projeto, caso algum desses riscos previstos
ou outros desvios aconteam, esses devem ser gerenciados.
planejamento
Pesos
40000
30000
0
Total
70000
Pesos
60000
1000
Peso base
10000
1000
100
10
RECURSOS
RECURSOS HUMANOS
CAPACITADOS
EXISTEM RECURSOS
NECESSRIOS
USABILIDADE DO PRODUTO
PROJETOS EM ANDAMENTO
Urgncia exigida por cliente conseguir ser

cumprida
Existe hardware compatvel para o
desenvolvimento
Existe capacitao disponvel para a
tecnologia a ser desenvolvida
SIM
SIM
Foram apontadas inviabilidades
NO
Tabela 8 . Planilha de critrios de viabilidade de projeto
Concluso
Empresas, principalmente as de pequeno e mdio porte,
acabam desistindo de implementar um mtodo de qualidade
no gerenciamento de seus projetos por acreditar que alteraria
sua forma de trabalho ou at mesmo pela necessidade de reaprender a forma correta, o que trata-se de um equvoco, pois
o modelo MPS.BR flexvel nas tarefas serem executadas
pela organizao, ou seja, apresenta resultados esperados
mas permite a empresa adotar a maneira compatvel com sua
realidade para alcanar o resultado.
Na gerncia de projetos, o modelo sugere atravs de seus resultados que todas as atividades a serem realizadas no projeto
sejam planejadas no seu inicio, at mesmo os provveis riscos
e atrasos, a fim de que no aconteam surpresas durante o
andamento at o trmino do projeto, ou desvios constantes
que resultem no atraso ou cancelamento do projeto.
O gerenciamento central do projeto cabe ao gerente de projeto,
o qual tem conhecimento de todas as atividades e tambm da
situao do projeto em todas as fases. Cabe a ele o monitoramento constante, analisando viabilidade, realizando tomada
de decises e gerenciando recursos e problemas encontrados
durante o andamento do projeto.
Referncias
KARNER, G. Use Case Points: resource estimation for Objectory projects. Objective
Systems
PREESMANN, Roger S. Engenharia de Software. So Paulo. Makron Books, 1995.
RUARO, Dirceu Antonio. Manual de apresentao de Produo Acadmica. Faculdade
Mater Dei. Pato Branco, PR: Faculdade Mater Dei, 2004.

Feedback
eu
edio
ta
D
s
SANTOS, Ivnia Ramos. MPS. BR Melhoria de software brasileiro, uma avaliao no

sudoeste do Paran. Faculdade Mater Dei. Pato Branco, PR 2008.
25
sobre e
s
Por isso aconselha-se ao gerente registrar todas as aes realizadas ou previstas em planilha de monitoramento. No monitoramento deve ser informada a ao a ser realizada para soluo
de problema identificado como apresentado pela Figura 9.
Na planilha de monitoramento do projeto, o gerente de
projeto registra a ao de monitoramento, o responsvel pela
ao, a causa desse registro, a data e o impacto, tambm o
prazo para soluo, o responsvel pela soluo, o status do
registro, as aes para soluo, a verificao do gerente de
projeto, a data de soluo e o tipo de registro realizado, como
exigido pelo GPR18 Registros de problemas identificados
e o resultado da analise de questes pertinentes, incluindo
dependncias crticas, so estabelecidos e tratados com as
partes interessadas.
Os problemas encontrados podem ter aes de soluo que
no alterem o planejamento do projeto, porm em alguns casos
pode ser necessrio desvios, ou seja, replanejamento do projeto,
como alterao no cronograma ou recursos, destacando que
esses desvios devem ser acompanhados at sua total concluso,
como resultado esperado pelo GPR19 Aes para corrigir
desvios em relao ao planejado e para prevenir a repetio
dos problemas identificados so estabelecidas, implementadas
e acompanhadas at sua concluso.
No incio do projeto e a cada desvio encontrado deve ser
verificado se o projeto continua ou no vivel baseando-se
nos critrios organizacionais, como pode ser observado na
Tabela 8.
O exemplo da planilha auxilia na verificao de viabilidade,
conforme GPR11 A viabilidade de atingir as metas do projeto, considerando as restries e os recursos disponveis,
avaliada. Se necessrio, ajustes so realizados. A inviabilidade
do projeto pode resultar na parada, ajuste ou cancelamento do
projeto, dependendo da deciso da organizao.
Caso seja necessrio algum replanejamento no projeto, esse
deve ser alterado tambm no plano geral do projeto, destacando que o que foi planejado deve ser monitorado, conforme
GPR13 O escopo, as tarefas, as estimativas, o oramento e o
cronograma do projeto so monitorados em relao ao planejado, para que os objetivos sejam alcanados, lembrando que
os outros planos de apoio afetados por alteraes tambm
devem ser replanejados.
Engenharia
Nesta seo voc encontra artigos voltados para testes, processo,
modelos, documentao, entre outros
Aplicando BPM na engenharia de software

A disciplina de BPM aplicada aos processos da engenharia de software

Apresentar, de forma simples, como o gerenciamento de processos de negcio (BPM) pode ser utilizado
na rea de engenharia de software, identificando e
sugerindo a utilizao das melhores prticas que a
disciplina prope.
E
Mircia Vinter Freire
mirceia.vinter@gmail.com
Certificada CBPP, Especialista em Qualidade e Governana de TI e Graduada em

Sistemas de Informao Profissional com
experincia na rea de engenharia de software e aplicao das melhores prticas de
mercado voltadas para o desenvolvimento
de sistemas, sendo os ltimos 6 anos dedicados s certificaes CMMI e MPS.BR.
Atualmente Coordenadora do Grupo de
Qualidade (SEPG) e Lder da Equipe de Processos na empresa baiana Avansys.
26
mpresas que desenvolvem software sentem a necessidade de

se tornarem mais produtivas e
consequentemente obterem melhores
resultados. O objetivo principal dessas
organizaes aumentar a efetividade
e eficincia dos softwares desenvolvidos,
para apoiar necessidades de clientes e
do mercado. O BPM (Business Process
Management) ou, em portugus, Gerenciamento de Processos de Negcio,
consiste em identificar/reestruturar
processos de negcio que auxiliem as
empresas na obteno de melhorias na
produtividade e gesto. As empresas
com a implantao de uma soluo BPM
podem alcanar melhorias significativas
e rentabilidade de investimento, reutilizando procedimentos atuais ou fluxos
de informao disponveis.
Este artigo apresenta como o BPM pode
ser utilizado na rea de engenharia de
software, identificando e sugerindo a
utilizao das melhores prticas que a
disciplina prope.
Engenharia de Software Magazine - Aplicando BPM na engenharia de software

Este artigo retrata algumas aplicaes de BPM
para projetos de desenvolvimento de software.
Apresenta alguns pontos importantes que devem ser observados para implantao de BPM
aliado engenharia de software, alm dos benficos que esta disciplina oferece.
BPM na engenharia de software:

No cenrio atual, existe uma preocupao contnua dos gestores com relao ao desenvolvimento do conhecimento e a busca de solues
para os problemas relacionados s reas de
engenharia de software das organizaes. O
Gerenciamento de Processos de Negcio, BPM,
uma abordagem disciplinada que apresenta
mecanismos de medio de desempenho considerando processos como um todo, do seu inicio
ao trmino.
Com base nisso, este artigo mostra como aplicar
as prticas de BPM na rea de engenharia de software, gerando benefcios para um projeto de
desenvolvimento de sistemas como o aumento
da produtividade e a reduo do retrabalho.
en gen haria
O que BPM?
Para o entendimento de BPM, necessrio compreender a
definio de processo de negcio. Onde o processo um conjunto determinado de atividades ou procedimentos executados
por recursos humanos ou no, que tem como objetivo alcanar
uma ou mais metas.
Os processos so iniciados por eventos especficos e apresentam um ou mais resultados que podem implicar no trmino
do processo ou na transferncia de um controle para outro
processo. Processos so compostos por vrias aes e operaes
inter-relacionadas com um objetivo anteriormente estabelecido, definindo o mtodo de trabalho numa organizao. J um
processo de negcio definido como um trabalho ponta a
ponta que agrega valor aos clientes. Destacando que o trabalho
ponta a ponta envolve todo o trabalho, ultrapassando os limites
funcionais necessrios para entregar valor aos clientes.
O Gerenciamento de Processo de Negcio (BPM) uma
abordagem disciplinada para identificar, desenhar, executar,
documentar, medir, monitorar, controlar e melhorar processos
de negcio automatizados ou no para alcanar os resultados
pretendidos consistentes e alinhados com as metas estratgicas
de uma organizao.
O BPM possibilita que uma organizao alinhe os seus processos de negcio sua estratgia organizacional, conduzindo
a um desempenho eficiente em toda organizao atravs de
melhorias das atividades especficas de trabalho em um departamento, na empresa como um todo ou entre empresas.
Valores, crenas, liderana e cultura

A disciplina de BPM determinada por um conjunto de valores, crenas, liderana e cultura que configuram os alicerces
de uma organizao. Estes elementos induzem e norteiam o
comportamento e a estrutura da empresa.
A organizao proporciona oportunidades para discusses,

crescimento profissional e pessoal, alm de formar apoio para
uma relao externa com os clientes, fornecedores e comunidade em geral. Estes valores, crenas, cultura e formas de
liderana, implicam no sucesso ou fracasso da empresa sob a
perspectiva financeira e organizacional.
O ciclo de vida BPM

A disciplina gerencial BPM pode ser especificada como um
ciclo de vida contnuo (processo) composto por atividades
integradas de BPM, que so realizadas de forma gradual e
interativa, incluindo planejamento e estratgia, anlise, desenho e modelagem, implantao, monitoramento e controle
e refinamento.
medida que os processos de negcio permeiam pelo ciclo de
vida, so capacitados ou limitados por vrios fatores, incluindo
os quatro fatores primrios de valores, crenas, liderana e
cultura. Observe a Figura 1.
Planejamento e estratgia
O ciclo de vida BPM inicia com a criao de um plano e uma
estratgia conduzida a processos para a empresa.
O plano iniciado com uma compreenso das metas e
estratgias da organizao, que devem ser desenhadas para
garantir valor agregado para o cliente. O objetivo do plano
prover uma estrutura para o gerenciamento contnuo de processos voltados para o cliente, assegurando o alinhamento e
integrao com a estratgia organizacional, tambm a pessoas,
processos e sistemas.
O planejamento tambm identifica papis e responsabilidades,
patrocnios da diretoria executiva, expectativas de medies de
desempenho, metas e metodologias. Nesse momento pode haver
anlise de mudanas organizacionais, caso se espere atividades
transformadoras nos processos.
Anlise de processos de negcio

A anlise de processos de negcio integra
vrios procedimentos e tcnicas com o
propsito de entender a situao atual dos
processos organizacionais no mbito de
metas e objetivos desejados, onde se busca
informaes dos planos estratgicos, mtricas de desempenho, modelos de processos
existentes e outros fatores, para alcanar o
entendimento completo dos processos de
negcio da organizao como um todo.
Desenho e modelagem de processos

de negcio
Figura 1. Ciclo de vida BPM
A atividade de desenho de processos tem

um enfoque intencional de como o trabalho
ponta a ponta acontece para agregar valor
aos clientes.
A ordem das tarefas documentada, incluindo definies de tempo, local e atores.
27
O desenho define a viso futura dos processos da organizao

e responde questes como: o qu, quando, onde, quem, e como
o trabalho realizado. Outra importante atividade garantir
que os indicadores gerenciais estejam implantados para medir
o desempenho e a conformidade dos processos.
No ciclo de vida BPM, as atividades de desenho podem
seguir pela padronizao ou automatizao das atividades
atuais, ou podem utilizar o redesenho ou transformao
radical do processo.
O entendimento dos processos de negcio inclui a atividade
de modelagem de processo e uma avaliao dos fatores que
preparam ou limitam o processo. Para organizaes mais
maduras, outros fatores podem ser explorados, como, fatores
ambientais, detalhes e excees aos processos de negcio.
Implementao de processos
Implementar processos de negcio concretizar seu desenho
aprovado em fluxos de trabalho documentados e verificados.
Tambm inclui a implementao de procedimentos e polticas
novas ou revisadas.
Ao iniciar as atividades de implementao, se admite que as
fases de anlise, modelagem e desenho definiram e aprovaram
todas as especificaes, por isso, apenas pequenos ajustes
devem advir na fase de implementao.
Monitoramento e controle dos processos

No ciclo de vida BPM, o monitoramento e medio fornecem
informaes importantes para avaliar o desempenho dos
processos de negcio. As mtricas devem estar relacionadas
s metas e ao valor da organizao. Essas informaes so
utilizadas para tomadas de deciso sobre melhorias no processo (por exemplo, insero de novas atividades ou excluso
de atividades existentes).
Refinamento de processos
Os processos de negcio devem continuar sendo medidos,
a fim de que essas mtricas sejam utilizadas pelos gestores
de processos na adequao dos recursos para alcanar os
objetivos esperados.
O refinamento uma fase responsvel pelo tratamento dos
ajustes e melhorias ps-implementao, com base nos indicadores e informaes importantes de desempenho.
Tipos de processos
Existem trs tipos de processos de negcio: processos primrios (tambm chamados de processos essenciais), processos de
suporte e processos de gerenciamento.
Os processos primrios so ponta a ponta, interfuncionais e entregam valor aos clientes. So compostos pelas atividades essenciais que uma organizao realiza para cumprir seu objetivo.
Os processos de suporte auxiliam processos primrios, geralmente considerando a gesto de recursos e/ou infraestrutura
demandada pelos processos primrios.
A principal diferena entre processos primrios e de suporte
que os de suporte no agregam valor direto aos clientes,
28
mas so imprescindveis e estratgicos para a organizao,

principalmente quando a capacidade efetiva para realizao
dos processos primrios aumentada.
Os processos de gerenciamento so utilizados para medir,
monitorar e controlar atividades de negcios. Esses processos
garantem que processos primrios, ou de suporte, atinjam suas
metas operacionais, financeiras, regulatrias e legais. Esses
processos no geram valor direto para os clientes, porm so
fundamentais para garantir que a organizao realize sua
operao de forma efetiva e eficiente.
Vantagens e Desvantagens
O BPM uma disciplina que favorece a implantao dos
modelos e certificaes de qualidade, como, CMMI, MPS.BR,
ISO 9001, pois um de seus conceitos a definio de processo.
Com os processos definidos e desenhados, acaba sendo simples
implantar as prticas e requisitos dos modelos de qualidade.
Alm disso, uma importante ferramenta de apoio s empresas inovadoras. Numa empresa orientada a processos, a
tecnologia aplicada s fases do BPM, modelagem, automao,
monitoramento e anlise, promove inovao por tendncias
naturais, por experincias e observao. BPM uma nova
cultura para gerir negcios.
A disciplina de BPM indica que as organizaes podem
obter melhorias operacionais e efetivas otimizando praticamente qualquer processo. Segundo a Gartner, a implantao
de BPM representa o maior ROI (Return of Investment) em
iniciativas de TI, apresentando 78% dos projetos com retorno
maior que 15.
Apesar das dificuldades nas implementaes, a viabilidade
tcnica e o retorno sobre o investimento de projetos BPM so
reais e podem ser comprovados. Entretanto, o processo de implantao envolve alguns desafios como, insero do conceito
de gerenciamento por processos na cultura organizacional e
integrao das atividades dos analistas de negcio e da equipe
tcnica que executa o processo.
Um dos mtodos para ultrapassar as barreiras relacionadas
cultura organizacional pode ser a intensificao de aes
voltadas para a institucionalizao e o aprendizado organizacional, como, treinamentos, seminrios, visitas e estudos
de caso de empresas que j implementaram BPM, entre outras. Sendo importante que esta etapa inclua no somente o
pblico interno da empresa, mas tambm clientes, parceiros
e fornecedores.
O que podemos aplicar de BPM na Engenharia de

Software?
A engenharia de software foca no software como um produto
desenvolvido em um conjunto de atividades (levantamento
e anlise de requisitos, projeto tcnico, codificao e teste),
chamado de processo.Um dos desafios da engenharia de
software solucionar o problema e deixar o cliente satisfeito
com o software desenvolvido.
Atualmente, as empresas tm buscado a aplicao do BPM
para a padronizao dos processos e, consequentemente,
en gen haria
o ganho de produtividade e eficincia. Alm desse possuir capacidade de integrao entre recursos humanos, fsicos e TI.
O foco da implantao BPM, na Engenharia de Software, deve
ser a melhoria dos processos de desenvolvimento de software,
para que as empresas possam obter os resultados esperados
do negcio, ou seja, aumentar lucratividade, satisfao dos
clientes, otimizao de custos, por exemplo.
Em relao ao desempenho da empresa e ao alcance dos
objetivos de negcio, o BPM auxilia na medio, anlise e aperfeioamento da gesto do negcio e dos processos, emprega as
melhores prticas de gesto de processos, como, mapeamento,
modelagem e documentao de processos, definio do nvel
de maturidade da organizao, plano de comunicao, automao, monitoramento atravs de medies, indicadores de
desempenho e o ciclo de melhoria contnua.
Implantao de BPM
A implantao de BPM se inicia levando em considerao a
organizao e seus processos de negcio pela perspectiva do
cliente. Ou seja, essa observao deve ser feita de fora para
dentro, com a mesma proporo que considerem os processos
de dentro para fora.
BPM permite a anlise, definio, execuo, gerenciamento
e medio deprocessos, envolvendo o suporte para a interao entre pessoas e aplicaesinformatizadas diversas. Ele
tambm define a padronizao dos processos de negcio,
objetivando reduzir o TCO (total cost of ownership - estimativa financeira projetada para avaliar os custos diretos e
indiretos relacionados ao investimento em um determinado
bem como, por exemplo, software e hardware) ereorganizar a
empresa, para otimizar desempenho, aumentando produtividade e eficincia.
A aplicao dessas prticas favorece a maximizao dos
resultados e da execuo dos processos, fazendo com que as
empresas obtenham otimizao de recursos, satisfao do
cliente e vantagem competitiva atravs de servios e produtos
com nvel de qualidade superior, tambm auxilia a empresa
no controle de seus prpriosprocessos.
Essa ampla forma de trabalhar com processos impe que as
organizaes troquem a abordagem vertical e departamental
de gesto por uma viso horizontal, agregando e otimizando
processos de negcio com os clientes, fornecedores e colaboradores, onde todos devem participar do desenho e redesenho
dos processos, a fim de definir formas de gerenciar os riscos,
indicadores e mtricas de desempenho.
A implantao de uma empresa com viso horizontal enriquece o trabalho em equipe, pois esto todos voltados para um
objetivo final que se refere ao produto. Em organizaes com
vises verticais, as estruturas departamentais so rigorosas
e as atividades so controladas por nveis hierrquicos, no
havendo um cuidado em analisar e verificar as interaes entre os setores funcionais e o impacto que cada departamento
exerce nos demais.
Quando a organizao no conhece seus processos de negcio
detalhadamente, isso pode dificultar o sucesso no alcance dos
seus objetivos, lembrando que melhorar o todo significa

melhorar cada parte de forma equilibrada e gradual.
A abordagem por processos indica quebrar o paradigma em
relao aos conceitos funcionais, verificando as necessidades
do cliente, tambm aprimorar e ampliar o processo sistmico
da organizao, desenvolvendo uma viso total e completa,
ao invs do pensamento linear.
Medio e BPM
Ao dedicar-se a abordagem sistmica e a gesto por processos, a empresa consegue analisar e estabelecer seus objetivos
estratgicos, podendo priorizar os processos mais crticos,
estabelecer indicadores que permitem medir o desempenho
e implantar projetos de melhoria contnua em seus processos.
Um exemplo quando o dono do processo pode estabelecer
indicadores para a rea de teste, como produtividade e percentual de retrabalho, analisar e identificar que talvez seja vivel a
automatizao do processo de teste, implantando ferramentas
e capacitando os analistas de teste.
As atividades de medio e a anlise do desempenho provm
feedback sobre as atividades de processo que podem auxiliar
nas tomadas de deciso pela alta gesto. As medies de
desempenho podem ser disponibilizadas atravs de reportes
baseados em informaes extradas dos pontos de controle dos
processos. So exemplos de mtricas que podem ser utilizadas
a produtividade, o tempo de concluso de atividades, o custo,
o retrabalho, os erros identificados pela clula de teste etc.
Novos papis na implantao de BPM

Outro ponto importante que implantar BPM em uma organizao no simples, nem rpido e requer mudanas de
comportamento das pessoas e comprometimento significativo
da organizao.
Novos papis e responsabilidades devem ser incorporados
como, dono de processo, analistas de processo, modeladores
e arquitetos.
importante termos pessoas responsveis pelo desenho dos
processos ponta a ponta interagindo com gerentes de funes
tradicionais (por exemplo: gerentes de requisitos, testes). Alm
disso, mudanas nas estruturas de governana so introduzidas, modificando a forma como as empresas tomam decises
e alocam recursos.
O BPM requer um comprometimento de cima para baixo da
organizao, desde a liderana executiva, que define e prov
suporte prtica, passando pela linha funcional de gerentes
que devem colaborar com os donos do processo no desenho
e execuo dos processos de negcio, at indivduos que frequentemente devem trabalhar em equipes que executam os
processos em nome dos clientes.
Tambm preciso dar ateno aos valores, crenas, liderana
e cultura, pois sem esse suporte improvvel que seja alcanado o sucesso da implantao do BPM na organizao. Uma
forte liderana influencia a cultura, estabelece estruturas,
objetivos e motivaes, e tem a competncia necessria para
propor mudanas e instituir um processo de sucesso.
29
30
Referncias
Livro Good to Great: Why some companies make the leap... and others dont ISSBN 9780066620992
Livro Business Process Management: Pratical guidelines to successful
implementations ISSBN 9780750686563
Link para o site oficial da notao BPMN
http://www.bpmn.org/

Feedback
eu
sobre e
s
Dos diferentes problemas enfrentados no desenvolvimento

de software, o aumento da produtividade e a eliminao de
retrabalho so preocupaes constantes.
Uma organizao efetiva e bem sucedida tem como um de
seus fatores de sucesso a capacidade de medir a performance
da execuo dos seus processos, e neste ponto que as prticas
de BPM podem auxiliar, tanto no objetivo da integrao dos
dados, quanto na medio do desempenho dos processos.
O BPM uma disciplina cujo objetivo identificar, modelar,
executar, documentar, medir e monitorar os negcios, automatizados ou no, e pode ser utilizada nas empresas a fim de
atingir resultados consistentes e direcionados de acordo com
os objetivos estratgicos da organizao. Essas atividades
so relevantes para que a empresa alcance ou se mantenha
na liderana, alm da obteno de vantagens competitivas e
retornos de investimento acima da mdia.
O gerenciamento de processo de negcio compreende
anlise e modelagem de processos, definio e redesenho de
processos, distribuio e alocao de recursos, medio tanto
da qualidade quanto da eficincia no contexto do processo e
otimizao do mesmo.
Os benefcios da implantao do BPM vm sendo expandidos
fortemente nas grandes organizaes, sendo considerado um
diferencial na forma de gerir negcios, pois o foco a gesto
da eficincia e da eficcia dos processos de negcios.
Como prtica do BPM, temos a institucionalizao da viso
horizontal da organizao, com seus processos interdepartamentais, utilizando uma viso sistmica e analisando o
D
s
Concluso
processo como um todo. Alm disso, temos o desenvolvimento

dos processos com o foco do cliente, identificando as suas
perspectivas; atividades de medio, estabelecendo metas de
desempenho para os processos; e definio e implementao
dos processos de negcio de cima para baixo, pensando no
processo de negcio como um todo.
Para uma implantao bem sucedida de BPM, necessrio
observar alguns pontos importantes como apoio da alta gesto, como, redesenho dos processos com o foco do cliente,
estabelecer os donos de processo, definir metas e medir o
desempenho dos processos.
A abordagem disciplinada de Gerenciamento de Processos
de Negcio, BPM, alm da anlise sistmica da organizao,
importante na anlise dos processos produtivos executados na
rea de engenharia de software, a fim de encontrar padres,
mtodos, solues tecnolgicas e ferramentas para auxiliar a
otimizao e melhoria dos processos de desenvolvimento de
software, considerando os resultados que atendero, de maneira satisfatria, todos os envolvidos no processo organizacional,
ou seja, clientes, participantes, fornecedores e parceiros.
edio
ta
A aplicao prtica da disciplina de BPM nas organizaes

visa a evoluo de uma situao atual, que chamamos de as
is, para uma viso otimizada, uma viso que os analistas de
processo denominam de to be, tornando-se uma organizao
gerenciada por processos.
As empresas tendem ainda a apresentar mais clareza em
suas operaes e, para isso, disponibilizam recursos e ferramentas adequadas para inter-relacionar os processos e medir
o desempenho de suas atividades, avaliando a nova forma de
pensar em processos.
Engenharia
Tcnicas de testes exploratrios

Entendendo as tcnicas e quando utilizar esse tipo de execuo
Clia Negrini
celianegrini@hotmail.com
Graduada na rea de TI, certificada pela

ISTQB(Certified Tester Foundation Level) e
pela ScrumAlliance(CSM- Certified Scrum
Master), com 13 anos de atuao na rea
de tecnologia, sendo os ltimos 8 anos
dedicados a Qualidade de Software. Atualmente coordenadora de testes e qualidade
na empresa VALID Certificadora Digital.
Apresentar as tcnicas de testes exploratrios de

forma a desmistificar esse tipo de teste. Para realizar testes exploratrios so necessrias tcnicas
que envolvem conhecimentos da rea de qualidade
de software.
qualidade de software uma

rea de conhecimento que objetiva garantir que o produto
seja entregue com o mnimo de defeitos atravs da definio e normatizao
de processos de desenvolvimento.
Seu principal objetivo garantir um
produto final que satisfaa s expectativas do cliente, dentro daquilo que
foi acordado inicialmente.
Contudo, para que a equipe de qualidade consiga auxiliar na garantia da
qualidade do software, necessrio
respeitar todas as fases que antecedem
uma execuo, e entre essas fases, temos
o planejamento dos testes. Na fase de
planejamento so criados cenrios de
testes, casos de testes e as massas de
testes necessrias para realizar uma
cobertura considervel no projeto que
ser testado, auxiliando a reduzir os riscos desse produto apresentar qualquer
problema quando estiver em uso.
Entretanto, mesmo com o planejamento efetuado, nem sempre o objetivo das
atividades de garantia da qualidade
so alcanados. Isto pode acontecer por

Testes exploratrios so uma boa alternativa
em busca da qualidade em projetos de software
quando o projeto tem um prazo muito apertado,
ou quando a documentao est desatualizada.
Alm disso, o teste exploratrio tambm deve
ser considerado como uma abordagem complementar a um teste planejado.
Tcnicas de Testes Exploratrios:

O teste exploratrio nem sempre bem entendido por todos os profissionais de TI, ora por
considerar que apenas testes exploratrios so
suficientes, ora por considerar que qualquer
um pode realizar um teste exploratrio. Veremos aqui que este tipo de teste de extrema
importncia e existe a tcnica, o momento e a
pessoa correta para execut-lo.
diversos fatores: ciclos de desenvolvimento curtos, projeto sem documentao, entre outros. Nesses casos pode
ser adotada uma tcnica denominada
Testes Exploratrios.
31
Teste exploratrio uma abordagem que oferece uma liberdade maior ao testador, de maneira que torna-se possvel interagir
com a aplicao da forma que considerar mais adequada e
utilizar as informaes obtidas que prov para direcionar os
testes dentro do cenrio existente, e assim, realizar as combinaes que julgar necessrias. Contudo, o teste exploratrio
no necessariamente executado de forma isolada. Pode ser
utilizado tambm como um teste complementar, ou seja, aps
a execuo de um teste planejado, realizada uma varredura na aplicao, realizando testes exploratrios para resgatar
bugs que tenham passado despercebidos e que tm seu grau
de importncia no projeto.
Apesar de poder ser utilizado para testes complementares,
os testes exploratrios geralmente so utilizados isoladamente.
Isso ocorre porque a abordagem exploratria a melhor maneira de testar um produto rapidamente para tentar garantir
o mnimo de qualidade possvel, quando o tempo no permite
um teste planejado.
Para entender como aplicar as tcnicas dos testes exploratrios, primeiramente importante entender o objetivo desse
tipo de teste, veremos aqui trs objetivos:
1. Obter uma compreenso de como funciona a aplicao.
Geralmente utilizado por novos testadores para auxili-los a
identificar pontos de entrada de testes e desafios especficos,
mas tambm, pode ser utilizado por testadores mais experientes com o intuito de explorar a aplicao para entender a
profundidade de suas necessidades de testes;
2. Expor as capacidades da aplicao. Auxilia a identificar
provas de que o software executa a funo para a qual foi
concebido e que satisfaz as suas necessidades;
3. Explorar a aplicao antes da liberao para realizao de
um teste planejado. Permite que a aplicao passe por uma
anlise inicial antes da liberao formal para a equipe de testes, possibilitando que sejam encontrados pontos vulnerveis
e suscetveis a erros antecipadamente.
Testadores experientes raramente executam suas tarefas
sem um planejamento prvio e uma estratgia de testes,
principalmente se aps uma anlise detalhada identificada a
complexidade da aplicao. Eles tendem a trilhar um caminho
que foi previamente estudado, o que faz com que encontrem
pontos mais sujeitos a erros.
A atividade de um testador est relacionada em realizar escolhas. Trata-se de compreender a complexidade da aplicao
no momento da execuo dos testes e a partir da anlise da
informao obtida realizar a melhor cobertura possvel.
Nesse contexto, esse artigo apresentar algumas tcnicas de
testes exploratrios para auxiliar os testadores nessas escolhas
e permitir que explorem a funcionalidade de uma aplicao
de forma mais segura e eficiente.
preciso conhecer o que ser testado

O primeiro passo para realizar um teste exploratrio obter
um conhecimento prvio da aplicao. Esse conhecimento
pode ser adquirido com um manual, com o cliente, com o
32
Engenharia de Software Magazine - Tcnicas de testes exploratrios
desenvolvedor, com o gerente de projeto, ou seja, com as

pessoas que possuem um entendimento do mesmo, mas
principalmente com quem tem um conhecimento do negcio
da aplicao. Sem esses conhecimentos ser difcil realizar
combinaes para realizar um teste exploratrio satisfatrio.
Considere para essa base de conhecimento o entendimento do
sistema legado, pois muitas vezes o legado mal compreendido
e pode conter bugs ou at influenciar em bugs que tero um
grande impacto para a organizao.
Um planejamento prvio necessrio

Sem a mentalidade adequada e orientao, os testadores
podem acabar vagando sem rumo pela aplicao a procura
por bugs e no conseguir realizar a melhor cobertura. como
explorar uma cidade turstica sem um guia. Voc conseguir
percorrer alguns lugares, mas poder deixar de passar por
pontos valorosos.
Por esse motivo, o planejamento para o teste exploratrio
sempre necessrio. Ele no se iguala ao planejamento dos
testes planejados, por ter uma cobertura mais ampla e no
muito especfica.
Para realizar esse planejamento, escolha um conjunto de cenrios como sendo pontos de referncia, defina uma ordem e
uma meta para cada um. A partir disso, voc ter seu mapa de
cobertura e conseguir acompanhar o seu progresso no decorrer dos testes. Considere nesses marcos no somente as partes
vitais da aplicao, mas tambm as partes menos acessadas.
Por exemplo, se considerarmos um e-commerce, alguns dos
cenrios possveis seriam os apresentados na Tabela 1.
Cenrios
Meta
Departamentos (Informtica, Finalizar ao menos uma compra em cada

Games, Bebs, etc..)
departamento.
Adicionar e Remover itens, aumentando e
Cesta de Compras
diminuindo quantidade.
Realizar buscas diversas e com variaes de
Busca
combinaes.
Logar, acompanhar o pedido j efetuado e
Login
um pedido novo.
Avaliar se os links do rodap do site esto
Rodap
direcionando para a pgina correta.
Ordem de
execuo
1
2
3
4
5
Tabela 1. Possveis cenrios de um e-commerce
Vale ressaltar que raramente as funcionalidades so independentes uma das outras, desta forma, realizar apenas testes
independentes pode impedir que bugs sejam encontrados,
uma vez que os recursos interagem uns com os outros. Por
exemplo, para um sistema de vendas, existe um sistema de
controle de estoque interagindo com ele. Se no momento do
teste o testador considerar apenas que realizou a compra e
no conferir se o sistema deu baixa no estoque, esse seria um
teste independente e no um teste integrado. Portanto, sempre
considere esse tipo de teste no planejamento. Essa tcnica ser
abordada no tpico Teste as Integraes.
en gen haria
Conhecer as tcnicas de qualidade de software

primordial
Os profissionais da rea de qualidade de software detm
o conhecimento de diversas tcnicas sobre como testar bem
uma aplicao. Entre elas, existem tcnicas como partio de
equivalncia (ler Nota do DevMan 1), anlise de valor limite
(ler Nota do DevMan 2) ou at mesmo tcnicas mais simples
como verificar se a aplicao funciona corretamente, ou
verificar se ela simplesmente no funciona. Um dado muito
importante alm de qualquer tcnica a experincia em teste
que o testador possui e o conhecimento prvio no software.
Contudo, fato que o testador realizar melhores escolhas no
momento da execuo dos testes.
Nota do DevMan 1
Particionamento de equivalncia
Esse critrio divide o domnio de entrada de um programa em classes de equivalncia a partir das quais os casos de teste so derivados. Ele tem por objetivo minimizar o
nmero de casos de teste, selecionando apenas um caso de teste de cada classe.
Nota do DevMan 2
Anlise de valor limite
Por razes no completamente identificadas, um grande nmero de erros tende a
ocorrer nos limites do domnio de entrada invs de no centro. Neste sentido, esse
critrio de teste explora os limites dos valores de cada classe de equivalncia para
preparar os casos de teste.
Esse profissional carrega uma base de conhecimento e informaes valiosas e capaz de realizar testes improvisados
quando no houver um planejamento prvio para a execuo
dos testes, por exemplo: inserir nmeros onde s deveria ser
possvel a insero de caracteres, realizar CTRL +V em um
campo que no deveria aceitar esse tipo de comando, inserir
um dado negativo em um campo que s deve aceitar valores
positivos e realizar combinaes de navegao (clicar em voltar,
onde geralmente se clica em comprar). Enfim, devem-se utilizar
todas as tcnicas possveis para realizao dos testes, pois elas
no podem ser deixadas de lado no momento da execuo dos
testes exploratrios.
Geralmente as tcnicas de como testar de forma eficiente a
aplicao (partio de equivalncia, anlise de valor limite, entre outras) so utilizadas para testes planejados onde possvel
detalhar diversas combinaes para um nico campo. Contudo, para testes exploratrios esse planejamento detalhado
no possvel, principalmente por causa do tempo, mas essas
tcnicas no devem ser esquecidas, pois auxiliam a identificar
bugs importantes. O que mudar ser a cobertura que ser feita
(testes exploratrios executados isoladamente nunca obtero a

mesma cobertura de um teste planejado), apesar disso, vlido
utilizar as tcnicas de testes no momento de uma execuo
exploratria. Dessa forma, o teste ser mais eficiente do que
simplesmente no utilizar nenhuma tcnica.
Porque to importante ressaltar a necessidade da execuo
do teste exploratrio por um profissional da rea de qualidade?
Isso acontece, pois na maioria das vezes em que um projeto entra em uma situao crtica quanto ao prazo de entrega e a rea
de qualidade no teve tempo hbil para realizar o planejamento
necessrio, os lderes de projeto solicitam o teste exploratrio
como sendo a salvao e com isso envolvem outras pessoas
para auxiliar os testadores. Entretanto, vlido explicitar
que um desenvolvedor realizando um teste exploratrio no
deter do conhecimento que um testador tem e por mais que o
teste realizado seja entregue na data desejada, no obter uma
cobertura to eficiente quanto se a execuo fosse feita apenas
por profissionais da rea de qualidade de software. Embora
vlido o auxlio, o risco da permanncia de bugs aumenta.
Considere o legado
Testar o cdigo legado (cdigo encontrado em sistemas antigos mas que continuam funcionais e normalmente demandam
atividades de manuteno) uma tarefa difcil de ser realizada,
pois quem o conhece na maioria das vezes so os desenvolvedores mais antigos que geralmente so de difcil acesso, no
h documentao sobre o projeto e raramente existe algum
manual explicando seu funcionamento.
Independente disso, o cdigo legado precisa ser considerado no momento da realizao do teste exploratrio uma vez
que pode esconder defeitos de grande importncia e impacto
para a organizao. Alm disso, ele no deve ser desprezado principalmente se estiver integrado ao sistema atual da
organizao.
Inicie fazendo um mapeamento das funcionalidades do legado e priorize quais so de maior importncia, isso ajudar no
momento da execuo, principalmente se o prazo de entrega
diminuir. Caso acontea, execute os testes dos pontos mais
importantes para os menos importantes.
Embora o software legado seja na maioria das vezes como
um campo minado, necessria essa priorizao, contudo,
se o tempo permitir execute tudo que for possvel, pois a
probabilidade de encontrar erros em sistemas legados grande, principalmente pela falta de manuteno. Muitas vezes,
preocupa-se muito com o sistema atual e se deixa o legado um
pouco de lado, embora no seja um problema generalizado,
o que ocorre com muita frequncia.
Reteste partes que tiveram correo de bugs

Todo software que passou por algum tipo de teste, j
teve alguma correo de bugs e essa informao muito
importante para os novos testes. Utilize-a no momento
de realizar os testes exploratrios, avalie mais demoradamente essa parte da aplicao, pois quando se trata erros,
a histria pode se repetir e importante testar novamente
33
essas funcionalidades. Avalie tambm as caractersticas da

aplicao que ficam ao redor do bug corrigido, para garantir que alm de no ocorrer mais, sua correo no afetou
nenhuma outra funcionalidade prxima.
Nem sempre os bugs que foram corrigidos so do conhecimento de quem realizar o teste exploratrio e o resultado
final dos testes pode ser influenciado se essa informao no
for considerada.
Para isso preciso tomar como premissa antes de realizar esse
tipo de teste uma busca em ferramentas de bug tracker - ferramenta de gerenciamento de bugs - da empresa. Com esta busca,
ser possvel identificar bugs corrigidos no perodo desejado
para realizar um teste focado nesses pontos, ou at mesmo
identificar os que nem foram tratados ainda. Dependendo da
ferramenta utilizada pela organizao, possvel detalhar
melhor a busca e listar todos os bugs de determinada tela, o
que facilitar ainda mais os testes e garantir a cobertura.
Teste as funcionalidades mais populares

Funcionalidades mais populares so aquelas que sero mais
acessadas pelos usurios, o caminho que ser mais percorrido.
Se considerarmos um site de uma organizao, esse caminho
poderia ser a pgina principal. O que estar na viso do usurio
mais facilmente? Poderamos considerar:
Os links das matrias principais esto funcionando? Esto
direcionando para a pgina correta?
As imagens so carregadas? Elas condizem com o enunciado
da matria?
Ao rolar at o fim da pgina, a pgina totalmente exibida?
O vdeo em destaque exibido com xito? O acesso ao email
ocorre com sucesso?
Esses so exemplos de testes em funcionalidades mais
populares. Da mesma forma que elas sero mais facilmente
acessadas, caso haja algum defeito eles tambm ocorrero com
maior frequncia. Considerando que um site atinge milhes
de usurios de forma rpida, o impacto de um bug desse tipo
em produo tambm seria grande.
Para saber quais so essas funcionalidades, busque informaes para identificar qual ser esse caminho. As pessoas que
detm esse tipo de informao so os usurios que costumam
acessar a aplicao frequentemente. O solicitante do desenvolvimento da aplicao pode ser a pessoa indicada e, se no for,
poder indicar quem ir auxili-lo.
Teste as funcionalidades menos populares

Funcionalidades menos populares so aquelas menos acessadas pelos usurios, mas que no devem ser desprezadas.
aconselhvel programar um tempo de teste para essas funcionalidades de acordo com a frequncia de utilizao, tanto
quanto possvel faz-lo.
Se considerarmos um e-commerce de grande visibilidade,
uma funcionalidade menos popular pode no ser to impopular assim, considerando que milhes de usurios tero
acesso a ela. Contudo, necessria uma anlise do projeto que
34
ser testado para avaliar o tempo que ser dispensado nessas

funcionalidades, se ter tantos acessos ou no.
Uma variao interessante sobre essa tcnica a realizao
de um teste misto, realizando uma combinao de caractersticas mais populares com as menos populares. provvel
que encontre problemas ao realizar um teste como esse, onde
caractersticas da aplicao interagem de uma forma que no
se esperava. Isso pode ocorrer porque os desenvolvedores no
imaginavam esse tipo de combinao e no realizaram um
tratamento adequado.
Avalie o Layout
Para um teste exploratrio completo, necessrio considerar o
layout apresentado. Para isso, preciso inicialmente comparar
o layout desenvolvido com o layout definido pelo cliente. Isso
vale desde o posicionamento dos campos at a aplicao das
cores, passando pela ortografia implantada.
O foco desse tipo de teste no a funcionalidade ou a interao como um todo, apenas uma anlise de interface. Nesse
momento possvel encontrar inclusive problemas de usabilidade. Para isso, utilize cenrios que manipulam dados e em
seguida exija que a interface do usurio seja exibida. Forar
que dados sejam exibidos e reexibidos o mais rpido possvel
permite que problemas com a atualizao da tela sejam efetivamente apresentados.
Nesse contexto, torna-se importante olhar alm da janela
atual ou controle que est focado no momento e passar a dar
ateno para todo o resto que a aplicao est exibindo no momento. Essa tcnica sugere que os testadores olhem um pouco
ao redor e no fiquem to focados na funcionalidade que est
sendo avaliada. Essa atitude auxiliar a obter a viso total da
aplicao e assim conseguir um resultado mais satisfatrio no
teste. Por exemplo: se ao utilizar uma aplicao apresentada
uma janela de pop-up, sua ateno ir se voltar para essa nova
janela, mas considerando a tcnica que acabamos de citar, necessrio tambm olhar para a tela atrs dessa janela de pop-up,
pois pode conter bugs sutis que podem passar despercebidos,
uma vez que o foco est na janela em destaque.
Existem vrias tcnicas para avaliar o layout apresentado,
mas tudo vai depender do requisito principal. Para isso,
necessrio saber a abrangncia da aplicao, quais sero os
usurios que tero acesso? Dependendo a resposta, possvel
criar cenrios como:
Alterar as configuraes do Sistema Operacional e realizar
um teste exploratrio para avaliar se os controles, cones e
textos so exibidos corretamente;
Execute a aplicao em um MAC (se o software tem como foco
atingir esse tipo de usurio) e avalie se houve quebra de layout;
Avaliar a aplicao em diversos browsers pode ser um teste
muito importante. Uma aplicao que funciona e tem um
layout agradvel no IE8 pode no ter o mesmo resultado se
utilizarmos o IE7 ou Firefox.
Apesar do grau de importncia de qualquer bug detectado
em um dos cenrios citados nessa tcnica, onde a aparncia
en gen haria
da aplicao pode levar a uma percepo do produto por parte

do usurio final, infelizmente esses tipos de erros so muitas
vezes considerados de prioridade baixa para correo.
A maioria dos bugs relacionados aparncia da aplicao
podem parecer inofensivos, mas dependendo do pblico
que ser atingido, os mesmos podem ter um grau de importncia alto.
Teste as integraes
Muitas vezes, quando testes isolados so realizados em
diferentes funcionalidades, no so identificados defeitos.
Contudo, ao se realizar testes integrados, os erros so revelados. justamente neste contexto que se tem a preocupao em
testar as integraes do software.
A premissa principal para esse tipo de teste verificar caractersticas diferentes interagindo umas com as outras. Aqui
esto alguns exemplos:
Alterar o cadastro de um produto para inativo e avaliar se
continua aparecendo na lista de produtos disponveis para
venda;
Realizar um agendamento de um cliente e verificar se aparece
na lista de clientes agendados;
Dar baixa em um produto em estoque e avaliar se continua
sendo exibido com a mesma quantidade para venda.
Para realizar um bom teste de integrao, os testadores de
software precisam aprimorar suas habilidades na seleo
e entendimento do momento exato e do ponto em que as
funcionalidades interagem. fato que a combinao de
duas ou mais entradas podem muitas vezes fazer com que a
aplicao falhe, mesmo quando o software no tem qualquer
problema com essas entradas individualmente. Contudo, os
testadores devem ser capazes de identificar quais entradas
interagem umas com as outras e garantir que apaream
juntas em um nico cenrio de teste, permitindo avaliar se
os comportamentos sero devidamente testados.
Considere como exemplo um e-commerce. Voc pode
realizar uma pesquisa independente de carro e ter como
resultado da pesquisa todos os artigos relacionados a esse
assunto. Da mesma forma, pode realizar uma pesquisa por
beb e ter como resultado todos os artigos de beb. Mas,
talvez, ao realizar uma pesquisa de carro e beb, ao invs
de ter como retorno carrinhos de bebe no seja retornado
nada embora na loja existam carrinhos de beb.
Faa questionamentos
Elaborar questionamentos difceis instiga o testador a
avaliar se a aplicao possui algum problema na lgica do
software e auxilia a detectar problemas na capacidade da
aplicao. A melhor forma de realizar esse tipo de questionamento buscar questes que forcem a aplicao a falhar.
Alguns exemplos de como podem ser feitos so:
O campo aceita caracteres especiais? Quais?
possvel inserir uma data invlida, tipo 31/02/2012? Qual
comportamento a aplicao deve ter ao inform-la?
Posso preencher alm do limite permitido?

Posso preenc her o lim ite de todos os campos do
formulrio?
O principal objetivo desse tipo de teste encontrar problemas na lgica do software, ou seja, como que vamos
fazer o software trabalhar to duro quanto possvel? Quais
recursos iro forar os seus limites? Que entradas e dados
far com que ele execute a maior parte do processamento?
Que entradas podem enganar suas verificaes de rotina?
Obviamente estas questes iro variar amplamente dependendo da aplicao em teste. Para um site de e-commerce,
por exemplo, podemos pedir 1000 itens de um nico produto? Posso mudar o carto de crdito que vou utilizar?
Ou posso mudar a forma de pagamento escolhida? Posso
informar um CEP de um endereo e informar um endereo
que no tem relao alguma com o CEP informado?
Realizando testes como esses, possvel encontrar lacunas
na aplicao que no seriam vistas em um teste comum, por
isso a importncia de questionamentos pensando em forar
o software a falhar. Qual seria o comportamento esperado
da aplicao para cada um desses questionamentos? Esses
questionamentos so passveis de se fazer no somente na
realizao dos testes exploratrios, mas tambm durante a
reunio de apresentao do projeto, ou em uma conversa informal com o desenvolvedor. Isso o ajudar a perceber o que
esperar da aplicao no momento da execuo dos testes.
Consuma tempo da aplicao

Para realizar testes exploratrios os testadores devem
considerar executar operaes que consumam tempo
de uma aplicao. Um bom exemplo so os recursos de
pesquisa; ao utilizar termos para uma busca mais longa
possvel que ela apresente algum problema no decorrer
do processamento.
As falhas que sero encontradas realizando testes como
esses esto relacionadas com a incapacidade da aplicao
de limpar os dados j processados e reiniciar uma nova
pesquisa. Esse teste permite ao testador ter certeza de que
qualquer ao que ele cancele deva ser capaz de ser concluda com xito. Esse teste deve ser considerado pois comum
esperar que um usurio ocasionalmente cancele alguma
ao da aplicao e em seguida tente novamente.
Nesse contexto, ao abrir uma pgina que inicia o carregamento de informaes e o usurio imediatamente clica
em Atualizar, uma ao cancelada e uma nova comea
imediatamente. Uma forma de realizar este tipo de teste
seria clicar no boto de Atualizar muitas vezes rapidamente.
Esta ao poder causar problemas de desempenho.
Existem outras formas de realizar testes como esse. O testador pode, por exemplo, apenas forar a exibio de uma
janela pop-up e verificar se possvel fechar a tela principal da
aplicao sem antes fechar a janela pop-up. O boto fechar da
aplicao estava habilitado? Se sim, deveria ser possvel fechar
sem apresentar qualquer anormalidade ou lentido.
35
Concluso
36
Links
Exploratory Testing Explained
http://www.satisfice.com/articles/et-article.pdf
Breaking the Tyranny of Form - Part 1
http://quality-intelligence.blogspot.nl/2012/06/breaking-tyranny-of-form-part-1.html
Testing Without a Map
http://www.developsense.com/articles/2005-01-TestingWithoutAMap.pdf
Taking a tour through test country: A Guide to Tours to Take On Your Next Test Project
http://www.testingeducation.org/BBST/testdesign/Kelly_Taking_a_Tour_Through_Test_
Country.pdf
An Introduction to Scenario Testing
http://www.testingeducation.org/BBST/testdesign/Kaner_ScenarioIntroVer4-1.pdf
Evolving Understanding About Exploratory Testing
http://www.developsense.com/blog/2008/09/evolving-understanding-about/

Feedback
eu
sobre e
s
A atividade de testar software complicada pela sobrecarga de possibilidades de variaes de entradas e caminhos
de cdigo a percorrer, alm dos dados apresentados e do
ambiente operacional. No importa qual abordagem de teste
ser utilizada, seja planejada ou exploratria, essa atividade
demasiadamente complexa para ser realizada completamente.
No entanto, as tcnicas de explorao tm a vantagem de que
elas encorajam testadores a planejar como testar e a utilizar
a informao obtida durante o teste para influenciar a forma
como o teste tradicional ser executado.
Apesar da atividade de teste ser complexa, o uso eficaz das

tcnicas de testes exploratrios pode ajudar a domar essa
complexidade e a contribuir para a construo de um software
de qualidade.
Contudo, vale ressaltar que embora os testes exploratrios
sejam efetivamente eficientes, dependendo do cenrio da organizao vale realizar uma combinao utilizando a abordagem
planejada somada a abordagem exploratria.
D
s
Realizar repeties indica que se deve entrar na mesma

funcionalidade vrias vezes. O objetivo realizar repeties,
seja ela entrar, sair, comprar, cadastrar, cancelar, copiar, colar, enfim tudo o que a aplicao faz de forma repetitiva. Por
exemplo, ao realizar a compra em um site de compras e depois
pedir o mesmo item novamente, verificar se um desconto de
compra considerado corretamente.
Outra forma inserir dados em uma tela, em seguida retornar
para a tela anterior, depois inserir dados novamente na tela.
Aes como essas no so na maioria das vezes pensadas pelos
desenvolvedores, pois para eles um usurio ir realizar aes
especficas e utilizaro o software na sequncia certa sem
retornar a ao anterior. Entretanto, importante considerar
que usurios cometem erros e precisam voltar atrs.
Se considerarmos um e-commerce, o usurio pode inserir
vrios itens em um carrinho e, aps solicitar para encerrar a
compra e ter sido direcionado para a tela de identificao, se
lembrar de que faltou inserir um item no carrinho e decidir
retornar ao invs de se identificar. Situaes como essa precisam ser previstas e tratadas. sempre melhor identificar
falhas de navegao como essa no perodo de testes, o que torna
esse tipo de teste importante para completar as atividades dos
testes exploratrios.
edio
ta
Faa repeties
Engenharia
Modelagem de processos de software com SPEM

Conhea a notao padro para modelagem de processos

Atualmente o SPEM (Software & Systems Process Engineering Metamodel) a notao padro da OMG (Object
Management Group) para modelagem de processos de desenvolvimento de software. Com seu meta modelo
possvel manter e apoiar uma ampla gama de fragmentos de mtodo e processos no desenvolvimento de projetos.
A forte ligao do SPEM com a UML (Unified Modeling Language) faz essa notao se destacar entre as abordagens
mais discutidas na literatura tcnica relacionada engenharia de processos.

Esse tema til para gerentes, arquitetos e engenheiros de software que buscam solues para aprimorar a modelagem de processos de software.
Modelagem de processos de software com SPEM:

Edson A. Oliveira Junior
Neste artigo sero apresentadas especificaes de processos de desenvolvimento de software utilizando

a linguagem SPEM, mantida pela OMG. Como forma de demonstrar os principais conceitos do SPEM ser
utilizado o Processo Unificado (PU) para representar um processo de software usual.
edson@din.uem.br
Professor de Engenharia de Software na

Universidade Estadual de Maring (UEM).
Doutor em Cincia da Computao pelo
Instituto de Cincias Matemticas e de
Computao (ICMC) da Universidade de
So Paulo (USP). Principais temas de pesquisa: linha de processo de software, linha
de produto de software, arquitetura de software e avaliao, mtricas, engenharia de
software experimental, modelos e metamodelos UML. Possui as certificaes Java:
SCJA, SCJP, SCJD, SCWCD e SCBCD.
Maicon Giovane Pazin

maiconpazin@gmail.com
Graduado em Informtica pela Universidade Estadual de Maring. Trabalha com

sistemas para Web, com experincia em
tecnologias como PHP, Javascript, CSS,
HTML5 e Java.
tualmente padres esto emergindo no escopo da modelagem

de processos. Alguns vindos
da evoluo de especificaes antigas,
enquanto outros so novos conceitos
introduzidos ao domnio. Nesse contexto
a Object Management Group (OMG) se
destaca como uma das mais relevantes
organizaes internacionais responsveis por manter padres abertos para
aplicaes orientadas a objetos.
Um dos principais padres desenvolvidos pela OMG o metamodelo SPEM,
sendo o SPEM 2.0 a notao padro da
OMG para modelagem de processos de

desenvolvimento de software e seus
componentes. Essa linguagem possui
forte ligao com a UML por meio do seu
metamodelo especificado na forma de
um modelo MOF (Meta Object Facility) e
do seu perfil UML utilizado para definir
um conjunto de esteretipos para representao de elementos de processos.
Nesse artigo sero apresentados os
principais conceitos envolvidos na especificao de processos de desenvolvimento de software utilizando o SPEM 2.0.
O Processo Unificado (PU) ser utilizado
37
como um processo de software usual para exemplificar o uso

do SPEM na modelagem de processos de software. Alm disso,
algumas ferramentas de modelagem que suportam o SPEM
como o EPF (Eclipse Process Framework) Composer e a Enterprise
Architect (EA) sero apresentadas.
Processos de Software
Um processo define quem est fazendo o que, quando e
como para alcanar certo objetivo. Na engenharia de software
o objetivo de um processo construir ou alterar um produto
de software j existente. Para um processo ser efetivo, ele
deve promover diretrizes para o eficiente desenvolvimento
de software de qualidade.
Quando processos so descritos e discutidos, suas atividades
(activities) so normalmente tratadas, como, por exemplo, na
especificao de modelos de dados, do projeto e da interface do
usurio, alm da ordenao cronolgica dessas atividades.
Quando complexas, as atividades podem incluir subatividades (sub-activities), as quais so tratadas nesse artigo como
passos (steps) para a realizao de tarefas no contexto de uma
atividade. Entretanto, descries de processos podem tambm
ser includas:
Produtos (Products) ou Artefatos, os quais so resultados
de uma atividade;
Papis (Roles), que refletem as responsabilidades de pessoas
envolvidas no processo;
Pr e Ps-condies, as quais so declaraes que so verdadeiras antes e depois de uma atividade de processo ter sido
promulgada ou um produto criado.
A definio de um processo de software deve estabelecer e
formalizar informaes sobre: as atividades e os papis responsveis, os artefatos de entrada e de sada que devem ser criados
ou mantidos em cada atividade, os procedimentos e ferramentas utilizadas, e o modelo de ciclo de vida utilizado.
H vrios anos, vem se tentando encontrar um processo ou
metodologia previsvel e repetvel que melhore a produtividade e qualidade dos produtos. Porm, no existe um modelo de
processo consolidado que atenda a todos os possveis domnios
de aplicao.
Um modelo de processo de software uma representao abstrata de um processo de software que representa um processo
a partir de uma perspectiva particular, de uma maneira que
proporciona apenas informaes parciais sobre o processo.
Alguns modelos de processos de softwares existentes na
literatura so: Modelo em Cascata, Modelo V, Prototipao,
Especificao Operacional, Modelo Transformacional, Desenvolvimento faseado - incrementos e iterao, Modelo Espiral
e Mtodos geis.
O Processo Unificado (PU) um dos processos de software
mais conceituado e pode ser entendido como um framework
de processo de desenvolvimento de software para a construo de sistemas orientados a objetos, centrado na arquitetura,
iterativa e incremental.
38
O Software and System Process Engineering Metamodel (SPEM)

O Software and System Process Engineering Meta-model (SPEM)
um framework conceitual usado para modelagem, apresentao,
gerenciamento, intercmbio e definio de mtodos e processos
de desenvolvimento de software.
A especificao formal da verso 2.0 do SPEM dividida
em duas partes:
O SPEM 2.0 Meta-model, que define todas as regras de estruturao, especificadas como um modelo MOF e reutiliza
algumas classes fundamentais da UML 2. Tambm define a
notao de diagramas de processo especficos;
O perfil do SPEM 2.0, que define um conjunto de esteretipos
da UML 2. Tal definio abrange apenas sua representao,
tornando-se dependente do SPEM 2.0 Meta-model para as declaraes semnticas e de restries.
O principal objetivo do SPEM 2.0 Meta-model manter e apoiar
uma ampla gama de fragmentos de mtodo e processos de
diferentes estilos, cenrios, nveis de formalidade, modelos de
ciclo de vida e comunidades para desenvolvimento de projetos. O perfil UML do SPEM 2.0 torna mais fcil a modelagem
de elementos de processos em ferramentas UML atravs da
definio de um conjunto de esteretipos.
Uma das principais caractersticas do SPEM 2.0 a possibilidade de especificao de diferentes processos a partir de uma base
de conhecimento independente de qualquer processo especfico.
Para isso, definida uma clara separao entre contedo e processo. O primeiro representa a base de conhecimento, enquanto
o segundo representa o processo especificado.
O contedo expressa elementos para a definio de Produtos
de Trabalho (Work Product Definition), de Papis (Role Definition),
de Tarefas (Task Definition), Categorias (Category) e Diretrizes
(Guidance). O processo permite expressar os elementos Atividade (Activity), Uso da Tarefa (Task Use), Uso do Papel (Role
Use), Uso do Produto de Trabalho (Work Product Use), Processo
(Process) e Diretriz (Guidance), representando a instanciao
de elementos a partir dos elementos definidos no contedo,
conforme Figura 1.
Figura 1. Terminologia chave definida nesta especificao mapeado para

o Contedo do Mtodo versus Processo
Engenharia de Software Magazine - Modelagem de processos de software com SPEM
en gen haria
A Figura 1 fornece uma viso geral de como os principais

conceitos definidos na especificao, esto posicionados para
representar contedo e processo.
Estrutura do metamodelo do SPEM 2.0

A estrutura do metamodelo do SPEM 2.0 composta por sete
pacotes principais, que se dividem em unidades lgicas.
As classes envolvidas no metamodelo so definidas em unidades de baixo-nvel, porm podem ser estendidas para largas
unidades, atravs de mecanismos que combinam pacotes
com adicionais propriedades e relacionamentos para atender
requisitos mais complexos na modelagem.
A Figura 2 apresenta os pacotes envolvidos na estrutura do

metamodelo do SPEM 2.0 e seus relacionamentos.
O pacote Core do metamodelo do SPEM 2.0 composto por
classes e abstraes que servem de base para todos os demais
pacotes. O pacote Process Structure define a base para todos
os modelos de processos e suporta a criao de modelos de
processos simples e flexveis.
O pacote Process Behavior permite estender as estruturas do
pacote Process Structure com modelos comportamentais. Entretanto, no define seu prprio comportamento, mas prov links
para modelos de comportamento externamente definidos.
O pacote Managed Content introduz conceitos para gerenciar
o contedo textual das documentaes construdas em linguagem natural. O pacote Method Content prov conceitos de SPEM
2.0 para usurios e organizaes para construir uma base de
conhecimento sobre desenvolvimento que seja independente
de qualquer processo especfico. O pacote Process with Method
define novas estruturas existentes para integrar processos
definidos com o pacote Process Structure com instncias do
pacote Method Content. Por fim, o pacote Method Plugin introduz
conceitos para projetar e gerenciar bibliotecas ou repositrios
de processos de larga escala, reusveis e configurveis.
Elementos de processos definidos pelos SPEM 2.0
Figura 2. Metamodelo do SPEM 2.0
cone
Os esteretipos existentes pelo perfil UML do SPEM 2.0 so utilizados para representar todos os elementos definidos pelo seu
metamodelo. Alm disso, utiliza cones para representa-los.
A Tabela 1 apresenta a relao de alguns cones com seus
respectivos esteretipos.
Diversos outros elementos de processos de software so
definidos pelo SPEM 2.0, mas nesse artigo esto sendo apresentados apenas os principais elementos utilizados para
modelagem de processos de software, conforme apresentado
na Tabela 1.
A partir dos elementos possvel identificar as atividades que
compreendem um processo de software por meio de Atividade,
tambm as tarefas envolvidas em cada atividade por meio do
elemento Uso da Tarefa, o passo-a-passo para realizao de
Esteretipo
Descrio
Activity
Elemento Atividade, que representa um agrupamento de elementos, tais como, outras instncias de Atividades (Activity), de Uso de Tarefas (Task Uses), de Uso
de Papis (Role Uses) e de Uso de Produtos de Trabalho (Work Product Uses).
TaskUse
Elemento Uso da Tarefa (Task Uses), que representa uma Tarefa sendo realizada por um Papel no contexto de uma Atividade.
Step
Elemento Passo (Step), que representa um dos passos necessrios para realizar a Tarefa.
WorkProductUse
Elemento Uso do Produto de Trabalho (Work Product Uses), que representa um Artefato consumido ou produzido no contexto de uma Atividade especfica.
RoleUse
Elemento Uso do Papel (Role Uses), que representa um Papel responsvel por uma ou mais Tarefas especficas.
Tabela 1. cones para representao de esteretipos do perfil UML do SPEM 2.0
39
determinadas tarefas por meio do elemento Passo, os papis

responsveis por realizar cada tarefa por meio do elemento Uso
do Papel e os artefatos consumidos ou produzidos em cada uma
das tarefas por meio do elemento Uso do Produto de Trabalho.
Ferramentas que suportam o SPEM 2.0

Atualmente possvel encontrar diversas ferramentas que
suportam o SPEM 2.0. Entre as opes disponveis existem ferramentas comerciais e gratuitas que possuem suporte completo
para a especificao de processos e diagramas baseados na
notao UML. Existem tambm ferramentas baseadas na notao UML que no possuem suporte padro para o SPEM 2.0,
mas que podem ser utilizadas para importar seu perfil UML,
como no caso da ferramenta MagicDraw.
Uma das ferramentas mais conhecidas o Eclipse Process
Framework Composer (EPF Composer), que trata-se de um editor
gratuito do SPEM 2.0 que utiliza uma abordagem baseada em
formulrios para definio do contedo de mtodo (papis,
tarefas, e produtos de trabalho) em uma IDE Eclipse. Nessa
ferramenta o contedo de mtodo configurado em padres
de processo usando vrias divises estruturais e modelos de
Figura 3. Workflow de Requisitos Modelado com SPEM 2.0
Figura 4. Workflow de Anlise Modelado com SPEM 2.0.
40
atividade. A ferramenta IBM Rational Method Composer (RMC)

a verso comercial do EPF Composer.
A Enterprise Architect distribuda pela Sparx System uma
ferramenta que oferece uma soluo completa para criar diversos modelos de processos de negcios, softwares e sistemas
de tempo real baseados na UML. Ela tambm possui suporte
para a verso 2.0 do SPEM permitindo que os usurios possam
modelar diagramas utilizando elementos de processos do
SPEM de forma rpida e simplificada.
O processo unificado de acordo com o SPEM 2.0

O processo unificado fornece diretrizes para desenvolver software com qualidade. Alm disso, pode ser especializado para
uma ampla classe de sistemas de software, diferentes reas de
aplicao, diferentes tipos de organizao, diferentes tipos de
nveis e diferentes tamanhos de projetos.
O PU organiza o desenvolvimento de software em quatro
diferentes fases: Concepo, Elaborao, Construo e Transio. Nessas quatro fases so realizadas diversas iteraes que
executam de forma linear diferentes workflows definidos pelo
processo, que so de Requisitos, de Anlise, de Projeto, de Implementao e de Teste.
A Figura 3 apresenta dois diagramas modelados na ferramenta Enterprise Architect, apoiada
pelo SPEM 2.0, que representa o workflow de
requisitos do PU. Os diagramas apresentam o
fluxo de atividades realizadas, assim como os
elementos de processos envolvidos em cada
atividade. O workflow de requisitos tem como
propsito essencial permitir descrever os requisitos de um sistema de forma que os stakeholders
entendam de forma clara o que o sistema deve
ou no fazer.
Observe que no diagrama da Figura 3 definimos
atividades de identificao de atores e casos de
uso, priorizao de casos de uso, detalhamento
de casos de uso e prototipao da interface com
usurio. Alm disso, so definidos tambm os
atores que participam das atividades: analista de
sistema, arquiteto, especificador do caso de uso,
projetista de interface com usurio, dentre outros.
Por fim, vale destacar tambm que o diagrama registra os artefatos consumidos e gerados durante
as atividades. Alguns exemplos so: glossrio,
caso de uso e descrio da arquitetura.
A Figura 4 apresenta a modelagem do workflow
de anlise, responsvel por refinar e estruturar
os requisitos capturados do sistema, tendo como
propsito fornecer um entendimento mais preciso dos requisitos e uma descrio que torne
fcil a construo e a manuteno da estrutura
de todo um sistema, incluindo a sua arquitetura.
Observe a definio de atividades como anlise
arquitetural, anlise de casos de uso e de classes.
Note tambm que os responsveis por executar
en gen haria
estas atividades so o arquiteto, engenheiro

de caso de uso e engenheiro de componentes.
Alguns dos artefatos gerados so a descrio
da arquitetura e das classes do projeto.
A Figura 5 apresenta a modelagem do workflow de projeto, responsvel por traduzir os
requisitos para as tecnologias que sero utilizadas no projeto, captura de requisitos sobre
subsistemas individuais, interfaces e classes,
decomposio do trabalho de implementao
em partes menores gerenciadas e captura inicial das interfaces entre subsistemas.
Observe que no diagrama da Figura 5 definimos atividades de projeto arquitetural,
projeto de casos de uso, projeto de classes e
projeto do sistema. Alm disso, so definidos
tambm os atores que participam das atividades: arquiteto, engenheiro de caso de uso
e engenheiro de componente. Por fim, vale Figura 5. Workflow de Projeto Modelado com SPEM 2.0
destacar tambm que o diagrama registra os
artefatos consumidos e gerados durante as
atividades. Alguns exemplos so: modelo de
anlise, requisitos suplementares, descrio
da arquitetura, dentre outros.
A Figura 6 apresenta a modelagem do
workflow de implementao, responsvel pela
construo do sistema a partir dos artefatos gerados pelos anteriores. Nesse workflow tambm
realizado o planejamento das integraes
do sistema em cada iterao do processo e a
criao dos testes dos componentes.
Observe que no diagrama da Figura 6 definimos atividades da etapa de implementao.
Para ela definimos as atividades de implementao da arquitetura, integrao de sistemas,
implementao de classes, realizao de testes
unitrios, dentre outras. Alm disso, so definidos tambm os atores que participam das
atividades: arquiteto, integrador do sistema
e engenheiro de componente. Por fim, vale Figura 6. Workflow de Implementao Modelado com SPEM 2.0
destacar tambm que o diagrama registra os
artefatos utilizados pelas atividades. Alguns
exemplos so: plano de integrao, modelo de implantao,
Neste processo destaca-se os artefato plano de teste, casos de
dentre outros.
teste, procedimentos de teste, modelo de testes e avaliao
Por fim, a Figura 7 apresenta a modelagem do workflow de
dos testes.
teste, responsvel por verificar o resultado da implementao do sistema. Dentre esses propsitos est o planejamento
Concluses
dos testes para cada iterao do processo, alm do projeto,
O SPEM 2.0 um dos principais padres desenvolvidos
implementao, integrao e execuo dos testes de forma
pela OMG para especificaes de processos. Atravs do seu
sistemtica, gerenciando os resultados obtidos.
metamodelo possvel realizar uma especificao completa
O diagrama da Figura 7 ilustra o processo de teste modede processos de desenvolvimento de software, enquanto que
lado. Suas principais atividades so: planejamento, projeto,
seu perfil UML fornece uma simplificao desse metamodelo.
implementao, execuo e avaliao dos testes. O principal
Tambm definida uma clara separao entre contedo de
ator envolvido nas atividades o engenheiro de testes. Por
mtodo e processos, permitindo o reuso de fragmentos de
fim, temos a definio dos artefatos utilizados e gerados.
processos pr-definidos.
41
Figura 7. Workflow de Teste Modelado com SPEM 2.0
A estrutura do SPEM 2.0 totalmente baseada na UML 2.0.

Seu metamodelo especificado na forma de um MOF enquanto que o perfil UML define esteretipos para cada elemento
de processo especificado pelo metamodelo, o que explica as
diversas ferramentas j existentes no mercado que suportam
esse padro de forma integral ou parcial.
Atualmente o SPEM 2.0 e as ferramentas relacionadas no
abordam a execuo do processo definidos pela linguagem.
Entretanto, diversas pesquisas tm sido publicadas com o
intuito de adaptar o SPEM para realizar essa tarefa.
Apesar da dificuldade de encontrar estudos sobre a validao
do SPEM 2.0 em casos reais, possvel verificar que seu padro
definido pela OMG disponibiliza uma forma organizada para
especificao de processos de desenvolvimento de software.
O exemplo de aplicao apresentado neste artigo mostra que at
mesmo um processo consolidado, como o caso do processo
unificado, pode ser especificado utilizando o SPEM 2.0.
Referncias
BENEDICTO, J.; ROSENBERG, I.; SOLER, I.; ARANA, N.; ESPINOZA, H. Analysis of Standard
Process Models. Online, 2010.
http://www.artemis-ediana.eu/documents/D63CM21_ATOSJB.pdf
ECLIPSE. Eclipse Process Framework Project (EPF).
http://www.eclipse.org/epf/
FUGGETTA, A. Software Process: a Roadmap. In: International Conference on Software
Engineering (ICSE), Limerick, Ireland. Anais. New York: ACM, 2000. p. 25-34.
IBM. Rational Method Composer. Online, 2012.
http://www-01.ibm.com/software/awdtools/rmc/
JACOBSON, I.; BOOCH, G.; RUMBAUGH, J. The Unified Software Development Process.
Ed. A.W. Longman. 1999, Reading: Addison Wesley Longman. 463, 1999.
NO MAGIC. MagicDraw. Online, 2012.
http://www.nomagic.com/products/magicdraw.html/
42
sobre e
s

OMG. Unified Modeling Language (OMG UML), Superstructure. online, 2011a.

http://www.omg.org/spec/UML/2.4.1/Superstructure/PDF/
Feedback
eu
edio
ta
D
s
OMG. Software & Systems Process Engineering Metamodel. Online, 2008.

http://www.omg.org/spec/SPEM
OMG. OMGs MetaObject Facility (OMG MOF). Online, 2011b.

http://www.omg.org/mof/
PFLEEGER, S. L.; ATLEE, J. M. Software Engineering: Theory and Practice. 4a Edio,
Publisher: Prentice Hall, 2009.
Nesta seo voc encontra artigos voltados para diferentes
abordagens de apoio ao desenvolvimento de projetos de software
VSS x SVN
Estudo comparativo entre as ferramentas Microsoft Visual SourceSafe 6.0 e
TortoiseSVN
Alan Antunes
alan.antunes@yahoo.com.br

Faculdade Mater Dei (2012).
Daniel Carlos Dvila

daniel@cdavila.net

Faculdade Mater Dei (2012). Atualmente
Programador na Empresa SAG Informtica,
trabalhando com Software ERP Agroindstrial, utilizando Delphi, T-SQL e PL-SQL
Interesse em Engenharia de Software e
Gerncia de Projetos.


empresa privada, professora na Universidade Tecnolgica Federal do Paran e revisora da revista Engenharia de Software.
Experincia gesto de processos de qualidade utilizando metodologia MPS.BR.
Robson Da Motta
robsondamotta@hotmail.com

Faculdade Mater Dei (2012). Experincia
em gerncia de configuraes e desenvolvimento de aplicaes mobile. Atualmente
desenvolvedor de softwares em empresa
privada, utilizando Delphi e T/SQL.
t ualmente as organizaes
trabalham com um grande
nmero de artefatos organizacionais e de projeto, os quais exigem
gerenciamento e controle de acesso de
seus usurios. Dessa forma, tornou-se
inevitvel a necessidade de uma ferramenta que auxilie a organizao nesse
gerenciamento.
O propsito do processo gerncia de
configurao estabelecer e manter a
integridade de todos os produtos de
trabalho de um processo ou projeto e disponibiliz-los a todos os envolvidos.
Os artefatos gerados pelo projeto ou
pela organizao precisam ser acessados
por diferentes interessados, gerando
verses constantemente.
As modificaes tambm so imprescindveis, o que exige a utilizao de
uma ferramenta que permita alm do
armazenamento, a gerao de baselines
(configurao formalmente aprovada
para servir de referncia ao desenvolvimento posterior do sistema), controle de
acessos e alteraes.
Para que todos os envolvidos, principalmente desenvolvedores, possam
cumprir suas tarefas, necessrio que a
ferramenta facilite a execuo de tarefas
e evite inconsistncias de arquivos.
Apresentar um comparativo entre as ferramentas

Microsoft Visual SourceSafe 6.0 e TortoiseSVN que
auxiliam na gerncia de configurao de projetos e
processos, controlando verses e integridade de artefatos, baseado em caractersticas das ferramentas
e na opinio de usurios.

Auxilia equipes de projetos na escolha de ferramenta compatvel a suas necessidades para auxiliar de forma produtiva na gesto de configurao.
VSS x SVN:
Hoje as organizaes trabalham com um nmero grande de artefatos, necessitando de
controle e gerenciamento de configurao. Para
isso, imprescindvel ferramentas que auxiliem
na agilidade e produtividade desse processo.
A ferramenta Microsoft Visual SourceSafe 6.0
e TortoiseSVN permitem uma rpida resposta
e deciso em relao a documentos do projeto,
porm comum a dvida de equipes na escolha
de uma dessas, ou na migrao de uma para outra, dependendo a deciso das necessidades das
tarefas e das caractersticas da equipe.
Neste cenrio, este artigo busca apresentar um estudo comparativo entre as

ferramentas Visual SourceSafe 6.0 (VSS)
e TortoiseSVN que auxiliam na gerncia
de configurao de projetos e processos,
43
controlando verses e integridade de artefatos. Para o comparativo, foram analisadas informaes tcnicas das ferramentas,
necessidades da gerncia de configuraes apresentadas pela
equipe de desenvolvimento de uma empresa de desenvolvimento de software localizada no sudoeste do Paran. Atravs
dos resultados deste trabalho, a organizao deve analisar e
escolher a ferramenta a ser utilizada, compatvel com sua realidade, buscando o aumento da produtividade de sua equipe
e a garantia da segurana de seus artefatos.
A fim de auxiliar na escolha de uma ferramenta que possa
atender as perspectivas de uma empresa desenvolvedora de
softwares, foi aplicado um questionrio a dez colaboradores,
usurios do software, com perguntas especficas sobre suas necessidades em relao a uma ferramenta compatvel, levantando
assim, critrios para a escolha que venha suprir necessidades da
organizao no processo de gerncia de configurao.
Cpias de segurana
As organizaes do segmento de software necessitam realizar
cpias de segurana de seus produtos para armazenamento e
para disponibilizao aos envolvidos - em diferentes estgios
de projeto, respeitando autorizao de usurios - sendo esse
procedimento conceituado como repositrio. As cpias podem
ser armazenadas em mdias, em servidores separados ou nas
nuvens por exemplo.
As cpias so divididas em global e incremental. Nestes casos,
uma cpia geral dos dados feita, aps isso, somente cpias
incrementais so realizadas dos arquivos modificados aps a
ltima cpia global. Neste tipo de repositrio, a vantagem
ter um alto nvel de segurana dos dados copiados e pode ser
usado em vrios tipos de dispositivos, mas a desvantagem
ter que lidar com vrias cpias incrementais necessitando de
vrias mdias de armazenamento.
A cpia, que tambm pode ser usada na forma de mirror (ou
espelho, em terminologia computacional, uma cpia exata de
um conjunto de dados, data set) e rsync (reversamente incremental - programa de computador utilizado em sistemas Unix,
para sincronizao de arquivos e diretrios entre duas localidades diferentes enquanto minimiza a transferncia de dados),
possui um conceito parecido ao modelo global e incremental,
mas neste modelo preciso somente uma cpia completa dos
dados. Aps isso, as cpias incrementais so aplicadas nas
cpias espelho e os arquivos modificados so movidos para a
cpia reversamente incremental. A desvantagem deste mtodo
no ser adequado para mdias de armazenamento removveis
(Pen Drives, CDs) por que cada cpia deve ser feita a partir da
cpia espelho dos dados.
produto pode ser usado para manter arquivos para qualquer

outro tipo de equipe.
O Visual SourceSafe suporta desenvolvimento de plataforma
hbrida permitindo edio colaborativa e compartilhamento
de dados. Ele projetado para manipular os problemas de rastreamento e portabilidade envolvidos na manuteno de uma
base de controle de origem, por exemplo, uma base de cdigo
de software, entre vrios sistemas operacionais.
Essa ferramenta apresenta caractersticas que possibilitam
salvar (check-in), editar (check-out) e cancelar alteraes realizadas em artefatos (undo check-out). Para ter acesso a esses
recursos basta usar o boto direto do mouse sobre determinado
arquivo que esteja dentro do repositrio do VSS:
Check-In: Processo de salvar as alteraes no repositrio;
Check-Out: Processo de marcar o arquivo para poder
editar;
Undo Check-Out: Processo de cancelar as alteraes feitas,
podendo escolher se deseja manter o arquivo modificado na
mquina ou substituir pela ltima verso do servidor;
Get Latest Version: Obtm a ltima verso do arquivo no
servidor e substitui a verso do mesmo arquivo que est na
mquina do usurio.
A aplicao apresenta uma interface elaborada com varias
opes de uso, exibe os diretrios dos arquivos com formato
de rvore e estes podem possuir vrios subnveis.
A Figura 1 apresenta a interface principal da aplicao. Na primeira vez antes de marcar um arquivo para edio necessrio
selecionar o diretrio que deseja copiar o mesmo para a mquina
do usurio. O arquivo fica destacado e s permitido a outro
usurio selecionar o mesmo arquivo se o usurio administrador
permitir que possa ser usado por mais de uma pessoa ao mesmo
tempo. Como comum nesse tipo de ferramenta, se o primeiro usurio der check-in no arquivo, quando o segundo fizer o
mesmo processo o sistema verifica a integridade. Se ambos os
usurios alteraram o mesmo trecho, um conflito ocorrer e isso
poder ser tratado atravs do merge (processo de mesclar dois
ou mais trechos selecionados para criar um nico registro).
Microsoft Visual SourceSafe

O Microsoft Visual SourceSafe trabalha com o sistema de
controle em nvel de arquivo, o que permite que vrios tipos de
organizaes possam trabalhar em vrias verses do projeto ao
mesmo tempo. Essa funcionalidade particularmente benfica
em um ambiente de desenvolvimento de software, onde ele
usado ao manter verses de cdigo paralelas. Entretanto, o
44
Engenharia de Software Magazine - VSS x SVN
Figura 1. Tela principal do Microsoft Visual SourceSafe 6.0
VSS x SVN
desen volvimento
No merge, o usurio pode escolher qual parte do arquivo

deve ser salva no repositrio. Aps montar a nova estrutura
do arquivo e no possuir mais conflitos o sistema substitui o
antigo arquivo pelo atual.
A cada check-in a ferramenta capaz de gravar um histrico
para cada alterao feita sendo que nele possvel adicionar
uma descrio como comentrio. Dentre os diversos recursos
que a ferramenta VSS apresenta, so citados os seguintes:
Disponvel para mltiplas plataformas incluindo Windows 95,
Windows 3.1, Windows NT para a Intel, MIPS e Alpha AXP
e Macintosh;
Armazena qualquer arquivo de texto ou binrio;
Conjunto de comandos intuitivos e facilmente dominados;
Projetos em ambiente cliente-servidor;
Sistema de segurana de forma que o usurio possa
customizar;
Rastreamento de histrico de arquivo ou projeto;
Pode manter mais de 8.000 arquivos em um nico projeto;
Facilidade em gerar relatrios com o histrico de reviso de
qualquer arquivo.
o menu acessado atravs do boto direto do mouse, conforme

pode ser observado na Figura 2.
Existem outros recursos disponveis na ferramenta, estas so

apenas algumas vantagens que merecem ser destacadas.
Ferramenta TortoiseSVN
O TortoiseSVN uma ferramenta livre Apache Subversion
incorporada ao Windows para controle de verso. Pode gerenciar arquivos e diretrios ao longo do tempo. Os arquivos
ficam armazenados em um repositrio central, sendo muito
parecido com um servidor de arquivos normal, exceto pelo fato
dele armazenar todas as alteraes feitas em seus diretrios.
Isto lhe permite recuperar todas as verses anteriores de seus
arquivos e examinar o histrico de como e quando seus dados
foram alterados e quem os alterou.
O Apache Subversion um sistema aberto de controle de
verso. Fundado em 2000 por CallabNet, Inc., o subversion
tornou-se um sucesso na ultima dcada. A Apache Software
Foundation desenvolve o projeto Subversion de forma livre.
um sistema genrico que pode ser usado para administrar
qualquer conjunto de arquivos, incluindo cdigo fonte.
Quando instalado, incorporado ao sistema operacional.
Para acessar suas propriedades, basta usar o boto direito do
mouse e escolher o que deseja. uma ferramenta livre e de
fcil manuseio, apresentando as caractersticas bsicas que um
software desse tipo precisa como:
Commit: o processo que salva as alteraes feitas no
repositrio;
Changed: o estado de marcado para o usurio poder
editar;
Unchanged: o estado de desmarcar o arquivo que estava
marcado para o usurio editar;
Revert: Volta o arquivo como era antes de editar.
O TortoiseSVN apresenta uma interface simples com poucas
opes disponveis na tela. Todas as funes de uso esto sobre
Figura 2. Opes da ferramenta TortoiseSVN
As funes apresentadas so acessveis quando pressionado

o boto direito do mouse sobre o arquivo ou pasta associado
ao TortoiseSVN. Funes mais avanadas podem ser acessadas
segurando a tecla Shift antes de usar o boto direito do mouse
em uma das telas do sistema (ver Figura 3).
O TortoiseSVN trabalha com cones diferenciados para mostrar como se encontra determinado arquivo, tornando fcil de
identificar o estado em que o arquivo se encontra na mquina:
se possui conflito, se est igual verso do servidor, se foi
modificado ou se existe apenas na mquina e no no servidor
de repositrio (ver Figura 4).
A cada commit, uma nova verso do arquivo criada, tornando possvel adicionar uma descrio sobre a alterao. Antes de
efetuar o commit, feita uma validao no arquivo em busca de
conflitos. Estes podem ocorrer quando dois usurios alteram o
mesmo arquivo e o ltimo a fazer o commit pode ser informado
de que um ou mais conflitos existem.
O TortoiseSVN exibe uma tela de edio de conflitos (Edit
Conflicts), onde o usurio escolhe determinado trecho do
45
arquivo que deseja manter e ao final, quando no possuir mais

conflitos, o arquivo salvo no repositrio.
Dentre os diversos recursos disponveis que o TortoiseSVN
apresenta, esto:
Interface integra;
Sobreposio de cones;
Interface grfica de usurrio;
Fcil acesso aos comandos do Subversion;
Submisso atmica;
Metadados Controlados;
Escolha das camadas da rede;
Manipulao consistente de dados;
Ramificao e rotulao eficiente;
Relatrios sobre histricos de arquivos por usurios ou
alteraes.
Alm destes recursos, existem outros que tambm oferecem

ao usurio um controle melhor dos artefatos do repositrio,
fazendo com que a ferramenta atenda as necessidades de
vrios pblicos.
Pesquisa
A fim de obter a opinio de usurios das ferramentas abordadas, VSS e SVN, foi realizada pesquisa de campo a dez
usurios da organizao que utilizou as duas ferramentas e
tinham dvida em qual definir.
Foi aplicado o questionrio sobre tpicos que costumam
ser discutidos na hora de escolher um dos softwares como, a
separao de arquivos utilizando cones e no que isso auxilia
nas tarefas, tambm foram coletados dados em relao vantagem de interfaces, recursos diferenciados das ferramentas,
relatrios, acesso por login e continuidade do software.
A anlise das informaes coletadas foi apresentada a gestores a fim de que fossem auxiliados na tomada de deciso.
Anlise
Atravs das respostas obtidas aps aplicar o questionrio
para os colaboradores da empresa que esto envolvidos de
forma direta no processo de utilizao da ferramenta, pode-se
notar que a escolha da ferramenta TortoiseSVN foi predominante para a maioria dos entrevistados.
O grfico da Figura 5 mostra a opinio dos entrevistados em
relao a separao de arquivos por cones.
Figura 3. Menu de contexto acessado pela janela de Reviso
Figura 4. Representao de classificao de arquivos no TortoiseSVN
46
Figura 5. Separao de arquivos por cones.
No grfico apresentado que 80% dos entrevistados acham

que a separao dos arquivos por cones distintos, presente no
SVN, vantajoso em relao ao VSS, ficando em apenas 20%
os que acham que separar por cones indiferente.
Em relao a vantagem de identificar arquivos por cones, o
grfico da Figura 6 mostra que 75% acredita que ele melhora
o entendimento do usurio.
J 25% dos entrevistados defende que isso agiliza a identificao dos arquivos. Vale destacar que o grfico da Figura 6,
apenas aos entrevistados que acham vantajosa a separao por
cones, conforme Figura 5.
VSS x SVN
desen volvimento
Em relao a interfaces elaboradas, o grfico da Figura 7

apresenta a opinio dos entrevistados em relao ao VSS ser
considerado como a ferramenta com interface mais elaborada
em relao ao TortoiseSVN.
Figura 8. Merge
Figura 6. Identificao de arquivos
Figura 9. Recursos para relatrios VSS.
Figura 7. Vantagens de interfaces
Dos usurios entrevistados, apenas 10% acham ser realmente

vantajosa, mas percebeu-se que isso predominante em equipes que j esto acostumadas a trabalhar com softwares que
possuem as mesmas caractersticas. Porm, 50% acham que
desnecessrio o sistema possuir uma interface bastante elaborada e 40% defende essa caracterstica como indiferente.
O grfico da Figura 8 destaca as caractersticas da funo
merge em ambos os softwares.
Nesta questo, 60% indicaram que o TortoiseSVN possua
a funo merge mais simples e 40% indicaram que as duas
ferramentas apresentam o recurso de forma igual.
O grfico da Figura 9 apresenta a opinio dos entrevistados
quanto aos recursos de emisso relatrios sobre os arquivos
do repositrio de dados do VSS.
Dos entrevistados, 30% informaram que o VSS atende s
necessidades, mas 60% disseram que o TortoiseSVN apresenta mais eficincia e somente 10% foram indiferentes a esta
questo abordada.
No grfico da Figura 10, pode ser observada a opinio dos entrevistados quanto a implicncia de usar uma ferramenta descontinuada o que o caso do VSS - para a gerncia de artefatos.
Figura 10. Implicncia do SourceSafe ser descontinuado.
Informaram implicar de forma significativa 60% dos usurios,

20% disseram que no implicam e 20% foram indiferentes.
A forma que o Tortoise separa seus projetos Branch/Tags
abordada no grfico da Figura 11.
Nesse caso, 80% dos entrevistados informaram que a ferramenta TortoiseSVN mais vantajosa devido a essa separao
e 20% foram indiferentes a respeito.
Em relao a existncia de um recurso para emitir relatrios
em ferramentas que fazem o controle de arquivos como o VSS
e o TortoiseSVN, o grfico da Figura 12 mostra a opinio dos
entrevistados.
47
Para esta questo, 80% dos entrevistados acham que uma

vantagem a ferramenta apresentar esses recursos e 20% foram
indiferentes.
Por fim, pelo grfico da Figura 13 possvel observar as
vantagens e desvantagens apontadas pelos entrevistados da
ferramenta SVN.
Em relao ao login, que no necessita efetuar ao acessar o
sistema, 70% acharam que uma vantagem, destes, 29% acham
que por haver apenas um usurio na estao desnecessrio
ter de fazer login a todo momento e 71% acham que um
ganho de tempo.
Por ltimo, tem-se que 10% dos entrevistados acreditam que

o SVN apresenta desvantagem por no necessitar de login,
devido ao controle que torna a aplicao mais segura e 20%
foram indiferentes em relao ao login.
Concluso
Os resultados de entrevistas foram apresentados a gestores,
que optaram por permanecer apenas com a ferramenta TortoiseSVN. A utilizao de cones para a classificao do status
dos arquivos foi uma das vantagens que torna a ferramenta
mais didtica e menos suscetvel a erro, o que tambm agiliza
seu uso.
A realizao de merge foi classificada como mais simples
de se realizar no SVN. Em relao ao branch, essa caracterstica presente apenas nessa ferramenta classificada como
sua principal vantagem por diminuir conflitos de arquivos,
ocorrncia de erros e por permitir o uso independente em
estaes de trabalho.
Os recursos relacionados a relatrios foram classificados
como mais eficientes no SVN. A continuidade da ferramenta
tambm foi abordada, sendo essa uma das principais desvantagens do VSS.
Assim, a ferramenta TortoiseSVN foi classificada por
usurios como a mais adequada para a implantao na
empresa abordada.
Figura 11. Vantagens Branch/Tags TortoiseSVN

Referncis
Apresentando o Visual SourceSafe.
http://msdn.microsoft.com/pt-br/library/3h0544kx%28v=vs.80%29.aspx
Executando tarefas bsicas no Visual SourceSafe.
http://msdn.microsoft.com/pt-br/library/aw4a9dsx%28v=vs.80%29.aspx
MANDELL. J, Microsoft Visual SourceSafe for Document Control in ISO 9000
Registration, Microsoft Corporation, Outubro 1995.
Subversion.
http://subversion.apache.org/
TortoiseSVN Manual do Usurio.
http://ufpr.dl.sourceforge.net/project/tortoisesvn/1.7.6/Documentation/TortoiseSVN-1.7.6-pt_BR.pdf
TECHNET. Descrio geral de cpia de segurana.
http://technet.microsoft.com/pt-pt/library/cc739983%28v=ws.10%29.aspx
Figura 13. Vantagem e desvantagem SVN.
48
VSS x SVN
Feedback
eu
sobre e
s

D
s
Usando o Visual SourceSafe.

http://www.macoratti.net/vss_vb.htm
edio
ta
Figura 12. Representao de relatrios para arquivos
Projeto de sistema para armazenamento de

interfaces
Um exemplo prtico de modelagem OO
Beatriz T. Borsoi
beatriz@utfpr.edu.br
Possui graduao em Cincias Habilitao

em Matemtica pela Faculdade de Cincias
e Humanidades de Pato Branco (1990), graduao em Tecnologia em Processamento
de Dados pela Faculdade de Cincias e Humanidades de Pato Branco (1992).
Franciele de Lima
francielli_dlima@yahoo.com.br
Acadmica do curso de Tecnologia em Anlise e Desenvolvimento de Sistema da Universidade Tecnolgica Federal do Paran.
Gssica de Wallau
Wgeh_13@hotmail.com


empresa privada, professora na Universidade Tecnolgica Federal do Paran.
Poliane de Souza
poliane.nardi@gmail.com
Apresentar conceitos de definio de interface e

um modelo de armazenamento para agilizar o
processo de produo e auxiliar com o mtodo de
usabilidade.
quipes de desenvolvimento de
software costumam no contar
com colaboradores especializados
em engenharia de software, principalmente na rea de IHC (Interao humano
Computador), logo, no conseguem
inserir em seus projetos tcnicas desse
segmento. Outra dificuldade est nos
prazos de entrega de projetos cada vez
mais abreviados, exigindo das equipes
adotarem fases mais curtas e objetivas.
Devido complexidade de interfaces,
para cri-las, necessrio conhecimento
tcnico, de negcio, de mercado e principalmente humano. Porm, na maioria
das organizaes de pequeno e mdio
porte, no existe equipe especialista, fazendo com que a definio e construo
de interfaces fiquem sob responsabilidade de desenvolvedores que comumente
no possuem tempo alocado suficiente
e conhecimento apropriado.
Outro problema atual a falta de preocupao com a usabilidade de software,
resultando em layouts fora do padro,
que no atendem as necessidades dos
usurios.

Para equipes que buscam atender os requisitos solicitados pelos usurios/clientes com
maior agilidade e qualidade, padronizando
layout e armazenando interfaces.
Repositrio para modelos de interface de

software:
Um aplicativo de software pode estar com seu
o cdigo livre de erros, estruturado em classes
e implementado adequadamente s regras de
negcio, mas no ser considerado satisfatrio pelo usurio, devido interfaces de baixa
qualidade, que no garantem interaes intuitivas, impedindo a execuo de tarefas do
usurio. Portanto, um repositrio de modelos
de interfaces previamente definidos auxilia na
entrega rpida de produtos padronizados.
A soluo apresentada neste artigo est

relacionada em chegar fase de construo do projeto com os layouts previamente criados e armazenados, conforme
padres estabelecidos, agilizando o desenvolvimento e os testes, aumentando a
qualidade de seus produtos finais.
49
Interface de interao do software

A interao do usurio com um sistema computacional dependente da forma de composio de interfaces, que exige que
sejam atendidos aspectos de usabilidade, considerando caractersticas de seus usurios e ambiente a serem implementados.
A criao de modelos de interface como formulrios, botes,
menus e outros, deve ser planejada pela organizao, ou seja,
pode ser terceirizada ou compor projetos da mesma, mas
devem ser priorizadas.
Os padres de interfaces devem respeitar tcnicas de engenharia de software e principalmente o perfil do usurio, por
isso uma anlise aprofundada deve ser realizada. fundamental que todos os envolvidos no projeto respeitem esses padres
e utilizem os modelos criados.
A criao de um repositrio para modelos de interfaces criados
pode auxiliar equipes a melhorarem a qualidade de seus softwares, por basear seu desenvolvimento em padres pr-estabelecidos, ou seja, alm de auxiliar programadores sem experincia e
conhecimento de desenvolvimento de interface, tambm mantm
padronizao de aplicativos distintos da organizao.
Nesse artigo foi projetado o armazenamento de modelos
pr-estabelecidos, sendo adotada no repositrio a rotina de
cadastro de um software. Contudo, h de se ressaltar que a
identificao de modelos cabe organizao, assim como o
padro adotado.
Composio de interfaces
A interface formada por componentes de hardware e de
software que definem a forma de interao do usurio com o
sistema, atravs de entradas e sadas de informaes.
As entradas so as aes que o usurio realiza ao interagir
com o sistema como fornecer dados e selecionar opes. As
sadas so resultados de aes realizadas pelo sistema e apresentados ao usurio como mensagem de validao de um
campo, um relatrio, a confirmao de insero de dados em
um formulrio ou a abertura de um aplicativo.
No processo de interao do usurio com o aplicativo, os
componentes que compem a interface podem atender a
um modelo de interao, referindo-se s regras que moldam
formas e padres utilizados na composio da interface e que
visam facilitar as aes de interao do usurio com o sistema,
definindo a usabilidade do mesmo.
Os componentes de hardware so utilizados para interagir
com os de software como, mouse, teclado, tela sensvel ao toque, impressora e monitor de vdeo. O software representa os
elementos computacionais de interao como caixas de texto e
botes. As regras relacionadas a esses elementos se referem ao
modelo conceitual de interao que define a forma e o contexto
em que a interao ocorre. As aes realizadas com esses elementos representam a interao do usurio com o sistema.
Exemplo de Interface
Um exemplo conhecido de interface a de cadastro, que assim como as demais rotinas, permite ao usurio enviar dados
50
para o aplicativo e receber informaes que so respostas s

suas aes.
Uma ao pode ser informar o cdigo de um cliente e receber
como resposta seus dados cadastrais. Pressionar um boto de
excluso e ter como resposta uma mensagem de confirmao,
ou ainda, acessar um link e ter como resposta o contedo da
pgina vinculada ao respectivo link.
A interface de usurio deve ser entendida como a parte de
um sistema computacional, onde o usurio entra em contato
de forma fsica (manipular), perceptiva (visualizar) e conceitual
(interpretar, processar e raciocinar).
Modelos de interao so caracterizados pelas maneiras como
um usurio interage com um sistema, podendo ser definido
como modelo de dilogo, porque por meio dele que o usurio
faz solicitaes ao aplicativo computacional e recebe respostas.
Os modelos de interao podem ser caracterizados pela maneira
como combinam estilos, tcnicas e padres de interao:
O estilo caracteriza um conjunto de maneiras de interagir
estabelecido ao longo do tempo em diversas aplicaes;
As tcnicas de interao compreendem as diferentes formas
como as interaes ocorrem. Cada estilo pode utilizar diferentes tcnicas de interao;
Os padres de interface se referem aos aspectos da interao, aparncia e comportamento que definem o que o usurio
visualizar e como deve agir.
O usurio precisa conhecer o modelo de interao para interagir com o sistema.
Repositrio de interfaces
Nesse artigo ser apresentada a modelagem de um sistema de repositrio de interfaces, que auxilia organizaes a
padronizarem interfaces e disponibilizarem na construo
de softwares.
Modelagem do sistema
A modelagem do sistema foi realizada utilizando a ferramenta Astah* Community e CaseStudio. O Astah* possui suporte para
a UML 2 (Unified Modeling Language), permitindo a modelagem
do sistema baseado na orientao a objetos.
A ferramenta CaseStudio foi utilizada para a modelagem do
banco de dados, por meio de entidades (tabelas) e relacionamentos entre elas.
O aplicativo se destina a armazenar modelos de interface de
software, focando-se em dois elementos, o programador e o
usurio. Sendo que para o programador, deve ser disponibilizada uma listagem de modelos, permitindo a sua utilizao
total ou parcial de acordo com as necessidades. Para o usurio,
possibilita escolher o modelo de interface para o sistema, ou
apresentar como prottipo.
A Figura 1 apresenta uma viso geral do sistema.
Pela representao, o modelo de interface o conceito central,
que apresenta o arquivo armazenado e o objeto de consulta.
Os atributos que caracterizam esse modelo de exemplo so:
rea (mdica, educao e financeira), nome (a identificao),
Engenharia de Software Magazine - Projeto de sistema para armazenamento de interfaces
desen volimento
descrio (complemento ao nome), autor (autoria do modelo),

editvel (indica se o modelo pode ser editado), plataforma (o
ambiente de aplicao do modelo), imagem ( o modelo grfico,
a figura em si), ferramenta (na qual o modelo foi elaborado)
tecnologia (linguagem, ferramenta ou outro que o modelo se
aplica ou na qual pode ser utilizado/editado), tipo (formulrio,
listagem, relatrio) e as palavras-chave que sero utilizadas
na busca ao modelo.
Os conceitos apresentados na Figura 1 auxiliaram na definio dos requisitos funcionais e no funcionais. Na Tabela 1
so apresentados requisitos funcionais identificados para o
sistema de repositrio.
Os requisitos no funcionais identificados esto apresentados
na Tabela 2.
A partir dos requisitos, foram definidos os casos de uso
representados na Figura 2.
Esses casos de uso se referem s funcionalidades do sistema
em termos de regras de negcio. De acordo com esse diagrama, o usurio Visitante pode consultar/pesquisar modelos de
interface armazenados no sistema. O usurio Padro, alm de
herdar as permisses do usurio Visitante, pode incluir modelos de interface. E o usurio Administrador pode realizar
todas as funcionalidades do sistema, incluindo a manuteno
de usurios.
Na Figura 3 est representada a sequncia de aes para pesquisar por um modelo de interface armazenado no sistema.
O usurio pode indicar vrias palavras-chave como requisito
para a busca de um modelo de interface cadastrado no sistema,
indicado pelo loop no diagrama.
Na Figura 4 est o diagrama de sequncia para cadastrar
uma interface.
Figura 1. Viso geral do sistema
Figura 2. Diagrama de casos de uso
Nome
Descrio
Cadastro de modelos de interface
So os modelos de interface armazenados no sistema.
Cadastro de plataformas
Refere-se ao sistema operacional, tipo de dispositivo ou plataforma.
Cadastro de reas
As reas so usadas para classificar os modelos.
Cadastro de tipos
Refere-se aos tipos de modelos de interface.
Cadastro de tecnologias
Diz respeito aos tipos de tecnologias nas quais o modelo de interface poder ser utilizado.
Cadastro de Ferramentas
Trata dos tipos de ferramentas utilizadas para elaborar o modelo de interface.
Cadastro de palavras-chave
So utilizadas palavras-chaves para classificar os modelos de interfaces.
Cadastro de autores
Utilizado para identificar o autor do modelo de interface.
Relacionamentos entre modelos e palavras-chave
Utilizado para associar palavras-chave a um modelo.
Relacionamentos entre tecnologias e modelos de interface
Utilizado para associar modelos de interface com as tecnologias nas quais cada modelo pode ser utilizado.
Cadastro de usurios
Cadastro dos usurios com acesso ao sistema.
Tabela 1. Requisitos funcionais

Nome
Descrio
Cadastro de modelos de interface.
Por padro estar marcada a opo No para o campo Editvel no cadastro de modelo de interface.
Acesso ao sistema
O sistema poder ser acessado por usurios no cadastrados para operaes de consultas. Para inclui, excluir e
alterar modelos necessrio que o usurio esteja logado no sistema.
Cadastro de usurios
Somente o administrador do sistema poder incluir e excluir usurios do sistema.
Tabela 2. Requisitos no funcionais
51
Nesse diagrama, a rotina apresentada a mesma da Figura 3,

porm mais detalhada, onde o loop, por exemplo, especifica
que a busca refere-se a palavra-chave.
J o diagrama de classes da Figura 5 contm as classes persistentes que representam os cadastros do sistema e as classes
fronteira e controladora. Essas tm o objetivo de proporcionar
maior segurana ao acesso aos dados do sistema.
No diagrama de classes, alm das classes fronteira e controladora, esto as classes usurios e permisses. As permisses
definem o tipo de usurio. Um usurio administrador pode
atribuir permisses de acesso a usurios cadastrados. As demais classes representam persistncia no sistema.
Figura 3. Diagrama de sequncia buscar interface
Figura 4. Diagrama de sequncia cadastrar interface
Figura 5. Diagrama de classes do sistema
52
Engenharia de Software Magazine - Projeto de sistema para armazenamento de interfaces
desen volimento
As classes representadas na Figura 5

que se referem aos cadastros so
apresentadas como tabelas no diagrama de entidades e relacionamentos
do banco de dados, apresentado na
Figura 6.
Por esse diagrama se verifica que
a classe Modelos_Interface a principal, que possui uma srie de relacionamentos como chave estrangeira
com outras tabelas.
Concluso
D
s
O repositrio modelado, quando

implementado, permite o armazenamento e a recuperao de artefatos de software, que so modelos
de interfaces.
O sistema de armazenamento
importante para a equipe desenvolvedora e para usurios. Os desenvolvedores contam como base para
consulta de modelos e para manter a Figura 6. Diagrama de classes do sistema
padronizao de sistemas. O usurio
pode validar requisitos por prottipos verificados atravs de
Referncias
interfaces pr-definidas.
ASTAH. Astah community.
A modelagem do repositrio utilizando orientao a objetos
http://astah.change-vision.com/en/product/astah-community.html
permite ter uma ideia real do sistema antes de o mesmo ser
implementado. Os diagramas representam a viso geral do sisCASESTUDIO. CaseStudio.
tema, permitindo visualizar as funcionalidades e interaes.
http://www.casestudio.com/enu/default.aspx
A engenharia de software demonstra o seu papel fundaEISENSTEIN, J.; VANDERDONCKT, J., PUERTA, A. Adapting to mobile contexts with
mental no desenvolvimento de software, sendo adotada tanto
user-interface modeling. Workshop on Mobile Computing Systems and Applications,
no desenvolvimento do repositrio, como tambm pelos que
p. 1-10, 2000.
adotarem o sistema.
Adotar layouts pr-definidos e a utilizao de repositrio
LEITE, J. C. Introduo ao projeto de interfaces de usurio.
permite representar exatamente como o software ser, sua
http://www.dimap.ufrn.br/%7Ejair/piu/apostila/cap1.pdf
complexidade. Tambm auxilia no gerenciamento de projetos,
MORAN, T. The Command language grammars: a represetantion for the user
por deixar estimar tempo, custo e esforo necessrio.
interface of interactive computer systems. International Journal of Man-Machine
Os modelos elaborados para representar o sistema so
Studies, vol. 15, p. 3-50, 1981.
independentes de linguagem de programao. A UML
fornece a linguagem para representar o software e foram
MOREIRA, A. A. Reuso de IHC orientado a padres concretos de interao e dirigido
complementadas por descries textuais a fim de facilitar o
por casos de uso. Dissertao (Mestrado em Cincia da Computao) Universidade
entendimento de analistas.
Federal do Rio Grande do Sul, Porto Alegre, 2007.
No diagrama elaborado que representa a viso geral do sisteSOUZA, C. S. de; LEITE, J. C.; PRATES, R. O.; BARBOSA, S. D. J. Projeto de interfaces de
ma, um conjunto de conceitos relacionados permite visualizar
usurio perspectivas cognitivas e semiticas. XIX Congresso da Sociedade Brasileira
os requisitos e as funcionalidades pretendidas. Na anlise,
de Computao, Rio de Janeiro, julho de 1999.
muitos desses conceitos se tornaro classes e entidades de
banco de dados e outros relacionamentos entre essas classes e
entidades. Outros conceitos servem apenas para entendimento
Feedback
eu
do contexto e das funcionalidades.
Os layouts alm de fornecerem suporte para a elaborao
de casos de uso, classes e tabelas, por exemplo, possibiPara isso, precisamos saber o que voc, leitor, acha da revista!
litam ao usurio conhecer o sistema antes mesmo de ser
desenvolvido, aumentando as chances de se ter um produto
com qualidade.
edio
ta
53
sobre e
s
Arquitetura orientada a servios

Contextualizando SOA
Bento Rafael Siqueira

bentor.siqueira@gmail.com
Mestrando em Engenharia de Software

(UFSCAR), Esp. em Engenharia de Sistemas
(ESAB), Bacharel em Sistemas de Informao (UNIFAFIBE), MCTS Windows Applications 4.0, MCTS SQL Server Development
2008, MCP Application Development Foundation. Atua como analista e desenvolvedor de software h 6 anos. Atualmente
desenvolvedor de software para o ramo de
aeroportos.
54
divergncias de comunicao
entre setores de negcios e
de TI. O que solicitado nem
sempre condiz com o que realmente os
usurios imaginavam. Para corporaes que buscam liderana no mercado
competitivo, h caminhos a serem traados. Para ser competitivo, no basta
ter tecnologia de ponta, necessrio
aperfeioar processos de negcios, ter
unio entre os setores e compreenso
de todos os processos envolvidos na
atividade empresarial.
A SOA (Arquitetura Orientada a
Servios) ajuda as empresas a estarem
preparadas para evoluir em tecnologia e
em rentabilidade, diminuindo restries
da tecnologia para os lderes de negcio,
tambm possibilita assegurar uma estrutura flexvel e reutilizvel.
De maneira simples, SOA uma abordagem de negcios para criar sistemas
de TI (Tecnologia de Informao) que
permitem alavancar recursos existentes, criar novos recursos e, principalmente, estar preparado para inevitveis
alteraes exigidas pelo mercado, obtendo mais produtividade e lucro para
a empresa.
Engenharia de Software Magazine - Arquitetura orientada a servios
O artigo trata da SOA (Arquitetura Orientada

a Servios), mais presente em organizaes
de mdio a grande porte, ou empresas que
buscam assumir uma posio em ascenso no
mercado competitivo.

Essa arquitetura til em organizaes que
utilizam variados tipos de sistemas, com diferentes tecnologias e fornecedores, sendo
imprescindvel o atendimento a requisitos
como escalabilidade, flexibilidade e interoperabilidade.
Arquitetura Orientada a Servios:

Neste artigo ser contextualizado SOA, considerando conceitos e boas prticas na modelagem de servios. Sero tambm apresentadas
formas de interao entre TI e negcios, diminuindo dificuldades existentes no desenvolvimento e na adaptao de implementaes e
regras de negcios em sistemas corporativos.
Para usufruir dos benefcios desta

arquitetura, necessrio investimento
de tempo e aprendizado. Atravs do
uso de SOA o entendimento entre os
lderes do negcio e a rea de TI facilitada. O principal item do SOA so os
servios que servem para denominar
desen volvimento
o relacionamento entre um provedor e um consumidor, que

possuem o objetivo de solucionar uma determinada atividade
em comum.
Cada servio pode ser definido como uma atividade especfica,
devido a identificao dos servios encontrados na corporao.
O mesmo pode ser comparado com o famoso brinquedo Lego,
onde se pode utilizar as mesmas peas para inmeras ocasies.
Um exemplo um servio para consulta de produtos..., que
criado apenas uma vez e pode ser utilizado em todo sistema.
O SOA auxilia na resposta e melhora de questes refletidas
em cenrios, como, O negcio amplo e complexo? O nicho
muda rapidamente? Nosso legado o centro do nosso negcio?
Nossos sistemas so flexveis? Podem ter mudanas atribudas?
As regras de negcios esto organizadas? Existe qualidade em
nossos dados?
Governana SOA
Toda empresa necessita de governana, para levantar, planejar, executar, controlar e aperfeioar processos e, consequentemente, gerar melhores resultados.
Governana significa garantir que as pessoas faam o que
certo, alm de controlar o desenvolvimento e a operao
de software.
Alguns pontos cruciais associados governana SOA so:
Polticas: definem o que certo;
Processos: reforam as polticas;
Mtricas: fornecem visibilidade e possveis reforos para
polticas;
Organizao: estabelece uma cultura que suporta o processo
de governana.
Processos tm que ser flexveis o suficiente para poderem
suportar atualizaes frequentes, devem ser o mais explcitos
possveis, para que a equipe acompanhe sua execuo.
Os aspectos tcnicos de um processo podem ser classificados
como, documentao, gerenciamento de servios, monitoramento e gesto de mudanas.
Como apresentado na Figura 1, existem duas formas para
implantao de governana SOA.
A forma Top-down, onde as requisies surgem dos presidentes, gerentes e executivos da empresa, j a Bottom-up
referem-se onde as requisies surgem de usurios, analistas,
programadores e, tcnicos.
Maturidade SOA
A Figura 2 mostra um modelo de maturidade SOA desenvolvido pela Sonic Software (uma empresa de desenvolvimento
de software).
Como pode ser observado, o nvel um representa a aprendizagem inicial e a fase de implementao do projeto. No nvel
dois so fornecidos servios que utilizam padres definidos,
como, governana tcnica de implementao SOA.
O nvel trs fornece servios dentro da parceria entre organizaes tecnolgicas e de negcio, buscando garantir que o uso
de fornecedores SOA esclarea responsabilidades de negcio.
Figura 1. Abordagem Bottom-up e Top-down
Figura 2. Modelo de Maturidade SOA da Sonic Software
Na sequncia, no nvel quatro, o foco a implementao de

processos de negcios internos e externos. J no nvel cinco
os processos de negcios so otimizados, de tal forma que o
sistema de informao utilizando SOA se torna o principal
sistema da organizao.
Alm deste modelo de maturidade, existe tambm a opo
desenvolvida pela IBM e conhecida comoServiceMaturity ModelIntegration (SIMM).Este modelo composto por sete nveis,
sendo eles (em ordem crescente de maturidade):
1. Silo: integrao de dados;
2. Integrado: integrao de aplicativos;
3. Modular: integrao funcional;
4. Servios simples: processo de integrao;
5. Composto servios: integrao de cadeia de fornecimento;
6. Servios virtualizados: infraestrutura virtual;
7. Dinamicamente configurveis: escalabilidade automtica.
Os nveis de maturidade SOA indicam o quanto a empresa
j est apta para levantar, planejar, implantar e controlar
55
processos e permite identificar a qualidade e o sucesso que

se ter em iniciativas para implantao SOA.
Servios
Embora a dificuldade em encontrar uma definio exata
para servio, seu principal objetivo associado em representar um passo natural da funcionalidade de negcio.
Em negcios, os passos de uma atividade de uma corporao
podem ser classificados como servios. Com todos os passos
sendo executados em sincronia, cria-se um processo gerando
resultados para outros processos.
Servio tambm pode ser definido como um ou mais
passos que usam mensagens para troca de dados entre um
fornecedor e um consumidor. Tecnicamente, um servio
uma descrio de uma ou mais operaes que usam (mltiplas) mensagens para trocar dados entre um fornecedor e
um consumidor, tendo como efeito comum o consumidor
obter alguma informao, modificar o estado do sistema ou
modificar o componente de processo.
Atravs de servios podem-se encapsular processos de negcios, onde cada processo ou parte de um processo podem
ser implementados atravs de servios.
Como apresentado pela Figura 3 possvel trabalhar com
estruturas complexas sem muitos obstculos de gesto.
Figura 3. Esquema dos nveis de encapsulamento
A Figura 3 apresenta nveis que um servio pode encapsular, onde as linhas primrias de cdigo so em uma determinada linguagem, que representam o passo-a-passo de
um determinado procedimento. J o mdulo procedural se
refere ao conjunto de linhas primrias de cdigo, tornando-se
uma funo ou procedimento que recebe valores e retornam
resultados.
A estrutura de Classe/Objeto a unio de vrios procedimentos e atributos responsveis pelas funcionalidades.
Os Componentes so a unio de vrias estruturas, formando
micro processos e os servios so a unio de vrios processos,
criando um macro processo.
As estruturas complexas podem ser representadas por
pequenos passos, podendo esses ser reutilizados em outra
estrutura que necessite da funo que esse servio proporciona, destacando que necessrio que um servio seja
independente e autossuficiente em seus objetivos.
A SOA traz como principal recurso o reaproveitamento de
cdigo, rotinas e base de dados, porque um servio pode ser
utilizado diversas vezes, em vrios momentos durante os processos de trabalho evitando redundncias e retrabalhos.
56
Classificao de servios
Servios podem ser categorizados em trs grupos, demonstrados na Figura 4.
Os servios bsicos, tambm conhecidos como corporativos, so aqueles que disponibilizam uma funo de
negcio bsica.
Os servios bsicos podem ser subdivididos em servios de
dados, como, criar cliente, alterar endereo de cliente, criar
conta, retornar lista de cliente e servios de lgica, como,
retornar se um ano bissexto, definir datas vlidas para o
sistema. Aps estabelecer servios bsicos obtida a SOA
Fundamental.
Figura 4. Estgios de Expanso SOA
Servios intermedirios, tambm conhecidos como servios

compostos, so os que fazem um trabalho de orquestrao
de servios. Como em uma orquestra musical em que o maestro tem vrios instrumentos (servios) para orquestrar, os
servios compostos utilizam os servios bsicos para obterem
resultados. Aps estabelecer servios compostos obtida a
SOA Federativa.
O processo de Servios de Processos a unio de servios
compostos, definindo um determinado processo que tem estado. Assim, diferentemente dos servios bsicos e compostos,
os servios de processos guardam estados no decorrer de sua
execuo, podendo trabalhar com o fluxo. Um exemplo pode
ser mencionado um carrinho de compras de sistema de ecommerce, onde durante o processo de compra vrias adies,
alteraes e excluses no mesmo so realizadas podendo-se
no fim efetuar ou no a compra.
Estabelecido servios de processos obtida a SOA Habilitada para Processos.
A Figura 5 apresenta os trs estgios de expanso de servios
de uma forma mais detalhada.
A existncia de backends (sistemas normalmente executados
do lado do servidor),que compe a principal camada da arquitetura, onde podem existir servidores de aplicao, banco de
dados, ERPs (Enterprise Resource Planning) etc. Nessa camada
necessrio todo cuidado e segurana de informao.
Os servios bsicos (Dados e Lgicos) efetuam o contato
com os backends. Tambm existem ESBs (enterprise service
bus) - barramento de servios corporativos, ou seja, uma
interface responsvel por prover conectividade, transformar dados, rotear dados, segurana, monitoramento,
dentre outras definies.
desen volvimento
Componentes podem ser unidos dinamicamente em tempo

real se comportando como uma nica aplicao, firmemente
acoplada.
O acoplamento fraco um conceito que visa lidar com escalabilidade, flexibilidade e tolerncia a falhas, permitindo
que seu uso permita eliminar dependncias, fazendo com
que a manuteno no traga impacto nas funcionalidades
j existentes.
Concluso
Consideraes para modelagem de servios
AECE, Israel. WCF Arquitetura, Desenvolvimento e Padres.

http://www.israelaece.com/post/WCF-Videos.aspx
ARSANJANI, Ali. IBM - SOA Maturity Model.
http://www.ibm.com/developerworks/webservices/library/ws-soa-simm/
BACHMAN, Jon. Sonic Software. SOA Maturity Model.
http://web.progress.com/pt-br/inthenews/soa-infrastructure-l-10202005.html
CHAPPEL, David A. Enterprise Service Bus. Sebastopol, CA: OReilly Media, 2004.
COND, L; GODINHO, R. Arquitetura Orientada a Servios WCF Boas prticas (do
levantamento, construo e hospedagem)
http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=1032415471&Event
Category=5&culture=pt-BR&Country=BR,Webcast,20/05/2009;s/d.
ECKSTEIN, Jutta. Agile Software Development in the Large. New York: Dorset
House, 2004.
ERL, Thomas. Arquitetura Orientada a Servios. Conceitos, Tecnologias e
Desenvolvimento. Upper Sadlle River, NJ: Prentice Hall, 2005.
HURWITZ, BLOOR, KAUFMAN e HALPER, Judith, Robin, Marcia e Fern. Arquitetura
Orientada a Servios SOA. Srie para Leigos. Rio de Janeiro, Alta Books, 2009.

Feedback
eu
57
sobre e
s
Os nveis de granularidade definem o quo especfico o

servio. Os processos que so definidos podem ser quebrados em vrios subprocessos efetuando uma determinada
ao do sistema.
Existem dois tipos de granularidade, sendo elas fina e
grossa. A modelagem baseada em granularidade grossa
serve para implantar poucos servios para vrios processos.
J a granularidade fina se refere a implantar vrios servios
para poucos processos. Deve ser salientado que quanto maior
a subdiviso, mais especficos so os servios e quanto mais
especficos so, melhor a manuteno, escalabilidade e
reutilizao dos mesmos.
Se os servios componentes se unirem e se separarem
facilmente, eles so de baixo acoplamento, isso , no
interligados como aplicativos tradicionais e por serem
codependentes, podem ser misturados e combinados com
outros servios componentes.
Quanto mais fraco o acoplamento, mais til e flexvel ser,
uma vez que poder ser combinado para diferentes processos.
Por exemplo, um servio que retorna listagem de clientes pode
ser utilizado em um mdulo de vendas, em um mdulo de
relatrios, ou em um mdulo de fornecedores.
Referncias
D
s
A transformao de dados inerentemente parte do barramento em uma distribuio de ESB, sendo os servios
de transformao, especializados para as necessidades das
aplicaes individuais ligadas no barramento, localizados em
qualquer lugar e acessveis de qualquer lugar do barramento.
Um ESB pode ser definido como uma resoluo de independncias entre as aplicaes, pelo fato da transformao
dada ser uma parte integrante. O ESB responsvel pela
interoperabilidade dos servios, no importando origem ou
destino do dado, tendo como principal funo fazer com que
consumidores e fornecedores consigam interagir.
A Figura 5 tambm apresenta a camada de orquestrao
(Estgio Federativo) e a camada de processos (Estgio Habilitado para Processos), onde o ESB como um tnel para o
consumo de servios e front-end.
edio
ta
Figura 5. SOA Habilitada para Processos
Ao longo deste artigo uma srie de benefcios possibilitados pelo uso da SOA foram apresentados, se destacando a
melhor interao entre a rea de TI e a rea de negcios da
organizao.
A implantao de SOA apresentou-se desafiadora, no sendo
possvel sua implementao totalmente imediato e sim gradual,
atravs de modelos de maturidade .
O uso da SOA pode expandir alm no desenvolvimento e
manuteno de softwares corporativos, pelo fato de se trabalhar com o conceito de servios bem definidos e fracamente
acoplados permite que ajustes sejam feitos mais facilmente ao
software elaborado, permitindo que a organizao se adeque
rapidamente s mudanas esperadas pelo mercado.
58

Edição56 2013

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Edição56 2013

Diunggah oleh

Hak Cipta:

Format Tersedia

Rodrigo Oliveira Spnola

Marco Antnio Pereira Arajo

Ano 5 - 56 Edio - 2012

Doutor e Mestre em Engenharia de Sistemas e Computao pela COPPE/UFRJ - Linha de Pesquisa

Eduardo Oliveira Spnola

Fale com o Editor!

definio e o gerenciamento de processos envolve uma srie de preo-

de um modelo de qualidade, a alcanar resultados esperados pelo modelo

cupaes que precisam ser consideradas em conjunto para o sucesso de

MPS.BR (Modelo de melhoria de software brasileiro) no processo de gerencia-

uma iniciativa de implantao de processos na organizao. Este cenrio

mento de projetos no seu primeiro nvel, G.

um tanto quanto complexo o tema de capa desta edio da Engenharia de Soft-

Alm destes artigos, teremos mais seis artigos nesta edio:

Gerenciamento de requisitos com Kanban

e complementares sobre iniciativas de definio e gerenciamento de processos.

Trabalhando com Scrum e UML

No artigo Modelagem de processos de software com SPEM ser visto como

Tcnicas de testes exploratrios

possvel especificar processos de desenvolvimento de software utilizando a

linguagem SPEM mantida pela OMG. Como forma de demonstrar os principais

conceitos do SPEM ser utilizado o Processo Unificado (PU) para representar um

Arquitetura orientada a servios

processo de software usual.

Desejamos uma tima leitura!

o gerenciamento de processos de negcio (BPM) pode ser utilizado na rea de

Equipe Editorial Engenharia de Software Magazine

11 - Trabalhando com Scrum e UML

31 - Tcnicas de testes exploratrios

37 - Modelagem de processos de software com SPEM

49 - Projeto de sistema para armazenamento de interfaces

54 - Arquitetura orientada a servios

Gerenciando requisitos com Kanban

De que se trata o artigo:

Em que situao o tema til:

Graduado na rea de TI e MBA em Gesto da Qualidade de Software pela FIAP.

om o surgimento das consultorias em desenvolvimento de

mento de requisitos visa melhorar a interao e

Gerenciamento de Requisitos com Kanban:

que buscam atender de forma eficiente o

Edio 56 - Engenharia de Software Magazine

da rea de processo de gerncia de requisitos do CMMI.

Figura 1. Exemplo de quadro Kanban

Figura 2. Exemplo de quadro Kanban

Para este nivelamento possvel limitar a quantidade de itens

Engenharia de Software Magazine - Gerenciando requisitos com Kanban

Estabelecer critrios para distinguir os fornecedores apropriados de requisitos;

SP2 Obter Compromissos com os Requisitos

A prtica explicada no pargrafo anterior torna a linha

Essa prtica especfica prope obter compromissos com os

SP3 Gerenciar as Mudanas de Requisitos

rea de processo de Gerncia de Requisitos do

SP1 Obter Entendimento dos Requisitos

Edio 56 - Engenharia de Software Magazine

SP4 Manter a Rastreabilidade Bidirecional de

SP5 Identificar Inconsistncias entre o Trabalho do

Durante essa pesquisa se notou a utilizao de um mtodo

Modelo Lean Six Sigma da empresa Black Belts

Aderncia da rea de Gerncia de Requisitos ao

Utilizamos neste artigo uma empresa de TI para realizao

Ao mapear todo o processo de trabalho dos Engenheiros do

Figura 4. Unidade de produo da empresa Black Belts Company

Engenharia de Software Magazine - Gerenciando requisitos com Kanban