Engenharia de Software Engenharia de Software

(1)

Engenharia de Software Engenharia de Software

Prof. Inês Ap. Gasparotto Prof. Inês Ap. Gasparotto

Boaventura Boaventura

1. Semestre/2001 1. Semestre/2001

(2)

Tópicos Tópicos

1- Introdução à Engenharia de Software 1- Introdução à Engenharia de Software

2 - Fundamentos Organizacionais de Sistemas 2 - Fundamentos Organizacionais de Sistemas

de Informação de Informação

3- Gerência de projeto de software- Gerência de projeto de software

4- Gerenciamento para a qualidade de software 4- Gerenciamento para a qualidade de software

5- Acompanhamento do processo de 5- Acompanhamento do processo de

desenvolvimento de software.

(3)

Software Software

1- Instruções 1- Instruções

quando executadas produzem a função e o desempenho desejados

2 - Estruturas de Dados 2 - Estruturas de Dados

possibilitam que os programas manipulem adequadamente a informação

3 - Documentos 3 - Documentos

descrevem a operação e o uso dos programas

(4)

Características do Software Características do Software

1. desenvolvido ou projetado por engenharia, não manufaturado no sentido clássico

2. não se desgasta mas se deteriora

3. a maioria é feita sob medida em vez de ser montada a partir de componentes existentes

(5)

Curva de falhas para o Hardware Curva de falhas para o Hardware

tempo

“desgaste”

“mortalidade infantil”

índice de falhas

(6)

Curva de falhas do Software Curva de falhas do Software

índice de

falhas mudançamudança

curva real curva real

curva idealizada

tempo

(7)

Aplicações do Software Aplicações do Software

BBÁÁSSIICCOO programas de apoio a outros programas DDEE TETEMMPPOO RREEALAL monitora, analisa e controla eventos do

mundo real

CCOOMMEERRCCIIALAL operações comerciais e tomadas de decisões administrativas

CCIIEENNTTÍÍFFIICCOO EE DDEE

EENGNGENENHHAARRIIAA algoritmos de processamento de números EEMBMBUUTTIIDDOO controla produtos e sistemas de mercados

industriais e de consumo DDEE COCOMPMPUTUTADADOORR

PPEESSSSOOAALL processamento de textos, planilhas eletrônicas, diversões, etc.

DDEE IINNTTEELLIIGGÊÊNNCCIIAA

AARRTTIIFFIICCIIAALL algoritmos não numéricos para resolver problemas que não sejam favoráveis à computação ou à análise direta

(8)

Evolução do Software Evolução do Software

(1950 - 1965)

 O hardware sofreu contínuas mudanças

 O software era uma arte "secundária" para a qual havia poucos métodos sistemáticos

 O hardware era de propósito geral

 O software era específico para cada aplicação

 Não havia documentação

(9)

Evolução do Software Evolução do Software

(1965 - 1975)

 Multiprogramação e sistemas multiusuários

 Técnicas interativas

 Sistemas de tempo real

 1^a geração de SGBD’s

 Produto de software - software houses

 Bibliotecas de Software

 Cresce n^o de sistemas baseado em computador

 Manutenção quase impossível

... CRISE DE... CRISE DE SOFTWARE SOFTWARE

(10)

Evolução do Software Evolução do Software

(1975 - hoje)

 Sistemas distribuídos

 Redes locais e globais

 Uso generalizado de microprocessadores - produtos inteligentes

 Hardware de baixo custo

 Impacto de consumo

... CRISE DE

... CRISE DE SOFTWARE SOFTWARE (aflição crônica???)(aflição crônica???)

(11)

Evolução do Software Evolução do Software

(Quarta era do software: atualidade)atualidade

 Tecnologias orientadas o objetos

 Sistemas especialistas e software de inteligência artificial usados na prática

 Software de rede neural artificial

 Computação Paralela

 Internet

... CRISE DE

... CRISE DE SOFTWARE SOFTWARE (aflição crônica???)(aflição crônica???)

(12)

Crise de Software Crise de Software

Refere-se a um conjunto de problemas

