INVESTIGAÇÃO E ANÁLISE DE SISTEMAS

Apresentação em tema: "INVESTIGAÇÃO E ANÁLISE DE SISTEMAS"— Transcrição da apresentação:

1 INVESTIGAÇÃO E ANÁLISE DE SISTEMAS

2 VISÃO GERAL SOBRE O DESENVOLVIMENTO DE SISTEMAS
2

3 Participantes no desenvolvimento de sistemas
Projetos Equipe 3

4 Participantes no desenvolvimento de sistemas
Participantes podem exercer mais de um papel na equipe. A composição da equipe pode variar no decorrer do projeto. 4

5 Participantes no desenvolvimento de sistemas
Metodologia Ágil de Desenvolvimento. Comunicação eficaz entre a equipe é essencial 5

6 Participantes no desenvolvimento de sistemas
Usuários Usuários que não concordam com o sistema. 6

7 Participantes no desenvolvimento de sistemas
O que as empresas fazem para melhorar a produtividade e motivação e reduzir o estresse do pessoal de SI? 7

8 Participantes no desenvolvimento de sistemas
8

9 Iniciando um desenvolvimento de sistemas
Fatores que levam ao início do desenvolvimento de um sistema. Problemas com um sistema já existente. 9

10 Iniciando um desenvolvimento de sistemas
Mudança no ambiente externo ou desejo de tirar partido de novas oportunidades. 10

11 Iniciando um desenvolvimento de sistemas
Aumentar a competitividade. Desejo de fazer um uso mais efetivo da informação. 11

12 Iniciando um desenvolvimento de sistemas
Crescimento da informação. Fusão ou aquisição. 12

13 Iniciando um desenvolvimento de sistemas
Novas leis ou regulamentos. 13

14 Planejamento de Sistemas de Informação
Planejamento estratégico da organização. Alinhamento dos Objetivos Corporativos e de SI. Plano estratégico Planejamento de SI Iniciativas de desenvolvimento de sistemas 14

15 Princípios de S.I. em Ação

16 Princípios de S.I. em Ação
Planejamento eficaz e cuidadoso; Esforço conjunto entre: Usuários Gerentes Desenvolvedores Pessoal de Apoio Grupos Internos e Externos

17 Vantagem competitiva Análise Criativa Análise Crítica
Investigação de novas abordagens a problemas existentes Análise Crítica Questionamento imparcial e cuidadoso sobre se os elementos do sistema estão relacionados de maneira mais efetiva e eficiente

18 Análise Crítica Ir além da mera automação de sistemas manuais
Questionar afirmações e pressupostos Identificando e resolvendo objetivos e orientações conflitantes

19 Metas para o desenvolvimento de Sistemas
Cumprir objetivos empresariais e não objetivos técnicos

20 Metas para o desenvolvimento de Sistemas
Sistemas de missão crítica Sistemas que desempenham um papel central nas atividades continuadas de uma empresa e no cumprimento de metas Fatores Críticos para o Sucesso (CSFs – critical success factors) Fatores essenciais para o sucesso de uma área funcional de uma empresa

21 Objetivos de Desempenho
Qualidade ou utilidade do resultado Precisão do resultado Qualidade ou utilidade do formato do resultado Velocidade com que o resultado é produzido

22 Objetivos de Custo Custos de desenvolvimento
Custos relacionados a singularidade da aplicação do sistema Investimentos permanentes em hardware e equipamentos relacionados Progressão de custos operacionais do sistema

23 Desenvolvimento de Sistemas
Comércio Eletrônico Tendências e Planejamento de Recursos Humanos

24 Ciclos de vida do desenvolvimento de sistemas

25 Definição É o processo de desenvolvimento de um sistema.

26 Modelo de ciclo de vida Define as principais atividades que fazem parte do desenvolvimento do sistema. Como: Levantamento de requisito, análise, documentação, implementação, teste, inplantação.

