Análise e Projeto de Sistemas para a Internet

Apresentação em tema: "Análise e Projeto de Sistemas para a Internet"— Transcrição da apresentação:

1 Análise e Projeto de Sistemas para a Internet
Centro Federal de Educação Tecnológica da Paraíba Coordenação de Informática Desenvolvimento de Software para a Internet

2 Conteúdo Apresentação e Conceitos fundamentais de Análise e Projeto de Sistemas 1. Noções de Engenharia de Software 2. Modelos de ciclo de vida e métodos de desenvolvimento 3. Análise de requisitos de sistema e de software 4. Levantamento de dados 5. Gerenciamento de software Análise estruturada, DFD e dicionário de dados Análise essencial, DFD, DER, DTE e dicionário de dados Análise orientada a objetos Detalhamento do RUP e de outros métodos de desenvolvimento Análise e projeto orientados a objetos e UML Requisitos e diagramas de caso de uso Aplicações de casos de uso Diagramas de classe e de objetos Aplicações de diagramas de classe e de objetos Diagramas de estados Aplicação de diagramas de estados Diagramas de sequência e colaboração (comunicação) Aplicação de diagramas de sequência e colaboraçào (comunicação) Diagramas de atividades, componentes e aplicação e suas aplicações Extensões UML para a Internet Aplicação de extensões UML para a Internet Especificidades de Análise e Projeto de Sistemas para a Internet

3 Apresentação e Conceitos fundamentais de Análise e Projeto de Sistemas
Objetivo: mostrar a proposta do curso, suas vantagens e limitações e as questões e os termos básicos que hoje estão a ele vinculados

4 Bom, o curso é de ANÁLISE e PROJETO de SISTEMAS…
Apresentação Bom, o curso é de ANÁLISE e PROJETO de SISTEMAS… O que é análise? O que é projeto? O que é um sistema? A compreensão de um sistema implica os seguintes eventos: Interdependência Importação / exportação Feedback Homeostasia Morfogênese Entropia Redundância

5 Falhas no entendimento de um sistema ocorrem devido a falhas nos seus eventos
A história do desenvolvimento de um sistema de balanço Falha no entendimento do sistema devido a uma provável falta de feedback

6 Alguma sugestão para melhorar de cara?
Apresentação Desvantagens da disciplina ANÁLISE E PROJETO DE SISTEMAS PARA A INTERNET Relativamente nova no curso Nova para a Internet Falta de experiência acadêmica da disciplina Falta de experiência empresarial, prática (sic), real ou outro termo melhor Alguma sugestão para melhorar de cara? Alguma orientação também para que “o curso sirva para algo”? Alguma motivação de vocês para fazer o curso?

7 Apresentação Minhas motivações… Estudar e trabalhar com novos paradigmas científicos em computação A computação e o desenvolvimento de sistemas deram uma guinada científica em função, entre outras coisas, da convergência do mundo acadêmico com as atividades de desenvolvimento “reais” Estudar a tecnologia e o desenvolvimento em uma atividade prática e próxima do dia-a-dia do profissional à luz de novos paradigmas científicos Isso só é possível sabendo antes o que é: Ciência Tecnologia Produto Modelo Método E até mesmo escolher um tema de projeto

8 Dicas para escolher um tema para o projeto
Apresentação Dicas para escolher um tema para o projeto 1) identificar as “necessidades” antes de tudo 2) propor soluções ADEQUADAS para as necessidades Grandes fracassos em desenvolvimento de software começaram por não atender o que foi dito anteriormente! … mas há outra motivação mais SÉRIA: Entender o que tem a ver ciência, tecnologia, desenvolvimento, empregabilidade, mercado (sic)? OU SEJA, como dar sentido ao fato de estudar aqui no CEFET e exatamente esta disciplina?

9 Possíveis respostas Ter um diferencial para o que tem hoje no mercado
Apresentação Possíveis respostas Ter um diferencial para o que tem hoje no mercado Entender que um sistema bem especificado, com uma elaboração rigorosa e formal, e bons testes e controles PODE NÃO DAR CERTO! Cuidado com quem sempre despreza isso e também com quem acha que assim sempre dará certo! Ter uma visão conjunta dos fatores críticos de sucesso do futuro 1) do profissional 2) do ferramental 3) do desenvolvimento integrado 4) da prototipação 5) da orientação a objeto 6) e principalmente do que é um trabalho com contrato Mesmo sem contrato, faça “APLICATIVOS MATADORES PARA A INTERNET” (Yourdon)

10 OPS! É aí que entra a ANÁLISE E O PROJETO DE SISTEMAS PARA A INTERNET
Apresentação O mercado não está tão bom mas questões como o estudo dos modelos de desenvolvimento e a avaliação deles têm sido cruciais para as reais mudanças na pesquisa e no mercado… OPS! É aí que entra a ANÁLISE E O PROJETO DE SISTEMAS PARA A INTERNET E as especificidades para se pensar em APS para a Internet podem começar com os seguintes fatores: Sempre houve medo de controle, mas a tecnologia evoluiu e precisou de novas formas de desenvolvimento para efetivar melhor o controle, além das ferramentas e linguagens Há um Tsunami de empregos na Internet É importante definir os trabalhos da ciência da informática e suas especificidades na Internet e como mudam em função do conhecimento

