• Nenhum resultado encontrado

4. Sistemas de Informação

4.6 O processo de desenvolvimento de sistemas de informação

4.6.2 Metodologias de desenvolvimento de sistemas de informação

Existe uma grande diversidade de metodologias de desenvolvimento de sistemas de informação, mas todas têm uma estrutura básica comun. As metodologias mais representativas deste conjunto são as seguintes:

- Metodologia básica de desenvolvimento de sistemas de informação.

Esta metodologia básica está baseada, principalmente, nas abordagens de Bio, Sergio (1996), Rebouças de Oliveira (1993), Burch e Grudnitsky (1993) e complementada com as abordagens de Laudon e Laudon apud Grupo TRW(1991) e Wetherbe (1984). Dá-se ênfase, principalmente, na parte de definição do sistema e análise da situação existente.

- Fases da metodologia

Primeira fase: definição do sistema de informação.

- Definir metas, objetivos, planos e políticas da organização. - Levantamento genérico da situação existente e análise inicial.

- Identificação das necessidades dos usuários, problemas e oportunidades existentes e principais fluxos de informação.

- Justificar o motivo de realização do trabalho.

- Definir os recursos humanos e materiais disponíveis.

- Definição dos objetivos e alcance do sistema de informação. - Viabilidade do sistema.

- Estabelecer uma equipe de projeto e estimar os recursos (humanos, tecnológicos e financeiros)

- Realizar o planejamento estratégico de desenvolvimento do sistema de informação.

- Análise do trabalho no sistema objeto, assim como de seu contexto: aplicação das ferramentas adequadas numa abordagem sistêmica.

- Levantamento das tarefas, atividades, principalmente, os processos humanos de tratamento da informação: algorítmicos, heurísticos e decisórios;

- Levantamento das necessidades de informação dos usuários.

- Identificar os problemas existentes em relação às exigências das atividades e avaliar a necessidade de mudanças organizacionais.

- Definição de objetivos e políticas do SIG congruentes com os da empresa;

- Definição e ponderação das forças do projeto: fatores humanos, interface, integração, forças competitivas, necessidade e qualidade da informação, fatores organizacionais, requisitos de custo e eficiência e requisitos de viabilidade.

- Definição dos requisitos e amplitude do sistema;

- Reformular o planejamento do trabalho, metodologia e recursos empregados

Terceira fase: Desenvolvimento do modelo conceitual.

- Estudo e avaliação de alternativas de solução.

- Decomposição do sistema em subsistemas e/ou blocos de construção. (pode-se utilizar a abordagem sistêmica e diagramas entidade - relacionamento) ;

- Características dos dados: padronização, propósito, modo e formato da transmissão;

- Fluxos de informação;

- Processamento da informação (modelos); - Reestruturação organizacional .

- Avaliação do modelo.

Quarta fase: Projeto e desenvolvimento detalhado do sistema

- Definição pormenorizada de dados de entrada, ciclos de procedimentos, relatórios ou saídas.

- Projeto do sistema de processamento: arquivos-modelos-fluxos, definição de programas.

- Programação, compilação e testes de programas. - Testes do sistema.

- Elaboração dos manuais de usuários e material de treinamento. - Documentação do sistema.

Quinta fase: Implantação

- Realizar treinamento.

- Providências físicas e organizacionais. - Operação.

Sexta fase: Acompanhamento.

- Avaliação do desempenho do sistema e realizar os ajustes necessários.

- Metodologia de desenvolvimento de sistemas de informação orientado a

objetos de D. A. Taylor

D. A. Taylor (1995), ressalta a necessidade de processos e sistemas de informações adaptáveis na organização, que possibilitem maior flexibilidade e que enfatizem mudanças graduais. Propõe, portanto, a “engenharia convergente” que se caracteriza por um único sistema integrado, ou seja, a convergência entre os sistemas de negócios e de software.

A base da engenharia convergente é o desenvolvimento de modelos de software ao invés de aplicativos. Esses modelos desempenham três funções:

representação, da estrutura e dos processos da organização de maneira uniforme;

simulação, isto é, projeções de operações futuras, incluindo necessidades de recursos e fluxo de caixa, além da análise das consequências de possíveis mudanças;

execução, execução de operações em tempo real, garantindo que estas sejam realmente executadas conforme o modelo.

Como os modelos nas organizações são complexos, a solução é o agrupamento que requer, primeiramente, um padrão representativo do todo e, segundo, que os itens dentro de um agrupamento não possam interagir diretamente com os de outro. Os grupos, portanto, devem ser encapsulados.

Para a construção de sistemas baseados em modelos, esta metodologia utiliza linguagens orientadas por objetos. Nela, cada objeto ou conceito do mundo real é representado por um objeto de software, assim como toda a informação e comportamento associados a ele. Assim, é possível a reprodução do comportamento empresarial fazendo os objetos desempenharem seus papéis dentro do modelo. Nesta linha, torna-se necessário um maior entendimento sobre objetos.

As definições, a seguir, estão baseadas nos trabalhos de Taylor (1995) e Pecego (1996).

Considera-se classe a definição genérica para objetos semelhantes, sendo estes enquadrados como a instância daquela classe.

Os objetos contém métodos e variáveis. Entende-se por métodos as sequências de instruções do computador que permitem ao objeto conduzir ações. Já variáveis são os locais onde as informações podem ser guardadas. Esses dois elementos compõem a classe do objeto.

Três relações básicas dão as conexões que unem os objetos em padrões significativos: especialização, colaboração e composição. A especialização diz respeito à divisão da classe em subclasses, formando uma hierarquia de classes. Como a subclasse herda todos os métodos e variáveis definidos na classe, se uma classe não contém esta definição ela procura ascendentemente seu caminho pela hierarquia até encontrá-la.

Os objetos enviam mensagens entre si para pedir serviços (interface de serviços). Nesta linha, a mensagem especifica o objeto receptor, nomeia o serviço desejado e adiciona valores específicos (parâmetros), que podem ser necessários para que o receptor atenda a requisição. Todavia, cabe ressaltar que a maneira como uma mensagem é manuseada é definida integralmente pelo objeto que a recebe, o que permite que um único serviço seja executado de várias maneiras (polimorfismo).

Na medida em que a maioria dos objetos de negócios contém outros objetos, esses são denominados objetos compostos, e os objetos que eles contém são conhecidos como objetos componentes. Como os objetos compostos contém referências de seus objetos componentes em vez de conter os próprios objetos, um objeto pode aparecer como um componente em qualquer número de objetos compostos (múltiplas composições).

Outra característica desta metodologia é a sua composição fractal. Um padrão fractal é aquele que exibe semelhanças próprias em múltiplos níveis. Um objeto fractal, neste sentido, é um tipo especial de objeto composto que contêm instâncias de sua própria classe como componentes, o que permite que objetos serviço percorram toda uma estrutura complexa sem programação adicional.

Cabe ser ressaltado ainda que em toda linguagem comercial de objetos há uma classe coleção predefinida que é projetada para conter grupos de outros objetos. Coleções oferecem serviços padrão para a adição, recuperação e remoção de objetos e elas podem aumentar ou diminuir seus tamanhos automaticamente com

base no número de objetos que estão mantendo em dado momento. Essas alterações não afetam o software nem desperdiçam os recursos de computação.