TECNOLOGIAS DA INFORMAÇÃO

3 REFERENCIAL TEORICO

Neste contexto, a utilização da Logística associada à Tecnologia de Informação é significativa para que a empresa alcance o objetivo almejado, ou seja, maior competitividade com as outras empresas do mercado. Estas ferramentas têm potencial para auxiliar a organização a obter tanto vantagem em custo e produtividade, como a vantagem em valor.

Segundo Porter (1989):

“A vantagem competitiva surge da maneira como as empresas desempenham suas atividades dentro da cadeia de valor”.

___________________________

PORTER, M. Vantagem Competitiva - Criando e Sustentando um Desempenho Superior. 17a ed. Rio de Janeiro: Campus, 1989.

3.1 TECNOLOGIA DA INFORMAÇÃO

Existem muitas definições para o termo informação, variando sensivelmente de autor para autor. Este trabalho cita algumas concepções, de autores diferentes, mostrando a sua importância como componente do processo de gestão organizacional.

A Tecnologia da Informação (TI) é um componente do Sistema de Informação como informação, ferramentas, políticas de trabalho e recursos humanos.

Segundo Spinola e Pessôa, (1998, p.98):

A Tecnologia da Informação reúne as contribuições da Tecnologia e da Administração, estabelecendo, assim, uma estratégia integrada, permitindo projetar e instalar sistemas de informação e as coerentes mudanças organizacionais, ou ainda, pode ser definida como a adequada utilização de ferramentas de informática, comunicação e automação, juntamente com as técnicas de organização e gestão, alinhadas com a estratégia de negócios, com o objetivo de aumentar a competitividade da empresa.

3.1.1 SISTEMAS DE INFORMAÇÃO

É a expressão utilizada para descrever sistema seja ele automatizado (que pode ser denominado como Sistema de Informação Computadorizado), ou seja manual, que abrange pessoas, máquinas, e/ou métodos organizados para coletar, processar, transmitir e disseminar dados que representam informação para o usuário e/ou cliente.

Segundo Spinola e Pessôa (1998, p.98):

Um “Sistema de Informação (S.I.) é um sistema que cria um ambiente integrado e consistente, capaz de fornecer as informações necessárias a todos os usuários” ou ainda, como Schutzer e Pereira (1999, p.149) “é um sistema integrado homem-máquina que fornece informações de suporte a operações, gerenciamento, análise e funções de tomada de decisões em uma organização.”

___________________________

SPINOLA, Mauro, PESSÔA, Marcelo. Tecnologia da Informação. In: Gestão de Operações. 2a ed. Professores

do Departamento de Engenharia da escola Politécnica da USP e da Fundação Carlos Alberto Vanzolini. São Paulo: Editora Edgard Blücher,1998, cap.4. p.97-104. .

Rezende e Abreu (2000, p.62):

Ao unir Sistema de Informação e Tecnologia da Informação, define estes como “um conjunto de software, hardware, recursos humanos e respectivos procedimentos que antecedem e sucedem o software”.

___________________________

REZENDE, Denis A., ABREU, Aline F., Tecnologia da Informação aplicada a sistemas de informação

empresariais: o papel estratégico da informação e dos sistemas de informação nas empresas. São Paulo: Atlas,2000.

3.2 ANALISE DE SISTEMAS

3.2.1 DEFINIÇÃO DE REQUISITOS DO SISTEMA

As descrições das funções e das restrições são os requisitos para o sistema e o processo de descobrir isto é chamado de engenharia de requisitos.

Se uma empresa deseja estabelecer um contrato para desenvolvimento de um grande projeto de software, ela tem de definir suas necessidades de maneira suficientemente abstrata para que uma solução não seja predefinida. Os requisitos devem se redigidos de modo que os diversos fornecedores possam apresentar propostas, oferecendo, talvez, diferentes maneiras de atender às necessidades organizacionais do cliente. Uma vez estabelecido um contrato, o fornecedor precisa preparar uma definição de sistema para o cliente, com mais detalhe, de modo que o cliente compreenda e possa validar o que o software fará. Esses dois documentos podem ser chamados de Documentos de requisitos do Sistema.

Alguns dos problemas que surgem durante o processo de eng. de requisitos são resultados da falta de uma nítida separação entre esses diferentes níveis de descrição. Os diferentes níveis são os requisitos de usuário para designar os requisitos abstratos de alto nível, e os requisitos de sistema, para indicar a descrição mais detalhada do que o sistema deverá fazer, e a especificação de projeto de software para associar a eng. de requisitos e as atividades de projeto.

REQUISITOS DO USUARIO

São declarações, em linguagem natural e também em diagramas, sobre as funções que o sistema deve fornecer e as restrições sob as quais deve operar.

REQUISITOS DO SISTEMA

Estabelece detalhadamente as funções e as restrições de sistema. O documento de requisitos de sistema deve ser preciso. Ele pode servir como contrato entre comprador do sistema e o desenvolvedor do software.

ESPECIFICAÇÕES DE PROJETO DE SOFTWARE

É uma descrição abstrata do projeto de software (SW) que é uma base para o projeto e a implementação mais detalhados.

DEFINIÇÃO DOS REQUISITOS DO USUÁRIO

1. O Software deve oferecer um meio de representar e acessar arquivos externos criados por outras ferramentas.

ESPECIFICAÇÕES DOS REQUISITOS DO SISTEMA

1.1 O usuário deve dispor de recursos para definir o tipo dos arquivos externos.

1.2 Cada tipo de arquivo externo pode ter uma ferramenta associada que pode ser aplicada a ele.

1.3 Cada tipo de arquivo externo pode ser representado como um ícone especifico na tela do usuário.

1.4 Devem se fornecidos recursos para o ícone que representa um arquivo externo, a ser definido pelo usuário.

1.5 Quando um usuário seleciona um ícone que representa um arquivo externo, o efeito dessa seleção é aplicar a ferramenta associada com tipo de arquivo representado pelo ícone selecionado.

3.2.2 REQUISITOS FUNCIONAIS

Os requisitos funcionais para um sistema descrevem a funcionalidade ou os serviços que se espera que o sistema forneça. Eles dependem do tipo de software que está sendo desenvolvido, dos usuários de software que se espera verificar e do tipo de sistema que está sendo desenvolvido.

Os requisitos funcionais de um sistema de software podem ser expressos de diversas maneiras.

Aqui estão os requisitos funcionais do sistema de gerenciamento básico recarga de cartucho:

1. O usuário deverá ser capaz de buscar todo o conjunto inicial de banco de dados ou selecionar um subconjunto a partir dele.

2. O sistema fornecerá telas apropriadas para o usuário ler documentos no repositório de documentos.

3. Cada pedido será alocado a um único identificador (order_id), que o usuário poderá copiar para a área de armazenamento permanente de conta.

Esses requisitos funcionais de usuário definem recursos específicos que devem ser fornecidos pelo sistema. Muitos problemas de engenheiro de SW se originam da imprecisão na especificação de requisitos. É natural para um desenvolvedor de sistemas interpretarem uns requisitos ambíguos para simplificar sua implementação.

Em princípio, a especificação de requisitos funcionais de um sistema deve ser completa e consistente. A completeza significa que todas as funções requeridas pelo usuário devem estar definidas. Na pratica é quase impossível atingir as metas citadas em sistemas complexos e grandes. Essas inconsistências podem não ser obvias quando os requisitos são especificados primeiramente, os problemas surgem depois de uma análise mais profunda devem ser corrigidos conforme são descobertos.

3.2.3 REQUISITO NÃO FUNCIONAIS

Os requisitos não funcionais são aqueles que não dizem respeito diretamente ás funções especifica do sistema. Isso significa que eles são mais importantes do que os requisitos funcionais individuais, pois uma falha neles podem degradar o sistema, uma falha nos requisitos não funcionais pode tornar o sistema inútil, um sistema de aviação que não atender a seus requisitos de confiabilidade não será atestado como seguro para operação.

Alguns requisitos não funcionais podem restringir o processo que pode ser utilizado para desenvolver o sistema. São exemplos de requisitos de processo umas especificações dos padrões de qualidade, que deve ser utilizada no processo, uma especificação de que o projeto deve ser produzido com um conjunto especificado de ferramentas CASE e uma descrição de processo a ser seguido.

Os diferentes tipos de requisitos não funcionais:

1. Requisitos de produtos são os que especificam o comportamento do produto. Entre exemplos estão os requisitos de desempenho sobre com que rapidez o sistema deve operar e quanta memória ele requer, os requisitos de confiabilidade, que estabelecem a taxa aceitável de falhas, os requisitos de portabilidade e os requisitos de facilidade de uso.

2. Requisitos organizacionais são procedentes de políticas e procedimentos nas organizações do cliente e do desenvolvedor. Entre exemplos estão os padrões de processos devem ser utilizados.

3. Requisitos externos esse amplo tópico abrange todos os requisitos procedentes de fatores externos ao sistema e a seu processo de desenvolvimento. Dentre eles destacam-se os requisitos de interoperabilidade, que definem como o sistema interage com sistemas em outras organizações, os requisitos legais, que devem ser seguidos para assegurar que o sistema opera de acordo com a lei. Os requisitos éticos são definidos em um sistema para garantir que este será aceitável para seus usuários e o público em geral.

A classificação dos diferentes tipos de requisitos não funcionais que podem surgir:

Um problema comum com os requisitos não funcionais é que eles são de difícil verificação, eles podem ser escritos para refletir os objetivos gerais do cliente, como a facilidade de uso, a habilidade de o sistema se recuperar de uma falha ou a rapidez de resposta ao usuário. Esses requisitos causam problemas para os desenvolvedores de sistema, à medida que eles deixam o enfoque aberto à interpretação e à consequente discussão, quando o sistema é entregue.

Os requisitos não funcionais devem ser expressos quantitativamente, utilizando-se métricas que possam ser objetivamente testadas.

_____________________________

Sommerville, Ian. Engenharia de Software, 6º Edição. São Paulo: Addison Wesley, 2003.