Desenvolvimento de Sistemas de Informação

Sistemas de Informação de 
Apoio à Gestão
Gestão de Empresas
Telmo Bento - tbento@ismai.pt

Sistemas de Informação de Apoio à Gestão
Informação
4. Desenvolvimento de Sistemas de
2
dos Sistemas de Informação

4.1. Redesenhar as Organizações Através
3
4. Desenvolvimento de Sistemas de Informação
4.1. Redesenhar as Organizações Através dos Sistemas de Informação
• A introdução de um novo sistema de informação envolve muito

mais do que actualizações de hardware e software.

• Inclui mudanças em:

• Empregos;

• Técnicas;

• Gestão;

• Organização.
4
• As tecnologias de informação podem promover vários níveis da

mudança das organizações.
5
•
A mudança mais comum nas organizações habilitadas a utilizar

as tecnologias de informação, é a automatização.

• As alterações iniciais são o desenvolvimento de tecnologias de

informação de auxílio aos funcionários, possíbilitando a que as
suas funções sejam efectuadas de forma eficaz e eficiente.
6
• Um modo mais profundo de mudança organizacional,

precedente à automatização, é a racionalização de processos.

• A automatização revela frequentemente algumas falhas na

produção, o que faz com que a disposição dos processos seja
mais complicada.

• A racionalização de processos é a simplificação e explicação dos

processos da organização.
7
• A racionalização de processos é muitas vezes encontrada em

programas que efectuam melhoria de produtos, serviços e
operações de modo contínuo.
8
• Um tipo de mudança organizacional mais poderoso é o

redesenho dos processos da organização.

• No redesenho dos processos da organização, os processos são

analisados, simplificados e redesenhados.
9
• O redesenho dos processos da organização redesenha e

reorganiza o fluxo de trabalho, combinando medidas para

eliminar o desperdício, a repetição e tarefas intensivas em papel.

• É muito mais ambicioso que a racionalização de processos,

pressupondo uma nova visão de como os processos são
organizados.
10
• Uma forma mais radical de mudança organizacional é a

mudança de paradigma.
• A mudança de paradigma envolve repensar a natureza do

negócio e da organização.
11
• A mudança de paradigma falha frequentemente, devido à

extensão da mudança, o que a torna difícil de orientar.

• Porque é que tantas organizações efectuam mudanças radicais?

• Devido às recompensas da mudança serem muito

compensatórias.
12
•
Grande parte das organizações têm tentado melhorar os seus

processos de negócios com as tecnologias de informação.

• Algum destes sistemas implicam uma mudança de processos

incremental, mas noutros casos é necessária uma mudança mais
vasta.
13
•
A gestão de processos oferece várias ferramentas e

metodologias para analisar os processos existentes, projectar
novos processos e optimizar os processos.

• A gestão de processos nunca está concluída, devido ao facto do

melhoramento de processos requerer uma mudança contínua.
14
• As organizações que efectuam a gestão de processos passam

pelos seguintes passos:

• Identificação dos processos a mudar;

• Análise dos processos existentes;

• Projectar novos processos;

• Implementar novos processos;

• Avaliação contínua.
15
• Identificação dos processos a mudar:

• Uma das mais importantes decisões estratégicas que uma

organização pode fazer é:

• em vez de decidir como utilizar o computador para

melhorar a organização, entender que processos da
organização precisam de ser melhorados.
16
• Identificação dos processos a mudar:

• Pode ser gasto tempo e dinheiro considerável na

melhoraria de processos da organização que não vão
trazer grande vantagem à organização.

• Os gestores precisam de determinar que processos da

organização são mais importantes, e como a melhoria
destes processos beneficiará a organização.
17
• Análise dos processos existentes:

• Os processos existentes devem ser modelados e

documentados, tendo em conta as entradas, as saídas, os
recursos e as sequências das ações.

• A equipa do projecto de processos identifica os passos

redundantes, a utilização excessiva de papel, obstáculos e
outras ineficiências.
18
• Projectar novos processos:

• Quando os processos existentes se encontram

