Aula 01 ES

8/16/2019 Aula 01 ES

1/46

8/16/2019 Aula 01 ES

2/46

22

EMENTA DA DISCIPLINA

 A crise do software e os requisitos dos produtos de software. Ciclo devida e paradigmas de desenvolvimento de software. Os conceitos demetodologia, técnica e ferramenta em engenharia de software. Oprocesso de engenharia de software.

8/16/2019 Aula 01 ES

3/46

33

CONTEÚDO PROGRAMÁTICO

1. Introdução à Engenharia de Software1.1. O que é Engenharia de Software.

1.2. Objetivo da Engenharia de Software: Qualidade e Produtividade1.3. Produto e Processo de Software1.4. Qualidade de Produto e Qualidade de Processo de Software

2. Processo de Software2.1. Conceitos2.2. Modelos de Ciclo de Vida (Modelos de Processo)

2.2.1 Modelo em Cascata2.2.2 Modelos Incrementais2.2.3 Modelos Evolucionários

3. CMM, CMMI4. MPS.BR5. Metodologias ágeis6. Especificação e Análise de Requisitos

6.1 Requisitos (Conceito e tipos)6.2. O Processo de Engenharia de Requisitos6.3. Levantamento de Requisitos6.4. Análise de Requisitos

7. Projeto de Sistemas

8. Implementação e testes8.1. Implementação8.2. Estratégias e tipos de testes

9. Entrega e manutenção9.1. Entrega e manutenção9.2. Tipos de manutenção

10. Gerência de Projetos de Software11. Gerência da Qualidade de Software12. Reengenharia de Software

12.1 Processo de Reengenharia de Software12.2 Ferramentas de apoio a Reengenharia de Software

8/16/2019 Aula 01 ES

4/46

44

Exposições, discussão de textos, análise de estudos decaso

 Atividades extra-classe

RECURSOS UTILIZADOS NO DESENVOLVIMENTO DADISCIPLINA

Computador 

Datashow

Quadro Branco

AVALIAÇÃO DA DISCIPLINA

Frequência

 Atividades em sala e extra-classe

 Avalia ões individuais

MÉTODOS E TÉCNICAS PARA O DESENVOLVIMENTO DADISCIPLINA

8/16/2019 Aula 01 ES

5/46

5

BIBLIOGRAFIA

10.1. Básica

GUSTAFSON, D. Teoria e Problemas de Engenharia de Software, Bookman, 2003(Coleção Schaum).

PAULA FILHO, W. de P. Engenharia de Software – Fundamentos, Métodos ePadrões. LTC, 2001

PFLEEGER, Shari Lawrence. Engenharia de Software - Teoria e Prática, 2ª Edição,Makron Books, 2004.PRESSMAN, R. S. Engenharia de Software, 5ª Edição, Rio de Janeiro: McGraw-Hill2002.

SOMMERVILLE, Ian. Engenharia de Software, 8ª Edição, São Paulo: Addison-Wesley,

2007.

8/16/2019 Aula 01 ES

6/46

6

BIBLIOGRAFIA

10.2. Complementar 

CARVALHO, A.M.B.R. e CHIOSSI, T.C.S. Uma Introdução a Engenharia de Software. SãoPaulo: Editora da Unicamp, 2001.

McCONNELL, S. Code Complete: um Guia Completo para Construção de Software.Porto Alegre: Bookman, 2000.

REZENDE, D. A. Engenharia de Software e Sistemas de Informações. Brasport, 1999.

8/16/2019 Aula 01 ES

7/46

• Elaborar e apresentar um artigo. – Entrega e apresentações (2/02/15 e 09/02/15)

• Desenvolver o projeto de uma aplicação. – Será desenvolvido durante o semestre

(Avaliações Progressivas)

 – Sugestão (utilizar este projeto como atividade

de POO)

7

 AtA ATIVIDADES

8/16/2019 Aula 01 ES

8/46

88

INTRODUÇÃO DE

ENGENHARIA DESOFTWATE

INTRODUÇÃO DE

ENGENHARIA DESOFTWATE

8/16/2019 Aula 01 ES

9/46

99

SOFTWARE - PAPEL DA

SOCIEDADE

