Modelagem SI PDF

Modelagem de Sistemas de
Informao
Vol. 1: Introduo
Uma Abordagem Prtica
Geraldo Xexo
Jos Antnio Moreira Xexo
Modelagem de Sistemas de Informao

Por Geraldo Xexo e Jos Antnio Moreira Xexo
Copyright 2002 Geraldo Xexo e Jos Antnio Moreira Xexo

Todos os direitos reservados e protegidos pela lei 5988 de 14/12/73.
Nenhuma parte deste livro, sem autorizao prvia por escrito dos
autores, poder ser reproduzida ou transmitida sejam quais forem os meios
empregados: eletrnicos, mecnicos, fotogrficos, gravao ou quaisquer
outros.
Todo o esforo foi feito para fornecer a mais completa e adequada
informao. Contudo, os autores no assumem responsabilidade pelos
resultados e uso da informao fornecida.
e-mail de contato: xexeo@ufrj.br, xexeo@acm.org
Sumrio
CAPTULO I. DESENVOLVENDO SISTEMAS DE INFORMAO ..............................1
CAPTULO II. SISTEMAS DE INFORMAO ................................ ............................2
II.1
DEFINIO ...................................................................................................2
II.2
VANTAGENS E DESVANTAGENS ........................................................................3
II.3
A EVOLUO DOS SISTEMAS DE I NFORMAO ................................ ....................3
II.3.1 Quatro Dcadas de Software................................ ................................ .......3
II.3.2 Modelo das Trs Eras de Ward ................................ ................................ ....4
II.4
CLASSIFICAO DOS SISTEMAS DE I NFORMAES ................................................5
II.4.1 Classificao hierrquica: ................................ ................................ ..........5
II.4.2 Classificao funcional:.............................................................................6
II.4.3 Classificao de Laudan ................................ ................................ ............7
II.5
OS SISTEMAS DO MODELO HIERRQUICO...........................................................7
II.5.1 Sistemas de Processamento de Transaes.....................................................7
II.5.2 Sistemas de Planejamento e Controle Operacional................................ ..........8
II.5.3 Sistemas de Planejamento e Controle Gerencial.............................................8
II.5.4 Sistemas de Planejamento Estratgico ................................ ..........................9
II.6
TAXONOMIA RELACIONADA A CLASSIFICAO DE ANTHONY ............................... 10
II.6.1 Sistemas de Informao para Executivos................................ ..................... 10
II.6.2 Comparao dos SIE com os SAD e SIG...................................................... 10
II.7
SITUAO ATUAL DOS SI NAS EMPRESAS................................ .......................... 11
CAPTULO III. DESENVOLVIMENTO DE SISTEMAS DE INFORMAO ................ 13
III.1
OBJETIVOS DO DESENVOLVIMENTO ................................................................. 13
III.1.1 O Princpio da Ausncia de Surpresas................................ ........................ 13
III.1.2 Direitos do Cliente e do Desenvolvedor...................................................... 14
III.2
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE .............................................. 15
III.2.1 A Necessidade de Garantir a Qualidade...................................................... 15
III.3
CICLO DE VIDA ........................................................................................... 16
III.3.1 Ciclo de Vida em Cascata......................................................................... 16
III.3.2 Prototipagem ......................................................................................... 17
III.3.3 Ciclos de Vida Evolucionrios................................................................... 18
III.3.4 Ciclo de Vida Win- Win ............................................................................ 19
III.3.5 Desenvolvimento Acelerado ...................................................................... 19
III.4
PROCESSO E MELHORIA DO PROCESSO ................................ ............................. 20
III.4.1 Inicial................................................................................................... 20
III.4.2 Repetitvel ................................ ................................ ............................. 20
III.4.3 Definido................................ ................................ ................................ 20
III.4.4 Gerenciado............................................................................................ 21
III.4.5 Otimizado ................................ ................................ ............................. 21
III.5
A EQUIPE DE DESENVOLVIMENTO................................................................... 21
III.6
LEITURA COMPLEMENTAR................................ ................................ ............. 23
CAPTULO IV. QUAL O TAMANHO DO SOFTWARE .............................................. 24
IV.1
QUAL O TAMANHO DO SISTEMA ? ................................ ................................ ..... 24
IV.2
PREO E CUSTO ................................ ................................ .......................... 24
IV.3
ESFORO E T EMPO DE DESENVOLVIMENTO ....................................................... 25
IV.3.1 Uma viso reduzida do modelo COCOMO II ............................................... 25
IV.3.2 Distribuio do Esforo........................................................................... 27
IV.4
O TAMANHO DO SOFTWARE........................................................................... 27
IV.5
ESTIMANDO O TAMANHO.............................................................................. 28
IV.5.1 A Tcnica de Delfos ................................ ................................ ................ 28
IV.5.2 Cenrios ............................................................................................... 29

IV.6
VERIFICANDO A SANIDADE DA ESTIMATIVA ...................................................... 29
IV.7
ANLISE DE P ONTOS DE FUNO .................................................................... 29
IV.7.1 Viso geral............................................................................................ 30
IV.7.2 Identificando Funes de Negcio.............................................................. 30
IV.7.3 Determinando a Complexidade................................ ................................ .. 32
IV.7.4 As Perguntas ......................................................................................... 33
IV.7.5 Clculo dos Pfs ...................................................................................... 34
IV.7.6 Os multiplicadores................................ ................................ .................. 34
IV.7.7 Utilizando Pfs para previses.................................................................... 34
CAPTULO V. UMA PROPOSTA INICIAL ................................ ................................ 40
V.1
O P RIMEIRO CONTATO E OS P RIMEIROS RESULTADOS ......................................... 40
V.2
O OBJETIVO DO SISTEMA .............................................................................. 40
V.3
METAS ...................................................................................................... 41
V.3.1 GQM Goal, Question and Metrics ........................................................... 42
V.3.2 Pontos Crticos ou Pontos Chave ............................................................... 42
V.4
LEVANTANDO OBJETIVOS EM ETAS ................................................................. 42
V.4.1 A solicitao do cliente............................................................................ 42
V.4.2 O sistema atual....................................................................................... 43
V.4.3 Problemas atuais .................................................................................... 43
V.4.4 Oportunidades para novos sistemas............................................................ 43
V.5
RESTRIES ............................................................................................... 43
V.6
ESTRUTURA DAP ROPOSTA I NICIAL ................................................................. 44
V.7
O RESUMO E XECUTIVO ................................................................................. 44
V.8
EXEMPLO DE DOCUMENTO ............................................................................ 45
V.8.1 Proposta Inicial...................................................................................... 45
V.8.2 Histrico da Software Legal...................................................................... 45
V.8.3 Solicitao do Cliente.............................................................................. 46
V.8.4 Descrio Sucinta do Sistema Atual............................................................ 46
V.8.5 Descrio do Sistema Proposto ................................................................. 47
V.8.6 Cronograma Provisrio ........................................................................... 47
V.8.7 Custo Provisrio................................ ................................ ..................... 48
V.8.8 Outras Clusulas.................................................................................... 48
CAPTULO VI. LEVANTANDO OS REQUISITOS................................ ..................... 49
VI.1
REQUISITOS FUNCIONAIS E NO FUNCIONAIS.................................................... 50
VI.2
REQUISITOS VERDADEIROS E FALSOS .............................................................. 51
VI.3
CONCEITOS E DEFINIES ................................ ................................ ............. 51
VI.4
AS TCNICAS DE ELICITAO ................................ ................................ ........ 52
VI.4.1 Abordagens voltadas para o sistema organizacional...................................... 53
VI.4.2 Abordagens voltadas para grupos.............................................................. 54
VI.4.3 Abordagens interativas............................................................................ 56
VI.5
A ENTREVISTA ............................................................................................ 57
VI.5.1 Entrevista por Questionrio ...................................................................... 58
VI.5.2 Entrevista Aberta .................................................................................... 59
VI.5.3 Entrevista Estruturada................................ ................................ ............. 59
VI.5.4 O processo da entrevista ................................ ................................ .......... 59
VI.5.5 Preparando a entrevista........................................................................... 60
VI.5.6 Realizando a entrevista............................................................................ 61
VI.5.7 O Comportamento do Entrevistador........................................................... 62
VI.5.8 Roteiro Bsico ....................................................................................... 63
VI.5.9 Documentando a Entrevista ...................................................................... 63
VI.5.10 As perguntas de concluso ...................................................................... 64
VI.6
JAD ................................ ................................ ................................ .......... 64
VI.6.1 O Objetivo do Mtodo ................................ ................................ ............. 65
VI.6.2 Os Componentes................................ ................................ ..................... 65

VI.6.3 A Dinmica ........................................................................................... 65
VI.6.4 O Ambiente............................................................................................ 66
VI.6.5 O Consenso ........................................................................................... 66
VI.7
A ABORDAGEM DE BOEHM ............................................................................ 66
VI.7.1 A Teoria W............................................................................................ 66
VI.7.2 O modelo de negociao ................................ ................................ .......... 67
VI.7.3 O modelo espiral WinWin ......................................................................... 67
Captulo I. Desenvolvendo Sistemas de

Informao
Esse livro apresenta algumas ferramentas destinadas ao desenvolvimento de
sistemas de informao baseadas em uma forma atualizada da Anlise Essencial.
A Anlise Essencial fornece conceitos importantes para que possamos nos guiar
na descoberta de todos os requisitos verdadeiros e para que evitemos a incluso de
requisitos falsos em nossos sistemas.
Sistemas de informao so sistemas interativos e reativos. Isso significa que
so sistemas que interagem com um ambiente externo, reagindo a mudanas nesse
ambiente. Segundo a anlise essencial, estamos interessados em sistemas que produzem
respostas planejadas , isto , que executam aes pr-programadas em funo de
mudanas reconhecveis e previsveis no ambiente externo. Chamamos essas mudanas
de eventos. No estamos interessados em respostas ad-hoc, isto , no estamos
interessados em respostas para eventos que no podem ser previstos, pois no podemos
program -las em um computador seguindo estas estratgias 1.
Para que tenhamos um sistema apenas com requisitos verdadeiros, imaginamos
que ele ser implementado com uma tecnologia perfeita. Assim, evitamos os requisitos
falsos causados pela tecnologia, seja ela passada ou antecipada. Em um sistema de
tecnologia perfeita, como diz o nome, os processadores so infinitamente velozes, no
gastam energia e no cometem erros, as memrias so infinitamente grandes, os dados
so transportados sem gastar tempo.
A seguir percorreremos um caminho que mostrar quais so nossos objetivos e
como eles podem ser alcanados de forma expedita.
Nesse caso, estaramos entrando no campo da Inteligncia Artificial.
Captulo II. Sistemas de Informao

Empresas bem sucedidas podem usar as Tecnologias da Informao para oferecer melhores produtos e
servios a preos mais baixos do que seus concorrentes.
Kenneth Laudon
Definio de Sistemas de Informao
Vantagens e Desvantagens
Perspectiva histrica
Classificaes
II.1
Definio
De forma objetiva, Um Sistema de Informao moderno coleta dados no ambiente

em que opera usando recursos de sensoria mento e telecomunicaes (entrada), analisa
essas informaes usando software e hardware (processo), e finalmente apresenta o
produto como informao til (sada).
Vrios autores j tentaram definir o que um Sistema de Informao. Algumas
dessas definies so as seguintes:
um sistema utilizado para coletar, armazenar, processar e apresentar informaes
para apoiar as necessidades de informaes de uma empresa (Shore [88]).
um conjunto de procedimentos organizados que, quando executados, provm
informaes para apoiar processos de tomada de decises e controlar a organizao
(Lucas [92]).
um sistema que prov procedimentos para registrar e tornar disponvel informao,
sobre parte de uma organizao, para apoiar atividades relacionadas com a prpria
organizao (Flynn [92]).
um conjunto de componentes interrelacionados utilizados para sentir, comunicar,
analisar e apresentar informaes com o propsito de melhorar nossa capacidade de
perceber, compreender, controlar e criar (Laudon [94]).
As definies no se referem automao ou a computadores. Sistemas de
Informao existem h muito tempo. Cada autor destaca o que julga de maior relevncia
em sua definio; todos, entretanto, exploram a existncia de um processo que nasce na
busca e obteno da informao e termina por uma interpretao, seja ela programada em
um sistema computacional , ou executada depor um ser humano. Isso demonstra,
portanto, que o bom desempenho dos Sistemas de Informao depende da qualidade das
informaes que os alimentam e da capacidade de interpretao dos responsveis pelas
decises.
Atentamos, porm, para o fato que um sistema atinge muito mais pessoas que
seus usurios. A qualquer dessas definies, deveramos incluir a afirmao: construdos
de forma a atender os interesses da empresa, de seus clientes internos e externos e de
todos aqueles atingidos direta ou indiretamente pelo novo produto.
II.2
Vantagens e Desvantagens
Os benefcios e os custos resultantes do uso dos computadores nas empresas

apresentam-se de vrias formas, que so relacionadas ao ponto de vista de quem analisa.
Vantagens para uns, muitas vezes so desvantagens para outros. Custos e investimentos
so muitas vezes confundidos.
Apesar de ser quase inimaginvel uma empresa de algum porte sem sistemas
informatizados, interessante citar algumas vantagens amplamente aceitas do uso de
sistemas de informao:
maior eficincia: principalmente no custo, na preciso e na velocidade dos processos
organizacionais.
maior eficcia 2: com efeito na viso externa da empresa, incluindo a participao no
mercado e o atendimento aos desejos dos clientes.
maior controle sobre as operaes;
melhor planejamento e organizao das atividades;
melhores decises, baseadas em melhores informaes;
menor dependncia de processos intensivos em mo de obra no especializada.
reduo das linhas de comunicaes;
garantia da informao correta no lugar correto no momento correto;
aumento do conhecimento sobre o ambiente;
proviso de servios novos ou adicionais, e
viso completa dos clientes e consumidores;
Reconhecemos, porm, que a adoo de Sistemas de Informao tambm pode
gerar alguns impactos negativos na estrutura do trabalho. Principalmente os autores
preocupados com o impacto do uso da computao na sociedade, citam problemas como:
desemprego tecnolgico;
isolamento das pessoas provocado pela maior autonomia das pessoas em relao aos
servios de apoio e as possibilidades criadas para o trabalho distncia, at mesmo
em grupo;
empobrecimento da funo;
intensificao do trabalho;
reduo do nvel de autonomia;
ruptura da viso de conjunto;
acessas a privacidade, e
aumento do controle.
II.3
A Evoluo dos Sistemas de Informao
II.3.1 Quatro Dcadas de Software

O progresso do software caracterizou quatro pocas bem distintas.
A maioria dos dicionrios no diferencia eficincia de eficcia, o que comumente feito na

administrao.
de 50 a meados de 60 prevaleceu aplicao customizada com distribuio limitada.

O prprio usurio desenvolvia seu sistema - quase sempre um sistema simples. Esse
processo quase informal no exigia qualquer tcnica de projeto, controle de qualidade
ou documentao. Sistemas (hardware e software) eram criados um a um e
intimamente ligados.
entre meados de 60 e o final da dcada de 70 vimos chegar os sistemas de tempo
real, os bancos de dados, o software produto e as software-houses. A complexidade
aumentou. A distribuio atingiu milhares de cpias. A manuteno passou a ser
exigida, pois os erros tinham que ser consertados e as modificaes especificadas
pelos usurios precisavam ser introduzidas. O software passou a ser importante.
Seus custos chegavam a atingir 80% do custo total do sistema.
a terceira fase foi at final dos 80 e assistiu o advento do micro processador e a
difuso em larga escala dos computadores pessoais. O hardware transforma -se em
commodity. O elemento de diferenciao passa a ser o software, ele que importa.
a quarta fase est s comeando, mas os sistemas especialistas, a computao
paralela, os sistemas de multimdia e principalmente a Internet, introduziram graus de
complexidade nunca imaginados.
De forma mais informal, podemos dizer que passamos das mquinas

especializadas para os computadores de grande porte, desses para os computadores
mdios e de time-sharing, que forma praticamente dizimados pela invaso dos
microcomputadores, e finalmente para a poca de computao na rede.
II.3.2 Modelo das Trs Eras de Ward

Ward sugere que devemos analisar no a forma em que os sistemas esto
implementados, mas sim seu uso, identificando que trs grandes eras: processamento de
dados, informao gerencia l, e a era dos sistemas de informao estratgica (figura 3.2).
era do processamento de dados : a eficincia era o objetivo principal e a automao
de procedimentos operacionais seu instrumento. Os sistemas eram orientados para o
processamento de transaes.
era dos sistemas de informao gerencial: a eficincia da organizao mantida
como objetivo, mas a orientao dos sistemas passa para o fornecimento de
informaes. A mudana foi facilitada pelo advento dos microcomputadores, das
redes e pela introduo das funes de consulta para apoiar os sistemas de suporte
deciso.
era dos sistemas de informao estratgicos: os sistemas so voltados para o
aumento da competitividade das organizaes, pela mudana que introduzem na
natureza ou maneira de conduzir o negcio.
H estimativas de que os investimentos futuros em SI sero repartidos da seguinte
forma: 50% para sistemas de PD, 30% para sistemas de informaes gerenciais e apenas
20% para sistemas de informaes estratgicas. O retorno, entretanto, ocorreria na
proporo inversa.
1960
1970
1980
1990
Processamento de Transaes

Informaes Gerenciais

Informaes Estratgicas

Figura 1. As eras de Ward [90] (fonte: Ward [90])
A categorizao das eras no determina seus limites com preciso. H

convivncia dos diferentes tipos de amb iente em vrios setores, inclusive na mesma
organizao. fato comum dois departamentos distintos de uma mesma empresa estarem
em nveis de amadurecimento em relao ao emprego das TI totalmente diferentes. Esse
fator preponderante na escolha ou especificao dos Sistemas de Informao da
empresa. Em geral, quanto menos envolvidos com as TI estiverem a estrutura
organizacional e as pessoas que a compe, mais investimento nos sistemas com foco na
eficincia administrativa.
II.4
Classificao dos Sistemas de Informaes
As organizaes utilizam SI para aplicaes desde processamento de transaes

at apoio a processos de tomada de deciso. A cadeia de aplicaes to extensa que as
caractersticas dos SI variam acentuadamente. Objetivos, software, hardware, usurios,
custos e benefcios, tudo diferente. Sistemas que tratam de rotinas administrativas como
folha de pagamento ou contas a pagar, so intrinsecamente diferentes dos sistemas, por
exemplo, de vendas on-line integradas com o processo de produo. Sistemas operados
em tempo real so essencialmente diferentes de sistemas com respostas baseadas em
anlise estatstica de sries histricas.
H vrias maneiras de classificar e descrever SI. Essas classificaes, entretanto,
no podem ser vistas com exagerado rigor. Sofrem as mais diversas influncias,
principalmente dos interesses do observador. As superposies sempre ocorrem e a
utilidade dos SI varia com o contexto e, portanto, muda ao longo do tempo.
Duas dessas classificaes so mais difundidas. A primeira delas a hierrquica,
que est ligada aos nveis organizacionais onde o SI utilizado. A segunda - funcional relaciona-se s atividades desenvolvidas por seu usurio e baseia-se na classificao de
Anthony [65]. Apresenta-se uma terceira, proposta por Laudon [94], que altera a estrutura
hierrquica tradicional das empresas face s modificaes introduzidas pela era da
informao.
II.4.1 Classificao hierrquica:
A classificao hierrquica contm 4 nveis ou tipos de sistemas:

sistemas de apoio ao planejamento estratgico
sistemas de apoio ao planejamento e controle gerencial
sistemas de apoio ao planejamento e controle operacional
sistemas de processamento de transaes
Cada um desses tipos est associado s atividades do nvel correspondente, assim:
5
Planejamento Estratgico: refere -se ao processo de decidir sobre os objetivos da

organizao, sobre as mudanas desses objetivos, sobre os recursos que sero
utilizados para alcanar esses objetivos e sobre as polticas que governam a aquisio,
o uso e a disponibilidade desses recursos.
Controle Gerencial: processo pelo qual gerentes asseguram que os recursos so
obtidos e utilizados de forma eficiente e efi caz para alcanar os 7objetivos
organizacionais. Ocorre de acordo com um conjunto de polticas derivadas do
planejamento estratgico.
Controle Operacional: processo de assegurar que tarefas especficas esto sendo
executadas de maneira eficiente e eficaz. Ocorre de acordo com um conjunto de
procedimentos e regras bem definidas derivadas tanto do planejamento estratgico
quanto do controle gerencial.
Os trs processos citados utilizam informaes com caractersticas diferentes.

Essas informaes so geradas por SI que tambm tm caractersticas distintas.
As informaes usadas por atividades prximas ao controle operacional so mais
detalhadas, tm freqncia de utilizao elevada, so normalmente obtidas no interior das
organizaes e relatam sobre um horizonte de tempo histrico. As mais prximas do
planejamento estratgico so mais agregadas, obtidas no ambiente externo, referem-se ao
futuro e tm baixa freqncia de utilizao.
II.4.2 Classificao funcional:
Apresenta quatro tipos de sistemas:

sistemas de informao para executivos
sistemas de apoio deciso
sistemas de informaes gerenciais
sistemas de processamento de transaes
Cada um desses tipos est associado s atividades da funo do usurio, assim:
Sistemas de Informao para Executivos (SIE): prestam apoio s atividades de
Planejamento Estratgico. Segundo Furlan et alli [94], os SIE integram informaes
de fontes internas e externas e, atravs de uma interface amigvel, apresentam as
informaes crticas de modo personalizado, com acesso simplificado, de forma a
proporcionar aos executivos interessados as informaes necessrias para gerenciar o
negcio.
Sistemas de Apoio Deciso (SAD): prestam apoio s atividades de Controle
Gerencial. So considerados uma evoluo dos SIG. Tratam de problemas menos
estruturados que aqueles tratados pelos SIG. Focalizam decises, enfatizando
flexibilidade, adaptabilidade e capacidade de fornecer respostas rpidas (Blaschek
[95]).
Sistemas de Informao Gerencial (SIG): tambm prestam apoio s atividades de
Controle Gerencial. Tratam de problemas bem estruturados e so menos flexveis e
adaptveis que os SAD. Focalizam a informao, que organizada em fluxos
estruturados e colocada disposio dos usurios por meio de relatrios ou consultas
a banco de dados.
Sistemas de Processamento de Transaes (SPT): prestam apoio s atividades de
Controle Operacional. Base dos SIGs, estabelecem procedimentos para registrar e
6
tornar disponveis informaes sobre a ocorrncia de eventos operacionais especficos

e autocontidos, das diversas reas da organizao (Flynn [92]).
II.4.3 Classificao de Laudan
Laudon [94], considerando os novos parmetros introduzidos pela era da
informao, modifica a estrutura proposta na hierarquia da estrutura organizacional de
Anthony [65], introduzindo o nvel da administrao da informao. Os profissionais
includos nesse nvel seriam de dois tipos: os processadores da informao (digitadores,
secretrias com conhecimento de processador de textos, agentes administrativos e
assistentes comerciais com acesso a bancos de dados de PCs, etc.) e aqueles que criam
novas informaes e conhecimento baseados em suas especialidades e experincias
(engenheiros operando sistemas de anlise estatstica ou sistemas de sntese de circuitos
eletrnicos; administradores e economistas simulando aes de logstica, ou projees
financeiras, etc.)
NVEIS
ORGANIZACIONAIS
SISTEMAS DE INFORMAO
GERENCIAL
DE APOIO GERENCIAL
ADMINISTRAO
DE APOIO AO
DA INFORMAO
CONHECIMENTO
PRODUO
PROCESSAMENTO
DE TRANSAES
Tabela 1. Organizao e sistemas de informao segundo Laudon

[94]
Em sntese, a proposta de Laudon classifica os sistemas em::

Sistemas de Apoio Gerencial: servem s necessidades gerenciais para o
planejamento e controle da organizao;
Sistemas de Apoio ao Conhecimento: serve s necessidades dos profissionais
responsveis pelo processamento e criao de informao e conhecimento;
Sistemas de Processamento de Transaes
II.5
Os Sistemas do Modelo Hierrquico
II.5.1 Sistemas de Processamento de Transaes

Os sistemas de processamento de transaes guardam e processam dados sobre as
atividades de rotina dos negcios. As operaes baseiam-se em procedimentos
operacionais padronizados que estabelecem exatamente como dar entrada nos dados,
process-los e apresentar os resultados.
So exemplos:
transaes bancrias automticas em mquinas ATM tais como aplicaes,
transferncias entre contas-correntes e saques;
processamento de informaes sobre diversos tipos de chamadas e emisso de contas
telefnicas mensais;
Formatted: Font: Bold
processamento de folhas de pagamento e emisso de contracheques.
As caractersticas desses sistemas de processamento de transaes que se

destacam so:
forte estruturao;
estabilidade de processo;
tratamento eficiente das rotinas;
operao por pessoal no especializado, com pouca ou nenhuma responsabilidade
gerencial;
exigncia de poucas decises dos operadores;
tratamento de um grande e detalhado volume de dados em pouco espao de tempo,
muitas vezes em tempo real.
II.5.2 Sistemas de Planejamento e Controle Operacional

Ao contrrio dos sistemas de transaes, que tratam da rotina, os sistemas de
planejamento e controle operacional focalizam as decises que precisam ser tomadas
para planejar e controlar as operaes dirias da empresa. Como instrumento de
planejamento, so usados para organizar e programar a fora de trabalho, materiais,
facilidades e os fundos necessrios para atender a demanda de curto prazo para os
produtos e servios da empresa.
Freqentemente as informaes tomam a forma de um relatrio padronizado que
resume a situao de um processo ou atividade. Por exemplo: em fabricao, sistemas de
planejamento e controle apoiam o processo de desenvolvimento de programa de
produo diria; o responsvel por uma programao de produo pode examinar as
conseqncias de uma possvel soluo, realizar ajustes, entrar com novos dados,
examinar a nova soluo e continuar com esse processo at decidir por uma soluo
satisfatria
Segundo Shore [88], sistemas de planejamento e controle operacional:
so utilizados em ambientes mais complexos que os ambientes de processamento de
transaes;
apiam o planejamento e o controle dirios dos processos operacionais;
esto sujeitos a interaes e modificaes;
so operados por profissionais responsveis por operaes dirias;
interagem com usurios e requerem que faam escolhas;
manipulam grande quantidade de dados de razovel detalhamento, derivados das
operaes dirias, e muito sensveis aos prazos de utilizao.
II.5.3 Sistemas de Planejamento e Controle Gerencial

O ambiente de tomada de decises nesse nvel complexo e no estruturado e
muitas vezes exige a adoo de processos passo a passo para a soluo de problemas.
Para acomodar as ambigidades resultantes, os sistemas so desenvolvidos para permitir
a interao com o usurio. Sendo assim, as decises nesse nvel carregam contedo de
julgamento e intuio do responsvel pela deciso.
A diferena mais significativa entre os sistemas de planejamento e controle
operacional e os sistemas de planejamento e controle gerencial parece estar exatamente
nas caractersticas que envolvem o processo decisrio, muito menos estruturado nesses
ltimos. A simulao descrita anteriormente para exemplificar o tipo de apoio dado
deciso por aqueles , na verdade, um processo de otimizao e a deciso no contm
julgamento. H uma anlise de alternativas nas quais vantagens e desvantagens esto
muito claramente explicitadas e quantificadas, proporcionando deciso muito bem
justificada.
Em resumo, as caractersticas principais de sistemas de planejamento e controle
gerencial so:
desenvolvimento em ambientes complexos e de baixa estruturao;
apoio ao processo de planejamento de nvel intermedirio - envolvendo perodos
futuros de at seis meses - detalhando informaes sobre o desempenho da empresa;
utilizao por gerentes de nvel intermedirio responsveis por planejamento e
controle;
envolvimento dos usurios em decises baseadas em julgamento independente;
considerao da incerteza no ambiente de planejamento;
trabalho com dados agregados, oriundos tanto da organizao com de fontes externas.
II.5.4 Sistemas de Planejamento Estratgico

Decises estratgicas so tomadas nos nveis mais elevados da organizao e,
geralmente, tm grande impacto no futuro dos negcios da empresa. Sistemas de
planejamento estratgico fornecem informaes para apoiar os gerentes de alto nvel a
tomar decises com foco nas questes que afetam a capacidade da empresa competir, a
longo prazo, nos mercados de produtos e servios em que opera.
Segundo Shore [88], as principais caractersticas desse tipo de sistema so:

adequados para estudo de problemas estratgicos de longo prazo;
usados por executivos responsveis por decises a respeito das metas e objetivos
globais da organizao;
necessidade de decises independentes;
uso de dados consolidados e fontes externas
Earl [89] considera que um SI tem potencial estratgico se possibilita a obteno

de vantagens competitivas, aumenta a produtividade e desempenho da organizao,
proporciona novas formas de gerenciar e organizar e viabiliza o desenvolvimento de
novos negcios.
Krcmar [91] considera que sistema de informao estratgico uma aplicao que
gera vantagens competitivas ou que pelo menos o mantenha em uma posio prxima a
de seus competidores.
King [92] considera que um SI estratgico se possui um efeito profundo no

sucesso ou destino da organizao.
Senn [92] considera que um SI tem seu valor estratgico determinado pelo uso
que dele feito e no pelos tipos em que est classificado.
Blaschek [95] identificou vrias classificaes para SIs Estratgicos:

quanto ao impacto nos negcios atuais e futuros da empresa (McFarlan [83])
quanto ao uso estratgico de SI/TI (Ward [90])
quanto aos fatores que diferenciam os sistemas de identificao de oportunidades de
uso estratgico de SI/TI dos sistemas tradicionais (Ward [90])
quanto aos efeitos para a competitividade das organizaes (Porter [85])
quanto aos nveis da estratgia corporativa afetados (Sabherwal [91])
II.6
Taxonomia Relacionada a Classificao de Anthony
II.6.1 Sistemas de Informao para Executivos

Sistemas de Informao para Executivos (SIE) prestam apoio s atividades de
Planejamento Estratgico da classificao de Anthony.
Os SIE visam integrar em um nico sistema de informaes todas as informaes
necessrias para que o executivo possa verific-las de forma numrica, textual, grfica ou
por imagens. Passa a ser possvel verificar informaes desde o nvel de maior
consolidao at o nvel mais analtico, de forma rpida e segura, proporcionando melhor
conhecimento e controle da situao e maior agilidade e segurana no processo decisrio
(Furlan [94])
Suas caractersticas principais so:

uso nos nveis mais elevados da organizao;
foco em acompanhamento e controle;
utilizao de indicadores de desempenho;
uso intensivo de recursos grficos;
apoio aos processos de tomada de decises crticas;
exigncia de pouco treinamento.
Os benefcios ao processo de tomada de deciso so, principalmente:

acesso mais rpido e direto s informaes estratgicas;
melhoria da qualidade de comunicao;
aumento do grau de segurana na deciso.
II.6.2 Comparao dos SIE com os SAD e SIG

Os SIE e os SAD tratam de problemas distintos. Os SIE destinam-se alta
gerncia enquanto que os SAD auxiliam as gerncias intermedirias. Os SAD podem ser
considerados uma evoluo dos SIG, resolvendo problemas menos estruturados. As
10
principais diferenas, como listadas por R. Sprague e apresentadas em Furlan [94], so as

seguintes:
DIMENSO
SIE
SAD
SIG
Foco
Indicadores de
Anlise
Processamento
gerncia
Gerncia
Desempenho
Usurio
Executivos
intermediria
Intermediria
Objetivo
Estratgico
eficcia
Eficincia
Aplicao
Acompanhar FCS
tomada de deciso
Controle de
banco de dados
Diversos
especial
Do sistema
tratamento da
Filtra e resume
usa info dos
Relatrios
SIG e SIE
Resumidos
Produo
informao
Tabela 2. Diferenas essenciais entre SIE, SAD e SIG (fonte:

Furlan [94])
II.7
Situao atual dos SI nas empresas
Atualmente a maioria das empresas trabalha com Sistemas de Informao

baseados em pacotes reconhecidos no mercado. As atividades bsicas de cada empresa
so normalmente cobertas com sistemas ERP Enterprise Resource Planning, cujo
objetivo integrar todos os departamentos e funes de uma empresa em um sistema
nico.
O lder do mercado SAP R/3, por exemplo, apresenta os seguintes mdulos, que
podem custar milhes de dlares para uma empresa:
PP (Production Planning)
MM (Materials Manageme nt)
SD (Sales and Distribution)
FI (Financial Accounting)
CO (Controlling)
AM (Fixed Assets Management)
PS (Project System)
WF (Workflow)
IS (Industry Solutions)
HR (Human Resources)
PM (Plant Maintenance)
QM (Quality Management)
Apesar do nome, ERP no permitem o planejamento. Para isso so necessrios
outros produtos, que precisam dos dados dos ERP para funcionar. Finalmente, para
11
tomada de decises so ainda necessrios outros produtos, cujo nome mais em voga no
mercado Business Intelligence.
12
Captulo III. Desenvolvimento de Sistemas

de Informao
More people have ascended bodily into heaven than have shipped great software on time
Jim McCarthy in Dynamic of Software Development
Tpicos Abordados
Objetivos do Desenvolvimento
Princpio da Ausncia de Surpresas
Verificao
Validao
Processo de Software
Ciclo de Vida (Seqencial, Prototipagem,
Evolutivo, Espiral)
Equipe de Desenvolvimento
III.1 Objetivos do Desenvolvimento

O objetivo de desenvolver um sistema de informao atender todas as
expectativas, explcitas ou implcitas, proferidas ou no, de todos os usurios do sistema,
no tempo previamente acertado.
Desenvolver software, mesmo em pequena escala, envolve muitos interesses. Um
sistema deve ter um preo que atenda simultaneamente as expectativas do comprador e
do vendedor. O produto deve cumprir vrias tarefas, de acordo com a necessidade do
usurio e deve ser entregue em um prazo determinado. Desenvolvedores normalmente
esto interessados no desafio do desenvolvimento propriamente dito. Algumas pessoas
nunca vero o sistema, mas so afetados por seu funcionamento. Aps pronto, algumas
pessoas ficaro responsveis pela instalao do sistema, outras pela sua manuteno,
outras pela sua operao diria. Cada um desses personagens tem interesses prprios e
vises diferentes do que um sistema de qualidade.
Dessa forma, o que fazemos normalmente ao desenvolver o sistema buscar uma
soluo de compromisso. Procuramos desenvolver sistemas que possuem uma boa
relao custo/benefcio, que possam ficar prontos em prazo hbil e que atendam as
principais expectativas de seus usurios.
III.1.1 O Princpio da Ausncia de Surpresas
Esse princpio{GUIDE MVS Group 1998 ID: 1150}, proposto pelo GUIDE MVS
group, essencialmente auto-explanatrio. O princpio conservado quando o produto:
faz o que o usurio espera
responde de forma previsvel e consistente aos estmulos
se comporta de forma limitada a sua razo de existncia
regular e mnimo, apesar de completo
13
quando falha, o faz de forma graciosa e recupervel

quando a dificuldade de utiliz -lo ou modific-lo e compatvel com a
dificuldade da rea de aplicao
Essa uma importante filosofia e que, junto com os princpios da modelagem

essencial apresentados mais tarde, servir de guia para todo o nosso processo de
desenvolvimento. Cada vez que tivermos que tomar uma deciso relacionada ao sistema,
ser nesses princpios que buscaremos a nossa resposta.
III.1.2 Direitos do Cliente e do Desenvolvedor
Segundo {McConnell 1998 1922 /id}, uma das formas de garantir o sucesso de
um projeto de desenvolvimento de software conhecer e garantir os direitos do cliente e
do desenvolvedor.
Direitos do Cliente
1. Determinar os objetivos do projeto, e ter eles seguidos
2. Saber quanto tempo o projeto vai levar e quanto dinheiro ele vai custar
3. Decidir que caractersticas vo e no vo fazer parte do software
4. Fazer mudanas razoveis nos requisitos durante o curso do projeto e saber os
custos de realiz-las
5. Saber o status do projeto de forma clara e confidencial
6. Ser informado regularmente dos riscos que podem afetar custo, prazos e
qualidade, com opo para resolver os problemas potenciais
7. Ter acesso imediato aos resultados do projeto
Direitos da equipe de desenvolvimento
1. Conhecer os objetivos do projeto e ter as prioridades clarificadas
2. Saber em detalhes que produtos deve ser construdo e poder clarificar a
definio se ela no for clara.
3. Ter acesso imediato ao comprador, gerente ou qualquer outra pessoa
responsvel por tomar deciso sobre a funcionalidade do projeto
4. Trabalhar cada fase do projeto de uma forma tecnicamente responsvel, no
sendo forado a codificar muito cedo
5. Aprova as estimativas de tempo e esforo para todo o trabalho que for
solicitado a fazer, incluindo o direito de dar apenas as estimativas
teoricamente possveis no estgio do projeto e revisar as estimativas quando
possvel e necessrio.
6. Ter a situao do seu projeto relatada de maneira precisa aos clientes e a
gerncia
7. Trabalhar em um ambiente produtivo, longe de distraes e interrupes,
principalmente nas fases crticas do projeto
14
III.2 Processo de Desenvolvimento de Software

No Processo de Desenvolvimento de Software realizamos as atividades de criao
do produto de software propriamente dito. Basicamente, podemos dividir as atividades do
processo de desenvolvimento em 3 grandes grupos:
Atividades de Anlise, cuja finalidade descobrir o que deve ser feito
Atividades de Projeto, cuja finalidade descobrir como o software deve ser feito
Atividades de Implementao, cuja finalidade produzir o produto de software de
acordo com as especificaes produzidas nas fases anteriores.
Atividades de Controle de Qualidade, onde se incluem todas as atividades com
objetivo de garantir a qualidade do produto, como testes e verificaes.
De acordo com o processo de desenvolvimento escolhido, cada uma dessas
atividades pode ser dividida em vrias outras sub-atividades ou tarefas. Tambm
possvel que as atividades de anlise e projeto sejam feitas de forma implcita, por
exemplo, quando desenvolvemos o software unicamente por meio de prottipos.
Dependendo do grau de formalidade do processo de desenvolvimento, que deve
ser escolhido em funo da complexidade do produto final, diferentes atividades so
desenvolvidas nas fases de anlise, projeto e implementao. Enquanto um produto para
um nico usurio pode ser feito por meio de prottipos, sem nenhuma fase bem-definida,
produtos muito grandes, como um sistema de informaes para toda um empresa,
necessitam ser realizados em passos muito bem planejados.
III.2.1 A Necessidade de Garantir a Qualidade
Desenvolver software um processo de transformao de uma necessidade do
cliente em uma seqncia de produtos de software (anlise, projeto, prottipo, manuais)
que tem em seu fim um programa de computador. Essas transformaes so imperfeitas,
devidos a problemas de comunicao entre o usurio e o desenvolvedor e falhas nas
tcnicas utilizadas pelo desenvolvedor para garantir que nenhuma informao perdida
ou inserida de forma espria no sistema.
Para garantir que o sistema faz o que o usurio deseja, utilizamos duas tcnicas: a
vrificao e a validao. Verificar significa analisar se o produto de uma fase do processo
de desenvolvimento est de acordo com sua especificao. Validar significa analisar se o
produto de uma fase do processo de desenvolvimento est de acordo com as expectativas
do cliente.
Precisamos ter claro em nossa mente a diferena entre as duas atividades. Quando
transformamos um algoritmo em portugus para pascal, por exemplo, podemos fazer isso
de forma perfeita e, ao mesmo tempo, fazer algo que o cliente no deseja. Quando
validamos um programa com o cliente e o aprovamos, no necessariamente o que
fizemos foi o que estava escrito na especificao do programa.
A tarefa mais importante, na verdade, a validao, j que devemos atender o
cliente. A validao, porm, geralmente mais informal e mais custosa que a verificao.
Assim, verificando que cada passo dado durante o processo de desenvolvimento esta
conforme o passo anterior previu podemos economizar na validao.
15
III.3 Ciclo de Vida

