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
66 Edio - 2014
Doutor e Mestre em Engenharia de Sistemas e Computao pela COPPE/UFRJ, Especialista em
Corpo Editorial Mtodos Estatsticos Computacionais e Bacharel em Matemtica com Habilitao em Infor-
mtica pela UFJF.
Editor
Rodrigo Oliveira Spnola Eduardo Oliveira Spnola
Colaboradores eduspinola@gmail.com
Marco Antnio Pereira Arajo Colaborador das revistas Engenharia de Software Magazine, Java Magazine e SQL Magazine.
Eduardo Oliveira Spnola bacharel em Cincia da Computao pela Universidade Salvador (UNIFACS).
Nicolli Souza Rios

Consultor Tcnico
Daniella Costa Nicolli Souza Rios
nicolli.devmedia@gmail.com
Jornalista Responsvel Formanda em Cincia da Computao na Universidade Salvador (UNIFACS), Gerente de Projetos da
Kaline Dolabella - JP24185 COMMIT Empresa Jnior de Computao da UNIFACS e Estagiria de Desenvolvimento de Software
Na Web na BAHIAGS. Faz parte do grupo de pesquisa em Engenharia de Software do Programa de Ps-
http://www.devmedia.com.br/revista-engenharia-de-software-magazine Graduao em Sistemas e Computao da UNIFACS.

Atendimento ao Leitor Fale com o Editor!

A DevMedia conta com um departamento exclusivo para o atendimento ao leitor. muito importante para a equipe saber o que voc est achando da revista: que tipo de artigo voc

Se voc tiver algum problema no recebimento do seu exemplar ou precisar de algum gostaria de ler, que artigo voc mais gostou e qual artigo voc menos gostou. Fique a vontade para

esclarecimento sobre assinaturas, exemplares anteriores, endereo de bancas de entrar em contato com os editores e dar a sua sugesto!

jornal, entre outros, entre em contato com: Se voc estiver interessado em publicar um artigo na revista ou no site ES Magazine,
entre em contato com os editores, informando o ttulo e mini-resumo do tema que voc gostaria
www.devmedia.com.br/central
(21) 3382-5038 de publicar.

Publicidade
Para informaes sobre veiculao de anncio na revista ou no site entre em
contato com:
publicidade@devmedia.com.br
Contedo sobre Agilidade, Artigo no estilo Prtico

06 Desenvolvimento gil: anlise sobre requisitos tradicionais

[ Mauricio M. O. Matos, Nicolli Souza Rios Alves e Rodrigo Oliveira Spnola ]
Sumrio
Contedo sobre Agilidade

14 Scrum backlog: requisitos no funcionais

[ Srgio Salles Galvo Neto ]

Artigo no estilo Prtico

23 IFPUG SNAP: medindo requisitos no funcionais

[ Thiago Chierici Cunha ]

Contedo sobre Boas prticas, Artigo no estilo Curso

29 Use Case Point : estimativas de projeto Parte 1

[ Anderson Pinheiro Balbo, Wilson Vendramel e Maria Beatriz Felgar de Toledo ]

Contedo sobre Boas prticas, Artigo no estilo Curso

40 Desvendando o Gerenciamento de Projetos Parte 3

[ Ary dos Santos Rocha Jnior ]
Feedback
eu
s
D

Contedo sobre Engenharia, Contedo sobre Boas Prticas

44 Trabalhando com Engenharia de Requisitos sobre e

[ Elaine G.M de Figueiredo ]
s
ta
edio

Contedo sobre Engenharia, Artigo no estilo Mentoring D seu feedback sobre esta edio!
49 Especificando casos de uso eficazes
[ Rodrigo Oliveira Spnola ] A Engenharia de Software Magazine tem que ser
feita ao seu gosto.
Para isso, precisamos saber o que voc, leitor, acha
Contedo sobre Boas prticas
da revista!
www.devmedia.com.br/esmag/feedback
52 Gesto de Regras de Negcios
[ Marco Ikuro Hisatomi, Anderson de Souza Ges e Rodolfo Mirando de Barros ]
Edio 05 - Engenharia de Software Magazine 5
Agilidade
Nesta seo voc encontra artigos voltados para as prticas e mtodos geis.
Desenvolvimento gil: anlise sobre
requisitos tradicionais
Entenda os benefcios e dificuldades das abordagens tradicionais e geis
Mauricio M. O. Matos
matos_mauricio@hotmail.com
Formado em Cincia da Computao pela
Universidade Salvador - UNIFACS. J atuou
na rea de Testes/Qualidade e atualmente
exerce a funo de Analista de Requisitos
na Softwell Solutions
Nicolli Souza Rios Alves
nicolli.devmedia@gmail.com
Bacharel em Cincia da Computao na
Universidade Salvador (UNIFACS), Mes-
tranda em Sistemas e Computao no
Programa de Ps-Graduao em Siste-
mas e Computao da UNIFACS na linha
de Engenharia de Software. editora da
Engenharia de Software Magazine.
Rodrigo Oliveira Spnola
rodrigo.devmedia@gmail.com
Editor Chefe Engenharia de Software
Magazine
6 Engenharia de Software Magazine - Desenvolvimento gil: anlise sobre requisitos tradicionais
A
especificao de requisitos
pode ser, em muitos casos, um
problema complexo, principal-
mente quando o analista de requisitos
no tem domnio sobre o negcio do
cliente. Compreender a natureza do
problema pode ser muito difcil, espe-
cialmente se o sistema for novo. Em
decorrncia disso, surgiu a engenharia
de requisitos que pode ser definida como
o termo usado para descrever as ativida-
des relacionadas produo e gerncia
de requisitos. Este artigo abordar, sob
diferentes perspectivas e metodologias,
as atividades do processo de produo
dos requisitos com foco em especificao
de requisitos.
Os requisitos funcionais de um sistema
descrevem as funcionalidades ou os
servios que se espera do sistema. Para
registrar estes requisitos, so utilizados
diferentes tipos de abordagens, sendo a
Fique por dentro:
A especificao dos requisitos uma etapa
crucial no processo de criao de um software.
Diferentes abordagens surgiram com o objetivo
de realizar esta etapa, porm, o diferencial est
nos princpios que cada uma aplica em seus
processos. Este artigo apresenta a realizao de
um estudo de caso com objetivo de investigar
na prtica as vantagens e desvantagens da es-
pecificao de requisitos entre as metodologias
geis e tradicionais. O estudo foi iniciado a par-
tir da elaborao de dois tipos de documento
de requisitos de software, um proveniente da
metodologia de especificao gil e o outro da
tradicional. Os requisitos definidos esto no
contexto de um sistema escolar hipottico, um
cadastro de usurios e uma emisso de relat-
rio de usurios.
tradicional realizada a partir de casos de
uso, e a gil que utiliza estrias de usu-
rios como documento de requisitos.
Tais abordagens diferem em certos
aspectos na especificao. A anlise
destas diferenas importante para
saber quando cada abordagem a mais
indicada para solucionar o problema
do cliente.

Neste artigo, sero investigadas as vantagens e desvantagens
de se trabalhar com ambas as metodologias de especificao
de requisitos, na perspectiva do analista de requisitos e do
desenvolvedor. Para realizar esta avaliao, um estudo de caso
foi planejado e foram elaboradas dois tipos de documentao:
uma considerando a metodologia gil e outra a tradicional.
Aps isto, estas documentaes foram entregues a quatro de-
senvolvedores para realizarem suas funes e, ao fim, respon-
derem um questionrio a respeito das dificuldades e benefcios
encontrados no uso de cada tipo de especificao.
Metodologias de especificao de requisitos
Um processo de engenharia de requisitos um conjunto
estruturado de atividades a serem seguidas para criar, va-
lidar e manter um documento de requisitos [2]. O processo
de produo do documento de requisitos constitudo pelas
atividades de levantamento de requisitos, registro, validao
e verificao como demonstrado na Figura 1.
Figura 1. Engenharia de Requisitos [2]
Este processo foi evoluindo utilizando-se as boas prticas de
engenharia de requisitos. Porm, fatores como a rpida evolu-
o tecnolgica, presso para o sistema entrar no mercado e
mudanas cada vez mais frequentes no ambiente de negcio Testes e anotaes so inseridos na estria para que auxiliem
do cliente esto desafiando as abordagens da ER.
Os mtodos geis surgiram com o objetivo de suprir estas
necessidades, onde o objetivo principal da abordagem ga-
rantir a entrega do sistema em um menor prazo, com maior
qualidade e satisfazendo as necessidades do cliente.
Metodologia gil
As exigncias do mercado mudaram e com isso, a engenharia
de requisitos teve que se adequar a elas. Os mtodos geis
(MAs) alteraram o processo da ER tradicional e o adaptou para
seus interesses. Tradicionalmente, ER fortemente baseada em
documentao para compartilhar conhecimento, enquanto que
MAs so focados em colaborao face a face entre desenvolve-
dores e clientes para garantir objetivos similares.
Para estabelecer um modelo de boas prticas, um grupo de
profissionais especialistas na rea criou um padro para as
metodologias geis, chamado Manifesto gil, em que centra-
lizaram princpios baseados em diversos mtodos existentes.
agilidade
Como de caracterstica dos MAs, o Manifesto gil tem um
enfoque muito maior em interao com o cliente do que com o
cumprimento metdico de processos. Partindo deste princpio,
passaram a valorizar:
Indivduos e interaes mais que processos e ferramentas;
Software em funcionamento mais que documentao
abrangente;
Colaborao com o cliente mais que negociao de
contratos;
Responder a mudanas mais que seguir um plano.
MAs tm foco na interatividade dos envolvidos e em respos-
tas rpidas como forma de atender os requisitos do usurio.
A abordagem de requisitos em MAs pode permitir bons resul-
tados a partir de sua combinao com aspectos favorveis do
contexto. Entretanto, isto pode requerer, por exemplo, que a
ER seja adaptada principalmente devido ao fato de que essas
metodologias abdicam, em parte, de documentos e controle
de artefatos muito presentes neste processo.
Produzir, manter e rastrear documentao de requisitos exige
um esforo que na viso gil pode comprometer a entrega do
software funcionando. MA precisa de processos rpidos, defi-
nidos, que sejam curtos, quando se tratando da documentao
gerada no diferente. Esta deve conter o necessrio para guiar
o tema da discusso entre o desenvolvedor e o cliente, de onde
sair todos os detalhes necessrios para a implementao do
requisito.
User Stories um dos modelos de especificao de requi-
sitos indicados para MAs. Uma User Story (US) descreve
uma funcionalidade que valiosa para o cliente ou usurio
do sistema. Este modelo de especificao composto pelas
seguintes caractersticas:
A descrio da estria usada para servir de planejamento
e lembrete, como demonstrado na Figura 2;
necessrio discutir sobre a estria para se esclarecer quais-
quer detalhes;
no desenvolvimento de regras e detalhes que a funciona-
lidade deve possuir. A estria estar concluda a partir do
momento que o sistema passar por todos os testes e contenha
as anotaes.
Figura 2. Um exemplo de descrio de uma User Story
Para se criar uma boa US necessrio que esta seja caracte-
rizada por seis atributos:
Independente;
Negocivel;
Valiosa para o cliente ou usurio;
Edio 66 - Engenharia de Software Magazine 7
 Estimvel;
Pequena;
Testvel.
Dependncias entre US podem causar transtornos no mo-
mento do desenvolvimento do sistema. Por exemplo, o cliente
definiu que uma US prioridade mxima, mas para inici-la
necessrio terminar outra de prioridade inferior.
As USs precisam ser negociveis, uma vez que elas so apenas
lembretes da funcionalidade desejada pelo cliente/usurio.
Caso haja alguma observao muito importante que dever
ser lembrada no momento da codificao, o cliente/usurio
poder adicionar notas US. Sempre tomando cuidado para
no exagerar nos detalhes, em muitos casos, especificar deta-
lhes muito cedo s cria mais trabalho. A Figura 3 mostra um
exemplo de US com anotao.
Figura 3. Um exemplo de anotao em uma User Story
Uma boa prtica deixar que o cliente/usurio escreva as
estrias, podendo ter um auxlio do desenvolvedor para isso.
Assim, as USs sempre sero de valor para os interessados.
importante tambm que as USs sejam estimveis. Para isso,
necessrio que o desenvolvedor possua os conhecimentos
tcnicos, do negcio e que as USs possuam tamanhos ideais
(estrias muito grandes so difceis de estimar).
Uma US no pode ser muito grande, pois no possvel elabo-
rar um planejamento concreto baseando-se nela. Nestes casos,
necessrio desagreg-las em USs menores e consistentes.
Por fim, uma US precisa ser testvel. Os testes servem para
o desenvolvedor saber quando a implementao da estria foi
concluda. Se ela passar em todos os seus testes, significa que
foi desenvolvida com sucesso. Os testes podem ser escritos no
verso do carto como demonstrado na Figura 4.
Figura 4. Verso de um carto, demonstrando os testes da US
Metodologia tradicional
Ao contrrio da metodologia gil de ER, a tradicionalmente
aplicada permite um controle maior do andamento do proje-
to, produzindo documentaes gerenciais e de especificao
muito mais detalhadas e consistentes. Alm de uma srie de
8 Engenharia de Software Magazine - Desenvolvimento gil: anlise sobre requisitos tradicionais
atividades que necessitam ser cumpridas com certa ordem para
que o processo como um todo funcione. Alguns dos principais
objetivos da ER so:
Estabelecer uma viso comum entre o cliente e a equipe de
projeto em relao aos requisitos que sero atendidos pelo
projeto de software;
Registrar e acompanhar requisitos ao longo de todo o pro-
cesso de desenvolvimento;
Documentar e controlar os requisitos alocados para esta-
belecer uma baseline para uso gerencial e da Engenharia de
Software;
Manter planos, artefatos e atividades de software consisten-
tes com os requisitos alocados.
A especificao de requisitos comumente utilizada nesta
metodologia so os Casos de Uso (UC do ingls Use Case).
Um UC uma sequncia de interaes entre o ator, algum ou
algo que interage com o sistema, e este, que acontece de forma
atmica na perspectiva do ator.
Por ser um documento que ser entregue e validado pelo
cliente, que nem sempre da rea de TI, um UC descrito de
forma que o cliente entenda a funcionalidade do sistema sem
necessidade de explicar tecnicamente como ocorre operao.
Na Tabela 1 tem-se um conjunto de definies que so im-
portantes em um caso de uso.
Estudo de Caso
Esse estudo tem como objetivo analisar as metodologias de
especificao de requisitos gil e tradicional, com o propsito
de definir as vantagens e desvantagens de cada abordagem,
com respeito aplicao destes conceitos no desenvolvimento
de software, do ponto de vista de quatro desenvolvedores
e um analista de requisitos no contexto da elaborao da
documentao e desenvolvimento das funcionalidades a
partir das documentaes fornecidas, especficas de cada
abordagem.
Alm disso, para este estudo de caso foram elaborados
alguns instrumentos definidos no cenrio de um sistema de
informao. Para isso, foram considerados dois requisitos: um
de cadastro bsico de usurio e outro de emisso de relatrios.
Para cada um dos requisitos, foram definidos os casos de uso
e estrias do usurio correspondentes:
Caso de Uso do cadastro de usurios (ver Tabela 2): Este caso
de uso define como as operaes de incluso, alterao, exclu-
so e consulta de usurios so efetuadas no sistema. Note que
para isso temos um fluxo principal representando a operao
de consulta. Em complemento, foram definidos seis fluxos
alternativos para funcionalidades auxiliares, como cancela-
mento de uma operao e outros para as funcionalidades de
incluso, alterao e excluso de usurios. Alm disso, foram
definidas trs regras de negcio.
Observe tambm que cada fluxo alternativo foi definido no
momento em que ele pode ser utilizado durante a interao do
ator com o sistema. De forma semelhante, as referncias s re-
gras de negcio foram definidas. Por fim, foi definido tambm
 agilidade

Objetivo: Contm uma breve descrio do objetivo do caso de uso.

Requisitos: Neste campo indicamos a qual requisito funcional o caso de uso em questo est associado.
Atores: Neste campo definimos a lista de atores associados ao caso de uso. Ator qualquer entidade externa que interage com o sistema (neste caso, com o caso de uso em questo).
Prioridade: Informao identificada junto ao usurio que auxilia na definio dos casos de uso que sero contemplados em cada iterao do desenvolvimento do software.
Pr-condies: Neste campo devemos informar as condies que devem ser atendidas para que o caso de uso possa ser executado.
Frequncia de uso: Informao identificada junto ao usurio que auxilia na definio dos casos de uso que sero contemplados em cada iterao do desenvolvimento do software.
Criticalidade: Informao identificada junto ao usurio que auxilia na definio dos casos de uso que sero contemplados em cada iterao do desenvolvimento do software.
Condio de
Neste campo definimos qual ao do ator dar incio interao com o caso de uso em questo.
Entrada:
Fluxo Principal: Esta uma das sees principais do caso de uso. onde descrevemos os passos entre o ator e o sistema. O fluxo principal o cenrio que maisacontece no caso de uso e/ou o mais importante.
Fluxo alternativo o caminho alternativo tomado pelo caso de uso a partir do fluxo principal, ou seja, dada uma condio de negcio o caso de uso seguir por outro cenrio que no
Fluxo Alternativo:
o principal caso essa condio seja verdadeira.
Extenses: Nesta seo colocamos todos os casos de uso que estendem o caso de uso base e em quais pontos eles so chamados dentro dos fluxos de eventos.
Ps-condies: Neste campo devemos informar o estado em que o sistema (ou entidade manipulada no caso de uso) estar depois que o caso de uso for executado.
Regras de negcio: Nesta seo descrevemos todas as regras funcionais que o caso de uso deve cumprir durante sua execuo.
Tabela 1. Definies importantes de um Caso de Uso

Objetivo Permitir a incluso, alterao, excluso e consulta de usurios.

Requisitos O software deve permitir o gerenciamento de usurios.
Professor-Administrador
Atores Professor
Aluno
Prioridade Alta
Pr-condies No se aplica
Frequncia de uso Eventual
Criticidade Mdia
Condio de entrada O ator seleciona a opo de gerenciar usurios.
1. O sistema apresenta o formulrio no registro do usurio logado
2. O ator consulta os dados no formulrio, que contm as seguintes informaes e funcionalidades:
#Nome (Campo texto. Indica o nome do usurio do sistema)
#Login (Campo texto. Indica o Login para acesso ao sistema)
#Senha (Campo texto, com mscara de senha. Indica a senha de acesso ao sistema)
#Administrador? (Campo texto com domnio fechado, possveis valores: Sim; No. Indica se o usurio ser administrador do sistema.) [RN3]
#Perfil (Campo texto com domnio fechado, possveis valores: Professor; Aluno. Indica o perfil do usurio, ser parmetro para acesso outras funcionalidades do sistema)
E-mail (Campo texto. Indica o e-mail do usurio)
Fluxo principal
Telefone (Campo numrico, com mscara de telefone. Indica o telefone do usurio)
Opo de inserir um novo usurio [FA1] [RN1]
Opo de alterar um usurio [FA2] [FA3] [RN2]
Opo de excluir um usurio [FA4] [RN1]
Opo de cancelar ao [FA5]
Opo de buscar usurio [FA6]
Opo de emitir o relatrio de usurios [E1]
3. O caso de uso encerrado.
[FA1] O ator seleciona a opo de inserir
1. O sistema altera o modo do formulrio para incluso, apresentando os seguintes campos a serem preenchidos:
Nome
Login
Fluxo alternativo Senha
Administrador? (Valor padro: No)
Perfil (Valor padro: Aluno)
E-mail
Telefone
Tabela 2. Caso de uso de cadastro de usurios

Edio 66 - Engenharia de Software Magazine 9

um fluxo de exceo que trata o preenchimento incorreto de
campos durante o cadastro do usurio.
Ainda no contexto deste caso de uso, vale observar que ao final
de cada fluxo definido explicitamente para qual passo da funcio-
nalidade o sistema ser direcionado (por exemplo: o caso de uso
encerrado ou o sistema retorna ao passo X do fluxo principal).
Caso de Uso do relatrio de usurios (ver Tabela 3): Este
caso de uso, mais simples que o definido na Tabela 2,
descreve como a consulta e gerao do relatrio so efe-
tuadas. Observe que basicamente temos uma tela de con-
sulta seguida do relatrio gerado a partir das informaes
consultadas.

2. O ator preenche os campos disponibilizados

3. O ator seleciona a opo salvar [FE1]
4. O sistema retorna ao passo 2 do fluxo principal.
[FA2] O ator seleciona a opo de alterar seu registro
1. O sistema altera o modo do formulrio para alterao, habilitando apenas os seguintes campos para edio:
Nome
Login
Senha
E-mail
Telefone
2. O ator altera os campos desejados
3. O ator seleciona a opo salvar [FE1]
4. O sistema retorna ao passo 1 do fluxo principal.
[FA3] O ator seleciona a opo de alterar registro de outro usurio
1. O sistema altera o modo do formulrio para alterao, habilitando os seguintes campos para edio:
Senha
Administrador?
Perfil
2. O ator altera os campos desejados
Fluxo alternativo
3. O ator seleciona a opo salvar [FE1]
4. O sistema retorna ao passo 2 do fluxo principal.
[FA4] O ator seleciona a opo de excluir um registro
1. O sistema solicita a confirmao da excluso com as opes de confirmar e cancelar
2. O ator confirma a excluso
3. O registro removido e o sistema retorna ao passo 2 do fluxo principal.
[FA5] O ator seleciona a opo de cancelar a ao
1. O sistema solicita a confirmao do cancelamento com as opes de confirmar e cancelar
2. O ator confirma o cancelamento da ao
3. O sistema fecha o formulrio e o caso de uso encerrado.
[FA6] O ator seleciona a opo de buscar usurios
1. O sistema exibe os seguintes campos para busca
Nome
Login
Administrador?
2. O ator executa a funo de busca
3. O sistema exibe a relao de usurios de acordo com os filtros definidos
4. O ator seleciona o usurio desejado
5. O sistema retorna ao passo 2 do fluxo principal.
[FE1] Campos obrigatrios no preenchidos
Fluxo de exceo 1. O sistema emite uma mensagem de erro informando qual campo obrigatrio no foi preenchido;
2. O sistema retorna ao passo onde este fluxo de exceo foi chamado.
Extenses [E1] Caso de uso UC02 - Emitir Relatrio de Usurios.
Ps-condies Ser realizada a manuteno dos usurios.
[RN1] Apenas os professores que forem administradores tero permisso para realizar esta ao.
[RN2] Os professores administradores podero alterar seus prprios registros por inteiro, de outros usurios apenas os campos:Senha,Perfil e Administrador?. Quem no
Regras de negcio
for administrador, poder editar o seu registro parcialmente, apenas os campos:Nome,Login,E-mail e Telefone.
[RN3] Apenas professores podero ser administradores.
Continuao: Tabela 2. Caso de uso de cadastro de usurios

10 Engenharia de Software Magazine - Desenvolvimento gil: anlise sobre requisitos tradicionais

 agilidade

Objetivo Permitir que os administradores emitam uma relao dos usurios cadastrados
Requisitos O software deve permitir a emisso do relatrio de usurios
Atores Professor-Administrador
Prioridade Mdia
Pr-condies No se aplica
Frequncia de uso Eventual
Criticidade Mdia
Condio de entrada O ator seleciona a opo de emitir relatrio de usurios
1. O sistema apresenta os seguintes campos para filtro do relatrio de usurios:
Perfil (Campo texto com domnio fechado, possveis valores: Aluno; Professor)
Administrador? (Campo texto com domnio fechado, possveis valores: Sim; No)
2. O ator executa a funcionalidade de emitir o relatrio [FA1] [FE1]
3. O sistema exibe o relatrio de usurios de acordo com os filtros definidos. De cada usurio sero exibidas as seguintes informaes:
Nome
Fluxo principal
Login
Administrador?
Perfil
E-mail
Telefone
4. O caso de uso encerrado.
[FA1] O ator executa a funcionalidade de emitir o relatrio sem preencher os filtros
1. O sistema exibe o relatrio de usurios com todos os usurios cadastrados. De cada usurio sero exibidas as seguintes informaes:
Nome
Login
Fluxo alternativo Administrador?
Perfil
E-mail
Telefone
2. O caso de uso encerrado
[FE1] O ator executa a funcionalidade de emitir o relatrio, mas no h usurios a serem retornados de acordo com os filtros
Fluxo de exceo 1. O sistema emite uma mensagem de erro informando que a consulta no retornou usurios
2. O sistema retorna ao passo 1 do fluxo principal
Extenses No se aplica
Ps-condies Ser exibido o relatrio de usurios
Regras de negcio No se aplica

Tabela 3. Caso de uso de relatrio de usurios

User Story do cadastro de usurios (ver Tabelas 4 e 5):

De forma semelhante ao que foi representado na Tabela 2,
essa US representa a funcionalidade de cadastro de usurio.
Oberve que ela bastante simples em termos de informaes
descritas. Por outro lado, tambm so definidas algumas
informaes que objetivam orientar a execuo dos testes
para a funcionalidade (informao no presente diretamente
na especificao do caso de uso).
Note que a US apresenta apenas uma viso geral das
funcionalidades. Sendo assim, seus detalhes devem ser
identificados apenas medida que as funcionalidades
sejam desenvolvidas. Isso tende a causar uma necessidade
de maior aproximao entre a equipe de desenvolvimento
e o cliente.
O sistema deve permitir a consulta, incluso, excluso e alterao de um usurio.
Apenas o administrador poder incluir e excluir um usurio
Notas Apenas o administrador poder alterar registros alm do seu.
Definir as permisses de acesso aos campos e registros
Tabela 4. User story cadastro de usurio Frente do Carto
Testar insero, alterao e excluso de usurios;
Testar como um aluno, a incluso de um novo usurio;
Testar como um administrador, a alterao do prprio registro e o de outros usurios
(acessibilidade aos campos).
Testar incluso ou alterao sem preencher um ou mais campos obrigatrios.
Tabela 5. User story cadastro de usurio Fundo do Carto

Edio 66 - Engenharia de Software Magazine 11

 User Story do relatrio de usurios (ver Tabelas 6 e 7):
De forma semelhante, pode-se obervar que a descrio da user
story do relatrio de usurios bastante simples: definimos
apenas as funcionalidades que estaro presentes, maiores de-
talhes sobre cada uma delas so definidos apenas no momento
de sua implementao.
O sistema deve permitir a emisso do relatrio de usurios
Apenas o professor administrador poder emitir os relatrios
Notas
Os relatrios podero ser filtrados pelos campos perfil e administrador
Tabela 6. User story relatrio de usurios Frente do Carto
Testar emitir o relatrio sem definir filtros;
Testar como um aluno, emitir o relatrio;
Testar emitir o relatrio quando no houverem registros a serem retornados.
Tabela 7. User story relatrio de usurios Fundo do Carto
Para realizao da comparao das duas abordagens consi-
derando o estudo de caso desenvolvido, foram definidos dois
questionrios:
Questionrio sobre cada abordagem: os participantes apresen-
tam as dificuldades de entendimento do documento e sobre a
quantidade de informao/detalhe contidos no documento.
Questionrio comparativo das abordagens: so informadas
as vantagens e desvantagens encontradas na abordagem tradi-
cional utilizando casos de uso e na abordagem gil utilizando
user story.
Sobre a escolha dos participantes, um analista de requisitos
ser selecionado para especific-los e produzir as documen-
taes. Outros quatro desenvolvedores sero escolhidos para
apresentar seus pareceres referentes documentao prove-
niente das duas abordagens.
Analisando os resultados
Executado o estudo de caso planejado, identificou-se que o
esforo para elaborao dos artefatos foi proporcional aos seus
tamanhos. As USs, por serem pequenas e possurem poucos
detalhes, apresentaram pouca dificuldade. Em contrapartida,
os UCs necessitaram de esforo considerveis por possurem
diversas regras de implementao e detalhes dos requisitos.
A partir das entrevistas com os desenvolvedores, foi possvel
tirar algumas concluses a respeito dos diferentes modelos de
documento de requisitos. Em relao as USs, nenhum desen-
volvedor expressou alguma dificuldade de entendimento da
documentao. A falta de informao os preocupou inicial-
mente, mas aps a conversao, todas as dvidas foram escla-
recidas. O desenvolvedor 4 pontuou O documento pode ser
facilmente entendido, porm no h maiores detalhamentos e
precisa ser discutido.... Tendo esta deficincia de informaes,
os desenvolvedores responderam que possvel desenvolver as
funcionalidades parcialmente. O desenvolver 3 pontuou ... h
a necessidade de entrevistar o cliente para obter informaes
complementares.
12 Engenharia de Software Magazine - Desenvolvimento gil: anlise sobre requisitos tradicionais
Ao longo das entrevistas ficou claro que a dependncia
maior do cliente na utilizao de US como documento de
requisitos. Os desenvolvedores solicitaram inmeras vezes
esclarecimento das regras de negcio, restries de acesso
e campos. J no UC eles encontram todas as respostas no
prprio documento.
Ao se tratar de Casos de Uso, os desenvolvedores, por
unanimidade, ficaram satisfeitos com a quantidade de
informaes e detalhes das funcionalidades e responde-
ram no questionrio que possvel desenvolver as fun-
cionalidades apenas com as informaes do UC. Por ser
um documento maior e detalhado, o UC gerou algumas
poucas dvidas de entendimento como sinalizado pelo
desenvolvedor 2: Alguns smbolos especficos do docu-
mento podem gerar dvidas., porm, a aceitao geral
foi positiva.
Os desenvolvedores 1 e 3 salientaram que h um risco para
o projeto caso a discusso sobre a US seja entre o desenvol-
vedor e o cliente, visto que nem sempre o desenvolvedor o
profissional mais indicado para a funo. O desenvolvedor
1 afirmou ... o desenvolvedor muitas vezes possui dificul-
dades at mesmo de comunicao e relao interpessoal.,
o que aumenta os riscos de fracasso do projeto.
Por ser um documento detalhado, o desenvolvedor 1
afirma que o UC Aumenta a produtividade na etapa do
desenvolvimento.... Outro fator importante mencionado
pelo desenvolvedor 4 foi a questo da validao do docu-
mento feita pelo cliente indicando que h um Respaldo e
segurana sobre o que foi discutido..
As vantagens encontradas na metodologia gil em relao
a tradicional foram:
Menor custo e tempo na elaborao de documentos;
Foco no desenvolvimento;
Contato direto com o cliente para solucionar dvidas.
As vantagens encontradas na metodologia tradicional
em relao a gil foram:
Documento detalhado de linguagem comum entre
usurio e desenvolvedor, o que facilita aceites e evitar
futuras inconformidades entre o que foi desenvolvido e
o que foi pedido;
Documento completo e detalhado, suficiente para im-
plementao da funcionalidade;
Documentao elaborada por analista de requisitos o
que diminui a possibilidade de erros do levantamento de
requisitos.
A partir do estudo de caso realizado foi possvel observar
que a metodologia gil de especificao de requisitos de
fato otimiza o tempo gasto com documentao quando
comparado metodologia tradicional. O papel do analista
de requisitos foi citado como essencial mesmo na aborda-
gem gil, a funo de especificao na entrevista fica clara
e para isto importante que seja o profissional indicado
para a funo.