11 EXERCÍCIO DA APRESENTAÇÃO
Identifique necessidades de informatização na Internet para um determinado problema e proponha soluções adequadas para este problema. Você pode imaginar uma situação, mas não pode prescindir de pensar na “adequabilidade” em relação a sua função profissional, ao ferramental que você imagina utilizar e com a forma como você pensa desenvolver.

12 Noções de Engenharia de Software 1. 1 O problema do software 1
Noções de Engenharia de Software 1.1 O problema do software 1.2 A velha crise do software! 1.3 Os velhos mitos do software! Objetivo: mostrar o que é a Engenharia de Software e a sua importância na análise e projeto de sistemas

13 O software é um produto diferencial em vários aspectos…
Noções de Engenharia de Software 1.1 O PROBLEMA DO SOFTWARE O software é um produto diferencial em vários aspectos… Evolutivo Feedback, interacional …e faz a diferença hoje até mais do que o hardware Evolução do software: Quarta era: Desk-top poderoso Orientação a objeto Sistemas especialistas / redes neurais Segunda era: Multiusuário Tempo real Produto de software Primeiros anos: Batch Distribuição limitada Customizado Terceira era: Sistemas distribuídos IA Baixo custo de hardware Adaptado de Pressman (1995)

14 Em direção a uma quinta era novos problemas surgem
Noções de Engenharia de Software Em direção a uma quinta era novos problemas surgem A sofisticação do software ultrapassou a capacidade de construir um software que tirasse potencial do hardware A capacidade de construir programas não acompanha a demanda A capacidade de construir programas é ameaçada por projetos ruins e recursos inadequados Em resposta a esses problemas estão sendo adotadas práticas da engenharia Especificamente, em relação ao desenvolvimento para a Internet, há alguma mudança?

15 E software para a Internet?
Noções de Engenharia de Software Voltando às práticas de engenharia, um dos primeiros problemas encontrados foi a própria definição de software Instruções que quando executadas produzem a função e o desempenho desejados (Pressman) Estruturas de dados que possibilitam que os programas manipulem adequadamente a informação Documentos que descrevem a operação e o uso dos programas Fairley diferencia produto de software de software para uso pessoal Há definições do ponto de vista de outros profisionais que não são de informática, mas participam do desenvolvimento do software Há definições do ponto de vista do usuário E software para a Internet?

16 Talvez o melhor seja descobrir as características do “software” para os interesses da disciplina em relação ao desenvolvimento. Nesse caso: 1) O software é desenvolvido ou projetado por engenharia, não manufaturado no sentido clássico Problema para a engenharia de hoje: a visão do software nem como produto de engenharia nem como produto de manufatura 2) O software não se desgasta Há uma diferença básica em relação ao HARDWARE! Curvas de falhas - Pressman (1995)

17 3) A maioria dos softwares é feita sob medida em vez de ser montada a partir de componentes existentes A visão de hoje no desenvolvimento radicalizou mais Mas em relação ao desenvolvimento existem hoje novas formas de concebê-lo que subvertem muito a concepção tradicional XP (eXtreme Programming) por exemplo: se baseia em quatro valores Feedback Comunicação Simplicidade Coragem De uma forma que nem vê o software como um produto de manufatura nem como uma adaptação da engenharia, mas como “a construção de um livro”

18 Além das características, é importante também compreender os componentes de software
Há os componentes executáveis e os não executáveis Exigências do cliente Conversões que mapeiam as exigências Projeto Conversão em uma linguagem que especifica as estruturas de dados, os atributos procedimentais e os requisitos Tradutor Conversão em instruções que são executadas em uma máquina

19 O software ainda possui aplicações que têm como fatores importantes o conteúdo e a determinância
Software básico Software de tempo real Software comercial Software científico e de engenharia Software embutido Software de computador pessoal Software de IA …

20 1.2 A VELHA CRISE DO SOFTWARE! Problemas associados
Não dedicamos tempo para coletar dados sobre o processo de desenvolvimento de software A insatisfação do cliente é frequente A qualidade de software é questionada O software é difícil de manter As causas podem ser atacadas pela ES Projeto Comunicação Gerência Enfrentamento de mudanças Bom, XP subverte esta idéia, que seria nova!

21 1.3 OS VELHOS MITOS DO SOFTWARE! Administrativos
Mito1: Já tenho um manual com padrões e procedimentos. Isso já não oferece o que o pessoal precisa saber? Realidade: O manual é usado? Os profissionais têm conhecimento? Reflete uma prática moderna? É completo? Mito2: Meu pessoal tem as ferramentas de desenvolvimento de última geração e os melhores computadores Realidfade: As ferramentas de ES são mais importantes do que o hardware, mas a maioria ainda não usa Mito3: Se estamos atrasados, podemos adicionar mais programadores e tirar o atraso (horda de mongóis) Realidade: O desenvolvimento de software não é mecânico igual à manufatura

