Análise e Projeto de Sistemas Análise e Projeto de Sistemas Aula 2 Professor: Italo Rodrigues Castro.

Apresentação em tema: "Análise e Projeto de Sistemas Análise e Projeto de Sistemas Aula 2 Professor: Italo Rodrigues Castro."— Transcrição da apresentação:

1 Análise e Projeto de Sistemas Análise e Projeto de Sistemas Aula 2 Professor: Italo Rodrigues Castro

2 O que é um Sistema? o Um conjunto ou arranjo de elementos inter- relacionados de modo a formar um todo, visando o cumprimento de um objetivo.

3 Problemas no projeto de um Sistema  Pressão dos usuários para que o sistema resolva o problema deles.  Insatisfação dos usuários com os sistemas informatizados que são disponibilizados para eles.

4 Problemas no projeto de um Sistema  Visão extremamente técnica, sem levar em conta fatores humanos no processo de informatização.  Ex.:  (Usuários) “O sistema vai fazer tudo automático para mim”.  (Analistas) “Sei tudo de Java, Visual Studio, modelagem E-R, etc.”.

5 Problemas no projeto de um Sistema o Então qual é a solução?  Seguir processos de desenvolvimento de sistemas, que proporcionem:  Produtividade da equipe de desenvolvimento  Confiabilidade no sistema  Manutenibilidade e portabilidade do código-fonte  Segurança dos dados  Bom desempenho

6 Problemas no projeto de um Sistema o Então qual é a solução?  Produzir especificações (documentos), de qualidade, dos Sistemas de Informação que serão criados.  A atuação de um profissional que, além do conhecimento da programação e da operação dos computadores, tenha um perfil também voltado para a especificação dos requisitos do sistema e percepção do negócio da empresa.

7 Problemas no projeto de um Sistema o Quem faz este trabalho?

8 Habilidades do Analista de Sistemas 1. Comunicação 2. Capacidade de Análise 3. Conhecimento da área do usuário 4. Capacidade de negociação 5. Conhecimento técnico

9 Habilidades do Analista de Sistemas 1. Comunicação: 1. Comunicação: É a capacidade de ouvir, redigir e expor idéias com facilidade, clareza e precisão. Também se refere à capacidade de aprender, e a expressar o conteúdo do aprendizado com facilidade.

10 Habilidades do Analista de Sistemas 2. Capacidade de Análise. 2. Capacidade de Análise. É a aptidão para realizar operações mentais com abstrações sobre a realidade em estudo. Também se refere à capacidade de estabelecer uma visão sistêmica e crítica do contexto em análise.

11 Habilidades do Analista de Sistemas 3. Conhecimento da área usuária. 3. Conhecimento da área usuária. É a habilidade de conhecimento por meio da vivência com absorver as operações da empresa (que pode ser obtido através de entrevistas), ou por meio de leitura de informações técnicas, documentos da empresa, etc.

12 Habilidades do Analista de Sistemas 4. Capacidade de negociação 4. Capacidade de negociação. É a habilidade de obter o resultado desejado, administrando situações de conflitos de interesses pessoais, fazendo convergir interesses opostos

13 Habilidades do Analista de Sistemas 5. Conhecimento técnico. 5. Conhecimento técnico. É a capacidade de especificar sistemas, principalmente em suas fases de nível de abstração mais alto, usando alguma linguagem ou ferramenta de modelagem.

14 Principais Atores da Análise de Sistemas

15 Habilidades do Analista de Sistemas  O que é melhor de se fazer na prática?  Vários profissionais, cada um com uma função especializada? ou o analista de sistemas deve fazer tudo?

16 Orientações para se fazer uma boa especificação de um sistema  Desenvolvimento de sistemas = solução de problemas.  Disposição para APRENDER da área cliente.

17 Orientações para se fazer uma boa especificação de um sistema  Qual é o grau de dificuldade de se APRENDER alguma coisa?  É um processo muito complexo!  Seria uma explicação para tantos erros em estimativas de prazos para desenvolvimento de software?  Talvez sim, pois...

