Engenharia de Software I CURSO DE INFORMÁTICA. 3O SEMESTRE PROF.: LUIS AUGUSTO MACHADO MORETTO. ESP.

Transcrição

1 Engenharia de Software I CURSO DE INFORMÁTICA. 3O SEMESTRE PROF.: LUIS AUGUSTO MACHADO MORETTO. ESP.

2 Na aula passada... Atividade em grupo Intro Eng. Software

3 Conhecimento, Problemas Video habilidades e atitudes; da Engenharia de Software Praticas Ageis

4 Se preocupa com o projeto, implementação, instalação e operação de sistemas que incluem hardware, software e pessoas. (Sommerville)

5 Um conjunto de componentes inter-relacionados organizados para atingir um certo objetivo. É organizado para executar certo método, procedimento ou controle ao processar informações. Automatiza ou apóia a realização de atividades humanas através do processamento de informações.

6 Sistemas grandes são projetados para resolver problemas problemáticos. Sistemas requerem abordagem multidisciplinar Infinitas possibilidades Falta de compreensão e confiança entre disciplinas Sistemas devem ser projetados para durarem muitos anos em um ambiente dinâmico.

7 Software Hardware Pessoas Banco de dados - Informações Usuários e Operadores Procedimentos Documentação

8 Sistema Sistema Sistema Sistema Sistema de de de de de Automação Bancária Folha de Pagamento Controle Acadêmico Biblioteca Controle de Tráfego Urbano Sistema de Controle de Elevadores Sistema de Editoração de Jornais

9 Podemos identificar três fases nos paradigmas de desenvolvimento vistos: Definição: Determina viabilidade, requisitos do software, especifica e projeta o sistema. Desenvolvimento: Implementação, integração e instalação. Operação:

10 Analista de Sistemas Patrocinador Gerente de Projetos Arquiteto de software

11 Atividade que engloba as tarefas da engenharia de sistemas de computador. Geralmente confundida com as atividades de análise de requisitos. Concentra-se em todos os elementos do sistema, não apenas software. Trabalha na fase de DEFINIÇÃO do sistema: especifica o sistema para o trabalho

12 Separar partes de hardware, software e peopleware requer muita negociação. Pessoas assumem que problemas com difícil solução são facilmente resolvidos pelo computador. Plataformas podem ser inapropriadas: software deve compensar isso.

13 Análise de sistemas envolve: Identificação das necessidades. Estudo de viabilidade. Análise, especificação e validação dos Requisitos. Projeto do sistema: Arquitetura Interface Dados

14 Econômica: análise custo benefício (pg 206 Pressman) Técnica: Estudo da função, desempenho e restrições para um sistema aceitável. Legal: infrações e violações legais (Ex: IA Médica) Alternativas

15 O processo que estabelece serviços necessários e restrições de operação e desenvolvimento. Requisitos: são objetivos ou restrições estabelecidas por clientes e usuários do sistema que definem as diversas propriedades do sistema (e que dizem respeito ao software). Natureza Funcional: Aquilo que o sistema deve fazer e!funcional: Restricoes para o funcionamento do sistema.

16 Feasibility study Requirements elicitation and analysis Requir ements specification Feasibility report Requirements validation System models User and system requirements Requirements document

17 Pressman define um documento básico para a especificação dos requisitos. Ele contém 8 partes: I. Introdução 1. Referências do Sistema 2. Descrição Geral 3. Restrições de projeto do software

18 II. Descrição da Informação 1. Representação do fluxo de informação a. Fluxo de Dados b. Fluxo de Controle 2. Representação do conteúdo de informação 3. Descrição da interface com o sistema

19 III. Descrição Funcional 1. Divisão funcional em partições 2. Descrição funcional a. Narrativas b. Restrições/limitações c. Exigências de desempenho d. Restrições de projeto e. Diagramas de apoio 3. Descrição do controle a. Especificação do controle b. Restrições de projeto

20 IV. Descrição Comportamental 1. Estados do Sistema VI. Bibliografia 2. Eventos e ações VII Apêndice V. Critérios de Validação 1. Limites de desempenho 2. Classes de testes 3. Reação esperada do software 4. Considerações especiais

21 Inicia a conversão da especificação em um sistema executável, projetando um Software a implementará. Define: a Arquitetura a Interface os Componentes as Estruturas de Dados os Algoritmos

22 Requirements specifica tion Design acti vities Architectur al design Abstract specifica t ion Interface design Component design Data structur e design Algorithm design System architectur e Software specifica t ion Interface specifica tion Component specifica tion Data structur e specifica tion Algorithm specifica tion Design pr oducts

23 Partition requirements Define sub system interfaces Identify sub systems Specify sub system functionality Assign requirements to sub systems

24 Existem diversas abordagens para o projeto de um sistema. Geralmente é feito de maneira gráfica Modelos possíveis: Fluxo de Dados (DFD) Entidade-relacionamento (MER) Estruturais Orientados a Objetos (UML)

25 Programador Testador Gerente de Projetos

26 Implementação: envolve a programação, depuração, validação e testes. traduz a estrutura definida durante o projeto em um programa executável OBS: As atividade de projeto e implementação estão fortemente relacionadas e geralmente são interligadas. Integração + Instalação.

