www.marrrceloandrade.com.br [email protected].

br

Fases e etapas de sistema de informação

As principais fases de um sistema de informação são:

br
1. Levantamento de requisitos
2. Desenvolvimento de sistemas de informação
3. Testes a sistemas de informação
4. Implementação de sistemas de informação

m.
5. Manutenção de sistemas de informação
6. Avaliação de sistemas de informação

1. Levantamento de requisitos

.co
Os requisitos podem ser descrições de como um sistema de informação se deve comportar, das suas propriedades e
das suas restrições ou condicionantes do seu desenvolvimento. A fase de levantamento de requisitos é, então, de
extrema importância, pois é ela que garante que o novo sistema de informação será capaz de fazer o que é suposto
fazer.
Esta fase é, em si, um processo que implica uma série de outras tarefas:
1. Estabelecer objetivos

de
2. Compreender o contexto
3. Organizar o conhecimento
4. Fazer o levantamento dos requisitos

1.1. Estabelecer objetivos

dra
 Definir objetivos do negócio;
 Definir o problema a resolver;
 Definir as restrições do sistema:
o Restrições econômicas;
o Restrições políticas;
n

o Restrições tecnológicas;
o Restrições ambientais;
oa

o Restrições temporais, etc.;

1.2. Compreender o contexto

 Compreender a estrutura organizacional;

cel

 Compreender o domínio da aplicação;

 Identificar os sistemas existentes.

1.3. Organizar o conhecimento

rrr

 Identificar os stakeholders e os utilizadores:

o Compreender as necessidades dos interessados num sistema de informação é decisivo para o
desenvolvimento de uma solução efetiva;
o Conhecer os interessados e as suas necessidades permite definir as fronteiras do sistema:
 Quem são os utilizadores do SI? Quem fornece, utiliza, remove informação do SI?
ma

 Como é que o SI contém a informação necessária ao seu funcionamento?

 Onde é que o SI é utilizado?
 Quem será afetado pelas saídas que o SI produz?
 Quem vai ficar responsável pela manutenção do SI?
 Que outros sistemas interagem com o novo SI?
 Definir prioridades para os objetivos;
 Filtrar o domínio de conhecimento.

www.facebook.com/marrrceloandrade.com.br/ Página 1 de 11
www.marrrceloandrade.com.br [email protected]

1.4. Fazer o levantamento dos requisitos

 Identificar requisitos dos stakeholders;

 Identificar requisitos do domínio;

br
 Identificar requisitos da organização.

O contexto no qual o sistema se vai inserir e as condições impostas ao processo, influenciam a forma como o
levantamento de requisitos é feito.

m.
1.5. Requisitos Funcionais e não funcionais

Requisitos não‐funcionais
São os requisitos relacionados ao uso da aplicação em termos de desempenho, usabilidade, confiabilidade, segurança,

.co
disponibilidade, manutenção e tecnologias envolvidas. Não é preciso o cliente dizer sobre eles, pois eles são
características mínimas de um software de qualidade, ficando a cargo do desenvolvedor optar por atender esses
requisitos ou não.
 Requisitos de produtos: requisitos que especificam o comportamento do produto. Ex. portabilidade; tempo na
execução; confiabilidade, mobilidade, etc.
 Requisitos da organização: requisitos decorrentes de políticas e procedimentos corporativos. Ex. padrões,

de
infraestrutura, etc.
 Requisitos externos: requisitos decorrentes de fatores externos ao sistema e ao processo de desenvolvimento.
Ex. requisitos de interoperabilidade, legislação, localização geográfica etc.
 Requisitos de facilidade de uso: Ex. usuários deverão operar o sistema após um determinado tempo de
treinamento.
dra
 Requisitos de eficiência: Ex. o sistema deverá processar n requisições por um determinado tempo.
 Requisitos de confiabilidade: Ex. o sistema deverá ter alta disponibilidade, por exemplo, 99% do tempo.
 Requisitos de portabilidade: Ex. o sistema deverá rodar em qualquer plataforma.
 Requisitos de entrega: Ex. um relatório de acompanhamento deverá ser fornecido toda segunda‐feira.
 Requisitos de implementação: Ex. o sistema deverá ser desenvolvido na linguagem Java.
 Requisitos de padrões: Ex. uso de programação orientada a objeto sob a plataforma A.