encontrados no desenvolvimento de software:

(1) As estimativas de prazo e de custo freqüentemente As estimativas de prazo e de custo freqüentemente são imprecisas

são imprecisas

“Não dedicamos tempo para coletar dados sobre o processo de desenvolvimento de software”

“Sem nenhuma indicação sólida de produtividade, não podemos avaliar com precisão a eficácia de novas ferramentas, métodos ou padrões”

(13)

Crise de Software Crise de Software

(2) A produtividade das pessoas da área de software A produtividade das pessoas da área de software não tem acompanhado a demanda por seus

não tem acompanhado a demanda por seus serviços

serviços

“Os projetos de desenvolvimento de software

normalmente são efetuados apenas com um vago indício das exigências do cliente”

(14)

Crise de Software Crise de Software

(3) A qualidade de software às vezes é menos que A qualidade de software às vezes é menos que adequada

adequada

Só recentemente começam a surgir conceitos quantitativos sólidos de garantia de qualidade de software

(4) O software existente é muito difícil de manterO software existente é muito difícil de manter

A tarefa de manutenção devora o orçamento destinado ao software

A facilidade de manutenção não foi enfatizada como um critério importante

(15)

Crise de Software Crise de Software

 estimativas de prazo e de custo 

 produtividade das pessoas 

 qualidade de software 

 software difícil de manter 

(16)

Causas dos problemas associados à Causas dos problemas associados à

Crise de Software Crise de Software

1. próprio caráter do Software 1. próprio caráter do Software

O software é um elemento de sistema lógico e não físico (produto intangível)

Conseqüentemente, o sucesso é medido pela qualidade de uma única entidade e não pela qualidade de muitas entidades manufaturadas

O software não se desgasta, mas se O software não se desgasta, mas se

deteriora!!!

(17)

2. falhas das pessoas responsáveis pelo 2. falhas das pessoas responsáveis pelo

desenvolvimento de Software desenvolvimento de Software

Gerentes sem nenhum background em software Os profissionais da área de software têm

recebido pouco treinamento formal em novas técnicas para o desenvolvimento de software Resistência a mudanças.

Causas dos problemas associados à Causas dos problemas associados à

Crise de Software

(18)

3. mitos do Software 3. mitos do Software

propagaram desinformação e confusão

 administrativos administrativos

 cliente cliente

 profissional profissional

Causas dos problemas associados à Causas dos problemas associados à

Crise de Software

(19)

Mitos do Software

Mitos do Software (administrativos) (administrativos)

Já temos um manual repleto de padrões e

procedimentos para a construção de software. Isso não oferecerá ao meu pessoal tudo o que eles

precisam saber?

Realidade:

Será que o manual é usado?

Os profissionais sabem que ele existe?

Ele reflete a prática moderna de desenvolvimento de software?

Ele é completo?

Realidade:

Será que o manual é usado?

Os profissionais sabem que ele existe?

Ele reflete a prática moderna de desenvolvimento de software?

Ele é completo?

(20)

Meu pessoal tem ferramentas de desenvolvimento de software de última geração; afinal lhes compramos os mais novos computadores.

Mitos do Software

Mitos do Software (administrativos) (administrativos)

Realidade:

É preciso muito mais do que os mais recentes computadores para se

fazer um desenvolvimento de software de alta qualidade.

Realidade:

É preciso muito mais do que os mais recentes computadores para se

fazer um desenvolvimento de software de alta qualidade.

(21)

Se nós estamos atrasados nos prazos, podemos adicionar mais programadores e tirar o atraso.

Mitos do Software

Mitos do Software (administrativos) (administrativos)

Realidade:

O desenvolvimento de software não é um processo mecânico igual à

manufatura.

Acrescentar pessoas em um projeto torna-o ainda mais atrasado. Pessoas

podem ser acrescentadas, mas somente de uma forma planejada.

Realidade:

O desenvolvimento de software não é um processo mecânico igual à

manufatura.

Acrescentar pessoas em um projeto torna-o ainda mais atrasado. Pessoas

podem ser acrescentadas, mas somente de uma forma planejada.

(22)

