engenharia de software e sistemas - cin.ufpe.brkiev/if682/revisao_1_exercicio.pdf · o processo de...

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

[email protected]

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

Engenharia de software

• 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 necessidades das partes interessadas)‏

– Levando-se em conta restrições de desenvolvimento e recursos disponíveis

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

2

Engenharia de sistemas

• Engenharia de sistemas: – Mais ampla

– Muita ênfase em aspectos de hardware e infra-estrutura • 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

Sistemas sociotécnicos

4

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.

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.

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.

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.

Propagação de falhas

9


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.

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.

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

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.

O processo de software

• 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


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


Modelo cascata

16


Resposta ao modelo code-and-fix vigente na década de 70

Ian Sommerville, Engenharia de Software, 8ª. edição. Capítulo 4

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


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


Processos Iterativos

• 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


Desenvolvimento incremental

20



Modelo espiral do processo de software

21



Transformação Formal

• 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

22


esp. 2 esp. 1 implement.

Atividades de um processo de desenvolvimento (Sommerville)

• Especificação de software

• Projeto e implementação de software

• Validação de software

• Evolução de software

23


O processo de engenharia de requisitos

24


Também pode envolver a prototipação de partes do

sistema! Ian Sommerville, Engenharia de Software, 8ª. edição. Capítulo 4

Modelo genérico do processo de projeto de sistema

25


Fases de teste

26



Evolução de software

27



RUP

28


OpenUp

29


Scrum

Imagem disponível em: www.mountangoatsoftware.com/scrum

Gerenciamento de Projetos

• SWEBOK

– 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 (IEEE610.12-90)

31


Projetos

• 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


Dimensões de um Projeto

33


Escopo

Qualidade

Tempo

Custo

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


Critérios de sucesso

• 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


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

36


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.

• Elaboração de relatórios e apresentações.

37


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


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%

39


O processo de gerenciamento de riscos

40



Requisito

• 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


Tipos de requisitos

• 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


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


Metas e requisitos

• 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


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


Alternativas à especificação em linguagem natural

46



Engenharia de requisitos

47



Elicitação e análise

• 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


Entrevistas

• 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


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


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


User stories

• 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


Etnografia

• 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


Validação de requisitos

• 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


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


Atividades do Gerenciamento de configuração

56


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


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


Processo de Gerenciamento de Mudanças

59


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


Funcionalidades de um Sistema de Controle de Versões

• Manutenção de um repositório de itens de configuração

– Com suporte ao checkin e ao checkout distribuídos

61


Branching

62


Leituras recomendadas

• SOMMERVILLE, I. Engenharia de Software. 9ª. Ed. São Paulo: Pearson Education, 2011

63


engenharia de software e sistemas - cin.ufpe.brkiev/if682/revisao_1_exercicio.pdf · o processo de...

Documents