documentados e avaliados em termos de tempo e custo, a
equipa de projecto de processos vai tentar melhorar o
processo desenhando um novo.

• Um novo processo simplificado será documentado e

modelado para comparação com o processo antigo.
19
• Projectar novos processos:

• Os novos processos precisam de ser justificados

mostrando por quanto serão reduzidos o tempo e
dinheiro ou mostrando a melhoria do serviço ao cliente.
20
• Implementar novos processos:

• Quando o novo processo se encontrar modelado e

analisado, este deve ser traduzido em novos conjuntos de
procedimentos e regras de trabalho.

• Os novos processos e os sistemas de suporte são

lançados na organização.
21
• Implementar novos processos:

• Quando a organização começa a utilizar os processos, os

problemas devem ser descobertos e tratados.

• Os funcionários que trabalham com os processos podem

recomendar melhorias aos mesmos.
22
• Avaliação contínua:

•
Quando os processos são implementados e optimizados,

estes necessitam de ser continuamente avaliados.

• Porquê?
• Os processos podem deteriorar-se ao longo do tempo ou

perder a sua eficiência, se a organização sofrer outras
mudanças.
23
• Apesar de grande parte das melhorias dos processos nas

organizações serem incrementais e contínuos, há ocasiões onde
é efectuada uma mudança mais radical.

• O exemplo a seguir demonstrará uma mudança mais radical.
24
25
26
• A mudança estudada no exemplo sucedeu na realidade, quando

a Amazon desafiou as livrarias tradicionais com o modelo de

venda online.

• Com a mudança radical da forma como se compram ou vendem

livros, a Amazon e outras livrarias online alcançaram
importantes níveis de eficiência, redução de custo e uma
maneira totalmente nova de operar neste negócio.
27
•
Os administradores das organizações, descrevem que a maior

barreira para uma mudança de processos bem sucedida é a
cultura da organização.

• Os funcionários não gostam de rotinas com que não estão

familiarizados e tentam frequentemente resistir às mudanças.
28
•
Esta situação acontece mais frequentemente quando as

mudanças são muito ambiciosas e vastas.

• A gestão da mudança não é simples nem intuitiva, e as

organizações que se comprometem com grandes melhorias de
processos, precisam de uma boa estratégia de mudança.
29
Sistemas de Informação
4.2. Ciclo de Vida do Desenvolvimento de
30
4.2. Ciclo de Vida do Desenvolvimento de Sistemas de Informação
• De modo a ser possível resolver os problemas existentes no

desenvolvimento de sistemas de informação, verificou-se uma
crescente consciencialização da importância de algumas fases

como a análise de requisitos e o desenho.

• Este facto impulsionou o aparecimento de uma nova filosofia

designada “desenvolvimento estruturado”, a qual defende que o
desenvolvimento deve ser sistemático e com recurso a uma
concepção top-down.
31
• Hoje em dia é comum falar do ciclo de vida do desenvolvimento

de sistemas de informação.

• Existem três tipos de ciclos de vida:

• Desenvolvimento sequencial linear;

• Desenvolvimento evolutivo;

• Desenvolvimento incremental.
32
• O Desenvolvimento Sequencial:

• Segue uma abordagem sistemática e linear ao longo da

vida do projeto;

• Avança o desenvolvimento entre fases sequenciais;

• O sistema está pronto no final de todas as fases.

• O modelo em cascata é um exemplo deste tipo.
33
• O Desenvolvimento Evolutivo:

• O sistema é construído em diferentes etapas;

• Em cada etapa é construída uma versão do sistema;

• O sistema vai evoluir de etapa para etapa;

• Cada versão satisfaz os requisitos conhecidos;

• Os utilizadores avaliam cada versão e clarificam mais
requisitos para a construção da nova versão.

• O modelo espiral é um exemplo deste tipo.
34
• O Desenvolvimento Incremental:

• O sistema é construído em várias versões;

• Cada versão tem um conjunto específico de funções;

• Na primeira versão, são desenvolvidas as funções mais
importantes;

• O utilizador avalia as versões desenvolvendo um plano
para o novo incremento;