Produtos de software fazem parte do nosso cotidiano eexercem papel estratégico para o alcance dos nossosobjetivos individuais, coletivos e corporativos(organizacionais).

8/16/2019 Aula 01 ES

10/46

10

Iniciantes da área na Ciência daComputação costumam confundir o

desenvolvimento de software comprogramação.

8/16/2019 Aula 01 ES

11/46

1111

Perguntas Importantes:

Você já participou de um projeto

cujo software resultante não terminouou nunca foi utilizado?

Na sua opinião, quais foram osproblemas deste projeto?

8/16/2019 Aula 01 ES

12/46

1212

Prováveis problemas no projeto deSoftware...

Desvio do escopo original.

Problemas de integração.Reescrita constante do código fonte.Estimativas de prazos, custo e esforço refeitosconstantemente.Modificações na concepção do projeto e reescritado código durante os testes.Falta de documentação (atualizada) relatando asdecisões de projeto

8/16/2019 Aula 01 ES

13/46

1313

 Alguns dados de projetos (1)...

O desenvolvimento de aplicações, especialmenteas grandes, envolve vários riscos.Por exemplo, riscos de cancelamento ou atrasosaumentam à medida que aumenta o tamanho globaldo aplicativo.Em uma pesquisa de 8000 projetos, verificou-seque 30% deles foram cancelados.Estes projetos estavam em média 1 ano atrasadose excederam em 200% o custo estimado.

8/16/2019 Aula 01 ES

14/46

14

 Alguns dados de projetos (2)...

Nos projetos concluídos, 2/3 foram executados comatraso e com custo acima do previsto.

Nos projetos concluídos, 2/3 passaram por  problemas de confiabilidade em relação àsfuncionalidades oferecidas e apresentaramproblemas de qualidade no primeiro ano de uso.

Segundo outro levantamento, foram registradasocorrências de 0.5 a 3.0 defeitos por 1000 linhascódigo.

8/16/2019 Aula 01 ES

15/46

15

QUESTIONAMENTOS IMPORTANTES

Por que leva tanto tempo para concluir o software?

Por que os custos de desenvolvimento são tãoaltos?

Por que gastamos tanto tempo e esforço mantendoprogramas existentes?

Por que não podemos achar todos os erros antesde entregar o software aos clientes?

(Pressman,2010)

8/16/2019 Aula 01 ES

16/46

16

O que é Engenharia de

Software?

O intuito da engenharia de software

é fornecer uma estrutura paraconstrução de software com altaqualidade.

8/16/2019 Aula 01 ES

17/46

17

O que é Engenharia deSoftware?

 A Engenharia de Software trata de aspectos relacionadosao estabelecimento de processos, métodos, técnicas,

ferramentas e ambientes de suporte ao desenvolvimentode software.

De acordo com o [IEEE, 93] a engenharia é aplicaçãode uma abordagem sistemática, disciplinada e

quantificável, para o desenvolvimento, operação emanutenção do software; isto é, a aplicação daengenharia ao software.

8/16/2019 Aula 01 ES

18/46

18

Objetivos da Engenharia de Software

Melhorar a qualidade dos produtos de

software desenvolvidos.

Mas , o que seria qualidade de software?

8/16/2019 Aula 01 ES

19/46

19

Qualidade de Software A qualidade de software é um conceito com Múltiplas facetas:

Perspectiva do usuário : para um usuário um produto de software éde boa qualidade se ele satisfizer suas necessidades, sendo fácil deusar, eficiente e confiável. (perspectiva externa pelo uso do produto)

Perspectiva do desenvolvedor : para um desenvolvedor um produtode boa qualidade tem de ser fácil de manter , de compreender e incluirnovas funcionalidades. (perspectiva interna)

Perspectiva do cliente: o produto de software deve agregar valor aoseu negócio. (qualidade em uso)

Todas essas perspectivas estão focadas noproduto de software !!!!!

8/16/2019 Aula 01 ES

20/46

Envolve diferentes características:

Usabilidade

Confiabilidade

Manutenibildade

Eficiência

PortabilidadeSegurança

Produtividade 20

Qualidade de Software

8/16/2019 Aula 01 ES

21/46

21

 A qualidade do produto de software dependefortemente da qualidade dos processos usados