Foi tambm constatado que h a necessidade de haver o
contato direto entre o detentor do negcio, cliente ou ana-
lista de requisitos, e o desenvolvedor, pois no h como
desenvolver as funcionalidades por completo baseando-se
apenas nos US. Tendo isto em vista, aconselhvel utilizar
esta abordagem quando h uma disponibilidade plena do
cliente para transmitir as informaes.
Apesar de envolver mais processos para chegar sua
verso final e demandar um tempo maior para ser imple-
mentada, a documentao tradicional a partir de Casos de
Uso foi considerada a mais completa pelos desenvolvedo-
res. O UC um documento de linguagem comum entre
usurio e desenvolvedor, deste modo, possvel garantir
que certas funcionalidades foram verificadas e validadas
pelo cliente.
Mesmo podendo gerar algumas dvidas na documenta-
o, com seu nvel de detalhamento, possvel entender
por completo o que a funcionalidade dever fazer e assim
implement-la sem dificuldades.
Concluindo, a abordagem gil, de fato, se mostrou mais efi-
ciente em relao ao tempo de elaborao, e mais suscetvel
agilidade
a negociaes. J a abordagem tradicional exigiu mais
tempo para ser executada, porm sua documentao mais
completa e rica em detalhes, o que praticamente extinguiu
a necessidade do cliente estar disposio para elucidar
possveis dvidas.
Referncias:
1. Beck, K.; Beedle, M.; Van, A.; Bennekum; Cockburn, A.; Cunningham, W.;
Fowler, M.; James; Genning; Highsmith, J.; Hunt, A.; Jeffries, R.; Kern, J.;
Marik, B.; Martin, R. C.; Mellor, S.; Schwaber, K.; Sutherland, J.; Thomas, D.
(2001) Manifesto para Desenvolvimento gil de Software.
http://agilemanifesto.org/iso/ptbr, Novembro
2. dAmorim, F. R. S. (2008), Engenharia de Requisitos para Mtodos geis.
Voc gostou deste artigo?
D seu voto em www.devmedia.com.br/esmag/feedback
Ajude-nos a manter a qualidade da revista!
Edio 66 - Engenharia de Software Magazine 13
Agilidade
Nesta seo voc encontra artigos voltados para as prticas e mtodos geis.
Scrum backlog: requisitos no funcionais
Criando um ambiente favorvel para gerenciar melhor o Backlog
Srgio Salles Galvo Neto
ssallesinf@hotmail.com
Gerente de Projetos certificado PMP, ITIL,
Microsoft entre outras. Atuando na rea
de informtica desde 1992 e, a mais de
10 anos liderando equipes em projetos
de desenvolvimento e implantao de
softwares. Nos ltimos cinco anos, atuando
como Scrum Master em projetos em diver-
sas tecnologias e ramos de negcio.
14 Engenharia de Software Magazine - Scrum backlog: requisitos no funcionais
A
produo de software atravs
de modelos geis de desen-
volvimento, como o Scrum,
popularmente adotada por empresas
e equipes de diversos tamanhos e
seguimentos.
Porm, existem alguns pontos que
merecem uma ateno por se tratarem
de peas fundamentais no desenvolvi-
mento de um software: os requisitos no
funcionais. Estes podem levar o software
do sucesso ao fracasso.
A equipe de desenvolvimento tambm
precisa possuir um ambiente favorvel
para lidar com tudo isso e, por vezes,
pode no ter notado o que seria neces-
srio para poder alcanar um ambiente
mais produtivo e seguro.
Veja os nmeros apresentados na Figu-
ra 1 publicados no ltimo relatrio gera-
do pelo Standish Group em Maro/2013.
Este grfico demonstra o percentual de
falha, mudanas e sucesso nos projetos
de desenvolvimento de software.
Fique por dentro:
Requisitos no funcionais nem sempre so
abordados de forma clara durante a adoo
ou uso das metodologias geis, como o Scrum.
Este artigo sugere uma forma mais ampla de
enxergar o tratamento destes requisitos, tam-
bm considerados fatores crticos de sucesso
das aplicaes. Este artigo procura abordar os
riscos envolvidos em no se cuidar devidamen-
te dos requisitos no funcionais do software e
de como o time Scrum deve estar estruturado
para tratar ou evitar surpresas as quais po-
dem levar qualquer produto ao fracasso.
Podemos perceber que houve uma sen-
svel melhora, desde a 1 aferio em 1994
at a ltima em 2012 onde, de apenas
16% de sucesso nos projetos, alcanou-
se os 39%. Isso significa uma melhoria
de quase 100%. mas considerar que de
todos os projetos, apenas 39% destes so
entregues conforme o planejado, torna-
se um fator preocupante.
Em complemento, a Tabela 1 apresenta
os fatores considerados crticos para o
sucesso dos projetos.
De acordo com os dados deste relatrio,
podemos destacar os seguintes pontos:
 agilidade

A conscientizao, por parte das empresas, sobre a impor- O relatrio X est muito lento e est atrapalhando os
tncia da TI como pea fundamental no sucesso. Isso fez com usurios;
que a maior parte das empresas colocassem seus executivos O sistema cai quando atinge 1.000 usurios simultneos;
(os patrocinadores dos projetos) frente para auxiliar a TI, O sistema ficou 24 horas fora do ar devido a no possuir
oferecendo maior suporte e acompanhamento; ou no terem funcionado as devidas contingncias;
Em decorrncia desta conscientizao gerou-se um maior
envolvimento dos usurios, promovendo otimizao das Esta lista de questes so puramente requisitos no funcio-
aplicaes em pequenos projetos, com investimentos em co- nais no observados e/ou no atendidos.
nhecimento, aumentando o capital intelectual das equipes, se- Em praticamente toda a literatura associada ao uso do Scrum,
guido por uma melhor viso e entendimento mais slido sobre existe um assunto que no claramente tratado mesmo sendo
gerenciamento de projetos e a adoo de Processos geis. de extrema importncia: os requisitos no funcionais. Na es-
trutura de trabalho do Scrum, temos os papeis bem definidos:
Chaos Manifesto 2013 - The Standish Group Product Owner, Scrum Master e a equipe, que composta
Failed Challenged Successful
sempre por membros com diversos conhecimentos e habilida-
de (multidisciplinar), mas nem sempre se observa a presena
16
(ou a necessidade) de recursos detentores de conhecimentos
27 26 28
34 29
35 32 37 39
especficos, como de um arquiteto, um DBA ou um especialista
de infraestrutura, o qual domine a parte de arquitetura da
53 33 soluo implementada.
46
49
51
53 46
44
42 43
As empresas as quais adotaram ou iro adotar o Scrum pre-
cisam ter em mente a questo de que se um novo requisito no
31
40
28
funcional ou um problema grave de performance na aplicao
23 19 24 21
18 18
15
surgir, pode comprometer o sucesso do produto. Na verdade,
1994 1996 1998 2000 2002 2004 2006 2008 2010 2012 um requisito no funcional to ou mais importante que um
requisito funcional.
Figura 1. Percentual de Falhas, Mudanas e Sucesso em projetos de TI

Fatores de sucesso Pontos Entendendo os requisitos funcionais e no funcionais

preciso entender o papel dos requisitos funcionais e no
Suporte da Gesto Executiva 20
funcionais para poder trat-los de forma correta:
Envolvimento dos Usurios 15
Funcionais: O que o produto deve fazer, que necessidades
Otimizao 15 de negcio deve atender, os cadastros, relatrios, funcionali-
Recursos Especializados 13 dades tangveis ao usurio: estes so cadastrados no Product
Experincia em Gesto de Projetos 12 Backlog e posteriormente se transformam em estrias, que
Processos geis 10 so priorizadas pelo Product Owner, entendidas e oradas
pela equipe e, durante o planejamento, transformam-se na
Objetivos Comerciais Claros 6
meta da Sprint;
Maturidade Emocional 5
No Funcionais: So aqueles no tangveis diretamente ao
Execuo 3 usurio final (Cliente), mas que determinam como e onde a
Ferramentas e Infraestrutura 1 aplicao (produto) deve funcionar, critrios de segurana e crip-
tografia, escalabilidade, disponibilidade, compatibilidade, etc.
Tabela 1. Fatores de Sucesso dos Projetos de TI

Ambos so itens do backlog, so premissas e fazem parte do

Observe que muitos desses fatores esto alinhados com as
prticas geis de desenvolvimento.
A importncia e os desafios na adoo das
metodologias geis
possvel verificar a importncia do entendimento e adoo
das metodologias geis para garantir o sucesso nos projetos de
desenvolvimento de software. Nelas o foco est em entregar
software funcionando.
Seguindo esta linha, imaginemos uma aplicao produzi-
da com o Scrum ou outra metodologia gil. Este software
encontra-se em produo e em uso por usurios e num dado
momento surgem questes como:
Escopo do Produto. Ento, precisamos entend-los e abord-
los adequadamente durante o processo de desenvolvimento
do software.
Desenvolver software representa diversos desafios e, cuidar
do produto e da equipe, sem sombra de dvidas, to ou mais
importante do que todo o resto. Quando aprendemos a obser-
var estas variveis de forma mais clara, no apenas a equipe,
mas principalmente a empresa, temos uma viso e um com-
prometimento muito maior, pois estabelece um entendimento e
uma comunicao mais transparente. o que podemos chamar
de fazerem todos falarem a mesma lngua.
Para quem no sabe, segundo o prprio Project Management
Institute (PMI.org), um Gerente de Projetos usa at 90% do seu

Edio 66 - Engenharia de Software Magazine 15

tempo em comunicao. Esta no um tema a ser abordado
neste momento, mas muito importante lembrar que a Comu-
nicao correta e clara entre todos os envolvidos essencial
para o sucesso de qualquer projeto.
Estruturando o produto e a equipe
Um produto nasce para atender determinada necessidade de
negcio e/ou administrativa. Para desenvolv-lo precisamos
definir o ambiente de desenvolvimento. Mas, qual a finalidade
de termos esse setup? A equipe deve conhecer o produto no
qual ir trabalhar e ser capaz de capacitar todos seus mem-
bros quanto ao escopo deste produto e todo o arcabouo de
informaes, cdigos fonte, especificaes, estrias, backlogs
(onde ficam e como so acessadas). Ou seja, a equipe s pode
cuidar de algo o qual:
Ela conhea (O que faz);
Ela entenda (Por que faz);
Ela tenha a clara viso da importncia/essncia de cada
parte do produto.
Ento, para cada parte, sugere-se realizar este setup
considerando estes dois pontos: Produto e Ambiente de
desenvolvimento.
Sugesto do setup do produto
Para se estabelecer um produto, sugere-se criar um ponto de
partida, uma referncia ou, ao termo mais conhecido em desen-
volvimento de software que criar uma Baseline. A partir
da criao desta referncia, ser possvel entender melhor, no
apenas o que o produto deve fazer, mas sim como ele deve
suportar. Para criar esta baseline, ser necessrio envolver
todos, principalmente o Product Owner e o Scrum Master.
Criar uma lista de requisitos funcionais e no funcionais da
aplicao no precisa ser uma tarefa complexa. Quanto mais
clara e objetiva ela for, melhor cumprir com seu objetivo que
descrever sucintamente o produto. Pode-se utilizar de uma
simples tabela, conforme o exemplo na Tabela 2, a ser usada
como consulta e referncia.
Temos quatro campos:
Requisito Funcional: Destinado a identificar o requisito pelo
nome, designao ou identificador do requisito ou funciona-
lidade do software. Podemos dizer at que seja a referncia a
um item de configurao;
Descrio: Uma breve descrio do requisito ou funciona-
lidade, informando seu objetivo central ou para o que ela se
destina;
Requisito No Funcional: Nome, designao ou identifi-
cador do requisito no funcional do software. Podemos dizer
Requisito Funcional Descrio Requisito No Funcional
Cadastro de Usurio Manter dados do usurio Criptografia
Workflow
Cadastro de Pedidos Manter os pedidos de Venda
Acessos Simultneos
Tabela 2. Exemplo de Baseline Produto
16 Engenharia de Software Magazine - Scrum backlog: requisitos no funcionais
at que seja a referncia a um item de configurao. Sugere-
se coloc-lo na mesma linha do requisito funcional pois,
na maioria das vezes, um requisito no funcional pode ser
criado especificamente para um requisito funcional. Pode-se
tambm serem abordados os objetos (componentes, classes,
bibliotecas). Lembrando que a maneira a ser adotada deve ser
aquela que Equipe preferir ou se sentir mais confortvel. Pode
haver mais de um requisito no funcional para um mesmo
requisito funcional. Observe o exemplo na Tabela 2 onde o
requisito Cadastro de Pedidos possui dois requisitos no
funcionais Workflow e Acessos Simultneos;
Descrio: Uma breve descrio do requisito no funcional,
informando seu objetivo central ou para o que ela se destina.
Em uma arquitetura orientada a objetos, estes podem (e devem)
ser construdos de forma mais genrica permitindo seu reuso
em diversos pontos do sistema.
Alm destas informaes, pode-se incrementar com outros
campos como: data de criao, data de atualizao, usar hiper-
links para levar para outro documento, ou at criar um cdigo
identificador para cada requisito. No menos importante, pode
ser interessante associar as estrias criadas para atender a cada
um dos requisitos.
Como outras sugestes, pode-se tambm incluir a verso, a
data de entrega de cada um destes requisitos.
Devemos lembrar que um requisito no funcional pode ser
definido globalmente, ou seja, ele est presente no software
como um todo e no apenas em uma ou outra funcionalidade
(requisito funcional) em especfico. Mesmo assim, por uma
questo de visualizao e controle inicial, estes requisitos no
funcionais devem ser mapeados junto com os requisitos fun-
cionais de forma que no sejam esquecidos durante a avaliao
e o Sprint Planning.
Critrios de classificao de demandas (issues) do
produto
Temos agora uma lista de referncia, um ponto de partida
e, assim, temos condies de classificar as demandas que
temos. Antes de se cadastrar os itens no Product Backlog (lista
geral de demandas do produto), deve-se ter bem claro o que
ser entendido como bug (erro), mudana, nova funcionalidade
ou novo requisito no funcional.
Ao adotar estes quatro tipos de classificao, o processo de
priorizao de demandas tambm ficar mais fcil. Um bug
grave ou crtico sempre ser mais prioritrio do que uma
mudana ou nova funcionalidade e, por vezes, ambos sero
igualmente crticos ou dependentes. Existiro momentos onde
no haver escolha e, tanto o bug quanto a mudana ou a nova
funcionalidade devero ser resolvidos numa mesma Sprint.
Descrio
Criptografar a senha do cliente
Distribuir automaticamente os pedidos entre as linhas de produo
Permitir at 1.000 acessos simultneos
 agilidade

Os pesos e critrios para orar cada um destes tipos tambm
podero ser levados em conta. Iremos comparar, brevemente,
bugs e novos requisitos de maneira a podermos elencar os
pesos e critrios com maior propriedade. Seguem:
Bug um erro sobre algo existente ento, por mais comple-
xo que seja resolv-lo, ser mais fcil corrigi-lo do que algo
novo;
Mas, o que seria algo novo? Uma nova funcionalidade ou um
novo requisito no funcional podem esconder complexidades
ou dependncias que no foram ou no puderam ser identificadas
logo no incio ento, a partir da, temos um ponto de interroga-
o, um alerta de risco e, este fator de risco deve incorporar a
estimativa (de forma racional e comprometida pelos membros
da equipe) considerando que a estimativa pode falhar e, neste
caso, tem o fator da novidade. Obviamente que o bom senso
sempre dever imperar: uma nova funcionalidade a qual, todos
sabem ser uma cpia quase fiel de uma j existente, no pode ser
considerada nova do ponto de vista tcnico, correto?
Enfim, agora temos uma viso do produto, seus requisitos
funcionais, no funcionais e uma classificao para cada tipo
de demanda que faz parte do backlog e, desta forma, a equipe
est pronta para orar, planejar as sprints e gerar estimativas.
Por outro lado, temos um Product Owner ciente dos desafios
impostos pelo backlog existente e as decises e os caminhos
para alcanar o sucesso.
Sugesto de setup para a equipe de desenvolvimento
Para se estabelecer uma equipe gil, motivada e produtiva,
no bastam bons computadores e boa remunerao agregada
com excelentes benefcios. Um ambiente favorvel e bem es-
truturado so peas fundamentais.
Da mesma forma que o foi abordado no item produto, co-
mear minimamente com um ambiente e equipe estruturadas,
as chances de se alcanar uma boa produtividade, qualidade
do produto e satisfao da equipe, so muito maiores. Seguem
alguns itens a serem considerados e disponibilizados equipe
de desenvolvimento: ferramentas, rotinas e, ambientes.
Ao adotar uma ferramenta, d preferncia quelas que faam
o controle de verses e, alm disso, que disponha da facilidade
de controle por branches (ramificaes).
Controlar verses significa poder controlar o que foi alterado
no contedo do cdigo fonte, quem o alterou e quando. E ainda,
poder estabelecer qual membro da equipe pode ou no acessar
partes do cdigo ou todo ele.
O recurso de branch permitir que vrios membros da
equipe possam trabalhar em separado, cada um em sua
branch em separado e, sem poluir o cdigo estvel com
cdigo em desenvolvimento durante os processos de corre-
o e/ou evoluo. Este recurso aumentar a produtividade
da equipe e reduzir o ndice de falha por serem gerados
builds com cdigo inacabado. A parte de Builds ser
abordada mais adiante.
No devemos nos esquecer de ter um repositrio, ou rea
dentro do repositrio de cdigo fonte, para os documentos
como os backlogs de Produto e da Sprint, ou de documentos
contendo as estrias implementadas e a implementar.
importante lembrar tambm que as polticas de acesso e
permisses devem ser geridas pela equipe de infraestrutura,
a fim de garantir que todos os membros da equipe possuam
tudo o que precisam e tambm tenham seus acessos conforme
sua necessidade.
Em ltimo lugar, mas no menos importante, esta ferra-
menta de repositrio permitir a execuo do backup (cpia
de segurana).

Ferramenta de repositrio de cdigo fonte

no cdigo fonte que tudo comea para um sistema.
essencial saber quem e quando alterou o cdigo fonte e qual
verso do mesmo. Para isso, se faz necessrio adotar um
repositrio de cdigo e no estamos dizendo em ter uma
pasta compartilhada na rede, mas sim uma ferramenta que
desempenhe este papel. Podemos citar vrias como CVS, SVN,
Team System, GIT, entre outras.
A principal funo de um repositrio a de centralizar o
armazenamento do cdigo fonte, evitando que cada membro
da equipe possua uma cpia do cdigo em sua prpria estao
de trabalho. Um repositrio unificado significa um ganho
considervel em performance e segurana geral. Com este
repositrio, no haver mais preocupaes como: quem est
alterando o cdigo x? ou qual a verso mais recente e
estvel do cdigo y?.

Edio 66 - Engenharia de Software Magazine 17

 Uma vez que o cdigo fonte e/ou documentos encontra-se
em um local centralizado, torna-se simples e eficaz fazer as
cpias de segurana, obedecendo aos critrios e polticas da
empresa.
Ferramenta de gerao de builds
Outro ponto crtico no desenvolvimento de sistemas a
cultura de se gerar as Builds ou Verses. Build, no contexto
do desenvolvimento de software, significa uma verso com-
pilada de um software ou parte dele que contm um conjunto
de recursos que podero integrar o produto final. Existem
diversas opes, algumas at j integradas aos repositrios
de cdigo fonte. Algumas tecnologias exigem compiladores
especficos. Enfim, o que importa ter o conceito e a cultura
estabelecida dentro da empresa e da equipe.
Gerar builds sempre que houver uma mudana significativa
no produto e que se permita sua avaliao, uma boa prti-
ca para dar continuidade ao processo de desenvolvimento,
testes, homologao e roll out (disponibilizar o software em
produo).
Possuir um ambiente com o fim de se gerarem as builds
aumenta a garantia da qualidade do software. Podemos dizer
que este ambiente um ou o mais importante e necessrio dos
ambientes para a equipe desenvolver seu trabalho.
Rotina de deploy automatizado
Uma rotina pode ser entendida como processo repetvel, ou
melhor, sempre que algo de uma natureza especfica tiver de
ser feito, que o seja seguindo-se uma sequncia de passos de
execuo previamente definidos, estruturados, documentados
e conhecidos pelos membros da equipe.
Um bom exemplo prtico do termo rotina seria a Rotina de
Backup da empresa. Dizer que existe uma Rotina de Backup
seria o mesmo que dizer sempre que uma cpia de segurana
de dados for gerada, ser da forma X. Esta forma X representa
sua ocorrncia (periodicidade), contemplar os dados arma-
zenados nas mquinas e/ou locais determinados, e os arqui-
vos de backup sero gravados (salvos) em um determinado
dispositivo (unidade de disco, fita, disco ptico, etc.) e sero
fisicamente guardados em determinado local seguro. Enfim,
chamar de rotina condiz com o detalhamento da(s) ao(es)
a(s) qual(is) existem para sua execuo.
Chamamos de deploy a ao de instalar ou entregar o
software desenvolvido e compilado (uma build) em um am-
biente. Esta ao pode ser feita manualmente, porm exige
muita ateno e extremamente suscetvel a falhas.
Aliando as definies de rotina e deploy tem-se que: sempre
ao se instalar alguma atualizao de um software, os passos
de 1 at N devero ser seguidos, verificados e, caso ocorra
algum erro, dever haver um procedimento de retorno es-
pecfico definido.
Agora imaginemos, na prtica, uma equipe de desenvolvi-
mento de software, a qual adotou uma metodologia de desen-
volvimento gil (como Scrum ou XP). As aes de criao e/ou
alterao do software ocorrero durante uma Sprint. Nesta(s)
18 Engenharia de Software Magazine - Scrum backlog: requisitos no funcionais
Sprint(s) (corrida(s)), sero realizadas inmeras e simultneas
alteraes no cdigo fonte, por diversas pessoas e, a todo o
momento. Estas alteraes sero entregues atravs de novas
verses do software. A cada nova verso (ou Build), para ser
considerado entregue, dever ocorrer instalao e configu-
rao dos componentes do software (deploy) em um ambiente
definido, de forma a disponibilizar esta nova verso do sistema
para os testes e homologao necessrios.
importante ressaltar que: o ato de um deploy considerado
como uma alterao no ambiente. Isso significa que sempre
que um deploy ocorrer, algo novo (seja uma atualizao ou um
novo sistema) ser instalado e afetar os itens de configurao
atuais no(s) ambiente(s) onde forem aplicados. Desta maneira,
sempre se deve preocupar em se ter um ponto de retorno, ou
seja, ter uma verso estvel para voltar.
Dependendo do tamanho e/ou da complexidade da verso
(Build) entregue, podem ser consumidas algumas horas de
um ou mais profissionais para realizar o deploy (instalao)
do software. O tempo ainda pode aumentar muito se houver
a necessidade de se atualizar itens de configurao da prpria
mquina como, por exemplo, verses de objetos, pacotes de
correo (patches ou service packs), atualizao de componen-
tes do sistema operacional ou do sistema de gerenciamento do
banco de dados, enfim, tudo isso leva tempo e ainda, corre-se
o risco de algo dar errado.
Se algo no sair conforme o planejado, precisarmos dar o
rollback e voltar situao anterior. O processo de desfazer
uma atualizao (ou deploy) pode ser proporcional ou maior
do que o processo normal de deploy. Pode-se dizer que se o
tempo estimado para realizar um deploy for de uma hora,
caso seja necessrio desfaz-lo, poder ser gasto a mesma uma
hora ou at mais. Portanto, o processo de deploy precisa ser
muito bem estruturado, documentado e conhecido por todos
os membros da equipe envolvidos nesta atividade. No opo
ter um processo de deploy o qual no contemple o caminho
de volta (rollback). Vale muito a pena investir recursos (pes-
soas + tempo) para conceber, estruturar, documentar, treinar
e estabelecer o processo de deploy na empresa.
Estamos falando sobre deploy, mas no podemos nos esque-
cer das pessoas responsveis por esta atividade. Por se tratar
de algo to essencial, deve existir uma equipe dedicada a esta
atividade de deploy que a equipe de infraestrutura. Esta
equipe dever possuir conhecimentos mais especficos com
relao aos ambientes (mquinas hardware e programas
software).
Esta equipe de infraestrutura existe para salvaguardar o
ambiente e no permitir que este seja modificado sem o devido
planejamento. Portanto, deve-se sempre manter a equipe de
infraestrutura ciente do planejamento destas intervenes de
maneira que tudo continue funcionando corretamente.
Para entender melhor sobre a importncia e a criticidade deste
assunto gostaramos de citar uma ocorrncia: Certa vez, uma
consultora em CMMi e MPS.Br comentou: o maior risco nos
projetos de Tecnologia , e to somente, a prpria tecnologia.
O tempo que se investe em escrever a aplicao (software),