22 Mitos do cliente Mito1: uma declaração geral dos objetivos é suficiente para se começar a escrever programas – podemos preencher os detalhes mais tarde Realidade: uma definição inicial ruim é a principal causa do fracasso. É fundamental uma descrição mais formal. Mito2: Os requisitos de projeto modificam-se continuamente, mas as mudanças podem ser facilmente acomodadas, porque o software é flexível Realidade: uma mudança, quando solicitada tardiamente, pode ser muito mais dispendiosa do que se fosse solicitada no início

23 Mitos do profissional Mito1: assim que escrevermos o programa e o colocarmos em funcionamento, nosso trabalho estará completo Realidade: “quanto mais cedo se escreve o código, mais tempo se demora para terminá-lo” Mito2: enquanto não tiver o programa “funcionando”, eu não terei como avaliar sua qualidade Realidade: as revisões técnicas formais têm sido mais eficientes do que os testes para a descoberta de certa classe de problemas de software Mito3: a única coisa a ser entregue em um projeto bem sucedido é o programa funcionando Realidade: esta afirmação desconhece a figura adiante e a documentação

24 Especificação de requisitos Projeto
Estrutura de dados Programa funcionando Listagem Plano Especificação de requisitos Projeto Especificação de testes

25 Além de acabar com os mitos, é essencial
Oferecer assistência para as práticas Melhorar a qualidade Permitir que o software acompanhe o desenvolvimento do hardware Quando combinamos… Métodos abrangentes para todas as fases de desenvolvimento Melhores ferramentas para automatizar o processso Blocos de construção mais sólidos Melhores técnicas para a qualidade de software e uma filosofia de coordenação predominante, controle e administração … fazemos uso da ENGENHARIA DE SOFTWARE

26 Definições de Engenharia de Software
“É a ciência e a arte de com economia, em tempo útil e de forma elegante, especificar, projetar, implementar e manter atualizados e corretos, programas, documentação e procedimentos operacionais para sistemas computacionais de utilidade para a humanidade” (Alan Brown, Anthony Earl e John McDermid) “Aplicação prática do conhecimento científico no projeto e construção de programas e da documentação requerida para desenvolver, operar e manter esses programas” (Boehm) etc

27 Definição de ES de Fritz Bauer
“Estabelecimento e uso de sólidos princípios de engenharia para que se possa obter economicamente um software que seja confiável e que funcione eficientemente em máquinas reais” A ES engloba: 1) Métodos – “como fazer” Planejamento e estimativa de projeto Análise de requisitos de software e de sistemas Projeto da estrutura de dados Arquitetura de programa e algoritmo de processamento Codificação, teste e manutenção Os métodos muitas vezes introduzem notações gráficas ou orientadas a uma linguagem especial e conjuntos de critérios para a qualidade de software

28 2) Ferramentas – apoio automatizado ou semi-automatizado aos métodos
Sustentam cada um dos métodos ou os métodos de forma integrada (CASE – computer-aided software engineering) Combina hardware, software e banco de dados de ES 3) Procedimentos – elo que liga métodos a ferramentas Sequência dos métodos Produtos a serem entregues (deliverables) Controles de qualidade e mudança A ES compreende conjuntos de etapas que envolvem métodos, ferramentas e procedimetos em modelos ou paradigmas de ES

29 Noções de Engenharia de Software
Na Internet, onde antes as informações eram usadas mais estaticamente, os métodos, ferramentas e procedimentos devem ser combinados para dar suporte a aplicações a serem usadas de diversas maneiras para os mais diversos usos

30 EXERCÍCIO DE NOÇÕES DE ENGENHARIA DE SOFTWARE
Descreva como construir uma determinada aplicação para a Web levando em consideração como o conteúdo e a determinância estão relacionados com os métodos, as ferramentas e os procedimentos.

31 Noções de Engenharia de Software
Ciclos de vida do software 2.1 O ciclo de vida em cascata 2.2 O ciclo de vida evolucionário 2.3 Prototipagem 2.4 Modelo espiral 2.5 Métodos de desenvolvimento Objetivo: mostrar os modelos de desenvolvimento de software e os métodos de desenvolvimeto para que se esclareça a forma como os projetos eram e são desenvolvidos

32 O estudo e a sistematização do processo de desenvolvimento de software, ou seja, a ES, requer que se conheçam as características do produto desejado e da tecnologia que será utilizada A partir dela, surgiram questões relacionadas às práticas e ao perfil do profissional de informática e à visibilidade do projeto Práticas Pergunta: Como vocês estão realizando o trabalho de construção do sistema? (Yourdon) Respostas: sobre uma ferramenta ou uma marca Tais respostas refletem o fracasso de construção do sistema que não leva em consideração melhores práticas:

33 Perfil do profissional de informática envolve habilidades
Gerenciamento de risco Especificação Inspeção e revisão de pares Cronogramento e rastreamento com métricas Rastreamento de defeitos e controle de qualidade Especificações de hardware e software Responsabilidade gerencial Visibilidade Perfil do profissional de informática envolve habilidades Comunicação Capacidade de análise Conhecimento da atividade do usuário Capacidade de negociação Administração de projetos Conhecimento técnico funções específicas para analista, projetista, programador