27 Tipos de Ciclo de vida Tradicional; Prototipação;
Desenvolvimento rápido de aplicações; Desenvolvimento pelo usuário final.

28 Modelo tradicional(cascata)
Investigação Análise Criação Implementação Manutenção e inspeção

29 Modelo tradicional(cascata)
Cada etapa deve ser concluída para que a próxima se inicie.

30 Modelo tradicional(cascata)
Vantagens: Controle gerencial; Criação considerável de documentação.

31 Modelo tradicional(cascata)
Desvantagens: Não tem integração com o usuário durante o processo de desenvolvimento. O excesso de documentos consome muito tempo e se torna difícil mantê-los atualizados.

32 Prototipação Envolve uma abordagem iterativa ao processo de desenvolvimento. Começa com um modelo do que será o sistema. A cada iteração o sistema é refinado e validado até que todo o sistema seja desenvolvido.

33 Prototipação Tipos de protótipos: Operacional; Não operacional.

34 Prototipação Não Operacional: É uma maquete, um modelo.
Sua utilização é comum para esboçar idéias, como o exemplo: O layout de um website, a interface gráfica de um software.

35 Prototipação Operacional (Espiral):
É um protótipo que de fato funciona. O modelo inicial tem as funcionalidades básicas do sistema. A cada iteração se obtem um feedback do usuário e pode ser descartado ou evoluir até o final do desenvolvimento.

36 Prototipação

37 Desenvolvimento rápido
RAD(Rapid application development). Inclui técnicas, ferramentas e metodologias para aumentar a produtividade no processo de desenvolvimento.

38 Desenvolvimento rápido
Exemplos de ferramentas de desenvolvimento rápido de software: Genexus; Ruby on Rails.

39 Desenvolvimento rápido
Metodologias: Xp; SCRUM.

40 Desenvolvimento pelo usuário final
Qualquer projeto de sistema no qual a iniciativa fica a cargo dos administradores da empresa ou usuários.

41 Desenvolvimento pelo usuário final
Pode ser um simples cadastro de clientes em uma planilha, como um sistema que acaba se tornando complexo com o tempo.

42 Desenvolvimento pelo usuário final
O usuário acredita que pode obter resultados mais rapidamente, pois conhecem as suas necessidades.

43 Desenvolvimento pelo usuário final
Ferramentas usadas: Ferramentas de criação e edição de páginas web. Criação de macros em ferramentas Office.

44 Desenvolvimento pelo usuário final
O surgimento de novas tecnologias de desenvolvimento

45 Investigação de Aplicabilidade de Sistemas

46 Porque a investigação?

47 Porque a investigação? O propósito da investigação é identificar potenciais problemas e oportunidades para o novo sistema e analisá-los à luz das metas da empresa.

48 Porque a investigação? Quais...
...os principais problemas que serão resolvidos pelo sistema novo ou aperfeiçoado? ...as oportunidades o sistema novo ou aperfeiçoado deve trazer? ...as melhorias trazidas ou requisitos impostos pelo sistema novo? ...os custos? ...os riscos associados?

49 Iniciando uma Investigação de Aplicabilidade de um Sistema

50 A investigação Ao iniciar uma investigação, a maioria das empresas, adotam um tipo formal para a sua solicitação, seleção e aprovação.

51 Formulário de Requisição
Documento que deve ser preenchido por aqueles que desejam que o departamento de SI inicie uma investigação de aplicabilidade.

52 Formulário de Requisição
Informações contidas em um Formulário de Requisição: Problemas resolvidos e oportunidades apresentadas pelo sistema; Objetivos da investigação de aplicabilidade; Visão geral do sistema proposto; Custos e benefícios esperados.

53 Participantes de uma investigação de aplicabilidade de sistemas

54 Participantes de uma investigação

55 Funções dos participantes
Conduzir a análise de viabilidade; Estabelecer metas de desenvolvimento; Selecionar a metodologia de desenvolvimento; Preparar o relatório de investigação.