Consideramos o Ciclo de Vida do software a forma como as atividades do
Processo de Desenvolvimento de Software so implantadas, isto , qual a seqncia em
que software desenvolvido.
III.3.1 Ciclo de Vida em Cascata
Tambm conhecido como Linear Sequencial. Nesse ciclo de vida, assuminos que
as atividades de anlise, projeto e implementao podem ser feitas de forma seqncial,
sem que sejam necessrias interaes entre as fases.
Um ciclo de vida em cascata tpico contaria com as seguintes fases:
1. Modelagem do Sistema, onde so estabelecidos os requisitos do
sistema do qual o software sendo realizado participa, incluindo os requisitos de
informao e de negcios.
2. Anlise de Requisitos, onde so modeladas os requisitos de
informao, funcionais, comportamentais, de desempenho e de interface do
software..
3. Projeto, onde so planejadas as estruturas de dados, a arquitetura do
sistema e o comportamento mapeado em procedimentos.
4. Codificao, onde o projeto transformado em uma linguagem
inteligvel pelo computador
5.
Testes, onde verificamos e validamos o software
6.
Manuteno, onde garantimos a utilizabilidade do software
Esse Ciclo de Vida, defendido inicialmente como a forma correta de desenvolver

software, basicamente impossvel de ser realizado. Podemos encontrar alguns exemplos
de sucesso em casos onde o produto sendo desenvolvido e o ambiente de
desenvolvimento so muito bem conhecidos.
Devido a diviso radical entre as fases, dada grande nfase a documentao.
Inicialmente assumia-se que cada fase seria executada por uma equipe distinta de
especialistas, fato que est se tornando mais raro hoje em dia. Tambm haviam
discusses sobre at que ponto deveria ir o projeto e onde comeava codificao. De
acordo com a complexidade do sistema, muitas vezes as fases de codificao e testes
eram dividas em codificao e teste de unidades e integrao e testes de integrao.
Entre os principais defeitos desse ciclo de vida est o fato que o cliente s v o
produto final no ltimo dia do desenvolvimento. Assim, impossvel detectar falhas ou
atender demandas imediatas do cliente. Alm disso, a participao do usurio muito
baixa.
16
Anlise
Projeto
Codificao
Testes
Figura 2. O Ciclo de Vida em Cascata ou Seqencial
III.3.2 Prototipagem
No Ciclo de Vida de Prototipagem (pura) o desenvolvedor interage diretamente
com o usurio, escutando seus pedidos e desenvolvendo, imediatamente, um prottipo do
produto desejado. O usurio ento utiliza esse prottipo e fornece ao desenvolvedor
novas informaes que o levam a modificar o prottipo, de maneira a atender todas as
necessidades do usurio.
claramente um processo de desenvolvimento baseado em um ciclo de
realimentao de informaes, com alta participao do usurio.
No existe uma fase formal de anlise ou projeto. Isso pode causar problemas
graves e difceis de corrigir no produto final, dificultando de sobremaneira a manuteno
dos produtos. Pouca nfase dada a documentao.
Atualmente quase todos os ciclos de vida utilizam prottipos, mas no um ciclo
de vida de prototipagem. Existem vrios tipos de ciclo de vida com prototipagem.
Usamos prottipos descartveis quando o prottipo usado apenas para levantar alguns
ou todos requisitos e depois abandonado, em troca de uma implementao mais
organizada. Um prottipo operacional um software feito rapidamente para atender
uma demanda do usurio e que usado, mais tarde, como modelo de especificao para
uma nova implementao do sistema.
Alguns autores diferenciam prottipos de mock-up. Um prottipo
apresentaria o comportamento correto, ou aproximadamente correto, e seria caracterizado
principalmente pela falta de rigor na implementao. Um mock-up apresentaria apenas
uma interface que serviria como prvia da interface final.
17
Contruo ou
Reviso do
Prottipo
Avaliao
do Prottipo
Escutar
o
Cliente
Figura 3. O Ciclo de Vida de Prototipagem
III.3.3 Ciclos de Vida Evolucionrios

Os modelos de ciclo de vida evolucionrios reconhecem que sistemas complexos
se alteram com o tempo, usando a iterao do ciclo de desenvolvimento para acompanhar
a evoluo do sistema.
Ciclo de Vida Incremental
Pode ser visto como combinando o linear com a prototipagem. Tem o foco
principal na entrega do produto. Para realiz-lo, repetimos a seqncia linear em vrias
calendrios defasados no tempo. Busca implementar funcionalidades essenciais o mais
cedo possvel.
Anlise
Projeto
Codificao
Testes
Anlise
Projeto
Anlise
Codificao
Projeto
Testes
Codificao
Anlise
Projeto
Codificao
Testes
Tempo
Testes
Figura 4. O Ciclo de Vida Incremental
Ciclo de Vida Espiral

O Ciclo de Vida Espiral se caracteriza pelo desenvolvimento por uma srie de
produtos desenvolvidos em seqncia, cada vez mais complexos e mais prximos do
produto final desejado. Ele se diferencia do ciclo de vida incremental porque os produtos
de cada ciclo no so sub-sistemas do sistema original, mas sim produtos especficos
que atendem necessidades especficas do projeto, como por exemplo teste de
viabilidade e definio da interface com o usurio.
18
Em cada ciclo da espiral, algumas ativades so realizadas em ordem seqncial:

comunicao com o cliente, planejamento, anlise de riscos, engenharia, construo e,
finalmente, avaliao dos resultados.
Avaliao
Comunicaao com
o Cliente
Planejamento
Construo
Engenharia
Anlise de
Riscos
Figura 5. O Ciclo de Vida em Espiral
III.3.4 Ciclo de Vida Win-Win

O Ciclo de Vida Todos Ganham-Espiral (Win-Win Spiral) a unificao de dois
trabalhos distintos de Barry Boehm. No primeiro, o ciclo de vida espiral, ele prope,
como vimos anteriormente, que um produto de software de acordo com um ciclo de
especificaes cada vez mais detalhadas que resultam em verses incrementais das
capacidades operacionais desejadas. Cada ciclo envolve a elaborao dos objetivos,
restries e alternativas do produto, a avaliao das alternativas e riscos, a elaborao da
definio do produto e do processo e o planejamento do prximo ciclo. No segundo, a
Teoria-W, ele prope que todas as decises tomadas em um processo gerencial devem
gerar uma situao de todos ganham3.
As fases para esse ciclo de vida so

Identificar X
Identificar condies de ganho para cada X
Conciliar condies de Ganho
Estabelecer objetivos, restries e alternativas
Avaliar alternativas de produto e processo, resolver riscos
Definir produto e processo, incluindo parties
Validar produto e processo, incluindo parties
Revisar e alcanar compromisso (commit)
III.3.5 Desenvolvimento Acelerado

Devido a grande presso pela produtividade que as empresas sofrem no processo
de desenvolvimento de software, constantemente so propostas novas tcnicas com a
finalidade de acelerar o processo de desenvolvimento. Entre elas podemos citar a prpria
Em contrapartida com o caso normal, onde um ganha e os outros perdem, ou, ainda pior, com os casos
onde a deciso tomada vista como uma situao onde todos perdem.
19
prototipagem, Rapid Application Development (RAD), Adaptative Programming,

Extreme Programming.
III.4 Processo e Melhoria do Processo

O Modelo CMM (Capability Maturity Model), proposto pelo SEI (Software
Engineering Institute) , segundo o SEI: um modelo para julgar a maturidade dos
processos de software de uma organizao e para identificar as prticas chaves que so
necessrias para aumentar a maturidade desses processos. Nesse modelo, as
organizaes que produzem software so avaliadas e cadastradas em um de 5 nveis, de
acordo com suas prticas de trabalho. Para cada nvel, um conjunto de melhorias permite
que a organizao passe para o prximo nvel.
Otimizado
Gerenciado
Definido
Repetitvel
Inicial
Figura 6. Os cinco nveis do modelo CMM
III.4.1 Inicial
O processo de software ad-hoc, ocasionalmente catico. Poucos processos so
definidos e o sucesso depende do esforo individual e herico
Melhoria: Disciplinar o processo
III.4.2 Repetitvel
Processos bsicos de gerenciamento so estabelecidos para controlar custos,
cronograma e funcionalidade. Existe uma disciplina necessria para repetir sucessos
anteriores com aplicaes similares.
Melhoria: existncia de um processo padro e consistente
III.4.3 Definido
Existe um padro de processo para engenharia e para gerncia, integrado para
toda a organizao
Todos os projetos usam uma verso aprovada e adaptada do processo padro
Melhoria: processo previsvel
20
III.4.4 Gerenciado
So coletadas medidas detalhadas do processo
Processo e produto so entendidos quantitativamente
Melhoria: Melhoria continua do processo
III.4.5 Otimizado
A melhoria continua do processo possvel, devido ao feedback do processo e do
uso de idias e tecnologias inovadoras
III.5 A Equipe de Desenvolvimento

A equipe de desenvolvimento o conjunto de pessoas responsveis por construir
o software. Dela fazem parte pessoas com diferentes habilidades. Em sistemas de
informaes tradicionais teremos gerentes de desenvolvimento, analistas, projetistas,
programadores, administradores de banco de dados, etc... Em sistemas mais modernos,
como sistemas multimdia e websites, podemos ainda ter profisses novas como artistas e
professores.
importante verificar que as pessoas em uma equipe de desenvolvimento se
comunicam de alguma forma. Seguindo a regra de quanto maior o projeto, maior o
nmero de pessoas, muito maior o nmero de formas em que essas pessoas podem se
comunicar.
A figura a seguir tenta demonstrar essa idia. Como uma pessoa, no h nenhuma
comunicao. Com duas pessoas, s h uma maneira delas se comunicarem. Com 3
pessoas, escolhendo apenas a comunicao entre duas pessoas, j existem 3 formas. Com
4 pessoas, so 6 formas, com 5 pessoas so 10 formas. Basicamente, com N pessoas
teremos (N(N-1))/2 formas delas se comunicarem duas a duas.
Em projetos enormes, se todos puderem falar com todos para fazer algo, a
situao fica incontrolvel.
Por isso, temos que organizar a equipe de desenvolvimento de alguma forma.
Figura 7. As linhas de comunicao entre as pessoa s crescem

rapidamente, segundo uma exploso combinatria
21
Em uma equipe com organizao democrtica, todos podem se comunicar com

todos. Esse tipo de equipe razovel para projetos pequenos, com equipes de at 5 ou 6
pessoas, onde a comunicao incentivar a descoberta. Normalmente essas equipes so
encontradas em universidades e no desenvolvimento de pequenos projetos de alta
tecnologia (um web site, por exemplo).
Figura 8. Em uma equipe democrtica todos falam com todos
A forma mais tradicional de organizar uma equipe a forma hierrquica, baseada

nas teorias clssicas de administrao (que por sua vez, so baseadas na forma de
organizao do Exrcito e da Igreja).
Na equipe hierrquica temos um ou mais nveis de gerncia. Cabe a gerncia
controlar o funcionamento do projeto. Os nveis mais baixos so responsveis pela
execuo do projeto.
A equipe hierrquica boa para manter regras e padres, sendo uma escolha boa
para projetos repetidos e que exigem grande estrutura. Muitas empresas utilizam esse tipo
de organizao, porm ele considerado fraco para o desenvolvimento de software novo,
pois a estrutura coibe a criatividade.
Em relao ao uso dos profissionais, podemos indicar um defeito importante: o
profissional de desenvolvimento experiente transformado em gerente e tira a mo da
massa. Muitas vezes, inclusive, ele transformado em um mau gerente...
Figura 9. Em uma equipe hierrquica, diminuem-se as linhas de

comunicao
22
Brooks {Brooks Jr. 1982 ID: 34} prope uma equipe conhecida como Equipe do
Programador Chefe. Nesse tipo de equipe o desenvolvedor vai recebendo cada vez mais
responsabilidade em relao ao desenvolvimento, mas no em relao a tarefa diria de
administrao, que tratada a parte. Cada programador-chefe responsvel por parte do
projeto e delega tarefas aos programadores seniors, que por sua vez podem delegar
tarefas aos programadores jnior. Alguns desses programadores compe uma equipe de
teste.
Programadores
Secretria
Chefe
Administrador
Senior
Bibliotecria
Junior
Figura 10. Equipes do tipo programador chefe se baseiam na
capacidade do programador chefe
Existem muitas outras formas de organizar equipes. Cada tipo de produto exige
um tipo especial de equipe. Afinal, no desenvolveramos um software para controle de
vo de um avio com o mesmo tipo de equipe para o qual desenvolvemos um software
para controle de uma biblioteca, no ?
III.6 Leitura Complementar

Para complementar a compreenso deste captulo leiam as partes 1,2 e ainda o
captulo 10 do livro Pressman {Pressman 1997 ID: 1146}, que resumem o problema de
gerncia de projetos de software.
Leiam tambm a primeira parte do livro do Yourdon, Anlise Estruturada
Moderna, {Yourdon 1990 ID: 42}.
O captulo 1 do livro do Ruble {Ruble 1997 ID: 1903}.
Os captulos 1 e 2 do livro de Anlise Essencial do Pompilho {Pompilho 1995 ID:
1904}
23
Captulo IV. Qual o Tamanho do Software

Tpicos Abordados:
Como medir software?
Preo
Esforo
Tamanho
Medidas diretas
Medidas indiretas
Pontos de Funo
COCOMO
IV.1 Qual o tamanho do sistema?

Uma das perguntas mais freqentes em desenvolvimento do software qual o
tamanho do sistema? Essa pergunta pode vir sob vrias formas:
Qual o preo do sistema?
Qual o custo do sistema?
Qual o esforo para desenvolver o sistema?
Quantas pessoas sero necessrias para fazer esse software?
Em quanto tempo o sistema ficar pronto?
Quantas linhas de cdigo tem o sistema?
Quantos pontos de funo tem o sistema?
Qual o tamanho do sistema?
Que recursos so necessrios para o sistema?
Nesse captulo veremos como responder essas questes.
IV.2 Preo e Custo

Quando queremos saber o preo ou o custo do sistema a preocupao
econmica. No nosso contexto vamos separar os conceitos de custo e preo: custo
quanto eu gasto para desenvolver o sistema, preo quanto eu cobro pelo sistema. Apesar
de existir uma relao entre preo e custo, cabe aos responsveis pelo desenvolvimento
prever, acompanhar e calcular o custo do sistema (incluindo muitas vezes no s o
24
desenvolvimento, mas tambm o custo de implantao, operao e manuteno). O

preo, porm, determinado por uma relao comercial entre cliente e fornecedor4.
Fica claro ento que a principal e primeira pergunta que o desenvolvedor deve
fazer quanto o sistema custa para ser desenvolvido. A partir desse valor, pode
comear, se necessrio, a pensar em um preo a ser cobrado.
Para sistemas de informao o principal fator de custo o gasto com pessoal 5 .
Assim, o custo do software diretamente ligado a quantidade de pessoas envolvidas no
seu desenvolvimento e ao tempo que elas dedicam a essa atividade.
IV.3 Esforo e Tempo de Desenvolvimento

Tendo em vista que o principal fator de custo no desenvolvimento de software o
gasto com pessoal, uma das principais preocupaes da Engenharia de Software
determinar qual ser a quantidade de pessoas e o tempo por elas dedicado a um projeto.
Para isso usamos o conceito de Esforo que representa a quantidade de trabalho
realizado, medido em pessoa-ms 6, isso , o trabalho feito por uma pessoa em um ms.
Assim, podemos dizer que um sistema precisa de 4 pessoas -ms para ser
realizado, ou seja, que uma pessoa trabalhando 4 meses ou 4 pessoas trabalhando um
ms. Acontece que sistemas de informao so um pouco como bebs: no podemos ter a
gestao de um beb com nove mes em um ms. Na verdade, Boehm achou uma relao
entre o esforo necessrio e o tempo necessrio para fazer um sistema, e
conseqentemente o tamanho mdio da equipe.
Obviamente, o que fazemos no incio do projeto tentar prever o esforo
necessrio para realiz-lo com sucesso, e conseqentemente o tempo necessrio para
complet-lo. Essas previses so mais ou menos acertadas de acordo com vrios fatores,
incluindo a maturidade da empresa, a disponibilidade de dados histricos, a experincia
dos responsveis pela predio e a capacidade intrnseca do modelo utilizado na predio.
Um dos principais modelos de predio do esforo necessrio o COCOMO II.
Esse modelo, baseado em equaes matemticas derivadas a partir da anlise estatstica
de casos reais bastante completo. No COCOMO II, que apresentaremos de forma
reduzida a seguir, o esforo calculado a partir de uma previso do tamanho do software.
IV.3.1 Uma viso reduzida do modelo COCOMO II
COCOMO (Constructive Cost Model) um mtodo de previso de custos de
software. Atualmente possvel conseguir gratuitamente um software COCOMO
Nessa relao o cliente tenta pagar o menor preo possvel para o sistema e o fornecedor tenta cobrar o
maior preo possvel. Tanto fornecedores quanto clientes devem evitar fazer um acordo com risco de futuro
arrependimento.
5
Outros custos adicionais comuns so equipamento e software. Mesmo quando j possumos o

equipamento e o software temos que nos lembrar de amortizar o seu custo original de alguma forma entre
os vrios projetos.
6
Em sistemas menores a medida pessoa-hora.
25
baseado em pontos de funo, o que facilita o clculo de custos de projeto de sistemas de

informao.
A relao entre o tempo de desenvolvimento e o esforo necessrioo, que
apresentamos em sua forma completa a seguir, parte importante do modelo COCOMO 7:
TDEV = [ C ( PM NS ) ( D+ 0.2( E B )) ]
SCED%
100
Equao 1. Tempo de Desenvolvimento calculado pelo modelo

COCOMO
Nessa frmula PMNS a quantidade nominal de pessoas/ms8, SCED a

compresso necessria no tempo de desenvolvimento, B,C e D so constantes calibrveis
e E um coeficiente calculado a partir de coeficientes de escala.
N
E = B + 0.01 SFj
j =1
Equao 2. Clculo de E, a partir dos coeficientes de escala
Na fase inicial do projeto, os coeficientes de escala so 5 (N=5), e representam a