testar, homologar e disponibiliz-lo em produo , infini-
tamente menor, do que a caa aos problemas oriundos de
atualizaes de verses de qualquer componente do ambiente,
seja hardware ou software. Geralmente so problemas os quais
exigem horas e horas de pessoas e geralmente, so resolvidos de
uma maneira totalmente adversa e sem uma explicao lgica.
Aqueles que no tem a menor lgica para acontecer porm,
acontecem e so extremamente avassaladores com nossa rotina
de trabalho. H grande sentido nesta colocao desta consulto-
ra e refora a necessidade e importncia em se ter um processo
de deploy muito bem estruturado e documentado.
Ambientes de Infraestrutura: definio
Pode-se dizer que um ambiente composto por uma ou mais
mquinas, que contm os requisitos necessrios para hospedar
o software desenvolvido. Estas mquinas tambm devero
possuir o software bsico (sistema operacional, sistema de
gerenciamento de banco de dados, software de servidor de
aplicao, etc.), devidamente instalado e configurado, a fim
de suportar a aplicao.
Podemos dizer que existem basicamente, trs ambientes
necessrios para o desenvolvimento de software: Desenvol-
vimento, Testes e Produo.
A seguir sero abordados os ambientes sugeridos e mini-
mamente necessrios para viabilizar e otimizar o processo
de desenvolvimento de software considerando uma estrutura
baseada em metodologia gil (Scrum).
Ambiente de integrao contnua
Antes de explicarmos quanto ao ambiente tecnolgico para
receber a Integrao contnua, necessrio contextualizar o seu
conceito. Segundo Martin Fowler, Integrao Contnua uma
pratica de desenvolvimento de software onde os membros de
um time integram seu trabalho. Geralmente, cada pessoa integra
pelo menos diariamente podendo haver mltiplas integraes
por dia. Cada integrao verificada por um build automatizado
(incluindo testes) para detectar erros de integrao o mais rpido
possvel. Muitos times acham que essa abordagem leva a uma
significante reduo nos problemas de integrao e permite que
um time desenvolva software coeso mais rapidamente.
Seguindo este conceito, para um ambiente mais produtivo de
uma equipe de desenvolvimento de software, recomenda-se
a adoo da Integrao Contnua, pois durante uma Sprint o
resultado das alteraes e/ou correes no cdigo fonte rea-
lizadas pela equipe de desenvolvimento devero gerar novas
verses (Builds) e estas builds devero ser disponibilizadas
(deploy) automaticamente em um ambiente de Integrao
Contnua. O objetivo do ambiente de Integrao Contnua ser
um ambiente para o desenvolvedor, e os demais membros da
equipe, verificar se a implementao est de acordo com o es-
perado, aplicando seus testes unitrios e at automatizados.
Se o cdigo funcionar neste ambiente, podemos dizer que
temos quase 15% (percentual de completude e no percentual
de esforo) do trabalho concludo. Com o cdigo funcionando,
basta mandar essa verso para os testes.
agilidade
Ambiente de Teste
Antes de falarmos sobre o ambiente de testes, importante
relembrarmos o que so testes. Conforme comentamos ante-
riormente, um produto de software deve possuir um escopo,
ou seja, estabelecer o que e como deve se comportar. A
partir do escopo definido, surgem os requisitos funcionais e os
no funcionais. De posse destas definies, deve-se estabelecer
uma validao para verificar se o o que e o como foram
atendidos. A esta validao, d-se o nome de Testes.
Testes devem ser aplicados para qualquer criao ou alterao
no cdigo fonte. Eles servem para verificar se o que foi feito;
implementao, a correo ou o novo software est atendendo
aos requisitos solicitados.
Existe uma vasta literatura contemplando a gesto e execu-
o de testes. Nosso objetivo agora no explicar esta parte,
mas sim de ressaltar sua importncia no processo como um
todo e ainda, ressaltar a necessidade de execut-los dentro de
um ambiente dedicado e seguindo os critrios necessrios e,
acima de tudo, registrar o resultado dos testes de forma que
possamos tomar decises sobre o que deve ser feito e sua
criticidade e severidade.
Mas, no basta simplesmente testar, imprescindvel ser
criado e seguido um roteiro, um plano de testes. Para que os
testes ocupem um papel mais central, recomendvel que seja
adotada uma metodologia voltada para este fim chamada TDD
desenvolvimento orientado a testes. Adotando este mtodo
TDD, todo o desenvolvimento ser orientado ao teste o que
minimizar os erros bsicos.
Segundo as definies existentes na metodologia chamada
Extreme Programming ou XP, o termo TDD pode ser descrito
da seguinte maneira: Test Driven Development (TDD), ou em
portugus Desenvolvimento orientado a testes, uma tcnica
de desenvolvimento de software que se baseia em um ciclo cur-
to de repeties: primeiramente o desenvolvedor escreve um
caso de teste automatizado que define uma melhoria desejada
ou uma nova funcionalidade. Ento, produzido cdigo que
possa ser validado pelo teste para posteriormente o cdigo ser
refatorado para um cdigo sob padres aceitveis.
Agora que j entendemos um pouco sobre os conceitos de
testes e de uma sugesto de metodologia, precisamos entender
mais sobre a importncia e o significado dos testes. Da mesma
forma que um cdigo implementado pode ter sucesso, podem
existir erros. Se durante os testes algum erro foi identificado,
isso ocorreu porque houve o pleno entendimento pela equi-
pe do o que e do como os requisitos foram definidos no
escopo, estes requisitos foram traduzidos em casos de teste
e estes testes aferiram corretamente a execuo do cdigo
gerado. Testar e no encontrar erros, isso sim pode ser sinal
de problemas.
Encontrar um erro durante os testes poupa muitos problemas
os quais, se ocorressem em produo, poderiam ser devasta-
dores, desde a perda da credibilidade ou at gerar prejuzos
financeiros para todos os envolvidos.
Para que seja possvel executar os testes se faz necessrio
possuir um ambiente destinado a isso. Um ambiente de teste
Edio 66 - Engenharia de Software Magazine 19
servir para execuo dos testes internos pela equipe (sem
interveno ainda do cliente). Este ser o ambiente o qual
receber a verso (Build) gerada no ambiente de Integrao
Contnua aps ter sido realizado o deploy desta verso.
Em termos de configurao, dever se assemelhar ao
ambiente de Homologao e/ou ao ambiente de Produo.
O ideal que o ambiente de testes seja o mais prximo possvel
ao ambiente de Produo.
Ambiente de homologao
neste ambiente onde sero aplicados os testes e validaes
do que est sendo entregue. Quem dever execut-los sero os
usurios e/ou clientes do software. Damos tambm o nome de
Testes de Aceitao a este processo de Homologao realizado
pelo cliente.
Em linhas gerais, significa que se o cliente aceitar ou con-
siderar homologado o software entregue, o cliente endossa o
produto em termos de escopo e qualidade.
No incomum que este ambiente seja disponibilizado pelo
prprio cliente. Sendo assim, os tpicos anteriores que mencio-
nam o processo de deploy se fazem mais necessrios do que
nunca. Possuir um processo estabelecido de deploy aumenta a
credibilidade sobre a empresa e o profissionalismo da equipe
envolvida na construo do software contratado.
neste ambiente tambm que devero ser aplicados os testes
relacionados aos requisitos no funcionais. Geralmente, para
execuo de testes de performance/carga, ser necessria a
construo de robs que simulem acessos simultneos e
transaes para aferir se o software entregue aguenta con-
forme o que foi estabelecido. Existem ferramentas disponveis
no mercado para este fim.
A configurao deste ambiente deve se assemelhar, o mximo
possvel, da configurao do ambiente de produo (hardwa-
re e software). Quanto mais prxima estiver do ambiente de
produo, maior a garantia de sucesso nos testes.
Ambiente de produo
Chama-se de Ambiente de produo aquele conjunto de
hardware e software destinado a hospedar a aplicao desen-
volvida e testada pela equipe, homologada e aceita pelo cliente
e/ou usurio(s) que a utilizaro.
Trata-se de um ambiente o qual dever ser controlado e
protegido rigorosa e cuidadosamente por uma equipe dedi-
cada geralmente a equipe de Infraestrutura da Empresa ou
do prprio cliente.
O ato de criao de um software passa por muitos cami-
nhos at que chegue neste estgio de disponibiliz-lo em
produo.
Neste ponto, o processo de deploy ser colocado prova.
Tenha certeza em seguir todos os passos j estabelecidos e
executados nos momentos anteriores. Da mesma maneira que
foi feito o deploy nos ambientes de testes e de homologao,
o processo de deploy em produo deve seguir os mesmos
moldes e, ainda, com um pouco mais de ateno. Isso garantir
o sucesso de todo o esforo investido.
20 Engenharia de Software Magazine - Scrum backlog: requisitos no funcionais
Trabalhando com os requisitos no funcionais
Em se tratando de metodologias geis, temos dois grupos
de pessoas: a equipe de desenvolvimento e o Product Owner.
Cada grupo possui suas necessidades especficas. Para o
Product Owner foi abordada a necessidade de se estabelecer
o escopo do produto (Baseline) e tambm, uma forma melhor
de se registrar e classificar o backlog do produto.
A equipe j adotou e est confortvel para construir software
de forma gil. Mas, por outro lado, a realidade de sua empre-
sa pode ainda no ter alcanado tudo isso e, agora, devemos
operacionalizar os requisitos no funcionais. Conforme expu-
semos anteriormente, existem alguns problemas relacionados
ao tratamento incorreto destes requisitos no funcionais.
Mas, qual seria a origem desses problemas? Para cada um
deles podem haver inmeras causas:
1. No houve modelagem do Banco de Dados?
2. A mquina que hospeda o Banco de Dados foi corretamente
dimensionada?
3. Faltou adotar alguma boa prtica do Banco de Dados como
uso de ndices, Procedures, Queries, Views, entre outros?
4. A aplicao foi desenhada para suportar quantos usurios
simultneos?
5. O conjunto de mquinas, o DataCenter ou a infraestrutura
disponibilizada para hospedar a aplicao foi dimensionada
para suportar alta disponibilidade?
Quem deveria ter se preocupado com isso? Olhando para
o quem (pessoa), existem dois papis: o ScrumMaster e o
Product Owner e, objetivamente, os dois so os verdadeiros
responsveis por no terem se preocupado com a falta de
definio dos requisitos no funcionais.
Pode parecer estranha essa colocao em atribuir a respon-
sabilidade destas falhas ao ScrumMaster e ao Product Owner,
mas sim, estes papeis deveriam ter se preocupado com isso.
Existem inmeras justificativas para a no observao destes
requisitos no funcionais como tempo, falta de foco nesta
questo entre outras. mas o fato que no foram observados
estes requisitos.
Planejar e tratar os requisitos no funcionais no , original-
mente, uma questo bem definida nas metodologias geis. Ao
observarmos leituras da forma clssica de desenvolvimento
de software (Cascata/Waterfall) como, por exemplo, o Unified
Process (Processos Unificados), os requisitos funcionais ou no
funcionais, o centro de tudo. Ao nos remetermos poca da
adoo desta forma clssica relevante ressaltar que no exis-
tiam mtodos eficazes de produzir software e, com a adoo
desta metodologia, houve ganhos significativos relacionado ao
sucesso dos projetos de desenvolvimento de software.
Construir software de boa qualidade e de forma rpida po-
deria ser impensvel, at o advento das metodologias geis.
A partir da popularizao destas metodologias, conquistou-se
a velocidade e o cumprimento das expectativas alcanando
timos resultados para as partes interessadas.
Na verdade, esta popularizao tambm levou muitos a dar
mais foco na agilidade, velocidade, visibilidade e deixando um

pouco de lado as premissas, o escopo, enfim, os requisitos.
preciso entender o fato: problemas como os relatados an-
teriormente so graves e, muitas vezes, de difcil e demorada
resoluo. Uma arquitetura mal definida, um banco de dados
mal modelado, uma infraestrutura mal dimensionada, geram
todos estes e tantos outros problemas.
Por esta razo que foi mencionado a importncia de se ter
uma referncia (baseline) do produto para que esta sirva de
nivelamento de comunicao, fazendo com que todas as partes
interessadas tenham acesso e absorvam integralmente os obje-
tivos a serem alcanados pelo software a ser desenvolvido.
Como podemos evitar tais problemas?
O Scrum Master e o Product Owner devem conversar,
alinhando seus conhecimentos. O Product Owner possui
o entendimento e as necessidades comerciais e conseguir
definir os requisitos no funcionais. Com o auxlio do Scrum
Master, que detm uma bagagem tcnica, conseguir en-
tender os requisitos funcionais e no funcionais bem como
seus impactos no software. O resultado desta conciliao de
necessidades e conhecimentos ser a definio de uma lista de
requisitos funcionais e no funcionais a serem contemplados
pelo software, ou melhor, o Baseline do Produto conforme
mencionamos anteriormente.
Uma vez que temos uma lista de requisitos (funcionais e
no funcionais), o Scrum Master ter condies de verificar
os conhecimentos e habilidades necessrias (skills) para
transformar estes requisitos em software. Determinando essa
lista de skills, o prximo passo identificar se os membros da
equipe contemplam estas exigncias. Se os membros da equi-
pe j possurem as qualificaes, timo, caso contrrio, resta
apenas duas alternativas: capacitar s pessoas ou contratar
novos recursos.
Qualquer uma das opes exigir investimentos da empresa
e, neste momento, o Scrum Master aliado ao Product Owner,
devero levar estas demandas alta direo da empresa e
justific-la.
Capacitar equipe existente gera sempre um sentimento
de valorizao da equipe e muitas pessoas sentem-se extre-
mamente motivadas, este seria o principal ponto positivo ao
optar-se pela capacitao da equipe. Outro ponto importante
seria o fato de que estas pessoas levaro para o treinamento os
desafios conhecidos, possibilitando um maior aproveitamento
tanto do treinamento em si quanto a aplicao dos conheci-
mentos adquiridos na prtica.
Como pontos negativos da opo de capacitar a prpria
equipe, destacam-se o tempo das pessoas, pois enquanto elas
estiverem em treinamento, no estaro produzindo e tambm,
as chances de rotatividade destas pessoas uma vez que esti-
verem mais qualificadas, sero mais cobiadas e at assedias
pelo mercado.
Para lidar com estes pontos positivos e negativos, a alta dire-
o da empresa dever balancear estas questes. Considerando
os aspectos negativos, com relao ao tempo, o Product Owner,
o Scrum Master e a equipe, devero se organizar para priorizar
agilidade
os itens do backlog (as estrias) equilibrando os conhecimentos
e a quantidade de pessoas disponveis para a execuo dos
trabalhos durante o perodo em que a outra parte das pessoas
estiver em treinamento.
Com relao rotatividade, o departamento de Recursos
Humanos dever atuar de forma a gerar mecanismos que
incentivem a reteno das pessoas atravs de polticas de reco-
nhecimento bem como acordos onde as pessoas que receberem
treinamento se comprometam a permanecer na empresa.
Obviamente que existem diversos outros aspectos relacio-
nados a Recursos Humanos e polticas especficas de cada
corporao, mas o fato que se deve observar esta opo de
capacitar a equipe, analisando clara e objetivamente os pontos
positivos e negativos para uma correta tomada de deciso.
Quanto a opo de contratar novos recursos, sejam estes
efetivos ou temporrios, a forma de contratao depender
das polticas e da realidade da empresa. O ponto chave desta
opo ter em mente que as lacunas de pessoas e skills sejam
preenchidas para atender o objetivo. Mesmo assim, os novos
recursos demandaro investimentos em treinamento quanto
ao projeto, o produto e a forma de trabalho da empresa e ainda,
sempre haver uma curva de aprendizado versus produtivida-
de onde, dependendo das circunstncias, o novo recurso estar
mais alocado em treinamentos, consumindo tambm recursos
da equipe os quais tenham condies de ensinar e ambos, no
estaro produzindo neste nterim. A produtividade plena da
equipe s atingir os patamares desejados aps este perodo
de ensino e a aprendizagem estiverem concludos.
De forma resumida, os tempos e a quantidade de pessoas
disponveis, at atingirem sua plenitude em termos de pro-
dutividade iro variar. Estes fatores devero ser considerados
tanto na opo de capacitar a equipe tanto quanto a contratao
de novos recursos. Vale ressaltar que, acima de tudo, tanto a
Organizao (Empresa) quanto as equipes devem estar con-
fortveis e comprometidas com a deciso tomada.
Considerando que todas as questes de organizao dos
backlogs, da lista de requisitos, das equipes e de toda a infra-
estrutura necessrias estejam atendidas, chega o momento de
organizar o trabalho e iniciar o processo de planejamento das
Sprints. A execuo dos processos permitir a operacionali-
zao de todos os tpicos explicados neste artigo conforme
passaremos a explicar.
A execuo dos processos da metodologia Scrum inicia-se
com o Planejamento das Sprints, a esta etapa d-se o nome
de Sprint Planning (Planejamento da Sprint). A atividade de
Planejamento da Sprint (Sprint Planning) serve para orar
os itens priorizados pelo Product Owner e, caber equipe
dizer se so possveis ou no de serem tratados em uma ou
mais Sprints. Percebam que estamos tratando apenas os itens
priorizados e no o Backlog geral.
neste momento, durante o planejamento, que estes requi-
sitos devero ser revistos, atualizados, e normalmente, serem
transformados em estrias e devidamente orados, planejados
e implementados nas Sprints pela equipe. Da mesma forma
que o ritual de reviso do Product Backlog ocorre.
Edio 66 - Engenharia de Software Magazine 21
 Ao final de cada Sprint, as metodologias geis, como o Scrum,
indicam a necessidade de ser feita uma reviso. A esta reviso
d-se o nome de Sprint Review ou Retrospective Meeting
(Retrospectiva da Sprint). Nesta ocasio, so verificados os
resultados alcanados, as falhas e os pontos de melhoria.
A reunio de Retrospectiva de fato no o evento a ser
utilizado para o fim de revisar os requisitos. Sugerimos que
seja criado um novo evento, o qual pode ser denominado de
Product Review ou Product Retrospective. Este novo evento
dever ocorrer logo aps a Reunio de Retrospectiva e, obriga-
toriamente, antes de ser iniciado o Planejamento da prxima
Sprint. Este evento servir para criar e atualizar a lista de itens
de escopo do Produto (Product Baseline).
Seguindo esta sugesto de criar este novo evento, permitir
que a lista de requisitos, o baseline do Produto, seja criado
igualmente de forma gil e, ao longo do tempo, torne este base-
line do Produto tangvel, completo, atendendo as necessidades
da empresa e da equipe.
Estas sugestes esto baseadas no fato de que, conforme
descrito nas metodologias geis, no existe o detalhamento
ou indicao dos momentos ou eventos a serem dedicados
ao estudo do produto exclusivamente. A Atividade de
orar o Backlog do Produto (Product Backlog) um bom
exemplo disso.
Ao verificar as metodologias geis, durante a fase de encerra-
mento, existe o evento de Retrospectiva da Sprint. Dentro deste
evento de Retrospectiva existe o ponto chamado de Fazer a
Melhoria Contnua dos processos.
Fazer a Melhoria Contnua dos processos significa rever,
junto com a equipe, tudo que foi bom e tudo o que poderia ser
feito de uma melhor maneira. Todos os membros da equipe
devem sugerir e eleger mudanas. Geralmente estas mudanas
devem objetivar o aumento da produtividade e/ou da qualida-
de da prpria equipe. Tais mudanas devem ser implantadas
estabelecendo-se critrios de avaliao permitindo que os
ganhos sejam medidos aps a adoo das mudanas.
Ao se criar este novo evento de Reviso do Produto houve,
na verdade, uma melhoria no processo atual da empresa.
22 Engenharia de Software Magazine - Scrum backlog: requisitos no funcionais
Esta mudana poder ser aferida na medida em que a produtivi-
dade e a qualidade melhorem, bem como com reduo do esforo.
O resultado prtico ser percebido quando a equipe conseguir
produzir mais itens do backlog dentro de um mesmo prazo
de Sprint.
Para concluir, sabemos que existem inmeros desafios no que
tange o desenvolvimento de software. Para superar estes, as
metodologias geis como o Scrum, oferecem diversos recursos
que visam alcanar o sucesso de forma descomplicada e rpida,
e ainda, garantindo a qualidade e satisfao do cliente.
Toda e qualquer metodologia oferece um framework como
forma de demonstrar diversos cuidados os quais se deve ter
para garantir o sucesso em sua adoo, porm a forma de como
implement-los ficar por conta de seus praticantes, dando-
lhes a liberdade de adaptar o que for necessrio para adequar
estas metodologias realidade das empresas e das equipes.
Links:
The Standish Group
http://blog.standishgroup.com/
The Standish Group - Chaos Report 2013
http://versionone.com/assets/img/files/ChaosManifesto2013.pdf
Artigo de Martin Fowler sobre Integrao Contnua
http://martinfowler.com/articles/continuousIntegration.html
Extreme Programming Extreme Testing
http://c2.com/cgi/wiki?ExtremeProgramming
Extreme Programming - Test Driven Development (TDD)
http://c2.com/cgi/wiki?TestDrivenDevelopment
Voc gostou deste artigo?
D seu voto em www.devmedia.com.br/esmag/feedback
Ajude-nos a manter a qualidade da revista!
Planejamento e Gerncia
Nesta seo voc encontra artigos voltados para o planejamento
e gerncia de seus projetos de software.
IFPUG SNAP: medindo requisitos no
funcionais
Um framework para a medio dos requisitos no funcionais
Thiago Chierici Cunha
Thiago.cunha@gmail.com
Profissional certificado em pontos de fun-
o pelo IFPUG desde 2009. Especialista
em Educao Tecnolgica pela UEMG e
graduado em Processamento de Dados
pela Anhanguera. Atualmente leciona em
alguns cursos de Ps graduao do IGTI e
atua como arquiteto de software na CI&T.
Nos ltimos 15 anos tambm acumula
experincias em gesto de processos e
projetos e desenvolvimento em diversas
plataformas.
A
medio do software to im-
portante quanto de qualquer
outro produto vendido por
quantidade, peso ou volume. O fra-
mework SNAP apresenta uma diviso de
trs dimenses em que o software preci-
saria ser medido: os requisitos tcnicos,
os requisitos de qualidade e os requisitos
funcionais. Para os requisitos funcionais,
o mercado adota largamente a anlise de
pontos de funo (APF BOX 1) definida
pelo IFPUG e padronizada pela ISO des-
de 2009, apesar da ISO tambm definir
outras metodologias como COSMIC,
FiSMA, Mark-II e NESMA.
Enquanto a APF define bem como
medir os requisitos funcionais, os re-
quisitos tcnicos e de qualidade no e nos custos.
so contemplados pela mesma. Assim,
medies feitas apenas com APF normal- IFPUG havia definido uma etapa da
mente ignoram dimenses importantes
do desenvolvimento do software, que
Edio 66 - Engenharia de Software Magazine
Fique por dentro:
Neste artigo iremos entender o contexto de
mercado que exigiu a criao de uma nova
metodologia de metrificao no funcional.
Ser explicado o que so os requisitos no
funcionais e suas principais categorias na viso
da ISO e do IFPUG. Na sequncia, veremos os
principais objetivos e benefcios do SNAP e co-
nheceremos a metodologia em si. Finalizando,
veremos um exemplo simples, porm completo
de uma contagem no funcional e iremos anali-
sar as concluses sobre o que foi exposto neste
trabalho.
A medio do escopo serve de base para gera-
o da maior parte das mtricas do ciclo de vida
do desenvolvimento de software. A utilizao
do tamanho no funcional como parte do esco-
po medido, permitir uma melhor adequao
das estimativas, principalmente em mtricas
relacionadas a esforo e custo.
podem gerar distores no planejamento
Para tentar corrigir tais distores, o
medio funcional, chamada de fator de
ajuste, que consistia em um ajuste de at
23
mais ou menos trinta e cinco por cento no tamanho funcional
original, ou seja, se o sistema possua 100 pontos de funo (PF),
seu tamanho ajustado poderia ser um valor entre 75 PF e 135
PF de acordo com os requisitos no funcionais considerados.
O uso do fator de ajuste no foi muito bem aceito pelo mer-
cado, assim como pela ISO, que a partir de 2009, sugeriu que
o mesmo no mais fizesse parte da metodologia APF. Desde
l, o fator de ajuste passou a ser descontinuado e disponi-
bilizado como um apndice do guia do IFPUG. O principal
motivo para a mudana seria o fato de que o requisito no
funcional no deveria alterar o tamanho funcional da apli-
cao, mas sim ser contado de forma independente. Surgia
a necessidade de uma nova metodologia para medio dos
requisitos no funcionais.
BOX 1. Anlise de Pontos de Funo
A APF tem suas origens em um trabalho feito na IBM em 1979 por Allan Albrecht que foi
formalizado como um guia em 1984. J em 1988, a verso 2.0 foi publicada pela primeira vez
sob a responsabilidade do International Function Point Users Group, o IFPUG. Na verso 3.0 de
1990 o IFPUG transformou o que era um conjunto de vrias interpretaes sobre como contar
pontos de funo em um guia mais organizado e coerente. A partir da verso 4.1 de 1999 o
guia comeou a sofrer revises constantes, graas ao enorme crescimento no uso da tcnica e a
um maior apoio da comunidade para que o processo pudesse amadurecer. No Brasil a APF teve
um grande crescimento a partir da publicao da Instruo Normativa 2 de 2008, que sugere o
uso de unidade de medida que permita a mensurao dos resultados.
Requisitos no funcionais
A ISO/IEC 14143-1:2007, que trata de medio de software,
especialmente a medio da parte funcional, mas que tambm
define e trata os principais conceitos relacionados, divide os
requisitos de usurio (RU) em dois grupos:
Requisitos funcionais de usurio (RFU);
Requisitos no funcionais de usurio (RNF);
Sobre as normas e demais definies relacionadas aos RFUs,
no iremos nos aprofundar neste artigo. J para os RNFs, a
ISO/IEC/IEEE 24765:2010 os define como um requisito de
software que descreve no o que o software ir fazer, mas como
o software ir fazer. Outra norma que trata sobre os RNFs
a ISO/IEC 25010:2011, que define caractersticas da qualidade
e suas categorias, listadas a seguir:
Adequao funcional;
Eficincia de desempenho;
Compatibilidade;
Usabilidade;
Confiabilidade;
Segurana;
Manutenibilidade;
Portabilidade;
As categorias utilizadas no mtodo SNAP que sero apre-
sentadas neste artigo no so as mesmas utilizadas pelo ISO,
porm todas as categorias podem ser enquadradas em ambas
as vises sem muita dificuldade.
24 Engenharia de Software Magazine - IFPUG SNAP: medindo requisitos no funcionais
Histrico
Em 2007 a diretoria do IFPUG formalizou o incio dos
trabalhos do que chamavam na poca de Framework de Ta-
manho Tcnico. O IFPUG buscava com este framework uma
forma de medir os aspectos tcnicos de projeto de software
com uma metodologia independente da APF, utilizada na
medio funcional. A importncia desta independncia seria
para manter a compatibilidade de resultados e histrico de
projetos legados j medidos e mtricas corporativas que j
se baseavam na APF. A iniciativa foi apoiada pela diretoria
e membros do IFPUG.
Em Outubro de 2009 foi publicada a primeira verso do
SNAP com o objetivo de permitir uma reviso do trabalho
que vinha sendo feito e ajustar a direo e expectativas. Esta
verso chamada 0.1 ainda no era aberta comunidade e foi
revisada apenas pela diretoria do IFPUG e comits especficos
de reviso.
Como fruto desta reviso e consequentes ajustes, cerca de
um ano depois foi lanada a verso 1.0 Beta do Manual de
Prticas de Avaliao SNAP - APM. Esta verso foi lanada em
novembro de 2010 e no incio do prximo ano comearam os
testes Beta executados por empresas do mundo inteiro.
Ainda em 2011 foi liberada uma nova verso do guia que foi
definida como 1.0, que j levavam em considerao os resul-
tados e observaes dos processos de teste Beta executados no
incio daquele ano. Esta primeira verso estabilizada j trazia
definies de conceitos, processos e regras para a avaliao
dos requisitos no funcionais.
A verso vigente durante a criao deste artigo, a 2.0, foi lan-
ada em janeiro de 2013. Esta verso trouxe mais maturidade ao
guia, apresentando novos conceitos que eram utilizados, mas
no eram bem explicados. Foram feitos ajustes nos processos e
regras e algumas subcategorias foram reorganizadas de acordo
com o retorno obtido da comunidade.
O APM ainda se define como um guia vivo, ou seja, novas
verses sero lanadas com certa frequncia para tentar ajus-
tar o guia realidade e s necessidades do mercado. Como o
processo possui definies e regras para cada subcategoria
funcional, esperado que novas verses fossem lanadas
sempre que novas tecnologias ou necessidades surjam no
mercado. Uma preocupao permanente dever existir para
que estas evolues mantenham a compatibilidade e histrico
de contagens que utilizem verses anteriores do guia.
Objetivos e benefcios do SNAP
De acordo com o guia do SNAP, so dois os principais ob-
jetivos da metodologia: o primeiro seria medir o tamanho
no funcional de determinado software que solicitado ou
recebido por um cliente, muito til no momento da contratao
de um desenvolvimento e na validao do que foi entregue e
sua conformidade com a solicitao original; o segundo obje-
tivo medir o desenvolvimento e manuteno de requisitos
no funcionais, como por exemplo, alterar a tecnologia de
implementao de um determinado aplicativo ou criar um
mecanismo de segurana em um software j existente.
 agilidade

Ao criar o SNAP, o IFPUG tambm pretendia ter uma metodo-

logia simples o bastante para que fosse necessria a dedicao
de pouco tempo para fazer as medies (BOX 2), incentivando
uma maior adoo por vrios projetos e empresas.

BOX 2. Estimativa x Medio