Uma declaração geral dos objetivos é suficiente

para se começar a escrever programas - podemos preencher os detalhes mais tarde.

Mitos do Software

Mitos do Software (cliente) (cliente)

Realidade:

Uma definição inicial ruim é a principal causa de fracassos dos esforços de

É fundamental uma descrição formal e

detalhada do domínio da informação, função, desempenho, interfaces, restrições de

projeto e critérios de validação.

Realidade:

Uma definição inicial ruim é a principal causa de fracassos dos esforços de

É fundamental uma descrição formal e

detalhada do domínio da informação, função, desempenho, interfaces, restrições de

projeto e critérios de validação.

(23)

Os requisitos de projeto modificam-se

continuamente, mas as mudanças podem ser facilmente acomodadas, porque o software é flexível.

Mitos do Software

Mitos do Software (cliente) (cliente)

Realidade:

Uma mudança, quando solicitada

tardiamente num projeto, pode ser maior do que mais do que uma ordem de

magnitude mais dispendiosa do que a mesma mudança solicitada nas fases iniciais.

Realidade:

Uma mudança, quando solicitada

tardiamente num projeto, pode ser maior do que mais do que uma ordem de

magnitude mais dispendiosa do que a mesma mudança solicitada nas fases iniciais.

(24)

FASES CUSTO DE MANUTENÇÃO

D^EFINIÇÃO 1 x

DESENVOLVIMENTO 1.5 - 6x

MANUTENÇÃO 60 - 100x

magnitude das mudanças

(25)

Assim que escrevermos o programa e o colocarmos em funcionamento nosso trabalho estará completo.

Mitos do Software

Mitos do Software (profissional) (profissional)

Realidade:

Os dados da indústria indicam que entre 50 e 70% de todo esforço gasto num

programa serão despendidos depois que ele for entregue pela primeira vez ao

cliente.

Realidade:

Os dados da indústria indicam que entre 50 e 70% de todo esforço gasto num

programa serão despendidos depois que ele for entregue pela primeira vez ao

cliente.

(26)

Enquanto não tiver o programa "funcionando", eu não terei realmente nenhuma maneira de avaliar sua

qualidade.

Mitos do Software

Mitos do Software (profissional) (profissional)

Realidade:

Um programa funcionando é somente uma parte de uma Configuração de Software

que inclui todos os itens de informação produzidos durante a construção e

manutenção do software.

Realidade:

Um programa funcionando é somente uma parte de uma Configuração de Software

que inclui todos os itens de informação produzidos durante a construção e

manutenção do software.

(27)

Preocupação: Sistematizar o processo de

criação e manutenção de software.

(28)

 Boehm: Engenharia de software envolve a

aplicação prática de conhecimento científico para o projeto e construção de programas de

computador e a documentação associada necessária para desenvolvê-los, operá-los e mantê-los.

Engenharia de Software Engenharia de Software

Definições

(29)

 IEEE Standard Glossary of Software Engineering terminology: Engenharia de software é uma

abordagem sistemática para o desenvolvimento, operação, manutenção de software

Software: programas de computador, procedimentos, regras, documentação

possivelmente associada, e dados sobre sua operação.

Engenharia de Software Engenharia de Software

Definições

(30)

 Fairley: Engenharia de software é a disciplina tecnologica e gerencial preocupada com a

produção sistemática e manutenção de produtos de software que são desenvolvidos e modificados no prazo estabelecido e dentro das estimativas de custo.

Engenharia de Software Engenharia de Software

Definições

(31)

abrange um conjunto de três elementos fundamentais:

Métodos, Ferramentas

Métodos, Ferramentas ee Procedimentos Procedimentos

Principais metas: melhorar a qualidade de produtos de software, aumentar a produtividade do pessoal técnico e aumentar a satisfação do cliente.

(32)

métodos: proporcionam os detalhes de métodos como fazer para construir o software

Engenharia de Software

(33)

 Planejamento e estimativa de projeto

 Análise de requisitos de software e de sistemas

 Projeto da estrutura de dados

 Algoritmo de processamento

 Codificação

 Teste

 Manutenção