precedncia do sistema, a flexibilidade do projeto, o risco do projeto e da arquitetura, a
coeso da equipe e a maturidade do processo. Em situao normal para todos os casos, o
valor de E igual a 0.2807.
Ficaremos ento com uma frmula simplificada, capaz de atender plenamente os
objetivos desse livro. Caso necessrio, o leitor pode recorrer ao livro Software Cost
Estimation With COCOMO II ou ao web site:
http://sunset.usc.edu/research/COCOMOII/index.html
TDEV = [ 3. 67 ( PM NS ) 0.32 ]
Equao 3. Equao simplificada que pode ser usada para ter uma
previso do tempo de desenvolvimento a partir do esforo
necessrio em pessoas-ms, baseada no modelo COCOMO II
Fica ento a pergunta: como descobrir o esforo necessrio. O modelo COCOMO

II tambm nos fornece uma frmula, desta vez baseada na quantidade de linhas de cdigo
previstas para o software. Desta vez forneceremos logo a frmula simplificada:
PM = 2 . 94 MLDC
0 ,28
Equao 4. Equao simplificada de clculo do esforo, onde

MLDC significa milhares de linhas de cdigo.
Atualmente em sua segunda verso (COCOMO II)
PM NS um valor de pessoas-ms sem considerar esforos de traduo automtica e ainda sem considerar
efeitos da necessidade de acelerar o desenvolvimento
26
2.94
0.91
3.67
0.28
Tabela 3. Valores atuais de A,B,C e D
IV.3.2 Distribuio do Esforo

Uma questo importante na previso do esforo a ser feito para o
desenvolvimento de um software como esse esforo ser distribudo nas fases do
processo de desenvolvimento. O COCOMO 81 tratava desse problema com certo detalhe
que no foi continuado no COCOMO II.2000. Os dados do COCOMO 81, porm, foram
reaproveitados com as metodologias do COCOMO II.2000 para nos fornecer valor
provisrios com que trabalhar.
Para um processo seguindo o modelo em Cascata, os seguintes resultados so
esperados:
Fase
Esforo %
Tempo %
Planos e Requisitos
7 (2-15)
16-24 (2-30)
Projeto do Produto
17
24-28
Programao
64-52
56-40
Programao: Projeto Detalhado
27-23
Programao: codificao e Teste

de unidade
37-29
Integrao e Testes
19-31
20-32
Transio
12 (0-20)
12.5 (0- 20)
IV.4 O Tamanho do Software

At agora descobrimos que para saber o preo de um software precisamos saber
seu custo, e que para saber seu custo precisamos saber o esforo necessrio para
desenvolv-lo. Finalmente chegamos a questo mais difcil: como prever o tamanho do
software, de forma a determinar o esforo necessrio?
A primeira questo a responder como medir o tamanho do software. Vrios
autores j discutiram amplamente sobre essa questo. Atualmente duas formas so aceitas
internacionalmente para essa medida: milhares de linhas de cdigo fonte (KSLOCs, a
partir do acrnimo em ingls kilo source lines of code) e pontos de funo (PFs ou FPs,
do ingls). Ambos possuem defensores e detratores, vantagens e desvantagens mais
bvias ou mais sutis.
Um linha de cdigo, no contexto do COCOMO II, deve ser uma linha executvel,
ou uma declarao ou uma diretiva para o compilador, que no tenha sido gerada com um
gerador automtico e que tenha sido feita pela empresa. Linhas de cdigo, obviamente,
s podem ser contadas aps a implementao do software.
27
Um ponto de funo uma medida abstrata que representa a funcionalidade

entregue ao cliente, em funo das interfaces do sistema com o usurio, com outros
sistemas e ainda com a informao vista pelo cliente. Pontos de funo so tratados
detalhadamente em um captulo posterior. Pontos de funo podem ser contados a partir
desde a especificao do sistema at sua implementao final.
Essas duas medidas podem ser convertidas uma na outra, por meio de estatstica
globais ou especficas da empresa.
A vantagem de KSLOC que podemos simplesmente cont-las, a principal crtica
que medir produtividade ou custo por KSLOCs pode provocar distores, pois bom
programadores deveriam utilizar menos linhas de cdigo para realizar uma funo.
Pontos de funo podem ser criticados por ser uma medida abstrata demais,
porm permitem a comparao de sistemas de forma direta.
IV.5 Estimando o Tamanho

Precisamos ento de metodologias que nos permitam prever o tamanho de um
produto de software. A partir de uma estimativa podemos ento utilizar as frmulas.
No caso de pontos de funo a metodologia principal fazer uma anlise inicial e
contar os pontos de funo presentes no resultado da anlise. Dependendo da qualidade
do processo da empresa e da pro fundidade dessa anlise inicial o erro nessa contagem
ser bem pequeno.
J no caso de linhas de cdigo precisamos de um mtodo de predio, como por
exemplo solicitar a previso a um especialista com experincia em projeto semelhante.
Um dos mtodos sugeridos no passado foi a Tcnica de Delfos9. Atualmente a tcnica
no aparece muito nos livros didticos, provavelmente porque no atende as necessidades
de velocidade do mundo atual.
IV.5.1 A Tcnica de Delfos
A Tcnica de Delfos uma forma de fazer com que especialistas entrem em
consenso sobre uma predio ou estimativa sem que haja uma discusso frente a frente.
Segunda a tcnica a primeira ao a ser feita a definio do produto sobre o qual
a estimativa ser feita. No nosso caso a pergunta em que estamos interessados quantas
linhas de cdigo sero necessrias para implementar o software. Normalmente, a
definio faz uma diviso do software em mdulos, para facilitar a estimativa.
So ento escolhidos especialistas, para os quais so distribudos os questionrios
com a descrio dos mdulos. Para cada mdulo os especialistas devem fazer uma
predio de tamanho. Este o primeiro ciclo.
A partir do primeiro ciclo so feitos ciclos sucessivos onde so distribudos os
mesmos questionrios, porm com a informao, no identificada, de cada resposta dada.
Normalmente esta informao dada em um grfico indicando ainda a estimativa
9
Ou Delphi. Baseado no Orculo de Delfos, nica relao direta com a linguagem Delphi.
28
mnima, a mxima, a mediana e a mdia. A partir do segundo ciclo os especialistas

devem justificar suas respostas, de maneira a facilitar a convergncia de opinies. Esse
tipo de ciclo repetido at que o consenso seja atingido.
Apesar da Tcnica de Delfos no ser muito rpida, compreender seu
funcionamento pode ajudar a determinar como deve ser feito o trabalho de predio de
especialistas.
IV.5.2 Cenrios
Outra tcnica alternativa determinar cenrios de pior caso, caso mais provvel e
de melhor caso. O valor final da estimativa dado por:
Ve =
Vpc + 4 Vcmp + Vmc

6
Equao 5. Clculo do valor estimado ( Ve) em funo do valor de

pior caso (Vpc), valor do caso mais provvel (Vcmp) e do valor do
melhor caso (Vmc).
IV.6 Verificando a Sanidade da Estimativa

importante que qualquer estimativa seja verificada quanto a sua qualidade. Uma
das melhores formas tentar formas alternativas de estimar e verificar se os resultados
so compatveis.
Por exemplo, interessante verificar a estimativa dada por um mtodo (por
exemplo, COCOMO II) com estimativas dadas por um segunda mtodo, de preferncia
feito por pessoas diferentes.
IV.7 Anlise de Pontos de Funo

Uma das mais importantes informaes que podemos ter sobre um produto de
software o esforo necessrio para desenvolv-lo. Usualmente definimos este esforo
pela quantidade de homens/hora ou homens/ms necessrios para desenvolver o produto.
A principal utilizao desta informao tem como objetivo prever e acompanhar o
esforo que ser gasto no desenvolvimento de um produto de porte semelhante.
Porm, como saber qual o porte de um produto de software?
Para isso foram inventadas vrias medidas, algumas delas arbitrrias, outras fceis
de medir. comum que digamos o tamanho de um software pela quantidade de linhas de
cdigo, pelo nmeros de horas gasto para desenvolv-lo ou pelo custo final do mesmo.
Porm, at 1979 no tnhamos uma boa medida do tamanho do software em
funo da sua funcionalidade como vista pelo usurio. Apenas nessa data, Albrecht
{Albrecht 1979 ID: 1144} apresentou uma medida conhecida como Pontos de Funo,
cujo objetivo era servir como avaliador e preditor do tamanho de um sistema.
29
Um Ponto de Funo (PF) uma medida abstrata e relativa que conta o nmero
de funes de negcio entregues ao usurio. Um relatrio simples, por exemplo, pode
medir 4 Pontos de Funo. Da mesma forma que um metro ou um litro, Pontos de
Funo s fazem sentido quando comparados com um padro. Assim, um sistema com
1.000 PF entrega o dobro de funcionalidade de que um sistema com 500 PF. Com o
tempo, aprendemos a ter uma idia absoluta do tamanho de um sistema a partir da
contagem de seus PFs.
A maneira padronizada de contar pontos de funo fornecida pelo International
Function Points User Group (IFPUG), que fornece aos seus associados um manual
contendo detalhes do que deve e do que no deve ser contado. A associao de uma
pessoa ao IFPUG custa aproximadamente US$ 200,00 em 1999. Esse captulo apenas
uma introduo ao mtodo, servindo para fazer clculos aproximados do nmero de
pontos de funo de um sistema.
IV.7.1 Viso geral
Para contar pontos de funo, primeiramente identificamos as funes de negcio
como percebidas pelo usurio, divindo-as em 5 grupos:
sadas , que informaes de negcio que o usurio final pode receber,
representando relatrios, telas e mensagens de erro como um todo e no em suas
partes individuais;
consultas, que so sadas simples e imediatas, sem alterao na base,
usualmente caracterizveis por chaves simples de consulta
entradas, que so informaes de negcio enviadas para o sistema pelo
usurio final
arquivos lgicos, que so os dados de uma aplicao, na forma como
so vistos logicamente pelo usurio, ou ainda podem ser contadas a partir das
entidades de um grfico E- R conceitual, dos depsitos de dados de um DFD ou do
nmero de tabelas em um banco de dados relacional, e
interfaces, que so dados guardados em algum lugar por outra
aplicao, mas usados pela aplicao em questo.
O segundo passo determinar a complexidade de cada funo de negcio. A
complexidade fornece um peso para cada funo de negcio encontrada. O somatrio do
nmero de funes multiplicadas pelo seu peso fornece o nmero bsico de pontos de
funo. Esse nmero um indicador preliminar do tamanho do sistema.
Finalmente, o nmero bsico de pontos de funes corrigido em funo de
fatores que aumentam o diminuem a complexidade do sistema.
IV.7.2 Identificando Funes de Negcio
Para identificar as funes de negcio devemos partir de algum documento que
aponte as funes aprovadas e pelo usurio e teis para o negcio. No devem ser
contadas funes necessrias por causa da tecnologia aplicada. Basicamente, s
cobrado o que o usurio pode ver e est disposto a pagar. Tambm importante que as
30
funes de negcio so cobradas como o usurio as percebem. Isto significa que no

interessa se estamos usando um ou vinte arquivos para guardar um informao, mas sim
de quantas formas o usurio pode acessar essa informao.
Alm disso, devemos identificar as funes seguindo uma certa ordem. A ordem
importante porque encontrar um tipo de funo de negcio ajuda a encontrar as funes
de outro tipo. Assim, em um sistema novo devemos usar a ordem sadas, consultas,
entradas, arquivos e interfaces; enquanto em um sistema j existente devemos usar a
ordem arquivos, interfaces, sadas, consultas e entradas.
Para ser contados os valores devem:

beneficiar claramente o usurio,
ser especificamente aprovado pelo usurio e
influenciar em algum grau mensurvel o projeto, desenvolvimento, implementao e
suporta aplicao
No manual da IFPUG podemos encontrar vrios XXX
Identificando Sadas
Para contar as sadas necessrio contar todos as informaes que o sistema gera
para o ambiente de forma procedural. Tipicamente, sadas so relatrios impressos, telas,
janelas e arquivos gerados para outras aplicaes.
Deve ser contadas como sadas distintas cada formato utilizado. Basicamente, se
for necessrio fazer outro procedimento para produzir a informao, contamos como uma
sada distinta. Tambm contamos cada tipo de lgica utilizada para fazer gerar a
informao. Assim, se um relatrio de vendas contm as vendas por vendedor e por loja,
contaremos como duas sadas, pois so necessrios procedimentos lgicos distintos para
calcular cada um desses valores. Linhas de sumrio e total, porm, no so contadas
como novas sadas.
Identificando Consultas
Ateno, consultas so sempre no monitor, no existe uma consulta em relatrio
de papel.
Uma consulta no pode calcular nenhum valor. Em caso de clculo de qualquer
valor, temos uma sada.
Identificando Entradas
Um comando especfi co para o sistema executar algo uma entrada.
Identificando Arquivos
Cada forma de acesso (chave) indica um arquivo.
Identificando Interfaces
Conta de novo as sadas que tem interface com outro sistema.
31
IV.7.3 Determinando a Complexidade

Para todos os tipos de funo de negcios, importante determinar o nmero de
itens de dados referenciados.
Para sadas, consultas e entradas, devemos contar o nmero de arquivos
acessados.
Para arquivos e interfaces, devemos contar o nmero de relacionamentos do
arquivo.
Sadas
Itens de dados referenciados
Arquivos
Referenciados
1-5
6-19
20+
0 1
Simples (4)
Simples (4)
Mdia (5)
2- 3
Simples(4)
Mdia(5)
Complexa(7)
4+
Mdia (5)
Complexa (7)
Complexa (7)
Consultas
Escolher o maior valor obtido entre a parte entrada

e a parte sada
Sada
Arquivos
Referenciados
1-5
6-19
20+
0 1
Simples (4)
Simplse (4)
Mdia (5)
2-3
Simples (4)
Mdia (5)
Complexa (7)
4+
Mdia (5)
Complexa (7)
Complexa (7)
Entradas
Arquivos
Referenciados
1-4
5-15
0 1
Simples (3)
Simples (4)
Mdia (4)
Simples (3)
Mdia (4)
Complexa (6)
3+
Mdia (4)
Complexa (6)
Complexa (6)
Entradas
16+
Arquivos
Referenciados
1-4
5-15
16+
0 1
Simples (3)
Simples (4)
Mdia (4)
Simples (3)
Mdia (4)
Complexa (6)
3+
Mdia (4)
Complexa (6)
Complexa (6)
32
Arquivos
Relacionamentos
1-19
20-50
Simples (7)
Simples (7)
Mdia (10)
2-5
Simples (7)
Mdia (10)
Complexa (15)
Mdia (10)
Complexa (15)
Complexa (15)
Interfaces
51+
Relacionamentos
1-19
20-50
51+
Simples (5)
Simples (5)
Mdia (7)
2-5
Simples (5)
Mdia (7)
Complexa (10)
Mdia (7)
Complexa (10)
Complexa (10)
6
Tabela 4. Como calcular o nmero de pontos de funo
IV.7.4 As Perguntas
So 14 as perguntas que devem ser feitas e ajudaram a determinar a quantidade de
PF relativa a um sistema. Cada uma deve ser respondida com um nmero, de 0 a 5,
indicando a importncia da caracterstica que se pergunta sobre o sistema, da seguinte
forma:
0 - No tem influncia
1 - Influncia incidental
2 - Influncia moderada
3 - Influncia mdia
4 - Influncia significativa
5 - Influncia essencial
Para as perguntas:
1.
O sistema necessita de backup e recuperao confivel?
2.
necessrio utilizar comunicao de dados?
3.
Existe processamento distribudo de funes?
4.
A performance crtica?
5.
O sistema vai funcionar em um ambiente operacional j existente e
fortemente utilizado?
6.
O sistema exige entrada de dados on-line?
7.
(Se existir) A entrada de dados exige que a transao seja realizada por meio
de vrias telas ou operaes?
8.
Os arquivos so atualizados on-line?
9.
As entradas, sadas e consultas so complexas?
10. O processamento interno complexo?
11. O cdigo deve ser projetado para ser reutilizvel?
12. A converso (se necessria) e instalao deve estar includa no projeto?
33
13.
14.
O sistema deve funcionar em mltiplas instalaes em diferentes

organizaes?
A aplicao projetada para ser facilmente modificvel e fcil de utilizar pelo
usurio?
IV.7.5 Clculo dos Pfs

Os PF so calculados em etapas:
1.
contam-se os nmeros de entradas, sadas, consultas, arquivos e interfaces do

sistema;
2.
multiplica-se cada um desses nmeros por um peso, de acordo com a

complexidade do sistema (Tabela 1), e somando os resultados;
3.
responde-se a uma srie de perguntas (apresentadas adiante), as quais

fornecem, cada uma, um valor de 1 a 5 (p i , 1 i 5),
4.
calcula -se o nmero de pontos de funo com a equao:

PF = total-de-2 x (0,65 + 0,01 x (pi )).
IV.7.6 Os multiplicadores
A Tabela 1 indica os multiplicadores que devem ser dados a cada item, de acordo
com a complexidade do sistema.
Complexidade
Medida
Contagem
Simples
Mdia
Complexa
Total
Total
Nmero de sadas
Nmero de consultas
6?
7?
Nmero de entradas
Nmero de arquivos
10
15
Nmero de interfaces com

outros sistemas
10
Total
Tabela 5. Guia de clculo para os pontos de funo
IV.7.7 Utilizando Pfs para previses

Para utilizar os Pfs para fazer previses necessrio primeiro calcular a
produtividade em PF/(homem/ms) da equipe que realizar o software. importante
levar em conta que o ambiente que esta equipe trabalha, suas qualidades e defeitos, as
ferramentas disponveis e o tipo de trabalho que realizam afetam o clculo dessa
produtividade. Por exemplo, comum que equipes de manuteno obtenham
34
produtividade (aparente) muito maior que equipes de desenvolvimento quando utilizada

a medida de pontos de funo.
Sabida a produtividade da equipe, basta calcular o nmero de PFs para o sistema
proposto, por exemplo analisando o resultado da anlise essencial, e dividir esse nmero
pela produtividade, obtendo o esforo necessrio para implementar o produto.
Contribuio percentual
rea de Aplicao
Total de Pontos
de Funo
Sadas
Consultas
Entradas
Arquivos
Interfaces
Processamento
Carne
654
30
28
35
Compras de Aes
166
18
37
28
Contabilidade
2047
18
34
45
108
27
26
29
19
Comrcio varejista
662
17
22
21
40
Comrcio
Atacadista
714
23
20
18
39
Sistemas de Caixa
604
28
12
39
21
Transterncia
dinheiro
105
55
18
20
186
48
31
21
Sistemas
Compras
de
de
de
Bibliotecas
Tabela 6. Tamanho mdio, em pontos de funo, de alguns

sistemas tpicos no mercado americano
LANGUAGE LEVEL
PRODUCTIVITY AVERAGE PER

