INVESTIGAÇÃO E ANÁLISE DE SISTEMAS. VISÃO GERAL SOBRE O DESENVOLVIMENTO DE SISTEMAS

INVESTIGAÇÃO E ANÁLISE DE SISTEMAS

VISÃO GERAL SOBRE O DESENVOLVIMENTO DE

SISTEMAS

Participantes no desenvolvimento de sistemas

• Projetos

• Equipe


• Participantes podem exercer mais de um papel na equipe.

• A composição da equipe pode variar no decorrer do projeto.


• Metodologia Ágil de Desenvolvimento.

• Comunicação eficaz entre a equipe é essencial


• Usuários

• Usuários que não concordam com o sistema.


• O que as empresas fazem para melhorar a produtividade e motivação e reduzir o estresse do pessoal de SI?


Iniciando um desenvolvimento de sistemas

• Fatores que levam ao início do desenvolvimento de um sistema.

• Problemas com um sistema já existente.


• Mudança no ambiente externo ou desejo de tirar partido de novas oportunidades.


• Aumentar a competitividade.

• Desejo de fazer um uso mais efetivo da informação.


• Crescimento da informação.• Fusão ou aquisição.


• Novas leis ou regulamentos.

Planejamento de Sistemas de Informação

• Planejamento estratégico da organização.

• Alinhamento dos Objetivos Corporativos e de SI.

Iniciativas de desenvolvimento de sistemas

Planejamento de SI

Plano estratégico

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


Cada etapa deve ser concluída para que a próxima se inicie.


Vantagens:• Controle gerencial;• Criação considerável de documentação.


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.


Exemplos de ferramentas de desenvolvimento rápido de software:

• Genexus;• Ruby on Rails.


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.


Pode ser um simples cadastro de clientes em uma planilha, como um sistema que acaba se tornando complexo com o tempo.


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


Ferramentas usadas:• Ferramentas de criação e edição de páginas

web.• Criação de macros em ferramentas Office.


O surgimento de novas tecnologias de desenvolvimento

Investigação de Aplicabilidade de

Sistemas

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.


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


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


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)


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.


Fórmula:

FC: Fluxo de caixa

t: Período (tempo)

k: Custo de capita do projeto

n: Projeto

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.


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


Grafico de Gantt

Ferramentas de Gestão de Projeto Histograma

Tempo/Periodo

Qu

an

tida

de


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

Ferramentas CASE

VANTAGENSX

DESVANTAGENS

Desenvolvimento de sistemas orientados a objetos


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


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


• Fases do desenvolvimento: Análise de requisitos Análise Projeto Programação Testes Revisões / Modificações

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.


• Evolução das técnicas de 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.


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


• 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:1. Permitir que clientes pagassem pelas compras

de quiosque diretamente no caixa, em dinheiro, cartão ou cheque

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

Discussão

A. Pontos que afetam diretamente o desenvolvimento e implantação?

B. 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 malfeitoImportante 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 demaisEstreite o foco do projeto para dar contat

apenas das oportunidades de negócio mais importantes

Falta de apoio da diretoria executivaIdentifique 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 200931,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% 28,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/chaoswww.maturityresearch.com53%26%21%FracassoParcialSucessoAVALIAÇÃO DO SUCESSO DE PROJETOS DE T.I

http://hsm.updateordie.com/tecnologia/2009/06/projetos-de-ti-numeros-preocupantes/

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

http://hsm.updateordie.com/tecnologia/2009/06/projetos-de-ti-numeros-preocupantes/

Documents

INVESTIGAÇÃO E ANÁLISE DE SISTEMAS. VISÃO GERAL SOBRE O DESENVOLVIMENTO DE SISTEMAS