Engenharia de Software

(34)

ferramentas: dão suporte automatizado ferramentas aos métodos.

 existem atualmente ferramentas para sustentar cada um dos métodos

 quando as ferramentas são integradas é estabelecido um sistema de suporte ao

desenvolvimento de software chamado CASE - Computer Aided Software Engineering

Engenharia de Software

(35)

procedimentos: constituem o elo de procedimentos

ligação entre os métodos e ferramentas

 seqüência em que os métodos serão aplicados

 produtos que se exige que sejam entregues

 controles que ajudam assegurar a qualidade e coordenar as alterações

 marcos de referência que possibilitam administrar o progresso do software.

Engenharia de Software

(36)

conjunto de etapas que envolveetapas

métodos métodos ferramentas ferramentas procedimentos procedimentos

Essas etapas são conhecidas como componentes de CICLO CICLO DE VIDA DE SOFTWARE

DE VIDA DE SOFTWARE ou ou Processo de SoftwareProcesso de Software

Engenharia de Software

(37)

Alguns ciclos de vida mais conhecidos são:

 Ciclo de Ciclo de Vida ClássicoVida Clássico

 Prototipação Prototipação

 Modelo Modelo Espiral Espiral

 Técnicas de 4Técnicas de 4^a^a Geração Geração

Engenharia de Software

(38)

para escolha de um Ciclo de Vida de Software:



natureza do projeto e da aplicação



métodos e ferramentas a serem usados



controles e produtos que precisam ser

entregues

(39)

Ciclo de Vida Clássico (Cascata) Ciclo de Vida Clássico (Cascata)

 modelo mais antigo e o mais amplamente usado da engenharia de software

 modelado em função do ciclo da engenharia convencional

 requer uma abordagem sistemática,

seqüencial ao desenvolvimento de software

(40)

Engenhari Engenhari

a de a de

Sistemas Sistemas

Engenhari Engenhari

a de a de

Sistemas

SistemasAnálise Análise de de

Requisitos Requisitos

Análise Análise de de

Requisitos

Requisitos Projeto Projeto Projeto Projeto

Codificaçã Codificaçã o o

Testes Testes Testes Testes

Manutenç Manutenç ãoão

Cascata

(41)

Atividades do Ciclo de Vida Clássico Atividades do Ciclo de Vida Clássico

ANÁLISE E ENGENHARIA DE ANÁLISE E ENGENHARIA DE SISTEMAS SISTEMAS  envolve a coleta de requisitos em

nível do sistema, pequena quantidade de projeto e análise de alto nível

Engenhari a de

SistemasAnálise de

Requisito s

Projeto

Codificaçã o Testes

Manutenç

ão  visão essencial quando o software deve fazer interface com outros elementos (hardware, pessoas e banco de dados)

(42)

Atividades do Ciclo de Vida Clássico Atividades do Ciclo de Vida Clássico

ANÁLISE DE REQUISITOS DE ANÁLISE DE REQUISITOS DE SOFTWARE SOFTWARE  processo de coleta dos requisitos

é intensificado e concentrado especificamente no software  deve-se compreender o domínio

da informação, a função, desempenho e interfaces exigidos  os requisitos (para o sistema e para

o software) são documentados e revistos com o cliente

Requisito s

Projeto

Manutenç ão

(43)

Atividades do Ciclo de Vida Clássico Atividades do Ciclo de Vida Clássico

PROJETO PROJETO

 tradução dos requisitos do software para um conjunto de representações que podem ser avaliadas quanto à qualidade, antes que a codificação se inicie  se concentra em 4 atributos do

programa:

 Estrutura de Dados,

 Arquitetura de Software,

 Detalhes Procedimentais e

 Caracterização de Interfaces Engenhari

a de

Requisito s

Projeto

Manutenç ão

(44)

Atividades do Ciclo de Vida Clássico Atividades do Ciclo de Vida Clássico

CODIFICAÇÃO CODIFICAÇÃO  tradução das representações

do projeto para uma linguagem “artificial”

resultando em instruções executáveis pelo computador

Requisito s

