Prof° Mozart de Melo Alves Jr.

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

1 Prof° Mozart de Melo Alves Jr.
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. 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.

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

5 O REQUISÍTOS DE UM ANALISTA
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

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

8

9 Sistemas de Informaçõ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.

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. Gerando Vantagens do ponto de vista competitivo. 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. 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.

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

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. 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. Maquetes de edifícios e de aviões e plantas de circuitos eletrônicos são apenas alguns exemplos de modelos.

16 Razões para construção de modelos
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. 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).

17 Diagramas 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. Um diagrama é uma apresentação de uma coleção de elementos gráficos que possuem um significado predefinido.

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

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 são descontinuados antes de chegarem ao fim: 25% Porcentagem de projetos acima do custo esperado: 60% Atraso médio nos projetos: um ano. Chaos Report (1994)

22 “Software is hard…” Software pago mas não entregue: 29.7%
Software que pode ser usado quando entregue: 2% Software entregue mas nunca usado: 47% Software usado mas posteriormente modificado ou abandonado: 19% 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. 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; Quando, como e por quem tais atividades serão executadas; Prover pontos de controle para verificar o andamento do desenvolvimento; Padronizar a forma de desenvolver software em uma organização.

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

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

27 Participantes do usuário
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. Dois modelos de ciclo de vida: modelo em cascata 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.

31 Modelo de Ciclo de Vida em Cascata
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. 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.

32 Modelo de ciclo de vida iterativo e incremental
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. 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.

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

34 Modelo de ciclo de vida iterativo e incremental
Iterativo: o sistema de software é desenvolvido em vários passos similares. 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. 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. Influências: custos do projeto,cronograma, qualidade do produto, satisfação do cliente, etc. 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). 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). PDS = Processo de Desenvolvimento de Software

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

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 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 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 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 “ 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 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 Um dos mais utilizado métodos atualmente.
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. 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. 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 O caminho da Análise Essencial

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

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

48 Especificação dos Requisitos
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 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) 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 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. 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 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.

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

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...”. Programe a entrevista de acordo com a disponibilidade do entrevistado.

54 Toda entrevista bem conduzida, formal ou não, possui três aspectos:
Abertura procure estabelecer uma atmosfera amigável para a comunicação, informe sobre o objetivo. 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 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 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 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 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 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 ?