56 Análise de Viabilidade

57 Análise de Viabilidade
Determina se um negócio (sistema) é viável ou não em diversos aspectos.

58 Análise de Viabilidade
Tipos de viabilidade: Viabilidade técnica Viabilidade econômica Viabilidade legal (ou jurídica) Viabilidade operacional Viabilidade Prazo

59 Viabilidade técnica

60 Viabilidade econômica

61 Viabilidade legal (jurídica)

62 Viabilidade operacional

63 Viabilidade Prazo

64 Valor Presente Líquido (VPL)

65 Valor Presente Líquido (VPL)
O valor líquido presente mostra o quanto a economia proporcionada por um projeto excede seu custo, levando em consideração o custo de capital e a passagem do tempo.

66 Valor Presente Líquido (VPL)
Fórmula: FC: Fluxo de caixa t: Período (tempo) k: Custo de capita do projeto n: Projeto

67 Investigação Orientada a Objeto

68 Investigação Orientada a Objeto
Durante a Investigação Orientada a Objetos há uma ênfase em encontrar e descrever os objetos – ou conceitos – no domínio do problema.

69 Investigação Orientada a Objeto
A Análise Orientada a objeto... ...pode ser empregada em qualquer fase da investigação; ...utiliza em seu desenvolvimento a linguagem UML (Unified Modeling Language).

70 Relatório de investigação de sistemas

71 Responsáveis pelo Relatório
Comitê Consultivo (ou Diretor): Administradores; Gerentes; Usuários do departamento de SI e de outras áreas relacionadas.

72 Uso de ferramenta de gestão do projeto

73 Ferramentas de Gestão de Projeto
Cronograma de projeto Marco de projeto Prazo máximo de projeto Trajetória crucial

74 Ferramentas de Gestão de Projeto
Grafico de Gantt

75 Ferramentas de Gestão de Projeto
Histograma Quantidade Tempo/Periodo

76 Ferramentas de Gestão de Projeto
PERT – avaliação e revisão de programas

77 Uso de Ferramentas de Engenharia de software

78 Ferramentas CASE CASE: Engenharia de Software Auxiliada por Computador
Ferramenta que oferece um conjunto de serviços, fortemente relacionados, para apoiar uma ou mais atividades do processo de desenvolvimento de software. As ferramentas CASE reforçam a aderência do processo ao SDLC.

79 Ferramentas CASE Divisão por funcionalidades da ferramenta:
Lower CASE Upper CASE I-CASE Norma ISO/IEC 14102

80 VANTAGENS X DESVANTAGENS
Ferramentas CASE VANTAGENS X DESVANTAGENS

81 Desenvolvimento de sistemas orientados a objetos

82 Desenvolvimento de sistemas orientados a objetos
Programação orientada a objetos (linguagens): Java C# C++ Delphi Ruby VISUAL BASIC Python

83 Desenvolvimento de sistemas orientados a objetos
OOSD: combina a lógica SDLC ao poder de modelagem e programação das linguagens orientadas a objetos. Objeto: representação virtual de algo do mundo real que se pretende utilizar no sistema.

84 Desenvolvimento de sistemas orientados a objetos
Fases do desenvolvimento: Análise de requisitos Análise Projeto Programação Testes Revisões / Modificações

85 Questões éticas e sociais: integração

86 Questões éticas e sociais: integração
O gerenciamento dos sistemas de informação tem se tornado difícil. Há um numero elevado de fornecedores de SI, e devido a falta de padronização cada empresa desenvolve sistemas em diferentes linguagens e plataformas. Surge o problema da integração, responsável por 40% do orçamento de SI das empresas.

87 Questões éticas e sociais: integração
Evolução das técnicas de integração