Muitas vezes observamos o uso destes dois termos como se tivessem o mesmo significado no
contexto de mtricas de software, porm temos algumas diferenas sutis, mas importantes
Figura 1. Os passos do processo SNAP
entre os conceitos, j que podem servir de critrio contratual ou de auditoria interna ou externa.
As estimativas ou aproximaes podem ser feitas sem termos todos os detalhes necessrios para
A primeira seo do processo SNAP equivale ao planejamen-
fazer uma medio completa ou mesmo em caso que temos estes detalhes, mas desejamos uma
to do que ser medido. Neste passo iremos definir o motivo de
mtrica com maior produtividade e no precisamos de tanta preciso. Abaixo temos a Tabela 1,
estarmos fazendo a contagem, e deixar claro onde ela comea e
adaptada do guia do SNAP, que ilustra quando normalmente podemos fazer aproximaes e
onde termina. Para isso detalharemos os seguintes aspectos:
quando podemos fazer medies em um ciclo de desenvolvimento generalista.
Propsito da avaliao;
Fase do ciclo de vida PS podem ser estimados PS podem ser medidos Tipo da avaliao;
Proposta Sim No Escopo da avaliao;
Fronteira da aplicao;
Requisitos Sim No
Parties.
Projeto Sim Sim
Construo Sim Sim O propsito da avaliao define de forma textual o objetivo
Entrega Sim Sim do trabalho de medio ou aproximao que ser feito.
Manuteno (Preventiva, atravs dele que podemos buscar o tipo e escopo da avaliao.
Sim Sim
adaptativa ou perfectiva) Um possvel exemplo de propsito poderia se parecer com os
Tabela 1. Estimativas e medies de Pontos SNAP (PS) exemplos:
Fornecer o tamanho no funcional do projeto de desenvol-
vimento do software XXX, para servir de base para o clculo
de esforo e custos para elaborao de proposta tcnica e
Ao criar o SNAP, o IFPUG tambm pretendia ter uma metodo- comercial;
logia simples o bastante para que fosse necessria a dedicao Fornecer o tamanho no funcional entregue pela mudana
de pouco tempo para fazer as medies, incentivando uma de tecnologia do banco de dados do sistema YYY.
maior adoo por vrios projetos e empresas.
De acordo com o guia oficial as empresas podem utilizar o Assim como na contagem de pontos de funo, o tipo da
SNAP como: avaliao ter trs possibilidades. Esta informao normal-
Uma metodologia para medir o tamanho no funcional de mente utilizada para clculo de outras mtricas derivadas.
um produto de software, para dar suporte a anlises de qua- A produtividade, por exemplo, ser diferente para projetos de
lidade e produtividade; melhoria e de desenvolvimento, mesmo que tenham a mesma
Uma metodologia para estimar custos e recursos necessrios quantidade de pontos de funo ou pontos SNAP:
ao desenvolvimento e manuteno de software; Projeto de desenvolvimento: quando estivermos metrifican-
Um fator de normalizao para a comparao de softwares; do a criao de um determinado software.
Uma metodologia para determinar o tamanho no funcional Projeto de melhoria: quando estivermos alterando um soft-
de um pacote de aplicativos adquirido, atravs da avaliao de ware existente.
todas as partes e categorias includas no pacote; Aplicao quando estivermos medindo uma aplicao j
Uma metodologia para ajudar os usurios a determinar os existente.
benefcios de um pacote de aplicativos para sua organizao,
atravs da avaliao de partes ou categorias que satisfaam O escopo ser criado a partir do propsito da contagem e
seus requisitos especficos. define o conjunto de requisitos no funcionais do usurio a
serem includos na avaliao. O escopo pode incluir mais de
O processo de avaliao no funcional uma aplicao e, normalmente, ir incluir um conjunto de par-
Na Figura 1 temos uma viso geral do processo SNAP. ties, alm de uma lista de categorias e subcategorias SNAP.
O primeiro passo tem uma viso mais conceitual, mas que Tanto as parties quanto as categorias sero detalhados nos
importante para orientar os passos seguintes. No segundo, prximos tpicos.
normalmente utilizaremos o guia como referncia para con- A fronteira da aplicao tambm um conceito comum com
seguir escolher as categorias corretas. Os demais (passos 3 a 6) a APF e a separao conceitual entre o software avaliado
representam os passos mais prticos da contagem. e seus usurios. a fronteira que define o que externo

Edio 66 - Engenharia de Software Magazine 25

aplicao. O IFPUG costuma dizer que a fronteira funcio-
na como uma membrana pela qual os dados so recebidos
pela aplicao, processados e devolvidos para o usurio.
A fronteira no deve considerar questes estritamente tc-
nicas para ser definida.
Uma partio define um conjunto de funes do software,
dentro de uma mesma fronteira, que compartilham critrios de
avaliao do SNAP e que exigem esforo para implementao
que no seriam cobertos por uma mtrica APF. As parties,
assim como as funcionalidades medidas em APF, devem ser
baseadas na viso do usurio, no podem ter sobreposies e
serviro para atender aos requisitos no funcionais do softwa-
re. Na Figura 2 representamos visualmente alguns dos itens
relacionados ao passo 1.
Figura 2. Viso de alguns conceitos do passo 1 do SNAP
A segunda seo do SNAP trata de como vamos relacionar
cada requisito funcional a uma categoria e subcategoria SNAP.
As categorias foram criadas de forma generalista para tentar
agrupar necessidades no funcionais, mesmo que ainda nem
foram inventadas ou definidas. A diviso contempla todos os
requisitos tcnicos e de qualidade conforme definidos na ISO/
IEC 9126-1 ou pela ISO/IEC 25010. As categorias SNAP esto
agrupadas da seguinte forma:
Operaes de Dados
- Validaes na Entrada de Dados
- Operaes Lgicas e Matemticas
- Formatao de Dados
- Movimentaes de Dados Internos
- Entregar valor agregado aos usurios por configurao de
dados
Projeto de Interface
- Interfaces do Usurio
- Mtodos de Ajuda
- Mltiplos Mtodos de Entrada
- Mltiplos Mtodos de Sada
Ambiente Tcnico
- Mltiplas Plataformas
- Tecnologia de Banco de Dados
- Processos Batch
Arquitetura
- Software baseado em componentes
- Mltiplas Interfaces de Entrada / Sada
26 Engenharia de Software Magazine - IFPUG SNAP: medindo requisitos no funcionais
Como contar
A terceira seo do SNAP comea a contagem dos pontos
no funcionais propriamente dita, identificando as unidades
de contagem SNAP (UCSs). A medio ser feita nos passos
seguintes para cada UCS. importante saber que um mesmo
requisito de usurio pode gerar, ao mesmo tempo, pontos de
funo e pontos no funcionais (pontos SNAP). O UCS pode ser
uma atividade, um componente do software ou um processo
que se enquadre na estrutura de categorias apresentada no
tpico anterior.
Na quarta seo vamos definir a complexidade de cada UCS
mapeado na etapa anterior. De acordo com a categoria e sub-
categoria em que o UCS foi identificado, responderemos um
conjunto de questes disponveis no guia, que diro a comple-
xidade deste UCS. De acordo com a complexidade levantada,
cada UCS receber uma pontuao no funcional.
Na quinta seo vamos calcular a quantidade de pontos
SNAP (PS) totais por subcategoria. Para isso devemos somar o
tamanho obtido para cada UCS no passo anterior. importante
observar que um mesmo UCS poder gerar PSs para mais de
uma subcategoria, quando este estiver relacionado a mais de
uma categoria ou subcategoria.
J no sexto e ltimo passo, devemos somar as parciais ob-
tidas por subcategoria para chegar aos totais por categoria.
Na sequncia, somaremos todos os PSs para obter o tamanho
no funcional total, para nosso projeto ou aplicativo.
Exemplo de contagem
Nosso exemplo ser estruturado em trs etapas. Na primei-
ra parte iremos apresentar a descrio de uma determinada
demanda de desenvolvimento. Na segunda, iremos seguir o
processo SNAP para calcular o tamanho no funcional da de-
manda. Na ltima, iremos mostrar informaes que podemos
derivar das mtricas iniciais, e como podemos nos beneficiar
destes nmeros ao longo do ciclo de vida do projeto e do hist-
rico da empresa. Em alguns momentos, alguns detalhes podem
ser ocultos para tornar o exemplo mais didtico.
A Tabela 2 representa a solicitao do nosso cliente fictcio,
que a primeira parte do nosso exemplo. Nela representamos
uma requisio de funcionalidades que, indiretamente exige a
implementao de um conjunto de requisitos no funcionais.
No escopo deste exemplo, no focaremos na medio do ta-
manho funcional da demanda.
De acordo com a Figura 1 comearemos nossa contagem
fazendo algumas definies conforme detalhamos abaixo:
Propsito da contagem: fornecer o tamanho no funcional
da demanda para calcular todas as mtricas que permiti-
ro gerar os custos da demanda 0001 do sistema de Gesto
Patrimonial;
Tipo da avaliao: projeto de melhoria;
Escopo da avaliao: est definido na ficha representada
na Tabela 2;
Fronteira: no exemplo no temos muitos detalhes do sistema,
mas neste caso no fica dvida do que faz parte da fronteira
da aplicao que est sendo contada;

Parties: no escopo desta contagem temos apenas uma
partio.
Na medio do tamanho no funcional deste exemplo iremos
considerar os requisitos relacionados apenas a uma das categorias
do SNAP, a Operaes de dados. Como abordamos anterior-
mente, cada categoria exige um tratamento especial, e de acordo
com o escopo do artigo no seria possvel exemplificar todas as
categorias, mas o processo para cada uma delas o mesmo.
Solicitao de implementao - 0001 Sistema: Gesto patrimonial Solicitante: Thiago Cunha
Criar um cadastro de ativo que ir compor um novo mdulo de gesto de ativos do sistema de
gesto patrimonial.
Campos:
ID do ativo - Alfanumrico - Opcional
Cdigo corporativo - Numrico - Opcional
Nome do ativo - Alfanumrico - Obrigatrio
Valor estimado - Numrico - Opcional - Maior que zero - Reais
Data aquisio - Data Opcional - YYYY/MM/DD
Depreciao - Numrico - Obrigatrio - Maior que zero - Percentual
Tabela 2. Solicitao feita por nosso cliente fictcio
Agora vamos completar o segundo passo do SNAP (asso-
ciar RNFs com categorias e subcategorias) e tambm definir
o terceiro. Podemos observar neste exemplo a ocorrncia de
algumas subcategorias de Operao de dados listadas a seguir.
Para cada uma contaremos um UCS, j que estamos contando
apenas uma funcionalidade. Definindo a complexidade e a
quantidade de pontos de cada UCS, estaremos cumprindo os
passos 4 e 5 respectivamente:
Validaes na Entrada de Dados:
Pela solicitao recebida, temos que validar os campos Valor
estimado e Depreciao, pois ambos exigem valores positi-
vos. No primeiro caso, a validao s ser feita se o campo for
preenchido, ou seja, se eu no digitar nenhum valor, eu no
precisarei validar se ele maior que zero. Este tipo de valida-
o condicional o que chamamos de nvel de aninhamento.
J cada campo validado ser chamado de DER. Com estas
informaes j podemos entender a tabela de referncia desta
subcategoria, conforme a Tabela 3.
Nvel de complexidade
Baixa Mdia
Critrio 1-5 aninhamentos 6-14 aninhamentos
Frmula (PS =) 2* #DERs 3* #DERs
Tabela 3. Frmulas da categoria Validaes na Entrada de Dados
Como no nosso exemplo temos apenas dois nveis de aninha-
mento de validaes, o nvel de complexidade desta subcate-
goria ser baixo e para calcular os Pontos SNAP da mesma,
vamos utilizar a primeira frmula, ou seja, teremos 2 * #DERs.
J que teremos dois campos validados teremos 4 PSs relativos
Validaes na Entrada de Dados.
agilidade
Formatao de Dados:
Nesta subcategoria tambm utilizaremos o termo DER, s
que para denotar os campos que so formatados ou converti-
dos para exibio. J para definir a complexidade desta UCS a
regra um pouco menos matemtica e mais textual, conforme
a Tabela 4.
Nvel de complexidade
Baixa Mdia Alta
Converses de tipos de
Casos que no sejam Criptografia ou
Critrio dados ou formatao
Baixa ou Alta descriptografia
simples
Frmula (PS =) 2* #DERs 3* #DERs 5* #DERs
Tabela 4. Frmula da categoria Formatao de dados
Em nosso exemplo temos trs casos de formatao de
valores, sendo uma formatao de data, uma de moeda e
uma de percentual. Em todos os casos temos formataes
simples, caracterizando que o nvel de complexidade desta
UCS baixo. Desta forma utilizaremos a primeira frmula da
tabela chegando a 6 PSs relativos Formatao de dados.
De acordo com o ltimo passo do SNAP, podemos obter
o total de SPs da nossa demanda. Neste exemplo teramos
10 SPs. importante ressaltar que este valor representa o
tamanho no funcional da demanda. O tamanho funcional
(PFs) ainda precisaria ser medido em pontos de funo de
forma independente.
Para casos mais complexos, poderamos ter UCS de vrias
categorias e subcategorias relacionados a um mesmo requi-
sito de usurio. Para cada subcategoria, o APM apresenta
uma diferente tabela para clculo da complexidade da UCS.
Neste exemplo, apresentamos duas destas tabelas. As de-
mais so parecidas e podem ser utilizadas facilmente com
o apoio do guia.
Com isso, podemos perceber que boa parte das etapas
de medio tem caractersticas comuns com o processo do
SNAP, o que pode facilitar o aprendizado e aceitao desta
nova metodologia pelo mercado. Por outro lado, no SNAP
temos diferentes parmetros na contagem de acordo com a
categoria no funcional coberta, o que torna mais importante
o uso de referncias durante a contagem.
Aps conhecer os conceitos bsicos e possuir um guia de
referncia com as categorias e pontuaes de referncia,
Alta
um profissional no ter grande dificuldade para fazer
15+ aninhamentos
contagens. Este artigo fornece a viso conceitual, mas no
4* #DERs
fornece o guia de categorias e suas frmulas que pode ser
o prprio guia disponibilizado pelo IFPUG.
Apesar de vrias compatibilidades, de acordo com a verso
atual do APM, o tamanho total da aplicao no deve ser
obtido atravs da soma do PFs e dos SPs. Cada uma das con-
tagem deve ser tratada de forma independente. O IFPUG ain-
da planeja novas pesquisas relacionadas possibilidade de
utilizar uma nica mtrica como tamanho total (funcional
mais no funcional) e quais seriam as implicaes disso.
Edio 66 - Engenharia de Software Magazine 27
 Sobre o impacto de um ponto SNAP na produtividade ou Links:
esforo total, somente o uso em determinado contexto pode
trazer respostas. Assim como com os pontos de funo, cada IFPUG
combinao de equipe de desenvolvimento, cliente e processo, http://www.ifpug.org/
tero diferentes produtividades. Grupo de discusso SNAP (requer aprovao)
Com relao tcnica de fator de ajuste, pudemos observar http://www.linkedin.com/groups?home=&gid=1854919&trk=anet_ug_hm
que esta foi descontinuada e no deve mais ser utilizada como
forma de medir requisitos tcnicos e de qualidade de projetos BFPUG: Comunidade nacional sobre mtricas
http://www.bfpug.com.br/
e aplicativos, tornando o SNAP uma excelente opo para este
tipo de medio em projetos e aplicativos que utilizem ou no
a APF para medir os requisitos funcionais. Voc gostou deste artigo?

D seu voto em www.devmedia.com.br/esmag/feedback

Ajude-nos a manter a qualidade da revista!

28 Engenharia de Software Magazine - IFPUG SNAP: medindo requisitos no funcionais

Planejamento e Gerncia
Nesta seo voc encontra artigos voltados para o planejamento
e gerncia de seus projetos de software.
Use Case Point: Estimativas de Projeto
Parte 1
Medio de software
Anderson Pinheiro Balbo
anderson.balbo@gmail.com
Possui graduao em Informtica com nfase
em Gesto de Negcios pela Faculdade de
Tecnologia da Zona Leste, especializao em
Engenharia de Software pelo Instituto de
Computao-UNICAMP e especializao em
Gesto de Projetos em TI pela Fundao Carlos
Alberto Vanzolini-USP. Atualmente supervi-
sor de TI na Caixa Econmica Federal.
Wilson Vendramel
wilson.vendramel@fatec.sp.gov.br
Possui especializao em Engenharia de
Software e mestrado em Cincia da Com-
putao pelo Instituto de Computao-
UNICAMP, e especializao em Melhoria
de Processo de Software pela Universidade
Federal de Lavras. Atuou como Especialista
de Sistemas na IBM Brasil.
Maria Beatriz Felgar de Toledo
beatriz@ic.unicamp.br
Possui graduao e mestrado em
Cincia da Computao pelo Instituto de
Computao-UNICAMP e doutorado em
Sistemas Distribudos pela Universidade de
Lancaster, Inglaterra. Atualmente profes-
sora associada na Universidade Estadual de
Campinas. Tem interesse nas reas de ges-
to de processos de negcio, servios Web,
Web semntica e arquiteturas orientadas a
servios.
Este artigo faz parte de
um curso
A
s empresas que concorrem no
mercado de software buscam
constantemente aperfeioar a
qualidade dos seus servios prestados,
a fim de obter diferencial competitivo e
fidelidade do cliente. Uma das maiores
preocupaes dessa indstria tem sido a
previsibilidade de projetos, onde apenas
34% dos projetos de software atingem
seus objetivos dentro do cronograma e
oramento planejados.
Decises que so tomadas com ba-
ses empricas conduzem o projeto a
dados de prazo e custo inconsistentes.
O Standish Group destaca que 43% dos
erros localizados em um projeto esto
relacionados ao fator custo. Dessa for-
ma, as consequncias imediatas de um
processo de software sem planejamento
Edio 66 - Engenharia de Software Magazine
Fique por dentro:
Um grande desafio dos Gestores de Projetos
de Software tem sido a estimativa de prazo,
custo, e esforo adequados durante o ciclo de
vida do software, desde o planejamento at
o produto final. Este trabalho mostra como a
aplicao de medidas se torna uma importan-
te ferramenta de apoio a deciso no planeja-
mento de projetos de software, permitindo ao
lder responsvel a adequao dos elementos
necessrios para a entrega do produto ou
servio com qualidade, usando a tcnica Use
Case Point e considerao de seus resultados
aplicados no estudo de caso de uma fbrica de
software.
das estimativas so a falta de controle
adequado de custo e cronograma e a
inadequao dos mesmos no ciclo de
vida do projeto.
Diante dos problemas apresentados,
desejvel que a empresa possua o conhe-
cimento sobre as tcnicas de estimativa
para o projeto em questo, assim como
fundamental que haja uma base de
dados a respeito de projetos anteriores
e que possibilitem o seu aproveitamento,
29
pois dessa forma o gerente estar capacitado a planejar o pro-
duto a ser desenvolvido baseando-se em informaes concisas
e realistas.
Gestores que tomam decises com bases empricas tendem
a estimar prazos fictcios, na maior parte dos casos, a favor
do cliente, uma vez que so pressionados por um mercado
competitivo onde o menor custo e prazo so determinantes
para a escolha do fornecedor de software.
Consequentemente, a ausncia de tempo necessrio para as
etapas do ciclo de vida do projeto levam as equipes a reduzir
o esforo; em alguns casos, excluem atividades consideradas
menos importantes (anlise e testes, em geral, so deixados de
lado, e a prioridade dada para a codificao). Dessa forma,
o produto, ao passar por uma auditoria de qualidade, retorna
s mos de seus desenvolvedores, gerando o retrabalho e a
necessidade de um prazo maior para entrega, no antes esti-
pulado. Com isso, o custo tambm ampliado, gerando outros
problemas como a insatisfao do cliente.
A adaptao do processo de software ao cronograma e
custo previamente estimados reduz a possibilidade de erros
no produto, considerando que ele ser produzido dentro do
tempo necessrio para as atividades propostas. Os integrantes
da equipe conhecero as suas atribuies claramente, uma
vez que trabalharo no prazo acordado para a realizao das
etapas de desenvolvimento.
Neste contexto, o objetivo desta srie de artigos apresentar
a tcnica adequada para as estimativas de custo, esforo e
prazo necessrios em uma organizao cuja finalidade seja a
produo de software.
Medidas de software
A medio de software pode ser considerada um fator crucial
para concretizar a gesto das melhorias de processo, pois a
base para se manter o controle do mesmo, alm de ser tratado
como indicador de desempenho de software.
As medies que tratam de tamanho associado ao custo,
prazo e esforo em processo de desenvolvimento de software
so considerados fatores primordiais de sucesso em gerencia-
mento de projetos.
As estimativas documentadas constituem a base para a ela-
borao de um plano do projeto de software. As estimativas
de tamanho de projetos de software devem ser utilizadas para
a derivao das estimativas de custo, esforo e cronograma,
conforme as diretrizes do CMMI.
As medies que se referem ao tamanho, prazo e esforo so
denominadas operacionais, pois esto diretamente associadas
s estimativas do processo; as demais estimativas recebem
da operacional os recursos necessrios para outras medies,
conforme segue:
Medies Estratgicas: so medies de comparao com
os padres de qualidade e em relao s demais empresas de
tecnologia, assim como o diagnstico do custo do software e
seus componentes associados;
Medies Tticas: so medies responsveis por dar suporte
gesto do ambiente de software e analisar as tendncias
30 Engenharia de Software Magazine - Use Case Point: Estimativas de Projeto Parte 1
desse ambiente em relao qualidade, custo, produtividade
das pessoas e processos, alm dos impactos causados pelas
inovaes tecnolgicas.
Quando se fala a respeito de medies, importante distin-
guir esse termo de medida e mtrica, embora ambos estejam
intimamente ligados com o primeiro. A medida em engenharia
de software pode ser entendida como um indicador quan-
titativo de um atributo, enquanto que a medio o ato de
determinar a medida, e a mtrica a quantidade de medidas
individuais de um atributo ou processo de desenvolvimento.
Com isso, entende-se que a medida de software possa mensu-
rar extenso, capacidade, ou qualquer outro fator quantitativo
que esteja relacionado a uma caracterstica ou propriedade
envolvida. Atravs da medio so descritas as medidas ne-
cessrias para se obter os valores e resultados.
O conjunto de medidas obtido conduz s mtricas, permitin-
do a extrao de dados que, aliados a um indicador, permitem
a anlise conjunta do universo de pesquisa. O indicador o
valor ou o agrupamento de valores de referncia que, quando
comparado com as mtricas, permite analisar se estas esto
ou no ajustadas com o valor esperado.
O processo de medio pode ser dividido em formulao,
coleta, anlise, interpretao e realimentao. A atividade
de formulao abstrai as medidas e mtricas adequadas do
projeto, considerando apenas aquelas que sejam viveis para
a anlise. A coleta acumula os dados abstrados do projeto,
que daro suporte anlise. A atividade de anlise calcula as
mtricas. A interpretao analisa as mtricas calculadas em
busca da representatividade das informaes. A atividade de
realimentao leva equipe as orientaes para o ajuste do
processo, de acordo com as informaes interpretadas.
Classificao das mtricas de software
Em geral, as mtricas podem ser classificadas conforme a
sua complexidade de medio, modelo de abstrao utilizado
no desenvolvimento do software, ou ainda com foco em um
determinado fator de anlise no projeto. Chiossi e Germano [3]
as classificam conforme a sua aplicao, podendo ser diretas ou
indiretas, tradicionais, de sistemas estruturados ou orientados
a objetos, e ainda em mtricas de produtividade, qualidade,
tcnicas, ou orientadas a pessoas.
As mtricas diretas so obtidas de atributos facilmente quan-
tificveis como tempo de durao, linhas de cdigo, custo, entre
outros; as mtricas indiretas so derivadas de duas ou mais
mtricas simples, para gerar informaes como qualidade,
complexidade do produto, confiabilidade e outros.
As mtricas tradicionais baseiam-se nos dados que so inse-
ridos no sistema e nas informaes que so geradas pelo mes-
mo, ou simplesmente entrada/sada; as mtricas de sistemas
estruturados tm como abordagem as medies em diagrama
de fluxo de dados, enquanto as mtricas orientadas a objetos
concentram-se em diagramas como os de classes.
As mtricas de produtividade obtm do resultado do processo
a produtividade da equipe; as mtricas de qualidade validam

as funcionalidades do produto contra os requisitos do cliente;
as mtricas tcnicas destinam-se aos atributos do software,
independente do processo no qual foi desenvolvido; as mtricas
orientadas a pessoas concentram-se na forma como as pessoas
desenvolvem o software e a sua interao com as ferramentas
e mtodos de desenvolvimento.
Mtricas utilizadas no Projeto
Para que uma mtrica seja vivel em um projeto, ela deve ter
atributos mensurveis, e no sofrer influncia dos envolvidos
no projeto; a coleta de dados tambm no deve prejudicar o
processo de desenvolvimento [3]. Alm disso, as mtricas de-
vem ser analisadas sob o ponto de vista de pessoas, processo
e produto (ver Figura 1).
Figura 1. Mtricas associadas ao projeto
As mtricas de projeto e seus indicadores so utilizados por
um gerente e sua equipe, a fim de adaptar o fluxo de trabalho e
as atividades tcnicas que agregam valor ao projeto, tornando
essas mtricas estratgicas.
A partir da obteno das medidas de esforo e tempo em
projetos anteriores, so formados indicadores que podem ser
usados com as atuais medies do projeto, gerando estimativas
que auxiliem nas decises do gerente. Essas decises tm como
objetivo reduzir o prazo do projeto atravs de correes de atra-
sos e problemas, e aperfeioar a qualidade do produto durante
o seu ciclo de vida, assim como a reduo de defeitos.
medida que os defeitos so minimizados, h melhoria da
qualidade do produto, e a quantidade de retrabalho durante o
projeto tambm reduzida; isso leva diminuio de custos
no projeto.
Embora cada modelo de medida possua suas prprias tc-
nicas de clculo, a maioria deles tem como base os pontos de
funo ou linhas de cdigo, dos quais derivam as mtricas de
produtividade.
As linhas de cdigo (LOC) so medidas que levam em con-
siderao a quantidade de linhas produzidas essenciais para
a execuo de um programa ou componente. Os pontos de
funo (FP), esto voltados ao domnio da informao que in-
terage com o software, e no s linhas de cdigo que definem
a funcionalidade do produto.
Dados estatsticos obtidos por Drach [4] confirmam que em
2001 apenas 30% das empresas utilizavam mtricas para medir
produtividade dos processos de software, sendo que 18,2%
planejamento
aplicavam a tcnica de pontos de funo, e 10,3% baseavam-se
em linhas de cdigo.
Um dos modelos mais recentes aplica o FP a casos de uso.
Esse modelo, criado em 1993, denominado Pontos por
Caso de Uso (UCP), e tem como finalidade a estimativa
de tamanho e esforo que so extrados diretamente dos
requisitos do projeto.
Mtricas de processo
As mtricas de controle, associadas ao processo, referem-se
durao, custo de esforo e nmero de incidentes associados
ao processo. Tambm fornecem indicadores que podem servir
como base para anlise em outros projetos, possibilitando que
se verifique o seu andamento, alm de possveis riscos e pro-
blemas, levando a melhorias nos processos de software.
Entretanto, a medio do processo somente determina a
qualidade do produto se associada medio deste.
Uma abordagem que auxilia na medio de processo a
Meta-Questo-Mtrica (Goal-Question-Metric - GQM). Esta
integra os objetivos das mtricas com os modelos de processo,
produto e perspectivas de qualidade de software, alinhando
as suas necessidades s metas da organizao e s questes
associadas ao seu aperfeioamento.
As metas so as expectativas da organizao de melhoria do
processo, como por exemplo, reduo do tempo de desenvol-
vimento, melhoria de produtividade da equipe, reduo do
retrabalho. As questes so indagaes associadas s metas
de melhoria, buscando na resposta a soluo pontual para o
problema levantado. As medies do processo, ao compor as
mtricas do GQM, fornecem os resultados das aes aplicadas
no processo, confirmando se as metas foram atingidas e se as
questes foram solucionadas.
Por envolver a qualidade do processo, a GQM pode ser situ-
ada no contexto da abordagem do CMMI.
Mtricas de pessoas
As mtricas de pessoas indicam a produtividade, tamanho
da equipe, quantidade de comunicao associada ao projeto e
habilidades individuais, possibilitando ao gerente verificar se
a equipe est alinhada com as necessidades do projeto. Uma
vez convertidos em indicadores, esses dados se tornam base
de anlise para futuras mtricas.
Podemos relacionar produtividade ao esforo utilizando a
equao: Produtividade = Esforo / Tamanho do software.
Considerando essa equao, pode-se concluir que o esforo
da equipe de software diretamente proporcional ao tama-
nho do software, e assim como o esforo, obtido atravs de
mtricas como a Anlise de Pontos de Funo ou Pontos por
Caso de Uso, por exemplo.
Mtricas de Produto
As mtricas preditivas, associadas ao produto, avaliam o seu
tamanho e complexidade da estrutura lgica, de dados e de
funes combinados ou isoladamente, alm da quantidade de
atributos e operaes em objetos, de um projeto.
Edio 66 - Engenharia de Software Magazine 31
 Fatores de Avaliao dos Indicadores de Produtos