• Este processo é repetido até o sistema estar completo.
35
• O Desenvolvimento Incremental:

• Esta aproximação combina o desenvolvimento sequencial com a

filosofia de prototipagem.

• Cada sequência linear produz um protótipo que será utilizado e

avaliado pelos utilizadores.
36
•
O desenvolvimento incremental e o desenvolvimento

evolutivo são muitas vezes confundidos.

• No entanto:

• No desenvolvimento evolutivo, em cada etapa é criada uma

nova versão de todo o sistema, conforme os requisitos se vão
tornando mais claros.

• No desenvolvimentos incremental, em cada etapa adicionam-

se algumas funcionalidades à versão anteriormente construída, a
qual não é alterada.
37
Sistemas de Informação
4.3. Paradigmas do Desenvolvimento de
38
4.3. Paradigmas do Desenvolvimento de Sistemas de Informação
• Modelo em Cascata:

• O modelo em cascata foi o primeiro paradigma que tentou

disciplinar e sistematizar o DSI.
39

• A cada rectângulo corresponde uma fase do processo de DSI, e

as setas mostram a possibilidade de existência de interação

entre as fases.
40
•
Modelo em Cascata:
• O estudo de viabilidade consiste na

análise do problema existente,

apontando soluções alternativas.
• Resulta numa proposta descrita em termos técnicos,

operacionais e económicos.

• Esta proposta poderá ou não ser aceite.
41
• A identificação de requisitos consiste

em fazer uma recolha exaustiva de

informação sobre o sistema a
desenvolver:
• Requisitos funcionais;

• Requisitos não funcionais;

• Restrições a que é preciso obedecer;

• Volume e tipo de informação a ser processada;

• Problemas e falhas existentes.
42
• A análise detalhada consiste em

desenvolver uma especificação dos

requisitos, construindo modelos
consistentes.
• O desenho desenvolve a arquitetura do sistema, especificando

as suas componentes, o modelo físico de dados e os seus
algoritmos.
43
• A codificação traduz as especificações obtidas no desenho em

linguagem de programação e cria documentação, como os
manuais de utilizador e de instalação.
44
• A implementação e os testes
pressupõem:
• A execução de testes ao sistema;

• A definição de uma forma de conversão na organização do
sistema antigo para o novo.

• A formação dos utilizadores.
45
• Várias críticas são feitas a esta aproximação:

• A falta de atenção prestada ao contexto do negócio para

qual o sistema é desenvolvido;

• O tempo associado com a progressão das atividades;

• A ausência de envolvimento do utilizador no processo de
desenvolvimento.
46
• Prototipagem:
• Um protótipo é uma versão experimental de um sistema,

construído com o objectivo de ser explorado, experimentado e

avaliado.
47
• Prototipagem:
• Uma primeira versão do sistema é construída, sendo melhorada

através de sucessivas iterações até que este reflita

corretamente o sistema requerido.
48
• Prototipagem:
• Estas sucessivas iterações consistem em verificações por parte

dos utilizadores do sistema, sugerindo alterações a introduzir.
49
•
Prototipagem:
• A prototipagem permite aumentar a participação e interesse

dos utilizadores no processo de desenvolvimento.

• Constroem-se sistemas onde os requisitos podem estar mal

definidos, o que vai ajudar na definição e clarificação dos
mesmos.

• A participação dos utilizadores é também um excelente

contributo para o desenho da interface.
50
• Modelo V:
• O Modelo V divide o processo de DSI em duas partes:

• Especificação;

• Verificação e validação.
51
• Modelo V:
• Neste diagrama as caixas rectangulares representam as fases e

as ovais representam os produtos, isto é, o resultado

documentado de uma revisão da fase anterior. Estes serão a
base para a próxima fase.
52
• Modelo V:
53
• Modelo V:
•
Este modelo sugere que nenhuma fase pode considerar-se

completa até que o documento produzido esteja completo.

• Não pode ser iniciada uma fase posterior se o documento da

anterior não estiver completo.

• Esta aproximação não é realista devido ao aspecto dinâmico dos

requisitos.
54
• Modelo Espiral:
• O modelo espiral foi desenvolvido para incluir os melhores