Projeto

Manutenç ão

(45)

Atividades do Ciclo de Vida Clássico Atividades do Ciclo de Vida Clássico

TESTES TESTES

Concentram-se:

 nos aspectos lógicos internos do software, garantindo que todas as instruções tenham sido testadas  nos aspectos funcionais

externos, para descobrir erros e garantir que a entrada definida produza resultados que concordem com os esperados.

Requisito s

Projeto

Manutenç ão

(46)

Atividades do Ciclo de Vida Clássico Atividades do Ciclo de Vida Clássico

MANUTENÇÃO MANUTENÇÃO

 o software deverá sofrer mudanças depois que for entregue ao cliente Engenhari

a de

Requisito s

Projeto

Manutenç ão

 causas das mudanças:

erros, adaptação do software para acomodar mudanças em seu ambiente externo e exigência do cliente para acréscimos funcionais e de desempenho

(47)

Problemas

Problemas com o Ciclo de Vida Clássico com o Ciclo de Vida Clássico

 projetos reais raramente seguem o fluxo seqüencial que o modelo propõe

 logo no início é difícil estabelecer explicitamente todos os requisitos. No começo dos projetos

sempre existe uma incerteza natural

o cliente deve ter paciência. Uma versão

executável do software só fica disponível numa etapa avançada do desenvolvimento

(48)

Embora o Ciclo de Vida Clássico tenha Embora o Ciclo de Vida Clássico tenha

fragilidades, ele é significativamente fragilidades, ele é significativamente

melhor do que uma abordagem casual melhor do que uma abordagem casual

ao desenvolvimento de software ao desenvolvimento de software Clássico

Clássico (comentários) (comentários)

(49)

Prototipação Prototipação

 processo que possibilita que o desenvolvedor crie um modelo do software que deve ser construído.

 idealmente, o modelo (protótipo) serve como um protótipo mecanismo para identificar os requisitos de

software.



apropriado para quando o cliente definiu um

conjunto de objetivos gerais para o software, mas não identificou requisitos de entrada,

processamento e saída com detalhes.

(50)

fim

início

construção produto

refinamento protótipo

avaliação protótipo

construção protótipo

projeto rápido obtenção

dos requisitos

Prototipação

(51)

Atividades da Prototipação Atividades da Prototipação

Obtenção dos Requisitos:

desenvolvedor e cliente definem os objetivos gerais do software, identificam quais requisitos são conhecidos e as áreas que necessitam de definições adicionais

Projeto Rápido:

Projeto Rápido: representação dos aspectos do software que são visíveis ao usuário (abordagens de entrada e formatos de saída) fim

início

(52)

Construção Protótipo:

implementação do projeto rápido

Avaliação do Protótipo:

cliente e desenvolvedor avaliam o protótipo

Atividades da Prototipação Atividades da Prototipação

fim

início

(53)

Refinamento dos Requisitos Refinamento dos Requisitos::

cliente e desenvolvedor refinam os requisitos do software a ser desenvolvido.

Ocorre neste ponto um processo de iteração que pode conduzir a iteração 1a. atividade até que as necessidades do cliente sejam satisfeitas e o desenvolvedor compreenda o que precisa ser feito.

Atividades da Prototipação Atividades da Prototipação

fim

início

(54)

Construção Produto:

identificados os requisitos, o protótipo deve ser descartado e a versão de produção deve ser construída considerando os critérios de qualidade.

Atividades da Prototipação Atividades da Prototipação

fim

início

(55)

Problemas

Problemas com a Prototipação com a Prototipação

cliente não sabe que o software que ele vê não considerou, durante o desenvolvimento, a

qualidade global e a manutenibilidade a longo prazo. Não aceita bem a idéia que a versão final do software vai ser construída e "força" a utilização do protótipo como produto final.

(56)

Problemas

Problemas com a Prototipação com a Prototipação

desenvolvedor freqüentemente faz uma

implementação comprometida (utilizando o que está disponível) com o objetivo de produzir

rapidamente um protótipo. Depois de um tempo ele familiariza com essas escolhas, e esquece que elas não são apropriadas para o produto final.