Correo Determina se um programa est de acordo com a especificao e as necessidades do cliente
Confiabilidade Refere-se preciso com que o produto atende aos requisitos do cliente
Eficincia Suporte dos recursos de computao necessrios para que o produto desempenhe o seu papel
Integridade Refere-se ao controle do acesso aos dados do sistema
Usabilidade o esforo empregado na interao com o produto
Manutenibilidade Esforo vinculado correo de erros
Flexibilidade O quanto o programa suscetvel a alteraes
Testabilidade Grau de facilidade em se testar um programa contra as funes requeridas para o mesmo
Portabilidade Esforo necessrio para adequar o produto a outro ambiente operacional
Reutilizao Refere-se aos componentes (ou o programa como um todo) que possam ser utilizados por outras aplicaes
Interoperabilidade Grau de facilidade para a juno de sistemas

Tabela 1. Fatores de Avaliao dos Indicadores de Produtos

Os principais fatores avaliados pelos indicadores de produto estrutura das medidas que devem atender s necessidades
esto apresentados na Tabela 1. de informao, e o de processo, que define o processo de
As mtricas de produto podem ser divididas em classes de medio.
mtricas dinmicas, coletadas por medies de um programa
em execuo, e estticas, coletadas atravs de documentaes
ou dados do programa. Ao se medir um programa em exe-
cuo possvel verificar a sua resposta s aes do usurio
(confiabilidade) e se suas tarefas esto sendo executadas cor-
retamente (eficincia).
Quando a anlise feita a partir de documentos, ou de um
programa que no esteja em execuo, a documentao pode
fornecer ao usurio a viso do quanto o programa simples
de se manusear (usabilidade), e ao ser comparada contra o pro-
grama, possvel verificar se os requisitos foram corretamente
aplicados, no apresentando erros (manutenibilidade).

Medio prtica de software

A medio prtica de software (Practical Software Manage-
ment - PSM) tem o objetivo de fornecer as melhores prticas
e ferramentas de medio para a anlise de prazos e custos
em desenvolvimento de projetos de software e sistemas.
A ferramenta oficial do PSM o PSM Insight, que automatiza
os processos de medio (ver Figura 2).
O PSM foi desenvolvido pelo Departamento de Defesa e o exr-
cito norte-americano como um projeto que visa estabelecer um
processo adequado de medio para o gerenciamento de softwa-
re e sistema, assim como fornecer a base para uma comunicao
e tomada de deciso objetiva, e a base para o gerenciamento
do desempenho na organizao. Alm desses fatores, o PSM
tambm define os seguintes propsitos para o projeto:
Desenvolver prticas efetivas de medies destinadas s
necessidades de gerenciamento de informaes e tcnicas de
software e sistemas;
Passar para uso geral medidas integradas que resultem no
aumento de desempenho.
So apresentados dois modelos integrados para o PSM: o
de informao, responsvel pelo modo de especificao e a
Figura 2. Ferramenta oficial do PSM, o PSM Insight
Modelo de Informao
O modelo de informao composto por trs diferentes nveis
de medida, como consta a Tabela 2.
Detalhes da construo da medio permitem visualizar a
aplicao dos trs nveis de medida no modelo de informao,
identificados na Figura 3.
Os atributos das entidades so obtidos por mtodos de me-
dio, formando com isso as medidas bsicas. As funes de
medio so responsveis por agregar duas ou mais medidas
bsicas (o resultado so as medidas derivadas). Semelhante
s funes de medio, o modelo tambm utiliza clculos
algortmicos para gerar os indicadores que do suporte
informao.
Modelo de Processo
O modelo de processo do PSM composto por quatro ativi-
dades principais: planejar, aplicar, e avaliar as medies, alm
de estabelecer e sustentar o comprometimento, atividades essas
baseadas na sequncia tpica Planejar-Fazer-Verificar-Agir.

32 Engenharia de Software Magazine - Use Case Point: Estimativas de Projeto Parte 1


Nveis de Medida Descrio
Medida adquirida diretamente dos atributos de um produto ou processo
Bsica
em medio, convertidos em valores;
Derivada Medida adquirida atravs duas ou mais medidas;
Indicadores Conjunto de medidas que do suporte s necessidades de informao.
Tabela 2. Nveis de medida do modelo de informao
Figura 3. Construo de uma medio pelo PSM
Planejamento das Medies
A atividade de Planejamento das Medies identifica as ne-
cessidades de informao no projeto e a seleo de medidas
apropriadas que atendam a essas necessidades. Podemos asso-
ciar o planejamento formalizao da coleta de dados, anlise
e divulgao dos procedimentos adotados, incluindo assuntos
relacionados ao planejamento para avaliar os resultados das
medies na forma de produtos de informao.
O Planejamento das Medies tambm caracterizado por
prover a integrao das medies para o gerenciamento de
processos e projetos tcnicos existentes. Mais do que forar um
projeto a implementar e pr-definir medidas, o PSM, atravs
dessa integrao, assegura que as medidas selecionas sero
efetivas no contexto do projeto.
Aplicao das Medies
A Aplicao das Medies consiste em uma das atividades
ncleo que direcionam os requisitos dos usurios das medi-
es. Trata-se da coleta e processamento dos dados de medio.
Esses dados so utilizados tanto para atender s necessidades
de informaes individualmente como para as informaes
inter-relacionadas a outras questes.
Ela responsvel por gerar os produtos de informao para
apresentar os resultados de anlises, aes alternativas, e re-
comendaes para a tomada de decises no projeto.
Avaliao das Medies
A Avaliao das Medies aplica tcnicas de medio e
anlise a fim de avaliar o prprio processo de medio. Essa
planejamento
atividade se dispe a identificar aes de melhoria para ga-
rantir atualizao constante do processo, de modo a satisfazer
as necessidades de informao.
As aes de melhoria aumentam a qualidade do processo,
e consequentemente do projeto de desenvolvimento do sis-
tema, permitindo ao lder do projeto estabelecer parmetros
de controle das etapas do processo e a adequada anlise dos
resultados que geram diferencial competitivo organizao,
em relao s organizaes que no adotam os procedimentos
de melhoria.
Essa atividade no PSM permite que a organizao, ao deter
as informaes geradas pelas medies, promova o seu ama-
durecimento constante, em relao s medies obtidas.
Estabelecimento e Sustentao do Compromisso
Essa atividade assegura que as medies so suportadas
tanto a nvel organizacional quanto do projeto provendo
a infraestrutura organizacional e os recursos necessrios
para implementar um programa de medio vivel (ver
Figura 4).
Figura 4. Modelo de Processo de Medio do PSM
O Paradigma da Meta-Questo-Mtrica
O paradigma da GQM utilizado para suportar decises
sobre que medies devem ser feitas e a forma como elas sero
utilizadas. Essa abordagem surgiu a partir da dificuldade em
saber o que deve ser medido, e a necessidade de melhoria dos
processos levou os seus desenvolvedores a associarem essa
prtica aos estgios de maturidade do CMMI.
O GQM implica a construo de um modelo para medio
imprescindvel obteno dos resultados das mtricas.
Considerando o GQM como orientado s metas ou obje-
tivos, trs passos fundamentais para sua elaborao so
definidos:
Conceitual: define o objeto a ser medido, podendo ser um
produto, processo ou recurso;
Operacional: define questes para caracterizar o objeto de
estudo e o seu papel no contexto da qualidade;
Quantitativo: trata da obteno de um conjunto de dados
associados ao nvel de realizao conceitual e operacional, de
modo que sejam respondidos com o apoio das mtricas.
Edio 66 - Engenharia de Software Magazine 33
 Fases do GQM
Planejamento Relaciona a equipe que participar do GQM, seleciona a rea que deve ser melhorada, define os projetos que sero analisados pelo GQM, e treina a equipe para aplicao do GQM.
Definio Define os objetivos do GQM, adapta os modelos de software ao mtodo, define as questes a serem solucionadas, e promove a reviso dos planos de GQM.
Coleta de Dados Coleta os dados obtidos atravs das mtricas.
Interpretao Analisa os dados contra as questes, a fim de respond-las.
Tabela 3. Fases do mtodo GQM
Alm dos nveis de realizao, o GQM tambm prev qua-
tro fases para definir as medies, conforme apresentado na
Tabela 3.
Durante a elaborao do GQM, so produzidos cenrios
que apresentam os objetivos e as questes com as mtricas
associadas. O mapeamento desses cenrios tem como base
o ponto de vista do cliente, gerente de projetos, e integrantes
da equipe.
Os objetivos so compostos por propsitos, questes, objetos e
ponto de vista. Cada questo pode apresentar uma ou mais m-
tricas, de acordo com o processo em anlise (ver Figura 5).
Figura 5. Objetivo Verificar Aderncia ao Processo
Os resultados da implantao das mtricas, obtidas atra-
vs das questes de ordem operacional, possibilitam que
indicadores para anlises futuras mais consistentes sejam
gerados.
O GQM tambm recomendvel por se tratar de uma abor-
dagem objetiva dos problemas da organizao quanto aos
processos, que podem ser solucionados pelo levantamento
das questes pontuais que envolvem esses problemas, e cujas
repostas possam ser convertidas nas mtricas. Os resultados
so os dados estatsticos que do suporte a tomada de aes
corretivas.
34 Engenharia de Software Magazine - Use Case Point: Estimativas de Projeto Parte 1
Descrio
Tcnicas de estimativa
A evoluo tecnolgica trouxe aos ambientes de desenvolvi-
mento de software a oportunidade de trabalharem com novos
paradigmas de medio no projeto, pois para cada abordagem
de linguagem de programao utilizada, novos ajustes ou me-
todologias para obteno das mtricas eram adotados.
Nenhum modelo de estimativa adequado a todos os pro-
cessos de desenvolvimento, pois para cada um deles h uma
amostra limitada do projeto, passvel de ajustes para que possa
ser utilizado.
Os modelos utilizados para estimativas, quando tratam de
sistemas de grande extenso, podem dividi-los em componen-
tes menores (subsistemas), de modo a facilitar a anlise dos
dados na medio. Ao iniciar a anlise pelos componentes a
fim de se obter as estimativas de custo, adota-se a abordagem
bottom-up. Aps analisar os componentes separadamente em
uma abordagem bottom-up, os custos so adicionados, totali-
zando o esforo total para o desenvolvimento do sistema.
A anlise inicial pela tcnica top-down permite ao res-
ponsvel pela medio conhecer as interaes entre os
subsistemas na formao do sistema maior, possibilitando
a viso da funcionalidade do sistema. Alm destas, atri-
bumos estimativa top-down os custos relacionados ao
sistema como um todo, alm do gerenciamento do sistema
e sua documentao.
Ao se utilizar os modelos de medio, possvel justificar a
solicitao de recursos monetrios, de tempo e pessoas; avaliar
a necessidade de treinamento e recrutamento de pessoas; gerar
compensaes de produtividade, custo e qualidade; avaliar
e mitigar o impacto das mudanas; negociar o oramento de
acordo com as novas exigncias de desenvolvimento. Essas
razes para estimar o custo de software explicam o uso dos
modelos de estimativas.
A seguir sero apresentados os modelos CoCoMo 81 e sua
verso atual (CoCoMo II), alm do mtodo de Delphi, o mo-
delo de Anlise de Pontos de Funo, e o modelo de Pontos
por Caso de Uso.
CoCoMo 81 X CoCoMo II
O Modelo de Custo Construtivo (Constructive Cost Model -
CoCoMo) foi baseado inicialmente em uma anlise de banco de
dados com 63 projetos, realizada na dcada de 70 pelo Prof. Dr.
Barry Boehm, da Universidade do Sul da Califrnia. O modelo
fornece frmulas detalhadas para determinar o cronograma do
tempo de desenvolvimento, alm de ser o mais completo para
estimativas de esforo baseado em linhas de cdigo.

Ao se analisar as linhas de cdigo como fator de clculo
no CoCoMo, importante desconsiderar as linhas de co-
mentrios no cdigo do programa, pois no so essenciais
para a execuo do mesmo; elas apenas descrevem as ca-
ractersticas ou aes que o trecho do cdigo realizar no
programa.
Dessa forma, as linhas de comentrios precisam ser excludas
para, a seguir, elaborar o modelo com base em trs modos de
desenvolvimento:
Embutido: o desenvolvimento no modo embutido aplicvel
a ambientes onde h constantes inovaes, com rgidas restri-
es e alteraes mais frequentes em requisitos;
Orgnico: dedicado a ambientes estveis, com equipe peque-
na e que desenvolvem sistemas relativamente simples;
Geminado: dedicado a ambientes que possuem caractersti-
cas do modo embutido e do modo orgnico.
O CoCoMo 81 conta com os estgios de desenvolvimento
bsico, intermedirio e completo, evoluindo de um para outro
medida que seus detalhes so implementados.
O modelo bsico tem como foco fornecer a estimativa de
forma rpida, e tambm mede o tamanho do programa em
linhas de cdigo para obter as estimativas de esforo e custo
no projeto.
No contexto do modelo bsico, o modo orgnico tem uma
produtividade de, por exemplo, 352 LOC por pessoa em um
ms, enquanto que esse valor cai para 105 LOC no modo
embutido.
Chiossi e Germano [3] utilizam o tamanho em milhares de
linhas de cdigo (KLOC) para expor os mtodos de clculo
do esforo (E) e do tempo em meses de desenvolvimento (Td),
considerando vinte e dois dias de trabalho por ms, para os
trs modos de desenvolvimento (ver Tabela 4).
Esforo nominal
Modo
Modelo Bsico Modelo Intermedirio
Orgnico E = 2,4 S 1,05 E = 3,2 S 1,05
Geminado E = 3,0 S 1,12 E = 3,0 S 1,12
Embutido E = 3,6 S 1,20 E = 2,8 S 1,20
Tabela 4. Equaes dos modelos bsico e intermedirio do CoCoMo
Supondo, para um projeto de software desenvolvido no modo
embutido, uma estimativa de 70 KLOC para uma aplicao.
Atravs do modelo bsico, o esforo requerido e o tempo de
desenvolvimento dessa aplicao podem ser calculados con-
forme segue:
Esforo = 3,6 X 40 1,20 = 301 pessoas-ms
Tempo = 2,5 X 301 0,32 = 15,5 meses
Logo, o clculo do nmero de pessoas necessrio no projeto :
N = 301 / 15,5 = 20 pessoas
planejamento
O modelo intermedirio considera, alm das linhas de cdigo,
15 fatores direcionadores de custo (cost driver), com valores
pr-determinados e que auxiliam o responsvel pela mtrica
a se dedicar a uma anlise apurada que associe o cost driver
certo a formula, de forma a gerar informaes mais precisas.
De acordo com Chiossi e Germano [3], aps calcular o esforo,
deve-se multiplicar o resultado pelo valor fornecido na Tabela 5,
de modo a ajustar o esforo aos atributos que interagem com
o projeto e que, portanto, interferem no desenvolvimento do
sistema.
Considerando um projeto desenvolvido no modo embutido,
e utilizando o modelo intermedirio para a produo de 20
KLOC, temos o seguinte esforo:
Esforo = 2,8 X 20 1,20 = 102 pessoas-ms
Cada um dos fatores de ajuste pode adequar o esforo de
forma a se aproximar da realidade do desenvolvimento. Por
exemplo, em um ambiente onde a capacidade do programador
alta e o tempo de resposta rpido, podemos adaptar o esforo
multiplicando-o por 0,86 e 1,07, respectivamente. O resultado
obtido (94), ajustado aos demais atributos direcionadores de
custo, compe o trabalho para a produo do software.
O modelo detalhado utiliza as mesmas equaes do interme-
dirio para obter a estimativa de esforo, entretanto duas carac-
tersticas so determinantes para reajustar as mtricas [3]:
Multiplicadores fase sensitivos para esforo: nele, a anlise
do cost-driver se aplica a cada fase do projeto, ao invs do pro-
jeto como um todo, pois alguns fatores podem ser alterados
no decorrer dessas fases;
Hierarquia do produto em trs nveis: a anlise do cost-
driver tambm abrange o nvel de sistema, subsistema e
mdulo.
A abordagem do CoCoMo II prope o desenvolvimento das
estimativas de custo associado ao reuso do cdigo. Utilizamos
Tempo nominal a seguinte frmula, com valores representados na Tabela 6,
para calcular o reuso do cdigo no CoCoMo II:
Td = 2,5 E 0,38
ESLOC = ASLOC x (AA + SU + 0,4 DM + 0,3 CM + 0,3 IM) / 100
Td = 2,5 E 0,35
O CoCoMo II tambm utiliza medidas indiretas de software,
como a contagem de telas, relatrios e componentes, citada
Td = 2,5 E 0,32
como contagem de pontos por objeto por. A seguir temos a
equao dos pontos de objeto para obter a produtividade,
considerando o cdigo reutilizado:
Nmero de Pontos de Objeto =
pontos por objeto X (100 - % de reuso)
100
Produtividade = Nmero de Pontos de Objeto / pessoa-ms
A Tabela 7 traduz o resultado dessa equao, onde possvel
concluir, atravs do nmero de pontos de objeto, se a comple-
xidade desses objetos simples, mdia ou difcil.
Edio 66 - Engenharia de Software Magazine 35
 Cost-Driver Descrio Muito Baixa Baixa Nominal Alta Muito Alta Extra Alta
Atributos do Produto
RELY Confiabilidade necessria nos requisitos 0,75 0,88 1,00 1,15 1,40 -
DATA Tamanho do banco de dados - 0,94 1,00 1,08 1,16 -
CPLX Complexidade do produto 0,70 0,85 1,00 1,15 1,30 1,65
Atributos do Computador
TIME Restries tempo de execuo - - 1,00 1,11 1,30 1,66
STOR Restrio armazenamento principal - - 1,00 1,06 1,21 1,56
VIRT Volatilidade da mquina virtual - 0,87 1,00 1,15 1,30 -
TURN Tempo de resposta - 0,87 1,00 1,07 1,15 -
Atributos do Pessoal
ACAP Capacidade do analista 1,46 1,19 1,00 0,86 0,71 -
AEXP Experincia na aplicao 1,29 1,13 1,00 0,91 0,82 -
PCAP Capacidade do Programador 1,42 1,17 1,00 0,86 0,70 -
VEXP Experincia com mquina virtual 1,21 1,10 1,00 0,90 - -
LEXP Experincia na linguagem de programao 1,14 1,07 1,00 0,95 - -
Atributos do Projeto
MODP Prticas modernas de programao 1,24 1,10 1,00 0,91 0,82 -
TOOL Utilizao de ferramentas de desenvolvimento 1,24 1,10 1,00 0,91 0,83 -
SCED Requisitos do cronograma de desenvolvimento 1,23 1,08 1,00 1,04 1,10 -

Tabela 5. Atributos (Cost drivers) considerados como previsores no CoCoMo [3]

Fator Representao Mtodo de Delphi

ESLOC linhas do novo cdigo O mtodo Delphi para obteno de estimativas de custo
ASLOC linhas do cdigo reutilizvel tem como objetivo ajustar as mtricas obtidas a fim de gerar
um valor mdio que torne os resultados mais precisos.
AA custo para avaliao de viabilidade do software
O mtodo de Delphi colabora com a coordenao das in-
SU custo necessrio para a compreenso do software pela equipe
formaes adquiridas e clculo de estimativas confiveis,
DM percentual do projeto modificado pelo reuso do cdigo atravs dos seguintes passos (ver Figura 6) :
CM percentual do cdigo modificado A especificao do projeto e demais informaes perti-
IM percentual de esforo de integrao do cdigo reutilizado nentes so apresentadas aos especialistas;
A reunio para discutir as estimativas formalizada;
Tabela 6. Representao da frmula de ajuste de esforo no CoCoMo II
Cada especialista preenche os formulrios com as suas
estimativas e esforos obtidos, acrescentando o valor pro-
Peso da complexidade vvel, com limite superior e limite inferior;
Tipo de Objeto
Simples Mdio Difcil As estimativas do grupo e individuais so resumidas em
Tela 1 2 3 um relatrio, acessvel a todos os envolvidos;
Relatrio 2 5 8 O coordenador, responsvel pelas etapas acima, convo-
ca uma reunio com os especialistas para discusso das
Componente 3 GL 10
estimativas geradas no relatrio.
Tabela 7. Um sistema de classificao por esteira rolante
O processo de levantamento das estimativas somente
Em seguida, o nmero de pontos de objeto dividido pelo termina quando a equipe chega a um consenso quanto
nmero de pessoas-ms, de forma a obter a estimativa de ao valor mais preciso. Peters e Pedrycz [6] apresentam o
produtividade da equipe de projeto e a maturidade / capa- consenso das estimativas individuais atravs do seguinte
cidade do ambiente. O nvel de produtividade muito baixo clculo:
tem valor 4, enquanto o valor 7 est associado a baixa ma-
turidade do ambiente e da equipe, o valor 13 considerado Estimativa = (LIe + 4 X estimativa mais provvel + LS e) /
normal, o nvel 25 est associada a alta produtividade, e 50 6, onde LI o limite inferior da estimativa e LS o limite
produtividade muito alta. superior da estimativa.

36 Engenharia de Software Magazine - Use Case Point: Estimativas de Projeto Parte 1

 planejamento

Como exemplo, um projeto de sistema

apresentado a sete especialistas, de
tal forma que todos so instrudos a
levantarem estimativas de custo para
produzir o software requerido.
Cada especialista analisa o projeto e ex-
trai dele os dados para medio, utilizando
a tcnica que consideram a mais adequa-
da. Aps obterem as mtricas necessrias,
os especialistas devem preencher formu-
lrios com questes que envolvem os re-
sultados individuais. Nele, os especialistas
incluem os desvios padro para o valor
Figura 6. Etapas para obteno das estimativas
aproximado gerado nos clculos.
O coordenador do processo rene as
sete estimativas e prepara o relatrio
com o consolidado das mesmas. O re-
sumo annimo, facilitando a anlise
imparcial do relatrio consolidado pelos
especialistas, conforme a Tabela 8.
Nela tambm apresentada a varincia
de cada especialista, que a mdia entre
o limite superior e inferior da estimativa.
Cada iterao tambm tem o propsito
de reduzir a varincia do grupo, pois Figura 7. Viso geral do processo de contagem de pontos de funo
isso pode significar o alcance do con-
senso dos especialistas. Nmero do especialista LI e Estimativa mais provvel LS e Estimativa Varincia
1 10 15 32 17 3,7
Anlise de Pontos de Funo 2 17 24 40 25,5 3,8
O modelo de Anlise de Pontos de Fun-
3 13 27 35 26 3,7
o foi criado na dcada de 70 por Allan
Albrecht, e aplicado pela IBM, levando a 4 18 30 37 29,2 3,2
criao do Grupo Internacional de Usu- 5 20 28 40 28,7 3,3
rios de Pontos de Funo em 1986. 6 14 25 36 25 3,7
A abordagem da contagem de pontos 7 23 30 39 30,3 2,7
de funo em uma aplicao surgiu
Mdia 16,4 25,6 37 26,0 3,4
como alternativa aos modelos baseados
em linhas de cdigo, pois consiste em Tabela 8. Mdia das estimativas e varincias
medir o tamanho do produto baseado
em especificao funcional, sem se pre- questo. Embora haja a entrada de novos instalao, incluindo a converso de da-
ocupar com a tecnologia utilizada no projetos para a empresa, alguns deles dos necessria para essa implantao;
processo, conforme ser visto adiante. no requerem que a equipe o desenvolva Contagem de projetos de melhoria:
A tcnica de Pontos de Funo tem do incio; existem projetos no qual o pro- mede a adio, modificao ou excluso
como foco os valores do domnio da duto vem parcial ou totalmente pronto, de funes em projetos j implantados,
informao, ou seja, as estimativas de sendo requisitado empresa o trabalho incluindo a converso de dados;
entradas, sadas, consultas, arquivos e de melhoria do produto. H casos tam- Contagem de uma aplicao: mede
interfaces externas para software CAD. bm em que o desenvolvimento ocorre as funcionalidades de sistemas de de-
A contagem dos pontos de funo, ne- em apenas um ou mais produtos que senvolvimento j implantados a fim de
cessrio seguir alguns passos, conforme compem o sistema. obter valores de referncia (baselines)
descrito na Figura 7. Drach [5] apresenta os trs tipos de atualizveis a cada medio dos projetos
contagem de pontos de funo, conforme de melhoria.
Tipo de contagem a sua aplicao no projeto:
Quando se planeja estimar um softwa- Contagem de projetos de desenvol- A definio do tipo de contagem
re, utilizando pontos de funo, deve-se vimento: mede a funcionalidade en- determinante para o clculo dos pontos
atentar quanto ao tipo de projeto em tregue ao usurio atravs da primeira de funo no ajustados.

Edio 66 - Engenharia de Software Magazine 37

Escopo da contagem e fronteira da aplicao Aps definir os EIs, EOs e EQs, deve-se identificar os DETs,
O escopo da contagem verifica se a medio envolve o sistema e os tipos de arquivos que so referenciados por uma transa-
completo ou apenas parte dele, se todas as funcionalidades so o (File Types Referenced - FTR). O FTR pode ser qualquer
requeridas, apenas as utilizadas pelo usurio, ou ainda algum arquivo lgico interno ou de interface externa, desde que
grupo especfico, como relatrios, por exemplo. tenha sido lido ou mantido atravs de uma transao, con-
A fronteira da aplicao pode ser entendida como a interface forme Tabelas 10 e 11.
entre o software a ser medido e qualquer usurio, sistema ou
outro agente que interaja com este. DET
Nmero de Elementos
O IFPUG determina que, para identificar a fronteira, esta deve 1 a 19 20 a 50 Maior que 50
ser baseada na viso do usurio, a fronteira entre aplicaes 1 Baixa Baixa Mdia
deve atender s regras de negcio e no a consideraes tec-

RET
2a5 Baixa Mdia Alta
nolgicas, e a fronteira inicial no deve ser influenciada pelo
Maior que 5 Mdia Alta Alta
escopo de contagem. Por fronteira inicial entende-se aquela
que j foi definida no incio do projeto. Tabela 9. Complexidade funcional dos ILFs e EIFs

Funes do tipo dados Nmero de Elementos

DET
Na anlise das funes do tipo dados, encontra-se aquelas refe- 1a4 5 a 15 Maior que 15
rentes a arquivos lgicos internos e arquivos de interface exter- 0a1 Baixa Baixa Mdia
na. Podemos defini-los, respectivamente, como agrupamentos
FTR
2 Baixa Mdia Alta
lgicos de dados dentro das fronteiras da aplicao e mantidos
por entradas externas, e agrupamentos lgicos de dados exter- Maior que 2 Mdia Alta Alta
nos aplicao e que fornece dados para a aplicao. Tabela 10. Complexidade funcional das Eis
Considerando esse ponto de vista, pode-se entender que os
arquivos lgicos internos (ILFs), so grupos de dados que so DET
Nmero de Elementos
produzidos e armazenados dentro da aplicao, enquanto que 1a6 6 a 19 Maior que 19
os arquivos de interface externa (EIFs), so grupos de dados 0a1 Baixa Baixa Mdia
que permanecem fora da aplicao em questo, ainda que
FTR

2a3 Baixa Mdia Alta

esteja dentro de uma outra aplicao, e fornecem dados para
a aplicao que est sendo medida, interferindo na contagem
dos pontos de funo.
Uma vez definidos os ILFs e EIFs, o prximo passo determi-
nar os tipos de elementos de dados (DETs) e tipos de elementos
de registros (RETs).
Os RETs so os grupos de dados reconhecidos pelo usurio
do sistema, e os DETs so campos no recursivos de infor-
maes dinmica, identificveis pelo usurio. Se um DET for
recursivo, apenas o levantamento da primeira informao a
respeito deve ser considerado para a contagem. A contagem
dos DETs e RETs permite a anlise da complexidade da funo
atravs da Tabela 9.
Funes do tipo transao
As funes do tipo transao descrevem as funcionalidades
de processamento de dados fornecidas ao usurio pela apli-
cao. Seus elementos de contagem so as entradas externas
(External Inputs - EIs), as sadas externas (External Outputs
- EOs), e as consultas externas (External Inquiries - EQs).
As entradas externas so processamentos de dados no sistema
originados pelo usurio ou por outro sistema. Essas entradas
de dados so usadas para atualizar os arquivos lgicos inter-
nos. As sadas externas so informaes fornecidas do sistema
para o usurio, como relatrios ou mensagens exibidas em
tela. As consultas externas so envios de dados para o sistema
com o objetivo de se obter respostas imediatas em forma de
novos dados.
Maior que 3 Mdia Alta Alta
Tabela 11. Complexidade funcional das EOs e EQs
Contagem de pontos de funo no ajustados
Uma vez identificadas s complexidades (baixa, mdia ou
alta) para os dados e transaes, o prximo passo calcular
os pontos de funo no ajustados (UFP). Os valores para cada
tipo de dado ou arquivo so pr-determinados, possibilitando
dessa forma o clculo de cada uma das funes do sistema
(ver Tabela 12).
UFP ILF = 7 x 3 ILF baixa + 10 x 3 ILF mdia + 15 x 3 ILF alta
UFP EIF = 5 x 3 EIF baixa + 7 x 3 EIF mdia + 10 x 3 EIF alta
UFP EI = 3 x 3 EI baixa + 4 x 3 EI mdia + 6 x 3 EI alta
UFP EO = 7 x 3 EO baixa + 10 x 3 EO mdia + 15 x 3 EO alta
UFP EQ = 7 x 3 EQ baixa + 10 x 3 EQ mdia + 15 x 3 EQ alta
UFP = UFP ILF + UFP EIF + UFP EI + UFP EO + UFP EQ
Tabela 12. Clculo dos pontos de funo no ajustados
Fator de ajuste
Todo sistema sofre a influncia de fatores externos, res-
ponsveis pelo desempenho do software e a sua resposta s
exigncias do usurio. Dessa forma, a contagem apenas da
complexidade dos dados e transaes torna-se insuficiente
para determinar o custo de um sistema. necessrio adaptar