aspectos do ciclo convencional e da prototipagem.

• Acrescenta uma nova fase inexistente nos modelos anteriores: a

análise de risco.
55
56
•
Modelo Espiral:
• O modelo define quatro atividades apresentadas pelos quatro

quadrantes do diagrama:

• Planeamento;

• Análise de risco;

• Engenharia;

• Avaliação.

• Cada ciclo representa uma sequência de passos.
57
• Modelo Espiral:
• Cada ciclo termina com uma revisão que engloba os produtos

desenvolvidos em fases anteriores e o planeamento para o ciclo
seguinte.

• Uma das vantagens deste modelo é a consideração dos riscos

em todas as etapas do processo, o que permite reduzir riscos
antes que estes se tornem problemáticos.
58
• Rapid Application Development:
•
O RAD tem como objectivo um ciclo de desenvolvimento

muito curto.

• Este paradigma pressupõem que nem todos os requisitos

possam ser identificados e especificados antecipadamente.

• Os requisitos, neste modelo, não são vistos como definitivos

mas evoluem ao longo do tempo.
59

• O desenvolvimento começa com os requisitos óbvios e fáceis

de identificar.

• É considerada a regra 80/20, segundo a qual:

• 80% da funcionalidade de um sistema pode ser entregue
com cerca de 20% do esforço necessário para completar
100% dos requisitos.

• Os últimos 20% de requisitos são mais difíceis e mais
demorados de desenvolver
60

• No modelo RAD os requisitos são hierarquizados segundo a

regra MoSCoW:

• Must have;

• Should have;

• Could have;

• Won’t have.
61
• Desenvolvimento de SI Web:
• Actualmente grande parte dos sistemas desenvolvidos

funcionam em ambientes web, o que levou a questionar a
necessidade de diferentes abordagens para o desenvolvimento
destes sistemas de informação WIS (Web Information Systems).
62
• Desenvolvimento de SI Web:
•
Uma abordagem para os WSI é o modelo W que é uma

adaptação do modelo V.

• Esta adaptação baseia-se na substituição da fase de codificação

por uma fase designada por implementação incremental.

• Inclui uma etapa de validação com o cliente, devido à

importância que a interface tem nestes sistemas.
63
de Sistemas de Informação
4.4. Fases do Processo de Desenvolvimento
64
4.4. Fases do Processo de DSI
• Independentemente das diferentes abordagens é possível

reconhecer um conjunto de fases comuns:
• Estudo de Viabilidade;
• Engenharia de Requisitos;
• Desenho;
• Codificação;
• Manutenção.
65
• Estudo de Viabilidade:
• Um estudo de Viabilidade é:

• Um estudo preliminar às necessidades de informação dos

utilizadores;

• Avaliar soluções alternativas e recursos necessários;

• Avaliar os custos e benefícios da intervenção;

• Avaliar a viabilidade do processo.
66
• A viabilidade do sistema pode ser avaliada em termos:

• Organizacionais - como o sistema suporta os objetivos

estratégicos de organização;

• Económicos - de que forma é que os custos são

compensados pelo aumento do lucro;
67
• A viabilidade do sistema pode ser avaliada em termos:

• Técnicos - em que medida é que as TI necessárias podem

ser adquiridas ou desenvolvidas no tempo necessário;

• Operacionais - como é que o sistema é aceite pelos

utilizadores.
68
• Um estudo de Viabilidade inclui normalmente uma análise de

custos e benefícios, estes podem ser:

• Tangíveis - os custos de equipamentos necessários, a poupança

de recursos que se consegue com a adopção do novo sistema.;

• Intangíveis - Os custos da desmotivação dos funcionários, o

beneficio de um melhor serviço ao cliente.

• Os custos Intangíveis são mais difíceis de estimar.

69
•
Engenharia de Requisitos:
70
•
71
• Engenharia de Requisitos:
• O objetivo da engenharia de requisitos é determinar as

necessidade e restrições do sistema em desenvolvimento,
estabelecendo uma visão geral do sistema num dado contexto.