(57)

Ainda que possam ocorrer problemas, a prototipação é um ciclo de vida eficiente



A chave é definir-se as regras do jogo logo no começo



O cliente e o desenvolvedor devem ambos concordar que o protótipo seja construído para servir como um mecanismo a fim de definir os requisitos



Prototipação

Prototipação (comentários) (comentários)

(58)

Ciclo de Vida em

Ciclo de Vida em Espiral Espiral

 engloba as melhores características do ciclo de vida Clássico e da Prototipação, adicionando um novo

elemento: a Análise de RiscoAnálise de Risco

 segue a abordagem de passos sistemáticos do Ciclo de Vida Clássico incorporando-os numa estrutura iterativa iterativa ^que

reflete mais realisticamente o mundo real

 usa a Prototipação, em qualquer etapa da evolução do produto, como mecanismo de redução de riscos

(59)

decisão de continuar ou não

direção de um sistema concluído

avaliação

do cliente engenharia análise dos

riscos planejamento

Espiral

(60)

Atividades do Ciclo de Vida em

Atividades do Ciclo de Vida em Espiral Espiral

Planejamento:

Planejamento: determinação dos objetivos, alternativas e restrições

Análise de Risco: análise das

alternativas e identificação / resolução dos riscos

Construção:

Construção: desenvolvimento do produto no nível seguinte

Avaliação do Cliente:

Avaliação do Cliente: avaliação do produto e planejamento das novas fases

avaliação do

cliente engenharia análise dos

riscos planejamento

(61)

 é, atualmente, a abordagem mais realística para o desenvolvimento de software em grande escala.

 usa uma abordagem que capacita o desenvolvedor e o cliente a entender e reagir aos riscos em cada etapa evolutiva.

 pode ser difícil convencer os clientes que uma abordagem

"evolutiva" é controlável

 exige considerável experiência na determinação de riscos e depende dessa experiência para ter sucesso

Espiral

Espiral (comentários) (comentários)

(62)



o modelo é relativamente novo e não tem sido amplamente usado

Demorará muitos anos até que a eficácia desse modelo possa ser determinada com certeza absoluta.

Espiral

Espiral (comentários) (comentários)

(63)

Técnicas de 4

^a^a

Geração Geração

Concentra-se na capacidade de se especificar o software a uma máquina em um nível que esteja próximo à

linguagem natural.

Engloba um conjunto de ferramentas de software que possibilitam que:

 o sistema seja especificado em uma linguagem sistema seja especificado em uma linguagem de alto nível

de alto nível e

o código fonte seja gerado automaticamente a código fonte seja gerado automaticamente partir dessas especificações

(64)

Obtenção dos

Requisitos Obtenção dos

RequisitosEstratégia do

“Projeto”

Estratégia do

“Projeto” Implement ação

usando 4GL Implement ação

usando 4GL Testes Testes

Técnicas de 4

^a^a

Geração Geração

(65)

Ferramentas do ambiente de Ferramentas do ambiente de

desenvolvimento de software de 4GL desenvolvimento de software de 4GL

O ambiente de desenvolvimento de software que sustenta o ciclo de vida de 4^a geração inclui as ferramentas:

 linguagens não procedimentais para consulta de banco de dados

 geração de relatórios

 manipulação de dados

 interação e definição de telas

 geração de códigos

 capacidade gráfica de alto nível

 capacidade de planilhas eletrônicas

(66)

Atividades das Técnicas de 4

^a^a

Geração Geração

1. obtenção dos Requisitos:

1. obtenção dos Requisitos:^o

cliente descreve os requisitos os quais são traduzidos para um protótipo operacional

Requisito s

Estratégi a do

“Projeto”Implemen tação

usando

4GL Testes

o cliente pode estar inseguro quanto aos requisitos

o cliente pode ser incapaz de

especificar as informações de um modo que uma ferramenta 4GL possa

consumir

as 4GLs atuais não são sofisticadas suficientemente para acomodar a verdadeira "linguagem natural"

(67)

2. estratégia de "Projeto":

para pequenas aplicações é

