A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

PROJETO ESTRUTURADO Prof° Mozart de Melo Alves Jr.

Apresentações semelhantes


Apresentação em tema: "PROJETO ESTRUTURADO Prof° Mozart de Melo Alves Jr."— Transcrição da apresentação:

1 PROJETO ESTRUTURADO Prof° Mozart de Melo Alves Jr.

2 EMENTA Metodologia de Desenvolvimento de Sistemas. Análise da Situação Atual e dos Requisitos do Sistema. Ciclo de Vida de Sistemas. Análise Essencial de Sistemas. Diagrama de Fluxo de Dados. Dicionário de Dados. Descrição de Funções Primitivas. Estudo de Casos com a aplicação da Análise Essencial de Sistemas. Metodologia de Desenvolvimento de Sistemas. Análise da Situação Atual e dos Requisitos do Sistema. Ciclo de Vida de Sistemas. Análise Essencial de Sistemas. Diagrama de Fluxo de Dados. Dicionário de Dados. Descrição de Funções Primitivas. Estudo de Casos com a aplicação da Análise Essencial de Sistemas. caracterização e aplicação de metodologias e ferramentas de modelagem de sistemas orientados a objetos - UML caracterização e aplicação de metodologias e ferramentas de modelagem de sistemas orientados a objetos - UML

3 O PAPEL DE UM ANALISTA Ser o elo entre o usuário e o computador Deverá entender e avaliar as necessidades e expectativas de cada usuário, a fim de que estas sejam organizadas e especificadas segundo uma formalidade técnica. Ser o elo entre o usuário e o computador Deverá entender e avaliar as necessidades e expectativas de cada usuário, a fim de que estas sejam organizadas e especificadas segundo uma formalidade técnica.

4 ADMINISTRADOR (Respostas sempre e para ontem, geralmente é o dono) ADMINISTRADOR (Respostas sempre e para ontem, geralmente é o dono) Analista de Sistema Pessoal Técnico (Performance Plataforma) elo técnico entre o analista e a empresa Pessoal Técnico (Performance Plataforma) elo técnico entre o analista e a empresa Usuário (Dinamizar o Serviço) tem influência na direta derruba ou ajuda o sistema Usuário (Dinamizar o Serviço) tem influência na direta derruba ou ajuda o sistema

5 O REQUISÍTOS DE UM ANALISTA Iniciativa Criatividade Concentração Persuasão Autoconfiança Ação conciliadora Espírito de Grupo Sensibilidade Iniciativa Criatividade Concentração Persuasão Autoconfiança Ação conciliadora Espírito de Grupo Sensibilidade Persistência Determinação Flexibilidade Percepção Clareza de Raciocínio Simplicidade Comunicativo Persistência Determinação Flexibilidade Percepção Clareza de Raciocínio Simplicidade Comunicativo

6 A Maior desvantagem em estabelecer uma lista de requisitos, é que jamais encontra- se alguém que venha a possuir todos eles.

7 OBSERVAR ALGUMAS DIRETRIZES Procure ser aceito profissionalmente, do nível mais alto ao mais baixo da empresa. Tente entender o que o cliente Quer Dizer e não o que Você Pensa que ele quer dizer. Escute muito primeiro, fale muito pouco depois (desenvolva grandes orelhas e boca pequena) Esteja sempre familiarizado com os últimos progressos da tecnologia de informação e compreenda como aplicá-los. Seja capaz de explicar conceitos complexos em termos simplificados fale a linguagem da empresa. Conheça a área de negocio, para a qual desenvolverá sistemas. Analise sempre a relação custo (Benefício, Utilizando alternativas viáveis). Procure ser aceito profissionalmente, do nível mais alto ao mais baixo da empresa. Tente entender o que o cliente Quer Dizer e não o que Você Pensa que ele quer dizer. Escute muito primeiro, fale muito pouco depois (desenvolva grandes orelhas e boca pequena) Esteja sempre familiarizado com os últimos progressos da tecnologia de informação e compreenda como aplicá-los. Seja capaz de explicar conceitos complexos em termos simplificados fale a linguagem da empresa. Conheça a área de negocio, para a qual desenvolverá sistemas. Analise sempre a relação custo (Benefício, Utilizando alternativas viáveis).

