Transcript Sem_ADMII_Cap_12

INVESTIGAÇÃO E
ANÁLISE DE SISTEMAS
VISÃO GERAL SOBRE O
DESENVOLVIMENTO DE
SISTEMAS
Participantes no desenvolvimento
de sistemas
• Projetos
• Equipe
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.
Participantes no desenvolvimento
de sistemas
• Metodologia Ágil de Desenvolvimento.
• Comunicação eficaz entre a equipe é essencial
Participantes no desenvolvimento
de sistemas
• Usuários
• Usuários que não concordam com o sistema.
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?
Participantes no desenvolvimento
de sistemas
Iniciando um desenvolvimento de
sistemas
• Fatores que levam ao início do
desenvolvimento de um sistema.
• Problemas com um sistema já existente.
Iniciando um desenvolvimento de
sistemas
• Mudança no ambiente externo ou desejo de
tirar partido de novas oportunidades.
Iniciando um desenvolvimento de
sistemas
• Aumentar a competitividade.
• Desejo de fazer um uso mais efetivo da
informação.
Iniciando um desenvolvimento de
sistemas
• Crescimento da informação.
• Fusão ou aquisição.
Iniciando um desenvolvimento de
sistemas
• Novas leis ou regulamentos.
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
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
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
Quantidade
 Histograma
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
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:
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 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
Desenvolva um programa rigoroso de
Os usuários não conseguem usar o sistema
treinamento dos usuários e reserve tempo
com eficiência
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
31,10%
52,70%
16,20%
1996
40,00%
33,00%
27,00%
1998
28,00%
46,00%
26,00%
2000
23,00%
49,00%
28,00%
2004
18%
53%
29%
2006
19%
46%
35%
2009
24,00%
44,00%
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%S
ucesso16%27%26%28%34%19941996199820002003Fonte: Chaos Report