pim pronto gestao ti

PIM PRONTO - GESTÃO DA TECNOLOGIA DA INFORMAÇÃO PREFEITURA DE CURITIBA/PRSUMÁRIO E CONTEÚDO:

SUMÁRIO.

01. INTRODUÇÃO.......................................................................................04

02. PROJETO DE REDE.............................................................................06

03. MODELO DE PROCESSO DE SEGURANÇA E CRIPTOGRAFIA......08

04. SISTEMA DE BANCO DE DADOS.......................................................12

05. ESTRUTURA NECESSÁRIA PARA A PREFEITURA..........................15

06. REQUISITOS DO SISTEMA..................................................................17

07. TREINAMENTO TÉCNICO....................................................................19

DICAS INTERESSANTES DE ADAPTAÇÃO DO SEU TRABALHO:

SUBSTITUA NESTE DOCUMENTO PALAVRAS COMO SEGUNDO - COLOQUE DE ACORDO

DEFINIÇÃO - COLOQUE CONCEITUAÇÃO, EXPLICITAÇÃO OU QUALQUER COISA RELACIONADA A

CONCEITO OU COLOCAÇÃO DE OBJETIVIDADE PARA DEFINIR.

NO LUGAR DE OBJETIVO TODA VEZ QUE TIVER, COLOQUE META OU ASPIRAÇÃO CONDICIONAL.

ASSIM SENDO, SUBSTITUA POR DESTA FORMA.

BIBLIOGRAFIA PARA ADICIONAR, MUDAR, USAR NESTE TRABALHO

ALBERTIN, Alberto Luiz ; Albertin, Rosa Maria de Moura. Tecnologia de Informação e Desempenho Empresarial. São

Paulo: Atlas, 2005. [Inf.]

______. Administração de informática: funções e fatores críticos de sucesso. 5 ed. São Paulo: Atlas, 2004.[Inf.]

ALBERTIN, Alberto Luiz; ALBERTIN, Rosa Maria de Moura. Aspectos e contribuições do uso de tecnologia de

informação. São Paulo: Atlas, 2006.[Inf.]

AUDY, Jorge L. N.; BRODBECK, Ângela F. Sistemas de Informação: planejamento e alinhamento estratégico nas

organizações. Porto Alegre: Bookman, 2003. [Inf.]

BALDAM, Roquemar; VALLE, Rogério; PEREIRA, Humberto; HILST, Sérgio; ABREU, Maurício; SOBRAL, Valmir.

Gerenciamento de Processos de Negócios - BPM - Business Process Management. São Paulo: Érica, 2005. 240

p. [Inf.]

BEAL, Adriana. Segurança da informação: princípios e melhores práticas para a proteção dos ativos de informação

nas organizações. São Paulo: Atlas, 2005. 180 p. [Inf.]

BOGHI, Claudio; SHITSUKA, Ricardo. Sistemas de Informação: um enfoque dinâmico. 3 ed. São Paulo: Erika,

2002. [Inf.]

CARDOSO, Mário S. CRM em ambiente E-business: como se relacionar com clientes, aplicando novos recursos da

web. São Paulo: Atlas, 2001. 160 p. [Inf.]

COLANGELO FILHO, Lúcio. Implantação de ERP. São Paulo: Atlas, 2001. [Inf.]

GRAEML, Alexandre Reis. SISTEMAS DE INFORMAÇÃO: O Alinhamento da Estratégia de TI com a Estratégia

Corporativa. 2 ed. São Paulo: Atlas, 2003. 160 p. [Inf.]

GREENBERG, Paul. CRM na velocidade da luz. Rio de Janeiro: Campus, 2001. [Inf.]

HELDMAN, Kim. Gerência de projetos: guia para o Exame Oficial do Pmi. 2 ed. Rio de Janeiro : Campus, 2006. [Inf.]

JOHNSON, Grace E.; SATHLER, André. Sistemas de Informações: administração em tempo real. Rio de Janeiro:

Qualitymark, 2007. [Inf.]

KAPLAN, Robert S.; NORTON, David P. Alinhamento: utilizando o Balanced Scorecard para criar sinergias

corporativas. Rio de Janeiro : Campus, 2006. [Inf.]

LAUDON, Kenneth C.; LAUDON, Jane P. Sistemas de informação gerenciais: administrando a empresa digital. São

Paulo: Prentice Hall, 2004. [Inf.]

LAURINDO, Fernando.J.B. Tecnologia da Informação: eficácia nas organizações. São Paulo: Futura, 2002, 248

p. [Inf.]

LAURINDO, Fernando.J.B. Estratégias para Competitividade. São Paulo: Futura, 2003. [Inf.]

MAGALHÃES, Ivan L.; PINHEIRO, Walfrido B. Gerenciamento de serviços de ti na prática: uma abordagem com

base na ITIL. São Paulo: Novatec, 2007. [Inf.]

MANAS, Antonio V. Administração de Sistemas de Informação. 7 ed. São Paulo: Futura, 2003.[Inf.]

MCGEE, James.; PRUSACK, Laurence. Gerenciamento Estratégico da Informação. Rio de Janeiro: Campus,

1994. [Inf.]

POTTER, Richard E.; TURBAN, Efraim; RAINER JR, R. Kelly. Administração de Tecnologia da Informação. 3 ed. Rio

de Janeiro: Campus, 2005. [Inf.]

REZENDE, Denis A. Tecnologia da informação integrada à inteligência empresarial: alinhamento estratégico e