8

9 Sistemas de Informações A necessidade é a mãe das invenções A necessidade é a mãe das invenções Em conseqüência do crescimento da importância da informação, surgiu a necessidade de gerenciar informações de uma forma adequada e eficiente e, desta necessidade, surgiram os denominados sistemas de informações. Em conseqüência do crescimento da importância da informação, surgiu a necessidade de gerenciar informações de uma forma adequada e eficiente e, desta necessidade, surgiram os denominados sistemas de informações.

10 Sistemas de Informações Um SI é uma combinação de pessoas, dados, processos, interfaces, redes de comunicação e tecnologia que interagem com o objetivo de dar suporte e melhorar o processo de negócio de uma organização com relação às informações. Um SI é uma combinação de pessoas, dados, processos, interfaces, redes de comunicação e tecnologia que interagem com o objetivo de dar suporte e melhorar o processo de negócio de uma organização com relação às informações. Gerando Vantagens do ponto de vista competitivo. Gerando Vantagens do ponto de vista competitivo. Objetivo principal e final da construção de um SI: adição de valor – Aumentando a produtividade, Objetivo principal e final da construção de um SI: adição de valor – Aumentando a produtividade,

11 Sistemas de Software Um dos componentes de um SI é denominado sistema de software. Um dos componentes de um SI é denominado sistema de software. Compreende os módulos funcionais computadorizados que interagem entre si para proporcionar a automatização de diversas tarefas. Compreende os módulos funcionais computadorizados que interagem entre si para proporcionar a automatização de diversas tarefas.

12 Modelagem de sistemas Característica intrínseca do desenvolvimento de sistemas de software: complexidade de desenvolvimento. Característica intrínseca do desenvolvimento de sistemas de software: complexidade de desenvolvimento.

13 Uma analogia... Uma analogia... Sistemas de Software Arranha-Ceús Casa Aumento da complexidade Casa de Cachorro

14 Complexidade Na construção de sistemas de software, assim como na construção de sistemas habitacionais, também há uma gradação de complexidade. Na construção de sistemas de software, assim como na construção de sistemas habitacionais, também há uma gradação de complexidade. A construção desses sistemas necessita de um planejamento inicial. A construção desses sistemas necessita de um planejamento inicial.

15 Modelos De uma perspectiva mais ampla, um modelo pode ser visto como uma representação idealizada de um sistema a ser construído. De uma perspectiva mais ampla, um modelo pode ser visto como uma representação idealizada de um sistema a ser construído. Maquetes de edifícios e de aviões e plantas de circuitos eletrônicos são apenas alguns exemplos de modelos. Maquetes de edifícios e de aviões e plantas de circuitos eletrônicos são apenas alguns exemplos de modelos.

16 Gerenciamento da complexidade inerente ao desenvolvimento de software (pode haver modelos de um mesmo sistema, cada modelo descrevendo uma perspectiva do sistema a ser construído). Gerenciamento da complexidade inerente ao desenvolvimento de software (pode haver modelos de um mesmo sistema, cada modelo descrevendo uma perspectiva do sistema a ser construído). Comunicação entre as pessoas envolvidas. Comunicação entre as pessoas envolvidas. Redução dos custos no desenvolvimento( é muito mais fácil destruir uma maquete do que uma parede). Redução dos custos no desenvolvimento( é muito mais fácil destruir uma maquete do que uma parede). Predição do comportamento futuro do sistema(laboratório). Predição do comportamento futuro do sistema(laboratório). Razões para construção de modelos

17 No contexto de desenvolvimento de software, correspondem a desenhos gráficos que seguem algum padrão lógico. No contexto de desenvolvimento de software, correspondem a desenhos gráficos que seguem algum padrão lógico. Esses desenhos são normalmente denominados diagramas. Esses desenhos são normalmente denominados diagramas. Um diagrama é uma apresentação de uma coleção de elementos gráficos que possuem um significado predefinido. Um diagrama é uma apresentação de uma coleção de elementos gráficos que possuem um significado predefinido. Diagramas

