Engenharia de Software e Sistemas

Transcrição

1 Engenharia de Software e Sistemas Revisão para 1º exercício Centro de Informática - Universidade Federal de Pernambuco Engenharia da Computação Kiev Gama kiev@cin.ufpe.br Slides originais elaborados por Ian Sommerville e adaptado pelos professores Marcio Cornélio, Vinicius Garcia e Kiev Gama O autor permite o uso e a modificação dos slides para fins didáticos

2 Engenharia de software [if682] Engenharia de Software e Sistemas - EC - CIn - UFPE Engenharia de software é uma disciplina relacionada com todos os aspectos da produção de software.... e propõe ferramentas, técnicas e processos para: Entender com precisão qual é o problema (as necessidades associadas ao sistema que deve ser ( construído/modificado Produzir uma solução adequada para esse problema (um sistema pronto para usar, levando-se em consideração as ( interessadas necessidades das partes Levando-se em conta restrições de desenvolvimento e recursos disponíveis 2

3 Engenharia de sistemas [if682] Engenharia de Software e Sistemas - EC - CIn - UFPE Engenharia de sistemas: Mais ampla Muita ênfase em aspectos de hardware e infraestrutura Abstração do hardware Organização física das partes do sistema Aspectos de comunicação Engloba a engenharia do software Os engenheiros de sistema estão envolvidos em diversas atividades da engenharia de software Projeto da arquitetura Elicitação e especificação de requisitos 3

4 Sistemas sociotécnicos 4

5 Sistemas Críticos Sistemas críticos de segurança A falha pode resultar em perda de vida, prejuízo ou dano para o ambiente; Sistema de proteção de planta química. Sistemas críticos de missão A falha pode resultar na deficiência de alguma atividade dirigida a metas; Sistema de navegação de nave espacial. Sistemas críticos de negócios A falha pode resultar em altas perdas econômicas; Sistema de contas de cliente em um banco.

6 Confiança no sistema Dependability Para sistemas críticos é, em geral, o caso em que a propriedade de sistema mais importante é a confiança. A confiança de um sistema reflete o grau de confiança do usuário nesse sistema, bem como a extensão de confiança do usuário que o operará conforme suas expectativas e que não falhará durante o uso normal. Utilidade e confiança não são a mesma coisa. Um sistema não tem de ser confiável para ser útil.

7 A importância da confiança Sistemas que não são confiáveis, inseguros ou desprotegidos, podem ser rejeitados pelos seus usuários. Os custos com falha de sistema podem ser muito altos. Sistemas não confiáveis podem causar perda de informação e, conseqüentemente, um alto custo de recuperação.

8 Sistemas sóciotécnicos críticos Falhas de hardware O hardware pode falhar por causa de erros de projeto e de produção, ou pelo fato de os componentes terem atingido o fim de sua vida natural. Falhas de software Software falha devido a erros na sua especificação, projeto ou implementação. Falha operacional Operadores humanos cometem erros. Atualmente, talvez sejam a maior causa de falhas de sistema.

9 Propagação de falhas [if682] Engenharia de Software e Sistemas - EC - CIn - UFPE 9

10 Confiança A confiança em um sistema equivale ao seu merecimento de confiança. Um sistema confiável é aquele em que os usuários depositam sua confiança.

11 Outras propriedades de confiança Facilidade de reparo Reflete a amplitude em que o sistema pode ser reparado no caso de uma eventual falha; Facilidade de manutenção Reflete a amplitude em que o sistema pode ser adaptado para novos requisitos; Capacidade de sobrevivência Reflete a amplitude na qual o sistema pode fornecer serviços quando está sob ataque hostil; Tolerância a erros Reflete a amplitude na qual os erros de entrada de usuário podem ser evitados e tolerados.

12 Defeitos e falhas Falhas são, em geral, resultado de erros derivados de defeitos no sistema. No entanto, os defeitos não resultam necessariamente em erros no sistema O estado defeituoso do sistema pode ser transitório, e corrigido antes do aparecimento de erros. Os erros não conduzem, necessariamente, a falhas de sistema O erro pode ser corrigido por detecção de erros built-in e pela recuperação

13 Realização de confiabilidade Prevenção de defeitos Técnicas de desenvolvimento são usadas para minimizar a possibilidade de erros e/ou detectá-los antes que causem a introdução de defeitos no sistema (ex. evitar LP que tenha manipulação de ponteiros) Detecção e remoção de defeitos O uso de técnicas de verificação e validação que aumentam a probabilidade de detecção e correção (teste e depuração) Tolerância a defeitos Técnicas de run-time são usados para assegurar que defeitos não resultem em erros de sistema e/ou que esses erros não resultem em falhas.

14 O processo de software [if682] Engenharia de Software e Sistemas - EC - CIn - UFPE Um conjunto estruturado de atividades, procedimentos, artefatos e ferramentas necessários para o desenvolvimento de um sistema de software Atividades: Especificação, Projeto, Validação, Evolução Exemplos: Processo Unificado (RUP), Programação Extrema, UML Components Um modelo de processo de software apresenta a descrição de um processo de uma perspectiva particular, normalmente focando apenas em algumas atividades. 14

15 [if682] Engenharia de Software e Sistemas - EC - CIn - UFPE Modelos genéricos de processo de software O modelo cascata Fases separadas e distintas de especificação e desenvolvimento. Engenharia de software baseada em componentes O sistema é montado a partir de componentes existentes. Desenvolvimento iterativo Sistema desenvolvido através de várias etapas Existem muitas variantes destes modelos Ex: desenvolvimento formal onde um processo semelhante ao cascata é usado, mas a especificação formal é refinada durante os vários estágios para um projeto implementável. 15

16 Modelo cascata [if682] Engenharia de Software e Sistemas - EC - CIn - UFPE Resposta ao modelo code-and-fix vigente na década de 70 Ian Sommerville, Engenharia de Software, 8ª. edição. Capítulo 4 16

17 [if682] Engenharia de Software e Sistemas - EC - CIn - UFPE Desenvolvimento evolucionário Implementação inicial, exposição do resultado aos comentários do usuário e refinamento desse resultado em versões Especificação, desenvolvimento e validação são intercaladas Dois tipos Desenvolvimento exploratório: explora requisitos e entrega um sistema final Prototipação throwaway: objetivo é compreender os requisitos do cliente 17

18 [if682] Engenharia de Software e Sistemas - EC - CIn - UFPE Engenharia de software baseada em componentes Baseado em reuso sistemático onde sistemas são integrados a partir de componentes existentes ou de sistemas COTS (Commercial-of-the-shelf) Estágios do processo Análise de componentes; Modificação de requisitos; Projeto de sistema com reuso; Desenvolvimento e integração. Esta abordagem está se tornando cada vez mais usada à medida que padrões de componentes têm surgido. Reuso acidental vs. Reuso planejado 18

19 Processos Iterativos [if682] Engenharia de Software e Sistemas - EC - CIn - UFPE Requisitos de sistema SEMPRE evoluem no curso de um projeto Algum retrabalho é necessário A abordagem iterativa pode ser aplicada a qualquer um dos modelos genéricos de processo Duas abordagens (relacionadas) Entrega incremental; Desenvolvimento espiral. Essência: especificação desenvolvida em conjunto com o software 19

20 Desenvolvimento incremental [if682] Engenharia de Software e Sistemas - EC - CIn - UFPE Ian Sommerville, Engenharia de Software, 8ª. edição. Capítulo 4 20

21 [if682] Engenharia de Software e Sistemas - EC - CIn - UFPE Modelo espiral do processo de software Ian Sommerville, Engenharia de Software, 8ª. edição. Capítulo 4 21

22 Transformação Formal [if682] Engenharia de Software e Sistemas - EC - CIn - UFPE Idéia geral: Uma especificação formal (definição matemática, não ambígua) do software é desenvolvida e posteriormente transformada em um programa através de regras que preservam a corretude da especificação esp. 1 esp. 2 implement. 22

23 Atividades de um processo de desenvolvimento (Sommerville) Especificação de software [if682] Engenharia de Software e Sistemas - EC - CIn - UFPE Projeto e implementação de software Validação de software Evolução de software 23

24 [if682] Engenharia de Software e Sistemas - EC - CIn - UFPE O processo de engenharia de requisitos Ian Sommerville, Engenharia de Software, 8ª. edição. Capítulo 4 Também pode envolver a prototipação de partes do sistema! 24

25 [if682] Engenharia de Software e Sistemas - EC - CIn - UFPE Modelo genérico do processo de projeto de sistema 25

26 Fases de teste [if682] Engenharia de Software e Sistemas - EC - CIn - UFPE Ian Sommerville, Engenharia de Software, 8ª. edição. Capítulo 4 26

27 Evolução de software [if682] Engenharia de Software e Sistemas - EC - CIn - UFPE Ian Sommerville, Engenharia de Software, 8ª. edição. Capítulo 4 27

28 RUP [if682] Engenharia de Software e Sistemas - EC - CIn - UFPE 28

29 OpenUp [if682] Engenharia de Software e Sistemas - EC - CIn - UFPE 29

30 Scrum Imagem disponível em:

31 Gerenciamento de Projetos SWEBOK [if682] Engenharia de Software e Sistemas - EC - CIn - UFPE Aplicação de atividades de gerenciamento (planejamento, coordenação, medição, controle e relatório) para assegurar que o desenvolvimento de software é sistemático, disciplinado e quantificado (IEEE ) 31

32 Projetos [if682] Engenharia de Software e Sistemas - EC - CIn - UFPE Definição do Project Management Institute (PMI): um esforço temporário para criar um produto ou serviço único Características dos projetos: Prazo limitado Recursos limitados e definidos a priori Data estipulada para conclusão Resultado diferente do que é produzido na rotina da organização 32

33 Dimensões de um Projeto [if682] Engenharia de Software e Sistemas - EC - CIn - UFPE Custo Escopo Tempo Qualidade 33

34 [if682] Engenharia de Software e Sistemas - EC - CIn - UFPE Gerenciamento de projetos de software Está relacionado às atividades envolvidas em assegurar que o software será entregue: dentro do prazo definido no crongrama; de acordo com os requisitos das organizações que desenvolvem e adquirem o software. Gerenciamento de projeto é necessário porque o desenvolvimento de software está sempre sujeito a restrições de orçamento e de cronograma Não abordaremos outros tipos de projeto que podem ser conduzidos em organizações de desenvolvimento de software 34

35 Critérios de sucesso [if682] Engenharia de Software e Sistemas - EC - CIn - UFPE Entregar o software para o cliente no prazo acordado. Manter os custos dentro do orçamento geral. Entregar um software que atenda às expectativas do cliente. Manter uma equipe de desenvolvimento feliz e que trabalhe bem. 35

36 PMBOK - Fases do Gerenciamento Iniciação Estudo de viabilidade, termo de abertura Planejamento Estudo do projeto e detalhamento do plano Execução Execução dos planos de projeto Controle Monitoramento e acompanhamento Finalização Aceite formal da entrega do projeto [if682] Engenharia de Software e Sistemas - EC - CIn - UFPE 36

37 Algumas atividades de gerenciamento Elaboração de proposta. Planejamento e desenvolvimento do cronograma do projeto. Estimativa de custo do projeto. Gerenciamento de riscos Gerenciamento de pessoas Monitoração e revisões de projeto. [if682] Engenharia de Software e Sistemas - EC - CIn - UFPE Elaboração de relatórios e apresentações. 37

38 [if682] Engenharia de Software e Sistemas - EC - CIn - UFPE Desenvolvimento do cronograma do projeto Dividir o projeto em tarefas e estimar tempo e recursos necessários para completar cada tarefa. Organizar tarefas simultâneas para fazer uso otimizado da força de trabalho. Minimizar dependências entre tarefas para evitar atrasos devido a uma tarefa ter de aguardar a conclusão de outra Normalmente lança mão de redes de atividades PERT (Program Evaluation and Review Technique)/CPM (Critical Path Method) Desenv. de software normalmente usa prioridades 38

39 Problemas no desenvolvimento do cronograma É difícil estimar dificuldades e problemas Logo, é difícil estimar o tempo total de uma atividade A produtividade não é proporcional ao número de pessoas que trabalham em uma tarefa. A inclusão de pessoas em um projeto atrasado o atrasa ainda mais devido aos overheads de comunicação. O inesperado sempre ocorre. Deve-se sempre considerar a contingência no planejamento. Margem mínima de 10% [if682] Engenharia de Software e Sistemas - EC - CIn - UFPE 39

40 [if682] Engenharia de Software e Sistemas - EC - CIn - UFPE O processo de gerenciamento de riscos Ian Sommerville, Engenharia de Software, 8ª. edição. Capítulo 5 40

41 Requisito [if682] Engenharia de Software e Sistemas - EC - CIn - UFPE Pode ser uma descrição abstrata de alto nível de um serviço, uma restrição de sistema ou até uma especificação matemática, entre outras coisas O problema cujo desenvolvimento do sistema deve resolver O sistema tem que ser construído de modo a satisfazer todos os seus requisitos 41

42 Tipos de requisitos [if682] Engenharia de Software e Sistemas - EC - CIn - UFPE Requisitos de usuário Declarações de alto nível escritas em linguagem natural Escritos para os clientes. Requisitos de sistema Um documento estruturado estabelecendo descrições detalhadas das funções, serviços e restrições operacionais do sistema. Define o que deve ser implementado e pode até ser parte de um contrato entre o cliente e o desenvolvedor. 42

43 [if682] Engenharia de Software e Sistemas - EC - CIn - UFPE Requisitos funcionais e não-funcionais Requisitos funcionais Serviços que o sistema deve fornecer Como o sistema deve reagir a entradas específicas Como o sistema deve se comportar em determinadas situações. Requisitos não-funcionais ou de qualidade Restrições sobre serviços ou funções oferecidos pelo sistema tais como restrições de timing, restrições sobre o processo de desenvolvimento, padrões, etc. 43

44 Metas e requisitos [if682] Engenharia de Software e Sistemas - EC - CIn - UFPE Requisitos não-funcionais podem ser difíceis de definir precisamente Requisitos imprecisos podem ser difíceis de verificar. Meta Uma intenção geral do usuário, tal como facilidade de uso. Requisito não-funcional verificável Uma declaração usando alguma medida que pode ser objetivamente testada. Metas são úteis para desenvolvedores quando exprimem as intenções dos usuários do sistema. 44

45 [if682] Engenharia de Software e Sistemas - EC - CIn - UFPE Problemas com linguagem natural Falta de clareza É difícil atingir uma precisão sem tornar o documento difícil de ler e ambíguo Confusão de requisitos Requisitos funcionais e não-funcionais tendem a estar misturados. Fusão de requisitos Vários requisitos diferentes podem ser expressos juntos Dificuldade de estruturar a especificação 45

46 [if682] Engenharia de Software e Sistemas - EC - CIn - UFPE Alternativas à especificação em linguagem natural Ian Sommerville, Engenharia de Software, 8ª. edição. Capítulo 6 46

47 Engenharia de requisitos [if682] Engenharia de Software e Sistemas - EC - CIn - UFPE Ian Sommerville, Engenharia de Software, 8ª. edição. Capítulo 7 47

48 Elicitação e análise [if682] Engenharia de Software e Sistemas - EC - CIn - UFPE Envolve pessoal técnico trabalhando com os clientes para descobrir sobre o domínio da aplicação, os serviços que o sistema deve fornecer e sobre as restrições operacionais. Pode envolver Usuários finais Gerentes Engenheiros envolvidos na manutenção Especialistas de domínio Representantes de sindicato, etc. Estes são chamandos stakeholders (partes interessadas) 48

49 Entrevistas [if682] Engenharia de Software e Sistemas - EC - CIn - UFPE Em entrevista formal ou informal, a equipe de ER formula questões para os stakeholders sobre os sistemas que eles usam e o sistema a ser desenvolvido. Existem dois tipos de entrevistas Entrevistas fechadas, onde um conjunto de questões predefinidas são respondidas. Entrevistas abertas, onde não há um roteiro predefinido e onde uma variedade de assuntos são explorados com os stakeholders. 49

50 [if682] Engenharia de Software e Sistemas - EC - CIn - UFPE Cenários Cenários são simulações de como um sistema poderá ser usado Eles devem incluir Uma descrição da situação inicial; Uma descrição do fluxo normal de eventos; Uma descrição do que pode dar errado; Informação sobre outras atividades concorrentes; Uma descrição do estado quando o cenário termina. Para sistemas interativos, cenários funcionam bem em combinação com protótipos da GUI 50

51 [if682] Engenharia de Software e Sistemas - EC - CIn - UFPE Casos de uso Os casos de uso constituem uma técnica baseada em cenários que identificam os agentes em uma interação e descrevem a interação em si. Apoiados pela UML Diagramas de casos de uso são usados para definir o escopo Especificações de casos de uso são cenários como o descrito anteriormente Um conjunto de casos de uso deve descrever todas as possíveis interações com o sistema. 51

52 User stories [if682] Engenharia de Software e Sistemas - EC - CIn - UFPE Utilizado em metodologias ágeis (XP, Scrum) como definição de requisitos em alto nível Na prática, detalha um item de backlog São lembretes de conversas com stakeholders Formato simples, pequeno e objetivo Como um <tipo/papel de usuário>, eu quero <objetivo> para <razão/benefício>. 52

53 Etnografia [if682] Engenharia de Software e Sistemas - EC - CIn - UFPE Um analista despende um tempo considerável observando e analisando como as pessoas realmente trabalham. As pessoas não têm de explicar seu trabalho. Fatores sociais e organizacionais de importância podem ser observados. Estudos de etnografia têm mostrado que o trabalho é, geralmente, mais rico e mais complexo do que o sugerido pelos modelos simples de sistema. 53

54 Validação de requisitos [if682] Engenharia de Software e Sistemas - EC - CIn - UFPE Dedica-se a mostrar que os requisitos definem o sistema que o cliente realmente deseja. Custos de erros de requisitos são altos e, desse modo, a validação é muito importante O custo da reparação de um erro de requisitos depois da entrega é muito maior que o custo de reparação de um erro de implementação 54

55 [if682] Engenharia de Software e Sistemas - EC - CIn - UFPE Gerenciamento de configuração Envolve o desenvolvimento e a aplicação de procedimentos e padrões para gerenciar um produto de software em evolução. O CM pode ser visto como parte de um processo mais geral de gerenciamento do projeto. Artefatos que estão sob gerenciamento de configuração são chamados de itens de configuração 55

56 [if682] Engenharia de Software e Sistemas - EC - CIn - UFPE Atividades do Gerenciamento de configuração 56

57 [if682] Engenharia de Software e Sistemas - EC - CIn - UFPE Planejamento de gerenciamento de configuração Todos os produtos do processo de software podem ser gerenciados: Especificações; Projetos; Programas; Dados de teste; Manuais de usuário. Milhares de artefatos separados podem ser gerados para um sistema grande e complexo de software. É necessário definir quais estão sujeitos ao gerenciamento de configuração 57

58 [if682] Engenharia de Software e Sistemas - EC - CIn - UFPE Gerenciamento de mudanças Sistemas de software estão sujeitos a solicitações contínuas de mudanças: De usuários; De desenvolvedores; De forças de mercado. O gerenciamento de mudanças está relacionado à manutenção da rastreabilidade dessas mudanças, de modo que: Reparos realmente corrijam falhas Novas falhas introduzidas por reparos possam ser identificadas rapidamente Seja fácil descobrir quais mudanças foram implementadas e quando 58

59 [if682] Engenharia de Software e Sistemas - EC - CIn - UFPE Processo de Gerenciamento de Mudanças 59

60 [if682] Engenharia de Software e Sistemas - EC - CIn - UFPE Baseline (linha de base) Codeline Conjunto de versões de um determinado componente Baseline Coleção de versões de componentes que constituem um sistema Mainline Sequência de baselines representando diferentes versões do sistema 60

61 Funcionalidades de um Sistema de Controle de Versões [if682] Engenharia de Software e Sistemas - EC - CIn - UFPE Manutenção de um repositório de itens de configuração Com suporte ao checkin e ao checkout distribuídos 61

62 Branching [if682] Engenharia de Software e Sistemas - EC - CIn - UFPE 62

63 [if682] Engenharia de Software e Sistemas - EC - CIn - UFPE Leituras recomendadas SOMMERVILLE, I. Engenharia de Software. 9ª. Ed. São Paulo: Pearson Education,