possível mover-se do passo de Obtenção dos Requisitos para o passo de Implementação usando uma Linguagem de 4G

Requisito s

usando

4GL Testes

Atividades das Técnicas de 4

^a^a

Geração Geração

para grandes projetos é necessário desenvolver uma estratégia de projeto.

De outro modo ocorrerão os mesmos problemas encontrados quando se usa abordagem convencional (baixa

qualidade)

(68)

3. implementação usando 3. implementação usando 4GL:4GL: os resultados desejados são representados de modo que haja geração automática de

código . Deve existir uma estrutura de dados com

informações relevantes e que seja acessível pela 4GL

Atividades das Técnicas de 4

^a^a

Geração Geração

Requisito s

usando

4GL Testes

(69)

Atividades das Técnicas de 4

^a^a

Geração Geração

Requisito s

usando

4GL Testes

4. teste:

4. teste: o desenvolvedor deve efetuar testes e

desenvolver uma

documentação significativa.

O software desenvolvido deve ser construído de

maneira que a manutenção possa ser efetuada

prontamente.

(70)

PROPONENTES:

PROPONENTES: redução dramática no tempo de desenvolvimento do software (aumento de

produtividade) OPONENTES

OPONENTES: as 4GL atuais não são mais fáceis de usar do que as linguagens de programação

 o código fonte produzido é ineficiente

 a manutenibilidade de sistemas usando técnicas 4G ainda é questionável

Técnicas de 4

^a^a

Geração Geração (comentários) (comentários)

(71)

Mudança na natureza de desenvolvimento de Mudança na natureza de desenvolvimento de

software software

métodos convencionais

aplicação de técnicas de 4^a

Geração

demanda demanda

global global

demanda por software

1970 1980 1990 2000

(72)

Combinação dos Métodos de Ciclo de Vida Combinação dos Métodos de Ciclo de Vida

obtenção dos requisitos preliminares

modelo espiral técnicas

4G protomodelagem

análise dos requisitos

projeto

codificação

testes

manutenção protomodelagem

no. interação

protomodelagem no. interação

técnicas 4G

modelo espiral no. interação

sistema completo

(73)

Engenharia de Software

uma visão genéricauma visão genérica

O processo de desenvolvimento de software processo de desenvolvimento de software contém 3 fases genéricas, independentes do modelo de engenharia de software escolhido:

1.

DEFINIÇÃO, DEFINIÇÃO

2. DESENVOLVIMENTO e DESENVOLVIMENTO

3. MANUTENÇÃO. MANUTENÇÃO

(74)

1. Revisões

2. Documentação 3. Controle de

Mudanças

C C

Cooonnnssstttrrruuuçççãããooo

1. Entender 2. Modificar 3. Revalidar

Manutenção

“mudanças”

O O

Opppeeerrraaaçççãããooo

S S

SOOOFFFTTTWWWAAARRREEE

P P

PRRROOODDDUUUTTTOOO

A A

Atttiiivvviiidddaaadddeeesss dddeee AAApppoooiiiooo

1. Análise de Sistema

2. Planejamento do Projeto 3. Análise de

Requisitos Definição

“o que” Desenvolvimento

“como”

1. Projeto de Software 2. Codificação 3. Teste

  

 

Engenharia de Software

(75)

DEFINIÇÃO

DEFINIÇÃO^: ““o que” será desenvolvido. o que”

 Análise do SistemaAnálise do Sistema: define o papel de cada :

elemento num sistema baseado em computador, atribuindo em última análise, o papel que o

software desempenhará.

 Planejamento do Projeto de SoftwarePlanejamento do Projeto de Software: assim que : o escopo do software é estabelecido, os riscos são analisados, os recursos são alocados, os custos são estimados e, tarefas e programação de

trabalho definidas.

Engenharia de Software

(76)

 Análise de RequisitosAnálise de Requisitos: o escopo definido para o : software proporciona uma direção, mas uma

definição detalhada do domínio da informação e da função do software é necessária antes que o

trabalho inicie.

Engenharia de Software

(77)

DESENVOLVIMENTO