18 Diagramas fornecem uma representação concisa do sistema. uma figura vale por mil palavras. Diagramas fornecem uma representação concisa do sistema. uma figura vale por mil palavras. No entanto, modelos também são compostos de informações textuais. No entanto, modelos também são compostos de informações textuais. Dado um modelo de uma das perspectivas de um sistema, diz-se que o seu diagrama, juntamente com a informação textual associada, formam a documentação deste modelo. Dado um modelo de uma das perspectivas de um sistema, diz-se que o seu diagrama, juntamente com a informação textual associada, formam a documentação deste modelo. Diagramas

19 Modelagem de Software A modelagem de sistemas de software consiste na utilização de notações gráficas e textuais com o objetivo de construir modelos que representam as partes essenciais de um sistema, considerando-se diversas perspectivas diferentes e complementares

20 O Processo de Desenvolvimento de Software Sendo um sociólogo, constatei que o desenvolvimento de software é um processo social altamente cooperativo. Jorg Strubing, 1991

21 Software is hard… Porcentagem de projetos que terminam dentro do prazo estimado: 10% Porcentagem de projetos que terminam dentro do prazo estimado: 10% Porcentagem de projetos que são descontinuados antes de chegarem ao fim: 25% Porcentagem de projetos que são descontinuados antes de chegarem ao fim: 25% Porcentagem de projetos acima do custo esperado: 60% Porcentagem de projetos acima do custo esperado: 60% Atraso médio nos projetos: um ano. Atraso médio nos projetos: um ano. Chaos Report (1994)

22 Software is hard… Software pago mas não entregue: 29.7% Software pago mas não entregue: 29.7% Software que pode ser usado quando entregue: 2% Software que pode ser usado quando entregue: 2% Software entregue mas nunca usado: 47% Software entregue mas nunca usado: 47% Software usado mas posteriormente modificado ou abandonado: 19% Software usado mas posteriormente modificado ou abandonado: 19% Software que podia ser usado após feitas mudanças: 3% Software que podia ser usado após feitas mudanças: 3% GAO Survey (1992)

23 Processo de Desenvolvimento Compreende as atividades necessárias para definir, desenvolver, testar e manter um produto (sistema) de software. Compreende as atividades necessárias para definir, desenvolver, testar e manter um produto (sistema) de software. Tentativas de lidar com a complexidade e de minimizar os problemas envolvidos no desenvolvimento de software. Tentativas de lidar com a complexidade e de minimizar os problemas envolvidos no desenvolvimento de software.

24 Objetivos de um Processo de Desenvolvimento Definir quais as atividades a serem executadas ao longo do projeto; Definir quais as atividades a serem executadas ao longo do projeto; Quando, como e por quem tais atividades serão executadas; Quando, como e por quem tais atividades serão executadas; Prover pontos de controle para verificar o andamento do desenvolvimento; Prover pontos de controle para verificar o andamento do desenvolvimento; Padronizar a forma de desenvolver software em uma organização. Padronizar a forma de desenvolver software em uma organização.

25 Atividades típicas Levantamento de requisitos Levantamento de requisitos Análise de requisitos Análise de requisitos Projeto Projeto Implementação Implementação Testes Testes Implantação Implantação

26 Participantes do processo Gerentes de projeto Gerentes de projeto Analistas Analistas Projetistas Projetistas Arquitetos de software Arquitetos de software Programadores Programadores Clientes Clientes Avaliadores de qualidade Avaliadores de qualidade

27 Participantes do usuário A participação do usuário é importante. A participação do usuário é importante.

28 Modelos de ciclo de vida

29 Modelo de Ciclo de Vida Um ciclo de vida corresponde a um encadeamento específico das fases para construção de um sistema. Um ciclo de vida corresponde a um encadeamento específico das fases para construção de um sistema. Dois modelos de ciclo de vida: Dois modelos de ciclo de vida: modelo em cascata modelo em cascata modelo iterativo e incremental. modelo iterativo e incremental.