38 Engenharia de Software Magazine - Use Case Point: Estimativas de Projeto Parte 1

 planejamento

Caractersticas Gerais do Sistema

Comunicao de Dados
Processamento Distribudo
Desempenho
Configurao Altamente Utilizada
Volume de Transaes
Entrada de Dados On-line
Eficincia do Usurio Final
Atualizao On-line
Processamento Complexo
Reusabilidade
Facilidade de Instalao
Facilidade de Operao
Mltiplos Locais
Modificao Facilitada
Refere-se comunicao da aplicao com o processador, atravs do envio e recebimento de dados.
Nvel em que a aplicao transfere dados entre os seus componentes.
Refere-se ao tempo de processamento e de resposta, alm das taxas de transao.
Mede o nvel de restries dos recursos computacionais no desenvolvimento das aplicaes.
Descreve a influncia das transaes no projeto, desenvolvimento, instalao e suporte da aplicao.
Descreve o nvel das entradas de dado realizadas pelas transaes.
So os fatores humanos como a facilidade de uso pelo usurio final.
Mede o nvel de atualizao dos ILFs on-line.
Refere-se ao nvel do processamento lgico ou matemtico na aplicao.
O quanto o cdigo projetado para uma aplicao pode ser reaproveitado em outra.
Nvel de adaptao entre a aplicao e o ambiente que a recebe.
Autonomia da aplicao para atividades de inicializao, segurana e recuperao.
Refere-se aplicao ter sido desenvolvida para locais ou organizaes diversas.
Nvel de flexibilidade para alterao do comportamento da aplicao.

Tabela 13. Fatores para Ajustes dos Pontos de Funo

o valor j obtido dos pontos de funo no ajustados com as Links e Referncias:

caractersticas gerais do sistema, que so os principais fatores
de influncia no funcionamento do produto (ver Tabela 13).
Cada fator para ajuste dos pontos de funo deve ser nivelado
quanto a sua influncia por pontuaes de 0 (zero) a 5 (cinco),
sendo respectivamente nenhuma, mnima, moderada, mdia,
significativa ou de grande influncia.
As pontuaes obtidas em cada um dos quatorze fatores de-
vem ser somadas, e seu valor total (V total) deve ser calculado
na seguinte frmula:
Pontos de Funo Ajustados = (V total x 0,01 + 0,65) x UFP
1. HAZAN, C.; STAA, A. Anlise e Melhoria de um Processo de Estimativas de
Tamanho de Projetos de Software. In: VI Simpsio Internacional de Melhoria
de Processos de Software. Rio de Janeiro: 2004, p.34.
http://www.simpros.com.br/simpros2004/VisualizarConteudo.aspx. 77.html
2. FERNANDES, A.A.; TEIXEIRA, D.S. Fbrica de Software: implantao e gesto
de operaes. So Paulo: Atlas, 2004.
3. CHIOSSI, T.C.S.; GERMANO, F.S.R. Gerenciamento de Projetos de Software.
So Paulo: UNICAMP - Universidade de Campinas, 2005.

4. DRACH, M.D. Aplicabilidade de Mtricas por Pontos de Funo em Sistemas

O tamanho funcional do sistema definido, podendo ser
utilizado como varivel para obteno do custo do software.
Os pontos de funo, por no depender da tecnologia emprega-
da, possibilitam uma melhor comparao entre projetos, alm
da elaborao das estimativas na fase inicial do projeto.
Voc gostou deste artigo?
Baseados em Web. So Paulo: UNICAMP - Universidade de Campinas, 2005.
http://libdigi.unicamp.br/document/?code=vtls000359854
5. ANDA, B. et al. Estimating Software Development Effort Based on Use
Cases - Experiences from Industry, Toronto: Departamento de Informtica
- Universidade do Oslo, 2001.
http://www.bfpug.com.br/artigos.htm

D seu voto em www.devmedia.com.br/esmag/feedback 6. VAZQUEZ, C.E.; SIMES, G.S.; ALBERT, R.M. Anlise de Pontos de Funo:
Medio, Estimativas e Gerenciamento de Projetos de Software. So Paulo:
Ajude-nos a manter a qualidade da revista! rica, 2003.

Edio 66 - Engenharia de Software Magazine 39

Planejamento e Gerncia
Nesta seo voc encontra artigos voltados para o planejamento
e gerncia de seus projetos de software.
Desvendando o gerenciamento de projetos
Parte 3
Fase de Iniciao
Ary dos Santos Rocha Jnior
ary@aryrochajunior.com.br
Bacharel em Cincia da Computao pela
Universidade Federal de Uberlndia, Mes-
tre em Cincias com nfase em Inteligncia
Artificial pela mesma Universidade. Possui
mais de 15 anos de experincia profissio-
nal, atuando sempre na rea de desenvol-
vimento de sistemas, liderana de equipes,
gerenciamento de projetos e como CIO.
40 Engenharia de Software Magazine - Desvendando o gerenciamento de projetos Parte 3
Este artigo faz parte de
um curso
N
os dias atuais, sabemos da
importncia de um bom ge-
renciamento de projetos. Por
consequncia, gesto de projetos um
dos principais assuntos discutidos em
boa parte das organizaes, principal-
mente pelos benefcios conquistados
com sua adoo ou prejuzos por no
se adotar gerenciamento de projetos de
forma efetiva.
Para que as organizaes realmente
colham resultados positivos na gesto
de projetos, elas devem se estruturar de
forma que uma metodologia de gesto
possa ser aplicada. O primeiro passo
para que isto ocorra capacitar um gru-
po de colaboradores em especfico para
as funes de gerenciamento de projetos
e das metodologias escolhidas para se
gerir qualquer projeto da empresa.
Fique por dentro:
Vamos apresentar de forma simples as princi-
pais reas e os principais processos necessrios
ao gerenciamento de um projeto que esto
contidos no Guia PMBOK 4 Edio. Neste ar-
tigo, em especfico, ser abordada a fase de
iniciao dos projetos. Assim, sero retratados
conceitos teis no gerenciamento de qualquer
projeto envolvendo tecnologia da informao,
desde desenvolvimento de aplicaes simples
at implantaes complexas de ERP. Conceitos
estes que qualquer gerente de projetos deve
ter em mente para serem aplicados em seu dia
a dia. No sero apresentados modelos dos do-
cumentos aqui citados, porm, voc pode cri-
los, desde que o contedo dos mesmos reflita a
necessidade do projeto.
Desta forma, os assuntos aqui rela-
cionados podem contribuir de forma
substancial para o enriquecimento dos
conceitos relacionados a gerenciamento
de projetos. Ao longo deste artigo per-
ceberemos a importncia de todos os
grupos de processos de gerenciamento
de projetos, mas em especial o primeiro
deles, que o grupo de processos de
iniciao.

Grupos de Processos de Gerenciamento de Projetos
O PMBOK considerado hoje um dos principais guias de
gerenciamento de projetos, sendo utilizado no mundo inteiro.
E neste guia, esto descritos os cinco grupos de processos de
gerenciamento de projetos. So eles:
1. Grupos de Processos de Iniciao;
2. Grupos de Processos de Planejamento;
3. Grupos de Processos de Execuo;
4. Grupos de Processos de Monitoramento e Controle;
5. Grupos de Processos de Encerramento.
O objetivo principal deste artigo focar no primeiro grupo
de processos de gerenciamento de projetos, que o grupo de
processos de iniciao. Dentre os cinco grupos de processos,
nenhum pode ser citado como o principal, nem o mais im-
portante; porm, iniciar bem um projeto o primeiro passo
para que este venha a ter sucesso. Caso no se inicie bem, os
problemas tendem a aumentar durante o projeto.
Um projeto, por definio, uma atividade ou grupo de
atividades que tem incio, meio e fim. Caso seja uma ativi-
dade que no se conclua, por exemplo, esta atividade uma
atividade rotineira, repetitiva e no pode ser considerado
um projeto. Todo projeto tem sua etapa de iniciao, poste-
riormente realizado o planejamento, em sequncia a exe-
cuo o projeto, durante todas as suas etapas, mantido sob
monitoramento e controle total do gerente de projetos. Por
fim, aps todas as atividades do escopo serem executadas, o
projeto encerrado.
O grupo de processos de iniciao consiste nos processos
realizados para que o projeto seja formalmente iniciado, como
o prprio nome j sugere. O primeiro passo a definio
do escopo do projeto e a alocao e aprovao dos recursos
financeiros para o mesmo. Neste momento tambm so iden-
tificadas todas as partes interessadas no projeto e tambm
formalizado o nome do gerente do projeto, que conduzir
todas as etapas do mesmo.
Aps a nomeao do gerente do projeto, ele deve iniciar suas
atividades e as principais aes a serem executadas so:
Examinar os objetivos do projeto e as restries que impactam
estes objetivos;
Desenvolver uma estratgia de aes para alcanar os obje-
tivos do projeto e os objetivos dos envolvidos e interessados,
e que, ao mesmo tempo, considere as restries;
Constituir uma equipe de projeto, identificar os outros recur-
sos necessrios e avaliar qual a disponibilidade de recursos
humanos e materiais para a execuo do projeto.
Alm destas atividades, o gerente de projetos deve sempre
atuar de maneira bem prxima aos patrocinadores do projeto,
deixando bem claros os principais objetivos:
Objetivos Tcnicos: o que ser entregue tecnicamente;
Objetivos de Prazo: qual o prazo estimado para se executar
o projeto e para que o mesmo seja entregue com sucesso;
Objetivos de Custo: qual o custo estimado do projeto, com
sua respectiva margem de erro;
planejamento
Objetivos de escopo: o que se espera em termos de caracte-
rsticas e funcionalidades do projeto, ou seja, qual o produto
ou servio que ser entregue no final do projeto.
Para que um projeto tenha um bom incio, ressalta-se que
as principais caractersticas de um gerente de projetos so:
ter atitude, ser responsvel, ser honesto e cativador de sua
plateia e equipe. Estas caractersticas devem ser muito bem
observadas ao selecionar o gerente do projeto. Com isto, por
consequncia, h uma probabilidade maior de que todos os
membros da equipe do projeto possam convergir para o ca-
minho que o gerente de projetos direcionar, minimizando o
risco de insucesso do projeto.
Com a nomeao do gerente do projeto, este ir atuar no
grupo de processos de iniciao. Para este grupo de processos
podemos citar cinco pontos de grande importncia, a saber:
1) Criao do Termo de Abertura do Projeto;
2) Criao de um plano de atividades para o projeto;
3) Definio dos recursos envolvidos por parte do cliente no
projeto;
4) Apresentao da metodologia de gesto de projetos para os
recursos do cliente;
5) Apresentao formal da abertura do projeto para os
envolvidos.
O primeiro ponto trata de um documento que formalmente
autoriza o projeto e contm os requisitos iniciais que satisfazem
as necessidades e expectativas das partes interessadas. O termo
de abertura deve conter obrigatoriamente as necessidades do
negcio, a descrio do escopo do produto ou servio e o plane-
jamento estratgico para o projeto. Este planejamento estratgi-
co do projeto deve dar suporte ao planejamento estratgico da
empresa e deve ser considerado em todo e qualquer momento
do projeto, ou seja, o planejamento estratgico do projeto deve
ser desenvolvido pensando no planejamento estratgico da
empresa de forma a garantir que a boa execuo do projeto ir
contribuir para que o plano da empresa tambm seja cumprido
de forma eficiente. Logo, o planejamento estratgico do projeto
deve estar sempre disposio dos stakeholders.
Outro ponto a ser considerado que no termo de abertura
no se deve esquecer-se de fazer referncia ao contrato que
faz a ligao entre contratante e contratada para a execuo
formal do projeto. De forma mais simples, podemos pensar que
para criar o termo de abertura do projeto, um dos principais
documentos que daro suporte a ele o contrato.
Depois de desenvolver todas essas atividades, pensar em
todos os aspectos supracitados, teremos a concluso do termo
de abertura consolidado em um documento contendo:
Ttulo do projeto: nome que ser dado ao projeto;
Misso do projeto: misso que o projeto deve cumprir;
Propsito e justificativa do projeto: objetivos do projeto,
qual o propsito dele para a companhia e as justificativas para
que ele seja executado;
Objetivos mensurveis do projeto e critrios de sucesso
relacionados: descrever os objetivos mensurveis do projeto
Edio 66 - Engenharia de Software Magazine 41
e quais os critrios e fatores de sucesso esto relacionados a
cada um para que se possa fazer esta medida e comparao
a qualquer momento;
Requisitos bsicos do projeto: definio de quais so os
requisitos bsicos para a execuo do projeto;
Descrio do projeto: descrio de todos os itens que
compem o projeto;
Riscos do projeto: documentao de todos os riscos do proje-
to, incluindo forma de combat-los e at mesmo elimin-los;
Resumo de cronogramas e marcos do projeto: deve-se
apresentar um resumo do cronograma macro e os macros
das pequenas entregas e validaes que o projeto poder
sofrer;
Resumo do oramento do projeto: descrio macro do
oramento aprovado para o projeto;
Requisitos para aprovao do projeto e das etapas subse-
quentes: definio e descrio dos requisitos para aprovaes
durante todo o desenvolvimento do projeto;
Gerente do projeto, responsabilidade e nvel de autoridade
designado: definio do gerente do projeto, suas responsabi-
lidades e nvel de autoridade que foi designado a ele;
Nome e autoridade do patrocinador do projeto, assim como
a assinatura do mesmo no referido documento, dando incio
formalmente ao projeto;
Identificao das partes interessadas: neste documento
todas as partes interessadas e seus respectivos interesses
devem estar devidamente documentados.
O principal objetivo do termo de abertura do projeto que
este documento sirva como base para aprovao ou no do
projeto. Sendo aprovado, o projeto torna-se oficialmente au-
torizado para ser iniciado. Neste momento os critrios para
o sucesso do projeto tambm so definidos, a influncia e os
objetivos das partes interessadas so avaliados. Com isto, h
uma definio clara se vai ser dado continuidade ao projeto, se
ele vai ser interrompido ou suspenso. Logo, este documento
deve estar assinado pelo gerente de projetos e tambm pelo
patrocinador do projeto, no mnimo.
No entanto, de uma forma geral, uma boa prtica envol-
ver o cliente desde a iniciao, aumentando a probabilidade
de sucesso, compartilhando melhor os riscos e objetivos do
projeto. Alm disso, a aceitao da entrega tende a ser mais
fcil e a satisfao do cliente e das partes interessadas tende a
aumentar. Tudo isto pelo simples fato deles terem participado
de todo o projeto, desde o incio.
Durante todo o projeto, praticamente tudo relacionado a ele
deve ser documentado e assinado por todas as partes interes-
sadas. Em especial, no grupo de processos de iniciao, este
cuidado deve ser ainda maior, para que o projeto seja bem
iniciado e qualquer problema futuro que possa ocorrer seja
resolvido com base em documentos previamente definidos.
Desta forma, ao criar o termo de abertura do projeto, deve
observar com clareza a descrio dos objetivos deste, inclusive
os motivos que caracterizam o referido projeto como a melhor
alternativa para a empresa.
42 Engenharia de Software Magazine - Desvendando o gerenciamento de projetos Parte 3
Como parte do grupo de processos de iniciao, o gerente
de projetos recebe a autoridade para aplicar recursos orga-
nizacionais s atividades subsequentes do projeto.
Outra atividade inerente ao grupo de processos de
iniciao a criao do plano de atividades do projeto.
Este documento nada mais do que uma lista de todas
as principais atividades que compem o projeto. O plano
de atividades deve descrever as macro atividades, pois na
prxima etapa do projeto, que engloba o grupo de proces-
sos de planejamento, ser desenvolvido um documento
que o plano do projeto e nele, todo o escopo e todos os
planos envolvidos no projeto estaro definidos minucio-
samente. Assim, nesse documento no h necessidade de
grande detalhamento e seu principal objetivo apresentar
aos stakeholders tudo o que ser feito durante o projeto.
Outro ponto importante a definio dos recursos
humanos envolvidos no projeto. Eles so de grande im-
portncia para que todas as atividades do projeto sejam
realizadas. Podemos dizer que a identificao e nome-
ao das pessoas chave da empresa, que iro compor a
equipe do projeto, um dos principais fatores para que o
projeto obtenha sucesso. Mas, como estas pessoas devem
ser escolhidas? Elas devem ser selecionadas levando em
considerao inmeros fatores, dentre os quais podemos
destacar: pr-atividade, conhecimento da rea em que atua
e nvel de envolvimento com a empresa. No entanto, tais
pr-requisitos no podem ser considerados como regra
geral. Cada cliente pode definir os seus prprios requisitos
desejveis para seleo de sua equipe, da melhor forma
que lhes convier. Aps a definio da equipe, importante
que o gerente de projetos avalie todos os integrantes e
informe ao patrocinador do projeto se alguma pessoa
selecionada pode gerar algum risco ao projeto. Tudo isto
para que o projeto realmente tenha os melhores recursos,
com a finalidade de minimizar os riscos e maximizar a
possibilidade de sucesso.
Para que todos os envolvidos no projeto tenham conhe-
cimento da forma com a qual o mesmo ser conduzido,
deve-se fazer uma apresentao da metodologia de gesto
do projeto. Assim, os stakeholders conhecero todos os
passos, alm de saber a necessidade e importncia da
documentao, cronogramas e prazos. Durante a apre-
sentao, o gerente do projeto pode conquistar e contagiar
todas as partes envolvidas no projeto, demonstrando toda
sua competncia para conduzir o projeto. Assim, o gerente
do projeto pode conseguir gerar como resultado da apre-
sentao, a garantia do controle do projeto, possuindo
responsabilidade mxima sobre a conduo do referido
projeto, possuindo confiana dos stakeholders.
A apresentao formal da abertura do projeto tambm
um item que compe o grupo de processos de iniciao. o
momento onde se apresenta todo o termo de abertura para
os patrocinadores do projeto, ou seja, para o cliente. Neste
momento que o termo de abertura assinado e o projeto
tem a autorizao para iniciar. Alm disso, este momento

de grande importncia para que qualquer desvio que possa
ser diagnosticado no incio do projeto seja sanado.
Em suma, o grupo de processos de iniciao consiste nos
processos realizados para executar as atividades ineren-
tes ao incio do projeto. Todas as atividades so de grande
importncia, haja vista que todo incio de projeto deve ser
documentado e assinado pelos stakeholders e sponsors. Em
todo em qualquer projeto, podemos fazer uma comparao
grosseira com a construo de uma casa. Toda construo
inicialmente precisa de uma fundao, de uma base slida,
para que a construo tenha uma boa qualidade e que a casa
tenha uma boa durabilidade. Se no for bem feita, no futuro
a casa poder apresentar problemas. Da mesma forma, em
um projeto, o grupo de processos de iniciao no pode ser
mal feito ou menosprezado. Apesar disso, vrios gerentes de
projeto esquecem este grupo de processos e j partem para o
planejamento ou mesmo para a execuo, o que um erro gra-
vssimo. Nestes casos, a qualquer momento que se necessitar
de algum documento anterior ao plano do projeto, o gerente
no ter nada em mos para recorrer.
Os grupos de processos de gerenciamento de projetos geram
uma srie de documentos com a finalidade de se documentar
todas as atividades do projeto. O objetivo principal dos mes-
mos deve ser registrar todos os fatos e atividades dos projetos,
unificando palavras e conceitos. Com isto, no haver a possi-
bilidade de uma pessoa A imaginar uma coisa e uma pessoa B
imaginar outra. Valer o que est escrito, documentado.
Alm disso, no se deve esquecer em momento algum, em
qualquer grupo de processos de gerenciamento de projetos,
dos registros das atas das reunies. Estes registros podem ser
registrados em papel, e-mail, vdeos de apresentaes, dentre
outros, desde que documente quem estava presente e tambm
as aprovaes, quando necessrio.
Para concluir, cabe reforar que a cautela com os itens de todos
os grupos de processos de gerenciamento do projeto deve ser
imperativa. Mas o grupo de processos de iniciao deve receber
um pouco mais de ateno, pois o momento crucial do projeto.
Portanto, ateno redobrada nas documentaes.
planejamento
Contratos bem elaborados, propostas comerciais claras,
reunies com as partes envolvidas, definio dos objetivos e
oramento do projeto so de grande valia neste momento.
Mesmo com toda esta ateno, no se pode esquecer tambm
que um dos pontos principais que devem ser verificados e que
afetam quase todos os projetos, principalmente neste momento
de iniciao, a falta de atitude do gerente de projetos. O geren-
te de projetos deve ter clareza e certeza de que quem domina o
projeto ele. Por mais que o cliente seja o suporte financeiro,
quem domina o projeto o gerente. Logo, ele deve possuir
habilidades para negociar com o cliente e apresentar para ele
com clareza todo e qualquer desvio logo que ele ocorrer para
que impactos futuros sejam minimizados.
Links e Referncias:
MARTINS, J. C.C. Tcnicas para Gerenciamento de Projetos de Software. 1.
Edio Editora Brasport, 2007.
PMI. Um Guia do Conhecimento em Gerenciamento de Projetos. Guia PMBOK
4. Edio EUA: Project Management Institute, 2008.
VARGAS, Ricardo. Manual Prtico do Plano de Projeto Utilizando o PMBOK
Guide 4. Edio Brasport, 2009.
VIEIRA, Marconi. Gerenciamento de Projetos de Tecnologia da Informao
2. Edio Editora Elsevier, 2007.
Site do PMI Brasil
http://brasil.pmi.org/brazil/home.aspx
Voc gostou deste artigo?
D seu voto em www.devmedia.com.br/esmag/feedback
Ajude-nos a manter a qualidade da revista!
Edio 66 - Engenharia de Software Magazine 43
Engenharia
Nesta seo voc encontra artigos voltados para testes, processo,
modelos, documentao, entre outros
Trabalhando com Engenharia de Requisitos
Boas e ms prticas
Elaine G.M de Figueiredo
mira.figueiredo@gmail.com
Mestrado em Ciencias da Computano
com enfase em engenharia de software,
ps graduao em gerncia de projetos,
oito anos de atuao na rea de desen-
volvimento e qualidade de software. Atu-
almente gerente de projetos na multina-
cional espanhola Indra Company, membro
colaborador do grupo de pesquisa ASSERT
Advanced System and Software Engi-
neering Research Technologies Lab pela
universidade federal de Pernambuco.
44 Engenharia de Software Magazine - Trabalhando com Engenharia de Requisitos
A
engenharia de requisitos a
disciplina que de fato tem a
misso de ajudar a equipe de
desenvolvimento a entender o software
a ser elaborado. a base slida para se
andar do projeto at a construo. Ela
constituda pelas fases apresentadas na
Figura 1. So elas:
Concepo: fase inicial que define o
escopo do problema de software;
Elaborao: fase em que os requi-
sitos so refinados e modelados em
cenrios;
Validao: a fase em que ocorre a vali-
dao dos requisitos, onde a equipe faz
uma reviso dos mesmos, para que se te-
nha a certeza de que os requisitos foram
elicitados de maneira no ambgua;
Gerncia de Requisitos: fase em que se
controla, analisa e registra as mudanas
de requisito, isto a fim de verificar os
impactos das alteraes no produto de
software em desenvolvimento.
Fique por dentro:
Este artigo til para que desenvolvedores de
software conheam medidas importantes que
podem auxiliar todo o processo de desenvol-
vimento de software a partir do momento em
que essas prticas ajudam na compreenso dos
requisitos de software, dos solicitantes destes
requisitos, da alterao dos mesmos, e dos
principais problemas aos quais os requisitos
de software esto sujeitos. Por fim, a maior
utilidade est em prover a compresso sobre
como se executar bem a fase de engenharia de
requisitos.
Requisitos: O necessrio para
entend-los
Um requisito uma capacidade que o
software deve possuir com a finalidade
de resolver um problema do usurio.
Os requisitos servem como especifica-
o do que deve ser implementado no
sistema. Os requisitos devem descrever
uma facilidade para o usurio, uma pro-
priedade ou uma restrio do sistema,
ou ainda, uma restrio do processo de
desenvolvimento do sistema.