para desenvolvê-lo e mantê-los.

Qualidade de Software

8/16/2019 Aula 01 ES

22/46

22

Processos de Software

Para se construir um produto ou sistema é necessário seguir uma série depassos previsíveis, isto é, um guia que ajude a chegar a um resultado dequalidade dentro do tempo previsto(Falbo, 2005).

Um conjunto de atividades, métodos, práticas e transformações queguiam pessoas na produção de software. (Falbo, 2005)

8/16/2019 Aula 01 ES

23/46

23

Processos de Software

Segundo Pressman engloba um conjunto de atividades guarda-chuva que sãoaplicáveis à grande maioria dos projetos de software. Pode-se considerar umarcabouço de processo genérico.

Comunicação

Planejamento

Modelagem

Construção

Implantação

Comunicação com cliente, abrange levantamento de

requisitos.

Desenvolver um plano de trabalho , com as tarefastécnicas, os risco prováveis, os recursos necessários,os produtos de trabalho , cronograma.

 Atividade que envolve a criação de modelos, que vai

permitir o desenvolvedor, cliente, entender melhor osrequisitos do software.

Combina geração do código e os testes que revelamerros no código

O software finalmente é entregue ao cliente, avalia oproduto entregue (feedback).

8/16/2019 Aula 01 ES

24/46

24

Processos de SoftwareRicardo Falbo (2005)destaca que o ciclo de vida de um software envolve pelo

menos as seguinte fases.

Planejamento  Análise e Especificaçãode Requisitos Projeto

Implementação Testes Entrega eImplantação

Operação Manutenção

8/16/2019 Aula 01 ES

25/46

25

Processos de Software: Modelosde Ciclo de Vida

No geral os modelos de processo contemplam asfases Análise e Especificação de Requisitos,

Projeto, Implementação, Testes , Entrega eImplantação.

8/16/2019 Aula 01 ES

26/46

26

Modelos de Ciclo de Vida

Podem ser agrupados em trêscategorias :

Modelos sequencias Modelos incrementais

Modelos evolutivos

8/16/2019 Aula 01 ES

27/46

27

 A escolha de um modelo de processo depende:

• Tipo de software• Paradigma de desenvolvimento (estruturado, orientado a

objetos, etc)

• Tamanho e complexidade do sistema

• Características da equipe

• Estabilidade dos requisitos

Modelos de Ciclo de Vida

8/16/2019 Aula 01 ES

28/46

28

Modelos Sequenciais

Modelo em cascata

Modelo em V

8/16/2019 Aula 01 ES

29/46

29

Modelo em Cascata

Modelo de ciclo de vida mais antigo e mais amplamente usado.

8/16/2019 Aula 01 ES

30/46

30

Modelo em Cascata

Requisitos são bem definidos e razoavelmenteestáveis.  A fase seguinte não deve começar antes que

a fase anterior tenha terminado. Uma das grandes vantagens consiste nadocumentação produzida. A entrega do sistema completo acontece em

um único marco ao final da entrega eimplantação.

8/16/2019 Aula 01 ES

31/46

31

Modelo em Cascata

Principais desvantagens:

O usuário precisa ter paciência , pois ele só vai ter  contato com uma versão operacional do software ao finaldo projeto.

Os requisitos devem ser estabelecidos de maneira clara, objetiva e completa logo no início do projeto, mas é difícilo usuário colocar todos os requisitos explicitamente. Ousuário nunca saber definir realmente o que deseja.

Forte dependência na realização das tarefas

Projetos reais muitas vezes não seguem o fluxosequencial que o modelo propõe.

8/16/2019 Aula 01 ES

32/46

32

Modelo em VVariação do modelo em cascata que procura enfatizar a estreita relação entre

as atividades de teste (teste de unidade, teste de integração, teste de sistemae teste de aceitação) e as demais fases do processo.

Implica que, caso sejamencontrados problemas

em uma atividade deteste, as fases do ciclo devida podem ter de ser  executadas novamentepara corrigir ou melhorar os problemas.

8/16/2019 Aula 01 ES

33/46

E quando é inviável esperar , e sobretudo quando

se tem a necessidade de disponibilizar

rapidamente uma versão operacional do software

 para o usuário ?