análise da prática nas organizações. São Paulo: Atlas, 2002.[Inf.

_____. Planejamento de sistemas de informação e informática: guia prático para planejar a Tecnologia da Informação

integrada ao planejamento estratégico das organizações. 2 ed. São Paulo: Atlas, 2007. [Inf.]

ROSSINI, Alessandro M.; PALMISANO, Ângelo. Administração de sistemas de informação e a gestão do

conhecimento. São Paulo : Thomson, 2003. [Inf.]

SOUZA, Cesar A.; SACCOL, Amarolinda Z. Sistemas ERP no Brasil: teoria e casos. São Paulo : Atlas, 2003. [Inf.]

STAIR, Ralph M.; REYNOLDS, George W. Princípios de sistemas de informação. 5 ed. São Paulo : Thomson,

2005. [Inf.]

SWIFT, Ronald S. CRM. Rio de Janeiro: Campus, 2001. [Inf.]

VIEIRA, Marconi F.Gerenciamento de projetos de tecnologia da informação. 2 ed. Rio de Janeiro: Campus, 2006.[Inf.]

TAPSCOTT, Don; WILLIAMS, Anthony D. Wikinomics: como a colaboração em massa pode mudar o seu negócio.

Rio de Janeiro: Nova Fronteira, 2007. 368 p. [Inf.]

TURBAN, Efraim; RAINER JR, R. Kelly; POTTER, Richard E. Introdução a sistemas de informação: uma abordagem

gerencial. Rio de Janeiro: Elsevier, 2007.[Inf.]

YIN, Robert. Estudo de Caso: Planejamento e Métodos. Porto Alegre: Bookman, 2001. [Inf.]

___________________________________________________________________________________

TRABALHO

01. INTRODUÇÃO.

Nos anos mais recentes a Internet, em particular a World Wide Web (WWW) - ou sigladamente chamada de Web -

tem se tornado a mídia preferida para transmissão e disseminação de inúmeras informações, acesso a dados

pessoais/empresariais e consultas tem sido enorme.

Facilitando neste contexto a idéia de criação de aplicações ligadas a distribuição de informações de maneira

integrada, criação de sistemas multi-plataforma, como comércio eletrônico, bibliotecas virtuais, educação a distância

e sistemas hipermídia, vêm sendo desenvolvidas neste tipo de programas de computadores ultra gestores.

Intertextualmente os chamados Sistemas Gerenciadores de Banco de Dados (SGBDs) apresentaram um grande

progresso e já se tornam componentes elementares dos mais complexos sistemas de informação, neste caso serão

administradores automáticos de registros diversos, um deles é o documento de identidade digital.

Um certificado digital é um documento de identidade eletrônico que tem o objetivo de identificar uma pessoa,

empresa ou sistema computacional no mundo dos computadores ou da internet. (INFO WESTER, 2010, texto online).

A mais ampla definição de gerenciamento de um banco de dados é a capacidade de agregar informações em um

mesmo contexto tecnológico, servindo como uma forma de codificar dados diversos, de acordo com Brumley e Boneh

(2010):

Um certificado digital possui informações sobre a entidade para a qual foi emitido (no caso de uma pessoa, possui o

seu nome, CPF etc.). Além destes dados, contém uma sequência de código conhecida como chave pública.

(BRUMLEY e BONEH, 2010, p.1).

Cada vez mais a automação é parte do processo de gestão de banco de dados visto a um volume de informações

disponível na Web vem crescendo exponencialmente, exigindo que haja o estabelecimento de maior integridade da

informação e seu melhor compartilhamento em redes complexas. (QUARESMA, 2010).

Exige neste contexto a chamada interação relacional, pois a razão de ocorrer sistemas gerenciadores de banco de

dados, é a necessidade de dar utilidade plausível a coleções de programas que permitam criação e administração

real de bancos de dados integrais e completos através de troca de mensagens entre emissores conectados.

No planejamento de teoria acerca do uso desta tecnologia sobre a presunção a questão da certificação de dados

integrados digitais, é interessante salientar a autenticação como a principal motivação para a criação de ligações

simétricas entre sistemas receptores e sistemas emissores.

Uma assinatura digital visa garantir a autoria de uma mensagem, e portanto a chave usada para a assinatura deve

estar nas mão de uma única pessoa: o emissor que assina digitalmente a mensagem. Como na criptografia por

chaves simétricas é necessário que emissor e receptor sempre possuam a mesma chave, ela não se torna

apropriada para fins de autenticação. (BRUMLEY e BONEH, 2010, p.1).

Apropriando-se a sistematização deste panorama segundo a idéia de se permitir a livre inserção de dados ou a

descrição dos fatos que se quer registrar.

02. MODELOS DE BANCO DE DADOS.

Bancos de Dados que tem como objetivo o armazenamento de informações em escala massificada, irão solicitar de

seus manipuladores modelos e métodos especiais para armazenamento.

No caso de projetos do tamanho e magnitude exposta pelo manual deve fazer com que seu administrador tenha em

mente a concepção de necessidade de obter um sistema gerenciador de banco de dados, ou melhor, um conjunto de

dados interrelacionados e gerenciados logicamente, os SGBD’S são exemplos de programas de computador

direcionados com tal finalidade, por essa razão a proposta de estudo inicial para implantação de um modelo de banco

de dados será norteado por este conceito.

De acordo com Elsmari (2002) este é o tipo mais popular de sistema de banco de dados, pois permite inúmeras

funções: definição da plataforma/formato dos dados, armazenamento, operações relacionadas diretamente a

recuperação de dados e criação de restrições de integridade.

Segundo concordância teórica de Korthe (1999, p.44) são fórmulas de conjunto de dados estritamente relacionais, ou

seja: “Em um banco de dados desta natureza, os dados e as relações entre eles estão organizados em TABELAS,

formalmente chamadas de RELAÇÕES. Alguns campos podem ser designados como chaves, o que significa dizer

que a procura por certo tipo de informação pode ser acelerada utilizando as indexações criadas com as chaves”.

Já para a concisão definitiva de estudiosos como Heuser (2004) que acreditam em operacionalidade e livre

manipulação expansora, um sistema gerenciador de banco de dados é muito mais que acesso convergente a

informação e sim uma transcendência a isto, através de transformar os dados em uma informação final bem definida,

conforme se explana a seguir em passagem extraída de seu estudo:

Oferece aos seus usuários acesso a dados e os ajuda a transformar estes dados em informações. Estes sistemas

permitem aos usuários criar, atualizar e extrair informações de suas bases de dados. Comparados a um sistema de

ficheiro manual, as principais e maiores diferenças para um banco de dados computadorizado são velocidade,

precisão e acessibilidade. Um banco de dados é uma coleção de dados estruturada. E estes dados se referem às

características de pessoas, coisas ou eventos. (HEUSER, 2004, p.47)

Os sistemas SGBD podem ser de diversos formatos, sendo os principais aplicações via web ou aplicações off line

ligadas a gerenciamento em massa de dados.

As aplicações via web inclinam-se a serviços de transição e as aplicações off line a consolidação da consistência dos

dados tratados e salvos em sua estrutura programática.

No contexto off line são sistemas que de acordo com a nuança técnico-teórica e técnico-analítica de Singh (2001,

p.99) servem para fazer as informações serem permanentes e verdadeiras podem ser mudadas durante específicos

processos básicos, sendo que as transações e operações manuais ou automáticas serão capazes de reversão ou

reconfiguração, dando uma noção de durabilidade a informação/dado renovado, excluído, modificado, etc:

Significa que os resultados de uma transação são permanentes e podem ser desfeitos somente por uma transação

subseqüente.Por exemplo: todos os dados e status relativos a uma transação devem ser armazenados num

repositório permanente, não sendo passíveis de falha por uma falha de hardware.

No ambiente on line, os sistemas gerenciadores de banco de dados podem buscar o isolamento para evitar

fenômenos como repetições e concorrência de acessos/dados/usuários, além de controlar o acesso de usuários a

específicas áreas do sistema, classificando cada usuário que gira este sistema

Cada transação funciona completamente à parte de outras estações. Todas as operações são parte de uma

transação única. O principio é que nenhuma outra transação, operando no mesmo sistema, pode interferir no

funcionamento da transação corrente(é um mecanismo de controle). Outras transações não podem visualizar os

resultados parciais das operações de uma transação em andamento.

Assim um Sistema Gerenciador de Banco de Dados irá funcionar no seguinte esquema explicitado no Quadro

Abaixo:

Interface com Usuário / Gerência de Visões⇳Controle Semântico / Verificação de Autorização⇳Decomposição da Consulta e Otimização⇳Execução da Consulta⇳Gerência de buffer / Métodos de Acesso⇳Controle de Concorrência / Controle de Reconstrução (logging)

Quadro 01. Características de um Sistema Gerenciador de Banco de Dados.

São programas utilizados para traduzir a lógica de operações fechadas em um database, privilegiando controles e

formas de verificação de autenticidade, exclusividade, individualidade e consultas de informações.

Este projeto deve utilizar aplicativos relacionados a uma linguagem de consultas estruturadas, como soluções em

SQL, onde sua principal função é similar ao contexto da principal forma de solução apontada por Date (2000) que é o

de fazer manipulação e controle dos dados em uma esfera puramente relacional.

Um sistema SQL instalado em um sistema como o da prefeitura de Curitiba em um contexto off line, daria a todos os

cadastros e solicitações de um documento de identidade digital uma maior solidez e organização, além disto,

ofereceria um intenso contexto de processamento de dados para mapear o andamento de confecção e entrega

destes documentos, etc.

De acordo com a literatura especializada, um sistema SQL ajuda nos seguintes parâmetros de qualidade de

tratamento de informações em cadeia:

o Alto poder de consulta

o Gerenciamento de índices

o Construção de visões

o Execução de instruções em blocos

É um sistema que funciona sob três paradigmas fundamentais do gerenciamento de dados, ou seja, sob as égides

universais de funcionamento deste tipo de solução informático-administrativa, que de acordo com Singh (2001) apud

Date (2000), estes citam que um sistema de banco de dados consolida-se os seguintes estágios de tratamento da

informação:

▪ projeto: representação do minimundo em vários níveis de abstração

▪ construção: definição da estrutura do banco de dados;

▪ povoamento: manipulação dos dados do Banco de Dados usando operações de busca ou atualização. (SINGH,

2001 apud DATE, 2000, p.214)

Já para aplicações web que irão ser acessadas e suportadas por um suíte especial, será indicado uma solução CGI

com tipificação puramente em linguagem PERL, ligadas a uma administração de arquivos e recursos em plataforma

PHP para troca contínua de dados.

Funcionando conforme um acesso a partir de um cliente web remoto que acessa informações no ambiente aberto da

internet e estas informações são lidas por um servidor web – aplicação CGI – esta a partir deste momento fica por

conta de fazer transições e comunicações entre servidores de transação externo e interno ao banco de dados.

Os protocolos de gestão dos dados favoreceram a seqüência lógica de transformação dos dados em um ambiente

não on line, isto é, off line, agregando uma aplicação CGI com uma estrutura PHP ocorre as seguintes plataformas de

estabelecimento conectivo de informações, como segue:

Primeiro passo: estabelecer uma conexão com o SGDB MySQL.

Segundo passo: selecionar o banco de dados utilizado.

Terceiro passo: executar a SQL desejada.

Quarto passo: fechar a conexão

O SQL simplifica a gestão de dados, pois um sistema também gerenciador como este é em relação a métodos

como

Figura 01. Esquema de Funcionamento de um SGBD via web.

Essa união conformam a idéia de flexibilidade e compactabilidade entre trocas feitas no ambiente online e que

posteriormente ficam armazenados em sistemas internos particulares.

Segundo lembra Soares 1995 todo tipo de trocas entre ambientes web e não web são tangenciabilizados por uma

coordenação maciça ente um determinado fluxo de pedidos que aconteçam no ambiente do cliente Web e os

programas de aplicação (compostos por vários componentes de aplicação), que podem processar os pedidos junto

ao SGBD como um agente facilitador do processo em voga.

O desempenho da arquitetura depende muito da carga da rede devido ao transporte do código móvel. Além disso, a

execução do código móvel na máquina cliente pode sobrecarregá-lo. A implementação de aplicações nesta

arquitetura exige o conhecimento da linguagem de código móvel e de funções específicas para a realização de

transações sobre o SGBD. A linguagem Java é suportada pela grande maioria dos browsers existentes, o que diminui

problemas de portabilidade da arquitetura. (TANEMBAUM, 1996, p.46)

03. SEGURANÇA DA REDE.

Um sistema de segurança em banco de dados deve servir como um sistema ligado a quatro objetivos elementares de

proteção da informação, citados em Davies (1989) que já antecipava mesmo em sistemas menos complexos que os

de hoje, que databases precisam de fatores de protetividade conseguintes:

Confidencialidade

Integridade

Autenticação

Não-repúdio

Exige-se que a gestão dos dados em redes seguras sejam estabelecidas por meio da criação de chaves públicas e

chaves privadas, além do uso agregado/juntor entre uma metodologia padding – definição de enchimento de valores,

onde valores desnecessários em termos de registros são usados para que haja a consecução entre a transformação

de uma chave fixa ou não em chave primitiva com assinatura de mensagem especificada, como foi respaldado em

Rhodes (1996) que apresenta a idéia conseguinte sobre este processo:

S = SigPrim (private key, Transform (Hash (M)))

Aplica-se uma primitiva de assinatura à uma chave privada e à transformação do valor hash da mensagem.

(RHODES, 1996, p.49-51).

A criptografia é um conjunto de dados mascarados sob chaves privadas e chaves públicas que possuem um hash –

tamanho de código – isto faz com que se defina a capacidade de mascarar-se dados integrados, assim sendo, o

processo de segurança em redes é gerido por uma concepção de acompanhamento ao padrão de um agente

certificador específico estritamente, procurando adquirir algorritmos que facilitem a encriptação dos dados por meio

da conjunção entre chaves simétricas e chaves assimétricas, ambas devem estabelecer um elo entre emissor e

receptor da requisição:

É necessário que emissor e receptor sempre possuam a mesma chave, ela não se torna apropriada para fins de

autenticação. (COMER, 1991, p.49).

Na verdade é a criptografia é a protetora de uma transação lógica, mantendo o estado íntegro dos dados que se

transformam em informação, este estado consistente antes e posteriormente a conclusão da transição só poderá ser

mantido se houver perspectiva de chegada aos eventos seguintes:

❖ Um mecanismo de transação garante que toda transação iniciada ou termina com sucesso ou é desfeita.

❖ Transações de diferentes usuários que envolvem dados compartilhados são executadas em seqüência.

❖ Transações controlam melhor a concorrência e a reconstrução

Então nosso projeto deve garantir a proteção dos dados geridos tanto no contexto off line quanto online, assim

sendo, os padrões de segurança de criptografia adotados serão o sistema DAC (Discretionary Access Control) –

segmentado no acesso dos dados somente através de permissões baseadas em privilégios de acesso.

O objetivo da criptografia é esconder o conteúdo, para que este não esteja acessível a terceiros, enquanto a

assinatura digital visa garantir a autoria do documento, e que a mensagem não tenha sido modificada durante sua

transmissão. (STALLINGS, 1999, p.104).

O desenho do sistema de acesso a informações via plataforma DAS deve ser garantido por uma análise prévia de

Risco, obedecendo à norma de projetos de arquitetura de sistemas da Norma ISSO/IEC 12207, esta é uma norma

que está destacada no Anexo A e serve para mensurar o caráter técnico e informático gerencial das estruturas de

software e gestão de hardwares do prospecto informático a ser instalado.

– Identificar e priorizar valores (patrimônio)

– Identificar vulnerabilidades

– Identificar ameaças e suas probabilidades

– Identificar contra-medidas (respostas)

– Desenvolver análise de custo-benefício

– Planejar políticas e procedimentos de segurança. (CANAVAN, 2001).

04. TOPOLOGIA DA REDE.

05. ESTRUTURA NECESSÁRIA PARA A PREFEITURA.

Esta deve ter uma estrutura informática mínima que obedeça as injunções de Canavan (2001) este destaca que um

servidor com sistema operacional altamente gerencialista e um computador com recursos avançados seja o começo

de estruturação de uma rede compacta de troca de informações.

Pode propor-se que sejam instalados:

1 SERVIDOR COM BANCO DE DADOS MICROSOFT SQL SERVER 2000:

- Pentium IV, 2 GHz

- 1 GB RAM

- HD "grande" (o tarifador gasta 1 GB para cada 1 milhão de ligações telefônicas armazenadas) e “rápido”

(recomenda-se SCSI), preferencialmente espelhado.

- 1 Interface ethernet

- WINDOWS 2000 SERVER

- Banco de dados Microsoft SQL Server 2005, com 20 licenças.

- Modem + software de tele-suporte Symantec PC Anywhere

1 COMPUTADOR PARA E SERVIDOR WEB:

- Pentium IV, 2 GHz

- 1 GB RAM

- 80 GB HD, preferencialmente espelhado

- 1 Interface ethernet

- Windows 2000 ou superior

- Servidor WEB Microsoft IIS

- Modem + software de tele-suporte Symantec PC Anywhere

06. REQUISITOS LICITATÓRIOS.

Este projeto deve ganhar como princípios de requisição técnica de aprovação a possíveis bases formalizadas

e que atestam certificação real e autentica de que as empresas que entraram no projeto para construção deste

sistema possam estar aptas a empreender um projeto tão importante e complexo de fato:

- Serviço de implantação deve ser elaborado por Empresas que já tenham projetos pioneiros na área e que a

prestação de serviços esteja alinhada a pesquisa e desenvolvimento de tecnologias especiais conforme o art.IV da

presente lei normatizadora;

- Todos os projetos devem ser avaliados com o objetivo de estar presente a duas preocupações elementares a

excelência do projeto, assim sendo, tem-se a valorização das habilitações conseguintes segundo o Art. 27. Para a

habilitação nas licitações exigir-se-á dos interessados os seguintes cômputos:

I - habilitação jurídica;

II - qualificação técnica;

- Privilegiar empresas que adotem diferencialmente de acordo com art.45 – inciso II - a melhor técnica como item de

discriminação e seleção principal ou de minerva;

O art 46 é sempre o principal neste contexto será a principal preocupação já que visando o custo benefício, o projeto

a ser aprovado e com o qual se estabeleça maior fidelidade aos pontos já citados no estudo anterior:

Art. 46. Os tipos de licitação "melhor técnica" ou "técnica e preço" serão utilizados exclusivamente para serviços de

natureza predominantemente intelectual, em especial na elaboração de projetos, cálculos, fiscalização, supervisão e

gerenciamento e de engenharia consultiva em geral e, em particular, para a elaboração de estudos técnicos

preliminares e projetos básicos e executivos, ressalvado o disposto no § 4o do artigo anterior.

Assim sendo, o sistema a ser implantado também deve seguir o art. 30 como principal fiscalizador e comprovador da

capacidade das empresas que possam realizar a instalação/estruturação da proposta que até agora analisamos nos

tópicos supra-anteriores deste PIM, então leia-se tal artigo e seus incisos capitulares, dispostos abaixo:

I - registro ou inscrição na entidade profissional competente;

II - comprovação de aptidão para desempenho de atividade pertinente e compatível em características, quantidades e

prazos com o objeto da licitação, e indicação das instalações e do aparelhamento e do pessoal técnico adequados e

disponíveis para a realização do objeto da licitação, bem como da qualificação de cada um dos membros da equipe

técnica que se responsabilizará pelos trabalhos;

III - comprovação, fornecida pelo órgão licitante, de que recebeu os documentos, e, quando exigido, de que tomou

conhecimento de todas as informações e das condições locais para o cumprimento das obrigações objeto da

licitação;

IV - prova de atendimento de requisitos previstos em lei especial, quando for o caso.

07. TREINAMENTO DE FUNCIONÁRIOS PARA OPERAR O SISTEMA.

Conforme o que estabelece as normas ISSO/IEC 12207 o treinamento deve ser coordenado segundo os

seguintes paradigmas para formulação de sua ementa:

CONHECIMENTO DOS PROCESSOS ENVOLVIDOS, CONFORME ITEM ESTRUTURA DESTA NORMA

UNIVERSAL, AOS QUAIS SERÃO DESENVOLVIDAS AULAS PRÁTICAS E TEÓRICAS DE DIFERENCIAÇÃO DE:

• Processos fundamentais;

• Processo de apoio;

• Processos organizacionais;

• Processos de adaptação.

ANÁLISE DA ESTRUTURA TÉCNICA, ESTUDANDO-SE O FUNCIONAMENTO X VIABILIDADES DOS SISTEMAS,

ARQUITETURA E TOPOLOGIA DO SISTEMA, COMO DETECTAR PROBLEMAS E ADAPTAÇÕES NECESSÁRIAS:

• Funções e capacidades do sistema;

• Requisitos de negócio, organizacionais e de usuários;

• Requisitos de proteção, de segurança, de engenharia de fatores humanos (ergonomia), de interface, de

operações e de manutenção;

• Restrições de projeto e requisitos de qualificação.

CONHECIMENTO TOTAL DO SISTEMA E SEUS REQUISITOS PARA FORMATAÇÃO, SOLICITAÇÃO DE

INFORMAÇÕES EM RELATÓRIOS GESTORES, ETC:

• Especificações funcionais e de capacidade, incluindo desempenho, características físicas e condições do

ambiente sob o qual o item de software será executado;

• Interfaces externas ao item de software;

• Requisitos de qualificação;

• Especificações de proteção, incluindo aquelas relacionadas aos métodos de operação e manutenção, influências

do ambiente e danos pessoais;

• Especificações de segurança, incluindo aquelas relacionadas com o comprometimento de informações sigilosas;

• Especificações de engenharia de fatores humanos (ergonomia), incluindo aquelas relacionadas com operações

manuais, interações entre homem-máquina, restrições a pessoal e áreas que necessitam de maior atenção humana,

que são sensíveis a erros humanos e treinamento;

• Definição de dados e requisitos de bases de dados;

• Requisitos de instalação e aceitação do produto de software entregue nos locais de operação e manutenção;

• Documentação do usuário;

• Requisitos do usuário para execução e operação;

• Requisitos do usuário para manutenção.

BIBLIOGRAFIA:

CANAVAN, John E. Fundamentals of Network Security. Artech House, 2001.

COMER, Douglas. "Internetworking with TCP/IP". Volume I, II e III. Prentice-Hall, 1991.

DATE, C. J. Introdução a Sistema de Banco de Dados. 3ª Edição. Campus, Rio de Janeiro, 2000.

DAVIES, Donald Watts. Security for computer networks. Chichester : J. Wiley, 1989.

ELMASRI, R.; Navathe, S. Sistemas de Bancos de Dados - Fundamentos e Aplicações. 3 edição, LTC, 2002.

HEUSER, C. Projeto de Banco de Dados. Porto Alegre: Sagra Luzzato, 1998, Série de Livros Didáticos, número 4,

2004.

KORTH, H.F. Sistema de Banco de Dados. 3a ed. São Paulo: Makron Books, 1999.

TANEMBAUM, A. "Computer Networks". Prentice-Hall, 3ª Edição, 1996.

SINGH, Harry. Data Warehouse. São Paulo: Makron Books, 2001.

SOARES, Luis Fernando Gome. "Redes de Computadores - Das LAN’s, MAN’s e WAN’s às Redes ATM". Editora

Campus, 1995.

STALLINGS, William. Network Security Essentials: Applications and Standards. Prentice Hall, 1999.

ANEXOS

ANEXO A:

A ISO/IEC 12207 é a norma ISO/IEC que define processo de desenvolvimento de software.

A norma internacional ISO/IEC 12207 [1] tem como objetivo principal estabelecer uma estrutura comum para os

processos de ciclo de vida e de desenvolvimento de softwares visando ajudar as organizações a compreenderem

todos os componentes presentes na aquisição e fornecimento de software e, assim, conseguirem firmar contratos e

executarem projetos de forma mais eficaz.

Índice

[esconder]

• 1 Introdução

• 2 Estrutura

o 2.1 Processos fundamentais

o 2.2 Processos de apoio

o 2.3 Processos organizacionais

o 2.4 Processos de adaptação

• 3 Atividades do desenvolvimento

o 3.1 Implementação

o 3.2 Levantamento dos requisitos

o 3.3 Análise dos requisitos do sistema

o 3.4 Projeto da arquitetura do sistema

o 3.5 Análise dos requisitos do software

o 3.6 Projeto da arquitetura do software

o 3.7 Projeto detalhado do software

o 3.8 Codificação e testes do software

o 3.9 Integração do software

o 3.10 Teste de Qualificação do software

o 3.11 Integração do sistema

o 3.12 Teste de qualificação do sistema

o 3.13 Instalação do software

o 3.14 Apoio à aceitação do software

[editar] Introdução

Um processo é uma seqüência de passos realizados para um determinado propósito [IEEE 610.12, 1690]; o processo

de software envolve métodos, técnicas, ferramentas e pessoas. Um processo pode ser descrito de duas formas: por

propósito ou resultado e por atividade.

A descrição por propósito ou resultado é utilizada quando não há necessidade de detalhar o processo, apenas indicar

o objetivo e o resultado. Essa abordagem poderá ser utilizada na avaliação do processo em relação aos modelos de

maturidade de software como, por exemplo, o modelo CMMI e o modelo da ISO/IEC 15504.

A descrição por atividade é a abordagem mais conhecida e intuitiva. Nela são descritas as atividades com as inter-

relações e o algoritmo de execução de cada atividade. As atividades devem atingir o propósito do processo. Para

isso deve adotar as premissas:

• Que procedimentos e métodos serão usados para a execução das atividades;

• Que ferramentas e equipamentos suportarão a realização das atividades, de forma a simplificar e automatizar o

trabalho;

• Qual o perfil adequado de quem irá executar as atividades e qual o treinamento requerido nos procedimentos,

métodos, ferramentas para que se possam realizar as atividades de forma adequada;

• Quais as métricas de processo que poderão ser empregadas para que a execução do processo possa ter a

qualidade avaliada.

A norma ISO/IEC 12207 estabelece uma arquitetura de alto nível do ciclo de vida de software que é construída a

partir de um conjunto de processos e seus inter-relacionamentos. Os processos são descritos tanto em nível de

propósito/saídas como em termos de atividades.

A ISO/IEC 12207 não possui nenhuma ligação com métodos, ferramentas, treinamentos, métricas ou tecnologias

empregadas. Esta determinação é útil para permitir que a norma seja utilizada mundialmente e possa acompanhar a

evolução da engenharia de software nas diversas culturas organizacionais. Ela pode ser utilizada com qualquer

modelo de ciclo de vida, método ou técnica de engenharia de software e linguagem de programação. Sua

flexibilidade é uma característica importante, as atividades e tarefas do processo de ciclo de vida do software

especificam "o que fazer" e não "como fazer".

Os processos da ISO/IEC 12207 são modulares, ou seja, são fortemente coesos e fracamente acoplados. Isto

significa que todas as partes de um processo são fortemente relacionadas, mas a quantidade de interfaces entre os

processos é mínima.

As regras listadas a seguir são importantes para identificação, escopo e estruturação dos processos e devem ser

seguidas.

• Um processo deve ser modular, isto é, convém que um processo execute uma e somente uma função dentro do

ciclo de vida e é conveniente que as interfaces entre dois processos quaisquer sejam mínimas;

• Cada processo é invocado na arquitetura;

• Se um processo A é invocado por um processo B e somente por ele, então A pertence a B;

• Se uma função é invocada por mais de um processo, então esta função torna-se um processo;

• Deve ser possível verificar qualquer função dentro do modelo de ciclo de vida;

• Convém que cada processo tenha uma estrutura interna suficientemente definida para que possa ser executável.

[editar] Estrutura

Os processos na ISO/IEC 12207 são de responsabilidade de uma organização, mas não são exclusivos desta, ou

seja, uma organização pode executar um ou mais processos e um processo pode ser executado por uma ou mais

organizações. Neste caso, uma das organizações será a responsável pelo processo total, mesmo que tarefas

individuais sejam realizadas por pessoas diferentes. Os processos são agrupados, por uma questão de organização,

de acordo com a sua natureza, ou seja, o seu objetivo principal no ciclo de vida de software. Esse agrupamento

resultou em 4 diferentes classes de processos, que são:

• Processos fundamentais;

• Processo de apoio;

• Processos organizacionais;

• Processos de adaptação.

[editar] Processos fundamentais

Os processos fundamentais são necessários para que um software seja executado. Eles iniciam o ciclo de vida e

comandam outros processos. São eles:

• Aquisição: possui o propósito de obter o produto e/ou serviço que satisfaça suas necessidades;

• Fornecimento: possui o propósito de prover um produto e/ou serviço;

• Desenvolvimento: possui o propósito de transformar um conjunto de requisitos em um produto ou sistema de

software;

• Operação: possui o propósito de operar o produto no seu ambiente e prover suporte aos usuários;

• Manutenção: possui o propósito de modificar o produto de software e depois dar liberação para o uso.

[editar] Processos de apoio

Os processos de apoio auxiliam outro processo. Eles são usados para garantir a qualidade, mas não são

fundamentais. São eles:

• Documentação: possui o propósito de prover, manter um registro de informações de software;

• Gerência de configuração: possui o propósito de estabelecer e manter a integridade de todos os produtos de

trabalho (artefato) de um processo do projeto;

• Garantia da qualidade: possui o propósito de prover garantia de que os produtos e processos estão em

conformidade com o requisitos (padrões/normas) pré-definidos;

• Verificação: possui o propósito de confirmar que os produtos e/ou serviços refletem os requisitos especificados;

• Validação: possui o propósito de confirmar que os requisitos para o uso específico de um produto e/ou serviço são

atendidos;

• Revisão conjunta: possui o propósito de manter o entendimento (gerencial comum com os stakeholders);

• Auditoria: possui o propósito de determinar independentemente a conformidade dos produtos e processos contra

os requisitos definidos;

• Resolução de problema: possui o propósito de assegurar que todos os problemas levantados sejam analisados e

resolvidos;

• Usabilidade;

• Contrato.

[editar] Processos organizacionais

Os processos organizacionais auxiliam a organização e gerência geral dos processos e podem ser empregados fora

do domínio de projetos e contratos específicos, servindo para toda a organização. São eles:

• Gerência: possui o propósito de organizar, monitorar e controlar a iniciação e o desempenho dos processos;

• Infra-estrutura: possui o propósito de manter uma infra-estrutura estável e confiável;

• Melhoria;

• Recursos humanos: possui o propósito de prover e manter recursos humanos adequados mantendo as suas

capacitações consistentes com o negócio;

• Gestão de ativos: possui o propósito de gerenciar a vida dos ativos (reusáveis) desde a concepção até a

desativação;

• Gestão de programa de reuso: possui o propósito de planejar, estabelecer, controlar, monitorar os programas de

reuso;

• Engenharia de domínio: possui o propósito de desenvolver e manter modelos de domínio, arquiteturas e ativos

deste domínio.

[editar] Processos de adaptação

Os processos são adaptáveis a:

• Projeto;

• Organização;

• Cultura;

• Modelo de ciclo de vida, métodos e técnicas, e linguagens.

[editar] Atividades do desenvolvimento

Algumas atividades importantes para o desenvolvimento de software serão descritas a seguir. São elas:

• Implementação;

• Levantamento de requisitos;

• Análise dos requisitos do software;

• Projeto da arquitetura do software;

• Projeto detalhado do software;

• Codificação e testes do software;

• Integração do software;

• Teste de qualificação do software;

• Instalação do software;

• Testagem e aprovação do software

Elas foram descritas com base na norma ISO/IEC 12207.

[editar] Implementação

A implementação consiste na definição ou seleção de um modelo de ciclo de vida de software apropriado ao escopo,

magnitude e complexidade do projeto e na execução de documentação dos resultados, de acordo com o processo de

documentação; colocação dos resultados sob o processo de gerência de configuração; execução do controle de

alterações, de acordo com ele; documentação e resolução de não-conformidades e problemas encontrados nos

produtos de software e tarefas, de acordo com o processo de resolução de problema; execução dos processos de

apoio, conforme especificado no contrato; seleção, adaptação e utilização de padrões, métodos, ferramentas e

linguagens de programação de computador; desenvolvimento dos planos para conduzir as atividades do processo de

desenvolvimento.

[editar] Levantamento dos requisitos

O levantamento dos requisitos consiste em entender os requisitos e solicitações do sistema; obter e definir os

requisitos e solicitações do cliente através de sua solicitação direta ou através de outras entradas como revisão da

proposta de negócio, objetivos operacionais, ambiente de hardware e outros documentos.

É imprescindível entender as expectativas do cliente e assegurar que tanto o cliente quanto o fornecedor entendam

os requisitos da mesma forma. Isso pode ser feito através do processo de apoio "Revisão Conjunta" descrito na

norma ISO/IEC 12207. É necessário acordar os requisitos e obter um acordo entre as equipes que irão desenvolver o

trabalho em relação aos requisitos do cliente.

É importante gerenciar todas as mudanças feitas nos requisitos do cliente em relação à linha-básica definida

assegurando que o resultado de mudanças tecnológicas e de necessidades do cliente são identificados e os

impactos de introdução dessas mudanças são avaliados.

[editar] Análise dos requisitos do sistema

Após o levantamento, segue para a especificação dos requisitos do sistema. Esta especificação deve descrever:

• Funções e capacidades do sistema;

• Requisitos de negócio, organizacionais e de usuários;

• Requisitos de proteção, de segurança, de engenharia de fatores humanos (ergonomia), de interface, de

operações e de manutenção;

• Restrições de projeto e requisitos de qualificação.

Os requisitos precisam ser avaliados. Por isso, para formalizar e facilitar a avaliação, os critérios listados a seguir

devem ser seguidos:

• Rastreabilidade com os requisitos do cliente e necessidades de aquisição;

• Consistência com as necessidades de aquisição e com o levantamento dos requisitos;

• Testabilidade;

• Viabilidade do projeto da arquitetura do sistema;

• Viabilidade da operação e manutenção.

Após a avaliação é importante estabelecer mecanismos de comunicação para disseminar os requisitos do sistema e

suas atualizações para todas as partes interessadas.

[editar] Projeto da arquitetura do sistema

Com os requisitos elaborados e validados, pode-se estabelecer uma arquitetura de alto nível para o sistema. A

arquitetura deve identificar itens de hardware, software e operações manuais. Após a arquitetura ser estabelecida, é

necessário avaliá-la, considerando os critérios listados a seguir:

• Rastreabilidade para os requisitos do sistema;

• Consistência com os requisitos do sistema;

• Adequação dos métodos e padrões de projeto utilizados;

• Viabilidade dos itens de software atenderem seus requisitos alocados;

• Viabilidade da operação e da manutenção.

[editar] Análise dos requisitos do software

Para garantir a qualidade do produto entregue, as características de qualidade descritas a seguir devem ser

observadas nos requisitos de software:

• Especificações funcionais e de capacidade, incluindo desempenho, características físicas e condições do

ambiente sob o qual o item de software será executado;

• Interfaces externas ao item de software;

• Requisitos de qualificação;

• Especificações de proteção, incluindo aquelas relacionadas aos métodos de operação e manutenção, influências

do ambiente e danos pessoais;

• Especificações de segurança, incluindo aquelas relacionadas com o comprometimento de informações sigilosas;

• Especificações de engenharia de fatores humanos (ergonomia), incluindo aquelas relacionadas com operações

manuais, interações entre homem-máquina, restrições a pessoal e áreas que necessitam de maior atenção humana,

que são sensíveis a erros humanos e treinamento;

• Definição de dados e requisitos de bases de dados;

• Requisitos de instalação e aceitação do produto de software entregue nos locais de operação e manutenção;

• Documentação do usuário;

• Requisitos do usuário para execução e operação;

• Requisitos do usuário para manutenção.

Após a análise de requisitos de software é necessário fazer a avaliação desses requisitos considerando os critérios

listados a seguir:

• Rastreabilidade para os requisitos do sistema e projeto do sistema;

• Consistência externa com os requisitos do sistema;

• Consistência interna;

• Testabilidade;

• Viabilidade do projeto do software;


Pode-se conduzir uma ou mais revisões conjuntas e estabelecer as baselines.

[editar] Projeto da arquitetura do software

O projeto de arquitetura de software busca transformar os requisitos em uma arquitetura que descreve sua estrutura

de alto nível e identifica os componentes de software. As versões preliminares da documentação do usuário, dos

requisitos preliminares e de testes devem ser garantidas e documentadas. O cronograma para a Integração do

Software deve ser criado. A avaliação da arquitetura do item de software e os projetos de interface e base de dados,

considerando os critérios listados a seguir:

• Rastreabilidade para os requisitos do item de software;

• Consistência externa com os requisitos do item de software;

• Consistência interna entre os componentes de software;


• Viabilidade do projeto detalhado;



[editar] Projeto detalhado do software

Após o projeto de arquitetura, desenvolve-se um projeto detalhado de software para cada componente do software.

Os componentes de software devem ser refinados em níveis mais baixos, contendo unidades de software que

possam ser codificadas, compiladas e testadas. O projeto detalhado das interfaces deve permitir a codificação sem a

necessidade de informação adicional. Durante o detalhamento de software, se for necessário, deve ser feita a

atualização da documentação do usuário. É importante definir e documentar os requisitos de teste e o cronograma

para testar unidades de software.

Após detalhamento do projeto de software é necessário fazer a avaliação deste detalhamento, considerando os

critérios listados a seguir:

• Rastreabilidade para os requisitos do item de software;

• Consistência externa com o projeto da arquitetura;

• Consistência interna entre os componentes e unidades de software;


• Viabilidade dos testes;



[editar] Codificação e testes do software

Para, finalmente, executar a codificação e os testes é necessário desenvolver e documentar cada unidade de

software com base em procedimentos a serem definidos. Os testes devem garantir que os requisitos documentados

sejam atendidos. Os resultados dos testes devem ser documentados. Durante esta fase, a atualização e

documentação do usuário pode ser feita, se necessário. Após a codificação e testes é importante fazer a avaliação

do código do software e dos resultados dos testes, considerando os critérios listados a seguir:

• Rastreabilidade para os requisitos e projeto do item de software;

• Consistência externa com os requisitos e projeto do item de software;

• Consistência interna entre os requisitos da unidade;

• Cobertura de teste das unidades;

• Adequação dos métodos e padrões de codificação utilizados;

• Viabilidade da integração e testes do software;


Os resultados das avaliações devem ser documentados.

[editar] Integração do software

Para poder homologar o sistema é necessário desenvolver um plano de integração para integrar as unidades e

componentes de software. O plano deve incluir requisitos de teste, procedimentos, dados, responsabilidades e

cronograma. Deve-se testar essas agregações à medida que forem sendo integradas, de acordo com o plano de

integração. Durante esta fase, a atualização e documentação do usuário pode ser feita, se necessário.

Após a codificação e testes é importante fazer a avaliação do plano de integração, projeto, código, testes, resultados

dos testes e a documentação do usuário, considerando os critérios listados:

• Rastreabilidade para os requisitos do sistema;

• Consistência externa com os requisitos do sistema;

• Consistência interna;

• Cobertura de teste dos requisitos do item de software;

• Adequação dos métodos e padrões de teste utilizados;

• Conformidade com os resultados esperados;

• Viabilidade do teste de qualificação do software;



[editar] Teste de Qualificação do software

Deve-se desenvolver e documentar OS Requisitos de Qualificação de software e elaborar casos de teste (Entradas,

saídas e Critérios de teste) e Procedimentos de teste Parágrafo conduzir o Teste de Qualificação do Software de De

De acordo COM OS Requisitos de Qualificação nenhum item de software . Após a Codificação e testes e importante

Fazer Uma Avaliação do Projeto testes, Código, resultados dos testes EA Documentação do Usuario, considerando

Listados Critérios OS Seguir a:

• Cobertura de teste dos Requisitos do software de item;

• CONFORMIDADE COM OS resultados esperados;

testículos * Viabilidade da Integração e do Sistema, se conduzidos;

• Viabilidade da Operação e Manutenção.

É de suma Importância Estar Preparado n dar Apoio auditorias Como.

[editar] Integração do sistema

A integração do sistema faz-se a partir da integração dos itens de configuração de software ao sistema. Após a

integração deve-se conduzir ao teste de qualificação do sistema. Após a codificação e testes é importante fazer a

avaliação do sistema, considerando os critérios listados a seguir:

• Cobertura de teste dos requisitos do sistema;

• Adequação dos métodos e padrões de teste utilizados;


• Viabilidade do teste de qualificação do sistema;


[editar] Teste de qualificação do sistema

Para garantir a qualidade do produto entregue é importante conduzir o teste de qualificação do sistema e fazer a

avaliação do sistema, considerando os critérios listados a seguir:

• Cobertura de teste dos requisitos do sistema;



É importante estar preparado para dar apoio às auditorias.

[editar] Instalação do software

Na instalação do software deve-se executar um plano para instalar o produto de software no ambiente alvo, conforme

designado no contrato. Deve ser assegurado que o código do software e as bases de dados sejam iniciados,

executados e finalizados, conforme especificado no contrato. Os eventos e resultados da instalação devem ser

documentados.

[editar] Apoio à aceitação do software

No apoio à aceitação do software é preciso garantir o apoio à revisão de aceitação do adquirente e testes do produto

de software. A revisão de aceitação e testes deve considerar os resultados de Revisões Conjuntas, Auditorias, Teste

de Qualificação do Software e Teste de Qualificação do Sistema (se executado). Conclusão e entrega do produto de

software deve ser feita, conforme especificado no contrato e o desenvolvedor deve prover treinamento inicial e

contínuo e suporte ao adquirente, conforme especificado no contrato.

REFERÊNCIAS BIBLIOGRÁFICAS:

BRUMLEY, David; BONEH, Dan. Remote Timing Attacks are Practical. Disponível em:

<http://citeseer.ist.psu.edu/cache/papers/cs/27395/http:zSzzSzcrypto.stanford.eduzSz~dabozSzpaperszSzssl-

timing.pdf/boneh03remote.pdf> Acesso em 10. jun. 2010.

INFO WESTER. Assinatura Digital. Disponível em: <http://www.infowester.com/assincertdigital.php>. Acesso em 11.

jun. 2010.

QUARESMA, Paul. Códigos e Criptografia. Disponível em:

<http://www.mat.uc.pt/~pedro/lectivos/CodigosCriptografia/apontamentos223a229.pdf>.Acesso em 9. jun. 2010.

pim pronto gestao ti

Documents