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

Slides:



Advertisements
Apresentações semelhantes
Engenharia de Software
Advertisements

Engenharia de Software
Participantes do Processo de Desenvolvimento de Software
Engenharia de Software
Profa. MS.Sandra Regina Costa Antico Setembro/2010
Gerenciamento de Projetos
Processos de Software Introdução
Rational Unified Process(RUP)
O, S & M, O QUE É ? ORGANIZAÇÃO ANALISTA DE O, S & M SISTEMAS MÉTODOS.
A falta de Teste Aumento de falhas devido a podre qualidade;
Professor Sílder Lamas Vecchi
Mitos e Problemas Relacionados ao Software
Faculdade de Ciências Sociais de Aplicadas de Petrolina – FACAPE
Faculdade de Ciências Sociais e Aplicadas de Petrolina – FACAPE
Metodologia de desenvolvimento de sistemas
Adélia Barros Requisitos Adélia Barros
Avaliação de Sistemas Operacionais
Curso Sistemas de Informação Disciplina: Arquitetura de Software
Professor: Rogério Lopes Disciplina: Engenharia de Software II Fortium Sistemas da Informação Engenharia de Software II.
Análise e Projeto de Sistemas
TSDD Teste de segurança durante o desenvolvimento.
Plano de Projeto de Software
RUP - Cap. 2 – Os 4 P’s (Pessoas, Projeto, Produto e Processo)
Aula 1 Minicurso: Astah Ministrantes: André Martins; Camila Brondani;
Engenharia de Software
Desafios do desenvolvimento de software
Prof.Alfredo Parteli Gomes
Fundamentos de Engenharia de SW
Cap 2 – Processo de Software
Análise e Projeto de Sistemas
Abertura.
Caracterização e Objetivos das LP
Rapid Application Development (RAD)
Análise e Projeto de Sistemas
Introdução e Fundamentos Engenharia de Requisitos
Desenvolvimento Rápido de Aplicação (RAD)
Modelos de Processo de Software
O Processo de desenvolvimento de software
Introdução à Engenharia de Software
Analises de sistemas ESTRUTURADA Analise de sistema estruturada.
Paradigmas de Linguagens de Programação Aula 2
Documentação de Software
Desenvolvimento e uso de Sistemas de Informação
ANÁLISE ESTRUTURADA DE SISTEMAS
Engenharia de Software
Análise e Projeto de Sistemas de Informação 2o. Semestre de 2014 Material criado por Prof. Edinelson Revisão e atualização: Prof. Gustavo Gonzalez Faculdade.
Engenharia de Software
METODOLOGIA, MÉTODOS E FERRAMENTAS
Trabalho de Engenharia de Software II
Capítulo 10 – Qualidade de Produtos de Software Escrito por: Renata Araújo Vírginia Chalegre Apresentado por: Cleice.
Requisitos de Software
Técnicas e Projeto de Sistemas
UML e a Ferramenta Astah
Engenharia de Software
Gestão tecnológica de cadeias produtivas
1 Linguagens de Programação Pedro Lopes 2010/2011.
TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS ANÁLISE E PROJETO DE SISTEMAS Aula /08/2012 Professor Leomir J. Borba-
Prof. Carlos Augusto da Costa Carvalho
Professora Michelle Luz
Prof. Dr. Murilo de A.Souza Oliveira PROJETOS EM ADMINISTRAÇÃO
Erton W. Vieira Metodologias Ágeis, Qualidade de Software e Design Centrado no usuário: Pontos de Interação Erton W. Vieira.
Processos - I. © 2002 Wilson de Pádua Paula Filho Processos - I O que é Engenharia de Software Computador: problema ou solução? Enunciar os problemas.
Apresentação Leonardo Brussolo de Paula
TÉCNICAS DE ESTIMATIVAS
Desenvolvimento de Software I
Processos de Software Ludimila Monjardim Casagrande 1º Semestre Desenvolvimento e Qualidade.
Qualidade do Ponto de Vista de Gestão Aplicado na Homologação de software Márcia Falcão 27/03/2007 Qualidade do Ponto de Vista de Gestão, aplicado na Homologação.
INTELIGÊNCIA EMPRESARIAL Aula 8 - Metadados e Operações OLAP.
Elicitação de Requisitos Análise Orientada a Objetos Prof. Wolley W. Silva.
O Processo Unificado (PU). 2 O que é o Processo Unificado (PU)? É um modelo de processo de software baseado no modelo incremental, visando a construção.
Transcrição da apresentação:

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

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.

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.

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

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

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.

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

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

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.

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.

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.

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

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.

Principais Atores da Análise de Sistemas

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?

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.

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

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?

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.

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.

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.

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

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.

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

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.

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.

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.

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

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.

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

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

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

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

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

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

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.

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.

Obrigado! ?