• Um requisito é uma condição que tem de se verificar, para

atingir os objetivos do sistema.
72
• O processo de engenharia de requisitos pode ser descrito

como:
73
•
• A especificação de requisitos deve ser:

• Completa;

• Consistente;

• Modificável;

• Não ambígua;

• A especificação deve especificar os requisitos funcionais e os

não funcionais.
74
•
• Requisitos funcionais são as condições que o sistema tem que

ser capaz e executar.

• Requisitos não funcionais são as características qualitativas do

sistema e especificam funções desejáveis para o sistema. Por
exemplo: desempenho, segurança e facilidade de utilização.

• Alguns requisitos não funcionais poderão em certos sistemas

ser mais importantes.
75
• As fases que compõem este ciclo são divididas em quatro fases:

• Levantamentos de requisitos;

• Análise e negociação;

• Especificação e documentação;

• Validação e verificação.
76
•
• Levantamento de requisitos:

• Qualquer processo de ER começa por tentar perceber

quais as necessidades e restrições do sistema a
desenvolver.

• O conhecimento do sistema encontra-se em diferentes

fontes como por exemplo: clientes, utilizadores, legislação,
documentação...
77
•
Levantamento de requisitos:

• O objectivo do levantamento de requisitos é interiorizar o

conhecimento sobre o sistema para o entender.

• Existem várias técnicas que podem ser usadas para atingir

o objectivo, permitindo e facilitando o diálogo com os
utilizadores.
78

• Algumas das técnicas são:

• Análise de Documentação;

• Entrevistas;

• Questionários;

• Observação;

• Volumes;

• Prototipagem.
79

• Análise de Documentação:

• A análise de documentação é o estudo de diferentes

documentos na organização, tais como, regulamentações
governamentais, relatórios, impressos...

• É vulgar encontrar-se nas organizações, grande número de

documentos, os quais nem sempre estão actualizados nem
descrevem os procedimentos da organização.
80

• Análise de Documentação:

• Esta técnica não é suficiente para facultar todo o

conhecimento sobre o domínio do problema em estudo.

• A análise de documentação serve para dar uma visão geral

do funcionamento da organização e do sistema.

• Deve ser utilizada em conjunto com qualquer uma das

outras técnicas.
81

• Entrevistas:

• As entrevistas são das técnicas mais utilizadas para

recolher informação.

• Muitas vezes, as opiniões são mais importantes do que os

factos;

• É através das opiniões que se descobrem os problemas.

• Para além das opiniões deve tentar perceber-se os

sentimentos do entrevistado.
82

• Entrevistas:

• O analista ou engenheiro de requisitos deve definir qual o

objetivo da entrevista.

• Tendo em conta o objetivo da entrevista, qual a pessoa ou

pessoas que lhe podem facultar essa informação.
83

• Entrevistas:

• Há cinco passos a considerar quando se planeia uma entrevista:

• Recolher informação de base sobre a organização e sobre

os possíveis entrevistados;

• Estabelecer os objetivos da entrevista;

• Decidir quem entrevistar;

• Preparar o entrevistado;

• Definir a estrutura e tipo de questões.
84

• Entrevistas:

• Depois da entrevista, é fundamental fazer um relatório

escrito, que deve ser visto novamente, com o entrevistado.
85

• Questionários:

• O questionário permite obter determinados detalhes que:

• Não foram obtidos durante a entrevista;

• Permitem filtrar e validar dados obtidos nas

diferentes entrevistas;
86
•

• Questionários:

• Pode decidir-se se a utilização de questionários é apropriada se

a resposta às seguintes questões for afirmativa:

• Há um grande número de pessoas envolvidas que é

necessário questionar?

• Pretende-se avaliar previamente problemas para explorar
em entrevistas?
87

• Questionários:

• Pode decidir-se se a utilização de questionários é apropriada se

a resposta às seguintes questões for afirmativa:

• As pessoas a questionar estão fisicamente distantes?

• Pretende-se fazer um estudo exploratório?
88

• Questionários:

• É importante que o questionário seja claro e conciso;

• Não deve utilizar um vocabulário técnico;