34 Precisamos então entender esses modelos
Visibilidade Como um modelo de ciclo de vida contempla o gerencimento de software? Através de um método que permita ver o progresso ou a falta de progresso em um projeto Precisamos então entender esses modelos

35 O processo de desenvolvimento é orientado por modelos de ciclo de vida
As funções primárias são: Determinar as fases Determinar a ordem das atividades e a atividade de cada etapa Estabelecer critérios para a transição das fases O estudo do desenvolvimento trouxe novas sugestões O mais primitivo foi o “caótico”, artesanal, “se colar colou”, codificar e consertar, com foco na programação

36 2.1 O CICLO DE VIDA EM CASCATA
A complexidade e o tamanho dos sistemas ocasionou sugestões mais focadas em sistemas do que em programas A primeira dessas sugestões foi baseada na engenharia de sistemas: o modelo em cascata

37 Análise Projeto Requisitos do sistema Domínio do problema
Requisitos e modelagem conceitual documentados para o usuário Projeto Vários passos com quatro atributos: Estrutura de dados Arquitetura de software Detalhe procedural Projeto da interface O documento especificação de projeto é baseado na especificação de requisitos

38 Construção Avaliação Manutenção Codificação Inspeção Walkthrough
Prova formal Testes Os testes devem ser devidamente planejados PERGUNTA: Quando o sistema é entregue ao usuário? após resultado satisfatório dos testes, mas pode haver erros Observados pelo usuário De adaptação ao ambiente De desempenho Manutenção Modificações devido a erros, adaptação e desempenho

39 O ciclo de vida em cascata ou “clássico” é o paradigma mais antigo e o que mostrou maior evolução até então Desvantagens Os projetos reais raramente seguem o fluxo sequencial do modelo Há necessidade de iterações É difícil declarar todas as exigências no início Há incerteza natural nos projetos O cliente precisa de muita paciência Há problemas terríveis em erros não previstos

40 2.2 CICLO DE VIDA EVOLUCIONÁRIO
Expansão gradativa com comportamentos do software É variante do “cascata” e o projeto foi decomposto em físico e lógico Viabilidade – é viável? lógico Requisitos – ok? projeto – concluído? físico codificação – testado? implantação – viável manutenção – problemas?

41 2.3 PROTOTIPAGEM Forma de desenvolvimento incremental com quatro tipos
Ilustrativo (telas) Simulado (acesso a banco de dados) Funcional (subconjunto limitado) Evolucionário (começa pequeno e cresce) – não descartável

42 O que fazer com um protótipo quando ele identificar os requisitos de software?
Desvantagens O cliente pode ver qualquer protótipo como uma versão de trabalho do software O desenvolvedor se familiariza com algumas opções de implementação e faz concessões para entregar o produto rapidamente A questão é se se deve planejar antecipadamente a construção de algo que se vai jogar for ou prometer entregar isso ao cliente Vale a pena defender a honestidade com o cliente?

43 Após o modelo evolucionário e de prototipação surgiram outros variantes
Ciclo de vida com reutilização Ciclo de vida com síntese automática Modelos de fusão… … até o surgimento do que hoje se considera um metamodelo

44 2.4 MODELO ESPIRAL Baseado em processos e níveis de risco Cíclico
Pode ser considerado incremental Os riscos levam em conta “prosseguir” / “não prosseguir” O fluxo ao redor da trajetória em espiral leva ao desenvolvimento mais completo distribuído em quatro quadrantes

45

46 2.5 MÉTODOS DE DESENVOLVIMENTO
vários serão discutidos durante o curso, mas a tabela abaixo resume alguns TÉCNICAS ABORDAGENS FERRAMENTAS ANÁLISE TRADICIONAL *FUNCIONAL *TEXTOS *FLUXOGRAMAS ESTRUTURADA *DADOS *DIAGRAMA DE FLUXO DE DADOS *DIAGRAMA DE ESTRUTURA DE DADOS *MINIESPECIFICAÇÕES *NORMALIZAÇÃO *DICIONÁRIO DE DADOS ESSENCIAL *CONTROLE *TABELA DE EVENTOS *DIAGRAMA DE ENTIDADE-RELACIONAMENTO *DIAGRAMA DE TRANSIÇÃO DE ESTADOS

47 Noções de Engenharia de Software
3. Análise de requisitos de sistema e de software 3.1 Análise de requisitos de sistema 3.2 Análise de requisitos de software Objetivo: mostrar o papel da análise de requisitos de sistema e sua aplicacação na análise de requisitos de software, bem como as principais atividades e documentos associados

48 3.1 ANÁLISE DE REQUISITOS DE SISTEMA
A análise de requisitos de sistema surgiu para solucionar problemas e o engenheiro de sistemas começa a sua resolução com metas e restrições definidas pelo cliente e deriva uma representação da função, desempenho, interfaces, restrições de projeto e estrutura Deve-se começar com a idéia de função desejada – demarcar o sistema ao identificar o escopo da função e desempenho requeridos (as restrições e as interfaces) Depois, deve-se passar para a tarefa de alocação – designar funções a um ou mais elementos do sistema

49 Exemplo: sistema de classificação por correia transportadora (CLSS)

