Projeto de Sistemas - Parte001

1.533 visualizações

Publicada em

Parte 1 de Práticas Simuladas e Projeto de Sistemas

0 comentários
1 gostou
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
1.533
No SlideShare
0
A partir de incorporações
0
Número de incorporações
19
Ações
Compartilhamentos
0
Downloads
65
Comentários
0
Gostaram
1
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Projeto de Sistemas - Parte001

  1. 1. Aula 001 Projeto de Sistemas PRONATEC Programa Nacional de Acesso ao Ensino Técnico e Emprego
  2. 2. PRONATEC Programa Nacional de Acesso ao Ensino Técnico e Emprego
  3. 3. 1. Engenharia de Software • Ciência de aplicar os conhecimentos técnicos e científicos na criação, aperfeiçoamento e implementação de projetos de softwares e sistemas de computador. • No inicio da década de 80, na primeira página da revista Business Week dizia: "Software: A Nova Força Propulsora“ • Em meados da década de 80, a capa da Fortune: "Uma Crescente Defasagem de Software“ • Começo da década de 90 a Newsweek perguntava: "Podemos Confiar em Nosso Software?" • A Engenharia de Software foi criada para preencher a lacuna criada pelo advento do invento e disseminação do uso do computador e o que o alimenta: Software
  4. 4. 2. Problemas Associados ao Software • Estimativas de prazos e de custos que são freqüentemente imprecisos • Produtividade dos profissionais da área que não tem acompanhado a demanda por novos serviços; • A qualidade do software desenvolvido que é insuficiente 3. A importância do Software • Antes da década de 80 o principal desafio era criar um hardware que reduzisse o custo de processamento e armazenagem de dados • Hoje o desafio é melhorar a qualidade e reduzir o custo de soluções baseadas em computador - soluções que são implementadas com software
  5. 5. 5. Categoria dos Softwares • Software Básico: programas para dar apoio a outros programas com forte união ao hardware. • Software de Tempo Real: usados para monitorar, analisar e controlar eventos do mundo real. • Software Comercial: maior área de aplicação de softwares. Controlam operações comerciais para facilitar o gerenciamento do negócio na empresa • Software Cientifico e de Engenharia: algoritmos de processamento numérico pesados para áreas de pesquisa e da ciência • Software Embutido: executam atividades específicas e inseridos em produtos inteligentes • Software de Computador Pessoal: criados para uso pessoal tais como planilhas, editores de textos, jogos, etc.. • Software de Inteligência Artificial (IA): aloritmos sofisticados que imitam o pensamento humano de tomada de decisão
  6. 6. 7. Paradigmas: Engenharia de Software • Paradigmas são os modelos de processos que possibilitam: • Ao gerente - controlar o processo de desenvolvimento de softwares • Ao desenvolvedor - obter a base para produzir, de maneira eficiente, software que satisfaça os requisitos preestabelecidos 8. Processos de Software • conjunto de atividades e resultados associados que levam à produção de um novo “software” • Atividades: Especificação de Software, Projeto e Implementação, Validação e Teste, Evolução e Manutenção. • Resultados: Retroalimentação (feedback) como forma de avaliar o quão eficaz e eficiente o software final está para refazer atividades e adequá-lo aos objetivos propostos
  7. 7. 9. Especificação do Software • Forma de conhecer o software e qual seus objetivos primários e objetivos parciais. • Geralmente feito por meio de Técnicas de Entrevista e Coleta de Dados com o Usuário por intermédio de um “Analista de Sistemas” • Precisamos coletar informações e compreender sobre o comportamento do sistema atual e seus requisitos para elaborarmos um projeto consistente, preciso e com parâmetros para calcularmos o seu cronograma e custo • Entrevista entre Analistas e os usuários do sistema fazendo anotações sobre o funcionamento do software • Na entrevista podem ser usadas ferramentas: gravadores, câmeras, planilhas, processadores de texto, para estruturar o resultado da entrevista e facilitar seu entendimento
  8. 8. 10. Problemas com as Entrevistas • Entrevistar a pessoa errada na hora errada: entrevistar usuários que não tem conhecimento muito detalhado sobre o sistema, ou que são específicos demais. Também marcar entrevistas para horários onde o usuário não estará totalmente focado no assunto. • Fazer perguntas erradas e/ou obter respostas erradas: sendo analista e usuário de “mundos” diferentes pode acontecer de o analista perguntar sem que o usuário entenda ou o usuário responder sem que o analista o compreenda. O maior perigo é isso acontecer sem que nenhum dos dois perceba. O melhor é marcar mais de uma reunião sobre o mesmo tema para confirmar • Criar ressentimentos recíprocos: o usuário poderá dificultar o trabalho por ficar receoso de que o novo sistema irá lhe dificultar ou mesmo tirar seu trabalho. O perigo é ele prestar informações inverídicas do funcionamento do sistema.
  9. 9. 11. Diretrizes para uma boa Entrevista • Desenvolva um plano geral: Procure já elaborar linhas gerais de perguntas de acordo com as funções exercidas pelos usuários. No momento da entrevista poderão surgir adequações mas as linhas gerais permaneceram. • Obtenha autorização superior: o analista deverá usar o organograma (formal ou informal) para saber quem são os reais usuários que sabem dizer sobre o funcionamento do sistema e marcar com seus chefes as entrevistas. • Procure não fazer perguntas redundantes: o usuário poderá dar respostas de uma vez a mais de uma pergunta, então poupe o tempo dele e já salte as perguntas respondidas • Utilize ferramentas automatizadas mas não abuse: o usuário poderá ficar entediado se usar muitos recursos automáticos e a entrevista pode não render o esperado • Procure o interesse do usuário: descubra quais funções no sistema o usuário mais domina e tem mais afinidade e parta desse princípio com sua entrevista • Use um estilo adequado de entrevistar: respeite o usuário, ele é quem é o perito no sistema, você é quem deve aprender com ele. Não o intimide, nem o coaja, a não ser em casos muito extraordinários.
  10. 10. 12. Formas de Resistência à Entrevista • Você está tomando tempo demais de mim: o usuário pode reclamar de estar perdendo tempo com sua entrevista, procure lembrá-lo que posteriormente com o sistema pronto ele terá uma ferramenta que aumentará a sua produtividade • Você está ameaçando meu emprego: não minta nem prometa nada ao usuário, você não é o patrão dele, esse receio pode ou não ter fundamento. Se tornar-se impedimento à entrevista comunique aos superiores dele ou ao responsável pela criação do sistema. • Você não conhece nossa empresa como quer dizer como deve ser o novo sistema? Responda: você tem razão, por isso estou lhe pedindo ajuda com esta entrevista para poder entender melhor e fazer o sistema o mais correto possível • Você está mudando as coisas aqui: tente convencer o usuário de que o sistema irá beneficiá-lo e não o contrário. • Não quero esse sistema: essa é uma variante da ameaça de emprego, novamente não minta nem prometa nada. Se persistir a dificuldade na entrevista é melhor direcionar aos superiores e aos responsáveis • Por que você está desperdiçando nosso tempo com isso? O usuário tem a noção errada de que se ele sabe você também deveria saber. Tente explicar a ele que a sua área de atuação não é a mesma dele.
  11. 11. 13. Outras Formas de coleta de dados • Questionários: com perguntas diretas, coerentes e não redundantes. Distribua os questionários aos usuários do sistema • Observando outros softwares: pode ser que outros já tenham desenvolvido softwares para o que você está trabalhando ou partes dele. Peça cópias de demonstrações e manuais caso existam para compreender o sistema, marque entrevistas com os usuários desses sistemas usando o software juntamente com eles para melhor compreensão • Visitas a outras empresas: se o sistema a ser criado já existem em outra empresa que não se importa em fornecer detalhes do seu funcionamento marque entrevistas com os responsáveis daquele software para o conhecer melhor. • Coleta de Dados: Procure formulários, relatórios, manuais, procedimentos escritos,registros, imagens de tela de terminais e listagens de programas que já existam na organização usuária onde o sistema será criado • Pesquisa externa: Se você estiver construindo um sistema para uma nova aplicação, para a qual o usuário não dispõe de qualquer experiência para descrever os requisitos, talvez seja necessário tentar obter informações em sociedades profissionais, ou em periódicos e livros técnicos e em relatórios de pesquisas

×