27 Traduz o projeto em um programa. Programação é uma atividade pessoal: não existe um processo genérico (XP - Extreme Programming). Existem diversos paradigmas de programação: Estruturada Orientada a Objetos Funcional

28 Na depuração ocorre a remoção dos erros de implementação do programa. (o próprio programador executa alguns testes, encontrando e removendo falhas). Programa-se os testes unitarios e executa para testar pequenas unidades do programa Locate error Design error repair Repair error Re test program

29 A Verificação e a Validação permitem mostrar que o sistema está de acordo com a especificação e cumpre os requisitos do consumidor. Pode utilizar ferramentas formais. Envolve testes onde o sistema é executado em casos derivados da especificação e com processamento de dados reais.

30 Unit testing Module testing Sub system testing System testing Acceptance testing Component testing Integration testing User testing

31 Unidade: Componentes individuais Modulo: Coleção de Componentes Sub-sistema: Integração dos módulos. Foco na Interface. Sistema: O sistema como um todo Aceitação: O consumidor verifica o resultado. Assina termo de aceite do projeto!

32 Requir ements specification System specification System integration test plan Acceptance test plan Service System design Acceptance test Detailed design Sub system integration test plan System integration test Sub system integration test Module and unit code and tess

33 Diversos projetos (hardware, software e comunicação) ocorrem em paralelo. Pode envolver produtos COTS (Commercial Off-the-Shelf) Problemas: Falta de comunicação Burocracia mecanismos lentos de proposição de mudanças - causa de atrasos

34 É o processo de juntar o hardware, software e as pessoas que fazem o sistema. Deve ser realizado de maneira incremental: um sub-sistema de cada vez. Quando aparecem problemas de interface e falta de coordenação na entrega dos componentes. Ideal ter um build a cada hora! CVS /

35 Onde aparecem os erros do analista. Pode ocorrer resistência a implementação do novo sistema. Vários sistemas podem coexistir por algum tempo. Problemas físicos (cabos, eng. civil). Início do treinamento dos operadores.

36

37 Trará problemas não previstos (lei de Murphi) Usuários usarão o sistema de maneira não esperada Pode revelar problemas de interação com outros sistemas: Incompatibilidade física Erros de conversão de dados Interfaces inconsistentes Problemas na integracao

38 Grandes sistemas devem possuir uma longa vida: devem evoluir para atender novos desafios (mudanca na demanda de negocios). Sistemas existentes que devem ser mantidos são camados Sistemas Legados (legacy systems): Bancos de Dados com bug do milênio. Mainframes com Web front-end (muitos bancos tem ainda sistemas escritos em COBOL / FORTRAN!).

39 Software é inerentemente flexível: pode acomodar modificações. Mudanças nos negócios força modificações no software de apoio. Apesar de ter existido uma demarcação entre desenvolvimento e evolução, esta diferença está se tornando irrelevante e poucos sistemas são completamente novos.

40 Problema: evolução é custosa: Mudanças devem ser analisadas técnica e economicamente. Interação entre novos sub-sistemas podem causar novos problemas. A estrutura do sistema se corrompe a medida que se realiza mudanças. Decisões do projeto original raramente são racionais...

41 Define system requirements Assess existing systems Existing systems Propose system changes Modify systems New system

42 Um sistema deve ser retirado do serviço no término da sua vida útil. Pode requerer remoção de material: Poluição. Sistema deve ser encapsulado. Pode necessitar a transferência de dados e funcionalidade para um novo sistema.

43 Engenharia de Sistemas permite: via Análise de Sistemas: identificação das necessidades do cliente. determinar viabilidade econômica e técnica definir função do hardware e software. Especificação dos requisitos é conseqüência da análise. Projeto do sistema Implementação, validação e testes. Evolução.

44

45 1 Fazer Pedido versão 1 Caso de uso primário Atores: Cliente Pré condição: O usuário deve ter feito "log in" e obtido autorização do sistema

46 Fluxo de Eventos (caminho básico): O caso de uso começa quando o cliente seleciona "fazer pedido". O cliente fornece seu nome e endereço. Se o cliente fornece apenas o CEP, o sistema coloca automaticamente o a cidade e o estado. O cliente fornece os códigos do produto. (veja alternativa) O sistema devolve as descrições e o preço de cada produto. (Ponto de extensão Produto em Oferta) O sistema calculará os valores totais para cada produto fornecido. (Ponto de extensão Cliente Especial) O cliente fornece as informações sobre cartão de crédito. O cliente submete os dados ao sistema. O sistema verifica as informações fornecidas, marca o pedido como "pendente" e envia as informações de pagamento para o sistema de contabilidade e pagamento. Quando o pagamento é confirmado, o pedido é marcado como "confirmado" e o número de pedido (NP) é dado ao cliente. Pós condição: O pedido deve ter sido gravado no sistema e marcado como confirmado.

47 Fluxo de eventos secundário: A qualquer momento antes de submeter, o cliente pode selecionar cancelar. O pedido não é gravado e o caso de uso termina. No passo 7, se alguma informação estiver incorreta, o sistema pede ao cliente para corrigir a informação.

48 Escreva os casos de uso restantes com os fluxos base, alternativo, excecao, atores primarios, pre e pos condicoes. Grupo de 3!