ria.ua.pt · 2016. 3. 8. · 5.10 Plano de Distribuição ... Figura 12 – Actividades da tarefa...

Palavras-chave

Balanced Scorecard; Sistemas de Informação; Engenharia de Software

Resumo

As condições para a sobrevivência e actuação das organizações nos mercados actuais,caracterizados pela sua cada vez maior globalidade, exigência e competitividade impuserama necessidade urgente da adopção de novas filosofias de gestão. As organizações quebuscam o êxito vêem-se obrigadas a focalizar-se numa estratégia, bem definida, estruturadae disseminada por toda a organização, e principalmente orientada à satisfação dos seusclientes. Neste contexto, o Balanced Scorecard (BSC) tem vindo a ganhar cada vez maispopularidade pela inovação que veio trazer à gestão das organizações, uma vez que a suafilosofia assenta na difusão da visão e estratégia por toda a organização tendo em vista ummais efectivo alinhamento dos diversos níveis hierárquicos. Com o aparecimento do BSC, surgiram também sistemas de informação (SI) para apoiar asua implementação, cada um com características próprias e diferentes abrangências.Decorrente da observação dessa realidade e partindo do principio de que haveriam aindanecessidades não satisfeitas aos utilizadores deste tipo de SI, surgiu a motivação pararealizar este trabalho, que se prende com o estudo do suporte tecnológico ao BSC. Maisconcretamente, debruçamo-nos sobre o estudo das funcionalidades consideradas maisrelevantes presentes nos SI de suporte ao BSC. Este trabalho foi desenvolvido em três fases: estudo do suporte tecnológico ao BSC atravésda análise de informação publicada pelo instituto Balanced Scorecard Collaborative (BSCol);análise das características dos SI presentes no mercado e certificados pelo instituto BSCol;inquirição de organizações nacionais e estrangeiras com experiência de uso deste tipo desistemas de informação. Como complemento do estudo realizado, numa segunda fase destetrabalho é proposta uma arquitectura para a concepção de um SI de suporte ao BSC. A contribuição deste trabalho foi a criação de uma lista das funcionalidades consideradasmais relevantes pela comunidade utilizadora de SI de suporte ao BSC, constituindo um guiapara qualquer organização que pretenda implementar um sistema de informação da área doBSC. De um outro ponto de vista, a proposta de um modelo conceptual assume-se bastanteenriquecedora e adequada, a quem pretenda desenvolver ou aprofundar o estudo deste tipode sistemas de informação.

Keywords

Balanced Scorecard; Information Systems; Software Engineering.

Abstract

Organizational survivor and actuation in the present business environment is characterized byits constant exigency and competitiveness imposed by the urgency to adopt new businessmanagement philosophies. The organizations who want to be well succeeded have to focus ina well defined and structured strategy, disseminated along all the organization, and principallyoriented to its stakeholder’s satisfaction. In this context, the Balanced Scorecard (BSC) haswinning more and more popularity by the innovation brought to organization’s management,because its philosophy settles in the diffusion of the vision and strategy along all theorganization as a mean align the hierarchic levels around same values. With the BSC emergence, also appeared information systems to support its implementation,each one with unique features and different scopes. Due to this reality and assuming thatcurrent software applications do not yet satisfy all customers’ needs, arose the motivation torealize this study on the BSC technological support. Particularly, this study is about therelevant features in information systems related to one BSC business tool. This work was been developed in three phases: first, we studied the BSC technologicalsupport through the analysis of published documentation by the Balanced ScorecardCollaborative institute (BSCol), then we analyzed the certified software applications’ featuresand, finally we inquired some organizations with experience on this type of informationsystems. Has a complement to this study, the second part of this work presents a conceptualmodel of an information system to support this business tool. This work contribution was the conceptualization of a list with the important features in oneBSC technological support application. This list can be useful to guide the organizations whowant to implement a BSC information system. On the other hand, to the software-houseswhich want to develop an information system to support the BSC concepts, we think that thisstudy can help them in that task.

i

Índice

Índice de figuras ......................................................................................................................................v Índice de tabelas..................................................................................................................................... ix Índice de gráficos ...................................................................................................................................xi Capítulo I - Introdução

1.1 Enquadramento .......................................................................................................................3 1.2 Objectivos principais ..............................................................................................................3 1.3 Metodologia..............................................................................................................................4 1.4 Estrutura da dissertação..........................................................................................................4

Capítulo II - Balanced Scorecard

2.1 Contexto ...................................................................................................................................9 2.2 Conceito..................................................................................................................................11 2.3 Perspectivas ............................................................................................................................12 2.4 Pontos fortes e limitações ....................................................................................................20 2.5 Implementação do BSC........................................................................................................21 2.6 O BSC na Mobil North America Marketing e Refining ..................................................23 2.7 Resumo ...................................................................................................................................25

Capítulo III - Suporte Tecnológico ao BSC

3.1 Enquadramento .....................................................................................................................29 3.2 Requisitos................................................................................................................................30 3.3 Oferta tecnológica .................................................................................................................34 3.4 Análise dos dados recolhidos...............................................................................................44 3.5 Lista de funcionalidades .......................................................................................................61 3.6 Resumo ...................................................................................................................................63

Capítulo IV - Metodologias de Desenvolvimento de Software

4.1 Enquadramento .....................................................................................................................67 4.2 Rational Unified Process ......................................................................................................68 4.3 Iconix.......................................................................................................................................74 4.4 Extreme Programming .........................................................................................................79 4.5 Microsoft Solutions Framework .........................................................................................81 4.6 Resumo ...................................................................................................................................84

iii

Capítulo V - Archetypus Scorecard 5.1 Âmbito ....................................................................................................................................87 5.2 Plano de Desenvolvimento do Sistema..............................................................................88 5.3 ARCHETYPUS – O nome..................................................................................................90 5.4 Visão Geral do Sistema.........................................................................................................90 5.5 Glossário.................................................................................................................................96 5.6 Lista de Riscos .......................................................................................................................98 5.7 Modelo de Casos de Uso....................................................................................................100 5.8 Modelo de Análise e Desenho...........................................................................................119 5.9 Modelo de Implementação ................................................................................................127 5.10 Plano de Distribuição .......................................................................................................133 5.11 Protótipo de Interface ......................................................................................................134 5.12 Resumo ...............................................................................................................................142

Capítulo VI - Conclusões

6.1 Conclusões............................................................................................................................147 6.2 Desenvolvimentos Futuros................................................................................................148

Bibliografia

Bibliografia..................................................................................................................................151 Recursos electrónicos ................................................................................................................153

Anexos

Anexo A – Engenharia de Requisitos ....................................................................................159 Anexo B – Fornecedores certificados....................................................................................173 Anexo C – Funcionalidades dos Sistemas de Informação..................................................177 Anexo D – Inquéritos...............................................................................................................181 Anexo E – Development Case ...............................................................................................214 Anexo F – Correspondência entre Casos de Uso e Requisitos modelados .....................189 Anexo G – Casos de Uso .........................................................................................................195 Anexo H – Protótipo de Interface..........................................................................................213 Anexo I – Esquema de Tabelas.............................................................................................214 Anexo J – Dados dos inquéritos ...........................................................................................229 Anexo K – Terminologia UML...............................................................................................237

v

Índice de figuras

Figura 1 – Componentes do BSC.......................................................................................................13 Figura 2 – Temas de cada perspectiva ...............................................................................................14 Figura 3 – Principais indicadores da perspectiva do cliente ...........................................................16 Figura 4 – O modelo genérico da cadeia de valor............................................................................18 Figura 5 – Os objectivos estratégicos da Mobil NAM&R .............................................................23 Figura 6 – Custo de correcção de problemas ...................................................................................70 Figura 7 – Conceitos do RUP .............................................................................................................71 Figura 8 – Estrutura do RUP: duas dimensões ................................................................................72 Figura 9 – Visão geral do ICONIX....................................................................................................75 Figura 10 – Actividades da tarefa de análise de requisitos ..............................................................76 Figura 11 – Actividades da tarefa de análise e desenho preliminar ...............................................77 Figura 12 – Actividades da tarefa de desenho ..................................................................................77 Figura 13 – Actividades da tarefa de implementação ......................................................................78 Figura 14 – Modelo do processo MSF ..............................................................................................82 Figura 15 – Principais artefactos produzidos no âmbito do RUP.................................................88 Figura 16 – Símbolo Archetypus ........................................................................................................90 Figura 17 – Arquitectura do sistema ..................................................................................................92 Figura 18 – Modelos de interacção dos utilizadores com o sistema .............................................93 Figura 19 – Diagrama de casos de uso "Modelo Principal" .........................................................101 Figura 20 – Diagrama de casos de uso "Comunicação"................................................................109 Figura 21 – Diagrama de casos de uso "Negócio".........................................................................114 Figura 22 – Diagrama de casos de uso "Flexibilidade" .................................................................116 Figura 23 – Diagrama de classes: nível organizacional ..................................................................119 Figura 24 – Diagrama de classes: componentes padrão do modelo............................................120 Figura 25 – Diagrama de classes: pessoas e papéis desempenhados...........................................123 Figura 26 – Diagrama de classes: recursos de informação............................................................124 Figura 27 – Diagrama de classes: parâmetros .................................................................................125 Figura 28 – Diagrama de classes completo .....................................................................................126 Figura 29 – Diagrama de pacotes de componentes: geral.............................................................128 Figura 30 – Diagrama de componentes: detalhe por pacote ........................................................128 Figura 31 – Diagrama de componentes: detalhe por pacote ........................................................129

vii

Figura 32 – Diagrama de componentes: nível organizacional......................................................130 Figura 33 – Diagrama de componentes: componentes padrão do modelo scorecard .................130 Figura 34 – Diagrama de componentes: diversos papéis assumidos pelas pessoas ..................131 Figura 35 – Diagrama de componentes: recursos de informação ...............................................131 Figura 36 – Diagrama de componentes: parametrização do sistema ..........................................132 Figura 37 – Diagrama de componentes: arquivo, importação e exportação..............................132 Figura 38 – Plano de distribuição .....................................................................................................133 Figura 39 – Mapa do site Archetypus ..............................................................................................134 Figura 40 – Interface: acesso .............................................................................................................135 Figura 41 – Interface: mapa scorecard organizacional ......................................................................136 Figura 42 – Interface: mapa scorecard pessoal...................................................................................137 Figura 43 – Interface: mapa estratégico...........................................................................................138 Figura 44 – Interface: mapa do modelo scorecard ............................................................................139 Figura 45 – Interface: formulário "Valores de Indicadores" ........................................................139 Figura 46 – Interface: formulário "Indicadores" ............................................................................140 Figura 47 – Interface: formulário "Formatos de Apresentação" .................................................141 Figura 48 – Interface: formulário “Permissões”.............................................................................142 Figura 49 – Processo de Engenharia de Requisitos .......................................................................214 Figura 50 – Custo de correcção de um defeito de requisito .........................................................214 Figura 51 – Modelo para documento de especificação de requisitos..........................................214 Figura 52 – Diagrama de casos de uso para categoria “Modelo Principal” ...............................214 Figura 53 – Diagrama de casos de uso para categoria “Comunicação”......................................214 Figura 54 – Diagrama de casos de uso para categoria “Negócio”...............................................214 Figura 55 – Diagrama de casos de uso para categoria “Flexibilidade” .......................................214 Figura 56 – Principais diagramas da linguagem UML ...................................................................214

ix

Índice de tabelas

Tabela 1 – Os dez mandamentos da implementação do BSC .......................................................22 Tabela 2 – Lista final de funcionalidades...........................................................................................63 Tabela 3 – Actores do sistema ............................................................................................................92 Tabela 4 – Lista de funcionalidades exigidas ....................................................................................95 Tabela 5 – Lista de riscos do sistema.................................................................................................99 Tabela 6 – Prioridade de requisitos ..................................................................................................214

xi

Índice de gráficos

Gráfico 1 – Funcionalidades Existentes: construção do modelo principal (scorecard) .................45 Gráfico 2 – Funcionalidades Existentes: comunicação...................................................................47 Gráfico 3 – Funcionalidades Existentes: negócio (componentes de análise) ..............................48 Gráfico 4 – Funcionalidades Existentes: flexibilidade.....................................................................50 Gráfico 5 – Funcionalidades Existentes: características técnicas...................................................51 Gráfico 6 – Funcionalidades Utilizadas: construção do modelo principal...................................52 Gráfico 7 – Funcionalidades Utilizadas: comunicação....................................................................53 Gráfico 8 – Importância de Funcionalidades: concepção do modelo principal..........................54 Gráfico 9 – Importância de Funcionalidades: comunicação ..........................................................56 Gráfico 10 – Importância de Funcionalidades: negócio .................................................................57 Gráfico 11 – Importância de Funcionalidades: flexiblidade...........................................................58 Gráfico 12 – Importância de Funcionalidades: características técnicas........................................58

“If you can’t measure it, you can’t manage it” (KAPLAN e NORTON, 1996a)

Capítulo I

INTRODUÇÃO

• Enquadramento

• Objectivos

• Metodologia

• Estrutura da dissertação

CAPÍTULO 1 – INTRODUÇÃO

3

1.1 ENQUADRAMENTO

O actual mercado em que as organizações actuam caracteriza-se pela sua cada vez maior

globalidade e alta competitividade, provocando gradualmente a mudança dos processos de gestão e

induzindo o surgimento de novos instrumentos de gestão. Agora, mais do que nunca, as organizações

que buscam o êxito vêem-se obrigadas a focalizar-se numa estratégia de longo prazo, bem definida,

disseminada por toda a organização e principalmente orientada à satisfação dos seus clientes.

Neste contexto, em que a gestão do desempenho organizacional assume uma importância

extrema, surgiram vários instrumentos baseados na gestão do desempenho, sendo o Balanced Scorecard

(BSC) aquele que se distinguiu devido à inovação que veio trazer relativamente aos instrumentos de

gestão tradicionais que apenas se focalizavam em indicadores de cariz financeiro. O BSC permite às

organizações uma rápida adequação a mercados e meios económicos em constante mutação, pois além

de analisar o seu passado (perspectivas financeira e de clientes) introduz novas formas de potenciar o

futuro (perspectivas de processos internos e aprendizagem e crescimento) sempre com uma orientação

comum: o cliente.

Mais do que um instrumento de gestão composto por indicadores, o BSC pode ser

considerado um sistema de partilha de informação, pois, sendo o seu objectivo a difusão e alinhamento

da visão e estratégia ao longo de toda uma organização, este processo depende de uma cultura

organizacional, nomeadamente nos níveis hierárquicos superiores, aberta à disponibilização e partilha

da informação com todos os colaboradores da organização.

Acreditando que o BSC apresenta boas perspectivas de utilização pelas organizações num

futuro próximo e, sabendo que este instrumento de gestão provoca um aumento considerável da

informação a circular no seio da organização, temos consciência que o seu suporte num sistema de

informação próprio apresenta inúmeras vantagens. Nesse sentido, justifica-se o estudo do suporte

tecnológico ao BSC, bem como as necessidades reais da comunidade de utilizadores deste tipo de

sistemas de informação.

1.2 OBJECTIVOS PRINCIPAIS

O problema inicialmente constatado prendia-se com a adequação dos sistemas de informação

para suporte ao BSC às implementações reais em organizações. Para solucionar este problema foram

estabelecidos os seguintes objectivos principais, a alcançar no fim deste estudo:

• Estabelecimento de uma lista das funcionalidades consideradas mais relevantes presentes

nos sistemas de informação que suportam o BSC.

SUPORTE TECNOLÓGICO AO BALANCED SCORECARD

4

• Construção de um modelo conceptual de um sistema de informação para suporte à

implementação de uma estratégia baseada nos princípios do BSC.

1.3 METODOLOGIA

Para a realização deste trabalho definiu-se uma metodologia composta por três fases

complementares. A primeira fase consiste no estudo dos conceitos fundamentais do instrumento de

gestão BSC e ilustração de um caso de estudo. A segunda, no estudo das aplicações informáticas

específicas para o BSC e posterior inquérito de organizações com experiência nesta área, tendo como

finalidade a constituição de uma lista das funcionalidades consideradas mais relevantes. Finalmente, é

desenvolvida uma arquitectura para um sistema de informação que suporte para além das

funcionalidades básicas, também as consideradas mais relevantes para as organizações, utilizando a

metodologia de desenvolvimento de software: RUP (Rational Unified Process).

1.4 ESTRUTURA DA DISSERTAÇÃO

Este documento foi organizado de uma forma coerente tendo em vista facilitar ao leitor a

compreensão da sequência do estudo realizado, desde o início da constatação da necessidade de

estudar o suporte tecnológico ao BSC até ao desenvolvimento do SI proposto.

Começa-se por estudar e caracterizar o instrumento de gestão estratégica BSC, explicitando:

conceitos básicos da sua filosofia, pontos fortes, limitações e questões a ter em linha de conta aquando

duma implementação, finalizando-se o capítulo com a ilustração de um caso real de implementação do

BSC.

De seguida, no terceiro capítulo, é estudada a oferta tecnológica existente, centrando a análise

nas funcionalidades dos SI consideradas mais relevantes para as organizações. Este estudo é realizado

em três etapas, consistindo a primeira na análise de informação produzida pelo instituto Balanced

Scorecard Collaborative, a segunda no estudo das aplicações informáticas certificadas por este mesmo

instituto, e a terceira etapa na inquirição de diversas organizações, nacionais e estrangeiras, com

experiência neste tipo de sistemas de informação. Este capítulo fornece a “matéria-prima” para os

capítulos seguintes, cujo objectivo é a concepção de um modelo de um sistema de informação para

suporte ao BSC.

O quarto capítulo serve de introdução e suporte ao capítulo seguinte, pois antes da construção

do modelo conceptual do sistema de informação, achou-se por bem realizar um estudo das mais

recentes metodologias de desenvolvimento de software. Foram estudados os aspectos gerais das

seguintes metodologias: RUP (Rational Unified Process); ICONIX; XP (Extreme Programming) e MSF

(Microsoft Solutions Framework).

CAPÍTULO 1 – INTRODUÇÃO

5

No quinto capítulo é desenvolvido o SI proposto seguindo a componente estática da

metodologia RUP, isto é, desenvolvendo-se os principais modelos (artefactos) necessários à modelação

do sistema de informação.

Finalmente, no sexto capítulo é sintetizado todo o estudo realizado evidenciando as principais

conclusões extraídas ao longo dos capítulos anteriores. São também tecidas as conclusões finais,

terminando com sugestões de desenvolvimentos futuro no âmbito do trabalho realizado.

De uma forma geral, para não tornarmos os capítulos muito extensos, optámos por incorporar

em anexos diversa informação para complementar algumas matérias referidas no texto, bem como os

dados que sustentam algumas análises.

Capítulo II

BALANCED SCORECARD

• Contexto

• Conceito

• Implementação

• Caso de estudo: MOBIL NAM&R

CAPÍTULO 2 – BALANCED SCORECARD

9

O Balanced Scorecard tem vindo a ganhar cada vez mais popularidade pela inovação que veio trazer à gestão das organizações, desde que foi pela primeira vez apresentado ao mundo em 1992.

Embora já existissem e continuem a existir instrumentos de gestão baseados na medição do desempenho, este é inovador porque, enquanto os instrumentos tradicionais se focalizavam apenas em indicadores de cariz financeiro, este contém um conjunto de objectivos e indicadores agrupados em quatro perspectivas: financeira, clientes, processos internos e aprendizagem e crescimento.

Em 1997, a Harvard Business Review classificou o conceito Balanced Scorecard como uma das descobertas mais importantes nos últimos 75 anos.

Este capítulo expõe o conceito do Balanced Scorecard, começando por fazer uma referência ao contexto económico que motivou o seu aparecimento. De seguida, é apresentada a definição do conceito e a sua evolução desde que foi apresentado ao mundo pela primeira vez, referindo as opiniões e contribuições de vários autores.

Por fim, apresentam-se algumas dificuldades susceptíveis de aparecerem aquando dum processo de implementação do BSC e um exemplo de uma implementação real, onde se podem observar os objectivos e indicadores definidos.

2.1 CONTEXTO

Actualmente o contexto económico e concorrencial em que as organizações operam assume-se

cada vez mais complexo, sendo vital para qualquer organização a busca não só da eficácia no alcance

dos seus objectivos estratégicos, mas principalmente da eficiência. Para os gestores, a capacidade para

gerir com sucesso está directamente dependente da medição do desempenho dos processos de

negócio.

Já nos anos sessenta, em França, se utilizava uma ferramenta similar ao Balanced Scorecard

chamada Tableau de Bord. Era um “painel de instrumentos semelhante ao dos aviões” (EPSTEIN e

MANZONI, 1997) que mostrava a evolução temporal de vários rácios financeiros, evoluindo depois

para rácios não financeiros organizados de uma forma ad-hoc.


10

A ideia de ter uma imagem balanceada1 do desempenho da organização não é nova. Algumas

organizações utilizavam vários indicadores e alguns países têm tradição nesta área. Mas o Balanced

Scorecard desenvolvido por Kaplan e Norton constitui um avanço que vai além daquilo que muitas

organizações Francesas e Americanas fizeram (EPSTEIN e MANZONI, 1997). Estes autores

evidenciaram também três características que caracterizam o avanço que o Balanced Scorecard

possibilitou relativamente aos métodos tradicionais:

• Num único documento é apresentada uma série de indicadores que mostram de uma

forma global o desempenho da organização.

• Este documento está directamente conectado ao sistema de informação, providenciando

uma base para ir até ao detalhe.

• Os indicadores são agrupados em quatro categorias, reflectindo perspectivas distintas

sobre o desempenho da organização, todas ligadas à visão e estratégia definida.

Segundo Epstein e Manzoni (1997) o conceito de Balanced Scorecard surgiu a partir do

reconhecimento de que uma única perspectiva de análise (financeira) não apreende a complexidade do

desempenho organizacional.

Segundo Kaplan e Norton (1996a), os tradicionais indicadores financeiros revelavam-se

insuficientes para fazer face às constantes mudanças no ambiente competitivo actual. Reconheceu-se

que a avaliação do desempenho organizacional numa perspectiva puramente financeira não era

suficiente, num ambiente onde os activos não financeiros, as relações entre os diversos agentes

económicos e o aumento das capacidades das organizações são factores determinantes para o sucesso.

Uma leitura das diversas publicações apresentadas por Kaplan e Norton (1992; 1993), leva a

concluir que o conceito de Balanced Scorecard começou por ser entendido como um conjunto de

indicadores para avaliação do desempenho, mas depressa evoluiu, transformando-se num instrumento

de gestão orientado à missão e estratégia da empresa.

O Balanced Scorecard foi pela primeira vez apresentado em 1992 como um sistema para avaliação

do desempenho, resultado de um estudo publicado na Harvard Business Review intitulado “The

Balanced Scorecard – Measures That Drive Performance” iniciado dois anos antes envolvendo doze empresas,

cujo objectivo consistia no desenvolvimento de um novo modelo para avaliação do seu desempenho.

Nesse estudo Kaplan e Norton (1992) desenharam um modelo para o Balanced Scorecard – “um

conjunto de medidas e indicadores que proporcionam aos gestores uma visão rápida e compreensiva

1 Este conceito de “imagem balanceada” surge ligado à definição do nome “Balanced Scorecard” conforme os seus criadores o definiram: “como um balanço estabelecido entre os objectivos a curto e longo prazo, indicadores financeiros e não financeiros, lagging e leading indicators, perspectivas de desempenho interno e externo” (KAPLAN e NORTON, 1996a).


11

do negócio”. Este modelo é constituído por indicadores financeiros – lagging indicators2 – que reflectem

dados históricos, não podendo por isso ser geridos; e indicadores não financeiros – leading indicators3 –

determinando o desempenho futuro ao nível financeiro, porque medem o desempenho de cada uma

das áreas funcionais da organização na prossecução dos objectivos definidos (presentes nas

perspectivas: clientes, processos internos, aprendizagem e crescimento).

Em 1993 Kaplan e Norton redefiniram o conceito do Balanced Scorecard, referindo que mais do

que um “exercício de medição” ele é um instrumento de gestão estratégica com potencial para ajudar

no aperfeiçoamento de áreas críticas tais como: produtos, processos, clientes e mercado (KAPLAN e

NORTON, 1993). Kanji e Sá (2002) citando Kaplan, Norton e McClintock referem os seguintes

aspectos inovadores neste conceito:

• Divulgação da visão da organização e dos objectivos estratégicos ao longo de toda a

organização

• Clarificação da estratégia a seguir

• Alinhamento entre as necessidades dos clientes e os objectivos do negócio

• Concepção de um sistema de retribuições em função da eficácia e desempenho obtidos

• Alinhamento dos objectivos pessoais e por departamento com a estratégia global traçada,

dando a conhecer a cada elemento da organização o seu contributo para o sucesso futuro

da organização.

2.2 CONCEITO

O Balanced Scorecard assume-se como uma base de suporte à difusão da missão e estratégia de

negócio por toda a organização, contribuindo fortemente para o aumento do desempenho

organizacional. Sendo o objectivo final de qualquer organização o retorno do investimento para os

seus accionistas, o Balanced Scorecard procura atingir esse objectivo actuando sobre a valorização do

capital humano para melhorar a eficiência dos processos internos da organização.

C. Chow et al4, citados por Sousa e Rodrigues, definem o Balanced Scorecard como um conjunto

de indicadores financeiros e não financeiros referentes aos factores críticos de sucesso da empresa. O

factor inovador neste conceito prende-se com a construção das perspectivas de uma forma integrada.

2 Lagging Indicators – indicadores que reflectem os efeitos de decisões não quando elas são tomadas, mas quando o resultado dessas acções é materializado. Estão presentes na área financeira. 3 Leading Indicators – indicadores impulsionadores do nível de desempenho futuro da organização a nível financeiro. Estão presentes nas áreas: clientes, processos internos e aprendizagem e crescimento. 4 Chow C. W., et al. (1997), “Applying the Balanced Scorecard to Small Companies”, Management Accounting, Agosto, pp.21-27


12

“Mais do que quaisquer outros, Kaplan e Norton provavelmente merecem muito do crédito por

elucidarem e aumentarem o conhecimento sobre esta noção” (SOUSA e RODRIGUES, 2002).

O Balanced Scorecard como um instrumento de gestão estratégica integra indicadores em quatro

perspectivas: perspectiva financeira, perspectiva do cliente, perspectiva interna e perspectiva de

aprendizagem e crescimento, devidamente inter-relacionadas com a estratégia e visão da organização.

Conforme referem Kaplan e Norton (1996a), as quatro perspectivas reflectem o balanço entre os

objectivos a curto e a longo prazo, os resultados desejados e as indicadores escolhidos, entre os lagging

e os leading indicators e entre as perspectivas de desempenho interno e externo. Além disso, verifica-se

também que duas perspectivas medem o passado: Financeira e Satisfação dos clientes, enquanto que as

outras duas potenciam o futuro: Processos internos e Aprendizagem e crescimento.

Estes autores alertam que o processo de definição de indicadores não deve ser visto como um

mecanismo de controlo e avaliação do desempenho passado. Deve antes, servir para articular e

comunicar a estratégia de negócio ao longo de toda a organização e, providenciar o alinhamento das

medidas e acções tomadas com os objectivos globais.

É fundamental que o Balanced Scorecard não seja visto como um sistema de recolha e arquivo de

resultados obtidos, mas sim como um meio que indique os resultados que se pretendem obter. Desta

forma, actua difundindo a visão e as linhas estratégicas ao longo de toda a organização dando a

conhecer a cada pessoa que integra a organização qual o seu contributo para a realização da estratégia

definida. Citando Kaplan e Norton (1996a), o Balanced Scorecard deveria ser encarado como um sistema

de comunicação, informação e aprendizagem, e nunca como um sistema de controlo.

De acordo com os criadores do Balanced Scorecard a perspectiva financeira reflecte o

desempenho da gestão e do negócio, mas é essencial a definição de indicadores que orientem o

desempenho dos clientes, processos internos e pessoas para o sucesso futuro a nível financeiro.

Kanji propõe um novo modelo – Kanji’s Business Excellence Model (KBEM) – que complementa

do Balanced Scorecard tradicional com os princípios da gestão da qualidade total (TQM) e os factores

críticos de sucesso (FCS).

2.3 PERSPECTIVAS

É globalmente reconhecido que a avaliação do desempenho organizacional de uma perspectiva

puramente financeira não é suficiente num ambiente onde os activos não-financeiros, as relações de

negócio e o aumento das capacidades das organizações são determinantes para o sucesso (KAPLAN e

NORTON, 1996a).


13

O Balanced Scorecard, tal como os seus criadores o conceberam fornece aos gestores uma visão

da organização sobre quatro perspectivas, respondendo a quatro questões fundamentais: (KAPLAN e

NORTON, 1992)

• Como é que podemos cuidar dos interesses dos accionistas? (perspectiva financeira)

• Como é que os clientes nos vêem? (perspectiva do cliente)

• Como é que nos devemos distinguir? (perspectiva dos processos internos)

• Podemos continuar a aperfeiçoar-nos e a criar valor? (perspectiva de aprendizagem e cres-

cimento)

Perspectiva Financeira

Objectivos Indicadores

Perspectiva Interna


Perspectiva do Cliente


Perspectiva Aprendizagem e Crescimento


Visãoe

Estratégia

Como é que os clientes nos vêem?

Como é que podemos cuidar dos interesses dos accionistas?

Como é que nos podemos distinguir?

Podemos continuar a aperfeiçoar-nos e criar valor?

Figura 1 – Componentes do BSC (KAPLAN e NORTON, 1996)

Estas quatro perspectivas estão inter-relacionadas por uma relação de causa-efeito, sendo a

perspectiva financeira o ponto de partida para compreender essa relação. Assim, a questão principal na

perspectiva financeira prende-se com o retorno de investimento e com o valor que a empresa cria aos

seus accionistas. As outras três perspectivas podem ser explicadas através do seguinte raciocínio: Para a

empresa ser bem sucedida financeiramente, terá de combinar dois elementos:

• Criação de valor para os seus clientes – interessando obter qual a percepção dos clientes acerca

do desempenho da empresa. Epstein e Manzoni (1997) alertam que o processo de criação

de valor para os clientes tem de ser baseado na eficiência dos processos internos, para que

seja lucrativo também para a empresa.

• Providenciar bases para que esta criação de valor seja sustentável ao longo do tempo – depois de

analisadas as respostas ao ponto anterior, são identificadas acções a tomar, conduzindo a

modificações nos processos internos. Para garantir que os clientes continuarão a apreciar a

empresa no futuro, deve ser seguido um caminho de inovação constante devendo por isso


14

a empresa fomentar um clima de aprendizagem e desenvolvimento constante tanto ao

nível operacional como intelectual, no que diz respeito aos recursos humanos.

A figura seguinte expõe uma visão integral do modelo base do BSC indicando a razão de

existência para cada perspectiva, a sua ordem de causa e efeito e, por fim, as duas perspectivas que

medem o passado e as duas que induzem resultados futuros.


“Para maximizar o valor aos nossos accionistas que objectivos financeiros temos de alcançar?”

Perspectiva de Clientes

“Para alcançar os nossos objectivos financeiros, que necessidades de clientes temos de

satisfazer?”

Perspectiva Interna

“Para satisfazer os nossos clientes, em que processos internos temos de ser excelentes?”

Perspectiva Aprendizagem e Crescimento

“Para alcançar os nossos objectivos, com que infra-estruturas (pessoas, tecnologia, activos fixos e alianças) e como devemos aprender,

inovar, crescer?”

Visã

o In

tegr

al

Mec

anis

mos

Inte

rnos

R

esul

tado

s Ex

tern

os

Figura 2 – Temas de cada perspectiva

Como referem Epstein e Manzoni (1997) no artigo “The Balanced Scorecard and Tableau de Bord:

Translating Strategy Into Action”, os objectivos e indicadores de cada caixa devem ser adaptados à

realidade da empresa, integrando-se com a sua missão e estratégia. O BSC fixa os objectivos, partindo

do princípio de que as pessoas decidem quais as acções a tomar para os atingir. Ao contrário dos

sistemas tradicionais, o BSC tem em conta que a realidade está em constante mudança, definindo os in-

dicadores para que sejam coerentes com a missão e estratégia da empresa.

Kanji considera que as quatro perspectivas do Balanced Scorecard são muito restritas,

defendendo o alargamento do âmbito de cada uma delas. Na definição do seu modelo, Kanji defende

que para as perspectivas financeira e de clientes, devem ser considerados não só os accionistas e

clientes respectivamente, mas sim todos os entes que directa ou indirectamente são influenciados pela

organização, nomeadamente os investidores, comunidade, empregados, fornecedores, etc. Para a

perspectiva de processos internos, Kanji critica Kaplan e Norton por estes defenderem que “...os

gestores devem focalizar-se apenas nas operações internas críticas para a satisfação das necessidades

dos clientes...” (KANJI e SÁ, 2002), referindo que “numa organização todo o trabalho é processo”


15

devendo por isso, ser a organização a decidir quais os processos e competências a melhorar e

estabelecer indicadores para cada um. Relativamente à perspectiva de inovação e aprendizagem, Kanji

concorda com Kaplan e Norton quanto à necessidade das organizações melhorarem os produtos

existentes por um lado, e por outro ao desenvolvimento de novos, acrescentando que este clima de

melhoria contínua e inovação deve ser não só em relação aos produtos mas também aos processos

internos.

2.3.1 PERSPECTIVA FINANCEIRA

Todas as empresas têm o mesmo objectivo em comum, o de conseguir retornos dos capitais

investidos, sendo esta a questão principal levantada na perspectiva financeira do BSC.

Os indicadores devem ser construídos com base na análise dos factores críticos de sucesso, de

cada fase em que a empresa se encontra, de modo a traduzirem em que medida esses factores críticos

de sucesso estão a ser atingidos. Kaplan e Norton consideram três fases no ciclo de vida da empresa:

Crescimento, Manutenção e Maturidade.

As empresas que se encontram na fase de crescimento possuem produtos e serviços com

elevado potencial, mas também esta é uma fase em que é imprescindível fazer investimentos. Devem,

por isso, ser considerados objectivos como o crescimento das vendas e a manutenção de níveis de

despesas.

A fase de manutenção é caracterizada por uma estabilidade da empresa no mercado, pelo que a

principal preocupação é a manutenção/aumento da respectiva quota. Os investimentos necessários são

direccionados à melhoria contínua dos processos, sendo já esperado um retorno considerável do

investimento. Devem ser estabelecidos objectivos relacionados com a avaliação do retorno do

investimento, tais como os resultados operacionais e a margem bruta.

Na fase de maturidade, as empresas estão a colher os frutos decorrentes das duas fases

anteriores, tendo uma perspectiva de manutenção do negócio existente focalizando-se no cash flow.

Os objectivos e indicadores financeiros têm um duplo papel. Por um lado especificam os

resultados financeiros esperados e por outro são os alvos finais dos objectivos das restantes

perspectivas do BSC.

Kanji (2002) propõe, para a perspectiva financeira, que a organização se focalize em todos

aqueles com quem interage, ao invés de apenas nos accionistas. O valor para o accionista deve ser

entendido numa perspectiva do longo-prazo, crescimento futuro, risco e retorno. Esta perspectiva foi


16

baptizada de “Valor para o Investidor5” com um único objectivo principal que consistia no alcance da

excelência de negócio, tendo os seguintes indicadores: Indicadores financeiros (cash flow, margem de

lucros, retorno dos capitais próprios, rotação dos activos); Procura6; Alcance das metas; Estratégia de

curto e longo prazo; Comparação com os melhores do sector.

2.3.2 PERSPECTIVA DO CLIENTE

“As empresas devem desejar mais do que clientes satisfeitos e felizes; elas devem desejar

clientes rentáveis” (KAPLAN e NORTON, 1996b).

Qualquer empresa ambiciona ser considerada como a primeira na preferência dos seus clientes.

Enquanto que antes a empresa focalizava a sua atenção sobre a capacidade de produção, agora passou

a ter de concentrar a sua atenção sobre a satisfação do cliente final. A aquisição e a retenção dos

clientes existentes assumem-se como a únicas vias para sustentar a rendibilidade da empresa a longo

prazo.

Para esta perspectiva, a questão chave prende-se com a forma com os clientes vêem a empresa

e em que medida esta cria valor para eles. Nesta perspectiva são identificados os segmentos de

mercado alvo em que a empresa actua, e definidos indicadores que permitam analisar o nível de

satisfação e lealdade dos clientes conseguidos. Estes indicadores são relativos à satisfação de clientes,

retenção de clientes, aquisição de novos clientes, rendibilidade de clientes e quota de mercado, estando

todos inter-relacionados como se mostra na figura 3:

QUOTAMERCADO

AQUISIÇÃOCLIENTES

RETENÇÃOCLIENTES

RENTABILIDADECLIENTES

SATISFAÇÃOCLIENTES

Figura 3 – Principais indicadores da perspectiva do cliente (KAPLAN e NORTON, 1996a)

5 Neste contexto “Investidor” significa todos os entes que participam na actividade de uma organização, sendo directa ou indirectamente influenciados por esta no decorrer da sua actividade. 6 Os bens e serviços que o cliente procura no mercado.


17

Relativamente à quota de mercado interessa medir a penetração no mercado para o segmento

de clientes alvo. Um aumento das vendas a clientes que não pertençam ao segmento alvo indica um

desvio à estratégia delineada. Como Kaplan e Norton (1996b) referem, a medição da quota de mercado

nos segmentos alvo permite avaliar se a estratégia delineada estará a conduzir aos resultados esperados.

O conceito account share refere-se à medição da quota de mercado considerando a quota que a empresa

detém, no total de negócios desenvolvidos pelos clientes dos segmentos alvo.

A retenção de clientes é uma forma de manter/aumentar a quota de mercado, sendo, em

termos de custos, preferível reter os clientes actuais do que captar novos. Segundo Kaplan e Norton, as

empresas que tenham possibilidades de identificar os seus clientes, poderão medir o índice de retenção

de clientes periodicamente. No caso de empresas cujo objectivo passe por alargar a base de clientes,

poderá interessar medir a taxa de aquisição de novos clientes, através de indicadores como o número

de novos clientes, ou o volume de vendas a novos clientes em determinado segmento alvo.

Ambos os indicadores anteriormente nomeados fornecem informação relativa às necessidades

dos clientes. A medição do nível de satisfação dos clientes reflecte o desempenho da empresa, mas

Kaplan e Norton (1996b) alertam que o enfoque apenas na satisfação do cliente não é suficiente para

conseguir a sua retenção, rendibilidade e fidelidade. Apenas quando os clientes se mostram

completamente satisfeitos, é que a empresa pode contar que estes continuem a comprar.

Na avaliação da rendibilidade dos clientes poderão surgir alguns não lucrativos interessando,

nestas situações ter em atenção se o cliente é recente, uma vez que os custos de aquisição são

geralmente elevados, devendo então ser analisado o seu potencial de crescimento.

Esta perspectiva do Balanced Scorecard constitui uma base para os gestores articularem as suas

estratégias para clientes e mercados, com vista à obtenção de proveitos financeiros no futuro. Alguns

dos indicadores geralmente usados são:

• Concorrência: análise da situação dos concorrentes, com o objectivo de verificar o grau de

diferenciação.

• Retenção: análise da variação de compras e frequência de visitas aos clientes.

• Aquisição: análise do número de novos clientes e do custo médio da sua obtenção.

• Satisfação: análise do número de reclamações recebidas.

• Rendibilidade: determinação do rendimento obtido por cliente.

2.3.3 PERSPECTIVA INTERNA

Sendo o objectivo da empresa a distinção junto dos seus clientes, para que estes a reconheçam

como a melhor, deverá actuar sobre a sua área interna para obter e manter a liderança no seu mercado


18

alvo. Kaplan e Norton referem que desde que a empresa tenha uma visão clara dos seus clientes e dos

objectivos financeiros a atingir, então poderá determinar os meios de actuação para melhorar a

produtividade e diferenciar-se junto dos mesmos.

Os processos internos capacitam a empresa na oferta de valor aos clientes dos seus segmentos

alvo, devendo os indicadores para esta perspectiva ser definidos depois da definição dos indicadores

das perspectivas financeira e clientes.

Os indicadores utilizados estão relacionados com o ciclo de produção, custo unitário, prazos

de entrega, qualidade, produtividade, satisfação dos funcionários, etc.

Kaplan e Norton defendem a existência de um modelo da cadeia de valor, que deve ser

adoptado e depois desenvolvido aquando da construção desta perspectiva do Balanced Scorecard. Este

modelo é composto por três processos: processo de inovação, processo operacional, processo de

serviço pós-venda.

Figura 4 – O modelo genérico da cadeia de valor (SOUSA e RODRIGUES, 2002)

Kaplan e Norton definem o processo de inovação como o processo de criação de produtos

e/ou serviços com o objectivo de satisfazer as necessidades, emergentes ou não, dos clientes. O

processo operacional é a segunda etapa, e compreende a produção e entrega dos produtos/serviços aos

clientes. Neste processo interessa ser eficiente na entrega dos produtos ou serviços. O serviço pós-

venda é caracterizado pela prestação de serviços que contribuem para a satisfação do cliente,

compreendendo actividades relacionadas com a manutenção e reparação do produto/serviço,

tratamento de reclamações, serviço financeiro, etc.

Enquanto o Balanced Scorecard restringe o enfoque da organização nos processos críticos para a

satisfação do cliente, Kanji defende que “numa organização todo o trabalho é processo” devendo a

organização decidir quais os processos em que pretende distinguir-se, estabelecendo depois indicadores

para cada. Por isso, no modelo de Kanji (2002) esta perspectiva é chamada de “Excelência nos

processos”, uma vez que incide sobre todos os processos da organização, tendo os seguintes


19

indicadores: Percentagem de não-conformidades e atrasos; Productividade; Benchmarking; Aplicação de

modelos estatísticos adequados; Indicadores de desempenho para melhorar processos e produtos.

2.3.4 PERSPECTIVA APRENDIZAGEM E CRESCIMENTO

Esta perspectiva começou por ser chamada, em 1992 e 1993, de Inovação e Aprendizagem,

mas em 1996 Kaplan e Norton reconheceram que o processo de inovação deveria estar presente na

perspectiva de processos internos, tendo depois passado a chamar-se a esta perspectiva

“Aprendizagem e Crescimento”. Esta perspectiva tem como objectivo a construção de uma infra-

estrutura, que permita à empresa competir no futuro, infra-estrutura essa que permitirá a satisfação dos

objectivos das outras perspectivas.

Esta quarta perspectiva do Balanced Scorecard actua sobre o investimento na requalificação dos

recursos humanos, melhoria e adaptação dos sistemas de informação e reengenharia dos

procedimentos/rotinas da empresa, com a finalidade de criar a infra-estrutura que permita no futuro

um crescimento e melhoria contínua dos processos internos da organização.

Segundo Kaplan e Norton existem três factores que facilitam o processo de aprendizagem e

crescimento: formação dos trabalhadores, capacidades dos sistemas de informação e motivação dos

trabalhadores.

A formação dos colaboradores tem uma dupla função; uma de acompanhamento da evolução

constante da tecnologia e outra ao nível motivacional, procurando fomentar nos trabalhadores uma

postura mais proactiva.

Relativamente às capacidades dos sistemas de informação, o objectivo principal prende-se com

a difusão atempada de informação aos trabalhadores. Mas não basta que tenham acesso à informação,

têm igualmente de ser motivados a actuar em consistência com os interesses da empresa, concedendo-

lhes alguma liberdade de acção e de decisão. Para medir os resultados da motivação dos trabalhadores

usam-se os seguintes indicadores: sugestões recebidas versus sugestões implementadas, percentagem de

trabalhadores cujos objectivos pessoais sejam comuns aos do BSC, etc.

Kanji partilha da mesma ideia dos criadores do Balanced Scorecard para esta perspectiva,

acrescentando apenas que a inovação e melhoria contínua não devem ser apenas sobre os produtos

mas também ao nível dos processos. Como objectivos para esta perspectiva, Kanji (2002) destaca os

seguintes: Melhoria contínua; Qualidade; Trabalho em equipa; Prevenção; Liderança. Relativamente

aos indicadores, Kanji também indica alguns: Benchmarking; Uso de equipas; Recursos alocados para

actividades de inovação; Investimento em formação; Número de novos produtos desenvolvidos e

introduzidos no mercado; Número e relevância de novos projectos.


20

2.4 PONTOS FORTES E LIMITAÇÕES

Segundo Kaplan e Norton (1996a), o Balanced Scorecard constitui um meio para fomentar a

aprendizagem constante, porque integra:

• Uma framework para divulgar a estratégia ao longo de toda a organização

• Uma especificação do contributo de cada pessoa para a realização da estratégia global

• Um processo de feedback que recolhe o desempenho da estratégia aplicada fornecendo

informação sobre como adaptar iniciativas e medidas à estratégia global definida

A metodologia do Balanced Scorecard traduz a visão e estratégia organizacional em objectivos e

indicadores criando uma visão estratégica da organização, constituindo-a em quatro perspectivas e

reunindo toda a informação sucintamente num único documento. Outra vantagem prende-se com a

flexibilidade e adaptabilidade do modelo proposto por Kaplan e Norton a qualquer tipo de

organização.

Tal como referem Epstein e Manzoni (1997), “…a visão balanceada que as quatro perspectivas

providenciam permite que os gestores tenham uma ideia mais clara e global da forma como a eficiência

do negócio é obtida.”.

Na actual era da informação, o Balanced Scorecard previne o problema do excesso de

informação, uma vez que foca um número limitado de indicadores. Segundo Kaplan e Norton (2001),

devem ser definidos somente entre 20 a 25 indicadores sendo a sua distribuição pelas perspectivas a

seguinte:

• Perspectiva financeira 5 indicadores (22%)

• Perspectiva do cliente 5 indicadores (22%)

• Perspectiva interna 8 indicadores (34%)

• Perspectiva de aprendizagem e crescimento 5 indicadores (22%)

Norreklit (2000) conclui que não existe uma relação de causalidade entre as quatro

perspectivas, mas sim de interdependência. Apoia-se na relação estabelecida entre as perspectivas

financeira e clientes, argumentando que para alcançar o lucro é necessário realizar cálculos financeiros.

Mais problemático ainda, segundo esta autora, é o facto do Balanced Scorecard não medir os

desenvolvimentos tecnológicos e competitivos, uma vez que o foco de obtenção dos retornos

financeiros é sobre a perspectiva dos clientes descurando a perspectiva de mercado.

Uma segunda desvantagem do modelo proposto por Kaplan e Norton é o facto de fomentar o

comprometimento externo ao invés do comprometimento interno. O conceito de comprometimento

externo significa que os empregados são motivados para actuar segundo regras definidas por outros.


21

Quando se valoriza o comprometimento externo, os empregados focam a sua atenção somente naquilo

que vai ser medido, em detrimento de outros aspectos igualmente importantes, mas sobre os quais não

recai observação directa. O comprometimento interno induz no empregado uma maior motivação e

responsabilidade individual, não se limitando este exclusivamente a trabalhar para aquelas tarefas cujo

desempenho vai ser medido.

Kanji e Sá (2002) na definição do seu modelo, Kanji’s Business Scorecard, argumentam que a

perspectiva de clientes, no modelo definido por Kaplan e Norton, constitui uma limitação devendo

passar incorporar todos os entes que interagem com a organização, como os investidores, fornecedores

e comunidade em geral.

2.5 IMPLEMENTAÇÃO DO BSC

O processo de implementação de uma filosofia de gestão conforme os princípios do Balanced

Scorecard provoca obrigatoriamente uma mudança na organização. Geralmente as mudanças nunca são

fáceis tornando-se especialmente difíceis quando envolvem relatórios de desempenho e riscos de

modificação do equilíbrio do poder dentro da organização. Algumas das dificuldades mais comuns que

surgem durante a implementação do BSC, estão relacionadas com os seguintes factores (EPSTEIN e

MANZONI, 1997):

• Gestão de topo pode não conseguir explicitar a visão, missão e estratégia – dever-se-á

obter um consenso quanto ao rumo a tomar;

• Sobrecarga de trabalho pode gerar resistências internas – para a construção do BSC será

necessário recolher e analisar informação de três novas áreas, relativamente ao passado,

sendo por isso normal haver resistência à mudança. A razão para tal resistência prende-se

com a não compreensão da necessidade de trabalho adicional;

• Pode ser prática habitual da empresa abandonar projectos a meio – fazendo com que as

pessoas, logo à partida, não acreditem no sucesso da implementação de qualquer projecto,

levando a baixas taxas de adesão e envolvimento;

• Protecção do poder base – o conceito Balanced Scorecard pressupõe que haja maior

transparência e fluência de informação ao longo de toda a organização. Uma vez que o

poder é geralmente de quem detém a informação, o Balanced Scorecard constitui uma

ameaça a alguns gestores.

• Sobrevivência e prosperidade – uma vez implementado, o Balanced Scorecard tem de

sobreviver e prosperar entre os outros meios de informação, tendo para isso a gestão de

topo dar ênfase a todas as perspectivas ao invés de unicamente à financeira.


22

Sousa e Rodrigues, citando McCunn, apresentam uma tabela que resume os “dez

mandamentos” da implementação do BSC, indicando o que fazer e não fazer:

Fazer..... Por outras palavras...... • utilizar o scorecard como uma rampa de

lançamento dos objectivos estratégicos • assegurar que os objectivos estratégicos estão

identificados, antes de implementar o scorecard • assegurar que alguém a nível superior apoia o

scorecard e que os gestores funcionais estão empenhados no projecto

• implementar um projecto piloto antes de introduzir o novo scorecard

• levar a cabo uma ‘inspecção de entrada’ para cada unidade de negócio, antes de implementar o scorecard

• pode ser o veículo ideal para fazer chegar a estratégia da empresa aos níveis inferiores da organização

• não conceber a estratégia como um processo em desenvolvimento, sob pena do scorecard conduzir ao comportamento errado

• o projecto do scorecard é demasiado importante para ser algo menos do que uma prioridade da gestão de topo, nunca devendo ser deixado à responsabilidade dos contabilistas

• ele fornece lições valiosas e evita grandes riscos • isto minimiza o risco de avançar em circunstâncias

desfavoráveis e permite adaptar o projecto para servir as necessidades da organização

Não fazer....... Por outras palavras...... • utilizar o scorecard para obter um controlo

extra, do topo para a base • tentar estandardizar o projecto. O scorecard

deve ser ‘feito por medida’ • subestimar a necessidade de formação e

comunicação para a utilização do scorecard • não se empenhar na complexidade nem na

perfeição • subestimar o trabalho administrativo extra e os

custos de apresentação periódica de relatórios sobre o scorecard

• as pessoas revoltar-se-ão • os imperativos estratégicos de cada organização são

únicos – um scorecard ‘pronto-a-vestir’ não se lhe adaptará

• não se deixar enganar pela simplicidade da ideia - tem que se lidar com a enorme mudança que ele acarreta

• evitar a ‘paralisia pela análise’ • a recolha de informação para o scorecard consome

mais tempo do que se poderia pensar

Tabela 1 – Os dez mandamentos da implementação do BSC (SOUSA e RODRIGUES, 2002)

Também, Clarke (2000) refere os três mecanismos que acha fundamentais para o sucesso deste

instrumento de gestão estratégica:

1. Estratégia e missão têm de estar definidas

2. Ter ideias claramente definidas do que se espera obter com a adopção deste instrumento

de gestão

3. Motivação e empenhamento da gestão de topo, tendo de ser esta a passar esse sentimento

para o resto da organização

Além disso, nunca se deve subestimar o tempo necessário à implementação do Balanced

Scorecard, porque uma vez bem definido a sua implementação tenderá a ser melhor sucedida. Pois, o

processo de definir a estratégia, indicadores de desempenho, metas e recompensas em torno de uma

missão ocupam muito tempo e esforço.


23

2.6 O BSC NA MOBIL NORTH AMERICA MARKETING E REFINING

A organização apresentada para exemplificar o processo de definição do Balanced Scorecard é a

Mobil North America Marketing e Refining (NAM&R), pertencente ao sector petrolífero e tendo

como produto final, entre outros, a gasolina. Conforme referem Kaplan e Norton, esta organização em

1992 apresentava-se com um desempenho insatisfatório e elevado grau de burocracia, situando-se em

último lugar no seu sector.

Historicamente, a Mobil tentou diferenciar-se apostando numa estratégia de liderança no

produto, tal como os seus concorrentes, focando a atenção sobre a redução de custos e melhoria da

produtividade em toda a cadeia de valor. O facto de alguns dos concorrentes terem acesso à matéria-

prima (petróleo) mais barata tornava mais difícil a sustentabilidade desta estratégia. A estratégia

adoptada passou pelo foco no crescimento e diferenciação, assentando em dois pilares (KAPLAN et

al., 2001):

• Redução de custos e melhoria do desempenho na cadeia de valor

• Aumentar volume de venda de produtos e serviços a preços mais altos

A visão definida foi a seguinte: “ser a melhor refinaria-fornecedora nos Estados Unidos, sendo

eficiente na criação de valor para os clientes” (KAPLAN e NORTON, 2000a).

Visão

“ser a melhor refinaria-fornecedora nos Estados Unidos, sendo eficiente na criação de valor para os clientes”

Estratégia Crescimento financeiro Cultivar bons relacionamentos com clientes e revendedores Alargar gama de produtos Fornecedor competitivo Qualidade Protecção ambiental Trabalhadores motivados

• Retorno sobre o capital investido • Aumento da rentabilidade • Liderança de custo no sector • Crescimento sustentável e rentável

• Satisfação do consumidor • Relacionamentos Ganha-Ganha com revendedores

• Novos produtos e serviços além da gasolina • Trabalhar com os melhores revendedores • Melhorar desempenho da refinaria • Melhorar a gestão de stocks • Liderança de custo no sector • Conformidade com especificações • Pontualidade • Eliminar incidentes ambientais e de segurança

• Envolvimento organizacional • Competências e habilidades essenciais • Acesso à informação estratégica

Fin

ance

ira

Clie

nte

s In

tern

a C

resc

imen

to

Figura 5 – Os objectivos estratégicos da Mobil NAM&R (KAPLAN et al.,2001)

A estratégia definida para alcançar a visão assentava em sete premissas (fig. 5): crescimento

financeiro, cultivar bons relacionamentos com clientes e revendedores, alargamento da gama de

produtos além da gasolina, estabelecer relações comerciais unicamente com fornecedores competitivos,


24

melhoria da qualidade, protecção ambiental e motivação dos recursos humanos. Por sua vez, para

medir o cumprimento da estratégia definida foram definidos objectivos estratégicos, agrupados nas

quatro perspectivas do modelo do Balanced Scorecard.

Ao nível financeiro o objectivo mais importante era o aumento do retorno sobre o capital

investido de 6% para 12% durante os próximos três anos. Isto seria conseguido por meio de duas

estratégias: estratégia de crescimento e estratégia de produtividade. A estratégia de crescimento

consistia numa primeira fase em fazer o levantamento das necessidades dos clientes para depois, numa

segunda fase seguir uma política de diferenciação. Foram estabelecidos como objectivos: introdução de

novas fontes de receita para além da gasolina e exploração de marcas premium. A estratégia de

produtividade tinha como meta a redução do custo total de produção, traduzindo-se na exploração dos

activos existentes e na integração das unidades de negócio. Os objectivos estabelecidos eram: assumir a

liderança de custo no sector e maximizar o uso dos activos existentes.

No passado a MOBIL tentara comercializar uma ampla variedade de produtos e serviços para

todos os tipos de clientes, competindo ao nível dos preços com os postos vizinhos. Através da

realização de um estudo de mercado concluiu-se que os consumidores sensíveis ao preço constituíam

apenas 20% dos compradores de gasolina (KAPLAN et al., 2001), enquanto que 60% dos

consumidores estariam dispostos a pagar preços mais altos em postos de abastecimento “rápidos,

amigáveis e dotados de loja de conveniência” (KAPLAN e NORTON, 2000a).

Do ponto de vista da MOBIL os seus clientes directos são os revendedores7, pelo que os

objectivos definidos segundo a perspectiva de clientes foram: aumento do lucro do revendedor,

satisfação do revendedor e do consumidor. Como Kaplan e Norton referem, a inclusão dos

revendedores na estratégia da MOBIL partilhando os lucros obtidos, constituiu um meio de motivação

para que estes passassem a direccionar as vendas para os produtos de marcas premium.

Após uma clara definição das perspectivas financeira e de clientes, a MOBIL definiu os meios

internos que lhe permitiriam criar valor diferenciado para os seus clientes, para assim alcançar os

resultados financeiros desejados. Foram definidos, entre outros, quatro objectivos principais:

• Criar produtos e serviços além da gasolina

• Aumentar valor para o cliente

• Excelência operacional

• Minimizar incidentes com o meio ambiente

O objectivo de criação de produtos e serviços além da gasolina era medido por dois

indicadores: taxa de aceitação de novos produtos e retorno do investimento para esses mesmos

7 Neste contexto os revendedores representam os proprietários dos postos de abastecimento, independentes da MOBIL.


25

produtos. Para medir o objectivo de aumentar o valor reconhecido pelos clientes, os indicadores

definidos foram: quota detida no segmento do mercado alvo e avaliação da qualidade dos

revendedores. Para alcançar a excelência operacional a MOBIL dedicou especial atenção à redução dos

custos operacionais, reduzindo os tempos de paragem de equipamento, e à melhoria da qualidade dos

produtos e do número de entregas atempadas (KAPLAN e NORTON, 2000a). Relativamente à

minimização dos incidentes ambientais e à promoção da saúde e segurança dos seus trabalhadores,

definiu os seguintes indicadores: número de acidentes de trabalho, taxa de absentismo e número de

incidentes ambientais e de segurança.

No âmbito da perspectiva de aprendizagem e crescimento, a meta principal prendia-se com a

constituição de uma força de trabalho motivada. O objectivo de promover o envolvimento

organizacional tinha em vista actuar sobre os aspectos motivacionais dos trabalhadores, alinhando

assim a visão global da organização. Na área das competências e habilidades essenciais a MOBIL

pretendia actuar sobre o desenvolvimento das capacidades individuais dos empregados, com o intuito

de melhorar a sua contribuição para a melhoria do desempenho dos processos internos,

nomeadamente: desenvolvimento de novos produtos e serviços, processo de refinamento e diminuição

dos incidentes ambientais e de segurança. No âmbito da informação estratégica a MOBIL tomou duas

medidas: implementação de um sistema de monitorização do processo de refinamento,

desenvolvimento de novas bases de dados e ferramentas para análise dos comportamentos dos

consumidores (KAPLAN e NORTON, 2000a).

A MOBIL lançou o seu projecto de Balanced Scorecard em 1994. Em 1999 fundiu-se com a

Exxon, dando origem à ExxonMobil. A estratégia de produtividade levou a uma redução de 20% nos

custos de refinamento, marketing e entrega de galão de gasolina. A estratégia de crescimento, centrada

na criação de valor para o cliente resultou no aumento da satisfação destes, que por sua vez levou ao

aumento da receita derivada dos produtos não-gasolina e crescimento anual do volume de vendas de

gasolina em mais de 2%. Estes resultados foram alcançados graças a uma mudança radical na empresa,

tendo esta sido reposicionada no seu espaço competitivo de mercado. Estudos anuais sobre os

recursos humanos da empresa mostraram que os níveis de compreensão da estratégia da MOBIL por

parte dos seus trabalhadores, passaram de 20% em 1994 para 80% em 1998 (KAPLAN e NORTON,

2000b).

2.7 RESUMO

O estudo realizado sobre o BSC neste capítulo permitiu-nos evidenciar algumas ideias base

que diferenciam este instrumento de gestão dos convencionais e que, por isso, contribuíram para a sua

popularidade:


26

• Pode-se considerar o BSC como um instrumento de gestão estratégica que faculta

medidas e indicadores de desempenho, para atingir a prosperidade financeira. Deve ser

encarado como uma mais valia para a empresa, na medida em que os gestores podem

utilizar os seus outputs, a qualquer momento, para apoiar o processo de tomada de decisão.

• A adopção deste instrumento de gestão permite que toda a organização prossiga em torno

da mesma estratégia e dos mesmos objectivos estratégicos. Se bem implementado, torna-

se um factor de motivação dos recursos humanos para o alcance dos objectivos.

• As quatro perspectivas apresentadas por Kaplan e Norton, facultam às organizações a

possibilidade de balancear os resultados financeiros a curto prazo, com os factores

geradores de oportunidades de crescimento, com vista a atingir resultados favoráveis no

futuro (longo prazo).

Sendo o BSC um instrumento de gestão estratégica que deve ser adequado e implementado de

acordo com as características próprias do negócio e meio envolvente de cada organização, a sua

implementação não pode ser copiada por outra já realizada, porque um BSC nunca é igual para duas

organizações. O uso deste instrumento de gestão permite às organizações ter uma visão mais clara da

sua economia interna e externa, assim como onde devem concorrer, quais os clientes a conquistar e o

que é preciso fazer para criar valor junto dos possíveis clientes.

Quando questionado sobre o futuro do BSC, Kaplan refere que o enfoque na gestão das

organizações estará na monitorização e condução da estratégia conforme os princípios deste

instrumento de gestão, conduzindo a uma maior utilização de relatórios anuais organizados conforme

o Balanced Scorecard. Acrescenta ainda que, assistir-se-á ao desenvolvimento das tecnologias de

informação e a uma cultura organizacional mais orientada à gestão do desempenho, porque isso

importa mais para as organizações, investidores e sociedade. “Técnicas para melhor medir a inovação,

capacidades dos empregados, alinhamento dos sistemas de informação, clima, cultura e sucesso do

cliente irão certamente melhorar nos próximos dez anos” (WAAL, 2003).

A implementação do BSC causa um aumento no volume de informação a circular na

organização, podendo-se inferir que os sistemas de informação são imprescindíveis para suportar este

modelo de gestão, uma vez que é através deles que se recolhe, processa, analisa e difunde a informação

por toda a organização. Justifica-se assim a necessidade de estudar o suporte tecnológico ao BSC e

desenvolver um modelo que auxilie a implementação deste instrumento de gestão nas organizações.

Capítulo III

SUPORTE TECNOLÓGICO AO BSC

• Enquadramento

• Requisitos

• Estudo da oferta tecnológica

• Lista de funcionalidades consideradas relevantes nos sistemas de informação para suporte

ao BSC

CAPÍTULO 3 – SUPORTE TECNOLÓGICO AO BALANCED SCORECARD

29

Depois de, no capítulo anterior, terem sido abordados os principais conceitos do BSC e ter sido constatada a necessidade de suportar as implementações deste instrumento de gestão em sistemas de informação próprios, entendeu-se como necessário fazer um levantamento das funcionalidades consideradas relevantes para os utilizadores deste segmento de sistemas de informação.

Ao longo deste capítulo vai ser estudada a oferta tecnológica ao BSC, recorrendo-se para isso a documentação produzida pelo instituto Balanced Scorecard Collaborative numa primeira fase, numa segunda à análise das aplicações informáticas certificadas e, finalmente, à inquirição de organizações com experiência no uso destas aplicações informáticas.

Este capítulo começa com um enquadramento e evidência da necessidade de suportar este instrumento de gestão num sistema de informação próprio. Segue-se o estudo dos requisitos gerais a ter em conta quando se pretende desenvolver uma aplicação na área do BSC, de acordo com as etapas descritas anteriormente e, por fim, é construída uma lista de funcionalidades que servirá de base ao próximo capítulo, actuando como a lista de requisitos para o sistema a desenvolver.

3.1 ENQUADRAMENTO

O Balanced Scorecard (BSC) assume-se como um instrumento de gestão estratégica cujo

objectivo fundamental é proceder à comunicação e alinhamento da estratégia ao longo de toda uma

organização.

Desde cedo começaram a surgir aplicações informáticas para suportar e ajudar à

implementação do BSC, diferenciando-se todas elas em termos de funcionalidades e níveis de análises

oferecidas. O Microsoft Excel começou por ser a ferramenta mais usada como suporte ao BSC, sendo

utilizado para cálculo de indicadores, elaboração de gráficos, etc., mas rapidamente se constatou

inviável o seu uso, na medida em que apresentava limitações de: escalabilidade, partilha de dados e

informação, actualização dos dados, capacidade para efectuar análises complexas, etc.

Referindo Marr e Neely (2003), as principais razões que justificam a aposta numa aplicação

informática específica para suporte ao BSC prendem-se com os seguintes aspectos: integração de

dados provenientes de várias fontes, elaboração de análises extensivas tanto quantitativas como

qualitativas, auxílio na difusão de informação ao longo da organização.

Não sendo possível estabelecer uma lista completa das funcionalidades e requisitos necessários

numa aplicação informática de suporte ao BSC, porque estes diferem de organização para organização,


30

nomeadamente os modelos de comunicação, o sistema de informação, o tamanho da organização, as

características do negócio, as políticas de segurança e difusão da informação, o scorecard construído, etc.,

o instituto Balanced Scorecard Collaborative estabeleceu os requisitos funcionais mínimos a observar para a

certificação de qualquer aplicação informática, que suporte o BSC segundo a metodologia proposta por

Kaplan e Norton (BS COLLABORATIVE, 2000).

Estes requisitos dizem respeito apenas à funcionalidade relacionada com a metodologia do

BSC, não sendo especificadas questões de ordem tecnológica, tais como a escalabilidade ou integração

com outros sistemas.

3.2 REQUISITOS

Tomando como referência a simples definição de Macaulay (1996), um requisito pode ser

definido como “algo que um cliente necessita”, ou do ponto de vista de um programador como “algo

que necessita ser desenhado”. Também Kruchten (2003) define requisito como uma condição ou

capacidade que o sistema deve satisfazer”.

Assim, tomando em consideração todas as definições acerca do conceito de “requisito”,

adoptou-se no contexto desta dissertação como sendo uma especificação de uma determinada

condição, acção ou necessidade a ser satisfeita pelo sistema. Estes dividem-se em duas categorias:

requisitos funcionais e requisitos não funcionais.

Os requisitos funcionais descrevem acções ou funções que o sistema deverá satisfazer (IEEE,

1990; SILVA e VIDEIRA, 2001; SOMMERVILLE, 2001). Segundo Wiegers (2003), requisitos

funcionais são funcionalidades ou comportamentos que o sistema deve cumprir de acordo com

determinadas condições impostas pelos utilizadores do sistema. Kruchten (2003) acrescenta a esta

definição que têm de ser especificadas ambas as condições de entrada e de saída necessárias ao alcance

do resultado esperado.

Para além das funcionalidades directamente requeridas existem também um conjunto de

características que, não sendo directamente especificadas nos documentos de requisitos pelos

utilizadores do sistema, se assumem igualmente muito importantes. Estas características prendem-se

com aspectos de qualidade que utilizador valoriza no sistema de informação, designando-se por

requisitos não funcionais. Segundo Kruchten (2003), a qualidade dos sistemas de informação analisa-se

nas seguintes quatro perspectivas8:

8 Robert Grady enquanto executivo da HP (Hewlett Packard), desenvolveu cinco perspectivas para classificação dos requisitos. A primeira refere-se à área funcional – funcionalidade – e as quatro seguintes à área não funcional – usabilidade, segurança, desempenho e suporte. Para mais informação poderá ser consultado o seguinte endereço: http://www-128.ibm.com/developerworks/rational/library /3975.html


31

• Usabilidade – requisitos relacionados com a interacção humano-computador como por

exemplo o aspecto estético, facilidade de uso, facilidade de aprendizagem, documentação

disponibilizada, consistência de interface em todo o sistema de informação, etc.

• Segurança – este tipo de requisitos estão relacionados com a tolerância a falhas,

recuperação de informação e disponibilidade do sistema de informação.

• Desempenho – os requisitos de desempenho impõem condições de realização dos

requisitos funcionais, tais como velocidade de processamento, tempo de resposta,

memória usada e tempo de iniciação do sistema.

• Suporte – nesta componente inserem-se os requisitos relativos à capacidade do sistema

para crescer e adaptar-se à organização no futuro. Por exemplo: adaptação, manutenção,

compatibilidade e escalabilidade.

Contudo, não sendo objectivo desta dissertação o estudo da engenharia de requisitos, esta

matéria encontra-se desenvolvida com maior detalhe e aprofundamento no anexo A.

Entrando no domínio do suporte tecnológico ao Balanced Scorecard, mais concretamente nos

sistemas de informação, de acordo com diversa literatura já publicada os seguintes aspectos ligados a

ambas as componentes (funcional e não funcional) devem ser tidos em conta, tanto quando se procura

uma aplicação informática no mercado como quando se pretende conceber uma nova (BS

COLLABORATIVE, 2000; LAWSON, STRATTON, e HATCH, 2004; MARR e NEELY, 2003;

RATINGS, 2003; SILK, 1998):

1. ESCALABILIDADE – capacidade que um sistema de informação tem para crescer e evoluir

de acordo com as necessidades da organização, podendo classificar-se em três aspectos:

• Programação – a aplicação deverá permitir adicionar novas funcionalidades, como por

exemplo novos scorecards.

• Base de dados – a quantidade de dados tenderá a aumentar rapidamente, pelo que é

importante a utilização de um sistema de gestão de base de dados (SGBD) robusto.

• Interface – a necessidade de desenvolver novos relatórios e vistas sobre a informação é

importante para aperfeiçoar a sua disseminação e adaptação às necessidades dos seus

clientes finais.

2. INTEGRAÇÃO – o objectivo final de uma aplicação para suporte ao BSC é o fornecimento

de informação que auxilie no processo de decisão, sendo por isso bastante importante a

actualidade e qualidade dos dados que carregam a aplicação. Quanto menor for o tempo de

actualização dos dados da aplicação, mais fiável se apresenta a informação, sendo ideal

conseguir-se uma integração em tempo real entre a aplicação e o sistema de informação da

organização.


32

3. FORNECEDOR/PRODUTO – nesta vertente interessa verificar o nível de experiência e

viabilidade do fornecedor na área do BSC, através da consulta da sua lista de clientes de

referência, peso do produto (aplicação informática) no negócio total da empresa fornecedora,

etc. As características a ter em atenção relativamente ao produto são: preço, licenças, contratos

de manutenção, custos de implementação e formação.

4. FLEXIBILIDADE – às aplicações informáticas cada vez mais é exigida a capacidade para

interagirem com outras aplicações. A finalidade de uma aplicação para medição do

desempenho é fornecer valores para indicadores, sendo assim muito importante que a

aplicação contenha funcionalidades específicas para recolha de dados de outras fontes

externas, etc.

5. SERVIÇO – na altura de escolher uma aplicação informática deve ter-se em atenção o serviço

prestado pelos fornecedores, bem como as componentes e restrições dos contratos de

manutenção. Os fornecedores que não implementam a aplicação ou não disponibilizam uma

linha telefónica de atendimento, geralmente constituem parcerias com empresas de consultoria

que desenvolvem estes serviços. A questão principal prende-se com a própria organização ter

percepção do nível de suporte necessitado, para só depois escolher qual o fornecedor que

melhor satisfaz as suas necessidades.

6. FUNCIONALIDADE – este aspecto refere-se às funcionalidades disponíveis na aplicação

informática. Algumas das funcionalidades poderão ser: implementação de sistema de alertas;

atribuição de pessoas responsáveis às tarefas; adaptação de relatórios e outros meios de

apresentação da informação; questões relacionadas com os níveis de segurança e permissões;

criação de um sistema de recompensas ligado a objectivos; criação e difusão de documentação,

etc.

7. CAPACIDADES DE ANÁLISE – a quantidade e variedade de análises disponibilizadas por

uma aplicação informática podem estender-se desde a simples estrutura em árvore, sobre a

qual se realizam agrupamentos e desdobramentos em camadas, até análises multidimensionais,

estatísticas e criação de cenários.

8. COMUNICAÇÃO – a comunicação é um aspecto fundamental para garantir o

funcionamento de qualquer modelo baseado no BSC na medida em que este instrumento de

gestão se apoia difusão e partilha de informação, ao longo de toda a organização, como meio

de operacionalização da estratégia. Algumas características exigidas a uma solução informática


33

são: ser baseada num ambiente de rede (intranet ou extranet); possibilidade da introdução de

comentários a objectivos, indicadores, tarefas; suporte de correio electrónico; emissão de

alertas automáticos ou específicos sobre determinados indicadores e/ou pessoas.

9. ESPECIFICAÇÕES TÉCNICAS – os requisitos técnicos estão relacionados com a infra-

estrutura tecnológica existente na organização. A título de exemplo, é imprescindível que a

aplicação informática permita a extracção de dados de fontes externas (por exemplo bases de

dados de outras aplicações). Um outro requisito é a compatibilidade da aplicação informática

com os browsers 9 mais utilizados.

10. INTERFACE – o modo como a informação é apresentada varia de aplicação para aplicação,

sendo numas mais gráfica e noutras mais textual e tabular. Segundo Marr e Neely (2003), um

dos aspectos mais importantes é a apresentação de mapas estratégicos e das relações causa-

efeito. O ideal seria que a aplicação informática suportasse as funcionalidades atrás referidas

dinamicamente10, isto é, existir a possibilidade de aceder ao detalhe dos dados que deram

origem à informação evidenciada no mapa. Ainda segundo os mesmos autores, os mapas

dinâmicos constituem a principal ferramenta de comunicação e entendimento da estratégia,

permitindo testar e verificar as relações de causa-efeito durante vários períodos de tempo.

11. FUTURO – os desenvolvimentos futuros e a frequência de actualizações sobre uma aplicação

informática constituem indicadores acerca do interesse do fornecedor em desenvolver e

aperfeiçoar este produto, indicando a viabilidade e continuidade da aplicação no tempo.

Interessa escolher uma aplicação informática cujo fornecedor dê garantias de ser desenvolvida

e actualizada no tempo, no sentido de se adaptar a novos modelos de análise e gestão.

Sendo um dos objectivos desta dissertação o desenho conceptual de um sistema de

informação para suporte ao BSC, assume-se como obrigatório um estudo aprofundado dos requisitos

necessários. Estudo este que será realizado em três fases: numa primeira através da análise de

documentação produzida pelo instituto Balanced Scorecard Collaborative; numa segunda fase através da

realização de um estudo da oferta tecnológica nesta área funcional, mais propriamente a recolha e

análise das funcionalidades das principais aplicações informáticas existentes no mercado; por fim, a

terceira fase consiste na aferição das funcionalidades recolhidas na fase anterior, através de um

9 Browser – Aplicação usada para navegar/editar informação numa infra-estrutura de rede. Ex: Netscape, Internet Explorer. 10 Por funcionalidades dinâmicas entenda-se a possibilidade de desdobrar-se a informação em camadas consecutivas visualizando os dados que lhe deram origem.


34

questionário distribuído a organizações com experiência neste tipo de aplicações (fornecedores,

consultores e utilizadores).

3.3 OFERTA TECNOLÓGICA

Antes de especificar os requisitos essenciais a um sistema de informação para suporte ao

Balanced Scorecard (BSC) assume-se como obrigatória uma análise, mesmo sendo superficial, aos

sistemas presentes no mercado. A preocupação inicial para este estudo da oferta tecnológica foi a

identificação dos sistemas de informação para suporte ao BSC actualmente existentes no mercado. De

entre todos os sistemas recolhidos numa fase inicial escolheram-se para análise todos os que são

certificados pelo instituto Balanced Scorecard Collaborative.

O âmbito da análise realizada restringiu-se às funcionalidades gerais que um sistema da área do

BSC deve disponibilizar aos utilizadores, tendo por isso sido feita em três fases.

Numa primeira fase foi analisada documentação produzida pelo instituto Balanced Scorecard

Collaborative (BSCol). Este instituto foi fundado pelos criadores do conceito de BSC, Kaplan e Norton,

sendo a sua missão “difundir o conhecimento, uso, melhorias e integridade do BSC como um processo

de gestão, que produz valor acrescentado para as organizações.” (BS COLLABORATIVE, 2003).

A segunda fase caracterizou-se pela recolha e organização das funcionalidades de todas as

aplicações informáticas devidamente certificadas pelo instituto BSCol. A lista dos fornecedores de

aplicações certificadas pelo BSCol encontra-se disponível para consulta no anexo B.

Após a recolha e organização das funcionalidades mais importantes na fase anterior, fazia

sentido validá-las junto de organizações com experiência em sistemas de informação da área do

Balanced Scorecard. Assim, a terceira fase consistiu na elaboração de um questionário para realizar a

referida validação das funcionalidades apontadas como necessárias, junto de organizações nacionais e

estrangeiras com experiência neste tipo de sistemas de informação.

3.3.1 PERSPECTIVA DO BALANCED SCORECARD COLLABORATIVE INSTITUTE

O instituto Balanced Scorecard Collaborative (BSCol) é uma organização fundada e gerida pelos

criadores do conceito BSC, Drs. Robert Kaplan e David Norton, cujo objectivo é a divulgação de

conhecimento e experiência em tudo o que está relacionado com o Balanced Scorecard (BS

COLLABORATIVE, 2000).

Este instituto publicou uma lista das funcionalidades consideradas mínimas em qualquer

sistema de informação de BSC, cujo objectivo é servir de guia aquando da concepção de uma aplicação

informática para gestão do BSC. Os fornecedores deste tipo de sistemas de informação são


35

aconselhados a diferenciarem os seus produtos a partir desta lista publicada, e a desenvolvê-los em

diversas vertentes ao longo do tempo.

De acordo com o instituto BSCol os requisitos básicos inserem-se em quatro secções:

1. Desenho do Balanced Scorecard

2. Educação e comunicação

3. Execução do negócio (componente de gestão)

4. Retorno de informação (feedback) e aprendizagem

3.3.1.1 DESENHO DO BALANCED SCORECARD

É fundamental que a aplicação permita a construção do modelo para o scorecard, integrando os

elementos básicos que o constituem. Embora as designações dos diversos elementos possam variar, a

estrutura básica tem de incluir as seguintes componentes: perspectivas, objectivos, indicadores, metas,

iniciativas e mapa de relações causa-efeito. Para de cada componente nomeada atrás, enunciam-se as

funcionalidades que devem permitir realizar:

1. PERSPECTIVAS

a. Indicação das perspectivas standard: financeira, clientes, processos internos e

aprendizagem e crescimento

b. Possibilidade de criar novas perspectivas

c. Possibilidade dos utilizadores renomearem as perspectivas padrão

2. OBJECTIVOS

a. Indicação dos diversos objectivos

b. Alinhamento/ligação de cada objectivo a pelo menos uma perspectiva

3. INDICADORES

a. Indicação dos indicadores e respectivas fórmulas de cálculo

b. Ligação de cada indicador a pelo menos um objectivo

4. METAS

a. Metas devem ser quantificáveis, mensuráveis e temporizadas

5. RELAÇÕES CAUSA-EFEITO

a. Permitir criar uma representação gráfica da ligação entre os objectivos

b. Processo simples de alteração das ligações entre os objectivos

6. INICIATIVAS

a. Ligação das iniciativas a pelo menos um objectivo

b. Mostrar iniciativas por cada objectivo


36

3.3.1.2 EDUCAÇÃO E COMUNICAÇÃO

O Balanced Scorecard tem como base a fluidez de informação ao longo de toda a organização. O

seu princípio é a comunicação da estratégia e objectivos estratégicos a toda a organização. A

abordagem comunicacional em que se apoia o BSC em termos de conceito é de que a informação

circule por toda a organização, em ambos os sentidos Top-Down e Bottom-Up. Por um lado, a

comunicação dos objectivos processa-se desde o nível estratégico da organização até ao nível

operacional, seguindo uma abordagem Top-Down. Por outro lado, a aceitação, reacções, comentários e

iniciativas também se propagam desde o nível operacional até ao nível estratégico da organização

seguindo uma abordagem Bottom-Up.

No ponto anterior (3.3.1.1), onde é desenhado o modelo do scorecard, é comum adoptarem-se

descrições genéricas e simples para indicar os objectivos, metas, iniciativas, etc. Para garantir que

qualquer pessoa compreende bem cada componente do scorecard, é importante que existam descrições

qualitativas e detalhadas sobre cada componente definida durante a fase de desenho do modelo do

scorecard.

Assim, segundo o instituto BSCol para esta secção o requisito refere-se à:

1. DOCUMENTAÇÃO

a. Facilidade no acesso a documentação sobre cada elemento do BSC (perspectivas,

objectivos, indicadores, metas, iniciativas)

b. As pessoas devem poder inserir comentários sobre os elementos do BSC

(perspectivas, objectivos, indicadores, metas, iniciativas)

3.3.1.3 EXECUÇÃO DO NEGÓCIO (GESTÃO)

“As iniciativas são a base do trabalho que conduz à mudança segundo a estratégia definida”

(BS COLLABORATIVE, 2000). As iniciativas devem ser monitorizadas para garantir que estão a ser

realizadas de acordo com a estratégia definida, em busca dos resultados pretendidos.

O único requisito definido no âmbito desta secção é que cada iniciativa deve estar ligada a um

ou mais objectivos estratégicos, devendo além disso o sistema mostrar essas ligações.

3.3.1.4 RETORNO DE INFORMAÇÃO (FEEDBACK) E APRENDIZAGEM

“Um bom desenho do sistema propicia a redução do tempo de retorno da informação” (BS

COLLABORATIVE, 2000). Realmente é bastante importante o tempo de retorno de informação

acerca da eficácia das medidas que foram adoptadas. Quanto menor for este tempo, mais rápida poderá

ser a identificação de possíveis problemas e a consequente actuação sobre eles.


37

Esta secção foca-se nos métodos para monitorização e recolha de informação acerca do nível

de desempenho para cada indicador, indicando por um lado o tipo de informação a recolher e, por

outro, as formas de apresentação da informação:

1. RELATÓRIOS

a. Relatório do desempenho actual e histórico por cada indicador, relacionando também

as metas definidas.

b. Uso de símbolos gráficos (semáforos, faces, cores, etc.) para indicar o nível de

desempenho de determinado indicador, assim como descrições qualitativas (bom,

mau, médio, etc.)

c. Possibilidade de adequar a cada utilizador os tipos de formatos a usar para representar

a informação nos relatórios (semáforos, cores, sinais, etc.).

3.3.2 APLICAÇÕES CERTIFICADAS EXISTENTES NO MERCADO

À semelhança de outros instrumentos de gestão (EVA, EFQM, etc.) também para o BSC

existem sistemas de informação próprios para auxiliar a sua implementação, diferenciando-se todos

entre si no que respeita ao seu grau de adaptação e conformidade com os princípios subjacentes à

filosofia do BSC.

Tendo como objectivo a preservação da integridade do mercado de sistemas de informação de

suporte ao BSC e a identificação dos bons sistemas de informação no “mar de aplicações informáticas

existentes para medição do desempenho” (BS COLLABORATIVE, 2003), o instituto BSCol decidiu

certificar os sistemas de informação que se baseiam nos princípios do BSC.

O instituto BSCol é a única entidade mundial que certifica sistemas de informação de suporte

ao BSC, disponibilizando informação acerca dos sistemas já certificados. Por isso constitui também

uma base de apoio tanto a fornecedores quando procuram os últimos desenvolvimentos em torno do

conceito do BSC, como a potenciais clientes aquando duma implementação ou selecção de um

produto já certificado.

Como forma de complementar o trabalho de recolha de requisitos realizado durante a fase

anterior, foram analisados superficialmente todos os sistemas de informação certificados, em busca das

funcionalidades gerais de cada um. Como foi referido atrás, a avaliação foi feita de uma forma

superficial porque não existiam condições para fazer uma avaliação exaustiva sobre cada sistema, uma

vez que isso implicava estar perante sistemas em funcionamento com dados reais e a prolongar a

análise durante vários meses para cada sistema. Considerou-se que, no âmbito desta dissertação, uma

recolha simples das diversas características dos diversos sistemas seria suficiente como ponto de


38

partida para a fase seguinte, em que através da aplicação de um inquérito se conseguiria perfeitamente

identificar os requisitos necessários para um sistema de informação para suporte ao BSC.

Para além dos sistemas de informação certificados pelo instituto BSCol, incluíram-se no

estudo mais dois sistemas, o Ergometrics e o Active Strategy, que se consideraram igualmente importantes

por serem referenciados por Marr e Neely (2003) num dos seus artigos acerca de avaliação de soluções

informáticas para o BSC. A recolha de informação acerca de cada sistema de informação foi feita em

duas fases: numa primeira solicitou-se, por correio electrónico, a cada um dos fornecedores que

enunciasse as características funcionais do seu sistema de informação; numa segunda fase, dando

seguimento a muitas das respostas dos fornecedores foram analisadas brochuras recolhidas

directamente dos respectivos websites na Internet.

Reconhecendo que muitas das funcionalidades descritas nos sistemas de informação analisados

são o detalhe de outras mais genéricas, optou-se por fazer a recolha e análise segundo um conjunto de

categorias previamente definidas, conforme se apresenta mais abaixo:

CARACTERÍSTICAS FUNCIONAIS

• Apresentação da informação (interface)

• Flexibilidade

• Funcionalidade

• Comunicação

• Análise

CARACTERÍSTICAS NÃO FUNCIONAIS11

• Características técnicas

• Administração

• Serviço

• Preço

Aquando da análise de cada sistema de informação recolheram-se e classificaram-se as suas

características nas categorias definidas acima, tendo-se constatado que em todos eles há uma série de

características comuns. A lista das funcionalidades recolhidas pode ser consultada no anexo C,

descrevendo-se agora apenas em traços gerais aquelas que se consideraram mais importantes para cada

categoria definida anteriormente.

11 Estas características consideram-se não funcionais do ponto de vista do utilizador final do sistema. Contudo, algumas poderão ser consideradas funcionais do ponto de vista do administrador do sistema.


39

Assim, para a categoria das características funcionais temos:

• Apresentação da informação

Neste tópico estão agrupadas as características do sistema que dizem respeito ao

interface e interacção com os utilizadores. O uso de gráficos ou símbolos traduz mais

eficientemente as ideias gerais a passar ao destinatário da informação. Geralmente

utilizam-se semáforos, faces ou gráficos12 para transmitir o estado ou desempenho de

determinado indicador. Uma mais valia agregada à forma de apresentação da informação,

é a possibilidade de poderem ser definidos os símbolos a utilizar por cada utilizador.

É também conveniente que o sistema seja baseado em ambiente de janelas,

permitindo assim ao utilizador a observação de diversa informação no mesmo espaço

(ambiente de trabalho).

• Flexibilidade

A flexibilidade de um sistema de informação mede-se pelo grau de desenvolvimento e

adaptabilidade das funcionalidades que disponibiliza à organização onde é implementado.

Por isso, no contexto dos sistemas de informação de suporte ao Balanced Scorecard é

importante que estes permitam tanto a importação de dados provenientes de outros

sistemas externos (ex: folhas de cálculo, bases de dados, ficheiros ASCII), como a

exportação de informação em diversos formatos (XML, Texto, MS Excel).

Porque as organizações diferem em termos de tamanho e complexidade, é igualmente

importante que o sistema de informação possibilite, para além das implementações totais,

implementações parcelares ao nível departamental ou unidade de negócio.

Um outro aspecto de flexibilidade muito valorizado é a possibilidade de criação e

interligação de novas perspectivas com as perspectivas padrão, bem como a criação e

interligação de novos scorecards com os principais.

Por fim e igualmente importante, o suporte a um número ilimitado de objectivos,

indicadores, metas e iniciativas são aspectos bastantes valorizáveis no âmbito destes SI de

suporte ao BSC.

• Funcionalidade

A funcionalidade está directamente relacionada com os requisitos funcionais

comummente exigidos pelos utilizadores, estando neste contexto muito direccionada a

conceitos fundamentais da filosofia do BSC.

12 Alguns dos símbolos mais utilizados:


40

Começando pela concepção do modelo geral do scorecard, assume-se como

indispensável a descrição da missão, visão, estratégia, definição das perspectivas padrão e

construção do mapa de relações de causa-efeito. É a partir destes pontos-chave que toda

a organização tomará conhecimento do eixo em torno do qual terá de moldar os seus

esforços. De seguida, e não menos importante, temos a definição dos objectivos

estratégicos e o estabelecimento das diversas relações consideradas pertinentes, como por

exemplo relações entre objectivos, indicadores, metas, iniciativas e ainda entre todos estes

atrás indicados e as perspectivas.

No que diz respeito aos indicadores, para além da definição de quais os mais

adequados para medir o grau de alcance dos objectivos, interessa também definir as suas

fórmulas de cálculo.

Tendo em conta as metas, as organizações ambiciosas poderão sentir a necessidade de

estabelecer vários tipos de metas para cada objectivo. Isto é, podem ser estabelecidos os

níveis mínimos a atingir, os níveis bons e os níveis excelentes.

Por fim, considerando que a estratégia deve ser adaptada às constantes mutações do

meio envolvente da organização, a possibilidade de se poderem construir e guardar

mapas estratégicos ao longo do tempo é uma mais valia para análise futura.

• Comunicação

O Balanced Scorecard enquanto instrumento de gestão baseia-se na definição e difusão

dos mais altos padrões de uma organização, a sua missão, a sua visão e a estratégia. Sendo

um princípio do conceito do BSC a comunicação da estratégia a toda a organização,

pode-se inferir que a comunicação é um dos factores críticos de sucesso para que uma

estratégia baseada no BSC seja bem sucedida.

A possibilidade dos empregados introduzirem comentários aos objectivos,

indicadores, metas e iniciativas, além de permitir recolher a sua percepção e opinião

acerca das linhas orientadoras definidas pelo nível de topo da organização, incute-lhes

motivação extra porque a sua opinião é ouvida pelos níveis de topo da organização.

Um sistema de alertas sobre os indicadores é também um meio de prevenir possíveis

desvios em tempo útil aos objectivos definidos e metas propostas.

Um aspecto também observado em alguns dos sistemas analisados foi a existência de

um sistema interno para partilha de informação entre todas as pessoas da organização,

nomeadamente: formulários, correio electrónico e fóruns de discussão. Ainda

relativamente à informação, a possibilidade de ligar documentos, aplicações externas,

fóruns de discussão, mensagens de correio, etc., aos objectivos e indicadores constitui

uma mais valia.


41

Por fim, assume-se como obrigatório a existência de relatórios padrão disponíveis no

SI, tais como: por perspectivas, relacionamento entre indicadores e metas, valores de

alcance dos objectivos, etc.

• Análise

A variedade e profundidade de análises permitidas por um sistema de informação são

a sua mais valia. Pois, é com base nas análises permitidas que o processo de tomada de

decisão é facilitado e as medidas tomadas se tornam mais eficazes.

No contexto das aplicações de suporte ao BSC, assumem-se como essenciais relatórios

relativos ao desempenho actual e histórico de cada indicador, assim como a respectiva correspondência

com as metas definidas. Também a monitorização gráfica e descritiva (usando palavras) do índice de

eficácia de cada objectivo e indicador é um meio para analisar e avaliar no tempo a evolução existente

em determinada área funcional.

No que diz respeito à análise da informação, é importante que o utilizador a possa desdobrar

em vários níveis de detalhe, por um lado utilizando gráficos dinâmicos que lhe permitam aceder de

uma forma directa aos dados que lhe deram origem (por exemplo através do sistema de point-and-

click13), e por outro através da construção de diagramas dinâmicos através da técnica de drag-and-drop14

de vários campos.

Quanto à categoria das características não funcionais, temos:

• Características Técnicas

Nesta categoria inserem-se características técnicas e gerais que diferenciam os sistemas

mais genéricos daqueles mais específicos e direccionados a nichos de mercado

particulares. Um bom sistema de informação deve, antes de mais, ser escalável e

adaptável às constantes necessidades dos seus utilizadores. Em termos tecnológicos

valorizam-se os sistemas que estejam desenvolvidos para funcionar em diversas

plataformas ou sistemas operativos (Windows, Linux, Unix) e assentes num SGBDR

(Sistema de Gestão de Base de Dados Relacional) como por exemplo o SQL Server,

Informix e Oracle.

O ponto de partida para um bom funcionamento do BSC baseia-se numa eficaz

partilha e difusão da informação ao longo de toda a organização, sendo por isso

aconselhável, na nossa opinião, que o SI esteja desenvolvido em ambiente WEB (HTML,

ASP, PHP, .NET, J2EE), isto é correndo sobre um navegador comum (browser15).

13 Técnica de selecção de objectos através do uso de um dispositivo apontador 14 Técnica que consiste no arrastamento de objectos e posicionamento sobre outros objectos 15 Browser – Aplicação usada para navegar/editar informação numa infra-estrutura de rede. Ex: Netscape, Internet Explorer.


42

Por fim, salientam-se aspectos genéricos como por exemplo o sistema ter uma

filosofia de cliente/servidor, ser multi-empresa, multi-lingua, fácil e intuitivo.

• Administração

Esta categoria diz respeito à gestão do sistema no seu todo pelos administradores do

sistema, privilegiando-se aspectos como a definição de políticas de segurança.

Quanto ao arquivo de informação para histórico, esta funcionalidade é considerada

importante porque este tipo de sistema de informação gera muita informação. Só

arquivando informação para histórico é que se pode garantir um bom rendimento e

desempenho do sistema de informação.

• Serviço

O serviço pós-venda é um ponto a ter em atenção quando se opta por um sistema de

informação, pois, deve haver a garantia de que o sistema será actualizado e adaptado ao

longo do tempo. Igualmente importante é a existência de uma linha de suporte contínuo,

que permita aos utilizadores a obtenção de correcções ou respostas aos seus problemas

em tempo útil.

• Preço

Nesta categoria o valor mais crítico é o custo de manutenção anual. Pois, este custo

está intimamente relacionado com o serviço pós-venda prestado pelo fornecedor. O

preço do produto e das licenças por utilizador, assumem-se como secundários para este

tipo de SI desde que sejam considerados SI certificados pelo instituto B.S. Collaborative.

3.3.3 INQUÉRITO

Depois de terem sido recolhidas, classificadas e categorizadas as funcionalidades julgadas

essenciais para um sistema de informação de suporte ao BSC durante as fases anteriores, julgou-se por

bem validar estas funcionalidades junto de organizações com experiência em sistemas de informação

desta área. Para realizar a validação atrás referida optou-se pelo inquérito através do questionário.

Com a lista de funcionalidades já construída, podendo ser consultada no anexo C, verificou-se

que esta apesar de bem organizada estava excessivamente longa para ser incluída directamente num

questionário. Pois, um questionário muito exaustivo e longo dificilmente seria respondido. Assim,

elaborou-se um questionário mais pequeno e que incide apenas nas funcionalidades consideradas

essenciais num sistema de informação de suporte ao BSC.

Uma vez que o âmbito de aplicação do questionário era a organizações com experiência na

utilização de sistemas de informação de suporte ao BSC, elaboraram-se versões em duas línguas:

português e inglês, podendo cada uma delas ser consultada no anexo D.


43

O questionário foi estruturado em três secções. Uma primeira de dados gerais cujo objectivo

consistia em recolher o perfil e experiência das pessoas que preencheram os questionários, de forma a

validar as suas respostas. Na segunda secção, composta pelas funcionalidades dos sistemas de

informação que se pretendiam validar, foram formuladas três questões. Para cada funcionalidade pedia-

se a indicação sobre a sua existência no sistema de informação actual e em caso afirmativo, se estava a

ser utilizada. A última questão consistia em classificar as funcionalidades em termos da sua importância

para um sistema de informação de suporte ao BSC, independentemente de existirem ou serem

utilizadas. Por último, a terceira secção do questionário consistia num campo de comentários onde se

pretendia recolher opiniões tanto de outras funcionalidades igualmente consideradas importantes,

como outros aspectos relativos à implementação do sistema em cada organização.

Ainda relativamente à segunda secção do questionário, nas questões ligadas à funcionalidade,

para facilitar a compreensão aos inquiridos optou-se por agrupar as funcionalidades nas seguintes cinco

categorias:

• Construção do modelo principal

Nesta categoria encontram-se enunciadas funcionalidades relacionadas com a

concepção do modelo de scorecard a implementar, tais como por exemplo: definição da

missão, visão, estratégia, mapa de relações causa-efeito, perspectivas, objectivos,

indicadores, metas, iniciativas, fórmulas de cálculo dos indicadores, etc.

• Comunicação

Esta categoria integra funcionalidades relacionadas com a apresentação de informação

aos utilizadores e partilha da mesma dentro da organização. Inclui funcionalidades como:

uso de informação gráfica para representar diversas realidades, introdução de

comentários por parte dos empregados da organização, sistema de alertas sobre

indicadores, objectivos, etc.

• Negócio

As funcionalidades incorporadas sobre este tópico referem-se às componentes de

análise que o sistema de informação possibilita aos seus utilizadores. Incorpora

funcionalidades como: desempenho actual e histórico dos indicadores, desdobramento da

informação em diversos níveis de detalhe, análises multidimensionais (OLAP), variedade

de indicadores, etc.

• Flexibilidade

Esta categoria refere-se ao contexto geral da aplicação contendo funcionalidades extra

que proporcionam valor aos utilizadores. Uma grande parte das funcionalidades

presentes nesta categoria resulta de requisitos não-funcionais constituindo assim um

factor de diferenciação entre as várias aplicações presentes no mercado.


44

A flexibilidade permite a adaptação de um sistema de informação a diversos tipos de

organizações e utilizadores. Pois disponibiliza várias opções para auxílio do utilizador

final, como por exemplo: importação de dados de diversas fontes externas ao sistema,

exportação de dados para diversos formatos, possibilidade de arquivar informação,

políticas de segurança, funcionalidades de agendamento de tarefas, etc.

• Características técnicas

A vertente técnica de um sistema de informação interessa somente aos gestores do

sistema. Pois, são os gestores do sistema que impõem restrições à arquitectura do

sistema, plataforma onde assenta, motor de base de dados, etc.

Em termos de escala utilizada para medir o grau de importância atribuído a cada

funcionalidade optou-se pela escala de Lickert, pois esta escala permite “...através do recurso a questões

que oferecem um amplo leque de respostas, evitar a rigidez e as limitações das alternativas concordo-

discordo....” (PARDAL e CORREIA, 1995). As normas para aplicação desta escala consistem numa

primeira fase num levantamento das proposições consideradas significativas relativamente à opinião

que se pretende investigar, de seguida elaboram-se as questões que têm a ver com o objecto de análise

e por fim apresentam-se as questões com cinco possibilidades de resposta, onde os inquiridos indicam

a sua opinião utilizando uma escala de classificação de 5 (máximo) a 1 (mínimo).

3.4 ANÁLISE DOS DADOS RECOLHIDOS

Após a validação dos questionários recebidos, desenvolveram-se análises em três vertentes:

funcionalidades existentes, funcionalidades utilizadas e importância reconhecida a cada funcionalidade.

Foi pedido a cada utilizador que indicasse para cada funcionalidade enunciada no questionário, se

estava disponível no seu sistema de informação actual e em caso afirmativo se era utilizada. Uma outra

questão independente destas consistia na classificação em termos de importância de cada

funcionalidade no contexto dos sistemas de informação de suporte ao BSC. Por fim disponibilizou-se

uma área para comentários.

Para tal utilizou-se a aplicação informática SPSS16 como meio de apoio e realizaram-se

estatísticas descritivas, tendo sido utilizada maioritariamente a mediana como medida de análise. A

decisão de adoptar a mediana com medida de análise a utilizar deve-se ao interesse em utilizar uma

medida resistente a “comportamentos extravagantes da variável” (PARDAL e CORREIA, 1995), pois

o questionário foi distribuído a pessoas com diferentes sensibilidades e experiência em sistemas de

informação de suporte ao BSC.

16 SPSS (Statistical Package for the Social Science) é uma aplicação informática especializada na gestão e análise de dados, produzindo diversas análises estatísticas apresentando a

informação graficamente.


45

A análise seguinte vai focar-se numa primeira fase na indicação das respostas recolhidas para

cada uma das três vertentes do questionário e numa segunda fase numa apreciação global e criação de

uma lista das funcionalidades esperadas pelos utilizadores. Com o intuito de facilitar a leitura dos

resultados recolhidos elaboraram-se gráficos do tipo radar, para cada um dos cinco grupos de questões

do questionário.

3.4.1 ANÁLISE DAS FUNCIONALIDADES EXISTENTES

Atendendo à perspectiva dos utilizadores (incluídos também os consultores neste grupo) foi

observada uma grande discrepância entre as suas respostas e as dos fornecedores. Quanto aos

fornecedores, de uma forma geral todos eles responderam que as suas soluções informáticas de suporte

ao BSC suportam todas as funcionalidades descritas no questionário, excepto a seguinte: o uso de

gráficos GANTT para vários tipos de análise.

O gráfico seguinte traduz as respostas recolhidas para o primeiro grupo: construção do

modelo principal (scorecard).

0

1

2A

B

C

D

E

F

G

H

IJ

K

L

M

N

O

P

Q

Utilizador Fornecedor

Gráfico 1 – Funcionalidades Existentes: construção do modelo principal (scorecard)

Segundo a perspectiva dos utilizadores verificou-se a presença de muitas respostas negativas

quanto há sua percepção acerca da existência de algumas funcionalidades. Assim, para este primeiro

grupo foram reconhecidas como existentes, as seguintes funcionalidades (referenciadas com a letra

respectiva do gráfico):

• Definição dos objectivos estratégicos. [D]

• Indicação de objectivos, indicadores, metas e iniciativas para cada um das perspectivas

padrão. [E]

• Indicação das fórmulas de cálculo dos indicadores. [F]

Legenda: 1 - Funcionalidade existente na aplicação informática actual. 2 - Funcionalidade não existente na aplicação informática actual.


46

• Estabelecimento de ligações entre objectivos, indicadores, metas e iniciativas. [G]

• Atribuição de objectivos a utilizadores específicos ou grupos de utilizadores. [J]

• Definição de várias metas para cada objectivo (meta interna, meta benchmark, etc). [K]

• Mapa de relações de causa-efeito. [H]

• Criação e interligação de novos scorecards (pessoais) com os existentes. [N]

• Definição de indicadores específicos (utilizador) e gerais (organização). [O]

• Possibilidade para inserir um número ilimitado de objectivos, indicadores, metas e

iniciativas para qualquer perspectiva. [Q]

Como funcionalidades não existentes foram referidas as seguintes:

• Definição da missão. [A]

• Definição da visão. [B]

• Definição da estratégia. [C]

• Criação e interligação de novas perspectivas com as principais. [M]

• Possibilidade elaborar várias versões do mapa estratégico, para depois analisar a sua

evolução. [L]

• Assistentes para ajuda aos utilizadores na realização de determinadas tarefas. [P]

• Possibilidade de interligar objectivos em diversas camadas (em cascata). [I]

Uma possível explicação para estas respostas negativas foi encontrada no campo de

comentários de alguns questionários, tendo sido apresentada como justificação que a definição da

missão, visão e estratégia são valores essenciais que deverão ser do conhecimento de todos os

empregados da organização. Por isso, é vulgar aparecerem cartazes e placards espalhados pela

organização onde estão descritos estes três valores. Ainda segundo as opiniões recolhidas, estas

definições e mapas são criados em aplicações comuns, como o Microsoft Word ou Microsoft Visio, ficando

posteriormente disponíveis para consulta. Inclusivamente podem ser ligados ou incorporados como

fundo (wallpaper) na aplicação informática que suporta o BSC.

Quanto às restantes funcionalidades referidas como não existentes, não foi encontrada

qualquer razão explícita nos campos de comentários, contudo pensamos poder dever-se há falta de

necessidade delas por parte dos utilizadores do sistema. Pois, poderá verificar-se mais adiante nos

gráficos de importância atribuída às funcionalidades que estas são aquelas cuja classificação é a mais

baixa.


47

O segundo grupo de perguntas do questionário refere-se à comunicação, cujo objectivo passa

por medir as funcionalidades relacionadas com a difusão de informação no seio da organização. O

gráfico seguinte ilustra a natureza das respostas recolhidas.

0

1

2A

B

C

D

E

FG

H

I

J

K


Gráfico 2 – Funcionalidades Existentes: comunicação

As respostas afirmativas relativas à existência das funcionalidades descritas no questionário são

apresentadas de seguida (referenciadas com a letra respectiva do gráfico):

• Introdução de comentários aos objectivos, indicadores, metas e iniciativas por parte dos

utilizadores do sistema. [A]

• Apresentação gráfica da ligação entre os objectivos. [D]

• Uso de informação gráfica (ex: semáforos, imagens, gráficos, etc., na representação das

tendências de evolução dos indicadores). [F]

• Uso de informação qualitativa para descrever a evolução de indicadores (bom, mau,

aumentou, baixou, positivo, etc). [G]

• Existência de relatórios e modelos de relatórios pré-definidos (perspectiva, indicadores vs

metas). [H]

As funcionalidades consideradas não existentes, são as seguintes:

• Sistema de alertas sobre os indicadores, comentários introduzidos e mensagens. [B]

• Mecanismos para partilha de informação entre os empregados (ex: mensagens,

formulários, correio interno, fóruns). [C]



48

• Possibilidade de ligar documentos, mensagens de correio, aplicações externas, etc., a

indicadores e objectivos. [E]

• Possibilidade de os utilizadores construírem relatórios pessoais e personalizados. [I]

• Possibilidade para personalizar a aplicação por utilizador (ex: páginas pessoais com

indicadores individuais, formatos de moeda, etc). [J]

• Uso de gráficos de GANTT para vários tipos de análise (ex: gestão das

iniciativas/actividades). [K]

Esta manifestação de opiniões antagónicas entre os utilizadores e fornecedores é o reflexo da

não utilização destas funcionalidades pelos utilizadores, uma vez que da parte dos fornecedores há

confirmação da sua existência. Tendo sido analisados alguns casos específicos constatou-se que

existem utilizadores que tendo consciência da existência das funcionalidades, não tiram partido da sua

utilização, concluindo nós que a não utilização delas é a razão para terem sido classificadas como não

existentes.

Há semelhança do grupo anterior, também o seguinte relacionado com as áreas de negócio e

componentes de análise agrega respostas opostas para as duas perspectivas – a dos fornecedores e a

dos utilizadores. O gráfico seguinte representa as respostas recolhidas para o terceiro grupo do

questionário.

0

1

2A

B

C

D

EF

G

H

I

Utilizador Fornecedor Gráfico 3 – Funcionalidades Existentes: negócio (componentes de análise)



49

Tal como referido anteriormente e observando o gráfico anterior, os fornecedores

responderam que os seus sistemas suportam todas as funcionalidades descritas, enquanto que da parte

dos utilizadores se obtiveram as seguintes respostas para as funcionalidades existentes (referenciadas

com a letra respectiva do gráfico):

• Relatório do desempenho actual e histórico de cada indicador. [A]

• Monitorização (gráfica e descritiva) do índice de satisfação de cada objectivo, indicador,

meta e iniciativa. [B]

• Existência de vários tipos de indicadores/métricas. [C]

• Capacidade para desdobrar a informação em diversos níveis de detalhe. [D]

• Definição de empregados responsáveis por iniciativas e indicadores. [E]

As funcionalidades indicadas como não existentes são as seguintes:

• Associação de sistema de recompensas às metas e iniciativas individuais. [F]

• Construção de diagramas dinâmicos pelos utilizadores através da técnica de drag-and-drop

de vários campos. [G]

• Análises multidimensionais (ferramentas OLAP). [H]

• Acompanhamento e medição do desempenho individual (por empregado) e respectiva

contribuição para a satisfação dos objectivos estratégicos. [I]

Mais uma vez se confirma que os utilizadores consideraram como inexistentes funcionalidades

não utilizadas, não tendo inclusivamente ideia sobre a sua existência. Mais adiante pode verificar-se que

no entanto são os utilizadores quem lhes atribui altos níveis de importância.

Seguindo para o próximo grupo de questões relativas à flexibilidade, interessa antes de mais

esclarecer o conceito de flexibilidade. A flexibilidade mede-se pelo grau de adequação e adaptabilidade

de um sistema de informação à organização onde é implementado. Adoptando a definição do IEEE,

“flexibilidade é a facilidade com que um sistema ou componente pode ser modificado para ser usado

em ambientes ou aplicações diferentes daquelas para que foi desenhado” (IEEE, 1990). O gráfico

seguinte mostra as respostas recolhidas para este grupo de funcionalidades.


50

0

1

2A

B

C

D

E

F

G

H


Gráfico 4 – Funcionalidades Existentes: flexibilidade

Para este grupo de funcionalidades obtiveram-se as seguintes respostas afirmativas quanto às

funcionalidades existentes (referenciadas com a letra respectiva do gráfico):

• Importação de dados provenientes de sistemas externos. [A]

• Exportação de dados em diversos formatos. [B]

• Possibilidade de implementações totais (toda a organização) ou parcelares (departamentos,

unidades de negócio). [C]

• Administração centralizada do sistema. [E]

• Opção para alterar a terminologia utilizada (ex: nomes de perspectivas). [H]

Em contrapartida as respostas negativas foram as seguintes:

• Possibilidade de arquivar informação do sistema actual para histórico. [D]

• Definição de políticas de segurança (utilizadores/permissões/acessos). [F]

• Funcionalidades de agendamento de tarefas (correio electrónico, extracção de dados, etc).

[G]

Estas três funcionalidades consideradas como não existentes são na realidade do âmbito dos

administradores dos sistemas de informação, pois geralmente constituem requisitos não-funcionais,

quase obrigatórios para este segmento de aplicações informáticas. Acreditamos que se este grupo



51

relacionado com a flexibilidade tivesse sido respondido pelos administradores dos sistemas de

informação, as respostas teriam sido consistentes com aquelas que foram dadas pelos fornecedores.

Pois, por exemplo o arquivo de informação para histórico (letra D no gráfico) tem como benefício o

aumento do desempenho (performance) do sistema de informação, não sendo exigido ao utilizador final

este tipo de sensibilidade. Já para os acessos e políticas de segurança, em que a maioria dos utilizadores

não reconheceram como existentes no seu sistema de informação actual, eles assumem-se como

obrigatórios em qualquer sistema de informação. O exemplo de uma situação onde se verificou a

inexistência de politicas de segurança foi no caso dos utilizadores que utilizam o Microsoft Excel como

ferramenta informática de apoio ao BSC.

Para o último grupo, características técnicas, pode observar-se melhor as constatações

inferidas anteriormente. Observando-se o gráfico seguinte compreende-se que o utilizador comum não

tem a mesma percepção e sensibilidade do fornecedor, uma vez que estes aspectos estão mais

intimamente relacionados com a área não-funcional dos sistemas de informação.

0

1

2A

B

C

DE

F

G


Gráfico 5 – Funcionalidades Existentes: características técnicas

Como funcionalidades existentes foram referidas as seguintes (referenciadas com a letra

respectiva do gráfico):

• Fácil de usar e intuitivo. [D]

• Sistema baseado em ambiente de janelas. [E]

Aquelas que foram referidas como não existentes foram as restantes:

• Funcionamento em várias plataformas ou sistemas operativos. [A]

• Desenvolvimento do sistema em tecnologia WEB. [B]



52

• Sistema assente num Sistema de Gestão de Base de Dados Relacional. [C]

• Sistema cliente/servidor. [F]

• Sistema multi-língua. [G]

Tendo sido observados alguns casos específicos e analisados os respectivos questionários

verificou-se que alguns utilizadores responderam que não tinham conhecimentos suficientes para

responder. Deste grupo conclui-se que a opinião dos fornecedores ilustra melhor a realidade acerca das

funcionalidades existentes.

3.4.2 ANÁLISE DAS FUNCIONALIDADES UTILIZADAS

Do ponto de vista das funcionalidades utilizadas verificou-se na generalidade dos inquéritos a

sua coincidência com as existentes, isto é na quase totalidade dos inquéritos foi respondido que se

utilizam as funcionalidades existentes. Contudo, existem alguns casos em que estando as

funcionalidades disponíveis, não são utilizadas. Para não nos tornarmos repetitivos relativamente à

análise anterior sobre as funcionalidades existentes, optámos por apresentar gráficos e analisar somente

os casos em que as funcionalidades utilizadas não coincidem com as existentes.

Para o grupo relacionado com a construção do modelo principal, apresenta-se de seguida o

gráfico que traduz as respostas recolhidas.

0

1

2A

B

C

D

E

F

G

H

IJ

K

L

M

N

O

P

Q


Gráfico 6 – Funcionalidades Utilizadas: construção do modelo principal

Legenda: 1 – Funcionalidade utilizada na aplicação informática actual. 2 - Funcionalidade não utilizada na aplicação informática actual.


53

Observando este gráfico e comparando-o com o mesmo gráfico relativo às funcionalidades

existentes verifica-se que as funcionalidades seguintes não são utilizadas apesar de estarem disponíveis

(referenciadas com a letra respectiva do gráfico):



Tendo sido analisados mais pormenorizadamente os questionários em que se verificaram estas

respostas, observou-se que a razão para a não utilização da funcionalidade [N] prende-se com a

inexistência da necessidade de criar scorecards extra e, relativamente à funcionalidade [O] normalmente

serem estabelecidos somente indicadores gerais e por unidade de negócio, não sendo definidos ao nível

do empregado.

O próximo e último caso em que também se verificou uma diferença entre a utilização e

existência de funcionalidades foi ao nível do grupo relacionado com a comunicação. Os fornecedores

apesar de reconhecerem que a funcionalidade de alertas sobre indicadores, comentários e mensagens

(letra [B] no gráfico) existe, têm consciência de que não é utilizada. Considera-se que esta resposta

poderá ser o resultado da experiência de implementações realizadas pelos fornecedores em várias

organizações. O próximo gráfico é apresentado para mostrar as respostas fornecidas pelos

fornecedores para este grupo da comunicação.

0

1

2A

B

C

D

E

FG

H

I

J

K


Gráfico 7 – Funcionalidades Utilizadas: comunicação

Legenda: 1 - Funcionalidade utilizada na aplicação informática actual. 2 - Funcionalidade não utilizada na aplicação informática actual.


54

3.4.3 ANÁLISE DA IMPORTÂNCIA ATRIBUÍDA

Esta secção tem como objectivo a análise do nível de importância reconhecida a cada

funcionalidade. Dentre os vários tipos de escalas de medição de opiniões e atitudes existentes,

escolheu-se a escala de Lickert cuja mais valia é permitir evitar a rigidez e limitações das alternativas

“concordo-discordo” conforme esclarece Pardal e Correia (1995), sendo a graduação de 1 (mínima

importância) até 5 (máxima importância).

Mais uma vez se salienta que o objectivo da aplicação destes questionários era fazer uma

análise qualitativa sobre as opiniões de organizações com experiência neste tipo de sistemas de

informação, não se apresentando por isso percentagens ou dados quantitativos, mas sim as opiniões

mais e menos votadas classificadas pelo tipo de entidade inquirida (utilizador, fornecedor). Alerta-se

também para o facto desta escala ser longa e por isso permitir o refúgio das respostas menos

compreendidas no valor 3 (valor central).

Começando pelo grupo relativo à construção do modelo principal do scorecard, apresenta-se o

seguinte gráfico:

0

1

2

3

4

5A

B

C

D

E

F

G

H

IJ

K

L

M

N

O

P

Q


Gráfico 8 – Importância de Funcionalidades: concepção do modelo principal

No que concerne à construção do modelo principal observaram-se várias realidades

interessantes, sendo as opiniões coincidentes quanto à importância atribuída, para as seguintes

funcionalidades (referenciadas com a letra respectiva do gráfico):

• Definição dos objectivos estratégicos. [D]

• Indicação de objectivos, indicadores, metas e iniciativas para cada um das perspectivas

padrão. [E]

• Indicação das fórmulas de cálculo dos indicadores. [F]

Legenda: 1 – Importância mínima atribuída 5 – Importância máxima atribuída


55

• Estabelecimento de ligações entre objectivos, indicadores, metas e iniciativas. [G]

• Definição de várias metas para cada objectivo. [K]


Embora exista um leque de funcionalidades que os fornecedores consideram mais

importantes, observou-se que essa importância corresponde a apenas um nível de aumento na escala.

Assim, aquelas a que os fornecedores atribuíram mais importância do que os utilizadores foram:

• Atribuição de objectivos a utilizadores específicos ou grupos de utilizadores. [J]


evolução. [L]



• Possibilidade para inserir um número ilimitado de objectivos, indicadores, metas e

iniciativas para qualquer perspectiva. [Q]

Em contrapartida também os utilizadores consideraram algumas funcionalidades com maior

grau de importância do que os fornecedores, nomeadamente:

• Definição da missão. [A]

• Definição da visão. [B]

• Definição da estratégia. [C]

• Mapa de relações de causa-efeito. [H]

• Possibilidade de interligar objectivos em diversas camadas (em cascata). [I]

• Assistentes para ajuda aos utilizadores na realização de determinadas tarefas. [P]

De salientar que a definição dos três valores principais missão, visão e estratégia e do mapa de

relações causa-efeito são ligeiramente mais importantes para os utilizadores do que do ponto de vista

dos fornecedores, sendo a nossa opinião de que devem ser considerados como necessários num

sistema de informação de suporte ao BSC.

Para o segundo grupo de funcionalidades, cujo objectivo é a avaliação das opiniões acerca das

funcionalidades relacionadas com a comunicação e difusão de informação no seio da organização,

apresenta-se de seguida o gráfico.


56

0

1

2

3

4

5A

B

C

D

E

FG

H

I

J

K


Gráfico 9 – Importância de Funcionalidades: comunicação

Para esta categoria de respostas também se registaram opiniões coincidentes, sendo as

seguintes (referenciadas com a letra respectiva do gráfico):

• Introdução de comentários aos objectivos, indicadores, metas e iniciativas por parte dos

utilizadores do sistema. [A]

• Sistema de alertas sobre os indicadores, comentários introduzidos e mensagens. [B]

• Apresentação gráfica da ligação entre os objectivos. [D]

• Possibilidade de ligar documentos, mensagens de correio, aplicações externas, etc., a

indicadores e objectivos. [E]

• Existência de relatórios e modelos de relatórios pré-definidos (perspectiva, indicadores vs

metas). [H]

Para os fornecedores, observou-se que as seguintes funcionalidades têm mais importância:

• Mecanismos para partilha de informação entre os empregados. [C]

• Uso de informação gráfica (ex: semáforos, imagens, gráficos, etc., na representação das

tendências de evolução dos indicadores). [F]

• Uso de informação qualitativa para descrever a evolução de indicadores (bom, mau,

aumentou, baixou, positivo, etc). [G]

• Possibilidades dos utilizadores construírem relatórios pessoais e personalizados. [I]

Segundo a perspectiva dos utilizadores foram classificadas duas funcionalidades com maior

grau de importância relativamente à opinião dos fornecedores. Embora estas duas funcionalidades



57

tenham uma classificação pouco superior, se tivermos em consideração que não são utilizadas,

podemos concluir que não são críticas nem esperadas pelos utilizadores num sistema de informação de

suporte ao BSC. As funcionalidades são a seguintes:

• Possibilidade para personalizar a aplicação por utilizador. [J]

• Uso de gráficos de GANTT para vários tipos de análise. [K]

Para a vertente de negócio (terceiro grupo do questionário), embora o gráfico seguinte

apresente diferenças entre as classificações atribuídas por ambos os inquiridos pode considerar-se que

sendo essas diferenças mínimas, todas as funcionalidades são importantes.

0

1

2

3

4

5A

B

C

D

EF

G

H

I


Gráfico 10 – Importância de Funcionalidades: negócio

Observando o gráfico acima facilmente se verifica que quase todos os níveis de importância

atribuídos são coincidentes, e mesmo para aqueles que não coincidem a diferença é mínima. A única

funcionalidade que se poderá considerar como não crítica é a que está relacionada com a construção de

diagramas dinâmicos pelos utilizadores (letra [G] no gráfico), mas seguindo uma política de valorização

das opiniões dos utilizadores conclui-se que deve ser considerada igualmente importante.

No que concerne à flexibilidade (gráfico 11) e há semelhança do observado nas análises

anteriores sobre a existência e uso de funcionalidades, partiu-se do princípio que os utilizadores têm

menos sensibilidade nestas questões do que os fornecedores, tendo-se optado por valorizar as opiniões

destes últimos. O gráfico seguinte contém as respostas para este grupo de funcionalidades, mostrando

uma maior tendência de valorização da flexibilidade por parte dos fornecedores.



58

0

1

2

3

4

5A

B

C

D

E

F

G

H


Gráfico 11 – Importância de Funcionalidades: flexibilidade

Realmente a maior parte das funcionalidades têm níveis de importância coincidentes e quando

o não são, a diferença é mínima. Para a funcionalidade de agendamento de tarefas (letra [G] no gráfico)

em que os utilizadores lhe atribuem mais importância, a nossa opinião é que deva ser considerada de

nível médio porque conforme observado nos dados recolhidos não é utilizada pela grande maioria das

organizações inquiridas.

Quanto ao último grupo (gráfico 12) sobre características técnicas, este é muito restritivo em

termos de população inquirida habilitada para as questões formuladas. Esta população é composta

pelos fornecedores e pelos administradores dos sistemas de informação da organização. Antes de tecer

as análises a este grupo apresentamos o gráfico respectivo:

0

1

2

3

4

5A

B

C

DE

F

G


Gráfico 12 – Importância de Funcionalidades: características técnicas




59

Uma vez que o questionário foi respondido por utilizadores com fraca sensibilidade para

questões técnicas, compreende-se que as opiniões coincidentes ou muito próximas das dos

fornecedores são as relativas à facilidade de uso no sistema (letra [D] no gráfico), sistema baseado num

ambiente de janelas (letra [E] no gráfico) e desenvolvimento do sistema em tecnologia WEB (letra [B]

no gráfico).

Todas as outras podem considerar-se necessárias em sistemas de informação de suporte ao

BSC, com excepção da característica relacionada com “sistema multi-lingua” (letra [G] no gráfico)

porque esta última funcionalidade está caracterizada como não utilizada nos gráficos anteriores acerca

das funcionalidades existentes e utilizadas. Não se considerando esta funcionalidade crítica constituirá

uma mais valia para o sistema de informação se o âmbito de implementação for ao nível de

organizações multinacionais.

3.4.4 CONCLUSÕES FINAIS AOS RESULTADOS RECOLHIDOS

Concluídas as análises às respostas recolhidas com os questionários é agora altura de fazer uma

análise conclusiva global, finalizando com a criação de uma lista das funcionalidades esperadas pelos

utilizadores deste tipo de sistemas de informação.

Como já foi referido anteriormente os inquiridos estendem-se desde organizações nacionais a

internacionais, nomeadamente utilizadores, fornecedores e consultores. Sendo nosso objectivo final a

constituição de uma lista de funcionalidades partimos do principio de aceitar todas as funcionalidades

cujo valor da mediana das respostas dos utilizadores se situe nos níveis 4 e 5 de importância. A

excepção passa-se para os grupos de funcionalidades relacionadas com a flexibilidade e características

técnicas, cujas respostas aceites serão as dos fornecedores, pois estes têm maior sensibilidade para estas

questões.

Para o grupo de funcionalidades relacionadas com a construção do modelo principal (scorecard)

optou-se por considerar todas as funcionalidades enunciadas no questionário, com a excepção das

seguintes três:


evolução. [L]



Observando os gráficos anteriores relativos à importância atribuída e à utilização das

funcionalidades por parte dos utilizadores, achámos por bem não considerar estas três funcionalidades

como esperadas pelos utilizadores porque, se por um lado lhes foi atribuído o nível médio de


60

importância, por outro também se verifica que não são usadas, apesar dos fornecedores indicarem que

geralmente estão disponíveis nos sistemas de informação.

Para o segundo grupo, o da comunicação, optou-se igualmente por considerar todas as

funcionalidades enunciadas com a excepção das quatro seguintes:

• Mecanismos para partilha de informação entre os empregados. [C]

• Possibilidade dos utilizadores construírem relatórios pessoais e personalizados. [I]

• Possibilidade para personalizar a aplicação por utilizador. [J]

• Uso de gráficos de GANTT para vários tipos de análise. [K]

Tal como para o grupo anterior, estas funcionalidades foram classificadas com nível médio de

importância e observando o gráfico sobre as funcionalidades geralmente utilizadas constata-se que

também não são usadas.

Para o terceiro grupo de funcionalidades relativas ao negócio, tendo seguido os mesmos

critérios dos grupos anteriores, apenas se excluiu a que está relacionada com a construção de diagramas

dinâmicos pelos utilizadores através da técnica de drag-and-drop de vários campos (letra [G] nos

respectivos gráficos).

No campo das funcionalidades relacionadas com a flexibilidade e tal como referimos

anteriormente consideramos os fornecedores com tendo mais sensibilidade nesta área, pelo que

seguindo o mesmo critério apenas foi excluída a funcionalidade relacionada com o agendamento de

tarefas (letra [G] nos respectivos gráficos). Pois, apesar de estar disponível para utilizar, os utilizadores

geralmente não a usam.

Quanto às características técnicas consideramos todas as funcionalidades enunciadas como

necessárias. Embora a que se refere ao sistema multi-lingua possa causar algumas dúvidas quanto à sua

consideração como necessária, achamos que deve ser considerada porque caso contrário constituiria

uma limitação do sistema de informação.


61

3.5 LISTA DE FUNCIONALIDADES

Após uma análise exaustiva da oferta tecnológica para o Balanced Scorecard e das características

dos sistemas de informação que suportam este conceito, vamos definir aquela que consideramos ser a

lista de funcionalidades esperadas pelos utilizadores deste tipo de sistemas de informação.

Adoptando o modelo usado no inquérito, apresentam-se de seguida as funcionalidades

agrupadas nos mesmos cinco grupos:

MODELO PRINCIPAL

● Definição da missão Descrever a missão definida para a organização. ● Definição da visão Descrever a visão definida para a organização. ● Definição da estratégia Descrever a estratégia definida para a organização. ● Definição dos objectivos estratégicos Indicar os objectivos traçados. ● Indicação de objectivos, indicadores, metas e iniciativas para cada um das perspectivas padrão

Atribuir a cada perspectiva os objectivos, indicadores, metas e iniciativas definidas.

● Indicação das fórmulas de cálculo dos indicadores

Para cada indicador indicar a respectiva fórmula de cálculo.

● Estabelecimento de ligações entre objectivos, indicadores, metas e iniciativas

Possibilidade de criar ligações que ilustrem a que objectivos correspondem determinados indicadores, metas e iniciativas.

● Mapa de relações de causa-efeito Possibilidade de criar o mapa de relações de causa e efeito entre os objectivos estratégicos, enquadrando-os nas respectivas perspectivas.

● Possibilidade de interligar objectivos em diversas camadas (em cascata)

Possibilidade de estabelecer uma relação de interdependência entre os objectivos, em forma de árvore.

● Atribuição de objectivos a utilizadores específicos ou grupos de utilizadores

Definir responsáveis pela concretização de objectivos específicos.

● Definição de várias metas para cada objectivo (meta interna, meta benchmark)

Definição de várias metas que ilustrem vários graus de concretização do objectivo.

● Definição de indicadores específicos (utilizador) e gerais (organização)

Criação de indicadores específicos para certa área de negócio ou utilizador e indicadores gerais ao nível da organização.

● Assistentes para ajuda aos utilizadores na realização de determinadas tarefas

Existência de assistentes (wizards) para ajuda aos utilizadores na realização de tarefas não rotineiras.

● Possibilidade para inserir um número ilimitado de objectivos, indicadores, metas e iniciativas para qualquer perspectiva

Possibilidade para atribuir um número ilimitado de objectivos, indicadores, metas e iniciativas para cada perspectiva.

COMUNICAÇÃO ● Introdução de comentários aos objectivos, indicadores, metas e iniciativas por parte dos utilizadores do sistema

Possibilidade dos empregados introduzirem comentários ou sugestões sobre objectivos, indicadores, metas e iniciativas.

● Sistema de alertas sobre os indicadores, comentários introduzidos e mensagens.

Sistema que produza alertas (mensagens de e-mail, telemóvel) quando determinado indicador atingir níveis definidos nos parâmetros.

● Apresentação gráfica da ligação entre os objectivos

Apresentação da ligação gráfica (usando caixas, setas, etc.) estabelecida entre os objectivos. Possibilidade de realizar alterações no modelo gráfico.

● Possibilidade de ligar documentos, Ligada aos objectivos e/ou indicadores deverá haver


62

mensagens de correio, aplicações externas, etc., a indicadores e objectivos

informação que permita avaliar a evolução do indicador no tempo e um histórico das medidas tomadas.

● Uso de informação gráfica (ex: semáforos, imagens, gráficos, etc., na representação das tendências de evolução dos indicadores)

Uso de informação gráfica para facilitar a compreensão clara e rápida do grau de desempenho de cada objectivo.

● Uso de informação qualitativa para descrever a evolução de indicadores (bom, mau, aumentou, baixou, positivo, etc)

Uso de informação qualitativa que descreva o nível de evolução dos indicadores.

● Existência de relatórios e modelos de relatórios pré-definidos (perspectivas, indicadores vs metas)

Existência de relatórios genéricos já disponíveis na aplicação e modelos que permitam a rápida criação de outros.

NEGÓCIO ● Relatório do desempenho actual e histórico de cada indicador

Documento que evidencie e compare o desempenho actual e histórico de cada indicador.

● Monitorização (gráfica e descritiva) do índice de satisfação de cada objectivo.

Monitorização em tempo real do índice de satisfação de cada objectivo, indicador, meta e iniciativa. A qualquer momento deve ser possível observar o grau de concretização de determinado objectivo.

● Existência de vários tipos de indicadores/métricas

Existência de vários tipos de indicadores predefinidos por perspectiva.

● Capacidade para desdobrar a informação em diversos níveis de detalhe

Possibilidade do utilizador ir desdobrando a informação em diversos níveis de detalhe até encontrar a origem dos factos que observa.

● Definição de empregados responsáveis por iniciativas e indicadores

Definição de empregados responsáveis pelo desempenho de determinado indicador ou realização de determinadas tarefas.

● Associação de sistema de recompensas às metas e iniciativas individuais

Associação de sistema de recompensas sobre metas e iniciativas individuais.

● Análises multi-dimensionais (ferramentas OLAP)

OLAP – Online Analytical Processing, designa as ferramentas que permitem realizar análises sobre dados em diversas perspectivas (dimensões).

● Acompanhamento e medição do desempenho individual (por empregado) e respectiva contribuição para a satisfação dos objectivos estratégicos

Possibilidade de obter o desempenho de cada empregado e respectiva contribuição para o alcance dos objectivos estratégicos.

FLEXIBILIDADE ● Importação de dados provenientes de sistemas externos (folhas de cálculo, bases de dados)

Alimentação do sistema com dados provenientes de fontes externas.

● Exportação de dados em diversos formatos (XML, texto, Ms EXCEL, etc)

Exportação de informação em diversos formatos.

● Possibilidade de implementações totais (toda a organização) ou parcelares (departamentos)

O sistema de informação deve permitir implementações parciais (por unidade de negócio) e ser escalável para depois ser alargado ao resto da organização.

● Possibilidade de arquivar informação do sistema actual para histórico

Possibilidade de mover informação para base de dados de histórico, como meio de aumento da performance do sistema e eliminação de informação excessiva e desnecessária para o dia-a-dia.

● Administração centralizada do sistema Administração centralizada do sistema. ● Definição de políticas de segurança (utilizadores/permissões/acessos)

Definição de políticas de segurança, controlando acessos e permissões (leitura e escrita).

● Opção para alterar a terminologia utilizada (ex: nomes de perspectivas)

Opção para alterar os termos ou conceitos utilizados no sistema. Por exemplo poder alterar o nome das perspectivas.


63

CARACTERÍSTICAS TÉCNICAS ● Funcionamento em várias plataformas ou sistemas operativos (Windows, UNIX)

O sistema de informação deverá funcionar em vários sistemas operativos.

● Desenvolvimento do sistema em tecnologia WEB (HTML, ASP, PHP, .NET, J2EE)

Desenvolvimento do sistema em tecnologia web, para que funcione na intranet da organização através do browser.

● Sistema assente num Sistema de Gestão de Base de Dados Relacional (SQL Server, Oracle, Informix)

Sistema assente numa base de dados relacional.

● Fácil de usar e intuitivo Facilidade de utilização do sistema, cumprindo as regras de usabilidade.

● Sistema baseado em ambiente de janelas Sistema baseado em ambiente de janelas e multi-tarefa conforme o princípio do MS Windows.

● Sistema cliente/servidor Sistema cliente/servidor. Tabela 2 – Lista final de funcionalidades

3.6 RESUMO

Este capítulo termina a primeira grande parte desta dissertação. Começou-se por estudar o

Balanced Scorecard (BSC) enquanto instrumento de gestão estratégica, estudo este que não foi muito

aprofundado porque não se justificava neste contexto. Depois partimos para o estudo do suporte

tecnológico, cujo objectivo era avaliar a oferta tecnológica existente para suporte ao BSC.

Neste capítulo estruturámos o estudo da oferta tecnológica ao BSC em três fases, permitindo-

nos assim simplificá-lo com o necessário nível de detalhe. Na primeira fase analisou-se diversa

documentação do instituto Balanced Scorecard Collaborative, tendo-se extraído as funcionalidades mínimas

para um sistema de informação de suporte ao BSC. A segunda fase consistiu numa recolha e análise

mais leve sobre os sistemas de informação certificados pelo mesmo instituto B.S. Collaborative. Em

todas as aplicações analisadas verificou-se a existência de um conjunto de funcionalidades comuns,

pelo que se recolheram as restantes funcionalidades consideradas igualmente importantes para o

sistema. Na última fase foi constituída uma lista genérica de todas as funcionalidades consideradas

importantes e, como meio de a validar, optou-se por inquirir organizações nacionais e estrangeiras com

experiência nesta área.

O resultado final deste capítulo é uma lista de funcionalidades que consideramos serem as

esperadas pelos utilizadores, servindo de base aos próximos capítulos desta dissertação. Na perspectiva

dos consultores acreditamos que esta lista é uma forte contribuição para a identificação das

necessidades dos seus clientes, podendo também constituir um guia para auxílio em futuras

implementações de sistemas de informação relacionados com o BSC. Na perspectiva dos fornecedores

esta lista encerra um estudo das funcionalidades esperadas pelos utilizadores, constituindo assim uma

base de conhecimento útil tanto para o melhoramento dos seus SI, como para a prestação de melhor

serviço aos seus clientes no futuro. Por fim, e segundo a perspectiva dos utilizadores deste tipo de

sistemas, este estudo por um lado dá a conhecer as funcionalidades mínimas a exigir junto dos


64

fornecedores de sistemas de informação de suporte ao BSC, e por outro serve para difundir a opinião

de um conjunto de organizações que também têm suportado o seu BSC num sistema de informação

próprio.

O próximo capítulo serve de introdução à segunda parte desta dissertação, onde serão

estudadas algumas das mais recentes metodologias de desenvolvimento de software, com vista à escolha

daquela que servirá de base à modelação conceptual de um sistema de informação para suporte ao

BSC.

Capítulo IV

METODOLOGIAS DE DESENVOLVIMENTO DE SOFTWARE

• Enquadramento

• Rational Unified Process (RUP)

• Iconix

• Extreme Programming (XP)

• Microsoft Solutions Framework (MSF)

CAPÍTULO 4 – METODOLOGIAS DE DESENVOLVIMENTO DE SOFTWARE

67

Após o estudo, tanto do BSC como dos sistemas de informação que o suportam, tendo no capítulo anterior sido constituída uma lista das funcionalidades que servirão de base ao sistema a modelar, achou-se por bem realizar um breve estudo sobre as principais metodologias de desenvolvimento de software existentes.

Assim, neste capítulo vão ser estudadas quatro metodologias dando especial ênfase àquela que escolhemos para suportar o desenvolvimento do sistema. As metodologias estudadas são: Rational Unified Process (RUP), ICONIX, Extreme Programming (XP) e Microsoft Solutions Framework (MSF).

4.1 ENQUADRAMENTO

Actualmente a tendência dos sistemas de informação é para o crescimento tanto em tamanho

(áreas de negócio suportadas) como em complexidade. Isto devido, em parte, ao facto da informação

nunca ter tido tanto valor como nos tempos actuais no que concerne no apoio ao processo de tomada

de decisões nas organizações. Este facto levou à necessidade de suportar os processos de negócio da

organização em sistemas de informação que disponibilizem informação clara, fiável e em tempo real,

constituindo por isso um factor de competitividade para as organizações.

Muito do software produzido ainda não assenta em processos de desenvolvimento estruturados

ou planos, sendo mesmo considerado por Fowler (2003) como sendo uma actividade “caótica”

caracterizada pela escrita de código-fonte indiscriminadamente e posterior correcção do mesmo. Este

processo não está totalmente errado, sendo até aconselhável quando o sistema a desenvolver for

pequeno e com baixo grau de exigência por parte do cliente final. Quando os sistemas são grandes,

cobrem várias áreas de negócio e não estão apoiados num processo de desenvolvimento, isto é, são

geridos de uma forma ad-hoc, torna-se extremamente difícil controlar o seu desenvolvimento sempre

que é necessário proceder a novos desenvolvimentos, assim como também é dificultada a tarefa de

correcção de erros. As metodologias impõem disciplina ao processo de desenvolvimento de software

tornando-o mais eficiente e previsível, pois obrigam à produção de documentação de suporte e ao

planeamento antecipado de tempos, actividades e metas a atingir.

Quando uma organização decide conceber um sistema de informação surgem um conjunto de

questões para definir: que produto vai ser desenvolvido; quanto tempo vai demorar; qualidade exigida,

etc. Estas questões só podem ser avaliadas e analisadas se for seguida uma metodologia de

desenvolvimento de software.


68

A adopção de metodologias de desenvolvimento de software tem vindo a ganhar cada vez mais

importância à medida que aumenta o grau de complexidade e exigência dos sistemas de informação.

Citando McConnell (1996), a necessidade de adoptar uma metodologia para desenvolvimento de

software cresce à medida que o ciclo de desenvolvimento do produto também cresce, o tamanho e

âmbito do projecto aumenta e os parâmetros de qualidade impostos são mais exigentes. Projectos onde

não seja aplicada uma metodologia desde cedo pagarão mais tarde com o aumento descontrolado dos

custos de desenvolvimento, pois, a adopção de uma metodologia tem vários benefícios:

• Minimização da duplicação de trabalho porque obriga à definição de planos antes da

construção do produto.

• Permite o uso e distribuição eficiente de recursos em todas as fases do processo.

• Testes ao produto podem ser desenvolvidos no início do seu desenvolvimento poupando

recursos e tempo relativamente a processos tradicionais em que os testes eram realizados

apenas no fim do desenvolvimento.

• Os testes permitem assegurar a qualidade do produto desde uma fase inicial e ao longo de

todo o processo de desenvolvimento.

• Orienta o desenvolvimento do produto para as necessidades do cliente final.

4.2 RATIONAL UNIFIED PROCESS

O Rational Unified Process (RUP) apresenta-se como uma metodologia para desenvolvimento de

software17, desenvolvida pela empresa Rational Software. Esta metodologia actua como um guia para a

condução de um projecto de desenvolvimento de software, cobrindo todos os aspectos geralmente

associados a projectos de desenvolvimento de sistemas de informação, independentemente da sua

dimensão e complexidade. Embora esta metodologia já disponibilize uma variedade de modelos que

podem ser aplicados a qualquer projecto, também estabelece normas e boas práticas que poderão ser

aplicadas em casos e situações específicas cuja natureza não permita a adopção dos modelos standards

da metodologia.

A ideia geral do RUP para o desenvolvimento de software assenta em boas práticas com vista à

redução dos riscos inerentes ao seu desenvolvimento, conforme enumeramos de seguida (EVANS,

2001; KRUCHTEN, 2003; SILVA e VIDEIRA, 2001; WEST, 2002):

1. Metodologia de desenvolvimento iterativa

17 Software – programas para computador, procedimentos, documentação associada e dados necessários ao funcionamento de um sistema informático (IEEE, 1990).


69

2. Gestão dos requisitos

3. Desenvolvimento de software baseado em arquitecturas de software e componentes

4. Modelação visual

5. Controlo contínuo da qualidade

6. Gestão da mudança

4.2.1 METODOLOGIA DE DESENVOLVIMENTO ITERATIVA

O RUP é um processo iterativo e incremental composto por fases e iterações. As iterações são

orientadas para os riscos do projecto, forçando assim a identificação e solução desses riscos numa fase

inicial do projecto. Segundo Kroll e Kruchten (2003) este tipo de metodologia previne uma série de

problemas geralmente associados ao desenvolvimento de software:

• Ajuda à resolução de equívocos numa fase inicial enquanto ainda é possível resolvê-los.

• Aumenta a participação do utilizador no processo e consequentemente o seu feedback

acerca dos requisitos necessários.

• A equipa de desenvolvimento é obrigada a focar-se nas questões críticas para o projecto.

• Percepção constante do estado do projecto.

• Detecção antecipada de inconsistências nos requisitos, análise e desenho do sistema.

• O trabalho de testes é diluído por todo o processo de desenvolvimento.

• Pode-se aprender muito com este processo e retirar boas práticas para aplicar no futuro

noutros projectos.

4.2.2 GESTÃO DOS REQUISITOS

A perspectiva de gestão dos requisitos obriga ao sistemático levantamento, organização,

comunicação e gestão das mudanças aos requisitos inicialmente formulados. Como vantagens desta

gestão têm-se a detecção atempada de inconsistências entre os requisitos e, por outro lado a

possibilidade de lhes atribuir diferentes prioridades.

4.2.3 ARQUITECTURA DE SOFTWARE E COMPONENTES

A proposta desta metodologia é que a arquitectura do sistema a desenvolver seja descrita em

termos de componentes, na forma como estão integrados e na definição de regras sobre a sua

interacção.


70

As arquitecturas baseadas em componentes são escaláveis e adaptáveis às constantes mudanças

no sistema de informação, facilitando também a reutilização de código fonte ou objectos já

desenvolvidos por outros fornecedores de software.

4.2.4 MODELAÇÃO VISUAL

Os modelos ajudam à formulação do problema e compreensão da solução proposta tanto pela

equipa de programação do software como pelos seus destinatários (utilizadores finais). Adoptando-se a

definição de “modelo” como uma simplificação da realidade pode-se inferir que a construção de

modelos ajuda à concreta definição de requisitos, fornecendo uma base de entendimento entre pessoas

com diferentes sensibilidades para o mesmo problema (utilizadores, consultores, programadores).

4.2.5 CONTROLO CONTÍNUO DA QUALIDADE

A qualidade foca ambas as vertentes do desenvolvimento de software: o processo de

desenvolvimento e o produto final. Realizando o desenvolvimento de software apoiado num processo

ou metodologia estruturada assegura e facilita a qualidade do produto final.

O controlo de qualidade, segundo Kruchten (2003) permite a identificação de defeitos quando

eles ocorrem reduzindo consequentemente o custo de correcção dos mesmos. Além disso também os

testes e controlos são efectuados sobre áreas críticas, levanto ao aumento da qualidade nestas áreas. A

figura seguinte ilustra que o custo de correcção de erros aumenta significativamente consoante a altura

da sua detecção.

Figura 6 – Custo de correcção de problemas (adaptado de Kruchten 2003)

Por esta razão é importante detectar e resolver os problemas o mais cedo possível. Isto só se

consegue se for seguida uma política de controlo da qualidade nas diversas áreas do software em

desenvolvimento, nomeadamente: funcionalidades, desempenho e segurança.

Tempo

Custo


71

4.2.6 GESTÃO DA MUDANÇA

A necessidade de realizar novas versões do sistema, correcção de erros e criação de novas

funcionalidades leva a constantes mudanças dos componentes e objectos do software. Se estas mudanças

não forem documentadas e controladas rapidamente se atinge um descontrolo tal, capaz de provocar

erros de compatibilidade e funcionamento da aplicação informática. Corre-se o risco de, tentando

corrigir um problema se estarem a criar outros novos problemas na aplicação informática. Por isso, e

citando Kruchten (2003), a criação e manutenção de documentação para cada versão de software é

essencial para prever o impacto das mudanças no software já desenvolvido.

Para além destas boas práticas existem também quatro conceitos chave utilizados no âmbito

do RUP e que interessa definir:

• Interveniente (quem) – define comportamentos e responsabilidades de um ou mais

indivíduos (analista, programador).

• Actividade (como) – unidade de trabalho realizada por um interveniente

• Artefacto (o quê) – informação produzida, alterada e utilizada durante uma actividade

• Tarefa (quando) – sequência de actividades que produzem um resultado observável.

Realiza Actividade

Interveniente

Responsável por

Artefacto

Output Input

Figura 7 – Conceitos do RUP (adaptado de SILVA e VIDEIRA, 2001)

O RUP é um processo iterativo que estrutura o processo de desenvolvimento de software em

duas dimensões (figura 7): a dimensão temporal (eixo horizontal) e a dimensão dos elementos do

processo (eixo vertical).


72

Figura 8 – Estrutura do RUP: duas dimensões (adaptado de KRUCHTEN, 2003)

A dimensão temporal, representando a componente dinâmica do RUP, mostra o processo de

desenvolvimento em termos de ciclos, fases e iterações sendo composto por quatro fases cada uma

com várias iterações. Essas fases são:

• Concepção – nesta fase é definido o âmbito do projecto incluindo critérios de sucesso,

avaliação de riscos e recursos necessários.

• Elaboração – durante esta fase é realizada uma análise do domínio do problema em

detalhe e definida uma arquitectura, tendo como objectivo final o estabelecimento de uma

base estável para as próximas fases. Para a construção da arquitectura base são tidos em

conta os requisitos funcionais críticos para o sistema, assim como também se solucionam

os maiores riscos.

• Construção – esta fase consiste no desenvolvimento do projecto, obtendo-se uma versão

operacional do produto desenvolvido.

• Transição – nesta fase o objectivo passa pela transferência da propriedade do sistema para

o cliente final. É composta por várias tarefas de implementação, formação, pequenos

ajustes através da realização de pequenos desenvolvimentos, tudo isto com vista a deixar o

sistema totalmente operacional para o cliente.

Cada uma destas fases anteriormente referidas tem definidas metas para possibilitar a

comparação dos resultados e tempos alcançados com os previstos inicialmente.

A dimensão dos elementos do processo, representando a componente estática do RUP,

descreve as tarefas (workflows) e actividades a realizar, indica quais os artefactos (documentos) a


73

produzir em cada fase e os respectivos intervenientes (workers). Esta dimensão estática divide os

workflows em dois grupos: os de processamento e os de suporte. Começando pelos workflows de

processamento, temos os seguintes (KRUCHTEN, 2003; SILVA e VIDEIRA, 2001):

• Modelação do negócio – descreve a estrutura e dinâmica da organização, incluindo

actividades que levem à compreensão dos processos de negócio.

• Requisitos – descreve o método para fazer o levantamento dos requisitos baseando-se no

desenvolvimento de casos de utilização. Tem como metas definir o que é esperado que o

sistema faça, através da determinação das necessidades do cliente e a definição das

fronteiras do sistema. Este workflow é aquele que vai fornecer a informação necessária para

ser feita a estimativa de custos com o projecto.

• Análise e Desenho – nesta fase são especificados os requisitos e identificada a arquitectura

através de casos de utilização e do diagrama de classes obtendo-se um modelo que servirá

de base ao desenvolvimento na próxima fase.

• Implementação – nesta fase é feita a implementação das classes e produção do código

fonte de acordo com os diagramas construídos na fase anterior. O resultado é a criação de

um programa executável e operacional.

• Testes – neste workflow é verificada a qualidade e conformidade do software produzido com

os requisitos definidos, de acordo com planos de testes.

• Instalação – esta é a fase em que se disponibiliza o software produzido aos seus utilizadores

finais, incluindo também a produção de manuais, instalação e configuração do sistema.

Cada um destes workflows de processamento ocorre maioritariamente em cada uma das fases da

dimensão temporal, contudo pode observar-se que devido ao RUP ser um processo iterativo estes

workflows ocorrem em todas as quatro fases. A título de exemplo, os testes devem ser realizados durante

todo o processo de desenvolvimento, constituindo um erro pensar-se em esperar pelo fim do ciclo de

desenvolvimento do produto para depois o testar.

Os workflows de suporte decorrem ao longo de todo o projecto com a mesma intensidade

porque não contribuem directamente para o produto final. São essenciais para garantir o sucesso do

processo devido às suas actividades de âmbito geral que ajudam à condução do projecto no seu todo.

Os workflows de suporte são os seguintes:

• Gestão de projectos – especificação de um conjunto de princípios a aplicar na gestão do

projecto no que diz respeito à alocação de recursos humanos e materiais, elaboração de

planos e metas a atingir, identificação e controlo dos riscos, etc.


74

• Gestão das alterações – actividades para controlo da mudança e manutenção da

integridade dos artefactos do projecto. O objectivo deste workflow é o controlo das

alterações que são surgindo durante o projecto.

• Ambiente – a razão de ser deste workflow é a definição e determinação da infra-estrutura

adequada ao desenvolvimento do sistema em termos de ferramentas, processos e

métodos.

Concluindo, o RUP é um processo bastante completo e por isso também com algum grau de

complexidade. Na sua essência ele constitui um guia para ajudar a conduzir os projectos de

desenvolvimento de software, não obrigando ao uso de todos os seus artefactos e workflows, mas sim à

adaptação à realidade onde se pretende aplicar.

Citando Silva e Videira (2001), para o futuro conta-se com o desenvolvimento de

metodologias em torno do RUP mas, menos complexas e direccionadas a vários tipos de projectos,

isto é não tão genéricas como o RUP. Estas serão as chamadas metodologias ligthweight ou

metodologias ágeis18.

4.3 ICONIX

O ICONIX é uma metodologia de desenvolvimento de software propriedade da empresa

ICONIX Software Engineering, tendo como principal criador Doug Rosenberg. O ICONIX assume-se

um pouco como uma mistura entre o RUP (Rational Unified Process) e o XP (Extreme Programming) sendo

também, à semelhança do RUP, conduzido por casos de utilização, iterativo e incremental.

O que caracteriza esta metodologia de desenvolvimento é a sua simplicidade em termos de

processo e a vasta abrangência semelhante ao RUP. Esta metodologia assenta em quatro tarefas

principais:

• Análise de requisitos

• Análise e desenho preliminar

• Desenho

• Implementação

18 Este tópico é explicado na secção 4.4, dedicada à metodologia Extreme Programming (XP).


75

Figura 9 – Visão geral do ICONIX (adaptado de SILVA e VIDEIRA 2001)

Observando a figura acima compreende-se que o ICONIX sendo mais simples que o RUP

produz toda a informação (artefactos) necessários ao desenvolvimento de software. À semelhança do

RUP existem também duas dimensões: a dinâmica e a estática. A dimensão dinâmica é composta pelos

diagramas de casos de utilização, sequências e robustez. A dimensão estática é composta pelos

diagramas de modelo do domínio e classes.

4.3.1 ANÁLISE DE REQUISITOS

As actividades desenvolvidas no âmbito da fase de análise de requisitos são as seguintes:

• Identificação dos objectos, a um nível abstracto, que compõem o sistema a desenvolver,

bem como as respectivas relações de generalização, associação e agregação.

• Construção do modelo de domínio.

• Desenvolvimento de alguns exemplos de formulários da aplicação (GUI-Graphic User

Interface) providenciando aos utilizadores finais uma ideia da aplicação informática a ser

desenvolvida.

• Desenhar casos de utilização e organizá-los em grupos. Compor essa organização num

diagrama de pacotes.

• Associar requisitos funcionais aos casos de utilização.


76

Figura 10 – Actividades da tarefa de análise de requisitos (adaptado de SILVA e VIDEIRA 2001)

Atendendo à figura anterior, constata-se que as tarefas de análise de requisitos são compostas

pelos protótipos GUI, diagramas de casos de utilização e modelo de domínio. Observa-se também que

as setas indicadas na figura mostram que o modelo funciona todo ele desde a dimensão dinâmica para

a estática, tendo como meta final a construção do diagrama de classes e posteriormente o código fonte.

4.3.2 ANÁLISE E DESENHO PRELIMINAR

Esta fase tem como objectivo o aprofundamento da análise em busca de requisitos mais

específicos não encontrados ainda, sendo composta pelas seguintes actividades:

• Descrição e detalhe dos casos de utilização construindo cenários.

• Realização da análise da robustez, criando o diagrama de robustez para cada caso de

utilização.

• Actualizar o diagrama de classes com os novos aspectos descobertos nesta fase.

Esta fase corresponde na figura seguinte aos diagramas de casos de utilização, diagramas de

robustez e diagrama de classes.


77

Figura 11 – Actividades da tarefa de análise e desenho preliminar (adaptado de SILVA e VIDEIRA 2001)

4.3.3 DESENHO

A tarefa de desenho tem como metas a especificação do comportamento do sistema e a

verificação da satisfação de todos os requisitos, sendo composta pelas seguintes fases:

• Para cada caso de utilização fazer o correspondente diagrama de sequência.

• Verificar se todos os requisitos identificados estão contemplados no desenho.

Esta tarefa é composta pelos diagramas de sequências, de robustez e de classes, como mostra a

figura abaixo.

Figura 12 – Actividades da tarefa de desenho (adaptado de SILVA e VIDEIRA 2001)


78

4.3.4 IMPLEMENTAÇÃO

A última tarefa consiste na produção do código fonte e realização de testes, sendo constituída

pelas seguintes actividades:

• Se necessário, produzir diagramas de componentes e instalação.

• Criação do código fonte.

• Realização de testes.

Figura 13 – Actividades da tarefa de implementação (adaptado de SILVA e VIDEIRA 2001)

Concluindo, o ICONIX é uma metodologia que apesar de iterativa e incremental, se apresenta

muito mais simples e prática de seguir do que o RUP.

O processo resume-se à criação do diagrama de casos de utilização e modelo de domínio numa

fase inicial. A partir deste detalham-se os casos de utilização e constroem-se diagramas de robustez

aperfeiçoando-se ao mesmo tempo o diagrama de classes. Por fim modela-se o comportamento do

sistema através dos diagramas de sequência completando o diagrama de classes. A partir desta etapa

pode ser produzido o código fonte, os programas executáveis e depois realizados testes.

Citando Videira (2001), o ICONIX tem como objectivo “fazer o menor trabalho possível, no

mais curto período de tempo, de forma a concretizar um bom sistema”, sendo por isso aconselhável a

sua aplicação a pequenos projectos e com baixo grau de complexidade.


79

4.4 EXTREME PROGRAMMING

A Extreme Programming (XP) foi desenvolvida em 1996 por Kent Beck a partir da sua

experiência na Chrysler Comprehensive Compensation (C3). Esta metodologia é uma das mais conhecidas do

grupo das metodologias ágeis19, isto é uma metodologia mais leve e direccionada a equipas de

desenvolvimento pequenas (até 12 pessoas), sendo o software desenvolvido com base em requisitos em

constante mudança.

A base do XP é a ideia de “ser feito hoje apenas aquilo que é necessário” (MARCHESI,

SUCCI, WELLS, e WILLIAMS, 2002).

A metodologia XP baseia-se na simplicidade, comunicação, feedback e coragem sendo o

significado de cada um destes valores explicado de seguida (POLLICE, AUGUSTINE, LOWE, e

MADHUR, 2004):

• Comunicação – valorização da comunicação directa e pessoal ao invés de comunicação

impessoal. Isto não implica a dispensa de documentação, antes pelo contrário defende que

deve ser produzida apenas a documentação necessária. A ideia geral é que o

desenvolvimento de software é um trabalho de equipa assente num ambiente de

comunicação aberto, onde todos partilham conhecimento e experiências.

• Simplicidade – a XP salienta a importância de se usar e trabalhar apenas naquilo que se

conhece da forma mais simples possível, deixando outras questões não prioritárias para

quando surgirem novos requisitos. Citando Gary Pollice (2001), “é preferível desenvolver

uma solução simples no presente e no futuro pagar para desenvolver se for necessária

uma solução mais complexa”.

• Feedback – as técnicas desta metodologia fomentam o rápido feedback do cliente

valorizando-o relativamente ao optimismo ou intuição por programadores. Quanto mais

cedo for recebido o feedback do cliente mais rápido e eficiente será o desenvolvimento do

sistema, pois as dúvidas acerca da forma de funcionamento do sistema serão rapidamente

resolvidas pelo cliente. A título de exemplo, o desenvolvimento de versões beta fornece

maior compreensão ao cliente e consequentemente maior feedback do que um conjunto de

diagramas desenhados em UML.

• Coragem – a coragem para fazer aquilo que se considera mais acertado mesmo que seja

contra as práticas convencionais. A coragem para experimentar. Isto aplica-se ao uso de

19 A diferença mais imediata das metodologias ágeis é a necessidade de menos documentação envolvida em cada tarefa. De uma forma geral as metodologias ágeis são mais orientadas à produção de código fonte, recolhendo os requisitos do sistema praticamente em qualquer altura do projecto. Para mais informação acerca de metodologias ágeis, consultar artigo de Martin Flower denominado de “The New Methodology” (FOWLER, 2003).


80

qualquer metodologia incluindo esta mesma quando se verificar que os seus princípios

não se adequam a uma situação ou projecto específico.

Além das suas quatro linhas orientadoras atrás explicadas a metodologia XP estabelece

também doze princípios:

• Jogo do planeamento – determinação das funcionalidades a implementar em cada versão

do produto com base na atribuição de diferentes prioridades aos requisitos do cliente.

Para a definição dos requisitos os clientes fazem descrições ou relatos sobre o

funcionamento que pretendem do sistema.

• Pequenas versões de software – disponibilização de pequenas versões funcionais do software

produzido, sendo todas elas incrementais. De versão para versão vão sendo acrescentadas

novas funcionalidades e por isso satisfeitos requisitos.

• Metáforas – descrições comuns de como certas áreas do software em desenvolvimento

devem funcionar. Adopção de termos e palavras-chave próprias.

• Desenho simplificado – manter o desenho e o código fonte tão simples quanto o

necessário para passar os testes.

• Testes – os testes são escritos antes da programação tanto pelos clientes (âmbito

funcional) como pelos programadores.

• Re-programação – a cada nova funcionalidade adicionada volta a programar-se o código

para que fique na forma mais simples, evitando a duplicação de blocos de código.

• Programação a par – a programação é feita por equipas de duas pessoas no mesmo

computador, escrevendo uma delas o código enquanto a outra o verifica.

• Responsabilidade global – toda a equipa é responsável por todo o código fonte produzido

no âmbito do projecto, garantindo-se assim que cada pessoa que integra a equipa de

desenvolvimento esteja apta a trabalhar sobre qualquer área da programação.

• Integração contínua – a cada alteração nas funcionalidades do sistema testa-se a integração

entre os diversos módulos já desenvolvidos, para evitar que novos desenvolvimentos

possam vir a causar erros em programação já feita.

• Semana de 40 horas – é contraproducente o trabalho por longos períodos de tempo

contínuos.

• Disponibilidade do cliente – o cliente deve estar permanentemente contactável e

disponível para esclarecer dúvidas.


81

• Normalização do código – todo o código fonte é desenvolvido segundo um padrão, desde

as nomenclaturas dos objectos até ao estilo semântico da programação, para permitir que

toda a equipa possa trabalhar sobre qualquer parte de código.

Concluindo, a metodologia XP é uma simples forma de desenvolvimento de software com base

nos princípios da comunicação, simplicidade, feedback e coragem, tendo sido estruturada para ser

seguida por pequenas equipas de desenvolvimento. Esta metodologia adequa-se a organizações que

pretendam desenvolver software rapidamente num ambiente de constante mudança dos requisitos.

A produção de documentação é uma característica frequentemente mal compreendida nesta

metodologia porque pode pensar-se que não lhe é dada a devida importância. Muito pelo contrário, a

XP dá especial atenção às áreas de desenho e planeamento do desenvolvimento do software, deixando

para segundo plano outro tipo de documentação que só produziria atrasos no normal prosseguimento

do projecto. Senão atente-se ao seguinte exemplo, muitas vezes a simples comunicação oral torna mais

rápidas as decisões do que se tivessem que ser seguidas todas as formalidades documentais. Citando

Wells, a documentação no âmbito do XP deve ser produzida quando se entender que é necessária

(MARCHESI et al., 2002).

A XP atribui muita importância aos testes sendo estes integrados em todo o processo de

desenvolvimento, ajudando assim à estabilidade do próprio projecto. Uma nova prática é a re-

programação do código a cada iteração ajudando assim à simplificação do mesmo. Uma outra

característica é o trabalho com base na iteração actual não se gastando tempo na antecipação de

necessidades, sendo apenas feitos desenvolvimentos nesse sentido quando elas surgirem.

4.5 MICROSOFT SOLUTIONS FRAMEWORK

A Microsoft Solutions Framework (MSF) foi criada em 1994 como sendo um conjunto das

melhores práticas resultantes da experiência de desenvolvimento de produtos pela Microsoft. Segundo

defende a Microsoft (2003) num seu artigo a criação de uma solução de negócio em tempo útil e

dentro do orçamento disponível só é possível se for seguido um processo de desenvolvimento que dê

garantias reais do seu sucesso. Assim, a MSF fornece um conjunto de práticas já testadas para o

planeamento, construção e implementação de soluções informáticas.

Quanto à classificação da MSF enquanto disciplina e não como metodologia, a Microsoft

(2003) sustenta a tese de que a MSF não é uma metodologia porque a sua filosofia é que não existe

uma estrutura ou processo óptimo que possa ser aplicado a todos os projectos. A MSF deve ser

entendida como um guia de boas práticas a ter em consideração, não tendo aprofundados detalhes,

linguagens, análises ou técnicas.


82

Os princípios em que assenta são oito:

• Fomentar um ambiente de comunicação aberto

• Trabalhar com base numa visão comum

• Dar poder (habilitar) os membros da equipa

• Estabelecimento de uma política clara de responsabilidades

• Foco na criação de valor para o cliente final

• Agilidade e previsão da mudança

• Investimento na qualidade

• Utilização do conhecimento derivado das experiências em projectos anteriores com meio

de aprendizagem para o futuro

O Processo decompõe-se em cinco fases: Visão (Envisioning), Especificação (Planning),

Desenvolvimento (Developing), Estabilização (Stabilizing) e Implementação (Deploying), tendo cada fase

definidos marcos a atingir e um conjunto de documentação a ser produzida.

Figura 14 – Modelo do processo MSF (adaptado de MICROSOFT, 2003)

A primeira fase – Visão – tem como objectivo a definição do âmbito do projecto. O marco

desta fase é a aprovação da visão por todas as partes envolvidas. No final desta fase resulta um

documento que delineia a visão e o âmbito do projecto. Estes dois conceitos não devem ser

confundidos porque enquanto a visão consiste na definição de uma ideia geral sobre o sistema, o

âmbito define quais são as partes do sistema que estão incluídas no projecto específico, isto é define as

fronteiras.


83

Nesta fase devem ser identificados os requisitos funcionais sem proceder ao seu detalhe, para

que no fim ambos cliente e fornecedor estejam de acordo quanto às funcionalidades a desenvolver no

âmbito do projecto actual, bem como do prazo para a sua conclusão.

A fase seguinte – Especificação – chamada de Planning no modelo original consiste no

planeamento ao pormenor de todo o projecto, sendo para isso realizadas tarefas de detalhe e

organização dos requisitos e especificação do sistema. Optámos por chamar esta fase de Especificação

porque é onde vai ser desenhado o sistema incluindo a especificação detalhada de cada funcionalidade

usando cenários e casos de utilização. A finalidade desta fase é (MICROSOFT, 2002):

• Indicação aos programadores sobre o que construir

• Providenciar uma base para estimar o trabalho a realizar

• Acordo com o cliente sobre o que desenvolver

• Pontos de sincronização com toda a equipa

No fim desta fase o cliente e a equipa de desenvolvimento estarão de acordo quanto ao que é

necessário ser desenvolvido, finalizando o período de estimativa de recursos e tempos a consumir.

A fase de Desenvolvimento caracteriza-se por ser aquela em que o sistema é desenvolvido na

sua quase totalidade, pois os desenvolvimentos finais são realizados durante a fase de estabilização do

sistema. Nesta fase é construído tanto o código fonte como a documentação. O marco desta fase é a

disponibilização de uma solução com todas as funcionalidades desenvolvidas e pronta a ser utilizada

pelo cliente.

A fase seguinte denominada de Estabilização consiste na realização de testes por parte dos

utilizadores. O sistema está operacional enquanto vão sendo corrigidas várias questões levantadas pelos

utilizadores durante a sua actividade normal. Esta fase dá lugar a várias versões de software e patches de

correcção, tendo em vista estabilizar a versão corrente do programa. Quando todas as questões tiverem

sido resolvidas, a solução desenvolvida estará pronta a ser posta em funcionamento no seu ambiente

real e distribuída ao resto da organização. Será uma versão de software praticamente testada e verificada,

cuja probabilidade de ocorrência de erros é muito baixa.

Após esta fase a responsabilidade pela resolução dos problemas passa da equipa de

desenvolvimento para a equipa de suporte, pois muitas das questões levantadas serão relativas a

configuração do sistema, e não a erros na componente semântica do desenvolvimento.

A última fase – Implementação – consiste na migração do sistema para o cliente final. É uma

fase em que se considera que o sistema está definitivamente terminado tendo sido alcançados todos os

objectivos definidos inicialmente. O marco desta fase culmina com a aprovação final por parte do

cliente de que o sistema está acabado e por isso o projecto encerrado. Quando o cliente encerrar o


84

projecto pode-se inferir que a solução desenvolvida proporcionou o valor de negócio esperado pelo

cliente (MICROSOFT, 2002).

De uma forma genérica, a conclusão que se pode tirar acerca desta disciplina é que toda ela é

baseada na experiência da Microsoft ao longo de vários anos. Verifica-se que este conjunto de boas

práticas agregam alguns princípios de outras metodologias num único modelo iterativo baseado em

etapas e que pode ser aplicado a qualquer tipo de projecto.

Este modelo foi concebido para responder às exigências de um ambiente em constantes

mutações, apresentando por isso iterações móveis com curtos ciclos de desenvolvimento e

disponibilizando versões do produto incrementais. É a filosofia seguida por produtos como o Microsoft

Windows, onde se observa a existência de versões beta antes do lançamento de uma nova versão e

posteriormente o lançamento de uma série de pacotes de correcções para estabilizar as versões de

software que vão saindo para o mercado.

4.6 RESUMO

Neste capítulo abordámos a importância de suportar um processo de desenvolvimento de

software numa metodologia, enunciaram-se os seus benefícios para o processo e descreveram-se os

principais aspectos de algumas das metodologias mais conhecidas.

Do estudo realizado concluiu-se que qualquer metodologia constitui uma sequência de etapas

e procedimentos recomendados para serem aplicados durante o processo de desenvolvimento de

sistemas de informação, sendo por isso aconselhável que seja adaptada ao tipo de organização,

necessidades dos clientes e complexidade do produto a desenvolver.

A metodologia escolhida para apoiar o desenvolvimento do sistema de informação a conceber

foi a da Rational, o RUP (Rational Unified Process), por ser aquela que se considerou mais completa e

adaptável ao desenvolvimento do sistema. Sendo esta uma metodologia iterativa e incremental e, por

isso, aplicável a projectos de desenvolvimento em tempo real, o que não se passa no caso deste

trabalho, adaptámo-la a este caso concreto cingindo-nos ao seguimento da sua componente estática,

nomeadamente através da produção dos artefactos julgados necessários, utilizando como linguagem de

modelação a UML (Unified Modelling Language).

Capítulo V

ARCHETYPUS SCORECARD

• Âmbito do sistema e estrutura do capítulo

• Plano de desenvolvimento do sistema

• Desenvolvimento dos principais artefactos

CAPÍTULO 5 – ARCHETYPUS SCORECARD

87

Após o estudo das principais metodologias de desenvolvimento de software no capítulo anterior, optou-se por modelar o sistema Archetypus segundo a metodologia da Rational, o Rational Unified Process (RUP) e utilizando a linguagem de modelação UML20 (Unified Modeling Language).

Este capítulo está organizado em torno dos artefactos a produzir, contendo alguns deles na sua totalidade e outros parcialmente conforme a sua importância e necessidade. Começam-se por apresentar artefactos mais gerais, isto é, ligados à gestão do projecto como por exemplo a justificação da necessidade do sistema, lista de riscos e glossário. De seguida, caminha-se gradualmente para a especificação mais detalhada do sistema, nomeadamente a modelação dos requisitos do sistema através dos casos de uso e diagramas de actividade, a análise e desenho das entidades (classes), desenho dos formulários (interface), desenho dos componentes (código fonte, bibliotecas, tabelas) e, por fim, o plano de distribuição (deployment) do sistema.

5.1 ÂMBITO

De entre as várias metodologias estudadas optou-se pela da Rational, o Rational Unified Process

(RUP), pelas vantagens que apresenta relativamente à flexibilidade de adaptação a vários tipos de

projectos e nível de documentação que providencia. Sendo o âmbito desta dissertação puramente

académico e não estando nós perante o desenvolvimento real de um sistema de informação, constatou-

se não ser possível seguir a componente dinâmica da metodologia, porque esta obriga à actualização

dos artefactos ao longo do tempo com as alterações que surgem normalmente durante o decorrer de

um projecto de desenvolvimento de software.

Quanto à lista dos requisitos necessários ao sistema esta já estava definida à partida, o que

implicou a eliminação de algumas das etapas do processo de levantamento e controlo das alterações

aos requisitos. O mesmo implicou o não desenvolvimento de todos os artefactos considerados

necessários pelo RUP, enfim, adaptou-se o processo à realidade e tipo de projecto, tal como é

defendido por Evans (2001) e Fowler (2003) o RUP “está aqui para nos servir” e por isso devemos

adaptá-lo conforme as nossas necessidades.

Assim, decidimos cingirmo-nos à componente estática do RUP, desenvolvendo o sistema de

acordo com as suas várias disciplinas (workflows), designadamente através da produção dos artefactos

20 A notação utilizada para a modelação é a relativa à versão 1.5 da linguagem UML, podendo ser consultada no anexo K


88

considerados necessários. Num futuro próximo aquando do desenvolvimento real do sistema, uma

parte substancial do trabalho já estará realizada.

5.2 PLANO DE DESENVOLVIMENTO DO SISTEMA

A componente estática do RUP envolve a descrição de quem (interveniente) faz o quê

(artefacto), como (actividades) e quando (disciplinas ou workflows). Para cada disciplina serão

identificados e elaborados os artefactos considerados necessários no âmbito desta dissertação, pois

como já se referiu anteriormente, uma parte do processo nomeadamente a relacionada com o

levantamento de requisitos, não é necessária seguir. Antes de mais, apresentamos os artefactos

considerados principais no âmbito desta metodologia:

Figura 15 – Principais artefactos produzidos no âmbito do RUP (SILVA e VIDEIRA, 2001)

O âmbito da disciplina de gestão das alterações estende-se por todas as fases do projecto,

sendo o seu objectivo o registo e controlo das mudanças que ocorrem durante o seu desenvolvimento,

como por exemplo as mudanças aos requisitos, interface, relatórios, etc. Neste caso, os requisitos já

foram definidos anteriormente e por isso este projecto é estanque a alterações, pois não há quaisquer

entidades a impor mudanças durante o seu desenvolvimento, não fazendo sentido aplicá-la uma vez

que depende exclusivamente do modo como cada projecto decorre.

Quanto à disciplina de ambiente, cujo objectivo é preparar a equipa de desenvolvimento para

o projecto, são definidas as ferramentas a usar e a metodologia a seguir, estando estas dependentes da


89

organização e da tecnologia actual no momento de desenvolvimento do projecto. De acordo com

Pollice et al. (2004) o artefacto desta disciplina – Development Case – não necessita ser muito detalhado

nem é necessário gastar-se muito tempo nas situações em que a equipa de desenvolvimento seja

pequena ou esteja integrada num ambiente familiar. Pode mesmo ser um “artefacto oral”. Contudo,

sendo este sistema passível de ser executável por uma pequena equipa de desenvolvimento optámos

por elaborar um Development Case, constante no anexo E, onde estão enunciados os artefactos

produzidos no âmbito de cada disciplina (workflow). Esses artefactos são os seguintes:

• Documento da visão do sistema – documento onde se justifica a necessidade do sistema,

identificam as entidades que com ele interagem e estabelecem os requisitos do sistema.

• Glossário – documento que contém definições para termos utilizados no projecto.

• Lista de riscos – documento que enuncia os riscos do projecto.

• Modelo de casos de uso – documento que captura e descreve os requisitos do sistema.

• Modelo de análise e desenho – documento contendo a definição das classes do sistema.

• Esquema de tabelas – documento contendo a definição das tabelas que suportam o

sistema.

• Modelo de implementação – documento que especifica a implementação das classes em

termos de componentes tais como ficheiros de código fonte, executáveis, bibliotecas, etc.

• Plano de distribuição – documento contendo a especificação dos componentes físicos do

sistema e respectiva interacção.

• Protótipo de interface – documento que contém o desenho dos formulários do sistema.

Pretende-se que o sistema funcione apoiado num navegador (browser) comum de internet tal

como o Microsoft Internet Explorer, tanto na Intranet como na Extranet da organização. Esta premissa

constituiu a base para a decisão de desenvolver o sistema na linguagem HTML (HiperText Markup

Language) para a concepção das páginas, ASP (Active Server Pages) para a interacção entre a aplicação

informática e a base de dados e, por fim, a decisão de estabelecer o SQL-SERVER como o sistema de

gestão de base de dados relacional (SGBDR) para suporte dos dados.

A razão para ter sido estabelecida uma tecnologia web como a base de desenvolvimento do

sistema prende-se com a sua imposição nos requisitos. Ressalvamos, apesar de tudo, que as linguagens

de programação e o SGBDR atrás enunciados são apenas um exemplo, podendo ser escolhidos

quaisquer outros conforme as necessidades e capacidades de cada organização.

O tempo de desenvolvimento de um sistema deste tipo poderia estender-se por 14 a 18 meses,

dependendo da constituição da equipa de desenvolvimento, todavia neste caso, tendo já sido feita uma

parte considerável do trabalho de análise o tempo de desenvolvimento reduzir-se-ia para 5 meses,


90

partindo do principio que se tinha uma equipa de dois programadores, sendo um deles também

analista de sistemas.

5.3 ARCHETYPUS – O NOME

A origem do nome escolhido para este sistema de informação – Archetypus – provém do

latim, significando “original” ou “servir do modelo para....”, sendo esta última definição a que serviu de

base à sua escolha. Achamos a definição “servir de modelo para...” aplicar-se correctamente a este

sistema uma vez que foi desenvolvido de acordo com os princípios definidos pelo instituto Balanced

Scorecard Collaborative.

O símbolo escolhido consiste numa bússola posicionada sobre um tabuleiro de xadrez,

indicando a bússola a ideia de “orientação” e o tabuleiro de xadrez a de “estratégia”. Assim,

pretendemos passar a ideia de “orientação das organizações em torno da sua estratégia”, sendo este o

slogan escolhido para apresentar em todo o interface do Archetypus.

Figura 16 – Símbolo Archetypus

5.4 VISÃO GERAL DO SISTEMA

A visão do sistema é composta pelo artefacto “Visão” apresentando-se de seguida esse

artefacto na sua totalidade. Este artefacto define a visão do produto por parte dos stakeholders (os entes

que interagem directa ou indirectamente com o sistema) especificada em termos de funcionalidades

necessárias. O seu objectivo é recolher os requisitos de alto nível do sistema. Num projecto em tempo

real este artefacto vai sendo revisto e actualizado, sendo que, neste caso apenas se registou uma

iteração – a data da elaboração inicial do documento.


91

HISTÓRICO DE REVISÕES

Data Versão Descrição Autor

2004/11/23 1.0 Elaboração inicial Gil Vieira

ÂMBITO

O objectivo deste documento é descrever as motivações que serviram de base à concepção do

Archetypus Scorecard. São também referidas as necessidades que se pretendem satisfazer, de acordo

com um estudo realizado sobre as funcionalidades mais relevantes e necessárias do ponto de vista de

organizações que já suportam o seu BSC num sistema de informação próprio.

NECESSIDADES MANIFESTADAS

Neste item justifica-se a adopção deste sistema formulando-se a necessidade que se pretende satisfazer.

DEFINIÇÃO DO PROBLEMA O problema de existirem necessidades ainda não satisfeitas aos utilizadores de sistemas

de suporte ao Balanced Scorecard Afecta as organizações. O impacto é a diminuição do rendimento obtido com a utilização do sistema e

ineficiência na operacionalização da sua estratégia. Uma boa solução permitirá a mais rápida implementação do Balanced Scorecard.

POSICIONAMENTO DO PRODUTO

Para as organizações Que pretendem implementar uma estratégia baseada nos princípios do Balanced

Scorecard o Archetypus Scorecard é uma solução informática Que permite satisfazer as necessidades mais relevantes dos utilizadores Ao contrário das comuns soluções informáticas genéricas Este produto para além de ser adaptável, contém de base as funcionalidades

consideradas necessárias (decorrente dum estudo realizado), apresentando-se por isso uma solução mais económica.

ACTORES

Os actores representam papéis desempenhados por entidades que interagem com o sistema,

desde os seus utilizadores, passando pelos administradores do sistema até outras aplicações

informáticas que desencadeiam acções sobre este sistema.


92

ACTORES DO SISTEMA

Nome Descrição Responsabilidades

Administrador (gestor topo)

Maior nível hierárquico da organização (generalização do actor Utilizador)

Aprovação do projecto. Definição do modelo scorecard da organização

Director Direcção de cada departamento ou unidade de negócio da organização (generalização do actor Utilizador)

Gestão e actualização dos dados dos indicadores.

Colaborador Pessoal do nível operacional. O sistema é alimentado com dados referentes ao desenvolvimento das suas actividades normais de trabalho. (generalização do actor Utilizador)

Providenciar os dados que alimentam o sistema. Utilizar o sistema (ex: comentários, consultas, etc.)

Utilizador Actor genérico que representa qualquer pessoa que possa interagir com o sistema

Administrador do sistema

Pessoa responsável por administrar e fazer manutenção ao sistema. Esta pessoa não é obrigatória na organização.

Administração do sistema.

Sistemas externos Outras aplicações que possam interagir com o sistema

Servir como fonte de dados para alimentar o sistema. Execução de tarefas rotineiras sobre o sistema (cópias de segurança)

Tempo Transacção que executa procedimentos em determinados intervalos de tempo.

Executar procedimentos de forma regular.

Tabela 3 – Actores do sistema

VISÃO GERAL DO PRODUTO

Esta secção faz uma abordagem simples e genérica à arquitectura do sistema de informação

apresentando a sua interacção com os diversos intervenientes que o compõe.

O Sistema consiste num servidor de páginas web semelhante aos servidores convencionais que

alojam e disponibilizam sítios na internet. Este disponibiliza páginas que poderão ser acedidas através de

um navegador (browser) normal a partir da rede interna ou externa da organização, conforme ilustrado

nas figuras seguintes.

Figura 17 – Arquitectura do sistema


93

Intranet

Firewall

Router

ServidorWindows 2003

VPN

LANLAN

BDSQL SERVER

HTML/ASPVBSCRIPT

UtilizadorInternet Explorer

Figura 18 – Modelos de interacção dos utilizadores com o sistema

O sistema de gestão de base de dados que suporta o Archetypus é o SQLSERVER, sendo o

desenvolvimento das páginas realizado em HTML e ASP. Como se referiu anteriormente, para além do

acesso interno através da rede local (LAN-Local Area Network) também é possível aceder a partir do

exterior da organização através duma rede privada virtual (VPN) sobre a Internet. Paralelamente à

inclusão de uma firewall no modelo, geralmente o fornecedor dos serviços da VPN assegura túneis

seguros até aos seus servidores e encriptação de dados ao longo de toda a VPN.

Para aceder ao sistema Archetypus os utilizadores necessitam apenas de computadores

pessoais normais que contenham um navegador (browser) comum, não estando por isso limitados a

estações de trabalho com software específico.

FUNCIONALIDADES EXIGIDAS

As funcionalidades exigidas para este sistema foram previamente estudadas e validadas através

de um inquérito feito a organizações com experiência neste tipo de sistemas, estando agrupadas em

quatro categorias: modelo principal, comunicação, negócio e flexibilidade.

MODELO PRINCIPAL

● Definição da missão Descrever a missão definida para a organização. ● Definição da visão Descrever a visão definida para a organização. ● Definição da estratégia Descrever a estratégia definida para a organização. ● Definição dos objectivos estratégicos Indicar os objectivos traçados. ● Indicação de objectivos, indicadores, metas e Atribuir a cada perspectiva os objectivos, indicadores,


94

iniciativas para cada um das perspectivas padrão

metas e iniciativas definidas.


















COMUNICAÇÃO ● Introdução de comentários aos objectivos, indicadores, metas e iniciativas por parte dos utilizadores do sistema

Possibilidade dos empregados introduzirem comentários ou sugestões sobre objectivos, indicadores, metas e iniciativas.





● Possibilidade de ligar documentos, mensagens de correio, aplicações externas, etc., a indicadores e objectivos

Ligada aos objectivos e/ou indicadores deverá haver informação que permita avaliar a evolução do indicador no tempo e um histórico das medidas tomadas.



● Uso de informação qualitativa para descrever a evolução de indicadores (bom, mau, aumentou, baixou, positivo, etc)

Uso de informação qualitativa que descreva o nível de evolução dos indicadores.



NEGÓCIO ● Relatório do desempenho actual e histórico de cada indicador


● Monitorização (gráfica e descritiva) do índice de satisfação de cada objectivo.




● Capacidade para desdobrar a informação em Possibilidade do utilizador ir desdobrando a informação


95

diversos níveis de detalhe em diversos níveis de detalhe até encontrar a origem dos factos que observa.

● Definição de empregados responsáveis por iniciativas e indicadores






● Acompanhamento e medição do desempenho individual (por empregado) e respectiva contribuição para a satisfação dos objectivos estratégicos


FLEXIBILIDADE ● Importação de dados provenientes de sistemas externos (folhas de cálculo, bases de dados)



Exportação de informação em diversos formatos.





● Administração centralizada do sistema Administração centralizada do sistema. ● Definição de políticas de segurança (utilizadores/permissões/acessos)




Tabela 4 – Lista de funcionalidades exigidas

OUTRAS CARACTERÍSTICAS REQUERIDAS

Estas características referem-se a aspectos gerais da aplicação relacionados com qualidade,

rapidez de funcionamento, plataforma de desenvolvimento e sistema de gestão de base de dados onde

assenta. São aspectos que influenciam positivamente a satisfação global do utilizador acerca do sistema

de informação porque embora não sejam impostos à partida, o utilizador está à espera que eles estejam

presentes no sistema. A título de exemplo, a usabilidade é uma característica que apesar de não ser

exigida no momento da escolha do sistema, é apreciada e influencia significativamente a satisfação do

utilizador final.

CARACTERÍSTICAS TÉCNICAS ● Funcionamento em várias plataformas ou sistemas operativos (Windows, UNIX)


● Desenvolvimento do sistema em tecnologia WEB (HTML, ASP, PHP, .NET, J2EE)



96

● Sistema assente num Sistema de Gestão de Base de Dados Relacional (SQL Server, Oracle, Informix)

Sistema assente numa base de dados relacional.

● Fácil de usar e intuitivo Facilidade de utilização do sistema, cumprindo as regras de usabilidade.

● Sistema baseado em ambiente de janelas Sistema baseado em ambiente de janelas e multi-tarefa conforme o princípio do MS Windows.

● Sistema cliente/servidor Sistema cliente/servidor.

5.5 GLOSSÁRIO O passo seguinte é a constituição de um glossário de termos utilizados durante o projecto,

sendo este documento actualizado durante todo o ciclo de vida do projecto. Também este artefacto é

apresentado na sua totalidade.

HISTÓRICO DE REVISÕES Data Versão Descrição Autor

2005/01/13 1.0 Elaboração inicial Gil Vieira 2005/02/25 1.1 Actualização Gil Vieira

ÂMBITO

Este documento contém termos e definições utilizados no âmbito da concepção do sistema

Archetypus Scorecard.

TERMOS E DEFINIÇÕES

ACTOR

Entidade que interage com o sistema, podendo representar pessoas, processos (tempo) ou

outros sistemas de informação.

ARTEFACTO

Peça de informação que é usada ou produzida durante um processo de desenvolvimento de

software.

BALANCED SCORECARD

Instrumento de gestão estratégica cujo principio consiste na operacionalização e alinhamento

da estratégia ao longo de uma organização, recorrendo para isso há sua divisão em quatro

perspectivas de análise genéricas.


97

Para mais informação consultar: http://www.bscol.com

INDICADOR

Instrumento usado para medir o grau de concretização de um objectivo.

INICIATIVA

Actividades, programas, projectos ou acções específicas desenvolvidas com vista ao alcance de

metas.

META

Componente mensurável do objectivo, geralmente um valor que se pretende atingir dentro de

um prazo específico.

OBJECTIVO

Declaração de um resultado que se pretende alcançar, devendo ter as seguintes características:

mensurável, claro, alcançável, realista e temporizado.

PERSPECTIVA

Componente do Balanced Scorecard constituindo uma visão diferente da organização segundo

determinada óptica.

ACTOR: COLABORADOR

Entidade que representa os recursos humanos do nível operacional da organização.

ACTOR: ADMINISTRADOR

Entidade que representa as pessoas que ocupam o maior nível hierárquico da organização.

ACTOR: DIRECTOR

Entidade que representa o nível das chefias intermédias da organização ao nível de

departamentos ou unidades de negócio.

ACTOR: UTILIZADOR

Entidade genérica que representa qualquer pessoa que interage com o sistema.


98

ACTOR: ADMINISTRADOR DO SISTEMA

Entidade que representa a pessoa responsável por administrar e fazer manutenção do sistema

de informação.

ACTOR: SISTEMAS EXTERNOS

Entidade que representa outros sistemas de informação que interagem com o sistema actual,

como por exemplo para fornecimento de dados.

ACTOR: TEMPO

Entidade que representa tarefas agendadas no sistema para ocorrerem automaticamente em

períodos de tempo definidos.

5.6 LISTA DE RISCOS A lista de riscos é um documento onde são enumerados e classificados em termos de gravidade

os riscos que possam ocorrer durante o ciclo de vida do projecto. Esta lista serve como base à

organização das tarefas do projecto, sendo apresentada de seguida.

HISTÓRICO DE REVISÕES

Data Versão Descrição Autor

2004/10/16 1.0 Elaboração inicial Gil Vieira

ÂMBITO

Neste documento são avaliados os riscos durante o processo de desenvolvimento do sistema.

RISCOS GERAIS DO PROJECTO

Em termos gerais o sistema não corre o risco de não-aceitação no mercado português porque

apesar de haverem muitas soluções disponíveis em Portugal, não existe ainda, qualquer solução

informática portuguesa certificada pelo instituto Balanced Scorecard Collaborative. Uma vez que esteja

certificada, esta solução posicionar-se-á no mesmo pé de igualdade com as outras soluções

concorrentes.


99

No que respeita às funcionalidades do Archetypus consideramos serem aceites e valorizadas

por parte dos utilizadores finais, porque estas foram determinadas com base num estudo exaustivo

efectuado sobre a opinião de organizações com experiência demonstrada na utilização deste tipo de SI.

RISCOS ESPECÍFICOS

RISCO P. CONTINGÊNCIA GRAU

Má interpretação dos artefactos produzidos no âmbito da metodologia RUP

Providenciar acções de formação periódicas.

Acompanhamento periódico da equipa de desenvolvimento

3

Compreensão da filosofia do BSC por parte da equipa que coordena o projecto de desenvolvimento

Providenciar acções de formação 2

Quantidade insuficiente de recursos para o tempo disponível para desenvolver o sistema

Medidas associadas a recompensas financeiras por trabalho extra e cumprimento de metas fixadas

4

Pessoas envolvidas não acreditarem no sucesso do projecto

Envolvimento dos colaboradores no projecto, indicando as metas pretendidas e os resultados alcançados.

5

Concorrência no mercado Implementação inicial em pequenas organizações oferecendo alguns serviços em troca de know-how para melhorias do sistema

6

Constante alteração dos requisitos Maior ênfase na fase de levantamento de requisitos 1

(Gravidade dos riscos: 1-Baixa 6-Elevada)

Tabela 5 – Lista de riscos do sistema


100

5.7 MODELO DE CASOS DE USO

O modelo de casos de uso é um artefacto resultante da disciplina (workflow) de requisitos cujo

objectivo é a documentação dos requisitos do sistema. As actividades desenvolvidas nesta disciplina

têm como finalidade a definição e especificação das funcionalidades pretendidas pelos utilizadores do

sistema.

No caso do Archetypus a definição dos requisitos foi feita numa base académica, tendo sido

seguidas três fases: numa primeira analisaram-se publicações do instituto Balanced Scorecard Colaborative

(BSCol) onde eram estabelecidas as funcionalidades mínimas a suportar por qualquer sistema de

suporte ao BSC; na segunda fase foi feito um levantamento das funcionalidades existentes nas

aplicações certificadas pelo mesmo instituto (BSCol); por fim, na terceira fase inquiriram-se

organizações com experiência neste tipo de sistemas de informação. Para não nos tornarmos

repetitivos dispensamo-nos de apresentar novamente a lista de requisitos para o sistema, podendo esta

ser consultada anteriormente no documento da “Visão geral do sistema” (secção 5.4) ou no anexo F,

contendo também este último a correspondência entre os requisitos e respectiva realização através dos

casos de uso.

No que respeita à priorização dos casos de uso partimos do princípio de que os relativos às

componentes padrão do BSC são os mais importantes, tendo definido as seguintes três categorias para

a classificação da prioridade:

• ALTA – funcionalidades consideradas imprescindíveis à construção de um scorecard

• MÉDIA – funcionalidades que proporcionam valor acrescentado significativo ao modelo

scorecard, fáceis de implementar e baixo valor de investimento adicional necessário.

• BAIXA – funcionalidades que constituem relativo benefício para o sistema, mas

contrariamente à categoria anterior são difíceis de implementar e o valor de investimento

necessário é elevado.

Os casos de uso foram divididos em quatro grupos: modelo principal, comunicação, negócio e

flexibilidade, sendo apresentados por esta ordem e somente aqueles que têm prioridade alta. Os

restantes podem ser consultados no anexo G.


101

5.7.1 MODELO PRINCIPAL

Figura 19 – Diagrama de casos de uso "Modelo Principal"

F6. Validação de util izador

(f rom Flexibilidade)

Uti lizador

(f rom Actores)

M6. Indicação das fórmulas de cálculo dos indicadores

M7. Mapa de relações de causa-efeito

M9. Atribuição de objectivos a uti lizadores específicos ou grupos

M8. Interl igação de objectivos em diversas camadas

Director

(f rom Actores)

M1. Definição da missão M2. Definição da visãoM3. Definição da estratégia

M4. Definição dos objectivos estratégicos

M5. Indicação de objectivos, indicadores, metas e iniciativas por perspectiva

Administrador

(f rom Actores)


102

Caso de Uso: M1. Definição da missão Finalidade: Registar a “missão” da organização Actores: Administrador Prioridade: Alta Pré-condições: N/A Pós-condições: N/A

Fluxo normal Acções dos actores Suporte TIC

1 Selecção da opção “Parâmetros” 2 Selecção da opção “Valores” 3 Abrir formulário “Valores da organização” 4 Preenchimento na caixa de texto para a Missão 5 Pressiona o botão de “Gravar” 6 Grava os dados na base de dados. 7 Actualiza o formulário

Fluxo alternativo Acções dos actores Suporte TIC

5.1 O processo pode ser cancelado, bastando para isso o actor pressionar o botão de cancelar.

5.2 Actualização do formulário, sem gravar os dados na base de dados

Interfaces Formulário “Valores da organização”

Seleccionar opção "Valores"

Escreve a missão

Pressiona botão de cancelar

Pressiona botão de gravar

Cancela a operação

Confirma a operação

Seleccionar opção "Parâmetros"

Abrir Formulário "Valores da organização"

Grava dados na base de dados

Actualização do formulário

SistemaAdministrador


103

Caso de Uso: M2. Definição da visão Finalidade: Registar a “visão” da organização Actores: Administrador Prioridade: Alta Pré-condições: N/A Pós-condições: N/A


1 Selecção da opção “Parâmetros” 2 Selecção da opção “Valores” 3 Abrir formulário “Valores da organização” 4 Preenchimento na caixa de texto para a Visão 5 Pressiona o botão de “Gravar” 6 Grava os dados na base de dados. 7 Actualiza o formulário






Escreve a visão











104

Caso de Uso: M3. Definição da estratégia Finalidade: Registar a “estratégia” da organização Actores: Administrador Prioridade: Alta Pré-condições: N/A Pós-condições: N/A


1 Selecção da opção “Parâmetros” 2 Selecção da opção “Valores” 3 Abrir formulário “Valores da organização” 4 Preenchimento na caixa de texto para a Estratégia 5 Pressiona o botão de “Gravar” 6 Grava os dados na base de dados. 7 Actualiza o formulário














Escreve a estratégia



105

Caso de Uso: M4. Definição dos objectivos estratégicos Actores: Administrador Finalidade: Registar os objectivos estratégicos da organização Prioridade: Alta Pré-condições: N/A Pós-condições: N/A


1 Selecção da opção “Parâmetros” 2 Selecção da opção “Valores” 3 Abrir formulário “Valores da organização” 4 Preenchimento na caixa de texto para os

objectivos estratégicos.

5 Pressiona o botão de “Gravar” 6 Grava os dados na base de dados. 7 Actualiza o formulário











Escreve os objectivos






106

Caso de Uso: M5. Indicação de objectivos, indicadores, metas e iniciativas por

perspectiva Finalidade: Atribuir objectivos, indicadores, metas e iniciativas a cada perspectiva Actores: Administrador, Director Prioridade: Alta Pré-condições: Haver um modelo de scorecard criado. Pós-condições: N/A


1 Selecção da opção “Parâmetros” 2 Selecção da opção “Scorecard” 3 Abrir formulário “Modelo Scorecard” 4 Seleccionar perspectiva 5 Selecção da opção “Criar objectivo” 6 Abrir formulário “Objectivo” 7 Preencher dados 8 Selecção da opção “Criar indicador” 9 Abrir formulário “Indicador” 10 Preencher dados 11 Selecção da opção “Criar iniciativa” 12 Abrir formulário “Iniciativa” 13 Preencher dados 14 Pressiona o botão de “Gravar” 15 Grava os dados na base de dados


4.1 Criação de nova perspectiva. Pressionar botão “Criar perspectiva”

4.2 Abrir formulário “Perspectiva”

4.3 Eliminação de perspectiva. Seleccionar na árvore e pressionar botão “Remover perspectiva”

4.4 Esta acção só poderá ser realizada se não existirem objectivos, indicadores, metas ou iniciativas ligados à perspectiva. Surge pop-up a pedir a confirmação.

5.1 Para criar outros objectivos repetir os passos 4 e 5

5.2 Actualização no modelo para as perspectivas respectivas

5.3 Eliminação de objectivo. Seleccionar no modelo e pressionar botão “Remover objectivo”

5.4 Surge pop-up a pedir a confirmação

8.1 Eliminação de indicador. Seleccionar no modelo e pressionar botão “Remover indicador”

8.2 Surge pop-up a pedir a confirmação

11.1 Eliminação de iniciativa. Seleccionar no modelo e pressionar botão “Remover iniciativa”

11.2

Surge pop-up a pedir a confirmação

14.1 Pressionar o botão “Cancelar” para cancelar o processo

14.2

Actualização do formulário, sem gravar os dados na base de dados

Interfaces Formulário “Modelo Scorecard” Formulário “Objectivo” Formulário “Indicador” Formulário “Iniciativa”


107


108

Caso de Uso: M7. Mapa de relações causa-efeito Finalidade: Criar um modelo visual que ilustre as relações causais entre os objectivos dentro

da respectiva perspectiva Actores: Director Prioridade: Alta Pré-condições: Haver objectivos criados e ligados a perspectivas Pós-condições: N/A


1 Selecção da opção “Parâmetros” 2 Selecção da opção “Mapas” 3 Selecção da opção “Mapa estratégico” 4 Abrir formulário “Mapa estratégico” 5 Construção do modelo, arrastando os objectivos

da caixa respectiva para o mapa principal. Estabelecimento de ligações através de ferramentas de desenho (seta).

6 Pressiona o botão de “Gravar” 7 Guarda o posicionamento e relações estabelecidas entre os objectivos.

8 Actualiza o formulário Fluxo alternativo

Acções dos actores Suporte TIC 6.1 O processo pode ser cancelado, bastando para

isso o actor pressionar o botão de cancelar. 6.2 Actualização do formulário, sem gravar os

dados na base de dados Interfaces

Formulário “Mapa estratégico”


Seleccionar opção "Mapas"

Construção do modelo.

Movimentação dos objectivos desde uma caixa para o mapa principal, posicionando-os na respectiva perspectiva e estabelecendo as ligações.

Pressionar botão "Gravar"

Pressionar botão "Cancelar"



Seleccionar opção "Mapa estratégico"

Abrir formulário "Mapa estratégico"

Guarda os dados na base de dados

Actualiza formulário

SistemaDirector


109

5.7.2 COMUNICAÇÃO



C2. Sistema de alertasTempo

(f rom Actores)

C5. Criação de relatórios


(f rom Actores)

C1. Introdução de comentários aos objectivos, indicadores, metas e iniciativasColaborador

(f rom Actores)

C3. Ligação de informação extra a objectivos e indicadores

Director

(f rom Actores)

C4. Emissão de relatórios

Administrador

(f rom Actores)

Uti lizador

(f rom Actores)

C6. Uso de informação gráfica e qual itativa

Figura 20 – Diagrama de casos de uso "Comunicação"


110

Caso de Uso: C1. Introdução de comentários aos objectivos, indicadores, metas e

iniciativas Finalidade: Introduzir comentários às principais componentes do scorecard Actores: Colaborador Prioridade: Alta Pré-condições: Estar construído um modelo de scorecard, incluindo as suas componentes. Pós-condições: N/A


1 Selecção da opção “Scorecard” 2 Selecção da opção “Pessoal” 3 Abrir formulário “Scorecard Pessoal” 4 Seleccionar componente no modelo (perspectiva,

objectivo, indicador)

5 Pressionar botão de “Notas” 6 Abrir formulário “Notas” 7 Descrever o comentário 8 Pressionar o botão de “Gravar” 9 Guardar os dados na base de dados 10 Fecha formulário “Notas” 11 Cria ícone no modelo


1 Selecção da opção “Fórum” 2 Abrir formulário “Fórum” 3 Seleccionar utilizador 4 Pressionar botão “Criar mensagem” 5 Pressiona o botão de “Gravar” 6 Guarda dos dados na base de dados

Interfaces Formulário “Scorecard Pessoal” Formulário “Notas” Formulário “Forum”

Seleccionar opção "Forum"

Seleccionar utilizador

Pressionar botão "Criar mensagem"





Abrir Formulário "Forum"


SistemaColaborador


111

Pressionar botão "Notas"



Seleccionar opção "Pessoal"

Descrever o comentário


Seleccionar opção "Scorecard"

Seleccionar componente no modelo


Abrir Formulário "Scorecard Pessoal"

Abrir Formulário "Notas"


Fecha formulário "Notas"

Cria ícone no modelo

SistemaColaborador


112

Caso de Uso: C2. Sistema de alerta sobre indicadores, comentários e mensagens Finalidade: Alertar sobre o comportamento de indicadores, recebimento de mensagens e

introdução de comentários Actores: Tempo Prioridade: Alta Pré-condições: Haver metas definidas e dados de indicadores. Pós-condições: Emitir alerta


1 Activa processo 2 Repetir para cada indicador: “Comparar valores actuais com as metas”

3 Verifica mensagens novas 5 Se necessário produz alerta 4 Verifica comentários introduzidos

Interfaces

Activação do processo periodicamente

Activa processo

Produzir alerta

Comparação dos valores actuais com as metas

Para cada indicador, repetir a actividade

Necessário alerta?

Verifica mensagens novas

Não

Mensagens novas?

Verifica comentários introduzidos

Comentários novos?

Sim

Sim

Sim

SistemaTempo


113

Caso de Uso: C4. Emissão de relatórios Finalidade: Emitir relatórios a partir da aplicação informática Actores: Administrador; Director Prioridade: Alta Pré-condições: N/A Pós-condições: Emissão relatório para o dispositivo seleccionado.


1 Seleccionar opção “Relatórios” 2 Escolher relatório pretendido 3 Escolher dispositivo de saída (ecrã, impressora) 4 Emite relatório 5 Envia relatório para o dispositivo de saída

seleccionado Interfaces

Seleccionar opção "Relatórios"

Escolher relatório pretendido

Escolhe dispositivo de saída (ecrã, impressora)

Emite relatório

Envia relatório para o dispositivo escolhido

SistemaAdministrador/Director


114

5.7.3 NEGÓCIO

Figura 21 – Diagrama de casos de uso "Negócio"

Uti lizador

(f rom Actores)



Director

(f rom Actores)

N1. Relatório do desempenho actual e histórico por indicador

N3. Existência de vários tipos de indicadores predefinidos por perspectiva

N4. Mecanismos de desdobramento da informação

N8. Medição do desempenho individual

N6. Sistema de recompensas para metas e iniciativas

N7. Ferramentas OLAP

N5. Definição de responsabilidades por indicadores e iniciativas

N2. Moni torização do índice de satisfação dos objectivos

Administrador

(f rom Actores)

N9. Actualização de informação

Tempo

(f rom Actores)


115

Caso de Uso: N9. Actualização de informação Finalidade: Actualizar periodicamente a informação sobre os objectivos e indicadores Actores: Tempo; Prioridade: Alta Pré-condições: N/A Pós-condições: N/A


1 Activação do processo de actualização. 2 Realização de consultas sobre a base de dados 3 Actualização de valores objectivos e indicadores

Interfaces

Activa processo

Activação periódica( 2 min. )

Consultas à base de dados

Actualizar valores de objectivos, indicadores.

SistemaTempo


116

5.7.4 FLEXIBILIDADE

Figura 22 – Diagrama de casos de uso "Flexibilidade"

Uti lizador

(f rom Actores)


Administrador

(f rom Actores)

F2. Exportação de informação para diversos formatos

Director

(f rom Actores)

Sitemas externos

(f rom Actores)

F4 Definição de políticas de segurança

F5. Al teração da terminologia uti lizada na apl icação

F3. Arquivo de informação para histórico

F1. Importação de dados de sistemas externos


(f rom Actores)


117

Caso de Uso: F4. Definição de políticas de segurança Finalidade: Criação de perfis de utilizador com permissões específicas Actores: Administrador do sistema Prioridade: Alta Pré-condições: N/A Pós-condições: N/A


1 Seleccionar opção “Administração” 2 Seleccionar opção “Permissões” 3 Abrir formulário “Permissões” 4 Definir permissões 5 Definir o nome do perfil 6 Pressionar botão de gravar 7 Pede palavra-passe que permite continuar com

a operação de gravação 8 Insere palavra-passe 9 Verifica palavra-passe 10 Grava permissões



6.2 Não grava as permissões definidas

9.1 Caso palavra-passe seja incorrecta, volta a pedir palavra-passe (passo 7)

Interfaces Formulário “Permissões”

Seleccionar opção "Administração"

Seleccionar opção "Permissões"

Definir o nome do perfil

Definir permissões

Pressionar botão de gravar

Pressionar botão de cancelar

Insere palavra passe

Grava os dadosCancela a operação

Abrir formulário "Permissões"

Pede palavra passe que permite gravar

Verifica palavra passe

Grava permissões

Palavra correcta

Palavra incorrecta

SistemaAdministrador do sistema


118

Caso de Uso: F6. Validação de utilizador Finalidade: Validar utilizadores no acesso ao sistema Actores: Utilizador; Sistema Prioridade: Média Pré-condições: N/A Pós-condições: N/A


1 Inicia a aplicação informática 2 Abrir formulário “Acesso” 3 Insere dados: utilizador e palavra-passe 4 Verifica dados introduzidos 5 Consulta as permissões definidas 6 Retorna sucesso da operação


4.1 Caso dados introduzidos sejam inválidos, exibe mensagem “Dados inválidos”.

4.2 Retorna ao passo 2 deste caso de uso. Interfaces

Formulário “Acesso”

Insere dados"utilizador" + "palavra-passe"

Retorna "Erro"

Retorna "Sucesso"

Inicia a aplicação

Consulta parâmetros

Dados introduzidosIncorrectos

Obter permissões e acessos

Correctos

Abrir formulário "Acesso"

SistemaUtilizador


119

5.8 MODELO DE ANÁLISE E DESENHO

A disciplina (workflow) de análise e desenho tem por finalidade a especificação técnica do

sistema a partir das especificações funcionais do modelo de casos de uso.

O modelo conceptual completo do Archetypus pode ser observado mais adiante no diagrama

de classes completo (figura 28), tendo nós optado por explanar o modelo por fases agrupando as

classes em pequenos grupos. Esses grupos são os seguintes:

• Nível organizacional (definição dos valores da organização)

• Nível das componentes padrão do modelo.

• Nível das pessoas (papéis assumidos)

• Nível dos recursos de informação (suporte ao modelo)

• Nível de parametrização do sistema

5.8.1 NÍVEL ORGANIZACIONAL

A um nível organizacional pretende-se guardar a informação relacionada com os valores da

organização, a criação de modelos scorecard e os dados da organização. A flexibilidade do sistema

permite a possibilidade de serem definidos vários modelos scorecard para cada organização podendo

apenas um deles estar activo. O diagrama seguinte apresenta as classes necessárias para a informação

organizacional.

Figura 23 – Diagrama de classes: nível organizacional

A classe “Valores” representa os valores da organização nomeadamente a sua visão, missão e

estratégia, estando estes directamente ligados a modelos de scorecard. De modelo para modelo os valores

podem variar, nomeadamente a estratégia que é o aspecto que condiciona directamente a definição do

modelo de scorecard a adoptar. Esta classe satisfaz os seguintes requisitos do sistema:

1. Definição da missão

2. Definição da visão

3. Definição da estratégia


120

4. Definição dos objectivos estratégicos.

A classe “Modelo” tem como finalidade a representação dos diferentes modelos de scorecard

que poderão ser criados na organização, assumindo dois tipos: Organizacional (O) – um modelo geral

para a organização; Pessoal (P) – um modelo para um empregado específico da organização, o

chamado scorecard pessoal.

5.8.2 COMPONENTES PADRÃO DO MODELO

No que respeita às componentes padrão do modelo scorecard, apresenta-se o diagrama de

classes seguinte, explicando-se depois tendo em conta a sequência lógica de construção de um modelo

scorecard.

Figura 24 – Diagrama de classes: componentes padrão do modelo

Pela observação do diagrama acima concluímos que um modelo scorecard é composto por

várias perspectivas, só fazendo sentido a existência de determinada perspectiva enquanto pertencente a

pelo menos um modelo. Quanto às perspectivas, estas podem assumir dois tipos: Standard (S) –


121

perspectivas padrão do BSC, designadamente a financeira, clientes, processos internos e aprendizagem

e crescimento; e o tipo Personalizada (P) – perspectivas extra que podem ser criadas e incorporadas em

qualquer modelo de scorecard, funcionando da mesma forma que as padrão, isto é, tendo objectivos,

indicadores, metas e iniciativas. Para além disso, é definido para cada perspectiva um tema ou frase que

justifica a razão da existência da perspectiva, como por exemplo o tema da perspectiva financeira do

modelo padrão: “Como é que podemos cuidar dos interesses dos nossos accionistas”. Por fim, o

último atributo a definir para as perspectivas é a ordem, cuja utilidade é a indicação da sequência

normal de relações de causa-efeito entre as perspectivas.

Agregado às perspectivas vêem os objectivos, sendo a partir destes que se desenvolve o resto

do modelo básico de definição do scorecard. Para cada objectivo poderão ser definidos vários

indicadores e respectivos valores para as metas. Detalhando um pouco mais a filosofia de

funcionamento do sistema relativamente às metas, para cada indicador é definido um valor pretendido

(meta) e um valor limite, correspondendo o valor pretendido ao alcance do objectivo proposto e o

valor limite a um desempenho muito fraco na concretização do objectivo. A título de exemplo, em

termos de simbologia a apresentar nos diversos mapas de desempenho presentes no sistema de

informação, consideraríamos da seguinte forma:

• Se o valor actual do indicador for maior ou igual ao valor da meta, então o símbolo a

apresentar é um semáforo com a cor verde .

• Se o valor actual do indicador for maior que o valor limite e menor que o valor da meta,

então o símbolo a apresentar é um semáforo com a cor amarela .

• Se o valor actual do indicador for menor ou igual ao valor limite da meta, então o símbolo

a apresentar é um semáforo com a cor vermelha .

Os valores das metas podem ser considerados desejáveis tanto pelo mínimo valor possível

como pelo máximo, dependendo da natureza do indicador definido. A pensar neste caso de metas cuja

leitura dos valores alcançados deva ser feita de forma inversa, foi criado o atributo “inverter” para a

classe “Indicador”, cujo objectivo é causar a inversão da análise e símbolos apresentados nos diversos

mapas.

Referindo-nos aos indicadores, estes têm como finalidade a medição dos objectivos através de

fórmulas próprias, sendo também sobre estes que são definidas as recompensas pelas metas alcançadas

e emitidos alertas sobre o seu valor actual. Observando o diagrama acima constata-se que as metas

estão definidas como atributos da classe indicador, já que o seu valor depende da natureza do indicador

definido.

As iniciativas são a última componente das perspectivas traduzindo-se nas actividades e tarefas

realizadas para a concretização do objectivo. Para a realização destas actividades poderão ser

necessários recursos adicionais, representando a classe “Recursos” essa necessidade.


122

A classe “Recompensa” foi criada para permitir atribuir recompensas aos colaboradores pelo

alcance de determinadas metas, de acordo com o nível de responsabilidade atribuído. Poderia pensar-se

que as recompensas devessem ser atribuídas em função das actividades (iniciativas) realizadas e não dos

indicadores, mas o principio seguido foi de que se deve recompensar o alcance da meta e não a

realização da actividade, pois a pessoa deve focalizar-se principalmente nas metas a atingir e não na

realização de actividades.

Finalmente, tendo em vista a satisfação dos requisitos relacionados com a concepção do mapa

estratégico e da interligação de objectivos em diversas camadas, criou-se o relacionamento da classe

“Objectivo” com ela mesma, representado no diagrama com o nome “Ligações”.

Com este conjunto de classes (figura 24) satisfazem-se os seguintes requisitos do sistema:

1. Indicação de objectivos, indicadores, metas e iniciativas para cada uma das perspectivas

padrão.

2. Indicação das fórmulas de cálculo dos indicadores.

3. Estabelecimento de ligações entre objectivos, indicadores, metas e iniciativas.

4. Mapa de relações causa-efeito.

5. Possibilidade de interligar objectivos em diversas camadas.

6. Atribuição de objectivos a utilizadores específicos ou grupos de utilizadores

(componente de responsabilização).

7. Definição de várias metas para cada objectivo.

8. Definição de indicadores específicos (utilizador) e gerais (organização).

9. Possibilidade para inserir um número ilimitado de objectivos, indicadores, metas e

iniciativas para qualquer perspectiva.

10. Existência de vários tipos de indicadores/métricas.

11. Definição de empregados responsáveis por iniciativas e indicadores.

12. Associação de sistema de recompensas às metas e iniciativas individuais.

5.8.3 PESSOAS

No âmbito de uma organização existem várias funções desempenhadas pelas pessoas que a

compõem, representadas no diagrama seguinte através de uma especialização a partir da classe

“Pessoa”.


123

Figura 25 – Diagrama de classes: pessoas e papéis desempenhados

Para qualquer pessoa na organização é guardada informação relativa aos seus dados pessoais

de contacto, como forma de permitir o funcionamento do sistema de alertas automáticos. O papel de

administrador tem de existir obrigatoriamente na organização, podendo ser desempenhado por uma ou

mais pessoas. A principal responsabilidade dos administradores é a definição do modelo scorecard

completo. O papel de director também tem de existir na organização, sendo responsável pela

introdução e verificação dos dados dos indicadores e iniciativas. Os colaboradores só consultam o

modelo, sendo a sua função a realização de actividades e o alcance das metas propostas. Tanto os

colaboradores como os directores participam em um ou mais fóruns de discussão, cuja utilidade é a

partilha de informação e comentários sobre as várias componentes do modelo scorecard e actividades

correntes. O papel de administrador do sistema consiste na criação de utilizadores, estabelecimento de

permissões e outras questões relacionadas com personalizações pontuais do sistema.

5.8.4 RECURSOS DE INFORMAÇÃO.

Sendo a filosofia do BSC a operacionalização da estratégia da organização assentando na

difusão e partilha de informação como um meio para tal, pode-se inferir que os recursos de informação

de apoio ao BSC assumem especial atenção. Assim, no caso do Archetypus foi criada a classe

“Informação de suporte” associada às classes de objectivos, indicadores e iniciativas como meio para

disponibilizar informação a cada um destes componentes do scorecard. A informação pode ser em

suporte electrónico (ex: documentos ou aplicações informáticas) ou em suporte papel (ex: manuais,

planos).

Paralelamente foi criada a classe “Forum”, actuando um como meio para a resolução de

dúvidas, recolha de comentários, sugestões e difusão de informação geral.

O diagrama seguinte ilustra as classes criadas para suporte à informação no sistema.


124

Figura 26 – Diagrama de classes: recursos de informação

Com estas classes satisfazem-se os seguintes requisitos impostos ao sistema:

1. Introdução de comentários aos objectivos, indicadores, metas e iniciativas por parte dos

utilizadores do sistema

2. Possibilidade de ligar documentos, mensagens de correio, aplicações externas a

indicadores e objectivos

5.8.5 NÍVEL DE PARAMETRIZAÇÃO DO SISTEMA.

A parametrização do sistema permite a adequação e personalização do sistema à organização e

seus colaboradores. No caso do Archetypus, os parâmetros dizem respeito ao controlo de acessos e ao

formato da informação.


125

A classe “Formato Informação” permite que dentro do mesmo sistema hajam utilizadores que

vejam informação no formato que mais lhe convém. Por exemplo para a informação acerca do

desempenho corrente de determinado objectivo, há a possibilidade de alguns utilizadores verem

semáforos, outros verem faces e outros verem apenas informação descritiva. Ainda em termos da

informação, o SI permite também a adequação da terminologia utilizada a cada utilizador.

A gestão de permissões e acessos é feita com base em perfis de utilizadores, sendo

constituídos perfis com permissões específicas e finalmente atribuídos aos utilizadores.

O diagrama seguinte apresenta a componente de gestão dos parâmetros do sistema

Archetypus.

Figura 27 – Diagrama de classes: parâmetros

Os requisitos satisfeitos por este conjunto de classes são os seguintes:

1. Uso de informação gráfica.

2. Uso de informação qualitativa para descrever a evolução de indicadores.

3. Monitorização gráfica e descritiva do índice de satisfação de cada objectivo.

4. Definição de políticas de segurança.

5. Opção para alterar a terminologia utilizada.


126

Após estes diagramas parciais apresenta-se de seguida o diagrama geral do sistema Archetypus

Scorecard, explicando-se as classes que não foram apresentadas nos diagramas anteriores e indicando

também o resto dos requisitos satisfeitos.

Figura 28 – Diagrama de classes completo


127

Os alertas impostos como requisitos para o sistema Archetypus actuam sobre três entidades:

valor dos indicadores, comentários e mensagens introduzidas. Quanto aos comentários e mensagens,

os alertas são produzidos por um procedimento interno no fórum que aquando duma nova mensagem

ou comentário, envia uma mensagem de correio electrónico de alerta para os remetentes de todas as

mensagens de nível superior. O princípio seguido é o de informar todos os intervenientes em

determinada mensagem aquando de novas alterações.

Quanto aos alertas sobre indicadores, estes estão definidos através da classe “Alertas” onde é

definido o tipo de alerta por indicador e pessoa. O alerta é gerado nas seguintes situações:

• Quando o valor do indicador baixar o valor mínimo definido para a meta, será emitido um

alerta sobre o mau desempenho deste objectivo.

• Quando o valor do indicador ultrapassar o valor da meta, será emitido um alerta que o

objectivo já foi alcançado.

Os requisitos finalmente satisfeitos são os seguintes:

1. Sistema de alertas sobre os indicadores, comentários e mensagens introduzidas.

Quanto aos restantes requisitos não enunciados atrás, tais como: os assistentes para ajuda aos

utilizadores na realização de determinadas tarefas, a apresentação gráfica da ligação entre os objectivos,

a existência de relatórios e modelos de relatórios predefinidos, a administração do sistema centralizada,

facilidade de utilização do sistema, etc., não são passíveis de representação no modelo de análise e

desenho, sendo por isso tidos em consideração durante o desenvolvimento do sistema.

Nesta secção do trabalho, imediatamente seguido ao diagrama de classes faz sentido apresentar

o esquema de tabelas correspondente, o qual deixamos disponível para consulta no anexo I.

5.9 MODELO DE IMPLEMENTAÇÃO

A disciplina de implementação tem como propósito a criação do código fonte que implementa

as classes definidas no modelo anterior, tendo como resultado final um programa executável pronto a

funcionar. Devido à complexidade do Archetypus, a apresentação dos diferentes diagramas de

componentes será feita nos mesmos cinco agrupamentos anteriormente utilizados no modelo de

desenho.

Começamos por ilustrar o funcionamento geral do sistema através de um diagrama de pacotes

na figura seguinte, onde se evidencia ao centro o sistema Archetypus e as diversas relações de

dependência com pacotes de componentes do sistema.


128

Figura 29 – Diagrama de pacotes de componentes: geral

O pacote “Tabelas” representa as tabelas que compõem a base de dados, o pacote

“Procedimentos” representa os diversos blocos de código fonte, o pacote “Formulários” representa a

componente de interfaces com os utilizadores do sistema, o pacote “Imagens” representa os ficheiros

do tipo imagem que estão presentes na aplicação e por fim o pacote “Ligações” representa as conexões

à base de dados.

De uma forma mais detalhada a figura seguinte ilustra os componentes do sistema agrupados

nos seus pacotes respectivos, verificando-se que o pacote das “Ligações” apenas evidencia dois

componentes, um de conexão à base de dados SQL-SERVER e um outro que representa quaisquer

ficheiros externos que alimentam o sistema com dados.

Figura 30 – Diagrama de componentes: detalhe por pacote


129

O pacote de “Imagens” mostra os seis ícones usados tanto em formulários como nos mapas

de scorecard e relatórios.

O pacote “Formulários” mostra as páginas acessíveis a partir do menu principal e mais

comummente utilizadas pelos utilizadores no seu dia-a-dia. Todas estas páginas são dinâmicas, por isso

aparecem como sendo ficheiros com a extensão “asp”, estando dependentes de uma conexão à base de

dados. Também se verifica haver uma generalização representada no diagrama para os scorecards

organizacional e pessoal, pois na sua essência eles são iguais diferenciando apenas no facto de o

organizacional ser global para a organização e o pessoal ser específico para um utilizador.

No pacote “Procedimentos” (figura 31) mostram-se programas e blocos de código específicos

para executarem determinadas tarefas, geralmente atribuídas ao actor tempo.

Por fim, o pacote “Tabelas” apesar de representar todas as tabelas do sistema só contém as

tabelas necessárias para os componentes do pacote de procedimentos, estando as outras tabelas

evidenciadas nos diagramas seguintes conforme vão sendo necessárias.

Figura 31 – Diagrama de componentes: detalhe por pacote

Até aqui foram apresentados diagramas gerais organizados em pacotes, passando de seguida a

detalhá-los agrupando-os nas mesmas categorias utilizadas para dividir as classes.

A figura seguinte apresenta o diagrama de componentes do nível organizacional,

designadamente os valores da organização, informação da própria organização e modelos de scorecard,

na forma de páginas web e respectivas tabelas que usam.


130

Figura 32 – Diagrama de componentes: nível organizacional

O diagrama seguinte respeita às componentes padrão do modelo scorecard identificando a

sequência de relações desde a definição do modelo inicial do scorecard passando pela definição das

perspectivas, objectivos, indicadores, metas, iniciativas e mapa estratégico. Para cada componente

padrão existe uma tabela específica, como se pode constatar na figura abaixo.

Figura 33 – Diagrama de componentes: componentes padrão do modelo scorecard

Mais uma vez se chama a atenção para o facto das metas estarem incluídas na tabela de

indicadores, não existindo por isso uma tabela específica para metas. Uma outra observação é que a

tabela de ligações regista tanto o mapa estratégico como um outro mapa onde são interligados

objectivos em diversas camadas.


131

O próximo diagrama de componentes diz respeito aos diversos papéis desempenhados pelas

pessoas na organização. A relação de um-para-um existente entre as classes “Pessoa” e “Utilizador”

conduziu à agregação dos seus atributos numa única tabela. Foi criada uma página web que contém o

formulário para definir o utilizador e uma outra para definir as permissões. Nesta última são definidos

perfis de utilizador com permissões específicas, sendo depois atribuído um perfil a cada utilizador.

Figura 34 – Diagrama de componentes: diversos papéis assumidos pelas pessoas

O próximo diagrama refere-se aos recursos de informação para suporte às várias componentes

do scorecard, nomeadamente a introdução de observações através de notas e anexação de documentos

electrónicos. Foram estabelecidas páginas web específicas para registar cada tipo de informação (notas,

anexos) com uma relação de dependência estabelecida com cada uma das várias componentes do

scorecard.

Figura 35 – Diagrama de componentes: recursos de informação


132

O diagrama seguinte evidencia as capacidades do sistema Archetypus para se adaptar aos

utilizadores, possibilitando o estabelecimento de formatos e terminologia própria para cada utilizador e

modelo scorecard.

Figura 36 – Diagrama de componentes: parametrização do sistema

Por último surgem os diagramas de componentes relativos à flexibilidade do sistema

Archetypus, ilustrando capacidades como: arquivo de informação, importação de dados de fontes

externas e exportação de dados para diversos formatos.

Figura 37 – Diagrama de componentes: arquivo, importação e exportação


133

5.10 PLANO DE DISTRIBUIÇÃO

Este artefacto tem como finalidade a apresentação das relações físicas entre componentes de

hardware e software num sistema. É composto por nós (nodes), relações de dependência (dependencies) e

componentes (components). Os nós representam unidades computacionais com capacidade de

processamento e memória, podendo ser tanto um simples sensor como um servidor. As relações de

dependência são conexões entre os vários nós e componentes, indicando uma relação entre ambos. Os

componentes representam módulos de código fonte ou programas executáveis que correm dentro dos

nós.

Figura 38 – Plano de distribuição

A arquitectura do sistema mostra que o Archetypus foi concebido para correr sobre um

servidor de Internet, necessitando de uma conexão para uma base de dados (Access, Oracle, Informix,

SQL-Server). Qualquer cliente que pretenda ligar-se ao sistema só necessita de ter instalado um

navegador (browser) comum de acesso à internet, tal como o Netscape Navigator ou Internet Explorer. Em

termos de acesso ao sistema, pode ser feito a partir da rede interna ou externa à organização, impondo-

se neste último caso a existência de uma VPN (Virtual Private Network).


134

5.11 PROTÓTIPO DE INTERFACE

O sistema Archetypus, como já foi referido anteriormente, foi concebido para funcionar num

ambiente web, ou seja da mesma forma que os websites. Estas páginas contêm código em HTML para a

componente de interface e interacção com o utilizador e código em ASP para a componente da

conecção das páginas com a base de dados. Seguindo o mesmo conceito das páginas web também estas

páginas são dinâmicas, sendo esta a característica que torna o Archetypus num sistema adaptável ao

utilizador, nomeadamente na terminologia e formato de informação. Um último pormenor prende-se

com a resolução dos ecrãs, tendo sido adoptada a de 1024 x 768 pixels, uma vez que actualmente é

comum a utilização de resoluções iguais ou superiores a esta.

Nesta secção da dissertação não vamos apresentar todos os formulários do sistema

Archetypus, mas somente aqueles considerados mais importantes deixando os outros disponíveis para

consulta no anexo H.

Para facilitar ao leitor a compreensão da estrutura do sistema e do seu funcionamento geral

optou-se por apresentar inicialmente o esquema de menus e interfaces do sistema. A figura seguinte

não é mais do que o mapa do website que aparece aos utilizadores do sistema.

Figura 39 – Mapa do site Archetypus


135

Quando o utilizador acede à aplicação aparece-lhe um formulário inicial de acesso ao sistema,

figura 40, onde tem de inserir a sua identificação de utilizador e palavra-passe de acesso. Como se pode

ver na figura, todos os menus estão visíveis mas indisponíveis até uma identificação bem sucedida por

parte do utilizador.

Versão 1.0 Optimizado Microsoft Internet Explorer 6.0 (1024 x 768)

ACESSO

Utilizador Palavra passe

ENTRAR SAIR

Versão 1.0 Optimizado Microsoft Internet Explorer 6.0 (1024 x 768) Utilizador: gil_vieira


Principal | Scorecard | Relatórios | Fórum | Parâmetros | Administração Login | Fechar

Terça-feira, 1 de Março de 2005Or ie nte a su a org ani zaç ão e m torno da sua e strat égia

Figura 40 – Interface: acesso

Após a entrada do utilizador no sistema, este exibe uma página com o modelo scorecard

organizacional, figura 41, constituindo este modelo a página principal do sistema. Esta página exibe

valores, tendências e estados dos objectivos e indicadores definidos para cada perspectiva.

Adicionalmente, conforme as permissões do utilizador o modelo pode ser alterado, podem ser

adicionados anexos, notas e comentários ou geridas as iniciativas estabelecidas para cada objectivo. O

detalhe das perspectivas pode ser consultado no scorecard pessoal ou na própria tabela de manutenção

de iniciativas.


136

SCORECARD ORGANIZACIONAL PERSPECTIVA FINANCEIRA

Objectivo / Indicador Unid. Valor Meta Var. Peso Ten. Resp. Inic. Anexos Notas

Aumentar a rentabilidade ROCE—Return on capital employed Cash Flow

Aumentar volume de vendas Margem bruta

% 20 € 150000

€ 1000000

1 %

Francisco

Carla

Entregas atempadas Tempo médio de resposta às reclamações

Aumentar grau de satisfação % 90 dia 3 José

PERSPECTIVA INTERNA

Taxa de não conformidades Quantidade de desperdícios

Aumentar a produtividade

Adquirir clientes Números de novos clientes obtidos

% 1,3 Kg 14000

16

António

Rogério

PERSPECTIVA APRENDIZAGEM E CRESCIMENTO

PERSPECTIVA CLIENTES

Período:

14 137843

980263,5

0,6

-3%

7%

8%

Manuel António

97 5

2%0,5%

0,05 12000

25

-0,2%0,3%

65%

100%

35%

40%35%

30%70%

% 0,3 2

20% 100%

Formação Horas de formação por trabalhador fabril H 28 Carlos 30 20% 100%

EDITAR




Terça-feira, 1 de Março de 2005 Or ie nte a su a org ani zaç ão e m torno da sua e strat égia

NOTAS ANEXOS




Figura 41 – Interface: mapa scorecard organizacional

As iniciativas estão representadas por uma lâmpada que aparece na linha de cada objectivo

indicando que aquele objectivo específico tem pelo menos uma iniciativa atribuída. Para se aceder à

lista de iniciativas basta dar um clique com o rato sobre o símbolo. Os anexos são representados por

um “clip” encontrando-se na linha de cada objectivo e/ou indicador, indicando que existe informação

anexada àquela componente do scorecard. Da mesma forma que para as iniciativas, para aceder aos

anexos basta dar um clique sobre o símbolo. Finalmente, para as notas e comentários representados

por um “bloco de notas”, o comportamento é o mesmo dos anexos.

Na parte esquerda do mapa existem umas bolas que assumem três cores: vermelho, amarelo e

verde. A bola vermelha representa um mau desempenho do indicador ou o não alcance do objectivo

definido. A bola amarela representa um desempenho razoável mas ainda insuficiente do indicador

respectivo. A bola verde representa um desempenho satisfatório e o alcance do objectivo respectivo.

Estes símbolos poderão ser alterados de acordo com o gosto do utilizador, podendo passar-se a usar

semáforos, faces, setas, ou até mesmo descrições qualitativas.

O scorecard pessoal (figura 42) é semelhante ao organizacional mas contém apenas perspectivas,

objectivos e indicadores específicos do utilizador. No que respeita às iniciativas, é apresentado um

quadro próprio que mostra o detalhe de cada uma bem como o seu estado de realização.


137

SCORECARD PESSOAL

PERSPECTIVA INTERNA



Adquirir clientes Custo de aquisição de novos clientes

% 1,3 Kg 14000

11750

PERSPECTIVA APRENDIZAGEM E CRESCIMENTO

Período:

0,05 12000

15000

-0,2%0,3%

30% 70%

% 0,3 2

20% 40%

Formação Horas de formação anuais H 28 30 20% 100%

EDITAR António Marques: 60%

€ Tempo de resolução de reclamações 2,2 3 -47% 60% dia

Iniciativa Data Início Data Fim Realização (%) Investimento Att. Not. INICIATIVAS

Realizar visitas periódicas aos clientes 7/11/2004 7/03/2005 39% 4500 €

Formação em Qualidade

Estudo de mercado do sul de Portugal

Campanha de publicidade

13/12/2004 13/02/2004 70% 1500 €

26/11/2004 26/05/2004 58% 4000 €

30/10/2004 30/01/2004 91% 13700 €





NOTAS ANEXOS

Objectivo / Indicador Unid. Valor Meta Var. Peso Ten. Inic. Anexos Notas

Objectivo / Indicador Unid. Valor Meta Var. Peso Ten. Inic. Anexos Notas

Figura 42 – Interface: mapa scorecard pessoal

Em termos de simbologia, a funcionalidade e o comportamento são iguais aos do scorecard

organizacional.

O mapa seguinte (figura 43) é considerado o mais importante no processo de implementação

do Balanced Scorecard porque descreve a estratégia da organização em termos de relações de causa-efeito

entre objectivos, agrupando-os nas diversas perspectivas. Este mapa é concebido pela administração da

organização e poderá ir sofrendo alterações ao longo do tempo, decorrentes das diversas adaptações

feitas à estratégia. Para isso, o sistema permite a criação de novos mapas estratégicos ao longo do

tempo, disponibilizando-os posteriormente para análise futura.


138

MAPA ESTRATÉGICO

GRAVAR CANCELAR

NOVO MAPA

OBJECTIVOS

APR.

CR

ESC

IME

NTO

INTE

RN

A

CLI

ENTE

S

FIN

ANC

EIRA

Financeira

Clientes

Interna

Aprendizagem e Crescimento

Aumentar rentabilidade Aumentar volume de vendas

Aumentar grau de satisfação

Aumentar produtividade Desenvolver novos produtos

Aumentar ROI em 3%

Aumentar renta-bilidade

Aumentar volume de vendas

Aumentar ROI em 3%


Aumentar pro-dutividade

Desenvolver novos produtos

Baixar preços

Baixar custos Melhoria contínua

Motivação dos trabalhadores Formação Especialização

Baixar preços

Baixar custos Melhoria contí-nua

Especialização Formação Motivação dos trabalhadores

Aumentar vendas médias por cliente Diminuir prazos de entrega

Aumentar vendas médias por cliente

Diminuir prazos de entrega





Figura 43 – Interface: mapa estratégico

Na figura acima observa-se que os objectivos aparecem agrupados (caixa à direita) nas suas

perspectivas conforme definido no modelo scorecard, sendo depois arrastados para o mapa à esquerda e

ligados entre si, constituindo assim o mapa estratégico. No mapa estratégico as elipses que contêm os

objectivos vão assumindo a cor verde, amarelo ou vermelho conforme o desempenho e grau de

alcance do objectivo.

A próxima figura (44) ilustra o formulário para criação de modelos scorecard. Um modelo

scorecard consiste na definição de perspectivas, objectivos por perspectiva e indicadores e iniciativas por

objectivo. Existe também a possibilidade de serem criadas novas perspectivas e definidos scorecards

organizacionais ou pessoais.


139

MODELO SCORECARD

GRAVAR CANCELAR

CRIAR

REMOVER PERSPECTIVA

CRIAR

REMOVER OBJECTIVO

CRIAR

REMOVER INDICADOR

CRIAR

REMOVER INICIATIVA

PERSPECTIVA FINANCEIRA Objectivo / Indicador Unid. Meta Responsável Iniciativas

Aumentar a rentabilidade ROCE—Return on capital employed Cash Flow

Aumentar a rentabilidade

Aumentar volume de vendas Margem bruta

% 20 € 150000

€ 1000000

1 %

Francisco

Carla

Entregas atempadas Tempo méd io máximo de resolução de reclamações

Aumentar grau de satisfação % 97

dias 5 José Número de reclamações recebidas 10

PERSPECTIVA INTERNA Objectivo/Indicador Unid Meta Responsável Iniciativas



Adquirir clientes Números de novos clientes obtidos

% 0,05 Kg 12000

25

António

Rogério

PERSPECTIVA APRENDIZAGEM E CRESCIMENTO Objectivo/Indicador Unid Meta Responsável Iniciativas


PERSPECTIVA CLIENTES Objectivo/Indicador Unid Meta Responsável Iniciativas

Nome

Tipo

Descrição

Data




Figura 44 – Interface: mapa do modelo scorecard

Ainda respeitante à figura acima, os botões para criação de perspectivas, objectivos,

indicadores ou iniciativas chamam formulários próprios que contêm cada uma dessas componentes do

scorecard. A título de exemplo apresenta-se de seguida um formulário para a gestão de indicadores,

podendo consultar-se os restantes em anexo (anexo G).

VALORES DE INDICADORES

Nome

Valor

Data / Hora

GRAVAR

CANCELAR * x

01/03/2005 15:38:06

Figura 45 – Interface: formulário "Valores de Indicadores"


140

Mínimo valor

Meta

INDICADORES

Nome

GRAVAR CANCELAR

Fórmula

Unidade

Descrição

Frequência

Responsável Inverter símbolos

RECOMPENSA

* x

dias

Estatísticas

Valor Actual Variação Tendência Estado

Figura 46 – Interface: formulário "Indicadores"

O primeiro formulário “Valores de Indicadores” é utilizado para guardar os valores actuais dos

indicadores, ao longo do tempo. Tal como foi referido anteriormente, no diagrama de classes, as

pessoas com o papel de “Director” têm a responsabilidade de alimentar o sistema com os dados

actuais dos indicadores, sendo esta a razão de existência deste formulário. Para os indicadores cuja

actualização com valores seja automática, serão desenvolvidos pequenos procedimento que depois

serão executados automaticamente pelo sistema (representado pelo actor “Tempo” nos casos de uso).

O segundo formulário relativo aos indicadores, figura 46, aparece ao utilizador tanto quando

pretende criar um indicador (caso do formulário “Modelo Scorecard”) como quando pretende

consultar o detalhe do indicador, apresentando diversa informação para além daquela que não é visível

nos mapas gerais, tal como a fórmula de cálculo, valores de meta, frequência de cálculo do indicador e

finalmente uma área de estatísticas com valores actuais do indicador.

No que respeita às características de flexibilidade inicialmente impostas como requisitos ao

sistema Archetypus, apresenta-se o exemplo do formulário para definição dos formatos de

apresentação da informação aos utilizadores. Como foi referido anteriormente, nos mapas que

aparecem ao longo da aplicação existe simbologia ligada ao desempenho dos indicadores,

nomeadamente semáforos, faces, setas, etc., sendo esta a simbologia que pode ser adequada a cada

utilizador.


141

FORMATOS APRESENTAÇÃO

Valor Bom

GRAVAR CANCELAR

Símbolo Descrição

Valor Médio

Valor Mau

Scorecard

Utilizador

Figura 47 – Interface: formulário "Formatos de Apresentação"

Pela observação da figura acima, constata-se que para cada utilizador e respectivo modelo (no

caso dos scorecards pessoais) poderão ser definidas descrições ou símbolos a utilizar no sistema. Estes

são definidos para três categorias:

• VALOR BOM – valor que corresponde ao alcance da meta proposta, correspondendo

por defeito ao semáforo com a cor verde.

• VALOR MÉDIO – valor que corresponde a um desempenho razoável do indicador,

correspondendo por defeito ao semáforo com a cor amarela.

• VALOR MAU – valor que corresponde a um mau desempenho do indicador,

correspondendo por defeito ao semáforo com a cor vermelha.

O último formulário que apresentamos nesta secção da dissertação é o da definição de

permissões e controlo de acessos. A figura seguinte (48) mostra-nos que as permissões e acessos são

atribuídos a perfis (papéis desempenhados) de utilizador. Para cada componente do modelo scorecard

poderão ser especificadas permissões de leitura, escrita e remoção. Assim, a título de exemplo, os

utilizadores que desempenhem o papel de administrador terão permissões totais, enquanto que aqueles

que desempenhem o papel de director para além das permissões de leitura ao scorecard, só terão

permissões de escrita nos indicadores da sua perspectiva. O conceito de permissões aqui implementado

passa pela pré-configuração de perfis de permissões e depois pela atribuição de determinado perfil a

cada utilizador.


142

PERMISSÕES

GRAVAR CANCELAR

VALORES L E A

Missão

Visão

Estratégia

Objectivos Estratégicos

TABELAS

Objectivos

Metas

Indicadores

Iniciativas

Recompensas

RELATÓRIOS

Criação Impressão

PERSPECTIVAS

Financeira Objectivos Metas Indicadores Iniciativas

Clientes Objectivos Metas Indicadores Iniciativas

Interna Objectivos Metas Indicadores Iniciativas

Aprend. e Crescimento Objectivos Metas Indicadores Iniciativas

ADMINISTRAÇÃO DO SISTEMA





Perfil

* x

L E A

L E A

Figura 48 – Interface: formulário “Permissões”

Para concluir, nesta secção de ilustração de alguns protótipos de interface apenas

apresentámos aqueles que julgámos mais importantes nas diversas vertentes do sistema Archetypus,

deixando os restantes para consulta no anexo H.

5.12 RESUMO

Neste capítulo propúnhamo-nos desenvolver um modelo conceptual para um sistema de

informação de suporte ao BSC, tendo em conta as funcionalidades consideradas mais importantes para

os utilizadores deste tipo de sistemas. O sistema proposto foi chamado de Archetypus, seguiu-se a

metodologia da Rational, o RUP (Rational Unified Process) e a linguagem UML (Unified Modeling

Language) para a sua modelação.

Por ser uma metodologia incremental e iterativa, foram desenvolvidos uma série de artefactos

(modelos e documentação) tendo sido decidido não seguir a metodologia à risca mas sim adaptá-la às

necessidades e à realidade de desenvolvimento do sistema. Sendo um dos pontos mais importantes da

metodologia a recolha dos requisitos e posterior controlo das suas alterações, neste caso não se

seguiram essas etapas porque a lista de requisitos do sistema foi previamente estudada e assumia-se

como estanque a alterações. Para além disso, uma metodologia incremental e iterativa só é possível de

ser aplicada em projectos de desenvolvimento em tempo real.


143

A um nível geral de gestão do projecto, foram produzidos os documentos de visão do sistema,

glossário de termos utilizados e uma lista de riscos inerentes ao projecto. Ao nível dos requisitos, tendo

nós partido de uma lista já constituída e verificada realizou-se a modelação, especificação detalhada dos

casos de uso e a representação do comportamento do sistema através de diagramas de actividade. A

fase seguinte foi a análise e desenho do sistema onde foram criados o diagrama de classes, esquema de

tabelas e protótipo de interface. De seguida produziu-se o modelo de componentes do sistema

representando os ficheiros de código fonte, as tabelas, bibliotecas, etc. Finalmente construiu-se um

esquema da topologia do sistema Archetypus.

Estamos convictos que a documentação produzida é suficiente para que uma equipa de

desenvolvimento compreenda o sistema proposto, ao pormenor, podendo inclusivamente concebê-lo

sem problemas.

Capítulo VI

CONCLUSÕES

• Conclusões sobre o trabalho desenvolvido

• Desenvolvimentos futuros

CAPÍTULO 6 – CONCLUSÕES E TRABALHO FUTURO

147

6.1 CONCLUSÕES

Ao longo dos capítulos anteriores foi apresentado o trabalho desenvolvido no âmbito desta

dissertação e que se insere na temática do suporte tecnológico ao Balanced Scorecard (BSC), mais

concretamente nos sistemas de informação de suporte a este instrumento de gestão estratégica. Esta

foi a principal linha de orientação seguida pelo trabalho, não aprofundando demasiado o estudo do

BSC. Aprofundou-se sim, a modelação e concepção do sistema de informação de acordo com a

metodologia de desenvolvimento de software definida.

O trabalho iniciou, no 2º capítulo, com um estudo teórico sobre o BSC onde foram

apresentados os conceitos básicos, descritas as perspectivas padrão, nomeados pontos fortes e

limitações deste instrumento de gestão, tecidas considerações sobre questões a ter em conta aquando

duma implementação, terminando com a ilustração de um caso real de implementação do BSC. A

conclusão retirada do estudo realizado foi que a orientação das organizações para a gestão do

desempenho se assume como uma das tendências futuras das organizações. O alinhamento do BSC

com as tecnologias de informação é também uma tendência futura inevitável, porque mais do que um

sistema de medição de indicadores, ele poderá ser considerado um sistema de partilha de informação.

Ficou assim justificada a necessidade de ser estudada a adequação dos sistemas de informação à

implementação do BSC nas organizações.

Prosseguindo o estudo, no terceiro capítulo, sobre as funcionalidades consideradas relevantes

nos sistemas de informação para suporte ao BSC, este realizou-se em três etapas. Na primeira foi

analisada diversa documentação produzida pelo instituto Balanced Scorecard Colaborative (BSCol), onde

foram recolhidas as funcionalidades consideradas como mínimas a existir em qualquer sistema de

informação para suporte ao BSC. Na segunda fase foi feito um levantamento das funcionalidades

presentes nos sistemas de informação já certificados pelo mesmo instituto, onde se determinaram mais

algumas para além daquelas definidas pelo BSCol. A terceira fase teve como objectivo a filtragem e

validação da lista de funcionalidades recolhidas anteriormente, tendo sido para isso inquiridas diversas

organizações nacionais e internacionais, com experiência neste tipo de sistema de informação.

Ainda no terceiro capítulo, verificou-se que ao contrário da opinião dos utilizadores a

generalidade dos fornecedores indicaram que os seus sistemas de informação suportavam todas as

funcionalidades descritas no inquérito, mas no entanto, como se observa na secção 3.4 (subsecções

3.4.1 e 3.4.3) os utilizadores para além de não terem reconhecido a existência de algumas dessas

funcionalidades, consideraram-nas como tendo um grau significativo de importância. Este capítulo

terminou com a constituição de uma lista das funcionalidades consideradas relevantes nos sistemas de

informação para suporte ao BSC, concluindo nós que ainda existem utilizadores não totalmente

satisfeitos, ou então, com falta de informação acerca das potencialidades dos seus sistemas actuais.


148

No quarto capítulo estudaram-se as diversas metodologias de desenvolvimento de software,

tendo-se concluído que a metodologia Rational Unified Process (RUP) era a mais indicada para ser seguida

na concepção do sistema actual, por ser a mais documentada e adaptável a esta realidade.

No quinto capítulo modelou-se o sistema através da produção de diversos modelos

(artefactos) de acordo com a componente estática da metodologia adoptada, obtendo como resultado

final uma arquitectura do sistema projectada de forma a permitir o seu funcionamento em qualquer

plataforma que suporte o uso da Internet, pois este sistema não é mais do que um caso particular de um

website.

De uma forma geral a contribuição específica deste trabalho está relacionada com dois

aspectos. O primeiro, a identificação e constituição de uma lista de funcionalidades consideradas

relevantes para os utilizadores, servindo como um meio de dar a conhecer a opinião dos utilizadores

aos fornecedores deste tipo de sistemas de informação. Na perspectiva dos potenciais utilizadores, esta

lista é um ponto de partida para a avaliação dos sistemas de informação presentes no mercado,

auxiliando no processo de escolha de uma solução. Na perspectiva dos actuais utilizadores de sistemas

de informação para suporte ao BSC, este estudo retrata a experiência de outros utilizadores,

fornecendo informação sobre as potencialidades deste tipo de sistemas de informação.

O segundo aspecto é a proposta de uma arquitectura que apresenta um alto nível de

flexibilidade, desempenho e adequação a uma realidade estudada que se apresenta como o caminho

futuro das organizações. A arquitectura proposta é inovadora não só por utilizar somente tecnologia

web, constituindo uma mais valia para as organizações uma vez que não obriga a grande investimento

tanto ao nível de software como de formação dos recursos humanos, mas também por assentar num

modelo conceptual profundamente estudado, simplificado e claro.

6.2 DESENVOLVIMENTOS FUTUROS

Como perspectivas de trabalho futuro, três linhas emergem com vista há conclusão deste

trabalho:

1. Construção e implementação do sistema de informação.

2. Actualização do sistema de acordo com a experiência a adquirir em implementações

futuras.

3. Certificação junto do instituto BSCol


149

Quanto ao primeiro ponto, a implementação do sistema será feita em organizações conhecidas

pelo autor deste trabalho, sendo tomadas as medidas necessárias para garantir a minimização dos

bloqueios à sua aceitação, nomeadamente:

• CUSTO – de forma a conseguir implementar o sistema nas várias unidades de negócio da

organização, ele será distribuído gratuitamente nesta fase inicial durante 2 anos. Findo este

período, a organização optará pela compra de licenças ou pelo abandono do sistema.

• PORTABILIDADE – o sistema poderá ser acedido através de um browser, pelo que os

utilizadores não estarão dependentes de uma estação de trabalho com software específico

para trabalhar no sistema. Havendo estabelecida uma ligação VPN será também possível

aceder ao sistema a partir do exterior da organização.

• FACILIDADE DE INSTALAÇÃO – o sistema foi desenvolvido numa arquitectura web,

não necessitando por isso de pacotes de bibliotecas ou programas específicos para a sua

instalação. Os requisitos são apenas a disponibilidade de uma estação de trabalho que

contenha um browser.

À semelhança dos sistemas de informação comuns, também neste durante a implementação

nas várias organizações serão realizadas actualizações e desenvolvimentos de novas funcionalidades,

conforme as necessidades dos utilizadores e as imposições do ambiente organizacional. O princípio é o

de adequar o sistema a cada organização onde for implementado, capacitando-o e diferenciando-o,

cada vez mais, relativamente aos outros.

Finalmente, pretende-se certificar este sistema perante o instituto Balanced Scorecard Collaborative

de acordo com os princípios e filosofia do BSC, constituindo assim o primeiro sistema português no

mercado.

BIBLIOGRAFIA

151

Bibliografia

BS COLLABORATIVE, I. (2000, May 5). Balanced Scorecard Functional Standards Release 1.0a. Acedido em 5/7/2004, em http://www.bscol.com/bsc_online/technology/standards/

BS COLLABORATIVE, I. (2003). BSCol. Acedido em 5/7/2004, em http://www.bscol.com/bscol/mission/

EPSTEIN, M. J., e MANZONI, J.-F. (1997), The balanced scorecard and tableau de bord: Translating strategy into action. Management Accounting.

EVANS, G. K. (2001), A Simplified Approach to RUP: Rational Software Corporation.

FOWLER, M. (2003). The New Methodology. Acedido em 22/12/2004, em http://martinfowler.com/articles/newMethodology.html

IEEE. (1990), IEEE Standard Glossary of Software Engineering Terminology. New York: IEEE Computer Society.

KANJI, G. K., e SÁ, P. M. (2002), Kanji's Business Scorecard. Total Quality Management, 13, 13-27.

KAPLAN, R. S., e NORTON, D. P. (1992), The balanced scorecard - measures that drive performance. Harvard Business Review, 71-79.

KAPLAN, R. S., e NORTON, D. P. (1993), Putting the balanced scorecard to work. Harvard Business Review.

KAPLAN, R. S., e NORTON, D. P. (1996a), The balanced scorecard: translating strategy into action. Boston: Harvard Business School Press.

KAPLAN, R. S., e NORTON, D. P. (1996b), Linking the Balanced Scorecard to Strategy. California Management Review, 39, 53-79.

KAPLAN, R. S., e NORTON, D. P. (2000a), Having Trouble with Your Strategy? Then Map It. Harvard Business Review.

KAPLAN, R. S., e NORTON, D. P. (2000b), The Strategy-Focused Organization: How Balanced Scorecard Companies Thrive in the New Business Environment. Boston: Harvard Business School Press.

KAPLAN, R. S., NORTON, D. P., e SERRA, T. A. C. D. C. (2001), Organização orientada para a estratégia: como as empresas que adotam o balanced scorecard prosperam no novo ambiente de negócios (7 ed.). Rio de Janeiro: Campus.

KROLL, P., e KRUCHTEN, P. (2003), The Rational Unified Process Made Easy: A Practitioner's Guide to the RUP: Addison Wesley.

KRUCHTEN, P. (2003), The Rational Unified Process: An Introduction (Third Edition) (3 ed.). Canada: Addison Wesley.


152

LAWSON, R., STRATTON, W., e HATCH, T. (2004), Automating the Balanced Scorecard. CMA Management, 77(9), 39 - 43.

MACAULAY, L. A. (1996), Requirements Engineering. London: Springer.

MARCHESI, M., SUCCI, G., WELLS, D., e WILLIAMS, L. (2002), Extreme Programming Perspectives. Boston: Addison Wesley.

MARR, B., e NEELY, A. (2003), Automating the balanced scorecard - selection criteria to identify appropriate software applications. Measuring Business Excellence, 7(3), 29-36.

MCCONNELL, S. (1996), Avoiding Classic Mistakes. IEEE Software, 13(2).

MICROSOFT. (2002, Junho). MSF Process Model. Acedido em 30/11/2004, em http://www.microsoft.com/msf

MICROSOFT. (2003, Junho). Microsoft Solutions Framework version 3.0 Overview. Acedido em 30/11/2004, em http://www.microsoft.com/msf

NORREKLIT, H. (2000), The balance on the balanced scorecard - a critical analysis of some of its assumptions. Management Accounting Research, 11, 65-88.

PARDAL, L., e CORREIA, E. (1995), Métodos e técnicas de investigação social (1ª ed ed.). Porto: Areal Editores.

POLLICE, G. (2001), Using the Rational Unified Process for Small Projects: Expanding Upon eXtreme Programming. Lexington: Rational Software Corporation.

POLLICE, G., AUGUSTINE, L., LOWE, C., e MADHUR, J. (2004), Software Development for Small Teams: A RUP-Centric Approach. Boston: Addison Wesley.

RATINGS, O. (2003), Automating the Balanced Scorecard - Maximizing corporate performance through sucessful entreprise-wide deployment: Open Ratings.

SILK, S. (1998), Automating the Balanced Scorecard - It's no longer just a dream - companywide performance indicators right on your desktop computer screen. Management Accounting, 79(11), 38 - 44.

SILVA, A., e VIDEIRA, C. (2001), UML: Metodologias e Ferramentas CASE. Porto: Centro Atlântico.

SOMMERVILLE, I. (2001), Software Engineering (6 ed.). harlow: Addison-Wesley.

SOUSA, M. G. P., e RODRIGUES, L. M. P. D. L. (2002), O Balanced Scorecard: Um instrumento de gestão estratégica para o século XXI. Porto: Editora Rei dos Livros.

WAAL, A. A. (2003), The future of the Balanced Scorecard: an interview with Professor Dr Robert S. Kaplan. Measuring Business Excellence, 7(1), 30-35.

WEST, D. (2002), Planning a Project with the Rational Unified Process. Lexington: Rational Software Corporation.

WIEGERS, K. E. (2003), Software Requirements: Practical techniques for gathering and managing requirements throughout the product development cycle (2 ed.). Washington: Microsoft Press.

BIBLIOGRAFIA

153

RECURSOS ELECTRÓNICOS

Título Endereço (URL)

Websites sobre Balanced Scorecard

Balanced Scorecard Collaborative http://www.bscol.com/bsc_online/technology/ 2 GC Active Management http://www.2gc.co.uk/ Fornecedores de aplicações certificadas

http://www.bscol.com/bsc_online/technology/certified/

Performance Measurement Association

http://www.performanceportal.org/

Instituto Balanced Scorecard http://www.balancedscorecard.org/ Exemplo de Scorecard http://isds.bus.lsu.edu/cvoc/learn/bpr/cprojects/spring1998/bs

m/page5.html Metodologias de desenvolvimento de software

Unified Modeling Language http://www.uml.org Rational Unified Process http://www-306.ibm.com/software/awdtools/rup/ ICONIX http://www.iconixsw.com/ Microsoft Solutions Framework http://msdn.microsoft.com/vstudio/enterprise/msf/ Extreme Programming http://www.extremeprogramming.org/ Metodologias Ágeis http://www.martinfowler.com/articles/newMethodology.html Software BSC (pode ser feito o download e utilizado) Dialog Software http://www.dialogsoftware.com/ Simpel Scorecard http://www.simpel.com/pms.htm Open Scorecard http://www.openscorecard.com/cgi-

bin/Zope.cgi/itsopen/openscorecard Aplicações informáticas para suporte ao Balanced Scorecard

Bitam www.bitam.com Business Objects www.businessobjects.com Cognos www.cognos.com CorVu www.corvu.com Fiber FlexSI www.fiber.com.br Hyperion www.hyperion.com Information Builders www.informationbuilders.com InPhase www.inphase.com Open Ratings www.openratings.com Oracle www.oracle.com/global/pt PBViews www.pbviews.com Peoplesoft www.peoplesoft.com


154

Pilot Software www.pilotsoftware.com Procos www.procos.com/en Prodacapo www.prodacapo.com QPR www.qpr.com SAP www.sap.com SAS www.sas.com Vision Grupo Consultores www.visiongc.net

ANEXOS

• Engenharia de requisitos

• Fornecedores certificados

• Funcionalidades dos sistemas de informação certificados pelo B.S. Collaborative

• Inquéritos (Português e Inglês)

• Development Case

• Correspondência entre casos de uso e requisitos modelados

• Casos de uso

• Protótipo de interface

• Esquema de tabelas

• Dados dos inquéritos

• Terminologia UML

Anexo A

ENGENHARIA DE REQUISITOS

ANEXO A – ENGENHARIA DE REQUISITOS

161

ENGENHARIA DE REQUISITOS

A engenharia de requisitos está ligada à identificação, especificação, validação e documentação

dos requisitos para um sistema, de acordo com o contexto em que este vai ser usado. A tarefa principal

da engenharia de requisitos é determinar o que construir antes do início do desenvolvimento, para

prevenir custos acrescidos com a correcção de erros decorrentes de requisitos errados.

Citando Sommerville, “a engenharia de requisitos é o processo constituído pelas actividades

necessárias à criação de um documento de requisitos” (SOMMERVILLE, 2001). A engenharia de

requisitos é uma área que se preocupa com a orientação e sistematização do processo de definição de

requisitos, tendo como objectivo final a criação de um documento de requisitos, promovendo o

entendimento mútuo entre cliente e fornecedor quanto às características do sistema a desenvolver.

Adaptação feita ao esquema proposto por Sommerville

Figura 49 – Processo de Engenharia de Requisitos (SOMMERVILLE, 2001)

Como ilustrado na figura 49, o processo de engenharia de requisitos é composto por quatro

fases (SOMMERVILLE, 2001):

• ESTUDO DA VIABILIDADE DO SISTEMA

A primeira fase a realizar para qualquer novo sistema é o estudo da sua viabilidade.

Analisa-se se irá contribuir para o alcance dos objectivos da organização, faz-se um

levantamento da tecnologia necessária, uma estimativa dos custos totais e, por fim analisa-

se também se poderá ser integrado com outros sistemas presentes.

Estudo de Viabilidade

Levantamento de Requisitos

Especificação de Requisitos

Validação de Requisitos

Relatório de Viabilidade

Modelação do Sistema

Requisitos de Utilizador e Sistema

Documentação de Requisitos


162

Após esta fase concluída, a organização terá informação para decidir se vale a pena

implementar o sistema. Tal como refere Sommerville, embora esta fase pareça óbvia,

existem organizações que desenvolvem sistemas que não satisfazem os eus objectivos.

• LEVANTAMENTO DE REQUISITOS

Nesta fase os consultores identificam e recolhem os requisitos do sistema, junto dos

stakeholders21. Nestes requisitos incluem-se os domínios da aplicação, serviços que o

sistema deve executar e possibilitar, exigências de hardware22, desempenho pretendido,

etc.

O objectivo principal é recolher informação que permita perceber as necessidades do

cliente, identificando o que deve ser feito. Não interessa o “como?”.

• ESPECIFICAÇÃO DE REQUISITOS

Esta fase é caracterizada pela reunião e disseminação de toda a informação recolhida na

fase anterior, com o propósito de criar um primeiro documento de requisitos. Os

requisitos serão classificados em duas categorias: requisitos de utilizador e requisitos do

sistema.

• VALIDAÇÃO DE REQUISITOS

O processo de validação de requisitos têm como meta a verificação da sua consistência,

completude e adequação à realidade. É nesta fase que deve ser feito o esforço adicional

de identificação de problemas e erros com os requisitos, para prevenir erros futuros

aquando do desenvolvimento do sistema.

Como adaptação ao esquema proposto por Sommerville, considerou-se importante

acrescentar um ciclo (seta a ponteado) entre a fase de validação de requisitos e a actividade de

documentação dos requisitos. Isto porque, considera-se importante realizar todas as iterações

necessárias entre a validação e a documentação, até que todos os requisitos sejam aprovados sem

restrições. O documento de requisitos será um acordo entre cliente e fornecedor quanto às

características do sistema pretendido e um guia para os programadores.

21 O termo stakeholder designa todos aqueles que interagem directa ou indirectamente com o sistema. 22 O termo hardware caracteriza o equipamento físico de suporte aos sistemas de informação. Exemplo: servidores, estações de trabalho, impressoras, etc.


163

REQUISITOS

Tomando como referência a simples definição de Macaulay, um requisito pode ser definido

como “algo que um cliente necessita”, ou do ponto de vista de um programador como “algo que

necessita ser desenhado” (MACAULAY, 1996).

Apesar de existirem inúmeras definições para o termo “requisito”, o glossário de engenharia de

requisitos define-o como (IEEE, 1990):

• Uma condição ou capacidade necessária a um utilizador23 para resolver um problema ou

alcançar um objectivo.

• Uma condição ou capacidade suportada ou possuída por um sistema ou componente para

satisfazer um contrato, um padrão, uma especificação ou outro documento formal.

• Uma representação documentada de uma condição ou capacidade.

Para Wiegers, um requisito é uma propriedade que um produto tem de ter para proporcionar

valor ao cliente final (WIEGERS, 2003). Segundo Joseph Carr, requisitos são descrições de

propriedades, atributos, serviços, funções e comportamentos necessários num produto para realizar os

objectivos e propósitos de um sistema (CARR, 2000).

Concluindo e adoptando uma definição mais restrita aos sistemas de informação (SI), define-se

requisito como uma especificação de algo (determinada acção ou condição) que o utilizador necessita

no SI para resolver um problema ou alcançar um objectivo. Os requisitos dividem-se em duas

categorias: funcionais e não-funcionais; conforme estejam directamente relacionados com

funcionalidade requerida ao sistema ou com constrangimentos impostos ao sistema ou ao processo de

desenvolvimento, respectivamente.

REQUISITOS FUNCIONAIS

Os requisitos funcionais descrevem acções ou funções que o sistema deverá satisfazer (IEEE,

1990; SILVA e VIDEIRA, 2001; SOMMERVILLE, 2001). Segundo Wiegers, requisitos funcionais são

funcionalidades ou comportamentos que o sistema deve cumprir de acordo com determinadas

condições (WIEGERS, 2003).

A ideia de Bredemeyer relativamente à definição de requisitos funcionais é bastante semelhante

às anteriores, no entanto chama a atenção para dois aspectos: funcionalidade base – obrigatória em

23 O termo utilizador deve ser generalizado para todos os clientes do sistema (stakeholders) independentemente de serem utilizadores.


164

qualquer sistema para que este possa competir no domínio de produto onde está inserido; e

funcionalidade extra – características que diferenciam o sistema relativamente a outros presentes no

mesmo segmento (BREDEMEYER e MALAN, 2001b).

No âmbito dos sistemas de informação os requisitos funcionais são geralmente impostos pelos

utilizadores, apresentando-se alguns exemplos de seguida:

• O sistema deverá obrigar a autenticação dos utilizadores.

• Os documentos deverão ser identificados univocamente.

• O sistema deverá enviar uma mensagem de correio electrónico com a confirmação do

pedido de encomenda.

• No processo de introdução de encomendas, o sistema deverá avisar o utilizador quando

determinado cliente tiver pagamentos em atraso.

REQUISITOS NÃO-FUNCIONAIS

Estes requisitos são muitas vezes designados de requisitos de desempenho ou qualidade.

Geralmente estes requisitos ocorrem ao nível do desenho do sistema, no que concerne às limitações ou

padrões de qualidade impostos.

Tal como o seu nome indica, não estão directamente relacionados com a funcionalidade

requerida pelos utilizadores, mas influenciam o comportamento do sistema e consequentemente a

satisfação dos utilizadores.

Segundo a opinião de Sommerville, enquanto a não satisfação de um requisito funcional possa

causar degradação no sistema, a não satisfação de um requisito não-funcional poderá tornar o sistema

inoperacional (SOMMERVILLE, 2001).

Os requisitos não funcionais têm a ver com aspectos gerais do sistema, tais como: eficiência,

robustez, fiabilidade, distribuição, segurança, suporte de standards, suporte de base de dados,

usabilidade e manutenção (BREDEMEYER e MALAN, 2001a; SOMMERVILLE, 2001; WIEGERS,

2003). Alguns exemplos de requisitos não-funcionais:

• O desenho da base de dados deve estar apoiado no modelo relacional

• A página do site não pode demorar mais de 12 segundos a abrir completamente.

• O sistema deverá permitir exportação de dados para formatos standard, tais como texto ou

Microsoft Excel.

• As passwords devem estar encriptadas.

• A impressão dos relatórios deverá ser rápida (menos de 8 segundos).


165

PROBLEMAS COM A ESPECIFICAÇÃO DOS REQUISITOS

A pior consequência resultante de uma má especificação de requisitos é a correcção e, em

algumas vezes a repetição do trabalho já realizado. Wiegers estima que este trabalho adicional

decorrente da alteração dos requisitos pode consumir de 30% a 50% do custo total de

desenvolvimento de um sistema (WIEGERS, 2003). Uma pobre especificação de requisitos contribui

significativamente para as falhas nos sistemas, tais como: entregas atrasadas, aumento dos orçamentos

e perda de performance (CARR, 2000). Torna-se assim óbvio que os requisitos influenciam o custo de

um projecto e que as alterações de requisitos são uma das causas principais do aumento dos

orçamentos.

0

20

40

60

80

100

120

Requisitos Desenho Codif icação Testes Operacional

Fase de desenvolvimento

Cus

to p

ara

corr

igir

um d

efei

to

Figura 50 – Custo de correcção de um defeito de requisito (WIEGERS, 2003)

Como ilustrado na figura 50, embora uma alteração a requisitos conduza geralmente a

aumentos nos custos orçamentados, se a alteração for efectuada nas fases iniciais do projecto os custos

são mínimos quando comparados com a mesma alteração feita nas fases finais (fase de testes e

operacional).

Em qualquer projecto é necessário alterar requisitos e acrescentar outros, contudo a

necessidade de proceder a essas alterações deve-se a factores como (CARR, 2000):

• Requisitos que não reflectem as necessidades dos clientes do sistema

• Requisitos incompletos/ambíguos

• Introdução/Alteração requisitos


166

• Ambiguidade de requisitos

• Conflitos de requisitos

Wiegers acrescenta alguns factores que considera igualmente importantes (WIEGERS, 2003):

• Envolvimento insuficiente dos utilizadores

• Introdução de funcionalidade para além dos requisitos

Requisitos que não reflectem as necessidades dos clientes do sistema

Quando se recolhem requisitos é natural que tanto os utilizadores do sistema como os

consultores pensem nos requisitos de uma forma concreta, ao invés de uma forma abstracta (CARR,

2000). Na prática durante a descrição dos requisitos é usual indicar o comportamento pretendido para

o sistema, isto é indica-se o “como?”, ao invés de se indicarem as necessidades sentidas e

funcionalidades pretendidas, isto é “o quê?”.

Karl Wiegers refere também que muitas vezes os gestores de projecto fazem uma

especificação de requisitos minimalista, esperando detalhar os requisitos ao longo das fases de

desenvolvimento do sistema (WIEGERS, 2003). Isto poderá funcionar para sistemas pequenos ou

quando haja uma grande flexibilidade relativamente aos requisitos, contudo na maioria dos casos não

funciona tornando-se frustrante tanto para os programadores e como para os clientes que nunca mais

vêem o sistema em funcionamento.

Requisitos incompletos/ambíguos

A documentação dos requisitos é muitas vezes feita em linguagem natural, podendo surgir

palavras com diversos significados. Aquando da análise do conjunto de requisitos recolhidos, muitos

deles poderão passar despercebidos por desconhecimento de quem faz a análise. A ambiguidade é

provocada também pela imprecisão e detalhe insuficiente dos requisitos, cabendo aos programadores a

decisão final sobre a interpretação do requisito (WIEGERS, 2003). É pois importante a revisão dos

requisitos por várias pessoas e a constituição de cenários e testes, para ajudar à detecção de falhas nos

requisitos (CARR, 2000).

Introdução/Alteração requisitos

É prática comum, durante o ciclo de desenvolvimento dum sistema a ocorrência de mudanças

nos requisitos e até mesmo o levantamento de novos. Tais mudanças causam vários problemas como,


167

os atrasos no desenvolvimento do sistema, necessidade de alocar recursos adicionais, repetição de

trabalho já realizado, etc. Uma vez que raramente se documentam estas mudanças e respectivas

responsabilidades, muitas vezes inviabilizam-se total ou parcialmente alguns projectos.

Conflitos de requisitos

Uma das funções do gestor do projecto é a negociação dos requisitos com os seus clientes

(cada uma das áreas funcionais da organização) com vista à eliminação de conflitos e problemas

futuros (CARR, 2000).

Durante o processo de levantamento de requisitos é normal o surgimento de variados e

numerosos requisitos provenientes das diversas áreas funcionais da organização. Não sendo todos eles

compatíveis entre si e partindo do princípio de que geralmente ninguém está disposto a abdicar dos

seus requisitos, é ao gestor do projecto que cabe a tarefa de gerir os conflitos entre requisitos e efectuar

negociações com os respectivos stakeholders24. Geralmente a técnica passa por atribuir graus de

prioridade e importância aos requisitos, definindo depois aqueles que serão mais importantes para o

sistema no seu todo.

Envolvimento insuficiente dos utilizadores

Os utilizadores não têm percepção sobre a importância de assegurar a completa especificação

e qualidade dos requisitos. Por outro lado os programadores não valorizam o envolvimento dos

utilizadores nas fases de desenvolvimento do sistema, até porque muitas vezes pensam saber o que é

que os utilizadores necessitam (WIEGERS, 2003). O não envolvimento dos utilizadores nas fases de

concepção e desenvolvimento do sistema, é um adiamento dos problemas que irão surgir, acabando

por provocar atrasos na implementação do sistema. É muito importante que pelo menos um utilizador

de cada área funcional acompanhe o processo de desenvolvimento do sistema, porque torna mais

eficiente a detecção e correcção de erros da aplicação.

Introdução de funcionalidade para além dos requisitos

Karl Wiegers define este facto como “Gold plating”, ocorrendo quando o programador decide

integrar novas funcionalidades no sistema que não estão previstas como requisitos a satisfazer, mas que

eles acreditam serem úteis e valorizáveis pelo utilizador final. O que se verifica é que geralmente os

24 O termo stakeholder designa todos aqueles agentes que interagem directa ou indirectamente com o sistema.


168

utilizadores não valorizam este excesso de funcionalidade, tendo assim sido desperdiçado tempo

(WIEGERS, 2003).

QUALIDADE DE REQUISITOS

A especificação de bons requisitos é essencial para garantir a qualidade do sistema a

desenvolver. Um dos problemas fundamentais associados à especificação de requisitos reside na falta

de conhecimento para escrever requisitos. Os requisitos bem escritos são claros, simples e concisos.

Tomando em consideração o IEEE e Wiegers , a qualidade dos requisitos mede-se pelas

seguintes características(IEEE, 1990; WIEGERS, 2003):

• Completos – cada requisito deve descrever detalhadamente a funcionalidade pretendida

pelo utilizador. Deve conter toda a informação necessária ao programador para

implementar cada funcionalidade.

• Possíveis – deve ser possível implementar cada requisito tendo em conta as

potencialidades e limitações do sistema. Para evitar requisitos impossíveis de implementar,

deve haver um programador que acompanhe a fase de especificação dos requisitos.

• Necessários – cada requisito deve constituir uma funcionalidade que seja realmente

necessária. Todos os requisitos deverão ser recolhidos junto de fontes com autoridade

para tal.

• Prioridade – atribuir graus de prioridade aos requisitos ajuda a planear o

desenvolvimento e/ou implementação do sistema ao menor custo e tempo. A prioridade

de um requisito traduz a sua importância para o sistema no geral. Wiegers citando Covey

apresenta um quadro para ajudar atribuir graus de prioridade aos requisitos, baseando-se

em duas dimensões: importância e urgência (WIEGERS, 2003).

Importante Não Importante

Urgente Prioridade Alta Não considerar estes

Não Urgente Prioridade Média Prioridade Baixa

Tabela 6 – Prioridade de requisitos (WIEGERS, 2003)

• Não ambíguos – qualquer pessoa que leia requisitos deve fazer uma única interpretação

deles. O uso de linguagem natural para escrever os requisitos pode provocar ambiguidade,

porque o significado das palavras e das frases está dependente da interpretação de cada


169

pessoa. Uma solução para evitar a ambiguidade será a constituição de um glossário

com os conceitos que possam ter várias interpretações.

• Verificáveis – é importante que após o desenvolvimento ou implementação do sistema,

se possa verificar em que medida foi satisfeito cada requisito especificado previamente. Se

um requisito não for verificável, determinar a sua correcta implementação é uma questão

de opiniões do cliente e programador, não havendo estabelecida uma base objectiva para

análise (WIEGERS, 2003).


170

DOCUMENTAÇÃO DOS REQUISITOS

O documento de requisitos é o contrato oficial das especificações que servirão de base ao

desenvolvimento ou implementação do sistema (SOMMERVILLE, 2001). No documento, os

requisitos devem estar separados em requisitos de utilizador e requisitos do sistema, sendo

aconselhável a sua estruturação e formatação de acordo com padrões já definidos, como por exemplo

o IEEE/ANSI 830-1998.

Um outro aspecto que confere o alto grau de importância ao documento de requisitos é que

este: estabelece uma base para acordo entre cliente e fornecedor, ajuda a reduzir os custos de

desenvolvimento, fornece uma base para estimar custos e tempos, permite a verificação e validação do

sistema desenvolvido (IEEE, 1998).

Igualmente importante a ter bons requisitos é ter um bom documento de especificação de

requisitos, cujas características segundo Wiegers (WIEGERS, 2003) são as seguintes:

• Completo – a falta de requisitos ou informação necessária influencia negativamente o

desenvolvimento do sistema. Uma boa técnica contornar este problema é, aquando da

recolha dos requisitos, a focalização nas tarefas do utilizador.

• Consistente – é frequente a existência de requisitos que entram em conflito com outros

no mesmo documento. Os conflitos entre os requisitos devem ser resolvidos antes de se

passar à fase de desenvolvimento ou implementação do sistema. Uma técnica para

resolver os conflitos entre requisitos é, como já se disse atrás, definindo prioridades entre

eles.

• Modificáveis – é usual a alteração dos requisitos ao longo das fases de desenvolvimento e

implementação do sistema. Deve ser possível guardar o histórico das revisões realizadas

ao documento de requisitos.

• A norma IEEE (830-1998) estabelece que para um documento de requisitos ser

considerado modificável tem de estar organizado com índice, não ser redundante e ter

bem separado cada requisito dos outros.

• Rastreáveis – a rastreabilidade dos requisitos é importante porque permite determinar

indubitavelmente a origem de cada requisito. A rastreabilidade permite acompanhar a vida

de um requisito para trás e para diante, da origem até à implementação (GOTEL e

FINKELSTEIN, 1994).


171

É difícil criar um documento de requisitos que contenha todas as características anteriormente

descritas mas, o facto de tentar adoptá-las durante o processo de concepção do documento já ajuda a

produzir bons documentos de requisitos.

Por fim, a construção e organização do documento de requisitos devem seguir um modelo

pré-definido. Embora existam vários modelos disponíveis um dos mais utilizados é o definido pelo

IEEE (1998) cuja estrutura é a seguinte:

Figura 51 – Modelo para documento de especificação de requisitos(IEEE, 1998)

Embora este modelo não seja o ideal, contém os pontos principais para a criação de um bom

modelo. Reconhece-se que este modelo é generalista devendo por isso, ser adaptado a cada situação.

“Não existe uma forma única de escrever bons requisitos; o melhor professor é a experiência.

Os problemas enfrentados no passado ensinam muito.“ (WIEGERS, 2003)

Table of Contents 1. Introduction 1.1 Purpose 1.2 Scope 1.3 Definitions, acronyms, and abbreviations 1.4 References 1.5 Overview 2. Overall description 2.1 Product perspective 2.2 Product functions 2.3 User characteristics 2.4 Constraints 2.5 Assumptions and dependencies 3. Specific requirements 3.1 External interface requirements 3.2 Functional requirements 3.3 Performance requirements 3.4 Design constraints 3.5 Software system attributes 3.6 Other requirements Appendixes Index

Anexo B

FORNECEDORES CERTIFICADOS

ANEXO B – FORNECEDORES CERTIFICADOS

175

Fornecedor Endereço electrónico

Bitam www.bitam.com

Business Objects www.businessobjects.com

Cognos www.cognos.com

CorVu www.corvu.com

Fiber FlexSI www.fiber.com.br

Hyperion www.hyperion.com

Information Builders www.informationbuilders.com

InPhase www.inphase.com

Open Ratings www.openratings.com

Oracle www.oracle.com/global/pt

PBViews www.pbviews.com

Peoplesoft www.peoplesoft.com

Pilot Software www.pilotsoftware.com

Procos www.procos.com/en

Prodacapo www.prodacapo.com

QPR www.qpr.com

SAP www.sap.com

SAS www.sas.com

Vision Grupo Consultores www.visiongc.net

Anexo C

FUNCIONALIDADES DOS SISTEMAS DE INFORMAÇÃO

ANEXO C – FUNCIONALIDADES DOS SISTEMAS DE INFORMAÇÃO

179

CARACTERÍSTICAS FUNCIONAIS APRESENTAÇÃO DA INFORMAÇÃO ● Apresentação gráfica da informação (ex: gráficos, símbolos) ● Existência de descrições qualitativas (bom, mau) ● Parametrização de formatos de apresentação da informação por utilizador ● Sistema baseado em ambiente de janelas ● Possibilidade para os utilizadores construírem relatórios pessoais e personalizados ● Gráficos de Gantt (ex: gestão das iniciativas/actividades) ● Páginas pessoais personalizadas por utilizador, com a informação que lhe interessa

FLEXIBILIDADE ● Importação de informação proveniente de sistemas externos (folhas de cálculo, bases de dados, etc) ● Exportação de dados em diversos formatos (XML, texto, Ms Excel, etc) ● Assistentes para ajuda aos utilizadores na realização de determinadas tarefas ● Possibilidade de implementações totais (toda a organização) ou parcelares (departamentos, unidades de

negócio) da aplicação ● Opção para alterar o nome das perspectivas principais ● Criação e interligação de novas perspectivas com as principais ● Criação e interligação de novos scorecards com os existentes ● Quadros de bordo e scorecards personalizados por utilizador ● Definição de indicadores específicos (utilizador) e gerais (organização) ● Número ilimitado de objectivos, indicadores, metas e iniciativas. ● Opção para alterar a terminologia utilizada na aplicação

FUNCIONALIDADE ● Descrição da estratégia da organização ● Descrição da missão da organização ● Descrição da visão da organização ● Indicação das perspectivas padrão: financeira, clientes, processos internos e aprendizagem e crescimento ● Mapas de relações de causa-efeito (para objectivos, entre indicadores, etc) ● Definição dos objectivos estratégicos ● Ligação dos objectivos às perspectivas ● Estabelecimento de ligações entre objectivos, indicadores, metas e iniciativas ● Definição das fórmulas de cálculo dos indicadores ● Definição de várias metas para cada objectivo (meta interna, meta benchmark, etc) ● Objectivos interdepentes e interligados (diversas camadas) ● Possibilidade elaborar várias versões do mapa estratégico, para depois analisar a sua evolução ● Definição e atribuição de objectivos a utilizadores específicos ou grupos de utilizadores

COMUNICAÇÃO ● Introdução de comentários aos objectivos, indicadores, metas e iniciativas por parte dos utilizadores do sistema● Sistema de alertas sobre os indicadores, comentários introduzidos e mensagens ● Sistema interno para partilha de informação entre as pessoas (mensagens, formulários, correio interno, fóruns

de discussão) ● Apresentação de informação no contexto estratégico, graficamente e com palavras (ex: objectivos, indicadores) ● Apresentação gráfica da ligação entre os objectivos ● Existência de relatórios/modelos pré-definidos (perspectiva, indicadores vs metas, metas vs iniciativas) ● Possibilidade de ligar documentos, mensagens de correio, aplicações externas, etc., a indicadores e objectivos

ANÁLISE ● Relatório do desempenho actual e histórico de cada indicador relacionando também com as metas definidas ● Monitorização (gráfica e descritiva) do índice de eficácia/realização de cada objectivo, indicador, meta e

iniciativa ● Existência de vários tipos de indicadores/métricas


180

● Capacidade para desdobrar a informação em diversos níveis de detalhe ● Definição de pessoas responsáveis por iniciativas e indicadores ● Associação de sistema de recompensas às metas e iniciativas individuais ● Gráficos dinâmicos que permitam aceder-se aos dados de origem através do sistema de point-and-click ● Construção de diagramas dinâmicos pelos utilizadores através da técnica de drag-and-drop de vários campos

CARACTERÍSTICAS NÃO FUNCIONAIS

CARACTERÍSTICAS TÉCNICAS ● Funcionamento em várias plataformas ou sistemas operativos (Windows, Linux, Unix) ● Desenvolvimento do sistema em tecnologia WEB (HTML, ASP, PHP, .NET, J2EE) ● Sistema cliente/servidor ● Sistema multi-língua ● Sistema multi-empresa ● Sistema assente num Sistema de Gestão de Base de Dados Relacional (SQL Server, Oracle, Informix) ● Fácil de usar e intuitivo ● Funcionalidades de agendamento de tarefas (correio electrónico, extracção de dados, etc)

ADMINISTRAÇÃO ● Administração centralizada do sistema ● Possibilidade de arquivar informação do sistema actual para histórico ● Definição de políticas de segurança (utilizadores, permissões, acessos)

SERVIÇO ● Actualização constante do sistema (novas versões anualmente) ● Existência de linha de suporte contínuo (telefone, correio electrónico, página de Internet)

PREÇO ● Custo do contrato de manutenção anual ● Custo da licença por utilizador ● Custo do produto

Anexo D

INQUÉRITOS

ANEXO D – INQUÉRITOS

183

(PORTUGUÊS)


184

(INGLÊS)

Anexo E

DEVELOPMENT CASE

DEVELOPMENT CASE

Disciplinas (Workflows) Descrição Artefactos Fase Papéis FerramentasCompreensão do negócio da organização Documento da visão do negócio Concepção 30 % Gestor Projecto MS WordDiagrama de casos de utilização Modelo de casos de utilização Elaboração 14 % Consultor Rational Rose

Construção 1 %Transição 1 %

Descrição das funcionalidades do sistema Glossário Concepção 55 % Consultor MS WordObter consenso por parte dos utilizadores Modelo de casos de utilização Elaboração 22 % Consultor MS WordDiagrama de casos de utilização Construção 15 %Capturar vocabulário próprio Transição 1 %

Especificação técnica do sistema Documento da arquitectura de software Concepção 8 % Analista sistemas Rational RoseEspecificação total Elaboração 28 % Analista sistemas Rational RoseModelo de análise Construção 23 % Analista sistemas Rational RoseModelo de desenho Transição 1 % Analista sistemas Rational RoseProtótipo de interface Designer Interface Ms Visio

Definir a organização do código-fonte em módulos Modelo de implementação Concepção 1 % Programador Rational RoseImplementação das classes Elaboração 26 % Programador MS FrontPageTeste dos componentes desenvolvidos Construção 50 % Analista sistemas MS FrontPage

Transição 28 %Procura de erros na implementação de requisitos Plano de testes Concepção 1 % Consultor MS WordErros no produto desenvolvido Elaboração 2 % Cliente MS WordValidação dos requisitos e do produto Construção 2 % Consultor / Cliente MS Word

Transição 3 %Disponibilização do produto Plano de distribuição / integração Concepção 0 % Consultor MS WordInstalação do produto Documentação do sistema Elaboração 1 % Consultor MS Word

Manuais de formação Construção 4 % Consultor MS WordTransição 39 %

Selecção e aquisição de ferramentas Development Case Concepção 2 % Gestor Projecto MS WordDefinição dos principios metodológicos a seguir Elaboração 3 % Consultor MS WordDefinição do processo de desenvolvimento Construção 2 % Consultor MS Word

Transição 2 %Principios a aplicar na gestão de projectos Business case Concepção 3 % Gestor Projecto MS Word

Lista de riscos Elaboração 4 % Gestor Projecto MS WordPlano de desenvolvimento do software Construção 3 % Gestor Projecto MS Word

Transição 25 %Gestão do projecto

Modelação do negócio

Requisitos

Análise e desenho

Implementação

Testes

Instalação

Ambiente

Anexo F

CORRESPONDÊNCIA ENTRE CASOS DE USO E REQUISITOS MODELADOS

ANEXO F – CORRESPONDÊNCIA ENTRE CASOS DE USO E REQUISITOS

191

MODELO PRINCIPAL C. USO

● Definição da missão Descrever a missão definida para a organização. M1 ● Definição da visão Descrever a visão definida para a organização. M2 ● Definição da estratégia Descrever a estratégia definida para a organização. M3 ● Definição dos objectivos estratégicos Indicar os objectivos traçados. M4 ● Indicação de objectivos, indicadores, metas e iniciativas para cada um das perspectivas padrão

Atribuir a cada perspectiva os objectivos, indicadores, metas e iniciativas definidas.

M5



M6



M5


M7



M8



M9



M5



M5, M725



Não modelado



M5

COMUNICAÇÃO

C. USO

● Introdução de comentários aos objectivos, indicadores, metas e iniciativas por parte dos utilizadores do sistema

Possibilidade para os empregados introduzirem comentários ou sugestões sobre objectivos, indicadores, metas e iniciativas.

C1



C2



M8

● Possibilidade de ligar documentos, mensagens de correio, aplicações externas, etc., a indicadores e objectivos

Ligada aos objectivos e/ou indicadores deverá haver informação que permita avaliar a evolução do indicador no tempo e um histórico das medidas tomadas.

C3



C6

● Uso de informação qualitativa para Uso de informação qualitativa que descreva o nível de C6

25 O indicador é considerado específico por utilizador se lhe for atribuído um responsável. Senão, será considerado geral (organização) e por isso ligado a um objectivo estratégico.


192

descrever a evolução de indicadores (bom, mau, aumentou, baixou, positivo, etc)

evolução dos indicadores.



C4; C5

NEGÓCIO C. USO

● Relatório do desempenho actual e histórico de cada indicador


C4

● Monitorização (gráfica e descritiva) do índice de satisfação de cada objectivo


C4; N9 26



M5

● Capacidade para desdobrar a informação em diversos níveis de detalhe

Possibilidade do utilizador ir desdobrando a informação em diversos níveis de detalhe até encontrar a origem dos factos que observa.

Integração com ferramenta

externa ● Definição de empregados responsáveis por iniciativas e indicadores


M527



N6



Integração com ferramenta

externa ● Acompanhamento e medição do desempenho individual (por empregado) e respectiva contribuição para a satisfação dos objectivos estratégicos


C4

FLEXIBILIDADE

C. USO

● Importação de dados provenientes de sistemas externos (folhas de cálculo, bases de dados)


F1


Exportação de informação em diversos formatos. F2



Não modelado



F3

● Administração centralizada do sistema Administração centralizada do sistema. Não modelado ● Definição de políticas de segurança (utilizadores/permissões/acessos)


F4; F6



F5

C. USO

26 A modelação desta funcionalidade foi desdobrada em dois casos de utilização: o de relatórios (“C4”) e o de actualização da informação (“N9”), consistindo este último em guardar numa tabela específica a informação os valores actuais dos indicadores de forma a aumentar a rapidez da emissão de relatórios e actualização de formulários. Pois, se para cada actualização tivesse de ser consultada toda a base de dados influenciaria muito o desempenho da própria aplicação informática. 27 Esta funcionalidade está desenvolvida do caso de utilização “M5”, aquando da definição de indicadores e iniciativas.

ANEXO F – CORRESPONDÊNCIA ENTRE CASOS DE USO E REQUISITOS

193

CARACTERÍSTICAS TÉCNICAS Funcionamento em várias plataformas ou sistemas operativos (Windows, UNIX)


Não modelado

Desenvolvimento do sistema em tecnologia WEB (HTML, ASP, PHP, .NET, J2EE)


Não modelado

Sistema assente num Sistema de Gestão de Base de Dados Relacional (SQL Server, Oracle, Informix)

Sistema assente numa base de dados relacional. Não modelado

Fácil de usar e intuitivo Facilidade de utilização do sistema, cumprindo as regras de usabilidade.

Não modelado

Sistema baseado em ambiente de janelas Sistema baseado em ambiente de janelas e multi-tarefa conforme o princípio do MS Windows.

Não modelado

Sistema cliente/servidor Sistema cliente/servidor. Não modelado

Anexo G

CASOS DE USO

ANEXO G – CASOS DE USO

197

MODELO PRINCIPAL

(prioridade média e baixa) Figura 52 – Diagrama de casos de uso para categoria “Modelo Principal”



Uti lizador

(f rom Actores)

M6. Indicação das fórmulas de cálculo dos indicadores

M7. Mapa de relações de causa-efeito

M9. Atribuição de objectivos a uti lizadores específicos ou grupos

M8. Interl igação de objectivos em diversas camadas

Director

(f rom Actores)

M1. Definição da missão M2. Definição da visãoM3. Definição da estratégia

M4. Definição dos objectivos estratégicos

M5. Indicação de objectivos, indicadores, metas e iniciativas por perspectiva

Administrador

(f rom Actores)


198

Caso de Uso: M6. Indicação das fórmulas de cálculo dos indicadores Finalidade: Definir a fórmula de cálculo para cada indicador Actores: Director Prioridade: Média Pré-condições: Haver o indicador no sistema Pós-condições: N/A


1 Selecção da opção “Parâmetros” 2 Selecção da opção “Tabelas” 3 Selecção da opção “Indicadores” 4 Abrir formulário “Indicador” 5 Preenchimento dos dados 6 Pressiona o botão de “Gravar” 7 Grava os dados na base de dados. 8 Actualiza o formulário




Interfaces Formulário “Indicador”

Seleccionar opção "Tabelas"

Seleccionar opção "Indicadores"

Preenchimento dos dados

Pressiona botão "Gravar"

Pressiona botão "Cancelar"

Abrir formulário "Indicador"

Grava os dados na base de dados



SistemaDirector


199

Caso de Uso: M8. Interligação de objectivos em diversas camadas Finalidade: Criar um modelo visual que ilustre as relações entre os diversos objectivos Actores: Director Prioridade: Média Pré-condições: Haver objectivos criados Pós-condições: N/A


1 Selecção da opção “Parâmetros” 2 Selecção da opção “Mapas” 3 Selecção da opção “Relações entre objectivos” 4 Abrir formulário “Relações objectivos” 4 Construção do modelo, arrastando os objectivos da

caixa respectiva para o modelo principal. Estabelecimento de ligações através de ferramentas de desenho (seta).

5 Pressiona o botão de “Gravar” 6 Guarda o posicionamento e relações estabelecidas entre os objectivos.

7 Actualiza o formulário Fluxo alternativo

Acções dos actores Suporte TIC 1.1 Selecção da opção “Tabelas” 2.1 Selecção da opção “Objectivos” 2.2 Abrir formulário “Objectivo” 2.3 Pressionar botão “Mapa Relações” 5.1 O processo pode ser cancelado, bastando para isso o

actor pressionar o botão de cancelar. 5.2 Actualização do formulário, sem gravar os dados

na base de dados Interfaces

Formulário “Relações entre objectivos” Formulário “Objectivo”


Construção do modelo.

Movimentação dos objectivos desde uma caixa para o modelo principal, estabelecendo depois as ligações.



Seleccionar opção "Mapas"

Seleccionar opção "Relações entre objectivos"



Abrir formulário "Relações objectivos"



SistemaDirector


200

Caso de Uso: M9. Atribuição de objectivos a utilizadores específicos ou grupos Finalidade: Definir pessoas responsáveis por objectivos Actores: Director Prioridade: Média Pré-condições: Haver objectivos e utilizadores criados no sistema Pós-condições: N/A


1 Selecção da opção “Parâmetros” 2 Selecção da opção “Tabelas” 3 Selecção da opção “Objectivos” 4 Abrir formulário “Objectivo” 5 Preencher campo “Responsável” 6 Pressiona o botão de “Gravar” 7 Guarda os dados na base de dados




Interfaces Formulário “Objectivo”


Seleccionar opção "Objectivos"

Preencher campo "Responsável"





Abrir formulário "Objectivo"



SistemaDirector


201

COMUNICAÇÃO

(prioridade média e baixa)



C2. Sistema de alertasTempo

(f rom Actores)

C5. Criação de relatórios


(f rom Actores)

C1. Introdução de comentários aos objectivos, indicadores, metas e iniciativasColaborador

(f rom Actores)

C3. Ligação de informação extra a objectivos e indicadores

Director

(f rom Actores)

C4. Emissão de relatórios

Administrador

(f rom Actores)

Uti lizador

(f rom Actores)

C6. Uso de informação gráfica e qual itativa

Figura 53 – Diagrama de casos de uso para categoria “Comunicação”


202

Caso de Uso: C3. Ligação de informação extra a objectivos e indicadores Finalidade: Ligar diversa informação a objectivos e/ou indicadores individualmente. Actores: Colaborador; Director Prioridade: Média Pré-condições: Haver um modelo de scorecard completamente construído. Pós-condições: N/A


1 Seleccionar opção “Scorecard”. 2 Seleccionar opção “Organizacional” 3 Abrir formulário “Scorecard Organizacional” 4 Seleccionar componente no modelo (perspectiva) 5 Pressionar o botão “Anexos” 6 Abrir formulário “Anexos” 7 Escolher ficheiro a anexar 8 Pressionar botão “Anexar ficheiro” 9 Anexa ficheiro 10 Fecha formulário “Anexos” 11 Cria ícone no modelo




Interfaces Formulário “Scorecard Organizacional” Formulário “Anexos”



Seleccionar opção "Scorecard"

Pressionar botão de anexos

Escolher ficheiro a anexar

Pressionar botão "Anexar Ficheiro"

Seleccionar componente no modelo

Seleccionar opção "Organizacional"



Grava dados na base de

Fecha formulário "Anexos"

Cria ícone no modelo

Abrir Formulário "Scorecard Organizacional"

Abrir Formulário "Anexos"

SistemaDirector; Colaborador


203

Caso de Uso: C5. Criação de relatórios Finalidade: Criar relatórios Actores: Administrador do sistema Prioridade: Média Pré-condições: N/A Pós-condições: N/A


1 Seleccionar opção “Relatórios” 2 Seleccionar opção “Criação de relatórios” 3 Abrir formulário “Criação de relatórios” 4 Preenche o nome, descrição e título do relatório 5 Escolhe um modelo na caixa da direita 6 Apresenta campos na caixa da esquerda 7 Arrasta campos para o novo relatório 8 Mostra do relatório em construção 9 Pressiona botão de gravar 10 Grava o relatório


7.1 A qualquer momento pode ser pré-visualizado o relatório, pressionando o botão respectivo.

7.2 Emite o relatório


9.2 Não grava o relatório

Interfaces Formulário “Criação de relatórios”


Seleccionar opção "Criação de relatórios"

Preenche nome, descrição e título do relatório

Escolhe um modelo na caixa da direita

Arrasta campos para o novo relatório


Pressiona o botão de gravar



Relatório concluído?

Abrir formulário "Criação de relatórios"

Apresenta os campos na caixa da esquerda

Grava o relatório

Não

Sim



204

Caso de Uso: C6. Uso de informação gráfica e qualitativa Finalidade: Definir descrições e símbolos a utilizar por cada utilizador nos mapas da aplicação Actores: Utilizador Prioridade: Média Pré-condições: N/A Pós-condições: N/A


1 Seleccionar opção “Administração” 2 Seleccionar opção “Parâmetros do sistema” 3 Seleccionar opção “Formatos de apresentação da

informação” 4 Abrir formulário “Formatos Apresentação”

5 Preencher gama de valores 6 Indicar a descrição desejada 7 Indicar o caminho par ao símbolo 8 Pressiona botão de gravar 9 Grava dados na base de dados



9.2 Não grava os dados

Interfaces Formulário “Formatos Apresentação”


Seleccionar opção "Parâmetros do sistema"

Seleccionar opção "Formatos de apresentação da informação"

Preencher gama de valores

Indicar a descrição desejada

Indicar caminho (path) para o simbolo





Abrir formulário "Formatos Apresentação"


SistemaUtilizador


205

NEGÓCIO

Figura 54 – Diagrama de casos de uso para categoria “Negócio”

Uti lizador

(f rom Actores)



Director

(f rom Actores)

N1. Relatório do desempenho actual e histórico por indicador

N3. Existência de vários tipos de indicadores predefinidos por perspectiva

N4. Mecanismos de desdobramento da informação

N8. Medição do desempenho individual

N6. Sistema de recompensas para metas e iniciativas

N7. Ferramentas OLAP

N5. Definição de responsabilidades por indicadores e iniciativas

N2. Moni torização do índice de satisfação dos objectivos

Administrador

(f rom Actores)

N9. Actualização de informação

Tempo

(f rom Actores)


206

Caso de Uso: N6. Sistema de recompensas para metas e iniciativas Finalidade: Definir recompensas pelo alcance/realização de metas e iniciativas Actores: Administrador; Director Prioridade: Baixa Pré-condições: Haver iniciativa ou meta já definida Pós-condições: N/A


1 Seleccionar opção “Tabelas” 2 Seleccionar opção “Meta” ou “Iniciativa” 3 Abrir formulário “Meta” ou “Iniciativa” 4 Pressionar botão “Definir recompensa” 5 Abrir formulário “Recompensas” 6 Preencher dados 7 Pressionar botão de gravar 8 Guardar dados na base de dados



7.2 Não guarda os dados

Interfaces Formulário “Criação de relatórios”


Seleccionar opção "Meta"

Seleccionar opção "Iniciativa"

Pressionar botão "Definir recompensa"

Preencher Dados





Abrir formulário "Meta"

Abrir formulário "Iniciativa"

Abrir formulário "Recompensas"

Guardar dados na base de dados

SistemaAdministrador;Director


207

FLEXIBILIDADE

Figura 55 – Diagrama de casos de uso para categoria “Flexibilidade”

Uti lizador

(f rom Actores)


Administrador

(f rom Actores)

F2. Exportação de informação para diversos formatos

Director

(f rom Actores)

Sitemas externos

(f rom Actores)

F4 Definição de políticas de segurança

F5. Al teração da terminologia uti lizada na apl icação

F3. Arquivo de informação para histórico

F1. Importação de dados de sistemas externos


(f rom Actores)


208

Caso de Uso: F1. Importação de dados de sistemas externos Finalidade: Importar dados a partir de fontes externas à aplicação Actores: Administrador do sistema Prioridade: Média Pré-condições: Ficheiro a importar estar no formato correcto. Pós-condições: Importa os dados para o sistema.


1 Seleccionar opção “Administração” 2 Seleccionar opção “Importação de dados externos” 3 Abrir formulário “Importação” 4 Seleccionar origem de dados 5 Indica formato dos dados 6 Indica o separador presente no ficheiro de dados 7 Pressionar botão de importar 9 Importa os dados



7.2 Não importa os dados

Interfaces Formulário “Importação”


Seleccionar opção "Importação de dados externos"

Selecciona origem dos dados

Indica o formato dos dados

Indica separador presente no ficheiro de dados

Pressionar botão de importar




Abrir formulário "Importação"

Importa os dados



209

Caso de Uso: F2. Exportação de informação para diversos formatos Finalidade: Exportar informação (relatórios) para diversos formatos Actores: Administrador; Director Prioridade: Média Pré-condições: N/A Pós-condições: N/A


1 Seleccionar opção “Relatórios” 2 Seleccionar opção “Exportação de informação” 3 Abrir formulário “Exportação” 4 Escolher um relatório 5 Indicar formato pretendido 6 Indicar o destino do ficheiro a criar 7 Pressionar botão de exportar 8 Cria o ficheiro com a informação



7.2 Não exporta a informação

Interfaces Formulário “Exportação”


Seleccionar opção "Exportação de informação"

Escolher um relatório

Indicar o formato pretendido

Indicar o destino (local onde vai ser escrito o ficheiro"



Pressionar botão de exportar


Abrir formulário "Exportação"

Cria ficheiro com a informação

SistemaAdministrador; Director


210

Caso de Uso: F3. Arquivo de informação para histórico Finalidade: Transferência de informação desde o sistema actual para uma área de histórico Actores: Administrador do sistema Prioridade: Média Pré-condições: N/A Pós-condições: N/A


1 Seleccionar opção “Administração” 2 Seleccionar opção “Arquivo de informação” 3 Abrir formulário “Arquivo” 4 Seleccionar tipo de informação pretendida 5 Preencher data de arquivo 6 Pressionar botão de arquivar 7 Surge mensagem a pedir a confirmação da

operação 8 Arquiva a informação



6.2 Não arquiva a informação

7.1 Cancelamento do processo caso não seja confirmada a operação de arquivo.

7.2 Não arquiva a informação

Interfaces Formulário “Arquivo”


Seleccionar opção "Arquivo de informação"

Seleccionar tipo de informação pretendida

Preencher data de arquivo

Pressionar botão de arquivar


Conf irma operação?

Abrir formulário "Arquivo"

Arquivo da informação

SimNão



211

Caso de Uso: F5. Alteração da terminologia utilizada na aplicação Finalidade: Definir novos termos para os diversos componentes de um scorecard Actores: Administrador do sistema Prioridade: Média Pré-condições: N/A Pós-condições: N/A


1 Seleccionar opção “Administração” 2 Seleccionar opção “Parâmetros do sistema” 3 Seleccionar opção “Terminologia” 4 Abrir formulário “Terminologia” 5 Seleccionar scorecard e utilizador 6 Definir os novos termos nas caixas de texto respectivas 7 Pressionar botão de gravar 8 Grava os dados na base de dados



7.2 Não grava as permissões definidas

Interfaces Formulário “Terminologia”


Seleccionar opção "Parametros do sistema"

Seleccionar opção "Terminologia"

Escrever os novos termos nas caixas de texto respectivas



Confirma operaçãoCancela operação

Abrir formulário "Terminologia"

Grava os dados na base de dados

Seleccionar Scorecard e Utilizador


Anexo H

PROTÓTIPO DE INTERFACE

ANEXO H – PROTÓTIPO DE INTERFACE

215

VALORES DA ORGANIZAÇÃO Missão

GRAVAR CANCELAR

Visão

Estratégia

Objectivos Estratégicos





RELAÇÕES OBJECTIVOS

GRAVAR CANCELAR

OBJECTIVOS

NÍV

EL 5

N

ÍVEL

4

NÍV

EL 3

N

ÍVEL

2

N

ÍVEL

1

? Aumentar rentabilidade

? Aumentar volume de vendas

? Aumentar grau de satisfação

? Aumentar produtividade

? Desenvolver novos produtos

? Aumentar ROI em 3%

Aumentar renta-bilidade

Aumentar volume de vendas

Aumentar ROI em 3%


Aumentar pro-dutividade

Desenvolver novos produtos

? Baixar preços

? Baixar custos

? Melhoria contínua

? Motivação dos trabalhadores

? Formação

? Especialização

Baixar preços

Baixar custos

Melhoria contí-nua

Especialização Formação Motivação dos trabalhadores

? Aumentar vendas médias por cliente

? Diminuir prazos de entrega

Aumentar vendas médias por cliente

Diminuir prazos de entrega





NOTA: Nível 1 - Objectivos gerais Nível 5 - Objectivos específ icos


216


FÓRUM

CRIAR MENSAGEM

MENSAGENS

ANEXAR FICHEIRO

UTILIZADORES

ANEXOS

António Manuel Carlos Rogério José Paulo Gil

Manual de procedimentos Vendas da semana Manual da Qualidade

Programa da Formação

Tópicos Data Autor Resp. Vistos Última resposta

03/02/2005 António 03/02/2005 - 15:01 6 15

Cálculo do cash flow 16/01/2005 Manuel 17/01/2005 - 11:28 3 8

Objectivo - Aumento da produtividade 30/01/2005 Rogério 04/02/2005 - 11:28 11 32

PESQUISAR





CRIAÇÃO DE RELATÓRIOS

GRAVAR

CANCELAR





MODELOS

Objectivos vs Indicadores

Objectivos vs Metas

Indicadores vs Metas

Objectivos vs Iniciativas

Perspectivas

Gráficos

Scorecard Pessoal

Desempenho mensal

Tarefas

PRE-VISUALIZAR

NOVO MODELO

Nome

Descrição

Título

NOVO RELATÓRIOEtiqueta Campo Tabela Ordenação Tamanho Visível Total Agrupar

Nome Modelo

Descrição

Tipo

Nome

Valor

Estado

Unidade

Modelo

Modelo

Indicador

Indicador

Indicador

Indicador

15

25

3

15

9

3

5

Scorecard

Descrição

Tipo

Indicador

Valor

Estado

Unidade

CAMPOS

Nome Modelo

Descrição

Data criação

Tipo

Objectivo Nome

Valor mínimo Nome Indicador

Descrição

Fórmula

Unidade

Frequência

Descrição Iniciativa

Data Criação

Data Início

Data Fim

Valor

Realização (%) Tendência

Variação

Estado

Valor Meta

Pessoa Nome

Morada

Telemóvel

E-Mail

Recompensa

Descrição Valor

Recursos Nome

Descrição

Quantidade

Valor actual


217

UTILIZADORES

Nome

Senha

Perfil

Conta

Confirmação

GRAVAR

CANCELAR * x

Morada Telefone Telemóvel E-mail

ORGANIZAÇÃO

Organização

GRAVAR CANCELAR

Código Postal

Logotipo

Morada

NIF


218

PERÍODOS

GRAVAR CANCELAR

De Até Descrição

PERSPECTIVAS

Ordem

Nome

Tema

Tipo

GRAVAR

CANCELAR * x


219

ALERTA

GRAVAR CANCELAR

Utilizador

Envio E-mail Telemóvel

Informação Fórum Indicador

DADOS INDICADORES

Valor

Indicador

Data

GRAVAR

CANCELAR * x

Hora


220

RECURSOS

Quantidade

Recurso

GRAVAR

CANCELAR * x

Descrição

OBJECTIVOS

Nome

Responsável

Perspectiva

MAPA DE RELAÇÕES

GRAVAR

CANCELAR * x

INICIATIVAS

Descrição

Responsável

Criação Inicio Fim

Valor

Realização %

€

Datas

GRAVAR

CANCELAR * x


221

NOTAS

GRAVAR CANCELAR

Objectivo

Indicador

Perspectiva

Iniciativa

Financeira

Aumentar rentabilidade

ROCE

Aumentar margem de vendas

12/01/2005

António

Data

Utilizador Utilizador

Notas

RECOMPENSAS

GRAVAR CANCELAR

Objectivo

Meta Alcançar 3%

ROCE

150 € Valor

Pessoa

Descrição


222

ANEXOS

GRAVAR CANCELAR

Objectivo


Rentabilidade

Indicador

Anexos

ROCE

Manual.doc Estatisticas.xls Relatório Vendas.doc

ANEXAR FICHEIRO

IMPORTAÇÃO

CANCELAR

Formato

Origem

Separador

IMPORTAR FICHEIRO

ASCII XML EXCEL

ponto-virgula virgula outro:


223

EXPORTAÇÃO

CANCELAR

Formato

Relatório

Destino

EXPORTAR FICHEIRO

ASCII XML EXCEL

ARQUIVO

CANCELAR

Informação a arquivar

Arquivar até

ARQUIVAR

Objectivos

Metas

Indicadores

Iniciativas

Fórum


224

TERMINOLOGIA

CANCELAR EXPORTAR FICHEIRO

Originais Modificados TERMOS

Scorecard

Utilizador


Perspectiva Clientes

Perspectiva Interna

Perspectiva Ap. Crescimento

Objectivos

Metas

Indicadores

Iniciativas

Recompensa

Mapa Estratégico

Anexo I

ESQUEMA DE TABELAS

Anexo J

DADOS DOS INQUÉRITOS

ANEXO J – DADOS RECOLHIDOS DOS INQUÉRITOS

231

TABELAS DE DADOS DOS INQUÉRITOS (Codificação de cada questão do inquérito)

a1 Definição da missão a2 Definição da visão a3 Definição da estratégia a4 Definição dos objectivos estratégicos a5 Indicação de objectivos, indicadores, metas e iniciativas para cada um das perspectivas padrão a6 Indicação das fórmulas de cálculo dos indicadores a7 Estabelecimento de ligações entre objectivos, indicadores, metas e iniciativas a8 Mapa de relações de causa-efeito a9 Possibilidade de interligar objectivos em diversas camadas (em cascata) a10 Atribuição de objectivos a utilizadores específicos ou grupos de utilizadores a11 Definição de várias metas para cada objectivo (meta interna, meta benchmark, etc) a12 Possibilidade elaborar várias versões do mapa estratégico, para depois analisar a sua evolução a13 Criação e interligação de novas perspectivas com as principais a14 Criação e interligação de novos scorecards (pessoais) com os existentes a15 Definição de indicadores específicos (utilizador) e gerais (organização) a16 Assistentes para ajuda aos utilizadores na realização de determinadas tarefas a17 Possibilidade para inserir um número ilimitado de objectivos, indicadores, metas e iniciativas para qualquer perspectiva b1 Introdução de comentários aos objectivos, indicadores, metas e iniciativas por parte dos utilizadores do sistema b2 Sistema de alertas sobre os indicadores, comentários introduzidos e mensagens. b3 Mecanismos para partilha de informação entre os empregados (ex: mensagens, formulários, correio interno, fóruns) b4 Apresentação gráfica da ligação entre os objectivos b5 Possibilidade de ligar documentos, mensagens de correio, aplicações externas, etc., a indicadores e objectivos b6 Uso de informação gráfica (ex: semáforos, imagens, etc., na representação das tendências de evolução dos indicadores) b7 Uso de informação qualitativa para descrever a evolução de indicadores (bom, mau, aumentou, baixou, positivo, etc) b8 Existência de relatórios e modelos de relatórios pré-definidos (perspectiva, indicadores vs metas) b9 Possibilidade de os utilizadores construirem relatórios pessoais e personalizados b10 Possibilidade para personalizar a aplicação por utilizador (ex: páginas pessoais com indicadores individuais) b11 Uso de gráficos de Gantt para vários tipos de análise (ex: gestão das iniciativas/actividades) c1 Relatório do desempenho actual e histórico de cada indicador c2 Monitorização (gráfica e descritiva) do índice de satisfação de cada objectivo, indicador, meta e iniciativa c3 Existência de vários tipos de indicadores/métricas c4 Capacidade para desdobrar a informação em diversos níveis de detalhe (drill-down *) c5 Definição de empregados responsáveis por iniciativas e indicadores c6 Associação de sistema de recompensas às metas e iniciativas individuais c7 Construção de diagramas dinâmicos pelos utilizadores através da técnica de drag-and-drop** de vários campos c8 Análises multidimensionais (ferramentas OLAP) c9 Acompanhamento e medição do desempenho individual e respectiva contribuição para a satisfação dos objectivos d1 Importação de dados provenientes de sistemas externos (folhas de cálculo, bases de dados, etc) d2 Exportação de dados em diversos formatos (XML, texto, Ms EXCEL, etc) d3 Possibilidade de implementações totais (toda a organização) ou parcelares (departamentos, unidades de negócio) d4 Possibilidade de arquivar informação do sistema actual para histórico d5 Administração centralizada do sistema d6 Definição de políticas de segurança (utilizadores/permissões/acessos) d7 Funcionalidades de agendamento de tarefas (correio electronico, extracção de dados, etc) d8 Opção para alterar a terminologia utilizada (ex: nomes de perspectivas) e1 Funcionamento em várias plataformas ou sistemas operativos (Windows, Linux, UNIX) e2 Desenvolvimento do sistema em tecnologia WEB (HTML, ASP, PHP, .NET, J2EE) e3 Sistema assente num Sistema de Gestão de Base de Dados Relacional (SQL Server, Oracle, Informix) e4 Fácil de usar e intuitivo e5 Sistema baseado em ambiente de janelas e6 Sistema cliente/servidor e7 Sistema multi-língua


232

IMPORTÂNCIA ATRIBUÍDA ÀS DIVERSAS FUNCIONALIDADES

Q1 Q2 Q3 Q4 Q5 Q6 Q7 Q8 Q9 Q10 Q11 Q12 Q13 Q14 Q15 Q16 Q17 U F U F U F U F F F F F F U U U U

a1 3 2 4 5 4 2 2 2 4 3 5 1 5 4 4 5 2 a2 3 2 4 5 4 2 2 2 4 3 3 1 5 5 4 5 2 a3 4 3 5 5 5 4 1 4 5 3 5 1 5 5 4 1 5 a4 5 5 5 5 5 4 5 4 5 4 5 5 5 5 4 5 5 a5 5 5 5 5 5 5 5 4 5 4 5 5 5 5 4 5 5 a6 5 5 3 5 5 5 4 4 4 5 4 4 5 5 4 5 5 a7 5 5 5 5 5 5 5 4 5 4 5 4 5 5 4 5 5 a8 5 5 5 5 4 4 5 4 5 3 4 5 3 5 4 3 4 a9 5 1 0 5 5 4 4 4 5 4 3 4 5 5 4 5 4 a10 4 5 4 5 5 5 4 4 5 4 3 3 5 5 4 5 4 a11 4 4 3 5 5 1 3 4 5 4 5 3 5 5 4 1 4 a12 4 3 2 5 5 4 2 0 4 4 4 3 2 3 4 1 3 a13 3 5 2 5 5 4 5 3 3 4 3 4 5 3 4 3 2 a14 4 4 3 4 5 4 5 0 3 4 4 5 4 3 4 3 3 a15 3 4 2 4 4 3 5 4 4 4 5 4 5 3 4 5 4 a16 4 4 4 4 4 1 4 3 2 4 4 3 2 2 4 4 3 a17 2 5 3 4 5 5 4 4 5 4 5 5 5 2 4 5 4 b1 4 5 3 5 5 4 5 4 4 4 4 5 5 3 5 4 4 b2 4 5 3 5 5 4 4 0 3 5 4 1 1 4 5 4 3 b3 2 5 4 5 3 5 3 4 3 5 5 1 5 3 5 4 3 b4 5 5 4 5 4 4 5 4 4 5 3 4 2 4 4 4 4 b5 4 4 4 5 3 4 4 4 3 5 4 1 4 4 4 4 4 b6 5 5 3 5 4 5 4 4 3 5 5 3 5 3 4 5 5 b7 5 5 3 5 4 5 4 2 2 5 4 3 5 4 4 3 5 b8 4 5 4 4 4 4 4 3 4 5 4 4 5 5 3 5 4 b9 3 4 3 3 3 5 4 3 3 5 4 4 5 5 3 5 4 b10 3 3 2 3 4 1 3 3 3 5 3 1 3 4 3 4 4 b11 4 3 2 3 4 5 2 0 2 3 4 1 3 3 3 4 4 c1 5 5 3 5 4 5 5 4 5 5 5 4 5 5 5 5 5 c2 5 5 3 5 4 5 5 4 5 5 5 5 5 5 5 3 4 c3 5 5 2 5 5 5 4 4 5 5 5 5 5 5 5 5 4 c4 5 5 3 5 5 5 5 4 4 5 5 4 3 5 5 5 4 c5 4 5 3 5 4 5 5 4 2 5 5 4 4 5 5 5 5 c6 5 5 3 4 5 5 1 2 2 5 4 1 3 4 5 3 4 c7 5 2 3 5 3 5 3 4 2 3 3 1 2 3 5 4 4 c8 3 2 3 4 5 5 4 4 4 5 4 3 2 2 5 5 5 c9 4 3 3 5 5 5 1 2 5 4 4 4 4 3 5 5 4 d1 5 5 4 5 5 5 4 5 3 5 5 3 3 4 5 5 4 d2 5 5 4 5 5 4 4 5 3 5 5 4 3 4 5 5 4 d3 5 5 4 5 4 5 0 5 5 5 5 3 5 4 5 5 5 d4 5 3 2 5 5 5 3 5 4 5 4 3 5 4 5 5 5 d5 5 5 3 4 5 4 4 4 2 5 3 3 4 3 4 5 4 d6 5 5 3 5 5 5 4 5 3 5 5 4 5 5 4 5 5 d7 5 4 4 4 3 3 4 0 2 5 4 2 3 4 4 4 4 d8 4 4 2 4 4 1 4 4 3 3 4 1 4 3 3 4 4 e1 5 5 2 4 4 2 2 4 1 5 4 3 3 3 5 5 5 e2 5 5 3 5 4 4 4 4 4 5 5 2 5 5 5 5 4 e3 5 5 3 5 5 5 4 4 2 3 4 2 5 5 5 5 4 e4 5 5 5 5 5 5 5 5 5 5 5 4 5 5 5 5 5 e5 3 5 4 4 4 5 5 5 4 5 5 4 3 5 5 5 4 e6 3 1 3 5 3 5 5 5 1 5 4 4 1 5 5 5 4 e7 3 4 4 4 3 5 4 5 1 3 4 5 5 3 3 5 2

Q1…17 – questionário; U-Utilizador; F-Fornecedor; a1….e7 – questão do questionário Dados: 1- Importância mínima; 5- Importância máxima


233

FUNCIONALIDADES EXISTENTES

Q1 Q2 Q3 Q4 Q5 Q6 Q7 Q8 Q9 Q10 Q11 Q12 Q13 Q14 Q15 Q16 Q17 U F U F U F U F F F F F F U U U U a1 0 1 0 1 1 1 0 0 1 0 1 0 1 0 0 9 1 a2 0 1 0 1 1 1 0 0 1 0 0 0 1 0 0 9 1 a3 0 1 1 1 1 1 0 1 1 0 1 0 1 0 0 9 1 a4 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 9 1 a5 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 9 1 a6 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 9 1 a7 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 9 1 a8 1 1 1 1 0 1 1 1 1 0 0 1 0 1 1 9 1 a9 0 0 9 1 0 1 1 1 1 1 0 1 1 1 1 9 0 a10 0 1 1 1 1 1 1 0 1 1 0 1 1 1 1 9 1 a11 0 1 0 1 1 0 1 1 1 1 1 1 1 1 1 9 1 a12 0 1 0 1 1 1 0 1 1 1 0 1 1 1 0 9 0 a13 0 1 0 1 0 1 1 1 1 1 0 1 1 0 1 9 0 a14 0 1 0 1 1 1 1 1 1 1 1 1 1 0 1 9 1 a15 0 1 0 1 1 1 1 1 1 1 1 1 1 0 1 9 1 a16 1 1 0 1 0 0 1 0 1 1 1 1 1 1 0 9 0 a17 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 9 1 b1 1 1 1 1 1 1 1 1 1 1 0 1 1 0 1 9 1 b2 0 1 0 1 0 1 0 1 1 0 0 0 0 1 1 9 1 b3 0 1 0 1 0 1 0 0 1 1 1 0 1 0 1 9 1 b4 1 1 1 1 0 1 1 1 1 1 0 1 0 1 1 9 1 b5 0 1 0 1 0 1 1 0 1 1 1 0 1 1 0 9 1 b6 1 1 1 1 0 1 1 1 1 1 1 1 1 1 1 9 1 b7 1 1 1 1 0 1 1 0 1 1 1 1 1 1 1 9 1 b8 1 1 0 1 0 1 1 1 1 1 1 1 1 1 1 9 1 b9 0 1 0 1 0 1 1 1 1 1 1 1 1 0 1 9 1 b10 0 1 0 1 0 0 0 0 1 1 0 0 1 0 1 9 1 b11 1 1 0 1 0 1 0 9 1 0 0 0 0 0 0 9 0 c1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 9 1 c2 1 1 1 1 0 1 1 1 1 1 1 1 1 1 1 9 1 c3 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 9 1 c4 0 1 0 1 1 1 1 1 1 1 1 1 1 1 1 9 1 c5 0 1 1 1 0 1 1 1 1 1 1 1 1 1 1 9 1 c6 0 1 0 1 1 1 0 0 1 1 1 0 1 0 1 9 0 c7 0 1 0 1 0 1 1 1 1 0 0 0 0 0 9 9 1 c8 0 1 0 1 0 1 0 1 1 1 1 1 0 0 9 9 1 c9 0 1 0 1 1 1 0 0 1 1 1 1 1 0 1 9 1 d1 1 1 0 1 1 1 1 1 1 1 1 1 1 1 1 9 1 d2 0 1 0 1 1 1 1 1 1 1 1 1 1 1 1 9 1 d3 0 1 1 1 0 1 9 1 1 1 1 1 1 0 1 9 1 d4 0 1 0 1 1 1 0 1 1 1 1 1 1 0 1 9 1 d5 1 1 0 1 1 1 0 1 1 1 1 1 1 1 1 9 1 d6 0 1 1 1 0 1 0 1 1 1 1 1 1 0 1 9 1 d7 0 1 0 1 0 1 0 1 1 1 1 0 1 1 1 9 1 d8 1 1 1 1 0 0 1 1 1 0 0 0 1 0 1 9 1 e1 0 1 0 1 0 0 0 1 1 1 1 1 1 0 9 9 1 e2 0 1 0 1 0 1 0 1 1 1 1 1 1 1 9 9 1 e3 0 1 0 1 0 1 0 1 1 0 0 1 1 1 9 9 1 e4 1 1 0 1 0 1 1 1 1 1 1 1 1 0 1 9 1 e5 0 1 1 1 0 1 1 1 1 1 1 1 1 1 1 9 1 e6 0 0 0 1 0 1 0 1 0 1 1 1 0 1 9 9 1 e7 0 1 0 1 0 1 1 1 9 0 0 1 1 0 1 9 1

Q1…17 – questionário; U-Utilizador; F-Fornecedor; a1….e7 – questão do questionário Dados: 0- Funcionalidade não existente; 1- Funcionalidade existente; 9- Não respondeu


234

Funcionalidades Utilizadas

Q1 Q2 Q3 Q4 Q5 Q6 Q7 Q8 Q9 Q10 Q11 Q12 Q13 Q14 Q15 Q16 Q17 U F U F U F U F F F F F F U U U U a1 0 1 0 1 1 1 0 0 1 0 1 0 1 0 0 9 0 a2 0 1 0 1 1 1 0 0 1 0 0 0 1 0 0 9 0 a3 0 1 1 1 1 1 0 1 1 0 1 0 1 0 0 9 1 a4 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 9 1 a5 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 9 1 a6 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 9 1 a7 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 9 1 a8 1 1 1 1 0 1 1 1 1 0 0 1 0 1 1 9 1 a9 0 0 9 1 0 1 1 1 1 1 0 1 1 1 1 9 0 a10 0 1 1 1 1 1 1 0 1 1 0 0 1 0 1 9 1 a11 0 1 0 1 1 0 0 1 1 1 1 0 1 1 1 9 1 a12 0 1 0 1 1 1 0 1 1 1 0 0 1 1 0 9 0 a13 0 1 0 1 0 1 1 1 1 1 0 1 1 0 1 9 0 a14 0 1 0 1 1 1 1 1 1 1 1 1 1 0 1 9 0 a15 0 1 0 1 1 1 1 1 1 1 1 1 1 0 1 9 0 a16 1 1 0 1 0 0 1 0 1 1 1 1 1 1 0 9 0 a17 0 1 9 1 1 1 1 1 1 1 1 1 1 1 1 9 1 b1 9 1 0 1 1 1 1 1 1 1 0 1 1 0 1 9 1 b2 0 1 0 1 0 1 0 0 1 0 0 0 0 0 1 9 0 b3 0 1 0 1 0 1 0 0 1 1 1 0 1 0 1 9 1 b4 1 1 1 1 0 1 1 1 1 1 0 1 0 1 1 9 1 b5 0 1 0 1 0 1 0 0 1 1 1 0 1 1 0 9 1 b6 1 1 1 1 0 1 1 1 1 1 1 1 1 1 1 9 1 b7 1 1 0 1 0 1 1 0 1 1 1 1 1 1 1 9 1 b8 1 1 0 1 0 1 1 1 1 1 1 1 1 1 1 9 1 b9 0 1 0 1 0 1 1 1 1 1 1 1 1 0 1 9 0 b10 0 1 0 1 0 0 0 0 1 1 0 0 1 0 0 9 1 b11 1 1 0 1 0 1 0 9 1 0 0 0 0 0 0 9 0 c1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 9 1 c2 1 1 1 1 0 1 1 1 1 1 1 1 1 1 1 9 1 c3 1 1 9 1 1 1 1 1 1 1 1 1 1 1 1 9 1 c4 0 1 0 1 1 1 1 1 1 1 1 1 1 1 1 9 1 c5 0 1 0 1 0 1 1 1 1 1 1 1 1 1 1 9 1 c6 0 1 0 1 1 1 0 0 1 1 1 0 1 0 1 9 0 c7 0 1 0 1 0 1 0 1 1 0 0 0 0 0 9 9 1 c8 0 1 0 1 0 1 0 1 1 1 1 1 0 0 9 9 1 c9 0 1 0 1 1 1 0 0 1 1 1 1 1 0 1 9 0 d1 1 1 0 1 1 1 1 1 1 1 1 1 1 1 1 9 0 d2 0 1 0 1 1 1 1 1 1 1 1 1 1 1 1 9 1 d3 0 1 1 1 0 1 9 1 1 1 1 1 1 0 1 9 1 d4 0 1 0 1 1 1 0 1 1 1 1 1 1 0 1 9 1 d5 1 1 0 1 1 1 0 1 1 1 1 1 1 1 1 9 1 d6 0 1 1 1 0 1 0 1 1 1 1 1 1 0 1 9 1 d7 0 1 0 1 0 1 0 1 1 1 1 0 1 0 1 9 0 d8 1 1 1 1 0 0 1 1 1 0 0 0 1 0 1 9 1 e1 0 1 0 1 0 0 0 1 1 1 1 0 1 0 9 9 1 e2 0 1 0 1 0 1 0 1 1 1 1 1 1 1 9 9 1 e3 0 1 0 1 0 1 0 1 1 0 0 1 1 1 9 9 1 e4 1 1 0 1 0 1 1 1 1 1 1 1 1 0 1 9 1 e5 0 1 1 1 0 1 1 1 1 1 1 1 1 1 1 9 1 e6 0 0 0 1 0 1 0 1 9 1 1 1 0 1 9 9 1 e7 0 1 0 1 0 1 1 1 9 0 0 1 1 0 1 9 1

Q1…17 – questionário; U-Utilizador; F-Fornecedor; a1….e7 – questão do questionário Dados: 0- Funcionalidade não utilizada; 1- Funcionalidade utilizada; 9- Não respondeu


235

Dados gerais

Sexo Idade Experiência com a aplicação

(anos) Satisfação geral (0-Minima; 5-Máxima)

Q1 M 34 0,5 4 Q2 M 36 2 5 Q3 M 28 1 3 Q4 M 42 4 4 Q5 M 42 3 3 Q6 M 0 2 5 Q7 M 35 2 4 Q8 M 0 2 4 Q9 M 49 2 5 Q10 M 45 5 4 Q11 M 48 5 4 Q12 M 35 0,5 5 Q13 M 35 6 5 Q14 M 33 3 1 Q15 M 46 3 3 Q16 M 47 Q17 F 25 1 4

Anexo K

TERMINOLOGIA UML

ANEXO K – TERMINOLOGIA UML

239

DIAGRAMA DE CASOS DE USO

Os casos de uso representam uma técnica de recolha dos requisitos funcionais de um sistema. A sua finalidade é a descrição das acções típicas entre os utilizadores de um sistema e o próprio sistema, ilustrando o modo de funcionamento do sistema. Um actor representa um papel desempenhado por uma pessoa (ou sistema externo) que intervém na realização do caso de uso.

DIAGRAMA DE ACTIVIDADES

Os diagramas de actividades são uma técnica para descrever procedimentos, processos de negócio e fluxos. Descrevem o comportamento dum sistema através da representação de uma sequência de actividades, que podem ocorrer de forma condicional ou paralela.

DIAGRAMA DE CLASSES

O diagrama de classes modela a estrutura de um sistema, descrevendo os diversos tipos de objectos (entidades) do sistema e relacionamentos entre si. É o principal diagrama que representa os dados a serem manipulados pelo sistema.

DIAGRAMA DE SEQUÊNCIA

Um diagrama de sequência captura o comportamento de um cenário, numa óptica temporal. Mostra um conjunto de objectos e respectivas mensagens que são passadas entre eles, para a realização de um caso de uso.


240

DIAGRAMA DE COLABORAÇÃO

O diagrama de colaboração mostra as relações entre objectos que desempenham diferentes papéis. Usa números para representar a sequência normal de operações entre objectos que participam numa interacção.

DIAGRAMA DE ESTADOS

O diagrama de estados representa o comportamento interno de um determinado objecto. Apresenta os possíveis estados de um objecto, as correspondentes transições e as operações que são executadas dentro de um estado.

DIAGRAMA DE COMPONENTES

O diagrama de componentes modela a organização do código, incluindo código fonte, executável, binário, procedimentos de código e documentos.

DIAGRAMA DE ARQUITECTURA

O diagrama de implementação mostra a organização física do sistema, representando que componentes de software correm em cada componente de hardware

Figura 56 – Principais diagramas da linguagem UML

ria.ua.pt · 2016. 3. 8. · 5.10 Plano de Distribuição ... Figura 12 – Actividades da tarefa...

Documents

Transcript of ria.ua.pt · 2016. 3. 8. · 5.10 Plano de Distribuição ... Figura 12 – Actividades da tarefa...