n

 Requisitos de interoperabilidade: Ex. o sistema deverá se comunicar com o SQL Server.

 Requisitos éticos: Ex. o sistema não apresentará aos usuários quaisquer dados de cunho privativo.
 Requisitos legais: Ex. o sistema deverá atender às normas legais, tais como padrões, leis, etc.
oa

 Requisitos de Integração: Ex. o sistema integra com outra aplicação.

Requisitos funcionais
São os requisitos relacionados com as funções específicas que o sistema de informação é suposto executar, e que
cel

levaram à sua instalação. São exemplos de possíveis requisitos funcionais de um registo clínico eletrônico:
 capacidade de recolher os dados das admissões de doentes;
 capacidade de recolher os dados das altas de doentes;
 capacidade de recolher os dados de prescrição.
rrr

1.6. Processos para descobrir requisitos

 Requisitos conduzidos por políticas organizacionais – Ex. no hospital XYZ todos os diagnósticos são identificados
através de código ICD;
 Requisitos iniciados por problemas:
ma

o Diagnóstico conduzido por eventos;

o Análise baseada em modelos.
 Requisitos iniciados por exemplos;
 Requisitos impostos pelo ambiente externo:
o Normas, regulamentos, etc. Ex. nos hospitais portugueses é obrigatória a identificação dos utentes nacionais
com o número de utente existente no cartão do cidadão.

www.facebook.com/marrrceloandrade.com.br/ Página 2 de 11
www.marrrceloandrade.com.br [email protected]

1.7. Instrumentos de identificação de requisitos

1. Entrevistas e questionários ‐ técnicas simples, mas difíceis de aplicar porque:

o Enviesamento dos entrevistadores;

br
o Predisposição do entrevistado; pode ser melhorada a predisposição usando linguagem apropriada e técnicas
de negociação;
o Relação pessoal.
2. Workshops de requisitos ‐ técnica de grupo para o debate e acordo das questões associadas à identificação de
requisitos:

m.
o Grupo é composto por representantes dos diversos stakeholders identificados;
o Discussão é mediada por especialista na identificação e levantamento de requisitos;
3. Brainstorming ‐ técnica de grupo para a geração de novas ideias:
o Encoraja a participação de todos os envolvidos no processo de criação de SI;
o Permite o aproveitamento e o refinamento de outras ideias e a criação de novas;

.co
o Encoraja o pensamento livre;
4. Cenários ‐ técnica que permite colocar os interessados no SI perante uma situação realista em que simulam ou
anteveem a interação com o SI;
5. Storyboarding ‐ técnica que permite obter, rapidamente, reações dos utilizadores para os conceitos propostos para
o SI:

de
o Passivo ‐ capturas de tela; regras do negócio; relatórios;
o Ativo ‐ slide shows; animações; simulações;
o Interativo ‐ demos; apresentações interativas;
6. Protótipos ‐ técnica que consiste na criação de uma versão inicial do sistema para apoio à identificação, análise e
validação de requisitos:
dra
o Baixa fidelidade ‐ Esquema iniciais para discussão, Casos de uso, Diagramas de Sequência
o Alta fidelidade ‐ Mockups com um aspecto muito próximo do final

1.8. Formato dos requisitos

 Numerar requisitos
 Esquemas em formato UML
n

 Uso de linguagem natural

 Incluir critérios de aceitação dos requisitos
oa

1.9. Problemas no levantamento de requisitos

Vários problemas podem surgir durante o levantamento de requisitos, nomeadamente:

cel

o Os utilizadores não sabem o que querem ou sabem o que querem, mas não conseguem articulá‐lo;
o Os utilizadores pensam que sabem o que querem até que os desenvolvedores lhes deem o que disseram que
queriam;
o Os analistas acham que compreendem os problemas dos utilizadores melhor que os mesmos.
o Uma forma de minimizar os problemas é serem discutidos de forma iterativa em várias versões até à final.
rrr