50 O engenheiro de sistemas recebe uma declaraçaõ “nebulosa” dos objetivos do CLSS quanto ao movimento da linha, classificação, identificação, impressão, ordem e espaçamento Para demarcar, o engenheiro deve identificar o escopo da função e desempenho desejados Não basta dizer que o robô reagirá rapidamente quando a bandeja estiver vazia mas 1) indicar o que é uma bandeja vazia para o robô 2) saber os limites precisos de tempo 3) qual forma uma resposta deve assumir

51 Uma série de perguntas pode ser feita
Quantos números de identificação? Qual a velocidade da correia? Qual a distância da estação para os depósitos? E entre os depósitos? O que aconteceria se uma caixa não tivesse o número de identificação? E se o depósito fica cheio? As informações devem ser repassadas para outro canto? Que erro é aceitável? Que peças existem atualmente? Que restrições de orçamento e prazo?

52 Então, o engenheiro demarca as funções principais
FUNDAMENTAL! Note que o engenheiro não pergunta como a tarefa deve ser feita, mas o que é exigido Então, o engenheiro demarca as funções principais Ler a entrada do código de barras Ler o tacômetro de impulsos Decodificar os dados dos códigos de peças Executar busca em banco de dados Determinar a localização do depósito Produzir sinais de controle para o mecanismo de desvio

53 ... E faz alocações alternativas
1) treina e aloca operador de linha 2) um leitor de código e um controlador com um desvio mecânico 3) um leitor de código e um controlador com um braço mecânico Critérios para configuração do sistema Consideraçôes de projeto Considerações de negócio Análise técnica Avaliação da manufatura Questões humanas Interfaces ambientais Consideraçôes jurídicas Também deve se pensar em soluções não convencionais!!!

54 As informações reunidas durante a etapa de identificação das necessidades deve ser reunida num Documento Conceitual do Sistema com algumas funções

55 Diagrama geral de contexto da arquitetura
A modelagem é feita em um documento de especificaçao e pode ser feita em um diagrama de contexto da arquitetura e em um diagrama de fluxo da arquitetura Outras ferramentas como descrições e dicionários podem ser utilizados Diagrama geral de contexto da arquitetura

56 Diagrama do CLSS do contexto da arquitetura

57 Diagrama do CLSS do fluxo da arquitetura

58 3.2 ANÁLISE DE REQUISITOS DE SOFTWARE
Qualquer que seja o projeto ou a boa codificação de um programa, a sua má análise frustará o usuário Esforços de uma análise de requisitos de software Reconhecimento do problema Avaliação e síntese Modelagem Especificação Revisão No final, estar preparado para as ambiguidades “sei que você acredita que entendeu o que acha que eu disse, mas não estou certo de que percebe que aquilo que ouviu não é o que eu pretendia dizer…”

59 Cada uma das tarefas descreve o problema de forma que uma solução global possa ser sintetizada
Exemplo: Um sistema de controle de estoques é exigido por um grande fornecedor de autopeças QUE PROBLEMAS NO ATUAL SISTEMA PODEM SER IDENTIFICADOS? Como nos requisitos de sistema, o foco da síntese e avaliação deve cair sobre “o que” e não “como” Um manual do usuário pode ser rascunhado para o caso em que um protótipo não esteja sendo desenvolvido

60 Um analista deve exibir nos seus esforços traços característicos…
Compreensão de conceitos abstratos Absorver fatos pertinentes Entender o ambiente do usuário Aplicar elementos do sistema aos elementos do usuário Comunicar-se bem nas formas escrita e verbal Capacidade de “ver as florestas entre as árvores” … e coordenar cada uma das tarefas associadas à análise de requisitos de software

61 Problemas durante a análise de requisitos de software
Dificuldade para obter informações pertinentes Complexidade Mudanças durante e após a análise O crescimento do sistema aumenta os problemas e as mudanças começam a ser vistas em termos de mudanças de exigência Primeira lei da engenharia de sistemas: “Não importa onde se esteja no ciclo de vida do sistema, o sistema se modificará, e o desejo de mudá-lo persistirá ao longo de todo o ciclo” (Bersoff)

62 Técnicas de comunicação e facilitação para especificação de aplicações
Um encontro pode estabelecer desconcerto entre as partes, mas algumas etapas podem ser iniciadas: Perguntas livres do contexto (direcionadas ao cliente) Quem está por trás do pedido deste trabalho? Quem usará a solução? Qual é o benefício econômico de uma solução? Há outra fonte para a solução exigida? Compreensão do problema (verbalização do cliente sobre uma percepção da solução) Como você caracterizaria um bom resultado? Qual problema essa solução resolverá? Você pode mostrar o ambiente? Existem questões de desempenho ou restrições especiais?

63 Metaperguntas (efetividade do encontro)
Você é a pessoa certa? Suas respostas são oficiais? Minhas perguntas são pertinentes ao problema que você tem? Estou fazendo perguntas demais? Há mais alguém que possa fornecer informações adicionais? Existe algo mais que devo perguntar-lhe? A técnica FAST (facilitated application specification techniques) estimula a criação de uma equipe conjunta de clientes e desenvolvedores e tem algumas diretrizes Encontros em locais neutros Regras para participação Agenda formal para cobrir os pontos importantes e informal para encorajar o fluxo de idéias Um moderador Mecanismos de definição