88 Questões éticas e sociais: integração
Serviços: porções -- ou componentes -- de software construídas de tal modo que possam ser facilmente vinculadas a outros componentes de software. Também podem ser reutilizados em várias áreas da empresa.

89 Questões éticas e sociais: integração
WEB SERVICES (WS): permite troca de informações entre sistemas em plataformas ou linguagens diferentes, que serão convertidas em XML. O objetivo é comunicação aplicação para aplicação através da Internet. As aplicações acessam os Web Services através de protocolos e formatos de dados padrões, como HTTP, XML e SOAP.

90 Questões éticas e sociais: integração
Arquitetura orientada a serviços (SOA): tradução das funcionalidades das aplicações em serviços padronizados inter-relacionado Foco na estruturação integrada das atividades de negócio. Os aplicativos baseados em SOA são independentes da plataforma e da linguagem e são compatíveis com os padrões mais aceitos pelas indústrias.

91 ANÁLISE DE SISTEMAS

92 Considerações Entender os objetivos da empresa e como o sistema ajudará a alcança-los Viabilidade das soluções Lista de prioridades de requistos como subproduto da Análise Pode ser direta em caso de pequenas empresas e complexa para empresas de grande porte

93 Procedimentos da Análise Formal
Montar grupo de participantes Coleta de dados e requisitos Análise dos dados e requistos Relatório sobre o sistema antigo, novos requisitos e prioridades do projeto

94 Participantes da Análise

95 Coleta de Dados Identificar a Fonte dados: Internas e Externas
Coletando Dados: Entrevista, Observação, Questionário, Amostragem Estatística, etc…

96 Análise de Dados Modelagem de Dados: baseado nos diagramas de ER(Entidade Relacionamento)

97 Análise de Dados Modelagem de Atividades: DFD(diagrama de fluxo de dados)

98 Análise de Dados Fluxogramas de Aplicação:relacionamentos entre aplicações/sistemas. Gráficos em Grade: relacionamentos entre os diversos aspetos de um projeto Ferramentas CASE: ajudam na geração de toda a documentação do sistema

99 Análise de Requisitos Determinar necessidades de Usuários/Especialistas/Organização em detalhes

100 Análise de Requisitos Técnicas: Perguntar Diretamente, Fatores críticos para o Sucesso(CSF – Critical Success Factors), Plano de SI, Layouts de Telas e Relatórios(Wireframe), Ferramentas

101 Análise Orientada a Objetos
Se baseia na OO, utilizando classes para descrever tipos distintos de objetos e organizadas em um diagrama de especialização/generalização.

102 Relatório da Análise Pontos fortes/fracos do Sistema Antigo
Requisitos para o novo sistema Requisitos organizacionais do novo sistema Como o novo sistema resolverá o problema

103 Estudo de caso: Revendedores da G.M.

104 Investigação Possui cerca de 7.500 vendedores
Despesas de 1bilhão em materiais e suprimentos Gastos repassados ao consumidor Queda nas vendas Incapacidade de redução de custos individualmente

105 Análise do sistema G.M. Propõe compras à granel
Parceria com fornecedores Desenvolvimento de TPS, permitindo compra diretamente de fornecedores Desenvolvimento de interface possibilitando maior conveniência na compra de produtos requeridos

106 Resultado: Custo de 360 dólares anuais pelo acesso
Economia de 15% na aquisição de materiais Aumento na lucratividade dos revendedores Ações da G.M. sobem

107 Estudo de caso: Staples

108 Investigação Grande loja de quiosques
Estação computacional incorpora tela sensível ao toque 42mil produtos disponíveis, além daqueles oferecidos na loja Insatisfação dos clientes por passar cartão 2vezes(quiosque e loja)

109 Análise do sistema Lançamento do projeto Ponto de acesso interno à loja Principais metas: Permitir que clientes pagassem pelas compras de quiosque diretamente no caixa, em dinheiro, cartão ou cheque Fornecer ferramenta ao cliente para especificar em detalhes o sistema computacional que desejasse comprar