2. Desenvolvimento de sistemas de informação

2.1. Desenvolvimento à medida ou por pacotes
ma

Existem duas abordagens principais distintas para o desenvolvimento de sistemas de informação:

 Desenvolvimento à medida:
o Construção do sistema corresponde diretamente aos requisitos da organização/dos utilizadores;
o Implica, tipicamente, um grande investimento, nomeadamente no que refere os recursos internos
qualificados.
 Desenvolvimento por pacotes:

www.facebook.com/marrrceloandrade.com.br/ Página 3 de 11
www.marrrceloandrade.com.br [email protected]

 Construção do sistema através da aquisição de um pacote de soluções de software já desenvolvidas, que

correspondem mais ou menos aos requisitos pedidos pela organização/pelos utilizadores;
 Implica, tipicamente, um maior trabalho de configuração e adaptação, que pode ser mais ou menos complexo
e envolver mais ou menos recursos dependendo do sistema.

br
2.2. Modelos para o desenvolvimento de SI

Existem diversos modelos para o desenvolvimento de Sistemas de Informação:

 Modelo Waterfall

m.
 Modelo em Espiral
 Modelo Agile
Cada modelo compreende um conjunto particular de fases que, com mais ou menos variações, procuram cumprir o
mesmo objetivo: desenvolver e construir sistemas de informação capazes de suprir as necessidades dos seus

.co
utilizadores.

Modelo Waterfall
O modelo waterfall (ou "em cascata") é um modelo de desenvolvimento de software/sistemas de informação
sequencial, isto é, no qual as fases se sucedem umas às outras de forma constante (como o fluir de uma cascata):
1. Análise de requisitos;

de
2. Projeto;
3. Implementação;
4. Testes (validação);
5. Integração;
6. Manutenção de software.
dra
Neste modelo, a passagem de uma fase
para a seguinte é puramente sequencial.
Isto significa que só se inicia uma nova fase quando a anterior está completa. Por isto, é considerado rígido ‐ não
permite voltar atrás numa fase para fazer melhoramentos (uma fase só é terminada quando considerada "perfeita") ‐
e monolítico ‐ não inclui a participação dos utilizadores no processo. Mais ainda, as métricas utilizadas nas estimativas
de tempo e recursos são imprecisas, levando a que, quase sempre, o planeamento das atividades tenha que ser
n

revisto. No entanto, devido à sua rigidez, o modelo em cascata não permite os reajustes necessários, causando o não
cumprimento dos prazos estipulados inicialmente.
oa

Modelo em Espiral
O modelo em espiral é um modelo de desenvolvimento de software/sistemas de informação cíclico onde, em cada
ciclo, existem fases de avaliação e planeamento.
Este modelo foi desenvolvido para abranger as melhores características tanto do ciclo de vida clássico como da
cel

prototipação, acrescentando, ao mesmo tempo, um novo elemento ‐ a análise de riscos ‐ que falta a esses
paradigmas. Existem diferentes variações do modelo, sendo que todos compreendem entre três e seis tarefas/setores
que incluem:
 Comunicação com o cliente;
 Planeamento;
 Análise de risco;
rrr

 Engenharia;
 Construção e liberação;
 Avaliação do cliente.
ma

www.facebook.com/marrrceloandrade.com.br/ Página 4 de 11
www.marrrceloandrade.com.br [email protected]

br
m.
.co
de
dra
A dimensão radial representa o custo acumulado atualizado e a dimensão angular representa o progresso através da
espiral. Cada sector da espiral corresponde a uma tarefa (fase) do desenvolvimento. Ao contrário do modelo em
cascata, este é flexível e inclui a participação dos utilizadores durante todo o processo. É uma abordagem mais realista
e evolutiva.
n

Modelo Agile
O modelo agile é um modelo de desenvolvimento de software/sistemas de informação que tem como objetivo
minimizar o risco através do desenvolvimento em janelas de tempo pequenas, chamadas de iterações. Cada iteração
oa