STAFF MONTH
1-3
5 to 10 Function Points
4-8
9 - 15
16 - 23
24 - 55
Above 55
Tabela 7 Nveis de Linguagem, segundo Caper-Jones
LANGUAGE
1st Generation default
2nd Generation default
3rd Generation default
4th Generation default
5th Generation default
ABAP/4
ACCEL
Access
Ada 95
LEVEL
1.00
3.00
4.00
16.00
70.00
20.00
17.00
8.50
6.50
AVERAGE SOURCE
STATEMENTS PER
FUNCTION POINT
320
107
80
20
5
16
19
38
49
35
LANGUAGE
AI shell default
AI SHELLS
ALGOL 68
ANSI BASIC
ANSI COBOL 74
ANSI COBOL 85
ANSI SQL
APL 360/370
APL default
APL*PLUS
APPLESOFT BASIC
Application Builder
Application Manager
APS
APT
APTools
ARC
Arity PROLOG
Assembly (Basic)
Assembly (Macro)
Associative default
Autocoder
awk
BASIC
BASIC A
Basic assembly
C
C Set 2
C++
CICS
CLIPPER
CLIPPER DB
CLOS
COBOL
COBOL II
Cobol/400
Common LISP
Crystal Reports
Data base default
dBase III
dBase IV
DCL
Decision support default
DELPHI
DOS Batch Files
DSP Assembly
EIFFEL
English-based default
Ensemble
EPOS
EXCEL 1-2
EXCEL 3-4
EXCEL 5
Extended Common LISP
EZNOMAD
FileMaker Pro
FLEX
FlexGen
FORTH
FORTRAN 66
FORTRAN 77
FORTRAN 90
FORTRAN 95
FORTRAN
FORTRAN II
FOXPRO 1
FOXPRO 2.5
LEVEL
6.50
6.50
3.00
5.00
3.00
3.50
25.00
10.00
10.00
10.00
2.50
16.00
9.00
19.00
4.50
16.00
6.50
5.00
1.00
1.50
5.00
1.00
15.00
3.00
2.50
1.00
2.50
3.50
6.00
7.00
17.00
8.00
15.00
3.00
3.00
3.50
5.00
16.00
8.00
8.00
9.00
1.50
9.00
11.00
2.50
2.00
15.00
6.00
11.00
16.00
51.00
55.00
57.00
5.75
9.00
9.00
7.00
11.00
5.00
2.50
3.00
4.00
4.50
3.00
2.50
8.00
9.50
AVERAGE SOURCE
STATEMENTS PER
FUNCTION POINT
49
49
107
64
107
91
13
32
32
32
128
20
36
17
71
20
49
64
320
213
64
320
21
107
128
320
128
91
53
46
19
40
21
107
107
91
64
20
40
40
36
213
36
29
128
160
21
53
29
20
6
6
6
56
36
36
46
29
64
128
107
80
71
107
128
40
34
36
LANGUAGE
Golden Common LISP
GPSS
GW BASIC
Haskell
High C
HP BASIC
HTML 2.0
HTML 3.0
IBM CICS/VS
IBM Compiled BASIC
IBM VS COBOL
IBM VS COBOL II
IDMS
INFORMIX
INGRES
Interpreted BASIC
Interpreted C
JAVA
JCL
KSH
Lattice C
LISP
LOTUS 123 DOS
LOTUS Macros
LUCID 3D
macFORTH
Machine language
Macro assembly
MATHCAD
MDL
MENTOR
MESA
Microfocus COBOL
Microsoft C
MODULA 2
MOSAIC
MS C ++ V. 7
MS Compiled BASIC
muLISP
NATURAL 1
NATURAL 2
NATURAL Construct
Natural language
Non-procedural default
Nroff
Object-Oriented default
OBJECT Assembler
Object LISP
Object LOGO
Object PASCAL
Object Star
Objective-C
OPS5
ORACLE
Oracle Developer/2000
PARADOX/PAL
PASCAL
PDP-11 ADE
PERL
polyFORTH
Power BASIC
PowerBuilder
Pro-C
PRO-IV
Problem-oriented default
Procedural default
Professional PASCAL
LEVEL
5.00
7.00
3.25
8.50
2.50
2.50
20.00
22.00
8.00
3.50
3.00
3.50
8.00
8.00
8.00
3.00
2.50
6.00
1.45
15.00
2.50
5.00
50.00
3.00
51.00
5.00
0.50
1.50
60.00
9.00
6.00
3.00
4.00
2.50
4.00
50.00
6.00
3.50
5.00
6.00
7.00
13.00
0.10
9.00
6.00
11.00
5.00
11.00
11.00
11.00
20.00
12.00
5.50
8.00
14.00
9.00
3.50
6.00
15.00
5.00
6.50
20.00
12.00
5.50
4.50
3.00
3.50
AVERAGE SOURCE
STATEMENTS PER
FUNCTION POINT
64
46
98
38
128
128
16
15
40
91
107
91
40
40
40
107
128
53
221
21
128
64
6
107
6
64
640
213
5
36
53
107
80
128
80
6
53
91
64
53
46
25
3200
36
53
29
64
29
29
29
16
27
58
40
23
36
91
53
21
64
49
16
27
58
71
107
91
37
LANGUAGE
Program Generator default
PROLOG
QBasic
QUATTRO
QUATTRO PRO
Query default
QUICK BASIC 1
QUICK BASIC 2
QUICK BASIC 3
Quick C
Reuse default
REXX (MVS)
REXX (OS/2)
RM BASIC
RM COBOL
RM FORTRAN
RPG I
RPG II
RPG III
SAS
SCHEME
Screen painter default
SHELL
SIMSCRIPT
SIMULA
SIMULA 67
Simulation default
SMALLTALK 80
SMALLTALK/V
SNOBOL2-4
Spreadsheet default
SPSS
SQL
SQL-Windows
Statistical default
Strongly typed default
SYBASE
TCL
Turbo C
TURBO C++
TURBO EXPERT
Turbo PASCAL >5
Turbo PASCAL 1-4
Turbo PASCAL 4-5
Turbo PROLOG
UNIX Shell Scripts
Visible C
Visible COBOL
Visicalc 1
Visual 4.0
Visual Basic 1
Visual Basic 2
Visual Basic 3
Visual Basic 4
Visual Basic 5
Visual Basic DOS
Visual C++
Visual COBOL
Visual Objects
VisualAge
VisualGen
VS-REXX
WATCOM C
WATCOM C/386
Waterloo C
Waterloo PASCAL
WATFIV
LEVEL
20.00
5.00
5.50
51.00
51.00
25.00
5.00
5.25
5.50
2.50
60.00
4.00
7.00
3.50
3.00
3.00
4.00
5.50
5.75
10.00
6.00
57.00
15.00
7.00
7.00
7.00
7.00
15.00
15.00
2.50
50.00
10.00
25.00
27.00
10.00
3.50
8.00
5.00
2.50
6.00
6.50
6.50
4.00
4.50
4.00
15.00
6.50
8.00
35.00
11.00
7.00
7.50
8.00
9.00
11.00
8.00
9.50
16.00
20.00
15.00
18.00
10.00
2.50
2.50
2.50
3.50
3.75
AVERAGE SOURCE
STATEMENTS PER
FUNCTION POINT
16
64
58
6
6
13
64
61
58
128
5
80
46
91
107
107
80
58
56
32
53
6
21
46
46
46
46
21
21
128
6
32
13
12
32
91
40
64
128
53
49
49
80
71
80
21
49
40
9
29
46
43
40
36
29
40
34
20
16
21
18
32
128
128
128
91
85
38
LANGUAGE
WATFOR
YACC
YACC++
ZBASIC
ZIM
LEVEL
3.50
6.00
6.00
3.50
17.00
AVERAGE SOURCE
STATEMENTS PER
FUNCTION POINT
91
53
53
91
19
Tabela 8. Tabela de converso, apresentando nmero mdio de

linhas de cdigo equivalentes a 1 ponto de funo
39
Captulo V. Uma Proposta Inicial

It isn't that they can't see the solution. It is that they can't see the problem.
Chesterton, G. K. (1874 - 1936) in The Point of a Pin in The Scandal of Father Brown.
Tpicos Abordados
Objetivos
Metas
Mtricas
Problemas
Oportunidades
Requisitos Iniciais
Descrio Sucinta do Sistema Atual
Restries
Proposta Inicial
V.1
O Primeiro Contato e Os Primeiros Resultados
Quando vamos iniciar o desenvolvimento de um sistema somos em geral

convidados por um cliente em potencial para conhecer seus problemas, seus desejos e
propor uma soluo.
Essa uma fase muito difcil para o desenvolvedor, pois ele precisa tomar muitas
decises com poucas informaes. Algumas vezes o desenvolvedor obrigado a fornecer
uma proposta de trabalho, incluindo previso de custos, a partir de uma entrevista curta.
Essa situao est muito longe da ideal, onde s teramos que fornecer uma proposta de
trabalho aps conhecer bastante o problema. Outro problema para o desenvolvedor que
esta uma fase de investimento. Entre vrias propostas apresentadas, apenas algumas
sero aceitas. O tempo gasto nas propostas no aceitas um custo a mais, a ser dividido
por todos os projetos aceitos.
Propomos ento que esta fase inicial de negociaes tenha um objetivo:
desenvolver um documento chamado proposta inicial. No queremos chamar esse de
proposta de desenvolvimento por considerar que so necessrios mais alguns dados para
desenvolver uma verdadeira proposta de desenvolvimento. A proposta inicial o
primeiro passo para atingir a proposta de desenvolvimento e pode ser mantida como
documento interno se o cliente no exigir uma proposta imediatamente.
V.2
O Objetivo do Sistema
O Objetivo do Sistema descrito por uma sentena de poucas linhas que permite
identificar imediatamente a finalidade do sistema. A sentena deve ser clara, de forma a
permitir uma identificao rpida do escopo do sistema, isto , do que faz parte e do que
no faz parte do sistema.
40
Alguns objetivos razoveis so:

O Sistema dever controlar a recepo e envio de pacotes pelo setor de cargas.
O Sistema permitir o gerenciamento de cardpios em uma rede de restaurantes
populares, definindo pratos e receitas e verificando sua aceitao
O Sistema controlar a entrada e sada de funcionrios, realizando o servio de
ponto e fornecendo dados para a folha de pagamento
Em todos esses objetivos podemos, at certo ponto, que tarefas podem fazer parte
e que tarefas no devem fazer parte do sistema.
Alguns exemplos de objetivos mal definidos:
O Sistema otimizar o desempenho da empresa na sua rea de atuao
O Sistema possibilitar o controle dos clientes
A finalidade do projeto deve permitir a clientes e desenvolvedores descrev-lo em
uma sentena, permitindo a identificao clara de porqu o projeto existe e o qual o
escopo do trabalho global.
V.3
Metas
O uso de metas para nortear o desenvolvimento de sistemas uma proposta

diferente das tradicionais. Isso porque as metas no esto relacionadas a funcionalidades
do sistema, mas sim aos resultados obtidos quando inserimos o sistema novo no
ambiente.
Assim, devemos definir metas que possam ser verificadas quando o sistema for
instalado. Cada meta vir acompanhada de uma mtrica, uma medida objetiva que
permite comprovar que a meta foi alcanada. Metas que no possuem mtricas objetiva,
como satisfao do cliente, devem ser evitadas ou devem ser associadas a um instrumento
de medida que permita verificar conceitos subjetivos, como uma pesquisa de opinio.
Assim, ao implantar um sistema de atendimento automtico, poderamos ter como
metas:
acelerar o atendimento, como a mtrica tempo mdio de atendimento
diminuir o tamanho das filas, com a mtrica tamanho mdio da fila.
Para cada para meta - mtrica, pode ser necessrio desenvolver um procedimento
de medida ou um procedimento de levantamento de dados passados. Isso no algo
comum no desenvolvimento de sistemas, porm algo desejvel.
A principal vantagem de associar metas ao sistema que no fazem parte dos
requisitos do sistema demonstrar a utilidade do sistema, isto , como o sistema faz o
cliente ganhar mais dinheiro ou realizar melhor sua tarefa.
Cuidado porm com as armadilhas que existem na escolha das metas. Primeiro,
muito comum que um cliente deseje uma meta que no pode ser alcanada por um
sistema com o objetivo definido. A questo, nesse caso, se resume a negociar a mudana
41
da meta ou negociar a mudana do objetivo. Como exemplo, podemos citar o caso de um

cliente que desejava um sistema de controle de pedidos para os fornecedores baseado em
pedidos de clientes e desejava que o sistema diminusse o prazo de entrega para os
clientes. Analisado o funcionamento da empresa, comprovamos que era impossvel
acelerar o prazo meramente controlando os pedidos. Era possvel, porm, fazer uma
previso mais acertada do prazo de entrega e estar preparado para atrasos, mediante o
acompanhamento dos pedidos.
Outra armadilha ter uma meta que afetada por muitas coisas alm do sistema.
Em um caso simples, tnhamos a proposta de um sistema de reservas de hotel que se
propunha a aumentar a ocupao dos quartos. Ora, o nvel de ocupao dos quartos de
um hotel depende de muitos fatores, inclusive da economia geral. Entendemos que o
sistema poderia ter como meta, por exemplo, diminuir o nmero de reservas no
cumpridas. Essa meta mensurvel e pode ser diretamente influenciada pelo sistema
(por meio de verificaes com o cliente, por exemplo). interessante notar que a meta
selecionada um dos fatores que afeta a meta proposta inicialmente. Essa outra
armadilha comum, escolher uma meta (e uma mtrica) que na verdade derivada da meta
(e da mtrica) que o sistema tem condies de atingir.
V.3.1 GQM Goal, Question and Metrics
O mtodo GQM: goal question and metrics, pode ser um bom mtodo para a
definio das metas do sistema.
V.3.2 Pontos Crticos ou Pontos Chave
Os pontos crticos (ou chave) de sucesso para um projeto so aquelas questes
que, no estando diretamente relacionada ao desenvolvimento propriamente dito, so
essenciais para o bom andamento do projeto.
Exemplos: compromisso de certos funcionrios, fornecimento de certa
informao, chegada de alguma mquina ou software, etc.
V.4
Levantando Objetivos e Metas
A melhor maneira de levantar objetivos e metas entender simultaneamente: o

que o cliente deseja, o que est funcionando agora, quais os problemas atuais, quais
oportunidades existem para um novo sistema.
V.4.1 A solicitao do cliente
Normalmente o cliente, ao solicitar um software, tem uma idia do que necessita
que esse software faa. Muitas vezes o cliente possui inclusive um documento
descrevendo essa idia. nesse documento, ou a partir das entrevistas iniciais, que o
analista deve procurar as principais motivaes e necessidades do cliente.
sempre importante focalizar nas necessidades de negcio do cliente. Muitas
vezes o cliente acredita precisar de um sistema para resolver um problema em seu
negcio, quando na verdade precisa de outro. Um exemplo tpico: uma loja que entregava
objetos feitos sob encomenda para os clientes fbricas terceirizadas acreditava que seria
42
possvel, com um software, diminuir o prazo de entrega. Na prtica, como os atrasos

estavam nas fbricas e no eram controlveis pela loja, poderamos apenas produzir
relatrios que permitissem calcular melhor o prazo ou selecionar melhor os fornecedores,
ou ainda produzir relatrios que permitissem influenciar mais diretamente esses
fornecedores, mas no influir diretamente no prazo de entrega. Deixando claras as
expectativas, teremos clientes mais contentes.
V.4.2 O sistema atual
Uma das tarefas mais importantes compreender, perfeitamente, como funciona o
sistema atual. Desprezar o sistema atual, por mais antigo ou mal feito que ele seja, um
dos erros mais freqentes dos desenvolvedores. S podemos criar um sistema novo aps
conhecer perfeitame nte o sistema atual, como funciona e porque funciona dessa forma.
V.4.3 Problemas atuais
Aps o levantamento do sistema atual, devemos apontar, baseado nas reclamaes
dos clientes e em nossas observaes, quais so os problemas do sistema atual.
Novamente imp ortante lembrar que os problemas de negcio so mais
importantes que os problemas tcnicos. Muitas lojas hoje em dia utilizam sistemas feitos
em MS-DOS porque eles atendem perfeitamente seus requisitos de negcio.
Os problemas atuais, principalmente quando relacionados ao negcio, podem ser
os principais fornecedores de metas para o sistema. Assim, se o problema for a lentido, o
aumento do desempenho uma meta importante. Da mesma forma, se o problema for a
dificuldade de utilizao, a meta pode ser facilitar a utilizao do sistema e as mtricas
podem estar relacionadas ao tempo de aprendizado ou ao nmero de erros na entrada de
dados.
V.4.4 Oportunidades para novos sistemas
Devemos incluir em nossa proposta oportunidades que detectamos a partir do
nosso conhecimento do que factvel atualmente ou em futuro prximo.
As oportunidades para um novo sistema esto normalmente ligadas a novas
tecnologias.
V.5
Restries
Muitos sistemas tem restries importantes, que devemos considerar em nossas

propostas.
Se voc nunc a fez anlise de sistemas, essa proposta pode
parecer incompreensvel. Isso acontece porque para fazer a
proposta inicial devemos fazer, de maneira extremamente
simplificada, uma anlise de sistema. Assim, se no
compreende o que deve ser feito, espere alguns captulos
43
V.6
Estrutura da Proposta Inicial
1. Resumo Executivo
2. Apresentao do Documento
2.1. Identificao do Projeto
2.2. Identificao do Cliente
2.3. Identificao do Prestador de Servio
3. Histrico do Apresentador de Servio
4. Pequena Descrio da Solicitao do Cliente
5. Descrio Sucinta do Sistema Atual
5.1. Descrio
5.2. Identificao de Problemas
5.3. Identificao de Oportunidades
6. Descrio do Sistema Proposto
6.1. Objetivo
6.2. Metas
6.3. Mtricas para avaliao das Metas
6.4. Requisitos Funcionais Iniciais
6.5. Requisitos de Informao Iniciais
6.6. Requisitos No Funcionais Iniciais
6.7. Restries
7. Cronograma Provisrio
8. Custo Provisrio
9. Outras Clusulas (opcionais)
9.1. Exclusividade
9.2. Forma de pagamento
9.3. Reajustes
9.4. Renegociao
9.5. Confidencialidade
V.7
O Resumo Executivo
O resumo executivo deve permitir que o leitor tenha uma viso completa do texto
do documento em uma pgina. Resumos executivos tm esse nome por partir da hiptese
44
que um executivo, ao tomar uma deciso, no tem tempo para ler longos documentos. Na
prtica eles leriam o resumo executivo e folheariam os documentos.
V.8
Exemplo de Documento
A seguir apresentamos um exemplo simples de uma proposta inicial.
V.8.1 Proposta Inicial