110 Análise do sistema Meta 1
Alterações complexas (distinção compras via internet x quiosque dentro da loja) Clientes recebem tiquetes em código de barras Tiquete processado no caixa Caixa envia informações de pagto ao EDI

111 Análise do sistema Meta 2 Aquisição software externo – calico commerce
Criação de interface XML permitindo interação com sistema de processamento de pedidos da Staples.com Pedidos enviados aos fabricantes via EDI

112 Resultado: Registro de 4milhões de dólares em vendas
Redução de estoque Clientes compram 2,5vezes mais em 2 canais e 4,5vezes mais em 3 canais Staples recebeu premiação por reconhecimento à implementação de sistemas e-commerce bem sucedido

113 Estudo de caso: Wesco distribution

114 Investigação Empresa de distribuição, reparo e apoio operacional de produtos elétricos à grandes empresas nos E.U.A Especialista em intermediações Ajuda clientes na redução de custos na cadeia de suprimentos Armazena 140mil itens de centenas de fabricantes

115 Investigação Oferece 900mil itens operacionais que não são estocados(20% das vendas) Transação de produtos não estocados é lento e custoso

116 Análise do sistema Desenvolvimento de acesso online ao sistema de estoque do fabricante Criação interface XML

117 Resultado: Em 10 segundos vendedor obtem informações de estoque do fabricante Redução de custos de chamada telefônica Aumento nas vendas de produtos não estocados Economia de até 12milhões anuais se economizassem 3horas semanais de cada um dos 1000 vendedores Novo sistema custou 400mil dólares

118 Fatores que afetam o sucesso do Desenvolvimento de Sistemas

119 SUCESSO Produto entregue = necessidade do usuário Prazos cumpridos
Orçamento viável – custo aceitável Aceitação dos usuários Apoio e interação constante dos envolvidos (desenvolvedores, analistas, gerentes e usuários) Habilidade Gerencial/ Reconhecimento do Ambiente Qualidade e Padrão

120 Nível de Alteração Profundidade das alterações:
Pequenas melhorias X reconstruções de grande calibre

121 Melhorias Contínuas X Reengenharia
Pequenas mudanças Não necessário retreinamentos Mudanças drásticas/ fundamentais Corresponde à uma iniciativa de desenvolvimento Alto grau de risco Grandes benefícios

122 Pontos que afetam diretamente o desenvolvimento e implantação?
Discussão Pontos que afetam diretamente o desenvolvimento e implantação? Quais são os pontos de maior impacto num desenvolvimento de sistema até sua implantação?

123 - medo (perda de emprego/ cargo/ influência/ poder);
Crenças/ pré-conceitos: novo sistema criará mais trabalho/ problemas que soluções; Resistências (aceitar/ aprender/ entender); Contato com o “pessoal da informática”; Expectativas negativas: o novo sistema vai alterar a estrutura organizacional;

124 Melhor solução?????? PREVENIR E SABER LIDAR

125 QUALIDADE E PADRÕES Qualidade de planejamento
Quanto > projeto > possibilidade de planejamento malfeito Importante um planejamento fundamentado, documentado, padronizado, organizado e com prazos reais ISO 9001 – padrões desenvolvidos para aumentar qualidade.

126 TEMPO X CUSTO X QUALIDADE
Produção fora do custo planejado Entregas fora do prazo Sem funcionabilidade esperada COMO REMEDIAR