DESENVOLVIMENTO: “como” o software vai ser “como”

desenvolvido.

 Projeto de SoftwareProjeto de Software: traduz os requisitos do :

software num conjunto de representações (algumas gráficas, outras tabulares ou baseadas em

linguagem) que descrevem a estrutura de dados, a arquitetura do software, os procedimentos

algorítmicos e as características de interface.

Engenharia de Software

(78)

 CodificaçãoCodificação: as representações do projeto devem : ser convertidas numa linguagem artificial (a linguagem pode ser uma linguagem de programação

convencional ou uma linguagem não procedimental) que resulte em instruções que possam ser executadas pelo computador.

 Realização de Testes do SoftwareRealização de Testes do Software: logo que o :

software é implementado numa forma executável por máquina, ele deve ser testado para que se possa

descobrir defeitos de função, lógica e implementação.

Engenharia de Software

(79)

MANUTENÇÃO

MANUTENÇÃO: concentra-se nas :

“mudanças”

“mudanças” que ocorrerão depois que o software for liberado para uso operacional

 Correção

 Adaptação

 Melhoramento Funcional

Engenharia de Software

(80)

Correção

Correção: mesmo com as melhores atividades de :

garantia de qualidade de software, é provável que o cliente descubra defeitos no software. A manutenção manutenção

corretiva

corretiva muda o software para corrigir defeitos.

Adaptação

Adaptação: com o passar do tempo, o ambiente original : (por exemplo a CPU, o sistema operacional e

periféricos) para o qual o software foi desenvolvido

provavelmente mudará. A manutenção manutenção adaptativa muda adaptativa o software para acomodar mudanças em seu ambiente.

Engenharia de Software

(81)

Melhoramento Funcional

Melhoramento Funcional: a medida que o :

software é usado, o cliente/usuário reconhecerá funções adicionais que oferecerão benefícios.

A manutençãomanutenção perfectiva estende o software perfectiva para além de suas exigências funcionais

originais.

Engenharia de Software

(82)

Atividades de Proteção:

Atividades de Proteção: as fases e etapas correlatas descritas são complementadas por uma série de

atividades de proteção.

Revisões

Revisões: : efetuadas para garantir que a qualidade seja mantida à medida que cada etapa é concluída.

Documentação

Documentação:: é desenvolvida e controlada para garantir que informações completas sobre o software estejam

disponíveis para uso posterior.

Controle das Mudanças

Controle das Mudanças:: é instituído de forma que as mudanças possam ser aprovadas e acompanhadas.

Engenharia de Software

(83)

A Engenharia de Software também se preocupa com A Engenharia de Software também se preocupa com

questões gerenciais, que encontra-se do lado oposto questões gerenciais, que encontra-se do lado oposto

ao domínio da programação ao domínio da programação Gerenciamento:

Gerenciamento: necessário para coordenar as necessário para coordenar as atividades técnicas em projetos de produtos de atividades técnicas em projetos de produtos de

software.

Engenharia de Software

uma aborgagem uma aborgagem gerencial

gerencial

(84)

Em geral, um

Em geral, um produto de software produto de software inclui: inclui:

-> Código fonte, e documentação relacionada:-> Código fonte, e documentação relacionada:

 documento de requisitos

 especificação do projeto

 planos de teste

 princípios de operação

 procedimentos para garantia da qualidade

Engenharia de Software

gerencial

(85)

Em geral, um

Em geral, um produto de software produto de software inclui: inclui:

-> Cogido fonte, e documentação relacionada:-> Cogido fonte, e documentação relacionada:

 relatórios de problemas com o software

 procedimentos de manutenção

 manuais do usuário

 instruções para instalação

 auxílio para treinamento

Engenharia de Software

gerencial

(86)

Qualidade de software

Qualidade de software : preocupação principal dos: preocupação principal dos gerentes de software.

gerentes de software.

-> Principal atributo de qualidade: -> Principal atributo de qualidade: utilidadeutilidade

-> outros atributos de qualidade:

- transportabilidade - eficiência

- clareza

- confiabilidade

Engenharia de Software

gerencial