30 Modelo de Ciclo de Vida em Cascata Tendência na progressão seqüencial entre uma fase e a seguinte. Tendência na progressão seqüencial entre uma fase e a seguinte.

31 Modelo de Ciclo de Vida em Cascata Projetos reais raramente seguem um fluxo seqüencial. Projetos reais raramente seguem um fluxo seqüencial. Assume que é possível declarar detalhadamente todos os requisitos antes do início das demais fases do desenvolvimento. Assume que é possível declarar detalhadamente todos os requisitos antes do início das demais fases do desenvolvimento. propagação de erros pelas as fases do processo. propagação de erros pelas as fases do processo. Uma versão de produção do sistema não estará pronta até que o ciclo do projeto de desenvolvimento chegue ao final. Uma versão de produção do sistema não estará pronta até que o ciclo do projeto de desenvolvimento chegue ao final.

32 Modelo de ciclo de vida iterativo e incremental Divide o desenvolvimento de um produto de software em ciclos. Divide o desenvolvimento de um produto de software em ciclos. Em cada ciclo de desenvolvimento, podem ser identificadas as fases de análise, projeto, implementação e testes. Em cada ciclo de desenvolvimento, podem ser identificadas as fases de análise, projeto, implementação e testes. Cada ciclo considera um subconjunto de requisitos. Cada ciclo considera um subconjunto de requisitos. Esta característica contrasta com a abordagem clássica, na qual as fases são realizadas uma única vez. Esta característica contrasta com a abordagem clássica, na qual as fases são realizadas uma única vez.

33 Modelo de ciclo de vida iterativo e incremental Desenvolvimento em mini-cascatas. Desenvolvimento em mini-cascatas.

34 Modelo de ciclo de vida iterativo e incremental Iterativo: o sistema de software é desenvolvido em vários passos similares. Iterativo: o sistema de software é desenvolvido em vários passos similares. Incremental: Em cada passo, o sistema é estendido com mais funcionalidades. Incremental: Em cada passo, o sistema é estendido com mais funcionalidades.

35 Modelo iterativo e incremental – Vantagens e Desvantagens Incentiva a participação do usuário. Incentiva a participação do usuário. Riscos do desenvolvimento podem ser mais bem gerenciados. Riscos do desenvolvimento podem ser mais bem gerenciados. Um risco de projeto é a possibilidade de ocorrência de algum evento que cause prejuízo ao processo de desenvolvimento, juntamente com as conseqüências desse prejuízo. Um risco de projeto é a possibilidade de ocorrência de algum evento que cause prejuízo ao processo de desenvolvimento, juntamente com as conseqüências desse prejuízo. Influências: custos do projeto,cronograma, qualidade do produto, satisfação do cliente, etc. Influências: custos do projeto,cronograma, qualidade do produto, satisfação do cliente, etc. Mais difícil de gerenciar Mais difícil de gerenciar

36 Ataque aos riscos Se você não atacar os riscos [do projeto] ativamente, então estes irão ativamente atacar você. (Tom Gilb). Se você não atacar os riscos [do projeto] ativamente, então estes irão ativamente atacar você. (Tom Gilb). Ou seja, a abordagem incremental e iterativa aconselha que as partes mais arriscadas sejam consideradas inicialmente. Ou seja, a abordagem incremental e iterativa aconselha que as partes mais arriscadas sejam consideradas inicialmente. Não se esconda dos riscos (como um avestruz). Não se esconda dos riscos (como um avestruz).

37 Análise Essencial Desenvolver sistemas de informação não é desenvolver programas

38 38 Motivado, normalmente por necessidades de última hora, situações de emergência, necessidades não antecipadas, (enfim ingerências, desorganização, falta de planejamento) as empresas se lançam na aventura de construir remendos para alicerçar suas bases para tomadas de decisão, e normalmente, tornam-se reféns dos aspectos que seguem:

39 39 Não há planejamento de qualquer natureza, isto compromete, futuras expansões, integrações e visão corporativa. Não há planejamento de qualquer natureza, isto compromete, futuras expansões, integrações e visão corporativa. Apenas uma pessoa detém o conhecimento sobre determinado desenvolvimento Apenas uma pessoa detém o conhecimento sobre determinado desenvolvimento Esta memória do conhecimento começa a apresentar problemas quando há um crescimento do sistema. Esta memória do conhecimento começa a apresentar problemas quando há um crescimento do sistema. Normalmente há problemas quando se trata de efetuar manutenção naquilo que foi desenvolvido Normalmente há problemas quando se trata de efetuar manutenção naquilo que foi desenvolvido Em geral não há qualquer documentação sobre o desenvolvimento, assim, qualquer intervenção no mesmo, requer a leitura dos programas fontes para se entender o que o sistema faz exatamente Em geral não há qualquer documentação sobre o desenvolvimento, assim, qualquer intervenção no mesmo, requer a leitura dos programas fontes para se entender o que o sistema faz exatamente

40 40 o objetivo básico do estabelecimento de um método padronizado no desenvolvimento de sistemas é obter maior consistência no trabalho, melhor qualidade oferecida ao usuário, maior facilidade no treinamento de novos Analistas, eliminação das perdas acarretadas por caminhos sem saída e, sem dúvida, melhor controle dos resultados obtidos no desenvolvimento de sistemas. o objetivo básico do estabelecimento de um método padronizado no desenvolvimento de sistemas é obter maior consistência no trabalho, melhor qualidade oferecida ao usuário, maior facilidade no treinamento de novos Analistas, eliminação das perdas acarretadas por caminhos sem saída e, sem dúvida, melhor controle dos resultados obtidos no desenvolvimento de sistemas. BALLESTERO ALVAREZ (1990)

41 41 O método que revela o estado da prática atual é a chamada Análise Essencial. Na Análise Essencial, deve-se considerar perfeito o ambiente tecnológico onde será implementado o software a ser projetado (princípio da neutralidade tecnológica). Isto significa considerar que a memória do computador é infinita, seu tempo de resposta é instantâneo, ele não para (não trava), não tem custo, ou seja, é infalível. Este aspecto propicia a análise pensar em uma solução ideal, no desenho do software, fazendo com que não sejam considerados certos requisitos impostos pelas restrições tecnológicas.

42 42 O método da Análise Essencial é uma evolução da Análise Estruturada, a qual o antecedeu. Pode-se sublinhar alguns fatores de seu uso: Um dos mais utilizado métodos atualmente. Um dos mais utilizado métodos atualmente. Princípio da Abstração Princípio da Abstração –Este aspecto permite resolver o problema, separando os aspectos que estão ligados a certa realidade, visando representá-los de forma simplificada e geral. Princípio da divisão. Princípio da divisão. –Para resolver um problema, o mesmo é dividido em um conjunto de problemas menores, que são mais fáceis de serem compreendidos e resolvidos.

43 43 O caminho da Análise Essencial

44 44 Domínio do Problema O primeiro momento, de altíssima importância é delimitar exatamente o que se espera do sistema a ser desenvolvido. Trata-se de estabelecer seus limites fronteiriços, exatamente o que deverá ser feito. O primeiro momento, de altíssima importância é delimitar exatamente o que se espera do sistema a ser desenvolvido. Trata-se de estabelecer seus limites fronteiriços, exatamente o que deverá ser feito. Por exemplo, alguém pode solicitar seus serviços para informatizar um hotel. Mas veja, um hotel é sem dúvida um macro problema. Ele é composto de várias facetas que podem ser informatizadas, como o controle da locação de quartos, o controle financeiro (contas a pagar/receber), a folha de pagamento dos funcionários, a contabilidade do hotel, enfim, é necessário que você verifique se a expectativa de quem o contratou é realmente informatizar todas estas facetas.

45 45 Todos os aspectos envolvidos no problema devem ser levantados, pessoas devem ser entrevistadas, documentos devem ser avaliados, o fluxo de trabalho deve ser entendido. Você deverá sair desta fase sendo quase um especialista sobre o assunto que deverá informatizar, ou seja, no mínimo saberá todos os eventos e dados essenciais relativos ao assunto.