• Deve focar diretamente o assunto a questionar;

• Na elaboração de questionários, nunca se deve esquecer de

facultar um guia com as regras de preenchimento, bem como
agrupar e criar uma sequência lógica das questões.
89
•

• Questionários:

• As questões podem ser de dois tipos:

• Abertas - Mais ricas em detalhe;

• Pré-codificadas - Mais fáceis de analisar e de quantificar.

• Devem utilizar-se perguntas fechadas quando se pretende

questionar um grande número de pessoas.
90

• Observação:

• Um observador gasta largos períodos de tempo, fazendo

uma observação detalhada das suas práticas.

• A observação é uma técnica muito utilizada que permite

observar diretamente as pessoas na execução do seu
trabalho, facilitando a identificação do tipo de suporte que
elas necessitam de um SI.
91

• Observação:

• A obser vação direta pode inibir, alterando o

comportamento das pessoas que estão a ser observadas,
pondo em causa a fiabilidade dos dados obtidos.

• É importante que o observador seja bem aceite pelas

pessoas a analisar e não tenha qualquer interferência no
processo que elas executam.
92
•

• Observação:

• Podem-se distinguir dois tipos de observação:

• Passiva - O observador não tem qualquer envolvimento

no processo;

• Participativa - O observador toma parte activa no

processo.
93

•
Volumes:

• A análise de volumes implica uma análise numérica de

dados relevantes à compreensão do sistema, tais como:

• O número de fornecedores nos últimos anos;

• O número de encomendas solicitadas por dia;

• A percentagem de encomendas rejeitadas por dia.
94

• Volumes:

• Os volumes permitem não só realçar erros e problemas

existentes mas também o crescimento do sistema.
95

• Prototipagem:

• O principal objetivo do protótipo é permitir que o

utilizador experimente o sistema, percebendo como ele
será utilizado para suportar o seu trabalho.

• Através da experimentação com o protótipo, os

utilizadores poderão mais facilmente descobrir problemas
e sugerir melhorias de requisitos.
96
• Análise e Negociação:

• O objetivo desta fase é analisar os requisitos para explicitar

conflitos, argumentos e razões, e estabelecer um acordo
entre todos os intervenientes no processo.

• Nesta fase podem elaborar-se listas de verificação, as quais

são listas de questões, que o analista utiliza para avaliar cada
requisito.
97

• Uma possível lista de itens a analisar inclui:

• Ambiguidade;

• Utilidade;

• Complexidade;

• Equipamento;

• Teste;

• Realismo.
98

•
Um objetivo importante desta etapa é descobrir as

interações entre os requisitos. apontando conflitos e
sobreposições.

• As sobreposições e conflitos entre requisitos devem ser

discutidos com os intervenientes na etapa de negociação.

• Na etapa de negociação devem assumir-se os compromissos

aceites por todos os stakeholders.
99

• Os compromissos são normalmente assumidos de acordo

com:

• As necessidades da organização;

• Os requisitos específicos dos diferentes stakeholders;

• As restrições de implementação;

• O orçamento e o tempo.
100

•
As reuniões são o meio mais eficaz de negociar requisitos e

resolver conflitos.

• Uma reunião para negociação de requisitos deve desenrolar-

se em três fases:

• Informar sobre o problema associado com o requisito;

• Discutir a resolução do problema;

• Concordar na forma de resolução do problema.
101
•
Especificação e Documentação de Requisitos:

• O resultado desta fase é um conjunto de modelos que

especificam todos os requisitos que o sistema deve satisfazer.

• Nesta fase, é importante manter a consciência das alterações

de requisitos em todos os modelos existentes.
102
• Validação e Verificação de Requisitos:

• Pode definir-se validação como:

• “Estou a construir bem o produto?”

• E verificação como:

• “Estou a construir o produto certo?”
103

• A validação de requisitos tem como objetivo garantir a

resolução do problema certo e controlar se os requisitos
especificados são consistentes com as intenções do utilizador
ou cliente.

• O principal problema da validação de requisitos é que não

existe nenhum documento que possa ser a base da validação.
104