Identificao do Projeto
Projeto de Automao da Video-Locadora Movieland
Identificao do Cliente
Jos Manual da Silva
Proprietrio
Movieland Locadora de Vdeo Ltda.
Identificao do Prestador de Servio
Guilherme Portes
Diretor
Software Legal S.A.
V.8.2 Histrico da Software Legal
A Empresa Software Legal tem larga experincia no desenvolvimento e
implantao de software sob medida para pequenos e mdios negcios. Fundada em
1980, vem desenvendo produtos direcionados para o comrcio varejista, como controle
de estoque e controle de vendas. H 5 anos comeamos a trabalhar com software para
Vdeo-Locadoras. Nossa empresa conta com uma carteira de aproximadamente 100
clientes.
Entre outros projetos que participamos, gostaramos de relacionar os seguintes
clientes como referncia:
VideoAgora Ltda.
Onde desenvolvemos um produto para controlar o aluguel de fitas de vdeo e de
jogos, incluindo o uso de cdigo de barras para identificar os itens alugados. O Sistema
est em uso h 2 anos.
ToPorCima Futebol Clube
Onde desenvolvemos um sistema para apoiar a loja da marca do clube, incluindo
controle de estoque, controle de caixa (venda). O sistema capaz de interagir com o
registro de scios do clube, fornecendo informaes utilizadas para clculo de descontos.
45
Restaurante do Cabeo
Onde desenvolvemos um sistema de controle de estoque integrado com o sistema
de preparao de cardpios.
V.8.3 Solicitao do Cliente
A Movieland uma rede de locadoras de vdeo que utiliza um sistema comprado
pronto para gerenciar, separadamente, cada uma de suas lojas.
A rede deseja implementar um sistema integrado para todas as lojas, que permita
que os clientes peguem e entreguem fitas em qualquer loja. Alm disso, o sistema deve
permitir que seja feito o controle de estoque das fitas nas lojas, permitindo uma
redistribuio diria das fitas, de acordo com a demanda.
Alm disso o sistema deve reproduzir as opes j existentes no sistema atual,
porm utilizando no s o movimento de cada loja, mas tambm o movimento da rede
como fator de clculo.
V.8.4 Descrio Sucinta do Sistema Atual
O Sistema atual permite a manuteno de um estoque de fitas a serem alugadas e
o controle do aluguel dessas fitas por parte dos clientes filiados. Duas funes bsicas do
sistema so: o cadastro de fitas e o cadastro de clientes.
Quando um cliente pega uma fita, feita a digitao do nmero da fita e do
nmero do cliente. Se o cliente no sabe seu nmero esse pode ser verificado no cadastro.
Se a fita perdeu a etiqueta com o nmero no pode ser alugada at ser re-etiquetada pelo
gerente.
Quando o cliente devolve a fita calculado o nmero de dias que ficou com ela.
De acordo com a classificao de preo da fita calculado o valor do aluguel, cobrado
imediatamente do cliente.
O sistema fornece vrios relatrios, porm os mais importantes so: clientes em
atraso (mais de 3 dias com a fita), fitas perdidas, fitas mais alugadas, fitas menos
alugadas.
Identificao de Problemas
Algumas vezes o nmero da fita ou do cliente digitado errado e ningum
percebe.
Clientes s so conhecidos na loja em que esto cadastrados.
O Cliente no pode ter uma conta para pagar no fi m do ms.
Identificao de Oportunidades
Uso de cdigo de barras nas fitas
Uso de tecnologia Internet para integrar as lojas
46
V.8.5 Descrio do Sistema Proposto

Objetivo
O sistema deve permitir o controle de aluguel e estoque de fitas em todas as lojas
da rede Movieland de forma integrada.
Metas
Diminuir o nmero de fitas pouco ou no alugadas por loja e pela rede
Aumentar o nmero de aluguis por cliente
Mtricas para avaliao das Metas
Nmero mdio de fitas no alugadas por loja
Nmero mdio de fitas Pouco alugadas por loja
Nmero de fitas no alugadas para a rede
Nmero de fitas pouco alugadas para a rede
Nmero mdio de fitas alugadas por cliente
Requisitos Funcionais Iniciais
Repetir todas as funes bsicas do sistema anterior.
Permitir a existncia de contas para os clientes.
Permitir a reserva de fitas.
Controle de Estoque geral e local
Requisitos de Informao Iniciais
Relatrio de fitas a transferir
Requisitos No Funcionais Iniciais
O sistema deve funcionar simulando a existncia de uma rede, i.e., ele deve
guardar as informaes em uma base local, transmitindo-as de tempos em tempos para a
base central, de onde recuperar as informaes necessrias.
Restries
Cada sistema local pode estar no mximo 12 h atrasado em relao ao sistema
global.
V.8.6 Cronograma Provisrio
O sistema levar aproximadamente 1 ano para ser desenvolvido.
47
V.8.7 Custo Provisrio

O custo total do sistema dever ser de R$ 200.000,00, dividido em 12 parcelas
mensais com o custo mximo de R$20.000,00.
V.8.8 Outras Clusulas
Exclusividade
Todo produto desenvolvido nesse sistema ser de propriedade exclusiva da
Movieland, incluindo manuais do usurio, cdigo, documentos intermedirios, etc... Ao
final do projeto ser entregue a Movieland um CD- ROM contendo todos os produtos do
desenvolvimento.
Excetuam-se da clusula de exclusividade as bibliotecas bsicas fornecidas pela
Software Legal, que sero assim identificadas na documentao entregues.
Forma de pagamento
O pagamento ser feito por meio de cobrana bancria, devendo ser efetuados at
5 dias teis aps o envio da cobrana.
Reajustes
Por Ter durao igual a um ano, o contrato no pode sofrer reajustes.
Renegociao
De comum acordo entre as partes, o contrato poder ser renegociado para
representar mudanas nas funcionalidades desejadas ou correes no esforo planejado
para desenvolv-lo.
Confidencialidade
A Software Legal garante a confidencialidade das informaes fornecidas pela
Movieland.
48
Captulo VI. Levantando os Requisitos

Tpicos Abordados
Requisitos
Elicitao de Requisitos
O que so requisitos de um sistema? E de um usurio? Vamos tentar entender

nesse captulo os vrios tipos de requisitos:
Requisitos do usurio: o que o usurio deseja d o software ou o sistema como um
todo; o que o usurio quer. So escritos pelo prprio usurio ou levantados por um
analista de sistemas que consulta o usurio.
Requisitos do sistema: o que exigido do sistema como um todo, incluindo
hardware e software. O comportamento desejado do sistema. So normalmente
levantados por engenheiros, refinando os requisitos do usurios e os transformando em
termos de engenharia.
Requisitos do software: o que exigido do software, o comportamento desejado
do software.
Requisito funcional: uma ao a ser executada pelo software, incluindo sua
entrada, o processamento a ser executado e possivelmente incluindo interao com o
usurio, outro software ou um hardware, e a sada resultante.
Requisito no-funcional: um atributo de um requisito funcional, como a facilidade
com que uma funo pode ser executada pelos usurios
Requisito de desempenho: um tipo de requisito no funcional que faz uma
exigncia de desempenho a uma funo especfica, normalmente ligada ao tempo de
execuo, mas tambm podendo ser uma restrio no uso de memria, alm de outras
formas de utilizar recursos limitados.
Restrio: um restrio de projeto, imposta por algum motivo externo a
funcionalidade do sistema, como a plataforma de hardware ou o sistema operacional no
qual ser usado.
Confiabilidade, segurana, etc...: So requisitos no funcionais melhores
compreendidos segundo uma abordagem de qualidade.
A principal tarefa de um analista descobrir o que o sistema deve fazer.
Usualmente, chamamos isso de requisitos do sistema. O problema que ningum
realmente sabe o que um sistema desejado deve fazer, inclusive o cliente. Descobrir os
requisitos de um sistema uma tarefa investigativa e criativa.
Quando um cliente solicita um sistema, pensa em automao de algum processo,
na modernizao de um processo j automatizado ou na criao de um novo processo
em sua empresa. O cliente ento imagina um sistema que executa algumas funes,
gerencia alguns dados e fornece alguns relatrios. Esse sistema imaginado pelo cliente,
porm, raramente o que ele realmente precisa, ou que precisar no dia que o sistema
49
ficar pronto. Cabe ao analista ajudar ao cliente descobrir como o sistema realmente
necessrio.
Dizemos ento que cabe ao analista desenvolver uma especificao do sistema
que contenha todos os requisitos verdadeiros e nada alm desses{Palmer &
McMenamim 1991 ID: 10}. Um requisito verdadeiro quando reflete uma caracterstica
do sistema que deve existir qualquer que seja a tecnologia utilizada para implementlo. Assim, uma especificao ser defeituosa se no contiver todos os requisitos
necessrios ou se contiver algum requisito falso ou esprio.
Um requisito falso ou esprio quando o sistema teoricamente capaz de
cumprir suas funes sem que esse requisito seja implementado. Requisitos falsos podem
ser gerados em funo da tecnologia ou por arbitrariedade do analista.
Cada requisito falso presente em uma especificao ir aumentar a complexidade,
o tempo de desenvolvimento e o custo de desenvolver um sistema, ao mesmo tempo
diminuindo as chances de que este sistema tenha qualidade suficiente para atender ao
usurio quando pronto, ou mesmo diminuindo as chances do sistema ficar pronto! Assim,
devemos evitar ao mximo incluir requisitos falsos em uma especificao. Para isso,
importante conhecer seus principais tipos:
Requisitos tecnolgicos includos pelo passado, quando inclumos na especificao
algo que existe na implementao existentes mas que no necessrio ao
funcionamento do sistema;
Requisitos tecnolgicos includos por antecipao, quando inclumos algo na
especificao em funo de alguma tecnologia escolhida para a implementao;
Requisitos arbitrrios includos por influncia da ferramenta de modelagem,
quando inclumos na especificao algo desnecessrio para fazer o sistema, mas
necessrio por alguma caracterstica da ferramenta de modelagem, e
Requisitos arbitrrios includos por preciosismo, quando inclumos uma funo
espria no sistema.
VI.1 Requisitos Funcionais e No Funcionais

Uma maneira de dividir os requisitos do sistema separ -los entre requisitos
funcionais e no funcionais.
Os eventos definem basicamente todos os requisitos funcionais do sistema, dado
que a funo dele responder a todos os eventos. Porm, muitas vezes no s difcil
descobrir quais so os requisitos no-funcionais, mas tambm produzir uma especificao
do sistema que possa ser cumprida em custo razovel e prazo hbil de forma a atender os
usurios.
Um exemplo tpico seriam dois requisitos funcionais que, genericamente, so
opostos: velocidade e transportabilidade. Ora, para fazer um software muito veloz voc
precisa adapt-lo especificamente para o ambiente onde ele est funcionando. Para fazer
um software transportvel, voc precisa implement-lo de forma a funcionar no maior
nmero possvel de ambientes. Normalmente esses dois requisitos funcionam de forma
inversa.
50
VI.2 Requisitos Verdadeiros e Falsos

Um requisito verdadeiro quando o sistema deve cumpri-lo qualquer que seja a
tecnologia de implementao escolhida. Se um sistema pode cumprir sua finalidade sem
que um requisito seja implementado, ento esse requisito falso.
Requisitos falsos aparecem de vrias formas dentro do sistema: por cpia de
sistemas antigos, por hbito do analista, por pensarmos na tecnologia antes do tempo.
Requisitos falsos tecnolgicos so aqueles includos em um sistema por antecipao de
alguma caracterstica tecnolgica futura, como a linguagem de programao a ser
utilizada, ou por alguma caracterstica tecnolgica passada, como o tipo de arquivo em
que esto guardados os dados atualmente. Requisitos tecnolgicos arbitrrios so
includos pelos analistas, ou por excesso ou por caractersticas da ferramenta de
modelagem sendo utilizadas.
O principal problema de introduzir requisitos falsos que eles aumentam de
vrias formas o risco do projeto no se completar a contento. Um requisito falso, por si
s, pode mascarar um requisito verdadeiro. Porm, o acmulo de requis itos falsos
geralmente aumenta a complexidade do sistema, de tal modo que pode tornar sua
implementao invivel.
Assim, a busca dos requisitos verdadeiros, e apenas esses, deve ser uma das
principais formas de garantir o sucesso de um projeto.
VI.3 Conceitos e Definies

A elicitao de requisitos o levantamento e registro das expectativas dos
diversos agentes envolvidos com o sistema, seguido da consolidao e validao dessas
expectativas para, finalmente, transform -las nos objetivos e metas do sistema.
Contemplar essas diferentes vises implica projetar interesses divergentes e concili-los.
Esta seo desenvolve a proposta de utilizao da Engenharia de Requisitos e suas
metodologias, tcnicas e procedimentos como recurso para essa construo.
O Aurlio define requisito como exigncia legal necessria para certos efeitos.
O IEEE Standard 610 (1990) define requisitos como uma condio ou
capacidade necessria a um usurio para resolver um problema ou atingir um objetivo
ou como a condio ou capacidade que um sistema ou componente de um sistema
precisa possuir para satisfazer um contrato, padro, especificao ou outro documento
formal de exigncia.
Especificao de Requisitos constituda por dois passos: elicitao dos
requisitos dos usurios e representao desses requisitos obtidos (Zeroual [89])
Especificao de Requisitos uma das fases da Anlise de Requisitos e consiste de
trs operaes interrelacionadas: elicitao de requisitos, especificao e validao,
onde especificao significa a representao dos requisitos (Kramer [88]).
Especificao de Requisitos o documento que especifica os requisitos para um
sistema ou componente (IEEE [90]).
51
Embora essas definies tenham por alvo o desenvolvimento de software, so

gerais o suficiente para aplicao em outras reas e situaes; justificando, ento, sua
utilizao como fonte do conhecimento para enderear o problema proposto. Os
objetivos dessa forma estabelecidos representam a conciliao das expectativas,
necessidades e pontos de vista sobre qualidade de todos aqueles direta ou indiretamente
envolvidos com o projeto.
Esse processo, entretanto, no se completa em apenas um ciclo. O cliente vive em
um ambiente em evoluo permanente. Novos desafios e oportunidades, novos problemas
e restries surgem com freqncia. Isso cria a necessidade de um processo de
realimentao ao longo de todo o ciclo de desenvolvimento do projeto, proporcionando a
oportunidade de modificar requisitos j estabelecidos a partir da deteco de novas
informaes. A Elicitao de Requisitos repetida ao longo do projeto como
conseqncia do aumento do conhecimento sobre o domnio, realizao dos limites da
tecnologia e o aumento do entendimento do problema por parte dos clientes (Armitage
[96]). Na verdade, a realimentao est presente durante o prprio ciclo de elicitao, no
momento em que um requisito precisa ser modificado para atender uma nova expectativa
ou pela adoo de outro requisito. O quadro [xx] registra a relao entre os pontos de
vista dos pesquisadores citados e evidencia a preocupao mais recente com o
gerenciamento do processo, no sentido de manter as Especificaes de Requisitos em
permanente evoluo. A Engenharia de Requisitos pode ser vista, ento, como a seguinte
seqncia de atividades:
Coleta de
Informaes
Consolidao e
Conciliao
Registro
Validao
Adoo
Acompanhamento
Figura 11. Seqncia de atividades da Engenharia de Requisitos
VI.4 As Tcnicas de Elicitao

Aqui so apresentadas as classificaes que diversos pesquisadores sugerem para
as tcnicas de elicitao, acompanhadas de descries sucintas daquelas consideradas
adequadas para aplicaes na rea de projetos de qualidade. As descries procuram
evitar a restrio da orientao para o desenvolvimento de software, valorizando o escopo
maior de um projeto genrico.
Essas abordagens compreendem metodologias, mtodos, tcnicas e
procedimentos que proporcionam os recursos para o levantamento, conciliao e
consolidao, validao, registro, adoo e acompanhamento de requisitos de projeto.
52
Macaulay [96] classifica as tcnicas de Elicitao de Requisitos em trs grandes

grupos:
Abordagens voltadas para o sistema organizacional
Abordagens voltadas para grupos
Abordagens interativas
VI.4.1 Abordagens voltadas para o sistema organizacional
Onde so includas as tcnicas que, de uma forma geral, endeream a necessidade
de definir as metas de um projeto no contexto da organizao como um todo, incluindo,
alm da tecnologia, seu ambiente poltico e social. Os exemplos principais so:
Soft Systems Methodology (SSM) - Checkland [81] - uma abordagem sistmica para
soluo de problemas, apropriada para as situaes complexas. Um dos seus objetivos
incorporar o indivduo partcipe de um projeto ao trabalho de desenvolvimento do
projeto. Segundo Christel [92], enfatiza a subjetividade, propiciando a deteco dos
vrios pontos de vista, todos eles legtimos, sobre o problema ou situao em tela.
Para Macaulay [96], a SSM tem caractersticas de orientao para objetivos e de
apoio anlise, a partir de vrias perspectivas. Tem como caractersticas mais
marcantes: tratamento da situao no ambiente mais amplo no qual o projeto est
situado; foco na mudana, determinando-a por comparao da situao proposta com
a atual; atendimento a mltiplas perspectivas, proporcionando um mecanismo para
identificar e resolver conflitos. Finigan [94], estudo de caso sobre transferncia de
tecnologia, aponta o sucesso do uso da SSM como ferramenta de elicitao, tanto na
qualidade da informao obtida quanto na resposta dos participantes entrevistados. A
importncia dessa abordagem no contexto de um Programa de Qualidade est na
possibilidade de contribuir para as anlises do problema e das alternativas de soluo,
para a reflexo sobre a organizao corrente e identificao do seu potencial de
mudana, alm de ajudar a identificar e conciliar conflitos entre pontos de vista
divergentes.
Effective Technical and Human Implementation of Computer Based Systems
(ETHICS) Mumford [86] uma proposta baseada na abordagem participativa para
desenvolvimento de projetos. Adicionalmente, alinha-se com a viso scio-tcnica de
que o sucesso de um projeto tanto funo da tecnologia quanto dos fatores sociais e
organizacionais. ETHICS tem algumas similaridades com SSM visto que tambm
envolve comparao entre a situao corrente e a situao ideal. Essa comparao
leva identificao do que preciso mudar e porque. Alm da valorizao da meta de
proporcionar satisfao aos envolvidos no processo, sua caracterstica mais
importante no mbito dessa discusso a capacidade de apoiar a identificao dos
objetivos do projeto a partir dos pontos de vista dos diferentes agentes. Esses agentes
participam do processo de levantamento de requisitos, analisando seus papis e
estabelecendo objetivos tanto para a eficincia e a eficcia das atividades do projeto
quanto para a satisfao com suas prprias atividades.
H outra tcnica importante que pode ser includa nessa classificao:

Anlise de Metas e Objetivos. Tcnica cujo objetivo, de acordo com Loucopoulos e
Karakostas [95], a colocao dos requisitos em um ambiente mais amplo, para
compreender como se relacionam com os problemas e objetivos do sistema maior do
53
qual fazem parte. Os autores recomendam a reviso dos requisitos sob o ponto de
vista organizacional, verificando o alinhamento dos requisitos com os objetivos da
organizao. Essa reviso est contemplada nas abordagens anteriores no momento
em que preconizam a elicitao, consolidao e conciliao dos pontos de vista dos
diversos interessados.
VI.4.2 Abordagens voltadas para grupos
Onde so colocadas as tcnicas que, de uma forma geral, endeream a
necessidade de estabelecer mecanismos apropriados de comunicao entre grupos e
pessoas como parte do processo de Elicitao de Requisitos. Segundo Goguen [93],
proporcionam uma interao mais natural entre as pessoas do que as entrevistas. Essa
interao , certamente, um fator facilitador da resoluo de conflitos. So citadas pela
autora:
JAD (Joint Application Design), usada desde a dcada de 70, quando foi introduzida
pela IBM, e apresentada, por exemplo, em JAD - Joint Application Design de Judy H.
August, McGraw Hill, 1991. Consiste de uma srie de reunies estruturadas entre
projetistas e usurios, conduzidas por um facilitador, para planejar, projetar ou
tomar decises em conjunto. Entre suas vantagens, esto o estmuloprovocado pelo
trabalho em grupo; o foco em qualidade e produtividade, provocado pela nfase dada
participao do usurio; e o alinhamento da tecnologia com os negcios, provocado
pelo envolvimento dos usurios com o estabelecimento dos requisitos. Para Macaulay
[96], entre outras caractersticas, a tcnica proporciona oportunidades para a anlise
do problema, cria possibilidades de identificao e conciliao de pontos de vista
divergentes, prov procedimentos para documentar requisitos e ajuda a desenvolver
conhecimento sobre opes tecnolgicas.
QFD (Quality Function Deployment ), originria da indstria automobilstica
japonesa, traduz requisitos de consumidores em requisitos tcnicos apropriados para
o desenvolvimento de produtos. QFD baseada em sesses nas quais os grupos de
interesse trabalham em torno de uma matriz (casa da qualidade) que relaciona
requisitos de usurios com os atributos desejados para o projeto. Isso permite a
identificao das relaes entre requisitos e os atributos da qualidade necessrios ao
processo de maximizao da satisfao do cliente com um projeto de engenharia. A
similaridade dos procedimentos da fase de planejamento do QFD com as atividades
de Elicitao de Requisitos justifica a afirmao contida em Christel [92] sobre a
facilidade de adaptao dos passos daquela em procedimento para essa. Como
caractersticas importantes dessa abordagem Macaulay [96] cita, entre outras, o apoio
s atividades de identificao e especificao de atributos de qualidade, s descries
de usurios e grupos de usurios tpicos e identificao de requisitos de produtos
genricos. O QFD usado em Brynjolfsson [96] para construir a Matriz de
Mudanas, ferramenta proposta para identificar as interaes - e o grau de
estabilidade existente nessas interaes - entre os processos que ocorrem durante a
mudana e assim detectar interferncias, pontos sensveis e otimizar o planejamento
das atividades de transio. Adiano [xx] prope um QFD Dinmico que vem ao
encontro de uma das necessidades mais importantes de um plano de implantao de
TQM: a incorporao ao processo em tempo real - da evoluo das expectativas e
necessidades dos usurios. A proposta implementa o QFD Dinmico como um
54
sistema de apoio deciso, onde laos de realimentao e sistemas de monitorao