46 Vantagens da Análise Essencial A Análise Essencial começa pelo modelo essencial, o que equivale, na Análise Estruturada, começar diretamente pelo modelo lógico proposto. A Análise Essencial começa pelo modelo essencial, o que equivale, na Análise Estruturada, começar diretamente pelo modelo lógico proposto. A Análise Estruturada aborda duas perspectivas do sistema - função e dados -, ao passo que a Análise Essencial aborda três perspectivas - função, dados e controle. A Análise Estruturada aborda duas perspectivas do sistema - função e dados -, ao passo que a Análise Essencial aborda três perspectivas - função, dados e controle. Na Análise Estruturada o particionamento é feito através da abordagem top-down, enquanto na Análise Essencial, o particionamento é por eventos Na Análise Estruturada o particionamento é feito através da abordagem top-down, enquanto na Análise Essencial, o particionamento é por eventos

47 Componentes da Análise Essencial Análise Essencial Modelo Ambiental Modelo Comportamental Declaração de Objetivos Diagrama de Contexto Lista de Eventos DFD Particionado Diagrama ER Normalização Dicionário de Dados

48 48 Especificação dos Requisitos Modelo Ambiental Modelo Ambiental –Você poderá definir qual a relação do sistema a ser desenvolvido com o ambiente no qual ele estará inserido. –Define a fronteira entre o sistema e o resto do mundo Modelo Comportamental Modelo Comportamental –Trabalho se volta para definição interna do sistema. Serão especificados todos os processos que irão compor o sistema. Haverá também a definição do modelo de dados que será utilizado para armazenar as informações por ele manipuladas. Projeto ( Design) Projeto ( Design) –Esta parte do trabalho cuidará das especificações referentes as limitações impostas pela tecnologia, a distribuição dos processos de acordo com os lugares onde serão executados.

49 Ferramentas O Analista de Sistemas, deverá utilizar algumas ferramentas que o ajudarão a trilhar o seu caminho.

50 50 Entrevistas A reunião pode ter um momento de questionamentos, na busca de informações; ou seja, uma entrevista, normalmente sem qualquer conotação de rigor ou formalidade como o termo pode sugerir. A reunião pode ter um momento de questionamentos, na busca de informações; ou seja, uma entrevista, normalmente sem qualquer conotação de rigor ou formalidade como o termo pode sugerir. Entrevistas portanto, são situações inseridas nas relações humanas que não estão sujeitas a regras ou fórmulas exatas. Mas, pode ser útil que o Analista de Sistemas tenha em mente alguns aspectos, relacionados a esta atividade que poderão ajudar na sua execução. Entrevistas portanto, são situações inseridas nas relações humanas que não estão sujeitas a regras ou fórmulas exatas. Mas, pode ser útil que o Analista de Sistemas tenha em mente alguns aspectos, relacionados a esta atividade que poderão ajudar na sua execução.

51 51 O objetivo de uma entrevista (para a análise de sistemas) é o de coleta de informações sobre o sistema a ser desenvolvido. Talvez, seja esta a fonte mais rica de conhecimentos sobre o sistema que deverá ser feito. Ajuda nos aspectos chaves do sistema bem como esclarece pontos contraditórios do mesmo, ou, em alguns casos, torna o aspecto mais contraditório, o que é algo também importante de se conhecer. Verifica-se posicionamentos pessoais acerca das questões envolvidas (omissões, medo, desvios). O objetivo de uma entrevista (para a análise de sistemas) é o de coleta de informações sobre o sistema a ser desenvolvido. Talvez, seja esta a fonte mais rica de conhecimentos sobre o sistema que deverá ser feito. Ajuda nos aspectos chaves do sistema bem como esclarece pontos contraditórios do mesmo, ou, em alguns casos, torna o aspecto mais contraditório, o que é algo também importante de se conhecer. Verifica-se posicionamentos pessoais acerca das questões envolvidas (omissões, medo, desvios). Não raro, haverá a necessidade de se entrevistar diversas vezes uma ou várias pessoas, para se chegar a informação desejada. Não raro, haverá a necessidade de se entrevistar diversas vezes uma ou várias pessoas, para se chegar a informação desejada.