é um "mini‐projeto" que inclui todas as fases necessárias à criação de novo software:

 Planeamento;
 Análise de Requisitos;
 Projeto;
 Codificação;
cel

 Teste;
 Documentação.

Para cada iteração, que tem uma duração típica de 1 a 4 semanas, é, então, lançada uma versão do SI.
rrr
ma

www.facebook.com/marrrceloandrade.com.br/ Página 5 de 11
www.marrrceloandrade.com.br [email protected]

br
m.
.co
Na criação de novo software, então, devem estar envolvidas todas as pessoas necessárias ao desenvolvimento do SI,

de
nomeadamente: os programadores, os clientes, os projetistas, os responsáveis pela realização dos testes, etc. Este
método dá uma grande importância à comunicação presencial, desenfatizando o papel da comunicação escrita.
Consequentemente, o modelo agile dá origem a pouca documentação, o que pode ser visto como um ponto negativo,
uma vez que a criação de documentação pode ser muito útil em iterações futuras ou novos projetos de
desenvolvimento.
dra
2.3. Recursos para o Desenvolvimento de Sistemas de Informação
 Técnicas:
o Centradas no desenvolvedor:
 Técnicas de análise de dados;
 Técnicas de análise de processos;
n

 Técnicas de análise de objetos.

o Centradas no utilizador:
 Prototipagem;
oa

 Cenários;
 Casos de uso.
 Métodos:
o Métodos estruturados;
cel

o Desenvolvimento rápido de aplicações;

o Métodos orientados a objetos.
 Ferramentas:
o CASE ‐ Computer Aided Software Engineering:
 Apoia e automatiza partes do processo de construção de SI;
o CAISE ‐ Computer Aided Information Systems Engineering:
rrr

 Apoia e automatiza parte do processo completo de desenvolvimento de SI.

2.4. Atividades da Construção de Sistemas de Informação

A construção de um sistema de informação envolve a programação/configuração, teste e documentação do sistema.

ma

Desta fase fazem parte as seguintes atividades:

 Construção da aplicação:
o Interface com o utilizador;
o Regras do negócio;
o Gestão dos dados.
 Teste da aplicação:
o Teste de unidades;
o Teste do sistema;
www.facebook.com/marrrceloandrade.com.br/ Página 6 de 11
www.marrrceloandrade.com.br [email protected]

o Teste de integração;
o Teste de aceitação.
 Documentação da aplicação:
o Documentação do utilizador;
o Documentação do sistema.

br
 Construção do sistema de atividades humanas:
o Especificação das funções e papéis;
o Especificação da estrutura organizacional;
o Especificação de procedimentos e tarefas.

m.
3. Testes de sistemas de informação
Os testes são uma fase de um sistema de informação e são fundamentais para garantir a qualidade do sistema. É nesta

.co
fase que os erros são detectados, criando a oportunidade para aperfeiçoar o software. O problema é que esta fase
implica tempo e recursos. Grande parte dos custos de desenvolvimento de sistemas advém, precisamente, da
realização de testes.

3.1. Sub‐fases

de
Tal como as anteriores, esta fase é composta por sub‐fases:
 Planeamento da estratégia e do plano de teste;
 Preparação do ambiente de teste (recursos materiais, tecnológicos e humanos);
 Especificação de casos e de roteiros de teste;
 Execução dos testes e registo dos resultados;
dra
 Entrega da documentação final.

3.2. Fontes de Erros

 Especificação errada e/ou incompleta dos requisitos;

 Requisitos impossíveis;
n

 Implementação errada/incompleta;
 Mau desenho do sistema;
 Técnica de desenvolvimento inadequada;
oa

 Erros de programação:
 Interface pouco clara/inadequada, etc.

3.3. Atributos a avaliar

cel

De acordo com a norma ISO 9126 (norma internacional para a qualidade de software), os atributos qualitativos a
avaliar num sistema de informação são:
 Funcionalidade:
o Capacidade de um sistema de fornecer as funcionalidades que satisfazem as necessidades do utilizador. Inclui:
 Adequação (quanto as funcionalidades estão adequadas às necessidades dos utilizadores);
rrr

 Precisão (capacidade de fornecer resultados precisos ‐ de acordo com o estipulado);

 Interoperabilidade (capacidade de interação com outros sistemas);
 Segurança (capacidade de proteger, processar, gerar e armazenar informação);
 Conformidade (com padrões, políticas e normas).
 Confiabilidade:
ma

o Capacidade do sistema de manter o grau de desempenho esperado. Inclui:

 Maturidade (capacidade de evitar falhas relacionadas com defeitos do software);
 Tolerância a falhas (capacidade de manter o desempenho, mesmo quando ocorrem erros);
 Recuperabilidade (capacidade de repor níveis de desempenho depois de uma falha);
 Usabilidade:
o Capacidade do sistema de ser compreendido e usado pelos utilizadores. Inclui:
 Inteligibilidade (capacidade do sistema de fazer o utilizador entender as suas funcionalidades);
 Apreensibilidade (capacidade do sistema de aprender com os utilizadores);

www.facebook.com/marrrceloandrade.com.br/ Página 7 de 11
www.marrrceloandrade.com.br [email protected]

 Operacionalidade;
 Atratividade.
 Eficiência:
o Capacidade do sistema de utilizar os recursos de forma adequada ao desempenho ‐ não há sobreutilização
nem desperdício de recursos. Inclui:

br
 Comportamento em relação ao tempo (tempos de resposta e processamento);
 Utilização de recursos (recursos consumidos e capacidade de utilização dos recursos).
 Manutenibilidade:
o Capacidade do sistema de ser modificado por melhorias, extensões, correções de erros, etc. Inclui:

m.
 Analisabilidade (capacidade para identificar falhas e as suas causas);
 Modificabilidade (capacidade de modificação do comportamento);
 Estabilidade (capacidade de evitar efeitos colaterais decorrentes de modificações);
 Testabilidade.
 Portabilidade:

.co
o Capacidade do sistema de ser transportado para outro ambiente. Inclui:
 Adaptabilidade (capacidade de se adaptar a novos ambientes);
 Capacidade de instalação (capacidade de ser instalado noutro ambiente);
 Coexistência (capacidade de coexistir com outros sistemas no mesmo ambiente);
 Capacidade de substituição (capacidade de substituir outro sistema num contexto e ambiente específicos).

de
3.4. Técnicas de Teste

Caixa Branca
Esta técnica assenta diretamente sobre o código fonte do software, por forma a avaliar aspetos tais como:
dra
 teste de condição,
 teste de fluxo de dados,
 teste de ciclos,
 teste de caminhos lógicos,
 códigos nunca executados.

No entanto, os aspetos avaliados através deste método dependem da complexidade do sistema e da tecnologia
n

utilizada na sua construção. Isto pode implicar que mais elementos tenham que ser testados, além daqueles referidos
anteriormente.
oa

Este teste é realizado, então, através da análise do código fonte do sistema em causa, elaborando casos de teste para
avaliar todas as possibilidades. Só assim é possível testar todas as variações relevantes resultantes do código.

Caixa Preta
Ao contrário do que acontece com o teste caixa branca, o teste caixa preta ignora o comportamento interno do sistema
cel

e foca‐se, antes, na avaliação do comportamento externo. Neste caso, dados de entrada são fornecidos ao sistema
para processamento e o resultado obtido é comparado com o resultado esperado. Assim sendo, os casos de teste
derivam todos da especificação inicial, isto é, dos requisitos.
Quantas mais entradas foram fornecidas, melhor será o teste. Idealmente, todas as entradas possíveis deviam ser
testadas, de forma garantir os melhores resultados. No entanto, isso implicaria muito tempo e muitos recursos. Para
garantir a qualidade do teste de forma realista, normalmente são utilizados subconjuntos de entradas (alguns
rrr

subconjuntos podem até ser processados similarmente) que se acredita maximizarem a riqueza do teste.

Caixa Cinzenta
O teste caixa cinzenta combina os métodos dos dois testes apresentados anteriormente. Assim sendo, através do uso
ma

desta técnica é possível aceder ao código fonte e aos algoritmos do software de forma a definir os casos de teste a ser
aplicados, posteriormente, ao teste do comportamento externo do sistema.

Regressão
Esta técnica é aplicada a novas versões de software. A regressão consiste na aplicação de todos os testes já aplicados
a versões ou ciclos de teste anteriores de um sistema, a uma nova versão ou a um novo ciclo. Para garantir a
produtividade e a viabilidade dos testes, é recomendado que se faça a automação dos mesmos. Assim, sobre a nova
versão ou o novo ciclo do sistema, os testes podem ser replicados com maior agilidade.

www.facebook.com/marrrceloandrade.com.br/ Página 8 de 11
www.marrrceloandrade.com.br [email protected]

Técnicas não funcionais

Ao contrário do que acontece com todas as técnicas anteriores, as técnicas não funcionais permitem avaliar aspetos
não funcionais, isto é, atributos de um sistema que não se relacionam com a funcionalidade, como a eficiência,

br
adequação do sistema às restrições (organizacionais, tecnológicas, de tempo, ...), a adequação a normas, a
confiabilidade, a usabilidade, etc. Exemplos de testes não funcionais:
 Teste de desempenho ‐ procura encontrar o limite de processamento de dados no melhor desempenho do
sistema;
 Teste de carga (ou de volume) ‐ procura encontrar o limite de processamento de dados até que o sistema não

m.
consiga mais;
 Teste de usabilidade ‐ testa a capacidade do sistema de ser compreendido e utilizado;
 Teste de confiabilidade ‐ testa se o sistema é capaz de recolher, processar e apresentar os dados de forma correta
(de acordo com as especificações iniciais);
 Teste de recuperação ‐ testa a capacidade de recuperação de um sistema após uma falha.

.co
4. Implementação de sistemas de informação
A implementação é uma fase de um sistema de informação e consiste na "entrega" dos mesmos às organizações, isto
é, na integração dos sistemas no ambiente organizacional cliente para que possam iniciar a sua atividade. Esta fase

de
implica, não só, a implementação do sistema de informação tecnológico, mas também do sistema de atividades
humanas (papéis/atividades dos utilizadores).

4.1. Implementação do Sistema de Informação Tecnológico

 Aquisição do software;
dra
o Contratos com Total Cost of Ownership (TCO) e Service Level Agreements (SLA)
 Aquisição do hardware;
o Dimensionar para os anos seguintes
o Ter atenção à redundância e balanceamento
 Preparação e conversão de dados;
o Exigir documentação das bases de dados
n

 Instalação;
o Criação de ambientes de QA (Quality Assurance)
 Teste;
oa

 Entrega.

4.2. Implementação do Sistema de Atividades Humanas

 Estabelecimento de grupos de trabalho;

cel

Formação de utilizadores e operadores;

o Avaliar a rotatividade de pessoal e a necessidade de mais ações de formação
 Aceitação do sistema pelos grupos de utilizadores.

4.3. Tipos de Implementação

 Conversão direta ‐ o sistema de informação antigo é desativado e totalmente substituído pelo novo sistema;
rrr

 Implementação paralela ‐ o novo sistema de informação é implementado paralelamente ao sistema antigo,

funcionando os dois em simultâneo até que se entenda que o novo está totalmente operacional e pronto para
substituir o antigo;
 Implementação híbrida.
ma

4.4. Tipos de fornecedores

 Empresas privadas
o Empresas de dimensão média ou grande
o Start‐ups
 Ministério da Saúde
o Empresas publicas
 Desenvolvimento interno
 Universidades
www.facebook.com/marrrceloandrade.com.br/ Página 9 de 11
www.marrrceloandrade.com.br [email protected]

5. Manutenção de sistemas de informação

Consiste no processo de aplicar mudanças aos sistemas durante a sua vida útil, de acordo com as necessidades da
organização e/ou dos utilizadores. Por isto, é essencial para garantir o bom funcionamento dos SI. A manutenção

br
permite resolver problemas como:
 Bugs no sistema;
 Mudanças nos processos;
 Alterações nos requisitos dos stakeholders/utilizadores;

m.
 Problemas técnicos com hardware e/ou software;
 Mudanças no ambiente.

Dependendo do tipo de problema a solucionar e dos objetivos a atingir, é adotado um tipo de manutenção. No
entanto, existe uma atividade de manutenção que deve ser aplicada durante todo o processo de desenvolvimento de

.co
um software/sistema de informação: Gestão de Configurações.

5.1. Atividades da Gestão de Configurações

 Identificar mudanças nos produtos do desenvolvimento;
 Controlar mudanças;
 Assegurar a correta realização de mudanças;

de
 Informar os stakeholders/utilizadores das mudanças.

5.2. Tipos de Manutenção

 Manutenção evolutiva (para melhoria) ‐ o foco é o aperfeiçoamento do desempenho de funções;
 Manutenção para adaptação ‐ o foco é modificação de funções existentes ou o acréscimo de novas funcionalidades
dra
que decorrem de mudanças no ambiente ou do aparecimento de novas necessidades (eg. novas leis);
 Manutenção corretiva ‐ o foco é a correção de bugs e erros lógicos que não foram detectados nos testes;
 Manutenção preventiva ‐ o foco é reduzir as oportunidades para falha do sistema ou, ainda, aumentar a sua vida
útil.

5.3. Contratos de manutenção com fornecedores

n

Os contratos de manutenção normalmente incluem ou um acordo entre:

 a área de TI e o seu cliente interno (SLA ‐ Service Level Agreement)
 um fornecedor de TI (underpinning contract / contrato de apoio) e uma instituição cliente e descrevem o serviço
oa

de TI, suas metas de nível de serviço, além dos papéis e responsabilidades das partes envolvidas no acordo.
Normalmente inclui:
o Disponibilidade (Service Availability)
o Tempo de Resposta
cel

o Tempo de Reposição
o Criticidade
o Forma de comunicação

6. Avaliação de sistemas de informação

rrr

Avaliar é a capacidade de explorar propriedades dos sistemas de informação, de forma a medir/descrever a diferença
que os sistemas fazem para as organizações e/ou para os utilizadores.

6.1. Objetivos da Avaliação

ma

 Melhorar os sistemas de informação;

 Tomar decisões com base em evidência;
 Promover o uso de sistemas de informação;
 Licenciar os sistemas de informação;
 Garantir a responsabilização e proteger contra acusações falsas.

6.2. Porquê avaliar

 Descrever e compreender problemas;
www.facebook.com/marrrceloandrade.com.br/ Página 10 de 11
www.marrrceloandrade.com.br [email protected]

 Verificar se o sistema foi bem construído;

 Validar o desempenho do sistema ‐ verificar se o sistema é capaz de resolver os problemas para os quais foi
desenvolvido;
 Fornecer evidência de boa qualidade;
 Descrever e compreender eventos inesperados posteriores à implementação do sistema.

br
6.3. Passos Gerais de uma Avaliação
 Definir e priorizar questões de estudo;


m.
Definir o sistema a avaliar;
 Selecionar ou desenvolver os instrumentos de avaliação/medição;
 Escolher a metodologia adequada;
 Garantir que os resultados da avaliação são generalizáveis;
 Realizar a avaliação/medição;


.co
Divulgar os resultados.

6.4. Problemas da Avaliação

 Avaliações limitadas:
o Falta de avaliação de novos recursos;
o Pouco envolvimento dos utilizadores finais;

de
 Variabilidade da qualidade das avaliações:
o Inadequação dos métodos;
 Falta de prática;
 Falta de liderança;
 Falta de financiamento.
n dra
oa
cel
rrr
ma

www.facebook.com/marrrceloandrade.com.br/ Página 11 de 11