18 Orientações para se fazer uma boa especificação de um sistema  Considerações sobre o aprendizado ... Como é possível saber em quanto tempo e com quanta eficiência a equipe que realiza a análise do sistema aprenderá as regras e os processos de negócio da área de aplicação?

19 Orientações para se fazer uma boa especificação de um sistema  Tanto durante o aprendizado, como após este, tem a questão da comunicação...  É fácil comunicar com o cliente/ usuário? Não!  Problemas semânticos, fatores psicológicos, etc.

20 Orientações para se fazer uma boa especificação de um sistema  Como superar problemas de comunicação?  Usar linguagens de especificação de sistemas, que podem ser entendidas tanto por analistas quanto por usuários.

21 Orientações para se fazer uma boa especificação de um sistema  Isso nos leva a concluir que o fator determinante para a boa qualidade da análise do sistema é a boa interação (comunicação) entre os usuários e os analistas de sistemas.

22 Orientações para se fazer uma boa especificação de um sistema  Qual é o principal produto da Análise?  Modelos do sistema, que por sua vez darão origem ao sistema final

23 Orientações para se fazer uma boa especificação de um sistema  A planta de uma casa é um eficiente meio de comunicação:  Entre os técnicos envolvidos no projeto e os usuários da casa.

24 Orientações para se fazer uma boa especificação de um sistema Planta de uma casa

25 Orientações para se fazer uma boa especificação de um sistema  A planta possibilita a resolução de algumas questões de natureza técnica antes do início da construção,resultando em economia de dinheiro e tempo.

26 Orientações para se fazer uma boa especificação de um sistema  Assim como no exemplo da casa, antes de se construir um sistema de informação, é proveitoso fazer sua modelagem primeiro.

27 Orientações para se fazer uma boa especificação de um sistema  A modelagem do sistema deve ser capaz de expressar com a máxima fidelidade possível o conhecimento que se tem do ambiente onde o sistema será implantado, para que assim todos os seus requisitos sejam satisfeitos.

28 Principais utilidades de modelar um sistema  Estabelecer uma visão comum entre usuários e analistas.  Apontar possibilidades futuras para o sistema.

29 Principais utilidades de modelar um sistema  Representar, avaliar e refinar conceitos de projeto.  Dividir o desenvolvimento em fases, com produtos bem definidos, e dependência mínima entre fases.

30 Principais utilidades de modelar um sistema  Tratar o problema por diferentes níveis de abstração, do mais abstrato para o mais detalhado.

31 Principais utilidades de modelar um sistema  Permitir avaliar a complexidade de um problema  Facilitar a geração de testes..

32 Principais utilidades de modelar um sistema  Será que começar o desenvolvimento de um sistema pela modelagem é sempre a melhor opção?  Não é mais fácil e rápido já começar codificando?.

33 Argumentos para não se iniciar pela modelagem  Fator tempo. “O cliente pressiona para entregar o sistema rapidamente. Modelar atrasa”.  “Um grande volume de documentos é gerado; são difíceis de serem mantidos atualizados”..

34 Argumentos a favor de se iniciar pela modelagem  Modelagem ajuda a resolver um sério problema: “o software ficar só na cabeça do desenvolvedor”. Se ele sai da equipe, o que acontece?....

35 Argumentos a favor de se iniciar pela modelagem  Atraso acontece porque ocorrem erros na estimativa do prazo para o desenvolvimento.

36 Argumentos a favor de se iniciar pela modelagem  Modelar primeiro pode ajudar a prevenir situações em que o sistema poderá sofrer desnecessária manutenção, logo após sua implantação.

37 Argumentos a favor de se iniciar pela modelagem  Conclusão: não modelar pode significar obter uma solução a curto prazo que gerará maiores problemas a longo prazo.

38 Obrigado! ?