52 52 Como Preparar uma Entrevista Alguns cuidados devem ser tomados: Clareza de sua finalidade Clareza de sua finalidade Identificação de perguntas chaves Identificação de perguntas chaves Repasse de documentação formal (se houver) Repasse de documentação formal (se houver)

53 53 Quando se tratar de aspectos gerais sobre um assunto, a pessoa mais indicada para se buscar esta informação é a gerência. Quando o interesse for para assuntos que exijam maior riqueza de detalhes, o ideal é entrevistar uma pessoa operacional, que esteja no seu dia a dia, envolvida com aquele aspecto. Mas, lembre-se da hierarquia da empresa, primeiro fale com o supervisor a quem a pessoa estiver locada. Isto envolve desde aspectos políticos até um fator de motivação para que a pessoa fale melhor sobre o assunto, visto que o chefe a indicou por ser a melhor funcionária que domina aquela questão.... Quando se tratar de aspectos gerais sobre um assunto, a pessoa mais indicada para se buscar esta informação é a gerência. Quando o interesse for para assuntos que exijam maior riqueza de detalhes, o ideal é entrevistar uma pessoa operacional, que esteja no seu dia a dia, envolvida com aquele aspecto. Mas, lembre-se da hierarquia da empresa, primeiro fale com o supervisor a quem a pessoa estiver locada. Isto envolve desde aspectos políticos até um fator de motivação para que a pessoa fale melhor sobre o assunto, visto que o chefe a indicou por ser a melhor funcionária que domina aquela questão.... Programe a entrevista de acordo com a disponibilidade do entrevistado. Programe a entrevista de acordo com a disponibilidade do entrevistado.

54 54 Toda entrevista bem conduzida, formal ou não, possui três aspectos: Abertura Abertura –procure estabelecer uma atmosfera amigável para a comunicação, informe sobre o objetivo. Corpo Corpo –se caracteriza por ser a entrevista propriamente dita. –Certifique-se de que entendeu o que lhe foi transmitido. Um meio indicado é o repasse (deixa ver se entendi, então quer dizer que...). Fecho Fecho –procure manter a atmosfera de comunicabilidade. Esteja atento ao horário para evitar qualquer transtorno ao entrevistado. Agradeça a colaboração, mesmo que o encontro tenha sido infrutífero e distante do planejado.

55 55 Entrevista não é julgamento, disputa do saber ou concorrência com o entrevistado. Lembre-se sempre que a pessoa é a especialista no que faz e você apenas busca informações. Procure distinguir fatos de opiniões pessoais.

56 56 Modelo de entrevista segundo Gaus e Weinberg (1989) 1. O primeiro conjunto de questões de contexto livre focaliza o cliente, as metas globais e os benefícios. Por exemplo o analista poderia perguntar a. Quem está por trás da solicitação deste trabalho ? b. Quem vai usar a solução? c. Qual será o benefício econômico ? d. Há outra fonte para solução ?

57 57 Modelo de entrevista segundo Gaus e Weinberg (1989) 2. O conjunto de questões a seguir permite ao analista entender melhor o problema e ao cliente verbalizar suas percepções sobre a solução : a. Quais problemas a solução vai resolver ? b. Você pode me mostrar o ambiente ( estrutura física) ?

58 58 Modelo de entrevista segundo Gaus e Weinberg (1989) 3. O conjunto final de questões focaliza a efetividade da reunião (metaquestão) a. É a pessoa adequada para responder as questões ? b. As repostas são oficiais ? c. Eu estou fazendo pergunta demais ? d. Alguém mais pode me dar informação adicional ? e. Eu deveria perguntar mais alguma coisa ?


Carregar ppt "PROJETO ESTRUTURADO Prof° Mozart de Melo Alves Jr."

Apresentações semelhantes


Anúncios Google