• Um programa pode ser validado contra a especificação,

contudo, não há forma de demonstrar que uma especificação
de requisitos está correcta.

• A validação significa garantir que a especificação representa

uma descrição clara do sistema, e é uma verificação final de
que os requisitos satisfazem os utilizadores.
105
•
Validação e Verificação de Requisitos:

• Podem também validar-se requisitos utilizando um protótipo.

• No entanto, os protótipos utilizados para a validação têm de

ser mais completos do que os utilizados para o levantamento
de requisitos.
106
• Desenho:
• Quando se opta pela construção de um sistema informático, é

necessário converter a especificação lógica do sistema,
resultante da fase de ER, num sistema executável.

• Pretende-se produzir uma especificação completa deste sistema

informático, descrevendo as suas componentes de dados,
processos e interface: este é o objetivo desta fase.
107
•
Desenho:
• A fase de desenho envolve a descrição do sistema em diferentes

níveis de abstração.

• A sua importância prende-se com a identificação e avaliação de

soluções alternativas que satisfaçam a especificação de
requisitos.

• Nesta fase devem identificar-se e avaliar-se as soluções possíveis

que podem estar dependentes da plataforma tecnológica.
108
• Desenho:
• Durante esta fase são elaborados:

• Desenho da arquitetura do sistema;

• Desenho das estruturas de dados fundamentais;

• Desenho da base de dados que suportará o sistema;

• Desenho de códigos;

• Desenho da arquitetura física do sistema;

• Desenho de comunicações, detalhando hardware e software;

• Desenho da interface.
109
• Desenho:
• A fase de desenho tem particular importância para sistemas

complexos que não podem ser implementados por um único
programador e que têm de ser desenhados antes de serem
codificados.
110
• Desenho:
• Torna-se, por vezes, difícil compreender devidamente a

importância desta fase, pois muitas vezes os sistemas a
desenvolver são pouco complexos e desenvolvidos por um
pequeno grupo de pessoas, passando directamente para da
especificação para a codificação.
111
• Desenho:
•
Uma das preocupações a ter quando se desenha um sistema é

prever a mudança.

• Deve desenhar-se o sistema de forma a que no futuro seja

possível adicionar e alterar funcionalidades, sem grande impacto
no sistema existente.

• Outro aspecto a ter em conta é permitir a reutilização.
112
• Codificação, Testes e Implementação:

• A codificação é a tradução das especificações de desenho, numa

dada linguagem de programação.

• Durante o processo de construção, realizam-se vários testes

para garantir o bom funcionamento do sistema, em termos de
requisitos funcionais e não funcionais.
113
• Codificação, Testes e Implementação:

• Os testes podem ser:

• Testes de unidade;

• Testes de sistema;

• Testes de volume;

• Testes de integração;

• Testes de aceitação.
114
•
Codificação, Testes e Implementação:
• A etapa de implementação tem aspectos tecnológicos,

relacionados com:

• Equipamentos físicos;

• Programas informáticos;

• Informação.

• Aspectos sociais relacionados com a identificação, treino e

suporte aos utilizadores.
115
•
Codificação, Testes e Implementação:
• É necessário definir a estratégica de conversão.

• Existem diferentes alternativas para a conversão do sistema

antigo para o novo, como por exemplo:

• Conversão directa;

• Conversão em paralelo;

• Conversão faseada;

• Conversão modular prototipada;
116
• Manutenção:
• A manutenção é o processo de alterar o SI depois de este ser

implementado.

• Existem várias razões que obrigam a necessidade de alterar o

sistema, como por exemplo:

• Erros que têm que ser corrigidos;

• Mudanças nos processos de uma organização;

• Novos requisitos;

• Problemas com equipamentos;

• Mudanças ambientais;
117
• Manutenção:
• Estas situações originam diferentes tipos de manutenção:

• Manutenção perfetiva;

• Manutenção adaptativa;

• Manutenção corretiva;

• Manutenção preventiva.
118
4.5. Falhas no Processo de Desenvolvimento

de Sistemas de Informação
119
4.5. Falhas no Processo de DSI
• Há diferentes motivos apontados como causas de falhas no