127 Resolver o problema errado
Estabelecer uma ligação clara entre o projeto e as metas Má definição e análise do problema Seguir uma abordagem de desenvolvimento de sistemas padronizados Má comunicação Comunicar-se. Comunicar-se. Comunicar-se o projeto é ambicioso demais Estreite o foco do projeto para dar contat apenas das oportunidades de negócio mais importantes Falta de apoio da diretoria executiva Identifique o diretor senior que mais tem a ganhar com o sucesso do projeto e o recrute para liderar o projeto Falta de envolvimento da direção e do usuário Identifique e recrute os indivíduos-chavve para serem participantes ativos do projeto Projeto de sistema inadequado ou impróprio siga uma abordagem de desenvolvimento de sistema padronizada Os usuários não conseguem usar o sistema com eficiência Desenvolva um programa rigoroso de treinamento dos usuários e reserve tempo suficiente no cronograma para executá-lo.

128 Modelo de Maturidade de Capacidade
CMM – Capability Maturity Model Maneira de medir na empresa a capacidade/ experiência/ maturidade que têm em desenvolvimentos de sistemas Modelo – resultado de uma pesquisa 5 níveis: Inicial ao Aperfeiçoado

129 1. Inicial: desenvolvimento aleatório, caótico
Processo disciplinado 2. Reproduzível: controles de custos, cronogramas, funcionalidades, disciplina nos desenvolvimentos Processo padronizado, consistente 3. Definido: procedimentos documentados/ bem definidos, padronização inclusive nos códigos Processo previsível 4. Gerenciado: medições detalhadas para melhor gerenciamento Processo contínuo de melhoria 5. Otimizado: melhorias contínuas fortalecedoras, processos inovadores, otimização.

130 Crise do Software (“Software Crisis”)
CHAOS (Standish 1994) Medida de sucesso/ fracasso dos projetos de TI; Análise realizada em 2009 – 1 em 4 projetos estão condenados Chaos Report do Standish Groups

131 Definições Inspiradas no Modelo do StandishGroup
Projeto bem sucedido (ou sucesso completo ou apenas sucesso): o projeto terminou praticamente no prazo orçamento e escopo previstos. Pequenos desvios nestes aspectos foram pouco significantes. O usuário ficou totalmente satisfeito, pois o produto que lhe foi entregue estásendo utilizado e realmente agregou valor ao seu trabalho. (Comentário: observe que se aceitam pequenos desvios) Projeto parcialmente bem sucedido (sucesso parcial ou comprometido): o projeto foi encerrado e o software estásendo utilizado. No entanto, aconteceram fatos comprometedores (atraso significativo e/ou estouro de orçamento e/ou desvios no escopo) ou a satisfação do usuário éparcial, pois o produto não foi entregue no prazo esperado e/ou não apresenta todas as funcionalidades esperadas enecessárias e/ou não agrega o valor esperado ao seu trabalho. Projeto fracassado: o projeto foi paralisado ou o produto entregue não estásendo utilizado por não atender às expectativas dos usuários ou o atraso foi tal que implicou em perdas no negócio. O usuário/cliente ficou profundamente insatisfeito.

132

133 1994 1996 1998 2000 2004 2006 2009 31,10% 40,00% 28,00% 23,00% 18% 19% 24,00% 52,70% 33,00% 46,00% 49,00% 53% 46% 44,00% 16,20% 27,00% 26,00% 29% 35% 32,00% Primeira linha - > % Projetos cancelados; Segunda linha - > % Projetos entregues com variação em termos de prazo, custo ou qualidade; Terceira linha - > %Projetos entregues dentro de prazo, custo e qualidade esperados; Fontes de pesquisa: DO SUCESSO DE PROJETOS DE T.I

134 PRINCIPAIS CAUSAS DE FRACASSO (Brasil)
Freqüentes mudanças de escopo: 73% Prazos inexeqüíveis: 51% Estudo de viabilidade incorreto ou incompleto: 27%

135 Bibliografia Acessado em 25/04/2010 1)StandishGroup- 2)Pesquisa Archibald & Prado 2006 – DO SUCESSO DE PROJETOS DE T.I.(Chaos Report)0%20%40%60%80%100%Fracasso31%40%28%23%25%Parcial53%33%46%49%41%Sucesso16%27%26%28%34% Fonte: Chaos Report

136