2.7.

4 ANLISE DE NEGCIOS:
Metodologias de modelagem e descrio de
processos de negcios; identificao e controle de
processos crticos em funo da estratgia da
organizao; entendimento das diferenas entre
uma organizao funcional e uma centrada em
processos; conhecimento de fundamentos de
gesto de processos de negcio; fundamentos do
BPM, notao BPMN.

Exemplo de Organizao funcional

Organizao funcional : As pessoas so alocadas

em departamentos conforme a especializao , pois
os problemas surgidos na operao de um setor
sero afetos ao chefe especializado na tecnologia
em questo.
Entretanto, a multiplicidade de comandos poder
levar a confuses, com disputa de poder e
concorrncia entre os especialistas, as tenses
decorrentes com prejuzos para o moral e mesmo
falta de responsvel, quando uma questo cai
dentro de uma zona cinzenta e ningum por ela se
responsabiliza.
Centrada ao processos : As organizaes orientadas
a processos, prioriza a gesto dos processos que
cruzam as reas funcionais, mas preserva a diviso
do trabalho que envolve um viso dinmica de
como a organizao produz o valor.
A primeira medida da estrutura organizacional de
funes para processos a definio clara e
objetiva de quem se beneficia ou seja foco no
cliente interno ou externo buscam uma boa
qualidade da entrega do produto ou servio, sendo
assim
orientadas
pelo
atendimento
das
necessidades, interesses e desejos deles.

Exemplo Centrada em Processos

Organizao funcional x Centrada em processos

Resumo do material de estudo BMPN

Engenharia de requisitos: conceitos bsicos;
tcnicas de elicitao de requisitos; gerenciamento
de requisitos; especificao de requisitos; tcnicas
de validao de requisitos; prototipao;
Mtrica e estimativas de software, anlise de
pontos por funo; tcnicas de modelagem de BI
(Business Inteligence) e Data mining;
1- Conceitos Bsicos
1.1- Engenharia de Requisitos
A engenharia de requisitos procura sistematizar o
processo de definio de requisitos. Essa
sistematizao necessria porque a complexidade
dos sistemas exige que se preste mais ateno ao
correto entendimento do problema antes
do comprometimento de uma soluo. [Leite 94].
Uma boa definio para requisitos pode ser
encontrada em [Leite 94] e mostrada a seguir.
Requisitos: Condio necessria para a obteno
de certo objetivo, ou para o preenchimento de certo
objetivo.
Pesquisas sobre a aquisio (elicitao) de
requisitos so valorosas por duas razes:
primeiramente, da perspectiva da engenharia de
software, a elicitao de requisitos talvez a mais
1

crucial parte do processo de desenvolvimento de

software. Estudos [Boehm 84] indicam que, quando
s detectados depois do software implementado,
erros em requisitos de software so at 20 vezes
mais caros de se corrigir que qualquer outro tipo de
erro. Alm disso, elicitao de requisitos no
atualmente muito bem apoiada por ferramentas de
software.
Para a engenharia de requisitos fundamental que
o engenheiro de software delimite os contornos do
macrosistema em que a definio de software
ocorrer, ou seja, delimitar o Universo de
Informaes do sistema (UdI).
importante ressaltar que o UdI sempre existe. O
UdI independe do modelo que estamos utilizando.
Mesmo que o macrosistema no esteja bem
definido, sempre podemos, e devemos, estabelecer
os limites de nossa atuao. Quanto mais bem
delineado um UdI, maiores so as chances de um
software bem definido.
A elicitao de requisitos um processo que est
constantemente em evoluo, ou seja, toda vez que
o UdI muda, o modelo resultante do processo de
elicitao de requisitos deve mudar junto. Esta
realidade muitas vezes desconsiderada atravs do
que se procurou determinar como um
congelamento dos requisitos. Se por um lado a
constante evoluo do UdI pode gerar custos altos
no desenvolvimento, uma vez que temos de estar
atualizando nossos requisitos, por outro lado o
congelamento dos requisitos em um determinado
momento no deve produzir efeitos contrrios,
aumentando consideravelmente o custo do
produto final em decorrncia de alteraes que
sero demandadas para a aceitao do software.
Este um tema ainda pouco explorado e maiores
pesquisas devero ser realizadas neste campo para
que possamos conhecer o ponto ideal de equilbrio.
Quais so essas tcnicas de elicitao de requisitos?
Entrevistas
Questionrios
Observaes de campo
Investigao e anlise documental
Prototipao
Entrevista
Okay, okay, mascomo so feitas as entrevistas?
Terei de entrevistar todas as pessoas da empresa?
Claro que no. Quer dizer, se a empresa for grande,
no.
O objetivo das entrevistas obter a opinio dos

entrevistados, o que ajuda na descoberta dos

problemas-chave a serem tratados, conhecer os
sentimentos sobre o estado atual sistema (caso
exista) e levantar procedimentos informais
(os workarounds).
As entrevistas relevam importantes dados sobre o
que ser necessrio no sistema e podem seguir dois
caminhos. Um longo, que poder no fornecer
dados slidos, mas por outro lado, poder fornecer
detalhes que em uma entrevista fechada.
No caminho longo, o analista faz perguntas abertas
ou subjetivas, e deixa a pessoa responder o que
ela desejar. Nisso, as pessoas podem devanear e
acabar falando de coisas inerentes ao projeto, mas
podem levar a novos questionamentos e fornece
mais
riquezas
de
detalhes.
No caminho curto, as perguntas so objetivas,
como sim ou no, boto quadrado ou redondo,
etc. Todo o material, claro, deve ser anotado e se
possvel, gravado (desde que se tenha a permisso
do entrevistado).
Entrevistas devem ser planejadas, com data e hora
marcada, tempo de durao, elaborao prvia das
questes,
Depois, esse material passado para a forma de
dados, a fim de se juntar aos prximos dados.
Questionrios
Os questionrios so interessantes e podem
fornecer um feedbackrpido, pois possuem o
formato pergunta-resposta, entretanto, deve ser
usado como uma forma de complementar, afim de
quantificar o que foi levantado em entrevistas,
determinar como certas opinies so realmente
difundidas ou limitadas.
Uma das vantagens a possibilidade de coletar
dados de uma grande quantidade de usurios para,
ento, selecionar pessoas-chave para entrevistas.
Devido a falta da presena fsica do entrevistador
quando o questionrio aplicado, preciso ter
alguns cuidados na aplicao de questionrios.
Confira:
Possuir questes claras e sem ambiguidades
Possuir um fluxo definido
Administrao planejada em detalhes
Levantar antecipadamente as dvidas das
pessoas que iro respond-lo
Como nas entrevistas. questes podem ser
subjetivas ou objetivas. No caso de subjetivas,
limite a quantidade de caracteres ou palavras da
2

resposta, como no Twitter. Por exemplo,

Responda com at 20 palavras.
No caso de perguntas subjetivas, ateno com
aquelas que permitem respostas muito vagas
Em questes objetivas, utilize mtodos que
envolvam escalas, como por exemplo, Escolha o
nvel de satisfao com tal funcionalidade, de 1 a
5, com 1 sendo muito insatisfeito e 5 muito
satisfeito.
Questionrios no devem ter mais que duas
folhas A4.
Mtodos de aplicao
A melhor forma de se coletar os dados de
questionrios atravs de uma reunio.
Aps informaes serem passadas, instrues e e
afins, a maior parte das pessoas interessadas ou
alvo do sistema estaro presentes. Isso torna a fcil
passar as instrues de maneira uniforme e o
retorno muito bom.
Uma segunda maneira de aplicar um questionrio,
o Analista entregando e recolhendo os
questionrios individualmente. Sua desvantagem
o tempo que se perde.
Observao
Esta tcnica uma interessante maneira capturar
informaes relevantes para o desenvolvimento do
projeto, pois coloca o analista dentro do campo de
atuao dos usurios do sistema, observando como
as coisas so feitas, quais os processos, quais os
meios alternativos que so tomados frente
situaes delicadas, enfim, importantssima para
coletar informaes que, normalmente passam
despercebidas quando usadas outras tcnicas.
Captura o que realmente feito e no o apenas
o que documentado ou explicado
Auxilia a compreenso do relacionamento entre
o tomador de deciso e os demais
Auxilia a confirmar ou negar informaes
obtidas por outras tcnicas
Investigao
A investigao coleta informaes que so difceis
de se obter por entrevistas, questionrios ou
observaes. Tais informaes so:
Histrico da organizao
Cultura e hbitos internos
Relacionamentos entre os diferentes setores que
utilizao o produto
Informaes financeiras
Direcionamentos futuros

Os dados coletados podem ser qualitativos ou

quantitativos.
Dados quantitativos fornecem dados baseados em
nmeros, mtricas, metas e relatrios de
desempenho, relatrios usados para tomadas de
decises, formulrios e fichas, etc.
Dados qualitativos so obtidos atravs de anlise de
memorandos, quadros de avisos, manuais, etc.
Dados qualitativos so teis para conhecer as
polticas da organizao, identificar termos comuns,
conceitos, comportamentos, linguagem e cultura,
compreender o fluxo de informao e o grau de
comprometimento dos membros.
Prototipao
Finalmente, a prototipao, que deve ser um
instrumento usado com cautela para se recolher
requisitos.
Este artifcio normalmente empregado quando o
cliente no sabe expressar seus requisitos de forma
satisfatria, porm, uma faca de dois legumes.
Um prottipo pode ser semi-funcional, algo que
fornea uma resposta. Pode ser em HTML, flash, ou
outra tecnologia, que poder fornecer a sensao
de funcionalidade, ou pode ser um desenho feito
mo, um mockup (montagem de tela com
programas de edio de imagens), etc.
O problema de prottipos funcionais, que alm do
tempo que se leva para constru-los, parte dele
pode ser levado para o projeto acidentalmente, o
que no nem um pouco considerado boa prtica
de programao. Outro fator, que o cliente pode
achar que o prottipo algo realmente funcional e
querer apressar o andamento do projeto, dando
menos importncia ao desenvolvimento completo
do trabalho.
Este artigo finaliza ento um breve conceito sobre
Anlise de Sistemas, porm, existe ainda um
campo enorme que no foi abordado.
Os temas expostos nos artigos relacionados nesta
srie, so materiais de estudo acadmico de minha
atual formao em andamento. Espero, com isso,
abrir caminhos para que pessoas interessadas em
saber o que e como funciona a Anlise de
Sistemas possam sanar algumas dvidas e, outras
pessoas que j esto estudando e precisam de
algum material de referncia.

O que o Gerenciamento de Requisitos?

Refinamento da definio do sistema
O gerenciamento de requisitos um modelo Gerenciamento dos requisitos variveis
sistemtico para encontrar, documentar, organizar
e rastrear os requisitos variveis de um sistema.
Anlise do Problema
Um requisito definido como:
A anlise do problema feita para compreender os
Uma condio ou uma capacidade com a qual o problemas e as necessidades iniciais dos envolvidos,
sistema deve estar de acordo.
e propor solues de alto nvel. um ato de
Nossa definio formal de gerenciamento de ponderao e anlise encontrar "o problema por
requisitos trata-se de um modelo sistemtico para:
trs do problema". Durante a anlise do problema,
identificar, organizar e documentar os requisitos so reconhecidos os problemas reais e quais so os
do sistema, e
envolvidos. Alm disso, voc define quais so, de
estabelecer e manter acordo entre o cliente e a uma perspectiva de negcios, as fronteiras da
equipe do projeto nos requisitos variveis do soluo e as restries de negcios da soluo.
sistema.
Voc tambm dever ter analisado o caso de
Os principais itens para o gerenciamento eficiente negcio para o projeto, para que haja uma boa
de requisitos incluem manter uma declarao clara compreenso de qual o retorno esperado do
dos requisitos, juntamente com atributos aplicveis investimento feito do sistema que est sendo
para cada tipo de requisito e rastreabilidadepara construdo.
outros requisitos e outros artefatos do projeto.
Consulte tambm Detalhamento do Fluxo de
A coleta de requisitos pode parecer uma tarefa bem Trabalho: Analisar o Problema.
precisa. Nos projetos reais, contudo, voc
encontrar dificuldades porque:
Noes Bsicas sobre as Necessidades dos
Nem sempre os requisitos so bvios e podem Envolvidos
vir de vrias fontes.
Os requisitos vm de vrias fontes, como clientes,
Nem sempre fcil expressar os requisitos parceiros, usurios finais e peritos do domnio.
claramente em palavras.
Voc precisa saber o melhor modo de determinar
Existem diversos tipos de requisitos em quais devem ser as fontes, como obter acesso a
diferentes nveis de detalhe.
essas fontes e qual a melhor forma de levantar as
O nmero de requisitos poder impossibilitar a informaes delas. Os indivduos que constituem as
gerncia se no for controlado.
fontes primrias para essas informaes so
Os requisitos esto relacionados uns com os conhecidos como os envolvidos no projeto. Se
outros, e tambm com o produto liberado do estiver desenvolvendo um sistema de informaes
processo de engenharia do software.
para ser usado internamente na sua empresa, voc
Os requisitos tm propriedades exclusivas ou dever incluir na sua equipe de desenvolvimento
valores de propriedade. Por exemplo, eles no pessoas com experincia de usurio final e com
so igualmente importantes nem igualmente experincia no domnio do negcio. Com bastante
fceis de cumprir.
freqncia, voc comear os debates no nvel de
H vrias partes interessadas, o que significa que um modelo de negcio em vez de no nvel de um
os requisitos precisam ser gerenciados por sistema. Se estiver desenvolvendo um produto para
grupos de pessoas de diferentes funes.
ser vendido para um estabelecimento comercial,
Os requisitos so alterados.
voc dever fazer uso extensivo do seu pessoal de
Ento, que habilidades voc precisa desenvolver em marketing para entender melhor as necessidades
sua organizao para ajud-lo a gerenciar essas dos clientes daquele mercado.
dificuldades? Ns aprendemos que importante O levantamento de informaes pode ocorrer
dominar as seguintes habilidades:
atravs de tcnicas como entrevistas, discusso de
Anlise do problema
idias, prottipos conceituais, questionrios e
Noes bsicas sobre as necessidades dos anlise competitiva. O resultado do levantamento
envolvidos
seria uma lista das solicitaes ou necessidades que
Definio do sistema
foram descritas textual e graficamente, e que
Gerenciamento do escopo do projeto
receberam prioridade uma em relao outra.
4

Consulte tambm Detalhamento do Fluxo de

Trabalho: Compreender as Necessidades dos
Envolvidos.
Definio do Sistema
Definir o sistema significa traduzir e organizar as
necessidades dos envolvidos em descries
significativas do sistema a ser construdo. No incio
da definio do sistema, ocorre o seguinte: as
decises sobre o que constitui um requisito, o
formato de documentao, a formalidade do
idioma, o grau de especificidade dos requisitos
(quantos e com que detalhe), a prioridade das
solicitaes e o esforo estimado (duas avaliaes
bem diferentes em geral atribudas por pessoas
diferentes em testes separados), os riscos tcnicos
e de gerenciamento, e o escopo inicial. Parte dessa
atividade pode incluir modelos de design e
prottipos iniciais diretamente relacionados aos
mais importantes requisitos dos envolvidos. O
resultado da definio do sistema uma descrio
do sistema que esteja em idioma natural e tambm
seja grfica.
Consulte tambm Detalhamento do Fluxo de
Trabalho: Definir o Sistema.
Gerenciamento do Escopo de um Projeto
Para gerenciar com eficincia um projeto,
necessrio priorizar os requisitos, com base em
retorno dado por todos os envolvidos, e gerenciar o
seu escopo. Vrios projetos tm seus
desenvolvedores trabalhando nos chamados "ovos
de Pscoa" (caractersticas que o desenvolvedor
acha interessantes e desafiadoras), em vez de
estarem concentrados desde o incio em tarefas
que aliviam algum risco no projeto ou estabilizam a
arquitetura do aplicativo. Para assegurar que os
riscos de um projeto sejam resolvidos ou aliviados o
mais cedo possvel, voc deve desenvolver seu
sistema de modo incremental, escolhendo
cuidadosamente os requisitos para cada
incremento que alivia os riscos conhecidos do
projeto. Para faz-lo, voc precisa negociar o
escopo (de cada iterao) com os envolvidos no
projeto. Normalmente, isso requer boas habilidades
no gerenciamento de expectativas dos resultados
do projeto em suas diferentes fases. Voc tambm
precisa ter controle das origens dos requisitos, da
aparncia dos produtos liberados pelo projeto e do
processo de desenvolvimento propriamente dito.

Consulte tambm Detalhamento do Fluxo de

Trabalho: Gerenciar o Escopo do Sistema.
Refinamento da Definio do Sistema
A definio detalhada do sistema precisa ser
apresentada de maneira que os envolvidos possam
entend-la, concordar com ela e sair dela. Ela
precisa abordar no apenas a funcionalidade, mas
tambm a compatibilidade com os requisitos legais
ou reguladores, a usabilidade, a confiabilidade, o
desempenho, a capacidade de suporte e de
manuteno. Um erro comum acreditar que o que
voc sente complexo para estabelecer
necessidades que tenham uma definio complexa.
Isso cria dificuldades para explicar a finalidade do
projeto e do sistema. As pessoas podem ficar
impressionadas, mas elas no daro bons retornos
por falta de compreenso. Voc deve se esforar
para compreender o pblico destinado aos
documentos que voc produz para descrever o
sistema. Voc sempre poder produzir vrios tipos
de descrio para pblicos diferentes.
J vimos que a metodologia do caso de uso, muitas
vezes em combinao com prottipos visuais
simples, um modo bem eficiente de comunicar a
finalidade do sistema e definir os detalhes do
sistema. Os casos de uso ajudam a colocar os
requisitos em um contexto, eles contam uma
histria de como o sistema ser usado.
Outro componente da definio detalhada do
sistema estabelecer como o sistema dever ser
testado. Planos de teste e definies dos testes a
serem realizados nos dizem quais capacidades do
sistema sero verificadas.
Consulte tambm Detalhamento do Fluxo de
Trabalho: Refinar a Definio do Sistema .
Gerenciamento dos Requisitos Variveis
No importa o quo cuidadoso voc seja sobre a
definio dos seus requisitos, sempre haver
mudanas. O que torna complexo o gerenciamento
dos requisitos variveis no apenas que um
requisito mudado implicar mais ou menos tempo
gasto na implementao de uma determinada
caracterstica nova, mas tambm que a mudana
em um requisito ter impacto em outros requisitos.
Voc precisa certificar-se de compor uma estrutura
de requisitos que seja adaptvel a mudanas, e de
usar vnculos de rastreabilidade para representar as
dependncias entre os requisitos e outros artefatos
do ciclo de vida do desenvolvimento. O
5

gerenciamento de mudana inclui atividades como

estabelecer uma linha de base, determinar quais
dependncias so importantes de serem
rastreadas, estabelecer a rastreabilidade entre itens
correlatos e o controle de mudana.
O que Gerenciamento de Requisitos?
Corresponde ao conjunto de atividades que auxilia
a equipe do projeto a identificar, controlar e
rastrear os requisitos, bem como as alteraes nos
requisitos em muitos momentos do projeto.
Em outras palavras, o processo que gerencia
mudanas nos requisitos de um sistema.
Estas mudanas ocorrem conforme os clientes
desenvolvem um melhor entendimento de suas
reais necessidades.
Novos requisitos surgem e h alteraes nos
requisitos em todos os estgios do processo de
desenvolvimento do sistema. So comuns os casos
em que mais de 50% dos requisitos so alterados
antes que o sistema seja posto em operao, o que
causa srios problemas para os desenvolvedores.
Para minimizar dificuldades, os requisitos devem
ser documentados e controlados.
Quando no h controle de alteraes, mudanas
de baixa prioridade podem ser implementadas
antes daquelas de alta prioridade, alm de
mudanas com
alto
custo no
serem
necessariamente aprovadas. Um levantamento em
mais de 4.000 empresas europia identificou que
uma das principais reas problemticas do
desenvolvimento e produo de software era o
gerenciamento de requisitos dos clientes (internos
e externos).
As principais preocupaes de gerenciamento de
requisitos so:
Gerenciar mudanas nos requisitos acordados;
Gerenciar os relacionamentos entre os
requisitos;
Gerenciar as dependncias entre o documento
de requisitos e outros documentos produzidos
ao longo do sistema e do processo de
engenharia de software.
As mudanas nos requisitos podem ser devidas a
erros e confuso no processo de engenharia de
requisitos, design ou problemas de implementao.
Novos requisitos podem surgir conforme os
stakeholders
desenvolvem
uma
melhor
compreenso do sistema ou em decorrncia de
alteraes em circunstncias externas como novas

leis ou regulamentaes introduzidas no ambiente

de negcio.
Os requisitos no podem ser gerenciados de forma
efetiva sem rastreabilidade. Um requisito
rastrevel se for possvel identificar quem solicitou
o requisito, porque o requisito existe, quais os
requisitos relacionados e como os requisitos se
relacionam as outras informaes como design de
sistemas, implementaes e documentos do
usurio. Estas informaes so utilizadas para
identificar todos os requisitos afetados por
mudanas propostas.
Boas prticas de gerenciamento de requisitos,
como uma manuteno de dependncias entre
requisitos, tm benefcios em longo prazo, como
maior satisfao do cliente e custos de
desenvolvimento mais baixos. Uma vez que os
retornos no so imediatos, o gerenciamento de
requisitos
pode
parecer
uma
despesa
desnecessria. Entretanto, sem a gerencia, a
economia de curto prazo ser devastada pelos
custos em longo prazo.
Os problemas com gerenciamento de requisitos
geralmente significam que os clientes no ficaro
satisfeitos quando da entrega do produto.
Ferramentas de gerenciamento de requisitos
podem prover facilidades como:
Um sistema de banco de dados para
armazenamento de requisitos;
Anlise de documento e facilidades de gerao
para ajudar a construir um banco de dados de
requisitos e auxiliar na criao dos documentos
de requisitos;
Facilidades de gerenciamento de mudanas que
ajudam a garantir que as mudanas foram
avaliadas e cotadas corretamente;
Facilidades de rastreabilidade que auxiliam os
engenheiros de requisitos a encontrar
dependncias entre requisitos.
Gerenciamento de requisitos
Aos Requisitos esto associados os principais
problemas do desenvolvimento de software.
Requisitos que no refletem as reais necessidades
dos usurios, por serem incompletos ou
inconsistentes.
As principais dificuldade relatadas so as mudanas
em requisitos j acordados e a grande dificuldade
6

para prosseguirem o entendimento comum entre

os usurios e os desenvolvedores, provocando retrabalho, atrasos no cronograma, custos
ultrapassados e a insatisfao dos clientes e
usurios de softwares
Muitos desses erros poderiam ser evitados se as
organizaes dispusessem de um processo de
engenharia de requisitos definido, controlado,
medido e aprimorado. No entanto percebesse que
para muitos profissionais da rea de informtica
esses conceitos no so muito claros., o que
certamente dificulta a ao dos gerentes no sentido
de
aprimorar
os
seus
processos
de
desenvolvimento.
Conceito de Requisitos e Engenharia de Requisitos
Antes de abordar o processo de engenharia de
requisitos, importante conceituar requisito, termo
freqentemente citado, debatido e utilizado na
redao de contratos, sem que as partes possuam
uma compreenso nica de seu significado.
Os requisitos de um sistema constituem uma
especificao das caractersticas e propriedades do
sistema ou uma descrio do que o sistema deve
fazer, de como ele deve se comportar, bem como
suas restries de operao.
importante ressaltar que os requisitos descrevem
o que o sistema deve fazer. Quando o requisito
expresso em termos do comportamento do
sistema, esse comportamento deve ser passvel de
ser percebido por um observador externo ao
sistema.
Os requisitos de um sistema podem ser organizados
em diferentes nveis de abstrao: Requisitos de
negcios, requisitos de usurios e requisitos
funcionais.
Os requisitos de negcio correspondem aos
objetivos do negcio ou do usurio que devem
ser satisfeitos pelo sistema. Normalmente so
descritos atravs de um documento denominado
viso ou escopo do sistema.
Requisitos de Usurios descrevem as atividades
que os usurios devero ser capazes de executar
com
a
utilizao
do
sistema
Requisitos funcionais so os que descrevem as
funcionalidades que o sistema deve possuir para
que o usurio possa executar suas atividades.

Embora o que se pensa dos requisitos:

- Nem sempre so bvios;
- Chegam por vrias fonts;
- Nem sempre so facilmente expressos em
palavras;
- Esto relacionados entre si e entre outros
produtos do processo de engenharia de software;
- Possuem propriedades e valores nicos;
- MUDAM!!
Alem deste, uma especificao de requisitos deve
conter:
A)
Requisitos
no
funcionais:
padres,
regulamentos e contratos com os quais o sistema
deve ter conformidade; descrio de interfaces
externas e requisitos de desempenho.
B) Restries: limita a possibilidade de escolha do
desenvolvedor no projeto e na implementao do
produto.
C) Atributos de qualidade: ampliam a descrio das
funcionalidades dos sistema atravs da descrio de
caractersticas de qualidade do produto. Que sejam
importantes para o cliente e para o desenvolvedor.
Antes de iniciar a especificao de requisitos
importante que a organizao tenha definido um
template do documento que dever ser elaborado,
visando um entendimento comum do que deve ser
produzido. O IEEE Guide for developing systems
requeriments specifications um exemplo de
template detalhado que pode ser utilizado com este
propsito.
Processo de engenharia de requisitos
Para elaborar e manter uma especificao de
requisitos necessrio que os desenvolvedores
executem um conjunto estruturado de atividades
destinas a elicitar, documentar, analisar e validar
requisitos. Este conjunto de atividades, iterativas
por natureza, recebe o nome de Processo de
Engenharia de Requisitos.
Quanta a organizao no dispe deste processo
formalmente definido e amplamente divulgado, os
desenvolvedores elaboram a especificaes de
requisitos de forma emprica, executando
atividades no padronizadas e definidas
individualmente.
Se isto ocorre, a qualidade da especificao
7

depender exclusivamente da experincia e

formao das pessoas, havendo assim uma elevada
probabilidade de ocorrerem conflitos e re-trabalho.
As atividade que compe o processo de Engenharia
de Requisitos e um conjunto de boas prticas que
apiam a sua execuo sero a seguir
apresentadas:
A) Elicitar - Elicitar requisitos o nome usualmente
atribudo atividade voltada para descobrir
(identificar, deduzir, extrair, evocar, obter) os
requisitos de um sistema, atravs de entrevistas
com os interessados pelo sistema, da anlise do
domnio do problema ou de estudos de mercado.
Na elicitao de requisitos constituem boas prticas
a redao de uma declarao de viso e escopo do
sistema; a definio dos procedimentos para
desenvolvimento dos requisitos, a identificao das
classes de usurios e dos diferentes grupos de
interesse no sistema, a identificao dos casos de
uso, a analise dos fluxos de trabalho dos usurios, a
definio dos atributos de qualidade do sistema e o
desenvolvimento de mecanismos que possibilitem o
re-uso de requisitos
B) Analisar - Na anlise os requisitos elicitados so
compreendidos e detalhadamente analisados por
todos os interessados no sistema. Nesta atividade
surgem muitos conflitos, sendo comum haver
necessidade de haver negociao para que os
requisitos sejam aceitos por todos.
As boas prticas de anlise referem-se a elaborao
de um diagrama de contexto do sistema; criao de
prottipos, anlise de viabilidade, priorizao dos
requisitos e a criao de um dicionrio de dados.
C) Documentar - Uma vez compreendidos,
analisados e aceitos, os requisitos devem ser
documentas com um nvel de detalhamento
adequado, produzindo a a especificao de
requisitos de softwares.
Pode ser utilizada a linguagem natural ou
diagramas, como os propostos pela UML.
D) Validar - Aps terem sido documentados,
necessrio que os requisitos seja cuidadosamente
validados, principalmente quanto a consistncia e a
completude. Esta atividade visa identificar

problemas nos requisitos, antes do inicio da

construo. A importncia dessa atividade
caracterizada pelo fato de que a correo de um
erro nesta fase, possui um custo muito inferior do
que a correo nas fases mais adiantadas do
processo de desenvolvimento.
Para o Gerente de projetos, responsvel por
atender as expectativas dos diferentes interessados
no sistema, recomenda-se como boas prticas, a
seleo de um modelo de ciclo de vida apropriado,
considerando que modelos incrementais e
iterativos como o Unified Process e Extreme
Programming
tem
apresentado
melhores
resultados, Elaborao de Planos de projetos
baseados nos requisitos de sistema, renegociao
de compromissos to logo se perceba que eles no
possam ser cumpridos, gerenciamento de rsicos
associados a requisitos e a criao de condies
para que os requisitos possam ser rastreados ao
longo
do
projeto.
Concluso
importante que gerentes de projeto reconheam
que no possvel desenvolver sistema de
qualidade, cumprir prazos e custos e atender s
expectativa dos usurios sem ter um processo de
desenvolvimento
de
requisitos
definido,
compreendido e utilizado por todos os
desenvolvedores.
Engenharia de requisitos
A engenharia de requisitos um processo que
engloba todas as atividades que contribuem para a
produo de um documento derequisitos e sua
manuteno ao longo do tempo.
O processo de engenharia de requisitos composto
por quatro atividades de alto nvel:
identificao;
anlise e negociao;
especificao e documentao;
validao.
Este processo deve ser precedido de estudos de
viabilidade que, a partir das restries do projeto,
determinam se este ou no vivel e se deve
prosseguir para a identificao dos requisitos. Uma
outra atividade que se pode considerar que faz
tambm parte deste processo, se incluirmos a fase
posterior produo do documento, agesto dos
8

requisitos (change management, sendo que as

alteraes podem ser causadas pelos mais diversos
fatores desde inovaes tecnolgicas a mudanas
na natureza do negcio, entre outras.

Estudos de viabilidade
Antes de se avanar com uma anlise mais
detalhada dos requisitos de um projeto, deve ser
feito um estudo de viabilidade.
Tal como o nome sugere, pretende-se com este
estudo avaliar sob o ponto de vista tecnolgico e
organizacional se o projeto vivel.
Uma forma de avaliar a viabilidade de um projeto
obter, atravs da interao com "as partes
interessadas" (ou stakeholder em ingls) do projeto
(em reunies ou entrevistas, por exemplo), a
resposta s seguintes questes:
Ser que o sistema contribui para os objetivos
da organizao?
Dadas
as
restries
tecnolgicas,
organizacionais
(econmicas,
polticas,
ambientais, recursos disponveis) e temporais
associadas ao projeto, ser que o sistema pode
ser implementado?
Caso haja necessidade de integrao entre
diferentes sistemas, ser que esta possvel?
A questo mais crtica a primeira, j que um
sistema que no contribua para os objetivos da
organizao no lhe traz qualquer valor
acrescentado e como tal a sua existncia no se
justifica. Apesar de parecer bvia, so
frequentemente desenvolvidos sistemas que no
contribuem para os objetivos das respectivas
organizaes, quer seja por interesses externos
(polticos ou organizacionais) ou por falta de clareza
na definio dos objetivos da organizao.
Deve portanto identificar-se que informao
necessria para responder a estas questes e quem
possui esta informao, procedendo-se de seguida
recolha de todos os dados disponveis para
clarificar ao mximo o mbito do projeto e avaliar a
sua viabilidade.
Tipicamente, quem poder fornecer esta
informao sero os usurios dos sistemas atuais e
do sistema a implementar, os responsveis pelos
departamentos nos quais o sistema ser usado,
tcnicos que estejam familiarizados com as
tecnologias envolvidas (do novo sistema e dos
sistemas existentes), responsveis pela manuteno

futura do sistema a implementar e, de um modo

geral, todos aqueles que tero qualquer tipo de
interao com o novo sistema (ou que sejam por
ele afetados).
Algumas das questes que podem ser postas nesta
coleta de informaes so, por exemplo:
Se o novo sistema no fosse implementado,
quais seriam as alternativas para a organizao?
Quais so os problemas que os sistemas atuais
apresentam e como que um sistema novo ir
resolver estas falhas?
De que forma que o sistema ir contribuir
diretamente para os objetivos da organizao?
possvel a integrao com os outros sistemas
da organizao (de um ponto de vista
tecnolgico)? Com que facilidade que se
consegue partilhar informao entre estes
sistemas?
O estudo de viabilidade dever culminar com a
produo de um relatrio e dever determinar a
continuao do desenvolvimento do projeto,
tornando mais claras as restries (econmicas,
temporais e organizacionais) do projeto e definindo
mesmo alguns requisitos de alto nvel.
Identificao
Caso se determine que o projeto vivel, o passo
seguinte a identificao dos requisitos.
Atividades envolvidas[
Algumas das atividades envolvidas nesta fase
incluem:
Compreenso do domnio: muito importante
para o analista compreender o domnio no qual
a organizao e o projeto se inserem; quanto
maior for o conhecimento acerca do domnio,
mais eficaz ser a comunicao entre o analista
e as partes interessadas.
Identificao das partes interessadas: estes j
devero ter sido identificados nos estudos de
viabilidade, porm para efeitos de identificao
de requisitos convm concentrar as atenes
nos usurios do sistema.
Captura: consiste na obteno com o cliente
dos requisitos (funcionais e no-funcionais)
pretendidos para o sistema.
Identificao e anlise de problemas: os
problemas devem ser identificados (e a sua
definio deve ser consensual) e devem ser
propostas solues em conjunto com as partes
interessadas.
9

Dificuldades
Esta fase no trivial, sendo que existem algumas
dificuldades tpicas que lhe esto associadas:
O cliente pode no saber exatamente o que
deseja para o sistema, ou sab-lo mas no
conseguir articul-lo (o que bastante comum).
Os requisitos identificados podem no ser
realistas (do ponto de vista econmico ou
tecnolgico, por exemplo).
Cada parte interessada pode expressar os
mesmos requisitos de formas diferentes, sendo
necessrio - atravs de um bom conhecimento
do domnio - identificar estas situaes.
Tcnicas para levantamento de requisitos
Existem diversas tcnicas de identificao de
requisitos, e que so adequadas a diferentes
situaes, entre as quais podemos citar:
Entrevistas e Questionrios
Entrevistas e Questionrios talvez a tcnica mais
simples de utilizar. Ainda que seja bastante eficaz
numa fase inicial de obteno de dados (e mesmo
de esclarecimento de algumas dvidas), est
condicionada a alguns fatores:
Influncia do entrevistador nas respostas do
cliente: convm que o entrevistador d margem
ao entrevistado para expor as suas ideias sem
as enviesar logo partida.
Relao pessoal entre os intervenientes na
entrevista.
Predisposio do entrevistado: caso, por
exemplo, o papel do entrevistado venha a ser
afetado pela introduo de um sistema na
organizao, este pode propositadamente
dificultar o acesso informao.
Capacidade de seguir um "plano" para a
entrevista: na ausncia destes planos natural
que haja tendncia para que os intervenientes
se dispersem um pouco, levando a que a
entrevista demore mais tempo do que seria
suposto. Caso a entrevista se torne demasiado
longa, as pessoas podem cair na tentao de
"querer despachar" sendo os ltimos pontos da
entrevista abordados de forma superficial (ou
podem nem chegar a ser abordados).

Workshops de requisitos
O Workshop de Requisitos consiste numa tcnica
usada atravs de uma reunio estruturada, da qual
devem fazer parte um grupo de analistas e um
grupo representando o cliente1 , para ento obter
um conjunto de requisitos bem definidos. Ao
contrrio das reunies, promove-se a interao
entre todos os elementos presentes no workshop
fomentando momentos de descontrao como
forma de dinamizar o trabalho em equipe, existindo
um facilitador neutro cujo papel conduzir o
workshop e promover a discusso entre os vrios
intervenientes (ainda que no tenha realmente
poder de deciso). As tomadas de deciso devem
seguir processos bem definidos e devem resultar de
um processo de negociao, mediado pelo
facilitador. Uma tcnica que tambm til em
workshops o uso de brainstorming (tempestade de
idias) como forma de gerar um elevado nmero de
ideias numa pequena quantidade de tempo. Como
resultado dos workshops deve ser produzida
documentao que reflita os requisitos e decises
tomadas sobre o sistema a implementar
Cenrios (Srie de Eventos Hipotticos)
Uma forma de levar as pessoas a imaginarem o
comportamento de um sistema o uso de
cenrios. Atravs de exemplos prticos
descritivos do comportamento de um sistema,
os seus usurios podem comentar acerca do
seu comportamento e da interao que
esperam ter com ele. Trata-se de uma
abordagem informal, prtica e aplicvel a
qualquer tipo de sistema. De um modo geral, os
cenrios devem incluir os seguintes elementos:
estado do sistema no incio do cenrio;
sequncia de eventos esperada (na ausncia de
erros) no cenrio;
listagem de erros que podem ocorrer no
decorrer dos eventos do cenrio e de como
estes erros sero tratados;
outras atividades que podem ser executadas ao
mesmo tempo que as deste cenrio;
estado do sistema depois de o cenrio terminar.
Prototipagem
O uso de prototipagem feito em diversas fases do
processo de engenharia de requisitos (por exemplo
na identificao, anlise e validao). Trata-se de
uma verso inicial do sistema, baseada em
requisitos ainda pouco definidos, mas que pode
10

ajudar a encontrar desde cedo falhas que atravs

da comunicao verbal no so to facilmente
identificveis. Neste tipo de abordagem apenas so
desenvolvidas algumas funcionalidades sendo
normalmente desenvolvidas primeiro aquelas que
so mais fceis de compreender por parte do
utilizador e que lhe podem trazer maior valor
acrescentado (principalmente na prototipagem
evolutiva, isto , aquela que mais tarde evoluda
para a fase de desenvolvimento). O uso de
prottipos deve ser considerado apenas mediante
uma anlise custo-benefcio, j que os custos de
desenvolvimento de um prottipo podem
facilmente crescer, sendo particularmente teis em
situaes em que a interface com os usurios ,
para eles, um aspecto crtico.
Estudo etnogrfico
Os Estudos Etnogrficos so uma anlise de
componente social das tarefas desempenhadas
numa dada organizao. Quando um dado conjunto
de tarefas se torna rotineiro para uma pessoa, de
se esperar que esta sinta dificuldade em articular
todos os passos que segue ou todas as pessoas com
as quais interage para as levar a cabo. Atravs de
uma observao direta das atividades realizadas
durante um perodo de trabalho de um funcionrio
possvel encontrar requisitos que no seriam
observveis usando tcnicas convencionais. Esta
observao pode ser acompanhada de registros
udio/vdeo, porm no convm us-los em
demasia visto que o tempo necessrio para os
processar pode ser demasiado. Nesta tcnica
assume-se que o representante do cliente
observado desempenha as suas funes
"corretamente", pelo que convm ter algum
cuidado na escolha do mesmo.
Anlise e negociao dos requisitos
Aps a identificao dos requisitos do sistema,
segue-se etapa de anlise dos requisitos e
negociao.
Atividades envolvidas
Algumas das atividades envolvidas na anlise de
requisitos incluem:
classificao: agrupamento de requisitos em
"mdulos" para facilitar a viso global do
funcionamento pretendido para o sistema;
resoluo de conflitos: dada a multiplicidade e
diversidade de papis das partes interessadas
envolvidas na captura e anlise de requisitos,

inevitvel a existncia de conflitos nos

requisitos identificados; importante resolver
estes conflitos o mais breve possvel;
priorizao: consiste na atribuio de uma
"prioridade" a cada requisito (por exemplo
elevada/mdia/baixa); obviamente, este pode
ser um fator gerador de conflitos;
confirmao: confirmada com as partes
interessadas a completude dos requisitos, sua
consistncia e validade (de acordo com o que se
pretende do sistema).
Estas fases no so independentes entre si, pois
uma informao obtida numa delas pode servir
para as demais fases.
A identificao e anlise de requisitos um
processo iterativo que se inicia com a familiarizao
do domnio do futuro sistema e termina na
confirmao dos requisitos, aumentando o grau de
compreendimento do sistema a cada ciclo de
trabalho.
Dificuldades
As dificuldades encontradas na anlise so de
diversas naturezas:
fatores externos (polticos) podem influenciar
os requisitos (alguma parte interessada, com
poder de deciso, pode exigir requisitos
especficos que sirvam aos seus interesses e no
aos da organizao, ou forar o seu ponto de
vista em detrimento dos demais interessados
que iro operar o sistema);
o ambiente (econmico e/ou organizacional)
em que a anlise feita possui fatores
dinmicos, e como tal, os requisitos esto
sujeitos a alteraes em decorrncia destes
(por exemplo: novas partes interessadas so
envolvidas no projeto, ou alteraes em prazos
e oramentos disponveis).
Negociaes
Na fase de negociao, tornam-se necessrios
alguns cuidados para que esta decorra sem
problemas, chegando-se logo a consensos. Algumas
sugestes so:
saber lidar com ataques pessoais (evitando-os
sempre que possvel, remetendo a sua
resoluo para mais tarde, fora de reunio), de
preferncia nunca tomando partidos;
fomentar a justificao das posies (negativas)
tomadas pelos intervenientes na negociao;
11

salientar (e procurar encontrar) os benefcios

que uma soluo apresenta para todos os
envolvidos;
relaxar restries, quando se torna bvio que as
atuais no levaro a um consenso.

Especificao e documentao
nesta fase que se d a produo propriamente
dita do Documento de Especificao de Requisitos.
Em todos os tipos de especificao h 2 tipos de
requisitos a considerar:
Requisitos
funcionais:
descrevem
as
funcionalidades que se espera que o sistema
disponibilize, de uma forma completa e
consistente. aquilo que o utilizador espera
que o sistema oferea, atendendo aos
propsitos para qual o sistema ser
desenvolvido.
Requisitos
no-funcionais: referem-se a
aspectos no-funcionais do sistema, como
restries nas quais o sistema deve operar ou
propriedades
emergentes
do
sistema.
Costumam ser divididos em Requisitos nofuncionais
de:
Utilidade,
Confiana,
Desempenho, Suporte e Escalabilidade.
Pode-se tambm considerar os requisitos do
domnio, que tal como o nome indica derivam do
domnio e no de necessidades especficas dos
usurios, podendo depois ser classificados como
funcionais ou no-funcionais.
A documentao produzida poder ter diferentes
destinatrios e como tal diferentes objetivos.
Podem-se distinguir trs tipos de especificao:
especificao de requisitos do usurio ou
utilizador;
especificao de requisitos do sistema;
especificao do design da aplicao.
A vantagem de conceber mais do que uma
especificao para um dado sistema a de em cada
especificao
se
comunicar
apenas
um
determinado tipo de informao adequado ao leitor
a que se destina (usando "linguagens" que o
utilizador conhea). Por exemplo, enquanto que
nos requisitos do utilizador apenas feita uma
abordagem de alto nvel das funcionalidades do
sistema e suas restries, usando linguagem natural
e eventualmente diagramas (esquemas), nos
requisitos do sistema cada requisito descrito com
mais detalhe introduzindo j alguns conceitos
relativos arquitetura do sistema, fazendo-se uso

de linguagens estruturadas (notaes grficos como

diagramas de casos de uso).
Requisitos do utilizador
Os requisitos do utilizador destinam-se portanto
aos vrios nveis hierrquicos da organizao na
qual o sistema ser implementado (desde gestores
a usurios), pelo que so descritos usando apenas
(conforme j foi referido) linguagem natural,
formulrios
e
diagramas
muito
simples.
Obviamente, neste nvel de especificao surgem
algumas dificuldades:
Ambiguidade: torna-se difcil descrever os
requisitos de uma forma inequvoca sem tornar
a sua descrio muito longa ou de difcil
compreenso.
Confuso: ainda que possa no ser to
relevante do ponto de vista do cliente, a
distino entre requisitos funcionais/nofuncionais e objetivos do sistema torna-se
difcil.
Agrupamento de requisitos: ao descrever as
funcionalidades de um sistema, pode tornar-se
difcil separar claramente os requisitos, o que
leva a que vrios requisitos sejam expressos
como sendo apenas um.
Algumas consideraes teis a ter em conta ao
escrever uma especificao de requisitos do
utilizador:
Usar o mesmo formato em todos os requisitos
(evitam-se omisses e facilita-se a verificao
dos requisitos).
Distinguir
claramente
entre
comportamentos esperados e desejveis do
sistema atravs do uso de expresses como "O
sistema permitir criar (...)" ou "Dever ser
possvel criar (...)" respectivamente.
importante deixar claro o que o sistema tem de
fazer e sugestes de como o deve fazer e, acima
de tudo, usar este tipo de expresses de forma
consistente ao longo de todo o documento.
Usar formatao de texto para salientar
determinados aspectos do documento (usando
negrito, por exemplo).
Evitar usar termos demasiado tcnicos ou fora
do mbito do sistema, identificando-os e
definindo-os de uma forma clara quando for
absolutamente necessrio us-los.

12

Requisitos do sistema
Os requisitos do sistema tm um carcter mais
tcnico, consistindo numa descrio detalhada dos
requisitos
do
utilizador
correspondentes
recorrendo ao uso, para alm da linguagem natural,
de linguagens estruturadas e notaes grficas.
Estes requisitos destinam-se ainda aos usurios do
sistema (e particularmente aos engenheiros que
trabalhem nessa organizao) e destinam-se
tambm s equipes de especificao de arquitetura
do sistema e de desenvolvimento. Tal como nos
requisitos do utilizador, o uso de linguagem natural
levanta problemas, embora alguns deles sejam
ligeiramente diferentes:
As mesmas palavras podem, de acordo com a
interpretao de cada pessoa, designar
conceitos diferentes.
O mesmo requisito pode ser descrito de formas
diferentes, o que leva a que cada pessoa tenha
de saber quando que descries diferentes se
referem ou no a requisitos diferentes.
Design da aplicao
Por fim, a especificao do design da
aplicao consiste num documento usado pela
equipe de desenvolvimento do sistema no qual
esto definidos pormenores, em um nvel mais
tcnico, acerca da implementao do sistema e sua
arquitetura. A partir deste documento, um
elemento que entre para a equipe de
desenvolvimento no meio do projeto dever ser
capaz de "se situar" quando precisar de comear a
codificar, compreendendo a forma como a
implementao, em um nvel global, est a ser feita,
mas sem conhecer necessariamente os detalhes de
implementao aprofundados. No convm cair na
tentao de deixar toda a implementao
detalhada, uma vez que convm que os
desenvolvedores tenham alguma margem de
manobra tanto para inovar como para resolver
problemas encontrados em sub-sistemas de formas
que uma especificao inicial da arquitetura no
consegue prever.
Documento de Especificao de Requisitos
Apesar da existncia dos 3 tipos de especificao
vistos nos itens anteriores, existe uma especificao
que a usada como declarao oficial dos
requisitos do sistema.

Este
documento,
normalmente
chamado
de Documento
de
Especificao
de
Requisitos (Software Requirements Specification ou
SRS) inclui uma combinao dos requisitos do
utilizador e do sistema e tem diferentes utilidades
para diferentes pessoas2 :
Clientes: confirmar a completude dos requisitos
e propor alteraes.
Gestores: oramentar o sistema e planejar o
processo de desenvolvimento.
Engenheiros: compreender o sistema a
desenvolver.
Engenheiros (testes): desenvolver testes para
validar o cumprimento dos requisitos.
Engenheiros (manuteno): compreender o
sistema e a ligao entre as suas partes.
Existem diversos padres para este documento,
embora no se possa apontar nenhum como o
"ideal". Uma estrutura proposta pelo IEEE que
talvez a mais usada o IEEE/ANSI 830-19933 .
Validao[
Nesta fase pretende-se demonstrar que o
documento de requisitos produzido corresponde,
de fato, ao sistema que o cliente pretende.
semelhana do que sucede na anlise dos
requisitos,
pretende-se
encontrar
problemas/conflitos na especificao, porm ao
contrrio das fases anteriores esta fase lida com
uma especificao completa dos requisitos.
A validao especialmente importante em
sistemas de grandes dimenses uma vez que erros
encontrados demasiado tarde (durante o
desenvolvimento ou j depois de o sistema estar a
ser usado) no documento de requisitos tm
repercusses proporcionais dimenso do projeto.
Uma vez que alteraes em requisitos j
consolidados tm um custo muito superior a
alteraes no cdigo ou design, este tipo de erro
traduz-se em elevados custos e necessidade de
refazer muito do trabalho que se julgava j
concludo.
Durante a fase de validao dos requisitos, devem
ser verificados (atravs de checklists) os seguintes
atributos dos requisitos:
Validade: a especificao resulta da anlise dos
requisitos identificados junto das diversas
partes interessadas envolvidas. Como tal,
requisitos identificados individualmente (isto ,
junto de cada parte interessada) podem diferir
13

da especificao final que se atinge aps o

cruzamento de informao e necessrio que
cada cliente compreenda e aceite a
especificao final obtida.
Consistncia: no devem existir conflitos entre
os requisitos identificados.
Compreensibilidade
/
Ambiguidade:
os
requisitos devem poder ser compreendidos de
forma inequvoca pelas partes interessadas.
Completude:
todas
as
funcionalidades
pretendidas devem fazer parte da especificao
do sistema.
Realismo: dadas as restries do projeto
(tecnolgicas, financeiras e temporais) o
sistema especificado tem de ser implementvel.
Verificabilidade: de forma a evitar futuras
discordncias quanto concretizao dos
requisitos especificados, estes devem ser
descritos de modo a que seja possvel verificar
se foram ou no concretizados, isto , se o
sistema final corresponde especificao
inicial.
Rastreabilidade: a origem dos requisitos, em
relao ao cliente, deve estar claramente
identificada. Entre outros motivos, isto
importante para facilitar a gesto futura dos
requisitos.
Conformidade com normas: para alm dos
aspectos funcionais dos requisitos, a sua
especificao deve obedecer s normas usadas
ao longo de todo o documento.
Tcnicas de validao
Para tornar a validao mais eficaz, existe um
conjunto de tcnicas que podem ser empregadas:
Revises dos requisitos (Verificao de Validade)[
Uma equipe de revisores pode analisar
sistematicamente a especificao produzida de
forma a garantir que esta corresponde ao sistema
pretendido; em revises informais, a equipe de
revisores pode simplesmente ter uma conversa,
envolvendo o maior nmero possvel de
representantes das partes interessadas, acerca dos
requisitos produzidos; em revises formais, a
equipe de revisores deve confirmar junto do cliente
um conjunto de critrios que todos os requisitos
devem cumprir, nomeadamente: verificabilidade,
compreensibilidade (por parte dos usurios finais),
rastreabilidade (a origem dos requisitos deve ser
identificvel) e adaptabilidade (capacidade de

sofrer alteraes sem produzir efeitos em todos os

outros requisitos).
Prototipificao
(Ou prototipao) A implementao de um
prottipo (por exemplo, da interface do sistema)
pode ser til para os usurios finais (e demais
interessados), j que se trata do elemento do
sistema final com o qual tero mais contacto
quando o sistema estiver operacional; esta tcnica
tambm eficaz, embora tenha desvantagens: o
tempo gasto na sua implementao pode no
justificar o seu uso, pode enviesar os usurios
(levando a desiluses com a verso final do sistema,
no caso de esta ser muito diferente do prottipo) e
pode ainda levar os programadores a cair na
tentao de usar o prottipo para continuar o
desenvolvimento do sistema (pelo que, idealmente,
o prottipo deva ser implementado noutra
linguagem que no aquela usada pelo sistema,
eliminando por completo esta tentao).
Gerao de casos de teste
Uma vez que cada requisito deve ser testvel,
deveria ser possvel criar (desenhar) os respectivos
testes desde a fase de validao de requisitos; se
isto no for possvel, sinnimo de que a
implementao deste requisito ser difcil e que
este poder ter de ser reconsiderado.
Anlise de consistncia automtica
Atravs da especificao formal de modelos para o
sistema possvel, recorrendo a ferramentas
adequadas (como as ferramentas CASE), testar de
forma automtica a consistncia dos modelos
criados; apenas a consistncia testada nesta
tcnica, pelo que tem de ser complementada com
uma das outras tcnicas referidas.
Recomendaes
A fase de validao no deve ser encarada de
nimo leve: trata-se de uma fase muito importante
na engenharia de requisitos e da qual dependem
elevados custos a mdio e longo prazo.
Por depender bastante dos retornos transmitidos
pelos clientes (que no so peritos em validao de
requisitos) bastante falvel e regra geral h erros
que no so encontrados num primeiro momento,
o que leva inevitavelmente a discordncias numa
fase posterior, j com o documento validado e o
14

projeto em desenvolvimento ou concludo. Quando

isto sucede, torna-se necessrio negociar e chegar a
um acordo quanto forma de corrigir o erro
detectado.
Gesto de requisitos
Os requisitos de um sistema, em especial em
sistemas minimamente grandes, esto em evoluo
constante.
De um modo geral, isto pode suceder em razo do
problema
abordado
no
conseguir
ficar
completamente definido antes da produo do
documento de requisitos (ou mesmo antes de o
sistema ser implementado) ou, por outro lado,
pode tambm acontecer por os prprios requisitos
se alterarem no decorrer do projeto (reflectindo
evolues tecnolgicas ou alteraes na
organizao na qual usado).
natural que surjam requisitos por parte dos
usurios por diversos motivos:
Conforme j foi referido, a resoluo de
conflitos entre requisitos resulta num
compromisso que procura equilibrar as
necessidades
das
diferentes
partes
interessadas. Este equilbrio pode ter de ser
modificado e s com o uso do sistema que
possvel avali-lo convenientemente. Para alm
de conflitos entre requisitos de diferentes
usurios do sistema, h ainda a considerar os
conflitos entre usurios e "elementos
executivos" da organizao, isto , aqueles que
tm o poder de deciso e que podem impr
requisitos perante os analistas (que podem no
contribuir para os objetivos da organizao).
A orientao do negcio da organizao podese alterar, nova legislao ou regulamentao
pode pr em causa alguns dos requisitos do
sistema, alteraes a nvel tecnolgico podem
surgir
na
organizao
(afetando
particularmente, no caso de alteraes
de hardware, os requisitos no-funcionais),
podem surgir novos sistemas que precisem de
suporte, a nvel de interao, por parte do
sistema implementado, e toda uma srie de
alteraes imprevisveis pode surgir levando a
que o sistema tenha de se adaptar a todo este
tipo de requisitos.
Existem requisitos que, tipicamente, so mais
volteis do que outros (como por exemplo
requisitos que dependam da entidade poltica
governante num dado momento), enquanto que

outros so relativamente estveis (os que se

referem natureza do negcio (domnio)
propriamente dita).
Na prtica, a gesto de requisitos acaba por
coincidir com o incio de novos processos de
engenharia de requisitos (para os "novos"
requisitos, isto , os "antigos" que sofreram
alteraes). Como tal, o planejamento uma parte
importante da gesto de requisitos. Devem estar
definidas desde o incio da gesto de requisitos
polticas para:
Identificao
de requisitos: identificao
unvoca em especial para facilitar a
rastreabilidade.
Processo de gesto de mudanas a utilizar:
conjunto de atividades que permitem avaliar o
custo e impacto das alteraes.
Rastreabilidade: relaes entre os requisitos e
relaes entre requisitos e design; estas podem
precisar de manter associada a cada requisito
informao como a parte interessada que a
props, dependncias de outros requisitos e
associao a mdulos especficos do design do
sistema.
Ferramentas a utilizar: para sistemas grandes, a
quantidade de informao a processar pode ser
elevada, sendo o uso de ferramentas
CASE aconselhado.
Para manter a consistncia entre as vrias
alteraes pedidas (e para estas serem feitas de um
modo controlado), importante que o processo de
gesto de mudanas esteja definido de um modo
formal, sendo que dever incluir as seguintes trs
fases:
Anlise do problema e especificao da
alterao a fazer: identificao do problema
existente nos requisitos originais e proposta de
alterao a fazer aos requisitos do sistema.
Anlise da alterao e seu impacto: atravs das
polticas
de
rastreabilidade
definidas
previamente, avaliao do impacto da alterao
no sistema.
Implementao da alterao: alterao no
documento de requisitos e, conforme seja
necessrio, no design e implementao.
importante seguir este processo conforme foi
enunciado j que cair na tentao de implementar a
alterao
diretamente
e
s
depois,
retrospectivamente, atualizar os requisitos pode
15

levar a dessincronizao
implementao.

entre

requisitos

Mtricas e Estimativas de Software - O incio de

um rally de regularidade
Imagine que voc faa parte de uma equipe de
Rally, e que voc e sua equipe tenham que
atravessar um deserto enorme e cheio de
obstculos e que 50% dos fatores crticos de
sucesso dependam do seu navegador para estimar
o tempo do percurso e a distncia. Agora imaginese diante de um projeto de Sistemas de Informao
onde 50% dos fatores crticos de sucesso esto nos
prazos e custos. Certamente voc ter que fazer
uma eficiente mtrica e estimativa de software.
As mtricas e estimativas de software vem se
tornando um dos principais tpicos na Engenharia
da Informao com a crescente exigncia de seus
consumidores pela qualidade, rapidez, comodidade
e baixo custo de implantao e manuteno,
impossvel no enxergar tais tcnicas como
alavanca para um produto de melhor qualidade,
com custos adequados. Mas existem ainda muitas
barreiras que impedem os profissionais da rea de
utilizarem tais tcnicas ou de o fazerem de maneira
errnea, embora a literatura disponvel atualmente
sobre engenharia da informao seja relativamente
ampla e variada, o que nos leva a questionar: Por
que as mtricas e estimativas de software
propostas para o desenvolvimento de sistemas no
so fiis realidade e dimenso do problema?
Tais tcnicas acompanharam a rpida evoluo do
setor?
Tais questes nos levam a crer que algumas
mtricas e estimativas de software ficaram
obsoletas e outras ganharam vigor nas pocas
atuais, quando a busca da qualidade de software
vem crescendo com grande rapidez.
Acredito que o ato de medir e estimar a parte
mais importante de um projeto de sistema bemsucedido e alguns fatos como: a falta de
maturidade, o desinteresse das empresas de
desenvolvimento de sistemas e a baixa
popularidade deste assunto entre os profissionais
da rea de informtica so algumas da principais
causas para o insucesso e o alto custo dos sistemas
de informao.
O termo mtrica de software refere-se
mensurao dos indicadores quantitativos do

tamanho e complexidade de um sistema. Estes

indicadores so, por sua vez, utilizados para
correlatar contra os desempenhos observados no
passado afim de derivar previses de desempenho
futuro.
A mtrica de software tem como princpios
especificar as funes de coleta de dados de
avaliao
e
desempenho,
atribuir
essas
responsabilidades a toda a equipe envolvida no
projeto, reunir dados de desempenho pertencentes
complementao do software, analisar os
histricos dos projetos anteriores para determinar
o efeito desses fatores e utilizar esses efeitos para
pesar as previses futuras. Estes princpios nos
permite prever o resto do processo, avaliar o
progresso e reduzir a complexidade, como numa
prova de rally, onde a cada corrida ficamos mais
esclarecidos da condies e limites da equipe.
As Mtricas Orientadas ao Tamanho
Mtricas de software orientadas ao tamanho so
medidas diretas do software e do processo por
meio do qual ele desenvolvido. Se uma
organizao de software mantiver registros simples,
uma tabela de dados orientada ao tamanho poder
ser criada. A tabela relaciona cada projeto de
desenvolvimento de software que foi includo no
decorrer dos ltimos anos aos correspondentes
dados orientados ao tamanho deste projeto. A
partir dos dados brutos contidos na tabela, um
conjunto de mtricas de qualidade e de
produtividade orientadas ao tamanho pode ser
desenvolvido para cada projeto. Mdias podem ser
computadas levando-se em considerao todos os
projetos.
As mtricas orientadas ao tamanho provocam
controvrsias e no so universalmente aceitas
como a melhor maneira de se medir o processo de
desenvolvimento de software. A maior parte da
controvrsia gira em torno do uso das linhas de
cdigo (LOC) como uma medida-chave. Os
proponentes da afeio de linhas de cdigo
afirmam que as mesmas so o "artefato" de todos
os projetos de desenvolvimento de software que
podem ser facilmente contados, que muitos
modelos existentes usam LOC ou KLOC (milhares de
linhas de cdigo) como entrada-chave e que j
existe um grande volume de literatura e de dados
baseados nas linhas de cdigo. Por outro lado, os
opositores afirmam que as medidas LOC so
16

dependentes da linguagem de programao

utilizada na codificao do projeto, que elas
penalizam programas bem projetados, porm mais
curtos, que elas no podem acomodar facilmente
linguagens no-procedurais e que seu uso em
estimativas requer um nvel de detalhes que pode
ser difcil de conseguir (isto , o planejador deve
estimar as linhas de cdigo a ser produzidas muito
antes que a anlise e o projeto tenham sido
construdos).
Essa forma de medida foi uma herana do modelo
de manufatura em que os CIO'S podiam determinar
os recursos necessrios para uma "corrida",
contando o nmero de produtos manufaturados
necessrios. Essa mtrica no leva em considerao
o fato de que o desenvolvimento envolve um custo
relativo ao ambiente ou linguagem de programao
utilizada. Por exemplo, em orientao a objeto
(OO), a flexibilidade da ferramenta no uso de
mecanismos de herana dilui o resultado final da
contagem de linhas.
A contagem de linhas de cdigo pode ser uma
medida do que foi feito, e no uma medida a ser
utilizada para previso.
Mtricas Orientadas Funo
Consiste em um mtodo para medio de software
do ponto de vista do usurio, que determina de
forma consistente o tamanho e complexidade de
um software, sob a perspectiva do usurio. Ele
dimensiona um software, quantificando a
funcionalidade proporcionada ao usurio a partir do
seu desenho lgico. Ou seja, so medidas indiretas
do software e do processo por meio do qual ele
desenvolvido. Em vez de contar linhas de cdigo, a
mtrica orientada funo concentra-se na
funcionalidade ou utilidade do programa. Uma
abordagem foi sugerida baseada nesta proposta
chamada de pontos-por-funo (function point). Os
pontos-por-funo (FPs) so derivados usando-se
uma relao emprica baseada em medidas de
informaes e complexidade do software.
Um dos princpios da anlise de pontos-por-funo
focaliza-se na perspectiva de como os usurios
"enxergam" os resultados que um sistema produz.
A anlise considera as vrias formas com que os
usurios interagem com o sistema, com os
seguintes objetivos:
1. Fornecer medidas consistentes;

2. Medir funcionalidades que o usurio solicita ou

recebe;
3. Independncia da tecnologia;
4. Mtodo simples.
As mtricas orientadas funo apresentam vrios
benefcios, dentre eles podemos citar o seguintes:
1. Uma ferramenta para dimensionar aplicaes;
2. Um veculo para quantificar custo, esforo e
tempo;
3. Um veculo para calcular ndices de produtividade
e qualidade;
4. Um fator de normalizao para comparar
software.
Tal mtrica parece ser til e funcional para o
desenvolvimento tradicional, mas apresenta
algumas falhas com o modelo de desenvolvimento
em orientao a objeto (OO), pois alguns atributos
do design em OO invalidam o clculo de alguns
pontos-por-funo. As caractersticas fundamentais
de OO tm efeito de reduzir a validade da
contagem de funes para a avaliao de esforo e
recursos necessrios para a execuo de um
projeto.
A mtrica de pontos por funo foi originalmente
projetada para sistemas de informao comerciais.
Para acomodar estas aplicaes, a dimenso dos
dados foi enfatizada para a excluso de dimenses
funcionais e de controle. Por esta razo, a medida
de pontos por funo era adequada para muitos
sistemas de engenharia. Um nmero de extenses
para a medida bsica de pontos por funo tem
sido propostas para remediar esta situao.
Uma extenso de pontos por funo chamada
"feature points" (ou, pontos caractersticos) uma
evoluo da medida de pontos por funo que pode
ser aplicada a sistemas e aplicaes de engenharia
de software. A medida "feature points" acomoda
aplicaes em que a complexidade algortmica
alta. Sistemas real-time de controle de processos e
outros apresentam alta complexidade algortmica, e
so receptivos a mtrica de "feature points".
Para computar o "feature point", valores do
domnio so contados e ponderados. A mtrica
"feature point" conta uma nova caracterstica de
software, os algoritmos. Um algoritmo definido
como "um problema computacional que includo
com um programa de computador especfico".
Inverte uma matriz, decodificar um bit de string ou
manusear uma interrupo so exemplos de
algoritmos.
17

Outra extenso de pontos por funo para sistemas

real-time e produtos de engenharia tem sido
desenvolvido por Boeing. A aproximao de Boeing
integra a dimenso dos dados de software com
dimenses funcionais e de controle para obter uma
medida orientada funo, chamada pontos por
funo 3D, que receptiva a aplicaes que
enfatizem capacidades de funo e controle.
Caractersticas de todas as trs dimenses do
"contadas, quantificadas e transformadas" em uma
medida que fornece uma indicao da
funcionalidade fornecida pelo software.
Contagem de dados retidos (a estrutura de dados
interna do programa, isto , arquivos) e dados
externos (entradas, sadas e referncias externas)
so usados com medidas de complexidade para
derivar uma contagem da dimenso de dados.
A dimenso funcional medida considerando "o
nmero de informaes internas requeridas para
transformar entradas em dados de sada". Para os
propsitos da computao de pontos por funo
3D, uma transformao vista como uma srie de
passos de processamento que so limitados por
regras semnticas estabelecidas. Como uma regra
geral, a transformao concluda com um
algoritmo que resulta em uma mudana
fundamental para dados de entrada como so
processados para se transformarem em dados de
sada. Passos de processamento que adquirem
dados de um arquivo e simplesmente os coloca na
memria do programa no poderia ser considerado
uma transformao. O dado no sofreu nenhuma
mudana.
O nvel de complexidade associado a cada
transformao uma funo do nmero de passos
de processamento e o nmero de regras
semnticas que controla os passos de
processamento.
A dimenso de controle medida pela contagem do
nmero de transies entre os estados. Um estado
representa algum modo internamente observvel
de comportamento e uma transio ocorre como
resultado de algum evento que fora o software ou
sistema a mudar seu comportamento, isto , mudar
seu estado.
Quando pontos por funo 3D so computados,
transies no so associadas a valores de
complexidade.
Nota-se que pontos por funo, "feature points" e
pontos por funo 3D representam a mesma coisa

"funcionalidade" ou "utilidade" fornecida pelo

software. De fato, cada uma destas medidas resulta
no mesmo valor se somente a dimenso de dados
de uma aplicao considerada.
Para sistemas real-time mais complexos, a
contagem "feature points" de 20 a 35% mais alta
que a contagem determinada usando somente
pontos por funo.
Pontos por funo (e suas extenses), como a
medida LOC, controversa. Os proponentes acham
que FP independente da linguagem de
programao, tornando-se ideal para aplicaes
usando
linguagens
convencionais
e
no
procedurais, e que ela baseada em dados que so
conhecidos muito cedo na evoluo do projeto,
fazendo a FP mais atrativa como uma estimativa
mais prxima.
Oponentes acham que o mtodo requer alguma
prestidigitao em que a computao baseada em
dados subjetivos, que a contagem das informaes
de domnio (e outras dimenses) podem ser difceis
de coletar aps terminado o projeto, e que FP no
tem significado fsico direto. s um nmero.
Mtricas Voltadas para Orientao a Objeto
Muitas mtricas j foram desenvolvidas para
geraes passadas de tecnologia e, em muitos
casos, so usadas at para desenvolvimento OO,
porm no so muito coerentes, pois a diferena
entre sistemas tradicionais e sistemas OO so muito
grandes.
Existem vrias propostas para mtricas OO que
levam em considerao as caractersticas bsicas e
interaes do sistema como: nmero de classes,
nmero de cases, nmero de mtodos, mdias de
mtodos, mdias de mtodos por classe, linhas de
cdigo por mtodo, profundidade mxima da
hierarquia de classes, a relao existente entre
mtodos pblicos e privados, entre outros.
Tais mtricas baseiam-se na anlise detalhada do
design do sistema. Como na tcnica de pontos-porfuno, faz sentido adicionar um peso s mtricas
das classes para produzir uma medida de
complexidade do sistema. A maioria das medidas
examina atributos em termos dos conceitos de OO,
como herana, polimorfismo e encapsulamento.
Para tanto, seria necessrio coletar um nmero
significativo de contagens, ou seja, seria necessrio
tomar valores de vrios projetos e dimencion-los
selecionando as classes, os mtodos e os atributos
18

desejveis para medir o tamanho e a complexidade

de um novo software , o que nos tomaria um longo
tempo.

Estimativa de Tempo
Aps desenvolver uma estimativa do volume de
trabalho a ser feito, voc pode pensar que fcil
estimar a extenso do tempo que o projeto exigir.
Afinal, se voc tem um projeto estimado em dez
pessoas-ms e h cinco pessoas disponveis ele
deve levar dois meses para ser concludo. Mas, e se
somente duas pessoas estiverem disponveis? O
projeto leva cinco meses para ficar pronto? De um
modo geral, a nossa preocupao aqui com a
relao tempo/pessoal. Muitos anos de dolorosa
experincia ensinaram-nos que tal relao no
simples. Duplicar o nmero de pessoas em um
projeto no reduz necessariamente a durao do
projeto pela metade (muito pelo contrrio, se
colocarmos mais pessoas num projeto em
andamento isso apenas retardar ainda mais o
processo, uma vez que estas pessoas devero
receber treinamento adequado e "aprender" todo o
projeto desde seu incio at a fase atual, e isso
consome muito tempo).
A estimativa do esforo a tcnica mais comum
para se levantar os custos de qualquer projeto de
desenvolvimento de engenharia. Um nmero de
pessoas-dia, pessoas-ms ou pessoas-ano
aplicado soluo de cada tarefa do projeto. Um
custo em dlares associado a cada unidade de
esforo e um custo estimado ser derivado. Como a
tcnica LOC (linhas de cdigo) ou FP (pontos-porfuno), a estimativa de esforo inicia-se com um
delineamento das funes do software obtidas a
partir do escopo do projeto. Uma srie de tarefas
de engenharia de software - anlise de requisitos,
projeto, codificao e teste - deve ser executada
para cada funo.
O planejador estima o esforo (por exemplo,
pessoas-ms) que seria exigido para se concluir
cada tarefa de engenharia de software para cada
funo de software. Taxas de mo-de-obra (isto ,
custo/esforo unitrio) so aplicados em cada uma
das tarefas de engenharia de software. Muito
provavelmente, a taxa de mo-de-obra ir variar
para cada tarefa. O pessoal de nvel snior
envolver-se- fortemente na anlise de requisitos e

nas primeiras tarefas de realizao de projeto; o

pessoal de nvel jnior (que inerentemente menos
dispendioso) envolver-se- nas ltimas tarefas de
projeto, codificao e nos primeiros teste.
O custo e o esforo de cada funo e tarefa de
engenharia de software so computados como o
ltimo passo. Se a estimativa do esforo for
realizada independentemente da estimativa LOC ou
FP, teremos ento duas estimativas para o custo e
para o esforo que podem ser comparadas e
reconciliadas. Se os dois conjuntos de estimativas
demonstrarem razovel concordncia, haver uma
boa razo para acreditar que as estimativas so
confiveis. Se, por outro lado, os resultados dessas
tcnicas de decomposio exibirem pouca
concordncia, ser necessrio levar a efeito a
investigao e anlise adicionais.
Estimativa de Custo
O objetivo desta anlise calcular de maneira
antecipada todo e qualquer custo que esteja
associado ao sistema, tais como: construo,
instalao, operao e manuteno.
O custo da construo um tpico importante,
visto que graas a ele que sabemos o total de
todas as pessoas envolvidas no desenvolvimento do
sistema, tais como: burocratas, diretores, membros
da
comunidade
usuria,
consultores
e
programadores, membros da auditoria, do controle
de qualidade ou da equipe de operaes.
O custo de instalao do sistema um projeto
simples que podemos entregar em disquetes ou CDROMs e a instalao fica por conta do prprio
usurio. Porm, em caso de sistemas grandes, o
processo de instalao mais complexo e envolve
outros fatores, tais como: custo de treinamento do
usurio, custo de converso de banco de dados,
custo de instalao do fornecedor, custo da
aprovao legal, custo do processamento paralelo,
custo da equipe de desenvolvimento durante a
instalao. Naturalmente, toda a comunidade de
usurios precisar de treinamento para maior
familiarizao com o sistema. Este tipo de capital
pode ser obtido atravs de emprstimo ou de
reservas prprias. Dependendo da organizao
temos que express-lo como sendo custo do
emprstimo feito ou em termos de juros que o
dinheiro poderia estar rendendo se tivesse sido
investido em lugar de ser utilizado no projeto. Esta
19

rea deve estar sempre em sintonia com o

departamento de contabilidade.
O custo operacional entra em ao aps a
instalao do sistema. Haver um custo para o
usurio manter sua operao. Contudo, isso
tambm deve representar uma rea em que seu
novo sistema economizar dinheiro, pois ele
presumivelmente ser mais barato que o atual
sistema. Os custos operacionais mais comuns so:
custos de hardware e de suprimentos, custos de
software, custo de pessoal, custo de manuteno e
custo de recursos.
O custo de falhas, ou manuteno, como podemos
imaginar, diz respeito s diversas formas de erros
que podem tornar o sistema completamente
indisponvel at que este erro seja corrigido,
enquanto que em outros casos o sistema continua
funcionando, porm uma ou mais de suas sadas
podem estar incorretas. Este custo importante
pelo simples fato de no termos sistemas perfeitos.
Devemos checar sempre as estatsticas disponveis
acerca da confiabilidade do software.
O Fator Humano
Quando os objetivos para o desenvolvimento de
sistemas no so claros, as pessoas passam a
deduzir e criar o produto dentro de suas prprias
vises, levando a sistemas inadequados para a
funo do negcio a ser atendida e,
consequentemente, a mtricas falhas, gerando uma
expectativa divergente entre o cliente e os tcnicos
ressonveis, isto , uma estimativa irreal.
As pessoas so sensveis aos estmulos externos e
por meio de tais estmulos so influenciadas suas
atitudes e pensamentos. Um analista, ou um grupo
de analistas, disposto a estimar o tempo e custo de
um projeto no poderia deixar de dar a devida
relevncia a este fato. Um grupo de pessoas
motivado, trabalhando em um ambiente agradvel,
sem sofrer qualquer tipo de presso por parte da
empresa ou organizao produziria muito mais do
que um grupo de pessoas sujeitas a condies
adversas a estas. Mas no apenas o ambiente de
trabalho, so as relaes familiares e pessoais, os
estudos e uma outra srie de fatores que podem
ser aqui classificados como estmulos externos.
Para tentar amenizar a dificuldade e se estabelecer
critrio para a estimativa em relao a pessoal
(fator humano) surge o conceito de "Engenharia
Humana", que consiste em aplicar conceitos de

psicologia para se projetar uma interao homemcomputador de alta qualidade. Do ponto de vista do
especialista em engenharia humana, o homem e a
mquina so partes integrantes de todo um sistema
homem-mquina. Ele v o homem como um elo de
coleta e processamento de dados.
Mesmo com tcnicas como esta, o fator humano
continuar sendo uma incgnita praticamente
indecifrvel na prtica da estimativa de software.
Concluso
Em um processo de desenvolvimento de software
preciso medir custo, produtividade e qualidade no
s do produto final, mas tambm de todo o
processo.
Com a implantao de um sistema de coleta de
mtricas, os desenvolvedores podero avaliar
melhor a sua produtividade e adaptabilidade ao
processo de desenvolvimento e, com isso, estimar
melhor o tempo necessrio para executar cada
tarefa.
A princpio, necessrio determinar o que se quer
medir, afim de se definir como os dados sero
coletados. Essas decises devem ser compatveis
com o processo de desenvolvimento. Uma
metodologia de mtrica e estimativa no vai
solucionar de imediato os problemas de um
processo de desenvolvimento, no entanto esta
deve ser utilizada para tornar possvel o
entendimento do processo, para facilitar a previso
de suas fases e mostrar como control-las.
As estimativas jamais podero ser precisas e exatas,
pois no so apenas fatores tcnicos e "contveis",
palpveis que fazem parte de um projeto, mas
tambm existem pessoas, sentimentos, polticas,
crenas, ambiente e outros mais que no se podem
medir, so absolutamente variveis. Afinal, no
seria possvel estabelecer um padro, ou ainda,
transformar em nmeros os sentimentos de uma
pessoa, ou provar a ela que, matematicamente,
suas supersties no so vlidas.
Estimar necessrio sim, mas com forte
embasamento terico e prtico, mas estimar no
adivinhar.
Anlise de pontos de funo
Anlise de Pontos de Funo (APF) uma tcnica
para
a
medio
de
projetos
de desenvolvimento de software,
visando
estabelecer uma medida de tamanho, em Pontos
20

de Funo (PF), considerando a funcionalidade

implementada, sob o ponto de vista do usurio. A
medida independente da linguagem de
programao ou da tecnologia que ser usada para
implementao.
Sob esse contexto, os objetivos da APF so:
medir a funcionalidade solicitada pelo usurio,
antes do projeto de software, de forma a
estimar seu tamanho e seu custo;
medir
projetos de desenvolvimento e
manuteno de software, independentemente
da tecnologia utilizada na implementao, de
forma a acompanhar sua evoluo;
medir a funcionalidade recebida pelo usurio,
aps o projeto de software, de forma a verificar
seu tamanho e custo, comparando-os com o
que foi originalmente estimado;
As organizaes podem aplicar a Anlise de Pontos
por Funo como:
uma ferramenta para determinar o tamanho de
pacotes de software adquiridos, atravs da
contagem de todos os Pontos por Funo
includos no pacote;
uma ferramenta para apoiar a anlise da
qualidade e da produtividade;
um mecanismo para estimar custos e recursos
envolvidos em projetos de desenvolvimento e
manuteno de software;
um fator de normalizao para comparao de
software.
Ligaes
A Anlise de Pontos de Funo (APF) uma medida
de tamanho de claro significado ao nvel de
negcio. A APF foi elaborada por Allan Albrecht da
IBM e trazida a pblico em 1979 atravs da
publicao do trabalho Measuring Application
Development
Productivity
(Medindo
a
Produtividade no Desenvolvimento de Aplicativos).
A APF quantifica as funes contidas no software
em termos significativos para os respectivos
usurios. A medida relaciona-se diretamente aos
requisitos do negcio que o software pretende
tratar. Dessa forma, a APF imediatamente
aplicvel a um amplo espectro de ambientes e ao
longo da vida de um projeto de desenvolvimento,
desde a definio inicial dos requisitos at a fase de
plena utilizao operacional. Tambm podem ser
derivadas outras medidas teis ao negcio, tais
como a produtividade do processo de

desenvolvimento e o custo unitrio de suporte ao

software.
A prpria medida em pontos de funo derivada
segundo um certo nmero de etapas. De acordo
com um conjunto de critrios padronizados,
atribudo um ndice numrico a cada uma das
funes do negcio, conforme os respectivos tipo e
complexidade. Tais ndices so totalizados, de modo
a fornecer uma medida inicial de tamanho, a qual
ento normalizada, atravs da incorporao de um
conjunto de fatores relacionados ao software como
um todo. O resultado final um nico nmero, cuja
unidade de medida Pontos de Funo, que mede
o tamanho funcional do produto de software.
Em resumo, a tcnica de pontos de funo fornece
uma medida objetiva e comparvel que auxilia a
avaliao, planejamento, gerncia e controle da
produo de software.
Data Warehouse principal tecnologia utilizada
para o desenvolvimento de sistemas de BI, na qual
criado um repositrio para armazenar as
informaes com uma arquitetura e modelagem
especfica. Tambm chamado no portugus de
Armazm de Dados. Saiba mais sobre os Data
Warehouses
aqui.
http://www.futurecom.com.br/blog/o-que-e-umdata-warehouse/
Data Mart diviso dos dados do Data Warehouse
em subconjuntos referentes a determinados
assuntos. Normalmente, o conjunto de Data Marts
compe o Data Warehouse.
Modelagem Multidimensional chamado tambm
de modelagem dimensional, trata-se do tipo de
modelagem normalmente utilizado para a
construo de um Data Warehouse. Caracteriza-se
pela
intuitividade
e
alta
performance
proporcionada por sua estrutura.
OLAP On-line Analytical Processing (OLAP) a
capacidade de analisar de forma geral os grandes
volumes de dados do Data Warehouse. Aplicaes
OLAP so as ferramentas que efetuam a anlise e
manipulao das informaes em mltiplas
perspectivas.
OLTP On-line Transaction Processing (OLTP)
refere-se aos sistemas transacionais, que so
aqueles utilizados no dia a dia para o
processamento dos dados rotineiros de uma
empresa.
Dimenso Termo tcnico referente entidade
que, na construo do Data Warehouse, utilizado
21

para composio de anlises e relatrios,

armazenando dados descritivos e qualificando a
respectiva mtrica associada.
Fato Termo tcnico referente entidade que, na
construo de Data Warehouse, utilizada para
composio de anlises e relatrios, armazenando
mtricas e quantificando o respectivo descritivo
associado.
ETL Sigla originria do ingls Extract, Transform
and Load que referencia o processo de extrao,
transformao e carga que os dados so
submetidos antes de ingressar ao repositrio de
dados do Data Warehouse.
Star
Schema
Tipo
de
modelagem
multidimensional com formato caracterstico
semelhante estrutura estelar. Tambm chamado
de modelo estrela.
Snow Flake Tipo de modelagem multidimensional
com formato caracterstico semelhante estrutura
do floco de neve. Tambm chamado de modelo
floco de neve.
Data Mining Processo capaz de efetuar
prospeco de grandes volumes de dados,
normalmente armazenados no Data Warehouse,
para descoberta de correlaes, associaes e
padres
de
informaes
que
agreguem
perspectivas importantes tomada de deciso.
Tambm chamado no portugus de Minerao de
Dados
O que Business Intelligence?
Apesar do conceito de BI (Business Intelligence)
existir h mais de uma dcada, volta e meia
aparecem dvidas a respeito de sua arquitetura e
de como implementar o sistema.
Business Intelligence envolve basicamente a anlise
do negcio atravs de mtricas sintetizadas,
que agrupam toda a informao disponvel na
empresa, com o objetivo de melhorar a tomada de
deciso.A partir desta definio, j podemos
deduzir algo muitas vezes negligenciado pelos
analistas de BI: apenas as informaes teis para a
tomada de deciso por parte dos executivos devem
ser modeladas no sistema.
Trazer informaes apenas por trazer gera trabalho
(e custos) desnecessrios.
Como implementar uma aplicao dessas?

Uma aplicao de BI muito complexa, devendo ser

investido um bom tempo em anlise e
levantamento de requisitos.
O primeiro passo a especificao das fontes que
sero origens de dados. Estes dados encontram-se
em sistemas externos, como o ERP da empresa
(SAP, Oracle, Microsiga, Cigam, etc), o e-commerce,
o e-procurement, sistemas de B2B, planilhas Excel e
outras fontes.
Definidas as fontes, deve-se especificar os
processos de ETL (Extract, Transform, Load). Estes
processos so responsveis por:
1. Extrair todas as informaes relevantes para a
aplicao. . O sistema de extrao deve contemplar
funcionalidades que permitam conectar a estas
fontes e tratar os diversos formatos de arquivos.
2.
Transformar
os
dados.
Realizar
as
transformaes necessrias das origens de dados
para permitir a gravao no banco de dados.
3. Carregar os dados. Persistir as informaes no
sistema de BI.
Outra etapa importante a modelagem do Data
Warehouse.
Este
processo
contempla
a
especificao de vrios estgios no banco de dados,
cada um deles sendo uma "fotografia" dos dados a
serem transformados. Normalmente de definem 3
ou 4 estgios para a modelagem do banco.
A modelagem do banco de dados de um sistema de
BI segue um paradigma diferente. Normalmente os
analistas que esto acostumados com o paradigma
relacional de sistemas transacionais, que incluem a
normalizao do banco de dados, se sentem um
pouco perdidos. Para modelar um Data Warehouse,
deve-se definir as tabelas com redundncia de
dados, para facilitar a performance nas consultas e
permitir o uso de ferramentas de criao de cubos.
Alm disto, a modelagem desta maneira facilita os
processos de cargas de dados.
Normalmente, no estgio do banco especificado
para visualizao dos dados, opta-se pela criao de
um modelo estrela, centrado em uma tabela-fato
relacionada com as outras tabelas que representam
as dimenses de visualizao. Estes so os cubos,
que permitem a visualizao multidimensional dos
dados.
Ferramentas
Outra questo importante a escolha das
ferramentas a serem utilizadas. Para a criao dos
cubos, pode-se optar por um servidor OLAP (Online
22

Analytical Processing) como o Hyperion, Cognos ou

o Mondrian. Para o ETL, pode-se optar pelo
JasperETL ou o ODI (Oracle Data Integrator). Outra
ferramenta interessante que pode ser utilizada para
a visualizao dos dados e que costuma apresentar
boa performance o QlikView.
Business Intelligence contempla uma variedade de
conhecimentos, tcnicas e ferramentas, que torna
invivel citar tudo aqui. Para uma viso geral,
importante destacar que uma ferramenta
complexa de desenvolver, que envolve muitas
horas de trabalho e consequentemente um custo
considervel. A vantagem que este investimento
traz ter informaes sintetizadas da empresa para
melhorar a qualidade da tomada de deciso.
2 Minerao de Dados
A Minerao de Dados pode ser definida como um
conjunto de tcnicas automticas de explorao de
grandes massas de dados de forma a descobrir
novos padres e relaes que, devido ao volume de
dados, no seriam facilmente descobertas a olho nu
pelo ser humano. De fato, muitas so as tcnicas
utilizadas, porm a minerao de dados ainda
mais uma arte do que uma cincia. O sentimento
do especialista no pode ser dispensado, mesmo
que as mais sofisticadas tcnicas sejam utilizadas.
Ainda que as tcnicas da Minerao de Dados sejam
antigas, foi apenas nos ltimos anos que passaram
a ser usadas como explorao de dados, por vrios
motivos [Carvalho, 2005]:
O volume de dados disponvel atualmente
enorme Minerao de Dados uma tcnica que
s se aplica a grandes massas de dados, pois
necessita disto para calibrar seus algoritmos e
extrair dos dados concluses confiveis.
Empresas de telefonia, cartes de crdito, bancos,
televiso por assinatura, comrcio eletrnico, entre
outras, vem gerando a cada dia uma grande
quantidade de dados sobre seus servios e clientes.
Estes dados so passveis de anlise por minerao;
Os dados esto sendo organizados - Com a
tecnologia do dataware house3, os dados de vrias
fontes esto sendo organizados e padronizados de
forma a possibilitar sua organizao dirigida para o
auxlio deciso. As tcnicas de
3 De acordo com o Wikipedia: Data Warehouse
uma coleo de dados orientados por assuntos,
integrados, variveis com o tempo e no volteis,
para dar suporte ao processo de tomada de

deciso; Data Warehousing um processo em

andamento que aglutina dados de fontes
heterogneas, incluindo dados
histricos e dados externos para atender
necessidade de consultas estruturadas e ad-hoc,
relatrios analticos e de suporte a deciso
[Wikipedia, 2006].
A minerao de dados necessitam de bancos de
dados limpos, padronizados e organizados;
Os recursos computacionais esto cada vez mais
potentes - A minerao de dados necessita de
muitos recursos computacionais para operar seus
algoritmos sobre grandes quantidades de dados. O
aumento da potncia computacional,
devido ao avano tecnolgico e queda dos preos
dos computadores, facilita o uso da minerao de
dados atualmente. O avano da rea de banco de
dados,
construindo bancos de dados distribudos, tambm
auxiliou em muito minerao de dados;
A competio empresarial exige tcnicas mais
modernas de deciso As empresas da rea de
finanas, telecomunicaes e seguro experimentam
a cada dia mais competio. Como estas empresas
sempre detiveram em seus bancos de dados uma
enorme quantidade de informao, natural que a
minerao de dados tenha se iniciado dentro de
seus limites. Atualmente, outras empresas buscam
adquirir dados para analisar melhor seus caminhos
futuros atravs dos
sistemas de apoio deciso. Para empresas de
servios, a aquisio de dados importante, pois
precisam saber que servio oferecer a quem. Para
outras empresas, at a venda das informaes pode
ser um produto; e
Programas comerciais de
minerao de dados j podem ser adquiridos As
tcnicas de minerao de dados so antigas
conhecidas da Inteligncia Artificial, porm
somente recentemente saram dos laboratrios
para as empresas. Alguns pacotes j podem ser
encontrados no comrcio, contendo algumas destas
tcnicas. As tcnicas mais recentes, no entanto,
ainda se encontram no campo acadmico, sendo
necessrio que a empresa se dirija a uma
universidade que realize pesquisa para obter ajuda.
2.1 Fases da Minerao de Dados
Em 1996, um conjunto de trs empresas
especializadas no ento jovem e imaturo mercado
de data mining, desenvolveram um modelo de
23

processos genricos, com o intuito de padronizar as

etapas do processo de minerao de dados, dando
incio ao denominado projeto CRISP-DM (CRoss
Industry Standard Process for Data Mining) [The
CRISP-DM Consortium, 2000].
Este projeto desenvolveu um modelo de processo
de minerao de dados industrial e livre de
ferramenta. Comeando pelos embrionrios
processos de descoberta de conhecimento usados
nos primeiros projetos de minerao de dados e
respondendo
diretamente aos requerimentos do usurio, esse
projeto definiu e validou um processo de minerao
de dados que aplicvel em diversos setores da
indstria.
Essa metodologia torna projetos de minerao de
dados de larga escala mais rpidos, mais baratos,
mais confiveis e mais gerenciveis. At mesmo
projetos de minerao de dados de pequena escala
se beneficiam com o uso do CRISP-DM. O modelo
CRISP, atualmente, uma referncia para que seja
desenvolvido um plano de integrao para a
descoberta de conhecimento.
O atual processo para minerao de dados prope
uma viso geral do ciclo de vida de um projeto de
minerao de dados. Ele contm as fases
correspondentes de um projeto, suas respectivas
tarefas e relacionamentos entre essas tarefas.
Na Figura 2 mostrado o ciclo de vida de um
projeto de minerao de dados, que consiste de 6
(seis) fases. A seqncia de fases no obrigatria,
ocorrendo a transio para diferentes fases,
dependendo do resultado de cada fase, e que etapa
particular de cada fase precisa ser executada em
seguida. As setas indicam as mais importantes e
mais freqentes dependncias entre as fases.
O ciclo externo na figura simboliza o ciclo natural da
minerao de dados. Um processo de minerao de
dados continua aps a soluo ter sido
desenvolvida. As lies aprendidas durante o
processo podem provocar perguntas novas,
frequentemente mais pertinentes ao negcio.
Processos subsequentes se beneficiaro das
experincias de processos anteriores.
2.1.1 Entendimento do Negcio (Business
Understanding)
Essa fase inicial tem o foco no entendimento do
negcio que visa obter conhecimento sobre os
objetivos do negcio e seus requisitos, e ento

converter esse conhecimento em uma definio de

um problema de minerao de dados, e um plano
preliminar designado para alcanar esses objetivos.
2.1.2 Seleo dos Dados (Data Understanding)
Consiste no entendimento dos dados, que visa
familiarizao com o banco de dados pelo grupo de
projeto, utilizando-se de conjuntos de dados
"modelo". Uma vez definido o domnio sobre o qual
se pretende executar o processo de descoberta, o
prximo passo selecionar e coletar o conjunto de
dados ou variveis necessrias.
Essa fase se inicia com uma coleta inicial de dados,
e com procedimentos e atividades visando a
familiarizao com os dados, para identificar
possveis
problemas de qualidade, ou detectar subconjuntos
interessantes para formar hipteses.
2.1.3 Limpeza dos Dados (Data Preparation)
A fase de preparao de dados consiste na
preparao dos dados que visa a limpeza,
transformao, integrao e formatao dos dados
da etapa anterior. a atividade pela qual os rudos,
dados estranhos ou inconsistentes so tratados.
Esta fase abrange todas as atividades para construir
o conjunto de dados final (dados que sero
alimentados nas ferramentas de minerao), a
partir do conjunto de dados inicial.
A utilizao de Data Warehouses facilita em muito
esta etapa do processo de minerao de dados, que
costuma ser a fase que exige mais esforo,
correspondendo geralmente a mais de 50% do
trabalho. Por isso, muito importante para uma
organizao, que ela possua em seus processos
habituais boas
prticas da administrao de dados, como o Data
Cleansing, que uma parte fundamental da cadeia
da administrao da informao, responsvel pelas
etapas de deteco, validao e correo de erros
em bases de dados [Chapman, 2005].
2.1.4 Modelagem dos Dados (Modeling)
Fase que consiste na modelagem dos dados, a qual
visa a aplicao de tcnicas de modelagem sobre o
conjunto de dados preparado na etapa anterior.
Nessa fase, vrias tcnicas de modelagem so
selecionadas e aplicadas, e seus parmetros so
calibrados para se obter valores otimizados.
Geralmente, existem vrias tcnicas para o mesmo
tipo de problema de minerao. Algumas tcnicas
24

possuem requerimentos especficos na forma dos

dados. Conseqentemente, voltar para a etapa de
preparao de dados freqentemente necessrio.
A maioria das tcnicas de minerao de dados so
baseadas em conceitos de aprendizagem de
mquina, reconhecimento de padres, estatstica,
classificao e clusterizao.
2.1.5 Avaliao do processo (Evaluation)
A avaliao do processo visa garantir que o modelo
gerado atenda s expectativas da organizao. Os
resultados do processo de descoberta do
conhecimento podem ser mostrados de diversas
formas. Porm, estas formas devem possibilitar
uma anlise criteriosa para identificar a
necessidade de retornar a qualquer um dos
estgios anteriores do processo de minerao.
Nesta etapa se construiu um modelo que parece de
alta qualidade, de uma perspectiva da anlise de
dados. Antes de prosseguir, importante avaliar
mais detalhadamente o modelo, e rever as etapas
executadas para construir o modelo,
para se certificar de que ele conseguir alcanar os
objetivos de negcio.
Deve se determinar se houve algum importante
objetivo do negcio que no foi suficientemente
alcanado. No fim desta fase, uma deciso sobre o
uso dos resultados da minerao deve ser tomada.
2.1.6 Execuo (Deployment)
Esta fase consiste na definio das fases de
implantao do projeto de Minerao de Dados.
A criao do modelo no o fim do projeto. Mesmo
se a finalidade do modelo for apenas aumentar o
conhecimento dos dados, o conhecimento ganho
necessitar ser organizado e apresentado em uma
maneira que o cliente possa usar. Dependendo das
exigncias, a fase de execuo pode ser to simples
quanto a gerao de um relatrio, ou to complexo
quanto executar processos de minerao de dados
repetidamente. Em muitos casos ser o cliente, no
o analista dos dados, que realizar as etapas da
execuo. Entretanto, mesmo se o analista no se
encarregar da execuo importante que ele faa o
cliente compreender que medidas devero ser
tomadas a fim de empregar efetivamente os
modelos criados.
2.2 Tcnicas
Existem 5 (cinco) tcnicas gerais de minerao de
dados que englobam todas as outras formas de
apresentao e permitem uma viso mais global e
apropriada ao assunto. So elas a classificao, a

estimativa, a previso, a anlise de afinidades e a

anlise de agrupamentos [Carvalho, 2005].
2.2.1 Classificao
A classificao uma das mais utilizadas tcnicas de
minerao de dados, simplesmente porque uma
das mais realizadas tarefas humana no auxlio
compreenso do ambiente em que se vive. O ser
humano est sempre classificando o que percebe a
sua volta, criando classes de relaes humanas
diferentes (colegas de trabalho, amigos, familiares,
por exemplo...) e dando a cada classe uma forma
diferente de tratamento.
A classificao pode ser sintetizada por um
processo de discriminao de unidades em classes
ou categorias. Assim, classificam-se sabores,
amigos, clientes, eventos, entre outros, em
categorias, tais como doce / salgado / neutro, bom
/ mau e legal / ilegal.
Em um processo de minerao de dados, a
classificao est especificamente voltada
atribuio de uma das classes pr-definidas pelo
analista a novos fatos ou objetos submetidos
classificao. Essa tcnica pode ser utilizada tanto
para entender dados existentes quanto para prever
como novos dados iro se comportar
[Euriditionhome, 2004].
Como no mundo fsico nada exatamente igual,
por mais semelhante que parea, para se criar
classes preciso permitir que detalhes sejam
desprezados e somente as caractersticas principais
sejam observadas. A tarefa de classificar
geralmente exige a comparao de um objeto ou
dado com outros dados ou objetos que
supostamente pertenam a classes anteriormente
definidas. Para comparar dados ou objetos utilizase uma mtrica ou forma de medida de diferenas
entre eles.
Na minerao de dados so comuns as tarefas de
classificao de clientes em baixo, mdio ou alto
risco de emprstimo bancrio; de clientes
potencialmente consumidores de um determinado
produto a julgar pelo seu perfil; de transaes
financeiras como legais, ilegais ou suspeitas em
sistemas de fiscalizao do mercado financeiro; de
aes da bolsa de valores com lucros potenciais
baixos, mdios e altos, entre outras. Os algoritmos
mais utilizados para este fim so os de rvores de
deciso [Pelegrin et al., 2005], regresso [Han et al.,
2001] e redes neurais [Sousa, 1998].
25

2.2.2 Estimativa
A estimativa, ao contrrio da classificao, est
associada a respostas contnuas. Estimar algum
ndice determinar seu valor mais provvel diante
de dados do passado ou de dados de outros ndices
semelhantes sobre os quais se tem conhecimento.
Suponha que se deseja determinar o gasto de
famlias cariocas com lazer e que para isto se
possua ndices de gastos de famlias paulistanas
com lazer, em funo da faixa etria e padro sciocultural. No se sabe exatamente quanto as famlias
cariocas gastam com lazer mas se pode estimar
baseando-se nos dados das famlias paulistanas.
Certamente que esta estimativa pode levar a
grandes erros, uma vez que Rio de Janeiro e So
Paulo so cidades com geografias diferentes e que
oferecem diferentes opes de lazer a seus
habitantes.
A arte de estimar exatamente esta: determinar da
melhor forma possvel um valor, baseando-se em
outros valores de situaes semelhantes.
Os algoritmos de regresso e as redes neurais so
bastante utilizados nestes casos.
2.2.3 Previso
A previso, como tarefa tpica de DM, est
associada avaliao de um valor futuro de uma
varivel a partir dos dados histricos do seu
comportamento passado.
Assim, pode-se prever, por exemplo, se o ndice
bovespa subir ou descer no dia seguinte; qual
ser o valor de determinada ao daqui a um
determinado perodo de tempo; o nmero de
clientes que sero perdidos por uma empresa, em
um dado horizonte futuro de tempo; qual ser a
populao de uma certa cidade daqui a dez anos;
entre outras coisas.
A nica maneira de avaliar se a previso foi bem
feita aguardar o acontecimento e verificar o
quanto foi acertada ou no a previso realizada.
Sem dvida, a previso uma das tarefas mais
difceis no somente na minerao de dados, mas
tambm no cotidiano das pessoas.
Os algoritmos que podem ser utilizados aqui so,
dentre outros, as redes neurais, a regresso, e as
rvores de deciso.
2.2.4 Anlise de Afinidades
A anlise de afinidades preocupa-se em reconhecer
padres de ocorrncia simultnea de determinados

eventos nos dados em anlise. Determinar que

fatos ocorrem simultaneamente com probabilidade
razovel (co-ocorrncia) ou que itens de uma massa
de dados esto presentes juntos com uma certa
chance (correlao).
O exemplo mais clssico de anlise de afinidades
o do carrinho de supermercado, do qual deseja-se
conhecer quais os produtos que so comumente
comprados em conjunto pelos consumidores. Isto
possibilita a otimizao do layout interno dos
supermercados e a realizao de vendas dirigidas
nas quais os itens so oferecidos j em conjuntos
com preos menores.
Em termos de algoritmos, a utilizao das regras de
associao constitui-se no procedimento mais
utilizado nestes casos [Pelegrin et al., 2005].
2.2.5 Anlise de agrupamentos
A anlise de agrupamentos visa formar grupos de
objetos ou elementos mais homogneos entre si.
Pode ser estabelecido previamente um nmero de
grupos a ser formado, ou ento se pode admitir ao
algoritmo de agrupamento uma livre associao de
unidades, de forma que a quantidade de grupos
resultante seja conhecida somente ao final do
processo.
Uma clara diferena entre agrupamento e
classificao que na classificao as classes so
pr-definidas pelo pesquisador, enquanto que aqui
no existe tal requisito. Isto torna esta tcnica
muito mais complexa do que a classificao. Por
exemplo, dadas as classes animal, vegetal e
mineral, relativamente simples classificar a qual
dessas classes um certo objeto pertence, porm de
posse de uma massa de dados sobre o consumo no
Brasil, determinar quantas classes ou padres
de comportamento consumista existem algo bem
diferente. A dificuldade reside no fato de que
podem no haver tais classes, ou seja, os dados se
distribuem igualmente por todo o espao possvel
no determinando nenhuma categoria.
Na anlise de agrupamentos, os grupos ou classes
so construdos com base na semelhana entre os
elementos, cabendo ao analisador das classes
resultantes avaliar se estas significam algo til. Por
exemplo, agrupar sintomas pode gerar
classes que no representem nenhuma doena
explicitamente, uma vez que doenas diferentes
podem possuir os mesmos sintomas.
26

A anlise de agrupamentos normalmente uma

tcnica preliminar, utilizada quando nada ou pouco
se sabe sobre os dados. Segmentar um mercado
uma tpica anlise de agrupamentos onde
consumidores
so
reunidos
em
classes
representantes dos segmentos deste mercado.
Em geral, a tcnica de agrupamento executada
por algoritmos estatsticos especficos para esse
fim, porm as redes neurais e os algoritmos
genticos [Han et al., 2001] so tambm utilizados
neste sentido.

Fundamentos do ITIL 2011, com nfase em:

Gerenciamento Financeiro (Estratgias de Servio),
Gerenciamento do Nvel de Servio (Desenho de
Servio), Gerenciamento da Configurao e de
Ativo de Servio (Transio de Servio) e
Gerenciamento de Mudana (Transio de
Servio).
Information
Technology
Infrastructure
Library, (ITIL) um conjunto de boas prticas para
serem aplicadas na infraestrutura, operao e
manuteno de servios detecnologia da
informao (TI).
Mudanas e caractersticas da edio de 2011 do
ITIL
Um resumo das alteraes foi publicado pelo
Governo HM. Alinhada edio de 2007, a edio
de 2011 composta por cinco publicaes
principais - Estratgia de Servio,Desenho de
Servio, Transio
de
Servio, Operao
de
Servio e Melhoria Contnua de Servio. A ITIL 2011
uma atualizao do modelo (framework) ITIL que
aborda orientao adicional significativa com a
definio de processos formais que foram
previamente implicados, mas no identificados,
bem como a correo de erros e inconsistncias. H
26 processos listados na edio 2011 da ITIL e
descritos abaixo que mostra qual a publicao
principal que fornece o contedo principal de cada
processo.
O ITIL verso 3 composto de cinco volumes,
publicados em maio de 2007 e atualizado em julho
de 2011 como "ITIL 2011" para consistncia:
1. Estratgia de Servio
2. Desenho de Servio
3. Transio de Servio

4. Operao de Servio
5. Melhoria Contnua de Servio
Todos esses volumes esto com definies e
detalhamentos em ITIL verso 3.
O ITIL V3, publicado em maio de 2007, e atualizado
em 2011, composto de cinco volumes, estgios do
ciclo de vida de servio, detalhados abaixo:
2

Estratgia do servio (Service Strategy)

Como ponto de origem do ciclo de vida de servio
ITIL, o volume sobre estratgia do servio um guia
sobre como tornar mais claro e priorizar
investimentos sobre provimento de servios.
Os pontos chaves sobre este volume so:
Os quatro Ps da estratgia;
Competio e participao no mercado;
Definio do valor do servio;
Tipos de provimento de servio;
Gerenciamento de servios como um ativo
estratgico;
Fatores crticos de sucesso;
Contabilidade orientada a servio;
Modelos de fornecimento de servios;
Desenvolvimento e projeto organizacional.
Processos neste volume incluem:
Gerenciamento financeiro de servios de TI;
Gerenciamento de portflio (ou carteira) de
servios;
Gerenciamento de demandas;
Gerenciamento do relacionamento com o
negcio (atualizao 2011).
3
Desenho de servio (Service Design)
Desenho, com ITIL, englobar todos os elementos
relevantes entrega de servios de tecnologia, ao
invs de focar somente no projeto da tecnologia
propriamente dita. Assim, desenho de servio
aponta como uma soluo planejada de servio
interage com o negcio e ambiente tcnico.
Com ITIL, trabalho de projetar um servio de TI
agregado em um simples pacote de desenho de
servios (Service Design Package - SDP). SDP, em
conjunto com outros servios de informao, so
gerenciados com um catlogo de servios.
Processos inclusos neste volume:
Gerenciamento de catlogo de servios;
Gerenciamento de fornecedores;
Gerenciamento do nvel de servio (Service
Level Management - SLM);
Gerenciamento de disponibilidade;
27

Gerenciamento de capacidade;
Gerenciamento de continuidade de servios de
TI;
Gerenciamento de segurana da informao;
Coordenao do Desenho do Servio.
4
Transio do servio (Service Transition)
Este volume direcionado entrega dos servios
necessrios ao negcio no uso operacional, e
geralmente englobam o "projeto".
Os processos deste volume incluem:
Gerenciamento
de
mudana
(Change
Management);
Gerenciamento de configuraes e ativos de
servio;
Gerenciamento de conhecimento;
Planejamento de transio e suporte;
Gerenciamento de liberao e entrega (release
and deployment)
Testes e validao de servios;
Mensurao;
Papis da equipe engajada na transio do
servio.
Adicionais
Conjunto de processos e atividades para a
transio de servios
Engloba o gerenciamento de mudanas e as
proticas de liberao e implantao para que os
riscos, beneficnio e mecanismos de entrega e
de suporte aos servios sejam considerados.
Projeto de implantao.
Ajuda a organizao a planejar, gerenciar
mudanas nos servios e implantar liberaes
de servios com sucesso no ambiente de
produo.
Planejar e gerenciar os recursos para
estabelecer com sucesso um novo servio ou
uma alterao em um servio dentro do
ambiente de produo, com custo, pedido,
qualidade e tempo estimado
Assegurar que haja o mnimo de impacto
possvel nos servios em produo
Aumentar a satisfao de clientes, usurios e
equipe de suporte
Fornecer um plano compreensivo e claro para
que os projetos de mudana estejam alinhados
com os planos de transio de servio
Faz a interface entre o Desenho de Servio e a
Operao de Servio.

Operao do servio (Service Operation)

Parte do ciclo de vida onde servios e valor so
entregues diretamente. Assim, monitoramento de
problema e balanceamento entre disponibilidade
de servio e custo, etc, so considerados.
Processos inclusos so:
Gerenciamento de eventos;
Gerenciamento de incidentes;
Gerenciamento dos pedidos;
Gerenciamento de acesso, (service desk);
Gerenciamento de problemas.
Atividades comuns da operao do servio:
Controle e monitoramento;
Coordenao
entre
gerenciamento
e
operaes;
Gerenciamento da infraestrutura;
Aspectos operacionais dos processos de outras
fases do ciclo de vida.
7
Melhoria contnua do servio (Continual Service
Improvement)
A meta do CSI (Continual Service Improvement)
ajustar e reajustar servios de TI s mudanas
contnuas do negcio atravs da identificao e
implementao de melhorias aos servios de TI que
apoiam processos negociais.
Para gerenciar melhorias, o CSI deve definir
claramente o que deve ser controlado e medido...
CSI est preocupada com a manuteno do valor do
servio atravs da avaliao contnua e melhoria da
qualidade e da maturidade do ciclo de vida do
Gerenciamento de Servios de TI e demais
processos. Ela combina princpios, prticas e
mtodos de gesto da qualidade e gesto da
mudana para melhorar cada fase do ciclo de vida
do servio, processos e atividades relacionadas
tecnologia. Essas prticas devem ser incorporadas
cultura organizacional e tornarem-se atividades de
rotina.
Processos inclusos so:
Os sete passos da melhoria de processos:
1. Defina o que voc deve medir;
2. Defina o que voc pode medir;
3. Rena os dados;
4. Formate os dados;
5. Analise os dados;
6. Mostre e use a informao (dados);
7. Execute aes corretivas.
Medio de servios;
Relatrio de servios.
28

Estratgia de servios: identificao de requisitos e

necessidades de negcio que sejam atendveis
por servios de TI. Os requisitos e necessidades so
acordados e documentados em um SLP (service
level package ou pacote de nvel de servios).
Desenho de servios: a partir dos requisitos
concebida a soluo de TI em forma de servios, em
todos os seus aspectos, que so documentados em
um SDP (service design package ou
pacote de desenho de servio). O SDP nada mais
que um documento de especificaes e
caractersticas dos servios.
Transio de servios: trata da implementao em
produo. Tal implementao testada e
acompanhada, bem como validada. O SKMS
(service knowledge management system sistema
de gesto do conhecimento em servios de TI)
atualizado com as informaes do ambiente de
produo.
Operao de servios: o servio mantido em
operao e funcionamento de acordo com os nveis
de servio (SLA service level agreement, ou
acordo de nvel de servio) estabelecidos para gerar
os resultados esperados.
Melhoria de Servio Continuada (Melhoria Contnua
de Servios): identifica oportunidades de melhoria
no servio.
2. Estratgia de Servios
Objetivo: desenvolvimento de estratgias e
modelos organizacionais baseados em servios.
Engloba:
Quais servios sero oferecidos e para quais
clientes;
Como criar valor para estes clientes;
Como fazer que percebam o valor criado;
Como desenvolver planos de negcio de modo a
obter capacidades e recursos necessrios aos
servios;
Como otimizar a alocao de recursos;
Como medir o desempenho dos servios.
Conceitos Importantes deste livro:
Competitividade: servios operam em mercados
competitivos; portanto necessria uma estratgia
de terceirizao e provimento os servios.
4 P's da estratgia de servio:
Perspectiva direcionamento, viso estratgica
da organizao sobre o mercado;

Posio como o mercado enxerga a

organizao, daqui derivam estratgias de
diferenciao;
Plano traduz a estratgia para a produo /
operao;
Padro descreve caractersticas essenciais dos
servios, norteando o funcionamento dos servios e
da organizao.
Riscos: Servios devem ter seus riscos gerenciados.
Fatores crticos de sucesso: so identificados e
revisados periodicamente para garantir adequao
do portflio de servios estratgia. Indica para
quais elementos necessria ateno de modo que
o servio esteja alinhado estratgia.
Contabilidade orientada a servios: forma de
alinhar a Gesto de TI Gesto Financeira.
No Itil V3 a gesto financeira no mais apenas um
balizador do SLA, parte da estratgia, uma vez
que alm de demonstrar os custos da TI, tambm
demonstra o valor dela para o negcio)
Valor do servio: combinao da utilidade +
garantia,
que
devem
crescer/avanar
proporcionalmente.
1. Utilidade: adequado ao propsito. Segundo o
ITIL, um servio pode ser til para suportar o
desempenho ou remover barreiras.
2. Garantia: adequado ao uso. Podem ser garantia
de Disponibilidade, de Capacidade, de Continuidade
ou de Segurana (DCCS).
* O Service Level Package (SLP pacote de nvel de
servio) deve descrever os requisitos de Utilidade +
Garantia para criao de valor para o negcio.
Tipos de Provedores de Servio:
Tipo 1 interno, atende a uma unidade de
negcio apenas. Vantagem:
atendimento dedicado s necessidades de negcio.
Desvantagem: Duplicao de esforos.
Tipo 2 interno, atende a vrias unidades de
negcio. Vantagem:
padronizao e reduo de custos. Desvantagem:
maior exposio ameaas de substituio por
provedores externos.
Tipo 3 externo, atende vrias organizaes.
Vantagem: acesso facilitado a melhores prticas de
mercado, manuteno do foco da organizao no
prprio negcio. Desvantagem: negcio passa a
depender de terceiros, alm de dificuldade em
alcanar vantagens competitivas.
Ativos de servio: incluem qualquer coisa que possa
contribuir para a entrega de um servio. Para
29

prover servios devo garantir que tenho os ativos

necessrios. Desenvolv-los parte da estratgia.
Podem ser habilidades e recursos.
Habilidades diferenciam os servios providos pelas
organizaes.
Recursos so necessrios para que as organizaes
faam plenamente seu trabalho.
2.1 Processos do livro Estratgia de Servios
(Mnemnico: Est/Fin/Port/Dem)
2.1.1 [Est] Gerao da Estratgia (Ou
desenvolvimento da estratgia)
um processo difuso no livro (trata dos tipos de
provedor, dos 4 Ps , da alocao de recursos, etc).
Trata da definio do mercado a ser atendido, das
ofertas para esse mercado e dos
ativos a serem utilizados para isso.
Cuida da preparao da organizao para execuo
da estratgia (no aspecto de prover estrutura).
2.1.2 [Fin] Gesto Financeira
Atividades de oramentao, contabilizao e
cobrana.
Neste processo, h uma novidade da verso 3:
- Tambm realiza quantificao do valor do servio
e dos ativos, em termos de TIR (taxa interna de
retorno), ROI (retorno sobre investimento), etc.
Papel ligado a este processo: Gerente financeiro,
responsvel por lidar com custos, acordar valores,
participar
na
modelagem
da
demanda
(incentivos/penalidades demanda), alm de
manter conformidade com marcos regulatrios
financeiros, como Sarbanes Oxley Act, Acordo da
Basilia, Resoluo 3380-Bacen, etc.
2.1.3 [Port] Gerncia de portflio
Primeiro preciso destacar que o portflio de
servios no o catlogo de servios. O portflio
fornece informaes sobre todos os servios
atravs do ciclo de vida. A partir do portflio
possvel saber o que est na fila de servios para
ser desenvolvido (funil de servio), o que est em
operao (catlogo de servio), o que deve ser
aposentado ou j foi retirado do portflio (servios
obsoletos).
Este processo descreve os servios em termos de
valor para o negcio, definindo as necessidades do
negcio e as solues do provedor para elas. Alm
disso, este processo compara os servios de vrios
provedores, baseado na descrio e no valor. uma
forma de analisar a competitividade de servios,
verificando fraquezas e pontos fortes.

Este processo Define (constri e atualiza), Analisa

(alinhamento, priorizao e balanceamento),
Aprova (autorizao de servios e recursos) e
Contrata (Charter, comunicao e alocao) a partir
da estratgia de servio.
Papel: gerente de produto, que gerencia servios
como se fossem produtos no ciclo de vida.
2.1.4 [Dem] Gesto de Demandas
Este processo tem como objetivo entender e
influenciar as demandas de clientes pelos servios e
realizar a proviso de capacidade para o
atendimento s demandas.
Aqui
so
feitos:
Anlise,
Rastreamento,
Monitoramento e Documentao de Padres de
Atividade do Negcio (PAN ou BAP) para prever as
demandas atuais e futuras por servios.
No nvel estratgico, este processo faz a anlise de
padres de negcio e perfis de usurios.
No plano ttico, define o uso de mecanismos de
diferenciao (cobrana, nvel de servio) para
encorajar o uso adequado dos servios.
Papel: gerente de demandas, que tem como
objetivo gerenciar demandas e capacidades,
recursos dos processos alm de responder s
mudanas no PAN.
O resultado desse processo o SLP SERVICE LEVEL
PACKAGE, ou pacote de nvel de servios, que
define o valor dos servios em termos de utilidade e
garantia, conceitos que sero tratados a seguir.
3 Desenho de Servios:
Objetivo: desenho e evoluo de servios para
atender requisitos atuais e futuros de negcio.
Traduz o SLP em um conjunto de especificaes.
Produz e mantm planos, processos, polticas,
padres e arquiteturas para criao dos servios;
Desenha servios que forneam resultados
adequados ao negcio;
Desenha processos para suportar o ciclo de vida dos
servios;
Desenvolve habilidades e capacidades de TI.
Desenha recursos seguros e resilientes de infra,
ambiente, aplicaes e dados.
Desenvolve mtodos de mensurao e mtricas.
Esta fase (livro) desenha servios de TI apropriados
e inovadores, incluindo suas arquiteturas,
processos, polticas e documentaes, de modo a
suprir atuais e futuros requisitos de
negcio (adaptado do ITIL).
30

A fase de desenho de servios projeta o servio de

TI e tambm os processos ao longo do ciclo de vida
que norteiam este servio.
Aqui importante lembrar da viso holstica
definida pelo ITIL V3, que envolve no
desenho de servios no s a TI e suas solues,
mas arquiteturas e sistemas de gerenciamento,
processos,
papis,
capacidades
alm
de
mensurao e mtricas. Esta etapa deve envolver
outras gerncias caso necessrio, tais como de
Capacidade, Financeira, Fornecedores, alm de
funes
como Service Desk. Dessa forma o planejamento
completo sob diversas pticas, lembrando que
avaliaes iniciais de anlise de impacto do negcio
e anlise de riscos tambm so importantes.
Conceitos Importantes deste livro:
4 P's do Desenho de Servios:
Pessoas preciso determinar os papis das
pessoas nos processos;
Produtos determinar os produtos (servios,
tecnologia e ferramentas);
Processos definir os processos;
Parceiros estabelecer parceiros, fornecedores e
vendedores de soluo.
Atividades:
Eng. De Requisitos do negcio;
Desenvolvimento de soluo, processos e
mtricas;
Produo e reviso de documentos e processos;
Produo e manuteno de polticas;
Gerenciamento de riscos;
Alinhamento com polticas e estratgias.
* Essas atividades so executadas no mbito de
cada um dos processos desta etapa, permeando
todos.
Os cinco aspectos mais importantes do Desenho de
Servio so:
Identificao dos requisitos de negcio, Definio
dos requisitos do servio e Desenho do Servio;
Consulta constante ao Portflio de Servios (pois
contm detalhes dos Servios e seus status);
Desenho da Arquitetura e da Tecnologia
(desenvolvimento e manuteno de polticas,
estratgias, documentos, planos e sistema de
gerenciamento de servios);
Desenho do processo, especialmente os
necessrios para transio, operao e melhoria
continuada;

Desenho de mtricas para medio velha

mxima de que aquilo que no se pode medir, no
gerencivel.
Opes de fornecimento de servios:
Segundo o ITIL, uma organizao pode no ter
todas as habilidades necessrias para desenvolver e
prover um servio de TI. A soluo sugerida a
terceirizao utilizando uma das
seguintes estratgias:
In-sourcing a organizao desenvolve ou tem
todas as habilidades necessrias.
Resulta em melhor controle sobre a entrega, mas o
custo tambm maior;
Outsourcing usa recursos de uma organizao
externa para desenvolver e manter um servio.
Menor controle sobre a entrega, mas pode ser
muito vantajoso se servios comuns estiverem
nesse regime (Exemplo: servios de impresso, que
no agregam valor ou inteligncia ao negcio);
Co-sourcing combinao dos dois anteriores,
com a vantagem de ter-se melhor controle sobre a
entrega do servio em relao ao Outsourcing puro;
Parceria ou multi-sourcing organizaes fazem
arranjo formal para trabalhar em conjunto.
Distribuem as atividades entre vrios fornecedores,
contratando-se os melhores da classe, ao invs de
ficarem presas a apenas um. uma terceirizao de
menor risco, por ser mais seletiva;
Business Process Outsourcing uma organizao
fornece e gerencia totalmente processos de
negcio da outra, como por exemplo, os Call
Centers;
Application Service Provision trata de
estabelecer acordo com um ASP de Servios de
Aplicao) para fornecer servios compartilhados,
como por exemplo aplicaes na nuvem, onde a
empresa obtm o benefcio do software sem
necessidade de manter a infraestrutura de suporte.
Reduz custos, mas no aplicvel a sistemas
crticos para o negcio.
Knowledge Process Outsourcing (KPO)
terceirizao de expertise de processos de negcio.
um movimento recente, de empresas que tem
expertise em determinado processo e transformam
dados em informao estratgica.
3.1

Processos:
(Mnemnico:
Cat/Niv/Cap/Disp/Cont/SI/For)
3.1.1 [Cat] Gerenciamento do Catlogo de
Servios
31

O propsito do Gerenciamento do Catlogo de

servios atuar como fonte centralizada de
informaes sobre todos os servios acordados, e
assegurar que ele esteja disponvel para que tem
autorizao para acess-lo.
O processo tem como meta assegurar que o
catlogo seja produzido e mantido, contendo
informaes corretas sobre os servios operacionais
e sobre os que esto sendo preparados para entrar
em operao.
A informao sobre o servio deve ser correta e
refletir detalhes, status, interfaces e dependncias
atuais de todos os servios que esto em operaes
ou sendo preparados para ir ao ambiente
operacional.
O catlogo faz parte do portflio e contm
informaes mais estruturadas e detalhadas dos
servios. Neste sentido, O Gerente de Portflio
apenas gerencia o portflio, tomando deciso sobre
quais servios devem ser produzidos ou retirados
de operao.
J o catlogo e sua respectiva gerncia mantm as
informaes (que so muito densas e sofrem
mudanas ao longo do ciclo de vida dos servios)
atualizadas, fazendo o controle das alteraes.
Papel: gerente de catlogo de servio produz e
mantm o catlogo. Um forte candidato a assumir
esta funo o Gerente Central de Servios, pelo
bom trmite com os clientes da TI.
3.1.2 [Niv] Gerenciamento de Nvel de Servio
Objetivo: garantir que os servios e seu
desempenho so medidos de forma consistente por
toda a organizao e que atendem s necessidades
de clientes e negcio.
Negocia, estabelece acordos e documenta as metas
de negcio a serem alcanadas pelos servios e
monitora e relata os SLAs (acordos de nvel de
servio).
O nvel de servio deve ser desenhado
corretamente para evitar que o servio seja
colocado em operao com nveis abaixo dos
requeridos. Logo, este processo depende de
informaes
advindas da Estratgia de Servio.
O gerenciamento de nvel de servio possibilitar
estabelecer acordos entre as partes.
Aqui sero negociados e acordados os requisitos
atuais nos SLAs (ou ANS), bem como os requisitos
de nvel de servio (RNS) para servios futuros.

Devero ser desenvolvidos e gerenciados os

Acordos de Nvel Operacional (ANOs ou OLAs)
baseados no alinhamento das metas com os SLAs.
Sero revisados contratos junto com o processo de
Gerenciamento de Fornecedores para garantir que
as metas esto sendo cumpridas.
Falhas nos servios devero ser proativamente
prevenidas e o PAS Plano de Aperfeioamento de
Servio (do ingls SIP Service Improvement Plan)
dever gerenciar,
planejar, e implantar melhorias nos servios e
processos.
Tambm sero desenvolvidos e mantidos os Planos
de Qualidade dos Servios (SQP).
Papel: gerente de nvel de servio responsvel por
identificar, entender e documentar os requisitos de
servio atuais e futuros, negociar os acordos, avaliar
impacto dos nveis de servio e
identificar quem so os stakeholders em cada
servio, alm de medir e analisar a melhoria de
satisfao do cliente.
3.1.3 [Disp] Gerenciamento da Disponibilidade:
Tem a meta de assegurar que os servios sejam
entregues dentro dos nveis acordados.
Concentra questes relacionadas disponibilidade
de servios, componentes e recursos e garante que
as metas de disponibilidade em todas as reas
sejam alcanadas e atendam s necessidades do
negcio.
Realiza a gesto da disponibilidade, confiabilidade,
sustentabilidade e funcionalidade (serviceability).
Mas s para as VBF's (Vital Business Functions),
uma vez que a gesto para todas as funes de
negcio torna-se cara e invivel.
Disponibilidade: refere-se habilidade de um
servio, componente ou item de configurao
executar sua funo acordada quando requerida;
Confiabilidade: a medida de quanto tempo um
servio, componente ou item de configurao pode
executar sua funo acordada sem interrupo.
Muito dependente da qualidade.
Sustentabilidade: mede a velocidade com que um
servio, componente ou item de configurao
consegue ser restaurado para o seu estado normal
aps uma falha. necessrio que a equipe suporte
o servio. Exemplo: Migrar o ambiente para um
Sistema Operacional novo, mas que ningum
domine a tecnologia, insustentvel.
32

Funcionalidade (serviceability): a habilidade de

um fornecedor em atender os termos de seu
contrato, como em casos de produtos suportados
pelos seus fabricantes, onde a TI dever ter
habilidade de obter esse servio.
O gerenciamento da disponibilidade no trata s de
planejamento, mas tambm de aspectos reativos
(anlise de indisponibilidades) e proativos (melhoria
de disponibilidade).
Papel: gerente de disponibilidade , que deve
garantir que servios atuais entregam os nveis de
disponibilidade acordados nos ANS e que os novos
servios so desenhados para entregar o nvel de
disponibilidade requerido pelo negcio.
Produtos: AMIS (Sistemas de Informao de Gesto
da disponibilidade) e Plano de Disponibilidade.
3.1.4 [Cap] Gerenciamento da Capacidade
Este processo mantm os nveis de entrega de
servios requisitados a um custo acessvel, alm de
assegurar que a capacidade da infraestrutura de TI
esteja alinhada com as necessidades de negcio.
suportado inicialmente pela estratgia de servio
na criao de indicadores necessrios para alinhar a
capacidade demanda.
Faz a gesto da capacidade de negcio (requisitos
futuros), de servio (dentro do ANS) e dos
componentes
(individualmente,
dentro
da
infraestrutura) ao longo de todo o ciclo de vida dos
servios.
Concentra a gesto de questes relacionadas a
capacidade e desempenho de servios e recursos;
equilibra a capacidade de TI com as demandas de
negcio acordadas.
Este processo deve fazer o balanceamento entre
custo x capacidade e fornecimento x demanda.
Fator chave de sucesso: sua realizao na fase de
desenho.
Principais produtos do processo: o SIGC (Sistema de
Informao de Gerenciamento da Capacidade
CIMS, em ingls) e Plano de Capacidade.
Papel: gerente de capacidade, responsvel por
garantir capacidade adequada, bem como
configurar um monitoramento de nveis atravs de
relatrios.
3.1.5 [Cont] Gerenciamento da Continuidade de
Servio Objetivo: manter continuamente a
capacidade de recuperao dos servios de TI, de
modo a atender as necessidades, requisitos e
prazos de negcio. Tudo isso atravs de planos,

anlises de impacto, avaliaes de risco,

aconselhamento das reas de negcio, medidas
proativas e negociao de contratos para suportar a
continuidade junto com o Gerenciamento de
Fornecedores.
O gerenciamento da continuidade de servio trata
de eventos significativos o suficiente para serem
considerados desastres. Este processo investiga,
desenvolve e implementa opes de
recuperao de servios quando ocorrer uma
interrupo grave.
A meta deste processo dar suporte aos processos
do Gerenciamento da Continuidade do Negcio
assegurando que os requisitos tcnicos de servios
e de estrutura de TI (incluindo sistemas, redes,
aplicativos, telecomunicaes, ambientes, suporte
tcnico e inclusive Central de Servios) possam ser
reiniciados dentro do tempo requerido e acordado.
A Anlise de Impacto do Negcio AIN (em ingls,
Business Impact Analysis BIA) feita no processo
de Gerenciamento Financeiro e complementada
aqui, de modo a quantificar o impacto que a perda
do servio de TI teria no negcio.
Neste processo implantado um fluxo de
atividades:
Estabelecer uma poltica;
Escopo do que deve ser includo nos planos;
Iniciar um projeto;
Anlise de impacto e avaliao de riscos;
Estratgia de continuidade dos servios de TI;
Desenvolver os planos de continuidade;
Desenvolver planos de recuperao e
procedimentos;
Testar a estratgia.
Produtos: estratgias e polticas de ITSCM (IT
Service Continuity Management) e planos de
preveno de desastres, de contingncia e
recuperao de desastres.
Papel: gerente de continuidade de servio, que faz
a gesto das mudanas que possam impactar na
continuidade, testes de continuidade, alm da
manuteno da continuidade do servio
de acordo com os requisitos do processo de
Gerenciamento da Continuidade de Negcio.
3.1.6 [SI] Gesto de Segurana da Informao
Objetivo: alinhar a segurana de TI do negcio e
garantir que a segurana da infraestrutura seja
33

gerenciada eficazmente em todos os servios e

atividades.
Trata da segurana alinhada governana
corporativa.
Alm de garantir o CID (Confidencialidade,
Integridade e Disponibilidade) tambm cuida da
Autenticidade e No Repdio.
Este processo de Gerenciamento de SI baseado na
norma ISO/IEC 27001, que aponta um ciclo para a
gesto de segurana da informao: EIOMAMM
(Ciclo PDCA) = Estabelecer / Implementar e Operar
/ Monitorar e Analisar Criticamente / Manter e
Melhorar.
Na verdade, o ciclo descrito no ITIL usa a seguinte
terminologia (CPIAM):
Controlar a primeira atividade do
gerenciamento de segurana e trata da organizao
e do gerenciamento do processo.
Planejar inclui definir os aspectos de segurana
do SLA em conjunto com o Gerenciamento de Nvel
de Servio, detalhando em ANOs posteriormente.
Tambm define as atividades em contratos com
terceiros relacionadas segurana. Importante
lembrar que os ANOs (Acordos de Nvel
Operacional) so planejamentos para uma unidade
do provedor de servio, como por exemplo para
cada plataforma de TI, aplicao e rede.
Implantar - implanta todas as medidas
especificadas nos planejamentos. Classifica e
gerencia os recursos de TI, trata da Segurana de
Pessoal (job-description, seleo, treinamentos) e
gerencia a segurana como um todo (implantao
de responsabilidades e tarefas, desenvolve
regulamentos e instrues, cobre todo o ciclo de
vida, tratamento de ambientes, mdias, proteo
contra vrus e ameaas).
Avaliar - avalia o desempenho das medidas
planejadas e atende aos requisitos de clientes e
terceiros. Os resultados podem ser usados para
atualizar medidas acordadas em consultas com os
clientes e para sugerir mudanas. Pode ser feita de
trs formas:
auto-avaliao, auditorias internas e auditorias
externas.
Manuteno - mantm a parte do SLA que trata
de segurana e mantm os planos detalhados de
segurana. feita baseada nos resultados da
avaliao e na anlise de mudanas nos riscos.
Papel: Gerente de Segurana responsvel por
atender aos objetivos deste processo, cuidar da

Poltica de SI como um todo e garantir que a mesma

seja adequada e seguida por todos.
Produtos: Sistema de Informao de Gesto de
Segurana (SMIS) e Poltica de SI
3.1.7 [For] Gerenciamento de fornecedor
Gerencia fornecedores e respectivos servios
fornecidos de acordo com as metas dos servios de
TI e as expectativas do servio. A meta desse
processo melhorar a conscincia da entrega dos
servios fornecidos por parceiros e fornecedores
externos de modo a beneficiar o negcio e a
organizao.
Deve ser feito em todas as fases do ciclo de vida.
Est explcita nesta fase porque aqui so
identificados e selecionados os fornecedores,
inicialmente, ao projetar um servio novo.
O objetivo desse processo obter o retorno
adequado (value for money) dos fornecedores e
garantir que eles alcancem metas estabelecidas em
seus contratos.
Produto : Base de Dados de Fornecedores e
Contratos (SCD). Sugere-se classificar os contratos
dentro desta base em fornecedores estratgicos,
tticos (atividades comerciais significativas),
operacionais e de commodities (papel, cartucho,
etc).
Papel Gerente de Fornecedores assiste o
desenvolvimento de SLAs, contratos, acordos e
demais documentos com terceiros. Mantm e
revisa o SCD, avalia e adquire novos contratos e
fornecedores. Revisa os riscos de todos os
fornecedores e contratos e mantm o processo de
negociao em disputas contratuais. Recomendvel
que o Gerente de Fornecedores seja o Gerente da
Central de Servios ou do Nvel de Servios.
3.2 Outros papis na fase do Desenho de Servios:
Gerente de Desenho de Servios: coordena os
gerentes dos processos para a produo de
desenhos de servios de qualidade.
Arquiteto de TI: coordena o desenho de
tecnologias, arquiteturas, estratgias e planos.
3.3 Sada da etapa de Desenho do Servio:
o SDP Service Design Package, um documento
de especificaes do servio.
4. Transio de Servio
A fase descrita nesse livro tem o propsito de
planejar, gerenciar mudanas nos servios e
34

implantar liberaes de servios com sucesso no

ambiente operacional.
Os objetivos so:
Planejar e gerenciar os recursos de modo a
estabelecer um novo servio ou alterao de um
servio no ambiente de produo, com qualidade,
custos previsveis e dentro do prazo estimado.
Assegurar o menor impacto possvel nos servios
em produo quando uma mudana ou um novo
servio for implantado.
Aumentar a satisfao dos clientes, usurios e
equipe de suporte com prticas de transio que
resultem em menor impacto para organizao.
Fornecer plano compreensivo e claro para que os
projetos de mudana estejam alinhados aos planos
de transio de servio.
Esta fase faz a transio entre o Desenho e a
Operao. Deve implantar os servios em produo
com base nas especificaes produzidas pelo
estgio de Desenho. Tambm envolve a
modificao do desenho e a reanlise das
especificaes.
O foco da transio est em todos os aspectos do
servio, incluindo o suporte a falhas.
A transio requer a compreenso de:
Potencial que o servio tem de criao de valor
para o negcio;
Partes interessadas, tais como fornecedores,
clientes e outras reas envolvidas/afetadas.
Princpios Bsicos:
Compreenso integral dos servios (quanto
Natureza, Utilidade e Garantia);
Estabelecimento de poltica e mtodo para
implementar mudana;
Foco na transferncia de conhecimento para
tomada de deciso e execuo dos processos;
Ao proativa para correo dos rumos;
Identificao de necessidades ao longo da
transio.
Conceitos importantes deste livro :
Item de configurao um ativo, um componente
de servio ou qualquer outro item sob controle do
processo de Gerenciamento de Configurao
(hardware, software, documentao, equipe).
BDGC ou CMDB / Banco de Dados de
Gerenciamento de Configurao um repositrio
de informaes sobre os registros de itens de
configurao. Cada item deve ter nesse BD um

registro nico, com alguns campos que o

identifiquem.
Sistema de Gerenciamento de Configurao SGC
ou CMS para gerenciar servios de TI necessrio
um sistema de suporte, que faa a gesto da
configurao dos ativos. Consiste em quatro
camadas:
Camada de apresentao: formatao de
informaes em relatrios especficos para
determinados pblicos.
Camada de processamento de conhecimento:
onde se produzem as querys (consultas) para
extrair os dados para serem exibidos em relatrios.
Camada de integrao de informao: coleta e
estrutura os dados.
Camada de dados: dados e informaes de
diferentes origens, como BDGCs, ferramentas de
inventrio, informaes de projetos.
Sistema de Gerenciamento do Conhecimento de
Servio SGCS ou SKMS formado por um
conjunto de dados em base central. Os BDGCs
alimentam o SGC, que fornece informaes ao SGCS
e estas informaes suportam a tomada de
decises.
Biblioteca de Mdia Definitiva BMD ou DML A
Definitive Media Library uma biblioteca segura
que armazena cpias-mestre de verses
autorizadas e definitivas de itens de configurao
(softwares). Difere do BDGC por que o BDGC
armazena registros lgicos, enquanto esta
biblioteca pode ser um armrio que contm as
mdias fsicas (cds / dvds), por exemplo.
Mudanas de Servio (service change) mudana
em um servio existente ou uma introduo de
novo servio no ambiente de produo.
Tipo de Mudanas (change types) podem ser trs:
Padro, Normal e Emergencial.
Padro indica que ela muda um servio ou
infraestrutura
e

pr-autorizada
pelo
Gerenciamento de Mudana. Normal trata de
mudana levantada a partir de uma pessoa ou
organizao, sendo
necessrios autorizao e planejamento antes da
execuo. Emergencial necessita urgncia para
implantao, em resposta a um incidente (nem
sempre possvel testar por completo).
7 Rs do Gerenciamento de Mudana
- Quem submeteu a mudana? (Raise)
- Qual a razo da mudana? (Reason)
35

- Qual o retorno requerido a partir da mudana

(Return)
- Quais so os riscos envolvidos na mudana?
(Risks)
- Quais os recursos necessrios para entregar a
mudana? (Resources)
- Quem o responsvel por construir, testar e
implantar a mudana? (Responsible)
- Qual a relao entre esta mudana e outras
mudanas? (Relationship)
Unidade de Liberao (Release Unit) a poro de
um servio ou infraestrutura de TI que
normalmente liberada de acordo com a poltica de
liberao da organizao. Esta unidade varia em
termos de item, ativo de servio e componente de
servio (hardware ou software).
O modelo V de Servio uma ferramenta para
mapear os diferentes nveis de configurao que
precisam ser construdos e testados. Na vertical
esto os nveis, partindo da especificao e
chegando ao detalhamento, enquanto na horizontal
podem
ser
especificadas
atividades
correspondentes, tais como testes e validaes.
4.1

Processos
(Mnemnico
Mu/Conf/Conh/Sup/Lib/Val/Aval):
importante ressaltar aqui que na Transio h
dois tipos de processos. Aqueles que so restritos
ao estgio de Transio e aqueles que permeiam
todo o ciclo de vida. Sero oportunamente
identificados nos tpicos a seguir.
4.1.1 Gerenciamento de Mudana (aplicvel a
todo o ciclo de vida)
O objetivo deste processo assegurar que
mudanas so feitas de forma controlada, e so
avaliadas, priorizadas, planejadas, testadas,
implantadas e documentadas.
Os riscos devem ser mapeados e gerenciados. A
rea de TI precisa ser responsiva s mudanas no
negcio.
O escopo deste processo cobre as mudanas desde
a base de ativos de servio e itens de configurao
at o completo ciclo de vida do servio. Isso implica
dizer que este processo pode ser usado para
implantar
melhorias
nos
processos
de
Gerenciamento de Servios de TI.
Conceitos bsicos do processo de mudana:
Requisies de Mudana (RDM ou RFC) so
requisies formais para mudar um ou mais Itens
de Configurao.

Comit Consultivo de Mudanas (CCM ou Change

Advisory Board CAB) rene pessoas que
autorizam a mudana e auxiliam na sua avaliao e
priorizao.
Como funciona o processo de mudana?
O processo de mudana comea com uma RDM.
Uma RDM pode conter proposta de mudana que
crie novas facilidades ao negcio, ou conter
justificativa do gerente de problema para implantar
mudana que corrija um problema. A RDM
verificada em termos de conformidade, se
necessria , se est completada e j no havia outro
registro aberto. Aqui aplicam-se os 7Rs. Depois da
anlise a avaliao , o comit decide pela
implementao, priorizando com base no impacto e
na urgncia. Em seguida coordenada a
implantao, que aps feita, deve ser avaliada para
saber se cumpriu o seu propsito.
Resultados esperados:
Reduo de erros em servios novos ou alterados;
Maior velocidade e preciso na realizao de
mudanas;
Priorizao de mudanas com maior benefcio
para o negcio.
Papel inerente a esta fase: Gerente de Mudana
que trata as mudanas em todo o seu ciclo, desde a
requisio at a implementao / rejeio. Ele deve
presidir o comit consultivo e enviar as agendas de
mudanas ao Service Desk. O comit consultivo
tambm exerce um papel, bem como o comit
emergencial (que um destacamento do
consultivo) para tratamento de mudanas
emergenciais.
4.1.2 [Conf] Gerenciamento da Configurao e de
Ativo de Servio (aplicvel a todo o ciclo de vida dos
servios)
Identifica todos os Itens de Configurao
necessrios para entregar os servios de TI,
fornecendo um modelo lgico da estrutura de TI.
As informaes sobre os itens de configurao so
mantidas na Base de Dados do Gerenciamento de
Configurao (BDGC).
Este processo identifica, controla e presta contas
por ativos de servios e itens de configurao
protegendo e garantindo sua integridade ao longo
do ciclo de vida. Inclui ativos que no sejam de TI e
ativos de provedores de servios, quando
necessrio.
Conceitos bsicos neste processo:
36

Biblioteca Segura (secure library): coleo de Ics de

software, eletrnicos ou documentos.
Armazm Seguro (secure store): o local onde ser
armazenam os ativos de TI.
Biblioteca de mdia definitiva (BMD DSL):
biblioteca segura na qual verses de software
autorizadas so armazenadas.
Peas Definitivas (definitive spares): armazena
peas sobressalentes de hardware, como mouses,
teclados e memrias.
Linha de Base de Configurao: a configurao
aprovada de um servio, produto ou infraestrutura.
Snapshot (Instantneo): cpia do estado atual de
um IC ou ambiente. Ferramentas de inventrio
mantm a rastreabilidade desses estados.
O produto deste processo o Sistema de
Gerenciamento da Configurao, conforme visto
anteriormente.
Papis: Gerente de Ativos de Servio, Gerente de
Configurao, Analista de Configurao,
Bibliotecrio de Configurao e Administrador de
Ferramentas de SGC.
4.1.3 [Conh] Gerenciamento do Conhecimento
(aplicvel a todo o ciclo de vida)
Tem como objetivo garantir que as pessoas certas
tenham o conhecimento adequado e oportuno para
entregar e suportar os servios requeridos.
Trata o conhecimento como forma de prover
servios eficientes e com qualidade, de valor
compreensvel a todos.
Principal sada: SKMS ou SGCS (sistema de gesto
do conhecimento de servios)
4.1.4 [Sup] Planejamento e Suporte da Transio
Tem como foco a melhoria das habilidades e da
eficincia do provedor de servios, de modo a
suportar grandes volumes de mudanas e
liberaes de servios.
Objetivos:
Planejar e coordenar recursos para garantir que
os requisitos codificados no desenho do servio
sejam realmente atendidos durante a operao do
servio.
Identificar, gerenciar e controlar os riscos de
falhas e interrupo de servios durante as
atividades de transio.
4.1.5 [Lib] Gerenciamento de Liberao e
Implantao.
To logo o gerenciamento de mudana aprovar a
mudana (atravs do comit consultivo), ela

passada para este processo, para que seja liberada

e implantada no ambiente de produo.
Este processo faz o controle de verses e controla
as instalaes de software, hardware e outros
componentes de infraestrutura, do ambiente de
desenvolvimento ao ambiente de teste e depois
para o ambiente de produo.
No desenvolve a mudana, apenas sua liberao
(ex: deployment de um software).
Liberaes so planejadas e este processo deve
atender at o suporte inicial da entrada em
produo.
Opes mais frequentes para o lanamento de
liberaes:
Big bang ou por fase: bigbang implanta o servio
para todos ao mesmo tempo, enquanto por fase a
liberao feita para partes de usurios.
Empurrada ou Puxada (Push/Pull): na liberao
empurrada o componente do servio implantado
a partir da rea central para usurios em
localizaes remotas. Puxada os usurios devem
trazer para si as atualizaes, atravs de downloads
ou requisies.
Automatizada ou manual: as automatizadas fazem
uso de scripts que rodam atualizao em cada
mquina na rede, atravs de um comando central,
por exemplo. Alguns softwares fazem isso. J a
liberao manual requer interveno ponto a
ponto.
Atividades de liberao: Planejamento / Preparao
para Construo, Teste e Implantao / Construo
e Teste / Teste de Servio e Pilotos / Planejamento
e Preparao para Implantao / Transferncia,
Implantao e Retirada / Verificao / Suporte.
Produtos/Sadas deste processo:
Aumento de valor para o negcio pela otimizao
de velocidade, custo e risco das mudanas;
Consistncia e auditabilidade na implantao de
servios teis ao negcio;
Correo de desvios no SDP.
Papis:
Gerente de liberao e implantao responsvel
por planejar, desenhar, construir, configurar e
testar os novos softwares e hardwares para criar o
pacote de liberao para a entrega de mudanas
nos servios.
Gerente de empacotamento e Construo de
Liberao estabelece a configurao final da
liberao.
37

Equipe de Implantao responsvel pela entrega

fsica do servio.
4.1.6 [Val] Validao de Servio e Testes
Este processo tem foco na qualidade. Deve checar
que o servio atende ao requisito do SDP, dentro
dos nveis de risco aceitos pelo negcio.
Objetivo: prover evidncia objetiva de que o servio
novo ou alterado suporta os requisitos de negcio,
incluindo os acordos de nvel de servio (SLA)
estabelecidos.
Concentra-se na funcionalidade, disponibilidade,
continuidade, segurana, usabilidade e testes de
regresso.
4.1.7 [Aval] Avaliao
Avaliao da relevncia do desenho do servio, da
abordagem de transio e da adequao do servio
novo ou alterado aos ambientes operacionais e de
negcios.
Objetivo: garantir que o servio continue sendo
relevante,
pelo
estabelecimento
de
mtricas/mensurao apropriados.
4.2 Atividades Operacionais da Transio
O ITIL V3 trata uma Transio como se fosse um
projeto, ou seja, Projetos de Implantao da
Mudana. Portanto, as seguintes atividades so
importantes:
Gesto de comunicao e compromissos;
Gesto de mudanas organizacionais e de partes
interessadas;
Organizao de papis e responsabilidades pela
transio de servios;
No so necessrias equipes exclusivas
transio, mas sim pessoas aproveitadas de outras
reas com experincia e habilidades adequadas.
5 Operao de Servio
Objetivo: entregar aos clientes e usurios os nveis
de servio acordados e gerenciar as aplicaes,
tecnologia e infraestrutura que suportam a entrega
do servio.
Este o nico estgio em que os servios
efetivamente entregam valor ao cliente, uma vez
que para o Cliente o valor est no servio de TI em
produo.
OBJETIVOS CONFLITANTES:
viso interna (TI) x viso externa (negcio): a
viso tcnica necessria para a gesto dos
componentes dos servios, mas no pode se
sobrepor aos requisitos de qualidade dos usurios
para esses servios;

estabilidade x tempo de atendimento: a infra de

TI deve ser estvel para oferecer a disponibilidade
esperada, ao passo que deve ser flexvel para
adaptar-se a mudanas de requisitos de negcio;
qualidade do servio x custo do servio: os
servios devem atender os acordos de nvel de
servio estabelecidos ao menor custo possvel e
com uso otimizado dos recursos;
atividades reativas x proativas: importante agir
proativamente
antecipando-se
a
possveis
problemas, desde que isso no implique mudanas
excessivas ou perda da capacidade de reao.
Conceitos Bsicos:
Requisio de servio: o pedido de informao
para uma mudana ou o pedido para acessar um
servio de TI. geralmente atendida pela Central de
Servio e no requer a abertura de uma requisio
de mudana.
Evento: um status report criado por um servio,
item de configurao ou ferramenta de
monitoramento causado pela alterao no
desempenho da infraestrutura ou de entrega de
servio. Geralmente requer que incidentes sejam
registrados e uma ao seja tomada pelo pessoal de
operaes de TI. uma mudana de estado
significativa para um item de configurao ou
servio.
Alerta: um aviso ou advertncia sobre uma
meta (threshold), mudana ou falha que ocorreu.
produzido e tratado por ferramentas de
gerenciamento de sistemas e pelo processo de
gerenciamento de eventos.
Incidente: interrupo inesperada ou reduo na
qualidade de um servio de TI.
Pode ser uma falha de um item de configurao que
ainda no tenha impactado o servio, mas que
possa faz-lo em breve.
Problema: a causa de um ou mais incidentes. O
processo de Gerenciamento de Problemas
responsvel pela investigao da causa raiz.
Soluo de contorno (workaround): resolve uma
dificuldade ou questo de forma temporria,
paliativa.
Erro conhecido (known error): um problema
que tem a causa raiz documentada e uma soluo
de contorno identificada. Erros conhecidos so
identificados no ciclo de
vida do processo de Gerenciamento de Problema.
Base de Erros Conhecidos: registro centralizado
de erros conhecidos. Tais registros so utilizados
38

pelo processo de Gerenciamento de Incidente para

resolver incidentes.
Esta base, por sua vez, faz parte do SKMS / SGCS
Sistema de Gerenciamento do Conhecimento de
Servio. Esta base pode ser disponibilizada para que
os usurios faam o prprio atendimento.
Impacto, urgncia e prioridade: a avaliao de
impacto e da urgncia de incidentes, problemas e
mudanas importante para determinar suas
prioridades. A prioridade determina a ordem de
execuo. Determin-la baseado na combinao
entre impacto x urgncia uma boa prtica. O
impacto considera quantas pessoas, clientes ou
quanto do negcio ser afetado, enquanto a
urgncia determina a velocidade em que o
incidente precisa ser resolvido.
Importncia da comunicao: a comunicao
entre as equipes de TI, departamentos, usurios,
clientes primordial na Operao de Servio. Uma
poltica de comunicao em cada equipe ou
departamento e para cada processo deve ser
estabelecida. A comunicao pode ser formal, mas
no necessariamente complexa.
5.1

Processos
(Mnemnico:
In/Ev/Cump/Ace/Prob):
5.1.1 [In] Gerenciamento de Incidentes:
O propsito deste processo restaurar o servio ao
normal o mais rpido possvel, alm de minimizar o
impacto no negcio.
Incidentes so:
Frequentemente detectados pelo Gerenciamento
de Eventos, ou por usurios contactando a Central
de Servios;
Categorizados para identificar quem dever
trabalhar neles e para anlises de tendncias;
Priorizados de acordo com a urgncia e o impacto
para o negcio.
Se um incidente no puder ser resolvido
rapidamente, ele poder ser escalado. Isso ocorre
de duas formas:
Escalao funcional passa o incidente para uma
equipe tcnica de suporte com
habilidades apropriadas;
Escalao hierrquica envolve os nveis
apropriados de gerncia.
Aps a investigao de um incidente, seu
diagnstico e o teste de sua resoluo, a Central de
Servios deve assegurar que o usurio est
satisfeito antes de fechar o registro do Incidente.

Dessa forma, uma ferramenta de gerenciamento de

incidentes essencial para guardar e gerenciar
informaes de incidentes.
Elementos que devem ser tratados no
Gerenciamento de Incidentes:
Limites de tempo: os limites de tempo para todas as
etapas na resoluo de incidentes devem ser
definidos e acordados, usando as metas do Acordo
de Nvel de Servio e de contratos
com fornecedores. Tudo isso para que os incidentes
sejam resolvidos dentro do tempo hbil sem
infringir o ANS com os clientes.
Modelos de incidente: determinam os passos que
so necessrios para executar o processo de
recuperao de incidentes corretamente. Trata de
processar com mais eficincia certos tipos de
incidentes que so comuns. Desta forma os
incidentes podem ser resolvidos dentro dos prazos
acordados, uma vez que um processo padro para a
resoluo j existe.
Incidentes Graves: o ITIL recomenda procedimento
separado para tratar incidente grave, dada a
urgncia de sua resoluo.
Atividades do Gerenciamento de Incidentes:
1. Identificao: o processo iniciado somente
quando o incidente identificado.
2. Registro: todos os incidentes precisam ser
registrados em um sistema. O registro deve conter
data, hora e informaes relevantes.
3. Classificao: deve-se registrar todos os tipos de
chamada e classific-las. Esta classificao ser til
para o Gerenciamento de Problemas identificar
quais so os tipos de incidentes mais recorrentes.
4. Priorizao: priorizao determinado pelo
impacto e pela urgncia.
5. Diagnstico: o diagnstico inicial realizado pela
Central de Servios, que averigua preliminarmente
possveis causas para o incidente, bem como o que
no est funcionando adequadamente.
6. Escalao: se o incidente no puder ser resolvido
pela central de servios, ele ser escalado dentro
do tempo hbil para outro nvel de suporte com
maior capacidade.
7. Investigao e diagnstico: determina a natureza
da requisio. Quando o incidente tratado, cada
grupo de suporte investiga o que aconteceu de
errado e faz um diagnstico.
8. Resoluo e recuperao: identifica uma soluo,
a mesma deve ser aplicada e testada.
39

9. Fechamento: a central de servios dever

categorizar o motivo do incidente, documentar,
pedir para que o usurio responda a pesquisa de
satisfao e fazer o fechamento formal junto ao
mesmo.
Papel: gerente de incidente deve buscar eficincia
e eficcia do processo, produzir informaes
gerenciais, gerenciar o trabalho das equipes de
suporte nveis 1 e 2, gerenciar os incidentes graves
e desenvolver/manter o processo e respectivos
procedimentos.
Responsabilidades: Equipes de Suporte
Classificadas em nveis. O primeiro feito pela
Central de Servios e inclui registro, classificao,
escalao, resoluo e fechamento dos
incidentes. O segundo e terceiro nveis investigam,
diagnosticam, e recuperam dos incidentes. Os
grupos de segundo nvel so de maior
conhecimento tcnico sobre o assunto e o terceiro
nvel poder ser formado por fornecedores de
software ou hardware. Esse nveis podem variar
dependendo do tamanho da rea de TI.
5.1.2 [Ev] Gerenciamento de Eventos
Evento refere-se a qualquer ocorrncia identificvel
que seja significativa para a gesto da infraestrutura
de TI ou para a entrega do servio de TI. So
tipicamente notificaes criadas por um servio de
TI, item de configurao ou ferramenta de
monitorao, indicando uma alterao de estado.
Um evento pode indicar que algo no est
funcionando como deveria, levando ao registro de
um incidente. Mas tambm pode indicar atividade
normal de servio, ou a necessidade de uma
interveno de rotina, como a troca de uma fita de
backup, ou o fim da execuo de um job.
O Gerenciamento de Eventos depende do
monitoramento, mas diferente deste. O
gerenciamento de eventos gera e detecta
notificaes, enquanto o monitoramento verifica
continuamente o status dos itens de configurao e
ativos de servio mesmo quando nenhum evento
est ocorrendo.
Para que a operao de servio ocorra de modo
eficiente, deve conhecer a situao da
infraestrutura e detectar qualquer desvio da
operao comum. Os sistemas de monitorao e
controle, responsveis por essa deteco, so
baseados em dois tipos de ferramentas:
Ativas de monitorao que avaliam itens chave de
configurao para determinar sua situao e

disponibilidade. Qualquer exceo vai gerar um

alerta que precisa ser comunicado ferramenta ou
equipe apropriada para uma ao corretiva.
Ferramentas passivas de monitorao que apenas
detectam e correlacionam alertas operacionais ou
comunicaes geradas por itens de configurao.
O processo de gerenciamento de eventos
proporciona entradas para muitos processos e
atividades da Operao de Servio. Tambm
permite comparar o comportamento real com o
planejado nos padres de desenho e Acordos de
Nvel de Servio.
Este processo tambm inclui quaisquer aspectos do
gerenciamento de servio que precisem ser
controlados, tais como itens de configurao,
condies do ambiente, licenciamento de software,
etc.
Os Eventos so classificados como Informativos (ex:
o usurio fez logon), Alertas (ex: tempo de
transao est acima do normal) ou Excees (ex: o
servidor de rede respondeu de maneira
inesperada).
As atividades do fluxo de gerenciamento do evento
so: Notificao, Deteco, Filtro, Tratamento
(como incidente, como alerta ou como registro
simples), Aes de reviso e Fechamento.
Papel no necessrio um gerente de eventos,
pois muitas atividades so delegadas central de
servio e ao gerenciamento de operaes.
5.1.3 [Cump] Cumprimento de requisies:
Uma requisio de servio a requisio de um
usurio por informaes, ou por uma mudana
padro, ou por acesso a um servio de TI.
O propsito deste processo :
Permitir ao usurio requerer e receber servios
padronizados;
Fornecer e entregar esse servios;
Prover informaes aos usurios e clientes sobre
servios e procedimentos para obteno do que
desejam;
Oferecer suporte com informaes gerais,
reclamaes e sugestes.
Todas as requisies devem ser registradas e
rastreadas. O processo deve incluir aprovao
apropriada antes de cumprir a requisio.
Atividades:
Seleo de Menu: os usurios podem fazer
solicitaes usando ferramentas de Gerenciamento
de servio que possuem interfaces web. Nelas, o
usurio solicita o que precisa.
40

 Autorizao financeira: muitas requisies podem

ter implicaes financeiras. O custo de cada uma
deve ser determinado e pode-se limitar as
solicitaes de usurios para controlar o custo.
Cumprimento: a entrega do servio.
Geralmente a central de servio envolvida em
solues mais simples, enquanto mais complexas
so encaminhadas para
especialistas ou
fornecedores externos.
Concluso: uma vez completa, a Central de
Servio fecha o registro da requisio.
Papel: nenhum papel especfico aqui neste
processo, o cumprimento de requisies fica a
cargo da Central de Servios.
5.1.4 [Ace] Gerenciamento de Acesso:
O gerenciamento de acesso deve prover os
privilgios necessrios para usurios acessarem um
servio ou um grupo de servios. No mesmo
sentido, previne o acesso de usurios
no-autorizados.
O gerenciamento de acesso ajuda a gerenciar a
confidencialidade, disponibilidade e integridade dos
dados, alm da propriedade intelectual.
Este processo se preocupa com a identidade
(informao nica que distingue um indivduo) e
direitos (configuraes que fornecem acesso a
dados e servios).
O processo inclui verificar identidade, conceder
acesso a servios, registrar e rastrear acesso e
remover ou modificar direitos quando o status ou
os papis mudam.
Atividades:
Verificao da legitimidade das requisies:
verificar a cada requisio de servio se mesmo a
pessoa que est solicitando o acesso e se esta
pessoa tem uma motivos legtimos para usar o
servio.
Fornecer os direitos: Executa a poltica e as regras
definidas na Estratgia de Servio e Desenho de
Servio. Esta atividade no tem poder decisrio
sobre quem acessa a qual servio, apenas a
execuo da poltica.
Monitorar o status da identidade (mudana de
papis): caso um usurio mude de departamento,
seja demitido da empresa, promovido, etc, seu
perfil deve ser atualizado ou removido para
acompanhar esta mudana.
Registrar e monitorar o acesso: garante que os
direitos foram dados corretamente ao usurio, sem

se preocupar em responder s requisies de

acesso.
Remover e limitar direitos: assim como uma
atividade d o direito de acesso ao uso de um
servio, esta tambm responsvel por remover
estes direitos. Obviamente aqui tambm h apenas
a execuo, no a deciso para tal.
Papel: No h um papel especfico, uma vez que
este processo uma sobreposio do
Gerenciamento de Segurana e Disponibilidade.
Mesmo assim, os envolvidos so a Central de
Servio, o Gerenciamento Tcnico e de Aplicaes e
Gerenciamento de Operaes de TI.
5.1.5 [Prob] Gerenciamento de Problemas
Os objetivos deste processo so a preveno de
problemas e incidentes resultantes deles,
eliminando incidentes recorrentes e minimizando o
impacto de incidentes que no podem ser
prevenidos.
Os problemas so a causa de um ou mais
incidentes. Mesmo assim, um incidente nunca
vira problema: sempre h o registro dos dois
separados, um para cada processo.
Este processo tem a inteno de encontrar erros
conhecidos na infraestrutura de TI. O foco :
Encontrar qual o erro conhecido (diagnstico);
Identificar solues alternativas para a remoo
do erro conhecido (controle de erro);
Emitir uma requisio de mudana para requisitar
que a supresso ocorra;
Depois que a mudana feita, checar se o erro
conhecido foi removido.
A meta do processo gerenciar o ciclo de vida de
todos os problemas. O gerenciamento de problema
tambm pode ter um elemento proativo de
resoluo de problemas. A ideia identificar e
facilitar remoo de erros antes que eles se
manifestem como reclamaes ou perguntas de
usurios finais.
O processo, ainda, mantm informaes sobre
problemas e resolues, e solues de contorno
apropriadas para que a organizao seja capaz de,
com o tempo, reduzir o nmero de impacto de
incidentes, tendo forte interface com o
Gerenciamento do Conhecimento.
As atividades do gerenciamento de problema so
geralmente exercidas por times de suporte
avanados. A central de servios j cuida das
atividades de Incidente, portanto no tem
41

habilidade e tempo para investigar as causas-raiz.

Atividades:
Identificao
Registro
Categorizao
Priorizao
Investigao e diagnstico
Deciso sobre a soluo de contorno
Identificao de erros conhecidos
Resoluo
Concluso
Reviso
Correo de erros identificados
Papis: Gerente de Problema e Grupos de
Resolues de Problemas. O primeiro acompanha
os grupos de resolues de problemas para que
observem o ANS, alm de gerir o banco de dados de
erros conhecidos e o registro dos mesmos. O
segundo constitudo de grupos de suporte mais
tcnicos e avanados ou de fornecedores externos.
5.2 Funes da Operao de Servio:
Central de Servios (Service Desk): unidade
funcional que est envolvida em vrios eventos de
servio, como por exemplo atender a chamadas e
requisies.
Funciona como ponto nico de contato para
usurios no dia-a-dia. O foco principal dela
restabelecer o servio normal o mais rpido
possvel, envolvendo , inclusive, soluo de erros
tcnicos, cumprimento de requisio ou resposta a
dvidas. Possui quatro tipos, Local (atende a
unidade de negcio local), Centralizada (atende
todos em um nico local), Virtual (geograficamente
distante), Follow the Sun (combinao de centrais
dispersas geograficamente, oferecendo suporte 24h
a custo relativamente baixo). Os papis da central
de servios so gerente e supervisor da central de
servios, alm do analista de suporte (primeiro
nvel, no confundir com analistas de nvel
avanado!).
Gerenciamento Tcnico: inclui todas as pessoas
que fornecem expertise tcnico e fazem
gerenciamento da infraestrutura de TI. Ajuda a
planejar, implementar e manter uma infraestrutura
tcnica estvel e assegura que os recursos
requeridos e o expertise esto em posio de
desenhar, construir, fazer a transio, operar e

melhorar os servios de TI e a tecnologia que os

suporta.
Gerenciamento de Aplicaes: gerencia
aplicativos durante seu ciclo de vida. Sua funo
realizada por qualquer departamento, grupo ou
equipe envolvida na gesto e suporte de aplicativos
operacionais. Tem funo similar anterior, mas
com foco em aplicaes de software. Trabalha
prximo do desenvolvimento de software, mas
uma funo distinta e com papel diferente.
Gerenciamento de Operaes de TI: funo
responsvel pela gesto contnua e manuteno de
uma infraestrutura de TI de uma organizao, para
assegurar a entrega do nvel acordado entre TI e
negcio. Tem duas subfunes:
1. O controle de operaes, que tem equipe de
operadores
que
garantem
execuo
e
monitoramento das atividades operacionais e
eventos na infraestrutura jobs, impresso, backup
e restaurao;
2. O Gerenciamento de instalaes, que gerencia a
parte fsica do ambiente de TI data center, sites
de recovery, contratos de data center terceirizados,
etc.
Metodologias e documentos usados em teste de
software; conceitos bsicos de gerenciamento de
projeto (processos do PMBOK verso 4);
metodologias,
tcnicas
e
processos
de
desenvolvimento de sistemas orientados a
objetos; metodologias, tcnicas e processos de
desenvolvimento de sistemas web e web services;

TCNICAS DE TESTE DE SOFTWARE

A atividade de teste de software um elemento
crtico da garantia de qualidade de software e
representa a ltima reviso de especificao,
projeto e codificao. No incomum que uma
organizao de software gaste 40% do esforo de
projeto total em teste.Alguns casos dos quais
dependam vidas humanas (por exemplo, controle
de vo), pode custar de 3 a 5 vezes mais que todos
os outros passos de engenharia de software juntos.
FUNDAMENTOS DE TESTE DE SOFTWARE
A fase de teste gera bastante conflito entre os
engenheiros de software. A atividade de teste tem
a inteno de "demolir" o software que ele
construiu.
42

Os desenvolvedores de software so, por sua

prpria natureza construtivos, e para atividade de
teste eles devem descartar noes de "corretitude"
do software que eles acabaram de desenvolver, e
devem superar conflitos de interesse que ocorrem
quando erros so descobertos.
OBJETIVOS DA ATIVIDADE DE TESTE
1. A atividade de teste o processo de
executar um programa com a inteno de
descobrir um erro.
2. Um bom caso de teste aquele que tem
uma elevada probabilidade de revelar um
erro ainda no descoberto.
3. Um teste bem-sucedido aquele que revela
um erro ainda no descoberto.
Se a atividade de teste for conduzida com sucesso
ela
descobrir
erros
no
software.
Mas importante saber que " A atividade de teste
no pode mostrar a ausencia de bugs ; ela s pode
mostrar se defeitos de software esto presentes".
importante ter essa declarao em mente quando a
atividade de teste estiver sendo realizada.
PROJETO DE CASOS DE TESTE
Os projetos de casos de teste so construdos , para
ajudar a garantir a integridade dos testes e
proporcionar a mais alta probabilidade de revelar
erros no software.
Qualquer produto de engenharia pode ser tratado
de duas maneiras:
1. Conhecendo-se a funo especfica que um
produto projetado deve executar, testes
podem ser realizados para demonstrar que
cada funo totalmente operacional;
2. Conhecendo-se o funcionamento interno de
um produto, testes podem ser realizados
para garantir que "todas as engrenagem se
encaixam", ou seja, que a operao interna
do produto tem um desempenho de acordo
com as especificaes e que os
componentes
internos
foram
adequadamente postos prova.
Esses testes so chamados de teste da caixa preta e
teste da caixa branca.
TESTE DE CAIXA BRANCA
O teste da caixa branca usa a estrutura de controle
do projeto procedimental para derivar casos de

teste. O engenheiro de software pode derivar os

casos de teste que:
1. garantam que todos os caminhos
independentes dentro de um mdulo
tenham sido exercitados pelo menos uma
vez;
2. exercitem todas as decises lgicas para
valores falsos ou verdadeiros;
3. executem todos os laos em suas fronteiras
e dentro de seus limites operacionais;
4. e exercitem as estruturas de dados internas
para garantir a sua validade.
TESTE DE CAMINHO BSICO
uma tcnica de caixa branca , e possibilita que o
projetista do caso de teste derive uma medida da
complexidade lgica de um projeto procedimental e
use essa medida como guia para definir
um conjunto bsico de caminhos de execuo.
TESTE DE ESTRUTURA DE CONTROLE
Se divide em vrios testes , dentre os quais
merecem destaque:
1. Teste de condio
um mtodo que pe a prova as condies
lgicas contidas num mdulo de programa.
Ele concentra-se em testar cada condio do
programa.
O propsito do teste de condio detectar
no somente erros nas condies de um
programa, mas tambm outros erros no
programa.
O teste de ramos e teste de domnio so
exemplos de estratgias de teste de
condio.
2. Teste de fluxo de dados
O mtodo de teste de fluxo de dados
seleciona caminhos de teste de um
programa de acordo com as localizaes das
definies e usos de variveis no programa.
As estratgias de fluxo de dados so teis
para selecionar caminhos de teste de um
programa que contenha instrues de laos
e if aninhadas.
3. Teste de laos (LOOPS)
Os laos so o fundamento para grande
maioria
de
todos
os
algoritmos
implementados no software. O teste de
laos se concentra exclusivamente na
validade das construes de laos. Quatro
43

diferentes classes de laos podem ser

definidas:
o Laos Simples
o Laos Aninhados
o Laos Concatenados
o Laos No-estruturados
TESTE DE CAIXA PRETA
Os mtodos de caixa preta concentram-se nos
requisitos funcionais do software.O engenheiro de
software pode derivar conjunto de condies de
entrada que exercitem completamente todos os
requisitos funcionais para um programa.
O teste de caixa preta procura descobrir erros nas
seguintes categorias:
1. funes incorretas ou ausentes;
2. erros de interfeace;
3. erros nas estruturas de dados ou no acesso
a banco de dados externos;
4. erros de desempenho;
5. e erros de inicializao e trmino.
O teste de caixa preta tende a ser aplicado durante
as ltimas etapas da atividade de teste. Ele se
concentra no domnio de informao. Testes so
projetados para responder s seguintes perguntas:
Como a validade funcional testada ?
Quais classes de entrada constituiro bons
casos de teste ?
O sistema particularmente sensvel a
certos valores de entrada ?
Como as fronteiras de uma classe de dados
so isoladas ?
Quais ndices de dados e volumes de dados
o sistema pode tolerar ?
Que efeito tero combinaes especficas de
dados sobre a operao do sistema ?
Alguns mtodos de Caixa preta sero abordados
agora :
1. Particionamento de equivalncia
Divide o domnio de entrada de um
programa em classe de dados a partir das
quais os casos de teste podem ser
derivados.
O
particionamento
de
equivalncia procura definir um caso de
teste que descubra classes de erros, assim
reduzindo o nmero total de casos de teste
que devem ser resolvidos.
O projeto de casos de teste para o
particionamento de equivalncia baseia-se

numa avaliao de classes de equivalncia

para uma condio de entrada. Uma classe
de equivalncia representa um conjunto de
estados vlidos ou invlidos para condies
de entrada. As classes de equivalncia
podem ser definidas de acordo com as
seguintes diretrizes:
1. Se uma condio de entrada
especificar um intervalo, uma classe
de equivalncia vlida e duas classes
de equivalncia invlidas so
definidas.
2. Se uma condio de entrada exigir
um valor especfico, uma classe de
equivalncia vlida e duas classes de
equivalncia invlidas so definidas.
3. Se uma condio de entrada
especificar
um
membro
de
um conjunto,
uma
classe
de
equivalncia vlida e uma classe de
equivalncia invlida so definidas.
4. Se uma condio de entrada
for booleana, uma classe vlida e
uma invlida so definidas.
Aplicando-se as diretrizes para derivao de
classes de equivalncias, os casos de testes
para cada item de dados do domnio de
entrada poderiam ser desenvolvidos e
executados. Os casos de teste so
selecionados de forma que o maior nmero
de atributos de uma classe de equivalncia
seja exercitado de uma s vez.
2. Anlise de valor limite
Um nmero maior de erros tende a ocorrer
nas fronteiras do domnio de entrada do que
no "centro". Por isso que a anlise do valor
limite foi desenvolvida como uma tcnica de
teste. Os testes pem a prova os valores
fronteirios. Essa tcnica complementa o
particionamento de equivalncia, e sob
muitos aspectos as diretrizes se assemelham
quelas
apresentadas
para
o
particionamento de equivalncia:
1. Se uma condio de entrada
especificar um intervalo, delimitado
pelos valores a e b, os casos de teste
devem
ser
projetados
com
valores a e b logo acima e logo
abaixo de a e b, respectivamente.
44

2. Se uma condio de entrada

especificar uma srie de valores os
casos de teste que ponham prova
nmeros mximos e mnimos devem
ser desenvolvidos. Valores logo
acima e logo abaixo do mnimo e do
mximo tambm so testados.
3. Aplique as diretrizes 1 e 2 s
condies de sada. Por exemplo,
suponhamos que uma tabela de
temperatura versus presso
seja
exigida como sada de um programa
de anlise de engenharia. Os casos
de teste devem ser projetados para
criar um relatrio de sada que
produza um nmero mximo (e
mnimo) permissvel de entradas na
tabela.
4. Se estruturas internas de dados do
programa
tiverem
prescrito
fronteiras , certifique-se de projetar
um caso de teste para exercitar a
estrutura de dados em sua fronteira.
3. Tcnicas de grafo de causa-efeito
O grafo de causa-efeito, uma tcnica de
projetos de caso de teste que oferece uma
uma representao concisa das condies
lgicas e das aes correspondentes. A
tcnica segue quatro passos:
1. Causas (condies
de
entrada)
e efeitos (aes) so relacionados
para um mdulo e um identificador
atribudo para cada um.
2. Um grafo de causa efeito
desenvolvido.
3. O grafo convertido numa tabela de
deciso.
4. As regras da tabela de deciso so
convertidas em casos de teste.
4. Testes de comparao
Usa-se quando a confiabilidade do software

absolutamente
crtica.
alguns
pesquisadores tem sugerido que verses
independentes
de
software
sejam
desenvolvidas para aplicaes crticas ,
mesmo quando uma nica verso for usada
no
sistema
copmputadorizado
entregue.Essas verses independentes
formam a base de uma tcnica de teste de

caixa
preta
denominada teste
de
comparao ou teste back-to-back.
O mtodo de comparao no infalvel. Se
a especificao a partir da qual todas as
verses foram desenvolvidas estiver errada,
provavelmente todas as verses refletiro o
erro. Alm disso, se cada uma das verses
independentes
produzir
resultados
idnticos, mas incorretos, os testes de
condies deixaro de detectar o erro.
5. Testes de sistemas de tempo real
Mtodos de projetos de caso de teste
abrangente para sistemas de tempo real
ainda precisam ser desenvolvidos. Porm
uma estratgia global de qutro passos pode
ser proposta:
1. Teste de tarefas. O primeiro passo da
atividade de testes de softwares de
tempo real consiste em testar cada
tarefa independentemente. Ou seja,
testes de caixa preta e de caixa
branca so projetados e executados
para cada tarefa. Cada tarefa
executada
independentemente
durante esses testes. O teste de
tarefas revela erros de lgica e de
funo, mas no revelar erros
comportamentais ou de timing.
2. Teste comportamental.
Usando
modelos de sistemas criados com as
ferramentas CASE, possvel simular
o comportamento de um sistema de
tempo real e examinar seu
comportamento
como
uma
consequncia de eventos externos.
Essas atividades de anlise podem
servir como a base para o projeto de
casos de teste que ser realizado
quando o software de de tempo real
for construdo.
3. Teste intertarefas. Assim que os
erros em tarefas individuais e no
comportamento de sistema tiverem
sido isolados , a atividade de teste
desvia-se para erros relacionados ao
tempo. As tarefas assncronas, que
sabidamente comunicam-se entre s ,
so testadas com diferentes taxas de
dados e cargas de processamento
para determinar se ocorrero erros
45

de sincronizao intertarefas. alm

disso, as tarefas que se comunicam
por intermdio de uma fila de
mensagens so testadas para
descobrir erros na determinao do
tamanho
dessas
reas
de
armazenagem de dados.
4. Teste do sistema. O software e o
hardware so integrados e uma
variedade completa de de testes de
sistema levada a efeito, numa
tentativa de descobrir erros na
interface software/hardware.
FERRAMENTAS DE TESTE AUTOMATIZADAS
Uma vez que o teste de software frequentemente
responsvel por at 40% de todo o esforo
despendido num projeto de desenvolvimento de
software, as ferramentas que podem reduzir o
tempo de teste so muito valiosas.Muitas
ferramentas de teste foram desenvolvidas e elas
podem ser divididas em uma srie de categorias:
Analisadores estticos. Esses sistemas de
anlise de programa suportam a
"comprovao" de afirmaes estticas afirmaes fracas sobre a estrutura e o
formato de um programa.
Auditores de cdigo. Esses filtros de
propsito especial so usados para verificar
a qualidade do software, a fim de garantir
que ele atenda aos padres mnimos de
codificao.
Processadores de assero. Esses sistemas
pr-processadores/ps-processadores so
empregados para dizer se as afirmaes
fornecidas
pelo
programador,
denominadas asseres,
sobre
o
comportamento de um programa so de
fato cumpridas durante as execues reais
do programa.
Geradores de arquivos de teste. Esses
processadores geram, e preenchem com
valores previamente determinados, arquivos
de entrada tpicos para programas que esto
em teste.
Geradores de dados de teste. Esses sistemas
de anlise automatizados auxiliam o usurio
a selecionar dados de teste que fazem um
programa comportar-se de uma forma
particular.

Verificadores de teste. Essas ferramentas

medem a cobertura interna dos testes,
frequentemente expressa em termos que
esto relacionados estrutua de controle do
objeto de teste, e relatam o valor da
cobertura ao especialista em garantia da
qualidade.
Bancadas de teste (Teste Harnesses). Essa
classe
de
ferramentas
apia
o
processamento de testes, tornando-se
quase indolor para :
1. instalar um programa candidato num
ambiente de teste;
2. aliment-lo com dados de entrada;
3. Com uso de stubs o comportamento
de
mdulos
subsidirios
(subordinados).
Comparadores de sada. Esta ferramenta
torna possvel a comparao de um
conjunto de sadas de um programa com
outro conjunto (previamente arquivado)
para determinar a diferena entre eles.
Sistemas de execuo simblica. Essa
ferramenta realiza testes de programas
usando entrada algbrica, em vez de valores
de dados numricos. O software que
testado, parece desse modo testar classes
de dados, em vez de ser um teste de caso
especfico. A sada algbrica e pode ser
comparada com os resultados esperados
que so especificados algebricamente.
Simuladores de ambiente. Essa ferramenta
um sistema computadorizado especializado
que possibilita que o analista modele o
ambiente externo do software de tempo
real e depois simule dinamicamente as
condies operacionais reais.
Analisadores de fluxo de dados. Essa
ferramenta rastreia o fluxo de dados
mediante um sistema e tenta descobrir
referncias a dados, indexao incorreta e
outros erros relacionados a dados.
O uso atual no definido de ferramentas
automatizadas para teste vem crescendo, e
provavel que a aplicao se acelere durante a
prxima dcada. Provavelmente, as descendentes
das ferramentas de teste da primeira gerao
provocaro mudanas radicais na maneira como
testamos softwares e , ento, melhoraro a
46

confiabilidade
computador.

dos

sistemas

baseados

em

RESUMO
O objetivo principal do projeto de casos de teste
derivar um conjunto de teste que tenham alta
probabilidade de revelar defeitos no software. Para
atingir esse objetivo, duas categorias diferentes de
tcnicas de projeto de caso de teste so usadas:
O teste de caixa preta e o teste de caixa branca.
Os teste de caixa branca focalizam a estrutura de
controle do programa. Os casos de teste so
derivados para garantir que todas as instrues do
programa tenham sido exercitadas pelo menos uma
vez durante os testes e que todas as condies
lgicas tenham sido exercitadas. Os testes de
caminho bsico , uma tcnica de caixa branca, faz
uso de grafos de programa para derivar o conjunto
de testes linearmente independentes que garantir
cobertura. Os testes de fluxo de dados e das
condies pem prova lgica do programa, e os
testes de laos complementam outras tcnicas de
caixa branca ao proporcionar um procedimento
para exercitar laos de vrios graus de
complexidade.
Os teste de caixa branca so "testes em pequeno
porte" (testing in the small). A implicao dessa
colocaxo que os teste de caixa branca so
tipicamente aplicados a componentes de
programas pequenos (Os mdulos). Os testes de
caixa preta, por outro lado, ampliam o nosso foco e
poderiam ser denominados "testes em grande
porte" (testing in the large ).
Os testes de caixa preta so projetados para validar
os requisitos funcionais, sem se preocupar com o
funcionamento interno de um programa. As
tcnicas de teste de caixa preta concentram-se no
domnio de informaes do software, derivando os
casos de teste ao dividir a entrada e a sada de uma
maneira que proporcione uma satisfatria
cobertura de teste. O particionamento de
equivalncia divide o domnio de entrada em
classes de dados que provavelmente exercitaro
uma funo de software especfica. A anlise do
valor de fronteira prova a capacidade que um
programa tem de manipular dados nos limites da
aceitabilidade. o grafo de causa-efeito uma
tcnica que possibilita que o analista valide
conjuntos complexos de aes e condies.

Os
projetistas
de
softwares
experientes
frequentemente dizem: " a atividade de teste nunca
termina; ela apenas transferida do projetista para
o seu cliente. toda vez que o seu cliente usa o
programa, um teste realizado". Ao aplicar o
projeto de casos de teste, o engenheiro de software
pode realizar testes mais completos e, portanto,
descobrir e corrigir o maior nmero de erros
possveis antes que os "testes do cliente" se
iniciem.
Fudamentos da engenharia de software

A metodologia do teste de software se reflete

atualmente no comportamento das empresas na
busca em implantar ou mesmo melhorar o processo
de teste utilizado. Ainda que as tcnicas de teste de
software mais utilizadas foram criadas por volta dos
anos 70, as empresas tm uma grande dificuldade
com a atividade de teste. Isto pode ser um reflexo
da falta de profissionais especializados na rea de
teste de software ou mesmo da dificuldade em
implantar um processo de teste utilizando as
tcnicas existentes na literatura.
Neste contexto, o CenPRA desenvolveu uma
metodologia para implantao ou melhoria do
processo de teste em empresas desenvolvedoras de
software. Este artigo apresenta consideraes
sobre teste no contexto da qualidade de software,
uma viso geral e resumida da metodologia
desenvolvida, uma aplicao prtica desta
metodologia e concluses.
2. Teste e Qualidade de Software
Existem vrias tentativas no sentido de definir a
atividade de teste, desde a viso intuitiva sobre
teste at uma definio formal [1, 2, 3]. Todas as
afirmaes, sejam intuitivas ou formais,
generalizam uma idia sobre o que teste de
software e essencialmente conduzem ao mesmo
conceito: Teste de software o processo de
executar o software de uma maneira controlada
com o objetivo de avaliar se o mesmo se comporta
conforme o especificado.
Devido a algumas caractersticas prprias do
software como flexibilidade para mudanas,
complexidade e intangibilidade, o teste no uma
tarefa trivial. A dificuldade em testar software
caracterizada por alguns pontos importantes
como: o teste de software um processo caro;
47

existe uma falta de conhecimento sobre a relao

custo/benefcio do teste; h falta de profissionais
especializados na rea de teste; existem
dificuldades em implantar um processo de teste; h
o desconhecimento de um procedimento de teste
adequado; h o desconhecimento de tcnicas de
teste adequadas; h o desconhecimento sobre
como planejar a atividade de teste; e
finalmente, a preocupao com a atividade de teste
somente na fase final do projeto.
Deve ser ressaltado que a atividade de teste exige
conhecimento, planejamento, projeto, execuo,
acompanhamento, recursos e tambm uma grande
interao com as outras equipes.
Na elaborao do planejamento do teste, uma das
etapas a elaborao da estratgia de teste. A
estratgia de teste compreende a definio dos
seguintes itens: O nvel de teste, isto , a definio
da fase do desenvolvimento do software em que o
teste ser aplicado; A tcnica de teste a ser
utilizada; O critrio de teste a ser adotado; O tipo
de teste a ser aplicado no software.
O nvel de teste depende da fase do
desenvolvimento do software em que o teste
poder ser aplicado, compreendendo a codificao
dos mdulos do sistema Teste de Unidade; a
integraodos mdulos do sistema - Teste de
Integrao; atendimento aos requisitos funcionais e
no funcionais do sistema Teste de Sistema;
aceitao do sistema pelo usurio
Teste de Aceitao; e, finalmente, o Teste de
Regresso que aplicado na fase de manuteno
do sistema.
Geralmente a definio da fase do desenvolvimento
do sistema em que sero aplicados os testes
depende da poltica de teste da empresa. Por
exemplo, uma empresa poder adotar a poltica de
fazer somente o teste de sistema, ou seja, aplicar o
Teste de Sistema depois que os mdulos estiverem
todos j integrados e no aplicar o Teste de
Unidade e Teste de Integrao.
A escolha da tcnica de teste depende tambm da
fase de desenvolvimento em que o teste ser
aplicado. Uma tcnica de teste direciona a escolha
de critrios para gerao de casos de teste que, ao
serem executados, vo exercitar os elementos
requeridos pela abordagem do teste.
Existem, basicamente duas tcnicas de teste: Teste
Estrutural - tcnica de teste que adota critrios para

a gerao dos casos de teste com a finalidade de

identificar defeitos nas estruturas internas do
software, atravs de situaes que exercitem
adequadamente todas as estruturas utilizadas na
codificao; Teste Funcional - tcnica de teste que
adota critrios para a gerao dos casos de teste
com a finalidade de garantir que os requisitos do
software que foi construdo sejam plenamente
atendidos.
Ao se adotar uma tcnica de teste (Funcional ou
Estrutural) necessrio escolher um critrio para a
elaborao dos casos de teste com a finalidade de
testar os elementos do software. Normalmente os
elementos de um software que podem ser testados
so: as linhas de comando; as funes
implementadas; as variveis definidas no software;
os loops existentes no software; todos os ramos de
uma deciso; e os requisitos do software.
O critrio de teste serve para orientar o testador na
gerao dos casos de teste. Os elementos
requeridos de um critrio de teste so os elementos
ou as caractersticas do software que devero
ser exercitados quando o software for testado. Os
casos de teste gerados devem exercitar os
elementos ou as caractersticas do software
definidos por aquele critrio.
Os tipos de teste referem-se s caractersticas do
software que podem ser testadas, e compreende:
Teste de Funcionalidade; Teste de Interface; Teste
de Desempenho; Teste de Carga (Stress); Teste de
Usabilidade; Teste de Volume; Teste de Segurana.
A Figura 1 ilustra graficamente a ligao existente
entre os nveis de teste, as tcnicas de teste, os
tipos de teste e os critrios de teste que podem ser
adotados ao se definir uma estratgia de teste.
3. Metodologia de Teste
O Centro de Pesquisas Renato Archer CenPRA,
tem sido procurado por empresas desenvolvedoras
de software e mesmo rgos do governo para
realizar projetos dentre os quais a atividade de
teste tem seu lugar de destaque.
Visando atender as necessidades dessas empresas o
CenPRA, atravs do grupo de teste da Diviso de
Melhoria de Processos de Software - DMPS,
desenvolveu um projeto que teve como
objetivo criar uma metodologia para a introduo
ou melhoria do processo de teste de software em
empresas produtoras de software, englobando
tcnicas, procedimentos e ferramentas,
48

capacitando-as a desenvolver produtos de melhor

qualidade[4, 5]. A metodologia est fundamentada
na adoo de um processo de teste e nos artefatos
sugeridos pela Norma IEEE
829-1998 [6], que descreve os documentos que
devem ser gerados na atividade de gerncia do
teste de software. A metodologia de teste foi
projetada e desenvolvida de uma forma que as
empresas pudessem instanciar o processo de teste
de
acordo
com as
suas
necessidades
edisponibilidade de recursos. Alm disso, a
metodologia de teste pode ser aplicada a qualquer
tipo de software, seja ele sistema de informaes
ou software cientfico. Nesta metodologia, a
implantao do processo de teste envolve um
conjunto de atividades que vai desde o
levantamento das necessidades da empresa, passa
pela realizao de treinamentos da equipe tcnica e
vai at ao acompanhamento dos trabalhos
realizados, constituindo assim, um completo ciclo
de implantao da atividade de teste dentro da
empresa.

Figura 1 Relao entre nveis, tipos e tcnicas de

teste
A metodologia, que preconiza a realizao de testes
sistemticos, pode ser empregada tanto por
empresas que desenvolvem quanto por empresas
que adquirem software, e est dividida em 3
componentes: Treinamento, Processo de Teste e
Suporte para Gerao de Documentos:
1. Treinamento: Atravs de cursos, consiste da
capacitao em conceitos bsicos sobre teste de
software, tcnicas de teste, documentao de teste
e processo de teste. Estes cursos esto
divididos em mdulos e sua aplicao pode ser
adaptada s necessidades especficas de cada
empresa.

2. Processo de Teste: A metodologia define um

processo genrico de teste que prev a realizao
das atividades de planejamento, projeto, execuo
e acompanhamento dos testes de unidade,
integrao, sistemas e aceitao. A partir deste
processo genrico cada empresa deve instanciar
um processo especfico que melhor atenda suas
necessidades.
3. Suporte para Gerao de Documentos: Consiste
da aplicao de uma tcnica para a criao de
documentos que sero utilizados para a gerncia do
processo de teste, tanto na fase de
preparao para a atividade de teste quanto na fase
de registro dos resultados do teste. Este
componente da metodologia est baseado na
Norma IEEE 829-1998, que descreve um conjunto
de 8 documentos que cobrem as tarefas de
planejamento, especificao e registro.
Critrios das atividades de teste de um produto de
software. Esta norma pode ser usada para o teste
de qualquer tipo de software, seja ele comercial,
cientfico ou militar, sendo definida de forma
independente de tcnicas, mtodos, estratgias,
recursos e ferramentas de teste.
O processo de teste instanciado pode ser
considerado como o processo de teste empregado
de forma global para todos os projetos da
organizao ou especificamente para cada um de
seus projetos. A seo do Plano de Teste que trata a
estratgia a ser empregada em cada projeto deve
fazer referncia ao processo empregado.
O processo de teste proposto na metodologia est
baseado em alguns pressupostos bsicos:
- Os testes de sistema e aceitao so projetados e
executados sob a responsabilidade da equipe de
teste.
- Os testes de sistema, e eventualmente tambm o
de aceitao, so realizados de forma iterativa,
havendo, antes do incio de cada ciclo de teste, uma
avaliao rpida do produto.
O processo de teste no contempla automao do
teste, medida tomada para manter a descrio
inicial do processo simples.
Uma organizao pode adotar outros pressupostos,
devendo realizar as alteraes necessrias no
processo de teste instanciado.
Uma premissa bsica da metodologia de teste
proposta que o processo de teste, quando
adequadamente definido, pode ter um impacto
49

positivo nos resultados de diversas outras

atividades de desenvolvimento. Desta forma, o
enfoque das atividades de teste no somente
identificar problemas, mas principalmente prevenir
problemas. Estas premissas esto presentes em
diversas referncias sobre teste preventivo [1, 7].
O fato do processo genrico proposto no
contemplar a automao de teste reflete a viso de
que um processo s deve ser suportado por
ferramentas quando estiver convenientemente
definido e consistentemente adotado. Zallar afirma
que o processo de automao de teste tem maior
probabilidade de ser bem sucedido para
organizaes que possuam uma equipe de teste
bem definida e com um processo padro de
documentao seguido [8].
3.1 Viso Geral da Norma IEEE 829
A Norma IEEE 829 descreve um conjunto de
documentos para as atividades de teste de um
produto de software.
Os 8 documentos definidos pela norma, que
cobrem as tarefas de planejamento, especificao e
relato de testes, so apresentados a seguir.
Plano de Teste Apresenta o planejamento para
execuo do teste, incluindo a abrangncia,
abordagem, recursos e cronograma das atividades
de teste. Identifica os itens e as funcionalidades a
serem testados, as tarefas a serem realizadas e os
riscos associados com a atividade de teste.
A tarefa de especificao de testes coberta pelos
3 documentos seguintes.
Especificao de Projeto de Teste Refina a
abordagem apresentada no Plano de Teste e
identifica as funcionalidades e caractersticas a
serem testadas pelo projeto e por seus testes
associados. Este documento tambm identifica os
casos e os procedimentos de teste, se existirem, e
apresenta os critrios de aprovao.Especificao
de Caso de Teste Define os casos de teste,
incluindo dados de entrada, resultados esperados,
aes e condies gerais para a execuo do teste.
Especificao de Procedimento de Teste
Especifica os passos para executar um conjunto de
casos de teste.
Os relatrios de teste so cobertos pelos 4
documentos seguintes.
Dirio de Teste - Apresenta registros cronolgicos
dos detalhes relevantes relacionados com a
execuo dos testes.

Relatrio de Incidente de Teste - Documenta

qualquer evento que ocorra durante a atividade de
teste e que requeira anlise posterior.
Relatrio-Resumo de Teste Apresenta de forma
resumida os resultados das atividades de teste
associadas com uma ou mais especificaes de
projeto de teste e prov avaliaes baseadas
nesses resultados.
Relatrio de Encaminhamento de Item de Teste
Identifica os itens encaminhados para teste no caso
de equipes distintas serem responsveis pelas
tarefas de desenvolvimento e de teste.
A norma separa as atividades de teste em trs
etapas: preparao do teste, execuo do teste e
registro do teste. A Figura 2 - Relacionamento entre
os Documentos de Teste - mostra os documentos
que so produtos da execuo de cada uma das
fases e os relacionamentos entre eles.
Embora a norma possa ser utilizada para o teste de
produtos de software de qualquer tamanho ou
complexidade, projetos pequenos ou de baixa
complexidade podem agrupar alguns documentos
propostos, diminuindo o gerenciamento e os custos
de produo dos documentos.
Alm disso, o contedo dos documentos tambm
pode ser abreviado.
Adicionalmente, a equipe responsvel pelo teste
dever tomar outras decises em relao
aplicao da norma em projetos especficos,
decidindo, por exemplo, se mais conveniente
elaborar um nico plano que englobe os testes de
unidade, integrao e aceitao, ou um plano para
cada uma das fases de teste citadas.
Mais do que apresentar um conjunto de
documentos, que deve ser utilizado ou adaptado
para determinadas empresas ou projetos, a norma
apresenta um conjunto de informaes necessrias
para o teste de produtos de software. Sua correta
utilizao auxiliar a gerncia a se concentrar tanto
com as fases de planejamento e projeto quanto
com a fase de realizao de testes propriamente
dita, evitando a perigosa armadilha de s iniciar a
pensar no teste de um produto de software aps a
concluso da fase de codificao.
3.2 Suporte Implantao do Processo de Teste
de Software
As normas de engenharia de software normalmente
so genricas e demandam um esforo adicional
para serem utilizadas com sucesso. Para facilitar a
50

utilizao da Norma IEEE-829 a metodologia de

teste prope um mtodo para a implantao do
processo de teste de software. Os documentos
descritos nesta seo: Guia para Elaborao de
Documentos de Teste de Software [9] e Processos
para Elaborao de Documentos de Teste de
Software [10], formam a base da metodologia
proposta.

3.2.1 - Guia para Elaborao de Documentos de

Teste de Software
Esse documento tem o propsito de servir como
referncia para a criao dos documentos de teste
baseados na Norma IEEE 829, tanto na fase de
preparao para a atividade de teste quanto na fase
de registro dos resultados do teste. O enfoque
principal deste guia situa-se na obteno do
contedo de cada documento de teste.
3.2.2 - Processos para a Elaborao de Documentos
de Teste de Software
Este documento apresenta os processos para a
elaborao dos documentos de teste de Software
baseados na Norma IEEE 829. Os processos
abrangem a preparao, a execuo e o registro dos
resultados do teste e esto descritos segundo o
Handbook for Process Management, [11].
Esses processos estabelecem uma orientao geral
e, se necessrio, podem ser modificados para
adequar-se
s
situaes
particulares
de
organizaes envolvidas nas atividades de teste.
Um processo definido para cada documento da
norma, segundo a seguinte estrutura:
1. Funes e responsabilidades no processo
participantes na execuo das tarefas;

2. Critrios para o incio do processo elementos

e/ou condies necessrios para iniciar a execuo
das tarefas;
3. Entradas do processo dados, recursos ou
ferramentas necessrios para a execuo das
tarefas;
4. Tarefas do processo aes necessrias para
produzir as sadas do processo. Para cada tarefa so
identificadas suas entradas, com indicao de
possveis fontes, e as sadas produzidas. Aordem de
apresentao
das
tarefas
no
reflete
necessariamente a seqncia em que devem ser
executadas;
5. Sadas do processo dados ou produtos gerados
pela execuo das tarefas;
6. Critrios para trmino do processo elementos
e/ou condies necessrios para encerrar a
execuo das tarefas; e 7. Medies do processo
medidas a serem coletadas como parte da execuo
das tarefas.
Dependendo do domnio da aplicao, da estratgia
ou da fase de teste, os processos podem ser
adaptados de modo a produzir um conjunto maior
ou menor de documentos. Contudo, os documentos
de preparao para o teste devem incluir: o
planejamento do teste, o projeto do teste, os casos
de teste e os procedimentos de teste. Alm disso,
os resultados do teste bem como os incidentes
ocorridos durante a execuo do teste devem ser
adequadamente registrados e condensados num
relatrio final.
Se necessrio, as tarefas ou passos dos processos
podem ser estendidos para incluir aes adicionais
que podem, eventualmente, resultar em novos
documentos e/ou formulrios.
Os documentos e os processos neles descritos
podem ser aplicados a diversos domnios de
aplicao (comercial, cientfico, etc.), no estando
restrita a sua utilizao a tamanho,
complexidade ou criticalidade do software; podem
ser usados para todas as fases de teste, desde o
teste de unidade at os testes de aceitao e de
regresso.
4 Aplicao da Metodologia de Teste
Como parte da experimentao e validao da
metodologia de teste, foi realizado um projeto de
melhoria de processo em uma micro empresa
desenvolvedora de software.
4.1. Contexto
51

A empresa na qual a metodologia foi aplicada

uma pequena empresa de desenvolvimento de
projetos de software, fundada em 1995 e instalada
em Campinas, SP, nas proximidades da
Universidade de Campinas (UNICAMP), no distrito
de Baro Geraldo. Esta empresa tem, desde o incio
de suas atividades, como foco principal o
desenvolvimento de projetos de software. Esta rea
representa cerca de 90% de seu faturamento
mensal. Os seus clientes so, em sua maioria,
grandes empresas, multinacionais em muitos casos.
Os projetos tm entre 2 e 6 meses de durao e
envolvem entre 2 e 4 profissionais.
Neste projeto de melhoria foram tratados vrios
processos, incluindo o processo de teste. O projeto
de melhoria seguiu a Abordagem de Melhoria de
Processo do CenPRA [12]. Esta abordagem suporta
a escolha de diferentes modelos de referncias e
diferentes metodologias para a melhoria de
processos especficos. Neste projeto, por exemplo,
foi utilizado o modelo de processo da ISO/IEC TR
15504-5 [13] como referncia e duas metodologias
para dois processos especficos: a metodologia
baseada no ProGer para o processo de gerncia de
projeto e a metodologia de teste do CenPRA para o
processo de teste. ProGer um modelo de
processo para gerenciamento de projetos para
organizaes de desenvolvimento de software de
pequeno porte [14].
O projeto foi iniciado em Janeiro de 2002. Seguindo
a Abordagem de Melhoria de Processo do CenPRA,
o projeto foi executado em seis fases seqenciais:
(1) Incio dos Trabalhos eDefinio de Metas, (2)
Avaliao das Prticas Correntes, (3) Planejamento
das Aes de Melhoria, (4) Implantao das Aes
de Melhoria, (5) Verificao dos Resultados e
Aprendizado, e (6) Institucionalizao da Melhoria.
A primeira fase foi composta pela elicitao do
negcio da empresa, estratgias e objetivos.
A escolha da ISO/IEC TR 15504 se deu devido
flexibilidade para adaptaes s necessidades da
empresa. Decidiu-se utilizar cinco processos da
futura norma, para o Nvel 2 de capacidade.
Os processo escolhidos foram: CUS.2 Supply
(Fornecimento), CUS.3 Requirement Elicitation,
(Elicitao de Requisitos) MAN.2 Project
Management (Gerncia de Projeto), ENG.1.6
Software Test (Teste de Software) e ORG.5
Measurement (Medio). Estes processos foram

selecionados de forma a cobrir as necessidades de

melhoria de processo da empresa.
Uma equipe do CenPRA realizou a avaliao para
estes cinco processos, at o Nvel 3 de capacidade,
para descobrir as prticas utilizadas. A avaliao foi
feita de acordo com o mtodo de avaliao criado
pelo CenPRA. Os resultados indicaram Nvel 2 de
capacidade para ORG.5
Measurement e Nvel 1 para os outros.
Aps a avaliao foram realizadas as outras fazes do
projeto. Uma descrio mais detalhada deste
projeto de melhoria e de resultados preliminares
foram apresentados e discutidos em outras
conferncias da rea [15, 16]. Este artigo foca
apenas a experimentao e validao da
metodologia de teste.
4.2. Situao Atual
Atualmente existe uma prtica institucionalizada na
Empresa de planejamento e execuo sistemtica
de teste de sistema, como parte do processo de
desenvolvimento de software da empresa.
O fluxograma da Figura 3 descreve uma
representao dos elementos principais do
processo de teste e seu relacionamento com o
processo de desenvolvimento de software,
conforme a sua execuo na Empresa.
O processo de teste parte de uma proposta tcnica
(PPT) bastante detalhada, que associada a um plano
de projeto (PP) previamente elaborado, permitem a
criao de um plano de teste (PLT).
Dependendo do projeto e nvel de exigncia do
cliente, este deve aprovar o plano de teste.
Alm de aprovar o plano, o cliente deve se envolver
tambm em sua elaborao, por exemplo atravs
da identificao de critrios de teste.
Aps a elaborao do plano de teste (a partir de
definio tambm deste plano), opta-se, em funo
do tamanho e riscos associados ao projeto, pela
elaborao ou no do documento projeto de teste
(PRT), que pode iniciar em paralelo ou aps a
criao do documento de detalhamento de
requisitos (DR).
Com o detalhamento de requisitos (DR) finalizado,
elabora-se
um
documento
condensando
informaes sobre casos e procedimentos de teste
(CPT), e eventualmente (na ausncia de um PRT),
questes gerais do projeto de teste, como
abordagem do teste por funcionalidade, critrios de
aprovao e rejeio, entre outros. Neste ponto o
teste est pronto para ser executado.
52

Figura 3: Processo de teste e seu relacionamento

com o processo de desenvolvimento.
As tarefas de detalhamento de teste correm
simultaneamente
com
a
implementao
(codificao) do novo produto de software gerado
ou da nova verso contendo melhorias em um
software pr-existente.
Assim que uma verso do software liberada pela
equipe de programao, a equipe de teste executa
os casos de teste previstos e retorna, via relatrio
de incidentes de teste (RIT), os
problemas detectados equipe de programao,
que dever corrigi-los.
As novas verses, possivelmente geradas a partir do
relatrio de incidentes de teste, retornam etapa
anterior, com definio do gerente de teste sobre
os casos de teste que devero ser re-executados
at que se tenha um produto considerado
adequado para a instalao, conforme deciso do
lder do projeto.
Ainda, durante a execuo do teste a equipe de
teste gera um documento detalhado sobre a
execuo do teste, denominado dirio de teste
(DIT). Este documento, permite a gerao de
anlises bem fundamentadas no momento da
criao do resumo do teste (RRT), gerado

normalmente aps a instalao do software

aprovado no cliente.
Este documento mostra o esforo necessrio para
preparao e execuo do teste, anlises das falhas
apontadas, dados gerais do projeto (de teste e de
implementao) e as concluses obtidas.
Na entrega para o cliente, dispara-se um processo
de aceitao do produto gerado, realizado pelos
usurios do software aps a visita de instalao,
com a utilizao de um relatrio de aceitao (RA),
que vai validar no somente o teste do software,
mas tambm a qualidade do produto entregue no
sentido da adequao s necessidades especficas
de uso.
4.3. Consideraes e dados sobre a utilizao do
processo
Este processo j foi utilizado em todos os sete
projetos executados aps sua implantao. A
Tabela 1 mostra um conjunto de dados sobre estes
sete projetos, e particularmente, das atividades de
teste.
Os dados desta tabela indicam que existe uma
prtica da execuo e gerenciamento de teste e
uma base inicial para comparaes com projetos
futuros buscando identificar problemas e
oportunidades de melhoria. Tambm indicam uma
boa execuo do processo de medio.
4.4. Resultados da melhoria
A melhoria do processo de teste, associada
melhoria do processo de desenvolvimento de
software como um todo, permitiu observar os
seguintes aspectos, dentre outros.
Maior controle durante a execuo do projeto,
devido principalmente ao planejamento prvio e
aos pontos de medio, sendo etapas do teste de
software alguns dos principais pontos existentes
atualmente. Este controle permite ainda que os
lderes de projeto nos clientes sejam acionados
imediatamente, sempre que houver qualquer
desvio em relao ao previsto.
Estudos e anlises, realizadas aps o
encerramento do projeto e entrega do produto
gerado, reforando os pontos positivos e criando
aes corretivas para os pontos negativos
detectados
no processo como um todo.

53

Qualidade do produto final gerado, no sentido da

verificao (requisitos definidos implementados
corretamente). No sentido da aceitao, a
documentao de projeto completa ajuda a
fornecer subsdios para que o usurio possa
verificar o aspecto da adequao s necessidades.
Outro ponto quanto qualidade que a
documentao gerada permite perceber mais
claramente as falhas relacionadas a detalhamentos
incorretos ou incompletos de requisitos.
Os clientes parecem compreender melhor as
dificuldades inerentes produo de software,
aumentando o respeito pelas informaes
transmitidas,
documentao
apresentada,
necessidades explicitadas, aceitando at maiores
prazos para entrega de produtos com maior
qualidade. A questo de maiores custos associados
ainda uma varivel a ser medida.
H um aumento nos custos gerais de produo de
software, esperados certamente no incio da
implementao dos novos processos, mas que
podero ser diludos apenas no longo prazo.
O objetivo da empresa , a partir dos dados gerados
pelo processo de teste, medir sistematicamente
cada projeto de software corrigindo desvios e
modificando consequentemente
as prioridades e aes corretivas a serem tomadas;
em outras palavras, aprimorando os processos com
o aprendizado.
Aps a implantao do processo de teste na
empresa, as seguintes melhorias foram observadas.
Existe um menor nmero de defeitos descobertos
aps instalao do software, diminuindo de forma
significativa os custos e problemas associados a
correes urgentes de um sistema em produo.
A equipe de programao est mais atenta: s
tarefas de verificao, antes da liberao de uma
verso para teste, causando inclusive uma melhoria
no produto, trazendo alm de menor desgaste da
equipe, menores custos para a empresa. Os

clientes, verificando os resultados iniciais obtidos,

tm dado mostras significativas que esto dispostos
a esperar mais pelo produto final. Mesmo assim,
nem sempre aceitam aumento nos custos. Em
seguida, eles passam a exigir tal comportamento,
em projetos posteriores ao primeiro onde tiveram
contato com o processo interno em implantao,
ou seja, passam a no querer mais verses do
software no devidamente testadas.
Os testes sistemticos tm fornecido dados e
informaes relevantes melhoria tanto do prprio
processo de teste quanto do processo de
desenvolvimento como um todo, aumentando sua
eficincia e/ou abrangncia, e permitindo a criao
de pessoal capacitado para as prticas necessrias.
Os testes sistemticos tm se mostrado, ainda, um
bom ponto de partida para medies, relacionadas
ao processo geral de desenvolvimento, ao processo
de teste, e ainda a outros processos internos da
empresa.
Pelo lado do investimento, os testes sistemticos
tendem a se pagar somente num horizonte de
mdio e longo prazo. Espera-se que o processo de
teste continue em evoluo, tanto para seu
contnuo aperfeioamento quanto, em um prazo
mais longo, para a incorporao de ferramentas.
4.4. Avaliao do processo de teste
Aps a implantao do processo, foi realizada uma
avaliao superficial das atividades de teste
segundo o processo de teste do modelo exemplo de
avaliao de processo da ISO/IEC 15504, chamado
de ISO/IEC 15504-5. O resultado desta avaliao foi
comparado com uma avaliao realizada em 2001,
antes da realizao deste ciclo de melhoria.
Tambm foi realizada uma avaliao em relao
rea de processo de Verificao do CMMI, que a
rea de processo mais prxima do escopo do
trabalho em teste.
O resultado da avaliao realizada em 2001
mostrou que a empresa executa o processo de
teste no Nvel 1 de capacidade. Existiam algumas
atividades de teste, sem nenhuma sistemtica, nem
planejamento. Na avaliao de 2004, existe uma
indicao do atendimento do Nvel 2 de
capacidade, com alguns elementos do Nvel 3.
Como a avaliao foi superficial, o mximo que se
pode dizer que existem indicadores.
O processo de teste de software da ISO/IEC TR
15504 tem como objetivo garantir que a
54

implementao de cada requisito do sistema seja

testada em conformidade com o requisito e que
o sistema esteja pronto para ser liberado. Como
resultado de uma implementao com sucesso do
processo de teste de sistema em uma organizao,
a 15504-5 requer que evidncias dos seguintes
quatro elementos sejam identificados durante uma
avaliao:
um critrio para o sistema desenvolvido que
demonstre a conformidade com os requisitos;
sistema verificado utilizando o critrio definido;
os resultados do teste so registrados; e
uma estratgia de regresso desenvolvida e
aplicada para retestar o sistema quando mudanas
forem feitas em elementos do sistema.
Para que o processo de teste da organizao esteja
no Nvel 1 de capacidade, o objetivo do processo e
os quatro resultados estejam sendo atingidos. Para
que este processo tambm esteja no Nvel 2, a
execuo do teste tem que ser planejada e
acompanhada, exigindo uma boa gerncia do teste,
e os principais produtos de trabalho do teste tm
que ser identificados, definidos, produzidos e
verificados. Para um processo estar no Nvel 3 ele
deve estar bem definido e ser seguido em cada uma
de suas execues.
Na avaliao superficial foi verificado que:
os objetivos do processo de teste estavam sendo
atingidos (portanto satisfaz o Nvel 1 de
capacidade);
a execuo planejada e acompanhada, e os
principais produtos de trabalho (no caso: Plano de
Teste PLP, Projeto de Teste PRT, Casos e
Procedimentos de Teste CPT, Relatrio de
Incidentes de Teste RIT, Dirio de Teste DIT, e
Relatrio Resumo de Teste RRT) so identificados,
definidos, produzidos e verificados (a verificao
no muito sistematizada, porm sendo uma micro
empresa, foi entendido que isto no compromete,
neste caso, o Nvel 2 de capacidade) (portanto
satisfaz o Nvel 2 de capacidade); e existe alguns
aspectos do processo j bem definidos (como por
exemplo, fluxo de execuo), mas ele ainda no
completo (portanto ainda no satisfaz o Nvel 3 de
capacidade).
Com isto, o processo de teste de software foi
considerado com o Nvel 2 de capacidade, em
relao ISO/IEC 15504-5. Para a rea de processo
de verificao da representao contnua CMMI-

SE/SW as indicaes tambm sinalizam o Nvel 2 de

capacidade.
Est previsto no programa de melhoria da empresa,
para 2004, uma avaliao detalhada, seguindo
todos os requisitos da ISO/IEC 15504, de um
conjunto de processos relevantes da
empresa, incluindo o processo de teste.
5. Concluso
Com a aplicao da metodologia em uma micro
empresa de desenvolvimento de software,
resultando em um processo de teste que foi
utilizado com bons resultados em sete projetos e
atingiu o Nvel 2 de capacidade de processo
segundo a Norma ISO/IEC 15504, pode ser
concludo que:
a metodologia vivel de ser aplicada em uma
micro empresa, como parte de um programa de
melhoria de processo; e
o processo de teste implantado pela metodologia
gera melhorias visveis aos clientes e aos
desenvolvedores, melhorando a qualidade do
software e o relacionamento entre a empresa e os
clientes.
A metodologia do CenPRA ajuda a estruturar as
atividades de teste desde o incio de um projeto de
desenvolvimento de software, tornando claro para
todas as partes envolvidas o relacionamento entre
o processo de desenvolvimento de software e as
atividades de teste. A definio pela metodologia
dos principais artefatos do processo de teste,
baseado na Norma IEEE
STD 829, o principal orientador das atividades de
teste.
3. Processos do gerenciamento de projetos (Fonte
PMBOK, 4.
Edio)
3.1. Iniciao
A iniciao o conjunto de processos realizado para
definir um novo projeto ou uma nova fase de um
projeto existente, mediante a obteno de
autorizao para tal. Nos processos de iniciao, o
escopo inicial definido e os recursos financeiros
iniciais so comprometidos.
As partes interessadas (stakeholders) que iro
interagir e influenciar os resultados finais do
projeto so identificadas. O gerente de projeto
selecionado e designado. Essas informaes so
registradas no Termo de Abertura do Projeto e no
registro das partes interessadas. Quando o termo
55

de abertura aprovado, o projeto se torna

oficialmente autorizado.
Os critrios para o sucesso so verificados e a
influncia e os objetivos das partes interessadas do
projeto so analisados. Ento decidido se o
projeto deve ser continuado, adiado ou
interrompido. Em geral, o envolvimento dos
clientes e de outras partes interessadas durante a
iniciao aumenta a probabilidade de propriedade
compartilhada, aceitao da entrega e satisfao
do cliente e das outras partes interessadas.
3.2. Termo de abertura do projeto Processo de
desenvolvimento de um documento que
formalmente autoriza um projeto ou uma fase e a
documentao dos requisitos iniciais que
satisfaam as necessidades e expectativas das
partes interessadas.
3.3. Identificao das partes interessadas
Processo de identificao de todas as pessoas ou
organizaes que podem ser afetadas pelo projeto
e de documentao das informaes relevantes
relacionadas a seus interesses, envolvimento e
impacto no sucesso do projeto.
As partes interessadas, ou stakeholders, so
pessoas ou organizaes cujos interesses afetam
ou podem ser afetados de forma positiva ou
negativa pelo projeto. Tambm conhecidos como
envolvidos.
4. Grupo de processos de planejamento (Fonte
PMBOK, 4 Edio)
O Grupo de processos de planejamento consiste
nos processos realizados para estabelecer o escopo
total do esforo, definir e refinar os objetivos e
desenvolver o curso de ao necessrio para
alcanar esses objetivos. Os processos de
planejamento desenvolvem o
plano de
gerenciamento e os documentos do projeto que
sero usados para execut-lo.
O plano de gerenciamento e os documentos do
projeto desenvolvidos como sadas do grupo de
processos de planejamento exploraro todos os
aspectos de escopo, tempo, custos, qualidade,
comunicao, risco e aquisies.
As atualizaes resultantes de mudanas aprovadas
durante o projeto podem ter um
impacto
significativo sobre partes do plano de
gerenciamento e dos documentos do projeto.
As atualizaes nesses documentos refletem maior
preciso em relao aos cronogramas, custos e

requisitos de recursos pra cumprir o escopo

definido para o projeto.
A equipe do projeto deve estimular o envolvimento
de todas as partes interessadas ao planejar o
projeto e desenvolver o plano de gerenciamento e
os documentos do mesmo.
4.1. Desenvolver o plano de gerenciamento do
projeto
Desenvolver o plano de gerenciamento do projeto
o processo de documentao das aes necessrias
para definir, preparar, integrar e coordenar todos
os planos auxiliares
(riscos,comunicaes e
treinamento). O plano de gerenciamento,
desenvolvido pelo gerente de projeto e equipe ou
por grupo representativo da equipe, torna-se a
fonte principal de informaes de como o projeto
ser planejado, executado, monitorado, controlado
e encerrado.
Para
o desenvolvimento
do plano de
gerenciamento do projeto, so necessrios
diversos documentos e informaes, tambm
denominados
entradas.
So
considerados
entradas: o termo de abertura do projeto,
processos de gerenciamento, fatores ambientais da
organizao (cultura organizacional) e ativos de
processos organizacionais (leis, normas, poltica,
processos, procedimentos, diretrizes, informaes
histricas e lies aprendidas de
projetos
anteriores).
4.2. Coletar requisitos
Processo de definir e documentar as necessidades
das partes interessadas para alcanar os objetivos
do projeto.
4.3. Definir escopo
Processo de desenvolvimento de uma descrio
detalhada do projeto e do produto.
4.4. Criar a estrutura analtica de projeto (EAP)
Processo de subdiviso das atividades, das entregas
e de todo o trabalho necessrio execuo do
projeto em componentes menores e de
gerenciamento mais fcil.
4.5. Definir as atividades
Processo de identificao das aes especficas a
serem realizadas para produzir as entregas do
projeto.SINAL Sindicato Nacional dos Funcionrios
do Banco Central
4.6. Seqenciar as atividades
Processo de identificao e documentao dos
relacionamentos entre as atividades do projeto.
4.7. Estimar os recursos das atividades
56

Processo de estimativa dos tipos e quantidades de

material, pessoas, equipamentos, suprimentos,
instalaes, viagens, estadias, dentre outros, que
sero necessrios para realizar cada atividade.
4.8. Estimar as duraes das atividades
Processo de estimativa do nmero de perodos de
trabalho que sero necessrios para executar
atividades especficas com os recursos estimados.
4.9. Desenvolver o cronograma
Processo de anlise de seqncias das atividades,
suas duraes, recursos necessrios e restries,
visando criar o cronograma do projeto.
4.10. Estimar os custos
Processo de desenvolvimento de uma estimativa
dos recursos monetrios necessrios para executar
as atividades do projeto.
4.11. Determinar o oramento
Processo de agregao dos custos estimados de
atividades individuais ou pacotes de trabalho para
estabelecer uma linha de base dos custos
autorizada.
4.12. Planejar a qualidade
Processo de identificao dos requisitos e/ou
padres de qualidade do projeto e do produto,
alm da documentao de como o projeto atingir
a conformidade.
4.13. Desenvolver plano de recursos humanos
Identificao de
papis,
responsabilidades,
habilidades necessrias e relaes hierrquicas do
projeo, alm da criao de um plano de
gerenciamento de pessoal
(titulares, alternos
eventuais), Processo de identificao dos requisitos
e/ou padres de qualidade do projeto e do
produto, alm da documentao de como o projeto
atingir a conformidade. SINAL Sindicato Nacional
dos Funcionrios do Banco Central
4.14. Planejar as comunicaes
Determinao das necessidades de informao
(emissor responsvel,
periodicidade, tipo de
documento, dentre outros) das partes interessadas
no projeto e definio de uma abordagem de
comunicao.
4.15. Planejar o gerenciamento de riscos
Definio de como conduzir as atividades de
gerenciamento de riscos de um projeto.
4.16. Identificar os riscos
Identificar os riscos que podem afetar o projeto e
registrar suas caractersticas.
4.17. Realizar a anlise qualitativa dos riscos

Processo de priorizao de riscos para anlise ou

ao adicional, mediante avaliao e combinao
de sua probabilidade e impacto.
4.18. Realizar a anlise quantitativa de riscos
Processo de analisar numericamente (custos, prazo,
estimativa de perdas) os impactos dos riscos
identificados nos objetivos gerais do projeto.
4.19. Planejar respostas a riscos
Processo de desenvolvimento de opes e aes
para aumentar as oportunidades e reduzir as
ameaas aos objetivos do projeto.
4.20. Planejar as aquisies
Processo de documentao das decises de
compras do projeto, especificando a abordagem,
forma de contratao e identificando fornecedores
em potencial.
5. Grupo de processos de execuo do Projeto
(Fonte PMBOK, 4 Edio)
Este grupo consiste nos processos realizados para
concluir o trabalho definido no
plano de
gerenciamento do projeto de forma a cumprir as
especificaes. Este grupo compreende coordenar
pessoas, recursos e tambm integrar e executar as
atividades do projeto em conformidade com o
plano de gerenciamento desenvolvido no item
anterior.
SINAL Sindicato Nacional dos Funcionrios do
Banco Central Durante a execuo do projeto, os
resultados podero requerer atualizaes no
planejamento e mudanas nas linhas de base. Isso
pode incluir alteraes nas duraes previstas para
as atividades e tambm influir na produtividade da
equipe, na disponibilidade
dos recursos e
ocasionando riscos no previstos.
O resultado da anlise poder acionar solicitaes
de mudanas, que devero ser aprovadas pela
instncia competente e que refletiro no plano de
gerenciamento do projeto e
demais planos,
podendo tambm impactar o prazo final, custos e
qualidade.
Os principais processos de execuo: orientar e
gerenciar a execuo do projeto, realizar a garantia
da qualidade, mobilizar a equipe do projeto,
desenvolver a equipe do projeto, gerenciar a
equipe do projeto, distribuir informaes, gerenciar
expectativas das
partes interessadas, realizar
aquisies.

57

6. Grupo de processos de monitoramento e

controle (fonte: PMBok, 4 Edio)
Este grupo consiste nos processos necessrios para
acompanhar, revisar e regular o progresso e o
desempenho do projeto, identificar todas as reas
nas quais so necessrias mudanas no plano e
iniciar as mudanas correspondentes. O principal
benefcio deste grupo de processos que o
desempenho do projeto observado e mensurado
de forma peridica e uniforme para identificar
variaes em relao ao plano de gerenciamento
do mesmo. O grupo de processos inclui tambm:
controlar as mudanas e recomendar aes
preventivas, monitorar as atividades em relao
linha de base e influenciar fatores que poderiam se
impedir o controle integrado de mudanas.
Processos: monitorar e controlar o trabalho do
projeto; realizar o controle integrado de mudanas;
verificar o escopo; controlar o escopo; controlar o
cronograma; controlar os custos; realizar o controle
de qualidade; reportar o desempenho; monitorar o
controle de riscos e administrar aquisies.
7. Grupo de processos de encerramento (fonte
PMBok, 4 Edio)
Consiste dos processos executados para finalizar
todas as atividades de todos os grupos de
processos de gerenciamento do projeto, visando
completar formalmente o projeto ou a fase, ou
obrigaes contratuais. Este grupo de processos,
quando concludo, verifica se os
processos
definidos esto completos em todos os grupos de
processos para encerrar o projeto ou uma fase do
projeto da forma apropriada. Neste grupo de
processos define-se formalmente que o projeto ou
a fase do projeto esto concludos. No
encerramento do projeto ou da fase, podem
ocorrer as seguintes atividades: obter aceitao do
cliente ou patrocinador; fazer uma reviso psprojeto ou de final de fase; registrar os impactos da
adequao de qualquer processo; documentar as
lies aprendidas; aplicar as atualizaes
apropriadas aos ativos de
processos
organizacionais; arquivar todos os documentos
relevantes no sistema de SINAL Sindicato Nacional
dos Funcionrios do Banco Central informaes do
gerenciamento de projetos (SIGP), para serem
usadas como dados histricos; e encerrar as
aquisies.

01 - INTRODUO
Uma metodologia de desenvolvimento constitui-se
de uma abordagem organizada para se atingir um
objetivo, possvel por meio do cumprimento de um
conjunto de procedimentos preestabelecidos. Desta
forma, o produto se torna o componente mais
importante
de
todo
o
processo
de
desenvolvimento.
Este documento se trata de um roteiro para o
desenvolvimento de sistemas que dever ser
utilizado e avaliado por todos os funcionrios da
empresa, que ser periodicamente revisado,
atualizado e complementado para que se possa
agregar qualidade ao produto final.
Vale a pena ressaltar a opo por um processo de
desenvolvimento de sistemas orientados a objetos,
baseado numa abordagem iterativa e incremental e
dirigido por casos de uso. Um ciclo de vida iterativo
se baseia o aumento e refinamento sucessivo de
um sistema atravs de mltiplos ciclos de
desenvolvimento de anlise, de projeto, de
implementao e de teste. [1] o processo em
questo uma adaptao do processo de Craig
Larman [1], por sua vez baseado no Rational Unified
Process (RUP).
A UML (Unifiel Modeling Language), linguagem de
modelagem adotada uma linguagem para
especificar, visualizar e construir os artefatos de
sistemas de software..[bjr97]. Ela um sistema de
notao (incluindo a semntica para suas notaes)
dirigida modelagem de sistemas, usando
conceitos orientados a objetos [1].
A Metodologia de desenvolvimento de sistemas da
empresa ser dividida em fases de execuo, onde
cada fase ser composta por um conjunto de
atividades. Ao final de cada fase espera-se obter
artefatos, sejam eles diagramticos ou textuais,
dependendo da fase em questo. A organizao da
metodologia de desenvolvimento de sistema da
empresa poder ser vista em formato grfico na
Figura 01(a-e).

Metas:
Descrever os procedimentos relacionados como
deve ser o produto final, como este ser
apresentado ao cliente e ainda, se este atende a
padres de qualidade.
Descrever procedimentos internos para a
formalizao das fases do projeto.
58

Metodologia de Desenvolvimento de Sistemas de

Informao
baseados em OO.
02 A METODOLOGIA DE DESENVOLVIMENTO
01 Plano de Execuo do Projeto.
Meta: Descrever o perfil do cliente e identificar o
servio solicitado pelo mesmo, a fim de considerar
os aspectos relacionados gesto do projeto, bem
como seu escopo, prazos e objetivos gerais.
Atividades:
Contato Inicial com o Cliente:
1. Identificao do Cliente;
2. Identificao do Servio Solicitado;
3. Levantamento de Recursos e Custos;
4. Cronograma Inicial
Concludo o levantamento de recursos, o produto
gerado por esta atividade Relatrio de Recursos
juntamente com o cronograma inicial dever ser
encaminhado ao setor comercial. O cronograma
poder ser elaborado pelo profissional da rea
tcnica juntamente com o responsvel pelo projeto
na rea comercial.
02 Levantamento de Requisitos
Meta: Identificar o sistema e definir seus requisitos
(funcionais e no funcionais).
Atividades:
Definio do Sistema:
Requisitos so uma descrio das necessidades ou
desejos para um produto. [1]
Esta atividade objetiva definir um nome para o
sistema, descrever a finalidade do projeto, resumir
o processo padro adotado no cliente, descrever
suas expectativas, quais as funcionalidades que o
projeto do sistema dever contemplar, e ainda
identificar se o sistema possuir interface com
algum j existente.
Identificao dos requisitos:
Consiste em entender o que deve ser feito em
termos de requisitos e o que se espera obter como
resultado. O descobrimento de requisitos ,
geralmente, possvel por meio de interao com o
cliente, ou ainda por fragmentao de sistemas
mais abrangentes.
Anlise e classificao dos requisitos:
Tem como objetivo avaliar as inconsistncias,
ambiguidades, riscos e prioridades dos requisitos
indicados na identificao dos Requisitos. A

classificao basicamente a diviso em dois

grupos distintos: os requisitos funcionais, os quais
refletem funcionalidades a serem implementadas
de modo a satisfazer as regras de negcio, e os
requisitos no funcionais, que incluem interfaces
externas, restries de desempenho, banco de
dados,
plataforma
de
desenvolvimento,
documentao para o usurio final, etc.
O registro dos requisitos levantados por esta etapa
formalizado em um editor de textos, com o
documento de requisitos do projeto (ver o modelo
3), o qual poder ser organizado da forma abaixo:
Documento de Requisitos do Projeto
1. Descrio textual do sistema (definio,
objetivos, processos atual, expectativas do cliente,
dentro outros);
2. Listagem dos requisitos (em forma de tabela);
a. Nmero de requisitos;
b. Descrio do requisito;
c. Classificao do requisito;
d. Prioridade;
Aps a concluso da fase de levantamento de
requisitos deve-se agendar uma nova visita ao
cliente. De posse dos artefatos produzidos at o
momento, o cliente poder validar as informaes
levantadas e formalizadas pelos profissionais da
empresa de desenvolvimento. Uma vez em
concordncia com o que for apresentado, o cliente
dever assinar um termo de concordncia, cujo
modelo sugerido pela metodologia (Ver modelo
4). Este procedimento poder se repetir at que o
cliente esteja de acordo com as informaes
presentes nos artefatos apresentados.
03 Casos de Uso
Meta: Elaborar o diagrama e a especificao dos
Casos de Uso do Sistema.
Atividades:
Compreenso dos requisitos:
Os casos de uso so dependentes de uma
compreenso mnima dos requisitos do sistema, os
quais devem estar expresses no documento de
requisitos de projeto.
Construo do diagrama:
O Diagrama de Casos de Uso dever conter todos os
requisitos j identificados, as interfaces com
sistemas j existentes no cliente e os atores
envolvidos.
Descrio em alto nvel
59

Trata-se de descrever de forma sucinta a

especificao essencial de requisitos. til pra o
entendimento do grau de complexidade e
funcionalidade de um sistema para que se
determine seu escopo. As informaes que devem
estar nesta especificao podem ser vistas no
Modelo 5.
Descrio em nvel detalhado.
Mostra mais detalhes que a descrio em alto nvel.
Sua utilidade est na compreenso mais profunda
dos processos e requisitos. importantes escrever
os casos de uso principais no formato expandido,
podendo os demais ser descritos no ciclo de
desenvolvimento o qual ser contemplado. A forma
expandida pode ser consultada no modelo 6.
Esta etapa dever ser realizada pelo Analista de
Sistemas e os artefatos produzidos resumem-se ao
Diagrama de Casos de Uso, o qual poder ser
feito em uma ferramenta case (ver sugestes); e s
especificaes em alto nvel/nivel expandido, que
dever ser feitas em um editor de textos. Aps a
descrio, deve-se estabelecer um ranking de
prioridades dos casos de uso, o qual definido de
acordo com o grau de importncia/complexidade
do caso de uso (Ver modelo 7). A priorizao dos
casos de uso determina o nmero de
iteraes/ciclos de desenvolvimento para o
sistema.
04 - Modelo Conceitual de Classes
Meta: Elaborar o Modelo Conceitual de Classes e o
Glossrio ou Dicionrio do Modelo.
Atividades:
O modelo conceitual de classes dever ser
construdo considerando-se:
Conceitos (ou entidades) representados por
classes;
Associaes, ou relacionamentos entre os
conceitos;
Multiplicidades;
Atributos;
Interfaces com sistemas j existentes.
Neste momento, o Analista de Sistemas poder
iniciar a construo de um glossrio ou Dicionrio
do Modelo (Ver Modelo 8). Este artefato define um
conjunto de termos que requerem esclarecimentos
e til para melhorar a comunicao e reduzir o
risco de mal-entendimento, principalmente em
equipes com muitos membros envolvidos. Trata-se
de um artefato continuamente aperfeioado,

apresentando novos termos a cada ciclo de

desenvolvimento.
04 Diagrama de Estados/Atividades
Meta: Elaborar os Diagramas de Estados/Atividades
do Sistema.
Atividades:
Diagrama de Estados
Ilustra os eventos e os estados interessantes a um
objeto, analisando tanto o comportamento de um
objeto em resposta a um estmulo, como o ciclo de
vida de um objeto. Deve ser usado para a
modelagem de sistemas com comportamento mais
complexo. Compreendem basicamente estados de
atividade, estados de aes, sinais e eventos.
Diagrama de Atividades
Representa um tipo particular de diagrama de
estados. Tem por finalidade mostrar um fluxo de
atividades
dentro de um sistema, dando uma viso dinmica.
importante para a modelagem de funes dentro
do
sistema, focalizando o fluxo de controle entre
objetos.
05 Diagrama de Interao (Colaborao e
Seqncia).
Meta: Elaborar os Diagramas de Interao
(Colaborao e Seqncia).
Atividades:
Diagrama de Estados
A finalidade dos diagramas de interao ilustrar
como os objetos interagem atravs de mensagens
para cumprir tarefas. Podem ser representados em
forma de grafo os diagramas de colaborao ou
em forma de cercas os diagramas de seqncia.
Desta forma, segue abaixo o que deve constar,
basicamente, em um diagrama de colaborao.
Diagrama de Atividades
Classes e instncias;
Ligaes;
Mensagens, parmetros e valores de retorno.
06 Diagrama de Classes do Projeto.
Meta: Elaborar o Diagrama de Classes de Projeto.
Atividades:
Diagrama de Classes
A construo do Diagrama de Classes de Projeto
depende da construo prvia do Modelo
Conceitual de Classes e de Diagramas de Interao.
60

Este artefato ilustra as especificaes para as

classes de software. A partir deste, o Analista de
Sistemas acrescenta detalhes s definies das
classes.
Um diagrama de classes de projeto deve conter:
Classes, associaes e atributos;
Interfaces;
Mtodos;
Informao de tipo de atributo;
Navegabilidade;
Dependncias.
07 Esquema de Banco de Dados.
Meta: Elaborar o Esquema do Banco de Dados.
Atividades:
Esquema de Banco de Dados
A construo do Esquema do Banco de Dados
consiste no detalhamento do Modelo Conceitual de
Dados.
Neste ponto deve-se nomear.
As entidades;
Os atributos;
Os domnios;
As validaes;
Os relacionamentos;
As Views;
As Stored procedures;
As Triggers.
Este artefato poder ser construdo na ferramenta
DBDesigner (Ver sesso Ferramentas). Uma vez
construdo possvel elaborar um Dicionrio de
Dados, utilizando-se o recurso disponvel na
ferramenta.
08 Modelo Arquitetural.
Meta: Elaborar o Modelo de Arquitetura do
Sistema.
Atividades:
Modelo Arquitetural
O Modelo de Arquitetura do sistema o artefato
que conter a especificao da arquitetura mais
indicada para o projeto., Abrange aspectos de
comunicao de dados, tecnologias mais adequadas
ao projeto, sistemas operacionais, sistemas
gerenciadores de banco de dados, dentre outros.
Uma prtica aconselhvel unir profissionais da rea
de sistemas com profissionais de suporte tcnico na
elaborao do Modelo de Arquitetura.

Meta: Construir o cdigo do sistema.

Atividades:
Construo
Consiste em definir a estrutura do cdigo em
termos de implementao em linguagem de
programao.
Produz como sada o software, o cdigo fonte e a
documentao tcnica gerada.
10 Segurana.
Meta: Estabelecer mecanismos para segurana e
controle.
Atividades:
Segurana
Est relacionada anlise dos seguintes
procedimentos, os quais devem ser incorporados
ao sistema.
Controle de acesso ao sistema;
Restrio de acesso a dados confidenciais;
Controle de acesso a funcionalidades,
determinados por nveis de permisses;
Registro e recuperao de atualizaes (log);
Continuidade do projeto em caso de interrupes
por queda de energia, parada de mquina, dentre
outros;
Poltica de backups;
Possibilidade de auditoria, a fim de se detectarem
fraudes de dados.
11 Construo Testes.
Meta: Elaborar Modelos de Testes.
Atividades:
Construo Testes
O planejamento de testes representa um aspecto
importante no processo de desenvolvimento de
sistemas, principalmente no que se refere ao
acompanhamento do que foi feito, na verificao
das funcionalidades solicitadas pelo cliente,
performance das aplicaes, dentre outras.
Consiste basicamente de:
Identificar os objetos de teste e classific-los;
Reconhecer requisitos para cada tipo de teste;
Definir uma massa de dados de teste;.
Fazer uma reviso ortogrfica e gramatical do
produto a ser entregue;
Comunicar defeitos encontrados ou desvios
relacionados aos resultados porventura no
alcanados.
12 Implantao Plano de Implantao.

09 Construo Implementao.
61

Meta: Elaborar plano baseado nos requisitos

levantados, definindo-se recursos para a
implantao do sistema.
Atividades:
Implantao
Como artefato para auxiliar a fase de implantao
sugere-se a construo de um plano que
especifique, alm de informaes referentes aos
recursos, os prazos previstos para a execuo das
atividades de implantao. Estas informaes
podero ser elaboradas em um editor de textos e
consultadas no Modelo 9.
13 Pacote de Entrega ao Cliente.
Meta: Estabelecer procedimentos para a entrega
do sistema ao cliente.
Atividades:
Pacote de Entrega
Os procedimentos para a entrega do sistema ao
cliente consistem em:
Elaborao de manuais do sistema;
Verificao da conformidade do help on-line
construdo com o sistema a ser entregue;
Elaborao da especificao de procedimentos de
instalao do sistema;
Gravao do sistema em mdia magntica/ptica.
14 Treinamento.
Meta: Elaborar plano e ministrar treinamento aos
usurios do sistema.
Atividades:
Treinamento
Para esta fase destacam-se as seguintes atividades:
Elaborar plano de treinamento, segundo Modelo
10;
Levantar material necessrio ao treinamento;
Confirmar com o cliente algum material que
venha a ser levantado pelo mesmo, datas previstas
para os treinamentos e disponibilidade dos usurios
no horrio agendado.
15 Avaliao do Cliente Garantia de Qualidade.
Meta: Orientar a prestao de servios aps a
implantao do sistema.
Atividades:
Avaliao do Cliente Garantia de Qualidade
Os procedimentos para a garantia do servio
prestado aps a entrega do sistema ao cliente
compreendem:

Elaborar plano de garantia do sistema (Ver

Modelo 11);
Avaliar como o sistema se comporta no cliente em
um perodo de adaptao inicial. Neste perodo
identificar
processos,
ocorrncias
de
comportamento e/ou procedimentos para a
continuidade de implantao, segundo Modelos 12
e 13;
Definir plano para a manuteno corretiva, de
acordo com a necessidade e segundo Modelo 14.
16 Ferramentas de Apoio.
Com o objetivo de automatizar as atividades e
melhorar a qualidade dos artefatos gerados, as
equipes da rea tcnica podero contar com o
suporte de ferramentas para o desenvolvimento de
algumas
atividades
no
processo
de
modelagem/desenvolvimento
de
algumas
atividades
no
processo
de
modelagem/desenvolvimento do sistema.
MVCASE uma ferramenta CASE orientada a
objetos consistindo em uma alternativa free para o
caso da empresa no possuir licena para o uso da
Rational Rose, ou ainda se no possuir recursos
para adquirir tal licena. Entretanto, vale salientar
que a MVCASE possui limitaes de funcionalidades
ao se comparar as duas, mas em termos de
diagramas apresenta resultados similares, alm
delas existem tambm o JUDE uma excelente
ferramenta para modelagem dos artefatos da UML.
DBDesigner uma ferramenta Open Source,
distribuda sob licena GLP, que integra criao,
modelagem, desenvolvimento e manuteno de
bancos de dados.
17 Resumo das Atividades
As fases de execuo e respectivas atividades
podem ser vistas na tabela abaixo:
Fases Atividades
Planejamento
Plano de Execuo do Projeto
1. Contato Inicial com o Cliente;
2. Levantamento de Recursos do Projeto;
3. Cronograma Inicial.
Levantamento de Requisitos
1. Definio do Sistema;
2. Identificao dos Requisitos;
3. Anlise e Classificao dos Requisitos.
62

Casos de Uso
1. Construo do Diagrama de Casos de Uso;
2. Descrio em Alto Nvel;
3. Descrio em Nvel Detalhado;
4. Priorizao e Escalonamento dos Casos de Uso.
Construo
Anlise
1. Modelo Conceitual de Classes;
2. Glossrio;
3. Diagramas de Estados/Atividades.
Projeto
1.Diagramas de Interao;
2. Diagrama de Classes do Projeto;
3. Esquema do Banco de Dados;
4. Modelo de Arquitetura.
Implementao
1. Implementao;
2. Segurana.
Testes
1. Testes.
Implantao
1. Plano de Implantao;
2. Pacote de Entrega ao Cliente;
3. Treinamento.
Avaliao do Cliente/Manuteno
1. Garantia da Qualidade.
Segue tambm a relao dos artefatos resultantes
no final de cada fase/atividade, bem como um
indicativo de opcionalidade para aqueles que no
se fizerem necessrio quando se tratar de um
projeto simples.
Quando se tratar de projetos com grau de
complexidade considervel aconselha-se que todos
os artefatos sejam desenvolvidos. Os artefatos
podero ser vistos na tabela abaixo:
Atividades Artefatos
METODOLOGIA PARA O DESENVOLVIMENTO DE
UMWEB SITE ADAPTATIVO UTILIZANDO TCNICAS
DE MINERAO DO USO DA WEB E REGRAS DE
ASSOCIAO

Palavras Chave: Minerao do Uso da Web, Web

Sites Adaptativos, Arquitetura Orientada a Servios,
Servios Web.
Resumo. Este artigo apresenta uma metodologia
para o desenvolvimento de Web Sites Adaptativos:
sites que automaticamente melhoraram a sua
organizao e apresentao a partir da
aprendizagem de padres de acesso dos seus
visitantes. Para tal desenvolvimento utilizado
tcnicas de minerao do uso da web e regras de
associao. Para facilitar o desenvolvimento de tal
metodologia foi definido a utilizao do conceito de
Arquitetura Orientada a Servios (SOA - Service
Oriented Architecture).
Esta arquitetura se preocupa com a construo
independente de servios, negcios alinhados que
podem ser combinados em significantes processos
de negcio de alto nvel e solues dentro do
contexto do empreendimento. Todavia, de forma a
avaliar e validar a metodologia, um prottipo de
site adaptativo, focado em uma instituio de
ensino (Centro Federal de Educao Tecnolgica de
Minas Gerais - CEFET-MG) vem sendo desenvolvido,
no sentido de fornecer a apresentao do material
em diferentes mdias adaptando-se ao perfil / estilo
do usurio. Acredita-se que a utilizao destas
tcnicas podero ser utilizadas para examinar os
logs de acesso dos usurios, descobrindo padres
de acesso automaticamente,
a fim de tornar o web site adaptativo.
1 INTRODUO
O desenvolvimento e a organizao do contedo de
um web site no tem sido uma tarefa trivial.
Normalmente um web site sintetiza diversas
informaes distribudas entre as pginas, imagens
e hiperlinks. Mesmo que o volume de acesso do site
no seja grande, geralmente os seus usurios so
diversificados. Cada visitante que acessa um site
pode ter um objetivo diferente, pode estar
procurando por informaes diferentes. muito
provvel que a maioria dos usurios da Internet
tenham visitado sites que poderiam ter a
informao, o produto ou o servio que ele estava
procurando, mas no conseguiu encontr-los e se
dirigiu para um outro site. Ao mesmo tempo que
projetar um web site uma tarefa complicada,
muito difcil identificar as caractersticas do pblico
alvo. Assim, construir uma interface que atenda os
requisitos de todos os usurios de um site no
63

uma tarefa fcil. Se o projetista tivesse uma

maneira de conhecer o seu pblico, grande parte
dos problemas de interao entre usurio e
interface poderiam ser resolvidos. Assim, a fim de
auxiliar na tarefa de conhecer o pblico que um site
possui, vrias tcnicas esto disponveis como a
minerao de dados na web (WebMining).
Independente das caractersticas dos usurios de
web sites, a sua principal necessidade consiste em
encontrar a informao desejada de modo fcil e
rpido. Ainda que seja possvel identificar o
comportamento de todos os usurios em um site,
tornasse difcil disponibilizar informaes de forma
clara e simples para todos. Para isto, um site
adaptativo, que se ajusta
automaticamente a cada usurio de acordo com
seus padres de comportamento, muito til.
Sites adaptativos so desenvolvidos com base em
tcnicas que auxiliam o projetista na tarefa de
personalizar pginas web e por este motivo, so
chamadas de tcnicas de personalizao. Algumas
possveis conseqncias da aplicao dessas
tcnicas so: aumento da mdia de pginas
visitadas por sesso, os usurios podem demorar
mais tempo visitando o site; pode haver um
umento da taxa de reteno (nmero de visitantes
que retornam ao site) e da taxa de converso
(visitas que se convergem em possveis compras)
(Greening (2000)).
Nossa abordagem bsica analisar os logs de
acesso de web, afim de encontrar grupos de
usurios que frequentemente acessam pginas
semelhantes, assumindo que estas pginas
representam temas coerente na mente dos
usurios. Para tal anlise utilizaremos os conceitos
de algoritmos de aprendizagem e clustering. Os
algoritmos
de
aprendizagem,
possibilita
encontrarmos uma descrio conceitual de uma
classe de objetos de uma coleo de dados com
base em exemplos da classe (exemplos positivos) e
exemplos de objetos no pertencentes a classe
(exemplos negativos). Essencialmente, o algoritmo
deve determinar o que os objetos tm em comum
que os distingue de outros objetos na coleo.
Contudo, o conceito de algoritmos de
aprendizagem so algoritmos de aprendizado
supervisionado: eles exigem que suas entradas
sejam classificadas antecipadamente. No nosso
domnio, tudo o que temos uma coleo de

objetos (pginas Web) e alguns dados sobre

padres de uso. Algoritmos de agrupamento
(clustering),
por
outro
lado,
no
so
supervisionados: eles recebem uma coleo de
objetos como
entrada e produzem uma diviso desta coleo uma classificao onde cada objeto se encontra
exatamente dentro de sua classe, ou "cluster".
Assim este artigo visa realizar um estudo sobre a
adoo de caractersticas e vantagens de tcnicas
de minerao do uso da web e regras de
associao, utilizando o conceito de Arquitetura
Orientada a Servios (SOA - Service Oriented
Architecture) para o desenvolvimento de web sites
adaptativos, apontando os benefcios que este tipo
de
metodologia
pode
trazer
para
o
desenvolvimento de sistemas adaptativos, gerando
automaticamente melhorias e sugestes a partir de
logs do servidor web, melhorando a organizao e
apresentao de web sites.
2 WEB SITES ADAPTATIVOS
Adaptao, em informtica, significa definir um
conjunto de parmetros para atender s exigncias
de um usurio especfico; ajustar para o uso
pessoal. Em Batista (2008) apontado alguns
fatores que justificam a opo pela personalizao:
Quando um web site voltado a um pblico com
perfil diversificado; estilos cognitivos variados;
abrangendo iniciantes at experts em interao
humano-computador; de crianas at idosos; desde
os que possuem maior conhecimento acerca do
contedo abordado, at aqueles que esto
comeando a se interessar pelo assunto; em suma,
quando existem diversos modelos de usurios,
torna-se vivel promover a adaptao de contedo,
navegao e apresentao.
Uma alternativa que promove melhor assistncia
heterogeneidade de perfis de usurios o
desenvolvimento de Web Sites Adaptativos
(Brusilovsky (2004)). Segundo Koch (2000), os
SistemasWeb
Adaptativos
potencializam
a
abordagem centrada no usurio: o sistema adapta
os aspectos visveis de acordo com o modelo do
usurio (construdo a partir de dados do usurio),
gerando uma interface que disponibiliza a
"informao apropriada, com layout adequado para
cada usurio".
64

Segundo Brusilovsky et al. (2004), "a Web

Adaptativa tem atrado ateno considervel
devido ao seu potencial para fornecer aplicaes e
servios personalizados para os cidados da
sociedade do conhecimento".
Os
web
sites
adaptativos
promovem,
automaticamente, sua organizao e apresentao
de acordo com os padres de acesso do usurio. As
pginas so mais acessveis, h possibilidade de
destacar links interessantes, conectar pginas
relacionadas e promover agrupamento de
documentos similares (Perkowitz e Etzioni (2009)).
Um Web Site pode ser adaptativo de duas formas
bsicas, a personalizao e a Otimizao. A
personalizao a adaptao da interface do site
devido as necessidades dos seus visitantes
individuais, com base em informaes sobre esses
indivduos. A otimizao o processo que define uma
estrutura melhor para o site baseado nas interaes
de todos os seus visitantes.
Em vez de fazer alteraes para cada indivduo, o
site aprende a partir de inmeros visitantes,
tornando sua utilizao mais fcil para todos,
incluindo aqueles que nunca usaram antes.
Sites adaptativos observam as atividades dos
usurios, os seus erros e aprendem sobre os perfis
de usurio, sobre os seus padres de acesso e
problemas com a organizao do contedo
de um site. A personalizao de web sites uma
estratgia para aproveitar as informaes deixadas
pelo usurio com o objetivo de tornar o site mais
prximo das necessidades do seu
pblico.
A seguir, apresenta-se uma taxonomia discutida em
Ruas et al. (2001) que classifica as tcnicas de
personalizao existentes e define todo o processo
de personalizao de um site. O processo de criao
de um site adaptativo envolve quatro fases Figura
1:
definio dos objetivos: o administrador do site
deve definir as metas a serem alcanadas com a
personalizao;
observao: a coleta dos dados de acesso ao site;
transformao: gera as regras de adaptao a
partir dos dados coletados na fase anterior;
aplicao: a utilizao das regras na sua estrutura.
3 MINERAO DE DADOS NA WEB
Nos ltimos anos tem crescido a aplicao da
minerao de dados em um ambiente altamente

dinmico a Internet. Esta nova aplicao tem sido

denominada de minerao de dados na WEB e o
crescimento de sua importncia pode ser atribudo
a alguns fatores como: a inexistncia de padres, a
falta de estruturao e a heterogeneidade; a
Internet apresentou um crescimento acentuado e
como conseqncia um aumento significativo no
acmulo de informaes e as mesmas mudam
muito rapidamente. Neste contexto observa-se a
existncia de um mundo de dados altamente
dinmico, e com extrema riqueza, sendo assim,
torna-se um meio de grande interesse para
aplicao da minerao de dados para um melhor
aproveitamento das informaes atravs da
descoberta e extrao de conhecimento.
A WEB (Zaiane (2000)) pode ser definida como uma
fonte de matria-prima, amplamente distribuda,
altamente heterognea, semi estruturada ou no
estruturada, interconectada, evolutiva,
repositrio
de
informaes
de
hipertexto/hipermdia. Este meio apesar da
abundncia e diversidade de informaes apresenta
problemas para o seu uso devido a dinamicidade e
diversificao de estruturas que a caracterizam.
Quando se enfoca a minerao de informaes no
ambiente da Internet, utiliza se a expresso
minerao de dados na WEB ou WEB MINING, que
segundo Cook (2000) pode ser definida
da seguinte forma: Minerao de dados na WEB
pode ser definida como a descoberta e anlise de
informao til originada na WEB.
Sendo assim, minerao de dados na WEB
configura-se em um processo no trivial de
minerao ambientado na Internet.
A minerao de dados na Web tem como objetivo
obter o conhecimento ou descobrir informaes
uteis atravs da estrutura da Web (Hyperlink), o
contedo da pgina, e dados do uso. Apesar
minerao da Web utilizar diversas tcnicas de
minerao de dados, no meramente uma
aplicao de minerao de dados tradicionais,
devido heterogeneidade e a natureza semiestruturada ou no dos dados da Web. Muitas
tarefas de minerao e novos algoritmos
foram inventadas na dcada passada. Com base nos
principais tipos de dados utilizados no processo de
minerao, as tarefas de minerao da Web podem
ser classificados em trs subreas

65

conforme a figura 2: minerao da estrutura da

Web, minerao do o contedo da Web e a
minerao do uso da Web.
Devido riqueza e diversidade de informaes na
Web, h um grande nmero de tarefas de
minerao web, neste trabalho vamos concentrarse na minerao do uso da Web.
3.1 Minerao do Uso daWeb
Com o contnuo crescimento e proliferao do
comrcio eletrnico, servios Web e Sistemas de
Informao baseados na Web, os volumes de dados
e de Clickstream (Sequncia de Cliques) do usurio
coletados por Organizaes Baseadas na Web em
suas Operaes dirias atingiu propores
astronmicas.
A anlise estes dados podem ajudar essas
organizaes determinar o de tempo de vida de
clientes, desenhar caminhos estratgicos de
marketing atravs de produtos e servios, avaliar a
eficcia das campanhas promocionais, otimizar a
funcionalidade dos aplicativos baseados na Web,
fornecer um contedo mais personalizado aos
visitantes, e encontrar a estrutura lgica mais eficaz
para o seu espao Web. Este tipo de anlise envolve
a descoberta automtica de padres e relaes
significativas de uma grande coleo de dados
semi-estruturados, muitas vezes armazenados em
aplicaes Web e logs de acesso ao servidor, bem
como nas respectivas fontes de dados operacionais.
A minerao do uso da Web refere-se descoberta
e anlise automtica de padres em dados de
pginas visitadas e associadas coletados ou gerados
como resultado de interaes do usurio com os
recursos da Web em um ou mais sites da Web (R.
Cooley e Srivastava (1997), Mobasher (2006), J.
Srivastava e Tan (2000)). O objetivo capturar,
modelar e analisar os padres comportamentais e
perfis de usurios que interagem com um Web Site.
Os padres descobertos so geralmente
representados como conjuntos de pginas, objetos
ou recursos que so acessados com frequncia por
grupos de utilizadores com necessidades ou
interesses comuns.
Na sequncia do processo padro de minerao de
dados (U. M. Fayyad e Smyth (1996)), o uso global
do processo de minerao da Web pode ser
dividido em trs fases inter-dependentes: coleta
dos dados e pr-processamento, descoberta de

padres e anlise de padres. Na fase de prprocessamento, os dados de clickstream so limpos

e particionados em um conjunto de transaes do
usurio que representam as atividades de cada
usurio durante diferentes visitas ao site. Outras
fontes de conhecimento, tais como o contedo do
site ou da estrutura, bem como o conhecimento
semntico das ontologias de domnio do site (tais
como catlogos de produtos ou hierarquias
conceito), tambm pode ser usado em prprocessamento de dados ou de melhorar a
transao do usurio. Na fase de descoberta de
padres, estatsticas, banco de dados e operaes
de mquinas de aprendizagem so realizados para
obteno de padres escondidos refletindo o
comportamento tpico dos usurios, bem como
resumos estatsticos sobre os recursos da Web,
sesses e usurios. Na fase final do processo, os
padres descobertos e as estatsticas so
futuramente processados, filtrados, possivelmente
resultando em modelos de usurios agregados que
pode ser utilizado como entrada em aplicaes tais
como sistemas de recomendao, ferramentas de
visualizao e anlise Web e ferramentas de
gerao de relatrios.
3.2 Minerao de Regras de Associao
As Regras de associao so uma importante classe
para encontrar relacionamentos ou padres
frequentes entre conjuntos de dados. Minerao de
regras de associao uma tarefa fundamental de
minerao de dados. talvez o modelo mais
importante inventado e amplamente estudado pela
comunidade de banco de dados e minerao de
dados. Desde que foi introduzido por R. Agrawal e
Swami (1993), tem atrado muita ateno. Muitos
algoritmos eficientes, extenses e aplicaes tm
sido relatados.
Como exemplo de uma aplicao clssica de regras
de associao pode-se citar um carrinho de
compras em um supermercado, onde o objetivo
desta aplicao descobrir quais itens existentes
no carrinho de compras dos seus clientes esto
associados. Uma regra de associao por
exemplo:
Carne Cerveja *suporte = 10%confianca = 80%+
A regra extrada no exemplo citado diz que 10% dos
clientes compram carne e cerveja, e 80% de quem
compra carne tambm compra cerveja. Suporte e
66

confiana so duas medidas de fora de regra, que

sero definidos no decorrer do trabalho.
Este modelo de minerao de fato muito geral e
que pode ser usado em muitas aplicaes.
Por exemplo, no contexto da Web e documentos de
texto, ele pode ser usado para encontrar relaes
de co-ocorrncia de palavras e padres de uso da
Web.
3.2.1 Conceitos Bsico sobre Regras de Associao
O problema de minerao de regras de associao
pode ser declarado do seguinte modo (R. Agrawal e
Swami (1993)): seja L = i1, i2, . . . , in um conjunto
literais chamados de itens.
Seja D um conjunto de operaes (transaes), no
qual cada transao T um conjunto de itens tal
que T L. Associado com cada transao est um
atributo que a identifica unicamente, chamado TID.
Uma transao T contm X, sendo X um conjunto
de itens em L, se X T.
Uma regra de associao uma implicao do tipo
X Y, onde X L, Y L e XY = .
A regra X Y vlida no conjunto de transaes D
com o grau de confiana c, se c% das transaes em
D que contm X tambm contm Y . A regra X Y
tem suporte s em D se
s% das transaes em D contm X Y . Um
conjunto X contendo k itens chamado de um
conjunto-de-k-itens. O conjunto de itens X, que
aparece esquerda do operador de implicao,
denominado antecedente (ou precedente) da regra;
por sua vez, o conjunto de itens Y , que aparece
direita do operador, denominado de
consequente.
O problema na minerao de regras de associao,
dado um conjunto de transaes, est em gerar
todas as regras que tenham suporte e confiana
maiores do que os valores mnimos
definidos pelo usurio, os quais, geralmente, so
referidos
como
minsup
e
minconf,
respectivamente. Se o suporte de um conjunto de
itens for maior ou igual ao mnimo estabelecido
(sup(X) minsup), diz-se que frequente. O
suporte de uma regra X Y dado por sup(XY ) e a
sua confiana sup(XY )/sup(X) (Agrawal et al.
(1996)). Dentro do conceito de que uma regra tratase de uma afirmao sobre uma distribuio
probabilstica, o suporte pode ser descrito como a
probabilidade de que uma transao qualquer
satisfaa tanto X como Y , ao passo que a confiana

a probabilidade de que uma transao satisfaa Y

, dado que ela satisfaz X.
Um grande nmero de algoritmos de minerao de
regras de associao, tm sido relatados na
literatura, onde cada um com diferentes benefcios
na minerao. Os conjuntos de regras resultantes
so, no entanto, todos iguais com base na definio
de regras de associao. Isto , dado um conjunto
de dados de transaes T, um minsup e uma
minconf, o conjunto de regras de associao
existentes em T unicamente determinado.
Qualquer algoritmo deve encontrar o mesmo
conjunto de regras, embora sua eficincia
computacional e os requisitos de
memria pode ser diferente. Este trabalho prope a
utilizao do algoritmo Apriori proposto por
Agrawal e Srikant (1994), que ser descrito abaixo.
3.2.2 O Algoritmo Apriori
O algoritmo Apriori foi proposto em 1994 pela
equipe de pesquisa do Projeto QUEST da IBM que
originou o software Intelligent Miner. Trata-se de
um algoritmo que resolve o problema da minerao
de itemsets frequentes, isto , dados um banco de
dados de transaes D e um um nvel mnimo de
suporte _, o algoritmo encontra todos os itemsets
frequentes com relao a D e _.
O algoritmo Apriori funciona em duas etapas:
1. encontrar todos os conjuntos de itens
freqentes, isto , com suporte acima do suporte
mnimo estabelecido. Por ser a etapa mais onerosa
em termos de uso de CPU e de E/S, esta recebe a
maior ateno no projeto de algoritmos de
minerao como o caso do Apriori;
2. para gerar as regras de associao utilizando os
conjuntos de itens freqentes, devem-se selecionar
apenas as regras que possuam o grau de confiana
mnimo, correspondente a
minconf, o que pode ser implementado da seguinte
forma: para cada conjunto de item freqente l,
encontram-se todos os subconjuntos no vazios de
l; para cada subconjunto a, gera-se uma regra na
forma a (l a), se o suporte de l dividido pelo
suporte de a for, no mnimo, igual ao minconf..
Esse algoritmo faz diversas passagens sobre a base
de transaes para encontrar todos os conjuntos de
itens freqentes; em cada um desses passos,
primeiro, gera conjuntos de itens candidatos e,
depois, percorre a base de dados para determinar
67

se os candidatos satisfazem o suporte mnimo

estabelecido. Na primeira passagem, o suporte para
cada item individual (conjuntos-de-1-item)
contado e todos aqueles que satisfazem o suporte
mnimo so selecionados,
constituindo-se os conjuntos-de-1-item freqentes.
Na segunda iterao, conjuntosde- 2-itens
candidatos so gerados pela juno dos conjuntosde-1-item e seus suportes so determinados pela
pesquisa no banco de dados, sendo, assim,
encontrados os conjuntos-de-2-itens freqentes.
Assim, o algoritmo, apresentado na Figura 4,
prossegue iterativamente, at que o conjunto-de-kitens frequentes encontrado seja um conjunto
vazio.
Esse algoritmo usa o princpio de que cada
subconjunto de um conjunto de itens frequente
tambm deve ser frequente. Tal constatao
utilizada para reduzir o nmero de candidatos a
serem comparados com cada uma das transaes
no banco de dados. Todos os candidatos gerados
que contenham algum subconjunto que no seja
frequente so eliminados.
4 ARQUITETURA ORIENTADA A SERVIOS
Arquitetura de software uma descrio de um
sistema de software em termos de seus
componentes principais, as relaes deles, e a
informao que passam entre eles. Em essncia,
arquitetura um plano para construir sistemas que
satisfazem para exigncias bem-definidas e, atravs
de extenso, sistemas que possuem caractersticas
precisaram satisfazer as exigncias agora e no
futuro.
O propsito fundamental de arquitetura de
software ajudar administrar a complexidade de
sistemas de software e as modificaes que
sistemas inevitavelmente sofram em resposta a
mudanas externas no negcio, organizacional, e
ambientes tcnicos.
Segundo ANSI/IEEE (2000), uma arquitetura de
software trata basicamente de como os
componentes fundamentais de um sistema se
relacionam intrinsecamente e extrinsecamente
(ANSI/IEEE (2000)). Enquanto arquitetura de
software tradicional enfocada na construo de
aplicaes de software, SOA enfocado na
construo de solues com um empreendimento
ou mbito inter-organizacional, baseado nas
interaes entre consumidores com necessidades

(frequentemente processos empresariais)

provedores com capacidades (servios).

SOA um estilo arquitetnico para construir

solues de empreendimento baseado em servios.
Mais especificamente, SOA se preocupa com a
construo independente de servios negcioalinhados que podem ser combinados em
significantes, processos de negcio de alto nvel e
solues dentro do contexto do empreendimento.
A arquitetura orientada a servios uma
abordagem da tecnologia da informao ou uma
estratgia em que as aplicaes fazem o uso dos
servios disponveis em uma rede, tais como a
internet. O conceito de SOA permite encontrar uma
soluo relativamente barata e com um custo
benefcio maior quando se refere a sistemas que
precisam conversar entre si e processos que
demandam maior flexibilidade e agilidade para
atender as revolues do mercado. A arquitetura
orientada a servio representa um novo modelo de
evoluo para a construo aplicaes distribudas
Erl (2004).
A arquitetura orientada a servios atualmente
reconhecida como um tipo de desenvolvimento
significativo, especialmente para sistemas de
aplicaes de negcios. Ela permite maior
confiabilidade,
integridade
de
mensagem,
integridade transacional e segurana de mensagem.
A Figura 5mostra o conceito de SOA que resume as
trs principais entidades emuma soluo tpica da
arquitetura orientada a servios:
Consumidor de servio
Produtor de servio
Diretrio de Servio
H ento dois pontos importantes no processo de
Arquitetura Orientada a Servios, o consumidor,
que consome e requisita os resultados ao provedor,
ou seja, o outro lado da questo executa o servio e
responde s necessidades [Figura 5].
O importante que para ser considerado
arquitetura SOA, um componente deve ser um
servio, o que implica em: granularidade grossa;
relevncia e alto nvel da transao executada;
baixo acoplamento; interface bem definida e
detalhes de implementao bem encapsulados
5 VIABILIDADE PARA O DESENVOLVIMENTO DE
SITES ADAPTATIVOS UTILIZANDO TCNICAS
DEWEB MINING
68

O desenvolvimento de diferentes tipos web sites

adaptativos
tm
sido
muito
explorado
recentemente.
bastante comum web sites permitirem aos seus
utilizadores personalizar o local para os mesmos. A
maioria dos "portais", por exemplo, permitem
personalizaes manual, tais como listas dos links
favoritos, imagens, cotaes de aes do interesse
do utilizador, relatrio de condies climticas
locais, entre outras funes. Um site tambm pode,
por exemplo, manter o controle das pginas que
foram alteradas desde a ltima visita de um
determinado usurio.
Alguns sites tambm permitem que seus usurios
descrevam os seus interesses e a partir disso
apresenta informaes relevantes para esses
interesses. Sites mais sofisticados realizam
previses de caminhos: supe que o usurio quer ir
em um determinado lugar e direciona-o de
imediato (ou, pelo menos, fornece um link). A
previso de caminho pode ser feito on-line,
prevendo o objetivo do usurio com base em seu
caminho, at ento, ou pode ser feito offline,
estaticamente calculado com base em modelos de
usurio. Em Joachims T. (1997) proposto o
sistema WebWatcher que aprende a prever quais
links os usurios iro acessar em uma pgina
especfica, em funo de um modelo de seus
interesses. O WebWatcher destaca graficamente o
link, que um determinado usurio provavelmente
ir acessar e o repete na parte superior da
pgina quando a mesma apresentada. J em Fink
J. (96) proposto o sistema AVANTI que centra-se
na personalizao dinmica baseada nos gostos e
necessidades dos usurios. Com
base no que sabe sobre o usurio, o AVANTI tenta
prever tanto o objetivo final do usurio e seu
provvel prximo passo., destacando os links que
levam diretamente s pginas que ele pensa que
um usurio vai querer acessar, baseado no
interesses do usurio. Os dois sistemas
apresentados dependem, em parte, de informaes
fornecidas pelos usurios quando eles entrarem no
site. Em Yan T. (1999) proposto uma abordagem
de personalizao automtica. realizado tcnicas
de minerao de dados na web, mais
especificadamente uma clusterizao sobre os
arquivos de log do site, a fim de identificar as
categorias de usurios. Essas categorias podem ser

utilizadas para classificar novos visitantes do site,

para personalizar o site enquanto eles navegam.
Por exemplo, links que so muito acessados por
outros membros da categoria podem ser
destacados.
A fim de tornar possvel a minerao uma tarefa
mais fcil de ser implementada poderia ser utilizado
a proposta feita por Dias (2008), que propem a
utilizao de uma nova arquitetura
para desenvolvimento de software, SOA
(Arquiteturas Orientadas a Servios), que tem como
principal objetivo o reuso intenso dos seus
componentes (servios) para que, em mdio prazo,
a tarefa do desenvolvimento de uma aplicao seja
primordialmente a tarefa da composio e
coordenao dos servios j implementados,
aumentando o reuso e diminuindo o dispndio de
recursos.
A proposta que estas tcnicas sejam aplicadas na
construo de sites adaptativos proporcionando
maior qualidade destes sistemas e fazer uso das
tcnicas de minerao de dados na web juntamente
com os benefcios que a Arquitetura Orientada a
Servios se prope.
6 METODOLOGIA PARA O DESENVOLVIMENTO DE
SISTEMASWEB
ADAPTATIVOS
UTILIZANDO
MINERAO DO USO DAWEB
Ao desenvolver um web site, o desenvolvedor
meticulosamente cria a aparncia do site, a
estrutura das informao e determina os tipos de
interaes que devem estar disponveis. Diante
disso, Acreditamos que deveria ser feita uma
distino severa entre as mudanas estratgicas
(longo prazo) e as tcnicas de adaptao (curto
prazo) ao implementar um web site adaptativo,
uma vez que devemos evitar danos estrutura do
site.
Este cenrio e pesquisas de outros trabalhos nesta
rea nos levou a formular as seguintes
consideraes para o desenvolvimento de um web
site adaptativo:
Evitar que os usurios preencham questionrios
sobre interesses: Usurios da internet no
interessam por trabalho extra (por exemplo,
preenchimento de questionrios), especialmente se
no tem uma recompensa clara, e podem optar por
sair e no participar.

69

 Fazer com que o site seja mais fcil de se usar

para todos usurios, incluindo usurios que esto o
acessando pela primeira vez, usurios casuais, etc.
Proteger o design original do site de mudanas
destrutivas: Limitar as transformaes de modo que
as mesmas no modifiquem a estrutura do site.
Podemos acrescentar links, mas
no remov-los, criar pginas, mas no destru-las,
adicionar novas estruturas, mas no embaralhar as
j existentes.
Manter o desenvolvedor no controle. O
desenvolvedor precisa de se manter no controle do
site, tanto para obter confiana nas tcnicas de
adaptao automtica e evitar possveis mudanas
indesejveis.
Diante do exposto e da identificao das
necessidades dos sistemas web adaptveis
podemos definir uma metodologia para que estes
sistemas possam ser desenvolvidos atendendo a
todas as necessidades para se obter o resultado
esperado no processo de adaptao de um site.
Considerando que o processo de desenvolvimento
de interface no uma atividade top-down (Batista
(2008)), prope-se ummodelo que descreve uma
seqncia iterativa de etapas, de forma a facilitar o
desenvolvimento de um sistema web adaptativo.
No modelo apresentado na Figura 6, pode se
observar todas as etapas que iro compor o
desenvolvimento do sistema, que permite ao
projetista obter uma viso global do processo de
desenvolvimento e realizar um trabalho
estruturado, sistemtico e organizado. A anlise
inicia a seqncia de etapas; ao percorrer o sentido
horrio, faz-se a transio para as seguintes etapas:
observao, transformao e aplicao.
6.1 Anlise
Enquanto no desenvolvimento de sistemas no
adaptativos, d incio ao processo a partir da etapa
levantamento de dados, iniciamos sua atividade
definindo e analisando os objetos referente a
adaptao do site. Ou seja, a etapa do
levantamento de dados j foi realizada para
construir os modelos do usurio, do domnio, da
navegao e da adaptao. Cabe ento nesta
etapa definir os objetivos a serem alcanados com a
aplicao dessas estratgias. Somente com esses
objetivos definidos que as estratgias podero ser
projetadas. O administrador de um site pode ter

diversos motivos para decidir aplicar estratgias de

personalizao em um web site.
Pode-se classificar esses motivos da seguinte forma:
1. Funcionais: O administrador do site quer facilitar
a visita do usurio. A estrutura do site deve ser
rearranjada de forma que o usurio encontre o que
estiver procurando ou que acesse sees que o
interessam e com facilidade.
2. Comerciais: Neste caso, se o objetivo fomentar
a venda de um determinado produto. O
administrador espera que depois da personalizao
aumente o nmero de vezes que uma ao ocorra,
por exemplo, pagar o produto "A".
6.2 Observao
Considerando um web site, a necessidade de tornlo adaptativo e os objetivos a serem alcanados
com a personalizao, o prximo passo do processo
deve ser a coleta de dados. Nesta fase, o objetivo
coletar os dados relacionados aos usurios do site
e, opcionalmente, dados relacionados ao negcio
do site. Deve-se ressaltar que no possvel realizar
uma anlise da eficincia da estrutura do site, com
o fim de alterar esta estrutura, se no existem
dados sobre interao dos usurios com o mesmo.
Neste ponto, pode-se considerar as seguintes
perspectivas (Perkowitz e Etzioni (2009)):
1. Limpeza dos Dados: Limpeza de dados
geralmente especifica de cada site, e envolve
tarefas tais como, a remoo de referncias a
objetos estranhos embutido que pode no ser
importante para fins de anlise, incluindo
referncias a arquivos de estilo, grficos ou
arquivos de som.
2. Identificao dos usurios: Define se os dados
coletados sero utilizados para identificar o usurio.
Usurio identificado: nesse caso, possvel
guardar as informaes de cada usurio, e a cada
vez que ele retornar ao site, estas informaes
podem ser aproveitadas. possvel analisar o
comportamento dos usurios ao longo de um
perodo de tempo e perceber quais partes do site
esto sendo descobertas e em qual ordem.
Usurio no identificado: no necessrio para
tornar um site adaptativo que os seus usurios
sejam identificados. Quando a forma de aquisio
dos dados atravs do log do servidor web, pode
ser que apenas a identificao das sesses seja
suficiente. Essa situao pode ser comparada s
70

anlises realizadas com os dados de compra de um

supermercado, onde a identidade do comprador
no considerada quando se aplica as tcnicas de
minerao de dados.
3. Fonte de dados: Trata da natureza dos dados
coletados. Especifica quais tipos de dados sero
utilizados na prxima fase, a de transformao.
Dados de acesso dos usurios: para descobrir
detalhes do comportamento dos usurios do site,
suficiente conhecer as pginas acessadas em cada
sesso e a ordem em que elas foram acessadas. As
preferncias dos usurios podem ser inferidas
atravs das pginas do site que ele acessou.
Dados pessoais dos usurios: se informaes
pessoais dos usurios do site estiverem disponveis
- como profisso, cidade/regio/pas onde mora,
estado civil outros tipos de anlises podem ser
realizadas. O site pode descobrir com estas anlises
que o perfil dos usurios do site , por exemplo,
homem, executivo e casado. Com essa informao,
pode destacar os links para as pginas relacionadas
ao Mercado de
Executivo.
Dados do mercado: utilizar dados de um data
warehouse, como por exemplo os dados das vendas
realizadas pela empresa que no foramfeitas via
Internet (Gomory et al. (2000)). Informaes de
quais produtos so vendidos juntos podem ser
obtidas neste data warehouse e aproveitadas nas
vendas via Internet.
4. Forma de aquisio dos dados de acesso:
Especifica a forma como os dados so coletados,
definindo se este processo ou no transparente
ao usurio.
No transparente: o usurio, voluntariamente,
pode fornecer dados para o site. Por exemplo, o
site pode fazer perguntas ao usurio para saber
qual o seu objetivo naquela sesso e saber se ele foi
ou no alcanado. Assim, pode criar um histrico de
acessos, baseado nos sucessos e insucessos dos
usurios.
Transparente: o site pode coletar as informaes
de acesso do usurio sem que ele precise responder
qualquer tipo de questionrio. Num arquivo de log
esto todas as requisies feitas ao servidor web
com o endereo IP da mquina que fez as
requisies e a data/horrio do acesso. possvel
identificar sesses e identificar qual a ordem de
acesso das pginas de um site, durante uma sesso.

Com estas informaes, j possvel realizar alguns

tipos de anlises.
6.3 Transformao
Depois que j foram coletados dados suficientes,
preciso descobrir padres de acesso (ou de
comportamento), os perfis dos usurios,
tendncias, para que a estrutura do site possa ser
melhorada. Os dados coletados na fase de
observao precisam ser trabalhados, relacionados
e bem entendidos para que informaes vlidas
sejam produzidas.
nesse contexto que entra em cena a
transformao, cujo objetivo obter informaes a
partir de dados. Nesta fase, vrias decises
caracterizam a estratgia:
1. Tcnicas de anlise: Esta tcnica identifica quais
tcnicas de anlise sero utilizadas para explorar os
dados.
Padres Informativos: quando no se tem um
problema especfico, uma forma de se obter
informaes de uma grande massa de dados
utilizando tcnicas para descobrir padres
informativos. Os algoritmos de agrupamento so
bons exemplos para este tipo de padro. Eles
identificam caractersticas comuns a um conjunto
de entradas de forma a particionar a base de dados
de acordo com os seus atributos. Uma possvel
aplicao nesse caso, seria descobrir os perfis de
usurios que acessam um site, com base nas
pginas visitadas e nas palavras pesquisadas, ou
mesmo com as suas caractersticas pessoais.
Padres de previso: dada uma entrada de dados
e os seus atributos, padres de previso tm o
objetivo de fazer uma estimativa razovel de um
atributo desconhecido com base em outros
atributos conhecidos. Redes neurais e regresso
linear vm sendo amplamente utilizadas para
determinao de padres de previso e tambm
podem ser usados para gerar as regras de
transformao do site.
2. Nvel de automatizao: Define se a fase de
transformao estimula ou no, para que o
administrador do site participe nas dedues sobre
a personalizao.
No automatizado: uma abordagem interessante
que o sistema estimule a interao do
administrador do site em momentos em que as
heursticas aplicadas no conseguem decidir qual
caminho seguir. Por exemplo, um sistema pode
71

identificar que determinados grupos de pginas so

acessadas simultaneamente, e sugere ento ao
administrador do site que seja criada um pgina no
site com links para essas pginas. Nesse caso, o
administrador do site ficaria encarregado de
descobrir a que
assunto essas pginas esto relacionadas e dar um
ttulo para a nova pgina do site.
Automatizado: se a tcnica de transformao dos
dados no depender da interferncia humana, o
processo exige uma menor interao do
administrador do site que, em alguns casos, pode
ser a melhor opo
6.4 Aplicao
Durante a fase de transformao, obteve-se
conhecimento sobre os padres de acesso ao site e
o que fazer para melhor-lo. Na fase de aplicao,
deve-se aplicar este conhecimento adquirido na
estrutura do site. Neste ponto, pode-se considerar
as seguintes perspectivas:
1. Escopo das aplicaes: Define qual o alcance das
transformaes.
Global: nesse caso, o site aprende com os dados
dos usurios e faz alteraes permanentes na
estrutura do site. Quando a fase de transformao,
por exemplo, sugere a criao de uma nova pgina,
a aplicao da tcnica ento altera definitivamente
a estrutura do site.
Local: o site dinmico e se adapta
sesso/usurio corrente. Quando a tcnica utilizada
apenas inclui links no permanentes na pgina que
est sendo acessada, esta alterao no
definitiva. A cada sesso, a estrutura do site pode
sofrer transformaes diferentes, que sero
desfeitas assim que aquela sesso terminar.
2. Automatizao: Define se as mudanas feitas no
site necessitam da autorizao do administrador do
site.

As
transformaes
so
aplicadas
automaticamente: nesta abordagem, o site pode
interagir diretamente com o usurio, alterando as
pginas pelas quais est navegando, sem que haja a
permisso de um administrador do site.
As transformaes so apenas sugeridas: o site
pode apenas sugerir mudanas na estrutura para o
administrador do site e ele as aplica se achar
conveniente. Esta abordagem geralmente leva a
transformaes definitivas na estrutura do site.

3. Recurso de formatao: Identifica quais recursos

de formatao das pginas so utilizados na
aplicao das mudanas.
Proprietrio: j foram desenvolvidos alguns tipos
especiais de linguagens de marcao, destinado a
sites adaptativos. Uma pgina pode ser construda
com tags especiais no HTML e as adaptaes so
feitas nas regies delimitadas por essas tags.
Por exemplo, essa tag pode ter argumentos que
indicam que um link deve ser destacado, caso a
pgina seja visualizada por um determinado
usurio, num determinado contexto.
Pblico: o HTML ou XML padro so utilizados e
os recursos de adaptao so feitos utilizando as
tags j existentes.
4. Amplitude das transformaes: Identifica quais
regies do site sero afetadas durante a fase de
aplicao.
5.
6. As regies "adaptveis" so fixas, prdeterminadas: o site pode, por exemplo, ter um
frame superior onde sempre aparecem links
relacionados com a pgina corrente ou os links que
as pessoas seguem depois que acessam a pgina
corrente. Esta uma forma simples de aplicar o
conhecimento adquirido na fase de transformao.
7. As adaptaes podem ocorrer em qualquer lugar
do site: nesse caso, nenhuma regio do site
destinada somente a adaptaes. Essas podem
ocorrer em qualquer parte da estrutura do site.
7 ARQUITETURA PROPOSTA DO WEB SITE
ADAPTATIVOS
Diante do exposto e da identificao das etapas
compostas no desenvolvimento de um web site
adaptativo podemos definir uma arquitetura de alto
nvel, como mostra a Figura 7.
O primeiro passo de um web site adaptativo
agrupar seus visitantes atravs de um padro de
minerao de dados, o prximo passo selecionar
as transformaes para o site de cada usurio ou
grupo. As transformaes selecionadas para cada
usurio ou grupo so armazenadas no servidor web
para serem utilizadas. Quando um usurio visita o
site, no futuro, o servidor verifica qual grupo o
mesmo pertence e realiza sua transformao
correspondente. A pgina web solicitada enviada
a partir do servidor, transformada e em seguida
enviada para o visitante. Com esta implementao
72

as
caractersticas
e
vantagens
descritas
anteriormente podero ser
absorvidas pelos sistemas e fornecendo a
capacidade de integrao com diferentes fontes de
dados (logs de servidor) permitindo assim a
adaptao do web site.
8 CONCLUSO
Este trabalho teve como objetivo apresentar um
estudo exploratrio sobre as vantagens de se
adotar tcnicas de minerao do uso da web e
regras de associao, juntamente com a utilizao
do conceito de Arquitetura Orientada a Servios e
uma possvel arquitetura para estes sistemas para
sua implementao. A adaptao de web site
apresenta-se como uma aplicao e rea de
pesquisa com excelentes perspectivas de futuro
devido variedade de informaes e perfis de
usurios disponveis na internet. So inmeras as
vantagens obtidas com a aplicao de tcnicas de
minerao do uso da web, regras de associao e
SOA conforme foram apresentadas. A aplicao
destas vantagens em sistemas web adaptveis
poder proporcionar inmeros benefcios tanto
para os web sites como para seus usurios,
trazendo qualidade tanto na usabilidade, como na
interao dos seus visitantes, visando a excelncia
nos seus resultados e atendendo a natureza
dinmica e heterognea da Web. Por fim, acreditase que a metodologia e a arquitetura proposta
trazem contribuies para facilitar a atividade
projetual dos profissionais nas reas do Design e de
Tecnologia da Informao e Comunicao a
desenvolverem sistemas web adaptveis.
1 Introduo
Vrios processos de software tm sido propostos ao
longo dos anos. Essencialmente todos tentam
definir um roadmap que guie o desenvolvimento,
identificando quem est fazendo o qu, onde, por
que, como e quando. Um processo de software
definido com um conjunto de atividades
interdependentes que visam desenvolver, manter e
gerenciar sistemas de software. Estas atividades
podem ser compostas de outras atividades e so
executadas por atores que desempenham um papel
no processo (programador, gerente, cliente, etc.).
Como resultado das atividades, so produzidos
artefatos (cdigo, documentao, modelos) que
servem de entrada para outras atividades para

produzir novos artefatos. Sem um processo de

software, o risco de falha do projeto se torna muito
alto, em especial para as aplicaes web modernas
cuja complexidade no pra de crescer.
Com o passar dos anos, as aplicaes web
evoluram rapidamente de simples web sites cujo
propsito era apenas navegao sobre a
informao para verdadeiros sistemas de
informao altamente complexos, repletos de
dados e transaes, voltados para a implementao
de processos de negcio intra- e inter-organizao.
Diante deste quadro, a necessidade de um processo
de software sistemtico que ajude a gerenciar o
ciclo de vida de tais aplicaes surge naturalmente.
Poder-se-ia argumentar que sistemas web no so
diferentes, sob o ponto de vista de processo de
software, de sistemas de software convencionais.
No obstante, existe um crescente reconhecimento
que sistemas web possuem caractersticas
particulares que no so apropriadamente
consideradas pelos processos de software
tradicionais. O desenvolvimento de aplicaes web
realizado por equipes multidisciplinares, com
diferentes habilidades, em prazos curtssimos
ditados pela voraz concorrncia e em um contexto
extremamente volvel, marcado por incertezas.
Para
completar,
sistemas
web
so
tecnologicamente muito abstrusos, reunindo
padres, protocolos e tecnologias diversas na
definio de uma arquitetura que encapsule em um
front-end amigvel um back-end que pode ser por
demasiado complexo e heterogneo.
Em muitos casos, as equipes de desenvolvimento,
acometidas pelas severas restries de tempo,
adotam solues ad-hoc para construir tais
aplicaes. Neste cenrio, o sucesso do projeto
depende muito da habilidade e conhecimento dos
membros da equipe, com os usuais efeitos
colaterais negativos em flexibilidade, qualidade e
robustez da aplicao [Sampaio et al, 2004a].
Como de se esperar, paralelamente s diferenas,
tambm co-existem pontos em comum entre
aplicaes web e convencionais. Portanto, um
caminho
interessante
seria
delinear
as
peculiaridades deste domnio de aplicao e
adaptar ou enriquecer processos de software j
existentes de forma a contemplar mais claramente
as necessidades especficas da web.
Sob a tica deste trabalho, importante ressaltar a
diferena entre aplicao na web e aplicao web.
73

Aplicao na web qualquer tipo de aplicao que

utiliza a web como ambiente de execuo. Um
simples repositrio de arquivos ou uma aplicao
com estilo tradicional desktop, composta apenas
por buscas e formulrios, so exemplos de
aplicao na web. J aplicaes web so aquelas
que, necessariamente, exploram o paradigma
hipermdia. Em outras palavras, no contexto deste
trabalho, somente so consideradas aplicaes web
aquelas que possuem uma estrutura navegacional
bem definida, fazendo jus ao elemento
fundamental da web que a noo de hiperlink. O
grande desafio das aplicaes web modernas
integrar, elegantemente, dois paradigmas capitais:
hipermdia e transao. Sendo assim, este trabalho
procurar evidenciar os requisitos que um processo
de desenvolvimento de software precisa atender de
modo a ser, efetivamente til, nesta integrao.
Esta monografia considera as diferenas entre
aplicaes web e convencionais, destacando as
implicaes na definio de um processo de
software para web. Para tal, definida uma lista de
requisitos que um processo web deve atender e,
com base nesta, so analisadas duas propostas
existentes.
1.1 Processos Orientados a Plano versus Processos
geis
Mais recentemente os processos de software
passaram a ser classificados em duas categorias:
orientados a plano e geis.
Processos orientados a planos so processos mais
rigorosos, preditivos por natureza, onde existe um
plano que procura antever problemas e as
respectivas solues. Ao longo do desenvolvimento
todas as decises de projeto so documentadas e
controladas, antes de serem implementadas. O foco
no processo, ou seja, institucionalizar um
processo de software e segui-lo a risca. Este
processo deve ser continuamente aprimorado.
So exemplos: CMMI - Capability Maturity Model
Integration [Chrissis et al, 2003],
TSP - Team Software Process [Humphrey, 2000],
PSP - Personal Software Process [Humphrey, 1995],
SPICE - Software Process Improvement and
Capability dEtermination [SPICE].
Por outro lado, processos geis tm o foco no
produto em si, ou seja, o mais importante
entregar
software
em
detrimento
de

documentao. So reativos por natureza, onde

atitudes so tomadas sob demanda e
desenvolvido somente o necessrio e
quando
necessrio.
Trata-se
de
um
desenvolvimento iterativo e incremental onde,
constantemente, so entregues novos releases do
produto ao cliente. As ideias podem ser
encontradas no Agile Manifesto *Agile
Manifesto]. Os elementos centrais do manifesto
so:
Pessoas e interaes so mais importantes do que
processos e ferramentas;
Software executvel mais importante do que
documentao;
Colaborao do cliente mais importante do que
negociao por contrato;
Reao a mudanas mais importante do que
plano pr-definido.
Processos rigorosos e processos geis, ambos tm
suas vantagens e desvantagens. No existe
processo correto ou incorreto, existe processo
adequado e inadequado, ou seja, para cada tipo de
projeto necessrio encontrar um ponto de
equilbrio entre as duas abordagens e definir um
processo hbrido que traga benefcios reais [Bohem
e Turner, 2004].
Independentemente de quo rigoroso ou gil seja o
processo, o fato que temos que levar em
considerao como contemplar os requisitos
presentes no desenvolvimento web, discutidos ao
longo deste trabalho. No entanto, o carter
altamente mutvel das aplicaes web nos leva a
crer que uma abordagem mais gil venha mais ao
encontro deste domnio de aplicaes do que um
processo mais rigoroso.
1.2 Organizao da Monografia
A seco 2 explora as diferenas entre sistemas
web e sistemas convencionais. Em seguida, na
seco 3, so enumerados os requisitos que devem
ser levados em considerao quando da elaborao
de um processo de desenvolvimento para web.
Para tornar a discusso mais concreta, a seco 4
apresenta duas propostas de processo web
existentes.
Seguindo na mesma linha, na seco 5, as propostas
apresentadas so analisadas de acordo com os
requisitos descritos anteriormente. Encerrando, a
seco 6 delineia as consideraes finais.
2 Diferenas entre Aplicaes Web e Aplicaes
74

Convencionais
Existe um conjunto de diferenas que justificam a
necessidade de uma ateno especial ao
desenvolvimento de aplicaes web. Algumas
caractersticas so nicas de sistemas web, outras
tambm
esto
presentes
nos
sistemas
convencionais, mas so mais pronunciadas na web.
Com base em [Lowe e Henderson-Sellers, 2001] e
[Kappel et al, 2004], esto seco destaca tais
diferenas que servem como base para a definirmos
os requisitos necessrios para a definio de um
processo de desenvolvimento para web.
A distino feita primeiramente sob um enfoque
tcnico e, em seguido, questes organizacionais so
discutidas.
2.1 Diferenas Tcnicas
Claramente existem diferenas tcnicas entre
sistemas web e convencionais. As mais significantes
so:
Diferenas relativas aplicao:
o Contedo: a web essencialmente um meio de
informao. Alm da funcionalidade, uma aplicao
web orientada a contedo. Contedo
compreende dados estruturados (banco de dados,
por exemplo) e no estruturados (arquivos textos,
vdeos, etc.). Alm disso, o contedo dinmico,
precisa ser continuamente atualizado e de
qualidade em termos de consistncia e
confiabilidade. Isto implica em um efetivo projeto
de informao, bem como gerenciamento de
contedo apropriado.
o Hipertexto: na web o paradigma fundamental
para estruturar a informao noo de hipertexto,
onde os elementos bsicos so: ns,
elos (links) e ncoras que ativam estes elos. Os ns
exibem informaes e os elos nos permitem
navegar entre os ns. Isto requer um projeto
cuidadoso e estratgico de navegao que preserve
a qualidade de acesso e evite desorientao e
sobrecarga cognitiva.
o Apresentao: o look and feel da aplicao web
um fator de qualidade essencial uma vez que
usurios podem facilmente abandonar o site e ir
para outro concorrente. No existe um manual de
usurio, portanto a interface tem que ser autoexplicativa, intuitiva e consistente com o estilo de
interao. Alm disso, a aparncia visual est
sujeita a modismo, tendncias e novas
caractersticas tcnicas que surgem todos os dias.

o Requisitos no-funcionais de qualidade:

requisitos de qualidade como disponibilidade 24/7,
performance, usabilidade, escalabilidade, robustez
e segurana se tornam ainda mais crticos quando
expostos externamente ao pblico.
Diferenas relativas ao uso:
o Ubiquidade: medida que a necessidade de
ubiqidade (ou seja, a possibilidade de acessar a
aplicao por diferentes tipos de dispositivos,
em diferentes contextos de uso) das aplicaes
cresce, torna-se
necessrio projetar diferentes vises da aplicao,
uma para cada contexto de uso.
o Infra-estrutura tecnolgica imprevisvel:
juntamente com o crescente carter ubquo, surge
uma enorme variedade de dispositivos de usurio
final, com diferentes capacidades de hardware e
software, diferentes tamanhos e verses de
navegadores. Conexes de rede diferem com
respeito largura de banda, confiabilidade,
estabilidade e disponibilidade, afetando a questo
de QoS (qualidade de servio).
Por fim, usurios configuram livremente seus
navegadores, podendo desabilitar importantes
funcionalidades.
Diferenas relativas ao desenvolvimento:
o Ambiente de desenvolvimento: a infra-estrutura
tcnica usada para desenvolver sistemas web
caracterizada por exacerbada volatilidade e
heterogeneidade.
As
aplicaes
so
freqentemente
construdas
a
partir de
componente COTS (commercial off-the-shelf) que
so adaptados e integrados, particularmente para
as camadas internas de middleware. Dentre estes
componentes se destacam servidores de aplicao
e frameworks de aplicao e persistncia. Isto
aumenta a importncia de criar solues flexveis
que possam migrar para novas tecnologias com
pouco esforo. Outra conseqncia o domnio
restrito destas tecnologias por parte da equipe,
aumentando o risco do projeto e demandando um
constante aprimoramento do conhecimento.
o Integrao com sistemas legados: aplicaes web
costumeiramente
precisam se integrar com sistema legados. So
sistemas com interfaces antigas e inapropriadas
que, portanto, precisam ser encapsuladas e
adaptadas (wrapping). Este encapsulamento
75

trabalhoso e existe o risco de no ser feito de forma

correta e completa. Sistemas legados raramente
so documentados e freqentemente so
modificados sem notificao, afetando a execuo
do sistema web. Alm disso, as tecnologias para
encapsulamento so vrias e esto sempre
mudando (por exemplo, encapsulamento via web
services).
2.2 Diferenas Organizacionais
Sob o ponto de vista organizacional, as diferenas
mais proeminentes so:
Diferenas relativas ao desenvolvimento:
o Incerteza do cliente: devido alta dinamicidade
da web, este domnio de aplicaes no bem
compreendido pelos interessados (tambm
chamados de stakeholders). Freqentemente o
cliente tem problemas em articular suas
necessidades, bem como em compreender se um
determinado design satisfaz suas expectativas.
Alm disso, muito comum a existncia de projetos
orientados por uma idia visionria ao invs de uma
necessidade bem definida. Isto aumenta a
necessidade de desenvolvimento incremental
baseado em prottipos.
o Alta volatilidade dos requisitos de negcio:
fortemente relacionada questo anterior est a
falta de clareza, por parte do cliente, sobre os reais
impactos que a aplicao web traz para o negcio.
Sendo assim, no surpresa esperar que o escopo e
foco do projeto mudem consideravelmente ao
longo do desenvolvimento. medida que a
empresa vai aumentando sua participao na web,
o prprio modelo de negcio da empresa pode
mudar diante de novas oportunidades outrora
desconhecidas.
o Ciclos de desenvolvimento muito curtos:
projetos web, em geral, tm prazos mais curtos do
que projetos convencionais, comumente de um a
trs meses.
o Alta competitividade: a concorrncia na web
muito mais intensificada pela facilidade do usurio
final visitar vrios sites em um curto espao de
tempo. Portanto, a aplicao precisa estar sempre
atualizada e atraente de acordo com as tendncias
atuais.
o Equipes multidisciplinares: o desenvolvimento de
uma aplicao web um esforo multidisciplinar,
envolvendo profissionais das mais diversas reas,
com habilidades bem dspares. So designers

grficos, autores, engenheiros de software,

programadores, publicitrios, consultores de
negcio, entre outros. Em geral, h muito jovens
inexperientes inclinados a empregar tecnologias
novas de forma ad-hoc.
o Evoluo e manuteno de granularidade fina:
aplicaes web esto sujeitas a mudanas dirias e
permanente evoluo. Tipicamente temos um
processo contnuo de atualizao de contedo,
mudanas editoriais, ajustes de interface, etc. Sem
falar nas mudanas tecnolgicas mais radicais.
Diferenas relativas ao uso:
o Diversidade de tipos de usurio: na web os
usurios variam em idade, conhecimento sciocultural, objetivos, intenes, habilidades e
capacidades. Esta heterogeneidade, diferentes
perfis de usurio, precisa ser considerada, dado que
na web os usurios so inteiramente livres para
escolherem as aplicaes que lhe forem mais
convenientes.
o Sazonalidade (ou caractersticas temporrias):
aplicaes possuem requisitos que so sazonais ou
temporrios,
ou
seja,
informaes
e/ou
funcionalidades
que
so
oferecidas,
estrategicamente, por uma faixa de tempo, que
pode se repetir ou no. Um exemplo so os
contextos navegacionais relacionados ao perodo
natalino.
Analisando o que foi exposto nesta seco,
percebe-se que um processo de desenvolvimento
voltado para aplicaes web caracterizado por
freqentes mudanas e ajustes, que so necessrias
devido rpida evoluo tecnolgica, ao
surgimento de novas tendncias, volatilidade dos
requisitos e aos cronogramas apertados. Um
processo para web precisa ser altamente iterativo,
flexvel e orientado a prottipos.
3 Requisitos de um Processo de Desenvolvimento
Web
Sob a luz das diferenas descritas anteriormente e
do trabalho exposto em [McDonald e Welland,
2004], foram identificados dezessete requisitos que
um processo de desenvolvimento de aplicaes
web deve ponderar. Como era de se esperar, estes
requisitos se confundem com os requisitos que um
mtodo de especificao de aplicaes web (por
exemplo, OOHDM [Rossi, 1996]) deve contemplar,
76

reforando a importncia do emprego de um

mtodo desta natureza ao longo do processo.

XWebProcess e uma proposta mais rigorosa

chamada OPEN-Web Process.

Sendo assim, um processo web deve dar suporte

para:
1. Autoria (ou engenharia) de contedo;
2. Autoria (ou engenharia) de navegao sobre o
contedo;
3. Autoria (ou engenharia) de apresentao
(interface);
4. Ubiqidade;
5. Definio de arquitetura multicamadas
5.1. Escolha, adaptao e utilizao de frameworks
e componentes;
5.2. Integrao com sistemas legados;
5.3. Distribuio das camadas entre servidores;
5.4. Definio do que roda no navegador e do que
roda no servidor;
6. Ciclos de vida de desenvolvimento curtos;
7. Equipes multidisciplinares;
8. Desenvolvimento concorrente de pequenas
equipes em tarefas interdependentes;
9. Pesquisa de mercado;
10. Incerteza do cliente e volatilidade dos
requisitos;
11. Reengenharia de modelos de negcio a partir de
modelos da aplicao;
12. Anlise de negcio e avaliao junto ao usurio
final;
13. Diferentes perfis de usurio (personalizao);
14. Requisitos explcitos (funcionais e nofuncionais);
15. Testes rigorosos com relao aos requisitos;
15.1. Teste de performance, escalabilidade e
resilincia;
16. Autoria (engenharia) de Segurana
16.1. Autorizao por papis de usurio (user role);
16.2. Definio de quais transaes so crticas
(precisam de criptografia) e no-crticas;
17. Manuteno e evoluo em granularidade fina.

4.1 XWebProcess
XWebProcess [Sampaio, 2004] [Sampaio et al,
2004a] [Sampaio et al, 2004b] um processo gil
para desenvolvimento de aplicaes web baseado
nos princpios do XP (Extreme Programming) [Beck,
2000]. O XWebProcess resultado da adaptao do
XP para lidar melhor com importantes questes de
sistemas web: interfaces com usurio complexas,
navegao, requisitos no-funcionais (distribuio,
concorrncia, balanceamento de carga), testes e
suporte de infra-estrutura.
Uma vez que o XWebProcess deriva do XP,
interessante, em primeiro lugar, apresentar uma
breve descrio do XP. O processo gil XP confia em
cinco pilares de valor:
Comunicao: significa que os membros da
equipe devem interagir constantemente para
discutir os problemas e propor solues. Alm
disso, o cliente, o algum que o represente, deve
ser um membro ativo da equipe para elucidar os
requisitos e regras de negcio envolvidos;
Feedback: implica que cada membro da equipe
(programador, gerente, cliente, etc.) deve fornecer
feedback constante sobre os problemas
encontrados para resolv-los o quanto antes;
Simplicidade: consiste em escolher a soluo mais
simples que funcione, ou seja, evitar complexidade
e trabalho desnecessrio. Fazer estritamente o
necessrio e com o design mais simples. Possveis
problemas que surjam em funo desta deciso so
minimizados com prticas como refactoring e testes
automatizados;
Coragem: preciso ter coragem para substituir o
que est ruim ou errado por algo que esteja melhor
ou correto. Ou seja, no tenha medo de fazer
refactoring em grandes partes do cdigo quando
necessrio, bem como descartar requisitos que se
tornem obsoletos.
Respeito: os membros da equipe tm que
respeitar uns aos outros. No XP, programadores
nunca devem confirmar modificaes que faam o
programa parar de compilar, que faam os testes
falharem, ou caso contrrio atrasam o trabalho de
seus companheiros. Devem sempre primar pela
qualidade. Sob outra tica, nenhum membro da
equipe deve se sentir rejeitado ou ignorado, de
forma a manter a equipe sempre feliz e motivada.

4 Duas Propostas Existentes

Diante da crescente necessidade de um processo de
desenvolvimento voltado para aplicaes web, ao
longo dos ltimos anos, alguns processos
especficos e evolues de processos de software
tradicionais foram propostos para web.
A seguir, sero brevemente descritos dois
processos.
Uma
proposta
gil
chamada

77

Para subsidiar os quatro pilares acima, XP prope

algumas prticas que so, resumidamente,
descritas a seguir:
Planning game (Jogo de Planejamento): um
release deve ser o menor possvel (dois a trs
meses). Cada release dividido em iteraes
semanais (duas a trs semanas), onde historietas
(pequenos casos de uso) so implementados. No
incio da semana, desenvolvedores e cliente
renem-se para analisar as funcionalidades. O
esforo estimado para implementar cada historieta
definido pelos programadores e o cliente define a
prioridade da historieta.
Small Releases (Pequenas Verses): um release
deve ser pequeno de forma a facilitar o
desenvolvimento, bem como o processo de
aceitao e satisfao por parte do cliente.
Metaphor (Metfora): metfora do sistema
uma histria que todos (clientes, programadores,
gerentes, etc.) podem contar sobre como o sistema
funciona. Enfim, uma histria que facilite o
entendimento comum sobre os conceitos
(abstraes) envolvidos.
Simple Design (Projeto Simples): projetar, de
forma simples, estritamente o necessrio sob
demanda.
Whole Team (Equipe Coesa): o cliente deve ser
um membro efetivo da equipe, disponvel para
esclarecer eventuais questionamentos.
Customer Tests (Testes de Aceitao): testes
construdos pelo cliente, em conjunto com analistas
e testadores, para validar um ou mais requisitos do
sistema. Tambm chamados de testes funcionais.
Sustainable Pace (Ritmo Sustentvel): a equipe
deve trabalhar em um ambiente adequado e
agradvel, sempre motivada e sob um ritmo de
trabalho saudvel (40 horas/semana, 8 horas/dia)
sem horas extras. Horas extras somente se forem
impreterivelmente necessrias.
Stand-up Meeting (Reunies em P): reunies
em p (por exemplo, no incio do dia) para no
perder o foco, somente abordando o que foi
realizado e prximas tarefas a realizar. Estas
reunies devem ser de curta durao.
Collective Ownership (Posse Coletiva): o cdigo
fonte um bem comum, ou seja, qualquer membro
da equipe pode alterar qualquer parte do cdigo
sem precisar pedir permisso. Todos devem ter
conhecimento de todas as partes do cdigo.

Pair Programming (Programao em Par): todo

cdigo produzido por um par de programadores.
Um programador codifica e outro analisa, sugerindo
melhoramentos e prevenindo erros. Os pares so
freqentemente modificados, fazendo com que os
programadores participem do desenvolvimento de
diferentes historietas, obtendo, desta forma, um
conhecimento geral de todo o sistema;
Coding Standards (Padres de codificao):
devem ser definidos padres (regras) de
estruturao do cdigo. Estas regras devem ser
seguidas, garantindo assim uma homogeneidade
em todo cdigo, facilitando o entendimento.
Test Driven Development (Desenvolvimento
Orientado a Testes): primeiro crie os testes
unitrios e, somente depois, crie cdigo que passe
nos testes. Tal prtica ajuda a manter a qualidade
do projeto.
Refactoring (Refatorao): o cdigo deve ser,
sempre que necessrio, melhorado, sem alterar a
funcionalidade.
Juntamente
com
testes
automatizados (automated testing) ajuda a manter
a qualidade do cdigo, dado que toda vez que
ocorre uma alterao todos os testes, na ntegra,
tm que ser
passados com sucesso. Toda funcionalidade pode
ser alterada por qualquer membro da equipe.
Continuous Integration (Integrao Contnua): a
equipe de desenvolvimento deve trabalhar sempre
na ltima verso do projeto. Sempre que uma nova
funcionalidade for produzida e passar nos testes,
esta deve ser integrada a verso atual do sistema,
no repositrio de cdigo. Isto evita atrasos mais
tarde devido a problemas de integrao.
O processo XWebProcess foi criado adaptando
elementos do XP e adicionado novos elementos de
forma a customizar o XP para o domnio web.
Primeiramente o XP foi modelado usando o metamodelo SPEM [SPEM] para melhor entendimento.
Em seguida, com base nas caractersticas das
aplicaes web, o modelo SPEM do XP foi
enriquecido gerando o modelo SPEM do
XWebProcess. Sendo assim o XWebProcess pode ser
visto como uma extenso do XP, como mostra a
figura 1.
O XWebProcess descrito, em SPEM, usando duas
vises: viso dinmica e estrutural.
A viso dinmica mostra como as disciplinas1 esto
relacionadas entre si durante a execuo do
78

processo, ao longo do tempo. J a viso estrutural

descreve a estrutura interna de cada disciplina,
destacando atividades, artefatos produzidos e
atores envolvidos, bem como os relacionamentos
entre eles.
A figura 2 ilustra a viso dinmica do XWebProcess.
Nesta figura, as disciplinas em destaque so
disciplinas inseridas ou modificadas no XP.
1 Uma disciplina em SPEM representa um conjunto
de elementos de processo relacionados (atividades,
artefatos, atores) agrupados por um tema comum.
Exemplos de disciplinas so: anlise, design, testes,
etc.
O processo comea com uma disciplina exploratria
que foi modificada para incluir sesses de
prottipo. O objetivo avaliar, junto ao cliente e
analistas de negcio, tecnologias, arquiteturas e
prottipos para verificar a viabilidade do projeto e
definir os requisitos iniciais.
Em seguida, temos a disciplina de definio e
reviso dos requisitos. Nesta, clientes e
programadores definem as historietas para o
prximo release. Programadores estimam o esforo
necessrio para cada historieta e os clientes
definem as prioridades das historietas. Esta
disciplina foi modificada para incluir uma atividade
de design de arquitetura, visando definir uma
estrutura flexvel que permita, mais facilmente,
integrao
com outros sistemas e adio de novas tecnologias.
Com as historietas em mos, clientes e
programadores planejam o prximo release,
selecionando
as
historietas
a
serem
implementadas. Dentro de cada release, vrias
interaes ocorrem. Em cada iterao, historietas
so implementadas e testadas. Para cada iterao
ocorrem as seguintes disciplinas: planejamento de
iterao, design, escrita de teste de unidade,
codificao, teste e integrao.
A disciplina de design foi modificada para incluir a
atividade de design da camada de dados. Durante
uma iterao, pode haver mudanas nos requisitos
e estimativas anteriores precisam ser reavaliadas.
Escrita de testes funcionais, bem como design de
na11 vegao e apresentao so feitos em
paralelo com as atividades anteriores. A disciplina
de design de navegao e apresentao foi inserida
devido inquestionvel importncia que estes dois
aspectos tm em uma aplicao web. Quando a

iterao termina, necessrio verificar se o que foi

implementado esta em conformidade com o que se
esperava. Portanto, so executados testes
funcionais para tal propsito. Alm disso, foi
inserida a disciplina de testes web para verificar se
os requisitos no funcionais foram atendidos.
Se for a ltima iterao do release, a verso
corrente do sistema posta em produo.
Depois do primeiro release do sistema, entre em
cena a disciplina de suporte web que foi inserida
com o propsito de lidar com a organizao de
componentes de hardware e software que fazem
parte do web site.
O processo termina quando todas as historietas
tiverem sido implementadas e postas em produo.
Tendo descrito a dinmica do processo, a seguir
ser apresentada a estrutura interna de cada
disciplina modificada ou inserida no XP, ou seja, as
disciplinas em destaque da figura 2. Para cada
disciplina ser apresentada um modelo, similar a
um diagrama de classes, usando esteretipos do
SPEM. Novamente, em cada figura, sero
destacados os elementos que foram modificados ou
inseridos no XP.
As disciplinas de explorao e definio de
requisitos so expostas pelas figuras 3 e 4,
respectivamente. Na disciplina de explorao foram
includas sesses de prottipo.
O web designer responsvel pela atividade de
prototipagem cuja sada um prottipo, criado com
ajuda de tcnicas de prototipagem. J a disciplina
de requisitos foi modificada para incluir a definio
da arquitetura geral da aplicao. Esta arquitetura
muito importante, pois usada em todas as
atividades subseqentes. Quem define o modelo de
arquitetura um desenvolvedor experiente que
entenda de reuso, manuteno, flexibilidade e
performance.
A disciplina de anlise e design, apresentada na
figura 5, foi modificada para incluir a atividade de
design de camada de dados, executada pelo DBA.
Esta atividade pode ser to simples quanto definir o
esquema de um nico banco de dados relacional ou
to complexa quanto fazer a mediao entre vrias
fontes de dados heterogneas.
A figura 6 apresenta uma das mais importantes
disciplinas inseridas: navegao e apresentao. O
web designer elabora o design de navegao,
assistido pelo programador e arquiteto. Para
79

projetar a navegao, mtodos como OOHDM

[Schwabe e Rossi, 1995] [Schwabe e Rossi, 1998]
so muito bem vindos, pois possuem primitivas
com este propsito especfico. O web designer
tambm responsvel por projetar a interface
abstrata
e, com base nesta, a interface fsica.
Para finalizar, as disciplinas de testes web e suporte
web so mostradas na figuras 7 e 8,
respectivamente. Na disciplina de teste, um
programador executa os testes, podendo ser
assistido pelo cliente, que os valida, e pelo analista
de suporte que configura todo o ambiente para que
os testes possam ser realizados. J na disciplina de
suporte, o administrador do web site realiza duas
atividades: gerenciamento de contedo e
gerenciamento de infra-estrutura (scripts, pginas,
componentes, vdeos, udio, etc.).
4.2 OPEN-Web Process
OPEN-Web Process uma extenso do processo
OPEN para desenvolvimento de aplicaes web.
OPEN (Object-Oriented Process, Environment, and
Notation) um framework de processo, conhecido
por OPF (OPEN Process Framework) que abrange o
ciclo de vida completo de desenvolvimento,
incluindo aspectos de negcio e de software. Tratase de um meta-processo, a partir do qual pode ser
gerado um processo especfico (instncia) para uma
dada organizao. OPEN foi desenvolvido e
mantido por um consrcio, sem fins lucrativos,
composto
por
pesquisadores,
acadmicos,
desenvolvedores e empresas.
Como pode ser visto na figuras 9 e 10, os maiores
componentes deste meta-modelo so:
Work Products (artefatos): os componentes que
so desenvolvidos no projeto (documento,
diagrama, modelo, mdulo, classe, etc.);
Languages (linguagens): os componentes usados
para documentar os work products (linguagem
natural, UML, Java, etc.);
Producers (produtores): os componentes que
desenvolvem os work products (programador,
analista, designer, gerente, cliente, etc.);
Work Units (unidades de trabalho): os
componentes que modelam as operaes
executadas pelos producers ao desenvolver work
products. H trs tipos de work unit:
o Activity (atividade): objetivo maior. Define o
qu, no como. composto por tasks;

o Task (tarefa): objetivo menor, ou seja, metas para

atingir o objetivo maior. Ainda define o qu, no
como. Resultam na criao, modificao ou
avaliao de um ou mais work products;
o Technique (tcnica): define como perfazer uma
dada task (casos de uso, cartes CRC, design
patterns, entrevista, etc.).
Stages (estgios): os intervalos de tempos que
provem uma macroorganizao para as work
units. Podem ter durao (Cycle, Phase, Workflow,
Project, Build, Release, Deployment) ou no
(milestone). Milestone um ponto no tempo que
indica que uma meta foi atingida. A figura 11
mostra um exemplo de stages.
Cada processo, instncia do meta-processo,
criado escolhendo atividades, tarefas e tcnicas
especficas, com configuraes especficas, como
descrito na figura 12. Portanto, OPEN prov um alto
grau de flexibilidade para as organizaes.
A natureza baseada em componentes do OPEN
permite criar extenses apropriadas para domnios
especficos. Desta forma, surgiu o OPEN-Web
Process com uma extenso voltada para o domnio
de aplicaes web. Esta extenso foi criada
analisando as diferenas entre sistemas web e
convencionais e validada usando estudos de casos
de projetos comerciais para web.
Apesar das diferenas, certas atividades, tarefas e
tcnicas do framework OPEN se mantm relevantes
para o desenvolvimento web, sem precisar de
alterao. Por exemplo,
as tarefas ligadas s atividades de Iniciao de
Projeto, Planejamento de Implementao e
Planejamento de Projeto permaneceram
relativamente inalteradas.
Estas atividades so as mesmas para qualquer tipo
de projeto, ou seja, necessrio obter aprovao,
fazer estudos de viabilidade, etc. J atividades como
Engenharia de Requisitos e Implementao so
mais volveis de acordo com o tipo de projeto.
A fim de criar o OPEN-Web Process, foram
propostas as seguintes adies e modificaes para
o framework OPEN:
Atividade:
o Gerenciamento de web site.
desenvolvimento,
80

manuteno e gerenciamento de um web site

corporativo, que
inclua ou no acesso a sistemas de processamento
de transao
no back-end.
Tarefas:
o Construir White Sites (prottipos);
o Criar contedo
vdeos, layout
de texto, reuso de templates, etc.).
o Criar mapa de navegao pelo contedo;
o Definir critrio de aceitao para o web site;
o Definir estratgias de teste para o web site;
o Projetar e implementar estratgia de
gerenciamento de contedo;
o Projetar e implementar estratgia de
personalizao
do, apresentao e navegao
por perfis de usurio, ou at mesmo fornecer meios
para que o prprio usurio possa customizar a
aplicao em tempo de execuo.
o Projetar arquitetura do web site;
o Projetar padres de web site
antir consistncia,
quer seja sob a perspectiva de usabilidade, quer
seja sob a perspectiva de
desenvolvimento. O World Wide Web Consortium
[W3C] tem
feito considerveis contribuies neste sentido.
o Desenvolver uma identidade para o web site
Desenvolver um estilo prprio do site que esteja
estrategicamente ligado com a misso do site e que
seja marcante para o pblico.
o Desenvolver um padro de dados;
-cmbio de dados entre
componentes de um mesmo sistema e, em especial,
em interaes B2B. Novamente
o World Wide Web Consortium tem trabalhado
muito na concepo de padres XML para a
indstria que podem ser muito teis.
o Integrar contedo com interface com usurio;
o Criar prottipos de interface com usurio;
o Realizar gerenciamento de contedo;
o Realizar anlise de mercado;
viabilidade
do projeto e tambm para oferecer um servio mais
apropriado.
o Testar o web site

qualidade como performance e concorrncia.

Sub-tarefas:
o Escolher um padro arquitetural para o web site
-tarefa de Definir uma arquitetura.
o Criar o modelo de papis ou atores (UCD2 role
model)
-tarefa de Projetar Interface do Usurio.
o Criar o modelo de tarefas (UCD task model)
-tarefa de Projetar Interface do Usurio.
o Criar o modelo de contedo (UCD content model)
-tarefa de Projetar Interface do Usurio.
Tarefas relacionadas ao desenvolvimento baseado
em componentes:
o Escolher um framework apropriado;
o Avaliar o potencial de frameworks;
o Integrar componentes;
o Enumerar uma lista de frameworks candidatos.
2 UCD Usage Centered Design. Diferentemente de
design baseado no usurio, trata-se de design
baseado no trabalho que o usurio ir realizar e no
que o software precisa fornecer, via interface com o
usurio, para ajud-lo a realizar.
5 Avaliao das Propostas Apresentadas
Esta seco apresenta uma avaliao das duas
propostas apresentadas de acordo com os
requisitos que um processo de software para
desenvolvimento de aplicaes deve atender. Cada
proposta avaliada com relao a cada requisito,
indicando o quo completo a proposta contempla
tal requisito, sob o seguinte esquema: no (no
contempla), parcial (contempla parcialmente), total
(contempla totalmente).
Avaliao do XWebProcess:
1. Autoria (ou engenharia) de contedo: no.
No possui uma atividade explcita para
preparao do contedo. Presume- se que seja
realizado algo neste sentido ao fazer o design de
classes, ou seja, modelo conceitual de domnio.
2. Autoria (ou engenharia) de navegao sobre o
contedo: total.
Atividade de Design de Navegao dentro da
disciplina Navegao e Apresentao.
3. Autoria (ou engenharia) de apresentao
(interface): total.
Atividade de Design de Interface com o Usurio
dentro da disciplina Navegao e Apresentao
4. Ubiqidade: no.
5. Definio de arquitetura multicamadas: parcial.
81

Atividade Definir Arquitetura dentro da

disciplina Definio e Reviso de Requisitos.
Todavia, deveria possuir sub-atividades mais
especficas relacionadas ao uso de padres
arquiteturais, frameworks, sistema legados,
distribuio entre camadas e separao entre o que
roda no navegador cliente e o que roda no servidor
web.
6. Ciclos de vida de desenvolvimento curtos: total.
Esta caracterstica foi herdada do XP.
7. Equipes multidisciplinares: total.
Inclui o cliente e os outros papis relacionados ao
desenvolvimento, bem como menciona a figura de
analista de negcio e expert de domnio.
8. Desenvolvimento concorrente de pequenas
equipes em tarefas interdependentes: no.
No menciona atividades em paralelo e
coordenao de vrias pequenas equipes.
9. Pesquisa de mercado: no.
No alude.
10. Incerteza do cliente e volatilidade dos
requisitos: parcial.
Na disciplina de Explorao foram includas
sesses de prottipo para lidar com a incerteza.
Tambm mencionada, na disciplina Definio e
Reviso de Requisitos, a necessidade de definio
de uma arquitetura flexvel que admita mudanas
com mais facilidade. No entanto, no fica claro
como tratar mudanas nos requisitos medida que
o sistema evolui.
11. Reengenharia de modelos de negcio a partir de
modelos da aplicao: no.
No oferece suporte para anlise de impactos de
modelos de software no negcio.
12. Anlise de negcio e avaliao junto ao usurio
final: parcial.
Anlise de negcio pode ser vista na disciplina de
Explorao e de Definio e Reviso de
Requisitos, no entanto no faz referncia ao
envolvimento do usurio final ao longo do ciclo de
desenvolvimento antes de colocar a aplicao em
produo.
13. Diferentes perfis de usurio (personalizao):
no.
No faz referncia.
14. Requisitos explcitos (funcionais e nofuncionais): total.
Na disciplina Definio e Reviso de Requisitos.
15. Testes rigorosos com relao aos requisitos:
total.

Na disciplina Testes Web.

16. Autoria (engenharia) de Segurana: no.
No alude.
17. Manuteno e evoluo em granularidade fina:
parcial.
Na disciplina Suporte para Web, por meio da
atividade gerenciamento de contedo e de
componentes. Entretanto, no deixa explcito como
fazer, quais os passos a serem seguidos.
Avaliao do OPEN-Web Process:
1. Autoria (ou engenharia) de contedo: total.
Tarefa Criar contedo.
2. Autoria (ou engenharia) de navegao sobre o
contedo: total.
Tarefa Criar mapa de navegao pelo contedo.
3. Autoria (ou engenharia) de apresentao
(interface): total.
Tarefa Projetar Interface do Usurio e suas subtarefas. Alm destas, as tarefas Integrar contedo
com interface com usurio e Criar prottipos de
interface com usurio.
4. Ubiqidade: no.
5. Definio de arquitetura multicamadas: parcial.
Atividade Projetar arquitetura do web site e sua
sub-tarefa Escolher um padro arquitetural, bem
como as tarefas relacionadas ao uso de
componentes e frameworks. No obstante, deveria
possuir sub-atividades mais especficas relacionadas
ao uso de sistema legados, distribuio entre
camadas e separao entre o que roda no
navegador cliente e o que roda no servidor web.
6. Ciclos de vida de desenvolvimento curtos: no.
O meta-processo OPEN requer um engenheiro de
software muito bom que conduza sua instanciao
para um processo de software particular. Desta
forma, existe uma dependncia muito grande na
capacidade do engenheiro de software em definir
um processo que atenda aos prazos curtos exigidos
por uma aplicao web.
7. Equipes multidisciplinares: parcial.
Inclui o cliente e os outros papis relacionados ao
desenvolvimento, mas no menciona a figura de
analista de negcio e expert de domnio.
8. Desenvolvimento concorrente de pequenas
equipes em tarefas interdependentes: no.
No menciona atividades em paralelo e
coordenao de vrias pequenas equipes.
9. Pesquisa de mercado: total.
Tarefa Realizar anlise de mercado.
82

10. Incerteza do cliente e volatilidade dos

requisitos: parcial.
Nas tarefas Construir White Sites e Criar
prottipos de interface com usurio so criados
prottipos para lidar com a incerteza. Tambm
mencionado, na tarefa Projetar uma arquitetura e
suas sub-tarefas, a necessidade de definio de
uma arquitetura flexvel que admita mudanas com
mais facilidade. Tambm esto previstas duas
tcnicas: Development spikes e Field trips. A
primeira utilizada para ajudar aos clientes a
compreenderem a tecnologia e o domnio do
problema atravs de pequenos prottipos. A
segunda consiste em analisar o ambiente do
negcio e o lugar final onde ser instalada a
aplicao. No entanto, no fica claro como tratar
mudanas nos requisitos medida que o sistema
evolui.
11. Reengenharia de modelos de negcio a partir de
modelos da aplicao: no.
No oferece suporte para anlise de impactos de
modelos de software no negcio. No entanto o
framework OPEN prev uma fase (phase) chamada
Reengenharia do Negcio.
12. Anlise de negcio e avaliao junto ao usurio
final: parcial.
O framework OPEN inclui modelagem de negcio,
mas no deixa claro como isto se relaciona com
anlise de negcio. O OPEN-Web Process no
menciona uma tarefa de avaliao ou o
envolvimento do usurio final ao longo do
desenvolvimento. No entanto, possui vrias tarefas
baseadas em UCD.
13. Diferentes perfis de usurio (personalizao):
total.
Tarefa Projetar e implementar estratgia de
personalizao.
14. Requisitos explcitos (funcionais e nofuncionais): total.
Na atividade Engenharia de Requisitos, bem
como na tarefa Definir critrio de aceitao para o
web site.
15. Testes rigorosos com relao aos requisitos:
total.
Nas tarefas Definir critrio de aceitao para o
web site, Definir estratgias de teste para o web
site e Testar o web site.
16. Autoria (engenharia) de Segurana: no.
No faz meno.

17. Manuteno e evoluo em granularidade fina:

parcial.
Na atividade Gerenciamento do web site, por
meio da atividade gerenciamento de contedo e de
componentes. Entretanto, no deixa explcito como
fazer, quais os passos a serem seguidos.
Os resultados da avaliao esto sumarizados na
tabela 1. Percebe-se que nenhum dos dois
processos atende plenamente a todos os requisitos.
Isto uma evidncia que ainda h a necessidade de
criao ou aprimoramento de processos que
apoiem a elaborao de aplicaes web, sendo,
portanto, uma ampla avenida para projetos de
pesquisa.
6 Consideraes Finais
Ao longo da histria da engenharia de software
vrios processos de software foram propostos e
certamente muito outros esto por vir. Todos os
processos definem de alguma forma um conjunto
organizado de prticas a ser seguido de maneira a
aumentar o controle durante todo o ciclo de vida
do software e, por conseguinte, elevar a qualidade
do produto. No entanto, determinados domnio de
aplicao, como aplicaes
web, possui suas especificidades, demandando um
processo de desenvolvimento mais especializado.
Este trabalho apresentou as diferenas relevantes
entre sistema web e sistemas convencionais a fim
de chamar a ateno para a necessidade de criao
de um processo de software voltado para
aplicaes web. Com base nestas diferenas, foi
identificada uma srie de requisitos que precisam
ser levados em considerao.
Com base nos requisitos levantados, foram
analisados dois processos existentes direcionados
para web. Ambos os processos tm sua importante
dose de contribuio, mas nenhum deles prev
integralmente os requisitos identificados. Esta
constatao refora o fato que, embora as
aplicaes web sejam reconhecidamente um
domnio de suma importncia em nossos dias,
ainda existem muitas prticas ad-hoc de
desenvolvimento para suprir a falta de um processo
sistemtico que preveja certas peculiaridades da
engenharia para web.
Como foi visto, uma aplicao web marcada por
incerteza e volatilidade. O cliente no sabe ao certo
aonde quer chegar. Ele vai adquirindo este
discernimento medida que a aplicao evolui.
83

Alm disso, a tecnologia est em constante

evoluo fazendo com que a soluo projetada
precise ser flexvel o bastante para absorver estas
mudanas.
Outro fato importante o treinamento da equipe
que precisa estar sempre reciclando seu
conhecimento.
Diante de todas estas diferenas e desafios,
envolvendo vrias reas, desde o nvel de negcio
at o nvel tcnico, fica claro que aplicaes web
merecem uma ateno especial.
Definir um processo de software para web
certamente no uma tarefa fcil.
Na verdade, trata-se de uma composio de subprocessos, cada processo cobrindo questes
particulares de cada rea envolvida.
A motivao deste trabalho foi justamente chamar
a ateno para esta necessidade e prover um
conjunto de requisitos que possa servir como passo
inicial para uma iniciativa de definio de processo
de software para sistemas web.
Conhecimentos
Bsicos
de
ambientes
operacionais/ambientes tecnolgicos; engenharia
de software; linguagens de programao
orientadas a objeto; metodologias e tcnicas para
arquitetura e projeto de software com orientao
a objetos; mtricas de qualidade de software;
tcnicas de anlise e modelagem de dados;
Os Sistemas Operacionais (SO) tm evoludo com o
tempo, tornando-se mais fceis, bonitos e
agradveis ao usurio. Mas antigamente a histria
era outra, sua estrutura e complexidade no
permitiam que qualquer usurio comum operasse
em SO.
Para adquirir noes sobre esse tema,
especialmente com relao a Windows e Linux
necessrio entender o que um software. Eles
foram criados para que um computador
funcionasse corretamente, pois o hardware no
executa tarefas sozinho, mas por meio de um
sistema que gerencia as atividades.
Softwares so todos os elementos que fazem parte
da programao e que funcionam dentro da
estrutura fsica do computador (hardware). Assim,
eles so classificados em dois tipos:
Softwares Bsicos: programas bsicos e
indispensveis para o funcionamento do
computador. Ex.: Sistema Operacional, utilitrios,

tradutores, linguagens de programao e ambiente

operacional.
Softwares Aplicativos: so todos os programas que
se preocupam em atender as necessidades de um
usurio comum. Podem ser programas de uso geral,
como planilhas, editores de texto, criao de
grficos, gerenciamento de dados, etc. E, tambm,
programas de uso especfico, construdos apenas
para um determinado objetivo, como realizao do
imposto de renda, folha de pagamento, credirio,
etc.
O que Sistema Operacional?
O Sistema Operacional um dispositivo lgico-fsico
que realiza trocas entre o usurio e o computador.
Nele so inseridos alguns softwares que
administram todas as partes do sistema e
apresentam-no de forma amigvel ao usurio.
Ele tambm tem a funo de fazer o gerenciamento
dos vrios usurios da mquina e sobre esse
sistema que os programas so inseridos e os
recursos do computador so gerenciados, como a
memria principal, as interrupes, a memria
secundria e os dispositivos de entrada e sada do
computador.
Um sistema operacional possui duas camadas, a
primeira chamada de Kernel, o seu ncleo
principal, uma das partes essenciais e bsicas que
d suporte a conversa entre software e hardware.
O segundo so os utilitrios, programas utilizados
para 'rodar' dentro do Kernel, ou seja, os softwares
aplicativos j citados.
Importante
O Sistema Operacional dever ser projetado de
acordo com as caractersticas do hardware, as
linguagens de programao e suas ferramentas.
Tipos de Sistemas Operacionais
Com o avano dos computadores foram surgindo
alguns tipos de sistemas operacionais que
contriburam para o desenvolvimento do software.
Os tipos de sistema operacional existentes so:
Monotarefa (Monoprogramvel) - quando h
apenas um programa em execuo e todos os
recursos so feitos em prol desse programa,
tendo ele uma estrutura bsica. Ex.: MS-DOS.
Multitarefa (Multiprogramvel) - sistema que
permite o funcionamento de vrios programas,
alm de compartilhamento e gerenciamento de
recursos,
apresentando
uma
estrutura
complexa. Ex.: Windows.
84

Sistema com Mltiplos Processadores - sistema

em que existem duas ou mais CPUs conectadas
e trabalhando em conjunto. Existem os
fortemente acoplados, quando compartilham
apenas uma memria e so controlados por um
Sistema Operacional; E, os fracamente
acoplados,
em
que
cada
sistema
interconectados possui o seu Sistema
Operacional.

Conhea alguns Sistemas Operacionais

UNIX: sistema operacional para grandes
corporaes
um sistema multiusurio (vrios usurios em
nica vez) e multiprogramvel, com uma estrutura
mais complexa, organizao de arquivos por meio
de subdiretrios, garantindo a proteo das
informaes e redirecionamento de entrada e sada
de dados.
Ele
foi
criado
na
dcada
de
1970,
por desenvolvedores da AT&T, sendo distribudo
comercialmente em linguagem 'C' aps 1980 e
considerado
um
dos
primeiros
sistemas
operacionais modernos. A partir dele foram criados
conceitos importantes no mundo da computao. O
Unix foi projetado para grandes universidades e
corporaes e aps ele, foram lanados outros
sistemas inspirados em sua interface grfica e
linguagem, como o BSD (Berkeley Software
Distribuition).
O
Unix
est
dividido
internamente
em Kernel (ncleo do sistema operacional)
e Interpretador de comandos SHELL (rene a
interface do sistema, executa os comandos
digitados pelo usurio).
Na poca, programadores pensavam em inovar,
no somente na produo de sistemas operacionais
utilizados em grandes corporaes, mas no
desenvolvimento de sistemas para usurios comuns
que
seriam
utilizados
futuramente
nos
computadores pessoais.
Mac OS: sistema operacional para PCs
Uma das primeiras empresas a pensar em
computadores pessoais foi a Apple, empresa
fundada em 1970 por Steve Jobs. Ele lanou,
inicialmente, o computador Apple I, com um
sistema operacional prprio chamado de Mac
OS(Macintosh
Operating
System) que
era
conhecido como System. Posteriormente lanou o
Apple II, III, Macintosh e Lisa.

A cada verso nova dos computadores da linha

Macintosh, o sistema System sofria modificaes e
melhorias. Na dcada de 90, foi lanado o System 7,
um sistema mais avanado que permitia o uso de
cores, com a vantagem de ser multitarefa, possuir a
linguagem
Apple
Script,
dentre
outras
caractersticas. Aps isso, houve a insero do
processador PowerPC, da empresa IBM, e a
possibilidade de criao de cpias por outros
fabricantes. Apenas, depois da verso 7.6 o nome
MAC OS foi considerado.
Com o aparecimento de problemas que atingiram
drasticamente
esse
sistema
operacional,
ocasionadas pela diminuio de seu uso e domnio
do sistema operacional da Microsoft, a Apple
decidiu reescrever todo o cdigo com base no Unix,
sendo chamado de MAC OSX.
Esse sistema, tem como caractersticas: qualidade
na interface grfica do computador, com o
lanamento do Aqua (interface grfica que permite
a produo de relevos, sombreamentos, reflexos e
outros elementos de design), alm de comandos
diferenciados em suas ltimas verses, como
permisso de mltiplos toques e uma navegao
baseada na intuio do usurio.
Outras verses do Sistema Operacional Mac OS X
As verses do sistema operacional Mac OS
X recebem o nome de felinos, sendo algumas
desenvolvidas para funcionar em tablets da Apple,
Iphone e Ipod Touch, veja:
Mac OS X verso 10.0 Cheetah;
Mac OS X verso 10.1 Puma;
Mac OS X verso 10.2 Jaguar;
Mac OS X verso 10.3 Panther;
Mac OS X verso 10.4 Tiger;
Mac OS X verso 10.5 Leopard;
Mac OS X verso 10.6 Snow Leopard;
Mac OS X verso 10.7 Lion;
Mac OS X verso 10.8 Montain Lion.
Windows: sistema operacional em janelas
A palavra Windows traduzida do ingls quer dizer
'janelas', um gerenciador de interfaces que permite
o usurio ver informaes e se comunicar com o
computador. Ele foi desenvolvido, na dcada de
1980, por Bill Gates, mas somente se tornou um
sistema operacional a partir do Windows NT,
lanado na dcada de 90. A partir da primeira
interface, foram surgindo outras verses para
Windows, como 1.01, 2.03, 2.1, 3.0, etc.
85

O Windows NT (New Tecnology) foi desenvolvido

para o ambiente corporativo. Ele multiusurio,
multitarefa e multiplataforma, rodando no
somente em plataformas como INTEL, mas em DEC
Alpha, MIPS, etc. Uma das caractersticas dos NT a
de se transformar em servidor na internet, sendo
dividido em Windows NT Server e Windows NT
Workstation.
Anteriormente, no havia ainda o Windows, mas
softwares que 'rodavam' no computador e eram
sistemas grficos com verses compatveis ao
sistema DOS (MS-DOS, DR-DOS, PC-DOS), sendo
utilizado e criado pela Microsoft, o MS-DOS
(sistema orientado por meio de linhas de comando
digitadas atravs do teclado pelo o utilizador).
Outras Verses do Sistema Operacional Windows
Cada verso foi sendo melhorada e adaptada para
os usurios, trazendo uma convergncia de
tecnologias, alm de maior desempenho e rapidez
com a tecnologia de 64 bits. As verses do Windows
possuem preos diferenciados, por se tratar de um
software proprietrio:
Windows 35;
Windows 98;
Windows Me (Millennium Edition);
Windows 2000;
Windows XP (Experience);
Windows Server 2003;
Windows Vista;
Windows 7;
Windows 8.
Linux: sistema operacional de cdigo aberto
O sistema operacional GNU/Linux foi desenvolvido
por Linus Torvalds, na Finlndia, em 1991. Ele
uma verso do SO Unix que possui cdigo aberto e
pode ser escrito e distribudo por qualquer tipo de
usurio na internet, por ser um software gratuito
(free software), sendo proibido a comercializao
do sistema.
Qualquer pessoa poder ver o cdigo fonte de um
sistema Linux, resolver problemas atravs de uma
lista de discusso online, em que consultores e
usurios que trabalham na manuteno do cdigo
podero solucionar, fazer atualizaes, etc. Alm
disso, ele d suporte a placas, cd-rom e outros
dispositivos mais ultrapassados e/ou avanados.
Das caractersticas desse sistema esto a
multitarefa, multiusurio, conexo com outros tipos
de sistemas operacionais, segurana quanto a

proteo de processos executados na memria

RAM, no h licena para seu uso, etc.
O SO Linux composto pelo kernel e vrios
programas, que podem ser criados de acordo com
as suas distribuies. Cada distribuio linux tem
caractersticas diferentes e foram criadas para
usurios especficos.
Outras distribuies do Sistema Operacional Linux
Slawckaware;
Debian;
Fedora;
Red Hat;
Conectiva;
Monkey;
Ubuntu;
Mandriva;
Mint;
Opensuse;
Puppy;
Sabayon, etc.

Sistema Operacional
hardware da mquina, tornando a utilizao do
equipamento mais fcil, mais eficiente e mais
confivel.
do computador
de forma fcil e eficiente.

SO um programa de controle

dos usurios (aplicativos)

aplicaes possuem necessidades em comum
que so atendidas pelo SO: alocao e controle de
recursos

Principais atribuies do SO
erenciamento de Memria

Gerenciamento de Processos
86

tempo

Tipos de Sistemas Operacionais

executando e vrios esperando para executar)

considera apenas um usurio por

vez.

recursos computacionais

-DOS

por selecionar um processo apto para executar no

processador
o dividir o tempo do processador de
forma justa entre todos processos aptos

(usernamee senha) e permite perfis diferentes.

Ex. Mac OS, Windows XP, Linux...

Gerenciamento de Memria

ite a execuo de apenas um programa

do usurio por vez.
-DOS

Tipos de Sistemas Operacionais

se livres e quais esto em uso

rdo com as
necessidades dos processos
um processo

de forma aparentemente simultnea, apesar de ter

apenas um processador.
Ex. Mac OS, Windows XP, Linux...

memria principal e a memria secundria

Tipos de Sistemas Operacionais

Gerenciamento de Entrada e Sada

visveis!) funes do SO
controlar os dispositivos de E/S

executando, mas somente um processador em

operao.

processadores paralelos utilizados no sistema.

resto do sistema
Gerenciamento de Arquivos
ser possvel armazenar uma quantidade
muito grande de informao
deve sobreviver ao trmino do
processo que a usa
processos devem ser capazes de
acessara informao concorrentemente
operaes sobre arquivos:
r um arquivo

Sistemas Operacionais Clssicos

-sharing
-time
Sistemas Operacionais tipo Batch
terminais de mquinas de grande porte, que
reuniam um lote de programas para enviar para
execuo.
rabatchpassou a
designar um processo onde o usurio no interage
com o seu programa.
haver comunicao do usurio com o seu
programa, durante a execuo.

Tipos de Sistemas Operacionais

Sistemas Operacionais Time-sharing
87

de Tempo Compartilhado
sinnimo de interao e multiprogramao.
-sharingpermite que diversos usurios
compartilhem o computador em um dado instante,
dando a cada um a sensao de que o computador
encontra-se dedicado a ele.
sui seu programa (ou parte dele)
na memria principal. O processador alocado por
um pequeno perodo de tempo (fatia de tempo ou
time slice) a cada programa de usurio.
Sistema de Tempo Real
perodo de tempo
previamente especificado (geralmente muito
pequeno), a estmulos gerados externamente

implica num eterno aprendizado por parte de seus

usurios.
Quando se usa um computador em que o sistema
LINUX foi instalado, a primeira coisa que se deve
fazer informar o seu login, e em seguida a sua
senha, o que lhe dar acesso a todos os recursos
disponveis. Em geral, apenas o usurio
denominado "root" tem acesso irrestrito a todo o
sistema, e ele quem administra o restante das
configuraes.
Uma vez digitado o login e a senha, voc ter
acesso ao prompt. Esse prompt (que aqui ser
simbolizado por um sinal de $) gerado por um
programa chamado shell (literalmente, casca ou
aparncia exterior) que responsvel por lidar com
os seus comandos.

multiprogramao e oferece facilidades para as

aplicaes de tempo real
preemptivo que leva em conta as prioridades dos
processos.
1.1. Usando o Linux
Para aqueles que nunca usaram o Linux, iremos
expor aqui os conceitos preliminares estritamente
necessrios para se programar usando o GTK.
Portanto, esta primeira seo, onde iremos apenas
apresentar alguns pontos que consideramos
fundamentais, dedicada aos iniciantes e queles
que ainda no esto familiarizados com o sistema.
Se esta no a sua situao, v direto para a
prxima seo.
Nosso primeiro principal objetivo ser motiv-lo a
usar o GTK. Esperamos que qualquer um que tenha
noes bsicas de C sinta-se encorajado a usar o
GTK aps ler este tutorial, independentemente do
sistema operacional que vinha usando at ento.
Por isso, muito importante para ns ter acesso a
possveis dvidas e comentrios. Teremos o maior
prazer em responder.

1.1.1. O que o Linux

O Linux um sistema multiusurio e multitarefa, o
que significa que vrias pessoas podem trabalhar de
uma vez, e que este capaz de realizar diversas
tarefas ao mesmo tempo. Alm disso, o Linux um
sistema operacional em constante evoluo. Isto

1.1.2. O que um comando

No Linux, os comandos so arquivos que possuem
permisso para serem executados. A maioria dos
comandos inerentes ao Linux encontra-se no
diretrio /bin. Assim como no DOS, existe uma lista
de diretrios onde o shell pesquisa procura de
comandos. Essa lista de diretrios se chama path
(ou caminho). Para ver como est o seu caminho
atual, digite:
$echo $PATH
Uma observao muito importante que,
diferentemente do DOS, o Linux no pesquisa
automaticamente no seu diretrio atual a procura
de comandos a serem executados.
O diretrio atual simbolizado por um ponto, e o
diretrio pai simbolizado por dois pontos. Se voc
quiser
executar
um
arquivo
chamado
"nomearq.exe", que se encontra no diretrio atual,
e informar apenas:
$ nomearq
receber uma mensagem do tipo "File not found".
Voc dever informar explicitamente ao sistema
que execute o arquivo "nomearq.exe", que se
encontra no diretrio atual:
$./nomearq.exe
Uma alternativa seria incluir um ponto ( . ) na
varivel $PATH. No bash, use:
$ export PATH=$PATH:.
88

Esse comando ir tornar o seu caminho igual ao

caminho antigo mais o diretrio atual (o ponto).
No tcsh, fornea:
$ set path = ( $PATH . ) 1
1.1.3. Alguns comandos disponveis
O formato geral de um comando :
comando [-[opo1][opo2]...] parmetro
onde o que est entre colchetes opcional.
A familiarizao com os comandos do Linux obtida
com a experincia. Em tempo, iremos apenas
apresentar a lista de alguns comandos bsicos, sua
finalidade, sintaxe e parmetros. Para obter mais
informaes sobre qualquer comando, basta
consultar as pginas manuais, digitando no prompt
"man" seguido do nome do comando. Por exemplo:
$man ls.
A tabela abaixo lista alguns dos principais comandos
do Linux, suas finalidades, sintaxes e parmetros: 2
Comand Finalidade
Sintaxe Parmetros
o
ls
Lista
o ls -lar -- -l: lista longa
list
contedo
color
-a:
lista
de
um diretri arquivos
diretrio.
o
ocultos
-r:
lista
recursivament
e
--color: ativa
cores
cd
Troca
de cd
change
diretrio.
diretri
directory
o
rm
Remove
rm -irf -i:
apaga
remove
arquivos e arquivo confirmando
diretrios.
-r:
apaga
recursivament
e
-f:
apaga
foradamente
cp
Copia
cp fonte
copy
arquivos.
destino
mkdir
Cria
um mkdir
make
diretrio.
diretri
directory
o
rmdir
Apaga um rmdir
remove
diretrio.
diretri
directory
o
touch
Cria
um touch

more

clear
su
find

ps
process

grep

df
disk free
du
disk
usage
pwd
print
working
directory
finger

passwd
passwor
d
logout

arquivo
vazio.
Exibe
contedo
do arquivo.
Limpa
a
tela.
Muda
de
login.
Procura
arquivos
em
diretrios.
Mostra os
processos
rodando na
mquina.
Procura
padres em
um arquivo.

arquivo

Mostra
espao em
disco livre.
Mostra uso
de disco.

df
partio

Mostra o
nome
do
diretrio
corrente.
Mostra
informae
s sobre um
usurio.
Definir
senha.

pwd

more
arquivo
clear
su
[-]
login
find
--name:
caminh procura
o expr.
nome

pelo

ps - aux

grep
expr.
arquivo

-a: todos os
processos
-x:
mostra
processos que
no
foram
iniciados
no
console
-u: nome do
usurio e hora
de incio

du
-s -s:
mostra
arquivo apenas o total

finger
usurio

passwd

Sair
do logout
sistema.
halt
Desliga
o halt
sistema.
Observe que no comando ls, a opo color deve ser
precedida por dois hfens. Nos comados em geral,
89

qualquer parmetro que possua mais de um

caracter (no caso, a palavra "color" possui cinco
caracteres) deve ser passado com dois hfens na
frente. Se quisermos mostrar uma lista longa dos
arquivos, incluindo os ocultos, com cores, devemos
digitar:
$ ls -la --color
Ateno! Em um sistema monousurio, antes de
desligar o computador sempre execute o comando
halt e aguarde a mensagem "System halted!". Em
muitos sistemas apenas o usurio root pode
executar o comando halt.
Para colocar qualquer comando em segundo plano,
basta proceder normalmente e digitar um & antes
de pressionar enter.
1.1.4. Terminais virtuais
No prompt do shell, ao pressionar a tecla Alt
esquerda e uma das teclas de funo, de F1 a F7,
voc poder navegar pelos consoles virtuais. Cada
um deles est associado a uma nova tela. Desse
modo pode-se trabalhar com atividades diferentes
em sees distintas. Observao: numa seo do X,
pressione Ctrl, Alt e uma das teclas de funo, de F1
a F7, para saltar para um outro console. Em geral, o
sistema de janelas X carregado no terminal virtual
de nmero sete.
Dentro de um console virtual, um recurso muito til
para se navegar no sistema o uso da tecla tab
para completar seus comandos em geral.
Experimente digitar:
$ cd /usr/sb
e tecle tab em seguida. Se voc usa o shell bash,
ksh, tcsh ou zsh, este ir preencher para voc as
informaes que faltam na sua linha de comando.
Caso exista mais de uma possibilidade de trmino
de palavra, pressione tab mais uma vez e
aparecero todas as opes disponveis. 1
1.1.5. O sistema de arquivos e diretrios
importantes
Algo que voc certamente mais cedo ou mais tarde
ir querer fazer acessar a unidade de disco, cdrom ou at mesmo uma partio que contenha
dados do Windows 95/98. Para isso, necessrio
inicialmente "mont-la" usando o comando mount.
A sua sintaxe :
mount -f tipo dispositivo ponto_de_montagem
Um exemplo de utilizao, para acessar os dados do
Windows 98 contidos na partio de nmero um do

terceiro disco rgido, ou seja, do dispositivo

chamado hdc1, seria:
$ mkdir /win98
$ mount -f vfat /dev/hdc1 /win98
Feito isso, nesse exemplo os dados da nova unidade
montada podem ser acessados a partir do diretrio
win98. Uma observao importante que nem
todos os usurios podem usar o mount em todas as
situaes. Consulte a pgina de manual do mount
para maiores detalhes.
Para acessar a unidade de disco, por exemplo, voc
poder recorrer aos mtools, caso estejam
instalados no seu sistema. Digite man mtools na
linha de comando para obter mais informaes.
Os diretrios que guardam os arquivos de sistema
do Linux, em sua maioria, so padronizados. Alguns
diretrios importantes so:
/
/usr/bi
n
/sbin

/home
/usr/spo
ol
/etc

/bin /usr
/de /usr/sbi
v
n

/
O diretrio "root" (raiz).
/home
Abriga os diretrios dos usurios. Por exemplo, um
usurio cujo login seja "ana" provavelmente
quando entrar no sistema ser encaminhado direto
para o diretrio /home/ana, e ter acesso a todos
os dados contidos no mesmo.
/bin
Guarda os programas e comandos bsicos do Linux.
bin um mnemnico para "binaries" (binrios), ou
seja, arquivos executveis. Na realidade todos os
arquivos armazenados num computador esto em
formato binrio. Infelizmente, usa-se como jargo,
por motivos histricos, o termo "arquivos binrios"
como sendo sinnimo de arquivos executveis.
/usr
Armazena muitos outros diretrios com contedo
orientado aos usurios.
/usr/docs
Documentos, incluindo informao til sobre o
Linux.
90

/usr/man
Pginas de manual, acessadas digitando man
<comando>
/usr/games
Jogos!

1.2.1. Conceitos sobre o X

O X Window System, ou Sistema de Janelas X,
basicamente um conjunto padronizado de rotinas
de tratamento de tela, desenvolvido no MIT, que
permite a criao de interfaces grficas
independentes do hardware. 4

/usr/bin
Neste diretrio esto contidos programas voltados
aos usurios do sistema em geral.
/usr/spool
Este diretrio possui vrios subdiretrios. Entre eles
mail, que guarda mensagens, spool, onde so
guardados arquivos a serem impressos e uucp que
abriga arquivos copiados entre mquinas Linux.
/dev
No Linux, tudo acessado por meio de arquivos! O
diretrio /dev armazena dispositivos. Estes, na
realidade, so pontes para os verdadeiros
componentes fsicos da mquina. Por exemplo, se
voc copia para /dev/fd0, na realidade voc est
enviando dados para uma unidade de disco. O seu
terminal um arquivo /dev/tty. Parties do disco
rgido so da forma /dev/hd0. At a memria do
sistema um dispositivo!
Um dispositivo famoso o /dev/null, que
corresponde a uma lixeira. Toda informao
desviada para /dev/null descartada.

Neste esquema, voc pode observar que os

aplicativos trocam dados com o Sistema de Janelas
X, o qual passa as informaes para o vdeo. No
existe um acesso direto ao monitor de vdeo por
parte das aplicaes, tornando-se estas mais
facilmente portveis. Isto , o mesmo programa
pode ser executado sobre qualquer hardware sem
ser modificado ou recompilado.
Alm disso, o X Window System um sistema de
janelas que pode executar aplicaes em rede de
forma transparente. Portanto, vrios aplicativos,
que podem estar rodando em mquinas
distribudas
por
toda
a
rede,
geram
simultaneamente texto e grficos na tela de um
determinado usurio. 5

/usr/sbin
Aqui esto os arquivos de administrao do
sistema.
/sbin
Neste diretrio esto contidos arquivos executados
em geral automaticamente pelo sistema
operacional.
/etc
Este diretrio e seus subdiretrios abrigam muitos
arquivos de configurao. Estes arquivos so na
maioria do tipo texto, e podem ser editados para
alterar parmetros do sistema. 3
1.2. X Window System

No prompt de seu shell, digite startx. Se o X for

inicializado, e o cursor aparecer no vdeo, voc est
pronto para utiliz-lo. Caso contrrio, ser
necessrio configur-lo. Clique aqui para fazer o
download de um tutorial a fim de aprender a
configurar o seu Sistema de Janelas X.
91

1.2.2. Os Gerenciadores de Janelas

Note que, ao definirmos o Sistema de Janelas X, nos
referimos a um conjunto de rotinas padronizadas
para acessar o vdeo. Em outras palavras, o Sistema
de Janelas X apenas um protocolo. Em cima desse
protocolo que rodam todos os aplicativos.
Inclusive os gerenciadores de janelas (ou window
managers), que so responsveis por gerar a
interface externa do sistema ao usurio.
funo dos gerenciadores de janelas prover:
- barras de ttulo, bordas e outras decoraes para
as janelas das aplicaes
- cones uniformes
- um meio uniforme de se mover e redimensionar
as janelas
- uma interface uniforme para se mover entre as
aplicaes
Entre os window managers mais famosos podemos
citar o fvwm, o KDE ( www.kde.org ) e o Window
Maker (www.windowmaker.org) entre vrios
outros (este ltimo foi desenvolvido em grande
parte na Universidade Federal do Rio Grande do
Sul). o window manager que determinar a
aparncia do seu sistema X, portanto escolha o que
mais lhe agradar.
1.3. Editores de texto
Em praticamente todos os sistemas Linux esto
instalados o vim e o Emacs. Por isso, de grande
utilidade saber utilizar bem um desses dois
editores. Se voc tem instalado o X, sua distribuio
deve provavelmente incluir tambm o gvim e uma
verso para o X do emacs.
Para
aprender
a
usar
o
vim,
visite http://www.vim.org/. O emacs tambm
possui a sua pgina em http://www.emacs.org
Note que o vim e o emacs so editores de textos
simples. Para formatar os textos, existem os
processadores de textos, entre eles o TEX/Latex, o
groff e o Textinfo. Por meio de comandos inseridos
no texto o usurio pode transformar um
documento simples em um documento formatado
usando um desses processadores.
1.4. Linguagens de Programao
1.4.1. Como programar com o gcc
O gcc um compilador C/C++ poderoso. Isto se
deve ao fato de que o C a linguagem nativa do
Linux.

O gcc (GNU C Compiler) funciona a partir da linha

de comandos do shell. Para saber todas as opes
que esse compilador oferece, consulte a pgina
manual
do
mesmo.
Visite
a
pgina www.gnu.org para saber mais sobre o
projeto GNU.
A sintaxe bsica para se chamar o gcc :
$ gcc [opes] [arquivos]
Muitas opes do gcc consistem de mais de um
caracter. Por isso, diferentemente da maioria dos
outros comandos do shell, cada opo deve ser
precedida pelo seu prprio hfen. Voc no pode
agrupar opes depois de um nico hfen. Os dois
comandos a seguir, por exemplo, no so idnticos:
$ gcc -p -g test.c
$ gcc -pg test.c
Se voc compilar um arquivo e no especificar
nenhum parmetro na linha de comando, o gcc ir
automaticamente criar um arquivo executvel, e ir
cham-lo de a.out. Para testar, clique aqui para
baixar o arquivo teste.c (o tradicional "Hello
World!" escrito em C), copie-o para o diretrio
adequado e l digite:
$ gcc teste.c
Para especificar um outro nome para o arquivo de
sada, deve-se usar a opo -o (do ingls, output).
Para compilar um programa chamado teste.c e
gerar um executvel chamado hello, digite o
seguinte:
$ gcc -o hello teste.c
O processo de gerar um arquivo executvel se
divide em duas etapas. Primeiro gerado o cdigo
objeto, a partir do cdigo fonte. Esse arquivo objeto
praticamente equivalente ao cdigo de mquina.
Em seguida, o arquivo objeto linkado ("ligado")
para produzir um executvel.
Essa etapa consiste em informar ao programa onde
encontrar as bibliotecas de que este necessita para
funcionar. Existem dois tipos de bibliotecas: as
estticas e as compartilhadas. As bibliotecas
estticas so anexadas ao arquivo a ser executado,
de modo que passam a fazer parte do programa
final. Isso, no entanto, pode ser pouco prtico, caso
muitos programas usem as mesmas sub-rotinas de
bibliotecas em comum. Nesses casos, costuma-se
usar as bibliotecas compartilhadas.
Quando o programa for ligado a uma biblioteca
compartilhada, ao invs de ser anexado todo o
cdigo da biblioteca ao programa, ser apenas
fornecida uma referncia para a mesma no disco,
92

de modo que o carregador possa encontr-la

durante a execuo.
Bibliotecas
Para o compilador saber onde encontrar os
arquivos de incluso e as bibliotecas, use as opes
-I e -L respectivamente, seguidas pelos diretrios
onde encontram-se os mesmos. Por exemplo:
$ gcc -I/usr/include -L/usr/lib -o exemplo exemplo.c
-lstuff
Neste exemplo, a opo -I informa ao gcc para que
acrescente o diretrio /usr/include ao caminho
onde sero pesquisados os arquivos de incluso. A
opo -L informa ao gcc que acrescente o diretrio
/usr/lib ao caminho onde sero pesquisadas as
bibliotecas. Por fim, a opo -lstuff indica ao gcc
que ligue a biblioteca libstuff.a ao executvel. Por
padro todas as bibliotecas comeam com as
iniciais "lib". As bibliotecas que terminam com a
extenso ".a" so estticas, e as que terminam com
extenso ".so" so compartilhadas. Por padro, o
compilador ir tentar primeiro ligar as bibliotecas
compartilhadas. Para especificar que voc deseja
usar bibliotecas estticas, utilize a opo -static.1
Mais opes...
recomendvel que se ative a opo -w ao se usar
o gcc. Esta ativa todas as mensagens de aviso e de
erro que o compilador possa gerar.
Pode-se especificar at que ponto o gcc ir
processar o cdigo fonte. A opo -c indica ao gcc
que apenas gere o cdigo objeto. A opo -S indica
ao gcc que pare aps gerar o cdigo assembly.
possvel ainda otimizar o seu cdigo fonte, usando
as opes -O, que far otimizaes bsicas, e -O2,
que trar otimizaes avanadas. Ao ativar essas
opes, o processo de compilao se tornar mais
lento, mas o seu executvel ser mais rpido.
Finalmente, para poder futuramente depurar ou
analisar detalhes sobre o cdigo, use a opo -g, se
for usar o gdb (Gnu Debugger), -p se for usar o prof
ou ainda -pg, se voc for usar o gprof. 3
Para saber como compilar programas que fazem
uso da biblioteca GTK, consulte a seo 2.2.2.
1.4.2. Makefiles (arquivos make)
Se voc estiver trabalhando num projeto com
diversos arquivos, o make um programa bastante
til, que lhe poder poupar muito tempo. Ao
compilar o seu projeto usando o make, este ir
consultar um registro de dependncias entre os

seus arquivos e atualizar apenas aqueles que foram

alterados desde a ltima atualizao.
O formato geral de uma entrada de um arquivo
make :
destino: dependncias
(TAB) lista de comandos
Note que a lista de comandos deve comear com
uma tabulao, e no com espaos.
Digamos, por exemplo, que voc deseja construir
um programa chamado felicidade, que dependa dos
arquivos saude.c e amor.c. Voc dever editar um
arquivo chamado makefile, ou Makefile, como
preferir, contendo as seguintes trs entradas:
felicidade: amor.o saude.o
gcc -o felicidade amor.o saude.o
amor.o: amor.c
gcc -c amor.c
saude.o: saude.c
gcc -c saude.c
Agora, digite na linha de comando:
$ make felicidade
O programa make ir procurar no seu diretrio
atual um arquivo chamado, literalmente, makefile
ou Makefile. Ao encontrar o arquivo que voc
acabou de fornecer, ele ir interpretar, a partir da
primeira linha do mesmo, que "felicidade"
construda a partir de amor.o e saude.o.
Recursivamente, o make ir verificar que amor.o
depende de amor.c, e que saude.o depende de
saude.c. Sempre que um dos arquivos de
dependncia for alterado, ou no existir, a lista de
comandos referentes a ele ser executada. Para
saber se um arquivo foi alterado, o make consultar
a data e a hora associados ao mesmo pelo sistema
operacional. Para saber quando determinado
arquivo foi modificado pela ltima vez, execute o
comando: ls -l. 1
1.4.3. Depurao com o gdb
O gdb (GNU Debugger) possui muitos comandos
que lhe iro permitir executar diferentes operaes
de depurao. Clique aqui para obter algumas
delas. E lembre-se! Ligue as opes de depurao
quando compilar o programa, a fim de poder
posteriormente depur-lo.
1.5. Instalao de novos programas
Instalar novos programas no seu ambiente Linux
uma tarefa simples, principalmente se voc tiver a
93

sua disposio um dos gerenciadores de pacotes

como o RPM ou o DPKG.
1.5.1. RPM
Se voc usa a distribuio da Red Hat ou alguma
outra que d suporte ao RPM, eis aqui algumas das
funes mais comuns:
rpm <parmetros> <nome do pacote>
-i : instalao bsica
- U : atualizao de um programa
-- nodeps : no procura por dependncias
-- help : lista opes
- q : (do ingls, query) mostra informaes sobre o
pacote
- e : exclui um pacote
Para verificar se voc tem instalado o pacote gtk
voltado para desenvolvedores, por exemplo, digite:
$ rpm -q gtk+-devel
seguido da tecla tab e enter.
Caso no possua, baixe o arquivo clicando aqui e,
no diretrio adequado, digite na linha de comando:
$ rpm -ivh gtk+-devel
seguido da tecla tab e enter.
1.5.2. DPKG
Usado para manusear pacotes da Debian.
dpkg <parmetros> <nome do pacote>
-i : instalar
-r : remover
1.5.3. Arquivos .tar.gz ou .tgz
Digitando, na linha de comando, no diretrio
adequado
tar -xzvg nome_do_arquivo
o arquivo ser descompactado. Provavelmente
voc encontrar um arquivo chamado README ou
INSTALL. Leia-o e siga as instrues recomendadas.
Caso no exista este arquivo, tente digitar
simplesmente
$ ./configure
$ make
no prompt do shell, para compilar, e depois
$ make install
para instalar (normalmente como root). 2
1.6. Roteiro
Finalmente, apresentamos aqui um roteiro para
voc dar os primeiros passo com o GTK.
a. Instalar o Linux.

b. a partir do shell inicializar uma seo do X

(digitando startx, kde, ou o nome de algum outro
gerenciador de janelas que esteja instalado e lhe
agrade).
c. instalar o GTK. Se preferir, instale o Gimp (no
Red-Hat, basta execut-lo pela primeira vez,
clicando no seu cone), que automaticamente o GTK
ser instalado.
d. abrir uma janela do xterm (shell) ou,
alternativamente, efetuar login num outro console
virtual.
e. usar esse console virtual ou o xterm para
inicializar um editor de textos e digitar o cdigo
fonte de seu programa.
f. compilar o programa, usando o gcc ou o make.
Software
Sistema de Computao = hardware + software

Software
So os programas (conjunto ordenado de
instrues), de qualquer tipo e qualquer linguagem,
que so introduzidos no computador para faz-lo
trabalhar e produzir resultados.
Tipos de software
Software bsico (programas do sistema)
Aplicativos (programas de aplicao)
Software bsico (programas do sistema)
Gerenciam a operao do computador e
proporcionam um
ambiente de utilizao da mquina ao usurio.
Ex: compiladores, linguagens de programao,
sistemas
operacionais.
Aplicativos (programas de aplicao)
Programas de usurio (abordagem sistmica).
Ex: editor de texto, planilha eletrnica, navegador
para Internet,
software comercial (folha de pagamento, controle
de estoque).
Sistema Operacional
Programa formado por vrios mdulos que
trabalham de modo
cooperativo para administrar os recursos de
hardware da
94

mquina e auxiliar na execuo dos programas do

usurio,
oferecendo a este uma interface mais amigvel com
o hardware.
Funciona como um intermedirio entre o usurio e
o hardware, tornando o uso do computador mais
conveniente.
o principal software bsico que controla todos os
recursos do computador.
Funes bsicas:
Comunicao do usurio com o hardware.
Prover aos usurios uma utilizao otimizada e
compartilhada
dos recursos do sistema.
Controle dos recursos de hardware:
- Gerencia a memria principal
- Gerencia as interrupes
- Gerencia o acesso memria secundria
- Gerencia o acesso aos dispositivos de
entrada/sada
Alguns exemplos: Unix, Hp-ux, Aix, Linux (Debian,
Ubuntu, Fedora, etc), OS2, MS-DOS, Windows,
Z/OS.
Estruturado em mdulos (mdulo => funes
especficas)
HARDWARE
Ncleo
Gerenciador de
memria
Sistema de E/S
Sistema de arquivos
Escalao e alocao de recursos
Interpretador de comandos
=> drivers
23
Sistemas operacionais
Usurio / Programa
S.O
Hardware
Aplicativo
Sw Bsico
Software livre
Software livre (Free software)
o software disponvel com a permisso para
qualquer um
us-lo, copi-lo, e distribu-lo, seja na sua forma
original ou com

modificaes, seja gratuitamente ou com custo. Em

especial, a
possibilidade de modificaes implica em que o
cdigo fonte
esteja disponvel.
No confundir software livre com software grtis.
GPL (GNU General Public License): licena que
acompanha os pacotes distribudos pelo Projeto
GNU, incluindo o ncleo do sistema operacional
Linux. Verso oficial em ingls.
Software livre
Linux
um kernel (ncleo) idealizado em 1991 pelo
finlands Linus
Torvalds (estudante de cincia da computao). Seu
objetivo foi criar um sistema operacional no qual
fosse possvel alterar
conforme a necessidade.
chassis => kernel (+cdigo fonte)
carroceria => coleo de programas e aplicativos
Distribuio
um sistema operacional Unix-like incluindo o
kernel Linux e
outros softwares de aplicao, formando um
conjunto.
Distribuies (ou distros) so mantidas por
organizaes
comerciais ou projetos comunitrios.
Principais distribuies
Debian (http://www.debian.org/)
Fedora (http://fedoraproject.org/)
Gentoo (http://www.gentoo.org/)
Mandriva (http://www.mandrivalinux.com/)
Slackware (http://www.slackware.com/)
SuSE (http://www.novell.com/linux/)
Ubuntu (http://www.ubuntu-br.org/) => amigvel
Algumas oferecem a possibilidade de execuo em
modo Live
CD: Kurumin (brasileira) e Ubuntu.
Lista completa: http://lwn.net/Distributions/
Como escolher uma distribuio
- Esta distribuio suporta todo o meu hardware?
- Ela inclui os pacotes de software de que
necessito?
- O processo de instalao e configurao est de
acordo com minhas
95

aptides?
- Ela tem documentao e treinamento em um
idioma que eu entendo?
- O suporte prestado (gratuito ou pago) atende
minhas necessidades?
- Existe uma comunidade de usurios da qual eu
possa participar?
- Ela lana atualizaes de segurana quando
necessrio?
- Ela continuar sendo atualizada?
- Ela livre? grtis? O preo aceitvel?

o sistema operacional mais usado do mundo e,

por isso, seu impacto
no mundo atual incalculvel.
Estima-se que, de cada 10 computadores no Brasil,
9 usam Windows.
Service Pack (SP)
Pacote de atualizao do Windows que corrige
bugs e traz melhorias.
As atualizaes podem aumentar a confiabilidade
do sistema, a compatibilidade de programas, a
segurana, a performance, etc.

Debian
- Uma das distribuies cuja utilizao mais cresce
no mundo.
- Segura e confivel: cada verso lanada aps
rigorosos testes
de segurana e correo de falhas (ambiente
corporativo).
- Distribuio oficial do projeto GNU/Linux.
- Mantida por programadores, hackers e
especialistas de
segurana espalhados ao redor do mundo.
- Suporte a mais de 10 arquiteturas (Intel x86,
Sparc, Macintosh).

Principais extenses de arquivos

doc documento do Word
pdf documento visualizvel pelo Acrobat Reader
txt arquivo texto
xls planilha do MS Excel
ppt apresentao do MS Power Point
avi, flv, wmv arquivo de vdeo
bmp, jpg, gif arquivo de imagem
exe arquivo executvel (programa)
Programas instalados
- Acionar o menu Iniciar (Ctrl + Esc)
- Com o mouse, selecionar Configuraes
- Selecionar e clicar em Painel de controle
- Selecionar e clicar em Adicionar ou remover
programas
Vises: nome, tamanho, frequncia de uso, data
atualizao

Operating System Market Share (August, 2009)

Fonte: Net Applications. [online] Disponvel na
Internet via www.
Windows
O Microsoft Windows uma popular famlia de
sistemas operacionais criados pela Microsoft.
Windows 1.01 (1985) interface grfica para o MsDos. No era um sistema operacional de fato.
Interface muito mas amigvel que seu antecessor
(Ms-Dos), o que alavancou o uso do micro em todo
mundo.
A sua interface baseada num padro de janelas
(windows) que exibem informaes e recebem
respostas dos utilizadores atravs de um teclado ou
de cliques do mouse.
A interface grfica uniforme em todos os
aplicativos, o que facilita o aprendizado.
um produto comercial, com preos diferenciados
para cada uma de suas verses, embora haja uma
enorme quantidade de cpias ilegais instaladas.
(Vista Home Basic: R$ 199,00 - fonte: Brasoftware)

MS Office
um conjunto de programas de escritrio da
empresa Microsoft.
Uso mais frequente: Excel, PowerPoint e Word.
Office Standard 2007: R$ 999,00 - fonte:
Brasoftware
BrOffice.org
Verso brasileira do projeto OpenOffice.org / 2000.
Pacote de aplicativos em portugus com editor de
textos,
planilha
eletrnica,
software
de
apresentao, editor de imagens, etc.
Software de cdigo aberto.
Licenciamento GNU LGPL, que permite a livre
modificao, execuo e distribuio do cdigofonte, com a ressalva de que todas as mudanas
devem ser publicadas abertamente.
Principais plataformas (Windows, Linux, Solaris,
etc).
Equivalncias: Word - Writer, Excell - Calc, Power
Point - Impress
96

Mozilla Firefox
Possui vrios recursos (extenses) que voc pode
adicionar ao browser.
Arquitetura de programao baseada em
extenses, que tornam o navegador mais seguro.
Em vez de incorporar inmeros recursos, que
podem ser usados por cdigos maliciosos, o usurio
quem escolhe o que adicionar.
Possui cdigo aberto e foi desenvolvido por
programadores
independentes. Como h muitos envolvidos em sua
criao, isso pode facilitar no processo de deteco
de erros e de criao de correes.
Utilizado em 22,98% dos computadores que
acessam a Internet (fonte: Net Applications).
Ambiente Tecnolgico
O ambiente tecnolgico formado pelos
conhecimentos e informaes relativos aos
processos e produtos de seu ramo de negcios e
pelas organizaes que o produz. As organizaes
utilizam alguma forma de tecnologia para executar
suas operaes e realizar suas tarefas. As condies
tecnolgicas influenciam na competitividade das
empresas principalmente quando se trata de
tecnologia
sujeita
a
inovaes,
ou
seja, tecnologia dinmica e de futuro imprevisvel.
Portanto, acompanhar a evoluo tecnolgica
uma estratgia segura para garantir a sobrevivncia
e eficcia da organizao.
Ambiente Tecnolgico
O Ambiente tecnolgico refere-se aos fatores,
tendncias e condies gerais que afetam todas as
organizaes tendo em vista que as organizaes
so sistemas abertos.
As condies tecnolgicas influenciam na
competitividade das empresas, principalmente
quando se trata de tecnologia sujeita a inovaes,
ou seja, tecnologia dinmica e de futuro
imprevisvel. Acompanhar a evoluo tecnolgica
uma estratgia segura para garantir a sobrevivncia
e eficcia da organizao.
O ambiente tecnolgico de extrema relevncia
em termos de vantagem competitiva. A vantagem
se deve ao fato de que a tecnologia agrega
empresa agilidade, eficcia e eficincia (menor

custo e menor tempo) em suas operaes, porm,

no basta perceber as tendncias tecnolgicas que
iro modificar um mercado, deve-se tambm levar
em conta o processo de assimilao dessas
tecnologias pelos consumidores.
Exemplos de empresas que aplicaram o ambiente
tecnolgico:
INTERNET: A facilidade de acesso ao computador e
a tecnologia facilitou a integrao das empresas
com o mundo. crescente o nmero de empresas
que esto adotando mtodos de e-business
tecnologicamente sofisticado para lidar com as
maiorias das suas operaes.
FORD: Criou a montagem em srie, que garantiu a
produo em massa dos automveis em menos
tempo. Alm disso, a empresa passou a ter menor
custo por meio da utilizao de linha de
montagem (processo que fabricava um carro a
cada 98 minutos). A Ford desenvolveu tambm a
mecanizao do trabalho, padronizao do
maquinrio, do equipamento e dos produtos, sem
contar a forte diviso do trabalho manual em
relao ao trabalho braal.
Associar as tendncias tecnolgicas ao atendimento
das necessidades dos clientes primordial para o
sucesso das empresas
Engenharia de software
A engenharia de software a rea responsvel pelo
estabelecimento de tcnicas e prticas para
o desenvolvimento de software cobrindo uma
ampla rea de aplicaes e diferentes tipos de
dispositivos.1
Engenharia de software uma rea da computao
voltada

especificao, desenvolvimento e
manuteno de sistemas de software, com
aplicao de tecnologias e prticas de gerncia de
projetos e outras disciplinas, visando organizao,
produtividade e qualidade.2
Atualmente,
essas tecnologias e
prticas
englobam linguagens de programao, banco de
dados, ferramentas, plataformas,bibliotecas,
padres, processos e a questo da Qualidade de
software.
Os fundamentos cientficos para a engenharia de
software envolvem o uso de modelos abstratos e
precisos que permitem ao engenheiro especificar,
projetar, implementar e manter sistemas de
software, avaliando e garantindo suas qualidades.
Alm disso, a engenharia de software deve oferecer
97

mecanismos para se planejar e gerenciar o processo

de desenvolvimento de um sistema computacional.
ndice
[esconder]
1 Definio
2 reas de conhecimento
3 Processo de software
o 3.1 Modelos de processo de software
o 3.2 Modelos de maturidade
4 Metodologias e mtodos
o 4.1 Modelagem
5 Ferramentas, tecnologias e prticas
o 5.1 Ferramentas
6 Gerncia de projetos
o 6.1 Planejamento
o 6.2 Anlise de requisitos
o 6.3 Gesto
7 Histrico
8 ES no presente e tendncias
9 Ver tambm
10 Referncias
11 Bibliografia
12 Ligaes externas
Definio
Friedrich Ludwig Bauer foi o primeiro dizendo:
"Engenharia de Software a criao e a utilizao
de slidos princpios de engenharia a fim de
obter software de maneira econmica, que seja
confivel e que trabalhe em mquinas reais". O
prprio significado de engenharia j traz os
conceitos de criao, construo, anlise,
desenvolvimento e manuteno.
A Engenharia de Software se concentra nos
aspectos prticos da produo de um sistema
de software,
enquanto
a cincia
da
computao estuda os fundamentos tericos dos
aspectos computacionais.
O termo foi criado na dcada de 1960 e utilizado
oficialmente em 1968 na NATO Science Committee.
Sua criao surgiu numa tentativa de contornar
a crise do software e dar um tratamento de
engenharia (mais sistemtico e controlado)
ao desenvolvimento
de
sistemas de software complexos.
Um
sistema
de software complexo se caracteriza por um
conjunto
de
componentes
abstratos
de software (estruturas de dados e algoritmos)
encapsulados na forma de procedimentos, funes,
mdulos, objetos ou agentes e interconectados
entre si, compondo a arquitetura do software, que

devero
ser
executados
em sistemas
computacionais.
Os fundamentos cientficos envolvem o uso
de modelos abstratos e precisos que permitem ao
engenheiro especificar, projetar, implementar e
manter sistemas de software, avaliando e
garantindo suas qualidades. Alm disto, deve
oferecer mecanismos para se planejar e gerenciar o
processo
de
desenvolvimento.
Empresas
desenvolvedoras desoftware passaram a empregar
esses conceitos sobretudo para orientar suas reas
de desenvolvimento, muitas delas organizadas sob
a forma de Fbrica de Software.
A engenharia de sistemas uma rea mais ampla
por tratar de todos os aspectos de sistemas
baseados em computadores, incluindo hardware e
engenharia de processos alm do software.
A Universidade Federal de Gois foi a primeira
instituio no pas a criar o curso de graduao em
Engenharia de Software, tendo em constante
evoluo de sua grade curricular.
reas de conhecimento
Segundo o SWEBOK (Corpo de Conhecimento da
Engenharia de Software), verso 2004, as reas de
conhecimento da Engenharia de Software so:
Requisitos de software
Projeto de software
Construo de software
Teste de software
Manuteno de software
Gerncia de configurao de software
Gerncia de engenharia de software
Processos de Engenharia de Software
Ferramentas e Mtodos de Engenharia de
Software
Qualidade de software
Conforme Pressman, a Engenharia de Software (ES)
uma tecnologia em camadas. E a base de todas
essas camadas o foco na qualidade do software
desenvolvido. Portanto, inclusive do ponto de vista
didtico, interessante estudarmos a ES em suas
camadas de Processo, Mtodos e Ferramentas.
Processo de software
Ver artigo principal: Processos de Engenharia de
Software
Processo de software, ou processo de engenharia
de software, uma seqncia coerente de prticas
que objetiva o desenvolvimento ou evoluo de
sistemas de software. Estas prticas englobam as
atividades
de
especificao,
projeto,
98

implementao, testes e caracterizam-se pela

interao de ferramentas, pessoas e mtodos.
SEE e PSEE so os ambientes voltados ao
desenvolvimento e manuteno de processos. O
projeto ExPSEE uma continuao dos estudos de
processos, principalmente do ambiente PSEE.
Devido ao uso da palavra projeto em muitos
contextos, por questes de clareza, h vezes em
que se prefira usar o original em ingls design.
Modelos de processo de software
Um modelo de processo de desenvolvimento de
software, ou simplesmente modelo de processo,
pode ser visto como uma representao, ou
abstrao dos objetos e atividades envolvidas no
processo de software. Alm disso, oferece uma
forma mais abrangente e fcil de representar o
gerenciamento de processo de software e
consequentemente o progresso do projeto.
Exemplos de alguns modelos de processo de
software;
Modelos ciclo de vida
Sequencial ou Cascata (do ingls waterfall) com fases distintas de especificao, projeto e
desenvolvimento.
Desenvolvimento iterativo e incremental desenvolvimento iniciado com um
subconjunto
simples
de Requisitos
de
Software e iterativamente alcana evolues
subsequentes das verses at o sistema todo
estar implementado
Evolucional ou Prototipao - especificao,
projeto e desenvolvimento de prottipos.
V-Model - Parecido com o modelo cascata, mas
com uma organizao melhor, que permite que
se compare com outros modelos mais
modernos.
Espiral - evoluo atravs de vrios ciclos
completos de especificao, projeto e
desenvolvimento.
Componentizado - reuso atravs de montagem
de componentes j existentes.
Formal - implementao a partir de modelo
matemtico formal.
gil
RAD
Quarta gerao.
Modelos de maturidade
Os modelos de maturidade so um metamodelo de
processo. Eles surgiram para avaliar a qualidade dos

processos
de software aplicados
em
uma
organizao (empresa ou instituio). O mais
conhecido o Capability Maturity Model
Integration (CMMi),
do Software
Engineering
Institute - SEI.
O CMMI pode ser organizado atravs de duas
formas: Contnua e estagiada. Pelo modelo
estagiado,
mais
tradicional
e
mantendo
compatibilidade com o CMM, uma organizao
pode ter sua maturidade medida em 5 nveis:
Nvel 1 - Inicial (Ad hoc): Ambiente instvel. O
sucesso depende da competncia de
funcionrios e no no uso de processos
estruturados;
Nvel 2 - Gerenciado: Capacidade de repetir
sucessos anteriores pelo acompanhamento de
custos, cronogramas e funcionalidades;
Nvel
3 - Definido: O processo de
desenvolvimento de software bem definido,
documentado e padronizado a nvel
organizacional;
Nvel
4
Gerenciado
quantitativamente: Realiza
uma
gerncia
quantitativa do processo de software e do
produto por meio de mtricas adequadas;
Nvel 5 - Em otimizao: Usa a informao
quantitativa para melhorar continuamente e
gerenciar o processo de desenvolvimento. At
maro/2012, no Brasil, h somente 13
empresas neste nvel.3
O (MPS.BR), ou Melhoria de Processos do Software
Brasileiro, simultaneamente um movimento para
a melhoria e um modelo de qualidade de processo
voltada para a realidade do mercado de pequenas e
mdias empresas de desenvolvimento de software
no Brasil. O MPS.BR contempla 7 nveis de
maturidade, de A a G, sendo a primeira o mais
maduro. At agosto/2012, no Brasil, h somente 2
empresas neste nvel.4
Metodologias e mtodos
O termo metodologia bastante controverso nas
cincias em geral e na Engenharia de Software em
particular.
Muitos
autores
parecem
tratar metodologia e mtodo como
sinnimos,
porm seria mais adequado dizer que uma
metodologia envolve princpios filosficos que
guiam uma gama de mtodos que utilizam
ferramentas e prticas diferenciadas para realizar
algo.5
99

Assim teramos, por exemplo, a Metodologia

Estruturada, na qual existem vrios mtodos,
como Anlise
Estruturada e Projeto
Estruturado (muitas vezes denominados SA/SD,
eAnlise Essencial). Dessa forma, tanto a Anlise
Estruturada quanto a Anlise Essencial utilizam a
ferramenta Diagrama de Fluxos de Dados para
modelar o funcionamento do sistema.
Segue abaixo as principais Metodologias e Mtodos
correspondentes no desenvolvimento de software:
Metodologia Estruturada
Anlise Estruturada
Projeto Estruturado
Programao Estruturada
Anlise Essencial
SADT
DFD - Diagrama de Fluxo de Dados
MER
- Modelo
de
Entidades
e
Relacionamentos
Metodologia Orientada a Objetos
Orientao a Objetos
Rational Unified Process ( RUP )
Desenvolvimento gil de software
Feature Driven Development ( FDD )
Enterprise Unified Process (EUP)
Scrum (Scrum)
Crystal (Crystal Clear, Crystal Orange,
Crystal Orange Web)
Programao extrema ( XP )
Outras Metodologias
Microsoft Solution Framework ( MSF )
Modelagem
A abstrao do sistema de software atravs de
modelos que o descrevem um poderoso
instrumento para o entendimento e comunicao
do produto final que ser desenvolvido.
A maior dificuldade nesta atividade est no
equilbrio
(tradeoff)
entre
simplicidade
(favorecendo a comunicao) e a complexidade
(favorecendo a preciso) do modelo.
Para a modelagem podemos citar 3 mtodos:
Anlise estruturada, criada por Gane & Searson;
Anlise Essencial, criada por Palmer &
McMenamin e Ed. Yourdon;
UML, criada por Grady Booch, Ivar Jacobson &
Jaimes Rumbaugh. hoje o mtodo mais
comum para o paradigma orientado a objetos.
Ferramentas, tecnologias e prticas

A engenharia de software aborda uma srie de

prticas e tecnologias, principalmente estudadas
pela cincia da computao, enfocando seu
impacto na produtividade e qualidade de software.
Destacam-se
o
estudo
de linguagem
de
programao, banco de dados e paradigmas de
programao, como:
Programao estruturada
Programao funcional
Programao orientada a objetos
Componentes de Software
Programao orientada a aspecto
Ferramentas
Outro
ponto
importante

o
uso
de ferramentas CASE (do
ingls Computer-Aided
Software Engineering). Essa classificao abrange
toda ferramenta baseada em computadores que
auxiliam atividades de engenharia de software,
desde a anlise de requisitos e modelagem at
programao e testes.
Os ambientes de desenvolvimento integrado (IDEs)
tm maior destaque e suportam, entre outras
coisas:
Editor
Compilador
Debug
Gerao de cdigo
Modelagem
Deploy
Testes no automatizados
Testes automatizados
Refatorao (Refactoring)
Gesto de Riscos nos projectos de Software
Uso da Prototipagem na Eng. de Requisitos
Gerncia de projetos
A gerncia de projetos se preocupa em entregar o
sistema de software no prazo e de acordo com os
requisitos estabelecidos, levando em conta sempre
as limitaes de oramento e tempo.
A gerncia de projetos de software se caracteriza
por tratar sobre um produto intangvel, muito
flexvel e com processo de desenvolvimento com
baixa padronizao.
Planejamento
O planejamento de um projeto de desenvolvimento
de software inclui:
Anlise Econmica de Sistemas de Informaes
100

organizao do projeto (incluindo equipes e

responsabilidades)
estruturao das tarefas (do ingls WBS - work
breakdown structure)
cronograma do projeto (do ingls project
schedule)
anlise e gesto de risco
estimativa de custos
Essas atividades sofrem com dificuldades tpicas de
desenvolvimento de software. A produtividade no
linear em relao ao tamanho da equipe e o
aumento de produtividade no imediato devido
aos custos de aprendizado de novos membros. A
diminuio de qualidade para acelerar o
desenvolvimento
constantemente
prejudica
futuramente a produtividade.
A estimativa de dificuldades e custos de
desenvolvimentos so muito difceis, alm do
surgimento de problemas tcnicos. Esses fatores
requerem uma anlise de riscos cuidadosa.
Alm da prpria identificao dos riscos, h que ter
em conta a sua gesto. Seja evitando, seja
resolvendo, os riscos necessitam ser identificados
(estimando o seu impacto) e devem ser criados
planos para resoluo de problemas.
Anlise de requisitos
As atividades de anlise concentram-se na
identificao,
especificao
e
descrio
dos requisitos do sistema de software. Em resumo,
requisito uma necessidade que osoftware deve
cumprir.
H vrias interpretaes e classificaes sobre
requisitos, entre elas:
funcional
no funcional
de usurio
de sistema
comum que o cliente no saiba o que ele
realmente deseja, que haja problemas na
comunicao e ainda que haja mudana constante
de requisitos. Todos esses fatores so recrudescidos
pela intangibilidade sobre caractersticas de
sistemas de software, principalmente sobre o custo
de cada requisito.
Estudo de Viabilidade (Levantamento de
Requisitos)
A Engenharia de requisitos um processo que
envolve todas as atividades exigidas para criar e
manter o documento de requisitos de sistema

(SOMMERVILLE). Segundo RUMBAUGH, alguns

analistas consideram a engenharia de Requisitos
como um processo de aplicao de um mtodo
estrutura como a anlise orientada a objetos. No
entanto, a Engenharia de requisitos possui muito
mais aspectos do que os que esto abordados por
esses mtodos.
Abaixo um pequeno Processo de Engenharia de
Requisitos.
Estudo da viabilidade "Relatrio de Viabilidade"
Obteno e Anlise de Requisitos "Modelos de
Sistema" Especificao de Requisitos "Requisitos
de Usurio e de Sistema" Validao de Requisitos
"Documento de Requisitos"
O primeiro processo a ser realizado num Sistema
novo o Estudo de Viabilidade. Os resultados deste
processo devem ser um relatrio com as
recomendaes da viabilidade tcnica ou no da
continuidade no desenvolvimento do Sistema
proposto. Basicamente um estudo de viabilidade,
embora seja normalmente rpido, dever abordar
fundamentalmente as seguintes questes:
O Sistema proposto contribui para os objetivos
gerais da organizao?
O Sistema poder ser implementado com as
tecnologias dominadas pela equipe dentro das
restries de custo e de prazo? Ou precisa de
treinamentos adicionais?
O Sistema pode ser integrado, e compatvel
com os outros sistemas j em operao?
Gesto
Existem cinco tipo de gestes: pessoal, produto,
processo, projeto e material.
Histrico
A Engenharia de Software (ES) surgiu em meados
dos anos 1970 numa tentativa de contornar a crise
do software e
dar
um
tratamento
de engenharia (mais sistemtico e controlado) ao
desenvolvimento de sistemas de software
complexos. Um sistema de software complexo se
caracteriza por um conjunto de componentes
abstratos
de
software
(estruturas
de
dados e algoritmos) encapsulados na forma de
procedimentos, funes, mdulos, objetos ou agent
es interconectados entre si, compondo a
arquitetura do software, que devero ser
executados em sistemas computacionais.
ES no presente e tendncias
101

Atualmente existe um destaque todo especial para

a Engenharia de Software na Web. Tambm
utilizado por Presmann a sigla WebE, o processo
usado para criar WebApps(aplicaes baseadas na
Web) de alta qualidade. Embora os princpios
bsicos da WebE sejam muito prximos da
Engenharia de Software clssica, existem
peculiaridades especficas e prprias.
Com o advento do B2B (e-business) e do B2C (ecommerce), e ainda mais com aplicaes para
a Web 2.0, maior importncia ficou sendo esse tipo
de engenharia. Normalmente adotam no
desenvolvimento a arquitetura MVC (Model-ViewController).
Outra rea de tendncia em Engenharia de
Software trata da aplicao de tcnicas otimizao
matemtica para a resoluo de diversos problemas
da rea. A rea, denominada Search-based
software
engineering,
ou Otimizao
em
engenharia de software em Portugus, apresenta
vrios resultados interessantes.6 Para mais detalhes
em Portugus, ver texto com aplicaes da
otimizao em engenharia de software.7
O Brasil atualmente conta com seis cursos de nvel
superior em Engenharia de Software nas seguintes
instituies
reconhecidas
pelo MEC: UnB, UFRN, Universidade Federal do
Cear, Universidade Federal de Gois, Universidade
de Rio Verde, Unipampa e UniCesumar.8
Eventos acadmicos tambm mostram tpicos
interessantes sobre futuras tendncias de
engenharia de software. O Brasil em 2013 sedia
grandes eventos de engenharia como a Conferncia
Internacional de Engenharia de Requisitos9 e a
Escola Latino Americana de Engenharia de
Software.10
Idias bsicas da POO
A POO foi criada para tentar aproximar o mundo
real do mundo virtual: a idia fundamental tentar
simular o mundo real dentro do computador. Para
isso, nada mais natural do que utilizar Objetos,
afinal, nosso mundo composto de objetos, certo?!
Na POO o programador responsvel por moldar o
mundo dos objetos, e explicar para estes objetos
como eles devem interagir entre si. Os objetos
"conversam" uns com os outros atravs do envio de
mensagens, e o papel principal do programador
especificar quais sero as mensagens que cada
objeto pode receber, e tambm qual a ao que

aquele objeto deve realizar ao receber aquela

mensagem em especfico.
Uma mensagem um pequeno texto que os
objetos conseguem entender e, por questes
tcnicas, no pode conter espaos. Junto com
algumas dessas mensagens ainda possvel passar
algumas informaes para o objeto (parmetros),
dessa forma, dois objetos conseguem trocar
informaes entre si facilmente.
Ficou confuso? Vamos a um exemplo prtico:
imagine que voc est desenvolvendo um software
para uma locadora e esta locadora tem diversos
clientes. Como estamos tentando modelar um
sistema baseado no sistema real, nada mais obvio
do que existirem objetos do tipo Clientes dentro do
nosso programa, e esses Clientes dentro do nosso
programa nada mais sero do que objetos que
"simulam" as caractersticas e aes no mundo
virtual que um cliente pode realizar no mundo real.
Vamos apresentar exemplo mais detalhadamente
mais para frente, mas antes precisamos especificar
mais alguns conceitos.
O que uma Classe, Atributo e Mtodo? E pra que
serve o Construtor?
Uma classe uma abstrao que define um tipo de
objeto e o que objetos deste determinado tipo tem
dentro deles (seus atributos) e tambm define que
tipo de aes esse tipo de objeto capaz de realizar
(mtodos).
normal no entender isso logo de cara, mas os
conceitos de classes e subclasses so relativamente
simples: Tente pensar no conceito de Classes
utilizado na Biologia: um animal uma classe, e tem
suas caractersticas: um ser vivo capaz de pensar,
precisa se alimentar para viver, etc, etc. O Ser
Humano uma sub-classe dos animais. Ele tem
todas as caractersticas de um animal, mas tambm
tem algumas peculiaridades suas, no encontradas
nas outras sub-classes de animais. Os pssaros
tambm so animais, mas possuem caractersticas
prprias.
Note que uma Classe no tem vida, s um
conceito.
Mas
os Objetos (animais,
serem
humanos, pssaros, etc) possuem vida. O seu
cachorro rex um Objeto (ou instncia) da classe
Cachorro. A classe Cachorro no pode latir, no
pode fazer xixi no poste, ela apenas especifica e
define o que um cachorro. Mas Objetos do tipo
Cachorro, estes sim podem latir, enterrar ossos, ter
um nome prprio, etc.
102

A criao de uma nova Classe dividida em duas

partes: os seus atributos e os seusmtodos. Os
atributos so variveis que estaro dentro de cada
um dos objetos desta classe, e podem ser de
qualquer tipo. Por exemplo, a classe Cachorro
poder ter o atributo nome que ser do tipo String.
Assim, cada Objeto desta classe ter uma varivel
prpria chamada nome, que poder ter um valor
qualquer (Rex, Frodo, Atila, ...).
Mtodos sero as aes que a Classe poder
realizar. Quando um objeto desta classe receber
uma mensagem de algum outro objeto contendo o
nome de um mtodo, a ao correspondente a este
mtodo ser executada. Por exemplo, caso um
objeto da classe Dono envie uma mensagem para
um objeto do tipo Cachorro falando "sente", o
cachorro ir interpretar esta mensagem e
conseqentemente ir executar todas as instrues
que foram especificadas na classe Cachorro dentro
do mtodo sente.
Um construtor tem uma funo especial: ele serve
para inicializar os atributos e executado
automaticamente sempre que voc cria um novo
objeto.
Quando voc especifica os atributos de uma classe,
voc apenas diz ao sistema algo como "objetos
desta classe Pessoa vo ter uma varivel chamada
Nome que do tipo String, uma varivel chamada
idade que do tipo inteiro, etc, etc". Mas estas
variveis no so criadas, elas s sero criadas no
construtor. O construtor tambm pode receber
parmetro, desta forma, voc pode passar para o
construtor uma String contendo o nome da Pessoa
que voc est criando, sua idade, etc.
Normalmente, a sintaxe algo parecido com isto:
Pessoa joao := new Pessoa( "Joo", 13 );
Este
cdigo
gera
um
novo objeto chamado joao que do tipo Pessoa e
contem os valores "Joo" como nome e 13 como
idade.
Caso voc tenha entendido o texto acima, voc
entendeu 99% do que esta por trs da orientao a
objetos. O mais importante entender como
funciona a comunicao entre os objetos, que
sempre segue o seguinte fluxo:
-Um objeto A envia uma mensagem para o
objeto B.
-Objeto B verifica qual foi a mensagem que recebeu
e executa sua ao correspondente. Esta ao est
descrita no mtodo que corresponde a mensagem

recebida, e est dentro da Classe a qual este objeto

pertence.
Exemplo
Voltando ao exemplo da locadora: Voc est
desenvolvendo um software para uma locadora.
Esta locadora ter diversos clientes. Podermos
ento criar uma classe explicando para o
computador o que um Cliente: para isso
precisaramos criar uma classe chamada Cliente, e
com as seguintes caractersticas (atributos):
Nome
Data de Nascimento
Profisso
Mas um cliente mais do que simples dados. Ele
pode realizar aes! E no mundo da POO, aes so
descritas atravs da criao de mtodos.
Dessa forma, objetos da nossa classe Cliente poder
por exemplo executar as seguintes aes
(mtodos):
AlugarFilme
DevolverFilme
ReservarFilme
Note o tempo verbal empregado ao descrever os
mtodos. Fica fcil perceber que trata-se
de aes que um Cliente pode realizar.
muito importante perceber as diferenas entre
Atributo e Mtodo. No comeo normal ficar um
pouco confuso, mas tenha sempre em mente:
Atributos so dados.
Mtodos descrevem possveis aes que os
objetos so capazes de realizar.
Assim, nosso sistema pode ter vrios Objetos do
tipo Cliente. Cada um destes objetos possuir seu
prprio nome, data de nascimento e profisso, e
todos eles podero realizar as mesmas aes
(AlugarFilme, RevolverFilme ou ReservarFilme).
Herana
Voltando a idia das classes na Biologia: um ser
humano um animal. Ele tem todas as
caractersticas (atributos) e pode realizar todas as
aes (mtodos) de um animal. Mas alm disso, ele
tem algumas caractersticas e aes que s ele pode
realizar.
Em momentos como este, utilizado a herana.
Uma classe pode estender todas as caractersticas
de outra e adicionar algumas coisas a mais. Desta
forma, a classe SerHumano ser uma especializao
(ou subclasse) da classe Animal. A classe Animal
seria a classe pai da serHumano, e logicamente, a
classe SerHumano seria a classe filha da Animal.
103

Uma classe pode sempre ter vrios filhos, mas

normalmente as linguagens de programao
orientadas a objetos exigem que cada classe filha
tenha apenas uma classe pai. A linguagem C++
permite que uma classe herde as caractersticas de
varias classes (herana mltipla), mas C++ no um
bom exemplo quando se est falando sobre
conceitos de POO.
Um exemplo um pouco mais prximo da nossa
realidade:
vamos
supor
que
estamos
desenvolvendo um sistema para um banco. Nosso
banco possui clientes que so pessoas fsicas e
pessoas jurdicas.
Poderiamos criar uma classe chamada Pessoa com
os seguintes atributos:
Nome
Idade
Em seguida, criamos 2 classes que so filhas da
classe
Pessoa,
chamadas PessoaFisica e PessoaJuridica. Tanto a
classe PessoaFisia como a PessoaJuridica herdariam
os atributos da classe Pessoa, mas poderiam ter
alguns atributos a mais.
A classe PessoaFisica pode ter por exemplo o
atributo RG enquanto a classe PessoaJuridica
poderia ter o atributo CNPJ.
Dessa
forma,
todos
os
objeto
da
classe PessoaFisica ter como atributos:
Nome
Idade
RG
E todos os objetos da classe PessoaJuridica tero os
seguintes atributos:
Nome
Idade
CNPJ
Os mtodos so anlogos: poderamos criar alguns
mtodos na classe Pessoa e criar mais alguns
mtodos nas classes PessoaJuridica e PessoaFisica.
No final, todos os objetos teriam os mtodos
especificados na classe Pessoa, mas s os objetos
do tipo PessoaJuridica teriam os mtodos
especificados dentro da classe PessoaJuridica, e
objetos do tipo PessoaFisica teriam os mtodos
especificados na classe PessoaFisica.
Polimorfismo
Um dos conceitos mais complicados de se
entender, e tambm um dos mais importantes,

o Polimorfismo. O termo polimorfismo originrio

do grego e significa "muitas formas".
Na orientao a objetos, isso significa que um
mesmo tipo de objeto, sob certas condies, pode
realizar aes diferentes ao receber uma mesma
mensagem. Ou seja, apenas olhando o cdigo fonte
no sabemos exatamente qual ser a ao tomada
pelo sistema, sendo que o prprio sistema quem
decide qual mtodo ser executado, dependendo
do contexto durante a execuo do programa.
Desta forma, a mensagem "fale" enviada a um
objeto da classe Animal pode ser interpretada de
formas diferentes, dependendo do objeto em
questo. Para que isto ocorra, preciso que duas
condies sejam satisfeitas: exista herana de
uma classe abstrata e casting (outras situaes
tambm podem resultar em polimorfismo, mas
vamos nos centrar neste caso).
Herana nos j definimos previamente, mas o que
uma classe abstrata? E o que esse tal de casting?
Uma classe abstrata uma classe que representa
uma coleo de caractersticas presentes em vrios
tipos de objetos, mas que no existe e no pode
existir isoladamente. Por exemplo, podemos criar
uma classe abstrata chamada Animal. Um Animal
tem diversas caractersticas (atributos) e podem
realizar diversas aes (mtodos) mas no existe a
possibilidade de criarmos objetos do tipo Animal. O
que existem so objetos das classes Cachorro, Gato,
Papagaio, etc. Essas classes, estendem a classe
Animal herdando todas as suas caractersticas, e
adicionando algumas coisas a mais. "Animal" s
uma entidade abstrata, apenas um conjunto de
caractersticas em comum, nada mais.
Voc pode olhar para um objeto da classe Cachorro
e falar "isto um animal, pois estende a classe
Animal", mas voc nunca vai ver um objeto que seja
apenas da classe Animal, pois isso no existe!
como eu olhar para voc e falar "voc um objeto
da classe SerVivo". Essa afirmao est correta, mas
voc na verdade um objeto da classe SerHumano,
que por sua vez herda todas as caractersticas da
classe SerVivo (que por sua vez uma classe
abstrata, j que no podemos criar algo que seja
apenas classificado como "SerVivo", sempre vamos
classifica-lo de forma menos genrica).
Resumindo: uma classe abstrata um conjunto de
informaes a respeito de uma coleo de outras
classes. Uma classe abstrata sozinha
completamente intil, j que no podemos
104

instanciar um objeto desta classe, podemos apenas

instanciar objetos de classes que estendem a classe
abstrata inicial. Ela serve apenas para simplificar o
sistema, juntando em um nico lugar diversas
caractersticas que so comuns a um grupo de
classes.
Nunca esquea disso: voc nunca vai poder criar
um objeto do tipo de uma classe abstrata. Sempre
crie objetos das classes que estendem esta classe
abstrata.
J o termo casting utilizado quando nos foramos
o sistema a ver um certo objeto como sendo de um
determinado tipo que no o seu tipo original.
Supondo que temos a situao a seguir:

Essa uma representao na notao UML

(Unified Modeling Language) que nos informa que
existe a definio de trs classes em nosso sistema:
existe a classe abstrata Animal (note que ela est
em itlico, isso significa na notao UML que tratase de uma classe abstrata) e existem tambm
outras duas classes chamadas Cachorro e Gato, que
so filhas da classe Animal. Ou seja, todo objeto
das classes Cachorro e Gato vo ter todas as
caractersticas (atributos e mtodos) presentes na
classe Animal, e mais algumas caractersticas
prprias.
Imagine que vamos criar um sistema de cadastro de
animais. Vamos, por questes didticas, supor que
todos os animais de nosso sistema fiquem
armazenados em um array. Ento existiria
um array contendo objetos dos tipos Gato e do tipo
Cachorro. Mas armazenar diversos tipos diferentes
de objetos em um nicoarray no uma boa idia,
pois depois, para extrair essas informaes de volta
bastante complicado. Mas pare e pense por um
instante: objetos do tipo Cachorro e objetos do tipo
Gato so tambm objetos do tipo Animal, correto?
Bom, ento podemos criar um array capaz de
armazenar Animais! Assim nossa vida fica bem mais
fcil, bastando atribuir ao array os objetos (do tipo

Cachorro e Gato - que estendem a classe Animal)

que queremos guardar. Em forma algortmica, seria
mais ou menos:
Animal[] listaDeAnimais = new Animal[100]; //
Criamos um array com 100 posies que armazena
objetos do tipo Animal.
listaDeAnimais[0] = new Cachorro("Frodo"); //
Criamos um novo objeto do tipo Cachorro com o
nome Frodo e armazenamos no array
listaDeAnimais[1] = new Gato("Alan"); // Criamos
um novo objeto do tipo Gato com o nome Alan e
armazenamos no array
.......
Certo! Agora temos um array com vrios objetos do
tipo Animal. Agora vamos fazer um looping por
todos esses objetos, enviando para cada um deles a
mensagem "fale". O que iria acontecer?
Inicialmente, vamos supor que a classe abstrata
Animal possui o mtodo "fale", e que ele seja
implementado (de forma algortmica) da seguinte
forma:
Classe Animal {
mtodo fale() {
imprimaNaTela(" Eu sou mudo! ");
}
}
Desta forma, todo objeto que de alguma classe que
estenda a classe Animal vai ter automaticamente o
mtodo "fale", e isso inclui todos os objetos das
classes Cachorro e Gato. Mas todos eles,
atualmente, ao receber a mensagem "fale" vo
responder imprimindo na tela a mensagem "Eu sou
mudo!". Mas Gatos e Cachorros podem falar! O que
podemos fazer sobreescrever o mtodo fale para
cada uma das classes, substituindo ento seu
contedo pelo comportamento que queremos que
cada subclasse tenha.
Por exemplo, poderamos escrever na classe Gato
do seguinte mtodo:
Classe Gato {
Mtodo fale() {
imprimaNaTela(" Miaaaaaauuuuuu! ");
}
}
Para a classe Cachorro, poderamos fazer de forma
semelhante:
Classe Cachorro {
Mtodo fale() {
imprimaNaTela(" Au au au! ");
}
105

}
Agora, se fizermos um looping entre todos os
objetos
contidos
em
nosso array criado
anteriormente enviando para cada objeto a
mensagem "fale", cada um deles ir ter um
comportamento diferente, dependendo se um
Cachorro ou um Gato. Nosso looping entre todos os
animais cadastrado no nosso sistema seria mais ou
menos assim:
int cont;
para cont de 0 a 100 faa {
listaDeAnimais[cont].fale();
}
Isto polimorfismo! Uma mesma mensagem
enviada para diferentes objetos da mesma classe
(Animal) e o resultado pode ser diferente, para cada
caso. :-)
Vantagens da POO
Os sistemas, em geral, possuem uma diviso de
cdigo um pouco mais lgica e melhor
encapsulada do que a empregada nos sistemas
no orientados a objetos. Isto torna a
manuteno e extenso do cdigo mais fcil e
com menos riscos de insero de bugs. Tambm
mais fcil reaproveitar o cdigo.
mais fcil gerenciar o desenvolvimento deste
tipo de software quando temos uma equipe
grande. Podemos fazer uma especificao UML
antes de iniciar o desenvolvimento do software
em si, e em seguida dividirmos o sistema em
classes e pacotes, e cada membro da equipe
pode ficar responsvel por desenvolver uma
parte do sistema.
Desvantagens da POO
Na minha opinio, o aprendizado do paradigma
de programao orientada a objetos bem
mais complicado no incio do que os velhos
sistemas procedurais. Para comear a
programar necessrio ter estabelecido uma
srie de conceitos bastante complexos. J na
programao procedural tradicional, basta
decorar meia dzia de comandos e voc j
consegue fazer um programa simples.
Dificilmente uma linguagem orientada a objetos
conseguir ter um desempenho em tempo de
execuo superior a linguagens no orientadas
a objetos.
Concluses
Espero que com este texto voc tenha ao menos
entendido o bsico da orientao a objetos. No se

preocupe caso voc tenha "viajado" em algumas

partes do texto, perfeitamente normal. Agora siga
em frente, continue estudando e leia um bom livro
sobre a linguagem de programao que quer
aprender. Caso esteja dando seus primeiros passos
no mundo orientado a objetos, um bom comeo
pode ser a linguagem Ruby. Ela uma linguagem
interpretada e bastante fcil de aprender, e ainda
assim, possui um bom sistema de orientao a
objetos, sendo um timo ambiente para comear.
Alm disso, Ruby uma linguagens que vem
crescendo bastante no mercado, sendo que tem se
destacado bastante no desenvolvimento de
softwares para web, substituindo linguagens como
como PHP, Perl e Java

Metodologia Orientada a Objetos

1. Metodologia
Metodologia a forma explcita de estruturar
pensamentos e aes. Define:
o que fazer;
como fazer;
quando fazer;
porque deve ser feito.
2. Conceito de Orientao a Objetos
O conceito de orientao a objetos surgiu no fim da
dcada de 80, e significa que o sistema
organizado em uma coleo de objetos separados
que incorporam tanto a estrutura quanto o
comportamento dos dados.
A Orientao Objeto pode ser aplicada na
modelagem e no desenvolvimento de sistemas. Na
modelagem, a orientao objeto pode ser aplicada
atravs das notaes para modelagem de sistemas
orientados a objetos, essas notaes (UML, OMT,
Booch, etc) so regras, conceitos e representaes
grficas do sistema. E no desenvolvimento de
sistemas atravs de linguagens de programao
orientada a objetos (Java, C++, Delphi, etc).
A Orientao a Objetos uma metodologia de
desenvolvimento de software.
3. Objetos e Classes
No dicionrio pode-se encontrar as seguintes
definies de objetos:
Tudo que manipulvel e/ou manufaturvel;
Tudo que perceptvel por qualquer dos sentidos;
Coisa, pea, artigo de compra e venda;
Matria, assunto, Agente; motivo, causa.
106

Pelo conceito de Orientao a Objeto, pode-se

definir objeto como uma abstrao, com limites e
significados bem definidos, em relao ao problema
considerado. Cada objeto tem sua prpria
identidade, que lhe inerente.

4. Metodologia Estruturada X Metodologia

Orientada a Objetos
Na metodologia estruturada o foco na
especificao e decomposio da funcionalidade do
sistema enquanto que na metodologia orientada a
objetos, primeiro identificam-se os objetos
contidos no domnio do sistema e depois os
procedimentos relativos a ele.
Em resumo:
Metodologia estruturada = o foco na
especificao e decomposio da funcionalidade do
sistema
Metodologia orientada a objetos = primeiro
identificam-se os objetos contidos no domnio do
sistema e depois os procedimentos relativos a ele.

2) Jogo de Futebol
Anlise de um campo de futebol utilizando
metodologia estruturada
Passe da bola;
Fazer gol;
Cobrar lateral;
Cobrar tiro de meta;
Driblar o jogador;
Cobrar falta;
Marcar penault;
Passar a bola.
Anlise de um campo de futebol utilizando
metodologia orientada a objetos
Jogador;
Juiz;
Bola;
Campo.
5. Alguns Conceitos Utilizados na Orientao a
Objetos
Durante o curso conceitos como abstrao,
atributo, entre outros sero utilizados para a
elaborao dos modelos Orientados a Objetos. Para
uma viso inicial e geral so apresentados esses
conceitos a seguir.
107

 Abstrao: o termo abstrao significa ressaltar os

aspectos essenciais de uma entidade e ignorar os
aspectos no relevantes para o enfoque
considerado;
Atributo: caracterstica da classe que pode ter
valor diferenciado para cada objeto instanciado;
Operao: uma ao ou transformao realizada
por um objeto ou sofrida por um objeto;
Propriedade: a implementao de um atributo
para uma classe;
Mtodo: a implementao de uma operao
para uma classe;
Polimorfismo: a implementao de uma mesma
operao em diversas classes. Atravs do
polimorfismo, a mesma operao se comporta de
forma distinta em classes distintas. Exemplo:
operao incluir, pode possuir mtodos distintos,
como: incluir cliente, incluir fornecedor, ...
Herana: o compartilhamento de atributos e
operaes entre as classes que possuem
relacionamento de hierarquia. Exemplo: um cliente
pode ser pessoa fsica ou pessoa jurdica;
Superclasse/Subclasse: Ao evidenciar os atributos
e as operaes de um conjunto de classes,
identifica-se uma superclasse (generalizao)
refinada em subclasses (especializao). Uma
subclasse herda atributos e operaes das
superclasses e possui seus
atributos e operaes especficas;
Encapsulamento: um pacote de atributos e
operaes o qual representa um estado em um tipo
de objeto, de tal forma que o estado acessvel ou
modificado somente pela interface provida pelo
encapsulamento.
Cardinalidade: quantidade de instncias
determinada para o relacionamento entre duas
classes. Por exemplo: 1 para n, 1 para 1, m para n.
6. Notao UML
A UML (Unifield Modeling Language) uma
linguagem padro para a elaborao da estrutura
de projetos de software, que surgiu em meados da
dcada de 90 visando unificar as diversas notaes
de modelagem orientadas a objetos, como por
exemplo: OMT (Object Modeling Technique
Rumbaugh), OOSE (Object-Oriented Software
Engineering Jacobson), Booch, entre outras. Cada
uma dessas notaes citadas possui suas qualidades
e deficincias, o OMT forte

em anlise e mais fraco em projeto, Booch forte

em projeto e mais fraco em anlise, Jacobson
forte em comportamento de anlise e mais fraco
em outras reas. Com isso, a UML uma notao
unificada e padro de todas as notaes mais
utilizadas na modelagem de sistemas.
Pode-se definir UML como uma linguagem de
modelagem usada para especificar, visualizar,
construir e documentar sistemas orientados a
objetos.
Durante o curso o UML ser utilizado como notao
principal para a metodologia orientada a objetos
em conjunto com a ferramenta Rational Rose.

6.3. O que a UML ?

Linguagem visual para a especificao de sistemas
orientados a objetos;
Visa:
Visualizar
Especificar
Construir
Documentar
independente de:
Fases de desenvolvimento de software
Processo de software utilizado
108

 Linguagens de programao
6.3. Objetivos da UML
Modelar sistemas utilizando conceitos de
Orientao a Objetos;
Estabelecer uma clara ligao entre os modelos
conceituais e de implementao;
Explicitar os pontos notveis em sistemas
complexos ou de misso crtica;
Definir uma linguagem de modelagem passvel de
uso por pessoas e mquinas.
6.4. Aspectos da UML
Funcional
Casos de Uso
Esttico (Estrutural)
Diagrama de Classes
Dinmico (Comportamental)
Diagrama de Seqncia, Atividades e Estados
7. Viso Geral dos Modelos da UML
Diagrama de Casos de Uso: descreve as
funcionalidades do sistema e os usurios e
entidades externas, organizando o comportamento
do sistema. Alm do diagrama h toda a descrio
de atores e casos de uso.
Diagrama de Classes: descreve a estrutura de
soluo do sistema, atravs de um conjunto de
classes (compostas de atributos e operaes), e
relacionamentos. Geralmente dividido em
diagrama de classes de anlise (domnio) e
diagrama de classes de projeto (implementao).
Diagrama de Objetos: descreve um conjunto de
objetos e seus relacionamentos. Esse diagrama
ilustra as estrutura de dados e instncias do
diagrama de classes.
Diagrama de Seqncia: faz parte do conjunto de
diagramas
de
interao,
descreve
o
comportamento do sistema, enfatizando a
comunicao dos objetos atravs da passagem de
mensagem entre os mesmos;
Diagrama de Colaborao ou Comunicao (na
UML 2.0): faz parte do conjunto de diagramas de
interao, descreve o comportamento do sistema,
enfatiza a organizao estrutural dos objetos que
enviam e recebem mensagens;
Diagrama de Atividades: descreve o
comportamento do sistema, atravs do fluxo de
controle de funes.

Diagrama de Estados: descreve o comportamento

do sistema, enfatizando os estados que o objeto
pode possuir.
Diagrama de Componentes: descreve os
componentes que iro ser criados no sistema e a
comunicao entre eles;
Diagrama de Distribuio: descreve a arquitetura
fsica e os componentes utilizados no sistema.
Diagrama de Pacotes (na UML 2.0): fornece um
mecanismo de organizao para os elementos da
UML. O pacote utilizado para agrupar elementos
da modelagem.
Diagrama de Interao Viso Geral (na UML
2.0): faz parte do conjunto de diagrama de
interao, apresenta a viso geral, de congregao,
dos outros diagramas de interao (seqncia,
comunicao e tempo).
Diagrama de Tempo (na UML 2.0): faz parte do
conjunto de diagrama de interao, descreve o
comportamento de um ou mais objetos em dado
perodo de tempo, mostrando suas alteraes de
estados.
Diagrama de Composio de Estrutura (na UML
2.0): descreve a composio de diversos elementos
de modelagem, como: interfaces, objetos ou
classes, mas que no perdem suas
caractersticas em combinao com outras.
8. Vises Arquiteturais

9. Viso de Casos de Uso

Descreve as funcionalidades do sistema o
qu;
Facilita o entendimento dos usurios;
Base para as demais vises;
Representada pelos diagramas de casos de
uso e diagrama de atividades (eventual).
Viso Lgica
Descreve como as funcionalidades sero
fornecidas;
Define o comportamento do sistema;
Representada pelos diagramas de classes,
seqncia, estados e atividades.
109

Viso de Processo
Descreve a diviso do sistema em processos;
Centrado na viso no funcional do sistema,
como desempenho, segurana e
concorrncia;
Representada pelos diagramas seqncia,
estados e atividades.
Viso de Implementao
Descreve os mdulos de implementao, suas
estruturas e dependncias;
Utilizada pelos desenvolvedores;
Representada pelo diagrama de componentes.
Viso de Distribuio
Exibe a distribuio fsica do sistema atravs
de ns e suas conexes;
Mapeia quais programas e objetos so
executados em cada computador;
Representada pelo diagrama de distribuio.
9. Algumas Ferramentas:
Rational Rose (www.ibm.com)
OMondo (www.omondo.com)
ArgoUML (www.argouml.tigris.org)
Jude (http://jude.change-vision.com)
Enterprise Architect (www.sparxsystems.com)
Orientao a objetos : Conceitos Bsicos
As tcnicas orientadas a objeto permitem que o
software seja construdo de objetos que tenham
um comportamento especifico. Os prprios objetos
podem ser construdos a partir de outros, os quais,
por sua vez, podem ainda ser construdos de
outros.
A anlise de sistemas no mundo orientado a objeto
feita analisando-se os objetos e os eventos que
interagem com esses objetos. O projeto de
software feito reusando-se classes de objetos
existentes e quando necessrio, construindo-se
novas classes.
Tcnicas orientadas a objeto podem ser usadas
para simplificar o projeto de sistemas complexos. O
sistema pode ser visualizado como uma coleo de
objetos, estando cada um dos objetos em um
determinado estado. Os objetos so construdos a
partir de outros objetos.
A anlise e o projeto orientados a objeto modelam
o mundo em termos de objetos que tem
propriedades e comportamentos e eventos que

disparam operaes que mudam o estado dos

objetos. Os objetos interagem com outros objetos.
A modelagem e o projeto orientados a objeto so
os paradigmas que devem integrar todas as
ferramentas e tcnicas poderosas para a criao de
software. Estratgia de desenvolvimento baseada
no conceito de que o sistema deve ser construdo a
partir de componentes reutilizveis, chamados de
objetos.
Conceitos
Entre as ideias fundamentais bsicas para a
tecnologia orientada a objeto incluem-se:
Objetos;
Classes;
Mtodos;
Herana;
Encapsulamento;
Cada conceito uma ideia ou um entendimento
pessoal que temos do nosso mundo. Os conceitos
que adquirimos nos permitem dar sentido sobre as
coisas do nosso mundo. Essas coisas s quais nossos
conceitos se aplicam so denominados objetos.
Objeto
Um objeto pode ser real ou abstrato.
Os objetos possuem informaes (contm
dados) e desempenham aes (possuem
funcionalidade).
Qualquer coisa qual um conceito ou tipo
de objeto se aplica uma instncia de um
conceito ou tipo de objeto.
Um objeto uma instncia de uma classe.
Exemplo:
o Uma fatura;
o Uma organizao;
o Um vo de avio;
o Uma pessoa;
o Um lugar.
Na anlise e no projeto OO, estamos interessados
no comportamento do objeto. As operaes so
codificadas como mtodos. A representao de
software OO do objeto , dessa forma, uma coleo
de tipos de dados e mtodos. No software OO: Um
objeto qualquer coisa, real ou abstrata, a respeito
da qual armazenamos dados e os mtodos que os
manipulam.
Exemplo: um tipo de objeto poderia ser Fatura e
um objeto poderia ser n. 51.783.
OBS: O termo objeto, porm, diferente do termo
entidade. A entidade preocupa-se apenas com os
dados enquanto o objeto preocupa-se tanto com os
110

dados como com os mtodos com os quais os

dados so manipulados.
Mtodos
Os mtodos especificam a maneira pela qual
os dados de um objeto so manipulados.
Uma especificao dos passos pelos quais
uma operao deve ser executada.
Ele um script de implementao de uma
operao.
Diferentes mtodos podem ser usados para
executar a mesma operao.
Os mtodos de um tipo de objeto
referenciam somente as estruturas de dados
desse tipo de objeto.
A ao que um objeto ou uma classe podem
desempenhar.
Os mtodos so similares s funes e
procedures do universo da programao
estruturada.
Um objeto , dessa forma, uma coisa, com suas
propriedades representadas pelos tipos de dados e
seu comportamento representado pelos mtodos.
Encapsulamento
O ato de empacotar ao mesmo tempo dados e
objetos denominado encapsulamento. O objeto
esconde seus dados de outros objetos e permite
que os dados sejam acessados por intermdio de
seus prprios mtodos. Isso chamado de
ocultao de informaes (information hiding).
O encapsulamento protege os dados do
objeto do uso arbitrrio e no-intencional.
O encapsulamento o resultado (ou ato) de
ocultar do usurio os detalhes da
implementao de um objeto.
O encapsulamento importante porque
separa a maneira como um objeto se
comporta da maneira como ele
implementado.
A definio de como implementar os
conhecimentos ou aes de uma classe, sem
informar como isto feito.
Exemplo:

Cada objeto encapsula uma estrutura de dados e

mtodos. Uma estrutura de dados encontra-se no
centro de um objeto. O objeto manipulado por
mtodos que implementam as operaes
permitidas. A estrutura de dados pode ser usada
somente com os mtodos. Essa restrio ao acesso
denominada encapsulamento, que protege os
dados contra adulterao. Os dados do objeto no
podem ser usados, exceto com esses mtodos.
Classe
O termo classe refere-se implementao de
software de um tipo de objeto. Um tipo de objeto
especifica uma famlia de objetos sem estipular
como o tipo e o objeto so implementados. Os tipos
de objetos so especificados durante a anlise OO.
Os tipos de objetos so implementados como
mdulos enquanto na linguagem orientada a
objeto, os tipos de objetos so classificados como
classes.
Uma classe uma implementao de um
tipo de objeto.
Uma classe especifica uma estrutura de
dados e os mtodos operacionais
permissveis que se aplicam a cada um de
seus objetos.
Uma classe pode ter sua prpria estrutura
de dados e mtodos, bem como herda - l
de sua superclasse.
Exemplo: Classe- Objeto - Mtodo - Atributo.

Classes Abstratas e Concretas

A classe abstrata uma classe que no possui
objetos instanciados a partir dela, enquanto a
classe concreta possui objetos instanciados
(criados) a partir dela.
Exemplo: No mundo real, por exemplo, existem
automveis e avies, mas nada que seja
simplesmente um veiculo (em outras palavras, se
111

no for um carro ou avio, no de nosso

interesse). Isso significa que podemos instanciar
objetos como carros e avies, mas nunca iremos
criar objetos veculos. As classes abstratas so
criadas quando necessitamos de uma classe que
implemente recursos comuns a duas ou mais
classes.

Herana
comum haver similaridades entre diferentes
classes. Frequentemente, duas ou mais classes iro
compartilhar os mesmos atributos e/ou mtodos.
Como nenhum de ns deseja reescrever vrias
vezes o mesmo cdigo, seria interessante se algum
mecanismo pudesse tirar proveito dessas
similaridades. A herana esse mecanismo. Por
intermdio da herana, possvel modelar
relacionamentos do tipo "" ou " semelhante", o
que nos permite reutilizar rotinas e dados j
existentes.
Uma subclasse herda as propriedades de sua classeme; uma subclasse herda as propriedades das
subclasses e assim por diante. Uma subclasse pode
herdar a estrutura de dados e os mtodos, ou
alguns dos mtodos, de sua superclasse. Ela
tambm tem mtodos e s vezes, tipos de dados
prprios.
Subclasse uma classe que um subtipo de uma
ou mais classes (denominadas superclasses). Como
tal, ela herda todas as caractersticas de suas
superclasses. Em outras palavras, todas as
caractersticas de uma classe so reusveis por suas
subclasses. Se a classe B herda de A, ento dizemos
que B uma subclasse de A.
Superclasse Uma classe que um supertipo de
uma ou mais classes (tb chamadas de subclasses).
Como tal, ela uma classe a partir da qual todas as
suas caractersticas so herdadas por suas
subclasses. Em outras palavras, todas as
caractersticas de uma superclasse so reusveis
por aquelas classes que so seus subtipos. Se a

classe B herda de A, ento dizemos que A uma

superclasse de B.
Exemplo 1: A figura abaixo mostra uma classe e
uma subclasse. A subclasse tem os mesmos
mtodos de sua superclasse, mas tem tambm o
mtodo G. s vezes, uma classe herda propriedades
de mais de uma superclasse. Isso denominado
herana mltipla.

Exemplo 2: Pessoa professor aluno

OBS: As subclasses devero sempre ficar abaixo da

superclasse e o semicrculo dever sempre apontar
da subclasse para a superclasse
Herana Simples e Mltipla
Quando uma classe herda caractersticas somente
de uma outra classe, dizemos que esta uma
herana simples. Quando uma classe herda de duas
ou mais classes, temos um caso de herana
mltipla. Em qualquer circunstncia, o fato que
voc dever lembrar o seguinte: a subclasse herda
todos os atributos e mtodos das superclasses.
112

cliente. A informao produzida aquela

que o cliente deve discutir e aprovar
2. O projeto inclui as atividades que resultam
em informao que interessa apenas ao
programador
3. Com essa definio, a anlise invade um
pouco o "lado da soluo", pois o cliente
deve discutir alguns tipos de interaes que
ocorrero na interface do usurio, etc.
Hierarquias de Generalizao
Um conjunto de classes relacionadas por meio da
herana. Uma boa maneira de organizarmos os
conhecimentos arranjando-o em hierarquias do
geral para o mais especifico. Por exemplo, a figura
abaixo descreve uma hierarquia com o
conhecimento do tipo de objeto Pessoa no topo.
Isso significa que Pessoa um tipo de objeto mais
geral do que empregado e estudante. Isso significa
que empregado e estudante so subtipos de
pessoa, ou, inversamente, que pessoa um
supertipo de empregado e estudante

Diferenas entre anlise e projeto:

Primeira alternativa:
1. A anlise modela o problema e consiste das
atividades necessrias para entender o
domnio do problema (o que deve ser feito).
uma atividade de investigao.
O projeto modela a soluo e consiste das
atividades de criao (como pode ser feito)

Segunda alternativa:
1. A anlise consiste de todas as atividades
feitas com ou para o conhecimento do

Diagramas de Objeto-Relacionamento
Os tipos de objetos tm relao com outros tipos de
objeto.
Os
diagramas
de entidaderelacionamento so usados h anos na anlise
convencional de sistemas. Os diagramas mostram
as associaes entre tipos de entidades. Um
diagrama de objeto-relacionamento representado
da mesma maneira que o diagrama de entidade
relacionamento.
Veja a figura abaixo:

Um diagrama de objeto-relacionamento
essencialmente o mesmo que um diagrama
de entidade-relacionamento, onde cada retngulo
poderia ser um tipo de objeto na analise e projeto
orientado a objeto. Fica mais fcil o entendimento
do modelo quando os tipos de objetos e as relaes
so representados num diagrama de objetorelacionamento; supertipos e subtipos num
diagrama de generalizao.
113

Diagramas Orientados a Objeto

Resumo dos smbolos usados para a analise e
projeto orientado a objeto. Como j sabemos um
objeto, como uma entidade, uma coisa real ou
abstrata. Ns, por conseguinte, usamos um
retngulo para desenhar tipos de objetos.
Recomenda-se que os tipos de objetos e classes
sejam desenhados com caixas de cantos vivos e as
atividades com caixas de cantos arredondados
Significado :

Multiplicidade de Associao (cardinalidade):

o nmero de instncias de uma classe
relacionada com uma instncia de outra
classe.
Para cada associao, h uma multiplicidade
em cada direo.
A notao usada pela UML, para os indicadores de
multiplicidade, :
Muitos
*
Apenas Um 1
Zero
ou
0..*
Muitos
Um
ou 1..*
114

Muitos
Zero ou Um 0..1
Artigo recebido como
identificao de autoria.

colaborao

sem

Arquitetura de Software
Desenvolvimento orientado para arquitetura
Software, de modo genrico, uma entidade que
se encontra em quase constante estado de
mudana. As mudanas ocorrem por necessidade
de corrigir erros existentes no software ou de
adicionar novos recursos e funcionalidades.
Igualmente, os sistemas computacionais (isto ,
aqueles que tm software como um de seus
elementos)
tambm
sofrem
mudanas
frequentemente. Essa necessidade evolutiva do
sistema de software o torna no confivel e
predisposto a defeitos, atraso na entrega e com
custos acima do estimado. Concomitante com esses
fatos, o crescimento em tamanho e complexidade
dos sistemas de software exige que os profissionais
da rea raciocinem, projetem, codifiquem e se
comuniquem por meio de componentes de
software. Como resultado, qualquer concepo ou
soluo de sistema passa ento para o nvel
arquitetural, onde o foco recai sobre os
componentes e relacionamentos entre eles num
sistema de software.
Arquitetura de software
Quase cinco dcadas atrs software constitua uma
insignificante parte dos sistemas existentes e seu
custo de desenvolvimento e manuteno eram
desprezveis. Para perceber isso, basta olharmos
para a histria da indstria do software (ver seo
Links). Encontramos o uso do software numa ampla
variedade de aplicaes tais como sistemas de
manufatura,
software
cientfico,
software
embarcado, robtica e aplicaes Web, dentre
tantas. Paralelamente, observou-se o surgimento
de vrias tcnicas de modelagem e projeto bem
como de linguagens de programao. Perceba que
o cenrio existente, dcadas atrs, mudou
completamente.
Antigamente, os projetos de sistemas alocavam
pequena parcela ao software. Os componentes de
hardware, por outro lado, eram analisados e
testados quase exaustivamente, o que permitia a
produo rpida de grandes quantidades de

subsistemas e implicava em raros erros de

projetos. Entretanto, a facilidade de modificar o
software, comparativamente ao hardware, tem
servido como motivador para seu uso. Alm disso,
a intensificao do uso do software numa larga
variedade de aplicaes o fez crescer em tamanho e
complexidade. Isto tornou proibitivo analis-lo e
test-lo exaustivamente, alm de impactar no custo
de manuteno.
Um reflexo dessa situao que as tcnicas de
abstrao utilizadas at o final da dcada de 1980
(como decomposio modular, linguagens de
programao de alto nvel e tipos de dados
abstratos) j no so mais suficientes para lidar com
essa necessidade.
Diferentemente do uso de tcnicas que empregam
algoritmos e estruturas de dados e das linguagens
de programao que implementam tais estruturas,
o crescimento dos sistemas de software demanda
notaes para conectar componentes (mdulos) e
descrever mecanismos de interao, alm de
tcnicas para gerenciar configuraes e controlar
verses. A Tabela 1 apresenta o contexto da
arquitetura de software. Na programao
estruturada, feito uso de estruturas de seqncia,
decises e repeties como padres de controle
nos programas. J a ocultao de informaes um
recurso do paradigma orientado a objetos que
permite ao programador, por exemplo, ocultar
dados tornando-os seguros de qualquer alterao
acidental. Alm disso, na programao orientada a
objetos, dados e funes podem ser encapsulados
numa entidade denominada objeto, o que resulta
em mais simplicidade e facilidade na manuteno
de programas. Por outro lado, os estilos
arquiteturais capturam o padro de organizao
dos componentes de software num programa,
caracterizando a forma na qual os componentes
comunicam-se entre si.
Abordagem

Foco

Padres

Programao
estruturada

Sistemas
de
pequeno
porte

Estruturas
controle

de

Abstrao e Sistemas
Encapsulamento
modularizao de mdio e ocultao de
porte
informaes
115

Componentes Sistemas
Estilos
e conectores de grande arquiteturais
porte
Tabela 1. Contexto da arquitetura de software.
Perceba que a categorizao, apresentada
na Tabela 1, teve o objetivo de capturar uma viso
geral de abordagens aplicadas a sistemas de
software. Nada impede, por exemplo, o uso da
programao estruturada em sistemas de grande
porte ou da nfase de um estilo arquitetural num
sistema de pequeno porte. Entretanto, essa prtica
no comum..
Note que medida que tamanho e complexidade
dos sistemas de software aumentam, o problema
de projeto extrapola as estruturas de dados e
algoritmos de computao. Ou seja, projetar a
arquitetura (ou estrutura geral) do sistema emerge
como um problema novo. Questes arquiteturais
englobam organizao e estrutura geral de
controle,
protocolos
de
comunicao,
sincronizao, alocao de funcionalidade a
componentes e seleo de alternativas de projeto.
Por exemplo, nos sistemas Web, uma soluo que
tem sido empregada faz uso de mltiplas camadas
separando componentes cliente, servidores de
aplicaes, servidores Web e outras aplicaes (que
possam ter acesso a esse sistema). Essa
estruturao em camadas objetiva facilitar a
alocao da funcionalidade aos componentes. O
uso de camadas oferece suporte flexibilidade e
portabilidade, o que resulta em facilidade de
manuteno. Outro aspecto a destacar da
arquitetura em camadas o uso de interfaces
padres visando facilitar reuso e manuteno.
Interfaces bem definidas encapsulam componentes
(com funcionalidades definidas) j testados, prtica
que permite o reuso e tambm auxilia na
manuteno, j que toda e qualquer alterao
necessria estaria confinada quele componente.
Importncia da Arquitetura de software
Todos esses fatores compreendem o projeto no
nvel arquitetural e esto diretamente relacionados
com a organizao do sistema e, portanto, afetam
os atributos de qualidade (tambm chamados de
requisitos no funcionais) como desempenho,
portabilidade, confiabilidade, disponibilidade, entre
outros. Se fizermos uma comparao entre
arquitetura de software (caracterizada, por

exemplo, pelo estilo em camadas) e arquitetura

clssica (relativa construo de edificaes),
podemos observar que o projeto arquitetural
determinante para o sucesso do sistema.
A Tabela 2 destaca aspectos da representao de
projeto que captura elementos caractersticos da
arquitetura enquanto que as restries esto
associadas a atributos de qualidade e, portanto,
servem como determinantes nas decises do
projeto arquitetural. Por exemplo, embora o uso de
mltiplas camadas facilite a manuteno de um
sistema de software, tambm contribui para
degradar o desempenho do sistema. Uma ttica
tem sido reduzir o nvel de acoplamento entre
componentes
para
no
comprometer
o
desempenho do sistema. Dessa forma, se
adotarmos uma reduo no nvel de acoplamento
dos componentes, eles tero menor necessidade de
comunicao entre si, o que resulta num melhor
desempenho.
Categorias
Representaes Restries
arquiteturais de projeto
Arquitetura
Clssica

Arquitetura
de Software

Modelos,
Padro
desenhos,
circulao,
planos,
acstica,
elevaes
e iluminao
perspectivas
ventilao
Modelos para
diferentes
papis,
mltiplas vises

de

Desempenho,
confiabilidade,
escalonamento e
manutenibilidade

Tabela 2. Comparao de aspectos arquiteturais.

Hoje em dia, os processos de engenharia de
software requerem o projeto arquitetural de
software. Por qu?

importante poder reconhecer as estruturas

comuns existentes de modo que arquitetos de
software (ou engenheiros de software realizando o
papel de arquiteto de software conforme Tabela
3) possam entender as relaes existentes nos
sistemas em uso e utilizar esse conhecimento no
desenvolvimento de novos sistemas.

O entendimento das arquiteturas permite

aos engenheiros tomarem decises sobre
alternativas de projeto.

Uma especificao arquitetural essencial

para analisar e descrever propriedades de um
116

sistema complexo, permitindo o engenheiro ter

uma viso geral completa do sistema.

O conhecimento de notaes para descrever

arquiteturas permite engenheiros comunicarem
novos projetos e decises arquiteturais tomadas a
outros membros da equipe.
Cabe destacar que, para que haja o entendimento
da arquitetura, faz-se necessrio ao engenheiro de
software conhecer os estilos arquiteturais
existentes, conforme apresentado adiante. As
propriedades de cada arquitetura, portanto, so
dependentes do estilo arquitetural adotado. Por
exemplo, o uso de uma notao padro como a
UML ajuda na representao de componentes e
compartilhamento de informaes do projeto.
Esses aspectos servem como indicadores de uma
maturidade inicial de engenharia de software.
Outros aspectos compreendem uso e reuso de
solues existentes no desenvolvimento de novos
sistemas. Para tanto, a prototipagem tem sido
usada em projetos de natureza inovadora (bem
antes da implementao ou aceitao de um
produto acontecer).
Alm disso, o aumento da complexidade e
quantidade de requisitos dos sistemas dificulta cada
vez mais atender s restries de oramento e
cronograma. Atualmente, empresas tm procurado
incorporar estratgia de reuso de software,
enfatizando o reuso centrado na arquitetura para
obter melhores resultados no desenvolvimento de
sistemas. Note que a arquitetura de software serve
como uma estrutura atravs da qual se tem o
entendimento dos componentes de um sistema e
de seus inter-relacionamentos. Em outras palavras,
ela define a estrutura do sistema, de modo
consistente para implementaes, j que est
diretamente relacionada aos atributos de qualidade
como confiabilidade e desempenho. A organizao
dos componentes num sistema de software
impacta sobre a qualidade apresentada por ele. Por
exemplo, a adoo de uma arquitetura em camadas
serve para modularizar o sistema bem como
facilitar modificaes. Entretanto, um nmero
elevado de camadas (4 ou 5) pode degradar o
desempenho do sistema se houver um elevado grau
de acoplamento entre os componentes.
Diversos benefcios decorrem da incorporao da
arquitetura de software como elemento norteador

do processo de desenvolvimento de software. Cabe

destacar que a arquitetura pode:

Prover suporte ao reuso seus componentes

definidos e testados podem ser reaproveitados em
novas aplicaes.

Servir de base estimao de custos e gerncia

do projeto a existncia de uma arquitetura bem
definida permite ao gerente de projeto
adequadamente alocar tarefas de, por exemplo,
implementao de componentes e melhor estimar
o tempo e tamanho de equipe necessria para
realizao de um projeto.

Servir de base para anlise da consistncia e

dependncia o arquiteto de software pode
verificar se a arquitetura de software adotada
suporta os atributos de qualidade desejados de
modo consistente e avaliar o nvel de dependncia
dos atributos de qualidade em relao
arquitetura. Para tanto, ele faz a anlise
arquitetural que verifica o suporte oferecido pela
arquitetura a um conjunto de atributos de
qualidade (como desempenho, portabilidade e
confiabilidade).

Ser utilizada para determinar atributos de

qualidade do sistema o arquiteto de software faz
a anlise arquitetural a fim de determinar os
atributos de qualidade. Trata-se de um processo
iterativo.

Atuar como uma estrutura para atender os

requisitos do sistema a arquitetura ajuda a definir
os requisitos funcionais, que compreendem o
conjunto de funcionalidades do sistema de
software, e requisitos no funcionais (ou atributos
de qualidade) que determinam as caractersticas
visveis ao usurio como desempenho e
confiabilidade.
Uma questo que voc deve estar se fazendo : Por
que apenas recentemente houve o foco na
arquitetura de software?
A resposta simples: economia e reuso.
Anteriormente no havia forte nfase na disciplina
de engenharia de software, fato este ocorreu com o
amadurecimento desta nova rea ao longo de toda
a dcada de 1990. Tudo motivou o surgimento de
um novo profissional: o arquiteto de software.
Habilidades do Arquiteto de software
Perceba que o arquiteto de software tem um papel
de suma importncia para estratgia adotada pela
empresa. Ele precisa ter profundo conhecimento do
117

domnio, das tecnologias existentes e de processos

de desenvolvimento de software. Uma sntese de
um conjunto desejado de habilidades para um
arquiteto de software e das tarefas atribudas a ele
so apresentados na Tabela 3. Note que a
prototipagem uma tarefa comum onde o
arquiteto desenvolve um prottipo para testar
uma possvel soluo. J a simulao pode ser
empregada quando ele necessita avaliar o suporte
oferecido a determinado atributo de qualidade
como o desempenho. Por outro lado, a
experimentao pode ocorrer quando o arquiteto
precisa testar um novo componente recm
implementado.
Habilidades desejadas

Tarefas atribudas

Conhecimento do domnio Modelagem

e tecnologias relevantes
Conhecimento
de Anlise
de
questes tcnicas para compromisso e de
desenvolvimento
de viabilidade
sistemas
Conhecimento de tcnicas Prototipagem,
de
levantamento
de simulao
requisitos, e de mtodos experimentao
de
modelagem
e
desenvolvimento
de
sistemas
Conhecimento
das Anlise
estratgias de negcios da tendncias
empresa
tecnolgicas

de

Conhecimento
de Evangelizador de
processos, estratgias e novos arquitetos
produtos de empresas
concorrentes
Tabela 3. Habilidades e tarefas de um arquiteto de
software.
Entendo o Estilo Arquitetural
O estilo arquitetural serve para caracterizar a
arquitetura de software de um sistema,
possibilitando a:

Identificao de componentes o arquiteto

identifica quais os principais elementos que tem
funcionalidades bem definidas como, um
componente de cadastro de (informaes de)

usurios e um componente de autenticao de

usurio numa aplicao Web.

Identificao de mecanismos de interao a

comunicao entre objetos por meio da troca de
mensagens constitui uma forma atravs da qual os
componentes de software interagem entre si.

Identificao de propriedades o arquiteto

pode analisar as propriedades oferecidas por cada
estilo baseado na organizao dos componentes e
nos mecanismos de interao, conforme discutido
abaixo.
O estilo arquitetural considera o sistema por
completo, permitindo o engenheiro ou arquiteto de
software determinar como o sistema est
organizado, caracterizando os componentes e suas
interaes. Em outras palavras, ele determina uma
estrutura para todos os componentes do sistema. O
estilo arquitetural compreende o vocabulrio de
componentes e conectores, alm da topologia
empregada. Mas, voc pode estar se questionando:
Por que saber o estilo arquitetural importante?
Os sistemas de grande porte exigem nveis de
abstrao mais elevados (justamente onde se tm
os estilos) que servem de apoio compreenso do
projeto e comunicao entre os participantes do
projeto. Ele determinante no entendimento da
organizao de um sistema de software.
Mas, o que se ganha em saber o estilo arquitetural?
Ele oferece:

Suporte a atributos de qualidade (ou

requisitos no funcionais);

Diferenciao entre arquiteturas;

Menos esforo para entender um projeto;

Reuso de arquitetura e conhecimento em

novos projetos.
Conhecer o estilo arquitetural permite ao
engenheiro antecipar, por meio da anlise
(arquitetural), o impacto que o estilo (isto a classe
de organizao do sistema) ter sobre atributos de
qualidade. Adicionalmente, facilita a comunicao
do projeto, alm do reuso da arquitetura (da
soluo).
A caracterizao e existncia de estilos arquiteturais
constituem sinais de amadurecimento da
engenharia de software, uma vez que permite ao
engenheiro organizar e expressar o conhecimento
de um projeto de modo sistemtico e til. Note que
uma forma de codificar conhecimento dispor de
118

um vocabulrio de um conjunto de conceitos

(terminologia, propriedades, restries), estruturas
(componentes e conectores) e padres de uso
existentes. Conectores so empregados na
interao entre componentes como, tubo (pipe) no
estilo tubos e filtros, e mensagens no estilo de
objetos.
Exemplificando o estilo pipes (tubos) e filtros
O estilo arquitetural de tubos e filtros considera a
existncia de uma rede atravs da qual dados fluem
de uma extremidade outra. O fluxo de dados se
d atravs tubos e os dados sofrem transformaes
quando so processados nos filtros.
O tubo prov uma forma unidirecional do fluxo de
dados uma vez que ele atua como uma espcie de
condutor para o fluxo de dados entre a fonte at
um destino. O exemplo mais comumente conhecido
do estilo tubos e filtros aquele usado no sistema
operacional Unix, isto :
who | sort
A linha de comando acima executa o
comando who (uma nica vez) e encaminha sua
sada ao programa sort, conforme ilustrado
na Figura 1. O resultado da execuo do programa
who uma lista de todos os usurios que se
encontram conectados (a um servidor especfico)
naquele momento, enquanto que o programa sort
ordena essa lista de usurios em ordem alfabtica
(de login).

Figura 2. Arquitetura bsica de um compilador

(seguindo estilo arquitetural de tubos e filtros)
Um compilador tem duas funes bsicas: anlise e
sntese. A funo de anlise implementada por
trs componentes: analisadores lxico, sinttico e
semntico. J a funo de sntese compreende os
componentes de otimizao e gerao de cdigo.
Observe que essa arquitetura oferece suporte
portabilidade e reuso.
Entretanto, essa arquitetura evoluiu com a
introduo
de
um
componente
gerador
intermedirio de cdigo, conforme ilustrado
na Figura 3, a fim de tornar a arquitetura do
compilador mais portvel a vrias plataformas
com o objetivo de reduzir custos no
desenvolvimento de diferentes produtos, ou seja,
compiladores para diferentes plataformas.

Figura 3. Evoluo inicial da arquitetura de um

compilador.
Figura 1. Exemplo do estilo arquitetural de tubos e
filtros
Outro exemplo compreende a arquitetura bsica de
um compilador como ilustrado na Figura 2. Observe
que cada etapa do processo de compilao
realizada separadamente por um componente (ou
seja, um filtro).

Uma nova evoluo da arquitetura de compiladores

a fim de atender a necessidade de integrao (do
compilador) com outras ferramentas, tais como
editor e depurador, resultou na arquitetura
mostrada na Figura 4.

119

Figura 4. Nova evoluo da arquitetura de um

compilador.
importante salientar que a evoluo da
arquitetura de compilador foi resultado,
principalmente, da necessidade de dar suporte ao
requisito de portabilidade. Nesse sentido, pode-se
destacar como vantagens:

Problema ou sistema pode ser decomposto de

forma hierrquica;

Funo do sistema vista como composio

de filtros;

Facilidade de reuso, manuteno e extenso,

que emprega abordagem caixa preta, onde cada
componente tem funcionalidade e interface bem
definida, facilitando alteraes nos mesmos;

Desempenho pode ser incrementado atravs

do processamento paralelo de filtros, j que a
ativao e uso do componente ocorre com o fluxo
de dados, permitindo que componentes com
funcionalidades independentes sejam executados
de forma concorrente.
Apesar das vantagens acima apontadas, o estilo de
tubos e filtros coloca nfase no modo batch,
tornando difcil seu uso em aplicaes interativas e
em situaes que exija ordenao de filtros. Outra
questo tcnica a ser observada a possibilidade
de haver deadlock com o uso de buffers finitos
(para armazenamento temporrio de dados). Esse
estilo arquitetural tem sido empregado em razo
das vantagens anteriormente destacadas.
Exemplos de outros estilos arquiteturais
compreendem:

Camadas a arquitetura do sistema de

software organizada num conjunto de camadas,

oferecendo maior flexibilidade e suporte a

portabilidade. A identificao do nvel de abstrao
nem sempre evidente e perde-se desempenho
medida que o nmero de camadas cresce. Exemplo
desse estilo compreende os sistemas Web de
mltiplas camadas que separa cliente, servidores de
aplicao, servidores Web e outros clientes Web.

Objetos essa arquitetura combina dados

com funes numa nica entidade (objeto),
facilitando a decomposio do problema,
manuteno e reuso. comum utilizar a arquitetura
orientada a objetos em sistemas de informao
como sistemas de consulta e emprstimos online
de bibliotecas de instituies de ensino que
dispem de componentes de cadastro de usurios e
componentes de autenticao de usurios. Note
que componentes similares existem em outros
sistemas de informaes, tais como sites de
contedos (jornais e revistas) que exigem cadastro
e autenticao de qualquer usurio antes de
disponibilizar o contedo.

Invocao implcita diferentemente do estilo

baseado em objetos, no qual um componente
invoca outro diretamente por meio da passagem de
mensagens, a invocao implcita requer que
componentes interessados em receber ou divulgar
eventos se registrem para receber ou enviar. Um
exemplo de sistema empregando mensagens so
listas de notcias e frum que possuem
componentes de registro de novos usurios
acoplados ao componente de autenticao.
Perceba que esse tipo de sistema apenas permite
que o usurio tenha acesso ao contedo se este for
devidamente autenticado e registrado.

(Sistemas orientados a) Eventos trata-se de

um estilo no qual os componentes podem ser
objetos ou processos e a interface define os
eventos de entrada e sada permitidos. Conectores
so implementados atravs do binding eventoprocedimento. Assim, eventos so registrados junto
com eventos e os componentes interagem entre si
atravs do envio de eventos. Dessa forma, quando
um evento recebido, o(s) procedimento(s)
associado(s) a este evento (so) invocado(s). Um
interessante exemplo deste estilo so jogos online,
como discutido na seo seguinte.

Quadro negro (ou Blackboard) esse estilo faz

uso de um repositrio central de dados circundado
por um conjunto de componentes (ou clulas) de
informaes.
Esses
componentes
contm
120

informaes necessrias soluo de problemas.

Os dados da soluo de problemas so mantidos na
base de dados compartilhada (o repositrio), o qual
denominado de quadro negro. O exemple mais
comum desse estilo um sistema especialista.

Combinao de estilos Outros sistemas, na

prtica, combinam estilos arquiteturais resultando
numa heterogeneidade, como ilustrado na Figura
5, que agrega o estilo de objetos e camadas.

selecionar a coluna na qual uma pea ser

depositada).

Figura 6. Jogo Connect4.

Figura 5. Combinao de estilos.

Exemplificando o estilo combinado de objetos e
eventos
Jogos online e de computador tm se tornado
comuns atualmente com a popularidade da
Internet. Costuma-se categorizar os jogos em:

Baseados na vez so jogos nos quais cada

ao baseada na vez do jogador como jogo da
velha e xadrez.

Baseados em eventos so jogos onde

eventos podem ocorrer em qualquer instante e
estes ditam o ritmo do jogo. Exemplos
compreendem simuladores de vo e corridas de
carro.
Por exemplo, quando os jogos so disponibilizados
na Internet, costuma-se denomin-los de jogos
online ou jogos para Internet, possibilitando ao
usurio jogar contra a mquina (computador). Um
exemplo desse tipo de jogo de computador o
Connect4 que tem como meta para cada jogador
conectar quatro peas da mesma cor,
verticalmente, horizontalmente ou diagonalmente.
Cada jogador deve depositar uma pea na parte
superior da coluna selecionada e esta cai at
preencher a lacuna inferior da coluna (selecionada),
conforme ilustrado na Figura 6. Note que o quadro
contm 7 colunas e 6 linhas, um indicador de status
do jogo e um seletor manual (utilizado para

A arquitetura de software dessa aplicao

apresentada na Figura 7. O componente jogador
computacional (que dispe de recursos de
inteligncia artificial para simular um jogador
humano) contm uma classe Connect4State que
trata a maioria das requisies para verificar se
algum jogador venceu o jogo, e tambm dispe de
mecanismo para atualizar o estado do jogo aps
uma jogada do jogador computacional.
O componente (mquina) de inferncia contm
uma classe para tratar as jogadas feitas pelos
jogadores bem como determinar a melhor jogada
para o jogador computacional.

Figura 7. Arquitetura do Connect4

O componente de interface de usurio contm uma
classe que carrega os arquivos de imagem e udio,
trata as requisies feitas atravs do mouse e
invoca um mtodo que checa se houve vitria,
derrota ou empate, alm de fazer a atualizao da
interface grfica. Um possvel estado final desse
jogo mostrado na Figura 8, onde na terceira linha
h um conjunto de quatro peas na cor azul,
indicando que o computador completou primeiro a
121

conexo de quatro peas na mesma cor (a cor do

usurio humano vermelha).

Figura 8. Possvel estado final do jogo Connect4

A combinao estilo arquitetural orientado para
eventos e objetos permite a decomposio de um
sistema em termos de objetos (componentes de
inferncia, componente de interface grfica e
componente jogador computacional) que so mais
independentes alm de possibilitar que atividades
de computao e coordenao (de eventos) sejam
realizadas separadamente. H ainda a facilidade de
reuso e manuteno, j que novos objetos podem
ser facilmente adicionados. Essa caracterstica, e
interfaces bem definidas, facilitam ainda a
integrao.
O mecanismo de invocao no determinstico
(isto , ocorre de forma aleatria) uma vez que
considera a recepo de eventos. Adicionalmente,
os componentes tm seus dados preservados de
qualquer modificao acidental j que essas
informaes so encapsuladas em objetos,
facilitando tambm a integrao.
Importncia do Reuso
importante perceber de tudo o que foi
apresentado e discutido que um modelo
arquitetural oferece suporte ao reuso de vrias
formas. Por exemplo, pode se ter arquiteturas
reusveis que forneam a organizao e o modelo
de coordenao, permitindo seu uso em diversos
sistemas. Alm disso, podem-se reutilizar
componentes, j testados, em mais de um sistema.
Disso tudo, o mais importante o reuso do
conhecimento que tem impacto direto na definio

da arquitetura de software candidata soluo de

um problema (ou sistema).
A ampla variedade de plataformas e utilitrios,
juntamente com a presso do mercado para reduzir
o tempo de entrega de produtos de software e
elevar a produtividade, faz com que o reuso seja
apontado como uma das chaves de sucesso para
empresas.
O reuso de artefatos (ou componentes) possvel
quando o projeto arquitetural est incorporado e
orienta o processo de desenvolvimento de
software. Isto, como discutido, permite antever os
atributos de qualidade que o sistema suporta e
tambm administrar o cronograma de execuo do
projeto. Portanto, impactando positivamente o
reuso e economia do sistema.
O quadro apresentado na Tabela 4 sumariza as
principais caractersticas da arquitetura de software
e pontos importantes na capacitao e reciclagem
de engenheiros e arquitetos de software.
Caractersticas
Uso prtico da arquitetura de
de arquitetura software
de software
Constitui
artefato
reutilizvel

um Como um arquiteto de software

pode organizar o projeto e
cdigo de um sistema

Dispe
de Como um arquiteto avalia e
mecanismos de implanta
arquiteturas
de
interconexo
software em sistemas
Oferece
um Como um arquiteto de software
vocabulrio de atua
no
processo
de
projeto e separa desenvolvimento de software
funcionalidades
Vincula o projeto Como um arquiteto avalia a
a atributos de qualidade do cdigo baseada em
qualidade
mtricas de produto
Suporta
o
desenvolvimento
baseado
em
componentes e
linha de produto
(quando
os
requisitos
so
considerados
para uma famlia
de sistemas)

Como usar arquitetura como

parmetro para reduzir custos de
manuteno e amortizar custos
de desenvolvimento

122

Tabela 4. Caractersticas e uso prtico da

arquitetura de software
Concluso
Embora arquitetura de software seja um tema
relevante no contexto atual para desenvolvimento
de sistemas de software que tm seu foco no reuso
e, portanto, consideram tanto o aspecto econmico
quanto a produtividade, sua incorporao nos
processos de desenvolvimento de software tem
sido observada apenas em empresas de grande
porte e em poucas de mdio porte. Entretanto,
esse cenrio comea a mudar dada a crescente
necessidade de integrao de sistemas a qual tem a
arquitetura de software como premissa. Assim, o
fator econmico tem sido e ser o determinante da
sobrevivncia da empresas de software. Novas
estratgias de desenvolvimento de sistemas devem
ser para o reuso e com reuso (de componentes de
software) e o pilar principal dessas estratgias a
arquitetura de software. H, portanto, uma
necessidade premente de formao de capital
humano com tais qualificaes
mtricas de qualidade de software; tcnicas de
anlise e modelagem de dados;

Neste artigo iremos falar sobre Qualidade de

Software e mtricas da Qualidade Software.
Existem muitas definies do termo Qualidade de
Software. Peters (2002) diz que Qualidade de
Software avaliada em termos de atributos de alto
nvel chamados fatores, que so medidos em
relao a atributos de baixo nvel.
J Sanders (1994) alega que o produto de software
apresenta qualidade dependendo do grau de
satisfao das necessidades dos clientes sob todos
os aspectos do produto.
A Norma ISO9126 define Qualidade como a
totalidade de caractersticas de uma entidade que

lhe confere a capacidade de satisfazer as

necessidades explicitas e implcitas.
Outro autor, Pressman, diz que:

Qualidade de Software a conformidade a

requisitos funcionais e de desempenho que foram

explicitamente declarados, a padres de
desenvolvimento claramente documentados, e a
caractersticas implcitas que so esperadas de todo
software desenvolvido por profissionais

Para saber se a Qualidade est sendo alcanada

devemos nos perguntar se chegamos ao resultado
desejado, se os clientes esto satisfeitos com os
produtos e servios prestados e se alcanamos o
objetivo do negcio.
Para que o nvel de Qualidade seja mantido, o ciclo
de Deming deve sempre estar em movimento, ou
seja, sempre devemos Planejar, Fazer, Verificar e
Agir em relao aos processos de gerenciamento de
projetos.

Fig.01Ciclo
PDCA
(http://gestaoeevolucao.blogspot.com.br)
Durante a execuo do ciclo de Deming, devemos
realizar a medio (etapa Verificao/Checagem)
para manter o nvel de Qualidade. Medir indicar
quantitativamente a extenso, quantidade,
dimenso, capacidade ou tamanho de um produto
ou processo.
Se desejar saber o esforo realizado em cada fase
do projeto, se deseja saber o desvio do projeto em
relao estimativa realizada, se deseja conhecer o
tamanho e a variao de custo do sistema, se
necessita de uma informao objetiva para tomada
de decises que tenham algum impacto no negcio
e no desempenho, devemos medir a qualidade.
Abaixo, temos alguns processos de software que
sero medidos quanto a sua Qualidade:
Gesto de Projetos: Estimativas e planejamento de
projetos, o controle de projetos e gesto de
recursos.
Gesto da Organizao: Melhoria de processos e
procedimentos organizacionais.
Gesto de Negcio: Ampliao de servios, gesto
financeira e de investimentos, gesto de recursos e
competitividade
MTRICAS DE QUALIDADE DE SOFTWARE
Mtrica uma medida quantitativa do grau que um
sistema, componente ou processo possui de um
123

dado atributo. Por exemplo, nos primeiros dezoito

meses de atividade foram encontrados somente
dois erros identificados por utilizadores.
As mtricas so um bom meio para entender,
monitorar, controlar, prever e testar o
desenvolvimento de software e os projetos de
manuteno.
Em um processo de desenvolvimento de software
temos vrios processos, como: gesto de requisitos,
gesto de riscos, testes, gesto da qualidade.
No processo de Gesto de Requisitos, podemos
coletar mtricas como:
Requisitos includos: indica a proporo de
requisitos de um projeto que so adicionados aos
requisitos estabelecidos inicialmente.
Requisitos cancelados: indica a proporo de
requisitos de um projeto que so anulados.
Requisitos aprovados: indica a proporo de
requisitos de um projeto que so aprovados pelo
cliente antes de finalizar o desenho.
Requisitos alterados: indica a proporo de
requisitos de um projeto que se modificam
Estabilidade de requisitos: mostra um valor de
estabilidade dos requisitos no momento da
medio, a partir do clculo de fatores que
influenciam na instabilidade.
No processo de Gesto de Riscos, podemos coletar
mtricas como o Nvel de Riscos, que uma mtrica
que indica o nvel de risco que assume o projeto. Na
gesto de riscos podemos determinar o nvel de
risco para cada fase do projeto e tambm
para obter uma classificao global do nvel de
risco do projeto.
No processo de Testes, podemos coletar mtricas
como:

projeto. Um valor baixo na Gesto de Incidncias

supe um nvel alto de incidncias no resolvidas e,
por tanto erros no software.
No processo de Gesto de Configurao, podemos
coletar mtricas como:
Evoluo do Software: indica a evoluo do
software para cada fase do projeto, baseado no
volume de modificaes que se produzem no
software. Esta mtrica indica como se evolui o
software gerado comparado com as fases do
projeto.
No processo de Gesto da Qualidade, podemos
coletar mtricas como:
Estabilidade do Software: indica o nmero de erros
detectados. Determina a qualidade dos sistemas
em produo, baseado no nmero de erros
detectados no perodo.
Gesto de No Conformidades: indica o nmero de
no conformidades gerenciadas, no gerenciadas,
moderadas, graves e leves.
Mas, como calcular uma mtrica?
Em um determinado projeto o Gerente de Projetos
gostaria de medir a satisfao do cliente. Durante
as quatro entregas realizadas, um tcnico averiguou
com o cliente os problemas encontrados e
identificou os casos de uso afetados, conforme
tabela abaixo.

Tabela de Defeitos Por Entrega

Para garantir a qualidade do software foi definida
uma mtrica para identificar o percentual de casos
de uso com defeito identificado pelo cliente.
% de CDU com defeitos = CDUcDefeito /
CDUImplementado * 100

Volume de erros por etapa: A estabilidade mostra

um nvel de confiana do software testado que
serve como critrio para a validao de um mdulo,
processo ou sistema. Conforme as correes dos
erros, a taxa de defeitos por caso de teste vai
diminuindo. Uma estabilidade elevada supe um
alto nvel de qualidade do software.
Gesto de Incidncias: Mostra o grau de resoluo
das incidncias detectadas por parte da equipe de

Onde:
% de CDU com defeitos: mtrica que representa o
percentual de erros encontrados pelo cliente.
CDUcDefeito: medida que representa o nmero de
caso de uso com defeitos.
CDUImplementado: medida que representa a
quantidade de casos de uso implementados pelos
desenvolvedores.

124

Benefcios da Medio para o Gerenciamento de

Projetos
Reduo das atividades que no agregam valor ao
produto e que est sendo desenvolvido.
Melhoria na gesto de recursos.
Aumento na eficincia dos servios prestados.
Conhecimento da produtividade do projeto.
Verificar se os recursos so adequados ao projeto.
Avaliar o rendimento da codificao e avaliar se um
produto est conforme aos critrios acordados com
o cliente.
Benefcios da Medio para uma organizao e
negcio
Identificar oportunidades de melhoria.
Fomentar a viso da empresa.
Aumentar o retorno de investimento.
Melhorar a satisfao do cliente.
Melhorar a posio da empresa no mercado.
Melhorar a visibilidade sobre a situao dos
projetos, baseada em dados objetivo.
Os processos que poderiam ajudar
Modelagem de Dados1 - O q u e a n a l i s e d e
dados?
um conjunto de tcnicas com o objetivo de
identificar, conceituar e estruturar os dados de uma
empresa, de uma parte da empresa ou de um
sistema. A anlise de dados nos ajuda a
- Obter um melhor conhecimento do problemaProjetar adequadamente a base de dados
- Organizar o compartilhamento dos dados e a
integrao dos sistemas
- Unificar a viso que a empresa tem dos dados
2-Tcnicas de modelagem de dados

- Normalizao dos dados: uma tcnica formal,

rigorosa e simples, de fcil aplicao, que visa a
simplificao dos arquivos (base de dados), mas no
ajuda muitos na investigao do problema.Modelagem entidade-relacionamento: uma tcnica
menos formal, mas extremamente til para
investigar as necessidades dos usurios em relao
aos dados.
3- Normalizao de Dados (Tcnica de modelagem
de dados)
- Atributo: so dados armazenados em uma tabela.
Pode ser opcional(preenchido o no), multivalorado
(pode conter mais de um valor, ex. telefone).Chave: um atributo ou um conjunto de atributos
que identifica, de forma nica, cada registro da
tabela. Toda tabela deve possuir uma chave. A
funo da chave garantir a unicidade dos
registros. A chave de uma tabela deve ser: nica,
universal e imutvel. Chave Universal: a chave
escolhida para uma tabela s adequada se todos
os registros da tabela tiverem um valor para chave.
Por exemplo, no adianta colocar CNPJ como chave
no cadastro de cliente se nem todos os clientes so
pessoa jurdica. Chave Imutvel: A outra
caracterstica de uma boa chave que ela seja
imutvel. Isto significa que se um valor atribudo
h um registro este valor no ser mais alterado.Dependncia funcional: quando um atributo tem
seu valor determinado pelo valor de outro atributo.
Exemplo: O salrio de um funcionrio depende da
matricula do mesmo. Pois para determinar o salrio
de um funcionrio precisamos saber de que
funcionrio se trata, ou seja, precisamos saber qual
a matricula deste funcionrio.
MODELAGEM DE DADOS TEORIA E PRTICA
ARAJO, M. A. P.
1. INTRODUO
Modelagem de sistemas, tanto a nvel funcional
quanto de dados, um requisito fundamental para
a obteno de produtos de software de maior
qualidade e confiabilidade. Entretanto, percebe-se
que cada vez menos profissionais tm dado a
ateno devida ao processo de construo de
modelos de suas aplicaes. Isso provavelmente se
deve s presses por sistemas em prazos cada vez
mais curtos e com menores custos de produo
mas, por outro lado, acaba por prejudicar e
muito o entendimento correto do problema e,
consequentemente, a construo do sistema que
125

atenda s reais expectativas do usurio. Esta

situao muitas vezes leva a sistemas de baixa
qualidade,
com
elevada
necessidade
de
modificao e de difcil manuteno.
Neste sentido, este trabalho apresenta as principais
tcnicas de modelagem de dados, no tendo por
objetivo tratar de modelagem funcional. Assim, no
que diz respeito modelagem de dados, ser
discutido tanto o modelo conceitual atravs do
MER (Modelo Entidade-Relacionamento), quanto o
modelo lgico atravs do MR (Modelo Relacional).
A abordagem apresentada neste artigo une a teoria
destes modelos de dados com um estudo de caso
prtico, discutindo diferentes alternativas de
soluo a partir de uma srie de problemas
propostos. Assim, sero exercitadas tcnicas
bsicas e avanadas de modelagem de dados, com
suas possveis solues comentadas.
Desta forma, espera-se que conhecimentos teis
prtica profissional de modelagem e manipulao
de bancos de dados relacionais tenham sido
apresentados e discutidos. Para isso, ser
considerado um fragmento de um sistema de
controle de biblioteca, onde importante
considerar que o objetivo aqui
exercitar o mximo possvel de tcnicas de
modelagem de dados, bem como discutir suas
possibilidades de soluo.
2. FUNDAMENTOS DE MODELAGEM DE DADOS
O Modelo Entidade-Relacionamento um modelo
de alto nvel, independente do SGBD (Sistemas
Gerenciadores de Bancos de Dados), que
representa o problema a ser modelado. A notao
que ser utilizada para a representao deste
modelo o DER (Diagrama EntidadeRelacionamento), exemplificado na Figura 1, onde
os retngulos representam as entidades (elementos
do domnio do problema) e os losangos
representam os relacionamentos entre estas
entidades (HEUSER, 2004). Entidades ainda so
descritas atravs de atributos e devem possuir uma
chave primria (ou Primary Key - atributo ou
conjunto de atributos que identificam unicamente
uma instncia em uma entidade, e que no podem
receber um valor nulo).
A Figura 1 representa que uma instncia da
Entidade A est associada a zero (opcional) ou mais
instncias da Entidade B. Por outro lado, uma
instncia da Entidade B est associada a uma

(obrigatoriedade), e somente uma, instncia da

Entidade A. A este par de elementos chama-se
cardinalidade, onde o primeiro elemento indica a
participao (opcional ou obrigatrio) do
relacionamento, enquanto o segundo representa o
grau do relacionamento (um ou muitos).
Naturalmente, existem outros elementos utilizados
na construo deste diagrama, como agregao,
relacionamento ternrio (ou de maior grau), autorelacionamento e generalizao/especializao, que
sero apresentados posteriormente.
Relacionamentos ainda podem ter atributos,
quando algum dado precisa ser associado ligao
das duas instncias envolvidas. Relacionamentos
so descritos atravs da cardinalidade, que indica
como as instncias das entidades se
relacionam. Os tipos utilizados na modelagem so
(KORTH, SILBERCHATZ e SUDARSHAN, 2006):
Um-para-um (1:1): uma instncia em A est
associada com no mximo uma instncia em B, e
uma instncia em B est associada com no
mximo uma instncia em A;
Um-para-muitos (1:n): uma instncia em A est
associada a qualquer nmero de instncias em B,
e uma instncia em B, todavia, pode estar
associado a no mximo uma instncia em A;
Muitos-para-muitos (n:n): uma instncia em A
est associada a qualquer nmero de instncias em
B e vice-versa. Alguns autores preferem chamar
esta cardinalidade de m:n, por considerar que
podem representar valores diferentes.
O modelo conceitual representa os elementos do
domnio do problema e, consequentemente, no
considera questes tecnolgicas. Assim, alguns dos
elementos descritos neste modelo no possuem
correspondncia com os recursos oferecidos pelos
bancos de dados relacionais, tornando necessrio
transformar o Modelo Entidade-Relacionamento
em uma notao que possa ser implementada
neste tipo de banco de dados. O DTR (Diagrama de
Tabelas Relacionais) uma representao grfica
deste modelo, cuja notao est exemplificada na
Figura 2, retratando a mesma situao descrita na
Figura 1. Esta notao tambm comumente
conhecida como P de Galinha, devido
simbologia utilizada (COUGO, 1997). Este diagrama
interessante, pois apresenta elementos com
correspondncia direta queles implementados nos
bancos de dados relacionais, facilitando a transio
do modelo conceitual para o lgico. Alm disso,
126

muitas ferramentas CASE atuais implementam

apenas este diagrama. Assim, no decorrer deste
artigo, quando necessrio, tambm ser
apresentado este diagrama de maneira a facilitar o
entendimento desta transio.
Neste sentido, existem algumas regras de
converso do Modelo Entidade- Relacionamento
para o Diagrama de Tabelas Relacionais, sendo as
principais (ELMASRI e NAVATHE, 2005):
Toda entidade vira uma tabela;
Relacionamentos que possuem atributos viram
tabelas (existe a possibilidade em relacionamentos
1:n dos atributos irem para uma das tabelas, ao
invs de se criar uma nova. Entretanto,
relacionamentos com atributos so mais comuns
em relacionamentos n:n, gerando assim uma nova
tabela);
Relacionamentos so representados por chaves
estrangeiras (ou Foreign Key atributo
correspondente chave primria de outra relao,
base para a integridade referencial);
Relacionamentos 1:1 podem ser mapeados numa
nica tabela (quando possuem a mesma chave
primria), em duas tabelas (quando as chaves
primrias so diferentes e um dos lados do
relacionamento obrigatrio) ou em trs tabelas
(quando o relacionamento opcional em ambos os
lados);
Relacionamentos 1:n so mapeados de forma que
a chave primria do lado 1 seja representada do
lado n como chave estrangeira;
Relacionamentos n:n devem ser transformados
em dois relacionamentos 1:n, resultando numa
nova tabela;
Relacionamentos ternrios (ou de maior grau)
geram novas tabelas;
Agregaes normalmente geram novas tabelas;
Auto-relacionamentos geram novas tabelas se
forem relacionamentos do tipo n:n;
Generalizao/Especializao
podem
ser
mapeadas em uma nica tabela, em uma tabela
para cada especializao ou uma tabela para cada
entidade envolvida, dependendo da situao.
Assim, a partir do modelo conceitual construdo o
modelo lgico que, diferentemente do primeiro,
dependente das caractersticas do SGBD escolhido.
A ferramenta para este fim o MR (Modelo
Relacional), que representa a soluo do

problema modelado, considerando as estruturas

(relaes) que sero transformadas em tabelas
quando da criao do banco de dados
propriamente dito.
Existem
tambm
algumas
diferenas na
nomenclatura. Por exemplo, entidades no
Modelo Entidade-Relacionamento so chamadas de
relaes no Modelo Relacional, e instncias so
chamadas de tuplas (as linhas de uma relao).
Quando da construo do banco de dados
propriamente dito, as relaes so chamadas de
tabelas, as tuplas de registros, e os
atributos de campos ou colunas.
Neste contexto, uma questo importante a ser
discutida na construo do Modelo Relacional a
normalizao, que um conjunto de regras que
leva construo de modelos mais robustos, com
menos dependncias entre seus elementos e
menos redundncia de informaes. Normalizao
uma atividade de verificao do modelo lgico e
suas Formas Normais mais comuns, apesar de
existirem outras, so (DATE, 2004):
1 Forma Normal (1FN): toda relao deve ter
uma chave primria e deve-se garantir que todo
atributo seja atmico. Atributos compostos devem
ser separados. Por exemplo, um atributo Endereo
deve ser subdividido em seus componentes:
Logradouro, Nmero, Complemento, Bairro,
Cidade, Estado e CEP. Alm disso, atributos
multivalorados
devem
ser
discriminados
separadamente ou separados em uma outra
relao. Por exemplo, um atributo multivalorado
Telefones poderia ser separado em Telefone
Residencial, Telefone
Comercial e Telefone Celular ou, ainda, ser
convertido em outra relao que pudesse
representar um nmero indeterminado de
telefones.
2 Forma Normal (2FN): toda relao deve estar
na 1FN e devem-se eliminar dependncias
funcionais parciais, ou seja, todo atributo no chave
deve ser totalmente dependente da chave primria.
Como exemplo, uma relao que contenha os
atributos Cdigo da Obra, Cdigo do Fornecedor,
Nome do Fornecedor e Preo de Venda,
considerando que a chave primria composta
pelos atributos Cdigo da Obra e Cdigo do
Fornecedor, no est na Segunda Forma Normal,
uma vez que o Nome do Fornecedor depende
apenas do Cdigo do
127

Fornecedor, e no do Cdigo da Obra. Uma nova

relao (Fornecedor) deve ser criada contendo os
campos Cdigo do Fornecedor (como chave) e
Nome do Fornecedor. Na relao original, ficariam
os atributos Cdigo da Obra e o Cdigo do
Fornecedor, ambos formando a chave primria
composta, e o atributo Preo de Venda. Alm disso,
o atributo Cdigo do Fornecedor tambm seria uma
chave estrangeira para a nova relao criada. Esta
forma normal ajuda a diminuir redundncias de
informaes criadas indevidamente.
3 Forma Normal (3FN): toda relao deve estar
na 2FN e devem-se eliminar dependncias
funcionais transitivas, ou seja, todo atributo no
chave deve ser mutuamente independente. Como
exemplo, uma relao que contenha os atributos
Matrcula do Funcionrio (atributo chave), Nome do
Funcionrio, Cdigo do Departamento e Nome do
Departamento no est na Terceira Forma Normal.
O Nome do
Departamento dependente do Cdigo do
Departamento, e no da Matrcula do Funcionrio.
Uma mudana no nome do departamento, por
exemplo, levaria a modificaes em todos os
funcionrios daquele departamento. Para eliminar
este problema, cria-se uma nova relao
(Departamento) contendo Cdigo do Departamento
e Nome do Departamento. Na relao original,
retira-se o Nome de Departamento, mantendo-se o
Cdigo do Departamento, agora como chave
estrangeira. Esta forma normal tambm ajuda a
diminuir redundncias
e aumentar a independncia das relaes.
3. UTILIZAO DE RELACIONAMENTOS 1:1 E 1:N
No sentido de exemplificar estes conceitos, ser
apresentado um fragmento de um sistema de
controle de biblioteca. Como requisitos iniciais
foram identificados:
1. Devem ser cadastradas as obras do acervo, que
representam livros, peridicos (revistas, jornais) e
qualquer outro elemento do acervo da biblioteca.
Inicialmente, obras devem possuir um cdigo que
as identifique: ttulo, autor principal, ano de
publicao, situao (disponvel, emprestada) e
editora. Editoras, por sua vez, possuem um cdigo,
nome e cidade. Uma obra sempre de uma editora
e uma editora pode possuir diversas obras;

2. Devem ser cadastrados usurios da biblioteca,

que devem ter uma identificao nica, nome,
endereo completo, telefone de contato e CPF;
3. Os funcionrios da biblioteca tambm devem ser
cadastrados.
Funcionrios tm um nmero de matrcula, seu
nome completo e departamento em que trabalha.
Departamentos, por sua vez, possuem cdigo e
nome. Todo funcionrio obrigatoriamente
vinculado a um departamento, que pode ter vrios
funcionrios. Alm disso, todo departamento
possui um nico chefe;
4. Usurios devem poder realizar emprstimo de
obras. Um emprstimo deve conter uma nica obra
e ser de um nico usurio, obrigatoriamente.
Emprstimos ainda devem registrar a data e horrio
do emprstimo, data prevista de retorno, bem
como o funcionrio que o realizou. Quando da
devoluo da obra em emprstimo, deve-se
registrar a data e horrio da devoluo, bem como
o funcionrio responsvel;
5. Usurios ainda podem realizar reservas de obras.
Uma reserva deve conter uma nica obra e ser de
um nico usurio, obrigatoriamente.
Reservas ainda devem registrar a data e horrio da
reserva e data na qual a obra ser retirada.
Alguns comentrios so importantes de serem
considerados quando da modelagem de dados.
Primeiro, deve-se atentar para o fato de que
redundncia de dados no desejvel. Numa
primeira anlise, e pela simplicidade inicial do
problema, se poderia imaginar a construo de uma
nica entidade contendo todas as informaes do
funcionrio, por exemplo, incluindo os dados de seu
departamento. Entretanto, a cada funcionrio
alocado a um mesmo departamento, acarretaria
que os dados do departamento seriam duplicados
no novo funcionrio. Se, por exemplo, o
departamento mudasse de nome, teria que mudar
esta informao nos diversos funcionrios lotados
nele o que, alm de redundante, pode causar
inconsistncias.
Outra considerao importante a respeito do
endereo do usurio. No modelo conceitual podese representar apenas o atributo Endereo, pois o
problema que est sendo modelado. Entretanto, no
modelo lgico, representam-se as estruturas
internas das relaes (atributos, restries, chaves,
relacionamentos).
128

Neste caso, deve-se lembrar que a Primeira Forma

Normal (1FN) determina que todo atributo deve ser
atmico. Desta forma, deve-se separar o endereo
em seus diversos atributos. Isso importante, pois
se for necessrio saber quais so os usurios que
vivem numa determinada cidade, este atributo
deve estar separado.
Caso contrrio, torna-se difcil distinguir, por
exemplo, um usurio que mora na cidade do Rio de
Janeiro de outro que mora na Rua Rio de Janeiro na
cidade de Belo Horizonte.
Alm disso, quando construir um relacionamento
entre duas entidades, deve-se tomar cuidado com
as obrigatoriedades dos dois lados do
relacionamento. Por exemplo, se for modelado que
um funcionrio deve pertencer a um departamento
e,
ao mesmo tempo, um departamento deve ter ao
menos um funcionrio, no se est considerando a
situao inicial, com o banco de dados vazio, onde
primeiro se cadastram os departamentos sem
funcionrios e, no momento do cadastramento do
funcionrio, este alocado ao departamento.
Tambm importante notar que nem todas as
entidades esto explicitamente descritas no
enunciado do problema.
Por fim, no se deve preocupar com outras
necessidades de modelagem, devendo-se focar no
problema apresentado.
A Figura 3 apresenta o Diagrama EntidadeRelacionamento contendo uma possvel soluo
para o problema apresentado. Optou-se por no
representar os atributos neste diagrama, para no
dificultar a legibilidade. Os atributos sero
apresentados posteriormente na estrutura das
entidades.
Figura 3. DER do problema apresentado
Vale lembrar que, apesar de uma prtica comum,
no obrigatrio nomear os relacionamentos,
exceto quando estes iro originar tabelas, o que o
caso de relacionamentos n:n ou relacionamentos
que possuem atributos. Nestes casos, o nome dos
relacionamentos normalmente so os nomes das
tabelas resultantes.
Entretanto, nomear relacionamentos importante
para uma melhor compreenso do modelo e este
recurso ser utilizado quando for necessrio. Neste
exemplo, foram nomeados os relacionamentos

entre as entidades Funcionrio e Departamento,

uma vez que seu entendimento fica dificultado se
os relacionamentos no forem nomeados, por
existirem dois relacionamentos entre as mesmas
entidades.
A seguir, descrita a estrutura inicial das entidades,
onde o atributo determinante est sublinhado.
Observe que, propositadamente, foram deixados os
atributos da editora dentro da entidade Obra:
Obra (cod_obra, titulo, autor_principal,
ano_publicacao,
situacao_obra,
tipo_obra,
cod_editora, nome_editora, cidade)
Usuario (cod_usuario, nome_usuario, endereco,
telefone, CPF)
Emprestimo (cod_emprestimo, cod_obra,
cod_usuario,
data_emprestimo,
horario_emprestimo,
data_prevista_retorno,
num_matricula_funcionario)
Devolucao (cod_emprestimo, data_devolucao,
horario_devolucao,
num_matricula_funcionario)
Funcionario (num_matricula, nome_funcionario,
cod_departamento)
Departamento
(cod_departamento,
nome_departamento,
num_matricula_chefe)
Reserva (cod_reserva, cod_usuario, cod_obra,
data_reserva,
horario_reserva, data_retirada)
Para a construo deste diagrama, algumas
decises de projeto foram tomadas e valem a pena
serem discutidas:
Na entidade Emprestimo, uma possibilidade para
a definio do atributo determinante seria a
concatenao dos atributos cod_usuario e
cod_obra, caracterizando uma chave composta.
Entretanto, esta chave impediria que o mesmo
usurio realizasse o emprstimo da mesma obra em
datas diferentes. Uma possibilidade seria incluir
tambm o atributo data_emprestimo na chave.
Neste caso, preferiu-se incluir um atributo
cod_emprestimo como atributo determinante. Este
tipo de situao chamada de chave cega, onde um
novo atributo inserido por dificuldades na
determinao da chave da entidade. O mesmo
raciocnio foi utilizado para determinar a chave da
entidade Reserva;
129

O relacionamento 1:1 entre as entidades

Emprestimo e Devolucao no necessariamente
precisaria existir. Relacionamentos com esta
cardinalidade muitas vezes podem ser eliminados e
os atributos das duas entidades podem ser
unificados, principalmente neste caso onde os
atributos determinantes so os mesmos (a entidade
Devolucao poderia ter um atributo determinante
diferente, como cod_devolucao
mas, neste caso, seria necessrio definir um outro
atributo que fizesse a ligao com a entidade
Emprestimo). Assim, uma possibilidade seria
transferir para a entidade Emprestimo todos os
atributos da entidade Devolucao e eliminar esta
entidade. Com isso, o emprstimo tambm teria os
dados de sua devoluo, sendo necessrio ter um
outro relacionamento com a entidade Funcionario,
para representar o funcionrio responsvel pela
devoluo. Neste exemplo, preferiu-se manter as
entidades separadas, uma vez que so eventos que
representam situaes diferentes e acontecem em
momentos distintos e, no caso da devoluo, pode
nem acontecer;
Os dois relacionamentos entre as entidades
Funcionario e Departamento so importantes, uma
vez que representam ligaes diferentes entre as
entidades, um representando lotao e outro
chefia. Neste caso, o relacionamento 1:1 no
poderia ser eliminado, uma vez que existe um
segundo relacionamento entre as mesmas
entidades;
Optou-se por no fazer um relacionamento entre
as entidades Emprestimo e Reserva, representando
que um emprstimo possa ter sido efetivado em
funo de uma reserva. Esta deciso foi tomada
uma vez que no existe a necessidade de estar
armazenando definitivamente as reservas, podendo
as mesmas ser eliminadas aps a data da reserva
ter sido vencida;
Deve-se observar ainda um problema na entidade
Obra. Caso existam vrios exemplares da mesma
obra, tem-se que cadastrar a obra vrias vezes, uma
para cada exemplar. Este problema ser resolvido
posteriormente.
O prximo passo analisar se as entidades
representadas esto normalizadas, podendo
transformar-se em relaes. Segue esta anlise das
Formas Normais:
1 FN: esta Forma Normal no foi satisfeita, uma
vez que o atributo Endereco da entidade Usuario

no atmico. Para satisfazer esta FN, este atributo

deve ser desmembrado em Logradouro, Numero,
Complemento, Bairro, Cidade, UF,
CEP;
2 FN: o modelo encontra-se na Segunda Forma
Normal, que determina que todo atributo no
chave deve ser totalmente funcionalmente
dependente da chave primria, e no de parte dela.
S faz sentido preocupar-se com esta Forma
Normal para aquelas relaes que possuem chave
primria composta.
No estudo de caso em questo, como todas as
relaes possuem chaves primrias simples,
contendo de apenas um atributo, no necessrio
preocupar-se com esta Forma Normal no momento;
3 FN: pode-se observar um problema com esta
Forma Normal ao analisar a relao Obra. Neste
caso, os atributos nome da editora e cidade da
editora dependem funcionalmente apenas do
atributo cdigo da editora, que um atributo no
chave. Lembrando, a 3 FN indica que todos os
atributos no chave devem ser mutuamente
independentes. Assim, apesar dos dados da editora
poderem ser considerados como atributos da obra,
torna-se importante separar estas entidades,
primeiro para no ter estes atributos redundantes.
Segundo, a digitao diferente do nome de uma
editora, por exemplo, faz com que consultas
indiquem editoras diferentes, o que no
desejvel. Outra situao indesejvel acontece se
uma editora mudar de cidade, ocasionando uma
mudana no valor deste atributo em todas as obras
desta editora.
4. UTILIZAO DE RELACIONAMENTOS N:N
Considerando o modelo anterior, esta seo ir
propor uma manuteno no modelo de dados
construdo, de forma a exercitar a utilizao de
relacionamentos n:n.
Neste sentido, ser necessrio efetuar uma
primeira manuteno no modelo de dados. Existem
dois novos requisitos solicitados pela biblioteca:
1. Ser necessrio armazenar os autores de uma
obra. Alm disso, importante saber a ordem dos
autores de uma obra, ou seja, quem o primeiro
autor, segundo autor, e assim sucessivamente.
Como comum fazer pesquisas pelo nome de
autores, a biblioteca no deseja que o mesmo autor
se repita no banco de dados, de forma que seu
130

nome possa ser digitado de maneiras diferentes e

dificultar a busca.
Assim, deseja-se fazer um cadastro de autores e
relacion-los s obras. Cada autor deve conter
apenas um cdigo que o identifique e seu nome
completo. Deve-se lembrar que uma obra tem
diversos autores (seguindo sua ordem) e um autor
pode participar em diversas obras. importante
atentar que existe um campo para este fim
(autor_principal) na tabela Obra.
2. Outra necessidade comum numa biblioteca a
consulta de obras por assunto. Uma obra pode
estar associada a diversos assuntos e um assunto
pode estar vinculado a diversas obras. Novamente,
deve-se fazer um cadastro de assuntos (contendo
apenas cdigo e descrio), de forma que possam
ser associados s obras.
Para estes novos requisitos, primeiro deve-se
pensar na soluo atravs do modelo conceitual,
para depois trabalhar no modelo lgico. Na
transformao do modelo conceitual para o lgico,
lembre-se que relacionamentos n:n devem originar
novas tabelas.
Inicialmente, ser discutido primeiro o problema de
associao de assuntos s obras. Para isso, deve-se
acrescentar ao modelo conceitual uma entidade
Assunto, contendo apenas cdigo e descrio.
Como uma obra pode possuir diversos assuntos e
um assunto pode estar vinculado a diversas obras,
deve-se
modificar
o
modelo
conceitual
acrescentando um relacionamento n:n entre estas
entidades. A Figura 5 representa o fragmento do
modelo conceitual para este problema.
Para transformar este modelo conceitual no
modelo
lgico,
necessita-se
fazer
uma
transformao substituindo o relacionamento por
chaves estrangeiras. No caso do sentido da tabela
Obra para a tabela Assunto, deveria ser colocado
um atributo multivalorado em Obra para apontar
para seus diversos assuntos, o mesmo ocorrendo
no sentido inverso, da tabela Assunto para a tabela
Obra. Entretanto, relacionamentos n:n no so
possveis de serem representados no modelo
relacional, uma vez que todos os atributos devem
ser atmicos, ou seja, armazenar um nico valor.
Neste caso, a alternativa a criao de uma terceira
tabela no modelo relacional, conforme ilustrado na
Figura 6.

Figura 6. Mapeamento do Modelo Conceitual para

o Modelo Lgico Neste caso, a nova tabela gerada,
Obra_Assunto, ter como chave primria a juno
das chaves primrias das duas tabelas participantes,
formando uma chave primria composta. Alm
disso, cada parte da chave primria ser tambm
uma chave estrangeira para sua tabela de origem.
Assim, a cada relacionamento de uma obra com um
assunto, gera-se um novo registro na tabela
Obra_Assunto, transformando o relacionamento
n:n do modelo conceitual em dois relacionamentos
1:n no modelo lgico. Observa-se ainda que o nome
do relacionamento no modelo conceitual foi
substitudo por um nome de tabela que tivesse
algum significado no modelo lgico, pois este ser o
nome da tabela no banco de dados.
Um outro requisito apresentado trata da
necessidade de armazenar os autores de uma obra.
Trata-se tambm de um relacionamento n:n, uma
vez que uma obra tem diversos autores e um autor
pode estar associado a diversas obras. Porm, neste
caso especfico, tem-se uma particularidade, uma
vez que importante identificar a ordem dos
autores de uma obra, caracterizando quem o
primeiro autor, o segundo, e assim sucessivamente.
Este requisito tornou-se necessrio para evitar
cadastrar repetidamente um mesmo autor que
participa em diversas obras, facilitando tambm a
busca por autores. A questo a ser tratada aqui
relativa ordem do autor na lista de autores de
uma obra. Esta informao no pode ficar na tabela
Obra, uma vez que esta possui diversos autores, e
tambm no pode ficar na tabela Autor, uma vez
que o mesmo pode estar vinculado a diversas
obras. Neste caso, o local apropriado para
armazenar esta informao no prprio
relacionamento entre as duas tabelas, conforme
apresentado na Figura 7, que ainda apresenta a
tabela resultante no modelo relacional, chamada de
Obra_Autor.
Figura 7. Mapeamento de Relacionamento n:n com
atributo
Nesta situao, o atributo ordem do
relacionamento entre as entidades Obra e Autor
representa a posio de um determinado autor em
uma determinada obra, na sua lista de autores. Este
atributo representado no modelo lgico como um
atributo simples na tabela originada do
relacionamento n:n. Ao fazer esta modificao, fica
131

sem sentido o atributo autor_principal da tabela

Obra, devendo ser retirado.
Desta forma, no se torna necessrio repetir um
mesmo autor em cada uma das obras que estiver
vinculado. Isto faz com que as consultas por autor
no banco de dados sejam mais precisas, uma vez
que um mesmo autor poderia ser cadastrado de
formas diferentes, tendo uma abreviatura em seu
nome em uma determinada obra, por exemplo.
Por fim, o ltimo problema a ser resolvido refere-se
repetio de uma mesma obra caso esta tenha
mais de um exemplar. Seria interessante que uma
obra fosse cadastrada uma nica vez contendo os
atributos comuns aos seus diversos exemplares.
Cada exemplar deveria ter apenas seus atributos
especficos, um identificador nico, sua data de
aquisio e sua situao. Num primeiro momento,
isso pode parecer uma modificao pontual,
representado atravs de um relacionamento 1:n,
conforme Figura 8. Assim, se deve retirar o atributo
situacao_obra da tabela Obra, uma vez que agora
responsabilidade de cada exemplar armazenar
sua situao especfica.
Figura 8. Criao da tabela Exemplar
Ainda segundo o requisito definido, a numerao
dos exemplares deve iniciar de 1 a cada Obra. Ou
seja, deve-se ter o exemplar 1 da obra O Cdigo Da
Vinci e
o exemplar 1 da obra O Livro dos Cdigos, por
exemplo. Para que isso ocorra, a chave primria da
tabela Exemplar deve conter, alm do nmero do
exemplar, o cdigo da obra, formando uma chave
primria composta. Esta situao de modelagem
chamada entidade fraca, onde a chave primria da
entidade fraca (neste caso, a entidade Exemplar)
formada pela chave primria da entidade forte (no
caso, a entidade Obra), mais algum atributo que
diferencie seus registros (como
o nmero do exemplar). Nota-se assim que a
entidade fraca estar sempre carregando o
relacionamento com sua entidade forte, sugerindo
sempre uma leitura como um exemplar de uma
determinada obra, neste caso. A Figura 9 exibe a
transformao do modelo conceitual para o modelo
lgico relativo a esta situao.
Figura 9. Mapeamento de Entidade Fraca
Percebe-se que, no modelo conceitual, a notao
da entidade fraca feita atravs de uma linha dupla

envolvendo a entidade fraca. Nota-se ainda que,

uma vez que esta entidade pode estar associada a
diversas outras, para saber quem sua entidade
forte, tambm se apresenta com linha dupla o
relacionamento que liga entidade forte. No caso
do modelo relacional, no existe simbologia
especfica para este fim, apenas modificando a
chave primria da entidade fraca. Entretanto,
algumas ferramentas CASE utilizam simbologias
prprias para representar entidades fracas,
arredondando os cantos do smbolo de entidade,
ou com um tipo diferente de linha ligando-a a
entidade forte. A presena da chave da entidade
forte na entidade fraca enfatiza que, ao excluir um
registro na entidade forte, todos os seus associados
na entidade fraca tambm devem ser excludos,
uma vez que a integridade referencial no pode ser
violada.
Este requisito ainda impacta o modelo de forma
mais significativa. Por exemplo, nesta nova
perspectiva, um usurio faria reservas de obras
(uma vez que no importa o exemplar para a
reserva), mas faria emprstimo de um exemplar
especfico de uma obra.
5. UTILIZAO DE AUTO-RELACIONAMENTOS E
RELACIONAMENTOS TERNRIOS
Esta seo apresenta modificaes no modelo de
dados do sistema de biblioteca para incluir
funcionalidades que exercitem a utilizao de auto
relacionamentos e relacionamentos ternrios.
Assim, tem-se um novo conjunto de requisitos que,
para serem atendidos, vo provocar novas
modificaes no modelo de dados. Os novos
requisitos so:
1. Ser necessrio organizar os assuntos de forma
que seja possvel associar um determinado assunto
a outros assuntos relacionados. Por exemplo, ao
fazer uma consulta pelo assunto Modelagem de
Sistemas, seria importante que as obras
relacionadas ao assunto Modelagem de Dados
tambm fossem encontradas. Assim, um assunto
pode estar relacionado a diversos outros assuntos.
2. No cadastro de um usurio, caso este tenha sido
indicado por um outro usurio cadastrado na
biblioteca, ser necessrio registrar esta
informao. Assim, um usurio poder ter sido
indicado por um nico outro usurio. Por outro
lado, um usurio poder indicar diversos novos
usurios.
132

3. Exemplares podem passar por diversas

manutenes durante sua vida til numa biblioteca,
como limpeza, recuperao de pginas ou
encadernao. O sistema necessitar cadastrar
estas manutenes, contendo o exemplar em
manuteno, a data da manuteno, o funcionrio
responsvel pela manuteno e o motivo da
manuteno, sendo todos os campos obrigatrios.
Motivos de manuteno devem ser cadastrados e
possuem apenas cdigo e descrio. Vale ressaltar
que um mesmo exemplar pode sofrer diversas
manutenes
realizadas
por
diferentes
funcionrios. Um mesmo funcionrio pode fazer
vrias manutenes por motivos diferentes. Um
motivo de manuteno pode estar associado a
diversos exemplares e funcionrios. No existe na
biblioteca um cdigo associado a cada manuteno
realizada.
Para estes novos requisitos, primeiro deve-se
pensar na soluo atravs do modelo conceitual,
para depois trabalhar no modelo lgico. Na
transformao do modelo conceitual para o lgico,
deve-se considerar que auto-relacionamentos de
cardinalidade 1:n apenas acrescentam uma chave
estrangeira na prpria tabela e de cardinalidade n:n
devem originar novas tabelas. Relacionamentos
ternrios no modelo conceitual tendem a gerar
novas tabelas no modelo lgico.
O primeiro requisito apresentado nesta seo
necessita organizar os assuntos de obras de forma
que seja possvel associar um determinado assunto
a outros relacionados. Por exemplo, ao fazer uma
consulta pelo assunto Modelagem de
Sistemas, seria importante que as obras
relacionadas a Modelagem de Dados tambm
fossem encontradas. Assim, um assunto pode estar
relacionado a diversos outros assuntos. Desta
forma, precisa-se efetuar um relacionamento entre
dois assuntos, ou seja, um auto-relacionamento na
entidade Assunto. Deve-se tomar cuidado para no
criar uma outra entidade no modelo conceitual
para os assuntos relacionados, pois isso causaria
uma redundncia na base de dados, fazendo com
que assuntos fiquem repetidos em duas tabelas.
Este relacionamento ser de cardinalidade n:n, uma
vez que um assunto est relacionado a diversos
outros e vice-versa, forando a criao de uma nova
tabela no modelo lgico. A
Figura 12 exibe o modelo conceitual para resoluo
desta questo, bem como sua transformao para o

modelo lgico. Percebe-se que a chave primria da

tabela Assunto_Relacionamento, gerada no modelo
lgico, composta por duas chaves estrangeiras,
ambas referenciando a tabela Assunto.
Figura 12. Auto-Relacionamento n:n
O prximo requisito determina que, no cadastro de
um usurio, caso este tenha sido indicado por um
outro usurio cadastrado na biblioteca, ser
necessrio registrar esta informao. Assim, um
usurio poder ter sido indicado por um nico
outro usurio. Por outro lado, um usurio poder
indicar diversos novos usurios.
Este problema semelhante ao anterior, exceto
que o relacionamento neste caso 1:n. Desta
forma, como todos so usurios, existir um autorelacionamento na tabela Usurio. Sendo um
relacionamento 1:n, basta acrescentar uma chave
estrangeira para o usurio que fez a indicao na
prpria tabela Usuario.
A Figura 13 mostra a soluo para este problema
tanto no modelo conceitual como no lgico,
apresentando apenas alguns dos atributos da
tabela Usuario.
Figura 13. Auto-Relacionamento 1:n
O terceiro e ltimo requisito proposto nesta seo
refere-se a exemplares que podem passar por
diversas manutenes durante sua vida til numa
biblioteca, como limpeza, recuperao de pginas
ou encadernao. O sistema necessitar cadastrar
estas manutenes, contendo o exemplar em
manuteno, a data da manuteno, o funcionrio
responsvel pela manuteno e o motivo da
manuteno, sendo todos os campos obrigatrios.
Motivos de manuteno devem ser cadastrados e
possuem apenas cdigo e descrio. Vale ressaltar
que um mesmo exemplar pode sofrer diversas
manutenes
realizadas
por
diferentes
funcionrios.
Um mesmo funcionrio pode fazer vrias
manutenes em exemplares por motivos
diferentes. Um motivo de manuteno pode estar
associado a diversos exemplares e funcionrios.
No existe na biblioteca um cdigo associado a
cada manuteno realizada. Pode surgir uma
dvida se seria utilizado um relacionamento
ternrio ou uma agregao. Neste caso, como todos
os elementos envolvidos neste relacionamento so
obrigatrios (exemplar, funcionrio e motivo da
manuteno), e devem existir simultaneamente,
133

pode-se modelar como um relacionamento

ternrio.
Este tipo de relacionamento no seria apropriado
se, por exemplo, fosse possvel cadastrar a
manuteno com seu motivo e, posteriormente,
associar o funcionrio responsvel. Num
relacionamento ternrio, o comum que este
resulte numa nova tabela, onde sua chave primria
a composio das chaves das entidades
envolvidas no relacionamento, obrigatrias
simultaneamente.
A Figura 14 apresenta a soluo para este
requisito, tanto no modelo conceitual quanto no
lgico, apresentando apenas os atributos
necessrios a esta situao.
Figura 14. Relacionamento ternrio
A Figura 15 apresenta o modelo conceitual aps as
modificaes realizadas, enquanto a Figura 16 exibe
o modelo lgico correspondente.
Figura 15. O modelo conceitual aps as
modificaes.
Figura 16. O modelo lgico aps as modificaes.
As Tabelas 16 a 19 mostram as estruturas das
tabelas que sofreram modificaes em funo dos
novos requisitos.
Tabela
16.
Estrutura
da
tabela
Assunto_Relacionamento
6. UTILIZAO DE AGREGAES E ESTRUTURAS DE
GENERALIZAO/ESPECIALIZAO
Nesta seo ser proposto um novo problema,
desta vez modificando o modelo de dados do
sistema de biblioteca para incluir funcionalidades
que exercitem a utilizao de agregaes e
estruturas de generalizao e especializao.
Tem-se ento um novo conjunto de requisitos que,
para serem atendidos, vo provocar novas
modificaes no modelo de dados. Os novos
requisitos so:
1. Ser necessrio fazer uma distino entre tipos
de obras, que agora podem ser Livros ou Peridicos.
Para Livros, deve-se armazenar o nmero do ISBN
(International Standard Book Number Nmero
Padro Internacional de Livro), enquanto para
peridicos, deve-se armazenar o nmero do ISSN
(International Standard Serial Number - Nmero
Internacional Normalizado para Publicaes
Seriadas). Estes nmeros no devem ficar
armazenados na tabela Obra, uma vez que obras
no possuem ambos os nmeros simultaneamente

e tambm no se deseja que fiquem nulos

dependendo do tipo da obra.
2. Periodicamente, a biblioteca faz compra de novas
obras. Para isso, so abertas requisies onde so
registradas as obras a serem adquiridas, bem como
sua quantidade. Desta forma, uma obra pode estar
em vrias requisies e uma requisio pode
possuir diversas obras.
Requisies ainda possuem um nmero seqencial
que as identificam, uma data de abertura e um
campo que indica o estado da requisio, podendo
estar aberta ou fechada para incluso de novas
obras.
Quando do momento da compra, cada obra da
requisio pode ser adquirida de um fornecedor
diferente, enquanto um fornecedor pode fornecer
vrias obras de diferentes requisies. Para isso,
deve-se considerar uma nova entidade chamada
Fornecedor, que possui cdigo, razo social, e
telefone de contato. Vale ressaltar ainda que
fornecedores somente so definidos quando da
compra de cada obra na requisio, associando
ento seu preo e data de compra.
Para estes novos requisitos, primeiro deve-se
pensar na soluo atravs do modelo conceitual,
para depois trabalhar no modelo lgico. Na
transformao do modelo conceitual para o lgico,
deve-se considerar que agregados tendem a gerar
novas
tabelas
e
relacionamentos
de
generalizao/especializao podem gerar tabelas
para cada entidade, para cada ramo na hierarquia
ou para a hierarquia completa, sendo o mais
comum gerar uma tabela para cada entidade.
O primeiro requisito desta seo torna necessrio
fazer uma distino entre tipos de obras, que agora
podem ser Livros ou Peridicos. Para Livros, deve-se
armazenar o nmero do ISBN, enquanto que, para
peridicos, deve-se armazenar o nmero do ISSN.
Estes nmeros no devem ficar armazenados na
tabela Obra, uma vez que obras no possuem
ambos os nmeros simultaneamente e tambm
no se deseja que fiquem nulos dependendo do
tipo da obra.
Problemas deste tipo podem ser resolvidos
utilizando
uma
estrutura
Generalizao/Especializao,
que
representa
situaes onde determinadas entidades so
tratadas como especializaes de uma mais
genrica, que agrupa o que comum s entidades
da hierarquia. Estruturas deste tipo podem ser
134

mapeadas em uma nica tabela, em uma tabela

para cada especializao ou uma tabela para cada
entidade envolvida, dependendo da situao.
A apresenta estas situaes de mapeamento para o
problema em questo. Na situao 1, todos os
atributos da hierarquia foram agrupados numa
nica tabela, fazendo com que atributos fiquem
eventualmente vazios em funo do tipo da obra. A
situao 2 representa apenas as especializaes,
fazendo com que os atributos da generalizao
sejam repetidos. A situao 3 apresenta uma tabela
para cada entidade da hierarquia, eliminando
atributos repetidos, mas fazendo com que o
acesso a uma obra tenha que agrupar dados de
mais de uma tabela. Neste estudo de caso, ser
utilizada a situao 3, onde cada entidade
mapeada para uma tabela especfica, no havendo
redundncia de dados ou atributos com valores
nulos em funo do tipo de obra em questo,
atendendo assim ao requisito proposto.
Figura
17.
Mapeamento
de
Estruturas
Generalizao/Especializao
O prximo requisito trata da questo de compras
de obras pela biblioteca.
Periodicamente, a biblioteca faz compra de novas
obras. Para isso, so abertas requisies onde so
registradas as obras a serem adquiridas, bem como
sua quantidade. Desta forma, uma obra pode estar
em vrias requisies e uma requisio pode
possuir diversas obras. Requisies ainda possuem
um nmero
seqencial que as identificam, uma data de
abertura e um campo que indica o estado da
requisio, podendo estar aberta ou fechada para
incluso de novas obras. Quando do momento da
compra, cada obra da requisio pode ser adquirida
de um fornecedor diferente, enquanto um
fornecedor pode fornecer vrias obras de
diferentes requisies. Para isso, deve-se considerar
uma nova entidade chamada Fornecedor, que
possui cdigo, razo social, e telefone de contato.
Vale ressaltar ainda que fornecedores somente so
definidos quando da compra de cada obra na
requisio, associando ento seu preo e data de
compra.
Como uma obra pode ser alocada a uma requisio
sem um fornecedor num primeiro momento, um
relacionamento ternrio no se mostraria

adequado, uma vez que a tabela originada teria

tambm o fornecedor como parte da chave
primria, e este no poderia ficar nulo. Desta
forma, esta situao pode ser resolvida com uma
agregao, que normalmente origina uma nova
tabela. A Figura 18 representa uma agregao para
este problema apresentado.
Figura 18. Mapeamento de Agregao Percebe-se
na tabela Item_Requisicao que o atributo
cod_fornecedor apenas uma chave estrangeira,
no fazendo parte da chave primria. Isso
irpermitir que o mesmo possa ter o valor nulo
enquanto uma obra de uma requisio no passar
pelo processo de compra.
Desta forma, a Figura 19 apresenta o modelo
conceitual aps as modificaes realizadas,
enquanto a Figura 20 exibe o modelo lgico
correspondente.
Percebe-se nas tabelas Livro e Periodico que ambas
possuem como chave primria o campo
cod_obra, o mesmo da tabela que representa a
generalizao.
Esta uma caracterstica de estruturas
generalizao / especializao, onde todas as
tabelas da hierarquia possuem a mesma chave
primria, aquela definida na tabela mais genrica.
Usualmente, ainda coloca-se um atributo na tabela
que representa a generalizao, neste caso a tabela
Obra, para indicar a tabela que possui a
complementao de seus dados, Livro ou Periodico
neste caso. Isto no precisou ser feito neste
momento, pois a tabela Obra j possua um atributo
chamado tipo_obra, justamente para este fim.
A tabela Item_Requisicao representa a agregao
do modelo conceitual.
Percebe-se, neste caso, que o relacionamento entre
as entidades Obra e Requisicao de cardinalidade
n:n, fazendo com que esta tabela surgisse de
qualquer forma. A
particularidade aqui se refere ligao desta tabela
Item_Requisicao com a tabela Fornecedor, de
forma opcional, oferecendo a possibilidade de um
item de requisio ainda no possuir um
fornecedor. Isto fica evidenciado no modelo
conceitual uma vez que o relacionamento com a
tabela Fornecedor feito diretamente com a
135

agregao, e no com nenhuma de suas entidades

participantes, caracterizando
que um fornecedor est associado com uma obra
de uma determinada requisio.
Esta situao no poderia ser resolvida com um
relacionamento ternrio entre as entidades Obra,
Fornecedor e Requisio pois, neste caso, as chaves
primrias das trs entidades participantes
comporiam a chave primria da entidade
Item_Requisicao, obrigando-a a ter um fornecedor
no momento da sua criao, uma vez que um
campo que faz parte de uma chave primria no
pode ser nulo. Por fim, percebe-se que os atributos
preco_compra e data_compra no so obrigatrios
uma
vez que um item de requisio pode ainda no ter
sido adquirido. Uma alternativa a isso seria deslocar
estes campos, bem como o cdigo do fornecedor
para uma outra tabela de compras, mas optamos
por esta soluo neste exemplo.
7. Consideraes Finais
Este artigo apresentou, atravs de um estudo de
caso prtico, as principais tcnicas de modelagem
de dados, tanto a nvel de utilizao do modelo
conceitual, atravs do Modelo EntidadeRelacionamento, quanto do modelo lgico, atravs
do Modelo Relacional, visando discutir no apenas
a teoria de modelagem de dados, mas tambm
apresentar possibilidades de aplicao atravs de
situaes reais de utilizao. A utilizao destas
tcnicas fundamental para um melhor
entendimento do problema e, consequentemente,
auxiliar na construo de sistemas de software mais
robustos e flexveis, objetivando atender as
necessidades do usurio final.
Administrao financeira e oramentria: noes
de planejamento e execuo de oramento
pblico; Ingls tcnico.

O planejamento oramentrio efetuado com trs

instrumentos
bsicos: o Plano Plurianual (PPA), a Lei das
Diretrizes
Oramentrias (LDO) e a Lei do Oramento Anual
(LOA).

A execuo oramentria inicia- se no primeiro dia

de janeiro e termina em 31 de dezembro,
coincidindo com o ano civil. Consiste na
arrecadao de receitas de impostos, taxas,
contribuies de melhoria, transferncias e na
aplicao desses recursos nos projetos e atividades
aprovados na Lei Oramentria Anual.
Execuo do oramento
Sancionada e publicada a LOA, inicia-se o processo
de execuo do oramento.
Na fase de execuo, os rgos realizam os
programas governamentais contemplados na lei
oramentria, mediante uma srie de aes que
possibilitam atingir as diretrizes, objetivo, metas e
prioridades estabelecidas nos instrumentos de
planejamento e na LRF.
Todas as atividades de execuo oramentria e
financeira
se desenvolvem dentro do exerccio definido como
o ano civil, isto , de 01 de janeiro a 31 de
dezembro, conforme dispe o art. 34 da Lei n
4.320/64.

O que Oramento Pblico?

um instrumento de planejamento governamental
em que constam as despesas da administrao
pblica para um ano, em equilbrio com a
arrecadao das receitas previstas. o documento
onde o governo rene todas as receitas
arrecadadas e programa o que de fato vai ser feito
com esses recursos. onde aloca os recursos
destinados a hospitais, manuteno das estradas,
construo de escolas, pagamento de professores.
no oramento onde esto previstos todos os
recursos arrecadados e onde esses recursos sero
destinados.
Leis e princpios oramentrios
O que Lei de Diretrizes Oramentrias (LDO)?
O Projeto de Lei de Diretrizes Oramentrias (LDO)
estabelece as metas e prioridades para o exerccio
financeiro seguinte; orienta a elaborao do
Oramento; dispe sobre alterao na legislao
tributria; estabelece a poltica de aplicao das
agncias financeiras de fomento. Com base na LDO
aprovada pelo Legislativo, a Secretaria de
Oramento Federal (SOF) elabora a proposta
oramentria para o ano seguinte, em conjunto
136

com os Ministrios e as unidades oramentrias dos

Poderes Legislativo e Judicirio. Por determinao
constitucional, o governo obrigado a encaminhar
o Projeto de Lei do Oramento ao Congresso
Nacional at 31 de agosto de cada ano.
O que Lei Oramentria Anual (LOA)?
Quais so os princpios bsicos que devem ser
seguidos para elaborao e controle do oramento?
O que Lei de Responsabilidade Fiscal (LRF)?
Elaborao e execuo do oramento
Como feito o Oramento Pblico?
O Oramento Geral da Unio (OGU) formado
pelos Oramentos Fiscal, da Seguridade Social e de
Investimento das empresas estatais federais.
Existem passos que devem ser seguidos para
elaborao e controle do Oramento que esto
definidos na Constituio Federal de 1988, na Lei n
4.320/64, no Plano Plurianual (PPA) e na Lei de
Diretrizes Oramentrias (LDO). A Constituio
atribuiu ao Poder Executivo a responsabilidade pelo
Sistema de Planejamento e Oramento e a iniciativa
dos seguintes projetos de lei: Plano Plurianual (PPA)
; Diretrizes Oramentrias (LDO); Oramento Anual
(LOA)

Como feito o Oramento Pblico?

O Oramento Geral da Unio (OGU) formado
pelos Oramentos Fiscal, da Seguridade Social e de
Investimento das empresas estatais federais.
Existem passos que devem ser seguidos para
elaborao e controle do Oramento que esto
definidos na Constituio Federal de 1988, na Lei n
4.320/64, no Plano Plurianual (PPA) e na Lei de
Diretrizes Oramentrias (LDO). A Constituio
atribuiu ao Poder Executivo a responsabilidade pelo
Sistema de Planejamento e Oramento e a iniciativa
dos seguintes projetos de lei: Plano Plurianual (PPA)
; Diretrizes Oramentrias (LDO); Oramento Anual
(LOA)
Como o processo oramentrio?
O processo oramentrio compreende as fases de
elaborao e execuo das leis oramentrias
Plano Plurianual ( PPA), Lei de Diretrizes
Oramentrias ( LDO) e Lei Oramentria Anual
(LOA). Cada uma dessas leis tem ritos prprios de
elaborao, aprovao e implementao pelos
Poderes Legislativo e Executivo. Entender esses

ritos o primeiro passo para a participao da

sociedade no processo decisrio, fortalecendo,
assim, o exerccio do controle social na aplicao
dos recursos pblicos.
O que execuo oramentria?
o processo que consiste em programar e realizar
despesas levando-se em conta a disponibilidade
financeira da administrao e o cumprimento das
exigncias legais.

L. PLANEJAMENTO ORAMENTRIO
1. Planejamento
As empresas vivem num ambiente extremamente
competitivo, se no planejarem suas atividades
correm o risco de serem surpreendidos por
imprevistos e passarem por grandes dificuldades ou
at mesmo chegar falncia. O planejamento deve
ser usado
como ferramenta para decidir
antecipadamente o que fazer, de que maneira
fazer, quando fazer e quem deve fazer.
Nenhuma empresa est livre de mudanas,
portanto o planejamento como uma das etapas da
administrao extremamente necessrio. Com o
uso desta metodologia a organizao opta por
metas baseadas em avaliaes e previses futuras,
dando forma e direcionando os esforos de
administradores e trabalhadores dos demais nveis
organizacionais.
O propsito do planejamento pode ser definido se
como desenvolvimento de processos, tcnicas e
atitudes administrativas, as quais proporcionam
uma situao vivel de avaliar as implicaes
futuras de decises presentes em funo dos
objetivos empresariais que facilitaro a tomada de
deciso no futuro, de modo mais rpido, coerente e
eficaz.
O planejamento formado atravs de planos,
portanto, o administrador deve saber lidar com
direfentes tipos desses planos, podendo incluir
perodo de longo a curto prazo, podendo envolver a
organizao inteira, uma diviso ou departamento
ou ainda uma tarefa. O planejamento possibilita o
administrador avaliar os recursos a serem utilizados
pela empresa, para que ela possa atingir os seus
objetivos traados.
Tipos de planejamento = O planejamento dentro
das empresas pode ser dividido em trs formas:
137

ESTRATGICO = Abrange as decises de longo

prazo (conjunto de metas a longo prazo e dos meios
disponveis que possibilitam a alcance dessas
metas, dando rumo aos negcios da empresa),
TTICO = Trata das metas de mdio prazo e tem
como objetivo aproveitar ao mximo determinadas
reas de resultado da empresa, ou seja, faz um
planejamento especfico para cada unidade da
empresa, sendo desenvolvido por nveis inferiores
da organizao.
OPERACIONAL = Compreende as decises a curto
prazo e tem o intuito de elevar ao mximo os
recursos da empresa utilizados em operaes
realizadas nas unidades e conforme perodos prdeterminados.
2. Receitas
Receita designa entradas de elementos para o ativo
da empresa, na forma de bens ou direitos que em
geral so representadas sob a forma de dinheiro ou
de crditos representativos de direitos.
Receita o valor proveniente principalmente das
entradas de recursos na empresa originados da
venda de produtos, mercadorias ou servios
prestados e juros recebidos.
Em resumo receita a expresso monetria,
validada pelo mercado, do agregado de bens e
servios da entidade, em determinado perodo de
tempo. As receitas so classificadas em:
Receita Operacional = Esta proveniente das
operaes freqentes da empresa, que podem ser
operaes normais e
habituais.
Receita No-Operacional = Est relacionada s
receitas que no ocorrem com freqncia, que no
esto envolvidas nas
operaes da empresa. So includas como
despesas no-operacionais os valores relativos s
receitas decorrentes de
transaes casuais, ou seja, algo que no
recorrente, que no se repte. Resumindo as
receitas ou despesas onde no esto relacionadas
diretamente com o objetivo do negcio da empresa
so classificados como no-operacionais, tratandose habitualmente como perdas ou ganhos.
3. Custos
Custo representa o esforo que uma empresa deve
despender para poder disponibilizar um produto
junto a um consumidor.

Assim definindo, parece fcil a tarefa de apurar um

custo, pois exige, apenas, a apurao de todos os
recursos consumidos pela
empresa e sua
distribuio pelos produtos fabricados. Entretanto,
ao considerar a complexidade dos recursos
aplicados pela empresa, a existncia de consumos
indiretos para suporte (apoio) produo, o
tratamento a ser dispensado aos investimentos
requeridos para possibilitar a produo, entre
outros, se constata que este trabalho no nada
simples.
Os custos podem ser classificados em:
Custos variveis = Todos aqueles que se alteram na
proporo direta com a quantidade produzida (os
custos variveis guardam com as quantidades
produzidas uma relao quase que linear) como,
por exemplo: custos com Matria Prima.
Observe-se que os custos variveis devem ser
analisados com respeito s quantidades consumidas
na produo e no s quantidades adquiridas ou s
estocadas.
Custos fixos = So aqueles que permanecem
inalterados, apesar de variao na quantidade
produzida (variao marginal); estes podem ser
exemplificados pelos custos de demanda de energia
eltrica. A anlise da intensidade das variaes na
quantidade produzida, fator de separao entre
estes dois tipos de custos, possibilitou que
pesquisadores desenvolvessem alguns novos
conceitos importantes (mas de uso especfico), que
so: custos semi-fixos e custos semi-variveis.
Custos Diretos = So gastos diretamente
relacionados aos produtos e podem ser
mensurados de maneira clara e objetiva, ou seja,
referem-se s quantidades de materiais e servios
utilizados na produo de um determinado
produto. Exemplos de custos diretos comuns na
indstria:
matrias-primas,
materiais
de
acabamento, componentes e embalagens. Em
alguns casos, a mo-de-obra aplicada na produo
poder ser considerada um custo direto. Para que
isso ocorra, torna-se necessria a mensurao do
tempo utilizado na fabricao do produto.
Custos Indiretos = So gastos no diretamente
relacionados aos produtos, portanto, no so
mensurveis de maneira clara e objetiva. Neste
caso, torna-se necessrio adotar um critrio de
rateio (distribuio) para alocar tais custos aos
138

produtos fabricados, como por exemplo: aluguel,

manuteno e superviso da fbrica etc.
A ocorrncia de custos diretos e indiretos est
presente em todos os processos produtivos, mas a
participao nos custos totais e seu contedo
variam, principalmente, em funo de: tipo de
produto, tecnologia empregada e estrutura da
empresa.
A caracterstica de invariabilidade dos custos fixos
se deve ao prazo de observao, ou seja, quanto
menor for o prazo de anlise e classificao dos
custos, maior ser a quantidade de custos fixos e
menor a de custos variveis; de forma inversa
tambm esta afirmao verdadeira e, levando-se
este prazo ao limite, todos os custos de uma
empresa so variveis.
Nem todos os custos diretos so variveis, apesar
de haver uma forte correlao entre eles, podendose at afirmar que, excepcionalmente os custos
diretos no so variveis. Quanto aos outros dois
tipos (custos fixos e custos indiretos) constata-se
que, normalmente, mas nem sempre, os custos
fixos tambm so indiretos.
4. Despesas
Despesa todo o gasto necessrio para obter uma
receita, como por exemplo, impostos, comisses de
vendas. As despesas so itens que reduzem o
patrimnio lquido e que tm essa caracterstica de
representar sacrifcios no processo de obteno de
receitas.
Contabilmente despesa no sinnimo de custo,
sendo que custo est relacionado com o processo
produtivo de bens ou servios, enquanto que
despesa de uma forma geral so os gastos com a
manuteno das atividades da organizao.
Podemos afirmar que todas as despesas esto
direta ou indiretamente para a efetivao de
receitas, as empresas possuem despesas para gerar
receitas e no para produzir seus bens e servios.
As despesas podem ser constitudas pelos grupos
de:
Despesas com vendas = So aquelas que oferecem
apoio as vendas, como por exemplo, comisses
sobre vendas, propaganda, marketing etc. As
despesas com vendas so os gastos relativos
promoo, posicionamento e distribuio dos
produtos da empresa, justamente com os riscos
assumidos pela venda.

Despesas administrativas = So necessrias para

dirigir a empresa, como material de escritrio,
salrios e encargos do pessoal administrativo.
Despesas financeiras = So gastos referentes aos
juros pagos pela empresa, em conseqncia de
emprstimos bancrios, descontos de cheques e
duplicatas. Resumindo englobam descontos de
ttulos, juros pagos sobre contratao de
emprstimos, financiamentos, descontos de ttulos
entre outras operaes passveis a despesas de
juros.
5. Margem de Contribuio
Margem de contribuio quantia em dinheiro que
sobra do preo de venda de um produto, servio ou
mercadoria aps retirar o valor do custo varivel
unitrio. Esta quantia que ir garantir a cobertura
do custo fixo e do lucro, aps a empresa ter
atingido o Ponto de equilbrio, ou ponto crtico de
vendas.
6. EBITDA
Vem da sigla inglesa de Earnings Before Interest,
Taxes, Depreciation and Amortization e que em
portugus significa, literalmente, Resultados antes
de Juros, Impostos, Depreciao e Amortizao.
Conhecido tambm como LAJIDA e em muitas vezes
designado por cash-flow operacional (embora seja
de realar que difere do cash-flow operacional
apurado com o mapa de cash-flows), e representa o
dinheiro gerado pela empresa e disponvel para:
Financiar os investimentos em bens de capital
(capex)
Financiar as necessidades de Fundo de Maneio
Efetuar o pagamento de impostos
Cumprir os encargos com a dvida
Criar reservas
Remunerar os acionistas atravs de dividendos
considerado pelos analistas financeiros o melhor
indicador de gerao de caixa operacional, pois
considera em seu calculo somente os resultados
operacionais que afetam o caixa, desconsiderando
as despesas e as receitas operacionais como a
depreciao, amortizao e exausto; o resultado
de equivalncia patrimonial, as despesas e as
receitas financeiras, outras receitas e despesas
operacionais no rotineiras e, tambm, os impostos
sobre o lucro (Imposto de Renda e Contribuio
Social sobre o Lucro).
7. Oramento
139

A administrao e muitos investidores e gerentes

de crditos bancrio est cada vez mais
consciente dos mritos dos planos empresariais
formais. O maior trabalho tcnico do contador
responsvel pelo oramento com os dados
futuros esperados, e no com os dados histricos. O
oramento coloca o planejamento no seu lugar no
primeiro plano na mente dos administradores.
Temos como misso nos dias de hoje encarar o
desafio de comear a compreender por que o
oramento til. O oramento visa, basicamente, a
dirigir a ateno, pois ajuda os administradores a se
concentrarem em problemas operacionais ou
financeiros com uma antecedncia suficiente para o
planejamento ou a ao eficaz.
A contabilidade ajuda o desempenho operacional
da administrao (com que eficincia se adquirem e
usam itens do ativo). Mas a funo de
financiamento (como se obtm os recursos
financeiros para investir em ativo) tambm
importante. por isso que examinamos os
oramentos de caixa e os oramentos operacionais.
As organizaes sucedidas caracterizam-se, em
geral, por uma administrao operacional superior
e por uma administrao financeira superior. Os
fracassos
das
empresas
podem
ser,
frequentemente, atribudos ao desprezo, pela
administrao, dos aspectos financeiros de suas
responsabilidades.
O oramento passou por uma evoluo significativa,
onde saiu de um oramento empresarial para um
oramento perptuo.
Conceito
Oramento nada mais do que colocar na frente
aquilo que est acontecendo hoje. Outra definio
que pode ser dada que o oramento a
expresso quantitativa de um plano de ao e ajuda
coordenao e implementao de um plano.
O oramento geral resume os objetivos de todas as
subunidades de uma organizao vendas,
produo, distribuio e finanas. Quantificam
metas para vendas, produo, lucro lquido e
posio de caixa e para qualquer outro objetivo
especificado pela administrao. O oramento geral
normalmente consiste num demonstrativo de lucro
futuro esperado, num balano, num demonstrativo
de receitas e despesas de caixa e em quadros de
clculos.

Esses demonstrativos so o ponto culminante de

uma srie de decises de planejamento baseadas
num exame detalhado e rigoroso do futuro da
organizao. claro que os oramentos tambm
podem ser usados a nvel individual. Por exemplo,
um aluno pode fazer um oramento detalhado ou
geral do que gastar com alimentao na prxima
semana ou ms, das horas de estudo antes das
provas, e assim por diante.
Vantagens do oramento
Muitos cticos nunca usaram oramentos dizem
logo: acho que o oramento muito bom para o
negcio dos concorrentes, mas minha empresa
diferente. H muitas incertezas e complicaes para
que o oramento possa valer a pena para mim.
Mas os mesmos administradores, quando
indagados quanto aos detalhes, geralmente
revelam que esto sempre planejando, mas de
modo informal.
Talvez a melhor maneira de combater esta atitude
mope seja citar outros da mesma indstria que
cuidem melhor do oramento e que,
inevitavelmente, estaro entre os lderes da
indstria. Uma organizao que se use formalmente
o oramento geralmente logo de convence de sua
utilidade e nem pensaria em voltar para a poca
antiga, que no usava oramento. Os benefcios do
oramento quase sempre superam claramente seu
custo e o esforo necessrio.
Um programa oramentrio sempre ser til para
qualquer organizao, independentemente se deu
tamanho e de suas incertezas. Eis os principais
benefcios:
1.
O
oramento,
formalizando
suas
responsabilidades pelo planejamento, obriga os
administradores a pensar frente.
2. O oramento estabelece expectativas definidas
que a melhor base de avaliao do desempenho
posterior.
Objetivos do oramento
O oramento pode e deve reunir diversos objetivos
empresariais, na busca da expresso do plano e
controle de resultados.
Portanto, convm ressaltar que o plano
oramentrio no apenas prever o que vai
acontecer e seu posterior controle. O ponto
fundamental p processo de estabelecer e
coordenar objetivos para todas as reas da
140

empresa, de forma tal que todos trabalhem

sinergicamente em busca dos planos de lucros. Os
objetivos da corporao, genricos, direcionam os
objetivos das diversas reas ou funes, que so os
objetivos especficos.
Desta maneira, o processo de estabelecer objetivos
deve ser interativo, que coordena os objetivos
gerais com os especficos.
Nessa linha de atuao, o processo oramentrio
deve permitir a participao de toda a estrutura
hierrquica com responsabilidade oramentria,
no devendo ser um processo ditatorial com uma
nica direo, de cima para baixo. certo portanto
que, em ltima instncia e em casos de dvida,
prevalecero os critrios da corporao.
Todos os envolvidos no processo oramentrio
devem ser ouvidos. Esse envolvimento permitir
uma gesto participativa, compatvel com a
estrutura de delegao de responsabilidades e
permitir o comprometimento de todos os gestores
dos setores especficos. S assim ser possvel a
gesto adequada da etapa final do plano
oramentrio, que o controle oramentrio, com
a anlise das variaes e do desempenho individual
dos gestores.
Diante dessas colocaes, podemos listar alguns
princpios gerais para a estruturao do plano
oramentrio:
Orientao para objetivos: O oramento deve se
direcionar para que os objetivos da empresa e dos
setores especficos sejam atingidos eficiente e
eficazmente.
Envolvimento dos gestores: Todos os gestores
responsveis por um oramento especfico devem
participar
ativamente
dos
processos
de
planejamento r controle, para obtermos o seu
comprometimento.
Comunicao integral: Compatibilizao entre o
sistema de informaes, o processo de tomada de
decises e a estrutura organizacional.
Expectativas realsticas: Para que o sistema seja
motivador, deve apresentar objetivos gerais e
especficos, que sejam desafiadores, dentro da
melhor viso da empresa, mas passveis de serem
cumpridos.
Aplicao flexvel: O sistema oramentrio no
um instrumento de dominao. O valor do sistema
est no processo de produzir os planos, e no nos
planos em si. Assim, o sistema deve permitir
correes, ajustes, revises de valores e planos.

Reconhecimento dos esforos individuais e de

grupos: O sistema oramentrio um dos principais
instrumentos de avaliao de desempenho etc.
Tipos de Oramento
O oramento pode ser mais bem visualizado atravs
dos seus diversos tipos. Descreve alguns dos tipos
mais utilizados pelas organizaes:
Oramento Administrativo: aquele que feito a
priori e prev os fatos administrativos de uma
empresa ou entidade.
Oramento Anual: quadro em que se prevem
receita e despesa a serem realizadas ao longo de
um ano.
Oramento Complementar: previso adicional, isto
, que visa complementao de um fato
patrimonial ou verba.
Oramento de Aquisies: so clculos para
investimentos a serem realizados.
Oramento de Cmbio: expresso utilizada para
designar uma previso dos recebimentos e
pagamentos em divisas, a serem realizados.
Oramento de Custos: previso das despesas a
serem realizadas para a execuo da tarefa
produtiva.
Oramento Pblico: uma tabela da despesa e da
receita, com suas fontes e origem legislativa. uma
previso das possibilidades financeiras do Estado e
ao mesmo tempo uma autorizao do Poder
Legislativo, para que os impostos possam ser
arrecadados e as despesas efetuadas. No se pode
cobrar impostos ou efetuar despesas, sem que
estejam consignadas na lei oramentria. O
oramento , portanto, instrumento da poltica
financeira, destinado a orientar o poder pblico na
execuo do programa de governo.
Por sua vez, diz que os oramentos podem ser
desenvolvidos com mtodos diferentes, de acordo
com as circunstncias concretas da empresa, como
segue:
1. Oramento de Tendncias = Trata-se de um
oramento contido aos elementos (receitas e
custos) de anos anteriores, os quais sero ajustados
aos valores atuais, com algumas pequenas
mudanas de metas. Um dos aspectos positivos
dessa abordagem defendido por estudiosos, afirma
que para sua elaborao, no se exigiria dos
funcionrios responsveis muito tempo e nem
muito esforo, pois existem dados a serem
comparados. J como aspecto negativo, os
141

estudiosos acreditam que essa teoria impossibilita a

correo de provveis ineficincias existentes no
processo produtivo e/ou administrativo [...],
condicionando a empresa a uma atitude
conservadora que pode afast-la do mercado em
pouco tempo.
2. Oramento Base Zero = O oramento base zero
rejeita a viso tradicional do oramento e,
principalmente, a ideia do oramento incremental,
que leva em considerao os dados do ano passado
mais um adicional. Em vez disso, o oramento de
base zero projeta todas as pecas como se
estivessem sendo compiladas pela primeira vez. A
principal desvantagem do oramento de base zero
o tempo de elaborao. Neste sentido, o
oramento base zero pode ser bastante
burocrtico, com muitos papis e inmeros
controles, leva muito mais tempo para ser
elaborado do que os oramentos tradicionais, em
virtude de que os gastos devem ser justificados e
aprovados. As vantagens do oramento base zero
que pode ser implementado em qualquer
organizao com ou sem fins lucrativos, as
atividades normalmente podem ser controladas
atravs das relaes de contribuio para o
resultado global do negcio, como cada quantia a
ser gasta precisa ser justificada, o oramento base
zero leva mais tempo para ser elaborado, mas
provavelmente conduz a um melhor resultado. Ele
leva a empreender revises nas estimativas bsicas
para todos os departamentos a cada ano, evitando
assim a perpetuao das ineficincias.
3. Oramento Flexvel = O oramento flexvel tem
duas diferenas bsicas frente ao oramento
empresarial. Primeiro, no limita a projeo a um
nvel de atividade, mas sim, para uma gama de
atividades. Segundo, os resultados atuais no so
comparados com os custos ao nvel de atividade do
oramento original; ou seja, os custos incorridos
so comparados com aqueles necessrios para esse
nvel de atividade.Vantagens e desvantagens do
oramento flexvel a anlise de cada variao
importante para melhorar o controle e avaliao do
desempenho.Atravs do oramento flexvel, as
variaes so analisadas e compreendidas pelos
colaboradores da empresa. A clareza e participao
na elaborao do oramento direcionam a empresa
a atingir os objetivos globais. A utilizao do
oramento flexvel exige um conhecimento maior
sobre os custos. As empresas em geral encontram

problemas para separar custos fixos de variveis,

dificultando a utilizao do oramento flexvel, o
mesmo tambm tem limitaes no gerenciamento
de medidas no financeiras.
4. Oramento Contnuo = O oramento contnuo
freqentemente usado quando se acredita que
planos realistas podem ser feitos para curtos
perodos e desejvel ou necessrio replanejar
projees
continuamente
por
fora
das
circunstncias.
Este sistema fcil de implementar, fcil de
gerenciar, requer muito menos tempo de
elaborao, assegura verdadeira responsabilidade,
prediz o fluxo monetrio, e resulta em um
oramento mais preciso que as aproximaes dos
do passado.
O oramento contnuo adequado a empresas com
produtos com ciclo de vida muito curto e a
processos que exigem rapidez nas mudanas.
5. Oramento Perptuo = um sistema de
planejamento que prev custos e uso de recursos
fundamentado nas relaes de causa e efeito entre
os processos correntes, permite clara identificao
das inter-relaes entre atividades da empresa e
como essas relaes influenciam no desempenho
individual e no resultado global. Qualquer mudana
nos eventos chave desencadear alteraes nas
metas oramentrias, adaptando-as realidade, tal
premissa proporciona ao sistema oramentrio
grande flexibilidade, desencadeando mudanas nas
metas a qualquer momento, independentemente
do ciclo oramentrio. A anlise dos eventos por
parte dos gestores e empregados permite melhor
entendimento dos efeitos, e tambm encontrar a
melhor maneira de controlar sua influncia positiva
ou negativa no resultado.
Formalizao do planejamento
A principal vantagem do oramento ,
provavelmente, que ele obriga aos administradores,
a pensarem frente a prever as condies em
transformao e se prepararem para elas. O
processo oramentrio torna o planejamento uma
responsabilidade administrativa explcita. Muitas
vezes, os administradores trabalham na base do
dia-a-dia, apagando um incndio aps o outro na
empresa. Simplesmente no tm tempo para
pensar mais detidamente em problemas alm dos
que vo ocorrer no dia seguinte. O planejamento
142

deixado para trs ou, de fato, impossibilitado pelas

presses do dia-a-dia.
O problema da orientao do dia-a-dia na
administrao de uma organizao que os
objetivos nunca se cristalizam. Sem os objetivos, o
funcionamento da empresa fica sem direo, os
problemas no so previstos e os resultados so
difceis de ser interpretados. Os que defendem o
uso correto dos oramentos afirmam que a maioria
das emergncias da empresa pode ser evitada com
um planejamento cuidadoso.
A elaborao do oramento exige que os objetivos
definidos pela organizao sejam contemplados e
perseguidos. Caso isso no ocorra, o oramento
deve ser revisado e ajustado, j que ele o
instrumento gerencial que deve proporcionar a
realizao dos objetivos.
A anlise externa a maneira pela qual a
organizao olha o ambiente externo e identifica as
oportunidades que pretende auferir. Ela o faz com
base na avaliao de cenrios, levando em conta
elementos que contm informaes (entre outras)
sobre:
Cenrio Poltico;
Cenrio Econmico;
Tecnologia;
Cenrio Social;
Cenrio Legal;
Cenrio Fiscal;
Ecologia;
Concorrncia;
Fornecedores;
Cenrio Demogrfico.
Anlise Interna a forma pela qual a organizao,
depois de analisar o ambiente externo, se volta
para dentro e identifica as necessidades de recursos
requeridos para que possa atingir os seus objetivos.
Ela deve avaliar os seus recursos humanos, sistemas
de
informaes,
tecnologias,
metodologia,
procedimentos, recursos materiais etc.
As estratgias explicam como os objetivos podem
ser atingidos. Especificam as aes propriamente
ditas. Uma das metodologias mais empregadas para
a identificao das estratgias a executar a anlise
de pontos fortes e fracos, ameaas e
oportunidades. Trata-se de modelo tradicional, mas
de grande utilidade prtica. Por sua vez o
oramento surge como sequncia montagem do
plano estratgico, permitindo colocar foco e

identificar, num horizonte menor, de um exerccio

fiscal, as suas aes mais importantes.
Nesse sentido, uma vez tendo feito um adequado
trabalho na montagem do plano estratgico, o
oramento tem muita chance de ser elaborado com
coerncia e consistncia. Caso os conceitos estejam
claros e entendidos pelos profissionais, o
oramento poder ser elaborado de maneira
adequada. composto pela seguinte sequncia de
elementos. (Figura 1.1):

a. Princpios gerais de planejamento a

necessidade estrutural. Na verdade, uma vez que
tais princpios no estejam sendo atingidos, o
processo de gerenciamento da organizao estaria
sendo negativamente afetado.
b. Diretrizes correspondem ao briefing da alta
administrao, direcionando as aes para vrios
segmentos. Em situaes em que a estabilidade do
ambiente macro grande, isso j foi feito no
momento de elaborar o plano estratgico.
c. Cenrios analogamente s diretrizes, em
situaes de estabilidade, j foram definidos no
momento da montagem do plano estratgico.
d) Premissas podem ser separadas em:
Operacionais = Referem-se s atividades
propriamente ditas. Entre as vrias premissas
existentes, destacam-se:
- Fatores de consumo de materiais e mo-de-obra;
143

- Hierarquia de produtos para perodo futuro;

- Estrutura organizacional do ponto de partida
- Reviso dos centros de custos e unidades de
negcios a detalhar no plano de contas - Tendncia
de obteno de insumos (importados ou adquiridos
localmente)
- Ponto de partida (saldos de balano, preos dos
produtos a comercializar, salrios, preos dos
insumos a comprar etc.);
De estruturao = Correspondem aos critrios
considerados, tais como moeda de deciso
utilizada, perodo de planejamento (janeiro a
dezembro, julho a junho, por exemplo).
Macroeconmicas = Tratam-se das premissas mais
conhecidas.
Correspondem a inflao, juros, variao dos preos
dos insumos, variao cambial etc. As premissas
devem estar prontas e definidas antes do incio da
montagem do oramento propriamente dito.
e) Plano de marketing indica a atividade comercial
da organizao, no que se refere o volume fsico de
venda, por perodo, por rea, por preo, etc. Deve
definir poltica de descontos, prazos, gastos com
comunicao e despesas comerciais previstas.
f) Plano de suprimentos, produo e estocagem
trata os estoques de produtos acabados, produtos
em processo e matrias-primas, produo prpria
e/ou terceirizada, suprimentos de materiais e
necessidade de mo-de-obra da organizao.
g) Planos de investimentos no ativo permanente
explicita os gastos que sero efetuados em
movimentaes (aquisies, vendas e baixas)
referentes a ativos do permanente da organizao.
h) Plano de recursos humanos deve tratar os
elementos referentes aos recursos humanos na
organizao, desde a estrutura organizacional, o
preenchimento dessa estrutura, movimentaes de
funcionrios,
remunerao,
treinamento,
admisses e desligamentos, consultorias na rea
etc.
i) Plano financeiro corresponde etapa do plano
em que as demonstraes financeiras so
disponibilizadas e a anlise global viabilizada. A
funo do plano financeiro consiste em permitir
que todas as decises tomadas nos vrios
subplanos sejam transformadas em um nico
denominador, no caso, o monetrio.

Uma forma de explicar ao empresrio que no

adianta fazer apenas o oramento, sem um plano
estratgico amadurecido, necessrio determinar
um planejamento estratgico e integr-los com
todas as unidades da empresa.
Controle Oramentrio
Controle oramentrio deve ser um instrumento
que permita organizao entender quo prximo
esto os resultados em relao ao que planejou
para dado perodo. Nessa abordagem, importante
definir e acompanhar o todo e as partes. Em outras
palavras, significa que metas da empresa podem ou
no ter sido atingidas (retorno sobre o
investimento, valor residual, lucro, gerao de
caixa, distribuio de dividendos etc.).
Tais metas so entendidas como macro no sentido
de que dependem do desempenho de todas as
reas da organizao. Por outro lado,
fundamental entender como foram atingidas, o que
s se pode entender com o detalhamento de
indicadores especficos de cada rea da
organizao. A realimentao do sistema de
planejamento corresponde a uma etapa
importante, j que o entendimento das variaes
permite aprimorar o processo de planejamento
(figura abaixo). Tomar conhecimento sem
desenvolver ao corretiva, quando necessrio,
pura perda de tempo e energia.
Na viso clssica de avaliao de desempenho,
eficincia e eficcia devem ser enfatizadas, j que
podem caminhar independentemente, embora
alguns autores considerem que o termo eficcia
possa (e deva) incluir o conceito de eficincia. Seria
o mesmo que dizer que eficcia sem eficincia seria
possvel por mero acaso ou sorte, nada garantindo
que possa refletir no futuro.
Eficcia entendida como quo b em o executivo
desenvolve o seu trabalho. Ela sempre estar
relacionada com os objetivos da organizao.
Eficincia significa quanto se produz, em
decorrncia dos insumos considerados, no
necessariamente relacionado com os objetivos da
organizao. Executivo eficiente o que minimiza o
consumo de recursos ou gera a maior quantidade
de produtos/servios, uma vez definidos os
recursos. Dessa maneira, dado colaborador pode
ter desempenho de grande eficincia e no
contribuir para que o objetivo da organizao seja
atingido. O que seria medido numa organizao? O
144

grau de eficincia uma permanente preocupao

dos executivos e pode ser percebido nos controles
sobre consumo de materiais, horas etc. Contudo,
de extrema importncia gerenciar tanto a eficcia
como a eficincia atingidas e a gerao de riqueza
sob a forma do lucro e caixa por unidade de
negcios pode ser a forma de monitor-las.

Prazo do Oramento
O horizonte do planejamento pode ir de um ano ou
menos h muitos anos, dependendo dos objetivos
do oramento e das incertezas existentes. Os
oramentos a longo prazo, chamados oramentos
de capital, so quase sempre preparados para
determinados Projetos como, por exemplo,
compras de equipamentos, localizao de fbricas e
introduo de linhas de produtos. Os oramentos
gerais, que consolidam os planos globais de uma
organizao num prazo mais curto, so geralmente
preparados anualmente. O oramento anual pode
ser subdividido em oramentos mensais ou, talvez,
em oramentos mensais no primeiro trimestre e
oramentos trimestrais nos trs trimestres
restantes.
Os oramentos contnuos esto sendo cada vez
mais usados. So oramentos gerais que vo
sempre acrescentando mais um ms que se
encerra. Os oramentos contnuos so teis porque
obrigam
os
administradores
a
pensar
especificamente nos prximos doze meses,
mantendo, com isso, um horizonte estvel de
planejamento.
Implantao do oramento
Numa organizao a implantao de um oramento
depende do envolvimentos de todas a unidades da
empresa. Os passos para a instalao so os
seguintes:
01. Criao de um setor que se encarregar de
implantar o sistema oramentrio.
02. Esse setor dever preparar todos os passos
necessrios para a instalao do processo.

03. Reunies com os membros da diretoria para a

definio das metas bsicas sobre as quais o
oramento vai ser estabelecido. Essas metas
podero ser traduzidas resumidamente pelos
seguintes pontos:
a) Participao no mercado;
b) Lucro lquido sobre as vendas;
c) Retribuio do investimento;
d) Assistncia aos empregados;
e) Ampliao das instalaes; e
f) Novos produtos e retirada de outros.
04. Levantamento de dados gerais, tais como
indicadores econmicos e sociais, tendncias da
indstria, na qual a empresa opera, e polticas do
governo.
05. Preparao de manuais de oramento, em que
devero constar os objetivos do oramento, os
diversos passos e as tcnicas de preparao das
estimaes.
06. Estimao das vendas em termos quantitativos.
As quantidades de cada produto a serem vendidas
devero ser analisadas por territrios de vendas e
mensalmente.
07. Estimaes das vendas em termos monetrios.
Os preos de venda devero ser determinados,
levando-se em conta o mercado. Essas estimaes
podero ser corrigidas no prprio trabalho de
preparao do oramento, depois que todos os
custos tenham sido previstos.
08. Estimaes das despesas de propaganda e das
despesas relacionadas atividade comercial.
09. Estimaes dos estoques da produo em
termos quantitativos.
10. Estimaes dos materiais a consumir, das
compras, da mo-de-obra necessria e dos custos
indiretos.
11. Estimaes das despesas administrativas.
12. Estimaes dos gastos de capital: aquisio e
alienao de ativos permanentes recuperaes e
manuteno.
13. Estimao das cobranas.
14. Estimao dos pagamentos a fazer com as datas
em que devero ser efetivados.
15. Estimao do fluxo de caixa.
16. Preparao da Demonstrao de Resultados,
por perodo.
17. Levantamento dos balanos mensais para
conhecimento da situao financeira e patrimonial
geral aps o decurso de cada perodo.
145

Classificao dos oramentos

Os termos usados para descrever diversos
esquemas de oramentos variam de uma empresa
para outra. s vezes, os oramentos so chamados
de demonstrativos projetados por serem
demonstrativos financeiros previstos, constatando
com os demonstrativos de resultados efetivos. Os
oramentos, acompanhados por demonstrativos
auxiliares, so divididos em dois grandes grupos
(ORAMENTO GERAL E RELATRIOS) e podem ser
classificados da seguinte maneira:
A) ORAMENTO DE INVESTIMENTOS
As etapas dos grandes projetos que integram o
plano de investimento de longo prazo programado
para o perodo coberto pelo oramento. Outros
investimentos de menor monta que devero iniciarse no perodo, relativos aos ativos fixos e s
instalaes, equipamentos, veculos, etc. de todas
as reas da empresa.
Cada investimento especfico costuma ser
submetido aprovao superior. As propostas
aprovadas tero seus desembolsos computados no
oramento de caixa, e seus valores contbeis
(Imobilizao e depreciaes) registrados nos
oramentos especficos.
B) ORAMENTO OPERACIONAL
O oramento operacional o que contm a maior
parte das peas oramentrias, pois engloba todos
os oramentos especficos que atingem a estrutura
hierrquica da empresa, englobando as reas
administrativa, comercial e de produo. O
oramento operacional equivale, na demonstrao
de resultados da empresa, s informaes que
evidenciam o Lucro Operacional, ou seja: vendas,
custo dos produtos, despesas comerciais e
administrativas.
Oramento de Vendas = Existe algumas dificuldades
da previso de Vendas, pois a preciso dos
programas estimados de produo e das tabelas de
custo depende do detalhamento e da exatido, em
valor e em quantidade, da previso de vendas. A
previso de vendas geralmente feita sob
superviso do principal executivo da rea de
vendas. Todos os seguintes fatores so
importantes: (1) padres passados de vendas; (2) as
estimativas feitas pelos vendedores; (3) as
condies gerais econmicas e de concorrncia; (4)
inter-relaes especficas entre vendas e
indicadores econmicos, como, por exemplo, o

produto nacional bruto ou ndices de produo

industrial; (5) variaes de preos; (6) estudos de
pesquisa de mercado; e (7) planos de propaganda e
promoo de vendas.
A previso de vendas em geral emprega vrias
tcnicas. Pedem-se opinies dos vendedores.
Muitas vezes, aplicam-se mtodos estatsticos. As
correlaes entre vendas e indicadores econmicos
ajudam a tornar as previses de vendas mais
confiveis. Na maioria dos casos, as anlises
quantitativas feitas por economistas e por tcnicos
da equipe de pesquisa de mercado do uma ajuda
valiosa, mas no respostas imediatas. As opinies
dos administradores de linha influenciam
sobremaneira as previses finais de vendas.
As polticas de preo podem ter efeitos
pronunciados sobre as vendas. A avaliao, pela
administrao, das elasticidades-preo (o efeito das
variaes de preo sobre o volume fsico vendido)
influencia a previso de vendas. Uma empresa pode
no cobrar o mesmo preo unitrio de todos os
fregueses (devido diferena de custos de
fornecimento para diferentes mercados).
Nesses casos preciso uma anlise detalhada tanto
das unidades a serem vendidas como do valor das
vendas para cada categoria de preo, para se poder
chegar a uma previso agregada final das vendas.
A previso de vendas ainda um pouco sujeita a
um certo misticismo, mas seus processos esto
ficando mais formais e esto sendo vistos com mais
seriedade por causa da intensidade das presses da
concorrncia.
Nos ltimos anos, a probabilidade estatstica tem
sido formalmente aplicada ao problema da previso
de vendas. Alm do mais, os modelos de
planejamento financeiro e a simulao tm
permitido aos administradores um entendimento
quantitativo dos desdobramentos de vrias
estratgias de vendas.
Oramento de Produo (para firmas industriais) =
totalmente decorrente do oramento de vendas.
O oramento de produo em quantidade dos
produtos a serem fabricados fundamental para a
programao operacional da empresa e temos dois
dados importantes para este oramento que so:
Oramento de vendas em quantidades por produto
e Poltica de estocagem de produtos acabados.

146