processo de DSI, com por exemplo:

• O incompleto levantamento e especificação de requisitos;

• A falta de envolvimento e comunicações com os

stakeholders;

• O ênfase nos aspectos tecnológicos.
120
• Nesta figura consegue perceber-se a importância da deteção
atempada de erros no processo de DSI, sendo que os erros

detetados em fases finais têm um maior custo para a
organização.
121
• Um outro aspeto descurado no processo de DSI é a

documentação do sistema.

• Qualquer sistema deve ser convenientemente documentado, de

forma a permitir a sua utilização eficaz.
122
• Devem ser criados dois tipos de documentos:

• Documentação do sistema - descreve o comportamento do

sistema, normalmente utilizando os modelos construídos ao
longo do processo de DSI;

• Manuais do utilizador - descrevem como o utilizador pode usar

o sistema;
123

Desenvolvimento de Sistemas de Informação

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Desenvolvimento de Sistemas de Informação

Enviado por

Direitos autorais:

Formatos disponíveis

Sistemas de Informação de

Telmo Bento - tbento@ismai.pt

dos Sistemas de Informação

• A introdução de um novo sistema de informação envolve muito

mais do que actualizações de hardware e software.

• Inclui mudanças em:

• As tecnologias de informação podem promover vários níveis da

A mudança mais comum nas organizações habilitadas a utilizar

• As alterações iniciais são o desenvolvimento de tecnologias de

• Um modo mais profundo de mudança organizacional,

• A automatização revela frequentemente algumas falhas na

• A racionalização de processos é a simplificação e explicação dos

• A racionalização de processos é muitas vezes encontrada em

• Um tipo de mudança organizacional mais poderoso é o

• No redesenho dos processos da organização, os processos são

• O redesenho dos processos da organização redesenha e

reorganiza o fluxo de trabalho, combinando medidas para

• É muito mais ambicioso que a racionalização de processos,

• Uma forma mais radical de mudança organizacional é a

• A mudança de paradigma envolve repensar a natureza do

• A mudança de paradigma falha frequentemente, devido à

extensão da mudança, o que a torna difícil de orientar.

• Porque é que tantas organizações efectuam mudanças radicais?

• Devido às recompensas da mudança serem muito

Grande parte das organizações têm tentado melhorar os seus

• Algum destes sistemas implicam uma mudança de processos

A gestão de processos oferece várias ferramentas e

• A gestão de processos nunca está concluída, devido ao facto do

• As organizações que efectuam a gestão de processos passam

pelos seguintes passos:

• Identificação dos processos a mudar;

• Identificação dos processos a mudar:

• Uma das mais importantes decisões estratégicas que uma

• em vez de decidir como utilizar o computador para

• Identificação dos processos a mudar:

• Pode ser gasto tempo e dinheiro considerável na

• Os gestores precisam de determinar que processos da

• Análise dos processos existentes:

• Os processos existentes devem ser modelados e

• A equipa do projecto de processos identifica os passos

• Projectar novos processos:

• Quando os processos existentes se encontram

• Um novo processo simplificado será documentado e

• Projectar novos processos:

• Os novos processos precisam de ser justificados

• Implementar novos processos:

• Quando o novo processo se encontrar modelado e

• Os novos processos e os sistemas de suporte são

• Implementar novos processos:

• Quando a organização começa a utilizar os processos, os

• Os funcionários que trabalham com os processos podem

Quando os processos são implementados e optimizados,

• Os processos podem deteriorar-se ao longo do tempo ou

• Apesar de grande parte das melhorias dos processos nas

• O exemplo a seguir demonstrará uma mudança mais radical.

• A mudança estudada no exemplo sucedeu na realidade, quando

a Amazon desafiou as livrarias tradicionais com o modelo de

• Com a mudança radical da forma como se compram ou vendem

Os administradores das organizações, descrevem que a maior

• Os funcionários não gostam de rotinas com que não estão

Esta situação acontece mais frequentemente quando as

• A gestão da mudança não é simples nem intuitiva, e as

Sistemas de Informação de 