combinam dados sobre satisfao dos usurios, controle estatstico de processo e
atributos de qualidade. Parmetros do processo so atualizados, dinamicamente, em
funo de medidas realizadas continuamente sobre indicadores relacionados a
atributos de qualidade quantificados sob o ponto de vista dos us urios.
CRC (Cooperative Requirements Capture), proposta apresentada pela autora em
Macaulay [96]. Semelhante tcnica JAD, a CRC constituda por uma srie de
reunies em que o papel do facilitador e dos participantes claramente definido. A
diferena que alm de usurios e projetistas, as reunies incluem a participao dos
outros agentes interessados. Alm disso, diferentemente da JAD e da QFD, a CRC
focaliza principalmente o contexto do usurio e trata com relevncia a identificao
da motivao para o negcio. Entre as caractersticas ressaltadas pela autora,
destacam-se
neste contexto: existncia de recursos para identificao e
documentao de requisitos, descries genricas de usurios e grupos de usurios
tpicos, identificao e descrio das prticas correntes do trabalho, identificao de
restries como custo, tempo e segurana, identificao e descrio de critrios de
aceitao, identificao e descrio de atributos de qualidade.
H outras tcnicas importantes que podem ser includas nessa classificao:
Brainstorm. Tipo de reunio durante a qual os participantes apresentam suas idias e
concepes, a respeito do projeto e seus desdobramentos, de maneira informal e
desvinculada de qualquer estrutura hierrquica. Essa tcnica estimula a imaginao e
a gerao de idias inovadoras, alm de explicitar mltiplas perspectivas (Armitage
[96]).
Anlise do Discurso, sugerida em Goguen [93]. Seria um exemplo de tcnica de
grupo capaz de explorar o conhecimento tcito, implcito. A ordem de participao na
reunio no preestabelecida; negociada em tempo real. Aquele que tem a palavra
explora seu assunto at o ponto em que sinttica e semanticamente possa encerr-lo,
e a palavra passada a outro participante.
Anlise de Ponto de Vista. Segundo Armitage [96], ponto de vista um conjunto de
necessidades e requisitos. Para Macaulay [96], ponto de vista algum ou alguma
coisa responsvel por processamento de informao. Darke [96] define como o
processo de identificar, compreender e representar diferentes perspectivas ou
conjunto de percepes do domnio do problema. O autor aponta que cada grupo de
interesse na Elicitao de Requisitos possui uma viso particular do processo e que
todas elas devem ser tratadas, inclusive em suas inconsistncias e conflitos. Leite [91]
define a resoluo de pontos de vista como o processo no qual as discrepncias entre
diferentes pontos de vista so identificadas, classificadas, avaliadas e integradas em
solues alternativas em uma nica representao. Prope, tambm, um processo para
resoluo de conflitos na validao de requisitos elicitados. Summerville [98] define
ponto de vista como a posio tomada por um indivduo quando examinando um
universo de discurso. Alm disso, relaciona, entre outras, as seguintes vantagens da
abordagem: reconhece explicitamente a diversidade de fontes de requisitos e
proporciona mecanismo para organizar e estruturar essa informao diversificada.
Armitage [96] e Macaulay [96] exemplificam com a Controlled Requirements
Expression (CORE) . Christel [92], alm da CORE, sugere o trabalho apresentado em
Delugach [91]. Delugach considera que a maior parte dos requisitos relevantes so
55
expressos por vrias vises, e que mesmo sendo possvel a consistncia e coerncia
interna, nem sempre h integrao, exigindo procedimentos de anlise, conciliao e
consolidao. Com base na proposta de Leite [91], e na adaptao da tcnica Delphi,
Werneck [95] prope a resoluo de pontos de vista no processo de elicitao de
conhecimento com a seqncia de procedimentos ilustrada pela Figura 12: identificar
o conhecimento, classificar e avaliar as divergncias e integrar os pontos de vista;
procedimentos diretamente aplicveis ao processo de qualidade.
Identificar
Classificar
Avaliar
Integrar
Figura 12. Fases da anlise de ponto de vista
VI.4.3 Abordagens interativas

Onde esto as tcnicas que, de uma forma geral, provocam a interao do
projetista com o usurio, endereando a necessidade dos primeiros melhor
compreenderem o trabalho dos usurios. So exemplos:
Observao. Processo ao longo do qual o projetista faz o papel de aprendiz ao assistir
o mestre (usurio) realizar sua tarefa. Com isso pretende compreender melhor tanto o
domnio do problema quanto o trabalho do usurio. Entre outras caractersticas
vantajosas do processo, registradas por Macaulay [96], esto a possibilidade de
reviso de procedimentos, identificao de necessidades de mudana, crescimento da
experincia concreta do projetista, identificao de restries, identificao e
especificao de atributos de qualidade. Por outro lado, algumas vezes, o projetista
pode anotar grande quantidade de dados irrelevantes. Outra barreira, em algumas
ocasies, a dificuldade de acesso aos locais de trabalho (Maiden [99]).
Grupos de Foco. Processo que tem por objetivo proporcionar a um grupo de usurios,
na presena do projetista, a livre discusso de assuntos de mtuo interesse, facilitando
a identificao da necessidade de mudanas e o desenvolvimento de uma viso
compartilhada do projeto (Macaulay [96]). Por outro lado, o projetista ganha
percepo sobre a forma de pensar e as prioridades dos usurios.
Workshops sobre o futuro, reunies com o objetivo de elucidar situaes confusas,
gerar vises sobre o futuro e discutir como essas vises podem ser realizadas.
H outras tcnicas importantes que podem ser includas nessa
classificao:
Cenrios. a descrio de uma seqncia de aes e eventos constituintes de alguma

tarefa genrica que o sistema deve realizar (Maiden [99]). Tcnica listada em
Armitage [96], pode ser acrescentada essa classificao de Macaulay. Segundo o
autor, um cenrio pode ser equiparado a uma storyboard que detalhe como o projeto
proposto atender determinado requisito do usurio. O cenrio, depois de criado,
analisado pelo projetista e pelo usurio que apontam provveis anomalias,
realimentam o processo e o alteram, se for o caso, para algo mais realista, mais
promissor ou mais adequado segundo seus pontos de vista. A anlise de cenrios o
processo de entender, analisar e descrever o comportamento de um sistema em termos
de caminhos particulares e, para Maral [xx], favorece a documentao de requisitos.
Segundo conclu1so do estudo de caso apresentado em Armitage [96], os cenrios
56
foram teis para obter a opinio dos usurios bem como para analisar as opes que
estariam disponveis em determinada fase do projeto.
Anlise de Protocolo. Situao durante a qual um especialista realiza uma tarefa ao
mesmo tempo em que a descreve passo a passo, em voz alta. H necessidade de
identificar as tarefas para as quais o processo adequado. Algumas vezes se torna
montono e demorado (Maiden[99]).
VI.5 A entrevista
Entre as tcnicas mais importantes de elicitao de requisitos est a entrevista.
Est constantemente presente dentro de outras as tcnicas porque, quase sempre, a
Elicitao de Requisitos em algum ponto - exige comunicao direta com os usurios e
outros interessados e a nica forma de comunicao, seja de que forma esteja disfarada,
a entrevista.
A entrevista procura explicitar o pensamento do entrevistado a respeito das suas
relaes com seu universo em determinada instncia, tanto como indivduo quanto como
profissional, revelando o conhecimento do entrevistado sobre as pessoas, objetos, fatos e
procedimentos com os quais interage.
Os objetivos so os mais diversos, por exemplo: estabelecer expectativas do
consumidor, verificar nveis de satisfao e necessidades atuais e futuras; estudar
tendncias na satisfao do cliente ao longo do tempo ou avaliar programas em
andamento.
O primeiro passo de uma entrevista determinar, entre outros aspectos: seus
propsitos ou objetivos; a informao necessria, e de quem obter, para alcanar esses
objetivos e os recursos disponveis para implementar e manter o processo de pesquisa.
Outros fatores merecem destaque: preciso na determinao da amostra; abrangncia e
relevncia do contedo da pesquisa e, essencial, a validao. Os resultados da entrevista
so sumariados em um relatrio interpretativo que inclui relato sobre os achados e as
recomendaes mais importantes. A anlise pode ser qualitativa ou quantitativa.
Normalmente, as entrevistas abertas esto no primeiro caso, enquanto que os
questionrios so analisados quantitativamente.
A responsabilidade do entrevistador tambm grande. Normalmente, alm das
entrevistas, ele que m integra as diferentes interpretaes, objetivos, metas, estilos de
comunicao, e o uso de terminologia. H tambm outras tarefas complexas como decidir
a oportunidade ou no de incluir certo tipo de informao no conjunto inicial de
requisitos. Finalmente, entrevistar e integrar toma tempo. Como os requisitos so
volteis, quanto mais longo o processo mais facilmente os requisitos deixam de atender
as necessidades e expectativas dos interessados. Todos esses encargos recomendam que o
analista conhea tanto as tcnicas de desenvolvimento quanto o domnio no qual se
insere.
Existem vrios tipos de entrevistas. Durante o processo de anlise, elas
normalmente seguem o seguinte processo:
Introduo inicial
Familiarizao com o ambiente
57
Busca de fatos
Verificao de informaes conseguidas de outras formas
Confirmao de informaes conseguidas com os candidatos
Acompanhamento, amplificao ou clarificao de entrevistas anteriores.
Outra grande varivel da entrevista o seu objetivo, entre outros:

Levantar informaes sobre a organizao
Levantar informaes sobre uma funo de negcio
Levantar informaes sobre um processo ou atividade
Descobrir problemas
Verificar fatos previamente levantados
Fornecer informao
Obter dicas para entrevistas futuras
H vrias formas de entrevista, entre elas: entrevista por questionrio; entrevista

aberta; entrevista estruturada.
VI.5.1 Entrevista por Questionrio

O questionrio muito usado como tcnica de entrevista, principalmente em
pesquisas de mercado e opinio. Exige preparao elaborada. Alguns aspectos
particulares do processo merecem destaque: emprego de vocabulrio adequado para o
pblico entrevistado; incluso de todos os contedos relevantes e de todas as
possibilidades de respostas; cuidado com os itens redundantes ou ambguos, contendo
mais de uma idia ou no relacionados com o propsito da pesquisa; redao clara;
execuo de testes de validade e confiabilidade da pesquisa.
H uma tenso no resolvida entre o uso do questionrio como um evento
interativo ou como instrumento neutro de medida. Por um lado, como entrevista, visto
como uma interao. Por outro lado, no interesse de torn-lo um instrumento, muitos
recursos da interao existentes na conversao no so permitidos, suprimindo recursos
de medida de incertezas de relevncia e interpretao.
Dificuldade importante o fato das palavras possurem significados diferentes
para pessoas diferentes em diferentes contextos. Em interaes normais essas questes de
interpretao so negociadas entre os participantes, mas em entrevistas com questionrios
o treinamento e o mtodo utilizados probem essa negociao. Alm disso, h
necessidade do uso de tcnicas especficas nem sempre do conhecimento dos projetistas
- para a construo e aplicao de questionrios. A menor ambigidade uma das
principais vantagens da entrevista via questionrio.
Para gerar bons itens de questionrio, devemos:

Evitar palavras ambguas ou vagas que tenham significados diferentes para pessoas
diferentes;
Redigir itens especficos, claros e concisos e descarte palavras suprfluas;
Incluir apenas uma idia por item;
Evitar itens com categorias de respostas desbalanceadas;
Evitar itens com dupla negao;
58
Evitar palavras especializadas, jarges, abreviaturas e anacronismos;

Redigir itens relevantes para a sua pesquisa;
Evitar itens demogrficos que identifiquem os entrevistados
VI.5.2 Entrevista Aberta

Esse tipo de entrevista evita muitos dos problemas dos questionrios. Cria outros.
O entrevistador formula uma questo e permite que o entrevistado responda como quiser.
O entrevistador pode pedir mais detalhes, mas no determina os termos da entrevista.
Permanecem, entretanto, as questes: as perguntas podem ser respondidas? A resposta
faz parte do repertrio normal do discurso do entrevistado ? H muitas coisas que as
pessoas sabem fazer mas no sabem descrever. H tambm o conhecimento tcito que
de difcil elicitao.
Os benefcios das entrevistas abertas so: a ausncia de restries, a possibilidade
de trabalhar uma viso ampla e geral de reas especficas e a expresso livre do
entrevistado.
H desvantagens tambm. A tarefa de entrevistar difcil e desgastante. O
entrevistador e o entrevistado precisam reconhecer a necessidade de mtua colaborao
ou o resultado no ser o desejado. H falta de procedimentos padronizados para
estruturar as informaes recebidas durante as entrevistas. A anlise da informao obtida
no trivial. difcil ouvir e registrar simultaneamente; principalmente, porque h fatos
que s tomam importncia depois de outros fatos serem conhecidos, e a ele j no foi
registrado. Da a importncia da gravao e da respectiva transcrio; fica mais fcil
selecionar e registrar o que relevante e validar com o entrevistado.
So exigncias para o relacionamento entre os participantes de uma entrevista:
respeito ao conhecimento e habilidade do especialista; percepo de expresses no
verbais; sensibilidade s diferenas culturais; cordialidade e cooperao.
VI.5.3 Entrevista Estruturada
Extrai informaes sobre reas especficas. importante entrevistar a
pessoa certa, adequada, apropriada. Vantagens: Respostas diretas, com menos
ambigidade, informao detalhada. Desvantagem bsica: as questes relevantes
precisam ser identificadas com antecedncia.
boa tcnica para ser usada aps uma pesquisa com questionrio, quando
possvel selecionar, entre as respostas, as partes int eressadas com maior potencial de
gerao de outras informaes
VI.5.4 O processo da entrevista
A processo de entrevista no se resume ao ato especfico da entrevista. Na
verdade ele comea muito antes e acaba muito depois. O processo normal da entrevista
inclui:
Determinao da necessidade da entrevista
Especificao do objetivo da entrevista
Seleo do entrevistado
59
Marcao da entrevista
Preparao das questes ou do roteiro
A entrevista propriamente dtita
Documentao da entrevista, incluindo os fatos e a informao conseguida durante a
entrevista
Reviso da transcrio da entrevista com o entrevistado
Correo da transcrio
Aceitao por parte do entrevistado
Arquivamento
VI.5.5 Preparando a entrevista

A preparao uma necessidade bsica da entrevista. No s precis amos preparar
a entrevista propriamente dita, mas tambm preparar a ns mesmos, como
entrevistadores, e ao entrevistado.
Uma entrevista deve ter um objetivo. Muitas vezes esse objeto no especfico,
principalmente na fase inicial do projeto. Mas deve ser claro, isso , quando expressado
deve permitir que entrevistador e entrevistado compreendam o motivo da entrevista.
A escolha do entrevistado o segundo aspecto importante. Devem ser escolhidas
as pessoas que permitam obter no fim da entrevista uma viso clara e o mais completa
possvel do problema, das diversas formas de analis-lo e solucion-lo. Nunca se deve
tratar um problema a partir de um nico nvel funcional, nem de uma nica viso
organizacional, pois estaramos correndo o srio risco de obter uma viso distorcida.
Devemos lembrar que nosso sistema afetar todos os nveis funcionais e departamentos
da instituio.
Dependendo do tipo de entrevista, ser necessrio um roteiro ou um questionrio.
No incio da anlise os roteiros levam a execuo de entrevistas abertas, no final
geralmente temos entrevistas por questionrios. Entrevistas estruturadas so preparadas
principalmente para esclarecimento de processos e atividades.,
Todos os roteiros e questionrios devem seguir o modelo padro, incluindo a
apresentao e a concluso da entrevista.
Outros aspectos fundamentais a serem preparados so:

A linguagem
A coerncia das perguntas
A programao dos horrios
importante estar preparado para a linguagem a ser usada na entrevista. Nisso

influenciam vrios fatores, como nvel cultural do entrevistado, terminologia do trabalho,
jargo da rea, etc. Devemos evitar ao mximo usar os nossos termos tcnicos e
aproveitar ao mximo a oportunidade de aprender os termos tcnicos do entrevistado. Se
necessrio, ler um pequeno texto esclarecedor sobre a rea e, sempre, ler o glossrio do
projeto.
60
A perguntas ou o roteiro devem ser coerentes. Para isso importante a

determinao do objetivo da entrevista. O entrevistado deve ter noo clara da finalidade
da entrevista e perceber sua utilidade.
Marque a entrevista com antecedncia, com confirmao de data, hora, durao e
local por todas as partes. As entrevistas devem ter 30, 60 ou 90 minutos, e no mximo
duas horas. As entrevistas iniciais podem ser mais longas, enquanto as entrevistas finais
devem ser mais rpidas.
Evite horrios perto da hora do almoo ou no final de expediente, ou em uma
tarde de sexta- feita ou vspera de feriado.
Obtenha o telefone do entrevistado, para poder avis-lo de sua ausncia em caso
de urgncia.
Prepare o equipamento, principalmente um gravador. Tenha pelo menos 2 horas
de fita e um jogo de pilhas extras para o gravador. Tenha um caderno de anotaes (
melhor que um bloco) reservado para o projeto. Canetas de vrias cores, lpis, borrachas.
Chegue sempre 10 minutos adiantado e esteja preparado para esperar e para ter
que encerrar a entrevista mais cedo, principalmente com a alta gerncia. Se possvel, caso
a entrevista seja mais curta que o combinado, marque imediatamente a sua continuao.
VI.5.6 Realizando a entrevista

O objetivo normal de uma entrevista conseguir informaes do entrevistado,
para isso devemos fazer no s que o usurio fale, mas tambm que ele pense.
importante para o entrevistador no assumir nada e no fazer pr-julgamentos,
caso contrrio correr o risco de fazer uma entrevista viciada.
O entrevistador deve manter o controle o assunto da entrevista. No deixe o
entrevistador mudar de assunto ou tergiversar, mantendo suas perguntas direcionadas
para o objetivo da entrevista.
As duas principais armas do entrevistador so a pergunta e o silncio. Para
perguntar devemos ter conscincia do tipo de pergunta que escolhemos. Se queremos que
o usurio explique algo, ento devemos utilizar uma pergunta aberta. Isso muito comu m
em entrevistas abertas no incio da anlise.
O importante fazer o usurio pensar, para isso devemos evitar perguntas que
contenham a prpria resposta, exigindo apenas um sim/no como resposta. As perguntas
fechadas devem ser utilizadas para tirar dvidas do entrevistador.
Em dvida, pergunta novamente de outra forma. Pea que processo complicados
sejam explicados mais de uma vez, preferencialmente sob perspectivas diferentes.
Use questes comeando com quem, qual, quando, onde, porque e
como sempre que possvel. Tente completar o ciclo (quem-qual-quando-onde-porquecomo) para todos os assuntos.
61
Antes de mudar de assunto, verifique sua compreenso, explicando de forma