Figura 1. Engenharia de Requisitos.
Os requisitos de software so de trs tipos:
Requisitos funcionais: so requisitos que descrevem uma
ao que o software deve ser capaz de realizar;
Requisitos no funcionais: so requisitos que tratam das
restries do software visando sempre a qualidade, ou seja,
uma qualidade que o software deve possuir durante a sua
execuo;
Requisitos inversos: so requisitos que definem o que nunca
deve ocorrer durante a execuo do software;
Os requisitos funcionais so de dois tipos:
Requisitos estveis: requisitos que no so alterados ou mo-
dificados com frequncia, sua alterao algo excepcional;
Requisitos volteis: so requisitos que vivem em constante
modificao, eles podem ser divididos em quatro categorias:
compatveis, mutveis, emergentes e consequentes.
Os requisitos ainda podem ser divididos em outra categoria,
se vistos pelo aspecto da implementao:
Requisitos do cliente, ou requisitos de alto nvel: so aqueles
expostos pelo cliente em linguagem natural, ou ainda em forma
de desenhos ou casos de uso, qualquer tcnica que facilite o
entendimento.
O importante que esses requisito se caracterizam por dizer
apenas aquilo que o usurio ou cliente quer que o sistema
faa, no h a preocupao de como aquela funcionalidade
ser implementada;
Requisitos do sistema, ou requisitos de baixo nvel: so re-
quisitos mais detalhados, que relatam no s o que deve ser
implementado, mas como deve ser implementado, eles fazem
restries a aspectos de implementao e arquitetura, possuem
detalhes que geralmente so obscuros para o cliente, mas que
certamente os desenvolvedores conhecem bem.
Olhando por um aspecto mais ligado a gerncia, outras duas
classificaes podem ser ofertadas aos requisitos, elas foram
relatadas por Spence (2000), e so pontuadas a seguir:
en gen haria
Grau de impacto que a implementao de um requisito pode
ter em relao elaborao de um sistema;
O requisito pode impactar muito, pode impactar modera-
damente, ou ainda causar pouco impacto em um projeto de
software. Este tipo de classificao muito importante para
deixar ciente toda a equipe de desenvolvimento, de quais re-
quisitos podem trazer resultados desastrosos caso no sejam
bem gerenciados ou implementados;
Grau de prioridade que o requisito tem diante s necessi-
dades do cliente, um requisito pode ser altamente prioritrio
para o cliente, ou para o sistema, sua implementao e gesto
devem ser muito bem elaboradas, caso contrrio, a funciona-
lidade do sistema ser deficitria. Um requisito tambm pode
ter prioridade mdia ou baixa.
Este entendimento sobre a classificao dos requisitos im-
portante, pois ao identificar os tipos de requisitos, as equipes
podem organiz-los em grupos, e conhec-los melhor, o que
torna mais fcil o controle sobre as mudanas e, como consequ-
ncia, o gerenciamento. Assim, como veremos, a classificao
dos requisitos a primeira boa prtica a ser seguida logo no
incio do projeto.
O estabelecimento de tipos diferentes de requisitos em um
projeto ajuda a equipe a classificar os pedidos de alteraes e
a se comunicar mais claramente e firmemente com os clientes,
portanto, a classificao j proporciona um entendimento e
planejamento mais consistente sobre o que ser implementado
e em qual ordem.
Os requisitos de um software so sistemticos, ou seja, algo
em que suas propriedades so conhecidas, mas que tambm so
suscetveis s mudanas. O Rational Software Corporation (RUP)
oferece bons esclarecimentos que justificam a complexidade dos
requisitos de software, estes esclarecimentos foram pontuados a
seguir, os mesmos auxiliam no exerccio de ms prticas:
Os requisitos podem vir de vrias fontes e nem sempre so
bvios;
Expressar os requisitos em palavras no to fcil;
Existem nveis de detalhes para cada requisito;
O nmero de requisitos pode prejudicar a gerncia de requi-
sitos, se no for controlado;
Cada requisito nico;
Os requisitos mudam.
Aps a explanao anterior, importante exibir as ms pr-
ticas. Vale frisar que mais importante do que entender o que
deve ser feito como boas prticas em um processo entender
o que no deve ser feito, bem como as armadilhas preparadas
para provocar os erros.
Ms prticas
De forma direta e objetiva, segue o que no deve ser ado-
tado em processos de software na fase de engenharia de
requisitos:
1. No corrigir erros e inconsistncias em requisito durante
sua anlise, ou fase de elaborao;
Edio 66 - Engenharia de Software Magazine 45
2. No entender que os clientes e usurios finais do software
costumam evoluir sua compreenso sobre o que desejam com o
passar do tempo. Nem to pouco se preparar para este fato;
3. Provocar problemas tcnicos e principalmente alteraes
bruscas de custo ou cronograma, isto acarreta mudana nos
requisitos que podem ser impactantes para o produto;
4. No conhecer o cliente e o usurio final da aplicao;
5. No se preparar para as mudanas no ambiente em que o
software ser implementado;
6. Ofertar as tarefas de requisitos para um profissional que
no tem talento e principalmente apreo pela engenharia de
requisitos;
7. Desconhecer o negcio e a finalidade da instituio que est
propondo o software a ser desenvolvido;
8. No fazer a modelagem de negcio (regras de negcio) antes
de iniciar a engenharia de requisitos.
9. No adotar uma linguagem familiar com os clientes e soli-
citantes dos requisitos;
10. Ofertar uma soluo ao invs de se entender e registrar as
necessidades e problemas dos solicitantes de requisitos;
11. No controlar a quantidade de requisitos solicitados, e nem
dividir esses requisitos em grupos de implementao;
12. No relacionar os requisitos entre sim, e entre os produtos
do processo de desenvolvimento de software;
13. Estimar mal a quantidade de recursos humanos necessrios
para controlar as mudanas nos requisitos;
14. Falta de habilidade para manter os documentos de requi-
sitos consistentes;
15. Ouvir muitos solicitantes de requisitos sem selecionar
previamente os que mais entendem do negcio;
16. No exibir para os interessados os requisitos em prototi-
paes grficas.
Boas prticas
Para se conhecer e definir quais as boas prticas a serem
aplicadas na engenharia de requisitos interessante formular
uma poltica de engenharia de requisitos. Tal poltica deve ex-
plicar os objetivos dos processos definidos para engenharia de
requisitos de forma clara aos envolvidos no projeto. Alm disso,
deve levar em conta os padres organizacionais, as regras de
negcio da organizao, e as caractersticas de cada projeto,
alm das aptides de cada profissional da equipe. Por si s, tal
poltica j se caracteriza como uma boa prtica.
Uma forte recomendao dentro da engenharia de requisitos
passar a ideia de que requisitos nunca podem ser congelados,
e dificilmente sero em algum projeto. Sendo assim, outra boa
prtica aplicar o gerenciamento de requisitos com o protocolo
que deve ser seguido neste gerenciamento, pois a tarefa de se
gerenciar requisitos pode ser extremamente burocrtica, sem
necessariamente agregar valor engenharia de requisitos e
ao processo de software.
Outras boas prticas so:
1. Concordar com um vocabulrio comum para o projeto;
2. Descreve de forma clara e objetiva o problema a ser resolvido
pelo sistema, bem como de seus recursos principais;
46 Engenharia de Software Magazine - Trabalhando com Engenharia de Requisitos
3. Fazer o levantamento das necessidades dos envolvidos
em pelo menos cinco reas importantes para o sistema:
funcionalidade, usabilidade, confiabilidade, desempenho e
suportabilidade;
4. Identificar membros da equipe que sero coautores e contri-
buiro para a formulao de um ou mais tipos de requisitos;
5. Decidir qual rastreabilidade de requisitos ser necessria. A
rastreabilidade de requisitos o mecanismo mais eficiente de
auxlio gerncia de requisitos, ela responsvel pela manu-
teno das modificaes nos relacionamentos entre objetos e
requisitos. Tal rastreabilidade pode ser feita por meio de uma
matriz. Com a rastreabilidade possvel ter visibilidade das
consequncias da alterao de um requisito;
6. Desenvolver uma Matriz de Rastreabilidade de Requisitos.
A matriz uma das formas mais usuais de se apresentar e
estabelecer a rastreabilidade de requisitos, ela que prov a
visualizao dos relacionamentos entre os objetos, ou artefa-
tos de um projeto de software. A Matriz de Rastreabilidade
um recurso til dentro da gerncia de requisitos, seu uso
extremamente recomendado pelos programas de melhoria
de desenvolvimento de software. Um modelo de matriz
representado na Tabela 1;
7. Criar relatrios de progresso e status da matriz de rastre-
abilidade e dos requisitos, para que a equipe desenvolvedora
entenda o impacto da alterao de um requisito;
Projeto <nome> - Matiz de Rastreabilidade
Requisito Documento Fonte Arquitetura Componente Caso de Teste
Tabela 1. Exemplo de Matriz de Rastreabilidade
8. A equipe responsvel pela engenharia de requisitos deve
receber todas as solicitaes de alterao nos requisitos por
um formulrio prprio, ou por um sistema automatizado, bem
como as solicitaes de adio de novos requisitos;
9. Aprovar os requisitos com o cliente, usurios e demais
solicitantes, isto dar oportunidade de conhecer requisitos
errneos e corrigi-los prematuramente;
10. Efetuar revises em planos e produtos de trabalho vi-
sando identificar e corrigir inconsistncias em relao aos
requisitos;
11. Deve-se eleger um gerente de requisitos que deve avaliar
o impacto das modificaes solicitadas nos requisitos, e em
tudo que est relacionado a eles;
12. Deve ser mantido um histrico de alteraes para cada
requisito;
13. Toda modificao em requisito deve ser comunicada aos
envolvidos, devido aos impactos em potencial;
14. Uma coleta peridica das mtricas deve ser feita para me-
lhor acompanhamento da gerncia de requisitos. As mtricas
daro visibilidade da quantidade de alteraes feitas e de que
natureza elas so. Isto contribui para que a equipe saiba o que
esperar em projetos futuros com requisitos semelhantes.

Em relao ao ltimo tpico, a importncia de se ter uma
mtrica se deve ao fato do gerente de requisitos poder ter o
percentual de requisitos alterados, includos ou excludos,
dentro de um determinado perodo de tempo. Isto poder
dar maior poder estratgico para os prximos projetos de
software, onde o gerente poder saber exatamente em que
perodo ocorre maior modificao nos requisitos.
importante salientar que muitos dos tpicos acima esto
relacionados alterao de requisitos. Assim relativamente
fcil notar que a fase de gerncia de requisitos uma das
mais importantes dentro da engenharia. Para a gerncia de
requisitos todas as mudanas precisam ser identificadas,
avaliadas, documentadas, comunicadas e acompanhadas
at sua finalizao. o que defende o CMMI.
Quando uma mudana ocorre, primeiramente deve-se ana-
lisar o requisito que est ligado quela mudana, verificar
a prioridade dele, as quais outros artefatos o requisito est
ligado, verificar o impacto sobre estes artefatos; deve-se
verificar tambm se o requisito prprio do cliente ou do
sistema, se voltil, ou seja, se j se esperava esta solicitao
de mudana, e qual a situao atual do requisito dentro do
processo, enfim, deve-se tratar esta mudana a comear do
reconhecimento do requisito.
Oberg (2002) escreveu que uma indstria americana formulou
um estudo publicado na conferncia internacional de requisi-
tos, este estudo apontava que 76% de um total de 500 gerentes
de TI nos Estados Unidos e no Reino Unido entrevistados, j
tinham tido falhas em projetos inteiros durante suas carreiras.
A causa mais frequentemente apontada como falha dos proje-
tos foi a alterao de requisitos. Atualmente, este percentual
deve ter pelo menos duplicado, no s pelo aumento no nmero
de sistemas implementados, mas tambm pelo aumento da
complexidade nas relaes e regras de negcios.
A gerncia de requisitos fundamental para o controle de
mudanas dos requisitos, pois estes seguem evoluindo com
o passar do tempo, j que esto inseridos em um ambiente
real que muda com o tempo. A rastreabilidade de requisitos
contribui para a previso do impacto que as mudanas dos
requisitos causaro no projeto de software, sendo assim, a
gerncia de requisitos pode contribuir para a garantia da
qualidade do sistema. A gerncia de requisitos se restringe
aos seguintes aspectos:
Gerenciar mudanas em requisitos existentes;
Gerenciar relacionamento entre os requisitos;
Gerenciar dependncias entre os produtos de trabalho
durante o desenvolvimento de software.
Para que a gerncia desenvolva seu papel de forma sa-
tisfatria, necessrio de antemo, definir novamente
um conjunto de polticas. Estas polticas devem explicar
os objetivos dos processos definidos de forma clara aos
envolvidos no projeto. E deve levar em conta os padres
organizacionais, as regras de negcio da organizao, e as
caractersticas de cada projeto, alm das aptides de cada
profissional da equipe.
en gen haria
Tudo na gerncia de requisitos parte da ideia de que requisitos
nunca podem ser congelados, e dificilmente sero em algum
projeto. Sendo assim, para que a gerncia de requisitos cumpra
sua misso necessrio que ela desenvolva algumas boas pr-
ticas, como: ter um modelo para rastrear requisitos, inclusive
com a utilizao de ferramentas que faam rastreabilidade.
Definir um modelo de rastreabilidade de requisitos para
um projeto depende de muitos fatores, o primeiro deles o
software que est sendo construdo. Projetos com relativa es-
tabilidade costumam ter os requisitos alterados na ordem de
1% ao ms. Portanto, observar as caractersticas do sistema
algo que no se pode omitir (mais uma boa prtica agregada).
Deste modo, fica evidente que um modelo de rastreabilidade
sempre nico e distinto de qualquer outro.
Um modelo de rastreabilidade inicia suas boas prticas se-
lecionando os requisitos que devem ser rastreados. Rastrear
muitos requisitos uma tarefa burocrtica e difcil, que pode
agregar atrasos e erros ao analista de requisitos. Ademais,
nem todo requisito, depende da sua classificao, necessita
ser rastreado.
Outra boa prtica dentro da rastreabilidade de requisitos esta-
belece que necessrio verificar (selecionar) as ferramentas de
rastreabilidade que apoiaro de forma mais eficaz o processo
de rastreabilidade de requisitos, necessrio ainda treinar a
equipe para o uso da ferramenta.
sadio ainda definir os momentos de registro e de controle da
rastreabilidade, isto pode ocorrer no momento de fechamento
de fases, por exemplo: efetuar rastreabilidade na finalizao
da etapa de anlise e projeto, e na finalizao da etapa de
codificao. No se pode esquecer que requisitos mudam a
todo o momento e podem impactar mudanas em todos os
artefatos de software.
Os pontos citados nos trs pargrafos acima so os mais rele-
vantes, sendo que o primeiro mais ainda, visto que no todo
requisito que passvel de rastrear. Deve-se fazer um catlogo,
e observar atravs das questes a seguir, se no requisito elici-
tado pode-se descobrir as informaes exigidas nas questes.
Se o requisito atender a todas, possivelmente ele ser candidato
rastreabilidade. As questes so pontuadas a seguir:
Deve-se saber quem geriu o requisito;
Saber o porqu da sua existncia;
Saber quais outros requisitos esto relacionados ao requisito
elicitado;
Como o requisito elicitado se relaciona com o sistema a ser
implementado;
Que documentaes do processo de software podem ser
afetadas pela modificao do requisito.
Aps obter respostas a essas questes, em relao aos requi-
sitos, devem-se saber os objetos a serem monitorados, bem
como, os tipos de rastreabilidade que sero efetuadas, alm de
estabelecer corretamente o tipo de ligao que ser gerenciada
nesta matriz, isto depender exclusivamente da caracterstica
dos objetos (produtos de software), dos processos de software
utilizados pela organizao, e dos prazos e custos do projeto
Edio 66 - Engenharia de Software Magazine 47
em questo. Executando essas aes, mais fcil fazer da
rastreabilidade, uma tarefa que demande um trabalho pouco
oneroso e com garantias na finalizao.
Tambm importante saber o grau de instabilidade dos
requisitos. Ou seja, se so requisitos volteis. Deve-se saber,
ou pelo menos deduzir, com que frequncia eles podem vir
a se modificar.
Conhecer a instabilidade dos requisitos do software a ser
desenvolvido algo que tambm facilita o estabelecimento
de uma matriz de rastreabilidade, visto que, alguns sistemas
possuem requisitos funcionais que so pouco volteis, onde
os fatores que podem ocasionar mudanas existem, mas no
so constantes, no provocam muitas variaes. Esses sistemas
desenvolvem uma matriz relativamente simples, com poucos
requisitos, ou com requisitos que no so to volteis. Neste
caso, o gerenciamento facilitado e pode-se usar at mesmo
uma planilha eletrnica como ferramenta.
Vale salientar que se faz necessrio a determinao de um
modelo de matriz de rastreabilidade para todo software que
ser construdo. Alis, todo sistema deve fazer uso da rastrea-
bilidade de requisitos, mesmo os mais estveis. Os sistemas que
necessitam de mais ateno na elaborao da matriz possuem
o seguinte perfil:
Aplicaes para Internet, onde modificaes surgem a todo
o momento em vrias etapas;
Sistemas em que a equipe desenvolvedora geralmente possui
prazos relativamente curtos para o desenvolvimento;
Aplicaes que possuem seus requisitos em constante
evoluo.
Aps a definio do modelo, alguns outros aspectos, em
relao ao desenvolvimento da rastreabilidade devem ser
levados em considerao:
Durante o processo de desenvolvimento da rastreabilidade,
os elos (relacionamento entre os requisitos e os objetos de
software) devem ser monitorados, pois eles tambm sofrem
modificaes, por exemplo: um elo que antes era de satisfao
passa a ser de dependncia, para isso, basta que o objeto a que
ele esteja ligado sofra alguma alterao;
Conscientizar a equipe da importncia do processo de ras-
treabilidade, evidenciar que a rastreabilidade de requisitos
sim um fator de sucesso para a agilidade do processo e para
o tratamento das mudanas, e isto impacta diretamente em
tempo e custo;
Aps o trmino do projeto, analisar e avaliar criticamente a
eficincia e eficcia do processo de rastreabilidade, verificando
os pontos positivos e os que necessitam de melhorias. O esforo
da equipe, o controle sobre as informaes manipuladas, e as
lies aprendidas devem ser considerados.
48 Engenharia de Software Magazine - Trabalhando com Engenharia de Requisitos
Aps os conceitos que j foram repassados sobre a tcnica de
rastreabilidade, possvel notar que a gerncia de requisitos
contribui muito para o tratamento de riscos do projeto de soft-
ware. 80% dos riscos em projetos de software so oriundos da
evoluo dos requisitos. Tal gerncia um processo chave ao
processo de gerncia de software, pois a sua correta execuo
pode mostrar ao gerente de projetos os problemas que o desen-
volvimento de software poder enfrentar futuramente.
Percebeu-se at agora, que a gerncia de requisitos, ao con-
trrio de outros processos que podem ser gerenciados dentro
de um nico grupo de negcios, pode envolver qualquer va-
rivel, ambiente, grupo de pessoas, ou processo, que possam
contribuir com o seu desenvolvimento. Este gerenciamento
inclui as pessoas envolvidas com a elicitao de requisitos,
e tambm com a definio dos testes pelo qual o sistema ir
passar. Gerentes de desenvolvimento, de qualidade, analistas,
engenheiros, clientes, podem e devem participar do processo
de gerncia de requisitos.
Apesar da importncia discutida neste artigo, a engenharia
de requisitos na prtica ainda pouco utilizada em muitos
ciclos de desenvolvimento. Isto se deve ao fato de muito dos
processos que compem esta engenharia serem feitos de forma
burocratizada. Um desafio para os executores dos processos e
tarefas relacionados aos requisitos prover solues prticas
e tcnicas geis a tais processos.
Links e Referncias:
1. Alves, S. R. e Alves, L. A. (2009), Engenharia de Requisitos em Mtodos
geis.
2. Cohn, M. (2004) User Stories Applied For Agile Software D evelopment.
Addison Wesley, Kent Beck, p. 17-29 .
3. dAmorim, F. R. S. (2008), Engenharia de Requisitos para Mtodos geis.
Os Processos Tpicos da Engenharia de Requisitos
http://www.choose.com.br/infochoose/artigos
Requirements Engineering Laboratory
http://www.cin.ufpe.br/~ler/index.php
Traceability Strategies for Managing Requirements With Use Cases.
SPENCE, Ian; PROBASCO, Leslee.
http://www.embeddedstar.com/technicalpapers/content/t/embedded818.html
Voc gostou deste artigo?
D seu voto em www.devmedia.com.br/esmag/feedback
Ajude-nos a manter a qualidade da revista!
Engenharia
Nesta seo voc encontra artigos voltados para testes, processo,
modelos, documentao, entre outros
Especificando casos de uso eficazes
Conhea algumas boas prticas
Rodrigo Oliveira Spnola
rodrigo.devmedia@gmail.com
Editor Chefe Engenharia de Software
Magazine
Este artigo do tipo mentoring
saiba mais:
www.devmedia.com.br/mentoring-saibamais
U
m questionamento comum que
muitos profissionais fazem ao
iniciar os trabalhos na rea de
requisitos se existe um formato de des-
crio de casos de uso a ser seguido. Em-
bora exista uma definio de estrutura
bastante difundida baseada no modelo
de documento de caso de uso proposto
pelo RUP (Rational Unified Process), no
existe uma regra sobre como eles devem
ser descritos.
Na verdade, a prtica da escrita de
casos de uso varia de empresa para a
empresa e cada cenrio deve ser respei-
tado. Se um determinado formato fun-
ciona adequadamente para a empresa
X, por que ele contem o conjunto de
Edio 66 - Engenharia de Software Magazine
Cenrio:
Requisitos so a base para diferentes etapas
do desenvolvimento de um software. Isto faz
deles um fator decisivo para o sucesso do pro-
jeto. Neste artigo partiremos de um exemplo
comum de ser encontrado em sistemas de
informao - uma consulta seguida da exclu-
so de itens cadastrados - e aprimoraremos a
especificao realizada inicialmente, conside-
rada equivocada, no sentido de torn-la mais
completa para que outros membros da equipe
de desenvolvimento possam trabalhar de for-
ma mais eficiente.
informaes necessrias para que os
demais membros da equipe de desen-
volvimento desempenhem de forma
satisfatria suas atividades. Contudo,
mesmo este formato funcionando ade-
quadamente em uma empresa, isso no
quer dizer que ele possa ser utilizado
de forma satisfatria por outra organi-
zao. Maiores ou menores nveis de
detalhamento na descrio podem ser
necessrios.
Enfim, no h uma regra. Entretanto,
um conjunto de boas prticas tem sido
49
percebido ao longo dos anos e que, se consideradas, podem
contribuir positivamente para que a especificao do caso
de uso seja realizada de forma mais satisfatria. Satisfatria
neste caso significa poder ser utilizada por outros membros
da equipe de desenvolvimento (testadores, projetistas e
desenvolvedores, por exemplo) sem a necessidade de novas
intervenes na especificao para que ela possa ser mais bem
compreendida.
Neste cenrio, partiremos de uma especificao de caso de
uso simplificada para um requisito de consulta e excluso
de itens cadastrados. Esta verso simplificada ser aprimo-
rada aos poucos considerando um conjunto de boas prticas.
Ao final, teremos uma especificao bem definida e que ir
considerar vrias das prticas que tm sido adotadas por
equipes de desenvolvimento de software.
Cenrio utilizado
Para ilustrar o uso de boas prticas na descrio de um
caso de uso, partiremos do seguinte requisito funcional: o
software deve permitir que funcionrios efetuem buscas por
itens cadastrados e, uma vez retornado o resultado da busca,
itens possam ser excludos. A partir deste requisito funcional,
busca-se detalhar sua descrio de forma que outros membros
da equipe de desenvolvimento possam realizar suas ativida-
des como projetar o software, planejar os testes e codificar o
produto.
A Tabela 1 apresenta uma possvel verso simplificada (que
no considera o conjunto de boas prticas descritas na prxima
seo) deste caso de uso. Observe que esta verso apresenta
vrios problemas associados a itens que precisam estar pre-
sentes numa descrio de caso de uso como:
Campos a serem preenchidos;
Fluxos alternativos;
Fluxos de exceo;
Opes presentes na tela.
Objetivo: Permitir que itens fossem procurados e excludos do sistema.
Atores: Funcionrio
1. O ator seleciona a opo Buscar Itens
2. O sistema apresenta tela de busca
3. O ator informa os dados do filtro e seleciona a opo buscar
Fluxo Principal: 4. O sistema apresenta os itens recuperados
5. O ator seleciona os itens que deseja excluir e seleciona a opo
excluir
6. O sistema exclui os itens selecionados
Fluxo Alternativo: - 4. Caso o campo contenha uma lista de opes fixa, definir
Fluxo de Exceo: -
[RN1] Apenas itens cujo status seja igual a Pendentes podem ser
Regras de negcio:
excludos
Tabela 1. Caso de uso Excluir Itens Cadastrados Verso com Problemas
Podemos afirmar que por conta do conjunto de omisses
encontradas na especificao, ela est mal elaborada, necessi-
tando que ajustes sejam realizados de forma que ela possa ser
50 Engenharia de Software Magazine - Especificando casos de uso eficazes
utilizada pela equipe de desenvolvimento. A partir de agora
veremos como corrigir os problemas presentes nesta especifi-
cao atravs da aplicao de um conjunto de boas prticas.
Boas prticas aplicadas ao caso de uso
O conjunto de boas prticas apresentadas neste artigo est
organizado em trs grupos:
Navegao: boas prticas que dizem respeito definio
de informaes na descrio de caso de uso que permitam
ao desenvolvedor entender como ser a interao do usurio
com o sistema;
Campos: boas prticas que dizem respeito definio de
informaes que permitam o correto entendimento sobre
as informaes manipuladas pelo sistema, assim como suas
propriedades como formatos e obrigatoriedade;
Regras de Negcio: boas prticas relacionadas a preocupa-
es que devem ser consideradas quando se estiver definindo
as regras de negcio associadas ao caso de uso.
Para o grupo navegao, as boas prticas consideradas
sero:
1. Definir explicitamente os diferentes fluxos de uso do soft-
ware nos casos de uso;
2. Definir explicitamente condies de entrada para cada um
dos fluxos;
3. Definir explicitamente o ponto em que o software estar
ao sair de cada fluxo;
Os resultados da aplicao dessas prticas na especificao
do caso de uso apresentada na Tabela 1 podem ser obser-
vados na Tabela 2. As linhas em vermelho representam as
informaes que foram acrescentadas especificao inicial.
Observe que acrescentamos um conjunto de informaes que
permitem agora, equipe de desenvolvimento, entender como
se d a interao entre o ator e o sistema para realizao da
funcionalidade.
Contudo, ainda no temos nenhuma informao sobre as
informaes manipuladas pela funcionalidade. sobre isso
que falaremos a partir de agora. Para o grupo campos, as boas
prticas consideradas sero:
1. Definir explicitamente os diferentes campos que so apre-
sentados em cada passo do caso de uso;
2. Definir explicitamente a obrigatoriedade dos campos;
3. Definir explicitamente se os campos so editveis ou so-
mente leitura;
explicitamente as opes disponveis;
5. Caso o campo possua um comportamento diferenciado,
definir este comportamento explicitamente atravs de uma
regra de negcio.
Os resultados da aplicao dessas prticas na especificao
do caso de uso apresentada na Tabela 2 podem ser observados
na Tabela 3. As linhas em vermelho representam as informa-
es que foram acrescentadas. Observe que foi adicionado um
 en gen haria

Objetivo: Permitir que itens fossem procurados e excludos do sistema. Objetivo: Permitir que itens fossem procurados e excludos do sistema.
Atores: Funcionrio Atores: Funcionrio
Condio de Entrada O ator seleciona a opo Buscar Itens Condio de Entrada O ator seleciona a opo Buscar Itens
1. O sistema apresenta tela de busca 1. O sistema apresenta tela de busca contendo as informaes [RN2]
2. O sistema apresenta ao final as opes Buscar e Cancelar [RN3]:
3. O ator informa os dados do filtro e seleciona a opo buscar [A01] - Nome (campo editvel)
4. O sistema apresenta os itens recuperados - Status (contendo as seguintes opes: Pendente, Confirmado, Todos)
5. O sistema apresenta ao final as opes Excluir e Voltar (campo editvel)
Fluxo Principal:
6. O ator seleciona os itens que deseja excluir e seleciona a opo excluir 2. O sistema apresenta ao final as opes Buscar e Cancelar
[A02] [RN1] [EX01] 3. O ator informa os dados do filtro e seleciona a opo buscar [A01]
7. O sistema exclui os itens selecionados 4. O sistema apresenta para cada item recuperado as seguintes
8. O sistema retorna para a tela inicial informaes:
9. O caso de uso encerrado Fluxo Principal: - Opo de seleo (campo editvel)
[A1] O ator seleciona a opo Cancelar - Nome (somente leitura)
1. O sistema retorna para a tela inicial - Descrio (somente leitura)
Fluxo Alternativo: 2. O caso de uso encerrado - Status (somente leitura)
[A2] O ator seleciona a opo Voltar 5. O sistema apresenta ao final as opes Excluir e Voltar
1. O sistema retorna ao passo 4 do fluxo principal 6. O ator seleciona os itens que deseja excluir e seleciona a opo excluir
[E1] Item no pode ser excludo [A02] [RN1] [EX01]
1. O sistema apresenta mensagem indicando quais itens no podem ser 7. O sistema exclui os itens selecionados
excludos 8. O sistema retorna para a tela inicial
Fluxo de Exceo:
2. O sistema apresenta ao final a opo OK 9. O caso de uso encerrado
3. O ator seleciona a opo OK [A1] O ator seleciona a opo Cancelar
4. O sistema retorna ao passo 4 do fluxo principal. 1. O sistema retorna para a tela inicial
[RN1] Apenas itens cujo status seja igual a Pendentes podem ser Fluxo Alternativo: 2. O caso de uso encerrado
Regras de negcio:
excludos [A2] O ator seleciona a opo Voltar
Tabela 2. Caso de uso Excluir Itens Cadastrados Prticas do Grupo 1. O sistema retorna ao passo 4 do fluxo principal
Navegao Aplicadas [E1] Item no pode ser excludo
1. O sistema apresenta mensagem indicando quais itens no podem
ser excludos
conjunto de informaes que permitem agora entender quais Fluxo de Exceo:
2. O sistema apresenta ao final a opo OK
informaes so manipuladas e quais as restries de seu uso.
3. O ator seleciona a opo OK
Alm disso, essa definio permitiu equipe de desenvolvi-
4. O sistema retorna ao passo 4 do fluxo principal.
mento definir mais duas regras de negcio associadas aos
[RN1] Apenas itens cujo status seja igual a Pendentes podem ser
campos Nome e Status da tela de busca.
excludos
Neste momento j temos uma descrio de casos de uso bem
Regras de negcio: [RN2] O campo nome opcional.
definida. Apresentaremos agora o ltimo grupo: Regras de
[RN3] O campo Status vem com a opo Todos selecionados como
Negcio. Para este grupo, podemos considerar as seguintes
padro.
boas prticas:
1. Caso a regra seja de difcil entendimento, complementar sua Tabela 3. Caso de uso Excluir Itens Cadastrados Prticas do Grupo
descrio atravs de um exemplo. Campos Aplicadas

Esta ltima boa prtica no se aplica ao nosso exemplo, con-

tudo, importante estar atento a ela. Lembre-se, a regra ser Referncias:
utilizada por outros membros da equipe de desenvolvimento,
e no apenas pela equipe de analistas de requisitos que, por Alves, S. R. e Alves, L. A. (2009), Engenharia de Requisitos em Mtodos
interagir diretamente com o cliente, tem um conhecimento geis.
mais completo do negcio que est sendo mapeado.
Concluindo, importante estar atento ao fato de que estas
prticas podem ou no ser adequadas s necessidades de sua Voc gostou deste artigo?
organizao. importante lembrar tambm que o conjunto
apresentado no e nem pretende ser uma lista final de D seu voto em www.devmedia.com.br/esmag/feedback
boas prticas. Outras certamente existem e quase sempre so Ajude-nos a manter a qualidade da revista!
provenientes da experincia de analistas nos projetos que
participa.

Edio 66 - Engenharia de Software Magazine 51