64 Após o encontro, desenvolvedores e clientes escrevem a requisição do produto com uma lista de objetos, suas restrições e desempenho, podendo ser feitas miniespecificações

65 Exemplo para uma empresa de produtos de consumo:
Nossa pesquisa indica que o mercado para sistemas de segurança domésticos cresce 40% ao ano. Gostaríamos de entrar no mercado construindo um sistema de segurança doméstico baseado em microprocessador que oferecesse proteção contra e/ou reconhecesse uma variedade de “situações” indesejáveis, tais como entrada ilegal, incêndio, alagamento e outros. O produto, experimentalmente chamado de SafeHOme, usará sensores apropriados para detectar cada situação, poderá ser programado pelo dono e telefonará automaticamente para uma agência de monitoração assim que uma situação for detectada

66

67 É importante saber ainda que:
Princípios de análise 1) o domínio de informação deve ser representado e compreendido 2) modelos que desenvolvam a informação, função e comportamento do sistema devem ser desenvolvidos 3) os modelos e o problema devem ser divididos em partições 4) o processo de análise deve mover-se da informação essencial para os detalhes de implementação É importante saber ainda que: O software processa dados e eventos O modelo do software é diferente do software O modelo tem partições com as funções mais importantes e os detalhes crescentes

68 Princípios da especificação
1) separar funcionalidade da implementação 2) linguagens de especificação orientadas a processos são exigidas 3) a especificação abrange o sistema do qual o software faz parte 4) a especificação deve abranger o ambiente 5) a especificação é um modelo cognitivo e obedece a algumas leis físicas 6) deve ser operacional 7) tolerante com a não inteireza 8) localizada e fracamente acoplada

69 Princípios da representação
1) pertinência ao problema 2) colocada em níveis 3) diagramas e outras notações restritas quanto ao número e consistente quanto ao uso O QUE SIGNIFICA ESTA NOTAÇÃO? 4) revisável Há também uma série de princípios para uma revisão detalhada de toda a especificação do software mais específica do que a do sistema

70 Revisão da especificação
Nível macroscópico Metas e objetivos permanecem consistentes? Interfaces foram descritas? O fluxo e a estruura são adequados? Os diagramas são claros? As funções estão no escopo? O comportamento é consistente com informação e funções? As restrições são realísticas? Qual é o risco tecnológico? Requisitos foram considerados? Critérios de validação foram detalhados? Há inconsistência, omissão, redundância? Contato com o cliente é completo? Protótipo ou manual foram revisados? Estimativas foram afetadas?

71 Revisão detalhada Enunciados da especificação
Olhar o porquê de conectivos persuasivos Por exemplo, certamente, obviamente, claramente Procurar termos vagos Algum, às vezes, usualmente, o mais, na maior parte Identificar listas incompletas Etc, assim po diante, daí pra frente, tal como Limites declarados com pressuposições não declaradas “códigos variam de 0 a 100” (inteiro, real…) Cuidado com pronomes pendentes Pedir prova das declarações com certeza Evitar outras definições para um mesmo termo Estrutura descrita em parágrafos (gráfico? Figura?) Quando houver cálculo, criar 2 exemplos

72 4. Análise estruturada 4.1 DFD 4.2 Dicionário de dados
Objetivo: introduzir a análise estruturada e suas ferramentas para uma compreensão geral de seu funcionamento

73 A análise estruturada é uma atividade de construção de modelos (modela o fluxo e o conteúdo)
Já foi muito utilizada Muito criticada Ainda existe em muitos documentos Muitas adaptações E foi a primeira Não teve um documento original único É associada ao projeto estruturado

74 DFD ou gráfico de bolha mais primitivo
A idéia é de que um modelo de fluxo pode ser feito por qualquer tamanho e complexidade com representações Transformação Entrada Saída Entidade externa DFD ou gráfico de bolha mais primitivo

75 O exemplo do Safehome O software SafeHome possibilita que o dono da casa configure o sistema de segurança quando ele for instalado, monitora todos os sensores ligados ao sistema e interage com o dono da casa por meio de um teclado e teclas de função…

76 Exemplos de diagramas de DFD para o SafeHome

77

78 Notações básicas Produtor ou consumidor de informações fora dos limites do sistema a ser modelado Transformador de informações que resida dentro dos limites a ser modelado Repositório de dados que são armazenados para serem usados em um ou mais processos Item de dados ou coleção de itens (fluxo)

79 5. Gerenciamento de Software
Objetivo: entender a idéia de gerenciamento aplicada ao processo de desenvolvimento de sotware e obter uma noção de como são usadas as métricas de desempenho

80 Software como produto de um projeto
Pistas para o problema: Primeiro a sobrevivência, depois a organização Não há pessoas para enxergar a importância Optar um método para as condições é custoso Gerência de projetos Conhecimento e prática administrativa Conhecimento da área de aplicação

81 Pessoas com alguma vivência ajudam nas estimativas
A gerência de projeto se constitui de um conjunto de ações que geram um resultado Executadas por pessoas… que devem ser informadas do que estão fazendo, porque, quanto tempo dispõem, onde e como devem fazer Pessoas com alguma vivência ajudam nas estimativas Dos riscos Das incertezas

