Auditoria de Aquisição Desenvolvimento Manutenção e Documentação. Prof. Dr. Joshua Onome Imoniana

Transcrição

1 Auditoria de Aquisição Desenvolvimento Manutenção e Documentação Prof. Dr. Joshua Onome Imoniana

2 Definição de controles Aquisição, Desenvolvimento, Manutenção e Docuentação de Sistemas As funções de aquisição, desenvolvimento, manutenção e documentação de sistemas são atribuídas aos indivíduos que têm competências para conceber e implantar sistemas. Naturalmente efetuado junto com os usuários com o propósito de atender aos objetivos dos negócios.

3 SDLC Ênfase nos procedimentos de Systems Development Life Cycle

4 Tarefas dos controles ADMD Planejamento de sistemas de informações; aquisição de sistemas; especificação, programação, teste e implementação de sistemas novos; modificação dos programas das aplicações existentes; manutenção preventiva dos sistemas aplicativos; Documentação; Controle sobre versões de programas em produção.

5 Familiarização com sistema novo Quando os usuários não estão familiarizados com operação de um sistema novo ou com os relatórios, encontrarão dúvidas freqüentes de processamento ou dificuldades para sugestão de modificações nos sistemas que podem ter deficiências significativas no seu controle.

6 Desenvolvimento e Responsabilidade da culpula O desenvolvimento efetivo de um sistema requer participação da alta cúpula da administração. Envolvimento por um comitê de direção composto de representantes de alto nível de usuários de sistemas. O comitê aprova ou recomenda alterações nos projetos e revisa o progresso deles.

7 Estudo de viabilidade economica, operacional e técnica do sistema Deve-se promover o estudo da viabilidade econômica; Deve-se promover o estudo operacional ; Deve-se promover o estudo técnica de aplicações novas necessariamente requerendo avaliações e também propondo ajustes nos sistemas.

8 Aquisição contempla Confiabilidade, compromisso com o serviço, prover treinamento, suporte e documentação do produto Especificação; Custo do Produto Prazos e data de entregas; Compromissos com documentação, upgrades, novo releases, etc; Compromissos para data de migração; Possibiidades de escrow agreement; Intalação e customização; Criterio de aceitação (UAT) Contrato de manutenção; Contratos de usos de cópias; Planos de pagamentos

9 Desenvolvimento Desenho representa o ponto ótimo para modelagem do software e acontece os cut-off com fase anterior

10 Codificação Desenvolvimento Debugging e teste de programas Uso de ferramentas de conversão Data de sistemas antigos (execute the load of data into the legacy structures) ; Criando procedimentos de usuários; Treinando usuários replicadores; Assegurar documentação

11 Planejamento do Projeto CPM PERT Outros

12 Manutenção de sistema Riscos na modificação de sistemas preocupa varios usuários e auditor também Quando novos sistemas ou modificações significativas nos sistemas existentes são implantados, o risco de erros relacionados a transações processadas pode crescer. Sistema sem histórico de precisão no seu processamento para suportar um ceticismo sobre existência de risco, o usuário preocupa-se com relação a onde efetivamente estão ocorrendo as modificações promovidas.

13 Riscos na modificação de sistema Quando novos sistemas ou modificações significativas nos sistemas existentes são implantados, o risco de erros relacionados a transações processadas pode crescer. Sistema sem histórico de precisão no seu processamento para suportar um ceticismo sobre existência de risco, o usuário preocupa-se com relação a onde efetivamente estão ocorrendo as modificações promovidas.

14 Solicitação de Mudanças Pedido por escrito solicitando uma mudança no programa de aplicação deveria ser feito por um usuário master e deveria ser autorizado por gerente imediato ou comitê de informática..

15 Regras para mudanças no ambiente de produção a) quando da modificação do programa em ambiente de produção, o mesmo deve ser redesenhado; b) Mudanças no programa devem ser testadas pelo usuário e o auditor interno; c) Quando existe atentar para um controle independente; recomenda-se que um funcionário que não era envolvido na projeção das mudanças faça análise dos resultados; d) Aprovação da mudança deve ser documentada e o resultado de testes deveria ser aprovado por um gerente de sistemas. e) Mudanças de programa sem autorização não podem ser implementadas em ambiente de produção. f) Modificações indevidas devem ser descobertas por meio de comparação de versões e auditor usa softwares para executar este procedimento.

16 Controles de Documentação de Sistemas Documentação deveria ser guardada em uma biblioteca que tenha um controle de acesso; Documentação de sistema inclui descrições narrativas, flowcharts, a definição de ferramentas usadas para seu desenvolvimento, contribuição e formas de produção; Listings de programa de fonte, dados de testes, contribuição e produção, arquivos detalhados e planos de registro, pedidos de mudança, instruções de operador e controles; Documentação operacional (manual de operação do computador) provê informação sobre organização, arquivos necessários e dispositivos, procedimento de contribuição, mensagens do console e ações de operadores Documentação processual inclui o plano-mestre do sistema e operações a serem executados, padrões de documentação, procedimentos para controlar arquivos e padrões para análise de sistemas, programação, operações, segurança e definição de dados; documentação de usuário descreve o sistema e procedimentos para entrada de dados, conferência e correção de erros, formatos e usos de relatórios. ;

17 Objetivos de auditoria Os principais objetivos de auditoria dos controles aquisição desenvolvimento, manutenção e documentação são: assegurar que sistemas adquiridos são realmente necessários, Desenvolvidos atentando para todos os critérios, Modificados conforme tendências das operações dos negócios; Documentados para orientar os usuários hoje e futuros.

18 Exemplo: Check-list de auditoria de controles ADMD Há procedimento de formalização da real necessidade para um novo sistema? As especificações são feitas de forma diligente, confrontando os conhecimentos dos usuários com os de analista de sistema, visando dar suporte aos projetos? Os desenvolvimentos de testes e instalação na produção são feitos sem traumas para os usuários? Há informações apresentadas para que os usuários possam decidir entre aquisição e desenvolvimento interno? O desenvolvimento segue os padrões e utiliza todas as ferramentas para alinhá-lo com os sistemas já existentes? As questões básicas operacionais/funcionalidade, tecnologia, pósvendas, segurança e de análise de custo e benefícios, entre outras, são esclarecidas quando da decisão de compras externas? Os usuários são treinados para utilizar os sistemas com todos os potenciais que possuem? As manutenções são feitas sem interrupção das operações normais da empresa? As documentações são consistentes e disponíveis para orientar os usuários?

19 Questão Prática Como auditor de sistemas voce está avaliando se um projeto de sistema novo atende os objetivos dos negócios. Qual dos seguintes testes retrata asseguração de que objetivos foram alcançados? A. User Acceptance Test (UAT) B. Teste de Performance C. Sociabilidade D. Penetration Test E. Teste de Escalabilidade