Engenharia
Nesta seo voc encontra artigos voltados para testes, processo,
modelos, documentao, entre outros
Gesto de Regras de Negcios
Marco Ikuro Hisatomi
marco.hisatomi@gmail.com
Possui graduao em Tecnologia em Proces-
samento de Dados pela UEM, especialista em
Desenvolvimento Gerencial e Gesto da Quali-
dade pela FECEA. Mais de 27 anos de vivncia
em desenvolvimento de software e gerencia-
mento de projetos, engenharia de Software,
engenharia de testes, fbrica de software, em
pequeno e grande porte. Professor em cursos
de graduao desde 2004.
Anderson de Souza Ges
andersonsouzagoes@gmail.com
Graduado em Cincia da Computao pela Uni-
versidade Estadual de Londrina - UEL (2011).
Atualmente aluno regular pela mesma ins-
tituio. Tem experincia na rea de Cincia
da Computao com nfase em Sistemas da
Informao e Engenharia de Software.
Rodolfo Mirando de Barros
rodolfo@uel.br
Rodolfo Miranda de Barros graduado em Ci-
ncia da Computao pela Universidade Federal
de So Carlos (UFSCar) e em Administrao de
Empresas pela Universidade Estadual de Lon-
drina (UEL). Concluiu o mestrado em Cincia da
Computao pela Universidade Federal do Rio
Grande do Sul (UFRGS) em 1997 e o doutorado
em Engenharia Eltrica pela Universidade Es-
tadual de Campinas (UNICAMP) em 2008.
52 Engenharia de Software Magazine - Gesto de Regras de Negcios
Fique por dentro:
Um desafio no desenvolvimento de software
sempre foi atender s necessidades dos usurios
finais, com maior preciso e rapidez em nveis
operacionais e estratgicos da organizao. Ain-
da, a complexidade tem crescido rapidamente
em funo das fortes demandas por sistemas
que exigem integraes com outros sistemas.
Os fatores que exigem maior gerenciamento no
desenvolvimento de software esto nas diversas
plataformas tecnolgicas, multidisciplinaridade
demandadas no desenvolvimento de software e
A
gesto da informao requer a proposta est na melhoria da gesto
uma disciplina de execuo
dos procedimentos bem defi-
nidos. Existem vrias fontes de infor-
maes e tambm inmeras formas
de expressar a mesma informao [1].
E por estes motivos que softwares nem
sempre possuem as funcionalidades de
acordo com as regras de negcios da
organizao patrocinadora do projeto
de desenvolvimento.
Atravs de um modelo de gesto das
regras de negcios, desde sua formali-
zao at a validao de aplicabilidade,
profissionais formados em diferentes universida-
des. Este artigo tem como finalidade a implanta-
o de um modelo de gesto de regras de neg-
cios paralelamente gesto do desenvolvimento
de software, ofertando uma viso transparente
aos usurios finais quanto aos processos de seus
negcios. Atravs deste modelo de gesto de re-
quisitos, possvel efetuar a gesto das regras
de negcios com foco na garantia da qualidade e
integralidade das implementaes destas regras
no software, alinhadas aos processos de neg-
cios da organizao.
do conhecimento. A partir de problemas
evidenciados no processo de desenvol-
vimento de software e perda de infor-
maes, algumas anlises esto sendo
formalizadas, como base para demons-
trar as melhorias que so possibilitadas
com o uso deste modelo.
Num formato mais prximo da reali-
dade do usurio e dos procedimentos da
empresa na qual a regra aplicada, esta
definio reflete exatamente os passos a
serem seguidos para alcanar os resulta-
dos esperados pela empresa. A partir das

Figura 1. Metodologia de pesquisa. Fonte: adaptada de [2]
regras de negcios consistentes s necessidades da empresa,
inicia-se o processo de desenvolvimento do software, atravs
das tcnicas e metodologias escolhidas para o projeto.
A diferena fundamental em ter a gesto das regras de neg-
cios segregadas da gesto de requisitos est na possibilidade
da avaliao do prprio usurio, de que suas regras foram
integralmente implementadas no software desenvolvido.
Neste artigo, o modelo da gesto das regras de negcios est
complementado com os princpios da transdisciplinaridade
entre a comunicao, a colaborao e a agilidade na gesto do
conhecimento [2]. Tendo como foco a participao ativa dos
envolvidos e responsveis pela informao que deve estar
atualizada; obtendo resultados muito maiores que uma simples
somatria dos conhecimentos catalogados.
Metodologia seguida e outras abordagens
Nesta seo, com a finalidade de estruturar o artigo e fornecer
os subsdios necessrios para a sua construo, ser apresen-
tada a metodologia de pesquisa utilizada para seu desenvol-
vimento. Para finalizar, sero apresentados os estudos mais
recentes relacionados ao gerenciamento de regras de negcio
no processo de desenvolvimento de software.
Metodologia de Pesquisa
O desenvolvimento do modelo da gesto de regras de negcio
foi aplicado com base na organizao GAIA que tem como ob-
jetivo o desenvolvimento de software. Baseado na metodologia
boas prticas
em uso para a avaliao de processos do desenvolvimento de
software foi aplicado, neste trabalho, um modelo de avaliao
genrico para o desenvolvimento de artigos. Foram seguidas
atividades de acordo com as trs etapas: Anlise Terica, De-
senvolvimento e Avaliao.
Em princpio, os trabalhos pesquisados foram planejados
por ano de publicao e assunto relacionados gesto do
conhecimento com foco nas regras de negcios. Especi-
ficamente limitados a trs anos, a partir de 2010, para os
peridicos e livros de autores com histrico em Engenharia
de Software e Qualidade no Processo de Desenvolvimento
de Software.
Dentre os assuntos relacionados gesto do conhecimento,
com foco no desenvolvimento de software, foram escolhidos
a gesto de regra de negcio, gesto da regra de requisitos,
avaliao de requisitos implementados e avaliao das regras
de negcios atendidas por aplicativos de software. Para me-
lhor compreenso, as atividades executadas foram ilustradas
pela Figura 1.
Na primeira etapa, so executadas duas macro atividades,
sendo a Fundamentao Terica (1), relacionados pesquisa
em artigos publicados. Esta tem como origem a busca em base
de dados para referncias e estudos desenvolvidos no seg-
mento de desenvolvimento de software e gesto de regras de
negcios. Em consequncia da pesquisa, elaborada a tabela
comparativa dos principais artigos que trataram de forma
explcita os assuntos.
Edio 66 - Engenharia de Software Magazine 53
 A etapa intermediria, de Desenvolvimento (2), que tambm
contempla a consolidao do modelo de gesto da regra de
negcios, so cumpridas com quatro macro atividades: Elabo-
rao do modelo de gesto da regra de negcio e Consolidao
do modelo de Gesto da Regra de Negcio; sendo que as ativi-
dades Estabelece critrio de avaliao e Aplicao do modelo
so compartilhadas com a etapa de Avaliao.
Na elaborao do modelo, foram adequadas abordagem
proposta, as definies identificadas em trabalhos anteriores.
Tendo como o principal diferencial, [3] a segregao das Regras
de Negcios dos Requisitos de Software, para que tenha uma
validao [4] de que o software estar contribuindo efetiva-
mente aos negcios da organizao.
Para obter uma validao completa e conclusiva, um dos
mtodos de elaborao do questionrio inclui a colaborao
dos membros da equipe que participaram neste estudo, de
modo a exatido das informaes prestadas associada ao
comprometimento dos participantes. Os critrios de avaliao
e a aplicao do modelo contemplam concomitantemente nas
etapas de Desenvolvimento e de Avaliao (3), mantendo a
objetividade da execuo e da avaliao.
Na etapa 3, a macro atividade Avaliao do Resultado teve
como finalidade analisar cada resposta do questionrio, atra-
vs da tabulao com a indicao de uso satisfatrio do modelo
de gesto. As respostas so obtidas atravs da macro atividade
de Aplicao do questionrio de avaliao.
Trabalhos Relacionados
A linha mestre para elaborar o quadro comparativo foi
transitar pelos diversos nveis da organizao. Desde o nvel
estratgico, de responsabilidade da alta administrao, at
o de validao das regras no software desenvolvido. Obvia-
mente, consultando as premissas da gesto do conhecimento,
do processo de gesto das regras de negcios e do impacto no
desenvolvimento de software.
O ponto inicial de qualquer atividade relacionada gesto do
conhecimento est na explicitao, padronizao e gerencia-
mento do conhecimento, enfatizado por [4]. Complementado
pelo armazenamento destes conhecimentos em separado quan-
do se trata de regras de negcios e requisitos de sistemas.
Com o foco em sistemas de informaes, necessria a
descrio das regras de negcios em modelos de testes. Este
modelo tem grande influncia na validao das regras im-
plementadas nos softwares, aumentando a sua qualidade.
Complementando a mesma linha de validao [1] defende a
melhoria da qualidade dos requisitos de usurios, tendo em
vista que ele recomenda a separao dos requisitos de sistemas
dos requisitos de usurios.
Um fator importante na gesto das regras de negcio est
na dependncia destas com o processo de negcios da orga-
nizao. O relacionamento entre as regras e os processos de
negcios proporciona mudanas rpidas das regras quando
existir alteraes da estratgia da organizao.
A alta administrao tem fundamental contribuio na ges-
to das regras de negcios, em funo do comprometimento
54 Engenharia de Software Magazine - Gesto de Regras de Negcios
com as metas da organizao. Atravs da incorporao com
a poltica organizacional, as regras de negcios conduzem a
alcanar as metas desejadas.
Na Tabela 1 possvel identificar a extenso em que a gesto
das regras de negcios percorre para obter a eficincia e eficcia
desta gesto nas organizaes de desenvolvimento de softwa-
re. E tambm verifica-se que os itens pesquisados refletem a
realidade de organizaes que possuem o conhecimento como
um de seus ativos organizacionais. Na qual, com a aplicao
dessas propostas percebem o benefcio da utilizao da gesto
das regras de negcios como fonte de qualidade em software e
o domnio destas regras ao longo da vida da organizao.
Outros trabalhos
Agora, para poder validar o estudo realizado, foi construda
uma reviso de literatura com as principais vertentes desse
trabalho. Nesse processo de reviso, foram abordados os traba-
lhos mais recentes (ltimos cinco anos), que foram publicados
em bases de dados de alta qualidade e de alta confiabilidade,
tais como, Scopus, ACM Library, IEEE Xplore, Science Direct,
entre outras. Tendo como finalidade expressar o verdadeiro
estado da arte das seguintes estruturas fundamentais para
esse trabalho: Regra de Negcio, Levantamento de Requisitos
e Gesto do Conhecimento.
Regra de Negcio
Uma definio clara de regra de negcio foi descrita por [2]
cujo entendimento ter a descrio atmica, na qual no pode-
r ser subdividida em partes; e deve afirmar, ou influenciar ou
controlar o comportamento dos negcios de uma organizao.
Dentre inmeras caractersticas da regra de negcio, o mesmo
autor cita algumas fundamentais:
Para tornar os processos de negcios com mais flexibilidade
as regras devem ser armazenadas separadamente de fcil
recuperao;
Deve prever que as regras de negcio evoluem ou se modifi-
cam independente do modelo de processos de negcios;
comum que as regras de negcios se alteram com maior
frequncia do que os processos de negcios;
Estando armazenado em separadas, num s repositrio, as
regras de negcio podem ser reutilizadas em vrios processos
de negcio;
A descrio padronizada facilita o entendimento e reutili-
zao da regra de negcio em outro contexto.
Em uma regra de negcio, a descrio deve ter clareza para
que a implementao desta regra tenha sucesso nos resultados
esperados pelo cliente [3], assegurando uma descrio e enten-
dimento de cada regra. Tambm deve existir uma sequncia
lgica de aplicao das mesmas. Atravs desta sequncia que
o sistema poder ser desenvolvido com garantia de sucesso na
implementao. Para cada conjunto de regras, exemplificado
em um cenrio de uma transportadora de mercadorias, confor-
me Tabela 2, existe uma sequncia lgica e ao mesmo tempo
cada regra representa a sua individualidade.
 boas prticas

Jr, E M Bizerra
Thi, Thanh Thoa Pham
Tosanguan, Piyanuch Silveira, D S
Helfert, Markus
Autores / Tcnicas e Mtodos Suwannasart, Taratip Gawe, Bartomiej (2012) Cruz, M L P M Sommerville, Ian (2011)
Hossain, Fakir
(2012) Wanderley, F J A
Dinh, Thang Le (2011)
Introduo, I (2012)
Alta administrao estabelece
Faz parte da estratgia para
estratgia para a Gesto da Regra - - - -
atingir as metas da Organizao
de Negcios
Apoio Gesto de RN um processo Incorporadas na poltica
- - - -
da Cultura Organizacional organizacional
Jr, E M Bizerra
Thi, Thanh Thoa Pham
Tosanguan, Piyanuch Silveira, D S
Helfert, Markus
Autores / Tcnicas e Mtodos Suwannasart, Taratip Gawe, Bartomiej (2012) Cruz, M L P M Sommerville, Ian (2011)
Hossain, Fakir
(2012) Wanderley, F J A
Dinh, Thang Le (2011)
Introduo, I (2012)
As regras de negcios so
Possui processo de Gesto da Regra As regras demandam
- - derivadas dos Processos de -
de Negcio definido mudanas rpidas
negcios
Procedimento para explicitao de Explicitao das regras de Regras descritas em Todas as regras devem estar
Descrio das regras de negcio -
regras de negcio negcios modelos de testes descritas
Padres de escrita da regra de Cita vrias regras: CIM, PSM, Usando OCL - Object Decomposio dos processos de
Prope padro prprio -
negcio SVBR, JSR-94 Constraint Language negcio para as regras de negcios
Processos de negcios e
Tratar Regras de negcios Separa o requisito de
Separa as regras de negcio dos tecnolgicos descritas de Considera regras de negcio em
separadas por nveis de decises da - Usurio com o requisito de
cdigos de aplicaes forma independentes (CIM, nveis
organizao e aplicaes Sistema
PIM, PSM)
Armazenar as regras de negcios Armazenar de acordo com Recomenda o
separadamente dos requisitos de - o nvel de negcio e de - - armazenamen-to em
softwares sistemas separado
A qualidade est na
Gerenciar regras de negcios Atravs de casos de testes
- - - validao dos requisitos
aumenta a qualidade do software com uso de ferramentas
de usurio
Validao da regra de negcio com Validar regras de negcios aos
- - - -
as regras da organizao processos da organizao
Validao da regra de negcio com a Validando as regras na fase
- - - -
aplicao em software de testes

Tabela 1. Comparativo em publicaes sobre a GRN

#Regra Definio da regra de negcio

1 As encomendas devem ser atendidas de acordo com a classificao dos Clientes.
A prioridade atender os clientes da classe A, conforme estabelecido em regra especfica. Exemplo: os clientes da Classe A so atendidos em primeiro lugar, com os melhores veculos e
2
motoristas disponveis. Sequencialmente, os clientes a classe B sero atendidos posteriormente ao da classe A.
Os clientes com classificao Z, por inadimplncia devero ter suas encomendas colocadas em lista de espera, sem programao para embarque, at que tenham a situao
3
regularizada.
Tabela 2. Definio de regra de negcios (exemplos).

A linguagem descrita estabelecida conforme entendimen-
to dos profissionais da rea operacional da organizao que
abrigam as regras de negcios.
A partir do momento em que as regras esto entendidas,
possvel iniciar o design do software, de acordo com o crono-
grama previsto para sua execuo. Em muitas situaes, estas
regras podem ser reescritas de acordo com os procedimentos
definidos na Gesto de Requisitos da organizao. Sendo que os
textos podero ser alterados, porm o contedo do ponto de vista
semntico jamais poder ser alterado. Inclusive, esse um dos
pontos crticos que podem levar ao fracasso no desenho e, con-
sequentemente, o desenvolvimento e a entrega do software.
Levantamento de Requisitos
Antes de iniciar um estudo sobre o levantamento de requi-
sitos, para um melhor entendimento, se faz necessrio um

Edio 66 - Engenharia de Software Magazine 55

processo de explicitao dos seus significados iniciando com
a definio de um requisito, que pode ser compreendido como
uma condio necessria para a obteno de um determinado
objetivo. No entorno desse artigo, adotaremos a definio de
um requisito no mbito de um sistema de software, que pode
ser compreendido como a descrio das funes e restries
que o produto a ser desenvolvido deve possuir.
Com esses termos bem definidos, o prximo passo explorar
os conceitos referentes ao levantamento de requisitos. Que de
acordo com [5] a fase primordial no processo de desenvolvi-
mento de software em que ocorre uma pesquisa de mercado
(junto ao cliente) para de forma simples e completa, encontrar,
organizar e rastrear as diversas funcionalidades que o sistema
deve obter.
Continuando com [5] e acrescentando ideias de [6] o levanta-
mento de requisitos pode ser definido como um conjunto de
mtodos e tcnicas empregadas para levantar, detalhar, docu-
mentar e validar os requisitos de um produto para sistemas
de informtica. Esse processo longo, moroso e com intensa
captura, combinao e disseminao do conhecimento.
nesse processo que todos os envolvidos no projeto, devem
trocar informaes sobre o contexto e as atividades que sero
executadas pelo software durante o seu desenvolvimento.
Durante, a sua descrio, essa atividade parece um tanto
quanto simplria, no entanto, realizar um bom levantamento
de requisitos um grande desafio.
Durante a sua elaborao, diferentes pontos de vistas e
expectativas divergentes entre, desenvolvedores, usurios e
clientes, tornam essa tarefa difcil e conflituosa. Fato este que
j se inicia com o cliente, tendo em vista, que em inmeros
casos, o cliente no est completamente certo das suas reais
necessidades.
Portanto, tudo isso fez e faz da fase de especificao de re-
quisitos uma atividade complexa e de alto risco para empresa,
influenciando diretamente no sucesso do projeto.
A maioria dos problemas encontrados nessa fase representam
cerca de 55% dos empecilhos em sistemas computacionais.
82% do esforo dedicado correo de erros est relacionada
a essa fase. Com tais dados em evidncia, pode-se novamente
reafirmar que os requisitos so a base de todo projeto, carac-
terizando de forma real o que os clientes necessitam para usar
ou modificar um sistema, e como este deve funcionar.
Interessante abordar tambm que esta constatao no se
torna verdica apenas no desenvolvimento de software, no
obstante tambm para qualquer processo que envolva a confec-
o de novos artefatos. Tudo isso demonstra que para chegar a
requisitos que realmente contemplem o sistema pretendido,
necessrio que esses sejam devidamente explicitados.
Dentre as atividades que fazem parte desse contexto, pode-
se citar o domnio da regra de negcio, captura e classificao
de requisitos, estabelecimento de prioridades, resoluo de
conflitos, verificao de inconsistncias e ambiguidade, e
finalmente, a negociao dos requisitos do sistema. Para au-
xiliar na execuo dessas atividades, alguns mtodos podem
ser utilizados.
56 Engenharia de Software Magazine - Gesto de Regras de Negcios
Um dos mtodos mais conhecidos e utilizados para espe-
cificao de sistemas o JAD (Joint Application Development).
A principal funcionalidade do JAD a descrio de uma va-
riedade de mtodos para conduzir workshops entre clientes
e desenvolvedores, fazendo com que esses trabalhem juntos
nas fases de desenvolvimento, principalmente durante a es-
pecificao dos requisitos.
Um segundo mtodo bastante utilizado so os pontos de
vistas orientados tcnica. Um exemplo bastante clssico desse
mtodo o VORD (Viewpoint Oriented Requirements Definition),
em que so definidos e estruturados diferentes pontos de vista
ficando a cargo do analista a integrao dos requisitos. Por fim,
todos esses mtodos, tcnicas e definies demonstram que o
levantamento de requisitos uma parte essencial e funcional
durante o processo de desenvolvimento de software.
Gesto do Conhecimento
Continuando na mesma linha de investigao e arguio dos
termos cruciais para a execuo desse projeto, o prximo passo
definir e esmiuar ao mximo o significado da gesto do
conhecimento, principalmente referente ao contexto da regra
de negcio. Vale definir, inicialmente, o que seria a gesto, que
pode ser entendida como um processo de coordenar tarefas,
atividades e projetos de maneira que sejam desempenhados
de forma eficaz e eficiente, sempre tendo em vista o objetivo
de gerenciar o conhecimento.
O conhecimento, dentro desse contexto, assume duas formas
principais, o Tcito e o Explcito. O primeiro refere-se ao co-
nhecimento que est armazenado na cabea das pessoas, sendo
pertencente somente ao indivduo que o detm. E o segundo,
explcito, refere-se ao conhecimento estruturado, inerente ao
indivduo, sendo pertence a sua organizao mantedora.
A principal funcionalidade da gesto do conhecimento se
refere a realizar a transformao do conhecimento tcito para
explcito. Processo esse, em que, o conhecimento deixa de ser um
bem apenas pertencente ao indivduo, e se torna, de forma es-
trutura, um ativo a todos os mtodos que desejarem utiliza-lo.
Alguns autores colocam algumas definies interessantes
sobre gesto do conhecimento, que uma abordagem da
empresa em busca de pontos, onde o conhecimento venha a
trazer uma vantagem competitiva. Ela pode ser vista como
um amplo processo de criao, uso e disseminao do conhe-
cimento dentro de toda e qualquer organizao que possua o
conhecimento como um de seus ativos capitais.
A gesto do conhecimento pode assumir diferentes defini-
es e denominaes, no entanto, mesmo que ora dispares,
todas as formas de expressar seu significado possuem no final
ao menos um aspecto de similaridade em seus sentidos.
Outra definio bastante interessante a que coloca a gesto
do conhecimento como uma estratgia que busca transformar
bens intelectuais da organizao - informaes registradas e o
talento de todos os seus usurios - em uma maior produtivida-
de. Ela procura apresentar novos valores dentro da organizao
e proporcionar de uma forma geral um aumento final na sua
capacidade de produtividade.

Por conseguinte, a gesto do conhecimento pode ser com-
preendida como uma ferramenta gerencial de administrao,
planejamento e controle do conhecimento modelando parte
do conhecimento que existe na cabea das pessoas em regras
de negcio, tornando-as visveis toda organizao de uma
forma simples e de fcil acesso, executando assim a principal
funcionalidade da gesto do conhecimento .
Modelo da Gesto de Regras de Negcios
O processo de software compreendido como sendo um ciclo
de atividades que se inicia na definio dos requisitos de softwa-
re at a entrega do produto desenvolvido. Sendo que neste ciclo
est compreendido tambm o planejamento do desenvolvimento
dos requisitos de software, a codificao e teste do software,
implantao da aplicao com os requisitos de software.
O modelo proposto por este artigo, conforme Figura 2, alm
deste ciclo do processo de software, fica prevista a gesto
das regras de negcios, antes da definio dos requisitos de
software.
Da mesma forma, esta gesto tambm est compreendida
num ciclo de atividades que contempla inicialmente a identi-
ficao das necessidades e oportunidades de negcios, at a
implantao destas regras na rotina das atividades operacio-
nais da organizao. Um conjunto de atividades fica elencado
a seguir:
Identificar necessidade ou oportunidade de negcio
basicamente, a origem de uma regra de negcio tem como
Figura 2. Fluxo das atividades do modelo de gesto de regras de negcio
boas prticas
fonte novas necessidades para resolver um problema existente
por falha no processo; ou por uma nova oportunidade no
mercado que proporcionar divisas ou novos lucros para a
organizao;
Analisar regras de negcio existentes a nova regra de
negcio, tambm considerada como regra candidata, deve ser
avaliada quanto a sua aplicao como sendo nica antes de ser
detalhada em definitivo;
Especificar regra de negcio candidata a descrio da
regra deve ter as caractersticas essenciais para o entendimento
[4] para ter a compreenso suficiente para que seja aplicada
corretamente, sem ambiguidade e ter a preciso nos resultados
esperados;
Aprovar regras de negcios candidatas quando a regra
de negcio est alinhada estratgia da organizao e es-
tratgia de negcios, com resultados mensurveis, deve ser
aprovada;
Adequar a especificao da regra de negcio caso no
tenha aprovao da regra, esta deve ser adequada para ter o
mnimo dos quesitos necessrios para ser aprovada, para tanto
se necessita da adequao da especificao;
Gesto das regras de negcios este um processo intei-
ramente destinado manuteno da regra desde a sua espe-
cificao at a desativao. Toda regra pode sofrer alteraes
ao longo de um perodo para se adequar s novas realidades
em que a organizao est submetida, assim requerendo uma
manuteno constante;
Edio 66 - Engenharia de Software Magazine 57
 Validar regra de negcio no software o software que
atende s regras de negcio devem ter estas regras validadas
pelo resultado almejado, pela fidelidade regra aprovada para
uso na organizao;
Processo de Desenvolvimento de Software este um
processo conhecido pelas atividades de planejamento, le-
vantamento de requisitos at a entrega efetiva do produto de
software. Conforme descrito por [1], as atividades previstas
no processo deve ter como objetivo a qualidade final do
software.
Considerando que a gesto do conhecimento um processo
nico e delimitado pelo seu domnio, em funo da natureza,
objetivo e responsabilidade; se torna perceptvel a separao
o controle das necessidades de negcios e dos requisitos de
softwares. Outro fator est relacionado evoluo das necessi-
dades de negcios que tm velocidades e amplitudes diferentes
dos requisitos de softwares.
Ao iniciar o desenvolvimento de software, o objetivo prin-
cipal atender s necessidades dos usurios finais atravs
dos requisitos do sistema. Na organizao, as atividades so
executadas seguindo um modelo de processo que analisa os
requisitos e projeta uma arquitetura do software para aten-
der aos requisitos analisados. Efetivamente, mecanizando
Figura 3. Fluxo ilustrativo do modelo de GRN
58 Engenharia de Software Magazine - Gesto de Regras de Negcios
os processos, tratando os dados de entradas e formatando as
informaes resultantes, at que o processo reflita as definies
das regras de negcios.
De modo geral, as regras de negcio definem as condies
em que um processo realizado ou as novas condies aps
a concluso de um processo. A grande vantagem em separar
a regra de negcio do requisito de software est na validao
do sistema com a lgica do negcio. Uma vez que a regra de
negcio passa a ser um processamento, descrito por um requi-
sito de software, esta deve validada.
O principal objetivo deste artigo foi modelar um processo
de gerenciamento de regras de negcios possvel de ser uti-
lizado numa organizao em que estas regras so utilizadas
somente como insumo para o desenvolvimento de software.
Foi escolhido o GAIA para aplicar o modelo proposto neste
artigo, com o objetivo de aumentar a qualidade dos produtos
desenvolvidos.
Este modelo ser aplicado em ambiente especificamente
de desenvolvimento de software, dando como foco princi-
pal o gerenciamento da regra de negcio por uma equipe
que conhece o gerenciamento de requisitos de software.
Com a nova viso para regra de negcio as pessoas estaro
comprometidas tambm com os objetivos estratgicos da
organizao.

Atualmente o GAIA contempla um modelo de desenvol-
vimento com o ciclo de vida caracterizado pelo processo de
software, no qual a gesto de requisito prioriza os requisitos
de sistemas. Com o novo modelo passar a executar atividades
de gesto das regras de negcios que contempla maiores esfor-
os na manuteno dos requisitos de usurios com objetivos
estratgicos da organizao.
Cada projeto desenvolvido pelo GAIA passar por um critrio
mais efetivo na escolha da funcionalidade a ser desenvolvida
juntamente com as regras priorizadas pela organizao. Como
podemos observar na Figura 3, as atividades de desenvolvi-
mento de software esto representadas pelo fluxo em amarelo,
enquanto que no fluxo azul ficam demonstradas as atividades
da manuteno das regras de negcios.
O modelo tem como objetivo aumentar a qualidade do
software desenvolvido, desde a sua concepo, projeto, de-
senvolvimento, entrega e resultados de sua aplicabilidade. No
fluxo tradicional da gesto de requisitos e sua implementao,
o objetivo atender as definies descritas nestes requisitos
funcionais e no-funcionais. Enquanto que com a implemen-
tao do fluxo acrescido da gesto de regras de negcios, o
comprometimento fica ampliado aos resultados que o software
deve proporcionar organizao patrocinadora do projeto.
boas prticas
Referncias:
1. I. Sommerville, Engenharia de Software. 9 edio. Editora Pearson do
Brasil, 2011.
2. Sujithra S. and Chandrashekar R., Externalizing business rules from
business processes for model based testing, International Conference on
Industrial Technology, 2012, pp. 312-318.
3. Wan-Kadir, WMN; Pericles Loucopoulos; Relating evolving business rules
to software design, 2012, pp. 367-382.
4. P. Tosanguan, T. Suwannasart, An Approach for Defining Rules as Functions
in Rule-Based Rule-Based Software Development, International Conference
on Digital Information Management, 2012, pp. 30-34.
5. Wen B., Z. Luo, P. Liang Distributed and Collaborative Requirements
Elicitation based on Social Intelligence, Ninth Web Information Systems
and Applications Conference, 2012, pp. 127-130.
6. D. P. A. Junior and R. Campos Definio de requisitos de software baseada
numa arquitetura de modelagem de negcios. Prod. Vol. 18 n1, So Paulo.
ISSN 0103-6513, 2008.
Voc gostou deste artigo?
D seu voto em www.devmedia.com.br/esmag/feedback
Ajude-nos a manter a qualidade da revista!
Edio 66 - Engenharia de Software Magazine 59
60 Engenharia de Software Magazine - Gesto de Regras de Negcios
 boas prticas

Edio 66 - Engenharia de Software Magazine 61