82 Atividade de gerência de projetos de software

83 Também existem algumas etapas para a gerência de projetos
No entanto não devem ser seguidas como solução definitiva Devem ser adaptadas de acordo com o projeto

84 ESCOPO DE SOFTWARE Objetivos e requisitos iniciais
Conveniência de se realizar ou não o projeto São realizadas estimativas quanto a recursos, prazos e custos São definidas viabilidades técnicas, operacionais e econômicas: Quantidade de pessoas, ambiente, exigências de hardware e software etc TÉCNICAS: Estimativa de linha de código e ponto por função Modelo de custo construtivo (COCOMO) Estimativa de Putnam Modelo de pontos por função

85 As informações inciais da definição de escopo resultam em um contrato de desesenvolvimento ou “proposta de desenvolvimento do sistema” Há funções e pré-requisitos que dependem do comprometimento do cliente Deve ser; Claro Não tendencioso Realista e viável

86 PLANEJAMENTO Comece bem: defina QUAIS atividades devem ser realizadas
Definição das atividades O QUE POR QUE QUEM QUNADO COMO ONDE Os cronogramas são importantes e definem ordem e sequência

87

88

89 ORGANIZAÇÃO E COORDENAÇÃO
Formação humana (administrativa) com alguns cuidados Combinar conhecimentos técnicos de cada pessoa com uma tarefa apropriada Não colocar tarefas para quem não pode 1 tarefa de cada vez Obter comprometimento, não só envolvimento Depois das pessoas, o que é mais importante? Ao combinar as pessoas com outros fatores, considerar aspectos fundamentais Trabalhar com pequenos grupos Liderança técnica por competência Local de trabalho adequado

90 Benefícios: Redução de problemas de comunicação Padrão de qualidade Aprendizado mútuo Sociabilização do trabalho

91 ORGANIZAÇÃO E COORDENAÇÃO
Milestones (pontos de controle específicos) Andamento Atraso Controle Informal Interação casual (intencional ou não) Diminui a frequência e a burocracia Formal (periódico) Revisão gerencial (com narrativa do ponto atual e justificativa) Revisão técnica (aspectos mais específicos)

92 Revisões Revisar é fazer mudanças
Reconstrução, reordenação ou inclusão de outras atividade Rastreabilidade Razões: Perda de prazo Tarefa mal feita ou não realizada Mudança imprevisível Corte de recursos Novos elementos no escopo inicial

93 COMPLEMENTO da primeira parte antes da prova
Métodos de quarta geração em engenharia de software e novos paradigmas Métodos de entrevista e abordagem com o usuário / cliente Dicionário de dados Exemplo de tabela simples de orçamento

94 Métodos de quarta geração em engenharia de software e novos paradigmas
O modelo do ciclo de espiral é considerado um modelo que engloba os demais e os seus quadrantes envolvem os outros paradigmas Planejamento Análise / Avaliação das alternativas / riscos Desenvolvimento / Engenharia de software Avaliação do cliente Apesar disso tudo, ainda há técnicas de quarta geração e outras formas de combinação de paradigmas que podem não ser contempladas no ciclo de espiral…

95 Técnicas de quarta geração (4GT)
Abrangem um amplo conjunto de ferramentas de software que possibilitam que o desenvolvedor especifique alguma característica do software em um nível elevado Têm desenvolvido bastante mas continuam dependentes do diálogo cliente-desenvolvedor Para pequenas aplicações é possível passar diretamente da etapa da coleta de exigências para a implementação usando um linguagem de quarta geração (4GL) O uso de 4GL sem planejamento ocasiona os mesmos problemas que ocorrem nos enfoques convencionais Coleta de requisitos Estratégia de projeto Implementação 4GL Teste

96 Prós Contras Situação atual Redução no tempo de desenvolvimento
Produtividade aumentada Contras Não são fáceis quanto se imagina O código produzido é ineficiente A manutenibilidade é questionável Situação atual São mais voltadas para aplicações comerciais, mas já há uso para aplicações de engenharia e de tempo real Tempo reduzido para aplicações pequenas e intermediárias Para grandes projetos, necessita-se tanto ou mais análise, planejamento e teste

97 Combinação de paradigmas
Além do espiral, qualquer paradigma pode constituir uma base sobre a qual outros paradigmas são integrados, incluindo o uso de 4GT Não há necessidade de ser dogmático em relação a paradigmas para a engenharia de software – a natureza da aplicação deve ditar a abordagem a ser tomada Contudo, para uma prototipagem evolutiva, algumas eventos podem ser priorizados O usuário é incapaz ou não deseja examinar modelos abstratos em papel, como os diagramas e fluxos de dados. O usuário é incapaz ou não deseja articular seus requisitos de alguma forma e só pode determinar seus requisitos por meio de um processo de tentativa e erro. O sistema deverá ser em-linha, com atividades com tela completa em terminal, ao contrário dos sistemas de edição, atualização e relatório em lote. O sistema não requer a especificação de muitos detalhes em algoritmos.

