Carregar apresentação
A apresentação está carregando. Por favor, espere
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.
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
Apresentações semelhantes
© 2024 SlidePlayer.com.br Inc.
All rights reserved.