33

8/16/2019 Aula 01 ES

34/46

34

Modelos Incrementais

O Modelo Incremental

O Modelo RAD

8/16/2019 Aula 01 ES

35/46

35

O Modelo IncrementalO sistema é dividido em subsistemas ou módulos. Os incrementos ou

versões são definidos começando com um pequeno subsistema funcionalque, a cada ciclo, é acrescido de novas funcionalidades.

Variações do Modelo Incremental

8/16/2019 Aula 01 ES

36/46

36

 A cada ciclo ou interação uma versão operacional dosistema será produzido e entregue para uso e avaliaçãodetalhada do cliente.

Geralmente a primeira versão contém as funcionalidadecentrais, tratando dos requisitos básicos. Podem até ser considerados como versões simplificadas do produto final.

O Modelo Incremental

8/16/2019 Aula 01 ES

37/46

37

Menor custo e menos tempo são necessários para seentregar a primeira versão

O risco associados ao desenvolvimento de umincremento é menor, devido ao tamanho reduzido

 A gerência de projetos é mais complexa, sobretudoquando a divisão em subsistemas feita inicialmente não

for boa.

O Modelo Incremental

8/16/2019 Aula 01 ES

38/46

38

O Modelo RAD (Rapid Application Development)

 Assim como no modelo incremental o sistema é subdividido emsubsistemas e incrementos são realizados, a diferença é os incrementossão desenvolvidos em paralelo por equipes distintas e apenas uma únicaentrega é feita.

8/16/2019 Aula 01 ES

39/46

39

O Modelo RAD (Rapid Application Development)

O ciclo de desenvolvimento é curto pode variar de 60 a 90dias.

Se o sistema for muito grande , o número de equipes

crescerá e o desenvolvimento e a integração acabará ficandocomplexo.

Os requisito também tem de ser bem definidos e o objetivodo projeto for restrito.

Para adotar este modelo a organização tem que possuirrecursos humanos suficiente para acomodar várias equipes.

8/16/2019 Aula 01 ES

40/46

40

Modelos Evolucionários

Evoluem ao longo do tempo.

Requisitos instáveis

Modelo que lida com incertezas e acomodamas contínuas mudanças

Utilizado quando o problema não está bemdefinido e não pode ser totalmente especificadono inicio do desenvolvimento.

8/16/2019 Aula 01 ES

41/46

41

Modelos Evolucionários x

Incrementais

Modelos Evolucionário Incrementais

Os primeiros ciclos podemproduzir protótipos ouapenas modelos e nãonecessariamente versõesoperacionais do sistemas.

Desde o primeiro cicloentrega versõesoperacionais do sistema

Requisitos não definidos, einstáveis

Requisitos estáveis edefinidos

8/16/2019 Aula 01 ES

42/46

42

Modelos Evolucionários

O Modelo Espiral

8/16/2019 Aula 01 ES

43/46

43

Modelo Espiral

Em vez de representar o processo de software como uma seqüência deatividades, o processo é representado como uma espiral. Cada loop naespiral representa uma fase do processo de software.

8/16/2019 Aula 01 ES

44/46

44

Modelo Espiral

Nos primeiros ciclos nem sempre todas as atividadessão realizadas, um loop mais interno pode estarrelacionado a definição de requisitos, o próximo loop aanálise, o próximo ao projeto e assim por diante.

 As passadas subsequentes ao longo da espiralpodem desenvolver protótipos, chegandoprogressivamente a versões operacionais do software,até se obter o produto completo.

A abordagem cíclica aumenta incrementalmente o grau dedefinição e implementação de um sistema enquanto diminui

o grau de risco.

8/16/2019 Aula 01 ES

45/46

45

Prototipação

È uma técnica para ajudar engenheiros de software eclientes a entender o que está sendo construído quandoos requisitos não muito claros.

Pode ser implementada dentro do contexto de qualquerum dos modelos de processos de software.

8/16/2019 Aula 01 ES

46/46

 Atividade

• Resenha do artigo: Flexible andDistributed Software Processes: OldPetunias In New Bowls?

• Entrega dia 03/11/14 – Formatação ABNT

 – Máximo 3 páginas

OBS: O artigo está disponível no Dropbox.

46