98 Métodos de entrevista Na maioria das vezes, os elementos de que o analista precisa não estão a sua disposição de forma clara Métodos para coleta de informações Entrevistas Pesquisas em arquivos, manuais de procedimentos operacionais, administrativos e outros, bem como a verificação de todos os tipos de registros de informações existentes A entrevista deve ser planejada, desenvolvida sem divergência e com controle da arrogância

99 Planejamento (todos os pontos devem ser obedecidos)
1) Marcação de data e horário 2) Preparação do entrevistador – com preparação dos itens e sua sequênca, com alguma documentação e registro 3) Comportamento do entrevistador – adequação ao local, atenção ao entrevistado, interesse em resolver os problemas que lhe atingem, sem desviar a atenção para outros assuntos 4) Linguagem – evitar termos técnicos e só expressar elogios de forma honesta 5) Distinção entre fatos e opiniões 6) Necessidades do usuário – cuidado com o raciocínio em termos pessoais e o pedido antecipado de relatórios ou inclusão de recursos não necessários

100 Considerações gerais A entrevista pode ser dividida em três partes de forma que seja imperceptível para o usuário Perguntas abertas são bem vindas Princípios: não criticar a empresa, o trabalho do entrevistado, o sistema existente ou qualquer funcionário Relatório após deve ser feito com máxima urgência, para não esquecer os detalhes, mesmo que tenha gravado ou filmado Alguns princípios não tradicionais, sociais e situados podem ser observados para se fazer uma entrevista proveitosa

101 Dicionário de dados na análise estruturada
O dicionário de dados ou “dicionário de requisitos” surgiu para suprir a pouca definição que tem cada item Definição Listagem organizada de todos os elementos de dados que são pertinentes ao sistema, com definições precisas e rigorosas, de forma que tanto o usuário quanto o analista de sistemas tenham uma compreensão comum das entradas, das saídas, dos componentes dos depósitos de dados e até mesmo dos cálculos intermediários (Yourdon)

102 A maioria dos dicionários de dados têm as seguintes informações, compreendendo elementos de dados e estrutura de dados Nome: o nome principal do elemento Alias / pseudônimo: outros nomes usados para a primeira entrada Descrição: representação do conteúdo (deve ser curta!) Formato: se o dado é numérico, alfabético, alfanumérico, além de informações como comprimento e casas decimais, se houver Validade: o que é aceito pelo sistema. Ex.: data de emissão de duplicata igual ou inferior ao seu pagamento Controle: para garantir a integridade: data de origem, origem da informação, programas que utilizam o item e autorização de mudanças Grupos: estruturas e localização física (banco de dados, registros, arquivos) e os programas que utilizam o item

103 Considerações sobre as informações
Os três primeiros itens podem ser agrupados em informações gerais Os dicionários podem ter as mais diversas adequações e é recomendável que ferramentas de engenharia de software auxiliadas por computador sejam utilizadas O item descrição de conteúdo pode se comportar como sequência, seleção ou agrupamento Construção de dados Notação Significado = é composto de sequência + e seleção [ | ] ou…ou repetição { }n n repetições de ( ) dados opcionais * * comentário

104 Exemplo com o SafeHome No DFD de nível 2 do SafeHome o item de dados número telefônico é especificado Nome: número telefônico Pseudônimo: não tem Onde / como é usado: avaliar com planejamento (saída), discar número telefônico (entrada) Descrição: Número telefônico = [extensão local | número externo] Extensão local = [2001 | 2002 | … | 2999] Número externo = 9 + [número local | número de longa distância] Número local = prefixo + número de acesso Número de longa distância = (1) + código de área + número local Prefixo = [795 | 799 | 874 | 877] Número de acesso = *qualquer série de quatro números*

105 Exemplo com o de reposição de peças (exemplo em doc)
Nome: Número de peça Pseudônimo: Descrição: campo-chave que identifica singularmente uma peça específica no estoque Formato: Alfanumérico, 8 caracteres Localização: Relatório de estoque por execeção Estoque Reposição Nome: Reposição - quantidade Pseudônimo: Descrição: o número de unidades de uma determinada parte deverá ser reposto de uma só vez Formato: Numérico, 5 dígitos Localização: Relatório de estoque por execeção Estoque Reposição

106 Importância do dicionário de dados
Documentação oficial e comunicação Evitar redundância Padronização Grande fonte de consulta

107 Exemplo de tabela simples de orcamento

108 Objetivo: entender a noção de análise essencial e suas ferramentas
6. Análise essencial 6.1 DFD 6.2 DER 6.3 DTD 6.4 Dicionário de dados Objetivo: entender a noção de análise essencial e suas ferramentas

109 O modelo essencial surgiu como uma revisão do modelo estruturado
O modelo essencial critica a abordagem clássica de modelos de sistemas no seu desenvolvimento e como são abordados Modelo físico atual Modelo lógico atual Novo modelo lógico Novo modelo físico

110 Críticas do modelo essencial à abordagem clássica
O analista pode não conhecer a aplicação ou o ramo de atividade O usuário não querer ou não poder trabalhar com um novo modelo lógico Um menor esforço para transformação de um modelo lógico atual em um modelo físico

111

112

113

114

115

116

117

118

119

120

121