resumida o que acabou de ouvir. Isso permite ao entrevistado pensar e dar uma
clarificao se necessrio
No tenha pressa, no responda pelo entrevistado. No se preocupe com a demora
para responder ou o silncio. O silncio, inclusive, uma boa ttica para fazer o
entrevistado continuar falando. Deixe o entrevistado pensar, olhe para ele curiosamente.
Esteja atento para a ausncia de crticas por parte do candidato. Isso pode ser
causado pela falta de confiana do entrevistado em voc ou porque o problema
constrangedor demais para ser tratado. O analista deve constatar esse fato no processo de
anlise, mas no durante a entrevista.
Observe (e anote) as interrupes casadas por fatores externos (telefone, pessoas
que entram e que saem, etc...).
Separa o que fato do que opinio.
Conclua a entrevista de forma positiva
VI.5.7 O Comportamento do Entrevistador
Esteja atento ao prprio comportamento. Lembre -se que no importa sua inteno
ao fazer ou deixar de fazer algo, mas a interpretao que o entrevistado dar ou que fizer
ou no fizer.
Fisicamente, no faa mo vimentos desnecessrios como bater o lpis na mesa,
mexer as chaves no bolso, etc. Movimentos automticos e cacoetes distraem o
entrevistado e podem tambm ser interpretados como falta de ateno. No fume, mas
tambm no evite que seu entrevistado fume. No constranja o entrevistado comentado
sobre os males do fumo. No pea caf, a no ser aceitar o oferecido.
Estabelea um horrio para a entrevista e o cumpra rigidamente. Chegue 10
minutos antes.
Mantenha o interesse. Tome notas, mas no seja obsessivo, principalmente no
interrompa o candidato para manter suas notas atualizadas. Grave a entrevista e a reveja
mais tarde se necessrio. Escute ativamente sem interromper. O entrevistado que deve
falar a maior parte do tempo.
Utilize um tom educado e corts. No seja engraado, sarcstico ou depreciativo.
No faa comentrios pejorativos ou preconceituosos. No faa comentrios sobre
poltica e religio, ou outro tema controverso. Seja cordial, mas sem deixar de ser
profissional. Pergunte e responda com cortesia e honestidade. No de opinies
particulares, mesmo quando pedido. A entrevista o momento de levantar informaes,
no de emiti-las.
No de a um entrevistados informaes passadas por outros entrevistados.
Educadamente, responda que no cabe a voc a deciso ou a opinio.
Evite de toda a forma confrontar o entrevistado. No torne a entrevista um
interrogatrio. Evite discutir, mesmo que no concorde com o usurio. Em caso de
discusso, defina claramente o motivo do desacordo, seja ele motivado por fato ou por
62
opinio. Utilize perguntas para restabelecer a comunicao em caso de desacordo. Se

necessrio, pea desculpas.
Basicamente estamos pedindo que seja educado.
VI.5.8 Roteiro Bsico
Apresente-se ao entrevistado: Ol, muito prazer, eu sou fulano-de-tal, responsvel
por parte do projeto XYZ. Apresente seu carto de visitas se for o primeiro encontro.
Informe ao entrevistado o motivo da entrevista e porque foi selecionado: Estou aqui
para levantar o funcionamento da sua rea, e seu nome foi escolhido por ser o
funcionrio mais experiente ou Estou aqui para levantar o funcionamento da
atividade X, que de sua responsabilidade
Deixe clara a idia que o conhecimento e as opinies do entrevistado so importantes
e sero teis no processo de anlise
Diga o que vai acontecer com a informao levantada
Garanta que o entrevistado ler a transcrio da entrevista e ter a oportunidade de
corrigi-la, garanta que nada ser passado a outras pessoas sem a reviso e verificao
do entrevistado
Determine os assuntos confidenciais ou restritos a serem tratados na entrevista
Deixe claro que no haver conseqncias negativas em funo do resultado da
entrevista
Solicite permisso para gravar a entrevista
Se autorizado Inicie a gravao com um texto de apresentao: Entrevista realizada
no dia X...
Faa a entrevista at faltarem 5 ou 10 minutos para o tempo determinado
Avise ao entrevistado que o tempo est acabando e pergunte se gostaria de adicionar
alguma informao
Solicite ao candidato que responda as .perguntas de concluso
Se necessrio, marque outra entrevista
Entregue ao candidato o formulrio de avaliao de entrevista e o envelope
correspondente. Ensine-o a enviar a avaliao preenchida.
Despea-se educadamente, agradecendo a ateno e o tempo dispensada.
VI.5.9 Documentando a Entrevista
O mais rpido possvel aps realizar um entrevista, deve document-la. Ao
document-la rapidamente, estar garantindo que recuperar mais informao.
A documentao da entrevista deve fornecer a seguinte informao.

A data, hora e local da entrevista
Nome do entrevistador
Cargo do entrevistador
Nome do entrevistado
Funo do entrevistado e a descrio desse cargo
Se necessrio, informaes de background do entrevistado, como experincia no
cargo ou com computadores.
63
Organograma do entrevistado (superior imediato, colegas do mesmo nvel,

subordinados)
O objetivo da entrevista
Nomes e ttulos de todos os outros presentes na entrevista
Um descrio completa dos fatos e opinies do entrevistado
Opcionalmente, uma transcrio da entrevista, possivelmente expurgada das falas que
no tinham relao com o assunto da entrevista
Todas as concluses tiradas dos fatos e opinies como apresentados
Todos os problemas de negcio levantados durante a entrevista
Exemplos de todos os relatrios, diagramas, documentos, etc. Discutidos durante a
entrevista
Todos os desenhos e diagramas feitos a partir ou durante a entrevista
Qualquer comentrio relevante feito pelo entrevistado
Todos os nmeros relevantes (quantidades, volume de dados, etc.) coletados durante a
entrevista.
importante notar que o relatrio da entrevista deve ser aceito pelo entrevistado.
normal o entrevistado remover alguma coisa ou colocar algo a mais. O analista deve
ficar atento aos motivos do usurio em fazer modificaes.
Se houver discusso quanto a interpretao de algo e o analista achar essencial
manter sua verso no relatrio, deve tambm permitir que o entrevistado coloque sua
verso.
VI.5.10
As perguntas de concluso
Ao final da entrevista, importante realizar uma avaliao da percepo do

entrevistado sobre a entrevista que acabou de ser realizada. Para isso necessrio que
seja respondido um formulrio, contendo perguntas como:
Voc acha que essa entrevista cobriu tudo que era necessrio?
Voc acha que foram feitas as perguntas certas?
Voc acha que era a pessoa mais certa para responder essas perguntas?
VI.6 JAD
Outra tcnica importante, que merece um tratamento separado, o JAD.
Muitas vezes, quando um grupo de inform tica entrega um sistema de informao
aos seus clientes escuta a frase: no era isso que eu queria! Isto acontece porque os
desenvolvedores no conseguiram levantar com os usurios suas verdadeiras
necessidades.
Este problema de comunicao pode ter diversas causas: linguagem especializada
de ambas as partes, desconhecimento da rea de atuao pelos desenvolvedores,
preocupaes com a tecnologia empregada ao invs das necessidades dos usurios, etc.
Na fase inicial do projeto, conhecida como anlise, a dificuldade de comunicao entre
clientes e equipe de desenvolvimento a principal causa de defeitos que sero
encontrados no produto final.
64
Para enfrentar os problemas de comunicao entre desenvolvedores e usurios,

foram desenvolvidos, ao final da dcada de 1970, vrios mtodos onde o
desenvolvimento de sistemas baseado na dinmica de grupo.
Na forma tradicional de desenvolver sistemas os analistas entrevistam os usurios,
um aps outro, tomando notas que so mais tarde consolidadas e ento validadas com o
usurio, finalmente se transformando em um documento de anlise.
O JAD, Joint Application Design, ou Mtodo de Projeto Interativo, substitui as
entrevistas individuais por reunies de grupo, onde participam representantes dos
usurios e os representantes dos desenvolvedores.
Quando o mtodo aplicado de forma correta, os resultados alcanados
ultrapassam os objetivos imediatos da obteno de informao dos usurios e cria um
ambiente de alta sinergia na equipe, onde todos se sentem comprome tidos com as
solues encontradas. Esse comprometimento permite que todos se considerem
proprietrios e colaboradores no desenvolvimento do sistema.
VI.6.1 O Objetivo do Mtodo
O objetivo do mtodo extrair informaes de alta qualidade dos usurios, em
curto espao de tempo, atravs de reunies estruturadas para alcanar decises por
consenso.
VI.6.2 Os Componentes
O lder de sesso tem como tarefa nmero um conduzir o grupo para solues de
consenso. Esse lder de sesso age como facilitador, um servidor neutro dentro do grupo
que no avalia nem contribui com idias. A responsabilidade do facilitador sugerir
mtodos e procedimentos que ajudem o grupo a concentrar energia em tarefas
especficas, garantindo a todos os membros do grupo condies de participar.
O documentador um auxiliar imparcial do lder de sesso, responsvel pelo
registro das decises e especificaes produzidas. Apenas as informaes relevantes so
documentadas, segundo orientao do lder de sesso.
O patrocinador detm a autoridade formal sobre as reas afetadas pelo sistema,
estabelecendo diretrizes e objetivos do projeto.
A equipe responsvel pelo contedo da sesso, representando as reas
envolvidas no projeto.
VI.6.3 A Dinmica
A base de trabalho a equipe presente na reunio. Para que no acontea como na
figura abaixo devemos combinar algumas regras de jogo, de modo a alcanar o
mximo de produtividade. natural que em um grupo de 15 pessoas surjam discusses,
conversas paralelas, interrupes, etc. Em respeito ao tempo precioso dos participantes
vamos necessrio estabelecer um cdigo de cooperao.
65
VI.6.4 O Ambiente
O Ambiente fsico da reunio fundamental para a produtividade dos trabalhos.
Os seguintes aspectos devem ser considerados:
Os participantes devem estar organizados de forma a poderem se olhar e olhar para o

lder de sesso. A melhor arrumao a em forma de U.
No devem acontecer interrupes aos participantes.
Todos devem cumprir a agenda, principalmente o incio e o fim da reunio.
VI.6.5 O Consenso
A forma mais produtiva de deciso do grupo aquela obtida por consenso.
Consenso no a unanimidade de opinies, mas, sim, a situao em que cada membro
concorda que a soluo encontrada a melhor para o grupo e que possvel conviver
com ela sem ferir convices ou valores essenciais.
VI.7 A abordagem de Boehm

Barry Boehm e diversos colaboradores desenvolvem, no USC Center for
Software Engineering, uma abordagem baseada na negociao, que tambm pode ser
considerada para emprego no estabelecimento de objetivos de um Programa de Qualidade
Total. A proposta constituda por trs elementos (Boehm [98]), um dos quais, a
ferramenta, no est no escopo desta tarefa:
Teoria W: teoria de gerenciamento que estabelece que a condio necessria e
suficiente para o sucesso de um projeto que todos os interessados sejam ganhadores.
Modelo espiral WinWin: extenso do modelo espiral de desenvolvimento de software
por adio das atividades da Teoria W ao incio de cada ciclo.
WinWin: ferramenta para trabalho cooperativo que facilita a negociao entre os
interessados.
VI.7.1 A Teoria W
Em muitas das tcnicas sugeridas, o conciliar de interesses foi citado como
um dos aspectos mais importantes da Engenharia de Requisitos. A teoria W (Bohem [89])
foi desenvolvida para ajudar a resolver esse tipo de problema sob o princpio fundamental
de transformar todos em ganhadores. As outras tcnicas que tm instrumentos para
estimular e facilitar a conciliao no exigem isso. O voto muitas vezes uma maneira de
ajustar interesses ou de afastar divergncias. Isso no acontece na teoria W; todos tm
que conhecer suas posies de ganho. Alm disso, preconiza a administrao do risco,
para dar ateno s situaes que possam causar dificuldades ou comprometer as
condies de ganho de qualquer dos participantes.
O problema primrio de um gerente de projeto de software a necessidade de
satisfazer simultaneamente uma variedade de pessoas direta ou indiretamente
interessadas.
As expectativas diferentes de todos esses agentes criam conflitos. Uma boa teoria
de gerenciamento de software, deve ajudar a resolver esses conflitos. Segundo o prprio
66
autor, a teoria W muito til para gerenciamento de produo de software, mas aplicvel
tambm em outras reas. Os procedimentos sugeridos por Boehm podem ser descritos da
seguinte forma:
compreender o que as pessoas julgam ser ganhar, identificando e ouvindo as pessoaschave de cada categoria interessada;
estabelecer expectativas razoveis, reunindo os interessados para que:
olhem as questes pelo ponto de vista dos outros;
procurem por critrios de soluo relevantes e objetivos para
todos;
identifiquem e resolvam suas divergncias de pontos de vista;
associar tarefas com condies de ganho;
proporcionar um ambiente de apoio;
estabelecer um plano de processo realstico ;
usar o plano para controlar o projeto;
identificar e gerenciar os riscos;
manter o envolvimento das pessoas em nvel elevado.
VI.7.2 O modelo de negociao
Boehm [98] apresenta um modelo de negociao que proporciona um instrumento
efetivo para o processo de conciliao de pontos de vista divergentes. O modelo
descrito da seguinte forma (Figura 13):
Qualquer condio no controversa coberta por um acordo.
Caso contrrio, gerada uma questo para registrar o conflito.
As opes permitem que os envolvidos sugiram solues alternativas, que endeream
as questes.
As opes so exploradas e refinadas via anlise, gerenciamento de expectativas e
negociao, eventualmente levando a um acordo.
condies
de ganho
questes
opes
acordos
Figura 13. O modelo de negociao de Boehm
VI.7.3 O modelo espiral WinWin

O modelo espiral WinWin a integrao da Teoria W (Boehm [89]) com o
modelo espiral de desenvolvimento (Bohem [88]). Acrescenta atividades da Teoria W no
incio de cada ciclo e explicitamente enfatiza o envolvimento colaborativo e contnuo
das pessoas interessadas nas definies preliminares e ao longo do projeto. A teoria W
67
usada para convergir em objetivos, restries e alternativas para um nvel seguinte de

projeto. O processo espiral WinWin realiza isso em dois passos (Boehm [95]):
identifica os interessados e suas condies de ganho;
reconcilia essas condies atravs de negociao para chegar a um conjunto de
objetivos, restries e alternativas que seja satisfatrio para todos no prximo nvel.
Identificar as condies de ganho
dos interessados
Identificar os interessados
do prximo nvel
Reconciliar as condies de ganho.

Estabelecer o prximo nvel
objetivos, restries e alternativas
Validar
definio
dos
processos
Rever os compromissos
de
Avaliar as alternativas.
Analisar os riscos
Definir prximo nvel de
processo
Figura 14. O modelo espiral Win-Win de Boehm
Os trs passos iniciais levam aos objetivos, restries e alternativas necessrios

para cada ciclo do espiral. Durante cada ciclo os interessados refinam as definies do
problema (requisitos) e suas solues (projetos e planos). Tambm definido um
conjunto de pontos de apoio nos quais a consistncia e a viabilidade do problema e as
solues definidas so revistas como base para as decises de gerncia.
A abordagem de Boehm , portanto, um instrumento flexvel que
proporciona oportunidades para:
Estabelecimento de pr -condies de ganho para todos
Anlise de alternativas
Anlise de riscos
Reviso de posturas
Negociao e conciliao de interesses conflitantes
68

Modelagem SI PDF

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Modelagem SI PDF

Caricato da

Copyright:

Formati disponibili

Modelagem de Sistemas de

Modelagem de Sistemas de Informao

Copyright 2002 Geraldo Xexo e Jos Antnio Moreira Xexo

IV.5.2 Cenrios ............................................................................................... 29

VI.6.2 Os Componentes................................ ................................ ..................... 65

Captulo I. Desenvolvendo Sistemas de

Nesse caso, estaramos entrando no campo da Inteligncia Artificial.

Captulo II. Sistemas de Informao

De forma objetiva, Um Sistema de Informao moderno coleta dados no ambiente

Os benefcios e os custos resultantes do uso dos computadores nas empresas

A Evoluo dos Sistemas de Informao

II.3.1 Quatro Dcadas de Software

A maioria dos dicionrios no diferencia eficincia de eficcia, o que comumente feito na

de 50 a meados de 60 prevaleceu aplicao customizada com distribuio limitada.

De forma mais informal, podemos dizer que passamos das mquinas

II.3.2 Modelo das Trs Eras de Ward

A categorizao das eras no determina seus limites com preciso. H

Classificao dos Sistemas de Informaes

As organizaes utilizam SI para aplicaes desde processamento de transaes

A classificao hierrquica contm 4 nveis ou tipos de sistemas:

Planejamento Estratgico: refere -se ao processo de decidir sobre os objetivos da

Os trs processos citados utilizam informaes com caractersticas diferentes.

Apresenta quatro tipos de sistemas:

tornar disponveis informaes sobre a ocorrncia de eventos operacionais especficos

Tabela 1. Organizao e sistemas de informao segundo Laudon

Em sntese, a proposta de Laudon classifica os sistemas em::

Os Sistemas do Modelo Hierrquico

II.5.1 Sistemas de Processamento de Transaes

Formatted: Font: Bold

processamento de folhas de pagamento e emisso de contracheques.

As caractersticas desses sistemas de processamento de transaes que se

II.5.2 Sistemas de Planejamento e Controle Operacional

II.5.3 Sistemas de Planejamento e Controle Gerencial

II.5.4 Sistemas de Planejamento Estratgico

Segundo Shore [88], as principais caractersticas desse tipo de sistema so:

Earl [89] considera que um SI tem potencial estratgico se possibilita a obteno

King [92] considera que um SI estratgico se possui um efeito profundo no

Blaschek [95] identificou vrias classificaes para SIs Estratgicos:

Taxonomia Relacionada a Classificao de Anthony

II.6.1 Sistemas de Informao para Executivos

Suas caractersticas principais so:

Os benefcios ao processo de tomada de deciso so, principalmente:

II.6.2 Comparao dos SIE com os SAD e SIG

principais diferenas, como listadas por R. Sprague e apresentadas em Furlan [94], so as

usa info dos

Tabela 2. Diferenas essenciais entre SIE, SAD e SIG (fonte:

Situao atual dos SI nas empresas

Atualmente a maioria das empresas trabalha com Sistemas de Informao

Captulo III. Desenvolvimento de Sistemas

III.1 Objetivos do Desenvolvimento

quando falha, o faz de forma graciosa e recupervel

Essa uma importante filosofia e que, junto com os princpios da modelagem

III.2 Processo de Desenvolvimento de Software

III.3 Ciclo de Vida

Testes, onde verificamos e validamos o software

Manuteno, onde garantimos a utilizabilidade do software

Esse Ciclo de Vida, defendido inicialmente como a forma correta de desenvolver

Figura 2. O Ciclo de Vida em Cascata ou Seqencial

Figura 3. O Ciclo de Vida de Prototipagem

III.3.3 Ciclos de Vida Evolucionrios

Figura 4. O Ciclo de Vida Incremental

Ciclo de Vida Espiral

Em cada ciclo da espiral, algumas ativades so realizadas em ordem seqncial: