SISTEMATIZAÇÂO DOS TIPOS DE INFORMAÇÂO DO PLANEJAMENTO ESTRATÉGICO EMPRESARIAL E DE TECNOLOGIA DA INFORMAÇÂO E COMUNICAÇÂO Danilo Freitas Silvas Sistemas de informação CEATEC danilofs.ti@gmail.com Resumo: O objetivo desse trabalho foi, de posse das varáveis identificadas quando da elaboração do PEE e do PETIC, propor um Sistema de Informação que permita sistematizar esses processos de planejamento. A criação do SI utilizando-se de técnicas de análise de requisitos e modelagem de dados, criando diagramas de Caso de Uso e de Classes). Palavras Chave: Planejamento Estratégico Empresarial, Planejamento Estratégico de Tecnologia da Informação, Sistemas de Informação. Área de Conhecimento: 6.00.00.00-7 Ciências Sociais Aplicadas; 6.02.00.00-6 Administração. 1. PLANEJAMENTO ESTRATÉGICO De acordo com Audy (1999), atualmente para garantirem uma boa posição no mercado, visto o cenário extremamente competitivo, as organizações devem recorrer às suas capacidades de criar aplicações computacionais eficientes rapidamente, sendo assim ferramentas para o desenvolvimento de sistemas torna-se um dos pré-requisitos. Para que isto ocorra, no entanto, é necessária a elaboração de um Planejamento Estratégico de Tecnologia de Informação e Comunicação (PETIC), porém ele deve estar estrita e estrategicamente alinhado com o Planejamento Estratégico Empresarial (PEE) da organização. 1.1. O Planejamento Estratégico Empresarial Com o PEE conseguimos definir a visão de futuro da organização, a missão, quais objetivos devem ser alcançados, quais estratégias devem ser utilizadas, quais atividades devem ser executadas e por fim quais recursos são necessários para que os propósitos da organização sejam realmente satisfeitos. Estes são os produtos gerados quanto à elaboração do PEE. A visão estratégica é o caminho que a empresa deve percorrer para se chegar a um futuro desejado. Deve-se evidenciar a diferença entre visão e missão empresarial, a visão é a trajetória Orandi Mina Falsarella Informação para Gestão e Inovação CEA orandi@puc-campinas.edu.br para o futuro onde a empresa almeja alcançar, já a missão é a finalidade empresarial pela qual a organização existe. A missão é criada juntamente à empresa, quando o fundador identifica o que será produzido e/ou qual serviço será prestado. Através da visão estratégica é possível criar objetivos a serem cumpridos para que o caminho para o futuro seja alcançado. Os objetivos ditam quais e quando os resultados precisam ser alcançados, mas não dizem como devem ser conseguidos (MAINTZBERG; QUINN, 2001, p.20). Para que os objetivos e metas sejam alcançados são elaboradas as estratégias, estas que ditam como os objetivos devem ser conseguidos. Maintzerberg e Quinn (2001) também afirmam que uma estratégia, bem elaborada, ajuda a organizar e alocar os recursos de uma organização para uma postura viável, utilizando como base as suas competências e deficiências internas em relação às mudanças no ambiente antecipadas e providencias contingentes realizadas por oponentes inteligentes. Para que possam ser cumpridas tais estratégias são criados projetos, com prazos, recursos e produtos necessários. Nessa etapa do planejamento estratégico empresarial é possível pensar em iniciar o alinhamento com o PETIC, pelo fato de que os projetos podem ser projetos de Tecnologia de Informação e Comunicação (TIC). 1.2. O Planejamento Estratégico de Tecnologia de Informação e Comunicação Com o Planejamento de TIC também se decide onde a organização quer chegar e quais os recursos de TIC que serão necessários para suportar as decisões, representando o movimento de passagem da estratégia presente para a estratégia futura. (MAGALHÃES, 2008). Os Sistemas de Informação (SI) podem ser de grande contribuição para organização, facilitando tanto na comunicação e tomada de decisões como também em diversos outros processos que ocorrem dentro da empresa, eles são de grande importância em um PETIC e devem ser escolhidos estrategicamente.
Magalhães (2008) diz que para ser relevante nas organizações, o PETIC deve: alinhar os SI e a TIC com as metas dos negócios empresariais; explorar a TIC para vantagem competitiva; direcionar os seus recursos para uma gestão efetiva; desenvolver arquiteturas e políticas de tecnologia e por fim gerar um ambiente informacional que favoreça a geração de estratégias organizacionais. Portanto, pode-se concluir que os produtos gerados da elaboração de um PETIC são: o Portfólio de aplicações, os SI que serão implantados na organização; a Infraestrutura de TIC, envolvendo toda a arquitetura de redes, os bancos de dados, as maquinas e o local em si; os Recursos Humanos, os funcionários que trabalharão nos setores de TIC; Recursos Financeiros, o dinheiro que será direcionado para cada parte do planejamento, de acordo com o necessário. 2. A SISTEMATIZAÇÃO DOS PROCESSOS DE PLANEJAMENTOS ESTRATÉGICO EMPRESARIAL E ESTRATÉGICO DE TIC. Com tudo o que foi abordado até o momento, é possível propor um Sistema de Informação que permite sistematizar esses processos de planejamento, utilizando-se de técnicas de análise de requisitos e modelagem de dados, criando diagramas de caso de uso e de classes, conforme abordado pela UML Unified Modeling Language (BOOCH; RUMBAUGH; JACOBSON, 2000). Na engenharia de software são reunidas metodologias, métodos e ferramentas a serem utilizadas, desde a percepção de um problema até o desenvolvimento do sistema (CARVALHO, 2001). Essas metodologias também são conhecidas como paradigmas, eles são modelos de processos que sugerem quais são as fases para o projeto de desenvolvimento de um sistema. No entanto é o gerente de projeto que define quais fases serão necessárias para o seu projeto e como ele irá trabalhar, junto com sua equipe, em cada fase, criando sua própria metodologia. 2.1. Os paradigmas da engenharia de software. Há alguns paradigmas que são os mais conhecidos, tais como: o ciclo de vida clássico; o evolutivo; e o espiral, cada qual com suas vantagens e desvantagens. 2.1.1. Ciclo de vida clássico (paradigma em cascata) O ciclo de vida de sistemas é o método mais antigo de montagem de sistemas de informação (LAUDON, LAUDON. 2007. p.344). Como o nome, paradigma em cascata, sugere que as tarefas de cada estágio estejam concluídas para que se inicie o estágio seguinte. (LAUDON, LAUDON, 2007). Ele possui atividades prédefinidas, e são elas: Análise e especificação de requisitos; Projeto; Implementação e teste unitário; Interação e teste de sistema; Operação e manutenção. Cada fase do projeto no paradigma de cascata em sua finalização é encapsulado não podendo voltar atrás, gerando um documento onde é detalhado tudo sobre tal fase. Pode haver exceções para esse encapsulamento. A complexidade de uma aplicação é que vai influenciar se será utilizado ou não o paradigma do ciclo de vida clássico. SOMMERVILLE (2003) diz que as aplicações complexas e de grande porte, que exigem um nível de formalidade são as que se utilizam de tal paradigma. 2.1.2. Paradigma evolutivo O desenvolvimento evolucionário é indicado para sistemas pequenos e de médio porte, com um tempo de vida razoavelmente curto, no entanto para sistemas de grande porte ele se torna inviável e sua utilização para esses tipos de sistemas é particularmente grave (SOMMERVILLE, 2003). Esse problema com sistemas de grande porte se dá ao grande número de iterações que ocorrem na utilização deste paradigma. Essas iterações no desenvolvimento e a grande interação com os usuários do sistema são o ponto chave deste método. Esse paradigma é baseado no desenvolvimento e implementação de um produto inicial, onde os usuários o avaliam, assim sendo refinado em múltiplas versões até que o software final seja desenvolvido. (CARVALHO, 2001). 2.1.3. Paradigma espiral O paradigma espiral foi criado com o intuito de conter o melhor de cada paradigma, além de se focar na análise dos riscos, possibilitando ao desenvolvedor entender e reagir a eles em cada fase. SOMMERVILLE (2003) diz que seu conceito impõe que ao invés de ser representado como uma sequência de atividades (linear) com algum retorno entre as atividades, o processo é representado como uma espiral. Ainda segundo o autor, geralmente o ciclo mais interno da espiral pode estar relacionado com a viabilidade do sistema; o seguinte, com a análise e definição dos requisitos; o próximo, ao projeto do sistema, assim por diante.
No entanto não existem fases pré-definidas, ou fixas, neste paradigma. É no decorrer do planejamento que é definido a estrutura do processo de desenvolvimento de software e suas fases. É importante esclarecer que durante cada ciclo é permitido o uso de outros paradigmas, que melhor sem encaixam. Exemplo: no ciclo de análise de requisitos pode ser utilizado o paradigma evolutivo, que tem uma grande interação com os usuários de modo a diminuir os possíveis erros de interpretação. Nesse paradigma, a espiral pode ser dividida em quatro partes, chamadas de quadrantes, com atividades que as representam, são elas: 1. Definição de objetivos: São definidos os objetivos específicos para essa fase do projeto. São identificados os riscos do projeto e dependendo dos riscos, poderão ser planejadas estratégias alternativas. 2. Avaliação e redução de riscos: Para cada um dos riscos de projeto identificados, é realizada uma análise detalhada e são tomadas providencias para reduzir esses riscos. 3. Desenvolvimento e validação: Depois da avaliação dos riscos, é escolhido um modelo de desenvolvimento para o sistema. 4. Planejamento: O projeto é revisado e é tomada uma decisão sobre como continuar com o próximo loop da espiral. Pode se concluir que o desenvolvimento em espiral seja o mais adequado para o projeto de sistematização dos processos do PEE e do PETIC, por englobar as melhores características dos outros paradigmas. Por poder ter um ciclo inteiro focado em análise de requisitos, que é uma das partes mais importantes deste projeto, e a avaliação e redução de riscos, tornam esse método confiável. 2.2. A UML e seus diagramas A UML (Unified Modeling Language) é uma linguagem padrão para modelagem orientada a objetos. Ela engloba diversas notações (ferramentas) que podem ser usadas para descrever graficamente um projeto de sistemas, através de diagramas. Existem dois diagramas que são os mais utilizados, o diagrama de caso de uso e o diagrama de classes. Esses diagramas mostram, de formas distintas, o comportamento que o sistema deverá ter, suas ligações (relacionamentos) e suas características. 2.2.1. Digrama de caso de uso Booch; Rumbaugh; Jacobson (2000) afirmam que todo sistema interage com atores humanos ou autômatos que o utilizam para algum propósito e esses atores esperam que o sistema se comporte de acordo com as maneiras previstas. Um caso de uso especifica o comportamento de um sistema ou parte de um sistema e é a descrição de um conjunto de sequencias de ações. Sendo assim eles podem ser aplicados para compreender o comportamento de esperado do sistema que está sendo desenvolvido. Casos de uso bem-estruturados especificam apenas o comportamento essencial do sistema ou subsistema e não são amplamente gerais, nem muito específicos. (BOOCH; RUMBAUGH; JACOBSON, 2000). Um diagrama de caso de uso costuma conter o seguinte: Assunto; Caso de uso; Atores; Relacionamentos de dependência, generalização e associação. 2.2.2. Diagrama de classes Para entender um diagrama de classe primeiro é necessário entender o que é uma classe na orientação a objeto. Uma classe é a descrição de um conjunto de objetos que compartilham os mesmos atributos, operações e relacionamentos. Uma classe é representada graficamente por um retângulo. (BOOCH; RUMBAUGH; JACOBSON, 2000). Um objeto é a representação virtual de algo que existe no mundo real. As classes possuem um nome que as diferenciem de outras, possuem atributos, operações e algum tipo de relação (associação) com outra classe. Os diagramas de classe são os mais utilizados para fazer uma visão estática de um sistema. Essa visão oferece suporte para os requisitos funcionais deste mesmo sistema. (BOOCH; RUMBAUGH; JACOBSON, 2000). Um diagrama de classes mostra um conjunto de classes, interfaces e colaborações e seus relacionamentos. Os diagramas de classes costumam conter os seguintes itens: Classes Interfaces Relacionamentos de dependência, generalização e associação. O banco de dados de um sistema geralmente é criado baseado em um diagrama de entidaderelacionamento ou de um diagrama de classes, que é o mais utilizado na programação orientada a objetos.
Para fins esclarecedores, um banco de dados é um conjunto lógico de arquivos relacionados que armazenam dados e as associações entre eles. Contudo, a segurança e integridade dos dados aumentam deixando que os aplicativos e os dados para compreender o comportamento esperado do sistema que estará sendo desenvolvido. No caso é o sistema gerenciador de Planejamento Estratégico Empresarial e de Planejamento Estratégico de Tecnologia da Informação e Comunicação. ficam independentes entre si. (TURBAN, E; RAINER, R. K. Jr; POTTER, R. E, 2005). Os dados, de um banco de dados, só são acessíveis através de um sistema gerenciador de banco de dados. 3. RESULTADOS A partir dos dados coletados na pesquisa bibliográfica e com as estruturas informacionais, desenvolvidas no projeto do ano anterior pelo aluno Gustavo Francisco, orientado pelo Prof. Orandi Mina Falsarella, foi possível elaborar diagramas de caso de uso (figura 1) e de classes (Figura 2). Como já dito, o diagrama de caso de uso é utilizado Figura 1 Diagrama de Caso de Uso Os usuários desse sistema, tratados na UML como atores, são o gestor de PEE e o gestor de PETIC 3.1. Descrição dos Diagramas de Caso de Uso e de Classes O gestor de PEE poderá realizar a manutenção (entende-se por manutenção as ações de cadastrar, alterar e/ou excluir) da Visão da empresa, inserindo uma descrição da mesma, a visão possuirá, além da descrição, um campo de código que será preenchido automaticamente pelo sistema, esse atributo é responsável pela diferenciação de cada visão que o planejamento irá possuir. Figura 2 Diagrama de Classes
Esse mesmo ator também irá realizar a manutenção da Missão da empresa, caracterizada por um código e uma descrição, da mesma forma que a visão, o código será fornecido automaticamente pelo programa. Ao realizar um cadastro de Objetivo o gestor de PEE deverá, obrigatoriamente, associar a visão cujo esse objetivo estará ligado. O objetivo além da ligação com a visão também possui seu código e sua descrição. Um planejamento estratégico empresarial também possui Metas, o gestor deverá fornecer na manutenção dessa meta em quanto tempo e a quantidade a ser alcançada, assim como todos os outros, o seu código será fornecido automaticamente pelo sistema. No entanto uma meta não está solta em um planejamento, ela deve estar associada a um Objetivo. Definir uma Estratégia é uma importante tarefa para um gestor PEE, ao realizar a manutenção de uma estratégia o ator deverá informar a sua descrição, ou seja, como ela será enfatizada e também um código, porém é imprescindível que essa estratégia seja de um conjunto meta-objetivo, sendo assim o usuário deverá realizar uma ligação, no momento do cadastro/edição, com uma meta. Outra tarefa do gestor de PEE é cadastrar e manter Projetos, que tem como campos a serem preenchidos sua descrição, seu tempo de duração e também o responsável por tal projeto. Um projeto é de uma estratégia, sendo assim o ator deverá identificar a qual estratégia esse projeto está relacionado. Os projetos podem ser divididos em Projetos de Gestão e Projetos de TIC, é função do gestor do PETIC identificar quais projetos são de TIC. Além disso ele irá definir o Tipo de Projeto dentre esses que são de TIC, ou seja, se irão ser projetos de Portfólio de Aplicações e/ou Infraestrutura de TIC, podendo ser um, ou ambos. Um portfólio de aplicações possui um código, o nome do sistema, uma descrição do que ele irá fazer, e o Usuário Responsável, já de Infraestrutura de TIC possui um código, uma descrição de seu uso, o nome do equipamento, e a quantidade que será usada. Esses dados serão fornecidos/definidos pelo gestor de PETIC. O gestor de PETIC irá também definir os Recursos Financeiros (RF) e Recursos Humanos de tais projetos. A tela de manutenção de RH terá como campos o código (gerado automaticamente), a sua descrição, o cargo e a quantidade de vagas. Em RF o ator irá colocar a descrição do investimento, a sua finalidade e também o seu valor (custo), seu código será gerado pelo software. CONCLUSÕES Como pode ser percebido, é possível sistematizar a integração do PEE como PETIC de modo que esses dois processos de planejamento possam ser melhor gerenciados. A interação entre os atores e os casos de uso, permite modelar em um Sistema de Informação os principais processos existentes no PEE e no PETIC. Além disso, é possível representar as relações existentes entre eles por meio do Diagrama de Classes. Como continuidade desse trabalho poderia ser seguida as etapas da engenharia de software com o propósito de construir o SI ora proposto. REFERÊNCIAS BIBLIOGRÁFICAS AUDY, J. L. N.; BECKER, J. L.; FREITAS, Henrique. Modelo de planejamento estratégico de sistemas de informações: a visão do processo decisório e o papel da aprendizagem organizacional. XXIII ENANPAD, Foz do Iguaçu, 1999. BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML guia do usuário, Rio de Janeiro: Campus, 2000. CARVALHO, Ariadne M. B. R.; CHIOSSI, Thelma. C. S. Introdução à Engenharia de Software. São Paulo: Editora da Unicamp, 2001. LAUDON, K. C., LAUDON, J. P. Sistemas de informação gerenciais. 7ed. São Paulo: Pearson Prentice Hall, 2007. MAGALHÃES, L. H.; DE MAGALHÃES, T. M.. Planejamento Estratégico de Tecnologia da Informação, 2008. MINTZBERG, Henry; Quinn, O processo da estratégia. 3ed. Porto Alegre: Bookman, 2001. SOMMERVILLE, L. Engenharia de Software. ed. São Paulo: Addison Wesley, 2003. THOMPSON, Artur A; STRICKLAND III, A.J; GAMBLE, John. Administração Estratégica. 15ed. São Paulo, McGraw-Hill, 2008. TURBAN, E; RAINER, R. K. Jr; POTTER, R. E. Administração de tecnologia da informação: teoria e prática. Rio de Janeiro: Elsevier, 2005.