INVESTIGAÇÃO E ANÁLISE DE SISTEMAS

VISÃO GERAL SOBRE O DESENVOLVIMENTO DE SISTEMAS 2

Participantes no desenvolvimento de sistemas Projetos Equipe 3

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

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

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

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

Participantes no desenvolvimento de sistemas 8

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

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

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

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

Iniciando um desenvolvimento de sistemas Novas leis ou regulamentos. 13

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

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

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

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

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

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

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

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

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

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

Ciclos de vida do desenvolvimento de sistemas

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

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.

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

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

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

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

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.

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.

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

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.

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.

Prototipação

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

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

Desenvolvimento rápido Metodologias: Xp; SCRUM.

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

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.

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

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.

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

Investigação de Aplicabilidade de Sistemas

Porque a investigação?

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.

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?

Iniciando uma Investigação de Aplicabilidade de um Sistema

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.

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.

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.

Participantes de uma investigação de aplicabilidade de sistemas

Participantes de uma investigação

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.

Análise de Viabilidade

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

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

Viabilidade técnica

Viabilidade econômica

Viabilidade legal (jurídica)

Viabilidade operacional

Viabilidade Prazo

Valor Presente Líquido (VPL)

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.

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

Investigação Orientada a Objeto

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.

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).

Relatório de investigação de sistemas

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

Uso de ferramenta de gestão do projeto

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

Ferramentas de Gestão de Projeto Grafico de Gantt

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

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

Uso de Ferramentas de Engenharia de software

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.

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

VANTAGENS X DESVANTAGENS Ferramentas CASE VANTAGENS X DESVANTAGENS

Desenvolvimento de sistemas orientados a objetos

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

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.

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

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

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.

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

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.

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.

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.

ANÁLISE DE SISTEMAS

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

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

Participantes da Análise

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

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

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

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

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

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

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.

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

Estudo de caso: Revendedores da G.M.

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

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

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

Estudo de caso: Staples

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)

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

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

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

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

Estudo de caso: Wesco distribution

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

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

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

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

Fatores que afetam o sucesso do Desenvolvimento de Sistemas

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

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

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

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?

- 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;

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

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.

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

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.

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

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.

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

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.

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: http://hsm.updateordie.com/tecnologia/2009/06/projetos-de-ti-numeros-preocupantes/ www.standishgroup.com/chaos www.maturityresearch.com53%26%21%FracassoParcialSucessoAVALIAÇÃO DO SUCESSO DE PROJETOS DE T.I

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

Bibliografia http://hsm.updateordie.com/tecnologia/2009/06/projetos-de-ti-numeros-preocupantes/ Acessado em 25/04/2010 1)StandishGroup-www.standishgroup.com/chaos 2)Pesquisa Archibald & Prado 2006 –www.maturityresearch.com53%26%21%FracassoParcialSucessoAVALIAÇÃO 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%19941996199820002003Fonte: Chaos Report